3 ms·

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 tha

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?

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?