Key Management and the Key Life Cycle

Key management refers to the process of working with keys from the time they are created until the time they are retired or destroyed.

Key management includes the following areas:

• Centralized versus decentralized key generation

• Key storage and distribution

• Key escrow

• Key expiration

• Key revocation

• Key suspension

• Key recovery

• Key renewal

• Key usage

  Note 

  Throughout this section, the terms certificate and key will be used interchangeably. Certificates contain keys that provide security. The process used is the same in either situation.

The term key life cycle describes the stages a key goes through during its entire life. You can think of this as a cradle-to-grave situation. By expressing these relationships in the terms of a life cycle, evaluating each phase of a key's use from its creation to its destruction becomes easier. If any aspect of a key's life is not handled properly, the entire security system may become nonfunctional or compromised.

Key management is one of the key aspects of an effective cryptographic system. Keys, as you may remember, are the unique passwords or passcodes that are used to encrypt or decrypt message. You can think of a key as one of the primary components of certificates. This is why these terms are used together. Certificates are used to transport keys between systems.

Centralized versus Decentralized Key Generation

Key generation (creating the key) is an important first step in the process of working with keys and certificates. Certificates are one of the primary methods used to deliver keys to end entities. Key length and the method used to create the key also affect the security of the system in use. The security of a key is measured by how difficult it is to break the key. The longer it takes to break the key, the more secure the key is considered to be.

According to RSA, it would take 3 million years and a $10 million budget to break a key with a key length of 1,024 bits. The amount of time it would take to break a 2,048-bit key is virtually incalculable. Of course, these numbers are based on the assumption that the algorithm is secure and no other methods of attack would work to break the algorithm or the key.

Note 

A very common method used to generate keys creates very large prime numbers. Prime numbers are numbers that are divisible only by themselves and 1. Examples of prime numbers are 1, 2, 3, 7, 11, 13, and 17. Computing prime numbers is a very laborious process. Most systems use a sophisticated approximation method to calculate prime numbers, as opposed to calculating them directly. If the calculation method is flawed, the numbers may not be prime numbers and, consequently, easier to determine.

One main thing to consider is where to create the keys. Should they be generated on a central machine or in a decentralized environment? A third method used to generate keys is called the split generation system. The split generation system is a combination of a centralized and decentralized process.

Centralized Key Generation

Centralized generation allows the key-generating process to take advantage of large-scale system resources. Key-generating algorithms tend to be extremely computer intensive. By using a centralized server, this process can be managed with a large single system. However, problems arise when the key is distributed. How can it be transported to end users without compromising security? Figure 8.11 shows a centralized generation process. In this example, all of the physical resources are in a single location, and they under centralized management control.

Figure 8.11: A centralized key-generating facility

Centralized generation has the advantage of allowing additional management functions to be centralized. A major disadvantage of a centralized environment is that the key archival and storage process may be vulnerable to an attack against a single point, instead of a network. Reliability, security, and archiving can be addressed if the proper systems, procedures, and policies are put into place and followed.

Decentralized Key Generation

Decentralized key generation allows the key-generating process to be pushed out into the organization or environment. The advantage of this method is that it is allows work to be decentralized and any risks to be spread. This system is not vulnerable to a single-point failure or attack. Decentralized generation addresses the distribution issue, but it creates a storage and management issue. Figure 8.12 demonstrates a decentralized system. In this situation, the loss of any single key-generating system does not disrupt the entire network. The RA in the figure refers to a registration authority, and the CA refers to a certificate authority. These two servers are described in more detail in Chapter 7.

Figure 8.12: A distributed key-generating system

Split-System Key Generation

Many systems, including the PKI system, require the use of a split system. The central server generates encryption keys. Digital signature keys are created at the client or in a smart card.

Key Storage and Distribution

Where and how keys are stored affects how they are distributed. Distributing keys is usually accomplished using a Key Distribution Center (KDC), as used in Kerberos, or by using a Key Exchange Algorithm (KEA), as in the case of PKI.

