Web Proof Techniques: TEE Mode

The ‘Web Proof Techniques’ series covers the technical implementations of various Web Proof protocols. Past articles have explored MPC Mode and Origo Mode. This article focuses on TEEs.

TEEs Web Proofs — TEE mode Aside: Hardware Support for TEEs The role of TEE’s in Cryptography TEE Research & Development at Pluto Summary

TEEs

A Trusted Execution Environment (TEE) is a secure area within a processor that isolates and protects sensitive computations from external interference or malicious software. End-to-end encryption is comprised of three states, and TEEs provide the last of the three: encryption-in-use.

Encryption-at-rest protects your data while it is being stored.

Encryption-in-transit protects your data when it is moving between two points.

Encryption-in-use protects your data while it is being processed.

The key features of TEEs are isolation, integrity, confidentiality, and performance.

Isolation - a secure, separate environment within the CPU, protecting sensitive tasks from interference or compromise by the host system or other processes. Isolation is enforced through hardware mechanisms that create a dedicated memory space for the TEE.

Integrity - the code and data within a TEE remain unaltered and trustworthy throughout execution. Integrity is maintained through cryptographic mechanisms like hashes and signatures, which verify authenticity of code and data.

Confidentiality - a product of isolation and integrity; sensitive data inside a TEE remains protected from unauthorized access. Cryptographic keys are securely stored within the TEE, preventing exposure to external systems and ensuring only the TEE can access them.

Performance - as they do not require complex cryptographic overhead, TEEs can process secure computations faster and with lower computational costs (relative to other cryptographic tools accomplishing similar goals).

Note that TEEs are built on two critical trust assumptions. First, users must trust that hardware manufacturers have implemented the technology with integrity — in other words, users must trust that there are no hidden backdoors in the system. Second, users need to trust that the hardware's security mechanisms can effectively resist both physical tampering and side-channel attacks. While these assumptions may be acceptable for some use cases, they might give pause to users handling particularly sensitive or high-value operations.

Since extensive discussion already exists on these topics, we'll simply acknowledge them here and proceed, assuming these trust assumptions hold true. Pluto provides multiple execution modes to maximize user optionality. Users should choose the security model that best fits their needs.

Web Proofs — TEE mode

Pluto offers three execution modes for Web Proofs: MPC mode, Origo proxy mode, and TEE mode. Each mode has distinct trust assumptions, performance characteristics, and latency considerations.

In TEE mode, a client’s request is routed through a proxy, which runs inside a Trusted Execution Environment. This proxy observes encrypted TLS session data (reusing components from our Origo networking stack) and generates attestations based on the observed data.

Establishing the Outer TLS connection

The process begins by establishing a TLS Websocket connection to the Notary (which again, runs inside a TEE). Initially, we use a standard Let’s Encrypt server certificate, which is generated within and then injected into all other TEEs. This first TLS connection ensures compliance with browser safety requirements, particularly around Root Certificate Authority-signed certificates, as self-signed certificates would be rejected by the browser. The browser is responsible for initiating this first TLS handshake.

Establishing the Inner TLS connection

Our custom WASM TLS client implementation creates a second “inner” TLS connection once the “outer” TLS connection has been established. This inner TLS connection uses an ephemeral server certificate generated within the TEE, ensuring that only the TEE has access to the key. This inner TLS connection is critical for Channel Binding, a security measure that “locks” the inner TLS session, ensuring that any tampering with the inner TLS session by an external party would be detected.

Channel Binding with EKM

We use TLS Exported Key Material (EKM) for Channel Binding on the inner TLS connection, which is a standard technique commonly supported in libraries like Rust and Golang. EKM ensures that both parties (i.e., client and TEE) can derive cryptographic keys from the established TLS connection, enabling the client to validate the integrity of the TLS connection.

Verifying TEE integrity with attestation

To verify the actual TEE’s authenticity, we use a custom protocol on top of the inner TLS connection, starting with parsing the magic bytes “TEETLS” to verify the transmitted TEE’s attestation payload. Once the client convinces itself that it is communicating to the correct Notary, the proxying process begins. The verification process includes reproducible Notary builds to verify the application running inside the TEE. Today, we utilize Github CI builds, which publish hashes of the built Notary for verification.

Web Proof Proxying

Once proxying is complete, we apply a Web Proof Manifest, which imposes conditions on the proxied HTTP request and response. The client sends the TLS application secrets to the Notary. Note that only the client and the confidential TEE have access to these secrets. After the manifest is enforced, an attestation is sent from the notary back to the client, which can then be verified on-chain, via Pluto’s public APIs, or by third parties.

