Slashdot Mirror
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.
A closed implementation, no independent review (until now), what can possibly go wrong?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
...keeping people out. Or in. whatever.
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.
I did some research on Phison based USB flash drives a couple years ago, and finally came back to the research a couple months ago. These controllers are dirt cheap, so they're prolific and in all kinds of flash drives. Brand name doens't really mean anything, nor do USB product ID and vendor IDs matter. The only way you can tell what kind of flash controller is on the inside of your USB flash drive is by either sending a vendor specific SCSI CDB at them, or ripping them apart and actually looking at the chip.
Anyway: details of the vuln - The phison 2251 (and similar) based drives have a way to split (think partitioning) the flash drive into separate regions, and then optionally lock access with a password. They let you choose the percentage of the split, so you could have a 2G "public" volume and a 2g "private" volume on a 4G stick, with the "private" volume requiring a password to make it visible to your OS.
But that password -- it's only used for visibility of the "private" volume. You can either re-position the split mark, or entirely disable the public/private split and make the drive one big volume again. It's not a configuration lock, it's a volume visibility lock. Stupid, stupid, stupid.
da w00t. mtfnpy?
On some of the tested drives, the user's password isn't actually used to encrypt the key. Those same drives also have vendor-specific commands to run arbitrary code on the SSD's CPU, so you can bypass the password check and gain access.
Insane, no? It's 2018 FFS. This isn't some sophisticated attack on the encryption algo or freezing the RAM to extract keys, it's just purely inept engineering and shouldn't be happening in this day and age. It's damn infuriating.
I browse on +1 so AC's need not respond, I won't see it.
Providing you don't use full disk encryption, in which case TPM will store the user credentials for the encryption only and then bitlocker will offload the rest to your hardware.
You can check this by running "manage-bde -status c:" as administrator and hope you don't see Hardware Encryption enabled.
It may be high quality engineering where the goals are not to provide customer security but to provide corporate profits.
Actually, keeping the password in the manual might be the safest place for it!
From the article:
This charitably assumes the "faults" are actual human error and not intentional.
Indeed. The interesting thing isn't that there were master passwords and insecure implementations. The interesting part is that this was a surprise to literally anyone. I'm just waiting for the other shoe to drop and the AES-NI instruction set to be revealed to store decryption keys in some non-volatile and retrievable part of Intel CPUs. And/or something similar for other CPU families. I'd put money on there at the very least being special batches of CPUs already in circulation that do this.
I highly, highly recommend the VeraCrypt project. Open source whole-disk encryption that has been source-audited. You do have to be careful with this software when doing Windows upgrades, since Microsoft (purposefully) doesn't play well with it in those cases. But with just a little care and attention, this is by far your best bet for reliable secure encryption.
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.