Hardware Encryption

The Cisco HyperFlex SED documentation captures the foundational definition: “Self-Encrypting Drives (SEDs) have special hardware that encrypts incoming data and decrypts outgoing data in real-time. The data on the disk is always stored in encrypted form. A media encryption key controls this encryption and decryption. This key is never stored in the processor or memory.”¹

The dedicated-silicon principle

The defining property of hardware encryption is that cryptographic operations are performed by purpose-built hardware rather than general-purpose CPU instructions:

• Storage controllers (Self-Encrypting Drives) include AES engines in the drive’s controller chip.
• Security coprocessors (TPM, Apple T2, Secure Enclave) perform encryption in dedicated chips separate from the main CPU.
• HSMs (Hardware Security Modules) are standalone devices for enterprise key management.
• SoC-integrated security blocks (Apple Silicon, modern smartphone SoCs) embed cryptographic hardware in the system-on-chip.

The “concept, not algorithm” framing

The SSSTC SED reference makes a useful clarification: “An SED is not a single encryption algorithm or a specific piece of hardware IP. Rather, it is a security concept that describes a storage device’s capability to perform trusted and manageable self-encryption behaviors. From an implementation perspective, an SED typically relies on the SSD controller’s inline hardware encryption architecture. The primary differentiator lies in its support for key isolation and manageable, policy-driven access control, rather than encryption alone.”² The implication: many modern SSDs perform inline AES on every write but are not properly classified as SEDs because they lack the key isolation and access control needed to qualify under TCG Opal or similar standards.

Hardware vs software encryption trade-offs

Property	Hardware encryption	Software encryption
CPU overhead	Zero (dedicated silicon)	3-30% depending on AES-NI support
Key location	In controller/chip; never exposed	In RAM during operation
Erase speed	Milliseconds (DEK rotation)	Hours to days (physical overwrite)
Auditability	Vendor firmware (often closed)	Often open-source (LUKS, VeraCrypt)
Cross-platform compatibility	Vendor and standard dependent	Generally portable (LUKS works on any Linux)
Cold-boot attack resistance	Strong (keys not in RAM)	Weak (keys may be in RAM)
Firmware vulnerability risk	Real (Radboud 2018 cases)	Lower for audited implementations

The “always encrypted” property

The QNAP SED documentation captures a key property of hardware encryption: “SEDs automatically encrypt all data as it is written to the drive and decrypt all data as it is read from the drive. Data stored on SEDs are always fully encrypted by a data encryption key, which is stored on the drive’s hardware and cannot be accessed by the host operating system or unauthorized users. The encryption key can also be encrypted by a user-specified encryption password that allows the SED to be locked and unlocked.”³ The architectural consequence: an SED is encrypting data even when the user has not configured a password; the password adds a gate around the always-encrypted DEK rather than initiating encryption.

Performance characteristics

The Trenton Systems hardware encryption guide describes the performance advantage: “Additional steps to encrypt and decrypt the drive’s data are not necessary, unlike with software-based disk encryption solutions. With hardware-based full disk encryption, you just turn your system on, and ceteris paribus, it’s business as usual.”⁴ Specifically:

• SED inline AES: dedicated controller hardware processes AES at full SATA/NVMe line rate; no measurable performance impact.
• TPM-assisted encryption: the TPM stores keys but actual bulk encryption typically uses CPU AES-NI; performance similar to software encryption.
• Apple Silicon Secure Enclave: integrated into the SoC; encryption happens at memory bus speed.
• Software encryption with AES-NI: ~3% overhead; close to hardware encryption performance.
• Software encryption without AES-NI: 10-30% overhead; noticeable on older systems.

SEDs are the most common form of hardware encryption in storage. Understanding their internal architecture clarifies what they protect, what they don’t, and how recovery scenarios play out.

The “no hardware difference” insight

