Transitive Trust

Overview

Completing some requests efficiently requires more than one PCC node. For example, a PCC cloud applications such as PCC Agent fans a request out to worker nodes for tool invocations, and Distributed inference spreads a request across several nodes. PCC can use a transitive trust flow that allows a user’s device to delegate trust decisions to PCC nodes with attestations it has already validated, so PCC can process these requests without additional round trips to the user’s device. The PCC node that distributes such a request is a proxy node, and the PCC cloud applications it runs, such as PCC Agent, determines how the proxy node processes the request. Before distributing the request, the PCC proxy node is responsible for validating attestations for any PCC nodes it has identified to handle the request, applying the same Node validation the user’s device would apply itself. Transitive trust helps ensure Verifiable Transparency and enables PCC to establish encrypted communications between a user’s device and the PCC nodes acting on the user’s request. The same flow applies whether a proxy node forwards a request to an Apple silicon node or a Google Cloud node.

Proxy node policy enforcement

PCC nodes that are expected to issue outbound requests to other PCC nodes use a dedicated darwin-init, which the Apple silicon node software implements. The CloudBoard family of daemons enforces that only PCC nodes with this security policy can issue outbound requests to other PCC nodes. When one of these PCC proxy nodes issues an outbound request, it validates the receiving node’s attestation on behalf of the user’s device — verifying the same attestation properties as the user’s device. The customerProxy policy also helps ensure that clients without support for verifying proxy node attestations to establish transitive trust reject these PCC nodes.

Trusted log revisions

When a user’s device validates the attestation of a PCC node, it also verifies the inclusion of the node’s release in the PCC Release Transparency. Because this validation process occurs directly on the user’s device, it can also help ensure key properties of the transparency log, such as non-targetability. To maintain these properties, PCC proxy nodes don’t perform their own end-to-end verification of worker node releases against the transparency log. Instead, they verify proxied worker node releases transitively, anchored to the same view of the log that the user’s device validated when accepting the proxy node attestation.

A proxy node attestation contains an inclusion proof for the release the proxy itself runs, anchored to a specific log revision, called the trusted log revision. When the user’s device validates the proxy node attestation, it verifies this inclusion proof and, by doing so, implicitly commits to that revision as the trusted view of the log for any downstream worker node. The proxy node periodically requests an inclusion proof from the Apple Transparency Service that is anchored to a log revision that contains all currently unexpired release entries. As new releases are added to the log, the proxy refreshes its inclusion proof and generates a new Application protocol and attestation bundle, which the Node selection distributes to users’ devices. Previous attestations remain valid until they expire, and the proxy honors the log revision associated with the REK used by the user’s device when wrapping a request.

When a proxy node validates a worker node attestation provided by the PCC Gateway, it doesn’t validate the worker node’s inclusion proof against its own current view of the log. Instead, it validates inclusion against the trusted log revision to which the proxy itself committed. Three cases are possible, distinguished by comparing the proxy and worker node log revisions:

Equal revisions

The proxy validates the inclusion proof in the worker node attestation directly.

Proxy revision ahead of worker node revision

The proxy requests a consistency proof from the Apple Transparency Service between the two revisions. Together with the worker node’s inclusion proof at its original revision, a valid consistency proof establishes that the leaf is also present at the proxy’s revision.

Worker node revision ahead of proxy revision

The worker node release was added to the log after the proxy committed to its revision. The proxy requests a fresh inclusion proof for the worker’s release at the proxy’s own revision and requires the tree head to match the one the proxy committed to. A release not present in the log at that revision has no such proof, so the proxy rejects the worker node until it refreshes its own inclusion proof to a revision that contains the new release.

A Google Cloud node’s attestation carries three inclusion proofs rather than one: one proof for the node’s Device identity certificate, and one each for its software release and its firmware release. All three are leaves of the same Log integrity verification, so the reconciliation above applies to each of them independently, against the trusted log revision the proxy committed to. The two release proofs are requested together and share a revision; the certificate proof carries its own.

[Image]

The user’s device only ever validates the proxy’s transparency proofs; all other inclusion verification happens between the proxy node and the Apple Transparency Service, but always against the trusted log revision the user’s device implicitly trusted when it accepted the proxy attestation. This helps ensure that proxy nodes forward requests only to PCC nodes running a software release present in the transparency log at the same revision the user’s device verified, while keeping proxy attestations small as the set of unexpired releases grows.

We introduced trusted log revisions in 6A releases. Earlier PCC releases use Trusted release sets. To preserve compatibility with client software that expects attestations with trusted release sets, 6A releases populate the trusted release set field in proxy attestations with one entry: the proxy’s own release. A client that supports trusted log revisions takes the worker’s trust decision from the revision rather than from that entry.

Trusted release sets

In this mechanism, proxy node attestation bundles contain authenticated metadata called the trusted release set that contains digests of all the PCC software releases for which the proxy node forwards requests. Together with this release set, the proxy node attestations contain inclusion proofs both for the release the proxy itself runs and for every release in the trusted set. Because all inclusion proofs are validated when the user’s device validates the proxy node attestation, the user’s device controls the set of releases that are trusted to process its requests.

