Section 16.1. Public Key Infrastructures

16.1. Public Key Infrastructures

Before the invention of public key cryptography, methods for secure digital communications were all but unavailable to mainstream computer users. The reason for this was the difficult problem of key distribution : for Alice to send a secure message to Bob, they first would have to agree on a shared secret (e.g., a key or password). The only way to do this would be for Alice (or Bob, or a third party) to generate such a key and then deliver that key to Bob (or Alice, or both). While in transit, the key not only had to be kept secret but also had to be protected from tampering.

Once Alice and Bob shared a secret key, Alice could do two things: first, she could encrypt messages with the shared key and be sure that only Bob would be able to read those messages. Second, if Bob used a message authentication code, Alice could be convinced that those messages indeed came from Bob and nobody else. Because Alice and Bob both used the same key, and because this key was used for both encryption and decryption, this kind of cryptography is usually called symmetric key cryptography .

Public key cryptography makes the key distribution problem much easier. Bob generates a key pair consisting of a private key and a public key. Now, all Alice needs to do is obtain a copy of Bob's public key. As the name suggests, a public key does not need to be kept secret. For example, people could publish their public keys in a central database. Alice would then simply connect to that database and request Bob's public key to be able to communicate with Bob securely. Again, this allows two different things: first, by encrypting messages with Bob's public key, which can only be decrypted using Bob's private key, Alice can ensure that only Bob can read them. Second, by using Bob's public key to verify a digital signature on a message, Alice can be convinced that the message indeed came from Bobsuch a signature can only be created using Bob's private key.

How does Alice know that the public key she requests from the central database is indeed Bob's (and hasn't been tampered with while in transit to Alice)? Certification authorities (CAs) solve this problem, and also get around scalability issues with the central database. A certification authority digitally signs a statement consisting of Bob's public key together with an assertion that this key belongs to someone named "Bob." This signed statement is called a certificate. We assume that everybody knows the certification authority's public key. (In practice, these public keys today are part of operating system distributions such as Microsoft's Windows or Apple's Mac OS.) Using the certification authority's public key, Alice can now verify Bob's certificate, no matter where she obtained it. If the name on the certificate is indeed Bob's, and the certification authority's signature indeed verifies, Alice can be sure that she is now in possession of an authentic copy of Bob's public key.

Certification authorities can also issue certificates for intermediate certification authorities, which in turn issue digital certificates either to further intermediate CAs, or to end entities such as Bob. A hierarchical arrangement of certification authorities and end entities to allow certification of public keys is called a public key infrastructure (PKI).

Public key infrastructures have a number of advantages:

• Participants in the PKI can generate their keys independently of the parties with whom they want to communicate: new keys do not need to be generated and shared for every private communication desired.

• Public keys do not need to be kept secret. This vastly simplifies the key distribution problem.

• To ensure authenticity of public keys as they are passed around among members of the PKI, a certification authority issues public key certificates that include both a member's public key and some identifying attributes such as the member's name. Every member is assumed to trust the certification authority and know the CA's public key.

• Once the certificates are issued, any two members of a PKI can establish a secure connection without anybody else's help. They use public key protocols to ensure the integrity and secrecy of messages.

These are just the most important advantages of public key infrastructures, as compared to shared key systems. There are many more details and subtleties to PKIs that cannot be covered in this short introduction. What is important to remember is that these are not simply theoretical ideas. The concepts of public key cryptography and public key infrastructures have been implemented, and many implementations follow established standards. For example, we can use X.509^[1] certificates to exchange public keys, and can use public key protocols such as Secure Sockets Layer^[2] (SSL) or Transport Layer Security^[3] (TLS) to secure communication between web browsers and web servers.

^[1] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," IETFNetwork Working Group, The Internet Society, RFC 2459 (Jan. 1999).

^[2] Alan O. Freier, Philip Karlton, and Paul C. Kocher, "The SSL Protocol Version 3.0," IETFTransport Layer Security Working Group, The Internet Society (Nov. 1996).

^[3] T. Dierks and C. Allen, "The TLS Protocol Version 1.0," IETFNetwork Working Group, The Internet Society, RFC 2246 (Jan. 1999).