Apple Is Trying to Make iMessages More Private

Of course the good part about a crowd is all views come out and so th closed source thing has its place but we should atleast give them their due and some kudos. We know people will try to evaluate the implementation and see what happens. In this case it's just a PR article. Let's wait for them to release detail and see if it stands out. May be the protocol is enough to give us confidence that their claim is true. We don't know yet.

TL;DR: Keychain recovery relies on a cluster of hardware security modules to enforce the recovery policy. After 10 tries to guess your PIN, the HSM will destroy the keys. Apple support gates all but the first few of these tries. The paper also implies that you can use a high entropy recovery secret as an alternative, though I can't figure out how you would enable that.

This seems like a pretty reasonable point in design space to me. Of course, you are relying on Apple's trustworthiness and competence to implement this design. But that is true without recovery, since the client software is also implemented by Apple.

For secure, private messages, your sane current options are Signal, WhatsApp, and Wire. Signal is the best option, but you're going to make some UX sacrifices for security. WhatsApp and Wire are extremely comparable. If you worry about implementation or operational security flaws, WhatsApp has the Facebook security team behind it, and a long-term relationship with OWS; no cryptographically secure messenger is better staffed. If you're worried about Facebook seeing your metadata, which is a sane worry, Wire is approximately as slick and usable as WhatsApp with mostly the same underpinnings.

Regardless of the underlying cryptography, in the absence of a well-reviewed published crypto messaging protocol, iMessage is basically just an optimization over SMS/MMS. It's great for that, but it shouldn't be anyone's primary messenger.

If they don't, I don't think it is that hard for Apple to extend their current security model to iCloud. They currently rely on senders encrypting messages with each destination device's public key, so they can store the individually encrypted messages separately in iCloud.

When a new device arrives, they could have an existing device perform re-encryption of the messages for it (after the user authorizes that the device should be added).

Even without the new iCloud functionality, Apple has always been in control over the key exchange, which would allow a malicious employee / government to write code that could add a new authorized device/key silently and thus allow Apple to eavesdrop from that point on in future conversations.

If Apple has changed backups to function in a more private manner, then they would announce that, not something exclusive to iMessage.

More detail: iMessage syncing has always been maximally private from day one. However a drawback to the current implementation is that new devices cannot sync message history. The reason is that each message is encrypted separately by senders for each currently registered device for the receiver. And yes that means if you have 3 devices on your iCloud account, whenever someone sends you an iMessage, 3 separately encrypted copies get sent. Apple has gone to great lengths to ensure that private keys are never shared by devices.

So what's new is apparently Apple's figured out a way to sync history via iCloud. I'm interested to hear the implementation details, but there can be no doubt that it still respects the design goal of never sharing private keys.

Now, the privacy goals for backups are different. You obviously want them to be as private as possible, but most people generally want to be able to recover their life in the event of a simple forgotten password. There are certainly scenarios where you want to encrypt your backups, but it always should be an informed, opt-in choice. You should clearly be aware that if you forget your password, you lose your backups. So generally it's desirable to default to having a fallback recovery method.

Like I said earlier, if Apple has figured out a fallback recovery method that somehow does not involve storing your data in a manner they can decrypt, that would be something they announce as part of iCloud Backup... not just for iMessage. But it seems almost a fundamental design constraint. You can either have something impossible for anyone else to decrypt or conveniently recoverable backups, not both.

I would recommend having an option to generate keys based on something you have and something you know that you won't easily forget, such as a passphrase. That way you can always recover them later!

Good or bad idea?

color me skeptical.

> "Our security and encryption team has been doing work over a number of years now to be able to synchronize information across your, what we call your circle of devices—all those devices that are associated with the common account—in a way that they each generate and share keys with each other that Apple does not have."

> It's unclear exactly how Apple is able to pull this off, as there's no explanation of how this works other than from those words by Federighi. The company didn't respond to a request for comment asking for clarifications. It's possible that we won't know the exact technical details until iOS 11 officially comes out later this year.

> Meanwhile, cryptographers are already scratching their heads and holding their breath.

This might be uncharitable, but in my mind I think this writing and presentation of facts (probably unintentionally) implies that this capability is novel, when it's not. Sharing keys between multiple devices is a straightforward issue if you're willing to make user experience trade offs. Cryptographers are not scratching their heads wondering how Apple could achieve E2EE with a network of devices, they're wondering how they did it without sacrificing account recovery. It's not clear to me that readers would automatically understand this, because the real head scratcher isn't addressed until near the end of the article, which brings me to my next point:

> "The $6 million question: how do users recover from a forgotten iCloud password? If the answer is they can't, that's a major [user experience] tradeoff for security. If you can, maybe via email, then it's [end-to-end] with Apple managed (derived) keys," Kenn White, a security and cryptography researcher, told Motherboard in an online chat. "If recovery from a forgotten iCloud password is possible without access* to keys on a device's Secure Enclave, it's not truly e2e. It's encrypted, but decryptable by parties other than the two people communicating. In that sense, it's closer to the default security model of Telegram than that of Signal."*

I'm hesitant on how much faith to put in Apple's scheme here. On the one hand I generally trust Apple very highly when it comes to security and cryptography in particular. On the other hand I don't see them making account recovery impossible.

However, over the past few years they have been increasingly pushing two-factor verification, and then full two-factor authentication based on a network of trusted devices. The iCloud password used to be enough to manage the account's security and trust, but now it frequently defaults to requiring authenticated approval from a trusted device (instead of e.g. security question responses).

I could see Apple abandoning conventional account recovery if they keep proceeding down this path by providing a huge amount of access redundancy. For example, they could keep redundant copies of all user data synced in iCloud which are respectively end-to-end encrypted on the client with a user's backup keys. Each authenticated user device might have 10 backup keys, with a typical warning that they should be written down and will not be displayed again, etc. The keys could be downloaded from the device and stored by the user but never given to Apple, and would primarily be useful in circumstances where a user only has one trusted device authenticated to iCloud. Then if a user loses primary access to any given Apple device, the user has two ways to recover data:

1) Authenticated approval from another of the user's trusted devices, or

2) Use the backup keys, which do not provide a method of changing the account password, but which instead decrypt the redundant user data corresponding to the key.

The basic idea is that removing conventional password-based account recovery required inordinate redundancy to counter usability loss; you can do this with redundant authenticated devices (each with their own keys), or you can simulate it on one device with redundant keys that are ideally harder to lose.

> It's unclear exactly how Apple is able to pull this off, as there's no explanation of how this works other than from those words by Federighi.

All Apple says is "end to end encryption". From your phone to the cloud is 2 ends, and then from the cloud to the FBI is 2 more. Yay!

Each user

1. encrypts her data at the source i.e. on her own computer and

2. sends the encrypted blob over the untrusted network, or so-called "dumb pipes".

Hardware company that makes the users computer tries to dictate whether and how #1 can be done.

Not necessary.

The software for doing #1 does need to be open source.

On mobile, does such software even exist?

And even if it does, is a mobile phone really the users computer? It is an effectively locked enclosure with several computers controlled by third parties.

The way to do secure mobile messaging would be to encrypt the message on a computer the user controls, then move the message to the "mobile phone" and then send to the untrusted network.

Alternatively, do not use a mobile phone for messaging if worried about others have access to the messages. Wait for a pocket sized portable computer that can be tinkered with. No baseband, etc.