Private Inputs, Public Guarantees: A Clean Architecture for TEE‑Proved ZK Apps

A practical blueprint for combining trusted execution environments (TEEs) with zero‑knowledge (ZK) proofs so startups and enterprises can ingest sensitive data privately while publishing verifiable guarantees on-chain, with concrete designs, cost models, and emerging best practices.
This guide shows how to deploy today on AWS Nitro, Intel TDX, AMD SEV‑SNP, and Arm CCA Realms, and how to settle proofs efficiently on Ethereum/L2s or modular proof‑verification layers.

Why read this now

Cloud TEEs are production‑ready across providers: Confidential VMs with Intel TDX and AMD SEV‑SNP are GA or broadly available on Google Cloud; attestation is consumable via first‑party services. (docs.cloud.google.com)
AWS Nitro Enclaves provide signed attestation documents and direct KMS policy gating on PCRs/Image measurements, enabling sealed key release tied to enclave identity. (docs.aws.amazon.com)
Vendor‑neutral attestation brokers like Intel Trust Authority now issue JWT tokens and even attest their own services with “Faithful Verification,” simplifying multi‑cloud appraisal. (docs.trustauthority.intel.com)
On-chain verification is cheaper and more flexible post‑Dencun (EIP‑4844 blobs for rollups) and with BN254 precompiles (EIP‑1108) for Groth16. (blog.ethereum.org)
Modular verification layers (e.g., zkVerify) and proof aggregation frameworks (e.g., Nebra UPA) slash settlement costs and open multi‑proof workflows. (chainwire.org)

Executive summary for decision‑makers

TEE‑proved ZK apps are systems where:

Private inputs are ingested and computed inside a remotely attested TEE.
A succinct proof of the outcome (plus proof that the computation was performed by an approved enclave/VM image at an acceptable TCB) is published and cheaply verified on-chain.

Adopting this pattern lets you:

Hold sensitive inputs off‑chain, including regulated PII/PHI or proprietary models.
Publish public guarantees (policy checks, threshold attestations, compliance states) without leaking inputs.
Meet auditors in the middle: attestation for runtime integrity, ZK for minimal disclosure.

The clean architecture: five layers

1) Private Input Ingress (TEE runtime)

Choose a TEE runtime matched to your operational environment and supply chain:

AWS Nitro Enclaves: Spawn isolated enclaves off your EC2 instance with no external networking; retrieve signed attestation documents (CBOR/COSE) from the Nitro Hypervisor. (docs.aws.amazon.com)
Confidential VMs on GCP:
- Intel TDX (C3) GA; AMD SEV‑SNP GA on N2D; attestation reports and release notes detail live mitigations and TCB versions. (docs.cloud.google.com)
Multi‑vendor, neutral appraisal via Intel Trust Authority across TDX/SGX/TPM (and preview support for SEV‑SNP/GPU), returning a signed JWT attestation token. (docs.trustauthority.intel.com)
Arm CCA Realms (RME): for Armv9 deployments, run workloads in “Realm world” with attestation flows defined by the CCA stack. (arm.com)

Design tips:

Pin exact measurements (PCR0/Image digest in Nitro; MRSIGNER/MRENCLAVE in SGX; TCB SVN/FMSPC/measurement fields for TDX/SEV‑SNP) and require non‑debug builds. (docs.aws.amazon.com)
Define per‑environment allowlists (staging vs prod) to avoid brittle single‑hash policies during rollouts.

2) Attestation & Policy Gate

Treat attestation as your policy‑enforcement API:

On AWS, attach Nitro Enclaves attestation to KMS operations; enforce kms:RecipientAttestation conditions on PCRs and ImageSha384 so the enclave can only decrypt keys if its measurements match. This ties secrets to code identity at runtime. (docs.aws.amazon.com)
Intel Trust Authority flow: workload captures quote, ITA returns a JWT attestation token; pass that to a Key Broker Service for controlled key release based on token claims (incl. attester_held_data). (docs.trustauthority.intel.com)
For GCP/Azure CVMs, incorporate provider security bulletins and TCB minimums into your policy (e.g., AMD SEV‑SNP minimum SNP TCB SVN per GCP advisory), and verify TCB values in every request. (docs.cloud.google.com)

Outcome: the TEE can unlock private inputs, model weights, or per‑session decryption keys only if its measured state, platform TCB, and IAM context satisfy policy.

3) Proving Engine

Two core patterns are in production today:

ZK wrapper over TEE attestation (zk‑attested TEEs)
- Verify TEE attestation (JWT/COSE) within a zkVM (SP1, RISC Zero) or custom circuit, then emit a succinct proof that “this output was computed by a TEE with acceptable measurements and policies.” This avoids on‑chain re‑implementations of vendor‑specific attestation verifiers while keeping the guarantee public and portable. Recent integrations can verify SP1/RISC Zero proofs directly on specialized layers to skip Groth16 conversion. (chainwire.org)
TEE‑accelerated proving with privacy
- Generate the ZK proof inside the TEE so the full witness (private data) never leaves the enclave, then publish only the succinct proof. Research and vendor efforts continue to speed up MSM/NTT (e.g., FPGA acceleration for BN254/BLS12‑381). (arxiv.org)

Engineering note:

When wrapping attestation, keep circuits small. Rather than parsing full X.509 chains and OEM roots in‑circuit, verify those off‑chain inside the TEE, then bind the result to attester_held_data (or Nitro PCRs) whose exact bytes are verified in‑circuit. That keeps your ZK footprint predictable while preserving end‑to‑end soundness via attestation semantics. (docs.trustauthority.intel.com)

4) Settlement & Verification

You have three pragmatic options for turning proofs into public guarantees:

Ethereum L1/L2 with Groth16 on BN254
- Post‑Istanbul EIP‑1108 rates make Groth16 checks affordable: pairing precompile priced at ~45k + 34k per pairing operation; total verify cost ≈ 181k gas + ~6–7k gas per public input in typical contracts. (eips.ethereum.org)
- Dencun (EIP‑4844) reduced L2 DA costs via blobs, catalyzing L2‑based proof workflows and batched settlement. (blog.ethereum.org)
Aggregation frameworks
- Use UPA‑style aggregation to cut per‑proof gas to ~40–60k on L1/L2 when batching 32+ proofs, with cheap inclusion queries. (docs.nebra.one)
Modular proof‑verification layers
- Offload verification to a dedicated chain (e.g., zkVerify), which reports a succinct result to your target L1/L2; public estimates/announcements cite up to ~90%+ cost reduction and native support for multiple zkVMs. (chainwire.org)

Pick the lane that matches your users’ trust and fee budgets: L1 for maximum finality, L2 for UX/fees, or modular for proof‑dense apps.

5) Monitoring, Rotation, and IR

Track TCB cycles and CVEs; bake minimal acceptable TCBs into your policies. AMD SEV‑SNP and Intel SGX/TDX see periodic recoveries and advisories—policies should fail‑safe and require upgrades. (intel.com)
Continuously audit proofs: alert on stale attestations, debug‑mode enclaves, or unexpected PCRs.
Practice “hot‑swap” deploys with rolling allowlists (old+new measurements) and explicit expiry windows in KMS/attestation policies so you never brick production during upgrades. (docs.aws.amazon.com)

Two end‑to‑end example designs (with precise components)

Example A — Confidential AI inference with public compliance guarantees

Goal: Let customers send private inputs to a model, get an inference, and publish on‑chain evidence that “the inference was computed by the approved model version in a confidential environment; policy X was enforced.”

Architecture:

Runtime: Confidential VM (Intel TDX on GCP C3) or AWS Nitro Enclave. Attest, then fetch the decryption key for the model only if the attestation token satisfies policy. (docs.cloud.google.com)
Policy: Intel Trust Authority appraises the quote and returns a JWT; KBS releases the model key if claims (measurement, TCB, attester_held_data) pass. Nitro path uses KMS with kms:RecipientAttestation. (docs.trustauthority.intel.com)
Proving: The enclave runs inference and computes a commitment to the output plus policy checks (e.g., “model hash = H, TCB ≥ v, policy flag = true”) and then uses SP1/RISC Zero to produce a portable proof attesting to these facts; verification is offloaded to a modular verifier (zkVerify) or an L2 contract, then bridged to L1 as needed. (chainwire.org)
Public state: The on‑chain contract records (output commitment, model version, time) based on a verified proof; the private prediction is shared off‑chain to the user.

Why it works:

Private inputs never leave the TEE.
Public can verify that the approved model and minimum TCB produced the result—without learning the input.

Example B — KYC/Proof‑of‑funds with zkTLS and TEEs

Goal: Prove “balance ≥ threshold” or “OFAC screening passed” without revealing account details, and without requiring the bank to run custom software.

