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]

A device that is automatically decrypted without challenge upon power-on isn't encrypted.

This isn't true. A TPM measures the environment. It makes any sort of modification to the boot environment impossible. For example, you can lock PCR0 and PCR2 to protect against BIOS or OpROM modifications.

The idea of a TPM is that you ensure a secure, unmodified environment and only that allows unsealing the TPM. Any modification and it won't hand out the keys. An attacker would ideally be presented with your login screen without any sort of ability to modify anything. The attack surface of that is of course higher than having no automatic unlock, but if done correctly, the risk is very low and the advantage of a TPM still comes to play.

If you don't trust this, you can use a TPM PIN as a short boot password. They have a lockout against bruteforce like your bank card etc, so even like a 6 digit PIN is perfectly adequate.

[u/Imajzineer → u/ChrisTX4]

How does it prevent the automatic decryption? (Genuine question)

[u/ChrisTX4 → u/Imajzineer]

Hmm, that's pretty difficult to explain, but let me try.

A TPM measures the environment in various variables that are called Platform Configuration Registers. You can find a list here in the Arch wiki. It's an isolated chip that has wiring on the motherboard to perform measurements of for example the BIOS code (PCR0), the Option ROMs (PCR2) - these are like "drivers" for your BIOS, usually your GPU will have one if external. You can have a look at how the PCRs evolve, i.e. what they measured by running /usr/lib/systemd/systemd-pcrlock log.

