Peter Smirnoff (guest) : 20. June 2018
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.
Any cryptographic key should be present only in a very limited set of states.
These states will likely be:
Transition between these states are very limited as well, however, t here 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 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.
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.
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.
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:
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.
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.
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:
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!
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 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:
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.
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:
Therefore key destruction becomes a problem. The problems mentioned are partly solved in HSMs.
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.
Cover photo: Private by courtesy of Nathan Barry Flickr (CC BY 2.0)