SSD Hardware Encryption and Data Recovery

Most SSDs manufactured after 2015 encrypt all data by default because always-on hardware encryption serves two functions: it enables instant Secure Erase by destroying the Media Encryption Key rather than erasing every NAND cell, and it provides the foundation for optional user-set passwords via ATA Security, TCG OPAL, or BitLocker.

Since approximately 2015, many enterprise and mainstream SSD controllers have implemented always-on AES-256 hardware encryption by default, without any user configuration. Samsung, Silicon Motion, Marvell, & Intel/Solidigm controllers commonly encrypt every write to NAND using a Media Encryption Key generated during manufacturing. The OS reads & writes plaintext; the controller handles all encryption and decryption in dedicated hardware, with negligible performance impact.

Notable exceptions exist: some DRAM-less NVMe drives and gaming SSDs (WD SN770, WD SN850X, Sabrent Rocket Q4) omit hardware AES-256.

The controller generates a Media Encryption Key (MEK) during manufacturing or first initialization. Every write to NAND passes through the AES engine, and every read is decrypted before being sent to the host. Performance impact is negligible because the AES engine is implemented in dedicated hardware on the controller die.

Always-on encryption exists for two reasons. First, it enables instant Secure Erase: instead of erasing every NAND cell, the controller destroys the MEK and generates a new one, making all existing data permanently unreadable in milliseconds. Second, it provides a foundation for user-set passwords.

When a user enables ATA Security, TCG OPAL, or BitLocker hardware mode, the MEK is itself encrypted with the user's authentication key. The NAND data was already encrypted; the user password simply locks access to the MEK.

Hardware encryption changes the viable recovery methods. On an unencrypted drive, multiple paths exist: chip-off NAND extraction, controller swap, or firmware repair all yield readable data. On a hardware-encrypted drive, the original controller is the only key holder. Chip-off yields ciphertext; controller swap generates a new key; only controller repair preserves the decryption chain.

Hardware Encryption vs Software Encryption: Recovery Comparison

Hardware encryption (SED) is performed by the SSD controller using a key stored in the controller silicon. BitLocker software mode is performed by the host CPU using a key stored in the TPM or supplied by the user. FileVault on modern Macs (T2 and Apple Silicon) is not purely host-CPU software: encryption runs on a dedicated AES engine in the SoC data path, with keys bound to the Secure Enclave. Recovery path differs depending on which layer holds the key.

Apple T2 and M-series chips implement hardware encryption through a Secure Enclave coprocessor. The AES keys are fused into the Secure Enclave silicon, and the NAND storage is soldered directly to the logic board. There are no removable drives to send to another lab; recovery requires repairing the logic board so the Secure Enclave can serve the decryption keys.

On a MacBook with a T2 or M-series chip, the SSD controller is integrated into the Apple silicon. The NAND chips are soldered to the logic board and communicate with the SoC through a proprietary bus. The Secure Enclave generates and stores the volume encryption keys.

If the MacBook logic board fails, the Secure Enclave keys are inaccessible. Desoldering the NAND yields AES-256 ciphertext with no path to decryption.

Recovery requires repairing the logic board so the T2 or M-series chip boots and the Secure Enclave can serve the decryption keys. This is T2/M-series data recovery at the board level: identifying which power rail, capacitor, or IC failure prevents the SoC from initializing, repairing it, and imaging the drive through the running system.

BitLocker can delegate encryption to the SSD controller instead of encrypting in software. When the SSD controller dies in this configuration, the BitLocker recovery key alone isn't enough; the controller must decrypt the data first, then BitLocker's key unlocks the volume. Recovery requires reviving the original controller through board-level repair at $450–$600 for SATA or $600–$900 for NVMe.

Windows 10 & 11 automatic device encryption often selected hardware mode on OPAL-compliant SSDs without asking the user. The OS detected the drive's SED capability & delegated encryption to the controller's AES engine. The user's BitLocker recovery key protected the MEK wrapper, but the controller performed all encryption and decryption operations in hardware.

This changed after researchers published CVE-2018-12037 & CVE-2018-12038, demonstrating that several SSD manufacturers implemented hardware encryption with flaws that allowed bypassing the authentication layer. Microsoft responded with ADV180028 in November 2018. Microsoft subsequently changed the Group Policy default via the September 2019 cumulative update (KB4516071) so new BitLocker volumes use software encryption instead of delegating to the SSD controller. Systems encrypted before that change may still be running in hardware mode.

Recovery Procedure for BitLocker Hardware Mode

1. Revive the SSD controller via board-level repair using Hakko FM-2032 microsoldering & FLIR thermal imaging to locate failed components on the power delivery circuit.
2. Authenticate the OPAL session. Because BitLocker delegated encryption to the hardware, the BitLocker recovery key is used to unlock the SED locking range before imaging begins.
3. Image the plaintext data using PC-3000 SSD. Once authenticated, the controller's hardware AES engine transparently decrypts the NAND reads, yielding fully decrypted data.

If the controller can't be revived, the data is permanently locked: the SSD's AES-256 layer encrypts the raw NAND, and the Media Encryption Key required to decrypt it is trapped inside the dead controller. Chip-off yields ciphertext with no path to the key. Board repair at $450–$600 (SATA) or $600–$900 (NVMe) is the only option.

Each SSD controller manufacturer implements AES-256 hardware encryption differently. Samsung, Phison, Silicon Motion, Marvell, & WD each store the MEK differently, use different authentication interfaces, and require different PC-3000 SSD recovery modules. Recovery procedures that work on a Samsung Elpis controller won't work on a Phison PS5012. Each requires its own diagnostic mode entry sequence & FTL reconstruction method.

