Embed Size (px)
Citation preview
Atlantis - User GuideSecure Messaging with OTP
Ricardo MatsuiJonathan VronskyDan SeeAndrew Brandes
PrefaceThis document provides the details on design and implementation and an overview of setup and deployment of the Atlantis application and backend. The goal is provide a comprehensive guide for further development, troubleshooting, and deployment of the project for future developers.
AudienceThe audience for this document includes future developers and project managers who need to have a complete view of the project.
Vocabulary● Application - The mobile secure messaging application installed on the end user devices
built for Android● Backend - The server hosted on the Heroku cloud which exchanges messages between
different devices running the application.● End-to-end Encryption - A form of communication where the backend server does not
decrypt the messages being sent, and only the end-user devices can read the messages.
● OTP - A random block of data which is generated from a random source rather than from an algorithm such as a pseudo-random number generator
● OTP Encryption - The OTP computed for conversation is saved on the device after it is encrypted using AES with the user PIN. Even if the file of OTP is compromised the attacker would have to decipher the OTP.
● Entropy - Entropy is the amount of disorder in the data the application collects. The random data used by the app always follow the minimum entropy available to ensure as unpredictable data as possible.
● Harvester - The Harvester is a service that will run on the device in the background. The service will collect random data that will be used to produce the OTP. The service will run until the top cap of data the application can hold will be collected.
● Syncing - Syncing is how the application maintains a copy of a given OTP on a separate device for the purpose of decrypting enciphered messages send between them. To ensure data privacy, syncing must be done locally with USB or bluetooth.
● Notebook - A pair of one-time pads used for communication between two devices. It contains a sending and receiving one-time pad to establish two-way communication.
● Conversation - A conversation is the part of the application where a user can send messages to one or more previously synced contacts.
● Contact - A contact is another user who has synced OTPs with your system and with who you can exchange messages and initiate conversations with.
● Message - A message is a small note of text or an attachment, such as an image, you can send that is received by all other members of a conversation.
Table of Contents
Preface..........................................................................................................................................1
Audience....................................................................................................................................1
Vocabulary.................................................................................................................................1
Table of Contents.......................................................................................................................2
Overview of Product......................................................................................................................2
Installation & Distribution...............................................................................................................2
Backend.....................................................................................................................................2
Development..........................................................................................................................2
Deployment............................................................................................................................3
Android Application....................................................................................................................3
Development..........................................................................................................................3
Deployment............................................................................................................................3
Functionality...................................................................................................................................3
Lock Screen...............................................................................................................................3
Conversation List.......................................................................................................................4
New Conversation Screen.........................................................................................................4
Notebooks Screen......................................................................................................................4
Notebook Screen.......................................................................................................................4
Syncing Screen..........................................................................................................................4
Conversation Screen..................................................................................................................5
Message Screen........................................................................................................................5
Settings Screen..........................................................................................................................5
Harvester Service.......................................................................................................................5
Backend Service........................................................................................................................5
Troubleshooting.............................................................................................................................6
Frequently Asked Questions.........................................................................................................6
Contact Information.......................................................................................................................7
Index..............................................................................................................................................7
Appendix........................................................................................................................................7
Design Document.......................................................................................................................7
Summary................................................................................................................................7
Introduction - Why One Time Pads?......................................................................................7
Background............................................................................................................................8
Design Goal............................................................................................................................8
The Platforms.........................................................................................................................8
OTP Transfer Medium............................................................................................................8
Generation of OTPs...............................................................................................................9
Local Device Storage.............................................................................................................9
Local Encryption...................................................................................................................10
User Interface.......................................................................................................................10
Server...................................................................................................................................14
A Graphic Explanation on How OTP Works:........................................................................15
Caveats & Possible Solution:...............................................................................................16
Testing Document....................................................................................................................16
Summary of Product.............................................................................................................16
Developer Contact Information.............................................................................................17
Resources Required for Testing...........................................................................................17
Packaging and Building........................................................................................................18
Process for Defect Reporting & Repair................................................................................18
Functional Testing Plan........................................................................................................18
Non-Functional Testing Plan................................................................................................19
Test Cases...........................................................................................................................19
Overview of ProductWith recent events, security and privacy have become major topics globally, and new revelations on mass surveillance and the ever-increasing power of computers have shown how existing Internet traffic encrypted with SSL and VPN can be problematic if the communication is recorded, since that communication may be decrypted as more powerful computers become available. The Atlantis project solves this by providing private, end-to-end encryption using the one-time pad technique which guarantees the message cannot be decrypted as long as the pad is not compromised. The app requires Atlantis users to start their conversation with an in-person meeting, allowing their devices to exchange a completely random pad outside of any network. This pad is then used to encrypt future messages for transfer across the Internet. Because the pad is random and is never reused, it is not possible to decrypt the messages without the pad, even with any amount of computational power. Atlantis therefore provides privacy-aware customers such as journalists and businesses, with a convenient platform for secure messaging.
Installation & DistributionBackendThe backend can be be downloaded using Git from: https://bitbucket.org/ecs-193-atlantis/otp-server
DevelopmentThe backend can be easily installed locally by downloading the necessary dependencies:
● MongoDB from http://www.mongodb.org/ ● Node.JS from https://nodejs.org/● Heroku Toolbet from https://toolbelt.heroku.com/● Install remaining dependencies by running `npm install` and `npm install nodemon`
After installation, the server can be run locally by running `nodemon index.js`
DeploymentIt is designed to be deployable using Heroku https://www.heroku.com. To deploy the server, create a new app on Heroku and add the following add-ons:
● MongoLab - MongoDB database provider● New Relic APM - App performance monitoring
Then following the instructions for uploading the code using Git on the Heroku App Deploy page. The backend will be uploaded and will auto-start on the domain provided by Heroku. Pushing new code will automatically restart the service.
Android ApplicationThe Android application can be downloaded using Git from:https://bitbucket.org/ecs-193-atlantis/otp-android
DevelopmentThe only requirement for developing the Android application is Android Studio http://developer.android.com/sdk/index.html After opening downloaded the project, select Build and Run to compile and run the project. To configure the application to use a different backend, modify the string resource `backend_url` to the URL of the backend hosted on Heroku.
DeploymentThe application can be packaged to an APK, signed, and distributed on the Play Store using the latest guides published on the Android developer platform: http://developer.android.com/tools/publishing/preparing.html
FunctionalityLock ScreenThe lock screen shows to enter a PIN to unlock the application. The first time a PIN is needed, the app will request the user to enter a PIN. The PIN is used to encrypt the local data of the application, including the one-time pads. This provides security from attackers with only limited access to the device.
Conversation ListThe conversation list is the home page of the app and shows a list of the conversations that can be selected to view the conversation. It also provides the ability to create a new conversation using the new conversation button. The settings page can also be opened from this page.
New Conversation ScreenThe new conversation screen can be opened from the conversation list. The contacts that this conversation will be with can be entered, with the application providing suggestions from the contacts on the phone when entering names. Multiple names can be entered to create a group conversation with multiple people. The notebook length can also be selected on this page to specify how large the one-time pads should be. The size slider allows a size based on the type of content will be used most. Conversations with images will require significantly larger one-time pads than text conversations. Submitting the new conversation will create the notebooks and go to the notebook screen.
Notebooks ScreenThe notebooks screen is opened after creating a new conversation and can be accessed from any conversation screen. The notebooks screen is used to show the status of the notebooks of the contacts in the conversation. These notebooks are the pairs of one-time pads used to encrypt and decrypt the messages being sent. The amount left is shown, as well as if the notebook has been synced with the necessary contact. Selecting an unsynced notebook will go to the sync screen for that notebook, and selecting a synced notebook will go the notebook screen.
Notebook ScreenThe notebook screen shows extra details about the notebook selected and allows for the notebook to the re-synced. Notebooks must be re-synced when they are empty or close to being empty because one-time pads cannot be re-used. When selecting to re-sync, a new notebook is created and the new notebook must be synced with the contact in-person via the syncing screen.
Syncing ScreenThe syncing screen is used to show methods of syncing the notebook which contains the one-time pad. It shows the various methods of syncing, including via Bluetooth and USB. Each method has a description and instructions specific to perform the sync. The syncing method must be the same between the two devices being synced. The Bluetooth method requires two Bluetooth-enabled devices and USB requires an On-The-Go adapter. Once the method is selected, the one-time pads will be transferred between the devices, and the conversation can be used.
Conversation ScreenThe conversation screen shows the message history in the conversation and send messages. The top bar shows the amount of the notebook that is still available to be used to send
messages, and buttons to refresh and view the notebooks being used in the conversation. The bottom bar contains the text entry, send button, and attachment button. Pressing the attachment button shows an image picker to allow for sending messages. The message history list can be scrolled and selecting a message in the list will open the message screen.
Message ScreenThe message screen shows the full contents of a message, including a large view of image messages so that the content can be easily seen and read. Pressing back will return to the conversation screen.
Settings ScreenThe settings screen shows options such as selecting the image quality preference and adjusting the PIN code settings. The settings screen can be opened from the conversation list. The settings are saved as they are changed making it easy to use.
Harvester ServiceThe harvester service runs in the background collecting data from various sources, then extracting the randomness from them to create the one-time pads. The specific data in the sources is destroyed, but the entropy is calculated and extracted in the process. This generates cryptographically secure random bytes that are used during the conversation creation stage. The harvester sleeps after it collects a sufficient amount of data for a new conversation in order to conserve battery.
Backend ServiceThe backend exchanges messages by temporarily storing them and allowing the application to look the messages up via their unique addresses that are generated by the one-time pads. Since both participants have the one-time pad, they can query for each other’s messages via the backend service. The backend service connects to the applications via Socket.io, which provides a real-time connection, allowing messages to be quickly pushed and pulled from the service to the devices.
Troubleshooting● Messages cannot be sent
Check the Internet connection of the device and check that the backend service is running and the application is configured to use the correct one if it has changed.
● USB device not foundCheck the manufacturer’s website if the device supports accessories and the USB On-The-Go standard. Replace the USB cable if the devices are still not working.
● Messages do not load when debuggingThe application may not have requested a PIN due to the application lifecycle when debugging. Exiting the application and returning to it will cause the application to request a PIN to decrypt the messages.
● Database incompatible after updating schema during developmentThe database must be given an upgrade path for the new schema for it to upgrade to the new version. Another solution is to clear the application data in phone settings to reset the application, but all data in the application will be lost.
Frequently Asked Questions● How is randomness generated?
Randomness is generated from entropy sources that exist on the device.● Why does making a new a conversation require having the participants in-person?
Since the app uses one-time pad, the one-time pads must be exchanged outside of the network in order to provide security.
● What makes a good entropy source?The entropy sources which are most affected by thermal noise, which is considered random, are good candidates for entropy. They can also depend on the randomness present in the environment, and the Shannon entropy calculation can determine the level of entropy present.
● Why use one-time pad if regular encryption is considered secure?Encryption could be broken with stronger computing power, while one-time pad will always be unbreakable if the pads are not compromised due to a lack of an algorithm that related the ciphertext to the plaintext without the pad.
● Why does the app require the participants to re-sync the notebook?The one-time pad is used and never re-used, hence when all the data in the one-time pad is sent, the it will run out and the notebook must be re-synced to create new one-time pads.
● Does the location of the in-person syncing matter?Sometimes, when using Bluetooth it could because the Bluetooth data could be captured by someone using a Bluetooth receiver if the location was a public place. USB data on the other hand is significantly more difficult to be captured by someone because it is a wired connection, so the location is not as important.
● Is an Internet connection necessary?Yes, the messages are sent over the Internet and require connection to the backend server to send messages.
● How long does the one-time pad last?It depends on the nature of the messages sent and the frequency that they are being sent at. Images require significantly more OTP than text, and text only conversation can last for several days with one sync.
Contact InformationName Email
Andrew Brandes [email protected]
Ricardo Matsui [email protected]
Dan See [email protected]
Jonathan Vronsky [email protected]
IndexAndroid, 1, 2, 5, 10, 19, 20, 22, 23, 24, 25,
26Android Studio, 5, 19, 20Application, 1Backend, 1, 2, 3, 4, 7Bitbucket, 20Bluetooth, 6, 8, 10, 11, 19, 20, 22Collision, 17Contact, 2, 3, 9, 19Conversation, 2, 3, 5, 6, 13, 21, 22, 24encrypt, 4, 5, 6, 10, 12, 19, 26end-to-end, 4, 10Entropy, 1entropy source, 8Git, 4, 5, 19, 20Harvester, 1, 3, 7Heroku, 1, 4, 5, 20Message, 2, 3, 7, 18, 19
MongoDB, 4, 5, 19, 20Node.JS, 4, 20Notebook, 2, 6notebooks, 6, 7On-The-Go, 6, 7OrmLite, 12OTP, 1, 2, 3, 9, 10, 11, 12, 13, 17, 19, 21,
24, 25PIN, 1, 5, 7, 8Randomness, 8Receiving, 17, 18re-synced, 6, 8schema, 8, 12settings, 5, 7, 8, 13sync methods, 23Syncing, 2, 3, 6Transmission, 17USB, 2, 6, 7, 8, 19, 20, 22
AppendixDesign Document
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 remain private.
Introduction - Why One Time Pads?
In any secure environment, users need a way to transfer data securely over a network. The users cannot use the Internet because the public network cannot be trusted. They operate under the assumption that all the data they send over it can be intercepted and read, even if it is transmitted under SSL, VPN, or other encryption based on difficulty of solving certain algorithmic problems such as factoring. By using encryption, the users can secure any data, but it’s only as strong as the encryption used. If the traffic is captured, newer computers. 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 Platforms1. 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 Medium1. 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 started with the Secure Random function found in Java, and then upgraded to harvesting higher entropy sources using audio and other sources and extracting entropy. 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 StorageTo 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 EncryptionIn 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 InterfaceOur 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.
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
a. Storagei. Safety: Encrypt dataii. Integrity
b. Off Network Communicationsi. Bluetoothii. USBiii. AUX
c. Message Encryption using OTP protocold. Network Connection with the Servere. GUI
2. Servera. Distributing addressesb. Storing of messages
Developer Contact Information● Ricardo Matsui ([email protected])● Jonathan Vronsky ([email protected])● Dan See ([email protected])● Andrew Brandes ([email protected])
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 at
https://bitbucket.org/ecs-193-atlantis/otp-android2. Open Android Studio and open the Atlantis project3. Select Build and Run
Server 1. Server can be checked out with Git from the Bitbucket repo at https://bitbucket.org/ecs-
193-atlantis/otp-server2. Install Node.JS from https://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 & RepairIssues 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 #<issue number>` 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 Type2. Goal3. Initial Conditions / Required Resources / Configurations4. Test Script
a. User actionb. Expected responsec. User actiond. Expected responsee. …f. User actiong. 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 application2. To start a new conversation with another user3. The two users are together with both Android devices that have the application installed4. Test Script
a. Both users launch the applicationb. The application launches to the conversation listc. Both users tap the new conversation buttond. The application moves to the new conversation buttone. Both users name the conversation with a title they like and choose a pad sizef. The application configures the conversation with those parametersg. Both users select createh. The application creates the conversation and generates the pad size and
completes this test by showing the sync page5. 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 application2. To sync a conversation with another user3. 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 Scripta. Both users select sync or are at the sync screenb. The application shows them a list of supported sync methods on their devicec. Both users tap the same sync methodd. The application shows the instructions for the method they chosee. Both users follow the instructions to start the transfer of the pad which may
include pairing the other devicef. The application performs the transfer and shows progress as the transfer is
madeg. Both users can observe the progress of transfer of the padsh. The application completes the transfer and completes this test by taking both
users to the conversation page5. 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 application2. To send a message from User A to User B3. The two users have both Android devices with Internet access and have the application
installed with a conversation created and synced between the two devices4. Test Script
a. User A opens the application and selects the conversation with User Bb. The application loads the conversation between User A and User Bc. User A selects the message field, enters a message, and presses send.d. The application encrypts the messages and sends it to the servere. User A sees the message in the conversation on their devicef. User B opens the application and selects the conversation with User Bg. The application loads the conversation and requests new messages from the
server.h. User B sees the conversation as it was previously rather than waiting for new
messagesi. The application receives the new message from the server, decrypts it, and adds
it to the conversationj. User B sees the new message and it is the same as what User A enteredk. 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 application2. To show that a conversation should be refreshed3. 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
a. The user opens the conversationb. The application shows them the conversation and a warning that the OTP is
below 20% and that they should refresh it with the other userc. The user can tap the refresh button to begin the sync processd. 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 application2. To delete an old conversation3. A user has an Android device and no longer needs a conversation4. Test Script
a. The user opens the conversationb. The application shows them the conversationc. The user taps the delete optiond. The application deletes the conversation and related OTPs from the device,
completing the test5. 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 application2. To show that messages are encrypted with OTP3. 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
a. The user opens the application and selects the conversationb. The application shows them the conversation
c. The user enters a message and taps on send and repeats the same message again.
d. The application encrypts the messages and sends them over the networke. 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 application2. To show that messages are checked for modification on the network3. 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
a. User A opens the application and selects the conversationb. The application shows them the conversationc. User A enters a message and taps on sendd. The application encrypts the messages and sends them over the networke. The tester modifies the message sent on the packet on the networkf. User B opens the conversationg. The application requests new messages and does not validate the modified
messageh. 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 application2. To show that the application performance is acceptable3. An Android device with the application and with a conversation set up and synced and
many messages sent.4. Test Script
a. User A opens the application and selects the conversationb. 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 application2. To show that the application performance is acceptable3. An Android device with the application and with a conversation set up and synced and
many messages sent.4. Test Script
a. The user opens the application and selects the conversationb. The application shows them the conversationc. The user sends a long messaged. The application encrypts the message without significant delay, completing the
test5. 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 API2. To show that the server does not fail with high loads3. A server instance and another computer on the network to stress-test4. Test Script
a. 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
b. The server processes and enqueues requests, but does not crash or consume more resources that it has
c. The server completes the test if it does not crash5. 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 API1. To show that the server can accept and respond to queries2. A server instance and another computer on the network to send API requests3. Test Script
a. The tester send a message to the server at a message address to the API endpoint
b. The server processes and stores the messagec. The tester queries the server for messages at the message address via the API
endpointd. The server responds with the message the tester originally sente. The tester queries the server for message at an address without messages
f. The server responds without any messagesg. The test is completed by showing the messages can be sent and received
correctly4. The test is completed showing that it can store and query for messages
