mjg59 | Supporting UEFI secure boot on Linux: the details

(Update January 18th 2012 - you probably want to read this for details on why the technical details described below are not the difficult bit of the problem)

An obvious question is why Linux doesn't support UEFI secure booting. Let's ignore the issues of key distribution and the GPL and all of those things, and instead just focus on what would be required. There's two components - the signed binary and the authenticated variables.

The UEFI 2.3.1 spec describes the modification to the binary format required to produce a signed binary. It's not especially difficult - you add an extra entry to the image directory, generate a hash of the entire binary other than the checksum, the certificate directory entry and the signatures themselves, encrypt that hash with your key and embed the encrypted hash in the binary. The problem has been that there was a disagreement between Microsoft and Intel over whether this signature was supposed to include the PKCS header or not, and until earlier this week the only widely available developer firmware (Intel's) was incompatible with the only widely available signed OS (Microsoft's). There's further hilarity in that the specification lists six supported hash algorithms, but the implementations will only accept two. So pretty normal, really. Developing towards a poorly defined target is a pain. Now that there's more clarity we'll probably have a signing tool before too long.

Authenticated variables are the other part of the puzzle. If a variable requires authentication, the operating system's attempt to write it will fail unless the new data is appropriately signed. The key databases (white and blacklists) are examples of authenticated variables. The signing actually takes place in userspace, and the handoff between the kernel and firmware is identical for both this case and the unauthenticated case. The only problem in Linux's support here is that our EFI variable support was written to a pre-1.0 version of the EFI specification which stated that variables had a maximum size of 1024 bytes, and this limitation ended up exposed to userspace. So all we really need to do there is add a new interface to let arbitrary sized variables be written.

Summary: We don't really support secure boot right now, but that's ok because you can't buy any hardware that supports it yet. Adding support is probably about a week's worth of effort at most.

Flat | Top-Level Comments Only

Not inherently. It's actually reasonably hard to do - inserting new keys requires that those keys themselves be signed by the private half of one of the keys in the KEK database, so you'd need to give your key to someone who *does* have an entry there (either the OEM or Microsoft), have them sign it and then pass that into the variable database.

Any possibility of creating a web of trust system for this?

Didn't the videos from the Microsoft conference say that they would use a certificate CA (or more than one probably) just like with SSL and current code signing for drivers and software ?

Right now, Microsoft and the OEMs are the CAs, and there's no requirement that a system carry any root certificates other than Microsoft's. Imagine if your browser only came with Godaddy's certificate and you couldn't install any others.

Do they intend for a manufacturer of, let's say a NIC and it's driver to talk to have their driver signed by Microsoft or by the OEM ?

That's not entirely clear yet, but it has to be signed by someone who has a key in the machine's database.

I will be suprised if Microsoft does not offer a way to digitally sign drivers for secure boot. They already have the WHQL program.

And seeing as Microsoft keys are the only ones guaranteed to be present on all systems, third parties will likely prefer this over any program set up by individual or coalition of OEMs.

...and of course, the mere existence of such a counter-signed key makes that key just as powerful, and valuable, as the root keys (if a piece of malware was somehow signed by that new key, it would just have to carry the signed key-update-request around with it).

If you want the issuance of countersigned keys to be viable in practice, there needs to be provision in the spec for the signed key update request to be limited in scope - say to a particular motherboard serial number and/or date range.

This seems odd. Why can't I as the owner just manually enter the keys that I trust (equivalent to my ssh authorized keys file)?

Because the spec doesn't allow you to do that once there's a KEK installed.

You apparently miss the point of the original post. The poster wants to know why they don't make it so that you can decide what keys are trusted and add your own. Saying that they don't make it that way doesn't answer the question. I suspect that there is no good answer to the question. In fact, your answer suggests there is no good answer, since it is the equivalent of the standard, "because I said so," reply (or in this case, because the UEFI implementers said so).

Because the Media Conglomerates who want this, along with Microsoft and the hardware manufacturers *don't trust you*.

The whole purpose of secure boot is to stop you from copying DRM'd media. It doesn't work because the pirates won't use secure boot, and then everybody uses those pirate copies even on systems with secure boot, IE it's completely f***ing useless, except that Linux won't always run with it and Microsoft of course likes that.

If we're not careful politicians will make this insidious crap a mandatory requirement.

No. Secure boot is not a DRM mechanism. It has no concept of attestation. It is vitally important that nobody permit the idea that it's a DRM mechanism to prevail.

Supporting UEFI secure boot on Linux: the details

Re: Is there any way for the end-user to load their own keys?

Re: Is there any way for the end-user to load their own keys?

Re: Is there any way for the end-user to load their own keys?

Re: Is there any way for the end-user to load their own keys?

Re: Is there any way for the end-user to load their own keys?

Re: Is there any way for the end-user to load their own keys?

Re: Is there any way for the end-user to load their own keys?

Re: Is there any way for the end-user to load their own keys?

why is this needed?

Re: why is this needed?

Re: why is this needed?

Re: why is this needed?

Re: why is this needed?