Administration

SAP Cloud Platform Security: Basic Cryptography

Whether you’re granting object privileges within SAP HANA or destroying data with SAP ILM, it’s important to keep your SAP solutions secure and out of trouble. SAP Cloud Platform security is no different. In this blog post, take a look at how you can utilize cryptography to keep data from falling into the wrong hands.

 

What is Cryptography?

Cryptography, in the broadest sense, deals with methods and techniques that help protect data against unauthorized access. One basic measure of protecting data against unauthorized access is to encrypt it. Encrypting means to transform a clear text (which is readable by everyone) into a secret text, prior to sending it to a communication partner.

 

This transformation is done on the sender side by a mathematical operation (based on an encryption key). The dedicated receiver needs to know the inverse operation (the decryption key) to transform the secret text back into the clear text.

 

Another measure to protect a message on its way between a sender and receiver is to apply a digital signature so that the receiver can be sure that the message has been sent by the trusted sender (this is also known as data integrity).

 

The simplest and most obvious approach (which is also referred to as symmetric key technology) is that sender and receiver use the same key, and a critical requirement to ensure a seamless and protected communication of sender and receiver is that the key is securely exchanged between both parties prior to the actual data exchange.

 

It’s obvious that this requirement can’t be met in the digital age, as the number of potential communication partners and communication paths for a given channel (e.g., email) is on a large scale and dynamically changes in the short term.

 

To overcome this challenge, asymmetric (or public) key technologies have been developed, which always require two different key types: a public key and a private (or secret) key. Both key types are generated together and are related to each other based on a mathematical operation such that the public key can be easily calculated from the private key.

 

However, it’s impossible to perform the reverse operation and derive the private key from the public key (at least, when considering computing capacities available today). Mathematically, this approach is based on one-way functions. For more information on this, refer to Cryptography and Public Key Infrastructure on the Internet (Wiley, 2003).

 

For the encryption use case, the asymmetric approach works in the following way: the intended receiver of a message generates a public-private key pair and shares the public key with the sender. The sender then uses the public key to encrypt the message. The receiver then uses its private key (which is always kept with the receiver and never shared with any other party) to decrypt the message.

 

For digital signatures, the inverse pattern is applied. The sender signs a message using its private key (which is always kept with the sender) and the receiver (and many other potential receivers) can verify the signature by using the public key, which they have been provided with by the sender.

 

The private key must never be shared with anyone else obviously, or it would allow others to sign messages in your name or to decrypt content that is destined solely for you.

 

Because of the inherent mathematical concepts (one-way functions), public keys, on the other hand, can potentially be shared through unsecure channels (e.g., email). Any malicious party who receives the public key by mistake has no opportunity to decrypt or sign any message with it. Note, however, that certain additional measures should be undertaken to enable the receiver of a public key to validate the authenticity of the same.

 

Hybrid Cryptography Approaches

Symmetric methods typically use simple bit operations to transform a clear text bit sequence into a secret text bit sequence. In asymmetric methods, however, sophisticated mathematical operations come into play (which use modulo mathematics). Because of this, asymmetric methods are computationally intensive and, therefore, not well-suited to operate on larger bit sequences that come along with large business messages exchanged in integration scenarios.

 

To overcome this issue, it’s more feasible to apply hybrid approaches, which combine asymmetric and symmetric methods. In encryption scenarios, the most common pattern is as shown in the first figure.

 

The sender encrypts the (potentially large-volume) content of a message using a symmetric encryption key. Thereafter, the sender encrypts the symmetric encryption key with a public key and sends the encrypted symmetric key (along with the encrypted message content) to the receiver.

 

Before the message exchange between sender and receiver has been initiated, the public key has been generated by the receiver as part of an asymmetric key pair and shared with the sender without risk. With the associated private key, the receiver, as soon as he has received the encrypted symmetric key (and the encrypted message content), decrypts it and, finally, uses the revealed secret key to decrypt the message content.

 

This way, we avoid applying asymmetric key operations to the whole message content.

Hybrid approaches are applied in the transport-level security option TLS as well as in certain message-level security options.

 

Sender and Receiver

Keystores

To introduce another important term, note that keys (public and private keys) are stored in keystores owned by the involved parties. How a keystore is implemented and its characteristics depend on the type of system that implements the services of the sender and receiver.

 

The following figure illustrates the setup of components for two parties exchanging encrypted messages based on public key technology. In the shown general setup, sender and receiver separately generate their own public-private key pair and import it into their keystore.

 

Keystores Overview

 

In a subsequent step, both participants share the corresponding public key with the communication partner. Both partners also import the corresponding foreign public key into their keystores.

