iMessage has flaws in how it protects messages, researchers at Johns Hopkins University explain in a paper released today, which can lead to effective, offline decryption of some intercepted messages.
The researchers disclosed their work to Apple in November, and today’s release of iOS 9.3 and OS X 10.11.4 remove some exploits and make others dramatically harder to take advantage of. The paper’s authors include Matthew D. Green, a cryptographer known for his research on privacy-preserving cryptographic protocols, including Bitcoin.
A story by the Washington Post appeared early on Sunday night, leading to inadvertent disclosure ahead of time. The story was quickly pulled but later republished after that became clear. We held some technical details for the initial version of this story at the request of the researchers, until Apple’s updates were out.
Here’s what you need to know.
Did they break iMessage encryption?
Yes and no. iMessage is Apple’s product name for a bundle of different kinds of message-and-file transfer that uses a variety of interlinked and layered encryption methods. Apple doesn’t disclose more than a surface description of its system, and has been criticized for years about not providing more detail, which would allow “white hat” hackers—like academic researchers and those within Apple, Google, and other companies—to more effectively probe quietly for weaknesses. These flaws could be fixed before a malicious party or government agency could take advantage of them.
While the researchers who wrote today’s academic paper found many avenues of exploration, some of which we can imagine that governments and criminals have already separately discovered and potentially exploited, the paper focuses on being able to decrypt attachments to iMessages, like images and other files for which the raw encrypted data has been intercepted.
However, so far, the fundamental mechanisms that prevent any but the intended recipients of a text message from being able to access the descrambled text remain intact. Also, the exploit used requires extraordinary, but not impossible, access to bypass one level of security.
Has Apple fixed the problems?
Yes, Apple has fixed all the problems the researchers specifically identified through one set of updates performed quietly a few months ago, and another set that appear in iOS 9.3 and OS X 10.11.4. Some are comprehensive fixes, while others are temporary solutions that need a significant revision in the long term.
Are my messages at immediate risk?
No, not for most people. The flaws can’t be exploited broadly, but would be useful for parties intending to pinpoint information from a small set of individuals, because of the complexity of obtaining the source data.
With iOS 9.3 and OS X 10.11.4 installed, the vulnerabilities have been patched. Until and unless Apple updates previous releases or installs server-side updates that it can perform unilaterally, weaknesses may remain in those older versions.
However, any encrypted iMessages that were previously captured could be vulnerable, for reasons discussed later. While it’s possible that some iMessage data of the form required was captured in the past, it’s unlikely to be very much and, further, it’s possible none of it could ultimately be decrypted. The risk is negligible for most people that past messages will be revealed. (If you use the preference Save History When Conversations Are Closed to retain transcripts in Messages for OS X, that unencrypted data is at vastly greater risk.)
Is there anything I can do to improve iMessage security for myself?
No, all the changes have to be made by Apple in its client software for iOS and OS X and its server operations.
How does the attack work?
The researchers found the weakest point in iMessage, which has to do with how it handles messages above a certain length, which the paper refers to as “long iMessages,” and can include runs of text and attachments, like images.
Effectively, they can intercept encrypted data (see next question) intended to be sent to an iMessage server from iOS and OS X, and then perform an enormous number of operations to extract information that then lets them decrypt the attachment in a reasonable amount of time using a standard Mac for part of the process and then inexpensive fast commodity hardware for the remainder.
The main flaw the paper covers stems from the way in which attachments are losslessly compressed (replacing recurring patterns with short codes), validated, and addressed to others. The researchers predict some parts of a message and know precisely some other parts, which allowed them to substitute in new values for known or guessed ones in the raw encrypted stream or “ciphertext.”
That flaw could be exploited only because they were also able to check when their substitutions were correct: Apple lets the iMessage software validate attachment requests locally in OS X (or iOS) and without any limit to the number of times, without consulting its servers or tripping any alarms or restrictions.
The researchers ultimately were able to show they could insert additional recipients (who were one-letter-off variants of a legitimate recipient) into an attachment’s delivery list, recover an attachment’s raw ciphertext, attack it, recover its unique encryption key, and decrypt it.
Because of how iMessage in OS X handles testing the message’s validity, the paper describes having to wait nearly half a second between each check. However, only about 262,000 (218) operations were required, taking roughly 35 hours. That allowed extracting enough of the encryption key that the remaining cracking could be shifted to high-performance hardware.
But can anyone get this raw ciphertext?
Not exactly. iMessage has another layer of protection, which is TLS (Transport Layer Security), also used to secure Web and many other Internet sessions. TLS protects data in transit using digital certificates that are authenticated by globally recognized certificate authorities (CAs), but it can be subverted in one of three ways:
- Attackers could break into Apple’s system to capture the ciphertext as it passes through. This is exceedingly unlikely, but it’s a constant concern.
- A malicious party could suborn a CA, which has happened in the past, and issue a legitimate but fraudulent certificate that was trusted as if it belonged to Apple’s servers.
- Someone with access to a user’s OS X or iOS system directly or via malware could install a fake CA that can sign certificates that appear to the computer to come from Apple, and then capture them locally or redirect them through an intermediary server.
The second and third options aren’t possible when certificate pinning is used, a practice in which software refuses to accept as valid any certificates other than a specific set or those issued by a particular CA (out of hundreds).
Apple had put pinning in place in iOS 9 for interactions with its servers related to iMessage and many other services, but not in El Capitan (10.11). Apple could update older versions of OS X, as it has recently, but it stopped releasing updates to iOS 8 and no longer signs that or previous iOS releases. However, some improvements may be possible entirely on the server side for older clients.
Stored ciphertext could be vulnerable, but, as noted above, it’s unlikely there’s very much of that stored by any party; Apple only stores undelivered messages, and those for only 30 days.
What remains to be fixed?
The researchers detail a number of flaws they didn’t examine in depth, but which are ripe for exploitation by others (and may already have been). These include, among less-technical recommendations:
- Key verification. Apple runs its entire key distribution system privately leaving users, researchers, and other parties no way to validate keys (preventing man-in-the-middle attacks) or notice changes. Apple could provide much more transparency without any risk of security, which would allow other parties to monitor for and be aware of malicious modifications to keys, distribution irregularities, or expected behavior by end-user software.
- Make announcements of device registration more robust. Apple’s mechanism for alerting users about newly registered devices is fragile, making it possible for an attacker to avoid having an alert sent, and thus surreptitiously receiving all iMessages for an account.
- A lack of forward secrecy. Apple doesn’t change out the encryption keys used to protect individual account’s iMessages. As a result, a future exploit that allows a key to be broken can allow the decryption of previously captured cryptographic material as long as it uses the same key. The researchers suggest that Apple immediately force every Apple device to regenerate its iMessage keys and destroy previously used keys. This won’t delete already decrypted and received messages stored in iOS or OS X’s transcript logs.
- Resistance to “replay” and “reflection” attacks. Captured iMessages can be re-sent to the original recipient, which allows spoofing of previously sent messages as well as the potential to decode them if a user’s device is obtained.
The researchers have a number of specific suggestions for short-term changes in the use of algorithms and interactions, including that Apple should ultimately dump its entire cryptographic system and replace it with something that’s more up to date and better tested.
Is this related to the FBI/DOJ court order?
No, although two things are absolutely likely. First, it’s highly probable that the National Security Agency and other governments’ code-cracking divisions were well aware of this. Despite the cleverness of the researchers’ approach, it’s low-hanging fruit that such departments would likely have probed and discovered.
Second, Apple may be bundling other security improvements to iMessage and other software in the latest iOS and OS X releases in advance of any potential change in U.S. law or ruling, as it isn’t under any publicly known order at the moment to halt its advances in security.
Apple’s desire to keep private data private may put more effort behind it adopting the researchers’ recommendations for a complete overhaul.
[Source:- Macworld]
