SP1 Private Proving: Integrating TEE‑Protected Inputs into Your Proof Pipeline

Succinct’s SP1 Private Proving lets you generate zero‑knowledge proofs inside a hardware Trusted Execution Environment (TEE) so witness data never leaves a sealed enclave while your application still gets a verifiable ZK proof. This guide shows decision‑makers and architects exactly how to plug TEE‑protected inputs into an SP1 proof pipeline with concrete architecture patterns, attestation flows, and operational recommendations.

Summary

Private Proving with SP1 runs your prover inside a TEE (CPU + GPU) so sensitive inputs are kept confidential at silicon level while SP1’s ZK proof preserves verifiability. Below is a production‑ready blueprint for onboarding TEE‑protected witnesses, verifying attestation, and binding the resulting proof to a trusted hardware execution.

Why this matters now

Succinct launched Private Proving: SP1 runs in a TEE so any app can request proofs with hardware‑backed privacy, not just bespoke ZK circuits. It’s built on SP1 zkVM and backed by the Succinct Prover Network. Use cases already include private payments, perp DEXs, identity, and confidential data analytics. (blog.succinct.xyz)
Under the hood, Private Proving runs SP1 inside H200‑class GPU TEEs (CPU TEE + NVIDIA Confidential Computing), enabling privacy at scale without rewriting your code into circuits. (blog.succinct.xyz)
TEE performance overhead for SP1 zkVM on H200 is measured under 20% for complex workloads when the GPU runs in Confidential Computing mode—good enough for rollups, zkEVMs, ZK‑TLS and zkML. (phala.com)

What security guarantees do you actually get?

Confidentiality of inputs during proving (witness privacy): hardware isolation plus memory encryption in the TEE; operator and cloud admins cannot read inputs. On H100/H200, the GPU memory is encrypted and attested; the CPU TEE (Intel TDX/AMD SEV‑SNP or AWS Nitro) isolates the VM. (developer.nvidia.com)
Verifiability of computation: the SP1 proof is still verified onchain/offchain, independent of the TEE. Aggregation/recursion options reduce onchain cost and enable scalable composition. (docs.succinct.xyz)
Platform integrity attestations:
- CPU TEE attestation (e.g., AWS Nitro Enclaves) produces a CBOR/COSE attestation document with PCR measurements (image, kernel, app, IAM role, instance ID, signing cert) signed by AWS Nitro Attestation PKI. (docs.aws.amazon.com)
- GPU attestation (NVIDIA H100/H200) uses device identity certificates (ECC‑384 burned into fuses) and NRAS (NVIDIA Remote Attestation Service) to issue tokens proving the GPU is genuine and in CC mode. (developer.nvidia.com)
- Intel Trust Authority can unify CPU+GPU evidence, so you can verify both TEEs with one policy. (community.intel.com)
Optional “TEE 2FA” integrity signatures for SP1: run the SP1 executor inside a Nitro TEE whose never‑exfiltrated key signs the program’s public outputs and verifying key—handy defense‑in‑depth even if the proving system were compromised. (github.com)

End‑to‑end architecture blueprint

Below is a concrete, field‑tested pipeline you can adapt.

Build your SP1 program

Write the program in Rust (or any LLVM target compiled to RISC‑V) and generate proofs using sp1‑sdk. For heavy pipelines, plan for SP1 aggregation/recursion to amortize onchain verification. (docs.succinct.xyz)

Choose your proving substrate

Option A: Succinct Prover Network with Private Proving enabled (recommended for most teams). You request proofs via the network and let Succinct route to TEE‑equipped clusters. Use the network client (ProverClient) with your private key and RPC URL to submit jobs; reserve capacity for strict SLOs. (docs.succinct.xyz)
Option B: Bring‑your‑own confidential cluster on Phala Cloud (H200/H100 GPU TEE with Intel TDX), getting dual attestation (Intel + NVIDIA) and on‑demand or reserved pricing. (phala.com)
Option C: On‑prem PoC using Intel TDX and SP1 TEE prover examples (e.g., Automata’s Intel TDX PoC). Great for regulated workloads or air‑gapped deployments. (github.com)

