KEKs with KMIP
A Key Encryption Key (KEK) provides an extra layer of security by encrypting all individual KMIP objects in a KMIP Vault. The KEK is created in your HSM for each KMIP vault and wraps all KMIP objects in the vault. Both the KEK and KMIP Vault must be available before a KMIP client can access the KMIP Vault.
To protect the KEK, KeyControl requires that the KEK be stored in the hardware security module (HSM) associated with this KeyControl cluster. If the HSM is not available, then the KMIP objects in the KMIP Vault protected by the KEK cannot be accessed. If you decide to associate a KEK with KMIP, it is imperative that the HSM be available to the KeyControl at all times.
KeyControl uses the AES-GCM algorithm for encrypting and decrypting KMIP Vaults. Each KMIP object will be encrypted with a unique key derived from the KEK. The KEK can be cached in KeyControl kernel memory by specifying the KEK cache timeout.
The KEK also provides a way to control the accessibility of all KMIP objects with a single command. If the KEK is revoked on the HSM, then all KMIP objects become inaccessible after the specified KEK cache timeout.
For information on configuring an HSM, see Hardware Security Modules with KeyControl.
Considerations
- The HSM must be available before you can enable KEK for KMIP objects.
- After you enable KEK for KMIP objects, the HSM must be available anytime a KMIP object is accessed by a KMIP client.
-
KMIP KEK can be enabled or disabled at any time.
- When KMIP KEK is disabled, all KMIP objects will be decrypted. Key material will continue to be accessible.
- If KMIP KEK is enabled and the HSM is disabled or unavailable, key material will not be accessible, but the UUID entries continue to be visible in WebGUI and object state can be changed.
-
KMIP objects will remain accessible when encryption or decryption is in progress.