Sealing and Secret Provisioning to SGX and TDX Workloads

Sealing, in the SGX sense, means encrypting enclave secrets for persistent storage outside the enclave boundary so they survive a power cycle, a deliberate teardown, or a scheduled restart. The enclave does not persist; its secrets can.

The foundation is a value called the Root Sealing Key, sometimes referred to as FK1 in Intel documentation, embedded in the CPU's fuse array at manufacturing time. It never moves. No software, no firmware, and no external entity, including Intel, can read it directly. The processor uses it only as an input to a key derivation function; the root itself is never exposed.

The mechanism an enclave uses to request a derived key is a single privileged instruction: EGETKEY. The enclave passes request parameters specifying what type of key it wants and which identity policy should bind it. The hardware incorporates the platform's Current Security Version Number, the enclave's own Software Version Number, and a random Key ID field generated via RDRAND. That last component exists for key wear-out protection: rotating the Key ID forces derivation of a fresh key, preventing any single key from accumulating too much ciphertext exposure. The hardware computes the derived key and returns it; the root remains inside the silicon.

The Intel SGX Developer Reference recommends AES-GCM via the Intel IPP Cryptography library for encrypting sealed blobs. AES-GCM is appropriate here because it provides both confidentiality and integrity in a single pass. A sealed blob that has been tampered with will fail authentication on decryption, which is a property SGX sealing alone cannot provide. The sealed ciphertext, the authentication tag, and the Key ID needed to re-derive the key are all stored together outside the enclave.

One operational requirement that receives less emphasis than it deserves: the seal key must be deleted from enclave memory immediately after use. An enclave's memory is protected against external inspection, but the enclave itself is not immune to bugs, and key material sitting in a register or on the stack longer than necessary is an unnecessary exposure surface. I have reviewed codebases where this step was deferred or simply forgotten. The enclave passed every formal verification check and still held key material in stack memory through several subsequent function calls.

Choosing between MRENCLAVE and MRSIGNER sealing policies

The policy parameter passed to EGETKEY determines which identity measurement the hardware incorporates into key derivation. Two policies are available, and choosing between them is less a technical question than a threat modeling question.

MRENCLAVE

MRENCLAVE is a cryptographic hash computed over the enclave's code and static data at load time. It changes with every build, which means only the exact binary that created a sealed blob can re-derive the key to open it. A patched build, even one that fixes a critical vulnerability, produces a different MRENCLAVE and cannot access previously sealed data.

This is the strongest isolation guarantee SGX offers. It also creates a real operational burden: any update to the enclave binary requires migrating sealed data before the old binary is retired. Teams that underestimate this friction at design time tend to encounter it painfully at the first security patch, usually somewhere around two in the morning when a rollout window is closing.

MRSIGNER

MRSIGNER is a hash over the identity of the entity that signed the enclave, combined with a Product ID. Different versions of the same signed enclave share a sealing key, which enables data migration across upgrades without an explicit re-provisioning step. Most production deployments default to MRSIGNER policy for this reason: it is operationally tractable.

The tradeoff is lateral movement risk. All enclaves signed by the same key with the same Product ID can read each other's sealed data. In a multi-enclave architecture where all enclaves belong to a single trust domain, that is a useful property. In a deployment where different enclaves serve different tenants, or where one enclave is significantly more exposed than others, it becomes a liability. A compromise of any one enclave in that signing group is a potential compromise of every sealed secret in the group. This is not a theoretical risk; it is the kind of thing that gets discovered during a post-incident review.

The directional constraint SVN provides

Regardless of which policy governs identity binding, the Security Version Number introduces a directional constraint: a key derived for a given SVN cannot be requested by an enclave at a lower SVN. This prevents a deliberate downgrade, where an attacker might replace a patched enclave with a vulnerable predecessor to access sealed data. The constraint is asymmetric by design. Newer versions can access older sealed data; old versions cannot reach forward.

Platform binding and the cross-machine migration problem

The sealing key is unique to the CPU package on which it is derived. This is not a caveat buried in fine print; it is the mechanism. The Root Sealing Key in the fuse array of one processor has no relationship to the Root Sealing Key in any other processor. Sealed data is, by construction, unrecoverable on a different machine.

For a single-tenant workload on dedicated hardware with a controlled lifecycle, that constraint is manageable. For anything else, it requires deliberate planning. Hardware failure means sealed data is gone unless the sealed secrets were backed up through some other mechanism before the failure. A host replacement or data center migration presents the same problem. Load-balanced environments where enclave workloads may be scheduled across different physical processors cannot rely on local sealing at all without coordination logic layered on top.

