How SSD Controller Encryption Works

Most modern SSD controllers encrypt all data before writing it to NAND flash. This encryption happens transparently: the host sends plaintext data over the SATA or NVMe interface, the controller's hardware AES engine encrypts it in-line, and only ciphertext reaches the NAND cells. On read, the controller decrypts the data before sending it back to the host. The encryption key is generated during drive initialization and stored in the controller or a dedicated secure element, not on the NAND itself.

Always-On AES Encryption in Modern Controllers

Controllers from Samsung, Phison, Silicon Motion, and Marvell implement AES-256 or AES-128 encryption in hardware. On many controllers, this encryption is always active, even when the user has not set a drive password. The controller generates a random media encryption key (MEK) during the drive's first initialization and uses it for all subsequent writes.

The purpose of always-on encryption is not necessarily security for the user. It enables instant secure erase: instead of overwriting every NAND cell (which is slow and accelerates wear), the controller can "erase" the drive by discarding the MEK and generating a new one. All data on the NAND becomes permanently unreadable ciphertext because the decryption key no longer exists.

For user-facing encryption (self-encrypting drives, or SEDs), the MEK is itself encrypted with a key encryption key (KEK) derived from the user's password. Setting a drive password wraps the MEK with the KEK. Clearing the password unwraps it. The NAND data stays encrypted with the same MEK throughout; only the access control changes.

Key Storage and the Role of the Controller

Where the MEK is stored depends on the controller architecture:

Controller internal storage

Many SATA SSD controllers store the MEK in a protected region of their internal flash or OTP (one-time programmable) memory. The key is tied to the specific controller silicon. Replacing the controller chip means losing access to the MEK.

NAND reserved area

Some controllers store a wrapped (encrypted) copy of the MEK in a reserved NAND block. The unwrapping key is derived from the controller's silicon-specific ID. This allows the controller to reload the MEK after a power cycle but prevents a different controller from using it.

External secure element

Enterprise SSDs and Apple's T2/M-series designs use a dedicated secure element (separate chip or secure enclave within the SoC) to store the encryption key. The key never leaves the secure element; encryption and decryption operations are performed within it.

Apple T2/M-Series Secure Enclave Key Binding

Apple Macs with T2 security chips (2018-2020 Intel Macs) and M-series chips (M1, M2, M3, M4) use a different encryption architecture than standard SSDs. The volume encryption key is generated and stored in the Secure Enclave, a hardware-isolated processor within the T2 or M-series SoC. The key is derived from the user's password (or Touch ID biometric on supported models) and a hardware-unique identifier (UID) fused into the Secure Enclave silicon during manufacturing.

This binds the encryption key to the specific T2 or M-series chip. It cannot be read, extracted, or transferred. If the SSD controller fails but the T2/M-series chip is functional, board-level repair to restore the SSD controller's operation allows the Secure Enclave to decrypt the data normally. If the T2/M-series chip itself is damaged or destroyed, the encryption key is permanently lost and the data is unrecoverable regardless of the NAND state.

Encryption Behavior by Controller Manufacturer

How Do TCG Opal, eDrive, and Vendor-Specific Encryption Compare?

Three self-encrypting drive (SED) standards control how SSDs manage hardware encryption: TCG Opal 2.0, Microsoft eDrive (IEEE 1667), & vendor-specific implementations like Samsung Class 0. Each standard handles key management, pre-boot authentication, & recovery differently. Understanding which standard your drive uses determines the recovery path when the controller fails.

TCG Opal 2.0

TCG Opal 2.0 is the industry standard for self-encrypting drives. The controller performs AES-256 encryption in hardware, offloading the CPU entirely. A Shadow MBR provides pre-boot authentication: the system boots into a minimal environment stored on the drive, the user enters credentials, & the controller unlocks the specified locking range. Each locking range maps to an LBA range on the NAND, allowing independent encryption zones on a single drive.