Provision TEE with attestation‑gated key access

CPU TEE: if using AWS Nitro Enclaves, configure KMS policies to release decryption keys only to enclaves whose PCRs match your golden image (for example, ImageSha384 or PCR0/1/2). This binds witness decryption to a specific enclave measurement. (docs.aws.amazon.com)
GPU TEE: ensure NVIDIA CC mode is on and NRAS verification is part of your admission control. Validate device certificates via NVIDIA’s CA and OCSP, then challenge the GPU and verify NRAS token claims. (developer.nvidia.com)
Combined: adopt Intel Trust Authority to collect CPU+GPU evidence and enforce joint policies (e.g., “Intel TDX PCRs = X AND GPU CC mode = ON with certified VBIOS”). (community.intel.com)

Witness intake (never leave plaintext outside the TEE)

Client encrypts witness with a KMS key whose policy requires enclave PCRs; only the enclave can decrypt. For Nitro, this is a standard pattern using KMS condition keys bound to attestation document fields. (docs.aws.amazon.com)

Prove inside the TEE

The enclave launches the SP1 prover, decrypts witness inside the TEE, and runs the program. If you adopt SP1 TEE 2FA, the enclave signs public outputs and the verifying key with an enclave‑held key. (github.com)

Export artifacts

Only the SP1 proof, optional TEE signature, and the attestation tokens (CPU + GPU) leave the enclave. Persist the attestation bundle alongside the proof to a tamper‑evident log.

Verification and settlement

Onchain: verify the SP1 proof (optionally aggregated) for low gas (e.g., SP1‑CC keeps verification ~280k gas for contract‑call proofs). (github.com)
Offchain: store or validate the TEE attestation (or a hash/claim subset) to satisfy policy, compliance, or customer audit needs. (docs.aws.amazon.com)

Practical attestation flows you can implement today

A. AWS Nitro Enclaves (CPU TEE) as the trust gate

Enclave requests a COSE‑signed attestation doc from Nitro Hypervisor, including PCRs for the image, kernel, and application, plus parent instance IAM/ID and the signing certificate. Verify against AWS Nitro Attestation PKI and reject debug‑mode enclaves (PCRs all zeros). (docs.aws.amazon.com)
Enforce “decrypt only if PCRs match” using KMS condition keys (e.g., ImageSha384, PCR0). This ensures your witness is decryptable exclusively by the expected enclave image. (docs.bluethroatlabs.com)

Minimal Rust verifier example (receiving an attestation doc as bytes), using a maintained crate from the Veracruz project:

use nitro_enclaves_attestation_document::AttestationDocument;

fn verify_attestation(doc_bytes: &[u8], aws_root_der: &[u8]) -> anyhow::Result<AttestationDocument> {
    let doc = AttestationDocument::authenticate(doc_bytes, aws_root_der)?;
    // check PCRs, nonce, and image hash against policy here
    Ok(doc)
}

This authenticates the COSE/CBOR object against the AWS Nitro root and gives you structured PCRs to compare against your policy. (github.com)

B. NVIDIA H100/H200 (GPU TEE) with NRAS

Retrieve device identity (ECC‑384) and verify against NVIDIA CA; check revocation via OCSP. Use NRAS SDK to attest the GPU and receive a signed JWT (EAT claims) proving CC mode, VBIOS/driver versions, etc. (developer.nvidia.com)
Enforce “GPU must be in CC mode with approved firmware/driver combo.” NVIDIA publishes a Secure AI Compatibility Matrix for supported combinations (firmware, VBIOS, driver). (nvidia.com)

C. One‑shot combined attestation

Intel Trust Authority client collects TDX evidence and calls NRAS for GPU, then returns a single token or a pair you can staple to the proof submission. Your policy engine can require both CPU and GPU claims to pass. (community.intel.com)

Concrete example: Private identity check with SP1 + Nitro + GPU CC

Goal: prove “KYC‑verified” without revealing PII.

