Dancing on the Lip of the Volcano: Chosen Ciphertext Attacks on Apple iMessage Christina Garman, Matthew Green, Gabriel Kaptchuk, Ian Miers, and Michael Rushanan, Johns Hopkins University https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/garman
This paper is included in the Proceedings of the 25th USENIX Security Symposium August 10–12, 2016 • Austin, TX ISBN 978-1-931971-32-4
Open access to the Proceedings of the 25th USENIX Security Symposium is sponsored by USENIX nc ng on t e of t e olc no osen erte t Att cks on A le ess ge
Christina Garman Matthew Green Gabriel Kaptchuk Johns Hopkins University Johns Hopkins University Johns Hopkins University cgarman cs hu edu mgreen cs hu edu gkaptchuk cs hu edu Ian Miers Michael Rushanan Johns Hopkins University Johns Hopkins University imiers cs hu edu micharu cs hu edu
A str ct Justice accused Apple of thwarting an investigation by refusing to turn over iMessage plaintext [11]. iMes- Apple’s iMessage is one of the most widely-deployed sage has been at the center of a months-long debate end-to-end encrypted messaging protocols. Despite its initiated by U.S. and overseas officials over the imple- broad deployment, the encryption protocols used by mentation of “exceptional access” mechanisms in end- iMessage have never been subjected to rigorous crypt- to-end encrypted communication systems [7, 26, 33], and analysis. In this paper, we conduct a thorough analy- some national ISPs have temporarily blocked the proto- sis of iMessage to determine the security of the proto- col [32]. Throughout this controversy, Apple has consis- col against a variety of attacks. Our analysis shows that tently maintained that iMessage encryption is end-to-end iMessage has significant vulnerabilities that can be ex- and that even Apple cannot recover the plaintext for mes- ploited by a sophisticated attacker. In particular, we out- sages transmitted through its servers [10]. line a novel chosen ciphertext attack on Huffman com- pressed data, which allows retrospective decryption of Given iMessage’s large installed base and the high some iMessage payloads in less than 218 ueries. The stakes riding on its confidentiality, one might expect practical implication of these attacks is that any party iMessage to have received critical attention from the re- who gains access to iMessage ciphertexts may poten- search community. Surprisingly, there has been very lit- tially decrypt them remotely and after the fact. We ad- tle analysis of the system, in large part due to the fact that ditionally describe mitigations that will prevent these at- Apple has declined to publish the details of iMessage’s tacks on the protocol, without breaking backwards com- encryption protocol. In this paper we aim to remedy this patibility. Apple has deployed our mitigations in the lat- situation. Specifically, we attempt to answer the follow- est iOS and OS X releases. ing uestion: how secure is Apple iMessage Our contributions In this work we analyze the iMessage ntrod ct on protocol and identify several weaknesses that an attacker may use to decrypt iMessages and attachments. While The past several years have seen widespread adoption of these flaws do not render iMessage completely insecure, end-to-end encrypted text messaging protocols. In this some flaws reduce the level of security to that of theTLS work we focus on one of the most popular such proto- encryption used to secure communications between end- cols: Apple’s iMessage. Introduced in 2011, iMessage user devices and Apple’s servers. This finding is surpris- is an end-to-end encrypted text messaging system that ing given the protection claims advertised by Apple [10]. supports both iOS and OS X devices. While Apple does Moreover, we determine that the flaws we detect in iMes- not provide up-to-date statistics on iMessage usage, in sage may have implications for other aspects of Apple’s February 2016 an Apple executive noted that the system ecosystem, as we discuss below. had a peak transmission rate of more then 200,000 mes- To perform our analysis, we derived a specification for sages per second, across 1 billion deployed devices [12]. iMessage by conducting a partial black-box reverse engi- The broad adoption of iMessage has been controver- neering of the protocol as implemented on multiple iOS sial, particularly within the law enforcement and national and OS X devices. Our efforts extend a high-level pro- security communities. In 2013, the U.S. Drug Enforce- tocol overview published by Apple [9] and two existing ment Agency deemed iMessage “a challenge for DEA partial reverse-engineering efforts [1, 34]. Armed with a intercept” [22], while in 2015 the U.S. Department of protocol specification, we conducted manual cryptanal-
USENIX Association 25th USENIX Security Symposium 655 ysis of the system. Specifically, we tried to determine our work primarily considers the iMessage instant mes- the system’s resilience to both back-end infrastructure at- saging system, we note that the vulnerabilities identified tacks and more restricted attacks that subvert only client- here go beyond iMessage. Apple documentation notes local networks. that Apple’s “Handoff” service, which transmits per- Our analysis uncovered several previously unreported sonal data between Apple devices over Bluetooth Low vulnerabilities in the iMessage protocol. Most signifi- Energy, encrypts messages “in a similar fashion to iMes- cantly, we identified a practical adaptive chosen cipher- sage” [9]. This raises the possibility that our attacks on text attack on the iMessage encryption mechanism that iMessage encryption may also affect inter-device com- allows us to retrospectively decrypt certain iMessage munication channels used between Apple devices. At- payloads and attachments, provided that a single Sender tacks on this channel are particularly concerning because or Recipient device is online. To validate this finding, these functions are turned on by default in many new we implemented a proof of concept exploit against our Apple devices. We did not investigate these attack vec- own test devices and show that the attack can be con- tors in this work but subsequent discussions with Apple ducted remotely (and silently) against any party with an have confirmed that Apple uses the same encryption im- online device. This exploit is non-trivial and required plementation to secure both iMessage and inter-device us to develop novel exploit techniques, including a new communications. Thus, securing these channels is one chosen ciphertext attack that operates against ciphertexts side effect of the mitigations we propose in 7. containing gzip compressed data. We refer to this tech- nique as a gzip format oracle attack, and we believe it Res ons le d sclos re may have applications to other encryption protocols. We discuss the details of this attack in 5. In November 2015 we delivered a summary of the results We also demonstrate weaknesses in the device reg- in this paper to Apple. Apple acknowledged the vulner- istration and key distribution mechanisms of iMessage. ability in 5 and has initiated substantial repairs to the One weakness we exploit has been identified by the re- iMessage system. These repairs include: enforcing cer- verse engineering efforts in [34], while another is novel. tificate pinning across all channels used by iMessage,1 As they are not the main result of this work, we include removing compression from the iMessage composition them in Appendix A for completeness. (for attachment messages), and developing a fix based Overall, our determination is that while iMessage’s on our proposed “duplicate ciphertext detection” mitiga- end-to-end encryption protocol is an improvement over tion (see 7). Apple has also made changes to the use of systems that use encryption on network traffic only (e.g., iMessage in inter-device communications such as Hand- Google Hangouts), messages sent through iMessage may off, although the company has declined to share the de- not be secure against sophisticated adversaries. Our re- tails with us. The repairs are included in iOS 9.3 and OS sults show that an attacker who obtains iMessage cipher- X 10.11.4, which shipped in March 2016. texts can, at least for some types of messages, retrospec tively decrypt traffic. Because Apple stores encrypted, Att ck odel undelivered messages on its servers and retains them for up to 30 days, such messages are vulnerable to any party Our attacks in 5 require the ability to obtain iMessage who can obtain access to this infrastructure, e.g., via ciphertexts sent to or received by a client. Because Apple court order [11] or by compromising Apple’s globally- Push Network Services (APNs) uses TLS to transmit en- distributed server infrastructure [36]. Similarly, an at- crypted messages to Apple’s back-end servers, exploit- tacker who can intercept TLS using a stolen certificate ing iMessage requires either access to data from Apple’s may be able to intercept iMessages on certain versions of servers or a forged TLS certificate. We stress that while iOS and Mac OS X that do not employ certificate pinning this is a strong assumption, it is the appropriate threat on Apple Push Network Services (APNs) connections. model for considering end-to-end encrypted protocols. Given the wide deployment of iMessage, and the at- A more interesting objection to this threat model is tention paid to iMessage by national governments, these the perception that iMesssage might be too weak to sat- threats do not seem unrealistic. Fortunately, the vulnera- isfy it. For example, in 2013 Raynal et al pointed out bilities we discovered in iMessage are relatively straight- a simple attack on Apple’s key distribution that enables forward to repair. In the final section of this paper, we a TLS MITM attacker to replace the public key of a re- offer a set of mitigations that will restore strong crypto- cipient with an attacker-chosen key [34]. One finding of graphic security to the iMessage protocol. Some of these this work is that as of December 2015 such attacks have are included in iOS 9.3 and Mac OS X 10.11.4, which been entirely mitigated by Apple through the addition of shipped in March 2016. 1This feature was added to OS X 10.11 in December, as a result of Other uses of the iMessage encryption protocol While our notification.
656 25th USENIX Security Symposium USENIX Association certificate pinning on key server connections (see Ap- service, which is operated by Apple using both their own pendix A). More fundamentally, however, such attacks servers and virtual servers provisioned on Amazon AWS, are prospective – in the sense that they require the at- Microsoft Azure, and Google’s Cloud Platform. tacker to target a particular individual before the individ- ual begins communicating. By contrast, the attacks we The basic unit of identity in describe in this paper are retrospective. They can be run dent t nd reg str t on iMessage is the iCloud account name, which typically against any stored message content, at any point subse- consists of an email address or phone number controlled quent to communication, provided that one target device by the user. End-user devices are registered to the iCloud remains online. Moreover, unlike previous attacks which service by associating them with an account. The map- require access to the target’s local network, our attacks ping between client devices and accounts is not one-to- may be run remotely through Apple’s infrastructure. one: a single account may be used across multiple de- vices, and similarly, multiple accounts can be associated e ess ge rotocol with a single device. We give further information about the registration process in Appendix A. To obtain the full iMessage specification, we began with the security overview provided by Apple, as well as de- tailed previous software reverse-engineering efforts con- ess ge encr t on nd decr t on To transmit a ducted by Raynal [34] and others [1]. While these pre- message to some list of Recipient IDs, the Sender’s vious results provide some details of the protocol, they iMessage client first contacts the IDS to obtain the pub- omit key details of the encryption mechanism, as well lic key(s) P 1,...,P D and a list of APNs push to- as the complete key registration and notification mecha- kens associated with the Sender and Recipient identi- nisms. We conducted additional black-box reverse engi- ties.3 It then encodes the Sender and Recipient ad- neering efforts to recover these elements. Specifically, dresses and plaintext message into a binary plist key- we analyzed and modified protocol exchanges to and value data structure and compresses this structure using from several jailbroken and non-jailbroken Apple de- the gzip compression format. The client next gener- vices.2 In conformity to Apple’s terms of service, we ates a 128-bit AES session key and encrypts the re- did not perform any software decompilation. sulting compressed message using AES-CTR with IV = 1. This produces a ciphertext c, which is next parti- tioned as c =(c c ) where c represents the first 101 stem o er ew 1 2 1 bytes of c. The Sender parses each P i to obtain the public encryption key pk and for i = 1 to D, cal- iMessage clients iMessage clients comprise several E,i culates C = RSA-OAEP(pk , c ) and a signature pieces of software running on end-user devices. On iOS i E,i 1 σ = ECDSASign(sk ,C c ). For each distinct push to- and OS X devices, the primary user-facing component is i S i 2 ken received from IDS, the Sender transmits (C ,c ,σ ) the Messages application. On OS X computers, this ap- i 2 i to the APNs server. This process is illustrated in Fig- plication interacts with at least three daemons: , the apsd ure 1. daemon responsible for pushing and pulling application For each ciphertext, the APNs service delivers the tu- traffic over the Apple Push Notification Service (APNs) ple (ID ,ID ,C ,c ,σ ) to the intended desti- channel imagent, a daemon that pulls notifications even sender recipient i 2 i nation. The receiving device contacts IDS to obtain the if Messages is closed and identityservicesd, a dae- Sender’s public key P , parses for the signature veri- mon which maintains a cache of other users’ keys. iOS fication key vk , then verifies the signature σ. If veri- devices also contain an apsd daemon, while other dae- S fication succeeds, it decrypts C to obtain c , recon- mons handle the task of managing identities. i 1 structs c =(c c ) and decrypts the resulting AES-CTR 1 2 Apple services iMessage clients interact with multiple ciphertext using . It decompresses the resulting gzip back-end services operated by Apple and its partners. We ciphertext, parses the resulting plist to obtain the list focus on the two most relevant to our attack. The Apple of Recipient IDs, and verifies that each of IDsender and directory service (IDS, also known as ESS) maintains a IDrecipient are present in this list. If any of the preced- mapping between user identities and public keys and is ing checks fail, or if the Recipient is unable to parse or responsible for distributing user public keys on request. decompress the resulting message, the receiving device iMessage content is transmitted via the Apple Push No- silently aborts processing. tification Service (APNs). Long iMessages and attach- ments are transmitted by uploading them to the iCloud 3This list includes one entry for each device registered to each Sender and Recipient ID. The Messages client encrypts the message 2In this analysis we considered iOS 6, 8, and 9 devices, as well as with each Sender public key to ensure that message transcripts can be Mac clients running OS X 10.10.3, 10.10.5, and 10.11.1. read across all of the Sender’s devices.
USENIX Association 25th USENIX Security Symposium 657 Recipient PK sender ID iMessage binary plist Sender SK gzip compress AES key huffman table compressed payload CRC AES-CTR encrypt (IV=1) AES encrypted payload extract bytes 0:100 extract bytes 101:n concatenation RSA-OAEP encryption RSA ciphertext partial AES ciphertext signature ECDSA-SHA1 sign
Figure 1: The iMessage encryption mechanism. From the top, each iMessage is encoded in a binary plist key/value structure. The structure encodes a list of Sender and Recipient account identifiers, as well as the message contents. This payload is subse uently gzip compressed, and encrypted under a freshly-generated 128-bit message key using AES in CTR-mode. The AES key and the first 101 bytes of the AES ciphertext are concatenated and are encrypted to each Recipient’s public key using RSA-OAEP. The remaining bytes of the AES ciphertext are concatenated to the RSA ciphertext and the result is signed using ECDSA under the Sender’s registered signing key.
Att c ments nd long mess ges For long messages or large Internet service providers. and messages containing file attachments (e.g., images or video), iMessage delivers the encrypted data using a etwork o er tor Apple operates centralized infras- separate mechanism. First, the client generates a 256- tructure for both public key distribution and mes- sage transmission/storage. Potential adversaries in- bit AES key and encrypts the attached data using AES in CTR mode. It next uploads the resulting en- clude Apple, a government, or a malicious party crypted document to Apple’s iCloud service and obtains with access to Apple’s servers. a uni ue icloud.com URL and an access token for the Each of these attackers may be active or passive. A attachment. In the course of this process, the iCloud passive attacker simply observes traffic and does not seek service may redirect the client to upload the encrypted to alter or inject its own messages. An active attacker file to a third-party storage server operated by an outside may issue arbitrary messages to any party. In many provider such as Amazon, Microsoft or Google. Hav- cases, these adversary classes may interact. As in [38] ing uploaded the attachment, the client now constructs we assume that adversaries also have access to the mes- a standard iMessage plist containing the URL and ac- saging system and can use the system to register accounts cess token, the key , and a SHA1 hash of the encrypted and transmit messages as normal participants. We also document. This plist, which may also include normal assume that the endpoints in the conversation are secure. message text, is encrypted and transmitted to the Recip- ient using the standard message encryption mechanism. Upon receiving and decrypting the message, the Recip- g le el rotocol An l s s ient downloads the attachment using the provided URL and access token, verifies that the provided hash matches An initial analysis of the iMessage specification shows the received attachment, and decrypts the attachment us- that the protocol suffers from a number of defects. In this section we briefly detail several of these limitations. In ing . the following sections we focus on specific, exploitable flaws in the encryption mechanism. ec r t go ls re t model e ser er nd reg str t on iMessage key manage- Apple has stated that iMessage is an end-to-end encryp- ment uses a centralized directory server (IDS) which is tion protocol that should be secure against all attackers operated by Apple. This server represents a single point that do not have control of Apple’s network. We base of compromise for the iMessage system. Apple, and any our threat model on a recent survey on secure messag- attacker capable of compromising the server, can use this ing by Unger et al [38]. This threat model includes the server to perform a man-in-the-middle attack and obtain following attackers: complete decryption of iMessages. The current gener- oc l Ad ers r This includes an attacker with con- ation of iMessage clients do not provide any means for trol over local networks, either on the Sender or Re- users to compare or verify the authenticity of keys re- cipient side of the connection. ceived from the server. Of more concern, Apple’s “new device registration” lo l Ad ers r An attacker controlling large seg- mechanism does not include a robust mechanism for no- ments of the Internet, such as powerful nation states tifying users when new devices are registered on their
658 25th USENIX Security Symposium USENIX Association devices running iOS 8 (and earlier) or versions of OS X released prior to December 2015 may still be vulnerable to such attacks. For example, at the time of our initial disclosure in November 2015 to Apple, pinning was not Original message from Bob present in OS X 10.11.
Non-standard encryption iMessage encryption does Attacker replays Bob’s message not conform to best cryptographic practices and gener- ally seems ad hoc. The protocol (see Figure 1) insecurely Figure 2: Example of a simple ciphertext replay. composes a collection of secure primitives, including RSA, AES and ECDSA. Most critically, iMessage does not use a proper authenticated symmetric encryption al- account. This mechanism is triggered by an Apple push gorithm and instead relies on a digital signature to pre- message, which in turn triggers a uery to an Apple- vent tampering. Unfortunately it is well known that in the operated server. Our analysis shows that these protec- multi-user setting this approach may not be sound [21]. tions are fragile in Appendix A we implement attacks In the following sections, we show that an on-path at- against both the key server and the new device registra- tacker can replace the signature on a given message with tion process. that of another party. This vulnerability gives rise to a practical chosen ciphertext attack that recovers the full Lack of forward secrecy iMessage does not provide contents of some messages. any forward secrecy mechanism for transmitted mes- sages. This is due to the fact that iMessage encryption keys are long-lived and are not replaced automatically 5 Attacks on the Encryption Mechanism through any form of automated process. This exposes In this section we describe a practical attack on the iMes- users to the risk that a stolen device may be used to de- sage encryption mechanism (Figure 1) that allows an at- crypt captured past traffic. tacker to completely decrypt certain messages. Moreover, the use of long term keys for encryption can increase the impact of other vulnerabilities in the sys- tem. For example, in 5, we demonstrate an active attack 5.1 Attack setting on iMessage encryption that exposes current iMessage Our attack assumes that an adversary can recover en- users to decryption of past traffic. The risk of such at- crypted iMessage payloads and subse uently access the tacks would be greatly mitigated if iMessage clients pe- iMessage infrastructure in the manner of a normal user. riodically generated fresh encryption keys. See 7 for The first re uirement implies one of two conditions: in proposed mitigations. condition (1) the attacker is on-path and capable of inter- cepting encrypted iMessage payloads sent from a client Replay and reflection attacks The iMessage encryp- to Apple’s Push Notification Service (APNs) servers. tion protocol does not incorporate any mechanism to pre- Since the APNs protocol employs TLS to secure connec- vent replay or reflection of captured ciphertexts, leading tions between the client and APNs server, this attacker to the possibility that an attacker can falsify conversation must possess some means to bypass the TLS encryption transcripts as illustrated in Figure 2. A more serious con- layer we discuss TLS interception in more detail in Ap- cern is the possibility that an attacker, upon physically pendix B. In condition (2) the attacker can recover iMes- capturing a device, may replay previously captured traf- sage ciphertexts from within Apple’s network. This re- fic to the device and thus obtain the plaintext. uires either a compromise of Apple’s infrastructure, a rogue employee, or legal compulsion. Figure 3 describes Lack of certificate pinning on older iOS versions the network flow of a single iMessage, along with poten- iMessage clients interact with many Apple servers. As of tial attacker locations. December 2015, Apple has activated certificate pinning on both APNs and ESS/IDS connections in iOS 9 and OS 5.2 Attack overview X 10.11. This eliminates a serious attack noted by Ray- nal et al [34] in which an MITM attacker who controls There are two stages of the attack. The first exploits the Sender’s local network connection and possesses an a weakness in the design of the iMessage encryption Apple certificate can intercept calls to the ESS/IDS key composition: namely, that iMessage does not properly server and substitute chosen encryption keys for any Re- authenticate the symmetrically encrypted portion of the cipient (see Appendix A for further details). We note that message payload. In a properly-designed composition,
USENIX Association 25th USENIX Security Symposium 659 iCloud Amazon Google linear under XOR but the compression function is not, Content S3 Storage we can verify guesses about message content by edit- (3) iCloud.com ing the compressed, encrypted message and testing if the (8) apsd 4 5 apsd corresponding correction to the CRC results in a valid 4 (2) APN server(s) (7) message. Messages A Messages 1 6 app app ESS/IDS B C Sender machine Recipient machine Apple network A form t or cle tt ck for gzip com ress on Figure 3: The process of sending an iMessage through The format [23] uses DEFLATE compression the APNS network. The steps are as follows: (1) The gzip which itself combines LZ77 [41] and Huffman coding Sender contacts ESS/IDS to obtain the public keys for to efficiently compress common data types. The format each Recipient (2) (optional) the Sender contacts iCloud supports both static and dynamically-generated Huff- to upload an attachment (3) (optional) the Sender up- man tables, though most encoders use dynamic tables loads the encrypted attachment to an outside storage for all but the shortest messages. To compress a mes- provider as directed by iCloud (4) the Sender’s apsd in- sage, a CRC32 C is calculated over the uncompressed stance transmits the encrypted iMessage payload to Ap- input. Next, the encoder identifies repeated strings and ple’s APNs server (5) Apple delivers the payload to a replaces each repeated instance with a tuple of the form Recipient (6) the Recipient contacts ESS/IDS to obtain length,backwards distance , where distance indicates the Sender’s public key (7) (optional) the Recipient con- the relative position of the previous instance of the string. tacts iCloud if an attachment is present (8) (optional) The input is encoded using an alphabet of 286 symbols, the Recipient downloads the encrypted attachment from comprising the 256 byte literals, an end-of-block (EOB) an outside storage provider. Potential attacker locations symbol, and 29 string replacement length values.5 If dy- are labeled A, B and C. namic generation is selected, a Huffman table T is calcu- lated using the resulting text as a basis (for static tables, T = ε), and the text is Huffman coded into a string of this section of the ciphertext would be authenticated us- variable-length symbols S =(s1,...,sN) where string re- ing a MAC in generic composition [14] or via an AEAD placement symbols are internally partitioned into a pair mode of operation. Apple, instead, relies on an ECDSA length,distance . The resulting compressed message signature to guarantee the authenticity of this ciphertext. consists of (T,S,C). On decompression the process is In practice, a signature is insufficient to prevent an at- reversed and the CRC of the resulting string is compared tacker from mauling the ciphertext since an on-path at- to C. If any step fails, the decompressor outputs . tacker can simply replace the existing signature with a ⊥ new signature using a signing key from an account con- Attack intuition Our attack assumes that the attacker has trolled by the attacker. In practice, the actual attack is intercepted a gzip compressed message encrypted using slightly more complex the first phase includes additional an unauthenticated stream cipher and that we have access operations to defeat a countermeasure in the decryption to a decryption oracle that returns 1 if and only if the mechanism, which we discuss below. message decrypts and successfully decompresses. Our The second stage of the attack leverages the ability to goal is to recover a substantial fraction of the plaintext modify the AES ciphertext (specifically, the section not message. contained within the RSA ciphertext). This phase con- For clarity, we assume the attacker knows the Huff- sists of an adaptive chosen ciphertext attack exploiting man table T and the length in bits of the uncompressed the structure of the underlying plaintexts. The attack re- input. We further assume the attacker knows the exact peatedly modifies the ciphertext and sends it to either the location in the ciphertext corresponding to some (un- Sender or a Recipient for decryption. If the attacker can known) -bit Huffman symbol s that she wishes to re- determine if decryption and parsing were successful on cover, as well as the position of the corresponding de- the target device, she can gradually recover the underly- coded literal in the uncompressed text. These are simpli- ing iMessage payload. fying assumptions and we will remove them as we pro- The attack specifics are reminiscent of Vaudenay’s ceed. padding oracle attack [40], but relies on the usage of Given a ciphertext c, our attack works by first select- ing a mask M 0,1 ,M =0 and perturbing the ci- compression within the iMessage protocol. Specifically, ∈{ } our attack takes advantage of the 32-bit CRC checksum, 4Were the compression function and CRC both linear, the edit to computed over the pre-compressed message, incorpo- the CRC and compressed text would always cancel. rated into gzip compressed ciphertexts. Since CRCs are 5A separate Huffman table is used to encode backwards distances.
660 25th USENIX Security Symposium USENIX Association phertext such that the underlying symbol s will decrypt CASE 2: In this case, the symbol represented by s (resp. to s = s M. This is done by oring M into the cipher- s ) is referenced by one or more subsequent instances of ⊕ text at the appropriate location. Let decode(T,s) and DEFLATE string repetition. The practical impact is that decode(T,s ) represent the Huffman decoding of s and modifying s will produce an identical alteration at two s respectively, and let repeats be a boolean variable that or more positions in the decoded string and with high is true if and only if s (resp. s ) is repeated subsequently probability none of the experiments indicated for Case 1 via a DEFLATE string replacement reference. The po- will succeed. tential values of these three variables can be categorized In some circumstances, it may be cost effective for the into the following seven cases: attacker to skip s and simply move on to the next sym- bol in S. Alternatively, the attacker can experimentally Case decode(T,s) decode(T,s M) repeats ⊕ 1 [0,255] [0,255] False modify the CRC to indicate the same alteration at all po- 2 [0,255] [0,255] True sitions that could be affected by modifying s. Since the 3 [0,255] [256,285] (either) attacker does not know the locations at which s is re- 4 [0,255] (either) ⊥ 5 [256,285] [0,255] (either) peated or the number of such locations, this requires the 6 [256,285] [256,285] (either) attacker to submit many candidate ciphertexts to the or- 7 [256,285] (either) ⊥ acle, one for each possible set of locations where s may repeat. In the event that s (resp. s ) is repeated only once, In the following paragraphs, we consider the outcome of this requires the attacker to issue 28 ( d)/8 queries · − our experiment for each of the cases above. to the oracle (one for each value of i and for each pos- CASE 1: In this case, when the attacker submits the sible location for the repeated value of s ). This may be mauled ciphertext to the decryption oracle, the oracle feasible for reasonably short strings. will internally decode a result that differs from the origi- CASES 3-4: In these cases, the original decoding of s nal input string in exactly one byte position: the position was a byte literal, but the decoding of s is either an in- corresponding to symbol s . However, with overwhelm- valid symbol or a special symbol (EOB or string replace- ing probability, the CRC C of the decompressed string ment symbol). The former case always results in decom- will not match C and cause the oracle to output 0. pressor failure, while the latter will typically cause the Because CRC is linear under XOR, the attacker may decoded string to differ from the original input at multi- correct the encrypted value C by further mauling the ci- ple locations, resulting (with high probability) in a CRC phertext. Let d indicate the bit position of the sym- comparison failure that will not be corrected by the pro- bol associated with s (resp. s ) in the decoded mes- cedure described above. sage. For each i 0,1 8 the attacker ors the string To address these cases, the attacker may select a new d ∈{d } C = CRC(0 i 0 − ) CRC(0 ) with the ciphertext at mask M = M = 0 and repeat the complete experiment || || ⊕ the known location of C and submits each of the re- described above. Depending on the structure of the Huff- sulting ciphertexts for decryption. Since we have that man table T, and provided that s [0,255], the new result ∈ decode(T,s ) [0,255], one of these tests will always s M may produce an outcome that satisfies the condi- ∈ ⊕ result in a successful CRC comparison. tions of cases (1) or (2).6 Upon receiving a successful result from the decryp- tion oracle, the attacker now examines the Huffman ta- CASES 5-7: These cases occur when the original sym- ble T to identify candidate symbols s for which relation bol represented by decode(T,s) is a string replacement or EOB symbol. In most instances, replacing s with (s M) decode(T,s M)=decode(T,s) i holds. If the attacker ⊕ ⊕ ⊕ cannot identify a unique solution for s, she may select a produces a decoded string that differs from the original new M = M = 0 and repeat the procedure described in many positions, making it challenging for the attacker above until she has uniquely identified s. The attacker to repair the CRC. If s decodes to a string replacement can now increment her position in the ciphertext by token, and the replacement reference points to a location bits and repeat this process to obtain the next plaintext that the attacker has already recovered, it may be possi- symbol. ble for the attacker to detect the alteration using the tech- If this experiment is unsuccessful, it indicates that the nique described under Case 2. Otherwise the attacker ciphertext is not in Case 1 from the above table. To de- must skip s and move on to the next symbol in S. termine which case applies, the attacker must conduct Recovering the unknowns The procedure described so additional experiments as described below. Sometimes far requires the attacker to know the Huffman table T, the recovery of the symbol s will not be feasible at all when 6In principle, this approach might require as many as 28 2 M = this occurs, the attacker must simply continue to the next · | | 28+ decryption queries to obtain a successful result, or rule out these symbol in S. Occasionally, the adversary may still be cases. In practice, however, the number of candidate mask values M is able to recover s at some additional cost. likely to be much more limited.
USENIX Association 25th USENIX Security Symposium 661 length of the uncompressed message , the location and attacker controls), the attacker can simply direct the tar- length of the symbol s, and the byte index of the corre- get device to issues HTTPS to a machine that the at- sponding decompressed literal. In practice many of these tacker controls. This allows the attacker to conduct the uantities may be determined experimentally by iterat- attack remotely by transmitting ciphertexts through Ap- ing through candidate values for , ,k and the symbol ple’s APNs network, at which point she obtains the full position. This re uires the attacker to issue many candi- HTTPS POST re uest from the target device. Since the date decryption re uests until one succeeds. In the case attacker controls the re uest domain, there is no need to of iMessage attachment messages, the length is fixed MITM the TLS connection.7 and an attacker can generate a representative corpus of messages offline and easily estimate the other parame- ters without oracle ueries. An Att ck on Att c ment ess ges Recovering the Huffman table is more challenging. If Having provided an overview of the attack components, the message is encoded using a static table, then the ta- we will describe each individual step of the complete at- ble is known to the attacker. However, if T is dynam- tack. This attack scenario assumes that a target Sender ically generated, then the attacker learns only the re- has transmitted an attachment-bearing message to one or lation decode(T,s M)=decode(T,s) i, but has no ⊕ ⊕ more online receivers, and the attacker has the ability to clear way of learning s or decode(T,s). Nonetheless, monitor the local network connection (and intercept TLS it might still be possible to recover enough information connections) on one of the Sender or Recipient devices. from these relations to recover the value of the underly- ing literals. te Removing and replacing the iMessage signature However, in iMessage this proves unnecessary as we Each iMessage is authenticated using an ECDSA sig- take advantage of iMessage’s structure to recover a large nature, formulated using the private key of the iMessage fraction of the dynamic table T. iMessage payloads con- Sender. This signature prevents the attacker from directly taining attachments embed a URL within the encrypted tampering with the message. However, a limitation of us- message, re uests to which can be monitored (described ing signatures for authenticity is that they do not prevent below). In this way, we learn the file path and/or host- ciphertext mauling when an attacker controls another ac- name indicated by the plaintext URL within each cipher- count in the system. An attacker who intercepts a signed text. Given this information, and by mauling individual iMessage may simply remove the existing signature from symbols s contained within the URL string, the attacker the message and re-sign the message using a different can recover the value decode(T,s M) for many differ- ⊕ key, corresponding to a separate account that the attacker ent values of M. This allows the attacker to identify a controls.8 The attacker now transmits the resulting en- relative-distance map of a portion of the Huffman tree. crypted payload, signed and delivered as though from a This proves sufficient to recover much of the Huffman different Sender address. The signature replacement pro- table T. cess is illustrated in Figure 4. Detecting successful decryption Our attack assumes that In practice, simply replacing the signature on a mes- the attacker can detect successful decryption of a modi- sage proves insufficient. In iMessage, a full list of Sender fied ciphertext. To simplify this assumption, we focused and Recipient addresses is specified both in the unen- on messages containing attachments, such as images and crypted metadata for the message and in the encrypted videos. These messages include a URL for downloading message payload. Upon decrypting each message, iMes- the attachment payload, as well as a 256-bit AES key to sage clients verify that the message was received from be used in decrypting the attachment. When an iMessage one of the accounts listed in the Sender/Recipient list, client correctly decrypts such a message, it automatically and silently abort processing if this condition does not initiates an HTTPS POST re uest to the provided URL. hold.9 While it is trivial to replace the unencrypted A local network attacker can view (and intercept) this Sender field, replacing encrypted envelope information re uest to determine whether decryption has occurred. is more challenging. Fortunately, in most cases this field Moreover, if the attacker blocks the connection, the de- of the iMessage plist is contained within the malleable vice will retry several times and then silently abort. Since 7 the client provides no indication to the user that a mes- The current versions of Apple’s Messages client do not enforce that this URL contains icloud.com and will connect to any hostname sage has been received, this admits silent decryption of provided in the URL. Similarly, the Messages client does not pin cer- ciphertexts. tificates for the HTTPS connection. This techni ue can also be extended to situations 8On Mac OS X, iMessage signing keys are readily accessible from where the attacker is not on the target device’s local net- the Apple Keychain. 9Based on our experiments, the participant list does not appear to work. By mauling the URL field to change the re uested be ordered, or to distinguish between Sender and Recipients. It is suf- hostname (e.g., from icloud.com to a domain that the ficient that the Sender identity appears somewhere in this list.
662 25th USENIX Security Symposium USENIX Association AES-CTR ciphertext, and we are able to alter the con- RSA ciphertext partial AES ciphertext sig A tents of the Sender/Recipient list so that it contains the Change sender ID (A->B) Modify payload, adjust CRC Sign with skB identity of the replacement Sender account. RSA ciphertext modified partial AES ciphertext sig B Figure 4: Modifying the partial AES ciphertext, includ- te Altering the Sender identity ing the Sender ID and CRC, and replacing the signature To alter the Sender identity, the attacker must selec- with a new signature corresponding to an account (and tively maul the AES-CTR ciphertext to change specific signing key) we control. bytes of the Sender/Recipient plist field to incorpo- rate the new Sender identity she is using to transmit the mauled ciphertext. This is challenging for several rea- tention to addresses that differ from the original Sender sons. ID in at most one symbol position. This is accomplished First, the initial 101 bytes of the AES ciphertext by registering new iCloud addresses that are “one off” are stored within the RSA-OAEP ciphertext, which is from the target Sender identity. To increase the likeli- strongly non-malleable. Thus we are restricted to alter- hood that we will succeed in altering the Sender account ing the subsequent bytes of the ciphertext. Fortunately, to match one that we have selected, we register multiple the binary plist key-value data structure is top heavy, new Sender identities that are near matches to the origi- in that it stores a list of all key values in the data struc- nal identity. For each attempt at mauling the ciphertext, ture prior to listing the values associated with each key. we must also “repair” the CRC by guessing the effect of In practice, this ensures that the relevant Sender iden- our changes on the decompressed message. tity appears some distance into the data structure. More- In our experiments, we found that an email address of over, the application of gzip compression produces ad- the form [email protected] could be efficiently mod- ditional header information, including (in many cases) ified to a new account of the form [email protected] a dynamic Huffman table. In all of the cases we ob- in approximately 210 decryption queries to a target de- served, the symbols encoding the Sender identity are lo- vice.10 Since Huffman tables vary between messages, we cated subsequent to the first 101 bytes, and are therefore cannot mutate every message to the same domain, and not included within the OAEP ciphertext. thus we need to control several variants of icloud.com The use of gzip compression somewhat compli- for this strategy to be successful in all cases. Fortunately, cates the attack. Rather than mauling uncompressed the edits are predictable and our simulations indicate that ASCII bytes, the attacker must alter a set of compressed we require only one domain to recover most messages. Huffman symbols which have been encoded using a A side effect of this modification is that, due to string (dynamically-generated) table T that the attacker does replacement in gzip, the attachment URL is simultane- not know. Fortunately, the attacker knows the original ously altered to point to i8loud.com, which means that identity of the Sender, as this value is transmitted in the attachment HTTPS POST requests are sent to a computer unencrypted apsd metadata. Moreover, in all iMessage under our control. This makes it possible to conduct the clients that we examined, the Sender identity is transmit- attack remotely. ted as the first string in the Sender/Recipient list, which – te Recovering the Huffman table Given the abil- due to iMessage’s predictable format – appears in a rela- ity to intercept the attachment request POST URL to tively restricted range of positions within the ciphertext. , we now recover information about the dy- Even with this knowledge, altering the Sender ID in- icloud.com namic Huffman tree T used in the message. The attach- volves a large component of guessing. The attacker first ment path consists of a string of alphanumeric digits, estimates the location of the start of the Sender/Recipient which in most instances are encoded as Huffman sym- list, then selectively mauls the appropriate portions of the bols of length [4,8]. AES ciphertext, while simultaneously updating the CRC ∈ By intercepting the HTTPS connection to to contain a guess for the modified (decoded) symbol. , the attacker can view the decoded This is a time consuming process, since the attacker must icloud.com URL path and systematically maul each Huffman simultaneously identify (1) the appropriate location in symbol in turn, repairing the CRC using the technique the ciphertext for the symbol she wishes to modify and described in the previous subsection. This allows the (2) a modification that causes the symbol to change to attacker to gradually recover a portion of the Huffman the required symbol. The target device will silently ig- tree (Figure 5). In practice, the attacker is able to nore any incorrect guesses and will proceed with attach- recover only a subset of the tree, however, because ment download only when the mauled Sender ID in the the iMessage client will silently fail on any URL that plist is equal to the Sender ID from which the attacker is transmitting. 10These email addresses are examples and not the real email ad- To simplify the attack, the attacker may restrict her at- dresses we used in our experiments.
USENIX Association 25th USENIX Security Symposium 663 counterintuitive to expect repeated strings within a ran- dom key, this occurrence is surprisingly common due to the fact gzip will substitute even short (3 digit) strings. Indeed, on average we encounter 1.9 three-digit repeti- tions within each key. In this case, we attempt to iden- tify subse uent appearances of the symbol by guessing later replacement locations. If this approach fails, our approach is to simply ignore the symbol and experimen- Figure 5: Fragment of a Huffman tree from an attach- tally move forward until we reach the next symbol. ment iMessage. While it is possible to recover a larger fraction of the symbols in the message by issuing more decryption ueries (see 6 for a discussion of the tradeoffs), in many contains characters outside the allowed URL character cases it is sufficient to simply guess the missing bitsof set.11 Fortunately this set includes most printable the key offline after recovering an encrypted attachment. alphanumeric characters. In practice, the entropy of the missing sections is usually Our implementation recovers a portion of the Huffman much lower than would be indicated by the number of tree that is sufficient to identify the characters in the set missing bits, since in most cases the replacement string 0 9, A . Our experiments indicate that this phase of is drawn from either the URL field or earlier sections of − − the process re uires an average 217 decryption re uests the key, both of which are known to the attacker. and a maximum of 219. te Recovering the message contents Each attach- ment message may also contain message text. This text Recovering the attachment encryption key When te can be read in a manner similar to the way the key is an iMessage contains an attachment, the message em- recovered in the previous step, by mauling the message beds a 256-bit AES key that can be used to decrypt the portion of the text and editing the CRC appropriately. attachment contents. This key is encoded as 64 ASCII This approach takes slightly more effort than the hex- hexadecimal characters and is contained within a field adecimal key recovery step, due to the higher number of named . An attacker with oracle ac- decryption-key potential values for each Huffman symbol in the message cess to a target device, and information on the Huffman text. table T, can now systematically recover bytes from this key. Upon recovering the key, they can use the inter- cepted HTTPS re uest information to download the en- m lement t on nd l t on crypted attachment and decrypt it using the recovered key. st m t ng tt ck d r t on The approach used in recovering the attachment key is an extension of the general format oracle attack de- To validate the feasibility of the attack described in 5.4, scribed above. The attacker first searches the cipher- we implemented a prototype of the gzip format oracle text to identify the first position of the decryption key attack in Python and executed it against the Messages field. The attacker identifies amask M (typically a sin- client on OS X 10.10.3. Our attack successfully recov- gle or double-bit change to the ciphertext) that produces ered 232 out of 256 key bits after 218 decryption ueries a change in the decoded message at the first position to the target device. The main challenge in running the of the encryption key, which is known due to the pre- attack was to determine the correct timeout period after dictable structure of attachment messages. To identify which we can be confident that a message has not been this change, the attacker “fixes” the CRC to test for successfully decrypted. This timeout period has a sub- each possible result from the decryption key, then learns stantial impact on the duration of the attack, as we de- whether the decryption/decompression process succeeds. scribe below. To obtain the full key, the attacker repeats this process for each of the 64 hexadecimal symbols of the encryption key. er ment l et To deliver iMessage payloads to This process does not reliably produce every bit of the the device, we customized an open-source Python project key, due to some complications described in the gen- called pushproxy (hereinafter called the proxy) and eral attack description above. Principal among these is used it to intercept connections from the device to Ap- the fact that some Huffman symbols represent string re- ple’s APNs server [3]. This approach models an at- placement tokens rather than byte literals. While it seems tacker who can either impersonate or control Apple’s APNs servers. While our attack assumed local network 11iMessage does not perform URL coding on disallowed characters. interception and did not send messages through Apple’s
664 25th USENIX Security Symposium USENIX Association servers, we note that if an attacker is able to capture mes- timeout period after which we can determine that the de- sages in transit (by bypassing TLS or by compromising vice has been unable to successfully decrypt and process Apple’s servers), the remainder of the attack can in prin- a message. To determine this, our attack queries the gzip ciple be conducted remotely (see the end of 5.3 for de- format oracle by sending a candidate message and wait- tails). For ethical and legal reasons, we explicitly chose ing until it either sees a resulting attachment download not to test attacks that relayed messages via Apple’s pro- (in which case the message decrypted) or some timeout duction servers. Thus all of our attacks were conducted passes. Too long of a timeout results in unreasonable via a local network. runtimes and too short of a timeout produces false nega- To address the use of TLS on apsd connections, we tives, which lead to incorrect key recovery. configured our modified proxy with a forged Apple cer- Small scale experiments proved unable to reliably esti- tificate based on a CA root certificate we created and mate the maximum timeout: the observed wait time dis- change /etc/hosts to redirect APNs connections in- tribution seemingly has a long tail and may be dependent tended for Apple towards our local proxy. We generate on load not encountered in small experiments (e.g. due to the forged certificate by installing our root CA on the tar- failed decryptions). Using the full attack code to find the get system.12 max timeout, on the other hand, is impractical, since we To monitor and intercept attachment download re- must run 218 queries, each lasting as long as the timeout. quests, we configured an instance of a TLS MITM proxy This would take between 18 hours and 3 days depending (mitmproxy) using our self-signed root certificate to in- on the timeout duration we wish to test. tercept all outbound requests from the device made via In order to estimate the correct timeout, we ran our HTTP/HTTPS. When the target device receives an at- attack on the device in tandem with a local instance of tachment message, it makes two HTTPS POST requests the format oracle which, using the recipient’s private key, to 0,...,255 -content.icloud.com. Based on the also decrypts the message and emulates iMessage’s be- { } result of these requests, the device issues a second HTTP havior. If the candidate message fails to decrypt against GET request to download the actual attachment. In our the local oracle, we use a short (400ms) timeout period. experiments we block both of the POST requests, ensur- If the candidate message decrypts successfully on this ing that no indication of the message processing is dis- local oracle, then we wait an unbounded amount of time played by the Messages client. For each oracle query, the for the oracle query and record the necessary delay. We attack code waits for mitmproxy to report an attachment stress that this local-oracle approach was used only to POST request as defined above or, after a set time out, speed up the process of finding the maximum delay the assumes the oracle query resulted in a failed message. full attack can be conducted without knowledge of the Finally, we created an iMessage account for the at- private key. tacker that is a single-character edit of the sender’s ad- dress (e.g. if the sender is alice example.com, the at- tacker might be clice example.com). We only generate Res lts We ran our main experiment on a real mes- sage intercepted using the proxy. It recovers 232 out of one such account for the edit we expect to be successful, 18 although a real attacker might register a large corpus of 256 key bits in 2 queries and took 35 hours to run. The iMessage accounts and thus increase the success proba- maximum observed delay between a query and the re- bility of this phase of the attack. sulting download request was 903ms, while the average was 390ms with a standard deviation of 100ms. Based on this data, and without considering further optimizations, er f ng t e e stence of t e or cle To ensure that we estimate that the full attack would require approxi- iMessage behavior is as expected, we conducted a series mately 73 hours to run if we naively used 1 second as the of tests using hand-generated messages to determine if timeout. we were able to detect decryption success or failure on these messages. Our results were sufficient to confirm the vulnerability of 5 and verify iMessage’s behavior t m ng r nt me The obvious approach to opti- sufficiently well that we could construct a simulated ora- mizing our attack is to reduce the timeout period to the cle for our experiments of 6.2. minimum period that iMessage requires to successfully process and queue a message. Through experiments, we determined this to be approximately 400ms. Thus st m t ng t e t meo t for f led er es The main one avenue to optimizing the experiment is to reduce the goal of our experiment was to determine the maximum timeout period for all messages to 400ms, using the as- sumption that a successful experiment may result in a 12Since OS X 10.10.3 does not include certificate pinning for APNs connections, this allowed us to intercept and inject iMessage cipher- “late” download. Since we would not be able to neatly texts. determine the specific message query that occasioned the
USENIX Association 25th USENIX Security Symposium 665 download, we would need to temporarily increase the de- For performance, it skips encryption and decryption.14 lay period and “backtrack” by repeating the most recent, Decompression is done using Python’s gzip module, e.g., 10 queries to determine which one caused the down- which is a wrapper around on zlib. We experimentally load. Because the issue is patched and further explo- validate the oracle’s correctness against the transcript of ration difficult, we have elected not to implement these a real attack and against separate messages. optimizations. 13 Because successful queries are quite sparse, this Res lts We ran our simulated attack on a corpus of does not meaningfully affect the number of queries 10,000 generated messages and show the results in Fig- needed for the attack. In our estimation, these techniques ure 6. In all cases, our experiments completed in at will reduce the cost of the full attack down to 35 hours most 219 queries, with an average of approximately 217 and requires only straightforward modifications to our queries. For 34 of the experiments we ran, our attack proof of concept code. was able to recover 216 bits of the attachment AES ≥ A second optimization is to run the attack against mul- key. For 23 of the messages we experimented with, tiple devices with attack queries split and conducted in we recovered 224 bits of the key, enabling rapid brute- ≥ parallel against them. For n devices, the attack time is force of the remaining bits on commodity hardware.15 reduced by approximately a factor of n. As many users may have 2 or 3 devices, this can offer substantial reduc- t m ng s ccess r te Many of the failures we ex- tions. perience in key recovery are caused by issues with string Finally, we can reduce the raw number of queries repetition. Recall that repeated substrings in a message needed to mount the attack by refining the gzip-oracle are compressed in gzip by replacing all subsequent rep- attack techniques. In particular, we can reduce the num- etitions of the substrings with a backwards-pointing ref- ber of queries needed to recover the Huffman table by erence. As a result, editing the canonical location of a inferring the structure of the tree from the partial infor- substring in the compressed message may cause similar mation we have and from the observation that the Huff- changes to future instances of the same substring in the man trees fall within a fairly limited range of distribu- decompressed message. Our CRC correction for a given tions. In particular we note that for the Huffman trees location fails to compensate for these later changes be- used in gzip, recovering the symbol lengths alone is suf- cause we simply do not know where in the uncompressed ficient to recover the tree. An approach drawing from message the second instance of the substring appears. As techniques in machine learning to recover the Huffman a result, our current attack simply skips these bits. table given only a few queries, the distribution of such ta- However, we can address this weakness with only a bles, and known partial information could offer substan- modest increase in the number of oracle queries. By tial improvements. We leave a full exploration of these scanning through the remaining bytes and applying the optimizations to future work. same CRC correction at each subsequent location in the uncompressed message, we can identify the location of the subsequent instances of the substring. This is effi- m l t on res lts cient mainly for strings that are repeated twice, but our Although we have conducted our attack on iMessage, we experiments indicate this is the most common case. Note have not explored its effectiveness with a large range of that we do not need to scan through the entire mes- messages. Given the time it takes to run an experiment, sage. As a result of the particular format of the mes- doing so is prohibitive. We opt instead to simulate our sages, there are only a few points where we can get dupli- results. cates: most of the message is in lowercase letters or non- printable characters, whereas the decryption-key and mmcs-url field (i.e. the locations where repeats cause m l t on To evaluate the overall effectiveness of our the most serious issues) are upper case alpha-numeric format oracle attack, we constructed a simulated mes- and hence will not contain repeats from the majority of sage generator and decryption oracle. Messages pro- the other fields. For the experiments described above, duced by our generator are distributed identically to 14Our implementation prevents the attacker from modifying the first real attachment-bearing messages, but contain randomly- 101 bytes of the message, as those are normally contained within the generated strings in place of the filename, URL path, RSA ciphertext. Additionally, the oracle enforces that the alleged Sender and Recipient addresses, decryption key, and Sender identity is included within the plist, which is a condition en- “signature” (hash) fields. The decryption oracle emulates forced by iMessage. 15Experiments on an inexpensive Intel Core i7 show that we can re- the iMessage client’s parsing of the inner binary plist. cover 32 missing key bits in approximately 7 minutes using an AES-NI implementation. Therefore recovering 40 missing key bits should take 13Out of the 218, only 418 were successful. approximately 28 hours on a single commodity desktop.
666 25th USENIX Security Symposium USENIX Association (a) Number of queries vs number of recovered key bits. The (b) Distribution of attack length, measured in queries. The orange dashed line represents 216 bits recovered, the solid high concentration of attacks near zero is due to a rapid green line 224. failure when it fails to edit the sender email.
Figure 6: Simulation results for the attachment recovery attack. this would result in a 14 increase in the number of mes- 10.11.4. sages for which we can recover 224 bits. orce re-generation of all iMessage keys and destroy message logs. iMessage uses long-term decryption keys 7 Mitigations and offers no mechanism to provide forward secrecy. If possible, Apple should force all devices to re-generate Our main recommendation is that Apple should replace their iMessage key pairs and destroy previously-held se- the entirety of iMessage with a messaging system that cret keys. In addition, Apple should destroy any archives has been properly designed and formally verified. How- of encrypted iMessage traffic currently held by the com- ever, we recognize this may not be immediately feasi- pany. ble given the large number of deployed iMessage clients. Pin PS ESS certificates or sign ESS responses. The Thus we divide our recommendations into short-term current iMessage protocol relies heavily on the security “patches” that preserve compatibility with existing iMes- of TLS, both for communications with the key server and sage clients and long-term recommendations that require as an additional layer of protection for iMessage push breaking changes to the iMessage protocol. traffic. Apple should enhance this security by employing certificate (or public key) pinning within the Messages 7.1 mmediate mitigations application and apsd to prevent compromise of these connections. Alternatively, Apple could extend their pro- prietary signing mechanisms to authenticate key server uplicate S ciphertext detection. The attacks we responses as well as requests. described in 5 are possible because the unauthenticated AES encryption used by iMessage is malleable and does eorgani e message layout. The current layout of not provide security under adaptive chosen ciphertext at- encrypted messages includes approximately 101 bytes tack, unlike RSA-OAEP encryption [15]. Maintaining of the CTR message within the RSA-OAEP cipher- a list of all previously-received RSA ciphertexts should text, which is resilient to ciphertext malleability attacks. prevent these replay and CCA attacks without the need Modifying sender-side code to re-organize the layout of for breaking changes in the protocol. Upon receiving a the underlying plist data structure to incorporate the stale RSA ciphertext, the Recipient would immediately sender and receiver fields within this section of the mes- abort decryption. This fix does not prevent all possi- sage would immediately block our attack. Implement- ble replays, given that iMessage accounts may be shared ing this change requires two significant modifications: across multiple distinct devices. However, it would sub- (1) Apple would need to disable dynamic construction stantially reduce the impact of our attacks until a more of Huffman tables within the gzip compression, and (2) permanent fix can be implemented. Note: This modifica- restructure the binary plist serialization code to place the tion has been incorporated into iOS 9.3 and Mac OS X sender address first. We stress that this is a fragile patch:
USENIX Association 25th USENIX Security Symposium 667 if any portion of the sender ID is left outside of the timing [8, 19]. Some more recent works have pro- RSA ciphertext, the ciphertext again becomes vulnera- posed attacks on more complex data formats such as ble to mauling. Moreover, this fix will not protect group XML [27, 30]. messages where the list of Recipients is longer than 100 Various works have addressed the combination of bytes. compression and encryption. Some attacks use knowl- edge of a relatively small number of bytes in the plain- text to learn information about the compression algo- ong term recommend t ons rithm and eventually recover an encryption key [16, 37]. Kelsey [28] and others [29, 35] used compression in the Re l ce t e ess ge encr t on mec n sm Apple (partially) chosen plaintext setting to recover information should deprecate the existing iMessage protocol and re- about plaintexts. place it with a well-studied construction incorporating modern cryptographic primitives, forward secrecy and message authentication (e.g., OTR [17] or the TextSe- oncl s on cure/Axolotl protocol [4]). At minimum, Apple should use a modern authenticated cipher mode such as AES- In this work we analyzed the security of a popular end- GCM for symmetric encryption. This change alone to-end encrypted messaging protocol. Our results help would eliminate our active attack on iMessage encryp- to shed light on the security of deployed messaging sys- tion, though it would still not address any weaknesses in tems, and more generally, provide insight into the state the key distribution mechanism. In addition, iMessage of the art in security mechanisms currently deployed by should place the protocol versioning information within industry. This insight raises questions about the way re- the public key block and the authenticated portions of the search results are disseminated and applied in industry ciphertext, in order to prevent downgrade attacks. and how our community should ensure that widely-used protocols employ best cryptographic practices. m lement ke tr ns renc While many of the This work leaves several open questions. First, the protocol-level attacks described in this paper can be mit- gzip format oracle attack we describe against iMes- igated with protocol changes, iMessage’s dependence on sage may apply to other protocols as well. For example, a centralized key server represents an architectural weak- OpenPGP encryption (as implemented by GnuPG) [18] ness. Apple should take steps to harden iMessage against also employs gzip and may be vulnerable to similar at- compromise of the ESS/IDS service, either through the tacks when it is used for online applications such as in- use of key transparency [31] or by exposing key finger- stant messaging [2]. Moreover, our attack requires that prints to the user for manual verification. the adversary have some access to a portion of the de- crypted information. We leave to future work the devel- opment of a pure “blind” attack on gzip encryption, one Rel ted ork that does not require this additional information. There are three lines of research related to our work: se- cure message protocols, attacks on symmetric encryp- Acknowledgments tion, and decryption attacks using compression schemes. Instant messaging has received a great deal of atten- This work was supported by: The National Science tion from the research community. Borisov et al. in- Foundation under awards CNS-1010928 and EFRI- troduced OTR [17] and proposed strong properties for 1441209 The Office of Naval Research under contract messaging, such as per-message forward secrecy and de- N00014-14-1-0333 and The Mozilla Foundation. niability. Frosh et al. analyze descendant protocols such We also are deeply grateful to Nate Cardozo and Kurt as TextSecure [24]. More recent work has focused on Opsahl of the Electronic Frontier Foundation for provid- multi-party messaging [25] and improved key exchange ing us with legal advice during our work on this paper. deniability [39]. In a related area, Chen et al analyzed push messaging integrations, including Apple push net- working [20]. For a survey of secure messaging tech- References nologies, see [38]. [1] iMessage. In OpenIM Wiki, Available at https://imfreedom. A number of works have developed attacks on unau- org/wiki/IMessage. thenticated, or poorly authenticated, encryption proto- [2] MCABBER. Available at https://mcabber.com/. cols. In addition to the padding oracle of Vaudenay [40] [3] Pushproxy: A man-in-the-middle proxy for ios and os x device and later applications [13], padding oracle attacks have push connections. Available at https://github.com/meeee/ been extended to use alternative side channels such as pushproxy.
668 25th USENIX Security Symposium USENIX Association [4] Textsecure. https://github.com/WhisperSystems/ [22] COVERT, A. Apple’s iMessage is the DEA’s worst night- TextSecure/wiki/ProtocolV2. Accessed: 2014-11-13. mare. Available at http://money.cnn.com/2013/04/ , April [5] Trustwave to escape ‘death penalty’ for SSL skeleton key, 2012. 07/technology/security/imessage-iphone-dea/ 2013. [6] Apple pulls ad-blocking apps that can ‘compromise’ security. En gadget (October 2015). [23] DEUTSCH, P. RFC 1952: GZIP file format specification version 4.3, May 1996. [7] ABELSON, H., ANDERSON, R., BELLOVIN, S. M., BENALOH, J., BLAZE, M., DIFFIE, W. W., GILMORE, J., GREEN, M., [24] FROSCH, T., MAINKA, C., BADER, C., BERGSMA, F., LANDAU, S., NEUMANN, P. G., RIVEST, R. L., SCHILLER, SCHWENK, J., AND HOLZ, T. How secure is TextSecure? Cryp- J. I., SCHNEIER, B., SPECTER, M. A., AND WEITZNER, D. J. tography ePrint Archive, October 2014. Keys under doormats. Commun ACM , 10 (Sept. 2015), 24– [25] GOLDBERG, I., USTAOGLU˘ , B., VAN GUNDY, M. D., AND 26. CHEN, H. Multi-party off-the-record messaging. In CCS [8] ALFARDAN, N. J., AND PATERSON, K. G. Lucky thirteen: (New York, NY, USA, 2009), CCS ’09, ACM, pp. 358–368. Breaking the TLS and DTLS record protocols. In IEEE S&P (Oakland) (2013), pp. 526–540. [26] GRIFFIN, A. WhatsApp and iMessage could be banned under new surveillance plans. The Independent (January 2015). [9] APPLE COMPUTER. iOS Security: iOS 9.0 or later. Avail- able at https://www.apple.com/business/docs/iOS_ [27] JAGER, T., AND SOMOROVSKY, J. How to break XML encryp- Security_Guide.pdf, September 2015. tion. In ACM CCS (October 2011), ACM Press. [10] APPLE INC. Privacy. Available at http://www.apple.com/ [28] KELSEY, J. Compression and information leakage of plaintext. privacy/approach-to-privacy/, 2015. In SE (2002), vol. 2365 of LNCS, Springer, pp. 263–276.
[11] APUZZO, M., SANGER, D. E., AND SCHMIDT, M. S. Apple [29] KOHNO, T. Attacking and repairing the winZip encryption and other tech companies tangle with U.S. over data access. scheme. In ACM CCS (2004), ACM Press, pp. 72–81. Available at http://www.nytimes.com/2015/09/08/us/ politics/apple-and-other-tech-companies-tangle- [30] KUPSER, D., MAINKA, C., SCHWENK, J., AND SOMOROVSKY, with-us-over-access-to-data.html, September 2015. J. How to break XML encryption – automatically. In Proceed ings of the th USENIX Conference on Offensive Technologies [12] BARBOSA, G. Apple execs Eddy Cue & Craig Federighi talk (Berkeley, CA, USA, 2015), WOOT’15, USENIX Association. Apple Music, App Store & more in new interview. Available at http://9to5mac.com/2016/02/12/apple-execs-eddy- [31] MELARA, M. S., BLANKSTEIN, A., BONNEAU, J., FELTEN, cue-craig-federighi-talk-apple-music-app-store- E. W., AND FREEDMAN, M. J. CONIKS: Bringing key trans- more-in-new-interview/, February 2016. parency to end users. In USENIX (Washington, D.C., Aug. 2015), USENIX Association, pp. 383–398. [13] BARDOU, R., FOCARDI, R., KAWAMOTO,Y.,SIMIONATO, L., STEEL, G., AND TSAY, J.-K. Efficient padding oracle attacks [32] MESSIEH, N. Apple’s iMessage and Facetime blocked in the on cryptographic hardware. In CRYPTO , vol. 7417 of LNCS. UAE. TheNe tWeb (November 2011). Springer, 2012, pp. 608–625. [33] PALETTA, D. FBI Chief Punches Back on Encryption. Wall [14] BELLARE, M., AND NAMPREMPRE, C. Authenticated encryp- Street Journal (July 2015). tion; relations among notions and analysis of the generic compo- sition paradigm. J Cryptol , 4 (Sept. 2008), 469–491. [34] RAYNAL, F. iMessage privacy. Available at http://blog. quarkslab.com/imessage-privacy.html, October 2013. [15] BELLARE, M., AND ROGAWAY, P. Optimal asymmetric encryp- tion: How to encrypt with RSA. In EUROCRYPT (1994), [35] RIZZO, J., AND DUONG, T. The CRIME Attack. Avail- A. D. Santis, Ed., vol. 950 of LNCS, Springer, pp. 92–111. able at https://docs.google.com/presentation/d/ 11eBmGiHbYcHR9gL5nDyZChu_-lCa2GizeuOfaLU2HOU/ [16] BIHAM, E., AND KOCHER, P. C. A known plaintext attack edit#slide=id.g1d134dff_1_222, September 2012. on the PKZIP stream cipher. In ast Software Encryption Sec ond International Workshop euven, Belgium, December [36] SHIH, G., AND CARSTEN, P. Apple begins storing users’ per- , Proceedings (1994), pp. 144–153. sonal data on servers in China. Reuters (August 2014).
[17] BORISOV, N., GOLDBERG, I., AND BREWER, E. Off-the-record [37] STAY, M. ZIP attacks with reduced known plaintext. In ast Soft communication, or, why not to use PGP. WPES ’04, ACM Press, ware Encryption, th International Workshop, SE Yoko pp. 77–84. hama, Japan, April , , Revised Papers (2001), pp. 125– [18] CALLAS, J., DONNERHACKE, L., FINNEY, H., SHAW, D., AND 134. THAYER, R. RFC 4880: OpenPGP Message Format. Available at [38] UNGER, N., DECHAND, S., BONNEAU, J., FAHL, S., PERL, , November 2007. https://tools.ietf.org/html/rfc4880 H., GOLDBERG, I., AND SMITH, M. SoK: Secure messaging. [19] CANVEL, B., HILTGEN, A., VAUDENAY, S., AND VUAG- In IEEE S&P (Oakland) (2015). NOUX, M. Password interception in a SSL/TLS channel. In [39] UNGER, N., AND GOLDBERG, I. Deniable key exchanges for se- CRYPTO , vol. 2729 of LNCS. Springer Berlin Heidelberg, cure messaging. In Proceedings of the Nd ACM SI SAC Con 2003, pp. 583–599. ference on Computer and Communications Security (New York, [20] CHEN, Y., L I, T., WANG, X., CHEN, K., AND HAN, X. Per- NY, USA, 2015), CCS ’15, ACM, pp. 1211–1223. plexed messengers from the cloud: Automated security analy- sis of push-messaging integrations. In CCS (New York, NY, [40] VAUDENAY, S. Security flaws induced by CBC padding - appli- USA, 2015), CCS ’15, ACM, pp. 1260–1272. cations to SSL, IPSEC, WTLS. In EUROCRYPT (London, UK, 2002), vol. 2332 of LNCS, Springer-Verlag, pp. 534–546. [21] CHIBA, D., MATSUDA, T., SCHULDT, J. C. N., AND MAT- SUURA, K. Efficient generic constructions of signcryption with [41] ZIV, J., AND LEMPEL, A. A universal algorithm for sequential insider security in the multi-user setting. In ACNS (2011), data compression. IEEE Transactions on Information Theory , pp. 220–237. 3 (1977), 337–343.
USENIX Association 25th USENIX Security Symposium 669 Client profile.ess.apple.com GET /WebObjects/QueryService.woa/wa/query?uri=mailto AuthenticateUser(usr, pass) %3AXXXXXX2027%40icloud.com&weight=light HTTP/1.1 ServerResponse(at, status 0, id) Host: query.ess.apple.com AuthenticateDS(at, csrid, id) ServerResponse(certid, id, status 0) IDGetHandles(AH) ∈
nonceid, σdevice, and σid. 0x30 0x81 0xA9 0x02 0x81 0xA1 0x00 Public Exponent 1280 Bit RSA Key 0x02 0x03 0x01 0x00 0x01
Figure 10: Format of public key payload in ESS server A Att cks on e Reg str t on response
While this work focuses on the retrospective decryption of iMessage payloads, in the course of our reverse engi- user’s iCloud account name. We diagram the full login neering we were able to implement attacks on Apple’s and registration protocols in Figures 7 and 8. To sup- key registration infrastructure. The first attack is an im- port multiple devices on a single account, the IDS will plementation of attacks previously noted by Raynal et store and return all public keys associated with a given al [34]. In these attacks, which work only against ver- account. sions of iOS prior to iOS 9 and Mac devices prior to OS X 10.11.4 (i.e., devices without key pinning), an at- A e st t t on Att ck tacker with a forged Apple TLS certificate can intercept the connection to the Apple key server in order to sub- The Apple key distribution systems are accessed each stitute chosen public keys. Additionally, we find a novel time a legitimate user wants to send an iMessage to attack against the device registration process that allows a new Recipient. The Messages client first contacts an attack with stolen credentials to circumvent existing query.ess.apple.com to look up the keys for a given protection mechanisms. username. In response, the server returns the user’s pub- The protocol for registering a device is shown in lic key(s), status, and push tokens for addressing APNs Figure 8. The user first establishes a TLS connec- communications to the user. A fragment of the request tion to Apple’s IDS server and authenticates using their and response is shown in Figure 9. iCloud credentials. The client generates two separate The query.ess.apple.com response message con- key pairs: a 1280-bit RSA public key pair (pkE ,skE ) tains public keys, along with push tokens, for each of the for use in encrypting and decrypting messages and an devices registered to an account. Each of the key entries ECDSA keypair (vkS,skS) for authenticating messages. is a 332 character long base64 encoded binary payload. The client transmits the public portion of these keys When decoded, they take the form shown in Figure 10. P =(pkE ,vkE ) to the IDS, which registers it to the
670 25th USENIX Security Symposium USENIX Association Upon receiving the RSA public key in the above di- to receive future messages. agram, the Messages client uses this key to encrypt the Apple’s primary defense against registration of new outgoing iMessage payload. The ECDSA key is not used devices is a notification message that is sent to all when sending a message, but is used to verify the in- previously-registered devices. In order to register a new tegrity of a message when it is received from that user. device to a target account without alerting the victim, we iMessage clients appear to accept the most recent key also developed a method to overcome these notification delivered by ESS/IDS even if it disagrees with previous mechanisms. We observed two such mechanisms: entries cached by the device. Notably, the only security measures embedded in this 1. Upon registration of a new device, all devices conversation are authentication fields in the header of the logged into the account receive a push notification re uest the server does not sign the response. Thus the over the APNs network. In response, each de- authenticity of the response depends entirely on the secu- vice initiates the GetDependantRegistrations rity of the TLS connection. This seems like an oversight, call shown in Figure 8. given that many other fields in the Apple protocols are explicitly authenticated. Worse, in iOS 8 and versions of 2. When an iMessage account is registered to a device OS X 10.11 released prior to December 2015, the Mes- that has not previously been registered to that ac- sages client does not use certificate pinning to ensure that count, a notification email is generated and sent to the connection terminated at an Apple server. Thus an at- the account’s registered email. tacker with a stolen TLS root certificate can intercept key requests and substitute their own key as a response. This In the first instance, once the APNs push notifi- degrades the security of iMessage to that of TLS. cation signaling that a GetDependantRegistrations We implemented this attack by installing a self-signed call should be executed has arrived at a client, the client X.509 root certificate into the local root certificate store will continuously send the request until it receives a re- of a Mac device. This allowed us to verify that there were sponse. An active attacker on the victim’s network can no warning mechanisms that might alert a user to the key simply block all these requests, but this is not sustain- substitution. By further intercepting messages transmit- able over long periods of time. We discovered that the ted via the APNs network, we were able to respond to client is satisfied when it receives any response — even all key lookup requests with our own attacker key, and a poorly formatted unreadable one. Thus, an attacker subsequently decrypt any iMessages transmitted via the can edit the server response causing it to decode incor- device. rectly. The client will accept this response and terminate Our experiments demonstrate that iOS 9 is no longer the repeated GetDependantRegistrations calls. This subject to simple key substitution attacks, due to the ad- blocks notifications that would alert the victim to the fact dition of certificate pinning on TLS connections. This that a new device has been registered to their account. increases the relative impact of our novel decryption at- All subsequent iMessage traffic, both incoming and out- tacks. Surprisingly, our experiments demonstrated that going, will be forwarded to the attack device. Until a OS X 10.11.1 remained vulnerable as of November 2015. user logs out of their iMessage client, logs into a new We notified Apple of this oversight, and they have added iMessage client, or manually checks the list of devices key pinning as of OS X 10.11.13. associated with their account, they will never notice that their traffic is being forwarded to the attack device. A redent l t eft The first message in the registration process, shown A d tes n in Figure 7, passes the user’s credentials to the The ESS messaging protocol changed in a number of profile.ess.apple.com server to be verified. As ways with the 10.11 update to OS X. The exchange noted in previous sections, OS X 10.10.5 and iOS 8 de- of credentials for an authorization token has moved to vices do not employ certificate pinning on this server, and point to gsa.apple.com and that connection has cer- the credentials are sent in plaintext within the TLS con- tificate pinning implemented. Due to this fact, weare 16 nection. By conducting a TLS MITM attack on this unable to MITM this connection, but attempting to login connection, we are able to intercept iCloud login creden- to an account with bad credentials will result only in a tials. Using this information we can register new iMes- message to that server and an error message displayed sage devices to an account, ensuring that we will be able on the client. Additionally, there is a message sent to with a username and password pair 16OS X 10.11 devices do not employ certificate pinning on this con- setup.icloud.com nection either, but they do not appear to send the credentials in plain- in which the password is no longer transmitted in plain- text. text.
USENIX Association 25th USENIX Security Symposium 671 The key substitution attack still worked against OS X 10.11 versions as of November 2015, but the additional certificate pinning of apsd made it more difficult to in- tercept the message. In order to make sure the attack still functioned properly, we recovered the encrypted payload of the message from the apsd logs and were able to suc- cessfully decrypt the message using our own keys. Al- though we are not able to easily intercept the messages as we could with 10.10.5, this attack still effectively re- duces the security of iMessage to that of TLS. Figure 11: On the left is a certificate verification dialog presented on encountering an unknown wireless access ss ng point. On the right is a root CA installation dialog. To execute the attacks described in this paper, the at- tacker must obtain encrypted iMessages from the APNs TLS root certificate [6]. link. Since iMessage secures the APNs connection using TLS, this re uires the attacker to penetrate to the TLS en- cryption on the link between Apple and the end-device. We identified three approaches to bypassing TLSon the APNs connections: (1) Apple, or an attacker with access to Apple’s infrastructure, can intercept the con- tents of push messages as they transit the APNs servers (2) on certain iOS and OS X versions that do not include certificate pinning for APNs, an attacker with access to a stolen CA root certificate may be able to conduct an MITM attack on the TLS connection or (3) on the same versions, an attacker can “sideload” a root certificate on the target device, by briefly taking physical control of it, or convincing a victim to install a root certificate via a malicious email or web page. The latter techni ue is particularly concerning due to the similarity between Apple’s interface for installing root CAs and other non- critical certificate installation re uests that may be pre- sented to the user (see Figure 11). Since some Apple operating systems do not use certificate pinning, instal- lation of a root certificate allows arbitrary interception of both APNs and HTTPS connections. We identified attacks (2) and (3) as infeasible on all iOS 9 versions due to the inclusion of certificate pinning on APNs connections in that operating system. As of November 2015 when we first notified Apple of the re- sults in this paper, we discovered that the then-current version of OS X 10.11 did not include certificate pin- ning. In response to our disclosure, Apple added certifi- cate pinning to OS X as of December 2015. We stress that given the interest in iMessage expressed by nation-states [26], a compromise of CA infrastructure cannot be ruled out. Even without such attacks, there have been several recent examples of CA-signed root or intermediate certificates being issued for use within cor- porate middle-boxes, primarily for the purposes of enter- prise TLS interception [5]. TLS interception may occur even within Apple OS distributions: a recent incident in- volving iOS 9 allowed ad-blocking software to install a
672 25th USENIX Security Symposium USENIX Association