The Trusted Platform Module

The Trusted Platform Module

Speakers: Eric Chiang, Co-founder and CTO, Oblique

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=As2yo2Jrw8w

Overview

The talk "The Trusted Platform Module," delivered by Eric Chiang at BSides SF, delves into the intricate world of the Trusted Platform Module (TPM), a hardware component designed to enhance system security. Chiang, co-founder and CTO of Oblique and a former Google security engineer, provides a comprehensive yet critical examination of TPM functionalities, ranging from secure key storage and cryptographic operations to system boot integrity measurements and remote attestation. The presentation aims to demystify this complex hardware, highlighting its theoretical capabilities alongside the practical challenges and limitations encountered in real-world implementations, particularly within enterprise and cloud environments.

Chiang's discussion goes beyond a mere technical exposition, revealing the often-overlooked complexities and "cursed" aspects of TPM deployment. He shares insights from his extensive experience, including his work on Google's internal Linux distribution (G Linux), to illustrate how seemingly straightforward security objectives with TPMs can quickly devolve into significant operational and architectural hurdles. The talk serves as a crucial resource for security professionals, developers, and system administrators seeking to understand the true scope and limitations of TPMs, urging a cautious and informed approach rather than viewing them as a panacea for all hardware security problems. It underscores the critical distinction between the TPM's robust API specification and the often-messy reality of its integration and verification.

Background

▶ Watch: Introduction to speaker, agenda, and acknowledgements (0:00)

The Trusted Platform Module (TPM) is not a single piece of hardware but rather an API specification spanning thousands of pages, designed to provide hardware-based security functions. This specification can be implemented in various forms: as a discrete hardware module that can be physically inserted into a motherboard, as a firmware TPM (fTPM) integrated directly into the CPU, or increasingly, as virtualized TPMs offered by cloud providers, whose underlying implementation details are often opaque. Despite its complexity, interacting with a TPM can be relatively straightforward at an API level, typically involving opening a device file like /dev/tpm0 on Linux systems and sending commands. For instance, a simple Go package can request 16 bytes of random data, demonstrating its capability as a secure, albeit inefficient, random number generator.

The core functionalities of a TPM are diverse and foundational to modern system security. Primarily, TPMs are renowned for storing private keys, ensuring that these keys never leave the secure hardware module, thus guaranteeing physical presence for their use. Beyond keys, TPMs can hold arbitrary secrets, commonly employed for disk encryption keys, which are read out during the boot process. A more advanced and complex function involves measuring boot processes. This entails recording cryptographic hashes of critical boot components—such as firmware, bootloaders, and secure boot configurations—into Platform Configuration Registers (PCRs). These measurements enable remote attestation, allowing a system to cryptographically prove its boot state or the secure storage of a key to a remote server, thereby establishing a chain of trust. As Chiang notes, while one might start with a simple use case, the interconnected nature of these functionalities often leads to broader engagement with the TPM's capabilities, quickly revealing its inherent complexities.

Key Findings

▶ Watch: Practical example: Interacting with the TPM via Linux (2:50)

Eric Chiang's talk unveils several critical findings that challenge common perceptions of the TPM as a straightforward security solution. A central theme is the significant gap between the TPM's robust specification and the complexities of its practical implementation and verification.

Firstly, Chiang highlights the resource-constrained nature of TPMs. Despite their secure cryptographic capabilities (supporting RSA and ECDSA, though notably lacking ED25519), their performance is often a bottleneck. He cites benchmarks showing RSA signatures taking 300-400 milliseconds, emphasizing that TPMs are a limited resource and cannot be used for all cryptographic operations within a system. This constraint necessitates careful architectural planning to avoid performance degradation.

Secondly, the speaker underscores the extreme difficulty in verifying boot state measurements via Platform Configuration Registers (PCRs) and event logs. While the concept of rolling hashes to ensure boot integrity sounds simple, the reality is fraught with challenges. Manufacturers often don't provide reliable hashes for firmware, making it impossible to establish a baseline. Legitimate updates (e.g., secure boot certificate bundles) can unpredictably alter PCR values, leading to scenarios where users are locked out of disk-encrypted systems. Moreover, Chiang revealed a significant parsing subtlety in event logs, where the event type was not included in the digest. This allowed him to craft malicious event logs that passed validation, leading to a CVE in a Windows product. This discovery starkly illustrates that even widely deployed systems might not correctly implement or verify TPM features, suggesting a lack of widespread practical adoption of full event log validation.

Finally, Chiang concludes that while storing keys in a TPM and identifying devices (especially with cloud provider APIs) can be effective, attempting to verify the boot state is "gnarly" and often leads to a "now you have two problems" scenario. He suggests that despite the theoretical promise, many organizations struggle to achieve resounding success with comprehensive TPM attestation. This critical assessment serves as a key finding, urging practitioners to approach TPM-based security with a deep understanding of its practical limitations and the significant expertise required for successful implementation.

Technical Deep Dive

▶ Watch: Core TPM functionalities: keys, secrets, boot measurements (4:00)

