Release Transparency

PCC attestation capabilities support independently verifiable transparency.

Overview

The PCC transparency process is a pillar of Apple’s commitment to Private Cloud Compute’s transparency. We built strong Cloud Attestation capabilities that enable user devices to determine whether to send private requests to a PCC node by first receiving trusted cryptographic measurements of the node’s operating system and all its loaded cryptexes. We publish expected measurements — which correspond to release builds of PCC software — to a public, append-only cryptographic transparency log. User devices send private requests to PCC nodes only if their runtime measurements are present in the transparency log, which helps ensure the measurements refer to an authorized software build that security researchers can inspect.

[Image]

The Apple Transparency Service, which also enables Contact Key Verification, provides a log with the following properties:

  • Transparency: The log is publicly auditable, with all log entries available for inspection. Independent parties can verify that devices have the same view of the log as their own audit tooling.

  • Tamper resistance: The transparency log is backed by a Merkle tree and is append-only. Any attempt to alter or remove an entry once it’s added disrupts the hash tree in a way that independent parties can detect.

  • Non-targetability: Clients access the transparency log through a third-party MASQUE proxy (RFC 9298), which conceals the IP address of the device and therefore significantly increases the difficulty of split-view attacks, for example targeting specific users with a different view of the log.

Security researchers monitoring the log can obtain the binaries referenced by each entry, reproduce their measurements, and inspect the software by running it in the Virtual Research Environment. Researchers can also perform static analysis by disassembling the binaries.

Release data structure

Cloud Attestation cryptographically proves that a PCC node booted an operating system and loaded cryptexes that match the Image4 manifests provided in the attestation. To implement release transparency, CloudAttestation introduces the DER-encoded Release data structure, which describes the OS and cryptex Image4 tickets that compose a specific PCC 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 purpose, see Appendix: 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 SHA256 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 client 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.

PCC proxy node attestations carry a single transparency proof: that the proxy’s own release is included in the log at a specific log revision. When the user’s device validates this proof, it implicitly commits to that log revision as the trusted view of the log for any worker node the proxy forwards to. The proxy maintains its inclusion proof at a log revision that contains the currently unexpired releases, and validates worker node attestations transitively against that revision. For details, see Trusted log revisions.

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 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 this metadata is published, 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 entry. The validation process begins by ensuring that the Release data structure provided within the log leaf metadata hashes to the same value described by the log leaf entry itself. The contained canonicalized tickets can then be used to validate their corresponding binary images.

Release inclusion verification

A consistent view of the transparency log across all clients and auditors is an important property to ensure comprehensive inspectability. To protect against split-view attacks, where malicious actors try to trick a target’s client device to trust a diverging history of the transparency log, connections to the Apple Transparency Service are routed through third-party MASQUE proxies. The top-level domains of these proxies are hard-coded in the client, so malicious configuration updates can’t arbitrarily re-route transparency traffic.

At least once a day, the Apple Transparency Service promotes a log head of the transparency log to a milestone. The client tracks these milestones and validates cryptographic consistency proofs to previous milestones, all the way to the beginning of the log to ensure it’s inherently consistent.

When a user’s device is verifying that the release of a PCC node is included in the transparency log, there are two possible cases to consider, depending on whether Apple Transparency Service generated the proof before or after it promoted a milestone containing that release:

  • After: The attestation bundle contains an inclusion proof of the release in a recent milestone.

  • Before: The attestation bundle contains an inclusion proof of the release in a recent non-milestone log head, and additionally a consistency proof from a recent milestone to that log head.

During the daily milestone download, the user’s device checks to make sure the log is consistent and confirms that it had previously been served consistency proofs that are also consistent with new milestones. Neither check is expected to fail in normal usage. If either fails, however, the device alerts the user only if the consistency error is not addressed by a new log within 7 days. This provides a grace period for recovery from operational errors or software bugs that corrupt the log, while still ensuring that any actual attack is discoverable by security researchers. In other words, in the unlikely case that the consistency failure was due to an attack, the user is alerted to the attack after the 7-day grace period because the attacker is unable to roll back the log to the pre-attack state.

Entries in the transparency log also have associated expiry timestamps that the client validates. Releases that are in use beyond the initial 14-day lifetime are republished to the log with a new expiry. For additional details of the protocol, see Appendix: Transparency Log.

Because the transparency log is append-only, corruptions might require the creation of a replacement log populated with current data. In this case, Apple will publish a note on security.apple.com that explains the circumstances that required the new log. In addition, the Apple Transparency Service will continue to provide access to the previous log for inspectability.

Apple Intelligence report

You can view the software components running in Private Cloud Compute using the Appendix: Apple Intelligence Report. This report includes the Appendix: Attestation Bundle Contents used during each request your device submitted to Private Cloud Compute. The measurements of the release structure describing the software components running on a PCC node are included in each attestation, as well as an inclusion proof for those measurements in PCC’s transparency log. For more details on how to inspect the transparency log, see Inspecting Releases and Appendix: Transparency Log.