Been down the rabbit hole lately of UEFI Secure Boot issues, and decided to write an overview of how it works out-of-the-box in the excellent Debian-based Linux Mint LMDE 6.
Have mostly been researching this stuff as I was looking to replace GRUB entirely with systemd-boot on one of my systems. Will likely write a follow-up piece documenting that journey if I think it’d be interesting to some nerds out there.
Interesting. I guess this could be a method to allow actual full disk encryption? Unless there’s a way to have grub encrypted too?
What do you mean by that? TPM and Secure boot do not manage encryption, but rather authentication and key management aspects. You still need an unencrypted UEFI partition storing your EFI binaries. This partition is always readable by an attacker, however any changes to binaries will make booting fail. Also no secrets should be stored here.
While secure boot and encryption aren’t directly related: yes, you can encrypt everything but the EFI partition. That include the boot partition, if you have such a partition in the first place.
Secure boot + FDE should be safe if you use your own secure boot keys to sign your own bootloader (unless your motherboard vendor is shit and allows “BIOS password recovery” like the BIOS in my PC). The EFI partition doesn’t need encryption, because the UEFI firmware will validate the bootloader, and the bootloader will validate its configuration, making it impossible to do an evil maid attack.
If you allow Microsoft’s standard keys, someone can just put an outdated, exploitable signed Grub bootloader on your disk that leaks the keys or messes with initramfs. That’s why custom keys are important. It’s practically impossible to defend against this while still allowing arbitrary boot disks.
You can configure the bootloader to unlock the disk with a password, with a key stored on the TPM, or both. Just a password is what most people probably use, the TPM solution is useful if you want encryption without the hassle (like default Bitlocker does), and the combination will make it impossible to decrypt a cloned drive even if the attacker knows the password.
This can be a problem if you ever need to recover your OS. You can clear out your secure boot keys if you have the password to your UEFI configuration, but if you forget it, you’ll be stuck booting only disks you’ve signed. Forgetting your password and losing your signing keys means that you can’t boot anything. Some UEFI firmware allows a forced reset that will clear out all settings and all TPM secrets. If you’ve used a TPM for security purposes, these firmwares will effectively make your encrypted data inaccessible after a reset, which is exactly what you want most likely.
For further recovery methods, you can have multiple keys on your encrypted LUKS volume. For example, you could store a key file on a USB drive in a safe somewhere that you can use to decrypt your disk even if you forget your password. This allows for data recovery when a TPM encrypted disk is taken out of a broken laptop, for example.
I have a full disk encryption setup with Grub, but I believe alternative bootloaders can do it too (and even better). It wasn’t that hard to set up, all I did was set up a LUKS partition next to the boot partition, put LVM inside that to do multiple virtual partitions easily, and then configure fstab and crypttab.