Key Management Certificate Life Cycle

---

Key Management / Certificate Life Cycle

Because the algorithms used to generate the cryptographic components of a certificate are so strong, direct attacks on keys are fundamentally infeasible. Therefore, hackers will most likely aim their attacks on the key management systems that store and protect the keys. For this reason, it is imperative that a key management system be secure. If the security of a key server is compromised, a malicious user could impersonate someone else given that stolen keys can be used to forge certificates. A hacker could also alter keys in such a way that they could intercept “secure” transmissions.

Key management refers to the secure systems that generate, store, distribute, and provide information about keys. Although this data must be vigorously protected, at the same time, it must be available to established users. Key management techniques are designed to fulfill these needs simultaneously. The elements of key management include the creation, storage, protection, distribution, status checking, escrow, revocation, suspension, renewal, and destruction of keys and the certificates that contain them. While most of these functions are secured by a centralized system, private-key protection can ultimately be the responsibility of the user. There are many applications and protocols designed to provide these functions but few standards have been agreed upon. There are two broad categories of systems that aim to serve these purposes: centralized and decentralized.

Similar to the hierarchical trust scenario, centralized key-management systems refer to those that place the authority in a top-level entity. Again, this is the standard model used by large-scale CAs, corporations, and government agencies. It gives an administrator system-wide control regarding the many facets of key management.

Conversely, decentralized (or manual) key management allows the configuration of smaller-scale systems to be controlled by the user. Again, we turn to PGP for an example of this method. If a user were to misplace their PGP private key, they could revoke the key themselves and then notify the server of their actions. The server would then list that particular key as expired. In a centralized system, one might instead contact the administrator to do this for them. Also, decentralized systems do not provide all the functionality of centralized systems.

There are numerous vendors that package these management techniques into applications as part of their proprietary PKI solutions. There has been much heated debate on issues regarding key escrow and the introduction of trusted third party (TTP) entities that allow government access to private keys. Again, the reasons for choosing one management technique over another depend on the needs of the organization.

Let’s look at some methods of key management and the different phases a typical key goes through in its life cycle.

Storage

Key storage is a multifaceted term that is relevant to the storage systems of private companies, CAs, TTPs, and end users, alike. It can refer to systems that store and provide access to public keys, such as searchable Lightweight Directory Access Protocol (LDAP) based directories. Because the public keys stored in a LDAP directory are indeed public knowledge, the confidentiality of these systems is not a major concern. However, attacks on these systems can affect their availability and integrity. If a hacker takes down one of these servers, a PKI infrastructure that relies on it can be interrupted. When the directory is unavailable, a PKI application might be configured to use a backup authentication method that’s not as secure. A well-planned attack could be aimed at exposing the weaknesses of this backup system. Furthermore, an attacker could alter the contents of public keys. In this scenario, a number of complications could be introduced into the PKI routine.

Key storage also refers to centralized systems that store the private component of a key pair in case one is lost or needs to be accessed by an authority such as your boss or a law enforcement agency. We’ll discuss these key recovery and escrow mechanisms later in this section.

Finally, key storage also refers to the methods of private-key storage used by the individual key holder.

As far as storing your own private key goes, there are some considerations to take into account. Generally, you will store your key in either software- or hardware-based mechanisms. Because a private key should never be stored in plain text form, the most common software based methods involve encrypting the private key with a password. This can be unsafe if anyone has access to your computer because passwords can be guessed.

Some software will allow protection of a key with an extended pass-phrase. A pass-phrase is like a password but it encourages a user to enter a much longer (and therefore, much stronger) string of characters. Pass-phrases can allow for spaces, so a whole sentence (complete with caps, numbers, and symbols) can be used as an entry. However, if you need mobile encryption/decryption capabilities, storing the key on a hard drive won’t do. One solution is to carry the key on a floppy or CD-ROM. The security concerns regarding this practice should be obvious. Another method is to carry the key within a smart card. Smart cards can offer the added benefit of on-board processing, enabling encryption/decryption without exposing the private key.

An additional component of key storage that should be noted is the regular backup and archival of keys. As with any other type of sensitive data, a solid backup system is a must.

Escrow

Key escrow is a term for the systems that provide a means of data recovery when the key used to encrypt the data in question is unavailable. These systems are comprised of a depository of private keys (usually with a TTP or key escrow agent) that can be accessed only by authorized individuals, such as our big brother. The term key recovery is also applied to the systems that provide this kind of unfettered access. Normally, an administrator will generate key pairs, copy the private component, and then provide the end user with the pair. The private key would then be included in the escrowed database. Alternatively, end users can generate key pairs and then securely hand over the private key for inclusion in the database.

