Although the value of using public key cryptography is easy to see, the ease of use depends on being able to find and access public keys on demand. One approach to securely storing and publishing keys is a public key infrastructure (PKI). PKI provides a framework through which two parties can establish a trusted relationship even if the parties have no prior knowledge of one another. For an example of PKI in use, consider web-based e-commerce applications that are used to purchase products or services online. Operating in an online environment requires different trust mechanisms than those we use in the physical world. In the physical world, you can walk into a store, see face-to-face who you are dealing with, and get a sense of whether you should trust the business. In cyberspace, a trust relationship is much harder to establish because you do not have the physical access to people and environments. PKI addresses these concerns and brings trust, integrity, and security to electronic transactions. The PKI framework exists to manage, create, store, and distribute keys and digital certificates safely and securely. The components of this framework include the following:

• Certificate authority (CA)—The entity responsible for enrollment, creation, management, validation, and revocation of digital certificates.

• Registration authority (RA)—An entity responsible for accepting information about a party wishing to obtain a certificate; RAs generally do not issue certificates or manage certificates in any way. In some situations, entities known as local registration authorities (LRAs) are delegated the ability to issue certificates by a CA.

• Certificate revocation list (CRL)—A list of certificates that have been revoked prior to their assigned expiration, which is published by the CA.

• Digital certificates—Pieces of information, much like a driver’s license in the real world, that are used to positively prove the identity of a person, party, computer, or service.

• Certificate distribution system—A combination of software, hardware, services, and procedures used to distribute certificates.

The issue of key management becomes much larger as the pool of users interacting with the system grows. Consider the fact that in small groups, it is possible for users to exchange public keys based on a previously established level of trust. As organizations grow, it is no longer possible to do this. PKI provides a solution to this problem because it provides a mechanism through which keys can be generated and bound to a digital certificate that can be viewed and validated by all parties. To ensure trust, PKI also addresses storing, managing, distributing, and maintaining the keys securely. For any PKI system to be used, a level of support for the binding between a key and its owner requires that both a public key and a private key be created and maintained for each user. Public keys must be distributed or stored in a secure manner that prevents the keys from being tampered with or altered in any way.

Another important issue is key recovery. In any complex environment like PKI, the possibility for key loss or for a key to be compromised exists, so the system must have safeguards in place for this. Consider a scenario in which an employee or other individual leaves an organization on less-than-ideal terms, such as being terminated for cause. In such situations, there exists a real possibility that retrieving the key from the individual may be impossible or unlikely. In these situations, there must be safeguards to retrieve such keys or provide backup mechanisms in the event that vital data must be decrypted. One option in this situation is known as key escrow, which can be used to delegate responsibility of keys to a trusted third party. The third party holding the keys securely is known as a key escrow agent. In this situation, keys are kept safe by the third party, and access to the keys is granted only if certain predefined conditions are met.

Finally, determine how long a key will be valid and set a key lifetime. The lifetime for a key can be any length that is determined to be useful or practical in a given situation. Keys used more frequently tend to be assigned shorter lifespans, whereas keys that are used less frequently tend to have much longer lifespans. Keys that are used more frequently tend to have shorter lifetimes simply because increased usage means that more of it has been used with more encryption operations, so there are many more pieces of information an attacker can analyze to determine the key. Another common factor in determining key lifetime is that of usage—specifically, what the key will be used for in practice. For example, an organization may assign keys of different lifetimes to temporary versus permanent employees. Suppose that some information may be valuable for only a short period of time, whereas other data may need protection for longer periods of time. If the piece of information being encrypted will be essentially useless in a week’s time, a key lifetime longer than a week may be pointless. Also, consider what happens at the end of a key’s lifetime. Keys cannot simply be erased from media or deleted in some other way. They must be carefully destroyed using the proper technique suitable for the environment. Even more important to the issue of key lifetime and destruction is the fact that keys might not simply be retired, but they may have been lost or compromised, which can be a more serious issue in many cases. It is important that every organization have current policies in place to handle compromised keys in an efficient and timely manner.

The Role of Certificate Authorities (CAs)

Certificate authorities perform several important functions that make them fundamental to PKI. The main function or capability of the CA is to generate key pairs and bind an authenticated user’s identity to the public key. The identity that the public key is bound to by the CA is the digital certificate that validates the holder of the public key. Because the CA is validating the identity of users and creating items such as key pairs that are in turn used to perform sensitive operations, it is important that the CA be trusted. The CA must be a trusted entity in much the same way as the Department of Motor Vehicles is trusted to issue driver’s licenses and the State Department is trusted with passports. The CA and the PKI systems function on a system of trust, and if this trust is ever in doubt, serious problems can result. The CA issues certificates to users and other certification authorities or services. CAs issue certification revocation lists (CRLs) that are periodically updated and post certificates and CRLs to a repository. CAs can function as any of these common types:

• Root CA—The CA that initiates all trust paths. The root CA is also the principal CA for its domain. The root CA can be thought of as the top of a pyramid if that pyramid represents the CA hierarchy.

• Peer CA—Has a self-signed certificate that is distributed to its certificate holders and used by them to initiate certification paths.

• Subordinate CA—A certification authority in a hierarchical domain that does not begin trust paths. Trust initiates from some root CA. In some deployments, it is referred to as a child CA.

Registration Authority (RA)

The RA is an entity positioned between the client and the CA that is used to support or offload work from a CA. Although the RA cannot generate a certificate, it can accept requests, verify a person’s identity, and pass along the information to the CA to generate certificates. RAs are usually found at the same vicinity as the subscribers for which they perform authentication.

Certificate Revocation List (CRL)

A CRL is a list of certificates that have been revoked. Typically, a certificate is added to a CRL because it can no longer be trusted. Whether there is a loss of a key or an employee has left the company is unimportant. If trust is lost, the certificate gets added to the CRL. A current and readily available CRL is necessary to maintain trust in PKI. CRLs also provide input for documenting historical revocation information. The CRL is maintained by the CA, and the CA signs the list to maintain its accuracy. Whenever problems are reported with digital certificates and they are considered invalid, the CA will have their serial numbers added to the CRL. Anyone requesting a digital certificate can check the CRL to verify any certificate’s validity.

Digital Certificates

Digital certificates provide an important form of identification on the Internet and in other areas. Digital certificates are not the same as digital signatures, but they do play a key role in digital signatures, encryption, and e-commerce transactions. One of the primary roles that the digital certificate serves is ensuring the integrity of the public key and making sure that the key remains unchanged and in a valid form. The digital certificate also validates that the public key belongs to the specified owner and that all associated information is true and correct. The information needed to accomplish these goals is determined by the CA and the policies in place within the environment. Some information is mandatory in a certificate; other data is optional and up to the administrators of the organization. To ensure compatibility between CAs, digital certificates are commonly built and formatted using the X.509 standard. The X.509 standard is a commonly used format in the creation of digital certificates.

An X.509 certificate includes the following elements (see FIGURE 3-6):

• Version

• Serial Number

• Signature Algorithm ID

• Issuer Name

• Validity Period

  • Not Before

  • Not After

• Subject Name

• Subject Public Key Info

  • Public Key Algorithm

  • Subject Public Key

• Issuer Unique Identifier (Optional)

• Subject Unique Identifier (Optional)

• Extensions (Optional)

• Certificate Signature Algorithm

• Certificate Signature

Clients are usually responsible for requesting certificates and maintaining the secrecy of their private key(s). Because loss or a compromise of the private key would mean that communications would no longer be secure, holders of such keys need to be aware of and follow reporting procedures in the event a key is lost or compromised. Loss of a private key could result in compromise of all messages intended for that recipient even if the key is posted immediately to a CRL.

There are seven key management issues that organizations should address:

• Generation

• Distribution

• Installation

• Storage

• Key change

• Key control

• Key disposal

There are several ways to properly protect keys, including split knowledge and what is known as dual control. Split knowledge and dual control are used to protect the centrally stored secret keys and root private keys, secure the distribution of user tokens, and initialize all crypto modules in the system to authorize their cryptographic functions within a system.