Excluded PCR Indexes: Disk-Key Sealing Policy vs. Attestation PCR Template

Introduction

EVE-OS (Edge Virtualization Engine) uses TPM (Trusted Platform Module) PCR (Platform Configuration Registers) values for two different purposes, controlled by two independent settings:

1. The disk-key sealing policy, which PCRs must match for the device to unlock its own vault (data-at-rest).
2. The attestation PCR template, which PCR values Edge Infrastructure Services expects to see when it verifies the device's TPM quote.

Excluding a PCR index from the sealing policy (the flexible PCR mechanism) does not change what the device reports during remote attestation, and it does not change what Edge Infrastructure Services expects. If you exclude a PCR from sealing but leave the attestation template unchanged, attestation can still flag or fail on that PCR.

This is expected behaviour, not a bug: the two mechanisms answer different questions and are deliberately decoupled. This document explains both, why they are separate, and what to do about the mismatch.

The Two Mechanisms

1. Disk-key sealing policy (flexible PCR)

Question it answers: "Is this machine in a state where it is allowed to decrypt its own data?"

The vault key is sealed into the TPM under a PCR policy. At boot the TPM will only release the key if the selected PCRs still hold the same values they had when the key was sealed. If a selected PCR changes (for example, due to a firmware update, a device upgrade, or a new bootloader), the unseal fails, and the device must recover its vault key from Edge Infrastructure Services.

The flexible PCR mechanism lets you choose which PCR indexes take part in that policy, per device, from Edge Infrastructure Services. The device stores the selection locally and re-seals the key when the policy changes.

• Available from EVE-OS 16.0.1-lts onwards.
• Default selection: PCRs 0,1,2,3,4,6,7,8,9,10,11,12,13,14 (PCR 5 excluded as volatile; it measures the GPT partition table, which EVE-OS itself modifies on every A/B base-OS update).
• The device enforces these guardrails when it receives a policy:
  • PCR 0 must be included (the firmware/S-CRTM root of the measured boot).
  • PCR 5 must not be included (volatile by design).
  • Indexes must be in the range 0-15, with no duplicates.
  • If a policy violates these rules, the device rejects it and keeps the previous policy.

Effect of excluding an index: that PCR no longer gates access to the vault key. Its value might change freely without locking the device out of its own data.

2. Attestation PCR template

Question it answers: "Does Edge Infrastructure Services recognise the software and firmware this device booted?"

During remote attestation the device produces a TPM quote (a signed statement of its current PCR values) and sends it to Edge Infrastructure Services. Edge Infrastructure Services compares the quoted values against the PCR template it holds for that device: the set of values it expects for a known-good boot.

Two things are important here:

• The quote always covers PCRs 0-15 in the SHA-256 bank. This selection is fixed in EVE-OS and is independent of the sealing policy. Excluding a PCR from sealing does not remove it from the quote; the device still reports it.
• The comparison is per-index and exact. For each index the template specifies, the reported value must equal the expected value. There is no automatic wildcard for indexes you excluded from sealing, because Edge Infrastructure Services has no way to know that an exclusion was intentional rather than the symptom of a compromise.

Effect of a mismatch: Edge Infrastructure Services reports an attestation warning or failure for that index. Depending on your configuration this can also withhold the Edge Infrastructure Services-side vault-key rescue, since that rescue is gated on successful attestation.

Side by side

Why They Are Separate

It would be convenient if excluding a PCR from sealing automatically wildcarded it in the attestation template, but that would be the wrong default. Sealing is an availability decision you make about your own hardware: "PCR 1 on this platform is noisy, and I do not want noise to lock me out of my data." Attestation is a trust decision Edge Infrastructure Services makes about the device: "do I still recognise what booted here?"

Letting a device-side availability setting silently relax what Edge Infrastructure Services verifies would let a device weaken its own attestation. You therefore change the two settings independently and deliberately.

What the Warning Means

An attestation warning on an index you excluded from sealing tells you exactly one thing: that PCR's value no longer matches what Edge Infrastructure Services expected.

