Introduction
The following table provides detailed usage, classification, and security implications of various Trusted Platform Module (TPM) Platform Configuration Registers (PCRs) defined across different Trusted Computing Group (TCG specifications), primarily TCG PC Client Platform Firmware Profile (PFP), coreboot, and Grub2.
In the context of the TCG PFP Specification for PCRs 0–7, a general guideline suggests even-numbered PCRs are for code and odd-numbered PCRs are for data/configuration.
TCG PCR Index Map and Security Implications
| PCR Index | PCR Usage / Meaning | Config or Code Measurement | Security Implication |
|---|---|---|---|
| 0 | Static Root of Trust for Measurement (SRTM), BIOS, Host Platform Extensions, Embedded Option ROMs, and PI Drivers. Includes PEI, DXE, and SMM code in flash FV. Pre-EVE-OS boot, EVE-OS is not directly measuring anything into this PCR, but relies on it for its vault sealing policy. |
Code (Core Firmware Code). | Establishes the foundational integrity of the platform by measuring the core, manufacturer-controlled firmware components (BIOS/CRTM). A failure here means the starting point of trust is compromised. |
| 1 | Host Platform Configuration. Includes OEM configuration data such as SMBIOS tables, Setup variables, Boot####/BootOrder variables, and CPU Microcode update. Pre-EVE-OS boot, EVE-OS is not directly measuring anything into this PCR, but relies on it for its vault sealing policy. See Host Platform Configuration (PCR 1) Interpretation Guide for more details. |
Configuration/Data (Host Platform Settings). | Verifies the integrity of static, manufacturer-provided configuration settings. Ensures configuration choices critical to boot (like boot order and hardware initialization data) have not been tampered with. |
| 2 | UEFI driver and application Code. This includes drivers loaded from HBA’s/disks, external Option ROMs, or non-host firmware updateable by an entity other than the OEM. Pre-EVE-OS boot, EVE-OS is not directly measuring anything into this PCR, but relies on it for its vault sealing policy. |
Code (Third-party/Optional Drivers and Applications). | Tracks the integrity of user- or vendor-added executable components (for example, PCIe card Option ROMs). This allows validation of user-configurable software outside the core manufacturer's firmware. |
| 3 | UEFI driver and application Configuration and Data. Includes configuration data associated with PCR components, such as SCSI configuration or non-host platform configuration that can be updated by entities other than platform firmware. Pre-EVE-OS boot, EVE-OS is not directly measuring anything into this PCR, but relies on it for its vault sealing policy. |
Configuration/Data (Third-party/Optional Settings). | Measures configuration associated with third-party components. Ensures the settings for optional hardware (for example, RAID arrays, non-host environments) are trusted. |
| 4 | UEFI Boot Manager Code (usually the MBR) and Boot Attempts. Includes the OS Loader and UEFI applications like pre-OS diagnostics. Shim also uses PCR 4 for measuring UEFI applications (for example, second_stage, MOK_MANAGER). Pre-EVE-OS boot, EVE-OS is not directly measuring anything into this PCR, but relies on it for its vault sealing policy. |
Code (OS/Boot Transition Code). | Records the chain of execution leading to the OS, verifying that the intended boot manager/OS loader is executed and logging any preceding boot attempts. |
| 5 | Boot Manager Code Configuration and Data and GPT/Partition Table. Also records the ExitBootServices action. Pre-EVE-OS boot, EVE-OS is not directly measuring anything into this PCR, EVE-OS is NOT using it for vault sealing policy. |
Configuration/Data (OS Boot Configuration). | Verifies static, security-relevant OS boot configuration data, particularly the integrity of the GUID Partition Table (GPT), and marks the final transfer of control from platform firmware to the OS environment. |
| 6 | Host Platform Manufacturer Specific. Reserved for OEM defined measurements. Pre-EVE-OS boot, EVE-OS is not directly measuring anything into this PCR, but relies on it for its vault sealing policy. |
Code. Manufacturer Specific. | Provides an index for OEM-specific measurements that fall outside standard definitions. Its content is not uniform across platforms. |
| 7 | Secure Boot Policy, Secure boot Verification Authority. Includes UEFI Secure Boot variables (PK, KEK, db, dbx), and security feature disabling events (for example, "UEFI Debug Mode", "DMA Protection Disabled"). Shim also uses PCR 7 for UEFI variables and verification policy authority ("Shim", "db", "MokList"). Pre-EVE-OS boot, EVE-OS is not directly measuring anything into this PCR, but relies on it for its vault sealing policy. |
Policy/Configuration (Security Policy). | Protects the integrity of the secure boot enforcement mechanism. Measures security settings and cryptographic keys that determine what code is trusted to load on the platform. |
| 8-15 | Defined for use by the Static OS. For EVE-OS use, check table EVE-OS PCR Index Map and Security Implications |
Mixed (OS Dependent). | Extends the chain of trust from the pre-OS environment into the operating system's static components. |
| 11 | BitLocker access control. For EVE-OS use, check table EVE-OS PCR Index Map and Security Implications |
Configuration/Policy (Access control list/data). | Used by Windows BitLocker to bind encryption keys to the integrity state of the boot environment. Critical for disk encryption security. |
| 14 | Used by UEFI Windows BitLocker policies. for example, PCR 14 is used for Boot Authorities. Shim uses PCR 14 for specific UEFI variables (MokList, MokSBState). For EVE-OS use, check table EVE-OS PCR Index Map and Security Implications |
Configuration/Policy (OS data/Authorities). | Tracks OS environment specifics and security authorities required for OS loader validation (for example, MokList in Shim). |
| 16 | Debug. Not used by EVE-OS. |
N/A (General Debug). | Not intended for production use, sealing, or attestation. It is resettable from any locality and is used primarily for software development and troubleshooting. |
| 17-22 | Represents the platform's Dynamic Root of Trust for Measurement (DRTM). PCR 17 is typically used to measure the first component executed after DRTM initiation. Not used by EVE-OS. |
Code/Data (DRTM dependent). | Used to establish a new, secure execution environment at runtime, dynamically resetting the trust chain after the initial boot phase is complete. |
| 23 | Application Support. Used by Static or Dynamic operating systems or their applications. Not used by EVE-OS. |
Application Data/Code (OS/App Dependent). | Provides a resettable PCR intended for OS or application use to manage their own local integrity states. |
EVE-OS PCR Index Map and Security Implications
| PCR Index | PCR Usage / Meaning | Config or Code Measurement | Security Implication |
|---|---|---|---|
| 8 | Grub command line: All executed commands, kernel command line, module command line. Used by EVE-OS bootloader (Grub), EVE-OS relies on it for its vault sealing policy. |
Configuration/Data (Grub command strings/Boot Sector). | For Grub, ensure the OS is loaded using expected, non-malicious command line arguments. |
| 9 | Files: Any file read by GRUB (file binary). Used by EVE-OS bootloader (Grub), EVE-OS relies on it for its vault sealing policy. |
Code/Binary (File binary content). | Ensures the integrity of OS files accessed by the bootloader (Grub). |
| 11 | Not used by EVE-OS. | N/A | N/A |
| 12 | Not used by EVE-OS. | N/A | N/A |
| 13 |
Used by EVE-OS bootloader (Grub) to measure the booting read-only root filesystem image.
|
Code (rootfs image binary) | Integrity of the Operating System. Measuring the root filesystem image ensures that the core OS components, libraries, and binaries accessed immediately after the boot loader have not been modified. This measurement is used to bind sensitive operations (like disk decryption/access control) to a known, trusted state of the OS environment. A mismatch in this PCR value indicates that the core operating system layer is either unauthorized or compromised. |
| 14 | Used by EVE-OS to measure the content of /config partition. EVE-OS relies on it for its vault sealing policy. |
Configuration (EVE-OS data/Authorities). The content measured is generally static data or system policy that dictates runtime behavior | Integrity of Core OS Policies and Operational State. Measuring the configuration partition content ensures that the critical, static configuration files and policies necessary for the EVE-OS to function securely have not been altered prior to runtime. This is crucial for maintaining the trust chain into the OS environment. A mismatch indicates unauthorized modification of the core OS security or operational policies. |
| 15 | Not used by EVE-OS. | N/A | N/A |
The function of PCRs acts much like a blockchain ledger (though locally scoped to the TPM): each new measurement is cryptographically linked to the previous state using a hashing function (PCR (new) = HASH (PCR (old) || HASH(Data))). This design ensures that the order of measurements matters, and any tampering or deviation in the measurement sequence results in a final PCR digest value that will not match the expected state, thus triggering a security failure for applications (like EVE Vault) sealed to those values.
References
- TCG Trusted Boot Chain in EDK II
- TCG Trusted Attestation Protocol (TAP) Information Model for TPM Families 1.2 and 2.0 and DICE Family 1.0
- TCG PC Client Platform Firmware Profile Version 1.06 Revision 52
- Trusted Platform Module 2.0 Library, Part 1 — Version 1.84
- Trusted Platform Module 2.0 Library, Part 2 — Version 1.84
- Trusted Platform Module 2.0 Library, Part 3 — Version 1.84
- Measured boot implementation in EVE-OS
Next Steps
- Overview of the Trusted Platform Module in EVE-OS
- Remote Attestation Overview
- TPM PCR Index Security Implications - You are here!
- Factors Affecting PCR[1] TPM Register
- Host Platform Configuration (PCR 1) Interpretation Guide
- Manage PCR Templates
- Configure an attestation policy in your project.
- Use EVE-OS Local UI to analyze attestation issues.