Operating SystemsSecure Boot

Secure Boot: Establishing Trust from Power-On

LevelAdvanced

Duration75 mins

TopicSecure Boot

5 / 5

Measured Boot

Trust, But Verify: The Complete Picture

We've explored two complementary approaches to boot security: Secure Boot prevents unauthorized code from executing, while TPM measurement records what actually executed. Measured Boot combines these approaches to create a system that is both protected at boot time AND whose boot state can be cryptographically verified afterward.

Measured Boot transforms security from a binary question ("Did something bad run?") into a verifiable statement ("Here's exactly what ran, signed by tamper-resistant hardware"). This enables sophisticated security architectures where secrets are only released to verified systems, access is granted only to machines that booted approved configurations, and remote verifiers can assess system integrity without trusting the system's software.

What You Will Learn

By the end of this page, you will understand how measured boot integrates Secure Boot and TPM technologies, the complete attestation workflow, practical implementation on Windows and Linux, and advanced topics including confidential computing and measured launch. You'll be equipped to design, deploy, and verify measured boot architectures in enterprise and cloud environments.

Measured Boot vs. Secure Boot

Understanding the distinction between Secure Boot and Measured Boot is fundamental. They solve different problems and are most powerful when combined.

Secure Boot vs. Measured Boot Comparison
Aspect	Secure Boot	Measured Boot
Primary Goal	Prevent unauthorized code execution	Record exactly what executed
Mechanism	Signature verification	Cryptographic hashing into PCRs
Failure Mode	Boot halts (enforcement)	Attestation reveals mismatch (detection)
Flexibility	Requires pre-signed binaries	Can measure any code
Key Component	UEFI Secure Boot (db/dbx)	TPM Platform Configuration Registers
Verification Time	At load time (before execution)	Any time after boot (attestation)
Remote Verification	Not inherent (local enforcement)	Core capability (remote attestation)
Use Case	Block known-bad, allow known-good	Prove what booted, seal to state

Why Both Together?

Secure Boot alone has limitations:

Only effective if dbx is current (attacker may use old, unrevoked malware)
No way to prove to a remote party what booted
No mechanism to seal secrets to boot state
Compromised db or KEK undermines protection

Measured Boot alone has limitations:

Doesn't prevent malicious code from running (only records it)
Detection is reactive, not preventive
Requires infrastructure to process attestations
System may be compromised before attestation fails

Combined ("Trusted Boot"): The system both enforces known-good signatures AND records what was loaded for verification. This provides:

Prevention: Unsigned/revoked code doesn't run
Detection: Any bypass or unexpected code is recorded
Sealing: Secrets only available if correct code ran
Attestation: Prove boot state to remote verifiers

Converting Mermaid diagram...

Defense in Depth

Secure Boot provides the first line of defense; measured boot provides the verification layer. Even if an attacker somehow bypasses Secure Boot (through a 0-day, compromised key, or misconfiguration), the measured boot record will differ from expected values—enabling detection through attestation or causing sealed secrets to fail to unlock.

Measured Boot Workflow

A complete measured boot implementation follows a carefully orchestrated workflow from power-on through operating system initialization. Each component measures the next before loading it, building a cryptographic record in the TPM.

Converting Mermaid diagram...

Phase Details

Phase 1: Core Root of Trust for Measurement (CRTM)

The CRTM is the first piece of code that executes and performs measurements. On modern Intel systems, this is the ACM code verified by Boot Guard. On AMD, it's the PSP boot code.

CRTM is inherently trusted (cannot be measured by earlier code)
CRTM measures itself into PCR 0 (by convention, a static value)
CRTM measures the platform firmware before executing it
This establishes the Root of Trust for Measurement

Phase 2: Firmware Measurement

UEFI firmware measures platform configuration and boot components:

PCR 0: Additional firmware code
PCR 1: Platform configuration (BIOS settings)
PCR 2: Option ROM code
PCR 3: Option ROM configuration
PCR 4: Boot loader code
PCR 5: Boot loader configuration (GPT partition table)
PCR 6: Wake events
PCR 7: Secure Boot policy (PK, KEK, db, dbx hashes)

Phase 3: Bootloader Measurement

The bootloader (GRUB, shim, Windows Boot Manager) continues measurement:

PCR 8: GRUB configuration, command line
PCR 9: Kernel image, initramfs

Phase 4: OS Measurement (IMA)

The Linux kernel's IMA subsystem extends measurement into runtime:

PCR 10 (typically): Executables, libraries, configuration files
                    as they're accessed

Measurement vs. Verification

Note the difference: Secure Boot VERIFIES before allowing execution (binary pass/fail). Measured Boot MEASURES everything that is about to execute (creates a record). Both happen—Secure Boot may reject code that would have been measured, but anything that passes Secure Boot is also measured.

Windows Measured Boot Implementation

Windows has comprehensive measured boot support, deeply integrated with BitLocker and enterprise management features.

Windows Boot Measurement Chain

