[sneak]

It's also insecure. The sync keys for iMessage are backed up in the non-e2ee iCloud Backup, which means that iCloud serves as a key escrow for iMessage's e2ee, rendering it useless (as Apple, which is definitively not an endpoint, has a private key of the participant and can read all the messages in real-time).

iMessage should be assiduously avoided.

[jxcl]

This is less true now, with the option to enable “advanced data protection”. Turning this setting on disables Apple’s access to your iMessage keys along with a bunch of other stuff, though of course if you get locked out, Apple can’t help you

[rodgerd]

Yeah, and this is the sort of thing that I think drives Apple's care in recommending the most secure modes; they don't want people causally turning it on and discovered that they've buggered themselves up.

[glompers]

I agree with you; Amazon servers receiving 80,000 or 800,000 requests per second or 8,000,000 is all a different ballgame than it is for 800 individual actual families around the world (or 8,000 or 80,000) to get their telephones totally buggered up before work that morning on any given workday -- just because somebody trustworthy has advised them to play it super safe without making equally sure the listeners were understanding the UX difficulties of recovering their smartphone's functionality in certain mundane use cases, etc, which would ensue. That's a lot of panic to deal with. Apple user help forum volunteers would be helpless to reach all the affected frustrated people.

[highwaylights]

I don’t believe this is true. You can change your iCloud password at any time, which means they definitely are not encrypting your iCloud data based on that key or a derivative. If I had to guess, they generate a key and encrypt that key with your password so it can be changed but they also aren’t able to produce it on request.

The drawback here is that the encryption key for your data never changes, even if you change your password (the private key is just re-encrypted with the new password).

If they’ve implemented it well then this is mostly academic but it does mean they must be escrowing encrypted keys for every account, and those with ADP enabled are just encrypted against their password rather than the Apple key. It also means if they’ve suffered an undetected breach in the past then changing your password doesn’t help protect your data going forward necessarily. That being said, if an attacker had ongoing access to iCloud data then it probably doesn’t matter (although the presumably-more-secure key vault wouldn’t need to be breached again).

I have no insight into Apple’s practices and this is all speculation, this is just the trade-off I would make to keep it usable.

[_cenw]

The keys in advanced protection are derived from your device passcodes, your macOS user password and a recovery key. You'll notice you have to approve from one of your devices to use iCloud web or add a new device.

The deviation function takes a while to run and depends on the secure enclave, but you still probably want to avoid 4-digit passcodes.

[highwaylights]

They are, but they also must be encrypted n separate times where n is the number of signed in devices.

Mac iPad iPhone Recovery Key

Each of the above would have a separate uniquely encrypted device backup key as a result of the derivation function. I can change the password on any of those (or regenerate the recovery key) without a full iCloud re-encryption or duplication of my iCloud data - therefore Apple must be holding a key in escrow that is the actual decryption key. One would assume it's that key that is encrypted against the derivation function, as then it could still be credibly argued as end-to-end, but that's just an assumption I'm making.

[_cenw]

I'm not sure why you're doing all this speculation, when wrapping keys is a pretty standard technique (i.e. LUKS key slots) and Apple provides the details themselves[1]. Yes, they're doing a handshake with secure enclave keys and transfer the master key to your devices. Turning on Advanced Protection will reencrypt all the data in iCloud in the background whereas turning it off will submit the master key to Apple so they can presumably place it on an HSM. Apple already did this before advanced protection with your Keychain.

[1]: https://help.apple.com/pdf/security/en_US/apple-platform-sec...

[sneak]

It's opt-in, so approximately nobody uses it.

Unless BOTH ends of a conversation are using it, it's pointless.

This means that turning it on does nothing in terms of privacy, in practice, today. All of the iMessages you send and receive will be readable using the escrowed keys from the other users you are messaging with.

Perhaps at some point Apple will prompt or nudge people to migrate, but that's unlikely given the risks to data loss for people who forget their credentials (and have "nothing to hide").

[cj]

> if you get locked out, Apple can’t help you

Unfortunately, I can attest to this.

I probably spent 100+ hours doing everything possible to regain access to an iCloud account with advanced data protection.

I lost the password and the recovery key (with no 2nd apple device that was logged in). The only outcome in that scenario is losing your iCloud account completely.

Lesson: enable advanced security, but save your recovery key!

[hackmiester]

You don't have to use iCloud Backup.

[sneak]

It's on by default, which means everyone you iMessage with is escrowing the keys that allow Apple to decrypt all of the messages. Turning it off on only one end of the conversation has no meaningful effect.

[hackmiester]

Fair point.

[Obscurity4340]

Was going to mention. iMessage seems to be that golden key thing the FBeye asked them for back in 2015 in San Bernadino (insofar as iCloud itself isn't a/the key itself, already)