On Monday, security researchers from Johns Hopkins University disclosed details of how they managed to decrypt photos and videos sent via Apple's end-to-end encrypted iMessage service. The paper, which is the most extensive reverse-engineering of iMessage yet, also reaffirmed several other problems with the messaging service, and gave a much bolder warning to Apple.
"Our main recommendation is that Apple should replace the entirety of iMessage with a messaging system that has been properly designed and formally verified," the team, led by Matthew Green, assistant professor at the Johns Hopkins Information Security Institute, write in the paper. The researchers do acknowledge that this approach may not be immediately feasible, though.
Because of the way iMessage authenticates encrypted messages, the researchers were able to methodically gain information about intercepted messages and eventually decrypt them. In their practical experiments, they were able to recover 232 out of 256 key bits in 35 hours. The process does not reliably produce every single part of the encryption key, but the researchers say it is possible to brute force the remaining bits to make up the key.
The research might also have ramifications for Apple's "Handoff" service, which, according to Apple, encrypts messages "in a similar fashion to iMessage."
The attack doesn't only apply to messages intercepted by an attacker on the fly, but also to messages that have been previously collected. This means that those stored on Apple's servers, or those that a resourceful adversary has stockpiled via another means of interception, may be vulnerable. Apple issued fixes for the problem in iOS 9.3, which was released today, and it's worth bearing in mind that iMessages are also protected by a layer of TLS encryption, meaning an attacker would need to get around that as well. The sort of capability necessary for carrying out the full attack outside of a test environment is only realistically possessed by powerful nation states.
Regardless, the researchers write that iMessage's encryption "does not conform to best cryptographic practices and generally seems ad hoc."
But broader problems with iMessage's design and implementation also drew criticism.
"Apple should deprecate the existing iMessage protocol and replace it with a well-studied construction incorporating modern cryptographic primitives, forward secrecy and message authentication," the researchers write.
Because iMessage encryption keys are long lived, and not automatically replaced at any point, gaining access to a user's key, perhaps via physical, unlocked access to their device, would then allow decryption of any iMessages the attacker had already intercepted. Forward secrecy, as one mitigation is known as, stops an attacking from decrypting messages from previous sessions.
And this applies to the decryption attack too: "The risk of such attacks would be greatly mitigated if iMessage clients periodically generated fresh encryption keys," the researchers add.
Another issue is that Apple relies on a central server to manage the keys of iMessage's users, and doesn't allow users to verify keys handed out by that system.
"This server represents a single point of compromise for the iMessage system. Apple, and any attacker capable of compromising the server, can use this server to perform a man-in-the-middle attack and obtain complete decryption of iMessages," the paper reads. This is because iMessage provides no way for users to verify that they have been provided the correct key, meaning that Apple, if forced to by law enforcement, could surreptitiously issue one that allows eavesdropping.
Other experts have warned about this issue in the past. "Without such an interface, iMessage is "backdoor enabled" by design: the keyserver itself provides the backdoor," Nicholas Weaver, a senior researcher from the International Computer Science Institute wrote last year on the Lawfare Blog.
In a statement, Apple said the company "works hard to make our software more secure with every release… Security requires constant dedication and we're grateful to have a community of developers and researchers who help us stay ahead."
Additional reporting by Lorenzo Franceschi-Bicchierai