What was all that about a scary iMessage flaw? Your three-minute guide
How a powerful hacker could just about intercept and decrypt your texts
Watercooler – On Sunday, we were warned that hackers could read our iMessages texts, photos and videos. Should I be worried?
As it turns out: no. If you're even a little curious about cryptography and secure programming, though, it should interest and amuse you. On Sunday, the Washington Post learned that Apple had fixed a flaw in the design of its iMessage system that could be exploited to decrypt private texts and snaps. The vulnerability was discovered by US academics.
On Monday, the next day after the newspaper's report, Apple announced a bunch of new things, released new software including fixes for this messaging vulnerability, and then the FBI surprisingly halted its legal fight against the iGiant over the unlocking of a murderer's phone, and everyone forgot about the iMessages trouble.
So what was the problem?
The WaPo article was very light on details. Here's the deal. Let's say Alice is sending Bob an iMessage. To Alice and Bob, the message is just one thing, like a "lol" or a photo, but really, it's split in three parts that are glued together by iOS on Alice's iPhone before being sent to Bob's iPhone:
- The body of the iMessage is encrypted using AES-CTR and a randomly generated key. That's one part.
- The encryption key is itself encrypted using Bob's RSA public key. This public key is obtained from Apple's iCloud by Alice's iPhone just before sending the text. That encrypted AES-CTR key is another part of the iMessage.
- The third and final part is a signature of the other two parts, generated by Alice's ECDSA signing key.
When Bob receives the message, Bob's iPhone uses its RSA private key to decrypt the AES-CTR key. This key is then used to decrypt the message body. It's like a Russian doll. The outer doll is the RSA-encrypted key. The doll within is the AES-CTR key. And the doll in the center is the message.
If someone intercepts and tampers with either the encrypted key or the encrypted message, they won't match the signature, and the message will be rejected?
You got it. Altering the encrypted key or the encrypted message will mean they no longer match up with the signature at the end of the iMessage. But here lies the flaw. Someone intercepting the iMessage can strip off the signature and sign it using their own ECDSA signing key.
And iOS accepts that.
So, if a bad person – let's call them Eve – can intercept Alice's iMessage on a network, Eve can strip off the signature, tamper with the encrypted message data, add her own valid signature to the end, and send it on to Bob. Eve's ECDSA signing key is simply the one associated with her iCloud account.
And Bob's iPhone will just accept the tampered message?
Well, yes and no. Yes, it will accept the modified message data with Eve's signature. However, altering the encrypted message data without knowing the decryption key, which Eve doesn't know at this point, means you'll just end up meddling with bits and bytes blindly.
The message bodies are also gzip-compressed with a dynamic Huffman table and unpacked into a particular format that iOS expects. Alice could send "lol" to Bob, and it could be transmitted compressed and encrypted as "8YTJj". But changing "8YTJj" to "9YTJj", a simple increment of one byte by Eve, could decrypt and decompress to something wildly different to the original "lol".
In other words, most of the time Eve will send to Bob tampered encrypted message data that decrypts into garbage that his iPhone can't understand and will reject.
Most of the time?
Well spotted. If you can silently intercept Alice's message, and replay it to Bob thousands of times with slightly different alterations, you'll eventually produce a valid message that's accepted by Bob's iPhone. We're talking more than 250,000 iterations, here.
When you send a broken message to Bob's iPhone, it will send back an error. If Eve, sitting on the network between Alice and Bob, sees no error from Bob, then Alice's message was sabotaged in a way that survived decryption and parsing. With some clever math, you can slowly, byte by byte, piece together the unencrypted contents of Alice's message.
That sounds like a nightmare to pull off?
There's an easier way. Now, the thing is: when you send a photo in an iMessage, what really happens is that your iPhone uploads the snap to the iCloud in encrypted form, and sends a link to the image with a decryption key in the body of the encrypted iMessage.
When Bob's iPhone receives a photo iMessage from Alice, his phone will decrypt the message, get the URL to the image, download it from iCloud.com, and decrypt it using the bundled key.
If Eve can intercept this iMessage and tamper with it so that the message still decrypts into a parseable formate, but the URL is slightly mangled in that it fetches not from iCloud.com but from iCleud.com – and Eve has bought iCleud.com – she can see the full damaged URL requested.
Replay this thousands and thousands of times, watching all the requests to iClued.com and other domains, and Eve can work out Bob's RSA private key.
Wait, so what does Eve need to achieve this?
Eve must be able to intercept TLS-encrypted connections between Alice, Apple and Bob, so she needs to run a malicious Wi-Fi point or similar. Eve must also have some serious computational power to crunch through all these attempts to cracking Bob's key. Eve must also have a bunch of domains that can serve mangled iCloud.com URLs.
Eve must waylay the connections using a HTTPS server that can successfully masquerade as Apple's legit systems. Only Apple can do this, of course. You'd have to steal Apple's private keys or compromise a root certificate authority to do this yourself. Also, iOS 9 uses certificate pinning, which makes it hard for Eve's systems to pretend to be real Apple backend systems.
You have to be a determined and well-resourced attacker to exploit this. Let's say Eve works at an intelligence agency, and has access to the kit needed to pull off this theft. There are probably better ways to spy on her targets, who probably aren't using iMessages for anything incriminating anyway.
Still, hats off to the Johns Hopkins University team in Maryland for spotting this Cupertino design blunder.
So what's Apple done about it?
Apple's software looks for repeated attempts to brute-force the messaging system and rejects attempts to deliver them: if it sees repeated use of the same RSA-encrypted block, it knows something's not right. That RSA block should change with each valid iMessage because it's encrypting a random key.
How do you know all this?