iMessage Privacy

iMessage is probably one of the most trendy instant messaging systems. Apple presents it as very secure, with high cryptographic standards, including end-to-end encryption preventing even Apple from reading the messages. Is this true?


Here you can download our slides of the presentation we gave at HITBSecConf2013:

Quick answers

  • What we are not saying: Apple reads your iMessages.
  • What we are saying: Apple can read your iMessages if they choose to, or if they are required to do so by a government order.
As Apple claims, there is end-to-end encryption. The weakness is in the key infrastructure as it is controlled by Apple: they can change a key anytime they want, thus read the content of our iMessages.
Also remember that the content of the message is one thing, but the metadata are also sensitive. And there, you rely on Apple to carry your messages, thus they have your metadata.
Now, you can read the article or jump to end of the article where we summarized it.

1. Instant messaging eavesdropping

For years now, every time a new instant messaging service has risen, lot of people ask questions about its security. Remember BlackBerry orSkype at the beginning, they claimed to be encrypted thus secure, impossible to eavesdrop. Years later, answers are coming from everywhere to deny that [1] [2]. For people working in the security industry, this is not a surprise. It is the role of a government to ensure security of people, and governments need ways to eavesdrop dangerous people. The question is more ethic than legal, and deals with the power given to intelligence agencies.
Recently, Snowden's leaks showed it was even worst than what many people imagined: crypto standard backdoored, collusion with major companies, massive data collection, intrusion everywhere, ... Despite that context and the legitimacy for government to practice lawful interception, all companies involved tried to minimize their role, and used a simple excuse: we just followed the law. However, one company has claimed it was impossible for them to eavesdrop their own instant messaging, and thus they are unable to collaborate with US government, even if requested to do so.
After Snowden's leaks, Apple published a statement, called Apple’s Commitment to Customer Privacy. As questions were around for some time on iMessage, Siri or Facetime, they clearly answered [3]:
There are certain categories of information which we do not provide to law enforcement or any other group because we choose not to retain it. For example, conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them.Apple cannot decrypt that data.
According to that statement, Apple can provide some metadata (who sends a message to who, the date, ...) but the content of a conversation would be excluded. We will show in this article it is not true. Apple can get access to encrypted message, despite end-to-end encryption. Does it mean they do it? Only Apple and some 3 letters agencies can answer, we can not.
Now, let's go into the details of our analysis.

2. Lack of certificate pinning: so what?

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. We do not need to know what protocol is used or how packets are forged. The first thing we want to try when we see that is adding a certificate to perform a MITM. We were actually very surprised it worked as easily, which means there is no certificate pinning. We created a fake CA, and added it to the iPhone keychain. Then, we could proxify communications much more easily. When a SSL communication arrives to the proxy, we generate a certificate signed by the newly added CA, and everything becomes unencrypted.
Second surprise was actually bigger: we saw our AppleID and password going through this SSL communication. Yes, the clear text password... There can be a lot of good reason to send the password as cleartext, ssh does it for instance. But here, we dont see any reason for Apple to get our password.
Firstly, it means that Apple can replay our password using for instance our email also on many websites. Ok, Apple has no reason to do so. But what of intelligence agencies? Secondly, it also means that anyone capable of adding a certificate and able to proxify the communications can get user's AppleID and password, thus get access to iCloud accounts, backups, buy apps, ....
Here is an example of what we get:
POST /WebObjects/VCProfileService.woa/wa/authenticateUser
'content-length': 223,
'accept-language': en-us,
'accept-encoding': gzip,
'content-encoding': gzip,
'accept': */*,
'user-agent': [Mac OS X,10.8.3,12D78,Macmini4,1],
'connection': keep-alive,
'x-protocol-version': 7,
'content-type': application/x-apple-plist,
'x-ds-client-id': t:3A5DC02C47249FC50EF0FF1B8CF3073C9EBD0668
And here are content of posted data:


Icandoaproperkeynote username We tried to play with the certificates for a while. We came up withiPhone Configuration Utility. This software is Apple's solution for enterprise to manage their iPhone. When this software is used for the 1st time and a device is plugged, a CA is added to the device. MDM administrators can do this transparently to enrolled devices
static/resources/2013-10-17_imessage-privacy/images/cert_verified.pngThe consequence is that in a company where iPhones are managed by IT, they wan setup a proxy and invisibly proxify communications from / to the iPhone, thus gain access to very personal information. Note the certificate pinning is not performed at any layer, PUSH or iMessage, so various problems can happen here and there.

3. The protocols: the client, PUSH & ESS servers

In this part, we will describe the usual process, with all the protocols and cryptographic steps involved.

3.1 The client on the device

Each device has its own certificate, which is 1024 RSA with a CN= (obviously, GUID has to be replaced with device's GUID). The client is MobileSMS /, but this application also relies on other services. The 2 mains are:
  • apsd: the Apple PUSH server daemon, in charge of carrying the messages from Apple to the devices.
  • imagent: the background process for iMessage tasks, like keeping connection when app is closed, etc.
When a message is sent to someone, Apple is in charge of transporting the message. It means 2 things:
  • Given a destination address (an URi, it can be a phone number or an email for instance), Apple has a way to link it with all devices related to that URI (iPhones, iPads or OS X systems).
  • Once Apple knows all the devices involved, Apple brings the message to the proper devices.
Let's start with the second point, the transport protocol, called PUSH.

3.2 The PUSH protocol

PUSH protocol [4] has been designed as a remote notification protocol over networks. It is used for iMessage of course, but also for FaceTime, GameCenter or by send party application when they want to notify of an event. Think about Facebook, Whatsapp or any news application notifying you than something just happened. Each time, it is based on the very same protocol, PUSH.
Here is how Apple defines it:
Local and push notifications are great for keeping users informed with timely and relevant content, whether your app is running in the background or inactive. Notifications can display a message, play a distinctive sound, or update a badge on your app icon.
PUSH behaves as a transport protocol, in charge of delivering a payload, whatever it is, to set of devices. Hence, iMessage itself is a payload in regard of the transport protocol.
All PUSH communications are made in TLS to server port 5223 when it comes to iMessage:
  • Hostnames are taken from [0, ..., 255]
  • The client certificate, specific to a device, which is explained right after.

The client certificate

The PUSH certificate is generated when the device is registered and activated at Apple. During the 1st connection to Apple's server, a certificate request is sent to This server runs a certificate authority, called Apple Iphone Device CA, in charge of signing every request.
This certificate is very sensitive as it is the one in charge of ALL PUSH communications from the device: PUSH communications are secured with it, with both client and server authentication.
As such, this certificate is not directly involved in iMessage, but since iMessage is carried over PUSH, it has a role to play anyway.

The Push-Token

From the PUSH layer, how it works is kind of magic known only by Apple. From client side, here is what we see. First, we write a message, and press the send button. Doing so, the client requests from Apple's ESS servers the information needed to send the message. The ESS Server sends back 3 pieces of information:
  • A Push-Token, which is a unique identifier for a pair iDevice.
  • Two cryptographic keys we will describe right after.
The Push-Token is computed by Apple when a device registers to the service. The generation of the Push-Token is defined as opaque by Apple since it is made server side, same goes for its precise usage. For now, we see it as the registration of a provider and a routing information.
As a provider as one needs to register itself as a iMessage provider, but also as a routing information as Apple needs to know where to deliver the messages. As a matter of fact, Apple fanatics users often have more than one device, and a iMessage must be delivered to all the devices at once.
So, when the client sends one message, it actually sends as many messages as the recipients has Push-Tokens, so that the message can be delivered to each iDevice. These messages are sent to the Apple Push Network Service (APNS) through a gateway on port 5223 as explained earlier.

By Cyril Cattiaux
Source and read more:

0 yorum: