Windows 10: UPDATED: Latest UEFI Signing Requirements from Microsoft

Brink · Dec 12, 2019

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 3rd 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:
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.
i. 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.
ii. The operating environment must achieve a level of security at least equal to FIPS 140-2 Level 2.
iii. 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.
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.
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:
A. Pull and merge from 2Pint's commit: iPXE git repositories - ipxe.git/commitdiff

B. Get a security review from a verified vendor. Refer vendor to the iPXE Security Review Guidance for the review. Emphasis of the review should be on:
i. NFS functionality being removed
ii. Wireless functionality being removed
iii. Non-UEFI loaders are not included
iv. Ensuring all known reported security problems are fixed (identified in the iPXE Security Review Guidance)
C) Share the specific commits that are made to the project, allowing Microsoft to ensure the expected changes are made.
Click to expand...

For questions about the UEFI Signing process, contact [email protected]

Source: https://techcommunity.microsoft.com/...s/ba-p/1062916

:)

btarunr · Dec 12, 2019

UEFI Forum Releases UEFI 2.3.1 Specification Update

The UEFI Forum has ratified an update to the UEFI 2.3.1 Specification that adds important firmware considerations and addresses numerous engineering change requests. The updated Specification will be referred to as “UEFI 2.3.1C”.

UEFI 2.3.1C adds: An OS Indications Variable - OS/FW feature & capability communication – when implemented, allows end-users to make an OS menu request to enter BIOS setup after next reboot.

UEFI 2.3.1C adds: A mechanism which, when implemented, facilitates Open Source Operating System installations and OS- agnostic end-user configurations of retaining the factory default keys while in Setup Mode (see Specification for full technical detail of Setup Mode).

UEFI 2.3.1C removes: Runtime driver requirement on Network UNDI drivers - this allows UNDI drivers to be delivered in EFI Byte Code (EBC) Virtual Machine format supporting systems based on different processor architectures.

Complete details on UEFI 2.3.1C are available here.

The UEFI Forum’s UTWG (UEFI Test Working Group) is currently working on updating the SCT (Self-Certification Tests) to align with the latest spec changes. Please see www.uefi.org for more updates.

UEFI Summer Summit Interoperability & Education Event:
Specification Update Benefits Windows 8 & Open Source OS Implementations Microsoft to Host UEFI Summer Summit, July 16-20, 2012 in Redmond, WA

The UEFI Testing Work Group (UTWG) and the UEFI Industry Communications Work Group (ICWG) from the Unified EFI (UEFI) Forum invite you to register for the upcoming UEFI Summer Summit: An Interoperability and Education Workshop being held this July at the Microsoft Campus in Redmond, WA.

Hosted by Microsoft, the event is sponsored by AMD, AMI, HP, Insyde, Intel, Microsoft & Phoenix.

Online registration for the UEFI Summer Summit can be found at here and here. Please note registration is scheduled to close on July 9th.

The organizers specifically wish to encourage add-in card vendors to attend the Summit. This is the last planned Forum-sponsored opportunity to test Secure Boot functionality and the interoperability of cards with UEFI-compliant systems for 2012. With the serious industry interest in Secure Boot functionality, this Summit is an excellent opportunity to test interoperability, as well as discuss the technology with other industry members.

Arun B J · Dec 12, 2019

I keep getting a notification click here to update your credentials Microsoft needs you to sign in Windows 10.

Hi,

I realized your concern and will assist you to resolve the issue.

I suggest you to sign out from Microsoft Account and sign in again and check if it helps.

Follow the steps below.

Press Windows key and type Settings.

Select Account.

Select your Account.

Click on Sign in with local account instead of Microsoft Account.

It will prompt for Microsoft Account Password.

Enter the password then again sign back with Microsoft Account follow the same steps.

And also check for latest Windows updates and install.

Press Windows logo key +R, enter
MS-settings: and then press OK. This opens Settings.

In Settings, go to Update & security >
Windows Update, and then select Check for updates. Install any available updates and restart your PC if required.

Your reply is very important for us to ensure a proper resolution. Please get back to us with the above information in order to assist you accordingly.

Thanks and regards.

Eeshwar Kumar · Dec 12, 2019

signing into microsoft account

Hi,

Thank you for getting back to us. We apologize for the delay in response.

I suggest you to follow the steps provided below and check if it helps.

Navigate to Start>Settings>Accounts.

In the left pane, click on sign-in options.

In the right pane select Never from the drop down list for the option
Require sign-in.

Hope this helps. Keep us posted on the status for further assistance.

Windows 10: UPDATED: Latest UEFI Signing Requirements from Microsoft

UPDATED: Latest UEFI Signing Requirements from Microsoft

UPDATED: Latest UEFI Signing Requirements from Microsoft

UPDATED: Latest UEFI Signing Requirements from Microsoft

UPDATED: Latest UEFI Signing Requirements from Microsoft - Similar Threads - UPDATED Latest UEFI

Sign-in required & Unable to Update

'Require sign-in' is missing from Sign-in Options

After latest update Password required.

Latest Microsoft update

Latest Microsoft update

Help required after latest Update

latest update to microsoft

Latest update requires pin for sign in?

Microsoft Account Required Sign in and Password