Securing the Life-cycle of a Cryptographic Key

This article discusses the main phases involved in the life-cycle of a cryptographic key, and how the operational lifetime of a key and its strength can be determined. It also looks at some driving forces to automate key management.

Importance of Key Life-cycle 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 over its life-cycle, 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 life-cycle 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.

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 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

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.

Automating Key Management

Costly, embarrassing and brand-damaging data breaches have occurred with alarming regularity and further emphasize the need to have keys managed in a professional, secure and highly automated way.

Whatever the situation, the case for introducing a new key management system will typically depend on the prevalent forces of change:

• RISK: If your organization has suffered from key compromises in the past, or perceives the risk and cost of such compromise as sufficiently high as to be potentially catastrophic, then the main business driver will probably be risk reduction. The business case will point towards a solution that minimizes the overall risk profile, and the justification will be the avoidance of fines, law suits, financial loss and reputational damage that could, in the worst case, destroy the business.

• COMPLIANCE: If your organization is struggling to comply with regulations and pass audits, then compliance is likely to be the main driver. Failure to comply with regulations can result in fines (which are becoming increasingly severe), loss of business licence and reputational damage, so the business case will suggest a solution that simplifies compliance and makes audits easier.

• DIGITIZATION: If your organization is going through significant IT transformation, then support for the new systems and key migration are likely to be the main drivers, and the business case will select a solution that provides the necessary technical capabilities.

• SCALABILITY & COSTS: If the number of keys being managed is growing rapidly (as it is in most organizations) and managing them is becoming an increasingly labor-intensive and costly exercise for the organization, then cost reduction is going to be the main driver, and the business case will call for the solution that offers the lowest total cost of ownership.

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). Read more on selection criteria. for a suitable key management system.

Conclusion

This article summarizes the phases which can ensure the secure generation & protection of keys, the practice of authentication, revocation, and erasure, eventually protecting the whole life-cycle of the keys. Appropriate management of cryptographic keys is essential for the operative use of cryptography. Automated key management is the best bet to master the diverse threats in a secure, effective, compliant and auditable way.

An earlier version of this article was published on this website in March 2018.

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