Releasing Secrets: Sealing and Unsealing

The Core Idea

Recording the boot state is useful, but the real power comes from acting on it. TPM Sealing lets you encrypt a secret in a way that is permanently bound to a specific PCR state. The TPM will only decrypt (unseal) the secret if the current PCR values exactly match the values that were present when the secret was sealed.

Think of it like a combination lock where the combination is the hash of your entire boot history. If anything in the boot sequence changes — even a single bit in the kernel binary — the combination changes, and the lock will not open.

How Sealing Works

Using a tool like tpm2-tools, the operator first reads the current "known-good" PCR values right after a clean install, then creates a policy object bound to that exact PCR set, and finally seals the disk encryption key under that policy. The result is a sealed key object stored on disk — useless without the TPM that sealed it, and useless if the PCR state has changed.

The Protection in Action

Suppose an attacker installs a rootkit by modifying the GRUB bootloader:

1. The bootloader binary changes → its SHA-256 hash changes.
2. During the next boot, the CRTM measures the modified GRUB → extends PCR[4] with the new hash.
3. The final PCR[4] value is different from the "known-good" value.
4. The OS boots and asks the TPM to unseal the disk encryption key.
5. The TPM compares current PCR[4] to the sealed policy. Mismatch.
6. The TPM refuses to release the key. The disk remains encrypted. The attacker cannot read the data.

This is how BitLocker (Windows) and systemd-cryptenroll (Linux) work. The disk encryption key is sealed to the TPM, and the TPM only releases it if the boot sequence matches the expected state.

The Operational Challenge: Resealing After Updates

Sealing creates an operational responsibility: every time you legitimately change the boot chain (kernel update, BIOS update, bootloader update), the PCR values will change, and you must reseal your secrets against the new values. Failure to do this is the most common operational mistake with TPM-based systems.

A robust update workflow looks like this:

1. Schedule maintenance window
2. Boot into known-good state
3. Apply kernel/firmware update
4. Reboot into new state
5. Verify new PCR values are expected (not tampered)
6. Reseal secrets against new PCR values
7. Confirm unsealing works before closing maintenance window

Key Point: Sealing binds secrets to a specific, verified boot state. Any tampering — even a single changed byte in the bootloader — produces a different PCR state and breaks the seal. This is the mechanism that makes full-disk encryption genuinely tamper-resistant, not just password-resistant.