Lesson 1.2 · 14 min read
Adversaries: who a TEE defends against
A precise list of in-scope and out-of-scope attackers, so that you can read vendor claims critically.
The privileged-software adversary
The defining feature of confidential computing is that it treats privileged software on the same machine as untrusted. In a conventional server, the kernel and hypervisor are the most trusted components. In a TEE threat model they are assumed to be potentially malicious or compromised. The CPU still has to schedule the TEE and give it memory, but it encrypts and integrity-protects that memory and prevents the host from reading or silently modifying it.
| Adversary | Typically in scope? | Notes |
|---|---|---|
| Compromised or malicious host OS / hypervisor | Yes | The central case. The host can still deny service. |
| Cloud or data-centre operator with admin access | Yes | Includes insiders at the infrastructure provider, to the extent the hardware and attestation chain are trusted. |
| Other tenants on the same host | Yes | Memory isolation is hardware-enforced, but see side channels. |
| Physical attacker probing DRAM or the memory bus | Partly | Memory encryption defeats simple cold-boot and bus snooping. Sophisticated physical attacks on the CPU package are generally out of scope. |
| Software side channels (cache timing, speculative execution) | Varies by platform and version | Historically the largest source of TEE vulnerabilities. Vendors address them with microcode, TCB recovery, and guidance to developers. |
| Bugs in the code inside the TEE | No | A TEE runs your code faithfully, including its vulnerabilities. An injectable app in an enclave is still injectable. |
| Denial of service by the host | No | The host controls scheduling, memory, and I/O and can always stop the workload. |
| The hardware vendor's root of trust | No (it is trusted) | Attestation ultimately chains to keys controlled by the CPU or GPU vendor. |
I/O is the soft underbelly
Everything that crosses the boundary can be observed or tampered with by the host: network packets, disk blocks, the timing and size of requests, and calls into the host for services. Well-designed confidential workloads therefore:
- terminate TLS inside the TEE, not at a host-side proxy;
- encrypt and authenticate anything written to host-provided storage;
- validate every value received from the host (an untrusted interface); and
- consider what metadata, such as request sizes and timing, reveals.
Key takeaways
- The host OS, hypervisor, and operators are outside the trust boundary.
- TEEs do not fix bugs in your own code and cannot guarantee availability.
- Side channels and the I/O interface are where most real-world weaknesses live.