Flaws in Self-Encrypting SSDs Let Attackers Bypass Disk Encryption (zdnet.com) 105
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.
Re:Really? (Score:4, Insightful)
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.
Re: (Score:2)
Controlling the standards committee to create the overly complex and flawed IPSEC standard is exactly what the NSA did so I expect the same thing happened here.
Nobody smart trusts these anyways (Score:5, Informative)
A closed implementation, no independent review (until now), what can possibly go wrong?
Re:Nobody smart trusts these anyways (Score:5, Insightful)
Yeah, it's not like there's *that* much of a performance penalty using your OS's encryption - or something like VeraCrypt.
Re: Nobody smart trusts these anyways (Score:1)
So long as it utilizes the AES-NI instruction set in modern processors, then yeah.
Re: (Score:1)
So long as it utilizes the AES-NI instruction set in modern processors, then yeah.
This shouldn't be this hard. The problem with AES-NI is you burn processor cycles for a task you could have used DMA reads on before. Your processor is busy enough. I suppose you could buy a couple more cores, but it is still not ideal.
Also, software encryption by default tends to encrypt the whole disk, which destroys SSD write speeds.
I'd rather have a hard disk that:
1. Does hardware encryption with the key you provide, which is transmitted to the hardware using well proven encryption. It should suppor
Re: (Score:2)
So long as it utilizes the AES-NI instruction set in modern processors, then yeah.
This shouldn't be this hard. The problem with AES-NI is you burn processor cycles for a task you could have used DMA reads on before. Your processor is busy enough. I suppose you could buy a couple more cores, but it is still not ideal.
Processor cores are cheap enough and can be repurposed to other tasks when AES is not required. They are also really fast and closely coupled with memory so performance is better. So the increased security of using a processor core for AES comes at a small cost and AES has other uses besides storage so it will be present anyway.
Integrating AES into the CPU is just another turn of the Wheel of Reincarnation.
Who thought encryption support on the mass storage device would be as secure as on the CPU?
Also, software encryption by default tends to encrypt the whole disk, which destroys SSD write speeds.
Why would
Re: (Score:3)
Umm... did someone audit those parts of modern processors?
Re: (Score:2)
Not that much performance penalty? DMA offloading does not work if the CPU has to get involved. 114MiB/s(1Gb/s link) over SMB is using less than 0.5% CPU right now. Just the simple math of 114MiB/s divided by 3GiB/s/core, which is near what AES-NI can do, is about 1% cpu on a quad core.
Often the CPU is involved doing memory copies to align and coalesce buffers anyway. In theory this should not be required with a good DMA agent but in practice, especially with network cards, it is but CPUs are really good at this.
Re: (Score:2)
If that is your criteria you've basically labelled the entire world dumb. It's not a very sensible way to go about solving the problem. Literally most of industry trust the process of outsourcing unverifiable expertise to a 3rd party.
Re: (Score:2)
Stupid is as stupid does.
TFA presents us with exhibit A.
The alternative is that they're all in Big Brother's back pocket.
Re: (Score:2)
Boy have I some bad news for you....
Yes, most of the world is dumber than a bag of rocks. Half the population has an IQ under 100. And all those motherfuckers can vote.
Re: (Score:2)
In addition. quite a few higher-IQ people are also pretty dumb because they never found out how to apply that intelligence to reality effectively. (I call that "lack of wisdom".)
Re: (Score:2)
Yes, most of the world is dumber than a bag of rocks.
Including those who think they can solve this problem simply by pointing it out. That was my point. Calling the world dumb is part of the problem.
Re: (Score:2)
At the very least if we have to let them live, we should stop them from breeding, we are just contaminating our own gene pool otherwise.
Heh, was curious so I youtubed [youtube.com] that
Re: (Score:2)
Hahahaha, no, it does not. We get asked how to find backdoors in existing code and when we inquire it turns out that there was outsourcing to somebody they do not trust after all. With the corruption spread by states (first and foremost the US), this will get worse.
Re: (Score:2)
Hahahaha, no, it does not. We get asked how to find backdoors
You get asked to find backdoors mostly in systems that are questionable. On the other hand the "trusted partner" space of the fortune 500 is a ratsnest of unverifiable security. This goes double for common hardware.
Re: (Score:2)
Does not match my experience.
Re: (Score:2)
Cool story. Matches mine though.
*Posted from my work computer, with our wonderfully encrypted drive from our trusted partner Microsoft.
Re: (Score:2)
People are not necessarily stupid, but they don't know how to protect themselves better. Worse, some have given up already, thinking that there is no way to be secure anyway, so why bother trying. Those that have not will just buy what's offered and hope for the best.
This is not the worst strategy, as long as they understand that security is a process, not a product. You don't buy "security", put it in the corner and forget about it. Security is something you have to get back to at least from time to time a
Re: (Score:1)
http://www.ata-atapi.com/ was pretty much the first to seriously question this.
Hiding stuff on engineering sectors, and undocumented drive commands.
Never trust what you cant see.
The security people are doing agood job this year. ME engine broken. Intel Spectre+ broken. Lookaside buffer broken. Much router firmware and backdoors - broken. SSD's ++ Backdoored. See a pattern here? And protocol faking is now in their sights, and that will really p**s off gov level snoopers.
Now compare that with a steel safe. Ea
Surprise (Score:5, Informative)
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 [veracrypt.fr] 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.
Re: (Score:2)
If you don't trust the CPU (you think the AES-NI instructions are backdoored) then how will VeraCrypt help? It runs on the CPU you are certain is backdoored, and this thus compromised.
Unless you make your own RISC-V CPU out of sand you are going to have to trust some back-box proprietary hardware. Rather than worry about that, it's more productive to look at what the capabilities of your opponents are. Is anyone offering tools to unlock VeraCrypt containers with strong passwords? It seems not (dictionary/br
Re: (Score:2)
You cannot actually backdoor something like AES or rather if you do it comes with an extreme risk of being found out and it will only help if you can force a specific key on the user (in which case you do not need that backdoor).
Some understanding of cryptography required to participate in this discussion...
Re: (Score:2)
You could backdoor the implementation of AES, e.g. storing the key in some hidden registers that can only be read with a special op-code. That would allow malware to steal keys from other processes using the AES-NI instructions.
Some understanding of CPUs required to participate in this discussion...
Re: (Score:2)
You cannot actually do that either. Well, you can, but it is a) one shot (it becomes worthless when discovered) and b) causes extreme problems for the CPU manufacturer when discovered. So, no, that does not work. Please stop fantasizing about things you do not understand.
Re: (Score:1)
This is just a special case of the problem, how do you ever act on intelligence obtained covertly without giving away that you know it and how you know it. For example, the breaking of Enigma was, according to many, a "one shot" deal. How do you explain being in the exact spot where a naval attack was going to be without giving away we were reading their coded messages? Well, the allies found numerous inventive ways of doing just
Re: (Score:2)
Cisco had a software problem. Apples and oranges.
Re: (Score:1)
VeraCrypt supports several different algorithms, including my favourite, Serpent [wikipedia.org], which is I believe one of the most secure ciphers ever designed. But it also supports disabling use of AES-NI instructions for AES. Its own native implementation is pretty damn fast too. Even if AES-NI is compromised, and I agree that the likelihood of that in the general population CPUs is less than one chance in ten, it would be intractably difficult to compromise a CPU's normal instruction path in a way to automatically
Re: (Score:2)
As you say it depends on the threat model. On-SSD encryption at least can't be compromised as easily as Veracrypt by malware running on the computer. With Samsung SSDs they lock out the firmware update once the drive is unlocked too, so you have to cold boot to do it.
I do both. OPALv2 on the SSD, and then additional Veracrypt containers for important stuff.
Re: (Score:3)
Personally, I do not like VeraCrypt. The designer thinks they know much more than they actually do and force me to use a really long password, despite my short one having more than enough entropy to be secure. That is not competence, that is arrogance and a desire to dominate people. I went back to the last version of TrueCrypt as that is still unbroken. My next one will be Windows virtualized on top of a Linux LUKS partition.
Re: (Score:2)
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.
That would be quite a trick. If Intel's high performance CPU process had non-volatile memory available, they would have been using it long ago. The various non-volatile memory types are incompatible with the highest performance logic processes.
But what you suggest could be done without non-volatile memory by for instance storing the key in a secret register to be accessed with a secret instruction sequence. They would only get caught once unless the exploit was masked as a deniable engineering oversight
Re: (Score:2)
It doesn't matter what the age of the implementation is, see this post [slashdot.org] for more details. Pretty much any Opal implementation is going to have bugs, security holes, and interop problems because of the way the specification was created. You can take the latest, greatest SSD, choose any one you like, and it'll still be riddled with bugs, it's just that security people don't have the resources to go through every single SSD ever created to find them all.
If you're someone of interest, your opponents will have t
Plenty of Smart People Trust them. (Score:2)
It's really dumb to assume otherwise.
BTW, if you think that having a master password on your device means that your encryption is sound, you probably wouldn't do much better setting up crypto in software. This kind of crypto doesn't quite handle the same use cases as software based crypto. It's not really sensible to do a direct comparison.
Some interesting bits from the paper: The EVO850 seems to have addressed an issue in the EVO840 storing the DEK before encrypting it with the user key. An ATA cryptog
Re: (Score:2)
The EVO850 with the master password feature disabled seems to be fine.... or am I missing something?
Well, you get the whole thing as a free add-on, so I would not expect too much anyways.
so the datas not really encrypted (Score:2)
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?
Re:so the datas not really encrypted (Score:5, Insightful)
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.
Re: (Score:3)
Re: (Score:1)
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.
Re: (Score:3)
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.
Re: (Score:3)
It may be high quality engineering where the goals are not to provide customer security but to provide corporate profits.
Re: (Score:2)
But things don't have to be 100% to be secure. Many people don't even use disk encryption and just assume their computer isn't going to be stolen. Things like user passwords on regular computers don't actually provide any real security as you can just put the disk in a different machine and read the data directly. Just because the security isn't 100% unbreakable doesn't mean it isn't useful.
Re: (Score:2)
Re: (Score:3, Funny)
Actually, keeping the password in the manual might be the safest place for it!
Re: (Score:2)
Many people don't even use disk encryption and just assume their computer isn't going to be stolen.
Re: (Score:2)
This isn't quite right either.
There's a hard-coded "backdoor" password called: MASTER PASSWORD. If you set it, it means that you might be the IT shop setting up machines for the organization. If you don't set it, it's like buying a lock with a master key and leaving the master key in the lock... because you're not going to use the master key anyway, right?
For the storage issue, it looks like the EVO 840 had a bug which the EVO 850 might have addressed. No disclosure etc. I'm not sure if setting the mas
Re: (Score:2)
-- disclaimer: I know nothing
Re: (Score:2)
It's actually fairly typical stupidity of security through obscurity... Someone along the chain, either the developers or the vendor has assumed that because they don't publish details of how it works noone will ever find out.
bitlocker TPM + AD backup is good and lets you rec (Score:2)
bitlocker TPM + AD backup is good and lets you recover as well.
Re:bitlocker TPM + AD backup is good and lets you (Score:4, Informative)
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 really isn't (Score:2)
Bitlocker has known issues. That's not a judgement on how serious they are, but it does disqualify it from being called good.
https://www.schneier.com/blog/... [schneier.com]
https://www.digitaltrends.com/... [digitaltrends.com]
I hope it's government agencies behind it all (Score:4, Insightful)
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.
Re: (Score:2, Interesting)
Of course it's the latter. There are OS limitations/considerations to the 'handshake' for booting off an encrypted volume, so they do not-even-obscurity shit like this for compatibility w/o building their own UEFI-signed boot kit, testing them...
It's actually a non-trivial thing to do that handshake securely, as even Truecrypt 7.1a showed.
Re: (Score:2)
Re: (Score:2)
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 would be a great exercise in rent seeking. Extract money from the company by shorting its stock once it is known that the exploit will be revealed. The company would be ruined.
Time for a FOSS SSD firmware (Score:1)
Time for a FOSS firmware for SSDs
Don't trust this (Score:5, Insightful)
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.
Re: (Score:1)
That's why I run Veracrypt. Fascinating even.
Re: (Score:2)
TrueCrypt was audited and found to be just fine. Just because it's no longer maintained doesn't mean it's insecure.
Re:Don't trust this (Score:5, Informative)
VeraCrypt is just a maintained fork of the audited TrueCrypt code.
Re: (Score:2)
And when you go to Truecrypt's website it will suggest you instead use Bitlocker and even provide instructions for you to do so.
When Bitlocker detects hardware encryption is present, supported, and you decide to opt for full disk encryption it will offload it to hardware without ever prompting or indicating this fact to the user.
So I would suggest don't point people to Truecrypt. You're sending mixed messages.
Re: (Score:1)
DERP, the program is no longer supported but that doesn't mean it doesn't work. Your lazy suggestion basically got scared off by a placeholder site, you have no idea whether or not it actually works - and it does. It's very useful even now.
Re: (Score:2)
And when you go to Truecrypt's website it will suggest you instead use Bitlocker and even provide instructions for you to do so.
Microsoft's BitLocker is insecure. It's fricking MICROSOFT for gods sake. They couldn't secure something if their life depended on it. Also, backdoors, non-open source code that can't be audited. BitLocker is no better than built-in drive encryption: Ie worthless.
Re: (Score:2)
Microsoft's BitLocker is insecure.
[Citation needed]
It's fricking MICROSOFT for gods sake.
That's not a citation. When was the last time you hacked NTIDs, or for a more direct approach provide examples of cases that show Bitlocker can be fundamentally decrypted. I mean It's been around since Vista so by your assertion it should have more holes than Swiss cheese.
Also, backdoors, non-open source code that can't be audited.
Interestingly the only open source security product that has been audited is now completely defunct and the only version audited was several versions behind the last active one. Security through obscurity isn't that differ
Re: (Score:2)
It depends on your needs. Even with this vulnerability of requires significant skill and effort to bypass the lock, so it's still very effective against most adversaries and has zero performance cost.
If you need SSD performance it's the only option. VeraCrypt is fantastic but there is a major performance hit, especially if you disable AES acceleration because if you don't trust the SSD presumably you don't trust that either.
Security is always a trade off.
Re: (Score:2)
If you need SSD performance it's the only option. VeraCrypt is fantastic but there is a major performance hit, especially if you disable AES acceleration because if you don't trust the SSD presumably you don't trust that either.
Not sure I can agree with this. Computer performance has been steadily (if slowly) improving, especially in the multi-core arena. I can tell you, I barely notice the presence of LUKS of all my linux machines. If there's a performance hit to LUKS, I can barely feel it.
One metric of TrueCrypt I can report for sure: There's no difference between a USB 3.0 device raw formatted and TrueCrypt formatted. You get the same speed read/write performance, which is the limit of USB 3.0, so the device + crypt is sat
Re: (Score:2)
I've done a fair bit of real world testing with VeraCrypt. On an SSD the performance hit is measurable but for most purposes manageable. The main hit is to latency of course, so it depends if your application is heavily dependent on that.
That's using AES-NI, mind. And there are other issues, like Veracrypt doesn't properly pass through TRIM commands it seems. It claims to support it but my drives get un-TRIMmed anyway.
Similar vulns found on common USB "thumb" drives (Score:5, Informative)
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.
Paradigm change. (Score:2)
Re: (Score:1)
Hold on I need to enter my PIN number. =P
--
Redundant, noun, duplicate information. Also see: redundant
Re: (Score:1, Offtopic)
Enter it into the ATM Machine's NIC Card using FOSS Software.
Re: (Score:1)
You're an obnoxious neck beard cunt.