Thoughts on iMessage Integrity

Recently, Quarkslab exposed design flaws[1] in Apple’s iMessage protocol demonstrating that Apple does, despite its vehement denial, have the technical capability to intercept private iMessage traffic if they so desired, or were coerced to under a court order. The iMessage protocol is touted to use end-to-end encryption, however Quarkslab revealed in their research that the asymmetric keys generated to perform this encryption are exchanged through key directory servers centrally managed by Apple, which allow for substitute keys to be injected to allow eavesdropping to be performed. Similarly, the group revealed that certificate pinning, a very common and easy-to-implement certificate chain security mechanism, was not implemented in iMessage, potentially allowing malicious parties to perform MiTM attacks against iMessage in the same fashion. While the Quarkslab demonstration required physical access to the device in order to load a managed configuration, a MiTM is also theoretically possible by any party capable of either forging, or ordering the forgery of a certificate through one of the many certificate authorities built into the iOS TrustStore, either through a compromised certificate authority, or by court order. A number of such abuses have recently plagued the industry, and made national news^{[2, 3, 4]}.

Apple’s response to Quartkslab’s research has been continued denial of the technical capabilities to or the desire to intercept iMessage traffic, however the technical details of the report have been validated by a number of independent security researchers, and at this stage are found entirely plausible. Because any organization that is compelled to perform surveillance on its customers is likely also under a court order to keep such activities confidential, the technical revelations alone are enough to potentially damage trust in the confidentiality of Apple’s services; with today’s secret government surveillance operations, the only way to truly gauge security is by the quality of the technology. In this case, there appear to be not only flaws, but potentially suspicious flaws, further chipping away at Apple’s credibility in securing iMessage. Since the technology could be compromised, it must therefore be assumed that it is being compromised, until such a time as the technology is fixed to prevent this type of eavesdropping.

The design flaws in the iMessage protocol are suspicious to the degree that certificate pinning is a feature already built into the iOS operating system for App Store developers (by Apple), and has been made very easy to implement (by Apple), yet is not implemented in Apple’s own software. A reasonable amount of Apple documentation even exists to describe the process by which a developer can implement pinning. It were, as it seems, that Apple is not eating their own dog food. The overall design and use of a centrally managed key directory further calls into question the integrity of the iMessage system, as Apple’s implementation allows for the most classic form of MiTM to be performed; a technique that has been well known in information security for decades. It could have been designed differently. Much differently.

Fortunately, Quarkslab has introduced a counter-surveillance tool to help mitigate the risk of iMessage surveillance, by monitoring the public keys for changes. The iMITMProtect tool attaches to the imagent process and intercepts keys sent by Apple’s key server. If a public key ever changes (which should not happen), the tool will alert the user that their communication may be the target of compromise, and will serve up a cached copy of the public key to allow for continued secure communication with the endpoint. This mechanism will identify and help combat most types of MiTM event, except in cases where a key is compromised from the point of initial exchange. Such an attack would only likely be possible if Apple were substituting keys for one or all users from the moment they are first generated. While a good monitoring and counter-surveillance tool, this is not a complete solution. Out-of-band verification of iMessage keys is the only way to ensure that your communications channel is secure. This type of key management is coming to their tool soon, according to Quarkslab.

Apple, in the meantime, could greatly improve the overall security of their own product. A number of instant messaging protocols incorporate perfect forward security (PFS), which can be used to establish encrypted sessions in an untrusted environment, even if one party’s keys are exposed. Because Apple hosts the keys for both parties on a centralized server, though, moving key generation and storage closer to the end-user (on-device), as instant messaging application do, can greatly improve the security of iMessage. The Diffie-Helman key exchange is a well-known and accepted protocol for performing crypgoraphic key exchange over an insecure channel, and is incorporated by PFS. Finally, implementing the certificate pinning mechanism that Apple, themselves, have already provided for developers, would greatly reduce the likelihood of a MiTM attack using a rogue certificate, or other means. Ten years ago, this may not have been a concern, however there is a pretty solid track record demonstrating recent rogue certificate abuse. Given the size of Apple’s TrustStore, consumers are trusting a large number of countries, many of which have governments that could easily compel rogue certificate creation for exactly this purpose.

Overall, Quarkslab’s design flaws claims in iMessage appear to be valid, however the question remains of whether these design flaws were actually mistakes in the design, or omissions intentionally left out of the design. This would not be the first suspicious design omission in Apple’s design. In fact, a number of design omissions still exist today in iOS 7, which prevent reasonably secure encryption of a majority of the user’s data at rest, lack of pairing record pinning or encryption, flaws that allow for backup encryption to be bypassed, and many other design choices. The  motivation behind Apple’s design choices should be deduced over the next several months, based on their technical response to fix the iMessage weaknesses now that they have been made public.

~

1 iMessage Privacy http://blog.quarkslab.com/imessage-privacy.html

2 Another Certificate Authority Issues Dangerous Certificates http://nakedsecurity.sophos.com/2011/11/03/another-certificate-authority-issues-dangerous-certficates/

3 Digital Certificate Authority Hacked http://www.darkreading.com/attacks-breaches/digital-certificate-authority-hacked-doz/231600498

4 Mozilla Toughens Up On CA Abuse http://news.techworld.com/security/3427196/mozilla-toughens-up-on-ca-certificate-abuse/