Secure Enclaves and Confidential Computing: Protecting Data in Use

Encryption protects data at rest and data in transit. Data in use — loaded into memory so a processor can work on it — has traditionally been unprotected, readable by the operating system, the hypervisor, and anyone with sufficient privilege on the machine. Confidential computing is the attempt to close that third state.

The threat model

The question is who you are protecting against, and the answer here is unusual: the infrastructure operator.

In a cloud environment your workload runs on someone else's hardware, under their hypervisor, administered by their staff. Conventional controls protect you from other tenants and from external attackers; they do not protect you from a compromised hypervisor or a malicious administrator, because those sit beneath your operating system.

Secure enclaves shrink the trusted computing base to the processor itself. Memory belonging to the enclave is encrypted by the hardware, with keys the processor holds and the operating system never sees. Code outside the enclave — including the kernel and the hypervisor — reads ciphertext.

The two approaches

Process-level enclaves protect a portion of one application. The developer partitions the code, placing sensitive logic and data inside the enclave and leaving the rest outside. Protection is tight and the development effort is substantial, since the boundary must be designed and every crossing of it scrutinized.

Confidential virtual machines protect an entire guest, with memory encrypted and the hypervisor excluded. Nothing in the application changes — you lift an existing workload into a confidential VM — at the cost of a larger trusted boundary, because the whole guest operating system is now inside it. This is the model most cloud providers offer, and it is why adoption has grown.

Confidential containers apply the same idea at container granularity.

Remote attestation

The feature that makes any of this trustworthy, and the one most worth understanding.

Memory encryption alone proves nothing to a remote party — you cannot tell whether you are talking to a genuine enclave running the code you expect, or to a convincing imitation. Attestation solves it: the processor produces a hardware-signed statement describing the enclave's measurement, essentially a hash of the code and configuration loaded into it.

A remote party verifies that signature against the manufacturer's certificate chain and compares the measurement to what it expects. Only if both check out does it release secrets — keys, credentials, data — into the enclave.

That is the useful pattern: attest, then provision secrets. It means a data owner can send data to infrastructure they do not control, with cryptographic evidence that only the intended code can read it. The chain of trust runs back to the silicon vendor, which is the same structural reliance on a signature root as under code signing — and carries the same caveat that compromise of the root undermines everything beneath it.

Real uses

Multi-party computation where organizations want a joint result without sharing inputs — several banks detecting fraud patterns across their combined data without exposing customer records to each other. Processing regulated data in a jurisdiction or on infrastructure the data owner does not trust. Key management where keys must be usable without ever being exposed to the host. And protecting model weights or inference data in machine learning workloads.

It is worth distinguishing this from homomorphic encryption, which computes on encrypted data without ever decrypting it. Homomorphic encryption needs no hardware trust and is orders of magnitude slower; enclaves run at close to native speed and require trusting the processor vendor. Different trade-offs for overlapping problems.

The limits, stated honestly

Side channels. Enclave technologies have repeatedly been undermined by speculative execution and cache timing attacks that leak enclave contents without breaking the encryption. Mitigations exist, several cost performance, and the research continues — the same category of problem described under VM escape and hypervisor security.

You trust the vendor. The attestation root, the microcode and the hardware implementation all belong to the processor manufacturer. That is a smaller trusted base than an entire cloud stack, and it is not zero.

Bugs inside the enclave still count. An enclave containing a memory corruption vulnerability can be exploited like any other code, and the enclave protects the attacker's activity from the host just as effectively as it protects yours.

Availability is not protected. The host can refuse to run your enclave, and confidentiality against the operator does not give you independence from them.

TPM, HSM and TEE

Frequently confused. A TPM is a discrete chip storing keys and platform measurements, used for boot integrity and disk encryption key sealing — it protects keys, not general computation. An HSM is a dedicated device performing cryptographic operations with keys that never leave it. A TEE or secure enclave runs arbitrary application code with memory protected from the rest of the system. Overlapping ideas, different scopes.

Exam angles

Know confidential computing as protecting data in use, completing the set with at rest and in transit, and secure enclaves as hardware-encrypted memory regions excluding the operating system and hypervisor. Identify remote attestation as the mechanism proving which code is running before secrets are released. Distinguish process-level enclaves from confidential VMs, and TPM, HSM and TEE by scope. Know side-channel attacks and trust in the hardware vendor as the acknowledged limitations.