Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Encryption

Flaws in Self-Encrypting SSDs Let Attackers Bypass Disk Encryption (zdnet.com) 105

Posted by msmash from the security-woes dept.
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.
This discussion has been archived. No new comments can be posted.

Flaws in Self-Encrypting SSDs Let Attackers Bypass Disk Encryption More

Flaws in Self-Encrypting SSDs Let Attackers Bypass Disk Encryption

Comments Filter:

  • Nobody smart trusts these anyways (Score:5, Informative)

    by gweihir ( 88907 ) on Monday November 05, 2018 @04:08PM (#57596282)

    A closed implementation, no independent review (until now), what can possibly go wrong?

    • Re:Nobody smart trusts these anyways (Score:5, Insightful)

      by 93 Escort Wagon ( 326346 ) on Monday November 05, 2018 @05:41PM (#57596832)

      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)

        by Anonymous Coward

        So long as it utilizes the AES-NI instruction set in modern processors, then yeah.

        • Re: (Score:1)

          by Anonymous Coward

          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)

            by Agripa ( 139780 )

            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

        • Umm... did someone audit those parts of modern processors?

    • 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)

        by sjames ( 1099 )

        Stupid is as stupid does.

        TFA presents us with exhibit A.

        The alternative is that they're all in Big Brother's back pocket.

      • If that is your criteria you've basically labelled the entire world dumb

        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)

          by gweihir ( 88907 )

          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".)

        • 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.

        • And they are allowed to breed, gone are the days when we left the morons and the physically disabled to die in the wild. We are fucking with natural selection, I think it was Jim Jeffries who said it best (and I am paraphrasing here) "If your father is a dumb cunt, and your mother is a dumb cunt, then chances are you are a dumb cunt."
          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)

        by gweihir ( 88907 )

        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.

        • 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.

      • 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)

      by Anonymous Coward

      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)

      by Excelcia ( 906188 ) <slashdot@excelcia.ca> on Monday November 05, 2018 @07:19PM (#57597224) Homepage Journal

      From the article:

      Master passwords and faulty standards implementations [emphasis added]

      This charitably assumes the "faults" are actual human error and not intentional.

      what can possibly go wrong?

      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)

        by AmiMoJo ( 196126 )

        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)

          by gweihir ( 88907 )

          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)

            by AmiMoJo ( 196126 )

            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)

              by gweihir ( 88907 )

              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.

              • Well, you can, but it is a) one shot (it becomes worthless when discovered)

                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

        • 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)

            by AmiMoJo ( 196126 )

            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)

        by gweihir ( 88907 )

        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)

        by Agripa ( 139780 )

        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

    • 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)

        by gweihir ( 88907 )

        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.

  • 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)

      by EvilSS ( 557649 ) on Monday November 05, 2018 @04:23PM (#57596396)

      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)

        by EvilSS ( 557649 )
        ...keeping people out. Or in. whatever.

      • Re: (Score:1)

        by Anonymous Coward

        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)

          by EvilSS ( 557649 )

          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.

          • It may be high quality engineering where the goals are not to provide customer security but to provide corporate profits.

      • 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)

          by EvilSS ( 557649 )
          If keys are stored in an encrypted enclave where it's easy to retrieve, or, worse, a drive uses a publicly available (it's in the manual!) then yea, it's useless. That's just too low of a level of effort for the attacks to consider it any more secure than an unencrypted disk.

          • Re: (Score:3, Funny)

            by Anonymous Coward

            Actually, keeping the password in the manual might be the safest place for it!

        • Many people don't even use disk encryption and just assume their computer isn't going to be stolen.

          ...or we dont see the point in encrypting video games and dvd rips, regardless of computer theft rates.

      • Re: (Score:2)

        by Dr. Evil ( 3501 )

        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

    • Or it is stored encrypted, but the encryption key used is internal to the drive and the password just unlocks the use of that encryption (internal key). Hence they can have multiple passwords, yours, the vendors, and a three letter agency, which all simply enables the internal encryption keys. Which means you are basically just down to password level security.

      -- disclaimer: I know nothing

  • bitlocker TPM + AD backup is good and lets you recover as well.

  • I hope it's government agencies behind it all (Score:4, Insightful)

    by Anonymous Coward on Monday November 05, 2018 @04:21PM (#57596376)

    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)

      by Anonymous Coward

      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)

      by AHuxley ( 892839 )
      PRISM for your data not just your OS and communications.

    • Re: (Score:2)

      by Agripa ( 139780 )

      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)

    by Anonymous Coward

    Time for a FOSS firmware for SSDs

  • Don't trust this (Score:5, Insightful)

    by duke_cheetah2003 ( 862933 ) on Monday November 05, 2018 @04:50PM (#57596560) Homepage

    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.

    • 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)

        by Anonymous Coward

        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.

      • 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.

        • 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)

      by AmiMoJo ( 196126 )

      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.

      • 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)

          by AmiMoJo ( 196126 )

          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)

    by Da w00t ( 1789 ) on Monday November 05, 2018 @04:54PM (#57596584) Homepage

    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.

  • Wouldn't it be more spectacular to report on something that is actually safe to use, rather than all these old run-of-the-mill reports of the usual bullshit?

Slashdot Top Deals

To stay youthful, stay useful.

Close