Linux and Secure Boot certificate expiration

This is yet another why I do not encrypt.

Secure boot has nothing to do with encryption. It is verifying crytographic signatures. The bootloader is signed, not encrypted.

Secure boot doesn't encrypt, secure boot only signs.

There's some link between secure boot and encryption.

If you don't do secure boot, you need to secure your boot chain in other ways, to prevent attacker from modifying your software to log entered passphrase.

Secure boot allows to build a verifiable chain of software (UEFI -> Bootloader -> Kernel -> Initrd) which will protect against any modification, so you can be sure that your key presses are not being logged by the malicious software. That said, commonly used Linux distros have some problems protecting initrd, but that's issue of those distros.

Another link is TPM. I set up my system in a way to keep encryption key in TPM and release it only when secure boot is enabled. This allows to decrypt root automatically, without entering passphrase and my configuration only allows to boot UKI kernel signed with my key. It trades security with convenience, of course (because now attacker, who stolen my computer, only has to break through gdm or perform other ways of attacks like extracting RAM sticks), but for me it's acceptable.

But it's very much a part of boot verification to unlock a TPM with your encryption keys on it.

I think it’s primarily to avoid someone just putting your SSD into any other computer and access all files. Anything more is probably not a realistic threat to most people.

That's like saying there is some link between putting locks on your doors and setting up booby traps because if you don't lock your doors then you need to set up booby traps to prevent a thief from stealing your stuff. They're both trying to mitigate the same threat, but there is no connection between the 40 pounds of explosives I have wired to my front door and an intricate metal cylinder that can only be manipulated by another piece of metal in a specific shape.

Personally, I do both secure boot and encryption.

No, it’s like saying there is a link between putting locks on your door and making sure the lock can’t be replaced with one that takes someone else’s key, or worse one that copies the key that’s put into it. The threat models directly overlap.

You're conflating secure boot with measured/verified boot.

They don't work in tandem? I enable secureboot with sbctl(securebootctl) and enroll keys in a TPM using the same tool as far as I can remember.

Or is this just some technical detail that in practice is under the same tools and settings?

That's a good analogy to point out the weakness behind relying on encryption without secure boot but without going into the mechanism behind "making sure the lock can’t be replaced" people might incorrectly think "they're both about setting up locks and therefore they are linked" whereas "making sure the lock can’t be replaced" involves securing the environment that the lock is placed in, like "Make sure your hinges are not exposed so the door cannot be taken off its hinges from the outside and replaced with a seemingly identical door."

By default, the secure boot status is part of the TPM registers that are used to unseal the encryption key for your drive. That's because if you disable secure boot, or reconfigure it with different keys, any bootloader could just replay measurements from a normal Linux system to the TPM and unlock your drive.

If you want, you can pick a different set of registers to use. The Arch wiki has a bunch of them: https://wiki.archlinux.org/title/Trusted_Platform_Module#Acc...

Calling systemd-cryptenroll with --tpm2-pcrs would allow you to manually pick a set of options. I believe Bitlocker uses 0, 2, 7, and 11 (11 being an OS specific register rather than a spec-defined one), which is why firmware updates often make you re-enter your Bitlocker key. Some people choose to only record the secure boot state, relying on the firmware to validate its own updates and config, which means you don't need your recovery key after firmware updates as long as the secure boot state remains the same.

Not taking secure boot state into account makes the entire setup rather easy to bypass, but you could do it to make your setup harder to break while still protecting against the "thief steals my SSD but not my laptop" scenario.

Secure Boot does nothing whatsoever to prevent that. Disk Encryption has got nothing to do with Secure Boot.

for most people that is an irrelevant threat model. people can steal my laptop, but if they don't know my passport they can't access my data. end of story. they would have to break into my laptop without stealing it to install any kind of tool that can read the password. how/when is that going to happen ever without you knowing it? you would have to be working on highly sensitive, and sought after stuff for someone to try that.

In addition to the great answer by jeroenhd, you also might have encrypted your secure boot signing keys with your TPM. This has the advantage that your signing keys can't be stolen so you know that your bootloader was signed on your specific physical machine. But this is not necessary, you can just store your signing keys on your SSD or anywhere/anyway you want.

Unless you're using a SED, your EFI system partition is unencrypted. It would be trivial to build a malicious copy of popular open source UEFI bootloaders (grub, refind, zfsbootmenu, etc), and a bootable USB stick that scans your EFI system partition, replacing your unencrypted bootloader with a malicious one. This attack could then be applied by relatively unskilled people in a couple minutes ("boot this flash drive, wait until the screen says "done", power it off"). I hope your laptop is never out of your possession for more than a couple of minutes! (For example, the TSA at the airport, geek squad or other repair centers, or classically an evil maid).