Why can't Apple decrypt your iPhone?

From what I can understand, if you wanted to hypothetically maximize your security, it would mean turning off iPhone backups.

Apple could also have it set that you must have the iPhone passphrase to restore a backup but obviously those can be "easily" brute forced (because for the restore to work, it must mean you can bypass the old device's UID)

But if this is the case, why bother with bullet point 1. to 4. The chip is probably manufactured in China, why spend a thought about whether US law enforcement can somehow via Apple decrypt the data of my phone when the Chinese Government can do it anyways?

In particular Apple provide photo backups and (speculation) may be doing something server side to allow continuity features around text messaging from other devices.

This is getting into speculation about their role in Prism but I'm wondering how the iCloud encryption actually works. They say everything is encrypted while stored [0] but it's not clear (or I haven't found) whether that's using a key derived from the password or something Apple control. Either way I'm not entirely sure there's any way to stop Apple getting it if they're told to given the lack of transparency.

[0] http://support.apple.com/kb/ht4865

If someone obtains your phone, and prevents you from initiating a remote wipe (perhaps they have you in custody, or perhaps they have isolate the phone so that it cannot receive the wipe command), it sounds like this technology will do a good job of preventing them from decrypting your data from the phone if you have a decent passcode. They cannot throw GPUs or FPGAs or clusters or other custom hardware at the problem of brute forcing your passcode because each attempt requires computation done by the Secure Enclave using data only available in the Secure Enclave. That limits them to trying to brute force with no parallelization and 80ms per try [1].

However, assuming they have an appropriate warrant, can't they get your iCloud backups and try to brute force those? Maybe I'm being an idiot and overlooking something obvious, but it seems to me the encryption on the backups CANNOT depend on anything in the Secure Enclave.

That's because one of the use cases that iCloud backup has to support is the "my phone got destroyed, and now I want to restore my data to my new phone" case. To support this, it seems to me that the backup encryption can only depend on my iCloud account name and password. They can throw GPUs and FPGAs and all the rest at brute forcing that.

My conclusion then is that when I get a new iPhone, I should view this as a means of protecting my data on the phone only. It lets me be very secure against an attacker who obtains my phone, but not my backups, provided I have a good passcode, where "good" can be achieved without having to be so long as to be annoying to memorize or type. A passcode equivalent to 32 random bits would take on average over 5 years to brute force.

To protect against someone who can obtain my backups, I need a good password on iCloud, where "good" means something considerably more than equivalent to 32 bits.

[1] I wonder if they could overclock the phone to make this go faster?

Yes, currently iCloud backups are not encrypted so they can be extracted by law enforcement, but on the other hand they are not mandatory, as Apple also offers a full local backup solution through iTunes (albeit, admittedly, they could make it work automatically like Time Machine, instead of manually; I guess they'll get there, now that they're using privacy in marketing).

On the other hand, it is perfectly possible to devise a system to locally encrypt iCloud backups and still be able to restore them. Look at how iCloud keychain works, in the Apple documents, as those datas (= all your passwords and secrets) are synced through the cloud between your devices but Apple can't access them. For iCloud keychain, in case you lost access to all your devices, you need a master recovery key that's generated when you first activate it; if you don't have it, you lose the data.