Skip to content

Instantly share code, notes, and snippets.

@vqhuy
Forked from anonymous/iMessage.md
Created May 28, 2016 05:53
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save vqhuy/bd90bd3bc87465a5ccad450fafd8fc8c to your computer and use it in GitHub Desktop.
Save vqhuy/bd90bd3bc87465a5ccad450fafd8fc8c to your computer and use it in GitHub Desktop.
Apple iMessage - Deficient by Design

Apple iMessage – Deficient by Design


Apple iMessage uses MAC-less encryption with malleable ciphertext. That, however, is not the worst part, and neither are the small 1280-bit RSA keys.

The worst part is that iMessage uses an independent ECDSA signature key, which is not only "independent" due to being a separate/different key from the AES encryption key, but also due to not being involved in the encryption/decryption stage at all!

dodgetocat_v2 (source)

You might be thinking: "...But the ECDSA key is a signature key – it is not supposed to be involved in the encryption/decryption stage... And isn't having a separate encryption and signature key a Good Thing?".

That is what Apple engineers probably thought as well.

Unfortunately, iMessage's ECDSA tag can be trivially stripped from the ciphertext payload, and replaced with a rogue ECDSA tag. This tag replacement works because iMessage's ECDSA key does not participate in the encryption/decryption process, and also because iMessage's ECDSA signature is over attacker-exposed ciphertext and not plaintext.

What iMessage should have done


  1. Symmetric encryption must always be Authenticated Encryption. Apple should have used [AES-CTR + HMAC], AES-GCM, whatever — the mechanics would not have mattered as long as it was a strong AE or AEAD mode. This is a big fail for Apple (goes beyond mere oversight, IMHO).
  2. There is this not-very-new thing called ECIES, which stands for Elliptic Curve Integrated Encryption Scheme. It runs over the same ECDSA primitive that iMessage is already using (no need for RSA), and can be extended to multiple recipients.
  3. Let's assume that ECIES is not an option for iMessage for some reason. The symmetric encryption used by iMessage should have been AEAD, with sender's public ECDSA key used as Additional Data.

Thus the minimal design changes that iMessage could make would be to switch to AEAD symmetric encryption with sender's public ECDSA key as AD (payload-wise the ciphertext would get 16 bytes longer due to extra AEAD tag).

SecurityDriven.Inferno


The Inferno library provides AEAD, streaming AEAD, and ECIES crypto APIs for .NET.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment