Flaws in Self-Encrypting SSDs Let Attackers Bypass Disk Encryption (zdnet.com)
An anonymous reader writes: Researchers have found flaws that can be exploited to bypass hardware encryption in well known and popular SSD drives. Master passwords and faulty standards implementations allow attackers access to encrypted data without needing to know the user-chosen password.
SSDs from Micron (Crucial) and Samsung are affected. These are SSDs that support hardware-level encryption via a local built-in chip, separate from the main CPU. Some of these devices have a factory-set master password that bypasses the user-set password, while other SSDs store the encryption key on the hard drive, from where it can be retrieved. The issue is worse on Windows, where BitLocker defers software-level encryption to hardware encryption-capable SSDs, meaning user data is vulnerable to attacks without the user's knowledge. More in the research paper.
SSDs from Micron (Crucial) and Samsung are affected. These are SSDs that support hardware-level encryption via a local built-in chip, separate from the main CPU. Some of these devices have a factory-set master password that bypasses the user-set password, while other SSDs store the encryption key on the hard drive, from where it can be retrieved. The issue is worse on Windows, where BitLocker defers software-level encryption to hardware encryption-capable SSDs, meaning user data is vulnerable to attacks without the user's knowledge. More in the research paper.
If the NSA, CIA or whoever approaches these companies and forces them to backdoor their encryption, that would be satisfying because it would at least make rational sense.
But if it's incompetence behind it Every. Single. Time. that would just be seriously depressing.
It's sounding like the data isn't stored encrypted, just their implementation with the chip gives you the illusion it is so, and the exploit shows it.
Is this right?
No, it's wrong. The data is encrypted, however in one case, there is a hard-coded backdoor password, and in the other the keys are stores in non-encrypted storage.
It's like locking your front door but leaving the key under the mat. The door is locked, but it's not very useful at keeping people.
I browse on +1 so AC's need not respond, I won't see it.
I wouldn't ever trust a drive's "self-encryption" whatnots. Do it yourself, with tools you know and trust, like TrueCrypt (yes it still works fine.), LUKS, VeraCrypt (have not tried this one.) or whatever else you fancy. Never trust the manufacturers solution, it's probably backdoored even if it wasn't easily exploitable as this suggests.
Yeah, it's not like there's *that* much of a performance penalty using your OS's encryption - or something like VeraCrypt.
#DeleteChrome
No, they're actual flaws. The specs are a clusterfuck of every possible feature that every member of the standards committee could think up, explained in a muddled and confusing manner that practically guarantees interop problems, and implemented by vendors who see it as a necessary checkbox item to allow them to meet USG requirements docs but nothing more. It's exactly, totally what I'd have expected from the design process that created them, the only surprise is that it took this long to find the holes.
Oh, and the root cause of the problem is still there, and it isn't getting fixed any time soon, if ever. These things will never be secure.