Spring 2000 - CS513 System Security - Programming Assignment, Phase I

Phase I: Secure Distributed Banking System

Due: 9:00am Monday, March 13

General Instructions. Students are required to work in groups of 2 or 3 for this assignment. An assignment submitted on behalf of a "group" having only one student will receive a grade of F. All members of the group are responsible for understanding the entire assignment.

No late assignments will be accepted.

Academic Integrity. Collaboration between groups is prohibited and will be treated as a serious violation of the University's academic integrity code.

Background: Building a Secure, Distributed Banking System

A bank comprises a set of branches. Each branch manages a disjoint subset of the bank's accounts. Associated with each account is a unique account number, a balance, as well as other information that will be of less concern to us in this phase of the project.

The computer system at each branch is connected

using insecure communications lines to one or more automated teller machines (ATMs), which are located in physically insecure areas,
using secure communications lines to one or more teller terminals, which are located in physically secure areas, and
using secure communications lines to computer systems at other branches.

An insecure communications line is subject to attack by active and passive wiretappers: messages may not be deleted by an attacker, but messages sent might be read, replayed, or changed by an attacker, and new messages might be generated by an attacker. Thus, the authorship and/or content of messages that transit an insecure communications line should be considered suspect. A secure communications line does not have these vulnerabilities.

In this first project phase, we are concerned with implementing security for ATM access to the bank. Subsequent phases will address security concerning teller terminals and account information.

ATM Access: What a Customer Would See in a Real System

Customers use ATMs to make queries, withdrawals, and funds transfers involving their accounts. Attackers must be prevented from interfering with these actions. One solution is to give each customer a smartcard --- which we call a bank card --- containing a small processor and some non-volatile memory. Interactions with the ATM would work like this:

The customer inserts his/her bank card into the ATM.
The ATM prompts the customer for a "password" which the user enters at the ATM.
The customer then selects an action to be performed, and that action is performed by the branch (perhaps causing dispersal of cash at the ATM).

Public key cryptography is then employed for secrecy, integrity-protection, and authentication.

A customer's bank card contains a private key for that customer, with the corresponding public key stored by the branch that manages the customer's account.
The bank's public key is stored by the ATM, with the corresponding private key stored by the branch directly connected to that ATM.

For efficiency, shared key cryptography is also used, because employing public key cryptography for entire messages can be significantly more expensive than encryption using a hybrid of shared key and public key cryptography. To eliminate certain attacks on the server, the server does not store any shared secret keys. This, for example, rules out the use of shared secret keys as "session keys".

The ATM communicates with the bank by running a protocol that satisfies the following requirements:

Encryption and Authentication Layer Requirements:

authenticates the customer (and not the ATM) to the bank branch,
authenticates the bank branch to the ATM,
preserves the integrity and confidentiality of communications between the bank branch and ATM, and
provides the bank branch with evidence it can log, so that the bank can demonstrate (to a technically knowledgeable judge) that every ATM-initiated action was, in fact, initiated by the customer.

The bank branch takes actions in response to customer uses of an ATM. Each bank branch records information in an audit log for later use in justifying its past actions to concerned customers. The audit log is stored in a file, so that it can be inspected should the need arise.

What to Do and How to Do It

Implement a banking system that works along the lines outlined above. Of primary importance is your design for a protocol to satisfy the Encryption and Authentication Layer Requirements and your implementation of that design. Therefore, we have already written Java applications that implement some of the functionality outlined above; some (carefully thought out!) modifications to that software is all that should be required.

You can find our Java applications in the directory

\\Goose\courses\cs513-sp00\PhaseI.Goodies

Download everything there into your own, new directory.

Simulating Bank Cards and Generating Public/Private Key Pairs. The computer lab where you are doing this project does not have hardware to support bank cards. But it is easy enough to simulate the functionality of a bank card being used in this project. Executing our Java application

java PrivPubKeyGenerator id passwd

(where passwd is optional) produces in the current directory two files that encapsulate information related to a possibly password-protected fresh public/private key pair.

id.pub This file contains a serialized instance of an object that supports method getPublicKey() which returns the public key.
id.pair This file contains a serialized instance of an object that supports methods:
- getPublicKey() returns the public key.
- getPrivateKey() returns the private key only if no passwd was specifed in the invocation of PrivPubKeyGenerator that produced the id.pair file. Otherwise, getPrivateKey() returns the private key exlusive-or'ed with the value of passwd provided for PrivPubKeyGenerator to produce the id.pair file
- getPrivateKey(pass) returns the private key if pass equals the value of passwd when PrivPubKeyGenerator was invoked to produce the id.pair file. If pass and passwd are not equal, then getPrivateKey(pass) returns the private key exlusive-or'ed with pass and with passwd.

Simulating the ATM. We have implemented the functionality of a bank ATM machine in the ATMGUI Java application. To start our simulation, execute

java ATMGUI bankid

in its own directory, giving an integer 1 through 5 that names a bank branch for bankid.

Our GUI involves a key dialog box and a transaction window. The key dialog box prompts the customer to enter two pieces of information to simulate a bank card:

.

key file: The name of a .pair file produced by running PrivPubKeyGenerator. Thus, we use an .pair to simulate a bank card.

password: The password needed to unscramble the encrypted private key in the named key file