The Trusted Platform Module's technical architecture is built upon a sophisticated framework for key management, attestation, and boot integrity. At its core, the TPM maintains a key hierarchy, a structured system where different types of keys serve distinct roles. While the specific details can be intricate, the essential concept is that keys can attest to other keys, even across different hierarchies, allowing for the proof of a key's presence and specific metadata within the TPM.

TPMs support a range of cryptographic algorithms, primarily RSA and ECDSA, reflecting the cutting edge of cryptography from the early 2000s. Notably absent for modern use cases is ED25519. Keys can be restricted, meaning they can only sign challenges about the TPM itself, or non-restricted, allowing them to sign arbitrary data for applications like TLS connections or SSH. An interesting, albeit antiquated, feature is the existence of decryption-only keys, which cannot sign but are intended for privacy-preserving decryption operations. Performance is a significant consideration; RSA signatures can take 300-400 milliseconds, while ECDSA is faster, underscoring the TPM's role as a limited resource for critical, infrequent operations rather than high-throughput cryptography.

Attestation is a cornerstone of TPM functionality, enabling a system to cryptographically prove certain facts about itself or its keys. For decryption-only keys, this process is called credential activation. A remote server creates an encrypted challenge for the key, which the TPM decrypts and returns along with key metadata (e.g., restricted status, exportability). This decryption-only key is often then converted into a signing key for simpler credential certification, where the TPM merely signs a challenge and returns it, proving its control over the key.

The initial trust anchor for attestation relies on the endorsement key (EK). TPMs leverage seeds, random bits of data within the module, to enable deterministic generation of public and private key material. This means that given the same template parameters, the same TPM will consistently produce the same EK pair. Manufacturers can sign EK certificates over this key, which are often stored in NVRAM, allowing the identity of a TPM to be chained back to its manufacturer. Theoretically, platform certificates would further chain this to the device manufacturer, enabling remote identification of a device down to its serial number. However, Chiang notes that achieving this ideal chain of trust is often challenging in practice, with manufacturers frequently unaccustomed to acting as certificate authorities. The NSA, for example, has published guidance requiring platform certificates to facilitate remote device attestation for employees.

Beyond key management, TPMs play a crucial role in boot integrity through Platform Configuration Registers (PCRs). A TPM contains 24 PCRs, which are running hashes that record boot measurements. As the computer boots, components like the UEFI firmware extend these PCRs. The process involves taking the old PCR state, concatenating it with a new digest (e.g., a hash of the next boot component), and then hashing the combined value to produce the new PCR state. This one-way hashing ensures that once a state is recorded, it cannot be reversed, providing an immutable log of boot events. The TPM can then attest to these PCR states by signing them along with a fresh challenge using an Attestation Identity Key (AIK), producing a quote. This quote provides cryptographic assurance of the boot state, independent of the host system's trustworthiness.

To provide granular detail beyond the final PCR digest, an event log is maintained externally to the TPM. Every time a PCR is extended, corresponding events are written to this log, detailing what was measured and which PCR was affected. A remote verifier can then independently re-roll the digests using the event log and compare the final hash with the quoted PCR values. If they match, confidence in the event log's authenticity is established, providing a complete history of the boot process. However, this process is plagued with practical difficulties. Determining the "correct" hash for firmware is often impossible. Legitimate system updates, such as secure boot certificate changes, alter PCR values, potentially locking users out of disk-encrypted systems bound to specific PCR states.

A particularly critical discovery by Chiang and his colleagues highlights a parsing subtlety: the event type was not included in the digest calculation for event logs. This vulnerability allowed an attacker to change event types to unrecognized values and then append malicious events, all while the re-rolled digest would still match the quoted PCRs. This flaw, which earned Chiang a CVE in a Windows product, demonstrated that even sophisticated systems might not properly validate event logs, suggesting a lack of robust, widespread implementation of this verification mechanism.

Disk encryption is another common use case, leveraging TPM policies to bind access to encryption keys. Policies can be based on user-supplied PINs or, more securely, on the state of specific PCRs. For instance, Windows BitLocker typically binds the disk encryption key to PCRs 7 and 11. PCR 7 measures the secure boot state, while PCR 11 is used by the operating system. If the secure boot state is correct, the boot manager can access the disk encryption key, which then immediately extends PCR 11, preventing future access to that specific key value. Chiang notes the architectural challenge of bootstrapping such a system, questioning where the initial unencrypted components reside and how the overall trust chain is established. He also points out a known vulnerability with discrete TPMs, where BitLocker keys can be sniffed from the bus, a risk mitigated by fTPMs co-located with the CPU. While encrypted sessions to the TPM are technically possible, they are often prohibitively expensive, leading to features like Linux disabling them by default.

Finally, Chiang touched upon the state of TPM integration in Linux. His experience with G Linux revealed that much of Google's secure boot and PCR measurement work was highly customized and not easily generalizable to upstream distributions. However, recent efforts, spearheaded by systemd maintainer Lennart Poettering, are aiming to standardize the Linux boot process for TPM integration. Initiatives like the Linux user space API (UAPI) group are defining standards for unified kernel images (UKIs)—combining the bootloader, initramfs, and kernel into a single signed entity—and working to standardize the set of Linux TPM PCRs. This standardization is critical for enabling consistent and verifiable TPM attestation across diverse Linux distributions, moving beyond philosophical debates about "is disk encryption enabled" to concrete, measurable states.

