Operating SystemsSecure Boot

Secure Boot: Establishing Trust from Power-On

LevelAdvanced

Duration75 mins

TopicSecure Boot

2 / 5

UEFI Secure Boot

The Industry Standard for Boot Security

UEFI Secure Boot represents the most widely deployed trusted boot implementation in history, protecting billions of personal computers, servers, and embedded systems worldwide. Born from industry collaboration between Microsoft, Intel, AMD, and dozens of hardware manufacturers, Secure Boot transformed boot security from a niche concern to a default-enabled feature on virtually every modern x86 and ARM system.

Understanding UEFI Secure Boot is not optional for systems security professionals—it's the mechanism that determines whether your operating system is trustworthy before a single line of kernel code executes. It's the barrier that boots rootkits must overcome, the checkpoint that prevents unauthorized operating systems from running, and the foundation upon which disk encryption, attestation, and measured boot technologies depend.

What You Will Learn

By the end of this page, you will understand UEFI Secure Boot from the ground up—the Platform Key hierarchy, signature databases, boot verification workflow, key enrollment procedures, and the complex ecosystem of trust that spans hardware manufacturers, operating system vendors, and end users. You'll be equipped to configure, troubleshoot, and secure Secure Boot deployments.

UEFI Foundation

Before examining Secure Boot specifically, we must understand the UEFI (Unified Extensible Firmware Interface) specification that provides its foundation.

From BIOS to UEFI

For decades, personal computers used the Basic Input/Output System (BIOS)—firmware dating back to the IBM PC era. BIOS had severe limitations:

16-bit real mode execution: Severely limited memory access and processing capability
1MB address space: Could only directly access the first megabyte of memory
No standardized boot process: Each vendor implemented boot differently
No security framework: No mechanism for verifying boot components
MBR limitations: Master Boot Record limited to 2TB disks, 4 primary partitions

UEFI replaced BIOS with a modern specification that runs in 32-bit or 64-bit mode from the start, supports arbitrarily large disks (GPT partitioning), provides a standardized driver model, and—critically—includes a complete security framework.

UEFI Key Capabilities for Security

•Authenticated Variables: UEFI variables that can only be modified with proper authentication (signatures). Used for storing keys and configuration.
•Driver Model: Standardized interface for loading firmware drivers, each of which can be individually verified.
•Protocol Architecture: Services exposed through discoverable protocols, enabling modular security implementations.
•GPT Partitioning: GUID Partition Table allows multiple EFI System Partitions and explicit boot partition identification.
•EFI System Partition: A FAT-formatted partition containing bootloaders, drivers, and firmware utilities—all potential verification targets.
•Runtime Services: Services that persist into OS execution, including access to authenticated variables for key management.

The UEFI Specification

UEFI is governed by the UEFI Forum, an industry consortium. The specification defines:

Boot Manager: How firmware locates and loads operating system bootloaders
Image Loading: How executable images (PE/COFF format on x86, ELF on some ARM) are loaded and authenticated
Authenticated Variables: How secure configuration is stored and protected
Secure Boot: The complete framework for boot-time image verification
Driver Signing: Requirements for option ROM and driver verification

Secure Boot is defined in Chapter 32 of the UEFI Specification. It's not a standalone technology but an integral part of the UEFI architecture, leveraging authenticated variables, the image loading protocol, and the driver model.

Implementation Reality

While UEFI is a specification, implementations vary:

Intel Reference Implementation (TianoCore/EDK II): Open-source reference used by many vendors
AMI (Aptio): Commercial implementation, dominant in consumer motherboards
Phoenix/Insyde: Commercial implementations for OEM systems
ARM UEFI implementations: Various implementations for ARM servers and embedded systems

Secure Boot behavior is largely consistent across implementations (the specification is detailed), but key enrollment, user interfaces, and recovery mechanisms differ.

The Secure Boot Key Hierarchy

UEFI Secure Boot implements a multi-tiered key hierarchy that balances security, manageability, and interoperability. Understanding this hierarchy is essential for both using and administering Secure Boot.

Converting Mermaid diagram...

Platform Key (PK)

The Platform Key sits at the top of the Secure Boot hierarchy. It represents ownership of the platform.

Singular: Only one Platform Key can exist at a time
Controls Everything: The PK holder can modify KEK, db, and dbx
Factory Default: OEMs typically ship with their own PK installed
Replaceable: Users can replace the PK to take full control (though this clears all other keys)

The PK is stored as an authenticated variable. Modifying it requires either:

A signature from the current PK (authenticated update)
Physical presence + clearing Secure Boot to Setup Mode (requires being physically present)

In practice: Most users never touch the PK. Enterprise environments may replace it to establish their own PKI. Security researchers replace it for custom key experiments.

platform_key.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Platform Key characteristics:
Variable Name: PK
Variable GUID:  8BE4DF61-93CA-11D2-AA0D-00E098032B8C (EFI_GLOBAL_VARIABLE)
Attributes:    NV + BS + RT + AT (Non-Volatile, Boot Service, Runtime, Authenticated)
Content:       EFI_SIGNATURE_LIST containing single EFI_SIGNATURE_DATA
Signature Type: Usually EFI_CERT_X509_GUID (X.509 certificate)
 
# To view the current PK on Linux:
mokutil --pk
 
# Example output:
[key 1]
SHA1 Fingerprint: 46:5b:2a:d0:...
Subject: C=US, O=Lenovo Ltd., CN=Lenovo Ltd. PK Certificate
 
# The PK is an X.509 certificate; its public key is used
# to verify signatures on KEK updates

Key Exchange Keys (KEK)

Key Exchange Keys represent entities authorized to update the signature databases (db and dbx). Unlike PK, multiple KEKs can coexist.

Multiple Allowed: A system can have KEKs from Microsoft, Linux vendors, and enterprise IT
Database Modification: KEK holders can add or remove entries in db and dbx
No Direct Boot Authorization: KEKs don't authorize bootable images directly—they manage who can authorize them
Managed by PK Owner: Adding/removing KEKs requires PK signature

Typical KEK population:

Microsoft Corporation KEK CA 2011 (allows Microsoft to update signature databases)
OEM KEK (allows manufacturer to push updates)
Enterprise KEK (allows IT department to enroll custom keys)

Signature Databases (db and dbx)

The signature databases are where the rubber meets the road—they contain the actual trust decisions.

db (Allowed Signatures Database)

Contains certificates and/or hashes that identify allowed boot components
An image passes verification if signed by a certificate in db OR its hash is in db
Typically contains Microsoft's UEFI CA certificate (signs Windows bootloader and many shims)
May contain vendor-specific certificates, individual hashes for specific tools

dbx (Forbidden Signatures Database)

Contains certificates and/or hashes of revoked or malicious components
Checked before db—if an image matches dbx, it's rejected regardless of db
Critical for revoking compromised bootloaders, blocking known malware
Updated via Windows Update, fwupd, or manual enrollment

dbt (Timestamp Database)

Less commonly used; contains timestamp authority certificates
Allows verification of signatures even after certificate expiration
Important for long-term key validity management

The db vs. dbx Priority

An image matching dbx is ALWAYS rejected, even if it also matches db. This is essential for security—a revoked bootloader with a valid signature must still be blocked. When troubleshooting boot failures, always check dbx first; a recent security update may have added new revocations.

Image Authentication Workflow

When Secure Boot is enabled, every PE/COFF image loaded by UEFI undergoes a rigorous authentication process. Understanding this workflow is essential for diagnosing boot failures and designing secure systems.

secure_boot_verification.pseudo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// UEFI Secure Boot Image Verification Algorithm
function verify_image(image_path) -> VerificationResult:
    image = load_image_from_disk(image_path)
    
    // Step 1: Parse the PE/COFF header
    pe_header = parse_pe_coff(image)
    if pe_header is invalid:
        return SECURITY_VIOLATION("Malformed PE/COFF image")
    
    // Step 2: Compute the image hash
    // Note: Hash excludes the signature data section itself
    authenticode_hash = compute_authenticode_hash(image, pe_header)
    
    // Step 3: Check forbidden database (dbx) by HASH
    for entry in dbx:
        if entry.type == HASH and entry.value == authenticode_hash:
            return SECURITY_VIOLATION("Image hash is in dbx (revoked)")
    
    // Step 4: Check allowed database (db) by HASH (direct whitelist)
    for entry in db:
        if entry.type == HASH and entry.value == authenticode_hash:
            return SUCCESS("Image hash explicitly allowed in db")
    
    // Step 5: Extract and parse signature (if present)
    signature = extract_authenticode_signature(image, pe_header)
    if signature is null:
        return SECURITY_VIOLATION("Image is unsigned")
    
    // Step 6: Verify signature cryptographically
    signer_cert = verify_signature_chain(signature, authenticode_hash)
    if signer_cert is null:
        return SECURITY_VIOLATION("Signature verification failed")
    
    // Step 7: Check if signer certificate is in dbx
    for entry in dbx:
        if entry.type == CERTIFICATE:
            if certificates_match(entry.value, signer_cert):
                return SECURITY_VIOLATION("Signer certificate revoked in dbx")
    
    // Step 8: Check if signer certificate (or issuer) is in db
    for entry in db:
        if entry.type == CERTIFICATE:
            if certificate_chain_contains(signer_cert, entry.value):
                return SUCCESS("Signed by trusted certificate in db")
    
    // No match found—image is not trusted
    return SECURITY_VIOLATION("No matching trust anchor in db")

Authenticode Hash Computation

Secure Boot uses Microsoft's Authenticode format for signatures. The hash computation specifically excludes the signature data itself (otherwise the signature would change the hash, creating a paradox). The algorithm:

Hash the DOS header
Hash the PE header up to (but not including) the checksum field
Skip the checksum field (4 bytes)
Hash from after checksum to the Certificate Table entry in the Optional Header Data Directory
Skip the Certificate Table entry (8 bytes)
Hash from after Certificate Table entry to the end of headers
Hash all sections in ascending order of PointerToRawData
Exclude the Certificate Table (signature data) from hashing

This careful construction allows the signature to be embedded in the image while still being verifiable.

Verification Outcomes and Their Meaning
Outcome	Condition	System Response
SUCCESS - Hash Match	Image hash found in db	Image loads and executes
SUCCESS - Signature Match	Valid signature by certificate in db	Image loads and executes
SECURITY_VIOLATION - Hash Revoked	Image hash found in dbx	Image rejected, error displayed
SECURITY_VIOLATION - Cert Revoked	Signing certificate in dbx	Image rejected, error displayed
SECURITY_VIOLATION - Unsigned	No Authenticode signature present	Image rejected unless db hash match
SECURITY_VIOLATION - Bad Signature	Signature cryptographically invalid	Image rejected, possible corruption
SECURITY_VIOLATION - Untrusted	Signer not in db, hash not in db	Image rejected, key not enrolled

Debugging Secure Boot Failures

When a boot fails with Secure Boot enabled, systematically check: (1) Is the image signed at all? (2) What certificate signed it? (3) Is that certificate in db? (4) Is the image hash or certificate in dbx? Tools like 'sbverify' (Linux) or 'signtool' (Windows) can extract and display signature information for diagnosis.

Microsoft's Role and the UEFI Ecosystem

Microsoft occupies a unique position in the Secure Boot ecosystem. As the primary force behind Secure Boot's development and the dominant desktop operating system vendor, Microsoft's certificates are present on virtually every Secure Boot-capable system.

Microsoft's Secure Boot Certificates

Microsoft operates two distinct Certificate Authorities for Secure Boot:

1. Microsoft Windows Production PCA 2011

Signs Windows bootloaders and kernel
Only used for Microsoft's own components
Present in db on all Windows-certified systems

2. Microsoft Corporation UEFI CA 2011

Signs third-party bootloaders (shim, GRUB, etc.)
Allows Linux distributions to boot on Secure Boot systems
Available to any software vendor through Microsoft's signing program

This dual-certificate approach means Microsoft can boot Windows with its own certificate while also allowing third-party operating systems to boot through the UEFI CA.

The Shim Bootloader: Linux's Bridge to Secure Boot

Linux distributions face a challenge: Microsoft controls signing for the UEFI CA, but Linux development is decentralized. The solution is the shim bootloader—a small first-stage bootloader signed by Microsoft that can then load distribution-signed components.

Secure Boot Verification    Shim Verification
         │                        │
         ▼                        ▼
┌─────────────────┐        ┌─────────────────┐
│   UEFI Firmware │        │      Shim       │
│                 │        │                 │
│ Verifies shim   │───────▶│ Verifies GRUB   │
│ using Microsoft │        │ using distro's  │
│ UEFI CA cert    │        │ embedded cert   │
└─────────────────┘        └─────────────────┘
                                  │
                                  ▼
                           ┌─────────────────┐
                           │      GRUB       │
                           │                 │
                           │ Verifies kernel │
                           │ using distro's  │
                           │ GPG keys        │
                           └─────────────────┘

Shim is:

Signed by Microsoft: Passes UEFI Secure Boot verification
Contains vendor certificate: Each distribution embeds their own public key
Implements MOK (Machine Owner Key): Allows users to enroll additional certificates
Minimal attack surface: Small, audited codebase

Major Linux distributions (Red Hat, Ubuntu, SUSE, Fedora) each have their own Microsoft-signed shim that contains their distribution's signing certificate.

Microsoft UEFI Signing Requirements

•Code Review: Submitted code undergoes security review before signing
•Malware Scanning: Binaries are scanned for known malware signatures
•Vendor Verification: Submitting organization must be verified
•Accountability Agreement: Vendors agree to terms holding them responsible for their code
•Revocation Cooperation: Vendors must cooperate if revocation becomes necessary
•EV Certificate Signing: Submissions must use Extended Validation code signing certificates

The Centralization Tradeoff

Microsoft's central role in Secure Boot signing is both a strength (consistent trust anchor, interoperability) and a concern (single point of control, dependency on one vendor). Users who require independence can replace the Platform Key and run entirely on their own PKI—but this requires technical expertise and breaks the 'just works' ecosystem compatibility.

Key Enrollment and Management

Managing Secure Boot keys is critical for enterprise deployments, custom operating system development, and security research. UEFI provides multiple mechanisms for key enrollment, each with different security implications.

Setup Mode: Full Key Access

When no Platform Key is enrolled, Secure Boot operates in Setup Mode. In this mode:

Secure Boot image verification is disabled
All authenticated variables (PK, KEK, db, dbx) can be modified without authentication
Firmware typically indicates Setup Mode status in setup utility
First enrollment of PK automatically exits Setup Mode

Entering Setup Mode:

Access UEFI firmware setup (usually Delete, F2, or F12 at boot)
Navigate to Security → Secure Boot
Select 'Clear Secure Boot Keys' or 'Reset to Setup Mode'
Confirm the action (may require physical presence verification)

Security Note: Setup Mode is inherently insecure. Systems in Setup Mode will boot unsigned code. This is acceptable during initial provisioning but should never be the production state.

Enrolling Custom Keys:

# Generate a new Platform Key
openssl req -new -x509 -newkey rsa:2048 -keyout PK.key -out PK.crt \
    -days 3650 -nodes -subj "/CN=My Platform Key/"

