This paper discusses how Secure Boot functions.

Abstract: before booting, the system BIOS launches a variety of code modules such as device firmware, diagnostics, and OS loaders. Secure Boot aims to distinguish trusted modules from untrusted modules. Before the system BIOS loads a module into memory, Secure Boot checks whether the module has authorization to execute. If a module does not have authorization, the system BIOS continues without loading or executing the module.

How does Secure Boot distinguish between trusted and untrusted modules? The Secure Boot policy, which the system administrator defines, specifies the rules for authorization. The policy contains keys and certificates for signed modules, and image digests for unsigned modules. Providers of pre-boot code modules sign the code with private keys, and the Secure Boot policy contains public keys needed to verify the digital signatures. Signature verification gives the system BIOS assurance that the module came from a trusted entity, and that other entities have not tampered with the module.

A Secure Boot policy consists of four components: the Platform Key (PK), the Key Exchange Key database (KEK), the Authorized Signature Database (db), and the Forbidden Signature Database (dbx). The system BIOS uses the first two components (PK and KEK) to verify changes to the Secure Boot policy itself. The last two components (db and dbx) help the system BIOS determine whether to execute a pre-boot image.