A SECURE MOBILE MESSAGING APPLICATION

USING IDENTITY-BASED ENCRYPTION

BY

RYAN HOLT

A Project

Presented to the Department of Information and Computer Sciences

in partial fulfillment of the requirements

for the degree of

Master of Science

in

Computer Science

Metropolitan State University

Minneapolis/St. Paul, Minnesota

April 24, 2015

TABLE OF CONTENTS

Table of Figures...........................................................................................................................................3

Table of Tables............................................................................................................................................5

Approval Page.............................................................................................................................................6

Abstract.......................................................................................................................................................7

Chapter 1 – Introduction.............................................................................................................................8

1.1 Security issues in mobile networks..............................................................................................9

1.2 State of the art...........................................................................................................................10

1.3 Project Goals..............................................................................................................................12

Chapter 2 – Background Concepts (IBE, ECC, and the PBC library)............................................................14

2.1 History of IBE.............................................................................................................................14

2.2 Elliptic Curves.............................................................................................................................15

2.3 Identity-Based Encryption..........................................................................................................16

2.4 Review of algorithms and their classifications...........................................................................16

2.5 Other interesting things about IBE.............................................................................................17

2.6 Notable Implementations..........................................................................................................17

2.7 Pros and Cons............................................................................................................................18

2.8 Why was IBE chosen?................................................................................................................18

2.9 Why was JPBC chosen?..............................................................................................................19

2.10 Why was Android chosen?.........................................................................................................19

Chapter 3 – Related Work.........................................................................................................................20

3.1 Off-The-Record (OTR) Messaging...............................................................................................20

3.2 Secure Instant Messaging and Presence Protocol (SIMPP)........................................................21

3.3 Self-Protecting EMRs.................................................................................................................24

3.4 JXTA-Overlay..............................................................................................................................26

3.5 TextSecure (Axolotl)...................................................................................................................27

3.6 Crypto-Book...............................................................................................................................28

3.7 Summary....................................................................................................................................30

Chapter 4 – Project Design and Implementation.......................................................................................31

4.1 Project Overview.......................................................................................................................31

4.2 Project Architecture...................................................................................................................31

2

4.3 Design........................................................................................................................................33

4.4 Implementation Details.............................................................................................................38

Chapter 5 - User Experience and Application Performance.......................................................................44

5.1 User Experience.........................................................................................................................44

5.2 Application Performance...........................................................................................................50

Chapter 6 – Conclusion..............................................................................................................................52

Chapter 7 - Future Work............................................................................................................................53

References.................................................................................................................................................54

3

TABLE OF FIGURES

Figure 1 - An Example of a Mobile Application Permissions Prompt...........................................................8Figure 2 - Excerpt from the Electronic Frontier Foundation's Secure Messaging Scorecard......................11Figure 3 - Identity-Based Encryption (IBE).................................................................................................14Figure 4 - Elliptic Curve y2 = x3 – 3x + 3......................................................................................................15Figure 5 - SIMPP Phase 1: Registration......................................................................................................21Figure 6 - SIMPP Phase 2: Client-Server Communications.........................................................................22Figure 7 - SIMPP Phase 3: Client-Client Communication...........................................................................23Figure 8 - SIMPP Protocol: Key Terms........................................................................................................23Figure 9 - iHealthEMR Policy Engine Flow.................................................................................................24Figure 10 - iHealthEMR Architecture Overview.........................................................................................25Figure 11 - CP-ABE and KP-ABE Mobile Performance................................................................................25Figure 12 - JXTA-Overlay Login Sequence..................................................................................................26Figure 13 - UKS attack on TextSecure........................................................................................................28Figure 14 - Crypto-Book's Anytrust Architecture.......................................................................................29Figure 15 – Crypto-Book Anonymous Key Retrieval..................................................................................29Figure 16 - High Level Project Architecture...............................................................................................32Figure 17 - Project Architecture.................................................................................................................33Figure 18 - REST Request: login.................................................................................................................34Figure 19 - REST Request - getIBEParams..................................................................................................34Figure 20 - User Authentication.................................................................................................................34Figure 21 - IBEParams Retrieval (New IBE)................................................................................................35Figure 22 – JPBC IBEParams JSON message...............................................................................................35Figure 23 - IBEParams Retrieval (Existing IBE)...........................................................................................36Figure 24 - Messaging Flow Diagram.........................................................................................................37Figure 25 - Authentication Sequence Diagram..........................................................................................38Figure 26 - SAGEBURNER_AUTH DATABASE SCHEMA...............................................................................39Figure 27 - USER TABLE DESCRIPTION.......................................................................................................39Figure 28 - Authentication Class Diagram..................................................................................................39Figure 29 - IBE Retrieval Class Diagram.....................................................................................................40Figure 30 - Message Encryption.................................................................................................................41Figure 31 - Message Decryption................................................................................................................42Figure 32 - Messaging Class Diagram.........................................................................................................43Figure 33 - Login Fragment View...............................................................................................................44Figure 34 - Friends List Fragment View......................................................................................................44Figure 35 - Conversation Fragment View...................................................................................................45Figure 36 - sageburner_im app icon..........................................................................................................46Figure 37 - Register Fragment View...........................................................................................................46Figure 38 - Logout Option on the Context Menu.......................................................................................47Figure 39 - Logout Option On The Navigation Drawer...............................................................................47Figure 40 - Client Flow Diagram.................................................................................................................48Figure 41 - User Interface Class Diagram...................................................................................................49

4

Figure 42 - IBE Performance on Modern Mobile Phones...........................................................................50Figure 43 - PBC Type a Pairing on Modern Mobile Devices.......................................................................51

5

TABLE OF TABLESTable 1 - Pairing Types (PBC).....................................................................................................................17Table 2 - Comparison of Related Projects..................................................................................................30Table 3 - Elliptic Curve Security Levels.......................................................................................................40

6

APPROVAL PAGE

7

ABSTRACT

Today, personal privacy is quickly forfeit in the name of convenience or in order to ‘take part in the conversation.’ We aren’t necessarily looking to throw away our rights, we just accept it as the ‘fee’ we pay to use ‘free’ applications and tools. Because there are often few to no perceivable consequences to giving away this information, it really does seem like we are getting all of these services for free. The problem is that the hidden cost of oversharing, like targeted advertising, might be more than some of us are willing to pay. A major culprit of these privacy violations are popular yet insecure messaging applications. One of the solutions to this problem is using advanced encryption techniques with simple implementations to make security seamless. Projects like Off-The-Record (OTR), TextSecure, and Crypto-Book are all designed with this solution in mind. Each of these projects provide exceptional security, however, the security mechanisms used beget usability issues that prevent them from being more widely adopted. In this paper I describe a novel construction of a secure messaging application for Android devices. This implementation is built on top of the Extensible Messaging and Presence Protocol (XMPP) standard as the instant messaging and presence protocol and Identity-Based Encryption (IBE) as the security mechanism. The project has three main goals. The first is to show, via a proof-of-concept, that Elliptic Curve Cryptography (ECC) is a viable security mechanism on modern mobile devices. The second is to implement this security mechanism in a way that is user friendly. This means that, in addition to an intuitive application user interface, the entire security process should be transparent to the user. The final goal is to design a system that is modular and extensible so that it is easy to create, extend, and maintain, and whose modules can be added as a security layer atop an existing system.

8

CHAPTER 1 – INTRODUCTION

In a time when oversharing is the norm and personal data is given away without much thought, it is becoming increasingly difficult for those who want to protect their privacy to keep their personal information secure. We have all heard of the virtues of big data, analytics, and crowdsourcing and their power to give us greater knowledge and make our lives easier, and for the most part we embrace it. However, because of the large volume and type of data being collected, the value of this data, and the lack of good security measures, these new phenomena have introduced a whole set of new security concerns.

Why should we be worried? While large amounts of anonymized aggregate data can be extremely useful to device manufacturers and software companies for providing support and quality assurance, as well as in medical and scientific research, it is much more useful to hackers and to those who would only use it to exploit you financially. What would be even more valuable to them would be vast quantities of very personal information. In fact, that is just the kind of data that device manufacturers, application developers, and service providers are collecting. They have the ability (and your consent) to gather very personal information such as your location, who you are talking to, the make, model, and unique identifiers of the device you are talking on, and in some cases, what you are saying. Surprised? You shouldn’t be. We are giving away our right to privacy every time we accept applications’ permissions requests like the one in the image shown below.

FIGURE 1 - AN EXAMPLE OF A MOBILE APPLICATION PERMISSIONS PROMPT

In addition to malevolent hackers, we also have a very good reason to be skeptical of our own government. Specifically, we should be concerned about the National Security Agency (NSA) and their “collect-it-all” policy on electronic communications. Their legal interpretation of the Patriot Act allows them to make use of information collected from domestic US communications without a warrant. This

9

includes bulk collection of domestic call records, information that is "inadvertently acquired" during foreign and domestic surveillance, and any electronic communications acquired because of limitations on the NSA's ability to filter communications. They are interested in any communication if it is deemed to contain usable intelligence, information on criminal activity, a threat of harm to people or property, is encrypted, or is believed to contain any information relevant to cybersecurity. That’s right. Simply the fact that data is encrypted (all HTTPS traffic would fall in this category) is justification enough for the NSA to have a look. The NSA is empowered to retain this data for up to five years. Good thing our government is a system of checks-and-balances and there’s probably someone in charge of keeping the NSA in line. Right? Wrong. The discretion as to who is actually targeted under the NSA's foreign surveillance powers lies directly with its own analysts, without recourse to courts or superiors. Oh, and if they weren’t able to collect it on their own, the NSA has the power to compel telephone and internet companies to turn over the communications of any individual identified by the NSA. [43]

Don’t look for private industry to protect your privacy either. Take Google for example. Many of their services are encrypted using SSL. They offer two step verification when accessing your Google account. They even ensure that you are protected from rogue employees and contractors with their strict contractual confidentiality agreements. However, though this might keep your data safe from some prying eyes, they have prying eyes of their own! Google utilizes automated systems that analyze your data on their systems including emails, device information, log information, location information, unique application numbers, local storage, cookies and anonymous identifiers. The technical information they gather is mostly used to improve existing services and develop new ones. The other information collected is used in a more invasive manner: enabling “tailored content” and “personally relevant product features” such as customized search results and targeted advertising. They don’t keep all this sensitive data to themselves either. They provide your personal information to their affiliates and “other trusted businesses or persons” for external processing. They also share aggregated, non-personally identifiable information publicly and with publishers, advertisers and other websites. They will also leave you high-and-dry if you should have a run-in with law enforcement. They will give up your personal information to “companies, organizations or individuals outside of Google” to “meet any applicable law, regulation, legal process or enforceable governmental request”, leaving you vulnerable to law enforcement requests or civil subpoenas. Don’t think that deleting your data from their services will protect you. Even after you delete information from their services, they “may not immediately delete residual copies from our active servers” and they may not ever remove the information from their backup systems. [34, 61]

