Dhvani Patel

TEE Notes

What is a TEE?

A Trusted Execution Environment (TEE) is a hardware-isolated region of a machine where code and data are protected even from the operator of the machine. The CPU encrypts the enclave’s memory and refuses to let the host OS, hypervisor, or a root user read it. Two properties matter:

  • Confidentiality + memory integrity — memory is encrypted and tamper-detected in hardware, so a malicious cloud host cannot read or silently modify what runs inside.
  • Remote attestation — the CPU signs a quote: a hardware-rooted statement of exactly which code is running and on genuine hardware. A remote client verifies that signature against the vendor’s certificate chain before trusting the enclave with any data. The quote also carries a report_data field the enclave chooses at runtime — what the code wants to say — used here to bind the attestation to a public key.

Common implementations:

  • Intel TDX and AMD SEV-SNP — VM-level enclaves (a whole confidential VM).
  • Intel SGX — the older process-level enclave.
  • ARM CCA (Confidential Compute Architecture) — ARM’s confidential-VM design.
  • NVIDIA GPU TEEs (Hopper / Blackwell) — confidential accelerator compute, increasingly paired with a CPU TEE for confidential AI/ML workloads.

Note: For private AI inference, awesome-private-inference keeps a public registry of inference providers whose TEE setups have been verified.

How a TEE enables joint computation

The problem: N parties each hold private data and want a shared result, but no party trusts the others or the host to see their raw input.

A TEE solves this by moving the trust from “the other parties” to “a piece of hardware-attested code that everyone reviewed”:

  1. Attest. Every party independently verifies the enclave’s quote: genuine hardware, running the agreed code, bound to a key generated inside the enclave.
  2. Send private data over a bound channel. Each party encrypts its input to the enclave’s key. Because the quote committed to that key, a malicious host cannot substitute its own key and intercept the plaintext.
  3. Compute once, inside. The enclave decrypts all inputs in memory, runs the program, and produces a result. Raw inputs never leave the enclave and are wiped after the run.
  4. Return per-party results. Each party gets its own output, encrypted to its own key — so party A never sees party B’s input, and can’t read B’s output either.

The guarantee “the program won’t leak my data into someone else’s output” ultimately rests on the offline review of the agreed program — attestation proves which code ran, but a human still has to confirm that code is safe.

TEEs are one of several approaches to this problem. Compared to pure-crypto techniques (secure multi-party computation, homomorphic encryption), TEEs are far faster and easier to program — you write ordinary code — at the cost of trusting the CPU vendor’s hardware and attestation chain. MPC/FHE trust only math, but are orders of magnitude slower and much harder to author.

Setup: running a TEE VM server

The rough shape of standing up a confidential VM as a service:

  1. Get TDX-capable hardware. Either a cloud Confidential VM (GCP, Azure) or a confidential-compute provider (e.g. Phala Cloud, which fronts TDX nodes via the dstack stack). You generally cannot get TDX on a normal VM — it must be provisioned as a confidential instance.
  2. Package the workload. Ship your server as a container image built for linux/amd64 (TDX hosts are amd64). The image is the thing that gets measured, so keep it minimal and reproducible.
  3. Expose attestation. Inside the guest, request a quote — via the dstack socket (/var/run/dstack.sock) on Phala, or the guest configfs-tsm interface on a GCP Confidential VM. Serve it on an endpoint clients can fetch.
  4. Bind a channel. Generate a keypair inside the enclave and put sha256(publicKey) into the quote’s report_data, so clients can prove the channel key really lives inside the attested enclave.
  5. Discover, then pin, the measurements. On first deploy, read the real MRTD (which base image booted) and RTMR3 (which app is running on top) values out of a trusted quote. Treat them like a TLS cert pin: clients enforce them and refuse to connect if the running code changes.

Costs

Confidential VMs cost a modest premium over equivalent standard VMs, plus the usual compute/storage/egress.

Item Ballpark Notes
Confidential VM premium ~ +5–15% over the same non-confidential instance GCP/Azure add a surcharge for TDX/SEV-SNP; some sizes similar to on-demand.
Small TDX instance ~ a few cents to ~$0.10+ / vCPU-hour Scales with vCPU/RAM like any VM; add disk + egress.
Managed confidential provider Provider-set rate (often per-CPU-second or per-instance-hour) e.g. Phala Cloud instance types like tdx.small; bundles the attestation plumbing.
Attestation collateral Usually free Fetching Intel/vendor collateral (PCCS) is not metered compute.

