Search
Close this search box.
Jobs

Why is it so important to use up-to-date SAP security libraries?

Success Story Carsten Olt

The SAP system architecture uses security libraries that enable encryption, advanced authentication mechanisms or digital signatures in SAP applications. In the past, the ABAP kernel shipped with the SAP Cryptographic Library (SAPCRYPTOLIB) as the default security product for SAP systems. It supports the use of digital signatures according to the Secure Store and Forward (SSF) interface and provides encryption functions such as Secure Network Communications (SNC) or Transport Layer Security (TLS) for the different SAP Application Servers. Besides SNC, SSF and TLS the SAP ABAP Application Server also supports the web-based implementation of the Kerberos authentication, the so-called Simple and Protected GSSAPI Negotiation Mechanism, or SPNEGO. 

One library for all scenarios

Since the end of 2013 SAP provides the CommonCryptoLib as the technical successor and replacement for the SAP Cryptographic Library. The CommonCryptoLib is part of the kernel of SAP NetWeaver Application Servers. Beginning with Kernel 7.20 PL88, no particular kernel patch is required to use CommonCryptoLib. The library is fully compatible with SAPCRYPTOLIB and SAPSECULIB. This single security library combines and merges all predecessors. It not only supports all scenarios from previous security libraries but offers additional features, well described in SAP Note 1848999.  SAP updates this Note frequently to provide an excellent feature overview, troubleshooting tips as well as a version history – so check it out! Having to maintain only a single security library, makes life easier for SAP administrators. Furthermore, SAP HANA uses the CommonCryptoLib for cryptographic operations, such as data volume encryption and communication encryption. Additionally, the SAP NetWeaver Application Server Java uses it for cryptographic functions like secure communication via TLS or SNC for RFC server-to-server connections.

Perfect Forward Secrecy for SNC

Thanks to the end-to-end encryption capabilities of SNC, DIAG and RFC connections can be used over unsecured networks. To establish an SNC session, a calculated Pre-Master Secret is encrypted with the corresponding public key of the other party. So, both sides send their “Hello” exchange public keys and agree on a shared session key (Master Secret) as part of the connection handshake, protected using public-key cryptography. Sounds good so far, right?

The problem is that if someone recorded the encrypted traffic and later eventually got possession of the private key, they would be able to extract the session key from it. Because the Pre-Master Secret is encrypted with the server’s public key, exposure of the private key would allow decryption of the data at any point in the future. The ability to decrypt historic data is considered a serious security issue. Just think about the global intelligence community that records Internet traffic on a large scale or the disgruntled network operator who has access to the all network traffic.

That is where Perfect Forward Secrecy (PFS) is helpful, as it mitigates this type of attack vector.  PFS was already implemented in CommonCryptoLib for HTTPS connections since it supports version 1.2 of the Transport Layer Security (TLS) protocol. Using TLS, the Diffie-Hellman key exchange is done using Elliptic Curves Cryptography (ECDH) which results in Perfect Forward Secrecy for SAP-SNC connections, providing a cryptographic solution to solve the problem of secure key exchange.

What’s the idea behind the solution?

It is based on the notion that two communication partners agree on a common key in the form of a number, which a potential attacker cannot use to calculate the symmetric session key. You can learn more about the mathematics behind PFC in this article. The key takeaway is that there is no exchange of encrypted session keys anymore. The session key is uniquely calculated for each new communication and destroyed immediately upon termination. Thus, even if someone had access to the private keys of the participants and recorded the session, the session key was not included in the initial communication between both sides.

Starting with CommonCryptoLib 8.5.2 and higher and due to an extension of the X.509-based GSS protocol, the SNC connection should be much safer now, thanks to PFS.

Besides PFS there are other improvements to the CommonCryptoLib which I would like to mention briefly, such as the new X.509 based Encryption Only Mode (check out our previous blog for more information) or a revised TLS engine with support for TLS_FALLBACK_SCSV. Also, low-security cipher suites have been removed, and several new configuration parameters were added to configure the library. In addition to that, a new FIPS 140-2 certified cryptographic kernel can be used.

In October 2014 SAP released the security note 2067859 concerning the SAPCRYPTOLIB which addressed an issue in the DSA implementation. The vulnerability allowed an attacker to compromise the private key of the SAP system. As you see, it is important to keep your SAP Security Libraries up to date and to check for security improvements as well as updates regularly. By the way, have a look at the version of your libraries. SAP just released CommonCryptoLib 8.5.9, and there was a lot of corrections and bug fixes since 8.5.1 – so happy updating!

Carsten Olt
Latest posts by Carsten Olt (see all)
Contact

Get in touch with us!

Do you have questions about our products?

+41 43 422 8803
[email protected]
+49 7656 8999 002
[email protected]
+1 855 594 84 64
[email protected]
+44 1454 838 785
[email protected]
Contact
Webinars

Attend our live webinars and learn more from our experts about SAP authorizations, XAMS, SAP IDM and many other topics in the context of SAP security.

Register now