Instruction manuals

How Secure is Text Secure

text secure
of 17
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  How Secure is TextSecure? Tilman Frosch Christian Mainka Christoph BaderFlorian Bergsma J¨org Schwenk Thorsten Holz Horst G¨ortz Institute for IT Security, Ruhr University Bochum { firstname.lastname } Abstract  Instant Messaging  has attracted a lot of attention by users for both private and businesscommunication and has especially gained popularity as low-cost short message replacement onmobile devices. However, most popular mobile messaging apps do not provide end-to-end security.Press releases about mass surveillance performed by intelligence services such as NSA and GCHQlead many people looking for means that allow them to preserve the security and privacy of their communication on the Internet. Additionally fueled by Facebook’s acquisition of the hugelypopular messaging app W HATS A PP , alternatives that claim to provide secure communicationexperienced a significant increase of new users.A messaging app that has attracted a lot of attention lately is T EXT S ECURE , an app thatclaims to provide secure instant messaging and has a large number of installations via Google’sPlay Store. It’s protocol is part of Android’s most popular aftermarket firmware C YANOGEN M OD .In this paper, we present the first complete description of T EXT S ECURE ’s complex cryptographicprotocol and are the first to provide a thorough security analysis of T EXT S ECURE . Among otherfindings, we present an Unknown Key-Share Attack on the protocol, along with a mitigationstrategy, which has been acknowledged by T EXT S ECURE ’s developers. Furthermore, we formallyprove that—if our mitigation is applied—T EXT S ECURE ’s push messaging can indeed achieve thegoals of authenticity and confidentiality. I. I NTRODUCTION Since more than a decade,  Instant Messaging  (IM) has attracted a lot of attention by usersfor both private and business communication. IM has several advantages over classical e-mailcommunication, especially due to the chat-like user interfaces provided by popular tools. However,compared to the security mechanisms available for e-mail such as PGP [1] and s/MIME [2], textmessages were sent unprotected in terms of authenticity and confidentiality on the Internet by thecorresponding IM tools: in the early days, many popular IM solutions like MSN M ESSENGER and Y AHOO  M ESSENGER  did not provide any security mechanisms at all. AOL only added aprotection mechanism similar to s/MIME to their IM service later on and Trillian’s S ECURE IMmessenger encrypted the data without providing any kind of authentication. Nowadays, mostclients provide at least client-to-server encryption via TLS. Mechanisms like  Off the Record  (OTR) communication [3] are available that provide among other security properties end-to-endconfidentiality.As the popularity of smartphones grows, the Internet is accessible almost everywhere andmobile communication services gained a lot of attraction. IM is one of the most popular servicesfor mobile devices and apps like W HATS A PP  and S KYPE  are among the top downloaded appsin the popular app stores. Unfortunately, both applications are closed-source and it is unknownwhich security mechanisms—beside a proprietary or TLS-based client-to-server encryption—areimplemented. As such, it is hard to assess which kind of security properties are provided by theseapps and especially end-to-end encryption is missing. In the light of the recent revelations of mass surveillance actions performed by intelligence services such as NSA and GCHQ, severalsecure IM solutions that are not prone to surveillance and offer a certain level of security wereimplemented.One of the most popular apps for  secure  IM is T EXT S ECURE , an app developed by  OpenWhisperSystems  that claims to support end-to-end encryption of text messages. While previouslyfocussing on encrypted short message service (SMS) communication,  Open WhisperSystems  in-troduced data channel-based push messaging in February 2014. Thus, the app offers both aniMessage- and WhatsApp-like communication mode, providing SMS+data channel or data channel-only communications [4]. Following Facebook’s acquisition of W HATS A PP , T EXT S ECURE  gaineda lot of popularity among the group of privacy-concious users and has currently more than 500,000  installations via  Google Play . Its encrypted messaging protocol has also been integrated intothe OS-level SMS-provider of CyanogenMod [5], a popular open source aftermarket Androidfirmware that has been installed on about 10 million Android devices [6]. Despite this popularity,the messaging protocol behind T EXT S ECURE  has not been rigorously reviewed so far. While thedevelopers behind T EXT S ECURE  have a long history of research in computer security [7]–[12] andT EXT S ECURE  has received praise by whistleblower Edward Snowden [13], a security assessmentis needed to carefully review the approach.In this paper, we perform a thorough security analysis of T EXT S ECURE ’s protocol. To thisend, we first review the actual security protocol implemented in the app and provide a precisemathematical description of the included security primitives. Based on this protocol description,we perform a security analysis of the protocol and reveal an  Unknown Key-Share attack  , an attack vector first introduced by Diffie et. al. [14]. To the best of our knowledge, we are the first to discussan actual attack against T EXT S ECURE . We also reveal several other (minor) security problems inthe current version of T EXT S ECURE . Based on these findings, we propose a mitigation strategythat prevents the UKS attack. Furthermore, we also formally prove that T EXT S ECURE  with ourmitigation strategy is secure and achieves  one-time stateful authenticated encryption .In summary, we make the following contributions: ã  We are the first to completely and precisely document and analyze T EXT S ECURE ’s securepush messaging protocol. ã  We found an Unknown Key-Share attack against the protocol. We have documented theattack and show how it can be mitigated. The attack has been communicated with and andacknowledged by the developers of T EXT S ECURE . We show that our proposed methodof mitigation actually solves the issue. ã  We show that if long-term public keys are authentic, so are the message keys, and that theencryption block of T EXT S ECURE  is actually one-time stateful authenticated encryption.Thus, we prove that T EXT S ECURE ’s push messaging can indeed achieve the goals of authenticity and confidentiality.II. T EXT S ECURE  P ROTOCOL P  a  T S   GCM(1)  phone # a g  ∈  Curve25519 ( a,g a )  ∈ R  Z  p  × Curve25519  pw  ∈ R  SHA1PRNG [ 128 ] authentication a  =  phone # ,  pw  regID a  ∈ R  SHA1PRNG [ 128 ] k enc,signal,a  ∈ R  SHA1PRNG [ 128 ] k mac,signal,a  ∈ R  SHA1PRNG [ 128 ]Generate 100 prekeys + last resort key ( k lr )( x a,i ,g x a,i )  ∈ R  Z  p  × Curve25519 (2) 204 OK(3) token  ∈ R  { 100000 , . . . , 999999 } (4) token , k enc,signal,a , k mac,signal,a , regID a , supportSms (bool) , authentication a (5) 204 OK(6)  g a , g ¯ x a, 0 , . . . , g ¯ x a, 99 , g ¯ x a, 100 =  k lr ,  authentication a (7) 204 OK(8) Registration GCM(9)  regID gcm a (10)  regID gcm a  , authentication a (11) 204 OK Figure 1: T EXT S ECURE  registration.We start with a precise description of the protocol implemented by T EXT S ECURE . We obtainedthis information by analyzing the source code of the Android app and recovering the individualbuilding blocks of the protocol. T EXT S ECURE  builds upon a set of cryptographic primitives. ForECDH operations, these are  Curve25519  [15] as implemented in Google’s Android Native Library.For symmetric encryption, T EXT S ECURE  relies on AES in both counter mode without padding and  cipher block chaining mode with PKCS5 padding. For authenticity and integrity, HMACSHA256is used. Security considerations of the cryptographic primitives are not within the scope of thispaper.For push messaging via data channel, T EXT S ECURE  relies on a central server 1 ( TS  ) to relaymessages to the intended recipient. Parties communicate with  TS   via a REST-API using HTTPS. TS  ’s certificate is self-signed, the certificate of the signing CA is hard-coded in the T EXT S ECURE app. Actual message delivery is performed via Google Cloud Messaging (GCM), which basicallyacts as a router for messages.  A. TextSecure Protocol Flow T EXT S ECURE ’s protocol consists of several phases. We distinguish (i)  registration , (ii)  send-ing/receiving a first message , (iii)  sending a follow-up message , and (iv)  sending a reply .Before a client is able to communicate, it needs to generate key material and register with  TS  .When a party  P  a  first decides to use T EXT S ECURE ’s data channel communication, it chooses anasymmetric long-term key pair  ( a,g a ) , referred to as  identity key  by T EXT S ECURE ’s developers.It also uses SHA1PRNG as provided by the Android Native Library to choose a password (  pw ),a registration ID ( regID a ), and two keys  k enc,signal,a ,  k mac,signal,a , each of 128 bit length.Additionally, the client chooses 100 asymmetric ephemeral key pairs, so-called  prekeys , and oneasymmetric  last resort key  ( k lr ). When a party calculates a message authentication code (MAC),it uses HMACSHA256 as implemented by Android’s respective Native Library.For a party  P  a  to send a message to a party  P  b ,  P  a  requests one of   P  b ’s public prekeysfrom  TS  , uses it to derive a shared secret, forms a message, whereof parts are encrypted and/orprotected by a MAC, authenticates with  TS  , and transmits the message to  TS  .  TS   shares asymmetric long-term key  ( k enc,signal,b ,k mac,signal,b )  with  P  b , which it uses to encrypt all partsof   P  a ’s message that are to be transmitted to  P  b .  TS   then hands off this encrypted message toGCM for delivery to  P  b . If   P  a  wants to send a follow-up message to  P  b , it derives a new keyusing a function  f   that is seeded with existing key material. When a party does not merely senda follow-up message, but a reply within a conversation, it also introduces new entropy into theseed of   f   and transmits a new ephemeral public key.  B. Detailed Description of Messages In the following we give a detailed description of messages sent and processed in the differentphases, as well as the key derivation. 1) Registration:  The registration process is depicted in detail in Figure 1. To register withT EXT S ECURE , a party P  a  requests a verification token by transmitting its phone number ( phone # a )and its preferred form of transport to  TS   (Step 1), which  TS   confirms with a HTTP status 204(Step 2). Depending on the transport  P  a  chose,  TS   then dispatches either a short message or avoice call containing a random token (Step 3) to the number transmitted in Step 1.  P  a  performsthe actual registration in Step 4, where it shows ownership of   phone # a  by including the token,registers its credentials with the server via HTTP basic authentication [16], and sets its  signalingkeys . In this step, the client also states whether it wishes to communicate only via data channelpush message or also accepts short messages. The server accepts if the token corresponds to theone supplied in Step 3 and the phone number has not been registered yet.In Step 6,  P  a  supplies its 100  prekeys  and  k lr  to  TS  . Prekeys are not transmitted individually,but within a JSON structure consisting of a  keyID  z , a  prekey  g x a,i , and the long-term key  g a .The  last resort key  is transmitted in the same way and identified by  keyID  0xFFFFFF. The serveraccepts, if the message is well-formed and HTTP basic authentication is successful.  P  a  thenregisters with GCM (Step 8) and receives its  regID gcm a  (Step 9), which it transmits to  TS   inStep 10 after authenticating again. 2) Sending an Initial Message:  We define the period in which  P  a  employs one  prekey  tocommunicate with  P  b  as a  session . When a new session is created to exchange messages, threemain cryptographic building blocks are applied: a) a key exchange protocol with implicit authen-tication to exchange a  secret , b) a key update and management protocol (the so-called axolotlratchet [17]), which updates the encryption and MAC keys for every outgoing message, and c) astateful authenticated encryption scheme. The process is depicted in detail in Figure 2. 1  Intuitively, the key exchange is a triple Diffie-Hellman (DH) key exchange using long-termand ephemeral secret keys. This is the only step in the protocol flow that uses the long-term keys.According to the developers [17], the key management protocol provides both forward secrecy(which roughly means that  past   sessions remain secure even if the long-term key of a party iscorrupted) and future secrecy (which translates to the idea that even after leakage of a currentlyused shared key  future  keys will remain secure).The result of the key exchange and key management is input to the stateful authenticatedencryption scheme [18]. The state of the encryption scheme is provided by the key managementsystem and handed over from every call of the encryption and decryption algorithm, respectively,to the next for the whole session. Every new message is encrypted under a fresh key. The schemeguarantees confidentiality and authenticity of the exchanged messages, which we discuss in detailin Section IV. P  a  T S   GCM(1) get prekey:  phone # b , authentication a Choose prekey withprekey ID  z  delete  g x a,z (2)  g x b,z , z,  g b ,  regID b (¯ x a, 0 ,g ¯ x a, 0 )  ∈ R  Z  p  × Curve25519secret  =  g x b,z · a ,g b · ¯ x a, 0 ,g x b,z · ¯ x a, 0  ( k BA,r ,k BA,c ) =  f   ( secret , const 0 , const R )(¯ x a, 1 ,g ¯ x a, 1 )  ∈ R  Z  p  × Curve25519 (¯ x a, 2 ,g ¯ x a, 2 )  ∈ R  Z  p  × Curve25519 k shared  =  g x b,z · ¯ x a, 2 ( k AB,r ,k AB,c ) =  f   ( k shared ,k BA,r , const R )( k Enc , k MAC ) =  f   MAC k AB,c  (const 1 ) , const 0 , const K   k AB,c  =  MAC k AB,c  (const 2 ) m  ∈  M c  =  ENC k Enc ( m )ctr a  = 0pctr a  = 0 χ  = ( v,g ¯ x a, 2 , ctr a , pctr a ,c ) tag  =  MAC k MAC ( χ ) ∗      a        )        b        )     c        ) (3)  χ ,  tag , z,  g ¯ x a, 0 ,  g a ,  regID a ,  regID b , phone # b ,  authentication a check:  regID b  belongs to  phone # b c signal =  ENC k enc,signal,b  ( χ, tag ,z,g ¯ x a, 0 ,g a , phone # a )mac signal =  MAC k mac,signal,b  c signal  (4)  c signal , mac signal ,  regID gcm a Legend:const 0  = 0 x 00 32 const 1  = 0 x 01const 2  = 0 x 02const R  = ”WhisperRatchet”const K   = ”WhisperMessageKeys” v  = 2 Figure 2: Sending an initial T EXT S ECURE  message. a) Key Exchange:  In the first step,  P  a  requests a  prekey  for  P  b  and receives a JSONstructure consisting of prekeyID  z , a prekey  g x b,z , and  P  b ’s long-term key  g b .  P  a  also receives regID b  from  TS   an then chooses a new ephemeral key to calculate a  secret  as the concatenationof three DH operations, combining  P  b ’s prekey,  P  a ’s long-term key,  P  b ’s long-term key, and  P  a ’sfreshly chosen ephermeral key. b) Key Management (axolotl ratchet):  After  P  a  has completed the initial key exchange, itderives two symmetric keys  ( k BA,r ,k BA,c )  for receiving messages using  f   (cf. Algorithm 1).  f  is here seeded with  secret . For all respective parameters of   f   see Figure 2.  P  a  then chooses anew ephemeral keypair  (¯ x a, 1 ,g ¯ x a, 1 ) , which is never used and just exists because of reuse. It thenchooses another ephemeral keypair  (¯ x a, 2 ,g ¯ x a, 2 ) , which it uses to calculate  k shared  as the outputof a DH operation that takes  P  b ’s prekey  g x b,z and  ¯ x a, 2  as input.  P  a  then derives two symmetrickeys  ( k AB,r ,k AB,c )  for sending messages. Here  f   is seeded with  k shared  and  k BA,r . Finally,  P  a uses  f  , seeded with  k AB,c , to derive the message keys  ( k Enc , k MAC )  and in the end derives a new k AB,c  as  MAC k AB,c  ( const 2 ) , where  const 2  = 0 x 02 . Algorithm 1  f   ( input,key,string ) k  pr  ←  MAC key  ( input ) k 0  ←  MAC k pr  ( string, 0 x 00) k 1  ←  MAC k pr  ( k 0 ,string, 0 x 01) return  ( k 0 ,k 1 ) c) Stateful Authenticated Encryption:  A message  m  ∈  M is encrypted using AES in countermode without padding as  c  =  ENC k Enc ( m ) .  P  a  then forms message (3.) and thus calculates tag  =  MAC k MAC ( χ ) , where  χ  = ( v,g ¯ x a, 2 , ctr a , pctr a ,c ) .  v  represents the protocol version and is
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks