data-clean-room

How it is built

Architecture overview

A data clean room lets two or more companies learn something from their combined data without handing the data to each other. A retailer and an advertiser, for example, want to know how many people who saw an ad later bought the product, but neither may give the other its customer list. The design has one idea and three layers. The idea: nobody gets to run arbitrary code over the joint data, and nobody sees row-level output. The layers: a policy layer that fixes in advance which questions may be asked and who may see the answers; a matching and computation layer that joins and aggregates the data in a way that hides the inputs (encrypted matching, secret sharing, or a hardware enclave); and an output layer that adds noise or suppresses small groups so that the answer itself cannot single out a person. AWS Clean Rooms is the best-documented example: it reads each party's data from its original location, applies analysis rules to restrict queries and output, can keep data encrypted during processing, and can add differential privacy to results (source: AWS Clean Rooms user guide).

Parts:

• Query language and policy check — parses the submitted query and tests it against what the collaboration allows — Recursive-descent parsing, Authorization models
• Small-group suppression — refuses or hides aggregates over too few people — k-anonymity (no page yet)
• Noise and budget — adds calibrated noise to results and counts how much privacy has been spent — differential-privacy (no page yet), privacy-budget-accounting (no page yet), built on csprng (no page yet), Floating-point error and conditional-writes (no page yet)
• Private matching — finds the overlap of two customer lists without revealing the rest — private-set-intersection (no page yet), built on ECDH key exchange and Cuckoo hashing
• Joint computation on hidden inputs — computes a function of several parties' data with cryptography — secure-multiparty-computation (no page yet), built on Shamir secret sharing, commitment-schemes (no page yet) and arithmetic-circuits (no page yet)
• Sealed execution — runs the joint query inside hardware that the data owners can attest — trusted-execution-environments (no page yet)
• Data protection at rest and in transit — each dataset encrypted under keys its owner controls — Envelope encryption, built on AEAD and aes-key-wrap (no page yet)
• Request integrity — signed requests and links, tamper-evident logs — hmac-request-signing (no page yet), Cryptographic hashes

 Party A data ──encrypt/hash──┐                              ┌── Party B data
 (own keys, own storage)      ▼                              ▼   (own keys, own storage)
                      ┌──────────────────── collaboration ─────────────────────┐
 analyst ─ query ───► │ parse ─► policy check ─► match / compute               │
                      │            │              (PSI | MPC | enclave)        │
                      │            ▼                      │                    │
                      │   privacy budget ◄── noise ◄── aggregate ◄─────────────┘
                      │            │          k-threshold
                      └────────────┼───────────────────────────────────────────┘
                                   ▼
                   result (aggregate only) ─► audit log (query, who, epsilon spent)

Nothing in the diagram is exotic on its own. What makes a clean room is the contract: the join and aggregation are the only operations that touch both sides' data, they run under a policy both sides approved, and everything leaving the room has passed the output layer.

How the parts fit together

Query language and policy check

The room does not run free-form code. Participants agree on query shapes in advance: in AWS Clean Rooms, members can create or approve analysis templates that fix in advance the exact queries and jobs allowed, and analysis rules restrict SQL and constrain outputs (source: AWS Clean Rooms user guide). To enforce this the room has to understand the query, not just forward it. A recursive-descent parser for a deliberately small SQL subset is the right tool: one function per grammar rule, easy to audit, and unknown syntax is rejected rather than guessed. After parsing, the query tree is checked against the policy: only agreed columns may be used as join keys, only aggregate functions are allowed in the output, filters cannot isolate fewer rows than the threshold, and so on.

Who may start a query, and who may read its result, is an authorization question: roles for the coarse rules (analyst, data owner, result receiver) and per-collaboration relationships for the fine ones. The result receiver is a distinct role in AWS Clean Rooms, and the differential-privacy guide states the reason: without noise, the receiving member could add or remove records of one individual in their own data and watch how the answer changes (source: AWS Clean Rooms differential privacy guide).

Small-group suppression

The cheapest protection is a threshold. k-anonymity (no page yet) in this setting means: do not release an aggregate unless it covers at least k individuals, and suppress or merge smaller groups. It is simple, deterministic and easy to explain to a legal team. It has a well-known limit: a sequence of overlapping queries, each above the threshold, can be subtracted from each other to isolate one person. That is why a threshold is paired with query-shape restrictions (policy layer) and, for stronger guarantees, with noise.

Noise and budget

Differential privacy (differential-privacy, no page yet) gives a quantitative guarantee: the answer's distribution changes by a bounded factor, controlled by a parameter epsilon (and a small delta), whether or not any one person's data is included. The mechanism adds noise scaled to how much one person can change the answer (the sensitivity) divided by epsilon (source: Dwork and Roth, The Algorithmic Foundations of Differential Privacy). Several points matter in a production room:

• Randomness must come from a cryptographically secure source (csprng, no page yet), since predictable noise can be removed.
• Floating point is a real attack surface: naive Laplace sampling on doubles can leak information through rounding and gaps in the representable values, so implementations use careful discrete samplers and bound error (Floating-point error). AWS says its Clean Rooms differential privacy uses a sampler implementation called SampCert (source: AWS Clean Rooms differential privacy guide).
• Budget. Each released answer spends some epsilon, and the spends add up under composition rules (privacy-budget-accounting, no page yet). The room therefore keeps a ledger per collaboration and per dataset and refuses queries when the budget is gone. The ledger must be updated atomically with the release decision, otherwise two concurrent queries can both pass a check that only one should: a compare-and-swap on the stored balance (conditional-writes, no page yet) is the natural primitive.

Private matching

Before two datasets can be joined on a person, the room needs to know which people are in both. Sending hashed emails is not private enough: anyone with a list of candidate emails can hash them and test membership. Private set intersection (private-set-intersection, no page yet) solves exactly this. A classic ECDH-based protocol works like this: the server encrypts each of its elements x as H(x)^s under a secret key s, using a commutative encryption scheme; the client raises what it receives to its own key and compares; neither side learns elements outside the intersection (source: OpenMined PSI README, which describes a client/server protocol based on ECDH and Bloom filters that returns the intersection cardinality). The group operations are those of ECDH key exchange. Implementations speed up the membership test with hash tables such as Cuckoo hashing, where each key sits in one of two buckets. Google's Private Join and Compute is a variant that also sums a value over the intersection ("private intersection-sum"), which is the form most ad measurement uses (source: private-join-and-compute README).

Joint computation on hidden inputs

When the question is more than a count over an intersection, the parties can compute the function itself under encryption. Secure multiparty computation (secure-multiparty-computation, no page yet) does this by splitting each input into shares such that any single share, or any set below a threshold, reveals nothing; the parties run the computation on the shares and exchange messages, and only the output is reconstructed. Shamir secret sharing is the basic building block (k of n shares reconstruct, k-1 reveal nothing). Addition is free on shares; multiplication needs a round of communication, which is why protocols compile the function into arithmetic circuits (arithmetic-circuits, no page yet) and why MPC is orders of magnitude slower than computing in the clear. Commitments (commitment-schemes, no page yet) let a party fix its input before the protocol starts so it cannot adapt it later. The alternative to MPC is homomorphic encryption, which computes on ciphertexts held by one party; it avoids the rounds of communication but costs more compute.

Sealed execution

Trusted execution environments (trusted-execution-environments, no page yet) take a different route: all parties send their (encrypted) data to a hardware enclave or confidential virtual machine, which proves to them by remote attestation which code it runs; only then do they release keys to it. The join and aggregation then run in the clear inside the enclave, at near-native speed. The Confidential Computing Consortium describes the goal as protecting data while it is in use (source: confidentialcomputing.io). The trade is that security rests on the hardware vendor and on the attested code, and on side-channel resistance, instead of on mathematics alone. Many rooms use a mix: PSI or MPC for the highest-sensitivity joins, enclaves or plain managed compute plus policy for the rest. AWS Clean Rooms lists its own variant, Cryptographic Computing, which keeps data encrypted while queries are processed (source: AWS Clean Rooms user guide).

Data protection at rest and in transit

Each party's data stays under its own keys. Envelope encryption encrypts each object with a fresh data key and wraps that key under a key-management-service key the owner controls, so revoking access means disabling one key rather than re-encrypting the data. The object encryption itself is an AEAD mode, which detects tampering as well as hiding content, and key material is wrapped with a dedicated construction (aes-key-wrap, no page yet).

Request integrity

The room exposes an API and produces results that are downloaded elsewhere, so requests and links have to be authenticated. hmac-request-signing (no page yet) signs a canonical form of the request (method, path, headers, body hash) with a secret, optionally with an expiry, so a replayed or altered request fails; a cryptographic hash of the body and of each result file gives the audit log something to point at that cannot be edited quietly. Comparing MACs and tags must not leak timing (constant-time-code, no page yet).

Data and control flow

Setting up a collaboration:

1. The parties agree on purpose, datasets, join keys, allowed query templates, output rules and privacy parameters (threshold k, epsilon per query and in total).
2. Each party registers its dataset and the keys that protect it, and the room records the agreed policy.
3. The policy is the only thing that changes what the room will answer; changing it needs all parties' approval.

One analysis:

1. An analyst submits a query or picks a template.
2. The room parses it, checks the role of the submitter, checks the query against the policy, and reserves privacy budget.
3. Matching runs (PSI, or a join inside the enclave or a managed environment), then the aggregation.
4. The output layer applies the threshold and adds noise; the budget reservation is committed.
5. Only the aggregate is released to the result receiver; the audit log records the query, the submitter, the epsilon spent and a hash of the result.

Scaling

1. Dataset size. Plain aggregation scales like any distributed query engine; the cryptographic parts do not. PSI costs a small, fixed number of group operations per element and batches well; general MPC costs communication per multiplication and is practical for small, fixed computations.
2. Number of parties. Each pairwise relation (keys, policies, budgets) is separate state; the number of collaborations, not the number of rows, becomes the operational limit.
3. Number of queries. Differential privacy makes the privacy budget the scarce resource: the more queries, the more noise per query for a fixed total. Plan the question set, reuse results, and prefer a few well-chosen aggregates over open exploration.
4. Latency of enclaves and managed compute is close to ordinary queries; MPC and PSI are batch-style operations.

Failure modes

Real implementations

The alternative: a plain data-sharing agreement plus a trusted third party who holds both datasets and runs the agreed queries is far simpler and often the right first step; the clean-room techniques above replace the trusted party with cryptography and hardware, at the cost of engineering effort, slower joins and a smaller set of supported questions.

Sources

• C. Dwork and A. Roth, The Algorithmic Foundations of Differential Privacy, 2014. book
• AWS Clean Rooms User Guide: what is AWS Clean Rooms, differential privacy.
• OpenMined PSI: README; Google Private Join and Compute: README.
• Google differential privacy libraries: repository; OpenDP: repository.
• Delta Sharing: repository.
• Confidential Computing Consortium: confidentialcomputing.io.