Poettering: Brave new trusted boot world [LWN.net]

Poettering: Brave new trusted boot world

Posted Sep 29, 2023 18:09 UTC (Fri) by kreijack (guest, #43513)
In reply to: Poettering: Brave new trusted boot world by farnz
Parent article: Poettering: Brave new trusted boot world

> I think you misread the spec slightly, and it's therefore fixable if you need tighter security. First, the difference
> between PCR 11 and PCR 4 is that PCR 4 contains not just the UKI, but also any boot menus (systemd-boot or rEFIt,
> for example) that you use, while PCR 11 is just the UKI.

> Your attack scenario depends on convincing the system to load a malicious application ...

Not really a "malicious" application. It is enough any OS where you have root access.. like a standard windows installation with Administrative privileges.

Then after the boot, you have to:
- extract from the UKI file the "expected PCR 11", the public key used during enrollment, a signature that matches both these PCR values and the public key, and the encrypted DEK
- set the PCR11 value to the "expected PCR 11" value
-pass to the TPM the encrypted DEK and the signature above

Would this be enough to get the un-crypted disk key ?

Obviously I am missing something, otherwise it would be very trivial to circumvent...

to post comments

Poettering: Brave new trusted boot world

Posted Sep 29, 2023 20:51 UTC (Fri) by dtlin (subscriber, #36537) [Link] (8 responses)

Setting a PCR directly is not possible, only updating <tt>PCR = hash(PCR, new input)</tt> or rebooting the machine to reset all values.

Poettering: Brave new trusted boot world

Posted Sep 30, 2023 17:32 UTC (Sat) by kreijack (guest, #43513) [Link] (7 responses)

My understanding is: that the PCR11 starts from 0 and it seems to be updated only by sb-boot. So starting a system without sd-boot is enough to allow an user to set it to an arbitrary value.

$ sudo tpm2_pcrread | egrep 11:
11: 0x0000000000000000000000000000000000000000
11: 0x0000000000000000000000000000000000000000000000000000000000000000
11: 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
11: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Poettering: Brave new trusted boot world

Posted Oct 2, 2023 14:12 UTC (Mon) by kreijack (guest, #43513) [Link]

> My understanding is: that the PCR11 starts from 0 and it seems to be updated only by sb-boot. So starting a system > without sd-boot is enough to allow an user to set it to an arbitrary value.

Sorry I wrote sd-boot, but I meant sd-stub

> $ sudo tpm2_pcrread | egrep 11:
> 11: 0x0000000000000000000000000000000000000000
> 11: 0x0000000000000000000000000000000000000000000000000000000000000000
> 11: 0x0000000000000000000000000000000000000[...]
> 11: 0x000000000000000000000000000000000000000000[...]

Poettering: Brave new trusted boot world

Posted Oct 3, 2023 0:31 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (5 responses)

So you seal to PCR 7 as well, and then never sign anything that doesn't extend PCR 11 (or do so with a different key such that the PCR 7 measurement changes)

Poettering: Brave new trusted boot world

Posted Oct 3, 2023 17:22 UTC (Tue) by kreijack (guest, #43513) [Link] (4 responses)

> So you seal to PCR 7 as well, and then never sign anything that doesn't extend PCR 11 (or do so with a different key > such that the PCR 7 measurement changes).

Sorry but I still don't understand (likely due to my ignorance).

The Poettering idea was to seal the disk key with the signature of the *expected* PCR11, so in case of an update of the UKI file, it would be enough to recompute the PCR11, sign it and store this signature in the UKI file itself.

Doing so, my understanding is that it is enough to boot a stock redhat (i.e. secureboot compatible), set the PCR11 to the *expected* value and pass the signature contained in the UKI file to unseal the disk key.

If I seal the disk key with a an additional PCR register which measures all the chain of the uefi-fw+shim+bootloader+uki, I still have problem to update the UKI (I can, but I am able to compute the new PCRs set only after a reboot). So the purpose of the PCR11 signature of UKI file is unclear.

If I seal the disk key with an additional PCR register which measures all the chain of the uefi-fw+shim+bootloader (*not* the uki), I don't have the problem to update the UKI, but still I opened the door to boot a generic distro "secureboot" compatible.

The fact that even windows (with bitlocker) says sometime that after an upgrade in the next boot the disk will be not crypted, let me suppose that the problem of updating the bootloader when the disk-key is sealed in the TPM is without a simple solution.

Poettering: Brave new trusted boot world

Posted Oct 3, 2023 17:32 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (3 responses)

PCR 7 only contains data that can be pre-calculated, and it includes the cert that Shim uses to verify the payload. So a distro that includes this support can have different PCR 7 measurements to one that doesn't, and can assert that it does the PCR 11 measurement.

Poettering: Brave new trusted boot world

Posted Oct 3, 2023 19:13 UTC (Tue) by kreijack (guest, #43513) [Link] (2 responses)

> PCR 7 only contains data that can be pre-calculated, and it includes the cert that Shim uses to verify the payload. So a distro that includes this support can have different PCR 7 measurements to one that doesn't, and can assert that it does the PCR 11 measurement.

You should remove all the keys (even the Microsoft key ) from the uefi-bios except the one that allow your shim to work, otherwise anything that was signed with (e.g.) Microsoft key may break the protection...

From the points above it seems to me that the PCR11 signature of an UKI file, is secure only in a strongly constrained environment, i.e. where it is possible to be sure that all 'bootloader chain' is secure. This is not impossible, but it is less practical than seemed in the beginning.

Poettering: Brave new trusted boot world

Posted Oct 3, 2023 20:08 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (1 responses)

> You should remove all the keys (even the Microsoft key ) from the uefi-bios except the one that allow your shim to work, otherwise anything that was signed with (e.g.) Microsoft key may break the protection...

How? If anything is signed with a different cert chain (even if it's a shim signed with the Microsoft key, it will then measure the vendor cert before booting the second stage) then the PCR 7 measurement will be different and you won't be able to unseal the material.

> From the points above it seems to me that the PCR11 signature of an UKI file, is secure only in a strongly constrained environment, i.e. where it is possible to be sure that all 'bootloader chain' is secure.

The alternative is to seal to PCRs 0-5+11. This doesn't rely on any sort of secure boot chain but does increase fragility over firmware updates or some security-relevant configuration changes.

Poettering: Brave new trusted boot world

Posted Oct 4, 2023 17:38 UTC (Wed) by kreijack (guest, #43513) [Link]

> > You should remove all the keys (even the Microsoft key ) from the uefi-bios except the one that allow your shim to work, otherwise anything that was signed with (e.g.) Microsoft key may break the protection...

> How? If anything is signed with a different cert chain (even if it's a shim signed with the Microsoft key, it will then measure the vendor cert before booting the second stage) then the PCR 7 measurement will be different and you won't be able to unseal the material.

Ok, I missed the fact that PCR7 measures the PK/KEK/db and *the "specific certificates used to validate each boot application"* [1].

But this means that the boot application have to be signed by a non public 'private key'; the same is true for the UKI.
Otherwise the user need to deploy a host-specific certificate to sign the uki.

> > From the points above it seems to me that the PCR11 signature of an UKI file, is secure only in a strongly constrained environment, i.e. where it is possible to be sure that all 'bootloader chain' is secure.

> The alternative is to seal to PCRs 0-5+11. This doesn't rely on any sort of secure boot chain but does increase fragility over firmware updates or some security-relevant configuration changes.

[1] from https://wiki.archlinux.org/title/Trusted_Platform_Module