The Seagate Enterprise SED user guide makes a counterintuitive observation: “There is no hardware difference between a standard enterprise drive and an SED (apart from the label) however the SED does undergo a set of additional manufacturing procedures which configure the security features in the drive. This configuration involves the installation of security tables, defines a set of credentials (passwords), enables the encryption engine, and initializes the system band on the media.”⁵ The implication: SED status is established at manufacturing through firmware provisioning and key generation, not through different physical components. The encryption engine is present in many modern drive controllers; SED status depends on whether it has been activated and configured.

The system band

The Seagate guide describes a specific drive structure: “The system band is shown in Figure 6 and comprises an area at the inner radius of the media which is used by the drive to store the information needed to manage its security.” This security metadata storage area:

• Located at the inner radius of HDDs (or in reserved NAND blocks for SSDs).
• Stores credential hashes, security policies, and key wrapping data.
• Is not directly accessible to the host OS.
• Survives full data wipes (it’s outside the user-addressable area).
• Initialization at manufacturing time is what converts a standard drive into an SED.

The SED key architecture

SEDs use a layered key system rather than encrypting data directly with user passwords:

1. DEK (Data Encryption Key) / MEK (Media Encryption Key): the actual key used for AES encryption; randomly generated by the drive controller, typically 256 bits.
2. KEK (Key Encryption Key): derived from the user password; used to encrypt the DEK.
3. System band metadata: stores the encrypted DEK plus authentication credentials.
4. Authentication keys: for multi-user/multi-band SEDs, separate keys per band.

This layered design enables instant cryptographic erase: rotating the DEK destroys all previously-encrypted data without touching the actual media. It also enables password changes without re-encrypting the entire drive; only the KEK needs to be recomputed.

Locked vs unlocked states

SEDs have two operational states that affect data accessibility:

• Unlocked: the drive controller has the DEK in working memory and decrypts on read / encrypts on write transparently. Host OS sees a normal drive.
• Locked: the drive controller does not have the DEK; reads return shadow MBR or zeros. The drive appears empty or refuses access.
• Transition: locked → unlocked happens via authentication (password entry, PBA bootloader, KMIP server response).
• Power cycle: typically resets to locked state requiring re-authentication.

Pre-Boot Authentication (PBA)

To unlock an SED before the OS boots, a small bootloader called Pre-Boot Authentication runs from the unencrypted shadow MBR area:

• Shadow MBR contains a minimal bootloader visible when the drive is locked.
• PBA prompts for password, communicates with drive controller via TCG Opal commands.
• Once authenticated, the controller switches to unlocked mode and reveals the real boot sector.
• The OS boots from the now-accessible drive.
• Implementations: Microsoft eDrive (BitLocker), Wave Systems Embassy, WinMagic SecureDoc, Sophos SafeGuard.

Instant cryptographic erase

The Cisco HyperFlex SED reference describes the defining decommissioning feature: “SEDs reduce the disk retirement and redeployment costs through instantaneous cryptographic erasure. Cryptographic erasure is done by changing the media encryption key. When the media encryption key of a disk is changed, the data on the disk cannot be decrypted, and is immediately rendered unusable. An SED based cluster can have encryption enabled and disabled at will. You are free to move between the two states whenever you want.” Practical applications:

• Decommissioning: retire a drive in seconds rather than hours of overwriting; the data is cryptographically destroyed.
• Repurposing: reassign a drive to a different user or team; the previous user’s data becomes inaccessible.
• RMA returns: ship a drive back to the manufacturer for warranty service without exposing data.
• Compliance: meet NIST SP 800-88 sanitization requirements through cryptographic erase rather than physical destruction.

Key management options

The Cisco SED reference describes two main key management modes: “Cisco HyperFlex Systems enables you to configure security keys locally or remotely. When you configure the key locally, you must remember the key. In case you forget the key, it cannot be retrieved, and the data is lost if the drive power cycles. You can configure the key remotely by using a key management server (also known as KMIP server). This method addresses the issues related to safe-keeping and retrieval of the keys in the local management.” The KMIP (Key Management Interoperability Protocol) standard is widely supported:

• Thales CipherTrust Manager: enterprise KMIP server.
• Fortanix Data Security Manager: cloud-based key management.
• HashiCorp Vault: open-source key management with KMIP.
• WinMagic SecureDoc Enterprise Server (SES): SED-focused key escrow.
• Microsoft Azure Key Vault: cloud-based with KMIP support.

The Trusted Computing Group (TCG) defines the dominant SED interoperability standards. Understanding the variant landscape is essential for choosing drives that actually provide the encryption guarantees they advertise.

The TCG Storage Working Group

The Trusted Computing Group is an industry consortium that develops storage security specifications. The TCG Storage Working Group has defined multiple Subsystem Class (SSC) specifications targeting different market segments. The ArchWiki Self-encrypting drives reference describes the variant landscape: “Many self-encrypting drives available today implement the OPAL, Ruby or Enterprise standards developed by the Trusted Computing Group (TCG). Other standards such as Opalite and Pyrite only offer a subset of the functionalities offered by OPAL, and might not even offer any actual encryption of data at rest.”⁶

The variant comparison

Variant	Target market	Encryption	Key features
Enterprise SSC	Datacenter SSDs/HDDs	Always AES-256	Multi-band, KMIP, advanced auth
Opal 2.0	Mainstream consumer/business	Always AES (128 or 256)	Up to 16 bands, shadow MBR, PBA
Ruby	Entry-level enterprise	Always AES	Subset of Enterprise SSC
Opalite	Limited consumer	Always AES	Reduced Opal feature set
Pyrite	Entry consumer	May not encrypt at all	Locking only; AES not required

The Pyrite warning

The ArchWiki reference’s warning about Pyrite is particularly important: drives labeled as TCG Pyrite-compliant may provide drive locking but not actual data encryption. A Pyrite drive that is “locked” simply refuses access to data; the underlying NAND or platters still contain plaintext. An attacker with the ability to bypass the drive controller (JTAG access, chip extraction) can read data directly from the storage media. For users wanting genuine encryption-at-rest, only Opal 2.0 or Enterprise SSC labels guarantee the encryption is actually being performed.

Known OPAL implementation problems

The ArchWiki reference notes a specific concern: “There are known complications with some device’s OPAL implementation, for example the Samsung 990 model and the WD_BLACK SN8100 model. It is sensible to research the respective model prior to using the feature.” Common problem patterns:

• Firmware bugs that fail to lock properly under specific conditions.
• Incompatibility with specific PBA implementations (Microsoft eDrive, sedutil-cli, etc.).
• Vendor-specific behaviors that violate TCG Opal expectations.
• Performance degradation when SED features are enabled.
• Drive recognition issues on certain controllers or BIOSes.

ATA Security vs TCG Opal

Two distinct password protection mechanisms exist in the storage world:

• ATA Security (ATA-7 / ATA-8): older standard built into the ATA command set; provides drive locking but encryption is optional and often not present.
• TCG Opal: modern standard requiring real AES encryption; built specifically for SEDs.

Many drives support both standards; ATA Security is simpler but provides weaker guarantees. The Radboud University 2018 research specifically targeted “ATA high” mode on Samsung 840/850 EVO drives, which was implemented poorly enough to allow encryption bypass.

SED management software

Several tools exist for SED configuration and management:

• sedutil-cli (open source): Drive Trust Alliance’s open SED management tool; works with Opal 2.0 drives on Linux/Windows.
• Microsoft eDrive: built into Windows 8.1+; integrates BitLocker with TCG Opal SEDs.
• WinMagic SecureDoc: commercial cross-platform SED management.
• Sophos SafeGuard: enterprise endpoint encryption with SED support.
• Vendor utilities: Samsung Magician, Crucial Storage Executive, Seagate SeaTools (limited SED features).

SEDs are the most visible form of hardware encryption, but the concept extends to several other categories of hardware that affect data recovery scenarios.

TPM (Trusted Platform Module)

The Trusted Platform Module is a dedicated security chip embedded on motherboards or CPUs that provides cryptographic services to the OS:

