Bottomley: Adventures in Microsoft UEFI Signing [LWN.net]

James Bottomley's UEFI bootloader signing experience is worth a read...still a few glitches in the system. "Once the account is created, you still can’t upload UEFI binaries for signature without first signing a paper contract. The agreements are pretty onerous, include a ton of excluded licences (including all GPL ones for drivers, but not bootloaders). The most onerous part is that the agreements seem to reach beyond the actual UEFI objects you sign. The Linux Foundation lawyers concluded it is mostly harmless to the LF because we don’t ship any products, but it could be nasty for other companies."

to post comments

still a few glitches in the system...

Posted Nov 20, 2012 15:06 UTC (Tue) by mjw (subscriber, #16740) [Link] (31 responses)

Wow, that is not just a "few glitches" that sounds like the whole system is broken...

You don’t just upload a UEFI binary and have it signed. First of all you have to wrap the binary in a Microsoft Cabinet file. [...] the file upload requires silverlight. Unfortunately, moonlight doesn’t seem to cut it [...] so time to fire up windows 7 under kvm. When you get to this stage, you also have to certify that the binary “to be signed must not be licensed under GPLv3 or similar open source licenses”. [...] The response: “The error code thrown by our signing process is that your file is not a valid Win32 application? Is it valid Win32 application?”. Reply: obviously not, it’s a valid UEFI 64 bit binary. No further response …

still a few glitches in the system...

Posted Nov 20, 2012 15:22 UTC (Tue) by davidescott (guest, #58580) [Link] (21 responses)

I actually didn't see the point of a large part of Bottomley's post. MSFT certainly doesn't care if this is hard to do using open-source tools. We might think some of the steps are obnoxious but that doesn't mean it doesn't work or is in some way immoral.

When someone asks for help with proprietary program X its common to suggest open source implementation Y. Does that make us bad people trying to subvert the proprietary software movement, or does it just reflect the fact that we understand and have experience with the open-source version. Clearly MSFT has tested their process with a particular set of windows tools, and it evidently almost worked.

The only real mistakes in their process are
a) The initial error when the process was checked to see if it was a win32 binary
b) signing the key with a generic MSFT key that they don't want you to actually use.
Complaining about Cabinet files and Silverlight seems a bit off to me.

still a few glitches in the system...

