Encryption component description

Encryption License Key User Guide

Version
9.8.7
Audience
anonymous
Part Number
MK-98RD9017-17

Encryption License Key consists of three major components:

  • Software license for Encryption License Key
  • Encryption hardware
  • Key management
Software license
The Encryption License Key software license must be installed on the storage system and valid (not expired). Note that an expired license can limit the operations that can be performed on an already configured storage system.
Encryption hardware
The data at-rest encryption (DARE) functionality is implemented using cryptographic chips included as part of the encryption hardware. The encryption hardware encrypts and decrypts data as it is being written to and read from the physical drives. These hardware components must be installed and configured before DARE can be used.
The encryption hardware depends on the storage system model as follows:
  • The VSP 5000 series models support SAS encrypting back-end modules (EBEMs), also called encrypting disk boards (EDKBs).
  • The VSP E1090 model supports encrypting controllers (ECTLs), SAS EBEMs, and NVMe EBEMs (also called EDKBNs).
  • The VSP E990 model supports NVMe EBEMs.
  • The VSP E590 and VSP E790 models support ECTLs and SAS EBEMs.
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 EBEM or ECTL, it is recommended to encrypt all parity groups on an EBEM or ECTL. 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 feature includes multiple options associated with key management.
It is important to understand the keys used by the storage system and the roles these keys play in the DARE solution. There is a hierarchy of keys that includes the following key types:
  • 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 encrypting back-end module or encrypting controller requires a key for the encryption of the certificate (registration of the EBEM/ECTL) and a key to encrypt the DEKs stored on the EBEM/ECTL.
  • 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 life cycle, 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 and configuration. 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 the encryption hardware installed in the storage system. When the storage system boots, the keys in shared memory are used. If the keys in shared memory are missing or corrupted, 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 performed automatically after certain key operations (for example, generating keys) and by regular (automated) key backups. Note that automatic key backups have been optimized so they are performed only when the CEKs and DEKs have changed.