# Convert to UEFI signature list format
cert-to-efi-sig-list -g $(uuidgen) PK.crt PK.esl

# Sign the update with itself (self-signed PK)
sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth

# Enroll via firmware setup or efi-updatevar
efi-updatevar -f PK.auth PK

Secure Boot States and Transitions

UEFI Secure Boot operates in distinct states, with well-defined transitions between them. Understanding these states is essential for deployment and troubleshooting.

Converting Mermaid diagram...

Secure Boot State Comparison
State	PK Enrolled	Verification	Variable Protection	Use Case
Setup Mode	No	Disabled	None	Initial provisioning, key replacement
User Mode - Enabled	Yes	Active	Authenticated only	Normal secure operation
User Mode - Disabled	Yes	Disabled	Authenticated only	Troubleshooting, testing
Deployed Mode (optional)	Yes	Active	PK cannot be cleared	Locked-down systems

Setup Mode vs. Secure Boot Disabled

These are often confused but differ importantly:

Setup Mode (No PK enrolled):

Anyone can modify db/dbx without authentication
System is in provisioning state
Appropriate only during initial key enrollment

User Mode with Secure Boot Disabled:

PK is enrolled, keys are protected
Image verification is turned off
Authenticated variable updates still required
Useful for troubleshooting boot issues

The key distinction: In Setup Mode, an attacker with OS-level access could add their own key to db. In User Mode (even disabled), they would need the KEK private key to modify db.

Audit Mode (UEFI 2.6+)

Some newer firmware supports Audit Mode:

Verification is performed but failures are logged, not enforced
Useful for testing what would pass/fail before enabling
Helps identify signing gaps before lockdown

Deployed Mode (UEFI 2.5+)

Deployed Mode provides additional lockdown:

PK cannot be cleared even with physical presence
Prevents accidental or malicious return to Setup Mode
Typically used in highly secure or IoT deployments
Recovery requires firmware reflashing or factory service

Physical Presence Requirements

Clearing Secure Boot keys or entering Setup Mode requires 'physical presence'—typically a confirmation prompt in firmware setup or a specific physical action. This prevents remote attackers from disabling Secure Boot. However, physical access attacks (evil maid) must be mitigated by other means, such as TPM-bound encryption.

Common Challenges and Solutions

Deploying and maintaining Secure Boot involves navigating several common challenges. Here are the issues practitioners encounter most frequently, along with proven solutions.

Common Problems

•Custom kernel won't boot: Self-compiled kernels are unsigned
•Third-party drivers blocked: DKMS modules not signed
•Dual boot fails: Second OS lacks proper signing
•Old bootloader rejected: dbx update revoked old version
•Recovery media won't boot: USB recovery tools unsigned
•Option ROM blocked: PCIe expansion cards have unsigned firmware

Solutions

•Sign kernel with enrolled key: Use mokutil for MOK or sbsign for db key
•Configure DKMS with signing key: Auto-sign modules during build
•Use shim + MOK for second OS: Enroll distribution's certificate
•Update bootloader: Upgrade shim/GRUB to current signed version
•Enroll hash or remaster: Add hash to db or rebuild with signing
•Enroll option ROM cert: Add vendor certificate to db (security risk!)

Detailed Solution: Signing Custom Kernels

For development or custom systems, you need to sign your own kernels:

# 1. Generate a signing key pair
openssl req -new -x509 -newkey rsa:2048 \
    -keyout MOK.key -out MOK.crt \
    -nodes -days 3650 \
    -subj "/CN=My Kernel Signing Key/"

# 2. Enroll the certificate in MOK
sudo mokutil --import MOK.crt
# Enter a one-time password when prompted

# 3. Reboot and complete enrollment in MokManager
# Press any key at the 'Press any key to perform MOK management'
# Select 'Enroll MOK', 'Continue', 'Yes'
# Enter the password from step 2
# Reboot

# 4. Sign your kernel
sudo sbsign --key MOK.key --cert MOK.crt \
    /boot/vmlinuz-custom \
    --output /boot/vmlinuz-custom.signed

# 5. Update bootloader to use signed kernel
sudo update-grub  # or manually edit boot entry

Detailed Solution: Signing Kernel Modules (DKMS)

Third-party kernel modules (NVIDIA, VirtualBox, etc.) need signing:

# 1. Create signing key (same as kernel signing)
openssl req -new -x509 -newkey rsa:2048 \
    -keyout /root/module-signing/MOK.key \
    -out /root/module-signing/MOK.crt \
    -nodes -days 3650 \
    -subj "/CN=Module Signing Key/"

# 2. Enroll in MOK (same as above)
sudo mokutil --import /root/module-signing/MOK.crt

# 3. Configure DKMS to use your key
# /etc/dkms/framework.conf:
modprobe_on_install="false"
sign_tool="/etc/dkms/sign_module.sh"
mok_signing_key="/root/module-signing/MOK.key"
mok_certificate="/root/module-signing/MOK.crt"

