The private life of private keys

A private cryptographic key is an extremely sensitive piece of information, and requires a whole set of special security measures to protect it. This article outlines some problems with key management relating to the life cycle of private cryptographic keys. There are many types of cryptographic keys; each type has own inherent challenges. Here, we outline some of the challenges we meet when managing the life cycle of asymmetric cryptographic keys and pairs.

A private cryptographic key life cycle

Possible key states

Any cryptographic key should be present only in a very limited set of states. These states will likely be:

• Key generation
• Key registration
• Key storage
• Key distribution & installation
• Key use
• Key rotation
• Key backup
  & recovery
• Key revocation & suspension
• Key destruction

Transition between these states are very limited as well, however, there will be variations in what these states are named, how they are distinguished as well as the exact sequence between these states.

State transitions basically follow each other in a circular order. However, the key could make “shortcuts”. For instance, a key in the registration state could go straight to destruction. In the next sections, we will look at what all those states mean.

Key generation

Key generation processes consume a significant amount of time and CPU resources and require specific security precautions. Once being generated, the key should be guarded. This is the initial state.

For a key to be “strong” it needs to be random. A computer itself cannot generate a strong cryptographic key - a computer is a finite-state machine, meaning it cannot generate truly random keys. Hardware Security Modules (HSMs) implement hardware key generators, which use physical processes as an entropy source for true randomness.

Key registration

The generated key should be ‘designated’ to a specific user or process, then named, attributed, and stored. Key registration can also take place during the generation stage. By registering a key, prepares it for the operations it is created for. For a registered key, an audit is performed to ensure the registered key belongs to a particular user or/and application and that the key has expiration date etc. In other words, the key registration is a subject relating to many HSM services.

Key storage

It is quite obvious that a key used for long-term operation should be saved in some secure storage. The storage should obviously be safe enough to prevent that key from being compromised. Fully functional protection is available only in special hardware storage. The easiest example is to protect it with an HSM.

Key distribution and installation

Imagine a Certification Authority (CA).  The CA processes certificate requests and enrolls public keys. The private keys that are paired with the public keys must be:

1. Exported by another key or/and password
2. Delivered to a client’s, server, computer or smart-card
3. Installed properly
4. Verified

Cryptomathic CKMS - Automated Key and Certificate Distribution 

Those activities are a ‘remote’ part of a key life cycle, but still related to a single key. Local key state history continues from point of installation.

Key use

Obviously, a key must serve its purpose. A key is used to sign data, encrypt other keys and so on. In this period, the key should be secured, used only for its intended purpose and by only the intended application and user.

Key rotation

Each time the key is used in a cryptographic operation the result will gives some ‘hint’ to attackers / cryptanalysts. After some critical mass of encrypting data using the same key, the key can be exposed fully, therefore the key should be re-generated/rotated on time, before this exposure.

Key rotation is a big problem. This problem is resolved differently depending on the nature of the key:

1. A session key is regenerated and replaced every N kilobytes of encrypted text
2. A signing key is regenerated after about 2 years of usage (see NIST recommendation)
3. A master key is regenerated after one year (which rarely happens without an efficient Key Management System)

The additional big problem is synchronous key rotation. Imagine a corporate VPN that uses a set of keys. If keys are near their end of life, they should be rotated at the same time in all VPN devices. We need a coordinated solution for that - this is why an automated and centralized key management system (KMS) is so important!

Key backup and recovery

Data backup is crucial. If you lost your data you are out of business. Key backup is extremely important. Remember the case when a main private key of one respectable CA was lost? The consequences were really terrible! A whole industry degraded for a month or so, it was a real nightmare.

As a cryptographic key is highly sensitive data, the key should not be just copied - it should be properly encrypted and wrapped. It must be written, most likely, to special media. The proper device to do key backup is an HSM.

Key revocation and suspension

Key revocation is a usual procedure. Imagine a key pair, owned by some absent-minded user. The user lost his smart card. What should we do with that? We could revoke the corresponding public key, and we will. The revoked key must be included in a Certificate Revocation List, or some database and be publicly available.

This procedure is a bit tricky, especially in case of PKI. To revoke a public key the following steps must be executed:

1. A user claims to a CA about his/her private key is lost (maybe with a smart-card as well)
2. The CA finds the certificate and the corresponding public key.
3. The CA puts the certificate hash into a certificate revocation list (CRL), and signs it.
4. The CA uploads the CRL to some public server.
5. Application systems read the new CRL, accessing the server via certificate distribution point (CDP), which is an X.509 certificate extension - A URL, speaking frankly.

Also, there is a variant of the last step. The revoked key includes in special database, available via OCSP - Online Certificate Status Protocol. Application systems can then check the revocation status online. If a user lost a key, s/he reports to a Certification Authority (CA) as soon as possible. The CA includes a corresponding public key, with a certificate, to a special database. The database is available via a network, and cryptographic-aware applications can ask the database online, by a protocol named OCSP - Online Certificate Status Protocol. Basically, an OCSP service is accessible via URL included in a certificate (there is a special extension for that).

Unfortunately, some inherent problems arise with OCSP. First of all, the protocol does not require nonce usage and therefore vulnerable to MITM attack. The second is high load to a OCSP responder. Also, sending a certificate in many cases is undesirable. There is a partial solution for it, but it is outside of this document scope.

In the case of a KMS/HSM, we do have centralized management, and therefore we can revoke or suspend keys in several place at a time.

Key destruction

Everything is going to its end, including cryptographic keys. Expired, revoked or compromised key must be terminated. I would like to outline some problems connected to proper key destruction:

1. There is no 100 % guaranteed method to ensure data destruction from an HDD (generally, any magnetic-related media - floppy (remember it?:), tapes (still in widely used), other types. There is a DoD standard for data erasure and the Gutmann method, but they aren't perfect.
2. The same thing holds for semiconductor memory. Even disconnected from power, electric cells continue to hold information.
3. Operating systems tend to swap data to disk, and do not clean memory after use.
4. Special software is able to find cryptographic keys in memory.

Therefore key destruction becomes a problem. The problems mentioned are partly solved in HSMs.

Conclusion

To properly protect the cryptographic key life cycle with an ‘ordinary’, run-of-the-mill computer raises several irreversible problems. The proper life cycle management is available only by utilizing an HSM, for secure key generation and storage, and a dedicated key life cycle management system, to ensure keys are in the right state, at the right time and always available - but only to the authorized users.

References

• NIST SP800-57 Part 1 Revision 4: A Recommendation for Key Management (2016) by Elaine Barker

• Selected articles on Key Management (2012-today) by Ashiq JA, Dawn M. Turner, Guillaume Forget, James H. Reinholm, Peter Landrock, Peter Smirnoff, Rob Stubbs, Stefan Hansen and more

• CKMS Product Sheet (2016), by Cryptomathic

Cover photo: Private by courtesy of Nathan Barry Flickr (CC BY 2.0)