Appendix: Google Cloud Attestation Bundle Contents

Overview

A PCC proxy node validates a Google Cloud node’s attestation on behalf of the user’s device, checking the same attestation properties and anchoring log inclusion to the Trusted log revisions that the device verified. After the request, the proxy provides the client with the attestation bundles of the nodes involved, and the client includes them in the Appendix: Apple Intelligence Report as base64-encoded binary Protobuf data.

The Understand attestation, the transparency log, and releases parse and verify a bundle in either form, reading it from a Report or from the encoded protobuf directly. Google Cloud Node Attestation describes the attestation model these fields encode: how the evidence is produced, bound together, and checked.

Extensible bundle format

Attestation bundles are binary Protobuf-encoded. Each platform’s roots of trust produce evidence of a different shape, so the top-level bundle sets exactly one per-architecture variant in a oneof, and a client dispatches on the variant it finds:

message AttestationBundle {
    oneof attestation_bundle {
        AppleSiliconAttestationBundle apple_silicon_attestation_bundle = 1;
        GCPv1AttestationBundle gcpv1_attestation_bundle = 2;
        TestAttestationBundle test_attestation_bundle = 99;
    }
    uint32 version = 2047; // version 2
}

The Google Cloud variant

The GCPv1AttestationBundle groups a node’s evidence into three categories: the cryptographically signed attestation blobs, the X.509 platform certificates identifying the platform, and a set of transparency log proofs.

message GCPv1AttestationBundle {
    GCPv1Attestation gcpv1_attestation = 1;
    PlatformCertificates platform_certificates = 2;
    GCPv1TransparencyProofs transparency_proofs = 3;
}
message GCPv1Attestation {
    confidential_space.VmAttestation tdx_workload = 1;
    confidential_space.VmAttestation tdx_key_protection = 2;
    bytes attested_metadata = 3;
    confidential_space.HostAttestation host_attestation = 4;
}
message PlatformCertificates {
    repeated bytes apple_chain = 1;
}
message GCPv1TransparencyProofs {
    TransparencyLog.ATLogProofs certificate_transparency_proofs = 1;
    TransparencyLog.ATLogProofs software_transparency_proofs = 2;
    TransparencyLog.ATLogProofs firmware_transparency_proofs = 3;
}

The GCPv1Attestation message contains all direct attestation evidence from each attested component on the platform. The confidential_space.VmAttestation message, defined in Google’s confidential-space protobuf, contains the Intel TDX Attestation Quote describing the security state of a confidential virtual machine.

There are two TDX attestations in the bundle. The first covers the confidential VM running the workload code. The second covers an auxiliary confidential VM that performs the node’s cryptographic key-management operations in an environment isolated from the Workload VM. In addition to the key-management and endorsement services, that VM runs only a log relay that forwards those two services’ journal entries to the Workload VM for onward delivery.

Each VmAttestation carries two event logs alongside its quote: a boot event log, replayed against RTMR[0] through RTMR[2], and a launch event log, replayed against RTMR[3]. Between them, they cover:

• Secure Boot configuration, including the initial EFI variable state and whether UEFI debug mode was enabled or DMA protection was disabled

• Digest of the unified kernel image the VM booted as the sole EFI application

• Workload container’s image digest and its launch environment

• Attestation report of each NVIDIA GPU attached to the platform

A verifier replays both VMs’ boot logs, but only the Workload VM launches a container through the Confidential Space launcher, so the container and GPU records appear only in its launch log. Each VM also runs service containers from its own measured disk image, and the image measurement covers those containers directly.

The confidential_space.HostAttestation message contains the TPM quote from the host Titan TPM device, which describes measurements of the host firmware and operating system. It also carries auxiliary attestations, signed separately by the same endorsement key, over NV indices that the PCRs do not cover. The Detecting a warm-reset attack is one of them.

The attested_metadata field carries a serialized AttestedMetadata message: a caller-supplied nonce, caller-supplied application data in appData, and the digest of the certificate-transparency log head the node witnessed at attestation time.

message AttestedMetadata {
    bytes nonce = 1;
    google.protobuf.Any appData = 2;
    bytes certificate_transparency_loghead_digest = 99;
}

Every quote in the bundle is taken over SHA256(attested_metadata), which ties the whole serialized message to the signed evidence. The host TPM signs that digest verbatim as its quote’s qualifying data; each TDX quote folds it into the quote’s report data. The caller’s nonce therefore reaches the signed evidence only through this digest. An empty message still hashes to a fixed digest that the quotes also carry, so an attacker cannot strip or alter the metadata without breaking the binding. Google Cloud Node Attestation gives the exact derivation for each quote type.

PlatformCertificates carries a certificate chain whose leaf re-certifies the CPU’s Intel Provisioning Certification Key under an Apple root. That leaf records the stable device identifiers of the Titan chip, the CPU, and each GPU in an X.509v3 extension.

The bundle includes three sets of proofs against the PCC transparency log:

• Certificate Transparency proofs for the Apple-issued X.509 platform certificate

• Proofs for the platform’s deployed software, which Apple builds and publishes

• Proofs for the firmware installed on the platform, whose reference measurements Google supplies and whose release cadence Google controls

Google Cloud Software Transparency explains why the software and firmware releases are logged separately, and gives the structures their digests cover.