If you carefully read the paper, you'll see that the exploit for this attack is a lot more interesting than its implications.
The underlying flaw here is very simple: the iMessage protocol doesn't properly authenticate messages. In a fashion somewhat similar to that of memory corruption vulnerabilities inevitably leading to code execution, message integrity vulnerabilities seem to inevitably result in losses of confidentiality (this is counterintuitive but well-studied). That's essentially what's happening here.
Backwards compatibility issues prevent Apple from simply fixing the protocol, and they've instead had to deploy tactical countermeasures to kill the exploit, but in the medium term one expects they'll simply revise the protocol. So this is basically a dead bug.
The exploit, though, is ridiculous!
iMessage messages are DEFLATE compressed. So when you're using bit-flipping attacks to convince the protocol to reveal plaintext bits, you're not XOR-ing plaintext, but rather compressed plaintext. Among the problems this creates for attackers:
* Whatever the result of your bit-flips are, they have to result in valid Huffman symbols.
* The resulting stream of Huffman symbols has to pass the DEFLATE CRC.
* You have to know what the Huffman table is for the message.
The exploit plays tricks to get past all these hurdles --- the trick for the last one is particularly nice.
I'm less interested in what this says about iMessage security. You should be using Signal, or even WhatsApp, in preference to iMessage (though iMessage even in its vulnerable state was more than secure enough to handle routine financial information; this attack is very painful to carry out). I'm much more interested in attacks like this as a blueprint for future attacks against other complicated protocols.
"Apple iMessage, as implemented in versions of iOS prior to 9.3 and Mac OS X prior to 10.11.4, contains serious flaws in the encryption mechanism that could allow an attacker -- who obtains iMessage ciphertexts -- to decrypt the payload of certain attachment messages via a slow but remote and silent attack, provided that one sender or recipient device is online. While capturing encrypted messages is difficult in practice on recent iOS devices, thanks to certificate pinning, it could still be conducted by a nation state attacker or a hacker with access to Apple's servers. You should probably patch now."
This attack started with a well known pattern where protocols where you can freely mutate cyphertext in transit usually end of building a decryption oracle into them that an attacker can exploit.
Then they found a novel oracle in the image decryption system.
Then big change at Apple lately is that on top of having world class cypto and security people they are publishing a lot more of their design work for peer review. This will lead to much more secure systems when they replace the iMessage crypto.
If Apple has world class crypto people then they had nothing to do with the design of imessage.
It didn't take the attack from Green and Co to see that this crypto design is very strange and doesn't follow any kind of modern best practice. (And no, the fact that it's 5 years old doesn't make things better. "Use an AEAD" and "use PFS" are things that one could've known in 2011.)
The underlying flaw here is very simple: the iMessage protocol doesn't properly authenticate messages. In a fashion somewhat similar to that of memory corruption vulnerabilities inevitably leading to code execution, message integrity vulnerabilities seem to inevitably result in losses of confidentiality (this is counterintuitive but well-studied). That's essentially what's happening here.
Backwards compatibility issues prevent Apple from simply fixing the protocol, and they've instead had to deploy tactical countermeasures to kill the exploit, but in the medium term one expects they'll simply revise the protocol. So this is basically a dead bug.
The exploit, though, is ridiculous!
iMessage messages are DEFLATE compressed. So when you're using bit-flipping attacks to convince the protocol to reveal plaintext bits, you're not XOR-ing plaintext, but rather compressed plaintext. Among the problems this creates for attackers:
* Whatever the result of your bit-flips are, they have to result in valid Huffman symbols.
* The resulting stream of Huffman symbols has to pass the DEFLATE CRC.
* You have to know what the Huffman table is for the message.
The exploit plays tricks to get past all these hurdles --- the trick for the last one is particularly nice.
I'm less interested in what this says about iMessage security. You should be using Signal, or even WhatsApp, in preference to iMessage (though iMessage even in its vulnerable state was more than secure enough to handle routine financial information; this attack is very painful to carry out). I'm much more interested in attacks like this as a blueprint for future attacks against other complicated protocols.