Details on Attestation in TEE Aggregator

[eriktaubeneck]

The TEE version of the Aggregation Service for the Attribution Reporting API proposal states that:

Decryption and aggregation of raw aggregatable report data happens within a secure and isolated Trusted Execution Environment. This prevents adtech from accessing the decrypted inputs, intermediate data, and the decryption key.

I am assuming that the Confidential VM offering from GCP is one of the proposed cloud providers. When looking into this offering, it's not completely obvious how this guarantee is made, and it would be helpful to understand better how the API intends to do this.

Attestation of Code Executed The documentation only mentions a launch attestation report event, which attests to the boot state of the VM, but not the software that actually gets executed. I launched such an instance and was able to SSH onto the box and, as the tenant, view files and run commands. The proposal states:

Google will periodically release binary images of the aggregation server code for TEE deployment. A cryptographic hash of the build product (the image to be deployed on the TEE) is obtained as part of the build process. The build is reproducible so that anyone can build binaries from source and verify they are identical to the images released by Google.

Is the intention here that this binary release is a custom Linux engine? If so, is there any existing analysis and tooling around building such an image that limits the tenant to only executing the desired software and includes the necessary components of an image built from scratch?

This seems like an important feature, from the user agent POV, in order to trust that the system, operated by an adtech tenant, is actually unable to view the underlying attribution reports.

Attestation of SEV Mode When a Confidential VM is launched, the above mentioned launch attestation report event is generated. In testing, and the docs, it seems that this is simply a log that states it's in SEV mode:

sevLaunchAttestationReportEvent: {
    integrityEvaluationPassed: true
    sevPolicy: {
        debugEnabled: false
        sevOnly: true
        ...
    }
}

From the adtech POV, it seems that you would actually want to establish the root of trust all the way down to the hardware. I'm not an expert here, but my understanding was that the hardware manufacture, in this case AMD, runs essentially a certificate authority, which allows any user to verify that a cryptographic signature was generated by an authentic manufacturer chip (according to the manufacturer.) I wasn't able to find such a signature included in the launch attestation report event, nor any documentation on how a tenant might validate such a signature against a manufactures certificate authority.

The only component which seems to be possibly such a signature is value in the log:

sevLaunchAttestationReportEvent: {
    finalDigest: "j324ZkjlkYaklj/skljlj2908Aionkl"
}

The documentation doesn't seem to be clear on what this value actually is, or how you would validate it. (Also, in my quick poking around, it didn't show up in my own logs, but that may have just been a misconfiguration.)

Do such processes and documentation exist? From the POV of the adtech, this seems like an important component to establish the root of trust in the hardware (beyond simply trusting the cloud provider explicitly.)

[palenica]

Hi Erik,

Thank you for the detailed post. We are working on providing more information. For now, I'll just say that per our recent update, our initial implementation will support Trusted Execution Environments (TEEs) provided by Amazon Web Services.

[peking2]

@palenica Does it mean that it's AWS Nitro? Do you have any design details? Thanks.

[palenica]

Yes, this is AWS Nitro.

FYI, we have just published instructions, scripts and binaries needed for running the aggregation service (both locally in untrusted mode and in the cloud in AWS Nitro) if you'd like to take it for a spin. https://github.com/google/trusted-execution-aggregation-service/blob/main/README.md

We're working on publishing documentation, and getting the code in shape for open sourcing. Please stay tuned.

[fhoering]

Hello @palenica,

Any news on that ?

I had a look a the repo but the AWS lambda functions are only provided as JARs. I would expect this to be open sourced somehow.

Can you also share some documentation on the client part ? In particular what keys are used to encrypt the reports from inside the browser ? Does this also use the TLS protocol similar to intel SGX technology (described here). Is this already implemented in chromium ?

[renanfel]

Hi all. Thanks for your patience. Providing a few updates on this issue and questions raised.

1. We have open-sourced the Aggregation Service; see https://github.com/privacysandbox/aggregation-service
2. Since the last reply, AWS published documentation about the Nitro security model here.
3. For GCP, we plan to use Confidential Space (which is different from Confidential VM). Their security model is documented here.
4. Re encryption of reports - Our design is different from the one linked for Intel SGX. We rely on a Coordinator, which operates a key management system and handles attestation of the Aggregation Service (detailed explanation here). The Attribution Reporting API specification explains the method for the client to obtain the public key from the Coordinator, and to encrypt the payload using HPKE.

[yoavweiss]

I'm not sure why the compat label is appropriate here. Can y'all expand on that? (or modify the label)

[csharrison]

I'm not sure why the compat label is appropriate here. Can y'all expand on that? (or modify the label)

Oops that was a mistake. I think just "documentation" suffices here.