12 ms·

Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

224 points by exceptione 8y ago

DyslexicAtheist 8y ago
"We have analyzed the hardware full-disk encryption of several SSDs by reverse engineering their firmware. In theory, the security guarantees offered by hardware encryption are similar to or better than software implementations. In reality, we found that many hardware implementations have critical security weaknesses, for many models allowing for complete recovery of the data without knowledge of any secret. BitLocker, the encryption software built into Microsoft Windows will rely exclusively on hardware full-disk encryption if the SSD advertises supported for it. Thus, for these drives, data protected by BitLocker is also compromised.This challenges the view that hardware encryption is prefer-able over software encryption. We conclude that one should not rely solely on hardware encryption offered by SSDs." we know how bad general code quality is in commercial vendor firmware, it's not surprising to see this
- exceptione 8y ago
  I still think it's shocking, and I imagine a lot of companies and professionals rely on hardware encryption based on the presumption that it would be safer than software based encryption. I myself trusted the Opal-certification too. There was really no option for the vendors to stunt this feature. For me, this paper is rather alarming and should be on the front page.
  - DyslexicAtheist 8y ago
    I fully agree with you EDIT: I found this link in the references section to a Travis Goodspeed talk (he writes a lot for PoC||GTFO) - it is phenomenal: https://www.youtube.com/watch?v=8Zpb34Qf0NY https://www.youtube.com/watch?v=8Zpb34Qf0NY
  - xoa 8y ago
    It's genuinely interesting to hear this is the case. I mean, I don't disagree with you that it's important to have out in the open regardless. But I honestly just assumed from the start that Opal would just generally be a badly implemented feature checkbox not something dependable. For this case of crypto code it didn't seem trustworthy if it wasn't open, standard and trivially auditable. Unlike Apple for example these products don't have the kind of marketshare, clear public profile and constant open as well as covert attacks that would be necessary to grant a higher degree of confidence despite being closed, the barrier needs to be lower given the lower profile. So I've never used the hardware crypto in any SSD, it's always been through software on top, although in fairness that has become easier to do as AES-NI has become more universal in CPUs. That has given a lot of the assurance and speed of a dedicated hardware crypto chip while still using higher level software. I guess in retrospect it's quite reasonable most people would trust it, or for that matter not think about it at all but rather trust Microsoft or whomever to be getting that right for them and that checking the FDE Box in the GUI would mean what it said. A good example of having personal blinders on for me, I'm too used to just ignoring Opal entirely since the day it was introduced.
  - paavoova 8y ago
    > the presumption that it would be safer than software based encryption Is this really a common presumption? Why are companies making security decisions based on mere presumption? Wikipedia has a citation from 2013 [1] that discusses a number of vulnerabilities exploiting constant-power hot swapping, so if you'd done any research at all during the last decade you wouldn't be so shocked. It seems SEDs are merely a convenience as far as transparency and overhead goes, and as a last resort when proper software FDE isn't available. All this talk about Bitlocker and such over LUKS suggests they're targeted at consumers, which would explain the shoddy engineering and proprietary specs. [1] https://www.cs1.tf.fau.de/research/system-security-and-software-protection-group/sed-insecurity/ https://www.cs1.tf.fau.de/research/system-security-and-softw... We show, however, that depending on the configuration of a system, hardware-based FDE is generally as insecure as software-based FDE [like TrueCrypt and BitLocker] Note that, despite Linux being mentioned in the paper and utilized for tests, dm-crypt/Luks is not, only software solutions like Bitlocker. Likewise in the OP paper. Which makes me think this is a consumer-class vulnerability, due to the focus the researchers take. Surely enterprises are using something other than SED?
- tjoff 8y ago
  What surprised me was that bitlocker could make use of it. I always assumed that software encryption would be much safer but I had no idea that the in-device hardware encryption could be leveraged by software.
- zAy0LfpBZLC8mAC 8y ago
  > This challenges the view that hardware encryption is prefer-able over software encryption. WAT? Who ever thought that? For exactly the reason you state, I certainly would not have recommended anyone to ever trust "hardware encryption". And it's not just that firmware tends to be terrible: We had plenty of "secure storage" thingies that weren't.
  - igor_sk 8y ago
    properly implemented, hw encryption is better because it does not expose key material in the RAM even for a brief moment.
    - zAy0LfpBZLC8mAC 8y ago
      Well, yeah, sure, but who would possibly expect something like this to be implemented properly?
      - acct1771 8y ago
        95%+ of consumers.
