Skip to Content
Technical Articles
Author's profile photo Johannes Goerlich

CommonCryptoLib: SNC protocol versions and cipher suites

Many years ago SAP deprecated the SAPCRYPTOLIB and introduced the CommonCryptoLib (CCL) as its successor. The CCL is not only a replacement for its predecessor but also for gsskrb5.dll, gI64krb5.dll, and gx64krb5.dll, which may still be used as Microsoft Kerberos Security Service Provider (SAP Note 352295) and gssntlm.dll, gI64ntlm.dll, and gx64ntlm.dll, which are hopefully no longer as Microsoft NTLM Security Service Provider, as NTLM must be considered as broken (Pass the Hash, PtH).

In the meantime the CCL is available in its latest version 8.5.x and is used by the SAP NetWeaver AS ABAP, ABAP Platform, SAP Java Connector, SAP .Net Connector, as well as by SAP NetWeaver AS Java (when acting as server) amongst others for encrypting communication using SNC.

 

Please also read the other blogposts of this series:

CommonCryptoLib: TLS protocol versions and cipher suites
CommonCryptoLib: SNC protocol versions and cipher suites
CommonCryptoLib: Manage PSE files and SSO Credentials (cred_v2)
CommonCryptoLib: Certificate Revocation List validation

 

Updates:

CCL integration

Whenever cryptography for SNC is needed the SAP kernel addresses a cryptographic library through the BC-SNC interface which is based on the GSS-API v2 interface. As already stated typically the CommonCryptoLib is used as cryptographic library, but there may also be implementations out there, for example, using the wrapper libraries for kerberos from SAP. Namely, gsskrb5.dll, gI64krb5.dll, and gx64krb5.dll.

For SAP ABAP and Java the to-be-used library is configured by the profile parameter snc/gssapi_lib.
For SAP JCo this is configured in the SAP SNC property or destination file in the parameter jco.client.snc_lib or in the environment variable SNC_LIB or SNC_LIB_64 (SAP Note 2642538 provides a good how-to).
For SAP NCo this is configured in the destination in the parameter SNC_LIB or in the environment variable SNC_LIB or SNC_LIB_64.
Others may integrate the CCL by other means, for example,by reading the path to the library from the environment variables SAPCRYPTOLIB, SNC_LIB, SNC_LIB_32, SNC_LIB_64, SNC_LIB_2, or SNC_LIB_64_2.

While using the CCL in default configuration serves maximum compatibility, it offers weak security and therefore should no longer be used nowadays.

During the SNC handshake the server and the client are negotiating the SNC protocol version and the cipher suites. Each side typically support more than one cipher suite to offer higher compatibility. Each party asks for acknowledgement on the SNC version and the cipher suites in a given order until they come to an agreement. If no matching SNC version or cipher suite could be negotiated the handshake will fail.

Protocol versions

The SNC protocol evolved over the years and today there are three versions out there:

1993, 2010_1_0, and 2010_1_1.

Cipher suites

Similar as we know it from TLS also SNC makes use of cipher suites which define a set of algorithms that usually contain a key exchange algorithm, a Signature, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

Not every cipher suite can be combined with every SNC protocol version. Run the command sapgenpse sncinfo -v ALL to display a mapping:

 

How to securely configure the protocols and cipher suites supported by the CCL?

Where to set the CCL parameters?

For SAP systems to make sure all application servers / nodes use the same configuration the CCL  parameters should be added to the DEFAULT.PFL. And the environment variable CCL_PROFILE should point to the same.

Please note: You may have recognized that i used the term “CCL parameter”. This is due to even if these parameter look like SAP Kernel parameters, they are not known by the SAP Kernel. Maintaining those parameters using RZ11 is not possible, but with the environment variable mentioned above they can be maintained in RZ10 in the DEFAULT.PFL and as soon as the changes are activated, meaning are written to the file system, the CCL takes advantage of the new settings.

 

Protocol Configuration

The following CCL parameters allow to configure the supported SNC protocol versions:

The protocols 1993 and 2010_1_0 can be considered as weak (at most because they do not support strong cipher suites) and should no longer be used. Today, only the version 2010_1_1 should be offered, which can be achieved with the CCL parameters

When acting as server: ccl/snc/server_protocol = 2010_1_1
When acting as client: ccl/snc/client_protocol = 2010_1_1

Cipher Suite Configuration

The CommonCryptoLib assigns sets of SNC cipher suites to classes. The available classes can be displayed using sapgenpse by issuing the command
sapgenpse sncinfo -H

These classes are defined by SAP. At time of writing the following classes exist:
“HIGH”: High security cipher suites (except PFS)
“MEDIUM”: Medium security cipher suites

