PaperlayerView exact revision on arXiv

Source-linked AI summary

TPMSpy: Validation of Measured Boot Systems by Low-Level Tracing of TPM Usage

Roman Lacko, Petr Svenda

arXiv:2609.05011v1cs.CR

TL;DR

Measured Boot security depends on whether systems measure expected components under expected conditions, a property not checked systematically. The paper introduces platform-agnostic virtualization-based TPM tracing to independently reconstruct and validate Event Logs, and applies it across Linux and Windows. The analysis finds increasing PCR use but divergent behavior and measurements stored outside the Event Log, affecting remote attestation.

  • Problem

    The paper addresses the lack of systematic checking that Measured Boot implementations measure expected components under expected conditions.

  • Method

    The paper uses a virtual TPM interposer to observe complete system–TPM communication and reconstruct and validate TPM Event Logs independently of the quoting mechanism.

  • Results

    Measured Boot usage increasingly employed PCRs but diverged across systems, while systemd user-space and IMA measurements were stored outside the TPM Event Log.

  • Takeaways & Limitations

    Measurements outside the TPM Event Log can cause an appraiser unaware of their locations to fail to attest to the measured values.

  • Takeaways & Limitations

    The method verifies TPM Event Log completeness but cannot guarantee that every boot-executed component was measured.

Abstract

from arXiv · show

Measured Boot extends trust in a booted system by recording cryptographic measurements of executed software and system state into a Trusted Platform Module (TPM), enabling subsequent verification through remote attestation. Although this mechanism is increasingly deployed in contemporary operating systems, its practical security depends on whether implementations measure the expected components under the expected conditions, yet this is not checked systematically. We propose a platform-agnostic method for analysing low-level TPM usage at the level of virtualized system--TPM interactions. It enables independent reconstruction and validation of the TPM Event Log without relying on the quoting mechanism itself. Because it does not depend on implementation details, it is applicable to both open and closed systems. We demonstrate the method on both Linux and Windows and conduct a systematic longitudinal analysis of Linux systems with systemd versions 245--258 (2020--2025), examining how Measured Boot usage evolved and observing wide divergence. No single usage pattern emerged amongst systems, warranting customized analysis. The analysis identifies undocumented behavioural changes, reveals inconsistent measurements of user-space systemd services, which prevent reliable remote attestation and LUKS disk decryption on such systems.

1 Introduction

Measured Boot records executed-component identities in a TPM for later remote attestation, but its security depends on complete, condition-appropriate measurements. The paper therefore develops and applies systematic methods to validate TPM usage and its documented behavior.

  • Measured Boot records identities of executed components for later evaluation during remote attestation, while Verified Boot permits only known components to run.The collected evidence can also support automatic unlocking of encrypted volumes such as BitLocker and LUKS.
  • TPMs receive chained measurements of the next component and use cryptographic hashing to prevent malicious components from retrospectively erasing traces.The appraiser requests TPM-signed register values as part of attestation.
  • Systemd has documented its TPM utilization since version 248, enabling transparent attestation-policy development but requiring behavioral validation.The paper explicitly frames documentation-versus-behavior alignment as a completeness-checking goal.
  • The study asks whether TPM Event Logs can be independently reconstructed, how systemd-based Linux Measured Boot evolved, and whether observed PCR use matches systemd documentation.These questions cover independent validation, longitudinal ecosystem analysis, and documentation conformance.
  • The paper contributes a platform-agnostic virtualized TPM-tracing method, a systemd analysis spanning versions 245–258, and an identified inconsistency affecting attestation for encrypted root volumes.It also surveys principal TPM-usage-tracing options and releases source code and experiment configurations.

2 Background: Protecting the Integrity of Boot Process

Verified Boot blocks unauthorized components, whereas Measured Boot records evidence for later verification through trusted hardware. TPM PCRs accumulate measurements, and remote attestation links signed register values, event-log records, and simulated results.

  • Verified Boot validates component signatures before execution, while Measured Boot collects measurements for posterior verification by a remote party.The two mechanisms can also be combined, as in Windows Trusted Boot.
  • Measured Boot forms a chain in which each running component measures the next before transferring control, while the TPM accumulates the resulting evidence.The measurement process uses multiple Roots of Trust with distinct roles.
  • Measured Boot does not prevent malicious firmware or hardware from gaining control, although correctly implemented measurements can preserve evidence of those components.Retrospective alteration or erasure would conflict with the cryptographic protections provided by the Root of Trust.
  • A TPM is trusted hardware that provides secure storage and measurement functions for Measured Boot.The supplied background introduces TPM 2.0 as the specification relevant to these functions.
  • TPM PCRs accumulate measurements through an Extend operation that hashes each register’s previous value with new data.This prevents components from writing arbitrary values directly into PCRs.
  • Remote attestation links a TPM-signed Quote, matching Event Log hashes, and simulation of the log to reproduce the Quote’s values.The Event Log explains how the reported PCR values were computed despite TPM memory limitations.

3 Methods for Analysing Measured Boot

The paper seeks independent, comprehensive observation of TPM interactions without modifying or relying on the observed system. It achieves this by tracing communication between a virtualized system and its TPM through an interceptable channel.

  • Validating a TPM Event Log requires independent evidence that observes or validates all TPM interactions without interfering with running processes.This addresses the need for evidence beyond the platform’s own quoting and logging mechanisms.
  • The method-selection criteria are Coverage, Deployability, Intrusive, and Independent.These criteria require broad boot-stage observation, repeatability, rapid validation, no system modification, and no dependence on proper system operation.
  • The proposed method observes Measured Boot in a virtualized environment by intercepting and analyzing the communication channel between the system and TPM.It applies to platforms implementing Measured Boot with a TPM.

3.2 Evaluated Methods for Measured Boot Analysis

The paper compares five approaches for observing Measured Boot measurements and selects virtualization as the basis for independent analysis. TPM Event Log analysis is established but remains platform-dependent, while formal verification covers only systems with sufficiently specified behavior.

  • The five principal approaches are TPM Event Log analysis, formal verification, hardware probes, software probes, and virtualization.They provide alternative ways to observe or validate measurements during boot.
  • TPM Event Log analysis obtains a TPM Quote and Event Log, then simulates the logged events to compare the result with the signed Quote.This is an established baseline for assessing measurement validity in remote attestation.
  • TPM Event Log analysis cannot provide evidence independent of the platform and inherits early-boot metadata constraints, so an external observation method is required.The passage also notes that TPM reset attacks can evade detection when relying on the platform’s mechanism alone.
  • Formal verification represents Measured Boot as logical statements and is best suited to components with explicitly and rigorously specified tasks.Examples include firmware, CRTM, bootloaders, and efforts extending toward drivers and kernels.

Formal verification

Formal verification is theoretically sufficient for answering RQ1, but applying it to the full boot chain of a general-purpose PC remains unsolved. Hardware-probe approaches also face access and platform constraints.

  • Formal verification: Formal verification could theoretically answer RQ1, but applying it to a complete general-purpose PC boot chain remains unsolved.
  • Hardware probes: Hardware probes can directly analyse component behaviour, including TPM requests, and have exposed attacks on discrete TPM chips.
  • Hardware probes: TPM Genie demonstrates that inexpensive open-source probes are available for at least some discrete TPM chips.
  • Hardware probes: Probe-based analysis requires physical access to attach a probe to the system bus.
  • Hardware probes: Direct interaction is required to inject faults and expose the internal state of firmware TPMs.
  • Hardware probes: Integrated TPMs such as Microsoft Pluton expose no accessible bus without dismantling the chip casing, an invasive and delicate process.

Software probes

Software tracing can intercept TPM-related data through kernel interfaces, but it cannot reliably cover early-boot measurements. Its scope is therefore mainly limited to measurements submitted by the kernel.

  • Software probes: Kernel tracing interfaces can intercept measurement software before data reaches the TPM communication bus.
  • Software probes: Linux offers function probes, kernel instrumentation probes, and Berkeley Packet Filter interfaces for tracing.
  • Software probes: Comparable tracing mechanisms exist for Windows but are limited in scope.
  • Software probes: Software tracing breaks down before the kernel because no unifying interface covers earlier-executing components.
  • Software probes: Closed-source firmware prevents capturing early-boot measurements, while tracing open-source firmware requires modifications that increase complexity and volatility.
  • Software probes: The approach also assumes a rootkit-free system because elevated-privilege malware could interfere with measurement capture.

Virtualization

Prior methods do not independently validate complete TPM Event Logs, while virtualization supplies most desired properties except direct TPM-behaviour observation. The paper addresses that missing observation.

  • Virtualization: Prior methods either validate specific components or observe TPM measurements, but neither independently validates a complete TPM Event Log.
  • Virtualization: Virtualization provides most desired analysis properties but lacks observation of TPM behaviour.
  • Virtualization: Table 1 summarizes TPM-based methods for analysing Measured Boot and the properties discussed in Section 3.1.

3.3 Technical Realization of TPM Measurement Tracing

TPMSpy validates TPM Event Logs by intercepting guest–TPM communication in a virtualized platform with a separate software TPM. Its relay and modular capture design handles dynamically negotiated channels and records analysis metadata.

  • 3.3 Technical Realization of TPM Measurement Tracing: The implementation uses a virtualized platform and separate software-emulated TPM to validate the TPM Event Log independently.
  • 3.3 Technical Realization of TPM Measurement Tracing: The hypervisor connects the guest to a software TPM through a communication channel carrying TPM commands as data.
  • 3.3 Technical Realization of TPM Measurement Tracing: A software interposer relays intercepted messages and can store, modify, or respond to them.
  • 3.3 Technical Realization of TPM Measurement Tracing: TPMSpy sits between QEMU and swtpm, while avoiding dependence on their internal implementations.
  • 3.3 Technical Realization of TPM Measurement Tracing: The traced path carries PCR Extend commands from the guest through a host socket, where TPMSpy intercepts them.
  • 3.3 Technical Realization of TPM Measurement Tracing: A modular core passes intercepted messages to plug-ins for extensible processing.
  • 3.3 Technical Realization of TPM Measurement Tracing: The implementation uses one control and one data channel per VM and labels them for later correlation.
  • 3.3 Technical Realization of TPM Measurement Tracing: The capture module stores timestamps, channel identities, ancillary linking messages, and collected Event Log metadata.

4 Evaluation Methodology of systemd Measurements

The evaluation combines documented systemd PCR behavior with controlled experiments that capture TPM interactions across systemd versions and configurations. It compares reconstructed TPM Event Logs and PCR results against documentation and repeatability expectations.

  • Evaluation approach: TPMSpy analyzes virtualized system–TPM communication to reconstruct TPM Event Logs and validate documented measurements.The approach observes reads and writes between measured components and a software TPM without relying on the quoting mechanism.
  • Firmware analysis: Firmware analysis is constrained because proprietary firmware lacks precise documentation of TPM use.The experiments therefore compare PCR changes across firmware versions while leaving detailed interpretation of PCR 0–7 outside the evaluation.
  • Documented systemd behavior: Systemd provides more detailed expectations than firmware because each version documents the PCRs it extends.The study reviews systemd documentation and focuses on documented TPM or PCR changes across major versions.
  • Experimental setups: Two experimental setups measure systemd evolution and optional UKI and encrypted-root features across versions v245–v258.The base setup expects PCRs 8 and 9 through v250, then PCRs 9 and 12 from v251; the encrypted-root setup additionally expects PCRs 11 and 15.
  • Expected measurements: The documented PCR usage is summarized in systemd-cryptenroll tables and figures, distinguishing default, feature-dependent, and externally implemented measurements.The documentation also identifies measurements requiring UKI, disk encryption, or tools outside systemd.
  • Validation criteria: Repeatability checks require captured TPM Event Logs to match TPMSpy’s command list, PCR values to remain consistent, and PCR-modifying operations to preserve order.Comparing PCR banks detects reordered extensions to the same PCR, while Event Logs can expose swaps when extension and logging operations are atomic.

5 Experimental Validation of systemd Interactions

Across systemd versions and Linux distributions, TPMSpy exposed evolving PCR usage, undocumented measurements, and gaps between captured TPM activity and the TPM Event Log. Unified Kernel Image and user-space measurement features introduced additional measurements that were often stored outside the platform event log.

  • Evolution of PCR use: Undocumented systemd-boot measurements extended PCR 8 before v248, despite documentation covering this behavior only from v248.The behavior originated in kernel-command-line measurement support released earlier but remained undocumented until v248.
  • Evolution of PCR use: In v251, systemd-boot switched from PCR 8 to PCR 12, while expected Linux Kernel PCR 9 measurements were absent because the tested NixOS kernel was older.NixOS used Linux 5.15 until February 2023 and later switched to 6.1.
  • Cross-distribution observations: Fedora and Ubuntu showed Shim and GRUB measurements in PCRs 14 and 8, while IMA extended PCR 10 without recording those measurements in the TPM Event Log.IMA measurements may produce hundreds of entries and are available through a kernel sysfs file.
  • Cross-platform observation: Windows 11 exhibited a distinct PCR 11–14 pattern, demonstrating TPMSpy’s application beyond systemd-based Linux systems.Windows measurement documentation was not specific enough for the same PCR analysis performed for systemd.
  • Performance: TPMSpy did not impose a statistically significant startup penalty: Fedora 43 took 22.13 ± 1.26s with TPMSpy versus 23.77 ± 1.48s without it.The 1.64s difference was comparable to run-to-run variability.
  • Unified Kernel Image: With systemd v258 and Unified Kernel Images, user-space components extended PCRs 11 and 15, but several measurements were missing from the TPM Event Log.Explicitly enabling the encrypted-volume-key measurement made a PCR 15 extension visible to TPMSpy, while it still remained absent from the event log.
  • Event-log completeness: The TPM Event Log alone was insufficient for remote attestation because systemd user-space and IMA measurements were stored in separate files.The relevant locations included systemd-tpm2-measure.log and the IMA sysfs file.

6 Conclusion

The paper presents TPMSpy as a virtualization-based method for independently observing TPM interactions and evaluating Measured Boot across platforms. Its analysis found mostly documented, increasingly extensive PCR use, but also event-log omissions that limit attestation, while the method itself remains bounded by limited context and does not replace formal verification.

  • Contribution: TPMSpy observes complete communication between a virtual system and software TPM emulator, enabling repeated, automated, non-intrusive assessment across Linux and Windows.The method is designed to remain independent of platform implementation details and available source code.
  • Findings: PCR use increased over time and generally matched documentation, but systemd user-space services and IMA stored measurement metadata outside the TPM Event Log.An appraiser unaware of those locations can fail to attest to the measured values.
  • Limitations: The method verifies TPM Event Log completeness but does not replace formal verification.Its strict independence from the observed system currently limits captured context to timestamps, channel metadata, and events.
Loading 2609.05011v1…