Note: the explainer is posted in the Protected Auction repository, but applies to all Privacy Sandbox services.
The Privacy Sandbox Coordinator model has been introduced as part of processing aggregatable reports in a privacy preserving way; the aggregatable reports are generated by the Chrome Attribution Reporting API. The use of Coordinator Services in Privacy Sandbox has since been extended to include Protected Auction Services.
The current Coordinator Services consist of several components: (1) private/public encryption key generation, (2) workload attestation and private/public encryption key distribution, (3) authentication and authorization management, and (4) aggregatable report accounting (used by aggregation service.
A split trust model has been implemented where decryption keys are split across two independent deployments of the coordinator services where each deployment is operated by an independent party (Aggregation Service AWS Coordinators). Currently, the coordinator services serving workloads on a specific public cloud (e.g. AWS) are operated in the same public cloud.
Coordinator |
Operator of coordinator services. Each coordinator deploys and operates the necessary components (Type-1 or Type-2) to support ad tech workloads. |
Coordinator pair |
An operated pair of coordinator services (Type-1, Type-2) in the same public cloud. |
Ad tech |
A company that provides services to deliver and measure ads. In this explainer it is used to describe the entity running a Privacy Sandbox trusted service workload compiled from open source code and interacting with Coordinator Services. |
Attestation |
A mechanism to authenticate software identity, usually with cryptographic hashes or signatures. In this explainer, attestation matches the code running in the coordinator-operated key-generation service or adtech-operated workload service with open source code. Note: this is not the Privacy Sandbox Enrollment Attestation. |
Trusted execution environment (TEE) |
A secure, private, and isolated execution context. The TEE's contents are protected from observation and tampering by unauthorized parties, including the root user. The requirements for supported public TEE implementations can be found here. |
Multi-party key generation and distribution service (MPKGDS) |
Formerly known as Key Management System (KMS).
|
Aggregatable Report Accounting |
A distributed ledger that tracks and limits the number of times a given aggregatable report sharedID can be processed to generate noised summary reports. The number of times allowed is referred to as the "budget" for the given sharedID. The aggregatable report accounting budget is maintained in both Type-1 and Type-2 coordinator deployments. |
Cloud KMS |
Key Management Service offered by a public cloud provider as a managed service for hardware or software backed symmetric and asymmetric encryption keys |
The Type-1 coordinator deploys the following components: (1) private/public encryption key generation and public key distribution, (2) workload attestation and private encryption key distribution, (3) authentication and authorization management, and (4 - use-case dependent) aggregatable report accounting (used by Aggregation Service).
The Type-2 coordinator deploys the following components: (1) workload attestation and private encryption key distribution, (2) authentication and authorization management, and (3 - use-case dependent) aggregatable report accounting (used by Aggregation Service).
The multi-party key generation service generates a set of public/private asymmetric HPKE keys. The private keys are split and stored independently in the respective Type-1 and Type-2 coordinator deployment. To ensure keys are generated, distributed and stored securely, the key generation service running on the Type-1 coordinator is (1) running inside a TEE, (2) attested by the Type-2 coordinator to run known open sourced code, and (3) does not store the Type-2 private key split in the Type-1 operated storage systems. The TEE based key generation creates a configurable count of public / private key pairs (in current deployed systems, 5 key pairs are generated) which are rotated within a configurable time window (in current deployed systems public keys are valid for 7 days, private keys are served between 90 and 365 days if not compromised (revoked)). Public keys and the Type-1 private key split are stored in the Type-1 coordinator managed storage systems, the private key split is encrypted with the cloud provider managed key management service (cloud KMS) before storage. The Type-2 private key split is securely sent to the Type-2 coordinator from within the TEE before it is discarded from the TEE memory. The Type-2 coordinator encrypts the Type-2 private key split with the cloud provider managed key management service before storage.
The Type-1 coordinator distributes the current valid public keys through a CDN (content delivery network) backed endpoint. Caching Headers are dynamically set to limit client caching beyond the key's validity and allow for cache invalidation in the case of compromised keys and out-of-cycle key rotations.
Serving endpoints follow the following format: https://publickeyservice.[use-case-area].[workload_cloud].privacysandboxservices.com/.well-known/[workload-use-case]/v1/public-keys
With the following content format:
{
"keys": [
{
"id": "[arbitrary string identifying the key (up to 128 characters)]",
"key": "[base64 encoded public key]"
},
// Optionally, more keys.
]
}Private decryption keys are required for workloads to process the data encrypted with public encryption keys for the specific workload privacy sandbox APIs.
Private decryption key splits are encrypted with a respective coordinator managed cloud KMS key. Type-1 coordinator manages a symmetric encryption key to encrypt the Type-1 private key split, Type-2 coordinator manages a symmetric encryption key to encrypt the Type-2 private key split. Onboarded ad tech credentials can fetch encrypted key splits from the authenticated private key distribution endpoint operated by each coordinator (Type-1 and Type-2).
Decryption of the encrypted private key splits is only authorized within TEE workload images whose cryptographic hash matches one of the hashes on the coordinator maintained allowlist and running on supported TEE hardware/software stack verified through workload attestation.
Once a workload attests successfully, it will be granted permission to use the respective coordinator managed cloud KMS key to decrypt ("unwrap") the Type-1 and Type-2 private key splits. Once both private key splits are successfully decrypted, they can be combined to reconstruct the full private HPKE decryption key.
The Aggregatable Report Accounting ledger is used for accounting to ensure encrypted payloads of aggregatable reports are not processed more often than the applicable budget limit. To do this, it uses privacy budget keys as received from the client that needs to consume the budget.
If the budget has not already been exhausted for the specified privacy budget keys, the transaction request is accepted, budget consumption is recorded in the ledger and a success code is returned to the client. If both transaction requests to each of the coordinators (Type-1 and Type-2) return successfully, the client can proceed with using the data to generate results.. If at least one of the transaction requests to the coordinators fails, the client fails the job, without generating a result.
The Aggregatable Report Accounting ledger transaction endpoint is authenticated with onboarded ad tech credentials. Each transaction request carries an authentication header, which is used for validating authentication and verifying authorization matching the credentials to only allow consuming budget for data the client owns.
Each coordinator deployment (Type-1 and Type-2) maintains per ad tech workload authentication credentials and permissions independently.
Credential management depends on the credential management system supported by the respective public cloud provider. Each ad tech requires onboarded credentials on both coordinator deployments (Type-1 and Type-2) to have their deployed workloads be able to interact with the coordinators.
The following endpoints are authenticated / authorized to onboarded ad techs:
- Encrypted private key split endpoint
- Cloud KMS key decryption - this endpoint additionally requires successful workload attestation for permission to use decryption keys
- (use-case dependent) aggregatable report accounting endpoint
Workload attestation is integrated with the respective public cloud provider's TEE platform and enforces access to cloud KMS decryption keys to allowlisted workload image hashes only. Access to the cloud KMS decryption keys is required to decrypt the respective coordinator private key splits.
As outlined in the call for feedback to consolidate coordinator services in one cloud, the key changes of this proposal are to operate the following services, consolidated in one cloud and serving workloads running in any of the supported workload public clouds:
- private/public encryption key generation and public key distribution
- wrapped private encryption key distribution
- authentication and authorization management
- (use-case dependent) aggregatable report accounting service
Workload attestation, private key split decryption with cloud KMS and therefore required authentication / authorization management will stay in the respective public cloud provider where the workload is running.
If the ad tech workload is operated in a public cloud different from where the coordinator services are deployed, a cross-cloud dependency will be added to enable communication with the consolidated coordinator components, and identity federation will be used for cross cloud authentication to obtain coordinator cloud credentials. Authorization permissions will be set on the federated identity.
The multi-party key generation will run in the coordinator public cloud and attestation of the key generation binary will be facilitated in the same public cloud the key generation is running in. The private key splits will be encrypted with the supported workload public cloud KMS service. E.g., a coordinator pair running on public-cloud-a serving workloads running in public-cloud-b will encrypt the private key splits with keys managed in public-cloud-b KMS. Public keys and encrypted private key splits will be stored in the same public cloud the key generation runs in.
Encryption keys for any supported public cloud will be served from the public cloud where the coordinator services run in.
Private decryption key splits encrypted with the respective cloud KMS of the public cloud where the workload is running in will be distributed to authenticated (through identity federation if applicable) workload clients of onboarded ad techs.
Workload attestation and private key split decryption will stay in the respective cloud where the workloads are running.
The aggregatable report accounting service will be operated from the coordinator public cloud. The flow to consume privacy budget will stay the same. Federated credentials will be used for authentication and authorization when the workload is running on a public cloud that is different from that of the coordinator services.
Authentication of ad tech workload credentials will be done through identity federation where credentials can be exchanged for federated credentials in the public cloud where the coordinator services are operated. Coordinators will configure Identity Provider (IdP) mappings for supported IdPs into federated credentials for onboarded ad techs.
Ad tech onboarding information will be maintained in both clouds, (i) the public cloud where the coordinator endpoints are running for identity federation and authorization and (ii) in the workload cloud for authentication and authorization to the workload cloud KMS.
Authentication against coordinator provided endpoints and public cloud endpoints where the coordinator is operated in will use federated credentials where applicable (for all workloads running in a different public cloud to the coordinator public cloud).
Authorization will be based on federated credentials and permissions will be configured on the on the federated credentials for all onboarded ad techs
Ad techs will continue to operate on their choice of supported cloud (AWS workloads will stay on AWS, GCP workloads will stay on GCP). This change will impact the coordinator services, where the cryptographic keys are held and the aggregatable report accounting ledger (relevant only for Aggregation Service) is operated.
We will continue to split the operation of the coordinator services between Google and an independent third party.
Ad tech workloads that are running in a supported public cloud that is different from the public cloud the coordinator is running in will have an added cross cloud dependency and metadata (onboarding data - account / credential id, reporting sites, aggregatable report accounting ledger data) maintained in the coordinator's public cloud.
With identity federation, the coordinators will configure Identity Provider (IdP) mappings to credentials in the public cloud the coordinators are operated in. Initially, the IdPs of supported public clouds will be trusted. Support for other trusted OIDC compliant IdPs may be added at a later date. Supported IdPs are expected to perform secure credential verification to obtain the respective IdPs credential tokens. These tokens can then be exchanged for federated credential tokens in the coordinator public cloud for onboarded credential mappings. Further requests to endpoints in the coordinator public cloud will use the federated credential tokens.
We expect minimal impact on ad techs running on any supported public cloud other than coordinator public cloud.
Calls to the coordinator services are not in a latency critical path. For Protected Auction Services keys are fetched during startup and refreshes are done asynchronously, for Aggregation Service batch processing will be minimally affected by small increases of latency on key fetches (keys are cached for 8hrs) and PBS calls.
Cost increases are expected to be minimal as calls to the coordinator services are infrequent and low data volume.
We expect to improve availability and disaster recovery measures through increased focus and resources to address these concerns. Resources that previously were split to maintain code bases to support deployment and operation of coordinator services in several clouds will now be able to concentrate on improving the reliability, availability, and resiliency of coordinator services focused on supporting deployment and operation in one public cloud.