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
There are many factors to consider in the lifecycle of a key. Keeping in mind the types of keys (public/private and symmetric) and their corresponding usages (authentication, authorization, signing, verification, etc.), there are many potential issues relating to how a key is properly generated, distributed, stored, replaced, deleted, and recovered during its lifetime, and provided with adequate protection against threats. Other questions come up as to how long the life-cycle of the key should be (which can range anywhere from just a few minutes to one or more years), and the key strength needed to withstand attacks. And there are other questions like: Who shall take care of the generation, usage, replacement, and other phases of the lifecycle?
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 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 its 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
The following paragraphs examine the phases of a key lifecycle and how a key management solution should operate during these phases. 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 pre-activation, activation, and post-activation.
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 keys, along with all their attributes, will then be stored in the key storage database (which must be encrypted by a master key). 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 it. A standard cryptographic algorithm is recommended that has been thoroughly evaluated and tested.
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 a 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 phase 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 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 viewed in the clear. Once the KEK is installed, data keys can then be shared securely since they can be encrypted (also known as 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 it 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 initial step of sharing a KEK using key shares is displaced by the simple technique of deploying a public key. 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 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/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 archived key can, if needed, be reactivated by an administrator. 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 life-cycle, 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 to 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.
This article summarizes the phases which can ensure the generation & protection keys, the practice of authentication, revocation, and erasure eventually protecting the whole key lifecycle management. Appropriate management of cryptographic keys is essential for the operative 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 and, whereas, in the past, plaintiffs would have weak regulation to arm themselves with. Now, at least in certain major jurisdictions (such as the European Union), there is 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 organisations 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
- Buyer’s Guide to Choosing a Crypto Key Management System - Part 1: What is a key management system (2018), by Rob Stubbs
- Buyer's Guide to Choosing a Crypto Key Management System; Part 2: The Requirement for a Key Management System (2018), by Rob Stubbs
- Buyer’s Guide to Choosing a Crypto Key Management System - Part 3: Choosing the Right Key Management System (2018), by Rob Stubbs
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)