Build Hybrid Systems and Audit the Final Architecture

What you will learn

This final lesson covers:

  • TEE plus zero-knowledge proofs
  • TEE plus MPC
  • TEE plus threshold cryptography
  • TEE plus FHE
  • TEE plus client-side encryption
  • Security review
  • Final architecture audit

Why combine technologies?

Every privacy technology has a different strength.

A TEE offers:

  • General-purpose computation
  • Low-latency execution
  • Familiar programming models
  • Hardware-backed isolation
  • Remote attestation

Its limitations may include:

  • Hardware-vendor trust
  • Side channels
  • Firmware risk
  • Attestation centralization
  • Limited public verifiability

Cryptographic systems can reduce some of these limitations.

The goal is not to add every privacy technology.

The goal is to identify one weak assumption and strengthen it.

TEE plus zero-knowledge proofs

A ZK proof may prove a statement about computation without revealing the private witness.

A hybrid design can use the TEE for fast private computation and a ZK proof for a smaller publicly verifiable statement.

Example:

1. TEE runs private matching. 2. TEE commits to input set. 3. TEE produces settlement output. 4. ZK circuit proves that output satisfies selected rules. 5. Smart contract verifies the proof.

The proof may check:

  • Conservation of value
  • Valid signature set
  • Correct commitment opening
  • Ordering constraint
  • Range constraint
  • No duplicate input

It may not prove that the TEE saw every submitted request unless the input-availability problem is also addressed.

Hybrid TEE and zero-knowledge architecture where private computation occurs inside a TEE and a ZK proof verifies selected rules about the resulting output for a public verifier or smart contract.

ZK proof of attestation

Another design creates a ZK proof that a hardware attestation report and certificate chain are valid.

Benefits may include:

  • Smaller on-chain verification payload
  • Privacy for selected attestation fields
  • Reduced smart contract parsing
  • Common verification format

The ZK circuit still depends on:

  • Correct vendor root
  • Correct reference values
  • Correct revocation data
  • Correct proof circuit
  • Up-to-date policy

On-chain TEE verification systems increasingly use proof systems to compress or normalize attestation verification.

TEE plus MPC

MPC allows several parties to compute using secret shares without one party holding the complete secret.

A hybrid design may place one share inside each of several TEEs.

Example:

`` Key share 1: AMD-based TEE Key share 2: Intel-based TEE Key share 3: HSM or separate provider Threshold: 2 of 3 ``

Benefits:

  • One compromised TEE does not expose the full key.
  • One operator cannot act alone.
  • Hardware diversity may reduce single-vendor dependence.

Costs:

  • Network rounds
  • Complex recovery
  • More attestation policies
  • More failure cases
  • Share synchronization
  • Collusion assumptions

TEE plus threshold signatures

A threshold-signature system splits signing power.

No one TEE contains the complete signing key.

This can protect:

  • Validator keys
  • Bridge keys
  • Treasury keys
  • Oracle-signing keys
  • Software-release keys

The system must still prevent:

  • Rollback of share state
  • Duplicate signers
  • Malicious signing requests
  • Collusion
  • Recovery-key misuse

TEE plus FHE

FHE supports computation over encrypted data.

A TEE may be used around FHE for:

  • Key setup
  • Bootstrapping assistance
  • Model protection
  • Faster preprocessing
  • Controlled decryption
  • Policy enforcement
⚠
The TEE should not silently become a complete trusted decryption shortcut that removes the reason FHE was selected. Write down exactly which data becomes plaintext inside the TEE.

TEE plus client-side encryption

Client-side encryption is one of the most practical combinations.

Flow:

1. Client verifies TEE evidence. 2. Client checks workload identity. 3. Client binds a public key to the evidence. 4. Client encrypts input directly to that key. 5. Host transports ciphertext. 6. TEE decrypts and processes it. 7. TEE encrypts output to the client.

This design reduces exposure to:

  • API gateway
  • Load balancer
  • Host
  • Logging proxy
  • Untrusted storage

It does not protect a compromised client device.

TEE plus reproducible builds

Attestation gives a measurement.

Reproducible builds help users connect that measurement to public source code.

A stronger transparency flow is:

`` Public source ↓ Public build instructions ↓ Independent reproducible build ↓ Expected measurement ↓ Remote attestation ↓ User accepts workload ``

Flashbots publishes tooling and manifests for reproducible TEE image builds in parts of its current confidential-computing infrastructure.

The broader lesson is that users need a path from readable source to attested binary identity.

Decide which guarantee comes from where

Create a guarantee map.

| Guarantee | Mechanism | | --- | --- | | Host cannot directly read private memory | TEE | | Workload identity | Attestation | | Source-to-binary verification | Reproducible build | | Public rule correctness | ZK proof | | No single key holder | Threshold cryptography | | Input protected before server | Client-side encryption | | Current state | External state anchor | | Output privacy | Application policy or differential privacy |

This prevents the team from crediting every guarantee to the TEE.

Hybrid privacy architecture mapping client-side encryption, TEEs, zero-knowledge proofs, threshold cryptography, external state anchors, and smart contracts to the specific guarantees each mechanism provides.

Final security audit

1. Assets

  • Are all sensitive assets named?
  • Are policy files and reference values included?
  • Are recovery and signing keys included?

2. Threat model

  • Are attacker capabilities precise?
  • Are physical attacks addressed?
  • Is denial of service addressed?
  • Is the application developer considered?

3. Trust boundary

  • Is trusted code minimized?
  • Is the guest operating system inside the TCB?
  • Are firmware and microcode listed?
  • Are external services listed?

4. Interface

  • Are all entry points documented?
  • Are inputs copied and validated?
  • Are lengths bounded?
  • Are system-call results treated as untrusted?
  • Are errors privacy-safe?

5. Build

  • Are dependencies pinned?
  • Is production debug mode disabled?
  • Is the build reproducible?
  • Is the signing key protected?
  • Can users connect source to measurement?

6. Attestation

  • Is the evidence signature verified?
  • Is the complete certificate chain checked?
  • Is freshness checked?
  • Is the expected measurement checked?
  • Is debug status checked?
  • Is the communication key bound?
  • Is revocation supported?

7. Secrets

  • Does secret release fail closed?
  • Are policies resource-specific?
  • Are keys separated by purpose?
  • Is rotation supported?
  • Is recovery tested?

8. State

  • Can the host replay a request?
  • Can the host restore old sealed state?
  • Can two instances fork state?
  • Is crash recovery atomic?
  • Is migration safe?

9. Side channels

  • Does timing depend on secrets?
  • Does memory access depend on secrets?
  • Does output length depend on secrets?
  • Do logs or metrics expose data?
  • Are tested channels documented?

10. Hardware lifecycle

  • Are advisories monitored?
  • Can minimum security versions be updated?
  • Can vulnerable hardware be revoked?
  • Are firmware and microcode patched?
  • Are secrets rotated after exposure?

11. Production operations

  • Is re-attestation performed?
  • Is collateral kept current?
  • Are updates staged?
  • Are backups recoverable?
  • Are regions using one policy?
  • Is there an incident-response plan?

12. User verification

  • Can users verify the measurement?
  • Can users verify source?
  • Can users understand remaining trust?
  • Can users detect revocation?
  • Can users choose not to send data?
Final TEE security audit flow covering assets, threat modeling, trust boundaries, interfaces, build security, attestation, secret management, state protection, side channels, hardware lifecycle, and production operations.

Final architecture exercise

Design one complete system.

Option A: Confidential AI service

Requirements:

  • Private prompts
  • Protected model weights
  • CPU and GPU attestation
  • Client-side encryption
  • Model-key release
  • Timing-leakage discussion

Option B: Private Web3 auction

Requirements:

  • Encrypted bids
  • Attested matcher
  • Rollback protection
  • Public settlement
  • Proof of auction constraints
  • Censorship discussion

Option C: Threshold validator signer

Requirements:

  • Three TEE or HSM shares
  • Two-of-three signing
  • Attestation
  • Signing-history protection
  • Recovery
  • Slashing-risk analysis

For the selected system, produce:

1. Threat model 2. Trust-boundary diagram 3. Data-flow diagram 4. Attestation sequence 5. Key hierarchy 6. State-continuity design 7. Side-channel review 8. Update process 9. Incident-response plan 10. Final audit checklist

Common mistakes

⚠
**Adding ZK proofs without defining what they prove** — Every proof should verify one specific claim. **Using several TEEs from one vendor and calling it hardware diversity** — Same hardware family shares the same root of trust. **Storing all MPC shares under one operator** — Threshold security requires independent parties. **Using the TEE to decrypt all FHE data without documenting the trust change** — Decryption inside the TEE removes the FHE confidentiality guarantee. **Publishing source without reproducible build instructions** — Source alone cannot be connected to a measurement. **Treating an on-chain attestation result as permanent** — Collateral, revocation, and policy change over time. **Auditing application code but not operations and recovery** — An insecure update process or backup can undermine a correct application.

Key takeaways

  • Hybrid systems should reduce one clearly identified weakness.
  • Assign every guarantee to a specific mechanism.
  • ZK proofs can add public verification.
  • MPC and threshold cryptography can reduce single-party key trust.
  • Client-side encryption protects data before it reaches the host.
  • Reproducible builds connect source code to attested measurements.
  • A complete audit covers application, hardware, policy, state, and operations.

Final knowledge check

1. What can a ZK proof add to a TEE-based system? 2. Why does threshold cryptography reduce single-point key risk? 3. What does client-side encryption protect that a server-side TEE may not? 4. Why are reproducible builds important for attestation? 5. What does a state anchor provide? 6. Why must every security guarantee be assigned to a mechanism? 7. What areas must a complete TEE audit cover?

Answer the quiz correctly to continue →

Quiz · Multiple Choice1 / 3

A team uses three TEE instances all running on AMD SEV-SNP from the same cloud provider as MPC threshold shares. A team member calls this "hardware diversity." What is the main flaw in this claim?