Technical Articles
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:
2022-03-28: Adjusted settings for ccl/snc/client_protocol
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.
When acting as server
Knowing this, the to-be-offered cipher suites should be configured directly. The available cipher suites can be displayed using sapgenpse by issuing the command
sapgenpse sncinfo -v ALL
Only cipher suites providing perfect forward secrecy (PFS) should be offered, which can be achieved with the CCL parameter ccl/snc/server_cipher_suites = SNC_ECDHE_P256_AES256_SHA256:SNC_ECDHE_P384_AES256_SHA512:SNC_ECDHE_P521_AES256_SHA512
When acting as client
The CCL does not support to configure individual cipher suites when acting as client. There it is only supported to adjust the classes. The cipher suites assigned to class MEDIUM can be displayed using sapgenpse by issuing the command sapgenpse sncinfo -cv MEDIUM
, the ones assigned to HIGH by issuing sapgenpse sncinfo -cv HIGH
.
When acting as client only cipher suites of class HIGH should be supported, by setting the CCL parameter ccl/snc/client_cipher_suites = HIGH
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.
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
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 assapgenpse
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
Hello,
first of all, thanks for the compendium. Didn't know about this until now.
I guess there is a mistake in the parameter names. In section Cipher Suite Configuration you are using the protocol parameters and not the ccl/snc/server_cipher_suites and ccl/snc/client_cipher_suites.
Kind regards...
Thanks for pointing me to that. Seems this got messed up during the last update. I've just corrected this now.
BR,
Joe