Electronics Guide

PCR Architecture and Organization

TPM specifications define a standard set of PCRs, each dedicated to specific types of measurements. The TPM 1.2 library specification requires a minimum of 16 PCRs, but the TCG PC Client profile mandates 24 (PCR 0 through PCR 23), and every TPM 1.2 PCR holds a single 160-bit SHA-1 digest. TPM 2.0 retains the same 24-register PC Client layout while permitting implementations to expose additional platform-specific registers. Each TPM 2.0 PCR is sized to the digest of the algorithm in use—160 bits for SHA-1, 256 bits for SHA-256, 384 bits for SHA-384.

Initial values matter as much as the layout, because attestation policies frequently test whether a register was ever touched. At TPM startup the PC Client profile initializes PCRs 0 through 16 and PCR 23 to all zeros. The DRTM registers, PCRs 17 through 22, initialize to all ones instead; only a measured launch drives them to zero. A verifier can therefore distinguish a register that was never extended from a DRTM register that no secure launch has ever entered, and it can reject a quote in which a register that should carry a measurement still holds its reset value.

PCRs are organized by function according to TCG specifications. PCRs 0-7 measure static core root of trust for measurement (SRTM) components including firmware, platform configuration, and Secure Boot policy. PCRs 8-15 are reserved for operating system and boot loader use, allowing them to store measurements of kernels, drivers, configuration files, and system state. PCR 16 is designated for debug operations. PCRs 17-22 support dynamic root of trust for measurement (DRTM), enabling trusted execution environments to be established after initial boot. PCR 23 supports application-specific measurements.

The allocation of measurements to specific PCRs follows defined conventions to ensure consistency across platforms and enable interoperability between attestation systems. On modern UEFI platforms, the TCG PC Client Platform Firmware Profile defines the firmware PCRs as follows: PCR 0 records firmware code (the SRTM, host platform extensions, and embedded option ROMs); PCR 1 records host platform configuration; PCR 2 records the code of UEFI drivers and applications from add-in adapters; PCR 3 records their configuration and data; PCR 4 records the boot manager code and boot attempts; PCR 5 records boot manager configuration and the GPT partition table; PCR 6 is reserved for host platform manufacturer events, including state transitions and wake events; and PCR 7 records the Secure Boot policy, including the Platform Key, Key Exchange Key, and the allowed and forbidden signature databases. This standardization allows attestation verifiers to interpret PCR values consistently regardless of hardware vendor. Legacy BIOS platforms used an earlier mapping in which option ROM code and configuration were measured into PCRs 2 and 3.

PCR Banks and Hash Algorithm Agility

TPM 2.0 introduces the concept of PCR banks, where each PCR exists in multiple parallel instances, one for each supported hash algorithm. A TPM might implement SHA-1, SHA-256, and SHA-384 banks simultaneously, with each bank holding its own set of registers; most shipping PC TPMs allocate SHA-1 and SHA-256. Two commands update them, and the difference matters. TPM2_PCR_Event submits raw data, and the TPM hashes it once with every allocated bank algorithm and extends each corresponding register. TPM2_PCR_Extend instead submits a list of precomputed digests tagged by algorithm, and the TPM extends only the banks named in that list. Firmware uses the latter for anything large, hashing a boot image on the host processor and sending only the resulting digests across the TPM interface.

This multi-bank architecture provides cryptographic agility, allowing systems to transition away from deprecated algorithms while maintaining backward compatibility. As SHA-1 weaknesses were discovered, systems could begin using SHA-256 PCR banks while legacy software continued operating with SHA-1 banks. New deployments can enable only SHA-256 and SHA-384 banks, avoiding weak algorithms entirely. Which banks are active is set with TPM2_PCR_Allocate under platform authorization, and the new allocation takes effect only after the next TPM reset, which makes bank selection a provisioning decision rather than a runtime one.

Hash algorithm selection impacts both security and performance. Longer hash outputs provide stronger collision resistance but consume more storage and bandwidth during attestation. SHA-256 represents the current minimum recommended algorithm, offering adequate security with reasonable performance. SHA-384 and SHA-512 provide increased security margins for applications with extended lifetimes or higher security requirements. The ability to support multiple algorithms simultaneously future-proofs TPM deployments against cryptographic advances.

The PCR Extend Operation

The extend operation represents the fundamental PCR update mechanism, implementing a one-way accumulation function that combines new measurements with existing PCR contents. When extending a measurement into a PCR, the TPM computes: PCR_new = Hash(PCR_current || measurement_data), where || denotes concatenation. In TPM 2.0 the measurement data is itself a digest of the measured object, computed with the same algorithm as the bank being extended, so a register never absorbs raw content directly. The result replaces the register's previous contents.

The extend operation's cryptographic properties ensure that achieving a specific target PCR value requires knowledge of the complete measurement sequence. Given the collision resistance of cryptographic hash functions, finding alternative measurement sequences that produce identical final PCR values is computationally infeasible. This property enables PCR values to serve as unforgeable evidence of boot sequence integrity.

