GRC
HR
SCM
CRM
BI


Article

 

What the Public-Key Infrastructure (PKI) Can Do for You and Your SAP Systems

by Dr. Jürgen Schneider | SAPinsider

April 1, 2002

by Dr. Jürgen Schneider, SAP AG SAPinsider - 2002 (Volume 3), April (Issue 2)
 

Privacy of communications, strong user authentication, data authenticity and integrity, and ultimately, the best possible protection for your business systems and applications — these have always been the central goals of security architects. A little more than 20 years ago, public-key technology promised to be the solution to elegantly achieve these goals.

Since then, you have probably heard conflicting views about whether public-key technology has fulfilled its promise. In fact, these high expectations were set and held up by vendors of public-key infrastructure (PKI) products who positioned this technology as the “be all and end all” solution to security, which it isn’t — and never was. However, while PKI was often oversold, it shouldn’t be overlooked entirely. In fact, for some critical security tasks, public-key technology is a very good solution. So when should you use it to your benefit in an SAP system?

For administrative staff and IT management responsible for the security in an SAP landscape, this article provides a snapshot of how PKI can be used to enhance the security of SAP systems. This overview will give you a good sense of areas where public-key technology already plays an important part in your SAP system, such as secure communications and trust management. It also offers a preview of the areas where PKI might be one option for future improvements, such as single sign-on and secure messaging.

Use of Public-Key Technology with SAP Technology

In an SAP system, including the newest in mySAP Technology such as the SAP Web Application Server and the SAP portal and exchange infrastructure, public-key technology is provided as an option for:

  • Establishment of secure communications
  • Strong authentication of servers and clients (users)
  • Support for digital signatures and document encryption

Secure Communications and Server Authentication


When different servers set up secure communication connections between each other (server-to-server connections), they first need to be sure about their identities (mutual authentication). The same applies to clients (client-server connections) that want to be sure to connect to authentic servers (server authentication). To achieve strong authentication with SAP servers, they need to be equipped with public-private key pairs and their digital certificates, as illustrated in Figure 1.

Figure 1 Server Authentication and Secure Communications

The use of public-key cryptography is an option provided for all servers with mySAP Technology to strengthen the default server authentication mechanism based on the IP address of the server only. Public-key technology in SAP supports:

SAP GUI and RFC Connections
For the classical SAP protocols DIAG (for GUI connections) and RFC (SAP Remote Function Call), SAP supports the use of public-key technology over the Generic Security Services (GSS) API Version 2, standardized by IETF (Internet Engineering Task Force).

Web-Based Communications
For web-based communications, public-key cryptography is standard Internet technology with the Secure Sockets Layer (SSL) protocol provided by all commercial web servers today, including the SAP Web Application Server 6.10. The SSL protocol is used for web communications via HTTPS, the secure variant of HTTP.1