# 4. Create signing script (/etc/dkms/sign_module.sh):
#!/bin/bash
/usr/src/linux-headers-$(uname -r)/scripts/sign-file \
    sha256 \
    /root/module-signing/MOK.key \
    /root/module-signing/MOK.crt \
    "$1"

# 5. Rebuild DKMS modules
sudo dkms autoinstall

Security Best Practice: Protect Signing Keys

Signing keys should be protected with appropriate access controls. For production systems, consider storing private keys in a TPM or HSM, or using an offline signing machine. If a signing key is compromised, an attacker can sign malicious code that will boot on your systems.

Summary: UEFI Secure Boot Mastery

UEFI Secure Boot is the foundation of boot-time security on modern systems. Let's consolidate the essential knowledge:

Key Takeaways

•UEFI provides the framework — Secure Boot is built on UEFI's authenticated variables, image loading protocols, and driver model. It's an integrated feature, not a bolt-on.
•The key hierarchy is PK → KEK → db/dbx — Platform Key controls everything, KEKs manage signature databases, and db/dbx contain the actual trust decisions.
•Images are verified via hash or signature — Both explicit hash whitelisting and certificate-based signing are supported. dbx always takes precedence over db.
•Microsoft's UEFI CA enables the ecosystem — Third-party operating systems (Linux) use shim bootloaders signed by Microsoft, with MOK for user-level key management.
•Key management is the operational challenge — Enrollment, updates, and revocation require careful planning in enterprise environments.
•Setup Mode vs. User Mode vs. Deployed Mode — Understand when verification is active and when variables are protected.
•Signing custom components requires a key infrastructure — MOK for convenience, firmware db for security. Protect signing keys appropriately.

What's Next:

With a solid understanding of UEFI Secure Boot, we'll now examine Boot Chain Verification in greater depth—looking at how each component in the boot sequence verifies the next, the specific mechanisms used at each stage, and what happens when verification fails. This deeper dive will connect Secure Boot to the broader trusted boot architecture.

Page Complete

You now understand UEFI Secure Boot comprehensively—its architecture, key hierarchy, verification workflow, and practical management. This knowledge is essential for securing systems, troubleshooting boot issues, and designing secure boot deployments. Next, we'll explore the complete boot chain verification process that builds on these foundations.

2 / 5

Loading learning content...

Operating SystemsSecure Boot

Secure Boot: Establishing Trust from Power-On

LevelAdvanced

Duration75 mins

TopicSecure Boot

2 / 5

UEFI Secure Boot

The Industry Standard for Boot Security

What You Will Learn

UEFI Foundation

Before examining Secure Boot specifically, we must understand the UEFI (Unified Extensible Firmware Interface) specification that provides its foundation.

From BIOS to UEFI

For decades, personal computers used the Basic Input/Output System (BIOS)—firmware dating back to the IBM PC era. BIOS had severe limitations:

16-bit real mode execution: Severely limited memory access and processing capability
1MB address space: Could only directly access the first megabyte of memory
No standardized boot process: Each vendor implemented boot differently
No security framework: No mechanism for verifying boot components
MBR limitations: Master Boot Record limited to 2TB disks, 4 primary partitions

UEFI Key Capabilities for Security

•Authenticated Variables: UEFI variables that can only be modified with proper authentication (signatures). Used for storing keys and configuration.
•Driver Model: Standardized interface for loading firmware drivers, each of which can be individually verified.
•Protocol Architecture: Services exposed through discoverable protocols, enabling modular security implementations.
•GPT Partitioning: GUID Partition Table allows multiple EFI System Partitions and explicit boot partition identification.
•EFI System Partition: A FAT-formatted partition containing bootloaders, drivers, and firmware utilities—all potential verification targets.
•Runtime Services: Services that persist into OS execution, including access to authenticated variables for key management.

The UEFI Specification

UEFI is governed by the UEFI Forum, an industry consortium. The specification defines:

Boot Manager: How firmware locates and loads operating system bootloaders
Image Loading: How executable images (PE/COFF format on x86, ELF on some ARM) are loaded and authenticated
Authenticated Variables: How secure configuration is stored and protected
Secure Boot: The complete framework for boot-time image verification
Driver Signing: Requirements for option ROM and driver verification

Implementation Reality

While UEFI is a specification, implementations vary:

Intel Reference Implementation (TianoCore/EDK II): Open-source reference used by many vendors
AMI (Aptio): Commercial implementation, dominant in consumer motherboards
Phoenix/Insyde: Commercial implementations for OEM systems
ARM UEFI implementations: Various implementations for ARM servers and embedded systems

Secure Boot behavior is largely consistent across implementations (the specification is detailed), but key enrollment, user interfaces, and recovery mechanisms differ.

The Secure Boot Key Hierarchy

Converting Mermaid diagram...

Platform Key (PK)

The Platform Key sits at the top of the Secure Boot hierarchy. It represents ownership of the platform.

Singular: Only one Platform Key can exist at a time
Controls Everything: The PK holder can modify KEK, db, and dbx
Factory Default: OEMs typically ship with their own PK installed
Replaceable: Users can replace the PK to take full control (though this clears all other keys)

The PK is stored as an authenticated variable. Modifying it requires either:

A signature from the current PK (authenticated update)
Physical presence + clearing Secure Boot to Setup Mode (requires being physically present)

In practice: Most users never touch the PK. Enterprise environments may replace it to establish their own PKI. Security researchers replace it for custom key experiments.

platform_key.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Platform Key characteristics:
Variable Name: PK
Variable GUID:  8BE4DF61-93CA-11D2-AA0D-00E098032B8C (EFI_GLOBAL_VARIABLE)
Attributes:    NV + BS + RT + AT (Non-Volatile, Boot Service, Runtime, Authenticated)
Content:       EFI_SIGNATURE_LIST containing single EFI_SIGNATURE_DATA
Signature Type: Usually EFI_CERT_X509_GUID (X.509 certificate)
 
# To view the current PK on Linux:
mokutil --pk
 
# Example output:
[key 1]
SHA1 Fingerprint: 46:5b:2a:d0:...
Subject: C=US, O=Lenovo Ltd., CN=Lenovo Ltd. PK Certificate
 
# The PK is an X.509 certificate; its public key is used
# to verify signatures on KEK updates

Key Exchange Keys (KEK)

Key Exchange Keys represent entities authorized to update the signature databases (db and dbx). Unlike PK, multiple KEKs can coexist.

Multiple Allowed: A system can have KEKs from Microsoft, Linux vendors, and enterprise IT
Database Modification: KEK holders can add or remove entries in db and dbx
No Direct Boot Authorization: KEKs don't authorize bootable images directly—they manage who can authorize them
Managed by PK Owner: Adding/removing KEKs requires PK signature

Typical KEK population:

Microsoft Corporation KEK CA 2011 (allows Microsoft to update signature databases)
OEM KEK (allows manufacturer to push updates)
Enterprise KEK (allows IT department to enroll custom keys)

Signature Databases (db and dbx)

The signature databases are where the rubber meets the road—they contain the actual trust decisions.

db (Allowed Signatures Database)

Contains certificates and/or hashes that identify allowed boot components
An image passes verification if signed by a certificate in db OR its hash is in db
Typically contains Microsoft's UEFI CA certificate (signs Windows bootloader and many shims)
May contain vendor-specific certificates, individual hashes for specific tools

dbx (Forbidden Signatures Database)

Contains certificates and/or hashes of revoked or malicious components
Checked before db—if an image matches dbx, it's rejected regardless of db
Critical for revoking compromised bootloaders, blocking known malware
Updated via Windows Update, fwupd, or manual enrollment

dbt (Timestamp Database)

Less commonly used; contains timestamp authority certificates
Allows verification of signatures even after certificate expiration
Important for long-term key validity management

The db vs. dbx Priority

Image Authentication Workflow

secure_boot_verification.pseudo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// UEFI Secure Boot Image Verification Algorithm
function verify_image(image_path) -> VerificationResult:
    image = load_image_from_disk(image_path)
    
    // Step 1: Parse the PE/COFF header
    pe_header = parse_pe_coff(image)
    if pe_header is invalid:
        return SECURITY_VIOLATION("Malformed PE/COFF image")
    
    // Step 2: Compute the image hash
    // Note: Hash excludes the signature data section itself
    authenticode_hash = compute_authenticode_hash(image, pe_header)
    
    // Step 3: Check forbidden database (dbx) by HASH
    for entry in dbx:
        if entry.type == HASH and entry.value == authenticode_hash:
            return SECURITY_VIOLATION("Image hash is in dbx (revoked)")
    
    // Step 4: Check allowed database (db) by HASH (direct whitelist)
    for entry in db:
        if entry.type == HASH and entry.value == authenticode_hash:
            return SUCCESS("Image hash explicitly allowed in db")
    
    // Step 5: Extract and parse signature (if present)
    signature = extract_authenticode_signature(image, pe_header)
    if signature is null:
        return SECURITY_VIOLATION("Image is unsigned")
    
    // Step 6: Verify signature cryptographically
    signer_cert = verify_signature_chain(signature, authenticode_hash)
    if signer_cert is null:
        return SECURITY_VIOLATION("Signature verification failed")
    
    // Step 7: Check if signer certificate is in dbx
    for entry in dbx:
        if entry.type == CERTIFICATE:
            if certificates_match(entry.value, signer_cert):
                return SECURITY_VIOLATION("Signer certificate revoked in dbx")
    
    // Step 8: Check if signer certificate (or issuer) is in db
    for entry in db:
        if entry.type == CERTIFICATE:
            if certificate_chain_contains(signer_cert, entry.value):
                return SUCCESS("Signed by trusted certificate in db")
    
    // No match found—image is not trusted
    return SECURITY_VIOLATION("No matching trust anchor in db")

Authenticode Hash Computation

Hash the DOS header
Hash the PE header up to (but not including) the checksum field
Skip the checksum field (4 bytes)
Hash from after checksum to the Certificate Table entry in the Optional Header Data Directory
Skip the Certificate Table entry (8 bytes)
Hash from after Certificate Table entry to the end of headers
Hash all sections in ascending order of PointerToRawData
Exclude the Certificate Table (signature data) from hashing

This careful construction allows the signature to be embedded in the image while still being verifiable.

