Architecture Plan Android Text Encryption Tommy Fritz Nghia Nguyen Paul Scott Sara Wells Introduction Encryption as an art has existed for centuries, vastly pre-dating the technological adaptations we take for granted today. Early encryptions were effective, but generally simple and limited by the time required to manually encrypt, send, and decrypt messages. In today’s society, almost instantaneous encryptions performed by computers are part of everyday life and make secure shopping, banking, data exchange, and other activities possible. One popular form of communication, however, generally lacks any sort of sophisticated encryption – text messages. Many people send delicate information and conduct private conversations via text with little protection from third parties who might intercept the message or the storage of their information in phone company records. In order to fill this void and offer customers a more securely private means of textual communication, Fish Eating Penguin hopes to develop Text Encryption, an application for Android phones. Text Encryption will be a third-party application capable of running on any Android system. It will allow users to send and receive encrypted text messages using the standard SMS text messaging system, and will only send encrypted data over that system. Without the Text Encryption program and an appropriate key/password, any intercepted or stored messages will appear unreadable. In this way, we hope to provide a safe and secure means of transferring private messages between any two Android phones. This paper details the specification of the Text Encryption system in two main parts: a requirements section and a use case section. The requirements section lists all currently anticipated functional and nonfunctional requirements. The use case modeling section provides a use case diagram representing the system and brief and detailed descriptions of each use case. Additionally, the responsibilities of each team member are addressed. System Architecture Class Diagrams Sequence Diagram GUI Sketches Fish Eating Penguin Tentative Schedule from Nov. 1st to December 6th Week 1 – Nov 1st to Nov 7th Architecture, design, and iterative development plan. We are going to finalize a schedule and confirm the iterative development plan which includes the system architecture, class diagrams, sequence diagrams, and use cases. Week 2 – 8th to 14th This week we put together the GUI and the basic texting functionality. We want to be able to read texts and have them show up in the appropriate fields, as well as write texts and such. Week 3 – 15th to 21 Put together the encryption interfaces and set it up to encrypt but not send, as well as decrypt but not receive. Make it so we can see encrypted messages and we have the ability to decrypt them. Week 4 – 22nd to 28th Start plugging in the SMS functionality and make it so that texts are able to be sent over the SMS system, as well as received, and that it functions as SMS texting system. Week 5 – 29th to 5th Validate that it works and tie loose ends, make it prettier, validate functionality by testing it on real phones and making sure it meets specifications and expectations. NEEDS Texting interface GUI View texts sent/received/from whom Text entering screen Encryption interface Lots of buttons Texting functionality Text Storage Text sending/receiving Text writing Encryption/Decryption System Algorithm Import message Encrypt message/decrypt message Show message to user encrypted and unencrypted USE CASE TEXT MESSAGE ENCRYPTION Description Actor Software user (Sender and Receiver) Precondition The software interact with the android text message, showing the ENCRYPT and DECRYPT icon on the top right of the text message window. User must have android phone and the text message that supports this software. Postcondition The input should not over 180 characters. English as default languages, using the roman alphabets. Functions Setup default encrypt key and decrypt key o To save time, the software automatically use default key to encrypt or decrypt the given message. Encrypt text with given key o Sender is asked to input the key, which is used to encrypt the message. Decrypt text with given key o Receiver is asked to input the key, which is used to Decrypt the Note message. Install/Uninstall o Setup or remove the software from the android phone. If the receiver input a wrong key code, the software still produce the output, however the output is not correct as the sender’s intention. Team Member Contributions Tommy Fritz – Copy and Paster/Class Diagrams, schedule Paul Scott- System Architecture and Sequence Diagram Sara Wells- Interface Sketches and intro/cover page Nghia Nguyen- Use Case Description and Incremental model References: http://developer.android.com/reference/android/telephony/SmsManager.html