Measurement ordering matters critically in extend operations. Measuring components A then B produces a different final PCR value than measuring B then A, even if the same components are measured. This ordering dependency ensures that PCR values reflect not just which components loaded, but the specific sequence in which they loaded. Boot sequence attacks that attempt to load malicious components before security checks will produce different PCR values than the legitimate boot sequence.

The irreversibility of extend operations provides security but complicates certain operational scenarios. Once extended with a measurement, a PCR cannot be reset to a previous state except through TPM reset or system reboot. This prevents attackers from "rewinding" PCR state to hide evidence of malicious activity. However, it also means that measurement errors or legitimate configuration changes may require system reboot to restore PCRs to known states.

Measurement Chains and Event Logs

A measurement chain represents the sequence of extend operations performed during boot, with each stage measuring the next before transferring control. The chain begins with the Core Root of Trust for Measurement (CRTM), typically implemented in immutable boot ROM. The CRTM measures the next boot stage, extends the measurement into appropriate PCRs, then transfers control. Each subsequent stage repeats this measure-extend-execute pattern, creating a chain from hardware through firmware to the operating system.

The event log complements PCR values by recording detailed information about each measurement. While PCRs store only the accumulated hash result, the event log maintains a sequential record of what was measured, when, and which PCR was extended. Event log entries typically include the measured data hash, a description of what was measured, and metadata about the measurement context. This detailed record enables attestation verifiers to understand how final PCR values were derived.

Event logs must be protected from tampering to maintain their integrity and correlation with PCR values. Since event logs typically reside in standard system memory rather than within the TPM, they are vulnerable to modification by compromised software. Attestation protocols address this by having the verifier independently compute expected PCR values from the event log and compare them against TPM-signed PCR quotes. Any discrepancy between event log claims and actual PCR values indicates tampering.

The TCG PC Client Platform Firmware Profile specification defines standard event log formats ensuring interoperability between platforms and attestation systems. Event log entries record the measurement digest, the event type indicating what was measured, and event-specific data describing the measurement context. Standard event types include BIOS measurements, UEFI boot variables, boot loader measurements, and operating system components. This standardization enables attestation verifiers to interpret event logs from diverse hardware platforms.

Static Root of Trust for Measurement

Static Root of Trust for Measurement (SRTM) establishes trust beginning at system power-on or reset, with the CRTM executing as the first code after processor initialization. The CRTM, implemented in immutable boot block code or burned into ROM, measures the next boot stage (typically BIOS or UEFI firmware), extends the measurement into PCR 0, then transfers control. This initiates the measurement chain that continues through all boot stages.

SRTM requires that all code executing during boot be measured before execution, producing a complete record of the platform's boot configuration in PCRs 0 through 7. The profile's consistent pairing of a code register with a configuration register—PCR 0 against PCR 1, PCR 2 against PCR 3, PCR 4 against PCR 5—exists so that changing a setting does not perturb the register that attests the firmware image itself. A policy can then bind a secret to firmware identity while tolerating a boot-order change, or the reverse, without the two concerns interfering.

The SRTM approach provides comprehensive boot measurement but has limitations. The CRTM must execute immediately after processor initialization, before any other code that could subvert the measurement process. This requirement typically necessitates implementing the CRTM in immutable storage, limiting updatability. Additionally, SRTM measurements reflect the complete boot sequence from power-on, meaning that any boot-time configuration change alters PCR values, potentially complicating sealed storage and attestation policies.

UEFI Secure Boot complements SRTM by adding enforcement alongside measurement. While measured boot records what executed, Secure Boot validates cryptographic signatures before allowing execution. Combining both approaches provides defense in depth: Secure Boot prevents unauthorized code execution, while measured boot creates auditable evidence of what actually executed, detecting scenarios where Secure Boot might be disabled or compromised.

Dynamic Root of Trust for Measurement

Dynamic Root of Trust for Measurement (DRTM) enables establishment of a fresh trusted execution environment at any point after initial boot, without requiring system reboot. DRTM implementations use processor features such as Intel Trusted Execution Technology (TXT), invoked through the GETSEC[SENTER] instruction, or the AMD SKINIT instruction, to reset designated PCRs (typically PCRs 17-22), load a measured launch environment, and begin execution in a known secure state. The processor signals the TPM that these operations originate from a measured launch by issuing them from a high-privilege locality, which is what authorizes the otherwise-restricted reset of the DRTM PCRs.

The DRTM launch process atomically performs several operations: disabling interrupts and debugging features, resetting DRTM PCRs to known values, measuring the launched code, extending the measurement into PCR 17, configuring memory protection, and transferring control to the measured environment. This atomic sequence ensures that the launched environment begins in a well-defined state regardless of the previous system state, enabling trust establishment even if the pre-launch OS was compromised.