Yahoo participates in the EU Safe Harbor program for protecting personal data. However, like Google, they have limitations when it comes to personal data retention. When you request your account be deleted or deactivated your information will remain on their system for another 90 days. Even once your account information is deleted, any of your personal information that was archived may remain in back-up storage for “some period of time” after your deletion request. [62, 65]

Both Google and Yahoo (and most other services) provide opt-out ability for some of the more invasive data collection practices.

1.1 SECURITY ISSUES IN MOBILE NETWORKSIn addition to the security concerns mentioned above, mobile networks have some unique security issues of their own. In many distributed systems, nodes are responsible for relaying messages to other

10

nodes. Because nodes may have access to messages meant for other nodes there is the possibility that malevolent nodes can passively eavesdrop on communication between other nodes. Denial-of-Service (DoS) and flow disruption (the delaying, dropping, or falsifying of relay packets) attacks are also easy in schemes where many of the nodes are inter-connected. Mobile ad-hoc networking is a type of communication taking place in unpredictable and dynamic environments. These types of systems are susceptible to signaling attacks, or transmitting false routing info, which can bring down the network. Some schemes utilize mobile agents, or software programs that can travel from system to system to perform tasks on behalf of a user. For example, a mobile agent could be tasked with visiting several different websites to find and compare prices of items. These agents must be able to operate in untrusted environments. Mobile devices themselves have resource constraints such as limited memory, processing power, and battery life. This can limit the amount of computation that can be performed or the level of communication between devices. Tradeoffs exist between bandwidth capabilities, range capabilities, and power consumption. Resource exhaustion (transmitting excessive packets to drain the batteries of a node device) can be a significant issue. Design choices have a large impact on the security of mobile networks. For example, in Peer-to-Peer (P2P) systems, decentralized systems are likely to be better suited for handing DoS attacks, while semi-centralized systems would be better suited for handling authentication. Some systems are designed with authentication and non-reputability as a primary concern. This means that under court order the system can reveal private information to government and legal authorities by cooperating to provide a key escrow service. [2, 5]

1.2 STATE OF THE ARTMessaging applications allow you to send short messages and share images and video virtually instantly with your friends, family, co-workers and loved ones via your computer, tablet or mobile phone. Most popular instant messaging apps are easy to use but communication is generally sent over insecure channels. According to the Electronic Frontier Foundation (EFF) most big-name messaging services fail to provide adequate security for their users. Security often comes at the cost of usability. Everyday users may have trouble installing and configuring secure applications, verifying other users’ authenticity, setting up accounts, or using the applications correctly. For example, Pidgin allows secure communication via a plugin called ‘Off-The-Record’ which works very well, but only an advanced user would be able to install and configure the plugin. In 2011, about 400 million mobile devices were shipped and there were around 600,000 apps available for these devices. A big driving force for the attacks on mobile devices, and the same reason that mobile security needs to be stressed, is that the value of mobile payment transactions is projected to reach over $600 billion this year. [15, 44, 66, 67]

Next I review three of the most popular messaging apps being used today and their security characteristics. I chose to look at WhatsApp, Hangouts, and SnapChat because I feel they best exemplify the current state of the art. Below is a chart from the Electronic Frontier Foundation’s website. It’s called the Secure Messaging Scorecard and it shows the security protections provided by messaging applications. As you can see, these three apps did not score very well.

11

FIGURE 2 - EXCERPT FROM THE ELECTRONIC FRONTIER FOUNDATION'S SECURE MESSAGING SCORECARD

WhatsApp is an instant messaging application developed by WhatsApp, Inc. It is available on all major mobile platforms including iPhone, Android, and Windows Phone. The company was founded by two former Yahoo! Engineers in 2009 and was eventually acquired by Facebook in February of 2014. There are 500 million registered (350 million active) WhatsApp users. WhatsApp is so incredibly popular because it is easy to use, cheaper than text (SMS) messaging (especially internationally), costs only $0.99 per year, and has no ads. Until 2012, all of WhatsApp messages were sent in plaintext. Though it has since begun encrypting messages it still does not score highly (2 out of 7 points) on the EFF's secure messaging scorecard. The app lost points because WhatsApp has access to the keys that messages are encrypted with, users can't verify other user's identities (no authentication), past messages are not secure if the encryption keys are stolen (no forward secrecy), the application source code is not open to independent review, and its security design is not properly documented. Since the acquisition by Facebook, WhatsApp has taken more interest in security. In November 2014 they entered into a partnership with Open Whisper Systems to provide end-to-end encryption by incorporating the protocol used in their TextSecure application. [45, 68]

Hangouts is Google’s mobile messaging offering. Its instant messaging feature is incorporated into the Gmail web-based email system and the Hangouts mobile messaging app is available on Android and more recently on Apple devices. The Hangouts app offers live video and voice conversations in addition to messaging. In 2013 Google reported its Google+ services had reached 540 million active users. All messages in Hangouts are sent over encrypted HTTPS connection with 128-bit encryption, using TLS 1.2. However, like WhatsApp, Hangouts only scored 2 out of 7 points on the EFF scorecard. Keep in mind Google’s Privacy Policy mentioned earlier. [46, 47, 69]

SnapChat is a photo and video messaging app created by Stanford University students Evan Spiegel, Bobby Murphy, and Reggie Brown. The main feature of the application is that photos and videos sent are auto-destroyed within 10 seconds, removed from both the recipient’s device and SnapChat’s

12

servers. The service boasts 100 million active users who send 700 million photos and videos daily. However, their premise is a little flawed. According to their official Privacy Policy, they “can’t guarantee that messages will be deleted within a specific timeframe. And even after we’ve deleted message data from our servers, that same data may remain in backup for a limited period of time. We also sometimes receive requests from law enforcement requiring us by law to suspend our ordinary server-deletion practices for specific information. Finally, of course, as with any digital information, there may be ways to access messages while still in temporary storage on recipients’ devices or, forensically, even after they are deleted.”

In addition to being unable to do good on their main premise, they also let companies “use cookies, web beacons, and other technologies” to collect your personal information including unique device information (device identifiers, manufacturer, and operating system), your IP address, the web browser you are using and the pages you are viewing with it, the links you are clicking, and how much time you spend doing it. They use this information to “analyze and track data, determine the popularity of certain content, and better understand your online activity.” They also sell this information to other companies to use in targeted advertising. The kicker: “Snapchat does not currently respond to do-not-track signals that may be sent from your device.”

Just like the two applications reviewed previously, the app that is trusted to privately manage close to one billion photos and videos every day only managed to score 2 points on the EFF scorecard. In a breach of their systems in October 2014 members of a hacker forum claimed to have collected at least 100,000 Snapchat photos. They were able to do this because the service uses very elementary encryption that would take a good hacker just a few-hours to reverse-engineer and find the key. This would be bad enough if each user had their own unique keys, but because they used a single universal key, once it was exposed the attacker would be able to decrypt everything in the system. Despite such massive security breaches being a common headline to see on the news, take Target and Home Depot for example, people don’t seem to mind as long as they get their free identity protection!. To quote an expert in the field: "These types of breaches will definitely stop people from using Snapchat … until they have a really cool picture to share." [48 - 50, 70]

1.3 PROJECT GOALSIf security can be made simple, secure applications would be more readily adopted by a larger number of users who might not otherwise be willing to deal with the headache, frustration, and tedium of current security measures. To that end, I propose the construction of a secure messaging application for Android devices. This implementation is built on top of the XMPP standard as the instant messaging and presence protocol and Identity-Based Encryption (IBE) as the security mechanism. The major goal of this project is to achieve a high level of security without distracting the user with confusing and error prone security configuration.

The paper starts with a review of the current state of the art, some of the outstanding security problems that exist in mobile messaging, and a review of some common solutions to these problems. In chapter two I do a quick review of the concepts involved in this paper such as mobile messaging, encryption, elliptic curves and bilinear groups, and identity-based encryption. I then justify my choices of the Android operating system, the XMPP messaging protocol, IBE and the JPBC library. In chapter three I review some of the related work in secure messaging applications. In the fourth chapter I describe my secure mobile messaging app and provide the details in its implementation. I review the user

13

experience and performance of my implementation in chapter five. I draw some conclusions in chapter six and in chapter seven I outline outstanding issues and future work.

14

CHAPTER 2 – BACKGROUND CONCEPTS (IBE, ECC, AND THE PBC LIBRARY)

In an Identity-Based Encryption (IBE) scheme, the public key of a user may be an arbitrary string like an email address or other identifier. Messages are encrypted using a combination of the system master key and the id of the recipient. Users must go to a trusted party and prove their identity in order to obtain a private key which will allow him to decrypt messages. This trusted party is known as the Key Generation Server (KGS). During system setup, the KGS creates a master public key and public parameters. [19, 27, 30, 59, 60]

FIGURE 3 - IDENTITY-BASED ENCRYPTION (IBE)

2.1 HISTORY OF IBEThe concept of Identity-Based Encryption (IBE) was first proposed by Adi Shamir, famous co-inventor of the RSA algorithm (among others), in 1984. Shamir introduced the concept of IBE as an approach to simplify public key and certificate management in a Public Key Infrastructure (PKI). In an IBE system a user can send an encrypted message to another party simply by knowing their identity as well as a set of global parameters, eliminating the need to distribute a separate public key for each user in the system.

Although the concept initially received a lot of interest, it wasn't until several years later that Boneh and Franklin introduced the first Identity-Based Encryption scheme using groups with efficiently computable bilinear maps. The original Boneh and Franklin result used the random oracle heuristic to prove security

15

under the Bilinear Diffe-Hellman assumption and a significant open question was whether the random oracle model could be removed. Boneh and Franklin implemented the first functional IBE scheme in the random oracle model (in 2001) and it was perfected by world-renowned cryptographers at Stanford University under US Defense funded research programs. Their implementation came to be known as the Stanford Pairing Based Cryptography (PBC) library.

Following the breakthrough result of Boneh and Franklin, there has been significant progress in realizing IBE in the standard model. First, Canetti, Halevi, and Katz proved security without the random oracle heuristic, but under a weaker “Selective-ID" model where the attacker must declare the identity that he will attack before even seeing the system's public parameters. Boneh and Boyen then provided an efficient selectively secure scheme. Subsequently, Boneh and Boyen and Waters gave fully secure solutions in the standard model. The Waters scheme provided an efficient and provably fully secure system in the standard model under the decisional Bilinear Diffie-Hellman assumption; however, one drawback was that the public parameters consisted of O(λ) group elements for security parameter λ. [7, 21, 27, 59, 60]

There has been significant work on IBE since then. Boldyreva, Goyal, and Kumar came up with an efficient revocation scheme for IBE in 2008. Brent Waters came up with the first Hierarchical IBE (HIBE) scheme and an IBE system with short parameters in 2009. De Caro, Iovino, Persiano realized the first Anonymous HIBE protocol in 2010. [21, 28, 31]

2.2 ELLIPTIC CURVESAn elliptic curve is one formed by an equation of the form y2 = x3 + ax + b over a finite field of prime order q (x, y ∈ q)

FIGURE 4 - ELLIPTIC CURVE Y2 = X3 – 3X + 3

Elliptic Curve Cryptography (ECC) is dependent on the Bilinear Diffie-Hellman (BDH) problem being hard to solve. A problem being ‘hard to solve’ means that the result of mathematical operations are fast to

16

compute, but hard to reverse. For the BDH problem, this means finding gxy given g and the values of gx

and gy. As of 2006, the most efficient solutions to the BDH problem involve solving the discrete logarithm problem (DLP); find x given g and gx. Maps are also central to ECC. Maps are classified as one-way functions, meaning it is easy to calculate their result given a pair of operands but hard to calculate the inverse. The pairings take place using two groups, an additive group and multiplicative group, over the same prime order q. The additive group is implemented using a group of points on an elliptic curve. The multiplicative group is a subset of a multiplicative group of points over a finite field. This subgroup must have the following three properties: bilinearity, non-degeneracy, and computability. This map is referred to as a “bilinear pairing.” These maps are derived from either the Weil (pronounced vay) or Tate pairings. Of these two, Tate pairing is typically faster. Computationally efficient ones are based on bilinear maps. Map is a function pairing elements from one group to another of the same prime order where the discrete logarithm problem is hard in the first group. For example, given:Pair(a ∙ X, b ∙ Y) = Pair(b ∙ X, a ∙ Y)Calculating a ∙ X is easy, and finding a given X and a ∙ X, is hard.

2.3 IDENTITY-BASED ENCRYPTIONThere are four major algorithms or steps performed in Identity-Based Encryption: Setup, KeyGen, Encryption and Decryption.

Setup: Performed by the Key Generation Server. Creates master public and private key pair based on initialization parameters.

Key Generation: Performed by the Key Generation Server. Generates and returns users’ private keys when requested after they have authenticated themselves to the KGS.

Encryption: Performed by the users. Using the recipients ID along with the master public key, the user encrypts the message and sends it to the recipient.

Decryption: Performed by the users. Using their private key, the receiving user can decrypt the encrypted message.

For more in-depth information on bilinear pairing and identity-based encryption, see Baek et al’s paper “A Survey of Identity-Based Cryptography,” Youngblood’s “An Introduction to Identity-Based Cryptography,” and Lee et al’s “Secure Key Issuing in ID-Based Cryptography” [30, 59, 60]

2.4 REVIEW OF ALGORITHMS AND THEIR CLASSIFICATIONSThe security strength of an IBE system is determined by the underlying algorithm, which, in turn, is determined by the bit-length of the parameters. Depending on system requirements, different curves and initialization parameters might be chosen.

Here is a summary of pairings available in PBC cryptosystems. ‘Type a’ is considered the fastest pairing and good for cryptosystems where group element size is not critical. It utilizes the supersingular curve y2 = x3 + x over a group order Solinas prime. ‘Type dn’ pairing is good for cryptosystems when group elements must be as short as possible. It uses the MNT method to generate curves. ‘Type e’ pairing is considered to not be useful but requires only modular arithmetic to implement. ‘Type f’

17

pairing is useful for insuring against future finite field discrete log algorithm improvements. The curve is found using the Paulo Barreto method. ‘Type gn’ pairing uses Freeman-Scott algorithm to generate curves. It is slower than embedding degree 12 pairings. No good use for this pairing has been found. Some cryptosystems need the curve order to be a specific number, e.g. N = p q where p and q are large primes so that N is hard to factorize. With ‘Type a1’ pairing, a suitable pairing can be found by using the same curve as for type a pairings. Below is a table of pairings and their attributes from the Stanford PBC Library.

Type Base Field Size (bits)

k Dlog security (bits)a 512 2 1024dn n 6 6ne 1024 1 1024f 160 12 1920gn n 10 10na1 1024 2 2048

TABLE 1 - PAIRING TYPES (PBC)

There is one particular curve classification that is of particular importance in PBC, supersingular curves. Supersingular curves are of the form y2 = x3 + x. As of 2007 there are no known weaknesses for (carefully selected) supersingular curves.

Identity-Based Encryption is referenced in several Internet Engineering Task Force (IETF) draft standards; RFC 5091 - Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems, and RFC 5408 - Identity-Based Encryption Architecture and Supporting Data Structures, among others. [16, 17, 22]

2.5 OTHER INTERESTING THINGS ABOUT IBEIdentity-Based Encryption has potential applications in a secure machine to machine (M2M) scheme in an Internet-of-Things (IoT). Identity-based proxy re-encryption schemes can be derived from existing IBE schemes. Proxy Re-Encryption (PRE) has many practical applications like email forwarding, distributed file systems, and Digital Rights Management (DRM).

In Fuzzy IBE, users’ keys and ciphertexts are associated with multiple descriptive attributes, ex. a user’s identity and time. A user’s key can decrypt a particular ciphertext only if some number of attributes (so called “error-tolerance”) match between the ciphertext and the key. The collusion-resistance property of Fuzzy IBE gives systems protection from users who have been revoked. Attribute-Based Encryption (ABE) is an encryption scheme that is derived from Fuzzy IBE and allows the authority to specify more advanced decryption policies. ABE is useful in Disruption-Tolerant Networks (DTNs) and for securing medical records (or similarly sensitive documents) on mobile devices. [7, 9, 16, 17, 23, 25, 28]

2.6 NOTABLE IMPLEMENTATIONSBoneh and Franklin developed a C++-based IBE implementation published under an MIT-style license commonly referred to as the “Stanford IBE System”. In 1988 Shamus Software developed a C++-based cryptographic library called “MIRACL” which follows Boneh and Franklin's IBE scheme. It is currently licensed to hundreds of leading companies in the United States, Brazil, Britain, Germany, France,

18

Switzerland, South Africa and Australia. Its cryptographic runtimes can be found in chips, operating systems and software applications in industries ranging from defense and intelligence to financial services and software as a service companies. In 2003 the Hewlett Packard Lab in Bristol UK developed a healthcare information system built on IBE. In 2004, Voltage security developed an IBE implementation that provides plugins for Microsoft Office, Hotmail, and Yahoo. [6, 7, 9, 58 - 60]

2.7 PROS AND CONSThe major issues with IBE are the key escrow and key revocation problems. The key escrow problem states that, because the Key Generating Server has access to all private keys in the system, it’s possible for them to decrypt any ciphertext in the system and forge any entity’s signatures. There have been several proposed solutions to this problem. One solution involves using multiple KGSs, where each KGS only has one piece of the key information and this needs to be combined with pieces from other KGSs to get a complete key. Another solution involves trusted third-party mediators that help a user decrypt messages. The key revocation problem deals with how to efficiently revoke users from the system as well as how to prevent revoked users from colluding with valid users to read encrypted messages. A technique that could solve both key escrow and revocation problems is using a threshold (e.g. timeout) technique, where keys expire after a given length of time and so users are forced to periodically renew their keys. One major drawback to either solution is that they involve additional infrastructure which makes the systems more complex and therefore you lose some of the advantages you have over a PKI scheme. Another drawback of Elliptic Curve Cryptography is that it can be significantly slower than the modular exponentiation used by RSA. It has been shown to be 10x slower at moderate security levels and up to nearly 20 times slower at high security levels. The inefficiency is due to the fact that the pairing computations involved are roughly 20 times slower. [16 – 18, 21, 26 – 30, 59]

The major advantage of Identity-Based Encryption over other encryption schemes is that it is certificate-less. It doesn’t require a complex key management infrastructure like Public Key Encryption (PKE) does, eliminating the storage and computing overhead of storing, verifying, and revoking certificates. Users in an IBE system do not need to pre-share secrets. This lends itself well to mobile and distributed systems where devices need to be able to find, authenticate, and transact with each other without a central authority. Significantly smaller cryptographic parameters, including small public and private keys, can be used in ECC than in other competitive public-key cryptographic systems such as the popular RSA cryptosystem but with equivalent levels of security. When using schemes with a small number of pairing calculations (some of which can be eliminated during repeated operations with the same user), the system can be computationally less intensive (light-weight). These restrictions are critical to preserve power in small, resource-constrained devices as the power to transmit one bit in a typical wireless sensor is equivalent to approx. 2,090 clock cycles of execution on a microcontroller. IBE is becoming more well supported as it becomes standardized, notably the IEEE 1363.3 standard for Identity Based Encryption and IETF draft standards RFC 5091, and RFC 5408. [3, 18, 19, 22, 25, 29, 30, 59]

2.8 WHY WAS IBE CHOSEN?I chose to use Identity-Based Encryption in my secure mobile messaging application for many reasons. First and foremost, I don’t know of any other instant messaging scheme that uses IBE so it would give me a chance to develop a proof-of-concept. Also, there has not been much work on Elliptic Curve Cryptography on mobile devices so I was interested to see how well ECC would perform on modern mobile phones. There are also many technical considerations that made IBE an attractive choice for my system. Because encryption is based on users’ identities there is no need to set up and manage a

19

certificate management infrastructure. The low implementation overhead allows for a system that can be modular and extensible. This makes it easy to add IBE as a security layer on top of an existing system. Certain schemes offer short ciphertexts and public parameters which is ideal for messaging systems and for mobile devices, where conserving system resources is paramount. IBE systems can also provide deniability so that the owner of the system cannot be compelled by law enforcement to give up information about the users of the system. IBE also provides leakage-resiliency which protects the system against timing attacks, power dissipation, and cold-boot attacks that can extract information from the system including secret keys and the state of the encrypting system.

2.9 WHY WAS JPBC CHOSEN?The Java Pairing-Based Cryptography (JPBC) library was chosen as the IBE library because it is a Java implementation of the popular and reputable Stanford PBC library.

2.10 WHY WAS ANDROID CHOSEN?Android ranked the top mobile platform on the market in 2014 making up 76.6% of smartphones sold globally and has become the #1 target for malicious hackers. Many of the mobile threats identified on the Android platform are common to all mobile platforms.

I chose to develop my messaging application for the Android operating system because it is free, open-source, and I had ready access to Android devices for development and testing. Because the Android API is Java-based, the learning curve will be smaller and I would be able to get a system up and running more quickly. There are also many quality development tools and frameworks available.

20

CHAPTER 3 – RELATED WORK

In addition to the notable implementations mentioned in Chapter 2, here is some other work being done related to secure messaging.

3.1 OFF-THE-RECORD (OTR) MESSAGINGOff-The-Record (OTR) is a secure messaging protocol that provides encryption, authentication, deniability, and perfect forward secrecy. The OTR scheme, which is better suited for “casual” conversation, was developed to be a replacement for Pretty Good Privacy (PGP) in instant messaging applications. The creators of Off-The-Record chose to implement their messaging protocol on top of existing protocols to avoid re-inventing proven instant messaging protocols. In this scheme, the message is encrypted and authenticated with OTR, then sent across the wire using typical IM protocols (AIM, jabber, XMPP, ICQ, etc.). OTR version 3 is the most recent version of the OTR protocol. In this version, the designers added many improvements to make it easier for the general public to use so that it would be more widely adopted. They utilize the Libgcrypt library for cryptographic functions, using AES for encryption, RSA for digital signatures, and SHA1-HMAC for message authentication. It also uses the Linux util /dev/random to generate random keys.

