How to Build an Infrastructure for Trusted E-Commerce

The solution for meeting each of the preceding goals includes two essential components: digital certificates for Web servers, to provide authentication, privacy, and data integrity through encryption; and a secure online payment management system, to allow e-commerce Web sites to securely and automatically accept, process, and manage payments online. Together, these technologies form the essential trust infrastructure for any business that wants to take full advantage of the Internet.

Public Key Cryptography and Digital Certificates

This part of the chapter presents background technical information on cryptographic systems. This includes Public Key Cryptography (PKC) and the system underlying 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.

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, to 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 (described in greater detail later in the chapter). 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.

Public Key Cryptography

Today’s public key, or asymmetric cryptography systems are a considerable improvement over 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 a 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 wanting to receive encrypted communications using an asymmetric cryptography system first generates such a key pair, keeping the private-key portion as a secret and “publishing” the public-key portion to all parties that want to encrypt data for that participant. Because 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 because no shared secret need be exchanged.

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. Because 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 and by secure e-mail schemes such as Secure/Multipurpose Internet Mail Extensions (S/MIME) that are built into such products as Netscape Communicator and Microsoft Internet Explorer.

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 previously described. For example, today’s Web browsers use the public key of a Web site 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 you be sure that the public key that your browser uses to send credit card information is in fact the right one for that Web site, and not a bogus one? And, how can you reliably communicate your public keys to your correspondents so that they can rely on it to send you encrypted communications?

What is 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 part of the chapter 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.

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.

Because 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. Figure 16.1 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^[1].

Figure 16.1: Steps in forming and verifying a digitally signed message.

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 center of Figure 16.1. 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

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.

Digital Certificates

A digital certificate is an electronic file that uniquely identifies individuals and Web sites 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 Web site 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). In addition, all participants who use such certificates agree it 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.

Use of Signer Certificates in Browsers

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 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 a browser, begin by clicking on the Security icon on the main toolbar, as shown in Figure 16.2^[1].

Figure 16.2: The Security toolbar button in a typical browser.

Under Certificates, choose Signers, and scroll down the list, as shown in Figure 16.3^[1]. A window similar to that shown in Figure 16.4 should appear^[1].

Figure 16.3: Security Info page.

Figure 16.4: The list of certificate signers hard coded to be trusted in a typical browser.

Next, select a particular certificate and click on the Edit button. A display similar to the one shown in Figure 16.5 should appear^[1].

Figure 16.5: A VeriSign CA certificate embedded in a typical browser.

This is a representation of an X.509 digital certificate. Although X.509 certificates come in three different versions (such as the one displayed in Figure 16.5), they 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 and the trusted CA that issued the certificate:

• Version

• Serial number

• Signature algorithm ID

• Issuer name

• Validity period

• Subject (user) name

• Subject public-key information

• Issuer unique identifier

• Subject unique identifier

• Extensions

• Digital signature for the preceding fields^[1]

Although only a few of the preceding fields (Version, Serial number, Signature algorithm ID, Issuer name, Validity period, Subject (user) name, Subject public-key information, Issuer unique identifier, Subject unique identifier, Extensions and Digital signature for the preceding fields) that are shown in Figure 16.5 (version, serial number, issuer name, and subject name) correspond to the display elements in Figure 16.5, these basic elements give an idea of what such a typical certificate contains. In other words, the certificate shown in Figure 16.5 contains only a few of the basic fields. A more detailed dump of raw certificate content might look like the following^[1]:

Certificate:       Data:        Version: v3 (0x2)        Serial Number: 8 (0x8)        Signature Algorithm: PKCS #1 MD5 With RSA Encryption        Issuer: CN=Root CA, OU=CIS, O=Structured Arts Computing Corporation, C=US        Validity:         Not Before: Fri Dec 5 18:39:01 1997         Not After: Sat Dec 5 18:39:01 1998        Subject: CN=Test User, OU=Test Org Unit, O=Test Organization, C=US        Subject Public Key Info:         Algorithm: PKCS #1 RSA Encryption         Public Key:          Modulus:           00:c2:29:01:63:a1:fe:32:ae:0c:51:8d:e9:07:6b:02:fe:ec:           6d:0e:cc:95:4b:dc:0a:4b:0b:31:a3:1a:e1:68:1f:d8:0b:b7:           91:fb:f7:fd:bd:32:ba:76:01:45:e1:7f:8b:66:cd:7e:79:67:           8d:48:30:2a:09:48:4c:9b:c7:98:d2:b3:1c:e9:54:2c:3c:0a:           10:b0:76:ae:06:69:58:ac:e8:d8:4f:37:83:c3:f1:34:02:6d:           9f:38:60:6f:5e:54:4f:71:c7:92:28:fb:0a:b3:44:f3:1a:a3:           fe:99:f4:3f:d3:12:e2:f8:3b:03:65:33:88:9b:67:c7:de:88:           23:90:2b          Public Exponent: 65537 (0x10001)        Extensions:         Identifier: Certificate Type          Critical: no          Certified Usage:           SSL Client         Identifier: Authority Key Identifier          Critical: no          Key Identifier:           a7:84:21:f4:50:0e:40:0f:53:f2:c5:d0:53:d5:47:56:b7:c5:           5e:96       Signature:        Algorithm: PKCS #1 MD5 With RSA Encryption        Signature:         2d:76:3f:49:5b:53:3a:c5:02:06:a3:67:6d:d9:03:50:57:7f:de:a7:a9:         cd:69:02:97:6f:66:6a:7f:95:ea:89:75:7a:fc:b0:26:81:fc:33:bb:60:         e8:f7:73:77:37:f8:8a:04:3b:fc:c1:3e:42:40:3d:58:16:17:7e:47:35:         1c:73:5a:ab:72:33:c3:f5:2b:c6:eb:b5:39:52:82:c6:3e:e1:38:c6:39:         8b:ee:e3:9f:b3:b9:29:42:0d:11:a5:79:af:6d:3a:f8:a6:ba:d0:9c:55:         48:0d:75:91:05:0b:47:67:98:32:f3:2d:2e:49:ed:22:ab:28:e8:d6:96:         a1:9b 

The next part of the chapter describes how SSL digital certificates for Web servers apply cryptographic techniques to secure e-commerce Web sites.