Building an E-Commerce Trust Infrastructure

II. The Solution: How to Build an Infrastructure for Trusted E-Commerce
The solution for meeting each of the goals above includes two essential components:

Together, these technologies form the essential trust infrastructure for any business that wants to take full advantage of the Internet.

A. Overview: Public Key Cryptography & Digital Certificates
This section presents background technical information on cryptographic systems, including Public Key Cryptography, the system underlying Secure Sockets Layer (SSL) - the basis for every e-commerce trust infrastructure.

Encryption is the process of transforming information before communicating it to make it unintelligible to all but the intended recipient. Encryption employs mathematical formulas called cryptographic algorithms, or ciphers, and numbers called keys, to encrypt or decrypt information.

1. Symmetric Cryptography
Until recently, symmetric encryption techniques were used to secure information transmitted on public networks. Traditional symmetric cryptographic systems are based on the idea of a shared secret. In such a system, two parties that want to communicate securely first agree in advance on a single "secret key" that allows each party to both encrypt and decrypt messages.

Symmetric cryptography has several drawbacks. Exchanging secret keys is unwieldy in large networks. Furthermore, the sharing of secret keys requires both senders and recipients to trust, and therefore be familiar with, every person they communicate with securely. Also, symmetric systems require a secure channel to distribute the "secret" keys in the first place. If there is indeed such a secure channel, why not use it to send the entire secret message?

In today's Web-based systems involving many participants and transitory interactions with strong cryptography requirements, such symmetric key-based systems are highly impractical as a means for agreeing upon the necessary secrets to begin communicating securely.

This problem, the key agreement or key distribution problem, is part of a larger problem that is central to the modern understanding of cryptographic systems - the key management problem. The key management problem is described more fully below. Together, they represent the fundamental challenge in designing effective cryptography systems for modern computing systems. Symmetric key encryption plays an important role in the SSL protocol, along with asymmetric public key encryption.

2. Public-Key Cryptography
Today's public key or asymmetric cryptography systems are a considerable improvement on traditional symmetric cryptography systems in that they allow two parties to exchange data privately in the presence of possible eavesdroppers, without previously agreeing on a "shared secret." Such a system is called "asymmetric" because it is based on the idea of a matched cryptographic key pair in which a cryptographic key is no longer a simple "shared secret" but rather is split into two subkeys, the private key and public key.

Abstractly, a participant wishing to receive encrypted communications using an asymmetric cryptography system will first generate such a key pair, keeping the private-key portion as a secret and "publishing" the public-key portion to all parties that would like to encrypt data for that participant. As encrypting data requires only access to the public key, and decrypting data requires the private key, such a system in principle can sidestep the first layer of complexity in the key management problem since no shared secret need be exchanged.

3. Modern Cryptography Systems: A Hybrid Approach
In fact, a combination of both public-key and traditional symmetric cryptography is used in modern cryptographic systems. The reason for this is that public-key encryption schemes are computationally intensive versus their symmetric key counterparts. As symmetric key cryptography is much faster for encrypting bulk data, modern cryptography systems typically use public-key cryptography to solve the key distribution problem first, then symmetric key cryptography is used to encrypt the bulk data.

Such a scheme is used by today's SSL protocol for securing Web transactions, as well as by secure e-mail schemes such as S/MIME that are built into such products as Netscape Communicator and the Microsoft Internet Explorer. See "IV. SSL Server Certificates" below for more on SSL.

4. The Key Management Problem
Underlying every cryptographic system is a set of practical problems and questions involving privacy, security and overall confidence in the underlying confidentiality features of the system. In principle, the techniques of asymmetric and symmetric cryptography are sufficient to resolve the security questions and properties described above. For example, today's Web browsers use the public key of a website in order to send credit card numbers over the Web; similarly, one can protect access to files and data using a private symmetric key to scramble the information before saving it.

However, in practice, each of these problems requires a "certified" public key in order to operate correctly without third parties being able to interfere. This leads to a second set of questions; for example:

"How can I be sure that the public key that my browser uses to send credit card information is in fact the right one for that website, not a bogus one?"

"How can I reliably communicate my public keys to my correspondents so that they can rely on it to send me encrypted communications?"

What's needed in order to address such concerns is the notion of a "secure binding" between a given entity that participates in a transaction and the public key that is used to bootstrap secure communication with that entity using asymmetric public key cryptography. The next section describes how a combination of digital signatures and X.509 digital certificates (which employ digital signatures), including SSL certificates, fulfills this role in e-commerce trust systems.

