Chapter 7: The Public Key Infrastructure

Overview

The purpose of this section is to describe the need for the public key infrastructure (PKI) and then walk the reader through the process of creating a PKI that meets their specific needs. The PKI is a term that is constantly bandied about as being something that is "essential" and "necessary" to the long-term growth of the Internet and electronic information processing. Many people, however, would be hard-pressed to walk into a network and say, "this is part of the public key infrastructure" while pointing at a piece of hardware on a rack of equipment.

The reason for that is twofold. First, although the need for a PKI is often discussed, the definition of the PKI is difficult to nail down. The second reason is related to the first; a PKI is not a device, or even a single technology. The PKI is just as its name implies, an infrastructure. It is the combination of a number of technologies that enables us to effectively utilize public key technologies.

While the math may be somewhat obscure to the non-mathematicians among us, the actual process of encrypting data using public key and secret key algorithms is quite straightforward. The chances are very good that you, in your normal Internet activities, have used encryption without ever even realizing it. The problem is not the actual encryption of data in a secure manner. Rather, the problem is knowing to whom you are encrypting the data. In our day-to-day lives, you know that you are speaking with your mother because the identity of your mother has been imprinted upon you for quite some time. You know her by sight and you know the sound of her voice. On the Internet we do not have the benefit of feedback from our own direct experience to identify someone, even if it is our mother. What we need is an electronic way of identifying a remote party — even if we have never met them prior to our first encounter.

The way we do this is through certificates. Certificates are simply public keys that have been publicly associated with a particular individual. Because it is unlikely that any one of us would have the chance to meet all the parties we would be interested in conducting business with on the Internet, we rely on a third party to verify that "Jane Doe" is, in fact, the Jane Doe that lives at 123 Highpoint Terrace, in the city of Winooski, Vermont, and not the Jane Doe living at 345 Oak St. in the same city — and most importantly, that it is not Sam Spade pretending to be Jane Doe. The organizations that we rely on to verify that there is a relationship between a public key and a user (or an Internet host) are known as certification authorities (CA).

For our purposes, the trust of the CA is going to be implied. That is, it does not matter which organization performs the function of the CA as long as we as the user of the certificate trust that the CA has done due diligence in establishing the identity of certificate holder. It could be the state or federal government, a hospital, our employers, the remote party's employer, or a separate corporation that has no other function than the verification of certificates.

Just having a trusted third party to perform the verification of individuals is not enough. How do I find Jane Doe's certificate if I need to contact her? What happens if Jane Doe suspects someone compromised her private key? What if Jane Doe changes jobs and her CA no longer chooses to stand behind her credentials? How does Jane Doe assure herself that the communication was indeed with me? What types of operations are Jane Doe's certificates valid for? Can I use her certificate to send her secure e-mail, or is the certificate only permitted when Jane Doe wants to connect to her company's VPN server?

To answer these questions, we need to create an infrastructure that supports the creation, dissemination, and termination of certificates. These functions and more are the realm of the public key infrastructure. PKI is not a single technology or even a piece of hardware. It is an abstraction created from many component parts that together answer the essential questions posed in the previous paragraph.

If PKI is an enabling technology, then what exactly does it enable other than the integration and management of certificates and public keys in our organization? After all, what can we accomplish with those two things? Quite a bit, as it turns out.

The most obvious application of PKI is in the assistance of secure communications. As discussed in the cryptography section of this text, public keys and certificates are not used to actually encrypt information. That is the role of secret key algorithms. Instead, public keys signed as a certificate are used to authenticate the remote party in a secure exchange and to encrypt the secret key itself as it is passed from one party to another. By maintaining an infrastructure that allows the easy access and control of public key certificates, encrypted sessions to any member of that PKI are trivial.

The PKI will also play a key role in the emergence of digital documents as legally binding entities. We have discussed that cryptography can also allow us to digitally sign documents. This can be the basis for a legally binding contract or can be used as the basis of a non-repudiation system, or even for notarization purposes. If you and I agree on a contract and I digitally sign it using my private key, then I cannot refute the fact that I have indeed seen and actually signed the contract. The use of certificates means that a third party has taken the steps to ensure that the key-pair I used to sign the document actually belonged to me. Thus, I cannot even argue that someone borrowed my identity to sign a document in my name. The only way that we can have confidence in the identity of digital signatures is if there exists an easy way to ensure that the signature in question is conclusively associated with a given individual. As an example, a government CA could sign the keys of individuals who were to act as notaries. While you or I may not understand the significance of a digital signature, the signature of the notary could be verified to the approval of the court system based upon the trust and verification of the government. The PKI, through the use of certificates and trust, provides this assurance.

