Apple Silicon Release Composition

Overview

The Release Transparency records measurements that a user’s device checks before it sends a request to a node. A measurement is auditable only if a researcher can obtain the code it measures, so we also publish the binaries behind each entry.

Release data structure

An Apple silicon node records the measurements a device compares against the log as a structured release entry, built from the Image4 tickets that its Apple Silicon Node Attestation covers. CloudAttestation introduces the DER-encoded Release data structure, which describes the OS and cryptex Image4 tickets that compose a specific release:

Release ::= SEQUENCE {
    version                 INTEGER(1),
    canonicalApTicket       OCTET STRING,
    canonicalCryptexTickets SET OF OCTET STRING,
    ...
}

Because Image4 manifests are personalized to each PCC node and contain device-specific information like device identifiers and anti-replay values, Release contains canonical representations of these tickets. Personalized tickets are canonicalized by setting the values of all tags listed in the uniq tag of the ticket to ASN.1 NULL (05 00). For a list of these fields and their purposes, see Appendix: Apple Silicon Secure Boot Ticket Canonicalization.

When a PCC node creates an attestation bundle, CloudAttestation computes the Release of its running software by converting the personalized tickets of the OS and loaded cryptexes to their canonical versions and constructing its Release. The node then requests cryptographic proofs from the Apple Transparency Service that the SHA-256 digest of that Release is part of the public transparency log. CloudAttestation then includes these proofs in the attestation bundle.

When validating an attestation, CloudAttestation on the user’s device independently computes the node’s Release from the personalized tickets in the attestation bundle and verifies the cryptographic proofs to confirm inclusion of the Release’s digest in the PCC transparency log.

Binary transparency

For each Release in the transparency log, Apple is committed to publishing all relevant machine-code binaries for inspection and independent measurement. There are two sources for these code objects:

• Secure Boot that directly describe boot firmware measurements

• Code signing, which contain code-directory hashes (CDHashes) for user-space executables

We publish both the boot firmware and user-space binaries to the Apple Content Delivery Network (CDN) for inspection, so researchers can verify that they match the measurements in their respective manifests and trust caches.

Under typical circumstances, we publish the binaries to the CDN, along with the leaf metadata described below, roughly simultaneously with the release’s entry into the transparency log. In cases where a release contains sensitive content, such as unreleased security fixes that also apply to other Apple platforms, or unannounced software features, publication of the binaries, the leaf metadata, or both might be delayed by up to 90 days.

Each transparency log leaf can carry additional metadata alongside its Release, including the CDN URLs needed to download the corresponding binaries, and identifying details such as application name, build version, and darwin-init configuration. Once we publish this metadata, CLI tooling provided as part of the Virtual Research Environment uses it to download these images and validate that their cryptographic hashes align with their corresponding transparency log entries. The validation process begins by ensuring that the Release provided within the log leaf metadata hashes to the same value described by the log leaf entry itself. The tooling can then use the contained canonicalized tickets to validate their corresponding binary images.