Understanding UEFI Secure Boot and how it helps to secure the Windows 10 boot process

In traditional BIOS boot flow, as the system is powered on, the CPU initializes the firmware bootloader which loads the firmware (BIOS/UEFI) image which then loads and executes all the firmware drivers and OEM firmware applications. The firmware then triggers the pre-OS_bootloader which reads the Boot Configuration Data to locate the OS Bootloader and launch it.

This boot flow is very much susceptible to rootkits/bootkits which though appears to be legitimate but are actually malicious codes as these can create backdoors to an attacker and expose the system. Since rootkits/bootkits get executed prior to the OS Kernel loads, the OS remains unaware of their presence. This is a key security risk and concern for any organization.

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

• bootmgfw.efi will verify the signature of winload.exe and 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.

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

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 db)
• 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.

UEFI Secure Boot keys are explained below:

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.

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

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.

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.

To figure out how Secure Boot is configured in my 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 recommend)
• 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.

In my next article I will explain the process of Windows Trusted Boot which takes benefit from the platform as layed by Secure Boot.