Attack of the Week: Apple iMessage

If you're struggling to understand the impact of this iMessage flaw, remember that it requires either a Root CA or Apple's help to work. If you're considering an attacker with access to a Root CA, then you have problems far beyond iMessage crypto.

It is certainly a good defense-in-depth measure to implement the recommendations from JHU and it's great that Apple has moved aggressively with them. Those mitigations will protect even from a catastrophic "goto fail"-type bug in the future where you could strip away TLS.

That leaves Apple cooperating with law enforcement (or an Apple insider, coerced or otherwise) to launch this attack against one of their users. I think this scenario is unlikely given their very public reaction to the iOS 9 backdoor the FBI requested.

Finally, I think their development of the gzip oracle is pretty great and that it has the potential to work against other cryptosystems. This is probably not the last that you'll hear of it. I suspect the JHU team is running down a list of other cryptosystems that it could work against right now...

The Cryptographic Doom principle strikes again! http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...

The article refers to it more precisely as "similar to the padding oracle attack discovered by Vaudenay", but this root problem -- malleability -- keeps coming up so often even in relatively mature attempts at crypto that the appeal-to-emotion "Doom" name seems worth using.

Direct link to the paper (since it's a bit hidden in the blog post): https://isi.jhu.edu/~mgreen/imessage.pdf

So the setup is... All iMessage has to start with is some unspecified sender who has your public key and wants to send you a message. Sender will RSA-OAEP a random key to the receiver's public key, but then for some reason they are doing encrypt-then-sign, which doesn't really accomplish much because an attacker can just substitute their own signature.

The receiver can't know where the ciphertext they are being sent actually originated.... Just strip the signature from the original sender, add back your own, keep the RSA-OAEP blob which is holding the encryption key as-is, and then start tampering with the AES-CTR ciphertext. Having found an oracle (a way to know if decryption succeeded or not) in the attachment download code, it was just a matter of the hard work of making the bits dance just right to use the oracle to deduce the key.

In this attack the RSA-OAEP encrypted nonce is left alone. The fix they propose at the end is to cache this part of the message for a while to not allow replay. But I don't understand... why not instead derive authentication and encryption keys from the random 'k' and use it to append a MAC to the AES-CTR ciphertext, like an IES?

Given RSA-OAEP is "IND-CCA2", it is not vulnerable to chosen cipertext. That means it's "safe" to touch the RSA and decrypt before authenticating anything. At that point you then have enough to generate an authentication key to run an HMAC on the "hot" AES-CTR ciphertext before proceeding any further. I guess the obvious appeal of just caching the RSA'd 'k' to prevent replay instead of something like this is that neither the crypto nor even the message format have to change.

Alternatively, what you see in X25519, is the sender generates an ephemeral keypair and does ECDH with their private key and the receiver's public key to get a shared secret. Sender can then use the shared secret to do any standard authenticated symmetric encryption they want. Receiver will need the sender's ephemeral public key on their end to ECDH the same shared secret. In this case, again, as long as the asymmetric crypto is IND-CCA2 the receiver can safely figure out the shared secret and an authentication key before they have to touch any hot sauce.

Actually pulling of a working exploit with 2^18 messages while having to mangle ciphertext and keep gzip happy is really impressive! But at the same time, encrypt-then-sign with no MAC obviously will fail given an oracle, and oracles will always exist. So.... why did Apple do it this way, and why not just fix the underlying crypto and instead hack around with anti-replay?

> ...attacks on a key server seem fundamentally challenging to implement -- since they require the ability to actively manipulate Apple infrastructure without getting caught.

Tell that to Belgacom [1]! If the NSA can tap the inner networks of Google's fibre connections as they traverse the Atlantic, then they can infiltrate Apple whilst juggling chainsaws.

Apple are probably the market leader in branding. Their hardware is top notch but their services are flaky and feel hacked together.

That doesn't bode well when it comes to securing message protocols and networks. In addition, much of Apple's services run in the cloud on Microsoft Azure and Amazon AWS. I doubt we can consider then safe havens from the snooping, driving, hacking five eyes.

[1] https://theintercept.com/2014/12/13/belgacom-hack-gchq-insid...

I'd be over the moon if iMessage turns cross platform and adopts Signal/Axolotl under the hood. iMessage UX is much better than Signal's and it just works.

a little bit tangential, but is it known how received imessages are able to be decrypted on multiple devices?

if the sender's message encryption key is encrypted with my iphone's public key, then my iphone's private key is the only key that can recover the the key used for the message.

so then how can desktop imessage also recover the key and decrypt the message? it seems like either: * private keys are shared between devices (doesn't seem good) * imessages are encrypted multiple times based on the number of registered devices the recipient has (plausible?)

Attack of the week on Monday, huh...

i think this was put in there on purpose