Recovery from a dead Opal drive requires the original controller to be operational. The MEK is bound to that controller's silicon. Board-level repair (PMIC replacement, capacitor swap) using a Hakko FM-2032 is the first step. Once the controller boots, PC-3000 SSD can enter diagnostic mode & extract data while the AES engine decrypts on-the-fly. SATA SSD board repair runs $450–$600; NVMe runs $600–$900.

eDrive (IEEE 1667)

eDrive is Microsoft's protocol for delegating BitLocker encryption to the SSD's Opal hardware. Instead of Windows performing software AES encryption on data before writing it, the OS tells the Opal-compliant controller to handle encryption at the hardware level. The result: faster writes, lower CPU usage, & no performance penalty from encryption.

The trap is invisible to most users. Windows shows BitLocker as "active," but the SSD controller is doing the actual encryption. If the controller dies, the BitLocker recovery key alone can't decrypt raw NAND reads. The recovery key authenticates a session with the Opal controller; without the controller, there's no session to authenticate. Recovery requires reviving the original controller first, then using the BitLocker recovery key to unlock the Opal session.

Samsung Class 0 (Vendor-Specific)

Samsung's Class 0 encryption is always-on from the factory. The controller generates a DEK during manufacturing & encrypts all NAND writes with AES-256. Setting an ATA password wraps the DEK with a key derived from the password. Without an ATA password, the encryption is transparent: the controller encrypts & decrypts automatically, & the user never interacts with it.

Class 0 isn't as structured as TCG Opal. There are no locking ranges, no Shadow MBR, & no standardized pre-boot authentication. But the recovery implication is identical: chip-off on a Class 0 Samsung drive yields ciphertext. The original Elpis or Phoenix controller must be functional to decrypt the data.

How Does the AES-256 Key Hierarchy Work Inside an SSD?

Self-encrypting SSDs use a three-layer key hierarchy: a Data Encryption Key (DEK) that encrypts the NAND, a Key Encryption Key (KEK) that wraps the DEK, & an Authentication Key (AK) derived from the user's credential. This hierarchy allows password changes without re-encrypting the entire drive. Only the KEK is re-wrapped; the DEK & NAND data stay untouched.

Data Encryption Key (DEK / Media Encryption Key)

The symmetric AES-256 key that encrypts every byte written to NAND. The controller generates this key during drive initialization using an on-chip hardware random number generator. The DEK never leaves the drive. It's stored in the controller's OTP memory or in a wrapped form in the NAND reserved area. If the DEK is lost or destroyed, every block on the NAND becomes permanent ciphertext.

Key Encryption Key (KEK)

Wraps the DEK so it's never stored in plaintext at rest. The KEK is derived from the user's authentication credential combined with a hardware-unique identifier on the controller. When the user changes their password, the controller re-wraps the DEK with a new KEK derived from the new credential. The NAND data doesn't change. No re-encryption is needed. A password change on a 2 TB SSD takes milliseconds, not the hours a full re-encryption would require.

Authentication Key (AK)

Derived from the user's credential: an ATA password, a BitLocker PIN, a TPM-stored key, or biometric data on supported platforms. The AK unlocks the KEK, which unwraps the DEK, which decrypts the NAND. If the user forgets the credential & has no recovery key backed up to Microsoft Entra ID, Active Directory, or a USB .bek file, the data is inaccessible even with a fully functional controller. The lab can't bypass the authentication layer.

This hierarchy is why encrypted drive recovery is a two-part problem. Part one: revive the controller so the AES engine is operational. Part two: provide the authentication credential so the key chain unlocks. A lab handles part one through board-level repair. Part two requires the customer to have their password, recovery key, or TPM binding. Without both parts, the data stays encrypted.

How Is Data Recovered from a Dead SSD with Intact Encryption Keys?

When an SSD controller dies but the NAND & encryption keys are intact, recovery requires reviving the original controller through component-level microsoldering, then using PC-3000 SSD to extract data through the controller's diagnostic interface. The controller's AES engine decrypts data on-the-fly during extraction. Replacing the controller chip loses the encryption keys; repairing the original one preserves them.

Board-Level Fault Localization

