Not applicable
First published on MSDN on Dec 03, 2013
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. Microsoft UEFI CA signs only those products which are for public availability and are needed for inter-operability across all UEFI Secureboot supported devices. If a product is specific to a particular OEM or Organization and is not available externally then we suggest you sign it with your private key and add the certificate to SecureBoot database.

4. 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.

5. 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.

6. 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.

7. If your submission is a shim (handing off execution to another bootloader):
a. Code signing keys must be backed up, stored, and recovered only by personnel in trusted roles, using at least dual-factor authorization in a physically secured environment.

  • The private key must be protected with a hardware cryptography module. This includes but is not limited to HSMs, smart cards, smart card–like USB tokens, and TPMs.

  • The operating environment must achieve a level of security at least equal to FIPS 140-2 Level 2.

If embedded certificates are EV certificates, you meet all of the above requirements. We recommend that you use an EV certificate because this will speed up UEFI CA signing turnaround.

b. Submitter must design and implement a strong revocation mechanism for everything the shim loads, directly and subsequently.

c. 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.

d. 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.8 or higher from shim - GitHub branch .

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

9. If there are known security vulnerabilities in your submission code, the submission won’t be signed, even if your functionality doesn’t expose that code. For example, the latest known secure versions of OpenSSL are 0.9.8za and 1.0.1h, so if your submission contains earlier versions that contain known vulnerabilities, it won’t be signed.

10. Microsoft will not sign EFI submissions that use EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER. Instead, we recommend transitioning to EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER. This prevents unnecessary use of runtime EFI drivers.

11. Use of EBC code: Microsoft will not sign EFI submissions that are EBC-based submissions.

12. If your submission is a DISK encryption or a File/Volume based encryption, then you MUST make sure that you either don’t encrypt the EFI system partition or if you do encrypt, be sure to decrypt it and make it available by the time Windows is ready to boot.