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

A Practical Blueprint for Combining TEEs with ZK Proofs

This guide provides a hands-on approach to merging trusted execution environments (TEEs) with zero-knowledge (ZK) proofs. It’s designed for startups and enterprises that want to handle sensitive data privately while still offering verifiable guarantees on-chain. You’ll find concrete designs, cost models, and some of the latest best practices.

Getting Started

We’ll walk you through deploying on popular platforms like AWS Nitro, Intel TDX, AMD SEV-SNP, and Arm CCA Realms. Plus, we’ll cover how to efficiently settle proofs on Ethereum/L2s or modular proof-verification layers.

Let’s dive in!

Why read this now

• Cloud TEEs are good to go with multiple providers now: Confidential VMs using Intel TDX and AMD SEV‑SNP are generally available on Google Cloud, and you can easily access attestation through first-party services. Check it out here: (docs.cloud.google.com).
• AWS Nitro Enclaves come packed with signed attestation documents and a handy direct KMS policy gating on PCRs/Image measurements. This lets you tie sealed key releases directly to enclave identities. More details can be found here: (docs.aws.amazon.com).
• If you're into vendor-neutral attestation brokers, check out Intel Trust Authority. They're now issuing JWT tokens and even verifying their own services with something called “Faithful Verification,” which makes multi-cloud evaluations a lot easier. Find out more at: (docs.trustauthority.intel.com).
• On-chain verification has gotten a lot cheaper and more flexible after Dencun, thanks to EIP‑4844 blobs for rollups and BN254 precompiles (EIP‑1108) for Groth16. Dive deeper into this topic here: (blog.ethereum.org).
• Modular verification layers like zkVerify and proof aggregation frameworks such as Nebra UPA slash those pesky settlement costs and open up the door to multi-proof workflows. Check it out: (chainwire.org).

---

Executive summary for decision‑makers

TEE-proved ZK apps are basically systems that work like this:

• They take in private inputs and handle computations within a remotely verified Trusted Execution Environment (TEE).
• After that, they generate a compact proof of the result (along with proof that all the calculations were done by an authorized enclave or VM image that's part of a trusted computing base) and publish it on-chain for easy verification.

By following this pattern, you can:

• Keep sensitive data off the chain--this includes things like regulated PII/PHI or your proprietary models.
• Share public guarantees (like policy checks, threshold attestations, and compliance states) without exposing any sensitive inputs.
• Find a balance that works for auditors: you get runtime integrity through attestation, and use ZK for minimal disclosure.

---

The clean architecture: five layers

1) Private Input Ingress (TEE runtime)

Selecting the Right TEE Runtime for Your Environment and Supply Chain

When it comes to picking a TEE (Trusted Execution Environment) runtime, it’s super important to find one that fits well with your specific operational setup and supply chain needs. Here are some key factors to keep in mind:

1. Compatibility: Make sure the TEE runtime you choose is compatible with your hardware and software stack. Each environment has its own quirks, so check that everything will work seamlessly together.
2. Performance: Different TEEs have varying levels of performance. Depending on the kind of tasks you need to run, some runtimes might work better than others. Look into benchmarks and real-world use cases.
3. Security Features: Security is key. Check out the security features that each TEE offers. Some might provide stronger isolation, while others may have added layers of encryption or integrity checks.
4. Ease of Integration: Think about how easy it is to integrate the TEE runtime into your existing systems. A runtime that plays well with your current architecture will save you time and headaches in the long run.
5. Support and Community: A robust support system and an active community can make a huge difference when you run into issues. Look for runtimes that have good documentation and community resources.
6. Cost: Finally, consider the costs associated with each TEE option. Factor in licensing fees, development costs, and potential costs for support or maintenance.

Take the time to evaluate each of these aspects to ensure you choose a TEE runtime that not only meets your operational requirements but also harmonizes with your supply chain strategy. Happy selecting!

