In the previous chapter, we explored three techniques for establishing and authenticating a person’s identity: the use of paper documents, biometrics, and digital signatures. We saw in that chapter that digital signatures had a significant security advantage over the first two systems for e-commerce: because the private key used to “sign” a digital signature is not used by the recipient to verify the signature, digital signatures are not easily subverted by replay attacks. Identity-proving signatures cannot be reused (if the nonces are created with care), but must be created new each time that a person’s identity needs to be proven. But as we also saw, digital signatures had a problem as well; for you to prove your identity to someone using a digital signature, that person needs to have your public key already on file. That is, being able to create a digital signature doesn’t actually authenticate your identity, it simply proves that you have possession of a private key.
The use of digital certificates and a public key infrastructure (PKI) are attempts to tie absolute identity to digital signatures. A digital certificate is a special kind of digital signature—it is a digital signature that comes with an identity, which is designed to be interpreted by computers in an automated way. A public key infrastructure is a collection of technologies and policies for creating and using digital certificates. The effectiveness of these systems comes from a marriage of public key cryptography, carefully created and maintained policies, and the legal system.
Digital certificates (shown in Figure 7-1) allow public key cryptography to be used as a kind of general-purpose identification system. A digital certificate is a signed block of data that contains a public key and other information, such as a person’s name, email address, or affiliation. For example, a university might issue digital certificates to its students that state that the students are enrolled at the university. The students could then get access to the university’s web server by presenting their digital certificates along with their public keys.
Figure 7-1. A digital certificate consists of a public key, additional information such as a person’s name or affiliation, and a digital signature from a certification authority (CA).
In the remainder of this section, we’ll use PGP’s built-in key management facilities to demonstrate how digital certificates work. Although PGP certificates are not commonly used for identity-proving, the program’s clear interface makes it particularly well-suited for this introduction. In Section 7.2, we’ll show how these principles are used in more mainstream applications.
In the previous chapter, we showed how to use a PGP public key to verify the signer of a digital signature. In fact, PGP’s “public keys” consist of much more than a simple RSA or DSA public key: PGP public keys are actually full-blown digital certificates. In addition to the public key, PGP’s “public keys” contain the key holder author’s name, email address, and digital signatures of their own. It’s these secondary digital signatures that are crucial for using digital signatures as a system for identification.
Think back to the last chapter. In Section 6.3.1, we used the CERT/CC public key to verify the Apache vendor bulletin that was distributed on January 20, 1998. Getting the public key for CERT/CC was relatively easy; we could download it either from their web page or from the PGP key server. And indeed, once we downloaded the key, the bulletin from CERT/CC verified perfectly. There was only one nagging question: how did we know that the public key we had downloaded really belonged to CERT/CC?
This question isn’t simply an off-the-cuff interrogatory—it is a question with profoundly deep philosophical implications. How can you ever know if a PGP key really belongs to the individual or an organization whose name is on the key? How can we ever really know anything?
As it turns out, we can know quite a bit about the identity of key holders and the authenticity of digital certificates, as long as certain rules and procedures are followed in the creation and protection of these instruments.
When we created the PGP key in the last chapter, PGP prompted us to enter our name and email address. This information was then attached to the key that we created. With this key, we certified our own information.
The ability for people to create and certify their own keys is one of the reasons that PGP became so popular in the 1990s. People could download a copy of PGP, create their own keys, and instantly start using it.
Alas, PGP’s ease of key creation had its own problem: if you looked up a person’s key on the key server, or if somebody emailed you a message that was signed with a key, there was really no way that you could be sure that the key really belonged to that person. There are a lot of pranksters out there, and by 1995 the PGP key servers were filled with fraudulent keys purporting to belong to U.S. President Bill Clinton, his cat Socks, Microsoft Chairman Bill Gates, and even PGP author Phil Zimmermann (see Figure 7-2). The CERT/CC even issued a warning about a fraudulent PGP key with the CERT/CC’s name that had been put on the PGP key server (see Figure 7-3). None of these keys really belonged to the individual whose name was on them.
Figure 7-2. Many keys put on the PGP key server don’t really belong to the person whose name is listed on them
Figure 7-3. CERT/CC issued a warning about a fraudulent PGP key with CERT/CC’s name that was put on the PGP key server.
The freedom that was a hallmark of PGP came with a cost: if you were given a person’s PGP key, there was no way you could be sure that it belonged to that person.
One way that you can be reasonably sure to get a person’s actual PGP key is to get the key from the person himself. In the last chapter, we saw that many individuals and organizations distribute PGP keys from their own web pages. In many cases, if you want to verify the PGP key of someone who is an avid PGP user, you can get a copy of his key from his own web site.
Most of us start life knowing only a few people—the members of our immediate family, perhaps a babysitter, a few neighbors, and some playmates. As we grow older, we meet more people. Some of them are trustworthy; we can count on them not to steal our possessions, not to hurt us, and to help us up when we fall down. Other people aren’t too trustworthy (and the less said about these people, the better).
How do we know whether to trust the new people that we meet? Most children trust everyone. But as they grow older, they become suspicious. After only a few years, when kids meet new people, those kids look to their parents and their friends—people they already trust—to figure out whether they should trust the newcomers.
One of the strengths of PGP is that it has a system that mimics this community-based approach to trust for helping users to decide if they should trust keys. With PGP, users are able to sign the key certificates of other users. A signature on a key certificate is a promise made by the signer that the key really does belong to the person whose name and email address are listed on the key. If you believe a person’s promises, then you are said to trust the key. If you have a key that has a signature (a promise) on it that you believe, then the key is said to be valid.
When you display your key ring with the PGPkeys application, each key appears with an indication of validity and trust:
- Validity
An indication of whether you believe that the key you have in your possession actually belongs to the person to whom it says it belongs. Keys are valid if you created them or if they are signed with a key that you trust.
- Trust
A measure of how much you believe the honesty and judgment of the person who holds the key. The more you trust a key, the more you trust the person who created the key to certify other people’s keys.
Figure 7-4 shows a window from the PGPkeys application. In this case, the keys for Mr. Test Key, Niche Software, and Philip R. Zimmerman are listed as both valid and trusted. This means that this PGP key ring has signatures on the keys for these individuals who the user (Simson) trusts, and that he trusts other keys signed by these keys. The key from Niche Software is listed as valid but only half trusted; if Simson finds a signature from Niche Software on a key, he will not consider that key to be valid unless there is a second signature on the key that he also trusts. The key from Peter Gutmann is valid but not trusted, which means that Simson thinks the key belongs to Peter Gutmann, but he doesn’t trust him to sign other people’s keys. There are also five keys that are implicitly trusted: Mr. Test Key, two keys for Simson, and two keys for Vineyard.NET. These keys are implicitly trusted because Simson created them and their private keys are on the private key ring.
When he created PGP, Phil Zimmermann hoped that these casual relationships between key holders would build upon each other to create an ad hoc system for global key certification. Zimmermann then called this system the "Web of Trust” (see Figure 7-5).[85]
Today the Web of Trust is most visible on the PGP key servers. In April 2001, Simson looked up his own key on the PGP public key server. He discovered that the key had five signatures on it: two from his own keys, one by Dave Del Torto, one by Eugene H. Spafford, and one by an “Unknown Signer” (see Figure 7-6) If you look up Simson’s key and you trust signatures by Dave Del Torto, Eugene H. Spafford, or the “Unknown Signer,”[86] then you will know that the key is valid.
Suppose you want to find our keys, but when you connect to the PGP key server you find several keys with our names on them. You might not know which key is the real key for each of us. However, if one of the keys on the key server is signed by someone whose key you trust, then you can differentiate between the actual key and the keys that are possibly fraudulent.[87]
One way that PGP users work to extend the Web of Trust is by holding key signing parties . PGP users will gather, exchange floppy disks or business cards containing their keys, and then show each other their driver’s licenses or passports. Having obtained a copy of someone’s key and seen an apparently unimpeachable form of identification, people at the key signing party will then sign each other’s keys and (usually) upload the signed keys to the key server.
Key signing parties are a lot of fun, especially in mixed company—and particularly when they are followed by trips to establishments involving the consumption of large quantities of alcohol, pizza, and/or chocolate. But while key signing parties are a great way to meet people, experience has shown that they are not a practical way to create a national database of cross-certified public keys—the coverage is simply too uneven. Some people have the time to go to key signing parties, but most don’t. What’s worse, having somebody’s signature on your key gives away personal information—it says that you know each other, or at least that you met each other. That’s why most large-scale uses of public key cryptography don’t rely on PGP’s Web of Trust. Instead, they rely on a tree of certifications, with a certification authority at the root.
[85] More information on the Web of Trust can be found at http://world.std.com/~cme/html/web.html.
[86] If you look up the KeyID of the unknown signer, you will find that it is Randy Antler (randy@pilot.com). We’re not really sure who this is and Simson didn’t ever meet him. He signed Simson’s key when he downloaded the key to send Simson an email in August 2000. Because this person never met Simson face to face and did not have any real way to attest that the key really belonged to Simson, this signature may be considered suspect. It illustrates why you need to be cautious about trusting arbitrary signatures on a key without knowing something about the signer.
[87] Actually, if you consult the servers, you will find two valid keys for each of us: we each have an old-style RSA key and a newer DSS/DH key.