Project 4 : Secure Distributed Banking
CIS 551


Due: 11:59PM, 28 Apr. 2009

Background: ATM's and Banks

In this project, you will implement the authentication and secure communications protocols for a distributed system consisting of a bank server and a number of automatic teller machines (ATMs). The computer system at the bank is connected using insecure communications channels to the ATMs. The insecure communications channels are 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 the insecure communications link should be considered suspect.

Customers use ATMs to make queries, withdrawals, and balance inquiries involving their accounts. Attackers must be prevented from interfering with these actions. Unlike ATM machines typically used in the US today, the ATM machines in the project accept smartcards capable of storing an RSA private key and performing a small amount of computation. 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 (their PIN) which the user enters at the ATM.
  3. The customer then selects an action to be performed, and that action is performed by the bank server (perhaps causing dispersal of cash at the ATM).
Public key cryptography is 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 server's public key is stored by the ATM, with the corresponding private key stored by server the connected to that ATM. For efficiency, shared key cryptography is also used.

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

  1. It authenticates the customer (and not the ATM) to the bank branch.
  2. It authenticates the bank branch to the ATM.
  3. It preserves the integrity and confidentiality of communications between the bank and ATM.
  4. It provides the bank server 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 server takes actions in response to customer uses of an ATM. It also 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. However, the server disk is potentially vulnerable to network attacks, and so data written to the log should be encrypted to prevent breach of confidentiality.

Simulation Details

The source files for the project are available from the course web site as the file Project4.tar.gz. The Java CLASSPATH environment variable must include both your working project directory and the
bcprov-jdk15-134.jar
library.

For example, the user stevez was able to compile and run the project in the following session after downloading the Project4.tar.gz archive to the directory /home6/s/stevez/CSE331.

% gunzip Project4.tar.gz 
% tar -xf Project4.tar 
% cd Project4 
% setenv CLASSPATH "/home6/s/stevez/CSE331/Project4/:/home6/s/stevez/CSE331/Project4/bcprov-jdk15-134.jar" 
% javac *.java 
% java BankKeys 
% ... 
The bank simulation consists of two main executables, BankServer and ATMClient, as well as a number of support utilities. The main pieces of the simulation are described below; it will be worth it to familiarize yourself with the provided code for more details.

What to do

There are three main tasks:
  1. Design an authentication algorithm that meets the criteria outlined above. During the course of authentication, the ATM should verify the Bank's authenticity, obtain the account owner's name (displaying it at the appropriate time), and establish a Rijndael session key with the server. Similarly, during authentication, the server should verify the user's authenticity, obtain the account number and ATM identifier, and establish the shared session key with the ATM.

    The authentication protocol you use should be based on RSA encryption. It should entail changes to ATMSession.java and BankSession.java, including additional code (and perhaps fields). You will need to create additional classes to represent your protocol messages.

  2. Design a transaction protocol that meets the criteria for confidentiality described above. No attacker should be able to modify or read the contents of the transactions, and, furthermore, the bank should obtain enough information during a transaction to convince a third party that the transaction was initiated by the user.

    The transaction protocol should be based on Rijndael shared key encryption, and RSA-based digital signatures. Your implementation should entail modifications to ATMSession.java and BankSession.java, and may also require additional classes or methods to implement the transaction messages.

  3. Design a cryptographic audit log. The log should implement efficient protection against unauthorized disk access.

    Only the BankServer should use the log, because the ATM does not have permanent storage. Instrument your authentication and transaction protocols to record information according to the criteria above. Justify the information that you decide to record in the audit log.

    Note that you do not need to implement a way to read the log file (but see extra credit below), but it will be useful for debugging to echo your log writes to the console.

The end of the page has an example BankServer session using our solution. First, the bank keys are created. Next the initial account database is created. Finally, the BankServer is started. (Note that you must start the server before running any of the clients.) The log messages you see were generated from the ATMClient session shown in Figure 2. Below is an example session of our solution as seen from the ATMClient. It includes some additional messages relevant to our solution authentication protocol.

What to turn in

Each group should turn in the following items (one submission per group).
  1. An electronic submission of your Java source code. This should be single directory. The directory should contain a file called README that describes the contents of the directory and any special instructions needed to run your programs (i.e. describe any command-line arguments). The README file should describe the tutorial required below.
  2. A project report containing the names of the students in your group. Include a one- or two-sentence description of each group member's contributions to the project and an estimate of the number of hours each member contributed. Your group will receive a single grade for the project. The information about individual contributions will be used at the end of the semester to determine borderline grade cases.
  3. The report should explain how you implemented the requirements for encryption, authentication, and auditing (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 Crypo.java Explain how your protocol resists various active and passive wiretapper attacks.
  4. A tutorial script (in a file called README) 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.
Don't underestimate what is involved in writing instructions for installing, compiling, and running your software. Do path values have to be set? 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.

Project 4 should be submitted online on eniac by using the command turnin.

There is also a turnin man page which explains the usage in more detail, including some additional arguments.

Grading guidelines

Your grade will be based on the following elements: The points will be broken up roughly as: 60% correctness, 20% code quality, 20% writeup.

Extra credit

For up to 10 points of extra credit, create a utility designed for browsing the cryptographic log. Explain your design decisions, emphasizing the relevant security measures. Create a separate tutorial that illustrates how your log viewer utility works.

Do not attempt the extra credit until you have completed the full assignment.

Example BankServer Session

$ java MakeAccounts
File: acct.db not found. Create it? (y/n): y
Creating new database
----- Creating Account ----
Account owner: steve
Please enter a pin number: 1234
Please enter ATM card filename: steve.card
Starting Balance: 100.00
Creating account. Please wait...... Done
Create another account? (y/n) n

stevez@ZETA ~/prj3 $ java BankServer
Mon Oct 28 16:44:51 EST 2002
Log initialized: Mon Oct 28 16:44:50 EST 2002

-------------------------
Bank Server is Running
-------------------------
Waiting for first message.
Got the first message.
Got it.
Sending challenge.
Waiting for Response.
Got Response.
Sending Accept.
Mon Oct 28 16:45:15 EST 2002
Initiating session with ACCT#0 from 1
Mon Oct 28 16:45:23 EST 2002
SignedMessage@f11b8

Mon Oct 28 16:45:23 EST 2002
ATM: 1 ACCT#: 0 DEPOSIT: 25.0

Mon Oct 28 16:45:23 EST 2002
Deposit complete.BALANCE: 125.0

Mon Oct 28 16:45:33 EST 2002
SignedMessage@5e9756

Mon Oct 28 16:45:33 EST 2002
ATM: 1 ACCT#: 0 WITHDRAW: 10.0

Mon Oct 28 16:45:33 EST 2002
Withrawal complete.BALANCE: 115.0

Mon Oct 28 16:45:35 EST 2002
SignedMessage@238bd2

Mon Oct 28 16:45:35 EST 2002
Terminating session with ACCT#0 from 1

Example ATMClient Session

$ java ATMClient 1 localhost
*****************************
ATM #1

Please insert card: steve.card
Please enter your PIN:
1234
Sending AuthInit
Waiting for challenge
Got Challenge
Sending response
Waiting for session key
Welcome steve
*****************************
(1) Deposit
(2) Withdraw
(3) Get Balance
(4) Quit

Please enter your selection: 1
Enter Deposit Amount: 25.00
Deposit complete.
New balance = 125.0
*****************************
(1) Deposit
(2) Withdraw
(3) Get Balance
(4) Quit

Please enter your selection: 2
Enter Withdrawal Amount: 10.00
Withrawal complete.
New balance = 115.0
*****************************
(1) Deposit
(2) Withdraw
(3) Get Balance
(4) Quit
Please enter your selection: 4
Goodbye!
*****************************
*****************************
ATM #1
Please insert card:
Last modified: Wed Apr 8 19:07:11 EDT 2009