A collection of information

Adventures in Microsoft UEFI Signing

As I explained in my previous post, we have the code for the Linux Foundation pre-bootloader in place. However, there was a delay while we got access to the Microsoft signing system.

The first thing you have to do is pay your $99 to Verisign (now Symantec) and get a verified by Verisign key. We did this for the Linux Foundation, and all they want to do is call head office to verify. The key comes back in a URL that installs it in your browser, but the standard Linux SSL tools can be used to extract this and create a usual PEM certificate and key. This is nothing to do with UEFI signing, but it’s used to validate to the Microsoft sysdev system that you are who you say you are. Before you can even create a sysdev account, you have to prove this by signing an executable they give you and upload it. They make strict requirements that you sign it on a specific Windows platform, but sbsign worked just as well and bingo our account is created.

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. According to Matthew Garrett, Microsoft is willing to negotiate special agreements with distributions to mitigate some of these problems.

Once the agreements are signed then the real technical fun begins. 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. Fortunately, there is one open source project that can create cabinet files called lcab. Next you have to sign the cabinet file with your Verisign key. Again, there is one open source project that can do this: osslsigncode. For anyone else needing these tools, they’re now available in my openSUSE Build Service UEFI repository. The final problem is that the file upload requires silverlight. Unfortunately, moonlight doesn’t seem to cut it and even with the version 4 preview, the upload box shows up blank, 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”. I assume the fear here is key disclosure but it’s not at all clear (or indeed what “similar open source licences” actually are).

Once the upload is done, the cabinet file goes through seven stages. Unfortunately, the first test upload got stuck in stage 6 (signing the files). After about 6 days, I sent a support email in to Microsoft asking what was going on. 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 …

Tried again. This time I got a download email for the signed file and the dashboard says the signing failed. Downloaded and verified. The binary works on the secure boot platform and is signed with the key

Asked support why the process was indicating failed but I had a valid download and, after a flurry of emails, got back “Don’t use that file that is incorrectly signed. I will get back to you.” I’m still not sure what the actual problem is, but if you look at the Subject of the signing key, there’s nothing in the signing key to indicate the Linux Foundation, therefore I suspect the problem is that the binary is signed with a generic Microsoft key instead of a specific (and revocable) key tied to the Linux Foundation.

However, that’s the status: We’re still waiting for Microsoft to give the Linux Foundation a validly signed pre-bootloader. When that happens, it will get uploaded to the Linux Foundation website for all to use.

131 thoughts on “Adventures in Microsoft UEFI Signing”

The application is apparently *signed* with a generic key. I don’t possess the key itself. I think the whole business of having to upload your applications and verify you are who you say you are for them to sign is because Microsoft doesn’t trust anyone with an actual signing key (even a company specific one).

So there is no technical reason, just a desire to stay in the good graces of Redmond. That makes sense for the foundation, it just seemed from your description that there was some technical reason it would not work.

Seems that this is demonstrating a major security flaw with secure boot. What is to prevent someone who doesn’t care what MSFT thinks from going through the same steps and then releasing the shim or selling it to malware authors?

Microsoft Support did seem to imply in their email that it was a technical problem; I just verified manually that the signed binary did actually work.

However, in order to get your EFI binary signed, you have to do it via Microsoft’s sysdev centre. Even assuming you want to get a single piece of malware signed, and you somehow pass the malware checks and achieve that, Microsoft can still blacklist whatever you get signed via the windows update mechanism (which puts hashes straight into the UEFI forbidden signatures database). So, in practice, this exploit would be short lived.

Modern malwares were created to have a short live, they are intent to be mutated and polymorphic, so this actually is a big flaw!

Most malwares toolkits have an auto update function, so there’s no problem to a malware to change it’s signed loader and continue the infection. Past experiences already demonstrated that Microsoft never update malware database fast enough.

I’m a little fuzzy on this whole secure boot thing. I have a couple of questions.

1) Why is it in microsofts control? This seems alarming to me. Microsoft, Apple and (forgive me) the linux foundation should not be in control of something like this. A third party that does not make any major OS should be given control of this process. Even if they are just contracted by Microsoft, it’d give some impartiality to the procedure.
2) Why do we care? From my limited understanding, secureboot can be turned off on all uefi devices (except ARM).

Matthew Garret has some blog posts on why we’re in this situation but the quick precis is that only Microsoft has the OEM relationships, the existing capability to run a CA and, at the end of the day, is mandating secure boot via the windows 8 hardware certification requirements.

Turning off secure boot isn’t that easy: In a secure boot environment, an unsigned loader on a CD/DVD will look like it’s just unbootable media. That’s a pretty high hurdle to today’s people who expect stuff to just work.

Unfortunately, the Moonlight project has been abandoned for about a year and a half at this point (we’ve had to focus on projects that could become profitable and Moonlight, being a free browser plugin, just couldn’t ever be profitable).

How is Microsoft controlling the boot process not anti-competitive and illegal behavior? What does the European Union think of this? The EU fined Microsoft hundreds of millions of dollars long after the United States bailed on holding Microsoft accountable over Microsoft’s allegedly illegal tactics to run Netscape out of business. Versions of Windows sold in EU nations have to give users a browser choice when they initially setup their machine instead of just defaulting to Internet Explorer.

I would think the best long-term permanent fix (although probably also the most costly, troublesome, and time-consuming one) would be a legal challenge against Microsoft for forcing UEFI signing on non-Microsoft operating systems and bootloaders.

The EU won’t do any serious steps against those mega corporation, as it is built and controlled by the very same cliques that control mega corporations. (remember: the EU was invented by the Bilderberg criminial club directly after WW2, the same people who brought the Europoean totalitarian regimes to power and engineered the war, and also attempted a military fascist coup in the US)

And these little fines against M$ are nothing but a decoy. M$ – and the mafia behind – got back way more indirectly by the bailouts for the totally bancrupt international banking/financial mega corporations – payed by the European taypers.

So, never ever put any hope in that Bruxels Sowjet Regime. They are same enemy of humanity itself, as M$ it.

Instead – as long as or nations aren’t fully destroyed yet – we should use their legislature to file criminal charges against the responsible persons from M$ as well as collaborating hardware companies.

Microsoft bind OEMs to UEFI secure boot (which no PC OEM will reject). This is not wrong by itself (MS asks something supplemental). The wrong part is the OEMs not allowing “user” keys or disabling secure boot (or making it extremely hard). In the “perfect” world, RedHat, Ubuntu and every other distribution should talk to the OEMs and negotiate keys with ALL of them. Also experienced users could upload their own keys to the firmware (thus secure boot ending up being a “things that user trusts” instead of “things that OEM/MS trusts”).
MS already has those contacts, to it’s cheaper+easier (even with these hurdles) to get a MS-signed (pre-)bootloader that will work by default on all existing systems. Unless MS clearly refuses it. But this will never be hold in court as anti-competitive because the OEMs are 1st link in the chain. And let’s face it, even a suit agains OEMs will highly-unlikely bring updates to old HW, not to mention the funds required to sue many OEMs.

So let’s face it, MS approach is the least painful….if it succeeds. It could make 100% of the systems work “now”, instead of maybe 60% in 2-3 years in the OEM-suing approach (and no! I’m not defending MS…I’m using Win7 just for games thanx to VT-d).

PS: making separate keys for all distributions is also impractical because it would require too much flash space, and, if accepted by OEMs, it would lead to a 1st-come 1st-served priority for distribution keys (e.g.: Mint working on HPs but Knoppix working on Dells instead). And let’s not mention future blacklisting.

A couple of things: 1) Grub is GPLv3 which you’re required to certify the binary isn’t and 2) even if you use the pre-v3 grub, it will boot anything and could be used to boot a UEFI virus payload silently. The latter will get either your key or the hash of the grub bootloader revoked.

While you are right, anything can still be booted, the idea is that MS bootloader (which the malware still has to load, otherwise what’s the point) will check and stop. It happened to me on Win8 consumer preview when I changed the boot order thought debian on my Lenovo laptop (although UEFI was loading the binary itself…but maybe the bootloader was too agressive). In other words, the bootloader can check that it was loaded from a signed enviroment (so grub loading Win8 will surely not work).

I will not use or purchase any software which requires UEFI hardware.
I will not use or purchase any hardware which requires UEFI signed software.

I urge others to do the same. I urge Linux distributors to offer easy to follow instruction for disabling UEFI, along with an explanation of why UEFI does not to improve use security, rather than giving microsoft money to get their approval/signature.

I don’t think you understand. UEFI allows for booting off of drives larger than 2TB, and allows for more than 4 primary partitions on a drive, and a whole host of other improvements that BIOS simply doesn’t have a concept of. UEFI is not the enemy here. And UEFI Secure Boot in theory isn’t the enemy, it’s the onerous and draconian measures required and the system currently in place to get signed to be allowed to boot on a Secure Boot machine.

What he is saying, and what I also agree with, is that the price Microsoft is forcing Linux users to pay is TOO HIGH.

Microsoft controlling your every use of your hardware, and who can say that they won’t change the terms after most distros have jumped on board, is not a condition that the FOSS community should even be considering. Bottomly’s experience only confirms that.

There are hundreds of Linux distros that would evaporate in the UEFI environment because they could never get their binaries signed. Those many distros, often ridiculed by opponents of Linux and FOSS, are the seed beds of improvements in Linux. The “LiveCD” is one such example, and it is singularly responsible for enabling Joe and Sally Sixpack to easily install Linux on a box that came with Windows pre-installed. Without it Linux would not be a major force that it now is on PCs and servers. And, of what value would the source code be to Joe Q. Developer if he has to step through Microsoft’s hoops in order to get a modified binary re-signed? If Bottomly and the LF are having these problems what influence would the smaller distros have?

The pretense of EUFI was supposedly to block the ability of the bad guys to put vectors to Trojans in the MBR or the recovery partition on Windows boxes. There is no proof that it will prevent the bad guys from doing so anyway, but there is now plenty of proof that it is very good at blocking the installation of Linux on the majority of devices running Win8. Considering the history of Microsoft’s scoff-law, anti-competitive attitude and actions, those Penguins who think the continued uptake of Linux by the masses won’t be severely hindered by UEFI are living in a fools paradise.

Right now, with Black Friday sales, it would be a good time to stock up on two or three Win7 laptops, store their batteries in the refrigerator, and wrap them up in plastic to insure the availability of a Linux compatible box in the near future. Then, become part of the political action to remove Microsoft’s monopolistic grip from the PC OEMs and bring them to justice for all the crap they have done since the DOJ trial.

Actually, I didn’t say, but the first time, I did use all the MS tools. That was the submission that got stuck in the signing process. The second submission which was done with the open source tools is the one that succeeded (at least it gave me back a signed binary even if the signature was with the wrong key).

I don’t think there are any material differences between the tools because both the cab format and the signing process are published standards.

The main reason for not using windows tools is that I’m used to openssl. Additionally, although I think openssl has a rather confusing interface, the Microsoft tools make it look slick by comparison.

It’s pretty annoying and disturbing that you have to depend on a 3rd party software developer company (yes, I mean Microsoft) when you want to run your own operating system on your own purchased hardware. Actually, as someone having been around computers and software for 19 years [1], I find this very objectionable and totally unacceptable. Also, the way things are going right now regarding Microsoft’s signing procedure – based on the original blog post above – doesn’t exactly suggest that Microsoft wants to make others easy to get signed. And, unfortunately, history tells us you can’t always be optimistic regarding Microsoft’s self-proclaimed benevolence in such matters.

[1] I’m stating this because someone young and growing up in the constrained world that Apple and Microsoft are forcing on the rest of us, might just think this is an acceptable way of doing thigs, since it fits right into the picture. Well, not my picture.

Question: when all this is said and done, will there be ‘dummy-friendly’ instructions made available on how to change the UEFI keys so that a notebook with Secure Boot can run a distro of our choice?

I have read your earlier articles about updating the keys but I still can’t seem to wrap my head around the proper procedures. As for the key that you are generating, is it a signature (ie, one of those db.x.cer) file? Am i right to asuume that the signing service will not generate any KEKs, only signature keys?

Also, what would end-users need to do? Let’s say I want to install Distro XYZ on a Secure Boot notebook, how do i enrol the signature key into the UEFI Secure Boot firmware? Using the distro’s LiveCD, or within Windows?

Any idiot-friendly, step-by-step breakdown /instructions will be greatly appreciated.

This explains how to create the keys for at least the tianocore key manager to install. I also produced a set of uefi programs to do this programmatically as explained here

It’s not for novice users, but it’s certainly possible (I’ve done it). If you don’t want to risk your actual hardware until you’re sure you know what you’re doing, I’d play with these in the OVMF qemu environment first.

Wrong….(or should I say the spec is so flexible that this cannot be proven)….how many “browsing-only” friends do you have? How many of those run OSes other than Windows or Apple? Secure-boot was meant for them, to reduce malwares, rootkits etc (note: reduce…not eliminate). On systems already with Windows installed (or iOS, but they don’t work with OEMs).
The experienced users know how to handle malware and they will not call MS tech support for it. But those are the users hurt by secure-boot. And not because MS requires it, but because OEMs don’t bother with anything other than MS. UEFI Secure Boot spec allows for user control, but again, OEMs don’t bother. It’s like ESP on cars….laws require it, so it’s there, but some manufacturers allow disabling it, others just allow it down to minimum, so track days are a pain for those that really can drive fast and are hindered by ESP.

This is probably the most sane, mature, reasonable and objective answer ever given in this discussion.

Which is a far cry from those who have become part of the ‘OMG-UEFI-AND-SECURE-BOOT-ARE-EVIL’ peanut gallery.

The spec on its own is reasonable, sane and potentially very useful. Only the implementation is borked. And borked implementations can (eventually) be fixed. Which is much better than specifications that were already borked right from the design stage.

Well, MS knew darn well that many or most OEMs wouldn’t bother implementing MS’s “Secure Boot” requirements properly and sensibly, if MS didn’t require them to, and that left to themselves these OEMs would generally implement Secure Boot only partially (at least for consumer hardware) — in other words just well enough to boot Windows 8 and thus meet MS’s needs and requirements (too bad for everybody else). MS coyly insisted that this was nothing to do with themselves (and of course, MS’s history of backroom deals, behind the scenes pressure and outright dirty-tricks was blandly ignored and denied).

After enough fuss was made, MS updated the official requirements for Windows 8 Certification and the Windows 8 Logo program, to also require the ability to turn off “Secure Boot” and to require some sort of user-controlled key management.

But only for PCs — for ARM devices (including but not limited to MS’s own Surface RT) to qualify for Windows 8 Certification or Logo, the ability for users (aka “owners”) to disable “Secure Boot” or manage their own boot keys is actually, explicitly forbidden.

You FOSS people have always hated MS with a passion, so why do you even CARE that you cannot disable SB on a Surface?

Devices shipped with ARM hardware are appliances, NOT computers. Just because they function like one does not mean that they should be classified as one.

Linux users are sitting on Microsoft’s tree, and this tree includes Microsoft’s hardware partners who have been contracted to make hardware for Windows. Be prepared to be the first to fall off the tree in the most spectacular manner whenever Microsoft goes pruning or simply gives it a kick.

If you don’t want to fall off this tree, get the whole FOSS community to grow their own tree complete with OEM support. Apple had grown their own tree to huge success.

After 2 decades, where is the FOSS / Linux tree? Not even planted yet. All the community wants is to pluck the fruits from Microsoft’s tree. Now that Microsoft has sprayed pesticides on the fruits, you’re complaining that you’re getting harmed by the pesticides.

I wish that the Linux Foundation, with its hundreds of industry members, would work to reverse the ridiculous “secure” boot requirement for Win8 certified hardware, and push hard for open hardware. How is this not illegal collusion, just like all of MS’ anti-competitive baloney? Not that any government regulators care.

I am completely confused by the bit about having to wrap the bootloader into a Windows Cabinet File in order to get it signed.

What on earth is the point of that?
Isn’t it a totally unnecessary and arbitrary complication?
I’m pretty sure (I’m not an IT guy) that UEFI doesn’t require cab files.
Surely EUFI can boot non cab files?

And how do you end up with a signed bootloader, unless MS unwraps the cab file, signs the contents, re-wrapps the binary and presumably signs that, too?

This strikes me as somewhat ludicrous. Rube Goldberg would be impressed.

Yes, in the long term, the distributions are working on solutions to take advantage of UEFI secure boot with the purpose of enhancing Linux security. The main projects are Matthew Garrett’s shim and SUSE’s MOK with all signs being they’ll actually produce a single joint solution.

I’ve just send this email to the Linux Foundation in the hope that they’ll pick up the idea if possible:

Regarding this whole issue of why we need some OS provider to grant other OS providers access to secure boot is really beyond me.

But Has the Linux Foundation tried to establish, like Microsoft did, it’s own
OEM relationship ? This will place the Linux Foundation key also into UEFI.

The way it is done right now by MS and the OEM’s can be seen by the European Union as Illegal because of it’s possibility, if desired by MS, to block access for other OS’s and thus falls into Cartel forming/illegal practices.

You as the Linux Foundation can directly address this concern to our well known Miss Nelie Smit Kroes, Vice-President of the European Commission, her department has dealt with Microsoft before.
I can guarantee the LF that she’ll be very interested in this issue !
She can force the OEM’s to incorporate the LF key into UEFI !