Web Proof TEE mode is designed to ensure sensitive data is handled securely while maintaining high performance using a combination of hardware-backed isolation, EKM Channel Binding and a custom “TEETLS” protocol. Pluto’s Web Proof TEE mode focuses on privacy, integrity, and low-latency to enable secure Web Proofs with minimal overhead.

Aside: Hardware Support for TEEs

Clearly, the effectiveness of a given Trusted Execution Environment (TEE) relies on the underlying hardware. Different hardware vendors have developed specific TEE implementations.

Intel SGX (Software Guard Extensions): Developers can create secure enclaves within their applications to protect sensitive data and code from the host system. This requires custom app logic to move critical operations into enclaves.

Intel TDX (Trust Domain Extensions): TDX provides VM-level isolation, where entire applications are isolated in Trust Domains. Developers can run applications with almost no modifications to the underlying code. Pluto is using Intel TDX.

AMD SEV-ES: Roughly similar to Intel SGX.

AMD SEV-SNP: Roughly equivalent to Intel TDX.

Cloud providers offer TEE solutions leveraging Intel, AMD, or other vendor implementations for secure workloads, including AWS Nitro Enclaves, Microsoft Azure Confidential Computing, and Google Cloud’s Confidential Space. In addition to these cloud offerings, some developers run TEEs on self-hosted bare metal servers, such as Hetzner. A list of compatible hardware can be found here. Many cloud solutions also integrate container-based technologies, often utilizing Kubernetes to orchestrate secure workloads within TEEs. At their core, these container solutions rely on the same foundational hardware-rooted TEE technologies.

Over the past 6 months, we’ve been primarily focusing on Intel’s TDX, as it has proved to be much easier to work with compared to Intel SGX. While others also have started exploring Intel’s TDX more thoroughly due to this advantage, AMD’s solutions are still under-explored.

The role of TEE’s in Cryptography

TEEs provide an alternative to pure cryptography solutions (like ZKPs) for ensuring privacy in cryptographic computations. ZKPs are often complex and resource-intensive, especially on constrained devices like browsers or mobile phones.

TEEs simplify privacy by processing sensitive data in secure, encrypted enclaves. Cryptographic computations can be carried out inside the TEE, with results returned without exposing private data. While ZKPs place trust in cryptographic protocols, TEEs place trust in secure hardware to protect privacy. At Pluto, we prioritize and invest heavily in cryptography, viewing TEE approaches as a temporary solution to address low-latency requirements for certain use cases of our users.

TEE Research & Development at Pluto

At Pluto, we’re actively exploring how TEEs can enhance security and trust in our systems. Our focus spans several key areas, from reproducible builds to custom Confidential Virtual Machine (CVM) images to secure communication protocols.

We’re committed to ensuring the integrity of workloads running inside a TEE with reproducible builds and transparent verification. While currently using Google Confidential Space for rapid prototyping, we’re working towards a Pluto TEE VM, which will give us greater control over attestation and eliminates reliance on proprietary systems.

Securing client-to-TEE communication, especially in browser environments, has been another challenge. We've developed a custom TEE-TLS protocol to address these unique challenges, but we'd be interested in seeing if we can establish an industry-wide standard.

Additionally, we’re investigating the trade-offs between stateful vs stateless TEEs in clustered environments. Managing shared secrets and securely distributing data across multiple TEEs is a complex but critical challenge in maintaining both security and functionality.

Stay tuned for an in-depth look at our active TEE-based R&D.

Summary

Trusted Execution Environments provide a secure area within a processor to protect sensitive computations from external interference. They offer key features such as isolation, integrity, and confidentiality to safeguard data during processing.

At Pluto, we use TEE mode as one mode for generating Web Proofs. In this mode, a client’s request is routed through a proxy running inside a TEE, which observes encrypted TLS session data and generates attestations. The process involves establishing a TLS connection to a TEE-based Notary, followed by a secure “inner” TLS connection for Channel Binding. We leverage TLS Exported Key Material (EKM) for integrity verification and use a custom protocol for authenticating the TEE’s integrity and generating valid Web Proofs.

Pluto is making significant investments in full client-side proving for zero-knowledge proofs. While ZKPs can be computationally intensive and introduce latency, TEEs provide faster processing times, making them an ideal solution for low-latency Web Proofs.

Are you interested in working with TEEs and cryptography? We are hiring.