UPDATED: UEFI Signing Requirements

by Contributed | Jan 28, 2021 | Technology

This article is contributed. See the original author and article here.

UEFI signing is a service provided by the Windows Hardware Dev Center dashboard by which developers submit UEFI firmware binaries targeted to x86, x86-64, or ARM computers. After these binaries are approved through manual review, the owners can install them on PCs that have secure boot enabled with the Microsoft 3^rd Party UEFI CA permitted.

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

The following list contains the latest requirements for the UEFI signing process. These requirements are to ensure the security promise of secure boot, and to help expedite the turnaround of signing submissions.

1. UEFI submissions require an EV certificate and an Azure Active Directory (AAD) account.


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, you should add your own key to the Secure Boot database UEFI variable or turn off Secure Boot during development and testing.


3. Microsoft UEFI CA signs only those products that are for public availability and are needed for inter-operability across all UEFI Secure Boot supported devices. If a product is specific to a particular OEM or organization and is not available externally, you should sign it with your private key and add the certificate to Secure Boot 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 will not be signed.


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


6. If there are known security vulnerabilities in your submission code, the submission will not 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, the submission will not be signed.


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


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


9. Use of EFI Byte Code (EBC): Microsoft will not sign EFI submissions that are EBC-based submissions.


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


11. If your submission is comprised of many different EFI modules, multiple DXE drivers, and multiple boot applications, Microsoft may request that you consolidate your EFI files into a minimal format. An example may be a single boot application per architecture, and a consolidation of DXE drivers into one binary.


12. If your submission is a SHIM (handing off execution to another bootloader), then you must first submit to the SHIM review board and be approved before a submission will be signed. This review board will check to ensure the following:
    
    
    
    1. 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.
       
       
       
       1. 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.
       
       
       2. The operating environment must achieve a level of security at least equal to FIPS 140-2 Level 2.
       
       
       3. If embedded certificates are EV certificates, you should meet all of the above requirements. We recommend that you use an EV certificate because this will speed up UEFI CA signing turnaround. 
       
       
       
       
    
    
    2. Submitter must design and implement a strong revocation mechanism for everything the shim loads, directly and subsequently.
    
    
    3. 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.
    
    
    4. 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.
    
    
    
    

13. If your submission contains iPXE functionality, then additional security steps are required. Previously, Microsoft has completed an in depth security review of 2Pint’s iPXE branch. In order for new submissions with iPXE to be signed, they must complete the following steps:

1. Pull and merge from 2Pint’s commit: http://git.ipxe.org/ipxe.git/commitdiff/7428ab7  


2. Get a security review from a verified vendor. Refer vendor to the iPXE Security Assurance Review blog post. Emphasis of the review should be on:
   
   
   
   1. NFS functionality being removed
   
   
   2. Wireless functionality being removed
   
   
   3. Non-UEFI loaders are not included
   
   
   4. Ensuring all known reported security problems are fixed (identified in the iPXE Security Assurance Review blog post).
   
   
   
   


3. Share the specific commits that are made to the project, allowing Microsoft to ensure the expected changes are made.

For questions about the UEFI Signing process, contact uefisign@microsoft.com

A Tour of SQL Workshops | Data Exposed

by Contributed | Jan 28, 2021 | Technology

This article is contributed. See the original author and article here.

Join Anna Hoffman and Buck Woody as they take a tour of the incredible learning resource the Microsoft Engineering team has put together. From labs to full hands-on workshops and much more, you’ll find a wealth of high-quality, free-cost training. You’ll also learn about many of the other valuable references and assets you can find at SQL Workshops. 

To get started with SQL Workshops, click here.

Watch on Data Exposed

View/share our latest episodes on Channel 9 and YouTube!