In KDE Linux you should have the option in the installer/setup to enable auto-unlock of the full disk encryption (LUKS) via TPM, instead of typing in your passphrase every boot.
3 Likes
It will probably be possible, and we may implement support for it, but personally I don’t recommend it — at least not without a firm understanding of the risks involved and a solid backup plan.
The problem is that the TPM won’t always be available to auto-unlock the disk. Here are some scenarios:
- The TPM is broken
- Systemd’s support for the TPM is broken (see systemd-tpm2-setup-early.service and systemd-tpm2-setup.service fail after upgrading to v259 · Issue #40159 · systemd/systemd · GitHub )
- The disk controller or motherboard is broken and you need to move the disk to another computer
I’ve personally experienced 2 and 3 within the past year, so this isn’t theoretical.
What happens when the TPM can’t unlock the disk? You’d better remember the password! But you won’t; because you’re not regularly entering it, it will rotate out of your memory and you won’t know it when you need it most.
In such a scenario, you’d better have it written down somewhere else safe! Do you? Do you remember where it is? Did you remember to update the hard copy when you changed it on the computer? Most people don’t.
In my over 25 years of side-gig “helping people with computers” work, forgetting important passwords and not having them even written down anywhere is probably the #1 issue. This is why Apple (and probably others, less familiar) let you back up your decryption key on their servers. KDE doesn’t have anything like this.
4 Likes
As Nate said, tpm isn’t all that great imho either. I spent some time trying to find a good integration between tpm and yubikey in piv mode, but gave up when there wasn’t a really good way to chain one off another for two factor auth. TPM for disk only really verifies the mobo/controller is present, which someone steals it bad maid-style, that bet is somewhat off.
I wanted tpm+yubikey-piv+pin that could unlock and let me into the desktop with a push of the yubikey and my pin, and mostly got it working in arch+zfs, but it was going to take some init/systemd hacking with a 4-stage boot process (I like a challenge). Then I found the whole pam+piv was sort of busted and not even really maintained any longer to work with my yubikey properly. Then I was gonna switch to fido, but something else was weird then too, and finally I got relatively disgusted and/or busy with the the whole thing to stop work.
Sadly redhat seemed the last to support serious use of pam with piv and fido use (go figure), which a few months ago got me to tinker with ublue to see if I could do it there with a fedora-base. While I did get raid+luks working there (adding tpm key to that is trivial during or after), it wasn’t automagical via a gui (just basic mdraid+luks+btrfs cli though), and I wasn’t even thinking about trying to add my 4 stage luks+tpm+yubikey working there in immutable (yet).
I wish there were more consideration from the dists for these sorts of security features, but sadly it seems still niche interest in disparate parts of the kernel distributions to gain a cohesive solution. How long has it taken for even luks in basic form to become ubiquitous across distributions?
I can provide my notes assuming you want to go cowboy, but I forget where my efforts came apart in there now. I’m sort of waiting on some adequate hardware for a new lappy for a few years to experiment on, but nothing really caught my eye yet.
1 Like
I see your point and that’s why I think both FDE and TPM-unlock should be disabled by default.
But since I am able to write down a passphrase, I would still like to be able to enable both 
You can enroll TPM after installation:
sudo systemd-cryptenroll --tpm2-device=auto
Is that all it takes?
I’d be happy to receive complete instructions on this and write them down in our docs — while fully explaining the risks.
Well, would still be way more elegant to just have an option for it in the setup process.
I believe it is. The command auto-detects the LUKS partition. But my KDE Linux installation is not encrypted, so I can’t verify at the moment.
In this case, all we need is to open the terminal and run
sudo systemd-cryptenroll --tpm2-device=auto
Then enter the passphrase, and it’s done. The passphrase is still there, so we can use it to unlock when TPM somehow fails.
Usually an additional --tpm2-pcrs=7 option is used to bind the secret to the Secure Boot status, so that the system wouldn’t auto-unlock when the bad guy replaced the BIOS or bootloader with a rouge one. But that also means the secret would be invalidated on BIOS or bootloader upgrades. So the instructions would be much longer with how to re-enroll on that.
Basically, we run
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7
And when auto-unlocking fails, we can enter the passphrase to continue, then run
sudo systemd-cryptenroll
It lists all enrolled secrets like:
SLOT TYPE
0 password
1 tpm2
Then we wipe the now-invalid TPM slot:
sudo systemd-cryptenroll --wipe-slot=1 <partition>
In this case, the partition must be explicitly specified. I’m unsure what that would be for KDE Linux.
Then re-enroll a new one:
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7
Arch wiki can be a good reference:
2 Likes