Google Cloud Roots of Trust

Overview

Attestation on a node depends on immutable hardware roots of trust and on the integrity of the parts that carry them. No single vendor supplies the whole node, so PCC roots trust in multiple independent vendor roots. Because the node runs in a fleet that Apple doesn’t manufacture, supply-chain integrity rests on each vendor’s certification of the part it builds and on an append-only hardware ledger of the machines that PCC trusts.

Multiple hardware roots of trust

Three independent hardware roots of trust produce the evidence a client checks:

Google Titan

A discrete Titan chip is the host’s root of trust and Trusted Platform Module (TPM). It captures measurements of the host firmware and boot chain, and attests to the host operating system running on the node.

Intel TDX

The CPU’s integrated root of trust attests to the confidential VM that runs the workload. Intel Trust Domain Extensions (TDX) measures the initial memory image of the VM and exposes Guest measurements for later boot stages.

NVIDIA GPU

Each GPU’s integrated root of trust attests to the firmware running on the GPU. The NVIDIA driver inside the confidential VM collects each GPU’s signed measurements at launch, and the VM reflects them into its own attestation.

A hardware root of trust is not unconditionally trusted: an attacker might extract keys or steal the part itself, so a single vendor root is not sufficient on its own to justify trusting a component that could leak user data if it were compromised. For any component an attacker could abuse to exfiltrate user data, PCC therefore roots the software attestation in at least two separate roots of trust from independent vendors, so that compromising one vendor’s root does not by itself defeat the protection.

Two independent vendor roots cover the software that handles user data: Intel TDX measures the confidential VM that runs the workload, and Titan measures the host beneath it. Node validation checks both quotes. The GPU’s firmware rests on NVIDIA’s root alone, because a GPU cannot reach the network or move data off the machine on its own; the Intel-rooted measurement log covers what the host reports about the GPUs.

Google Cloud Node Attestation describes how a running node binds these roots into a single body of attestation evidence, and how a client and the proxy node verify it.

Manufacturing provenance

Titan is provisioned during manufacturing and certified under Common Criteria, so its cryptographic identity is established before it reaches a data center. For Titan’s manufacturing life cycle, site audits, and security certifications, see Google’s Titan hardware security chip documentation. Intel and NVIDIA provide corresponding evaluations and supply-chain controls for the CPU and GPU roots of trust.

Roots of trust outside the attested set

The machine carries more roots of trust than these three. The network interface cards (NICs), the PCIe switches, and the GPU baseboard’s management components each carry their own.

The components these roots cover are deliberately outside the node’s Hermetic environment: their firmware is not measured, the Appendix: Google Cloud Attestation Bundle Contents carries no evidence from them, and nothing a client establishes about a node depends on them. The node’s configuration is designed to help ensure they cannot access or manipulate user data; the host keeps the ConnectX-7 interface cards, which would otherwise provide GPUDirect remote direct memory access, out of the Workload VM, whose kernel denies their driver module so it cannot load. Neither the host nor the Workload VM loads the NVIDIA peer-memory module that GPUDirect requires.

These peripherals are nevertheless verified, by Google rather than by Apple, before a machine serves a workload and for as long as it is in service. That verification runs out-of-band through the machine’s baseboard management controller, so its results are not exposed in attestation evidence, and the evidence a client checks covers the parts that handle user data instead.

Hardware ledger

Independent hardware roots establish what a node’s parts can attest to, and vendor certification establishes how those parts were built. Neither establishes to a client that a given set of parts is a legitimate member of the PCC fleet rather than attacker-controlled hardware inserted into the supply chain. To close that gap, PCC maintains a cryptographically verifiable, append-only ledger of all Google Cloud hardware that is part of the PCC fleet. Its entries are recorded in the Release Transparency, and a node’s attestation is trusted only if its hardware is a known, logged member of the fleet.

Device identity

A node’s ledger entry is built around its device identity, expressed as a Device Identity Manifest (DIM). The manifest binds together the identities of the parts that make up one node: its Titan TPM, its Intel CPU (identified by its Binding the evidence together), and its NVIDIA GPUs.

The manifest exists because these identities are emitted from separate roots of trust on separate parts, and a client needs assurance that a particular set of parts belongs together on the same machine in a data center. The PIID links the CPU to the platform, and the manifest binds those component identities into a single certified record when a node comes into service.

Assembling and certifying a device identity

The manifest is assembled from certificates already present in the node’s attestation bundle:

Google

A digest of the Titan DeviceID certificate from the host attestation’s DICE chain.

Intel

The platform instance ID carried in the PCK certificate that accompanies the Intel TDX quote.

NVIDIA

The Security Protocol and Data Model (SPDM) subject-alternative-name identity of each GPU attestation leaf certificate, one entry per GPU.

An issuing service outside the node certifies the manifest: it issues a certificate carrying the manifest in an X.509 extension and adds that certificate to the transparency log. CPAgent retrieves the issued certificate and writes it where the node’s attestation path reads it, refreshing it on a fixed interval so a node presents a current one. A node therefore cannot certify its own hardware, and because the log is append-only, hardware admitted to the fleet leaves a permanent record.

[Image]