Recovery Key storage transition hightlights Apple’s privacy and obscurity

We trust Apple with a lot of our data. In general, that hasn’t seemed like a bad idea; in particular, compared to its competitors, Apple seems to ensure that it can inspect or interact with very little of our data. The company has built its platform and its reputation on being an elegant, frictionless, hands-off conduit. While we can make many complaints about Liquid Glass, its increased focus on invasive (and poor) advertising, its software quality, and much else, Apple has kept its corporate nose cleaner than anybody else. Its transparency and documentation are, oddly, worse than its actions and clear intent. The Apple Watch is the only wearable with end-to-end encryption for first-party health data. (Image: Apple) I was thinking about this when I received an email from an anonymized iCloud Hide My Email account, asking for more detail about how Apple managed the transition from the old method of presenting or escrowing (in iCloud) your macOS FileVault Recovery Key to the new method, in which the key is stored in Passwords. This transition, which I’ve documented in a few places, was a step forward in privacy and security. But not transparency! I’ll explain, but you can’t find an explanation on Apple’s site about the transition. The support documentation remains out of sync with Tahoe. That leaves it to yours truly to explicate. Don’t trust and verify The Electronic Frontier Foundation recently published a newsletter with a round-up of how fitness wearables, like rings, watches, and bands, preserve your privacy from government intrusion, as well as whether they protect you from unwanted security invasions by using end-to-end encryption (E2EE). (The former often requires the latter: governments typically can’t break through E2EE.) I want to quote two full paragraphs to make this point: In the end, we found that only four of these companies (Apple, Google, Whoop, and Oura) promise to notify users of law enforcement requests in publicly available documentation. And just two of those companies, Apple and Google (which also owns Fitbit), currently publish transparency reports on how often they hand users’ data to the government. Support for end-to-end encryption—a method that ensures your personal data is only accessible by you, and not the company who makes the device and manages the cloud storage—is more rare than transparency reports among wearable device makers. The Apple Watch is the only popular fitness wearable that supports end-to-end encryption.1 Apple wasn’t an early player with E2EE. Really, it was seen as the kind of thing only true security geeks cared about, even while people like EFF and other digital privacy advocacy groups and individuals warned us that our data was only lightly protected. Over time, as the criminal, exploitative, and political monitoring and extraction of our secrets became clear, Apple kept stepping up. I don’t understand every part of this flowchart, but it shows how Apple uses the Secure Enclave to ensure the integrity of device-based end-to-end encryption. (Image: Apple) The Secure Enclave is a keystone of those moves, as the tamper-resistant silicon subsystem allows devices to keep locally generated security keys entirely private. Most of these keys never leave the Secure Enclave! Rather, it’s the encryption hub.2 iCloud initially had a fairly cursory level of protection, with the then-Apple ID account password serving as the only real bar. Two-step verification in March 2013 provided better account protection, but didn’t cover iCloud backups, which could be retrieved without that second step. A rash of celebrity account leaks in late summer 2014 led Apple to extend two-step to iCloud data within a couple of weeks. The next year, it upgraded security to the more rigorous two-factor authentication, which later became mandatory. As part of its response to the iCloud data hijacks, Apple began to beef up iCloud. It began rolling out E2EE for all the device-based services it could, leaving synced data still relatively lightly protected. (iCloud data is always encrypted with Apple’s at-rest keys, which only it ostensibly has access to, and in transit with HTTPS. However, a security breach at Apple or someone able to hijack one end of an in-progress HTTPS sync allows access to that unencrypted data.) Then, suddenly, months after shipping major updates to its operating systems, Apple announced Advanced Data Protection in December 2022. Enabling this feature put the E2EE aegis over nearly all synced or stored data at iCloud; mail, contacts, and calendar entries remain an exception because of their interoperability with third-party apps and services. You can view Apple’s document that explains what level of protection applies to data, with and without ADP enabled. With that in mind, let’s talk about the Recovery Key transition. Recovery Key is not recovered? I think not The particular reader question driving this was their concern about the FileVault Recovery Key that was in place when the Tahoe-driven transition occurred. Was the old key destroyed and a new one created and stashed in Passwords? Or was the old one just moved over? If the latter, isn’t that a security hole, if a tiny one? My initial reply wasn’t entirely glib, but I said, having not documented the upgrade, I believed Apple explained the process when it occurred. But I couldn’t find any screen captures of how that occurred. Apple’s documentation remains in the past—it doesn’t mention the Passwords method at all. The Passwords User Guide perversely mentions the Recovery Key, but not how to interact with turning it off or on. People who had FileVault disabled (whether they never turned it on, or turned it off at some point) did receive an alert during the upgrade: Your Mac is Ready for FileVault: FileVault keeps your Mac safe by encrypting your data and protecting it with the password you use to log in. If you forget your password, you can use your Recovery Key to reset it. Clicking Not Now bypassed the process; Turn On opted the user into the new Passwords-based storage for the Recovery Key. I’ve explained in previous columns how FileVault provides an extra layer of protection. FileVault requires a Recovery Key, so you have recourse if your password stops working, you forget it, or corruption happens in the boot data. This shouldn’t happen, but it can. The Recovery Key and your password (transformed by a cryptographic formula—or hash—after you enter it) are both “key encryption keys,” delightfully named KEKs. Neither directly encrypts your data. Each instead unwraps the key that the Secure Enclave uses to unlock your drive for use in macOS.3 (You can find out a lot more about this topic in my Take Control of Securing Your Apple Devices, a revised version of which, including “27” betas, will be out shortly as a free update.) The Recovery Key entry in Passwords identifies the Mac by its model, and provides a shortcut to FileVault settings. Apple never knows your macOS passwords, and it shouldn’t know your Recovery Key. That was the flaw with iCloud escrow: your Recovery Key could be retrieved by someone with your Apple Account information who had access to your Mac. With that said, how did Apple manage the transition from the old system to the new one that uses Passwords? Into this lacuna of details, jump I with inferential logic about what Apple must have done. With a “show me once” Recovery Key: Apple would generate this key, show it to you, then destroy it. The company (and macOS) didn’t need a record of it, because its purpose was to be used to decrypt another key: don’t have the key, can’t decrypt that other key. If you opted for that method, Apple had to destroy the existing KEK to replace it with a new one derived from the newly created Recovery Key. With an iCloud escrow key: The same scenario applies from a different angle. Apple can’t retrieve your escrowed key unless you use your Apple Account. That isn’t a per se security weakness, but Apple doesn’t need that escrowed key, and it doesn’t want to decrypt it at iCloud to send it to you. I would warrant that the company once again destroys the KEK, creates a new one, and that’s what’s stored in Passwords. Anything else leaves a potential gap in my explanation of why Apple made this change in the first place. Now, you say, if macOS generated the key and it stored it in Passwords, doesn’t it “know” the key? Not exactly. The key is ostensibly generated in memory, added to Passwords, and destroyed. To have accessed the key, an attacker would need to be monitoring your screen or grab particular memory locations at an exact moment. If someone has undetected remote observation of your Mac display, the game is already over. Passwords uses end-to-end encryption with device-based secrets. You can enter a device password or use biometrics to unlock Passwords (or chained biometrics with an Apple Watch linked to your Mac). That’s as secure as we can get to protect any password. If someone wanted to access your Recovery Key through Passwords, they need access to one of your devices; cracking your Apple Account and its second-factor or passkey authentication wouldn’t help—and that’s a big stretch to begin with. Nor does just having your macOS account name and password without the ability to have physical or remote screen access to your device. I believe Apple handled this transition awkwardly. The company could have provided more clarity about the requirement to change how a FileVault Recovery Key was stored, and explain exactly what measures it took to ensure security across that transition. And it could update its support pages! [Got a question for the column? You can email glenn@sixcolors.com or use /glenn in our subscriber-only Discord community.] [Glenn Fleishman is a printing and comics historian, Jeopardy champion, and serial Kickstarterer. His current books in preparation, which you can pre-order, are Flong Time, No See, and That One Matt Bors Comic. Other books include Six Centuries of Type & Printing and How Comics Are Made.] If you appreciate articles like this one, support us by becoming a Six Colors subscriber. Subscribers get access to an exclusive podcast, members-only stories, and a special community.