Understanding Enterprise Self‑Encrypting Drives (SED), Key Management Controllers (KMC) and NetApp Encryption Technologies

In the previous article we introduced mainstream enterprise data‑encryption technologies, focusing on application‑transparent encryption for NAS and object storage; this continuation examines encryption‑disk solutions, storage‑controller encryption, and self‑encrypting drives (SED).

Most commercial SEDs meet FIPS government‑grade security standards, but they must be paired with a corresponding FIPS‑compliant key management system (KMC). The KMC can be a standalone server or integrated into the storage system; a standalone KMC offers higher security and can be deployed in a dual‑node hot‑standby configuration.

The KMC (shown as KeyAuthority) connects its management port to the storage management network, allowing many encrypted storage systems to share a single KMC. Each KMC can manage hundreds of storage systems and millions of symmetric keys. Storage array controllers do not cache or statically store encryption keys; they act as a proxy between the third‑party KMC and the self‑encrypting disks, providing a secure key‑transfer channel.

KMC does not affect storage performance; encryption/decryption rates match the disk interface speed, and data protection adds no latency. It provides transparent full‑disk encryption without impacting other array features such as mirroring, snapshots, deduplication, or compression.

The core of KMC key management is to guarantee key security and availability. Using a client‑server (CS) model, the third‑party KMC acts as the server, while storage devices act as clients. Keys are created, stored, managed, revoked, and destroyed via KMIP protocol commands issued by the client and processed by the server.

Key security is ensured by the server, while the key‑exchange channel is protected by encrypted tunnels. The storage controller never retains keys; it only functions as an AES encryption module that exchanges keys with the KMC.

Popular KMC vendors such as Thales and SafeNet offer independent key‑management deployments with FIPS 140‑2 Level 3 security, high availability through hardware redundancy or cluster hot‑standby, KMIP 1.0/1.1 interoperability, and full key‑lifecycle management compliant with NIST 800‑57.

About SED encryption disks:

Enterprise‑grade disks provide three encryption levels based on customer needs: static data and secure latch protection (FIPS 140‑2 Level 2), full static data protection (Full SED), and instant secure erase (ISE). Corresponding disk types are SED‑ISE, Full‑SED, and FIPS‑SED.

Data encryption process:

When a storage system reads or writes data, it obtains an Authentication Key (AK) from the KMC via KMIP over SSL. The AK encrypts the Data Encryption Key (DEK), which is stored on the disk. The disk’s AES engine uses the DEK to encrypt data on write and decrypt on read. The AK is kept in the KMC, while the DEK, encrypted by the AK, resides on the disk.

AK lifecycle:

AK setup: Enable disk encryption and AutoLock; the KMC assigns an AK to the disk.

AK authentication: On power‑up, the disk retrieves the AK from the KMC and matches it to the stored AK; successful match permits read/write operations.

AK update: To mitigate long‑term key compromise, AKs are periodically rotated; the disk re‑encrypts the DEK with the new AK while the DEK itself remains unchanged.

When a disk is authenticated, its internal circuit obtains the DEK, and the AES engine encrypts outgoing data and decrypts incoming data. Because the DEK is never exposed externally, physical removal or failure of the disk renders the data unreadable.

Data remains plaintext at the host, network, and storage‑system layers; encryption occurs only within the disk’s AES engine using the DEK.

Key communication technology:

The AK is stored on the KMC; storage controllers do not cache keys. When a SED is attached, the controller requests the AK from the KMC via KMIP, establishing a secure channel. Mutual authentication uses CA certificates: the client presents its certificate, the server validates it, then encrypts the response with its private key, and the client performs a second layer of encryption with its own certificate before sending back to the server.

Data destruction technology:

When a disk is decommissioned, the DEK is changed via a command from the KMC, instantly rendering all data on the disk unreadable without the need for time‑consuming overwrite operations.

NetApp Encryption Technologies (NSE & NVE):

NetApp FAS systems support two encryption methods. NetApp Storage Encryption (NSE) encrypts data on write at the disk level; without the correct disk key, data cannot be read. NSE works with self‑encrypting HDDs and SSDs and can be combined with NetApp Volume Encryption (NVE) for double encryption, though NSE does not encrypt MetroCluster traffic.

NVE is a software‑based volume encryption that encrypts both data and metadata with a unique XTS‑AES‑256 key per volume. It supports external KMCs or internal key managers, works with snapshots, deduplication, and compression, but cannot encrypt root, SVM root, or MetroCluster metadata volumes.

External KMCs are required when encryption key management must meet FIPS 140‑2 or OASIS KMIP standards, when the solution spans multiple storage clusters, when centralized key management is needed, or when authentication keys must be stored separately from data.

Recommended reading: "Which Enterprise Encryption Technology Can Bear the Heavy Load?" and "What Is Distributed System Data Consistency?"

Warm reminder: Scan the QR code below to follow the public account and click the original link for more technical resources.