---
title: Google Cloud Roots of Trust
framework: Private Cloud Compute Security Guide
role: article
role_heading: Article
path: private-cloud-compute/googlecloudrootsoftrust
---

# Google Cloud Roots of Trust

A node roots trust in multiple independent hardware vendors, and an append-only ledger records the hardware that PCC trusts.

## Overview

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: 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: 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.

note: CPAgent CloudAttestation-GoogleCloud: platform certificate handling