Of particular importance to companies is the use of the PKI in privilege management. Capable of including more than just keying information, certificates can also contain extensions that describe user privileges. This can become the basis of a single sign-on system for a company, eliminating the need for multiple sign-on in the use of a heterogeneous operating environment. This is a particular benefit to the security of a company because password proliferation tends to encourage people to make a number of easy-to-remember passwords and then write them down to keep them straight. We know that passwords alone can be insufficient in ensuring the identity of a user. It is advantageous to provide users with a system that allows the use of a single password for all resources and then to instruct users in the selection of a single secure password. Certificates can also operate with smart card systems, in which case the single secure password is a one-time password generated by the smart card reader in association with a short PIN required of the user. The certificate of the PKI, by design, supports the integrity of the key that is signed by the certificate authority. Combine this with the verification of identity provided by the certificate authority and we can see that a PKI provides several major services along the way of authenticating users.

A final benefit of the PKI is the ability to provide timestamping services. Secure timestamping is not one of those things that immediately springs to mind when considering information security, but timestamping is an essential element of almost all security services. What use is notarization or privilege management if there is not also a secure way of ensuring when the documents were examined or any time limits on user privileges provided? Timestamping is also a critical function of logging. As a system administrator, I may not care if my logs were digitally timestamped when troubleshooting a problem on the network. As a forensics investigator investigating or assisting in the prosecution of computer crimes, however, I am very interested in assuring legal authorities that the logs are intact and could not have been altered without detection. A digital timestamp, providing protection of the log contents as well as verification of the time recorded, is another element of network security that the PKI can provide through the use of keys and certificates.

In a business environment, these technologies can be used to provide secure communications and log-ins for business partners, and local and remote users. This means VPNs can be established between branch offices and remote users, ensuring that cryptographic information is transferred securely and mutually authenticating both parties in a single action. Through the use of timestamping technologies and user certificates, extensive auditing capabilities are now available to a corporation.

Databases and other file systems can be secured so that the contents of the drive themselves are encrypted and only allow access to users with the proper certificates. This alone is a significant advantage in that most methods of secure communication only protect data in transit. Secure communications do not protect any stored data. It is a generally accepted fact that few are going to waste their time trying to decrypt an IPSec session. It is usually far easier to simply attack the machines at either end of the connection and hope to access the transmitted data in unencrypted form on one of the host systems. Encrypting file systems provides an effective countermeasure to this behavior.

The process of encrypting sensitive documents on a hard drive also underscores another advantage of the PKI. It is not enough simply to sign and distribute certificates. For the technology to be useful in a business environment, the PKI must also be an effective management tool. If a key employee were to become injured or leave the company, any data he or she has encrypted would become unavailable under normal circumstances. PKIs used in a corporate environment should always have the ability to back up or escrow key components. That ensures that keying material is not simply lost through the destruction of a hard drive, or the death or departure of an employee. It also serves as a certain safeguard to ensure that employees are not using encryption technologies in a manner that might cause harm to other people or the company itself.

In a comprehensive PKI, a device known as the certification authority (CA) is the cornerstone of the system. The CA provides all of the essential key management functions required for an enterprise. It is through the CA that users register their keys. It is the CA that provides the signing key for the organization and it is the CA that distributes signed keys to those that request them. The CA is also responsible for maintaining key histories and any backup or escrow functions that may be desired. Finally, the CA is the arbiter of revoked keys and provides revocation information if required.

The functions of a CA may be offloaded to another device known as a registration authority (RA). Due to the sensitive nature of the CA, it may be advantageous to provide many key management functions on a separate device and reserve the CA for the act of issuing and assigning new keys. In a busy environment, this provides more efficient operation and allows better isolation of the CA.

The security requirements of the CA cannot be understated. Commercial organizations that provide CA services for individuals and other companies spend a good amount of marketing budget describing the security steps they have taken to protect the signing keys. Their caution is warranted. The foundation of the PKI is the trust that the users have in the system. If the signing keys for a CA are compromised, then the entire infrastructure that relies on these keys is in jeopardy. That includes VPN communications, encrypted data, personnel authorization, logging, accounting and auditing functions, and any data that may have been digitally signed after the time of compromise. Imagine walking into work on a Monday morning and having to sort out all that. Thus, when considering the total expense of a PKI, steps taken to secure the CA itself must be considered. In many ways, it is akin to performing another risk analysis specifically for the CA. This may mean creating a separate secure subnet with the associated dedicated firewalls, increased logging and monitoring of CA activity, and building a physically secure storage area for the CA independent of the security of other network hardware and services. Of course, the final expense for this system will also be based on the total cost of the information protected versus the cost of the countermeasure.

