--- title: Google Cloud Software Transparency framework: Private Cloud Compute Security Guide role: article role_heading: Article path: private-cloud-compute/googlecloudsoftwaretransparency --- # Google Cloud Software Transparency A node measures and publishes the platform firmware, operating systems, and container image it runs. ## Overview Overview Verifiable Transparency is a core requirement of Private Cloud Compute: every production build that runs on PCC infrastructure is published to an append-only Release Transparency, and security researchers can inspect and analyze those builds. A node measures every layer of its launch: platform firmware, the host operating system, the guest operating system, and the workload container image. User data reaches a node only after Node validation confirms that the node’s attested runtime measurements match an entry published in the transparency log. Software layers The software on a node falls into three layers, each with different owners and update cadences: Restarting the whole host to pick up a new workload or operating-system version resets machine state between deployments, helping ensure that the node boots from known reference measurements. note: Some hardware-management software that may be updated alongside these layers — for example, smart-NIC and PCIe-retimer firmware — is excluded from the TCB and treated as untrusted rather than measured, so its updates aren’t reflected in attestation, reference measurements, or the transparency log. The host’s IOMMU limits each device’s direct memory access to the buffers the host maps for it. Composing and publishing a release The three software layers map to two independently published release types in the transparency log, because different parties control their deployment: Recording the layers as two separate release types reflects deployment boundaries while keeping release verification independent. Google builds and releases the hardware TCB, but Apple approves a firmware update by publishing its reference measurements to the transparency log. Because node validation verifies a node’s measurements against the log before traffic routes to it, an unapproved firmware update prevents the node from accepting requests. Apple also coordinates the maintenance windows when updates are applied. For the software release, Apple builds the workload, selects the operating-system image, and deploys both together. Within each release, components are bundled so that a single measurement covers several of them: the hardware TCB updates as one bundle with one endorsement, and the software release pairs the operating-system boot-disk measurements with the workload container image digest. Because the container image also encapsulates startup asset digests, an update to runtime code or assets produces a new container image measurement and a corresponding log entry. Across releases, a verifier checks a firmware entry and a software entry independently rather than every pairing of the two. Because the hardware TCB updates infrequently and isn’t pinned to a particular software release, a node can run a newly deployed software release against the current hardware TCB without requiring new firmware measurements. Each release is recorded in the log as a structured record of its measurements, and the log entry is a digest over that record. The verifying client parses the measurement records in the node’s attestation and confirms that the record digest matches a published entry in the log, so that a component is trusted only when it is both present in the attestation and recorded in the log. Researchers can Reproducing Google Cloud Measurements to independently verify the host image, the nested guest images, and the guest firmware. Release structures Both release types travel in one ASN.1 envelope. A release is identified by the SHA-256 digest of that envelope’s DER encoding, not of the inner structure alone, so reproducing a digest means encoding the wrapper too: ReleaseV2 ::= SEQUENCE { version INTEGER(2), appleSiliconV1 [0] AppleSiliconV1 OPTIONAL, gcpV1Workload [1] GCPv1Workload OPTIONAL, gcpV1Platform [2] GCPv1Platform OPTIONAL } The envelope defines an appleSiliconV1 member; an Apple silicon node’s release is recorded in the version 1 Release data structure structure. A software release carries GCPv1Workload, holding the boot measurements of each operating system on the node alongside the container identity: GCPv1Workload ::= SEQUENCE { workloadVMMeasurements [0] LinuxV1Measurements OPTIONAL, keyProtectionVMMeasurements [1] LinuxV1Measurements OPTIONAL, hostMeasurements [2] LinuxV1Measurements OPTIONAL, containerImageDigest [3] UTF8String OPTIONAL, -- OCI form, "sha256:…" variant [4] UTF8String OPTIONAL, -- afm, adm, … quotingEnclave [5] IntelTDXQuotingEnclave OPTIONAL } The verifier fills each LinuxV1Measurements block from the replayed boot log of the corresponding operating system: the SHA-384 digest of the unified kernel image, plus the OVMF digest that the quote body reports as that domain’s MRTD. The Workload VM’s block additionally carries the NVIDIA driver measurement. The host’s block holds the single boot-services application digest from its replayed boot log, using SHA-256 rather than SHA-384. The container image digest and the deployment variant come from the replayed launch log. The quotingEnclave block records the identity of the SGX quoting enclave that signed both TDX quotes: its MRENCLAVE, MRSIGNER, ISVPRODID, and ISVSVN. It belongs to the software release rather than the firmware release because the enclave binary ships in the host image that this release pins. A firmware release carries GCPv1Platform, holding the hardware TCB: GCPv1Platform ::= SEQUENCE { titan [0] OCTET STRING OPTIONAL, -- SHA256, Titan RW firmware hash from its EK cert bmc [1] OCTET STRING OPTIONAL, -- SHA256, EV_EFI_HCRTM_EVENT digest at PCR[0] bios [2] OCTET STRING OPTIONAL, -- SHA256, Google DRTM event digest at PCR[17] intelTDX [3] IntelTDXPlatform OPTIONAL, nvidiaGPU [4] NvidiaGPUMeasurement OPTIONAL } IntelTDXPlatform pins the TDX module and its security version with MRSEAM, MRSIGNERSEAM, and teeTcbSvn from the workload quote body. The FMSPC comes from the PCK certificate, and the CPUSVN — the running platform TCB — comes from the quoting enclave’s report. IntelTDXPlatform doesn’t record the enclave’s own identity; the software release carries it, as described above. The nvidiaGPU block carries the GPU product and VBIOS version with its attributed SPDM measurement blocks: the verifier splits the verified blocks between driver and VBIOS by fixed index sets, and skips all-zero digests. Because one GPU’s measurements stand in for all eight here, the verifier refuses to build a release when any GPU diverges from the rest. No field in either structure is compared against a reference value on its own. A verifier projects the values it reads out of the quotes, certificates, and event logs into the release structure, digests the encoded result, and checks that digest for inclusion in the log. A single divergent field, such as a different MRSEAM or a rolled-back teeTcbSvn, therefore produces a digest that matches no entry. IntelTDXPlatform defines a seamVersion field that the current projection leaves absent, because the first byte of teeTcbSvn already carries that value. tip: To reproduce a release’s measurements from its published artifacts, follow Reproduce the measurements. note: CloudAttestation-GoogleCloud: release structures confidential-space go-tpm-tools Binary transparency The reference measurements in the log record which software states PCC accepts. Confirming that a measurement corresponds to code that behaves faithfully requires the binaries themselves. The metadata that accompanies each release in the log lists where to download the artifacts measured by the release, so Downloading available releases can retrieve them. Apple and Google publish those artifacts: Google’s artifacts contain components that third parties build, including those from Intel and NVIDIA: Intel publishes the TDX module’s source, and the module builds reproducibly from it. The foundation models a node loads are measured through their Startup assets and attested like the rest of a release, but they are considered proprietary and not published as part of PCC’s transparency commitment. Third-party firmware Some third-party firmware presents additional challenges for independent verification: Each vendor’s firmware presents these challenges differently: