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.
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.
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:
Public key cryptography is then employed for secrecy, integrity-protection, and authentication.
The ATM communicates with the bank by running a protocol that satisfies the following requirements:
Encryption and Authentication Layer 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.
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 bankidin 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.)
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 bankidwhere 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
(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
You can then run all the Java 2 binaries directly from the shell.
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):
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: