How Does Secure Boot Verify Signatures to Block Rootkits?

Secure Boot is a firmware-level security standard in classical computing that prevents unauthorized code, such as bootkits and kernel-level rootkits, from running during system startup. It achieves this by using asymmetric cryptography to verify the digital signatures of bootloaders, operating system kernels, and critical drivers before executing them. If any component fails verification or has been tampered with, the firmware halts the boot process.

The Chain of Trust and Firmware Roots

In a classical computing system using Unified Extensible Firmware Interface (UEFI), security begins with an immutable root of trust stored in the motherboard's firmware. This firmware contains a set of cryptographic keys stored in non-volatile memory:

  • Platform Key (PK): The top-level key that establishes trust between the platform owner and the firmware.
  • Key Exchange Key (KEK): Keys used to update the signature databases.
  • Signature Database (db): A whitelist of trusted public keys and cryptographic hashes for approved bootloaders and OS components.
  • Forbidden Signature Database (dbx): A blacklist of revoked certificates and known malicious hashes.

When the computer powers on, the UEFI firmware initializes hardware and prepares to load the first-stage bootloader. Because the firmware itself is trusted, it acts as the anchor for a chain of trust that extends to every subsequent piece of software loaded into memory.

How Cryptographic Signature Verification Works

To verify a bootloader or OS kernel, Secure Boot relies on asymmetric (public-key) cryptography, typically using algorithms like RSA or ECDSA, paired with a cryptographic hash function such as SHA-256.

When a software vendor compiles a bootloader or kernel, they compute a cryptographic hash \(H(m)\) of the binary file \(m\). They then sign this hash using their private key \(K_{\text{priv}}\) to produce a digital signature \(S\):

\[S = \text{Sign}(K_{\text{priv}}, H(m))\]

This signature is embedded directly into the Portable Executable (PE) header of the EFI binary or kernel image.

During the boot process, the UEFI firmware performs the following steps before executing the binary:

  1. Hash Computation: The firmware reads the binary from disk and computes a fresh hash \(H'(m)\) using the same algorithm.
  2. Database Lookup: It checks the dbx database first to ensure the binary's hash or signing certificate has not been revoked. It then locates the corresponding public key \(K_{\text{pub}}\) in the db database.
  3. Signature Decryption and Comparison: Using the public key, the firmware verifies the signature \(S\) to recover the original signed hash and compares it against \(H'(m)\).

If \(H'(m)\) matches the verified hash and the certificate is trusted, the firmware transfers execution control to the bootloader. If even a single bit of the binary was altered by a rootkit, \(H'(m)\) will not match, and execution is blocked.

Extending Verification to the OS Kernel

The initial bootloader, such as GRUB or the Windows Boot Manager, is responsible for loading the operating system kernel. To maintain the chain of trust, the bootloader must also verify the kernel and any early-load drivers before they run.

In Linux environments, a small signed binary called shim is often used as the first-stage bootloader. shim is signed by a widely trusted authority (such as Microsoft's UEFI CA) so it can pass initial UEFI checks. Once running, shim uses its own embedded keys or Machine Owner Keys (MOK) to verify the next-stage bootloader (like GRUB) and the Linux kernel. In turn, the kernel enforces signature checks on loadable kernel modules.

Blocking Rootkits and Bootkits

Bootkits and kernel-level rootkits attempt to gain persistent, high-privilege access by modifying the Master Boot Record, EFI System Partition binaries, or the OS kernel itself. Because these modifications alter the binary file, they invalidate the original digital signature. An attacker cannot generate a valid new signature without possessing the vendor's private key.

By enforcing strict signature verification at every handoff—from UEFI firmware to bootloader, and from bootloader to OS kernel—Secure Boot ensures that only authentic, untampered code executes during startup, effectively neutralizing persistence mechanisms used by rootkits.