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?