Quantcast

Apple Details the Amazing Security Behind iMessage

Apple has updated its security document, explaining how iMessage really works and how secure the whole process is, TechCrunch reports. Apple details how an iOS device creates sets of private and public keys when an iMessage conversation is started, how each message sent is encrypted (AES-128) and stored on Apple’s servers and how that encrypted copy of the message is deleted from Apple’s servers once a device has retrieved it.

Imessage

To make things easier to understand, TechCrunch gives the example of a mail box that has two keys. One key lets you drop mail into the mail slot, while the other key lets you take mail out, and both keys are entirely different. Similarly, a “public key” is like the mail slot key. You can share it with the world, and anyone can encrypt messages to send to you. However, the key only works in one direction. Your private key (the mail pickup key, in the analogy above) is the only way to decrypt the message.

With that, here’s how iMessage works:

When a user first enables iMessage, your device creates two sets of private and public keys: one set for encrypting data, and one set for signing data (read: signing data is a secondary blurp of data that helps to verify that the encrypted text hasn’t been modified after it was sent to the server. If these two things ever don’t match up, red flags start going off.)Your public keys are sent to Apple’s servers.

Your private keys are stored on your device. Apple never sees your private keys.

When someone starts an iMessage conversation with you, they fetch your public key(s) from Apple’s servers. Before that message leaves the sender’s device, it’s encrypted into something that only your device knows how to decrypt.

So if Apple never has your private key, how do messages arrive at all of your devices in a readable form? How do your private key(s) get from one device to the other?Simple answer: they don’t. You’ve actually got one set of keys for each device you add to iCloud, and each iMessage is encrypted independently for each device. So if you have two devices — say, an iPad and an iPhone — each message sent to you is actually encrypted (AES-128) and stored on Apple’s servers twice. Once for each device. When you pull down a message, it’s specifically encrypted for the device you’re on.

Some data (“such as the timestamp and APN routing data”, says Apple) is not encrypted.

All of this independently encrypted/non-encrypted data is then encrypted as a whole package, on the trips between your device and Apple’s servers. This makes it considerably tougher for attackers sitting between you and Apple’s server to figure out what data is what, and what they should actually try to decrypt.

Once your device has retrieved a message, that encrypted copy of the message is deleted from Apple’s servers. If you have multiple devices, another encrypted copy meant for another device might sit on their servers until it expires. Messages are stored for up to seven days.

Apple’s updated document also details the inner working of both Touch ID and the “Security Enclave” built into Apple’s 64-bit A7 processor. For those interested can download the document here.

“Technology runs through my veins...” | Follow me: @DrUsmanQ usman@iPhoneinCanada.ca

  • http://www.ryantoyota.com/ Ryan

    Whenever I’ve read claims from Apple about how they encrypt iMessages and they don’t have your private keys, I’ve never quite believed it, because of how multiple devices are able to get the same string of messages. My confusion was answered with this statement:

    “How do your private key(s) get from one device to the other? Simple answer: they don’t. You’ve actually got one set of keys for each device you add to iCloud, and each iMessage is encrypted independently for each device. So if you have two devices — say, an iPad and an iPhone — each message sent to you is actually encrypted (AES-128) and stored on Apple’s servers twice. Once for each device.”

    That totally makes sense. It’s much easier to believe now. (I assume read receipts are not encrypted, as those seem to pass from device to device with no issues.)