The first step is finding what killed the controller. A FLIR thermal camera identifies shorted components by their heat signature: a failed PMIC pulling excess current shows as a hot spot on the thermal image within seconds of applying power. The technician then replaces the specific component (voltage regulator, capacitor, inductor) using a Hakko FM-2032 microsoldering iron on an FM-203 base station. The goal is to bring the original controller back to a state where it can initialize & respond to commands.

PC-3000 SSD Recovery Procedure

Once the controller responds, PC-3000 SSD connects through the controller's diagnostic interface. The procedure for encrypted drives with firmware corruption follows a specific sequence:

1. Force Safe Mode / Technological Mode entry by shorting specific test points on the PCB. This bypasses the corrupted firmware boot sequence & loads the controller into a minimal diagnostic state.
2. Inject a volatile loader (LDR) into the controller's SRAM. This microcode provides PC-3000 with read/write access to the NAND through the controller, without relying on the corrupted on-chip firmware.
3. Read the NAND reserved area to locate firmware modules, the Flash Translation Layer (FTL) tables, & the wrapped MEK. The reserved area is the controller's internal bookkeeping zone on the NAND.
4. Reconstruct the Virtual Translator in host RAM. PC-3000 reads the raw NAND blocks & rebuilds the logical-to-physical block mapping that the FTL normally maintains. This step can take hours on high-capacity drives with fragmented FTL tables.
5. Extract data sector-by-sector through the controller's AES engine. The controller decrypts each sector as PC-3000 reads it. The output is plaintext user data, written to a target drive.

This entire procedure depends on the original controller being alive. A replacement controller won't have the MEK. A different controller from the same model won't have the same hardware fuses. Board repair isn't a separate service from SSD data recovery; for encrypted drives, board repair IS the data recovery. SATA SSD board repair runs $450–$600. NVMe board repair runs $600–$900. Firmware-level recovery (loader injection & FTL reconstruction) runs $600–$900 for SATA or $900–$1,200 for NVMe.

How Do PC-3000 SSD Extraction Procedures Differ by Controller Family?

The generic recovery procedure above applies broadly, but each controller family requires a different diagnostic entry method, microcode loader, & FTL reconstruction approach. Samsung controllers use Vendor-Specific Commands to enter Factory Access Mode. Silicon Motion controllers require a permanent test-point short & volatile loader injection. Phison controllers vary by generation: budget SATA models use XOR scrambling without AES, while NVMe models use hardware AES-256 encryption.

Samsung (Elpis, Phoenix, Pascal): Factory Access Mode

Samsung SSDs use always-on AES-256 encryption with the MEK fused into controller silicon during factory initialization. The controller maintains multiple copies of its firmware table architecture across the NAND. A power loss during an FTL cascade write can corrupt all copies simultaneously, leaving the drive in one of several panic states: 0GB reported capacity, a 0E S.M.A.R.T. media error counter on early Elpis firmware revisions, a complete drop off the PCIe bus, or a stuck read-only state that rejects all write commands.

PC-3000's Samsung SSD module issues Vendor-Specific Commands (VSCs) over the PCIe or SATA interface to force the controller into Factory Access Mode (also called Technological Mode on Samsung drives). This approach differs from the Silicon Motion procedure in a key way: it does not inject a full virtual translator into host RAM. Instead, the controller's own firmware executes the VSCs, reads the NAND through its intact AES-256 decryption pipeline, & streams plaintext data back to the PC-3000 workstation.

Board-level stabilization comes first. The MEK is hardware-bound, so the original controller must be alive. A FLIR thermal camera localizes the failed component; a Hakko FM-2032 on an FM-203 base station replaces the shorted PMIC or voltage regulator. Once the controller initializes, PC-3000 can also use VSCs to shift NAND read reference voltages dynamically (read-retry) for drives with NAND cell degradation. NVMe board repair runs $600–$900.

Silicon Motion (SM2258, SM2259, SM2262): Volatile Loader Injection

Silicon Motion controllers implement AES-256 with optional TCG Opal support & NANDXtend ECC, which combines LDPC hard/soft decoding with RAID-like page parity for error correction. FTL corruption from a power loss during garbage collection causes either a BSY (Busy) hang on the ATA interface or a ROM Mode state where the drive reports 1GB or 0GB capacity. Both states mean the controller's firmware can't build a valid FTL from the NAND contents.

