Atlantis User Guide

Introduction - Why One Time Pads?

Background

Design Goal

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

Local Device Storage

Schema Diagram

Local Encryption

User Interface

UI Design Mock-Up

UI Design Examples

Server

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.
   

Testing Document

Summary of Product

Brief Primary Use Case of Product

The primary use case is to provide secure and private communication between two devices by using the one-time pad encryption technique. This technique involves generating a random pads of data, exchanging them between two devices outside of the network by using USB, Bluetooth, etc., and then using the pads to encrypt messages between the devices and sent over the network via an anonymous relay server. In this way, users can create conversations and then send messages.

Major Elements of Product

1. 
   Android Application
   
   1. 
      Storage
      
      1. 
         Safety: Encrypt data
         
      2. 
         Integrity
         
   2. 
      Off Network Communications
      
      1. 
         Bluetooth
         
      2. 
         USB
         
      3. 
         AUX
         
   3. 
      Message Encryption using OTP protocol
      
   4. 
      Network Connection with the Server
      
   5. 
      GUI
      
2. 
   Server
   
   1. 
      Distributing addresses
      
   2. 
      Storing of messages
      

Developer Contact Information

• 
  Ricardo Matsui (rmmatsui@ucdavis.edu)
  
• 
  Jonathan Vronsky (jvronsky@ucdavis.edu)
  
• 
  Dan See (dcsee@ucdavis.edu)
  
• 
  Andrew Brandes (apbrandes@ucdavis.edu)
  

Resources Required for Testing

Development Machine

• 
  Capable of running Android Studio and Git for building Android application
  
• 
  Capable of running Node.js, MongoDB, and Git for running server
  

Android Application

• 
  Two Android phones running Android 4.4
  
  • 
    AUX Cable Connection
    
  • 
    Bluetooth Capability
    
  • 
    USB host capability
    
• 
  USB On-the-Go Cable
  
• 
  USB to Micro USB Cable
  

Estimated Person Hours

Approximately 1 hour and 30 minutes.

How to Obtain Resources

Hardware is widely available and can be purchase online at Amazon. Software is free and can be downloaded from the Git, Android, Node.js, and MongoDB websites or package managers for the development operating system.

Packaging and Building

Android Application

1. 
   Application can be checked out with Git from the Bitbucket repo athttps://bitbucket.org/ecs-193-atlantis/otp-android
   
2. 
   Open Android Studio and open the Atlantis project
   
3. 
   Select Build and Run
   

Server

1. 
   Server can be checked out with Git from the Bitbucket repo athttps://bitbucket.org/ecs-193-atlantis/otp-server
   
2. 
   Install Node.JS fromhttps://nodejs.org/
   
3. 
   Install Heroku Toolbet from https://toolbelt.heroku.com/
   
4. 
   Install dependencies by running `npm install` and `npm install nodemon`
   
5. 
   Launch the server locally by running `nodemon index.js`
   
6. 
   Configure the Android application by setting the remote URLs to use the IP address of the local server.
   

Process for Defect Reporting & Repair

Issues defects will be reported to the Bitbucket repo issue tracker, with proper title, reproduction steps, component identification, priority, and assigned to a developer. Within one day, the developer will accept the issue by responding to it or request more information by assigning back to the reporter. Once accepted, the developer will create a separate branch from the master branch to address the issue and develop the fix. Once the fix has been completed, the developer will create a pull request to master for code review including `Fixed #` in the title. Once the pull request has been reviewed by at least one other developer and merged into master, the issue will be resolved, and the reporter of the issue can then close the issue or reopen if the problem continues.

Functional Testing Plan

Test ID	User Identification	User Goal	Developer Estimated Time	Tester Estimated Time
#1	End-User	Create Conversation	3 min.	3 min.
#2	End-User	Sync Conversation	10 min.	7 min.
#3	End-User	Send and Receive Messages	20 min.	9 min.
#4	End-User	See Warning on Low OTP	10 min.	8 min.
#5	End-User	Delete Conversation	8 min.	8 min.
#6	Application	Application Can Send and Query Messages on Server	7 min.	7 min.

Non-Functional Testing Plan

