Background: TPM 2.0 Sealing and PCR Policies

TPM 2.0 sealing binds a secret to a set of Platform Configuration Register (PCR) values. The TPM will only release the secret when the current PCR state matches what was recorded at seal time. This is the foundation for measured boot, disk encryption key protection, and platform attestation. However, PCR values change whenever the measured components change; BIOS updates, kernel upgrades, bootloader patches. A secret sealed to PCR[7] before an OS update will fail to unseal afterward because the measurements no longer match. This is expected behavior, but it creates an operational problem: how do you seal secrets on systems that receive regular updates? TPM 2.0 provides several policy mechanisms to handle this, but they’re complex to implement correctly. wolfTPM PR #464 adds three new example programs that demonstrate the major sealing patterns with working, tested code.

Three New Examples

seal_pcr - PCR-Only Policy

The simplest sealing pattern: bind a secret directly to PCR values. No password, no signing key, just the platform state.

Feature Detail

What it does Seals a secret so it can only be unsealed when PCR values match

Modes Separate -seal / -unseal, or combined -both

Options Configurable PCR index (-pcr=N), custom blob filenames (-sealblob=)

Encryption XOR and AES parameter encryption supported

Usage: ./examples/seal/seal_pcr -both ./examples/seal/seal_pcr -seal -pcr=7 ./examples/seal/seal_pcr -unseal -pcr=7 seal_policy_auth - PolicyAuthorize with Signing Key The real-world pattern for systems that update. A TPM-resident signing key can re-authorize the PCR policy after legitimate changes (like OS updates), so secrets survive updates without re-sealing.

Feature Detail

What it does Seals with PCR policy + a signing key that can re-authorize after PCR changes

Key types ECC (-ecc) and RSA (-rsa) signing keys

Split operations Persistent authkey.bin allows seal and unseal across reboots

Encryption XOR and AES parameter encryption supported

Usage: ./examples/seal/seal_policy_auth -both -ecc ./examples/seal/seal_policy_auth -seal -rsa ./examples/seal/seal_policy_auth -unseal -rsa

**seal_nv - NV Storage with PCR Policy** Stores secrets directly in TPM non-volatile memory protected by a PCR policy. No external blob files are needed; the secret lives entirely inside the TPM.

Feature Detail

What it does Stores secrets in TPM NV memory, protected by PCR policy

Operations -store / -read / -delete lifecycle

Options Configurable NV index (-nvindex=)

No blob files Secret stays entirely inside the TPM hardware

Usage: ./examples/nvram/seal_nv -store ./examples/nvram/seal_nv -read ./examples/nvram/seal_nv -delete

Choosing the Right Pattern

---

seal_pcr seal_policy_auth seal_nv

PCR binding Yes Yes Yes

Key types No Yes No

Split operations Yes Yes No (NV storage)

Encryption No Yes (signing key) Yes

Encryption Simple binding Production systems Self-contained secrets

Testing

The PR includes a comprehensive standalone test suite (seal_test.sh) with 28 tests across three groups, covering positive flows, negative tests (PCR mismatch, missing auth keys), parameter encryption variants, and custom options. All 28 tests pass on both the SWTPM simulator and Infineon SLB9672 hardware. A dedicated GitHub Actions CI workflow runs the full suite on every PR that touches seal-related files.

Get Started

The new examples are available in wolfTPM PR #464. To build:

./autogen.sh
./configure --enable-wolfcrypt
make

# Run all seal tests
bash examples/seal/seal_test.sh

Full documentation is in examples/seal/README.md, covering all four seal examples (the existing seal/unseal plus the three new ones) with usage, environment variables, and a policy comparison table.

  If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now