
Many years ago SAP deprecated the SAPCRYPTOLIB 5.5 (which replaced the SAPSECULIB 5.4) and introduced the CommonCryptoLib (CCL) as its successor. The CCL is not only a replacement for its predecessor but also for the gsskrb5.dll, gI64krb5.dll, and gx64krb5.dll, which may still be used as Microsoft Kerberos Security Service Provider (SAP Note 352295) and for the gssntlm.dll, gI64ntlm.dll, and gx64ntlm.dll, which are - hopefully no longer- used as Microsoft NTLM Security Service Provider, as NTLM must be considered as broken (Pass the Hash (PtH) Attack).
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 JCo), SAP .Net Connector (SAP NCo), the RFC DSK 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
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.
The SNC protocol evolved over the years and today there are three versions out there:
1993, 2010_1_0, and 2010_1_1.
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:
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.
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
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. 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.
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 also only cipher suites providing perfect forward secrecy (PFS) should be supported, by setting the CCL parameter ccl/snc/client_cipher_suites =SNC_ECDHE_P256_AES256_SHA256:SNC_ECDHE_P384_AES256_SHA512:SNC_ECDHE_P521_AES256_SHA512.
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
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 .
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
7 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 |