The data-at-rest encryption feature, called Encryption License Key, protects your sensitive data against breaches associated with storage media (for example, loss or theft). Encryption License Key provides a controller-based encryption implementation.
The Encryption License Key feature provides the following benefits:
- Hardware-based Advanced Encryption Standard (AES) encryption, using 256-bit keys in the XTS mode of operation, is provided.
- Encryption can be applied to some or all supported internal drives.
- Each encrypted internal drive is protected with a unique data encryption key (DEK).
- Encryption has negligible effects on I/O throughput and latency.
- Encryption requires little to no disruption of existing applications and infrastructure.
- Cryptographic erasure (media sanitization) of data is performed when an internal encrypted drive is removed from the storage system.
- Encryption hardware
- The data at-rest encryption (DARE) functionality is implemented using cryptographic hardware (chips) on the encrypting controllers (ECTLs) of the VSP One Block storage systems. The ECTLs encrypt and decrypt data as it is being written to and read from the cache memory.
Enabling and disabling data encryption is controlled at the dynamic-drive-protection (DDP) group level. All drives in a DDP group (parity group) are either encrypting or non-encrypting. While it is possible to have both encrypting and non-encrypting DDP groups configured on an ECTL, best practice is to encrypt all DDP groups on an ECTL.
- Key management
- Key management for VSP One Block is integrated within the storage system. 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. The DEKs are stored in the shared memory of the storage system. When the storage system boots, the DEKs in shared memory are used.
The initial set of encryption keys is generated during the initial encryption setup. Any keys that are not assigned to drives are designated as Free keys and will be available for use. Encryption keys are generated with the Free (unused) attribute, and the attribute is changed depending on the use of the key:
- DEK: Data encryption key. A key used to encrypt stored data.
- KEK: Key encryption key. The key used to encrypt the other keys. There is only one KEK in the storage system.
When encryption is enabled for a DDP group, DEKs are automatically assigned to the drives in the DDP 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 DDP groups to accomplish rekeying of the DEKs.
- Key management server (KMS)
- You can use encryption keys created by a KMS that conform to the Key Management Interoperability Protocol (KMIP) standard. In addition, you can back up encryption keys to a KMS and restore encryption keys from the backups on the KMS. When an encryption key is backed up to a KMS, it is encrypted with another encryption key and stored with that encryption key on the KMS.
- Primary backup
- The storage systems store an encrypted copy of the DEKs in shared memory. A primary backup (encrypted) of these keys is also made on the flash memory of the ECTLs in the storage system. When the storage system boots, the DEKs in shared memory are used. If the DEKs in shared memory are missing or corrupted, the primary backups on the ECTLs are used.
- Secondary backup
- Secondary backup of encryption keys is performed by the user using the REST API. For this reason, it is the responsibility of the user to store the secondary encryption key backup. If the primary backup becomes unavailable, a secondary backup is required to restore the encryption keys. To perform a secondary backup, a dedicated user role, Security Manager (View & Modify), is required.CAUTION:If the primary backup becomes unavailable and no secondary backup exists, the system cannot decrypt the data.
You can make secondary backups of the keys to a key file on the management client or to a KMS. If secondary backups are used, it is important that they contain the current DEKs. Make sure to perform secondary key backups after operations such as generating keys. If the encryption environment is set to connect to a KMS, the keys cannot be backed up as a file on the management client.
When backing up by connecting to a KMS, the number of keys that can be backed up to the KMS is one generation, including secondary backup and automatic backup. The old keys are overwritten during backup. Encryption keys are backed up against the already created encryption keys.
Important: The creation and secure storage of backup keys must be included as part of your corporate security policy. To ensure data availability, back up the encryption keys immediately after they are created and also after each hardware maintenance in which a drive or ECTL is replaced. You are responsible for storing the secondary backup keys securely. - Automatic backup (KMS only)
- If you are using a KMS, the encryption keys are automatically backed up after they are created. This is called the automatic backup. The number of keys that can be backed up to the KMS is one generation, including the secondary backup and automatic backup. The old keys are overwritten during backup.
If you are not using a KMS, automatic backups are not performed.
- Restoring encryption keys
- If an existing encryption key becomes unavailable, for example, due to a failure, the encryption key is restored from the primary backup or secondary backup.
- Restoring an encryption key from the primary backup is done automatically by the storage system.
- Restoring an encryption key from the secondary backup is performed by the user. To restore an encryption key from the latest secondary backup, the Security Manager (View & Modify) user role is required. To restore an encryption key from a secondary backup that is not the latest, the Security Manager (View & Modify) role and the Maintenance (Vendor Only) role) are required.
- Decrypting data
- To decrypt an encrypted DDP group, you can delete the DDP group. When you delete an encrypted DDP group, the encryption keys for the drives in the group are deleted and new encryption keys are assigned.CAUTION:Care must be taken when decrypting data. You are responsible for backing up any required data in a DDP group before decrypting it. Alternatively, decrypt the entire DDP group before formatting it, such as when adding a DDP group or formatting using the LDEV format feature.
- Audit logging
- The Audit Log feature provides logging of events that occur in the storage system, including events related to encryption and data encryption keys. You can use the audit log to check and troubleshoot encryption key generation and backup. For details about audit logging and audit log events, see the VSP One Block System Administrator Guide.
- Key usage for maintenance operations
- Encryption keys are used when the following operations and maintenance tasks are performed.
Operation or maintenance task Number of keys used* Notes Adding drives 1 per drive You will need one unused key for each drive being added. Replacing drives 1 per drive You will need one unused key for each drive being replaced. Deleting an encryption-enabled DDP group 1 per drive You will need one unused key for each drive in the DDP group being deleted. * If a failure occurs during the above operations or maintenance tasks, more than the above number of unused keys might be required for recovery.