A KDC is a single service or server that stores, distributes, and maintains cryptographic session keys. When a system wants to access a service that uses Kerberos, a request is made via the KDC. The KDC generates a session key and facilitates the process of connecting these two systems. The advantage of this process is that once it is implemented, it is automatic and requires no further intervention. The major disadvantage of this process is that the KDC is a single point of failure and, if attacked, the entire security system could be compromised. Figure 8.13 illustrates the KDC creating a session between two systems.

Figure 8.13: The KDC process in a Kerberos environment

The KEA process is slightly different from the KDC process. The KEA negotiates a secret key between the two parties. The secret key is a short-term single-use key intended strictly for key distribution. The KEA process should not be used to transmit both the public and private keys. Figure 8.14 illustrates the KEA process. The KEA session terminates once the key has been successfully transmitted.

Figure 8.14: The KEA process

Protecting keys from unauthorized access while making them available for use by authorized personnel is important. The process can utilize physical security measures such as locked cabinets and safes, and it can involve software such as Kerberos and PKI.

Hardware versus Software

Keys can be either hardware devices or software devices. An example of a hardware device would be a smartcard. Software keys may be generated by CA-oriented systems such as PKI. Whether hardware or software, the protecting keys are essential for a security system to operate effectively.

Protecting keys is a difficult process. Public keys do not require full protection; they only require integrity protection. Private keys, on the other hand, require full protection. The unknowing disclosure of a private key in a symmetrical or public/private key system potentially compromises the system. Armed with a private key, an attacker could read all of the communications in the system and they could also sign information and impersonate the real owner. This fraudulent signature could be very difficult to repudiate. This section briefly discusses private key protection and key server protection, which are both essential for good security.

Private Key Protection

Physically, private keys should be kept under close supervision. If possible, multiple keys should be required to open the storage facility, and the two keys should never be stored together. If two different people are responsible for storing the keys, both of them must consent and be present for the storage facility to be opened.

Key servers also pose potential security problems, both from an access control perspective and from a physical access perspective. If a fault is introduced into the system, a resulting core dump may leave the key information in a core dump file. A sophisticated attacker could use the core dump to get key information.

Most private-key security failures can be traced back to physical security or human errors. Make sure that private keys are well guarded and secure.

Key Escrow

A key escrow system stores keys for the purpose of law enforcement access. If a criminal investigation is underway, law enforcement agents, with a search warrant, have the right to access and search records within the scope of the warrant. In general, the key archival system will provide the access needed. Key escrow is listed separately because the usage is peculiar to a law enforcement investigation.

Note 

Key escrow refers to both a process and an organization or system that stores keys for access at a later date.

Many privacy groups are fighting the use of mandated key escrow on the basis that they violate personal freedom. One of the proposed methods of dealing with key escrow involves the storage of key information with a third party, referred to as a key escrow agency. This agency would provide key information only when ordered by a court. In general, key escrow is handled by the key archival system.

Note 

In an early encryption system offered by the NSA for civilian use, the NSA would have acted as the key escrow agency. The system was called Clipper, and it was not widely accepted by industry. The key escrow controversy was one of the chief reasons cited for its lack of acceptance.

Key escrow systems can also be a part of the key recovery process. Several government agencies are attempting to implement regulations requiring mandated key escrow. Mandated key escrow would allow law enforcement agencies to investigate a key escrow user without their knowledge. Many individuals and organizations view this as an invasion of their privacy. The key escrow process is covered in more detail in the key recovery section of this chapter.

Key Expiration

A key expiration date identifies when a key is no longer valid. Normally, a key is date stamped. This means that it becomes unusable after a specified date. A new key or certificate is normally issued before the expiration date.

Keys with expiration dates work similarly to credit cards that expire. Usually, the card issuer will send another card to the cardholder before the expiration date.

Most applications that are key-enabled or certificate-enabled will check the expiration date on a key and report to the user if the key has expired. PKI gives the user the opportunity to accept and use the key.

Key Revocation

Keys are revoked when they are compromised, the authentication process has malfunctioned, when people are transferred, and when many other security risks occur. Revoking a key keeps it from being misused. A revoked key must be assumed to be invalid or possibly compromised.

The credit card analogy is applicable here too. Consider a credit card that was stolen from a customer. This card, for all intents and purposes, is a certificate. A retailer could take their chances and accept the card, or they could verify that the card is accurate by running the card through a card verification machine to check its status. If the card has been reported stolen, the credit card authorization process will decline the charge.

Status Checking of Revoked Keys

Systems such as PKI use a Certificate Revocation List (CRL) to perform check the status of revoked keys. Revocations are permanent. Once a certificate is revoked, it cannot be used again. A new key must be generated and issued.

Key Suspension

A key suspension is a temporary situation. If an employee were to take a leave of absence, the employee's key could be suspended until they came back to work. This temporary suspension would ensure that the key would not be usable during their absence. A suspension might also occur if a high number of failed authentications or other unusual activities were occurring. The temporary suspension would give administrators or managers time to sort out what is happening.

The next section discusses the issues associated with checking the status of suspended keys.

Status Checking of Suspended Keys

Checking the status of suspended keys is accomplished by checking with the certificate server or by using other mechanisms. In a PKI system, a certificate revocation list (CRL) would be checked to determine the status of a certificate. This process can occur automatically or manually. Most key or certificate management systems provide a mechanism to report the status of a key or certificate.

Note 

Key management systems use the same general process when checking the status of keys. The Security+ exam distinguishes between status checking for suspension and revocation. The major difference is that a revoked key cannot be used again, while the status of a suspended key can be changed to allow the key to be used again. Once a key is revoked, a new key would be required.

Recovering and Archiving Keys

One of the problems with a key-based system is that older information, unless processed with a new key, may become inaccessible. If for example, you have a two-year-old file on your system and it is still encrypted, will you remember which key was used to encrypt it two years ago? If you are like most people, you won't. If you can't decrypt the data, it is useless.

To deal with this problem, archiving old keys is essential. This is most easily done on a server that offers secure storage. Older keys can be stored and retrieved when necessary. Figure 8.15 illustrates this relationship with a CA. This server requires strong physical security and at least the same security as the key-generating system.

Figure 8.15: The key archival system

Anytime a user or key generator creates and issues a key, the key must also be sent to the key archive system.

Key recovery is a very important part of an encryption system. Information that is stored using older keys will be inaccessible using a new key. Key recovery allows information to be accessed that is encrypted with older keys. For example, key recovery could be used to retrieve information from an ex-employee. Three different factors must be considered when implementing a key archival system.

Current Keys Current keys are the keys in use at the present time. They have not been revoked. In the event that a current key becomes lost, destroyed, or damaged, a way to recover the key needs to be added so that data loss does not occur. A smart card can also become damaged, and a method must be established to reload the card with key information.

If the current key is not recoverable, all information that was encrypted using that key will be unavailable. This type of data loss could be expensive. Some newer systems allow the creation of "virtual" smart cards that can be used temporarily to initialize a new card. This card would generally be good only for a short period of time, such as for use during a work shift.

This process should be relatively easy for administrators to manage, as people do forget to bring their authentication devices to work from time to time.

Previous Keys Previous keys are the keys that have recently expired and are no longer current. An employee who comes to work today may not know that a key rollover has occurred until they try to open yesterday's e-mail. Depending on what's in the e-mail, this could be a disaster. Many newer systems keep copies of recent keys in a key store on the system. This key store may contain the last two or three keys. If a local key store is not provided, a key restoration process will be required from the archive system. Again, this may involve manual intervention by administrators.

Archived Keys Archived keys were discussed earlier. You should expect that older messages will be needed from time to time. This is especially true in a situation where litigation is involved. During the discovery phase of litigation, all records, correspondence, and memoranda must be presented to attorneys when subpoenaed. Failure to comply will result in sanctions from the court. Imagine, if you will, that you had to access all of the e-mails and files from a particular department for the last five years. This would be a very labor-intensive undertaking.

Many recovery and archive systems use the M of N Control method of access.

M of N Control

The M of N Control method, simply stated, says that in order to access the key server if n number of administrators have the ability to perform a process, m number of those administrators must authenticate for access to occur. This may require the administrators' physical presence.

A typical M of N Control method may stipulate that six people have access to the archive server, and at least three of them must be present to accomplish access. In this situation, m = 3 and n = 6. Three of six people are needed to access the archive server. This would ensure that no one person could compromise the security system.

