Reportedly, Apple dropped plan for encrypting backups after FBI complained. Apple’s decision will undoubtedly cause turmoil and will have a number of consequences. In this article, I want to talk about the technical reasons for encrypting or not encrypting cloud backup, and compare Apple’s approach with the data encryption strategies used by Google, who have been encrypting Android backups for several years.

iCloud encryption

Apple encrypts everything stored in iCloud down to the last bit. All information that the user or their iPhone store in iCloud is securely encrypted in transit and in storage. On a physical layer, the data is cut into multiple small chunks. The chunks are distributed (randomly or redundantly) across various servers that belong to companies such as Amazon, Microsoft, AT&T, or controlled by the Chinese government if the user resides in Mainland China. Neither of these companies (nor the Chinese government) have access to the actual data since it is fully encrypted. The encryption keys are stored on Apple’s own servers in Cupertino. Without these encryption keys, no one can decrypt anything.

The thing is, the encryption keys are readily accessible if one has access to the user’s Apple ID account (as in knowing the login and password and being able to pass two-factor authentication). If a third party gains control over the user’s Apple ID/iCloud account, they can download and decrypt information.

More importantly, governments and the law enforcement can request information from Apple. Since Apple has full control over the encryption keys, the company will serve government requests by providing a copy of the user’s iCloud data along with the encryption keys. This is the status quo, and this is exactly what the FBI wants to protect.

This is how Apple encrypts your iCloud photo library. This is also the way your iCloud backups are currently protected, and it is not this type of encryption that Apple is about to scrap.

End to end encryption

There is another layer of encryption Apple uses to protect some of the information is considers the most sensitive. The company employs a protection method it calls “end-to-end encryption”. End-to-end encryption additionally encrypts certain types of data with a password only known to the end user. Without that password, no one, not even Apple, can decrypt the data.

What kind of a password? It’s the user’s screen lock passcode, the PIN code you type to unlock your iPhone or iPad, or the system password you use to sign in to your macOS computer. Technically speaking, a typical iPhone passcode consists of only 6 digits. If Apple wanted, it could brute-force “end-to-end encryption” in a matter of minutes (if not seconds). However, the company officially refuses to do so.

It is important to note that, while governments and the law enforcement can still request information that is end-to-end encrypted from Apple, they will get nothing but random-looking encrypted data in return. With Apple refusing to break the encryption and not supplying the governments with the right tools, certain types of data remain out of the reach of the law enforcement – unless they know the user’s screen lock passcode and use Elcomsoft Phone Breaker, that is. Nevertheless, end-to-end encryption adds an obstacle to the general procedure of government requests.

What kinds of data are currently protected with end-to-end encryption? Most importantly, the iCloud Keychain containing all of the user’s stored passwords to various Web sites, apps, social networks, accounts and instant messengers.

End-to-end encryption also protects Messages (SMS and iMessage), Health data, Screen Time, Home data, Voice memos, Apple Maps (searches, routes, frequent locations) and, since iOS 14, Safari browsing history.

What Apple had planned to do

Without a source in the company, we can only speculate on what exactly Apple planned to do for encrypting iCloud backups. Our educated guess is that the company was planning to use the already familiar end-to-end encryption scheme, additionally encrypting iCloud backups with a key derived from the user’s screen lock passcode.

This wouldn’t change much for the end user. When restoring from a cloud backup, they would only need to type in their old screen lock passcode (not even that if they reused their old passcode on their new device). Since Apple made passcodes nearly impossible to forget (users have to unlock their devices with a passcode to reenable Touch ID/Face ID every 72 hours at least), the fear of more users being “locked out” of their data is unsubstantiated except for a few marginal cases.

The use of end-to-end encryption would make it more difficult for the governments and the law enforcement to request data. Currently, Apple does not provide end-to-end encrypted data when serving government requests. Adding iCloud backups to the list of unavailable data sources was probably the last straw that made the FBI complain.

What about Google?

Since the release of Android 9 in August 2018, Google has been encrypting cloud backups produced by Android phones running Android 9 or newer. The backups are encrypted with a key derived from the user’s screen lock passcode, and nobody complained. Why the FBI does not seem to care about Android backups, and puts that much stress on to Apple? The content is the answer.

Android backups only contain marginal amount of information. According to Google’s Data backup overview, “Backup data is stored in Android Backup Service and limited to 5MB per app. Google treats this data as personal information in accordance with Google’s Privacy Policy. Backup data is stored in the user’s Google Drive limited to 25MB per app.” It is only the 5MB part that is encrypted with the user’s screen lock passcode. The other 25MB of data the apps are allowed to store in the user’s Google Drive are not encrypted with the user’s passcode (storage encryption still applies), and will be passed on when serving government requests.

What about “sensitive” data such as passwords, health, or location history? While Google collects massive amounts of data (significantly more than Apple), that data is protected… not. Governments and the law enforcement can request and receive the user’s passwords, location data, health information (Google Fit), browsing history and the history of search requests on a whim. The small and unimportant Android backup can be encrypted all Google wants.

In contrast, Apple devices produce large, comprehensive cloud backups that can be used to fully restore a new device. iCloud backups can be multiple gigabytes in size, and contain just about everything.

Conclusion

We regret Apple’s decision to scrap end-to-end encryption of iCloud backups, even if the new feature would make us spend countless hours circumventing the encryption.