Skip to content

PATTERN Cited by 1 source

Cryptography-plus-TEE defense in depth

Pattern

When the workload requires provable confidentiality of per-user data and the deployment substrate is a server you do not fully trust (or that you don't want users to have to fully trust), compose two independent privacy mechanisms:

  1. A cryptographic protocol — typically secure aggregation, homomorphic encryption, or another non-extractability primitive — that prevents server-side decryption of individual contributions as a mathematical guarantee.
  2. A TEE — Intel TDX, AMD SEV-SNP, or equivalent — that confines the running binary to an attested measurement and provides hardware-backed isolation as a second, independent layer.

Each layer would have to be independently broken to expose plaintext. A side-channel against the TEE (the persistent side-channel risk class) exposes only encrypted state, not plaintext. A flaw in the cryptographic implementation is constrained by the TEE-attested binary digest — only the publicly-reviewable code can be running.

Problem

Single-layer privacy designs fail to a single mechanism break:

  • TEE-only: side-channel attacks against TEEs are a continuing research direction; the 2026-05-27 Google post explicitly states "new side-channel vulnerabilities are expected to be discovered." A TEE-only design bets on no exploitable side-channel for the workload's lifetime — typically years.
  • Crypto-only: protocol implementation bugs, timing-channel leaks in the binary, or covert channels through performance counters can exfiltrate plaintext from a correct-on-paper crypto protocol. Implementation review is hard; transparency-log + attestation of the binary digest helps, but only if there's a TEE to attest to.

Solution

Run the cryptographic protocol inside the TEE, with the TEE serving two independent functions:

  1. Attestation transparency — the TEE produces a hardware-rooted attestation of the running binary; clients verify it against a publicly-reviewable code release. This makes the cryptographic protocol's correctness auditable, not just claimed.
  2. Defense backstop — even if the cryptographic protocol has an unknown bug, the TEE's hardware isolation provides a second barrier; attackers must compromise both.

Conversely, the cryptographic protocol provides the load-bearing confidentiality property — even a successful TEE breakout reveals only encrypted state. The TEE's role is auditability + defense-in-depth, not the only confidentiality mechanism.

Layering rationale (from the 2026-05-27 post)

"With this solution, confidentiality no longer relies entirely on hardware protection. The cryptographic layer ensures that individual raw data is never exposed or reconstructed in any server memory — not even within the hardware-protected perimeters. The only time unencrypted data is ever processed off-device is at the final stage, when the data has already been aggregated and anonymized. Furthermore, our solution leverages TEE attestation mechanisms to provide high-assurance, verifiable proof to all participants that the secure aggregation protocol is being executed exactly as intended, i.e., by compiling and running correctly publicly available code."

The phrase "confidentiality no longer relies entirely on hardware protection" is the load-bearing one — it's the single-sentence articulation of why this pattern is structurally distinct from the TEE-for-private-AI-inference pattern, which uses TEE as the confidentiality boundary.

When to use

  • Workload has high confidentiality requirements (private user data, PHI, financial records, classifier outputs over sensitive inputs).
  • Deployment surface is server-side aggregation / inference that cannot be done client-side (computational, fleet-wide-aggregate, or model-size constraints).
  • Long workload lifetime where new TEE side-channel attacks are likely to be discovered while the system is still in production.
  • Public scrutiny is desired — the architecture is published and the binary is reviewable, increasing trust without requiring users to take operator's word for it.

When NOT to use

  • Latency-critical workloads where the cryptographic overhead exceeds the latency budget. Lattice-based crypto is fast but not free; one-shot encryption + aggregation has measurable per-request cost.
  • Workloads where the aggregate alone is sensitive — composing with DP is necessary to bound output privacy, and the DP budget management is an additional engineering burden.
  • Single-tenant / fully-trusted-server workloads where the threat model doesn't include a compromised aggregation server.

Production instances on the wiki

System Layers composed
systems/google-confidential-federated-analytics (2026-05-27) Lattice secure-aggregation + TEE (TDX or SEV-SNP) + DP + client-committee key shares
systems/android-safetycore Consumer of the above for on-device safety-classifier effectiveness analytics

Sibling pattern: patterns/tee-for-private-ai-inference — canonicalised by systems/whatsapp-private-processing (2025-04-30). That pattern uses TEE as the only confidentiality boundary, with attestation + OHTTP + transparency log composing for unlinkability and auditability. The 2026-05-27 Google design adds a cryptographic layer underneath the TEE — strictly stronger threat-model coverage at the cost of cryptographic-protocol complexity.

Components

  1. Client-side encryption — devices generate ciphertexts under a key-aggregating cryptographic scheme; never transmit plaintext contributions.
  2. TEE-resident aggregation server — runs the publicly-reviewable secure-aggregation binary; produces hardware-rooted attestations of the running code.
  3. Attestation transparency — published binary digests + log, clients verify the running binary against the policy.
  4. Cryptographic decryption gate — typically a client-committee holds key shares; aggregate is only unlockable when the committee reveals shares.
  5. Differential-privacy noise — applied at the unmasking step so even the released aggregate is privacy-bounded.

Failure-mode coverage matrix

Failure mode Mitigated by
Operator reads decrypted contribution from RAM TEE memory encryption
Side-channel attack against TEE leaks state Cryptographic layer — leaked state is encrypted
Bug in secure-aggregation binary leaks plaintext via covert channel TEE attestation surfaces the binary digest; committee model bounds blast radius
Server runs a tampered binary TEE attestation; only attested-as-publicly-reviewable binaries get key shares
Aggregate reveals an individual due to small population Differential-privacy noise
Server colludes with sub-threshold of committee Cryptographic protocol's threshold property; design choice
Quantum attack against the encryption concepts/lattice-based-cryptography (Lattice substrate) gives PQ resilience by construction

No single layer covers all failure modes; composition is load-bearing.

Caveats

  • Two layers, two operational complexities. Cryptographic protocol expertise + TEE operations expertise are both required.
  • Performance composes multiplicatively. TEE encrypted-DRAM cost + cryptographic ciphertext-aggregation cost. Lattice schemes are fast, but not free.
  • Auditability is only as good as the publicly-reviewable code. If the binary is not actually open-source, the TEE attestation reduces to "vendor signed something".
  • Threat model assumptions matter. The protocol is malicious-server- secure under specific assumptions; collusion thresholds, network models, and committee selection mechanics must all be reviewable.

Seen in

Last updated · 542 distilled / 1,571 read