Jeffrey Paul: On Trusting Macintosh Hardware

Jeffrey Paul

On Trusting Macintosh Hardware
4 December 2020
( 1645 words, approximately 9 minutes reading time. )

Modern Apple computers can no longer be fully used and maintained in 100% offline environments, or in ways that will reasonably ensure that the computer is free of state-ordered tampering.

Buy a new mac, Intel (with T2 chip; all recent Intel machines) or M1, and it comes “activated” from the factory, with the OS installed and ready to use. Inside all current and recent Apple computers is a chip made by TSMC for Apple, to Apple’s design and specification. In the M1 this is the main (central) processing unit, in all of the Intel macs this is a chip called T2, which is responsible for allowing the Intel chip to boot.

If you wish to fully and completely restore these systems to their factory state for whatever reason, be it a virus or malware, reverting a testing or research configuration, preparing for resale, disk data corruption, whatever: the operating system for the special secured section of the processor (in M1-land) or the separate security/encryption chip (the T2, in Intel-land) must be restored, first and foremost, for the computer to even think about booting an OS. The only way to do this is to obtain a cryptographic signature from Apple, specific to that hardware. Apple provides these freely (provided your hardware isn’t marked as locked to a particular Apple ID, in which case they provide it freely if you provide the authentication data (password, et c) for that Apple ID).

Freely over the internet, that is.

I’m not talking about the main OS for the computer. This is the special, security-specific OS that runs either on a dedicated part of the M1 or the external T2 on Intel systems (BridgeOS, it’s called on T2). If the internal disk is totally blanked and wiped to restore the computer’s software to exactly as it was from the factory (or at least exactly as it was the last time you freshly wiped and reinstalled it from known-quantity, checksummed media), you must connect it to the internet to “activate” (that is, provide the appropriate cryptographic proofs to the security chip that will convince it to function) to begin using the internal disk again.

This means that macs, even the recent Intel ones, are now entirely unsuitable for certain critically important industrial applications:

  • airgapped systems that never touch the internet, such as:
    • those that are used in cryptocurrencies,
    • high value encryption ceremonies,
    • SCIFs,
    • or other secure/offline data processing facilities
  • systems that must maintain cryptographic integrity (such as being fully wiped and reinstalled, offline, from known-checksummed boot media)

  • systems that are offline for extended periods of time, where no internet access is readily available, and where such systems must be able to be repaired/reinstalled/restored whilst underway, such as:
    • remote research stations, such as those in Antarctica
    • ships at sea
    • space

Also, any country that decides to fully censor or block access to Apple or the US (without a special deal with Apple, such as in China) will render inoperable any mac or iPhone/iPad that gets wiped, as it won’t be able to reactivate.

This is a major bummer. I maintain a small number of high assurance systems that have never been connected to the internet, and have only come into contact with a limited set of devices that can possibly move data in or out of them. They were purchased in ways that are not linked to me or my companies, in person, off the shelf, for cash, to avoid targeted attacks. They’ve been fully wiped, zeroed out, and then booted from cryptographically verified (locally, on other high assurance systems) boot media. Some have had their internal firmwares dumped directly from the chips to verify that they are what they should be. Then a known-good OS image (again, verified on other machines) is used to install them, and they are used for certain extremely sensitive or high value cryptographic tasks, usually permanently offline (airgapped). Some are connected in very specific, limited ways to exclusively non-internet-connected “island” networks.

To repurpose these machines, or to audit/verify them, the steps are repeated: dump their data, wipe them fully, verify their firmware, reinstall from cryptographically verified media. (Optionally, audit to ensure that the data dumps are what they are expected to be.)

This is now impossible on any modern mac (and 100% of all recent macs with decent keyboards). Between the wipe and reinstallation step, the machine must connect to Apple to obtain a tiny bit of cryptographic signature data that allows it to be “activated”, enabling the security chip (which mediates all disk i/o) which then permits it to be reinstalled. The code that makes this request is closed source, and (I presume, and will verify soon) that the request itself is encrypted (and perhaps certificate pinned; more info on that soon). Based on the security system design, we know that the request necessarily includes a unique identifier of the system (likely the system serial number, or a different unique identifier inside of the processor that maps 1-to-1 in Apple internal records with the assembled system serial number). Because the connection back to Apple includes the IP address from which you’re connecting, and IP addresses are coarse (city-level) location, Apple knows that serial number X is at location Y at time Z when you reactivate. If you don’t reactivate, the computer simply won’t work at all, even if you have full, local reinstallation media.