Recovery starts with a permanent Safe Mode pin short: the technician holds the ROM signature pins shorted while applying power, forcing the controller to ignore corrupted NAND firmware entirely. PC-3000's Silicon Motion utility then uploads a volatile loader (LDR) to the controller's SRAM. The LDR must match the exact controller & NAND combination. An SM2258XT paired with SanDisk 64L BiCS3 TLC NAND requires a different loader than the same controller paired with Micron B0KB QLC NAND. Loading the wrong LDR produces ECC failures & no readable data.

Once the correct LDR executes, it disables background processes (TRIM, garbage collection), slows the clock for stable single-channel NAND access, & extracts the Configuration Page (CP) modules from the NAND Service Area. PC-3000 then builds the virtual FTL translator entirely in host workstation RAM, using block sequence numbers & page headers extracted from the NAND. AES decryption happens transparently through the original controller executing the LDR. SATA SSD board repair runs $450–$600; firmware-level FTL reconstruction runs $600–$900.

Phison (PS3111, PS5012, PS5016, E18): Generational Encryption Variance

Phison's controller lineup spans a wider encryption range than any other manufacturer. The PS3111-S11 (budget SATA, DRAM-less) does not use AES-256; it applies XOR scrambling only. PC-3000 can reverse the XOR scrambling polynomial & extract data from these drives even with a dead controller through chip-off, because the "encryption" is a reversible mathematical transform, not a cryptographic cipher.

The PS5012-E12 (NVMe) steps up to AES-256-XTS, RSA-2048 firmware signature verification, & HMAC_DRBG key generation. Firmware on this controller is cryptographically signed; unsigned modifications are rejected. The PS5016-E16 varies by OEM implementation: some products like the Seagate FireCuda 520 use XOR randomization rather than full AES-256. The PS5018-E18 enforces strict AES-256 hardware encryption. Chip-off on an E18 drive yields ciphertext.

SATAFIRM S11 Firmware Failure on Phison PS3111

When the PS3111's DRAM-less FTL (stored directly in TLC NAND) corrupts due to NAND cell degradation, the controller drops to its BootROM & reports the factory identity string "SATAFIRM S11" with 0GB capacity in BIOS. The drive rejects all standard ATA read/write commands. Data is still present on the NAND chips, but the controller can't build a valid FTL to access it.

Recovery requires a momentary pin short during power-up (unlike Silicon Motion's permanent short). PC-3000's Phison utility injects a volatile loader to the controller's SRAM, then scans surviving NAND page headers to reconstruct the primary & backup copies of the Flash Translation Layer (FTL). A controller-specific complication: corrupted S.M.A.R.T. logs can cause an infinite reboot loop during FTL rebuild. PC-3000 must clear or bypass the corrupted S.M.A.R.T. tables before extraction proceeds. SATA SSD firmware recovery runs $600–$900.

What Happens When Someone Executes a PSID Revert?

A PSID (Physical Security ID) revert destroys all data on a self-encrypting drive. The operation deletes the existing DEK & generates a new one. Every byte of ciphertext on the NAND becomes permanently unreadable because the original decryption key no longer exists. No lab, no tool, & no amount of money can reverse a PSID revert.

The PSID is a 32-character alphanumeric code printed on the drive's physical label. Drive manufacturers include it as a last-resort factory reset mechanism for locked drives. The intended use case is an IT department recycling a locked drive for reuse when the authentication credentials are lost. The PSID revert wipes the encryption state, generates fresh keys, & returns the drive to factory defaults.

The PSID revert scenario is distinct from Secure Erase or Crypto Erase. All three destroy the DEK, but PSID revert also resets the drive's ownership & authentication state. The outcome is the same for data recovery: once the DEK is gone, the ciphertext is permanent. AES-256 has no known cryptographic weaknesses that would allow brute-force recovery of the key in any practical timeframe.

Frequently Asked Questions