• AWS Nitro Enclaves: You can create isolated enclaves straight off your EC2 instance without any external networking. Plus, you can grab signed attestation documents (CBOR/COSE) right from the Nitro Hypervisor. Check it out here.
• Confidential VMs on GCP:
  • Intel TDX (C3) is now generally available! Also, AMD SEV-SNP is live on N2D. Their attestation reports and release notes offer details on live mitigations and TCB versions. Dive deeper here.
• Multi-vendor, neutral appraisal: With Intel Trust Authority, you can get a signed JWT attestation token across TDX/SGX/TPM, and preview support for SEV-SNP/GPU is also on board. You can learn more here.
• Arm CCA Realms (RME): For those using Armv9, you can run your workloads in the “Realm world,” with attestation flows that are all defined by the CCA stack. Find out more about it here.

Design Tips:

• Make sure to pin down the exact measurements--like PCR0/Image digest in Nitro, MRSIGNER/MRENCLAVE in SGX, and TCB SVN/FMSPC/measurement fields for TDX/SEV‑SNP--and always go for non-debug builds. Check out the details here.
• Set up environment-specific allowlists (think staging vs. production) to steer clear of those pesky brittle single-hash policies when you're rolling things out.

2) Attestation & Policy Gate

Treat attestation as your policy-enforcement API:

Attestation can be viewed as your go-to API for enforcing policies. It's a powerful tool that helps ensure that your systems are operating within the guidelines you've set. Here's how to make the most of it:

• When you're working on AWS, you should definitely attach Nitro Enclaves attestation to your KMS operations. Make sure to enforce the kms:RecipientAttestation conditions on PCRs and ImageSha384, so your enclave can only decrypt keys if its measurements are on point. This way, you’re tying secrets to the code's identity while it’s running. Check out the details here.
• With the Intel Trust Authority flow, your workload captures a quote, and the ITA sends back a JWT attestation token. You can then pass that token to a Key Broker Service to control key release based on the token claims (including attester_held_data). It’s pretty streamlined! Learn more about it here.
• For GCP and Azure Confidential VMs, it’s a good idea to fold in provider security bulletins and keep those TCB minimums in mind for your policy. For instance, adhere to the AMD SEV‑SNP minimum SNP TCB SVN as highlighted in the GCP advisory, and remember to verify TCB values with every request. For more info, head over here.

Outcome: the TEE can only access private inputs, model weights, or per-session decryption keys when its measured state, platform TCB, and IAM context meet the required policy criteria.

3) Proving Engine

Two main patterns are making waves in production today:

• ZK Wrapper over TEE Attestation (zk-attested TEEs)
  • You can verify TEE attestation (JWT/COSE) right within a zkVM (like SP1, RISC Zero) or a custom circuit. From there, it emits a neat proof saying, “this output was computed by a TEE with acceptable measurements and policies.” This approach helps you steer clear of on-chain re-implementations of vendor-specific attestation verifiers, while still ensuring that the guarantee remains public and portable. The latest integrations can check SP1/RISC Zero proofs straight on specialized layers, allowing you to bypass Groth16 conversion. (chainwire.org)
• TEE-accelerated Proving with Privacy
  • Here’s the deal: you generate the ZK proof inside the TEE, so the complete witness (that’s the private data) never has to leave the enclave. You only end up publishing the succinct proof. Meanwhile, research and vendor efforts are cranking up to speed up MSM/NTT (think FPGA acceleration for BN254/BLS12-381). (arxiv.org)

Engineering Note

• When you're wrapping attestation, try to keep those circuits nice and small. Instead of diving into full X.509 chains and OEM roots in‑circuit, it’s easier to handle the verification off‑chain inside the TEE. You can then link that result to attester_held_data (or Nitro PCRs) and verify the exact bytes in‑circuit. This way, you can keep your ZK footprint manageable while still ensuring everything is sound from end to end through attestation semantics. Check out more details here.

4) Settlement & Verification

You’ve got three practical ways to transform proofs into public guarantees:

