---
title: Apple Silicon Node Attestation
framework: Private Cloud Compute Security Guide
role: article
role_heading: Article
path: private-cloud-compute/applesiliconnodeattestation
---

# Apple Silicon Node Attestation

A node binds its boot measurements and its attested key into an attestation bundle that the user’s device verifies.

## Overview

Overview A user’s device sends a request to a PCC node only after it Node validation: cryptographic proof of the node’s identity, bound to the boot chain’s measurements, checked against the append-only Release Transparency. To make that proof meaningful, PCC pairs it with sufficient context for the device to check these claims about the node: The PCC node is Apple Silicon Hardware Integrity. A PCC node’s SEP protects the private key counterpart to its public key. The PCC node was securely configured and locked before generating the attestation. The attested measurements account for the node’s entire software stack: the base operating system and every cryptex. SEP-signed attestation The SEP requests a Cryptographic identity-resident, one-time signing key that the PKA derives from a random seed, the UID, and the Secure and measured boot (such as SEAL_DATA and SEAL_DATA_A). The SEP then requests a Hardware attestation of the DCIK to the one-time signing key, which cryptographically proves that the attestation was generated with the DCIK private key, and ties the one-time signing key to the hardware-verified boot measurements. The SEP then constructs an ASN.1-encoded data structure that consists of: Signed hardware attestation received from the PKA Public key of the SEP-protected attested key to which the user’s device encrypts PCC requests System state that the SEP manages, such as Software Sealed Registers and developer-mode status Anti-replay value that contains the SHA-256 digest of application-specific metadata, which the bundle carries outside the signed structure; the digest ties that metadata to the attestation The PKA signs only a digest of the attested key and the register contents, so the SEP also includes those register values in the structure, which lets the user’s device recompute the digest and verify the PKA’s signature over it. The SEP then asks the PKA block to sign that data structure with the one-time signing key. The attestation bundle Private Cloud Compute uses the CloudAttestation framework to surround the SEP-signed structure with the software manifests, certificates, and log proofs that give its register values meaning. CloudAttestation serializes the information into an Appendix: Apple Silicon Attestation Bundle Contents, a Protobuf structure that contains: SEP attestation of the attested encryption key AP Image4 manifest Cryptex Image4 manifests for every active Cryptexes Node’s DCIK certificate, issued through the PCC Certificate ceremony process Transparency log inclusion proof for the node’s attested software release, which on PCC proxy nodes also anchors Transitive Trust of proxied worker node releases Transparency log inclusion proof for the node’s DCIK certificate Application-specific metadata

This diagram shows the nested structure of an attestation bundle in simplified form, including the keys that sign certain information and where the information originates. Bundle verification On the user’s device, CloudAttestation validates the attestation bundle and ensures that data in the signed attestation matches contextual data in the attestation bundle. For example, the Software Sealed Registers must have the expected value given the set of cryptex manifests in the attestation bundle. Checking the node’s DCIK certificate, issued by the Data Center Attestation Certificate Authority (DCA CA), is a standard X.509 certificate validation. Checking the SEP attestation involves more specific processes: CloudAttestation validates the authenticity and integrity of the attestation itself, and confirms that the attesting DCIK public key matches the public key of the DCIK certificate. The framework then evaluates a security policy to assert the following security properties: Hardware-attested SEAL_DATA_A register contains the SHA-384 hash of the booted AP Image4 ticket. SEP-attested Cryptex Manifest Register matches a replay of the hash operations of all cryptexes, and the register is locked. SEP-attested Configuration Seal Register matches a replay of the hash operation of the darwin-init configuration. SEP-attested options on the Attested Request Handling include OS-bound and sealed-hashes-bound as defense-in-depth measures, so that encryption keys with access to user data are invalidated on system state changes. SEP-attested anti-replay value matches the SHA-256 digest of the application metadata section in the attestation bundle. SoC is production-fused. Ephemeral Data Mode and Restricted Execution Mode are enabled. Developer Mode is disabled. darwin-init config sets config-security-policy to a production policy: customer for a worker node, or customerProxy for a node that issues outbound requests to other PCC nodes under Transitive Trust. note: CloudAttestation: attestation verification