Atlantis - Design Document
Secure Messaging with OTP
Ricardo MatsuiJonathan VronskyDan SeeAndrew Brandes
Summary
This document provides background and details on the implementation of One Time Pads (OTPs) in a secure messaging application. The goal is to provide secure end-to-end messaging that is fairly convenient and guarantees that your data will not be decrypted.
Introduction - Why One Time Pads?
In any secure environment, users need a way to transfer data securely over a network. The users can’t use the internet because they assume that the internet/public network isn’t to be trusted. They operate under the assumption that all the data they send over it can be intercepted and read. By using encryption, the users can secure any data, but it’s only as strong as the encryption used. The more data they send, the easier it is for a malicious user to decrypt and gain access. OTPs tries to solve this by providing secure transfer that can’t be decrypted even if all of the data is intercepted. But for this to work, users need to transfer the OTPs over short range secure methods.
Background
A one-time pad is an encryption technique that can’t be cracked if used properly. It works by pairing plaintext with a random key (or pad). We combine each bit of the text with the corresponding bit of the pad with modular addition. Since the pattern is never reused, and the pad is truly random, it will be impossible to decrypt without the same pad.
Design Goal
Our goal is to create an application to guarantee the secure, end-to-end transmission of a message using the one time pad technique to encrypt the message and related server infrastructure to exchanges messages between devices running the app. We want to create this mobile application in addition to an accompanying server that fields the transmission and delivery of these messages. The application should show the users multiple recipients that they can send to, and allows an easy process for starting a new OTP exchange/conversation with another user. The OTP should be generated relatively quickly and have the encryption and decryption logic built in.
The Platforms
1. Android: We choose to develop this system primarily for android, due to the high market volume and a very friendly development process. It is free to develop and to publish which helps keep costs to a minimum.
2. iPhone: We have plans to expand our working product to the iPhone is it is feasible. The downsides include a cost to develop and the fact that they only run Bluetooth Low Energy. We will also have to modify the android java code for use in Objective-C.
OTP Transfer Medium
1. Bluetooth: Easiest way to transfer the OTPs between phones. It only requires you to be fairly close to the corresponding device, and no additional parts needed. We also implemented a system that error checks the data being sent and has a resend option. This will guarantee delivery even for larger file sizes. However, large OTPs (>10MB) can have long transfer times, which is undesirable. In terms of security, bluetooth is much more secure than the network, but it is not perfect. Malicious users can gain access to the data with use of specialized equipment if they are nearby.
2. Cable: Another very easy way but requires the use of additional piece that needs to be obtained elsewhere. It requires physical interaction and something additional. You could either use a computer as an intermediary, a male to male AUX cable, or a female usb cable to connect the two phones directly. This takes away from the convenience factor but could be useful for exceptionally large OTPs because we could transfer them much faster. It makes for a good secondary transfer method.
3. SD Card: Very similar to the cable, as it requires a separate item. Potential to be very useful for large OTPs and makes it easy to transfer between people. The problem is that not all platforms (i.e.: iPhone) support SD cards. It requires more user knowledge and can be a bit of a hassle. Users would have to be able to install and remove SD cards from their individual phones.
Generation of OTPs
To generate the OTPs we make use of the Secure Random function found in Java. This function provides a way to generate a non-deterministic random value. This approach makes it nearly impossible to reproduce the seed and the output. We use this approach to generate an OTP that is a merely a file of random data. By encrypting the data being sent with this, character by character, we create a ciphertext that can’t be decrypted without the OTP. This OTP can also be used as an addressing system for the messages. Because we want to keep it anonymous without permanent addresses, we adapted our system to use a small part of the OTP for every message you send as an address. Because both users in a conversation have the OTP, the receiving device can “listen” at that address for messages on the server. While we could use a separate OTP for this operation, we decided that it would be most efficient if both pulled from the same OTP. To keep the OTPs safe on the phones, they will be encrypted into a database and retrieved only when the corresponding conversation is in use.
Local Device Storage
To store data on the device, we are planning on using an OrmLite SQL database. This allows us to store the applications data in a straightforward and logical way. We plan to make use of a schema as shown below. By following this, we can set up our data in an easy to access and manage way. In this way, we can link conversations to multiple OTPs which in turn will be linked to people. Each person can have multiple OTPs but a single OTP can only belong to a single person. Messages are simply a part of the conversation but also keep track of whether a message has been read and if it needs to notify the user.
Schema Diagram
Local Encryption
In order to protect the users data on the phone, we plan to implement a pin lock system. We will use the pin to generate a random string that is used to encrypt the data and the checksum. When starts the app and enters in their pin, we will decrypt these values and compare the checksum to ensure that the decoding was done properly. This offers protection for the data on the phone for the user. We also want to give the user the option to delete data upon a number of failed pin attempts.
User Interface
Our main page will give the user a few choices: Existing Conversations, New Conversation, and settings. Existing conversations is merely the conversations that have already had OTP exchanges and are ready to send. The page will let the user know how much of the OTP remains and offer a simple chat UI. The new conversations panel will allow the user to start off a OTP exchange with options letting the user select the transfer medium. After syncing, this will be added as a new conversation. Settings will allow the user to edit things such as their pin.
UI Design Mock-Up
UI Design Examples
Server
Our server is going to field the retrieval and storage of the ciphered messages. When a user goes to send a secured message over the network, it will use a small piece of the OTP as an address. Using this address, it is stored in the server. The app will periodically check with the server on addresses it is expecting messages from because it has the same OTP as the sender so it knows what to addresses to look under. This keeps user identities anonymous so the server can’t reveal this information if compromised.
1. Transmission: the device that is transmitting will send the message to the first address decoded, and will start a timer. Then the transmitting device will wait for an "OK" message to arrive from the receiver on the same address. Once the "OK" has arrived the transmitter knows to disregard the first address and make address 2 into address 1 and generate new address for address 2. If the "OK" message does not arrive before timeout is declared the transmitter will resend the message.
2. Receiving: As for transmission the receiver also keeps track of two addresses. When the receiver sees a message on address1 it sends back an "OK" message. At this point the receiver keeps address one until it sees a new address coming in address2. Arrival of message in address2 indicates the "OK" was received. Then the receiver disregard address1, makes address2 address1 and creates a new address2.
3. Collision: In case two different conversation use the same address space the newer message will override the older one. The receiver will know if the address was meant for it by comparing the decoded message to the checksum. To avoid constant race condition we will introduce exponential back-off to help reduce the amount of overrides.
A graphic explanation on how OTP works:
OTP Exchange
Sending Secure Message
Receiving Secure Message
Caveats & Possible solution:
1. A nice thing to have for messaging is push notifications. They would let the user know immediately when a message arrives for him/her. The problem with this is that our server doesn’t know who is receiving. We believe it is not feasible to implement a push notification system and instead just have our app check in with the server periodically with addresses it is expecting traffic on. To do this without requiring constant access, we feel a check that backs off is the best compromise.
2. Denial of service attacks could be very problematic for our application. An attacker could send non-stop messages to random addresses and by that constantly override everybody's messages. A proposed solution is to take addresses with high override rate 'out of service' till they clear up. By doing that we can minimize the damage done by the attacker.