search

WICG / attribution-reporting-api

Attribution Reporting API
https://wicg.github.io/attribution-reporting-api/
Other
370 stars 173 forks source link

Who will act as coordinators for the aggregation service? What are appropriate criteria for selecting coordinators and ensuring coordinators are trustworthy? #323

Open palenica opened 2 years ago

palenica commented 2 years ago

How should we choose appropriate parties to act as coordinators and how can we ensure that the coordinator(s) can be trusted?

eriktaubeneck commented 2 years ago

I see three potential options:

  1. Find some single trusted party which can manage these public/secret key pairs.
  2. Spread the trust among multiple parties, which each manage part of a threshold public/secret key pair.
  3. Further extend the root of trust into another long running instance of a TEE, which can manage these public/secret key pairs.

1/ is the most simple, however it does mean that a single party holds the decryption event for all these events. If that party leaks those keys (intentionally or from an attack), all the data is exposed. If this were an acceptable route, there seems to be a question as to why that party can't be trusted to run the entire aggregation and skip the TEE step altogher.

2/ is similar to the already proposed helper party system (but applied to the key coordination part exclusively.) It also seems relatively easy to accomplish: there is an existing IETF draft specifying how such threshold keys could be generated. There is slightly more complicated than 1/, but that seems manageable. Moreover, this could also extend to only needed 2 out of 3, 3 out of 5, or generically any t out of n parties to agree to release the keys, allowing for measurement to continue when one party may have a service interruption.

3/ seems like the most complicated solution, and comes with the added risk of the whole system failing if that one piece of hardware fails. You could potentially also use a threshold key here over multiple pieces of hardware (i.e. 1 out of n).

palenica commented 2 years ago

Hi Erik, thank you for your thoughtful comments.

On your Option 1, I see a benefit to keeping a separation between the party that holds the key and the party that manages the aggregation servers. In our proposal, the data is collected and held by adtech throughout the process, without need to send it to another party for aggregation. Assuming you trust the Coordinator to perform TEE attestation correctly, anyone can tie the logic running in the TEE to a specific version of open source code. In terms of business model, the adtech will be billed by the cloud provider for the cost of running the aggregation servers instead of (presumably) having to compensate the "aggregation provider" for the cost of aggregation.

I agree with you that Options 2 and 3 are worth exploring as a way to increase trust in the system. In Option 2, beside cryptographic solutions for split-key generation, one could also consider generating a split key within a TEE that in turn distributes a part of the private key to each Coordinator.

eriktaubeneck commented 2 years ago

Assuming you trust the Coordinator to perform TEE attestation correctly, anyone can tie the logic running in the TEE to a specific version of open source code.

My point is that you don't only have to trust the Coordinator to perform the TEE attestation correctly, but you also have to trust that Coordinator to leak the decryption keys. You have to trust the Coordinator completely, because if they collude with an ad tech provider who holds in encrypted data, they can reveal all the information.

palenica commented 2 years ago

Agreed. As you describe, a configuration with two or more Coordinators each holding a part of the key would be resilient to a single Coordinator attack.