DRTM supports use cases including launching a trusted kernel that verifies system integrity independently of the running OS, establishing secure execution environments for sensitive computations, and implementing runtime attestation without requiring reboot. Cloud service providers can use DRTM to launch customer workloads in trusted environments with attestable configurations. Security-critical applications can use DRTM to establish isolated execution contexts that even privileged malware cannot compromise.

DRTM measurements use PCRs 17-22 following conventions defined by the D-RTM Architecture specification. PCR 17 records the launched measured environment digest. PCR 18 stores the trusted OS startup code measurements. PCR 19 measures trusted OS configuration. PCRs 20-22 are reserved for trusted OS use and application-specific measurements within the DRTM environment. This separation from SRTM PCRs enables DRTM measurements to be evaluated independently of boot-time measurements.

PCR Quote Operations

Quote operations enable the TPM to cryptographically sign PCR values, creating unforgeable attestation evidence that can be verified by remote parties. When performing a quote, the TPM reads specified PCR values, combines them with a nonce provided by the requester, and signs the resulting structure with an attestation key. The nonce prevents replay attacks by ensuring that each quote operation produces a unique signature even if the PCR values have not changed.

A quote does not carry the raw register contents. TPM2_Quote produces a TPMS_ATTEST structure whose quote body holds the PCR selection—which banks and which register indices were included—together with pcrDigest, a single digest computed over the concatenated values of the selected registers. The surrounding attestation structure adds the caller's nonce as extraData, the qualified name of the signing key, the TPM's firmware version, and the clock, reset count, and restart count. The TPM signs that structure with a loaded attestation identity key (AIK in TPM 1.2) or attestation key (AK in TPM 2.0).

Because only the composite digest is signed, the verifier must obtain the individual PCR values by a separate path, either reading them with TPM2_PCR_Read or reconstructing them by replaying the event log, then recompute the composite digest and confirm that it matches pcrDigest. Omitting that recomputation is a genuine implementation error rather than a theoretical one: a verifier that validates the signature but never binds it to concrete register values will accept PCR values that were never in the TPM.

Quote operations can select specific PCRs to include in the signed attestation. An attestation request might quote only PCRs 0-7 to attest boot configuration, or quote PCRs 17-22 to attest a DRTM environment, or quote all PCRs to provide comprehensive platform state evidence. PCR selection enables efficient attestation focused on relevant measurements while minimizing quote data size and signature verification time.

TPM 2.0 also allows one quote to span multiple banks, because the PCR selection is a list of selections, each naming a hash algorithm and a bitmap of register indices. A single operation can therefore attest the SHA-256 values of the firmware registers alongside the SHA-384 value of an operating system register, serving verifiers that have standardized on different algorithms. The composite-digest design keeps the signed structure a small fixed size no matter how many registers are selected, which matters because signature generation, not register selection, is the expensive part of the operation.

Remote Attestation Protocols

Remote attestation protocols enable a platform to prove its configuration state to a remote verifier, typically as a prerequisite for accessing sensitive resources or joining a network. The attestation process begins with the verifier sending a challenge including a fresh nonce to the platform. The platform performs a TPM quote operation over relevant PCRs, sending the signed quote and event log to the verifier. The verifier validates the quote signature, checks the nonce freshness, and evaluates whether PCR values match expected "golden" measurements.

Attestation protocols must address several security requirements. Freshness guarantees prevent attackers from replaying old attestation evidence—the nonce ensures that the attestation reflects current platform state rather than historical measurements. Signature validation proves that attestation evidence originated from a genuine TPM rather than being fabricated by compromised software. Event log correlation enables verifiers to understand how PCR values were derived from individual measurements.

Privacy considerations affect attestation protocol design. The TPM's endorsement key provides a unique hardware identifier, enabling correlation of attestations across different sessions and contexts. Privacy-preserving attestation uses attestation identity keys (AIKs) that are certified by a Privacy CA but do not directly reveal the platform's unique identity. Direct Anonymous Attestation (DAA) provides cryptographic privacy guarantees, allowing platforms to prove they possess a valid TPM without revealing which specific TPM.

Modern attestation protocols extend beyond simple boot configuration verification. Runtime attestation continuously monitors system state, generating fresh attestations periodically or when configuration changes occur. Composite attestation evaluates evidence from multiple sources including TPM measurements, runtime integrity monitors, and configuration management systems. Hierarchical attestation enables complex systems to attest subsystem integrity, with each component attesting its own state and the states of components it manages.

Sealed Storage and PCR Binding

Sealed storage leverages PCR values to bind encrypted data to specific platform configurations, ensuring that secrets remain inaccessible unless the system is in an expected measured state. The sealing process encrypts data under a TPM storage key configured with authorization policies requiring specific PCR values. The unsealing operation succeeds only when current PCR values match those specified in the sealing policy, providing cryptographic enforcement of configuration requirements.

