Automated TPM2 LUKS setup might be the one thing that can get me to switch from Fedora to OpenSUSE.
deleted by creator
Yep, you need a pin for your TPM to be safe. Here’s a proof of concept of someone unlocking Linux systems without TPM pin.
https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/
What makes TPM+pin safer than just having a normal LUKS password? I would think it would be the same amount of security just with more chance of data loss if your computer gets damaged
deleted by creator
Interesting, how do you recover from that and get your data back?
deleted by creator
As I understand it the TPM is for people who have physical access. It prevents them from cloning your disk.
I think with an adequately long password (or an adequately resource-intensive encryption algorithm) you can secure your disk enough to prevent unauthorized access. But the TPM would prevent them from removing your hard-drive and shunting it into a super-computer (so all password attempts wouldn’t need to be on the crummy 10-year old laptop CPU) so a TPM + password is more secure.
I’ve read the arguments and trust the people who know far more than I do about this, but… I just find it difficult to think of “unlocks automatically” as more safe than “is locked until I enter my password”. I’m open for it, but it just feels strange to me.
Is it possible to configure the kernel to allow access to decrypted contend only through the user session?
Theoretically, kernel keys can be set to be readable only by the user session, and in an uncompromised root is not able to read those keys. I can imagine a filesystem encryption design that uses a user session key to en/decrypt data on the fly using a user session key, such that not even root or a process in another user session could read the mounted filesystem.
Does such a system exist? As I understand, this is not the way dm-crypt or LUKS work. FDE and TPM are still vulnerable to hacking while everything is running, unlocked, and mounted.
I believe thats how Android works. As I recall, it uses fscrypt.
Yeah, it sounds like something you could do with SE linux and some scripting to handle mounting the user’s filesystem as needed.
Ok, I went and read some more about it, and you can manage keys with the kernel user session keyring. So it’s possible.
It brought me back around to why systemd is so shitty.
Session Keyring (Rejected)
This strategy involves placing all keys for fscrypt in KEY_SPEC_SESSION_KEYRING. Using the current session keyring means that fscrypt will not need elevated privileges to place keys in this keyring, eliminating the need for a setuid binary. It also means that if something like pam_keyinit is used, the keys will be inherited across things like sudo.
However, this strategy has a few significant downsides that led to it not being used. The first issue is that keys unlocked in one session for a user are (sometimes) not accessible to the user in other sessions. This can create confusion for users unable to access certain directories. However, the bigger problem is that systemd is incompatible with use of the system keyring. The systemd maintainers are of the reasonable position that the session keyring just shouldn’t be used.
Emphasis mine. Because the user session keyring is incompatible with systemd, the Poetterites say it shouldn’t be used.
The only way to handle keys securely Ok base Linux shouldn’t be used because it’s incompatible with systemd. What a way to see the world: so convinced in the superiority of your monolithic monster system that you argue against an immediately available way of improving security.
It’s incompatible, by the way, because systemd doesn’t run user jobs in the user’s session, but in parallel sessions. This means that, if you use systemd, you can’t use the most secure way of handling secrets with fscrypt, the kernel user session keyring.
Integrated TPM chips have been busted for a while
TPM + Pin with Secure Boot is still unbroken AFAIK
And as far als inux goes, physical access to TPM is game over
Isn’t setting up fscrypt on your home partition enough?
Not really. Imagine they replace the ssh binary with a back doored version. Home directory encryption protects your data but not your system.
