Update – 2014/09/19
Since this topic has been raised again recently, I thought it might be helpful to update this post with the easiest to understand (not the only) way that iMessage could be “wiretapped” (the term they recently used – “we wouldn’t be able to comply with a wiretap order even if we wanted to”, in reference specifically to iMessage communications). I thought it was worth a short update, since the original post is probably way too long and technical for normal users to read through.
You or a friend may get a new device (either a replacement or an addition) at any time. According to Apple’s own description of what happens, the public encryption keys unique to the new device are provided to other users who want to send that user a message, so that the messages will be received on all the user’s devices, and securely encrypted end-to-end.
Since this key distribution happens automatically and transparently to all the users involved, exclusively via Apple’s servers , the first obvious option for wiretapping is that representatives from a three letter agency go to Apple with some iDevice(s) and say “add these devices on this/these accounts”. From that point forward, the “wiretap” is in effect. (Note that under this model, they would not be able to go back in time to read old messages – it would be a traditional wiretap: from now forward).
Now, there’s probably not an easy/automated way for them to associate a device with an account outside of the normal channels, but it would be
naive impossible to believe it’s impossible, and impossible should be the standard for saying “we wouldn’t be able to comply with a wiretap order even if we wanted to”. What I can only assume they “mean” when they say this is that their system as it exists doesn’t support it easily or as an existing feature, but if you don’t believe that someone could go manipulate the database (or whatever) where they store the device-to-user associations to make it happen, you’re fooling yourself. If they’re telling their customers they can’t do it, they’re fooling their customers.
It’s a bit puzzling to me why they would even bother trying to say this, since I really don’t think many users are worried about whether their messages could be wiretapped, but then again most users don’t care that Google can read their mail or search history either. I think in trying to make this into a selling point to contrast Google’s business model (which might be a good strategy), they overstepped into making misleading statements. I think they’d be better off sticking to the facts.
End Update – 2014/09/19
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.