TPM 2.0 expresses these conditions through enhanced authorization. TPM2_PolicyPCR folds the current values of a chosen selection of registers into a running policy digest, and the unseal succeeds only when that digest equals the policy the sealed object was created under. Because the command consumes the whole selection at once, a policy naming PCR 0 and PCR 4 is satisfied only when both registers hold their expected values; there is no partial credit. Additional policy commands chain onto the same digest, adding requirements such as an authorization value, a physical-presence signal, or a permitted command code, so access control can combine measured state with conditions that have nothing to do with measurement.

Full disk encryption is the archetypal use case. BitLocker seals the volume master key to the TPM and, on a UEFI system with Secure Boot enabled, validates PCR 7, which carries the Secure Boot policy, together with PCR 11, which Windows reserves for BitLocker access control; where the Secure Boot state is unsuitable for PCR 7 binding it falls back to the older profile of PCRs 0, 2, 4, and 11. On Linux, systemd-cryptenroll binds a LUKS2 key slot to a chosen selection, commonly PCR 7 alongside PCR 11, the latter carrying the components of a unified kernel image measured by the boot stub. In each case the volume unlocks silently on an expected boot and falls back to a recovery secret when the measurements move, which is exactly the behavior that defeats bootkits and offline firmware tampering. The same mechanism protects application secrets, license material, and machine credentials.

Managing sealed storage across updates raises the difficulty usually called PCR brittleness. A legitimate firmware or boot loader update changes the measurements, the policy digest no longer matches, and the sealed secret becomes unreachable—the mechanism behind the BitLocker recovery prompts that follow some UEFI updates. Three mitigations are common. The simplest is to unseal and re-seal around the update, which requires exposing the secret to software at the moment of change. PCR prediction computes the expected post-update values from reference measurements and seals to the new configuration in advance. The most robust approach replaces the direct measurement policy with an authorized one: TPM2_PolicyAuthorize accepts any policy digest that carries a valid signature from a designated authority key, so a vendor can bless a new set of expected measurements without ever touching the sealed data. TPM2_PolicyAuthorizeNV performs the equivalent check against a policy digest held in TPM non-volatile storage, and Linux tooling such as systemd-pcrlock uses it to regenerate a local boot policy after each authorized change.

Trusted Boot Sequences

Trusted boot implements a complete measured boot chain from hardware through the operating system, with each component measuring the next before transferring control. The process begins with the CRTM measuring initial firmware, continues through BIOS/UEFI measuring boot loaders, boot loaders measuring OS kernels, and kernels measuring drivers and system services. This creates a comprehensive measurement chain recorded in PCRs and event logs.

Boot component measurement must occur before execution to prevent malicious code from subverting the measurement process. Firmware measures each boot stage by reading the component's code and configuration into memory, computing a cryptographic hash, extending the hash into appropriate PCRs, recording details in the event log, then transferring control to the measured component. This measure-before-execute pattern ensures that all executing code is accounted for in PCR values.

Operating system integration extends trusted boot beyond firmware. Windows implements measured boot through bootmgr and winload.exe, which measure system files and extend the results into the operating system register range. The Early Launch Anti-Malware (ELAM) driver, measured and loaded early in the boot sequence, can evaluate subsequent drivers and prevent malware drivers from loading. Linux implementations including Integrity Measurement Architecture (IMA) measure files as they are accessed, creating comprehensive runtime integrity logs.

Boot component whitelisting complements measurement by defining expected "golden" measurements for legitimate boot components. Attestation verifiers compare actual PCR values against these reference measurements to determine if the platform booted with trusted components. Measurement databases maintain golden values for known-good firmware versions, boot loaders, kernels, and drivers. Updates to these databases track legitimate software updates while detecting unauthorized modifications.

PCR Reset and Locality

PCR reset operations enable PCRs to be returned to their initial values, providing controlled state initialization for specific use cases. TPM 2.0 differentiates between resettable and non-resettable PCRs based on their designated function. The SRTM PCRs (0-15) are non-resettable, cleared only through a TPM reset triggered by system reboot. The DRTM PCRs (17-22) are resettable, but only from the high-privilege locality used by a secure launch, allowing DRTM launch operations to initialize these registers without requiring a reboot. In the standard PC Client profile the debug PCR (16) and the application-support PCR (23) are also resettable, and these are the only PCRs the operating system may reset from locality 0. The command is TPM2_PCR_Reset, which returns the register to all zeros; an attempt to reset a register from a locality its reset policy does not permit fails outright rather than quietly succeeding.

Locality controls restrict PCR operations based on the requesting context's privilege level. TPM specifications define five localities (0-4), with locality 4 representing the most privileged context (typically hardware-based CRTM), and locality 0 representing the least privileged (typically operating system context). Certain PCRs can only be extended or reset from specific localities, preventing less-privileged software from tampering with more-privileged measurements.

