Encrypted boot partition on secure UEFI firmware like Heads?

Dasharo is a great project, porting Coreboot with advanced security features to new intel Hardware.

Using such a system, the integrity can be checked using a Yubikey/Nitrokey. You could also use things like TPM encryption and more.

But encrypting the boot partition is “not possible” normally, which sounds for me like a pretty substantial security hole.

As you have read in the article there is a problem of ESP and /boot/ partition being separate. You can encrypt /boot e.g. with LUKS and possibly have GRUB decrypt it, but you can’t encrypt ESP. Also you would have to separate the ESP from /boot/ due to nested mount point. There is no support for ESP encryption.

Michal wrote.

Especially on immutable Distros such a setup could not be done manually. What do you think of this, would it have drawbacks seperating those partitions, or could it be a general fix to allow encrypting the /boot ?

The ESP partition is accessed during boot before being mounted.
The /boot partition is accessed during boot before being mounted and must be accessible to grub and the bios to load the kernel and initramfs.

Both must be accessible to bios and grub before luks is loaded which is why they are not encrypted.

There is no advantage to encrypting data that is publicly available.
The security is gained by checking that the data has not been tampered with.
And the signature checking does that.

1 Like

I agree with that 100%.

Additionally I note that the data of concern would not be accessible until the root partition has been mounted since it would not be unlocked (unencrypted) until the system has proceeded further into the boot.

/boot and /boot/efi only contain the files needed to boot the OS and do not contain any sensitive data.

There are lots of IDS (intrusion detection system) software packages (tripwire is one of those) that can be used to ensure that none of those files have been compromised as well.

If the system is not accessible to anyone local to the machine then security of the boot process is of very little risk. If someone has direct local physical access to the system then security is never guaranteed anyway.

of course encryption would be to provide tampering protection. If there are other mechanisms this might me unnecessary.

In theory it could make sense though. for example the bootloader might be outdated (was a problem on Atomic desktop, not sure if fixed?) and that would mean an attacker could find that and use a specific hack to use that.

But that is theoretical. staying at “if a local attacker has access, its too late anyways” is not a good solution. Then we wouldnt need LUKS.