Apple can intercept iMessages

New research has revealed Apple was not completely honest when it claimed it could not intercept iMessages sent by users.

While there was no evidence the technology giant had actually intercepted iMessages, the research demonstrated some cryptographic and certificate weaknesses in the service that made man-in-the-middle attacks possible.

The flaws centred on a discovery Apple kept secret - that public keys were managed on a server called ESS and unlike other systems could not be not publicly inspected.

That left open the possibility for interception of iMessages by Apple or any entity with access to Cupertino's infrastructure.

Apple billed iMessages as an alternative to SMS and recommended users concerned about potential eavesdropping by the US National Security Agency use the PKI service.

That recommendation came on the back of allegations within documents leaked by former US contractor Edward Snowden that Apple had joined a laundry list of the world's biggest technology companies who were complicit in providing the NSA access to their technology platforms for spying purposes.

Apple said in response it could not access iMessages, a claim disproven in the research given at the Hack in the Box conference in Malaysia this week.

"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," Apple said in a statement still live on its website at the time of writing.

Quarkslab researchers Cyril Cattiaux (@pod2g) and his partner, known publicly as 'gg', were working with Apple ostensibly to help it amend the issues.

"Apple's claim that they cant read end-to-end encrypted iMessage is definitely not true," the pair said.

Should Cupertino make its protocols transparent, iMessage could be "considered the most practical and secure real-time messaging system available", the researchers said in analysis.

An important lesson for companies: don't oversell the security capabilities of your product. Someone will take it apart to check your work.

— Matthew Green (@matthew_d_green) October 17, 2013

They noted that performing man-in-the-middle attacks was possible only by well-resourced state agencies, and the encryption algorithms used were strong AES, ECDSA and RSA.

Even as it stands, the researchers said users should stick with the platform unless they were concerned of government interception or, they joked, were discussing zero day within Apple kit.

They pointed out that iMessages did not use certificate pinning -- which would tell devices to trust a given certificate -- for PUSH and iMessage servers, allowing a fake certificate authority to be added to the user keychain.

The research duo also found that Apple iCloud passwords were sent in cleartext without good reason.

"Firstly, it means that Apple [and intelligence agencies] can replay our password using for instance our email on many websites. Secondly, it also means that anyone capable of adding a certificate and able to [proxy] the communications can get user's AppleID and password, thus get access to iCloud accounts, backups" and app purchasing.

This led to the possibility that enterprise IT managers, when assigning Apple devices with mobile device management platforms, could intercept sensitive Apple user account details including iCloud usernames and passwords.

"If the device is connected to iPhone Configuration Utility, Apple's enterprise solution for management of iPhones, a trusted CA (Certificate Authority) is added. Consequence is that all subsequent certificates signed by that CA will be trusted to create the SSL communication. It means all companies using that are able to retrieve their employee's AppleID and password by simply [proxying] the SSL communication."

Detailed analysis was available in the researchers' slides and blog. (pdf)

In brief:

• Involved cryptography is based on well-known algorithms (AES, RSA, ECDSA) with proper key sizes and implementation.

• Code in charge of key generation is open source.

• No certificate pinning is performed between client and PUSH servers (Apple's servers involved in iMessage).

• Authentication between client and Apple's servers is protected with strong obfuscation and whitebox cryptography, preventing the development of third party iMessage clients.

• User password is sent cleartext through a secure SSL channel to Apple. This is clearly an issue for people using the same password at several places (mail, bank, whatever) as Apple knows this password.

• No pinning + cleartext password means that if somebody manages to add a certificate in a device, he can perform a MITM, thus get the user's AppleID and password. That is the key to everything belonging to the user.

• iMessage is carried over Push protocol, the very same protocol used but FaceTime, GameCenter or notification services.

• PUSH is tunneled inside SSL to Apple's PUSH servers on port 5223.

• Every Apple device is identified by a unique Push-Token.

• When someone sends one message, the client looks for all Push-Tokens related to that destination (called an URI) to transport the message to every device where the URI is registered.

• When one sends an iMessage, the client firstly connects to an Apple key server, called ESS, to get the target public keys.

• The clients retrieves 2 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.

• The iMessage payload is actually a binary plist, designed to embed serialized data as dictionary.

• The iMessage payload is encrypted with a random AES key, the key is appended at the beginning of the encrypted payload, the 1280 first bits are encrypted with destination RSA key.

• Every message is signed with sender ECDSA key.

• iMessage can be used to send attachment. They are stored on iCloud, encrypted with an AES session key as explained above.

• Since Apple controls ESS servers, and all iMessages are routed to Apple's PUSH servers, Apple is able to perform MITM: Apple sends fake public RSA / ECDSA key to the sender. Apple can then decipher, alter the payload of the message and sign it before sending to its final destination.

• There is end-to-end encryption as Apple claims, but 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.

Copyright © SC Magazine, Australia