Apple’s Platform Security Guide Places Greater Emphasis on Vertical Integration

Last week, Apple published an update to its Platform Security Guide. The PDF now weighs in at nearly two hundred pages and includes a lot of updates — particularly with the launch of the M1 Macs late last year. Unfortunately, because of its density, it is not exactly a breezy thing to write about.

Rich Mogull, TidBits:

As wonderful as the Apple Platform Security guide is as a resource, writing about it is about as easy as writing a hot take on the latest updates to the dictionary. Sure, the guide has numerous updates and lots of new content, but the real story isn’t in the details, but in the larger directions of Apple’s security program, how it impacts Apple’s customers, and what it means to the technology industry at large.

From that broader perspective, the writing is on the wall. The future of cybersecurity is vertical integration. By vertical integration, I mean the combination of hardware, software, and cloud-based services to build a comprehensive ecosystem. Vertical integration for increased security isn’t merely a trend at Apple, it’s one we see in wide swaths of the industry, including such key players as Amazon Web Services. When security really matters, it’s hard to compete if you don’t have complete control of the stack: hardware, software, and services.

Vertical integration in the name of privacy and security is the purest expression of the Cook doctrine that I can think of. We got a little preview of the acceleration of this strategy not too long ago — and a glimpse of its limitations in November — but it has been a tentpole of Apple’s security strategy for ages. Recall the way Touch ID was pitched when the iPhone 5S was introduced, for example. Phil Schiller repeatedly pointed to its deep software integration while Dan Riccio, in a promotional video, explained how the fingerprints were stored in the Secure Enclave.

All of this makes me wonder whatever happened to Project McQueen, Apple’s effort to eliminate its reliance on third-party data centres for iCloud. Surely this project did not die when some of the engineers responsible for it left the company, but Apple still depends on others for hosting. From page 109 of the guide:

Each file is broken into chunks and encrypted by iCloud using AES128 and a key derived from each chunk’s contents, with the keys using SHA256. The keys and the file’s metadata are stored by Apple in the user’s iCloud account. The encrypted chunks of the file are stored, without any user-identifying information or the keys, using both Apple and third- party storage services — such as Amazon Web Services or Google Cloud Platform — but these partners don’t have the keys to decrypt the user’s data stored on their servers.

Even though Amazon and Google absolutely cannot — and, even if these files were not strongly encrypted, would not — access users’ data, it is still strange that Apple still relies on third-party data centres given its tight proprietary integration.

I’ve been picking through this guide for the past week and trying to understand it as best I can. It is, as an Apple spokesperson explained to Jai Vijayan at Dark Reading, intended to be more reflective of security researchers’ wishes and needs, which you can read as being more comprehensive with a greater level of technical detail. One item I noticed on pages 14–15 is the new counter lockbox feature in recent devices:

Devices first released in Fall 2020 or later are equipped with a 2nd-generation Secure Storage Component. The 2nd-generation Secure Storage Component adds counter lockboxes. Each counter lockbox stores a 128-bit salt, a 128-bit passcode verifier, an 8-bit counter, and an 8-bit maximum attempt value. Access to the counter lockboxes is through an encrypted and authenticated protocol.

Counter lockboxes hold the entropy needed to unlock passcode-protected user data. To access the user data, the paired Secure Enclave must derive the correct passcode entropy value from the user’s passcode and the Secure Enclave’s UID. The user’s passcode can’t be learned using unlock attempts sent from a source other than the paired Secure Enclave. If the passcode attempt limit is exceeded (for example, 10 attempts on iPhone), the passcode-protected data is erased completely by the Secure Storage Component.

I read this as a countermeasure against devices, such as the GrayKey, that try to crack iPhones by guessing their passcodes using some vulnerability that gives them infinite attempts. I cannot find any record of a GrayKey successfully being used against an iPhone 12 model, but I did find an article highlighting a recent funding round for the company.

Thomas Brewster, Forbes:

But not all are convinced by Grayshift’s long-term capabilities, given Apple’s consistent improvement of the iPhone’s security. The GrayKey is believed to be capable of hacking iPhones up to the iPhone 11, though it’s unclear how effective the tool is against the iPhone 12. “It’s most likely they can’t do much, if anything at all, with the iPhone 12 and iOS 14,” said Vladimir Katalov, CEO of another forensics company, Elcomsoft. “Perhaps they just want to cash out.”

Katalov previously speculated that iOS 12 defeated the GrayKey but, clearly, some new method was developed to keep it working — at least, until recently. A new method may be discovered again. But it seems that Apple is particularly keen to address concerns about passcode vulnerabilities exploited by third parties. It is too bad that iCloud backups remain a critically weak point.