[tzs]

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?

[giovannibajo1]

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.

[gilgoomesh]

> iCloud backups are not encrypted

This is wrong. iCloud uses AES 128 and 256 encryption:

http://support.apple.com/kb/HT4865?viewlocale=en_US&locale=e...

[kentonv]

This doesn't really say much unless we also know how the AES key itself is derived.

If you don't have two-step authentication on, then Apple's password reset is based on asking some security questions and sending an e-mail challenge. Even if they actually derived the key from your security question answers (unlikely), that's the kind of thing law enforcement would have no trouble cracking. More likely, the whole authentication system simply returns true or false, and the key is stored in some separate place -- perhaps more secure than a random hard drive in the datacenter, but still somewhere where Apple can get it if forced.

If you do have two-step authentication enabled, Apple's docs imply that it is impossible to recover your account without at least two of:

* Your password.

* Your "recovery key" -- a secret that they give you and instruct you to print out and keep somewhere.

* Your phone (or some other device that can generate one-time codes).

They say that if you can't produce two of these then all your data is lost and you'll need to create a new Apple ID. This implies that they might indeed store your data encrypted by an AES key which is in turn stored encrypted in two different ways: once with your password, and once with your recovery key. Thus it would actually be impossible to recover your data without one of these, and Apple doesn't store either one on their servers, therefore Apple would not be able to produce your data for law enforcement.

That said, I would be very surprised (and impressed) if Apple actually does this. Consider that this would prevent their services from doing any offline processing of your data at all -- a compromise few product designers would be willing to make for a security guarantee that almost no user actually understands. More likely, the language in the documentation is a matter of policy -- Apple refuses to recover your account simply because that's the only way to guarantee that social engineering is impossible, not because they are technically incapable.

And anyway, even if your data is stored encrypted at rest with a key that is actually derived from your password, there's nothing stopping law enforcement from demanding that Apple intercept your password (or the key itself) next time you log in. That's basically what they did with Lavabit, after all.

(Things I think about while working on sandstorm.io...)

[dmishe]

But Apple says "iCloud secures the content [backups] by encrypting it when sent over the Internet, storing it in an encrypted format, and using secure tokens for authentication"

[foobarqux]

That would be better and it would prevent certain types of attacks. But at the end of the day you cannot verify what software is running on the phone so circumventing encryption for targeted individuals remains trivial.

[giovannibajo1]

Agreed, but that's true of any system where you regularly install updates without checking and compiling them one by one, and that cover most computers nowadays.

Let's say I have infinite resources and I want to target your Debian server; it's sufficient to bribe one Debian maintainer of a default package and you're basically doomed. Until they don't get to the point of reproducible builds and don't embed something in apt to make sure the build is correct, you still need to trust the whole Debian community.

Any time you run an operating system released by a vendor, you're basically trusting the vendor. It doesn't strictly have to be like that for FLOSS systems, but it is like that right now.

So your comment is indeed correct, but doesn't specifically highlight a defect in iOS.