Raja Naeem Akram
email: rnakram@waikato.ac.nz

Ryan K L Ko

End-to-End Secure and Privacy Preserving Mobile Chat Application

Since the 1990s, two technologies have reshaped how we see and experience the world around us. These technologies are the Internet and mobile communication, especially smartphones. The Internet provides a cheap and convenient way to explore and communicate with distant people. A multitude of services have converged on the smartphone platform, and potentially the most notable is social networking. With increased interconnectivity and use of online services, concerns about consumers' security and privacy are growing. In this paper, we evaluate the security-and privacy-preserving features provided by existing mobile chat services. This paper also puts forwards a basic framework for an End-to-End (E2E) security and privacy-preserving mobile chat service and associated requirements. We implemented the proposal to provide proof-of-concept and evaluate the technical diculty of satisfying the stipulated security and privacy requirements.

Introduction

The instant messaging services provided by applications like WhatsApp, Apple iMessage and BlackBerry Messenger are overtaking traditional SMS services [START_REF] Thomas | Rapid Rise of Chat Apps Slims Texting Cash Cow for Mobile Groups[END_REF], becoming the preferred medium of communication for millions of smartphone users 1 . However, the security and privacy-preserving features of dierent mobile applications have come under the spot-light [START_REF] Greenwald | NSA Collecting Phone Record of Millions of Verizon Customers Daily[END_REF]. There are dierent security and privacy features provided by dierent mobile chat applications, but there are not many mobile chat applications that provide an End-to-End (E2E) security and privacy-preserving service to their customers.

In this paper, we focus on such a mobile chat service. We propose a framework for building such a service and then evaluate the technical challenges involved in implementing it, to provide a proof-of-concept and understand any potential technical issues which may restrict such features from being implemented by mainstream mobile chat service providers.

1 Financial Times report [START_REF] Thomas | Rapid Rise of Chat Apps Slims Texting Cash Cow for Mobile Groups[END_REF] put the number of daily instant messages at 41billion and WhatsApp has more than 200 million active monthly users [START_REF] Paczkowski | WhatsApp: Bigger Than Twitter[END_REF].

Contributions of the Paper

This paper deals with the security and privacy-related challenges faced in the design, development and maintenance of a mobile chat service. The main contributions of this study are:

1. End-to-End (E2E) security and privacy-preserving architecture for mobile chat services 2. Secure key exchange, even when communicating parties are not online (i.e. for oine messages) 3. User-to-User (U2U) authentication mechanism 2 4. Implementation analysis of proposed architecture 1.2 Structure of the Paper Section 2 discusses the evolution of mobile phone technology and how mobile chat is becoming a convenient method of communication. In section 3, we explore the existing commercial applications that provide dierent degrees of security and privacy features. In addition, we also stipulate the security and privacy requirements for an E2E secure and privacy-preserving mobile chat service. Subsequently, we describe the proposed framework along with the details of crucial operations. In section 4, practical implementation experience is presented.

Section 5 provides an overall analysis of the proposed/implemented framework.

Finally in section 6 we provide potential future research directions and conclude the paper.

Mobile Phones

In this section, we briey visit smartphone technology in order to understand the scale of the market, which directly relates to the security and privacy concerns of mobile chat users.

Smartphones: A Paradigm Shift

The mobile phone platform has evolved a long way from the original simple medium of voice and text communication to become the hub of the digital world.

Mobile phones, along with being an entertainment hub, have also developed into a social construct that has aliations and emotional attachments for individuals.

It is also becoming the predominant medium for connecting with the world through social media sites/applications [START_REF] Vincent | Aliations, Emotion and the Mobile Phone, in Cross-Modal Analysis of Speech, Gestures, Gaze and Facial Expressions, ser[END_REF][START_REF] Ling | New Tech, New Ties: How Mobile Communication Is Reshaping Social Cohesion[END_REF].

The so-called App Culture promoted by Apple Inc. [START_REF] Laugesen | What Factors Contributed to the Success of Apple's iPhone[END_REF][START_REF] Akram | Building the Bridges A Proposal for Merging dierent Paradigms in Mobile NFC Ecosystem[END_REF], has enabled users to seamlessly download any application they desire. This has opened the smartphone platform to a wide range of companies and services. One of the most 2 An authentication mechanism that enables individual users to authenticate each other during a chat session without involving the respective chat servers. prominent services provided by dierent applications on smartphones is mobile chat. It provides a potentially convenient and cost-eective alternative to traditional voice and SMS 3 . Mobile chat services have the potential to eclipse SMS communication and this trend is becoming more obvious on a daily basis [START_REF] Thomas | Rapid Rise of Chat Apps Slims Texting Cash Cow for Mobile Groups[END_REF].

With consumers' increasing reliance on mobile chat services, security and privacy features are becoming serious concerns [START_REF] Shabtai | Google Android: A Comprehensive Security Assessment[END_REF][START_REF] Becher | Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices[END_REF].

Consumers use a mobile chat service to communicate with each other, a process that can include relaying personal information. The security and privacy of such communications should be taken seriously. However, recent episodes of vulnerability in the major chat services (i.e. WhatsApp [START_REF] Goodin | The WhatsApp Architecture Facebook Bought for $19 Billion. Online. High Scalability[END_REF]) reveal that they might not be robustly implementing security and privacy features.

In the following sections, we briey explore the range of mobile chat applications available on Android and iOS. This discussion provides an analysis of existing work in the commercial arena. In section 2.6, we discuss existing academic work related to security and privacy-preserving chat software. The selection of commercially available chat software was made in a manner that reects the existing approaches, and it is by no means an exhaustive list.

WhatsApp

WhatsApp is considered to be one of the biggest mobile chat services available on dierent platforms (e.g. iOS, and Android). The architecture of the service is proprietary and the details in this section are taken from a range of resources; notably from [11]. The main focus of the product is on messaging and privacy concerns are secondary. WhatsApp does not store any messages on the server: the chat history is stored on the client's device. The client application uses SSL [START_REF] Freier | RFC:6101 -The Secure Sockets Layer (SSL) Protocol Version 3.0[END_REF] to connect to the server; however, a recent blog posting [START_REF] Goodin | The WhatsApp Architecture Facebook Bought for $19 Billion. Online. High Scalability[END_REF] discussed the deployment of SSL version 2. This deployment might open up WhatsApp to attacks on SSL 2.0. There is no E2E encryption to provide security in chat messages between sender and receiver. Therefore, the message server can read the messages exchanged.

BlackBerry Messenger

BlackBerry Messenger (BBM), for better or worse, is perceived to be a secure messaging service. In this section, we examine the consumer version of the BBM, not the business application. An analysis conducted by Communications Security Establishment Canada (CSEC) in 2011 found a number of issues with the BBM [13]. Messages are encrypted but the cryptographic key used is a global key that is common to every BlackBerry device/application. The use of a single key to encrypt all messages sent using BBM enables the message server to decrypt 3 Smartphone-based mobile chat services use the Internet as the communication medium, and this might be provided by a Telecom operator. In some areas the cost for mobile data might reduce its benets in comparison to traditional Telecom services. the messages. In addition, there is a potential for malicious users to gain access to the global key and decrypt any intercepted messages sent or received via BBM.

Wickr

The most recent addition to the range of secure chat applications is Wickr.

Although most of their architecture is proprietary, in this section we discuss the features they claim to oer 4 . They claim that they encrypt individual messages using a cryptographic key. However, it is dicult to determine whether these keys are generated by the message server or the clients. They only claim that users' private keys are not communicated to the server. Furthermore, it is claimed that device, location and Meta information about users and messages is protected, providing a strong privacy mechanism. Communication between the device and the message server is protected by TLS [START_REF] Dierks | RFC 5246 -The Transport Layer Security (TLS) Protocol Version 1.2[END_REF].

Silent Text

Similar to mobile chat applications discussed above, the complete architectural design of Silent Text is proprietary. There is fragmentary information available on their website 5 . Silent Text enables E2E key exchange and secure message communication using the Silent Circle Instant Messaging Protocol (SCIMP) [START_REF] Moscaritolo | Silent Circle Instant Messaging Protocol: Protocol Specication, Online[END_REF].

Each message is encrypted with a new key that is expanded/derived from a master secret shared between the communicating entities. The message server does not handle any key material and does not store any messages. To share the master secret, the communicating entities have to exchange several messages (before they can actually communicate). It is not clear from their white paper [START_REF] Moscaritolo | Silent Circle Instant Messaging Protocol: Protocol Specication, Online[END_REF] and website whether their key sharing protocol supports oine communication 6 .

Related Work

Security and privacy issues in relation to smart phones have received considerable attention [START_REF] Landman | Managing Smart Phone Security Risks[END_REF][START_REF] Felt | I've Got 99 Problems, but Vibration ain't One: A Survey of Smartphone Users' Concerns[END_REF][START_REF] La Polla | A Survey on Security for Mobile Devices[END_REF] with regard to mobile chat applications. Although there are a number of mobile chat applications that claim to provide a secure service, their complete architecture is not publicly available. To our best knowledge there are not many publications that describe such systems. Secure text messaging systems have a strong foundation in proposals like Media Path Key Agreement for Unicast Secure RTP (ZRTP) [START_REF] Zimmermann | ZRTP: Media Path Key Agreement for Unicast Secure RTP[END_REF], O-the-Record (OTR) [START_REF] Alexander | Improved User Authentication in O-the-record Messaging[END_REF] and A Secure Text Messaging Protocol [START_REF] Belvin | A Secure Text Messaging Protocol[END_REF]. In this paper, we aim to present a potential architecture along with security and privacy-preserving architecture to provide a complete architecture, thereby lling the gap in the existing work in the area of mobile chat applications.

Secure and Privacy Preserving Mobile Chat

In this section, we rst discuss the security and privacy requirements of mobile chat applications. In the remaining part of this section, we detail a proposed architecture and describe its features. should not be able to retrieve the messages.

Proposed Architecture

The generic architecture of a secure and privacy-preserving mobile chat application is shown in Figure 1.

After downloading a mobile chat application, the user of mobile `A' initiates the sign-up process. The sign-up process is used either to create a new account or to sign in using an existing account (credentials). The chat server, which consists of a membership server and a message server, initiates the account creation process. The membership server manages the user's accounts, associated credentials and (optionally) the user's contact-list. The message server handles the message communication between users, whether both users are online or if the intended recipient is oine. If the recipient is oine, the message will be stored in the oine message store. These messages are temporarily stored and once they are delivered to the respective recipients they are deleted. The dotted line represents virtual communication between the users of mobiles `A' and `B', via the message server.

Chat Server

Membership Server

Message Server Offline Message Store The communication link between the mobile application and the message server is protected using cryptography. In addition, the virtual communication link between the users of mobiles `A' and `B' is encrypted using the cryptographic keys generated and known only to the respective applications (of users `A' and `B').

The generic architecture shown in Figure 1 is essentially deployed by all of the mobile chat services discussed in section 2. However, the dierentiator is the features deployed by the proposed architecture that are discussed in subsequent sections.

Signing Up

When a user completes the installation of an application and wants to create a new account or connect using existing credentials, they can initiate the sign-up process described below:

1. User selects either the new account option or an existing account.

(a) If the user is an existing customer, then she will provide her account credentials (login/password) (b) If the user is a new customer, she will provide her email address 7 and provides a password (for mobile applications)

2. The server checks the provided information from the previous step, and instructs the application to generate local credentials. In addition, the server also generates a unique alphanumeric sequence that acts as the user identier.

3. The mobile application generates a set of keys 7 Email verication is carried out as part of the account creation process, in which an account only becomes active after the user clicks the account activation link sent to her (provided) email address.

(a) A signature key pair for TLS [START_REF] Dierks | RFC 5246 -The Transport Layer Security (TLS) Protocol Version 1.2[END_REF] (b) A public key pair for encryption/decryption operations (c) A symmetric storage key to encrypt/decrypt local storage that includes contact list, chat history and key store.

4. On the mobile application's request and verication by the chat server, it issues cryptographic certicates to both the signature key and the public key of the application

In subsequent communications between the mobile chat application and the chat server, a unique alphanumeric user ID and cryptographic certicate is used to authenticate the user/application and establish a TLS session (i.e. a two-way authentication-based SSL/TLS session). To add users to contact lists, their email address or unique identities can be used. When user `A' makes a request to add user `B' and she accepts the request, both users will then share their public keys along with associated certicates (issued by the chat server). The certicates provide the necessary guarantee that the received public key indeed belongs to the appropriate user.

Key Exchange

Keeping in mind the requirements listed in section 3.1, we have to design a key exchange process that can work even when the intended recipient(s) are oine.

The requirement for an oine key exchange rules out any synchronous two-way key sharing protocols. The rationale behind having an oine key exchange is to avoid restricting a user to communicating only if a key is already shared. In addition, sharing a key only when both parties are online might not be a feasible proposition. Furthermore, in group chats all users would have to be online to share the key before they could start secure communication with each other. In this situation, if a single participant is oine then either she might not be able to read messages exchanged in the group chat or she has to be removed from the group if the chat session has to be established/continued.

Master (Symmetric) Key Cryptographic Algo Key Lifetime Timestamp

Four Random Numbers Therefore, we propose a scheme for key sharing that can accommodate such requirements. Each communicating party will generate a random key and encrypt it using the public key of the intended recipient. The encrypted message contains a number of elements shown in Figure 2. Timestamps [START_REF] Dyreson | Timestamp semantics and representation[END_REF] are included to avoid any potential replay attacks. Clock synchronisation between the communicating entities (users) is not required to use the timestamp, because when a mobile application connects to the chat server, it gets a time (server time) and uses it as an internal application. The timestamp included in the message is taken from this internal application time and not from the device/user time. All applications will get internal time synchronised with the chat server whenever they connect with it, thus removing the need to synchronise device clocks between users.

The key lifetime eld gives a choice to the user/mobile-application to set a limit on key usage. The key lifetime eld can congured to a session-based lifetime or to any arbitrary time (e.g. seven days). The cryptographic algo eld communicates the preferred symmetric key algorithm that the sender would like the receiver to use when communicating with her. The cryptographic algorithms are chosen from a list of selected algorithms which are part of the mobile chat application. The four random numbers included in the message are to generate individual message keys that are discussed in detail in section 3.6. Finally, the last block contains the master key (symmetric key) that the sender requires the receiver to use during any future communications.

Mobile A Mobile B

Encrypt with B's Public Key(Timestamp, key lifetime, cryptographic algo, four random numbers, A' master key)

Encrypt with A's Public Key(Timestamp, key lifetime, cryptographic algo, four random numbers, A' master key) Fig. 3. Key Exchange Two Users A point to note is that the key and cryptographic-algorithm choice shared by the sender communicates to the receiver that when decrypting any future messages from this sender, she should use them, as shown in Figure 3. Similarly, the receiver will also send the key share message shown in Figure 2 encrypted by the sender's public key. Therefore, both users will use their own generated keys to encrypt all their outgoing messages. The only dierence in a group chat is that the chat organiser (group creator/administrator) will generate the master key and share it with all participants, who will then use this key to encrypt all their messages. This avoids using multiple keys (equal to the number of users in the group) to communicate with all users in the group.

Mutual User-to-User (U2U) Authentication

Mobile chat authenticates itself to the chat server, but U2U authentication is between the users themselves. This authentication process does not involve the chat server and the objective of the process is to assure communicating entities that they are talking with the right person. The U2U authentication process has two phases: the opt-in and the authentication phase.

In the opt-in phase, users agree on establishing a U2U authentication mechanism. To accomplish this, two users will initiate the U2U opt-in phase shown 1. User A requests establishment of a U2U authentication mechanism with user B. The request is communicated to user B: if she accepts the establishment of U2U authentication, her decision is communicated back to user A 2. Both users A and B provide their secrets (keyword) to their respective mobile chat applications that will generate hash values of the secrets. Chat applications communicate these hash values to each other.

3. In this step, the mobile applications of A and B generate U2U secrets (individually). The mobile application of A will generate its U2U secret by hashing the concatenation of the secret of A and the hash of B's secret. Similarly, the mobile application of B will generate its U2U secret by hashing the concatenation of the secret of B and the hash of A's secret. This means that both mobile chat applications have dierent U2U authentication values 4. Either of the users can request U2U authentication; however in gure 4, A initiates the authentication phase 5. Both A and B provide their secrets to their respective mobile chat applications 6. Individual applications will have these secrets and communicate them to each other 7. Applications will then generate the U2U secret and match with the stored value. If it matches then they can ascertain that the person with whom they are chatting is not an imposter A point to note is that all the messages listed in Figure 4 are communicated condentially, using the shared cryptographic keys. These messages are encrypted as if they were chat messages, which are discussed in detail in the next section. A point to note is that our mechanism is not comparable to the SafeSlinger 8 as the U2U authentication is no associated in any way with the key generation.

Message Communication

In this section, we discuss how individual messages are constructed and how the master key is used to generate message keys. The keys are then used to encrypt and decrypt the messages. Each message send by individual users is encrypted by a dierent key, generated using the shared master key and four random numbers (gure 2).

To generate individual message keys, we use the Pseudorandom Number

Generator (PRNG) design from [START_REF] Akram | Pseudorandom Number Generation in Smart Cards: An Implementation, Performance and Randomness Analysis[END_REF], illustrated in Figure 5. The shared (four) random numbers are taken as the seed le: for each iteration a random number (n ) is encrypted using the shared master key. The output is used as the message key. The output is again encrypted using the shared master key, the output is XOR with n. The output of the XOR operation then replaces the value of n in the seed le.

Seed File

AES Encrption

Shared Master Key Message Key AES Encrption XOR Fig. 5. Message Key Generation [START_REF] Akram | Pseudorandom Number Generation in Smart Cards: An Implementation, Performance and Randomness Analysis[END_REF] The message generated will then be used to encrypt the outgoing message.

Similarly, each user will also have a second message key generator for messages they are receiving. For incoming and outgoing messages, each communicating entity will have two dierent shared master keys and seed les. Therefore, message keys for outgoing and incoming messages will be dierent.

Chat and Prole Storage

All data related to the application should be securely stored on the device. As chat histories are not stored on the server, users might need to have them on their devices. Therefore, chat histories, shared master keys, public key pairs, signature key pairs and contact lists should be stored on the device, protected with the user's Personal Identication Number (PIN) or password. For our proposal, we use a PIN-based mechanism with a short velocity limit (only three wrong tries permitted). If a user locks her applications, she can delete the application and then reinstall it again. If she provides her account credentials she can get her contact list back, but her application will new public and signature key pairs (revoking previous keys) along with establishing new master shared keys with her contacts.

In our proposal, the PIN is not the account credential that the user requires to connect with the chat server. The PIN is to authenticate the user to her mobile chat application and open her prole. The PIN is not communicated by the mobile chat application to the chat server and it is stored locally. To protect the PIN value, the application has to rely on the underlying platform and its security mechanism, which is beyond the scope of this paper.

Practical Implementation

Using the proposed architecture/features of the mobile chat application in the previous section, we detail the basic implementation carried out to provide a proof-of-concept for the proposed architecture. In this section, we discuss the practical implementation.

Technology Overview

As part of the design, we opted for using components that are publicly available and have the least license restrictions. For this reason, most of the features presented in the proposal are built using public libraries.

As shown in Figure 1, the deployment of a secure chat service requires the implementation of the chat server and the mobile application. For mobile application development, we choose the Android platform [START_REF] Rogers | Android Application Development: Programming with the Google SDK[END_REF]. The chat server was hosted on the Intel 9 Core i7, 2.70 GHz and 8GB RAM machine running Ubuntu 10 13.10.

In subsequent sections, we briey discuss the implementation experience for both the chat server and the mobile application.

Server Side Implementation

On the chat server, we deployed two logical servers. One server ran XAMPP 1.8.3 as a membership server and Mosquitto 1.2.3 as a message server. The XAMPP server is an Apache [START_REF] Apache | Apache Tomcat[END_REF] distribution containing MySQL [26], PHP [START_REF] Wenz | PHP 5.1[END_REF], and Perl [START_REF] Wall | The Perl Language Reference Manual (for Perl version 5.12[END_REF]. In addition to this, we also included Mcrypt [29] and OpenSSL [START_REF]OpenSSL: The Open Source Toolkit for SSL/TLS[END_REF] extensions.

Mosquitto [START_REF] Mosquitto | [END_REF] is an open source message server based on the MQ Telemetry Transport (MQTT) protocol [32]. The most recent release of Mosquitto supports the MQTT protocol version 3.1, which provides a very lightweight messaging architecture. We chose Mosquitto for its implementation of MQTT and the rationale behind the choice of MQTT is: 9 Intel website: www.intel.com 10 Ubuntu website: www.ubuntu.com MQTT provided several useful features, such as push notications (so that constant polling for new messages is not required by the Android-based chat application), assured message delivery and reliability, low battery usage, and also oine message Oine messages are stored on the message server until the recipient comes online, at which point these messages are sent to the recipient and removed from the server.

MQTT also provides smaller message sizes due to being a binary protocol, compared to other protocols like XMPP [START_REF] Saint-Andre | Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence, Internet RFC 3921[END_REF], which uses XML [START_REF] Bray | Extensible Markup Language -SW (XML-SW)[END_REF] for its messages. Using MQTT means that text messages are smaller in size than the same messages created with other message protocols such as XMPP (an example is the two character message :), which using MQTT generates 70 bytes, whereas the same message in XMPP is represented with 100 bytes). The low data usage for communicating the message is important from the point of view of both performance (delivery of messages) and bandwidth usage (i.e. mobile data packages).

Mobile Side Implementation

For mobile chat, we developed an application supporting Android 4.1+. Additional APIs included GSON [START_REF] Singh | GSON User Guide, User Guide[END_REF] for converting JSON, SQLCipher [36] for fully encrypted databases, Eclipse Paho [START_REF]Eclipse Paho Project[END_REF] for MQTT messaging and Spongy Castle 11 [START_REF] Castle | [END_REF] for cryptographic algorithms. The PIN is stored in the applica- tion/share preferences, and it unlocks the SQLCipher encryption/decryption key. Shared master keys, (optional) chat histories, U2U authentication secrets, and contact lists are stored in the SQLCipher database.

Overall Analysis

In section, we briey analyse the architecture and implementation of our secure mobile chat service.

Analysis of the Proposed Architecture

In section 3.1, we list 12 seven basic requirements for a secure and privacy pre- serving chat service. Taking these seven requirements, we have provided a comparison between our proposal and commercially available products discussed in section 2. The comparison based on the listed requirements is shown in table 1. It is clear that our proposal meets all the requirements, and that one of the most widely-used mobile chat services, WhatsApp does not satisfy even half of the requirements. However, in support of WhatsApp we can argue that they do not market or claim to provide a secure and privacy-preserving chat service. Therefore, it is only natural that it does not meet the majority of the requirements.

Implementation Analysis

The objective of the implementation was to provide a proof-of-concept for constructing a secure and privacy-preserving mobile chat application with publicly available specications. Therefore, this exercise was a study of the technical difculties that a chat service provider might face in developing such a service.

12 * We do not claim that this is an exhaustive list and it should be considered as a basic list of requirements.

During our development process, we did not face any technical issues. In most cases, the important components required for such a proposed service are already present, apart from concerns about handling a large number of simultaneous connections.

We only tested the application for its features and whether it adequately supports the listed requirements (section 3.1). In addition, we did not test the scalability of the implementation of the chat server. However, with regard to message generation, the implementation was comparable to any commercially available mobile chat application. However, we cannot claim the same for the chat server as we did not simulate the load test to make it comparable to other mobile chat services. Such a test is beyond the scope of this work.

Conclusion and Future Research Directions

In this paper, we provided an open specication for a secure and privacypreserving chat service. We described the basic requirements, architecture and implementation experience in deploying such a service. The aim of the paper is to develop mobile chat services and explore any potential complexities involved in such a service providing privacy protection to its customers. In this work, we explored the theoretical foundations and technical challenges faced if privacy protection is built into a chat service. We found that most of the theoretical and technical components are already available. With a few minor modications, a strongly privacy-based chat service can be constructed. We have shown that a secure and privacy-preserving chat application is technically feasible. During the implementation of the framework, we did not face any serious issues concerning the technology or performance that might make this proposal infeasible.

Whether it is a viable business is a dierent aspect of such a service, and was not considered in this paper.

In future research, we would like to experiment with the scalability and performance of the chat server: this might reveal some bottlenecks in building and maintaining a privacy-based chat server. Another potential aspect is investigation of how the text chat service proposed in this paper could be extended to a voice and video chat service. The challenges presented in providing a secure and privacy-preserving voice and/or video chat service might be more than those presented by a text-based chat service. This will give a much better insight into the development of secure and privacy-preserving services, their running costs and usability requirements, providing an opportunity to understand the underlying reasons why such services are not prevalent or widely adopted by customers.

3. 1

 1 Secure and Privacy Preserving Mobile Chat Requirements Before we present the details of the proposed architecture for mobile chat applications, this section provides a brief list of requirements that any such proposal should meet: Req1 The sign-up process should require minimal information related to the user. The account creation process should not rely heavily on Personal Identity Information (PII) Req2 The key exchange process should be secure, seamless and support o-line chat Req3 Encryption/decryption of messages should not require user interaction (i.e. least interaction) Req4 Secure oine messages can be communicated securely along with potential key share Req5 Individual users have a mechanism to authenticate each other, assuring themselves they are communicating with the right person Req6 Communications are not stored on the chat server. Individual chat sessions can be stored on the user's device Req7 Local chat storage should be adequately protected Req8 To safeguard the privacy of the users and their chat, the message-server

Fig. 1 .

 1 Fig. 1. Generic Architecture of a Mobile Chat Application

Fig. 2 .

 2 Fig. 2. Key Share Message Structure

Fig. 4 .

 4 Fig. 4. Overview Of the U2U Authentication

Fig. 6 .

 6 Fig. 6. Screen Shot of Mobile Chat Application Running on Two Android Devices

Table 1 .

 1 Comparison with Existing Chat Applications

	Criteria WhatsApp BlackBerry Messenger Wickr Silent Text Proposed Chat
	Req1	-	*	*	*	*
	Req2	-	-	( * )	( * )	*
	Req3	*	*	*	*	*
	Req4	-	-	-	-	*
	Req5	-	-	-	-	*
	Req6	*	*	*	*	*
	Req7	-	*	*	*	*

Note: * means that it meets the requirement. -stands for either does not support the requirement or information is not publicly available. ( * ) means that the requirement is partially supported.

Claims were made on their website https://www.mywickr.com/en/howitworks.php

Silent text website https://silentcircle.com/web/silent-text/

Oine Communication: In mobile chat applications, a user can send messages to other users even when they are not online, using so-called oine communication.

Acknowledgemetns

The authors would like to thank the Faculty of Computing of Mathematical Sciences for the funds supporting this research, and acknowledge the implementation inputs of Corey Brown in this research.