┌─────────────────────────────────────────────────────────────────┐
│ Windows Measured Boot Components                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌────────────┐   ┌────────────┐   ┌────────────┐              │
│  │ Boot Guard │──▶│ UEFI FW    │──▶│ bootmgfw   │              │
│  │   (CRTM)   │   │            │   │   .efi     │              │
│  └────────────┘   └────────────┘   └────────────┘              │
│       │PCR0           │PCR1,7          │PCR4                   │
│       ▼               ▼                ▼                       │
│  ┌────────────┐   ┌────────────┐   ┌────────────┐              │
│  │ winload    │──▶│ ntoskrnl   │──▶│ Early Boot │              │
│  │   .efi     │   │   .exe     │   │  Drivers   │              │
│  └────────────┘   └────────────┘   └────────────┘              │
│       │PCR11           │PCR11          │PCR11                  │
│       ▼               ▼                ▼                       │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │                   BitLocker Unlock                        │ │
│  │  1. Read PCR 0, 2, 4, 7, 11 values                       │ │
│  │  2. Unseal Volume Master Key (VMK) from TPM              │ │
│  │  3. If PCRs match sealed values: Decrypt volume          │ │
│  └───────────────────────────────────────────────────────────┘ │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Windows Boot Logging

Windows logs all boot measurements in the TCG event log. Key events include:

EV_EFI_VARIABLE_BOOT: Boot order and variables
EV_EFI_ACTION: Boot actions (ReadyToBoot, ExitBootServices)
EV_SEPARATOR: Transition between boot phases
EV_EFI_BOOT_SERVICES_APPLICATION: Loaded applications
EV_EFI_OS_LOADER: Windows Boot Manager, winload

The event log is stored in memory and accessible through WMI after boot.

windows_measured_boot.ps1
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
# Windows Measured Boot Verification
 
# Check if Secure Boot is enabled
Confirm-SecureBootUEFI
# Expected: True
 
# Get TPM information
Get-Tpm
# Expected: TpmPresent: True, TpmReady: True, TpmOwned: True
 
# Read PCR values (requires Admin)
Get-TpmEndorsementKeyInfo
 
# View BitLocker protection status
Get-BitLockerVolume -MountPoint "C:"
# Look for: KeyProtector with type "Tpm"
 
# Get BitLocker key protector details
(Get-BitLockerVolume -MountPoint "C:").KeyProtector | 
    Where-Object {$_.KeyProtectorType -eq 'Tpm'}
# Shows PCRs that BitLocker is sealed to
 
# View TCG event log
$Log = Get-WmiObject -Namespace root\cimv2\Security\MicrosoftTpm `
                                    - Class Win32_Tpm
$Log.GetPhysicalPresenceRequest()
 
# More detailed event log(requires Windows Admin Center or tpmtool)
# tpmtool gatherlogs<output_path>
 
# Check Device Health Attestation enrollment
Get- ItemProperty - Path "HKLM:\SOFTWARE\Microsoft\DeviceHealthAttestation"
 
# Verify boot configuration against expected
bcdedit /enum | Select - String "integrity"

Windows Defender System Guard

System Guard provides additional measured boot hardening:

Secure Launch (DRTM)

Uses Intel TXT or AMD SKINIT for measured late launch
Establishes clean CPU state before hypervisor/kernel
Measures Hyper-V and kernel into PCRs
Enables Virtualization-Based Security (VBS)

System Management Mode (SMM) Protection

SMM runs at highest privilege (Ring -2)
System Guard measures SMM code
VBS-protected secrets remain safe even if SMM compromised

Runtime Attestation

Periodically attests system state to Windows Device Health Attestation service
Cloud service verifies measurements against policy
Results available to MDM for conditional access

Windows 11 Requirements

Windows 11 requires TPM 2.0 and Secure Boot capable systems. This isn't arbitrary—it's to enable measured boot, attestation, and modern security features like System Guard and VBS. The hardware requirements establish a baseline for enterprise security capabilities.

Linux Measured Boot Implementation

Linux measured boot leverages firmware measurements, shim/GRUB extensions, and the Integrity Measurement Architecture (IMA) for comprehensive boot-to-runtime measurement.

linux_measured_boot.sh
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
48
49
50
51
52
53
54
55
# Linux Measured Boot Configuration and Verification
 
# === Phase 1: Check TPM availability ===
# Verify TPM device exists
ls - la / dev / tpm *
# Expected: /dev/tpm0 and / dev / tpmrm0
 
# Check TPM version
cat / sys / class/ tpm / tpm0 / tpm_version_major
# Expected: 2(for TPM 2.0)
 
# === Phase 2: Verify firmware measurements ===
# Read current PCR values
tpm2_pcrread sha256: 0, 1, 2, 3, 4, 5, 6, 7
 
# View TCG event log
    tpm2_eventlog / sys / kernel / security / tpm0 / binary_bios_measurements
 
# Verify event log matches PCR values
    tpm2_eventlog / sys / kernel / security / tpm0 / binary_bios_measurements \
    --verify - pcrs
 
# === Phase 3: Check Secure Boot status ===
        mokutil--sb - state
# Expected: SecureBoot enabled
 
# === Phase 4: IMA Configuration ===
# Check if IMA is enabled
    dmesg | grep - i ima
# Look for: "integrity: Platform Keyring initialized"
 
# View IMA policy(if loaded)
        cat / sys / kernel / security / ima / policy
 
# View IMA runtime measurements
    head - 20 / sys / kernel / security / ima / ascii_runtime_measurements
# Format: PCR template - hash algorithm: file - hash filename
 
# Example output:
# 10 abc123...ima - ng sha256:def456...boot_aggregate
# 10 fed321...ima - ng sha256: 123abc... /usr/sbin / init
# 10 aabbcc...ima - ng sha256:ddeeff... /usr/lib / systemd / systemd
 
# === Phase 5: TPM - backed LUKS encryption ===
# Check LUKS for TPM binding(using systemd - cryptenroll)
systemd - cryptenroll / dev / sda3--tpm2 - device=list
# Shows TPM binding status
 
# Enroll TPM for LUKS unlock
sudo systemd - cryptenroll / dev / sda3 \
    --tpm2 - device=auto \
    --tpm2 - pcrs=0 + 7  # Seal to PCR 0 and 7
 
# Verify enrollment
cryptsetup luksDump / dev / sda3 | grep - A5 "Token"

Unified Kernel Images (UKI) for Measured Boot

UKIs address a traditional weakness in Linux measured boot: the initramfs gap.

Traditional Problem:

Kernel is signed and measured
Initramfs is often not signed or measured (or measured too late)
Command line can be manipulated
Each component measured separately, complex to verify

UKI Solution: Bundle everything into a single signed PE binary:

┌───────────────────────────────────────────────┐
│          Unified Kernel Image(.efi)          │
├───────────────────────────────────────────────┤
│  .osrel    │ OS release information           │
│  .cmdline  │ Kernel command line(LOCKED)     │
│  .linux    │ Kernel image                     │
│  .initrd   │ Initramfs(compressed)           │
│  .splash   │ Boot splash image(optional)     │
│  .uname    │ Kernel version string            │
│  .sbat     │ UEFI revocation metadata         │
│  .pcrsig   │ Expected PCR values + signature  │
└───────────────────────────────────────────────┘

Benefits:

Single file to sign and verify
Command line cannot be modified
Initramfs included in measurement
.pcrsig section contains predicted PCR values for unsealing

Creating a UKI:

# Using ukify(systemd - ukify) 
ukify build \n--linux = /boot/vmlinuz - 6.1.0 \n--initrd = /boot/initramfs - 6.1.0.img \n--cmdline ="root=/dev/mapper/root ro quiet" \n    --os-release=@/etc/os-release \n    --output=/boot/efi/EFI/Linux/linux-6.1.0.efi \n    --secureboot-private-key=/path/to/key \n    --secureboot-certificate=/path/to/cert

IMA Deep Dive

The Integrity Measurement Architecture extends measured boot into the running system:

IMA Modes:

Mode	Description	Use Case
`measure`	Record hash to PCR	Attestation
`appraise`	Verify against stored signature	Enforcement
`audit`	Log measurements to audit log	Compliance

IMA Policy Example:

# /etc/ima/ima-policy

# Measure all executables run by root
measure uid=0 func=BPRM_CHECK

# Measure all kernel modules
measure func=MODULE_CHECK

# Measure all firmware loaded
measure func=FIRMWARE_CHECK

# Appraise (verify signatures) for all executables
appraise fowner=0 mode=0755 func=BPRM_CHECK appraise_type=imasig

# Audit all file opens by root
audit uid=0 func=FILE_CHECK

IMA + TPM Integration:

Measurements extended to PCR 10 (configurable)
Event log at /sys/kernel/security/ima/ascii_runtime_measurements
Binary log for remote attestation
Can be used with Keylime for continuous attestation

IMA Performance Considerations

IMA measurement has a performance cost—every file access matching the policy triggers a hash computation and TPM extend. In high-throughput environments, carefully craft the IMA policy to measure only security-critical files. Broad policies (measure all files) can impact system performance significantly.

Attestation Architectures

Measured boot provides the foundation; attestation architectures provide the verification infrastructure. Different use cases require different attestation models.

Local Attestation: Sealing Secrets

The simplest attestation model—the system attests to itself.

Use Case: Disk Encryption (BitLocker, LUKS+TPM)

During setup: Seal encryption key to current PCR values
On boot: TPM verifies PCRs before releasing key
No external verifier needed
Protects against offline attacks and boot tampering

Advantages:

No network dependency
No external infrastructure required
Immediate enforcement (key won't unseal if tampered)

Limitations:

No visibility into system state from outside
System must be configured correctly initially
Doesn't protect against runtime attacks

Implementation:

# LUKS with TPM sealing (systemd-cryptenroll)
sudo systemd-cryptenroll /dev/sda3 \n    --tpm2-device=auto \n    --tpm2-pcrs=0+7  # Seal to firmware and Secure Boot policy

If anything in the measured boot chain changes (firmware update, bootloader change, Secure Boot policy modification), the system won't boot without the recovery key. This is the tradeoff: security vs. maintainability.

Dynamic Root of Trust for Measurement (DRTM)

Static Root of Trust for Measurement (SRTM), which we've discussed primarily, establishes trust at system reset. Dynamic Root of Trust for Measurement (DRTM) provides the ability to establish a new root of trust at any point during system operation—even if the early boot was potentially compromised.

Why DRTM?

SRTM has a fundamental limitation: if any component in the early boot chain (SMM, Option ROMs, firmware drivers) is compromised, all subsequent measurements are suspect. DRTM addresses this by:

Resetting CPU state to a known-good configuration
Entering a protected execution mode
Measuring a new trusted environment from this clean slate
Using different PCRs (17-22) to record DRTM measurements

DRTM Technologies:

Intel TXT (Trusted Execution Technology)

Uses GETSEC[SENTER] instruction
Resets CPU state, clears caches
Loads and measures SINIT ACM (Intel-signed)
SINIT measures the Measured Launch Environment (MLE)
Hypervisor/OS boots in measured, protected state

AMD SKINIT (Secure Kernel Init)

Uses SKINIT instruction
Similar concept to Intel TXT
More streamlined (single instruction does everything)
Used by AMD SEV for VM attestation

Converting Mermaid diagram...

DRTM PCR Usage

PCR	Description
PCR 17	DRTM launch policy, SINIT ACM
PCR 18	MLE (Hypervisor/tboot policy)
PCR 19-22	Platform-specific DRTM measurements

DRTM Benefits:

Bypasses early boot compromises: SMM attacks, Option ROM attacks don't affect DRTM measurements
Late launch capability: Can establish trust on already-running systems
Smaller trusted computing base: Only the MLE needs to be trusted, not all firmware

Intel TXT with tboot (Linux)

tboot is a pre-kernel module that implements DRTM for Linux:

# Install tboot
sudo apt install tboot

# Configure GRUB to use tboot
# /etc/default/grub:
# GRUB_CMDLINE_TBOOT="..."

# tboot loads first, performs SENTER, then loads kernel
# Kernel boots in measured environment with PCRs 17-22 populated

# Verify DRTM measurements
txt-stat

Windows System Guard Secure Launch

System Guard uses DRTM to protect Hyper-V and VBS:

Triggered late in boot, after some firmware code runs
Resets CPU state before loading Hyper-V hypervisor
Hypervisor starts in clean, measured state
Protects VBS secrets even if SMM was compromised

When to Use DRTM vs. SRTM

SRTM is simpler and measures from the very first instruction. DRTM is more complex but provides stronger guarantees by resetting to a known state. Use DRTM when: (1) You can't trust all platform firmware, (2) You need to protect against SMM attacks, (3) You're running sensitive hypervisor workloads, or (4) Compliance requires DRTM-level protection.

Confidential Computing Integration

Measured boot provides the foundation for Confidential Computing—technologies that protect data in use by ensuring computations occur in hardware-attested trusted execution environments.

Intel SGX (Software Guard Extensions)

SGX creates isolated memory regions called enclaves:

Enclave Memory: Encrypted by CPU, inaccessible to OS/hypervisor
Remote Attestation: Enclave generates quote proving its code and data
Measured at Load: Enclave code is hashed when loaded
Quote includes: MRENCLAVE (code hash), MRSIGNER (author), user data

SGX Attestation Flow:

Application creates enclave
CPU measures enclave code → MRENCLAVE
Enclave generates quote (signed by Quoting Enclave)
Quote sent to Intel Attestation Service
Service verifies, returns attestation report
Remote party trusts enclave based on report

Use Cases:

Secure key management
Confidential smart contracts
Private machine learning inference

AMD SEV-SNP (Secure Encrypted Virtualization)

SEV-SNP protects entire virtual machines:

Memory Encryption: VM memory encrypted, unique key per VM
SNP (Secure Nested Paging): Integrity protection + attestation
Measured Launch: VM boot code measured by PSP
Report includes: VM measurement, policy, host configuration

SEV-SNP Attestation Flow:

VM launched on SEV-SNP capable host
AMD PSP measures initial VM state
VM requests attestation report from PSP
Report signed by AMD Root Key (verifiable)
Remote party verifies VM is genuine SEV-SNP VM
Secrets provisioned only to verified VMs

Use Cases:

Confidential cloud computing
Multi-tenant workload isolation
Trusted VM migration

Attestation Comparison

Technology	Granularity	Attested By	Trust Root
TPM Measured Boot	Whole system	TPM Quote	TPM EK → Manufacturer
Intel SGX	Application enclave	Quoting Enclave	Intel Root Key
AMD SEV-SNP	Virtual machine	AMD PSP	AMD Root Key
Intel TDX	Trust Domain	TDX Module	Intel Attestation
ARM CCA	Realm	RMM	ARM Security Root

Measured Boot → Confidential Computing Pipeline:

1. System boots with measured boot (TPM records)
2. Hypervisor launches confidential VM (SEV-SNP/TDX)
3. VM boot is measured by security processor
4. Application in VM creates enclave (SGX)
5. Each layer provides attestation:
   - TPM: "This host booted correctly"
   - SEV: "This VM is encrypted and genuine"
   - SGX: "This enclave runs expected code"
6. Remote verifier chains attestations
7. Secrets released only to fully verified stack

This layered attestation enables end-to-end verified computation, where data owners can verify every layer from hardware to application code before releasing sensitive data.

The Future of Attestation

Cloud providers like Azure, GCP, and AWS are rapidly adopting confidential computing. Azure Confidential Computing offers SGX and SEV-SNP VMs with integrated attestation. Google Cloud offers Confidential VMs with AMD SEV. AWS Nitro Enclaves provide a different but complementary approach. Measured boot and hardware attestation are becoming table stakes for sensitive workloads.

Summary: Measured Boot Mastery

Measured boot brings together all the secure boot concepts we've explored—creating systems that are both protected and verifiable. Let's consolidate the essential knowledge:

Key Takeaways

•Secure Boot prevents, Measured Boot records — They're complementary: Secure Boot enforces known-good signatures; Measured Boot creates a verifiable record for attestation.
•The measurement chain extends from hardware to applications — CRTM → Firmware → Bootloader → Kernel → IMA, each layer measuring the next into TPM PCRs.
•Windows and Linux have comprehensive implementations — Bitlocker with TPM, System Guard, IMA, UKIs, and systemd-cryptenroll provide production-ready measured boot.
•Attestation architectures verify boot state — Local (sealing), remote (network access), and continuous (runtime monitoring) patterns serve different use cases.
•DRTM provides late-boot trust establishment — Intel TXT and AMD SKINIT reset CPU state to bypass potential early-boot compromises.
•Confidential computing extends attestation — SGX, SEV-SNP, TDX layer additional attestation on top of measured boot for end-to-end verification.
•Unified Kernel Images solve Linux gaps — UKIs bundle kernel, initramfs, and cmdline into one signed binary, closing verification gaps.

Module Complete: Secure Boot Mastery

You have now completed a comprehensive exploration of secure boot technologies:

Page 1: Trusted Boot Process — The foundational concepts of trust establishment
Page 2: UEFI Secure Boot — The industry-standard implementation
Page 3: Boot Chain Verification — How each stage verifies the next
Page 4: TPM — The hardware that records and attests boot state
Page 5: Measured Boot — Combining prevention and verification

Together, these technologies form the foundation of modern platform security. From protecting personal laptops with BitLocker to attesting cloud VMs for confidential computing, the principles you've learned apply across the entire spectrum of computing systems. You're now equipped to design, implement, configure, and troubleshoot secure boot architectures in any environment.

Module Complete

Congratulations! You've mastered the complete secure boot landscape—from hardware roots of trust through attestation infrastructure to confidential computing. This knowledge is essential for modern security engineering, whether you're protecting endpoints, hardening servers, or designing cloud security architectures. The era of attestable computing is here, and you're now prepared to build on these foundations.

5 / 5

Loading learning content...

Operating SystemsSecure Boot

Secure Boot: Establishing Trust from Power-On

LevelAdvanced

Duration75 mins

TopicSecure Boot

5 / 5

Measured Boot

Trust, But Verify: The Complete Picture

What You Will Learn

Measured Boot vs. Secure Boot

Understanding the distinction between Secure Boot and Measured Boot is fundamental. They solve different problems and are most powerful when combined.

Secure Boot vs. Measured Boot Comparison
Aspect	Secure Boot	Measured Boot
Primary Goal	Prevent unauthorized code execution	Record exactly what executed
Mechanism	Signature verification	Cryptographic hashing into PCRs
Failure Mode	Boot halts (enforcement)	Attestation reveals mismatch (detection)
Flexibility	Requires pre-signed binaries	Can measure any code
Key Component	UEFI Secure Boot (db/dbx)	TPM Platform Configuration Registers
Verification Time	At load time (before execution)	Any time after boot (attestation)
Remote Verification	Not inherent (local enforcement)	Core capability (remote attestation)
Use Case	Block known-bad, allow known-good	Prove what booted, seal to state

Why Both Together?

Secure Boot alone has limitations:

Only effective if dbx is current (attacker may use old, unrevoked malware)
No way to prove to a remote party what booted
No mechanism to seal secrets to boot state
Compromised db or KEK undermines protection

Measured Boot alone has limitations:

Doesn't prevent malicious code from running (only records it)
Detection is reactive, not preventive
Requires infrastructure to process attestations
System may be compromised before attestation fails

Combined ("Trusted Boot"): The system both enforces known-good signatures AND records what was loaded for verification. This provides:

Prevention: Unsigned/revoked code doesn't run
Detection: Any bypass or unexpected code is recorded
Sealing: Secrets only available if correct code ran
Attestation: Prove boot state to remote verifiers

Converting Mermaid diagram...

Defense in Depth

Measured Boot Workflow

Converting Mermaid diagram...

Phase Details

Phase 1: Core Root of Trust for Measurement (CRTM)

The CRTM is the first piece of code that executes and performs measurements. On modern Intel systems, this is the ACM code verified by Boot Guard. On AMD, it's the PSP boot code.

CRTM is inherently trusted (cannot be measured by earlier code)
CRTM measures itself into PCR 0 (by convention, a static value)
CRTM measures the platform firmware before executing it
This establishes the Root of Trust for Measurement

Phase 2: Firmware Measurement

UEFI firmware measures platform configuration and boot components:

PCR 0: Additional firmware code
PCR 1: Platform configuration (BIOS settings)
PCR 2: Option ROM code
PCR 3: Option ROM configuration
PCR 4: Boot loader code
PCR 5: Boot loader configuration (GPT partition table)
PCR 6: Wake events
PCR 7: Secure Boot policy (PK, KEK, db, dbx hashes)

Phase 3: Bootloader Measurement

The bootloader (GRUB, shim, Windows Boot Manager) continues measurement:

PCR 8: GRUB configuration, command line
PCR 9: Kernel image, initramfs

Phase 4: OS Measurement (IMA)

The Linux kernel's IMA subsystem extends measurement into runtime:

PCR 10 (typically): Executables, libraries, configuration files
                    as they're accessed

Measurement vs. Verification

Windows Measured Boot Implementation

Windows has comprehensive measured boot support, deeply integrated with BitLocker and enterprise management features.

Windows Boot Measurement Chain

┌─────────────────────────────────────────────────────────────────┐
│ Windows Measured Boot Components                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌────────────┐   ┌────────────┐   ┌────────────┐              │
│  │ Boot Guard │──▶│ UEFI FW    │──▶│ bootmgfw   │              │
│  │   (CRTM)   │   │            │   │   .efi     │              │
│  └────────────┘   └────────────┘   └────────────┘              │
│       │PCR0           │PCR1,7          │PCR4                   │
│       ▼               ▼                ▼                       │
│  ┌────────────┐   ┌────────────┐   ┌────────────┐              │
│  │ winload    │──▶│ ntoskrnl   │──▶│ Early Boot │              │
│  │   .efi     │   │   .exe     │   │  Drivers   │              │
│  └────────────┘   └────────────┘   └────────────┘              │
│       │PCR11           │PCR11          │PCR11                  │
│       ▼               ▼                ▼                       │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │                   BitLocker Unlock                        │ │
│  │  1. Read PCR 0, 2, 4, 7, 11 values                       │ │
│  │  2. Unseal Volume Master Key (VMK) from TPM              │ │
│  │  3. If PCRs match sealed values: Decrypt volume          │ │
│  └───────────────────────────────────────────────────────────┘ │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Windows Boot Logging

Windows logs all boot measurements in the TCG event log. Key events include:

EV_EFI_VARIABLE_BOOT: Boot order and variables
EV_EFI_ACTION: Boot actions (ReadyToBoot, ExitBootServices)
EV_SEPARATOR: Transition between boot phases
EV_EFI_BOOT_SERVICES_APPLICATION: Loaded applications
EV_EFI_OS_LOADER: Windows Boot Manager, winload

The event log is stored in memory and accessible through WMI after boot.

windows_measured_boot.ps1
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
# Windows Measured Boot Verification
 
# Check if Secure Boot is enabled
Confirm-SecureBootUEFI
# Expected: True
 
# Get TPM information
Get-Tpm
# Expected: TpmPresent: True, TpmReady: True, TpmOwned: True
 
# Read PCR values (requires Admin)
Get-TpmEndorsementKeyInfo
 
# View BitLocker protection status
Get-BitLockerVolume -MountPoint "C:"
# Look for: KeyProtector with type "Tpm"
 
# Get BitLocker key protector details
(Get-BitLockerVolume -MountPoint "C:").KeyProtector | 
    Where-Object {$_.KeyProtectorType -eq 'Tpm'}
# Shows PCRs that BitLocker is sealed to
 
# View TCG event log
$Log = Get-WmiObject -Namespace root\cimv2\Security\MicrosoftTpm `
                                    - Class Win32_Tpm
$Log.GetPhysicalPresenceRequest()
 
# More detailed event log(requires Windows Admin Center or tpmtool)
# tpmtool gatherlogs<output_path>
 
# Check Device Health Attestation enrollment
Get- ItemProperty - Path "HKLM:\SOFTWARE\Microsoft\DeviceHealthAttestation"
 
# Verify boot configuration against expected
bcdedit /enum | Select - String "integrity"

Windows Defender System Guard

System Guard provides additional measured boot hardening:

Secure Launch (DRTM)

Uses Intel TXT or AMD SKINIT for measured late launch
Establishes clean CPU state before hypervisor/kernel
Measures Hyper-V and kernel into PCRs
Enables Virtualization-Based Security (VBS)

System Management Mode (SMM) Protection

SMM runs at highest privilege (Ring -2)
System Guard measures SMM code
VBS-protected secrets remain safe even if SMM compromised

Runtime Attestation

Periodically attests system state to Windows Device Health Attestation service
Cloud service verifies measurements against policy
Results available to MDM for conditional access

Windows 11 Requirements

Linux Measured Boot Implementation

Linux measured boot leverages firmware measurements, shim/GRUB extensions, and the Integrity Measurement Architecture (IMA) for comprehensive boot-to-runtime measurement.

linux_measured_boot.sh
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
48
49
50
51
52
53
54
55
# Linux Measured Boot Configuration and Verification
 
# === Phase 1: Check TPM availability ===
# Verify TPM device exists
ls - la / dev / tpm *
# Expected: /dev/tpm0 and / dev / tpmrm0
 
# Check TPM version
cat / sys / class/ tpm / tpm0 / tpm_version_major
# Expected: 2(for TPM 2.0)
 
# === Phase 2: Verify firmware measurements ===
# Read current PCR values
tpm2_pcrread sha256: 0, 1, 2, 3, 4, 5, 6, 7
 
# View TCG event log
    tpm2_eventlog / sys / kernel / security / tpm0 / binary_bios_measurements
 
# Verify event log matches PCR values
    tpm2_eventlog / sys / kernel / security / tpm0 / binary_bios_measurements \
    --verify - pcrs
 
# === Phase 3: Check Secure Boot status ===
        mokutil--sb - state
# Expected: SecureBoot enabled
 
# === Phase 4: IMA Configuration ===
# Check if IMA is enabled
    dmesg | grep - i ima
# Look for: "integrity: Platform Keyring initialized"
 
# View IMA policy(if loaded)
        cat / sys / kernel / security / ima / policy
 
# View IMA runtime measurements
    head - 20 / sys / kernel / security / ima / ascii_runtime_measurements
# Format: PCR template - hash algorithm: file - hash filename
 
