Verifiable Transparency

Overview

[Image]

In traditional cloud services, nobody outside a data center can see what software actually runs inside it. We designed a PCC node’s Hermetic environment so a node runs only known, measured, and attested software, but that environment doesn’t by itself let anyone outside the operator verify the operator’s privacy claims.

Verifiable transparency makes those claims independently auditable. Apple must record a node’s attested measurements in an append-only, tamper-proof transparency log, and must publish the corresponding software for inspection. The user’s device must verify that those measurements appear in the log before entrusting the node with user data.

Verifiable transparency belongs to PCC’s Verified service and cloud layer, and it closes the operator attack of software modification: the operator runs software whose data retention or use differs from its public claims.

PCC takes the extraordinary step of making its production software publicly verifiable. Our commitment to verifiable transparency includes:

• Publishing the measurements of the code running on PCC in an Release Transparency.

• Making the log and the binary software images measured by each release publicly available for inspection and validation by privacy and security experts, and keeping them retrievable, so an attestation recorded today is checkable against published software later.

• Publishing Source Code for a subset of PCC’s security-critical components, so researchers can analyze the mechanisms that enforce our guarantees rather than only their compiled form.

• Publishing and maintaining an official set of tools for researchers analyzing PCC node software.

• Rewarding research findings through the Apple Security Bounty program.

This transparency, combined with PCC’s Enforceable Guarantees, lets anyone verify that the system abides by its Stateless Computation promises.

End-to-end attestation

PCC’s verifiable transparency is rooted in the user’s own device: a node attests to the measurements its boot chain produced, and the user’s device verifies an inclusion proof that those measurements appear in the Release Transparency, a public ledger of the releases PCC deploys. Apple publishes every release to the log, so the user’s device trusts only software that Apple approved, no matter where the node runs or who operates its infrastructure. The user’s device encrypts a request to a node only after completing this Node validation, enabling the PCC node to act as an extension of the user’s device.

A node’s Hermetic environment covers the entire node: its measurements reach below the application layer to the firmware and boot chain, the operating system, and the security- and privacy-relevant configuration fixed at boot. Because the attestation also carries values unique to that node, the user’s device sets those values aside and checks only the measurements the log records. Each platform anchors the attestation, separates its measurements from node-specific values, and covers its boot configuration in its own way:

Apple silicon nodes

The Secure Enclave anchors the attestation by signing it with a hardware-rooted identity key, and its Apple Silicon Root of Trust cannot change after manufacturing. The user’s device canonicalizes the node’s Secure Boot, redacting only Appendix: Apple Silicon Secure Boot Ticket Canonicalization, such as device identifiers and anti-replay values. The node measures a subset of its Appendix: Apple Silicon System Configuration into the Configuration Seal Register, and the user’s device validates the configuration against that register.

Google Cloud nodes

Google Cloud Roots of Trust anchor the attestation, and their separate evidence is bound together into Google Cloud Node Attestation. The user’s device replays the boot event logs and projects the measurements they record into the release structure, leaving the node-specific evidence that authenticates those logs outside the release. The release also includes the node’s Measured, unmeasured, and dynamic configuration.

The transparency log is a cryptographically tamper-evident, append-only data structure: the same construction that Certificate Transparency uses to make mis-issued web certificates detectable, and that Apple’s iMessage Contact Key Verification applies to public keys. A recorded release stays in the record, and any attempt to remove or alter an entry is detectable. The log also presents a single history to everyone: because a client tracks the log’s periodic milestones, validates consistency proofs linking each milestone back through the log’s history, and reaches the log through independent third-party proxies whose domains are fixed in the client, it can confirm it sees the same append-only history as every other client rather than a divergent view served to it alone. These properties mean the user’s device verifies against the same measurements that security and privacy researchers inspect.

Inclusion in the log is permanent in history but bounded in time. A log entry carries an expiry that the user’s device validates, so a release stays deployable only while Apple continues to publish it, and withdrawing a release means letting its entry lapse rather than altering the log. The user’s device enforces this against the log rather than accepting a node’s own account of how long its keys remain valid.

The user’s device performs this validation for the first PCC node involved in handling a request, which we call the proxy node. When a request needs more nodes, the proxy node extends trust to them through Transitive Trust: before sending the request to another PCC node, the proxy node validates that node on behalf of the user’s device, applying the same checks against the log revision the user’s device verified. Only proxy nodes can send requests to other PCC nodes, so every hop beyond the first passes the same validation, and transitive trust extends only to software the user’s device authorized.

