[dathinab]

Slightly unrelated:

I currently have a custom platform key, packet everything I need for booting into a single image (signed with the custom platform key) and everything else is in a fully encrypted partition (lvm2 on dmcrypt). "Decryption key" is inserted via keyboard on boot, which is not to everyone's liking but is what I want.

It's not really hard to setup (on arch Linux) and works like a charm. ;-)

Through the drawback is that the initRamFs is only protected by the signature/secure boot but not encrypted and combining it with some other boot related setup can be less straight forward then under a "boring" setup.

I.e. some of the thinks this project promises are already possible now, just not streamlined. Which is why it's nice to have such a project.

[thudson]

That was exactly my motivation: there are tons of guides for setting up UEFI SecureBoot platform keys, yubikey tokens, TPM disk encryption, dmverity, etc, but all of them seemed to involve "type hundreds of commands with no mistakes and hope that your system still boots afterwards". It felt to me that each program represented a low-level library function that needed to be linked into a high-level tool to handle the common cases for most users.

Regarding /boot being in the clear -- the initramfs and kernel shouldn't contain any secrets, so having them unencrypted isn't a big drawback. Signed is much more important so that an adversary with write access to the disk can't swap out the kernel.

One advantage to using the TPM for unsealing the disk encryption key is that it helps protect against attacks that re-write the firmware. If an adversary can reflash the platform key (via either a local SPI flash programmer or some code execution that gives them write access to the NVRAM region of the flash), then you can't tell that the PK has been changed and that the kernel to which you are inputting the password is no longer trustworthy. Since the secret is sealed with (among other things) the hash of the UEFI SecureBoot configuration, the TPM will not unseal it if the PK, KEK or db are changed.

If you want to take it to another level, TPM TOTP can be used to validate that the password dialog is even valid before you type in the password. I think we can integrate that fairly easily into the initramfs for the next version of safeboot.

[ohazi]

There's a way to encrypt the boot partition and have GRUB ask you for the boot partition key, but you're limited to LUKS1, and the decryption process is slow as molasses, since it's implemented inefficiency directly in the GRUB code, because the Kernel's faster code isn't loaded yet. It's also probably full of side channel leaks. Signing the kernel and ramdisk is probably the better option...

[jstanley]

What's your defence against an attacker with a few hours of physical access meddling with whatever comes before you typing the decryption key, such that you're actually typing your key into a program controlled by them, which then decrypts your filesystem image, inserts its own malicious code into some irrelevant kernel module, then boots the system as normal?

[andrewnicolalde]

What's the disadvantage of not encrypting your initramfs if it's protected by a signature?