通过

Diving into Secure Boot

  • 项目

Hello

It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today we will dive into Secure Boot technology.

Secure Boot is a feature of UEFI (Unified Extensible Firmware Interface) that ensures that each component loaded during the boot process is digitally signed and validated. Secure boot makes sure that your PC boots using only software that is trusted by the PC manufacturer or the user.

Secure boot support has been added in Windows 8 and requires UEFI specification 2.3.1 Errata C. It is not supported on BIOS platforms or UEFI with CSM mode enabled (Compatibility Support Module). So booting your PC only in pure UEFI mode will give you an option to enable Secure Boot.

Standard Boot

In standard boot process when we turn on computer, it passes POST (Power On Self-Test) and BIOS is initialized. Then the hardware is initialized and its firmware is loaded to the memory. After that the bootloader is called. The problem is that firmware, bootloader and other components loaded at this stage are not verified. So attacker which has access to our machine could temper with these components and replace bootloader with malicious one. This malware could be a rootkit or a bootkit which are almost impossible to detect using common AV software and mostly are invisible to Operating System.

Secure Boot

In Secure Boot process, after passing the POST test, UEFI firmware is loaded. This firmware is responsible for verification of components before they are loaded. There are different components during the boot process that are being verified including: UEFI drivers, UEFI shell applications, boot manager, UEFI bootloaders etc. For simplicity we will refer only to bootloader in this article.

If your operating system doesn’t pass the validation you might see an error: “Invalid signature detected. Check Secure Boot Policy in Setup”, more general “Boot failure” or no error at all (silent fallback to next boot media: CD/USB/network) .

This validation is done against trusted certificates or hashes present in UEFI firmware. These certificates and hashes have to establish some hierarchy of trust by:

PK – Platform Key represents the root of trust and is used to protect the KEK (Key Exchange Key) database. The platform vendor puts public portion of the Platform Key (PK) into UEFI Firmware during manufacturing. Its private portion stays with the vendor. When updating the PK, the new PK certificate must be signed with the old one.

KEK - The KEK (Key Exchange Key) database contains trusted certificates that are allowed to modify the Allowed Signature database (db), Disallowed Signature database (dbx) or Timestamp signature database (dbt) described below. KEK database usually contains certificates of Operating System Vendor (OSV) and is secured by the Platform Key (PK).

Hashes and signatures used to verify bootloaders and other pre-boot components are stored in 3 different databases:

DB - EFI_IMAGE_SECURITY_DATABASE (d719b2cb-3d3a-4596-a3bc-dad00e67656f:db)

Allowed Signature database - this database may contain Certification Authority certificates or their hashes that were used to generate code-signing certificates used to sign bootloader and other pre-boot components. If the bootloader is signed by any of certificates chaining to the CA certificate present in this database, it is permitted to execute. In this database we may also find explicit SHA2 hashes of the bootloader images.

DBX - EFI_IMAGE_SECURITY_DATABASE1 (d719b2cb-3d3a-4596-a3bc-dad00e67656f:dbx)

Disallowed Signature database - this database may contain the hash of a specific binary, an X.509 certificate, or the hash of a certificate that were compromised and/or revoked. If the bootloader is signed by any certificate present in this database, or its hash is present here, it will be denied from execution. See KB 2871690 for list of recently revoked image hashes.

DBT - EFI_IMAGE_SECURITY_DATABASE2 (d719b2cb-3d3a-4596-a3bc-dad00e67656f:dbt)

This is secure boot timestamp signature database. Contains timestamping certificates using when signing bootloader images.

All of these 3 databases are locked from editing by Key Exchange Key (KEK).

So if we take a look at the typical UEFI content, we can see one Platform Key (PK) from the vendor, 2 Key Exchange Keys (KEK) from Microsoft and vendor, 3 certificates in the DB databases (allowed signatures) and some hashes of compromised images in the DBX database (disallowed signatures):

In the allowed signatures database (DB), we can see few keys (certificates) that are usually guaranteed to be installed on every computer:

Microsoft Windows Production PCA 2011 – signs certificates used to sign binaries of Windows Operating System (like Windows boot manager, bootloader)

Microsoft Corporation UEFI CA 2011 – signs certificates used to sign binaries of 3rd party vendors (explained later)