As an enabling technology, the PKI can add quite a bit to your network. Because the capabilities are so extensive, rarely do you see a PKI that provides all the possible services that the PKI is capable of. Instead, you find the components that directly apply to the information security needs of your network. If this is the case, then we must first discuss the capabilities of the PKI and then determine what needs we have that can be addressed by a PKI.

A PKI can address any of the following needs:

• Confidentiality. Public key and secret key technologies can be used to encrypt data, either on a VPN or as files to be transported.

• Integrity. Through the use of digital signatures, we can ensure that information has not been modified from the original without detection.

• Authentication. Certificates can be used in conjunction with private keys to authenticate users.

• Key management. Keys must be generated, distributed, backed up, recovered in the event of loss, and occasionally revoked. A combination of software and protocol functions enables this in the PKI.

• Certificate management. Like key management, there are a number of functions that must be performed here, such as the issuance of certificates, storage, backup, revocation, certification of keys, and distribution of certificates to requesting entities.

• Notarization and non-repudiation. This includes digital timestamping and is applicable when the PKI is asked to support legal documentation.

• Policy and privilege management. The PKI can also be enabled to serve as a sign-on system for network resources. This is especially valuable in single sign-on situations as it can increase the security of a system while enabling users to sign on once to access network resources.

• Client software. Depending on the installation, client software may be included as part of the application that is requesting PKI services or included as a separate program that all applications requesting PKI services may access.

Together, the elements of PKI combine to create a system similar to the diagram in Exhibit 1.

Exhibit 1: Logical PKI Implementation

While Exhibit 1 is dense with information, it represents the various parts that combine to create a public key infrastructure. Not all of them may be employed in any given PKI environment.

The single most important element of a PKI is the concept of trust. When designing a PKI, some effort should be spent understanding the trust model that is applied to your particular PKI solution. To place the issue in context, consider the following common example of trust structures.

When I go to the liquor store to purchase some beverages, due to my boyish good looks I am constantly asked by the clerks to show proof of age. To furnish such proof, I provide picture identification in the form of a driver's license. My state government signs this license with its official state seal. While the clerk at the liquor store does not know me personally and does not know the person at the state government who signed my picture ID, he does have some faith that the state government has taken steps to ensure that the name on the license with the attached birth date does indeed match the picture on the license. The ability to use a picture ID then relies upon the trust that the liquor store clerk has in the state government. In this case, the state government is acting as a certification authority for its citizens.

I could issue my own ID card that I created on a computer and laminate that. Should I attempt to present it to a clerk, however, no matter how official looking I make it seem, the clerk will most likely be unimpressed with the certificate that I have presented. This is because the clerk does not have the requisite element of trust that I am an unbiased third party capable in the issuance of my certificate. In this instance, the element of trust in the certification authority is missing.

Were I travel out of state and attempt to purchase a bottle of wine in another state, I will be asked to provide picture ID there as well — again because of my boyish features. Although I am using an out-of-state ID card to prove my identity, the clerk in this out-of-state store trusts another state's certifications because, presumably, their own state recognizes my state as a valid issuer of identity cards. Were this not the case, I would have to apply to the new state government for a locally issued identity card in order to purchase a bottle of wine. To finish the analogy, the ability for independent certification authorities to trust each other allows the PKI to scale much larger than it would otherwise be able to do.

As can be imagined, the issue of trust is relative. For example, your employer may act as a CA for your corporation. This enables you to ensure that Jane in accounting is really Jane from accounting although you have never met, or that the company intranet Web server is really the company intranet Web server although you have never actually seen the machine to which you are connecting. Within your domain of trust, it is reasonable for your company's CA to certify the public key of the Web server because the users of that device are within the same domain of trust. I, on the other hand, may have no faith in your CA because I am not affiliated with the company. If you wish to have me perform online transactions on your Web server, you will need to have a third party certify the key of your Web server so that I can trust the device.

As with any important issue, trust relationships can be represented in a number of ways within the PKI. Some of the most common trust models are described in the following paragraphs.