The MEK storage location, the authentication interface, & the PC-3000 SSD recovery utility all vary by controller family.

The PC-3000 SSD module for each controller family communicates using vendor-specific ATA or NVMe commands to enter diagnostic mode, read the FTL mapping table, & image the drive through the controller's decryption engine. Phison controllers require shorting diagnostic test points on the PCB to enter Safe Mode for firmware repair; Samsung controllers require a specific power-on sequence to enter service mode. These differences matter because using the wrong procedure on the wrong controller can overwrite firmware modules & destroy the MEK reference.

Board repair pricing depends on the controller complexity: SATA board repair runs $450–$600, NVMe runs $600–$900. The NVMe tier is higher because NVMe controllers have more complex power delivery circuits with multiple voltage rails feeding the PCIe PHY, DRAM interface, and NAND channels independently.

On a Self-Encrypting Drive without a user password, the Data Encryption Key (DEK, equivalent to the MEK in TCG OPAL terminology) lives inside a controller-resident key blob, wrapped by a Hardware Unique Key fused into the controller silicon during manufacturing. The DEK never leaves the controller in plaintext. NAND chip-off extraction sees only AES-256 ciphertext because the DEK cannot be reconstructed from the flash dies. The wrapped key blob is stored either in a protected firmware partition on the NAND (encrypted with the HUK) or in a small region of the controller's on-die OTP/eFuse area, depending on the family.

SED with User PIN vs. ATA Security Class 0: Where the DEK Lives

On a Class 0 always-on drive, the controller initializes the DEK on first power-up with no user input. Anyone who can boot the controller reads plaintext through it. On a TCG OPAL drive with a user PIN, the controller adds a Key Encryption Key derived from the PIN and uses it to wrap the DEK. The wrapped DEK still lives in the controller's secure region; the PIN only unwraps it at runtime. Both architectures defeat chip-off recovery, but for different reasons. Class 0 defeats chip-off because the HUK is required to unwrap the DEK; OPAL defeats it for the same reason plus the PIN-derived KEK requirement. Decapping the controller die to read the HUK is not a service offered by mainstream data recovery labs; the silicon is designed to resist optical and electrical probing of the fuse bank.

Controllers That Default to AES-256 Always-On

• Phison E12, E16, E18, E19T families. Most OEM configurations enable hardware AES-256 with a factory-generated DEK. Used by Kingston, Corsair, PNY, Sabrent, Inland, MyDigitalSSD. Some OEM SKUs (Sabrent Rocket Q4 on E16) ship with AES disabled in firmware; the drive label and TCG identify report disclose this.
• Silicon Motion SM2246EN, SM2258, SM2259, SM2262, SM2263, SM2264, SM2267, SM2269. AES-256 is on by default in the reference firmware. Used widely in Crucial MX SATA, Adata, Patriot, HP, Lexar, and Micron consumer NVMe. Crucial disabled hardware AES on the budget BX series (BX100), so chip-off remains viable on those specific drives.
• SandForce legacy SF-1200, SF-2281, and SF-3700. Originally LSI/Sandforce, later acquired by Seagate. Shipped with AES-128 (SF-1200/2281 early) or AES-256 (SF-2281 late silicon, SF-3700) always-on. Found in OCZ Vertex 3/4, Vector, Agility 3/4, Intel 330/335/520/530, and Kingston HyperX 3K. These drives are PC-3000 SSD supported via the SandForce utility, but the AES key is stored in a controller-internal blob; controller swaps fail for the same reason as modern families.
• Marvell 88SS1074, 88SS1093, 88SS1100. AES-256 always-on in WD Blue/Green SATA, SanDisk Ultra 3D, and Plextor M8V/M9P generations.
• Samsung Elpis, Phoenix, Pascal, Piccolo. Proprietary AES engine with HUK fused in controller silicon. Default behavior is always-on; the user-visible "encryption status" in Samsung Magician reflects whether a user password has wrapped the MEK, not whether the AES engine is active.

When PMIC or Power-Rail Failure Preserves the DEK

An SSD that fails to enumerate on the SATA or PCIe bus is often diagnosed externally as "dead controller," but the controller silicon is frequently intact. Common electrical failure modes that leave the controller die undamaged: shorted decoupling caps on the 1.2V or 1.8V core rail, blown PMIC step-down converters, failed LDO regulators feeding the DRAM rail, cracked solder joints on BGA balls under thermal cycling, and ESD damage to the SATA or PCIe PHY transceiver pads (not the AES core).

In every one of these cases, the DEK and the wrapped key blob are physically intact. Restoring power delivery and signal integrity boots the controller, the AES engine initializes with the original DEK, and reads through the controller produce plaintext. The repair path uses Hakko FM-2032 microsoldering for cap and resistor replacement, Atten 862 hot-air rework for PMIC reflow or replacement, FLIR thermal imaging to locate shorts, and PC-3000 SSD for firmware stabilization once the drive enumerates. Chip-off in this scenario destroys a recoverable case: desoldering the NAND yields ciphertext that can never be decrypted because the DEK extraction step is no longer available once the original controller is removed from the PCB.

The contrast matters at intake. A drive that arrives with shorted passives or a dead PMIC is a board-repair candidate at $450–$600 (SATA) or $600–$900 (NVMe). A drive that arrives with a cracked controller die, burned silicon from a power surge, or visible delamination of the controller package is a different category: the HUK is gone with the silicon, the wrapped DEK can no longer be unwrapped, and chip-off would still yield ciphertext with no decryption path. We disclose this at evaluation rather than billing for a recovery the physics will not support. A donor drive is a matching SSD used for its circuit board. Typical donor cost: $40–$100 for common models, $150–$300 for discontinued or rare controllers.