UEFI Secure Boot

Secure Boot Overview

Secure boot is a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). When the PC starts, the firmware checks the signature of each piece of boot software, including UEFI firmware drivers (also known as Option ROMs), EFI applications, and the operating system. If the signatures are valid, the PC boots, and the firmware gives control to the operating system.

Secure Boot is a technology where the system firmware checks that the system boot loader is signed with a cryptographic key authorized by a database contained in the firmware. With adequate signature verification in the next-stage boot loader(s), kernel, and, potentially, user space, it is possible to prevent the execution of unsigned code.

Secure Boot is a form of Verified Booting. Boot path validation is also part of other technologies such as Trusted Boot. Boot path validation is independent of secure storage of cryptographic keys and remote attestation.
The OEM can use instructions from the firmware manufacturer to create Secure boot keys and to store them in the PC firmware. When you add UEFI drivers, you'll also need to make sure these are signed and included in the Secure Boot database.

UEFI Secure Boot
UEFI Secure Boot is the boot path validation component of the UEFI specification (Unified Extensible Firmware Interface) as of version 2.3. Roughly speaking, it specifies the following:
- a programming interface for cryptographically protected UEFI variables in non-volatile storage,
- how the trusted X.509 root certificates are stored in UEFI variables,
- validation of UEFI applications (boot loaders and drivers) using AuthentiCode signatures embedded in these applications, and
- procedures to revoke known-bad certificates and application hashes.
UEFI Secure Boot does not require specialized hardware, apart from non-volatile (flash) storage which can be switched from read-write mode to read-only mode during system boot. This storage has to be used to store the UEFI implementation itself and some of the protected UEFI variables (including the trusted root certificate store).
From a user point of view, a system which has enabled UEFI Secure Boot and which is confronted with a tampered boot path simply stops working until UEFI Secure Boot is disabled or a signed next-stage boot loader is available on boot media. “Typical error message from UEFI Secure Boot” shows a typical error message.) Similarly, operating system installers without a cryptographically valid signature do not run and result in an error message. Users are not offered a way to override the boot loader decision to reject the signature, unlike the similar scenario with web server certificates. No certificate issuer information is provided to the user.

Typical error message from UEFI Secure Boot
UEFI Secure Boot does not prevent the installation or removal of second-stage boot loaders or require explicit user confirmation of such changes. Signatures are verified during booting, and not when the boot loader is installed or updated. Therefore, UEFI Secure Boot does not stop boot path manipulations. It only prevents the system from executing a modified boot path once such a modification has occurred, and simplifies their detection.
UEFI Secure Boot is currently only generally enabled on client devices, and is currently not recommended for deployment on server machines. It is expected that server technology will enable Secure Boot at a future date.

Secure boot requirements :
In order to support Secure boot, you must provide the following.

Signature Databases and Keys
Before the PC is deployed, you as the OEM store the Secure Boot databases on the PC. This includes the signature database (db), revoked signatures database (dbx), and Key Enrollment Key database (KEK). These databases are stored on the firmware nonvolatile RAM (NV-RAM) at manufacturing time.
The signature database (db) and the revoked signatures database (dbx) list the signers or image hashes of UEFI applications, operating system loaders (such as the Microsoft Operating System Loader, or Boot Manager), and UEFI drivers that can be loaded on the device. The revoked list contains items that are no longer trusted and may not be loaded. If an image hash is in both databases, the revoked signatures database (dbx) takes precedent.
The Key Enrollment Key database (KEK) is a separate database of signing keys that can be used to update the signature database and revoked signatures database. Microsoft requires a specified key to be included in the KEK database so that in the future Microsoft can add new operating systems to the signature database or add known bad images to the revoked signatures database.
After these databases have been added, and after final firmware validation and testing, the OEM locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, and then generates a platform key (PK). The PK can be used to sign updates to the KEK or to turn off Secure Boot.
You should contact your firmware manufacturer for tools and assistance in creating these databases.

Boot sequence
1. After the PC is turned on, the signature databases are each checked against the platform key.
2. If the firmware is not trusted, the UEFI firmware must initiate OEM-specific recovery to restore trusted firmware.
3. If there is a problem with Windows Boot Manager, the firmware will attempt to boot a backup copy of Windows Boot Manager. If this also fails, the firmware must initiate OEM-specific remediation.
4. After Windows Boot Manager has started running, if there is a problem with the drivers or NTOS kernel, Windows Recovery Environment (Windows RE) is loaded so that these drivers or the kernel image can be recovered.
5. Windows loads antimalware software.
6. Windows loads other kernel drivers and initializes the user mode processes.