Architecture:

Data acquisition: A zkTLS engine (DECO/TLSNotary‑style) captures a TLS session transcript from the bank website and constructs a zk‑SNARK that the response contains the target value under a valid certificate, with no other content revealed. (blog.chain.link)
Secrets handling: OAuth tokens or session cookies live only inside a Nitro Enclave; KMS policies require enclave PCRs to match; the enclave requests short‑lived data keys tied to its current measurement. (docs.aws.amazon.com)
Settlement: Publish only the ZK proof plus a short policy digest to L2; verify via Groth16 on BN254 or aggregate many proofs into a super‑proof for cheaper settlement. (eips.ethereum.org)

Why it works:

No server‑side changes at the bank (zkTLS preserves normal HTTPS).
The app never touches raw credentials outside the enclave.
On‑chain consumers get a durable, minimal disclosure proof.

Implementation details that save months

Encoding formats to expect
- AWS Nitro attestation is CBOR/COSE‑signed; pin the Nitro CA and parse PCRs (ImageSha384 → PCR0). Intel Trust Authority returns a JWT with claims about TCB, measurement, and attester_held_data. (docs.aws.amazon.com)
How to bind attestation to computation
- Put a content‑addressed hash of your computation transcript (inputs/outputs/params) in attester_held_data (TDX/SGX) or a custom PCR (Nitro). Your ZK circuit only needs to check equality of these bytes and a small set of policy bits.
Key release policies (Nitro KMS)
- Use kms:RecipientAttestation:ImageSha384 (PCR0) and specific PCR indices with StringEqualsIgnoreCase. Deny if Recipient is missing or PCRs don’t match. (docs.aws.amazon.com)
Gas budgeting for Groth16 verification (Ethereum)
- Baseline pairing: ~45k + 34k·k; Groth16 usually uses 4 pairings → ~181k gas fixed, plus ~6–7k gas per public input due to ECADD/ECMUL and calldata. Plan ≈ 200–230k gas typical. (eips.ethereum.org)
Aggregation to amortize fees
- With UPA‑style batching (N=32), per‑proof cost is often ~40–60k gas on L1/L2; inclusion queries ~16–22k gas. (docs.nebra.one)
Alternative settlement
- Dedicated proof‑verification layers can accept SP1/RISC Zero receipts directly, cut costs ~90%+, and return a succinct attestation (log/event/state) your L1/L2 contracts consume. (chainwire.org)

Security notes you should not skip

Track TCB recoveries and force upgrades:
- Intel SGX/TDX TCB recovery cycles began March 2024; plan for scheduled enforcement. (intel.com)
- GCP bulletins specify minimum SNP TCB SVN and mitigation versions for SEV‑SNP; bake these numbers into policy and reject stale attestation. (docs.cloud.google.com)
Don’t verify “debug mode” attestations: Nitro explicitly zeros PCRs in debug; reject them categorically. (docs.aws.amazon.com)
Heterogeneous trust:
- Prefer a vendor‑neutral verifier (Intel Trust Authority) so your app logic is stable as you move between clouds and CPU vendors; compose evidence across TDX/TPM/GPU as needed. (docs.trustauthority.intel.com)
ZK correctness and circuit hygiene:
- Underconstrained circuits happen; incorporate static analyzers/fuzzers into CI (e.g., academic work shows measurable bug finds in Circom/Halo2 pipelines). Do not rely on a single zkVM version without tracking advisories. (arxiv.org)

Clean architecture reference diagram (text)

Ingress (TEE): Nitro/TDX/SEV‑SNP/Arm Realm
- Attestation → Attestation Broker (Intel Trust Authority) or KMS (Nitro)
- Key release → decrypt private inputs/model
Proving:
- Compute result + policy digest inside TEE
- Generate ZK proof (inside TEE or outside on encrypted witness)
- Optional: TEE‑attestation wrapper proof in SP1/RISC Zero
Settlement:
- Aggregate proofs (UPA) or submit to zkVerify, or verify Groth16 on L2/L1
- Emit on‑chain event/state → “public guarantee”
Observability:
- Log attestation claims, TCB versions; alarm on drift; rotate allowlists

Best emerging practices

