Comment by Groxx | Hacker News Reader

Comment by Groxx | Hacker News Reader

So to double check my understanding of this article and the linked one that led to it[1], the issue is:

1. the TPM does not require a password to get the decryption keys

2. bootup decryption passwords are checked by code, before asking (using?) the TPM's data (passwordless, because the bootup code is trusted)

3. exhausting multiple layers of retries causes ^ part 2's code to accidentally get/use the decryption data from the TPM

And assuming that's correct....

WTF

Isn't that stupidly insecure design, because even with trusted-boot checks it's probably trivially bypassed with hardware access (edit: like cutting traces)? Why even offer a bootup password if that's how it's implemented?

Like... at the absolute minimum, a sane design would not completely trust the TPM. Combine the TPM's key with the password to get the real key. No additional steps for users, and it eliminates all TPM-only attacks (subject to your password strength... but currently that is 0 so anything is an improvement).

[1]: https://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptset...

TPMs typically won't give out a secret unless all of the software which has been loaded and executed was "measured" and found to be unmodified from when the secret was stored. So you couldn't simply stick your own hard disk or USB disk into the computer and then ask the TPM for the secret: the running software wouldn't match, and the TPM would refuse.

This is a problem because the "approved" software has this strange vulnerability to get into the rescue shell, right at the point where the TPM would be happy to give you the secret because the software is unmodified.

Which wouldn't really be an issue if all the trust wasn't unnecessarily put on a single system, yes.

This is the equivalent of a rubber hose attack, where your OS vendor is being threatened and can give away your information retroactively. That's ridiculous to even consider allowing if you're selling something as "securely encrypted", just make it E2EE (derive the key rather than directly using the TPM's data).

On further reading and wondering what some of these terms / tools are: since this is describing a system with un-attended decryption, it seems like it literally requires passwordless access to the disk encryption keys.

If that re-reading is correct: yeah, there's not much choice but to put all hope in your code + the TPM, since you essentially can't wait for a password. You get what you pay for in that case - no password means no password, so you're inherently vulnerable to exploits like this.

The linked article, https://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptset... , seems to describe this kind of setup: the exploit gets you root in the boot partition only, but not any encrypted volumes, so encrypted data is still encrypted. An attacker could get access to anything not protected otherwise though, e.g. unencrypted volumes and hardware, which is a potentially big problem for cloud environments but not so much personal device theft (they already have the hardware).

Nah, I'm doubting myself more here as time passes.

If it's meant for unattended booting, why/how is there a password?

This smells more and more like an extremely poorly thought out system that allowed a bug to compromise the system.

Reply on news.ycombinator.com