Trusted Execution Environments (TEEs): A primer

Trusted Execution Environments (TEEs, sometimes referred to as “enclaves”) are processing environments that enable secure execution of code by isolating themselves from the host system’s operating system, kernel, and hypervisor. This isolation is often achieved through hardware separation, making it difficult (but not impossible) for external systems to tamper with or inspect enclave processes. This post serves as a broad framework for how to think about and use this important primitive in the context of blockchains.

TEEs have been around since the 1990s, used for things like digital rights management, content protection and secure payments, but have found recent application in the context of processing private state in blockchain systems. Their popularity is due to specific (and conditional) guarantees around private state they can provide protocol designers, which I’ll discuss more below.

TEEs and blockchains 

A TEE can be one of the most efficient tools to bootstrap a network that is processing private state. TEEs enable node operators to participate in a network without knowledge of the private data that is being processed on their server. Potential applications include: dark pools, private AI agent deployment, MEV-resistant block building, and onchain processing of sensitive healthcare and financial data. But because TEEs can be compromised, builders need to have a strategy in place when such exploits affect their protocols. 

As TEEs proliferate in decentralized systems, this technology will likely be used in many different kinds of protocols — each with different risk profiles and trust assumptions. It is important to understand what TEEs can and cannot do, especially when projects aim to be decentralized and trustless. 

TEEs are distinct from the host OS and applications. Only trusted code and data executes inside the TEE. Source 

In addition to isolation, these enclaves are designed with several goals in mind:

• Confidentiality: Code and data running inside the TEE are encrypted and inaccessible to the operating system, hypervisor, or other software outside the TEE.
• Recoverability (optional): The TEE can recover from a non-compliant or potentially compromised state. For example, if the enclave’s launch authentication fails, it may be possible to update that component and retry the launch.
• Attestability (optional): The TEE can provide evidence or measurements of its origin and current state through attestation. A third party could use this feature to verify that the result is coming from a genuine TEE running trusted code, not a server pretending to run an enclave.

TEEs are the canonical hardware solution for handling private data, unlike purely cryptographic methods like fully homomorphic encryption (FHE) and secure multiparty computation (MPC). FHE and MPC are often not feasible due to their complexity and performance overhead. Proving systems can add large overhead for simple execution, and existing circuits can make new features hard to add or modify. In contrast, TEEs tend to be more efficient and more expressive, capable of running existing smart contract applications out of the box, without bespoke domain-specific languages (DSLs) or proof systems. 

The design of a TEE is vendor-specific, and therefore inherently relies on trust with the hardware vendor. Different vendors offer a variety of features — including attestation, secure bootloading, and different forms of hardware isolation. Some examples include Intel’s Software Guard Extensions (SGX), Trust Domain Extensions (TDX), AMD’s Secure Encrypted Virtualization (SEV), and ARM’s Confidential Compute Architecture (CCA). GPU enclaves are also arriving to the market — for example, NVIDIA is offering enclaves on their Hopper and Blackwell architectures. 

Code and data lifecycles

Most TEE designs follow general principles around the flow of data and code in the enclave.

1. Initialization: There are several parts to setting up TEE initialization correctly, some of which have to happen at system boot. For example, the BIOS (Basic Input/Output System), or its modern replacement UEFI (Unified Extensible Firmware Interface), is the firmware that initializes hardware and starts the boot process. It sets up the system memory, including the area allocated to the TEE, and verifies the integrity of the boot process. The Memory Encryption Engine (MEE) or similar hardware encrypts RAM regions reserved for the TEE. The bootloader can also be used to launch the TEE runtime, loading the TEE kernel and trusted applications into the TEE memory.
2. Loading data and code: TEE-related code and data are generally stored encrypted on the hard drive. This data is loaded into enclave memory and decrypted within the TEE, ensuring it is not exposed to the host OS or hypervisor.
3. Entering the enclave: When an application needs to perform a sensitive operation, that operation is executed within the TEE. Often, execution flow can enter an enclave by special CPU instructions, similar to the mechanism for switching from user mode to kernel mode. Inside the TEE, sensitive code executes securely with access to isolated memory and data. 
4. Host access: The TEE enforces memory access control, ensuring that applications within the TEE can only access their own data and assets. The TEE can also protect memory access patterns to prevent information leakage from side channels. Hardware blocks any attempt to access the TEE memory from the host OS.
5. I/O operations: Peripheral devices or accelerators are outside the trust boundaries of TEEs. When data needs to be transferred to or from a peripheral device, the data is placed in shared memory, which is outside the TEE’s protected space. Hypervisors or peripheral devices can move data in and out of the shared memory. Any I/O data transferred into the TEE from untrusted components must be validated by the user. 
6. Network communication: The TEE can establish a Transport Layer Security (TLS) session in order to communicate securely with the outside world. The TEE can generate a key pair inside the TEE and establish a TLS session with the remote party, ensuring that data transmitted over the network is encrypted and authenticated.
7. Exiting: When TEE code needs to interact with non-TEE resources (e.g., the system hard disk or network), it can call back into the untrusted environment using secure APIs or exit functions. 

