Secure Boot

What It Is

Secure Boot is a UEFI feature that verifies the digital signature of every piece of code loaded during the boot process. If a bootloader, driver, or kernel hasn't been signed by a trusted key, the firmware refuses to run it.

The goal: prevent unauthorized code from running before the operating system's own security mechanisms are active. Without Secure Boot, malware could replace the bootloader, load before the OS, and hide itself from all OS-level detection (a "bootkit").

Why It Matters

The boot process is the most privileged time in a computer's lifecycle. Code that runs during boot has full access to everything -- it runs before the OS kernel, before the firewall, before antivirus, before any security boundaries exist. If you can control what runs at boot, you control the machine.

Secure Boot establishes a chain of trust: firmware verifies the bootloader, the bootloader verifies the kernel, and the kernel verifies its modules. Each link in the chain is verified before it gets to execute. Breaking any link stops the boot.

This is the same principle as HTTPS certificate validation: you trust the root CA, the root CA signed an intermediate, the intermediate signed the server cert, and you verify the chain before trusting the connection. Secure Boot does this for code instead of network connections.

How It Works

The Key Hierarchy

Secure Boot uses four key stores, all kept in UEFI NVRAM:

Platform Key (PK): The root of the Secure Boot trust chain. Exactly one PK per system. The PK owner (typically the hardware OEM) controls who can modify all other key databases. The PK itself is never used to sign boot binaries -- it only authorizes changes to the key databases below it.

Key Exchange Key (KEK): One or more CA certificates authorized to sign updates to the db and dbx databases. On a typical Windows machine, Microsoft has a KEK and the OEM has a KEK. When Microsoft publishes a dbx update (to revoke a vulnerable bootloader), they sign the update with their KEK, and the firmware verifies the KEK signature before accepting the change.

Signature Database (db): The allow list. Contains certificates and SHA-256 hashes of trusted boot binaries. A bootloader is allowed to execute if:

Its signature chains to a certificate in db, OR
Its exact hash appears in db

On most shipping machines, db contains Microsoft's "Windows UEFI CA" and "UEFI CA 2023" certificates. Linux distributions boot via a shim signed by Microsoft's UEFI CA.

Forbidden Signature Database (dbx): The block list. Contains certificates and hashes of known-bad binaries. dbx is checked first -- anything matching dbx is blocked regardless of what db says. This is how compromised bootloaders (known-vulnerable GRUB versions, the BlackLotus bootkit) are revoked without updating db.

The Verification Chain

Firmware (UEFI)
  |
  | Verifies signature against db/dbx
  v
Bootloader (shim, systemd-boot, Windows Boot Manager)
  |
  | Verifies next stage with its own embedded key
  v
Kernel or second-stage bootloader (GRUB, Linux kernel)
  |
  | Verifies modules/drivers with its own key
  v
Operating system running

Each stage is responsible for verifying the next one. The firmware only directly verifies the first stage. Everything after that is a chain -- if stage 1 is compromised but passes firmware verification, the chain is broken.

How Keys Get Into the Databases

This is the part that confuses most people. The key databases (PK, KEK, db, dbx) live in UEFI NVRAM on the motherboard. There are several ways to modify them, depending on who you are and what state the firmware is in:

From UEFI Setup (BIOS menu): Enter the firmware setup screen (usually Del, F2, or F12 during POST). Under the Security or Secure Boot section, most firmware provides options to: view enrolled keys, add certificates from a USB drive (DER or EFI Signature List format), delete keys, or enter Setup Mode (clears all keys). This is the manual, physical-access approach. FortrOS's provisioner does this programmatically during enrollment.

From the running OS (via UEFI Runtime Services): The OS can write to the key databases through /sys/firmware/efi/efivars/ on Linux. But writes are authenticated -- the firmware only accepts updates signed by the appropriate key:

Modifying db/dbx requires a signature from a KEK
Modifying KEK requires a signature from the PK
Modifying PK requires a signature from the current PK (or physical presence in Setup Mode)

This means: if you have the PK private key, you can remotely update the entire Secure Boot chain from the OS without touching UEFI Setup. FortrOS's provisioner holds the org's PK private key and uses it to enroll the org's KEK and db entries during provisioning. Subsequent key rotations happen through the OS via authenticated NVRAM writes -- no reboot to UEFI Setup needed.

Setup Mode (factory state): When no PK is enrolled, the firmware is in "Setup Mode" -- any key can be written without authentication. This is how the OEM initially populates the keys during manufacturing. Entering Setup Mode clears all keys and disables Secure Boot until a new PK is enrolled.

Enrolling Custom Keys

For a custom OS, there are four approaches:

1. Take over via Setup Mode: Enter UEFI Setup, clear all keys (enters Setup Mode), enroll your own PK, KEK, and db certificates from a USB drive or via the OS. You now control the entire chain. Downside: Windows and other OSes won't boot unless you also add their certificates to db. FortrOS does this for government/locked-down deployments.

2. Microsoft-signed shim: The shim bootloader is signed by Microsoft's UEFI CA (already in db on most machines). Shim contains your distribution's signing key and verifies the next stage (GRUB, systemd-boot). This is how Ubuntu, Fedora, and most distros boot with Secure Boot enabled out of the box.

3. Add your key to db alongside vendor keys: Use sbctl, KeyTool.efi, or authenticated NVRAM writes to add your signing certificate to db without removing the vendor's. Requires the KEK private key (to sign the db update) or doing it from Setup Mode. FortrOS does this for dual-boot or less restrictive deployments.

4. Machine Owner Key (MOK): Shim maintains its own separate key database in NVRAM. Users can enroll keys via mokutil and MokManager (a shim component) without touching the firmware's PK/KEK/db. The easiest path for personal use but requires shim as the first-stage bootloader.

How FortrOS Uses It

FortrOS uses Secure Boot to ensure that only org-signed code runs on org hardware:

The org CA signs the preboot UKI during the build process. The UKI contains the kernel, initramfs, and kernel command line in a single PE binary.
The org CA's signing certificate is enrolled in db during provisioning (either alongside Microsoft's certs or as the sole trusted key, depending on org policy).
The preboot verifies the next stage (the generation kernel) using the org CA's public key embedded in its initramfs. This extends the chain from firmware through the preboot and into the main OS.

The Secure Boot chain for FortrOS:

Firmware verifies preboot UKI (org CA cert in db)
  -> Preboot verifies generation image (org CA pubkey in initramfs)
    -> Generation kernel boots with verified configuration

This means:

A stolen device with Secure Boot enabled cannot boot unauthorized code
Revoking a generation's signing key (via dbx or by not signing it) prevents that generation from booting on any org hardware
The org controls the entire trust chain without depending on Microsoft's signing infrastructure

Alternatives

No Secure Boot: The firmware loads whatever is on the ESP without verification. Simple, compatible with everything, but no protection against bootkits or unauthorized OS loading. Appropriate for development environments and trusted physical locations.

Measured Boot (without Secure Boot): Instead of blocking unsigned code, the firmware measures (hashes) each boot component into TPM PCRs. The TPM then seals secrets (disk encryption keys) to specific PCR values. An unauthorized boot modifies the PCR values, and the TPM refuses to release the secrets. This doesn't prevent the unauthorized code from running -- it just prevents it from accessing sealed secrets. FortrOS uses measured boot alongside Secure Boot for defense in depth.

Verified Boot (ChromeOS): A more aggressive model where the firmware itself is open source (coreboot) with a hardware-protected read-only root of trust. Stronger than UEFI Secure Boot because the firmware is auditable, but requires hardware support.