Samsung 840 EVO SSD - disk encryption key exposed through wear-levelled NAND and vendor-specific commands: The drive

Impact

The drive stores key material in ordinary wear-levelled flash. Because the FTL never overwrites in place, changing the password leaves the OLD key version sitting in a stale physical block that vendor-specific commands can still reach. So even a drive whose password was rotated - the exact hygiene step an operator performs between customers - still hands over a key that decrypts the previous tenant's data. BREAKS TENANT HANDOFF, and it breaks it in the specific way that defeats the mitigation most operators would reach for: rotating the credential is not enough, because the old key is physically still there.

Who can reach it

Anyone holding the physical drive who can issue vendor-specific (undocumented) ATA commands to the controller - the next bare-metal tenant, an RMA handler, or a buyer of decommissioned hardware. Requires no knowledge of any current or previous password.

What to do

No firmware fix restores the guarantee, because the exposure is old key material already committed to NAND; flashing new firmware does not scrub blocks the FTL has retired. Physically destroy any 840 EVO that ever held tenant data. Going forward, do not use drive-managed encryption as the tenant boundary - use LUKS/dm-crypt with an operator-held key so that 'erase' is a key-deletion event in your KMS, not a request to the drive. This is also the canonical argument for why a wear-levelled device can never prove sanitization to you: the blocks that matter are the ones the drive has already hidden from the host address space.

References