Secure Boot: Establishing Trust from Power-On

Hidden on your motherboard—or increasingly, embedded within your CPU—sits a specialized security chip that observes every step of your system's boot process. This is the Trusted Platform Module (TPM), a cryptographic coprocessor that serves as an unforgeable witness to what actually booted on your system.

Unlike Secure Boot, which prevents unauthorized code from running, the TPM records exactly what ran. It maintains a tamper-evident log that can later be used to prove the system's state—to itself, to disk encryption systems, to corporate security infrastructure, or to cloud attestation services. If Secure Boot is the guard at the gate, the TPM is the security camera that records everyone who passed through.

The Trusted Platform Module is specified by the Trusted Computing Group (TCG), an industry consortium. The current specification is TPM 2.0, which replaced TPM 1.2 and offers significantly enhanced cryptographic capabilities and flexibility.

TPM Implementation Types

TPMs come in several physical forms:

Discrete TPM (dTPM)

• Separate chip on the motherboard
• Connected via LPC, SPI, or I2C bus
• Highest isolation—separate silicon
• Required by some high-security standards
• Examples: Infineon SLB9670, Nuvoton NPCT750

Firmware TPM (fTPM)

• Implemented in platform firmware
• Runs on the platform security processor (Intel PTT, AMD fTPM)
• Uses isolated execution environment
• Lower cost, increasingly common
• Dependent on security processor integrity

Hypervisor TPM (vTPM)

• Virtual TPM for virtual machines
• Backed by hypervisor-managed state
• State stored in VM configuration
• Enables TPM features for VMs

Software TPM (sTPM)

• Pure software implementation
• For development and testing only
• NOT secure—no hardware protection
• Examples: IBM's TPM2-software, Microsoft simulator

Platform Configuration Registers are the heart of TPM measurement functionality. Each PCR is a fixed-size register that accumulates cryptographic measurements—a running record of everything measured into it since the last reset.

The Extend Operation

PCRs cannot be directly written. Instead, they are extended using a cryptographic operation:

PCR_new = Hash(PCR_old || data_to_measure)

This operation is fundamental:

• One-Way: Given a PCR value, you cannot determine what was measured (hash pre-image resistance)
• Order-Sensitive: Measuring A then B produces different result than B then A
• Tamper-Evident: Any modification to measured components changes the final PCR value
• Irreversible: You cannot 'undo' a measurement or set PCR to arbitrary value

The only way to reset most PCRs to their initial value is to reboot the system.

Standard PCR Allocation

The TCG specification defines standard PCR assignments for platform firmware and operating systems:

OS-Specific PCR Usage

Linux PCR Conventions:

• PCR 8: GRUB command line and configuration
• PCR 9: Boot loader code (GRUB, shim)
• PCR 10: Kernel (using IMA)
• PCR 11-14: Reserved for IMA

Windows PCR Conventions:

• PCR 11: BitLocker sealing
• PCR 12-14: Windows-specific boot data

Multiple PCR Banks (TPM 2.0)

TPM 2.0 maintains separate PCR banks for different hash algorithms. Each bank has a complete set of 24 PCRs:

┌──────────────────────────────────────────────────────────────┐
│                     TPM 2.0 PCR Banks                        │
├──────────────────────────────────────────────────────────────┤
│ SHA-1 Bank:   PCR[0..23] (160 bits each) - Legacy compat    │
│ SHA-256 Bank: PCR[0..23] (256 bits each) - Primary use      │
│ SHA-384 Bank: PCR[0..23] (384 bits each) - Optional         │
│ SHA-512 Bank: PCR[0..23] (512 bits each) - Optional         │
└──────────────────────────────────────────────────────────────┘

When firmware extends a measurement, it typically extends the same data into all active PCR banks simultaneously.

The TPM manages cryptographic keys in a hierarchical structure. This hierarchy provides organization, access control, and key derivation capabilities.

The Four Hierarchies (TPM 2.0)

1. Endorsement Hierarchy

• Contains the TPM's identity keys
• Endorsement Key (EK) is unique per TPM, certified by manufacturer
• Used for attestation and proving TPM genuineness
• Authorization: Endorsement password (often empty by default)

2. Storage Hierarchy

• Primary hierarchy for user/application keys
• Storage Root Key (SRK) is the parent of all user keys
• Sealing keys, signing keys, encryption keys derived here
• Authorization: Owner password

3. Platform Hierarchy

• Controlled by firmware/platform manufacturer
• Used for platform-specific functions
• Often reset on ownership change
• Authorization: Platform password (firmware-controlled)

4. Null Hierarchy

• Ephemeral keys for current session only
• Lost on TPM reset
• No authorization required
• Useful for transient cryptographic operations

Endorsement Key (EK) Deep Dive

The EK is the TPM's identity:

Creation:

• Derived deterministically from the Endorsement Primary Seed
• Same seed always produces same EK
• EK cannot be exported—private portion never leaves TPM

Certification:

• TPM manufacturer creates an EK certificate during production
• Certificate attests that this EK belongs to a genuine TPM
• Certificate can be verified against manufacturer's CA
• Enables trust in TPM-generated attestations

Privacy Considerations: The EK uniquely identifies the TPM (and thus the machine). Using the EK directly for attestation has privacy implications—the same key identifies the device across all interactions.

Attestation Keys (AK) / AIK: To address privacy, the TPM can create Attestation Keys under the Endorsement hierarchy:

• AK signed by EK, proving it's from this TPM
• Different AKs for different services
• Services see different keys, can't correlate
• Privacy-CA protocols enable zero-knowledge attestation

One of the TPM's most powerful capabilities is sealing—the ability to encrypt data such that it can only be decrypted when the system is in a specific state, as measured by PCR values.

Binding vs. Sealing

Binding encrypts data to a TPM key:

• Data can only be decrypted by this specific TPM
• No PCR constraints—decryption always works if you have authorization
• Use case: Protecting data to a specific device

Sealing encrypts data to a TPM key AND PCR values:

• Data can only be decrypted when PCR values match
• If any measured component changes, unsealing fails
• Use case: Disk encryption that only works on unmodified systems

BitLocker TPM Integration

Microsoft BitLocker uses TPM sealing extensively:

Seal to PCRs 0, 2, 4, 7, 11 (typical configuration):

• PCR 0: Core BIOS code
• PCR 2: Option ROM code
• PCR 4: Boot loader code (MBR/bootmgr)
• PCR 7: Secure Boot policy
• PCR 11: BitLocker-specific

Protection Provided:

• If BIOS is modified: PCR 0 changes → Cannot decrypt
• If bootloader is replaced: PCR 4 changes → Cannot decrypt
• If Secure Boot policy changes: PCR 7 changes → Cannot decrypt

BitLocker Key Protectors: BitLocker can have multiple 'protectors' for the encryption key:

• TPM only: Automatic unlock if PCRs match
• TPM + PIN: PCRs must match AND user enters PIN
• TPM + USB key: PCRs must match AND USB key present
• Recovery key: Bypass for emergency recovery

Automatic PCR Re-Sealing: When you install a firmware update, PCR values will change. BitLocker handles this by:

1. Reading the key using current (old) PCR values
2. Re-sealing to new PCR values after update
3. This requires administrative access

While PCR values tell you whether the system state matches an expected configuration, they don't tell you what actually booted. That's where the Event Log comes in—a detailed record of every measurement extended into the PCRs.

Measured Boot Flow

1. CRTM (Core Root of Trust for Measurement) extends its own hash into PCR 0
2. For each subsequent component loaded:
   • Compute hash of the component
   • Create a TCG Event Log entry describing what's being measured
   • Extend the hash into the appropriate PCR
3. Record continues through firmware, bootloader, and optionally into the OS
4. Event Log is stored in memory, accessible to OS and attestation services

Event Log Structure (TCG Format)

Each event log entry contains:

┌──────────────────────────────────────────────────────────────┐
│ TCG_PCR_EVENT2 Structure                                     │
├──────────────────────────────────────────────────────────────┤
│ PCRIndex      │ Which PCR was extended (0-23)                │
├───────────────┼──────────────────────────────────────────────┤
│ EventType     │ What kind of measurement (EV_EFI_*, etc.)    │
├───────────────┼──────────────────────────────────────────────┤
│ Digests[]     │ Array of hashes, one per PCR bank           │
├───────────────┼──────────────────────────────────────────────┤
│ EventSize     │ Size of event data                           │
├───────────────┼──────────────────────────────────────────────┤
│ Event[]       │ Variable-length event data (what was hashed)│
└───────────────┴──────────────────────────────────────────────┘

Common Event Types:

• EV_EFI_VARIABLE_DRIVER_CONFIG: UEFI variable measurement
• EV_EFI_BOOT_SERVICES_APPLICATION: Bootloader/application measurement
• EV_EFI_ACTION: String describing an action
• EV_IPL: Initial Program Loader events
• EV_SEPARATOR: Marks firmware-to-OS transition

Linux Integrity Measurement Architecture (IMA)

IMA extends measured boot into the operating system, measuring files as they're accessed:

IMA Measurement Flow:

