TPMs and Secure Boot Explained

A Trusted Platform Module (TPM) is a small, standardized security chip that provides a hardware root of trust for a computer, while Secure Boot uses digital signatures to ensure that only trusted code runs during startup. Together they let a device prove that it booted a known, untampered software stack. This pairing underpins full-disk encryption, device attestation, and defenses against boot-level malware such as bootkits and rootkits that would otherwise load before the operating system and evade detection.

What a TPM Is

A TPM implements a published specification, most commonly the TPM 2.0 standard, and can be a discrete chip, firmware running in a protected processor mode, or logic integrated into a system-on-chip. Whatever its form, it offers a consistent set of security functions:

• Generation and protected storage of cryptographic keys in shielded locations.
• A hardware random number generator.
• Platform Configuration Registers (PCRs) that record measurements of the boot process.
• Sealing, which binds secrets to a specific platform state.
• Attestation, which lets the device report its state to a remote verifier.

A TPM is intentionally lightweight compared with a full hardware security module; it is a low-cost root of trust focused on platform integrity rather than high-volume cryptographic processing.

Platform Configuration Registers and Measured Boot

The heart of TPM-based integrity is the PCR, a special register with an unusual rule: it cannot be freely overwritten, only extended. Extending folds a new measurement into the existing value through a one-way hash, so the register accumulates an order-sensitive record of everything measured:

# Measured boot: each stage hashes the next into a PCR before running it
PCR[n] = SHA256( PCR[n]  ||  measure(next_component) )
# Any change to firmware, bootloader, or kernel changes the final PCR values

In measured boot, each boot stage measures the next component into a PCR before handing off control. The result is a chain: firmware measures the bootloader, the bootloader measures the kernel, and so on. The final PCR values are a fingerprint of the exact code that ran, and any tampering produces different values.

Secure Boot Versus Measured Boot

Secure Boot and measured boot are complementary, and the difference matters.

Secure Boot is an enforcement mechanism, typically implemented in UEFI firmware. Before executing each component, the firmware verifies its digital signature against a set of trusted keys, and it refuses to run anything unsigned or untrusted. Its key hierarchy, including the platform key, key exchange keys, and the allow and deny databases, decides what is permitted to load.

Measured boot does not block anything. It records what actually ran into the TPM's PCRs so that the boot can be evaluated afterward. In short, Secure Boot *prevents* untrusted code from running, while measured boot *proves* what did run. Used together, one stops known-bad code and the other provides verifiable evidence.

Sealing Secrets to Platform State

Sealing is a TPM operation that encrypts data so it can only be decrypted, or unsealed, when the PCRs hold specific expected values. This ties a secret to a known-good boot state.

Full-disk encryption is the classic application. The disk encryption key is sealed to the TPM against the expected PCR values, allowing the system to unlock automatically only when it boots the trusted software stack. If an attacker alters the firmware or bootloader, or moves the drive to another machine, the PCRs no longer match and the TPM withholds the key, defeating offline tampering.

Remote Attestation

Beyond local sealing, a TPM can prove its state to a remote party through remote attestation. The TPM produces a signed quote over its PCR values using an attestation key, and a verifier compares those values against a known-good reference.

This enables device health checks in a zero-trust architecture, where access is granted only to endpoints that can demonstrate a trustworthy boot state. The same conceptual pattern, hardware-signed evidence of integrity, also appears in trusted execution environments.

Threat Model and Limits

A TPM and Secure Boot are powerful but bounded. They defend well against boot-level tampering, unsigned malware loading early, and offline attacks on an encrypted disk. They do not, however, protect a running operating system that is later compromised through a network service, and a TPM is not a general-purpose secure execution environment.

Physical attackers can also target a discrete TPM by sniffing the bus between it and the processor, which motivates firmware TPMs, integrated designs, and encrypted communication sessions. As always, these controls are one layer of defense in depth rather than a complete solution on their own.

Key Takeaways

• A TPM is a standardized hardware root of trust for keys, random numbers, measurement, sealing, and attestation.
• PCRs accumulate boot measurements through one-way extension, producing a fingerprint of exactly what ran.
• Secure Boot prevents untrusted code from executing, while measured boot proves what executed.
• Sealing binds secrets such as disk encryption keys to a trusted boot state, defeating offline tampering.
• TPMs protect the boot chain but are not a general secure execution environment, and discrete chips can face bus-level physical attacks.