--- title: Apple Silicon Hardware Integrity framework: Private Cloud Compute Security Guide role: article role_heading: Article path: private-cloud-compute/hardwareintegrity --- # Apple Silicon Hardware Integrity Apple issues a node’s attestation identity only to silicon that the provisioning ceremony verified. ## Overview Overview Attestation allows a user’s device to communicate with a PCC node based on its strong cryptographic identity. Establishing trust in that identity requires knowing whether a specific Cryptographic identity (DCIK) belongs to a trustworthy PCC node. To enable this, the Data Center Attestation Certificate Authority (DCA CA) issues a certificate to each PCC node that identifies it as authentic PCC hardware and certifies that its hardware security features meet PCC security requirements. This certification is a representation that: Each certificate is issued to the public key that corresponds to a private key resident in the Secure Enclave of an authentic Apple silicon SoC. The hardware environment of the SoC, including the other components in the chassis, is not tampered with or modified. The DCA CA issues a certificate only after the ceremony confirms that a node’s components and their cryptographic identities match Apple’s recorded inventory for that chassis. That control prevents anyone — including a malicious insider — from injecting non-genuine hardware with untrustworthy attestations into the PCC fleet. When designing the provisioning process to ensure certificate integrity, we took inspiration from other multi-party ceremony processes, such as WebTrust’s CA Key Generation controls (or Cloud Key Vault), and applied these techniques to protect the ongoing process rather than just the generation of initial keys. This design ensures that it is exceptionally difficult to attempt to maliciously induce certificate misissuance, and that any such attempt requires wide-ranging and difficult efforts that leave a clear audit trail and are overwhelmingly likely to be detected. Hardware design The attack surface of the hardware is an important consideration. We define the trust boundary as the PCC node and consider all interfaces and inputs untrusted. These interfaces to other hardware components in the server chassis represent an attack surface that someone might attempt to use to circumvent our Secure Boot or attestation flows. Because we need many of these interfaces to manage the hardware and cannot remove them entirely, our threat model for such attacks focuses on detecting external manipulation. The manufacturing process starts with the assembly of multiple PCC nodes into a server chassis alongside an Apple silicon baseboard management controller (BMC). Each chassis design limits the physical attack surface of the PCC nodes and enables tampering detection. The BMC has USB connectivity to each of the PCC nodes and uses this connectivity to install software and manage system state. Each chassis design maintains a built-in tamper switch that resets the power supply for the entire chassis if someone opens the lid. Finally, we attest and seal all components of the chassis, including the BMC and system-management microcontrollers, into a manifest that we verify during provisioning and periodically thereafter. Hardware life cycle Protecting the hardware life cycle starts during manufacturing. Using the cryptographic identity of each Apple silicon SoC to track its life cycle from production to the finished server chassis produces reliable documentation of the hardware supply chain for our certificate issuance process. During assembly, each printed circuit board (PCB) is automatically scanned at high resolution, both optically and by X-ray, prior to the addition of any thermal modules. The images are permanently recorded and run through an anomaly detection mechanism that analyzes each PCB and compares it to known reference images. This record provides a point of reference for comparison — for example, following field failure of a part — while also providing assurance that every PCB matches Apple reference designs for PCC. The automated imaging is controlled by an Apple security team and is on a fully separate network from the rest of the factory-floor systems. During the assembly of a PCC chassis, we: Create a signed manifest of the cryptographic identity embedded in each SoC and microcontroller. Activate the built-in tamper switch. The chassis tamper switch is attached to a battery-backed, real-time clock that stores an anti-replay value in SRAM, which is rotated in the event that tampering activity activates the switch. Record the sealed identities into the Apple Component Attestation Authority (CAA), the same system we use to verify the integrity of parts in users’ devices. Record these identities in the manufacturing asset database and the data-center asset database. The use of multiple systems helps ensure that the compromise of a single credential doesn’t enable an attacker to bypass our process. For any shipment of PCC hardware, we work with our logistics partners to ensure a strong chain of custody from factory to integration centers. Each shipment is actively monitored, with both Apple employees and shipping partners monitoring the route that the package takes, along with expected delivery dates and times. All shipments are in secure, sealed packaging and photographed upon arrival. Integration-center staff assemble PCC node hardware into racks. During assembly, they record the layout of each rack in the Apple data-center asset database. Apple then re-verifies the expected systems by using this database when a data center deploys a rack. Once deployed, all software on the PCC chassis, including microcontroller firmware, is updated to a current production PCC release prior to performing the certificate issuance process. After Apple determines that a PCC chassis needs to be opened for repair or maintenance, our automated processes revoke the certificates for each node in the chassis and delete those nodes from the data-center asset database. Following the repair of a chassis, and after verifying its functionality, Apple schedules it for a new certificate issuance ceremony. This ceremony follows the same procedures as ingesting new systems, while also validating the repair records for the chassis. Users’ devices check for the revocation state of certificates in the attestation bundle. Devices accept only attestation bundles that are signed by a DCIK and include a valid certificate issued by the DCA CA. Similarly, on the server side, a PCC proxy node applies the same constraints to each node whose attestation it validates on behalf of a user’s device under Transitive Trust, and the leader of each Ensemble attestation applies them to each node within the ensemble. Both reject nodes that don’t have a valid certificate. Apple actively monitors the status of the tamper switch for each PCC chassis during regular operations to detect any unexpected event where the chassis is opened. When the tamper switch fires, the tamper anti-replay value rotates, invalidating the chassis attestation. The chassis then fails node validation, and Apple removes it from production until the integrity of the system is reaffirmed. To help ensure that hardware remains in the same secure condition as when it left the factory, Apple images and analyzes a statistically significant sample of PCC nodes using the same imaging process used when they were manufactured. Certificate ceremony process Before PCC nodes can handle user requests, a hardware audit helps ensure that they’re authentic, untampered Apple silicon, and that they meet our integrity standards. The audit implements multiple controls to validate hardware and software integrity for each PCC node and confirm that each node is deployed in the data center in the same state in which it left the factory. We perform the audit in two stages. An automated process first collects and durably records the evidence for each node: its component inventory, cryptographic attestations, and software measurements. A quorum of employees from three Apple organizations, witnessed by a third-party independent auditor, then confirms the recorded evidence and issues the certificate for each node. Collecting the evidence ahead of time makes the audit repeatable and independently auditable, and lets the witnessed stage confirm durable records instead of depending on a single live session. These controls verify that: The inventory of components and their cryptographic identities match both the data-center asset database and the manufacturing asset database, by querying the BMC on each PCC chassis. The data-center asset database provides change logs for the entire history of a chassis; the database drives data-center operations and is updated immediately following changes, such as when a chassis is installed into a rack, or racks are moved to a new location. The manufacturing asset database provides a record of each chassis in the factory prior to shipping. This record provides a fixed-in-time comparison point, to ensure that the contents of each chassis show no changes since shipment. Repair records of each chassis that was removed from service for maintenance are checked to ensure the integrity of the replacement components. The tamper switch in each chassis has not been activated, and the Component Attestation Authority uses a challenge-response to attest each chassis component that carries a cryptographic identity. This attestation provides cryptographic assurance in support of the integrity of each chassis. The software release deployed to each PCC node under audit has been published to the Release Transparency, so the release each node reports during the audit is one that anyone can inspect. Each SoC is a valid, physical Apple silicon part with the correct specifications. We issue Basic Attestation Authority certificates to SEP-backed keys and verify that the certificate attributes indicate that the SEP meets PCC security requirements. The third-party auditor separately verifies that the physical location of each chassis matches the data-center asset database. During scheduled data-center visits, the auditor selects chassis and confirms their physical placement, validating the integrity of the data-center asset database that drives these controls. After successful exercise of these controls, the ceremony team issues DCIK certificates from the DCA CA. The security of the DCA CA and its process is critical, because the ability to issue a DCIK certificate might enable an attacker to impersonate legitimate PCC nodes. We ensure its security by using an offline certificate authority backed by Hardware Security Modules (HSMs) that are designed to the latest FIPS-140-3 standard, and we require multi-party approval with hardware authentication tokens. The HSMs that the DCA CA uses to protect its private key produce a signed, immutable log for all key operations they perform, which is verified at the start of each ceremony by comparing the log from the end of the previous ceremony to the log at the start of the next. This ensures that any hypothetical certificate misissuance outside of sanctioned ceremonies is detected. If such a case were to be detected, the new ceremony would be terminated, and we’d publicly disclose this event as a critical security incident. Between ceremonies, the ceremony team places the HSM hardware in tamper-evident bags and stores the bags in a safe that requires multi-party control to unlock. Each quorum member also stores their HSM authentication tokens in tamper-evident bags in their representative organizations’ safes. This approach means each ceremony requires items from four different safes: the multi-party safe that stores the HSM hardware and three organization safes that store admin cards. Trust in these certificates rests on more than the offline CA alone. We record each DCIK certificate in the PCC transparency log, and a user’s device verifies that a node’s certificate is included in the log before trusting the node, in addition to verifying the DCA CA signature. PCC proxy nodes and ensemble leaders apply the same check to the nodes they validate. Independent auditors are able to enumerate the log and confirm that its contents match the certificates approved during each ceremony. Because a client trusts a node only when its certificate is both issued by the DCA CA and present in the auditable log, introducing a trusted node requires subverting both controls and still leaves a record that auditors can detect. The external third-party auditor follows SOC 2 and SOC 3 standards and is contractually required to be independent and impartial to this process. We publish the SOC 3 reports from the third-party auditor on the Apple Private Cloud Compute SOC 3 audit reports page; these reports cover the ceremonies that took place within their reporting period and attest that we follow the controls outlined in this document, which helps ensure that PCC nodes are genuine Apple silicon hardware. Because certification is critical to protect the PCC hardware root of trust, we engaged a third-party security research firm to perform a detailed review of the ceremony process. Apple will publish the third-party firm’s report after the engagement is completed.