Exploring the Lifecycle of a Cryptographic Key

This article discusses the main phases involved in the lifecycle of a cryptographic key, and how the operational lifetime of a key and its strength can be determined.

Importance of Key Lifecycle Management

The most important aspect to consider is what the key is used for. One should always be careful not to use any key for different purposes. Here an important distinction is made between data keys (used to encrypt data) and key-encryption-keys (KEKs), which are used entirely to protect other keys. Keys are, fundamentally, used for encryption - but encryption often acts as a very cunning proxy for other uses such as authentication and signing (you can prove who you are based on ownership of a key).

Determination of the key’s operational lifetime and key strength

Once a key is generated, the key-management system should control the sequence of states that a key progresses through over its lifecycle, and allow an authorized administrator to handle them when necessary. The National Institute of Standards and Technology (NIST) provides strict guidelines for most aspects of the life cycle of cryptographic keys and has also defined some standards on how a crypto period is determined for each key. A crypto period is the operational life of a key, and is determined by a number of factors based on:

• The sensitivity of the data or keys to be protected
• How much data or how many keys are being protected

From this information, the operational life of the key can be determined, along with the key length (which is proportional to the cryptographic strength of the system). The algorithm (and, therefore, the key type) is determined by the purpose of the key; for example, DSA is applicable to a signing purpose only, whereas RSA is appropriate for both signing and encryption. NIST specifies cryptographic algorithms that have withstood the test of time.

The occasional need to change a key state based on unexpected circumstances

There are instances when it is necessary for an authorized administrator to make changes to the key's parameters, which cause a change in the keys state during a life-cycle. (Some of these can still be automatically taken care of through the key-management system.)

• Whether the key or associated data or encrypted key is suspected of compromise
• Change in vendor support of product or need to replace product
• Technological advances that make it possible to attack where it was previously infeasible
• Change of ownership where a change of keys is associated with a change in assignment of liability
• Regulatory requirements, contractual requirements, or policy (crypto-period) that mandates a maximum operational life
  

Description of the basic phases of a key life cycle

In the next few paragraphs, we'll look at the different stages of a key's lifecycle and how a key management solution should work at each stage. Note that every key-management solution is different, so not all of them will use the same phases. Some are not used at all, and other phases can be added, such as pre-activation, activation, and post-activation.

Generation

Keys can be generated through a key management system, hardware security module (HSM) or by a trusted third party (TTP), which should use a cryptographically secure true random number generator (TRNG) for seeds. The key storage database (which demands a master key for encryption) will then store the keys along with all of their attributes. Attributes include items like name, activation date, size, and instance. A key can be activated upon its creation or set to be activated automatically or manually at a later time.

Each key should have a key strength (generally measured in number of bits) associated with it that can provide adequate protection for the entire useful lifetime of the protected data, along with the ability to withstand attacks during this lifetime. The different key lengths will depend on the algorithm that uses them. A standard cryptographic algorithm that has been thoroughly evaluated and tested is recommended.

Backup and Storage

In order to retrieve a key that has been lost during its use (for example, due to equipment failure or forgotten passwords), a secure backup copy should be made available. Backup keys can be stored in protected form on external media (CD, USB drive, etc.) or by using an existing traditional backup solution (local or networked). When a symmetric key or an asymmetric private key is being backed up, it must be encrypted before being stored.

Distribution and Loading

The objective of the deployment and loading phases is to install the new key into a secure cryptographic device, either manually or electronically. This is the most critical phase for key security and should only be performed by authorized personnel in the case of manual installation. For manual distribution, which is by far the most common method of shared key distribution in the payments space, key encryption keys (KEKs) must be distributed and loaded in key shares to avoid the full key being “wrapped, in this context). Best practice key management standards (such as PCI DSS) are now mandating that, as well as encrypting the key material, the key usage needs to be equally secured (e.g., PIN block encryption/decryption). While this is a very secure, well-known, and established method of key distribution, it is labor intensive and does not scale well (you need a new KEK for every point that you share a key with); for larger scale key deployments (e.g., managing keys for an entire secure web server farm), asymmetric key distribution techniques are really the only feasible way. In this case, the straightforward method of deploying a public key replaces the initial step of sharing a KEK using key shares. Keys can then be transmitted securely as long as the public key (or its fingerprint) gets adequately authenticated.

Cryptomathic CKMS - Automated Key and Certificate Distribution 

Normal Use and Replacement

