How Secure is TextSecure?

Tilman Frosch∗†, Christian Mainka†, Christoph Bader†, Florian Bergsma†,Jorg¨ Schwenk†, Thorsten Holz† ∗G DATA Advanced Analytics GmbH firstname.lastname @.de { } †Horst Gortz¨ Institute for IT-Security Ruhr University Bochum firstname.lastname @rub.de { }

Abstract— has gained popularity by users without providing any kind of . Today, many for both private and business communication as low-cost clients implement only -to- via TLS, short message replacement on mobile devices. However, until although security mechanisms like Off the Record (OTR) recently, most mobile did not protect confi- communication [3] or SCIMP [4] providing end-to-end con- dentiality or integrity of the . fidentiality and integrity are available. Press releases about mass performed by intelli- With the advent of , low-cost short-message gence services such as NSA and GCHQ motivated many people alternatives that use the data channel to communicate, to use alternative messaging solutions to preserve the security gained popularity. However, in the context of mobile ap- and of their communication on the . Initially plications, the assumption of classical instant messaging, fueled by ’s acquisition of the hugely popular mobile for instance, that both parties are online at the time the messaging app WHATSAPP, alternatives claiming to provide conversation takes place, is no longer necessarily valid. experienced a significant increase of new Instead, the mobile context requires solutions that allow for users. asynchronous communication, where a party may be offline A messaging app that claims to provide secure instant for a prolonged time. In this setting, existing solutions, such messaging and has attracted a lot of attention is TEXTSECURE. as OTR, are only applicable in a limited fashion. Besides numerous direct installations, its protocol is part of and TextSecure. In the light of the Android’s most popular aftermarket firmware CYANOGEN- recent revelations of actions performed MOD.TEXTSECURE’s successor continues to use the by intelligence services such as NSA and GCHQ, several underlying protocol for . In this paper, we secure text messaging (TM) solutions that claim not to be present the first complete description of TEXTSECURE’s com- prone to surveillance and to offer a certain level of security plex , provide a security analysis of have appeared on the market [5]. its three main components ( exchange, key derivation and One of the most popular apps for secure TM is TEXT- 1 ), and discuss the main security claims SECURE , an app developed by Open WhisperSystems that of TEXTSECURE. Furthermore, we formally prove that—if key claims to support end-to-end security of text messages. registration is assumed to be secure—TEXTSECURE’s push While previously focusing on encrypted short message ser- messaging can indeed achieve most of the claimed security vice (SMS) communication, Open WhisperSystems intro- goals. duced data channel-based push messaging in February 2014. Thus, the app offers both an iMessage- and WhatsApp-like communication mode, providing SMS+data channel or data 1. Introduction channel-only communications [6]. Following Facebook’s ac- quisition of WHATSAPP,TEXTSECURE gained in popular- Since more than a decade, Instant Messaging (IM) is ity among the group of privacy-conscious users and has cur- an alternative to classical e-mail communication, for both rently more than 500,000 installations via Play. Its private and business communication. IM has different fea- encrypted messaging protocol has also been integrated into tures; most importantly, messages are delivered in real-time, the OS-level SMS-provider of CyanogenMod [7], a popular but only if both parties are online. However, in contrast to open-source aftermarket Android firmware that has been security mechanisms available for e-mail such as PGP [1] installed on about 10 million Android devices [8]. According and S/MIME [2], instant messages were sent unprotected: to media reports [9], TextSecure’s protocol has additionally In the early days, many popular IM solutions like MSN been implemented in WhatsApp’s Android client. While we MESSENGER and YAHOO MESSENGER did not provide any did not verify this claim, in consequence the protocol’s secu- security mechanisms at all. AOL only added a protection mechanism similar to S/MIME to their IM service later 1. The name of the App has been changed to SIGNAL in November 2015 on and ’s SECUREIM messenger encrypted the data to be consistant with the iOS App. rity would affect several hundred million users. Despite this OTR’s focus differed significantly from previous message popularity, the messaging protocol behind TEXTSECURE prKGotection mechanisms like OpenPGP and S/MIME by has not been rigorously reviewed so far. While the develop- introducing two novel properties: Perfect ers behind TEXTSECURE have a long history of research and Deniability. in , a security assessment is needed to Figure 1 shows how the OTR protocol version 1 works: carefully review the approach. After an initial signed Diffie-Hellman (DH) , Contribution. In summary, we make the following contri- novel DH shares are exchanged with every message, and the butions: resulting DH key is constantly changed. OTR uses malleable We are the first to completely and precisely docu- encryption [12] in combination with MACs (instead of digi- • ment and analyze TEXTSECURE’s secure push mes- tal signatures). The OTR protocol reveals the MAC keys one saging protocol. Our description was confirmed by round later to the public. This is essential for the deniability the developers of TEXTSECURE. property of the protocol: anyone can change the value of the We show that the main protocol of TEXTSECURE plaintext message, as inverting bits of the will • consists of three building blocks: A cached One- result in an inversion of the same bits at the same positions Round Key Exchange (cORKE) protocol, a secure in the plaintext. Thus, the received messages are authentic , and authenticated encryp- at the time of reception only (given a party verifies the first tion. We give formal security definitions and security signature and the following MACs). Since the MAC keys proofs for these blocks. are derived as hash values of the encryption keys, revealing We found subtle, but avoidable flaws in the protocol MAC keys does not compromise the security of the former, • that allows for an Unknown Key-Share attack. We and the exchanged messages remain confidential. Private have documented the issues and show how they DH shares xi and yj are deleted as soon as the key kij can be mitigated. They have been communicated to has been computed. This guarantees perfect forward secrecy the developers of TEXTSECURE. We show that our since without these private shares the encryption keys cannot proposed method of mitigation actually solves the be recomputed from the public shares Xi,Yj later. issues. Di Raimondo et al. [13] showed that OTR v1 is vul- We discuss how and to which extent deniability, • nerable to an unknown key-share (UKS) attack (also called perfect forward secrecy (PFS) and future security identity misbinding attack) [14]. We will discuss this kind (FS) are realized. While TEXTSECURE meets PFS of attack in Section 4.2. OTR version 2 did address this and FS, deniability is only achieved partially in issue by introducing a four message handshake that follows practice. the SIGMA protocol paradigm [15], effectively mitigating the UKS attack. Moreover, the protocol achieves deniability: 2. High-level Overview of TextSecure and re- public keys and signatures are exchanged within a con- lated protocols fidential channel, leaving no trace of participation for an eavesdropper. However, these strong capabilities come at the TEXTSECURE was previously compared [10] to the Off- cost of a four-message handshake. the-Record Protocol (OTR) and the Instant Messaging Protocol (SCIMP) [11]. In the following, we OTR and Mobile Messaging. Instant Messaging connec- discuss common elements and differences. tions are typically short-lived and online, whereas text mes- saging conversation may last for prolonged spans of time,

a P Pb and parties may be offline temporarily. Additionally, text choose x0 messaging may be asynchronous, such that a sender sends x0 X0 := g (1) X0, σA σA := sign(skA,X0) choose y0 several messages before receiving an answer. y0 Y0 := g (2) Y0, σB choose x1 σB := sign(skB,Y0) The first adaption needed to derive a secure text mes- x1 X1 := g e x0 saging protocol from OTR is to make OTR work in offline k00 := H ((Y0) ) e k00 := H(k00) e scenarios. The basic idea here is due to ElGamal [16]. Thus c00 := Enc(k00, m00) m (3) X1, c00, mac00 mac00 := MAC(k00, (X1, c00)) choose y1 OTR can be adapted to an offline scenario by storing many y1 Y1 := g e y0 ephemeral DH shares of each party on a server. k10 := H ((X1) ) m e k10 := H(k10) e c10 := Enc(k10, m10) The second adaption concerns key bookkeeping: In (4) Y1, c10, mac10 mac := MAC(km , (Y , )) choose x2 10 10 1 10 OTR, an ephemeral DH share must be protected by a MAC x2 X2 := g e x1 k11 := H ((Y1) ) computed with a previous key, and must be acknowledged m e k11 := H(k11) c := Enc(ke , m ) by the recipient B before being used by the sender A. 11 11 11 m m (5) X2, c11, mac11, k00 mac11 := MAC(k11, (X2, c11)) . .. This secure chaining of keys through MACs needs a lot of bookkeeping, as well as the acknowledgment. Here, Figure 1: The Off-the-Record protocol. TEXTSECURE adapts to the scenario by replacing MAC chaining by a secret value derived from long-lived (ga, gb) Off-the-Record Protocol. OTR was proposed by Borisov et and ephemeral (gxa , gxb ) DH shares, which is fed into any al. [3] as a method to secure conventional instant messaging. key generation step. Silent Circle Instant Messaging protocol (SCIMP). In AES [19] in both, counter mode without padding and SCIMP [11] the idea of using different generations of sym- block chaining mode with PKCS7 [20] padding. HMAC- metric keys is essential: After sending a message, the sender SHA256 [21], [22] is used for message integrity. Security updates his own key by replacing it with its own hash value: considerations of the cryptographic primitives are not within knew := hash(kold). In doing so, perfect forward secrecy the scope of this paper. between two DH key exchanges can be achieved: Even if For push messaging via data channel, TEXTSECURE the sender is forced to reveal all his keys, an adversary can relies on a central server4 ( ) to relay messages to the no longer decrypt the message sent, since this key has been intended recipient. Parties communicateTS with via a deleted. REST-API using HTTPS. ’s certificate is self-signed;TS the TS TextSecure. Informally speaking, TEXTSECURE builds on certificate of the signing CA is hard-coded in the TEXT- a (cached) one-round key exchange (ORKE) protocol [17] SECURE app. Actual message delivery is performed via executed between parties A and B to compute the long- . lived secret, a key derivation function (KDF) which takes From TEXTSECURE’s description in Google’s Play store, the authors’ blog and we can identify some as input the long-lived secret and a fresh DH secret, and an 56 authenticated encryption scheme. security goals of TEXTSECURE . These are end-to-end For the first message, a cached ephemeral key of the security, deniability, forward secrecy, and future secrecy. We receiver (called prekey)2 is fetched from the TEXTSECURE formalize and prove the first of these goals in Section 5, and server, together with its long-lived public key. Later, new discuss the remaining goals in Section 6. ephemeral public DH shares are included in each (first) TEXTSECURE’s protocol consists of several phases as response to a message. The process of changing ephemeral shown in Figure 3. We distinguish (1) registration, (2) key comparison sending/receiving a first message DH shares is called ratcheting in OTR and TEXTSECURE , (3) , (4) terminology. If a party sends several messages before receiv- sending a follow-up message, and (5) sending a reply. ing an answer, it updates the symmetric key used for each We provide a complete overview of the protocol in the message in a one-way fashion by applying a key derivation Appendix. function on an intermediate value (called chaining key), from a b which all cryptographic keys are computed. The structure of P TS P long-lived public key the TEXTSECURE communication is depicted in Figure 2. (i) registration A complete representation of the protocol can be found one-time DH shares 3 long-lived public key online . one-time DH shares (ii) cached ORKE long-lived public key

a b ephemeral DH share P TS P Get Prekey key derivation with (iii) ephemeral DH share, ciphertext + MAC Ratchet DH, Encryption + MAC Message A.1.1 key derivation, (iv) ciphertext + MAC Ratchet Encryption + MAC Message B.1.1 key derivation with Ratchet (v) ephemeral DH share, ciphertext + MAC Message A.2.1 DH, Encryption + MAC Message A.2.2 Ratchet Message A.2.3 Figure 3: High-Level view on the different phases in TEXT- SECURE. Message B.2.1 Ratchet

Figure 2: High-Level view on the Axolotl-ratchet protocol Notation in TEXTSECURE. In the protocol description, we use the following nota- tion: Each protocol participant is associated with a set of Pa parameters, which all share the same index: e.g. phone#a 3. TextSecure Protocol is the phone number associated with a. We denote the private, long-lived key of this party withP a, and its public We analyzed the of the Android app to counterpart with ga. Prekeys (recall that prekeys actually are recover the individual building blocks of the protocol. ephemerals keys stored on the server) belonging to a are TEXTSECURE builds upon a set of cryptographic primi- named gxa,z with z 0, 99 , their private counterpartsP are ∈ { } tives. For ECDH operations, [18] is used as it xa,z. The t-th ephemeral public Diffie-Hellman (DH) share is implemented in Google’s Android native cryptographic chosen by is denoted as gx¯a,t , with its private counterpart Pa library. Symmetric encryption in TEXTSECURE relies on x¯a,t. (Please note the overline symbol.)

2. We refer to prekeys as cached ephemeral keys to distinguish them 4. -service.whispersystems.org from ephemeral keys which are chosen at the time of protocol execution, 5. ://play.google.com/store/apps/details?id=org.thoughtcrime. whereas prekeys are chosen in advance and then stored on the server. securesms 3. http://bit.ly/1IPIJ3Y 6. https://github.com/trevp/axolotl/wiki Phase 1: TEXTSECURE Registration Phase 2: Key Comparison

The registration process is depicted in detail in Figure 4. In an attempt to establish that a given public key in- To register with the TEXTSECURE server , a party deed belongs to a certain party, TEXTSECURE offers the requests a verification token by transmittingTS its phone possibility to display the fingerprint of a user’s long-term Pa public key. Two parties can then compare fingerprints using number (phone#a) and its preferred form of transport to (Step 1), which confirms with a HTTP status 204 an out-of-band channel, for example, a phone call or an in- TS TS person meeting. If two parties meet in person, TEXTSECURE (Step 2). Depending on the transport a chose, then dispatches either a short message or a voiceP call containingTS also offers to conveniently render the fingerprint of one’s a random token (Step 3) to the number transmitted in Step own long-term public key as a QR code, using a third- 1. performs the actual registration in Step 4, where party application on Android, which the other party can Pa then scan using the same application on its . it shows ownership of phone#a by including the token, registers its credentials with the server via HTTP basic TEXTSECURE then compares the fingerprint it just received to the party’s fingerprint it received as part of a conversation. authentication [23], and sets its signaling keys kmac, ,A 7 TS and kenc, ,A . In this step, the client also states whether it wishes toTS communicate only via data channel push message Phase 3.1: Sending an Initial Message or also accepts short messages. The server accepts if the token corresponds to the one supplied in Step 3 and the Before a first message can be sent from a to b, phone number has not been registered yet. three main steps have to be completed (see leftP sideP of Figure 5): (a) a (cached) ORKE-type key exchange protocol

a GCM P TS (cf. Section 5.1) to establish a shared, long-lived symmetric (1) phone#a g Curve25519 secret rkBA (also called root key), (b) a key derivation and ∈ a (2) 204 OK (a, g ) R Zp Curve25519 ∈ × pw SHA1PRNG[128] (3) token R 100000,..., 999999 update protocol (the so-called Axolotl-ratchet [24]), which ∈R ∈ { } authenticationa = phone#, pw updates the root key, and generates a chaining key from regIDa R SHA1PRNG[128] (4) token, kenc, ,A, kmac, ,A, regIDa, ∈  TS TS kenc, ,A R SHA1PRNG[128] supportSms (bool), authenticationa TS ∈ which the encryption and MAC keys are derived, and (c) an kmac, ,A R SHA1PRNG[128] (5) 204 OK GenerateTS 100∈ prekeys authenticated encryption scheme. The process is depicted in + last resort key (klr) a x¯a,0 x¯a,99 x¯a,100 xa,i (6) g , g , . . . , g , g = klr, authenticationa detail in Figure 5. (xa,i, g ) R Zp Curve25519 ∈ × (7) 204 OK (a) Establishment of . In the first step, re- Pa (8) Registration GCM quests a prekey for b and receives a JSON structure consist- gcm (9) regIDa P xb,z ing of prekey-ID z, a prekey g , and b’s long-term key

gcm b P (10) regIDa , authenticationa g . also receives regID from and then chooses a new Pa b TS (11) 204 OK ephemeral key x¯a,0 to calculate an intermediate secret secint as the concatenation of three DH operations, combining ’s Pb prekey, a’s long-term key, b’s long-term key, and a’s Figure 4: TEXTSECURE registration. P P xb,z a b x¯Pa,0 freshly chosen ephemeral key, secint = g · , g · , x x¯ g b,z · a,0 ). From this value, the first root key is derived via In Step 6, supplies its 100 prekeys (or one-time keys) the HKDF key derivation function. Pa and klr to . Prekeys are not transmitted individually, but (b) (Axolotl-ratchet). After has com- TS Pa within a JSON structure consisting of a keyID z, a prekey puted the shared secret, a fresh secret kshared is derived xa,i a g , and the long-term key g . The last resort key klr from the received prekey and a freshly generated private xb,z x¯a,2 8 (the meaning of which will be clear at the end of this Diffie-Hellman share x¯a,2: kshared := (g ) . From section) is transmitted in the same way and identified by kshared and rkBA, a new root key rkAB and a chaining keyID 0xFFFFFF. The server accepts, if the message is key ckAB are derived, again via HKDF. well-formed and HTTP basic authentication is successful. The chaining key ckAB is finally used to derive (again a then registers with Google Cloud Messaging (GCM) in via HKDF) the encryption and MAC keys (KEnc,KMAC ) P gcm Step 8 and receives its regIDa (Step 9), which it transmits to encrypt and protect the integrity of the first message. to in Step 10 after authenticating again. (c) Authenticated Encryption. A message m M is TSTaking a look ahead, a prekey for is needed whenever ∈ Pa encrypted using AES in counter mode without padding. a new session is to start in which a plays the role of That is, c = ENC (m). then forms message (3.) P kEnc a the responder. Thus, the number of prekeys on the server and thus calculates tag = PMAC (χ), where χ = kMAC decreases. If there are only a few prekeys left on the server, (v, gx¯a,2 , ctr , pctr , c). v represents the protocol version and may store new prekeys on the server. In the case that no a a Pa is set to 0x02. For ordering messages within a conversation more prekeys are available, the last resort key is used. This ctr and pctr are used. Both are initially set to 0. ctr is key, however, will not be erased from the server. incremented with every message a party sends, while pctr is

x¯ 7. These keys are later used by to encrypt messages that are 8. Please note that the DH share (¯xa,1, g a,1 ) is only generated because TS transmitted via GCM so that GCM cannot see any metadata, e.g. regIDa of code reuse, but never used. set to the value ctr carried in the message a party is replying Phase 3.2: Receiving a message to. Message (3.) is sent to . TS The receiving process is depicted in Figure 6. b re- P signal ceives the message in Step (5.). First, b verifies mac and, if successful, decrypts csignal. It looksP up its long-lived Forwarding the message to GCM. Upon receiving mes- private key and the one-time private key that corresponds sage (3.), checks if regIDb corresponds to phone#b. It to prekey-ID z and calculates sec and the first root key TS int then encrypts the parts of message (3.) intended for b with rk . From now on, all computations are identical to those P BA b’s signaling key (kenc, ,B), using AES in CBC mode done by the sender, until the message keys (k , k ) P TS Enc MAC with PKCS5 padding. additionally calculates a MAC are derived. b now verifies the MAC and, if successful, TS signal over the result, which we denote as mac . sends both, decrypts the message.P encrypted message data csignal and macsignalTS, to the GCM gcm server, together with regIDb as the recipient. The result Phase 4: Sending a Follow-up Message of this additional encryption layer is that Google’s Cloud Messaging servers will only be able to see the recipient but If a wants to send a message before b not the sender of the message. replies, P first derives a new chaining keyP Pa

