Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Microsoft Data Storage Encryption Windows

Microsoft Stops Trusting SSD Makers (tomshardware.com) 56

Windows ships with a full volume encryption tool called BitLocker. The feature used to trust any SSD that claimed to offer its own hardware-based encryption, but that changed in the KB4516071 update to Windows 10 released on September 24, which now assumes that connected SSDs don't actually encrypt anything. From a report: "SwiftOnSecurity" called attention to this change on September 26. The pseudonymous Twitter user then reminded everyone of a November 2018 report that revealed security flaws, such as the use of master passwords set by manufacturers, of self-encrypting drives. That meant people who purchased SSDs that were supposed to help keep their data secure might as well have purchased a drive that didn't handle its own encryption instead. Those people were actually worse off than anticipated because Microsoft set up BitLocker to leave these self-encrypting drives to their own devices. This was supposed to help with performance -- the drives could use their own hardware to encrypt their contents rather than using the CPU -- without compromising the drive's security. Now it seems the company will no longer trust SSD manufacturers to keep their customers safe by themselves. Here's the exact update Microsoft said it made in KB4516071: "Changes the default setting for BitLocker when encrypting a self-encrypting hard drive. Now, the default is to use software encryption for newly encrypted drives. For existing drives, the type of encryption will not change." People can also choose not to have BitLocker encrypt these drives, too, but the default setting assumes they don't want to take SSD manufacturers at their word.
This discussion has been archived. No new comments can be posted.

Microsoft Stops Trusting SSD Makers

Comments Filter:
  • I imagine this won't have much effect on pre-built systems where the manufacturer will override this and use the SSD's native encryption. The people who will be affected by this are consumers building their own systems or adding additional drives.

    I'd have preferred a warning message and choice to enable or use software there and then. This decision is expected from Microsoft though - their whole thing at the moment is picking a default that is safe for the user and not even bothering to ask complicated ques

    • Makes sense. You can choose to trust the SSD's built-in encryption, but the default is not to trust.
    • by gl4ss ( 559668 ) on Monday September 30, 2019 @09:59AM (#59252546) Homepage Journal

      prebuilts aren't encrypted by default anyways so it makes very little difference for those.

      What bs move microsoft has done however is that bitlocker needs windows 10 pro to be available. "Device security" encryption enabled devices on the other hand are lower tier devices. basically what this means is that you can't have drive encryption on mid priced 1000-1500 gaming laptops which ship with windows home without upgrading to pro.

      Now, I just enabled bitlocker on a newish laptop I have last thursday, what I want to know is how I can check if it's using the ssd's encryption or not? also there's some hw assist on it probably anyways. what I did however see when enabling it was an option for an old or newer crypto, which I don't recall being there before. (they recommend the older one for removable drives).

      • by AmiMoJo ( 196126 ) on Monday September 30, 2019 @10:11AM (#59252596) Homepage Journal

        These days many pre-built systems are encrypted by default. For example Microsoft Surface and most Thinkpads have Bitlocker turned on by default now. My work HP laptop has it too. They don't ask for a password, it's stored in the TPM and used automatically by the OS.

        The purpose is to make wiping the machine securely a quick and easy operation. It only takes a fraction of a second to erase the key and all the data is gone. Can be done remotely as well, e.g. Lenovo actually offer a cellular modem option that supports remote wipe while the machine is "off".

        • by trawg ( 308495 )

          I got a new Dell laptop recently which was encrypted by default with "device encryption" (Windows 10 Home). I find it a bit confusing after doing some light research on the topic - it's not clear to me if the change mentioned in this article will impact me or not.

          I have been thinking about upgrading to Pro just to make sure I get "proper" Bitlocker so I can be more confident about the disk encryption - more so after reading this.

      • Now, I just enabled bitlocker on a newish laptop I have last thursday, what I want to know is how I can check if it's using the ssd's encryption or not?

        From a run-as-administrator Command Prompt run manage-bde -status C: (or whatever the volume letter is). If it's trusting the drive hardware to do the encryption the output should include something like "Encryption method: Hardware Encryption - 1.3.111.2.1619.0.1.2". The number is an OID for the encryption method: 1.3.111.2.1619.0.1.1 means XTS-AES-128 and 1.3.111.2.1619.0.1.2 means XTS-AES-256.

      • prebuilts aren't encrypted by default anyways so it makes very little difference for those.

        What bs move microsoft has done however is that bitlocker needs windows 10 pro to be available. "Device security" encryption enabled devices on the other hand are lower tier devices. basically what this means is that you can't have drive encryption on mid priced 1000-1500 gaming laptops which ship with windows home without upgrading to pro.

        Now, I just enabled bitlocker on a newish laptop I have last thursday, what I want to know is how I can check if it's using the ssd's encryption or not? also there's some hw assist on it probably anyways. what I did however see when enabling it was an option for an old or newer crypto, which I don't recall being there before. (they recommend the older one for removable drives).

        Well, Sorry to kind of hijack your comment here but how much do you TRUST Bitlocker in your case? Do you know that Microsoft does love to share information with agencies, right? So your decryption keys are stored online (if you chose) which they can be downloaded by Microsoft (or they might have a copy of the decryption keys). These can be handed to anyone when they get a warrant so whats the point of using it? I would still recommend you AxCrypt or Veracrypt encryption tools [securedyou.com] which are OPEN-SOURCE encryptio

    • I imagine this won't have much effect on pre-built systems where the manufacturer will override this and use the SSD's native encryption.

      But do many prebuilt systems come with BitLocker turned on in the first place, especially "home user" targeted systems?

  • by BAReFO0t ( 6240524 ) on Monday September 30, 2019 @09:14AM (#59252390)

    Like fake RAID in storage chipsets, they were a pure gimmick, that nobody with a clue actually used.

    What do I know what it actually does in there. No way am I gonna trust a random hardware manufacturer to get this right.

    • IIRC you could set a registry key to override that behavior but here was also a major flaw in Bitlocker a year or two ago that let your software-encrypted drive be decrypted as well, with a simple attack. That one is fixed but who knows what else lurks beneath.

      If it really matters, boot your hardware on linux LUKS and launch your Win10 full-screen with full virtualization support. Alternately run the latest ZFS with native crypto and give it an encrypted zvol to use. If there's a Chicom firing squad on t

      • I didn't think there was any audited open source crypto software. At any rate, if there's a Chicom firing squad, I'm pretty sure having an undecryptable blob is considered a guilty plea. I think the same is true in the UK.

        • by Anonymous Coward

          At any rate, if there's a Chicom firing squad, I'm pretty sure having an undecryptable blob is considered a guilty plea. I think the same is true in the UK.

          Yeah, I know it's the fashion to shit on the UK as being 'as bad as China' but we don't have firing squads, and the only person ever convicted of 'failure to decrypt' was stupid enough to *confess* that they were refusing to decrypt, as opposed to saying 'I don't remember the key' or 'I don't know the key' or just saying nothing.

          The 'I don't know/remembe

        • by Zumbs ( 1241138 )
          There is VeraCrypt [veracrypt.fr].
      • by Kaenneth ( 82978 )

        Belt-And-Suspenders.

        I use the a hardware encryption on cold boot, but also software encryption for the volume on that drive.

      • by Zumbs ( 1241138 )

        Storing the decryption key on the encrypted drive itself is inherently unsafe.

        In November 2018, a group from Radboud University published a draft article [www.ru.nl], where they described how the broke the hardware encryption on a number of SSDs from different manufacturers by reasonably simple means. The article is only about SSDs as the researchers only looked into SSDs, and there is no reason to expect better security on a magnetic disc.

    • by AmiMoJo ( 196126 ) on Monday September 30, 2019 @09:39AM (#59252472) Homepage Journal

      Long ago Sandforce (remember them?) introduced AES encryption into their chipsets, and then everyone else copied it. It was basically free, the SSD could already exceed the bandwidth of the SATA3 port (this was way before NVMe) and cost next to nothing in silicon.

      A standard, OPALv2, was created to allow the user to set their own private key. The key is not supposed to be stored anywhere by the SSD, the computer has to supply it every time the SSD is power cycled. It's a little more tricky as a small part of the SSD has to remain unencrypted so that the computer can boot enough of the OS to retrieve the key, but basically it's a good idea.

      The problem is that some of the SSD firmware out there is unreliable. The most common flaw is not actually using the supplied private key as any more than a simple passcode, and encrypting the drive with a secret key that is recoverable from the flash memory.

      If you can trust the firmware it's still worth using, because you get full SSD speed with no load on the CPU. In fact it's probably worth using even if you can't trust the SSD, because to exploit these weaknesses is way beyond thieves and most law enforcement.

      I'm not convinced the alternative is that much better either, as it relies on Intel/AMD having implement AES-NI properly and causes the encryption key to be kept in RAM all the time the computer is turned on. With self-encrypting drives the key can be wiped as soon as it has been sent to the SSD, protecting it from malware. Key storage is usually via TPM which protects it even from rootkits.

      • Is it truly just a CPU load issue? My experience has been roughly 90% drop in 4 KB IOPS using software encryption, even with Intel AES-NI equipped CPUs.
        • by AmiMoJo ( 196126 )

          I believe that the massive IOPS hit is because the CPU has to schedule time to decrypt all those small chunks, and it's not that efficient. Latency goes up from just the SSD+bus to include scheduling time for the CPU to run over the whole lot.

    • Comment removed based on user account deletion
    • by Agripa ( 139780 )

      Like fake RAID in storage chipsets, they were a pure gimmick, that nobody with a clue actually used.

      What do I know what it actually does in there. No way am I gonna trust a random hardware manufacturer to get this right.

      Fake RAID would have its place if it was implemented correctly. It allows booting from a redundant boot disk by operating systems which do not support booting from software RAID.

      The problem of course is that like many hardware RAID systems, they are implemented very poorly resulting in poor reliability. They do not support effective scrubbing and are way too sensitive to kicking disks out. Some of these problems are amplified by companies like Western Digital who deliberately makes their consumer level d

  • check this (Score:5, Funny)

    by FudRucker ( 866063 ) on Monday September 30, 2019 @09:15AM (#59252394)
    i bought one of those external harddrive enclosures so you can put any harddrive in it you want "IO Magic" and if i put in a drive that already has partitions & data in it i can read it just fine, but if i format a drive in the external enclosure then remove it and put it in a computer, then the computer wont be able to see any partitions as if the partition table itself is corrupted, and if i take it back out and put it back in the external enclosure it works fine again, i am guessing that is the encryption preventing anything else from read/write on that harddrive? thats the only thing i can think of

    it might protect your data from theft, but it sure is annoying & inconvenient for a user that juggles drives & data often
    • by twms2h ( 473383 )

      It could simply be a bug in the controller.
      We have had simple (no encryption) USB-SATA enclosures where the same drive worked fine as long as you used it either with inside the enclosure or directly connected to the PC, but if you tried to move it from one to the other Windows could no longer detect the partitions.

      • It could simply be a bug in the controller.

        I used to believe in all that bu11sh!t about "never assume a conspiracy when mere incompetence could have caused the same result," but since I woke up and started to be aware of some of the more horrifying aspects of human psychology, I'd say that psychopathy & a desire for vendor-lock-in [with the resulting increase in profits] is at least as likely as would be a mere "bug".

        BOTTOM LINE: You're on your own. You simply cannot trust anyone anymore. And if you
    • This could be an addressing error in the enclosure, have you examined the drive in a hex editor, or a tool like Testdisk to see if things like partition label or filesystem are readable?
    • by AmiMoJo ( 196126 )

      Those things are, unfortunately, crap.

      The encryption is usually broken. Some used a fixed key and simple XOR system, for example. Some claim to do AES but have broken implementations. They usually need special software to work too, they are not generally Bitlocker compatible.

      The issue here is with SSDs that implement eDrive, which is a Microsoft variant of OPALv2. Basically most SSD controllers already have encryption built in. eDrive/OPALv2 just lets you set your own encryption key. Unfortunately some manu

      • I think it is wise. With so many incidents of hardware "encryption" being duds, why trust it? I use hardware encryption on some USB flash drives, but mainly because they give ten guesses, and then erase the data. For security, that is what BitLocker, LUKS, or VeraCrypt are for, so even if the hardware encryption is just smoke and mirrors, the data is still protected.

    • Some external enclosures (especially the ones sold by WD and Seagate) have a translation layer on them to convert between 512 byte and 4k sectors on the fly [klennet.com]. This was added about a decade ago when we were transitioning to 4k sectors and drives larger than 2 TB. Without it, some people would put an external drive larger than 2 TB in an enclosure, only to find that they could only see 2 TB of it. These enclosures have a translation layer which auto-converts between 512 byte and 4k sectors, allowing you to
    • by Agripa ( 139780 )

      i bought one of those external harddrive enclosures so you can put any harddrive in it you want "IO Magic" and if i put in a drive that already has partitions & data in it i can read it just fine, but if i format a drive in the external enclosure then remove it and put it in a computer, then the computer wont be able to see any partitions as if the partition table itself is corrupted, and if i take it back out and put it back in the external enclosure it works fine again, i am guessing that is the encryption preventing anything else from read/write on that harddrive? thats the only thing i can think of

      That is a common problem with RAID controllers as well going back more than 20 years. Some allow mirroring of an existing disk but others do some form of sector translation so a pair of mirrored disks cannot be used separately. It does not surprise me at all that an external hard drive enclosure could suffer from the same problem. Maybe during formatting the enclosure uses an offset to align the partition's clusters with the native sectors.

  • by Lumpy ( 12016 ) on Monday September 30, 2019 @09:23AM (#59252430) Homepage

    Honestly anyone with any security education did not trust any drive built in encryption.

    • Re: (Score:3, Insightful)

      by thegarbz ( 1787294 )

      The point here is that the user was not in control of this decision. It was made for them by Bitlocker itself.

      • by AmiMoJo ( 196126 ) on Monday September 30, 2019 @11:21AM (#59252850) Homepage Journal

        It's always been configurable via Group Policy. All they did was change the default from "enabled" to "disabled".

        • And that's kind of the point isn't it. Why does it need to be expressly configurable somewhere hidden within the OS policy instead of say ... now where can I put it .... oh that's right, the bitlocker page. I mean Bitlocker only goes through multiple windows of questions and keys and saving options before it is enabled, but I guess displaying an additional option would have been too hard for them.

          • by Agripa ( 139780 )

            And that's kind of the point isn't it. Why does it need to be expressly configurable somewhere hidden within the OS policy instead of say ... now where can I put it .... oh that's right, the bitlocker page. I mean Bitlocker only goes through multiple windows of questions and keys and saving options before it is enabled, but I guess displaying an additional option would have been too hard for them.

            Because Microsoft knows better. And because it is magic.

  • It seems like the biggest problem in the industry especially around security. There is this lack of certification process for these system to say they are secure vs actually being secure.

    Even if these means the hardware companies need to open up their IP for public review to make sure they are following some sort of good processes. Then having independent external review to insure such processes are in play.

    Yes I would prefer hardware encryption as it won't kill my CPU to encrypt everything. However if co

    • Yes I would prefer hardware encryption as it won't kill my CPU to encrypt everything

      I'm not saying you personally should kill it, but you might want to stop worrying about if it happens. If it gets killed some day, then you'll finally have the justification you've always wanted to finally upgrade to a less-than-ten-year-old processor, with multiple cores and AES instructions. The catch is that when they go looking to see who killed your processor, everyone will say you had sufficient motive. So you'll defi

  • by ReneR ( 1057034 )
    Even I (unsuccessful one man Linux distribution https://t2sde.org/ [t2sde.org] never trusted hw built-in crypto, ..! ;-)
  • by Indy1 ( 99447 ) on Monday September 30, 2019 @09:57AM (#59252530)

    If your security requires disk encryption, then why gamble with a non standard implementation that no one has tested?

    There's a reason why I use Veracrypt on all my Windows machines.

  • Okay, this is a problem in the sense that it leaves current installation "as is". Instead, they should alert users in this case with a warning and an option to re-encrypt the SSD with software encryption. Now, all of my machines are Linux and the laptops that actually see "outside-home" usage are indeed encrypted with LUKS, which is software encryption. I'm not worried about those.

    The one I am worried about is the only Windows machine we have. My wife works in education. My wife is a Mac user, I'm fin

  • by MyFirstNameIsPaul ( 1552283 ) on Monday September 30, 2019 @10:05AM (#59252578) Journal
    Microsoft SSD certification program. All hardware manufacturers are encouraged to sign up early.
    • They already do that with secure boot keys, I can totally see them doing this with self-encrypting drives.
  • The SED standards allow the operating system/BIOS to set user and master passwords to the drive. Wouldn't it be up to Microsoft to do that automatically and change the keys when Bitlocker is initialized? Why did Microsoft trust anyone, including the user or manufacturer that they chose sane defaults?

    • by PPH ( 736903 )

      The SED standards allow the operating system/BIOS to set user and master passwords to the drive.

      What if the bad drive accepts the BIOS-set passwords and then does nothing with them?

    • The SED standards allow the operating system/BIOS to set user and master passwords to the drive. Wouldn't it be up to Microsoft to do that automatically and change the keys when Bitlocker is initialized? Why did Microsoft trust anyone, including the user or manufacturer that they chose sane defaults?

      The master passwords are for ATA passwords (Class 0). Bitlocker is an OPAL client. They are mutually exclusive. Both can't be used concurrently.

      If using Class 0 you can only use bitlocker in software mode. For SED drives this results in double encryption. (SED + Software Bitlocker)

      When using Bitlocker in hardware mode (OPAL) you can't be using Class 0 and so master passwords don't even enter into the equation.

  • Having read Netherlands and other papers on various SED implementations the people reporting on this are confusing all kinds of shit and making overblown assertions.

    First they are confusing class 0 with OPAL. Bitlocker is basically just a mediocre OPAL client. This garbage about master passwords is limited entirely to class 0 and has nothing at all to do with bitlocker.

    In the end there was a single vendor (Crucial) known to have sufficiently fucked up their OPAL implementation when it comes to internal SS

  • I have personally evaluated the RNG on some SSD controller chips and they have all been bad, thus making the security protocol insecure.

    Some got fixed after I gave the evaluation, but not all.

    The cause was the bad RNG IPs for sale from some hardware IP vendors. They were not tolerant of being put into a new context (silicon process, clock speed, noise environment etc) and so failed, but the output processing made them look good even though there was little entropy in the output.

    Unfortunately, I can't name n

"Someone's been mean to you! Tell me who it is, so I can punch him tastefully." -- Ralph Bakshi's Mighty Mouse

Working...