Millions and millions of people use iMessage every day. But how many people know exactly what’s going on behind the scenes, or what happens to a message once you send it?
Maybe a handful. Up until now, the vast majority of what we knew about iMessage’s inner workings came from reverse engineering and best guesses. This week, however, Apple quietly released a document that breaks it all down.
If you know your stuff when it comes to cryptography, you can find the document here. The iMessage bit starts at page 20, but there’s all sorts of crazy interesting stuff regarding cloud keychain and hardware security packed in there too.
If you don’t know much about crypto, I’ll try to break it down a bit below. I admittedly have plenty of gaps in my crypto knowledge, but I’ve triple-checked this with people who know considerably more about this topic than I.
Before we dive in to the deeper stuff, you’ve got to understand one overarching concept at play here. It’s a fairly standard concept in the tech world, but it’s not something that most people ever have to think about. It’s called public-key cryptography.
To over simplify it: imagine you have a mail box. This box has two keys. One key lets you drop mail into the mail slot, and one key lets you take mail out. The input key and the pickup key are entirely different; one can never be used to replace the other. You can give away a million copies of your input key, and no one could use it to do anything but put mail in. Unless they find a copy of your pickup key or find a weakness in the way your mailbox was designed, your message is safe.
This is the thinking behind public-key cryptography. Your “public key” is like the mail slot key. You can share it with the world, and anyone can encrypt messages to send to you. But the public key only works in one direction. Once a message is encrypted, that public key can’t be used to decrypt it, or reverse the encryption. Once encrypted, your private key (the mail pickup key, in the analogy above) is the only way (barring exploits/brute force with a supercomputer) to restore the message to its original readable form.
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.
- Things change around a bit for long messages and pictures, allowing Apple to hold photos and other media on the iCloud servers without being able to view them. In those case, your device generates a new, random key and a URI (read: address for something on a server) which catalogs where on the iCloud servers the image/media is stored. Apple sends your device the key and URI (which again, only your private key can decrypt), and your device pulls that image down from Apple’s servers and turns it into something readable.
- 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.
Too long, didnt read? Basically: Unless Apple is omitting something or there’s some backdoor tucked into their many-layers-deep encryption (which, while unlikely, isn’t inconceivable) they really can’t read your iMessages without a fairly insane amount of effort. Sure, they could theoretically brute force their way past your private key. Or they could scrap the entire system and replace it with something with glaring security holes, and hope no one notices.
But the same could be said for any service where someone else is even temporarily storing your messages — when you’re putting things into a black box, even if you think you know exactly how that black box works, you’re trusting that the black box hasn’t changed. And if Apple intends on ever lurking through your iMessages, they’ve made it pretty damned hard for themselves.
Update: As some have pointed out, there are, in fact, potential points of failure in this security model as detailed. For example: because Apple is encrypting messages/data once for each device and has control over the key infrastructure, they may (if, say, by court order) be able to throw another public key into the mix— thereby allowing messages sent to you after that point to be read by whoever has the corresponding private key.
Comment