mirror of
https://github.com/privacy-scaling-explorations/pse.dev.git
synced 2026-04-23 03:01:03 -04:00
Update tee ppd post
This commit is contained in:
tkmct
@@ -1,36 +1,42 @@
|
||||
---
|
||||
authors: ["Takamichi Tsutsumi"]
|
||||
title: "TEE based private proof delegation"
|
||||
image: "/articles/[article_folder]/cover.web"
|
||||
image: null
|
||||
tldr: "Intro to trusted execution environment based private proof delegation"
|
||||
date: "2025-05-08"
|
||||
date: "2025-05-19"
|
||||
projects: ["private-proof-delegation"]
|
||||
---
|
||||
# Introduction
|
||||
|
||||
## tl;dr
|
||||
We built a TEE-based system for secure zero-knowledge proof delegation using Intel TDX. It allows clients to privately outsource large proving tasks without leaking inputs. Unlike mobile-native proving, which is constrained by hardware limits, TEE-based proving can scale to larger statements today — and continue to scale as proof systems improve. As a hardware-backed solution, TEE remains compatible with future advancements in software (e.g., faster proof systems, better engineering) and won't be invalidated by them, as long as the trust model is acceptable.
|
||||
We built a TEE-based system for secure zero-knowledge proof delegation using Intel TDX. It allows clients to privately outsource large proving tasks without leaking inputs. Unlike mobile-native proving, which is constrained by hardware limits, TEE-based proving can scale to larger statements today — and continue to scale as proof systems improve. As a hardware-backed solution, TEE remains compatible with future advancements in software (e.g., faster proof systems, better engineering) and won't be invalidated by them, as long as the trust model is acceptable.
|
||||
|
||||
➡️ [Jump to Benchmarking section](#Benchmarking) to see how it performs in practice.
|
||||
|
||||
# Introduction
|
||||
## Background and motivation
|
||||
Typically, zk applications let consumer devices such as mobile phone or web browsers to generate SNARK proofs. In such cases, the secret inputs from the clients never leave the device, therefore the privacy of the inputs are protected. However, the complexity of the statements that weak hardware can prove is fairly limited. This means that proving more complex statements requires stronger hardware - something most users do not have access to in their daily lives.
|
||||
One approach to address this issue is to **delegate the proof generation** to external servers with powerful hardware. This technique is called proof delegation. By using this technique, clients with weak devices can offload heavy computation to an external server and still obtain a proof about their private data.
|
||||
Typically, zk applications let consumer devices such as mobile phones or web browsers generate SNARK proofs. In such cases, the secret inputs from the clients never leave the device; therefore, the privacy of the inputs is protected. However, the complexity of the statements that weak hardware can prove is fairly limited. This means that proving more complex statements requires stronger hardware—something most users do not have access to in their daily lives.
|
||||
One approach to address this issue is to **delegate the proof generation** to external servers with powerful hardware. This technique is called proof delegation. By using this technique, clients with weak devices can offload heavy computation to an external server and still obtain proof about their private data.
|
||||
|
||||
*How naive proof delegation works*
|
||||
In naive proof delegation, the client sends their raw inputs directly to the proving server, which then generates the proof. This approach works well for non-sensitive computations (e.g., public blockchain state transitions), but it fails to preserve the zero-knowledge property when the inputs are private. The server learns the data as-is, so there is no privacy guarantee.
|
||||
In naive proof delegation, the client sends their raw inputs directly to the proving server, which then generates the proof. This approach works well for non-sensitive computations (e.g., public blockchain state transitions), but it fails to preserve the zero-knowledge property when the inputs are private. The server learns the data as is, so there is no privacy guarantee.
|
||||
|
||||
## Private proof delegation (PPD)
|
||||
**Private proof delegation**(PPD) enhances this model by ensuring the private input remains hidden from the server. This is achieved by introducing a cryptographic layer between the client and the proving server. Instead of sending raw data, the client encrypts the private input before transmission.
|
||||
**Private proof delegation** (PPD) enhances this model by ensuring the private input remains hidden from the server. This is achieved by introducing a cryptographic layer between the client and the proving server. Instead of sending raw data, the client encrypts the private input before transmission.
|
||||
|
||||
|
||||
*Private proof delegation*
|
||||
|
||||
The cryptographic techniques that we can possibly use includes:
|
||||
The cryptographic techniques that we can possibly use include
|
||||
|
||||
- **MPC ([Collaborative zkSNARKs](https://eprint.iacr.org/2021/1530))** utilize secret-sharing based MPC to hide the raw private inputs by splitting them into pieces.
|
||||
- **MPC ([Collaborative zkSNARKs](https://eprint.iacr.org/2021/1530))** utilizes secret-sharing-based MPC to hide the raw private inputs by splitting them into pieces.
|
||||
- **FHE**-based approach encrypts the private inputs and computes directly on ciphertext. Example: [Blind zkSNARKs](https://eprint.iacr.org/2024/1684) and [FHE-SNARK](https://eprint.iacr.org/2025/302)
|
||||
- **TEE** based approach (this work) utilize hardware-isolated environment to protect data.
|
||||
- **TEE**-based approach (this work) utilize hardware-isolated environments to protect data.
|
||||
|
||||
In this article, we focus on TEE-based approach which we believe practical and well-supported in today's cloud environments.
|
||||
In this article, we focus on the TEE-based approach, which we believe is practical and well-supported in today's cloud environments.
|
||||
|
||||
# TEE Primer: What and Why
|
||||
## What is Trusted Execution Environment(TEE)?
|
||||
## What is Trusted Execution Environment (TEE)?
|
||||
|
||||
A **Trusted Execution Environment (TEE)** is a **secure and isolated processing environment** that runs alongside the main operating system on a machine. It provides:
|
||||
|
||||
@@ -52,7 +58,7 @@ There are several key components of TEE:
|
||||
We will take a closer look into each of the items.
|
||||
|
||||
### Hardware isolation
|
||||
At the heart of any Trusted Execution Environment (TEE) is the concept of hardware-enforced isolation. Hardware isolation refers to the physical and logical mechanisms built directly into the CPU and platform architecture that create a boundary between the execution environment inside the TEE and the rest of the system (Rich Execution Environment, REE) — including the operating system, hypervisor, firmware, and other software running outside the TEE.
|
||||
At the heart of any Trusted Execution Environment (TEE) is the concept of hardware-enforced isolation. Hardware isolation refers to the physical and logical mechanisms built directly into the CPU and platform architecture that create a boundary between the execution environment inside the TEE and the rest of the system (Rich Execution Environment, REE)—including the operating system, hypervisor, firmware, and other software running outside the TEE.
|
||||
|
||||
Rather than relying on software controls (which can be bypassed by privileged attackers), hardware isolation ensures that:
|
||||
|
||||
@@ -60,39 +66,39 @@ Rather than relying on software controls (which can be bypassed by privileged at
|
||||
- Only code running inside the TEE itself can read or modify its protected memory and internal state.
|
||||
- External attempts to inspect, tamper, or interfere with the TEE are either blocked at the hardware level or immediately detectable.
|
||||
|
||||
This isolation is enforced by mechanisms such as:
|
||||
This isolation is enforced by mechanisms such as
|
||||
|
||||
- Memory address translation and access control rules tightly integrated with the CPU
|
||||
- Dedicated secure memory regions (e.g., EPC in Intel SGX, Secure EPT in Intel TDX)
|
||||
- Dedicated secure memory regions (e.g., Enclave Page Cache in Intel SGX, Secure EPT in Intel TDX)
|
||||
- CPU privilege separation between "trusted" and "untrusted" execution modes
|
||||
|
||||
|
||||
### Memory encryption
|
||||
While hardware isolation protects the logical boundaries of the Trusted Execution Environment (TEE), it does not by itself prevent physical attacks targeting the system’s memory. For example, if the attacker have access to the physical hardware, it is possible to dump the memory to see the data inside. Memory encryption addresses this gap by ensuring that all data stored outside the CPU boundary — particularly in RAM — remains cryptographically protected by encryption scheme against unauthorized access, even in the face of direct hardware attacks. The data stored inside the memory is always encrypted with a key secured in the chip (only from inside the TEE can access the key). For example in Intel TDX, AES-XTS with ephemeral 128bit memory-encryption key (TDX) is used for encrypting the data and the integrity of the data inside memory is guranteed by SHA-3 based MAC so that the malicious data tampering can be detected.
|
||||
While hardware isolation protects the logical boundaries of the Trusted Execution Environment (TEE), it does not by itself prevent physical attacks targeting the system’s memory. For example, if the attacker has access to the physical hardware, it is possible to dump the memory to see the data inside. Memory encryption addresses this gap by ensuring that all data stored outside the CPU boundary — particularly in RAM — remains cryptographically protected by encryption schemes against unauthorized access, even in the face of direct hardware attacks. The data stored inside the memory is always encrypted with a key secured in the chip (only TEE can access the key). For example, in Intel TDX, AES-XTS with ephemeral 128-bit memory-encryption keys (TDX) are used for encrypting the data, and the integrity of the data inside memory is guaranteed by SHA-3-based MAC so that malicious data tampering can be detected.
|
||||
|
||||
This ensures that:
|
||||
This ensures that
|
||||
|
||||
- Even if an attacker has physical access to the machine (e.g., cold boot attacks, bus sniffing), the data they retrieve from RAM remains unintelligible.
|
||||
- DMA (Direct Memory Access) attacks by peripherals cannot extract plaintext secrets from memory regions assigned to the TEE.
|
||||
- Side-channel leakage through unprotected memory reads/writes is minimized.
|
||||
|
||||
### Remote attestation
|
||||
ven with hardware isolation and memory encryption, a crucial question remains:
|
||||
Even with hardware isolation and memory encryption, a crucial question remains:
|
||||
**"How can a remote party trust that the TEE is running the intended code on a genuine, uncompromised platform?"**
|
||||
|
||||
**Remote attestation** answers this question. It is the process by which a TEE proves to an external verifier that:
|
||||
|
||||
- It is running on authentic, trusted hardware
|
||||
- The code executing inside the TEE matches an expected and approved version
|
||||
- The system's security configuration (e.g., secure boot, memory protections) is correctly enabled
|
||||
- It is running on authentic, trusted hardware.
|
||||
- The code executing inside the TEE matches an expected and approved version.
|
||||
- The system's security configuration (e.g., secure boot, memory protections) is correctly enabled.
|
||||
|
||||
This proof enables remote clients to establish trust before transmitting sensitive data or initiating private computations.
|
||||
|
||||
|
||||
- The booted TD image exactly as expected (Secure boot)
|
||||
- The measurements created/extended during runtime are as expected
|
||||
- The TEE is executed on an certified hardware platform
|
||||
- The platform is fully up to date (TCB)
|
||||
- The booted TD image exactly as expected (secure boot).
|
||||
- The measurements created/extended during runtime are as expected.
|
||||
- The TEE is executed on a certified hardware platform.
|
||||
- The platform is fully up to date (TCB).
|
||||
|
||||
If the measurements match, the verifier can trust the TEE is in a secure and expected state.
|
||||
|
||||
@@ -100,15 +106,15 @@ Technologies like Intel TDX TD Quote, Intel SGX Attestation Service, and TPM 2.0
|
||||
|
||||
### Root of Trust
|
||||
|
||||
At the foundation of any Trusted Execution Environment (TEE) lies the concept of a **Root of Trust** — a minimal, immutable, and trusted set of hardware, firmware, and cryptographic keys that anchors all higher-level security guarantees. Without a reliable Root of Trust, none of the protections offered by hardware isolation, memory encryption, or remote attestation would be meaningful.
|
||||
At the foundation of any Trusted Execution Environment (TEE) lies the concept of a **Root of Trust** — a minimal, immutable, and trusted set of hardware, firmware, and cryptographic keys that anchors all higher-level security guarantees. Without a reliable root of trust, none of the protections offered by hardware isolation, memory encryption, or remote attestation would be meaningful.
|
||||
|
||||
A Root of Trust is the starting point from which trust is established and extended throughout the system. It typically involves:
|
||||
A Root of Trust is the starting point from which trust is established and extended throughout the system. It typically involves
|
||||
|
||||
- Immutable hardware components (such as CPU microcode or a dedicated security processor)
|
||||
- Secure boot firmware that verifies each stage of system initialization
|
||||
- Cryptographic keys (e.g., device identity keys, endorsement keys) that are embedded during manufacturing and protected from software access
|
||||
|
||||
In Intel TDX and similar TEEs, the Root of Trust is composed of:
|
||||
In Intel TDX and similar TEEs, the root of trust is composed of
|
||||
|
||||
- Intel-manufactured CPU with trusted microcode
|
||||
- Hardware-isolated execution of the TDX modules
|
||||
@@ -117,7 +123,7 @@ In Intel TDX and similar TEEs, the Root of Trust is composed of:
|
||||
Importantly, the security of the entire TEE — including attestation, isolation, and encryption — ultimately depends on the integrity and authenticity of this Root of Trust.
|
||||
|
||||
## What is the trust assumption of TEE?
|
||||
In traditional cryptography, security relies on mathematical hardness assumptions — for example, the difficulty of solving the Discrete Logarithm Problem (DLP), or the intractability of Learning With Errors (LWE). These assumptions are well-studied and allow cryptographic protocols to provide strong, quantifiable security guarantees.
|
||||
In traditional cryptography, security relies on mathematical hardness assumptions — for example, the difficulty of solving the Discrete Logarithm Problem (DLP) or the intractability of Learning With Errors (LWE). These assumptions are well-studied and allow cryptographic protocols to provide strong, quantifiable security guarantees.
|
||||
|
||||
In contrast, when relying on a Trusted Execution Environment (TEE), security instead depends on a different class of assumptions: trust in hardware, firmware, and system integrity.
|
||||
Rather than assuming a computational problem is hard, we assume that certain hardware components behave correctly, securely, and without malicious interference.
|
||||
@@ -128,7 +134,7 @@ In this section, we detail what specific components and entities must be trusted
|
||||
|
||||
|
||||
### Trust in the Hardware Manufacturer
|
||||
A fundamental trust anchor when using a TEE is the **hardware manufacturer**. In the case of Intel TDX, this is Intel Corporation, who designs and produces the processors and microcode that enforce TDX protections.
|
||||
A fundamental trust anchor when using a TEE is the **hardware manufacturer**. In the case of Intel TDX, this is Intel Corporation, which designs and produces the processors and microcode that enforce TDX protections.
|
||||
|
||||
When trusting the hardware manufacturer, the following assumptions are made:
|
||||
|
||||
@@ -167,12 +173,361 @@ The attestation service correctly verifies the quotes it receives, checking that
|
||||
- **Impartial and Secure Operation**:
|
||||
The attestation service must behave honestly, not issuing approvals for devices that are compromised, outdated, or misconfigured.
|
||||
- **Resistance to Collusion or Coercion**:
|
||||
The attestation service must resist external pressures (e.g., nation-state coercion) that might lead it to falsely attest an insecure environment.
|
||||
The attestation service must resist external pressures (e.g., nation-state coercion) that might lead it to falsely attestation to an insecure environment.
|
||||
|
||||
**What if Broken**
|
||||
If the attestation service incorrectly verifies a compromised TEE — or worse, issues fabricated attestation results — remote users would falsely believe they are communicating with a secure environment.
|
||||
This would completely undermine the remote trust model that TEEs are designed to enable.
|
||||
|
||||
---
|
||||
|
||||
# TEE-based private proof delegation
|
||||
## Construction of TEE-based private proof delegation
|
||||
TEE-based private proof delegation system involves a few additional components compared to naive PPD system. In this section, we describe how to construct a TEE-based private proof delegation system.
|
||||
|
||||
|
||||
|
||||
*Architecture diagram*
|
||||
|
||||
In the architecture diagram above, we can see several comopnents, including
|
||||
- Client
|
||||
- TD Host
|
||||
- TD Guest (Prover)
|
||||
- Attestation provider
|
||||
- Verifier
|
||||
|
||||
**Client** is a party who wants to have a zk proof about a statement using their private input. Typically this party computes the proof by itself, but somehow it wants to delegate the proving computation to external parties.
|
||||
|
||||
**TD Host** is a host OS running on a server that runs the TEE VM inside. In Intel TDX, the TEE VM is called trusted domain (TD); therefore, we call this host OS a TD host. TD host is physically running the TEE VM (TD guest) on the machine, but the OS, firmware, and supervisors cannot access the data inside the guest VM thanks to the TEE functionality, such as memory encryption. The TD guest is isolated from the TD host.
|
||||
|
||||
**TD Guest (Prover)** is a TEE VM running inside the TD host. This party actually computes the zk proof on behalf of the client. In order to make the safe transfer of the secret data, TD guest and client have to establish a secure communication channel so that no one else can read the data passed between the two parties. TD guest will decrypt the data passed through the channel, run the proof computation, and send the proof data back to the client. At the beginning, the TD guest is asked to generate TD quote for the remote attestation by the client. They get a quote and send its data to the attestation provider to securely attest to its state.
|
||||
|
||||
**Attestation provider** is a party who provides a secure remote attestation capability. This party will provide a quote verification and generate attestation using pre-registered TEE hardware information. In this scenario, we have to trust this attestation provider correctly registered the hardware info, like its embedded keys and keychains.
|
||||
|
||||
**Verifier** is anyone who verifies the generated proof.
|
||||
|
||||
## Execution flow
|
||||
### Remote Attestation
|
||||
We start the whole process with remote attestation. In this step, the client ensures that the prover VM is running on legitimate hardware and firmware, OS, and program.
|
||||
|
||||
|
||||
### What Happens
|
||||
|
||||
1. The **TEE environment** (such as a confidential VM or enclave) begins by measuring its **initial state** at launch time. These measurements include:
|
||||
- The code and data loaded into the TEE at startup
|
||||
- Configuration values (e.g., enabled security features, TEE attributes)
|
||||
|
||||
2. These measurements are securely recorded in **platform-protected registers**, such as:
|
||||
- Platform Configuration Registers (PCRs) in a TPM
|
||||
- Runtime Measurement Registers (RTMRs) or equivalent TEE-specific structures
|
||||
|
||||
3. The TEE then generates an **attestation report** — a structured message that includes:
|
||||
- The recorded measurements
|
||||
- TEE metadata (such as the identity of the code, runtime version, and security configuration)
|
||||
- Optional application-specific data (e.g., a nonce or public key from the client)
|
||||
|
||||
4. This attestation report is sent to a trusted component inside the platform known as the **attestation signing agent** (e.g., a *quoting enclave*, *firmware-based attestation module*, or *secure co-processor*).
|
||||
|
||||
5. The attestation signing agent signs the report using a **manufacturer-provisioned attestation key**. This key is
|
||||
- Cryptographically tied to the device
|
||||
- Certified by the TEE vendor (e.g., Intel, AMD, ARM)
|
||||
- Stored and used in a protected environment inaccessible to untrusted software
|
||||
|
||||
6. The resulting **attestation quote** is returned to the TEE and passed to the **client** (or relying party) that requested attestation.
|
||||
|
||||
7. The client forwards the quote to a **remote attestation service**, which:
|
||||
- Verifies the signature on the quote using the manufacturer’s root certificate
|
||||
- Validates the integrity and freshness of the TEE’s measurements
|
||||
- Confirms that the platform is genuine, up-to-date, and securely configured
|
||||
|
||||
8. If successful, the attestation service returns a signed statement (e.g., JWT, certificate, or signed JSON blob) to the client, confirming the TEE’s authenticity.
|
||||
|
||||
9. The **client** examines this attestation result, ensuring:
|
||||
- The measured code matches the expected application.
|
||||
- All required security features (e.g., secure boot, memory encryption) are active.
|
||||
- The quote is recent and bound to a valid nonce or challenge.
|
||||
|
||||
Only once this trust is established does the client proceed to send sensitive data to the TEE.
|
||||
|
||||
---
|
||||
|
||||
### Runtime Attestation with Linux IMA and Keylime
|
||||
|
||||
While launch-time attestation provides assurance that a Trusted Execution Environment (TEE) **starts in a known-good state**, it does not cover what happens *after* boot. A malicious actor could, for example, replace a binary or tamper with configuration files post-launch without affecting the original attestation quote.
|
||||
|
||||
To address this, we incorporate **runtime attestation** using the **[Linux Integrity Measurement Architecture (IMA)](https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture)** and the **[Keylime](https://keylime.dev/)** framework.
|
||||
|
||||
---
|
||||
|
||||
#### What Is Linux IMA?
|
||||
|
||||
**IMA** is a Linux kernel subsystem that measures files — such as executables, libraries, scripts, and configuration files — *at the time they are accessed*. It maintains a **measurement log**, which contains cryptographic hashes of all accessed files. These hashes are extended into a **Platform Configuration Register (PCR)** (typically **PCR10** in TPM-backed systems).
|
||||
|
||||
This allows the system to:
|
||||
- Detect if any critical file has been changed or tampered with.
|
||||
- Compare runtime measurements against a reference "good" state.
|
||||
- Bind application behavior to expected code and configuration.
|
||||
|
||||
---
|
||||
|
||||
#### What Is Keylime?
|
||||
|
||||
**Keylime** is an open-source remote attestation framework designed to work with IMA. It allows a **remote verifier** (e.g., a client) to continuously monitor the integrity of a **running system**, including a TEE-based confidential VM.
|
||||
|
||||
Keylime components include:
|
||||
- **Agent (inside the TEE guest)**: Reports IMA measurements and TPM quotes
|
||||
- **Verifier (outside the TEE)**: Validates measurements against a policy
|
||||
- **Registrar**: Manages key provisioning and trust setup
|
||||
|
||||
---
|
||||
|
||||
#### How Runtime Attestation Complements Launch-Time Attestation
|
||||
|
||||
| Launch-Time Attestation | Runtime Attestation (IMA + Keylime) |
|
||||
|--------------------------------------------------|----------------------------------------------------|
|
||||
| Validates integrity at the point of TD creation | Monitors integrity throughout execution |
|
||||
| Covers bootloader, kernel, early OS state | Covers binaries, libraries, config files, scripts |
|
||||
| Performed once at startup | Ongoing or on-demand validation |
|
||||
| Bound to hardware measurement registers (e.g., RTMRs) | Bound to TPM PCRs (e.g., PCR10) |
|
||||
|
||||
|
||||
#### Benefits in a ZK Proving Context
|
||||
|
||||
In delegated proving, runtime attestation can ensure that:
|
||||
- The ZK prover binary running inside the TEE has not been modified or replaced.
|
||||
- The proving key and parameters are untampered.
|
||||
- The system hasn’t silently switched to an insecure configuration.
|
||||
|
||||
This provides **stronger guarantees to the client** — not only is the environment secure at boot, but **it remains secure during execution**.
|
||||
|
||||
---
|
||||
|
||||
#### Deployment in TEE-Based Setup
|
||||
|
||||
1. The TEE guest VM runs a Linux kernel with IMA enabled.
|
||||
2. The IMA policy is configured to measure:
|
||||
- ZK prover binary
|
||||
- Dependencies and shared libraries
|
||||
- Config files and proving keys
|
||||
3. The Keylime Agent runs inside the TEE guest and periodically sends:
|
||||
- TPM quotes (including PCR10)
|
||||
- IMA measurement log
|
||||
4. The remote Keylime Verifier (e.g., hosted by the client) checks:
|
||||
- The TPM quote's signature
|
||||
- That IMA measurements match an expected whitelist
|
||||
|
||||
---
|
||||
|
||||
### Trust Model Enhancement
|
||||
|
||||
By combining
|
||||
- **Launch-time attestation** (via TEE quote + attestation service), and
|
||||
- **Runtime attestation** (via IMA + Keylime + TPM),
|
||||
|
||||
We create a **two-layer trust model** where the client can verify:
|
||||
1. The TEE starts securely and is properly configured.
|
||||
2. The integrity of the prover binary and environment is continuously enforced.
|
||||
|
||||
This layered approach significantly raises the bar against both **transient** and **persistent** attacks on delegated ZK proving infrastructure.
|
||||
|
||||
## Secure channel setup
|
||||
|
||||
Once attestation confirms that the TEE is in a trusted state, the client needs a secure way to transmit private data — such as private inputs — into the TEE without exposing them to the untrusted host. We can use secure communication channels such as TLS.
|
||||
|
||||
---
|
||||
|
||||
#### Purpose
|
||||
|
||||
- Protect the client’s sensitive data in transit.
|
||||
- Ensure data is delivered **only to the verified TEE**.
|
||||
- Prevent tampering or interception by the host or hypervisor.
|
||||
|
||||
---
|
||||
|
||||
#### How It Works
|
||||
|
||||
1. **Attestation is completed**, and the client verifies the TEE’s integrity.
|
||||
2. In our implementation, we used **Keylime’s secure payload delivery mechanism**:
|
||||
- The **Keylime Tenant** sends the encrypted data to the **Keylime Agent** running inside the TEE guest.
|
||||
- This only happens **after the TEE passes both launch-time and runtime attestation**.
|
||||
- Keylime tenant and agent are communicating via mTLS channel.
|
||||
3. The Keylime Agent receives and decrypts the data inside the TEE.
|
||||
4. The proving process begins using the securely provisioned input.
|
||||
|
||||
## Proof generation and verification
|
||||
Once all the data needed to compute the zk proof, TD guest can now compute the proof. This part is pretty much the same as normal computation because we can run exactly the same binaries as in the normal server.
|
||||
|
||||
When proof is computed, TD guest send the proof back to the client or any third party who wants to verify the proof.
|
||||
|
||||
# Benchmarking
|
||||
We took benchmarks of the system architecture described in the previous section. The benchmark targets are **[semaphore](https://semaphore.pse.dev/)** and [proof-of-twitter](https://github.com/zkemail/proof-of-twitter/tree/main) from **[zkemail](https://prove.email/)**. Both are important client applications that utilize zk proof for privacy. The results help assess whether modern TEEs offer a viable foundation for private proof delegation in practice.
|
||||
|
||||
The first thing we did was to take benchmarks of the semaphore circuit using [this repo](https://github.com/vplasencia/semaphore-benchmarks).
|
||||
For the semaphore we ran three benchmarking settings.
|
||||
1. Benchmark for proof generation inside TEE VM
|
||||
2. Benchmark for proof generation inside normal VM
|
||||
3. Benchmark for E2E TEE-based private proof delegation setting
|
||||
|
||||
For 1 and 3, we use the Azure VM Standard_EC16eds_v5 series; for 2, we use the Azure Standard_E16ds_v5 series. Both have a RAM size of 128 GiB and 16 vCPUs. The only difference is if TEE functionality is turned on or not.
|
||||
|
||||
For zkemail, we used proof-of-twitter circuit to measure the number. For this, we only took E2E benchmarks to see if the whole system can provide an acceptable number.
|
||||
|
||||
## Semaphore benchmarks
|
||||
1. Benchmark for proof generation inside TEE VM
|
||||
|
||||
2. Proof generation inside normal VM
|
||||
|
||||
|
||||
|
||||
E2E benchmarks
|
||||
In our scenario, we measure the E2E performance, including
|
||||
- Keylime runtime attestation
|
||||
- TDX attestation
|
||||
- Proof generation
|
||||
- (We skipped the actual transfer of secret input data in this scenario)
|
||||
|
||||
| | 1 | 2 | 3 | Avg. |
|
||||
| ------------------- | ------ | ------ | ------ | ------ |
|
||||
| Keylime attestation | 901ms | 591ms | 597ms | 696ms |
|
||||
| TDX attestation | 1065ms | 1041ms | 1040ms | 1048ms |
|
||||
| Proving | 1147ms | 1133ms | 1128ms | 1136ms |
|
||||
| Total | 3166ms | 2803ms | 2809ms | 2926ms |
|
||||
|
||||
## zk-email benchmarks
|
||||
We use proof-of-twitter circuit as our benchmark target. This demonstrates the real-world use case for TEE-based private proof delegation. The benchmark was taken for the E2E setting, as in the semaphore benchmark.
|
||||
|
||||
| | 1 | 2 | 3 | Avg. |
|
||||
| ------------------- | ------- | ------- | ------- | ------- |
|
||||
| Keylime attestation | 885ms | 606ms | 633ms | 708ms |
|
||||
| TDX attestation | 1079ms | 1387ms | 1820ms | 1428ms |
|
||||
| Proving | 87213ms | 57185ms | 56976ms | 67124ms |
|
||||
| Total | 89224ms | 59216ms | 59462ms | 69300ms |
|
||||
|
||||
|
||||
## Discussions
|
||||
See Table 2—the ~67s proving time dominates E2E latency, so in this case, TEE overhead becomes <5 %. Our benchmarks show that TEE-based delegated proving is both **feasible and practically performant** for real-world zero-knowledge applications — with varying trade-offs depending on the circuit size and security assumptions.
|
||||
|
||||
|
||||
### Attestation Overhead Is Modest
|
||||
|
||||
Both **Keylime runtime attestation** and **TDX launch attestation** contribute **1.74 s total (696 ms + 1 048 ms)** in both cases. In the Semaphore benchmark, their combined overhead accounts for less than 25% of the total latency. This indicates that
|
||||
- **Launch-time and runtime attestation are fast enough** to be included in every proving session.
|
||||
- They can be embedded into interactive or on-demand proving scenarios without causing significant delay.
|
||||
|
||||
However, it's important to note that our benchmarks used a **simple attestation policy** that only performs **signature verification** on the attestation quote.
|
||||
In a production setting, policies may include
|
||||
- Validation of **RTMR (Runtime Measurement Register)** values
|
||||
- Checks for **specific file measurements** via IMA
|
||||
- Enforcement of secure configuration (e.g., Secure Boot, kernel version)
|
||||
|
||||
Such policies would add additional verification steps, which could modestly increase attestation latency.
|
||||
|
||||
### Input Transfer Cost Not Accounted
|
||||
|
||||
Our current benchmark **skips the actual transfer of secret input data** (e.g., witness values, proving keys if needed). In real deployments, this step involves
|
||||
- Transmitting encrypted payloads over a secure channel (e.g., via mTLS)
|
||||
- Decrypting and loading the data inside the TEE
|
||||
|
||||
The cost of this step depends on
|
||||
- **Payload size** (some proving inputs may be tens or hundreds of megabytes)
|
||||
- **Network conditions**, including latency and bandwidth
|
||||
- **Disk I/O**, if data is staged or stored before proving
|
||||
|
||||
While not captured here, this cost should be considered for systems with large or frequent input provisioning.
|
||||
|
||||
## Proving Time Dominates for Larger Circuits
|
||||
|
||||
The **zkEmail circuit** (based on proof-of-Twitter) demonstrates a **much larger proving time** — averaging over 67 seconds — due to higher circuit complexity. In contrast, the **Semaphore proof** completes in just over 1.1 seconds on average.
|
||||
|
||||
This reinforces a key insight:
|
||||
- The performance bottleneck shifts from attestation to proving as circuit size grows.
|
||||
- TEE-induced overhead is amortized in large proofs, making the TEE setup cost relatively negligible in long-running sessions.
|
||||
|
||||
## Scalability and Future Acceleration
|
||||
|
||||
One advantage of using a **VM-based TEE like Intel TDX** is the ability to **scale up compute resources**:
|
||||
|
||||
- On platforms like Azure, we can increase the number of vCPUs and available memory by selecting a larger VM size (e.g., scaling from 4 to 16 or 32 cores).
|
||||
- This enables faster proof generation for large circuits without modifying the security model or proving logic.
|
||||
|
||||
Furthermore, although we have not explored it in this benchmark, **[GPU acceleration is becoming increasingly feasible](https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-trustworthy-ai/)** within TEE environments. Some confidential computing frameworks are beginning to support
|
||||
- GPU passthrough into confidential VMs
|
||||
- Secure offloading of compute-intensive workloads (like FFTs, MSMs) into trusted GPU regions
|
||||
|
||||
If applicable to the proving backend, this could **dramatically reduce proof times** for large circuits — especially for modern SNARKs and STARKs with GPU-optimized primitives.
|
||||
|
||||
## Comparison with Other Approaches
|
||||
|
||||
To contextualize our results, we briefly compare TEE-based delegated proving with two alternative approaches:
|
||||
|
||||
- **Collaborative zkSNARKs**: These use multi-party computation (MPC) to split proof generation across multiple participants. While they eliminate the need to trust hardware, they typically involve higher coordination and communication overhead.
|
||||
|
||||
- **[MoPro](https://zkmopro.org/)**: A mobile-native ZK prover designed to run directly on smartphones. It removes the need for delegation entirely but is limited by the constraints of mobile hardware.
|
||||
|
||||
---
|
||||
|
||||
Thanks to **Roman from [TACEO](https://taceo.io/)**, we also have a benchmark for the same Semaphore circuit using collaborative zkSNARKs with CoCircom. In this setup, three MPC parties ran inside the same data center on **m7a.4xlarge** machines (16 vCPUs, 64 GiB RAM). The total proving time, including witness extension and proof generation, was **626 ms + 39 ms**.
|
||||
|
||||
Although performance depends heavily on specific configurations (e.g., number of parties, network latency), these results show that collaborative SNARKs are a **viable option** for delegated proving.
|
||||
|
||||
However, since both collaborative SNARKs and TEE-based proving rely on cloud infrastructure, it's important to compare their **infrastructure costs**.
|
||||
|
||||
According to Azure's VM pricing:
|
||||
|
||||
- **Standard_E16ds_v5** (non-TEE): $1,010.32/month
|
||||
- **Standard_EC16eds_v5** (TEE-enabled): $1,012.32/month
|
||||
|
||||
This means adding TEE features incurs **virtually no extra cost** — only around $2/month.
|
||||
|
||||
In contrast, collaborative SNARKs typically require **n servers** for n-party computation. So, for a 3-party setup, the base cost is **at least 3× higher** than the TEE-based model.
|
||||
|
||||
---
|
||||
|
||||
We also have benchmark data for mobile proving using **MoPro**, available [here](https://zkmopro.org/docs/performance/). For Semaphore, witness generation and proof creation on an **iPhone 16 Pro** ranged from **165 ms to 1267 ms**, depending on the library.
|
||||
|
||||
However, circuits that require large memory (e.g., 3 GB for iPhone 15) tend to **crash** on native apps. This is a known limitation when using proving backends that rely on **large proving keys**.
|
||||
|
||||
For context, the typical hardware specs used in these mobile benchmarks are
|
||||
|
||||
- **iPhone**: 6-core CPU @ 3.33 GHz, 5.7 GiB RAM
|
||||
- **Android**: 7-core CPU @ 2.16 GHz, 3.82 GiB RAM
|
||||
|
||||
These constraints illustrate the challenge of using mobile-native proving for larger circuits.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Relative Comparison (based on our benchmarks)
|
||||
|
||||
| Approach | Semaphore Circuit | Notes |
|
||||
| ---------------------- | ---------------------------- | ------------------------------------------- |
|
||||
| TEE | ~210ms (proving), ~2.9s (E2E) | Fast, attested, scalable |
|
||||
| Collaborative zkSNARKs | ~ 700ms (proving) | Needs coordination; performance varies |
|
||||
| MoPro | 165 ~ 1267ms (proving) | Local execution; limited by mobile hardware |
|
||||
|
||||
|
||||
# Conclusion
|
||||
|
||||
Our benchmarks show that **TEE-based delegated proving** is both practical and performant for real-world zero-knowledge applications like **Semaphore** and **zkEmail**.
|
||||
|
||||
With modest attestation overhead, strong confidentiality guarantees, and the ability to scale VM resources, this approach offers a compelling balance between **security, performance, and deployability**. While it requires trust in hardware and attestation infrastructure, it avoids the coordination complexity of MPC-based proving and the limitations of mobile-native approaches.
|
||||
|
||||
TEE-based proving is ready for real deployment — especially in cloud-based privacy systems where trust, verifiability, and performance must coexist.
|
||||
|
||||
---
|
||||
|
||||
## Future work
|
||||
|
||||
- Scale to larger circuits using more powerful VMs or GPUs.
|
||||
- Bind attestation results directly to ZK proof outputs.
|
||||
- Extend runtime integrity policies for broader trust coverage.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
## Our choice of TEE
|
||||
Trusted Execution Environments (TEEs) come in multiple forms, distinguished primarily by the granularity of isolation they provide.
|
||||
The two most prominent architectures are process-based TEEs and VM-based TEEs.
|
||||
@@ -208,7 +563,7 @@ Examples: Intel TDX, AMD SEV-SNP
|
||||
|
||||
Characteristics:
|
||||
|
||||
- Isolation is established at the full Virtual Machine (VM) level.
|
||||
- Isolation is established at the full virtual machine level.
|
||||
- The entire guest VM — including its OS and applications — is isolated from the hypervisor and the host system.
|
||||
- The guest OS and applications can largely run unmodified.
|
||||
|
||||
@@ -224,7 +579,7 @@ Limitations:
|
||||
- Larger TCB compared to process-based TEEs (full guest OS must be trusted unless further minimized).
|
||||
- Slightly higher performance overhead compared to native execution (due to memory encryption and virtualization).
|
||||
|
||||
#### Why VM-Based TEE is Better for Our Purpose
|
||||
#### Why VM-Based TEE Is Better for Our Purpose
|
||||
In our private proof delegation use case — where we generate zero-knowledge proofs inside the TEE — the requirements favor VM-based TEE designs for several reasons:
|
||||
|
||||
**Large Memory Requirements**:
|
||||
@@ -243,351 +598,4 @@ Azure Confidential VMs (ECedsv5 series) allow seamless deployment, scaling, and
|
||||
VM-based TEEs like TDX provide attestation mechanisms that cover the entire VM, enabling strong guarantees about the full execution environment — not just a single process.
|
||||
|
||||
|
||||
*Confidential VM availability on Azure*
|
||||
|
||||
---
|
||||
|
||||
# TEE based private proof delegation
|
||||
## Construction of TEE based private proof delegation
|
||||
TEE based private proof delegation system involves a few additional components to naive PPD system. In this section, we describe how to construct a TEE based private proof delegation system.
|
||||
|
||||
|
||||
|
||||
*Architecture diagram*
|
||||
|
||||
In the architecture diagram above, we can see several comopnents including
|
||||
- Client
|
||||
- TD Host
|
||||
- TD Guest (Prover)
|
||||
- Attestation provider
|
||||
- Verifier
|
||||
|
||||
**Client** is a party who wants to have a zk proof about a statement using their private input. Typically this party computes the proof by its own, but somehow they wants to delegate the proving computation to external parties.
|
||||
|
||||
**TD Host** is a host OS running on a server who runs the TEE VM inside. In Intel TDX, the TEE VM is called trusted domain(TD) therefore we call this host OS a TD Host. TD host is physically running the TEE VM (TD guest) on the machine, but the OS, firmware, supervisors cannot access the data inside the guest VM thanks to the TEE functionality such as memory encryption. The TD guest is isolated from the TD host.
|
||||
|
||||
**TD Guest(Prover)** is a TEE VM running inside the TD host. This party actually computes the zk proof on behalf of the client. In order to make the safe transfer of the secret data, TD guest and client has to establish secure communication channel so that no one else can read the data passed between the two parties. TD guest will decrypt the data passed through the channel and runs the proof computation and send the proof data back to the client. At the beginning, td guest is asked to generate TD quote for the remote attestation by the client. They get a quote and send its data to attestation provider to securely attest its state.
|
||||
|
||||
**Attestation provider** is a party who provide a secure remote attestation capability. This party will provide an quote verification and generate attestation using pre-registered TEE hardware infomation. In this scenario, we have to trust this attestation provider correctly registered the hardware info like its embedded keys and key chains.
|
||||
|
||||
**Verifier** is anyone who verify the generated proof.
|
||||
|
||||
## Execution flow
|
||||
### Remote Attestation
|
||||
We start the whole process with remote attestation. In this step, the client ensures that the prover VM is running on a legitimate hardware and firmware, OS and program.
|
||||
|
||||
|
||||
### What Happens
|
||||
|
||||
1. The **TEE environment** (such as a confidential VM or enclave) begins by measuring its **initial state** at launch time. These measurements include:
|
||||
- The code and data loaded into the TEE at startup
|
||||
- Configuration values (e.g., enabled security features, TEE attributes)
|
||||
|
||||
2. These measurements are securely recorded in **platform-protected registers**, such as:
|
||||
- Platform Configuration Registers (PCRs) in a TPM
|
||||
- Runtime Measurement Registers (RTMRs) or equivalent TEE-specific structures
|
||||
|
||||
3. The TEE then generates an **attestation report** — a structured message that includes:
|
||||
- The recorded measurements
|
||||
- TEE metadata (such as the identity of the code, runtime version, security configuration)
|
||||
- Optional application-specific data (e.g., a nonce or public key from the client)
|
||||
|
||||
4. This attestation report is sent to a trusted component inside the platform known as the **attestation signing agent** (e.g., a *Quoting Enclave*, *firmware-based attestation module*, or *secure co-processor*).
|
||||
|
||||
5. The attestation signing agent signs the report using a **manufacturer-provisioned attestation key**. This key is:
|
||||
- Cryptographically tied to the device
|
||||
- Certified by the TEE vendor (e.g., Intel, AMD, ARM)
|
||||
- Stored and used in a protected environment inaccessible to untrusted software
|
||||
|
||||
6. The resulting **attestation quote** is returned to the TEE and passed to the **client** (or relying party) that requested attestation.
|
||||
|
||||
7. The client forwards the quote to a **remote attestation service**, which:
|
||||
- Verifies the signature on the quote using the manufacturer’s root certificate
|
||||
- Validates the integrity and freshness of the TEE’s measurements
|
||||
- Confirms that the platform is genuine, up to date, and securely configured
|
||||
|
||||
8. If successful, the attestation service returns a signed statement (e.g., JWT, certificate, or signed JSON blob) to the client, confirming the TEE’s authenticity.
|
||||
|
||||
9. The **client** examines this attestation result, ensuring:
|
||||
- The measured code matches the expected application
|
||||
- All required security features (e.g., secure boot, memory encryption) are active
|
||||
- The quote is recent and bound to a valid nonce or challenge
|
||||
|
||||
Only once this trust is established does the client proceed to send sensitive data to the TEE.
|
||||
|
||||
---
|
||||
|
||||
### Runtime Attestation with Linux IMA and Keylime
|
||||
|
||||
While launch-time attestation provides assurance that a Trusted Execution Environment (TEE) **starts in a known-good state**, it does not cover what happens *after* boot. A malicious actor could, for example, replace a binary or tamper with configuration files post-launch without affecting the original attestation quote.
|
||||
|
||||
To address this, we incorporate **runtime attestation** using the **[Linux Integrity Measurement Architecture (IMA)](https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture)** and the **[Keylime](https://keylime.dev/)** framework.
|
||||
|
||||
---
|
||||
|
||||
#### What Is Linux IMA?
|
||||
|
||||
**IMA** is a Linux kernel subsystem that measures files — such as executables, libraries, scripts, and configuration files — *at the time they are accessed*. It maintains a **measurement log**, which contains cryptographic hashes of all accessed files. These hashes are extended into a **Platform Configuration Register (PCR)** (typically **PCR10** in TPM-backed systems).
|
||||
|
||||
This allows the system to:
|
||||
- Detect if any critical file has been changed or tampered with
|
||||
- Compare runtime measurements against a reference "good" state
|
||||
- Bind application behavior to expected code and configuration
|
||||
|
||||
---
|
||||
|
||||
#### What Is Keylime?
|
||||
|
||||
**Keylime** is an open-source remote attestation framework designed to work with IMA. It allows a **remote verifier** (e.g., a client) to continuously monitor the integrity of a **running system**, including a TEE-based confidential VM.
|
||||
|
||||
Keylime components include:
|
||||
- **Agent (inside the TEE guest)**: Reports IMA measurements and TPM quotes
|
||||
- **Verifier (outside the TEE)**: Validates measurements against a policy
|
||||
- **Registrar**: Manages key provisioning and trust setup
|
||||
|
||||
---
|
||||
|
||||
#### How Runtime Attestation Complements Launch-Time Attestation
|
||||
|
||||
| Launch-Time Attestation | Runtime Attestation (IMA + Keylime) |
|
||||
|--------------------------------------------------|----------------------------------------------------|
|
||||
| Validates integrity at the point of TD creation | Monitors integrity throughout execution |
|
||||
| Covers bootloader, kernel, early OS state | Covers binaries, libraries, config files, scripts |
|
||||
| Performed once at startup | Ongoing or on-demand validation |
|
||||
| Bound to hardware measurement registers (e.g., RTMRs) | Bound to TPM PCRs (e.g., PCR10) |
|
||||
|
||||
|
||||
#### Benefits in a ZK Proving Context
|
||||
|
||||
In delegated proving, runtime attestation can ensure that:
|
||||
- The ZK prover binary running inside the TEE has not been modified or replaced
|
||||
- The proving key and parameters are untampered
|
||||
- The system hasn’t silently switched to an insecure configuration
|
||||
|
||||
This provides **stronger guarantees to the client** — not only is the environment secure at boot, but **it remains secure during execution**.
|
||||
|
||||
---
|
||||
|
||||
#### Deployment in TEE-Based Setup
|
||||
|
||||
1. The TEE guest VM runs a Linux kernel with IMA enabled.
|
||||
2. The IMA policy is configured to measure:
|
||||
- ZK prover binary
|
||||
- Dependencies and shared libraries
|
||||
- Config files and proving keys
|
||||
3. The Keylime Agent runs inside the TEE guest and periodically sends:
|
||||
- TPM quotes (including PCR10)
|
||||
- IMA measurement log
|
||||
4. The remote Keylime Verifier (e.g., hosted by the client) checks:
|
||||
- The TPM quote's signature
|
||||
- That IMA measurements match an expected whitelist
|
||||
|
||||
---
|
||||
|
||||
### Trust Model Enhancement
|
||||
|
||||
By combining:
|
||||
- **Launch-time attestation** (via TEE quote + attestation service), and
|
||||
- **Runtime attestation** (via IMA + Keylime + TPM),
|
||||
|
||||
we create a **two-layer trust model** where the client can verify:
|
||||
1. The TEE starts securely and is properly configured
|
||||
2. The integrity of the prover binary and environment is continuously enforced
|
||||
|
||||
This layered approach significantly raises the bar against both **transient** and **persistent** attacks on delegated ZK proving infrastructure.
|
||||
|
||||
|
||||
|
||||
|
||||
## Secure channel setup
|
||||
|
||||
Once attestation confirms that the TEE is in a trusted state, the client needs a secure way to transmit private data — such as private inputs — into the TEE without exposing them to the untrusted host. We can use secure communication channel such as TLS.
|
||||
|
||||
---
|
||||
|
||||
#### Purpose
|
||||
|
||||
- Protect the client’s sensitive data in transit
|
||||
- Ensure data is delivered **only to the verified TEE**
|
||||
- Prevent tampering or interception by the host or hypervisor
|
||||
|
||||
---
|
||||
|
||||
#### How It Works
|
||||
|
||||
1. **Attestation is completed**, and the client verifies the TEE’s integrity.
|
||||
2. In our implementation, we used **Keylime’s secure payload delivery mechanism**:
|
||||
- The **Keylime Tenant** sends the encrypted data to the **Keylime Agent** running inside the TEE guest.
|
||||
- This only happens **after the TEE passes both launch-time and runtime attestation**.
|
||||
- Keylime tenant and agent are communicating via mTLS channel.
|
||||
3. The Keylime Agent receives and decrypts the data inside the TEE.
|
||||
4. The proving process begins using the securely provisioned input.
|
||||
|
||||
|
||||
## Proof generation and verification
|
||||
Once all the data needed to compute the zk proof, TD guest can now compute the proof. This part is pretty much the same as normal computation because we can run exactly the same binaries as in the normal server.
|
||||
|
||||
When proof is computed, TD guest send the proof back to the client or any third party who wants to verify the proof.
|
||||
|
||||
# Benchmarking
|
||||
We took benchmarks of the system architecture described in the previous section. The benchmark target are **[semaphore](https://semaphore.pse.dev/)** and [proof-of-twitter](https://github.com/zkemail/proof-of-twitter/tree/main) from **[zkemail](https://prove.email/)**. Both are important client applications which utilize zk proof for privacy. The results help assess whether modern TEEs offer a viable foundation for private proof delegation in practice.
|
||||
|
||||
First thing we did was to take benchmarks of semaphore circuit using [this repo](https://github.com/vplasencia/semaphore-benchmarks).
|
||||
For semaphore we ran three benchmarking settings.
|
||||
1. Benchmark for proof generation inside TEE VM
|
||||
2. Benchmark for proof generation inside normal VM
|
||||
3. Benchmark for E2E TEE based private proof delegation setting
|
||||
|
||||
For 1 and 3, we use Azure VM Standard_EC16eds_v5 series, for 2 we use Azure Standard_E16ds_v5 series. Both has RAM size 128GiB, 16 vCPUs. The only different is if TEE functionality is turned on or not.
|
||||
|
||||
For zkemail, we used proof-of-twitter circuit to measure the number. For this, we only took E2E benchmarks to see if the whole system can provide acceptable number.
|
||||
|
||||
## Semaphore benchmarks
|
||||
1. Benchmark for proof generation inside TEE VM
|
||||
|
||||
2. Proof generation inside normal VM
|
||||
|
||||
|
||||
E2E benchmarks
|
||||
In our scenario, we measure the E2E performance including
|
||||
- Keylime runtime attestation
|
||||
- TDX attestation
|
||||
- Proof generation
|
||||
|
||||
| | 1 | 2 | 3 | Avg. |
|
||||
| ------------------- | ------ | ------ | ------ | ------ |
|
||||
| Keylime attestation | 901ms | 591ms | 597ms | 696ms |
|
||||
| TDX attestation | 1065ms | 1041ms | 1040ms | 1048ms |
|
||||
| Proving | 1147ms | 1133ms | 1128ms | 1136ms |
|
||||
| Total | 3166ms | 2803ms | 2809ms | 2926ms |
|
||||
|
||||
## zk-email benchmarks
|
||||
We use proof-of-twitter circuit as our benchmark target. This demonstrate the real-world usecase for TEE based private proof delegation. The benchmark was taken for E2E setting as in the semaphore benchmark.
|
||||
|
||||
| | 1 | 2 | 3 | Avg. |
|
||||
| ------------------- | ------- | ------- | ------- | ------- |
|
||||
| Keylime attestation | 885ms | 606ms | 633ms | 708ms |
|
||||
| TDX attestation | 1079ms | 1387ms | 1820ms | 1428ms |
|
||||
| Proving | 87213ms | 57185ms | 56976ms | 67124ms |
|
||||
| Total | 89224ms | 59216ms | 59462ms | 69300ms |
|
||||
|
||||
|
||||
## Discussions
|
||||
|
||||
Our benchmarks show that TEE-based delegated proving is both **feasible and practically performant** for real-world zero-knowledge applications — with varying trade-offs depending on the circuit size and security assumptions.
|
||||
|
||||
|
||||
### Attestation Overhead Is Modest
|
||||
|
||||
Both **Keylime runtime attestation** and **TDX launch attestation** contribute **under 2 seconds total** in both cases. In the Semaphore benchmark, their combined overhead accounts for less than 25% of the total latency. This indicates that:
|
||||
- **Launch-time and runtime attestation are fast enough** to be included in every proving session.
|
||||
- They can be embedded into interactive or on-demand proving scenarios without causing significant delay.
|
||||
|
||||
However, it's important to note that our benchmarks used a **simple attestation policy** that only performs **signature verification** on the attestation quote.
|
||||
In a production setting, policies may include:
|
||||
- Validation of **RTMR (Runtime Measurement Register)** values
|
||||
- Checks for **specific file measurements** via IMA
|
||||
- Enforcement of secure configuration (e.g., Secure Boot, kernel version)
|
||||
|
||||
Such policies would add additional verification steps, which could modestly increase attestation latency.
|
||||
|
||||
### Input Transfer Cost Not Accounted
|
||||
|
||||
Our current benchmark **skips the actual transfer of secret input data** (e.g., witness values, proving keys if needed). In real deployments, this step involves:
|
||||
- Transmitting encrypted payloads over a secure channel (e.g., via mTLS)
|
||||
- Decrypting and loading the data inside the TEE
|
||||
|
||||
The cost of this step depends on:
|
||||
- **Payload size** (some proving inputs may be tens or hundreds of megabytes)
|
||||
- **Network conditions**, including latency and bandwidth
|
||||
- **Disk I/O**, if data is staged or stored before proving
|
||||
|
||||
While not captured here, this cost should be considered for systems with large or frequent input provisioning.
|
||||
|
||||
## Proving Time Dominates for Larger Circuits
|
||||
|
||||
The **zkEmail circuit** (based on proof-of-Twitter) demonstrates a **much larger proving time** — averaging over 67 seconds — due to higher circuit complexity. In contrast, the **Semaphore proof** completes in just over 1.1 seconds on average.
|
||||
|
||||
This reinforces a key insight:
|
||||
- The performance bottleneck shifts from attestation to proving as circuit size grows.
|
||||
- TEE-induced overhead is amortized in large proofs, making the TEE setup cost relatively negligible in long-running sessions.
|
||||
|
||||
## Scalability and Future Acceleration
|
||||
|
||||
One advantage of using a **VM-based TEE like Intel TDX** is the ability to **scale up compute resources**:
|
||||
|
||||
- On platforms like Azure, we can increase the number of vCPUs and available memory by selecting a larger VM size (e.g., scaling from 4 to 16 or 32 cores).
|
||||
- This enables faster proof generation for large circuits without modifying the security model or proving logic.
|
||||
|
||||
Furthermore, although we have not explored it in this benchmark, **[GPU acceleration is becoming increasingly feasible](https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-trustworthy-ai/)** within TEE environments. Some confidential computing frameworks are beginning to support:
|
||||
- GPU passthrough into confidential VMs
|
||||
- Secure offloading of compute-intensive workloads (like FFTs, MSMs) into trusted GPU regions
|
||||
|
||||
If applicable to the proving backend, this could **dramatically reduce proof times** for large circuits — especially for modern SNARKs and STARKs with GPU-optimized primitives.
|
||||
|
||||
## Comparison with Other Approaches
|
||||
|
||||
To contextualize our results, we briefly compare TEE-based delegated proving with two alternative approaches:
|
||||
|
||||
- **Collaborative zkSNARKs**: These use multi-party computation (MPC) to split proof generation across multiple participants. While they eliminate the need to trust hardware, they typically involve higher coordination and communication overhead.
|
||||
|
||||
- **[MoPro](https://zkmopro.org/)**: A mobile-native ZK prover designed to run directly on smartphones. It removes the need for delegation entirely but is limited by the constraints of mobile hardware.
|
||||
|
||||
---
|
||||
|
||||
Thanks to **Roman from [TACEO](https://taceo.io/)**, we also have a benchmark for the same Semaphore circuit using collaborative zkSNARKs with CoCircom. In this setup, three MPC parties ran inside the same data center on **m7a.4xlarge** machines (16 vCPUs, 64 GiB RAM). The total proving time, including witness extension and proof generation, was **626 ms + 39 ms**.
|
||||
|
||||
Although performance depends heavily on specific configurations (e.g., number of parties, network latency), these results show that collaborative SNARKs are a **viable option** for delegated proving.
|
||||
|
||||
However, since both collaborative SNARKs and TEE-based proving rely on cloud infrastructure, it's important to compare their **infrastructure costs**.
|
||||
|
||||
According to Azure's VM pricing:
|
||||
|
||||
- **Standard_E16ds_v5** (non-TEE): $1,010.32/month
|
||||
- **Standard_EC16eds_v5** (TEE-enabled): $1,012.32/month
|
||||
|
||||
This means adding TEE features incurs **virtually no extra cost** — only around $2/month.
|
||||
|
||||
In contrast, collaborative SNARKs typically require **n servers** for n-party computation. So, for a 3-party setup, the base cost is **at least 3× higher** than the TEE-based model.
|
||||
|
||||
---
|
||||
|
||||
We also have benchmark data for mobile proving using **MoPro**, available [here](https://zkmopro.org/docs/performance/). For Semaphore, witness generation and proof creation on an **iPhone 16 Pro** ranged from **165 ms to 1267 ms**, depending on the library.
|
||||
|
||||
However, circuits that require large memory (e.g., 3 GB for iPhone 15) tend to **crash** on native apps. This is a known limitation when using proving backends that rely on **large proving keys**.
|
||||
|
||||
For context, the typical hardware specs used in these mobile benchmarks are:
|
||||
|
||||
- **iPhone**: 6-core CPU @ 3.33 GHz, 5.7 GiB RAM
|
||||
- **Android**: 7-core CPU @ 2.16 GHz, 3.82 GiB RAM
|
||||
|
||||
These constraints illustrate the challenge of using mobile-native proving for larger circuits.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Relative Comparison (based on our benchmarks)
|
||||
|
||||
| Approach | Semaphore Circuit | Notes |
|
||||
| ---------------------- | ---------------------------- | ------------------------------------------- |
|
||||
| TEE | ~210ms (proving), ~2.9s (E2E) | Fast, attested, scalable |
|
||||
| Collaborative zkSNARKs | ~ 700ms (proving) | Needs coordination; performance varies |
|
||||
| MoPro | 165 ~ 1267ms (proving) | Local execution; limited by mobile hardware |
|
||||
|
||||
|
||||
# Conclusion
|
||||
|
||||
Our benchmarks show that **TEE-based delegated proving**, is both practical and performant for real-world zero-knowledge applications like **Semaphore** and **zkEmail**.
|
||||
|
||||
With modest attestation overhead, strong confidentiality guarantees, and the ability to scale VM resources, this approach offers a compelling balance between **security, performance, and deployability**. While it requires trust in hardware and attestation infrastructure, it avoids the coordination complexity of MPC-based proving and the limitations of mobile-native approaches.
|
||||
|
||||
TEE-based proving is ready for real deployment — especially in cloud-based privacy systems where trust, verifiability, and performance must coexist.
|
||||
|
||||
---
|
||||
|
||||
## Future work
|
||||
|
||||
- Scale to larger circuits using more powerful VMs or GPUs
|
||||
- Bind attestation results directly to ZK proof outputs
|
||||
- Extend runtime integrity policies for broader trust coverage
|
||||
*Confidential VM availability on Azure*
|
||||
Reference in New Issue
Block a user