Some random thoughts about crypto. Notes from a course I teach. Pictures of my dachshunds.

Matthew Green

I'm a cryptographer and professor at Johns Hopkins University. I've designed and analyzed cryptographic systems used in wireless networks, payment systems and digital content protection platforms. In my research I look at the various ways cryptography can be used to promote user privacy.

Archives

Can Apple read your iMessages?

About a year ago I wrote a short post urging Apple to publish the technical details ofiMessage 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.

And that brings us back to iMessage encryption. Apple runs one of the most popular encrypted communications services on Earth, moving over two billion iMessage every day. Each one is loaded with personal information the NSA/DEA would just love to get their hands on. And yet Apple claims they can’t. In fact, even Apple can’t read them:

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.

The biggest problem with Apple’s position is that it just plain isn’t true. If you use the iCloud backup service to back up your iDevice, there’s a very good chance that Apple can access the last few days of your iMessage history.

For those who aren’t in the Apple ecosystem: iCloud is an optional backup service that Apple provides for free. Backups are great, but if iMessages are backed up we need to ask how they’re protected. Taking Apple at their word — that they really can’t get your iMessages — leaves us with two possibilities:

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.

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 XMPPApple’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.

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.

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.

> 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?

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.

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.