Verification Outcomes and Their Meaning
Outcome	Condition	System Response
SUCCESS - Hash Match	Image hash found in db	Image loads and executes
SUCCESS - Signature Match	Valid signature by certificate in db	Image loads and executes
SECURITY_VIOLATION - Hash Revoked	Image hash found in dbx	Image rejected, error displayed
SECURITY_VIOLATION - Cert Revoked	Signing certificate in dbx	Image rejected, error displayed
SECURITY_VIOLATION - Unsigned	No Authenticode signature present	Image rejected unless db hash match
SECURITY_VIOLATION - Bad Signature	Signature cryptographically invalid	Image rejected, possible corruption
SECURITY_VIOLATION - Untrusted	Signer not in db, hash not in db	Image rejected, key not enrolled

Debugging Secure Boot Failures

Microsoft's Role and the UEFI Ecosystem

Microsoft's Secure Boot Certificates

Microsoft operates two distinct Certificate Authorities for Secure Boot:

1. Microsoft Windows Production PCA 2011

Signs Windows bootloaders and kernel
Only used for Microsoft's own components
Present in db on all Windows-certified systems

2. Microsoft Corporation UEFI CA 2011

Signs third-party bootloaders (shim, GRUB, etc.)
Allows Linux distributions to boot on Secure Boot systems
Available to any software vendor through Microsoft's signing program

This dual-certificate approach means Microsoft can boot Windows with its own certificate while also allowing third-party operating systems to boot through the UEFI CA.

The Shim Bootloader: Linux's Bridge to Secure Boot

Secure Boot Verification    Shim Verification
         │                        │
         ▼                        ▼
┌─────────────────┐        ┌─────────────────┐
│   UEFI Firmware │        │      Shim       │
│                 │        │                 │
│ Verifies shim   │───────▶│ Verifies GRUB   │
│ using Microsoft │        │ using distro's  │
│ UEFI CA cert    │        │ embedded cert   │
└─────────────────┘        └─────────────────┘
                                  │
                                  ▼
                           ┌─────────────────┐
                           │      GRUB       │
                           │                 │
                           │ Verifies kernel │
                           │ using distro's  │
                           │ GPG keys        │
                           └─────────────────┘

Shim is:

Signed by Microsoft: Passes UEFI Secure Boot verification
Contains vendor certificate: Each distribution embeds their own public key
Implements MOK (Machine Owner Key): Allows users to enroll additional certificates
Minimal attack surface: Small, audited codebase

Major Linux distributions (Red Hat, Ubuntu, SUSE, Fedora) each have their own Microsoft-signed shim that contains their distribution's signing certificate.

Microsoft UEFI Signing Requirements

•Code Review: Submitted code undergoes security review before signing
•Malware Scanning: Binaries are scanned for known malware signatures
•Vendor Verification: Submitting organization must be verified
•Accountability Agreement: Vendors agree to terms holding them responsible for their code
•Revocation Cooperation: Vendors must cooperate if revocation becomes necessary
•EV Certificate Signing: Submissions must use Extended Validation code signing certificates

The Centralization Tradeoff

Key Enrollment and Management

Setup Mode: Full Key Access

When no Platform Key is enrolled, Secure Boot operates in Setup Mode. In this mode:

Secure Boot image verification is disabled
All authenticated variables (PK, KEK, db, dbx) can be modified without authentication
Firmware typically indicates Setup Mode status in setup utility
First enrollment of PK automatically exits Setup Mode

Entering Setup Mode:

Access UEFI firmware setup (usually Delete, F2, or F12 at boot)
Navigate to Security → Secure Boot
Select 'Clear Secure Boot Keys' or 'Reset to Setup Mode'
Confirm the action (may require physical presence verification)

Security Note: Setup Mode is inherently insecure. Systems in Setup Mode will boot unsigned code. This is acceptable during initial provisioning but should never be the production state.

Enrolling Custom Keys:

# Generate a new Platform Key
openssl req -new -x509 -newkey rsa:2048 -keyout PK.key -out PK.crt \
    -days 3650 -nodes -subj "/CN=My Platform Key/"

# Convert to UEFI signature list format
cert-to-efi-sig-list -g $(uuidgen) PK.crt PK.esl

# Sign the update with itself (self-signed PK)
sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth

# Enroll via firmware setup or efi-updatevar
efi-updatevar -f PK.auth PK

Secure Boot States and Transitions

UEFI Secure Boot operates in distinct states, with well-defined transitions between them. Understanding these states is essential for deployment and troubleshooting.

Converting Mermaid diagram...

Secure Boot State Comparison
State	PK Enrolled	Verification	Variable Protection	Use Case
Setup Mode	No	Disabled	None	Initial provisioning, key replacement
User Mode - Enabled	Yes	Active	Authenticated only	Normal secure operation
User Mode - Disabled	Yes	Disabled	Authenticated only	Troubleshooting, testing
Deployed Mode (optional)	Yes	Active	PK cannot be cleared	Locked-down systems

Setup Mode vs. Secure Boot Disabled

These are often confused but differ importantly:

Setup Mode (No PK enrolled):

