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, …

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

          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 Silver 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??
          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
          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

      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

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

            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 Silver badge

            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

        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

          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

            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 Silver badge

        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

          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 Silver badge

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

        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
      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 Silver badge

      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

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

    3. OhThatGuy

      Re: The issue is changing the password...

      Having the drive manufacturer decide the encryption key means that the user isn't in control. The chosen solution just adds extra steps for no good reason, and now we see the resulting facepalm. KISS is more important in security designs than in most other areas, IMO. The issue with changing the key is no big deal, the process will just take some time.Small price for getting a key you can actually change...

      1. eldakka

        Re: The issue is changing the password...

        Having the drive manufacturer decide the encryption key means that the user isn't in control.

        There is a method/command to trash the existing DEK and generate a new random DEK. A crryptographic disk erasure (or crypto erase) command. This will destroy any existing data on the drive (since you are trashing the key used to encrypt any existing data). But can be done on a brand new drive before putting any data on it, or when you want to re-partition/format the drive anyway.

        Therefore the manufacturer won't know the key in this case, although in theory they shouldn't know the DEK on the drive you purchase because before leaving the factory it should be be put into some sort of 'shipping' mode that will generate a new random key when it is next powered on. And, in theory at least (exploits are being found all the time) a generated DEK cannot be extracted from the drive once it is generated.

      2. Anonymous Coward
        Anonymous Coward

        "the process will just take some time"

        Decrypting and re-encrypting terabytes of data is often not an option.

      3. John Smith 19 Gold badge
        FAIL

        The illusion of security.

        Without actual security.

        Something people who buy disks should keep in mind.

    4. gnasher729 Silver badge

      Re: The issue is changing the password...

      Interesting how you describe quite accurately how encryption on an iPhone works.

      1. Anonymous Coward
        Anonymous Coward

        Re: The issue is changing the password...

        Interesting how you describe quite accurately how encryption on an iPhone works.

        AFAIK also done in FileVault..

    5. bombastic bob Silver badge
      Unhappy

      Re: The issue is changing the password...

      let's say the encryption key is derived from a math operation on a hash of the password/passphrase and the stored key on the disk. If you change the password, you'd need to re-calculate the stored key. If it's possible to do this from the actual key, that might at least address THIS problem. But a truly secure system might derive the actual key with a 1-way operation (like matrix multiply or similar).

      in any case these things _COULD_ be solved in ways that make the system secure, and "not what THEY did".

    6. Anonymous Coward
      Anonymous Coward

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

      Here's the attack introduced by your proposal:

      1) Bad Guy gets access to the drive for long enough to get the encrypted DEK

      2) Later, Bad Guy figures out passphrase

      3) User goes "oh no, Bad Guy has my passphrase, I better change it" and changes passphrase, and changes e.g. all their Internet passwords and other secrets that were stored on that disk.

      4) Bad Guy gets access to the drive again... this time they can use the OLD passphrase and the OLD encrypted DEK to get the STILL-CURRENT DEK and access the drive.

      5) Now Bad Guy has all the NEW secret data that User created after changing their passphrase

      For extra fun, you can swap over steps 2 and 3 - i.e. the Bad Guy might only figure out the passphrase after the user has changed it.

      Some people might consider this OK, but it's very counter-intuitive that changing the passphrase doesn't actually get you any security against people who know your old passphrase. And many people won't understand it. It's much simpler (which is more secure) to have changing the password re-encrypt the whole disk.

      1. Anonymous Coward
        Anonymous Coward

        "User goes "oh no, Bad Guy has my passphrase"

        The whole system is evidently compromised. You need a new, better system, not a new passphrase. Evidently once you got the decryption key is utterly useless to re-encrypt it with a different password, you don't even need the old password, you can just read data and decrypt them.

        Anyway, in your scenario even if you change the DEK the bad guy will be able to get it again, as it has done previously. But in the paper it looks they didn't get the DEK (which could be protected inside the disk) - they just cheated the firmware to access it whatever password they used.

      2. Anonymous Coward
        Anonymous Coward

        Re: The issue is changing the password...

        You, literally, have no idea what you are talking about vis-a-vis this attack. At no time is there anything to do with the user's passphrase. None. This is all about convincing the firmware in the disk itself that you are an authorized user to see the decrypted content of the data on the drive.

        If there were everything including the stars aligning to establish the user's passphrase, that'd be a different matter. I've the tools (Tesla GPGU) and various Rainbow tables, which I do have, that isn't an attack that will give you much return in terms of cryptological return.

        We've short-circuited the entire security stack. THAT is the problem.

        1. Paul Crawford Silver badge

          Re: The issue is changing the password...

          This is all about convincing the firmware in the disk itself that you are an authorized user to see the decrypted content of the data on the drive.

          Basically this. In fact it is another example of a system storing the "password" in plain text. Really the SSD sector encryption key should never be stored in non-volatile memory, hence it should not be possible to simply bypass it by a firmware change. It should be generated on demand from the stored part and the user-supplied pass phrase.

          If you need to change your pass-phrase then you decrypt using the old one, check its OK (e.g. CRC as part of the stored 'key') and then re-encrypt using the new pass phrase.

      3. Justthefacts Silver badge

        Re: The issue is changing the password...

        Yes. That’s a risk at high security level.

        If you don’t like it, consider a FIPS compliant solution. Not consumer or even enterprise grade, more TLA.

        BitLocker is primarily for “I lost my laptop on the train”

    7. Anonymous Coward
      Anonymous Coward

      Re: 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."

      To me that's the whole idea of the password. Bypass the encryption key or store it somewhere and byebye security.

  3. Destroy All Monsters Silver badge
    Holmes

    All together now....

    "PROTECTING YOUR DATA IS OUR FOREMOST CONCERN"

    Microsoft trusting these devices to implement Bitlocker has to be the single dumbest thing that company has ever done.

    I don't think so, compared to all the security pratfalls over the ages apparently implemented by TOP.SKILLED COMPUTER SCEINTIST this doesn't sound so bad.

  4. Oh Homer
    Headmaster

    "should not rely solely on hardware encryption"

    Always true, not just for SSDs.

    No source, no security.

    1. bombastic bob Silver badge
      Devil

      Re: "should not rely solely on hardware encryption"

      POSIX systems have a cert mechanism for ssh that might work for mounting an encrypted file system using a FUSE file system, as one example...

      if it does not already exist, it should.

      /me could create one if I wanted to... but do I _NEED_ to?

    2. big_D Silver badge

      Re: "should not rely solely on hardware encryption"

      And, because it wasn't mentioned in the article, if you use BitLocker, here are the Group Policies for determining whether it should use Hardware Encryption or not:

      https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings

      Configure use of hardware-based encryption for fixed data drives

      Configure use of hardware-based encryption for operating system drives

      Configure use of hardware-based encryption for removable data drives

      1. sabroni Silver badge

        Re: the Group Policies for determining whether it should use Hardware Encryption or not

        So this isn't "MS didn't write it properly" it's "MS fucked the defaults up"? (By assuming that you bought disks with hardware encryption deliberately?)

        1. Wincerind

          Re: the Group Policies for determining whether it should use Hardware Encryption or not

          It's not even that. All MS did was expect hardware vendors to implement the standard properly. Either that or the standard itself is fucked. Hardly Microsoft's fault at all..

          1. Spazturtle Silver badge

            Re: the Group Policies for determining whether it should use Hardware Encryption or not

            No Microsoft should have made it so that by default it would only use the hardware encryption on devices if Microsoft had verified and certified that device.

            1. Charles 9

              Re: the Group Policies for determining whether it should use Hardware Encryption or not

              Even if that were true, it could've been fine at first then borked (without Microsoft's knowledge) later. Or, in this case, something slipped through which standardization wasn't set up to catch.

  5. Dazed and Confused

    Perhaps its just as well

    That I couldn't get the poking HW encryption working on my Samsung 850 EVO then.

    The steps Samsung suggest you need to go through, like pulling out certain cables while standing on one leg in a vat of cold porridge were clearly written by someone who'd never seen an M.2 device.

    So I've ended up with bitlocker using SW encryption. I suspect there are ways around that too, but the customer who's paying the bill insists on bitlocker on the PC.

    There has to be a way for the system to access the disk before getting the password since normally with bitlocker W10 boots first and asks for the password later.

    1. h4rm0ny

      Re: Perhaps its just as well

      So I've ended up with bitlocker using SW encryption. I suspect there are ways around that too, but the customer who's paying the bill insists on bitlocker on the PC.

      Well if you know any you should contact Microsoft for a hefty bounty. Bitlocker is very good. The only way "around it" that I know of is if you store a copy of your keys with Microsoft for disaster recovery, which is optional. Basically, if you want to guard against thieves and competitors, it's fine. If you want to guard against the FBI or CIA, keep the keys local (or don't keep a backup at all!).

      1. Anonymous Coward
        Anonymous Coward

        Re: Perhaps its just as well

        "The only way "around it" that I know of is if you store a copy of your keys with Microsoft for disaster recovery, which is optional. "

        Microsoft _claims_ is optional. In real life BitLocker keys are stored automatically to your Microsoft account if you have one. And there's no way to stop that.

    2. Spazturtle Silver badge

      Re: Perhaps its just as well

      "There has to be a way for the system to access the disk before getting the password since normally with bitlocker W10 boots first and asks for the password later."

      There first part of the boot process is stored unencrypted, once it reaches a certain stage it asks for the password to decrypt the rest of the drive.

      The unencrypted part is protected by UEFI Secure Boot to prevent tampering.

      1. Danny 14

        Re: Perhaps its just as well

        not keeping a backup of keys for you bitlocker drive is very silly. Most enterprise probably backup the keys in AD though.

  6. RobinCM

    Drive firmware updates?

    I wonder if there'll be any firmware updates released, and if these will be able to fix the issue without effectively junking all the data on the drive.

    I also wonder what the performance hit is of software vs on-disk-hardware encryption. Newer CPUs have AES instructions built in so unless your processor is already running at 100% it presumably won't be too bad?

    BitLocker documentation is here: https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings#bkmk-hdeosd

    I imagine you'd have to decrypt then re-encrypt the drive after changing this setting, which would be somewhat time consuming.

    It'll be interesting to see if/what guidance Microsoft produce on this topic.

    1. Giovani Tapini

      Re: Drive firmware updates?

      An update may be OK on a desktop or laptop, but I can't imagine doing this on a large disk array or storage device. Given the problem is at drive level not at the OS layer I would expect the solution to be a bigger issue than the problem.

      1. Bitsminer Silver badge
        Boffin

        Re: Drive firmware updates?

        Can happen. Dell, as an example of this, publishes update packages that go through every drive in a raid controller updating the firmware. Offline of course. IIRC the firmware is signed.

  7. Sureo

    This explains it

    I always wondered how the hackers on those police dramas are always able to access the bad guy's computer.

    1. Anonymous Coward
      Anonymous Coward

      Re: This explains it

      They type faster than you and don't use the mouse.

      1. eldakka

        Re: This explains it

        They type faster than you and don't use the mouse.

        Ahh, so that's why sometimes they have 2 people bashing at the same keyboard, to increase the typing speed.

        1. h4rm0ny

          Re: This explains it

          Ahh, so that's why sometimes they have 2 people bashing at the same keyboard, to increase the typing speed.

          Always a favourite: https://www.youtube.com/watch?v=u8qgehH3kEQ

          1. DropBear

            Re: This explains it

            What, those amateurs...? Meh... behold proper pwnage: https://www.youtube.com/watch?v=p_6hxB1OK00

            1. TRT Silver badge

              Re: This explains it

              I was looking for a clip of Robocop's data spike.

              1. DropBear
                Trollface

                Re: This explains it

                As cool as that was, it can end in tears - remember how R2D2 and C3PO had to wander around looking for a compatible socket (that isn't just a power socket) after being booted out from the control room? Fingers might be slower, but all you need is a keyboard / terminal...

                1. TRT Silver badge

                  Re: This explains it

                  I've recently come to wonder if R2D2 got The Death Star pregnant.

    2. oldtaku Silver badge
      Trollface

      Re: This explains it

      They also have the software that puts up 'HACKING PASSWORD' in 196 point red letters.

      1. FozzyBear

        Re: This explains it

        @ oldtaku

        Don't forget the all important "Bypass password" when all else fails

      2. Anonymous Coward
        Anonymous Coward

        Re: This explains it

        Yeah, but it turns out the “HACKING PASSWORD” is just as fake as the underlying SSD encryption...

        Who knew these cop shows would turn out to be so realistic?

        1. Anonymous Coward
          Anonymous Coward

          Re: This explains it

          "Who knew these cop shows would turn out to be so realistic?"

          On the other hand, Person of Interest - an excellent show - very much underplayed how easy it is with the right skills and tools to compromise a smartphone, making the show's limitations far greater than real life.

          Maybe the didn't want to scare people, or maybe they thought people wouldn't be able to (or want to) accept such an obviously 'fictional' ability.

      3. Adam 1

        Re: This explains it

        > They also have the software that puts up 'HACKING PASSWORD' in 196 point red letters.

        There is some pretty amazing software available on the internet these days. A lot easier than in days of old.

  8. oldtaku Silver badge
    Facepalm

    I'm just going to quote the paper - nuff sed

    'The drive's contents is still accessible to anyone in possession of the default Master password... which is an empty string.'

  9. Anonymous Coward
    Anonymous Coward

    Full Disk Encryption Not Good For SSD

    Using full disk encryption on SSD can severely shorten the life expectancy of the SSD. This is because the full disk encryption causes the NANDs on the drive to change state every time they start up the drive. Where I work, they use full disk encryption on SSDs and they have to replace the SSD every 4 years or less. So, if you use full disk encryption on SSDs have a good back regime as you never know when it is going stop working.

    1. bombastic bob Silver badge
      Meh

      Re: Full Disk Encryption Not Good For SSD

      an SSD-friendly encrypted file system would encrypt file names, path names, etc. from the index, but would not encrypt the block allocation, pointers, indexes, etc. so as to minimize the impact of encryption on re-writes. That way the data would still be encrypted, along with the names, but would not have to re-encrypt large parts of the file system because you changed something.

      it would still be possible to determine "this is a large file" and try to decrypt it the hard way, but with a strong enough key... good luck. maybe you could look for file headers as a 'crib' of some kind, but a properly designed algorithm would prevent THAT from working, too.

    2. Updraft102

      Re: Full Disk Encryption Not Good For SSD

      Samsung SSDs use the full disk encryption function at all times, even if you've never set the password. It just doesn't require the user to present a passphrase/password first. That's presumably where the null password thing someone else mentioned comes from.

    3. Anonymous Coward Silver badge
      Megaphone

      Re: Full Disk Encryption Not Good For SSD

      Ignore everything else. Just "have a good backup regime as you never know when it is going to stop working". That applies to any data storage medium, whether you use encryption or not.

    4. Richard 12 Silver badge

      Re: Full Disk Encryption Not Good For SSD

      Just encrypt page-by-page. Doesn't matter what any of the data means.

      You have to erase and write by whole pages anyway, so decrypt-append-encrypt-write-erase doesn't add much (any?) flash wear.

      Keep the state around so you can keep streaming more data into a page until it's full or power is lost, and there's no extra wear at all.

    5. Anonymous Coward
      Anonymous Coward

      Re: Full Disk Encryption Not Good For SSD

      So, if you use full disk encryption on SSDs have a good back regime as you never know when it is going stop working.

      So, however you store your data have a good back regime as you never know when it is going stop working (sic).

      There, FTFY,

      1. Charles 9

        Re: Full Disk Encryption Not Good For SSD

        But then you're gonna need a good backup scheme FOR your backup scheme since you never know when Murphy will strike and take out your backup just when you need it. And then you'll need a backup for that, too, and so on. Turtles All The Way Down.

        At some point, you're gonna just have to shrug and say, "That's as far as I can go."

  10. Carl D

    Fed up with these nonstop security issues

    "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, …"

    And, therein lies the problem.... the "miscreants" would probably never know anything about this let alone exploit it if these issues were never made public to begin with.

    And, I'm still waiting for Meltdown and Spectre exploits to appear nearly a year following the big panic epidemic after they were announced. Maybe by the end of the decade? Probably not.

    Nowadays, every time I see another (alleged) major security issue splashed all over the Internet I just chuckle and carry on with life.

    1. Anonymous Coward
      Anonymous Coward

      Re: Fed up with these nonstop security issues

      Meltdown proof of concepts came out more or less instantaneously after this august website blew they story wide open earlier this year. And a lot of emergency patching happened very soon thereafter, to negate the value to anyone writing actual exploits.

      Spectre is a lot harder to exploit, apparently. Though, conceptually speaking, Spectre is the one that will upset your quiet enjoyment of life because it might be doable in Javascript in a browser...

      1. DryBones

        Re: Fed up with these nonstop security issues

        What, you mean blocking Javascript might actually do things besides reveal just how many sites don't have control over their own layouts?

    2. Chronos

      Re: Fed up with these nonstop security issues

      And, therein lies the problem.... the "miscreants" would probably never know anything about this let alone exploit it if these issues were never made public to begin with.

      Security by obscurity, compounded by the fact that the underlying issue is pretty much the same thing. Please hand in your geek card at reception.

    3. naive

      Re: Fed up with these nonstop security issues

      > And, therein lies the problem.... the "miscreants" would probably never know anything about this let

      > alone exploit it if these issues were never made public to begin with.

      That is on the level of European gun laws, where the bad guys have guns, and the good ones have to jump through a dozen of hoops to get one.

      People trust their lives with encryption, companies trust sometimes billions of development costs to be protected by encryption. And once again, the world is left in the rain by one of the biggest IT companies in the world, probably even on purpose, since MS always liked to cosy up with law enforcement so they could easily peek into Windows computers.

      It is the Ford Pinto gas tank scandal all over again, but then in IT. Contrary to cars, users have little choice, or even do not want to choose since IT converged to a weird thing where de-facto monopolies are kept alive by near religious fan-boys.

    4. Anonymous Coward
      Black Helicopters

      Re: Fed up with these nonstop security issues

      > "And, therein lies the problem.... the "miscreants" would probably never know anything about this let alone exploit it if these issues were never made public to begin with."

      Snowden told me that the US Govm't were doing it. There was one bunch of miscreants using unpublicised zero-days.

    5. Anonymous Coward
      Anonymous Coward

      Re: Fed up with these nonstop security issues

      "And, therein lies the problem.... the "miscreants" would probably never know anything about this let alone exploit it if these issues were never made public to begin with."

      False logic as those are obvious back doors by three/four letter state organisations. And yes, _they know_.

      Why shouldn't ordinary people, i.e. the targets, know?

    6. gnwiii

      Re: Fed up with these nonstop security issues

      "Nowadays, every time I see another (alleged) major security issue splashed all over the Internet I just chuckle and carry on with life."

      This is dangerous thinking. Some of these nonstop security issues can be used to disrupt essential services such as utilities (power, water, internet), large facilities (airports, refineries, food distribution warehouses). Some security issues have been in the toolkits of nation-state and criminal enterprises long before they became public. With increased attention to the social media activities of nation-state and criminal enterprises, the use of stolen accounts for such activities is increasing. The US Government is so busy denying that nation-state hacking contributed to the current post-turtle president's election victory and distractions such as the "border emergency" that it has neglected cyber security for essential services. A key element in the US elections was use of social media to enhance existing divisions. Europe too is dealing with divisions between left, center, and right wing elements, separatists (Spain), racism, etc.

      It is quite possible that the only reason we haven't seen more large scale attacks is competition among nation-states and criminal enterprises for control of key assets.

      Security is hard, and requires ongoing diligence. Too many businesses have been given a free pass due to lack of penalties for peddling shoddy implementations. Cell phone batteries that catch fire are recognized as a danger to the public. Mistakes in widely used encryption tools have the potential to be used for crippling attacks. This is a clear and present danger and nothing to chuckle at.

  11. Anonymous Coward
    Big Brother

    Fundamental flaws in SSDs encryption.

    I would suspect this is more than an unintentional flaw, more likely Samsung implemented a secure encryption system and then handed it over to the spooks for review, who helpfully made some alterations, like not actually using the password to generate the key.

  12. ThatOne Silver badge
    WTF?

    Small problem though

    Something drew my attention: The article mentioned the possibility to reprogram the firmware to ignore the password. That's the big(gest) problem IMHO.

    If you can change the firmware to tell the drive not to ask for a password but just go on and decrypt everything as requested it really doesn't matter if the password used is user-set or just "1234".

    On the other hand, if the drive doesn't actually know the password unless you give it to it, it shouldn't matter if it is directly user-set or a longer password protected by the user password. Firmware, no matter what you program it to, wouldn't be able to access the data on its own.

    Did I miss something?

    1. Anonymous Coward Silver badge
      Boffin

      Re: Small problem though

      The biggest issue here is that they can reprogram the firmware to decrypt the data without ever knowing the key.

      If it was implemented securely, they'd have to reprogram the firmware before the data was encrypted, or reprogram it and put it back in place to capture the user entering the password, before they'd be able to decrypt anything.

      1. Richard 12 Silver badge

        Re: Small problem though

        The problem is that the password isn't used by the encryption scheme in any way.

        The encryption engine is simply told "yes, decrypt", or "no, don't"

        So if you edit the the firmware to always say "yes, yes, YES!", it still decrypts correctly... and is thus useless to a local attacker.

  13. Robert Heffernan
    Mushroom

    Government Back Door

    Drats! The back door for FBI/CIA/NSA/MI5/ETC has been found! Oh noes!

  14. Nicko
    Flame

    Missing something here?

    Crucial no longer make the MX100, MX200 or MX300 series stuff.

    Yes, there a lot of these in the field, but folk learn. It'd be good to see the MX500 tested...

  15. Anonymous South African Coward Bronze badge

    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

    theskyisfallingtheskyisfallingtheskyisfallingtheskyisfallingtheskyisfalling

    wegottadosomethingquickquickquick

    <font=500size>MEH</font>

  16. Anonymous Coward
    Anonymous Coward

    Not quite as bad as made out

    As a Samsung Evo 850 user, I’m relieved to see that unless using ATA on high mode, my drive actually stands up pretty well here. In particular, when using Bitlocker to manage the hardware encryption, TCG Opal mode is used which they failed to compromise. For the 840, there may be issues with enabling encryption without resetting the DEK, but since the only way I’ve managed to reliably enable Bitlocker using hardware encryption is to start with a drive that has just been reset (including DEK), that seems less of an issue too. The main message for 840/850 users therefore seems to be ‘don’t use ATA high mode’.

    My reason for using hardware encryption was based on the idea that with software encryption, sequential reads/writes can no longer be done using DMA but become CPU-constrained, but that may be based on my inadequate understanding.

  17. John Smith 19 Gold badge
    Unhappy

    So yet another case of "Security by obscurity"

    PHB "Test port. Who knows what a test port is? Let alone where to find one. It'll be fine."

    PHB "It'll save a ton of money and months on time to market. No one will notice."

    Until some one does.

    And if your marketing this to people with serious security issues you should assume that they have serious enemies who will go to nearly any lengths to get their data.

  18. rmason

    I'm going to have to read the paper.

    Need some clarity on a few things. We have these drives in the wild and windows 10, but all devices (laptops) have TPM, and it was my understanding win10+TPM (we pay a premium for 'enterprise' devices that include TPM), explicitly does NOT do this.

    It means you have whole ranges of machines you can't even consider, until you hit the most costly in whatever brand you're looking at.

    Waste of time and money eh? Brilliant.

    1. Anonymous Coward
      Anonymous Coward

      Hmmm

      rmason

      We have these drives in the wild and windows 10, but all devices (laptops) have TPM

      I vaguely recall TPM's are / were banned in Russia, and China insists you use one specified by the Government.

      Probably fine if you go there on a visit, but locally sourced devices would have to adhere to the countries policy.

    2. Anonymous Coward
      Anonymous Coward

      Re: I'm going to have to read the paper.

      My understanding is that TPM has been a requirement for most (all?) enterprise encryption solutions across Windows/OSX/Linux platforms, so that likely addresses most of the market already.

      I would suggest the combination of people using encryption-at-rest outside of an enterprise solution, on a device that isn't TPM-enabled, hitting one of the SSD protection schemes where the password doesn't affect the DEK and relying SDD encryption mechanisms is likely to be small...

  19. Huw D
    Trollface

    I'm hurting here...

    Never mind the security aspect.

    El Reg, how could you use the phrase "We've pinged Microsoft, Crucial, and Samsung for comment"? Seriously. Using ping that way is the language of marketers and buffoons.

    ;)

  20. chivo243 Silver badge
    Headmaster

    Curly Howard method

    Hey Curly, did you lock the door? Yes, twice, once this way, and once that way...

  21. Anonymous Coward
    Anonymous Coward

    ensure the secrets needed to decrypt a drive are stored off the equipment itself.

    a sensible, if not a breakthrough suggestion. Presumably though, google, MS, AWS and such cloud-based solutions are, wait for this... "burdened with an increased risk of access by a 3-party (make it a 3-letter party ;)

  22. Luiz Abdala
    Pirate

    I will never forget IBM using ZIP files with passwords on their Aptiva Images.

    If you wanted to reinstall just one thing - say, the modem - you had to FORMAT the machine and boot it from the CD with the aforementioned zipped, passworded image. Booting the CD caused the script to simply format the HDD, decompress the files back on it, and reboot. No way to choose which files you wanted.

    Or you could brute-force it and extract just the drivers.

    The password was 'magic'. No uppercase, no numbers, no extended characters.

    Even THAT was more efficient than bitlocker, forcing a brute-force attack, apparently. Even back then, a Pentium 100Mhz was capable of 2 million password attempts per second, but still... brute force.

  23. imanidiot Silver badge

    Dumb execution to be sure, but:

    Wasn't the usual assumption for security: "If the assailant has physical access you have already lost"?

    1. chivo243 Silver badge
      Facepalm

      Re: Dumb execution to be sure, but:

      @imanidot

      Wasn't the usual assumption for security: "If the assailant has physical access you have already lost"?

      That is where disk encryption was supposed to save the bacon... Seems not so much now?

    2. FrogsAndChips Silver badge

      Re: Dumb execution to be sure, but:

      True in a sense, but the assumption behind disk encryption is "Losing a drive is bad, but if it's encrypted then recovering the data without the key should be near impossible". My company downplays the severtity of laptop/phone losses when the device was off and Bitlocker enabled.

      The article shows that some implementations leave you vulnerable to 'easy' data recovery even if encryption is enabled.

    3. Mike Pellatt

      Re: Dumb execution to be sure, but:

      Not when it comes to encrypted data-at-rest, no.

    4. Anonymous Coward
      Anonymous Coward

      Re: Dumb execution to be sure, but:

      "Wasn't the usual assumption for security: "If the assailant has physical access you have already lost"?"

      Security in general (meaning access to machine) but it specifially does not apply to hard drive encryption as the most common use for it is to protect the data in a situation where assailant has the drive in hand.

      If it doesn't do anything at that point, it's worse than useless: It's _false security_.

  24. Flak

    Bypass

    Reminded me of this classic image:

    http://vicclap.hu/static/pic/verda/zavora.jpg

  25. Brent Beach
    Big Brother

    A bug or a mandated back door?

  26. Zippy´s Sausage Factory
    Unhappy

    "Being earnest now: Microsoft trusting these devices to implement Bitlocker has to be the single dumbest thing that company has ever done."

    That is, it has to be said, a pretty high benchmark. I mean, there was Bob, Clippy, jettisoning classic Skype, ruining their own Windows Phone product when it was just starting to become competitive... I mean I could go on, but I'm getting depressed now.

  27. Luiz Abdala

    802.11b

    Remember the WEP encryption for wifi networks?

    I call those "knee-high white-picket-fence strategy".

    Yes, you can break/bypass those in less than 30 seconds, but you can prove that the guy had to jump a locked fence, hence he was trespassing.

    Yes, you can change the password and decrypt the device, but you leave evidence of doing it. Honey pot strategies... so it's not completely useless, it proves someone tampered with the device.

    Or maybe not, what do I know.

    1. Anonymous Coward
      Anonymous Coward

      Re: 802.11b

      "Yes, you can change the password and decrypt the device, but you leave evidence of doing it."

      Irrelevant when you won't get the device back to show the evidence to anyone.

      There's no way to prove the hard drive ever was encrypted after the data is successfully decrypted from there and the actual drive destroyed.

      So false logic: No evidence left about anything.

  28. Anonymous Coward
    Anonymous Coward

    It's all down to the implementation

    You really need to read the paper to get the full story - all of the drives tested apart from the MX100 and 200 implemented password based key derivation which provided keys to decrypt the media encryping keys. They also implemented firmware signing. So in principle they were doing the right thing. But this wasn't the problem, it was issues like the MX300 not enabling signature verification of the bootloader in SPI NOR flash (that allowed an unsigned bootloader to be used, which then could load unsigned firmware from the NAND flash) the blew open the security.

    I suspect that the verification step was a development switch in the ROM that someone 'forgot' to enable in the production version. Or maybe they thought that nobody would desolder the SPI NOR and reprogram it so it wasn't necessary. All they need to protect supposedly were the downloadable firmware images, which were validated (by the SPI NOR bootloader - oh dear).

    The Samsung implementations seemed to be much better - although their attempts at obfuscation of the (signed) firmware in the update boot images didn't prevent the researchers getting round that and being able to reverse engineer things like the key verification scheme, RNG and being able to unlock vendor specific commands to read/write the crypto blob. A JTAG exploit was required to unlock the 840 EVO though (by modifying the password validation routine). The 850 retained JTAG so although they didn't specifically say, I guess it remains vulnerable to the same attack.

    While the specific implementation might not be something that normally goes into specs like TCG, the researchers point out (and I agree) that they should be publishing a reference implementation that could be security checked. At the moment TCG Opal is little more than ATA Security with AES knobs on. As written, there is no requirement to bind the authentication/unlocking with the media encryption keys for instance.

  29. Borg.King
    Joke

    Umbrella

    It’s like jumping out of a plane with an umbrella instead of a parachute.

    Mary Poppins is covered then. That's nice.

  30. Anonymous Coward
    FAIL

    Lovin' It!!!

    I've been doing security for over 20 years - and the longer I do it, the more shitty it gets. Let's take vPro machines and leave the backdoor wide open, and never use it.

    I love ITSec, but I also love its demise. Dumb fuck devs, shitty managers and security folk that have spent decades trying to protect you from yourself. Burn in hell, dipshits!!!! You hire 'em, and never fire 'em ... you get reap what you sow.

    Fuck you're all dumb!

  31. Anonymous Coward
    Anonymous Coward

    Open backdoor from MS on purpose, obviously.

    "exploited by miscreants to easily decrypt data, once they've got their hands on the equipment."

    "miscreants" meaning of course national spying organisations in China and US. Possibly elsewhere too.

    There's no way MS has done that by accident, but knowing SSDs have backdoors and leaving them open for abuse.

    "using standard API" is irrelevant when a) you know there's a backdoor and b) don't tell about it to user at any point and c) don't give any option to encrypt the hard drive anyway.

    For single developer assumptions like that are allowed but for MS it's not. So backdoor left open on purpose.

  32. Muppet Boss

    Designed backdoor?

    Could this be not bad design but rather specifically designed backdoor to show some love to various agencies' backdoor addiction? It does feel like this sort of hanky panky design.

  33. sjoram

    Samsung 850

    2 x Samsung Evo 850s here....

    According to MS article and manage-bde -status results on my two, I'm not using the hardware encryption...

    https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180028

    "Run ‘manage-bde.exe -status’ from elevated command prompt.

    If none of the drives listed report "Hardware Encryption" for the Encryption Method field, then this device is using software encryption and is not affected by vulnerabilities associated with self-encrypting drive encryption."

    Both appear to be using different variants of AES, but neither states 'Hardware Encryption'...

  34. Long John Silver
    Pirate

    Degrees of trust?

    Presumably hardware mediated encryption offers simplicity of setup and speedier on-the-fly processing than software equivalents. For most people and for most purposes that sits well despite concerns over security; at very least hardware implementations keep out casual intruders. Someone opting for hardware encryption retains capacity to implement additional software encryption for highly confidential material.

    Speed advantages of hardware based encryption may be not noticeable by most users. They choose operating system controlled encryption and/or independent software like VeraCrypt. If using an open-source operating system (or software add-on) they belong within a community containing people with high level security skills and thus will be alerted to problems.

    It all boils down to trust. Trust at two levels: that the provider of hardware/software does their best without malicious intent and errors are infrequent, or that trust in integrity itself cannot be guaranteed. Individual decisions weigh these factors in the light of tightness of security required; this in realisation that it (seemingly) can never be absolute; moreover, beyond the minimum, enhancing security comes at a cost (e.g. that of multiple layers of encryption consuming resources); diminishing returns set in.

  35. Jamie Kitson

    Not New?

    It looks like this isn't a new concern:

    https://vxlabs.com/2012/12/22/ssds-with-usable-built-in-hardware-based-full-disk-encryption/

  36. Anonymous Coward
    Anonymous Coward

    Lessons of the day:

    1. Any full partition on hardware that gets seized can be accessed and decrypted over time.

    2. Putting key-management inside hardware equates to asking a programmer/administrator to create something that can undo the encryption.

    1. Charles 9

      To reply:

      1. If the TLA's have access to vastly better hardware than you, or a secret waterboard, then if they REALLY want your data, then as they say, "We have ways of making you talk."

      2. Encryption MUST be decrypted at SOME point because our brains can't directly grok encrypted data (sometimes makes me beg for the sci-fi of stuff like Ghost in the Shell which DID provide for that capability). That's why "Outside the Envelope" attacks can always work. For performance reasons, you're going to need hardware, especially if the CPU is going to be busy doing something else.

  37. DrM
    FAIL

    Duh?

    "Basically, the cryptographic keys used to encrypt and decrypt the data are not derived from the owner's password, meaning, you can seize a drive and, via a debug port, reprogram it to accept any password. At that point, the SSD will use its stored keys to cipher and decipher its contents. Yes, it's that dumb."

    And who would be dumb enough to think it was otherwise? You can change the drive’s password in a few seconds – how many people thought it decrypted and re-encrypted the whole drive in a second?

    1. Charles 9

      Re: Duh?

      The way it normally works (and I know TrueCrypt and VeraCrypt do this) is that the drive is normally encrypted with a fixed key that is ITSELF cryptographically hashed from the password you enter and then stored. That way, if you want to change the password, you enter both old and new passwords. The old password decrypts the key which can then be re-encrypted using the new key. No need to re-encrypt the whole drive, yet you still need the new password to get even basic access to it.

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

Other stories you might like