Overview of SED support with TPM

This topic gives an overview of self-encrypting drives (SED) Support, Trusted Platform Module (TPM), and TPM as key management.

The self-encrypting drives (SED) support protects data at rest on IBM Storage Scale System 3200 drives. This support uses the crypto-erase feature to securely and quickly wipe data from drives during a recovery group delete.

The SED support for GPFS Native RAID (GNR) was introduced from IBM Storage Scale System 3200 6.1.5.0 with IBM® Security Guardium Key Lifecycle Manager (GKLM) as key management in IBM Storage Scale System 3200 systems. However, GKLM has the following limitations:

Supporting only GKLM for SED requires a separate, potentially expensive license.
Managing GKLM can be complex at times.
There is a request for more cost-effective and user-friendly key management for SED support.

IBM Storage Scale System 3200 6.2.2.0 release with IBM Elastic Storage® Scale System 6000, the SED support for GNR using the TPM key management is supported to address the previously mentioned limitations.

TPM overview

A Trusted Platform Module (TPM) is a cryptographic coprocessor present in the system board of modern PCs and servers. It is a specialized hardware security chip that provides secure cryptographic functions. TCG (Trusted Computing Group) defines the TPM specifications. TPM 2.0 is the latest standard. Some of the key features are secure storage, encryption and decryption, platform integrity, etc and some of the applications are secure boot, disk encryption, device authentication, etc.

Using the TPM for key management has the following benefits:

Security: TPMs are hardware-based security modules that resist software-based attacks. In software-based systems, security keys are kept in shared memory where software vulnerabilities in the operating system could be exploited to expose or access the keys. With TPM, keys are stored in the chip's secure storage, reducing the attack surface and making it highly immune to software vulnerabilities from the operating system and application levels.
Cost-effective: Manufacturers often build TPMs into modern computers and servers. This eliminates the need for additional hardware investment and separate licenses.
Ease of use: Setting up and managing TPMs is generally easier than managing a full-fledged key server.
Key storage: Key is stored securely within TPM using strong authorization and available locally without much dependency on network.
Integrated key management: Maintain strong secure keys for SED support as part of the Scale Storage System without extra costs and with ease of use.

It is important to understand the following concepts before using the SED support with the TPM key management:

TPM owner hierarchy: The TPM hierarchy is crucial for managing and organizing keys, data, and other entities within the Trusted Platform Module (TPM) 2.0. The TPM has four hierarchies: Platform, Owner, Endorsement, and NULL. In the Platform, Owner, and Endorsement hierarchies, data can persist across TPM power cycles, and you can set a password to prevent unauthorized access. The fourth hierarchy, NULL, is volatile. For the SED support, the owner hierarchy is configured by setting a password to protect the TPM from unauthorized access and to create NV slots in the owner hierarchy for saving keys.
TPM nonvolatile (NV) storage: NV Storage in TPM securely stores sensitive information, persisting data through TPM power cycles. To store keys in NV Storage, create slots in the owner hierarchy of TPM called NV slots. NV slots are identified by a unique hexadecimal ID called NV Slot ID.
TPM Random Number generator (RNG): A TPM's random number generator provides high-quality, hardware-derived randomness. It can serve as a secure seed for cryptographic key generation. Using the TPM's tamper-resistant and isolated RNG as the initial entropy makes generated keys harder to predict or compromise, strengthening overall security.
TPM clear: TPM clear resets the TPM to its factory default state by erasing all keys, data, and configuration stored in it. It is recommended to disable the clear function of TPM before using it for SED support with TPM. For more information about disabling the TPM clear, see Disable the TPM clear function.

OpenSSL and operating system requirements for TPM

SED Support for GNR with TPM uses OpenSSL version 3 to generate FIPS 140-2 compliant AES 256-bit keys with a seed from TPM RNG. As OpenSSL supports FIPS from version 3 and above, and OpenSSL version 3 is supported from RHEL 9 and above, there is an OS dependency on using RHEL 9 and above for SED Support for GNR with TPM.

High availability of TPM keys

To achieve high availability of keys when using keys from TPM for SED support, make sure that both canisters (I/O nodes) of the IBM Storage Scale System are having the same key in an NV Slot by using the key migration mechanism. This requirement is because both canisters (I/O nodes) have access to the same disks.

In a single building block scenario, losing both canisters (I/O nodes) of the IBM Storage Scale at the same time might lead to losing two copies of the TPM key, resulting in data loss. To prevent this, create a third copy of the key by using esstpmkey and esstpm tools on the EMS Utility Node TPM through the EMS VM.

The tools esstpmkey and esstpm are part of the IBM Storage Scale System deployment tools rpm. Using these tools, you can create a backup of the TPM key in I/O Nodes to the EMS Utility Node TPM through the EMS VM. For more information on these tools, see TPM backup and restore.

In a multi building block scenario, use the same key across all the building blocks for SED Support with TPM to ensure high availability of keys. For example, if two building blocks use the same key for SED support with TPM, there will be four copies of the key. Even if two canisters of a building block are lost simultaneously, you can migrate the key from the other building block.

Important: For a multi building block scenario, it is highly recommended to use the same key across all the building blocks for SED Support with TPM.

Coexistence of TPM and GKLM-based keys

For SED support with TPM, all disks of a node class must only use the key from either TPM or GKLM. Use the mmvdisk sed rekey command to switch key management from TPM to GKLM or vice versa. Moving MEK from TPM to GKLM or vice versa is not supported. Generate a new key in the respective key management for rekey.

Changing Key from TPM to GKLM

You need to get the key from GKLM by getting the RKM ID and Key UUID values of the key to change current SED Key from TPM to GKLM. Once you have the RKM ID and Key UUID values, issue the following command:

mmvdisk sed rekey --rg rg1 --rkmid ESS_ab --key-uuid KEY-86a24d4-f0d12986-42f1-4209-9688-1d1ab01f05c8 --confirm

Changing Key from GKLM to TPM

You need to get the key from TPM by getting the NV Slot ID value of the key to change current SED Key from GKLM to TPM. After getting the TPM key details, issue the following command:

mmvdisk sed rekey --recovery-group rg1  --tpm-slot-id 0x1500012

Data protection with TPM

The following table describes the different threats from which data can be protected by using SED Support for TPM.

Table 1. Data protection with TPM
THREAT	DATA PROTECTION
One or more disk drives are stolen.	Data is protected since the drive is locked. The key is in TPM, which is not accessible.
One or both canisters are stolen.	Data is protected since the drive is locked. Policy creation fails without access to the internal enclosure.
Entire IBM Storage Scale System is stolen (Canisters and internal enclosure).	If root access is gained, data might not be protected. The acces to Internal enclosure is available, which is used for accessing MEK as part of policy. CAUTION: If there is a high possibility of this threat, you need to use the SED support with GKLM instead of TPM. GKLM is an external key server that is located in a different place, so the key remains inaccessible even if the entire SSS box is stolen.