Data Sealing

Data sealing cryptographically binds plaintext to the enclave's unique identity. The sealing key is derived from the MRENCLAVE (a hash of the enclave's code) or MRSIGNER (the author's signing key). This ensures that only an enclave running the exact same code, or code from the same trusted author, can unseal the data. This prevents a malicious or modified enclave from accessing persisted secrets.

The sealing process uses Authenticated Encryption with Associated Data (AEAD), typically AES-GCM. This provides both confidentiality and integrity. Any tampering with the sealed data blob on the untrusted storage will be detected immediately upon unsealing, causing a decryption failure. This guarantees that the enclave never processes corrupted or maliciously modified state.

Sealing policies can bind data to a specific Security Version Number (SVN) or CPUSVN of the platform's firmware and hardware. If a vulnerability is patched and the security version is incremented, an enclave can be configured to refuse to unseal data that was sealed on a vulnerable, older version. This prevents a rollback attack where an attacker downgrades the platform to exploit a known flaw.

To prevent an attacker from replacing the latest sealed data with a valid but older version (a replay attack), sealing can be bound to a hardware monotonic counter. The enclave increments the counter on each write and verifies it on read. If the counter in the sealed blob doesn't match the hardware's current counter value, the data is rejected, ensuring only the most recent state is restored.

Two primary sealing policies exist:

• Sealing to the Enclave Identity (MRENCLAVE): Only the exact same enclave binary can unseal the data. Any code change breaks access.
• Sealing to the Signing Identity (MRSIGNER): Any enclave signed by the same developer key can unseal the data. This allows for seamless data migration between application versions from the same vendor.

The primary use case for data sealing is maintaining a trusted state across power cycles. An enclave can seal its internal state (e.g., database encryption keys, user credentials, or a blockchain wallet) to the local disk. On restart, the enclave attests itself to a local or remote verifier, unseals its state, and resumes secure operation without human intervention to re-inject secrets.

A cryptographic hash of the enclave's initial code, data, and configuration. Represented as MRENCLAVE in Intel SGX, this fingerprint uniquely identifies the software running inside the TEE. Data sealing binds secrets to this specific measurement, preventing unauthorized code from accessing protected data.

A physically immutable, tamper-resistant module that serves as the foundational trust anchor for the platform. It underpins:

• Secure boot verification
• Attestation key generation
• Sealed storage encryption Without this root, cryptographic binding to a platform identity is impossible.

The set of all hardware, firmware, and software components critical to security. A vulnerability in any TCB component compromises the entire system's guarantees. Data sealing ties secrets to a specific TCB version, ensuring that if a security flaw is patched, old sealed data cannot be retrieved by a downgraded, vulnerable system.

A non-invasive attack exploiting physical information leakage—such as timing, power consumption, or electromagnetic emissions—to extract secrets from a theoretically secure enclave. Defending against these attacks is critical because a compromised enclave could unseal data and expose it to an attacker monitoring the hardware.

The overarching hardware-based security paradigm that protects data in use. Data sealing is a core mechanism within this paradigm, allowing a TEE to securely persist state to untrusted storage. This closes the gap left by protecting data at rest and in transit, ensuring end-to-end confidentiality for sensitive workloads.