Enclave Sealing

Sealing cryptographically binds data to the enclave identity (MRENCLAVE) or the sealing authority (MRSIGNER).

• MRENCLAVE (Enclave Identity): Binds to the exact hash of the enclave's code and initial state. Any code change makes the data permanently inaccessible.
• MRSIGNER (Sealing Authority): Binds to the developer's signing key. Allows different versions of the same application to share sealed data.

This ensures that even if an attacker gains root access to the host operating system and copies the sealed data blob, they cannot decrypt it without running inside the original enclave.

The sealing key is not stored on disk. It is derived on-the-fly by the TEE hardware using a fused, platform-unique root key and the enclave's measurement.

• The CPU combines a hardware-embedded root key (fused at manufacture) with the enclave's cryptographic identity.
• This derived key is only accessible to the enclave during execution.
• On Intel SGX, this is the Enclave Key Hierarchy; on AMD SEV, it leverages the Platform Diffie-Hellman key.

The result is a symmetric key that exists only within the CPU package and is never exposed to RAM, the OS, or the hypervisor.

Sealing integrates with monotonic counters and versioning to prevent an attacker from restoring an old, vulnerable version of sealed data.

• The TEE maintains a hardware-backed counter that only increments.
• When sealing data, the current counter value is embedded in the sealed blob.
• On unsealing, the enclave verifies the counter hasn't been tampered with.

This defeats rollback attacks where an adversary with physical access replaces the latest sealed state with a previous one to exploit a patched vulnerability.

Sealing policies define the scope of where data can be decrypted.

• Platform Sealing: Binds data to a specific physical CPU. The sealed blob cannot be decrypted on any other machine, even with identical enclave code. Ideal for node-specific credentials.
• Migration Sealing: Allows data to be transferred between trusted platforms in a cluster. Requires a migration authority to re-wrap the sealed data for the target platform's TEE.

This distinction is critical for designing stateful, fault-tolerant confidential services that must survive hardware failures.

The output of a seal operation is an opaque, authenticated ciphertext blob with a defined structure.

• Payload: The original plaintext encrypted with AES-GCM.
• Key Blob: The sealing key itself, encrypted with the CPU's hardware key.
• Enclave Identity: The MRENCLAVE or MRSIGNER value required for decryption.
• Policy Flags: Attributes like anti-rollback version and migration permissions.
• MAC Tag: An authentication tag over the entire structure to detect tampering.

Any modification to the sealed blob—even a single bit—will cause the unseal operation to fail cryptographically.

Enclave sealing is foundational for stateful confidential AI workloads.

• Model Weight Persistence: Encrypt fine-tuned model weights to disk so they survive enclave restarts without exposing proprietary IP to the host.
• Secure Checkpointing: Save training state periodically in long-running confidential training jobs.
• Local Secret Storage: Store API keys and database credentials that the enclave needs across reboots, avoiding external key management dependencies.
• Confidential Ledgers: Maintain an append-only, tamper-evident log where each entry is sealed to the auditing enclave.

The cryptographic process that verifies the identity and integrity of a Trusted Execution Environment before sealing or unsealing operations. A remote party or local platform generates an attestation report containing the enclave's measurement hash, hardware TCB version, and platform security state. This report is signed by a hardware-rooted key, proving the enclave is genuine. Without attestation, sealing is meaningless—you would be encrypting data to an unverified entity. Attestation binds the sealing key derivation to a specific, verified code identity, ensuring only an enclave running the exact expected software can decrypt the data.

A cryptographic hash of the initial code, data, stack, and configuration loaded into a TEE. This measurement serves as the enclave's unique identity fingerprint. When sealing data, the enclave can bind the encryption to its own measurement (MRENCLAVE in Intel SGX) or to the identity of the signing authority (MRSIGNER). Binding to MRENCLAVE means only the exact same binary version can unseal; binding to MRSIGNER allows any enclave signed by the same developer key to decrypt, enabling version migration without data loss.

A storage architecture where data is encrypted by the enclave before being written to disk, ensuring data-at-rest is cryptographically bound to the enclave's identity. The host operating system, hypervisor, or cloud provider sees only ciphertext and cannot decrypt it. This is the direct application of sealing: the enclave derives a sealing key from its measurement and platform keys, encrypts data with it, and stores the ciphertext externally. On restart, the same enclave re-derives the key and decrypts. This enables stateful confidential workloads like databases and ledgers.

A KMS that integrates with TEE attestation to release decryption keys only to verified enclaves. Unlike standard KMS that authenticates via API tokens, a Confidential KMS validates the enclave's attestation report before releasing secrets. This enables a secure key release pattern: an enclave proves its identity to the KMS, receives a wrapping key, and uses it to decrypt sealed data. This decouples key management from the enclave itself, allowing centralized policy control, rotation, and revocation across fleets of enclaves without modifying sealed data.

The immutable cryptographic foundation embedded in the silicon that anchors all sealing operations. In Intel SGX, this is the Root Provisioning Key burned into the CPU during manufacturing; in AMD SEV, it's the Root Key managed by the Platform Security Processor. These keys never leave the hardware and are inaccessible to all software. The sealing key is derived from this root combined with the enclave measurement, creating a transitive trust chain: hardware → firmware → enclave → sealed data. Compromising sealed data requires breaking the silicon itself.

Defensive techniques that protect the sealing key derivation process from leakage through physical side effects. Attackers may observe timing variations, power consumption, or electromagnetic emissions during cryptographic operations to extract key material. Modern TEEs implement constant-time algorithms, cache partitioning, and microarchitectural mitigations to prevent key extraction. Sealing operations must be side-channel resistant because the derived key is the linchpin of persistent confidentiality—if an attacker extracts the sealing key through a side channel, all sealed data is compromised regardless of cryptographic strength.