Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]
1–10 of 113 posts
Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]
#2"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
Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]
#3"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. BitLocke…
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.
Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]
#4"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. BitLocke…
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.
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
Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]
#5I 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.
Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]
#6Warning - this file will automatically download instead of opening up in the browser.
Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]
#7As 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/i...
Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]
#8I 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.
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.
Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]
#9I 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.
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.
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.
Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]
#10Earlier quoted context omitted.
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.
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.
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.