Don't Trust iMessage's Cryptography
2021 July 31
When it comes to privacy, Apple is good at lip service. It can even be convincing. Some privacy advocates recommend Apple's iMessage as an end-to-end encrypted messenger due to its ease of use.
Despite this, iMessage is not a good example of an encrypted messenger.
Scope
This post is about iMessage's crypto model. It won't get into other iMessage privacy issues, like that Apple can collect metadata about use or that users are required to identify themselves by their phone numbers. I just wanted to focus on the reasons not to rely upon iMessage's crypto.
This post will not try to detail every issue iMessage has ever had. I'm writing this on 2021 July 31, and I will focus on the things I believe are major issues at the time of writing.
Do we trust Apple?
The point of end-to-end encryption is that it enables us to use infrastructure without trusting it.
If we trust Apple with our messages, there's no point in using end-to-end encryption. Transport encryption is sufficient in that case.
Let's assume from here on that we do not trust Apple (or any other service provider).
With that trust model in mind, let's talk about iMessage's cryptography model.
Problem #1: iMessage's "end-to-end" encryption is circumvented by default.
By default, Apple has access to all messages, thus rendering the end-to-end encryption meaningless. I wrote about this yesterday.
Mitigation?
To disable this key escrow, users must disable iCloud Backup (not "Messages in iCloud") and convince all of their contacts to do the same.
Problem #2: Apple distributes the public keys
Users obtain each other's public keys directly from Apple. This gives Apple the power to provide false keys and PITM or add additional parties to chats, fundamentally defeating the end-to-end encryption.
I don't have access to an Apple device to confirm how anything works, but from what I can tell, there's no way for users to verify each other's keys or reject invalid ones, so there's no way to defend against this.
Update 2022 February 16: I looked at iMessage on an iPhone and confirmed that there is no way to view, verify, or reject a contact's public key.
In other words, iMessage's end-to-end encryption (which, again, only matters if we distrust Apple) requires us to trust Apple.
Mitigation?
none
Problem #3: iMessage's crypto is weak
Algorithms
If you don't want to know the technical details, just jump down to my interpretation.
Take a look at the iMessage security overview and How iMessage sends and receives messages securely. At the time of writing, Apple reports that iMessage uses:
- 128-bit AES-CTR based on an 88-bit random value
- 1280-bit RSA to encrypt the AES key
- Newer devices (iOS 13+, iPadOS 13.1+) "may" use ECC (NIST P-256 curve) instead. These pages don't specify how this decision is made.
- SHA-1 and ECDSA (NIST P-256) for signatures
(The other 40 bits come from an HMAC (refreshingly, using SHA256) of the two users' public keys and the message plaintext, and this value is used by the receiver to verify the message's integrity. I'm not clear on the key strength implications of including a MAC of the message as part of the key.)
Let's see what NIST recommended in 2020...
- For symmetric key algorithms, the minimum strength recommended is 112 bits, and 80 bits is "no longer approved for applying cryptographic protection on federal government information" (pages 54-55).
- For RSA, minimum recommended strength is 2048 bits, and 1024 is deprecated (54-55).
- For ECC, 256 bits is actually good (54-55), but I'll talk about the NIST P curves later.
- SHA-1 is deprecated for applications like digital signatures (56).
NIST P curves
NIST selected its P curves in a way that is not obvious or transparent. It is believed that the USA government intentionally chose curves with known vulnerabilities.
See, for example, SafeCurves: Rigidity and Bruce Schneier's comment on ECC:
I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry.
Interpretation
All parts of iMessage's cryptographic protocol are weaker than they should be in 2021.
Lack of forward secrecy
At the time of writing, Apple reports that when Alice sends Bob a message, she generates a new AES key, then encrypts it with Bob's public key.
Importantly, this scheme does not provide forward secrecy; an attacker who learns Bob's private key can go back and decrypt all the messages that have ever been sent to Bob.
Non-repudiation
When Alice sends Bob a message, she signs the message with her own private signing key, making the message non-repudiable. This isn't necessarily a problem, but it's worth knowing: iMessage does not provide cryptographic deniability. iMessage is not "off-the-record".
Mitigation?
none
Problem #4: iMessage's encryption is opportunistic
iMessage can only send encrypted messages when all parties are iMessage users and the sender is online. If you try to send a message to a non-Apple phone or while you're offline (but have cell reception), messages will be sent unencrypted over SMS.
Mitigation?
It looks like there's an iMessage setting for "Send as SMS" which you can disable. Of course, doing so will stop your phone from performing what might be an essential function.
Problem #5: iMessage's code is a secret
iMessage, like everything Apple, is extremely proprietary. No, you may not look at the code. No, you may not think about the code. It's definitely secure. Trust us. Don't think, just consume.
Whether or not I personally have the technical skill to understand how it works, I don't trust anything that I'm forbidden to study and understand.
Mitigation?
none
Conclusion
iMessage is bad. Use something better.