Some key management systems incorporate what known as m of n control to facilitate key recovery. Using this method, a separate key is generated that has the unique ability to recover other private keys in the system. This key is then actually split among many administrators in the organization. The idea is that m out of a total n of these individuals must decide collectively that key recovery is necessary. This prohibits abuse of the recovery process by any one individual.

Although it has its opponents, key escrow and recovery have become necessary evils as the use of encryption continues to rise. For instance, imagine that your lawyer has encrypted some data on a personal computer that will prove your innocence in an upcoming court appearance. Furthermore, imagine that the private key used to encrypt the data is on a disk in the lawyer’s pocket. If this person is involved in a fatal accident and the disk is destroyed, who has access to the data? The answer is, nobody. If the destroyed disk held the only copy of the key, you’re in trouble. However, if the lawyer (or the firm that employed the lawyer) had put the key in escrow, there would be a way for you to recover the vital information locked in cipher-space.

Note 

Key escrow provides a way for authorities to obtain private keys. In this scenario, there might be a stipulation that the key be destroyed after it’s been used.

Expiration

As we discussed earlier, it’s good practice to impose time limits on the life of a certificate. Typically, this is done to protect against cryptanalysis of the key in question. An additional reason for this time limit is to reduce the effects of a compromised key. If an attacker obtains a private key and stays quiet about it, the user might never find out that the key has been stolen. Instead, the thief could simply collect data in transit, decrypt it, and add it to their own database over time. Enforced periodic key changes, just like enforced password changes, keep this risk to a minimum. When checking certificate status, a returned state of expired will cause an application to reject the certificate. Similarly, a state of revoked or suspended causes the same rejection.

Renewal

It’s recommended that certificates be renewed before they expire. When a certificate expires, a new one can be issued in its place using the same keys or using brand new ones, depending on the situation. Sometimes, the only necessary change that a new certificate warrants is an update to one of its attributes. In this case, a new certificate could be issued using the original keys that the expired version contained.

Destruction

When certificates expire or get revoked, it’s common practice for CAs to destroy the certificates and any keys associated with them. This is usually accomplished by overwriting the key data. One common method of destruction is called zeroization, which simply means that all sensitive data is written over with zeros. It can also be specified that copies of private keys that reside in memory be destroyed as well.

Key Usage

The X.509 certificate standard includes an extension for specifying key usage. This extension simply specifies the intended purpose of the key in a certificate. A certificate can have more than one entry in the key usage extension. In addition, these entries can be marked critical or noncritical. If marked critical, then the certificate must only be used for the one of the designated purposes. When an application verifies a certificate, it checks this extension and compares the requested use of the certificate with the specified use or uses. If there is a discrepancy, the application will not accept the certificate but the key usage extension might have information on the whereabouts of a certificate (owned by the same entity) that fits the bill.

Here are a few examples of intended key usage:

• KEY_CERT_SIGN: States that the key is to be used for signing certificates. Only applicable to CA certificates.

• DIGITAL_SIGNATURE: States that the key is to be used for creating digital signatures.

• DATA_ENCIPHERMENT: States that the key can be used to encrypt common data.

• CRL_SIGN: States that the key is to be used to sign certificate revocation lists.

Because the key usage extension is comprised of preset values, there also exists a customizable, extended key usage field. This field can specify any organization-specific intended uses for the certificate that supplement or replace the purposes noted in the key usage extension.

Note 

If a key usage extension is flagged critical, then the certificate must be used for the specified purpose.

Multiple Key Pairs

If an entity does have multiple key pairs used for different reasons—such as one for signing and one for encrypting—it will have multiple certificates as well. This presents another challenge for key-management systems regarding the creation, distribution, revocation, and all-around management of multiple certificates owned by a single entity. One reason this is done is if an employee quits their job, the company can maintain the encryption key in order to read the employee’s encrypted documents. The signing key, however, would be revoked to prevent any prospective ill-intended document signing. Multiple key pairs can also have different strengths, strong keys for encrypting sensitive data, and weaker keys for encrypting more commonplace data. This enables faster encryption of the less sensitive stuff. Another reason for key multiplication is to provide a backup if the key is lost. Still another reason is that a spare key might be needed for entrustment with a key escrow agent. Whatever the reason, someone needs to keep track of all these keys. The complex applications that tackle the task of key management aim to simplify the process.

---