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

To all those saying SecureBoot brings absolutely nothing security wise...

Why is a project like, say, Debian, even bothering signing kernels:

https://wiki.debian.org/SecureBoot

What's their rationale for supporting SecureBoot?

It's what the customer has come to expect.

Doesn't this enable them to be installed on systems with Secureboot enabled without having the user muck around in the BIOS? Smart for VMs?

I can see your point but, geez, that's pretty depressing if it's the only reason it's supported!

As a sidenote for having installed Debian with SecureBoot on on several systems, I'd say I still had to muck around quite some in the BIOS/UEFI. Latest one I scratched my hair for a bit was an AMD 3700X on an Asrock mobo where I somehow had to turn "CSM" (Compatibility Support Module) off otherwise Debian would stubbornly start the non-UEFI (and hence no SecureBoot) installer. On my Asus / AMD 7700X things were a bit easier but I still had to toggle some SecureBoot setting (from "custom" to "default" or the contrary, don't remember). All this to say: it's still not totally streamlined and users still need to muck around anyway.

That wiki page buries what might be the rationale in the "What is UEFI Secure Boot?" section:

> Other Linux distros (Red Hat, Fedora, SUSE, Ubuntu, etc.) have had SB working for a while, but Debian was slow in getting this working. This meant that on many new computer systems, users had to first disable SB to be able to install and use Debian. The methods for doing this vary massively from one system to another, making this potentially quite difficult for users.

> Starting with Debian version 10 ("Buster"), Debian included working UEFI Secure Boot to make things easier.

Sounds plausible, but I don't know how seriously to take it, when that wiki page also includes very generous and regurgitated-sounding bits like:

> UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.

I normally look to Debian to be relatively savvy about detecting and pushing back against questionable corporate maneuvers, but it's not perfectly on top of everything that goes on.

There's another reason but it's even worse: Some certifications require that secure boot is enabled.

Anyone saying secureboot "brings absolutely nothing" clearly doesn't understand how secure boot works (or is just arguing in bad faith). Secure boot has issues (see key revocation issue & vulnerable UEFI program used by malware to install bootkit) but it does address a real security issue.

People might not like who holds the commonly preinstalled keys (Microsoft and motherboard OEMs) but even then you can add your own keys and sign your own images if you want (there was just a post yesterday about doing this for raspberry pis),

The raspberry pi example is an even worse implementation of secure boot using an absurd write only once scheme for the keys.

That's just creating more ewaste, nobody can ever use that device normally again and it cannot be resold.

Can you provide examples of such pushback from Debian? I always viewed them as a typically understaffed, underfunded volunteer effort without the resources to push back against funded technology. I'm ready to be wrong on this, if you can help me out!

I don't think its absurd at all. It isn't required in anyway (opt in), lets you use your own keys (no preinstalled microsoft or other bigcorp keys), and isn't possible for someone to modify what keys you installed.

Of course if you lose your keys you can't sign anything else and that would make it basically ewaste, but most things end up as waste when you take actions that are reckless and can't be reversed (which is what losing the keys would be). Plus tech tends to ends up as ewaste after less than a decade anyways. Like sure you could still be using an AMD steamroller CPU but realistically after 10 years you'd be better off using a cheaper more power efficient chip anyways.

> Plus tech tends to ends up as ewaste after less than a decade anyways. Like sure you could still be using an AMD steamroller CPU but realistically after 10 years you'd be better off using a cheaper more power efficient chip anyways.

I'm not sure what you are trying to argue but people routinely buy used computers on market place. Rasperry pies with locked keys are essentially paper weights once the owner doesn't want to use them anymore.

And realistically, the biggest ewaste generators are especially smartphones nowadays which are too locked to be reused well.

For example, Debian putting their foot down on closed drivers and (for a long time) downloadable device firmware blobs.

I've also seen Debian very responsive when I pointed out that a particular package was phoning home before consent given.

And one of the notable annoying parts of the Debian installer forever is when you think it's started a long unattended period of installing packages, but it soon pauses to ask you for opt-in to some package usage telemetry (so at least they're asking before doing it).

I definitely get the understaffed vibe from Debian, but I'm also still pleasantly surprised how well they execute in general.

Contrast with a certain commercial derivative -- which snoops, installs closed software without the user understanding that's that they're doing, pushes an IMHO horrible different package manager, is sloppier about regressions in security updates, etc.

I wish I had time to volunteer right now to scratch some of the itches I have with Debian, and very much appreciate all the work that others have done and are doing on it.

> I'm not sure what you are trying to argue but people routinely buy used computers on market place. Rasperry pies with locked keys are essentially paper weights once the owner doesn't want to use them anymore.

Why can't the owner who wants to sell their locked Pi give the buyer the key?

Debian keeps track of all remaining privacy issues in all packages (i.e. such issues which have not yet been corrected or patched by the Debian package maintainer):

https://wiki.debian.org/PrivacyIssues

> People might not like who holds the commonly preinstalled keys (Microsoft and motherboard OEMs) but even then you can add your own keys and sign your own images if you want (there was just a post yesterday about doing this for raspberry pis),

I like SecureBoot, and I like that I can select my keys to sign things the UEFI will run, but I don't like that I can't replace the UEFI itself since it's protected by bootguard.

Now if I can edit the UEFI, that's a gamechanger: I could have my signed UEFI payloads check the UEFI firmware has the parts I want (or don't want) and refuse to keep booting if it doesn't

I’m confused, why would a kernel need to be signed if you don’t actually care about secureboot? If you have a signed GRUB, then UEFI with SB will run it, after which you can use GRUB to launch any kernel, signed or not, right?

Because presumably they are not going to use one key per raspberry they own? Who would complicate their setup like that?