Monitoring the lifecycle of encryption keys in Unified Key Orchestrator

IBM Cloud® Hyper Protect Crypto Services follows the security guidelines by NIST SP 800-57 for key states.

Key states and transitions

Managed keys in Unified Key Orchestrator transition through several states that indicate how long the keys are in existence and whether data is protected.

The following diagram shows how a managed key passes through states between the generation and the destruction.

The following table shows the details of each key state.

Table 1. Key states and transitions
State	Integer mapping	Description
Pre-active	0	A Pre-active key is not yet activated in keystores and is therefore not available for use by applications. New keys are initially created in the Pre-active state.
Active¹	1	An Active key is activated in keystores and is available for use by applications. If the key is used to protect associated resources, the key will be accessible to its associated resources and can be used for data protection. You can set a key to the Active state when you create the key, or manually activate a Pre-active key later.
Deactivated	3	A Deactivated key is no longer allowed for operations that generate new cryptographic data, such as encryption or signing, but can still be used for operations on existing data to do decryption or signature verification. When you deactivate a key, the key is unlinked from all the keystores, and not accessible to all associated resources and their data. However, you can still reactivate the key so that it is accessible to the resources again.
Destroyed²	5	A Destroyed key is a key record for which the actual key material has been permanently erased. The record of the key is retained to be available for later queries or audits until you manually remove the key from the vault. You cannot restore keys in Destroyed state.

1: If the key state in some keystores is different from the managed key state, you receive a Key out of sync warning message. An Out of sync flag is also displayed in the corresponding keystore card or the key list. There can be multiple reasons why the key is out of sync. For example, there is an issue in relinking the key in the keystore,the key is failed to be destroyed in some of the distributed keystores, or the key is modified in the target keystore outside of Unified Key Orchestrator. You can sync the key state by clicking Sync key on the Key details page.

2: After you move a key from Deactivated to Destroyed state, the key will first be pending on destruction for a time period defined by the destruction policies of the external cloud providers. When the time period ends, the key will be moved to Destroyed state. For any pending destruction keys, a pending flag is displayed in the corresponding key card or the key list. Refer to the following table for detailed destruction policies of keystores.

Table 2. Key destruction policies
Keystore type	Key pending destruction policy	Pending period customizable on the external cloud provider side? (Yes/No)
AWS keystore	7 days	No
Azure Key Vault	90 days	Yes
Google Cloud KMS keystore	30 days	Yes
IBM Cloud KMS keystore	30 days	No
Key Protect	30 days	No

For Azure Key Vault and Google Cloud KMS keystore, you can customize the pending destruction time period if you want to on the external cloud provider side. If you apply different customized pending destruction periods to more that one keystore that the key is distributed to, the pending destruction period of the key will also vary based on your settings. For more information about customizing destruction pending policies, see the following topics:

You cannot cancel pending destruction using the Unified Key Orchestrator UI or API. However, you might still do so through the third-party keystores that the keys are created in. For more instructions, check out the following links:

Key states and service actions

Key states affect whether an action that you perform on a key succeeds or fails. For example, if a managed key is in the Active state, you cannot destroy the key before you deactivate it first.

The following table shows how Unified Key Orchestrator handles service actions based on the state of a key. The column headers represent the key states, and the row headers represent the actions that you can perform on a key. The Checkmark icon indicates that the action on a key is expected to succeed based on the key state.

Table 3. How key states affect service actions
Action	Pre-active	Active	Deactivated	Destroyed
Get a key.
List keys.
Rotate a key.
Deactivate a key.
Reactivate a key.
Destroy a key.
Remove a key from vault.

Monitoring for lifecycle changes

After you add a managed key to the service, use the UI or the Unified Key Orchestrator API to view your key's transition history and configuration.

For audit purposes, you can also monitor the activity trail for a managed key by integrating Hyper Protect Crypto Services with the IBM Cloud Activity Tracker. After both services are provisioned and running, activity events are generated and automatically collected in an IBM Cloud Activity Tracker log when you perform actions on keys in Hyper Protect Crypto Services.

What's next

To find out instructions on creating a managed key, check out Creating managed keys.
To find out instructions on editing a managed key, check out Editing key details.
To find out more about managing your key list, check out Viewing a list of keys or Filtering and searching keys.
To find out instructions on deleting a managed key, check out Deleting managed keys.
To find out more about the UKO API, see Unified Key Orchestrator API reference.