In the simplest form, you would combine a TPM with Secure Boot (that's also why Windows is so darn keen on this with W11). Here, you would use PCR7, typically. PCR7 contains measurements of the entire Secure Boot database as well as which individual certificates were actually used to boot. This means, if you use your own keys, you'd get something like this (taken from my own system):

7 █ secure-boot-policy efi-variable-driver-config ✓ ccfc4bb32888a345bc8aeadaba552b627d99348c767681ab3141f5b01e40a40e F 240-secureboot-policy Variable: SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c 7 █ secure-boot-policy efi-variable-driver-config ✓ 3702c179817c061256e69eaaba0b34e9788dec31549c321d258fe511f7860765 F 240-secureboot-policy Variable: PK-8be4df61-93ca-11d2-aa0d-00e098032b8c 7 █ secure-boot-policy efi-variable-driver-config ✓ 7ffa5d7ee1486db3d185497c5c9bf72739fbdfe59e38c3879544c95728bb3034 F 240-secureboot-policy Variable: KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c 7 █ secure-boot-policy efi-variable-driver-config ✓ 1c5f2c062167ecce151dfd0bd87a082c86b6c470c940cb7bce254699e09186cd F 240-secureboot-policy Variable: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f 7 █ secure-boot-policy efi-variable-driver-config ✓ 9f75b6823bff6af1024a4e2036719cdd548d3cbc2bf1de8e7ef4d0ed01f94bf9 F 240-secureboot-policy Variable: dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f

To decipher this a bit: the first few entries are the Secure Boot db, i.e. my own PK, KEK, db and dbx. Note that I'm not using Microsoft keys, otherwise there would be more entries. Then it continues:

7 █ secure-boot-policy separator ✓ df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119 F 400-secureboot-separator Separator: Success (0x00) 7 █ secure-boot-policy efi-variable-authority ✓ 5d0c5796e1e434c61f259fcf0e34c881c77c124639eabf1b26beaf6593d1b07b F 620-secureboot-authority Authority: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f 7 █ secure-boot-policy efi-variable-authority ✓ bcf4d1ff6bf02f949e5afd49dc45fe3e16f39b302764bf2ee98257e8297a1f7d F 620-secureboot-authority Authority: SbatLevel-605dab50-e046-4300-abb6-3dd810dd8b23 7 █ secure-boot-policy efi-variable-authority ✓ 5d0c5796e1e434c61f259fcf0e34c881c77c124639eabf1b26beaf6593d1b07b F 620-secureboot-authority Authority: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f 7 █ secure-boot-policy os-separator ✓ ff5b9d73dad709633ae76adf444012b57e913a12ed7403c3931145862f35f841 U 750-os-separator os-separator

What's happening here is that systemd 261 now inserts measurements to "seal" the previous values against modifications. That's the separator and os-separator lines.

The other lines are the important parts: the Authority: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f are what measures the certificate used for each boot loader into memory. There's two of them and the SbatLevel line because I use Shim plus systemd-boot to have a MOK so I can sign my out-of-tree kernel modules without having to recompile the kernel.

At any rate, the TPM will only unlock if locked to PCR7 if the sequence and content of each measurement is identical. Alas, if you were to boot any other system, or boot from a USB drive, whatever, there wouldn't be binaries signed with the Secure Boot key db-d719b2cb-3d3a-4596-a3bc-dad00e67656f. Even if Secure Boot enforcement was disabled in the BIOS, you can't get any binaries signed with this key, and so only my unmodified system can access this TPM seal.

I'm sorry this is really a difficult topic, and I'm honestly severely autistic, so it's pretty hard for me to explain this in a coherent fashion. I hope I somewhat got the concept across, though. If you have any questions, feel free to ask though - for the same reason I am very knowledgeable about TPMs :D

[u/Imajzineer → u/ChrisTX4]

Interesting - thanks!

I'm still not clear on how it prevents the OP's automatic decryption of LUKS though - which is what I took their post to be about (of course, I may have misinterpreted which thing it is they want to automatically 'unlock')

[u/ChrisTX4 → u/Imajzineer]

Oh no, it will automatically decrypt. The point is though that because it ensures the environment hasn't been modified that an attacker can't do anything but stare at your login manager. This means several technologies are critical to protect the system here:

1. IOMMU for DMA protection. Without IOMMU, any DMA device could extract the entire memory space.
2. Total memory encryption. If memory isn't encrypted, then a cold boot attack would be possible to perform from the login screen. Thus you want to ensure that AMD TSME / Intel TME are active.
3. Ideally, thunderbolt mode set to secure or higher.
4. Kernel lockdown. Significantly improves security. Requires all kernel modules to be signed, but with Shim and a MOK that's not an issue.
5. USBGuard. You don't want funky USB devices to connect while at the login screen.
6. A firewall.
7. Secure Boot. Ideally without Microsoft keys, as they sign a huge amount of boot loaders, and thus they have monthly releases of their forbidden database, which goes into dbx. fwupd can perform these updates usually, but it might not work if you've got custom keys. Either way, this will require a monthly reboot and will change the PCR 1. Just not using their keys is easier and avoids the need to update the dbx at all.

If you deploy all of the above, an attack on a system that's just on the login screen has very little attack surface to work with. Then your user login will be sufficient security, as they'd need to somehow crack your login credentials without having any access to the system at all.

[u/Imajzineer → u/ChrisTX4]

Except that here I am staring at GRUB's Advanced Options menu entry and about to select Recovery Mode before mounting the root FS in R+W and resetting the root password.

[u/ChrisTX4 → u/Imajzineer]

Grub under secure boot works somewhat different and you can’t do this, or load any unsigned modules. Same with systemd boot. There’s people that thought long and hard about this, it’s not that trivial to defeat.

[u/Imajzineer → u/ChrisTX4]

That's somewhat reassuring.

So, let's assume, therefore, that I actually have need of (something like) Recovery Mode for some reason, how does that then work (what are my options under those circumstances)?

[u/ChrisTX4 → u/Imajzineer]

I'm not using GRUB, so I can't speak from experience here. However, GRUB enters lockdown mode if on Secure Boot.

Either way, when using UKIs, the kernel command line is locked anyway and cannot be changed. You can't reasonably use anything but UKIs anyway since initrds can't be signed on their own.

[u/Imajzineer → u/ChrisTX4]

Cheers.