by Rik Farrow
It all started innocently enough. While speaking at a security conference, an attendee mentioned to me that they planned on employing disk encryption, but that would have to wait until they had their PKI up and running. The very notion that disk encryption relied on a Public Key Infrastructure left me stunned. As I had no quick answer, I decided I would dig deeper. And what I discovered turned out to explain why that attendee was both right and wrong.
A few years ago, PKI sounded like the technology that would solve lots of security problems. Today, there are few large scale PKI implementations, although many pilot projects. To see why PKI has not been a great success, you have only to look into the history behind PKI and you will understand why your security landscape does not, and probably will not, include a working PKI.
The notion of a PKI goes all the way back to the original paper on public key cryptography (Whitfield Diffie and Martin Hellman, 1976). What you might know about Diffie and Hellman is that they invented the concept of asymmetric ciphers, ones where there are two related keys, as opposed to symmetric ciphers, where there is only one key used. In their proposal, they suggested using two values that were related via some very slow to compute mathematical function, but where one value could be used to encrypt a message and the other to decrypt the enciphered message. Because the relationship between the two values would be non-trivial to compute, one of the key pair could be made public with no loss in the security of other, private, key.
The authors went on to suggest that a "Public Key White Pages" be created, so that anyone could fetch a person's public key. At one stroke, they had invented public key cyptography and PKI. But the history of PKI doesn't end there.
Public key cryptography relies on the private key remaining secret, and keeping the private key as part of an online server seems foolish, then as now. In 1978, a college student, Kohnfelder, published the idea of having an offline certificate authority (CA) that binds together an identity and a public key by digitally by signing a certificate containing this data using the CA's own, private key. The signing authority lends its trust, via its signature, to the combination of an identity and its corresponding public key. Now, an online server can provide the certificates, and anyone can fetch the certificates and verify its authenticity by using the public key of the CA.
If history had just been a little different, we might have a real PKI today. But several things intervened. The first is that RSA acquired the patents on the first workable public key implementation, and that resulted in public key technology generally being avoided because of licensing issues -- until the patents expired. Phil Zimmerman did create PGP, which avoided the RSA patents, but choose an anarchistic approach to public key distribution. The second big problem for a workable PKI turned out to be something that seems totally unrelated, X.500 directories.
X.500 directories were designed to be an online, global information database used for electronic mail and other network applications by the OSI (Open Systems Interconnections) in the 1980s. X.500 relies on ASN1 (Abstract Syntax Notation One) to define the content of directory entries. European readers and Active Directory administrators may be very familiar with X.500, but for those of you who are not so familiar with it, let me describe a Distinguished Name, or DN. An example DN, taken from the book "Understanding PKI" (Carlisle Adams and Steve Lloyd, Addison-Wesley, 2003) looks like "C=CA, O=ADGA, OU=AEPOS Technologies, CN=Steve Lloyd". DN's are hierarchical, starting with a country code, than an organization, organizational unit, and finally, a common name.
The connection between X.500 directories and DN's becomes clear as soon as you learn that the X.509 public key certificates were created to authenticate access of X.500 directories, and DNs are used for both the issuing certificate authority and the subject. Versions one and two of X.509 have fallen out of use, as they were missing key fields required for use in Internet applications. For example, neither version one or two of X.509 includes space for the certificate subject's email address. The DN turns out to be a large part of the reason why we don't have PKIs today, because DNs turn out to have little relationship to the naming schemes we use in everyday life.
X.509 version 3 has sufficient extensions to keep (almost) everybody happy (you can read about it in RFC 3280, see Resources,as well as the Adams and Lloyd book). There is even a "Subject Alternative Name" that is designed to contain other name forms, such as an email address, domain name, URI, etc. The extensions can be used to specify the allowed uses for the key within the certificate, certificate policy URIs, and the Certificate Revocation List Distribution Point. There is now more than enough flexibility in X.509v3 to suit everybody.
Everything contained within the fields of an X.509 certificate gets signed using the private key of the CA. Thus, not even a single bit can be changed within a certificate without invalidating the signature. And thus lies one enormous problem for PKI.
You can dye your hair or grow a beard, and your passport or driver's license is still valid. But change a single bit, much less your organizational unit or your email address, and any X.509 certificates you have become invalid. Not only must your CA issued new certificates, but it must also revoke your existing certificates.
Certificate revokation lists (CRL) are themselves an enormous issue for PKI. The idea is simple enough--each CA maintains a list of revoked certificates that can be checked everytime an application wishes to use a certificate. But consider the implications of that statement. Certificates can no longer be used offline, but require access to the most current CRL. The CRL itself can be quite lengthly, so the mere process of downloading the CRL is nontrivial, both for the application and for any network that supports the CRL service. Note that even changing the CRL service means that all current certificates must be revoked, because the Certificate Revocation List Distribution Point gets included in those certificates.
CRLs neither scale well, nor follow any real world paradigm. If you can imagine a global PKI where every use of a certificate involved downloading the current CRL, you can see one problem. Another is that the mechanism is one that has already been proven unworkable. Credit card companies used to publish lists of stolen or revoked credit cards, but they stopped doing this long ago in favor of online authorization. A similar mechanism does exist for PKI, in which instead of downloading a CRL, the application validating a certificate checks with the issuing CA to see if the certificate has been revoked. The Online Certificate Status Protocol, OCSP, attempts to deal with this problem, although even this protocol turns out to be too vague to be useful (see Peter Gutmann's PKI Tutorial).
X.509 is too flexible in others ways. Most vendors actually create certificates that are incompatible with other products by using fields, such as the Key Identifiers or Key Usage fields, in different ways. The various PKI products today have an interoperability record not unlike those of VPN products had several years ago. That is, if you planned on interoperability, your best strategy is to use the same product everywhere. In other words, no real interoperability at all.
Some products (see Network Mag article in Resources) do support the concept of cross certification. Cross certification allows different CAs to issue certificates for each other. As an example, imagine two corporations, each with its own, internal CA, that wish to leverage PKI in communications between the two corporations. The cross certification certificate permits users within either organization to recognize and validate certificates from within the other organization. Of course, this depends on the fields within the certificates being compatible for both CA implementations.
The DNs issue arises again here, as different organizations may have different naming schemes to handle name collisions. Does the common name (CN) of John Smith refer to John Smith, CEO, or John Smith, clerk? You might be able to perform a directory lookup and discover the correct Smith, if the certificate you are using can be validated and will permit the directory lookup in the first place.
By this point, I hope that you have become aware of the management infrastructure that surrounds any PKI. There will be the group or application that registers participants, verifying their identities to whatever level is required by the CA's policy. The client application that works with the registration service must also create the key pair, securely transport the public key to the registration server, wait for a certificate to be generated (usually by the offline CA server), then download and install the certificate. This process is usually unfamiliar to users, and requires support to complete successfully. Once completed, the user should now have a certificate that they can use for secure email (S/MIME) and other applications that will use their private key for signing, and include the certificate for validation.
Adams and Lloyd go into great detail about the support infrastructure
required to make PKI a reality within an organization. Besides the
CA and the registration server, they also cover backing up both the
certificates issued and the private key. At first glance, backing
up the private key seems to turn the entire notion of PKI on its
head, but users will lose their passwords (that encrypt the private
key), or even their entire portable computing device, such
as a notebook or a PDA. Secure
methods for backing up private keys do exist, so a key backup and
recovery server will also be a part of your internal PKI. As keys
should not be used indefinitely, you will also need to update keys,
and keep a history of past key pairs, so that archived documents
can still be validated or decrypted.
Once you have a mechanism for backing up private keys, you could use this same mechanism for backing up a second key pair, used for encryption keys, instead of digital signatures. The backup mechanism provides your organization with a secure key escrow, so the loss of a password or encryption key never results in the loss of data. Even though key management/escrow is not by itself the reason for PKI, it does turn out to be an essential ingredient in running a successful PKI.
Thus, the student who claimed that disk encryption relied on their PKI was right. Some PKI products solve a problem they were never intended to solve. As long as PKI products rely on X.509 certificates that were intended for authentication to X.500 severs, they can hardly be used to match existing, real-world applications for authentication, digital signatures, and authorization.
Resources:
Network article on PKI products:
http://www.networkmagazine.com/shared/article/showArticle.jhtml?articleID=8703412
RFC3280, X.509 v3 certificates for an Internet PKI: http://www.faqs.org/rfcs/rfc3280.html
Peter Gutmann's PKI Tutorial:
http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
ArticSoft page that mentions some degree of interoperability in S/MIME: http://www.articsoft.com/wp_smime.htm