Encrypted /boot partition - when/how to seal keyfile?

[sandersaares]

I am thinking of using TrustedGRUB2 in a situation where the /boot partition is encrypted, with only TG2 itself being on a clear partition. I understand from the readme that the use of a sealed keyfile is supported for bootloader-stage decryption of /boot. So far so good.

However, in order to actually take the proper measurements and seal the keyfile, I would have to do so within the TG2 boot process itself, wouldn't I? Since doing it later would mean that PCR 10 will be in a different state due to loading the /boot contents.

Furthermore, I wonder how this interacts with PCR 11 and PCR 12.

Perhaps you can clarify what the proper process of using TG2 in such a scenario might be - I take it from the extension of the cryptomount command that this is an intended use case?

[morbitzer]

I'm currently working on the same setup. I am trying to use tpm-sealdata-raw while i'm in the OS to seal my keyfile.
I have an unencrypted disk for /boot/grub, the rest is encrypted.

When sealing only to PCRs 0-9, my boot process works without a problem. Here's what I have so far for the other PCRs:

PCR 10 contains thing like the linux-kernel and initird, which you will only be able to access after mounting the encrypted partition with the sealed file. Therefore, sealing to PCR 10 would not make sense in this case. (Also, the PCR is still at all 0s at this stage)

Sealing to PCR 12 works - The LUKS header does not change, so this can be done

PCR 11 is a bit tricky. In my setup, after the cryptomount command is executed, there are still multiple measurements that influence PCR 11, which I don't want, because I want it to be the same once my OS is booted up as during the cryptomount command is executed.
So the first thing I did was adapting my grub.cfg, removing the search command and executing the set root command before the cryptomount command. Therefore, the only to commands left after the cryptomount (which would cause PCR 11 to be in a different state once we are in the OS than at the point of time where we try to decrypt the LUKS partition) are linux and initrd:

        load_video
        insmod gzio
        if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
        insmod part_msdos
        insmod cryptodisk
        insmod luks
        insmod gcry_rijndael
        insmod gcry_rijndael
        insmod gcry_sha1
        insmod lvm
        insmod ext2
        set root='lvmid/<ID>'
        cryptomount -u <ID> -k (hd0,msdos1)/sealed.bin -s
        echo    'Loading Linux 3.16.0-4-amd64 ...'
        linux   /boot/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/debian--vg-root ro  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-3.16.0-4-amd64

Further, I patched TrustedGRUB2 so that the linux and initrd command are not measured into PCR 11. (Since the linux-kernel and the initrd itself are anyway measured into PCR10, I don't see a problem with that)
This way, the last time I can see PCR 11 being changed when I switch on debugging is after the cryptomount command. However, once the OS is up, I still see a different value in PCR 11 than what I saw directly after the cryptomount command. I don't really understand this, because the cryptomount should be the last command measured into PCR 11. So, if somebody has a pointer for me what could cause this further change of PCR 11, please let me know.

The last PCR is 13, which includes "Parts of GRUB2 that are loaded from disk like GRUB2-modules". Here, a lot of things are also measured after the cryptomount command, so you won't be able to seal your file to the value PCR 13 has once the OS is booted up.

One more thing that I still need to figure out: Even if I manage to seal my file to PCR 11, which measures all the commands and arguments to scripts, what would prevent an attacker from booting up the system, edit the boot entry, remove the last four lines (which would in my case be echo, linux, echo, initrd), and then press f10 so that all other commands are executed in the right order and cryptomount successfully mounts the encrypted disk? In this case, the attacker would be able to enter a GRUB command shell and have access to the unencrypted partition...

[dunkpa]

It's been quite a while since the earlier posts, but this issue doesn't seem to be dealt with anywhere, so I think it's worth discussing..

I'm working with a modified version of the CoreOS GRUB package (TPM 2.0 support on EFI systems). I've modified it so it can read PCR locked data from nvram, which is analogous to the TrustedGRUB2 sealed file support.

The way I deal with the problem you've been discussing is as follows;

• I embed a grub configuration file into the core grub image (see grub-mkimage). The job of the commands in this configuration file is to invoke cryptomount. The commands in the configuration file are measured as part of the core.img measurement process (boot.S in TrustedGRUB2 I think, and by earlier EFI things on my system). When grub executes the commands from this embedded configuration, it doesn't measure them - no need to as it's part of core.img, tho you would want to ensure nothing in here is conditional.
• Seal my passphrase using PCR's 0-9, and again (passphrase stored in 2 nvram locations) using PCR's 0-13 (not including 10 - used for kernel and initrd - these are stored on the encrypted partition, so I see no need, and it makes managing updates easier).
• initramfs also retrieves the passphrase from the TPM, using the location sealed with PCRs 0-13 (I've not implemented this part yet. You can look at https://github.com/fox-it/linux-luks-tpm-boot for some inspiration).
• Set a password on grub, to prevent any interactive use, because as mentioned in the previous post, interactive users have access to the encrypted partition, which is mounted. (again, I've not yet implemented this part, but according to the grub2 documentation, it's possible).

[securitykernel]

Unfortunately, this project is deprecated and no longer maintained. I will be closing this issue.