- wlll 8y ago
  > we know how bad general code quality is in commercial vendor firmware, it's not surprising to see this Quite. My experience of firmware is that it's usually total junk, from Internet connected web cams, to HTTP routers, to backplanes for NAS devices. I was putting together a FreeNAS box for home a couple of months ago and this was the first time I'd seen drives with a self-encrypting ability. I ignored it and went for software encryption.
trulyrandom 8y ago
I did not know that BitLocker relies on hardware encryption if the SSD has support for it. That seems like an extremely dangerous default to have, especially as the implementation is closed source in most (all?) cases.
- Skunkleton 8y ago
  But bitlocker itself is closed source. Why do you trust microsoft more than the disk vendor? Further, if I were going to choose an opaque blob to trust I would choose the one that has the smaller attack surface.
  - trulyrandom 8y ago
    Whether or not Microsoft can be trusted is not relevant. It's just very surprising to me that Microsoft itself blindly trusts disk vendors, instead of using their own encryption layer on top.
    - Skunkleton 8y ago
      Ahh. I would guess that they aren't blindly trusting them. Given Microsoft's historical relationships with hardware vendors I would bet they have at least partially audited the firmware.
      - trulyrandom 8y ago
        Yeah, I can imagine they'd conduct audits for firmware on the hardware they ship with their own products. I doubt they look at much beyond that though.
  - dogma1138 8y ago
    Because Windows due to its attack surface is much better researched and understood, Microsoft actually has a decent track record of investing in security and it can be patched.
    - 8y ago
conbandit 8y ago
Warning - this file will automatically download instead of opening up in the browser.
- deleted 8y ago
  [deleted]
- jobigoud 8y ago
  It's a direct link to a PDF, what it does depends on how your browser is configured. For me on FF it shows a dialog asking if I want to open or save.
  - sandov 8y ago
    Doesn't the website set a header or something like that for the preferred way of consuming it?: in-site viewing or downñoading to hdd?
- dang 8y ago
  We changed the link. The pdf is at https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf.
amarshall 8y ago
As far as I know, no other popular full-disk encryption (LUKS, geli, FileVault) delegates to the SSD’s hardware encryption (by default, anyway) as BitLocker apparently does [0]. Anyone know otherwise? [0]: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj679890(v=ws.11)#configure-use-of-hardware-based-encryption-for-fixed-data-drives https://docs.microsoft.com/en-us/previous-versions/windows/i...
- wmf 8y ago
  Lots of enterprise SAN/NAS equipment uses SEDs, although one would hope those are actually secure considering how much they charge for it.
  - yellowapple 8y ago
    "although one would hope those are actually secure considering how much they charge for it" Considering BitLocker requires a Windows purchase (unless you pirate it) and LVM costs exactly $0, I think it's safe to say that the amount of money thrown is not a good indicator of actual security.
  - pbarnes_1 8y ago
    Yeah. Would love to see if a Toshiba PX04/PX05 with SED/SED FIPS is vulnerable. That's a very expensive add-on.
raesene9 8y ago
In case you're wondering if this affects you (I know I was wondering) the relevant command to run is (in an elevated command prompt) `manage-bde -status <drive_letter>` Then look at the output for "Encryption Method". If it says something like "XTS-AES 128" I think that means you're using software encryption. If it mentions hardware encryption, then it's using it :) (more info. https://helgeklein.com/blog/2015/01/how-to-enable-bitlocker-hardware-encryption-with-ssd/ https://helgeklein.com/blog/2015/01/how-to-enable-bitlocker-...) FWIW on my Win 10 install with a Samsung PM871 it was set to software encryption.
- dogma1138 8y ago
  I never used HW disk encryption (other than TPM) because I always seen it as unnecessary as in it doesn’t really improve on SW+TPM in terms of performance or compatibility and could only cause potential data recovery and security issues. There is no performance benefit in fact with modern CPUs that have crypto extensions it’s often slower and I never trust commercial solutions ever since you could dump the key from the SanDisk/McAfee “secure” flash drives, and all previous HDD password protection schemes like the ATA passcode were so shit I didn’t even understood why people bothered with them in the first place.
  - pmorici 8y ago
    The hw drives absolutely perform better if you have a raid.
    - dogma1138 8y ago
      Is there a source for that? XTS-AES was actually slower with some of the drives, block chaining for raid is done on the raid logical blocks I don’t see how HW would be faster, in fact until fairly recently HW encryption didn’t really work with raid setups at least those available to consumers.
      - pmorici 8y ago
        That was my point. Software aes-Xts gets slow when you use it on a raid. If you do use it on raid put it under the raid so make one decrypt device for each drive then raid those.
chmike 8y ago
It would have been interesting to see the result with Intel SSD
nly 8y ago
Why would anyone be surprised about this? If you can't read a whitepaper, and inspect the algorithm to a degree where you can create your own provably-compatible implementation, or easily inspect the vendors source code, then you should just assume it's implemented incompetently and is completely and utterly compromised. The same goes for all cellular/mobile phone encryption standards, proprietary VPN solutions, proprietary DRM, crypto used in banking (Chip n Pin etc etc). All compromised. Period. Don't trust it. All crypto implementations should be guilty until proven innocent under serious peer review. The same attitude should be taken with anything not encrypted. Yes your ISP is spying on your browsing habits, logging everything, and probably will one day sell that data. Yes your bank is analyzing your spending habits. Just assume it's happening. There's enough evidence out there now that this is the new reality.
- yellowapple 8y ago
  Yep, yep, and yep. I've said it enough to sound like a broken record: Transparency is a dependency of trust. If you can't see how it works, then it's objectively impossible to trust it to do the right thing. This applies to everything on a computer, really. Is your browser transparent? Is your operating system transparent? What about the drivers? Device firmware? That "security" solution that unexpectedly ushered in the Year of the MINIX Desktop™? Of course, we sacrifice some of those points in favor of pragmatism, but if you ain't paranoid about your computer's lack of transparency, you should be.
  - nly 8y ago
    It's not really about vendors being malicious. It's just that both the carrots and the sticks involved in providing secure products are weak. You can slap a "Uses 256-bit military grade encryption" sticker on your product, pull some half-arsed home-baked crap and make more money. When someone exposes you you just go "Darn, those hackers... ruining things for good everyday folk" It's an attitude problem. Most people wouldn't buy a glass house where people on the street could watch you shower and poop, but that's what we have in tech.
    - 8y ago
Fnoord 8y ago
BitLocker, ehh? Truecrypt.org, before its final demise, claimed it was obsolete due to FDE being native in Windows nowadays (ie. BitLocker).
- nyolfen 8y ago
  i remember this being widely interpreted as sarcasm or a straussian double meaning at the time
- Simon_says 8y ago
  LOL
walrus01 8y ago
There's a very strong argument that encryption should only be implemented in software, in something GPL, LGPL, BSD or Apache licensed so that its full source code can be examined by cryptographers. I'm extremely wary of vendor supplied hardware-based "crypto" that is totally opaque with what's going on under the hood.
- sandov 8y ago
  IMO, it should be common sense at this point
