Skip to content

GOOGLE 2026-05-27

Read original ↗

Google Research — Private analytics via zero-trust aggregation

Summary

Google Research announces a production private-analytics architecture that composes a new lattice-based secure-aggregation cryptographic protocol with a TEE inside Google's confidential federated analytics service, delivering two-layer defense in depth where each layer would have to be independently broken to expose individual user data. The cryptographic layer ensures "individual raw data is never exposed or reconstructed in any server memory — not even within the hardware-protected perimeters"; the TEE layer adds attestation-backed transparency that the correct binary is running. The novel cryptographic primitive is a one-shot single-message submission scheme — overcoming the multi-round-online-device requirement that has limited prior production secure-aggregation deployments. A small client committee holds hints needed to unlock the aggregated value masked with differential-privacy noise. First named production deployment is Android System SafetyCore (Android 9+), where the system is used to evaluate effectiveness metadata of on-device safety classifiers without ever observing the private content that triggered local alerts.

Key takeaways

  1. Zero-trust principle applied to data-flow architecture, not just network access. The post explicitly invokes "zero-trust principle, which aims to reduce trust necessary in any single entity" — but at a different layer than the corporate-network ZTA that Yelp / Convera instances canonicalise. Here zero-trust is applied to the trust-allocation per protection mechanism: don't put all confidentiality eggs in either "hardware isolation" or "cryptographic protocol" — compose both, so neither single failure breaks privacy. (Source: this post, intro §)

  2. TEE side-channel risk named as the structural justification for a second layer. "TEE isolation mechanisms are constantly evolving. Researchers regularly discover side-channel vulnerabilities that can be leveraged by an attacker to either invalidate TEE guarantees, or application-level specific guarantees (SNPeek, TDXray)." This is the canonical wiki articulation of TEE side-channel vulnerability as a persistent ongoing risk rather than a point-in-time bug class — "new side-channel vulnerabilities are expected to be discovered." The architectural response is composition, not waiting for side-channels to be fixed. (Source: this post, "A tale of two protections" §)

  3. The structural barrier to prior secure-aggregation: multi-round protocols requiring devices to remain online. "Its widespread use has been limited by the complexity in its requirement that user devices remain online in multiround protocols over extended periods of time." Two prior generations of Google secure-aggregation protocols (cited as the federated-analytics blog and a follow-up) ran into this. The new protocol's single one-shot message primitive is the load-bearing fix. (Source: this post, "A tale of two protections" §)

  4. The cryptographic primitive: lattice-based aggregation where ciphertexts AND keys can be summed. "An innovative lattice-based protocol that allows clients to encrypt their data in a way that the resulting ciphertexts can be aggregated while aggregating the underlying messages as well as encryption keys." The server obtains a single decryption key that only decrypts the aggregate — not individual contributions. Lattice-based, so naturally post-quantum (lattices are the primary PQC substrate). (Source: this post, "The cryptographic engine" §)

  5. Decryption-key share distribution via client committees. "To aid with this task we form small committees among the clients that hold hints which help unlock the aggregated value masked with additional differential privacy noise. Clients serve on committees infrequently according to their availability and facilitate the property that any decryption key is shared over a number of parties each one of which protects the confidentiality of the encrypted data." This is the client-committee key-share pattern — the decryption key is never held by Google in full; the confidentiality property is enforced even against a fully-compromised server. Differential-privacy noise is applied before committee members reveal their hints, so even a fully-leaked aggregate is DP-bounded. (Source: this post, "The cryptographic engine" §)

  6. Production deployment target: Android System SafetyCore (Android 9+). "Android SafetyCore will leverage our zero-trust private analytics to evaluate metadata indicative of the effectiveness of its tools while respecting its privacy commitment that user content stays only on device." The use case is measuring true-positive rate of on-device safety classifiers across the global Android fleet — a workload that intrinsically cannot use centralised analytics because "developers need to understand their real-world performance — specifically, which threats are being caught and where there are opportunities to further refine detection capabilities, all without ever compromising user privacy." (Source: this post, "Private analytics for SafetyCore" §)

  7. Prior production proof point: TEE-only DP aggregation in Pixel Recorder. "Google has deployed TEE-backed differentially private aggregation for computing insights into AI systems in the Pixel Recorder app." Linked from the Toward provably private insights into AI use 2025-12 post. The new protocol is positioned as a second-generation architecture that adds the cryptographic layer to the existing TEE-based one — incremental defense composition, not a replacement. (Source: this post, "A tale of two protections" §)

  8. Attestation as transparency primitive, not just identity primitive. "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." Attestation is being used here in the composition pattern that WhatsApp Private Processing canonicalised — the binary digest is published, attestation lets the client verify what's running, and "publicly available code" means the digest is meaningful. (Source: this post, "Encryption meets isolation" §)

Architectural shape (numbers + composition)

The post does not give numeric performance figures (no QPS, no aggregation window size, no latency budget, no batch size). The architectural shape it discloses:

┌───────────────────────────────────────────────────────────────┐
│  User device (Android SafetyCore)                             │
│  ┌───────────────────────────────────────────────────────┐    │
│  │  On-device classifier                                 │    │
│  │  ↓                                                    │    │
│  │  Outcome metadata (effectiveness signal,             │    │
│  │  NOT raw user content)                               │    │
│  │  ↓                                                    │    │
│  │  Lattice-based encryption                            │    │
│  │  (one-shot message, key-aggregating)                 │    │
│  └───────────────────────────────────────────────────────┘    │
└──────────────────────────┬────────────────────────────────────┘
                           │ single message (no online-during-aggregation requirement)
                           ↓
┌───────────────────────────────────────────────────────────────┐
│  Google confidential federated analytics service              │
│  ┌───────────────────────────────────────────────────────┐    │
│  │  TEE (Intel TDX or AMD SEV-SNP)                       │    │
│  │  - attested binary digest published                   │    │
│  │  - aggregates ciphertexts (sum of encrypted)          │    │
│  │  - aggregates keys (sum of key shares)                │    │
│  │  - server does NOT hold full decryption key           │    │
│  │                                                       │    │
│  │  Cryptographic invariant: individual raw data is      │    │
│  │  never decrypted in this perimeter — only the         │    │
│  │  aggregate is recoverable.                            │    │
│  └───────────────────────────────────────────────────────┘    │
└──────────────────────────┬────────────────────────────────────┘
                           │ aggregate-only decryption request
                           ↓
┌───────────────────────────────────────────────────────────────┐
│  Client committee (subset of devices, rotated)                │
│  - holds key hints                                            │
│  - hints, combined with DP noise, unlock aggregate            │
│  - participates infrequently, opportunistically               │
└───────────────────────────────────────────────────────────────┘

Notable composition properties:

  • Defense layers ordered by mathematical strength: cryptographic invariant first (provable via mathematical proof), TEE attestation second (provides auditability of the attested binary, but vulnerable to side-channels). The post explicitly orders these: "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 crypto layer is load-bearing on confidentiality; TEE adds transparency + attestation, not the only privacy mechanism.

  • Differential-privacy noise as final unmasking step, not the protection primitive. DP noise is applied alongside the committee-released key hints — providing the standard DP guarantee (no individual contribution has more than ε-bounded influence on the aggregate output).

  • Off-device decryption only happens at the final, aggregated, anonymized step: "The only time unencrypted data is ever processed off-device is at the final stage, when the data has already been aggregated and anonymized."

Operational numbers

The post does not disclose operational numbers — none of: deployment scale (SafetyCore device count, aggregation window size, batch size), latency (end-to-end aggregation completion time, client encryption time, committee participation cadence), throughput (QPS into the federated analytics service, TEE CPU/memory cost), DP budget (ε / δ values), TEE hardware mix (Intel TDX vs AMD SEV-SNP fleet split), or committee size envelope. The publication is positioned as an architectural-disclosure post, with the cryptographic internals deferred to the ACM cryptographic-aggregation paper linked from the post's quick links. Operational numbers will likely live in a follow-up production post.

Caveats

  • Architectural-disclosure shape, not deployment retrospective. No production-numbers retrospective — no QPS, no DP budget, no committee size, no end-to-end aggregation latency, no Android SafetyCore client count.
  • Cryptographic protocol is referenced via the linked ACM paper, not inlined. The blog post explains the shape (lattice-based, one-shot, ciphertext + key co-aggregation, committee-held shares) but does not give the formal protocol spec. The paper is behind a paywall (ACM Springer link).
  • Side-channel-attack mitigation depth is implicit. The post names the side-channel risk as the justification for the second crypto layer; it does not enumerate which specific side-channel classes are mitigated by the composition (e.g. whether speculative-execution leakage of the partial aggregation state is meaningful when the data is already encrypted).
  • Pixel Recorder's existing TEE-only deployment is not contrasted with numerics. The previous-generation TEE-only DP aggregation is referenced but not quantitatively compared (e.g. "how much does the cryptographic layer cost?").
  • Committee-trust model is not fully decomposed. Committee size, rotation cadence, threshold-of-collusion that breaks confidentiality, and how the committee composition is itself attested are not specified in the blog post.

Cross-references

This post sits in a tight three-way producer-side cluster on the wiki:

  • Sibling to Meta's WhatsApp Private Processing (2025-04-30). Both compose TEE + attestation + transparency-log primitives. The Meta post canonicalises TEE-for-private-AI-inference in the inference direction (server-side LLM inference over private content); this Google post canonicalises the analytics direction (server-side aggregation over private outcomes). Where Meta's post uses TEE as the only confidentiality layer plus OHTTP / non-targetability as the unlinkability layer, Google's post adds a cryptographic confidentiality layer underneath the TEE — an additional defense composition not present in the Meta architecture.

  • Sibling to Google's quantum-disclosure post (2026-03-31). Both Google Research posts use lattice-based cryptography as load-bearing primitive — the quantum-disclosure post uses ZKP (often lattice-based) for capability disclosure; this post uses lattice-based aggregation for one-shot secure summation. Both are part of Google's broader post-quantum research portfolio, applied to different problem domains.

  • Producer-side counterpart to Cloudflare's PQC migration post in that lattice-based crypto is being productionised at consumer scale, but at a different protocol layer (aggregation vs TLS).

Source

Last updated · 542 distilled / 1,571 read