A brief history of Mac enclaves and exclaves

Until 2016, no Mac had a processor dedicated to working with secrets like encryption keys, and those had to be handled by the main CPU, as in most other computers. This made it feasible for vulnerabilities in macOS and the CPU to be exploited to surrender those secrets, allowing an attacker to open anything protected by FileVault, for example.

Intel Macs

With the release of the first 13-inch MacBook Pro with a Touch Bar, Apple built its first Apple silicon chip into an Intel Mac, the T1, based on the S2 chip used in the Apple Watch Series 2. The T1 handles biometric data for Touch ID, as well as running the Touch Bar’s display and protecting Apple Pay. Although this isn’t a complete Secure Enclave, it was the first step on the road to Apple silicon Macs.

A year later, in December 2017, with the release of the iMac Pro, Apple moved up to the Mac’s first Secure Enclave in its T2 chip. This is more complex than the T1, and consists of a four-core main CPU derived from the A10 used in the iPhone 7 and contemporaneous iPads and iPod Touch.

Alongside that is a 32-bit Arm CPU running a completely different operating system, sepOS (a custom version of the L4 microkernel), dedicated to handling and working with the secrets protected by its Secure Enclave. That has its own secure EEPROM storage, an AES engine to perform hardware-accelerated encryption and decryption for the internal SSD, and more. Most subsequent Intel Macs came with a T2 chip, although they were incorporated late into iMacs, which didn’t get them until 2020, and the Mac Pro in 2019.

Apple silicon Macs

When the first M1 models were released in November 2020, they all came with integral Secure Enclaves, as have all subsequent M-series chips. These are a significant improvement on their predecessors in the T2, adding replay prevention, a second-generation Secure Storage Component, and more. They continue to run their own operating system, sepOS.

Among their more puzzling features is the potential to support Face ID, although that hasn’t yet been implemented on any Mac. Rather than integrate the required Secure Neural Engine into the Secure Enclave itself, this is now implemented as a secure mode in the main Neural Engine (ANE), but apparently remains unused in M-series chips.

Virtual machines

Prior to macOS Sequoia, macOS virtual machines (VMs) running in lightweight virtualisation on Apple silicon are unable to use Apple ID or to access iCloud, because they’re unable to access any protected secrets from the host Secure Enclave. In macOS 15 and later, creation of a VM running macOS 15 or later configures an identity derived from the host Secure Enclave, enabling access to resources requiring Apple ID including iCloud. If that VM is then run on a host using a different Apple ID, a different identity has to be created, again derived from the Secure Enclave.

Private Cloud Compute

Another new feature being introduced in macOS Sequoia is Private Cloud Compute (PCC), to support off-device Apple Intelligence. Apple has already stated that PCC nodes have a Secure Enclave. All code that can run on a node is part of a trust cache signed by Apple and loaded by the Secure Enclave to ensure that it can’t be changed at runtime. The enclave is also used to generate non-persisting encryption keys, and to enforce guarantees that those keys can’t be duplicated or extracted. It’s responsible for cryptographic erasure of the user’s data volume when it reboots at the end of each session, presumably using the same key erasure mechanism as in Erase All Content & Settings in macOS.

Most interesting of all, Apple has promised to provide images of the PCC used, including the sepOS firmware in plain text, for researchers to scrutinise.

Exclaves

While an enclave is a territory entirely surrounded by the territory of another state, an exclave is an isolated fragment of a state that exists separately from the main part of that state. Although exclave isn’t a term normally used in computing, macOS 14.4 introduced three kernel extensions concerned with exclaves. They seem to have appeared first in iOS 17, where they’re thought to code domains isolated from the kernel that protect key functions in macOS even when the kernel becomes compromised. This in turn suggests that Apple is in the process of refactoring the kernel into a central micro-kernel with protected exclaves. This has yet to be examined in Sequoia.