Sealing

While both produce ciphertext, sealing differs fundamentally from standard encryption:

Sealing is not a replacement for a KMS but a complementary primitive for data-in-use protection where the decryption key must never exist outside the CPU package.

The cryptographic handshake that makes Sealing useful. Before an enclave can unseal data, it must generate a signed report proving its identity and integrity to a remote party. This report includes the enclave's MRENCLAVE (code identity) and MRSIGNER (author identity). Without attestation, a malicious host could impersonate the enclave and request decryption. The attestation service validates that the enclave is genuine, running unmodified code on authentic hardware, before releasing the decryption key.

The dominant implementation of TEE that provides the EGETKEY instruction used for Sealing. SGX creates protected memory regions called enclaves. The Sealing operation derives a key from the CPU's Root Provisioning Key fused at manufacture, combined with the enclave's identity. Two modes exist:

• Sealing to MRENCLAVE: Binds data to the exact code version
• Sealing to MRSIGNER: Binds data to any enclave signed by the same developer This hardware-level binding ensures sealed data cannot be decrypted on a different machine or by a modified enclave.

The hardware foundation that makes Sealing meaningful. Modern processors with Total Memory Encryption (TME) or Secure Memory Encryption (SME) transparently encrypt all data moving between the CPU and RAM. This prevents physical attackers from extracting sealed data via DRAM probing or cold boot attacks. The encryption key is generated randomly at each boot and stored in an inaccessible register. When combined with Sealing, this creates a defense-in-depth: sealed data is encrypted at rest on disk, and decrypted data exists only in encrypted memory.

The immutable foundation upon which Sealing depends. A Hardware Root of Trust is a physically unalterable source of cryptographic identity embedded in the silicon. For Intel SGX, this is the Root Provisioning Key burned into fuses during manufacturing. This key never leaves the processor package and is used to derive all subsequent sealing keys. The chain of trust flows:

• Root Provisioning Key → Seal Key → Encrypted Data Blob If an attacker could extract this root key, all sealed data across every device would be compromised. The physical immutability of this root is the ultimate security guarantee.

The operational workflow that leverages Sealing for production systems. When deploying a confidential AI service, the process follows:

1. Initial Boot: Enclave generates a sealing key pair
2. Remote Attestation: Enclave proves its identity to a Key Management Service
3. Secret Injection: KMS securely transmits model weights or API keys into the enclave
4. Seal to Disk: Enclave encrypts the secrets with its hardware-derived key and writes the blob to persistent storage
5. Recovery: On restart, the enclave unseals the blob, validates integrity, and resumes service without human intervention This ensures secrets are never exposed to the host OS or cloud provider.

The security objective that Sealing helps achieve across the data lifecycle. Data exists in three states:

• Data-at-Rest: Protected by disk encryption (e.g., AES-XTS)
• Data-in-Transit: Protected by TLS 1.3
• Data-in-Use: Protected by TEEs and Sealing Sealing bridges the gap between states. When an enclave processes sensitive data and needs to persist it, Sealing encrypts it with a key that only exists within the TEE. This means the data is protected both at rest (on disk) and in use (only decryptable inside the enclave). The sealed blob is useless to any process outside the TEE, including the cloud provider's hypervisor.