[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.