Loose SEAL: Enabling Crash-Tolerant TDX Applications by Utilizing SGX Sealing Provider Sidecar

TEE - Trusted Execution Environment
1

image
image1536×768 128 KB

1. Introduction

In this post, we demonstrate how to restore “sealed keys” functionality in Intel TDX, a critical feature that was available in its predecessor Intel SGX but is notably absent in TDX environments.

For most applications running in Trusted Execution Environments (TEEs), migrating from Gramine-SGX to TDX is surprisingly straightforward. Nearly all dependencies that work in Gramine-SGX also work seamlessly in TDX, and even components that were challenging to implement in SGX (such as interprocess shared memory and slow system calls in Go) perform efficiently in TDX.

However, one crucial capability is conspicuously missing: sealed storage. Intel’s Trust Domain Extensions (TDX) technology, while providing robust hardware-based isolation for virtual machines and strong security guarantees for cloud workloads, lacks native sealing capabilities that are essential for maintaining state across crashes or restarts.

The Challenge

Consider a typical scenario: Your application running in a Confidential Virtual Machine (CVM) needs to persist its state to disk to recover from system crashes or benign reboots. However, since the disk falls outside the CVM’s confidentiality and integrity guarantees, you need a sealing key to derive unique keys for each CVM to securely store and verify its state. While this capability was readily available in Intel SGX, it’s notably absent in TDX—likely because reliance on sealing keys can sometimes be considered an anti-pattern and potentially open attack surfaces, particularly for replay attacks (checkout ROTE paper).

Current Approaches and Limitations

Currently, there are two main approaches to address this limitation:

  1. Use a persistent key stored in a Trusted Platform Module (TPM)
  2. Recover state from a network of replicas using Crash Fault Tolerant (CFT) protocols like Paxos or Raft, or using something similar to the rollback protection protocol as described in ROTE.

However, each approach has drawbacks. TPM-based solutions require additional hardware, while distributed protocols add complexity and overhead—especially burdensome when an application simply needs a reliable way to derive a unique key.

Our Solution: Loose SEAL

Together with Andrew Miller, we’ve developed Loose SEAL, a solution that elegantly bridges this gap. Since every processor that supports TDX also supports SGX, we leverage this co-existence by creating an SGX-based sealing provider service that runs alongside TDX workloads on the same platform.

This approach follows an established pattern in TDX—similar to how quote generation in TDX is provided by an SGX-based “quoting enclave” service communicating via local attestations. The key challenge we address is enabling secure recognition between the TDX guest and the SGX sealing key service on the same CPU while maintaining the security properties expected in confidential computing environments.

Our solution provides:

  • Secure state persistence for TDX applications
  • Crash recovery capabilities
  • Maintenance of confidential computing security guarantees
  • Platform-bound key derivation
  • Quote-based mutual verification

Through this design, we enable TDX applications to maintain state persistence and recover from failures while preserving the strong security properties that make TDX valuable for confidential computing workloads.

2. System Architecture

The key aspects of our solution include:

  • A stateless service design that maintains security without persistent state
  • Secure key derivation based on TDX measurements
  • Platform binding through PPID verification
  • Quote-based attestation for mutual verification
  • Public key encryption for secure key transfer

The service operates by:

  1. Receiving TDX quotes containing the application’s public key
  2. Verifying platform identity through PPID matching
  3. Deriving unique keys based on TDX measurements
  4. Securely transferring keys using public key encryption
  5. Providing quote-based verification of response integrity

Design:

1920×915 104 KB

This figure is from the TDX documentation and it describes how a TD instance interacts with the SGX quoting enclave to access key materials via indirectly calling EGETKEY CPU instruction. Although in this example the only purpose is for Quote Generation, the Loose SEAL uses similar architecture but for providing a general purpose key derivation process.

Key Derivation Process:

1711×3840 353 KB

There are mainly two parties here engaged in the process: the TDX App that requests to derive a unique sealing key for itself from the SGX Sealing Provider (Loose SEAL).

The process starts with the TDX App generating a new keypair <SecretKey, PubKey> which will later be used to do asymmetric encryption of the derived unique sealing key. Afterwards, the TDX App generates an attestation quote that includes its measurement (MRTD & RTMR[0-3]) and writes the PubKey in the user report data of the quote. This quote will be sent to Loose SEAL over a communication channel, currently a TCP socket but it can also be done with AF_VSOCK, Unix Domain Socket service or expose it as a rest API service.

