COS 496: Information Security

Spring 2000

General information
Schedule
Homework: 0 1 2 3 4 5 6 7

Assignment 4: Secure Communications

Logistics

This assignment must be submitted by 1:30 PM on Tuesday, March 28. Submit your solution by emailing it (as an attachment) to submit496-4@felten.com.

Your solution should be a zip-file containing three things: your source code (SecureConnection.java, and any other source code files you create), your compiled code (SecureConnection.class and the compiled versions of any other files you create), and a report that describes what you did and why. The report should be an HTML file named index.html. (It may contain links to other files, if you include those files in your submission.)

You must work in a group on this assignment. You may not collaborate with anyone outside your group.

Introduction

ATM machines are connected to bank headquarters by a phone line. At present, the data and commands communicated between the bank and the ATM go across the phone line in cleartext, with nothing to guarantee their integrity and confidentiality. An adversary who got access to the phone line could spy on users and could perform fraudulent transactions.

Your goal in this assignment is to improve the integrity and confidentiality of the communication across the phone line. You will decide which algorithms and mechanisms to use.

You will implement your solution by modifying the file SecureConnection.java, which has been provided in the bank's software.

The Code

Even though the bank and the ATM are part of the same program and run in the same Unix process, they actually have an arms-length relationship. To be more precise, they don't call each other directly, but rather communicate by passing messages across a bidirectional byte stream. This byte stream simulates a phone line.

The basic byte stream communication functionality is implemented in the Connection class. You can read the code in Connection.java if you're interested in how it works, or you can treat it as a black box.

We have implemented another class, SecureConnection (and a helper class, AbstractSecureConnection), that provides the hooks you'll need in order to implement a secure connection. However, our implementation of SecureConnection doesn't actually do anything to protect the communication. That's up to you.

Every time an ATM is created, a pair of SecureConnection objects is created --- one SecureConnection for the ATM side, and one for the bank side. The two SecureConnection objects are hooked up with each other so that, working together, they provide a bidirectional stream.

When a pair of SecureConnection objects is created, the system will call into the new objects and tell them to do their initial cryptographic handshake. On the ATM's end, the clientSideHandshake() method is called, and on the bank's end, the serverSideHandshake() method is called. These methods are called in separate threads, so that they execute simultaneously. (At present the handshake methods don't do anything. You'll have to change that.)

In addition to the handshake, SecureConnection objects support two other methods you'll have to implement: send() and receive(). As the names suggest, send() sends a message (an array of bytes) on the SecureConnection, and receive() waits until a message arrives and then returns it. Each of these methods throws a ConnectionClosedException if it is called on a connection that has already been closed. At present, send() and receive() just call the corresponding methods of their superclass; this causes the messages to be sent in cleartext. You'll have to change that.

Goal

Your goal is to modify SecureConnection.java, and add any other needed code, so that the integrity and confidentiality of data send on the connection is protected.

You have a lot of latitude in choosing which method to use.

Threat Model

The adversary's goal is to learn the contents of a message, to tamper with a message without the tampering being detected, or to inject a forged message without the forgery being detected. Your goal is to prevent him from doing so. Of course, you must not prevent legitimate communication from taking place.

You should make the following assumptions:

The adversary can read and/or modify messages in transit.
The adversary can inject messages into the connection.
The adversary knows what algorithm you are using. He can read your code, but he cannot observe the values of any of your variables.

Note that your design need not recover from message tampering or message injection. It is enough to detect that one of these events has occurred and then raise an alarm.

Your Report

Your report should describe your solution, and explain how and why it prevents the adversary from learning the contents of a message or tampering with a message, under the assumptions given above. Your report should be concise but should be as convincing as you can make it. The quality of your report will be a very important component of your grade, so pay at least as much attention to your report as to your code.

Helpful Hints

The class java.security.SecureRandom implements a cryptographically strong pseudorandom number generator.

The class java.security.MessageDigest implements cryptographic hash functions.

The package javax.crypto implements several other cryptographic primitives.