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

Poettering: Brave new trusted boot world

Posted Nov 2, 2022 17:44 UTC (Wed) by luto (subscriber, #39314)
In reply to: Poettering: Brave new trusted boot world by farnz
Parent article: Poettering: Brave new trusted boot world

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.

to post comments

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.