Encryption License Key component description
The Encryption License Key feature consists of three major components:
- Encryption License Key software license
- Data at-rest encryption
- Key management
Encryption License Key software license
A valid (not expired) Encryption License Key software license must be installed before the Encryption License Key feature can be used. Note that an expired license can limit the operations that can be performed on an already configured storage system. The Encryption License Key software license is provided by Hitachi.
Data at-rest encryption (DARE)
The data at-rest encryption (DARE) functionality is implemented using cryptographic hardware (chips), included as part of the encryption disk adapters (encryption DKAs), which must be installed and configured before DARE can be used. These DKAs perform the I/O to the drives as well as encrypting and decrypting data as it is being written to or read from a physical drive.
Enabling and disabling DARE is controlled at the parity group level (that is, all drives in a parity group are either encrypting or non-encrypting). While it is possible to have both encrypting and non-encrypting parity groups configured on an encryption DKA, it is recommended to encrypt all parity groups on an encryption DKA. It is also important to note that different spare drives are used for encrypting and non-encrypting parity groups.
Key management
Data security provided by encryption is only as good as the generation, protection, and management of the keys used in the encryption process. Further, encryption keys must be available when they are needed while being protected from possible compromise (for example, unauthorized access or destruction). To address these issues and meet a wide range of requirements associated with key management, the Encryption License Key feature includes multiple options associated with key management.
It is important to understand what keys the storage systems use and the roles these keys play in the DARE solution. There is a hierarchy of keys that include:
- Data encryption keys (DEKs): Each encrypted internal drive is protected with a unique DEK that is used with the AES-based encryption. AES-XTS uses a pair of keys, so each key used as a DEK is actually a pair of 256-bit keys.
- Certificate encryption keys (CEKs): Each encryption DKA requires a key for the encryption of the certificate (registration of the encryption DKA) and a key to encrypt the DEKs stored on the encryption DKA.
- Key encryption keys (KEKs): A single key, the KEK, is used to encrypt the CEKs that are stored in the system.
Managing these keys in a secure manner is a critical aspect of the Encryption License Key feature. This key management functionality controls the full key lifecycle, including the generation, distribution, storage, backup/recovery, rekeying, and destruction of keys. In addition, the design of this key management functionality includes protections against key corruption (for example, integrity checks on keys) as well as key backups (both primary and secondary).
After the key generation source (storage system or key management server) has been established in the initial encryption setup, the initial set of keys is generated. The number of generated keys depends on the storage system model. Any keys that are not assigned will be designated as free keys and will be available for use.
When encryption is enabled for a parity group, DEKs are automatically assigned to the drives in the parity group. Similarly, when encryption is disabled, DEKs are automatically replaced (old DEKs are destroyed, and keys from the free keys are assigned as new DEKs). You can combine this functionality with migrating data between parity groups to accomplish rekeying of the DEKs.
The key management can be configured in a stand-alone mode (integrated key management), or key management can be configured to use third-party key management (external key management). When external key management is leveraged, some or all the following functionality can be used:
- Initial and/or subsequent generation of keys used as CEKs and DEKs
- Generation and protection of KEKs
- Manual and automated backup of keys to a key management server (KMS)
- Restoration of keys from a key backup on a KMS
All communications with a KMS are performed using the OASIS Key Management Interoperability Protocol (KMIP) version 1.0 over a mutually authenticated Transport Layer Security (TLS) version 1.2 connection. The TLS authentication is performed using X.509 digital certificates for both the storage system and two cluster members of the KMS.
In addition to using the KMS for certain transactions (for example, generation of keys, key backups, and key recoveries), the storage systems can be configured to be dependent on the availability of the KMS. This dependency is achieved by protecting the KEK on the KMS, which means that the storage system must retrieve the KEK from the KMS as part of its boot-up sequence. If the KEK cannot be retrieved from the KMS, the storage system will not fully boot. This configuration is reversible (that is, you can change back to integrated key management) unless you configure the storage system in a special mode called KMIP-lock mode. When you configure the storage system in KMIP-lock mode, local key generation is prevented and the configuration cannot be changed back to allow local key generation.
Under a typical configuration, the storage systems store an encrypted copy of the CEKs and DEKs in shared memory. A primary backup (encrypted) of these keys is also made on the flash memory of every encryption DKA installed in the storage system. When the storage system boots, the keys in shared memory are used unless they are missing or corrupted, at which point one of the primary backups is used. This is the default behavior even when a KMS is used to protect the KEK.
It is also possible to generate secondary backups of the keys either to a key file or on a KMS. Generating secondary backups of the keys on a KMS is the only way to ensure that CEKs and DEKs are stored on a KMS. These secondary key backups can be used to recover keys when the keys are not available in the storage system (for example, when the storage system has been configured to purge all CEKs and DEKs at shutdown). If secondary key backups will be used, it is important that they contain the current CEKs and DEKS, and this is simplified with a KMS because secondary key backups are automatically performed after certain key operations (for example, generating keys) and/or by leveraging regular (automated) key backups. Note that automatic key backups have been optimized such that they are only performed when the CEKs and DEKs have changed.