Note that iPhones and iPads have all been like this since their first day of release: you can wipe them offline, but they’re very close to bricked until you can get them back online to “activate” them, which, just like the computer, exposes your device’s unique identifier, IP (coarse location), and timestamp to Apple. It does so again whenever you install an app, as a similar online authorization is required to put any app on such a device.

This means that the machine can potentially be tampered with by Apple (or anyone who can coerce Apple), on a system-by-system basis. There’s no way to take a system, wipe it, and reinstall it offline from a cryptographically verified exactly-the-same-OS-as-everyone-else-on-the-planet reinstallation USB. There’s now a step in between, where it identifies itself to Apple and persists some unique-to-that-system data to the long-term storage on the device, and this process is totally opaque to you. Will the security chip OS, or the main system OS, do something differently based on the contents of that system-unique data? There’s no simple or straightforward way to know, especially considering that the OS for the security chip is encrypted in such a way that only the security chip can decrypt it: you’re not allowed to inspect it at all. Reverse engineering these systems takes huge amounts of time; it was years after their release that the first software dumps of the iPhone’s security enclave code even became available (and, even then, the dumps are executable, not source code, and must be reverse engineered like any other compiled binary). This software is periodically updated with new versions, so any such previous in-depth public analysis is then totally worthless (from a security assurance standpoint) a short while later.

This is a huge degradation in the trustworthiness of the mac platform as a whole. It’s now impossible to know that a mac is obeying the wishes of its owner (via wipe and reinstall from known-good media) and hasn’t had some subtle “backdoor the disk encryption hardware because the FBI made us do it” flag jammed down its throat from half a planet away. To achieve that, one must now buy a brand new shrinkwrapped system (anonymously, in person, for cash, to avoid interdiction and other targeted attacks) and never, ever fully wipe its disk, or it’s now useless without letting Apple reach into it over the internet and modify its lowest level code however they wish.

(Before you Apple-bashers start shouting, I absolutely do not think this is some “but Apple is a hardware company!” conspiracy to sell a few thousand more single-use macs to the tiny segment of the population that requires high assurance systems.)

Recall also this is the same Apple who, under pressure from the CCP, censored apps used by pro-democracy protesters in Hong Kong. The ability to ensure that your device, once manufactured by Apple, is now no longer remotely controlled by Apple (and the governments with whom they cooperate), has been taken away from you in their latest models. (No one ever been able to have confidence in this fact on an iPhone or iPad.) Even if you trust Apple 100%, the fact that the state can effectively put a gun to their head and demand that they disable or surveil certain specific devices means that this platform as a whole is can no longer be made trustworthy, even with extreme and professional measures.

Every single mac sold today or recently is running under this system; you cannot put them into a locally known/verified state, a function where you control all of the inputs: it simply won’t allow you to use the disk at all without an external opaque input to that function, one that you cannot inspect or modify.

It’s no longer your machine; wipe its storage and that machine won’t function without explicit permission from Apple. Apple wants your machine to be secure: secure from everyone except Apple (and the governments to whom Apple must answer). Apple wants your data to be private: private from everyone except Apple (and the governments to whom Apple must answer).

These systems are now insecure by design: there is no way for them to be made secure.






I’ve the M1 Air in hand and will have more specifics (and pcaps) about specifically what it sends and receives both during activation, as well as normal system operation, soon.

About The Author

Jeffrey Paul is a hacker and security researcher living in Berlin and the founder of EEQJ, a consulting and research organization.

 sneak@sneak.berlin

 @sneak@sneak.berlin

 @sneakdotberlin

 @eeqj

 linkedin.com/in/jeffreypauleeqj