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

Poettering: Brave new trusted boot world

Posted Nov 1, 2022 22:07 UTC (Tue) by luto (subscriber, #39314)
Parent article: Poettering: Brave new trusted boot world

I find the disk encryption part to be disappointing. The goals state:

> Provide a fully measured execution path from firmware to userspace, no exceptions

But this seems quite weak in practice. Assuming the firmware isn’t itself malicious or exploitable, the firmware will (if I read the spec right) measure the boot loader (which is the UKI itself!) into PCR 4 and the SecureBoot policy into PCR 7. And the UKI’s stub will measure the UKI into PCR 11. Then unlocking is like this:

> Input to the TPM part of the unlocking process are the TPM’s internal SRK, the current TPM PCR 11 values, the public key used during enrollment, a signature that matches both these PCR values and the public key, and the encrypted DEK. – Output is the plaintext (“unsealed”) DEK.

But there seems to be a hole here — if the system can be convinced to simply load a malicious UEFI application that doesn’t speak this “Brave New … Protocol”, it will get PCR11 set to zero and can spoof the entire process. PCR 4 won’t match and, if the attacker is running their attack by turning off SecureBoot or changing the keys, PCR 7 won’t match, but PCR 11 will, and unlocking will succeed.

It seems to me that providing a *useful* measured path requires firmware to measure whatever non-firmware component it hands off control to, but I’m not convinced that’s possible in a robust way here.

to post comments

Poettering: Brave new trusted boot world

Posted Nov 2, 2022 9:39 UTC (Wed) by farnz (subscriber, #17727) [Link] (16 responses)

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 - if the firmware and boot menus are bug-free and locked down to only load approved applications from the system, then this is not possible. It also protects against the case where I am able to take the M.2 SSD or equivalent out of your machine and image it.

For typical users, I think this is the right trade-off; my encrypted partition will automatically unlock as long as I'm booting on my hardware, but won't if you move the M.2 stick to another machine. The presence of PCR 4 and PCR 7 allows a user with deeper security requirements to lock things down further, by tying more deeply to this machine's configuration, but that carries a risk of being locked out when a legitimate change happens.

Poettering: Brave new trusted boot world

Posted Nov 2, 2022 16:51 UTC (Wed) by luto (subscriber, #39314) [Link] (5 responses)

> Your attack scenario depends on convincing the system to load a malicious application - if the firmware and boot menus are bug-free and locked down to only load approved applications from the system, then this is not possible.

This essentially means using a custom Secure Boot configuration, right? And setting a firmware password so an attacker can’t simply turn off or reset Secure Boot.

UEFI could have done so much better in this regard. In theory DRTM / Secure Launch / TXT could do a better job here.

Poettering: Brave new trusted boot world

Posted Nov 2, 2022 17:33 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

It doesn't require a custom Secure Boot setup, but it does require a firmware password (at least on my laptop) to stop you just turning Secure Boot off. On my setup, if there's a firmware password, then there are only two ways to boot something other than the default option:

Enter the firmware password.
Log into the running system as root (or equivalent unconstrained superuser), and change the BootNext UEFI variable.

Both of these need credentials - but if I have system owner credentials, it's game over already.

Poettering: Brave new trusted boot world

Posted Nov 2, 2022 17:44 UTC (Wed) by luto (subscriber, #39314) [Link] (3 responses)

With a standard Secure Boot configuration, can't an attacker simply boot any signed (via Microsoft keys or anything transitively signed or approved) OS that doesn't use PCR 11?

In general, the entire Secure Boot ecosystem seems to be set up for one of three use cases:

1. Only Windows. Useless here.

2. Only Windows, something that Microsoft considers benign, or whatever a physically present user wants to run. Fine as long as the attacker isn't a physically present user for this purpose and nothing that Microsoft considers benign leaves PCR 11 set to zero.

3. Custom configuration. Fine.

Poettering: Brave new trusted boot world

Posted Nov 2, 2022 18:31 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

On all the Secure Boot devices I've owned, if there is a firmware password set, then the only way to change the boot option is to enter the firmware password - otherwise, the device will only boot the single entry it's been configured to boot (the Linux OS on the SSD in the case of my current laptop).

In the default (PCR 11, no firmware password) configuration described by Poettering, the promise you get from Secure Boot is simple: if I image your device, I cannot decrypt your system. I can still boot another OS on your system and tamper with it that way, but if you upgrade your SSD, the old SSD is not usable by an attacker as a source of information. This is a useful property in its own right - it means that if my SSD fails, I can replace it without being worried about information leaks from the SSD (e.g. someone taking it to a lab and extracting data from the NAND directly), and yet I don't have to deal with boot passwords at all.

If I set a firmware password, I now get much more security - I can boot my trusted OS cleanly, but an attacker with physical access cannot tamper with my boot sequence. This is also easy to explain to end users - "set a firmware password if you're worried about attackers tampering with your device - then it can boot normally, but it can't be tampered with". Further, I could set my device up this way for a child, and keep the firmware password and root access away from them; they can then use my trusted OS, but they can't replace the OS or tamper with the system, even though they have physical access.

If I'm a special case, I can custom-configure the whole thing, and avoid whatever threat I care about.

Poettering: Brave new trusted boot world

Posted Nov 6, 2022 3:10 UTC (Sun) by nybble41 (subscriber, #55106) [Link] (1 responses)

> On all the Secure Boot devices I've owned, if there is a firmware password set, then the only way to change the boot option is to enter the firmware password - otherwise, the device will only boot the single entry it's been configured to boot (the Linux OS on the SSD in the case of my current laptop).

But does it identify "the single entry it's been configured to boot" in a secure way, such as a hash of the boot image or its signing key? If not, one could still swap out the boot device for another one with the "same" entry (same identification), but controlled by the attacker. If that ultimately results in a system with PCR 11 not initialized (zero) then the attacker could feed in the expected measurements after booting their own OS and obtain the keys to unlock the encrypted storage.

Poettering: Brave new trusted boot world

Posted Nov 6, 2022 9:01 UTC (Sun) by farnz (subscriber, #17727) [Link]

The ones I've owned rely on physical security - you can't set a default boot device that's not inside the laptop chassis, and if intrusion detection triggers, which is supposed to happen in any case where you have access to the boot devices, you must enter the firmware password to boot. If you choose the onboard NIC as a boot device, then you need the firmware password after UEFI has downloaded an image, but before it starts the executed code (this appears to be done this way so that you can set netboot first, then on-board SSD, and as long as you don't connect to the provisioning network, it boots without a password). An attacker would therefore need the firmware password to carry out the attack you describe.

Poettering: Brave new trusted boot world

Posted Sep 29, 2023 18:09 UTC (Fri) by kreijack (guest, #43513) [Link] (9 responses)

> 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...

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