Non-Targetability

Overview

[Image]

An attacker who wants one specific user’s data has a much simpler task if they can steer that user’s request to a node they control. An attacker must not be able to compromise personal data that belongs to specific, targeted Private Cloud Compute users without attempting a broad compromise of the entire PCC system. Where PCC’s other requirements govern what happens to a request once it reaches a node, non-targetability governs which node a request reaches in the first place, and whether an attacker can arrange for that node to be one the attacker controls.

Non-targetability belongs to PCC’s Verified service and cloud layer, and it closes the operator attack of user-targeted substitution: singling out a chosen user and routing that user’s request to software or hardware the operator has compromised.

PCC provides three properties to meet this requirement:

Anonymous request routing

An attacker must not be able to steer a targeted user’s request onto a node of the attacker’s choosing, because routing depends only on the request’s routing metadata and not on the identity of the user or the device.

Target diffusion

Each node can decrypt only a small share of incoming requests, so reaching most requests means compromising many nodes, not one.

Routing transparency

PCC streams the attestation of every node that handled a request back to the user’s device, so the device can audit the routing PCC performs rather than take it on trust.

A request travels from a user’s device to a PCC node through the third-party relay, the PCC Gateway, and the network between them. All of that infrastructure sits outside the trust boundary, and PCC’s threat model treats it as attacker-controlled rather than merely attacker-observed. Enforceable Guarantees keeps a request encrypted to its destination node across every hop, so none of this infrastructure can read a request; non-targetability adds the stronger property that even an attacker operating this infrastructure cannot single out or steer a chosen user’s request. The threat model also includes attackers with the resources and expertise to subvert a node’s hardware protections, and the physical access to attempt it.

We believe non-targetability is fundamental to a private cloud AI service because it sets the terms for such an attack across the whole design:

• It forces an attacker seeking a particular user’s data to compromise the system broadly rather than a single node.

• It forces an attacker to mount a hardware attack at fleet scale. Subverting a single node is already expensive, a cost that each platform’s hardware design and life cycle establish, and admitting a node an attacker built instead requires a Multi-party control. Subverting enough nodes to reliably catch a chosen user’s request is far more expensive still, and far more likely to be detected.

• It helps ensure that data that does leak, for example, through an undisclosed side channel, is difficult to attribute to a specific user.

Anonymous request routing

Non-targetability starts by denying an attacker any way to tell whose request is whose. A request’s routing metadata is the only portion readable outside the trust boundary. It carries only the context PCC needs to direct the request to the right model, and nothing that identifies the source device or user.

Implementing this starts with authentication: a conventional cloud service authenticates each request with a token tied to the user’s account, which by design reveals who is making the request. PCC instead authorizes requests with Client authentication based on RSA Blind Signatures. A device obtains a batch of these credentials in an authenticated exchange and then spends one to authorize each request. The blind signature makes a spent credential cryptographically unlinkable to the exchange that issued it, so PCC can confirm a request comes from an entitled user without learning which user it is. An attacker watching the point where PCC decides whether to serve a request therefore cannot pick out a chosen user’s traffic.

Anonymous credentials still leave one identifier exposed: a request sent directly to PCC carries the device’s source IP address, which an attacker positioned to observe the request might use to recognize or locate a user. PCC therefore routes requests through Network transport that strips the source IP address before a request reaches PCC. Because a separate party operates the relay, associating a request with an IP address requires compromising both the relay and the PCC Gateway.

Anonymous credentials must also accommodate the service’s operational needs. PCC must be able to enforce eligibility and per-user usage limits without learning which user made any given request, so the accounting behind those limits has to be as unlinkable as the request itself. A request returns a Cost feedback that carries no per-request detail, and a device aggregates its receipts and redeems them through a relay, so restoring a user’s quota cannot be tied to the requests that consumed it.

Anonymity also depends on every device receiving the same cryptographic material. A relay encapsulation key or a credential issuer’s public key vended to a single device re-identifies that device’s traffic with no node compromise at all, so PCC publishes the keys it advertises to clients in the same public Release Transparency that carries its software, and a device accepts only keys it can confirm appear there. To prevent an attacker from presenting a divergent view of the log to a targeted user — a split-view attack — clients access the transparency log through third-party MASQUE proxies that conceal the device’s IP address. A researcher can therefore check that one set of keys is in use across the fleet rather than trusting that it is.

Target diffusion

Anonymous routing keeps an attacker from recognizing a target’s request; target diffusion keeps the attacker from reliably receiving it. Target diffusion bounds the share of incoming requests that any single node can decrypt, so a compromised node can access only a small, unpredictable slice of traffic rather than the requests an attacker would choose.

A device encrypts its request Node selection, not to the fleet as a whole. Because the PCC Gateway assembles the candidate set without any identifying information about the user or device, it has no basis on which to bias that set toward a targeted user. The device enforces this bound rather than relying on the infrastructure to honor it: it caps how many candidate attestations it uses regardless of how many the PCC Gateway offers, and a configuration PCC supplies can only lower that cap, never raise it. This bounds the capability of a single compromised node: it can decrypt only the subset of requests that devices encrypted to it. The set of node attestations a device holds ahead of time might itself act as a fingerprint, so a device draws at random from a pool of prefetched attestations, preventing a compromised PCC Gateway from recognizing that set and using it to route the request. On Apple silicon, where a model may span an Ensemble attestation, every member shares the requests routed to that ensemble, so the ensemble rather than the individual node is the unit to which this bound applies.

Non-targetability must hold for the whole request, not only the first hop to the initial proxy node. At every hop, no single component may unilaterally choose the node that handles a leg of a request: on the first hop the device encrypts to a set of candidates the PCC Gateway cannot bias, and on later hops, either an attested proxy node makes the selection, or the component making the selection holds nothing that identifies the user. Choosing a node for a later hop also means a node must provide the routing infrastructure with sufficient information about the request to determine eligible nodes, and that information may derive from the request’s content in addition to its envelope. PCC must therefore use Privacy-preserving routing metadata to help ensure that this information cannot become a fingerprint for the request or for the device that sent it.

One case requires special attention. An External tool calls is a lookup PCC cannot answer inside the trust boundary, such as retrieving world knowledge, and it necessarily exposes its contents to the tool gateway and the downstream provider; an attacker observing one might try to use what it reveals to steer the request’s remaining node selections onto a compromised node. To close that gap, when a request makes such a call, it opts into stronger protection: the PCC Gateway can route to a new node only through Node selection for requests from proxy nodes, where the attested proxy node narrows the candidate set.

Routing transparency

To mitigate the risk of a malicious PCC Gateway attempting to bias routing onto a small set of PCC nodes, PCC makes its routing decisions auditable by the user. The Request execution log streams back to the device the validated attestation of every node that processed a request, so the device records every node that saw it. A user, or a researcher reading their own Appendix: Apple Intelligence Report, sees that record.

Limitations

These measures raise the cost of a targeted attack and make it easier to detect, but three limits remain.

Two kinds of information about the user’s device necessarily remain visible outside the encrypted request:

• The local instance of the third-party relay observes the device’s rough geographical region, which is what enables routing to a nearby data center.

• Requests carry headers with non-identifying information about the device, such as the product and the build version of the operating system, to enable troubleshooting.

A user who is highly distinguishable by those properties might be subject to a semi-targeted attack. The threat model’s analysis of Diffusing compromise discusses this residual visibility.

Anonymous routing constrains which node receives a request. Once a request arrives, some mechanisms inside the trust boundary, such as Responsible AI, make policy decisions based on its content. A mechanism of this kind must select which policies it applies only from the request’s metadata, never from the identity of the device or user, so that no one can aim it at a chosen person. The node records the identifier, version, and hash of each policy asset it has loaded in the Request execution log, so a researcher can confirm that their own requests are served under the same policy assets as everyone else’s.

Finally, even with non-targetability in place, the homogeneity of the PCC fleet remains a concern. PCC nodes run identical software, or software differing only by platform and release, so an attacker who can silently exploit one PCC node might use the same vulnerability against much of the fleet running that release, and spreading requests across the fleet doesn’t change that. We mitigate this threat with statelessness and containment: whatever a node keeps once a request completes stays encrypted under keys that only the user’s device holds, request processing is isolated and recycled, and the mechanisms of Stateless Computation and Containing compromise bound the data a fleet-wide software defect can access.