Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by msmash on 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.

105 comments

  1. Really? by Anonymous Coward · · Score: 0

    Are they flaws, or "government imposed back doors"?

    1. Re:Really? by Anonymous Coward · · Score: 0

      And by "back doors", do you mean insecure ports and APIs or do you mean anal sex?

    2. Re:Really? by arglebargle_xiv · · Score: 3, 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.

    3. Re:Really? by Anonymous Coward · · Score: 0

      I think that's "back hole" these days.

    4. Re:Really? by Agripa · · Score: 1

      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.

  2. Nobody smart trusts these anyways by gweihir · · Score: 5, Informative

    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.
    1. Re:Nobody smart trusts these anyways by 93+Escort+Wagon · · Score: 4, Insightful

      Yeah, it's not like there's *that* much of a performance penalty using your OS's encryption - or something like VeraCrypt.

      --
      #DeleteChrome
    2. Re:Nobody smart trusts these anyways by thegarbz · · Score: 1

      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.

    3. Re: Nobody smart trusts these anyways by Anonymous Coward · · Score: 1

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

    4. Re:Nobody smart trusts these anyways by Anonymous Coward · · 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. Easy to drill and get into - however it is clearly evident of entry - blast marks whatever. So far every IOT or computer hardware does not have audit software to even report a change. That has to change.

    5. Re:Nobody smart trusts these anyways by sjames · · Score: 1

      Stupid is as stupid does.

      TFA presents us with exhibit A.

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

    6. Re:Nobody smart trusts these anyways by Anonymous Coward · · Score: 0

      ...at the same time this research paper is targeting EXTREMELY old (by the standards of SSD's today) SSD's, all of which have been known for years now to have issues and problems with their TCG Opal implementations if they even offer one.

      This research paper is targeting only the dirt-cheap SATA stuff also, there's not a single NVMe drive in the list or anything newer than Samsung's 850 series or Crucial's MX300 series. So it's targeting hardware the vendors don't even offer directly anymore.

      Samsung doesn't even have the 850 Evo for sale on their own site, that line is on the 860's with the 870's about to be released. For the 9xx series they're already on 970.

      As for Crucial, they haven't offered the MX300's for a'while now, their current offering is the MX500, they skipped over MX400 entirely.

      As for the external USB flash drives, they were never advertised as secure or encrypted, they offer a basic password lock but it's not a drive advertised as having any form of business-class security.

      This was a 'finish a paper to graduate' nothing more, and having such a fatalistic headline when all the paper actually is saying is "This old, broken stuff that we already had lots of forum posts about being broken? It's really badly broken. Surprise!"

      - WolfWings, too lazy to login to /. even when I have a point to make.

    7. Re: Nobody smart trusts these anyways by Anonymous Coward · · 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 support full speed SSD read/write (several hundred MB/s) Some space might have to be unused to achieve this. It should also support as many IOPS as an unencrypted SSD.
      2. The OS should be able to securely unlock the drive at power on, or once a day through the use of 2 factor authentication (i.e. smart card). At power on, this should be little more than a secure bios routine, and in some case that may be all there is.
      3. Once unlocked, the key should not be retrievable.
      4. The drive should be twitchy. If there is any sign of a removal of the drive from the system, or any number of conditions, then the key should be deleted from drive ram, and have to be reloaded.

      Also AES-NI implies the key is present in memory somewhere, or at least in processor registers. That is not necessarily more secure. That being said, I've coded examples with AES-NI. It is definitely very useful.

    8. Re:Nobody smart trusts these anyways by arglebargle_xiv · · Score: 1

      It doesn't matter what the age of the implementation is, see this post 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 the resources, however.

    9. Re:Nobody smart trusts these anyways by sg_oneill · · Score: 1

      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.

      --
      Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
    10. Re:Nobody smart trusts these anyways by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    11. Re:Nobody smart trusts these anyways by gweihir · · Score: 1

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

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    12. Re: Nobody smart trusts these anyways by Opportunist · · Score: 2

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

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    13. Re:Nobody smart trusts these anyways by Opportunist · · Score: 1

      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 and review and update.

      That's basically what you may expect, at the most, from the average person. Not because they're stupid, but simply because that's not their main field of expertise.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    14. Re:Nobody smart trusts these anyways by thegarbz · · Score: 1

      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.

    15. Re:Nobody smart trusts these anyways by thegarbz · · Score: 1

      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.

    16. Re:Nobody smart trusts these anyways by gweihir · · Score: 1

      Does not match my experience.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    17. Re:Nobody smart trusts these anyways by Anonymous Coward · · Score: 0

      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.

    18. Re:Nobody smart trusts these anyways by thegarbz · · Score: 1

      Cool story. Matches mine though.

      *Posted from my work computer, with our wonderfully encrypted drive from our trusted partner Microsoft.

    19. Re:Nobody smart trusts these anyways by LordWabbit2 · · Score: 1

      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 that section of his comedy show and it's even funnier than I remembered.
      "Society is very accommodating to dumb cunts, they even have weekly meetings where they all get together and sing songs, it's called a church, and they've never turned away a dumb cunt, they love dumb cunts, they don't like the smart ones, with all the questions."

      --
      There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
    20. Re: Nobody smart trusts these anyways by Agripa · · 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.

      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 whole disk encryption matter for SSD write speed unless deduplication or compression is relied on? As I recall, SandForce does this to decrease write amplification but I always thought it was a false economy like TRIM.

    21. Re:Nobody smart trusts these anyways by Agripa · · Score: 1

      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.

    22. Re:Nobody smart trusts these anyways by Anonymous Coward · · Score: 0

      History shows you can piss right off with that "closed implementation" argument.

  3. so the datas not really encrypted by G00F · · Score: 1

    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?

    --
    The spirit of resistance to government is so valuable on certain occasions that I wish it to be always kept alive
    1. Re:so the datas not really encrypted by EvilSS · · 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.

      --
      I browse on +1 so AC's need not respond, I won't see it.
    2. Re:so the datas not really encrypted by EvilSS · · Score: 2

      ...keeping people out. Or in. whatever.

      --
      I browse on +1 so AC's need not respond, I won't see it.
    3. Re:so the datas not really encrypted by Anonymous Coward · · 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.

    4. Re:so the datas not really encrypted by Fly+Swatter · · Score: 1

      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

    5. Re:so the datas not really encrypted by CastrTroy · · Score: 1

      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.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    6. Re:so the datas not really encrypted by EvilSS · · Score: 1

      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.

      --
      I browse on +1 so AC's need not respond, I won't see it.
    7. Re:so the datas not really encrypted by EvilSS · · Score: 2

      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.
    8. Re:so the datas not really encrypted by Anonymous Coward · · Score: 0

      No, it is encrypted, but there exist methods to get around that fact.

      This is more of a case where the door is locked, but the key is under the doormat.

    9. Re:so the datas not really encrypted by Darinbob · · Score: 2

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

    10. Re:so the datas not really encrypted by Anonymous Coward · · Score: 3, Funny

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

    11. Re:so the datas not really encrypted by Rockoon · · Score: 1

      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.

      --
      "His name was James Damore."
    12. Re:so the datas not really encrypted by Dr.+Evil · · Score: 1

      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 master password, then using a ATA Secure Erase would scramble the DEK and render the traces of the previously stored DEK unusable. ATA Secure Erase has always been sensible when setting these things up, but it's all black-box voodoo anyway.

  4. On disk? by Anonymous Coward · · Score: 0

    while other SSDs store the encryption key on the hard drive, from where it can be retrieved

    They didn't really think that one through did they.
    Reminds me of some shitty DOS file encryption utility I looked at 25-30 years ago. The password was stored in the encrypted file as comma-separated ascii number values. That might prevent grandma from looking at your diary but not much else.

    1. Re:On disk? by Anonymous Coward · · Score: 0

      LOL!

      "Hello Mr. burglar, welcome to my house. Here are the floor plans, which indicate where the valuables are stored. There's no guard dog, no security system and the house will be empty from 09:30 to 16:00 tomorrow and the day after."

    2. Re:On disk? by Bert64 · · Score: 1

      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.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  5. bitlocker TPM + AD backup is good and lets you rec by Joe_Dragon · · Score: 1

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

  6. I hope it's government agencies behind it all by Anonymous Coward · · 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.

    1. Re:I hope it's government agencies behind it all by Anonymous Coward · · 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.

    2. Re:I hope it's government agencies behind it all by AHuxley · · Score: 1

      PRISM for your data not just your OS and communications.

      --
      Domestic spying is now "Benign Information Gathering"
    3. Re: I hope it's government agencies behind it all by Anonymous Coward · · Score: 0

      Encryped disks sucks. Turned on MS encrypted folders once. After reinstall due to boot problems, all keys were wiped and encrypted ntfs folders unreadable.. openssl and secrets probably safer.

    4. Re: I hope it's government agencies behind it all by Anonymous Coward · · Score: 0

      Nope.
      These same companies produce Enterprise grade drives used for network attached storage arrays which are not vulnerable to any of these "attacks." It's an obvious case of the encryption behavior changed only in Consumer class devices.

    5. Re: I hope it's government agencies behind it all by Anonymous Coward · · Score: 0

      So it did its job, and you didn't understand how it works. Oh well.

    6. Re: I hope it's government agencies behind it all by Anonymous Coward · · Score: 0

      In defense of stupid MS.
      Always backup you encryption keys (Personal certificate store), after enabeling folder encryption.

      Had the same issue a while ago, and it took months to find the certificate backup I had stored somewere on some stick.

      But after that I imported the certificate to my new PC and deceypted the data feom the old.

      So in this one itâ(TM)s kinda your own mistake you dis not backup your encryption keys?

      Itâ(TM)s microsofts fault not telling you, tou should do that after activating folder encryption. So its a Tie?

    7. Re:I hope it's government agencies behind it all by Agripa · · Score: 1

      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.

  7. Those are deliberate flaws by Anonymous Coward · · Score: 0

    It doesn't take a master cryptographer to design a method that does not have these obvious flaws. You generate the key from the password or store a randomly generated key encrypted with a key. Anyone who stores unencrypted keys or transmits unencrypted keys over exposed links knows what they're doing. Those flaws are deliberate.

    1. Re:Those are deliberate flaws by Anonymous Coward · · Score: 0

      Anyone who stores unencrypted keys or transmits unencrypted keys over exposed links knows what they're doing.

      You give people too much credit.

    2. Re:Those are deliberate flaws by Anonymous Coward · · Score: 0

      Anyone who stores unencrypted keys or transmits unencrypted keys over exposed links knows what they're doing.

      Never attribute to malice that which is adequately explained by stupidity.

    3. Re:Those are deliberate flaws by Anonymous Coward · · Score: 0

      That is not adequately explained by stupidity. A large group of people can't be both intelligent enough to create a system of that complexity and collectively stupid enough to create an obvious flaw like that without noticing.

  8. Time for a FOSS SSD firmware by Anonymous Coward · · Score: 1

    Time for a FOSS firmware for SSDs

  9. Re:bitlocker TPM + AD backup is good and lets you by Anonymous Coward · · Score: 0

    According to the article Bitlocker will defer to the hardware encryption on the drive instead of using the TPM option, so yeah.

  10. Don't trust this by duke_cheetah2003 · · 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.

    1. Re:Don't trust this by Anonymous Coward · · Score: 0

      You're afraid of backdoors yet you willingly run TrueCrypt? Interesting...

    2. Re:Don't trust this by Anonymous Coward · · Score: 1

      That's why I run Veracrypt. Fascinating even.

    3. Re:Don't trust this by ArchieBunker · · Score: 1

      TrueCrypt was audited and found to be just fine. Just because it's no longer maintained doesn't mean it's insecure.

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
    4. Re:Don't trust this by 93+Escort+Wagon · · Score: 4, Informative

      VeraCrypt is just a maintained fork of the audited TrueCrypt code.

      --
      #DeleteChrome
    5. Re:Don't trust this by thegarbz · · Score: 1

      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.

    6. Re:Don't trust this by AmiMoJo · · Score: 1

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    7. Re:Don't trust this by Anonymous Coward · · 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.

    8. Re:Don't trust this by Anonymous Coward · · Score: 0

      Of course the manufacturer built in backdoors on purpose. This is because if the device is "encrypted" and the luser cannot remember the password, the manufacturer needs to be able to "break in" and override the encryption at will. THis is just the same thing as a phone that you can hook up a USB cable to a computer and send the "AT+BYPASS_ALL_SECURITY" command to, guess what, bypass all security.

    9. Re:Don't trust this by Anonymous Coward · · Score: 0

      Like Windows, not getting updates is an advantage. Beside the fact that it will work today the same as it did yesterday, and will work tomorrow the same as it does today -- for all values of "today" is an advantage. THe THree Letter Agencies won't be "slipping in" a backdoor via an update that way ...

    10. Re:Don't trust this by duke_cheetah2003 · · Score: 1

      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.

    11. Re:Don't trust this by duke_cheetah2003 · · Score: 1

      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 saturating USB 3.0.

      On SSD's, yes for the die-hard max performance, encryption may shave a few percentage points off your performance. Just have to ask yourself, is this worth it? I can't really agree that the performance hit from encrypted volumes is 'major' anymore. A little hit is the best I'll give in to.

      As a side note, I'm pretty such some encryption implementations can take advantage of built-in crypto whatnots in modern CPU's to help it do the processing. I would say this probably ok and secure, since the software is holding all the cards. I know BitLocker does, cuz I had that get enabled (Yes, Windows 10 just turned it on one day, out of no where. Gotta love microsoft!) on an Atom-based tablet I use sometimes, and you can't even tell the difference with bitlocker on or off, so it's got to be using some hardware assist to keep the speed up.

    12. Re:Don't trust this by AmiMoJo · · Score: 1

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    13. Re:Don't trust this by thegarbz · · Score: 1

      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 different than security through hopes and dreams.

      BitLocker is no better than built-in drive encryption

      And with that comment you've shown you didn't actually read my post.

  11. Re:"well known and popular SSD drives" by Anonymous Coward · · Score: 0, Offtopic

    It could be worse, they could be talking about how those automated teller atm machines need a personal identification pin number near the L.A. Angels stadium.

  12. Similar vulns found on common USB "thumb" drives by Da+w00t · · 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.

    --

    da w00t. mtfnpy?
  13. Re:bitlocker TPM + AD backup is good and lets you by Anonymous Coward · · Score: 0

    When BitLocker detects hardware encryption capability it blindly trusts it. In the worst case all you need to do to get "encrypted" data is to JTAG the drive and flip a switch in RAM as the paper suggests.

  14. Re:"well known and popular SSD drives" by UnknownSoldier · · Score: 0

    Hold on I need to enter my PIN number. =P

    --
    Redundant, noun, duplicate information. Also see: redundant

  15. Re:"well known and popular SSD drives" by Anonymous Coward · · Score: 1

    You're an obnoxious neck beard cunt.

  16. Re:"well known and popular SSD drives" by sconeu · · Score: 1, Offtopic

    Enter it into the ATM Machine's NIC Card using FOSS Software.

    --
    General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
  17. Paradigm change. by AndyKron · · Score: 1

    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?

    1. Re:Paradigm change. by Anonymous Coward · · Score: 0

      Why would anyone report something is safe to use? All it takes is one undiscovered bug to prove that statement a lie. Reporting something is safe is not only likely to be proven incorrect eventually, it's factually dangerous because it gets out the word 'this is safe' when that's not even demonstrable most of the time.

  18. Re:bitlocker TPM + AD backup is good and lets you by thegarbz · · Score: 3, 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.

  19. I want you to watch something... apk by Anonymous Coward · · Score: 0

    See subject & 1 of the inspirations in my life (for his being a GOOD man, f'd w/ by a scumbag + coming out ontop) https://www.youtube.com/watch?...

    APK

    P.S.=> ... & THAT is what I'm doing to "your kind" as Marcus Allen did... apk

    1. Re:I want you to watch something... apk by Anonymous Coward · · Score: 0

      Shut up retard. Go suck off your roommate in your $1 house before your start your shift at the glory hole at the Pilot Travel Center off of I81 near your house.

  20. It really isn't by jd · · Score: 1

    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/...
    https://www.digitaltrends.com/...

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re: It really isn't by Anonymous Coward · · Score: 0

      The Schneier article is nearly 10 years old... I'm sure MS improve BL in that time.

      You can check if its using your SED by

      manage-bde -status C:

  21. Have any other details on this? by Anonymous Coward · · Score: 0

    I could actually use it for keeping Linux and Windows partitions on separate volumes/mbrs.

    1. Re:Have any other details on this? by Anonymous Coward · · Score: 0

      Yeah that could be useful. Whenever I use my fat32/ext4 partitioned USB stick in a Windows 10 computer, it wants to format the ext4 partition. Would be better if it couldn't see it at all.

  22. Surprise by Excelcia · · Score: 5, Informative

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

    1. Re:Surprise by AmiMoJo · · Score: 1

      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/brute force attacks only) and the same goes for these SSDs, so anyone below state level probably can't get in.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    2. Re:Surprise by gweihir · · Score: 2

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:Surprise by gweihir · · Score: 1

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

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:Surprise by AmiMoJo · · Score: 1

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

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    5. Re:Surprise by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    6. Re:Surprise by Excelcia · · Score: 1

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

      This is literally the one thing that intelligence agencies have the most experience with.

      b) causes extreme problems for the CPU manufacturer when discovered

      Tell that to Cisco. They are still around and very much in business.

      If you think that Cisco is the only one to ever have this done, you are hopelessly naive. On every side. Huawei has got themselves into trouble for it. Remember the digital photo-frame virus distribution of over a decade ago? That was just a proof-of-concept. Compromised chips are rampant.

    7. Re:Surprise by gweihir · · Score: 1

      Cisco had a software problem. Apples and oranges.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Surprise by Excelcia · · Score: 1

      VeraCrypt supports several different algorithms, including my favourite, Serpent, 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 detect and recover encryption keys. It is actually the difficulty involved in doing that that makes me distrust AES-NI a little. This is the type of thing the NSA has done in the past. Recovering keys can be hard, so compromise them from the beginning, say with a weak PRNG they caused to be inserted into a NIST standard. Getting at AES from the side, say by paying or forcing Intel to backdoor AES-NI, is just the sort of thing the NSA would do.

      The problem with a threat assessment is you don't know, and likely can't know at the time you are putting in your safeguards, who the opponent will be. The issue with insecure SSDs, for example. Sure, that is likely not known to anyone outside serious hacker and state actor level circles. But who knows where my computer will end up, or if and when another release of state-actor-level penetration software will hit the streets like WannaCry? The fact that SSDs are today known to be vulnerable was certainly known to the NSA yesterday, and they certainly have rapid access tools. So even if I'm not trying to protect against state actors getting in, I need to also protect against their tools getting out. Which means I use the very best encryption I can without crippling my computer with computational overhead.

    9. Re:Surprise by AmiMoJo · · Score: 1

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    10. Re:Surprise by Agripa · · Score: 1

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

  23. Re: "well known and popular SSD drives" by Anonymous Coward · · Score: 0

    Hey, good job explaining the joke, you autistic sperglord

  24. Plenty of Smart People Trust them. by Dr.+Evil · · Score: 1

    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 cryptographic erase was always a sensible way to (supposedly) scramble the DEK from the factory delivered DEK (who knows where it gets its entropy?).

    The EVO850 with the master password feature disabled seems to be fine.... or am I missing something?

    1. Re:Plenty of Smart People Trust them. by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  25. Why? I shut you up Mr. "hotairware" by Anonymous Coward · · Score: 0

    See subject & see you "Run, Forrest: RUN!!!" vs. https://yro.slashdot.org/comme... & where's your "MILLION$" (vs. your millions of lies)?

    * ANSWER - it's not in your hotairware/notware + your LACK of money (or substance OR accomplishment you PITIFUL loser).

    APK

    P.S.=> In a way though? I thank GOD almighty for MILKSOP do-NOTHING "ne'er-do-wells" like you JEALOUS "Lil' Jowie" because its FREAKS & underachiever DEFICIENTS like you attacking me & LOSING that always makes ME look GOOD & you like the SHIT you KNOW you are, lmao... apk