Intel OEM Private Key Leak: A Blow to UEFI Secure Boot Security

The pervasiveness of secure boot has genuinely made things difficult for attackers - there'd have been no reason for the Black Lotus bootkit to jump through all the hoops it did if it weren't for secure boot, and the implementation of UEFI secure boot does make it possible to remediate in a way that wouldn't be the case without it.

But secure boot at the OS level (in the PC world, at least) is basically guaranteed to give users the ability to enable or disable it, change the policy to something that uses their own keys, and ensure that the system runs the software they want. When applied to firmware, that's not the case - if Boot Guard (or AMD's equivalent, Platform Secure Boot) is enabled, you don't get to replace your firmware with code you control. There's still a threat here (we've seen firmware-level attacks for pre-Boot Guard systems), but the question is whether the security benefit is worth the loss of freedom. I wrote about this a while back (https://mjg59.dreamwidth.org/58424.html) but I lean towards thinking that in most cases the defaults are bad, and if users want to lock themselves into only using vendor firmware that's something that users should be able to opt into.

Would it be sensible to make that choice using a good old fashioned jumper? For example, when the jumper is connected to pins 1 and 2, the firmware must be signed by a list of vendor-controlled keys; when the jumper is connected to pins 2 and 3, the firmware must be signed by a list of user-managed keys. That way, I can choose what kind of freedom makes sense for me. Most people value the freedom of not having to worry about firmware, while others value the freedom to use or create their own firmware.

No, because the entire point of this is to be resilient against physical attack - anyone re-flashing your firmware already has your case open and can just move the jumper while they're at it.

However, all UEFI implementations (on PCs at least) allow anybody with physical access to disable Secure Boot, the classic method of just popping the button battery remaining valid to these days.

So, isn't this firmware protection with BootGuard only really meant to prevent rootkits from getting persistence?

PS: thanks for all the blog posts you share on the matter! they are really golden

Kind of true? If you disable secure boot at least on Windows BitLocker will no longer unlock your disk at boot, and so you'll need to enter the recovery code at least once.