[HowTo] Using Secure Boot and TPM2 to unlock LUKS partition on boot

Contributions Tutorials
,
21

I’m half tempted to do this crazy thing… But it’s a little bit spicy for me…

23

Thank you a lot for this how-to, i would like to give it a try, but my setup is quite different usually, i use btrfs filesystem and i like a lot to have my snapshot entries in grub menu.
Anyway, i guess this can be done manually after “snapshoting” / in order to have those entries in systemd-boot menu.

I have one question regarding systemd-boot i almost know nothing about, i am in the Arch wiki page and it says :
https://wiki.archlinux.org/title/Systemd-boot#Adding_loaders

Note that entries in esp can only use files (e.g. kernels, initramfs, images, etc.) in esp…

So if i understand well, what’s usually inside /boot folder (no separate boot partition) with grub : initramfs, wmlinuz and ucode.img are now located inside /efi (which is the mountpoint of your esp ?

Are those files encrypted or not ? I mean, i was thinking that an esp partition could not be encrypted, is it true ?

Thank you for your help

24

This is one of the reasons I went with systemd-boot. In this specific case, it doesn’t need any files traditionally placed into /boot, it just loads 1 signed file containing kernel, initrd, cmdline, etc from $esp partition, and because it is signed and checked during boot, there’s no need in encrypting such file.

And no: files that usually located in /boot, stay in /boot. They are just a source of generated unified kernel images and exist there as package manager and system hooks expect them to be. But generated files used to actually boot the system are placed into /efi so systemd-boot or UEFI could see them.

Files in /efi are not encrypted, files on all other partitions - are. It is a good idea to keep only config files and signed UKIs on $esp. Maybe some trusted signed tools like memtest, too. And tools that manage Secure Boot keys like KeyTool.efi should not be there - no matter if signed with your key or not. It should be deleted from $esp every time you finish working with it. EFI shell, probably, too.

Actually you can stick to grub if you really want that but anyway you’ll have to use something other than /boot to store your signed kernel images, because otherwise (without encrypting /boot) you’ll have extra hassle of securing files in that location too - and it’s just what I immediately thought of, more considerations to come if you think it over.

1 Like
25

I guess this is a good point, at the price of a “plaintext” file (e.g. the UKI). I am wondering how secure is it if we compare with another setup such as :

  1. Secure Boot enabled
  2. GRUB
  3. Boot partition LUKSv1 encrypted (as GRUB does not yet support LUKSv2, building the patched version fail since the last grub upstream commit)
  4. / partition LUKSv2 encrypted

https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

The other option would be, instead of 3. & 4. : only one / partition and /boot as regular folder, but it should be LUKSv1 encrypted.

I do not like having a /boot partition but this is surely better to have one LUKSv2 / partition and one LUKSv1 /boot partition, rather than only one LUKSv1 / partition.

Sure the UKI can’t be tampered because it’s signed, but isn’t it a potential weakness of your setup ?

Nonetheless, what is interesting in your setup is :

  1. no boot partition
  2. no GRUB

Did you activate fast boot in your UEFI as i know this is possible with systemd-boot ? How fast/slow is it to boot on your computer ? With grub option, I am afraid it would be too much slow for unlocking, i do not have any idea though.

26

The whole point of signing and using TPM is to check the validity of kernel images. If it boots without LUKS password prompt, then it is safe. If there’s a password prompt, it indicates that the image has been modified and the user becomes aware of something wrong going on.