This series of posts will look at common customer configurations when implementing network communication security in the HANA Cloud Integration (HCI) platform. When beginning its best to consider the different scenarios and the frames of reference around terms so that we are clear about the different directions messages will be flowing in.
This paper will focus around security protocols in general as well as security landscapes for the on premise installation and the HANA Cloud Infrastructure, specifically around the implementation of Basic and Certificate authentication for messages being transferred to and from the HCI Tenant and the Customer Installation since this is often the most complex portion of the environment to setup.
Customer Installation:
Refers to an ERP system running Process Integration or Process Orchestration but it is not restricted to this, it could just as easily be a third party landscape sending messages to HCI.
HCI Tenant:
This is the installation that is running on the HANA cloud platform and is subscription licensed by SAP who provide the infrastructure to companies and partners. This will be referred to as the HCI Tenant. Each customer will have one or more tenants.
Inbound Messages:
These are the messages that are being received by the specified server. It will be clear in the documentation which server (HCI Tenant or Customer Installation) is being referred to.
Outbound Messages
These are the messages that are being delivered by the specified server. It will be clear in the documentation which server (HCI Tenant or Customer Installation) is being referred to.
Certificates and Public Key Infrastructure
Fundamental to secure communication on the Internet is the use of public key cryptography (PKI).
Wikipedia defines PKI as:
"A public key infrastructure (PKI) is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates[1] and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, Internet banking and confidential email.”
PKI manages certificates and the SSL/TLS protocol for infrastructure. The certificates use the X.509 standard for identity management and when used properly can verify the identity of the server and the client. Though SSL has been replaced by the newer and stronger Transport Layer Security (TLS), the name SSL is still used though the protocol has been retired. Throughout this paper there will be references to SSL, however this will be synonymous with Transport Layer Security.
SSL is based on a hierarchical model of trust where Certificate Authorities (CA’s), are the very fundamental entities on which both parties involved in a SSL communication must know and trust. If any of them does not know about them or does not trust them, SSL will not work since basically they cannot build trust on what a client or a server are claiming to be.
Certificates by themselves are much like business cards in that they provide a means of identity but do not prove the owner of the certificate is who they say they are. The actual encryption stage is done later when establishing a secure connection by asking the server to encrypt some data and see if the data supplied can be correctly decrypted using the supplied server certificate. Since only the owner of the private key can decrypt data that has been encrypted using the public key held in the certificate, this proves the server is the owner of the certificate and can be trusted. If the data is not decrypted correctly, then the server does not possess the correct private key and so is not the owner of the certificate.
The top of the certificate tree is referred to as the Root Certificate and is issued by the Root Certificate Authority or the Root CA. A Root CA may issue special certificates that allow other parties to issue certificates but are trusted by the root CA. These are called intermediate certificates and are issued by an Intermediate Certificate Authority (CA). The client certificate will have path from its intermediate CA's (if there is one) to the Root CA. This means that the Root CA and any intermediate CA certificates will need to be present in the browser but the Root CA is the only certificate that is implicitly trusted.
The terms Root Certificate and Client Certificate will be used throughout this document so it is important they are well understood. The root certificate is the one everyone trusts and is normally shipped with the browser. The intermediate certificates are trusted only because their trust is guaranteed by the root certificate. Finally, the client certificate which is your certificate is the one used in your communications to prove your identity.
Mathematically speaking that trust is computed as a public/private key pair digital signature bound to the SSL certificate.
No matter which tool you use, the process of generating SSL certificate is fundamentally as follows:
- The customer generates a private and public key pair according to the rules of a given encryption algorithm and with a given size of bits. That key pair consists of a public and a private key and will make up the two fundamental pieces of the final SSL certificate.
- The customer also establishes a subject for the certificate. This will assign an identity to the certificate and is the identity the CA is agreeing to certify. The subject will be a Distinguished Name (DN) and this name is guaranteed to be unique. The format of the name is required to be compliant with RFC 5280:4.1.2.6 and looks similar to the following example:
E=some.one@sap.com,CN=i00000,OU=SAP Trust Centre,O=SAP AG,L=Walldorf,ST=BW,C=DE
Here we have attributes for the Entity (E), the email name (CN) the organizational unit (OU), the organization (O), the location (L), the state (ST) and the country (C).
- The public key along with the name of the owner who is requesting the signing is sent as a signing request to the CAs in the form of the PKCS#10 Certificate Signing Request (CSR).
- The CA validates the information received and signs the CSR request as an act of trust on the given subject (typically this is the distinguished name of the CSR). The signed CSR eventually becomes the digital signed certificate that is returned back to the owner
- The private key and the signed certificate are installed on the server providing SSL services to connecting applications or to servers requesting the caller provide proof of their identity. The certificate (which contains the DN and public key, signed by the CA) can be made public to whoever requests it. Once the owner receives and installs that signed digital certificate, the owner will have a fully functional SSL certificate ready to be deployed on the HTTP server.
This process of verifying the certificate is known as the server authentication. Note that same process can be also applied in reverse if required which is known as client authentication or if both the server and the client request a certificate exchange then this is termed mutual authentication. If the certificate exchange process seems familiar, it is the basis for Single Sign-on!
To complete the PKI overview lets look at what happens when a client connects to the HTTP server via the SSL port. This will initiate a defined sequence to ensure the server is who they claim to be and to provide a secure means of negotiating a shared secret to encrypt the stream.
- The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported cipher suites (ciphers and hash functions).
- From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision.
- The server usually then sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key.
- The client may contact the server that issued the certificate (the trusted CA as above) and confirm the validity of the certificate before proceeding. Other checks are also performed to ensure the certificate is genuine such as the domain name matching the domain name in the certificate and that the certificate has not been revoked, has not been expired and the date is not before the issue date.
- In order to generate the session keys used for the secure connection, the client either:
a) Encrypts a random number with the server's public key and sends the result to the server (which only the server should be able to decrypt with its private key); both parties then using the random number to generate a unique session key for subsequent encryption and decryption of data during the session
b) uses Diffie-Hellman key exchange to securely generate a random and unique session key for encryption and decryption that has the additional property of forward secrecy: if the server's private key is disclosed in future, it cannot be used to decrypt the current session, even if the session is intercepted and recorded by a third party. - This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the session key until the connection closes. If any one of the above steps fail, the TLS handshake fails, and the connection is not created.
In the next posting we will look at some of the typical operations needed to manage security within the HCI environment.
