About a year ago I wrote a short post urging Apple to publish the technical details of
iMessage encryption. I’d love tell you that Apple saw my influential crypto blogging and fell all over themselves to produce a spec, but, no. iMessage is the same black box it’s always been.
What’s changed is that suddenly people seem to care. Some of this interest is due to Apple’s (alleged) friendly relationship with the NSA. Some comes from their not-so-friendly relationship with the DEA. Whatever the reason, people want to know which of our data Apple has and who they’re sharing it with.
There are certain categories of information which we do not provide to law enforcement or any other group because we choose not to retain it.
For example, conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them. Apple cannot decrypt that data.
This seems almost too good to be true, which in my experience means it probably is. My view is inspired by something I like to call “Green’s law of applied cryptography”, which holds that applied cryptography mostly sucks. Crypto never offers the unconditional guarantees you want it to, and when it does your users suffer terribly.
And that’s the problem with iMessage: users don’t suffer enough. The service is almost magically easy to use, which means Apple has made tradeoffs — or more accurately, they’ve chosen a particular balance between usability and security. And while there’s nothing wrong with tradeoffs, the particulars of their choices make a big difference when it comes to your privacy. By witholding these details, Apple is preventing its users from taking steps to protect themselves.
The details of this tradeoff are what I’m going to talk about in this post. A post which I swear will be the last post I ever write on iMessage. From here on out it’ll be ciphers and zero knowledge proofs all the way.
Apple backs up iMessages to iCloud
 |
| That’s the super-secret NSA spying chip. |
- iMessage backups are encrypted under a key that ‘never leaves the device‘.
- iMessage backups are encrypted using your password as a key.
Unfortunately neither of these choices really works — and it’s easy to prove it. All you need to do is run the following simple experiment: First, lose your iPhone. Now change your password using Apple’s iForgot service (this requires you to answer some simple security questions or provide a recovery email). Now go to an Apple store and shell out a fortune buying a new phone.
If you can recover your recent iMessages onto a new iPhone — as I was able to do in an Apple store this afternoon — then Apple isn’t protecting your iMessages with your password or with a device key. Too bad. (Update 6/27: Ashkan Soltani also has some much nicer screenshots from a similar test.)
The sad thing is there’s really no crypto to understand here. The simple and obvious point is this: if I could do this experiment, then someone at Apple could have done it too. Possibly at the request of law enforcement. All they need are your iForgot security questions, something that Apple almost certainly does keep.*
Apple distributes iMessage encryption keys
But maybe you don’t use backups. In this case the above won’t apply to you, and Apple clearly says that their messages are end-to-end encrypted. The question you should be asking now is: encrypted to whom?
The problem here is that encryption only works if I have your encryption key. And that means before I can talk to you I need to get hold of it. Apple has a simple solution to this: they operate a directory lookup service that iMessage can use to look up the public key associated with any email address or phone number. This is great, but represents yet another tradeoff: you’re now fundamentally dependent on Apple giving you the right key.
 |