Write a Rust program for SP1 to verify a signed credential (e.g., passport/driver’s license signature verification routines in Rust). SP1 lets you do this without custom circuits. (blog.succinct.xyz)
Client encrypts PII with an AWS KMS key bound to Nitro PCRs; enclave fetches and decrypts inside TEE only after attestation passes. (docs.aws.amazon.com)
Prover runs on H200 with GPU CC on Phala Cloud or a comparable stack; NRAS attestation proves GPU is genuine and in CC mode; TDX/Nitro attestation proves CPU TEE integrity. (phala.com)
The enclave produces SP1 proof and optional TEE 2FA signature binding verifying key + outputs; only the proof and a “verified: yes/no” flag are revealed. (github.com)
Onchain: verify the SP1 proof; Offchain: archive attestation tokens for audit.

Performance, capacity, and cost planning

Overhead: Benchmarks show SP1 zkVM in H200 TEE has under‑20% overhead for realistic, long‑running proving jobs (where memory encryption and PCIe encryption cost is amortized). Short bursts see higher TTFT/latency; sustained workloads fare best. (phala.com)
Capacity: H200 provides 141 GB HBM3e and 4.8 TB/s bandwidth—valuable headroom for large witnesses, proof aggregation, and zkML. (phala.com)
Pricing reference (Phala Cloud, as of 2025‑03 to 2025‑12): H200 on‑demand starts around $3.50/GPU/hr; reserved six‑month commitments from $2.56/GPU/hr; enterprise SLAs available. Use these to size your budget vs. throughput. (phala.com)

Deployment options in practice

Succinct Prover Network (recommended default): You configure the network client with SP1_PROVER=network, provide your payment key, and submit proof requests; Private Proving routes your job to TEE provers. Teams needing strict latency/volume can reserve capacity. (docs.succinct.xyz)
Phala Cloud “click‑to‑deploy”: Package your SP1 prover as Docker, choose H200/H100 GPU TEE, and deploy; zero code changes are required to run inside the TEE; you also get dual attestation and public PCCS for quote verification. (phala.com)
On‑prem PoC: Use Intel TDX hosts; adopt the SP1 TEE prover PoC (Automata) to run ELF + stdin in a TDX VM; good for regulated sectors piloting confidential proofs. (github.com)

Binding attestations to proofs: three patterns

Out‑of‑band policy log (simplest)
Store CPU/GPU attestation tokens next to the proof in an append‑only log (e.g., object store with immutability). Your verifiers check both the SP1 proof and the attestation token set for the job ID. (docs.aws.amazon.com)
Signed result envelope (TEE 2FA)
Have the enclave sign: (program hash || verifying key || public outputs || proof commitment). You then verify the SP1 proof and the TEE signature together. If either fails, reject. (github.com)
Attestation‑bound witness keys
Encrypt witness under a key released only to PCR‑matched enclaves; include a hash of the attestation doc (or select claims) as a public input to SP1. This cryptographically ties “who could read the witness” to “what was proved.” (docs.aws.amazon.com)

Best emerging practices (checklist)

Enforce production mode: reject Nitro debug mode (PCRs all zeros). (docs.aws.amazon.com)
Use nonces in attestation requests to prevent replay. (enclaver.io)
Bind KMS policy to image/kernel/app measurements (PCR0/1/2) and, if needed, the parent instance IAM role and instance ID (PCR3/4). (docs.aws.amazon.com)
Validate NVIDIA device cert and NRAS token; ensure CC mode claims + driver/VBIOS versions match your allow‑list (consult the compatibility matrix). (developer.nvidia.com)
Prefer combined attestation verification to reduce operational complexity (Intel Trust Authority). (community.intel.com)
Adopt SP1 proof aggregation to compress multiple proofs for cheaper onchain verification. (docs.succinct.xyz)
Add TEE 2FA signatures for public outputs as a tamper‑evident layer. (github.com)
Keep attestation TTLs short; re‑attest on each job or on rotation events (driver/firmware updates).
Log and hash the attestation claims and proof metadata to a WORM store for audits.
For multi‑tenant privacy, isolate per‑tenant enclaves and keys; rotate KMS keys and enclave images regularly.
Use reserved GPU capacity for steady‑state pipelines; on‑demand for burst proving.
Track firmware/driver updates; re‑baseline PCRs and NRAS policies after upgrades.