The Intel SGX Developer Guide addresses this directly: the prescribed migration path is remote attestation between enclaves. The source enclave decrypts the sealed data, establishes a mutually attested secure channel with a destination enclave on the target platform, and transmits the plaintext over that channel. The destination enclave re-seals locally. This is the intended architecture for any deployment that requires portability, not a workaround.

The hardware-rooted binding that makes sealing trustworthy is precisely what makes it immobile. You cannot have both properties simultaneously. That raises an important question for any architect evaluating TDX: its lack of a native sealing primitive, which reads as a deficiency at first glance, sidesteps this exact constraint by never creating the local binding in the first place. It is worth turning over before deciding which model fits a given deployment.

Rollback and cloning attacks on SGX sealed state

AES-GCM protects sealed data against tampering and unauthorized decryption. It does not protect against replay. A sealed blob is a valid ciphertext; it will authenticate correctly regardless of when it was created. A malicious host OS that replaces the current sealed file with an older authenticated version has not broken the cryptography. It has simply presented valid old data, and the enclave has no basis for objecting.

The processor holds no persistent monotonic counter across reboots. There is no hardware-native freshness guarantee.

The ROTE scheme, presented at USENIX Security 2017, addresses this by coordinating enclaves across multiple platforms to maintain distributed monotonic counters. The insight is that a single platform cannot be trusted to maintain its own counter, but a quorum of independent platforms with independent hardware roots is substantially harder to subvert simultaneously. ROTE combines sealing with a freshness proof derived from that distributed state. It requires a more complex deployment topology, but it is the most principled published solution to rollback.

Cloning is a separate and orthogonal threat. Sealing keys depend on enclave identity, not on enclave instance identity. If a secret is provisioned to an enclave and then sealed on a given host, every other instance of that exact binary on the same host can derive the same sealing key and read the sealed data. Correct attestation of one instance does not distinguish it from its clones.

A 2025 study examining 72 SGX-based system proposals found roughly 20% were insecure against cloning attacks. The study also found that some of these proposals had correctly addressed rollback through monotonic counters, which is the most important finding: solving one of these problems does not solve the other. They are distinct threat surfaces that require distinct mitigations. But what if a team has implemented ROTE-style rollback protection and considers the problem solved? Developers who treat rollback resistance as a complete solution to sealed-state security are leaving a significant attack surface unaddressed.

How TDX encrypts memory without a sealing primitive

TDX operates at an entirely different granularity. Where SGX protects a process-level enclave, TDX protects an entire virtual machine running inside a Trust Domain. The encryption mechanism is Multi-Key Total Memory Encryption, MKTME, extended with TDX-specific controls.

MKTME encrypts and decrypts data transparently at the memory controller using AES-128 XTS at cache-line granularity. Software inside the TD sees plaintext; everything written to DRAM is encrypted under a key the software never touches. Keys are associated with Host Key Identifiers, HKIDs, which are embedded in physical addresses. The TDX Module, running in the Secure-Arbitration Mode (SEAM) introduced with 4th Generation Intel Xeon Scalable processors, binds a specific HKID and key to each TD at creation. The cryptographic keys live inside MKTME's internal memory, inaccessible to software at any privilege level, including the hypervisor.

In ordinary MKTME deployments, the hypervisor controls key assignment. TDX's threat model explicitly places the hypervisor outside the trusted computing base, so leaving key management in hypervisor hands would be internally inconsistent. The TDX Module removes the hypervisor from that path entirely.

What MKTME provides is protection against cold boot attacks, physical DRAM inspection, and a compromised or malicious host OS reading TD memory. What it does not provide is an identity-bound key derivation primitive. There is no EGETKEY equivalent in TDX. A TD cannot derive a key that is cryptographically bound to its own identity on demand. Any long-lived secret, a disk encryption key, a credential, a signing key, must arrive from outside the TD through a channel that verifies what the TD is before releasing anything.

One might argue this looks like a deficiency. It is not a design oversight. It is a consequence of the VM-level architecture, and the tradeoff is legible once the boundary is understood.

TDX measurement registers and how they anchor attestation

SGX collapses enclave identity into a single hash, MRENCLAVE. TDX cannot do this, because there is no single moment at which a TD's full software stack is committed. A TD boots; it loads firmware, then a kernel, then an initrd, accumulating state across a sequence of steps. The measurement architecture reflects this.

MRTD is the build-time measurement register. It records the initial configuration and firmware image of the TD during construction, playing the role MRENCLAVE plays in SGX: a hash over the code that will run.

RTMR registers are extended sequentially as the boot progresses, recording measurements of the kernel image, firmware configuration, command-line options, initrd, and ACPI tables. SGX has no analog to the RTMRs because SGX enclaves do not boot an operating system. The RTMRs are TDX's answer to a question SGX never had to ask: how do you capture the state of an entire boot chain?

