 I am Igor Spanos, and this is a pre-recorded presentation for the paper called Security Under Message-Drived Keys, Signed Cription in iMessage. It is a joint work done with Mihir Belare while at UCSD. In the wake of his learning about the existence of NSA's Prism program, the security of private messengers has been put in the spotlight. Nowadays, the instant messengers are very widely used, and a number of them claim to provide end-to-end encryption. The question you want to answer is, are these instant messengers really secure? And how secure they are? It is not so easy to tell. These applications include new cryptography, which deserves analysis by cryptographers, and of course the overall security involves a lot beyond cryptography. Prior work is given definitions, schemes, and analysis for a technique called ratcheting, which is widely used in instant messaging. This work is similarly motivated by iMessage. In 2019, it was estimated to have 1.3 billion active users, and it provides end-to-end encryption. Our analysis of iMessage is based on the protocol description that is available at Apple Ios Security webpage. However, some details are missing from this description. In order to fill in the missing details, we also refer to the prior reverse engineering efforts. Let us start from examining the old end-to-end encryption protocol that was used by iMessage in iOS version 9 prior to 2016. In order to send a message, the sender encrypted with AES-CTR using an ephemeral encryption key sampled uniformly at random. It didn't encrypt the symmetric key itself using the recipient's RSA public key. Finally, the sender signs the hash of the produced cybertext using its own signing key, and pucks the three values into a single cybertext. In 2016, Garmin, Green, Kaptichuk, Meyers and Ruschenan found a practical chosen cybertext attack against this scheme, which resulted in being able to recover encrypted messages. This vulnerability was acknowledged by Apple, and it was fixed starting from version 9.3 of Apple Ios. In order to prevent the attack, the current scheme no longer samples the AES key uniformly at random. Instead, it samples an 88-bit long HMAC key, and then computes a 40-bit HMAC tag by hashing the public keys of the sender and of the recipient, along with the message that needs to be encrypted. The AES key is then produced by concatenating the 88-bit long HMAC key with the 40-bit long HMAC output. The rest of the encryption algorithm remains the same as before. The main question you want to answer is whether the new scheme is secure, and specifically has the 2016 attack been thwarted. On the more theoretical side, we observed that iMessage encrypts a message under a key that is itself a function of this message. This is an interesting technique, providing encryption under a message-derived key. To answer the question about the security if iMessage we need to start by identifying the security goal targeted by the iMessage design. Our answer to that is the goal is Syncryption. Syncryption was introduced by Zeng in 1997, and its security was formalized by An, Dodis and Rabin in 2002. Syncryption combines encryption with signatures to build a single primitive that simultaneously provides both the privacy and the authenticity of the syncrypted messages. An, Dodis and Rabin define two types of syncryption security. An adversary attacking the insider security is assumed to have its own pair of syncryption keys that belong to the user network. An adversary attacking the outsider security does not possess its own key pair in the network. To summarize, syncryption can be thought of as the asymmetric analog of symmetric authenticated encryption. Interestingly, neither any Apple documents we found nor the 2016 attack paper explicitly identify syncryption as the goal. But identifying that as the goal provided us with some insights. First, its original iMessage implemented a variant of the encrypt-then-sign composition that was proposed by An, Dodis and Rabin back in 2002. Furthermore, the 2016 attack against iMessage is a clever practical rendition of the generic attack on the insider privacy that was also explained by An, Dodis and Rabin. So it is clear that the current iMessage scheme also aims to provide insider security. Not that we have identified syncryption as the goal, let me summarize our contributions. On the theoretical side, first we give syntax and security definitions for syncryption in the messaging setting. We also define a new symmetric primitive called encryption under message-drapped keys, abbreviated as EMDK. Next, we give general constructions of a syncryption scheme from EMDK, public key encryption, and signatures. Finally, we prove the insider security of our scheme. On the practical side, we can now instantiate our theoretical construction to recover the iMessage protocol. This lets us obtain the security proof for iMessage and derive a quantitative security balance for it. Going back to the theoretical side, we provide attacks that much declined lower bounds of the practical construction. We expand the standard syntax of a syncryption scheme to the multi-recipient setting, and we pass the user identities as explicit inputs to some of the algorithms of the syncryption scheme. This key generation algorithm produces a key pair that can be used with any user identity. The syncryption algorithm SIG-ENG takes a plaintext message, the identity and the key pair of the sender, and the set containing each recipient's identity and public key. It returns a set of cybertexts where each cybertext encrypts the plaintext message for a distinct recipient's identity. Then the unsyncryption algorithm VerDec takes the cybertext, the sender's identity and public key, and the recipient's identity and the key pair. It returns the decrypted plaintext message. It calls the standard security definitions for syncryption as defined by Ando, Desin, Robin. The privacy of syncryption is an INDCCA-style security definition, where the adversary is given access to the left-to-right syncryption oracle, and to the unsyncryption oracle. The adversary is required to guess the challenge bit used by the left-to-right oracle. The authenticity of syncryption is an UFCMA, or Cybertext Integrity-style definition, where the adversary is given access to the syncryption oracle and to the unsyncryption oracle. The adversary is required to forge a new cybertext. We provide separate definitions of privacy and authenticity, and we also unify them into a single security definition that simultaneously captures most of them. We provide all security definitions into a multi-user setting, where the adversary has full control over the network and is allowed to expose user's secret keys. Our definitions allow to capture both the insider and the outsider's security notions of syncryption by considering different classes of adversaries. Finally, we parameterize all of our security notions by relations that determine which queries to the unsyncryption oracle are considered valid. This results in a definitional framework where choosing different relations allows us to capture different security notions for syncryption in a fine-grained way. Next, we define a new primitive called encryption under message-drive keys. This new primitive captures a special type of symmetric encryption. We'll refer to it using its abbreviation, an EMDK scheme. The encryption algorithm of an EMDK scheme generates a secret key that can depend on the plaintext message that is being encrypted. The decryption algorithm of an EMDK scheme uses the standard syntax of symmetric encryption schemes. We modeled the core part of the IMSH protocol as an EMDK scheme. The encryption algorithm of the scheme generates the secret key as follows. Half of the key called R0 is chosen uniformly at random. The other half of the key called R1 is produced by hashing the first half together with the message. The two halves as in concatenated together and used to encrypt the plaintext message M with the counter-mode of the AES blockcyper. Our goal is to analyze the security of the scheme, so let us start by defining the two necessary security notions. First, we define the authenticated encryption security of an EMDK scheme. The security game provides the adversary with an access to the left-to-right oracle and to the decryption oracle. Each call to the left-to-right oracle generates a distinct secret key, and therefore each call to the decryption oracle has to indicate the index I of the secret key that needs to be used for decryption. The adversary has to guess the challenge bit that is used by the left-to-right oracle, and the adversary is not allowed to trivialize the game by calling its decryption oracle in a cybertext that was returned by the left-to-right oracle to gather with the index of the corresponding secret key. The second security notion we consider is the robustness of an EMDK scheme. The security game provides the adversary with an access to the encryption oracle that encrypts arbitrary messages. The goal of the adversary is to find the key that decrypts any of the obtained cybertexts into a message that is different from the plaintext message that was originally encrypted to produce this cybertext. At the beginning of this presentation, we already discussed the current design of the iMessage protocol. We will now revisit it, defining a encryption scheme that formally captures it in a very modular way. Our encryption scheme is based on the Digital C-Nature scheme DS and on a multi-recipient public key encryption scheme MRPK. The key generation algorithm of our encryption scheme separately runs the key generation algorithms of both underlying schemes and groups together the corresponding secret and public key outputs. The encryption algorithm of our scheme creates a payload M-star by encoding the plaintext message, the sender's identity, and the set of recipient identities with the corresponding public keys. It generates the MRPKE encryption algorithm to produce a distinct cybertext for each of the recipient identities, where all cybertexts encrypt the same payload M-star. Finally, each of these cybertexts is independently signed and the resulting signature is combined with the corresponding MRPKE cybertext. In our paper, we prove that this encryption scheme has authenticity if DS is enforceable and if MRPKE is robust. We also show that this encryption scheme has privacy if MRPKE is INDCCA secure. In the iMessage design, the Digital C-Nature scheme DS is instantiated with ECDSA and we will now define the construction of the multi-recipient public key encryption scheme MRPK. We define the MRPKE scheme roughly as a hybrid encryption scheme, combining an encryption scheme under the under message-derived keys EMDK and a public key encryption scheme PKE. To encrypt the plaintext message M-star, it first runs an encryption algorithm of EMDK to produce a symmetric cybertext with the corresponding secret key. It then uses PKE encryption to separately encrypt the secret key to each of the recipient public keys. It then combines each of the resulting public key cybertext with the single symmetric cybertext. We prove that this MRPKE scheme is robust if either of the two underlying schemes is robust. We prove that this MRPKE scheme is INDCCA secure if the PKE scheme provides INDCCA security and if the EMDK scheme provides authenticated encryption. In the iMessage design, the public key encryption scheme PKE is instantiated with RSA or AEP and we will now discuss the construction of the EMDK scheme. We can define the EMDK scheme in different ways in order to recover the design of either the legacy version of iMessage or the current version of iMessage. We are interested in the current version and we already discussed the construction of the current EMDK scheme on the previous slide. Formally, in the definition of this EMDK, we model HMAC SHA256 as a function family F and we model ASCTR as a symmetric encryption scheme SE. We prove the robustness and the authenticated encryption security of this EMDK scheme based on several assumptions about the function family and the symmetric encryption scheme. Some of these proofs are done in the random oracle model. I'll make the detailed discussion about these reductions here, but you can find them in our full paper. We obtained a sequence of security reductions, each of them proven in the concrete setting. In the paper, we instantiated this sequence of proofs with the specific real-world primitives used in iMessage. This allowed us to deduce a lower bound for the concrete security of iMessage. As a result, we claimed that the iMessage design provides at least 71 bits of security with respect to authenticity and at least 39 bits of security with respect to privacy. For simplicity, when calculating this bit security in lower bounds, we modeled function family F as the random oracle and we modeled symmetric encryption scheme SE as the ideal cyber. Finally, we showed that our derived concrete security bounds are tied by defining theoretical attacks against the encryption scheme. I will make the description of the attacks here, but you can find them in our full paper. Recall that from the start of the presentation, that the design of the iMessage scheme was changed in response to the 2016 attack by Garmin Green, Kaptichuk, Myers and Ruschenan. The initial EMDK scheme that was used prior to 2016 simply generated a uniformly random key independently of the plaintext message that had to be encrypted. It was then replaced in version 9.3 of IOS with a more sophisticated scheme where the key depends on the plaintext message. This might raise a question of why Apple did not replace the entire scheme with a more standard construction of secure sign encryption. The answer to this question is that it was necessary to preserve backwards compatibility and Apple confirmed it in a conversation with us. This means that any messages sent by the current iMessage version should be decryptable by the old iMessage version. This explains the non-standard design choices that are used in the current iMessage version. When analyzing the current scheme, we also attempted to find better ways to fix the legacy scheme while still preserving the backwards compatibility. In the end, we could not come up with a backwards compatible scheme that would provide security that is better than that of the current iMessage scheme. We confirmed with Apple that the definition of our sign encryption scheme captures the design of iMessage with one minor but important difference. Recall that our construction of the sign encryption scheme uses multi-recipient public encryption to encrypt the payload mStar. In our model, mStar contains the plaintext message, the identity of the sender and the set of recipient identities and public keys. As opposed to our model in the actual implementation, this payload also includes a uniformly random CDAR. This makes two of the three attacks we present in our paper less efficient than claimed. However, the third attack is not affected and as a result, our overall security, concrete security bounds still remain the same. Finally, note that the original attack from 2016 had constant time theoretical complexity, but its implementation required 2 to the power 18 queries and 235 hours. Furthermore, version 9.3 euphios besides changing the design of iMessage also added ad-hots implementation level mitigations to prevent further attacks. In this work, we focused on the theoretical analysis of the iMessage design. We showed that the lower bound for the concrete privacy of the current design is 2 to the power 39. This means that there do not exist more efficient attacks against the formal model that captures the iMessage design. We emphasized that we did not have access and hence did not attempt to analyze the actual implementation of iMessage. Furthermore, we do not know whether our theoretical results can be used to implement practical attacks against iMessage. This question was the outside of the scope of our project. But it is likely that any theoretical attacks like the ones presented by us would incur a substantial slowdown when implemented, possibly comparable or exceeding the slowdown that affected the original 2016 attack. Thank you for listening and you can find our full paper on ePrint at the provided link.