University of Cambridge 15 JJ Thomson Avenue Cambridge - UK - CB3 0FD
[email protected], [email protected]
Abstract. An application was completed that runs on the Android mobile phone platform. The application allows its users to send and receive text messages that are encrypted with the Advanced Encryption Standard using hashing algorithms or Elliptic Curve Diffie-Hellman for key creation. Cer-tificates can also be created, signed, verified and sent to others using text messages. An anonymous remailer was also built to allow users of the mo-bile application to send text message anonymously. The remailer receives messages from a text gateway and sends them on using Mixminion to another remailer that then passes them on to the desired destination. The remailers use a custom made protocol and use cryptography to provide anonymity.
1. Introduction
SMS has limited security provided with it. Mobile phone companies and governments have the capability to view messages sent through networks within their jurisdiction, as well as performing traffic analysis on text messages sent. SMS also provides little security to third parties who may try to view text messages; messages are displayed on phones which have limited security to prevent attackers who have physical access to the phone. The GSM network phone company’s use for text messages is also protected by weak ciphers and has many security risks. This leaves its users open to attack.
The aims of this project were therefore to provide an application that allows you to encrypt text messages and send them anonymously. Preventing governments, companies and eavesdroppers from breaching your privacy. This project draws on several different subjects in computer security, typically cryptography, public key in-frastructure, certification schemes, Pretty Good Privacy and Anonymous Remailers. These are briefly explained below.
The cryptographic protocol used was Elliptic Curve Cryptography, which works by assuming that computing the discrete logarithm of a random elliptic curve is com-putationally infeasible [Stinson 2006]. The advantages of using ECC over other meth-ods such as RSA is that the key sizes needed for computationally secure encryption is
∗Project Supervisor
†Supported by CAPES Foundation/Brazil on grant #4226-05-4
much smaller than that of RSA. Elliptic Curve Diffie-Hellman [Barker et al. 2007], an ECC protocol, is used to create keys for symmetric encryption algorithms. Both the sender and receiver each have a private key and its corresponding public key which they share. The algorithm is designed so that the shared secret can be reconstructed if the sender has a private key and public key.
Pretty Good Privacy (PGP) [Pretty Good Privacy 2009] is an application that lets the user sign, encrypt and decrypt emails as well as implementing a web of trust for key distribution. The web of trust used in PGP is a certification system for validating whether or not a user really owns the private keys he claims to. Unlike the X509 system, where only a set certificate authority can sign certificates, the web of trust system lets anyone sign a certificate effectively making everyone a certificate authority. Each user can define people as trusted inducers.
An Anonymous Remailer is a server that receives and sends on messages in such a way to protect the identity of the sender. The main types of remailer servers are: Pseudonymous remailers, which simple take away the email address and place it with an alias [Chaum 1981]. Type I, for example CypherPunk. CypherPunk which takes encrypted messages, decrypts them and removes any header information, and then sends the message on. Type II for example Mixmaster. Mixmaster servers take fixed sized packets and reorder them before sending them on [MixMaster 2010]. Type III for example Mixminion. Mixminion splits messages up into smaller packages and then encrypts each one using the public keys of the servers it will be sent along in reverse order. Each server then decrypts a package it receives and then sends it on. The timing used to decide when a package is sent on is also controlled by the server for extra security. [George Danezis and Mathewson 2009].
2. Requirements Analysis
Three programs were created as part of the project, a mobile phone application to pro-vide users with secure communication, a remailer server to propro-vide users with anony-mous communication, and a key server to provide users with a list of all the remailers available to be used. A certification scheme was also produced to allow users to se-curely transfer keys.
The mobile phone application needed to satisfy a large list of functional re-quirements. Firstly it needed to integrate into the phone’s SMS service to send and receive text messages as well as finding a way to compress the messages sent. The application will need to use Advanced Encryption Standard to encrypt and decrypt text messages and use Elliptical Curve Diffie-Hellman to perform key exchanges and provide Public Key Infrastructure. It will also need to have a way to store certificates, as well as features that let you send, receive, verify and sign peoples’ certificates. Lastly there needs to be an option to let text messages be sent anonymously through the Anonymous Remailer servers. An additional non-functional requirement was that the application would be easy to use by those that have previous knowledge of public key cryptography.
The certification scheme used also needed to satisfy the following require-ments. It needed to be based on a Web of Trust system where people can sign each others’ certificates and verify them by seeing if anyone they trust has signed the certifi-cate plus provide a method to convert certificertifi-cates to a text message string, preferably being 140 characters long or less.
To provide the option to send texts anonymously from the phone application, an anonymous remailer server needed to be built that did the following. The sever needed to receives texts from an SMS gateway, it then calculates where to send them on and does so using Mixminion. The server would also need to be able to receive the server to server messages from Mixminion and calculate what to do with them next. The server also needs to be able to send text message through SMS gateways and onto their intended recipient. Lastly the remailer must not require the mobile phone application to perform any tasks that would be considered demanding.
A Key Server needed to be built that let remailer servers add and removes themselves from the Key Server, and use this information to provide a directory of online remailers for the mobile application to use. It would also need to cache this directory in case the Key Server shut down unexpectedly.
3. Phone Design
Figure 1. Compression Perfor-mance of LempelZivWelch and Huffman Encoding
The user was provided with 3 different options for encryption, in the following protocols S is the sender and R is the re-ceiver. AES encryption with a hashed password (K), S → R : {P ayload}K.
ECDH key exchange where the sender’s private key and the receiver’s public key are used to create a shared secret KSR,
S → R : {P ayload}KSR. ECDH key
exchange with the receiver’s public key and an ephemeral key (P ubx) are used
to create a shared secretKRx, S → R :
P ubx{P ayload}KRx. Using an already known private key as shown reduced the size
of the text message while using an ephemeral key allows the message to be sent anony-mously.
To reduce message sizes two compression algorithms were considered, Huff-man encoding and LempelZivWelch. HuffHuff-man encoding was considered as it is always known to be quite efficient, however typically used with large files [Huffman 1952]. LZW on the other hand may be perfect for small messages due it not needing a cod-ing table like Huffman [Welch 1984]. Applycod-ing the algorithms to a corpus of 653 text messages produced the table of results shown in Figure 1. The graph clearly shows that LZW is the better choice also guaranteeing to be smaller than to equal to the original text’s size unlike Huffman coding.
The Android mobile phone platform was chosen as it is free to use, mostly open source, provides full access to the phone, and lastly has functionality included which allows applications to send text messages [Google Coorporation 2009]. Since the encryption and decryption algorithms used work with raw bytes; the resulting raw bytes need to be turned into a String that is an acceptable text message. Short Message Services allows messages to be sent using a selection of encodings, though the typical one used in the west is the GSM 03.38 [ETSI 2009]. Base64 coding was chosen instead due to it being simpler and easily available.
Bouncy Castle [Bouncy Castle 2009] was selected as the cryptographic library due to it being a free open source product with an excellent reputation. It also contained all the functionality needed for performing cryptography and creating the certificate scheme.
4. Remailer Design
The remailer server has 4 main features, to receive and send texts, to receive emails and to send emails anonymously.The server host a web page which will be called by the third party text gateway when it receives a message. The web server then opens a new thread that performs the decrypting, parsing and sending of the message while the server continues to listen for more messages. For the remailer to receive anonymous messages, it needs to check its email and download any new messages. The server can easily iterate through all the downloaded messages decrypting and sending them on.
A protocol was designed for use by the remailer servers to provide anonymity. The protocol was developed to provide a way to send messages anonymously with-out it being computationally expensive for the mobile application. The protocol uses Mixminion [George Danezis and Mathewson 2009] to send messages betweenSy and
Sx and so was designed to be similar to Mixminion to reduce complications.
Mixmin-ion works by sending encrypted messages with separate encrypted headers for each server that handles the message so that each server doesn’t know the responsibility of the other servers. The protocol used by the remailer to provide anonymity is explained:
P →Sy :P ubSy{LSy, Sx, P ubSx,{LD, D, P ayload}KSx}KSy
Sy →Sx :P ubSx,{LD, D, P ayload}KSx
Sx →D:P ayload
WhereSy →Sxis a message sent anonymously,P is the sender,Dis the destination,
Sy is the first remailer,Sxis the second remailer,KSyis the AES key made fromP ubSy
and the private ECDH key forSy,KSx is the AES key made fromP ubSx and the private
ECDH key forSx,LD is the length in bytes of the destination phone number andLSx
states how long in bytesSxwill be.
This protocol above is designed to provide anonymity and confidentiality, it does not provide authentication, freshness, unicity and only partly provides key dis-tribution. Confidentiality is provided by making sure that all information is encrypted
and only accessible to those who need it using symmetric cryptography and ECDH for key distribution.
Anonymity is provided by making sure that at each stage the principles (ex-cluding the sender) only have limited information about where the message is being sent, and where it is from. Server y only knows who the sender is and the next server in the network, therefore he is unable to work out who the text is destined for. Server x does not know who the previous server was as the message was sent through an anonymous remailer, he only knows who the receiver is. The receiver only knows who Server x is, therefore knowing the message was sent anonymously. To stop people im-personating remailers or creating corrupted ones the key server should also be tightly controlled. Freshness and unicity could be implemented by adding timestamps to the protocol. Relay attacks are still an issue, if an attacker resends an encrypted message he can then monitor different suspected targets until he sees one of them receive the same message twice.
The text gateway used for this project was kindly donated by MX Telecom, the text gateway sends all received texts to a given web server in a GET request [MX Telecom 2009]. Mixminion was used as the medium to communicate between the anonymous remailer servers being developed. Mixminion is a well known and widely used anonymous remailer that has been peer reviewed intensively to make sure it provides the best security[George Danezis and Mathewson 2009].
5. Certificate Design
A custom certificate scheme is used in the project, this allows more focus to be placed on producing certificates that can be made as small as possible for sending via text messages. The aim was to produce a certificate scheme that uses a Web of Trust simi-lar to that used by PGP certificates. X509 or PGP certification schemes were not used since it was not possible to send the certificate chains required by the schemes in an SMS. The custom certificate scheme was therefore used to counter this problem. How-ever if there had been more time finding a way to use PGP certificates instead would have been desirable. Web of Trust was selected instead of a Certificate Authority sys-tem due to the need for anonymity. If a certificate needs to be verified by a Certificate Authority it will have to know basic details about the certificate and its user.
To make sure the certificate as small as possible, we should only store the minimum amount of information needed, therefore the certificate will consist of an id, the issuer’s common name, the subject’s common name, a start date, an expiry date, the public key of the subject, and a signature of the certificate signed by the issuer’s private key. It may not be possible to fit this into 140 characters since the key or signature alone could be larger than 140 characters however this is probably as small as we can get it. When a user receives a certificate he can then check if a verified chain using the recipient’s certificates can be formed. If so then the certificate is fine to be used, otherwise it will have to be used at the recipient’s discretion. When certificates that cannot be verified are sent, the sender and receiver can physically compare the
certificates to make sure that the certificate sent was correct. In this case the receiver knows that the certificate is valid and can be used and sign the certificate himself.
6. Key Server Design
The key server is going to be simple, as a complicated one will take too much time and the majority of effort was focused on the remailer’s communication security. Without a secure key server the entire network is at risk. However with a simple key server comes the requirement to closely monitor editing of the directory. Therefore the Key server’s implementation will be a simple website with a page for adding, removing and viewing remailer servers.
7. Implementation
The implementation of the three programs, the mobile phone application, the remailer server and key server was done to the requirements and designs stated above.
From the mobile application there are two noteworthy implementation choices to mention. Firstly a class called KeyHandler was created to handle all public and pri-vate keys used by the phone. This included the creation of keys, including ephemeral keys, and all access to the KeyStore used by the app. A second class called TextCer-tificate contained all the operations a user can perform on cerTextCer-tificates received via text messages or stored in the KeyStore. The app was also designed to retrieve the remailer directory from the Key Server. Servers were split into two types those that can receive texts and those that can send texts, where it’s possible for a server to be both types. Different heuristics can then be used to pick the two servers used for sending the text message anonymously. At the moment the only heuristic is randomly selecting two different servers, though others can easily be added. The GUI of the mobile phone application was kept as simple as possible, the graphics were kept simple due to time constraints, however the usability of the application was not neglected in the process.
Figure 2(a) is the activity displayed when the application is started. While this activity runs in the background the Key Store is set up for later use by the application. Figure 2(b) is the main page which displays all the text messages in the inbox and provides links to all other activities in the application. When a message is clicked on a dialogue box appears that will show the user the decrypted message or certificate details depending on the message type.
The activity in Figure 2(c) is used to send text messages through the applica-tion. The anonymous button toggles sending the text anonymously or not. When the users presses the send button a list of options appears to let the user choose (if any) which encryption method they wish to use. The key management activity shown in Figure 2(d) shows the public key and certificate information. The user then has the option to sign the contact’s key or send certificates via text message.
When importing the Bouncy Castle library into the android application sev-eral problems arose. The problems were caused by the Android JVM already having
(a) Introduction Activity (b) Main Activity (c) New Message (d) Certificate Activity
Figure 2. Activities Screenshots
Bouncy Castle imported to provide functionality for key stores but nothing else. The final solution was to work out which Bouncy Castle files were needed in the applica-tion, these were then included in the application. The package name was then renamed from org.bouncycastle to bouncycastle so that they didn’t clash, the security provider name which was also changed so that it didn’t clash with the operating system’s ver-sion of Bouncy Castle as well. After this was done the library worked without any problems. This problem required a lot of analysis and trial and error to solve, since there was very little documentation on the error messages provided.
The Remailer Server was split into three main sections, a HTTP server and HTTP client used for communication with text gateways, the Mixminion and SMTP clients used to communicate between Remailer Servers and lastly the cryptography library. The HTTP client and server are designed such that all implementations have the same functionality but are customised for the text gateway they use. The server works slightly different by having a separate HTTP handler defined for the gateway to be used as well. For alternative text gateways a class that performs similar functions would need to be built.
The main functions of the Key Server are performed by the AddFileHandler and RemoveFileHandler which add and remove new remailer servers from the remailer directory. The remailer server’s information is stored on the key server which works as a public directory.
8. Testing
Testing was done throughout development of both applications. All tests were per-formed on the android emulator in the preliminary stages after which all tests were performed on the HTC Hero. Testing the mobile application was done manually due to the fact the graphical user interface of the application was constantly changing dur-ing development. For the phone application white box and black box testdur-ing was used. For white box testing each possible code path in the application was identified and
tested. Received text messages are the only data parsed by the application and so a list of all the possible classes the text messages could fit under were identified and tested. Tests were also repeated after each working version for regression testing, to make sure new changes did not break old features. Testing for the remailer was done using JUnit Testing. Stress testing was also going to be performed on the remailer to see how it would react depending on the number of text messages sent through. However the server being used for the tests had a hardware failure before the stress testing.
Sending texts to and from the text gateway was expensive and difficult to auto-mate from a phone, to deal with this a separate application was written that sent and received the messages directly to and from the anonymous remailer. The application works by sending sample messages to the remailer at a set frequency which decreases by half every 10 messages. The frequency at which the remailer servers fail would also have been found. The Key Server is a conduit for data and never directly uses or edits the data, therefore the only testing done was to make sure that each page worked.
A detailed security review was also performed on the system. Flaws in the system and how the system can be improved were discovered and stated along with assurances and evidence for the parts of the system that are considered secure.
(a) The application provides a good quality way to encrypt and send messages using Advanced Encryp-tion Scheme
(b) The application provides a good quality way to encrypt and send messages using Advanced Encryp-tion Scheme with ECDH
(c) The certification scheme used to send and store certificates is an effective way to handle certificates and keys for a phone
9. User Feedback
(e) Out of 5 what would you rate the application
Figure 3. Evaluation Graphs
A user study was performed with some students at Cambridge University. An open beta version of the application was also released on the android market to al-low others to review and test the applica-tion. Since only the HTC Hero was used in testing this meant bugs only found on other mobile phones could be found. 13 users were invited to use the application without guidance, after which they were given a short demo and explanation of how it worked, they then filled out an evaluation form. Their results are shown on the graphs below. Each statement they
selected whether they strong agreed (SA), agreed (A), had no opinion (NO), disagreed (D) or strongly disagreed (SD).
Figures 3(a) and 3(b) show that all users felt that the cryptography provided was adequate. Though figures 3(c) and 3(d) show a few users didn’t like the certificate scheme and more felt the application wasn’t easy to use. The general consensus shown in figure 3(e) seemed to be positive, the average rating was 3.7, where the lowest was 3 and the highest was 4, which is a positive result. Some users also left suggestions for possible improvements. The user interface was commented on a lot with almost everyone thinking it needed improving. Since the focus of this project was to imple-ment the functionality the user interface was not given as much attention, but will be in the future. Suggestions included changing the font size, having a different colour font for headers and content, make encrypted text messages more obvious, adding field labels and the renaming of some of the dialog boxes buttons. Also whenever contacts are referred to their contact name is not shown, only their mobile number, to make the application easier to use it was also suggested that contact names be used.
9.1. Open Beta Feedback
After being on the android market place for about a month the open beta version of the mobile application had been downloaded 95 times and had 36 active installs. However the feedback form provided in the application was not used.
10. Work completed
The project has succeeded in producing both a working mobile application and re-mailer server. The mobile application fulfils the requirements stated in the preparation section, allowing its users to send and receive encrypted messages using AES and ECDH, as well as letting them send and store certificates. The certificate scheme was also implemented however producing a method to convert certificates to a string less
than 140 characters was not possible due to the signature itself exceeding this limit. With an alternative encoding format or better compression it may be possible to im-prove this. The remailer also fulfils all its requirements sending and receiving texts while performing encryption to provide anonymity, the key server was also imple-mented to the requirements set without any known bugs.
This project has a huge range of possibilities when it comes to further work. For the phone application these include improving the user interface to encourage more users to use the application and performing HCI and security research to improve the application to a point that people without significant cryptographic knowledge can use the program securely. The Key Server’s security also needs improving. At the moment the Key Server has a limited use of cryptography, to make sure that people cannot abuse the Key Server this would need to change. The certificates would also need changing, especially when providing users with a method for key revocation, and finding alternative ways to communicate certificates, the best way to do this would be to replace it with a PGP certificate system.
References
Barker, E., Johnson, D., and Smid, M. (2007). Recommendation for pair-wise key establishment schemes using discrete logarithm cryptography. NIST, page 41. Bouncy Castle (10/2009). The Legion of the Bouncy Castle.
http://www.bouncycastle.org/.
Chaum, D. (1981). Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM 24, pages 84–88.
ETSI (10/2009). GSM 03.38 to Unicode.
http://www.unicode.org/Public/MAPPINGS/ETSI/GSM0338.TXT.
George Danezis, R. D. and Mathewson, N. (10/2009). Mixminion: Design of a type iii anonymous remailer protocol. http://mixminion.net/minion-design.pdf.
Google Coorporation (10/2009). Android Reference, SMS Manager.
http://developer.android.com/reference/android/telephony/SmsManager.html. Huffman, D. (1952). A method for the construction of minimum-redundancy codes.
Proceedings of the I.R.E., pages 1098 – 1102.
MixMaster (05/2010). Mixmaster. http://mixmaster.sourceforge.net/.
MX Telecom (10/2009). MX Telecom SMS Gateway HTTP Interface. http://www.mxtelecom.com/uk/tech/sms/http.
Pretty Good Privacy (10/2009). Pretty Good Privacy. http://www.pgp.com.
Stinson, D. R. (2006). Cryptography Theory And Practice. ChapMan & Hall/CRC. Welch, T. (1984). A technique for high-performance data compression. IEEE
