Intel TDX (Trust Domain Extensions) is a confidential computing architectural feature launched in 2023 with a new generation of Intel Xeon processors. It is similar to Intel SGX in what it provides: hardware-enabled confidential computing, in particular offering integrity and confidentiality features. Intel TDX supposedly provides better abstractions compared to Intel SGX and eliminates some bugs and inconveniences introduced by Intel SGX.
Because Intel TDX is quite similar to Intel SGX in the provided features, I’ll start with a short Intel SGX description.
Intel SGX high-level description
Intel SGX is a trusted execution environment that allows creating application enclaves running trusted (or rather verified) code protected by Intel hardware and Intel-developed-and-verified software. The flow is roughly as follows: a developer writes a program, loads it into the SGX, and SGX provides:
- Integrity: the code inside it is not modified (remote attestation)
- Confidentiality: everything that happens inside the enclave is not visible to the host environment (memory encryption)
Local and remote attestations
SGX enclaves can produce local and remote attestations. Local attestations are used to prove integrity to another enclave on the same platform, remote attestations are used to prove integrity to a third party.
Local attestation
Local attestations work roughly as follows: the attesting enclave generates a report, which includes the enclave’s measurement (a hash of its content). The SGX-enabled CPU signs the report with a key associated with the receiver enclave. The receiver enclave uses its key to verify the produced report.
The attesting enclave can also include DH data in the report to establish a secure communication channel with the receiver enclave.
Remote attestation
Remote attestation mechanism is based on the local attestation mechanism. The attesting enclave generates a local report signed under quoting enclave’s key. A quoting enclave is a special enclave developed by Intel that produces remote attestations. It verifies the local report and transforms it into a remote report (quote). The quote is signed by the attestation key associated with the SGX. The produced quote is then sent to IAS (Intel Attestation Service) to verify the correct binding between the attestation key and the platform and perform some other checks. After IAS verified the quote, it is sent to the challenger to verify the enclave’s measurement.
Applying RM terminology, IAS would be the compliance verifier and the challenger would be the logic verifier.
Application verification
The challenger can verify the integrity of the running in the enclave code by recomputing the hash of the binary of the program that is supposedly running in the enclave and comparing to the hash included in the quote. This implies that the SGX integrity mechanism relies on reproducible builds - compiling the same program with the same settings produces the same binary - which is often not the case.
For example, reproducible builds are a challenge for ZKVMs, so running ZKVMs-produced circuits in TEEs doesn’t seem like a good idea. But afaik you don’t need to go as fancy as ZKVM to find these reproducibility challenges.
That means that, in order to support integrity checks, the developer of the SGX program must ensure the challenger can reproduce the binary.
Back to Intel TDX
Intel TDX enables TEE environments at the virtual machine level as opposed to Intel SGX that operates at the process level. It assumes an untrusted hypervisor and ensures that the virtual machine (called trust domain in the TDX world) is protected from a malicious hypervisor. Intel TDX main components:
- Intel-VT - hardware-assisted virtualisation. A special instruction set (VMX) is used for virtualisation, SEAM (Secure Arbitration Mode) is a an extension of VMX to support TDX
- Intel MKTME. TME encrypts memory. MKTME - multi-key TME - supports memory encryption (AES-XTS) for multiple trust domains.
- Intel SGX is used to produce attestations
- TDX module. Given that the hypervisor is assumed to be untrusted, TDX Module acts like a trusted hypervisor that ensures that TD is protected from the outside environment.
Comparison to Intel SGX
| SGX | TDX | |
|---|---|---|
| Year of launch | 2015 | 2023 |
| Level | process | VM |
| Integrity (remote attestations) |  |
|
| Confidentiality (memory encryption) | |
|
| Allows for deployment of legacy applications |  |
|
One major downside of TDX compared to SGX is that it is pretty new and there is not enough information and supporting tools to work with TDX. While TDX seems to support legacy code deployment, it requires a TDX-compatible guest OS, and it is hard to be compatible with something when you don’t know it exists. Well, seems like some Linux distributives already support TDX [1][2], so it is not that bad.
A note on other TEEs
Intel TDX overview provides a short description of non-Intel TEEs. One thing to notice is that all of them are VM-based. The difference between the two IBM ones seems to be in that the second one uses TPM to protect the keys.
Resources: