Public Key Infrastructure: The Beginning of a Beautiful Friendship?

A public key infrastructure (PKI) can make it possible to securely exchange data on the Internet. This introduction will help you understand the issues in PKI implementation.

The plane is waiting to take off in dense fog. Rick and Ilsa are planning to escape Casablanca on a flight to Lisbon. They are confident that they can, because they hold nonrescindable letters of transit signed by General DeGaulle (or is that Weygand?but that is another story). In the hangar, just before takeoff, Rick instructs Renault to put the names Mr. and Mrs. Victor Laszlo on the letters. What follows is perhaps the most famous film scene in historyRick and Ilsa saying goodbye on the runway, and Humphrey Bogart walking away with Claude Rains to the words, Louis, I think this is the beginning of a beautiful friendship.

Casablanca. A great movie and a great starting point for a discussion of public key infrastructure in organizations. Those letters of transit were central to the movie. They were a ticket out of Casablanca, because they were verifiably signed by a French general, and had absolute authority. They could not be rescinded (at least that was the premise of the film). Yet, none of the characters had ever met or spoken with the general. How did they know the letter was authentic? Why should a letter of transit have been created without naming the intended recipient? The characteristics of those letters of transit and the signature on them somehow proved the authenticity of the letters, and their origin.

These very same issues are important to the transmission of electronic messages and transactions and can be addressed by the administration of digital certificates through public key infrastructures (PKIs). Before we launch into a discussion of PKIs, it is worth reviewing the general concepts of public key/private key encryption.

Public keys/private keys
The use of public key/private key encryption allows the secure transmission of messages or data on the Internet, as discussed in a previous Technology Viewpoint column (Sign Here Please, Mr. Bond, August 2000, p. 28). Public keys and private keys are created as matching pairs through a sophisticated mathematical algorithm. The two keys are related to one another, but cannot be derived from one another. Each can be used to encrypt a message, turning it into unreadable coded characters. To properly use the keys, each person creating a pair of keys must keep the private key absolutely secret while publicizing the public key.

Someone who wishes to have a message read only by a particular recipient will use the public key of the intended recipient to encrypt the message. Only the recipients private key can decrypt the message and unlock the original text. The recipient can be assured of the integrity of the message, since any alteration would prevent the message from being decrypted. However, the recipient has no guarantee of who sent the message, since anyone with the public key could have sent it. If senders want to guarantee to recipients that they (and nobody else) sent the message, they encrypt it with their own private key.

The recipient (and for that matter, anyone else) can use the senders public key to decrypt the message and prove the identity of the recipient and guarantee the integrity of the message. Unfortunately, anyone who has access to the public key can also read the message. Creative combinations of these methodologies can allow the transmission of a secure, authenticated, and nonrepudiatable message. Nonrepudiatable is a term from the cryptography world that means that the sender of a message cannot deny that he or she did, indeed, send that message.

Public key infrastructures
When you receive a message encrypted with someones private key, you must have his or her public key in order to decrypt it. How do you get that public key? Perhaps the sender sent it to you in a previous e-mail or in a letter? But there is no way to be sure of the identity of the person who actually sent you the key. Anyone can easily spoof an e-mail address and send an e-mail that appears to have come from someone else. Perhaps the sender posted it on his or her Web site. Can you be sure it is the senders Web site, and not someone masquerading as the sender? If it were an important issue, you would want the sender to give you the public key in person, while showing you his or her drivers license or passport to demonstrate his or her identity. This is, in fact, the standard that a notary public uses in authenticating a persons identity and signature.

As you can imagine, the requirement for person-to-person transfer of a public key is costly, cumbersome, and impractical. The entire idea of public key/private key encryption schemes is to allow transfer of private messages between strangers. The solution to this problem involves the creation of a public key infrastructure. A PKI is a system for the management of public keys, including their assignment to an individual, their publication, and their validation. It involves technology, standards, andmost importantlypolicies. Without any of these components, a PKI cannot establish and transmit trust, and therefore cannot be relied upon.

Digital certificates
A fundamental component of a PKI is the digital certificate, which is the digital equivalent of a passport for an individual. The certificate is issued and digitally signed by a digital certificateissuing company or agency known as a certificate authority (CA), and at a bare minimum contains the name of an individual, the date range for which the certificate is valid, and the public key of that individual. The result is digital passports that absolutely identify individuals and link them to their public keys. Or do they? Lets look at the way that a digital certificate is issued in a hypothetical scenario.

Joe Smith would like to obtain a digital certificate. He contacts a registration authority (RA) that is responsible for assuring his identity and informing the CA of that identity. In many PKI schemas, the CA also performs the RA function. Once the identity is confirmed, the RA requests a certificate from the CA and the CA validates the request. It issues a certificate containing Joe Smiths public key and signs the certificate with the CAs private key.

