This article is part 1 (Windows 10 UEFI Secure Boot) of a new Windows series. In it, I will explain the built-in security measures implemented in Windows 10 to secure the OS boot phases and ensure the integrity of the OS platform for corporate use cases.
In my previous article, “Understanding Device Health Attestation Intune Device Compliance Check,” I briefly discussed Secure Boot, Code Integrity, and TPM Boot Measurement. If you have not read that yet, I recommend you do so.
In this post, I will explain Windows 10 UEFI Secure Boot and how it protects the Windows Pre-Boot phase. So, let’s get started.
Windows Boot Flow Classification
The Windows OS boot flow can be classified into three parts –
- Pre Boot phase
- Boot Loader phase
- Kernel Initialization phase
Again, based on the platform firmware settings, the window boot flow can be classified as below
- Traditional/ Legacy Boot flow
- Modern/ UEFI Boot flow
Traditional Windows Boot Flow – Why is it not secure?
In traditional/legacy boot flow – as the system is powered On
- Firmware conducts a Power On Self-Test, a diagnostic testing sequence to check the system’s components and detect whether the system can continue to the next stage. If OK, firmware initializes the hardware components.
- Firmware next reads the boot information from CMOS to invoke the Windows Boot Manager, which reads the Boot Configuration Data to invoke the Windows Boot Loader. The latter loads the OS kernel to the RAM, and the Kernel takes over from here.
Before Windows 10, kernel initialization was posted when Windows Defender service used to start – the native anti-malware shipped with Windows OS.
Thus, in the traditional or legacy boot flow, no security measure is implemented at any stage to check against corrupt or malicious code (rootkits/boot kits) and prevent them from being executed during the boot flow.
As such, boot parameters can be easily modified to run malicious code during the boot flow, which can cause the system to boot to an unstable state or compromise run-time security. This is a serious threat if we consider the impacts in corporate scenarios.
Does Windows 10 improve the scenario?
With Windows 10, Microsoft introduced a number of security features built into the OS to address the above and protect the Windows boot flow.
- Windows Trusted Boot
- Early Launch Anti-Malware Driver
- Windows Measured Boot (TPM dependency for health attestation)
- Device Guard
- Credential Guard
- Windows Defender Application Guard
However, Windows 10 UEFI Secure Boot—the focus of this article—is the feature that forms the foundation for a secure Windows platform.
Enter Windows 10 UEFI Secure Boot
Windows 10 UEFI Secure Boot, a UEFI feature per specification 2.3.1 errata C, helps to secure the Windows pre-boot phase, mitigating the risks against rootkits and boot kits.
As a UEFI system starts, it first verifies whether the firmware is digitally signed, thereby reducing the risk of firmware rootkits. If Secure Boot is enabled in UEFI, the firmware examines the bootloader’s digital signature to verify that it hasn’t been modified and is trusted to be executed.
Let’s repeat the same boot flow, but this time with the Secure Boot feature enabled in UEFI.
- As a device is powered on, Core Root of Trust Management (usually implemented in the CPU, the first code block that gets executed when a device is powered on and is implicitly trusted to form the Root of Trust) checks the signature of the UEFI boot loader provided by SoC (System on Chip) vendor and triggers it.
- The UEFI Boot Loader verifies the signature of the UEFI Firmware Image before loading it.
- The UEFI Firmware then verifies the signatures of the UEFI drivers and OEM UEFI applications before initializing them. The firmware then verifies the signature of Windows Boot Manager (bootmgfw.efi) located at \EFI\Microsoft\Boot\ on the EFI System Partition and triggers it.
In the event that UEFI finds a problem with the Windows Boot Manager (bootmgfw. efi), it will replace the same with a backup copy and attempt to continue with the boot process. In case this also fails, the UEFI firmware initiates OEM-specified remediation.
- Considering no problem with Windows Boot Manager, bootmgfw. efi reads the Boot Configuration Data (bcd) located at \EFI\Microsoft\Boot\BCD on the EFI System Partition to locate the OS Bootloader (winload. efi), which is usually located at %SystemRoot%\System32\
With Bitlocker Device Encryption enabled and the Bitlocker key sealed to TPM, depending on the PCR measurement value, TPM will automatically unseal the Bitlocker key to decrypt the OS Volume for Windows Boot Manager to access and call Windows Boot Loader. However, if the PCR measurement value doesn’t match the value with which the key was sealed, TPM won’t unseal the key and as such Bitlocker Recovery will be triggered.
- Considering no changes in PCR measurement value, Bitlocker will automatically unlock the OS drive for bootmgfw. efi to verify the signature of winload.efi before passing control to it.
If a problem arises due to corrupt boot-start drivers or NTOS Kernel image, UEFI Firmware will initiate the Windows Recovery Environment (WinRE) to recover/repair the drivers/OS Kernel.
Execution of the OS bootloader marks the end of Secure Boot’s jurisdiction. Though its jurisdiction ends, it does not cease to play a role as it lays the foundation of the Code Integrity check, which will continue to check the Kernel Boot Phase of the Windows OS.
Secure Boot Flow Schema – Windows 10 UEFI Secure Boot
Since all the EFI components are verified for trust before execution, creating a trust chain helps reduce rootkit/bootkit risks. If the signature/hash doesn’t match the UEFI signature database, it will be prevented from getting executed, eliminating the risk.
Windows 10 UEFI Secure Boot protected flow for loading OS Bootloader is schematically represented below
Secure Boot is not supported on legacy BIOS platforms or UEFI with the enabled Compatibility Support Module (CSM) mode. It is only available in pure UEFI mode.
Windows 10 UEFI Secure Boot Internals
Windows 10 UEFI Secure Boot uses Public Key Cryptography to authenticate code before it is allowed to execute. Below is a representation of the UEFI Secure variables as per the hierarchy.
An EFI component is verified trusted if it
- is unsigned but has a SHA256 hash of the image in db and not in dbx,
- or is signed and has a signature in db but not in dbx.
The associated keys are
- Platform Key (pk)
- Key Exchange Key Database (KEK)
- Signature Database (db)
- Forbidden Signature Database (dbx)
The OEM stores these in the UEFI NVRAM during manufacturing as UEFI Secure Variables, as per section 7.2 of the UEFI 2.3.1 errata C specification.
UEFI Secure Variable stores both the key and time of variable creation or the monotonic count. This is to ensure that a newer update must have either a later time or a higher monotonic count.
Windows 10 UEFI Secure Boot requires each EFI component to be digitally signed by the OEM using the private key, the public key of which needs to be present in the UEFI Signature database (DB) to be trusted and allowed execution during the boot phase. If the signature of an EFI component does not match any public key present in the UEFI Key Signature database (DB) or matches with a public key present in the revoked/forbidden signature database (dbx), then that component is not allowed to get executed, and the boot process is halted.
Purpose of Platform Key (PK) – Windows 10 UEFI Secure Boot
This key establishes a trust relationship between the platform owner (PC Manufacturer/OEM) and the firmware (UEFI BIOS) and control access to the KEK database. This is considered the Root of Trust.
There can only be a single PK per platform. However, it’s at the sole discretion of the OEM to decide if it will create a unique PK per PC, per PC model or per PC product line. The public part of this key is stored in the UEFI NV-RAM by the OEM during manufacturing. The private part remains with the OEM.
Purpose of Key Exchange Key database (KEK)
The purpose of the KEK key is to establish trust between the OS (and each third-party application that requires communicating with the firmware) and the firmware. The private part of KEK (KEK_Priv) is used to update/modify the signature databases or sign binaries for valid execution. OEM enrolls the public part of the key (KEK_Pub) in the UEFI NV-RAM.
The KEK database can contain multiple keys of type x.509 or RSA-2048, any of which may perform the function of a KEK and is protected by the PK_Pub. Any update to the KEK database needs to be signed with the PK_Priv, and as such, it is usually the OEM that updates the contents of the KEK database via firmware updates, which are signed by the EK_Priv or Secure Firmware Update key, as it is known.
Though there can be multiple KEKs per platform, however mostly all the PC OEMs include
- The Microsoft Corporation KEK CA 2011 as KEK_Pub enables Microsoft to control the list of OS Bootloaders permitted by Secure Boot, update the Signature Databases to allow newer Windows versions and revoke bad images.
- An OEM-specific KEK that enables the OEM to update the signature databases as well
Thus with Secure Boot, Microsoft somehow controls the permitted OS that is allowed to boot on the platform. This is why, with Secure Boot enabled, you cannot have a dual boot system if the 2nd OS bootloader is custom-signed or unsigned or not signed by Microsoft.
This is why many Linux distros fail to boot with Secure Boot enabled since it fails to verify its bootloader signature. However, Microsoft offers a service to sign custom bootloaders at https://sysdev.microsoft.com. Ubuntu and Fedora’s bootloaders are signed using this process and some other Linux shims and pre-loaders, thereby enabling them for Secure Boot.
Purpose of Signature Database (db)
This UEFI Secure variable stores a set of trusted keys, signatures, or hashes. The signature of an EFI binary (or SHA265 hash if no signature is present) is compared with the entries stored in this variable and is allowed to execute if only a match is found. The contents of this UEFI variable can only be updated by signing the authentication descriptor with the KEK_Priv, provided the KEK_Pub is present in the KEK_db.
Purpose of Forbidden Signature Database (dbx)
This UEFI Secure variable is used to store a set of keys, signatures or hashes that are known to be malicious or untrusted. The signature of an EFI binary (or SHA265 hash if no signature is present) is compared with the entries stored in this variable, and if a match is found, it is denied execution. EFI binaries that are unsigned and don’t have a hash in either db or dbx are automatically refused execution. Just like db, the contents of this UEFI variable can only be updated by signing the authentication descriptor with the KEK_Priv, provided the KEK_Pub is present in the KEK_db.
Checking Windows 10 UEFI Secure Boot Variables present in your system…
I used a tool called Insyde® UEFI Secure Boot Checkup to check the UEFI Secure Variable contents. The program is for diagnosis only and cannot make any changes to the Secure Boot configuration.
As can be seen, the PK is from Lenovo, which is the OEM for my system.
There are two KEK present—one from OEM (Lenovo) and one from Microsoft (Microsoft Corporation KEK CA 2011), which allows both updating/modifying the signature database (db) and revoking it (dbx).
Signature Database (db) has 4 certs –
- 3 are vendor-specific (from Lenovo), allowing the UEFI Firmware to initialize with Lenovo UEFI applications and Lenovo root drivers.
- The Microsoft Windows Production PCA 2011 cert, which is used by Microsoft to sign the EFI Windows Boot Manager (bootmgfw.efi) and EFI Windows Boot Loader (winload.efi)
However, the signature database doesn’t include the certificate Microsoft Corporation UEFI CA 2011 which is used by Microsoft to sign OS loaders of other vendors.
As such my system won’t permit any OS from 3rd party vendor to boot with Secure Boot enabled.
What if you need to run a custom OS or a Linux distro?
The options you have are
- Disable Secure Boot (Not really recommended)
- Sign the custom OS bootloader with Microsoft Secure Boot signing service (Check the presence of Microsoft Corporation UEFI CA 2011 in the allowed signature db, else this won’t work either)
- Clear UEFI Secure Variables to reset all values and add your custom keys (For highly technical users only)
This is to update/modify the Signature Database (db) contents, which require the KEK_Priv, which should match with a KEK_Pub as stored in the KEK database. Now, updating/modifying the KEK database requires the PK_Priv, which is owned by the OEM and can’t be retrievable by an individual.
As per UEFI specification version 2.7, section 31.3.2, clearing the Platform Key is possible via
- An individual cannot sign a new PK with the existing PK (PK_Priv). If the existing PK is compromised, OEMs use firmware update capsules to update the platform with a new PK.
- You can use the UEFI Setup Utilities to load UEFI into setup mode, but this feature relies on firmware support and is not universal.
- Using special tools to clear the UEFI Secure Variable contents. Intel has SYSCFG for this, which works on Intel-based platforms. Or, if you are comfortable with Linux, you can use the tools to clear the Secure Boot variables and add your own to it.
Windows 10 UEFI Secure Boot.. To be contd…
If you have read this far, you should have a fair idea and knowledge regarding UEFI Secure Boot and how it helps to secure the Windows 10 pre-boot phase.
In my next article of this series, I will continue with the Windows Kernel Initialization phase, explaining the role of Windows Trusted Boot/Code Integrity and ELAM, which benefits from the foundation as provided by UEFI Secure Boot.
Resources
- Understanding Device Health Attestation Intune Device Compliance Check
- Secure Boot – Microsoft Documents
- Geeking out with UEFI – Michael Niehaus
- Working with UEFI variables from PowerShell
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He is awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site MDM Tech Space at https://joymalya.com
The images are not visible. Can you please check if its the issue with the page.
We are looking into it. Keep you posted.
The images are still not visible
Great article, would be awesome with some pictures 🙂