Homework 3

Due at 11:55pm, Tuesday, October 20th 2015

In this assignment, you'll add functionality to the code you wrote for Homeworks 1 and 2, to reach the goal of implementing a secure facility for client-server communication across the Internet.

As before, we will give you some of the code you need, and we'll ask you to provide certain functions missing from the code we provide. You can download the code we are providing. Create a fresh directory and unzip the downloaded code into it. Then copy into that same directory all of the .java files from your solutions to Homeworks 1 and 2. As before, you must not use any crypto libraries; the only primitives you may use are the ones we gave you, and ones you implemented from scratch yourself. If you'd like to use our reference solutions for HW1 and HW2, you may download them here. Note that this library does not contain source code.

In this assignment you will implement a secure channel abstraction that can be used by two programs, a client and a server, to communicate across the network, with the confidentiality and integrity of messages guaranteed. We have given you a class InsecureChannel which implements a channel that works but is not secure: everything is sent in unprotected cleartext. We have also given you stubbed-out code for a class SecureChannel that extends InsecureChannel and (once you have modified it) will protect security and confidentiality.

To facilitate the testing process, we have provided a few test files. The first is Util432s.java, which provides a few methods used by the other testing files (feel free to use these methods for debugging). The second is ChannelTest.java, which provides a demonstration that the InsecureChannel class works correctly. The third is SecureChannelTest, which you can use to test your SecureChannel class (once implemented). Note that this class does NOT test security properties, instead testing only basic functionality. Note the commented out lines which give an example of how you can Util432s for debugging. The fourth is InsecureChannelDebug, which is a special version of InsecureChannel which provides the ability to echo channel transmissions to the screen. To use this class, simply rename the file "InsecureChannel.java" and place it in the same directory as SecureChannel.java.

Although your solution will call on code that you wrote for Homeworks 1 and 2, we will test your solution with our own implementation of the Homework 1 and 2 functionality. Your solution must work correctly when we do this --- this shouldn't be a problem for you as long as you respect the API requirements of the previous assignments.

IMPORTANT: For this assignment, we will also REQUIRE a README file. In the file, you should describe your setup and your threat model: What are you doing? How would a user of the classes you've written use them? And what security properties (against what sort of adversary) should they expect to get if they use them correctly? This should be in addition to any documentation you would normally put in comments or a README.

We're not looking for War and Peace in this (i.e. it doesn't need to be very long). Rather, you should provide a clean and clear description of your security goals and how they are achieved in a few paragraphs at most.

SecureChannel. Your SecureChannel class should implement the following API:

public class SecureChannel extends InsecureChannel {
    public SecureChannel(InputStream inStr, OutputStream outStr, 
			 PRGen rand, boolean iAmServer,
             RSAKey serverKey) throws IOException 
    public void sendMessage(byte[] message) throws IOException
    public byte[] receiveMessage() throws IOException

The constructor will contain the vast majority of your code. Its role is to set up the secure channel such that the sendMessage and receiveMessage methods can do their jobs. These methods should provide authenticated encryption for the messages that pass over the channel, ensuring that messages arrive at the receiving end in the same order that they were send on the sending end. Furthermore, when the client is setting up its channel, it should also authenticate the server's identity, and should take whatever steps are necessary to detect any man-in-the-middle. If one of the two parties (server or client) detects a potential security problem during channel construction, that party should close the channel by calling close(). You can assume the serverKey (public key) passed to the constructor of SecureChannel on the client side of the communication is verified externally in some way (for example via a trusted certificate).

The underlying InsecureChannel will normally deliver messages in the same order they were sent. But note that an adversary might try to reorder messages. receiveMessage should return null if an invalid or out-of-order message shows up.

Assignment Tips and Tricks. This list will definitely grow in response to Piazza questions.

Submitting your solution: You should submit any code files that you modified or created in doing this assignment. (You don't need to submit code that you copied from your solution to Homeworks 1 or 2. If you submit these we will ignore them anyway.) Submit your code using this link.

Copyright 1998-2014, Edward W. Felten.