It does not mean the exclusion failed. If the exclusion is in effect, the vault will unlock locally regardless of that PCR. It means the record Edge Infrastructure Services holds for that index is now stale relative to the device.

Before deciding what to do, establish which of these you are looking at:

• A change you caused and understand: you applied a firmware update, changed a Secure Boot setting, or the index is one you already know to be unstable on this hardware. Expected; act on it in the following section.
• A change you cannot account for: no known maintenance, and the index is one that should be stable. Investigate before relaxing anything. This is precisely the case the template exists to catch.

Your Options

Option A: Acknowledge the warning and leave the template as it is

Appropriate when you want to keep the strictest possible remote verification and can tolerate a standing warning on that index, or when you expect the value to settle back to the template's expectation.

• Attestation continues to flag the index on every cycle.
• Nothing about data-at-rest changes: the exclusion still protects local unlocking.
• If attestation failure gates the Edge Infrastructure Services-side vault-key rescue in your setup, a standing failure removes your recovery path for the next event that does break sealing. Verify this before choosing to live with it.

Option B: Align the template with the sealing policy

If you had a sound reason to exclude an index from sealing, that same reason almost always applies to the attestation template. A PCR whose value is not stable enough to gate your own data is also not a meaningful trust signal for Edge Infrastructure Services; all it can produce is recurring false alarms.

Excluding (wildcarding) that index in the device's PCR template is generally safe and is the recommended action, provided the exclusion was justified in the first place.

Example: PCR 1 flakiness. Some platforms measure volatile data into PCR 1, for instance firmware that writes the CPU's live clock speed and voltage into the SMBIOS table, which is then measured into PCR 1. The value legitimately differs from boot to boot with no change in software or firmware. Excluding PCR 1 from the sealing policy stops it locking the vault; excluding it from the attestation template stops it raising a warning on every attestation cycle. The trust loss is minimal because a field that changes with CPU frequency was never carrying a useful integrity signal.

Keep in mind what you give up. After wildcarding, a genuine change to that index (including a malicious one) will no longer be detected by attestation. Make the call per index, not as a blanket policy.

See Manage PCR Templates for the procedure.

Option C: Re-include the index in the sealing policy

If reviewing the warning shows the exclusion was not actually justified (the value changed for a reason you can fix, or the index is one you want gating your data), put it back in the sealing policy and let both mechanisms enforce it again. The device re-seals the vault key under the updated policy.

Choosing per Index

The right answer depends on what each PCR measures and how stable it is on your hardware. Broadly:

• Firmware-owned PCRs (0-7) carry the strongest integrity signal and change on legitimate firmware/Secure Boot maintenance. Exclude with care; PCR 0 cannot be excluded from sealing at all.
• Volatile or platform-quirk indexes, where a vendor measures data that varies between boots without any software change, are the clear-cut cases for exclusion from both mechanisms.
• Indexes EVE-OS does not use can be excluded with little practical loss.

Do not treat this list as a decision procedure. For the specific meaning of each index, what writes to it, and the concrete risk of excluding it, see TPM PCR Index Security Implications  and decide according to your own risk profile.

Recommended Sequence

1. Identify which index is being flagged and confirm whether the change is accounted for.
2. If it is not accounted for, investigate first; do not relax the template to silence an unexplained change.
3. If it is accounted for and the index is genuinely unstable on your platform, exclude it from the attestation template to match the sealing policy.
4. Re-check attestation status and confirm the warning has cleared and the Edge Infrastructure Services-side vault-key rescue path is healthy.

Next Steps

This is a series of articles, you will likely follow them in this order: 

• Overview of the Trusted Platform Module in EVE-OS
• Factors Affecting PCR TPM Register
• Remote Attestation Overview 
• Flexible Platform Configuration Registers (PCR) Policy Overview 
• Excluded PCR Indexes: Disk-Key Sealing Policy vs. Attestation PCR Template - You are here!
• Manage a PCR Policy Using ZCLI
• Manage PCR Templates
• Configure an attestation policy in your project. 
• Use EVE-OS Local UI to analyze attestation issues.