Deep Dive on UEFI Secure Boot

1. Overview of UEFI and Secure Boot

UEFI (Unified Extensible Firmware Interface) is a modern firmware interface that replaces the legacy BIOS. One of its critical features is Secure Boot, which enhances platform security by ensuring only trusted software is executed during the boot process.

Secure Boot Objective

• Prevent the execution of unauthorized or malicious code during boot.
• Maintain the integrity of the operating system and firmware.
• Reduce risks from bootkits and rootkits.

---

2. How Secure Boot Works

End-to-End Workflow of Establishing Trusted Computing with UEFI Keys

To establish a secure boot chain, UEFI relies on a hierarchical system of cryptographic keys. Here's how each component contributes to trusted computing:

1. Platform Key (PK)
   • The PK is the root of trust and defines who controls the system firmware.
   • The entity holding the PK (typically OEM or IT admin) can update the KEK database.
   • Secure Boot can only be enabled or disabled with the correct PK.
2. Key Exchange Key (KEK)
   • KEK is a set of keys authorized to manage the contents of the db and dbx signature databases.
   • Managed by OS vendors (like Microsoft), enterprises, or administrators.
   • Allows acceptance of signed OS updates, bootloaders, and drivers.
3. db (Allowed Signature Database)
   • Contains public keys, certificates, and hashes of trusted bootloaders, OS kernels, and EFI apps.
   • Each boot stage is validated against entries in db.
   • OS vendor keys (e.g., Microsoft) are typically preloaded.
4. dbx (Revoked Signature Database)
   • Contains blacklisted keys, hashes, or certificates known to be compromised.
   • Blocks execution of known vulnerable or malicious components.
5. MOK (Machine Owner Key)
   • Used primarily on Linux systems to allow user-added keys without modifying firmware db.
   • Works with Microsoft-signed shim bootloader and allows verification of custom-signed modules.
   • Useful for developers and enterprise IT to load custom kernel modules or bootloaders.

Boot Flow with Key Usage

1. Firmware Boot Start
   • UEFI firmware checks if Secure Boot is enabled.
   • Firmware validates bootloader (e.g., shim) using entries in db.
2. shim Bootloader (Linux-specific)
   • shim is signed by Microsoft and trusted by OEM db.
   • shim verifies GRUB or kernel using MOK or db.
3. GRUB / Kernel
   • GRUB or kernel is validated using MOK (via shim) or UEFI db.
   • Execution continues only if the signature is trusted.
4. Driver and Module Loading
   • Kernel modules must be signed and verified by keys in MOK or db.
   • Unsigned modules are blocked if Secure Boot is enforced.

Establishing Trust

• Trust begins with the Platform Key (PK), which controls KEK updates.
• KEK governs trusted entries in db/dbx.
• db authorizes known good code; dbx blacklists malicious or outdated code.
• MOK provides flexibility for local trust without changing firmware keys.

This layered key model ensures the entire boot process is authenticated, preventing unauthorized or malicious code from executing.

3. Configuring UEFI Secure Boot

Enabling Secure Boot

1. Enter UEFI firmware setup (usually via F2, Del, or similar during boot).
2. Locate Secure Boot settings.
3. Set Secure Boot mode to "Standard" (default keys) or "Custom" (custom keys).
4. Install or enroll Platform Key (PK).
5. Populate KEK, db, and dbx with required certificates/hashes.

Custom Key Enrollment

• Generate your own PK, KEK, and signing keys using OpenSSL or Microsoft tools.
• Used in enterprise environments for tighter control.
• Keys are enrolled using UEFI Key Management menus or tools like KeyTool.efi.

---

4. Security Benefits of Secure Boot

• Rootkit Prevention: Blocks unauthorized bootloaders that might install persistent malware.
• Trusted Boot Chain: Ensures every stage in the boot process is signed and verified.
• Firmware Tamper Detection: Prevents tampered UEFI binaries from executing.
• Revocation Support: dbx can blacklist known compromised components.

---

5. Common Attack Vectors and Vulnerabilities

Bypassing Secure Boot

• BootHole Attack: Exploited GRUB2 vulnerability via manipulated config files.
• Signed but Vulnerable Bootloaders: Older bootloaders with known exploits.
• PK Compromise: Breaks entire trust chain if leaked.

Misconfigurations

• Secure Boot disabled or set to "Audit Mode."
• Improper key handling, e.g., unsafe self-signed keys.
• Firmware bugs that bypass signature checks.