The key management system should allow an activated key to be retrieved by authorized systems and users e.g. for encryption or decryption processes, or MAC generation and verification. It should also seamlessly manage current and past instances of the encryption key.

The key manager will replace a key automatically through a previously established schedule (according to the key's expiration date or crypto-period) or if it is suspected of compromise (which might be achieved manually by an authorized administrator.) When replacing keys, the intent is to bring a replacement key into active use by the system, and typically to also re-encrypt  all stored data under the new key (for example if the key was used for S/MIME or Encrypting File System) but if the new key has to be used for new sessions such as TLS then old data doesn’t need to be secured by the new key. Replacing keys can be difficult because it necessitates additional procedures and protocols, which may include correspondence with third parties in public-key systems.

The timing for expiration depends on the strength of the key (key length) and how long the protected data or key will be valid. In common practice, keys expire and are replaced in a time-frame shorter than the calculated life span of the key. As a key is replaced, the old key is not totally removed, but remains archived so is retrievable under special circumstances (e.g., settling disputes involving repudiation).

Archival

Archival refers to offline, long-term storage for keys that are no longer in operation. These keys usually have data associated with them that may be needed for future reference, such as long-term storage of emails. There may also be associated data in other external systems.

When archiving a key, it must be encrypted to add security. As recommended in the creation and deployment phases, it may be useful to encrypt a symmetric key with the public key of an asymmetric key pair so that the person or entity holding the corresponding private key can only decrypt it. Sometimes (depending on the key’s deployment scenario), archival is the last phase in the life process and never moves on to deletion or destruction.

An archived key cannot be used for cryptographic requests. In certain cases, the key can continue to be used to, e.g., decrypt data previously encrypted with it, like old backups, but even that can be restricted. An administrator can, if necessary, reactivate an archived key. Before a key is archived, it should be proven that no data is still being secured with the old key.

End of Key's Life-cycle

The last phase is the end of the key's lifecycle, where all of its instances, or just certain instances, are completely removed, and recovery of that key may be possible, depending on the method used. The end of life for a key should only occur after an adequately long archival phase and after adequate analysis to ensure that loss of the key will not correspond to loss of data or other keys.

There are three methods of removing a key from operation:

• Key destruction: This method removes an instance of a key in one of the permissible key forms at a specific location. Information may still exist at the location from which the key may be feasibly reconstructed for subsequent use.
• Key deletion: This method removes an instance of a key, and also any information from which the key may be reconstructed, from its operational storage/use location. Instances of this key may continue to exist at other locations (e.g., for archival purposes).
• Key termination: All instances and information of the key are completely removed from all locations, making it impossible to regenerate or reconstruct the key (other than through a restore from a backup image).

The importance of monitoring keys during their life-cycle

The key-management system should be able to handle all of the transitions between phases of a life-cycle, and should be capable of monitoring and keeping track of these workflows.

There are certain aspects of monitoring that should be considered:

• It is important to monitor for unauthorized administrative access to the system to ensure that unapproved key management operations are not performed.
• The computer processor may be under significant load. When combined with an overloaded cryptographic service, the results could be serious, including data corruption or unavailability.
• Monitoring the key's life-cycle is also important to ensure that the key has been created and deployed properly.

Conclusion

This article summarizes the phases that can ensure the generation and protection of keys, the practice of authentication, revocation, and erasure, and eventually protect the whole key lifecycle management. Appropriate management of cryptographic keys is essential for the operational use of cryptography. Best practices for key management have been around for decades, but their strict implementation has been somewhat lacking—until now, that is!

Costly, embarrassing, and brand-damaging data breaches have occurred with alarming regularity, whereas, in the past plaintiffs would have had weak regulation to arm themselves with. Now, at least in certain major jurisdictions (such as the European Union), there is a regulation with serious teeth (GDPR) that ensures no large company can ignore data protection (through strong cryptography) anymore. So expect the take-up of encryption to reach scales never before seen, which, of course, means large organizations must get their key management act together in short order.

This should be done with a centralized management system (to ensure clean and simple administration and auditing) but one that also allows maximum flexibility (remote log-in, asynchronous workflows, stateless operation), not forgetting best practice security (FIPS 140-2 Level 3 HSM-backed, dual control, strict separation of duties) to pass the strictest of compliance audits (PCI DSS, etc)

References and Further Reading

• 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:  The Start and Finish Line of the "Inishowen 100" Scenic Drive by courtesy of Andrew Hurley, Flickr (CC BY-SA 2.0)