Inspecting Releases

Inspect releases in the transparency log for either node platform.

Exploring available releases

You can inspect published releases of the Private Cloud Compute component directly from the live transparency log using the pccvre release command:

% pccvre release list
Found 10 releases:

   19930: TIE (downloadable)
	b4e91d75d4cb2df8b4c2b06bdd1cbe4611fc2d8823cacfe53d93b5676481e192
   19929:  (downloadable)
	ea443d36a2cd962570c1201ff20cc1e0265172af0cc99a06994ab306daa49ee6
   19162: TIE Proxy (downloadable)
	502b0514e353194b9e16c2cb50920c3e3f7bd2383162e1f2cc572a9fe9aa657f
...

By default, the 10 most recent release entries are displayed, each as a release index followed by the application name as published to the transparency log, and a (SHA-256) digest of the release structure the entry records. The name of an application that runs on a Google Cloud node ends in a suffix identifying the platform, so the listing tells you which kind of node a release targets. As older devices don’t support Transitive Trust, any releases for such clients don’t have an application name listed. Apple may also withhold a release’s leaf metadata, including its application name and CDN download location, for up to 90 days, for example, to avoid revealing an unannounced application. See Binary transparency. Releases in this state are listed without an application name until the metadata is published. If multiple releases have the same digest, only the newest one is displayed unless the --all option is used. There are additional types of entries in the transparency log that are not listed by this command, and account for gaps in the index numbers, for example, key bundles and “liveness” checks used by operations.

A Google Cloud node contributes Release structures, and both appear in this listing: a software release covering the code the node runs, and a firmware release covering the node’s Titan security chip, its baseboard management controller (BMC), its BIOS, and its GPU firmware. An Apple silicon node contributes one kind of release.

Use pccvre release dump to view additional details for a release. What it displays depends on which structure the entry holds:

Apple silicon releases

A release displays the individual digests for the OS manifest ticket along with the associated cryptexes, such as Private Cloud Extensions. The software components are published; the model and adapter images are not.

Google Cloud releases

A software release displays the Unified Kernel Image and guest firmware digests for the Workload VM and the Key Protection Service VM, the host’s Unified Kernel Image digest, the attached GPUs with their SPDM measurement blocks, the container image digest, the measured variant name, and the quoting enclave’s identity. A firmware release displays the Titan, BMC, and BIOS measurements, an Intel TDX block covering the TDX module and its trusted computing base, and the GPU firmware.

Adding --detail appends the release’s published metadata, which names each downloadable asset and its URL; adding --json emits the whole entry, including the raw encoded release, for a tool to consume.

   19930: TIE (downloadable)
	b4e91d75d4cb2df8b4c2b06bdd1cbe4611fc2d8823cacfe53d93b5676481e192

Expires: 2025-07-11T00:33:45
Created: 2025-06-05T14:55:44
Application: TIE
Tickets
      OS: ef571c0f38c4493008d43de4b298adcfb9db849e9d317f1bfd7c26d2dc289e70
    Cryptexes
    Code: eb0312520bb2e189f6dd97a340018c01be0a7d8e9b2229c314e0099149c41cb6
    Data: 89841dd34a6857bb450b26b3f86cefd3630f44a27222032c79ea1c0b8ea3b948
    Data: 11e677bb222f35da0fb26dbd5994614d9d1a0e2401f4824099f817b255b23c08
    Data: 13dcddb266ceda432eeb09f14e5c19b16e0d8f90f640dcb83fb6674e3b101080
    Data: 2eb87b63c64ece5a96c5a27b7141ed1739c36940f381a3da98988a97088d0862

The --count and --start/--end arguments can be used to select ranges (by index number) and the number of past releases.

Downloading available releases

You can download a release either by index number or its associated digest using the following command:

% pccvre release download [--overwrite] <index | sha256>

What a download yields depends on the platform the release targets:

Apple silicon releases

Software cryptexes are downloaded into a cached folder along with a demo model for research purposes. You can’t download specific cryptexes; assets already in the cache, such as the demo model, are normally skipped (--overwrite downloads and updates them).

Google Cloud releases

A software release yields the host operating-system image archive and the workload container archive. Reproducing Google Cloud Measurements covers recomputing a release’s measurements from those archives.

Auditing the transparency log

You can audit the correctness of the PCC transparency log with the transparency-log subcommand:

% pccvre transparency-log audit --continuous
Top Level Tree: (466098/466098)
	Valid root digest: a77c032ca697ceb467a78a2a71a784f44dc84a86c325a70b465c33323ff4fc41 ✅
Per Application Tree: (30805/30805)
	Valid root digest: 3cf1cdaf4a1414cd7246b66372d5aa413b7d6ffe987194abb06b14809710b452 ✅
Application Tree: (37845/37845)
	Valid root digest: ba94e99d4b6b64d001c6bc4f68f90ebf1026261797ec5a394111f6cc5c15d4ec ✅
waiting 30s until next update

All downloaded leaves are stored as JSON files under ~/Library/Application Support/com.apple.security-research.pccvre/transparency-log/<environment>:

% ls ~/Library/Application\ Support/com.apple.security-research.pccvre/transparency-log/production
applicationTree.json
perApplicationTree.json
topLevelTree.json

Subsequent invocations of the transparency-log subcommand will resume verification from the previously downloaded leaves.

Verifying an attestation’s inclusion proof

Attestations contain Merkle inclusion proofs, each in the form of a Log server protocol. An Apple silicon node carries two: one over the Release data structure structure it composes, and one over its DCIK certificate. A Google Cloud node carries three, over its software release, its firmware release, and its device identity certificate. The proof format and the verification procedure are the same in every case. A LogEntry contains several key fields of data that you can use to verify the inclusion proof against a locally constructed view of the transparency log:

  1. SignedLogHead, which contains both the revision number and leaf count of the transparency log used to generate the inclusion proof.

  2. hashesOfPeersInPathToRoot, which contains an array of peer hashes needed to reconstruct the Merkle root hash.

  3. nodePosition, which indicates the index of the leaf node for which the inclusion proof is generated.

With all of these items, you can use the information received from the SignedLogHead to slice a local copy of the transparency log from 0..<logSize. This constructs a view of the transparency log just as it was when the server created the inclusion proof.

The Merkle root hash of this sliced view of the log will match the root hash computed from hashesOfPeersInPathToRoot and nodePosition. For more details on how Merkle inclusion proofs work, see Section 2.1.3 of Certificate Transparency.

Assuming you already have a verified and up-to-date local copy of the transparency log from the pccvre transparency-log audit command, you can use the pccvre transparency-log verify-inclusion command to verify a specific attestation from an Appendix: Apple Intelligence Report:

% pccvre transparency-log verify-inclusion \
    --request-index <request-index> \
    --attestation-index <attestation-index> \
    <path to Apple_Intelligence_Report.json>

Since an Apple Intelligence Report contains many requests, each containing many attestations, you must provide both the request index and the attestation index for a given request. For example, to verify the first attestation of the first request:

% pccvre transparency-log verify-inclusion \
    --request-index=0 \
    --attestation-index=0 \
    ~/Downloads/Apple_Intelligence_Report.json

Successfully verified inclusion proof ✅ (revision: 7211, index: 7798, logSize: 7901, rootDigest: a8f06134677b3034ee2cb4359546b6032a427a031de5d4df613e8666275aa104)

You can use pccvre release dump -R <index> to view information about the release.