"Secure Boot"
What's up with Secure Boot
Secure boot was implemented in the release of Windows 8 in 2012. Microsoft introduced digitally signed kernel files for Windows PE, Windows RT, Windows 8, and Windows Server 2012.
With the release of Windows 11 in 2021, Secure Boot became a mandatory requirement in PC systems preloaded with Windows 11.
Secure Boot is one feature of the Unified Extensible Firmware Interface (UEFI) 2.3.1 specification (Errata C). The feature defines an entirely new interface between operating system and firmware/BIOS.
When enabled and fully configured, Secure Boot helps a computer resist attacks and infection from malware. Secure Boot detects tampering with boot loaders, key operating system files, and unauthorized option ROMs by validating their digital signatures.
After Secure Boot is enabled and configured, only software or firmware signed with approved keys are allowed to execute. Conversely, software signed with blacklisted keys are disallowed from executing.
Secure Boot is split into several pieces and stages.
db, the “signature database.” Entries here (typically certificates) determine what EFI executables are allowed to run on the device. So this is an “allow” list.
dbx, the “forbidden signatures database.” Entries here are typically SHA256 hashes of specific UEFI binaries, i.e. those things that were signed by a certificate in the “db” list but later found to be bad (e.g. having a security vulnerability that compromises the firmware). So this is a “block” list.
kek, the “key exchange key.” This specifies who is able to update the signature database (the “db” and “dbx” keys). Interestingly, any UEFI binaries signed by the “kek” key can also boot on the device. Microsoft's certificate will be stored here.
pk, the “platform key.” The “pk” variable contains a single certificate that controls access to the “kek” and “db” variables. If this value is cleared, it effectively turns off Secure Boot (putting the device in setup mode). For example, if the manufacturer of the hardware is Dell, then their certificate will be stored here.
For Linux systems, a special boot loader Shim created by Matthew Garrett is used to integrate with the Secure Boot setup. It manages its own certificates. Ubuntu, Red Hat, SUSE, and Debian generate their own versions of Shim that include certificates issued by their companies.
Verisign/Symantec for a fee will digitally signs the Shim bootloader on behalf of Microsoft that the UEFI firmware will permit the loading of the Shim. Once Shim is loaded, it operates independently of the Microsoft verification chain. Shim has built-in certificate management that lets the owner of the computer store certificates called machine owner keys (MOKs).
Shim lets large distributors such as Ubuntu, SUSE, and Red Hat win back control of hardware. Using the Distribution certificate stored in Shim, The Distribution sign the GRUB 2 bootloader. The firmware boots Shim, Shim boots GRUB 2, and GRUB 2 boots the operating system.
A Machine Owner Key (MOK) is a type of user generated key that is used to “sign," or authenticate as trustworthy, an Extensible Firmware Interface (EFI) binary. MOK gives you ownership of the boot process by allowing you to run locally-compiled kernels, kernel modules or boot loaders not delivered with the Linux distribution. This means that to use custom kernel or kernel modules, A public MOK needs to be enrolled and the private MOK is used to sign the custom kernel and kernel modules.