Loose SEAL will receive the quote and verifies it to make sure it is authentic and not being modified.
Upon successful verification, it generates its own quote to make an early verification of the PPID to make sure that the received quote is coming from a TDX App running on the same platform. This way, it can early detect and reject requests coming from TDX Apps of non recognized platforms. Currently, we are only restricting it to those running on the same platform for simplicity and more controlled environment. Once both quote verification and PPID matching are done, a unique sealing key is derived for the TDX APP by extracting the unique measurements from its quote and use them as input to key derivation function. The key derivation function would use Loose SEAL’s private sealing key as a seed. This way, we can make sure that the key derivation is deterministic as well as secure considering the security guarantees around SGX sealing keys.
The derived key will be encrypted using the PubKey that was written in TDX App quote.
Finally, Loose SEAL generates its own attestation quote and writes the hash of the encrypted derived key in its user report data field. Then, it will send its attestation quote and the encrypted derived key back to the TDX App.

Now, the TDX App needs to be sure that the encrypted derived key is coming from Loose SEAL and not modified. Hence, the reason why Loose SEAL is sending its quote with the hash. The TDX App will extract the hash of the encrypted derived key from the quote’s user report data field upon a successful attestation verification of the quote. If the hash matches the hash of the received encrypted derived key, it can be decrypted and used to recover the state. Otherwise, reject it because a forging attempt is detected.

3. System Evaluation

Threat Model:

We adopt the same strict threat model of Intel’s TDX/SGX. Where only the enclave/TD is considered trusted. That is why, we rely on passing TEE attestation quotes along side the request & response to apply the verify before usage principles. More concretely, Loose SEAL verifies the TDX App quote sent with the request, and the TDX App verifies the Loose SEAL’s quote in the response. Those are required to make sure that the request/response hasn’t been tampered with as well as coming from the expected sources to prevent forging attacks.

Design:

Loose SEAL is fully stateless and does not persist any data. Its functionality is idempotent to guarantee same key derivation output for the same source. Hence, it bridges the sealing key capabilities to TDX Apps while preserving the same security guarantees.

Limitation:

The current system is built to be used on the same platform where the TDX Apps are being deployed. Hence, not scalable to remotely deployed TDX Apps yet. Furthermore, it would benefit from further security enhancements, such as key rotation, forward secrecy in the key derivation process, censorship resistance, transparency logs and much more. Loose SEAL is a proof of concept of such a sidecar functionality and can be extended as long as it preserves the stateless design and the desired security guarantees.

4. Open Challenges & Potential Incremental Work

  • Multi-Platform Support: Implement support for multiple platforms by maintaining a secure registry of valid PPIDs, enabling cross-platform deployment while maintaining security guarantees.
  • Censorship Resistance and Transparency: Explore blockchain integration for transparent key derivation verification while preventing censorship attempts. This could involve recording key derivation proofs on-chain while maintaining confidentiality.
  • Distributed Sealing Key Provider: Design a distributed architecture for the sealing key provider to eliminate single points of failure and enhance availability, potentially using threshold cryptography for key derivation.
  • Key Rotation: Implement secure key rotation mechanisms that maintain backward compatibility while allowing for periodic updates of the root sealing keys.
  • Forward Secrecy: Develop protocols for achieving forward secrecy in the key derivation process, ensuring that compromised keys cannot be used to decrypt historical data.
  • TCB Recovery: two scenarios can be identified here.
    • First scenario, if the Loose Seal TCB status changes, then we would need to rely on a network recovery rejoin method. However, Loose Seal is currently only meant to be useful for restarts where no processor changes occur.
    • Second scenario, if only the TD TCB status changes, then this shouldn’t impact the key derivation process as we are only relying on the MRTD & RTMR values in the attestation report to generate the TD unique sealing key. But, in case the MRTD also might change upon a TCB recovery, we can consider relying only on the RTMR values to make the key derivation process platform independent and more TDX application specific.

5. Summary

Loose SEAL bridges a critical gap in Intel TDX technology by providing secure sealing capabilities through an SGX-based provider service. The solution maintains the security guarantees of confidential computing while enabling crucial features like crash recovery and state persistence. By leveraging SGX’s sealing capabilities and implementing a robust attestation-based protocol, Loose SEAL offers a practical and secure solution for TDX applications requiring state persistence. The stateless design and platform-binding mechanisms ensure both security and reliability, making it suitable for a wide range of applications from database systems to financial services

Acknowledgments

A huge shoutout to @socrates1024 for his invaluable collaboration and insights throughout this project. His expertise and feedback were instrumental in shaping both the design and implementation of this work. Special thanks to Mona Vij and James Beaney from Intel for their thoughtful feedback on the article.

References & Links

3 Likes