After clicking Login in the key dialog box, our ATM GUI next displays the transaction window and requests the following information:

source / destination accounts:	customer account numbers. All accounts must be in the form `b.xyz` where `b` is an integer 1 through 5 that names a bank branch (i.e. a bankid) and `xyz` is a 3-digit number designating the account within that branch. (The bank branch name for the branch connected to this ATM appears in the title bar of the transaction window.)
operation:	radio buttons to select a command for displaying a balance, withdrawing cash, or transferring funds from one account to another.

Operations that can be initiated at the ATM include:

query	The balance of the named account is displayed by the GUI.
withdraw	The amount specified is withdrawn from the named account. In a real ATM, this would cause a cash disbursement. Upson PC's are unable to print cash, so we simulate the effect by displaying the new balance.
transfer	The name of a second account is requested. Then the amount specified is withdrawn from the first account and deposited in the second account. At the conclusion of this operation, the new balance of the first account is displayed.

Class ATMOperations of our ATM GUI implementation is the place to augment the protocols being used for communication between the ATM GUI and a bank branch. You have access to the source for the class, and the source has comments indicating (the only) places in the file that you may change. (Making changes to other parts of ATMOperations will likely cause things to break.)

Method initateLogon is invoked when Login is clicked in the key dialog box. Parameter psswd contains the string that was entered into the password field.
Method performRequest is invoked when the transaction window has been completed and is concerned with building messages for communication with the bank branch and parsing responses.

Simulating the Bank Branch. We have implemented the functionality of a bank branch in the BankOperations Java application. To start our simulation, execute

java BankOperations bankid

where bankid is 1-digit number that is the name of a bank branch. BankOperations should be invoked in a separate directory from ATMGUI and must be invoked before ATMGUI is.

Class BankOperations is the place to augment the bank branch half of the protocols being used for communication between the ATM GUI and a bank branch. You have access to the source for the class, and the source has comments indicating (the only) places in methods send and recv that you may change. (Making changes to other parts of BankOperations will likely cause things to break.)

Encryption. Routines to implement cryptographic calculations can be found in the Cryptix security provider, which is located on-line at

http:///www.cryptix.org/

Although Cryptix provides routines for RSA encryption and decryption, you may have trouble getting these to work. Therefore, we have written routines to perform RSA encryption and decryption as well as RSA signature generation and verification for you to use. These can be downloaded from

\\Goose\courses\cs513-sp00\AliGoodies

(The Cryptix routines for DES encryption and decryption work just fine, and you should use these for any shared key encryption/decryption).

Some Miscellaneous Details

Java 2 in the Undergraduate Lab can be found in the path g:\jdk\jdk1.2\. To use Java 2, open a CMD shell and set the PATH to point to the Java 2 binaries with the command
set PATH=g:\jdk\jdk\bin;%PATH%.
You can then run all the Java 2 binaries directly from the shell.
BankOperations must be started and running before ATMGUI is started.

Submission Procedure

Create a directory containing the files you wish us to grade. Call this directory xxxxx0, where xxxxx is the Cornell network id of the team member whose net id is alphabetically first (of your team). Then copy this directory to the following folder:

\\Goose\courses\cs513-sp00\proj02.submit

Don't be disturbed by warnings informing you that the file cannot be accessed after it has been copied.

Should you wish to revise your submission after you have copied it to our folder, then simply correct the files and recopy the entire directory---but this time use the name xxxxx1. Revisions to that should be named xxxxx2, and so on. We will grade only the largest-numbered file of a series. No late submissions will be accepted.

Your directory should contain the following files (at least):

TEAM.txt which contains the names (and net-ids) for all team members. Also, for each team member, give a 1 or 2 paragraph description of the tasks this team member performed and the number of hours this required.

README.txt which contains

The names and a description of the contents for the other files in the directory.
Instructions for installing, compiling, and running your software on our Windows-NT system.
A tutorial that the grader can follow to start your software and to convince himself that your system implements the required functionality. Expect the grader to spend at most 20 minutes on this task.

Rationale.txt which explains how you implemented the requirements of the Encryption and Authentication Layer (as defined above). Recount the operation of your protocol in high-level terms (i.e. messages sent, encryption, decryption, and signature creation or verification steps) rather than using names of the Cryptix and AliRSA methods. Explain how your protocol resists various active and passive wiretapper attacks.

JAVA source file that contain the Java source needed to compile and run your system.

Don't underestimate what is involved in writing instructions for installing, compiling, and running your software. Do path values have to be set? Must the software be installed in a particular directory? Must the name of the host processor be put someplace? Use one group member's account to test your installation script. The easier it is to install your system, the more-kindly disposed the grader will be in evaluating your efforts.

Grading. Your grade will be based on the following elements:

Is the discussion in Rational.txt compelling, complete, and accurate?
Does the system operate correctly?
Are your protocols simple and efficient?
How easy is it to follow the README file installation and sample-execution script.
How completely does the sample-execution script exercise your system.
Is the source code easy to understand and does it exhibit good structure?
Is it possible to successfully attack your system?

key file:	The name of a `.pair` file produced by running `PrivPubKeyGenerator`. Thus, we use an `.pair` to simulate a bank card.
password:	The password needed to unscramble the encrypted private key in the named key file