negative zero

[Video] iMessage is a joke

2022 February 17

[apple] [crypto] [info] [messaging] [privacy] [tech] [video]

iMessage, touted as a private messaging app, is a joke when it comes to privacy and security. I explain three issues with iMessage's end-to-end encryption:

  1. iMessage's encryption is circumvented if iCloud Backup is enabled.
  2. iMessage uses weak encryption.
  3. iMessage is PITM-able.


The emoji used for the "I do not see it" meme comes from Google's noto-emoji set, licensed Apache 2.0.

All original content in this video is dedicated to the public domain. Additional third-party resources are not necessarily public domain, but they fall into one of two categories:

  1. They are public domain or licensed under a license which permits commercial use without attribution.
  2. They are copyrighted works which I have not licensed but which I believe I am using in accordance with fair use.

All Formats

Sources (in order)

  1. Apple. Privacy – Features.
  2. Apple. What does iCloud back up?, February 2021.
  3. Apple. iCloud security overview., October 2021.
  4. J. Vincent. Apple reportedly scrapped plans to fully secure iCloud backups after FBI intervention., January 2020.
  5. C. Hoffman. Apple's iMessage Is Secure … Unless You Have iCloud Enabled., July 2021.
  6. Apple. iMessage security overview., February 2021.
  7. Apple. How iMessage sends and receives messages securely., February 2021.
  8. M. Scott. Backdoors in NIST elliptic curves., October 2013.
  9. SafeCurves. Rigidity., October 2013.
  10. B. Schneier. Comment. In The NSA Is Breaking Most Encryption on the Internet., September 2013.

Additional Sources


Normally when it comes to non-free messaging apps like iMessage, I would simply say "The source code is secret, so we can't trust it" and be done with it. But with Apple's iMessage app, it's actually way worse than that. In this video I'm going to talk about why iMessage is an absolute joke when it comes to protecting your privacy. I'm not even going to get into issues like centralization, metadata, use of phone number as an identifier, or non-repudiability of messages; this video is all about how iMessage fails to properly protect message content.

1. iMessage is not end-to-end encrypted by default.

While iMessage technically uses end-to-end encryption by default with other iMessage users, it uses it in a way that's, by default, useless in the context of the ecosystem it inhabits.

Suppose Alice and Bob both have iPhones they've set up normally without any special configuration. Alice sends a message to Bob. Apple would have you believe that it can't read this message because it just does such a good job protecting your privacy. For example, here's what Apple's "Privacy Features" page has to say on the matter:

End-to-end encryption protects your iMessage and FaceTime conversations across all your devices. [...] [Y]our messages are encrypted on your device so they can't be accessed without your passcode. iMessage and FaceTime are designed so that there's no way for Apple to read your messages when they're in transit between devices. You can choose to automatically delete your messages from your device after 30 days or a year or keep them on your device indefinitely.[1]

There are some important weasel words here, namely "your messages are encrypted on your device" and "there's no way for Apple to read your messages when they're in transit between devices". I'll circle back to this later.

Let's look at how the process of sending a message actually works. (We'll assume there's no foul play aside from the specific issue at hand.) Alice encrypts the message with Bob's public key and sends it to Apple's server. As claimed, Apple cannot read this message while it's in transit between devices. Apple delivers the message to Bob, and Bob decrypts the message. So that's end-to-end encryption, right? The message was encrypted from one end, Alice, to the other end, Bob.

HOWEVER, in addition to the actual sending of the message, which, true to Apple's promise, is encrypted, Alice and Bob both upload an unencrypted copy of the message to the server where Apple can read it. This is because messages are part of iCloud Backup[2][3], which is enabled by default on iPhones and unencrypted, a choice that was likely made at the behest of the FBI.[4]

In order to actually prevent Apple from reading the message, both Alice AND Bob need to manually turn iCloud Backup off. It's not sufficient for Alice to simply disable iCloud Backup for herself; her contacts have to do it too.

To further confuse things, there are two backups: iCloud Backup and Messages in iCloud. Messages in iCloud does use encryption; however, if iCloud Backup is also enabled, the decryption key is stored in the unencrypted iCloud Backup, giving Apple access to your messages. The only way to avoid giving Apple access to your messages via your backups is to disable iCloud Backup.[5]

Let's look back at Apple's claims:

[Y]our messages are encrypted on your device so they can't be accessed without your passcode.

Your iCloud Backup is not "on your device"; it's on Apple's server, so this is technically true without invalidating the fact that you're giving Apple a plaintext copy of the message.

iMessage and FaceTime are designed so that there's no way for Apple to read your messages when they're in transit between devices.

Again, the key phrase here is "when they're in transit between devices". This statement conveniently ignores the unencrypted backup you make separate from the encrypted "in transit" step.

2. Bad crypto

But that's all only if you or your chat partner uses iCloud Backup, right? Let's go ahead and suppose that Alice and Bob have both disabled iCloud Backup and confirmed that the other has done the same. Now is iMessage end-to-end encrypted?

Yes... but let's take a look at the cryptography used in iMessage.

2.1. Weak crypto

From Apple's Platform Security guide[6][7], we can see that iMessage uses weak and outdated cryptography, such as 1280-bit RSA for encryption and SHA-1 for signatures. It also uses the NIST P-256 curve for signatures and sometimes for encryption. While NIST P-256 theoretically does provide sufficient strength, there is plausible concern that the NSA has some sort of backdoor or known vulnerability for the NIST P curves.[8][9][10]

Oh, and by the way, iMessage's encryption protocol, as described on its website, does not provide forward secrecy, meaning an attacker need only break Alice and Bob's suspiciously weak long-term private keys to compromise their entire encrypted message history.

2.2. Apple as keyserver

But let's assume for the sake of argument that the crypto is good, and we're confident that Apple and the NSA can't break the encryption. I'll even go ahead and throw in the assumption that all messages use encryption, rather than falling back to insecure SMS, and that there are no unknown backdoors hiding in the app's secret source code. If we assume all that stuff, surely there's no way for Apple to read Alice and Bob's conversation, right?


In order for Alice to send an encrypted message to Bob, she needs Bob's public key. Where does she get this public key? From Apple, of course. If Apple acts dishonestly, it can launch a person-in-the-middle attack, enabling it to read and/or modify Alice and Bob's messages to each other. While it is absolutely possible to protect against this type of attack, as other apps do with fingerprint or safety number verification, there is no option in iMessage to detect or prevent this attack. Instead, Alice and Bob must trust completely that Apple will choose to act honestly and not compromise their conversation.

3. Conclusion

In conclusion, while some privacy advocates praise Apple's iMessage for its use of end-to-end encryption, iMessage is actually quite a poor example of a private messaging app, and it doesn't even take appropriate measures to protect the content of users' messages.