Note 

It is very important to remember that your key archival system contains the complete history of all the keys that have been issued by your system. This information might also include all of the current keys in use. Access to this server would be the equivalent of discovering the Rosetta Stone of your organization. An attacker with this information would have full and unrestricted access to every bit of information in your network.

Renewing Keys

Key renewal defines the process of enabling a key for use after its scheduled expiration date. A key would be reissued for a certain time in this situation. This process is called a key rollover. In most cases, the rollover of keys is something that occurs for a given time frame. What would happen if an organization found itself in a situation where a key rollover must not occur? Many systems provide a way to renew existing keys, rather than a rollover.

In general, key renewals are a bad practice and should not be performed except in the most dire of situations. The longer a key is used, the more likely it is to be compromised.

If an earthquake occurred in your area and your building was inaccessible for a two-week period of time, you would want to allow the existing keys to be used until higher priority matters could be resolved when you went back to your building. In a natural disaster, a key rollover could add an inordinate amount of stress to an already very stressful situation.

Real World Scenario: What Do You Do About Forgetful Programmers?

You work as a network administrator for a software development company. The president of the company has been reading the newspapers, and he has recently become very concerned about industrial espionage. Specifically, he wants to implement a system that will require the use of smart cards for access and authentication by all employees.

Your company has used employee badges for a number of years, and now you will be upgrading to a newer technology. You have noticed that your software developers work very long hours and sometimes forget to bring their badges to work. This has not been much of a problem because you have been able to issue temporary badges when you needed them. How could you deal with an employee who leaves his smartcard at home?

You could implement a system that allows a virtual smart card to be created for short periods of time. The employee's supervisor or a security staff member could call your smart desk to authorize the release of a virtual smart card. You would need to make sure that only trusted individuals could authorize or initiate this process.

Key Destruction

Key destruction is the process of destroying keys that have become invalid. For example, an electronic key can be erased from a smart card. In older mechanical key systems, keys were physically destroyed using hammers.

Many symmetrically based encryption systems use a dedicated device to carry the key for the encryption. This key would be physically delivered to the site using the encryption system. Old keys would be recovered and destroyed.

Whether you are using physical keys or software-oriented key systems, old keys must be destroyed in a manner that ensures that keys do not fall into unauthorized hands.

Real World Scenario: Selling the Company's Old Computers

You have been asked to verify that the computers your company has liquidated are ready to be sold. What steps should you take to verify unauthorized access to information does not occur?

You really need to be concerned about two issues in this case. First, you need to make sure that all corporate records, software, and other sensitive information is removed from the system. Second, you need to make sure that any special access devices or encryption systems have been removed. Encryption systems that use key-based models may store keys in hidden areas of the disks. As a general practice, the disks on systems that are sold as surplus should be completely zeroed out. This prevents any sensitive information from being released inadvertently.

Key Usage

Keys form the basis for most encryption and security systems. Keys are used to provide encryption and decryption. Keys are used in both symmetrical and asymmetrical systems. (See Figure 8.16.)

Figure 8.16: Symmetrical and asymmetrical keys in use

Symmetrical Keys Symmetrical keys present a difficult challenge from both a key management and a security perspective. The loss or compromise of a symmetrical key compromises the entire system. Single key systems are entirely dependent on the privacy of the key. This key requires special handling and security. Make sure that symmetrical keys are never divulged. Symmetrical keys should be transmitted using secure out-of-band methods.

Note 

In high-security environments, such as the military, symmetrical keys are commonly sent by armed courier. If a private key is compromised, the entire system is compromised. It is a good practice to assume that a potential compromise is a compromise. Avoid taking half-measures.

Multiple Key Pairs Multiple key pairs are usually designed to provide two or more keys. In a system that uses two private keys, both keys must be protected in the manner described in the symmetrical key section for security to be maintained.

A PKC system, such as PKI, has two keys: a public key and a private key. The public key is designed to be distributed and published. Security considerations for the public key are primarily focused on integrity issues. The private key, on the other hand, requires the same treatment as a symmetrical key. The compromise of a private key in a multiple key system has potentially the same affect as the compromise of a private key in a symmetrical system.