# Example output:
# 10 abc123...ima - ng sha256:def456...boot_aggregate
# 10 fed321...ima - ng sha256: 123abc... /usr/sbin / init
# 10 aabbcc...ima - ng sha256:ddeeff... /usr/lib / systemd / systemd
 
# === Phase 5: TPM - backed LUKS encryption ===
# Check LUKS for TPM binding(using systemd - cryptenroll)
systemd - cryptenroll / dev / sda3--tpm2 - device=list
# Shows TPM binding status
 
# Enroll TPM for LUKS unlock
sudo systemd - cryptenroll / dev / sda3 \
    --tpm2 - device=auto \
    --tpm2 - pcrs=0 + 7  # Seal to PCR 0 and 7
 
# Verify enrollment
cryptsetup luksDump / dev / sda3 | grep - A5 "Token"

Unified Kernel Images (UKI) for Measured Boot

UKIs address a traditional weakness in Linux measured boot: the initramfs gap.

Traditional Problem:

Kernel is signed and measured
Initramfs is often not signed or measured (or measured too late)
Command line can be manipulated
Each component measured separately, complex to verify

UKI Solution: Bundle everything into a single signed PE binary:

┌───────────────────────────────────────────────┐
│          Unified Kernel Image(.efi)          │
├───────────────────────────────────────────────┤
│  .osrel    │ OS release information           │
│  .cmdline  │ Kernel command line(LOCKED)     │
│  .linux    │ Kernel image                     │
│  .initrd   │ Initramfs(compressed)           │
│  .splash   │ Boot splash image(optional)     │
│  .uname    │ Kernel version string            │
│  .sbat     │ UEFI revocation metadata         │
│  .pcrsig   │ Expected PCR values + signature  │
└───────────────────────────────────────────────┘

Benefits:

Single file to sign and verify
Command line cannot be modified
Initramfs included in measurement
.pcrsig section contains predicted PCR values for unsealing

Creating a UKI:

# Using ukify(systemd - ukify) 
ukify build \n--linux = /boot/vmlinuz - 6.1.0 \n--initrd = /boot/initramfs - 6.1.0.img \n--cmdline ="root=/dev/mapper/root ro quiet" \n    --os-release=@/etc/os-release \n    --output=/boot/efi/EFI/Linux/linux-6.1.0.efi \n    --secureboot-private-key=/path/to/key \n    --secureboot-certificate=/path/to/cert

IMA Deep Dive

The Integrity Measurement Architecture extends measured boot into the running system:

IMA Modes:

Mode	Description	Use Case
`measure`	Record hash to PCR	Attestation
`appraise`	Verify against stored signature	Enforcement
`audit`	Log measurements to audit log	Compliance

IMA Policy Example:

# /etc/ima/ima-policy

# Measure all executables run by root
measure uid=0 func=BPRM_CHECK

# Measure all kernel modules
measure func=MODULE_CHECK

# Measure all firmware loaded
measure func=FIRMWARE_CHECK

# Appraise (verify signatures) for all executables
appraise fowner=0 mode=0755 func=BPRM_CHECK appraise_type=imasig

# Audit all file opens by root
audit uid=0 func=FILE_CHECK

IMA + TPM Integration:

Measurements extended to PCR 10 (configurable)
Event log at /sys/kernel/security/ima/ascii_runtime_measurements
Binary log for remote attestation
Can be used with Keylime for continuous attestation

IMA Performance Considerations

Attestation Architectures

Measured boot provides the foundation; attestation architectures provide the verification infrastructure. Different use cases require different attestation models.

Local Attestation: Sealing Secrets

The simplest attestation model—the system attests to itself.

Use Case: Disk Encryption (BitLocker, LUKS+TPM)

During setup: Seal encryption key to current PCR values
On boot: TPM verifies PCRs before releasing key
No external verifier needed
Protects against offline attacks and boot tampering

Advantages:

No network dependency
No external infrastructure required
Immediate enforcement (key won't unseal if tampered)

Limitations:

No visibility into system state from outside
System must be configured correctly initially
Doesn't protect against runtime attacks

Implementation:

# LUKS with TPM sealing (systemd-cryptenroll)
sudo systemd-cryptenroll /dev/sda3 \n    --tpm2-device=auto \n    --tpm2-pcrs=0+7  # Seal to firmware and Secure Boot policy

Dynamic Root of Trust for Measurement (DRTM)

Why DRTM?

SRTM has a fundamental limitation: if any component in the early boot chain (SMM, Option ROMs, firmware drivers) is compromised, all subsequent measurements are suspect. DRTM addresses this by:

Resetting CPU state to a known-good configuration
Entering a protected execution mode
Measuring a new trusted environment from this clean slate
Using different PCRs (17-22) to record DRTM measurements

DRTM Technologies:

Intel TXT (Trusted Execution Technology)

Uses GETSEC[SENTER] instruction
Resets CPU state, clears caches
Loads and measures SINIT ACM (Intel-signed)
SINIT measures the Measured Launch Environment (MLE)
Hypervisor/OS boots in measured, protected state

AMD SKINIT (Secure Kernel Init)

Uses SKINIT instruction
Similar concept to Intel TXT
More streamlined (single instruction does everything)
Used by AMD SEV for VM attestation

Converting Mermaid diagram...

DRTM PCR Usage

PCR	Description
PCR 17	DRTM launch policy, SINIT ACM
PCR 18	MLE (Hypervisor/tboot policy)
PCR 19-22	Platform-specific DRTM measurements

DRTM Benefits:

Bypasses early boot compromises: SMM attacks, Option ROM attacks don't affect DRTM measurements
Late launch capability: Can establish trust on already-running systems
Smaller trusted computing base: Only the MLE needs to be trusted, not all firmware

Intel TXT with tboot (Linux)

tboot is a pre-kernel module that implements DRTM for Linux:

# Install tboot
sudo apt install tboot

# Configure GRUB to use tboot
# /etc/default/grub:
# GRUB_CMDLINE_TBOOT="..."

# tboot loads first, performs SENTER, then loads kernel
# Kernel boots in measured environment with PCRs 17-22 populated

# Verify DRTM measurements
txt-stat

Windows System Guard Secure Launch

System Guard uses DRTM to protect Hyper-V and VBS:

Triggered late in boot, after some firmware code runs
Resets CPU state before loading Hyper-V hypervisor
Hypervisor starts in clean, measured state
Protects VBS secrets even if SMM was compromised

When to Use DRTM vs. SRTM

Confidential Computing Integration

Measured boot provides the foundation for Confidential Computing—technologies that protect data in use by ensuring computations occur in hardware-attested trusted execution environments.

Intel SGX (Software Guard Extensions)

SGX creates isolated memory regions called enclaves:

Enclave Memory: Encrypted by CPU, inaccessible to OS/hypervisor
Remote Attestation: Enclave generates quote proving its code and data
Measured at Load: Enclave code is hashed when loaded
Quote includes: MRENCLAVE (code hash), MRSIGNER (author), user data

SGX Attestation Flow:

Application creates enclave
CPU measures enclave code → MRENCLAVE
Enclave generates quote (signed by Quoting Enclave)
Quote sent to Intel Attestation Service
Service verifies, returns attestation report
Remote party trusts enclave based on report

Use Cases:

Secure key management
Confidential smart contracts
Private machine learning inference

AMD SEV-SNP (Secure Encrypted Virtualization)

SEV-SNP protects entire virtual machines:

Memory Encryption: VM memory encrypted, unique key per VM
SNP (Secure Nested Paging): Integrity protection + attestation
Measured Launch: VM boot code measured by PSP
Report includes: VM measurement, policy, host configuration

SEV-SNP Attestation Flow:

VM launched on SEV-SNP capable host
AMD PSP measures initial VM state
VM requests attestation report from PSP
Report signed by AMD Root Key (verifiable)
Remote party verifies VM is genuine SEV-SNP VM
Secrets provisioned only to verified VMs

Use Cases:

Confidential cloud computing
Multi-tenant workload isolation
Trusted VM migration

Attestation Comparison

Technology	Granularity	Attested By	Trust Root
TPM Measured Boot	Whole system	TPM Quote	TPM EK → Manufacturer
Intel SGX	Application enclave	Quoting Enclave	Intel Root Key
AMD SEV-SNP	Virtual machine	AMD PSP	AMD Root Key
Intel TDX	Trust Domain	TDX Module	Intel Attestation
ARM CCA	Realm	RMM	ARM Security Root

Measured Boot → Confidential Computing Pipeline:

1. System boots with measured boot (TPM records)
2. Hypervisor launches confidential VM (SEV-SNP/TDX)
3. VM boot is measured by security processor
4. Application in VM creates enclave (SGX)
5. Each layer provides attestation:
   - TPM: "This host booted correctly"
   - SEV: "This VM is encrypted and genuine"
   - SGX: "This enclave runs expected code"
6. Remote verifier chains attestations
7. Secrets released only to fully verified stack

This layered attestation enables end-to-end verified computation, where data owners can verify every layer from hardware to application code before releasing sensitive data.

The Future of Attestation

Summary: Measured Boot Mastery

Measured boot brings together all the secure boot concepts we've explored—creating systems that are both protected and verifiable. Let's consolidate the essential knowledge:

Key Takeaways

•Secure Boot prevents, Measured Boot records — They're complementary: Secure Boot enforces known-good signatures; Measured Boot creates a verifiable record for attestation.
•The measurement chain extends from hardware to applications — CRTM → Firmware → Bootloader → Kernel → IMA, each layer measuring the next into TPM PCRs.
•Windows and Linux have comprehensive implementations — Bitlocker with TPM, System Guard, IMA, UKIs, and systemd-cryptenroll provide production-ready measured boot.
•Attestation architectures verify boot state — Local (sealing), remote (network access), and continuous (runtime monitoring) patterns serve different use cases.
•DRTM provides late-boot trust establishment — Intel TXT and AMD SKINIT reset CPU state to bypass potential early-boot compromises.
•Confidential computing extends attestation — SGX, SEV-SNP, TDX layer additional attestation on top of measured boot for end-to-end verification.
•Unified Kernel Images solve Linux gaps — UKIs bundle kernel, initramfs, and cmdline into one signed binary, closing verification gaps.

Module Complete: Secure Boot Mastery

You have now completed a comprehensive exploration of secure boot technologies:

Page 1: Trusted Boot Process — The foundational concepts of trust establishment
Page 2: UEFI Secure Boot — The industry-standard implementation
Page 3: Boot Chain Verification — How each stage verifies the next
Page 4: TPM — The hardware that records and attests boot state
Page 5: Measured Boot — Combining prevention and verification

Module Complete

5 / 5