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.
Chip-off NAND reads yield ciphertext on encrypted drives.
Desoldering the NAND chips and reading them directly with a programmer produces encrypted data. Without the controller's MEK (or the Secure Enclave key on Apple devices), this data cannot be decrypted. Chip-off recovery is not a viable technique for hardware-encrypted SSDs unless the controller itself can be made functional again to perform the decryption.
Encryption Behavior by Controller Manufacturer
| Controller | Encryption Default | Recovery Implication |
|---|---|---|
| Samsung (Elpis, Phoenix, and others) | AES-256 always-on | NAND reads require the original controller. Controller swap loses the MEK. |
| Phison (PS3111, E12, E18) | Data scrambling always-on; AES optional | Older Phison SATA controllers use scrambling without AES. PC-3000 can de-scramble. Newer NVMe models use AES. |
| Silicon Motion (SM2258, SM2259, SM2262) | AES-256 always-on | MEK tied to controller. PC-3000 SSD module can access data through the controller's diagnostic path if the controller initializes. |
| Marvell (88SS1074, 88SS1084) | AES-256 always-on | Similar to Samsung: controller replacement without key transfer renders data unreadable. |
| Apple T2/M-series | AES-256 via Secure Enclave | Key bound to silicon. Board repair is the only recovery path if the SSD controller fails. |
Frequently Asked Questions
Why does chip-off recovery not work on encrypted SSDs?
Chip-off reads the raw NAND contents, which are ciphertext if the controller encrypted the data. The encryption key is stored in the controller or secure element, not on the NAND chips. Without the key, the data cannot be decrypted.
Can data be recovered from an Apple T2 or M-series Mac with a failed SSD?
The Secure Enclave key is bound to the specific silicon. If the SSD controller fails but the T2/M-series chip works, board-level repair to restore the SSD controller is the recovery path. If the T2/M-series chip is destroyed, the key is lost and data is unrecoverable.
If you are experiencing this issue, learn about our SSD recovery service.