ThinkPad Product CA 2012 – vendor specific key, signs certificates used to sign its own bootloaders. Since Lenovo owns this platform by having PK (Platform Key) they can put also their own keys into UEFI.

So to be clear: the only usage of PK is to update KEK (or to update PK itself). Because of the fact PK is owned by vendor Microsoft can't update KEK or PK but can update DB, DBX and DBT anywhere.

Microsoft Bootloaders:

Windows UEFI bootloader bootmgfw.efi (copy is present in C:\Windows\Boot\EFI) is signed by code-signing certificate issued by the Microsoft Corporation UEFI CA 2011, which is present in the allowed signature database (DB) on all machines. That’s why it is considered as trusted by computers.

clip_image005

Non Microsoft Bootloaders:

If you want to run your custom bootloader there are few options:

  1. Disable secure boot

It is not recommended practice as boot images will not be verified anymore which puts your platform at risk. For logo-certified Windows RT PCs, Secure Boot is required to be configured so that it cannot be disabled.

  1. Sign your bootloader with Microsoft certificate

Because of lack of industry-standard body to manage the signing of Secure Boot keys Microsoft offers service to sign custom bootloaders at https://sysdev.microsoft.com. As a UEFI or OSV vendor, first you have to register your company on that portal, sign special agreement with Microsoft, verify your identity and then upload your custom bootloader to the website. After binaries reaches the Microsoft they are checked against malwares and malicious code. There are multiple phases of validation besides malware validation which I will not cover here.

clip_image006

Ubuntu and Fedora bootloaders were signed using this process. Bootloaders under the GPL license will not be signed as they require revealing private keys used for signing. Some of the Linux shims and pre-loaders have been also signed in this way.

  1. Sign your bootloader with your own key.

When you sign bootloader with your own key you need to add the hash of the image, certificate hash or CA certificate to the UEFI database. In order to add this key to the allowed signature database (db) you need to own the KEK key (owned by the Operating System vendor). Updating the KEK database is also not possible because it is protected by the PK (platform key – owned by the Platform Vendor). So the only solution would be to clear the platform key (PK) and import your own. Then generate and add to UEFI your own KEK and certificate used to sign the custom bootloader.

clip_image007

We could clear all keys, instead of only PK (like in above screenshot from Surface) and import our own, but it would prevent Windows operating system to run in the future unless default keys are restored.

PowerShell

In Windows you can use PowerShell to verify if Secure Boot is enabled:

Confirm-SecureBootUEFI

clip_image008

You can also export PEK, KEK database, DB, DBX to the ESL format (EFI Signature List):

Get-SecureBootUEFI -name <UEFI variable> -outputFilePath <path>

clip_image009

To summarize: Secure boot as an industry standard that has been developed to perform boot components’ image authentication and validation before execution. It reduces the risk of pre-boot malware attacks such as rootkits or bootkits and injection of malicious code in pre-boot phase. Secure Boot on most platforms can be disabled in UEFI settings and doesn’t restrict you from running alternative operating systems.

Comments

  • Anonymous
    May 27, 2016
    For security purposes upon booting you pc or while browing the web, it is important to know the necessities for security software such as ESET Antivirus and the likes. It is really helpful to keep the files secured from malwares and such. -Henry Price, Software Developer, V&R Trading Corporation
  • Anonymous
    January 23, 2017
    I remember a while back Ubuntu had Microsoft sign a bootloader, which did not in turn verify the signatures of what came after it, effectively compromising the Secure Boot process. Did Microsoft revoke that bootloader somehow, or is the only way to protect against it to remove the Microsoft Corporation UEFI CA 2011 from the sytem? Thank you!
  • Anonymous
    January 24, 2017
    @ Tom I don't recall this particular situation (Ubuntu) but Microsoft revokes compromised certificates and images whenever it is required. See content of KB 2871690 as an example.
  • Anonymous
    May 28, 2019
    Hi RafalI'm also trying to configure secure boot on Windows, I want to know which file has been signed by Lenovo's certificate that it can pass the UEFI secure boot authentication and Microsoft's authentication process. I tried to sign bootx64.efi, bootmgr.efi, bootmgfw.efi and all fail with the error message : Your PC/Device need to be repaired, The digital signature for this file couldn’t be verified.Thank you!!!