How TEE attestation works (Intel TDX, plain English)

The problem attestation solves#

You want to send a prompt to a server and be sure that:

• —it's running the exact code you think it is,
• —the operator can't read your prompt,
• —nobody swapped the model or added a logger.

You can't verify any of that by asking nicely. A Trusted Execution Environment (TEE) plus remote attestation lets the hardware itself vouch for what's running — with a signature chained to the chip manufacturer.

What a TEE is#

A TEE is an isolated region of a machine where code and data are protected from everything outside it, including the host OS, the hypervisor, and the cloud operator. Intel TDX (Trust Domain Extensions) creates an encrypted, isolated VM — a "trust domain" — whose memory the host cannot read.

Confidentiality alone isn't enough, though. You also need to *prove* to a remote client which code is inside. That's attestation.

Measurements: MRTD and RTMRs#

When a TDX trust domain boots, the CPU measures it — it hashes the initial memory image into a register called the MRTD (Measurement of the Trust Domain). Additional runtime measurements extend RTMRs (Runtime Measurement Registers).

The MRTD is, in effect, a fingerprint of the exact software that booted. Change one byte of the image and the MRTD changes. Pin a known-good MRTD and you can detect any tampering.

The quote#

The TEE asks the CPU to produce a quote: a signed blob containing the measurements (MRTD, RTMRs) and a field you supply called report data. The signature chains up through Intel's provisioning certificate to Intel's root — so a verifier can confirm the quote came from genuine Intel silicon in TDX mode, not an emulator.

Verifying a quote (the DCAP flow) checks:

• —the certificate chain back to Intel's root,
• —the TCB (the platform's patch level isn't revoked),
• —the signature over the measurements and report data.

Binding the quote to *this* session#

A quote that proves "some genuine enclave exists" is useless if an attacker can replay it. So we bind it to the session using report data.

The enclave generates an ephemeral key pair. It puts sha256(enclavePublicKey || nonce) into the report data of the quote. Now the quote says: *"the enclave holding this specific public key, answering this specific challenge, is the genuine measured code."*

The client:

• —sends a fresh random nonce,
• —gets back the quote,
• —verifies the DCAP signature and checks the measurements,
• —recomputes sha256(enclavePublicKey || nonce) and confirms it matches the report data,
• —only then seals its prompt to that public key.

If any check fails, nothing is ever sent. That's what makes "private" honest instead of a promise.

Why the public key matters#

Because the prompt is encrypted to a key that only exists inside the measured enclave, the operator running the box never sees plaintext. They route ciphertext. The decryption happens inside the trust domain, runs the model, and re-encrypts the answer to the client.

What you should verify yourself#

Don't take a product's word for it. With the room's quote you can:

• —confirm it's DCAP-valid (genuine Intel TDX),
• —check the MRTD matches the published, audited image,
• —confirm the report data binds the key you're sealing to.

Darkroom publishes its room's MRTD so you can do exactly this. Walk through it in verify a Darkroom attestation yourself.