This article is part 1 (Windows 10 UEFI Secure Boot) of a new Windows series through which I will explain the in-built security measures implemented in Windows 10 to secure the OS boot phases to ensure integrity of the OS platform for corporate use case.
In my previous article titled “Understanding Device Health Attestation Intune Device Compliance Check” I talked briefly about Secure Boot, Code Integrity and TPM Boot Measurement. If you have not read that yet, I would recommend to give it a read first.
In this post, I will be taking you through UEFI Secure Boot – how it helps to protect the Windows Pre-Boot phase. So lets 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 it is 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 components of the system and detect if 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, which in turn loads the OS kernel to the RAM and the Kernel takes over from here.
Prior to Windows 10, it was post Kernel initialization when Windows Defender service used to start – the native anti-malware shipped with Windows OS.
Thus in the traditional or legacy boot flow, there is no security measure implemented at any stage to check against corrupt or malicious code (rootkits/bootkits) and stop them from getting executed during the boot flow.
As such, boot parameters can be easily modified to run malicious code during the boot flow which can result 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 improves the scenario?
With Windows 10, Microsoft introduced a number of security features built-in to the OS to deal with the above and protect the Windows boot flow.
- Windows Trusted Boot
- Early Launch Anti-Malware driver
- Windows Measured Boot (TPM dependancy for health attestation)
- Device Guard
- Credential Guard
- Widows Defender Appliction Guard
But the feature which forms the foundation for a secure Windows platform is Secure Boot – the focus of this article.
Enter Windows 10 UEFI Secure Boot
Windows 10 UEFI Secure Boot, an UEFI feature as per specification 2.3.1 errata C, helps to secure the Windows pre-boot phase mitigating the risks against rootkits and bootkits.
For an UEFI system, as its starts, it first verifies if 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 it is trusted to be executed.
Let’s go through the same boot flow again, but this time with 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 signature of the UEFI boot loader provided by SoC (System on Chip) vendor and triggers it.
- The UEFI Boot Loader verifies the signature of 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 if this also fails, the UEFI firmware initiate 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 measurment value, Bitlocker will automatically unlock the OS drive for bootmgfw.efi to verify the signature of winload.efi before passing control to it.
In the event of any problem arising 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 jurisdiction. Though it’s jurisdiction ends, but not its role as it lays the foundation of Code Integrity check which will continue to check the Kernel Boot Phase of the Windows OS.
Secure Boot Flow Schema
Since all the EFI components are verified for trust before execution creating a chain of trust, this helps to reduce rootkit/bootkit risks as if the signature/hash doesn’t matches the UEFI signature database, it will be prevented from getting executed eliminating the risk.
Secure Boot protected flow for loading OS Bootloader is schematically represented below
Secure Boot is not supported on legacy BIOS platforms or UEFI with Compatibility Support Module (CSM) mode enabled. It is only available in pure UEFI mode.
Windows 10 UEFI Secure Boot Internals
It is based on Public Key Cryptography to authenticate code before allowed to execute. Below is a representaion of the UEFI Secure variables as per 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 to the UEFI NVRAM during manufacturing as UEFI Secure Variables as per section 7.2 of 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.
It requires each EFI component to be digitally signed by the OEM using 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 matches 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)
The purpose of this key is to establish 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 as 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 a trust between the OS (and each 3rd party application that requires to communicate 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) to 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 which 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 which enables Microsoft to control the list of OS Bootloaders permitted by Secure Boot and also update the Signature Databases to allow newer Windows versions or revoke bad images.
- an OEM specific KEK which 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 the reason why with Secure Boot enabled, you cannot have a dual boot system if the 2nd OS bootloader is custom signed or unsigned or is 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 bootloaders are signed using this process as well as some other Linux shims and pre-loaders thereby enabling them for Secure Boot.
Purpose of Signature Database (db)
This UEFI Secure variable is used to store a set of keys, signatures or hashes which are trusted. The signature of an EFI binary (or SHA265 hash if no signature is present) is compared with the entries stored in the 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 which 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 the this variable and if a match is found, it is denied execution. EFI binaries which are unsigned and doesn’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 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 is not capable of making any changes to the Secure Boot configuration.
As can be seen, the PK is from Lenovo which 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 to update/modify the signature database (db) and revoked signature database (dbx).
Signature Database (db) has 4 certs –
- 3 are vendor specific (from Lenovo) which allows for 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 includes 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 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 as to update/modify the Signature Database (db) contents requires to have the KEK_Priv which should match with a KEK_Pub as stored in the KEK database. Now updating/modifying the KEK database requires to have 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
- Signing a new PK with the existing PK (PK_Priv), which is not possible for an individual. This is used by OEM via firmware update capsules to update platform with a new PK if the existing PK is compromised by any means.
- Using the UEFI Setup Utilities to load UEFI in to 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 in Linux, you can use the efitools to clear the Secure Boot variables and add your own to it.
Ending? To be contd…
If you have read till this, you would now have a fair idea and knowledeg 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 takes benefit from the foundation as provided by UEFI Secure Boot.