iMessage Privacy

3.1 The client on the device

Each device has its own certificate, which is 1024 RSA with a CN=<Push GUID> (obviously, GUID has to be replaced with device's GUID). The client is MobileSMS / Message.app, 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]-courier.push.apple.com

• The client certificate, specific to a device, which is explained right after.

root@joker:~>> ps aux |grep apsd
root 90 0.0 0.1 2467868 8052 ?? Ss Thu09AM 0:06.06 /System/Library/PrivateFrameworks/ApplePushService.framework/apsd
root 20295 0.0 0.0 2432768 588 s003 S+ 3:08PM 0:00.00 grep apsd

root@joker:~>> lsof -p 90 |grep TCP
apsd 90 root 9u IPv4 0x667b30bc14a94f93 0t0 TCP joker.lan:65158->17.172.232.179:5223 (ESTABLISHED)

root@joker:~>> whois 17.172.232.179
NetRange:       17.0.0.0 - 17.255.255.255
CIDR:           17.0.0.0/8
OriginAS:
NetName:        APPLE-WWNET
NetHandle:      NET-17-0-0-0-1
Parent:
NetType:        Direct Assignment
RegDate:        1990-04-16
Updated:        2012-04-02
Ref:            http://whois.arin.net/rest/net/NET-17-0-0-0-1
OrgName:        Apple Inc.
OrgId:          APPLEC-1-Z
Address:        20400 Stevens Creek Blvd., City Center Bldg 3
City:           Cupertino
StateProv:      CA
PostalCode:     95014
Country:        US
RegDate:        2009-12-14
Updated:        2011-03-08
Ref:            http://whois.arin.net/rest/org/APPLEC-1-Z
...

0a                    >> Message Type
XX XX XX XX           >> Next Length
04 00 04 XX XX XX XX  >> Identifier (4 bytes)
01 00 14 XX .. .. XX  >> Topic Hash (20 bytes)
02 00 20 XX .. .. XX  >> Push-Token (32 bytes)
03 XX XX ...          >> iMessage payload

3.3 The iMessage IDs

From now on, we will refer to iMessage simply as IM. There are a lot of information involved at the IM layer:

• AppleID: as already explained, that is the very heart of an account for Apple.

• URI: same format as an AppleID, which is either an email address or a phone number. One AppleID can have several URI. When it is an email, it is verified with a link to click. When it is a phone number, they are authorized only from the SIM card.

• Push-Token: as explained earlier, it is used for iMessage to identify a device on which an URI is registered. As such, a Push-Token is unique for each URI used on a device.

3.4 Sending an iMessage

When a user wants to send an iMessage, he firstly provide one or several destination URI. Since the communication is end-to-end encrypted, it means either the devices directly exchange the needed keys, or there is a key directory involved somewhere.

There is actually such a directory, called ESS servers (dont ask us what ESS stands for, ask Apple). So, to retrieve the keys, the iDevice sends the following request to the server:

GET /WebObjects/QueryService.woa/wa/query?uri=tel:+33123456789
'Host': service1.ess.apple.com
'Content-Type': application/x-apple-plist
'x-id-cert': [Provision Certificate]
'x-id-nonce': [Random Nonce with Timestamp]
'x-id-sig': [Query Signed with Provision Cert.]

In this example, the iDevice wants to retrieve the keys for URI "+33123456789".

It is important to notice this request is signed with yet another certificate, called Provision. This certificate is generated client-side, and signed by the authority called Apple IDS DS-ID Realm CA during iMessage authentication. It is valid for one month.

The corresponding answer looks like:

{
  'push-token': [PushToken]
  'client-data':
  {
    'show-peer-errors': True,
    'public-message-identity-version': 1.0,
    'public-message-identity-key': [Public Keys Buffer]
  }
}

It is actually a XML plist. We converted it to JSON to make it more readable. In our example, there is only one identity returned. However, if the destination URI have several devices and registered accounts under his AppleID, the same information would be given for each of them.

The answer contains the Push-Token, well-known now. But it also carries a buffer full of public keys:

• One ECDSA (256-bit) used to verify the signature of messages sent by the destination URI on this device. That way, when the destination URI replies, we'll already have the ECDSA key to check the signature.

• One RSA (1280-bit) used to encrypt iMessage sent to the destination URI.

With both these keys, we can setup a secured (?) communication with the destination URI, and all the related devices.

3.5 The iMessage Payload

We finish our explanation of the PUSH protocol by providing an iMessage payload. Now, we will see what this payload is made of.

This payload is in an Apple specific format, called bplist (binary-plist). It is designed to embed serialized data as dictionary. Several kinds of data are defined, including the usual ones: NSString, NSNumber, NSDate, NSArray, NSData and NSDictionnary, and so on.

Here is an example of such a bplist:

D:   True
E:   'pair'
P:   <variable length binary data> (iMessage payload, deflate compressed)
U:   <128bit binary data> (iMessage UID)
c:   100
i:   <32bit integer> (messageId, same as in PUSH header)
sP:  mailto:tim_c@icloud.com  (sender URI)
t:   <256bit binary data> (sender Push-Token)
tP:  mailto:mark_z@facebook.com (receiver URI)
ua:  [Mac OS X,10.8.5,12F37,MacBookPro10,2] (sender OS and hardware version)
v:   1

The ua field is totally useless but is sent on every request, for Apple statistics?

Anyway, the P field is the IM payload. It is encrypted then compressed (yes, yes, encrypted first, compressed after). It is composed with the following keys:

(byte)     0x02          version?
(short)    ciphertext    length
(data)     ciphertext    RSA / AES-CTR data : ciphered with the RSA public key of the recipient
(byte)     signature     length
(data)     signature     ECDSA signature of <ciphertext> : computed with the ECDSA private key of the emitter

In cleartext, the data is also a bplist, which we called inner bplist:

p: array of URIs in the discussion group
t: iMessage text (for iOS)
v: version (1)
x: iMessage html (attachments, and style - for OS X)

Let's spend some lines on the RSA / AES-CTR data. This data is the actual message sent to the target (the URIs, the message itself, attachment if any). Let us describe how it is built:

1. Let's call ibplist the cleartext data.

2. A 16 random byte are generated to be the AES key.

3. The data is encrypted with AES in CTR mode, giving AES(ibplist)

4. The 128-bit key is put at the beginning of the output buffer

5. The 128-bit key and 808-bit of AES encrypted data are ciphered with RSA-1280 using a public exponent of 65537 and PKCS1 OAEP padding. It gives a 1280-bit buffer.

6. That buffer is then signed with the owner's ECDSA key.

The RSA key used here is the one retrieved from ESS server, as mentioned above.

<file
   name="<name>"
   width="<width>"
   height="<height>"
   datasize="<size>"
   mime-type="<mime type>"
   uti-type="<uti type>"
   mmcs-owner="<identifier>"
   mmcs-url="<URL>"
   mmcs-signature-hex="<signature>"
   file-size="<size>"
   decryption-key="<key>"
/>

4.1 Test protocol

As we have seen, the 2 main services for iMessage are the PUSH servers and the ESS ones. So, in order to perform any attack, we need to impersonate these servers. There are lots of ways to do that, from ARP spoofing to injecting BGP routes (if you can), but we simply keep playing with /etc/hosts, as for the PUSH proxy earlier.

Here are the tools we used:

• Python to be able to run following tools

• PushProxy with Quarkslab’s imessage-mitm.py handler to intercept iMessages

• Quarkslab’s ess-mitm.py to intercept and modify Apple ESS responses

• A DNS proxy software. We used dnschef.

From the crypto point of view, we added a root CA to the target keychain so that we are able to serve our own certificates with no complaint from the iDevice.

From there, we have all our tools running locally, we are ready.

4.2 One-sided MITM

Here, the attacker is between the sender and Apple's server, on sender's iDevice. Let's call the sender Dhillon, and the receiver Belinda. We will explain step by step how it is going on. An evil guy called Evil, is in the middle.

First, let's start with the emission of a message:

1. Dhillon writes a message to Belinda.

2. Dhillon's iDevice makes a request to ess.apple.com

3. Evil intercepts that request:

1. Evil requests from ess.apple.com Belinda's information (Push-Token, RSA and ECDSA keys)

2. Evil replaces Bel's RSA and ECDSA keys with his own

4. Dhillon sends his message to Belinda: it is encrypted with assumed Bel's RSA (Evil's actually) key, signed with Dhillon's ECDSA key.

