Investigating iMessage security and privacy claims

How secure and how private is iMessage, Apple's SMS/MMS-like communications platform? Earlier this month, after news broke about the NSA's electronic surveillance program, codenamed PRISM, Apple released a statement (opens in new tab) detailing some specifics on the number of requests they receive from government agencies for customer records. As part of the statement, Apple claimed that iMessage conversations use end-to-end encryption and therefore cannot be decrypted by Apple:

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.

Matthew Green, cryptographer and research professor at Johns Hopkins University, has raised some important questions about these claims, based on what little information is publicly available about iMessage encryption. In a post on his Cryptography Engineering blog, Green writes:

And that's the problem with iMessage: users don't suffer enough. The service is almost magically easy to use, which means Apple has made tradeoffs -- or more accurately, they've chosen a particular balance between usability and security. And while there's nothing wrong with tradeoffs, the particulars of their choices make a big difference when it comes to your privacy. By witholding these details, Apple is preventing its users from taking steps to protect themselves.

The first point Green raises is that iMessages are backed up and can be restored to a new device. If iMessages can be restored to a new device, then the encryption key can't be locked to the device. You can also read messages after resetting your password, meaning that the data must not be encrypted with your password either. This makes it unlikely, if not impossible, that the keys used to encrypt the stored messages are not possessed or recoverable by Apple.

Ultimately, there's no way for a person to know that messages are being encrypted with the correct public key to ensure only the intended recipient can decrypt them.

Green's second point has to do with how Apple distributes iMessage encryption keys. If you send another person an iMessage, it is encrypted using their public key. They can then decrypt the message using their private key. However, you have no way of knowing whose public key you're receiving from Apple to encrypt the messages. For instance, Apple could theoretically have you encrypt the messages with their public key, in which case, Apple could decrypt the message being sent with their private key. This isn't a particularly likely scenario as such an act, once discovered, would destroy any goodwill users have with Apple in entrusting them with their privacy. Although, a third party could also do the same if they had access to Apple's systems. Ultimately, there's no way for a person to know that messages are being encrypted with the correct public key to ensure only the intended recipient can decrypt them.

The third issue raised is Apple's ability to retain metadata. Even if all of the contents of your iMessages are securely encrypted, Apple's statement says nothing about protecting the metadata of those messages. This metadata would show who you talked to at what time, and possibly other seemingly innocuous details. While many people don't find this too concerning, an alarming number of details can be gleaned from this type of metadata. Without Apple addressing it in their statement, it remains unknown how this metadata is protected, if at all.

Finally, while iMessage does make use of SSL to encrypt communications with Apple's directory lookup service, it does not employ certificate pinning. SSL helps guarantee that communications are encrypted between the client and server. However, without certificate pinning, there is no assurance as to the identity of the server. It is not unheard of for valid SSL certificates to be forged, making it possible for malicious third parties to perform intercept traffic. Certificate pinning works by explicitly telling an application which SSL certificate should be trusted, rather than trusting any certificate issued by a trusted certificate authority.

This doesn't necessarily mean you should stop using iMessage.

This doesn't necessarily mean you should stop using iMessage. Many electronic communication methods, such as email, don't offer any sort of encryption by default. iMessage's encryption, at the very least, offers protection from casual eavesdroppers or criminals looking to capture your information. The points outlined by Green mean it could be possible for Apple, and in-turn law enforcement agencies, to decrypt communications sent over iMessage.

Unfortunately, it's difficult to know anything more specific without Apple providing more details on how they secure these communications.

Source: Cryptography Engineering

Nick Arnott
  • If I remember correctly, the Messages encryption key is stored in your keychain, which is encrypted with your password. When you change your password, your keychain is unencrypted and re-encrypted with the new password. So this explains the first issue. I believe it works similarly to FileVault disk encryption in MacOS X - the actual key is horribly long, but it is stored in your keychain, so you can boot the Mac with just your account password.
  • You may be missing part of the first point - the strength of the private key is irrelevant if somebody else is in possession of that key. The article posits that, if Apple is able to backup and restore iMessages, or transfer iMessage data/functionality from one iOS device to another newly purchased one, that they must also be in possession of your private key, or some other means of encrypting/decrypting your data. Just having your public key would not be enough for Apple to do what they do for us there.
  • Apple can backup/restore the encrypted contents and they would be unusable until decrypted on the destination device. It's also possible to move keys between devices in a secure fashion where Apple still wouldn't know what the private key is. However Apple has not explained if they are doing this, or by what methods, so it's not possible to tell if they're doing it in a secure fashion. 1Password, for example, can keep your passwords encrypted and still use Dropbox to sync them between devices. Neither 1Password nor Dropbox are able to decrypt those keys (1Password has made public enough information about their methods that this can be verified.)
  • In the case of 1Password, the key is stored in a place that is nominally under the user's control.
  • the 1password key is stored in the dropbox sync along with the passwords. The key is encrypted with your master password. Most likely Apple does the same thing, however as Nick notes below, with Apple you can can change your password via their forgotten password process for your Apple ID. Since you lose no data in this process they most likely have a recovery key associated with the account.
  • I think one noteworthy difference is that 1Password can't help you if you forget your master password.
  • I always thought that private/public key encryption worked as the public key was distributed to anyone and used only to encrypt the message. the private key was kept by the user and used to decrypt the message.
  • Right you are! Thanks for pointing that out. The article has been updated to correct that.
  • Wouldn't the private key be stored as an asset associated with the AppleID? Maybe Apple set up some multi-layer encryption technique, similar to onion routing, which means that even in a AppleID password reset its impossible for them to see the deeper layers?