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

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

Really, not so much.

The problem here isn't so much with transparency as with delegating cryptography to non-cryptographers (or, for that matter, trusting that other vendors have had cryptographers review their designs). Based on the track record not only of open source cryptography but also of internal review of closed-source cryptography (that is: closed source software reviewed by the vendor that wrote it), having access to designs and code is of marginal importance. Crypto bugs of comparable severity have lived for many, many years in these systems.

What you actually want is an assurance that no link in the security chain of a system protected by cryptography depends on a cryptographic capability had hasn't been formally assessed. Ideally, you want the specific name of the person who assessed it. For instance: Intel's SGX setup has been audited by third parties and was also designed and in some sense overseen by Shay Gueron. You will never see any of that underlying code, but you would probably be crazy to trust an comparably ambitious un-vouched cryptographic enclave more than SGX. Similar story with Amazon and KMS (again: Shay Gueron, but also in-house crypto experts at AWS).

If anything, this story illustrates how weak an obstacle closed source really is. This is an academic project, and they tore up something like 8 different drives and game-overed most of them.

Of course, I agree with the broader point that Microsoft shouldn't have trusted hardware cryptographic capabilities they clearly knew nothing about (Microsoft also has sharp crypto people, all of whom would have barfed all over any of these designs).

I've been moving more of my purchases back to cash. Not that I'm purchasing anything nefarious -- well, until I consider how e.g. purchasing medication X may be used against me, something I consider to be nefarious on the part of these companies doing and using said data mining.

Anyway, not that I'm purchasing anything nefarious. But to hell with them.

P.S. I also occasionally think about the 2-5% price markups we universally face, put in place to compensate for credit card processing fees. Although there are valid counterarguments about the risk and cost for businesses, and people in more personally vulnerable environments, of handling cash.

Sorry no, i don't trust Shay Gueron either and, even if I did, I wouldn't trust what Intel, AWS or anybody else did after he left the building. Same goes for Whatsapp. It might be based on Moxies protocols and excellent work. I might trust Moxie, but I still don't trust WhatsApp to be eavesdrop free because I can't easily create compatible clients, inspect their protocol, or look at their code.

That's not to say you shouldn't use TPMs, HSMs, or CPU enclaves. It's just that, if at all possible, you shouldn't elevate them to being the only thing protecting you. In fact, most of these devices can be coupled with software encryption by splitting secrets between them and the users brain. My android phone for instance is encrypted, but only protected by a 6 digit PIN. I'm aware that I'm totally dependent on the SoC vendor here to rate-limit and otherwise fend off bruteforce attacks and protect the key ultimately protecting my data. But you know what? The encryption itself is still done in software and can be verified, and I have the choice to use a ridiculously long passphrase instead.

What Microsoft did is choose a stupid default, and put their users at unknown risk.

>Transparency is a dependency of trust.

I think you go too far here. Trust is a dynamic spectrum, not binary. Transparency is one potential avenue to add trust, but is neither necessary nor sufficient in most cases. Every instance must be evaluated in light of its specific details, threat scenarios, and available tradeoffs.

>If you can't see how it works, then it's objectively impossible to trust it to do the right thing.

For most people "seeing how it works" is utterly meaningless by itself because few are able to properly evaluate the system (both knowledge and time play a role). For complex systems they're simply physically beyond the capability of any human to retroactively fully evaluate, or any system at all for that matter. Transparency can help positively change the incentives all involved players face, lower the upfront resource cost to evaluation which in turn may allow users to expand their trust parties to include actors with more direct interest in their interests, allow more casual white hat investigation even if there is less direct compelling need, etc.

In this specific case yes, open should definitely be standard given the stakes and because pure symmetric crypto should be simple, fast and standardized long since. There is no competitive advantage or secret algorithms here to be had. Furthermore as something that is effectively "infrastructure" it can result in less attention then flashier stuff.

But transparency is not a panacea, and closed software can perfectly well be probed anyway (as this very software and every single vulnerability ever found in proprietary software demonstrates!). The biggest value of open is less finding issues then fixing them. That was always the big driver of open source, not that it would somehow be magically bug free by the power of a thousand eyes but that when issues were discovered users wouldn't be up shit creek because whoever made it had gone out of business or moved on to new products or whatever. That has happened constantly with proprietary products for decades, the frustration with that is the huge practical driver for OSS. Over a long enough time span a lot of proprietary software devs will die or pivot or abandon useful expensive "old" tools without support and in turn their customers will get screwed. Transparency/openness can help with that, or at least offer more options. But in terms of just finding security vulnerabilities it's much less of a big deal then it gets made out, which again should be obvious given all the security vulns in proprietary software constantly being found.