Locality enforcement ensures proper separation between different trust domains. DRTM measurements in PCRs 17-22 can only be reset by locality 4 operations during secure launch sequences, preventing the operating system from arbitrarily resetting these registers. Platform-specific PCRs might be resettable only from localities associated with platform firmware. The debug register, PCR 16, is resettable from any locality, which supports development and test workflows and is also why no security policy should ever depend on its contents.

The locality mechanism extends beyond PCRs to control access to other TPM functions. Locality restrictions can apply to key usage, authorization sessions, and administrative operations. This provides hardware-enforced access control ensuring that security-critical operations can only be performed by appropriately privileged contexts. Locality 4 operations, initiated through processor-specific mechanisms like Intel TXT, provide the highest assurance of operating in a trusted environment.

PCR Validation and Policy Evaluation

PCR validation involves comparing actual PCR values against expected reference measurements to determine whether a platform is in a trusted state. Validation policies define acceptable PCR values and the logic for evaluating compliance. Simple policies might require exact matches between actual and expected values, while sophisticated policies might accept any of several known-good configurations or evaluate complex combinations of PCR values.

Policy evaluation engines process attestation evidence including PCR quotes and event logs, applying validation rules to determine trust decisions. The engine verifies quote signatures to ensure evidence authenticity, validates nonce freshness to prevent replay attacks, reconstructs PCR values from event logs to verify consistency, and compares PCR values against golden measurements. Policy violations trigger configurable responses ranging from alerts to access denial.

Composable policies enable flexible trust evaluation combining multiple factors. A policy might require that boot firmware matches expected measurements (PCRs 0-7) AND the operating system is a known-good version (PCRs 8-15) AND specific security software is running (PCR 23). Boolean operators combine individual conditions into comprehensive trust policies. Policy versioning and updates enable trust requirements to evolve as threats change and new software versions are validated.

Unknown PCR values present a challenge for validation policies. During initial deployment, software updates, or configuration changes, actual PCR values may differ from previously recorded golden values. Policies must balance security against operational flexibility—strict policies provide stronger security but may reject legitimate configurations, while lenient policies improve operational flexibility but might accept compromised systems. Approval workflows enable security teams to review and authorize new PCR values before adding them to golden measurement databases.

Platform Configuration and Firmware Measurements

Platform configuration encompasses all firmware code, configuration data, and settings that affect system behavior and security properties. Comprehensive measurement captures BIOS/UEFI code, configuration variables, option ROM firmware, embedded controller firmware, and security-critical hardware configuration. These measurements extend into PCRs 0-7 following standardized conventions, creating an auditable record of platform configuration state.

The register mapping described earlier is prescriptive rather than advisory. The profile fixes both what must be measured and which register receives it, which is what lets a verifier interpret a PCR 0 value from one vendor's firmware the same way it interprets another's, and what lets a single golden-measurement database serve a mixed fleet. Coverage extends past the main firmware image to embedded option ROMs, add-in adapter firmware, and the security-relevant portions of platform configuration. The gaps are the interesting part: firmware that the profile does not require to be measured—an embedded controller image, a baseboard management controller, a storage device's own firmware—is invisible to attestation no matter how carefully the main boot chain is covered, and attacks have repeatedly targeted exactly those unmeasured surfaces.

Configuration variable measurements present particular challenges. UEFI systems store hundreds of variables affecting boot behavior, security settings, and hardware configuration. Measuring all variables would be prohibitively expensive in terms of boot time and event log size. The specification designates security-critical variables that must be measured, including Secure Boot configuration, boot order, and variables affecting trusted boot operation. Balancing comprehensive measurement against performance requires careful selection of measured variables.

Firmware updates change measurement values, requiring careful management of sealed storage and attestation policies. Before updating firmware, systems should unseal any sealed data and re-seal it with expected post-update PCR values. Attestation policies must be updated to accept the new firmware measurements before deploying updates to production systems. Staging environments enable validation of new firmware measurements before production deployment, preventing sealed storage lockout or attestation policy violations.

Operating System and Application Measurements

Operating system measurements extend the trusted boot chain beyond firmware, recording boot loader, kernel, driver, and system service integrity in PCRs 4 and 8-15. The boot loader executable itself is measured by firmware into PCR 4 as part of the boot manager chain. The boot loader then measures the components it loads before transferring control; GRUB2, for example, extends the commands it executes and the kernel command line into PCR 8 and the files it reads, including the kernel image and initial ramdisk, into PCR 9. The kernel in turn measures and loads drivers and modules. Runtime measurement systems continue recording file access and application execution throughout system operation.

Linux Integrity Measurement Architecture (IMA) provides comprehensive runtime measurement, maintaining an event log recording all executed files, loaded kernel modules, and accessed sensitive files. By convention IMA extends its file measurements into PCR 10, often seeding that register with a "boot aggregate" derived from the firmware and boot loader PCRs so that runtime measurements remain anchored to the static boot chain. This produces a cumulative measurement reflecting all code that has executed. The Extended Verification Module (EVM) complements IMA by protecting file metadata, including security labels and extended attributes, against offline tampering.

Windows measured boot extends measurements through bootmgr, winload.exe, and the OS kernel into the operating system register range, with PCR 11 reserved specifically for BitLocker access control. The Core Isolation feature leverages measurements to establish virtualization-based security contexts. Early Launch Anti-Malware (ELAM) drivers measure subsequently loaded drivers, preventing malware drivers from loading before anti-malware software can evaluate them. Secure Kernel Mode (part of Virtualization Based Security) uses DRTM to establish isolated execution environments even if the main OS kernel is compromised.

Application-specific measurements enable custom measurement policies tailored to particular applications or security requirements. Applications can measure configuration files, plugins, or dynamic libraries, extending measurements into PCR 23 or application-designated PCRs. Container orchestration systems can measure container images and runtime configurations. Critical applications can seal secrets to specific application configurations, ensuring that sensitive data is only accessible when the application is in a known-good state.

Debugging and Development Considerations

Debugging measured boot implementations requires specialized tools and techniques. PCR 16 is designated for debug purposes and may be resettable without system reboot, enabling iterative development. Debug builds might measure fewer components or use debug policies accepting a wider range of measurements. Software TPMs—the Microsoft TPM 2.0 reference implementation, the IBM software TPM, and the swtpm daemon commonly paired with QEMU—let measurement logic be written and regression tested without production hardware, though a simulator offers no hardware protection and must never stand in for a real TPM in a deployed system.

Event log analysis tools parse and display the log, showing the sequence of measurements and the register values they imply. On Linux the kernel exposes the firmware log at /sys/kernel/security/tpm0/binary_bios_measurements, and the tpm2-tools suite supplies the standard workflow: tpm2_pcrread dumps current bank contents, tpm2_eventlog decodes the firmware log into readable events, and tpm2_quote paired with tpm2_checkquote exercises the full attestation path locally. Comparing a decoded log from a failing boot against one from a known-good boot is usually the fastest way to identify the single component that moved a register.

Measurement prediction computes expected PCR values based on known component versions and measurement sequences without requiring actual execution. Prediction tools use reference measurements of firmware, boot loaders, kernels, and drivers to compute expected final PCR values. This enables policy updates and sealed storage re-sealing to be prepared before deploying software updates. Prediction failures indicate unexpected measurements requiring investigation.

Testing and validation must cover both positive and negative cases. Positive testing verifies that known-good configurations produce expected PCR values and attestation succeeds. Negative testing validates that compromised or modified components produce different PCR values and fail attestation. Edge cases including error conditions, partial boot failures, and recovery scenarios require testing to ensure the system behaves correctly under all conditions. Automated testing frameworks can verify measurement consistency across repeated boots and different hardware configurations.

Security Considerations and Attack Resistance

PCR security depends on several properties working together: the cryptographic strength of hash algorithms, the tamper resistance of the TPM hardware, the completeness of measurement coverage, and the protection of event logs and attestation protocols. Weak points in any of these areas can compromise the entire measured boot system. Comprehensive security evaluation must consider the complete trust chain from CRTM through TPM to attestation verifiers.

Hash algorithm cryptanalysis poses long-term risks to PCR integrity. While SHA-256 is currently secure, advances in cryptanalysis or quantum computing might eventually weaken it. PCR bank architecture provides algorithm agility, enabling migration to stronger algorithms as needed. Organizations should plan for cryptographic transitions, including maintaining multiple PCR banks during transition periods and updating attestation infrastructure to support new algorithms.

Time-of-check to time-of-use (TOCTOU) attacks exploit the gap between measuring code and executing it. Attackers might attempt to modify code after measurement but before execution. Proper measured boot implementations minimize this window by measuring code immediately before execution and preventing modification of measured code regions. Memory protection and execution controls ensure that measured code cannot be altered after measurement.

Event log tampering can mislead attestation verifiers if attackers modify event logs to hide malicious measurements while actual PCR values remain untampered. Attestation protocols address this by having verifiers independently compute expected PCR values from event logs and compare against TPM-signed PCR quotes. Any discrepancy indicates tampering. Advanced attacks might attempt to construct fraudulent event logs that compute to actual PCR values, but the cryptographic difficulty of finding alternative measurement sequences producing identical hashes makes this infeasible.

TPM reset attacks attempt to reset PCRs to known values without rebooting the system, potentially enabling attackers to achieve desired PCR values through controlled measurement sequences. Proper PCR reset policies and locality enforcement prevent unauthorized reset operations. Non-resettable SRTM PCRs can only be cleared through system reboot. DRTM PCRs can be reset only through secure launch operations from high-privilege localities. Operating systems cannot arbitrarily reset security-critical PCRs.

Performance Optimization

Measured boot performance impacts system boot time, with each measurement requiring cryptographic hash computation and TPM extend operations. Optimization strategies include parallelizing measurements where possible, using efficient hash algorithms, minimizing the number of measured components, and implementing hash caching for components measured multiple times across boot sequences.

Hash computation performance depends on algorithm selection and implementation. Hardware-accelerated hash implementations significantly outperform software implementations. SHA-256 offers a good balance of security and performance. SHA-1 survives in shipping TPMs only for compatibility with older attestation software, and practical chosen-prefix collisions against it mean no new deployment should rely on a SHA-1 bank. Longer algorithms such as SHA-384 and SHA-512 cost more per byte, but on the boot path that cost is almost always negligible beside the fixed overhead of each TPM command.

Interface latency, not hashing, dominates measured boot cost. A discrete TPM sits behind a low-bandwidth LPC, SPI, or I2C link, and every extend is a full command and response round trip with the TPM's own internal processing in between. No standard command extends several register indices at once: TPM2_PCR_Extend updates a single index, across as many banks as the caller supplies digests for, so the number of TPM commands tracks the number of distinct measurements rather than the volume of data measured. Firmware reduces that count by hashing components on the host processor and sending only digests, and by measuring aggregates in place of many small items. The serial dependency of the boot chain, in which each stage must be measured before it runs, limits what remains.

Selective measurement reduces performance impact by measuring only security-critical components rather than comprehensive measurement of all code and configuration. Risk-based measurement identifies high-value targets like boot firmware, security software, and cryptographic key material as measurement priorities. Less-critical components might be measured through representative samples or omitted entirely. This trade-off exchanges some security assurance for improved boot performance.

Interoperability and Standards

PCR interoperability enables attestation systems to work across diverse hardware platforms and TPM implementations. TCG specifications define standard PCR allocations, measurement conventions, event log formats, and attestation protocols. Compliance with these standards ensures that attestation verifiers can interpret evidence from any compliant platform without vendor-specific customization.

The TCG PC Client Platform specification defines standard PCR usage for x86 platforms. The TCG Server specification extends these conventions for server-specific use cases. Platform-specific specifications for Arm, embedded systems, and virtualized environments adapt the core concepts to different architectures while maintaining interoperability principles. Cross-platform applications can rely on standardized PCR allocations and measurement formats.

Event log formats must be standardized to enable verifier portability. The TCG Event Log specification defines binary formats for event log entries, including event headers, event types, and event-specific data structures. Standardized event types enable verifiers to understand what each entry represents without platform-specific knowledge. Event log parsers can process logs from any compliant platform, facilitating centralized attestation infrastructure.

Attestation protocol interoperability lets clients and verifiers from different vendors work together. The TCG TAP information model describes attestation exchanges independently of TPM family, while the IETF Remote ATtestation procedureS (RATS) working group supplies an architecture that names the roles—attester, verifier, relying party, and endorser—and separates appraisal of the evidence from consumption of the resulting attestation result. That separation is what allows one verifier service to appraise TPM quotes, confidential-computing reports, and device-specific evidence behind a single interface, which is increasingly how large fleets are managed.

Cloud and Virtualized Environments

Cloud computing introduces unique challenges for PCR-based attestation. Traditional attestation attests physical hardware, but cloud workloads run in virtual machines with virtualized TPMs. Virtual TPMs (vTPMs) provide TPM functionality to guest VMs, enabling attestation of guest configuration while raising questions about the trust relationship between guest, hypervisor, and cloud provider.

Hypervisor attestation enables cloud providers to attest to the hypervisor's integrity and configuration using physical TPMs. Measured boot of the hypervisor extends measurements into physical TPM PCRs, creating evidence of the virtualization layer's integrity. Customers can verify that their workloads run on trustworthy hypervisors before deploying sensitive applications or data. This establishes hardware root of trust despite the virtualization layer.

Virtual TPM implementations must address the challenge of providing TPM services to multiple VMs from shared physical TPMs. Each vTPM instance maintains its own PCRs and cryptographic keys, isolated from other VMs. The hypervisor mediates access to physical TPM resources, implementing virtual TPM functionality while preventing VMs from interfering with each other's TPM state. vTPM migration enables VM mobility while keeping TPM-bound data accessible, at the cost of a trust assumption a discrete TPM does not carry: a vTPM's endorsement key is certified by the platform owner or cloud provider rather than by a silicon vendor, so a relying party must decide whether it trusts that authority as it would a TPM manufacturer.

Confidential computing extends attestation to protect data during processing, not only at rest or in transit. Intel SGX and TDX, AMD SEV-SNP, and Arm CCA create isolated execution environments whose initial contents are measured by hardware and reported in a signed attestation report. Those reports are conceptually close to a quote—a hardware-rooted signature over a launch measurement plus caller-supplied data—but they do not use TPM PCRs, and their measurement is a snapshot of the environment at launch rather than an accumulating chain. Confidential virtual machines bridge the two models by exposing a vTPM inside the guest whose own state is covered by the hardware attestation report, so the guest can present a familiar PCR-based quote while the platform vouches for the vTPM that produced it.