Forward secrecy is a concept used to ensure that if a key is compromised, no captured messages can be decrypted because of the use of unique session keys. To realize forward secrecy they utilize the Diffie-Hellman key exchange protocol. The shared secret generated from DH is used to create a short-lived encryption key (re-keying at least once a minute on slow devices, or with every message exchange on faster machines). The session keys are generated using 128-bit SHA-1 (now deprecated). On each message exchange the message is encrypted using the shared secret derived from the last key received from the other party and the last key that has been sent to the other party. To achieve perfect forward secrecy, the users must forget previously used keys once a new key exchange has been completed.

Digital signatures are used to prove the authenticity of messages. The signatures are used only to sign the public keys in DH key exchange. No message is digitally signed as this would create non-reputability. Message authentication codes (MACs) are used to prevent message spoofing.

In addition to reputability, they also want forgeability, or the capability to show that anybody could have modified the message. To achieve this, they use what they call “malleable encryption,” which essentially means that the ciphertext should be modifiable without producing garbage output when decrypted. The encryption scheme they chose to achieve this is AES in counter mode (a stream cipher). How it works: Whenever you are about to forget either one of your old DH key pairs, or one of your correspondent’s old DH public keys, take all of the receiving MAC keys that were generated by that key (there are up to two: the receiving MAC keys produced by the pairings of that key with each of two of the other side’s keys; but note that you only need to take MAC keys that were actually used to verify a MAC on a message), and put them into the “Old MAC keys to be revealed” section of the next Data Message you send.

While Off-The-Record is a very secure messaging protocol, it has some drawbacks when it comes to user-friendliness. Because implementations of OTR allow for both secure and insecure communications, it relies on status icons on the user interface to display the security state of the communication session.

21

These icons can be confusing to users who aren't completely familiar with the system. This confusion can lead to user frustration as well as leaving the users vulnerable to communicating over an insecure channel that they believe to be secure. Because there is no central authority in OTR, users are responsible for authenticating each other. This authentication can happen ‘out-of-band’ by verifying each other’s fingerprint (the hash of a user’s public key) in person, over the phone, etc., or by using the secret-sharing popup window. In this window, the instigating user enters a question or phrase that they are sure only the other party would know the response to. If the recipient enters the correct response, the users are authenticated and secure messaging is initiated. In practice, new users tend to have issues figuring out how to use this secret sharing window. A big limitation of this form of authentication is that it doesn’t allow for the authentication of users who have not had any prior contact. [12, 32, 33]

3.2 SECURE INSTANT MESSAGING AND PRESENCE PROTOCOL (SIMPP)The Secure Instant Messaging and Presence Protocol (SIMPP) is an XMPP-compliant protocol created in 2007 by Yang, Kuo, Ahn, and Lee and based on the open-source jabberd project. It is an implementation of RFC 2778, drafted in 2000, which defines standard for presence and instant messaging services. SIMPP is adapted from the Instant Messaging Key Exchange (IMKE) protocol created by Mannan and van Oorschot to ensure the confidentiality, integrity and authentication of client-server and client-client communications. SIMPP improves upon RSA-based IMKE by using Elliptic Curve Cryptography to speed up public-key cryptographic functions. Their main objective was to increase the security of instant messaging systems by making them more practical and more readily adoptable. They aim to do this by reducing the computational overhead imposed on these systems due to the security mechanisms.

SIMPP is configured with two system parameters: elliptic curve E : y2 = x3 + ax + b and base point G = (xG, yG) of prime order n > 2160. Using these parameters, the server generates for itself a public/private key pair and shares its public key with all users in the system. This key is used by the clients to generate their master keys. Their system has three phases: registration, client-server communication, and client-client communication. In the registration phase, the client submits their ID and public key to the server (R1). The server responds with these credentials, along with a random string, encrypted with the master key (R2). The user responds with the random string signed with their private key, and, if valid, is then registered on the server (R3).

FIGURE 5 - SIMPP PHASE 1: REGISTRATION

22

The client-server communication phase is the phase where the client authenticates with the server to login to the system. The client authenticates himself by generating a symmetric session key it wishes to use for communication, encrypted with the master key, and sending it to the sever (S1). The server responds with the client’s ID and proposed symmetric key, along with a random string, encrypted with the master key (S2). The client responds with a hash of the random string, encrypted with the symmetric session key, and if the hashed value matches the hashed value computed by the server, the client is allowed to login (S3).

FIGURE 6 - SIMPP PHASE 2: CLIENT-SERVER COMMUNICATIONS

Once two clients are authenticated and logged into the system, they must retrieve each other’s public key from the server (C1, C2). With these keys, they perform the Elliptic Curve Signature Algorithm (ECDSA) to authenticate each other (C3, C4). Once the clients have authenticated, they generate a shared session key by means of Elliptic Curve Diffie-Hellman (ECDH) key exchange (C5) which is then used to secure their communications (C6, C7).

23

FIGURE 7 - SIMPP PHASE 3: CLIENT-CLIENT COMMUNICATION

FIGURE 8 - SIMPP PROTOCOL: KEY TERMS

The creators of SIMPP chose to use the MIRACL cryptographic SDK as their library of cryptographic functions. From this library they use 128-bit AES for symmetric encryption, and ECC over a prime field of 224 and 160 bits on the server and clients respectively for asymmetric encryption.

The main drawback of this system is that it relies on a Public-Key Infrastructure (PKI) to distribute keys each time a new pair of clients wish to communicate. This adds unwanted overhead and complexity to the system. [3]

24

3.3 SELF-PROTECTING EMRS Akinyele et al designed and implemented what they call self-protecting electronic medical records (EMRs). Specifically, they look at XML-based standard EMRs including Continuity of Care Records (CCRs) and Continuity of Care Documents (CCDs). Their implementation provides fine-grained encryption, the ability to protect individual items within an EMR by encrypting it and giving it its own access control policy, and allows them to remain secure in an offline environment. These features are enabled by the use of Attribute-Based Encryption (ABE). Leveraging a 224-bit MNT elliptic curve from the Stanford Pairing-Based Cryptography (PBC) library, they build a mechanism to automate the process of creating access control policies. These policies come in two forms; Key-Policy ABE: each record is tagged with relevant attributes and each key has a policy formula embedded determining which of these attributes the user has access to, and Ciphertext-Policy ABE: the ciphertext contains the policy describing who is entitled to access it. ABE has expressive policy access formulae: policies can be expressed with AND, OR, 1-of-n, m-of-n, > >=, <, <=.

FIGURE 9 - IHEALTHEMR POLICY ENGINE FLOW

Their scheme is meant to be practical and usable on modern (2011) smart phones. Their smartphone app is meant to allow patients to take their medical records with them while remaining secure on their device. To achieve this security, the patient first needs to bring their phone into the hospital (or other trusted entity) and hook it up to their private-key generator (PKG) to assign them their keys. They get their ABE key pair, as well as a pair of RSA keys which they can use to securely connect to the hospital to update their keys when they are about to expire.

25

FIGURE 10 - IHEALTHEMR ARCHITECTURE OVERVIEW

For efficiency reasons they do not use ABE to directly encrypt record data. Instead, they use a standard hybrid approach wherein each record is encrypted using a 128-bit AES session key, and the session key is protected using ABE encryption. On the mobile app, decryption is done lazily, as in, on demand by the user so as to not use any unnecessary resources on the device. They take care not to store any unencrypted data on the mobile device.

Testing was performed on an iPhone 4 running iOS4, an Apple A4 processor, and 512MB of memory. They tested their scheme using both CP-ABE and KP-ABE, testing CP-ABE with up to 100 leaves in the policy, and KP-ABE with up to 100 key attributes. Their results showed that encryption and decryption time was directly related to the number of attributes in the access policy.

FIGURE 11 - CP-ABE AND KP-ABE MOBILE PERFORMANCE

The chart on the left in Figure 11 above shows the performance of both the “normal” and “lite” variants of their scheme. The “lite” version realizes significant performance gains, and is recommended for mobile devices, because it uses a constant number of pairing operations.

26

Using an out-of-band key exchange process gives the system additional security, but also makes the system less practical outside of a scheme where the user needs to physically interact with a central authority. Their implementation of a secure EMR system is elegant and well executed, and, while their system has acceptable performance on a fourth generation iPhone, it would likely realize improvements in user experience on a modern mobile device. [7]

3.4 JXTA-OVERLAY JXTA-Overlay is an implementation of a security layer on top of the Java P2P framework JXTA (a.k.a. juxtapose) by Arnedo-Moreno et al. The JXTA specification provides a set of open protocols that enable the creation and deployment of P2P networks, enabling P2P applications to discover and observe peers, communicate and offer and access resources within the network. JXTA-Overlay is based on JXTA and enables the creation of Java-based end-user applications. The goal of their security layer is to provide security while being transparent to the underlying framework. They also wanted it to be extensible and easily adapted to different crypto modules. With their system, this can be achieved mostly by extension and with little modification to the original code base.

The major security entities involved in the JXTA-Overlay framework are the SecurityManager and the CryptoManager. Because they designed the CryptoManager in a modular fashion, it essentially acts as a proxy for any cryptographic module you wish to plug in, potentially even one based on Elliptic Curve Cryptography. In their implementation, security is provided by TLS utilizing X.509 certificates, JCE keystores, and 128-160 bit session identifiers (SIDs), in addition to a challenge-response protocol.

FIGURE 12 - JXTA-OVERLAY LOGIN SEQUENCE

The roles in the JXTA network are end-users, clients, peers, brokers, a central database, and administrators. The framework is divided into 3 layers: the client layer, broker layer, and control layer, much like a traditional MVC framework. Client peers are protected against impersonation by extending the Discover primitives and functions with broker authentication. A secure login primitive is provided to protect username and password from eavesdroppers. They also implement a basic method for key distribution between group members, once they have been granted access to the JXTA-Overlay network by the broker.

27

In JXTA-Overlay, key distribution is invisible to the end-users and they need not concern themselves about how the key distribution mechanism works. This makes the system more user-friendly and therefore its use and implementation less error-prone. The proposed framework is completely modular and can be adapted to different scenarios, including different types of credentials or cryptographic modules. Performance of the system is likely highly dependent upon the type of cryptographic functions used in the CryptoManager module. The only real issue is that it relies on certificates and a certificate authority to manage those certificates. [14]

3.5 TEXTSECURE (AXOLOTL) TextSecure is a secure messaging app for Android developed by Whisper Systems, whose goal is to create “simple and easy-to-use tools for secure mobile communication and secure mobile storage.” In addition to a private text and chat app, they also feature an app that allows private calling. Whisper Systems was acquired by Twitter in late 2011, who very generously made some of the Whisper Systems software available under an open-source license (GPLv3). This new project is known as “Open Whisper Systems” and has been under active development by the open-source community. TextSecure has received praise by whistleblower Edward Snowden.

