Which keys are transferred to Apple during an iCloud backup?

Question

The iOS data protection implementation and the implementation of iTunes backups are both reasonably well documented, on a high level by by Apple, and on a much more detailed level by third parties.

However, I'm wondering about the implementation details of iCloud backups. Apple's document only mentions the matter very briefly in a paragraph on the iCloud backup keybag.

According to that information, and unlike for a local iTunes backup, the data is read from the device still encrypted (except for files with the protection class NSFileProtectionNone, for which the class key is readily available at all times). On the other hand, Apple is clearly able to decrypt an iCloud backup even without the user providing the original Apple ID credentials or the phone with which it has been originally created, thereby passing (or failing?) the mud puddle test.

This seems to imply that at some point in the backup process, the actual class keys are transmitted to Apple (otherwise, there is no way for an iCloud backup to work while the device is locked - some files are protected with a class key that is only available as long as the screen is unlocked). (For local backups, the files are decrypted on the device, using the keys contained in the escrow keybag, thereby not exposing any long-term keys to the computer performing the backup.)

While it is already known that Apple has full access to iCloud backups stored on their servers, this would imply that by enabling iCloud backup even a single time, some encryption keys that otherwise would never leave an iOS device are transmitted and stored to iCloud.

I'm wondering what an adversary would be able to do once they gain access to an iCloud backup, using some third-party software to download everything to a computer:

It would seem like they are not only able to examine the contents of the backup itself, but also gain enough information to decrypt everything in the device's NAND, if they were able to physically acquire it (in addition to the Apple ID credentials), since the class keys are contained in the downloaded backup file.

Can anybody share some knowledge on how the iCloud backup process actually works, and if the scenario above is plausible?

Answer 1

There is a newer security guide published by Apple than the one you referenced that contains a list of non-migratory keys, keychain items for which the class is protected. The word Privacy occurs in the 2012 guide once. Twenty-one other references were added in the 2016. Inquiries of this nature are common, especially when iOS users hold medical, financial, intellectual property, and other confidential information.

As you deduced, it is not possible to deserialize the keychain AND provide privacy from internal Apple attackers unless a secret is held on the client and used to encrypt data prior to entering the backup process. There is no mention of any mechanism that allows the iOS user to install a certificate or set a backup password that Apple cannot access.

If you wish to have highly secure privacy, you need client side encryption at the user interface level. It is not clear whether an app could reach the App Store with such a privacy device. Such code would probably be considered a potential source of malware or viruses by Apple. (See the Commitment to Security section of the new guide.)

Although various comments can be found on your topic, none are from within the Apple development or security teams, as server-side information is surely considered Apple company confidential. The API for client-side apps is black-box, core services transparency is low, and the Core Backup API is not granular enough to provide hints.

You can read more about the class NSFileProtectionNone and related classes in the API documentation, but no sequence diagram or description is provided. I was unable to find a sequence or action diagram with any detail to it. We only know that the transfer is via TLS.

A packet sniffer would produce details, but the second paragraph above would hold regardless of operational details.

---