Key Management and the Certificate Lifecycle

Being able to manage the digital certificates and key pairs used is a critical component to any PKI solution. A method of management involves the use of a lifecycle for digital certificates and their keys. The lifecycle is typically based on two documents discussed in the previous chapterthese include the certificate policy and the Certificate Practice Statement ( CPS ) . The lifecycle is a perpetual set of events required for creating, using, and destroying public keys and the digital certificates with which they are associated. The certificate lifecycle is composed of the following events:

Key generation A generator creates a public key pair. Although the CA may generate the key pair, the requesting entity may also generate the pair and provide the public key with the submission of identity in the next step.
Identity submission The requesting entity submits its identify information to the CA.
Registration The CA registers the request for a certificate and ensures the accuracy of the submission of identity.
Certification If the identity is validated , the CA creates a certificate and then digitally signs the certificate with its own digital signature.
Distribution The CA distributes and/or publishes the digital certificate.
Usage The entity receiving the certificate is authorized to use the certificate only for the certificate's intended use.
Revocation and expiration The certificate will typically expire and must be withdrawn. Alternatively, the certificate may need to be revoked for various reasons prior to expiration (for example, if the owner's private key becomes compromised).
Renewal A certificate can be renewed if requested , provided that a new key pair is generated.
Recovery Recovery may become necessary if a certifying key is compromised, yet the certificate holder is still considered valid and trusted.
Archiving This event involves storing the certificates' records and their uses.

The preceding list offers a broad view of the certificate lifecycle; however, in the following sections, we will go into more detail about important topics you should understand in regard to key management and the digital certificate lifecycle.

Centralized Versus Decentralized

Alternative methods exist for creating and managing digital certificates. These operations may either be centralized or decentralized, depending on the organization's security policy.

Centralized key management allows the issuing authority to have complete control over the process. Although this provides for a high level of control, many do not like the idea of a centralized system having a copy of the private key. Whereas the benefit of central control may be seen as an advantage, a centralized system also has other disadvantages, which include additional required infrastructure, a need to positively authenticate the end entity prior to transmitting the private key, as well as the need for a secure channel to transmit the private key.

Decentralized key management allows the requesting entity to generate the key pair and only submit the public key to the CA. Although the CA can still take on the role of distributing and publishing the digital certificate, it can no longer store the private key. As a result, the entity must maintain complete control over the private key, which is considered one of the most sensitive portions of the PKI solution. This, however, creates the added burden for the CA to ensure that the keys were generated properly and all the policies where adhered to in regard to the generation of the key pair.

Storage

Once the key pairs are generated and the CA has issued a digital certificate, both keys must be stored appropriately to ensure their integrity is maintained and that they are still easy and efficient to use. The methods used to store the keys may either be hardware or software based.

Hardware storage is typically associated with higher levels of security and assurance than software because hardware can have specialized components and physical encasements to protect the integrity of the data stored within. In addition to being more secure, hardware devices are more efficient because they provide dedicated resources to PKI functions. Naturally, however, hardware solutions often have a higher cost than software solutions.

Although software solutions do not have the same level of security as their hardware counterparts, software storage solutions are less complicated to distribute and provide for easier administration and transportability as well as lower costs.

Because the private key is so sensitive, it requires a higher level of protection than the public key. As a result, special care needs to be taken to protect private keys, especially the root key for a CA. Remember that if the private key is compromised, the public key and the associated certificate are also compromised and should no longer be valid. In the case of the CA's root key, if it becomes compromised, all active keys generated using the CA are also compromised and should be revoked and reissued. As a result of this need for increased security over the private keys, hardware solutions are often used to protect them.

Even a private key in the possession of an end user should be carefully guarded . At a minimum, this key is protected via a password. An additional safeguard may be to provide another layer of security by storing the private key on a portable device such as a smartcard ; therefore, possession of the card, as well as knowledge of the password, is required.

Escrow

Key escrow occurs when a CA or other entity maintains a copy of the private key associated with the public key signed by the CA. This allows the CA or escrow agent to have access to all information that is encrypted using the public key from a user's certificate as well as to create digital signatures on behalf of the user. As a result, key escrow is a sensitive topic within the PKI community, because there could be harmful results if the private key is misused. Because of this issue, key escrow is not a favorable public PKI solution.

Contrary to the preceding paragraph, key escrow is often seen as a good idea in corporate PKI environments. In most cases, an employee of an organization is bound by the information security policies of the organization that mandate that the organization have access to all intellectual property generated by a user as well as access to any data an employee generates. Additionally, key escrow enables an organization to overcome the large problem of forgotten passwords. Rather than revoke and reissue new keys, an organization can instead generate a new certificate using the private key stored in escrow.

Expiration

When digital certificates are issued, they are given an issued date and an expiration date. This period is indicated in a specific field within the certificate. Many certificates are set to expire after one year; however, the time period may be shorter or longer depending on the needs. In Figure 9.1, note the "Valid to" and "Valid from" fields within the certificate.

Figure 9.1. The digital certificate for a Web site.

graphics/09fig01.gif

You might recall several years ago the issue with older Web browsers as the year 2000 approached. VeriSign's root certificate, embedded into Web browsers, had an expiration date of December 31, 1999. After the certificate expired , many browsers, if they weren't updated, were unable to correctly verify certificates issued or signed by VeriSign. As a result, many certificates are given expiration dates further out. For example, a recent check of the certificates installed in one of our Web browsers shows certificates from VeriSign and Microsoft not expiring until the year 2028we sure hope we've upgraded beyond Internet Explorer version 6 before the year 2028 rolls around.

Revocation

After a certificate is no longer valid, certificate revocation occurs. There are many reasons why this may occurfor example, a private key becomes compromised, the private key is lost, or the identifying credentials are no longer valid. Revoking a certificate, however, is simply not enough. The community that trusts this certificate must be notified that the certificate is no longer valid. This is accomplished via a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP), both of which were discussed in the Chapter 8, "Basics of Cryptography."

