The recent HITBSecConf2013 revealed some pretty interesting information about the inner workings of Apple’s iMessage protocol. You can an read in-depth description about it on the author’s blog right here.
This isn’t my first time writing about iMessage. You can read my thoughts on the matter on the Information Security Stackexchange blog posted about a year ago right here. Given the new information, I would like to take the time to pen down my current thoughts on the protocol.
Now, there are already countless articles already written about iMessage sucks and that Apple was lying when the released their previous statement about their ability to decrypt iMessage data. I strongly disagree. iMessage, even with the new information, is still a very secure protocol that strikes a good balance between security and usability. So let’s dive into the newly revealed information about the protocol.
First thing first, we notice than pretty much all the traffic is encrypted. Good point. All communications to Apple’s servers are made through a secure SSL tunnel.
That’s good. SSL/TLS is a well-vetted transport layer encryption protocol. However, Apple isn’t using certificate pinning for communications to Apple’s servers. This is surprising considering the level of control Apple asserts over the iOS software stack. For those unfamiliar with certificate pinning, OWASP has a nice introduction on the subject. Essentially, certificate pinning circumvents the whole root CA infrastructure and tells the machine that an SSL certificate for a particular website or server must match a particular certificate. This helps to protect against the whole evil root CA problem. Absence of certificate pinning essentially means that an iOS device is susceptible to MITM attacks by attackers that manage to install a fake CA onto the device.
iMessage revolves around a protocol from Apple known as PUSH. In addition to iMessage, iOS uses PUSH for things like FaceTime and notifications. PUSH communications are protected by a certificate generated when a device is activated with Apple. A certificate signing request is sent to
albert.apple.com which is a Apple-run certificate authority in charge of signing every request.
So what happens when an iMesasge is sent? Firstly, the device request from Apple’s servers information needed to send the message. Three pieces of information is sent back.
A PUSH token. The generation and usage of PUSH tokens isn’t really known since it happens on Apple’s server. It is assumed to be providing routing information and other metadata.
A 256-bit ECDSA public key. This key is used to verify the signature of messages sent by the destination URI of the iMessage.
A 1280-bit RSA public key. This key is used to encrypt iMessages sent to the destination URI.
The keys are provided by a key directory from Apple called ESS servers and are sent encrypted with a client-side generated certificate called
Provision that is valid for one month. Once the key information has been exchange, two iOS devices have the means of sending encrypted data to each other, end-to-end.
File attachments sent through iMessage are stored encrypted with AES on iCloud. The AES key is sent to the destination through iMessage and the AES key is encrypted with the destination RSA key.
There is a whole bunch of other interesting information on the protocol. Again, read the original blog post describing it.
So how can an MITM attack be performed? The first two scenarios described essentially requires an attacker to compromise one or both iOS device in a conversation. This isn’t really interesting, it should come as no surprise that any fancy encryption measures go out the window when an attacker is able to access the private keys stored on a system. The last two attacks described are more interesting, so let’s take a look at them in more detail.
MITM by replacing Apple
The blog post notes that this scenerio requires the attacker to possess huge resources.
- Huge network control to redirect the traffic of the iDevice (through DNS or whatever).
- Verified PUSH and ESS certificates, for each target.
If an attacker manages to fulfill the requirements, the MITM attack is very straightforward. Since the attacker is sitting in the middle of the network, he is able to modify all data sent and received. This includes the RSA/ECDSA keys used to encrypt and sign the iMessage. This is obviously beyond the means of your conventional attacker. This however, bring us to the next point.
MITM being Apple
Apple is in a perfect position to carry out the MITM attack. Apple owns the CA used to sign the certificates. All traffic is going through Apple’s PUSH and ESS servers. Apple can tamper with the RSA/ECDSA keys sent to each iDevice as Apple see fit.
So why is this not a big deal? While interesting, the information revealed basically boils down to one fact. Whoever controls your key infrastructure controls your encryption. Big whoop. This is not new. This is essentially the same problem the SSL/TLS PKI system faces since a compromised CA can issue certificates for MITM purposes.
What iMessage does is offer users seamless encryption for messages sent between iOS devices. The encryption is very strong and requires huge resources to subvert. This protects your data from all conventional threats. If you are the target of an attacker with the resources needed to subvert iMessage, DO YOUR KEY EXCHANGE IN PERSON.
Again, this new information is interesting and very welcomed. Cryptographers have been calling for Apple to be more open about the iMessage protocol for ages. What we now know assures me that the protocol iMessage utilizes is solid. That’s good. Be sure to read the original blog post for much greater detail about the protocol!