Keystore Types for SAP Cloud Platform Integration

When the tenant is one communication partner, a keystore needs to be deployed on the tenant that contains the required key material. The characteristics of the keystore also depend on the chosen security standard.

 

To give an example, when you use X.509 certificates, you utilize a Java keystore, whereas when you use OpenPGP, you’ll need two different “keystore” types: a PGP Public Keyring and a PGP Secret Keyring.

 

To give an example for a remote system that can be connected to a tenant: if it’s an SAP system based on Application Server ABAP (AS ABAP), the required keys are maintained with the Trust Manager in the Personal Security Environment, which takes over the role as the keystore.

 

Although public keys can potentially be exchanged on unsecure channels (whereas private keys must never be shared with another party), a malicious party can nevertheless misuse this fact and send a public key to another party, pretending to be the owner of the public key. So, the question is, how can the authenticity of a public key be guaranteed to further increase security?

 

To answer this, we’ll briefly discuss digital certificates.

Digital Certificate

A digital certificate is a public key that is signed by a trusted authority (usually referred to as a certification authority (CA). This way, the identity and trustworthiness of the public key owner can be confirmed. Taken in short, a certificate couples an identity with a public key.

 

There are many options to build trust based on certificates. One example is the X.509 standard, which comes into play, for example, when two communication partners protect their communication channel using TLS. X.509 supports the usage of PKIX-certificates (Public Key Infrastructure X.509) that allow you to build up certificate chains. These are hierarchical trust models, which include many CAs on different levels, where the CA on the higher level signs the certificate of the correspondingly lower level, and so forth. The CA on the top level is referred to as the root CA. This model is called a certificate chain.

 

An example of a CA is GeoTrust (www.geotrust.com). One root certificate issued by GeoTrust and supported by the load balancer is GeoTrust Global CA.

 

Another, alternative trust model is the Web of Trust. In such a model, communication partners mutually confirm the authenticity of each other’s public keys, building a network of partners rather than a hierarchical structure.

 

The Web of Trust model can be used in conjunction with the security standard OpenPGP. The final figure shows the difference between the two trust models.

 

Certificate Chain and Web of Trust

X.509 Certificates

As this certificate type is the most commonly used for transport-level security, we would like to discuss a few basic concepts and terms. X.509 certificates allow you to implement trust models based on certificate chains. A set of elements is required to specify a X.509 certificate, although we won’t go into detail about that in this post.

 

We only want to point out the Issuer and the Subject field, which are required to understand the following:

  • Issuer: Specifies the CA (that issued and signed the certificate).
  • Subject: Specifies the entity that is associated with the public key of the certificate. If the certificate is used to authenticate a client calling a server, the subject usually identifies the client.

Both entries, Issuer and Subject, are uniquely defined by a distinguished name (DN), which is composed of a set of attributes such as company name, country identification, and so on. The format of DNs is defined by the specification RFC 5280 (see https://tools.ietf.org/html/rfc5280). That way, DNs are guaranteed to be unique, and using them ensures that, first, the certificate issuer can uniquely be identified (to make sure the certificate isn’t tampered with information from a malicious party) and, second, the entity associated with the certificate certainly can considered to be the one it’s intended to be.

 

Conclusion

SAP Cloud Platform security should be an important part of your system administration landscape. By using ideas such as cryptography to safeguard data, you can feel more confident that your system isn’t prone to unauthorized access.

 

Or course, this blog post is meant as a primer to cryptography—an idea that should be part of a more robust SAP Cloud Platform security strategy. The information above should give you a decent idea on what options are available to you, however. Now go forth and work on securing your systems!

 

Editor’s note: This post has been adapted from a section of the book SAP Cloud Platform Integration: The Comprehensive Guide by John Mutumba Bilay, Peter Gutsche, Mandy Krimmel, and Volker Stiehl.

Recommendation

SAP Cloud Platform Integration: The Comprehensive Guide
SAP Cloud Platform Integration: The Comprehensive Guide

Bring your cloud and on-premise applications together with SAP Cloud Integration (formerly SAP Cloud Platform Integration) in the SAP Integration Suite! Integrate processes and data in your system, step-by-step, by developing and configuring integration flows in Cloud Foundry and Neo environments. Enhance your integrations with APIs, open connectors, and custom adapters. Explore prepackaged content in the content catalog, debug and secure integration projects, enable B2B integration, and more!

Learn More
SAP PRESS
by SAP PRESS

SAP PRESS is the world's leading SAP publisher, with books on ABAP, SAP S/4HANA, SAP CX, intelligent technologies, SAP Business Technology Platform, and more!

Comments