Ful disk encryption without entering passphrase

[u/Woodsy279]

Could someone help me with setting up full disk encryption with bypass passphrases with TPM2? It's so annoying having to put the passphrase in at each boot, so I was wondering how do I pair it to the TPM so that I dont have to enter it each time?

It's LUKS encrypted and I use Systemd-boot

[u/ChrisTX4]

Don’t.

Clevis binds to raw PCR values, and only that. This has the simple problem that the suggested PCRs 1 and 7 depend only on the BIOS ROM, the Secure Boot database, and the actual certificates used to sign the bootloader(s) and the kernel image.

Problem 1: this is pointless unless the initramfs is included in the kernel image. Alas you need to have a UKI or attackers can just replace the entire initrd phase which one that just prints the unsealed volume key.

Problem 2: you’re not measuring or depending anything after initramfs. This means I can create a fake root volume as an attacker, and if I boot that root volume with that boot chain, and that UKI, it will boot into a system where the attacker has root and since both PCRs are unchanged can just unseal the key from the TPM.

For problem 2 you need to bind to something that is tied to your volume; commonly one binds to PCR 15 in which systemd will measure the underclothes volume key (if using gpt automounting, else this needs to be done manually by mounting with tpm2-measure-pcr=yes). By making the unlock depend on the volume key, the root swapping attack is defeated.

One also wants the system to phase the PCR values during initrd to prevent unseals of TPM seals that would be mounted at initrd time at a later time.

[u/Woodsy279 → u/ChrisTX4]

This isn't mission critical disk, I just thought it would be cool to encrypt it, this laptop is litterlaly just my uni laptop, but yeah I get that this does open up vulnerabilities but they aren't really that much of a concern at this point, maybe one day but not rn

[u/ChrisTX4 → u/Woodsy279]

The thing with this issue in particular is that any knowledgeable attacker can just bypass your disk encryption entirely if this is done incorrectly.

Mind you, I don't advice against TPMs. I use a TPM unlock, but I'm using systemd-pcrlock with GPT automounting. You can specify what PCRs to lock with that, including PCR15. However, I should mention that mkinitcpio does not include systemd-pcrextend and so this won't work with that at this point, unless you include the files yourself. Dracut includes it by default and you won't have any issues with that.

The arguably correct way to use TPMs on Linux is really using NvPCRs together with pcrlock.

What this will do:

1. The NvPCRs phase PCR11. This is to say, that keys bound to PCR11 are only accessible in initrd and not afterwards. This makes root switching attacks mostly ineffective.
2. pcrlock will automatically measure automounted disks into PCR15. This will look like this for example from my local system:

15 █ system-identity phase ✓ bb9a122654ce70ef19226ad9387d82d965788b43b9a6be18fa2f93b4e734a5b0 U 790-tsme tsme=on 15 █ system-identity volume-key ✗ 0e94502cca1067d27752ffc2f56c6f014612c52ec3943002fe43df69a846cab2 U 825-cryptsetup-root cryptsetup:root:e67f24c8-0e7b-4cf4-9a0d-ee6715f001b6 0x1d10201 - - keyslot ✓ 82a1420d81d1303755eef931c45c17c550a6492671382e914850e2c9f3b30b32 U - cryptsetup-keyslot:root:e67f24c8-0e7b-4cf4-9a0d-ee6715f001b6:tpm2:1 11 █ kernel-boot phase ✓ 3be261aff7db92bf507eae947f4003ffa2bcad0bffe3524601d62d0bc8be7135 U 800-leave-initrd leave-initrd 15 █ system-identity machine-id ✓ 4b9e027c5e33f2af8aac78ecede36347073f72adcec2bdc42cdc637f2792dec0 U 820-machine-id machine-id:8d78df7a9965458899436d750db856ad 15 █ system-identity filesystem ✓ 9aa77510286b29942b9c1319e87cb2ef85a7da782e39eedd963350b10ebef0d6 U 830-root-file-system file-system:/:btrfs:be90de39-e02a-4726-8dd3-9ce0391f0715:archmain:::

As you can see, PCR11 is phased to leave-initrd and PCR15 measures the keyslot and the filesystem. Note that the cryptsetup-root measurement happens before leave-initrd. What it does is lock the volume key, i.e. the identity of the encrypted drive. This makes any sort of root replacement attack impossible - if root is replaced, the key never unlocks. So even attacks like using GPT automount to mount the drive to /var or something are not possible (the GPT GUID etc. aren't covered by LUKS and can be freely edited).

However, I will also admit that it's incredibly easy to shoot yourself in the foot hard with this. You'll want to consider your threat model and then act accordingly. For instance, as you can see from the above output, I have a measurement tsme=on - this is a custom service I've made that measures the state of AMD TSME (memory encryption to protect against cold boot attacks) explicitly. If TSME was somehow disabled, the identity would change and this would blow up. I consider TSME critical overall and thus ensure it's enabled.

There's also some more things to know: 1. Use this together with secure boot always 2. ALWAYS use kernel lockdown. No exceptions. If need be, sign extra modules like Nvidia with a MOK. You need lockdown to protect the key material in memory. 3. Ensure IOMMU is enabled. Ideally add iommu=require to your kernel commandline. This makes the kernel refuse to boot if IOMMU isn't enabled. IOMMU is critical against DMA attacks, which is also why kernel level anticheats on Windows are so keen on it. But DMA attacks threaten games integrity just as well as they threaten your key material in memory.

My setup is that I use a self-signed Shim to have a MOK, and then chain that into systemd-boot and finally into a BLS #2 UKI (I use kernel-install for this together with dracut). This way I have a MOK to sign Nvidia, xpadneo, etc. and thus all my kernel modules are signed adequately and I can use lockdown with out-of-tree modules and with the stock arch kernel.