This post is in response to a recent article covering the implementation of the encryption system used in Apple’s iMessage system.
Disclaimer: This post is only going to cover the purely technical answer to the question of whether Apple could read / intercept iMessages (assuming that the description in the article is accurate). This means the post isn’t about how I don’t like Apple very much (which I grant is true); I think I’ve done a pretty great job recently of not bashing Apple (I rarely post or even RT stuff about them), and that’s not what this is meant to be. It also isn’t about whether similar messaging systems from other companies are any more secure – most aren’t, but GPG email (for example) is. Please, if you want to comment on this post, let’s keep it on topic to this specific technical issue and the answer to the question in the post title.
Also, to be fair to the original author of the article, I don’t know whether it was even meant to answer that question, although it does neglect to mention what I’m covering here and in doing so may give a false impression that the answer is “no”. The article could just be trying to convey the technical details of how it works, and they did a great job of that.
The question of whether Apple could intercept is primarily being discussed due to recent concerns about the NSA forcing companies like Apple to do this sort of thing and also keep quiet about it. The response to that concern (by some) has been to try to claim that this system is impervious to that threat because Apple themselves couldn’t do it even if they wanted to, and that’s the part that unfortunately just ins’t true.
The post actually does a pretty great job of explaining the concept of public key cryptography, and how it’s used by the iMessage system. In this post, I’m going to take for granted that the article is an accurate representation of how iMessage works.
Here’s a quick illustration of the basic example, why it seems secure, and eventually why it isn’t. [And please excuse the crude drawings - don't want to spend all day on this].
User A wants to send an encrypted message to User B, via a messaging system that’s owned by Company X. Both users have a set of public / private key pairs, and the great thing about that type of system is that as long as both users have the public key of the other user, they can send encrypted messages to each other that Company X cannot read.
Using only User B’s public key, User A can create an encrypted message, and then send it through Company X to User B. Since X does not have User B’s private key, X cannot decrypt the message.
Seems great, right? Of course! If it were as simple as that, the answer to whether X can read or intercept is (at this point) “no”.
The Critical Question
What this simple picture doesn’t take into account is the question of how did User A get the public key for User B? Again, assuming the article is correct, it says:
“When someone starts an iMessage conversation with you, they fetch your public key(s) from Apple’s servers.”
Uh oh. This is game over for the question of whether Company X (Apple) can read / intercept. Here’s exactly how they could do it:
User A: “I want to send an encrypted message to B. X, can you give me B’s public key?”
X creates key pairs C and D. X gives public key C to A and tells A it’s public key B. X also gives public key D to B and tells B that it’s public key A.
User A encrypts a message using the key X told it was public B, and sends it through Company X’s system.
The obvious flaw here is that A and B both can only (in this system as described in the article) obtain the public keys by asking Company X to give them to them. Given that, there’s nothing stopping X from giving A & B keys that it actually controls both ends of behind the scenes, and A & B have no way of seeing that that’s what happened.
Of course, if you’re only concerned with whether other parties can read / intercept, and you don’t care that X could, that’s all fine. But the question this post is answering then has to be answered with a “yes”, which means (especially for a US company) that someone like the NSA could at any time compel X to do what is illustrated above and to not talk about it – and it would all be transparent to the users.
How It Could Be Better
It would actually be pretty simple for Company X to give the users a way to avoid this vulnerability. If X gave A & B the option to generate and directly exchange keys with each other without that exchange going through X in any way, the problem described in the above illustration would be eliminated. Users could transfer the keys in person, or via any other channel they trust that X doesn’t control.
I’d love to see Apple (and other companies with similar messaging systems) do this. I doubt they will, but if they do I will definitely update this post and give them huge kudos.