Could Apple Read iMessages?

TLDR: Yes

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 Basics

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.

This entry was posted in Blog Posts. Bookmark the permalink.

10 Responses to Could Apple Read iMessages?

  1. jared says:

    Just a quick follow-up to mention that there are (or seem to be – I obviously haven’t tried them myself) apps in the iOS store that do let you do secure public key encryption. oPenGP is one that looks good. I don’t know if there are any that have integrated IM (as opposed to mail) functionality, but if not you could copy/paste the encrypted text into other messaging apps.

    If you are looking for something like this, the important feature to watch for (as it relates to the vulnerability described in this post) is that it gives you a way to put trusted public keys onto your device without having to get them through some external service hosted by a party that you don’t want to be able to intercept your messages.

  2. jared says:

    Update #2 – props to the author of the original article for adding an update to the post that clarifies / corrects the issue, stating that because of the issue described here (and there are other variations), the messages can actually be intercepted / read.

  3. Dan says:

    To bring our conversation from twitter here…

    I understand how MitM would work with iMessages, I clarified that after linking to a comment thread on HN. I didn’t think you needed to explain it anymore than you already had (but you did), since that wasn’t the issue I was bringing up.

    I was arguing that the article was not a “joke”, it’s purpose is what you describe:

    The article could just be trying to convey the technical details of how it works, and they did a great job of that.

    (emphasis mine)

    Based on that quote (and what’s said prior to it here) and your twitter comments it seems as though you want(ed?) to imply that the article was meant to explain how iMessage is completely secure even though it doesn’t, the title of the article should prevent you from concluding that. Even the docs that Apple released that this article is based on doesn’t imply it’s as more secure than another, including GPG (since you love to compare it to that).

    Again, the article is hardly a “joke”. I don’t mind that you have higher standards for Apple’s products, argue that they should be better all day; your compromises are is a personal choice.

    —-

    To clarify my reply here since it was a side note to the conversation I was trying to have above:

    Users could transfer the keys in person, or via any other channel they trust that X doesn’t control.

    That’s what I mean by saying “it’s not really possible”. A company that cares about the user experience would never do this. I couldn’t imagine providing keys for each one of the devices that I want to message with, it’s completely impractical.

    Even your solution shows a major flaw, “via any other channel they trust that X doesn’t control” because you’re trusting someone, even the person you privately whisper the key to.

    If you think security is a boolean than it’s always false, even your highly touted GPG has had it’s problems.

    And now we’ve come full circle: the problem with the article (or at a lower level: iMessage) is not your distrust in Apple (even though you trust other “platforms”, e.g. GPG).

    After you reply I’ll follow up with more about how the MitM attack that could happen isn’t what you describe.

  4. Dan says:

    Followup from our conversation:
    Here’s that statement of them denying it’s possible[1], at least they’re saying that they do not provide that information (which I would believe unless someone can prove otherwise).
    http://www.apple.com/apples-commitment-to-customer-privacy/

    And here’s a doc they shared when every other tech company was allowed to share requests:
    http://s-v.me/UIBD/131105reportongovernmentinforequests2-131106004557-phpapp02.pdf

    Updated (and shorter):
    http://www.apple.com/pr/pdf/140127upd_nat_sec_and_law_enf_orders.pdf

    Anyway, they’re sharing what requests they get (too) but they’re still implying they can’t share iMessage or FaceTime data[1].

    [1] even though we agree it’s technically possible, maybe not feasible.

  5. jared says:

    This is a little weird since we have had an in person conversation covering all this, but for the benefit of other readers, I’ll briefly address the points mentioned in both comments, while mostly trying to keep it related to what I said the scope of this post was – the technical question of whether it was possible.

    The “joke” comment was in reference to the idea that many people were arguing that Apple couldn’t read the messages even if they wanted to. After this article came out, many were pointing to it as evidence. The article itself even says

    “Unless Apple is omitting something or there’s some backdoor … they really can’t read your iMessages without a fairly insane amount of effort.”

    (emphasis on the word “can’t” is from original article). In the excerpted part of this quote they link to a story about the NSA possibly undermining the cryptographic algorithms themselves, but that “insane amount of effort” is not what we’re talking about here. Based on that, it does still seem to me that the article was in some ways trying to support the idea that interception couldn’t be done (as easily as described here), and that’s what the “joke” thing was about. But I definitely don’t want to argue about perceived motivations behind the post. Like I said, I was glad to see they updated it to clarify that the answer to this technical question is “yes”.

    As for allowing secure key exchange outside of Apple’s control in order to make it more secure, I certainly was never suggesting that should be only method, or even the default. Ideally, they could make it work exactly the way it does now, and simply add an option for the people who cared about it to choose to handle some key exchanges securely through another channel. The reality (which we both agreed to in conversation) is that they probably wouldn’t do that since that kind of security isn’t a priority for them in iMessage, and the users who care about it would probably already just use a different application / system that does support secure key exchange.

    We also talked about how there’s an even simpler method than I describe in this post since they say that they support new devices by sending the new keys whenever a new device is added. So they could easily add their own hidden “new device” to the mix, or replace keys for an existing device (just like would happen if the user bought a new iPhone to replace their old one), and the new keys would get added / replaced transparently to the users. I did intentionally leave out the additional device angle from the original post because I wanted to keep it as simple as possible, but ultimately the technique described in my original post is certainly still viable, and there are also lots of other even easier ways it could be pulled off given what we know about how new devices are handled.

    I appreciate the links and docs, but despite all of those I think we both know that it’s technically possible, and that’s the only point this post was making. I’d disagree that it isn’t “feasible”; some of the options that simulate extra devices being added would be pretty trivial for them to do. If the NSA told them they had to, they’d basically have no choice, so debating their their motivations or desires is irrelevant in my opinion. I’ve certainly never suggested that they want to do it, or implied anything else about that. That’s why I wanted to keep this post strictly about whether they *could* technically do it (if forced), and it’s clear that we both agree that they could.

  6. Dan says:

    I wonder if the people that care about this, which probably know they’re being tracked, have tested if any of those attacks are being done, since it would be easy for them to do.

    Option 1 – Replacing keys and swapping them around (your graph): User A could just ask User B what public key they have and vice versa. If different than it’s immediately clear a circumvention is being done.

    Option 1 – adding an extra device in the key bag that the user receives: User A just asks User B how many devices they have and if the totals don’t match than they can simply audit the keys (similar to option 1 but counting the keys would be easier).

    Subsequently these nefarious/crazy users need to check to see if the keys change, in amount and/or string, if a change has been made than they can ask the other user if they have a new device.

    So…with that in mind it really isn’t possible for the NSA to go undetected “unless there’s a backdoor” of some sort.

    This could be Apple’s out, stating it could easily be detected; we just don’t know if the NSA cares about the possibly of being found out, especially if they can somehow use Apple as the scapegoat.

    Only if Apple provided and easier method to check the keys reliably than you wouldn’t your method to exchange the keys in person.

  7. jared says:

    In Option 1, how do they “check” which key they have? Does Apple even make the keys visible in iMessage?

    As for the number of devices, same question: can you see in iMessage how many devices the other user has?

    Can you post some screenshots somewhere about what iMessage shows you in terms of other users’ key info and device counts?

    Like you said, they could always just not show that extra information in these cases, but I would be interested to see what it looks like now.

  8. jared says:

    Here is a really good technical write-up, making a lot of the same points, and a few new ones: http://blog.quarkslab.com/imessage-privacy.html

  9. Dan Cameron says:

    I don’t know how to get them. I’m just saying they could check if they wanted.

    Option #2: you simply ask the other person how many devices they have. Then you cross check.

    I’m sure some smart person can (or has) figured something out. I’d guess calculating packet sizes would work with enough testing.

  10. jared says:

    You’re saying they “could check if they wanted”, but I don’t see any way they could.

    I looked all through Emma’s phone (iOS 7) which has many iMessage conversations with other iOS users, and I didn’t see any way to see anything about the keys and/or number of devices from another party you’re messaging, so I think that’s a no-go. If I missed it (certainly possible), please point it out to me via a screenshot / link.

    I don’t think asking and/or knowing how many devices the other person has would help in any way, because (again – same point as above) I don’t think it shows that to you on your device, so I’m not sure what you’d be checking that number against. Again, if it does show you, let me know where / how.

    Lots of smart people have in fact looked at this, and I think most of them (who understand the technical details of how public key encryption works, and the iMessage platform as described by that post) have acknowledged that the answer to the question of whether Apple could (most likely on behalf of another party) intercept iMessage traffic – without either user being aware of it – is “yes”.

    I’ve never seen any convincing technical post refuting the “vulnerabilities” described here in a way that would make the answer to the question “no”, or even that would make the process detectable by the users. Again, if you know of any, please post a link.

    I’m considering this case closed, unless you’d like to post screenshots or an explanation of exactly (technically) how the users would do the kind of cross-checking you suggest.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>