---
title: Apple Silicon Root of Trust
framework: Private Cloud Compute Security Guide
role: article
role_heading: Article
path: private-cloud-compute/hardwarerootoftrust
---

# Apple Silicon Root of Trust

A node roots its attestations in immutable hardware features that cannot change after manufacturing.

## Overview

Overview The trustworthiness of an attestation depends on the hardware that signs it. That hardware is Apple silicon, an immutable component of the system that serves as the basis for the node’s software attestations. Immutable features of Apple silicon A node’s Apple Silicon Node Attestation depends on three features of Apple silicon: Hardware-backed cryptographic identity: Cryptographic keys are securely generated during manufacturing and fused into the silicon. These keys are accessible only to the Secure Enclave Processor (SEP) to perform cryptographic operations that prove its identity. They remain protected by the hardware and are not exportable. Secure and measured boot: Secure Boot technology measures and validates all code running on the device. The Boot ROM, the start of the Secure Boot process, is laid onto the silicon during fabrication and is therefore immutable. Hardware-based attestation: The Secure Enclave can sign measurements of the software using its hardware-backed identity. Even Apple cannot change these features after manufacturing, and Apple’s supply-chain integrity and code-audit processes add multiple rounds of both internal and external verification. When combined, these features let a node produce hardware-signed attestations over its measurements that a user’s device can check against the transparency log. Cryptographic identity The Secure Enclave is a special coprocessor on Apple’s System-on-Chip (SoC). It’s built on a set of related hardware security features, including a true random-number generator, a Public-Key Accelerator (PKA), and a dedicated Advanced Encryption Standard engine. The SEP integrates these blocks to provide key-management primitives that remain secure even if the rest of the system is compromised. The Secure Enclave contains special hardware blocks to enable the use of hardware-bound keys. During manufacturing, the Secure Enclave executes a special process within its own trust boundary that uses the dedicated true random-number generator to fuse a Unique ID (UID) into the silicon. The PKA derives its hardware keys from this UID, so a hardware key the PKA generates is entangled with the UID and bound to the given Secure Enclave. The UID and the private half of every key the PKA derives from it are never exposed to any software, even software running on the SEP itself. The SEP can access them only indirectly through limited functionality exposed by the PKA. The Secure Enclave can use the UID to derive ephemeral keys by mixing it with random seeds or to derive long-lived keys by mixing it with fixed seeds. These long-lived keys form the basis of a durable cryptographic identity that can be used to identify a particular SEP, and therefore a particular SoC. For Private Cloud Compute, we created a new Data Center Identity Key (DCIK), which is generated within the PKA of the Secure Enclave using a fixed seed, and the public pairing of this identity key is recorded in Apple’s device database during manufacturing. Secure and measured boot The Application Processor (AP) block is the powerhouse that provides the primary compute for the SoC. The AP’s root of trust begins with Boot ROM, the boot code that’s laid onto the silicon during SoC fabrication. This code is part of the SoC silicon and is immutable. Boot ROM handles initial bootstrapping of the SoC, after which it validates the node’s Image4 boot manifest, the APTicket. Image4 is Apple’s ASN.1-based, Secure Boot specification, which we use to manage the authorized lifetime of code through our Trusted Signing Service (TSS). The APTicket contains signed measurements of the iBoot (system boot loader) image and each firmware image for the system. After validating the manifest, Boot ROM measures the iBoot image and ensures that it matches the manifest. Before passing control to iBoot, Boot ROM locks the digest of the manifest into the write-once system register SEAL_DATA_A. Boot ROM is immutable, which means its behavior of enforcing Secure Boot and locking the manifest in SEAL_DATA_A cannot be changed after manufacturing, even by Apple. After iBoot completes setup, it loads and validates additional boot images described in the APTicket. The Secure Enclave’s trust boundary does not extend to the rest of the SoC, so the SEP implements its own Secure Boot. Upon reset, the SEP begins executing from the Secure Enclave Boot ROM (SEPROM). SEPROM is immutable, like Boot ROM on the AP, and is laid down on the silicon during SoC fabrication. SEPROM forms the hardware root of trust on the SEP and bootstraps sepOS, the firmware image that runs on the SEP. Much like how Boot ROM locks down SEAL_DATA_A before handing off code execution to iBoot, the SEPROM locks down a register known as SEAL_DATA with the digest of the sepOS image. Hardware attestation Hardware attestation builds upon measured boot and hardware-rooted cryptographic identities. The PKA can generate attestations that attest key residency of PKA-resident keys to security-critical system states such as SEAL_DATA and SEAL_DATA_A. This attestation works by hashing the public key of the attested key with the content of these hardware registers, and then signing the resulting hash with a long-lived key, such as the DCIK. This step cryptographically ties a given key pair to the measurements booted by Boot ROM. Because the PKA behavior is implemented entirely within hardware, including reading the values of the SEAL_DATA and SEAL_DATA_A registers, this behavior is also immutable and cannot be changed after manufacturing.