elliptic curve diffie-hellman 571 on google™ android
TRANSCRIPT
NANYANG TECHNOLOGICAL UNIVERSITY
SCHOOL OF ELECTRICAL AND ELECTRONIC ENGINEERING
Elliptic Curve Diffie-Hellman 571 on Google™ AndroidProject No: A3024-111
Submitted by:Goh Ying Yi, Alvin (U0921277D)
Supervisor:Associate Professor Ng Chee Hock
Chan Choong Wah Ph.D.
A Final Year Project Report presented to the
School of Electrical and Electronic EngineeringNanyang Technological University
in partial fulfilment of the requirements for theDegree in Bachelor of Engineering
(Electrical and Electronic Engineering)Academic Year 2011/2012
1
Table of ContentsList of Figures.........................................................................................................................5
List of Tables..........................................................................................................................6
Abstract...................................................................................................................................7
Acknowledgements................................................................................................................8
Chapter 1: Introduction...........................................................................................................9
1.1 Background...................................................................................................................9
1.2 Project Scope..............................................................................................................10
1.3 Project Objectives.......................................................................................................10
Chapter 2: Literature Review...............................................................................................11
2.1Hybrid Encryption Scheme.........................................................................................11
2.1.1 Asymmetric Key Exchange.................................................................................12
2.1.2 Symmetric Key Cipher........................................................................................14
2.2 Diffie-Hellman Key Exchange...................................................................................15
2.2.1 Overview.............................................................................................................15
2.2.2 Diffie-Hellman Implementation..........................................................................16
2.3 Elliptic Curve Cryptography......................................................................................17
2.3.1 Overview.............................................................................................................17
2.3.2 Elliptic Curves over Finite Prime Fields (Fp).....................................................18
2.3.3 Elliptic Curves over Finite Binary Fields (F2m)..................................................18
2.3.4 ECDH Shared Secret Generation........................................................................19
2.4 Google Android..........................................................................................................20
2.5 Bouncy Castle.............................................................................................................21
2.5.1 Spongy Castle......................................................................................................21
2.6 Short Message Service................................................................................................22
Chapter 3: Project Overview and Design Methodology.......................................................23
3.1 Project Overview........................................................................................................23
3.2 Project History............................................................................................................24
2
3.2.1 Initial Implementation.........................................................................................24
3.2.2 Second Implementation.......................................................................................25
3.2.3 Current Implementation.......................................................................................25
3.3 Project Strategy...........................................................................................................26
3.3.1 Phase 1: Beginning Android................................................................................26
3.3.2 Phase 2: Research................................................................................................26
3.3.3 Phase 3: Rapid Prototyping.................................................................................27
3.3.4 Phase 4: Spiral Development...............................................................................28
3.3.5 Testing, Report & Presentation...........................................................................29
3.6 Design Methodology..................................................................................................29
Chapter 4: Implementation...................................................................................................30
4.1 System Specifications.................................................................................................30
4.2 ECDH Encryption.......................................................................................................31
4.2.1 Initial Implementation.........................................................................................31
4.2.2 Usage of Named Curves......................................................................................31
4.2.3 Final Implementation...........................................................................................32
4.2.4 Supported Parameters..........................................................................................33
4.3 SMS Activity Screen..................................................................................................34
4.3.1 Sending SMS.......................................................................................................35
4.3.2 Key Sharing.........................................................................................................36
4.4 Preferences Screen......................................................................................................37
4.5 Receiving SMS...........................................................................................................38
4.5.1 SmsKeyShare Screen...............................................................................................39
4.5.2 DisplayMessage Screen.......................................................................................40
3
Chapter 5: Testing & Analysis.............................................................................................41
5.1 Functional Test...........................................................................................................41
5.2 Named Curve Performance Test.................................................................................44
5.2.1 Test Setup............................................................................................................45
5.2.2 Selected Test Results...........................................................................................45
5.2.3 AES Performance Test Results............................................................................46
5.2 SMS Transmission......................................................................................................47
5.2.1 Message Transmission.........................................................................................48
5.2.2 Public Key Transmission.....................................................................................48
5.3 Physical Device Test..................................................................................................49
5.3.1 Physical Device Test Results...................................................................................50
Chapter 6: Conclusion and Recommendations.....................................................................51
6.1 Conclusion..................................................................................................................51
6.2 Recommendations for Future Work...........................................................................52
6.2.1 Contact List Integration.......................................................................................52
6.2.2 ECDH Generation on Physical Server.................................................................52
6.2.3 UI Improvements.................................................................................................53
6.2.4 Multipart Messaging............................................................................................53
Bibliography.........................................................................................................................54
Appendix..............................................................................................................................56
Appendix A: Related WaveCrypt Projects.......................................................................56
Appendix B: WaveCrypt Storyboards..............................................................................57
Appendix C: Activity Diagram of SMS Activity.............................................................60
Appendix D: Activity Diagram of SmsReceiver Activity................................................61
Appendix E: Named Curve Efficiency Test Results........................................................62
4
List of Figures
Figure 1: Hybrid Encryption Scheme [1].............................................................................11Figure 2: Public-Key Cryptography [2]................................................................................12Figure 3: Symmetric Key Cryptography [2].........................................................................14Figure 4: Diffie Hellman Key Exchange..............................................................................15Figure 5: Elliptic Curve with Parameters (a, b) = (1, 0), (-3, 0), (-2, 5)...............................17Figure 6: Worldwide Smartphone Sales in 3Q11 According to Gartner [7]........................20Figure 7: Diagram of SMS Operation..................................................................................22Figure 8: Use Case Diagram for SMS Functionality............................................................23Figure 9: WaveCrypt Prototype for Secure SMS Messaging...............................................24Figure 10: Second WaveCrypt Implementation...................................................................25Figure 11: Project Timeline..................................................................................................26Figure 12: Prototyping Model of Software Development [14]............................................27Figure 13: ECDH Encryption Screen...................................................................................27Figure 14: Spiral Model of Software Development [15]......................................................28Figure 15: Sequence Diagram for Encrypted SMS..............................................................29Figure 16: Defining the Elliptic Curve.................................................................................31Figure 17: Code for Specifying Security Provider and Generating ECDH Key Pair...........32Figure 18: SMS Activity Screen...........................................................................................34Figure 19: Activity Diagram for SMS Activity (Abbreviated)............................................35Figure 20: Activity Diagram for shareKeys Method............................................................36Figure 21: Preferences Screen..............................................................................................37Figure 22: Activity Diagram for SmsReceiver Activity (Abbreviated)...............................38Figure 23: SmsKeyShare Activity Screen............................................................................39Figure 24: DisplayMessage Activity Screen........................................................................40Figure 25: Named Curve Test Environment.........................................................................44Figure 26: LogCat Output.....................................................................................................44Figure 27: Comparison of Generation Speed (ms) of Selected Curves................................45Figure 28: LogCat Output 2..................................................................................................46Figure 29: Screenshots of Android’s Messaging App..........................................................47Figure 30: Sequence Diagram of Loopback Test.................................................................49Figure 31: Activity Diagram for SMS Activity....................................................................60Figure 32: Activity Diagram of SmsReceiver Activity........................................................61
5
List of Tables
Table 1: Guidelines for public key sizes with equivalent security levels [3].......................13Table 2: Selected ECDH Parameters....................................................................................33Table 3: SMS Headers..........................................................................................................38Table 4: Processing Time (in milliseconds) for NIST B-571 ECDH Curve........................46Table 5: ANSI X9.62 Named Curves Over Finite Prime Field Fp.......................................62Table 6: SEC Named Curves Over Finite Prime Field Fp...................................................62Table 7: Teletrust Named Curves Over Finite Prime Field Fp.............................................62Table 8: NIST Named Curves Over Finite Prime Field Fp..................................................63Table 9: ANSI X9.62 Named Curves Over Finite Binary Field F2m...................................63Table 10: SEC Named Curves Over Finite Binary Field F2m..............................................64Table 11: NIST Named Curves Over Finite Binary Field F2m.............................................64
6
Abstract
The penetration of smart devices into the mobile phone market has taken much momentum in the recent years. It is now gathered that there are almost three in four Singaporeans, and one in three global mobile users carrying smartphones. While smart mobile devices have expanded our communication capabilities, by allowing services like the Internet to be used on our mobile devices, it has also inadvertently exposed us to more security vulnerabilities, which can result in data theft. This report details the WaveCrypt project, a mobile application suite allowing for multiple modes of secure communication, such as SMS, MMS, email, and VoIP, over the Google Android mobile platform. In particular, this report will cover the secure SMS function using the Elliptic Curve Diffie-Hellman (ECDH) 571 asymmetric key encryption system. The implementation of the ECDH algorithm using the BouncyCastle API to generate the asymmetric key pair, which is used in conjunction with the symmetric key encryption system to perform the encryption/decryption of SMS, will be discussed. In addition, test results to verify the workability of the project as well as the efficiency of various ECDH parameters will be showcased.
7
Acknowledgements
I would like to acknowledge and extend my heartfelt gratitude to the following persons who have made the completion of this final year project possible:
Associate Professor Ng Chee Hock, my supervisor, for his vital support and management of the project.
Chan Choong Wah Ph.D., my co-supervisor, for his much needed guidance in the implementation of the project.
Mr Thean Hock Boon and Ms Tay Mei Yun, both previous implementers of WaveCrypt, for their excellent work on which I have based my implementation on.
Most especially to my family and friends.
8
Chapter 1: Introduction
1.1 Background
In recent years, we have seen an increase in the significance of cryptosystems in everyday application. With the world becoming more and more connected each day via the World Wide Web, the threat of becoming a target for cyber-espionage increases. At an enterprise level, we hear of many instances of large, secured networks being compromised (e.g. the PlayStation Network) and user data stolen.
At a personal level, user communication has gone largely unsecured. Our most commonplace form of communication, via voice and short message (SMS), is transmitted wirelessly over unsecured channels. While the risk of such data being compromised is generally low, the advent of Internet enabled smartphones could pose a potential risk.
In Singapore, smartphones have taken over the island by storm. In a survey conducted by market research company TNS, Singapore ranked third globally in smartphone penetration rate with almost three in four Singaporeans carrying smartphones. The fact remains that while Internet penetration via the mobile phone has significantly increased, the same cannot be said about the penetration of security suites and the channel remains largely vulnerable to a yet-to-be exploited loophole.
As smartphone users continue to download content via the form of applications or files, a likely scenario that could happen would be that a user downloads a malicious application which in turn silently sends user communication data such as SMS over the Internet. An even simpler yet effective of security breach would be the loss of the mobile device itself, rendering all information open to the bearer of the phone.
To counter this issue, a suite of secure mobile applications developed under the name of WaveCrypt will be used. The primary function of the application is to provide secure communication via encryption of the data before transmission through unsecured channel paths, such as mobile voice, SMS and email.
9
1.2 Project Scope
The scope of this part of the WaveCrypt project is on the development of a secure Short Message Service (SMS) application via the use of various existing cryptography methods currently available in the market. The Elliptic Curve Diffie-Hellman (ECDH) cryptosystem will be studied in detail and implemented for this project due to its ability to achieve a similar level of security as compared to other Public Key Cryptosystems (PKC) while keeping a relatively smaller key size.
Google Android™ has been selected as the platform of development due to its wide penetration in the smartphone market as well as its general availability on the Windows operating system as open source software as compared to Apple’s iOS.
1.3 Project Objectives
Several objectives are to be achieved upon completion of this project:
The main objective would be to come up with the framework for which the SMS function of WaveCrypt will operate on, including cryptographic key generation methods, SMS payload and key agreement protocol.
The next objective is to study and understand the ECDH asymmetric cryptosystem which will used to generate keys to be used in conjunction with the symmetric key cipher.
Understanding of the Google Android™ platform and its method of programming (Java) and testing is also required to allow the enhancement of the Graphical User Interface (GUI) of the application.
Finally, the application will need to be rigorously tested to ensure proof of concept as well as to iron out bugs present in the system.
10
Chapter 2: Literature Review
2.1Hybrid Encryption Scheme
Hybrid Encryption Scheme utilizes a combination of two functional blocks, the asymmetric Elliptic Curve Diffie-Hellman key exchange protocol for generation of public-private key pairs, and the symmetric key cipher for encryption and decryption of data.
Figure 1: Hybrid Encryption Scheme [1]
While asymmetric key cryptography allows two uses to share secret keys securely over an unsecure channel, it is computationally complex to use directly as a data encryption tool. Conversely, symmetric key cryptography has the advantage of fast computational speed, but lacks the ability to share keys securely over an unsecure channel.
By combining the use of a computationally complex key sharing technique and an efficient encryption/decryption cipher, we are able to get the best out of both asymmetric and symmetric key cryptography in terms of security and speed.
11
2.1.1 Asymmetric Key Exchange
Asymmetric key cryptography, also known as Public Key Cryptography (PKC) makes use of a public-private key pair to establish a shared secret between two parties over an insecure channel. When two users wish to perform PKC, they must first generate their personal public-private key pairs. Each user will then share their public key to the other party.
Figure 2: Public-Key Cryptography [2]
Figure 2 illustrates the sequence taken by Bob to encrypt a message to be sent over to Alice. Bob first takes Alice’s public key which was shared to him earlier to encrypt the message. He then sends the message over to Alice who decrypts the message using her private key.
In the case of ECDH, the public key is not used directly to encrypt the message. Instead the shared public key of Alice is combined with the private key of Bob (and vice versa) to create a new shared secret key which is then used in tandem with a symmetric key cipher to do the encryption. Section 2.2.1 explains in detail the Diffie-Hellman key exchange protocol.
The Elliptic Curve Diffie-Hellman key agreement protocol makes use of Elliptic Curve Cryptography (ECC) as the key generation method due to its ability to achieve a higher
12
level of security with a smaller key size as compared to other public-key cryptography methods such as RSA (Rivest, Shamir, Adleman).
Table 1: Guidelines for public key sizes with equivalent security levels [3]
Security (bits) Symmetric
Encryption
Algorithm
Minimum size (bits) of public keys
DH RSA ECC
80 2TDEA 1024 1024 160-233
112 3TDEA 2048 2048 224-255
128 AES-128 3072 3072 256-383
192 AES-192 7680 7680 384-511
256 AES-256 15360 15360 512+
Table 1 shows the NIST guidelines comparing the public key sizes of 3 different PKC methods for equivalent security levels. It can be noted that ECC requires public key lengths that are comparatively shorter than RSA or traditional Diffie-Hellman. This presents to users a significant benefit in terms of a smaller key size, allowing more efficient storage and transmission of keys.
13
2.1.2 Symmetric Key Cipher
Figure 3: Symmetric Key Cryptography [2]
As shown in Figure 3, symmetric key cryptography relies on a secret key shared between two users to perform the encryption and decryption. Examples of symmetric key cryptography techniques include the Data Encryption Standard (DES), Triple DES (3DES), Blowfish and the Advanced Encryption Standard (AES).
The key motivator for using symmetric key cryptography is the speed at which data can be encrypted and decrypted compared to asymmetric key cryptography. However, there lies a problem of secure key sharing.
Symmetric key sharing requires the actual secret key to be shared between two parties, as compared to asymmetric key sharing where a publicly available key is available to use by all for encryption and a privately held key is used solely by the recipient of the message for decryption. Direct sharing of secret keys pose a security problem, as anyone with the knowledge of the secret key is able to access messages encrypted with it. Hence, it is often used as a cipher in tandem with an asymmetric key generator.
Readers who are interested to learn more about the AES symmetric key are encouraged to view the report SMS Mobile Encryption on Google™ Android by Ong Chai Seng (See Appendix A)
14
2.2 Diffie-Hellman Key Exchange
2.2.1 Overview
The Diffie-Hellman (DH) Key Exchange protocol, first published by Whitfield Diffie and Martin Hellman in 1976, was one of the earliest methods that utilized a key exchange for cryptography. It allowed two parties with no prior knowledge of each other’s private key to generate a shared secret key for use over an insecure channel.
Figure 4: Diffie-Hellman Key Exchange
To understand the Diffie-Hellman protocol, we take a look at Figure 4. Supposing there are two parties, Alice and Bob, who wish to send a secured message. Bob and Alice will each generate a Public and Private Key of their own. They then trade their Public keys over the unsecure network. Private keys are not shared with anyone.
Upon reception of each other’s public key, they will generate a shared secret key using their own Private Key as well as their partner’s Public Key. The generated shared Secret Key, which is equivalent for both parties, will then be used for encryption of data.
15
2.2.2 Diffie-Hellman Implementation
To understand the technique behind the Diffie-Hellman key agreement protocol, we take a look at the encryption mathematics behind this technique. In this example [4], we make use of the original implementation of Diffie-Hellman (ECC is omitted) using the multiplicative group of integers modulo p where p is prime and g is a primitive root mod p.
Key Agreement Proof:
1. Alice and Bob agree to use prime number p=23 and base g=52. Alice chooses a secret integer a=6 and sends Bob A = ga mod p
A= 56 mod 23 = 83. Bob chooses a secret integer b=15 and sends Alice B = gb mod p
B = 515 mod 23 = 194. Alice computes shared secret s = Ba mod p
s = 196 mod 23 = 25. Bob computes shared secret s = Ab mod p
s = 815 mod 23 = 26. They now both share a secret s = 2 which can be used for encryption
On Alice’s end:
s = Ba mod p = (gb mod p)a mod p = (gb)a mod p
On Bob’s end:
s = Ab mod p = (ga mod p)b mod p = (ga)b mod p
It should be noted that:
(gb)a mod p ≡ (ga)b mod p
Hence, both parties will end up with the same shared secret.
16
2.3 Elliptic Curve Cryptography
2.3.1 Overview
As earlier mentioned, ECC presents a more computationally efficient method of achieving similar security levels compared to other PKC. An elliptic curve (EC) should not be mistaken for an ellipse. It is given by the general equation:
E : y2=x3+ax+b
Figure 5: Elliptic Curve with Parameters (a, b) = (1, 0), (-3, 0), (-2, 5)
By varying the parameters for ‘a’ and ‘b’, we are able to get different shapes of elliptic curves as seen in Figure 5.
The general concept of elliptic curve cryptography is as such:
1. We begin on a point P(x, y) on the elliptic curve2. We specify an ordinary integer k which will be used for the encryption process3. We then calculate the final point R(x, y) = kP by applying point addition of P for k
number of times (R = P+P+P+…+P)
Given the points R and P, it is computationally excruciating to recover k if k is large, with the possible way being the naïve method of iterating point additions of P to get R. This is known as the discreet logarithmic problem.
ECDH is defined over either the Finite Prime Field (Fp) or the Finite Binary Field (F2m).
17
2.3.2 Elliptic Curves over Finite Prime Fields (Fp)
Elliptic curves defined over the finite prime field Fp contain the following parameters:
T= (p, a, b, G, n, h)
The integer p for the finite prime field Fp and the elements a & b (a, b ∈ Fp) specify the elliptic curve parameters in the equation:
E(Fp) : y2=(x¿¿3+ax+b)mod p¿
G is a base point G(x, y) on the curve E(Fp), n is a prime number of order G and h is an integer cofactor where h= #E(Fp) / n.
2.3.3 Elliptic Curves over Finite Binary Fields (F2m)
Elliptic curves defined over the finite binary field F2m contain the following parameters:
T= ( m , f(x) , a , b , G , n , h )
The integer m for the finite binary field F2m, the irreducible binary polynomial f(x) of degree m and the elements a & b (a, b ∈ F2m) specify the elliptic curve parameters in the equation:
E(F 2m): y2+xy=x3+ax+b, b ≠ 0
G is a base point G(x, y) on the curve E(Fp), n is a prime number of order G and h is an integer cofactor where h= #E(F2m) / n.
18
2.3.4 ECDH Shared Secret Generation
We have seen separately how the Diffie-Hellman algorithm works as well as that of ECC. Now, we specify the method for generation of the shared secret key (K) using the Elliptic Curve Diffie-Hellman algorithm:
1. The elliptic curve to be used (Fp or F2m) as well as a & b parameters are specified, along with base point G.
2. User A selects an integer PT(A) as his private key. He then generates his public key PU(A) = PT(A) x G where PT(A) x G is (G+G+….+G) by PT(A) times. He then sends his public key to user B.
3. User B then selects an integer PT(B) as his private key. He then generates his public key PU(B) = PT(B) x G where PT(B) x G is (G+G+….+G) by PT(B) times. He then sends his public key to user A.
4. A calculates the shared secret key K K = PT(A) x PU(B)
5. B calculates the shared secret key K K = PT(B) x PU(A)
6. Both User A and B will end up with the same shared secret K.
It should be noted that:
K calculated by A = PT(A) x PU(B)
= PT(A) x (PT(B) x G)
= (PT(A) x PT(B)) x G
= (PT(B) x PT(A)) x G
= PT(B) x (PT(A) x G)
= PT(B) x PU(A)
19
= K calculated by B
2.4 Google Android
Android is a Linux-based operating system for mobile devices (e.g. mobile phones, tablets) by Google Inc. Originally developed by Android Inc., it was bought over by Google in 2005 as the company’s first step into the smartphone industry [5].
It is widely adopted by many leading smartphone producers around the world such as HTC, Motorola, Samsung and many others under the Open Handset Alliance [6] which aims to develop open standards for mobile devices. The Google Android code was released as open-source under the Apache Licence and is primarily developed in a customized Java version.
52%
17%
15%
11% 2% 1% 1%
Worldwide Smartphone Sales for 3Q11 Android Symbian iOS RIM Bada Microsoft Others
Figure 6: Worldwide Smartphone Sales in 3Q11 According to Gartner [7]
Today, Google Android is one of the most sought after smartphone platform, with a 3 rd
quarter 2011 (3Q11) market share of 52.5% according to Gartner [7], far surpassing that of other platforms like Apple’s iOS and Nokia’s Symbian, which banked in on only 15% and 16.9% respectively of total smartphone sales in 3Q11.
20
2.5 Bouncy Castle
Bouncy Castle (BC) is a set of Application Programming Interfaces (APIs) developed for use for cryptography [8]. It was originally developed as a means to minimize the need for redevelopment of cryptographic libraries and is available online as open source software under an adaptation of the MIT X11 Licence. It consists of two components supporting basic cryptographic capabilities; the ‘light-weight’ API and the JCE provider.
2.5.1 Spongy Castle
It should be noted that this project utilizes a variant of BC known as Spongy Castle (SC). Both APIs are identical in terms of implementation and SC is merely a repackaged version of BC.
The motivation for using SC over BC is due to Google Android’s in-built BC API [9] which was included in Android 2.3. The Android BC API was a scaled-down version of the actual BC API and did not contain certain necessary components for performing ECDH. Due to the similar naming convention of BC in both versions, users found that they could not load the full BC API. To solve this problem, BC was repackaged and renamed SC.
Developers should note the following [10]:
21
Spongy Castle is the stock Bouncy Castle libraries with a couple of small changes to make it work on Android:
all package names have been moved from org.bouncycastle.* to org.spongycastle.* - so no classloader conflicts
the Java Security API Provider name is now SC rather than BC
No class names have been changed, so the BouncyCastleProvider class remains Bouncy, not Spongy, but moves to the org.spongycastle.jce.provider package.
22
2.6 Short Message Service
Short Message Service (SMS) is a text messaging service found in most, if not all, modern phones. It allows the user to send short text messages of 160 characters over the fixed line or mobile phone devices.
Figure 7: Diagram of SMS Operation
SMS messages are sent using the store and forward mechanism. When User A intends to send an SMS message to User B, the phone first sends the message to the SMS Center (SMSC). The SMSC saves the message and searches for User B on the network. On finding user B on the network, the SMSC then forwards the message to User B.
23
Chapter 3: Project Overview and Design Methodology
3.1 Project Overview
The WaveCrypt project aims to develop a suite of applications used for secure mobile communication on the Google Android™ mobile platform. Key functionality of the software suite includes secure SMS/MMS messaging, email and Voice over IP (VoIP). The project is developed consecutively between several students working on different sections of the application (See Appendix A for a list of related project reports on WaveCrypt).
For this part of the implementation, the focus lies on creating the secure SMS functionality of the application. The key outcomes include:
1. Ability to generate public-private key pair and share public keys2. Generation of shared secret for encryption purposes3. SMS send and receive capability4. Encryption and decryption of SMS5. Set preferences
24
Figure 8: Use Case Diagram for SMS Functionality
3.2 Project History
3.2.1 Initial Implementation
This project was first worked on by Then Hock Boon under the project code A3033-101[11]. A prototype application was developed as a Proof of Concept (POC) which was able to send encrypted SMS between users.
25
Figure 9: WaveCrypt Prototype for Secure SMS Messaging
However, a working model was not completed due to the limitations which prevented the generated keys from being shared between phones.
Several improvements were proposed from the previous project:
1. Enablement of multipart SMS to allow sharing of keys via SMS2. Integration of the Bouncy Castle API to allow native ECDH functionality3. Improvements to User Interface (UI) 4. Dedicated inbox5. Support for other data types
26
3.2.2 Second Implementation
The second implementation was done by Tay Mei Yun under the project code A3229-102[12].
Figure 10: Second WaveCrypt Implementation
In the second revision of WaveCrypt, an improved user interface was presented which consolidated the functions into a single main application. This UI would be the basis for the current implementation of the project.
Several improvements were proposed from the second implementation:
1. Increase the character limit of SMS2. Make the key generation/sharing transparent to the user
3.2.3 Current Implementation
The current project addresses a few key improvements raised from the previous implementations. Multipart SMS was successfully implemented to allow key sharing via SMS; however this was omitted for the user end to ensure message integrity. The Bouncy Castle API was also implemented for ECDH key generation. Finally, the key generation process was made optionally transparent to the user.
27
A dedicated inbox for confidential SMS was not added due to security considerations. Support for other data types were also not implemented as it was out of the project scope.
3.3 Project Strategy
Prior to this project, the author had neither been exposed to the field of Android/Java programming nor cryptography techniques. Hence, there was a need to quickly get up to speed in terms of proficiency in order to accomplish the task at hand.
The project was implemented through several key stages:
Figure 11: Project Timeline
3.3.1 Phase 1: Beginning Android
The Hello, World tutorial [13] was used as a fundamental stepping stone towards Android programming. It served as a guide for the author to setup the programming (Eclipse Helios) and testing (Android Emulator) environments used for Android. The author also performed several other tutorials from the same site to get familiar with the interface.
3.3.2 Phase 2: Research
In Phase 2, the author sought to equip himself with the required knowledge of cryptography techniques, particularly on the subject of ECDH, through readings provided by C.W. Chan as well as off the Internet. He also attempted to identify and found the reason why the Bouncy Castle API was previously unsuccessfully implemented.
28
3.3.3 Phase 3: Rapid Prototyping
The author then began work on WaveCrypt by applying the prototyping model of software development.
Figure 12: Prototyping Model of Software Development [14]
The aim was to quickly get acquainted with the existing software from the previous projects, as well as to begin preliminary coding. A key focus during this phase was to get the ECDH algorithm up and running.
Figure 13: ECDH Encryption Screen
To do so, a test page was created that allowed a user to simulate key exchange between two parties and perform encryption and decryption of a plain text message. Once this was
29
complete, the author then proceeded to add the SMS messaging capabilities between two devices.
3.3.4 Phase 4: Spiral Development
The second development phase of the project followed the spiral model of software development. The spiral model follows the same five step cycle of the prototyping model but adds an additional risk analysis component at the end of each cycle to assess the project before continuing on the next development cycle.
Figure 14: Spiral Model of Software Development [15]
In this phase, the ECDH components were integrated with the SMS functionality to allow two users to share keys and encrypted messages. At the end of each development cycle, the author met up with C.W. Chan to assess the project. The project underwent three development cycles in this phase:
1. Key functionality (SMS/Key Share/Encryption/Decryption) was implemented2. Project codes were tidied and integration functions with the other group members’
projects were defined3. Transition of ECDH Encryption to use named curves was done
30
A fourth development cycle, which involved the integration of the author’s part of WaveCrypt with the others’ projects, was planned. However, it was not implemented due to time constraints.
3.3.5 Testing, Report & Presentation
The final project phase involved extensive testing of the completed portions that cover user interface, navigational, and performance testing. It also covers the preparation of this report as well as the oral presentation.
3.6 Design Methodology
Figure 15: Sequence Diagram for Encrypted SMS
Figure 15 illustrates the workflow for setting up a confidential SMS session between two parties. Before both parties begin the process, they first agree on the type of curve to be used (not shown). After which, either party can begin the process.
To begin, the sender first generates his key pair. He then sends a SMS containing his public to the receiver. On receipt of the key, the receiver then generates her key pair (if not
31
already generated) and sends her public key to the Sender. Following that the receiver will generate the shared secret and is ready for the encrypted SMS session.
Once the sender receives the public key of the receiver, he generates the shared secret and is also ready to trade encrypted SMS.
Chapter 4: Implementation
4.1 System Specifications
The specifications of the workstation for implementation of the project are as follows:
Workstation Model: Fujitsu Lifebook T5010
Processor: Intel Core 2 Duo T8700 2.53GHz
Operating System: Windows 7 Ultimate 32-bit OS
Eclipse SDK: Eclipse Helios for Java Developers with Android ADT plug-in
Android SDK: Android 2.3.3 Gingerbread
Java Version: 6
The specifications of the test environment of the project are as follows
Functional Testing: Android Emulator
Performance Testing: Android Emulator, Samsung Galaxy SII [SGS2] (Dual-core 1.2 GHz Cortex-A9 on Android 2.3.3)
32
4.2 ECDH Encryption
4.2.1 Initial Implementation
Figure 16: Defining the Elliptic Curve
Initially, the ECDH algorithm was defined as shown in Figure 16. The author found that it was impossible to implement ECDH-571 defined over F2m field due to the low computational efficiency of the algorithm. When run on the Android emulator and the physical test unit, it was found that the key generation time ran in the excess of 50 seconds.
This was unacceptable as such long delay would cause inconvenience to users, making it undesirable for use. Hence, the author opted to make use of another curve defined over the Fp field. This curve had lesser security strength than the ECDH-571 and was faster to run; hence it was adopted for use.
4.2.2 Usage of Named Curves
When performing the third development cycle, the author discovered the use of named curves for the implementation of ECDH. Named curves are predefined curves that are recommended under NIST, SEC, X9.62, Teletrust specifications etc.
On switching over to named curves, the author discovered that such curves were much more efficient in terms of computation speed (See Section 5.3.1 for details). Not only that, the author discovered that size of the generated key was much smaller for similarly defined ECDH parameters.
An example is the “prime239v1” parameter. Using the method in the initial implementation, the key size was 329 characters. However, upon using named curves, the author found that the generated Base64 key size had shrunk to 116 characters. This meant that the number of SMS sent for key exchange for one party would drop from three SMS to only one SMS, which is a great improvement.
33
Hence, the author opted to use named curves due to the benefits of computational efficiency and shorter key size.
4.2.3 Final Implementation
In this final implementation, we make use of named curves to perform the ECDH encryption process:
Figure 17: Code for Specifying Security Provider and Generating ECDH Key Pair
Before we begin the encryption, we have to first specify the security provider class inside the activity class. Note that it is still the BouncyCastleProvider class.
We then call the KeyPairGenerator and specify the type of encryption we will be doing (ECDH) and the provider (SC). Once that is done, we specify the elliptic curve to be used. As we are using named curves, we call the ECGenParameterSpec and specify the named curves listed in Section 4.2.2.
We then initiate the curve and generate the key pair. The system will take different amounts of time to complete the initiation and generation depending on the type of curve specified.
34
Finally, we encode the public key using the X.509 certificate and convert it to a Base64 character set to prepare for transmission.
35
4.2.4 Supported Parameters
The following are a list of selected named curves for WaveCrypt:
Table 2: Selected ECDH Parameters
Curve NameSize (bits)
Key Pair Generation
(ms)
Shared Secret Generation
(ms)
Base64 Key Size
Organization Field
brainpoolp160t1
160 1310 1395 92 TeletrustFp
prime239v1 239 2428.7 2095.2 116 ANSI X9.62 Fp
P-521 521 7112.6 6460.3 212 NIST Fp
c2pnb163v2 163 4016.5 3358.9 92 ANSI X9.62 F2m
sect409r1 409 23243.1 23119.3 172 SEC F2m
sect571r1 571 50029.4 52079.4 228 SEC F2m
The author made a selection of six named curves to implement in the application. Three curves were selected which utilized the Fp field and another three for the F2m field. To allow for a balanced selection, the author chose from each field type: one key that could be generated the fastest, one that had the highest security level, and one at random from the middle ranges.
Note the highlighted generation times for the curves in Table 2. It can be clearly seen that the difference in generation timings for the least secure parameter “brainpoolp160t1” and the most secure parameters “sect571r1” (ECDH 571) is of a great difference in magnitude.
For full list of curves tested on the Android Emulator, refer to Appendix E.
36
4.3 SMS Activity Screen
Figure 18: SMS Activity Screen
The SMS activity screen is a key aspect of the project. Through this screen, a user is able to:
1. Search for a contact via Android or WaveCrypt (future implementation) contact lista. Via the Contacts Search Button b. Via long clicking on the Contacts Field
2. Manually input contact number 3. Select type of SMS to send
a. Normal (unencrypted SMS)b. Internal (future implementation)c. Confidential (encrypted via ECDH+AES/DES)d. gAlgorithms (future implementation)
4. Send/Cancel an SMS 5. Send public key to other party6. Encrypt a SMS 7. Generate user key pair via Confidential SMS Screen
Circled numbers represent the inputs (as per Figure 14) to initiate task.
37
See Appendix B for WaveCrypt storyboard.
4.3.1 Sending SMS
Currently WaveCrypt supports 2 modes of SMS communication, Normal and Confidential. Users select the SMS type via the drop down list in the SMS activity screen.
Normal SMS does no intermediate processing and sends the SMS as it is. For Confidential SMS, it goes through several layers of verifications and processing before it is sent.
Figure 19: Activity Diagram for SMS Activity (Abbreviated)
Figure 19 illustrates the abbreviated activity flow for Confidential SMS (Refer to Appendix C for full diagram of both Normal and Confidential SMS). When a user clicks the ‘Send’ button, the system will verify if both parties had shared keys prior to this message.
If keys were shared then encryption will proceed using the shared secret key and the message sent to the receiver.
If keys were not shared, the phone will send the user’s public key (assume prior generated) to the other party. It will then verify if it already has the public key of the other party and will generate the shared secret if it has the key.
The verification step is done as a safeguard in case a user regenerates his key pair. In this scenario, the sender will resend his public key to the receiver, but the receiver will not
38
resend the key because she has not regenerated her key. Hence, the sender has to refresh his shared secret to match that of the receiver’s updated shared secret.
39
4.3.2 Key Sharing
Figure 20: Activity Diagram for shareKeys Method
When the shareKeys method is called, the system first determines if the user’s private key has been prior set. If it has not been set, the system will call up the preferences screen to allow the user to generate his key pair.
Once the keys have been generated, the user is able to share his key with another recipient via SMS. The system will verify the public key size and determine the number of SMS to be sent.
As each SMS is limited to 160 characters, the author has opted to break keys longer than 150 characters into separate SMS. The remaining 10 characters are reserved as headers to identify the type of SMS sent. The author decided to refrain from using Android’s multipart SMS feature as it was error prone. Instead, the receiver side is equipped with mechanisms to detect and join the SMS.
40
4.4 Preferences Screen
The Preferences Screen allows the user to set various preferences for Confidential SMS as well as perform the key pair generation.
Figure 21: Preferences Screen
When the user invokes the Preferences screen either from the Settings or SMS screen he is presented with the screen as in Figure 21.
The user main key generation button is located at the top of the screen. On clicking the button, the system will generate or regenerate the key pair. Once it is generated, the button will toggle green to notify the user that the key is generated.
Seamless Access is a feature introduced into WaveCrypt to make the key sharing process transparent to the user. When enabled, the systems for both parties will automatically generate the shared secret without the user needing to click anything.
The final preference selectable by the user is the ECDH Type. It allows the user to select from a list of supported ECDH parameters according to those highlighted in Section 4.2.4. It is important to note that once a user clicks on the ECDH Type, the private key will be reset, and users have to regenerate the key.
41
4.5 Receiving SMS
Figure 22: Activity Diagram for SmsReceiver Activity (Abbreviated)
The abbreviated activity diagram for SmsReceiver activity is shown in Figure 22. See Appendix D for full diagram.
When an SMS is received by the phone, the message is parsed according to the SMS header located in first four characters within the SMS payload. Only encrypted SMS or keys will contain headers.
Table 3: SMS Headers
Header Description Value ReturnedPT0= Full ECDH Key FULLKEYPT1= Partial ECDH Key 1 of 2 -PT2= Partial ECDH Key 2 of 2 KEYMSG= Encrypted Message MSG
Once it is determined what kind of message it is, the appropriate activities will be called to further parse the incoming SMS message. When a key type of SMS is received, the SmsKeyShare activity is called which allows the receiver to generate his private key and send it to the Sender, as well as to generate the shared secret key.
When a message type of SMS is received, the system will invoke the DisplayMessage activity to process the SMS (for encrypted SMS) for viewing by the receiver.
42
43
4.5.1 SmsKeyShare Screen
Figure 23: SmsKeyShare Activity Screen
The SmsKeyShare screen is opened automatically to a user when a public key comes in from another party. It should be noted that if Seamless Access is enabled, the user will not see this screen as everything is performed automatically.
When this screen is first invoked, the key display is initially empty. If the user has yet to set his key pair, the Shared Secret Generation button and Send Public Key button are greyed out (See ) to ensure the user first sets his key pair.
Once the keys are set, & are enabled for the user to click. The Shared Secret Generation button is greyed out once the shared secret is generated once. This is because the shared secret key will not change unless the user resets his own key pair or a new public key from the other party is sent.
It is recommended however that most users do not use this screen and enable Seamless Access instead. This screen should only be used for verification purposes when two users want to verify that they have the same shared secret key.
44
4.5.2 DisplayMessage Screen
Figure 24: DisplayMessage Activity Screen
The DisplayMessage screen is a simple screen that lets users view the messages that come in. Encrypted messages are decrypted before being displayed to the user. However, the decryption process is transparent to the user.
Both Normal SMS and Confidential SMS will appear through this screen. SMS is also stored on the Android messaging system. Normal SMS can be viewed by the user as plaintext on the Android messaging system. Confidential SMS on the other hand will be seen as a mass of random letters (See Section 5.2).
The WaveCrypt system does not keep copies of decrypted Confidential SMS. This is to ensure confidential messages are not compromised should the phone be separated from the user.
45
Chapter 5: Testing & Analysis
In this chapter, we will explore the various tests done by the author on the WaveCrypt system. We will also demonstrate step by step how the system is operated.
5.1 Functional Test
In this section, we will demonstrate how two way encrypted communications is achieved between users. To perform this operation, we set up two instances of the Android Emulator on the development platform, namely the Sender and Receiver. We then simulated two way communications. Note that some screenshots are cropped.
Screen DescriptionSender Receiver
1. Sender begins by initiating the application
2. Once loaded, Sender clicks on the Send SMS button.
1. Sender inputs the contact number of the receiver.
2. Composing an SMS message at this point is possible but not necessary.
3. Sender clicks the drop down list to select the type of SMS to send. In this case he selects Confidential SMS.
4. He then clicks the Send button.
46
Screen DescriptionSender Receiver
Key pair generated successfully
1. As Sender’s key pair was not previously input, he will be brought to the Preferences Screen.
2. Sender generates his key pair by clicking the Key Generation toggle button. The system will not respond for several seconds before turning the toggle button green.
3. As earlier mentioned, users are highly recommended to enable Seamless Access.
4. Sender can also select the ECDH Type to choose ECDH parameters. Both users must use the same ECDH Type
5. Once done, the key pair is generated, Sender should to return to the previous screen and click the Send button.
1. At this time, the key share screen will be displayed on Receiver’s side.
2. Receiver will click on the Set Private Key button and set the private key.
47
3. Once successful, the Generate Shared Secret button and the Send Public Key button should light up for Receiver to click.
4. Note: If Seamless Access was enabled, users will not encounter this screen.
Screen DescriptionSender Receiver
1. Receiver clicks the Generate Shared Secret Key button and the Send Public Key button to generate the shared secret and send public key to Sender.
2. Sender will receive the public key and generate the shared Secret
3. If Seamless Access was disabled, both users can visually verify the shared secret. It should be the same for both parties. Encrypted SMS can now be sent.
1. Sender inputs message and clicks the Send button
2. Receiver will receive an encrypted message. WaveCrypt will decrypt the message before displaying it to user.
48
3. Receiver clicks the Reply button or the Back button to reply to Sender or dismiss the message
4. Take note that once the Back button is pressed the decrypted message cannot be retrieved again. This is a security feature in WaveCrypt
This guide performs the functional test of the encrypted SMS capabilities of WaveCrypt in sending, encrypting and decrypting SMS and should be taken as proof of concept.
49
5.2 Named Curve Performance Test
In this section, the author tested the efficiency of the BouncyCastle supported named curves. To do so, the author decided to create a separate application to perform the testing to minimize unnecessary setup time.
Figure 25: Named Curve Test Environment
The application tested two parameters, the first being the time taken to generate the key pair and the second, the time taken to generate the shared secret. In designing this test environment, the author made a single assumption that there was a possibility that two systems could, by chance, produce an exact same key pair.
Hence, the application first generated its own key pair and encoded its public key to Base64. It then decoded the Base64 key and used that key (his public key) in conjunction with his private key to perform the generation of the shared secret
Figure 26: LogCat Output
To measure the time, the author added timing parameters into the code which could measure the timings and output them via LogCat, which is Android’s logging and debugging tool. Figure 26 shows an excerpt of the LogCat logs. As can be seen the timings are for key pair generation (Generate EC) and shared secret generation (Generate SS) are separately logged.
In total, 55 different named curves (See Appendix E for full test results) were tested for their performance. All tested curves tested are BouncyCastle supported named curves.
50
5.2.1 Test Setup
The test was conducted in this manner:
1. For each curve, the test application was run 10 times.2. Results for each curve were tabulated and averaged.3. The entirety of this test was performed on the Android emulator environment.
5.2.2 Selected Test Results
(571) sect
571r1
(571)
B-571
(431) c2tnb431r1
(409) sect
409r1
(359) c2tnb359v1
(239) c2tnb239v1
(163) sect
163r2
(239) prim
e239v1
0100002000030000400005000060000
Key Pair Generation Shared Secret Generation
Figure 27: Comparison of Generation Speed (ms) of Selected Curves
Figure 27 shows a selection of eight curves from the pool of curves tested, the bracketed values represent the bit size of each named curve. See Appendix E for full test results.
As can be seen, the curve parameters utilizing ECDH 571 (sect571r1 & B-571) take up about 50 seconds to generate. This is much larger compared to the other curves of smaller bit size. Hence, the author determined that using this curve would not be practical in this implementation as the user would be forced to wait a much longer time.
Attention should be paid to the rightmost curve (prime239v1). This curve is generated using the finite prime field Fp instead of finite binary field F2m which is used for the other seven curves listed. It can be noted that the key generation speed is even faster than an F2m
curve of smaller bit size (sect163r2). This is favourable for the current implementation to ensure users do not have to wait too long. However, there is a compromise in the aspect of security strength of the key generated.
51
5.2.3 AES Performance Test Results
The author also performed an additional AES performance test to verify the high speed performance capabilities of symmetric key ciphers.
Figure 28: LogCat Output 2
To do so, the author added code that performed the encryption and decryption of the message “This Message Is Encrypted In ECDH”. This additional test was performed on the NIST B-571 named curve. The author chose this curve as it utilized ECD-571 parameters and therefore had the longest key size of 228 Base64 characters. It was assumed that a longer key size would result in the longest AES processing time.
The decrypted message would then appear in LogCat logs as shown in Figure 28.
Table 4: Processing Time (in milliseconds) for NIST B-571 ECDH Curve
Parameter Sample 1 Sample 2 Sample 3 Sample 4 Sample 5 AverageB-571 Key Generation 48742 49185 48006 48916 46991 48368B-571 Shared Secret 48265 48223 56592 51454 49212 50749.2B-571 AES Encryption 5 5 10 8 27 11B-571 AES Decryption 90 7 49 8 39 38.6
As can be seen in Table 4, the order of delay times for AES encryption/decryption is very much lower than the curve generation and shared secret generation time. This reinforces our reason for using a hybrid key system for encryption.
52
5.2 SMS Transmission
We take a look into the screenshots from Android’s messaging application to understand the transmission dynamics of the system.
Figure 29: Screenshots of Android’s Messaging App
By analysing the first four characters of each encrypted message, we are able determine the type of message it is. Messages with the “PTx=” headers are key type messages while messages with the “MSG=” header are encrypted text type messages.
Encrypted text messages are fully encrypted when sent over SMS. This can be seen in Figure 29 where the text after the message header (MSG=) is jumbled up and indiscernible. The message sent is “This Message Is Encrypted In ECDH”.
53
5.2.1 Message Transmission
It is important to note that the encryption overhead for the message is quite large. In reference to the message “This Message Is Encrypted In ECDH”, the actual text contains 33 characters while the encrypted message contains over 90 characters, or roughly 3 characters for each character encrypted.
If we note the limited size of SMS messages (160 characters), we realize that we are unable to cram much text into each message. In this case, multipart SMS may be the solution to sending longer messages.
However, the author has chosen to limit each message to the length of 1 SMS. This is due to the fact that SMS, when sent in multiple parts, is particularly error prone due to the speed at which the message parts are received. This may result in messages which cannot be decrypted due to corruption.
5.2.2 Public Key Transmission
In the case of public key transmission, the author allowed a public key to be transmitted over multiple SMS. This was due to the potentially larger size of keys generated from certain named curves. The author ascertained from the performance testing of supported named curves that curves with a bit size larger than 320 bits required multiple SMS for key sharing.
While the author refrained from supporting multi part SMS for messaging purposes, he permitted it for use for key sharing. This is because, unlike messages, once a shared secret is successfully generated between two parties, the probability of error is close to zero. On the other hand, messages are constantly traded between parties and is always different, hence the restriction.
54
5.3 Physical Device Test
The final test that the author performed was the physical device test. In this test, the author made use of a physical phone (a Samsung Galaxy S2 phone) instead of the Android emulator to test the application. The goal of this test was to verify that the application was able to function on a physical phone (performance parameters were not tested).
Figure 30: Sequence Diagram of Loopback Test
As the author had access to only one device, he performed a loopback test and sent his public key to his own number to simulate reception of a public key from another party. He then generated the shared secret key and sent an encrypted message to his number. The loopback message would then be decrypted by the system and displayed to the user.
This test was completed successfully on the physical phone.
55
5.3.1 Physical Device Test Results
The physical device test using the Samsung Galaxy S2 generated some interesting results.
Initially, the test was first performed using the manually defined ECDH 571 parameters. This produced less than stunning results. In addition to taking a long time to generate (>50 seconds), the key size generated was very large, spanning more than the length of five SMS messages. This led to the author abandoning the idea of using the ECDH 571 parameter as it was too impractical for use.
However, when the author attempted to do a physical device test on the second go, using named curves, the author was surprised to find that the key generation took much less time than before, or slightly over five seconds. Most other ECDH parameters of smaller size were generated almost instantaneously. This was a big leap in terms of performance. And, while the ECDH 571 still took a significant amount of time, it was much more bearable than before.
Through this test, the author concluded that the usage of named curves was a correct approach as it enabled much higher performance than the previous setup. However, the author also attributed the performance leap to the device capability of the Samsung Galaxy S2, which was, at the time of writing, one of the more powerful Android mobile devices in the market.
56
Chapter 6: Conclusion and Recommendations
6.1 Conclusion
Mobile phones have become an irreplaceable communication tool for many people around the world as it allows users to be connected to each other via phone calls or messaging (SMS), no matter which part of the world they are. Smartphone, in particular, have slowly gained market share as they provide an extended amount of communication features such as Internet communication. However, as communication channels increase, so do the chances of personal data theft. There is an ever growing need for provision of secure mobile communications.
To address this imminent security flaw, the WaveCrypt project was designed to provide a suite of secure mobile communication channels. In this implementation of the project, the author focused on the generation of secure SMS functionality of the system through the use of the Elliptic Curve Diffie-Hellman (ECDH) and Advanced Encryption Standard (AES) to provide secure communications on the Android mobile platform.
In this implementation, the author successfully performed an overhaul of the encryption system from previous implementations by integrating the BouncyCastle API to perform the ECDH encryption. In doing so, it addressed the limitations of the previous implementations in which two users wishing to perform secure communications using ECDH required an additional known password between them to perform the generation of the shared secret, effectively making the system more of a symmetric encryption system than the hybrid model proposed. In addition, the author was able to provide users with a range of named elliptic curves of different size and security strengths to perform the encryption with.
The author also managed to perform several tests, namely the functional and physical device test, which allowed the author to verify that the application was working according to the author’s requirements, as well as the named curve performance test. The performance test gave the author a clearer picture of how efficiently (time-wise) each parameter could perform the generation of the key pair and shared secret key necessary for the encryption process.
In conclusion, the author has successfully developed an application that is ready to be used to perform secure SMS transactions between users.
57
58
6.2 Recommendations for Future Work
As previously mentioned, the WaveCrypt project was broken down into several functional parts which were worked on by a team of students. Hence, the author deliberately left out several components awaiting integration with the other project parts.
The author recommends several improvements to the system for future works:
Integration of a contact list for storage of shared keys Moving the ECDH generation functionality to a physical server Improvements to UI, particularly in the management of activity screens Inclusion of multipart messaging
6.2.1 Contact List Integration
In the current implementation of the project a user is only capable of talking to a single party at a time using confidential SMS. By integrating a contact list, a user would be able to store the shared secret keys used for encryption. In this way, a user could interchangeable load shared secret keys depending on the other party he is talking to.
The author has reserved the checkKeysShared() method inside the Sms.java class for this purpose.
Refer to FYP project code A3025-111 for details of the contact list implementation.
6.2.2 ECDH Generation on Physical Server
The current limitation of WaveCrypt is its ability to handle larger ECDH parameters such as the ECDH 571 due to the large amount of time required to generate the key pair and shared secret, which would make usage of more secure parameters less attractive. A solution to this would be to shift the key generation to a dedicated physical server. The server would generate the key pairs as well as the shared secret key for users and send the shared secret key to both users who request them for confidential communication purposes.
This would effectively free the mobile phone from performing the more complex and time consuming task of key generation, leaving it to focus solely on encryption and decryption of messages using the more effective symmetric key encryption methods like AES
59
Refer to FYP project code A3026-111 for details of the implementation of the physical server.
6.2.3 UI Improvements
The author notes an issue in the system when multiple SMS are sent to the user in succession and the user does not respond immediately. This issue would lead to having multiple screens popped up; whereby the user has to manually close them one by one. The author recommends developing a screen that can handle multiple SMS at once to reduce the need for the user to continuously dismiss messages.
6.2.4 Multipart Messaging
As previously mentioned in the report, the author refrained from allowing multipart SMS to be sent by the user, instead restricting users to 1 SMS size per message, due to multipart SMS being corruption prone, hindering the decryption process.
The author suggests inclusion of a message storage bank which is able to hold messages temporarily until all message parts arrive. Once that happen the system will join the parts up and ready it for decryption.
60
Bibliography
[1] C. W. Chan, “EE4758 Computer Security: L6 Public-Key Cryptography,” Nanyang Technological University, 2010.
[2] C. W. Chan, “EE4758 Computer Security: L3 Secret-Key Cryptography,” Nanyang Technological University, 2010.
[3] NIST, “Key Management,” 3 May 2011. [Online]. Available: http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-57Part1-Revision3_May2011.pdf.
[4] Wikipedia, “Diffie-Hellman key exchange,” 2011 December 2011. [Online]. Available: http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange. [Accessed 5 December 2011].
[5] Bloomberg, “Bloomberg Businessweek,” Bloomberg, 17 August 2005. [Online]. Available: http://www.businessweek.com/technology/content/aug2005/tc20050817_0949_tc024.htm.
[6] Open Handset Alliance, “Open Handset Alliance FAQ,” November 2007. [Online]. Available: http://www.openhandsetalliance.com/oha_faq.html.
[7] Gartner, “Gartner Newsroom,” Gartner, 15 November 2011. [Online]. Available: http://www.gartner.com/it/page.jsp?id=1848514.
[8] Wikipedia, “Bouncy Castle (cryptography),” 20 October 2011. [Online]. Available: http://en.wikipedia.org/wiki/Bouncy_Castle_%28cryptography%29.
[9] Android Developers, “Android 2.3 Platform Highlights,” Google, December 2010. [Online]. Available: http://developer.android.com/sdk/android-2.3-highlights.html.
[10] R. Tyley, “Spongy Castle - a repackage of Bouncy Castle for Android,” August 2011. [Online]. Available: https://github.com/rtyley/spongycastle#readme.
[11] H. B. Then, “FYP A3033-101: Elliptic Curve Diffie-Hellman 571 on GoogleTM
61
Android,” Nanyang Technological University, 2011.
[12] M. Y. Tay, “FYP A3229-102: Encrypted Smartphone - Elliptic Curve Diffie-Hellman 571,” Nanyang Technological University, 2011.
[13] Android Developers, “Tutorials: Hello, World,” [Online]. Available: http://developer.android.com/resources/tutorials/hello-world.html.
[14] H. B. K. Tan, “Part 1 - Software Requrements Analysis, Design and Testing,” in EE4001/IM2001 Software Engineering, Nanyang Technological University, 2011.
[15] B. W. Boehm, “A Spiral Model of Software Development and Enhancement,” TRW Defence Systems Group, California, 1988.
[16] C. Paar and J. Pelzl, “Understanding Cryptography,” 3 November 2009. [Online]. Available: http://www.crypto-textbook.com.
62
Appendix
Appendix A: Related WaveCrypt Projects
Project Number
Project Title Student Year
A3023-111 Real-time 256-bit Military-Grade Encrypted Voice over IP (VOIP) Software on Android
Penglin 2011/12
A3025-111 Secure Mobile Application on Google™ Android
Lee Chun Fong 2011/12
A3026-111 Two-Factor Authenticating against App Engine from an Android App
Boon Wenjie 2011/12
A3027-111 Development of Text-To-Speech Applications for Mobile Commerce on Google™ Android
Teoh Jonathan 2011/12
A3028-111 SMS Mobile Encryption on Google™ Android
Ong Chai Seng 2011/12
63
Appendix B: WaveCrypt Storyboards
64
65
66
67
Appendix C: Activity Diagram of SMS Activity
Figure 31: Activity Diagram for SMS Activity
68
Appendix D: Activity Diagram of SmsReceiver Activity
Figure 32: Activity Diagram of SmsReceiver Activity
69
Appendix E: Named Curve Efficiency Test Results
Table 5: ANSI X9.62 Named Curves Over Finite Prime Field Fp
Named CurveSize (bits)
Key Pair Gen (ms)
Shared Secret Gen (ms)
Base64 Key Size
prime192v1 192 1946.1 1867.7 100prime192v2 192 1977.8 1604.8 100prime192v3 192 1771.1 1565.4 100prime239v1 239 2428.7 2095.2 116prime239v2 239 2427.3 2070.4 116prime239v3 239 2421.4 2103.1 116prime256v1 256 2618 2269 124
Table 6: SEC Named Curves Over Finite Prime Field Fp
Named CurveSize (bits)
Key Pair Gen (ms)
Shared Secret Gen (ms)
Base64 Key Size
secp224r1 224 2059.1 1968.7 108secp256r1 256 2487 2268.1 124secp384r1 384 4559.9 4042.6 160secp521r1 521 6888.5 6343.3 212
Table 7: Teletrust Named Curves Over Finite Prime Field Fp
Named CurveSize (bits)
Key Pair Gen (ms)
Shared Secret Gen (ms)
Base64 Key Size
brainpoolp160r1 160 1535.6 1451.9 92brainpoolp160t1 160 1310 1395 92brainpoolp192r1 192 1694 2010 104brainpoolp192t1 192 2335.9 2543.9 104brainpoolp224r1 224 2199.6 2403.5 112brainpoolp224t1 224 2282.3 2298.2 112brainpoolp256r1 256 2943.3 3608.1 124brainpoolp256t1 256 2966.9 2900.4 124brainpoolp320r1 320 4650.3 4973.4 144brainpoolp320t1 320 4458.7 4477.8 144brainpoolp384r1 384 5054.4 5793.5 168brainpoolp384t1 384 5600.7 5394.9 168brainpoolp512r1 512 8830.7 12480.8 212
70
brainpoolp512t1 512 9370.3 10052.4 212
Table 8: NIST Named Curves Over Finite Prime Field Fp
Named CurveSize (bits)
Key Pair Gen (ms)
Shared Secret Gen (ms)
Base64 Key Size
P-224 224 2083 1934.5 108P-256 256 2656.9 2360.1 124P-384 384 4462.5 4120.5 160P-521 521 7112.6 6460.3 212
Table 9: ANSI X9.62 Named Curves Over Finite Binary Field F2m
Named CurveSize (bits)
Key Pair Gen (ms)
Shared Secret Gen (ms)
Base64 Key Size
c2pnb163v1 163 4077.2 3435.4 92c2pnb163v2 163 4016.5 3358.9 92c2pnb163v3 163 4045.4 3306.2 92c2pnb176w1 176 4302.1 3382.5 96c2tnb191v1 191 5148.6 4494.1 100c2tnb191v2 191 5140.2 4456.9 100c2tnb191v3 191 5101.9 4641.8 100c2pnb208w1 208 5723 4894.9 180c2tnb239v1 239 8028.5 7372.4 116c2tnb239v2 239 8252.6 8059.2 116c2tnb239v3 239 8139.1 7565.4 116c2pnb272w1 272 9894.6 9763.5 128c2pnb304w1 304 12741.9 11315.2 140c2tnb359v1 359 19800.2 18068.5 156c2pnb368w1 368 17887.5 17358.2 160c2tnb431r1 431 24257.5 24594.7 184
71
Table 10: SEC Named Curves Over Finite Binary Field F2m
Named CurveSize (bits)
Key Pair Gen (ms)
Shared Secret Gen (ms)
Base64 Key Size
sect163r2 163 3973.7 3452.8 88sect233r1 233 7459.5 6932.6 112sect283r1 283 10854.4 10365.9 128sect409r1 409 23243.1 23119.3 172sect571r1 571 50029.4 52079.4 228
Table 11: NIST Named Curves Over Finite Binary Field F2m
B-163 163 4214.5 4067 88B-233 233 8529.6 7758.9 112B-283 283 12585.8 12117.6 128B-409 409 26766.2 25521.6 172B-571 571 51318.5 52227 228
The above results are performed using the Android Emulator and hence should only be used to benchmark between curves. Actual device performance varies from device to device depending on hardware processing speeds.
Please refer to the following sites for more information about ECC curve parameters
SEC: http://www.secg.org/collateral/sec2_final.pdf
NIST: http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf
ANSI X9.62 Fp: http://www.flexiprovider.de/CurvesGf2mX962.html
ANSI X9.62 F2m: http://www.flexiprovider.de/CurvesGfpX962.html
Teletrust Brainpool: http://www.ecc-brainpool.org/download/Domain-parameters.pdf
72