Digital forensics firm Elcomsoft revealed this week that, reducing security to improve the overall user experience.
Elcomsoft’s discovery kicked off a vigorous debate on Hacker News and Twitter, but does this change represent a real risk to the average Apple user? The answer is yes, but that answer has to be understood in the proper context. In absolute terms, Apple’s change is a step backward for iOS security, but the nuances of real-world usage suggest that Apple believes it’s a net improvement for protecting user data from loss.
While I wish that Apple hadn’t made this change, and I do consider it a hit to my personal security, I can see where Apple is coming from and how the company may see it as enhancing the safety of user data. Let me explain.
The Difference between iCloud and iTunes Backups -- By default, iOS devices try to back up to iCloud. Apple encrypts those backups in storage, but they aren’t protected with a separate user-defined password or encryption key. That’s why Apple can access customer data if required by law enforcement; Apple controls the encryption key and can recover the data without the customer’s knowledge or permission.
Before you call this a massive security flaw, keep in mind that my sources tell me that Apple has seriously looked at encrypting these backups with customer-managed encryption. However, allowing users to control encryption keys creates a massive usability problem. If someone were to lose their device and couldn’t remember their iCloud credentials, which happens all the time, they would lose access to all their data forever. Yes, it’s possible to regain access if you have more than one device, but many millions of Apple’s customers own just a single iPhone.
I would love to see Apple make customer-managed encryption for iCloud backups an option, but I see no viable path for it to become the default. Too many users lose access to their iCloud accounts — and thus to irretrievable family photos — for Apple to implement something that would unilaterally prevent data recovery. And too few journalists and security professionals either understand or want to admit the complexity of Apple’s situation, which leads to oversimplified suggestions that “Apple could just…”
Apple does try to minimize customer risk by limiting what is backed up. Most notably, your keychain passwords are not backed up to iCloud unless you separately enable iCloud Keychain, which has a different passcode that follows an entirely different security and restore mechanism. Apps can also control what data goes into an iCloud backup, ensuring that really sensitive information isn’t exposed.
Encrypted iTunes backups are a completely different beast. Rely on iTunes for backing up your iOS device and effectively all your data, including your entire keychain, is backed up locally (although I believe app programmers can still block the transfer of some keychain items in their code). The security assumption is these local backups are protected by a separate password and strong encryption, Apple never sees them, and no one but the device owner can access them. I’ve glossed over a few details, but that’s essentially how encrypted iTunes backups work.
That’s why, when you upgrade to a new iPhone or iPad, you should always restore from an encrypted iTunes backup or an iCloud backup that has iCloud Keychain enabled. You won’t have to log back into everything as most of your keychain items will be restored, plus a lot of other ephemeral data.
How Encrypted iTunes Backups Changed -- In iOS 8, 9, and 10, if you made an encrypted iTunes backup to your local machine, the password protecting the backup was owned by the iOS device. Although you set the password on your computer, the device itself would then protect all future backups to any computer using that password. The host computer itself wouldn’t have access to the backup password, although you could store it in the keychain.
In other words, when you make an encrypted iTunes backup, your iOS device does the encryption, not your computer. This approach materially improved the security of iOS backups, since the computer itself couldn’t access the data without the encryption key. It also prevented someone who had gained physical possession of the device from performing an encrypted backup with a new password and then using that to unlock and snoop the data.
This backup password was different from your computer’s login password or device’s passcode. If you lost your backup password, you could never restore from those backups ever again, as you would want to do when buying a new iPhone. Since there was no way to set a new backup password without knowing the old password, no one, including Apple, could help you. Worse, according to Elcomsoft, you could never again make another encrypted backup that you could restore in the future without factory-resetting your device.
(Conceivably, if you still controlled the device, you could switch to iCloud backups, reset the device, and restore from iCloud to reset the iTunes backup password, although I haven’t tested that.)
This previous iTunes approach was secure, but not very user-friendly; just the opposite of how iCloud backups are user-friendly, but not as secure as they could be.
Here’s what’s new and controversial. In iOS 11, Apple lets you reset the encrypted local backup password if you know the device’s login passcode.
Using the device passcode as a second password reduces security because if an attacker can get the passcode, they can then reset the encrypted backup password and perform arbitrary backups with a weak passcode that tools from companies like Elcomsoft can crack.
“So what?” you say. “The attacker has the iPhone and the passcode anyway.” True, but iOS devices employ a fair number of protections even if you have local access. Tools that can read full device backups can access much more information. For example, they can pull passwords out of your keychain that are not accessible when using iOS. Your iPhone may use your email password to log into your email account, but it never displays that password. By hacking into a backup, an attacker can read it and log into your account or change your password and lock you out. And that’s just the tip of the iceberg — all other passwords stored in the keychain would be accessible as well.
Before this change, there was no way an attacker could hack into your iTunes backups without the backup password. Now, if the attacker can get your passcode, everything in the iPhone is fair game.
Risks Have Nuance -- I’m a bit surprised Elcomsoft publicized this change in iOS 11 because it’s a boon to forensics firms. Elcomsoft often hypes up their ability to access iOS devices, but when you read between the lines, you see that their access pretty much always depends on having a passphrase or some other circumvention first. Security firms often use these kinds of discoveries as a marketing tool, so you should always take them with a grain of salt.
Let’s take a step back and look at this change within the context of the Apple ecosystem.
There are over a billion iOS devices out there, with many hundreds of millions of users. In recent years, Apple has had an exceptional track record on security and privacy in the iOS world. Elcomsoft hints they believe Apple made this change at the behest of law enforcement, but doing so would be antithetical to Apple’s current culture. Apple is the company that faced down the FBI.
Here’s how I see it. What percentage of iOS users use encrypted iTunes backups? What percentage of those people lose their backup password and then have to reset their device — possibly with a complete loss of data — if they ever want to make or restore from an encrypted backup again?
On the other side of the equation, what percentage of users with encrypted backups lose their device (even temporarily) and the passcode, thus allowing an attacker to change the encrypted backup password, perform a backup, and crawl through their data?
Only Apple, via support requests, knows those numbers, and thus we have to assume that Apple believes that fewer people will suffer from inherently reduced security than will benefit from a second chance at recovering data from a backup.
There is no question that allowing the iOS device passcode to act as a secondary backup password reduces the security of encrypted iTunes backups on an individual level. As a professional paranoid I really wish Apple hadn’t made this change.
But there is also a legitimate case to be made that Apple improved the overall iOS experience for a much larger percentage of its customer base by making it less likely that average users could lose access to their encrypted iTunes backups entirely.
As an Apple customer who once had to factory-reset one of my children’s iPads because I had forgotten the backup password, hadn’t backed up to iCloud to save space, and couldn’t recover it from the Mac keychain where I… had failed to store it, I can certainly see Apple’s point of view.