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

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:

  1. The customer inserts his/her bank card into the ATM.
  2. The ATM prompts the customer for a "password" which the user enters at the ATM.
  3. 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.

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:

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


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.

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:

Operations that can be initiated at the ATM include:

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.)

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

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


(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

  1. 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.

  2. 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:


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

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: