Enforceable Guarantees

Overview

Security and privacy guarantees are strongest when they are entirely technically enforceable, which means every component inside the trust boundary must be one we can constrain and analyze. Most privacy commitments are promises a company makes about its own conduct; PCC’s privacy properties come from mechanisms instead.

The High-security inference of a cloud AI service includes every component with access to user data, or with the ability to influence how the system protects that data. For PCC, that boundary is the PCC node responsible for processing a request, designed from top to bottom so everything inside it can be constrained and analyzed:

Hermetic environment

The node runs a minimized operating system that enforces a hermetic or sealed environment: the boot chain is designed to measure each executable before it runs and to include those measurements in the node’s attestation.

Analyzable runtime behavior

The node’s software uses small components that each enforce a narrow responsibility on behalf of the whole system.

Data secured end to end

Data is encrypted whenever it leaves a node, and is readable only by the user’s device and the attested nodes that handle the request.

Secured boundary edges

The software accounts for both how an attacker might get in and how user data might leak out.

Hermetic environment

We designed a PCC node to be hermetic: every component trusted with user data must be measured and attested. This is full-stack attestation: it reaches from firmware to application code, rather than only the software that handles a request. That measured stack is the node’s trusted computing base, the components inside the trust boundary on which PCC’s guarantees depend. Everything that can execute on the machine falls inside it, so a device verifying the attestation accounts for what runs alongside its request as well as what serves it.

Only code Apple authorizes and measures may execute on a node, and that authorized set must be fixed before the node accepts user data rather than extensible while it runs. Each platform has its own machinery to implement this:

Apple silicon nodes

A node runs on Hardware design, with Apple Silicon Software Foundations beneath Private Cloud Extensions we built for PCC’s workloads. Restricted Execution Mode narrows the authorized set further once user data is present.

Google Cloud nodes

A node runs on Google Cloud Node Architecture whose hardware roots of trust come from independent vendors, and it occupies a whole physical machine on which no other tenant’s workload runs. The measured stack reaches from the host firmware through Google Cloud Node Hardening to the Workload Megacontainer carrying Apple’s runtime. The build also measures the Python code that the runtime loads, and a Script-execution policy holds a recognized interpreter to that measurement at runtime. The authorized set is fixed when those images are built, and changing it means redeploying the node.

Measurement extends past executables to the assets and configuration that determine how a node behaves, so that anything able to affect the security or privacy of the system is part of a node’s measured state. Foundation models and adapters are among those assets: a node’s attestation identifies the exact model the node holds, and the Release Transparency records that model as part of the release. These assets are proprietary and not published, so PCC constrains what their format can express; see Binary transparency.

A node also accepts data that changes while it runs, such as the Runtime Configuration and Assets the PCC control plane delivers, which an attestation fixed at boot cannot cover. Because the measured state must cover everything able to affect the security or privacy of the system, PCC requires that anything a node accepts after that point be incapable of changing those properties. Each component that consumes such data treats it as untrusted input.

An attestation is only meaningful if the key to which the user’s device encrypts its request can’t outlive the state that the attestation describes. An attested key must therefore be non-exportable by construction, so no compromise of the software above it can lift the key out of the node. Each platform holds that key beyond the reach of the software that parses a request:

Apple silicon nodes

The Secure Enclave provides an enforceable guarantee that an attacker cannot duplicate or extract the key that decrypts a request: the Secure Enclave holds that key, and it binds the key to the node’s Software Sealed Registers, so the key becomes inaccessible if the measured state changes.

Google Cloud nodes

The key lives in a Protecting request keys that runs in a confidential VM of its own, separate from the one running the workload. The Key Protection Service decapsulates each request’s key-encapsulation ciphertext inside its own VM, so the component that parses the request’s untrusted input never holds the private key that decrypts it. The Key Protection Service returns only the resulting shared secret, sealed to a binding key that a verifier has tied to the workload’s attested measurements. Both key pairs live only in the memory of the confidential VMs that generated them, so they do not survive a change in the node’s measured state, and a verifier endorses a replacement only after a fresh exchange of attestations establishes the measurements of both VMs.

A node that leaves its attested state loses the ability to decrypt, and the user’s device declines a node that cannot demonstrate that state.

Analyzable runtime behavior

Enforceability requires more than knowing which software is present; a researcher must also be able to follow a request through a node in normal operation and account for what happens to it. PCC is built for that analysis. Atop its minimized operating system, it decomposes its software into small components, each with a narrow responsibility and only the privileges that responsibility requires, making each component specific enough to reason about.

Because each component has a narrow responsibility, a researcher can analyze its behavior on its own and follow the path a request takes across these components, end to end:

CloudBoard

Terminates the cryptographic channel with the user’s device, so a request enters a node at a single point rather than at many.

Per-request processes

Parse untrusted input in a process scoped to one request, so a compromise while parsing reaches no other user’s data.

The inference engine

Processes each request independently, so one request can neither read another’s state nor affect how another is processed. The Inference Engine and The inference pipeline each run their own.

Operating the service without privileged access

Admit only output permitted by a published allow list, so nothing leaves a node that Apple has not approved in advance.

Concentrating enforcement in a few components like these keeps a guarantee’s implementation in places a researcher can find and examine.

Data secured end to end

The user’s request is exposed only inside an attested node. Whenever it crosses the boundary, it travels encrypted end to end to an endpoint the sender has authenticated, so the infrastructure carrying it cannot read it.

The first crossing is the request itself. The user’s device encrypts it to a node’s public keys only after Node validation, so the third-party relay, the PCC Gateway, and the other data-center services that it passes through carry ciphertext and hold none of the keys to decrypt it. Those components sit outside the trust boundary without being trusted with user data.

A request often needs more than one node, and data moves between nodes under the same rule: only after the receiving node is authenticated. Where a request is routed across nodes at request time, Transitive Trust has a proxy node validate each node’s attestation against the transparency-log revision the user’s device verified when it accepted the proxy’s own attestation. That validation must establish not only that a node runs authorized software, but also that it is authorized for the application the request targets, so no single component can redirect a request to a different application. A node that cannot present a valid attestation receives no user data, so the boundary extends across nodes only as far as attestation reaches.

Some workloads are too large for a single node and run across a group of nodes that hold a model collectively. On Apple silicon, such a group is an Ensemble attestation; a Google Cloud node holds its model on a single machine, so no such group forms there. Where one does, the group rather than the node is the unit that must be constrained, and three requirements apply to it:

Fixed membership

The group’s membership must be fixed before any user data arrives and must not be extensible while it runs, so no node can join the set of nodes able to read a request in flight.

Mutual verification

Each member must verify that its peers run the same measured software before any of them shares user data, and that software must be a release the user’s device has authorized, so joining the group grants no trust the device did not already extend.

Fail closed

If a member cannot be authenticated, or data fails to authenticate on arrival, the group must go out of service rather than continue running in a degraded state.

An ensemble meets all three requirements: its topology is fixed at boot and cannot change for the life of the boot session, each node verifies that its peers run the same PCC release before any of them shares user data, and the loss of any member takes the whole ensemble out of service. Because every member shares the requests routed to that ensemble, Target diffusion applies to the ensemble rather than to the individual node.

Secured boundary edges

Protecting the intended crossings still leaves the edges themselves open to abuse, so PCC constrains those too. An inbound attack exploits the code that handles untrusted input. Outbound leaks take two forms: the microarchitectural channels a co-resident workload might read, and the operational data a node emits so that we can operate the fleet.

Resisting exploitation

A trust boundary that is measured and analyzable is still only as strong as the code inside it. An adversary who cannot subvert the boundary from outside may instead exploit a defect in a component within it, such as a memory-safety bug in the code that parses a request, and attempt to bypass the system’s protections. Because software enforces those protections, we design against exploitation rather than assuming the code is free of defects.

On Apple silicon, the On-Node Request Termination and The Inference Engine layers are written in Swift, which provides memory safety, and use separate address spaces to isolate initial processing of requests. Technologies such as Pointer Authentication Codes and sandboxing resist such exploitation and limit an attacker’s lateral movement within a node. On a Google Cloud node, Host and guest OS hardening reduces the code an exploit can reach, and containerization isolates components from one another to provide sandboxing. The host and guest operating systems enforce write-xor-execute on their integrity-protected file systems, and inside a component container an Execution enforcement bounds which programs run.

The user’s request is not the only untrusted input a node accepts; every input must be either strictly validated or covered by the node’s attestation. A node parses the responses to the Appendix: Tool Gateway Protocol it makes, third-party media such as the HomeKit Secure Video Analysis a workflow analyzes, and the management and configuration inputs Apple supplies to operate the fleet. PCC isolates the parsing of these inputs based on format complexity and parser memory safety. A media codec is the clearest case: PCC runs that parsing Media Decoding, in a compartment scoped to a single request, so a successful exploit yields no other user’s data and does not outlive the request that carried it.

Resisting side-channel extraction

Side-channel resistance is a Frontier security and privacy requirement that follows from where the hermetic boundary is drawn. Code that runs on the same machine as an otherwise hermetic workload shares caches, memory controllers, page tables, performance counters, and the clock, and an adversary can recover data from how the workload uses them. Microarchitectural side-channel research has repeatedly turned such shared resources into practical extraction paths against isolated workloads, including against the enclaves that confidential computing provides: Foreshadow read enclave memory out of the L1 data cache through a transient-execution attack, recovering Intel SGX’s attestation key and letting an attacker forge attestations for enclaves that never ran. Such an adversary needs no vulnerability in the workload at all; co-residency is the capability.

PCC’s primary defense is full-stack attestation: the measured set contains every layer that can execute on the machine, so no unmeasured code runs alongside a workload and no privileged layer is left over to serve as a vantage point. Denying an adversary a co-resident launch point puts most microarchitectural channels out of reach rather than mitigating them one at a time.

Removing the launch point addresses channels that need code on the machine, not the ones an adversary can observe from outside it: in the node’s network traffic, in a service the node contacts, or in the operational data it emits. PCC implements specific mitigations for these channels. Side-channel extraction analyzes the network channels, including traffic analysis and the token-length mitigation. That section also covers the design-time side-channel testing every Apple silicon design undergoes, and Rejecting replayed requests, which helps prevent an attacker from replaying one request to accumulate observations. The Operating the service without privileged access bound what a node emits, to help ensure that an attacker cannot repurpose an observability path as a measurement instrument.

Target diffusion also bears on side-channel exposure. Because a device encrypts its request to several candidate nodes, an attacker controlling the routing infrastructure might try to have more than one of them process it, multiplying the observations a side channel yields from a single request. The system must therefore process a request at most once across the fleet. The routing infrastructure sits outside the trust boundary, so it cannot confirm this; because the device selected the candidate set, it is positioned to detect whether more than one candidate processed its request. A candidate that is not selected therefore Request execution log.