Confidential Computing

Confidential Computing¶

Confidential computing describes a set of technologies that protect data while it is in use The Confidential Computing Consortium, 2022. This is distinct from protecting data at rest, written to a storage device, or in transit, while being sent over a network. We could consider both of those as solved problems, with public/private key encryption, secure protocols and modern filesystems. Confidential computing is achieved by creating a hardware-based, attestable TEE. Attestation proves that a TEE is correctly configured and has not been tampered with. Data in use, and code being executed in a TEE is encrypted and may not be read or modified by other processes on the same computer.

Trusted Execution Environments¶

A TEE is a reserved portion of hardware (CPU, memory and possibly GPU) that is cryptographically segregated from the rest of the system (the host, and any other TEEs). The contents of a TEE are unable to be read, or modified by any processes outside of the TEE, including those running on the same host. TEEs are the enabling technology for confidential computing The Confidential Computing Consortium, 2022. They operate by selectively encrypting sections of memory belonging to TEEs with enclave-unique keys, which ensure encrypted memory can only be read as plain text by the correct TEE. Implementations vary as to how this is achieved but generally involve some kind of memory address virtualisation or remapping in addition to encryption. A TEE can prove its state (and hence that it has been configured correctly) though an attestation process, so its users can make an informed decision whether to trust it or not.

Both memory encryption and gathering evidence for attestation are performed by a trusted secure processor. This is a section of the CPU dedicated to confidential computing functions and enforcing the security of TEEs. It provides an API for managing the TEE platform and enclaves for example, reporting firmware versions, creating an enclave, generating attestation evidence. However, it cannot be arbitrarily controlled by the host to bypass enclave isolation for instance, decrypting TEE memory outside of the enclave or returning enclave encryption keys. The secure processor therefore plays a critical role in the operation of a TEE.

TEE security¶

TEEs provide very strong, cryptographic isolation between the enclave and the host. Memory encryption and address remapping ensure TEE processes are confidential and their memory cannot be read in plain text outside of the enclave. This confidentiality includes privileged users on the host OS or hypervisor.

A TEE implementation may also protect against some physical, hardware-based attacks such as reading memory directly (bypassing the CPU), or malicious code running early in the boot process. Furthermore, as the lifecycle of a TEE and the attestation process do not depend on trust in the host, a TEE remains secure even in the case of the host OS, hypervisor, software, drivers or firmware being compromised.

The TCB of a TEE can vary based on the design of the TEE. However, it will always exclude the host OS and any hypervisor as the TEE is cryptographically segregated from these and they play no role in attestation The host CPU, and its firmware and microcode, are critical to the security of a TEE, and so are in the TCB. They form the hardware root of trust. The CPU and CPU manufacturer are therefore the root of the chain of trust for the entire TEE and ultimately you must trust these organisation and their products. An overview of the TCB and hardware root of trust are shown in Figure 1.

TEEs don’t address vulnerabilities of code or processes inside the TEE. Malicious software (including a guest OS) inside an enclave may still have access to secrets and be able to exploit these or expose them outside the TEE.

Similarly, TEEs do not protect against users able to interact software inside a TEE, such as an OS or API. Users may be able to use their privileges, or exploit a vulnerable software inside the TEE, to access or leak sensitive data. TEEs do not, therefore, rule out the need for security best practices regarding user access and the application running inside the enclave.

Advanced side-channel, physical-access attacks have been use to expose TEE secrets. Proven attacks include tee.fail Chuang et al., 2026 and wiretap.fail Seto et al., 2025. Another class of attacks, which modify communications between CPU and memory on the memory bus, have also been demonstrated BadRAM De Meulemeester et al., 2025, Battering RAM De Meulemeester et al., 2026. One attack of this kind, DDRop De Meulemeester et al., 2026 has been shown to be able to corrupt memory in an Intel TDX CVM, enabling a debug mode where CVM memory can be obtained in plaintext by the hypervisor.

Attestation¶

Attestation is the process by which a TEE proves that it is secure. This is how trust is established when interacting with a TEE. Attestation verifies that,

• The TEE has been configured correctly

• The TEE is running on authentic hardware

In some cases, it may also verify that some software component of the TEE is in a known state, i.e. it has not been modified or tampered with.

Attestation Evidence¶

In order to attest the legitimacy of a TEE, evidence about that TEEs state must be assessed. The evidence consists of a number of claims made by the TEE. Each claim consists of a name and value. The claims will vary, depending on a TEEs configuration and hardware, and may include,

• CPU manufacturer, model

• Firmware and microcode versions

• TEE configuration data (such as types of memory encryption and address remapping)

• Hashes of software in a TEE

All claims are collected as an evidence object, such as JWT Jones et al., 2015 or EAT Lundblade et al., 2025.

It is important that evidence is correct so a TEE can be accurately assessed. The evidence is collected by hardware-based routines^[1] in the secure processor making it unfeasible for the host or hypervisor to tamper with the evidence. The evidence object is signed by a private key belonging to the secure processor. Unique, unpredictable, random private keys for each CPU are generated at the time of manufacture. They are written to the hardware in one-time PROM, and so are immutable. This signature can be verified by the hardware vendor, which keeps a set of corresponding public keys to use in identity verification challenges. It is therefore not possible to mimic a legitimate system through virtualisation. If the signature is verified, and the hardware vendor is trusted, the claims are known to be correct and produced by the CPU.

Remote Attestation¶

It is not feasible for most organisations to review attestation evidence themselves, due to the complex and technical nature of the evidence The Confidential Computing Consortium, 2023. Therefore, it is expected that most TEE users will rely on a verifier to assess the evidence and obtain endorsements. This is defined formally in IETF’s request for comments 9934 Birkholz et al., 2023. In these cases the relying party owner must trust the verifier and verifier owner to process evidence on their behalf.

Remote attestation is a process that uses a third party (i.e. neither the TEE, nor the part requesting verification of the TEE) to assess the TEE. The RFC sets out a number of roles, which are paraphrased in RATS Roles.

The basic workflow of remote attestation, showing how data flows between roles, is shown in Figure 2.

The actual procedure of a remote attestation process may be implemented in different ways. Birkholz et al. (2023) describes two possible patterns.

In the passport model the attester requests an attestation report from the verifier, who then returns the attestation results directly back to the attester. The attester shares the report with the relying party. This means the relying party does not need to interact directly with the verifier and an attester may cache a result to reuse. The model is named from the similarity of this process with a person issued with a passport that they can present to prove their identity.

In contrast, in the background check model the attester provides evidence directly to the relying party. It is then the relying party who sends the evidence to the verifier and requests an attestation result. Unlike the passport model, here the relying party interacts with both the attester and verifier, and will possess both the attestation report and the attester's evidence.

Neither of these possibilities are enforced or recommended by Birkholz et al. (2023). Each pattern, or an alternative, may be more suitable for particular types of activity. For example, the passport model would be more suitable for a TEE providing a service to many unique users as long-lived attestation reports can be sent to many clients, without the need to an equal number of requests to the attestation service.