The period of time between the key activation and key deactivation is called the crypto period of the key. The crypto period is defined by factors such as the sensitivity of the data, the risk of key compromise, and the cost of new key generations.
Successful key management depends on proper usage of crypto periods in the key management system (KMS).
The KMS security policy should state the maximum allowable crypto period of keys that protect the data of the organization.
The KMS documentation should define and specify information regarding cryptographic keys and metadata elements. The metadata elements include details such as key type, crypto period for the key, generation method (RNG - Random Number Generator, Algorithms, key length). The KMS policy should specify the maximum allowable crypto period of key.
The value is defined based on multiple factors such as the sensitivity levels of the data. Similarly, the deactivation of cryptographic keys is determined mainly by crypto periods, amount of data or number of uses. There is no one answer for calculating an exact crypto period, security experts suggest that - as the sensitivity of data being protected by cryptography increase - the lifetime of crypto period decreases.
The archive of keys involves placing cryptographic keys in a safe, long-term storage facility so that they can be recovered when needed. Keys used to protect the keys and metadata in an archive are called archive keys. These archive keys will also have crypto-periods, and the continued protection provided to the archived keys needs to be considered when the crypto-period of the archive key expires.
Old storage media may become unreadable due to aging and technical issues. Archived keys should be recovered from the old storage medium and stored on a new storage medium. The keys should be destroyed on the old storage medium after the transfer. When performing key archival or destruction, applicable laws and regulations must be considered, so that the keys and/or metadata are available for the required period of time.
A key is generally given a deactivation date and time when it is created and distributed. In some instances, deactivation may also be based on the number of uses or the amount of data protected. Deactivation of key takes place based on crypto-period or lifetime of key. As discussed earlier, the KMS should specify the deactivation date-time for each key type. Similarly the Key Management System should also specify the process involved in the deactivation such as manual or automated process. As per the NIST SP 800-57 documentation, KMS design shall specify requirements for advance notification of the deactivation of the key type, including which KMS supported roles are notified, how they are notified, what security services are applied to the notification, and the time-frames for notifications.
If a key compromise is detected, then the compromised key and other keys whose security depends upon the security of the compromised key should be replaced as soon as possible.
A crypto key management system should limit the exposure of undetected key compromises by implementing a crypto-period for each key that it uses. At the end of each crypto-period, a new key could be established to replace the old key. When a new key is established and activated to protect new data, the old key should no longer be used to protect the new data. Thus, unless the compromise recurs with the new key, the new data will be protected.
Public key certificates contain a public key of an asymmetric key pair i.e the subject key and a validity period for that certificate. It may be desirable to have a public key validity period that is shorter than the subject key’s crypto period. This reduces the size of revocation lists and revocation information, but requires certificates to be issued more frequently.
Renewal establishes a new validity period for an existing subject public key beyond its previous validity period by issuing a new certificate containing the same public key with a new validity period. The sum of the renewal periods for a given public key must not exceed the crypto-period of the key.
NIST Special Publication 800-57 highlights multiple factors affecting the risk of exposure, such as:
The NIST framework provides useful guidelines for developing a crypto key management policy in order to protect your data. Depending on the data being protected, some industry standards will apply to the secure management of keys and may also have clearly defined crypto periods that you must comply with. In order to achieve compliance with such regulations, the important part is to be able to show evidence that you always enforce the crypto periods of the keys as stated in your key management policy.
NIST Special Publication 800-130 - A Framework for Designing Cryptographic Key Management Systems (2013) by E. Barker, M.Smid, D. Branstad, S. Chokhani