tptacek 8y ago
Litany of failures: * Firmware protection in drives is almost uniformly broken, so that they can get code execution (through JTAG or through hacked firmware images) routinely. This is bad, but shouldn't be the end of the world, since in the drive encryption threat model you don't want to have to depend on the firmware anyways. But: * Two Crucial SSDs encrypt the drive with a key unrelated to the password; the password check is enforced only with an "if" statement in the firmware code, which can be overridden. * Another Crucial SSD uses PBKDF2 to derive keys, but then has a master override key, which is blank by default. It also has a multi-volume encryption interface (Opal) with slots for volume keys, all of which are populated whether they're in use or not, and if they're not in use, they're protected with an all-zeroes key that recovers the master key for the device. * Two Samsung drives implement PBKDF2, but not in the default mode, which is "password is checked in an if statement, like the Crucial drive". Also, the wear-leveling logic in one of the drives doesn't zero out old copies of the master key, so that when you change your disk password (or set it for the first time), unprotected copies of the data encryption key are left in blocks on the device. * The Samsung T3 portable drive uses the drive password in an "if" statement and is trivially unlocked through JTAG. Its successor, the T5, is no more cryptographically sound, but is simply harder to obtain code execution on. People have strange ideas about what disk encryption is good for (in reality, full-disk encryption really only protects you from the situation where your powered-down, locked device is physically stolen from you and never recovered [if you get the drive back, you have to assume, at least from a cryptographic standpoint, that it's now malicious.]) But the net result of this work is that Samsung and Crucial couldn't even get that right. This paper is full of attacks where someone simply steals your drive and then unlocks it on their own. It's bananas.
- walterbell 8y ago
  Are there regulations in any industry which require the name of software authors on binaries/products, or at least the name of someone who approved the security claims made by the device?
  - tptacek 8y ago
    Absolutely not.
paavoova 8y ago
I wonder what this implies for SSDs that claim to support instantaneous ATA Secure Erase. Many SEDs, when issued this command, will simply discard their internal key and generate a new one, in theory rendering data irretrievable. I've encountered this method recommend over traditional wiping for reasons of security (you can't be sure all blocks are wiped when overwriting due to internal reservation), speed, and flash-longevity.
- mjevans 8y ago
  My own personal policy is to allow SSD reuse internally, but to just physically destroy the drives at the end of useful life.
monocasa 8y ago
I'm not surprised. My understanding was that encryption was originally added as a whitening step to the data, a product guy somewhere heard about it and added it as a checkbox.
CaliforniaKarl 8y ago
Here's what I love the most about this: If you have a full-disk encrypted Windows laptop, which is fully powered down (or hybernated), and the laptop contains PHI, _and_ you lose the laptop, then you probably do _not_ have to report it as a data breach. (https://www.hitechanswers.net/hipaa-doesnt-require-data-encryption-but-you-should/ https://www.hitechanswers.net/hipaa-doesnt-require-data-encr...) But with this revelation, if you have an affected SSD, and you are running Windows, then losing such a laptop may now be a reportable event.
tyingq 8y ago
Not related to encryption, but I enjoyed this article where they hack into the microcontroller on a typical HDD: http://spritesmods.com/?art=hddhack http://spritesmods.com/?art=hddhack
pmorici 8y ago
I spent a lot of time this year looking at ssds with encryption support. I’ve come to the conclusion that what is really needed is to separate the crypto hardware from the storage. Make a 2.5” drive sled for example that takes any m.2 and adds cryto to it. Then you can choose the best supplier for both crypto and flash independently.
dang 8y ago
The paper is here: https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf. (That was the submitted URL but download links don't work so well for HN stories.)
sandov 8y ago
Who would have thought that proprietary firmware encryption implemented by hardware vendors would be crappy?
- Arkight 8y ago
  Who would have thought water is dry?
nootropicat 8y ago
Based on the presented analysis, TCG Opal encryption for the Samsung 850+ series appears to be secure. I don't see a reason to still use software encryption. I would sooner expect a backdoor in cpus rather than SSD. Almost nobody even has the capability to even analyze the microcode for modern cpus. It could contain a backdoor that stores N aes passwords in the cpu itself, sorted by the amount of data encrypted. Using AES-NI makes it relatively trivial. At worst, both ssd controllers and amd/intel cpus would have backdoors like that, but if that's the case there's nothing to be done.
- m45t3r 8y ago
  > I don't see a reason to still use software encryption. Why not? Software encryption can still be hardware accelerated (thanks to encryption instructions in the CPU), and it is fast enough to not be a bottleneck unless you have a very fast IO device (and very fast in this case mean either Optane or modern SSD's in RAID-0). Also, the impact in CPU usage/power consumption is low.
deleted 8y ago
[deleted]
rhtcmu 8y ago
I am the original inventor of self-encrypting drives. My 3-4 page comment is too long so you can read it here www.privust.com/sedlies Which describes the work at RU, its partial truths, and the lying tweets that followed. Robert Thibadeau, Ph.D.
- fencepost 8y ago
  You'll probably get more credibility if that's linked in some way with your page at CMU or your Linkedin profile.

224 points by exceptione 8y ago

"We have analyzed the hardware full-disk encryption of several SSDs by reverse engineering their firmware. In theory, the security guarantees offered by hardware encryption are similar to or better than software implementations. In reality, we found that many hardware implementations have critical security weaknesses, for many models allowing for complete recovery of the data without knowledge of any secret. BitLocker, the encryption software built into Microsoft Windows will rely exclusively on hardware full-disk encryption if the SSD advertises supported for it. Thus, for these drives, data protected by BitLocker is also compromised.This challenges the view that hardware encryption is prefer-able over software encryption. We conclude that one should not rely solely on hardware encryption offered by SSDs." we know how bad general code quality is in commercial vendor firmware, it's not surprising to see this

exceptione 8y ago
I still think it's shocking, and I imagine a lot of companies and professionals rely on hardware encryption based on the presumption that it would be safer than software based encryption. I myself trusted the Opal-certification too. There was really no option for the vendors to stunt this feature. For me, this paper is rather alarming and should be on the front page.
- DyslexicAtheist 8y ago
  I fully agree with you EDIT: I found this link in the references section to a Travis Goodspeed talk (he writes a lot for PoC||GTFO) - it is phenomenal: https://www.youtube.com/watch?v=8Zpb34Qf0NY https://www.youtube.com/watch?v=8Zpb34Qf0NY
- xoa 8y ago
  It's genuinely interesting to hear this is the case. I mean, I don't disagree with you that it's important to have out in the open regardless. But I honestly just assumed from the start that Opal would just generally be a badly implemented feature checkbox not something dependable. For this case of crypto code it didn't seem trustworthy if it wasn't open, standard and trivially auditable. Unlike Apple for example these products don't have the kind of marketshare, clear public profile and constant open as well as covert attacks that would be necessary to grant a higher degree of confidence despite being closed, the barrier needs to be lower given the lower profile. So I've never used the hardware crypto in any SSD, it's always been through software on top, although in fairness that has become easier to do as AES-NI has become more universal in CPUs. That has given a lot of the assurance and speed of a dedicated hardware crypto chip while still using higher level software. I guess in retrospect it's quite reasonable most people would trust it, or for that matter not think about it at all but rather trust Microsoft or whomever to be getting that right for them and that checking the FDE Box in the GUI would mean what it said. A good example of having personal blinders on for me, I'm too used to just ignoring Opal entirely since the day it was introduced.
- paavoova 8y ago
  > the presumption that it would be safer than software based encryption Is this really a common presumption? Why are companies making security decisions based on mere presumption? Wikipedia has a citation from 2013 [1] that discusses a number of vulnerabilities exploiting constant-power hot swapping, so if you'd done any research at all during the last decade you wouldn't be so shocked. It seems SEDs are merely a convenience as far as transparency and overhead goes, and as a last resort when proper software FDE isn't available. All this talk about Bitlocker and such over LUKS suggests they're targeted at consumers, which would explain the shoddy engineering and proprietary specs. [1] https://www.cs1.tf.fau.de/research/system-security-and-software-protection-group/sed-insecurity/ https://www.cs1.tf.fau.de/research/system-security-and-softw... We show, however, that depending on the configuration of a system, hardware-based FDE is generally as insecure as software-based FDE [like TrueCrypt and BitLocker] Note that, despite Linux being mentioned in the paper and utilized for tests, dm-crypt/Luks is not, only software solutions like Bitlocker. Likewise in the OP paper. Which makes me think this is a consumer-class vulnerability, due to the focus the researchers take. Surely enterprises are using something other than SED?
tjoff 8y ago
What surprised me was that bitlocker could make use of it. I always assumed that software encryption would be much safer but I had no idea that the in-device hardware encryption could be leveraged by software.
zAy0LfpBZLC8mAC 8y ago
> This challenges the view that hardware encryption is prefer-able over software encryption. WAT? Who ever thought that? For exactly the reason you state, I certainly would not have recommended anyone to ever trust "hardware encryption". And it's not just that firmware tends to be terrible: We had plenty of "secure storage" thingies that weren't.
- igor_sk 8y ago
  properly implemented, hw encryption is better because it does not expose key material in the RAM even for a brief moment.
  - zAy0LfpBZLC8mAC 8y ago
    Well, yeah, sure, but who would possibly expect something like this to be implemented properly?
    - acct1771 8y ago
      95%+ of consumers.
wlll 8y ago
> we know how bad general code quality is in commercial vendor firmware, it's not surprising to see this Quite. My experience of firmware is that it's usually total junk, from Internet connected web cams, to HTTP routers, to backplanes for NAS devices. I was putting together a FreeNAS box for home a couple of months ago and this was the first time I'd seen drives with a self-encrypting ability. I ignored it and went for software encryption.

trulyrandom 8y ago

I did not know that BitLocker relies on hardware encryption if the SSD has support for it. That seems like an extremely dangerous default to have, especially as the implementation is closed source in most (all?) cases.

Skunkleton 8y ago
But bitlocker itself is closed source. Why do you trust microsoft more than the disk vendor? Further, if I were going to choose an opaque blob to trust I would choose the one that has the smaller attack surface.
- trulyrandom 8y ago
  Whether or not Microsoft can be trusted is not relevant. It's just very surprising to me that Microsoft itself blindly trusts disk vendors, instead of using their own encryption layer on top.
  - Skunkleton 8y ago
    Ahh. I would guess that they aren't blindly trusting them. Given Microsoft's historical relationships with hardware vendors I would bet they have at least partially audited the firmware.
    - trulyrandom 8y ago
      Yeah, I can imagine they'd conduct audits for firmware on the hardware they ship with their own products. I doubt they look at much beyond that though.
- dogma1138 8y ago
  Because Windows due to its attack surface is much better researched and understood, Microsoft actually has a decent track record of investing in security and it can be patched.
  - 8y ago

conbandit 8y ago

Warning - this file will automatically download instead of opening up in the browser.

deleted 8y ago
[deleted]
jobigoud 8y ago
It's a direct link to a PDF, what it does depends on how your browser is configured. For me on FF it shows a dialog asking if I want to open or save.
- sandov 8y ago
  Doesn't the website set a header or something like that for the preferred way of consuming it?: in-site viewing or downñoading to hdd?
dang 8y ago
We changed the link. The pdf is at https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf.

amarshall 8y ago

As far as I know, no other popular full-disk encryption (LUKS, geli, FileVault) delegates to the SSD’s hardware encryption (by default, anyway) as BitLocker apparently does [0]. Anyone know otherwise? [0]: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj679890(v=ws.11)#configure-use-of-hardware-based-encryption-for-fixed-data-drives https://docs.microsoft.com/en-us/previous-versions/windows/i...

wmf 8y ago
Lots of enterprise SAN/NAS equipment uses SEDs, although one would hope those are actually secure considering how much they charge for it.
- yellowapple 8y ago
  "although one would hope those are actually secure considering how much they charge for it" Considering BitLocker requires a Windows purchase (unless you pirate it) and LVM costs exactly $0, I think it's safe to say that the amount of money thrown is not a good indicator of actual security.
- pbarnes_1 8y ago
  Yeah. Would love to see if a Toshiba PX04/PX05 with SED/SED FIPS is vulnerable. That's a very expensive add-on.

raesene9 8y ago

In case you're wondering if this affects you (I know I was wondering) the relevant command to run is (in an elevated command prompt) `manage-bde -status <drive_letter>` Then look at the output for "Encryption Method". If it says something like "XTS-AES 128" I think that means you're using software encryption. If it mentions hardware encryption, then it's using it :) (more info. https://helgeklein.com/blog/2015/01/how-to-enable-bitlocker-hardware-encryption-with-ssd/ https://helgeklein.com/blog/2015/01/how-to-enable-bitlocker-...) FWIW on my Win 10 install with a Samsung PM871 it was set to software encryption.

dogma1138 8y ago
I never used HW disk encryption (other than TPM) because I always seen it as unnecessary as in it doesn’t really improve on SW+TPM in terms of performance or compatibility and could only cause potential data recovery and security issues. There is no performance benefit in fact with modern CPUs that have crypto extensions it’s often slower and I never trust commercial solutions ever since you could dump the key from the SanDisk/McAfee “secure” flash drives, and all previous HDD password protection schemes like the ATA passcode were so shit I didn’t even understood why people bothered with them in the first place.
- pmorici 8y ago
  The hw drives absolutely perform better if you have a raid.
  - dogma1138 8y ago
    Is there a source for that? XTS-AES was actually slower with some of the drives, block chaining for raid is done on the raid logical blocks I don’t see how HW would be faster, in fact until fairly recently HW encryption didn’t really work with raid setups at least those available to consumers.
    - pmorici 8y ago
      That was my point. Software aes-Xts gets slow when you use it on a raid. If you do use it on raid put it under the raid so make one decrypt device for each drive then raid those.

chmike 8y ago

It would have been interesting to see the result with Intel SSD

nly 8y ago

Why would anyone be surprised about this? If you can't read a whitepaper, and inspect the algorithm to a degree where you can create your own provably-compatible implementation, or easily inspect the vendors source code, then you should just assume it's implemented incompetently and is completely and utterly compromised. The same goes for all cellular/mobile phone encryption standards, proprietary VPN solutions, proprietary DRM, crypto used in banking (Chip n Pin etc etc). All compromised. Period. Don't trust it. All crypto implementations should be guilty until proven innocent under serious peer review. The same attitude should be taken with anything not encrypted. Yes your ISP is spying on your browsing habits, logging everything, and probably will one day sell that data. Yes your bank is analyzing your spending habits. Just assume it's happening. There's enough evidence out there now that this is the new reality.

yellowapple 8y ago
Yep, yep, and yep. I've said it enough to sound like a broken record: Transparency is a dependency of trust. If you can't see how it works, then it's objectively impossible to trust it to do the right thing. This applies to everything on a computer, really. Is your browser transparent? Is your operating system transparent? What about the drivers? Device firmware? That "security" solution that unexpectedly ushered in the Year of the MINIX Desktop™? Of course, we sacrifice some of those points in favor of pragmatism, but if you ain't paranoid about your computer's lack of transparency, you should be.
- nly 8y ago
  It's not really about vendors being malicious. It's just that both the carrots and the sticks involved in providing secure products are weak. You can slap a "Uses 256-bit military grade encryption" sticker on your product, pull some half-arsed home-baked crap and make more money. When someone exposes you you just go "Darn, those hackers... ruining things for good everyday folk" It's an attitude problem. Most people wouldn't buy a glass house where people on the street could watch you shower and poop, but that's what we have in tech.
  - 8y ago

Fnoord 8y ago

BitLocker, ehh? Truecrypt.org, before its final demise, claimed it was obsolete due to FDE being native in Windows nowadays (ie. BitLocker).

nyolfen 8y ago
i remember this being widely interpreted as sarcasm or a straussian double meaning at the time
Simon_says 8y ago
LOL

walrus01 8y ago

There's a very strong argument that encryption should only be implemented in software, in something GPL, LGPL, BSD or Apache licensed so that its full source code can be examined by cryptographers. I'm extremely wary of vendor supplied hardware-based "crypto" that is totally opaque with what's going on under the hood.

sandov 8y ago
IMO, it should be common sense at this point

tptacek 8y ago

Litany of failures: * Firmware protection in drives is almost uniformly broken, so that they can get code execution (through JTAG or through hacked firmware images) routinely. This is bad, but shouldn't be the end of the world, since in the drive encryption threat model you don't want to have to depend on the firmware anyways. But: * Two Crucial SSDs encrypt the drive with a key unrelated to the password; the password check is enforced only with an "if" statement in the firmware code, which can be overridden. * Another Crucial SSD uses PBKDF2 to derive keys, but then has a master override key, which is blank by default. It also has a multi-volume encryption interface (Opal) with slots for volume keys, all of which are populated whether they're in use or not, and if they're not in use, they're protected with an all-zeroes key that recovers the master key for the device. * Two Samsung drives implement PBKDF2, but not in the default mode, which is "password is checked in an if statement, like the Crucial drive". Also, the wear-leveling logic in one of the drives doesn't zero out old copies of the master key, so that when you change your disk password (or set it for the first time), unprotected copies of the data encryption key are left in blocks on the device. * The Samsung T3 portable drive uses the drive password in an "if" statement and is trivially unlocked through JTAG. Its successor, the T5, is no more cryptographically sound, but is simply harder to obtain code execution on. People have strange ideas about what disk encryption is good for (in reality, full-disk encryption really only protects you from the situation where your powered-down, locked device is physically stolen from you and never recovered [if you get the drive back, you have to assume, at least from a cryptographic standpoint, that it's now malicious.]) But the net result of this work is that Samsung and Crucial couldn't even get that right. This paper is full of attacks where someone simply steals your drive and then unlocks it on their own. It's bananas.

walterbell 8y ago
Are there regulations in any industry which require the name of software authors on binaries/products, or at least the name of someone who approved the security claims made by the device?
- tptacek 8y ago
  Absolutely not.

paavoova 8y ago

I wonder what this implies for SSDs that claim to support instantaneous ATA Secure Erase. Many SEDs, when issued this command, will simply discard their internal key and generate a new one, in theory rendering data irretrievable. I've encountered this method recommend over traditional wiping for reasons of security (you can't be sure all blocks are wiped when overwriting due to internal reservation), speed, and flash-longevity.

mjevans 8y ago
My own personal policy is to allow SSD reuse internally, but to just physically destroy the drives at the end of useful life.

monocasa 8y ago

I'm not surprised. My understanding was that encryption was originally added as a whitening step to the data, a product guy somewhere heard about it and added it as a checkbox.

CaliforniaKarl 8y ago

Here's what I love the most about this: If you have a full-disk encrypted Windows laptop, which is fully powered down (or hybernated), and the laptop contains PHI, _and_ you lose the laptop, then you probably do _not_ have to report it as a data breach. (https://www.hitechanswers.net/hipaa-doesnt-require-data-encryption-but-you-should/ https://www.hitechanswers.net/hipaa-doesnt-require-data-encr...) But with this revelation, if you have an affected SSD, and you are running Windows, then losing such a laptop may now be a reportable event.

tyingq 8y ago

Not related to encryption, but I enjoyed this article where they hack into the microcontroller on a typical HDD: http://spritesmods.com/?art=hddhack http://spritesmods.com/?art=hddhack

pmorici 8y ago

I spent a lot of time this year looking at ssds with encryption support. I’ve come to the conclusion that what is really needed is to separate the crypto hardware from the storage. Make a 2.5” drive sled for example that takes any m.2 and adds cryto to it. Then you can choose the best supplier for both crypto and flash independently.

dang 8y ago

The paper is here: https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf. (That was the submitted URL but download links don't work so well for HN stories.)

sandov 8y ago

Who would have thought that proprietary firmware encryption implemented by hardware vendors would be crappy?

Arkight 8y ago
Who would have thought water is dry?

nootropicat 8y ago

Based on the presented analysis, TCG Opal encryption for the Samsung 850+ series appears to be secure. I don't see a reason to still use software encryption. I would sooner expect a backdoor in cpus rather than SSD. Almost nobody even has the capability to even analyze the microcode for modern cpus. It could contain a backdoor that stores N aes passwords in the cpu itself, sorted by the amount of data encrypted. Using AES-NI makes it relatively trivial. At worst, both ssd controllers and amd/intel cpus would have backdoors like that, but if that's the case there's nothing to be done.

m45t3r 8y ago
> I don't see a reason to still use software encryption. Why not? Software encryption can still be hardware accelerated (thanks to encryption instructions in the CPU), and it is fast enough to not be a bottleneck unless you have a very fast IO device (and very fast in this case mean either Optane or modern SSD's in RAID-0). Also, the impact in CPU usage/power consumption is low.

deleted 8y ago

[deleted]

rhtcmu 8y ago

I am the original inventor of self-encrypting drives. My 3-4 page comment is too long so you can read it here www.privust.com/sedlies Which describes the work at RU, its partial truths, and the lying tweets that followed. Robert Thibadeau, Ph.D.

fencepost 8y ago
You'll probably get more credibility if that's linked in some way with your page at CMU or your Linkedin profile.