EMC VMAX 100K, Product Manual

Page: 42 / 200

snapshots or remote sites. D@RE external key managers can be used with either a
FIPS 140-2 level 3 validated HSM, in the case of Gemalto SafeNet KeySecure, or FIPS
140-2 level 1 validated software, in the case of IBM Security Key Lifecycle Manager.
Encryption keys must be both highly available when they are needed, and tightly
secured. Keys, and the information required to use keys (during decryption), must be
preserved for the lifetime of the data. This is critical for encrypted data that is kept
for many years.
Encryption keys must be accessible. Key accessibility is vital in high-availability
environments. D@RE caches the keys locally so that connection to the Key Manager
is required only for operations such as the initial installation of the array, replacement
of a drive, or drive upgrades.
Key lifecycle events (generation and destruction) are recorded in the VMAX Audit
Log.
Key protection
The local keystore file is encrypted with a 256-bit AES key derived from a randomly
generated password, and stored in the Common Security Toolkit (CST) Lockbox,
which leverages RSA’s BSAFE technology. The Lockbox is protected using MMCS-
specific stable system values of the primary MMCS. These are the same SSVs that
protect Secure Service Credentials (SSC).
Compromising the MMCS’s drive or copying Lockbox/keystore files off the array
causes the SSV tests to fail. Compromising the entire MMCS only gives an attacker
access if they also successfully compromise SSC.
There are no backdoor keys or passwords to bypass D@RE security.
Key operations
D@RE provides a separate, unique Data Encryption Key (DEK) for each drive in the
array, including spare drives. The following operations ensure that D@RE uses the
correct key for a given drive:
l
DEKs stored in the VMAX array include a unique key tag and key metadata when
they are wrapped (encrypted) for use by the array.
This information is included with the key material when the DEK is wrapped
(encrypted) for use in the array.
l
During encryption I/O, the expected key tag associated with the drive is supplied
separately from the wrapped key.
l
During key unwrap, the encryption hardware checks that the key unwrapped
properly and that it matches the supplied key tag.
l
Information in a reserved system LBA (Physical Information Block, or PHIB)
verifies the key used to encrypt the drive and ensures the drive is in the correct
location.
l
During initialization, the hardware performs self-tests to ensure that the
encryption/decryption logic is intact.
The self-test prevents silent data corruption due to encryption hardware failures.
Audit logs
The audit log records major activities on the VMAX3 array, including:
l
Host-initiated actions
l
Physical component changes
l
Actions on the MMCS
l
D@RE key management events
VMAX3 with HYPERMAX OS
42 Product Guide VMAX 100K, VMAX 200K, VMAX 400K with HYPERMAX OS