Skip to content

Latest commit

 

History

History
112 lines (58 loc) · 11.9 KB

public_cloud_tees.md

File metadata and controls

112 lines (58 loc) · 11.9 KB
Raw

Note: the explainer is posted in the Protected Auction repository, but applies to all Privacy Sandbox services.

Public Cloud TEE Requirements

Privacy Sandbox has established several APIs that allow off-device processing of user data in order to provide important functionality for API users. For example, the Attribution Reporting API uses Aggregation Service to aggregate data across multiple users. The Protected Audience API will use Bidding & Auction Services to expand real-time bidding and ad auctions from the user’s device to a server, and access Key/Value Services to provide real-time signals for ad auctions.

Off-device processing must be done in a way that protects confidentiality of user data, and meets the privacy and security goals of Privacy Sandbox and the specific APIs. To meet such goals, Privacy Sandbox requires that processing be done in an attested and isolated environment (also referred to as Trusted Execution Environment, or TEE), using software provided and approved for this purpose by Privacy Sandbox. Other mechanisms to protect user data include adding noise to outputs.

Privacy Sandbox started by supporting TEEs on Amazon Web Services (AWS) and Google Cloud Platform (GCP). These platforms were chosen for their security standards, availability of solutions, and because of feedback from ad techs.

In this explainer, we focus on expansion to additional trusted compute environments offered by public Cloud Service Providers (CSPs). We propose criteria these environments must satisfy in order to be eligible for processing user data generated by Privacy Sandbox APIs. The technical and security criteria outlined in this document are aimed at protecting the user data handled by Privacy Sandbox APIs. Each adopter of a Privacy Sandbox API should continue evaluating which cloud solution best fits their needs.

This explainer focuses on TEEs whose isolation and integrity guarantees are provided by a CSP. TEEs whose isolation and integrity properties come from other sources (such as private clouds or ad tech data centers) pose additional technical and security challenges, and are out of scope for this explainer and will be considered separately.

Overview of Cloud-based TEEs

Data is typically processed in TEEs as follows:

  1. A CSP offers a secure computing environment that satisfies Privacy Sandbox physical and logical security, isolation, confidentiality and attestation criteria.
  2. An Operator that wishes to use Privacy Sandbox APIs (such as an ad tech company) creates instances of this secure compute environment, configured to run a specific workload binary (service) approved by Privacy Sandbox.
  3. The workload requests Coordinators to provide credentials (such as cryptographic keys) that would allow it to process encrypted user data. The Coordinators decide whether to release such credentials after inspecting and verifying: claims about the security, integrity and confidentiality properties of the execution environment, the identity of the workload, and the identity of the Operator.

Criteria

Cloud-provided Trusted Execution Environment (Cloud TEE)

A Cloud TEE must satisfy the following criteria to be eligible for running trusted Privacy Sandbox workloads1:

  • The environment must be secure, private, and isolated. The CSP must implement controls to prevent all parties (including the workload Operator, and agents or employees of the CSP) from:

    • Viewing, adding, removing or altering data while it is in use within the TEE (referred to as Data Confidentiality and Data Integrity)
    • Adding, removing, or altering code executing in the TEE (referred to as Code Integrity)
    • Otherwise tampering or interacting with the workload (except via APIs explicitly exposed by the workload)

  • The environment must be remotely attestable. This means that the CSP must provide an attestation report2 with claims about the state of the TEE, including:

    • Whether the workload meets the above requirements that the environment is secure, private, and isolated
    • Cryptographic measurements of the workload and any security-relevant software components running in the TEE
    • Identity of the operator

    The above claims must be exposed via a secure API, which is accessible to an external Relying Party (such as a Coordinator) when evaluating whether the instance can be trusted with credentials such as decryption keys. Additional information about the role of Coordinators is available in our service-specific explainers: Protected Audience services and Aggregation Service.

  • The TEE must be commercially available to a wide range of customers, including academic and security researchers.

  • The TEE must be able to run a Linux-based containerized workload with access to functionality such as networking, load balancing, and object storage.

Security and trust of the CSP

CSPs need to employ a combination of technological (hardware and software) and operational measures to provide Cloud TEEs that meet the criteria. For example:

  • CSPs play a crucial role in procuring, hosting, maintaining and physically securing server hardware.
  • CSPs are responsible for maintaining integrity and security of their internal systems, enforcing proper access controls (such as prevent unilateral access from CSP insiders and human operators), and maintaining isolation of workloads from each other, and from the underlying compute infrastructure
  • CSPs ensure isolation of the confidential workload from the workload's operator, and provide secure infrastructure that enables remote attestation by third parties.

Preferably, CSPs should employ technological measures that are externally verifiable (in concert with internal security measures and operational best practices) to provide protection of their TEEs. For example, CPU technologies such as AMD SEV-SNP and Intel TDX provide a layer of protection and assurance with a root of trust that is external to the CSP.

We recognize that there are significant hurdles in having all measures externally verifiable (such as limited attestation support by processor-based TEEs, and confidentiality of code and supply chain). We will therefore validate that the CSP and the remote attestations are trustworthy using the following criteria.

  • Compliance with recognised standards on cloud security. In particular, ISO 27001, ISO 27017 and ISO 27018, outlining information security controls for cloud services.
  • Certification from cloud security industry bodies. We plan to accept Level 2 in Cloud Security Alliance’s STAR program, which requires a third-party audit of the CSP’s adherence to security frameworks. We are open to feedback on other established certification programs which provide comparable guarantees.
  • The CSP makes a public commitment to uphold the security and privacy guarantees of their Cloud TEE solutions, including that the Cloud TEE meets the requirements described earlier and the CSP cannot or will not undermine the security of the data processed in environments under their control. In addition, an independent security assessment conducted by a reputable entity is preferred.
  • Inclusion in an established global industry research report on public cloud offerings. We plan to accept the Gartner Magic Quadrant for Strategic Cloud Platform Services report. Gartner established itself as a trusted consulting firm for technology, and conducts independent research into the offering by CSPs, including feedback from customers and size of the CSP business. Inclusion in their report indicates that the CSP has gained users’ trust, and has a major reputational stake in ensuring secure provision of cloud infrastructure. We are open to feedback on other established independent research reports which provide comparable guarantees.
  • The CSP (including parent company) is headquartered in a supported country or region (currently including the EEA, UK, and US).

Updating requirements

In a competitive marketplace, we expect CSPs to be proactively working on improving the security posture and transparency of their confidential computing offerings over time. As industry standards evolve, we may update the requirements. We may similarly update requirements as we gain more experience in reviewing Cloud TEE solutions.

We'll provide advance notice if and when requirements are updated.

Review Process

To initiate a review of a Cloud Service Provider, please file a GitHub issue in this repository using the template provided in this explainer, and provide all required evidence. We may also independently initiate review processes using the same process, and will document our previous decisions to approve AWS and GCP.

We aim for the review process and discussion to be transparent. However, some discussions may be private to protect confidential information by CSPs and to avoid disclosing internal security practices. We welcome feedback from the ecosystem on any review request.

If a CSP is approved, we will prioritize starting the work required to enable the CSP based on the benefits to the ecosystem, including demand from users of the Privacy Sandbox TEE services, the effort required to enable the CSP, and other priorities. Initial approval of a CSP is subject to review throughout the development process, as technical challenges may arise that require us to delay or block enabling the cloud. We will provide appropriate notice when we decide which CSPs to support, and the expected timeline (including any changes to the timeline as appropriate).

Sunsetting support

We will deprecate support for specific Cloud TEE solutions that no longer meet the security or privacy bar. Such deprecation may be a result of updated requirements or of actions (including lack of action) by the CSP which undermine the security of the data processed in environments under their control.

We'll provide advance notice and support for migration if and when solutions are deprecated.

Template for CSP approval GitHub Issue

Name and web address for the Cloud Service Provider: <>

Short description of the Cloud TEE solution, including security properties, remote attestation and workload capabilities. Please include links to supporting documentation **. <>

Short description of security and trust of the CSP, including compliance with ISO standards, Certification from cloud security industry bodies (such as STAR Level 2), and inclusion in a research report on public cloud offerings (such as Gartner’s public cloud report) . Please include links to supporting documentation **.

(optional) Relevant factors for prioritization of review of the Cloud TEE solution and, if approved, enabling support. For example, demand for solutions **:

** We understand some information may not be public, and we can accommodate alternative ways to provide supporting evidence.

Footnotes

  1. The TEE criteria are aligned with industry definitions for TEE, such as those by the Confidential Computing Consortium ↩

  2. ‘Attestation report’ is the technical term used to describe the report provided by the CSP on the state of the workload and TEE. It is not related to Privacy Sandbox enrollment attestation. ↩