How to define appropriate Crypto-periods for Cryptographic keys

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.

Crypto-periods for keys

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.

Archive key state

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.

Deactivated key state

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.

Key compromises

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 renewal and crypto periods

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.

Risk affecting crypto periods

NIST Special Publication 800-57 highlights multiple factors affecting the risk of exposure, such as:

• The strength of the cryptographic mechanisms such as the algorithm, key length, and mode of operation
• The operating environment such as open office environment or publicly accessible terminal
• The volume of information flow or the number of transactions
• The security life of the data
• The security function such as data encryption, digital signature, and key protection
• The number of copies of a key and the distribution of those copies

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.  

Image: "clock", courtesy of Scott Riggle, Flickr (CC BY 2.0)

 Reference and further reading

NIST Special Publication 800-130 - A Framework for Designing Cryptographic Key Management Systems (2013) by E. Barker, M.Smid, D. Branstad, S. Chokhani