Why Apple’s claim that it can’t intercept iMessages is largely semantics

This op-ed originally appeared in the Washington Post last Saturday in response to Apple’s claims about the security of iMessage.

A lively debate is brewing over the security of Apples iMessages. I was recently quoted on this issue, but Apple has since responded, and it seems important to clarify that the argument now seems to be largely a matter of semantics.
In case you missed it, a group of researchers at Quarklab recently analyzed the iMessage protocol, including the trust model and key exchange, and found some mistakes that leave iMessages open to attacks. I had also previously demonstrated that iCloud backups, including backed-up iMessages, could easily be accessed by Apple. This news is important because previous reports suggested that iMessage encryption was a major impediment to law enforcement, and Apple specifically described iMessage data as “protected by end-to-end encryption so no one but the sender and receiver can see or read them” in response to their reported participation in the NSA’s PRISM program.

Apple stands by its claim that its software can’t be intercepted and that it is not reading iMessages. In that article, Apple spokeswoman Trudy Muller said: “iMessage is not architected to allow Apple to read messages. The research discussed theoretical vulnerabilities that would require Apple to re-engineer the iMessage system to exploit it, and Apple has no plans or intentions to do so.”

But Apple’s response that it cannot intercept messages is a bit misleading.

Apple controls the entire stack: the phone operating system (iOS), iMessage application, the SSL certificates, and key exchange. Quarklab’s researchers demonstrated that if they could obtain (or fake) a trusted Apple SSL certificate AND man-in-the-middle the iMessage key exchange, they would be in a position to intercept or tamper with iMessage. Basically, that means iMessage could be vulnerable if an actor is able to convince the application that they are authorized to carry the data and to insert themselves between the users.

And that might be easier than you’d expect. The researchers also highlight some key mistakes that could allow a well-resourced attacker to intercept iMessage. The most problematic of these is the lack of certificate pinning for SSL. In certificate pinning, an application is told that only specific SSL certificates (e.g. ones the company itself issued) should be trusted; Google does this with its browser, and Twitter does it with its mobile app. Without certificate pinning, SSL can accept certificates as long as they are issued by a “trusted” entity — which is problematic because there’s a great deal of evidence that the SSL trust model is broken.

I should clarify that I haven’t independently verified the Quarklab findings, but the logic is sound — if you can man-in-the-middle the key exchange and the communication, then you can also decrypt the messages. The researchers attach a caveat to this finding by saying “it would take a very resourceful actor like a 3-letter agency or the NSA themselves” to take advantage of this vulnerability. In fact, these findings could be interpreted as evidence of the strength of Apple’s system.

But this essentially boils down to a question of what is possible now and what is possible under the right circumstances. Apple is correctly answering the first question, not the second. I believe Apple’s response that it can’t read your iMessages is currently true. Under the architecture of iMessage, Apple “cannot intercept your messages” — in the same way that Skype couldn’t read your messages, until they could. However, if Apple were pushed to engineer a back door into its system (which I personally believe it would fight) then it could intercept your messages in the way the researchers describe.

In fact, because Apple controls the entire stack, it could intercept your messages 100 different ways. The easiest, in my opinion (and which I have previously pointed out) would be to just add a “ghost” iMessage device that receives copies of your messages and simply suppress the notification that “a new device has been added.” This would take substantially less engineering than these more complicated methods and would keep Apple’s systems intact.

So, is iMessage interception possible? Yes, of course. When you control the entire stack, anything is possible. Saying “we can’t do this” is a bit disingenuous since what Apple really means is “the current system doesn’t have the ‘spy on user X’ ” button. But it could add this with a few lines of code, and most users probably wouldn’t know.

Is Apple doing it? Given how heavily it has pushed back on this topic, I don’t believe the company is currently intercepting iMessages — the potential of a Skype-type leak could be extremely damaging and sacrifice its biggest asset: the Apple brand.

Could or would it intercept iMessages? Probably only if it legally had no other choice, which is the key issue. Recent revelations about PRISM, Skype, Lavabit and the legal interception debate show that this is a major decision facing companies.

Now, there are ways to guarantee that even Apple couldn’t do it if it wanted to — but that requires an entirely different model. If the operating system and application were open-source so that it could be regularly audited by experts AND if the private keys were managed or verified by the user (such as is done with PGP), then perhaps Apple’s claim that it “cannot decrypt” iMessage data would be more persuasive.

However, auditing source code or even managing their own keys is something that both we and Apple know users don’t really have the patience for — yet. Users want simply to use products that just let them text each other or send cat pictures without having to think about “trust relationships.” However, as users begin to realize more and more that their government can force companies to build back doors into the software we all use everyday, this might become a more important consideration.