^Back to Top
The Full Life-Cycle of Keys
The encryption key life-cycle, defined by NIST as having a pre-operational, operational, post-operational, and deletion stages, requires that, among other things, a operational crypto period be defined for each key. A crypto period is the “time span during which a specific key is authorized for use” and in Section 5.3 of NIST’s Guide, the crypto period is determined (for example, with a symmetric key) by combining the estimated time during which encryption will be applied to data (the Originator Usage Period (OUP)) and the time when it will be decrypted for use (the Recipient Usage Period (RUP)).
So, as an example:
- let’s say that a database is encrypted and for the next 6 months items are added to it. Then:
- the OUP is 6 months
- For 2 years the database is also viewed by authorized users. Then:
- the RUP is 2 years (and completely overlaps with the OUP)
- Therefore, the crypto period would equal 2 years and the encryption key would need to be active during that time.
But, since an organization may reasonably want to encrypt and decrypt the same data for years on end, other factors may come into play to when factoring the crypto period:
Maybe you are interested: Cryptocurrency vs. Stocks: Understanding the Difference | Maryville Online
You may want to limit the:
- “amount of information protected by a given key”
- “amount of exposure if a single key is compromised”
- “time available for attempts to penetrate physical, procedural, and logical access”
- “period within which information may be compromised by inadvertent disclosure”
- “time available for computationally intensive cryptanalytic attacks”
This can be boiled down to a few key questions:
- How long will the data be used
- How is the data being used
- How much data is there
- How sensitive is the data
- How much damage will be done when the data is exposed or the keys are lost
The general rule: as the sensitivity of data being secured increases, the lifetime of an encryption key decreases.
Given this, your encryption key may have an active life shorter than an authorized user’s access to the data. This means that you will need to archive de-activated keys and use them only for decryption. Once the data has been decrypted by the old key, it will be encrypted by the new key, and over time the old key will no longer be used to encrypt/decrypt data and can be deleted. (see graphic below)
See below for a more thorough understanding of a keys full life-cycle.
Key Creation (Generation & Pre-Activation)
The encryption key is created and stored on the key management server. The key manager creates the encryption key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key storage database. The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, key access, and other attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. The encryption key manager should track current and past instances (or versions) of the encryption key. You need to be able to choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Your key manager should allow the administrator to change many of the key’s attributes at any time.
Key Use and Rollover (Activation through Post-Activation)
The key manager should allow an activated key to be retrieved by authorized systems and users for encryption or decryption processes. It should also seamlessly manage current and past instances of the encryption key. For example, if a new key is generated and the old one deactivated (or rolled) every year, then the key manager should retain previous versions of the key but dispense only the current instance and activate previous versions for decryption processes. Previous versions can still be retrieved in order to decrypt data encrypted with such versions of the key. The key manager will also roll the key either through a previously established schedule or allow an administrator to manually roll the key.
An administrator should be able to use the key manager to revoke a key so that it is no longer used for encryption and decryption requests. A revoked key can, if needed, be reactivated by an administrator so that, In certain cases the key can be used to decrypt data previously encrypted with it, like old backups. But even that can be restricted.
Back Up (Escrow)
NIST (Section 8.3.1) requires that an archive should be kept for deactivated keys. The archive should “protect the archived material from unauthorized [disclosure,] modification, deletion, and insertion.” The encryption keys need “to be recoverable … after the end of its cryptoperiod” and “the system shall be designed to allow reconstruction” of the keys should they need to be reactivated for use in decrypting the data that it once encrypted.
Key Deletion (Destruction)
If a key is no longer in use or if it has somehow been compromised, an administrator can choose to delete the key entirely from the key storage database of the encryption key manager. The key manager will remove it and all its instances, or just certain instances, completely and make the recovery of that key impossible (other than through a restore from a backup image). This should be available as an option if sensitive data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure and unrecoverable since it would be impossible to recreate the encryption key for that data.