Attestation Verification for Delegated Proving

[AmeanAsad]

Overview

This PR adds Trusted Execution Environment (TEE) attestation report verification to proving service clients. With this PR, clients can verify that their delegated prover was run inside a TEE and thus preserved the input and processing privacy of their request.

Note: We tested this end-to-end on versions 0.8.1 of the miden client and the miden prover proxy. The reason behind using these versions is for compatibility with the Miden Testnet.

Implementation Details

Changes

Attestation Verification Integration

• Add TEE attestation report verification to the proving service client.
• Verify attestation reports attached in the Attestation-Report HTTP response header from TEE-enabled delegated provers.

New Dependencies

• attestation-rs - Open source rust attestation verification library that verifies TEE attestation reports written by lunal.

Architecture

1. Client submits a proving request to a delegated prover running inside a TEE.
2. The delegated prover in the TEE processes the client request and generates a proof.
3. The delegated prover returned the generated proof and a cryptographic attestation report in the HTTP response.
4. The client verifies the attestation report and confirms the proof was generated in a private, trusted environment.
5. Now verified, the standard proving workflow continues from there.

Backwards Compatibility

• If an attestation report is present in the Attestation-Report HTTP response header? → Verify the attestation.
• If there’s no Attestation-Report response header or no attestation report in the Attestation-Report response headers? → Proceed without verification (legacy behavior).
• No breaking changes to existing client configurations.

Testing Changes

To test:

• Spin up a delegated prover inside a TEE (this can be provided by Lunal folks). This will have an endpoint (e.g https://miden.lunal.dev/)

• Initialize a local miden client (https://github.com/0xMiden/miden-client)

• In the miden-client.toml , set the remote_rpc_endpoint to the delegated prover url:

  remote_prover_endpoint = "https://miden-prover.lunal.dev"

Migration Strategy

Phase 1: Parallel Deployment

• Deploy TEE-secured delegated prover(s) alongside existing, non-TEE-secured delegated provers.
• Separate, independent endpoints will exist in parallel for testing and gradual adoption.
• Full backward compatibility maintained.

Phase 2: Testing & Validation

• End-to-end, production testing with TEE delegated provers.
• Validate client-side attestation verification.
• Benchmark performance and reliability.

Phase 3: Transition (Optional)

• Gradual migration of all traffic to TEE-secured delegated provers.
• Optional requirement and enforcement of attestations by clients.
• Graceful deprecation of non-TEE, non-private delegated provers.

[AmeanAsad]

closing this now tracking at: 0xMiden/miden-node#969