If you think about this scenario carefully, several questions should immediately pop to mind. First, who is this certificate authority, anyway? Is it Steves Certificate Authority, or VeriSign (a well-known certificate authority), or some other trusted third party? A company that plans to use the PKI can perform the CA function. Others have suggested that governmental agencies might serve as a CA; however, the risks of this strategy are of grave concern to privacy advocates and those concerned with civil liberties. The degree to which you can trust the identity of individuals and their public keys is completely dependent on trust of the certificate authority. A dishonest employee at a certificate authority could destroy the trust in any digital certificate issued by that authority. If a CAs private key is not kept under the strictest controls, it can lead to the issuance of fraudulent certificates.

Next, how do you ensure that the person identified on the digital certificate is the person that you think it is? A certificate containing Joe Smiths public key may be useful in a small organization where there is only one Joe Smith, but PKIs are intended to manage transactions between strangers in large groups, or even between people with no previous association. Other identifying information may be needed. In addition, how can you be sure that the RA carefully checked the identity of the individual? In fact, verification of identities is one of the key policies that must be understood concerning PKIs. Identity checks can be done loosely, through the exchange of e-mails. Obviously, only limited information about an individual can be obtained by this low-assurance method. A high-assurance PKI policy could require individuals to actually physically present themselves to the RA along with a passport or drivers license. Obviously, this form of identity checking is much more reliable than e-mail exchanges.

Another question that you might ask is, how well do individuals control their private keys? Use of a private key is controlled by some form of authentication, typically a username-password or a pass phrase. If an individual shares that authentication information with a co-worker (for example, by posting the username-password on a yellow sticky note on his or her own computer), there is no way to know who is using the digital certificate. An obvious solution to this problem is biometric authentication, which is not yet reliably deployed on a large scale. (See Sign Here Please, Mr. Bond, August 2000, p. 28.)

Finally, how can you be sure that the certificate is still valid? If a digital certificate is issued, but is then compromised by sharing a password, or by bad private key management at a CA, it is necessary to somehow notify interested parties that the certificate is invalid. Otherwise, people could continue to trust a compromised digital certificate. Therefore, the recipient of a certificate needs to validate the certificate before accepting it. One way of doing this is to check (or have your software check) with the CA each time the certificate is used. The CA would keep a list of revoked certificates, and only valid certificates would pass the check. Unfortunately, this check with the CA may not be practical in some instances. An alternative is the creation of a certificate revocation list (CRL) that contains a list of all revoked certificates. It is periodically signed and issued by the CA. The problem with a CRL is that a certificate may be revoked, but the CRL list may not yet be issued. There would be no way for users to know that they were being presented with an invalid certificate. In addition, the CRL would grow very large over time. Other, more sophisticated methods are beyond the scope of this brief introduction.

The PKI hierarchy
As you can see, the use of a PKI for digital certificates is quite complex, and requires careful consideration of policy in its administration to establish trust. An organization considering PKI must deal with important questions about how the certificates will be used. For example, a company might be interested in issuing digital certificates to its employees that allow the employees to engage in secure transactions with people from other companies. To do this, the company could have an existing CA issue certificates for each employee. Alternatively, the CA could issue a digital certificate for the company, and give it the authority to serve as a CA itself. Now the company could issue, revoke, and control digital certificates. The CA confers trust upon the company through issuance of the digital certificate. Transactions can take place between any two individuals whose certificates ultimately derive trust from the root CA, whether they are in the same or different companies. In fact, two CAs can agree to trust one another, and to trust the certificates issued by any CA that derives trust from the root CA. This represents a top-down hierarchy for a PKI, which can be difficult and cumbersome to administer. The design of a PKI hierarchy can determine the degree of scalability.

Another company might wish to create a PKI for its employees alone, and may not care about transactions outside the company. The company could declare itself as the root CA and issue certificates to employees. With any model, the most difficult task is the policies and procedures around the administration of the digital certificates.

A final model is one used by the software PGP (which stands for pretty good privacy). This software allows users to act as their own CAs by issuing digital certificates to themselves. They can post these on a Web site. This alone may give little comfort to the user of such a certificate. However, another PGP digital certificate holder can sign the certificate. If you trust the signer, you can trust the signed certificate. Multiple signers can sign individual digital certificates, increasing the likelihood that you will trust one of the signers. Thus, PGP relies on a web of trust. It is a highly unstructured PKI, but can be very successfully used.

Key escrow
One very controversial issue is that of key escrow. Key escrow entails placing ones private key with a trusted authority. A proper authority can obtain the key if it is ever necessary to retrieve encrypted information in the absence of the original key owner. In a criminal investigation, for example, a person might refuse to release his or her private key to allow the reading of a message encrypted with the public key. If the key is in escrow, the police can obtain it and read the information. However, the use of key escrow seriously strengthens the ability of senders to repudiate a messagethey can simply say that someone obtained their private key and encrypted a message with it.

Administration is everything
It should be clear that use of a PKI does not guarantee security or privacy in any way. It must be properly thought through, planned, and administered to allow the secure transmission of messages or data in clinical trials, or anywhere else. Going back to those letters of transit, you now should understand the serious error that was made. The combined RA/CA failed to identify an individual for whom the letters were produced, thereby creating certificates that were compromised from the start. Fortunately for Victor and Ilsa, nobody much caredthey escaped to Lisbon and lived happily ever after.