Microsoft UEFI CA Signing policy updates

re: Microsoft UEFI CA Signing policy updates

Dee — Fri, 14 Feb 2014 03:43:22 GMT

Thanks CT - on the EV in SHIM; We currently provide our own (public) certificate inside shim which was generated via openssl (along of course with the private key). We sign our binaries (from what shim loads all the way to the kernel/main binary) with the private key (which we keep protected). In that case EV certificates don't mean anything, we are 100% sure of who we are and since we will be signing shim (which has our private embedded certificate) with our verisign EV certificate matching the one in sysdev, you're sure that the signed shim we provide is from us and the certificate within it is also under our trust. If someone modified our shim, secure boot wouldn't load it. or am I missing something?

re: Microsoft UEFI CA Signing policy updates

Certification team — Fri, 14 Feb 2014 01:14:47 GMT

Hi Ed,

The Developer Portal is working towards supporting EV certificates from both DigiCert and VeriSign, and we will bring this capability online soon. In the interim, if you are planning to sign up and submit, you can continue to use VeriSign’s Non-EV Code Signing certificate as stated in the sign up workflow, though we would recommend you use VeriSign’s EV certificate to be forward compatible with future requirements (See answer to Dee’s question on EV certificates). If you use a VeriSign’s EV certificate then you don’t need VeriSign’s $99 certificate for sign up.

re: Microsoft UEFI CA Signing policy updates

Certification team — Fri, 14 Feb 2014 01:13:36 GMT

Hi Dee,

(about loading unsigned kernel)

As mentioned in 5.b above, it is strongly recommended to load only signed kernel modules to avoid security vulnerabilities which may result in possible future revocation (if and when exploits are found compromising SecureBoot). This latest article in ITWire(www.itwire.com/.../63120-microsoft-changes-policy-on-third-party-signing-of-efi-code) might help with deeper understanding of the security need of this, and the adoption of these practices by other operating system vendors, such as Fedora.

(about EV in SHIMs)

The rationale for requiring EV inside SHIM is to get a better guarantee of key management and trustworthiness. Signing SHIM is equivalent to cross signing a CA to trust other non-UEFI CA signed modules. Hence the higher security bar for SHIM. We, of course, appreciate this feedback and we will continue discussing with various partners on the impact this change may have on their build infrastructure.

re: Microsoft UEFI CA Signing policy updates

Dee — Thu, 13 Feb 2014 18:32:52 GMT

Still questioning the EV requirement within the shim (6a) - the more I think about, the less sense it makes. If we put our own private strong certificate built using openssl (we know who we are) within the SHIM to verify all our loading of binaries, that is just as strong as using an EV certificate. There is no advantage to having to use an EV certificate within the shim to verify our binaries. Now for submitting to MS, an EV certificate is fine. Once signed, that shim can't be altered with another certificate (only our private certificate can be in there or it would have never been loaded by the UEFI secure boot code).

re: Microsoft UEFI CA Signing policy updates

Plaque — Wed, 12 Feb 2014 11:11:57 GMT

Still no answer to Myria 10 Dec 2013 2:16 PM blogs.msdn.com/.../microsoft-uefi-ca-signing-policy-updates.aspx

re: Microsoft UEFI CA Signing policy updates

Ed — Tue, 11 Feb 2014 20:44:11 GMT

The UEFI sign-up process points new registrants at

> VeriSign Code-Signing Certificates for Microsoft Authenticode ($99 USD)

> products.verisign.com/.../winqualOrder.do

Is there a new process to obtain an EV certificate to sign up, or does one need both the certificate mentioned above and an EV certificate?

re: Microsoft UEFI CA Signing policy updates

Dee — Fri, 07 Feb 2014 01:28:10 GMT

What exactly is the point of requiring an EV certificate in the SHIM? As long as shim is checking the code to be executed by checking it (using a certificate), that's all that is needed to ensure it's okay. What additional would be needed if it was an EV type? Because you can't provide the CA itself.

6. If your submission is a shim (handing off execution to another bootloader):

a. Certificates embedded in the shim must all be EV Certificates, and the Organization attribute in all these embedded certificates must be same as the Organization attribute in the EV Certificate on file for the SysDev account.

re: Microsoft UEFI CA Signing policy updates

John Doe — Thu, 06 Feb 2014 03:55:44 GMT

I wonder where to anti-monopoly regulators are looking. MS has gone as far as to policing what licenses we should use. What a blatant monopoly abuse.

re: Microsoft UEFI CA Signing policy updates

Dee — Fri, 31 Jan 2014 01:20:42 GMT

So is it still okay to boot unsigned linux kernel if the ExitBootServices is called or is the requirement that it *has* to be signed to boot if secureboot is enabled.

re: Microsoft UEFI CA Signing policy updates

JJ Cox — Tue, 07 Jan 2014 17:54:44 GMT

Hi geofft,

Yes, we are working on an alternative distribution channel for the revocation lists that is directly consumable by 3rd-parties without requiring a functioning Windows 8.x installation. We'll post here when we have more information.

re: Microsoft UEFI CA Signing policy updates

Michael Alberts - MSFT — Thu, 12 Dec 2013 17:25:23 GMT

Hi Anthony. Because your question isn’t directly about certification, we aren’t the best resource for you. I recommend that you contact your motherboard vendor. Hope this helps.

re: Microsoft UEFI CA Signing policy updates

ANTHONY M — Thu, 12 Dec 2013 11:54:47 GMT

Gigabyte is changing my mobo BIOS OVER TO UEFI BIOS. I'll be honest here. I have NOT a clue on how to do the change over yet. Is there anything that I need to do before I try this conversion? If so, then please advise. Even better are there any areas in M Soft that can help me with this??

Sincerely,

ANTHONY M

re: Microsoft UEFI CA Signing policy updates

geofft — Tue, 10 Dec 2013 23:56:19 GMT

How do vendors (and users) of third-party OSes distribute revocations like this morning's security advisory 2871690 to machines that don't have a Windows partition? Is there a feed of blacklists that we can put in our own security updates?

re: Microsoft UEFI CA Signing policy updates

Myria — Tue, 10 Dec 2013 22:16:47 GMT

If Windows fails requirement 5b, will Microsoft revoke its signature?

re: Microsoft UEFI CA Signing policy updates

JJ Cox — Thu, 05 Dec 2013 17:06:59 GMT

Sathya,

Please review the PreSubmission Testing webpage linked above and let us know if you have additional questions.

re: Microsoft UEFI CA Signing policy updates

JJ Cox — Thu, 05 Dec 2013 01:25:25 GMT

The pre-submission test directions are here:

blogs.msdn.com/.../pre-submission-testing-for-uefi-submissions.aspx

re: Microsoft UEFI CA Signing policy updates

Sathya — Wed, 04 Dec 2013 18:03:05 GMT

Could we get more details on this like what are the tests and how they applicable to IHV provided boot services driver etc?. More like step be step version of what needs to be done prior to signing submission

re: Microsoft UEFI CA Signing policy updates

WM — Tue, 03 Dec 2013 20:31:31 GMT

Where can this pre-submission testing document be found?