a GCM P TS

(1) get prekey: phone#b, authenticationa

xb,z b Choose prekey with (2) g , z, g , regIDb x¯a,0 prekey ID z (¯xa,0, g ) R Zp Curve25519 xa,z xb,z∈ a b xׯa,0 xb,z x¯a,0 a) delete g secint = g · , g · , g · (rkBA, ckBA) = HKDF (secint, const0, constR) x¯a,1  (¯xa,1, g ) R Zp Curve25519 x¯a,2 ∈ × (¯xa,2, g ) R Zp Curve25519 xb,z∈ x¯a,2 × kshared = g · b) (rkAB, ckAB) = HKDF (kshared, rkBA, constR)

(kEnc, kMAC) = HKDF (MACckAB (const1) , const0, constK )

ckAB = MACckAB (const2) m M c =∈ENC (m) kEnc ctra = 0 c) pctra = 0 x¯a,2 χ = (v, g , ctra, pctra, c) (3) χ, tag, z, gx¯a,0 , ga, regID , regID , a b check: regIDb belongs to phone#b tag = MAC (χ)∗ kMAC phone#b, authenticationa signal x¯a,0 a c = ENCkenc, ,B (χ, tag, z, g , g , phone#a) signal TS signal mac = MACkmac, ,B c TS Legend: signal signal gcm  (4) c , mac , regIDb 32 const0 = 0x00 const1 = 0x01 const2 = 0x02 constR = ”WhisperRatchet” constK = ”WhisperMessageKeys” v = 2

Figure 5: Sending an initial TEXTSECURE message.

GCM Pb

signal signal signal0 signal (5) c , mac mac = MACkmac, ,B c TS if macsignal0 = macsignal then: signal  DECkenc, ,B c TS get prekey: xb,z a xb,z x¯a,0b x¯a,0 xb,z secint = g · , g · , g · (rkBA, ckBA) = HKDF (secint, const0, constR) x¯a,2 xb,z  kshared = g · Legend: (rkAB, ckAB) = HKDF (kshared, rkBA, constR) (k , k ) = HKDF (MACck (const1) , const0, constK ) Enc MAC AB const = 0x0032 tag00 = MACk (χ) 0 MAC ∗ const = 0x01 if tag00 = tag then: 1 m = DEC (c) const2 = 0x02 kEnc constR = ”WhisperRatchet” ckAB = MACckAB (const2) constK = ”WhisperMessageKeys”

Figure 6: Receiving an initial TEXTSECURE message. old , and derives a new ckAB := MACckAB (const2) 4.2. Unknown Key-Share Attack pair (k , k ) = HKDF (MACck (const1) , Enc MAC AB An Unknown Key-Share Attack (UKS) is an attack vector const0, constK ). first described by Diffie et al. [14]. Informally speaking, if such an attack is mounted against a, then a believes to Phase 5: Sending a Reply share a key with , whereas in factP sharesP a key with Pb Pa e = b. P 6ForP a better understanding how this can be related If b wants to reply to a message within an existing P to TEXTSECURE, suppose the following example (jealous session with a, it first chooses a new ephemeral keypair x¯b,0 P spouse attack): Bart ( ) wants to trick his friend Milhouse (¯xb,0, g ) and calculates a new kshared as the output of b ( ). Bart knows thatP Milhouse will invite him to his birth- a DH operation that takes a’s latest ephemeral public Pa key gx¯a,2 and its own freshlyP chosen ephemeral private day party using TEXTSECURE (e.g., because Lisa already x¯a,2 x¯b,0 told him). He starts the UKS attack by replacing his own key x¯b,0 as input: kshared = g · . b then updates the root key and derives a new chainingP key by seeding public key with Nelsons ( e) public key and lets Milhouse verify the fingerprint of hisP new public key. This can be HKDF with the new kshared and rkAB: (rkBA, ckBA) = justified, for instance, by claiming to have a new device and HKDF (kshared, rkAB, constR). From the chaining key, a new encryption and MAC key pair is derived, the message having simply re-registered, as that requires less effort than is protected with these keys, and the encrypted message is restoring an encrypted backup of the existing key material. x¯b,= Now, as explained in more detail below, if Milhouse invites sent together with g back to a. P Bart to his birthday party, then Bart may just forward this message to Nelson who will believe that this message was 4. Issues with TextSecure actually sent from Milhouse. Thus, Milhouse ( ) believes Pa that he invited Bart ( b) to his birthday party, where in fact, he invited Nelson ( P). During our analysis, we found several issues that we Pe discuss in the following. In detail, the attacker (Bart, b) has to perform the steps shown in Figure 7 for this attackP (only the important protocol parameters and steps are mentioned): 4.1. Password-based Key Registration x x (1-2) requests g e,z0 , . . . , g e,zi from using Pb TS phone#e. xe,z xe,z In TEXTSECURE, the password pw is both required to (3-4) b commits g 0 , . . . , g i to as his own register prekeys with the server and to send messages on prekeysP plus ge as its own long-termTS public key. behalf of a party. The password is stored in the application- (5) b lets a verify the fingerprint of its new public specific storage on an Android device. When we first keyP ge. NoteP that this step uses QR-codes, therefore analyzed TEXTSECURE, the easiest way to recover the it is offline. password of another party was to trigger TEXTSECURE’s (6-7) Once wants to send the message to , Pa Pb Pa encrypted export function, which exported an encrypted requests a prekey for b by using phone#b. re- x x representation of the user’s messages and an XML file turns g b,zj = g e,zj andP the long-term key gbTS= ge. x containing the unencrypted pw. The export function placed (8-9) computes the sec using g b,zj and gb from Pa int the data on the device’s SD card, thus easily accessible. which k , k are going to be derived. This is a very limited level of protection for a token that is Enc,AB MAC,AB For computing those keys, he uses in fact e’s rather attractive for an attacker. Having access to pw does prekey and identity key although he believesP to not only facilitate one way of conducting the Unknown Key use ’s ones. He then encrypts message m , Share attack we describe below, but allows for much more b M computesP the respective MAC tag, and sends∈ it to severe scenarios, where an attacker can register arbitrary (GCM is omitted for simplicity). key material on behalf of a party, as well as, send arbitrary b (10-11) P is neither able to verify the tag nor to decrypt messages. The encrypted export function has been silently b theP message c. He sends the ciphertext and message removed in more recent versions of TEXTSECURE. tag to e. In more recent versions of the TEXTSECURE proto- P (12) e processes the incoming message as usual. He col, digital signatures have been added for the ephemeral P xb,z computes the same secint as a, because g j = public shares. In particular, a conversion of the long-lived xe,z b e P g j and g = g . The secint is then used to com- key (a, ga) Curve25519 is used to sign prekeys Zp pute k = k , k = k so before sending∈ them× to the TEXTSECURE server . The Enc,AE Enc,AB MAC,AE MAC,AB TS that is able to read and verify the message. signature scheme used here is Ed25519, a variant of the Pe  Schnorr-Signature scheme which is known to be a non- In Step 10, has to forward the message to , such Pb Pe interactive proof of knowledge of the secret key a. However, that it appears to be sent by a. Therefore, he needs to prekeys are still not bound to an identity, as it is the case include authentication for Pand phone# in Step 11, so a TS a with PGP keys. Also, as the proof is non-interactive, it can that e will receive phone#a with the forwarded message. be forwarded. ThisP can be achieved in several ways: a b e P P TS P (1) get prekey: phone#e, authenticationb (repeat it i times) xe,z xe,z e (2) g 0 , z0, . . . , g i , zi, g

e x¯e,z x¯e,z (3) g , g 0 , . . . , g i , authenticationb

xb,zj a , b x¯a,0 xb,zj x¯a,0 (4) 204 OK secint = g · g · , g · (5) Verify new public key fingerprint . .  (6) get prekey: phone# , authenticationa k , k = b Enc,AB MAC,AB xb,z xe,z b e ··· (7) g j = g j , zj , g = g c = ENC (m )  kEnc M tag = MAC (∈c, . . .) kMAC . (8) . . . , c, tag, zj , phone#b, authenticationa . (9) . . . , c, tag, zj , phone#a

(10) . . . , c, tag, zj , phone#e, authenticationa

(11) . . . , c, tag, zj , phone#a (12)

Figure 7: UKS attack on TEXTSECURE: believes to share a key with but shares one with . Pa Pb Pe

