Intel TDX overview

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
Supporting processors Intel Core 6th-10th Gen + some other Intel Xeon 4th Gen
Level process VM
Integrity (remote attestations) :white_check_mark: :white_check_mark:
Confidentiality (memory encryption) :white_check_mark: :white_check_mark:
Allows for deployment of legacy applications :x: :white_check_mark:

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:

3 Likes

I’m a bit confused by this. Is this some key that is shared by enclaves A and B? Why wouldn’t enclave A sign with a (private) key associated with A, and enclave B verify with a public key associated with A?

A few questions:

  1. Why do we need two steps (sending to quoting enclave and then IAS)? What does IAS check “remotely” (in Intel’s datacenters) that can’t be checked locally (on the third party machine)?
  2. I still don’t quite understand why we keep signing with the key of the enclave that we’re sending to. What does this mean?

I have no idea what most of these differences mean and most of them sound like marketing. Is there an analysis somewhere of TEE/TDX/SEV/etc. with a clear adversarial threat model (as one might find in a cryptography research paper)?

I was also confused by this. From what I understand, the first enclaves requests the CPU to sign the attestation using the enclave B’s keys but it doesn’t have access to the key itself.

  1. It ensures the report can only be verified by a specific enclave
  2. It ensures that both enclaves are on the same platform: enclave A doesn’t see the keys associated with enclave B, so it asks the CPU to sign the report.

The quoting enclave is the only place where the attestation (SGX-wide) key is stored. Local attestation allows sending reports to other enclaves on the same machine, so it doesn’t leave the TEE, and for remote attestation we also need to use the attestation key to bind it to the machine

IAS checks the platform against the revocation list, verifies the firmware running on the platform, and verifies the report against the EPID keys. EPID is a protocol designed to specifically work with IAS. From what I understand, the keys hardcoded in the SGX are used to derive EPID keys, and this EPID verification allows IAS to make sure the hardware is genuine. These keys are also somewhat private (from what I understand, they are not shared, but they have something like DH between them) and only known to the SGX and Intel, so a third party can’t verify them. I tried to find information about the hardcoded keys and what keys are derived from them, but most sources don’t describe the EPID key derivation but already start from the point where there are EPID keys generated in SGX

1 Like

So the CPU has access to enclave B’s keys but enclave A doesn’t? That doesn’t make any more sense, at least to me. Why would the A computer’s CPU have access to enclave B’s keys? Is this not encryption using a public key of B (that would at least make sense)? Why sign anything sent to B with B’s key? What does that prove?

Maybe I’m not understanding what is meant by “sign”. By “sign”, I understood “generate a cryptographic signature using a private key which can be verified by anyone with the associated public key”. Is something else meant here? Are we talking about some kind of symmetric signing (maybe a MAC) which only parties with the relevant key could verify? I still don’t understand why A’s CPU would have enclave B’s key though.

As in, the quoting enclave is a globally unique single enclave that stores a globally unique (SGX-wide) attestation key? What do you mean by “bind it to the machine”?

Thanks, this is somewhat helpful (at least for me), although there are a lot of parts which I still don’t understand, or boil down to “trust Intel to be doing the right thing”. I suppose that we’re already trusting Intel to be doing the right thing, so that’s not adding an additional trust assumption, which makes me less uncomfortable than I otherwise would be about this lack of clarity (but not entirely comfortable either).

Yes.

This is local attestation, the enclaves are on the same computer, the managing CPU is the same.

Nope, it is a cryptographic signature.

There is no A and B’s CPUs, it is one SGX-enabled CPU

We are still in the context of a single SGX, so globally here means on the same platform. The same SGX (i.e., on the same machine) contains many enclaves. Some of them are created by Intel, e.g., quoting enclave and provisioning enclave. Quoting enclave is the only enclave on that machine that has access to the attestation key.

SGX is a hardware solution, and we need to prove that whatever we are outputting is produced by that specific instance of SGX that is also verified by Intel. Since we can’t just transfer SGX from one machine to another, we have to prove that the attestation comes from a legitimate SGX platform. It doesn’t matter much for local attestation because local attestation would only work if the enclaves are on the same machine, so the verifying enclave has the same hardware setup as the attesting enclave, and we only need to prove that they are indeed on the same machine

1 Like

Ah I see, I missed that part, thanks. Generally makes sense now.

1 Like