SAMES - Short Anonymous Message Encryption Scheme

Transcription

1 SAMES - Short Anonymous Message Encryption Scheme David Anthony Read 1, Jean Everson Martina 1 1 Computer Laboratory University of Cambridge 15 JJ Thomson Avenue Cambridge - UK - CB3 0FD davidread@cantab.net, Jean.Martina@cl.cam.ac.uk 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. Certificates can also be created, signed, verified and sent to others using text messages. An anonymous r er was also built to allow users of the mobile application to send text message anonymously. The r er receives messages from a text gateway and sends them on using Mixminion to another r er that then passes them on to the desired destination. The r ers 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 infrastructure, certification schemes, Pretty Good Privacy and Anonymous R ers. 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 computationally infeasible [Stinson 2006]. The advantages of using ECC over other methods such as RSA is that the key sizes needed for computationally secure encryption is Project Supervisor Supported by CAPES Foundation/Brazil on grant #

2 72 Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG) 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 s 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 R er is a server that receives and sends on messages in such a way to protect the identity of the sender. The main types of r er servers are: Pseudonymous r ers, which simple take away the 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 provide users with secure communication, a r er server to provide users with anonymous communication, and a key server to provide users with a list of all the r ers available to be used. A certification scheme was also produced to allow users to securely transfer keys. The mobile phone application needed to satisfy a large list of functional requirements. 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 R er 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.

3 X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 73 The certification scheme used also needed to satisfy the following requirements. 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 certificate plus provide a method to convert certificates 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 r er 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 r er 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 r er servers add and removes themselves from the Key Server, and use this information to provide a directory of online r ers 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 The user was provided with 3 different options for encryption, in the following protocols S is the sender and R is the re- Figure 1. Compression Performance of LempelZivWelch and Huffman Encoding 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 K SR, S R : {P ayload} KSR. ECDH key exchange with the receiver s public key and an ephemeral key (P ub x ) are used to create a shared secret K Rx, S R : P ub x {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 anonymously. To reduce message sizes two compression algorithms were considered, Huffman encoding and LempelZivWelch. Huffman 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 coding table like Huffman [Welch 1984]. Applying 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.

4 74 Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG) 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 [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. R er Design The r er server has 4 main features, to receive and send texts, to receive s and to send s 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 r er to receive anonymous messages, it needs to check its 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 r er servers to provide anonymity. The protocol was developed to provide a way to send messages anonymously without it being computationally expensive for the mobile application. The protocol uses Mixminion [George Danezis and Mathewson 2009] to send messages between S y and S x and so was designed to be similar to Mixminion to reduce complications. Mixminion 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 r er to provide anonymity is explained: P S y : P ub Sy {L Sy, S x, P ub Sx, {L D, D, P ayload} KSx } KSy S y S x : P ub Sx, {L D, D, P ayload} KSx S x D : P ayload Where S y S x is a message sent anonymously, P is the sender, D is the destination, S y is the first r er, S x is the second r er, K Sy is the AES key made from P ub Sy and the private ECDH key for S y,k Sx is the AES key made from P ub Sx and the private ECDH key for S x, L D is the length in bytes of the destination phone number and L Sx states how long in bytes S x will be. This protocol above is designed to provide anonymity and confidentiality, it does not provide authentication, freshness, unicity and only partly provides key distribution. Confidentiality is provided by making sure that all information is encrypted

5 X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 75 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 (excluding 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 r er, 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 impersonating r ers 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 r er servers being developed. Mixminion is a well known and widely used anonymous r er 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 similar 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. However 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 system 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

6 76 Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG) 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 r er 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 r er servers. 7. Implementation The implementation of the three programs, the mobile phone application, the r er 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 private 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 TextCertificate contained all the operations a user can perform on certificates received via text messages or stored in the KeyStore. The app was also designed to retrieve the r er 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 application. 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 several problems arose. The problems were caused by the Android JVM already having

7 X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais 77 (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 application, 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 version 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 R er 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 R er 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 r er servers from the r er directory. The r er 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 performed 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 during development. For the phone application white box and black box testing was used. For white box testing each possible code path in the application was identified and

8 78 Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG) 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 r er was done using JUnit Testing. Stress testing was also going to be performed on the r er 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 automate from a phone, to deal with this a separate application was written that sent and received the messages directly to and from the anonymous r er. The application works by sending sample messages to the r er at a set frequency which decreases by half every 10 messages. The frequency at which the r er 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 (b) The application provides a good quality way to encrypt and send messages using Advanced Encryption Scheme tion Scheme with encrypt and send messages using Advanced Encryp- ECDH (c) The certification scheme used to send and store certificates is an effective way to handle certificates and keys for a phone (d) The application is simple and easy to use

9 X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais User Feedback 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 allow others to review and test the application. 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 (e) Out of 5 what would you rate the application how it worked, they then filled out an evaluation form. Their results are shown Figure 3. Evaluation Graphs 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 implement 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 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 r er 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

10 80 Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG) 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 improve this. The r er also fulfils all its requirements sending and receiving texts while performing encryption to provide anonymity, the key server was also implemented 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. Chaum, D. (1981). Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM 24, pages ETSI (10/2009). GSM to Unicode. George Danezis, R. D. and Mathewson, N. (10/2009). Mixminion: Design of a type iii anonymous r er protocol. Google Coorporation (10/2009). Android Reference, SMS Manager. Huffman, D. (1952). A method for the construction of minimum-redundancy codes. Proceedings of the I.R.E., pages MixMaster (05/2010). Mixmaster. MX Telecom (10/2009). MX Telecom SMS Gateway HTTP Interface. Pretty Good Privacy (10/2009). Pretty Good Privacy. Stinson, D. R. (2006). Cryptography Theory And Practice. ChapMan & Hall/CRC. Welch, T. (1984). A technique for high-performance data compression. IEEE Computer, pages 8 9.