Apple iMac Pro and Secure Storage
Introduction
With the introduction of the iMac Pro by Apple in late December 2017, a number of brand-new features premiered on the macOS platform. While Apple had already introduced a dedicated security coprocessor with the inclusion of the T1 processor in the late 2016 MacBook Pro with Touch Bar, it served only a few specific tasks like driving the Touch Bar display and touch screen, reading fingerprints from the Touch ID sensor and storing fingerprint data in the T1’s Secure Enclave Processor or SEP.
In keeping with its limited system architecture role, the T1 Application Processor or AP was based on a 32-bit ARMv7 processor similar to the S1 AP used in the Apple Watch. Its dedicated watchOS-based OS is named BridgeOS, while the hardware identifier is iBridge.
The announcement of the iMac Pro made reference to the presence of another security processor but also mentioned a number of changes to system security. Touch ID would not be present and, while rumored to be an option, Face ID was also not present. Instead of focusing on mobile-friendly security features like touch or facial recognition, Apple instead used the next-generation T2 coprocessor to implement an overhauled boot security system, which it named Secure Boot.
Due to the increased reliance on a security coprocessor, Apple decided to give the T2 coprocessor a significant performance bump by basing it on the same AP core as the one found in the Apple A10 processor, a 64-bit ARMv8 processor also found in the iPhone 7 and 7 Plus. The T2 coprocessor is not exactly the same as the A10 processor since it incorporates only one of the T801x cores that make up the A10 package, but is a significant step up in capabilities from the earlier T1 AP. Apple gave the AP the model number T8012, references to which can be found throughout BridgeOS. A separate Secure Enclave Processor or SEP is also found in the T2, similar to that in the T1.
Given all of these changes, we wanted to explore how the T2 coprocessor was being used by Apple and how it currently fits into the larger system security model, as well as how this may evolve in the future. What follows is the first part of this exploration where we describe how the T2 coprocessor is used to implement Secure Boot on the iMac Pro, as well as comparing and contrasting this Secure Boot approach to those that have been present in Apple’s iDevices for a number of years.
Storage and the T2
First, we need to understand the role the T2 coprocessor plays in the security of the data stored on a system and understand the tasks that have been delegated to it from the main CPU. What follows is a technical walk through of what we discovered during our analysis and the conclusions we have drawn from it.
By significantly stepping up the performance of the T2 coprocessor in order to handle early boot tasks, the T2 coprocessor also gained a number of abilities that can be leveraged to enhance the security of at-rest data storage for the iMac Pro. Apple announced its improved security capabilities on the iMac Pro’s official product page:
“T2 also makes iMac Pro even more secure, thanks to a Secure Enclave coprocessor that provides the foundation for new encrypted storage and secure boot capabilities. The data on your SSD is encrypted using dedicated AES hardware with no effect on the SSD’s performance, while keeping the Intel Xeon processor free for your compute tasks.”
In addition, Apple published the “About encryption on your iMac Pro” support document, which further states:
“Data on your iMac Pro built-in, solid-state drive (SSD) is encrypted using a hardware accelerated AES engine built into the T2 chip. The encryption is performed with 256 bit keys tied to a unique identifier within the T2 chip.”
These claims are backed up by what we found in BridgeOS itself when we looked at the com.apple.iokit.IOCryptoAcceleratorFamily.kext kernel extension which implements a number of cryptographic acceleration methods. Specifically, the IOAESAccelerator class is what helps to offload the work previously done by the AES-XTS support built into x86 CPUs, as documented here:
“The IOAESAccelerator service provides hardware-accelerated AES encryption/decryption functions in CBC mode. It also provides access to the secure UID (2000) and GID (1000) keys, and the generated securityd (2101/0x835) and various firmware encryption keys.”
But Apple went further than simply offloading the main CPU-bound AES encryption work to the T2 coprocessor as dedicated security coprocessor. In order to make it harder for an attacker with physical access to an iMac Pro to gain access to data stored on the internal storage, Apple implemented what appears to be encrypted storage in a way that puts the T2 coprocessor squarely in the middle of the I/O path instead of giving the main CPU access via the normal PCIe/NVMe path.
Further evidence about the use of dedicated encryption acceleration hardware and software can be found by taking a look at SEPOS since the decryption key for the SEPOS image found on the iPhone 5s became available in August 2017.
Apple NVMe
In order to understand Apple’s decision to switch from the older Serial ATA (SATA) interface to the higher-performing Non-Volatile Memory Express or NVMe, we recommend reading Ramtin Amin’s excellent deep-dive into its implementation. The main advantages of using NVMe to provide SSD storage access are that by using all the available parallel operations possible with modern flash-based storage over a four-lane PCIe connection, much better I/O speeds can be achieved compared to older HDD-specific interfaces.
In a nutshell, NVMe was designed with solid state storage as a central design goal, unlike older interfaces like SATA that were designed to meet the needs of spinning platter hard disks. NVMe support on both macOS and BridgeOS is handled by the com.apple.iokit.IONVMeFamily.kext kernel extension. When we take a look at the IORegistry layout for the iMac Pro’s SSD storage device, we can see this more clearly:
In the above diagram, we can see the Apple SSD AP1024M Media device as it is visible to the user in macOS. This device is made available as a regular block storage device via the IOStorageFamily.kext kernel extension, which, in its place, is support by the NVMe kernel extension. Meanwhile, the Apple ANS2 (Apple NAND Storage) controller appears to be only found on recent iOS devices such as the iPad Pro, iPhone 7, 8 and X. Inspection of Apple’s “iOS Security Guide” white paper gives some further insight into this:
“Every iOS device has a dedicated AES-256 crypto engine built into the DMA path between the flash storage and main system memory, making file encryption highly efficient. On A9 or later A-series processors, the flash storage subsystem is on an isolated bus that is only granted access to memory containing user data via the DMA crypto engine.”
This statement confirms what we’ve seen in the BridgeOS code itself, as well as what is known about the T2 coprocessor external connectivity: the pair of physical SSD memory chips that are exposed as a single device to macOS are directly connected via dual x4 PCIe lanes to the SoC where they are uniquely paired to the AP and at-rest encryption is enabled by default. Apple confirms this as well in the white paper:
“The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor and Secure Enclave during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed by dedicated AES engines implemented in silicon using the UID or GID as a key. Additionally, the Secure Enclave’s UID and GID can only be used by the AES engine dedicated to the Secure Enclave.”
The unique pairing here provides some very important security properties that prevent the memory chips that comprise the SSD itself from being physically removed from the system and connected to a different system, or from having their contents extracted from the chips and flashed onto SSD chips in another system. Apple states in further detail the way in which the T2 coprocessor and the SSD chips are uniquely bound together to provide these protections when the SSD chips are first initialized:
“On T1, S2, S3, and A9 or later A-series processors, each Secure Enclave generates its own UID (Unique ID). [...] The UID allows data to be cryptographically tied to a particular device. For example, the key hierarchy protecting the file system includes the UID, so if the memory chips are physically moved from one device to another, the files are inaccessible.”
At the time of last publication, Apple had not yet updated the information for the T2 coprocessor, but our research shows that the above largely applies to its implementation as well.
By further exploring the complete output of the IODeviceTree plane of IORegistry (which can be retrieved from BridgeOS running on the T2 coprocessor using sysdiagnose -c), we can see the logical hierarchy of the AES crypto engine and the ANS2 device that sits behind it.
macOS Device Discovery
On the macOS side, it’s interesting to see how the AppleNVMeFamily-backed storage device is exposed over a single x4 PCIe lane to the x86 CPU itself. As far as the x86 CPU and macOS running on it are concerned, the iMac Pro’s SSD storage is just a regular NVMe-compatible storage device when discovered; yet we’ve seen a number of transparent processes will have occurred and continue to occur during normal use in order to encrypt data as it written to the SSD’s memory chips.
The hierarchical view of the storage device that as we have now learned is actively managed by the T2 coprocessor and BridgeOS is as follows:
Filevault and Secure Storage
By now, we’ve learned that by default, the iMac Pro’s storage is encrypted using a unique identifier stored in its T2 coprocessor. This prevents physical attacks involving removing the SSD memory chips, thus making them useless when installed anywhere but the iMac Pro they were original paired with.
In order to also protect against physical attacks on the same physical machine, full-disk encryption (FDE) comes into play. Apple has implemented FDE for a number of years through its FileVault feature. FileVault is a fully capable FDE system that has gone through a number of evolutions since its introduction in Mac OS X 10.7.
Originally, FileVault only encrypted the user’s home folder as a disk image. FileVault 2 fully encrypted volumes at the block level using AES-XTS and 128 bit blocks with a 256-bit key by leveraging its CoreStorage logical volume management. A more in-depth description of the FileVault 2 architecture can be found in this archived document from Apple’s Training website.
With the introduction of macOS 10.13 High Sierra, Apple introduced another evolution of FileVault that was mostly unseen but leverages the new APFS filesystem’s native encryption capabilities to allow for instant-on FDE and more streamlined enrollment of additional users.
We believe that, with the introduction of always-on disk encryption in the iMac Pro, the FileVault activation process is now essentially identical to how a passcode protects an iOS device. When enabled, the user’s passphrase is entangled with the device’s hardware UID and used to create further derived keys that are used to encrypt and decrypt. The Apple iOS Security white paper goes into more detail, but our findings corroborate that the iMac Pro’s T2 coprocessor operates in the same way. The Passcode key that is derived from the user’s passphrase is stored in the Secure Enclave that is part of the T2 coprocessor and not accessible through unprivileged means.
Conclusion
This is the first in a series of research articles about the iMac Pro and its new security features that we plan to publish in future installments. We decided to take a closer look at its storage security improvements first since it is prominently featured in Apple’s marketing for the iMac Pro. With the inclusion of its next generation of security coprocessors, Apple has set the standard for what to expect for the future of the Mac platform. By taking their proven success and leadership on the iOS platform with respect to security and privacy, Apple has been able to fast-track catching up with competing platforms that already implement modern hardware security features.
Windows and ChromeOS’s support for TPMs, Universal 2nd Factor (U2F) and Universal Authentication Factor (UAF)/Webauthn have made them popular choices for security-minded customers. We hope that Apple pays close attention to these technologies as well, as they are quickly gaining adoption by the larger community, in addition to further improving its own proven platform security strength.
We expect to see future Mac models adopting many, if not all, of these security features while further iterating on them as well.