Practical Deployment Considerations

Deploying PCR-based security requires careful planning around measurement policies, attestation infrastructure, sealed storage management, and operational procedures. Organizations must decide which components to measure, how frequently to perform attestation, what constitutes acceptable PCR values, and how to handle legitimate configuration changes without compromising security.

Baseline establishment involves measuring known-good systems to determine expected PCR values. Reference platforms should be built and configured according to security policies, then booted while capturing PCR values and event logs. These baselines become the "golden" measurements against which production systems are compared. Baselines must be updated when legitimate software updates or configuration changes are deployed.

Change management processes integrate with PCR-based security to handle updates without disrupting sealed storage or attestation. Before deploying firmware updates, compute expected post-update PCR values and update attestation policies to accept the new measurements. Re-seal protected data with new PCR policies before applying updates. Test updates in non-production environments to validate that attestation succeeds with new measurements before production deployment.

Incident response leverages PCR attestation to detect and investigate compromise. Unexpected PCR values indicate potential security incidents requiring investigation. Event log analysis reveals which components differ from expected measurements, guiding remediation efforts. Forensic analysis of PCR changes and event logs can determine when compromise occurred and which components were affected. Attestation monitoring provides early warning of firmware attacks, bootkit infections, and unauthorized configuration changes.

Future Directions and Emerging Technologies

PCR technology continues to evolve, and the quantum threat to attestation is frequently misstated. Hash functions hold up comparatively well: Grover's algorithm offers only a quadratic speedup against preimage resistance, leaving SHA-256 with roughly 128 bits of preimage security against a quantum adversary, and collision resistance—the property the extend operation actually depends on—gains little from quantum search. The exposed component is the signature over the quote, because RSA and elliptic curve signatures fall to Shor's algorithm. The Trusted Computing Group has responded on that front: revision 1.85 of the TPM 2.0 library specification adds the NIST post-quantum algorithms ML-KEM and ML-DSA, allowing endorsement keys to use ML-KEM against harvest-now-decrypt-later collection and attestation keys to sign quotes with ML-DSA. Migration pressure therefore falls on key hierarchies and attestation infrastructure rather than on bank algorithms, though moving from SHA-256 to SHA-384 banks remains an inexpensive hedge.

Real-time attestation and continuous monitoring extend beyond boot-time measurements to provide ongoing verification of system integrity. Runtime integrity measurement systems continuously hash executing code and accessed files, extending measurements into PCRs or auxiliary registers. Continuous attestation enables rapid detection of runtime compromises rather than waiting until the next boot cycle to detect changed measurements.

Fleet-scale analytics complement cryptographic measurement, within limits worth stating plainly. A PCR value is an opaque digest with no internal structure to learn from, so the useful signal is comparative rather than predictive: across a large population of nominally identical machines, an event log that diverges from its peers, or a firmware digest that appears on exactly one host, is worth investigating even though the boot itself succeeded. Correlating measurement changes with maintenance records and update campaigns separates authorized change from the unexplained kind. That triage, rather than any detection capability of its own, is what statistical analysis adds to an assurance that is already cryptographic.

Confidential computing integration creates synergies between PCR-based attestation and isolated execution environments. Attestation of SGX enclaves, SEV virtual machines, or TrustZone secure worlds leverages PCR-like measurement mechanisms. Combining hardware-isolated execution with cryptographic attestation enables trustworthy cloud computing where customers maintain control over code and data even when executing on third-party infrastructure. This represents the convergence of multiple hardware security technologies into comprehensive protection frameworks.

Conclusion

Platform Configuration Registers form the foundation of trusted computing, enabling cryptographic measurement and attestation of system configuration from hardware through operating systems to applications. The extend operation's one-way accumulation property ensures that PCR values faithfully reflect the complete measurement sequence, providing unforgeable evidence of platform state. Standardized PCR allocations, measurement conventions, and attestation protocols enable interoperability across diverse platforms and vendors.

Effective use of PCRs requires understanding the complete trust chain from CRTM through firmware, boot loaders, operating systems, and applications. Measurement policies must comprehensively cover security-critical components while balancing performance and operational flexibility. Attestation infrastructure must properly validate signatures, verify freshness, correlate event logs with PCR values, and implement appropriate trust policies. Sealed storage binds secrets to specific configurations, ensuring that sensitive data remains protected unless the system is in an expected measured state.

As systems become more complex and threats more sophisticated, PCR-based attestation becomes increasingly essential for establishing trust in computing platforms. From securing boot processes against firmware attacks to enabling remote verification of cloud infrastructure, PCRs provide the cryptographic foundation for trusted computing. Understanding PCR architecture, operations, and applications enables designers to leverage these powerful security mechanisms in building trustworthy systems that resist evolving threats.

Related Topics