1. File is opened for reading/execution
2. IMA hooks the kernel file access
3. File contents are hashed
4. Hash is extended into PCR 10 (or configured PCR)
5. Entry is added to IMA measurement list

IMA Policy Examples:

# Measure all executables
measure fowner=0 func=BPRM_CHECK

# Measure all files opened by root
measure uid=0 func=FILE_CHECK

# Measure kernel modules
measure func=MODULE_CHECK

# Measure firmware loaded by kernel
measure func=FIRMWARE_CHECK

IMA Use Cases:

• Remote attestation of running software
• Detecting unauthorized binaries
• Audit trail for compliance
• Container image verification

Remote attestation allows an external party (verifier) to determine the state of a system (attester) without trusting that system's software. The verifier receives a cryptographically signed statement of the system's boot state, verifiable back to the TPM manufacturer.

Quote: Signed PCR Statement

A TPM quote is a signed statement of PCR values:

Quote = Sign_AK(TPMS_QUOTE_INFO)

TPMS_QUOTE_INFO = {
    magic: TPM_GENERATED,       # Proves TPM generated this
    type: TPM_ST_ATTEST_QUOTE,  # Quote type identifier  
    qualifiedSigner: AK name,   # Identifies signing key
    extraData: nonce,           # Verifier's challenge
    clockInfo: {                # TPM clock state
        clock, resetCount, restartCount
    },
    firmwareVersion: ...,       # TPM firmware version
    attested: {                 # The actual attestation
        pcrSelect: [0,1,7],     # Which PCRs are attested
        pcrDigest: SHA256(      # Hash of selected PCR values
            PCR[0] || PCR[1] || PCR[7]
        )
    }
}

The nonce (challenge) prevents replay attacks—an attacker can't reuse an old quote from when the system was in a good state.

Real-World Attestation Systems

Microsoft Azure Attestation

• Cloud service for attesting VMs and containers
• Verifies guest boot state before releasing secrets
• Supports SEV-SNP (AMD), TDX (Intel) and TPM attestation
• Issues attestation tokens (JWTs) for verified systems

Keylime

• Open-source remote attestation framework
• Continuous monitoring of system state
• Agent runs on attested systems, verifier on central server
• Automatic remediation actions on attestation failure

SPIFFE/SPIRE with TPM Attestation

• Workload identity framework
• TPM attestation as node attestation method
• Issues short-lived X.509 certificates to verified nodes

Intel Trust Authority

• Intel's attestation service
• Supports SGX enclaves, TDX VMs, and standard TPM
• Provides attestation policies and tokens

Enterprise Use Cases:

• Zero Trust Network Access: Only attested devices get network access
• Confidential Computing: Secrets released only to verified TEEs
• Compliance Verification: Prove systems boot approved configurations
• Supply Chain Security: Verify device hasn't been tampered with

While TPMs provide powerful security capabilities, they are not invulnerable. Understanding TPM limitations and attack vectors is essential for proper security architecture.

TPM-FAIL Vulnerability (CVE-2019-11090, CVE-2019-16863)

In 2019, researchers demonstrated timing side-channel attacks against TPM ECDSA signature operations:

• Affected TPMs from Intel (fTPM), STMicroelectronics, and others
• Attackers could recover private keys by measuring signature timing
• Mitigated by firmware updates implementing constant-time algorithms

Lesson: Even dedicated security hardware can have implementation vulnerabilities. Keep TPM firmware updated.

BitLocker-Specific Considerations

BitLocker's transparent TPM unlock (no PIN) is vulnerable to certain attacks:

Attack: Direct Memory Access

• Attacker with physical access can use DMA (Thunderbolt, FireWire) to read memory
• BitLocker key in memory could be extracted
• Mitigation: Kernel DMA Protection, VBS, TPM+PIN mode

Attack: Cold Boot

• RAM contents persist briefly after power-off
• Freeze RAM, move to attacker's system, read key
• Mitigation: TPM+PIN makes unlock not automatic

Attack: Evil Maid (Steal and Observe)

• Attacker modifies boot so it appears normal but logs credentials
• User boots and enters credentials
• Attacker retrieves credentials
• Mitigation: Pre-boot authentication different from OS login

The Trusted Platform Module provides a hardware foundation for platform security that goes beyond simple boot verification. Let's consolidate the key concepts:

What's Next:

With a comprehensive understanding of both Secure Boot (prevention) and TPM (measurement), we'll explore Measured Boot in depth—how these technologies combine to provide both enforcement and verifiability. We'll examine practical measured boot implementations, remote attestation architectures, and how confident computing builds on these foundations.