Skip to main content

​
Introduction

The Flexible PCR Policy lets operators control which Platform Configuration Registers (PCRs) EVE-OS (Edge Virtualization Engine) uses when sealing the vault encryption key into the Trusted Platform Module (TPM). Before this feature, the PCR index list was hardcoded in EVE-OS at compile time. Now Edge Infrastructure Services manages the list per node and distributes it as part of the node configuration. For background on PCRs and how EVE-OS uses them, see TPM PCR Index Security Implications and Factors Affecting PCR[1]. For how the sealing policy relates to the separate attestation PCR template, see Excluded PCRs: Disk-Key Sealing vs. Attestation Template.

​
How It Works

EVE-OS seals the vault encryption key against a set of PCR values. Sealing means the TPM will only release the key if the node boots into a state that produces the same PCR values recorded at sealing time. The default sealing policy covers PCRs 0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, and 14. PCR 5 is excluded because it measures the GPT partition table, which EVE-OS itself rewrites on every A/B base image update. PCR 15 is excluded because it is reserved for OS or user-defined measurements. With Flexible PCR Policy, Edge Infrastructure Services sends a PCR index list and a policy ID to the node. When the node receives a new policy, EVE-OS validates it, unseals the vault key under the current policy, and re-seals it under the new one. This happens locally, without a reboot and without a remote attestation round-trip. Remote attestation is needed only if the local unseal fails, for example because the PCR values have already changed since the key was last sealed. The node validates every policy it receives and rejects any policy that:
  • Omits PCR 0 (the Static Root of Trust for Measurement, which anchors the measured boot chain).
  • Includes PCR 5 (volatile by design, as described in the preceding paragraph).
  • Contains duplicate indexes.
  • Includes indexes outside the range 0–15.
  • Contains more than 15 indexes.
If a policy fails validation, the node keeps its previous policy and reports the rejection. ZCLI applies the same checks before sending a policy, so most invalid policies are caught before they reach the node. After the node re-seals the vault key under the new policy, it stores the PCR index list and policy ID on disk in the persist partition for subsequent unseal operations. If that saved policy is ever lost or does not match the sealed key, EVE-OS can recover the correct index set by testing candidate subsets of PCRs 0–15 against the sealed key’s policy digest.

​
Key Benefits

  • Per-node control. Tailor the PCR sealing policy to the specific hardware, firmware, and boot configuration of individual nodes without modifying or redeploying EVE-OS.
  • Reduced false lockouts. Exclude PCRs that change frequently due to legitimate hardware or firmware variation (for example, PCR 1 on nodes where host platform configuration changes are expected), reducing unnecessary vault lockouts.
  • Policy versioning. Each policy carries a unique policy ID that increments with every change, giving operators a traceable record of which PCR configuration was active when a vault key was sealed.
  • Backward compatibility. Nodes that do not receive a custom policy continue to use the EVE-OS default PCR indexes. No migration steps are required for existing deployments.
  • ZCLI safety guardrails. ZCLI enforces a multi-stage review workflow when modifying a policy, including a security impact warning when PCRs are removed from the default set.

​
In This Series

Manage PCR Templates covers a related but distinct concept: storing expected PCR values as named templates on a hardware model, so Edge Infrastructure Services can verify that a node’s boot measurements match what is expected for that hardware. PCR sealing policy (this article) controls which indexes protect the vault key; PCR templates control which values those indexes should contain for a given hardware model.