Anonymous Request Routing

PCC routes every request through a third-party relay and authenticates it with unlinkable tokens, so no component learns who sent it.

Overview

[Image]

The PCC request flow starts on the user’s device, the root of all security and privacy policies in PCC. The Apple Intelligence orchestration layer routes a request to a server-based model; the device authenticates to obtain an anonymous credential, then submits the request through a third-party relay so that no data-center component learns which device sent it.

The Node selection then offers the device a set of nodes eligible to serve the request. The device Node validation and wraps the request’s encryption key to the nodes it accepts, so the request is readable only on a node whose attested measurements match a release recorded in the Release Transparency. The node that receives the request On-Node Request Termination, and Transitive Trust when it cannot serve the request alone. The flow is the same whether an Apple silicon node or a Google Cloud node serves the request.

The sections that follow describe the current flow on iOS and macOS 27 and later. iOS and macOS 26 and earlier use a two-step token issuance flow with a separate PCC Identity Service; see Legacy authentication flow for the differences.

Apple Intelligence orchestration

Apple Intelligence experiences are managed by an orchestration layer on the user’s device, which is responsible for:

  • Routing inference requests between on-device and server-based models

  • Prewarming on-device models and connections to server-based models

[Image]

These tasks are handled by the modelmanagerd daemon, which in turn uses extensions to service requests for the on-device and server-based models. Requests to the server-based models in Private Cloud Compute are handled first by the PrivateMLClientInferenceProviderService extension and then passed to the privatecloudcomputed daemon. modelmanagerd is responsible for deciding how to prewarm and execute intelligence requests based on user activity and device context.

When the user invokes an Apple Intelligence feature, the device can prewarm connections so it’s ready for intelligence requests. If needed, privatecloudcomputed executes its authenticates and Application protocol. When the user triggers an inference request, modelmanagerd routes appropriate requests to the PCC extension.

A given intelligence feature may use multiple requests, and the requests may use different models or back ends. modelmanagerd is aware of the relationship between these requests; it assigns a “Session UUID” to related requests to the same model and a “Session Set UUID” for related requests across all models. These identifiers are distinct from any request identifiers that are shared with PCC, and the mapping between these identifiers is not shared with Apple.

Client authentication

PCC applies limits to its use to prevent malicious or fraudulent use. This includes:

  • Limiting which devices or users can access the service

  • Imposing reasonable rate limits on those users and devices

However, Non-Targetability rules out traditional authentication: requiring an account or device credential when submitting a request would tie requests to an identity. Instead, PCC enforces these policies while preserving anonymity and non-targetability by using an identity service that vends cryptographically unlinkable tokens. The client authenticates to the Token Granting Service (TGS) to receive One-Time Tokens (OTTs), which it then attaches to its requests to PCC.

[Image]

  • The client authorizes itself and sends an OTT Request to the Token Granting Service (step 1 in the flow diagram above).

  • The Token Granting Service verifies that a specific client and device are eligible to use PCC, and applies an appropriate rate limit (step 2).

  • The Token Granting Service issues a batch of OTTs (step 3) if the user is under their rate limit. OTTs are built using RSA Blind Signatures, as detailed in RFC 9474 and used in Privacy Pass (RFC 9578). The blindness property of RSA Blind Signatures guarantees that the OTT Redemption is cryptographically unlinkable to the OTT Request that the client sent, including authentication information.

  • For each request to PCC, the client attaches one OTT as proof that it is authorized by the Token Granting Service to use PCC (step 4). The PCC service verifies this OTT using the OTT public key, confirming the request is authorized without learning any information about the user or device from which the request came (step 5).

Once a client runs out of OTTs, it can request another batch by repeating steps 1-3 above. Because the OTT Redemption is cryptographically unlinkable to the OTT Request that the client sends during authentication, the user’s identity can’t be unmasked during inference, and requesting more OTTs doesn’t leak any information about a specific client’s PCC usage pattern.

Network transport

Apple routes all requests to PCC through a third party to conceal the source IP addresses from the PCC infrastructure. Requests are protected with the chunked variant of the Oblivious HTTP protocol.

In this routing approach, clients:

  • Encrypt requests using Hybrid Public Key Encryption (HPKE) and the public key configuration of Apple’s Oblivious Gateway (OG).

  • Randomly select among multiple Oblivious Relays (ORs) operated by distinct third parties, currently Cloudflare and Fastly.

  • Send messages to the OG through the OR, which provides a secure HTTP proxy.

Like iCloud Private Relay, clients use HTTP/3 to communicate with the ORs and fall back to HTTP/2 when HTTP/3 is not possible. They use Publicly-Verifiable RSA Blind Signature Privacy Pass tokens to authenticate to both the ORs and OGs. Clients present different tokens, signed by different keys, to each OR and OG.

The Oblivious HTTP key configuration and the signing key that PCC uses for the Token Granting Token (TGT) or OTT must not enable targeting of specific devices:

Oblivious HTTP

If a unique OHTTP public key were provided to a specific client, the Oblivious Gateway that decrypts a request could identify which requests that client submitted. This scenario is discussed in the Privacy Considerations section of RFC 9458.

TGT and OTT

If unique token public keys were provided to a specific client, the client’s token-issuance requests would receive blinded tokens signed with unique keys, enabling identification during token verification.

PCC is designed to mitigate these targeting concerns by using the Release Transparency. The keys advertised to clients are published to the transparency log, and clients confirm that the keys they receive have been recorded in the transparency log. Security researchers can use the transparency log to verify that only one set of keys is in use in a given time period.

Cost feedback

Starting in iOS and macOS 27, the updated authentication flow allows PCC to account for inference requests of varying costs and factor these costs into a user’s rate limit. The PCC application calculates each request’s cost, and CloudBoard composes a cost token. To preserve non-targetability, the cost token carries only the cost information, token issuer metadata, and bucketed timestamps. It does not include the raw model details or other per-request data used to compute the cost.

The protocol for reporting these costs proceeds as follows:

  • While processing a request, the PCC application calculates the cost of the request, which CloudBoard composes, signs, and returns as a cost token, a JSON Web Token, in the encrypted response body to the client.

  • Later, the client submits its accumulated cost tokens to the PCC Cost Aggregation Service, using OHTTP to help ensure this request is unlinkable to any other traffic from the client.

  • The PCC Cost Aggregation Service uses the cost tokens to calculate a total amount to refund to the client. It returns one or more cost denominations, Private Access Tokens that sum to the total refund amount. Using a batch of Private Access Tokens to represent the total refund helps minimize the amount of information about the requests that is communicated through the refund process.

  • The client can submit any cost denominations it possesses when requesting a new batch of OTTs. The Token Granting Service reconciles these credits against estimated costs accrued by the client when determining the client’s rate limit.

Legacy authentication flow

On iOS and macOS 26 and earlier, the client first obtains a TGT from the PCC Identity Service and then exchanges it for OTTs at the Token Granting Service. Starting with iOS and macOS 27, the PCC Identity Service capabilities are merged into the Token Granting Service, and the client authenticates directly, as authenticates describes. This section describes the legacy two-step flow and its associated fraud data protocol.

Legacy client authentication

In the legacy flow, the client obtains a Token Granting Token from the PCC Identity Service and redeems it for a batch of OTTs at the Token Granting Service, as the following diagram shows.

[Image]

  • The client authorizes itself and sends a TGT Request to the PCC Identity Service, which is a separate entity from PCC and plays no role in request routing or processing (step 1 in the flow diagram above).

  • The PCC Identity Service verifies that a specific client and device are eligible to use PCC, and issues a TGT as proof of eligibility (step 2). TGTs are issued on a per-user, per-device basis and are built using RSA Blind Signatures, as detailed in RFC 9474 and used in Privacy Pass (RFC 9578). The blindness property of RSA Blind Signatures guarantees that the TGT Redemption is cryptographically unlinkable to the TGT Request that the client sent, including authentication information.

  • The client sends the TGT to the Token Granting Service, along with a Batch Request for OTTs (step 3).

  • The Token Granting Service checks that the TGT is valid and that it has up-to-date fraud data for that TGT. If updated fraud data is required, this is indicated to the client, which reissues the request following the fraud data protocol.

  • The Token Granting Service then returns a batch of OTTs (step 4), enforcing the appropriate rate limit based on the TGT’s fraud data.

  • For each request to PCC, the client attaches one OTT as proof that it is authorized by the Token Granting Service to use PCC (step 5).

  • OTTs are also built using RSA Blind Signatures, which means that the OTT Redemption is publicly verifiable and is also cryptographically unlinkable to the OTT Batch Request that was sent by the client alongside the TGT Redemption. These properties allow the PCC service to use the OTT public key to verify that the OTT is valid without learning any information about the user or device from which the request came (step 6).

  • The client includes the TGT in the body of the encrypted request, which only the PCC node can decrypt. The node may check that the TGT is valid prior to processing the request (step 7). The inclusion of the TGT in the body of the encrypted request makes future abuse-mitigation options available, but these options are not currently implemented.

Once a client runs out of OTTs, it can request another batch of OTTs by repeating steps 3 and 4. Because the TGT Redemption is cryptographically unlinkable to the TGT Request that the client sends alongside its authorization information, requesting more OTTs doesn’t leak any information about a specific client’s PCC usage pattern.

Fraud data protocol

The Token Granting Service (TGS) uses a Fraud Detection Service (FDS) to make anonymous fraud determinations about transacting entities. We designed the fraud data exchange protocol to preserve privacy and non-traceability in the following ways:

  • Minimize data sent from the fraud scoring service to TGS, with size limits enforced by the user’s device.

  • Keep requests for fraud scoring and TGT redemption unlinkable.

The fraud data associated with a TGT is assigned or updated using the following process:

  • The PCC client issues a batch request for OTTs to the Token Granting Service.

  • TGS responds to the client with a data-refresh challenge, which includes up to 8 bits of reported data.

  • The client makes a request to the FDS service and provides the 8 bits of data received from TGS.

  • FDS provides the client with an updated data value in a signed message, using blind signatures.

  • The client reissues the OTT request to TGS while presenting the updated data value provided by FDS.

  • TGS then returns OTTs after applying appropriate controls (such as rate limit) based on the updated data associated with the TGT.

  • TGS continues to associate the updated data with the TGT, so subsequent OTT requests use that data.

When TGS requires fresh fraud data, it restarts this process.