Test ID	Category	Sub-Category	Specific Goal	Developer Estimated Time	Tester Estimated Time
#6	Security	Encryption	Messages are Encrypted with OTP	15 min.	15 min.
#7	Security	Authenticity	Messages are Checked for Authenticity	15 min.	18 min.
#8	User Experience	Performance	Conversation Loads Quickly	5 min.	8 min.
#9	User Experience	Performance	Messages Are Sent Quickly	5 min.	8 min.
#10	Security	Availability	Server Is Reliable	9 min.	10 min.

Test Cases

Test Case Template

1. 
   User Type
   
2. 
   Goal
   
3. 
   Initial Conditions / Required Resources / Configurations
   
4. 
   Test Script
   
   1. 
      User action
      
   2. 
      Expected response
      
   3. 
      User action
      
   4. 
      Expected response
      
   5. 
      …
      
   6. 
      User action
      
   7. 
      Expected response indicating completion
      
5. 
   Functional test cases - Checking for correct completion or Non-functional test cases - measuring degree of compliance
   

1. Create Conversation

1. 
   End-user of application
   
2. 
   To start a new conversation with another user
   
3. 
   The two users are together with both Android devices that have the application installed
   
4. 
   Test Script
   
   1. 
      Both users launch the application
      
   2. 
      The application launches to the conversation list
      
   3. 
      Both users tap the new conversation button
      
   4. 
      The application moves to the new conversation button
      
   5. 
      Both users name the conversation with a title they like and choose a pad size
      
   6. 
      The application configures the conversation with those parameters
      
   7. 
      Both users select create
      
   8. 
      The application creates the conversation and generates the pad size and completes this test by showing the sync page
      
5. 
   The application reaches the sync page without any error and the OTPs are saved to each device’s memory.
   

2. Sync Conversation

1. 
   End-user of application
   
2. 
   To sync a conversation with another user
   
3. 
   The two users are together with both Android devices that have the application installed and have a common method of syncing data (USB, Bluetooth, etc.). They have created a conversation in the previous step or already have made a conversation together.
   
4. 
   Test Script
   
   1. 
      Both users select sync or are at the sync screen
      
   2. 
      The application shows them a list of supported sync methods on their device
      
   3. 
      Both users tap the same sync method
      
   4. 
      The application shows the instructions for the method they chose
      
   5. 
      Both users follow the instructions to start the transfer of the pad which may include pairing the other device
      
   6. 
      The application performs the transfer and shows progress as the transfer is made
      
   7. 
      Both users can observe the progress of transfer of the pads
      
   8. 
      The application completes the transfer and completes this test by taking both users to the conversation page
      
5. 
   The application reaches the conversation page without any error and the OTPs are the same on both devices.
   

3. Send and Receive Messages

1. 
   End-user of application
   
2. 
   To send a message from User A to User B
   
3. 
   The two users have both Android devices with Internet access and have the application installed with a conversation created and synced between the two devices
   
4. 
   Test Script
   
   1. 
      User A opens the application and selects the conversation with User B
      
   2. 
      The application loads the conversation between User A and User B
      
   3. 
      User A selects the message field, enters a message, and presses send.
      
   4. 
      The application encrypts the messages and sends it to the server
      
   5. 
      User A sees the message in the conversation on their device
      
   6. 
      User B opens the application and selects the conversation with User B
      
   7. 
      The application loads the conversation and requests new messages from the server.
      
   8. 
      User B sees the conversation as it was previously rather than waiting for new messages
      
   9. 
      The application receives the new message from the server, decrypts it, and adds it to the conversation
      
   10. 
       User B sees the new message and it is the same as what User A entered
       
   11. 
       The application completes this test by having sent and received the message correctly
       
5. 
   The application was able to send and receive a message without any error and the message is received correctly on the devices.
   

4. Warning on Low OTP for Conversation

1. 
   End-user of application
   
2. 
   To show that a conversation should be refreshed
   
3. 
   A user has an Android device and has been using a conversation for some time and the OTP available is below 20%.
   
4. 
   Test Script
   
   1. 
      The user opens the conversation
      
   2. 
      The application shows them the conversation and a warning that the OTP is below 20% and that they should refresh it with the other user
      
   3. 
      The user can tap the refresh button to begin the sync process
      
   4. 
      The application completes this test by showing the sync process
      
5. 
   The application completes the test by showing the warning message with the OTP available is below 20%
   

5. Delete Conversation

