iMessage

Apple claims to be resisting a court order to decrypt iMessages in real time. They claim it’s a technical impossiblity. This claim deserves a closer inspection. Page 35 of Apple’s Security guide states the following:

Apple does not log messages or attachments, and their contents are protected by end-to-end encryption so no one but the sender and receiver can access them. Apple cannot decrypt the data.
iMessage connects to Apple’s IDS directory service (key distribution server) and Apple Push notification server (IM server) over TLS DHE. The following diagrams show how keys used in end-to-end encryption are exchanged:

1. IDS delivers client the public keys of contact
11 - iMessages KE overview2. APN delivers signed and encrypted messages:
12 - iMessages COM overview cropThe messages are encrypted with unique 128-bit AES keys, encrypted with 1280-bit RSA keys. Data is signed with 256-bit ECDSA (Nist P-256 curve). The 1280-bit RSA has the computational complexity of 289.46, which is way below current recommendation (2128). In fact, RSA-1280 is almost a hundred times weaker than legacy standard level of ECRYPT (296) evaluated to be secure until 2020. So there’s a possibility that the encryption keys are within computational reach of HSAs, if not now, perhaps in the near future.

What’s worse than crypto dragging behind standards, is it turns out the implementation of end-to-end-encryption (E2EE) in iMessage is insecure by design. Matthew Green recently wrote a great article about this, so I’m keeping the explanation short.

Above, the quote from Apple stated they “cannot decrypt data.” This is only a half-truth, as Apple decides what encryption keys you use to protect those keys, that are used to protect your messages. This is in direct conflict with Stef’s 7 rules to detect snake oil:
#4 “The user doesn’t generate, or exclusively own the private encryption keys”
I should note that iMessage is also in violation of
#1 “Not free software”
#3 “Runs on a smartphone”
#5 “There is no threat model”
#7 “Neglects general sad state of host security”
but the #4 is in my opinion the most important. User will have to rely on blind faith, that the client is using the actual public encryption key of the contact to encrypt symmetric key, and also that the public ECDSA signature verification key belongs to the contact. Under an NSL, Apple might be coerced into performing the following attack:

1. Server is coerced to send public encryption and signing keys of attacker instead of contact’s.
13 - iMessages KE server compromise2. Once the public keys have been distributed, here’s how the MITM attack takes place when Alice sends message to Bob (the reply from Bob is the exact mirror of this process, so it was left out from the already huge scene):
14 - iMessages communication server compromise crop
I should also mention, that a DHE MITM with the server or CA private key allows the HSA to pose as the IDS and APN servers. So iMessage users might be under MITM attack by HSAs even if they had ever approached Apple.

The standard approach to solve this simple MITM attack is to compare the fingerprint of public signing key via off-band channel, where the intergrity of data is guaranteed. iMessage does not have the fingerprint checking feature, so there’s no way to detect MITM attacks.

tl;dr? Vote with your feet.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s