The Adventures in Microsoft's UEFI Signature

I'm going to translate this article written by James Bottomley , technical advisor of the Linux Foundation , who set about putting together a pre-bootloader so that Linux can boot.

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 gained access to Microsoft's signing system.

The first thing you need to do is pay the $99 fee to Verisign (now Symantec) and get a Verisign-verified key. We did this for the Linux Foundation, and all they want to do is call headquarters to verify it. The key is returned via a URL that installs in your browser, but standard Linux SSL tools can be used to extract it and create a regular PEM certificate and key. It has nothing to do with UEFI signing, but it's used to validate to Microsoft's sysdev system that you are who you say you are. Before you can create a sysdev account, you have to test it by signing an executable they provide and uploading it . They have strict requirements that you sign it on a specific Windows platform, but sbsign at least worked, and bingo, our account was created.

Once you create an account, you still can't upload UEFI binaries for signing without first signing a paper contract . The agreements are very onerous, including a lot of excluded licenses (including all GPLs for drivers, but not for bootloaders). The most onerous part is that the agreements seem to extend beyond the UEFI objects you sign . The Linux Foundation's lawyers concluded that it's mostly harmless to the LF because we don't sell products, but it could be unacceptable to 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, the real technical fun begins . You can't just upload a UEFI binary and expect it to be signed. First, you have to wrap it in a .cab file . Fortunately, there's an open-source project that can create cabinet files called lcab. Then you have to sign the .cab file with the Verisign key . Again, there's another open-source project that can do that: osslsigncode. For anyone who needs those tools, they're available in my openSUSE UEFI Build Service repository. The final hurdle is that uploading the file requires Silverlight . Unfortunately, Moonlight doesn't seem to work, and even with the version 4 preview, the upload box goes blank, so it's time to use Windows 7 under a KVM (kernel-based virtual machine). When you get to that part, you also have to certify that the binary "to be signed, must not be licensed under the GPLv3 or similar open-source licenses ." I assume it's due to fear of the key being disclosed, but it's not clear at all (the same goes for "similar open source licenses").

Once the upload is complete, the cabinet file goes through seven stages. Unfortunately, the first test upload got stuck at stage 6 (the file signing stage). After six days, I emailed Microsoft support asking what was happening. The response: “The error code returned by the signing process is that your file is not a valid Win32 application . Is it a valid Win32 application?” The answer: obviously not, it's a valid 64-bit UEFI binary. There were no further replies

I tried again. This time I received a download email for the signed file, but the dashboard said the signing failed . I downloaded and verified it. The binary works on the Secure Boot platform and is signed with the key.

subject = / C = US / ST = Washington / L = Redmond / O = Microsoft Corporation / OU = MOPR / CN = Microsoft Windows UEFI Driver Publisher
issuer = / C = US / ST = Washington / L = Redmond / O = Microsoft Corporation / CN = Microsoft Corporation UEFI CA 2011

I asked support why the process was indicating an error, but I had a valid download. After a flurry of emails, they replied, "Don't use that file; it was incorrectly signed . I'll get back to you." I'm still not sure what the problem is, but if you look at the Subject of the signing key, there's nothing in the 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 linked to the Linux Foundation.

However, this is the status: We will continue to wait for Microsoft to give the Linux Foundation a signed and validated pre-bootloader. When that happens, it will be uploaded to the Linux Foundation site for all to use.

Source: http://blog.hansenpartnership.com/adventures-in-microsoft-uefi-signing/

Draw your conclusions, but this is going to take time.


Add as preferred source in Google