CSE408 Fall 2006. Network Security. Project

Note: If you would like to do a different class project, feel free to come discuss your project ideas with me.

A Secure Chat Program

In this project, you will develop a secure chat program that lets users send short messages to eachother via an encrypted, authenticated channel. The project is deliberately open-ended to give you the opportunity to develop the features you find most compelling. For example, you may develop a chat program with a GUI or with a command-line interface, as you see fit. You may include a rendezvous server in your chat system or not. There are also several optional security extensions to the base project.

Connection Initiation. If Alice and Bob are both running your chat application, then Alice can use her program to initiate a connection to Bob. If you have a rendezvous server, then she may just click on a name in a list, or you may have Alice specify Bob's current IP address or hostname, e.g. "rob@fiasco.cs.sunysb.edu".

Basic Security Handshake. Once Alice and Bob's chat applications are connected via a TCP connection, they should perform a Diffie-Hellman key agreement to establish a shared secret key, k. The exact format of the messages exchanged in this step is up to you.

Key Setup. The actual chat messages should be encrypted and MACed using an encryption algorithm, mode-of-operation, and MAC algorithm of your choice. You will have to derive encryption keys, MAC keys, etc. from the shared secret k.

Chatting. Once the key setup is complete, users can exchange chat messages, and the program will transmit these over the encrypted, MACed channel.

Extensions

Extensions are entirely optional. A working implementation of the base protocol can receive full credit without any extensions. Each working extension will increase your project grade by 10%.

Authenticated Diffie-Hellman. As we saw in class, Diffie-Hellman is vulnerable to a man-in-the-middle attack. Enable users of your program to create public/private key pairs, and use those keys to sign/verify the messages sent in the "Basic Security Handshake" step above. For this extension, you may assume that users have exchanged their public keys somehow.

Public-Key Management. Add facilities for your chat program to transfer the public-keys of the users.

Public-Key Infrastructure. Create a Certificate Authority that will issue certificates binding a user's public key to his name (e.g. email address). Add client support for verifying these certificates.

Non-Repudiation. Enable clients to sign every chat message with their private key and to verify incoming signed messages.

Group Chat. Enable 3 or more users to create a forum in which all messages are broadcast to all other recipients. How should key-agreement be performed in this scenario?

Logistics and Grading

You should work in teams of 2 students. You may collaborate with other teams to create chat programs that work with eachother. You MUST NOT show any code to another team, but you can work together in the design of the protocol and during interoperability testing.

You should implement your project in Java. You may use any libraries in the standard java API, including big-integer classes and other crypto-relevant classes, except classes in java.net.ssl. See the java documentation for a list of all the standard classes.

Grading will be based on a demo of your project, a code review of your project, and a one-page design document describing your protocol. Even if you collaborate with other teams to develop interoperable protocols, each team must write and submit its own protocol description. You must make an appointment to demo your project to me sometime before the exam on 12/20.

DateItemWeight of Grade
12/7 Protocol description 20%
12/20 Demo 40%
12/20 Code 40%