Binary transparency

Releases PCC deploys are published for independent binary inspection, so a researcher can examine the software the log names, rather than only identify it. Responsibility for building and publishing a release’s binaries differs by platform:

Apple silicon nodes

Apple builds every binary measured by a release, and publishes the Binary transparency when the release enters the log. Apple holds publication for up to 90 days only in specific cases, such as an embargoed security fix or an unannounced feature.

Google Cloud nodes

Apple builds the workload container and publishes it on the same terms as Apple silicon software. Google builds and publishes the Binary transparency, which include components supplied by Intel, NVIDIA, and other third parties.

Researchers retrieve the artifacts Google publishes the same way as Apple’s, using the Downloading available releases, which locates each artifact from the metadata that accompanies its release in the transparency log. Google publishes the components that Intel, NVIDIA, and other third parties supply, subject to its agreements with those vendors, and access to them is subject to the vendors’ license terms. Google publishes an artifact only once any security or other embargo on it lifts. When an artifact remains unpublished beyond the 90-day hold that applies to Apple’s binaries, Apple provides notice in a release note where possible, including when legal requirements are the reason.

Some data assets in a PCC release are measured but unpublished. Because an unpublished asset is not open to independent inspection, PCC’s threat model treats its contents as attacker-controlled. An asset may therefore remain unpublished only when attacker-controlled contents cannot affect the security or privacy of the system, either by changing how a node behaves or by exploiting a defect in the parser that reads them. The foundation models a node loads are proprietary and stay unpublished, as are their adapters on Apple silicon, and our model file formats address both concerns: they represent weights alone, cannot encode arbitrary control flow, and are restricted enough that we treat parsing a hostile file as safe.

Enabling research

Researchers must be able to perform verification independently, rather than relying on assertions from Apple. Anyone can enumerate the transparency log, Downloading available releases it names, and use tooling Apple publishes to recompute the binaries’ measurements and confirm they match the release recorded in the log. The same workflow applies on both platforms. Apple’s build pipeline produces artifacts anyone can re-measure, and a Google Cloud node also attests Third-party firmware whose measurements a researcher cannot derive from the published update files alone.

Exercising the software rather than only reading it depends on the hardware a node runs on:

Apple silicon nodes

The Virtual Research Environment boots a release, minimally modified for virtualization, in a virtual machine on a Mac with Apple silicon. That brings inspectability to anyone, with no need to apply for access to physical hardware.

Google Cloud nodes

A node’s trusted computing base includes confidential-computing hardware that a Mac cannot emulate, so research runs against real cloud instances in the Google Cloud Research Environment, with Reproducing Google Cloud Measurements.

Apple also publishes Source Code for a subset of PCC’s security-critical components and, through the Apple Security Bounty, rewards findings that show PCC falling short of these guarantees.

Callout transparency

Verifying the software a node runs doesn’t, by itself, account for what that node sends outward. A node running exactly the published software, unable to identify whose request it is serving, can still carry query-derived data outside the trust boundary in an External tool calls. Deliberately routing data outward through such a call is the operator attack of callout manipulation. PCC makes such a call only where a lookup cannot be answered cryptographically, as described in Tool calls. This requirement covers what happens when one is unavoidable.

The requirement attaches to a call that carries query-derived cleartext outward, because that is the case where the party answering it learns what the user asked. A lookup whose contents stay hidden from that party, such as a Private Information Retrieval query, is bounded instead by that cryptographic property, and the record returned to the device identifies the data set the lookup consulted.

Three properties make that egress path enforceable rather than merely policed:

• It is the only such path. A single process on the node is authorized to open outbound connections for external tool calls, and other components reach that process over an Containing compromise rather than the network, so every such call passes the point where it is recorded.

• Every call is individually enumerable. The node records each call as its own entry in the Request execution log that it streams back to the device.

• The record reaches the user. The device collects those entries into the outboundCalls list of the request’s record in the Appendix: Apple Intelligence Report.

The record must reach the user’s side of the boundary. An operator-internal audit log of outbound calls leaves the operator as the only party able to check it, which is the arrangement this requirement exists to prevent. Because the record reaches the device, a user or a researcher reading their own report can see the destinations and query terms of the calls made for a request. We designed these calls to preserve the same privacy as on-device tool access, and PCC preserves a request’s Non-Targetability across them.