Ryan_Holt_MS_Thesis_Project

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

1
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 Otherinteresting 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
4.3 Design...............................................................................................................................33

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

4
Figure 43 - PBC Type a Pairing on Modern Mobile Devices ..................................................................51

5
TABLE OF TABLES
Table 1 - Pairing Types (PBC) .............................................................................................................17
Table 2 - Comparison of RelatedProjects...........................................................................................30
Table 3 - Elliptic Curve Security Levels................................................................................................40

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 necessarilylooking to throw away our rights, we just accept it as the ‘fee’ we
pay to use ‘free’applicationsandtools. Because there are oftenfew to no perceivable consequences to
giving away this information, it really does seem like we are getting all of these services for free. The
problemisthat the hiddencostof oversharing,like targetedadvertising, mightbe 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 tomake security seamless. Projectslike Off-The-Record(OTR),TextSecure,andCrypto-
Book are all designed with this solution in mind. Each of these projects provide exceptional security,
however,the securitymechanismsusedbegetusabilityissuesthatpreventthemfrombeingmore widely
adopted. In this paper I describe a novel construction of a secure messaging application for Android
devices. Thisimplementationisbuilton top of the Extensible MessagingandPresence Protocol (XMPP)
standard as the instant messaging and presence protocol and Identity-Based Encryption (IBE) as the
securitymechanism. The projecthas three main goals. The firstis to show,via a proof-of-concept,that
EllipticCurve Cryptography (ECC) isa viable securitymechanismonmodernmobile devices. The second
is to implementthissecuritymechanisminaway that isuserfriendly. Thismeansthat,inadditionto 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, andwhose modulescanbe addedas a securitylayeratopan existingsystem.

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 heardof the virtuesof big data, analytics,andcrowdsourcing 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 shouldwe be worried? While largeamountsof anonymizedaggregate datacanbe extremelyuseful
to device manufacturersandsoftware companies forprovidingsupportandqualityassurance,aswell as
in medical and scientific research,it is much more useful to hackers and to those whowouldonly 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 providersare collecting. Theyhave the ability(andyour consent) togather very
personal information such as your location, who you are talking to, the make, model, and unique
identifiersof 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 inthe image shownbelow.
FIGURE 1 - AN EXAMPLE OF A MOBILE APPLICATION PERMISSIONS PROMPT
Inadditionto malevolenthackers, wealsohaveaverygoodreasontobe skeptical of ourowngovernment.
Specifically, we should be concernedabout 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 includes bulk
collection of domestic call records, information that is "inadvertently acquired" during foreign and

9
domestic surveillance, and any electronic communications acquired because of limitationson the NSA's
ability to filter communications. They are interested in any communication if it is deemed to contain
usable intelligence,informationoncriminal activity, athreatof harmto people orproperty, isencrypted,
or isbelieved tocontainanyinformationrelevanttocybersecurity. That’sright. Simplythe factthatdata
isencrypted(all HTTPStrafficwouldfallinthiscategory) isjustificationenoughforthe NSAto have alook.
The NSA isempoweredtoretain thisdataforup to five years. Goodthingour governmentisasystemof
checks-and-balancesandthere’sprobablysomeone incharge of keepingthe NSA inline. Right? Wrong.
The discretionastowhoisactuallytargetedunderthe NSA'sforeignsurveillancepowersliesdirectlywith
itsownanalysts,withoutrecoursetocourtsorsuperiors. Oh,andif theyweren’tabletocollectitontheir
own, the NSA has the power to compel telephone and internet companies to turn over the
communicationsof anyindividual identifiedbythe NSA.[43]
Don’t look for private industry to protect your privacy either. Take Google for example. Many of their
services are encrypted usingSSL. 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 theirsystemsincludingemails,deviceinformation,loginformation,locationinformation,unique
application numbers, local storage, cookies and anonymous identifiers. The technical information they
gatherismostlyusedto improveexistingservicesand developnewones. The otherinformationcollected
isusedinamore invasivemanner:enabling “tailoredcontent”and“personallyrelevantproductfeatures”
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. Theywill also leave you high-
and-dryif youshouldhave arun-inwithlaw enforcement. They will giveupyourpersonal information to
“companies,organizationsorindividualsoutsideof Google”to“meetanyapplicablelaw,regulation,legal
process or enforceable governmental request”, leaving you vulnerable to law enforcement requests or
civil subpoenas. Don’tthinkthat deletingyourdata from theirserviceswill protectyou. Even afteryou
delete informationfromtheirservices, they“maynotimmediatelydelete residualcopiesfromouractive
servers”andthey may noteverremove the informationfrom theirbackupsystems. [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
deletedordeactivated yourinformationwillremainontheirsystemforanother90days. Evenonce your
account informationisdeleted,anyof your personal informationthatwas archived may remaininback-
up storage for“some periodof time”afteryour deletionrequest.[62,65]
Both Google and Yahoo (and most other services) provide opt-out ability for some of the more invasive
data collectionpractices.
1.1 SECURITY ISSUES IN MOBILE NETWORKS
Inadditiontothe securityconcernsmentioned above,mobilenetworkshave someunique securityissues
of theirown. In many distributedsystems,nodesare responsible forrelayingmessagestoothernodes.
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

10
(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
differentwebsitestofindandcompare pricesof items. These agents mustbe able tooperateinuntrusted
environments. Mobiledevicesthemselves have resourceconstraintssuchaslimited memory,processing
power, and batterylife. Thiscan limitthe amountof computationthatcan be performedorthe level of
communicationbetweendevices. Tradeoffs existbetweenbandwidthcapabilities,rangecapabilities,and
powerconsumption. Resourceexhaustion(transmittingexcessive packetstodrainthe batteriesofanode
device) canbe a significantissue. Designchoiceshave alarge impactonthe securityof mobile networks.
For example, in Peer-to-Peer (P2P) systems, decentralized systems are likely to be better suited for
handingDoS attacks,while semi-centralizedsystemswouldbe bettersuitedforhandlingauthentication.
Some systems are designedwith authentication and non-reputabilityas a primary concern. This means
that undercourt order the systemcan reveal private informationtogovernmentandlegal authoritiesby
cooperatingtoprovide akeyescrowservice.[2,5]
1.2 STATE OF THE ART
Messagingapplications allowyouto sendshort messagesand share images and video virtuallyinstantly
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. Accordingtothe ElectronicFrontierFoundation (EFF) mostbig-namemessagingservicesfail to
provide adequate securityfor their users. Security often comes at the cost of usability. Everyday users
mayhave trouble installing andconfiguringsecure applications,verifyingotherusers’ authenticity,setting
up accounts, or usingthe applications correctly. Forexample,Pidginallowssecure communicationviaa
plugincalled‘Off-The-Record’whichworksverywell,butonlyan advanceduser wouldbe able to install
andconfigure the plugin. In2011, about400 millionmobile deviceswereshippedandthere werearound
600,000 apps available for these devices. A big driving force for the attacks on mobile devices, and the
same reason that mobile securityneedstobe stressed,isthat the value of mobile paymenttransactions
isprojectedtoreach over$600 billionthisyear. [15, 44, 66, 67]
Next I review three of the most popular messaging apps being used today and their security
characteristics. I chose to lookat WhatsApp,Hangouts,andSnapChat because Ifeel theybestexemplify
the currentstate of the art. Below isachart fromthe ElectronicFrontierFoundation’swebsite. It’scalled
the Secure MessagingScorecardanditshows thesecurityprotectionsprovidedbymessaging applications.
As youcan see,these three appsdidnotscore verywell.

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 acquiredby Facebook in February of 2014. There
are 500 million registered (350 million active) WhatsApp users. WhatsApp is so incredibly popular
because itiseasy to use,cheaperthantext(SMS) messaging(especiallyinternationally),costsonly$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
encryptedwith,userscan'tverify otheruser'sidentities(noauthentication),pastmessagesare notsecure
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
partnershipwith OpenWhisperSystemstoprovide end-to-endencryptionbyincorporatingthe protocol
usedintheirTextSecure application. [45,68]
Hangouts is Google’s mobile messaging offering. Its instant messaging feature is incorporated into the
Gmail web-basedemailsystemand the Hangouts mobilemessagingappisavailableonAndroidand 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
messagesinHangoutsare sent overencrypted HTTPS connectionwith128-bit encryption,usingTLS1.2.
However, like WhatsApp, Hangouts only scored 2 out of 7 points on the EFF scorecard. Keep in mind
Google’sPrivacyPolicymentionedearlier. [46, 47, 69]
SnapChatisaphotoandvideomessagingappcreatedby StanfordUniversitystudents EvanSpiegel,Bobby
Murphy,and Reggie Brown. The mainfeature of the applicationisthatphotosand videossentare auto-
destroyed within 10 seconds, removed from both the recipient’s device and SnapChat’s servers. The

12
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 deletedwithinaspecifictimeframe.Andevenafterwe’vedeletedmessagedatafromourservers,
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 ordinaryserver-deletionpractices for specific
information. Finally, of course, as with any digital information, there may be ways to access messages
while still intemporarystorage onrecipients’devicesor,forensically,evenaftertheyare deleted.”
In additiontobeingunable to do goodon theirmainpremise,theyalsoletcompanies “use cookies,web
beacons, and other technologies” to collect your personal information including unique device
information (device identifiers, manufacturer,and operatingsystem), 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
spenddoingit. Theyuse thisinformationto “analyze andtrack data, determine the popularityof certain
content,and betterunderstandyouronline activity.” Theyalsosell thisinformationtoothercompanies
to use in targeted advertising. The kicker: “Snapchat does not currently respond to do-not-track signals
that may be sentfromyour device.”
Justlike the twoapplicationsreviewedpreviously,theappthatistrustedtoprivatelymanageclosetoone
billionphotosandvideoseverydayonlymanagedtoscore 2 pointsonthe EFF scorecard. In a breachof
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
enoughif eachuser hadtheirown unique keys,butbecause theyusedasingle universalkey,once itwas
exposed the attacker would be able to decrypt everything in the system. Despite such massive security
breachesbeingacommonheadlinetosee onthe news,take Targetand Home Depotforexample,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 definitelystop people from using Snapchat … until they have a really cool
picture to share." [48 - 50, 70]
1.3 PROJECTGOALS
If securitycan be made simple,secure applicationswouldbe more readilyadoptedbyalargernumberof
users who might not otherwise be willing to deal with the headache, frustration, and tedium of current
securitymeasures. Tothatend,I propose the constructionof asecure messagingapplicationforAndroid
devices. Thisimplementationisbuiltontopof the XMPPstandardasthe instantmessagingandpresence
protocol and Identity-BasedEncryption(IBE) asthe securitymechanism. The majorgoal of thisproject is
to achieve a high level of security without distracting the user with confusing and error prone security
configuration.
The paperstarts witha reviewof the currentstate of the art, some of the outstandingsecurityproblems
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,
ellipticcurvesandbilineargroups, andidentity-basedencryption. Ithenjustifymychoicesof the Android
operatingsystem,the XMPPmessagingprotocol,IBEandthe JPBClibrary. Inchapterthree Ireviewsome
of the relatedworkinsecure messagingapplications. In the fourth chapterI describe mysecure mobile
messaging app and provide the details in its implementation. I review the user experience and

13
performance of myimplementationinchapterfive. Idraw some conclusions inchaptersix andinchapter
sevenIoutline outstandingissuesandfuture work.

14
CHAPTER 2 – BACKGROUNDCONCEPTS (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 addressorotheridentifier. Messagesare encryptedusingacombinationof the systemmasterkey
and the id of the recipient. Usersmustgo to a trustedparty and prove theiridentityinordertoobtaina
private keywhichwill allow himtodecrypt messages. Thistrustedpartyis knownas the Key Generation
Server (KGS). During system setup, the KGS creates a master public keyand public parameters. [19, 27,
30, 59, 60]
FIGURE 3 - IDENTITY-BASED ENCRYPTION (IBE)
2.1 HISTORY OF IBE
The concept of Identity-BasedEncryption (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
simplifypublickeyandcertificatemanagementinaPublicKeyInfrastructure (PKI). InanIBEsystemauser
can sendan encryptedmessagetoanotherpartysimplybyknowingtheiridentityaswell asasetof global
parameters, eliminatingthe needtodistribute aseparate publickeyforeach userin the system.
Althoughthe concept initially received alotof interest,itwasn'tuntil several yearslaterthat Bonehand
Franklinintroducedthe firstIdentity-BasedEncryptionscheme usinggroupswithefficientlycomputable
bilinearmaps.The original Bonehand Franklinresultusedthe random oracle heuristicto prove security
under the Bilinear Diffe-Hellman assumption and a significant open question was whether the random

15
oracle model couldbe removed. Bonehand Franklinimplementedthe firstfunctional IBEscheme inthe
random oracle model (in 2001) and it was perfected by world-renowned cryptographers at Stanford
UniversityunderUSDefense fundedresearchprograms. Theirimplementationcame tobe knownasthe
StanfordPairingBasedCryptography(PBC) library.
Followingthe breakthroughresultof Bonehand Franklin,there hasbeensignificantprogressinrealizing
IBE in the standard model. First, Canetti, Halevi, and Katz proved security without the random oracle
heuristic,butundera weaker “Selective-ID"model where the attackermustdeclare the identity thathe
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 publicparametersconsistedof O(λ) group elementsforsecurityparameterλ. [7,
21, 27, 59, 60]
There hasbeensignificantworkonIBEsince then. Boldyreva,Goyal,andKumarcame upwithan efficient
revocation scheme for IBE in 2008. Brent Waters came up with the first Hierarchical IBE (HIBE) scheme
and an IBE systemwithshortparametersin 2009. De Caro, Iovino,Persiano realizedthe firstAnonymous
HIBE protocol in 2010. [21, 28, 31]
2.2 ELLIPTIC CURVES
An elliptic curve is one formed by an equation of the form y2 = x3 + ax + b over a finite field of prime
orderq (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
compute, but hard to reverse. For the BDH problem, this means findinggxy
given g and the values of gx

16
andgy
. As of 2006, the most efficientsolutionstothe BDHprobleminvolvesolving the discretelogarithm
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 orderq. The additive groupisimplementedusingagroupof pointsonan ellipticcurve. The
multiplicativegroupisa subsetof a multiplicative group of points overafinite field. Thissubgroupmust
have the followingthree properties:bilinearity,non-degeneracy,andcomputability. Thismapisreferred
to asa “bilinearpairing.” These mapsare derivedfromeitherthe Weil(pronouncedvay)orTate pairings.
Of these two, Tate pairingis typicallyfaster. Computationallyefficientonesare basedon bilinearmaps.
Map isa functionpairingelementsfromone grouptoanotherof the same prime orderwherethe discrete
logarithmproblemishardinthe firstgroup. Forexample,given:
Pair(a ∙ X, b ∙ Y)= Pair(b ∙ X, a ∙ Y)
Calculatinga∙ X iseasy,and finding agivenX anda ∙ X,ishard.
2.3 IDENTITY-BASED ENCRYPTION
There are four major algorithms or steps performed in Identity-Based Encryption: Setup, KeyGen,
EncryptionandDecryption.
 Setup:Performedbythe KeyGenerationServer. Createsmasterpublicandprivate keypairbased
on initializationparameters.
 Key Generation:Performedbythe KeyGenerationServer. Generates andreturns users’private
keyswhenrequestedaftertheyhave authenticatedthemselvestothe KGS.
 Encryption: Performedbythe users. Usingthe recipientsIDalongwiththe masterpublickey,the
userencryptsthe message andsendsitto the recipient.
 Decryption: Performed by the users. Using their private key,the receiving user can decrypt the
encryptedmessage.
For more in-depth informationon 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,”andLee et al’s“Secure KeyIssuinginID-BasedCryptography”[30,59, 60]
2.4 REVIEW OF ALGORITHMS AND THEIR CLASSIFICATIONS
The 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 initializationparametersmightbe chosen.
Here is a summary of pairings available in PBC cryptosystems. ‘Type a’ is considered the fastest pairing
and goodforcryptosystemswhere groupelementsize isnotcritical. Itutilizesthe supersingularcurve y2
= x3 + x over a group order Solinas prime. ‘Type dn’ pairing is good for cryptosystems when group
elementsmust be as short as possible. It uses the MNT method to generate curves. ‘Type e’ pairing is
considered to not be useful butrequiresonlymodulararithmetictoimplement.‘Type f’pairingis useful
for insuringagainstfuture finite fielddiscrete logalgorithmimprovements. The curve is foundusingthe

17
Paulo Barreto method. ‘Type gn’ pairing uses Freeman-Scottalgorithmto generate curves. It is slower
than embeddingdegree 12 pairings. No good use for this pairinghas beenfound. 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. Belowisatable of pairings andtheirattributes fromthe StanfordPBCLibrary.
Type Base Field Size
(bits)
k Dlog security
(bits)
a 512 2 1024
dn n 6 6n
e 1024 1 1024
f 160 12 1920
gn n 10 10n
a1 1024 2 2048
TABLE 1 - PAIRING TYPES (PBC)
There is one particular curve classification that is of particular importance in PBC, supersingular curves.
Supersingularcurvesare of the formy2
= x3
+ x. As of 2007 there are no known weaknessesfor(carefully
selected) supersingularcurves.
Identity-BasedEncryptionisreferencedinseveralInternetEngineeringTaskForce (IETF) draft standards;
RFC 5091 - Identity-BasedCryptographyStandard(IBCS) #1: SupersingularCurve Implementationsof the
BF and BB1 Cryptosystems, and RFC 5408 - Identity-Based Encryption Architecture and Supporting Data
Structures,amongothers. [16, 17, 22]
2.5 OTHER INTERESTING THINGSABOUTIBE
Identity-BasedEncryptionhaspotentialapplicationsinasecure machine tomachine(M2M) scheme inan
Internet-of-Things (IoT). Identity-based proxy re-encryption schemes can be derived from existing IBE
schemes. ProxyRe-Encryption(PRE) hasmanypractical applicationslikeemailforwarding,distributedfile
systems, andDigital RightsManagement (DRM).
In Fuzzy IBE, users’ keys and ciphertexts are associatedwith multiple descriptive attributes,ex. a user’s
identityandtime. A user’skey can decrypt a particular ciphertextonlyif some numberof attributes(so
called“error-tolerance”)matchbetweentheciphertextandthe key. The collusion-resistance propertyof
FuzzyIBE givessystems protectionfromuserswhohave beenrevoked. Attribute-BasedEncryption(ABE)
isan encryptionscheme thatis derivedfromFuzzyIBEandallowsthe authoritytospecifymore advanced
decryptionpolicies. ABEisusefulinDisruption-TolerantNetworks(DTNs)andforsecuring medical records
(or similarlysensitive documents) onmobile devices.[7,9,16, 17, 23, 25, 28]
2.6 NOTABLE IMPLEMENTATIONS
Boneh 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,
Switzerland, South Africa and Australia. Its cryptographic runtimes can be found in chips, operating
systemsandsoftware applicationsinindustriesrangingfromdefense andintelligence tofinancialservices
and software as a service companies. In 2003 the Hewlett Packard Lab in Bristol UK developed a

18
healthcare informationsystembuiltonIBE. In 2004, Voltage securitydevelopedanIBE implementation
that providespluginsforMicrosoftOffice,Hotmail,andYahoo.[6,7, 9, 58 - 60]
2.7 PROS AND CONS
The 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 proposedsolutionstothis problem. One solutioninvolvesusing multiple KGSs,where eachKGS
onlyhas one piece of the key information andthisneedstobe combinedwithpiecesfromotherKGSsto
get a complete key. Another solution involves trusted third-party mediators that help a user decrypt
messages. The keyrevocationproblemdealswithhowtoefficientlyrevoke usersfromthe systemaswell
as howtopreventrevokedusersfrom colludingwithvalidusers toreadencryptedmessages. A technique
that could solve bothkeyescrow and revocationproblemsisusinga 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 usedby RSA. It has been shownto be 10x slower at moderate securitylevels and up to
nearly 20 times slower at high security levels. The inefficiency is due to the fact that the pairing
computationsinvolvedare roughly20timesslower.[16– 18, 21, 26 – 30, 59]
The majoradvantage of Identity-BasedEncryption overotherencryptionschemes isthatit is certificate-
less. It doesn’trequire acomplex keymanagementinfrastructure like PublicKeyEncryption (PKE) does,
eliminatingthe storage andcomputingoverhead of storing,verifying,andrevokingcertificates. Usersin
an IBE systemdo not needto pre-share secrets. This lendsitself well tomobile anddistributedsystems
where devices need to be able to find, authenticate, and transact with each other without a central
authority. Significantlysmallercryptographicparameters,includingsmall publicandprivate keys,canbe
used in ECC than in other competitive public-key cryptographic systems such as the popular RSA
cryptosystembutwithequivalentlevelsof security. Whenusingschemeswithasmall numberof pairing
calculations(someof whichcanbe eliminatedduringrepeated operationswiththesame user),the system
can be computationally less intensive (light-weight). These restrictionsare 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 draftstandardsRFC 5091, and RFC 5408. [3, 18, 19, 22, 25, 29, 30, 59]
2.8 WHY WASIBE CHOSEN?
I chose to use Identity-Based Encryption in my secure mobile messaging application for many reasons.
Firstand foremost,Idon’tknowof anyotherinstantmessagingscheme thatusesIBEsoit wouldgive me
a chance to develop a proof-of-concept. Also, there has not been much work on Elliptic Curve
CryptographyonmobiledevicessoIwasinterestedtoseehow well ECCwouldperformonmodernmobile
phones. There are also manytechnical considerationsthatmade IBE an attractive choice for my system.
Because encryption is based on users’ identities there is no need to set up and manage a certificate
managementinfrastructure. The lowimplementationoverhead allowsfora systemthatcan 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

19
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
informationabouttheusersof the system. IBEalsoprovidesleakage-resiliency whichprotectsthesystem
against timing attacks, power dissipation, and cold-boot attacks that can extract information from the
systemincludingsecretkeysand the state of the encryptingsystem.
2.9 WHY WASJPBC CHOSEN?
The Java Pairing-Based Cryptography (JPBC) library was chosen as the IBE library because it is a Java
implementationof the popularandreputable StanfordPBClibrary.
2.10 WHY WASANDROID 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 Androidplatformare commonto all mobile platforms.
I chose to develop my messaging application for the Android operating system because it is free,open-
source,andI had readyaccessto Androiddevicesfordevelopmentandtesting. Because the AndroidAPI
isJava-based, the learningcurve will be smallerandIwouldbe able to geta systemupand runningmore
quickly. There are alsomanyqualitydevelopmenttoolsandframeworksavailable.

20
CHAPTER 3 – RELATED WORK
In additiontothe notable implementationsmentionedin Chapter2,here issome otherwork beingdone
relatedtosecure messaging.
3.1 OFF-THE-RECORD (OTR) MESSAGING
Off-The-Record(OTR)isasecure messagingprotocol that providesencryption,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 IMprotocols (AIM, jabber, XMPP, ICQ,
etc.). OTR version 3 is the most recentversionof the OTR protocol. In thisversion,the designersadded
many improvements to make it easier for the general public to use so that it would be more widely
adopted. They utilize the Libgcryptlibraryfor cryptographicfunctions,usingAESforencryption,RSA for
digital signatures, and SHA1-HMAC for message authentication. It also uses the Linux util /dev/random
to generate randomkeys.
Forward secrecy is a concept used to ensure that if a key is compromised,nocapturedmessagescanbe
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 encryptedusing the sharedsecret derived from the last keyreceived
from the other party and the last keythat has beensentto the otherparty. To achieve perfectforward
secrecy,the usersmustforgetpreviouslyusedkeysonce anew keyexchange hasbeencompleted.
Digital signatures are used to prove the authenticity of messages. The signatures are used only to sign
the publickeysinDH keyexchange. Nomessage isdigitallysignedasthiswouldcreate non-reputability.
Message authenticationcodes(MACs) are used topreventmessagespoofing.
In additiontoreputability,theyalsowantforgeability, orthe capabilitytoshow thatanybodycouldhave
modifiedthe message. Toachieve this,theyuse whattheycall “malleable encryption,”whichessentially
meansthat the ciphertextshouldbe modifiablewithoutproducinggarbage outputwhendecrypted. The
encryption scheme theychose to achieve this is AES in counter mode (a stream cipher). How it works:
Wheneveryouare abouttoforgeteitherone of youroldDHkeypairs,orone of yourcorrespondent’sold
DH publickeys,take all of the receivingMACkeysthat were generatedbythat key(there are up to two:
the receivingMACkeysproducedbythe pairingsof thatkeywitheachof twoof the otherside’skeys;but
note thatyouonlyneedtotake MAC keysthatwere actuallyusedtoverify aMACona message),andput
themintothe “Old MAC keystobe revealed”sectionof the nextDataMessage yousend.
While Off-The-Recordisaverysecure messagingprotocol,ithassome drawbackswhenitcomestouser-
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.
These iconscanbe confusingtouserswhoaren'tcompletelyfamiliarwiththe system. Thisconfusioncan
leadtouserfrustrationaswellasleavingthe usersvulnerabletocommunicatingoveraninsecurechannel

21
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 hashof auser’spublickey) inperson,overthe phone,etc.,orbyusingthe 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 issuesfiguring out
how to use this secret sharing window. A big limitation of this form of authentication is that it doesn’t
allowforthe authenticationof userswhohave nothadany priorcontact. [12, 32, 33]
3.2 Secure Instant Messagingand Presence Protocol (SIMPP)
The Secure Instant Messaging and Presence Protocol (SIMPP) is an XMPP-compliant protocol createdin
2007 by Yang, Kuo,Ahn, and Lee and basedon the open-source jabberdproject. Itisan implementation
of RFC 2778, draftedin2000, whichdefinesstandardfor presence andinstantmessagingservices. 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
reducingthe computational overheadimposedonthese systems due tothe security mechanisms.
SIMPP isconfiguredwith twosystemparameters:ellipticcurve E : y2 = x3 + ax + b and base pointG =
(xG, yG) of prime ordern > 2160. Usingthese parameters,the servergeneratesforitself apublic/private
keypair and sharesits publickeywithall usersin the system. This keyis usedby the clientsto generate
theirmaster keys. Their systemhas three phases:registration,client-servercommunication,andclient-
client communication. In the registrationphase,the client submits their ID and public key to the server
(R1). The serverrespondswiththese credentials,alongwitharandomstring, encryptedwiththe master
key (R2). The user responds with the random string signed with their private key, and, if valid, is then
registeredonthe server(R3).
FIGURE 5 - SIMPP PHASE 1: REGISTRATION
The client-server communication phase is the phase where the client authenticates with the server to
loginto the system. The clientauthenticateshimself bygeneratingasymmetricsessionkeyitwishesto

22
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 masterkey(S2). The clientrespondswithahashof the randomstring,encryptedwiththe symmetric
session key, and if the hashed value matches the hashed value computed by the server, the client is
allowedtologin(S3).
FIGURE 6 - SIMPP PHASE 2: CLIENT-SERVER COMMUNICATIONS
Once twoclientsare authenticatedandloggedinto the system,theymustretrieve eachother’spublickey
fromthe server(C1,C2). Withthese keys,theyperformthe EllipticCurve Signature Algorithm(ECDSA) to
authenticate each other (C3, C4). Once the clients have authenticated, they generate a shared session
keybymeansof EllipticCurve Diffie-Hellman(ECDH) keyexchange(C5) whichisthenusedtosecure 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. Fromthislibrarytheyuse 128-bit AESfor symmetricencryption,andECCover a prime fieldof
224 and160 bitson the serverandclientsrespectivelyforasymmetricencryption.
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
Akinyeleetal designedandimplementedwhattheycallself-protectingelectronicmedicalrecords(EMRs).
Specifically, they look at XML-based standard EMRs including Continuity of Care Records (CCRs) and
Continuityof Care Documents(CCDs). Theirimplementation providesfine-grainedencryption,the ability
to protect individual itemswithinanEMR by encryptingitand givingititsown accesscontrol 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 attributesthe user
has access to, and Ciphertext-PolicyABE:the ciphertextcontainsthe policydescribingwhoisentitledto
access it. ABE has expressive policyaccessformulae:policiescanbe expressedwithAND,OR,1-of-n,m-
of-n,> >=, <, <=.
FIGURE 9 - IHEALTHEMR POLICY ENGINE FLOW
Theirscheme is meanttobe practical andusable onmodern(2011) smartphones. Theirsmartphoneapp
ismeanttoallowpatientstotake theirmedical recordswiththemwhileremainingsecure ontheirdevice.
To achieve this security, the patient first needs to bring their phone into the hospital (or other trusted
entity) andhook itup to theirprivate-keygenerator(PKG) toassignthemtheirkeys. They get theirABE
key pair, as well as a pair of RSA keys which they can use to securely connect to the hospital to update
theirkeyswhentheyare aboutto expire.

25
FIGURE 10 - IHEALTHEMR ARCHITECTURE OVERVIEW
For efficiencyreasons they donot use ABE to directlyencryptrecord data. Instead, they use a standard
hybridapproachwhereineachrecordisencryptedusinga128-bit AES sessionkey,andthe sessionkeyis
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
unencrypteddataonthe mobile device.
TestingwasperformedonaniPhone4runningiOS4,anAppleA4processor,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-ABEwithupto 100 keyattributes. Theirresultsshowedthatencryptionanddecryptiontimewas
directlyrelatedtothe numberof attributesinthe accesspolicy.
FIGURE 11 - CP-ABE AND KP-ABE MOBILE PERFORMANCE
The chart on the leftin Figure 11 above showsthe performance of both the “normal” and “lite”variants
of theirscheme. The “lite”versionrealizessignificantperformance gains,andisrecommendedformobile
devices,because it usesaconstantnumberof pairingoperations.

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
systemhas acceptable performance on a fourthgenerationiPhone,itwouldlikelyrealize improvements
inuser experience onamodernmobile 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-Morenoetal. The JXTA specificationprovidesaset of openprotocolsthat enable
the creationand deploymentof P2P networks,enablingP2Papplicationstodiscoverandobserve 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
securitywhile beingtransparenttothe underlyingframework. Theyalsowantedit to be extensibleand
easilyadaptedtodifferentcryptomodules. Withtheirsystem, thiscanbe achievedmostlybyextension
and withlittle modificationtothe original code base.
The major security entities involved in the JXTA-Overlay framework are the SecurityManager and the
CryptoManager. Because theydesignedthe CryptoManagerina modularfashion,itessentiallyactsas a
proxy for any cryptographic module you wish to plug in, potentiallyeven one based on Elliptic Curve
Cryptography. In their implementation, security is provided by TLS utilizing X.509 certificates, JCE
keystores,and128-160 bit sessionidentifiers(SIDs),inadditionto 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 MVCframework. Clientpeersare protectedagainstimpersonationbyextending
the Discoverprimitivesandfunctionswithbrokerauthentication. A secure loginprimitive isprovidedto
protect username and password from eavesdroppers. They also implement a basic method for key
distributionbetweengroupmembers,once theyhave beengrantedaccessto the JXTA-Overlaynetwork
by the broker.

27
InJXTA-Overlay, keydistribution isinvisibletothe end-usersandtheyneednotconcern themselvesabout
how the keydistributionmechanismworks. Thismakesthe systemmore user-friendlyandtherefore 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 CryptoManagermodule. The onlyreal issue isthat itreliesoncertificatesanda certificate authority
to manage those certificates.[14]
3.5 TEXTSECURE (AXOLOTL)
TextSecure isasecure messagingappforAndroiddevelopedby WhisperSystems,whosegoal istocreate
“simple andeasy-to-use toolsforsecure mobilecommunicationandsecure mobilestorage.” Inaddition
to a private textandchat app, theyalsofeature anapp that allows private calling. WhisperSystems 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 beenunderactive developmentbythe open-source community. TextSecure hasreceivedpraise
by whistleblowerEdwardSnowden.
TextSecure’sprotocol consistsof several phases: registration,sending/receivinga firstmessage,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
everyoutgoingmessage,anda stateful authenticatedencryptionscheme. Keyexchange is essentiallya
triple Diffie-Hellman(DH) keyexchange usinglong-termandephemeral secretkeys. Thisisthe onlystep
in the protocol flowthat usesthe long-termkeys. The keymanagementprotocol providesbothforward
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
introductionof newDH ratchetkeys). Messagesare encryptedusingAESincounter mode andsent 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
deliveryisperformedviaGoogle CloudMessaging(GCM),whichbasically actsasa routerformessages.
Version 2 of the TextSecure messaging protocol uses the no header keysvariation of the axolotl ratchet
and protobuf records. The protocol can detect replay,reorder,and deletion of messages. It allowsthe
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 asthe confidentialityandauthenticityof the exchangedmessages. Everynew messageisencrypted
usinga new key and all messagesare encryptedlocally aswell asintransit.
In additiontoits reliance ona central authority, one issue withTextSecure isthatit onlypartiallyutilizes
its MAC image space. TextSecure uses HMAC-SHA-256 to calculate MACs but does not transmit the
complete output,onlythe first 64 of the 256 bit MAC. NIST recommends a MAC lengthof 80 bitswhen
used for key confirmation. TextSecure is also vulnerable to an attack known as an Unknown Key-Share

28
Attack (UKS). FirstdescribedbyDiffie etal, if such an attack is mountedagainst Pa, thenPa sharesa key
withPb,however, Pb believestheyshare akeywithPe != Pa.
FIGURE 13 - UKS ATTACK ON TEXTSECURE
Frosch etal provide asolutiontothe UKS attack intheirpaper ‘How Secure isTextSecure?’
Another issue with TextSecure is that it requires two parties to initially authenticate by comparing
fingerprintsusinganout-of-bandchannel,forexample,aphonecall oranin-personmeeting. Eventhough
they do make the manual process fairly easy by allowing the two parties to scan Quick Response (QR)
codesoneach other’sphones,it isstill inconvenientandinsome casesimpossible forthe communicating
partiestomeetinperson.[34, 42, 57, 64]
3.6 CRYPTO-BOOK
Modernsocial networkingsitesutilizecross-siteauthenticationprotocolssuchasOAuthandOpenID. One
of the down-sidesof theseprotocolsisthatauser’sonlineactivitycanbe easilytracked,presentingarisk
to online privacy. Toaddressthisissue, JohnMaheswaran,DavidIsaacWolinsky,andBryanFord created
Crypto-Book in2013. The conceptof the projectisto buildaprivacy-preservingcryptographiclayeratop
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 backto the owneryetcan resistanonymousabuse.
Crypto-Bookutilizeskeyservers(which couldbe runbythe social networkingsitesorindependently) that
existina cloudtheycall “anytrust”. Usersobtaintheirprivate keybyauthenticatingwitheachof the key
serversviaOAuth(overanSSLconnection). Eachkeyservergeneratesonlyone partof the user’sprivate
key; the user’s client machine (or potentially some trusted proxy) combines these key parts into the
complete private key. Tosupportthis,the creators chose the DSA keyformat because DSA keyssupport
easy key splittingand combining. DSA keys operate in a group G of order p and are of the form Y = gx
mod p, where Y isthe publickeyand xisthe private key. The keysare furtherdividedintoepochs,where
the key server’s master secret is valid only during a given epoch, and gets randomly reinitializedin each
successive epoch. The scheme remainssecure aslongasat leastone of these serversremainshonest.

29
FIGURE 14 - CRYPTO-BOOK'S ANYTRUST ARCHITECTURE
Crypto-Bookemploys RSA-basedringsignaturestoauthenticateanonymouslytothird-partywebsitesand
serviceswithoutrevealing Personally-Identifiable Information(PII)sothatuserscannotbe tracked. A ring
signature proves that one of the “ring members” signed a message but does not reveal which one. To
protect clientsfrombeingtrackedby maliciousservers,clientsare assumedtobe connectingto the key
serversoverananonymitynetworksuchasTor.
FIGURE 15 – CRYPTO-BOOK ANONYMOUS KEY RETRIEVAL
Asa proof-of-concept,they builtanimplementationof theirschemewhichtheydubbedBlackBox. Black
Box allowsuserstosignfilesdeniablyusingringsignatures. A possiblethreatto the Crypto-Bookscheme
involvesthirdpartysitescolluding inanattempttode-anonymizeanduniquelyidentifyusersusingsome
formof cross-site correlationattack. Overall,Crypto-Bookisaveryintriguingproject,withexcellentdata
securityoptionsfromachoice of cryptographicimplementation(RSA,DSA,orevenIBE),andusers’privacy
iswell protectedwiththe combinationof ringsignaturesandananonymitynetwork. [39]

30
3.7 SUMMARY
There isa lotof veryexcitingworkgoingoninthe worldof securityandprivacysoftware. Inthischapter
I reviewedavery small andeclecticsubsetof projectsfromthatworld. Ihave compiledatable toquickly
summarize the technical andpractical aspectsof eachapproach.
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 MIRACL
Elliptic Curve
Diffie-Hellman AES and ECC No
Self-Protecting
EMRs No N/A PBC Out-of-band ECC Yes
JXTA-Overlay Yes Yes Configurable Custom Configurable N/A
TextSecure (Axolotl) Yes Yes
Android
Native Library Diffie-Hellman AES Yes
Crypto-Book Yes Configurable Configurable Custom DSA, RSA, ECC No
TABLE 2 - COMPARISON OF RELATED PROJECTS
I wasveryexcitedtosee that,more oftenthannot,projectsare open-source. Thisisgoodnews,notonly
because publicscrutinyissecurity’sbestfriend,butitwillalsohelpfosterinterestandadoptionof secure
software applications. The projects also leveraged a wide variety of cryptographic libraries. I made a
judgementcall aboutthe user-friendlinessof eachapproachasit relatedtoitsparticulartask. 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) andwhetherornot the useris involvedinmakinganysecuritydecisions.

31
CHAPTER 4 – PROJECT DESIGN AND IMPLEMENTATION
4.1 PROJECT OVERVIEW
The goal of this projectis to developamobile messagingappthat is exceptionallysecure yetsimpleand
intuitive to use. Messages will be protected whensent over the wire as well as at rest, and will not be
persistedonusers’devicesoronthe servers. To be user-friendly,the securitymechanismisdesignedto
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,
authenticationsothatuserscanbe sure of otherusers’identities,deniabilitysothatanythingauserdoes
cannot be heldagainstthem,and forwardsecrecy so that if a userlosescontrol of theirprivate keys,no
previousconversationiscompromised. The application isintendedto be useful to anyonewhowouldlike
to share their personal, financial, business, and health information with the assurance that it is secure.
[71]
4.2 PROJECTARCHITECTURE
I chose to leverage cloud services to implement the messaging system. Cloud services provide fast
provisioning,reliability,lowmaintenance,andlow costs. I use AmazonWeb Services tohost 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
instancescanbe usedandpaid forbythe hourof runtime. Route 53providesscalableandhighlyavailable
DomainName System(DNS) services.The name (Route 53) is a reference to TCP or UDP port 53, where
DNS serverrequestsare addressed.[72]
The implementationconsistsof twoserversand,fordevelopmentandtesting,twoAndroidsmartphones.
One serveracts as the IBE KeyGenerationServer(KGS) anduserauthenticationserver. The otherserver
providesthe XMPPmessagingservice. The smartphonesrunthe secure messagingclientapplication.
On the KGS serverI am runningthe Ubuntu Linux Serveroperatingsystem (UbuntuServer14.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 WebServerisconfiguredforHTTPS sothatall authenticationrequeststothe serverare protected.
On the XMPP Serverinstance I am running Ubuntu Linux Server14.04.01 and the ProsodyXMPP Server.
Thisserveralsohoststhe projectwebsite 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-A9processorwith1GB of RAM. The Galaxy Note 3 (2013) runs the Android4.4 operatingsystem
and has a quad-core 2.3 GHz Krait400 processorandhas 3 GB of RAM.

32
FIGURE 16 - HIGH LEVEL PROJECT ARCHITECTURE

33
4.3 DESIGN
A majordesigngoal of the system istomake iteasy totake the modulesdeveloped andimplementanew
system with them or add them as a security layer to an existing system. Two moduleswere developed
for thissystem,amobile clientmodule andaservermodule. The servermodule providesauthentication
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 clientmodulecanbe modifiedtoutilizedifferent messagingprotocols,andthe IBE
module canbe takenby itself andaddedtoan existingmessagingsystem.
Anotherimportantdesignchoice wastoisolatethe userfromanysecuritydecisions. Asidefromentering
their username and password, users should not be aware of how the security mechanism functions or
that it evenexists. This iswhere Identity-BasedEncryptioncomesin. Because publickeysare basedon
users’identities,thereisnoneedforacomplex keyexchange mechanismeither withinthe applicationor
out-of-band.
FIGURE 17 - PROJECT ARCHITECTURE

34
There are four main steps performed by the client devices in order to send and receive encrypted
messages. These are authentication,IBEretrieval,messageencryption/decryption,andsending/receiving
messages. The authentication and IBE retrieval tasks are performed in conjunctionwith the KGS server
viawebservice requests login andgetIBEParams. The login requesttakesthe user’susernameandahash
of theirpasswordasparameters.
FIGURE 18 - REST REQUEST: LOGIN
The getIBEParams request accepts a single parameter called a key. This key is either the key of the
IBEParamsobjectstoredon the server,or‘0’ if the clientisrequestinganew IBEParamsinstance.
FIGURE 19 - REST REQUEST - GETIBEPARAMS
A userauthenticates tothe systemby submittingtheirusername andpassword tothe KGS serverovera
secure HTTPSsession. HTTPSisarequirementonauthenticationasusers’passwordsare sentinplaintext.
FIGURE 20 - USER AUTHENTICATION
Upon successful authentication,anXMPPconnectioniscreated and the user is connectedtothe instant
messagingservice. The userisauthenticated tothe XMPPserverwithstoredcredentials andgetsthe user
roster (or ‘friends list’) showing the user’s list of friends and their online status. The user then selectsa
userwithwhom theywishto start a conversationwith. Whenthe conversationisstarted,the firstthing
that happensisa requestismade tothe KeyGenerationServerfora new IBEParamsinstance.

35
FIGURE 21 - IBEPARAMS RETRIEVAL (NEW IBE)
ThisIBEParamsobjectcontainsall of the IBE publicparameters. Once the IBEParamsobjectiscreatedon
the server,itissavedtothe IBEParamsmapand the publicparametersare returnedinJSON format. With
these parameters,the clientinitializesitsownIBEinstance. Withthis IBEobject,the usercannow encrypt
and decryptmessages.
FIGURE 22 – JPBC IBEPARAMS JSON MESSAGE
Messagesare Base64 encodedandsentoveraninsecure (unencrypted)channel. Ichose to implementa
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.
Whensendinga message itis immediatelyencryptedandsenttothe recipient. A copyof the encrypted
message is stored in the Conversation Message List on the client so that it can be displayed on the UI.
Because the messageisstoredinencryptedform,itisprotectedfromanyleakofinformationontheusers’

36
devices. The message istherefore securedbothintransitand at rest. A majordrawback to thisscheme
isthat messagesmustbe decryptedeverytimetheyare displayedon the conversation view. Thoughthis
isa verysecure process,itisinefficientandhas observable performance implications.
Upon receiptof the message,the receivingusermustrequestthe correspondingIBE parametersfor the
sessionfromthe KGS. The recipienttheninitializes theirown IBE instance withthese parametersandis
thenable to decryptthe message.
FIGURE 23 - IBEPARAMS RETRIEVAL (EXISTING IBE)
The novel partabout thisIBE scheme isthat in thisimplementation, differentIBEobjectsare 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. Thisavoidsthe keyescrow problemof IBE because once the IBE is initializedandhandedoff,the
KGS isn’taware of any of the keysusedinthe system. A compromisedKGScouldbe configuredtomake
copiesof eachIBEParamsobject, buttheseobjectswouldonlybe useful ifthe attackerwasalsosomehow
able togetthe encrypted messagesoff of oneof the users’devices. The attackerwouldhavelimitedtime
to do this as the messages are destroyed when the users endthe communication session. On a trusted
KGS, IBEParamsare onlyexposedtoattack as longas it takesfor the initial message recipienttoretrieve
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
lookingto disclose. Theycoulddo this by parsingthe veryfirst message sentinthe conversationas this
message contains the keyto the IBEParams object in the map stored on the server, however,this keyis
not transmittedagainafterthe initial message.

37
The diagram belowshowsthe completemessagingflow of the application.
FIGURE 24 - MESSAGING FLOW DIAGRAM

38
4.4 IMPLEMENTATION DETAILS
There are two maincomponentsinthe implementationof the system;aserverapplicationmodulecalled
the sageburner_im_server and a client application called sageburner_im. The sageburner_im_server
module runs on the Key GenerationServer. This applicationis writtenin Java and is built on top of the
Spring application framework running on Apache Tomcat 7 web application server. Its purpose is to
provide authenticationandIBE KeyGenservicestothe sageburner_imclientapplicationviaRESTful web
services. It utilizesthe JPBCand BouncyCastle librariesforencryption. Thismodule performsthe Setup
and KeyGenstepsfromthe IBEprotocol. [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
supportedbythe Androiddevelopmentcommunityanditisdevelopedusingindustrystandardpractices
and proven design patterns. Along with user-interface templates, the framework comes with
authenticationandRESTservice componentsout-of-the-box. Thismodule providesthe securemessaging
clientforthe mobiledevices. ItwascompiledforAndroidAPI19(Android4.4KitKat) andutilizesthe JPBC
andBouncyCastle librariesforencryptionaswell asthe ‘asmack’XMPPclientlibraryforinstantmessaging
and presence services. Thismoduleperformsthe EncyptandDecryptstepsfromthe 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,itreliesonthe UserDaoclassto retrieve the user informationfrom the database. The users’
passwords are validated with the help of the CryptoService, which compares the hash of the received
passwordto the hashedpasswordstoredinthe database.
FIGURE 25 - AUTHENTICATION SEQUENCE DIAGRAM

39
The UserDao class leveragesthe onlydatabasetable inthe system whichis usedasthe userdirectoryfor
authentication. This table, named user, stores information about each user that is registered with the
system. Itstoresthe users’personal informationaswellastheirsystemcredentialsandXMPPconnection
information. The XMPP credentials are used to connect to the XMPP services once the user has
successfullyauthenticated.
FIGURE 26 - SAGEBURNER_AUTH DATABASE
SCHEMA
FIGURE 27 - USER TABLE DESCRIPTION
The heartof the authenticationmechanismisthe CryptoUtilsclass. Thisclass reliesonthe PasswordHash
utilityclasstogenerate andcompare the hashesof users’passwords.
FIGURE 28 - AUTHENTICATION CLASS DIAGRAM

40
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 (seenin
JSON format in Figure 22) giving it a unique key with which it can be accessed at a later time. These
IBEParamsare generatedbythe initializationof anew IBE instance.
FIGURE 29 - IBE RETRIEVAL CLASS DIAGRAM
As stated before, Identity-Based Encryption using Elliptic Curve Cryptography was chosen as the
cryptographicscheme in thissystem. ECC with ‘Type a’ pairingwas chosen because it is consideredone
of the mostefficientpairingalgorithmsavailable inthe JPBClibrary. ‘Type a’ pairingsare constructedon
the curve y2 = x3 + x over the finite field 𝔽qfor some prime q = 3 mod 4. The pairingis initializedwith
publicparameters r= 160, q = 512, and k = 2. Here is a definitionof these parameters:
 𝐸: ellipticcurve overfinitefieldoverprime 𝔽q
 q: fieldsize of base-point 𝑃∈ 𝐸(𝔽q)
 r: prime orderof base-point 𝑃∈ 𝐸(𝔽q) – r doesnot divide q
 k: embeddingdegree (multiplicativeorderof qmod r)
Security Level (in bits) 80 112 128
r 160 224 256
q 512 1024 1536
RSA Key Size 1024 2048 3072
TABLE 3 - ELLIPTIC CURVE SECURITY LEVELS

41
Encryptionis performed onthe clientmodule whensendingmessagesandinvolves twosteps. First,the
message is encrypted using the Advanced Encryption Standard (AES) symmetric encryption protocol.
Then,the AES key isencryptedusingIBE encryption. The encryptedmessage andencryptedAESkeyare
concatenatedandsentto the recipient. The diagram below shows,ingreatdetail,the innerworkingsof
thisprocess.
FIGURE 30 - MESSAGE ENCRYPTION
In instantmessaging,the messagesthatare sentbackand forthare typicallyveryshortandsothere isno
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
wouldbe symmetricallyencrypted,whichwouldbe fast,andthe symmetrickeygeneratedwouldthenbe
encryptedusingIBE,whichwouldalsobe fastbecause the keysize isrelativelysmall.

42
Decryption isperformedinthe reverse orderof encryption. The receivinguserparsesthe concatenated
message and usesIBE to decryptthe AES key. With thisnow decrypted symmtrickey the user is able to
decryptand readthe message.
FIGURE 31 - MESSAGE DECRYPTION

43
Belowisthe classdiagramshowingallof thecomponentsinvolvedinthe securetransmissionandretrieval
of messages. Thisdiagramexemplifiesthe modulardesignof the systemwithIBEat itscore. As youcan
see,several differentthird-partylibrarieswere usedinthisimplementation toprovidethe userinterface,
authentication,andcommunication functionalityof the system. These libraries includethe base Android
SDK libraries, the Retrofit REST web service client APIs, and the asmack client library for communicating
withthe XMPP protocol.
It isworth notingthatall of the encryption,bothIBE and symmetric,ishandledbythe CryptoUtilsclass.
FIGURE 32 - MESSAGING CLASS DIAGRAM

44
CHAPTER 5 - USER EXPERIENCE AND APPLICATION
PERFORMANCE
5.1 USER EXPERIENCE
The user interface of an application plays a large role in determining whether or not a user is going to
have a gooduserexperience. Asa developer,you wanttopresentthe userwiththe right amountof the
featuresandinthe rightwaysothattheyare confident inwhattheyare doing. Thismeansusingcontrols,
layouts, and a flow that a user is comfortable and familiar with. User Experience (UX) engineers have
spentcountlesshoursperfectingthisexperience onmobiledevices andthe AndroidBootstrapframework
builds on this effort. It comes with a basic user interface including a login page, a few list views, a
navigationdrawer,andsome simplebutusefulUserInterface(UI) controls. The mainapplicationscreens
are configuredwitha ‘carousel’ or ‘viewpager’layoutmanagerthat allowsthe userto flipleftandright
throughviewslike pagesof a book. Swipinginfrom the far leftor selectingthe menuiconwill openthe
navigationbar. There is alsoa contextmenuallowingyoutoadd more advanced,butnot oftenneeded,
features toyourapplication.
There are three mainscreensinthissecure messagingapplication. Theyare the loginscreen,the friends
list,andthe conversationview.
FIGURE 33 - LOGIN FRAGMENT VIEW FIGURE 34 - FRIENDS LIST FRAGMENT VIEW

45
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.
Whena userclicks on the name of an online contacttheyare takento the conversationview (Figure 35)
where theycanbeginasecure conversationwiththe selected user. Fromthere the usercan swipe leftor
right on the screento navigate betweenthe friendslistandthe conversationview. On the conversation
view, the user enters the message they wishto 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
sendinguser’savatarimage onthe rightof the screen. Incomingmessageswill show upwiththe sending
user’savatar onthe left.

46
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
applicationicon. Clickingon thisicon launchesthe applicationanddisplaysthe loginscreen(Figure 33).
Foruserswhoare notregisteredwiththesystem, theycanregisterusing theuserregistrationpage(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 registrationprocess.

47
FIGURE 38 - LOGOUT OPTION ON THE CONTEXT MENU FIGURE 39 - LOGOUT OPTION ON THE NAVIGATION
DRAWER
The user can log out of the applicationbyselectingthe logoutoptionfromeitherthe navigationdrawer
(Figure 38) or fromthe contextmenu(Figure 39).

48
The diagram belowshowsthe completeuserinterface flowof the Androidclientapplication.
FIGURE 40 - CLIENT FLOW DIAGRAM

49
Figure 41 showsthe majorcomponentsof the applicationuserinterface. All Androidapplicationshave a
MainActivitythathandlesthe initializationof the application. Inthisimplementation,the MainActivityis
responsible forinitializingall of the servicesusedbythe applicationincludingthe authenticationservice,
messaging service, and encryption service. Once initialization is complete, or as it completes in the
background,the application displaysthe mainview. In thisapplication,thatmain view isthe LoginView
(Figure 33). The two maindisplays,the FriendsListFragmentandConversationFragment,are managedby
the CarouselFragment whichgives the user the ability to page back and forth betweenthem by swiping
back and forthon the screen.
In Android, the application logic is bound very tightly to the user interface components. The most
importantuserinterface objectinthisappisthe ConversationViewbecauseithandlesall of themessaging
tasks,fromsecuritytotransmissionandreception. Forthatreason,youseethatthe CryptoUtilsclass,the
class responsible for all of the cryptographic functions in the system, has a direct relationship with the
ConversationFragmentuserinterfaceclass.
FIGURE 41 - USER INTERFACE CLASS DIAGRAM

50
5.2 APPLICATION PERFORMANCE
Twodifferentperformance testswereperformedoneachof the mobile devicesusedduringdevelopment
(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
whichloggedthe time ittookto performeachtask. The resultsare showninthe chart below.
FIGURE 42 - IBE PERFORMANCE ON MODERN MOBILE PHONES
As indicatedbythe chart, IBE Setuptakes a longtime to complete;almost2 secondsonthe Nexusand1
second on the Note 3. In practice, this does not have a noticeable impact on the performance of the
applicationbecause thistaskisdone asymmetrically,inthe background,whenthe applicationisstarted.
Notsurprisingly,the biggestperformancebottleneckinthe application are theencryption(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
‘exponentiationpreprocessing’istakingplace,cachingalarge amountof exponentsforuse inthe pairing
functions.

51
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,isthatthe device manufacturedin2013 performedalmosttwice aswell asthe one from 2011.
If this trend continues, Identity-Based Encryption schemesbased on Elliptic Curve Cryptography could
become a viable securityscheme formobileapplicationsinthe verynearfuture.

52
CHAPTER 6 – CONCLUSION
A mobile user’s privacy is under constant threat of attack from numerous sources at any given time.
Protectingpersonal and professional informationinsucha hostile environmentisa continuoustaskand
one of utmost importance. Taking on such a challenge requires having the right toolsand empowering
users to use them. Along with projects like Off-the-Record, TextSecure, and Crypto-Book, the secure
messagingapplicationdevelopedhere isone of those tools.
The appprovides securityviafourmajorcryptographicfunctions:encryption,authentication,deniability,
and forward secrecy. Encryption is provided by implementing an IBE scheme which leverages the JPBC
library. The novel partof thisIBE implementationisthat new IBE instancesare createdfor eachsession,
thereby avoiding the intrinsic key escrow problem of IBE. Authentication is provided via a REST-based
authenticationmodule runningonthe KGSserver. Deniabilitycomesfromthe factthat the messagesdo
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, usersare assuredthe messagestheyread are authenticand unmodified. Forwardsecrecy
is achieved by the use of unique session keyswhich are destroyed alongwith the conversation session.
All of thesefunctionsare builtusingstandardalgorithmsandparameterssothat the securityof the system
can be easily testedandproven.
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. Developedasa proof-of-conceptforAndroiddevices,the projectshowsthatIdentity-Based
Encryption can be utilized effectively in a mobile environment and that Elliptic Curve Cryptography is a
viable securitymechanismonanymodernmobile device. Althoughthe currentsystemdoessufferfrom
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
applicationshavepotential usesinsecureinstantmessagingaswellasthe sharingof sensitive professional
and healthinformation.

53
CHAPTER 7 - FUTURE WORK
The secure mobile messaging application developed here works well as a proof-of-concept but there is
much workthat can be done to improve uponit. The most obvious areaof improvement tousersof 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 systemdesignedandimplementedin thisproof-of-conceptisnotadesignthatwouldscale. Asis,the
systemhas no wayof managingkeysbetween multiple KeyGenerationServers,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 servermodule toimplementamulti-KGSsystem.
The application and infrastructure also do not support group messaging, and, for several reasons the
applicationdoesnotkeeptrackof pastconversations. Itislikelythatsome userswouldlike tobe able to
communicate securelywithgroupsof people,aswellasbe able to view theirconversationhistorydespite
the somewhat increased security risk. With careful design these features could be added as
enhancementstothe clientapplication.
Much more testingis needed toprove long termconnectionstabilityandapplicationreliability. And,as
withany securitymechanism,itcouldbenefitfrommore thoroughsecurityanalysis. Thatsaid,there are
some security issues that became clear as the prototype was being developed. To increase the security
of the system,future versions couldbenefitfromutilizingastandard authenticationmechanismsuchas
Spring Security. Also,the implementation of a periodic IBE refreshscheme, where new IBE parameters
are requestedwithinamessagingsession(similartothe OTR scheme) wouldprovide additional security
and improvedforwardsecrecy.
Because the systemwasdesignedwiththe goal of beingmodularandextensible,there are opportunities
forthe systemtobe improvedandexpandedupontocreate new applications. Forexample,becausethe
system uses a symmetric/asymmetric double encryption scheme, the system should be able to handle
muchlargermessage sizeswithlittledecreaseinperformance. Forthisreason,Ibelieve the systemcould
be easilyadaptedtoa secure file transfer scenario. These filescouldbe anythingfromphotosandvideo
to businessdocumentsandmedical records.
Future applications of this secure messaging scheme include the transmission of personally identifiable
information(PII) suchassensitiveformsneededbyemployersandgovernmentagencies,personalhealth
information (PHI) such as medical history forms needed by doctors’ offices and emergency rooms, and
othersensitivedata.
GoingforwardI will continue toimprove uponthe secure messagingapplicationandtake the knowledge
gainedfromdevelopingthe prototype tocreate new andinnovative securitytools.

54
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 communicationmethodinmobile wireless networks. InProceedings o f
the 1st international conference on MOBILe Wireless MiddleWARE, OperatingSystems, andApplications
(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. DesignandImplementation ofa Secure Instant
Messaging Service basedonElliptic-Curve Cryptography. http://security.nknu.edu.tw/publications/200801JOC.pdf
[4] Chung-Huang Yang, Tzong-Yih Kuo. 2007. The DesignandImplementation ofa Secure Instant Messaging Key
Exchange Protocol. http://www.kc.org.tw/fleget/FileDownLoad.aspx?CDE=149
[5] James Walkerdine, Peter Phillips, andSimonLock. 2008. Architecting secure mobile P2Psystems. InProceedings of
the 1st international workshop onSoftware architectures andmobility(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, andJoos Vandewalle. 2003. (How)canmobileagents dosecure electronic transactions
on untrustedhosts? A surveyof the securityissues andthe current solutions. ACMTrans. Internet Technol. 3, 1
(February2003), 28-48. DOI=10.1145/643477.643479 http://doi.acm.org/10.1145/643477.643479
[7] JosephA. Akinyele, MatthewW. Pagano, Matthew D. Green, Christoph U. Lehmann, ZacharyN.J. Peterson, andAviel
D. Rubin. 2011. Securing electronic medical records using attribute-based encryptiononmobile devices. In
Proceedings of the 1st ACM workshoponSecurityandprivacyin 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] ViganRaça, Betim Çiço, andMajlinda Fetaji. 2012. Management, communications andsecuritypolicyin mobile
database systems. InProceedings ofthe FifthBalkan Conference inInformatics (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, andClaus PoppLarsen. 2011. Secure mobile accessto homecare patients'
data. InProceedings of the 5th International Conference onTheoryandPractice 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] AndroidProgramming:The Big Nerd RanchGuide (BigNerdRanchGuides) Series:Big NerdRanchGuides. Paperback:
580 pages. Publisher:BigNerdRanch Guides;1 edition(April 7, 2013). ISBN-10:0321804333. ISBN-13:978-
0321804334.
[11] Abhijit Bose andKang G. Shin. 2006. Proactive securityfor mobile messaging networks. InProceedings of the 5th ACM
workshopon 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, IanGoldberg, andEric Brewer. 2004. Off-the-record communication, or, whynot to use PGP. In
Proceedings of the 2004 ACMworkshopon Privacyinthe 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, andMoti Yung. 2007. Forward-secure signatures in untrustedupdate
environments:efficient andgeneric constructions. In Proceedings of the 14th ACMconference onComputer 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, LeonardBarolli, andFatos Xhafa. 2009. Securing a Java P2Pframework:the JXTA-
overlaycase. InProceedings of the 11th InternationalConference on Information Integration andWeb-based

55
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, andLi Yang. 2013. Learning mobile securitywith android
securitylabware. In Proceeding of the 44th ACMtechnical symposiumon 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, JianqingZhang, Eve Schooler andMihaela Ion,“Performance Evaluationof Attribute-BasedEncryption:
Toward Data Privacyinthe IoT,” IEEE InternationalConference on Communications (ICC), 2014.
http://csiflabs.cs.ucdavis.edu/~xlwang/public/icc_2014_wang.pdf
[17] S. Roy, M. Chuah, "Secure Data Retrieval Based onCiphertext PolicyAttribute-BasedEncryption (CP-ABE)Systemfor
the DTNs", LehighCSE TechnicalReport, May, 2009 http://www.cse.lehigh.edu/~chuah/publications/cpabe-
report09.pdf
[18] InternationalJournal ofNetworkSecurityVolume: 15, No:4 (July1, 2013) A Surveyon Attribute-basedEncryption
Schemes of Access Control inCloud Environments Cheng-Chi Lee, Pei-Shan Chung, andMin-ShiangHwang, 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 Theoryof CryptographyConference TCC2007 February21-24 2007, KNAW Trippenhuis Amsterdam, The
Netherlands. Multi-AuthorityAttribute-BasedEncryption. Melissa Chase
http://cs.brown.edu/~mchase/papers/multiabe.pdf
[20] The Java Pairing-BasedCryptographyLibrary(JPBC) @inproceedings{ISCC:DecIov11,author = {Angelo{De Caro} and
VincenzoIovino},title = {jPBC:Java pairing basedcryptography},year = {2011},pages = {850-855},booktitle =
{Proceedings of the 16th IEEE Symposium onComputers and Communications, ISCC2011},address = {Kerkyra, Corfu,
Greece, June 28 - July1}publisher = {IEEE},url = {url{http://gas.dia.unisa.it/projects/jpbc/}},}
[21] Brent Waters. 2009. Dual System Encryption:RealizingFullySecure IBE andHIBE under Simple Assumptions. In
Proceedings of the 29th AnnualInternational CryptologyConference 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] JoonsangBaek and JianyingZhou. 2011. Compact identity-basedencryptionwithout strongsymmetric cipher. In
Proceedings of the 6th ACMSymposium onInformation, Computer andCommunications Security(ASIACCS '11). ACM,
[23] Song Luo, JianbinHu, and ZhongChen. 2010. New constructionof identity-basedproxyre-encryption. In Proceedings
of the tenthannual ACMworkshopon Digital rights management (DRM'10). ACM, New York, NY, USA, 47-50.
[24] Sherman S.M. Chow, YevgeniyDodis, Yannis Rouselakis, andBrent Waters. 2010. Practicalleakage-resilient identity-
basedencryptionfrom simple assumptions. InProceedings of the 17th ACMconference onComputer 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, andV. L. Shivraj. 2012. An identitybasedencryption
using elliptic curve cryptographyfor secure M2Mcommunication. InProceedings ofthe First InternationalConference
on Securityof 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, andTakeshi Takahashi. 2014. Buildingsecure andanonymous
communicationchannel:formal modelandits prototype implementation. InProceedings ofthe 29th Annual ACM
Symposium onAppliedComputing(SAC'14). ACM, New York, NY, USA, 1641-1648. DOI=10.1145/2554850.2554879
http://doi.acm.org/10.1145/2554850.2554879

56
[27] Vipul Goyal, Steve Lu, Amit Sahai, andBrent Waters. 2008. Black-box accountable authorityidentity-based
encryption. In Proceedings of the 15th ACMconference onComputer andcommunications security(CCS '08). ACM,
[28] Alexandra Boldyreva, Vipul Goyal, andVirendra Kumar. 2008. Identity-basedencryptionwithefficient revocation. In
Proceedings of the 15th ACMconference 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 KeyCryptography
[30] Byoungcheon Lee, Colin Boyd, Ed Dawson, KwangjoKim, JeongmoYang, andSeungjae Yoo. 2004. Secure keyissuing
in ID-basedcryptography. In Proceedings of the secondworkshoponAustralasianinformation security, Data Mining
and Web Intelligence, andSoftware Internationalisation - Volume 32 (ACSW Frontiers '04), J. Hogan, P. Montague, M.
Purvis, and C. Steketee (Eds.), Vol. 32. AustralianComputer Society, Inc., Darlinghurst, Australia, Australia, 69-74.
[31] AngeloDe Caro, VincenzoIovino, Giuseppe Persiano. FullySecure Anonymous HIBEandSecret-KeyAnonymous HIBE
with Short Ciphertexts. CryptologyePrint Archive, Report 2010/197, 2010. http://eprint.iacr.org/.
[32] Off-the-RecordMessaging Protocol version3. 2014. https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
[33] Ryan Stedman, Kayo Yoshida, andIanGoldberg. 2008. A user studyof off-the-record messaging. InProceedings of the
4th symposium onUsable privacyandsecurity(SOUPS'08). ACM, New York, NY, USA, 95-104.
[34] Matt Green. Matt Green:A Few Thoughts onCryptographic Engineering. 2014.
http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html
[35] Vinnie Moscaritolo, GaryBelvin, Phil Zimmerman. Silent Circle Instant Messaging Protocol. Protocol Specifications.
Silent Circle Engineering. December 5, 2012. Version1.0.
[36] Neal Koblitz andAlfred Menezes. 2005. Pairing-Based cryptographyat high securitylevels. InProceedings of the 10th
international conference onCryptographyandCoding (IMA'05), NigelP. 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, StanfordUniversity, 2007.
[38] M. Ion, Securityof Publish/Subscribe Systems. PhD thesis, Universityof Trento, 2013. http://eprints-
phd.biblio.unitn.it/993/
[39] John Maheswaran, DavidIsaac Wolinsky, and Bryan Ford. 2013. Crypto-Book:an architecture for privacypreserving
online identities. In Proceedings of the Twelfth ACMWorkshoponHot Topics inNetworks (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] GlennGreenwald. The topsecret rulesthat 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 accessedFebruary, 2015)
[44] Stephanie Mlot. Only6 MessagingApps Are TrulySecure. 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 accessedFebruary, 2015)
[46] https://support.google.com/a/answer/6046115?hl=en (last accessedFebruary, 2015)
[47] http://en.wikipedia.org/wiki/Google_Hangouts#Security (last accessedFebruary, 2015)

57
[48] http://www.reuters.com/article/2014/10/14/us-snapchat-future-security-idUSKCN0I32UJ20141014 (last accessed
February, 2015)
[49] https://www.snapchat.com/privacy (last accessedFebruary, 2015)
[50] http://en.wikipedia.org/wiki/Snapchat#Secure_messaging_scorecard (last accessed February, 2015)
[51] https://www.pidgin.im/about/ (last accessedFebruary, 2015)
[52] https://otr.cypherpunks.ca/index.php#docs (last accessedFebruary, 2015)
[53] https://www.aim.com/faq (last accessedFebruary, 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 accessedFebruary, 2015)
[56] Skype Has A SecurityProblem With LeakingChats :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.comhttps://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2 (last accessed
February, 2015)
[58] http://www.voltage.com/company/awards-recognition/(last accessedFebruary, 2015)
[59] JoonsangBaek, JanNewmarch, Reihaneh Safavi-Naini, andWillySusilo. A Surveyof Identity-BasedCryptography
www.jan.newmarch.name/publications/auug_id_survey.pdf
[60] Carl Youngblood. An Introductionto Identity-basedCryptography. 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 accessedFebruary, 2015)
[62] Yahoo PrivacyCenter. https://info.yahoo.com/privacy/us/yahoo/details.html (last accessedFebruary, 2015)
[63] The Pairing-BasedCryptographyLibrary. https://crypto.stanford.edu/pbc/(last accessedSeptember, 2014)
[64] TilmanFrosch, Christian Mainka, Christoph Bader, FlorianBergsma, Jörg Schwenk, and ThorstenHolz. 2014. How
Secure is TextSecure? Horst Görtz Institute for IT Security, Ruhr UniversityBochum.
https://eprint.iacr.org/2014/904.pdf
[65] export.gov/safeharbor (last accessedFebruary, 2015)
[66] eff.org (last accessedFebruary, 2015)
[67] otr.cypherpunks.ca (last accessed February, 2015)
[68] whatsapp.com (last accessed February, 2015)
[69] google.com/hangouts/(last accessedFebruary, 2015)
[70] snapchat.com(last accessedFebruary, 2015)
[71] androidbootstrap.com (last accessed February, 2015)
[72] aws.amazon.com (last accessedFebruary, 2015)
[73] www.ubuntu.com(last accessedFebruary, 2015)
[74] http://tomcat.apache.org/ (last accessedFebruary, 2015)
[75] http://httpd.apache.org/(last accessedFebruary, 2015)
[76] http://dev.mysql.com/(last accessedFebruary, 2015)
[77] prosody.im (last accessedFebruary, 2015)
[78] http://sageburner.com (last accessedFebruary, 2015)
[79] spring.io (last accessedFebruary, 2015)

Ryan_Holt_MS_Thesis_Project

More Related Content

Viewers also liked

Similar to Ryan_Holt_MS_Thesis_Project

Ryan_Holt_MS_Thesis_Project