A hierarchical trust model is conceptualized in Exhibit 2. We see that there is a single root CA that all subordinate CAs trust. The subordinate CAs generally provide services to the end users, although the root CA may perform this same service. In all instances, the trust model is very linear. Each device trusts the devices upstream from it, but not the devices downstream. Thus, a subordinate CA would trust a certificate signed by the root CA, but the root CA would not necessarily trust a certificate signed by an end user. Furthermore, subordinate CAs trust each other only because they share the same common root CA that has signed the keys of each of the subordinate CAs. While a strict hierarchical trust model is ideal for single organizations, it is unlikely that all entities that need to trust each other will share the same root CA. This is especially true as the PKI grows and it becomes more common to check certificates before communicating with remote parties. To accommodate the scalability requirements of a truly global PKI, a distributed trust model is more common.

Exhibit 2: PKI Hierarchical Trust Model

In a distributed model, illustrated in Exhibit 3, root CAs will sign each other's certificates. This is similar to the manner in which state governments trust each other's identification cards. This allows a user from one trust domain to trust a user in another trust domain because the root CA from the remote domain is now trusted. Following this distributed model, the PKI can scale quite large. In comparison, some of the largest databases used on the Internet — the domain name system — are distributed systems. Each CA becomes responsible for only its own end users. As long as the trust relationship between the root CAs remains intact, the system can accommodate tens of millions of users. The distributed and hierarchical models are ideal for corporate environments where an IT staff is there to support users and users themselves can be expected to have some sort of training regarding trust and the use of the PKI. For some applications, however, the full services of a PKI and the CA are either unnecessary or impractical to implement, considering the user base. In these instances, other trust models may be required. A good example of this is the use of trust on the Internet in Web browsing and online shopping.

Exhibit 3: PKI Distributed Trust Model

The particular requirements of online shopping have led to another form of trust model, deemed the "Web-based" trust model. Before describing the trust model itself, let us consider the requirements of such a model. For the Internet public at large, it would be unreasonable (and unlikely) for them to fully understand the issues of trust in creating secure communications. At the same time, for online business to evolve, nontechnical users are going to have to trust the infrastructure that has been created — without knowing how it works. This leads to a requirement of a certain amount of transparency in the trust models used for Web commerce.

In the Web-based trust model, it is most important that users trust the sites they are visiting. While it would be helpful in reducing fraud for Internet users to fully authenticate themselves to Web sites with signed digital certificates, it is unlikely that the average Internet user is going to be able to secure their private key and adequately maintain a personal certificate with a CA. Thus, authentication of the user identity is typically not enforced using certificates. Simpler measures such as passwords and credit cards are used when this authentication is important.

For users to trust the sites they visit, the sites have their certificates signed by a third-party CA that is in the business of establishing the identity of the Web server. When a user browses to a Web site and establishes a secure communications channel with the Web site, the Web server sends the browser its certificate. All popular browsers are bundled with the public key and certificate of most of the popular CAs. To keep users from having to worry about certificate expirations, most CAs include multiple keys and certificates in Web browser software. This is to reduce traffic to the CA itself by distributing the load among many, and because the CA that an online business uses may vary from business to business.

In the Web-based model then, there is a very linear relationship between the user and the CA. Instead of one root CA representing many users, as in a strictly hierarchical model, a single user may refer to multiple root CAs in the course of normal browsing. While this is not ideal from an infrastructure perspective, it represents the realities of employing the PKI in a mass-market environment. This Web-based trust relationship is illustrated in Exhibit 4.

Exhibit 4: PKI Web-Based Trust Model

The final common trust model is known as the user-centric trust model. The most famous implementation of this trust model is through the personal privacy and encryption software known as Pretty Good Privacy (PGP). The user-centric trust model essentially enables each individual user to operate as an independent CA (see Exhibit 5). Alice knows Bob and has personally verified Bob's public key, usually by verifying the contents of the key over the phone or in person. Alice then signs Bob's key with her own key. Thus, anyone who trusts Alice should also trust that Bob's key is legitimate. As users meet and exchange keys, this web of trust grows larger and more encompassing. While the user-centric model is intriguing, in practice it has scaling problems. Businesses have avoided such trust models because they eliminate the control that the root CA of the business has over the PKI. It can also require a good deal of responsibility on the part of the end user. I work in two major elements of the information economy: network design and security. It is sometimes difficult for my colleagues on the design side of the network to fully grasp the workings of the PGP user-centric model although these colleagues are extremely literate in technology. Much of the confusion centers on the issue of trust and trust relationships within the user-centric models. While trust is just as important in other models, the actual implementation of trust is more transparent to the end user than the user-centric model. Ultimately, user-centric models are ideal for technologically and security literate folks who wish to create secure relationships between diverse groups of users without the interference of centralized control.

Exhibit 5: PKI User-Centric Trust Model