The paper is called "Dancing on the Lip of the Volcano: Chosen Ciphertext Attacks on Apple iMessage" by Christina Garman, Matthew Green, Gabriel Kaptchuk, Ian Miers, and Michael Rushanan, Johns Hopkins University.

Abstract:

> Apple’s iMessage is one of the most widely-deployed end-to-end encrypted messaging protocols. Despite its broad deployment, the encryption protocols used by iMessage have never been subjected to rigorous cryptanalysis. In this paper, we conduct a thorough analysis of iMessage to determine the security of the protocol against a variety of attacks. Our analysis shows that iMessage has significant vulnerabilities that can be exploited by a sophisticated attacker. In particular, we outline a novel chosen ciphertext attack on Huffman compressed data, which allows retrospective decryption of some iMessage payloads in less than 218 queries. The practical implication of these attacks is that any party who gains access to iMessage ciphertexts may potentially decrypt them remotely and after the fact. We additionally describe mitigations that will prevent these attacks on the protocol, without breaking backwards compatibility. Apple has deployed our mitigations in the latest iOS and OS X releases.

Paper (PDF): https://www.usenix.org/system/files/conference/usenixsecurit...

Based on the paper, the title should include "WAS" or "FIXED" or something like that.

And in a side note, that's why I dislike that journalists have been trained to remove so many words from headline copy by default.

Have you read the article?

The underlying problems have not been fixed. They added some band aids to prevent the specific attack Green found, yet the protocol is still a big mess, an ad-hoc design that is doing a couple of things that every cryptographer who knows a thing about modern crypto designs knows to avoid.

The article suggests to replace iMessage with Signal protocol but fails to describe exactly how Signal is better.

If that's the "fix" you can see why it hasn't been done and we instead have several mitigations instead.

The article explains in great length what the problem of iMessage is. It has no forward secrecy and uses no authenticated encryption. Signal does both. The flaw Matthew Green's team found is precisely due to the fact that iMessage is not using authenticated encryption (as are tons of other crypto flaws). As said: They added some band aid, they have not fixed the problem.

Signal would be an improvement, but the status of signal as open source, and the details of what you get security wise is not very transparent with all of these new "signal integrations" that open whisper is doing.

Signal is definitely moving things in the right direction but I wish there was more research in this "signal integration" space. Do you know of any research here?

Matthew Green has a very readable yet technical writeup of this attack:

http://blog.cryptographyengineering.com/2016/03/attack-of-we...

I don't think that can be the same attack: Matthew Green was one of the discoverers of this attack, which was just disclosed in a USENIX Security paper and was not public until then. The post you linked to is from March.

No, I believe it's the same attack.

Certainly looks like the same attack. The talk was given at Usenix on Thursday, which I assume is why it's coming back up.

Oops, I wrongly thought that the Usenix paper was embargoed so it must have been different. I agree that it's the same attack; thanks for the corrections.

The blog post links to a copy of the paper.

Alas it's too bad the article makes a lot of assertions and assumptions about what iMessage "should" do and be. I agree with a lot of the suggestions but there are also practical concerns to consider when designing a messaging system. iMessage is criticized for allowing decryption of old messages and iCloud backups to share history among devices. But presumably that's a feature that Apple believes its users desire. Every security protocol makes tradeoffs. Merely allowing real-time arbitrary-length communication leaks a lot of metadata about the communicating parties. Yet Signal allows me to send messages of different lengths whenever I please. Presumably that's a feature Signal users desire.

In what way could iMessage's encryption be better than TLS? Which improvements, specifically, could make it better than TLS? I was under the impression that TLS is state-of-the-art.

TLS is a form of transport encryption, which encrypts data between the client and the server. End-to-end encryption encrypts data between two clients, so that the server cannot read any messages. The paper claims that while iMessage is marketed as end-to-end encrypted, because of vulnerabilities it is more like it just uses transport encryption.

TLS is supposed to protect data in-flight, but the data is known to both parties.

iMessage was advertised to protect the user's message in such a way that even Apple couldnt't read them, even if they stage a man-in-the-middle attack.

(disclosure: I have not read the article)

I’m by no means an expert in this field, but my impression is that Signal’s protocol is state of the art when it comes to end-to-end-encrypted messaging.

https://github.com/WhisperSystems/libsignal-protocol-java

Edit: Some more pointers for those interested: https://whispersystems.org/blog/signal-inside-and-out/

I believe only in the sense that it doesn't chain entirely back to the TLS X.509 CA PKI.

tls is "state of the art" for a public server to talk to unknown users.

but basically totally broken by design.

http://www.interworx.com/community/is-ssl-tls-broken/

further tls:sender,recipient and server can read the message

end to end:only sender and reciever can read the messages even though a sever facilitates connecting them to each other.

  > but basically totally broken by design.
  > http://www.interworx.com/community/is-ssl-tls-broken/

Can you please excerpt some quotes from that article which support that claim?

"That’s worrying, but in practical terms, it’s unlikely to have significantly impacted the security of TLS because the elliptic curve random number generator in question is not often used." vs. http://www.loyalty.org/~schoen/rsa/

"Secondly, there’s the implementation. This is a bit more tricky because there’s plenty of scope for influencing either the software implementations or the standards upon which that implementation is based." vs. http://www.theregister.co.uk/2015/09/15/still_200k_iot_heart...

And if you think the vulnerabilities of the shocking state of openssl stop at heartbleed (which is as obvious as backdoors get), you've obviously not given the code even a cursory glance over.

https obviously greater than http But if you trust it with your life you wont have a life. It's as simple as that. (and tls is basic compared to tor, and even that we have seen is broken to hell and back, or silkroad would still be running.)

Signal and especially OTR are the current state of the art. Apple went the security by obscurity route and once again proved it's inferior.

And here I am thinking TLS is pretty good...

It is. The title is a little misleading; here's an explanatory excerpt from the actual paper:

> In this work we analyze the iMessage protocol and identify several weaknesses that an attacker may use to decrypt iMessages and attachments. While these flaws do not render iMessage completely insecure, some flaws reduce the level of security to that of the TLS encryption used to secure communications between end- user devices and Apple’s servers.

TLS is pretty good, but has a completely different scope. It is entirely dependent on the intentions and competence of people who can control the server and access the certificate, as well as the issuer. The client has very little power over this.

A good end-to-end encryption should guarantee that as long as both clients have good intentions, nothing can reveal their communication. This is a much higher level of expectation.

The paper is cool, but it is painful to read the news article. Mostly because it lacks details, but uses "techie" terms without explaining issues in the usual English. Seems like journalist does not understand the issue well enough. Very bad reporting.

Wait, TLS is broken? Since when?

April 2014.

Uh, no. Implementation bugs don't mean a protocol is broken.

Uh, good luck convincing anyone that April 2014 does anything other than demonstrate there are exactly zero reliable implementations of TLS. If the most widely used implementation can demonstrate that level of incompetence, what chance do any of the others have.

And I don't care if pointing that out costs me mod points. Its seems on these types of conversations negative points are a mark of honesty.

If there are exactly zero reliable implementation of TLS, then these 10 BTC should be easy to collect: https://ownme.ipredator.se/

Why would you waste an extremely valuable exploit on a bounty worth under $6000 USD?

It’s not clear to me that an exploit of a vulnerability in a not-widely-used TLS implementation in native OCaml (or a vulnerability in any of the other software in use on that system) would be more valuable than the bounty offered.