Critically, these measurements are not used to derive an encryption key locally. They are recorded in a signed quote, a structured evidence report that a remote relying party can inspect. A key server receives the quote, verifies the signature chain back to Intel's attestation infrastructure, checks each measurement register against expected values, and, if everything matches, releases the requested secret. If any measurement deviates, the secret is withheld.

The binding model differs from SGX in a way that matters architecturally. SGX binds secrets to hardware key derivation: the key exists because the hardware computed it, and no external party needs to be available for the enclave to unseal its data. TDX binds secrets to remote policy evaluation: the key exists because an external party decided to release it after verifying the quote. More flexible, more portable, but dependent on the continued availability and correct operation of the key server. In practice, that dependency surfaces at the worst possible moments, typically during a maintenance window when the key server's certificate cache has quietly expired.

TDVF's role in the trusted boot chain and secret delivery

Before a TD guest OS can run, firmware must initialize the virtual platform. That firmware layer is the Trust Domain Virtual Firmware, TDVF, and its security posture matters because it is the first software component that executes inside the TD's trust boundary.

TDVF treats the hypervisor as a threat. This is not a rhetorical position; it is an implementation requirement. TDVF validates all input received from the hypervisor before acting on it, and it extends the firmware configuration into the TD's RTMR registers as it runs. The Intel TDX Virtual Firmware Design Guide, Document 344991-004US (2023), is the primary specification. The open-source implementation carrying TDVF support is OVMF.

The secret delivery sequence runs roughly as follows. TDVF executes and measures the firmware configuration into RTMR registers. It then hashes the kernel image, initrd, and startup script, extending those measurements into the appropriate RTMRs. At that point the TD has a complete, signed measurement chain from firmware through the userspace entry point. TDVF contacts a remote key server and presents a TDX quote containing those measurements. The key server verifies the quote, confirms every measurement matches the expected values for the authorized software stack, and releases the secret over a secure channel established after attestation.

A concrete use case: mounting an encrypted root filesystem. The encryption key is held by the key server and released only after the measured boot state is verified. If the initrd has been tampered with, or an unauthorized kernel has been loaded, the measurement will not match, the quote will fail verification, and the disk will not mount. The confidentiality of the data depends on the integrity of the measurement chain, not on the physical security of the host.

The operational implication for platform teams is precise: every component in the boot chain that is measured must be pinned, and its expected measurement must be registered with the key server before deployment. A kernel update, an initrd change, or a modification to ACPI tables will alter the measurements and cause attestation to fail until the key server policy is updated. Teams that treat this as a background detail rather than a first-class operational concern will encounter production incidents. The mechanism is working exactly as designed; the problem is that no one told the on-call engineer what that means at two in the morning.

The attestation infrastructure both platforms depend on

Both SGX and TDX ultimately depend on the same attestation infrastructure, and understanding that dependency is necessary for anyone reasoning about the full trust chain.

The root of trust for TDX quotes is Intel's TDX Provisioning Certification Enclave, which is itself an SGX enclave. This architectural detail is significant: TDX's attestation chain runs through SGX's security guarantees at its base. The PCE signs evidence reports, provisions cryptographic keys, and certifies platform TCB status.

Intel's Provisioning Certification Service, the PCS, was originally built for SGX attestation and has been extended to cover TDX. It provides PCK certificates, revocation lists, and TCB information for both platforms. The verification mechanism in data center deployments is ECDSA-based quote verification.

The Data Center Attestation Primitives, DCAP, allow organizations to run a local Provisioning Certificate Caching Service, a PCCS, that caches certificates from Intel's service. For air-gapped deployments or latency-sensitive workloads, this removes the need to call Intel's service on every verification. It does not remove the underlying trust dependency: the cached certificates originated from Intel, and their validity depends on Intel's PKI.

Tenants must trust Intel's PCS as the ultimate source of PCK certificates and TCB status. If Intel's service is unavailable during a period when DCAP caches have expired, attestation fails and secrets cannot be provisioned. If a PCK certificate is revoked unexpectedly, the same outcome follows. DCAP caching addresses availability risk at the margins; it does not address the fundamental question of whether an organization is comfortable placing Intel's PKI in its trust boundary. That question deserves an explicit answer during architecture review, not during a production outage.

For SGX, this infrastructure backs the remote attestation channel that is also the prescribed mechanism for cross-platform sealed-data migration. For TDX, it is the only provisioning path that exists. Whatever secrets TDX workloads need, and whatever migration SGX workloads require, both ultimately depend on a certificate chain that traces back to the same Intel provisioning service. Architects who treat that as an implementation detail rather than a design constraint tend to be surprised by it, and the surprise is rarely cheap.