The dominant cost is just VM uptime: a long-lived attested VM that serves many computations amortizes far better than spinning up an enclave per job. Because the compute is a shared, open resource, real deployments often meter access (e.g. a pay-per-session or pay-per-CPU-second charge) both to fund the VM and to prevent a free-for-all.

Performance overhead

Compute inside a TEE is fast; the expensive part is data crossing the trust boundary. Rough, workload-dependent ranges:

  • VM-level TEEs (Intel TDX / AMD SEV-SNP): ~0–10% for CPU bound work. Memory encryption is inline in the memory controller (cheap); the real cost is VM entry/exit and bouncing I/O through shared buffers, so syscall-/network-heavy workloads pay the most.
  • Process-level (Intel SGX): near-native if the working set fits, but enclave transitions cost thousands of cycles and exceeding the Enclave Page Cache triggers encrypted paging — a 2×–100×+ cliff.
  • GPU TEEs (NVIDIA): GPU compute stays near-native; overhead is the encrypted CPU↔GPU transfers, so large compute / small transfers is cheap and the reverse isn’t.
  • Startup + attestation is a one-time cost (hundreds of ms to seconds) — negligible for a long-lived VM that attests once and serves many sessions, but significant for short-lived jobs.

The VM running inside a TEE has its own overhead (eg wasm sandbox adds ~2x).

Tradeoffs

What you gain

  • Run ordinary code over combined private data with strong confidentiality — no rewriting your algorithm as a circuit (as MPC/FHE require).
  • Near-native performance; latency measured in the program’s own runtime, not a crypto blowup.
  • A single attested VM can serve many independent computations (when the program is submitted at runtime and pinned by hash).

What you give up / must watch

  • Hardware trust. You are trusting the CPU vendor’s implementation and attestation service — a closed root of trust and a centralization concern. A hardware flaw can undermine the guarantee. (Efforts like the Flashbots-initiated Trustless TEE / Project Sovereign aim to replace this with open, auditable secure-chip designs.)
  • Side-channel & microarchitectural attacks. TEEs have repeatedly been weakened by attacks like Spectre and Meltdown, and by memory-access-pattern leakage (what an enclave touches in host RAM can leak information even when the contents are encrypted). And no current TEE fully defends against a sophisticated attacker with physical access to the chip. This is an active research area.
    • Access-pattern leakage in particular is mitigated with ORAM (Oblivious RAM), which randomizes physical memory accesses so they’re independent of the secret data being touched — at a real cost (often 10–100× access amplification).
  • Attestation required. If clients skip verification, pin the wrong measurements, or fail to bind the channel key, there are no guarantees.
  • Review still required. Attestation proves which code runs, not that the code is safe. Someone must audit the agreed program — easier for a small, reproducible module than a giant bundle.
  • TCB size & patching. A whole-VM TEE measures a large software stack; keeping the trusted computing base small and TCB status current (Intel TCB recovery) is ongoing work.
  • Operational limits. Confidential VMs constrain instance types, live migration, and some device/GPU features; availability varies by region and provider.
  • Don’t rely on the TEE alone for integrity. The hardware tamper-detects memory in the nominal case, but don’t treat the TEE as your only assurance the result is correct: a compromised enclave (side channel, bug, physical attack) can still produce a valid-looking quote while lying.
    • One solution is to produce zk proofs inside the enclave so the result is independently verifiable.
  • No availability. A TEE protects secrecy and memory integrity but guarantees neither liveness nor completion — the host can always pull the plug.
    • One solution is to use a decentralized operator set backed by crypto-economics.
    • For example, EigenCompute runs a workload across a decentralized operator set in TEEs, has a second verifier enclave independently re-check the result, and backs it with restaked collateral so an operator that returns a wrong result gets slashed. It also anchors which code runs: each deployment’s Docker digest is recorded on-chain and secret/key access is bound to that attested image, so an operator can’t silently swap the running code — a change breaks attestation, shows up on-chain, and loses access to the keys.