back to article Solid state of fear: Euro boffins bust open SSD, Bitlocker encryption (it's really, really dumb)

Fundamental flaws in the encryption system used by popular solid-state drives (SSDs) can be exploited by miscreants to easily decrypt data, once they've got their hands on the equipment. A paper [PDF] drawn up by researchers Carlo Meijer and Bernard van Gastel at Radboud University in the Netherlands, and made public today, …

Page:

  1. muhfugen

    Not sure why you (or the twitter guy) is blaming Microsoft. They're just using a standards based API. Its the drive vendor's fault for this vulnerability. Also this has nothing to do with SSDs, there are plenty of self encrypting HDDs.

    1. Anonymous Coward
      Anonymous Coward

      Really?

      Not sure why you (or the twitter guy) is blaming Microsoft.

      What? Is this your first day on El Reg?

      1. Yet Another Anonymous coward Silver badge

        Re: Really?

        Not sure why you (or the twitter guy) is blaming Microsoft.

        You turn on full disk encryption in your corporate standard enterprise grade Windows operating system and it actually doesn't bother but just trusts the unknown crappy made in China hardware encryption.

        1. whitepines Silver badge
          Thumb Down

          Re: Really?

          ....while sending all the data on the "encrypted" drive back to Microsoft anyway. Why bother? This shouldn't even count to tick the box for legal requirements.

        2. bazza Silver badge

          Re: Really?

          Be fair, the motherboard, CPU and memory chips are also hardware items that have to be trusted if one were to rely solely on software encryption. It's not unreasonable for MS to have assumed one has purchased good hardware.

        3. K Silver badge

          Re: Really?

          "China hardware encryption."

          They may manufacture it, but most often it's designed by Western and Korean companies!

        4. h4rm0ny

          Re: Really?

          You turn on full disk encryption in your corporate standard enterprise grade Windows operating system and it actually doesn't bother but just trusts the unknown crappy made in China hardware encryption.

          Just the same as it trusts your TPM module or the security certificates you've installed. Because that's normal. BitLocker DOES allow you to CHOOSE whether or not to use the drive's own on-board encryption. Which uses the same standard algorithms that others use so seems reasonable. If it defaults to using them well, they offer lower energy usage and a smaller performance hit. You can't really blame Microsoft for believing the hardware does what it is supposed to.

          Also, Samsung are Korean and their SSDs are generally considered to be industry leaders by most reviewers. Not exactly "crappy Chinese hardware" as you call it.

          If anyone wants to quickly check whether their system is using their drives own hardware encryption, run "manage-bde.exe -status" from the command line as administrator. It should say for the encryption method if it's using the drive's.

          1. Spazturtle Silver badge

            Re: Really?

            "Just the same as it trusts your TPM module or the security certificates you've installed. Because that's normal."

            Windows will only trust TPM modules that Microsoft has validated and certified, it doesn't just assume compliance.

          2. FrogsAndChips Bronze badge

            Re: manage-bde.exe -status

            Here's what it says, how do I figure out what encryption it's using?

            Disk volumes that can be protected with

            BitLocker Drive Encryption:

            Volume C: [OSDisk]

            [OS Volume]

            Size: 165.60 GB

            BitLocker Version: 2.0

            Conversion Status: Fully Encrypted

            Percentage Encrypted: 100.0%

            Encryption Method: AES 256

            Protection Status: Protection On

            Lock Status: Unlocked

            Identification Field: Unknown

            Key Protectors:

            Numerical Password

            TPM And PIN

            1. Anonymous Coward
              Anonymous Coward

              Re: manage-bde.exe -status

              "Encryption Method: AES 256"

              My understanding is that "Encryption Method: Hardware" means it's using the built-in encryption of the device, and anything else is windows own software encryption.

            2. h4rm0ny

              @FrogsAndChips Re: manage-bde.exe -status

              You're using Windows own in-built encryption. The line "Encryption Method" will be whatever is reported by the disk if it's using that. And whilst the disk could say "AES 256" it would almost certainly more likely say something like "SAMSUNG blah blah blah blah".

          3. jbuk1

            Re: Really?

            > run "manage-bde.exe -status"

            XTS-AES 128

            Looks like that's one of the Windows built in encryption methods.

            I'm using a Samsung Evo 870 but didn't enable Bitlocker until after Windows installation.

            I'm guessing the hardware encryption is only used when Bitlocker is enabled pre windows installations.

          4. Woodnag

            Bitlocker

            If MS wanted BL to be great, why is AES-128 the default, and passwords limited to 20 chars max?

          5. Anonymous Coward
            Anonymous Coward

            Re: Really?

            "Just the same as it trusts your TPM module or the security certificates you've installed."

            False. None of those are expected to offer any protection for a situation where hardware is in wrong hands. While that situation is the major real use case for hard drive encryption.

            No comparison and therefore every conclusion derived from that point of view is also totally wrong.

            "Not exactly "crappy Chinese hardware" as you call it."

            Any hard drive with encryption capability and master encryption password a) enabled and b) as an empty string is by default "crappy hardware". Being top of the crappy line is irrelevant.

          6. Tuomas Hosia

            Re: Really?

            "BitLocker DOES allow you to CHOOSE whether or not to use the drive's own on-board encryption. "

            No it doesn't, that's false. Actually you can't even see what encryption it is using, if any.

            And of course defaults to one drive offers.

            1. Woodnag

              Re: Really?

              Per an earlier comment:

              If anyone wants to quickly check whether their system is using their drives own hardware encryption, run "manage-bde.exe -status" from the command line as administrator.

              For mine it shows AES-256, which is how I configured it, not using the available hardware encryption on the Samsung EVO SSD.

        5. Robert Helpmann?? Silver badge
          Childcatcher

          Re: Really?

          It isn't just Bitlocker that trusts HW encryption. Other solutions at my work do the same thing. My guess is that this is a commonly utilized strategy. The thinking probably went along the lines of "If it doesn't have a native solution, implement encryption using our software but if it does, it is much easier to simply manage the built in HW solution than to turn it off and replace it with our own. Using the HW solution will undoubtedly produce better speed, too, so customers can enjoy a machine that is both responsive and secure."

        6. vtcodger Silver badge

          Re: Really?

          Ah come on folks. Is anyone really shocked at this point to find out that hardware storage encryption is less than perfect? Sounds to me like just another security issue. one of many thousands uncovered this year alone. And no hardware encryption isn't useless. Like most password schemes, it should be quite effective at keeping unsophisticated "users" -- the janitor, the babysitter -- from perusing one's financial records and porn collection. Really sophisticated attackers -- national agents, etc? Different story. But if you have secrets that interest the three letter folks, are you sure you should be trusting a company notorious for spying on its users to keep your secrets secret?

        7. Hans 1 Silver badge
          Windows

          Re: Really?

          Now, now, now ... It requires some skill to crack these SSD's , on the other hand, MS' BitLocker stores the encryption key on the tiny partition used by BCD when you upgrade (install the spring or fall update) ... netfs undelete is easier to get than a cracked firmware ...

    2. bombastic bob Silver badge
      Facepalm

      *FACEPALM*

      see icon

    3. Dave K Silver badge

      Because what MS have done is to effectively "outsource" the encryption. Any SSD that says "Hey, I can encrypt myself", Bitlocker just says "OK, sure thing!" without any further checking.

      End result, companies have enabled BitLocker to ensure that their data is safe, without realising that BitLocker is just allowing the drive to use its own encryption capabilities. And now many of those drives' encryption capabilities have turned out to be a bit shit. Because MS was just blindly trusting them all, they have to take some of the blame.

      When you allow everyone who claims to be a locksmith to fit their own lock, you're going to be broken into eventually...

      1. John Smith 19 Gold badge
        Unhappy

        "Because MS was just blindly trusting them all, they have to take some of the blame."

        True.

        Along with any other supplier of so-called "Encryption" software.

        Other takeaway.

        Implementing a complex standard is hard --> expensive.

        1. Dave K Silver badge

          Re: "Because MS was just blindly trusting them all, they have to take some of the blame."

          Many other suppliers of encryption software don't just trust all 3rd party hardware implementations however. If you encrypt your system disk with VeraCrypt (for example), it uses its own encryption algorithm. Hence the only way your disk can be compromised is if VeraCrypt's own encryption is compromised.

          It would be interesting to know if MS was testing and vetting SSD encryption from various vendors before approving BitLocker to utilise it, or whether they were just allowing any device that stated that it supported hardware encryption to go ahead. If it's the former, their testing clearly could have been better. If it's the latter, it's a major risk if Bitlocker is allowing untested and potentially insecure hardware encryption to take the place of its own encryption capabilities.

          1. Jack of Shadows Silver badge

            Re: "Because MS was just blindly trusting them all, they have to take some of the blame."

            Given that you have to be very comfortable with hacking systems on debug port and know exact details of hour the firmware works, I'd give Microsoft a pass on this one. There's not a lot of this flavor of hacker wandering around to be hired or that would even have anything to do with Microsoft, for that matter.

          2. h4rm0ny

            Re: "Because MS was just blindly trusting them all, they have to take some of the blame."

            It would be interesting to know if MS was testing and vetting SSD encryption from various vendors before approving BitLocker to utilise it, or whether they were just allowing any device that stated that it supported hardware encryption to go ahead. If it's the former, their testing clearly could have been better. If it's the latter, it's a major risk if Bitlocker is allowing untested and potentially insecure hardware encryption to take the place of its own encryption capabilities.

            Microsoft could well have tested this and still not found the problem, because the problem isn't with the encryption itself but an exploit on the attached password system. Nothing to do with AES. And these things have been out in the wild for a long time before this vulnerability has emerged and used by far more than just Microsoft. Microsoft is not everybody's parent. If someone plugs in hardware that later turns out to have a vulnerability, MS are not going to tell you at the time you can't use it.

        2. Anonymous Coward
          Anonymous Coward

          Re: "Because MS was just blindly trusting them all, they have to take some of the blame."

          "Along with any other supplier of so-called "Encryption" software."

          That's BS. Most of them actually do the encryption and do not leave it to anyone one who says 'hey I can do that for you'.

          We use SSH extensively and yea, it does the encryption nicely thank you.

          1. Justthefacts

            Re: "Because MS was just blindly trusting them all, they have to take some of the blame."

            “It does the encryption nicely thank you”

            Staying in your box, not thinking about the bigger picture.

            Those Spectre, Meltdown bugs etc, are a threat *precisely because* of the trade offs you made to do security in software. If the key storage and engine were in physically separated hardware, it wouldn’t have happened. “Trust”. You still had to trust underlying CPU hardware, that you knew nothing about.It turned out to be possible to recover keys held in software using timing channel attacks that “ought” not to be possible. It’s a human bias to trust things we know and distrust or ignore what we don’t, but it is just that, a bias.

            Once again. Security is hard. Really hard. If you do it yourself, you better be very sure that out of the other thousands of security professionals in the world, not one of them is smarter or more experienced than you. Be very, very sure. It only takes one. Otherwise, rely on certification.

        3. Scott 29

          Re: "Because MS was just blindly trusting them all, they have to take some of the blame."

          > Implementing a complex standard is hard --> expensive.

          Agree.

          Also, implementing it to a required level of securedness requires reading, both the how-to's and the academic papers showing weaknesses.

          Samsung was more forthcoming to the researchers than they were to me.

      2. LeahroyNake Bronze badge

        Cr@p analogy

        I'm no locksmith but I have replaced a few lock barrels....

        I'm also not an encryption genius but can implement it....

        I could NOT design either of them in a way that is secure.

    4. Anonymous Coward
      Anonymous Coward

      BBC Micro's FRAK! did a better job of encryption back in 1984.

      The 6502 assembly code used for the cassette protection on BBC Micro's FRAK! did a better job of encryption back in 1984.

      The cassette software protection decrypted itself 'as it went' based on the 6502 assembly code interrupt timings of the code itself. Modifying any of the code, changed the number of cycles a machine code instruction used, causing the code just ahead to scramble itself as it was been decrypted and fail to decrypt the game itself (it's software protection).

      Assuming no tampering, once unencrypted, it jumped to the new unencrypted game code lower in memory, changed the screen mode to 'Mode 2' which had the effect of erasing the memory where the decryption code was executed from/held in memory, covering its tracks.

      Clever stuff indeed back then even if it was just XORing the code with the interrupt timer to reveal it, fairly simple but clever.

      The best way to imagine this is the scene in Wallace and Gromit, "the wrong trousers", where Gromit lays down the train track in front of him as he goes, to follow and keep up with the Penguin, but also, additionally, removing the tracks from behind, to cover his own tracks. Get the timing wrong and it all goes pearshaped pretty quick.

      1. Pugwash69

        Re: BBC Micro's FRAK! did a better job of encryption back in 1984.

        I had a ripped off copy of that game with the bitmap of Frak! replaced by another similar phrase.

      2. arobertson1

        Re: BBC Micro's FRAK! did a better job of encryption back in 1984.

        Clever, but not immune from tape to tape. Didn't Unlock2 also crack this? Obfuscation is one thing, but true encryption without any dodgy TPM's is the only way that might stop hackers. I wonder if phone encryption works the same way? Hmmm... Memory dump + virtual phone + modified virtual firmware...

        1. d3vy Silver badge

          Re: BBC Micro's FRAK! did a better job of encryption back in 1984.

          "Clever, but not immune from tape to tape"

          Ah but the sea loader did have protection for that built in... Based on the crappy hardware available in consumer grade tape to tape machines... It was something to do with playing a really high pitched tone which the crappy tape decks would try to level out on the transfer resulting in the following low tones being essentially missed...

          The guy that wrote the loader has a big blog about it, ages since I read it but it's very interesting.

          1. d3vy Silver badge

            Re: BBC Micro's FRAK! did a better job of encryption back in 1984.

            ** edit doesn't work on mobile.

            Ocean loader - I was close :)

    5. Anonymous Coward
      Anonymous Coward

      Not sure why you (or the twitter guy) is blaming Microsoft. They're just using a standards based API

      It's shared blame here.

      (1) you do not default to relying on an uncontrolled variable for encryption (whatever disk is mounted) because that's abdicating responsibility. Oh, wait, that's a Microsoft default anyway so that actually fits.

      (2) disk manufacturers should be implementing standards properly or face taking their stock back as it's not conform proclaimed standards. To me, that is a defective product.

      Of course, we now face a question: did Microsoft maybe know this, hence the default? Let's hand the agencies a hand at bypassing due process and all that. I'll leave that to the conspiracy theorists to work out..

      1. Justthefacts

        Yes and no.

        Starting with: is it sensible for the OS to defer responsibility to the hardware.

        Yes. That is exactly the correct thing to do. it is so hard to get this stuff right, unless you have *tens* of years experience, it is dereliction of duty to roll your own. You push the security boundary into a separate certified object. And if you don’t trust the hardware, you can’t trust the RAM either. For example, Where Exactly will the OS store the decryption key? Ultimately, via some key hierarchy, that would be on the disk, in the clear, unless you have a separate hardware key store. ARM Trustzone do. Thats great, as I said, push it into hardware! Somehow.

        Secondly. SSD manufacturers did this accidentally, not deliberately. Because *this isn’t the security hole* as far as a TLA is concerned.

        There’s a much simpler way, once you have physical access and can update the firmware and play with the hardware. Simply, the data on SSD is encrypted with AES CBC mode, which is *symmetric and a simple XOR with scrambling code*. Just: hoik off the raw SSD chips read the encrypted data, swap out the SSD chips and put in ones filled with 0’s. Read again through the hardware decryption unit, XOR the two streams together. Job Done.

        1. Charles 9 Silver badge

          Re: Yes and no.

          "That is exactly the correct thing to do. it is so hard to get this stuff right, unless you have *tens* of years experience, it is dereliction of duty to roll your own."

          Isn't it ALSO a dereliction of duty to pass the job off to someone to whom you can't really trust? And that apples to just about everyone around you since everyone has something to hide?

          So what do you do? You can't trust yourself, and yet you can't trust anyone else.

        2. It's just me
          FAIL

          Re: Yes and no.

          If you can get it to decrypt then there is no need to mess around with swapping memory chips, just read the data and let it decrypt it as usual. But if it's properly encrypted using a user supplied key then, without the key, physical access doesn't help you at all. The fail here is they didn't use the user supplied key to derive the data encryption key. It's such an obvious security bypass that it smells like a purposefully designed backdoor.

          1. Justthefacts

            Re: Yes and no.

            I agree with you, about the failure root cause. The point I was making is that this is the drive manufacturer at fault, not MS. Had MS decided not to trust drive encryption at all, that would likely have caused more holes, and more easily exploited, just because security is hard to do right.

            I don’t agree however that it is purposeful, because the alternatives are problematic too. You say “derived key” which is security correct. However, any updateable Data Encryption Key makes it not be easily updateable (requiring entire drive rewrite) as someone pointed out. Unfortunately this pushes one to the security undesirable static Data Encryption Key, whatever you do with the Key Encryption Key. Accepting that trade off pushes to a model where the drive as a whole is locked by the user key.

            Personally, I would have argued for something like: internal private randomised key, which the user Key encrypts, and then it is only that which is stored. Thereafter, it is only the encrypted key that is ever stored, with the DEK generated dynamically in from the user Key. To update the “key”, decrypt the DEK with old key and re-encrypt with the new key.

            The extra manufacturing line time to provision the initial device-specific randomised key is going to come under fire from cost perspective. So, you can see how this got bastardised in a meeting to: the user key is just the key to the box, job done. I have been in very similar meetings, and lost the same argument to “this box has to be secure enough against standard hackers (who in the minds of management are all script kiddies); nation-state security requires FIPS compliance and we aren’t doing that”

        3. Anonymous Coward
          Anonymous Coward

          Re: Yes and no.

          "Starting with: is it sensible for the OS to defer responsibility to the hardware."

          yes, _for ordinary tasks_.

          But security? No, never!

          Even less to 3rd party totally unverified and who knows what hardware. That's just not done, ever.

          That's a major security stupity by itself.

          "Secondly. SSD manufacturers did this accidentally, not deliberately. "

          Yea, sure. And flying pigs deliver those SSDs where empty master key passwords happen accidentally.

      2. Jack of Shadows Silver badge

        Last time I looked, Microsoft "helpfully" stores your Bitlocker password to your Microsoft account, if you have one, on their servers. That's the reason why I don't use Bitlocker and damned sure will not tie a Microsoft account to my laptop.

    6. ForthIsNotDead Silver badge
      Unhappy

      Deliberate

      There is only one plausible explanation to this. It's a deliberate design decision, probably implemented under pressure from various three-letter around the world in order to gain access to data when they need to.

      What else could it be?

    7. Anonymous Coward
      Anonymous Coward

      "Not sure why you (or the twitter guy) is blaming Microsoft. "

      because the encryption service frontend is provided to the user via the OS.

      it's a bit like buying a dodgy toaster from argos. if it fails - your first port of call is Argos, not the toaster manufacturer.

      similarly, seeing as Microsoft offer the 'you can encrypt your disk using this button...' service, then its down to microsoft to actually ensure the encryption is happening to the standards their customers would expect. palming off the responsibility to the hardware providers (whilst we understand is actually their fault) is neither helpful nor desirable.

      or put another way, either do it properly or dont do it at all. dont promise to do it but never deliver (for whatever reason). false security is just as bad, if not worse than no security.

      1. h4rm0ny

        it's a bit like buying a dodgy toaster from argos. if it fails - your first port of call is Argos, not the toaster manufacturer.

        If we absolutely must argue by analogy (which is usually just a way of moving away from the actual facts) then lets make your analogy better. In this case, Argos sold you a kitchen. You brought your own toaster and plugged it in yourself.

    8. TomG

      I see you made the mistake of saying something that could be construed as being favorable to Microsoft. You should know that will get you a lot of downvotes.

    9. The Man Who Fell To Earth Silver badge
      Black Helicopters

      Spook Agencies

      All those conspiracy theories that Truecrypt suddenly disappeared with a recommendation to use Bitlocker due to a threat from Spook Agencies does not sound so crazy anymore.

  2. Anonymous Coward
    Anonymous Coward

    The issue is changing the password...

    If the DEK is derived from the user password, changing the user password requires to decrypt and re-encrypt the whole disk with the new key. Thereby I'm not surprised the DEK is separated. What should be derived from the user password is the key protecting the DEK - so changing it would require only a small decrypt/re-encrypt. Even better if that is stored in a tamper resistant module outside the disk. What is bad here is that it's so easy to force a driver firmware to accept a different password, and access the DEK.

    1. Paul Crawford Silver badge

      Re: The issue is changing the password...

      That is the usual argument for most data-at-rest encryption where you have a fixed random encryption value and your password simply protects that so a change of key is simple and fast as you don't have to decrypt and re-encrypt all of the data using the past and new keys.

      But who would have assumed the same of a disk? I always assumed that your PC (e.g. BitLocker mentioned) would present some high entropy key to the disk and if you changed password that key would be unchanged, as would a software implementation of disk encryption. After all you don't really expect to have the SATA bus, etc, snooped upon during operations. If you do its kind of game over anyway...

    2. cornetman

      Re: The issue is changing the password...

      > What should be derived from the user password is the key protecting the DEK - so changing it would require only a small decrypt/re-encrypt.

      Indeed. My understanding is that is how LUKS works.

      1. asdf Silver badge

        Re: The issue is changing the password...

        >Indeed. My understanding is that is how LUKS works.

        How about bioctl and CRYPTO? Asking for a friend :)

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019