Encryption is the process of transforming data to make it unreadable to anyone except those possessing specialized knowledge. Self-Encrypting Drives (SEDs) in a VNXe system use AES-256 bit encryption. The encryption is done within each drive before the data is written
to the media. This protects the data on the drive against theft, hardware loss, and attempts to read the drive directly by physically de-constructing the drive using methods such as a drive recovery service. The encryption also provides a means to quickly and securely erase information on a drive without the need to overwrite it multiple times in order to ensure that the information is not recoverable.
Reading encrypted data requires the authentication key for the SED to unlock the drive.
Only authenticated SEDs will be unlocked and accessible. Once the drive is unlocked, the SED decrypts the encrypted data back to its original form.
Self-Encrypting Drives
VNXe systems support data at rest encryption through the use of Self-Encrypting Drives (SEDs). All data on a SED is encrypted by the data encryption key that is stored on the drive. Encryption is set at the factory before shipment and cannot be reversed once set.
The SED encryption/decryption process is transparent and automatic, and does not degrade performance.
Access control to a SED is enforced through the use of an authentication key. The authentication key is used to lock/unlock the drive and to encrypt/decrypt the data encryption key that is stored on the drive. On power-cycle, a SED that is part of a user-defined storage pool comes up in a locked state and does not permit access. The authentication key is used to unlock the drive and to gain access to user data.
An embedded Key Manager on the storage processor (SP) provides key management for the authentication key. Key management responsibilities include:
◆ authentication key generation
◆ secure key storage
◆ self-managed key life cycle
◆ synchronization of redundant key copies
A VNXe system contains either all SEDs or all non-self-encrypting drives. You cannot add a non-self-encrypting drive to a VNXe SED system. If you try to do this, the system raises an error. Likewise, you cannot add a SED to a VNXe non-self-encrypting drive system.
Secure array
A secure array is one that can only have SEDs installed in the array. You cannot intermix SEDs with non-encrypted drives in a VNXe. All SEDs in the VNXe are unlocked by default and only become locked once a storage pool is associated with them. An authorization key is created and applied to all drives while locking them and is required for any future interactions. Conversely, if all storage pools associated with a drive are destroyed, all the data on the drive is cryptographically destroyed (authorization key is deleted, making the data unrecoverable) and the drive is unlocked.
Once a SED is included in a storage pool, access control is enabled and the authentication key is set. The drive may then be used only with the authentication key stored on the
Data-at-rest-encryption 39
array. User data on the drive will not be accessible on a different array or externally.
With the exception of the first four drives in the Disk Processor Enclosure (DPE), a drive may be re-purposed for use on another array by destroying any storage pool it may belong to. Destroying the storage pool will cryptographically erase any user data on the drive, disable access control on these drives, and reset all passwords to the manufacturer's secure ID. Drives that do not belong to a storage pool do not hold user data and do not have access restrictions. These drives may be moved without issues.
If you inadvertently delete a storage pool with a drive missing, that drive will remain inaccessible until it is reverted to the factory default. Reverting a drive cryptographically erases the data on the drive and disables authentication. To revert a SED to its factory default, use the svc_key_restore service command. For information on this service command, see the technical notes document, VNXe Service Commands. For additional information and help to revert a SED to the factory default, contact your service provider.
When a new SED is introduced in the VNXe, either as a replacement of an existing drive or as a part of an array expansion, it is automatically detected and included in the array.
If the new drive replaces an old drive that was a part of a storage pool, access control will be enabled and the authentication key will be set on the new drive.
Note:Removing drives can degrade storage pools and reduce the redundancy of that storage pool.
With regards to a system with SEDs, certain hardware part replacements impact SED operation:
◆ Replacing both SPs and the chassis at the same time is not supported. The authentication key will become inaccessible.
EMC highly recommends that you back up the authentication key to an external drive as soon as the key is created. If the master copy of the authentication key is missing or corrupted, the data stored on the system will become inaccessible. For instructions to back up the authentication key, refer to the VNXe Unisphere online help or the VNXe Unisphere CLI User Guide .
◆ Array conversion, in which all the drives are removed and inserted in a new array, is not supported.
Authentication key
The Key Manager randomly generates the authentication key for SEDs automatically the first time you create a storage pool on a VNXe SED system. The same authentication key will apply to all drives in the VNXe system, including those added to the system later on.
VXNe encrypts the authentication key and stores it in a secured area on the system drive under a triple mirrored redundancy scheme. You can back up the authentication key to an external device by using either a Unisphere UI option or Unisphere CLI command.
EMC highly recommends that you back up the authentication key to an external drive as soon as the key is created. If the master copy of the authentication key is missing or corrupted, the data stored on the system will become inaccessible. For instructions to back up the authentication key, refer to the VNXe Unisphere online help or the VNXe Unisphere CLI User Guide .
If you receive an alert for a corrupt authentication key, you must restore the key. Place both SPs in the VNXe into service mode and run the svc_key_restore service command on one of the SPs in the VNXe.
Note:For instructions for placing SPs into service mode, refer to the VNXe Unisphere online help.
For information about the svc_key_restore service command, see the VNXe Service Commands Technical Notes .
With the following exception, if all the storage pools on the VNXe system are deleted, the master copy of the authentication key will also be deleted. However, if you reinitialize a system containing storage pools, the authentication key will still be valid when the system comes back up, even though the storage pools were deleted.
The backup authentication keys are useless after all the storage pools on the VNXe system are deleted (with the exception of reinitializing a system containing storage pools). When the first new storage pool is subsequently created, a new master copy of the authentication key is automatically generated. In this case all existing backup authentication keys of the previous authentication key are invalid, and a new backup authentication key should be made.
Data-at-rest-encryption 41