is corrupted. In this case, it is a trivial task to of as its peer, i.e., that the message is indeed intended • TS Pe get or circumvent authenticationa. for e. Moreover, e is convinced that a actually sent If is benign, an attacker might be able to eaves- the message.P Thus, P will not be able toP mount the above • TS Pb drop authenticationa. Although TLS is used for all attacks. connections between clients and server, future or existing issues with TLS implementations [25]–[29] 4.4. Mitigation of Authentication Issue can not be ruled out and would allow for a com- While the Unknown Key-Share Attack is mitigated if promise of authenticationa. Another way to obtain the message in Step 8 is modified as we propose in Sec- authenticationa could be a governmental agency (legally) enforcing access to the TLS keys. tion 4.3, the underlying problem is not resolved. It results In contrast to a party’s other key material, the pass- from a party’s erroneous assumption that a communication • word is stored unencrypted and is not protected by partner’s long-term identity key is authentic, if they have TEXTSECURE’s master password. Thus, the easiest compared key fingerprints, and these fingerprints matched possibility to realize this attack might be for an their assumptions. However, this is not necessarily the case. Given the attack scenario described in Section 4.2, a mali- attacker to recover the password for authenticationa from TEXTSECURE’s preferences9. cious party would always be able to present a third party’s long-term public key as their own, as only fingerprints are Remark 1. The signing of prekeys, as it is implemented compared – a party is not required to show their knowledge in current versions of TEXTSECURE, does not prevent the of the corresponding secret key. attack. As the keys are still not cryptographically bound to To resolve this issue and to enforce that only a party the parties’ identities, an attacker can still download keys in possession of the valid long-term identity key for this of an arbitrary party and pass them off as their own. Thus respective party may register new key shares with the server, the UKS attack described in this section was not mitigated. we propose to use an interactive zero-knowledge proof of knowledge. Instead of presenting pw before uploading new 4.3. Mitigation of Unknown Key-Share Attack prekeys, a party could present a proof that it knows the private key that corresponds to the identity key already Let us consider the message that is sent in Step 8 of Figure 7: registered with the server and used for signing previous prekeys. Thus, the authentication required for registering x¯a,0 a χ, tag, g , g , regIDa, regIDe, keys would now depend on a strongly protected secret: a phone#e, authenticationa, party’s identity key. The Schnorr identification protocol [30] works ideally where χ = (v, gx¯a,2 , ctr , pctr , c) and tag = MAC (χ). a a kMAC a Intuitively, if both ’s and ’s identity were protected in this case. Let (ska, pka) = (a, g ) Zp Ed25519 be a e the key pair of Party . Then the Schnorr∈ protocol× can be by the tag, then theP attacks aboveP do not longer work. As Pa identities we propose to use the respective parties’ phone used to prove possession of a to Pb (the verifier) as follows: $ r 1) Pa chooses r Zp and sends G = g (the commit- numbers, as they represent a unique identifier within the ← system. χ would thus be formed as ment) to Pb. $ 2) Pb samples e Zp and sends e (the challenge) to Pa. x¯a,2 ctr pctr ← (v, g , a, a, phone#a, phone#e, c). 3) Pa computes s = a e + r mod p and sends s (the · s e response) to Pb. Pb accepts if g = pka G. If kMAC is secret (i.e., only shared among a and e) and · if MAC is secure, the inclusion of both identitiesP P in the The protocol could easily be carried out between a TEXTSECURE client and the server to proof possession tag provides a proof of a towards e that a is aware P P P of the corresponding secret key, eachTS time a party attempts 9. File: shared-prefs/org.thoughtcrime.securesms preferences.xml to upload keys. It is well known that the Schnorr protocol is an honest share gxa and his long-lived public share ga together with verifier zero knowledge proof of knowledge [31]. That is, it the encrypted message and additional data to B. A and B holds that: then both derive an intermediate secret secint by computing 1) Computing a proof requires knowledge of the secret 3 of the 4 possible combinations of their public shares: a xb b xa xa xb key, and secint := (DH(g , g ),DH(g , g ),DH(g , g )). 2) An honest verifier, i.e., a verifier that follows the pro- The long-lived secret rkBA shared between A and B tocol honestly, learns nothing about a. is then derived by applying the key derivation function In the sequel we assume public keys to be authentic. HKDF to this intermediate secret and two constant values: (rkBA, ckBA) = HKDF (secint, const0, constR). Remark 2. If we do not want to trust the server , the TS Security models for ORKE protocols mostly follow Schnorr protocol can also be carried out when to parties Canetti and Krawczyk [34], and the many different variants meet face to face via exchange of QR-codes. of these models are often summarized under the term “ex- This would mitigate the UKS attack, because in addition tended Canetti-Krawczyk” (eCK) model. All these models to being authenticated with his real identity at the TEXT- differ slightly in the definition of a “protocol session”, and SECURE server, the attacker would have to prove knowledge in the adversarial capabilities. of the private long-lived key of the victim, which he does Computational model. We model each instance of TEXT- not know. SECURE installed on a mobile device as a party Pi, i 1, ..., n . Each party keeps track of the long-lived and∈ { } 5. Security Proofs -lived variables (i.e., for party PA the long-lived private key a, the corresponding public key ga, the identity In the following, we provide security proofs for the A, and all the registered one-time key pairs). building blocks of TEXTSECURE. Namely, we give a se- For each communication started with another party, Pi curity proof for the cached ORKE protocol and prove the forks off a (medium-lived) process πs, s 1, ..., ` , to i ∈ { } key derivation function and authenticated encryption to be maintain the different session key variables. For cORKE (cf. s secure. Figure 8) and πA, these variables include the identity B of We note that we do only prove security of the building the communication partner PB as requested in message (2), b x blocks of TEXTSECURE here, not of their composition. We the long-lived key g and the one-time key g b as received in see this as a first step to provide a thorough security analysis message (3), the ephemeral secret key xa, the value secint, of TEXTSECURE and encourage further research in this and the pair (rkBA, ckBA). direction. This approach was succesful, for example when Each child process may request a registered private key proving the security of TLS where Jager et al. [32] built on from the party by presenting a reference to the correspond- provable security results of the building blocks (e.g., [33]). ing public key. Remark: This computational model seems over- 5.1. The computation of the long-lived symmetric idealized, since the different sessions are most likely im- secret is a secure ORKE protocol plemented as threads, not as separate processes. However, in order to allow Reveal queries targeting only session- One of the main design criteria as described by Marlin- specific variables, some kind of memory separation should spike in his blog entry on “Axolotl-ratchet” [10] is the re- be in place, to avoid fatal effects like reading the com- placement of the three-message ratchet (“key refreshment”) plete OpenSSL memory with a attack. So this used by OTR by a two-message ratchet. This, however, computational model should be seen as without memory disables the MAC-based “chain of trust” for successive separation, the proof may not hold. Or to put it the other way round: Without memory separation, we must remove ephemeral DH shares. As a solution, TEXTSECURE first Reveal queries from the adversarial model to be able to establishes a shared, long-lived, symmetric secret rkBA between sender A and receiver B. This secret is then used, prove security. together with a fresh DH secret, in the TEXTSECURE key The TEXTSECURE server is modelled as an additional derivation function. party, since this server does not compute any session-specific In this section we describe the establishment of this values. secret as a cached one-round key establishment protocol Adversarial model. Adversarial capabilities are formalized (cORKE, cf. Figure 8), where the first message has been as queries, where the fact that an active adversary controls cached on the TEXTSECURE server. In the TEXTSECURE the whole communication network is modeled as a Send cORKE protocol, each party B generates one long-lived key query, together with various variants of queries which reveal b xb pair (b, g ) and several one-time DH key pairs (xb, g ). secret data from all but the Test session. The multiplicity of The public shares of these key pairs are then registered. different secret values established during the TEXTSECURE Before party A can send the first message to B, he has to protocol (cf. Section 6.2) makes it difficult to correctly request the long-lived and one one-time public DH share define queries revealing any long-, medium- or short-lived from the TEXTSECURE server. Party A then chooses a values to the adversary. However, this is not the goal of this xa fresh ephemeral DH key pair (xa, g ), and sends the public section: we only want to prove security of the cORKE build- a b P TS P (a, ga) b, gb

(1) register B, gb, gxb choose xb compute gxb 

(2) request(B)

(3) B, gb, gxb choose xa compute = gxa xb a b xa xb xa secint := ((g ) , (g ) , (g ) ) (4) A, ga, gxa , z a xb xa b xa xb (rkBA, ckBA) = HKDF (secint, const0, constR) secint := ((g ) , (g ) , (g ) ) (rkBA, ckBA) = HKDF (secint, const0, constR)

Figure 8: The cached ORKE protocol in TEXTSECURE to compute a shared secret secret between parties A and B. Please note that z is a pointer to gxb . ing block. Therefore we formalize adversarial capabilities as Cremers [35] and Bergsma et al. [36] independently came the following queries: up with a satisfactory definition, which we use. Send(πs, m). With this query, the adversary can • i Definition 1 (Origin session). Consider two parties A and send message m to process oracle πs. TheA oracle s t in out i B with processes πA and πB, and let M (π) and M (π) will process this input according to the protocol be the sequences of messages received and sent by process specifications, and return any output it produces s t in s π, resp. We say πA has origin session πB, if M (πA) = to . The Send query may also be used to send out t s t M (πB), and denote this by πA πB. messagesA to the TEXTSECURE server. This query ← models that an active attacker may control the com- In Figure 8 we assume that the one-time key retrieved plete communication between different process ora- by Pa in message (2) is unique, and that the TEXTSECURE cles and the TEXTSECURE server, and may delete, server does not issue the same key twice. (We do not modify, delay or inject arbitrary messages. consider the last ressort key here.) The adversary may A Reveal(πs). This query will reveal the values forward message (4) to different process oracles at party • i (rkBA, ckBA) if they have already been computed Pb, which consequently would all compute the same key. by the process oracle. If this computation is not We consider this (trivial) attack by restricting the security finished yet, the query will return . game with the help of the concept of origin sessions. Corrupt(P ). This query will return⊥ the long-lived • i Definition 2 (Freshness). We say that an oracle πs is fresh secrets of party P to , which consist of the long- i i if neither party P nor the intended partner P of this oracle lived private key and theA password. After this is i j A is corrupted, and able to completely impersonate Pi, including regis- tering one-time keys at the TEXTSECURE server. if the oracle is an initiator oracle (i.e., if it retrieves Test(πs). This query can only be asked once, and • • i a one-time key from the TEXTSECURE server), then is answered by the oracle in the following way: The no Reveal query has been asked against any oracle oracle flips a fair coin , and returns , where b kb k0 = πt with πt πs, or and for two random j j i (rkBA, ckBA) k1 = (r1, r2) if the oracle← is a responder oracle, the no Reveal values r1, r2 chosen from the same distribution. • query has been asked against the unique initiator EXT ECURE t s t Please note that the T S server may be ad- oracle πj with πi πj dressed with Send queries, but not with (a) Reveal or (b) ← Corrupt queries, because (a) he does not compute any Definition 3 (cORKE Security Game). Let be a - session secrets, and (b) corruption of the TEXTSECURE nomial time adversary, and let be a challengerE who server would also reveal long-lived passwords, and thus the simulates the TEXTSECURE communicationC network. Af- registration phase would become insecure by definition. ter observing and manipulating several instances of the Security model. To define security, first we have to exclude cached ORKE protocol from Figure 8 by using the Send, trivial attacks which result from a combination of the above Reveal and Corrupt queries, may choose one fresh or- A queries, but which do not correspond to any real attacks. acle which just has successfully completed this protocol, The simplest example is asking Reveal and Test to the same and send a TEST query to this oracle. In our security oracle, which does not make sense. More subtly, we must game, this oracle will now set s0 := (rkBA, ckBA) and $ not allow this combination of queries against pairs of oracles s 0, 1 length(HKDFout). Then the party throws a fair 1 ← { } which should compute the same key, i.e., we must define coin and uses the result b to return sb to the adversary. The what a protocol session is. For protocol sessions, recently adversary may now perform some additional computations b xa involving Send, Reveal and Corrupt, and eventually issue a may choose xb by herself. Thus we set (g , g ) = c d bit b0. He wins the game if b0 = b. (g , g ). 2) The test oracle is a responder oracle πt . In this case, Since an attacker may always win this game with prob- B may choose x , and thus we have to embed the CDHA ability 1 by just guessing b, we cannot use this winning a 2 challenge as (ga, gxb ) = (gc, gd). probability directly in our security definition. A protocol should only be considered broken if an attacker can do Since HKDF is modeled as a random oracle, we may significantly better that just guessing. replace HKDF by a programmable random oracle RO sim- ulated by the challenger . The adversary may now follow C Definition 4 (cORKE security). Let P r (b0 = b) be the two strategies: either he tries to compute b0 by querying RO, probability that attacker wins the gameE described in or he doesn’t. If he doesn’t, then his advantage in this game E Definition 3. We say that an attacker breaks the cORKE is 0, since s0 and s1 are both random. 1 protocol if Adv := P r (b0 = b) 2 is non-negligible. If he does query RO, then he has to provide the full input E | E − | xb a b xa xa xb The cORKE protocol is secure if no such attacker exists. (g · , g · , g · , const0, constR). In case 1, the second value is the solution to the CDH challenge, and in case 2 Theorem 1. If the Gap-DH assumption holds10 in it is the first value. Since simulates RO, he sees these and we model as a non-programmable Curve25519 HKDF values. With the help of theC DDH oracle can check if random oracle, then cORKE is a secure cached ORKE these values are the solution to the CDH problem.C protocol and we have For all other simulation steps, only has to check if (n`)2 the input provided by either or byC one of the simulated Adv + (n`)gDH . A A ≤ 2q oracles has already been asked to RO, and either return a freshly chosen random value, or the value stored in the Proof. The proof is organized as a sequence of games. . To be able to do so, we need the DDH oracle from Let be an arbitrary adversary, and let be the cORKE the gap-DH assumption. For example, if we use gb to embed challenger.A Let be the order of C . q Curve25519 one value from the CDH assumption, and the adversary Game 0: This is the original cORKE security game. sends message (4) where xa is chosen by the adversary, Game 1: In this game we exclude collisions in the DH then cannot compute (gxa )b; however, with the help of shares for the cORKE subprotocol. (For the full TEXT- the DDHC oracle, can check if CDH(gxa , gb) equals any SECURE protocol we would need a different, but still neg- value queried before,C and thus adapt the answer. ligible bound, because of the ephemeral shares used for Thus we have the ratcheting.) Since there are n parties, and each party 2 3 may fork off at most ` process oracles, at most n` DH Adv = Adv + gDH . shares (both one-time and ephemeral) are used in the dif- A A ferent cORKE protocols. The challenger will now abort the game if any of these shares have the same value. We get 2 0 1 (n`) 5.2. Key derivation P r (b0 = b) P r + 2q , and therefore also A ≤ A 2 Definition 5 (Key derivation function [38]). A key derivation 0 1 (n`) Adv Adv + . function KDF is a function KDF that takes as input 1) a A ≤ A 2q value SKM sampled from a source of keying material, 2) Game 2: In this game we guess which of the n` oracles a length value l, 3) a salt value XTS , and 4) a context will be asked the Test query. Note that according to our variable CTXInfo (the last two inputs being optional) and security definition, neither the party of this oracle, nor its outputs a string of l bits. intended partner may be corrupted. If our guess is wrong, the simulation is aborted and the bit b0 is chosen randomly. Let us elaborate on this definition. First of all, one may This gives us wonder, why we cannot simply use a secure pseudo-random Adv1 = Adv2 (n`). function for key derivation. The reason is that PRFs require A A · a key of a certain length, e.g., a key of 512 bits in HMAC Game 3: We now want to embed our CDH challenge SHA-256 and with sufficient high min-entropy, say, at least (g, gc, gd), where g is the generator of Curve25519 used in 160 random bits. However, it may occur that though the our computations, into the simulation. To do this, we have key SKM that is input to KDF provides enough entropy, it to distinguish two cases: is not of the correct size to be used with the considered i PRF. This may occur, if e.g., SKM is the result of Diffie- 1) The test oracle is a initiator oracle πA. In this case we know that xa is chosen by the test oracle itself, so that Hellman key exchange in a group of prime order. Here, it is the adversary cannot influence this value. Additionally, usually the case that the Diffie-Hellman protocol is carried we assume that the public key gb of the intended partner out in a group of order roughly 160 bits. Since by the Diffie- has been authenticated offline. On the other hand, Hellman assumption the secret (gab) is indistinguishable A from a random value in that particular group, it provides 10. For instance, the CDH assumption holds but we have an oracle to us with 160 uniform bits. However, to thwart attacks that simulate the DDH assumption [37, p. 278f]. deploy the structure of the field, the group is actually a Algorithm 1 HKDF(key, salt, contextInfo) in the above game. k HMAC(salt, key) pr ← Key Derivation in TextSecure. The core of the key deriva- k0 HMAC(kpr, contextInfo 0x00) ← || tion in TEXTSECURE is the HMAC based key derivation k1 HMAC(kpr, k0 contextInfo 0x01) return← (k , k ) || || function HKDF due to Krawczyk [38] that is depicted 0 1 in Algorithm 1. Krawczyk showed that under reasonable assumptions, HKDF is a secure key derivation function. Let us denote by rk the secret established in the subgroup of a group of order roughly 2048 bit. Thus, though BA cORKE phase and by gxb,z the one-time key of B. After the secret provides us with 160 uniform bits, the that $ sampling xa,2 and computing represents the secret is actually of size 2048 bits. (xa,2, g ) Zp Curve25519 k = gxb,z xa,2 , key← derivation× in TEXTSECURE pro- Thus, the goal of a key derivation is actually twofold: shared · ceeds as depicted in Algorithm 2. On the one hand, the random bits from SKM need to be extracted (for reasons described above) and on the other hand they need to be expanded, that is an output of the Algorithm 2 KDFTS(rkBA, kshared, aux) desired length is to be produced (we often omit where l l 1: (constR, const2, const1, const0, constK ) aux the output length is clear from the context). The value r c ← 2: (kAB, kAB) HKDF(kshared, rkBA, constR const2) XTS (extractor salt) in Definition 5 may contain additional new ← c || 3: kshared HMAC (kAB, const1). public information on the extraction step (see below). It may, ← new 4: (keyEnc, keyMAC) HKDF(kshared , const0, constK ). however, also be empty. The context-variable is used to use ← SKM for different purposes. Let us in the following assume that there is an algorithm Here, variable aux contains the strings constR, const2, (SKM, α) $ Σ(1k) that inputs the security parameter and const1, const0 and constK and is parsed as these in the first outputs a← key SKM and additional information α that is step. The length variable l is set to l = 2 for KDFTS. available to the adversary about SKM. We will also refer We note that though the source of keying material SKM to Σ as the distribution of (SKM, α) and we will denote is (close to) uniformly distributed over Curve25519, it con- tains only ephemeral and non-authenticated values. , by ΣSKM and Σα the corresponding marginal distributions rkBA the only value that is uniformly and authenticated, acts as on SKM and α. Moreover, let us denote by µSKM the Min- salt, when is first called (and not as source of keying Entropy of ΣSKM. HKDF In our scenario, Σ will be the cORKE protocol from material). Thus, the key to KDFTS is rkBA the secret from above, where SKM is the key and α is the transcript that is the cORKE protocol and not kshared which is the key when available to the attacker. In case cORKE is secure it holds HKDF is called first. Therefore we can not apply [38, ΣSKM Theorem 4] on the KDF-security of HKDF directly. Rather that 2− negl. Next, we≤ define the security of a KDF with respect to we show the following: Σ. To this end, consider the following security game that Theorem 2. KDFTS is a secure KDF with respect to cORKE is played between a challenger and an adversary and A if HKDF is modelled as a non-programmable random oracle that is parametrized by Σ, and q the number of queries the and HMAC is a secure PRF. adversary may issue. We slightly deviate from the definition in [38] in that we do not allow side information on SKM. This suffices in our case sinceA the key exchange phase is Proof. Again, the proof follows the sequence of games secure (see above). On the other hand, we allow to choose approach. Let χi denote the event that the adversary breaks A XTS adaptively for each evaluation of KDF. security of KDFTS in game i. $ k 1) First, runs (SKM, α) Σ(1 ) and passes α to . GAME 0. This is the real security game as per Definition 5. C ← A 2) may now adaptively query on arbitrary values Note that here, we have SKM = rk , XTS = k and A C AB shared (XTSi, ci, li), for i = 1, . . . , q0 q. When issues CTXInfo = aux. In particular, CTXInfo and l are fixed. ≤ A query (ci, li), returns KDF(SKM, li, XTS, ci). C GAME 1. In Game 1, we proceed similar to Game 0, except 3) At some point chooses values XTS∗, c∗, l∗ such that $ A $ for the following. Instead of sampling (SKM, α) Σ(1k) XTS∗ / XTS1,..., XTSq . flips a bit b 0, 1 . ∈ { 0 } C ← { } (i.e., running Σ(1k)) we sample SKM and α independently← If b = 1, then returns KDF(SKM, l∗, XTS, c∗), other- wise, it providesC with a uniformly random bit string from the marginal distributions ΣSKM and Σα. Stated oth- $ k A erwise, we run (SKM0, α) Σ(1 ) and afterwards replace of length l. ← 4) may continue to adaptively query on SKM0 with a uniformly random value SKM. By the security A C of the cORKE protocol (Theorem 1) we have (XTSi, ci, li), i = q0 + 1, . . . , q such that XTSi = XTS∗. Pr[χ ] Pr[χ ] negl 6 0 − 1 ≤ Definition 6 (Security of KDF). We say that a KDF KDF is secure with respect to Σ if it is computationally hard to GAME 2. Game 2 proceeds similar to Game 1, except that determine the value of b significantly better than by guessing loses whenever issues a query ( , SKM, ) to the HKDF- A A · · oracle. Since SKM is sampled indpendent of α from a source Algorithm 4 TS.Dec(k, hd, C) µSKM with Min-Entropy µSKM such that 2− negl, we have ≤ parse C as C = (χ0, tag0) x¯a,2 0 Pr[χ1] Pr[χ2] negl parse χ0 as χ0 = (v0, (g ) , ctra0 , pctra0 , c0) − ≤ tag00 MACk (χ0) ← MAC GAME 3. Game 3 proceeds similar to Game if tag00 = tag0 return ( , ) m Dec6 (c) ⊥ ⊥ 2, except for the following. When issues kEnc rA c ← XTS∗ to the challenger, it samples (k , k AB) if m = return ( , ) AB , ⊥ ⊥ ⊥ uniformly at random, instead of computing return m r c (kAB, k, AB) HKDF(kshared, rkBA, constR const2). Due to Game 2,← will never issue such query|| to the A The ENCRYPT-then-MAC (EtM) construction produces HKDF-oracle (recall that SKM = rkBA) and thus, the change in Game 3 is purely conceptual. It follows: a ciphertext by encrypting the plaintext with a symmetric encryption scheme (SE) and protecting the output with a Pr[χ2] = Pr[χ3] code (MAC). Bellare and Namprem- pre have shown [39] that the EtM construction achieves GAME 4. In Game 4, we proceed similar to Game 3, for these goals under the assumptions that 1) MAC is strongly the following. When issues XTS∗, the challenger does unforgeable and 2) SE is IND-CPA-secure. As depicted in new A c not compute kshared HMAC(kAB, const1) but samples Algorithms 3 and 4, TEXTSECURE also follows this EtM- new ← kshared uniformly at random. By the PRF-properties of approach. HMAC we have Thus, we obtain the following: Pr[3] Pr[4] negl Theorem 3. (TS.Enc, TS.Dec) provides IND-CCA-security − ≤ and INT-CTXT-security if AES in counter mode is GAME 5. Game 5 proceeds similar to Game 4, except that IND-CPA-secure and HMAC is a strongly unforgeable mes- loses whenever issues a query (knew , , ) to the HKDFA- sage authentication code. A shared · · oracle. By Game 4 it follows It thus suffices to show that the underlying primitives

