-
Notifications
You must be signed in to change notification settings - Fork 7
Home
Welcome to the SecureChat wiki!
This will cover all design and documentation for the End-to-End Encrypted secure chat.
This can be printed by following this tutorial.
- Aaron Turner, #011502541
- Kumin In, #012216371
The projects are, in fact, multiple pieces of a bigger project, namely a secure end-toend encrypted text messaging application (limited-size text messages only, one-to-one chat, group chat functionality is a big bonus but not required). In this project, you are assigned a task of designing, implementing and testing a secure messaging app that provides end-to-end encryption for one-to-one messaging (at minimum). The idea is that you’ll have a server that distributes the messages among client applications. You’ll need to develop a secure, authenticated way of communicating between your client and server. Then you’ll need to design and implement an end-to-end encrypted (that proves confidentiality and integrity) of message exchange between two clients thru the server. To this end, you will develop a RESTful web server (https only) to receive a message from one client and pushes to the recipients when they become available (i.e., store messages in a database). You need to make sure that only the client applications developed by you can connect to the server (tip: Use an application authentication mechanism such as an app key). In addition, you'd need to authenticate the user (username/password or something similar. If your platform is mobile you can read the phone number w/out any user interaction and set it as username). Each message will contain info about the sender, the receiver, the encryption meta data, the encrypted message and anything else necessary. Apps periodically ask the server if there is a new message for them (e.g., you can use a GET request). The receiving end, will use the encryption meta data (if any exists) to decrypt the message. Then the message along with the identity of the sender is displayed. A very basic GUI is enough, there is absolutely no emphasis on how fancy your GUI looks. Note: If you are after the bonus points of adding group chat (multiple people) functionality, make sure you run your ideas with the instructor. If you are not familiar with web servers, API requests, JSON web tokens (JWT) then get started on reading up on those ASAP. If you intend to use a framework, start reading documents as early as you can.
In your repo as well as BeachBoard (under Dropbox, folder titled "Phase I") you'll include all your design documentation of your solution. That is, you explain any additional security requirements your system will satisfy (e.g., whether the server is trusted or not and how that affects your solution). You'll explain how you plan to achieve your goals. Your document should include a high-level overview of your system components (e.g., authentication methods, message integrity checks, etc). Your documentation needs to justify why your solution works (meeting the security requirements). Be creative yet rigorous in your solution. You need to include system diagrams (depicting what your system components are and how they tie together). Also, include use case diagrams or tables. Most likely you will not cover all possibilities but try to be as comprehensive as possible. Your project will be tested based on what you include here. Even though this phase includes no programming, this is the most important task since here you actually design your solution to your assignment. Make sure that you think of all possible venues of attack and how things could go wrong. For any attack surface that you can think of, incorporate a defense method in your solution. By the end of this task, you ought to have a very clear understanding of what you'll be doing and how you'll achieve the desired outcomes. Ask your friends to go over your documents and criticize you before the instructor finds a mistake in your work. Remind your fellow students of: "I scratch your back your scratch mine".
Setup a RESTful web server on Amazon AWS cloud (LAMP stack is recommended, MEAN at your own risk. You are free to use well-established frameworks such as Django or web2py for Python, Laravel for PHP, Spring for Java, Qt for C++,Node and ....). Amazon is free with your .edu email. Get a domain for your server (find something cheap). Use Let's Encrypt to setup a free certificate (all instructions on Let's Encrypt). Your server should have a simple database to keep record of messages (sender, receiver, encrypted text, security data, timestamp, …). Incorporate SQL injection defense mechanisms if applicable. Test your TLS configuration with SSL Labs. Work on GET, POST and other necessary API requests. You may want to focus on JSON or XML structures for your responses. Think of authentication (username/password, JSON web token (jwt), ….). You will be graded based on your SSL Labs performance and the robustness of your API routes along with your authentication methods.
You can develop your application for any platform (desktop or mobile). Little attention is given to GUI. Your client has to connect to your sever over TLS protocol using your http API calls. The message delivery should work even when the receiver is offline at the time of sending (i.e., store them to the DB, clients have to do GET pooling to check for any new message periodically. The alternative method of Websockets is bonus but this is a risky area if you have not used Websockets before). We will check whether you can post a message or get a message from the server at this stage.
For each client, use OpenSSL command line prompts to generate a 2048-bit RSA public key (ECC is bonus). Implement a method for distributing public keys -such as trusting the server to do so thru new API routes, use QR code scanners for an offline in person public key exchange, ….). Our approach for key distribution will be similar to the principles of PGP (Pretty Good Privacy). That is to say, for each message, the sender generates a set of two independent FRESH 256-bit long AES keys. One is used to encrypt the message (think of the mode of encryption to be used here), the other is used to compute the HMAC of the cipher text (integrity tag). The cipher text and the tag are concatenated together. Both keys are also concatenated to generate the keys plaintext. The keys plaintext is then encrypted using public key of the receiver (for this project, RSAOAEP is sufficient). This publicly encrypted message is your encryption meta data. At the receiver side, the receiver will decrypt this encryption meta data to recover the two keys. It first checks whether the HMAC test passes only THEN it attempts to decrypt the actual message and display the decrypted text to the user. For more info, Google OpenPGP implementation of PGP protocol. Also, you can check out the source of the Open Whisper Systems at github. We will check your encryption/decryption method calls as well as your integrity check.
Kumin In, Aaron Turner. CECS 478. 2016