4 ms·

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 decry

by Groxx 3y ago

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_cryptsetup_initrd_shell.html https://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptset...

deleted 3y ago
[deleted]
brenns10 3y ago
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.
- Groxx 3y ago
  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).
Groxx 3y ago
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_cryptsetup_initrd_shell.html 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).
- Groxx 3y ago
  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.

by Groxx 3y ago

deleted 3y ago

[deleted]

brenns10 3y ago

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.

Groxx 3y ago
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).

Groxx 3y ago

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_cryptsetup_initrd_shell.html 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).

Groxx 3y ago
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.