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

There is no reason to use a manufacture key anyway, at least for SecureBoot.

Obviously it isn't in everyone's skillset, but if you have the means there is nothing preventing you from generating and using your own key.

Honestly it seems like a good basic security precaution, not only to prevent against leaks like this, but also to counteract any backdoors (although kind of a moot point with chipmakers).

Yesn't

1. some EFIs are broken in ways that make using private platform keys hard or impossible

2. there are PCIe cards which need option ROMs to be executed (most commonly that dedicated GPUs), this ROMs are not always but often signed by one of the Microsoft Keys and removing it from the trust db will prevent the ROMs from running and lead to all kinds of problems, e.g. not having any video and in turn not being able to undo to EFI setting/disable secure boot. You can make sure the specific ROMs are whitelisted, but then you need to be very very careful about e.g. graphics drivers updating the GPU firmware and similar. And putting the right data in the trust db isn't easy either.

Secure Boot keys are unrelated to the leaked key in question. The Boot Guard key is used to verify the firmware itself that the CPU executes on boot. What the firmware happens to do afterwards, say it's a UEFI firmware that implements Secure Boot, is irrelevant to Boot Guard.

Good points. I was subconsciously focusing on laptops when I made my comment.

Thank you for clarifying, realized that too late after commenting.

If your firmware and its UEFI modules were originally signed by these leaked signatures, what are you going to do? You can't just un-trust those.

In many BIOSes were you can apparently remove all keys and the firmware still loads its own builtin components, that's because the manufacturer has put a backdoor so that their own components can always be loaded irregardless of Secure Boot state. (Otherwise users would be able to brick their own machines). MSI, for example, does this. And guess what: with these leaked keys, now anyone can claim to be a "manufacturer's own component". Secure Boot is useless.

Is there a way to know if it is safe to enroll my own keys? I always wanted to, but always didn't do it, because I often read that it can make the system unbootable.

There are plenty of mobos that gladly brick themselves until you reset configuration. The most common way being Device Guard getting enabled and GPU not being initialized after that. I've not taken a look about manufacturers' own components and those defaults however.

The question is whether you have any mandatory UEFI drivers or not. If they're in the ESP you can just look there to check, but UEFI drivers can also be loaded from PCI cards or baked in the firmware itself.

If you're using a TPM for Secure Boot, you can use the commands in https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom to know for sure.

Thanks, I'm not seeing these lines in the eventlog, thats good. Are these the only things that could brick my laptop, or are there any other known "security features" that vendors implement?

mainly research/googling

Most option ROMs are signed by the same set of Microsoft keys, You can make sure to enroll this keys alongside your custom platform key (e.g. the tool sbctl can do so for you). While this does tend to work it has one drawback which is if someone has that key they can break your secure boot chain, i.e. it weakens the benefits custom platform keys give you.

Option ROMs signed by vendor keys are somewhat rare, but sometimes (parts of) firmware update tools are signed by vendor keys, in which case you can choose between not updating your firmware, disabling secure boot while doing so or hoping you can find the (pub)keys for the keys they used somewhere on the internet.

In the end you probably want to see if someone already tried it and had success.

option ROMs are not quote "security features" they are more like legacy x86 thing which if they get corrupted (e.g. modified by malware) would be a complete security nightmare of having malware in a way which can access most things and can't be detected at all (slightly oversimplified).

Because of this validating option ROMs is _very_ important to a point some would argue it's more important then validating that e.g. your Linux kernel has not been modified

Honestly option ROMs IMHO should not exist in the way they do (for security reasons), but they outdate secure boot by quite a bit and like many of this "old legacy features a lot of things depend on" are just really hard to get right of.

Through without question the design this ended up with has a terrible UX.

But most laptops with a reasonable EFI implementation and no dedicated graphics card do luckily not have option ROMs (through their firmware update tool might have something similar, but you can just not use it).

> If your firmware and its UEFI modules were originally signed by these leaked signatures, what are you going to do? You can't just un-trust those.

You are going to tweak them again, and check down the line (ex: grub) that they match the hash you've stored, say inside you secureboot, or in your TPM

This should get you MORE security: before, you had to accept whatever the board manufacturer though it was ok (ex: any WWAN or WLAN cared with just these Ids). Now you can add more checks (just this serial or mac address) and refuse to boot.

Someone could do the same, but if you verify at the next level (ex: grub, etc) that you tweaks are present, you can refuse to boot if they aren't.

Thanks for the clarification!