---

6. Introducing Custom Keys Securely

Steps for Secure Key Introduction

1. Generate PK, KEK, and signing certs on an air-gapped system.
2. Validate certificates format and trust chain.
3. Switch UEFI to Custom Mode.
4. Enroll keys using the UEFI menu or trusted tooling.
5. Sign bootloaders and drivers with the private signing key.
6. Lock down firmware post-configuration.

Best Practices

• Use HSM/TPM-backed key storage.
• Audit and rotate keys frequently.
• Keep dbx updated to revoke threats.
• Enable tamper-evident logging for audit trails.

Exploitation Possibilities

• Leaked keys can be used to sign malicious binaries.
• Insider threat: Enroll compromised keys intentionally.
• Downgrade attacks using old bootloaders not present in dbx.

---

7. What Are MOK Keys and How to Use Them

MOK (Machine Owner Key) Overview

MOK is a Linux mechanism (Ubuntu, Fedora, etc.) allowing users to manage custom keys outside the UEFI PK/KEK/db chain.

Purpose

• Install custom kernel modules or bootloaders.
• Enable flexibility for developers within Secure Boot constraints.

How MOK Works

• Shim bootloader (signed by Microsoft) loads GRUB or kernel verified against UEFI db or MOK.
• MOKs are enrolled through mokutil and a boot-time password UI.

Steps to Enroll a MOK Key

1. Generate a key pair:

   openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt -nodes -days 365

2. Sign the kernel module:

   sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.key ./MOK.crt <module.ko>

3. Import the key:

   sudo mokutil --import MOK.crt

4. Reboot and enter password via MOK Manager UI.
5. Verify with:

   mokutil --list-enrolled

Security Considerations

• MOK enrollment is less privileged but must be monitored.
• Private keys must be protected.
• Track changes to enrolled MOKs in multi-user environments.

---

8. Who Signs Drivers and How Keys Are Managed

Driver Signing Authorities

• Windows: Microsoft signs through WHQL validation.
• Linux: Signed by distro maintainers or via MOKs by sysadmins.

Key Maintenance

• Microsoft’s keys populate db and KEK.
• OEMs or enterprises can add their own keys in custom mode.
• Linux admins manage via shim and key enrollment tools.

Key Revocation Process

• dbx stores revoked keys or binaries.
• Updates published via Windows Update or firmware tools.
• Revocation ensures tampered or vulnerable binaries are blocked.

Challenges

• Devices not updated stay vulnerable.
• Revoking broad certificates can break compatibility.
• Needs balance between security and usability.

---

9. Recent Developments in Secure Boot

Key Events and Responses

• Baton Drop Attack (2023): A sophisticated Secure Boot bypass discovered by Eclypsium. This vulnerability exploited a signed but insecure bootloader to elevate privileges during boot. It allowed unsigned and potentially malicious code to execute even when Secure Boot was enabled. Microsoft responded with dbx updates and advisories to block vulnerable binaries.
• BootHole Disclosure (2020): Led to mass revocation and dbx updates by Microsoft. It exploited configuration files in GRUB2 to load unsigned code.
• BlackLotus Bootkit: An advanced malware that used a vulnerable signed bootloader to install itself before the OS, bypassing Secure Boot. BlackLotus leveraged signed binaries no longer considered secure but not yet in dbx.
• Kaspersky MosaicRegressor (2020): An espionage tool that used malicious UEFI firmware implants. It showed how attackers could persist below the OS layer, bypassing protections including Secure Boot if firmware was compromised.
• Microsoft dbx Updates: Ongoing efforts to maintain a current revocation list.
• Linux Shim Updates: Newer versions with stronger protections are now required to be signed.
• Firmware Vulnerability Research: Projects like CHIPSEC and fwupd continuously test firmware resilience.

Enhanced Secure Boot (ESB)

• Proposed improvements include measuring and logging boot metrics via TPM.
• Tighter integration with OS-level security (e.g., Measured Boot in Windows).

---

10. Conclusion

UEFI Secure Boot is a cornerstone in modern platform security. When properly configured and managed, it significantly raises the bar against low-level attacks. However, it is not foolproof. Security depends on:

• Proper configuration,
• Strong key management,
• Staying current with firmware and revocation updates.

Enterprises introducing custom keys must follow rigorous procedures to avoid inadvertently creating new attack surfaces.

Maintaining trust in the Secure Boot process is essential, and ongoing community and vendor efforts are required to adapt to new threats.