Pr[χ4] Pr[χ5] negl satisfy the respective security notions. We recall these prop- − ≤ erties here: Claim 1. Pr[χ5] negl. ≤ IND-CPA-security, i.e., security of encrypted mes- new • Due to Game 5, never issues a query (kshared, , ) sages, even if the adversary is provided with an A new· · to the HKDF-oracle. By Game 4, we have that (kshared) encryption oracle, holds for AES in counter-mode is the key that is input to this last evaluation of HKDF if AES itself is a pseudo-random permutation. when issues XTS∗. It follows that the output of HKDF is A message authentication code is strongly unforge- A • uniformly random from the adversaries point of view. The able if it is computationally hard for an adversary claim follows. that has access to an oracle that computes tags for 5.3. Encryption of Messages is Authenticated En- messages of the adversary’s choice, to output a pair cryption (m∗, tag∗) such that tag∗ is a valid tag for m that has not been previously output by the oracle. In The goals of authenticated encryption are indistinguisha- particular, we require that it is hard for the adversary bility of plaintext even in the presence of a decryp- to compute a tag tag0 for a message m, even if it is tion oracle (IND-CCA-security) and integrity of given pairs (m, tag) for the same message such that (INT-CTXT-security) [39] (which also guarantees plaintext- tag = tag0. For any message m and key k there is integrity). only6 one tag such that tag = HMAC(k, m) and thus there is a unique tag that will be accepted by the Algorithm 3 TS.Enc(k, hd, m) verification-algorithm of HMAC for any message. It c Enc (m) is well known [41] that any unique MAC is strongly kEnc ← x¯a,2 unforgeable if and only if it is a secure MAC (i.e., χ (v, g , ctra, pctra, c) tag← MAC (χ) if an existential forgery is computationally hard). kMAC return← C (χ, tag) Thus, by the results of [42], we may assume that ← this property is satisfied for HMAC. IND-CCA-security guarantees security of encrypted mes- sages, even if the adversary is provided with encryption and 6. Claimed Additional Security decryption oracles. The practical motivation stems from the Features discovery of padding oracle attacks (e.g., [40]). INT-CTXT- security guarantees that an adversary can not create well- We now briefly discuss how the TEXTSECURE protocol formed ciphertexts, even when having access to an encryp- achieves forward secrecy and also a security notion called tion oracle. future secrecy. Furthermore, we show that TEXTSECURE does not achieve deniability in the sense of the definition key, which can only be erased if new prekeys have given for the OTR protocol. been generated and uploaded to the server. Short-lived keys. For each new ratchet in the com- • munication flow, must generate and store the 6.1. Future Secrecy Pa ephemeral private DH key xa until it is used a The authors of TEXTSECURE formulated the security second time to derive master and chaining keys. goal of future secrecy [43]. Future secrecy guarantees that The revealing of long-lived keys alone does not compro- if, in a conversation between A and B, at some point in mise the security of any message in TEXTSECURE, since time kEnc, kMAC or ephemeral DH exponents were leaked, they only influence one parameter of the key derivation, the protocol will recover and from a certain point in time namely the shared secret secAB. on future messages will be secured again. If however in addition some medium or short-lived keys Please note that future secrecy does not hold if the whole are revealed (which are stored on the same device), the key material of one of the parties is leaked: for example, if situation becomes more complex: If a key xa,z has already rkBA (rkAB, resp.) and one private exponent is leaked, the been used for sending messages to A, but A has not received attacker may act as a man-in-the-middle and read and alter these messages at the time of the key reveal, then somehow all future messages. So one precondition for future secrecy “previous” messages can be decrypted. The same holds for is that long-lived keys remain secret. keys xa who must be kept stored until an answer from the If the long-lived keys remain secret, future secrecy will other party B has been received. be enforced with each new ratchet: Since ( , rkAB rkBA So strictly speaking, TEXTSECURE again only fulfills a resp.) is one input to the key derivation function, no attacker weaker variant of PFS, but of course the large majority of will be able to control the new keys from this point on. “previous” messages is protected by PFS. However, the question whether TEXTSECURE does achieve future secrecy depends on the amount of information that may leak to an attacker. We discuss this issue in more 6.3. Deniability depth below for the classic notion of perfect forward secrecy. Deniability, which was one of the primary design goals 6.2. Perfect Forward Secrecy in the OTR protocol, can be described as follows: Both sender and receiver of a message should be able to deny that they have sent or generated a message, by showing Perfect forward secrecy (PFS) [44]–[46] is a desirable that any other party may also have sent and generated a goal in cryptographic systems since its guarantees that if one particular message. OTR achieves this property by using of the communicating parties is forced to reveal its private a malleable encryption scheme and periodically publishing and secret keys, nevertheless all messages remain secure (i.e. the MAC key after the receiver has verified a message’s they cannot be decrypted with the revealed keys) that were authenticity. Thus, anyone could have modified the messages sent prior to this event. All major key exchange protocols plaintext and produced a valid MAC. support PFS (e.g. TLS-DHE, SSH and IPSec IKE), and a TEXTSECURE encrypts and authenticates all messages formalization has been proposed by Jager et al. [32]. PFS with symmetric primitives. Assuming the key-exchange pro- does not prevent messages sent after this event from being vides authenticated keys, either of the two communication read, since an attacker may now impersonate one of the parties knows that the received messages come from the communicating parties by using the revealed keys. communication partner. However, since both parties com- When claiming PFS for TEXTSECURE, we first have pute the same keys for encryption and MAC, neither of them to define which keys could be revealed. Since the TEXT- can cryptographically attribute authorship. This is the nature SECURE server does not store any private or secret end-to- of symmetric . end communication keys, those keys can only be revealed Looking at the protocol, we see that parties are able from a TEXTSECURE app. Here the following types of keys to simulate the whole key exchange themselves, since di- are stored: rect interaction of a second party is unnecessary thanks to Long-lived keys. The TEXTSECURE app used by prekeys cached by the server. The same can be done during • party a has to store the private DH key a for the any real conversation: at time t, a party a, communicating lifetimeP of the app, or until the user changes this with begins to derive new ephemeralP DH shares for Pb value. Additionally, it has to store the long-lived b to simulate an ongoing conversation. As long as there shared secrets sec for any communication partner isP no proof that was able to re-enter the session at a AB Pb b. time t + n, b can deny any involvement. To conclude Medium-livedP prekeys. Here party must store the the discussion,P the design of the TEXTSECURE protocol • Pa private prekeys xa,z for all public prekeys stored achieves deniability on a protocol level. at the TEXTSECURE server. These keys should be However, in practice the following happens: when a erased once they have been used in a communica- party sends a message, it needs to do so via the TEXT- tion, and a chaining key has been derived. The only SECURE server. The message itself is encrypted, but in order exception from this deletion rule is the last resort to guarantee correct delivery, the identities of the sender 11 12 (regIDa) and recipient (regIDb) have to be transmitted to Circle’s SCIMP, and . Addition- the server. The sending request is authenticated with the ally, the security of GCM in Android has been analyzed sender’s phone number and password. at CCS’14 [53]. The work revealed serious security issues The server is not able to read the content of any message allowing to intercept user messages, for example, and handles only the delivery. Therefore no one can prove— messages, or even command Android service apps, like even if the server collaborates—which content was sent. (un-)installing any apps stealthily. However, our work con- However, one major goal regarding deniability is the ability centrates on the cryptographic protocol analysis and treats to plausibly disclaim any involvement in a conversation or TEXTSECURE ’s GCM usage transparently. to deny having a conversation to some party at all. Looking at the delivery procedure of TEXTSECURE , this goal is not 8. Conclusion and Future Work achieved if the server logs all delivery requests. In conclusion, TEXTSECURE only achieves deniability theoretically. Content deniability is provided due to our Mobile messaging apps with security guarantees are security proof but we can not prove that no delivery request becoming more and more popular. Prominent mobile ap- plications for secure IM are THREEMA,SURESPOT, and will be recorded at the TEXTSECURE server. TEXTSECURE. In this paper, we have provided a detailed security analysis of TEXTSECURE. First, we precisely de- 7. Related Work scribed the protocol and then performed a security analysis of the individual steps of the protocol. This led to the dis- covery of several peculiarities, most notably the protocol’s At the 2004 Workshop on Privacy in the Electronic Soci- susceptibility for a UKS attack. We proposed a mitigation ety (WPES), Borisov et. al. [3] presented a protocol for “Off and showed that, if our mitigation is applied, TEXTSECURE the Record” (OTR) communication. The OTR protocol was actually provides authenticated encryption. To the best of designed to provide authenticated and confidential instant our knowledge, this is the first formal verification of the messaging communication with strong perfect forward se- security guarantees offered by the app. crecy and deniability: no party can cryptographically prove While TEXTSECURE’s implementation is open source, the authorship of a message. The deniability property of little is known about the competing messaging applications. OTR has been discussed by Kopf and Brehm [47]. The While THREEMA makes use of the open source library work of Di Raimondo et. al. [13], who analyzed the security NaCl [54] for cryptographic operations, its protocol is kept of OTR, is in its nature closely related to our paper. The confidential. authors point out several issues with OTR’s authentication SURESPOT is an open source project with its own crypto- mechanism and also describe a UKS attack on OTR, as well graphic protocol; an analysis of its protocol has (as far as we as, a along with fixes. We note, however, that know) not been done yet. A comparison of TEXTSECURE EXT ECURE the authentication mechanisms of OTR and T S and SURESPOT will be an interesting project for future work. have little in common: Though it aims to provide deniabil- On October 18th 2014, Open Whispersystems and sev- ity, OTR explicitly uses signatures for authentication while eral news outlets reported that WHATSAPP, a mobile mes- TEXTSECURE does not. The UKS attack on OTR described saging application with more than 500M installations via by Raimondo et al. [13] directly targets the key exchange , now uses TEXTSECURE’s protocol to provide mechanism of the protocol, whereas the attacks presented in end-to-end encryption for its users [55], multiplying the this paper are rather subtle and exploit the protocol structure protocol’s user base. Besides its Android app, WHATSAPP and key derivation of TEXTSECURE . does also offer an app for Apple’s iOS platform, and a Besides OTR, which has been widely adopted, there web-based client. TEXTSECURE’s protocol can only be used exist protocols for like IMKE [48], with WHATSAPP, if the two communicating parties are both which at being verifiable in a BAN-like logic, but has using Android and one of the latest version of WHATSAPP. never found a wider adoption. SILC [49] also has received In the context of the protocol’s role-out to WhatsApp, this a certain adoption and some discussion, but is rarely used results in WHATSAPP’s server deciding whether two users today, as is FiSH [50], a once popular plugin for IRC can communicate encrypted [56]. However, there is no clients that used Blowfish with pre-shared keys to encrypt indication to users, whether they are communicating end- messages. to-end encrypted or not. While it is not unexpected that Thomas [51] analyzed the browser-based instant mes- WHATSAPP does not offer a way for users to authenticate saging client and found that, due to an imple- each other’s key – naturally, WHATSAPP suffers from the mentation error, Cryptocat used private keys of insufficient same shortcomings, as TEXTSECURE–WHATSAPP does length when establishing a group chat session. Green [52] not even offer a way for users to compare key fingerprints. recently discussed Cryptocat’s group chat approach from a Altogether the existing differences warrant the conclusion protocol perspective and points out several issues. that one should not deduce WHATSAPP’s security proper- Further protocols exist that aim at securing instant mes- saging communication but have, to the best of our knowl- 11. https://threema.ch/ edge, not received public scrutiny. Among these are Silent 12. https://surespot.me/ ties from TEXTSECURE’s. Instead, a thorough analysis of [18] D. J. Bernstein, “Curve25519: new diffie-hellman speed WHATSAPP can be subject of future research. records,” in PKC, 2006. [Online]. Available: http://cr.yp.to/ecdh/ curve25519-20060209.pdf Acknowledgments [19] “Advanced encryption standard (aes),” National Institute of Standards and Technology (NIST), FIPS PUB 197, U.S. Department of Com- merce, Nov. 2001. The authors thank Dominik Preikschat for the initial [20] R. Housley, “Cryptographic Message Syntax (CMS),” RFC 5652 documentation of TextSecure’s source code during his bach- (INTERNET STANDARD), Internet Engineering Task Force, Sep. elor thesis, David L. Gil for highlighting the application 2009. [Online]. Available: http://www.ietf.org/rfc/rfc5652.txt of HMAC in the Random Oracle Model, Brian Smith for [21] H. Krawczyk, M. Bellare, and R. Canetti, “HMAC: Keyed-Hashing pointing out several publications, and Tibor Jager, as well for Message Authentication,” RFC 2104 (Informational). as, our anonymous reviewers and Trevor Perrin for their [22] D. E. 3rd and T. Hansen, “US (SHA and comments and insightful discussion. HMAC-SHA),” RFC 4634 (Informational). The research was supported by the German Ministry of [23] R. Fielding and J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Research and Education (BMBF) as part of the VERTRAG Authentication,” RFC 7235 (Proposed Standard). research project. [24] T. Perrin, “Axolotl ratchet,” Jun. 2014. [Online]. Available: https://github.com/trevp/axolotl/wiki References [25] C. Meyer, J. Somorovsky, E. Weiss, J. Schwenk, S. Schinzel, and E. Tews, “Revisiting ssl/tls implementations: New bleichenbacher side [1] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer, channels and attacks,” in 23rd USENIX Security Symposium (USENIX “OpenPGP Message Format,” RFC 4880 (Proposed Standard). Security 14), 2014. [2] B. Ramsdell and S. Turner, “Secure/Multipurpose Internet Mail Ex- [26] A. Karjalainen and N. Mehta, “The heartbleed bug,” 2014. [Online]. tensions (S/MIME) Version 3.2 Message Specification,” RFC 5751 Available: http://heartbleed123.com/ (Proposed Standard). [27] C. Meyer and J. Schwenk, “Sok: Lessons learned from ssl/tls attacks,” [3] N. Borisov, I. Goldberg, and E. A. Brewer, “Off-the-record commu- in WISA, 2013, pp. 189–209. nication, or, why not to use pgp,” in WPES, 2004, pp. 77–84. [28] N. J. AlFardan and K. G. Paterson, “Lucky thirteen: Breaking the [4] V. Moscaritolo, G. Belvin, and P. Zimmermann, “Silent circle instant tls and dtls record protocols,” in IEEE Symposium on Security and messaging protocol protocol specification,” 2012. Privacy, 2013. [5] Electronic Frontier Foundation, “Secure messaging scorecard,” 2014. [29] N. J. AlFardan, D. J. Bernstein, K. G. Paterson, B. Poettering, and [Online]. Available: https://www.eff.org/secure-messaging-scorecard J. C. N. Schuldt, “On the security of in tls,” in USENIX Security, [6] Open WhisperSystems, “The new TextSecure: Privacy beyond 2013. SMS,” Feb. 2014. [Online]. Available: https://whispersystems.org/ [30] C.-P. Schnorr, “Efficient identification and signatures for smart cards,” blog/the-new-textsecure/ in CRYPTO’89, 1989. [7] ——, “TextSecure, now with 10 million more users,” Dec. 2013. [Online]. Available: https://whispersystems.org/blog/ [31] R. Cramer, I. Damgard,˚ and B. Schoenmakers, “Proofs of partial cyanogen-integration/ knowledge and simplified design of witness hiding protocols,” in CRYPTO’94, 1994. [8] M. Crider, “CyanogenMod is now installed on over 10 million android devices,” Dec. 2013, [online] Available: [32] T. Jager, F. Kohlar, S. Schage,¨ and J. Schwenk, “On the security of http://www.androidpolice.com/2013/12/22/ -is-now- TLS-DHE in the standard model,” in CRYPTO 2012, 2012. installed-on-over-10-million-android-devices/. [33] K. G. Paterson, T. Ristenpart, and T. Shrimpton, “Tag size does [9] T. Fox-Brewster, “WhatsApp adds end-to-end encryption using Text- matter: Attacks and proofs for the TLS record protocol,” in ASI- Secure,” November 2014, http://www.theguardian.com/technology/ ACRYPT 2011, ser. LNCS, D. H. Lee and X. Wang, Eds., vol. 7073. 2014/nov/19/-messaging-encryption-android-. Springer, Dec. 2011, pp. 372–389. [10] M. Marlinspike, “Advanced cryptographic ratcheting,” https:// [34] R. Canetti and H. Krawczyk, “Analysis of key-exchange protocols and whispersystems.org/blog/advanced-ratcheting/, November 2013. their use for building secure channels,” Cryptology ePrint Archive, Report 2001/040, 2001, http://eprint.iacr.org/2001/040. [11] P. Z. Vinnie Moscaritolo, Gary Belvin, “Silent circle instant messag- ing protocol,” https://silentcircle.com/sites/default/themes/silentcircle/ [35] C. J. F. Cremers and M. Feltz, “Beyond eCK: Perfect forward assets/downloads/SCIMP paper.pdf, December 2012. secrecy under actor compromise and ephemeral-key reveal,” in ES- ORICS 2012, 2012. [12] D. Dolev, C. Dwork, and M. Naor, “Nonmalleable cryptography,” SIAM Journal on Computing, vol. 30, no. 2, pp. 391–437, 2000. [36] F. Bergsma, T. Jager, and J. Schwenk, “One-round key exchange with [13] M. D. Raimondo, R. Gennaro, and H. Krawczyk, “Secure off-the- strong security: An efficient and generic construction in the standard record messaging,” in WPES, 2005, pp. 81–89. model,” in PKC 2015, 2015. [14] W. Diffie, P. C. van Oorschot, and M. J. Wiener, “Authentication and [37] J. Katz and Y. Lindell, Introduction to modern cryptography. CRC authenticated key exchanges,” Des. Codes Cryptography, 1992. Press, 2014. [15] H. Krawczyk, “SIGMA: The “SIGn-and-MAc” approach to au- [38] H. Krawczyk, “Cryptographic extraction and key derivation: The thenticated Diffie-Hellman and its use in the IKE protocols,” in HKDF scheme,” in CRYPTO 2010, 2010. CRYPTO 2003, 2003. [39] M. Bellare and C. Namprempre, “Authenticated encryption: Relations [16] T. ElGamal, “A public key and a signature scheme based among notions and analysis of the generic composition paradigm,” on discrete logarithms,” in CRYPTO’84, 1984. Journal of Cryptology, vol. 21, no. 4, pp. 469–491, Oct. 2008. [17] C. Boyd, Y. Cliff, J. G. Nieto, and K. G. Paterson, “Efficient one- [40] S. Vaudenay, “Security flaws induced by CBC padding - applications round key exchange in the standard model,” in ACISP 08, 2008. to SSL, IPSEC, WTLS ...” in EUROCRYPT 2002, 2002. [41] M. Bellare, O. Goldreich, and A. Mityagin, “The power of verifica- Appendix tion queries in message authentication and authenticated encryption,” Cryptology ePrint Archive, Report 2004/309, 2004, http://eprint.iacr. The complete message flow in the TEXTSECURE proto- org/. col is depicted in Figure 9. [42] M. Bellare, “New proofs for NMAC and HMAC: Security without collision-resistance,” in CRYPTO 2006, 2006. [43] Open WhisperSystems, “The new TextSecure: Privacy beyond SMS,” Feb. 2013. [Online]. Available: https://whispersystems.org/ blog/advanced-ratcheting/ [44] C. G. Gunther,¨ “An identity-based key-exchange protocol,” in EURO- CRYPT’89, 1989. [45] M. Bellare, D. Pointcheval, and P. Rogaway, “Authenticated key exchange secure against dictionary attacks,” in EUROCRYPT 2000, 2000. [46] H. Krawczyk, “HMQV: A high-performance secure Diffie-Hellman protocol,” in CRYPTO 2005, 2005. [47] G. Kopf and B. Brehm, “Phrack magazine: Secure function evaluation vs. deniability in OTR and similar protocols,” Apr. 2012. [Online]. Available: http://phrack.org/issues/68/14.html [48] M. Mannan and P. C. van Oorschot, “A protocol for secure public instant messaging,” in Financial Cryptography and Data Security, 2006. [49] P. Riikonen, “Secure internet live conferencing pro- tocol specification DRAFT,” 2007. [Online]. Available: http://tools.ietf.org/id/draft-riikonen-silc-spec-09.txt [50] Unkown, “FiSH – secure communications with ,” 2007. [Online]. Available: http://ultrx.net/doc/fish/ [51] S. Thomas, “DecryptoCat,” 2013. [Online]. Available: http://tobtu. com/decryptocat-old.php [52] M. Green, “Noodling about IM protocols,” Jul. 2014. [Online]. Available: http://blog.cryptographyengineering.com/2014/ 07/noodling-about-im-protocols.html [53] T. Li, X. Zhou, L. Xing, Y. Lee, M. Naveed, X. Wang, and X. Han, “Mayhem in the push clouds: Understanding and mitigating security hazards in mobile push-messaging services,” 2014. [54] D. J. Bernstein, T. Lange, and P. Schwabe, “The security impact of a new cryptographic library,” in LATINCRYPT 2012, 2012. [55] M. Marlinspike, 2014. [Online]. Available: https:// openwhispersystems.org/ [56] ——, “Second thoughts on whatsapp encryption,” 2014. [Online]. Available: https://www.mail-archive.com/messaging@moderncrypto. org/msg01138.html a GCM b P TS P (1) phone#a g Curve25519 ∈ a (2) 204 OK (a, g ) R Zp Curve25519 ∈ × pw SHA1PRNG[128] (3) token R 100000,..., 999999 ∈R ∈ { } authenticationa = phone#, pw regIDa R SHA1PRNG[128] (4) token, kenc, ,A, kmac, ,A, regIDa, ∈  TS TS kenc, ,A R SHA1PRNG[128] supportSms (bool), authenticationa TS ∈ kmac, ,A R SHA1PRNG[128] (5) 204 OK GenerateTS 100∈ prekeys + last resort key (klr) a x¯a,0 x¯a,99 x¯a,100 xa,i (6) g , g , . . . , g , g = klr, authenticationa (xa,i, g ) R Zp Curve25519 ∈ × (7) 204 OK