• TPM 1.2: older standard; still common on legacy systems.
• TPM 2.0: current standard; required for Windows 11.
• fTPM (firmware TPM): implemented in CPU firmware (Intel PTT, AMD fTPM); functionally equivalent for most uses.
• Discrete TPM: separate chip; higher security but rarer in modern systems.

The TPM doesn’t perform bulk data encryption; it provides key storage and platform integrity attestation. BitLocker uses the TPM to seal volume keys to platform state (Platform Configuration Register values), so the keys are released only when the boot environment matches expected configuration.

Apple T2 and Secure Enclave

Apple’s hardware encryption integrates differently from Windows TPM:

• T2 Security Chip (2017-2020 Intel Macs): Apple-designed coprocessor with integrated Secure Enclave; handles SSD encryption at the storage controller level.
• Apple Silicon (M1/M2/M3/M4, 2020+): Secure Enclave integrated into the SoC; storage controller encryption built into the silicon.
• Always-on encryption: data is encrypted regardless of FileVault status; FileVault adds password gating.
• Hardware-bound keys: Volume Encryption Key sealed to specific hardware; cannot be extracted or used on different hardware.

Hardware Security Modules (HSMs)

HSMs are dedicated cryptographic appliances used in enterprise environments:

• Network HSMs: rack-mounted appliances accessed over network (Thales Luna, Entrust nShield).
• USB HSMs: portable form factor (YubiHSM, Nitrokey HSM).
• Cloud HSMs: AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM.
• Use cases: CA root key protection, payment card industry (PCI-DSS) requirements, code signing, blockchain key custody.
• FIPS 140 certification: typical security baseline; FIPS 140-2 Level 3 or 140-3 Level 3 for high-security uses.

USB device hardware encryption

Hardware-encrypted USB drives are a specific subcategory:

• Apricorn Aegis: hardware PIN entry on the device itself.
• Kingston IronKey: FIPS 140-2 Level 3 certified flash drives.
• iStorage diskAshur: PIN-protected USB drives.
• IEEE 1667: USB authentication standard; less commonly used than vendor-specific solutions.

CPU-integrated security blocks

Modern CPUs include various hardware security features:

• AES-NI: Intel/AMD CPU instructions that accelerate software AES; not strictly hardware encryption but blurs the line.
• Intel SGX (Software Guard Extensions): trusted execution environments for sensitive code (deprecated on consumer CPUs).
• AMD SEV (Secure Encrypted Virtualization): VM memory encryption for cloud security.
• ARM TrustZone: ARM CPU security architecture; underlies many embedded device security implementations.

The 2018 Radboud SED vulnerabilities

The most significant historical SED vulnerability disclosure came from Radboud University researchers Carlo Meijer and Bernard van Gastel in November 2018. The CERT advisory VU#395981 describes the scope: “Researchers have detected multiple vulnerabilities in implementations of the TCG Opal standard with SEDs. These vulnerabilities are known under CVE-2018-12037 and CVE-2018-12038. CVE-2018-12037: There is no cryptographic link between the given password end user and the key used for the encryption of user data. CVE-2018-12038: Key information is stored on a wear-leveled storage chip.”⁷ Affected products:

• CVE-2018-12037 affected drives: Crucial (Micron) MX100, MX200, MX300; Samsung T3 and T5 portable drives; Samsung 840 EVO and 850 EVO (in “ATA high” mode only).
• CVE-2018-12038 affected drives: Samsung 840 EVO.

The nine threat vectors

The CERT advisory enumerates nine specific issues addressed by certified mitigations: “Password and DEK not linked; Single DEK used for the entire disk; Lack of entropy in randomly generated DEKs; Wear leveling, power-saving mode (e.g. DEVSLP); General implementation issues (i.e. incorrect crypto usage); JTAG access; Vendor diagnostic commands access; Arbitrary unsigned code execution; Same intermediate encryption key for all MEKs.” The Microsoft response was particularly notable: BitLocker by default offloaded encryption to SED hardware on Windows 10, so users with affected drives were exposed even though they thought they were using BitLocker software encryption. Microsoft issued a security advisory recommending users force BitLocker to use software encryption mode regardless of SED capability.