| HTTPS request/response containing a “message identity key” associated with an iPhone phone number (modified). These keys are sent over SSL. |
The concern here is that Apple – or a hacker who compromises Apple’s directory server – might instead deliver their own key. Since you won’t know the difference, you’ll be encrypting to that person rather than to your friend.**
Moreover, iMessage lets you associate multiple public keys with the same account — for example, you can you add a device (such as a Mac) to receive copies of messages sent to your phone. From what I can tell, the iMessage app gives the sender no indication of how many keys have been associated with a given iMessage recipient, nor does it warn them if the recipient suddenly develops new keys.
The practical upshot is that the integrity of iMessage depends on Apple honestly handing out keys. If they cease to be honest (or if somebody compromises the iMessage servers) it may be possible to run a man-in-the-middle attack and silently intercept iMessage data.
Now to some people this is obvious, and to other’s it’s no big deal. All of which is fine. But people should at least understand the strengths and weaknesses of the particular design that Apple has chosen. Armed with that knowledge they can make up their minds how much they want to trust Apple.
Apple can retain metadata
While Apple may encrypt the contents of your communication, their statement doesn’t exactly rule out the possibility they store who you’re talking to. This is the famous meta-data the NSA already sweeps up and (as I’ve said before) it’s almost impossible not to at least collect this information, especially since Apple actually delivers your messages through their servers.
This metadata can be as valuable as the data itself. And while Apple doesn’t retain the content of your messages, their statement says nothing about all that metadata.
Apple doesn’t use Certificate Pinning
As a last – and fairly minor point – iMessage client applications (for iPhone and Mac) communicate with Apple’s directory service using the HTTPS protocol. (Note that this applies to directory lookup messages: the actual iMessages are encrypted separately and travel over XMPP Apple’s push network protocol.)
Using HTTPS is a good thing, and in general it provides strong protections against interception. But it doesn’t protect against all attacks. There’s still a very real possibility that a capable attacker could obtain a forged certificate (possibly by compromising a Certificate Authority) and thus intercept or modify communications with Apple.
This kind of thing isn’t as crazy as it sounds. It happened to hundreds of thousands of Iranian Gmail users, and it’s likely to happen again in the future. The standard solution to this problem is called ‘certificate pinning‘ — this essentially tells the application not to trust unknown certificates. Many apps such as Twitter do this. However based on the testing I did while writing this post, Apple doesn’t.
Conclusion
I don’t write any of this stuff because I dislike Apple. In fact I love their products and would bathe with them if it didn’t (unfortunately) violate the warranty.
But the flipside of my admiration is simple: I rely on these devices and want to know how secure they are. I see absolutely no downside to Apple presenting at least a high-level explanation to experts, even if they keep the low-level details to themselves. This would include the type and nature of the encryption algorithms used, the details of the directory service and the key agreement protocol.
Apple may Think Different, but security rules apply to them too. Sooner or later someone will compromise or just plain reverse-engineer the iMessage system. And then it’ll all come out anyway.
Notes:
* Of course it’s possible that Apple is using your security questions to derive an encryption key. However this seems unlikely. First because it’s likely that Apple has your question/answers on file. But even if they don’t, it’s unlikely that many security answers contain enough entropy to use for encryption. There are only so many makes/models of cars and so many birthdays. Apple’s 2-step authentication may improve things if you use it — but if so Apple isn’t saying.
** In practice it’s not clear if Apple devices encrypt to this key directly or if they engage in an OTR-like key exchange protocol. What is clear is that iMessage does not include a ‘key fingerprint’ or any means for users to verify key authenticity, which means fundamentally you have to trust Apple to guarantee the authenticity of your keys. Moreover iMessage allows you to send messages to offline users. It’s not clear how this would work with OTR.
A Few Thoughts on Cryptographic Engineering 
Oh and when you install iMessage on your mac you can see the messages that have been previously sent to your phone…..
It may come as a surprise to you that iCloud runs on Microsoft's Azure and Amazon AWS.
iMessages are sent via Apple's push service, which is not using XMPP, but a proprietary protocol.
I reversed it and documented it here: https://github.com/meeee/pushproxy/blob/master/doc/apple-push-protocol-ios5-lion.md
OS X 10.9 (and probably also iOS 7) does certificate pinning for the push connection, I don't know about the directory lookup.
Because you entered your iCloud password…
Regarding changing the passwords, have you considered a scheme where the password wraps the decryption key in order to allow the changing of passwords? And that those secret questions (though low-entropy) also wrap that decryption key?
Another way that is possible to think of (but unlikely) is that when you changed your password and then turn on a new phone you sign into the same iMessage bundle and another phone could re-encrypt the iMessages for your new iPhones public key.
“If you can recover your recent iMessages onto a new iPhone — as I was able to do in an Apple store this afternoon — then Apple isn't protecting your iMessages with your password or with a device key. “
This might be wrong. The device key may leave the device in case of backups (like in case of encrypted itunes backups). If it is backed up to icloud, then why shouldn't the key be encrypted by your icloud login data and “glued” to the bunch of encrypted imessages, as it is done with truecrypt conainters.
Also this allows apple to decrypt the imessages kept in icloud, as they have the key, this doesn't mean there is no end-to-end encryption, which apple might not directly be able to decrypt.
If the device key leaves the device, then I was able to obtain it again using an Apple password reset and a brand new device. I'm certainly not going to claim that I know everything about Apple's system, just the end result. If Apple wants to — or is compelled to — they can read messages stored in your iCloud backups.
People like to say stuff like this, which seems kinda silly when Apple has just built a billion dollar data center and is in the process of building another.
Apple may use Azure or AWS for some service support, but it may also be the case that they did this temporarily while they waited for the maidenhead datacenter to come online.
on some testing at a carrier level, it seems as though iMessage doesn't like older style SIM cards, so I would not be shocked if Apple is using some of the information stored on the SIM or other items like the Akey used for CDMA. I would think using the MILENAGE would make a lot of sense, as it is an open standard but very secure for use on mobile devices.
Regarding indication of how many keys have been associated with a recipient, I believe the key is tied to the identity subject, i.e. a tel: URI or mailto: URI. This is independent of a device that subscribes to messages on that identity.
I know I do get notified on all devices whenever a device introduces a new identity to my iMessage or FaceTime chain, and usually get an option of accepting or rejecting that identity on my other devices. (I have an iPad, two iPhones and a Mac).
With regards to backups, I believe Apple is pretty clear in the iOS Security Whitepaper (https://www.apple.com/ipad/business/docs/iOS_Security_Oct12.pdf) as to which data elements are “non-migratory” across devices, meaning they are encrypted with the device-UID-wrapped key, and can only be restored on the actual device. They're also clear about “Full Protection” of files such as Mail that require the device UID and passcode. This is why you actually don't see your old mail messages on a newly restored device – you have to go back to your IMAP or POP server.
iMessages don't seem to have the same level of protection by design — because there's apparently no other way to get at history other THAN a backup. It's not clear if iMessage files are encrypted at all or if they have standard “NSFileProtectionCompleteUntilFirstUserAuthentication” disk encryption.
The long & short of it is that Apple can't get at your iMessage contents or history if you don't use iCloud backups and don't subscribe to Apple's desktop password recovery service (duh).
(Me from above again) This would just mean don't use icloud 😉 if you think about security you should rethink the usage of cloud storage in seperation to your messaging needs.
Another question in that train of thoughts is the device and app synchronisation. This could be done by applying per-device keys for one account, and having send everything (incl. my send imessages) to every device of me and the devices of the receiver.
I can recommend threema 😀
> The standard solution to this problem is called 'certificate pinning' — this essentially tells the application not to trust unknown certificates. Many apps such as Twitter do this. However based on the testing I did while writing this post, Apple doesn't.
Out of curiosity, did you explicitly test a forged or untrusted cert to determine this? Or is it something you can reasonably infer?
“In fact I love their products and would bathe with them if it didn't (unfortunately) violate the warrantee.”
I assume you meant “violate the warranty”. Unless you meant that these products would violate you, the warrantee, which I imagine would be just as objectionable, if not more so. 🙂
Perhaps for live iMessages, but the iCloud backup doesn't require you to use the same SIM card. I got a brand new one with the phone.
Yes, I used the Charles proxy which does SSL interception using a self-signed cert (I added the root to my phone & Mac.)
Apple also claims FIPS certification which requires Apple provide the crypto method and key equation to NIST. Sooooooooooooo the feds have everything they need.
An assumption:
1. The iMessages are encrypted with a key derived from the iCloud password.
2. Every time the iCloud password is changed, a new encryption key is derived, and all iMessages are decrypted (with old key) and newly encrypted (with new key).
This could explain why iMessages can be recovered with a new device and a new password.
This is a simple asumption (no proof whatsoever that this is correct).
In the description above, the encryption would be performed by the user's device (not by iCloud which wouldn't need to know the user's password — but only a hash of it or something).
But still, if one is able to change the iCloud password at her convenience, the net result is that she is able to get the iMessages in clear.
And you can also read/write on your Mac OS X
Mathew,
This is a little off the topic of iMessages but has to do with messaging security in general.
What about one-time pad encryption? In every book about encryption, it seems like they start by talking about this as being unbreakable but then immediately dismiss the idea because of the problem of key distribution.
But wait, the current universal collection of all messages impacts people whose requirements differ from those of governments, armies, businesses, etc. I know a maybe 50 or 100 people and communicate regularly with maybe 5 or 10. Most of these I see daily.
New phones have Near Field Communication (NFC) that allows files to be exchanged by simply touching the phones or at least having them close together. Suppose that people exchanged files of random bits by this mechanism and used them in short messaging. For example, maybe the random bits would be structured as files with numbered file names. Each file contains enough bits to encode a single SMS message.
So A sends a message to B. A uses the next available sequence number in the A-B set of random bits, pulls the bits and encodes the message. The message would be prefixed with the sequence number so that B could choose the same bits to decode the message. After encoding, A erases the bits and after decoding, B also erases the bits.
Here is a project that does something like this already.
http://hcsoftware.sourceforge.net/HardEncrypt/doc/howitworks.html
So if this works, the hard drives of the observers fill up with junk????
This is likely what a terrorist cell would do making the whole billion dollar operation of the NSA pretty fucking pointless in the first place…