(8) Registration GCM

gcm (9) regIDa

gcm (10) regIDa , authenticationa

(11) 204 OK

(12) get prekey: phone#b, authenticationa

xb,z b Choose prekey with (13) g , z, g , regIDb x¯a,0 prekey ID z (¯xa,0, g ) R Zp Curve25519 xa,z xb,z∈ a b xׯa,0 xb,z x¯a,0 a) delete g secint = g · , g · , g · (rkBA, ckBA) = HKDF (secint, const0, constR) x¯a,1  (¯xa,1, g ) R Zp Curve25519 x¯a,2 ∈ × (¯xa,2, g ) R Zp Curve25519 xb,z∈ x¯a,2 × kshared = g · b) (rkAB, ckAB) = HKDF (kshared, rkBA, constR)

(kEnc, kMAC) = HKDF (MACckAB (const1) , const0, constK )

ckAB = MACckAB (const2) m M c =∈ENC (m) kEnc ctra = 0 c) pctra = 0 x¯a,2 χ = (v, g , ctra, pctra, c) (14) χ, tag, z, gx¯a,0 , ga, regID , regID , a b check: regIDb belongs to phone#b tag = MAC (χ)∗ kMAC phone#b, authenticationa signal x¯a,0 a c = ENCkenc, ,B (χ, tag, z, g , g , phone#a) signal TS signal mac = MACkmac, ,B c TS

