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
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
||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:
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).
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:
- Given a large number of different groups of senders and recipients
of encrypted data, secure distribution of secret keys is a major
- 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
“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
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).
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
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.
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).
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.
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.
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.
||SAP Trust Manager
SAP Trust Center Services
The SAP Trust Center services provided via the SAP Service Marketplace
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.
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
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!
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.
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.
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.
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
Standardized in ITU Recommendation X.509.
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.
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