Posted Nov 20, 2012 15:50 UTC (Tue) by drag (guest, #31333) [Link] (2 responses)

>MSFT certainly doesn't care if this is hard to do using open-source tools. We might think some of the steps are obnoxious but that doesn't mean it doesn't work or is in some way immoral.

Well the IP system is immoral and if Microsoft is trying to exploit it to limit competitors then that is immoral also.

But it also can be just pure incompetence and/or apathy.

still a few glitches in the system...

Posted Nov 20, 2012 16:03 UTC (Tue) by davidescott (guest, #58580) [Link] (1 responses)

What does IP have to do with this?

still a few glitches in the system...

Posted Nov 23, 2012 0:58 UTC (Fri) by Rudd-O (guest, #61155) [Link]

Microsoft only has the power it has over you -- the power to deny your use of your stuff -- because of Intellectual Poverty.

Intellectual Poverty -- the belief that it is okay for a monopolist to punish you for your use of your property in ways he disapproves -- is obviously immoral.

If this topic interests you, Stephan Kinsella has written Against Intellectual Property, a treatise that covers this topic at length.

Have a nice day.

still a few glitches in the system...

Posted Nov 20, 2012 18:58 UTC (Tue) by jcm (subscriber, #18262) [Link] (12 responses)

Indeed. Microsoft uses various file formats and packaging that we don't. If Linux distribution X were doing UEFI bootloader signing, I expect they might seek the "convenience" of wrapping things up in a deb, or an rpm, or similar container. And the similar "convenience" of using "this set of tools that everyone knows every Linux person has and always uses...". So, similarly, that they use CABs and so on isn't surprising. In fact, in the Microsoft world, that sounds pretty clean and neat as part of their process. They probably have decades worth of tools internally that can handle those.

I'm also not surprised they disallow the GPLv3. That revision of the GPL was specifically crafted to make cryptographic signing of bits difficult - the so called "anti-tivolization" provisions, and so on. I think GPLv3 is an overreach and goes too far, but that's my personal opinion. However, many corporations have also been very reluctant to even touch it (see the re-implementations of GPLv3 stuff in the embedded space as an example of where this is going over time). I expect someone in Microsoft legal blanketly put the brakes on going anywhere near it out of a fear of what might happen.

still a few glitches in the system...

Posted Nov 20, 2012 19:51 UTC (Tue) by davidescott (guest, #58580) [Link]

Its strange how MSFT Legal approached this. They require that you certify that the binary you will upload “to be signed must not be licensed under GPLv3 or similar open source licenses,” which Bottomley notes is a bit unclear, and the contract you must agree to prohibits a bunch of different licenses by name.

One could create a license, the MSFT_LEGAL_CORNER_CASE license, that is in no way "open-source" simply because it requires nothing with respect to source code, but that is anti-tivo in requiring that anyone distributing a signed copy of the binary it must distribute the private key.

It wouldn't be on any of their blacklists because its completely made-up, presumably it must be covered under some generic clause in the contract, and that neither uploading a file now downloading a binary will oblige MSFT... But why make such a fuss over the GPLv3 and disallowed licenses when you can't cover the actual item of concern with those clauses.

A much simpler solution is obvious. Don't return the binary. You upload the binary, they send you back a signature with a placeholder (all 00 or EE) for your binary, you insert the binary into the signature packet. No need for them to dirty their hands by distributing your binary.

still a few glitches in the system...

Posted Nov 20, 2012 21:35 UTC (Tue) by Wol (subscriber, #4433) [Link] (10 responses)

But why bother wrapping it up AT ALL!

That's the point - it requires MS technologies for something that shouldn't need it. It's a bit like telling Ford owners that they can only buy their petrol from pumps on a Ford garage forecourt.

Why should I have to wrap the binary up, when they're simply going to unwrap it at the other end? If it was going by Royal Mail, I can see the point of wrapping it up in paper, but on the Intar-tubes?

Cheers,
Wol

still a few glitches in the system...

Posted Nov 20, 2012 22:17 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Probably for the same reason that people use cut&pasted code snippets from random sites to generate self-signed certs.

I.e. nobody freaking understands how this certificate crap works. Microsoft has a set of tools for cryptographic operations that hasn't changed much since late 90-s and probably only a few engineers in Microsoft know how they work. Coincidentally, these tools prefer CABs for file containers.

still a few glitches in the system...

Posted Nov 20, 2012 22:39 UTC (Tue) by khim (subscriber, #9252) [Link]

I think you are overthinking things here. Microsoft uses CAB because CAB was designed for such use from the beginning.

The only question which can ever be asked is: why have not Microsoft switched to some other non-proprietary format and if you frame the question like this then the answer is self-obvious, isn't it?

still a few glitches in the system...

Posted Nov 20, 2012 22:35 UTC (Tue) by khim (subscriber, #9252) [Link] (7 responses)

But why bother wrapping it up AT ALL!

My mother always said: don't ask stupid question which you can answer yourself. I can not believe I see this stupidity here on LWN.

Why should I have to wrap the binary up, when they're simply going to unwrap it at the other end?

Think. That's kind of obvious.

P.S. And no, "wrapping is done to annoy Linux users" is wrong answer. Wrapping is actuslly essential to the process. Why it's done using Microsoft's tools and not, for example, PGP is obvious.

A motherly request

Posted Nov 20, 2012 22:40 UTC (Tue) by corbet (editor, #1) [Link] (6 responses)

Can I play your mother for just a moment and suggest that calling people stupid is not the politest way to behave? We don't need to throw in that kind of gratuitous insult, really. Please?

A motherly request

Posted Nov 20, 2012 22:50 UTC (Tue) by khim (subscriber, #9252) [Link]

Can I play your mother for just a moment and suggest that calling people stupid is not the politest way to behave? We don't need to throw in that kind of gratuitous insult, really. Please?

Sure. Just please explain where exactly I've implied that anyone here is stupid. Someone is obviously hasty, sure, but I'm pretty sure anyone (including Wol) can answer this question if they'll spend few minutes thinking - which makes the question stupid, isn't it?

A motherly request

Posted Nov 21, 2012 1:35 UTC (Wed) by davidescott (guest, #58580) [Link] (4 responses)

I have to say Wol's suggestion that it not be wrapped is if not stupid, intentionally obtuse. It comes from the:
We hate Microsoft. Everything they do is evil. Unencumbered by the thought process.

Wol's was given a very good example of how we do things differently from the Windows and ignored it entirely. Are we to blame CYGWIN because it ships the underlying packages via RPM.

Its always going to be wrapped. Some wrappers are just more complex than others. Whether it be CAB or ASCII armored, its wrapped. The only way it would not be wrapped if it were a (void *) pointer of a specified length, which isn't a practical way of transmitting the data to different hosts.

Microsoft chose the wrapper that made sense for them. I don't see how we can criticize them on that basis.

A motherly request

Posted Nov 21, 2012 8:46 UTC (Wed) by jcm (subscriber, #18262) [Link]

Indeed. There was a time when I thought it was just hilarious to misquote biblical verse implying Gates was some satanic figure, or just to hate on Microsoft on principle. I was a lot younger, and far more naive then. Now, I realize they're just a corporation in a business community that we are also part of, and we disagree in how one should go about implement, distribute, and market software, and so on. But we should just accept that for a moment and ask ourselves if - from their viewpoint - any of this process is odd. To me, wrapping things in a CAB and so on sounds a lot like me saying "oh, just wrap it in an RPM..." and then having someone who prefers ipkg files complaining I am doing something strange.

A motherly request

Posted Nov 21, 2012 9:38 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Well, actually, as I understood it we have a bootloader. A SINGLE file, which gets loaded and cryptographically checked. And if it's correct, it gets executed.

Seeing as we are asking for a single file to be signed, why can't we upload that file as itself, rather than an archive? It's all very well saying "MS should use an open packaging standard", but why - if it's just one file - does it need to be packaged at all?

If I'm sending stuff to my friends, it's usually single files, and I don't bother packing them.

Cheers,
Wol

A motherly request

Posted Nov 21, 2012 12:23 UTC (Wed) by khim (subscriber, #9252) [Link]

Seeing as we are asking for a single file to be signed, why can't we upload that file as itself, rather than an archive? It's all very well saying "MS should use an open packaging standard", but why - if it's just one file - does it need to be packaged at all?

Sure, if you want to create service which just signs random sequences of bytes without any verification then this approach will work just fine - but this will kind of defeat the purpose: anyone will be able to sign any kind of junk in this case thus you can just rip out the whole signature checking process: it'll be more honest, surely.

But of course Microsoft is not crazy: it's process includes two parts (actually more, but it should include at least two). You've forgotten about vital, yet extremely important part of the whole process: first we must make sure the file presented have actually come from trusted source (from someone who've gotten the certificate and signed some papers) and then we need to sign it with Microsoft's key.

Well, actually, as I understood it we have a bootloader. A SINGLE file, which gets loaded and cryptographically checked. And if it's correct, it gets executed.

That's for the second part of the process. First part (which checks the credentials) is generic - as it should be (you should not invent new cryptoprocedures unless you must). And for that part signed CAB makes perfect sense: this is format designed for just such a use, after all!

If I'm sending stuff to my friends, it's usually single files, and I don't bother packing them.

And how exactly do you prevent forgery in this case? You use PGP, S/MIME, or some other container format which add the signature, isn't it? Well, Microsoft prefers signed CAB for obvious reason.

A motherly request

Posted Nov 21, 2012 12:36 UTC (Wed) by khim (subscriber, #9252) [Link]

Wol's was given a very good example of how we do things differently from the Windows and ignored it entirely. Are we to blame CYGWIN because it ships the underlying packages via RPM.

Just a nit (since I've fought with Cygwin's distribution system half a year ago and was kind of surprised by it's baroquiness). Cygwin does not use RPM. It uses tar.bz2 files plus an external file with MD5 (yes, MD5 - in this day and age!) hashes for said files and only that one file is signed.

still a few glitches in the system...

Posted Nov 21, 2012 3:12 UTC (Wed) by Trelane (guest, #56877) [Link]

>When someone asks for help with proprietary program X its common to suggest open source implementation Y.

When we become the gatekeepers to 95% of all desktop and laptops, this comparison will be aot. Until then, it ignores very salient details.

still a few glitches in the system...

Posted Nov 21, 2012 9:20 UTC (Wed) by jejb (subscriber, #6654) [Link]

> I actually didn't see the point of a large part of Bottomley's post.

The point is mainly to outline for others who have to get UEFI code signed what the process is likely to be and where you can get the necessary tools from.

> Complaining about Cabinet files and Silverlight seems a bit off to me.

I don't believe I was actually complaining, merely documenting the process.

If I have a complaint, it's just the length of time this is taking.

still a few glitches in the system...

Posted Nov 21, 2012 9:21 UTC (Wed) by mjw (subscriber, #16740) [Link] (2 responses)

You might be more a half-full person, and I might be more a half-empty person. But I wouldn't call the (vaguely worded) legal restrictions on using licenses for binaries distributed by third parties, signing stuff with the wrong key, only supporting signing Win32 executables, "annoyances" of using an uncommon wrapper format, requiring Silverlight (plus basically Windows7) instead of a simple http upload, etc. "it evidently almost worked" :) Sure, not all steps are fatal showstoppers, but it looks to me that half of them could certainly be counted as such.

I haven't used Windows in the last decade (but I have dealt with certificates and signing, and it certainly doesn't have to be so painful), so I might be "out of touch" with how windows binary certification works. But I thought this whole process was for simple UEFI bootloaders to enable common hardware in the default setup and has basically nothing to do with Windows. Organizations that already use Windows anyway are probably not the target of this process.

still a few glitches in the system...

Posted Nov 21, 2012 12:50 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

I haven't used Windows in the last decade (but I have dealt with certificates and signing, and it certainly doesn't have to be so painful), so I might be "out of touch" with how windows binary certification works. But I thought this whole process was for simple UEFI bootloaders to enable common hardware in the default setup and has basically nothing to do with Windows. Organizations that already use Windows anyway are probably not the target of this process.

As far as Microsoft is concerned Windows is the golden standard everyone should use (preferably the latest version). They certainly don't plan to support anyone who does not use it. And if you'll stick with Microsoft's tools the process is as streamlined as they come (well, except for Silverlight at the end - but that's just a minor gimmick and not a problem if you are using Windows7 anyway).

still a few glitches in the system...

Posted Nov 22, 2012 21:51 UTC (Thu) by Jan_Zerebecki (guest, #70319) [Link]

> if you'll stick with Microsoft's tools the process is as streamlined as they come

Assuming you didn't try it yourself and had a different experience than James Bottomley this is just plain wrong. According to http://blog.hansenpartnership.com/adventures-in-microsoft... he tried the Microsoft tools.

He also says: "Additionally, although I think openssl has a rather confusing interface, the Microsoft tools make it look slick by comparison."

still a few glitches in the system...

Posted Nov 20, 2012 15:34 UTC (Tue) by davidescott (guest, #58580) [Link] (8 responses)

The bigger issue in my mind is:
YTF is this process automated? Is Microsoft anticipating such a great need for custom bootloader's that they can't just have someone check a email mailbox? Who is going to want to have their own signed bootloaders and be willing to pay the fee to get one... A half-dozen linux distributors, a few dozen government agencies, X many development teams of major corporations. Everyone else is just going to disable secure boot. Unless X is really large this seems like a relatively minor part-time task for a single developer.

Putting the whole process on some website just opens you up to attacks on that website. An enterprising cracker might find a way to inject code into the signing program website and freely generate as many shims with new keys as he wants and permanently topple the house of cards that is secure boot.

The cynic in me says MSFT recognizes that there is money to be made in selling secure boot keys to malware authors and then revoking them a month later, and they want to automate the process so they can maximize the revenue stream.

still a few glitches in the system...

Posted Nov 20, 2012 16:08 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

It's the same process as is used for signing UEFI drivers, and there's likely to be a lot of those.

still a few glitches in the system...

Posted Nov 20, 2012 16:11 UTC (Tue) by cesarb (subscriber, #6266) [Link] (1 responses)

> The bigger issue in my mind is: YTF is this process automated?

Probably because they do not want anyone to have direct access to the machine with the private signing key. With an automated process, they can enforce that all signatures pass through a well-defined process, with built-in audit trails in case anything goes wrong, and that nothing is signed with that key outside of that process.

Of course, that is the theory. As shown by the number of glitches this time, it seems that the process is not that well-defined in practice.

still a few glitches in the system...

Posted Nov 20, 2012 16:26 UTC (Tue) by davidescott (guest, #58580) [Link]

Matt Garrett already gave the answer. But I wasn't suggesting that the process not be automated internally, but rather that the automation shouldn't be connected to an outward facing website.

still a few glitches in the system...

Posted Nov 20, 2012 22:08 UTC (Tue) by redden0t8 (guest, #72783) [Link] (3 responses)

Forget enterprising crackers... too bad he didn't distribute the Microsoft-signed shim before he was told not too. Once it's out on the internet, you can't ever take it back.

Once keys start getting revoked, I bet an irrevocable shim will look pretty sweet.

still a few glitches in the system...

Posted Nov 20, 2012 22:42 UTC (Tue) by khim (subscriber, #9252) [Link] (2 responses)

Forget enterprising crackers... too bad he didn't distribute the Microsoft-signed shim before he was told not too. Once it's out on the internet, you can't ever take it back.

You can't ever take the [private] key back, but you most certainly can blacklist the shim thus is the end such childish behavior will just lead to troubles.

still a few glitches in the system...

Posted Nov 21, 2012 15:12 UTC (Wed) by redden0t8 (guest, #72783) [Link] (1 responses)

You can't blacklist the shim, only the key it was signed with. If Microsoft accidentally signed it with (one of) their own key(s), blacklisting it would have the side-effect of also disabling everything else signed with the same key.

What else has Microsoft signed with that key? Could they practically push out updates for those components re-signed with a different key, so as to ensure that blacklisting the original key wouldn't break any Windows 8 systems? What would happen to an end-user's system if the blacklist got updated before those components?

I suppose you could see it as "childish", but I see it as not covering for Microsoft's mistakes on their behalf. They made this mess, I don't feel bad for them if they have to deal with it.

still a few glitches in the system...

Posted Nov 21, 2012 15:26 UTC (Wed) by jake (editor, #205) [Link]

> You can't blacklist the shim, only the key it was signed with.

As I understand it, you *can* blacklist the shim. The blacklist can either have keys *or* hashes. Put the hash of the shim in the blacklist and MS can still use their key, but that shim no longer boots.

jake

still a few glitches in the system...

Posted Nov 21, 2012 9:28 UTC (Wed) by jejb (subscriber, #6654) [Link]

> The cynic in me says MSFT recognizes that there is money to be made in selling secure boot keys to malware authors and then revoking them a month later, and they want to automate the process so they can maximize the revenue stream.

Microsoft doesn't get any money from this. The cash we paid was to Verisign (now Symantec) so that they would certify to Microsoft that we were who we said we were and give us a Verisign certified certificate to prove it.

This is the Linux Foundation's actual certificate subject and issuer:

Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Code Signing 2010 CA
Subject: C=US, ST=California, L=San Francisco, O=The Linux Foundation, OU=Digital ID Class 3 - Microsoft Software Validation v2, CN=The Linux Foundation

Bottomley: Adventures in Microsoft UEFI Signing

Posted Nov 21, 2012 13:44 UTC (Wed) by krake (guest, #55996) [Link] (7 responses)

IMHO the question is. "Why doesn't the Linux Foundation provide a signing service that all FOSS operating systems could then use?"

And all LF (corporate) members could of course use it as well

Bottomley: Adventures in Microsoft UEFI Signing

Posted Nov 21, 2012 14:15 UTC (Wed) by corbet (editor, #1) [Link] (6 responses)

This question has certainly been asked before, and the Linux Foundation has considered it, but it's not really a practical alternative. Providing this kind of service is quite difficult and very expensive; it's not something that the Linux Foundation has the resources to do.

Bottomley: Adventures in Microsoft UEFI Signing

Posted Nov 21, 2012 14:24 UTC (Wed) by krake (guest, #55996) [Link] (5 responses)

Right, I assumed as much as that they had considered it.

But I was expecting something more along the lines of will take some time, after all the benefit of having a non-Microsoft "root" key widely available should outweight a lot of costs.

Bottomley: Adventures in Microsoft UEFI Signing

Posted Nov 21, 2012 16:09 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (1 responses)

How would you ensure that this key was widely deployed?

Bottomley: Adventures in Microsoft UEFI Signing

Posted Nov 21, 2012 18:17 UTC (Wed) by krake (guest, #55996) [Link]

I don't think there is any such thing as ensuring that something would happen.

I assumed that the Linuxfoundation, being a interest group of several very large hardware and software vendors, would be able to help board vendors to see that continued business with its members is in fact in their best interest.

Of course those who only sell components for consumer PC white boxes and WinRT devices would not care, but that should leave plenty of them who do.

Bottomley: Adventures in Microsoft UEFI Signing

Posted Nov 21, 2012 16:59 UTC (Wed) by jejb (subscriber, #6654) [Link] (2 responses)

In the interests of full disclosure, the Linux Foundation investigated what it would take to be a Linux CA for UEFI. The figures that came back are pretty staggering.

Firstly the current CA operators want payments in the order of millions of US Dollars to set up a CA and not charge the end user (otherwise they want to charge fairly ridiculous fees). It should also be noted that the UEFI forum tried to go this route as well (they originally planned to sponsor a neutral CA) but gave up when they found out about the kind of money required.

Secondly, the OEMs and ODMs who make the motherboard wanted anyone supplying a UEFI KEK or db entry to post a bond, also in the six to seven figure range, to indemnify them against anything going wrong with the LF Key.

Given there are quite a few OEM and ODMs, that's more cash than the current Linux Foundation core operating budget and therefore not something that could be realistically undertaken.

Bottomley: Adventures in Microsoft UEFI Signing

Posted Nov 21, 2012 17:50 UTC (Wed) by krake (guest, #55996) [Link] (1 responses)

Oh boy!

Seems like the UEFI people didn't a lot of thinking as in considering consequence of their decisions.

Not that it is very surprising given that they are a industry group, but still.

It is quite telling that the Linux Foundation didn't do more publicity on this outrage.

It inevitably leads to the conclusion that all the big corporate members have legal contracts with Microsoft that protects their Linux related business in some way that make relying on Microsoft for access to phyical machines unproblematic.

Anyone else, including smaller corporate members like Red Hat, are left to the wolves.

Good to keep in mind next time some LF,IBM, Intel, etc press release claims that any of those companies is "heavly supporting" Linux.

Bottomley: Adventures in Microsoft UEFI Signing

Posted Nov 22, 2012 0:28 UTC (Thu) by vonbrand (guest, #4458) [Link]

Never, ever forget Hanlon's razor.

Bottomley: Adventures in Microsoft UEFI Signing

Posted Nov 22, 2012 2:04 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

The point will be that the market has to punish vendors who play along with the silly Redmond game.
MSFT might be able to wrest a few government contracts for this idea, but the private sector absolutely has to hoist a middle finger at it.