I personally will always use a passphrase for device encryption.
I recognize that I am decreasing my security a bit, but that tradeoff is worth it to me.
Fully agree, when I first read the HN story headline my initial reaction was where can I get a copy for use on my own machines.
Can you elaborate as to what is foolish about using a TPM?
You want those modules signed by someone like Canonical, so you don't have to mess around with a MOK? If you use Ubuntu Core they'll be happy to - for about $100,000 per year per module.
Automatically unlocking hard drive encryption is less secure than just typing in a password at boot.
No OS-independent way of confirming the user's presence means it's less secure than a Yubikey.
No iphone-style activation lock, so it's useless as a theft deterrent.
No xbox-style main memory or system bus encryption, so no protection against evil maid attacks.
Too slow for servers to offload SSL or disk encryption to - so all the important keys end up being held in memory anyway.
The spec and interface are complicated as hell, so you know there's no chance this stuff is bug-free. You want a command line tool? We've got 99 command line tools. Literally.
The foundation of its security is the code of your system's BIOS, which we all know is some of the shittiest code out there.
So the TPM offers a hair-trigger system that'll destroy all your data if your BIOS vendor messes up and miscalculates a PCR value. The security benefits you get in return are pretty minor.
You can have arbitrarily complex TPM authorization policies for unlocking storage keys. You can have it be that the loaded firmwares and OS are trusted and (or or) you have to enter in a passphrase that only the TPM can verify, and/or you can have a recovery mechanism so that if some firmware got updated you could use a smartcard or whatever to authorize moving on anyways. So, while OSes that support TPMs for storage key recovery generally have -as you say- hair-trigger policies, that's not TPM's fault but the OS's, for they could develop much more interesting policies.
1. You'll have your master password, for which it asks when you first create it. You can make this absurdly long and consider it'll be used as a last resort (say you've lost everything else and your computer is broken - you only have the drive left).
2. You can then add Windows-style auto-unlock with the TPM. It works with systemd. You can of course choose whichever registers you like, the correct TPM device if you have several.
systemd-cryptenroll /dev/sda1 --tpm2-device=auto --tpm2-pcrs=0+1+7
4. What if this is an external drive and / or often change your UEFI settings yet still need a quick unlock? Luckily, you have a FIDO2 device, so systemd's got you covered:
--unlock-fido2-device=auto instead of the tpm2
Check the Arch wiki for more:
https://wiki.archlinux.org/title/Trusted_Platform_Module#Usi...
---
edit: it should be noted that even on Windows, there's a recovery key which allows you to unlock bitlocker if the TPM was cleared. It's not clear what the poster above said that the data would be nuked (unless, of course, you only count on the TPM and don't save that key somewhere).
https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(...
It's referring to dual booting windows but the same principles apply.
Another backdoored closed piece of hardware ?