Make TEEs ephemeral, proofs durable
- Use short‑lived enclaves/TDs that produce long‑lived, portable ZK receipts. Treat attestation as a freshness check, the ZK receipt as a permanent audit artifact.
Use policy‑driven key release
- Tie secrets to both measurement and TCB version; be explicit about acceptable platform versions (e.g., “SNP TCB SVN ≥ 0x18 0d24”). (docs.cloud.google.com)
Keep circuits small; push heavy parsing into the TEE
- Verify vendor cert chains/CRLs inside the enclave; export only a compact claim set hashed into attester_held_data for the ZK circuit to check. (docs.trustauthority.intel.com)
Settle where it’s cheapest for your audience
- For consumer UX, verify on L2 and anchor to L1 periodically; for proof‑heavy workloads, offload verification to a modular layer and consume the result cross‑chain. (chainwire.org)
Bring your own crypto agility
- BN254 is cheapest on EVM today (EIP‑1108), but keep an abstraction layer to shift to BLS12‑381/IPA or STARK receipts as your target chain’s precompiles and tooling evolve. (eips.ethereum.org)

A 90‑day rollout plan

Weeks 1–2: Select your TEE target(s). On AWS, prototype a Nitro Enclave; on GCP, spin a TDX CVM; wire up attestation capture. (docs.aws.amazon.com)
Weeks 3–5: Implement policy‑gated key release:
- AWS: attach kms:RecipientAttestation policies to permit Decrypt/GenerateDataKey only for your enclave image (PCR0) and IAM role. (docs.aws.amazon.com)
- Multi‑cloud: integrate Intel Trust Authority; propagate JWT tokens to your KBS. (docs.trustauthority.intel.com)
Weeks 6–8: Build the ZK wrapper:
- Encode a compact claim vector (measurement hash, TCB OK flag, policy ID, output commitment).
- Implement a Groth16 verifier on your target chain; measure gas. (eips.ethereum.org)
Weeks 9–10: Add aggregation or modular verification for cost reduction (UPA or zkVerify). (docs.nebra.one)
Weeks 11–13: Hardening
- Enforce minimum TCBs (per GCP/AMD bulletins) and schedule upgrades around vendor recovery windows (Intel). (docs.cloud.google.com)
- Add circuit analyzers/fuzzers to CI; add alarms for debug attestations/PCR drift. (arxiv.org)

FAQs we hear from leadership

How do we avoid vendor lock‑in?
- Normalize to an attestation broker (Intel Trust Authority) and to a ZK receipt format your target chain verifies cheaply; that lets you move between Nitro, TDX, SEV‑SNP, or Arm Realms with policy changes rather than code changes. (docs.trustauthority.intel.com)
What’s the steady‑state on fees?
- With EIP‑1108 pricing, single Groth16 verifications (few public inputs) are ≈200–230k gas; with aggregation or a modular verification layer, you can get to ~40–60k gas per proof equivalent, with large batches reducing amortized cost further. (eips.ethereum.org)
Can we do this without the data source’s cooperation?
- For many web sources, yes—zkTLS approaches (e.g., DECO/TLSNotary) require no server changes; for enterprise systems, a TEE agent can also fetch and attest to private data under corporate policy. (blog.chain.link)

Where 7Block Labs can help

Platform selection and threat modeling for your vertical (finance, health, AI).
KMS/attestation policy engineering and audits.
ZK circuit design with gas‑aware verification, aggregation, and modular settlement.
Incident‑response playbooks mapped to vendor TCB cycles.

If you want a reference implementation that’s production‑grade in 6–8 weeks, we’ll bring the scaffolding (Nitro/TDX samples, KMS/ITA policies, Groth16 verifier contracts, aggregation or zkVerify integration) and tailor it to your compliance and product needs.

References and source notes

AWS Nitro Enclaves attestation and KMS condition keys (PCR/ImageSha384): docs and prescriptive guidance. (docs.aws.amazon.com)
Google Cloud Confidential VMs (Intel TDX/AMD SEV‑SNP): GA/notes; TCB SVN guidance. (docs.cloud.google.com)
Intel Trust Authority: multi‑tech attestation, JWT tokens, Faithful Verification. (docs.trustauthority.intel.com)
Ethereum Dencun (EIP‑4844) and EIP‑1108 gas schedule: official references/explanations. (blog.ethereum.org)
zkTLS landscape (DECO/TLSNotary) and events: current docs. (blog.chain.link)
Modular verification (zkVerify) and proof aggregation (UPA): cost reduction approaches. (chainwire.org)
TEE advisories/TCB recoveries: Intel/AMD/GCP bulletins. (intel.com)
Arm CCA Realms (RME) documentation and learning paths. (arm.com)