1. 
   End-user of application
   
2. 
   To delete an old conversation
   
3. 
   A user has an Android device and no longer needs a conversation
   
4. 
   Test Script
   
   1. 
      The user opens the conversation
      
   2. 
      The application shows them the conversation
      
   3. 
      The user taps the delete option
      
   4. 
      The application deletes the conversation and related OTPs from the device, completing the test
      
5. 
   The application completes the test by removing the conversation, messages, and OTPs from the device memory
   

6. Messages are Encrypted With OTP

1. 
   End-user of application
   
2. 
   To show that messages are encrypted with OTP
   
3. 
   An Android device with the application and with a conversation set up and synced. A network which can have the traffic captured.
   
4. 
   Test Script
   
   1. 
      The user opens the application and selects the conversation
      
   2. 
      The application shows them the conversation
      
   3. 
      The user enters a message and taps on send and repeats the same message again.
      
   4. 
      The application encrypts the messages and sends them over the network
      
   5. 
      The tester examines the messages sent over the network and verifies that it was sent encrypted and the tester verifies that the OTP is not reused in any way by seeing that the encrypted text has been shifted accordingly. This completes the test.
      
5. 
   The test is completed by showing that the messages are encrypted with the OTP on the device and the OTP is not reused
   

7. Messages Are Checked for Authenticity

1. 
   End-user of application
   
2. 
   To show that messages are checked for modification on the network
   
3. 
   Two Android devices with the application and with a conversation set up and synced. A network which can have the traffic modified.
   
4. 
   Test Script
   
   1. 
      User A opens the application and selects the conversation
      
   2. 
      The application shows them the conversation
      
   3. 
      User A enters a message and taps on send
      
   4. 
      The application encrypts the messages and sends them over the network
      
   5. 
      The tester modifies the message sent on the packet on the network
      
   6. 
      User B opens the conversation
      
   7. 
      The application requests new messages and does not validate the modified message
      
   8. 
      User B does not see the modified message, completing the test
      
5. 
   The test is completed by showing that the messages must be received correctly to be shown and cannot be tampered
   

8. Conversations Load Quickly

1. 
   End-user of application
   
2. 
   To show that the application performance is acceptable
   
3. 
   An Android device with the application and with a conversation set up and synced and many messages sent.
   
4. 
   Test Script
   
   1. 
      User A opens the application and selects the conversation
      
   2. 
      The application shows them the conversation without significant delay
      
5. 
   The test is completed by measuring how quickly the application opens the conversation
   

9. Messages Are Sent Quickly

1. 
   End-user of application
   
2. 
   To show that the application performance is acceptable
   
3. 
   An Android device with the application and with a conversation set up and synced and many messages sent.
   
4. 
   Test Script
   
   1. 
      The user opens the application and selects the conversation
      
   2. 
      The application shows them the conversation
      
   3. 
      The user sends a long message
      
   4. 
      The application encrypts the message without significant delay, completing the test
      
5. 
   The test is completed by measuring how quickly the application is able to encrypt the message and send it to the network
   

10. Server Is Reliable

1. 
   Application API
   
2. 
   To show that the server does not fail with high loads
   
3. 
   A server instance and another computer on the network to stress-test
   
4. 
   Test Script
   
   1. 
      The tester runs a script to deliver many requests per second of messages and message queries to the server of various lengths and some valid and invalid
      
   2. 
      The server processes and enqueues requests, but does not crash or consume more resources that it has
      
   3. 
      The server completes the test if it does not crash
      
5. 
   The test is completed by measuring how many requests per second can be processed successfully and how many resources it uses on the server.
   

11. Server Can Receive and Query For Messages

1. 
   Application API
   

1. 
   To show that the server can accept and respond to queries
   
2. 
   A server instance and another computer on the network to send API requests
   
3. 
   Test Script
   
   1. 
      The tester send a message to the server at a message address to the API endpoint
      
   2. 
      The server processes and stores the message
      
   3. 
      The tester queries the server for messages at the message address via the API endpoint
      
   4. 
      The server responds with the message the tester originally sent
      
   5. 
      The tester queries the server for message at an address without messages
      
   6. 
      The server responds without any messages
      
   7. 
      The test is completed by showing the messages can be sent and received correctly
      
4. 
   The test is completed showing that it can store and query for messages