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

Post by nly » Mon, Nov 05, 2018, 9:13 PM UTC

PeterisP wrote: post #49

basilgohar wrote: post #41

Earlier quoted context omitted.

I did not read GP as saying it was a binary choice, but rather a prerequisite. That is to say, without transparency, there can be no trust, but you can also have no trust with transparency. For someone like me, who is somewhat technically competent, but not a security expert, openness means that names and figures I do trust have the chance to examine whatever I intend to use and comment on it, observe it, and make as…

"names and figures I do trust have the chance to examine whatever I intend to use and comment on it, observe it, and make assessments, including shaming poor implementations claiming traits they have no right to" does not necessarily require openness - third party audits, if done by people who you do trust, can do the same thing for closed systems, for example as described in the tptacek's comment https://news.ycombi…

Post by igor_sk » Mon, Nov 05, 2018, 9:26 PM UTC

zAy0LfpBZLC8mAC wrote: post #23

DyslexicAtheist wrote: post #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. BitLocke…

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

Post by zAy0LfpBZLC8mAC » Mon, Nov 05, 2018, 10:28 PM UTC

igor_sk wrote: post #53

zAy0LfpBZLC8mAC wrote: post #23

Earlier quoted context omitted.

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

properly implemented, hw encryption is better because it does not expose key material in the RAM even for a brief moment.

Post by walterbell » Mon, Nov 05, 2018, 10:34 PM UTC

tptacek wrote: post #36

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

Post by pmorici » Mon, Nov 05, 2018, 11:34 PM UTC

walterbell wrote: post #57

tptacek wrote: post #36

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

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?