Hardware encryption recovery scenarios differ from software encryption in specific ways that affect both prospects and procedures.

The credential-and-controller dependency

Hardware encryption recovery has two prerequisites that must both be satisfied:

1. Credentials: the password, recovery key, or KMIP server access.
2. Functional drive controller: the chip that holds the keys must be alive and able to perform decryption.

Either prerequisite failure renders recovery impossible. Without credentials, the controller refuses to decrypt; without a functional controller, even with credentials there’s no way to invoke decryption. This dual dependency makes hardware encryption recovery harder than software encryption recovery in some scenarios; software-encrypted volumes can be unlocked on any system with the right credentials, while hardware-encrypted volumes are tied to specific hardware.

Recovery from a forgotten password

The most common SED recovery scenario: the user has forgotten the password but the drive is functional. Approaches:

• Recovery key (Opal 2.0): if a separate recovery key was configured at setup, use it to unlock and reset the password.
• KMIP server: for enterprise SEDs, the key management server can release the key after administrator authentication.
• Institutional Recovery Key: for managed deployments via WinMagic, eDrive, or similar; admin can unlock.
• PSID revert: on Opal 2.0 drives, the PSID (Physical Security ID) printed on the drive label can revert the drive to factory state, destroying all data but making the drive usable again.
• BitLocker recovery key: if the SED was managed by BitLocker eDrive, the BitLocker recovery key can unlock it.

Recovery from drive controller failure

This is the catastrophic scenario for hardware-encrypted drives. The Cisco HyperFlex SED documentation captures one variant: “If you forget the [local] key, it cannot be retrieved, and the data is lost if the drive power cycles.” But the harder version is hardware failure of the controller itself:

• NAND flash or platters may be physically intact and contain readable encrypted data.
• The controller chip holds the DEK and is the only component capable of using it.
• A failed controller means the DEK is unrecoverable and the encrypted media is mathematically locked.
• Standard chip-off recovery (reading NAND directly) yields encrypted data that requires the controller’s keys to decrypt.
• Even cleanroom-class data recovery cannot help in this scenario.

The chip-off recovery limitation

Traditional chip-off recovery works on standard SSDs by extracting NAND chips and reading their contents directly. For hardware-encrypted drives, this approach has a fundamental limitation:

• The NAND contains AES-encrypted ciphertext.
• Without the DEK from the controller, the ciphertext is computationally indistinguishable from random data.
• Chip-off recovery yields encrypted bits that cannot be decrypted without the original controller’s key material.
• For affected SEDs covered by Radboud University’s research, vulnerability-based recovery may be possible but requires controller-specific tooling.
• For modern Opal 2.0 / Enterprise SSC drives with certified mitigations, chip-off recovery is essentially useless.

Recovery from BitLocker-on-SED scenarios

The 2018 Microsoft advisory specifically affects recovery in mixed BitLocker + SED scenarios:

• Windows 10 BitLocker by default offloads encryption to SED hardware when a supported SED is detected.
• For users with vulnerable Crucial or Samsung drives, this means data was actually protected only by the flawed SED encryption, not by BitLocker software.
• Microsoft’s mitigation: force BitLocker to use software encryption via Group Policy “Configure use of hardware-based encryption for fixed data drives”.
• Users who applied the mitigation can recover from BitLocker software encryption normally with the BitLocker recovery key.
• Users who did not apply the mitigation are vulnerable to the underlying SED bypass attacks.

When hardware encryption recovery is impossible

Specific scenarios where hardware-encrypted data is permanently inaccessible:

• Password forgotten AND no recovery key/KMIP access AND PSID not used.
• Drive controller hardware failure on a non-affected SED.
• Apple Silicon Mac with logic board failure (VEK sealed to Secure Enclave hardware).
• HSM key destroyed without backup.
• KMIP server data permanently lost without DR site backup.

The hardware-encrypted nature of modern storage makes comprehensive backups essential; for some failure modes, no recovery service can help regardless of expertise.