Encryption component description
The Encryption feature consists of three major components:
- Software licenses for Encryption License Key and FMD Encryption License Key
- Data at-rest encryption
- Key management
Software licenses
If you are using BED-based or controller-based encryption, the Encryption License Key software license must be installed and valid (not expired). If you are using the FMD-HDE drives, the FMD Encryption License Key software license is required. Note that an expired license can limit the operations that can be performed on an already configured storage system.
Data at-rest encryption (DARE) provided by Encryption License Key
For Encryption License Key, the data at-rest encryption (DARE) functionality is implemented using cryptographic hardware (chips), included as part of the encrypting back-end directors (EBEDs) for the VSP G1x00, VSP F1500, VSP G/F700, and VSP G/F900 models. For the VSP G/F350 and VSP G/F370 models, the cryptographic hardware is located on the encryption controller boards. The EBEDs or encryption controllers must be installed and configured before DARE can be used. These hardware components encrypt and decrypt data as it is being written to or read from the physical drives.
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 EBED, it is recommended to encrypt all parity groups on an EBED. It is also important to note that different spare drives are used for encrypting and non-encrypting parity groups.
Data at-rest encryption (DARE) provided by FMD Encryption License Key
The FMD-based DARE functionality is implemented using cryptographic hardware (chips) that reside on the FMD-HDE drives themselves. The FMD-HDE drives encrypt and decrypt data as it is being written to or read from the drives, and the drives must be installed and configured before DARE can be used.
As with Encryption License Key, FMD-based DARE is implemented at the parity group level. The FMD-HDE parity groups can be configured on regular (nonencrypting) BEDs or EBEDs. When the FMD-HDE drives are configured on an EBED, encryption and decryption are performed by the FMD-HDE drives. The spare drives for FMD-HDE parity groups must be FMD-HDE drives.
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 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 EBED requires a key for the encryption of the certificate (registration of the EBED) and a key to encrypt the DEKs stored on the EBED.
- 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 EBED 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.