Anyone can modify db/dbx without authentication
System is in provisioning state
Appropriate only during initial key enrollment

User Mode with Secure Boot Disabled:

PK is enrolled, keys are protected
Image verification is turned off
Authenticated variable updates still required
Useful for troubleshooting boot issues

The key distinction: In Setup Mode, an attacker with OS-level access could add their own key to db. In User Mode (even disabled), they would need the KEK private key to modify db.

Audit Mode (UEFI 2.6+)

Some newer firmware supports Audit Mode:

Verification is performed but failures are logged, not enforced
Useful for testing what would pass/fail before enabling
Helps identify signing gaps before lockdown

Deployed Mode (UEFI 2.5+)

Deployed Mode provides additional lockdown:

PK cannot be cleared even with physical presence
Prevents accidental or malicious return to Setup Mode
Typically used in highly secure or IoT deployments
Recovery requires firmware reflashing or factory service

Physical Presence Requirements

Common Challenges and Solutions

Deploying and maintaining Secure Boot involves navigating several common challenges. Here are the issues practitioners encounter most frequently, along with proven solutions.

Common Problems

•Custom kernel won't boot: Self-compiled kernels are unsigned
•Third-party drivers blocked: DKMS modules not signed
•Dual boot fails: Second OS lacks proper signing
•Old bootloader rejected: dbx update revoked old version
•Recovery media won't boot: USB recovery tools unsigned
•Option ROM blocked: PCIe expansion cards have unsigned firmware

Solutions

•Sign kernel with enrolled key: Use mokutil for MOK or sbsign for db key
•Configure DKMS with signing key: Auto-sign modules during build
•Use shim + MOK for second OS: Enroll distribution's certificate
•Update bootloader: Upgrade shim/GRUB to current signed version
•Enroll hash or remaster: Add hash to db or rebuild with signing
•Enroll option ROM cert: Add vendor certificate to db (security risk!)

Detailed Solution: Signing Custom Kernels

For development or custom systems, you need to sign your own kernels:

# 1. Generate a signing key pair
openssl req -new -x509 -newkey rsa:2048 \
    -keyout MOK.key -out MOK.crt \
    -nodes -days 3650 \
    -subj "/CN=My Kernel Signing Key/"

# 2. Enroll the certificate in MOK
sudo mokutil --import MOK.crt
# Enter a one-time password when prompted

# 3. Reboot and complete enrollment in MokManager
# Press any key at the 'Press any key to perform MOK management'
# Select 'Enroll MOK', 'Continue', 'Yes'
# Enter the password from step 2
# Reboot

# 4. Sign your kernel
sudo sbsign --key MOK.key --cert MOK.crt \
    /boot/vmlinuz-custom \
    --output /boot/vmlinuz-custom.signed

# 5. Update bootloader to use signed kernel
sudo update-grub  # or manually edit boot entry

Detailed Solution: Signing Kernel Modules (DKMS)

Third-party kernel modules (NVIDIA, VirtualBox, etc.) need signing:

# 1. Create signing key (same as kernel signing)
openssl req -new -x509 -newkey rsa:2048 \
    -keyout /root/module-signing/MOK.key \
    -out /root/module-signing/MOK.crt \
    -nodes -days 3650 \
    -subj "/CN=Module Signing Key/"

# 2. Enroll in MOK (same as above)
sudo mokutil --import /root/module-signing/MOK.crt

# 3. Configure DKMS to use your key
# /etc/dkms/framework.conf:
modprobe_on_install="false"
sign_tool="/etc/dkms/sign_module.sh"
mok_signing_key="/root/module-signing/MOK.key"
mok_certificate="/root/module-signing/MOK.crt"

# 4. Create signing script (/etc/dkms/sign_module.sh):
#!/bin/bash
/usr/src/linux-headers-$(uname -r)/scripts/sign-file \
    sha256 \
    /root/module-signing/MOK.key \
    /root/module-signing/MOK.crt \
    "$1"

# 5. Rebuild DKMS modules
sudo dkms autoinstall

Security Best Practice: Protect Signing Keys

Summary: UEFI Secure Boot Mastery

UEFI Secure Boot is the foundation of boot-time security on modern systems. Let's consolidate the essential knowledge:

Key Takeaways

•UEFI provides the framework — Secure Boot is built on UEFI's authenticated variables, image loading protocols, and driver model. It's an integrated feature, not a bolt-on.
•The key hierarchy is PK → KEK → db/dbx — Platform Key controls everything, KEKs manage signature databases, and db/dbx contain the actual trust decisions.
•Images are verified via hash or signature — Both explicit hash whitelisting and certificate-based signing are supported. dbx always takes precedence over db.
•Microsoft's UEFI CA enables the ecosystem — Third-party operating systems (Linux) use shim bootloaders signed by Microsoft, with MOK for user-level key management.
•Key management is the operational challenge — Enrollment, updates, and revocation require careful planning in enterprise environments.
•Setup Mode vs. User Mode vs. Deployed Mode — Understand when verification is active and when variables are protected.
•Signing custom components requires a key infrastructure — MOK for convenience, firmware db for security. Protect signing keys appropriately.

What's Next:

Page Complete

2 / 5