5 Things to Know About Managing Encryption Keys for Self-Encrypting Drives in Lenovo System x Servers
AxelBuecker 270000KUKR Visits (12248)
Data security is one of the paramount requirements for organizations of all sizes today. Although many have invested heavily in protection from network based attacks and other threats, only a few effective safeguards are available to protect against potentially costly exposures of proprietary data that result from a hard drive being stolen, misplaced, retired, or redeployed.
Self-encrypting drives (SEDs) can satisfy this security deficit by providing the ultimate in security for data-at-rest and can help reduce IT drive retirement costs in the data center. Self-encrypting drives are also an excellent choice if you need to comply with government or industry regulations for data privacy and encryption.
To effectively manage a large deployment of SEDs in System x servers, an organization has to rely on a centralized key management solution. The IBM Redbooks publication, "Cen
To give you a good overview of these security technologies, I would like to introduce the following 5 key concepts:
Self-encrypting drives (SEDs) are Serial Attached SCSI (SAS) hard drives that include an Advanced Encryption Standard (AES) processor that encrypts data dynamically at the drive level. Encrypting at this level avoids the performance overhead and ongoing maintenance of software based encryption approaches. With SEDs, the data is always encrypted (using a random AES key) on the physical disk. This Media Encryption Key (MEK) is stored in a hidden section of the disk at the time of manufacture. SEDs not only protect the data, they also reduce drive retirement and redeployment costs through instantaneous cryptographic erasure. This cryptographic erasure is done through changing the MEK, as opposed to multi-pass data write approaches (which can take days for a multi-terabyte drive). Self-encrypting drives are also an excellent choice if you need to comply with government or industry regulations for data privacy and encryption.
2. Local and centralized key management
The data on SEDs is always encrypted (using MEK). Controlling access to data on SEDs can be done after initial server deployment without impacting the data on the drive. You can either utilize local or centralized key management for your SEDs. These local and centralized key management approaches provide tools where the MEKs on SEDs in a RAID configuration are encrypted using a Key Encryption Key (KEK). Implementing key management post the initial deployment of the server with the SEDs does not change the encrypted data on the drives or the MEK. Rather, key management introduces additional logic as part of the server boot process to decrypt the MEK using the KEK so that I/O to the drives is possible.
3. Key management options for SEDs
There are three options for managing access to the Media Encryption Keys on SEDs:
a. No key management
The SED is in essence treated like a normal hard drive. The data on the SED is encrypted using the MEK, but if the drive were stolen, the data is not protected (as there are no controls for the drive decrypting the data as it is read). This option still provides the benefits of cryptographic erasure through changing the MEK.
b. Local key management
The server's RAID adapter configuration utility provides several options for controlling access to the SEDs by encrypting MEKs using a KEK, which is defined for each individual server. This approach may be suitable for deployments with a smaller number of servers where keeping track of the KEKs would not be an onerous task. Data on the drive is only available if the KEK is provided at the boot time of the server.
c. Centralized (external) key management (depicted in the figure above)
At boot time, the System x server with SEDs interacts with an external key manager (for example, IBM Security Key Lifecycle Manager). This interaction acquires the KEK needed to decrypt the MEKs to gain access to the SEDs. Centralized key management is scalable and IT organizations no longer have to keep track of the KEKs manually. Centralized key management also provides key management support for a wide range of device types, enabling System x servers to be included in a much larger security key management strategy.
4. Transitioning to centralized key management
System x servers support the transition from local key management to centralized key management without impacting the data on the SEDs. The RAID adapter configuration utility provides the means to change from local to external key management. When exiting the utility, the user is prompted to reboot to make the changes effective. On the next boot up, the server firmware will request a new KEK from the external key manager, which is then used to encrypt/decrypt the MEKs on the individual drives.
5. Supported environments
SEDs are supported on System x servers with the MegaRAID SafeStore feature. The SafeStore feature is included with any RAID 5 Feature on Demand or cache/flash hardware upgrade and is available on specific ServeRAID adapters. IBM Security Key Lifecycle Manager centralized key management support is available with the purchase of a Feature on Demand option (which turns the SKLM support on in the System x firmware).
In the IBM Redbooks publication, "Cen
Andy Ehrenzeller is an Executive Project Manager for Lenovo System x Solutions Offerings