Hardware Provisioning

Overview

PCC’s promise of verifiable transparency rests on hardware: the attestation a device verifies reduces to signatures checked against the roots of trust built into the node. Those roots anchor the whole chain of guarantees, and an attestation is only as trustworthy as the hardware that signs it.

An attacker can instead introduce a node into the fleet whose roots of trust the attacker controls. Such a node signs attestation evidence for a software state it is not in. This attacker doesn’t need to defeat any other requirement: measurement, transparency, and the absence of privileged access all remain intact, yet the verification of the node’s environment rests on false evidence.

This is an attack of exceptional cost and sophistication. PCC defends against it by requiring more than one independent party to vouch for a node, and an auditable record of every node admitted to the fleet:

Multi-party control

The provisioning of any component an attacker might use to exfiltrate user data must either derive from two different roots of trust held by two different suppliers or take place in the presence of an independent auditor.

Auditable provisioning

The hardware and cryptographic identities of every node admitted into the production fleet must be recorded in an append-only, cryptographically verifiable ledger, to enable anomaly detection and forensic analysis.

These protections raise the cost of admitting a subverted node and increase the likelihood of detection. Together with PCC’s Non-Targetability, they help ensure that an attacker must mount a successful attack at scale.

Multi-party control

Admitting a node to the fleet and forging the evidence a node presents must each require the cooperation of more than one team and more than one point of provisioning. The design ensures that the failure of a single process cannot admit a node, and that any attempt to admit a subverted node requires a broad, multi-party breach. When different components of a PCC node have their own independent root of trust, this property is required only where an attacker might use a component to independently exfiltrate user data from a node.

This admission checks a node against evidence recorded earlier, and that evidence carries the same requirement: parties independent of the organization that later deploys the node must create that evidence as the hardware is built, and must protect it from alteration until admission.

On Apple silicon, PCC meets this requirement with an independent auditor. Before a node joins the fleet, the Certificate ceremony process requires a quorum drawn from several Apple organizations to clear a sequence of gates, each cross-checking an independent record, such as a challenge-response attestation of each chassis component that carries a cryptographic identity. Those records come from Hardware life cycle, which tracks each SoC by its cryptographic identity from production to the finished chassis. Apple issues a certificate for Cryptographic identity only after a chassis passes all of them. A third-party auditor witnesses the ceremony, and Apple publishes that auditor’s SOC 3 reports. Because no single organization controls every gate and an independent auditor witnesses certificate issuance, admitting a subverted node requires a simultaneous breach across those organizations and their independent record systems.

On Google Cloud, PCC meets the requirement with independent roots of trust, because no single vendor supplies the whole node: Multiple hardware roots of trust from Google, Intel, and NVIDIA each attest to a different part of the machine, and each vendor Manufacturing provenance. For any component an attacker might use to exfiltrate user data, the software attestation is rooted in at least two of those vendors’ hardware roots, so compromising a single vendor’s root doesn’t by itself defeat the protection.

Auditable provisioning

An append-only ledger of the hardware and cryptographic identities of every admitted node opens the provisioning process to audit after the fact, so trust does not rest on the integrity of a point-in-time ceremony. PCC records the identity certificate issued for each node in the same public, append-only Release Transparency that carries its software releases, and that certificate binds the evidence of authenticity gathered during provisioning. A node then uses an inclusion proof to show its certificate is present in the log, just as it proves its software release is logged. Each platform records different evidence in that certificate:

Apple silicon nodes

The Certificate ceremony process issues the certificate for Cryptographic identity, and it carries the cross-checked evidence the ceremony’s gates produced.

Google Cloud nodes

The certificate carries a Device identity binding together the identities that a node’s separate roots of trust emit, so a client can confirm that a particular set of parts belongs together in one physical machine. Logging each such certificate builds Hardware ledger, an append-only record that makes the set of machines PCC trusts auditable.

Because the log is public and tamper-evident, an independent auditor can review the certificates, the evidence measured into them, and the log itself to reconcile the fleet against that record. A certificate issued outside a sanctioned process, or a node whose identity never entered the log, appears as a mismatch.