2014 Apple iMessages security update

A few days ago I made the following tweet:

I’d like to apologize for the wording of that, as it could have been written in a more accurate way.

To help clear up any confusion, I spent the past day or so diving into the nitty-gritty details of Apple’s iOS Security Guide from October 2014. Big thanks to Nate Cardozo of EFF for linking me to it.

The tweet I should have made instead is:

While Apple’s iMessages are designed to be “end-to-end encrypted”, Apple can still read them (if they wanted to).

That is not news. On October 17th, 2013, Quarkslab published iMessage Privacy, where they stated (correctly) that:

Apple can read your iMessages if they choose to, or if they are required to do so by a government order.

This is because Apple owns and operates the infrastructure that distributes the public keys between phones. At any point in time they are capable of giving out a public key of their invention (not belonging to the intended recipient), and decrypting/re-encrypting your messages as you send them to your friends and family.

A separate and more concerning issue was pointed out by Ars Technica a few months prior: if you enable iCloud backups, Apple will encrypt your data with keys that they generate themselves instead of using a key that’s based on your password (which they do not know). This is why Ashkan Soltani was able to restore his iMessages onto a completely different iPhone after resetting his iCloud password and answering Apple’s iForgot security questions.

Update July 27, 2015: A third issue, perhaps the most severe, is  Apple’s use of weak encryption, only 1280-bits!

Has anything changed since then?

After reviewing Apple’s 2014 October iOS Security Guide, unless I am misreading something, the answer appears to be: Nope.

Below are some choice screenshots from my annotated copy.

iMessages security (in transit)

Here Apple describes how their IDS and APN services act as MITM between users for the purpose of public key exchange and message delivery. As long as these services are honest, the communication actually is end-to-end encrypted. There’s nothing in the protocol forcing Apple to be honest, however.

iMessages security (when backed up to iCloud)

On the matter of iCloud backups, we have the following (for the infosec crowd; skip below if you find it overwhelming):

Screen Shot 2014-11-08 at 9.41.52 PM

Screen Shot 2014-11-08 at 9.42.43 PM

This gobbledygook says that for iCloud backups data like iMessages gets encrypted with Apple’s keys (not yours), while keychain entries (wifi passwords, credit cards, iMessage private keys [not messages], etc.) are stored in a way that (allegedly) Apple cannot read because it’s tied to a password (a “UID”) that Apple creates for each phone upon manufacture (but claims to not know). The iMessage keys are used for the so-called “end-to-end” encryption when sending data between phones. They are not used to encrypt the messages stored on the phone, nor the messages stored in iCloud.

Conclusion & Recommendations

It should be emphasized that Apple has gone to noble lengths to protect your data.

The technical shortcomings described above do not imply any sort of intentional failure or sneakiness on Apple’s part. IMHO, Apple has done fairly well (within the confines of a centralized system) when it comes to balancing communications security with easy of use. The award for “the best” job still goes to the Signal/TextSecure team. Apple’s iCloud backups, however, should be encrypted with the user’s keys, not Apple’s (at the very least this should be an option). Nate points out that Apple provides a way for users to delete old iCloud backups.

To address the rest of the shortcomings, we suggest that Apple (and other companies) explore decentralized key distribution mechanisms (like okTurtles’ DNSChain). Such mechanisms don’t require fingerprint verification between users and therefore would preserve the fantastic user experience that Apple is known for, while simultaneously protecting both Apple’s users and Apple itself from forms of coercion (like National Security Letters) that destroy Apple’s “end-to-end” encryption.

Apple should also be commended for the steps they’ve taken to be more transparent about the security of their systems. I enjoyed reading their iOS Security Guide and felt they did a fantastic job with it. Props to the team that made that happen! 🙂

A final remark: if Apple is to receive any criticism, it shouldn’t be for any technical shortcomings, but instead for the following misleading marketing claim on their website:


My thanks to Nate Cardozo, Simon de la Rouviere, Filipe Beato, and Bob for reviewing this post.

Leave a Reply

Your email address will not be published. Required fields are marked *