(15) csignal, macsignal, regIDgcm  b signal signal signal0 signal (16) c , mac mac = MACkmac, ,B c TS if macsignal0 = macsignal then: signal  DECkenc, ,B c TS get prekey: xb,z a xb,z x¯a,0b x¯a,0 xb,z secint = g · , g · , g · (rkBA, ckBA) = HKDF (secint, const0, constR) x¯a,2 xb,z  kshared = g · (rkAB, ckAB) = HKDF (kshared, rkBA, constR)

(kEnc, kMAC) = HKDF (MACckAB (const1) , const0, constK ) tag00 = MACk (χ) MAC ∗ if tag00 = tag then: m = DEC (c) kEnc

ckAB = MACckAB (const2)

Answer: x¯b,0 (¯xb,0, g ) R Zp Curve25519 x¯∈a,2 x¯b,0 × kshared = g · (rkBA, ckBA) = HKDF (kshared, rkAB, constR)

(kEnc, kMAC) = HKDF (MACckBA (const1) , const0, constK ) m M c =∈ENC (m) kEnc

ckBA = MACckBA (const2) signal x¯b,0 b signal signal (17) c = ENCkenc, ,A χ, tag, g , g , phone#a , mac = MACkmac, ,A c [GCM, ommited] TS TS TS ctrb = 0   pctrb = ctra = 0 x¯b,0 Legend: χ = (v, g , ctrb, pctrb, c) tag = MAC (χ)∗ kMAC 32 const0 = 0x00 Follow up message: const1 = 0x01 (k , k ) = HKDF (MAC (const ) , const , const ) const2 = 0x02 Enc MAC ckBA 1 0 K m constR = ”WhisperRatchet” M c =∈ENC (m) constK = ”WhisperMessageKeys” kEnc v = 2 ckBA = MACckBA (const2) signal x¯b,0 b signal signal (18) c = ENCkenc, ,A χ, tag, g , g , phone#a , mac = MACkmac, ,A c [GCM, ommited] ctrb = ctrb + 1 = 1 TS TS TS   pctrb = ctra = 0 x¯b,0 χ = (v, g , ctrb, pctrb, c) tag = MAC (χ)∗ kMAC

Figure 9: The complete TEXTSECURE protocol.