Secure AS/400 Transactions Over Intranets and the Public Internet
The following is an I/NET partial reprint of Netscape
Communications Corporation's White Paper on Internet Security by Taher
Elgamal, Chief Scientist, Jeff Treuhaft, Director of Security
Products, Frank Chen, Product Manager, Security.
In it, I/NET hopes to describe how Commerce Server/400 uses Secure
Sockets Layer (SSL) to provide secured Intranet/Internet
transactions. While this document references secured e-mail
transactions, I/NET only provides SSL for web serving at this time.
Providing robust security services is chief among the challenges faced by
information systems teams that are building full-service intranets or
connecting to the public Internet. IS teams want to provide such services
as single-user login, message privacy, and access control for safeguarding
confidential documents. These services need to be provided in a
cross-platform (Windows, Macintosh, Unix, etc.) and application
independent (Web server, Web client, mail server, news servers, directory
server, proxy server, etc.) way.
Fortunately, industry-standard solutions to these challenges are emerging.
Cryptography plays a pivotal role in these standard solutions. This
technology white paper discusses the motivations, protocols, and product
offerings for deploying cryptographic technology throughout the
enterprise and over the public Internet.
This paper covers the following topics:
Security challenges and solutions
- Typical security challenges
- Cryptographic technology
- Secure Sockets Layer (SSL)
There are many challenges in building a full-service intranet that provides
safe communications and collaboration. As the exponential growth of the
public Internet demonstrates, TCP/IP solves many problems in a remarkably
scalable way. However, TCP/IP was not designed to offer secure
Because TCP/IP was not designed with security in mind, we must bring
additional technology and policies to bear to solve typical security
problems such as the following:
Remarkably, there is a single technology that provides the foundation for
solving all of these challenges: cryptography. Cryptographic technology is
embodied in industry-standard protocols such as SSL(Secure Sockets Layer),
SET (Secure Electronic Transactions) and S/MIME (Secure Multipart Internet
Mail Encoding). These standards provide the foundation for a wide variety
of security services, including encryption, message integrity verification,
authentication, and digital signatures. In the next section, we provide a
quick overview of cryptography as well as references for further reading.
- How do I authenticate users to make sure they are who they claim to
be? Standard Web protocols such as TCP/IP and HTTP make impersonating a
person or an organization relatively simple. For example, if Alice
connects to http://www.well-known-retailer.com, how does she know that
site is actually operated by the well-known retailer?
- How can I perform authentication without sending usernames and
passwords across the network in the clear?
- How can I provide single-user login services to avoid costly username
and account maintenance for all the servers (Web, proxy, directory, mail,
news, and so on) across the enterprise? Can I provide single-user login
without compromising security or incurring high administrative costs?
- How can I ensure that these services not only work on my intranet but
also scale to the Internet? In other words, how can I avoid managing a
separate security scheme for inside my firewall and a completely different
scheme for outside the firewall?
- How can I protect the privacy of my communications, both those in real
time (such as the data flowing between a Web client and a Web server) and
those with store-and-forward applications such as email?
- How can I can ensure that messages have not been tampered with between
the sender and the recipient?
- How can I safeguard confidential documents to ensure that only
authorized individuals have access to them?
Cryptography is a surprisingly general technology that provides the
foundation for each of the security challenges listed above. The next
sections describe how public-key technology works and explains its role
in industry-standard protocols such as SSL and S/MIME.
What Is Cryptography?
Cryptography comprises a family of technologies that include the
- Encryption transforms data into some unreadable form to ensure
privacy. Internet communication is like sending postcards in that anyone
who is interested can read a particular message; encryption offers the
digital equivalent of a sealed envelope.
- Decryption is the reverse of encryption; it transforms encrypted
data back into the original, intelligible form.
- Authentication identifies an entity such as an individual, a
machine on the network, or an organization.
- Digital signatures bind a document to the possessor of a
particular key and are the digital equivalent of paper signatures.
- Signature verification is the inverse of a digital signature;
it verifies that a particular signature is valid.
All of these technologies make use of sophisticated mathematical
techniques. For more information on cryptography, please see RSA's
Frequently Asked Questions.
Symmetric-Key and Public-Key Cryptography
Symmetric-key or secret-key cryptography uses the same key to encrypt and
decrypt messages. This is a familiar real-world phenomenon: We use the
same key to unlock and lock our car doors, for instance. The problem with
symmetric-key cryptography is having the sender and receiver agree on a
secret key without anyone else finding out. How can they do this? Over the
phone, on a floppy disk, using a courier? All of these are cumbersome,
slow, and error-prone techniques. In addition, the number of Keys tends to
be much larger than the number of nodes; that is, people may have multiple
keys they use for different purposes.
Public-key cryptography was invented in 1976 by Whitfield Diffie and
Martin Hellman to solve precisely this problem. With public-key
cryptography, each person gets a pair of keys, a public key and a private
key. Each person's public key is published, while the private key is kept
secret. When Alice wants to send Bob a secure message, she encrypts it
using Bob's public key. When Bob gets the message, he decrypts it using
his private key. The sender and receiver no longer have to share secret
information before they can communicate securely.
In practice, both symmetric-key and public-key techniques are used in
popular security protocols such as SSL and S/MIME because symmetric-key
algorithms tend to be much faster than public-key algorithms. Let's visit
Alice and Bob again. They want to communicate securely, but they also want
to communicate quickly. Here's what they do:
- Alice generates a random number (key) that will be used for actually
encrypting her message to Bob.
- Alice encrypts the random number with Bob's public key.
- Bob decrypts the random number with his private key. Now Bob has a
secret shared with only Alice that they can use to encrypt and decrypt
messages to each other.
In reality, most security protocols are much more complicated than this,
but the three-step process above gives you an idea of the fundamentals.
SSL is an excellent example of a security protocol that uses these
techniques to safeguard communications.
Digital certificates, also called digital IDs, digital passports, or
public-key certificates, are defined by an ITU standard called X.509. A
certificate is the digital equivalent of an employee badge, passport, or
The certificate and corresponding private key identify you to someone who
needs proof of your identity. If you are pulled over by the highway
patrol, you need to show your driver's license to prove that you are
legally licensed to drive a car. If you want to get into a secure
workplace, you might have to show a badge to prove that you are an
employee of the company. If you want to make a credit card purchase, you
typically have to show a credit card and demonstrate that you can produce
a signature like the one on the back of your card. All of these forms of
identification allow you to establish your identity with someone.
Over a network, a certificate serves the same role as a driver's license,
employee badge, or credit card: It establishes your identity. Servers may
be configured to grant access only to people with particular certificates;
similarly, clients may be configured to trust servers that present certain
What's in a Certificate?
An X.509 certificate is typically a small file that contains the
information shown in the following table.
|Subject's distinguished name (DN)
||A name uniquely identifying the owner of the certificate
||C=US, O=Netscape Communications, OU=Technology,
|Issuer's distinguished name (DN)
||A name uniquely identifying the certificate authority that
signed the certificate
||C=US, O=VeriSign, CN=VeriSign Class 1 root
|Subject's public key
||The owner's public key
||512-bit RSA key
||The certificate authority's digital signature from which
the certificate derives its authenticity
||RSA encryption with MD5 hash (signature itself is not human
||Dates between which the certificate is valid
Wed, Nov 9, 1995, 15:54:17
Fri, Dec 31, 1997, 15:54:17
||A unique number generated by the certificate authority for
With this overview of public-key technology in mind, let us review the
challenges described at the beginning of this paper and see how
public-key technology embodied in industry-standard protocols such as
SSL and S/MIME offers solutions for those challenges.
Example of Typical Use
|Authentication of users without username and password in
||Digital certificates (X.509)
||SSL handshake includes exchange of client and server
certificates and corresponding signatures.
||Digital certificates (X.509)
||Servers may be configured to demand digital certificates
rather than username/password pairs.
|Scalability to the Internet
||Standards-based encryption and message digest algorithms
(for example, RSA, DES) negotiated using industry-standard protocols
(for example, SSL)
||Unlike most proprietary security systems, SSL works both
inside and outside the firewall.
|Message privacy (real-time as well as store-and-forward
||Public-key encryption and RSA decryption (for example, RSA).
Often used in conjunction with symmetric-key technology (for example, RC2,
RC4, and DES) for higher performance.
||SSL protects the session key used to encrypt and decrypt a
data stream with public-key encryption. S/MIME uses a similar technique
for encrypting and signing email messages in a store-and-forward
||Message authentication codes calculated using message
digest algorithms (MD5, SHA1)
||SSL calculates message authentication codes (MACs) using a
message digest algorithm and a key negotiated during the SSL handshake.
||Protection of confidential documents from unauthorized
||Digital certificates (X.509) and signatures
||Binds users listed in access control lists (ACLs) to
certificates or requires that users present a particular certificate
(for example, signed by the Netscape Marketing Certificate Authority) for
Secure Sockets Layer (SSL) is an industry-standard protocol that makes
substantial use of public-key technology. SSL is widely deployed on the
intranet as well as over the public Internet in the form of
SSL-capable servers and clients from leading vendors including Netscape,
Microsoft, IBM, Spyglass, and Open Market as well as public-domain products
such as Apache-SSL. All Netscape products - clients, servers, and
applications - incorporate SSL to provide advanced security services. The
features in each product are described in detail below.
SSL provides three fundamental security services, all of which use
|| Protection Against
| Message privacy
| Message integrity
|| Message authentication codes (keyed hash functions)
| Mutual authentication
|| X.509 certificates
Message privacy is achieved through a combination of public-key and
symmetric key encryption, as described above. All traffic between an SSL
server and SSL client is encrypted using a key and an encryption algorithm
negotiated during the SSL handshake described below. Encryption thwarts
eavesdroppers who can capture a TCP/IP session using devices such as IP
packet sniffers. Even though packet sniffers can still capture the traffic
between a server and client, the encryption makes it impractical for them
to actually read the message.
The message integrity service ensures that SSL session traffic does not
change en route to its final destination. If the Internet is going to be a
viable platform for electronic commerce, we must ensure that vandals do
not tamper with message contents as they travel between clients and
servers. SSL uses a combination of a shared secret and special
mathematical functions called hash functions to provide the message
Mutual authentication is the process whereby the server convinces the
client of its identity and (optionally) the client convinces the server
of its identity. These identities are coded in the form of public-key
certificates, and the certificates are exchanged during the SSL
To demonstrate that the entity presenting the certificate is the legitimate
certificate owner (rather than some impostor), SSL requires that the
certificate presenter must digitally sign data exchanged during the
handshake. The exchanged handshake data includes the entire certificate.
The entities sign protocol data (which includes their certificates) to
prove they are the legitimate owner of the certificate. This prevents
someone from masquerading as you by presenting your certificate. The
certificate itself does not authenticate; the combination of the
certificate and the correct private key does.
What Happens During the SSL Handshake
SSL is designed to make its security services as transparent as possible
to the end user. Typically, users click a link or a button on a page that
connects to an SSL-capable server. A typical SSL-capable Web server
accepts SSL connection requests on a different port (port 443 by default)
than standard HTTP requests (port 80 by default).
When the client connects to this port, it initiates a handshake that
establishes the SSL session. After the handshake finishes, communication
is encrypted and message integrity checks are performed until the SSL
session expires. SSL creates a session during which the handshake needs
to happen only once. Performing an SSL handshake for every HTTP connection
would result in poor performance.
The following high-level events take place during an SSL handshake:
- The client and server exchange X.509 certificates to prove their
identity. This exchange may optionally include an entire certificate
chain, up to some root certificate. Certificates are verified by checking
validity dates and verifying that the certificate bears the signature of a
trusted certificate authority.
- The client randomly generates a set of keys that will be used for
encryption and calculating MACs. The keys are encrypted using the server's
public key and securely communicated to the server. Separate keys are used
for client to server and server to client communications for a total of
- A message encryption algorithm (for encryption) and hash function
(for integrity) are negotiated. In Netscape's SSL implementation, the
client presents a list of all the algorithms it supports, and the server
selects the strongest cipher available. Server administrators may turn
particular ciphers on and off.
SSL 2 Versus SSL 3
The first generations of Netscape products (including, for example,
Netscape Navigator 2.0, Netscape Commerce Server 1.0, and Netscape News
Server 1.0) implement SSL version 2.
The current generation of Netscape products (including Netscape Navigator
3.0 and the Netscape SuiteSpot server products) implement version 3 of the
SSL protocol. The SSL 3 protocol incorporates feedback on SSL 2 from a
wide variety of companies. The basic services SSL provides - message
integrity, message privacy, and mutual authentication - are the same in
both versions 2 and 3 of the protocol. However, SSL 3 boasts a number of
protocol enhancements such as the following:
- Fewer handshake messages for faster handshakes
- Support for more key-exchange and encryption algorithms (for example,
- Support for hardware tokens in the form of Fortezza cards. This is the
first step toward more general support for cryptography-capable smart
- An improvement to the client certificate request protocol that allows
a server to specify a list of certificate authorities that it trusts to
issue client certificates. Navigator returns a certificate signed by one
of those certificate authorities. If it does not have such a certificate,
the handshake fails. This frees the user from having to choose a
certificate for each connection.
We at I/NET hope this document helps you understand SSL and its
relationship to Commerce Server/400. We hope you understand the value
of security in your communications for general business as well as online
Please forward any questions or concerns that you might have to
Copyright © 1996 I/NET
Copyright © 1996 Netscape Communications Corporation