Attested Request Handling

The PCC application protocol preserves client anonymity and efficiently routes traffic through the PCC fleet.

Overview

The same wire protocol carries a request from a user’s device to the node that processes it, whether that node is an Apple silicon node or a Google Cloud node. Once the PCC Gateway routes a request to a node, the node terminates the connection, decrypts the request with keys released only against its valid attestation, and hands the decrypted request to the application that services it in a Per-request isolation that is torn down when the request completes.

A node advertises itself as available for requests only once it is booted, healthy, and ready to serve. As part of becoming ready, the node creates a Request Encryption Key (REK) pair, to which users’ devices encrypt requests. The node assembles an attestation bundle covering this key pair, containing all the information necessary for a client to determine whether the node is securely configured and is running an inspectable release. The node then registers with the PCC Gateway to indicate it can receive requests. Each platform holds the REK and binds it to the node’s attested state differently:

Apple silicon nodes: The key is held in the Secure Enclave and its usability is bound to the measured boot state, so it works only while the node remains in the state its attestation vouches for. See Apple Silicon Root of Trust and On-Node Request Termination.
Google Cloud nodes: The key is tied to the node’s attested state through the attestation the verifier checks when the key is issued, and is then governed by a bounded lifetime rather than by continuous boot-state binding. See Google Cloud Node Attestation.

Application protocol

The first step in the PCC application protocol happens before a request is submitted, often overnight. The user’s device makes a query using Oblivious HTTP to the PCC Gateway to prefetch a set of attestations. The device can use these attestations later in PCC queries. If any of the nodes from which the device received a prefetched attestation are free, the PCC Gateway can route the query directly to that node, which avoids the need for an extra network round trip before processing begins.

These prefetched attestations raise an additional targetability concern. Because prefetched attestations are client-specific state, the client needs to mitigate the risk that the PCC Gateway might fingerprint a client based on the attestations that it uses. The client achieves this by maintaining a set of at least 40 prefetched attestations and selecting at most two of them at random for each request, which minimizes correlations across requests.

When submitting a request to PCC, the client generates a unique symmetric Data Encryption Key (DEK) for that request and uses it to encrypt the request payload.

The PCC Gateway provides the client with attestations, covering the REK, for a set of nodes eligible to serve a request. Following the flow in Node validation, the client validates the attestations to verify that the nodes are candidates to handle the request. For each node with a client-validated attestation, the client wraps the DEK using Hybrid Public Key Encryption (HPKE), as defined in the Oblivious HTTP specification. The recipient key for each HPKE operation is the REK, and the client’s sender key is a unique ephemeral key, generated randomly by the client for each node.

The PCC Gateway then routes the request to a specific PCC node, and once the node is ready to return a response, the node uses the HPKE envelope to generate a key for response data. The node then uses this key, instead of the DEK, to encrypt its response so the client knows which node sent the response data.

This collection of keys provides an end-to-end encrypted, bidirectional tunnel, cryptographically tied to the REK and the node attestation. This tunnel enables transmission of request and response data, as well as protocol-control messages, between the user’s device and a PCC node.

To provide the client with attestations from appropriate PCC nodes, the PCC Gateway must be able to determine which nodes can handle a specific request. To enable this, a small amount of metadata is passed by the client to the PCC Gateway outside of the HPKE-protected tunnel. This metadata is protected by Oblivious HTTP and not observable by third parties. This metadata doesn’t contain personally identifiable information, or any information that might allow for deanonymizing the user or compromising their data.

User requests are initially handled by a proxy node, a PCC node that runs a PCC cloud applications and forwards requests to other PCC nodes. When issuing outbound requests, the same application protocol is used between the two PCC nodes as between the user’s device and the initial PCC proxy node. For this, the proxy node queries the PCC Gateway for a PCC node that can handle its request. The PCC Gateway chooses a node and returns the node’s attestation, which the proxy node validates to establish Transitive Trust on behalf of the user’s device. The proxy node then re-wraps the client-provided DEK to the PCC node’s REK and uses the DEK to encrypt the request payload for that node.

[Image]

In detail, the steps of this flow are:

Device: Generate the DEK.
Device: Assemble the request by encrypting the request body with the DEK and constructing a plain text envelope with any metadata required to route the request.
Device: Submit the request to the PCC Gateway. If any prefetched and validated node attestations are available, provide the symmetric keys wrapped to those nodes as a sidecar.
PCC Gateway: Search for an appropriate node to handle the request. Determine if client-provided prefetched HPKE keys correspond to acceptable nodes; if found, skip to (6). Otherwise, select candidate nodes and return their attestations to the client.
Device: Verify each attestation provided by the PCC Gateway, up to a fixed limit. If valid, provide the PCC Gateway with an HPKE-wrapped copy of the DEK over the same connection. Otherwise, reject the node.
PCC Gateway: Select a node from the list of candidates and notify the client of the selection.
PCC Gateway: Forward the node-specific wrapped DEK to the selected node, along with the encrypted invocation request.
Proxy node: Determine what types of worker nodes are required to process the request and provide the corresponding routing metadata to the PCC Gateway.
PCC Gateway: Select a worker node that matches the provided constraints and provide the node’s attestation to the proxy node.
Proxy node: Verify the attestation and, if valid, proceed by sending a Request execution log entry with the validated attestation bundle back to the user’s device.
Proxy node: Forward the re-wrapped DEK and request payload to the worker node, routed through the PCC Gateway.
Worker node: Process the request, while generating and sending encrypted response data back to the client, routed through the PCC Gateway.

At the conclusion of this procedure, the node can begin delivering incremental results, if any, and then deliver the final result data to the client. The response is encrypted using the HPKE-derived key established with the client or the proxy node.

Node validation

Before a user’s device releases the DEK to a PCC node — and therefore grants access to the user’s request — the device validates the node’s attestation. This is the single trust decision at the heart of PCC, and it is deliberately narrow. The node presents two things: a public key and an attestation. That attestation carries cryptographic proof that the node owns the corresponding private key, together with the node’s software measurements. The device compares those measurements against the public, append-only Release Transparency of PCC software releases, and it releases the DEK only if the measurements appear in that log.

The device trusts a node not because Apple asserts the node is trustworthy, but because the node presents attested measurements that match a release Apple has published for inspection. A node whose measurements are absent from the log cannot produce an attestation that passes validation, so user data does not reach it. Because the log is append-only and publicly auditable, no software reaches production without Apple first recording it in a log open to researchers; how completely each recorded component can then be independently reproduced or examined varies, as Google Cloud Software Transparency documents.

The decision is the same on both platforms, and the same whether the user’s device makes it or a Transitive Trust.

Across both platforms, validating an attestation confirms three things:

Authentic hardware: The node presents evidence, chained to an immutable hardware root of trust, that it is genuine, integrity-checked hardware rather than an impostor.
Expected security state: The evidence shows that the node booted into the strict security state that PCC requires, so the device can confirm that the expected security policies are being applied.
Inspectable software: The software measurements in the attestation correspond to a software release recorded in the transparency log, so the software is subject to our Release Transparency promises. A proxy node’s attestation includes an inclusion proof anchored to a specific log revision; by validating that proof, the device commits to that revision as its trusted view of the log, and the proxy validates every node it transitively trusts against the same revision.

Both the evidence a node produces and the checks that establish authentic hardware and expected security state differ between the platforms, because the underlying hardware is different:

Apple silicon nodes: Validation is performed by the CloudAttestation framework against evidence rooted in the Secure Enclave and Boot ROM. The device checks that the node holds a valid certificate from the Data Center Attestation Certificate Authority and that the Certificate ceremony process. See Apple Silicon Root of Trust for the root of trust these checks rely on.
Google Cloud nodes: Validation checks evidence from several independent hardware roots of trust, bound together in one attestation bundle. See Google Cloud Node Attestation.

In both cases, the client reaches the same conclusion: the node’s attested measurements correspond to logged, inspectable software, and its hardware presents valid integrity evidence.

The third check — confirming the software is inspectable — is platform-neutral. Validation verifies that our Release Transparency process has logged these measurements for public inspection, which enables our Verifiable Transparency guarantee: a node receives users’ data only when its attested measurements correspond to code Apple has publicly logged for inspection. To accomplish this, the client validates consistency and inclusion proofs provided as part of the attestation bundle against the local milestones available on the device. When the user’s device accepts a proxy node’s attestation, it also trusts the log revision that the attestation anchors. The proxy node then checks each worker node’s release for inclusion at that Trusted log revisions. Transitive trust therefore carries verifiable transparency across every PCC node.

To enable security researchers to inspect the attestations being returned to their devices, the Apple Intelligence Report includes information about the attestations used in each request. For more information about viewing these logs and their contents, see Appendix: Apple Intelligence Report.

Node selection

PCC nodes with attestations that are considered for use in a specific request by a user’s device come from two sources, both part of the application protocol:

Prefetched: locally cached attestations acquired during a prefetch step.
Just-In-Time: attestations provided by the PCC Gateway during the request flow.

The Node validation process enables our verifiable transparency property, but to enable our Non-Targetability property we need to consider the process by which a device determines the set of PCC nodes to which it encrypts a request. A specific request should be able to be decrypted only by a subset of PCC nodes, so if a single node is compromised, it’s not able to decrypt more than a small portion of incoming requests. This approach reduces the value of a targeted compromise by ensuring that such an attack is unlikely to decrypt requests from a specific user or device, because the set of nodes for that request is unlikely to contain the compromised node.

There is a natural tension between this goal and optimally selecting nodes to service requests: if there are fewer nodes that can decrypt a request, it’s less likely that a node is available to immediately service an incoming request. Each PCC node can handle a limited number of requests at a time, and some requests can take several seconds, so PCC must avoid queuing multiple requests on a small set of nodes. To ensure that PCC can operate efficiently and that slow clients cannot cause a denial of service, PCC must also avoid reserving capacity on a node until an incoming request is fully received and able to be processed.

PCC’s node selection process therefore tries to balance these two goals simultaneously:

Ensure that most requests experience no additional latency due to queueing or additional round trips.
Encrypt to the minimum required set of PCC nodes.

Balancing these goals requires carefully tuning the size k of the set of PCC nodes to which the client encrypts a request. k must be large enough to accomplish our latency goals but small enough to ensure non-targetability. To strike the right balance, the quality of service is defined as PCC should be able to handle 99 percent of incoming requests without any additional latency while operating at an average of 90 percent utilization.

For this reason, PCC requests go to PCC proxy nodes first, which can handle a larger number of concurrent requests than PCC worker nodes. This makes it more likely that a selected node can handle the request and reduces k significantly.

Selecting the size of k

To determine the right value of k, PCC’s design needs to consider two cases:

The client provides prefetched attestations with the initial request body, which PCC uses to avoid an additional round trip with the client. Two prefetched attestations from the client are sufficient to meet the goals of handling 99 percent of requests without queuing or falling back to just-in-time attestations and maintaining 90 percent utilization.
The PCC Gateway receives a request without prefetched attestations and determines the set of just-in-time PCC node attestations that it returns to the client. To minimize the requirement on k in this case, the PCC Gateway uses current service state to select candidate nodes that are likely to be idle when the request arrives, keeping k=2 for just-in-time attestations.

Some scenarios might result in none of the prefetched attestations being valid, such as failover between data centers, so the client must be able to provide both of these sets of attestations in the same request context, producing a worst-case value of k=4. To keep PCC resilient against targeted hardware attacks, the client enforces an upper bound on k.

The number of just-in-time attestations provided for a request is determined by the PCC Gateway, which often returns fewer attestations than allowed by these limits if system utilization permits. To protect limits from being exceeded if the PCC Gateway is compromised, the user’s device caps the number of attestations it uses at these values, regardless of how many attestations the PCC Gateway offers. The PCC client also supports a server-provided configuration so we can dynamically lower (but not raise) the client’s limit on k to evaluate the impact of smaller k values on performance. This configuration is fetched through an OHTTP relay, ensuring that an attacker cannot target changes to this value at a specific user.

Node selection for requests from proxy nodes

When PCC proxy nodes make outbound requests to other PCC nodes, the PCC Gateway selects a node matching the constraints specified by the proxy node. Because latencies within a data center are low and the proxy node is always expected to respond quickly, the PCC Gateway selects and reserves a single node to handle the request. The proxy node validates the selected node’s attestation before encrypting the request payload to the node and including the selected node’s attestation in a Request execution log streamed back to the client. Without additional safeguards, this routing would let a compromised PCC Gateway direct many requests to a small set of compromised nodes.

Two mechanisms validate that the PCC Gateway is distributing nodes across the PCC fleet appropriately:

For users who opt in to sharing analytics data with Apple, the PCC client reports statistics that describe the flatness of the distribution of the PCC nodes the PCC Gateway offers the device. These statistics cover the k attestations a device receives for a client-originating request.
Security researchers can use the Apple Intelligence Report to view the hardware identity of the PCC nodes used in each request, including the nodes a proxy node reaches, and to confirm they are appropriately distributed. For more information, see Appendix: Apple Intelligence Report.

Beyond these detection-based checks, the proxy node selection process incorporates two proactive protections. First, the routing metadata that proxy nodes provide to the PCC Gateway is designed to minimize the data revealed outside the trust boundary. Second, for requests that require stronger anti-targetability guarantees, the system uses a negotiation protocol that prevents the PCC Gateway from unilaterally choosing which node handles a request. Together, these mechanisms help ensure that even if the PCC Gateway is compromised, an attacker cannot reliably direct specific users’ requests to compromised nodes.

The system adapts its selection approach based on the context of each request, balancing non-targetability with operational efficiency. Requests already protected through other privacy mechanisms can use more efficient routing, while subsequent requests use additional protections to maintain non-targetability throughout multi-turn interactions. PCC uses one of three approaches:

Free choice: When a request’s non-targetability is already assured by other means, the PCC Gateway may select any eligible worker node, providing the most efficient routing.
Pick negotiation: When stronger protection is required, the proxy node and the PCC Gateway share node selection, so the Gateway cannot unilaterally determine which node handles the request.
Trusted reuse: Once a node has been selected through a non-targetable method, later steps of the same request can reuse it, preserving non-targetability while avoiding repeated negotiation.

PCC applies the more conservative pick negotiation in contexts that call for stronger protection, for example, after an External tool calls, which sends query-derived data outside the trust boundary. From that point, the proxy node restricts subsequent node selections: the PCC Gateway can route to an unused worker node only through pick negotiation. The PCC Gateway may still reuse a node the request has already reached.

Privacy-preserving routing metadata

To enable informed routing decisions, proxy nodes provide routing metadata to the PCC Gateway that describes the expected computational requirements of a request. This metadata allows the PCC Gateway to select appropriate worker nodes without exposing information that could be used to fingerprint or target specific users.

To protect privacy, proxy nodes degrade routing metadata before transmission in two ways. First, the proxy node converts precise workload estimates into coarser-grained values by bucketing them into a limited set of possible values, reducing the precision of the routing metadata. Second, the proxy node adds symmetric noise to help prevent fingerprinting, reducing the accuracy of the metadata. Together, these mechanisms maintain enough information for effective load balancing while protecting user privacy.

Worker node selection with limited candidate sets

When anti-targetability protection is required, the PCC Gateway provides multiple candidate worker nodes, and the proxy makes the final selection. The proxy can also reuse previously selected nodes during this process.

The proxy communicates requirements for how many candidate nodes it needs. The PCC Gateway responds with a set of eligible worker nodes. The proxy then selects from the provided candidates using a cryptographically secure selection method. The PCC Gateway reserves one of the nodes the proxy returns, queueing if necessary, and returns its attestation for validation.

This approach helps prevent a compromised PCC Gateway from precisely controlling which node handles each request. To reliably route requests to compromised nodes, an attacker would need to compromise a significant portion of the fleet, increasing the scale and detection risk of an attack.