About Key Lifecycles
Keys undergo a lifecycle based on the key policy. A key will transition to multiple states throughout its lifecycle.
Encryption and Crypto Periods
The lifecycle imposed by the OKM is based on the NIST 800‐57 guidelines. A few additional states are added to deal with nuances of the OKM. The encryption period is the period after a key is assigned that can be used to encrypt data. The cryptoperiod is the period that can be used for decryption. The two periods start at the same time when the key is assigned.
Key States and Transitions
- Pre-activation
-
This state indicates that the key has generated but is not yet available for use. Within the pre-activation state, the key can take two further states:
- Generated — Indicates a key that has been created on one KMA in a OKM cluster. It remains generated until it has been replicated to at least one other KMA in a multi-OKM cluster. In a cluster with only a single KMA, a key must be recorded in at least one backup to transition out of the generated state.
- Ready — A ready state indicates that the key has been protected against loss by replication or a backup. A ready key is available for assignment. The "replicated" transition occurs when the key is replicated or (for a single OKM cluster) backed up.
- Active
-
This state indicates that the key may be used to protect information (encrypt) or to process previously protected information (decrypt) NIST states that an active key may be designated to protect only, process only, or protect and process. Further, it specifically states that for symmetric data encryption keys, a key may be used for some time period to protect and process information and once this time period expires, the key may continue to be used for processing only.
Within the active state, the OKM adds two substates. These states are described in NIST, but are not specifically identified as states.
- Protect-and-process — A key in this state can be used for both encryption and decryption. A key is placed into this state when it is assigned. The assignment is done when an encryption agent requests a new key to be created.
- Process only — A key in this state can be used for decryption but not encryption. When an agent determines that none of the keys available to it for a specific data unit that is being read or written are in the protect-and-process state, it should create a new key.
Keys move from the protect-and-process state to the process only state when the encryption period for the key expires.
- Deactivated
-
This state indicates that the key has passed its cryptoperiod but may still be needed to process (decrypt) information. NIST specifically states that keys in this state may be used to process data.
The NIST guidelines state that if post-operational keys, including deactivated and compromised keys, need to remain accessible, they should be archived. This is a key recovery process that allows keys to be recalled from an archive and made available for use.
The OKM provides archives in the form of KMA backups but cannot recall a single key from a backup. Therefore, the OKM retains post-operational phase keys in the OKM cluster and delivers them upon request from an agent.
- Compromised
-
Keys are in the compromised state when they are released to or discovered by an unauthorized entity. Compromised keys should not be used to protect information, but may be used to process information.
- Destroyed/Destroyed Compromised
-
Destroyed and Destroyed Compromised keys (keys that are compromised before or after destruction) no longer exist. However, information about the key may be retained. Key material from destroyed keys is removed from the OKM cluster. Destroyed keys will not be delivered to an agent.
Note:
The only way to destroy a key is through the GUI or the management API.
The NIST guidelines do not provide any basis for destroying keys based on time.
Within the Destroyed and Destroyed Compromised states, the OKM defines two substates, incomplete and complete. These states are created because the OKM does not control the backups that it creates. A customer administrator must inform the OKM when a backup has been destroyed. Only after all backups have been destroyed can a key be considered truly destroyed.
-
Incomplete — An Incomplete substate indicates that at least one backup still exists that contains the destroyed key. In this substate, the key does not exist in any KMA in the OKM cluster. Keys in this state cannot be delivered to agents.
-
Complete — A Complete substate indicates that all backups containing the key have been destroyed. The key does not exist in any KMA, nor in any backup. Strictly speaking, backups that contain the key may well still exist. Although the OKM identifies the backups as destroyed, it is the responsibility of the user to ensure these backups have actually been destroyed.
It is worth noting again that the "destroyed" transition occurs only as the result of an administrative command. Further, keys may still be delivered to an encryption agent when the key is in the post-operational phase (Deactivated and Compromised states). This interpretation is consistent with NIST's descriptions for the post-operational phase. The NIST guidelines specify that a post-operational key should be destroyed when it is "no longer needed." We believe that only you can determine when a key is "no longer needed," so only an external entity can initiate the destroyed transition.
-
In diagram below, states and transitions shown in red are added by the OKM. When examining keys in the OKM Manager, only the innermost state is listed.
