Keys, Secret Provisioning, Sealing, and Rollback

Why key management matters

Memory isolation protects data while a TEE is running.

A real system must also answer: How does the TEE receive a secret? Where is the secret stored after shutdown? How does a new instance recover access? How are keys rotated? How are old versions rejected? What happens when hardware fails? How is old state detected?

TEE security depends heavily on the answers.

Types of keys

Hardware root key — Tied to a device or platform. Ordinary application software should not be able to read it directly. It may be used to derive other keys.

Attestation key — Authenticates evidence about the platform or workload. The application may not directly control this key.

Sealing key — Protects application data stored outside the TEE.

Session key — Protects one communication session. It should normally be temporary.

Application data key — Encrypts application files, records, or datasets.

Signing key — Authorizes messages, transactions, releases, or protocol actions.

Different key purposes should normally use different keys.

Key derivation

A TEE may derive operational keys from:

• Hardware secret
• Application measurement
• Signer identity
• Product identity
• Security version
• Platform identity
• Key purpose
• Application context

A conceptual derivation may look like:

`` derived_key = KDF( hardware_secret, application_identity, security_version, key_purpose ) ``

The key_purpose value provides domain separation. A storage key should not also be used as a network encryption key, signing key, authentication key, or backup key.

Secret provisioning

Secret provisioning delivers a secret to an approved TEE.

A common flow is:

1. Launch the TEE. 2. Generate a temporary key pair inside it. 3. Bind the public key to attestation evidence. 4. Send the evidence to a Verifier. 5. Check the evidence against policy. 6. Establish an encrypted channel to the attested key. 7. Release the secret. 8. Keep plaintext inside the protected environment.

A secret provider may be a key management service, HSM, Key Broker Service, enterprise secrets manager, another TEE, user device, or threshold key network.

AWS KMS uses attestation documents from Nitro Enclaves and NitroTPM environments before performing supported cryptographic operations.

What is sealing?

Sealing protects application data before it is stored outside the TEE.

A simplified process is:

1. Obtain or derive a sealing key. 2. Encrypt the data. 3. Add integrity protection. 4. Store the ciphertext outside the TEE. 5. Load the ciphertext later. 6. Verify and decrypt it inside an authorized environment.

Exact application identity

A sealing policy may bind a key to the exact application measurement.

Only the same measured application can recover the protected state.

Benefit: The access policy is narrow.

Limitation: A software update changes the measurement and may lose access to old data.

Intel SGX commonly represents the exact enclave identity through a value known as MRENCLAVE.

Signer identity

A sealing policy may instead bind access to the authority that signed the application. This can allow updated versions signed by the same authority to recover old state.

Intel SGX commonly represents this form of identity using MRSIGNER.

Benefit: Software upgrades become easier.

Limitation: More binaries may become eligible to access the data. The system must also prevent a downgrade to an older signed version with known vulnerabilities.

Sealing does not prevent rollback by itself

Suppose an application stores:

`` Balance: 100 State version: 8 ``

It later stores:

`` Balance: 20 State version: 9 ``

A malicious host cannot decrypt either file. The host replaces version 9 with the old version 8 file. Version 8 may still have a valid authentication tag because it was created by the genuine application.

The host has not broken encryption. It has restored an older valid state. This is a rollback attack.

Rollback protection

Possible rollback controls include:

• Hardware monotonic counters
• Trusted external version service
• Append-only transparency log
• Distributed consensus
• Blockchain commitment
• Multiple independent storage providers
• Version-bound key release
• Signed state checkpoints

Each method introduces new assumptions. A blockchain commitment may provide a public record of the latest state, but it may introduce cost, latency, public metadata, finality assumptions, and smart contract risk.

Key rotation

Keys may need to change because of security policy, application updates, hardware migration, employee changes, certificate expiration, suspected compromise, algorithm migration, or platform deprecation.

A rotation plan should answer:

• Who authorizes the rotation?
• Where is the new key generated?
• How is old data re-encrypted?
• When is the old key deleted?
• How are backups updated?
• How is rollback prevented?
• How are old application versions rejected?

Recovery changes the trust model

Hardware can fail. If a key is available only from one physical TEE, permanent hardware failure may make the data unrecoverable.

Recovery options include HSM-controlled backup keys, threshold key shares, several authorized TEEs, offline recovery keys, enterprise key escrow, and re-encryption to a new platform.

Each recovery mechanism creates another path to the secret. That path becomes part of the security model.

Example: Blockchain validator key

A validator stores its signing key inside a TEE. The host cannot directly read the key.

The design still needs to answer:

• Can the host request conflicting signatures?
• Does the enclave track previous signatures?
• Can the host roll back the signing history?
• How is a replacement machine authorized?
• Can two recovered copies sign at the same time?
• How is the key rotated?
• What happens if attestation fails?

Protecting key bytes is only one part of protecting key use.

Key takeaways

• TEE systems use different keys for different purposes.
• Key derivation should include purpose-specific context.
• Secret provisioning should depend on verified attestation.
• Sealing protects stored data outside the TEE.
• Exact-measurement policies are strict but difficult to upgrade.
• Signer-based policies support updates but expand trust.
• Authenticated encrypted state can still be rolled back.
• Recovery and backup introduce additional trust.