TextSecure’s protocol consists of several phases: registration, sending/receiving a first message, sending a follow-up message, and sending a reply. When a new session is created to exchange messages, three main cryptographic building blocks are applied: a key/secret exchange protocol, a key update and management protocol (the so-called axolotl ratchet), which updates the encryption and MAC keys for every outgoing message, and a stateful authenticated encryption scheme. Key exchange is essentially a triple Diffie-Hellman (DH) key exchange using long-term and ephemeral secret keys. This is the only step in the protocol flow that uses the long-term keys. 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 is corrupted) and future secrecy (in which a leak of keys to an eavesdropper will be “healed” by the introduction of new DH ratchet keys). Messages are encrypted using AES in counter mode and sent over JSON/REST.

For push messaging, TextSecure relies on a central server to relay messages to the intended recipient. Parties communicate with the central server via REST using HTTPS. The central authority’s certificate is self-signed, and the certificate of the signing CA is hard-coded in the TextSecure app. Actual message delivery is performed via Google Cloud Messaging (GCM), which basically acts as a router for messages.

Version 2 of the TextSecure messaging protocol uses the no header keys variation of the axolotl ratchet and protobuf records. The protocol can detect replay, reorder, and deletion of messages. It allows the decryption of out-of-order messages with minimal reduction in forward secrecy. It also does not leak metadata, such as identities or sequence numbers, in cleartext. The scheme guarantees deniability as well as the confidentiality and authenticity of the exchanged messages. Every new message is encrypted using a new key and all messages are encrypted locally as well as in transit.

In addition to its reliance on a central authority, one issue with TextSecure is that it only partially utilizes its MAC image space. TextSecure uses HMAC-SHA-256 to calculate MACs but does not transmit the complete output, only the first 64 of the 256 bit MAC. NIST recommends a MAC length of 80 bits when used for key confirmation. TextSecure is also vulnerable to an attack known as an Unknown Key-Share

28

Attack (UKS). First described by Diffie et al, if such an attack is mounted against Pa, then Pa shares a key with Pb, however, Pb believes they share a key with Pe != Pa.

FIGURE 13 - UKS ATTACK ON TEXTSECURE

Frosch et al provide a solution to the UKS attack in their paper ‘How Secure is TextSecure?’

Another issue with TextSecure is that it requires two parties to initially authenticate by comparing fingerprints using an out-of-band channel, for example, a phone call or an in-person meeting. Even though they do make the manual process fairly easy by allowing the two parties to scan Quick Response (QR) codes on each other’s phones, it is still inconvenient and in some cases impossible for the communicating parties to meet in person. [34, 42, 57, 64]

3.6 CRYPTO-BOOK Modern social networking sites utilize cross-site authentication protocols such as OAuth and OpenID. One of the down-sides of these protocols is that a user’s online activity can be easily tracked, presenting a risk to online privacy. To address this issue, John Maheswaran, David Isaac Wolinsky, and Bryan Ford created Crypto-Book in 2013. The concept of the project is to build a privacy-preserving cryptographic layer atop existing social network identities. It does this via third-party key servers that convert social network identities into public/private key pairs on demand. This results in unique pseudonyms that are untraceable back to the owner yet can resist anonymous abuse.

Crypto-Book utilizes key servers (which could be run by the social networking sites or independently) that exist in a cloud they call “anytrust”. Users obtain their private key by authenticating with each of the key servers via OAuth (over an SSL connection). Each key server generates only one part of the user’s private key; the user’s client machine (or potentially some trusted proxy) combines these key parts into the complete private key. To support this, the creators chose the DSA key format because DSA keys support easy key splitting and combining. DSA keys operate in a group G of order p and are of the form Y = gx mod p, where Y is the public key and x is the private key. The keys are further divided into epochs, where the key server’s master secret is valid only during a given epoch, and gets randomly reinitialized in each successive epoch. The scheme remains secure as long as at least one of these servers remains honest.

29

FIGURE 14 - CRYPTO-BOOK'S ANYTRUST ARCHITECTURE

Crypto-Book employs RSA-based ring signatures to authenticate anonymously to third-party websites and services without revealing Personally-Identifiable Information (PII) so that users cannot be tracked. A ring signature proves that one of the “ring members” signed a message but does not reveal which one. To protect clients from being tracked by malicious servers, clients are assumed to be connecting to the key servers over an anonymity network such as Tor.

FIGURE 15 – CRYPTO-BOOK ANONYMOUS KEY RETRIEVAL

As a proof-of-concept, they built an implementation of their scheme which they dubbed Black Box. Black Box allows users to sign files deniably using ring signatures. A possible threat to the Crypto-Book scheme involves third party sites colluding in an attempt to de-anonymize and uniquely identify users using some form of cross-site correlation attack. Overall, Crypto-Book is a very intriguing project, with excellent data security options from a choice of cryptographic implementation (RSA, DSA, or even IBE), and users’ privacy is well protected with the combination of ring signatures and an anonymity network. [39]

30

3.7 SUMMARYThere is a lot of very exciting work going on in the world of security and privacy software. In this chapter I reviewed a very small and eclectic subset of projects from that world. I have compiled a table to quickly summarize the technical and practical aspects of each approach.

Open-Source

Central Authority

Crypto Library

Key-Exchange Protocol

Encryption/Decryption Algorithm

User Friendly

Off-The-Record (OTR) Yes No OTR Diffie-Hellman AES No

SIMPP Yes Yes MIRACLElliptic Curve

Diffie-Hellman AES and ECC NoSelf-Protecting EMRs No N/A PBC Out-of-band ECC Yes

JXTA-Overlay Yes Yes Configurable Custom Configurable N/A

TextSecure (Axolotl) Yes YesAndroid

Native Library Diffie-Hellman AES Yes

Crypto-Book Yes Configurable Configurable Custom DSA, RSA, ECC NoTABLE 2 - COMPARISON OF RELATED PROJECTS

I was very excited to see that, more often than not, projects are open-source. This is good news, not only because public scrutiny is security’s best friend, but it will also help foster interest and adoption of secure software applications. The projects also leveraged a wide variety of cryptographic libraries. I made a judgement call about the user-friendliness of each approach as it related to its particular task. In general I consider an approach user-friendly if it is accessible to someone with little or no knowledge about security and privacy mechanisms. To that end, I take into consideration the look-and-feel of the application (if relevant) and whether or not the user is involved in making any security decisions.

31

CHAPTER 4 – PROJECT DESIGN AND IMPLEMENTATION

4.1 PROJECT OVERVIEWThe goal of this project is to develop a mobile messaging app that is exceptionally secure yet simple and intuitive to use. Messages will be protected when sent over the wire as well as at rest, and will not be persisted on users’ devices or on the servers. To be user-friendly, the security mechanism is designed to be transparent and seamless. I leveraged the Android Bootstrap framework to develop a secure messaging app for the Android operating system that uses Identity-Based Encryption based on elliptic curves from the Stanford PBC library. The system will provide encryption to protect the user’s data, authentication so that users can be sure of other users’ identities, deniability so that anything a user does cannot be held against them, and forward secrecy so that if a user loses control of their private keys, no previous conversation is compromised. The application is intended to be useful to anyone who would like to share their personal, financial, business, and health information with the assurance that it is secure. [71]

4.2 PROJECT ARCHITECTUREI chose to leverage cloud services to implement the messaging system. Cloud services provide fast provisioning, reliability, low maintenance, and low costs. I use Amazon Web Services to host my project infrastructure. In particular, I leverage the Amazon Elastic Compute Cloud (EC2) and Route 53 services. Amazon EC2 runs virtual server instances. One basic server instance can be used for free and other instances can be used and paid for by the hour of runtime. Route 53 provides scalable and highly available Domain Name System (DNS) services. The name (Route 53) is a reference to TCP or UDP port 53, where DNS server requests are addressed. [72]

The implementation consists of two servers and, for development and testing, two Android smartphones. One server acts as the IBE Key Generation Server (KGS) and user authentication server. The other server provides the XMPP messaging service. The smartphones run the secure messaging client application.

On the KGS server I am running the Ubuntu Linux Server operating system (Ubuntu Server 14.04.01), the Apache Tomcat Application Server (Tomcat 7), the Apache Web Server (Apache 2.4.7) and the MySQL database server from the LAMP software package, which stands for Linux-Apache-MySQL-PHP. The Apache Web Server is configured for HTTPS so that all authentication requests to the server are protected. On the XMPP Server instance I am running Ubuntu Linux Server 14.04.01 and the Prosody XMPP Server. This server also hosts the project website sageburner.com. [73 - 78]

The mobile devices used in the system were the Samsung Galaxy Nexus and Samsung Galaxy Note 3 smartphones. The Galaxy Nexus smartphone (2011) runs on Android 4.3 and has a dual-core 1.2 GHz Cortex-A9 processor with 1 GB of RAM. The Galaxy Note 3 (2013) runs the Android 4.4 operating system and has a quad-core 2.3 GHz Krait 400 processor and has 3 GB of RAM.

32

FIGURE 16 - HIGH LEVEL PROJECT ARCHITECTURE

33

4.3 DESIGNA major design goal of the system is to make it easy to take the modules developed and implement a new system with them or add them as a security layer to an existing system. Two modules were developed for this system, a mobile client module and a server module. The server module provides authentication and Key Generation services. This module can be adapted to a variety of different authentication mechanisms. Alternatively, the KGS portion can be broken off and added to an existing authentication module. Likewise, the client module can be modified to utilize different messaging protocols, and the IBE module can be taken by itself and added to an existing messaging system.

Another important design choice was to isolate the user from any security decisions. Aside from entering their username and password, users should not be aware of how the security mechanism functions or that it even exists. This is where Identity-Based Encryption comes in. Because public keys are based on users’ identities, there is no need for a complex key exchange mechanism either within the application or out-of-band.

FIGURE 17 - PROJECT ARCHITECTURE

34

35

There are four main steps performed by the client devices in order to send and receive encrypted messages. These are authentication, IBE retrieval, message encryption/decryption, and sending/receiving messages. The authentication and IBE retrieval tasks are performed in conjunction with the KGS server via web service requests login and getIBEParams. The login request takes the user’s username and a hash of their password as parameters.

FIGURE 18 - REST REQUEST: LOGIN

The getIBEParams request accepts a single parameter called a key. This key is either the key of the IBEParams object stored on the server, or ‘0’ if the client is requesting a new IBEParams instance.

FIGURE 19 - REST REQUEST - GETIBEPARAMS

A user authenticates to the system by submitting their username and password to the KGS server over a secure HTTPS session. HTTPS is a requirement on authentication as users’ passwords are sent in plaintext.

FIGURE 20 - USER AUTHENTICATION

Upon successful authentication, an XMPP connection is created and the user is connected to the instant messaging service. The user is authenticated to the XMPP server with stored credentials and gets the user roster (or ‘friends list’) showing the user’s list of friends and their online status. The user then selects a user with whom they wish to start a conversation with. When the conversation is started, the first thing that happens is a request is made to the Key Generation Server for a new IBEParams instance.

36

FIGURE 21 - IBEPARAMS RETRIEVAL (NEW IBE)

This IBEParams object contains all of the IBE public parameters. Once the IBEParams object is created on the server, it is saved to the IBEParams map and the public parameters are returned in JSON format. With these parameters, the client initializes its own IBE instance. With this IBE object, the user can now encrypt and decrypt messages.

