Due: 11:59PM, 28 Apr. 2009

Background: ATM's and Banks

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

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.

Simulation Details

bcprov-jdk15-134.jar

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

• BankServer.java is the bank server. The bank server establishes a Java ServerSocket object that listens for connection requests on port 2100. For each request from an ATMClient, the BankServer creates a new BankSession thread that will authenticate the user of the ATM and process that user's transactions.

  The BankServer program takes no command-line arguments. It expects to be run from a directory that also contains the file bank.key, which contains the RSA KeyPair object for the bank. The bank KeyPair and any Rijndael keys needed during the server's operation are assumed to be stored in a secured RAM.

The BankServer also expects there to be a file called acct.db in the directory from which it is run. This file simulates the bank's database of accounts. In reality, such a database would be heavily replicated and bullet-proofed to prevent loss of accounting information, but for the purposes of this project, none of these features are significant. The file acct.db contains a AccountDB object that allows the bank to lookup and update account information.

The BankServer has access to additional non-volatile storage (a disk), on which it stores an audit log. The disk could possibly be read by an intruder, however, so the audit log should be encrypted to prevent undesired access. However log messages are liable to be large and frequent.

• ATMClient.java provides the functionality of an ATM. It compiles to an executable program that simulates the ATM interface. It is run from the command line by providing two arguments:

  java ATMClient ATM# BankServer 

  The first argument is a string specifying a unique identifier for this ATM client. (The simulation does not verify that different clients have different ATM's, because that is not significant from the perspective of the project.) The argument BankServer is the IP address (or domain name) of the host machine running the BankServer program. Note that this argument should be localhost if the client and server are being run on the same machine.

  The ATM is assumed to have little non-volatile memory (just enough to store the bank server's public key, the software itself, and the ATM identifier). The ATM software is trusted by the user and the bank; assume that it has been burned in ROM and so is not subject to attack. (This assumption rules out certain kinds of Trojan Horse attacks.)

  The ATMClient program assumes that there is a file called bank.pub in the directory from which it is run. The bank.pub file contains the bank server's RSA public key, generated with the BankKeys utility.

  Whenever a user has inserted a valid ATMCard, and entered the corresponding PIN, the ATMClient creates an ATMSession object that handles transactions for that user's session with the ATM.

• BankSession.java and ATMSession.java contain the main implementations of the authentication protocol and the transaction protocols (which you must complete). The authentication protocol is encapsulated in the method authenticateUser. After successfully authenticating, the user, ATM, and bank server perform a number of transactions, as encapsulated by the doTransaction method. The authenticateUser method and the doTransaction method are called from main loops in the BankSession.run() and ATMClient.main methods.

  The constructors for the BankSession and ATMSession objects initialize some fields used for communications, key information, and the account database. The fields kSession, currAcct, and atmID are to be established during the authentication procedure.

  Communication between an ATMSession object and a BankServer object takes place via the Java ObjectIntputStream and ObjectOutputStream objects created when the socket connection is established. See the Java documentation at http://java.sun.com/j2se/1.5.0/docs/api/index.html for information on how to use these objects

• Log.java contains the skeleton for a persistent log. The constructor of a Log object takes in an RSA public key and initializes the log. The Log object also provides a method write that is able to append a Serializable Java object to the log. By default, the write method prints out a message to the terminal.

  The BankServer class contains a static reference to a Log object, so that log messages may be written as BankServer.log.write(...).

• Account.java encapsulates a user's account information. It supports several kinds of transactions, maintains a running balance, and stores the bank's copy of the user's public key. The accounts are indexed in the account database by an account number, which is generated automatically when the account is created.

  There are three kinds of transactions that the user can perform at the ATM: (1) Deposit, (2) Withdrawal, and (3) Balance inquiry. At the user's request, the bank server should perform the corresponding action on the Account object owned by the user.

• ATMCard.java provides the functionality of the ATM card. It stores the user's private RSA key. Because the ATM hardware constitutes a secure channel to the ATM card, the ATM is trusted to manipulate the private key contained in the card. When ATMClient is run, it prompts the user to Please insert card:. For the purposes of simulation, the user types in the name of a file containing ATMCard object. ATMCards are created by using the MakeAccounts utility described below.
• BankKeys This program (run with no command line arguments) creates the files bank.pub and bank.key containing the bank's public RSA key and key pair.
• MakeAccounts This program creates the acct.db if it doesn't already exist, or allows the user to add additional entries to an existing database.
• Crypto.java provides some basic cryptographic routines. The cryptographic algorithms (RSA, Rijndael, and digital signatures) are provided by the Java library, Bouncy Castle (in bcprov-jdk15-134.jar), and a Crypto object wraps these encyprtion algorithms to make them a little easier to use. Crypto.java provides routines to encrypt/decrypt using RSA or Rijndael, create new Rijndael keys, convert a Serializable Java object into a byte array, provide a source of random bits, and sign and verify RSA-based digital signatures. For this project, you should not have to call Bouncy Castle library routines directly.

  For more information and Bouncy Castle documentation, see http://www.bouncycastle.org/. Also, you can try compiling the Crypto.java file with the debug flag set to true, to see the results of encryption/decryption.

• Disk.java provides some useful library routines for reading and writing Serializable Java objects to disk. The method append should be used in the Log class to append log entries to bank.log.

What to do

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.

What to turn in

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.

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

• login system is your eniac login name
• place all the codes and documents in a folder, such as "hw"
• turnin -c cis551 -p project4 hw
  Please make sure the login name is yours when submitting, turnin identifies the submitted projects by the login name.
• turnin -l -c cis551
  You may see what project tags turnin will accept at any given time with the command
• turnin -v -c cis551 -p project4
  The command to verify the submitted project.

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

Grading guidelines

• Is the discussion in your report 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?

Extra credit

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

Example BankServer Session

Example ATMClient Session