5. Evil intercepts the IM payload:

1. He can decrypt it with his own key

2. He can alter it and recipher it with Belinda's real RSA key

3. Since he is on the device, he can use Dhillon's ECDSA private key to re-sign the message.

6. Belinda gets the message, it is properly signed and she can read it.

As everyone can notice, a very strong requirement here is that the attacker, Evil, gets access to sender's ECDSA private key.

Let's see now what is happening when Belinda is answering to the message:

1. Belinda writes a message.It is ciphered with Dhillon's RSA key, and signed with Belinda ECDSA key.

2. The message is sent to Apple Push servers, then to Dhillon's mobile

3. Evil intercepts that message:

1. Evil can decrypt the message as he has access to Dhillon's RSA private key.

2. Evil can change the message, and recipher with with Dhillon's RSA public key.

3. Evil signs the modified message with his own ECDSA key as Dhillon's believe it is Bel's (see step 3.2 in the previous description).

4. Dhillon receives the forged message:

1. He checks the signature with Evil's ECDSA key (believing it is Bel's): everything is fine.

2. He decipher the message with his own private RSA key.

Once again, in reception, there is a strong requirement: the attacker, Evil, needs to get access to the RSA private key.

4.3 Two-sided MITM

Now, we are thinking big: we want to perform a MITM on Dhillon and Belinda at the same time. So, we assume now that Evil is running his MITM on both Dhillon's and Belinda's iDevice.

As example, Dhillon is sending a message to Belinda:

1. Dhillon writes a message to Belinda.

2. Dhillon's iDevice makes a request to ess.apple.com

3. Evil intercepts that request:

1. Evil requests from ess.apple.com Belinda's information (Push-Token, RSA and ECDSA keys)

2. Evil replaces Bel's RSA and ECDSA keys with his own.

4. Dhillon sends his message to Belinda: it is encrypted with assumed Bel's RSA (Evil's actually) key, signed with Dhillon's ECDSA key.

5. Evil intercepts the IM payload:

1. He can decrypt it with his own key

2. He can alter it and recipher it with his own key.

3. He signs with his own key too.

6. The message is sent to APSN and delivered to Belinda's device.

Since Evil is now on both side, things are symmetric here, so let's go:

7. Evil receives the message on Bel's iDevice.

8. Evil deciphers the payload with his own RSA private key.

9. Evil encrypts the message with Bel's RSA public key.

10. Evil signs the encrypted message with his own ECDSA key, since he provided this key to Belinda presenting it as Dhillon's.

11. Evil delivers the message to Belinda

12. Belinda checks the signature, which is ok and appears to be from Dhillon (since it has been signed with Evil's key, which is Dhillon's ECDSA alleged key).

13. Belinda deciphers the message.

The main requirement here is for Evil to be, at the same time, in between Dhillon and Apple on on end, and Belinda and Apple at the other end. Still a strong requirement for most attackers, but we didn't need users' private keys anymore!

4.4 MITM by replacing Apple

Let us perform an excise assuming an attacker is able to replace Apple to perform the MITM. This assume huge requirements:

• Huge network control to redirect the traffic of the iDevice (through DNS or whatever).

• Verified PUSH and ESS certificates, for each target.

Clearly, not the many people have such capabilities. Maybe 3 letters agencies... Who knows.

How would it work? Like a classical MITM:

1. Evil gives his RSA and ECDSA to Dhillon

2. Evil gives his RSA and ECDSA to Belinda

3. When Dhillon sends a message, Evil can read it, change it and resign it before passing it to Belinda

4. When Belinda receives it, she deciphers the message with her RSA key, and check the signature with Evil's ECDSA key, even through she believes it is Dhillon's.

Since, Evil is really in the middle, things are the same when Belinda answers to Dhillon:

So, what are the requirements here:

1. For that to work, he needs a valid CA in the devices of the targets.

2. The attacker needs to redirect the traffic from both targets to himself.

3. He needs to provide keys to each target impersonating the other end of the communication.

Obviously, this attack is not realistic for the average attacker.

4.5 MITM being Apple, or why end-to-end encryption is not enough

Actually, not all attackers can fulfill the above requirements. But now, let's have a look at Apple's position there:

1. For that to work, he needs a valid CA in the devices of the targets.

   > Apple has such a certificate.

2. The attacker needs to redirect the traffic from both targets to himself.

   > Apple does not need to do that since all traffic is going anyway through the PUSH server.

3. He needs to provide keys to each target impersonating the other end of the communication.

   > Apple owns the key server, ESS.

So, definitely, Apple can perform the MITM, they just have to tamper with the keys the send to the targets. Then, you remember how iMessages are encrypted: a RSA key encrypts an AES key.

Since Apple can change the keys, Apple can then decrypt the AES key, and as a consequence, the content of the message.

Remember Apple's statement:

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.

So, yes, there is end-to-end encryption as Apple claims, but the key infrastructure is not trustworthy, so Apple can decrypt your data, if they want, or more probably if they are ordered to.

5.1 iMITMProtect

We have developed a simple Mac OS X application, iMITMProtect which hooks some functions involved on iMessage. The application is very simple / stupid:

• When Push-Tokens and keys are received, they are stored in a local database.

• Each time a token or a key is received, we look up for the corresponding URI in the database, and check it is the same or not. If not, Houston, we have a problem.

As soon as a jailbreak will be available, we will port it as a Cydia package.

5.2 iMessage over-encryption

If one considers iMessage as an insecure channel, the solution is to encrypt the data sent to that channel. Setting up such an encryption is not easy, even without considering the General Conditions of Use.

We cant say more on that now, except it is tricky!