FIGURE 22 – JPBC IBEPARAMS JSON MESSAGE

Messages are Base64 encoded and sent over an insecure (unencrypted) channel. I chose to implement a scheme where the secure encrypted messages are sent over insecure (non-SSL) channels because this avoids the setup and maintenance of a complex SSL system with no justifiable gain in security by using HTTPS.

When sending a message it is immediately encrypted and sent to the recipient. A copy of the encrypted message is stored in the Conversation Message List on the client so that it can be displayed on the UI. Because the message is stored in encrypted form, it is protected from any leak of information on the

37

users’ devices. The message is therefore secured both in transit and at rest. A major drawback to this scheme is that messages must be decrypted every time they are displayed on the conversation view. Though this is a very secure process, it is inefficient and has observable performance implications.

Upon receipt of the message, the receiving user must request the corresponding IBE parameters for the session from the KGS. The recipient then initializes their own IBE instance with these parameters and is then able to decrypt the message.

FIGURE 23 - IBEPARAMS RETRIEVAL (EXISTING IBE)

The novel part about this IBE scheme is that in this implementation, different IBE objects are transferred between distinct pairs of users, and different IBE instances are used in each session. A new session is created on connections made with new pairs of users, and also new connections made with previous users. This avoids the key escrow problem of IBE because once the IBE is initialized and handed off, the KGS isn’t aware of any of the keys used in the system. A compromised KGS could be configured to make copies of each IBEParams object, but these objects would only be useful if the attacker was also somehow able to get the encrypted messages off of one of the users’ devices. The attacker would have limited time to do this as the messages are destroyed when the users end the communication session. On a trusted KGS, IBEParams are only exposed to attack as long as it takes for the initial message recipient to retrieve these parameters from the server. In normal use, this would typically be a short amount of time. The attacker would also have to find the IBEParams corresponding to the specific conversation they are looking to disclose. They could do this by parsing the very first message sent in the conversation as this message contains the key to the IBEParams object in the map stored on the server, however, this key is not transmitted again after the initial message.

38

The diagram below shows the complete messaging flow of the application.

FIGURE 24 - MESSAGING FLOW DIAGRAM

39

4.4 IMPLEMENTATION DETAILSThere are two main components in the implementation of the system; a server application module called the sageburner_im_server and a client application called sageburner_im. The sageburner_im_server module runs on the Key Generation Server. This application is written in Java and is built on top of the Spring application framework running on Apache Tomcat 7 web application server. Its purpose is to provide authentication and IBE KeyGen services to the sageburner_im client application via RESTful web services. It utilizes the JPBC and BouncyCastle libraries for encryption. This module performs the Setup and KeyGen steps from the IBE protocol. [79]

The sageburner_im module runs on the users’ mobile devices. This module is also written in Java and built on the Android Bootstrap application framework. This framework was chosen because it is well supported by the Android development community and it is developed using industry standard practices and proven design patterns. Along with user-interface templates, the framework comes with authentication and REST service components out-of-the-box. This module provides the secure messaging client for the mobile devices. It was compiled for Android API 19 (Android 4.4 KitKat) and utilizes the JPBC and BouncyCastle libraries for encryption as well as the ‘asmack’ XMPP client library for instant messaging and presence services. This module performs the Encypt and Decrypt steps from the IBE protocol.

In the Key Generation Server module, authentication is handled by the LoginController. The controller calls the LoginService, which fetches the user and validates the users’ passwords. To get the user information, it relies on the UserDao class to retrieve the user information from the database. The users’ passwords are validated with the help of the CryptoService, which compares the hash of the received password to the hashed password stored in the database.

FIGURE 25 - AUTHENTICATION SEQUENCE DIAGRAM

40

The UserDao class leverages the only database table in the system which is used as the user directory for authentication. This table, named user, stores information about each user that is registered with the system. It stores the users’ personal information as well as their system credentials and XMPP connection information. The XMPP credentials are used to connect to the XMPP services once the user has successfully authenticated.

FIGURE 26 - SAGEBURNER_AUTH DATABASE SCHEMA

FIGURE 27 - USER TABLE DESCRIPTION

The heart of the authentication mechanism is the CryptoUtils class. This class relies on the PasswordHash utility class to generate and compare the hashes of users’ passwords.

FIGURE 28 - AUTHENTICATION CLASS DIAGRAM

41

IBE Retrieval requests (requests to the getIBEParams service) are processed by the IBEController. The IBEController in turn leverages the IBEParamsService to create the IBEParamsWrapper object that gets sent back to the user. This IBEParamsWrapper is simply a wrapper around the IBEParams class (seen in JSON format in Figure 22) giving it a unique key with which it can be accessed at a later time. These IBEParams are generated by the initialization of a new IBE instance.

FIGURE 29 - IBE RETRIEVAL CLASS DIAGRAM

As stated before, Identity-Based Encryption using Elliptic Curve Cryptography was chosen as the cryptographic scheme in this system. ECC with ‘Type a’ pairing was chosen because it is considered one of the most efficient pairing algorithms available in the JPBC library. ‘Type a’ pairings are constructed on the curve y2 = x3 + x over the finite field 𝔽q for some prime q = 3 mod 4. The pairing is initialized with public parameters r = 160, q = 512, and k = 2. Here is a definition of these parameters:

𝐸: elliptic curve over finite field over prime 𝔽q q: field size of base-point 𝑃 ∈ 𝐸(𝔽q) r: prime order of base-point 𝑃 ∈ 𝐸(𝔽q) – r does not divide q k: embedding degree (multiplicative order of q mod r)

Security Level (in bits) 80 112 128r 160 224 256q 512 1024 1536

RSA Key Size 1024 2048 3072TABLE 3 - ELLIPTIC CURVE SECURITY LEVELS

42

Encryption is performed on the client module when sending messages and involves two steps. First, the message is encrypted using the Advanced Encryption Standard (AES) symmetric encryption protocol. Then, the AES key is encrypted using IBE encryption. The encrypted message and encrypted AES key are concatenated and sent to the recipient. The diagram below shows, in great detail, the inner workings of this process.

FIGURE 30 - MESSAGE ENCRYPTION

In instant messaging, the messages that are sent back and forth are typically very short and so there is no real gain from this dual encryption process. However, if file sharing were to be implemented in this system, this dual encryption scheme would greatly improve performance. This is because the large file would be symmetrically encrypted, which would be fast, and the symmetric key generated would then be encrypted using IBE, which would also be fast because the key size is relatively small.

43

Decryption is performed in the reverse order of encryption. The receiving user parses the concatenated message and uses IBE to decrypt the AES key. With this now decrypted symmtric key the user is able to decrypt and read the message.

FIGURE 31 - MESSAGE DECRYPTION

44

Below is the class diagram showing all of the components involved in the secure transmission and retrieval of messages. This diagram exemplifies the modular design of the system with IBE at its core. As you can see, several different third-party libraries were used in this implementation to provide the user interface, authentication, and communication functionality of the system. These libraries include the base Android SDK libraries, the Retrofit REST web service client APIs, and the asmack client library for communicating with the XMPP protocol.

It is worth noting that all of the encryption, both IBE and symmetric, is handled by the CryptoUtils class.

FIGURE 32 - MESSAGING CLASS DIAGRAM

45

CHAPTER 5 - USER EXPERIENCE AND APPLICATION PERFORMANCE

5.1 USER EXPERIENCEThe user interface of an application plays a large role in determining whether or not a user is going to have a good user experience. As a developer, you want to present the user with the right amount of the features and in the right way so that they are confident in what they are doing. This means using controls, layouts, and a flow that a user is comfortable and familiar with. User Experience (UX) engineers have spent countless hours perfecting this experience on mobile devices and the Android Bootstrap framework builds on this effort. It comes with a basic user interface including a login page, a few list views, a navigation drawer, and some simple but useful User Interface (UI) controls. The main application screens are configured with a ‘carousel’ or ‘view pager’ layout manager that allows the user to flip left and right through views like pages of a book. Swiping in from the far left or selecting the menu icon will open the navigation bar. There is also a context menu allowing you to add more advanced, but not often needed, features to your application.

There are three main screens in this secure messaging application. They are the login screen, the friends list, and the conversation view.

46

FIGURE 33 - LOGIN FRAGMENT VIEW FIGURE 34 - FRIENDS LIST FRAGMENT VIEW

47

FIGURE 35 - CONVERSATION FRAGMENT VIEW

On the login screen (Figure 33) the user enters their username and password and presses the ‘login’ button to authenticate with the KGS. Upon successful authentication the user is presented with the friends list (Figure 34) that shows the roster of their friends and their online statuses. A green box next to the user’s name indicates that they are online. A grey box means they are not currently connected. When a user clicks on the name of an online contact they are taken to the conversation view (Figure 35) where they can begin a secure conversation with the selected user. From there the user can swipe left or right on the screen to navigate between the friends list and the conversation view. On the conversation view, the user enters the message they wish to send in the input box on the bottom of the screen and clicks ‘send’ to send the message. Outgoing messages will display in the conversation view with the sending user’s avatar image on the right of the screen. Incoming messages will show up with the sending user’s avatar on the left.

48

FIGURE 36 - SAGEBURNER_IM APP ICON FIGURE 37 - REGISTER FRAGMENT VIEW

In Figure 36 above you see the home screen of the Galaxy Note 3 test phone with the sagebuner_im application icon. Clicking on this icon launches the application and displays the login screen ( Figure 33). For users who are not registered with the system, they can register using the user registration page (Figure 37). Here they enter their email address and the password they wish to use and click on the ‘register’ button. If their credentials are valid, the user will receive an email containing an activation link to complete the registration process.

49

FIGURE 38 - LOGOUT OPTION ON THE CONTEXT MENU FIGURE 39 - LOGOUT OPTION ON THE NAVIGATION DRAWER

The user can log out of the application by selecting the logout option from either the navigation drawer (Figure 38) or from the context menu (Figure 39).

50

The diagram below shows the complete user interface flow of the Android client application.

FIGURE 40 - CLIENT FLOW DIAGRAM

51

Figure 41 shows the major components of the application user interface. All Android applications have a MainActivity that handles the initialization of the application. In this implementation, the MainActivity is responsible for initializing all of the services used by the application including the authentication service, messaging service, and encryption service. Once initialization is complete, or as it completes in the background, the application displays the main view. In this application, that main view is the LoginView (Figure 33). The two main displays, the FriendsListFragment and ConversationFragment, are managed by the CarouselFragment which gives the user the ability to page back and forth between them by swiping back and forth on the screen.

In Android, the application logic is bound very tightly to the user interface components. The most important user interface object in this app is the ConversationView because it handles all of the messaging tasks, from security to transmission and reception. For that reason, you see that the CryptoUtils class, the class responsible for all of the cryptographic functions in the system, has a direct relationship with the ConversationFragment user interface class.

FIGURE 41 - USER INTERFACE CLASS DIAGRAM

52

5.2 APPLICATION PERFORMANCETwo different performance tests were performed on each of the mobile devices used during development (the Samsung Galaxy Nexus and Note 3). The first test performed was to test the performance of sageburner_im client module at runtime. Logging statements were added to the methods of interest which logged the time it took to perform each task. The results are shown in the chart below.

FIGURE 42 - IBE PERFORMANCE ON MODERN MOBILE PHONES

As indicated by the chart, IBE Setup takes a long time to complete; almost 2 seconds on the Nexus and 1 second on the Note 3. In practice, this does not have a noticeable impact on the performance of the application because this task is done asymmetrically, in the background, when the application is started. Not surprisingly, the biggest performance bottleneck in the application are the encryption (getEncFromID) and decryption (getDecFromID) methods.

The next test was running the Android JPBC benchmark application provided by the developers of the JPBC library. This application tested the performance of several of the functions performed on each pairing type. Below I show the results of this test for the ‘Type a’ curve. The large spikes occur when ‘exponentiation preprocessing’ is taking place, caching a large amount of exponents for use in the pairing functions.

53

FIGURE 43 - PBC TYPE A PAIRING ON MODERN MOBILE DEVICES

The test results show that encryption and decryption tasks are still probably too slow for most mobile applications where users are expecting virtually instant feedback from their apps. What’s promising, however, is that the device manufactured in 2013 performed almost twice as well as the one from 2011. If this trend continues, Identity-Based Encryption schemes based on Elliptic Curve Cryptography could become a viable security scheme for mobile applications in the very near future.

54

CHAPTER 6 – CONCLUSION

A mobile user’s privacy is under constant threat of attack from numerous sources at any given time. Protecting personal and professional information in such a hostile environment is a continuous task and one of utmost importance. Taking on such a challenge requires having the right tools and empowering users to use them. Along with projects like Off-the-Record, TextSecure, and Crypto-Book, the secure messaging application developed here is one of those tools.

The app provides security via four major cryptographic functions: encryption, authentication, deniability, and forward secrecy. Encryption is provided by implementing an IBE scheme which leverages the JPBC library. The novel part of this IBE implementation is that new IBE instances are created for each session, thereby avoiding the intrinsic key escrow problem of IBE. Authentication is provided via a REST-based authentication module running on the KGS server. Deniability comes from the fact that the messages do not have digital signatures that are checkable by a third party. Anyone can forge messages after a conversation has ended to make them look like they came from another user. However, during a conversation, users are assured the messages they read are authentic and unmodified. Forward secrecy is achieved by the use of unique session keys which are destroyed along with the conversation session. All of these functions are built using standard algorithms and parameters so that the security of the system can be easily tested and proven.

The major goal achieved by this project is the development of a mobile messaging application that uses leading edge security that is unobtrusive and empowers users by providing them with a good user experience. Developed as a proof-of-concept for Android devices, the project shows that Identity-Based Encryption can be utilized effectively in a mobile environment and that Elliptic Curve Cryptography is a viable security mechanism on any modern mobile device. Although the current system does suffer from some minor performance issues, with advances in hardware technology and improvements to pairing-based cryptographic schemes these issues will soon become negligible. Secure mobile messaging applications have potential uses in secure instant messaging as well as the sharing of sensitive professional and health information.

55

CHAPTER 7 - FUTURE WORK

The secure mobile messaging application developed here works well as a proof-of-concept but there is much work that can be done to improve upon it. The most obvious area of improvement to users of the application is the user experience. User interface activities are often slow and sometimes unreliable. Future work would include improving the UI flow, look-and-feel, responsiveness, and configuration options.

The system designed and implemented in this proof-of-concept is not a design that would scale. As is, the system has no way of managing keys between multiple Key Generation Servers, and, because the design deviates from the traditional Identity-Based Encryption architecture, we cannot take advantage of the advancements made in Hierarchical IBE (HIBE) to bring scalability to the system. Modifications would have to be made to the server module to implement a multi-KGS system.

The application and infrastructure also do not support group messaging, and, for several reasons the application does not keep track of past conversations. It is likely that some users would like to be able to communicate securely with groups of people, as well as be able to view their conversation history despite the somewhat increased security risk. With careful design these features could be added as enhancements to the client application.

Much more testing is needed to prove long term connection stability and application reliability. And, as with any security mechanism, it could benefit from more thorough security analysis. That said, there are some security issues that became clear as the prototype was being developed. To increase the security of the system, future versions could benefit from utilizing a standard authentication mechanism such as Spring Security. Also, the implementation of a periodic IBE refresh scheme, where new IBE parameters are requested within a messaging session (similar to the OTR scheme) would provide additional security and improved forward secrecy.

Because the system was designed with the goal of being modular and extensible, there are opportunities for the system to be improved and expanded upon to create new applications. For example, because the system uses a symmetric/asymmetric double encryption scheme, the system should be able to handle much larger message sizes with little decrease in performance. For this reason, I believe the system could be easily adapted to a secure file transfer scenario. These files could be anything from photos and video to business documents and medical records.

Future applications of this secure messaging scheme include the transmission of personally identifiable information (PII) such as sensitive forms needed by employers and government agencies, personal health information (PHI) such as medical history forms needed by doctors’ offices and emergency rooms, and other sensitive data.

Going forward I will continue to improve upon the secure messaging application and take the knowledge gained from developing the prototype to create new and innovative security tools.

56

REFERENCES[1] A Secure Instant Messaging System. http://students.mimuw.edu.pl/SR/prace-mgr/wrzesinska/thesis6.html

