This post describes UEFI Signing policy changes. These changes are important to help secure boot meet its security goals and also to maintain a reasonable turnaround time for signing UEFI submissions. This post also reiterates a few important parts of the existing UEFI signing policy licensing terms.

UEFI signing is a service provided by the Windows Dev Center hardware dashboard that lets you submit UEFI firmware binaries targeted to x86 or x64 computers for signing by Microsoft, so they can be more easily installed on computers running Windows that use secure boot and execute code signed with the UEFI CA.

While Microsoft reserves the right to sign or not sign submissions at its discretion, this list of requirements should be adhered to. Doing this will help you achieve faster turnaround times for getting your submission signed, and will also help avoid revocation. Microsoft might conduct follow-up reviews, including but not limited to questionnaires, package testing, and other security testing of these requirements before signing.

1. Starting March 15, 2014, UEFI submissions will require an EV certificate.

a. Starting March 15, 2014, SysDev will begin accepting EV certificates issued by either DigiCert or VeriSign for new submissions and renewals.

b. Existing submitters have until August 15, 2014, to move from existing non–EV code signing certificates to EV code signing certificates. This extension is provided to facilitate frictionless migration.

2. Only production quality code (for example, “release to manufacturing” code, rather than test or debug modules) that will be released to customers (no internal-only code or tools) are eligible for UEFI signing. For internal-use code, we suggest that you either turn off secure boot or add your own key to the SecureBoot database during development and testing.

3. Code submitted for UEFI signing must not be subject to GPLv3 or any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device. Code that is subject to such a license that has already been signed might have that signature revoked. For example, GRUB 2 is licensed under GPLv3 and won’t be signed.

4. If there’s a known malware vector related to code that uses certain techniques, that code won’t be signed and is subject to revocation. For example, the use of versions of GRUB that aren’t SecureBoot enlightened won’t be signed.

5. All code modules must be authenticated before execution. If this is not the case, submissions won’t be signed, and, if already signed, are subject to revocation.

a. If your submission loads a GRUB or other loaders, it must be SecureBoot enlightened.

For example, the latest GRUB 2 with SecureBoot patches.

b. Developers might assume that secure boot security requirements have been satisfied when their initial boot is complete. However, if a secure boot system permits launch of another operating system instance after execution of unauthenticated code, the security guarantee of secure boot is compromised. If this vulnerability is exploited, the submission might be revoked.

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.

b. If you lose keys or abuse the use of a key, or if a key is leaked, any submission relying on that key will be revoked.

c. Some shims are known to present weaknesses into the SecureBoot system. For a faster signing turnaround, we recommend that you use source code of 0.7 or higher from shim - GitHub branch.

7. You must test your product, following the Pre-Submission testing document (for UEFI Submissions), before submitting for signing.