Key Management Principles

Before you start

Objectives: Learn about some common principles and terms when it comes to key management.

Prerequisites: you have to know what is PKI.

Key terms: key, certificate, deployment, facts, principles, PKI, management


 What to have in mind

There are some basic things that we should have in mind when working with keys. For example, key length should always be long enough to provide sufficient level of protection. We should also store and transfer our keys in a secure way. Keys should be truly random and unique. We should never repeat or reuse keys. In fact, we should always destroy old keys. The lifetime of the key should be compliant with the sensitivity of the data we are protecting. We should always have a backup of our keys in case of emergency recoveries.

Key Management

There are two primary ways to implement key management. We have a centralized way and a decentralized way.

In a centralized key management solution, we have a central entity for control of our keys and certificates. This entity is responsible for the creation, distribution, modification and revocation of keys and certificates. This is not always an acceptable method for all who want to implement PKI, since centralized entity has a copy of all keys and certificates, which means that it can decrypt all user data. This can lead to a privacy violation problems.

In a decentralized key management solution, users have complete control over their own keys. Users generate their own keys (public and private), and then send them to the Certificate Authority (CA) for validation. Since users have a complete control over their keys, this method doesn’t have a problem with privacy violation.

Key Storage

In all methods, keys have to always be stored securely. The privacy of the whole PKI solution depends on the storage of keys. We have two ways to store private keys. We can do it by using software or hardware.

Software based key storage is subject to access violations, intrusions, and destruction. This method relies on the operating system to provide the security for the keys. Hardware based storage is considered more secure, but it is more expensive. Hardware based key storage can be a subject to theft. For example, hardware based storage are smart cards, flash memory drives, etc.

Key Escrow

With key escrow, we place copy of our private keys to the CA or another management entity, in case we ever somehow lose our keys. This way we can perform a key recovery by using the copy of the private key.

In many cases the key recovery from escrow requires the key recovery agent who has authority to pull keys from the escrow. Capabilities of key recovery agent is usually managed by access control mechanism called m of n control. In m of n control environment, there are n number of recovery agents, each having a unique PIN number. The specific m number of those agents, must participate together to successfully recover the key. The m number of agents can be equal or less than n number.

Key Expiration

At some time keys will expire. The lifetime of the key is defined at the time of the key creation, using valid from  and valid to fields. Once the key expires, it must be removed from the system and destroyed. Then, the new key should be created for the owner. Expired keys are not added to the CRL.

Key Revocation

During the lifetime of the key, there may be situations in which we will have to revoke the key. Key revocation takes place in situations in which owner information changes, like domain name, company name, etc. Also, revocation can occur in case of key theft, if the key has been compromised, or in case of acceptable use policy violation.

Once the key is revoked, it is listed in the Certificate Revocation List (CRL) and the Online Certificate Status Protocol (OCSP) server is updated. This way clients can query OCSP server to find the status of the certificate. Status of the certificate can be valid, suspended, and revoked. A suspended certificate is one which is still valid, but is temporarily removed from valid use. Suspended certificate can be reactivated again.

Renewing Keys

We can renew a certificate before it expires. We use our current key and sign the request for the new key. This way we don’t have to go trough the process of proving our identity, and the new key can be issued very quickly.

Key Update is a related process to renewing, in which a new key is generated by modifying the old key that is still valid.

Destroying Keys

Key destruction takes place when key is no longer useful. When a key is to be destroyed, we need to notify the CA so that they can update their CRL and OCSP servers.

Deregistration

Deregistration means that all information for the owner of the key gets invalid and is to be removed from the server. This happens, for example, when the company who owns the key stops existing. Deregistration is different from revocations because in revocation, only the key gets revoked, while the owner information remains valid. In deregistration all information of the owner is deleted from the CA database.

Key Usage

PKI and CA keys and certificates can be used in many applications, including IPsec and other VPN protocols, web based security protocols like Secure Sockets Layer (SSL), Transaction Layer Security (TLS) and Secure HTTP, as well as Secure Shell, PGP, etc. In some of these applications, multiple key pairs may be issued. One key set might be used for authentication and encryption, while another key set  might be used for digital signatures. This enables us to have the first key pair escrowed and backed up without compromising the privacy of the owners digital signature, and therefore avoid misuse.