• Ethereum L1/L2 with Groth16 on BN254
  • Thanks to the post-Istanbul EIP‑1108 changes, Groth16 checks have become a lot more wallet-friendly. We're talking about pairing precompile costs sitting around ~45k, plus an additional 34k for each pairing operation. So, the total verify cost shakes out to about 181k gas, plus roughly 6-7k gas for each public input in typical contracts. You can dive deeper into the details on the EIP-1108 page.
  • The Dencun upgrade (EIP‑4844) has really helped bring down L2 data availability (DA) costs through blobs. This change is giving a boost to L2-based proof workflows and making batched settlements way more efficient. Check out the full scoop on the Ethereum Blog.
• Aggregation frameworks
  • By employing UPA-style aggregation, you can slash the per-proof gas costs to about ~40-60k on L1/L2 when you batch together 32 or more proofs. Plus, inclusion queries are super cheap! If you're curious about the nitty-gritty, take a look at the details on Nebra's docs.
• Modular proof-verification layers
  • Consider offloading the verification process to a special chain like zkVerify. It sends back a concise result to your target L1/L2, and public estimates suggest you could see a cost reduction of up to 90% or more. Bonus: it natively supports multiple zkVMs! For more information, check out this article from Chainwire.

Choose the lane that fits your users' trust levels and budget for fees: go with L1 if you want maximum finality, L2 if you’re focusing on user experience and lower fees, or opt for modular if you're building proof-dense applications.

5) Monitoring, Rotation, and IR

• Keep an eye on TCB cycles and CVEs, and make sure you're incorporating minimal acceptable TCBs into your policies. Both AMD SEV‑SNP and Intel SGX/TDX have their ups and downs with periodic recoveries and advisories--so your policies need to have a fail-safe approach and require timely upgrades. (intel.com)
• Regularly audit your proofs: set up alerts for stale attestations, debug-mode enclaves, or any unexpected PCRs.
• Get comfortable with “hot-swap” deployments using rolling allowlists (think of having both old and new measurements) and clearly defined expiry windows in your KMS/attestation policies. This way, you can prevent any mishaps in production during upgrades. (docs.aws.amazon.com)

---

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

Confidential AI inference with public compliance guarantees

Goal

Our aim is to allow customers to securely send private inputs to a model, receive an inference, and then publish on-chain evidence that confirms: “the inference was computed by the approved model version in a confidential environment; policy X was enforced.”

Architecture:

• Runtime: We're using either a Confidential VM (Intel TDX on GCP C3) or AWS Nitro Enclave. First up, we need to attest before grabbing the decryption key for the model--only if that attestation token checks out with the policy. You can find more on this here.
• Policy: The Intel Trust Authority comes into play by assessing the quote and spitting out a JWT. The KBS will let go of the model key if certain claims (like measurement, TCB, attester_held_data) make the grade. On the Nitro path, we’re utilizing KMS with kms:RecipientAttestation. Check out the details here.
• Proving: Inside the enclave, we’re running inference and calculating a commitment to the output along with a few policy checks (like “model hash = H, TCB ≥ v, policy flag = true”). Then, we use SP1/RISC Zero to whip up a portable proof that backs up these claims. For verification, that’s handed off to a modular verifier (zkVerify) or an L2 contract, and we bridge it to L1 if necessary. More info can be found here.
• Public state: The on-chain contract logs (output commitment, model version, time) based on a verified proof. And just so you know, the private prediction is sent off-chain to the user.

Why it Works

• Your private data stays secure inside the TEE and never leaves.
• The public can check that the approved model and the minimum TCB generated the result, all without seeing the input data.

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.

To achieve this goal, we need a way to confirm that an account meets the necessary criteria without diving into sensitive details or asking the bank to do extra work. Here’s a breakdown of how we might handle this:

1. Use of Aggregated Data

Instead of revealing specifics about individual accounts, we can rely on aggregated data. By showing a summary of account statuses, we can demonstrate that a certain percentage of accounts meet the specified balance or screening criteria.