As these classes are defined by SAP they do not underlay a common understanding. From time to time SAP makes adjustments to these classes and communicate this via SAP note 2004653 (it is worth to subscribe to this note to keep track about changes). Almost all recommendations out there relay on these classes. Nevertheless, they do not provide control about the supported cipher suites to a full extent as it is desired in a high security area.

Knowing this, the to-be-offered cipher suites should be configured directly. Only cipher suites providing perfect forward secrecy (PFS) should be offered, which can be achieved with the CCL parameters

When acting as server: ccl/snc/server_protocol = SNC_ECDHE_P256_AES256_SHA256:SNC_ECDHE_P384_AES256_SHA512:SNC_ECDHE_P521_AES256_SHA512
When acting as client: ccl/snc/client_protocol = SNC_ECDHE_P256_AES256_SHA256:SNC_ECDHE_P384_AES256_SHA512:SNC_ECDHE_P521_AES256_SHA512

Signature Algorithms Configuration

When using X.509 certificates for the authentication in an SNC handshake, the server is signing the handshake. When using an ECDHE cipher suite (PFS) also the client is using a signature algorithm for the authentication.

For this, we do not want to allow weak signature algorithms like  SHA1_DSA, SHA224_DSA, PKCS_BT_01_SHA1_RSA or PKCS_BT_01_RIPEMD160_RSA to be used. This considerations will result in the CCL parameters

When acting as server: ccl/snc/server_accepted_signature_algorithms = SHA256_DSA:PKCS_BT_01_SHA256_RSA:PKCS_BT_01_SHA512_RSA:SHA256_ECDSA:SHA512_ECDSA:SHA384_ECDSA
When acting as client: ccl/snc/client_accepted_signature_algorithms = SHA256_DSA:PKCS_BT_01_SHA256_RSA:PKCS_BT_01_SHA512_RSA:SHA256_ECDSA:SHA512_ECDSA:SHA384_ECDSA

Server Session Key Mode

For authentications in SNC between an end user system (SAP Secure Login Client, SLC) and an AS ABAP the server session key mode is available.
When server session key mode is activated the client generates and signs a temporary key which is used for authentication in multiple sessions.
This can be enabled by CCL parameter ccl/snc/server_session_key_mode .

Server Session Key Types

For the temporary key in server session key mode, the key types accepted by the server can be specified.
The key type RSA_1024 must be considered as weak and should no longer be offered, which can be achieved with the CCL parameter

ccl/snc/server_session_key_types = ECDSA_P256:ECDSA_P384:ECDSA_P521

Server Session Authentication Mode

For authentications in SNC between an end user system and an AS ABAP the encryption only mode is available and can be configured in profile parameter ccl/snc/server_partner_auth_mode.

Set value 2 to enforce SSO or to 1 if the emergency mode of SAP Secure Login Client (SLC) shall be supported which allows password based logon over an encrypted communication channel.

 


<–Previous

Next –>

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Claire Beaubaton
      Claire Beaubaton

      Thank you very much Johannes for these amazing articles about CommonCryptoLib

      I have a general question regarding CommonCryptoLib.

      Recently there is a security issue and we need to check if we have >=8.5.39 on our Unix servers.(More info 3051787)

      CommonCryptoLib is used in SAP Host Agent, SAP HANA Server & Client, SAP XSA, SAP Webdispatcher, SAP ABAP, SAP JAVA, Content Server, SSO and i would like to know if you have a quick method to identify quickly the version of CommonCryptoLib on my server for all the possible paths ?

      I have tried :

      sapgenpse cryptinfo | grep '^VERSION'

      sapgenpse cryptinfo | grep '^BINARY-FILE'
      find / -name 'libsapcrypto.so' | xargs strings | grep '^CommonCryptoLib 8'
      strings /hana/shared/HDB/global/hdb/saphostagent_setup/libsapcrypto.so | grep '^CommonCryptoLib 8' | sort -r |tail -1
      Any ideas to retrieve quickly the path and the version of SAP CommonCryptoLib ?
      Thank you
      Author's profile photo Johannes Goerlich
      Johannes Goerlich
      Blog Post Author

      Hello Claire,

      thanks for your comment!

      Sadly imho there is no quick solution for determining all CCL versions in a landscape (including interface partner systems).

      Please remember sapgenpse will use the crypto lib which is defined in the environment variable SNC_LIB of the current user or the one which is stored in the same directory as sapgenpse itself if env is not set. sapgenpse shows the lib used by the current user, so you have to run it at least as <sid>adm and sapadm.

      For ABAP you can find the CCL Version also in the CCDB config store CRYPTOLIB of SolMan or FRUN.

      For SAP HANA database & XSA the CCL cannot be patched individually. Therefore, it should be sufficient to check the revision or patch level.

      btw. for security reasons, there is no possibility to log or trace for incoming connections which CCL version is used by an interface partner system.

      BR,

      Joe