How iMessage distributes security to block “phantom devices”

By Rich

Last Friday I spent some time in a discussion with senior members of Apple’s engineering and security teams. I knew most of the technical content but they really clarified Apple’s security approach, much of which they have never explicitly stated, even on background. Most of that is fodder for my next post, but I wanted to focus on one particular technical feature I have never seen clearly documented before; which both highlights Apple’s approach to security, and shows that iMessage is more secure than I thought.

It turns out you can’t add devices to an iCloud account without triggering an alert because that analysis happens on your device, and doesn’t rely (totally) on a push notification from the server. Apple put the security logic in each device, even though the system still needs a central authority. Basically, they designed the system to not trust them.

iMessage is one of the more highly-rated secure messaging systems available to consumers, at least according to the Electronic Frontier Foundation. That doesn’t mean it’s perfect or without flaws, but it is an extremely secure system, especially when you consider that its security is basically invisible to end users (who just use it like any other unencrypted text messaging system) and in active use on something like a billion devices.

I won’t dig into the deep details of iMessage (which you can read about in Apple’s iOS Security Guide), and I highly recommend you look at a recent research paper by Matthew Green and associates at Johns Hopkins University which exposed some design flaws.

Here’s a simplified overview of how iMessage security works:

  • Each device tied to your iCloud account generates its own public/private key pair, and sends the public key to an Apple directory server. The private key never leaves the device, and is protected by the device’s Data Protection encryption scheme (the one getting all the attention lately).
  • When you send an iMessage, your device checks Apple’s directory server for the public keys of all the recipients (across all their devices) based on their Apple ID (iCloud user ID) and phone number.
  • Your phone encrypts a copy of the message to each recipient device, using its public key. I currently have five or six devices tied to my iCloud account, which means if you send me a message, your phone actually creates five or six copies, each encrypted with the public key for one device.
  • For you non-security readers, a public/private keypair means that if you encrypt something with the public key, it can only be decrypted with the private key (and vice-versa). I never share my private key, so I can make my public key… very public. Then people can encrypt things which only I can read using my public key, knowing nobody else has my private keys.
  • Apple’s Push Notification Service (APN) then sends each message to its destination device.
  • If you have multiple devices, you also encrypt and send copies to all your own devices, so each shows what you sent in the thread.

This is a simplification but it means:

  • Every message is encrypted from end to end.
  • Messages are encrypted using keys tied to your devices, which cannot be removed (okay, there is probably a way, especially on Macs, but not easily).
  • Messages are encrypted multiple times, for each destination device belonging to the recipients (and sender), so private keys are never shared between devices.

There is actually a lot more going on, with multiple encryption and signing operations, but that’s the core. According to that Johns Hopkins paper there are exploitable weaknesses in the system (the known ones are patched), but nothing trivial, and Apple continues to harden things. Keep in mind that Apple focuses on protecting us from criminals rather than governments (despite current events). It’s just that at some point those two priorities always converge due to the nature of security.

It turns out that one obvious weakness I have seen mentioned in some blog posts and presentations isn’t actually a weakness at all, thanks to a design decision.

iMessage is a centralized system with a central directory server. If someone could compromise that server, they could add “phantom devices” to tap conversations (or completely reroute them to a new destination). To limit this Apple sends you a notification every time a device is added to your iCloud account.

I always thought Apple’s server detected a new entry and then pushed out a notification, which would mean that if they were deeply compromised (okay, forced by a government) to alter their system, the notification could be faked, but that isn’t how it works. Your device checks its own registry of keys, and pops up an alert if it sees a new one tied to your account.

According to the Johns Hopkins paper, they managed to block the push notifications on a local network which prevented checking the directory and creating the alert. That’s easy to fix, and I expect a fix in a future update (but I have no confirmation).

Once in place that will make it impossible to place a ‘tap’ using a phantom device without at least someone in the conversation receiving an alert. The way the current system works, you also cannot add a phantom recipient because your own devices keep checking for new recipients on your account.

Both those could change if Apple were, say, forced to change their fundamental architecture and code on both the server and device sides. This isn’t something criminals could do, and under current law (CALEA) the US government cannot force Apple to make this kind of change because it involves fundamental changes to the operation of the system.

That is a design decision I like. Apple could have easily decided to push the notifications from the server, and used that as the root authority for both keys and registered devices, but instead they chose to have the devices themselves detect new devices based on new key registrations (which is why the alerts pop up on everything you own when you add or re-add a device). This balances the need for a central authority (to keep the system usable) against security and privacy by putting the logic in the hardware in your pocket (or desk, or tote bag, or… whatever).

I believe FaceTime uses a similar mechanism. iCloud Keychain and Keychain Backup use a different but similar mechanism that relies as much as possible on your device. The rest of iCloud is far more open, but I also expect that to change over time.

Overall it’s a solid balance of convenience and security. Especially when you consider there are a billion Apple devices out there. iMessage doesn’t eliminate the need for true zero-knowledge messaging systems, but it is extremely secure, especially when you consider that it’s basically a transparent replacement for text messaging.

No Related Posts

I find it interesting to contrast this approach against WhatsApp.

As I understand it, WhatsApp mobile app registration is tied to your phone service number, and the WhatsApp web app relies on your phone app for initial registration. Subsequently web app usage requires your phone to be online in order to respond to web app browser communication and present your message history stored on your phone.

iMessage, while different, I don’t yet think is more secure until it prevents lifting of every client key (via a data protection scheme) on all client end-points.

By Maki

Thanks for explaining this. I was wondering how imessage works when sending text messages to an android phone? I noticed that the iphone knows when another phone is an apple or not. I added a friend to contacts, and it showed me that I can facetime them. Also the differant colors used by imessage.

But, I wondered how encryption worked when sending text message. I was assuming that the iphone doesn’t encrypt when it is not an apple device.

Thanks in advance. Dennis.

By Dennis

Thanks for the piece, Rich!

I’m curious, at one point you say that sending you a message will encrypt a separate copy of the message for each device. Is that accurate, or was that part of your oversimplification?

As I’m sure you know (but reads to this might not) public key encryption usually encrypts the message with a one-time session key, and then encrypts just the session key with each required public key. Makes it more computationally efficient ... and keeps the payload smaller.

Or at least that’s what I was taught, but I could be wrong, too! ;)

By Dave Hamilton

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.