2. Zero-Knowledge Proofs

Implementing zero-knowledge proofs can be a game changer. This tech allows us to prove a statement (like “the balance is above a certain threshold”) without giving away any actual data. It’s all about confirming the validity while keeping the specifics under wraps.

3. Third-Party Verification

Engaging a reputable third-party service could help us validate the required conditions. These services can perform the necessary checks and provide proof of compliance without sharing account details with us or requiring the bank to adapt their systems.

4. Secure Hashing

We could hash account information to create a unique identifier that doesn’t share actual numbers. Then, we can run checks against this hashed version, proving it meets the threshold or passed screening without ever exposing the actual data.

In Conclusion

By using these strategies, we can successfully prove compliance with “balance ≥ threshold” or “OFAC screening passed” without compromising sensitive account information or burdening the bank with custom software requirements.

Architecture:

• Data acquisition: We kick things off with a zkTLS engine (think DECO/TLSNotary style) that grabs a TLS session transcript straight from the bank's website. This nifty tool then builds a zk‑SNARK, which shows that the response holds the target value under a legit certificate without giving away any other details. Check it out here: blog.chain.link.
• Secrets handling: When it comes to handling secrets, OAuth tokens or session cookies are kept safely tucked away inside a Nitro Enclave. KMS policies ensure that the enclave’s PCRs line up perfectly, and the enclave will request short-lived data keys that are linked to its current measurement. For more info, visit: docs.aws.amazon.com.
• Settlement: For the settlement process, we only need to publish the ZK proof along with a quick policy digest to L2. Verification can be done using Groth16 on BN254, or if we’ve got a bunch of proofs, we can aggregate them into a super-proof, which makes settlement a lot cheaper. Take a look at this for details: eips.ethereum.org.

Why it works:

• There’s no need for any server-side changes at the bank since zkTLS keeps everything running smoothly with regular HTTPS.
• The app doesn’t handle raw credentials outside of the secure enclave, keeping things safe and sound.
• On-chain consumers receive a solid, minimal disclosure proof that lasts.

---

Implementation details that save months

• Encoding formats to expect
  • When it comes to AWS Nitro attestation, you're looking at a CBOR/COSE-signed format. Make sure to pin the Nitro CA and parse PCRs (specifically, ImageSha384 to PCR0). The Intel Trust Authority will give back a JWT with claims about TCB, measurement, and attester_held_data. You can check it out in detail here.