[2] Masao Tanabe and Masaki Aida. 2008. Secure communication method in mobile wireless networks. In Proceedings of the 1st international conference on MOBILe Wireless MiddleWARE, Operating Systems, and Applications (MOBILWARE '08). ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), ICST, Brussels, Belgium, Belgium, Article 17, 6 pages.

[3] Chung-Huang Yang, Tzong-Yih Kuo, TaeNam Ahn, Chia-Pei Lee. 2007. Design and Implementation of a Secure Instant Messaging Service based on Elliptic-Curve Cryptography. http://security.nknu.edu.tw/publications/200801JOC.pdf

[4] Chung-Huang Yang, Tzong-Yih Kuo. 2007. The Design and Implementation of a Secure Instant Messaging Key Exchange Protocol. http://www.kc.org.tw/fleget/FileDownLoad.aspx?CDE=149

[5] James Walkerdine, Peter Phillips, and Simon Lock. 2008. Architecting secure mobile P2P systems. In Proceedings of the 1st international workshop on Software architectures and mobility (SAM '08). ACM, New York, NY, USA, 9-14. DOI=10.1145/1370888.1370892 http://doi.acm.org/10.1145/1370888.1370892

[6] Joris Claessens, Bart Preneel, and Joos Vandewalle. 2003. (How) can mobile agents do secure electronic transactions on untrusted hosts? A survey of the security issues and the current solutions. ACM Trans. Internet Technol. 3, 1 (February 2003), 28-48. DOI=10.1145/643477.643479 http://doi.acm.org/10.1145/643477.643479

[7] Joseph A. Akinyele, Matthew W. Pagano, Matthew D. Green, Christoph U. Lehmann, Zachary N.J. Peterson, and Aviel D. Rubin. 2011. Securing electronic medical records using attribute-based encryption on mobile devices. In Proceedings of the 1st ACM workshop on Security and privacy in smartphones and mobile devices (SPSM '11). ACM, New York, NY, USA, 75-86. DOI=10.1145/2046614.2046628 http://doi.acm.org/10.1145/2046614.2046628

[8] Vigan Raça, Betim Çiço, and Majlinda Fetaji. 2012. Management, communications and security policy in mobile database systems. In Proceedings of the Fifth Balkan Conference in Informatics (BCI '12). ACM, New York, NY, USA, 118-123. DOI=10.1145/2371316.2371339 http://doi.acm.org/10.1145/2371316.2371339

[9] Sven Heiberg, Peeter Laud, Sigurðr Másson, and Claus Popp Larsen. 2011. Secure mobile access to homecare patients' data. In Proceedings of the 5th International Conference on Theory and Practice of Electronic Governance (ICEGOV '11), Elsa Estevez and Marijn Janssen (Eds.). ACM, New York, NY, USA, 363-364. DOI=10.1145/2072069.2072143 http://doi.acm.org/10.1145/2072069.2072143

[10] Android Programming: The Big Nerd Ranch Guide (Big Nerd Ranch Guides) Series: Big Nerd Ranch Guides. Paperback: 580 pages. Publisher: Big Nerd Ranch Guides; 1 edition (April 7, 2013). ISBN-10: 0321804333. ISBN-13: 978-0321804334.

[11] Abhijit Bose and Kang G. Shin. 2006. Proactive security for mobile messaging networks. In Proceedings of the 5th ACM workshop on Wireless security (WiSe '06). ACM, New York, NY, USA, 95-104. DOI=10.1145/1161289.1161307 http://doi.acm.org/10.1145/1161289.1161307

[12] Nikita Borisov, Ian Goldberg, and Eric Brewer. 2004. Off-the-record communication, or, why not to use PGP. In Proceedings of the 2004 ACM workshop on Privacy in the electronic society (WPES '04). ACM, New York, NY, USA, 77-84. DOI=10.1145/1029179.1029200 http://doi.acm.org/10.1145/1029179.1029200

[13] Benoît Libert, Jean-Jacques Quisquater, and Moti Yung. 2007. Forward-secure signatures in untrusted update environments: efficient and generic constructions. In Proceedings of the 14th ACM conference on Computer and communications security (CCS '07). ACM, New York, NY, USA, 266-275. DOI=10.1145/1315245.1315279 http://doi.acm.org/10.1145/1315245.1315279

[14] Joan Arnedo-Moreno, Keita Matsuo, Leonard Barolli, and Fatos Xhafa. 2009. Securing a Java P2P framework: the JXTA-overlay case. In Proceedings of the 11th International Conference on Information Integration and Web-based

57

Applications & Services (iiWAS '09). ACM, New York, NY, USA, 160-167. DOI=10.1145/1806338.1806373 http://doi.acm.org/10.1145/1806338.1806373

[15] Minzhe Guo, Prabir Bhattacharya, Ming Yang, Kai Qian, and Li Yang. 2013. Learning mobile security with android security labware. In Proceeding of the 44th ACM technical symposium on Computer science education (SIGCSE '13). ACM, New York, NY, USA, 675-680. DOI=10.1145/2445196.2445394 http://doi.acm.org/10.1145/2445196.2445394

[16] Xinlei Wang, Jianqing Zhang, Eve Schooler and Mihaela Ion, “Performance Evaluation of Attribute-Based Encryption: Toward Data Privacy in the IoT,” IEEE International Conference on Communications (ICC), 2014. http://csiflabs.cs.ucdavis.edu/~xlwang/public/icc_2014_wang.pdf

[17] S. Roy, M. Chuah, "Secure Data Retrieval Based on Ciphertext Policy Attribute-Based Encryption (CP-ABE) System for the DTNs", Lehigh CSE Technical Report, May, 2009 http://www.cse.lehigh.edu/~chuah/publications/cpabe-report09.pdf

[18] International Journal of Network Security Volume: 15, No: 4 (July 1, 2013) A Survey on Attribute-based Encryption Schemes of Access Control in Cloud Environments Cheng-Chi Lee, Pei-Shan Chung, and Min-Shiang Hwang, Vol. 15, No. 4, 2013, pp. 231-240 http://ijns.femto.com.tw/contents/ijns-v15-n4/ijns-2013-v15-n4-p231-240.pdf

[19] Fourth IACR Theory of Cryptography Conference TCC 2007 February 21-24 2007, KNAW Trippenhuis Amsterdam, The Netherlands. Multi-Authority Attribute-Based Encryption. Melissa Chase http://cs.brown.edu/~mchase/papers/multiabe.pdf

[20] The Java Pairing-Based Cryptography Library (JPBC) @inproceedings{ISCC:DecIov11,author = {Angelo {De Caro} and Vincenzo Iovino},title = {jPBC: Java pairing based cryptography},year = {2011},pages = {850-855},booktitle = {Proceedings of the 16th IEEE Symposium on Computers and Communications, ISCC 2011},address = {Kerkyra, Corfu, Greece, June 28 - July 1}publisher = {IEEE},url = {\url{http://gas.dia.unisa.it/projects/jpbc/}},}

[21] Brent Waters. 2009. Dual System Encryption: Realizing Fully Secure IBE and HIBE under Simple Assumptions. In Proceedings of the 29th Annual International Cryptology Conference on Advances in Cryptology (CRYPTO '09), Shai Halevi (Ed.). Springer-Verlag, Berlin, Heidelberg, 619-636. DOI=10.1007/978-3-642-03356-8_36 http://dx.doi.org/10.1007/978-3-642-03356-8_36

[22] Joonsang Baek and Jianying Zhou. 2011. Compact identity-based encryption without strong symmetric cipher. In Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security (ASIACCS '11). ACM, New York, NY, USA, 61-70. DOI=10.1145/1966913.1966923 http://doi.acm.org/10.1145/1966913.1966923

[23] Song Luo, Jianbin Hu, and Zhong Chen. 2010. New construction of identity-based proxy re-encryption. In Proceedings of the tenth annual ACM workshop on Digital rights management (DRM '10). ACM, New York, NY, USA, 47-50. DOI=10.1145/1866870.1866880 http://doi.acm.org/10.1145/1866870.1866880

[24] Sherman S.M. Chow, Yevgeniy Dodis, Yannis Rouselakis, and Brent Waters. 2010. Practical leakage-resilient identity-based encryption from simple assumptions. In Proceedings of the 17th ACM conference on Computer and communications security (CCS '10). ACM, New York, NY, USA, 152-161. DOI=10.1145/1866307.1866325 http://doi.acm.org/10.1145/1866307.1866325

[25] B. S. Adiga, P. Balamuralidhar, M. A. Rajan, Ravishankara Shastry, and V. L. Shivraj. 2012. An identity based encryption using elliptic curve cryptography for secure M2M communication. In Proceedings of the First International Conference on Security of Internet of Things (SecurIT '12). ACM, New York, NY, USA, 68-74. DOI=10.1145/2490428.2490438 http://doi.acm.org/10.1145/2490428.2490438

[26] Keita Emura, Akira Kanaoka, Satoshi Ohta, and Takeshi Takahashi. 2014. Building secure and anonymous communication channel: formal model and its prototype implementation. In Proceedings of the 29th Annual ACM Symposium on Applied Computing (SAC '14). ACM, New York, NY, USA, 1641-1648. DOI=10.1145/2554850.2554879 http://doi.acm.org/10.1145/2554850.2554879

[27] Vipul Goyal, Steve Lu, Amit Sahai, and Brent Waters. 2008. Black-box accountable authority identity-based encryption. In Proceedings of the 15th ACM conference on Computer and communications security (CCS '08). ACM, New York, NY,

58

USA, 427-436. DOI=10.1145/1455770.1455824 http://doi.acm.org/10.1145/1455770.1455824

[28] Alexandra Boldyreva, Vipul Goyal, and Virendra Kumar. 2008. Identity-based encryption with efficient revocation. In Proceedings of the 15th ACM conference on Computer and communications security (CCS '08). ACM, New York, NY, USA, 417-426. DOI=10.1145/1455770.1455823 http://doi.acm.org/10.1145/1455770.1455823

[29] Al-Riyami Certificateless Public Key Cryptography

[30] Byoungcheon Lee, Colin Boyd, Ed Dawson, Kwangjo Kim, Jeongmo Yang, and Seungjae Yoo. 2004. Secure key issuing in ID-based cryptography. In Proceedings of the second workshop on Australasian information security, Data Mining and Web Intelligence, and Software Internationalisation - Volume 32 (ACSW Frontiers '04), J. Hogan, P. Montague, M. Purvis, and C. Steketee (Eds.), Vol. 32. Australian Computer Society, Inc., Darlinghurst, Australia, Australia, 69-74.

[31] Angelo De Caro, Vincenzo Iovino, Giuseppe Persiano. Fully Secure Anonymous HIBE and Secret-Key Anonymous HIBE with Short Ciphertexts. Cryptology ePrint Archive, Report 2010/197, 2010. http://eprint.iacr.org/.

[32] Off-the-Record Messaging Protocol version 3. 2014. https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

[33] Ryan Stedman, Kayo Yoshida, and Ian Goldberg. 2008. A user study of off-the-record messaging. In Proceedings of the 4th symposium on Usable privacy and security (SOUPS '08). ACM, New York, NY, USA, 95-104. DOI=10.1145/1408664.1408678 http://doi.acm.org/10.1145/1408664.1408678

[34] Matt Green. Matt Green: A Few Thoughts on Cryptographic Engineering. 2014. http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html

[35] Vinnie Moscaritolo, Gary Belvin, Phil Zimmerman. Silent Circle Instant Messaging Protocol. Protocol Specifications. Silent Circle Engineering. December 5, 2012. Version 1.0.

[36] Neal Koblitz and Alfred Menezes. 2005. Pairing-Based cryptography at high security levels. In Proceedings of the 10th international conference on Cryptography and Coding (IMA'05), Nigel P. Smart (Ed.). Springer-Verlag, Berlin, Heidelberg, 13-36. DOI=10.1007/11586821_2 http://dx.doi.org/10.1007/11586821_2

[37] B. Lynn, On the implementation of pairing-based cryptosystems. PhD thesis, Stanford University, 2007.

[38] M. Ion, Security of Publish/Subscribe Systems. PhD thesis, University of Trento, 2013. http://eprints-phd.biblio.unitn.it/993/

[39] John Maheswaran, David Isaac Wolinsky, and Bryan Ford. 2013. Crypto-Book: an architecture for privacy preserving online identities. In Proceedings of the Twelfth ACM Workshop on Hot Topics in Networks (HotNets-XII). ACM, New York, NY, USA, , Article 14 , 7 pages. DOI=10.1145/2535771.2535798 http://doi.acm.org/10.1145/2535771.2535798

[40] https://www.eff.org/secure-messaging-scorecard (last accessed February, 2015)

[41] http://www.entrepreneur.com/article/230335 (last accessed February, 2015)

[42] https://github.com/trevp/axolotl/wiki (last accessed February, 2015)

[43] Glenn Greenwald. The top secret rules that allow NSA to use US data without a warrant. June 20, 2013 18:59 EDT. http://www.theguardian.com/world/2013/jun/20/fisa-court-nsa-without-warrant (last accessed February, 2015)

[44] Stephanie Mlot. Only 6 Messaging Apps Are Truly Secure. November 5, 2014 11:25AM EST. pcmag.com http://www.pcmag.com/article2/0,2817,2471658,00.asp (last accessed February, 2015)

[45] http://en.wikipedia.org/wiki/WhatsApp#Security (last accessed February, 2015)

[46] https://support.google.com/a/answer/6046115?hl=en (last accessed February, 2015)

[47] http://en.wikipedia.org/wiki/Google_Hangouts#Security (last accessed February, 2015)

[48] http://www.reuters.com/article/2014/10/14/us-snapchat-future-security-idUSKCN0I32UJ20141014 (last accessed February, 2015)

59

[49] https://www.snapchat.com/privacy (last accessed February, 2015)

[50] http://en.wikipedia.org/wiki/Snapchat#Secure_messaging_scorecard (last accessed February, 2015)

[51] https://www.pidgin.im/about/ (last accessed February, 2015)

[52] https://otr.cypherpunks.ca/index.php#docs (last accessed February, 2015)

[53] https://www.aim.com/faq (last accessed February, 2015)

[54] AOL Instant Messenger : Wikipedia http://en.wikipedia.org/wiki/AOL_Instant_Messenger#Security (last accessed February, 2015)

[55] Skype Security - Encryption http://www.skype.com/en/security/#encryption (last accessed February, 2015)

[56] Skype Has A Security Problem With Leaking Chats : Forbes.com http://www.forbes.com/sites/ianmorris/2014/08/14/skype-has-a-security-problem-with-leaking-chats/ (last accessed February, 2015)

[57] TextSecure - ProtocolV2 : github.com https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2 (last accessed February, 2015)

[58] http://www.voltage.com/company/awards-recognition/ (last accessed February, 2015)

[59] Joonsang Baek, Jan Newmarch, Reihaneh Safavi-Naini, and Willy Susilo. A Survey of Identity-Based Cryptography www.jan.newmarch.name/publications/auug_id_survey.pdf

[60] Carl Youngblood. An Introduction to Identity-based Cryptography. March 2005. https://courses.cs.washington.edu/courses/csep590/06wi/finalprojects/youngblood_csep590tu_final_paper.pdf

[61] Google Privacy & Terms. https://www.google.com/intl/en/policies/privacy/ (last accessed February, 2015)

[62] Yahoo Privacy Center. https://info.yahoo.com/privacy/us/yahoo/details.html (last accessed February, 2015)

[63] The Pairing-Based Cryptography Library. https://crypto.stanford.edu/pbc/ (last accessed September, 2014)

[64] Tilman Frosch, Christian Mainka, Christoph Bader, Florian Bergsma, Jörg Schwenk, and Thorsten Holz. 2014. How Secure is TextSecure? Horst Görtz Institute for IT Security, Ruhr University Bochum. https://eprint.iacr.org/2014/904.pdf

[65] export.gov/safeharbor (last accessed February, 2015)[66] eff.org (last accessed February, 2015)[67] otr.cypherpunks.ca (last accessed February, 2015)[68] whatsapp.com (last accessed February, 2015)[69] google.com/hangouts/ (last accessed February, 2015)[70] snapchat.com (last accessed February, 2015)[71] androidbootstrap.com (last accessed February, 2015)[72] aws.amazon.com (last accessed February, 2015)[73] www.ubuntu.com (last accessed February, 2015)[74] http://tomcat.apache.org/ (last accessed February, 2015)[75] http://httpd.apache.org/ (last accessed February, 2015)[76] http://dev.mysql.com/ (last accessed February, 2015)[77] prosody.im (last accessed February, 2015)[78] http://sageburner.com (last accessed February, 2015)[79] spring.io (last accessed February, 2015)

60