The set of trusted releases is implicitly communicated to the proxy node from the user’s device when it wraps the Application protocol (DEK) using the corresponding attested proxy node’s Application protocol (REK). When a proxy node asks the PCC Gateway for another PCC node, it provides the set of trusted releases to the PCC Gateway. After selecting a node, the PCC Gateway provides the node’s attestation to the proxy node, which validates it using the CloudAttestation framework. Instead of validating the node’s transparency inclusion proof against the transparency log, the proxy node enforces that the node runs one of the trusted releases by recomputing the release digest from the measurements in the attestation and matching it against the trusted set.

Proxy nodes periodically poll the transparency log to determine the current set of non-expired releases. When the set changes, proxy nodes generate a new REK and attestation bundle, which includes the updated trusted release set, and provide the attestation to the PCC Gateway for distribution to users’ devices. Previous attestations remain valid until expired, and proxy nodes respect the release set associated with the REK used by the user’s device when encrypting a request.

Request execution log

To provide transparency into the PCC nodes involved in the processing of a user’s request, the attestations validated by the proxy node are added to a request execution log (REL). REL entries are streamed back to the user’s device end-to-end encrypted and authenticated, and included in the Appendix: Apple Intelligence Report. When processing of a request is complete, the proxy node finalizes the REL with a corresponding message. A finalized REL indicates that a proxy node will not make any further requests to other PCC nodes as part of processing the user’s request.

As discussed in Node selection, users’ devices may attest to multiple PCC proxy nodes, so the PCC Gateway can balance the load by choosing which of them handles the request. Any proxy node for which the user’s device wraps the DEK, but that does not process the request, responds to the device with a negative acknowledgment (NACK) in the form of an empty finalized REL. This helps ensure that the REL information received by the user’s device describes the full set of PCC nodes involved in processing a request, even with a compromised PCC Gateway.

Sometimes a node can’t send a NACK, for example when the proxy node isn’t reachable due to an outage or because it has rebooted. For this reason, even empty finalized RELs are included in the Apple Intelligence Report, allowing security researchers to monitor the frequency of missing NACKs.

The REL also records any External tool calls made by a request. When a cloud application calls a tool, the proxy node emits a REL entry of its own capturing the call, including the tool invoked and the arguments sent to the tool. Like attestation entries, these entries are streamed to the user’s device end-to-end encrypted and authenticated, and the device collects them into the outboundCalls list of the request’s Apple Intelligence Report record, so the user and security researchers can see exactly what data left the trust boundary for each external tool call.

Request and response bypass

Depending on the use case, proxy nodes might not need to access the application payload of a request to fulfill their purpose. For example, they could decide the types and quantities of ensembles that are required to process a request based exclusively on request metadata, such as the model and adapter routing parameters or workflow identifier. For this reason, PCC supports a request-bypass mode, in which the proxy receives only the wrapped DEK and request metadata and not the request payload. The payload is buffered at the PCC Gateway until the proxy node requests an inference node from the PCC Gateway to handle the request payload. After the proxy node validates the inference node’s attestation and re-wraps the DEK, the PCC Gateway forwards both the re-wrapped DEK and the buffered request payload to the inference node.

Similarly, if the proxy node doesn’t need to transform the response payload or make further requests, the PCC Gateway can bypass the proxy node and directly stream the response back to the user’s device. The proxy node decides when it can be bypassed and informs the PCC Gateway accordingly. Because the user’s device doesn’t know about the inference node upfront, it can’t establish a secure communication channel with the node itself. Instead, the proxy node performs the HPKE protocol with the inference node and shares the computed HPKE-derived AEAD key and AEAD anti-replay value that are used to encrypt the response stream to the user’s device by appending both to the inference node’s REL entry. Upon receiving the REL entry, the user’s device then establishes a receive-only AEAD context to decrypt the response stream.

Workload-type validation for multi-app routing

As PCC supports multiple PCC cloud applications on shared infrastructure, the transitive trust flow includes workload-type validation to help ensure each request reaches only nodes authorized for the intended application. Each cloud application is identified by a serviceName: the routing identifier the PCC Gateway uses to direct requests to the correct application. When the client requests a proxy rather than a specific worker, for example, for PCC Agent tool invocations, the proxy node tells the PCC Gateway which type of worker node the request needs, and the PCC Gateway selects a worker of that type. Without workload-type validation, a compromised PCC Gateway or routing misconfiguration could direct a request to a worker node running a different application.

To prevent cross-application request routing, PCC enforces two layers of validation on an Apple silicon worker:

Proxy validates worker’s appIdentifiers

Worker attestation bundles include an Appendix: Apple Silicon System Configuration field, a set of application identifiers that the worker is authorized to run. When the proxy selects a worker and validates its attestation, it verifies that the serviceName it requested maps to an identifier present in the worker’s attested appIdentifiers. Because this field is part of the attestation bundle, it’s covered by the same attestation validation performed on behalf of the user’s device.

Worker validates workload type

The proxy sends the serviceName as the workloadType to the worker, which independently validates that it matches its own capabilities. If the workload type doesn’t match, the worker rejects the request.

This two-layer validation helps ensure that no single compromised component can unilaterally re-route a request to an unauthorized application.

Transitive attestation for distributed inference

Transitive attestation is handled differently for PCC inference nodes that participate in Distributed inference. On Apple silicon, those nodes are combined to form ensembles. Each ensemble forms a statically configured unit, with all nodes running the exact same software release. PCC proxy nodes attest to and communicate only with the leader nodes of inference ensembles. The leader node attests to the trustworthiness of follower nodes within the ensemble internally, as described in detail in Ensemble attestation.