Limitations and mitigations

Many users are wary of relying on TEEs due to concerns about side-channel attacks, potential bugs in TEE isolation, and risks of backdoors from hardware manufacturers. Indeed, there have been instances of successful attacks on TEEs, including Spectre, a sidechannel attack, and Meltdown, a microprocessor vulnerability. Current TEE implementations, despite offering enhanced security features, also remain vulnerable to sophisticated physical attacks. No existing TEE design can fully defend against a sophisticated attacker with physical access to the chip. 

Regardless, several strategies can limit risk when building with TEEs.

1. Design for failure. The builder should assume TEEs will be eventually compromised. Therefore, TEEs should not be used to protect system integrity without some form of backup. In other words, builders should ensure that a TEE exploit will prove to be a nuisance, not an existential risk.
2. Build for privacy, not for integrity. TEEs should not be used as the only tool to protect the integrity of a blockchain protocol. For example, if a TEE is solely responsible for verifying on-chain transactions, the attacker could manipulate or falsify asset creation. This is why TEEs should never be relied on solely for integrity-critical tasks. On the other hand, if TEEs are used for privacy, the compromise may not be existential. Suppose a TEE is used to keep a user’s transaction history or balances private. A compromise might leak sensitive metadata, but the attacker wouldn’t be able to alter the actual transaction data onchain. If a TEE is used to preserve the privacy of an orderbook, an attacker might be able to see the current state of bid and ask prices, but they can’t execute these trades, match bids with asks, or change the state of the orderbook generally. They would also only get a temporary look, which would not affect future visibility of the order book.
3. Use Oblivious RAM (ORAM) whenever the enclave accesses host memory. TEEs alone can be insufficient to prevent information leakage. Even if the code and data within a TEE are encrypted, an attacker can still observe memory access patterns to the host RAM. ORAM obscures memory access patterns, ensuring that they reveal no information about the data being processed. While ORAM adds performance overhead, it’s still usually necessary to maintain privacy when using TEEs that access host memory.
4. Use forward secrecy and key rotation. Key rotation involves regularly replacing encryption keys with new ones and securely retiring old keys. This limits the damage from key exposure to the data protected by the compromised key; past communication or data encrypted with earlier keys cannot be decrypted. Forward secrecy is achieved by frequently generating ephemeral session keys that are not stored long term. For example, in a private messaging platform that relies on a TEE for message privacy, key rotation would limit the scope of a breach to recent conversations rather than compromising the entire history of communications. Without consistent key rotation, the system risks extensive damage if TEEs are compromised (and, remember, it’s safest to assume they will be compromised).

***

TEEs can be a compelling option to process private state. Designs are vendor specific but generally involve the loading of code and data segments into a secure region, processing that data, and attesting to its authenticity. Using Oblivious RAM (ORAM) can help obscure memory access patterns, and implementing forward secrecy can limit the impact of key compromise. As long as these risks are mitigated, TEEs can be a great asset in a cyberpunk’s toolkit for building valuable blockchain protocols.

***

Thanks to Dan Boneh and Joe Bonneau for background context and sourcing prior work. More excellent related reading is available at fleek.xyz and Bedlam Research.

***

Aaditya Shidham is a partner on the a16z crypto investment team. He focuses on infrastructure and application layer investments across crypto. Previously, he ran a product team at Protocol Labs. He was also a product manager at Coinbase, where he built the MPC retail wallet product.

***

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.