This paper discusses the various phases in the life cycle of a cryptographic key, and how the operational life-time and key strength can be determined.
Initial consideration of key parameters and life-cycle phases
There are many factors to consider in the life-cycle of a key. With so many types of keys available (public, private, authentication, authorization, signing, verification, etc.), there are many questionable issues on how a key is properly generated, distributed, stored, replaced, deleted, and recovered during its life time, 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 amount of 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 life-cycle?
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 between data keys, also called primary keys and key-encryption-keys or secondary keys, used entirely to protect other keys.
Determination of the key’s operational life-time 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:
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 encrypting. 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.)
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.
Keys can be generated through the key manager or by a trusted third party, which must use a cryptographically secure random bit generator.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 life-time of the protected data, plus the ability to withstand attacks during this life-time. 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 (due to equipment failure or forgotten passwords, for example), 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 and 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. For manual distribution, keys must be distributed and loaded in key shares to avoid the full key being viewed in the clear. When symmetric keys are installed, it is recommended that they be encrypted by a public key or key-encryption key prior to being delivered for deployment. It is also advised that the a key be deployed and tested for a certain period of time to ensure that operations with the new key are successful, in order to avoid any potential data loss or theft.
Automated key distribution with CKMS
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 convert all stored, secured data to 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 off-line 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 half of an asymmetric key pair. Sometimes (depending on the situation), 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:
The importance of monitoring keys during their life-cycle
The key-management system should be able to handle most of the transitions between phases of a life-cycle, and should be capable of monitoring and keeping track of these work-flows.
There are certain aspects to monitoring that should be considered: