3 ms·

TPM, at least older version <1.2 were still subject to physical key exfil attacks [1] because the chips communications with other parts of the board were done i

TPM, at least older version <1.2 were still subject to physical key exfil attacks [1] because the chips communications with other parts of the board were done in the clear. So it was/is recommended to use a pin/key and/or recovery key to ensure the security of the data. Unless your only threat model was to protect against common thievery and assume the attack had no technical prowess (and that’s perfectly fine, I do this for my company). Not to mention they were kinda used as a warranty canary for Truecrypt [2]. There were suspicions that nation states may have hardware bypasses worked out. Later there were implementations of hardware encryption found to be vulnerable. So even now bitlicker does everything in software by default. [3] So I understand why FOSS devs would rely more on standard practice (shared keys) with LUKS and not embrace hardware enclave options like TPM. They haven’t been the most reliable over the long term and are harder to patch/fix. [1] https://pulsesecurity.co.nz/articles/TPM-sniffing https://pulsesecurity.co.nz/articles/TPM-sniffing [2] https://threatpost.com/of-truecrypt-and-warrant-canaries/106355/ https://threatpost.com/of-truecrypt-and-warrant-canaries/106... [3] https://www.technadu.com/bitlocker-to-use-software-encryption-on-windows-10/54907/ https://www.technadu.com/bitlocker-to-use-software-encryptio...

smoldesu 5y ago
Plus, many Linux users just outright distrust the NIST encryption employed by security subsystems. Why encrypt your drive with SHA-2 keys that might be backdoored when you could just as easily encrypt with Ed25519?
jeroenhd 5y ago
Bitlocker still uses the TPM on modern installs. Hardware encryption on SSDs and similar aren't used anymore, but those aren't directly related. Bitlocker is still vulnerable to key exfiltration attacks because it's not using any encrypted communication protocols that exist in the TPM standard, but that can be (and should be!) fixed. In the end, I use encryption to make sure nobody can just plug in a flash drive and copy all my personal files and passwords off my laptop. If they have the time and tools to exfiltrate the security key through the SPI bus, they probably have the means to install a hardware key logger in my keyboard as well. The attacks against TPMs are out of scope for my threat model and honestly they probably should be for anyone but businesses carrying secrets as well. If the United States or China wanted my passwords that badly, they'd probably just drug me or hit me until I hand them over. Defending against such adversaries requires more than just encryption, you'd need to use something like Qubes and alter your entire lifestyle to be secure. What I want is to have a Linux system where I can turn it on without a password and have a good reason to believe that my files weren't compromises by the maid and that the OS didn't get keylogged. That requires several parts working together. Getting secure boot to work is easy enough these days, but once you get through secure boot you're in for a challenge. I don't know of any stable bootloaders that don't allow you to edit the init binary to /bin/bash to give you a root shell from the menu, which is a requirement for the ease of use Windows provides. I also don't know if it's even possible to get a chain of trust from initramfs back to the hardware like Windows allows for. The *BSDs seem to be doing some kind of checksumming, but I don't know how far Linux is along with this. In my ideal world, you get prompted on how to encrypt your Linux system upon install. "Disabled", "Automatic" or "Secure", with a note that "secure" is probably what you want if you can't pick but you have to provide a password at boot. I'd also like for popular distros to switch to full disk encryption because the unencrypted boot partition defeats half the point without secure boot and custom keys (which nobody actually uses). Microsoft proves that this can be done, although their default allows for booting without a password a bit too easy. If you buy Windows with a Pro key, they'll encrypt your system in place with the click of a button. Everyone can set it up, and in many cases it's even the default. This is a basic usability security feature that Linux just can't compete with, and in my opinion that's a shame.

smoldesu 5y ago

Plus, many Linux users just outright distrust the NIST encryption employed by security subsystems. Why encrypt your drive with SHA-2 keys that might be backdoored when you could just as easily encrypt with Ed25519?

jeroenhd 5y ago

Bitlocker still uses the TPM on modern installs. Hardware encryption on SSDs and similar aren't used anymore, but those aren't directly related. Bitlocker is still vulnerable to key exfiltration attacks because it's not using any encrypted communication protocols that exist in the TPM standard, but that can be (and should be!) fixed. In the end, I use encryption to make sure nobody can just plug in a flash drive and copy all my personal files and passwords off my laptop. If they have the time and tools to exfiltrate the security key through the SPI bus, they probably have the means to install a hardware key logger in my keyboard as well. The attacks against TPMs are out of scope for my threat model and honestly they probably should be for anyone but businesses carrying secrets as well. If the United States or China wanted my passwords that badly, they'd probably just drug me or hit me until I hand them over. Defending against such adversaries requires more than just encryption, you'd need to use something like Qubes and alter your entire lifestyle to be secure. What I want is to have a Linux system where I can turn it on without a password and have a good reason to believe that my files weren't compromises by the maid and that the OS didn't get keylogged. That requires several parts working together. Getting secure boot to work is easy enough these days, but once you get through secure boot you're in for a challenge. I don't know of any stable bootloaders that don't allow you to edit the init binary to /bin/bash to give you a root shell from the menu, which is a requirement for the ease of use Windows provides. I also don't know if it's even possible to get a chain of trust from initramfs back to the hardware like Windows allows for. The *BSDs seem to be doing some kind of checksumming, but I don't know how far Linux is along with this. In my ideal world, you get prompted on how to encrypt your Linux system upon install. "Disabled", "Automatic" or "Secure", with a note that "secure" is probably what you want if you can't pick but you have to provide a password at boot. I'd also like for popular distros to switch to full disk encryption because the unencrypted boot partition defeats half the point without secure boot and custom keys (which nobody actually uses). Microsoft proves that this can be done, although their default allows for booting without a password a bit too easy. If you buy Windows with a Pro key, they'll encrypt your system in place with the click of a button. Everyone can set it up, and in many cases it's even the default. This is a basic usability security feature that Linux just can't compete with, and in my opinion that's a shame.