Status Checking

Both OCSP and CRLs are used to verify the status of a certificate. Most PKI solutions have three basic status levels: valid, suspended , and revoked. The status of a certificate can be checked by going to the CA that issued the certificate or to an agreed upon directory server that maintains a database indicating the status level for a set of certificates. In most cases, however, the application (such as a Web browser) has a function available that initiates a check for certificates. For example, Microsoft introduced automated status checking for users of Internet Explorer 3.0 with the download of its Authenticode 2.0.

Suspension

Certificate suspension occurs when a certificate is under investigation to determine whether it should be revoked. This mechanism allows a certificate to stay in place, but it is not valid for any type of use. Like the status checking that occurs with revoked certificates, users and systems are notified of suspended certificates in the same way. The primary difference is that new credentials will not need to be retrievedit is only necessary to be notified that current credentials have had a change in status and are temporarily invalid.

Recovery

Key recovery is the process of restoring a key pair from a backup and re-creating a digital certificate using the recovered keys. Unlike in the case of a key compromise, this should only be done if the key pair becomes corrupted but is still considered valid and trusted. Although it is beneficial to back up an individual user's key pair, it is even more important to back up the CA's keys in a secured location for business continuity and recovery purposes.

M of N Control

M of N control , in regard to PKI, relates to the concept of backing up the public and private keys across multiple systems. This provides a protective measure to ensure that people cannot re-create their key pairs from the backup. The backup process involves a mathematical function to distribute that data across a number of systems. A typical setup includes multiple personnel with unique job functions who are from different parts of the organization to circumvent collusion among the individuals for the purpose of recovering the keys without proper authority. The mathematical equation involved can support up to 255 individuals to perform such an event; however, in most cases, no more than five are used.

Renewal

As mentioned previously, every certificate is issued with the date through which it is valid. Once the certificate expires , a new certificate needs to be reissued. Provided that the certificate holder's needs or identity information has not changed, the process is relatively simple. Once the issuing CA validates the entity identity, a new certificate can be generated based on the current public key.

Destruction

Destruction of a key pair and certificate typically occurs when the materials are no longer valid. There are, however, some precautions that should be followed in regard to destruction. If the key pair to be destroyed is used for digital signatures, the private key portion should be destroyed first to prevent future signing activities with the key. If, however, the materials were used for privacy purposes only, it may be necessary to archive a copy of the private key, because it may be needed later to decrypt archived data that was encrypted using the key. Additionally, a digital certificate associated with a key that is no longer valid should be added to the CRL regardless of whether the key is actually destroyed or archived for possible future use.

Key Usage

Digital certificates and key pairs can be used for multiple purposes, including privacy and authentication. The security policy of the organization using the key and/or the CA defines the purposes and capabilities for the certificates issued.

To achieve privacy, a user requires the public key of the individual or entity he would like to communicate with securely. This public key is used to encrypt the data transmitted, thus the corresponding private key is used on the other end to decrypt the message.

Authentication is achieved by digitally signing the message being transmitted. To digitally sign a message, the signing entity requires access to the private key.

In short, the key usage defines how the private key can be usedeither to enable the exchange of sensitive information or to create digital signatures. In addition, the key usage can define that an entity can use the key for both the exchange of sensitive information and for signature purposes.

Multiple Key Pairs

There might be circumstances that require dual or multiple key pairs to be used to support distinct and separate services. For example, an individual in a corporate environment may require one key pair to be used only for signing, yet require another for encrypting messages. Another example might be the reorder associate who has one key pair to use for signing and sending encrypted messages and another that is restricted to ordering equipment worth no more than a specific dollar amount. Multiple key pairs will also require multiple certificates because the X.509 certificate format does not support multiple keys.