Example: SP1‑CC + TEE for cheap onchain consumption

If you’re proving EVM calls offchain and verifying onchain, SP1‑CC keeps verification around 280k gas. Combining SP1‑CC with Private Proving gives you confidentiality on the inputs (TEE) plus verifiability (ZK), so the chain never sees secrets and still trusts the result. (github.com)

Pipeline:

Offchain: decrypt sensitive calldata in TEE, execute the EVM call in SP1‑CC, generate proof.
Onchain: verify the SP1 proof; store a minimal attestation reference (hash) offchain for compliance.

Governance, compliance, and vendor risk

Private Proving is production‑ready per Succinct; maintain an attestation/audit trail per proof request for SOC2/GDPR evidence. (blog.succinct.xyz)
If you’re renting TEEs, prefer providers that offer dual attestation (Intel + NVIDIA) and documented compliance posture. Phala Cloud publishes pricing, regions, and says it provides audit‑friendly dual attestation. (phala.com)
Understand SP1’s security model: it proves correct execution of your program; you remain responsible for program safety and memory safety. (docs.succinct.xyz)

What to roadmap next

Real‑time proving: SP1 Hypercube targets sub‑12s proofs for most Ethereum blocks—plan your UX around near‑real‑time confirmation as this matures. (blog.succinct.xyz)
Decentralized proving: the Succinct Prover Network handles scale and provides a market for performance; for critical workloads, reserve capacity. (docs.succinct.xyz)

Implementation runbook (condensed)

Choose substrate: Succinct Private Proving or Phala Cloud/own TDX cluster. (blog.succinct.xyz)
Establish policies: golden PCRs, allow‑listed GPU firmware/driver, CPU+GPU combined attestation policy. (community.intel.com)
Wire attestation:
- Nitro: parse COSE/CBOR attestation docs and verify against AWS Nitro root. (docs.aws.amazon.com)
- NVIDIA: pull device cert, run NRAS attestation, verify JWT claims. (docs.nvidia.com)
Bind KMS: require matching PCRs to release the witness decryption key. (docs.aws.amazon.com)
Prove with SP1: run prover inside TEE; enable proof aggregation for batch jobs. (docs.succinct.xyz)
Export: SP1 proof + TEE 2FA signature + attestation tokens; archive to WORM. (github.com)
Verify: onchain SP1 verify; offchain attestation policy check. (docs.succinct.xyz)
Operate: monitor firmware/driver updates; rotate images and keys; re‑baseline PCRs; track GPU CC mode.

How 7Block Labs can help

Architecture and policy design: we’ll define your PCR/NRAS allow‑list, KMS bindings, and combined attestation policies.
Build + run: we package your SP1 programs, deploy TEEs, integrate Prover Network, and wire proof aggregation.
Compliance: we instrument immutable proof/attestation logs and design retention/sealing workflows aligned to your obligations.

Key references

Succinct Private Proving overview and readiness. (blog.succinct.xyz)
SP1 proof aggregation docs. (docs.succinct.xyz)
SP1‑CC verification cost guidance. (github.com)
SP1 security model. (docs.succinct.xyz)
Nitro attestation (PCRs, CBOR/COSE, PKI). (docs.aws.amazon.com)
NVIDIA CC and attestation (NRAS, device identity). (developer.nvidia.com)
Intel Trust Authority for combined CPU+GPU attestation. (community.intel.com)
H200 TEE capacity and pricing; dual attestation. (phala.com)
SP1 TEE integrity signatures (“TEE 2FA”). (github.com)
On‑prem PoC: SP1 TDX prover. (github.com)

With this blueprint, your team can keep sensitive inputs private in a TEE while still publishing an SP1 proof that anyone can verify—delivering both confidentiality and trust without forcing a rewrite into custom circuits.