Demo / Proof of Concept

▶ Watch: Understanding the TPM's complex key hierarchy and roles (5:00)

While Eric Chiang's talk did not feature a live, interactive demonstration or a traditional proof-of-concept execution, he effectively illustrated key technical interactions and the discovery of a significant vulnerability. He presented a code snippet using a Go package by Google that interacts with the TPM via /dev/tpm0 to request 16 bytes of random data. This example served to show the fundamental ease of communicating with the TPM API, assuming appropriate permissions (typically root).

More notably, Chiang detailed his discovery of a parsing subtlety in event logs that led to a CVE in a Windows product. He explained how the absence of the event type from the digest calculation allowed for the injection of malicious events into an event log, which would still pass replay validation against quoted PCR values. This was not a live exploit demonstration but a clear explanation of a discovered vulnerability, demonstrating a profound understanding of TPM internals and their implementation flaws. He also alluded to the general concept of "sniffing the bus" to extract BitLocker keys from discrete TPMs, highlighting a known architectural weakness rather than performing a live exploit. Thus, while lacking a live demo, the talk provided compelling evidence of TPM interactions and vulnerabilities through code examples and detailed technical breakdowns.

Defensive Implications

▶ Watch: Supported cryptography (RSA, ECDSA) and key restrictions (6:00)

The insights from Eric Chiang's talk offer crucial defensive implications for organizations and individuals leveraging or considering TPMs for enhanced security. The overarching message is one of cautious optimism, emphasizing that TPMs are powerful tools but demand significant expertise and careful implementation to be effective.

Firstly, defenders should approach TPMs with a realistic understanding of their limitations and complexities. While key storage is a relatively straightforward and beneficial use case, especially when coupled with cloud provider APIs that abstract away some of the underlying "gnarly" infrastructure, comprehensive boot state attestation is exceedingly difficult. Organizations must be prepared for the substantial effort required to establish baselines, manage legitimate changes to boot components, and correctly parse and validate event logs. This implies a need for dedicated security engineering resources with deep low-level system knowledge.

Secondly, the discovery of the CVE related to event log parsing underscores the importance of thorough validation of all TPM-related data. Defenders cannot assume that off-the-shelf software or even established specifications are perfectly implemented. Any system relying on event logs for integrity verification must implement robust, comprehensive parsing and digest re-calculation that accounts for all relevant data fields, even those not explicitly stated as part of the digest in initial specifications. This may involve custom tooling and a continuous auditing process.

Thirdly, for environments utilizing discrete TPMs, particularly for disk encryption solutions like BitLocker, the risk of bus sniffing for key extraction must be acknowledged and mitigated. While fTPMs (firmware TPMs) integrated into the CPU offer better protection against this specific attack vector, organizations with older hardware or specific discrete TPM deployments need to assess this physical security risk.

Finally, the efforts by the Linux user space API (UAPI) group and systemd to standardize Linux TPM PCRs and the unified kernel image (UKI) should be closely monitored and adopted where possible. Standardization will significantly ease the burden of implementing and verifying TPM-based security on Linux distributions. Defenders should advocate for and contribute to these standardization efforts to foster a more secure and manageable ecosystem. Ultimately, the defensive posture should be one of informed skepticism and diligent verification, recognizing that the TPM is a foundational component that, if not properly understood and implemented, can introduce its own set of complex security challenges.

Key Takeaways

• TPMs are complex and resource-constrained: They are powerful for specific security tasks but are not a universal solution. RSA signatures, for example, can take hundreds of milliseconds, limiting their use to infrequent, critical operations.
• Key storage is effective, attestation is challenging: Storing keys securely within the TPM is a primary benefit. However, comprehensive remote attestation of boot states using PCRs and event logs is "gnarly" due to issues like firmware hash availability, dynamic state changes, and parsing subtleties.
• Event log validation is critical and often flawed: The speaker's discovery of a CVE (where event types were not part of the digest) highlights that event logs, while providing granular boot history, are prone to implementation flaws that can undermine their integrity verification.
• Standardization is crucial for Linux adoption: Efforts by systemd and the Linux UAPI group to standardize PCR usage and boot processes (e.g., Unified Kernel Images) are vital for making TPM-based security more reliable and manageable across diverse Linux distributions.
• Beware of "now you have two problems": Treating the TPM as a magic bullet for security can introduce new, complex challenges if its intricate architecture, performance limitations, and real-world implementation quirks are not thoroughly understood and managed.

About the Speaker(s)

Eric Chiang is the co-founder and CTO of Oblique, a startup specializing in group management. Prior to his current role, he spent approximately six to eight years working in Google's corporate security division. In a previous lifetime, he was also involved with the Kubernetes special interest group (SIG). Chiang's work at Google, particularly on G Linux (Google's internal Linux distribution), heavily involved TPMs and attestation, forming the basis for much of the expertise shared in this talk. He also acknowledged contributions from Matthew Garrett, Tom Detto, and Brandon Weekes to the work discussed.