SAP customers can download an implementation of the GSS API and SSL using public-key technology from the SAP Cryptographic Library (SAPCRYTOLIB) on the SAP Service Marketplace (http://service.sap.com/ocs-download).

With public-key technology, server authentication is carried out using a cryptographic authentication protocol, which includes challenge-and-response messages where the server’s public key is used to securely exchange a fresh symmetric session key. For each connection, the connection initiator generates a new symmetric session key and encrypts it using the connection acceptor’s public key. Only the intended connection acceptor (server) is able to retrieve the encrypted session key using its private key and is then able to receive and send data encrypted with the session key.

What Is Public-Key Technology?

Traditionally, when trying to protect the confidentiality of data via encryption, we would think of a cryptographic algorithm and a secret key, which is used to transform the data to be protected into non-readable bit patterns. To decrypt and retrieve the data, the authorized recipients need to have access to the same secret key used for encrypting the data. This is called symmetric encryption, and there are a number of well-known algorithms providing strong protection2 of the encrypted data when using key lengths of 128 bits or more.

However, there are basically two major problems with symmetric encryption:

  1. Given a large number of different groups of senders and recipients of encrypted data, secure distribution of secret keys is a major practical challenge.

  2. Since secret keys are known both by the senders and recipients, they cannot be used to unambiguously prove the identity of the respective sender or recipient.

Public-key technology was invented to overcome both problems. Instead of a single, secret key, a pair of keys is used: a private key and a public key. The private key remains secret and is only known to its owner. The public key can be distributed and passed to others without affecting the secrecy of the private key or the protection of encrypted data.

Let’s consider a scenario where two users, Mary and John, need to share some data. In a secure system using public-key technology, Mary uses John’s public key to encrypt the data, and also uses her private key to digitally sign the data.3 When he receives it, John can use his private key to decrypt the data and retrieve the original message. Likewise, he can verify the authenticity and integrity of the digitally signed message by using Mary’s public key. In this way, public-key systems can be used to protect the confidentiality of data via encryption, as well as to prove the identity of the sender and the authenticity of the message.4

Obviously, it is of utmost importance that public keys are authentic. This is where trust centers come into the picture. When public keys are distributed over untrusted communication channels, both senders and recipients rely on a correct “binding” between a public key and its owner. Such bindings are confirmed by a trust center, which puts its own digital signature under the combined information about the key value and the owner’s identity. The result is a digital certificate.5

For security reasons, digital certificates are only valid for a certain period of time (usually one or two years). They can also be revoked by the issuing trust center before expiration. To verify the validity of digital certificates, only the trust center’s public key (and the trust center’s revocation list) is needed.

Client (User) Authentication

Both the SSL protocol and GSS API, as used by mySAP Technology, provide an alternative to using passwords or other authentication methods. With the option of mutual authentication for both the server and the client, not only can the client be sure about the server’s identity, but the server also learns about the client’s identity as part of the cryptographic authentication protocol. Here, clients can be other servers that are initiating secure connections, or they can be graphical user interface programs, such as web browsers or the SAP GUI, that are sending requests or setting up dialog connections on behalf of a user. In the latter case, the client identity actually is the user’s identity.

In fact, enrolling your users with digital certificates — whether they are software certificates with private keys and certificates stored on the user’s workstation or in a central directory, or private keys and certificates stored on hardware tokens, like smartcards — actually represents an interesting and highly secure option for user authentication and single sign-on.6

In order to authenticate users via public-key technology (instead of using passwords, for example), users need access to their own public-private key pair and digital certificate. In addition, the user interface software must support the use of this technology for connection setup and authentication, which is provided by commercial web browsers over the SSL protocol and by the SAP GUI with GSS API.

Admittedly, one might argue about the level of support available today when it comes to user-friendliness and configuration. However, when hardware tokens are used to store the user’s private key protected by a Personal Identification Number (PIN), this is probably the most secure authentication method available today for your users.7

Digital Signatures

As explained before, public-key technology can be used to create and verify digital signatures. This mechanism can be used at both the system level (to secure internal and cross-system operations) and the business level (to secure business documents such as orders, invoices, and payments).

Digital Signatures for System Security
At the system level, this mechanism is used with mySAP Technology. For example, the SAP Logon Ticket (which is issued as a single sign-on token after logon to the SAP Enterprise Portal or to the SAP Web Application Server as well as in the SAP exchange infrastructure) is digitally signed by the issuing system. The digital signature protects the authenticity and integrity of the ticket so that it cannot be tampered with. When other systems join the SAP single sign-on environment, they verify the digital signature of the issuing system when they receive tickets and check whether the ticket issuer is allowed to create single sign-on tickets for the receiving system.

Ticket-issuing systems can obtain digital certificates from SAP’s own trust center using the SAP Service Marketplace. In this case, the SAP Trust Center’s public key, which is required for certificate and signature verification, is already contained in the SAP Logon Ticket verification library.

Digital Signatures for Secure Business Documents
At the business level, documents such as orders, invoices, or payments can be digitally signed by the sending system. The receiving system can confirm the digital signature to verify the authenticity and integrity of the document and the identity of the sender. In addition, the receiving system can also store the document together with the digital signature and keep it for evidence (in case of dispute, for example).

As yet, there is no widespread use of this mechanism, but it is envisaged to be introduced with the SAP exchange infrastructure in the future, based on the XML Signature standard defined by the W3C (World Wide Web Consortium).

Digital Signatures for User Authentication
Whenever an SAP system creates digital signatures, it uses a public-private key pair and digital certificate generated and configured for signatures. Users do not have direct access to the system signature keys, but may have their own signature key-pair and certificate in a PKI. In such a scenario, it is possible to let the individual users sign business documents, even over the web. Users can be asked to authorize workflows and confirm orders or payments, and their digital signatures for these actions can be stored as evidence by the receiving systems.

User signatures are already provided with mySAP Technology, as part of the SAP GUI for Windows, and are used, for example, in the mySAP Pharmaceuticals industry solution to authorize production steps for medicines. Although user digital signatures over the web are not yet included in SAP standard applications, they are possible with mySAP Technology and are about to become reality in future applications.

Document Encryption

Not only can business documents be authenticated using public-key technology, they can also be encrypted. This preserves their confidentiality even when they are stored in intermediate message hubs or databases.

Secure electronic mail according to the S/MIME standard is an example where encryption technology is used today, but it requires an internal company, or even cross-company and global, PKI. The W3C is currently working on the XML Encryption standard, which will introduce public-key encryption technology to XML business documents and provide an additional security mechanism for future versions of the SAP exchange infrastructure.

Key Management

To manage public-private key pairs and digital certificates with mySAP Technology, the SAP Trust Manager (dialog transaction STRUST) is provided with the SAP Web Application Server (see Figure 2). SAP system administrators use it to manage existing key pairs and certificates for system signatures, and to create and manage new ones for use with SSL, GSS API, and the SAP Logon Ticket.

Figure 2 SAP Trust Manager

SAP Trust Center Services

The SAP Trust Center services provided via the SAP Service Marketplace (http://service.sap.com/tcs) already cover basic functions, such as signature certificates for the SAP Logon Ticket mechanism and user certificates for authentication and single sign-on (SAP Passport).

For the SAP Web Application Server 6.10, SSL test certificates have been available since fourth quarter 2001, and there are plans to support productive SSL certificates in 2002. The use of other suitable services by other trust centers is always possible supporting the corresponding open standards.

Conclusion

Public-key technology has gradually made its way into mySAP Technology to provide increased security for productive operation. At SAP, for example, several hundred SAP systems and nearly 30,000 users are equipped with digital certificates for secure connection setup, authentication, and single sign-on.

Clearly, public-key technology was not the revolution promised (and advertised) by many. Further careful work is still needed across all software vendors involved, including web server and web browser technology, to overcome existing deficits. These deficits still exist to some degree with respect to performance issues, user certificate support in web browsers, and revocation handling, for example. However, continued efforts toward making proper use of public-key technology in today’s business software will pay off in the form of improved security — check it out for your own SAP systems!


1 For a description of how to enable SSL in the SAP Web Application Server see my article “Developing and Deploying Secure Internet Applications — Security Features of the SAP Web Application Server” in the October-December 2001 issue of SAP Insider and in the online Article Archives.

2 Strong protection refers to protection that is practically impossible to break in a reasonable amount of time (hundreds of years) with today's computing power and cryptographic knowledge.

3 A digital signature is a cryptographic seal appended to the signed message, represented by a string of 128 or 160 bits. These bits are computed using the signatory's private key and a cryptographic signing algorithm, usually a public-key algorithm.

4 The first public-key system, RSA, was published in 1978 and is based on the difficulty of factoring large prime numbers. Others quickly followed, such as DSA and elliptic curve cryptography. Both RSA and DSA today require keys of 1,024 bits or more to provide strong protection. RSA can be used for encryption and digital signatures, while DSA can be used for digital signatures only.

5 Standardized in ITU Recommendation X.509.

6 See also my previous article “Authentication and Single Sign-On Options with SAP Systems” in the July-September 2001 issue of SAP Insider and in the online Article Archives.

7 I’d like to note here, however, that this form of authentication proves only the identity of the smartcard, not the person who uses it, and admittedly there are always means to force somebody to pass the smartcard and the PIN. The only way out would be authentication systems based on strong biometrics, but such systems still require a very large effort to provide adequate security and are usually out of range for SAP systems.



Dr. Jürgen Schneider has been involved in the design and implementation of SAP security functions since 1996. Since 1998, he has been the Development Manager for Security in SAP’s Technology Development. He can be reached at j.schneider@sap.com.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