5. Digital Signatures
Digital signatures are based on a combination of the traditional idea of data hashing with public-key based encryption. Most hash functions are similar to encryption functions; in fact, some hash functions are just slightly modified encryption functions. Most operate by grabbing a block of data at a time and repeatedly using a simple scrambling algorithm to modify the bits. If this scrambling is done repeatedly, then there is no known practical way to predict the outcome - it is not in general practical for someone to modify the original data in any way while ensuring that the same output will emerge from the hash function. These hash-based signature algorithms use a cryptographically secure hash function such as Message Digest 5 (MD-5) or Secure Hash Algorithm (SHA) to produce a hash value from a given piece of data.

As the digital signature process is central to the idea of a digital certificate - and in turn, the digital certificate is the primary tool to ensure e-commerce security - it's useful to look at a diagram of the process:

The figure illustrates the steps taken by a sender in forming a digitally signed message as well as the steps a recipient takes in verifying that the signed message is valid.

The first step is to take the original message and compute a "digest" of the outgoing message using a hashing algorithm. The result is a "message digest," which is typically depicted as a long string of hexadecimal digits (and manipulated by software as binary data). In the next step, the sender uses his private key to encrypt the message digest.

The original message content, together with the encrypted digest, forms a digitally signed message, as depicted in the centre of the figure. This digitally signed message is suitable for delivery to the recipient. On receipt, the receiver verifies the digital signature using an inverse set of steps: first the encrypted digest is decrypted using the sender's public key. Next, this result is compared to an independent computation of the message digest value using the hashing algorithm. If the two values are the same, the message has been successfully verified.

Note that no actual encryption of the message content itself need take place. Only the digital signature itself is encrypted while the message is in transit (unless of course there are privacy concerns, in which case the message content should be encrypted as well).

Why is a digital signature compelling evidence that only the intended signer could have created the message? For example, what if interlopers were to change the original message? It was not encrypted, after all, and could have been changed by a third party in transit. The answer is that if such a change had been made, then the decrypted original message digest wouldn't have matched the recomputed one for the changed data in the message. Verification of the digital signature would fail. Similarly, the creation of a bogus signature is impractical because an interloper doesn't have the appropriate private key.

6. Digital Certificates
A digital certificate is an electronic file that uniquely identifies individuals and websites on the Internet and enables secure confidential communications. It associates the name of an entity that participates in a secured transaction (for example, an e-mail address or a website address) with the public key that is used to sign communication with that entity in a cryptographic system.

Typically, the "signer" of a digital certificate is a "trusted third party" or "Certificate Authority" (CA), such as VeriSign, that all participants in the use of such certificates agree is a point of secure storage and management of the associated private signing key. The CA issues, creates and signs certificates as well as possibly playing a role in their distribution.

Using digital certificates simplifies the problem of trusting that a particular public key is in fact associated with a participating party, effectively reducing it to the problem of "trusting" the associated CA service. Digital certificates therefore can serve as a kind of digital passport or credential. This approach represents an advance in the key management problem because it reduces the problem of bootstrapping trust to the problem of setting up (or in today's marketplace, selecting as a vendor) the appropriate CA functionality. All parties that trust the CA can be confident that the public keys that appear in certificates are valid.

a. Example: Use of Signer Certificates in Netscape Communicator (v4.05 & later)
Digital certificates already play a fundamental role in Internet-based cryptography systems. For example, consider the case of a secure Web transaction that takes place when a user visits a Web storefront to make a credit card purchase. When the user's browser accesses a secure page, a public key from the Web store has already been delivered to the client browser in the form of an X.509 digital certificate. All this happens transparently to the browser user at the time the secure connection is set up.

The browser trusts the certificate because it is signed and the browser trusts the signature because the signature can be verified. And why can it be verified? Because the signer's public key is already embedded in the browser software itself. To see this in the particular case of Netscape Communicator, begin by clicking on the "Security" icon on the main toolbar.

Under "Certificates", choose "Signers" and scroll down the list. A window similar to the following should appear:

Figure 3: The list of certificate signers hard-coded to be trusted in Netscape Communicator

Next select a particular certificate and click on the "Edit" button. A display similar to the following should appear:

This is a representation of an X.509 digital certificate. Although X.509 certificates come in three different versions, version 3 certificates, such as the one displayed here, are the ones that are most commonly encountered in today's cryptography systems. Such a certificate consists of the following fields to identify the owner of the certificate as well as the trusted CA that issued the certificate:

Although only a few of these fields are shown in Figure 4 (version, serial number, issuer name and subject name) corresponding to the display elements in Figure 4, these basic elements give an idea of what such a typical certificate contains.

In the next section, we describe how SSL digital certificates for Web servers apply cryptographic techniques to secure e-commerce websites.