• How to bind attestation to computation
  • To link attestation with your computations, just stash a content-addressed hash of your computation transcript (that includes inputs, outputs, and parameters) in attester_held_data (if you're using TDX/SGX) or a custom PCR (for Nitro). Your ZK circuit only needs to do a basic equality check on these bytes along with a small number of policy bits.
• Key release policies (Nitro KMS)
  • For key release policies, go with kms:RecipientAttestation:ImageSha384 (PCR0) and the specific PCR indices using StringEqualsIgnoreCase. If the Recipient is missing or the PCRs don’t match, you’ll want to deny access. You can read more about this here.
• Gas budgeting for Groth16 verification (Ethereum)
  • When budgeting gas for Groth16 verification, a good baseline is around ~45k plus 34k multiplied by k. Typically, Groth16 will need about 4 pairings, bringing it to around ~181k gas as a fixed cost, plus an additional ~6-7k gas for each public input due to ECADD/ECMUL and calldata. So, plan for roughly 200-230k gas on average. More details can be found here.
• Aggregation to amortize fees
  • If you go for UPA-style batching (with N=32), the cost per proof is generally around ~40-60k gas on L1/L2, and inclusion queries will be roughly ~16-22k gas. For further insights, check out this guide.
• Alternative settlement
  • There are dedicated proof-verification layers that can take SP1/RISC Zero receipts directly, which can cut costs by more than 90% and provide a succinct attestation (log/event/state) that your L1/L2 contracts can then use. You can find more about this here.

---

Security notes you should not skip

• Keep an eye on TCB recoveries and force upgrades:
  • The Intel SGX/TDX TCB recovery cycles kicked off in March 2024, so let’s make sure we’re prepared for scheduled enforcement. Check out the details here.
  • GCP bulletins outline the minimum SNP TCB SVN and mitigation versions for SEV‑SNP; be sure to integrate these figures into your policy and reject any outdated attestations. You can find more info here.
• Avoid verifying “debug mode” attestations: Nitro wipes PCRs in debug mode, so it’s best to reject these outright. More details can be found here.
• Heterogeneous trust:
  • It’s a good idea to use a vendor-neutral verifier like Intel Trust Authority. This way, your app logic remains stable as you switch between clouds and CPU vendors; remember to compile evidence from TDX/TPM/GPU as necessary. Check it out here.
• ZK correctness and circuit hygiene:
  • Underconstrained circuits can crop up; incorporate static analyzers and fuzzers into your CI process. Academic research shows that this can lead to noticeable bug detection in Circom/Halo2 pipelines. And don’t just stick to a single zkVM version--make sure you’re keeping track of advisories. Read more about it here.

---

Clean architecture reference diagram (text)

• Ingress (TEE): Nitro/TDX/SEV‑SNP/Arm Realm
  • Attestation → Use either the Attestation Broker (Intel Trust Authority) or KMS (Nitro)
  • Key release → This is where we decrypt private inputs or the model
• Proving:
  • We compute the result along with the policy digest inside the TEE
  • Generate a ZK proof, which can happen either inside the TEE or outside on an encrypted witness
  • Optional: Add a TEE‑attestation wrapper proof using SP1/RISC Zero
• Settlement:
  • Aggregate proofs (UPA) or submit them to zkVerify, or just verify Groth16 on L2/L1
  • Emit an on-chain event/state for that “public guarantee”
• Observability:
  • Keep track of attestation claims and TCB versions, set alarms for any drift, and remember to rotate those allowlists

---

Best emerging practices

• Make TEEs ephemeral, proofs durable
  • Use short-lived enclaves or Trusted Domains (TDs) to create long-lasting, portable zero-knowledge (ZK) receipts. Think of attestation as just a freshness check, while the ZK receipt serves as a solid audit trail.
• Use policy-driven key release
  • Link secrets to both the measurement and the Trusted Computing Base (TCB) version; be super clear about which platform versions are acceptable (for example, “SNP TCB SVN ≥ 0x18 0d24”). (docs.cloud.google.com)
• Keep circuits small; push heavy parsing into the TEE
  • Check vendor certificate chains and Certificate Revocation Lists (CRLs) right inside the enclave. Only export a compact set of claims hashed into attester_held_data for the ZK circuit to verify. (docs.trustauthority.intel.com)
• Settle where it’s cheapest for your audience
  • For a better consumer experience, verify on Layer 2 and periodically anchor to Layer 1; for workloads that are heavy on proofs, it’s best to offload verification to a modular layer and pull in the results cross-chain. (chainwire.org)
• Bring your own crypto agility
  • Right now, BN254 is the cheapest option on the Ethereum Virtual Machine (EVM) (EIP-1108), but it’s smart to maintain an abstraction layer so you can switch to BLS12-381, IPA, or STARK receipts as the precompiles and tools on your target chain evolve. (eips.ethereum.org)

---

A 90‑day rollout plan

• Weeks 1-2: Time to pick your TEE target(s). If you're on AWS, check out how to prototype a Nitro Enclave; if you're leaning towards GCP, go ahead and set up a TDX CVM and get that attestation capture rolling. (docs.aws.amazon.com)
• Weeks 3-5: Let's implement some policy-gated key release:
  • For AWS: You'll want to attach those kms:RecipientAttestation policies to allow Decrypt/GenerateDataKey just for your enclave image (PCR0) and the specific IAM role you have. (docs.aws.amazon.com)
  • If you're going multi-cloud: integrate with Intel Trust Authority and make sure to pass JWT tokens to your Key Management System (KBS). (docs.trustauthority.intel.com)
• Weeks 6-8: Now, let’s build that ZK wrapper:
  • Start by encoding a compact claim vector--this should include the measurement hash, TCB OK flag, policy ID, and output commitment.
  • Don’t forget to implement a Groth16 verifier on your target chain and monitor that gas usage. (eips.ethereum.org)
• Weeks 9-10: Next up, tackle aggregation or modular verification to cut down on costs with UPA or zkVerify. (docs.nebra.one)
• Weeks 11-13: Time for some hardening:
  • Make sure to enforce minimum TCBs based on the latest GCP/AMD bulletins, and plan your upgrades around vendor recovery windows (Intel's schedule is key here). (docs.cloud.google.com)
  • Add some circuit analyzers and fuzzers to your CI pipeline, and set up alarms for any debug attestations or PCR drift. (arxiv.org)

---

FAQs we hear from leadership

• How can we dodge vendor lock-in?
  • One way is to normalize to an attestation broker, like the Intel Trust Authority, and use a ZK receipt format that your target chain can verify without breaking the bank. This setup allows you to shift between Nitro, TDX, SEV‑SNP, or Arm Realms by tweaking policies instead of messing with code. (docs.trustauthority.intel.com)
• What’s the scoop on fees?
  • With EIP‑1108 pricing, a single Groth16 verification (when there are just a few public inputs) runs you about 200-230k gas. But if you use aggregation or a modular verification layer, you can get that down to around 40-60k gas per proof equivalent. Plus, when you're working with larger batches, the amortized cost gets even better. (eips.ethereum.org)
• Is it possible to do this without the data source’s buy-in?
  • For a lot of web sources, absolutely! zkTLS approaches, like DECO or TLSNotary, don’t need any changes on the server side. And for enterprise systems, a TEE agent can scoop up and verify private data while staying in line with corporate policies. (blog.chain.link)

---

Where 7Block Labs can help

• Choosing the right platform and figuring out potential threats for your industry (whether it’s finance, health, or AI).
• Crafting KMS/attestation policies and running audits.
• Designing ZK circuits with an eye on gas-aware verification, aggregation, and modular settlement.
• Creating incident response playbooks that align with vendor TCB cycles.

Looking for a solid reference implementation that you can roll out in about 6-8 weeks? We’ve got you covered! We’ll provide all the essential scaffolding--think Nitro/TDX samples, KMS/ITA policies, Groth16 verifier contracts, and options for aggregation or zkVerify integration. Plus, we'll customize everything to fit your compliance and product requirements.

---

References and source notes

• Check out the AWS Nitro Enclaves attestation and KMS condition keys (PCR/ImageSha384). There’s some solid documentation and helpful guidance here. (docs.aws.amazon.com)
• If you're into Google Cloud, don’t miss the Confidential VMs (Intel TDX/AMD SEV‑SNP) release notes and TCB SVN guidance. Lots of useful info! (docs.cloud.google.com)
• Dive into the Intel Trust Authority for some multi-tech attestation, JWT tokens, and all about Faithful Verification. Super interesting stuff! (docs.trustauthority.intel.com)
• Curious about Ethereum Dencun (EIP‑4844) and the EIP‑1108 gas schedule? Find all the official references and explanations you need right here. (blog.ethereum.org)
• Explore the zkTLS landscape (think DECO/TLSNotary) and check out the latest events in their current docs. Worth a look! (blog.chain.link)
• Looking for ways to cut costs? Take a peek at modular verification (zkVerify) and proof aggregation (UPA) techniques. (chainwire.org)
• Don't forget to keep an eye on TEE advisories and TCB recoveries, with the latest bulletins from Intel, AMD, and GCP. Always good to stay updated! (intel.com)
• Lastly, if you're interested in Arm CCA Realms (RME), check out the documentation and learning paths they've got. Great resources! (arm.com)

---