Phase II: Teller Authentication

 

Due: 9:00am Monday, April 10

General Instructions. Students are required to work in groups of 2 or 3 for this assignment. The group may have a different composition from your group for Phase I. 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.

 

---

Distributed Banking System Overview

Recall, 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.

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 passively insecure 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 passively insecure communications line is subject to monitoring by passive wiretappers. And a secure communications line does not have these vulnerabilities. Note that the characteristics of these communications channels are slightly different than what was assumed in phase I.

In this second project phase, we are concerned with teller terminals. These are standard PC computers that run Java and do local processing. All human interaction with a teller terminal is through a keyboard and mouse; attaching smart-card readers or other specialized input devices is not considered a cost-effective option.

Teller Terminal Access

Staff at bank branches access information about accounts and customers through the teller terminals. Henceforth, we refer to this information as client data. Consistent with the Principle of Least Privilege, access to client data is carefully controlled. Whether a given bank employee is permitted to access any particular piece of client data depends on the employee's job level.

For simplicity, you may assume that there is a fixed, pre-specified set of employee identifiers called userid's.

As part of enforcing authorization of employee access to client data, the bank's computer system authenticates each access request. The mechanism to authenticate requests made at teller terminals is the subject of this phase.

Think of each teller terminals being at any time either inactive or active.

• An inactive teller terminal displays a login dialog box. It invites a user (bank staff member) to enter a userid (possibly along with additional information) and either (i) to initiate a session or (ii) to change his/her password (in which case, the teller is first authenticated using the current password, then the password is updated, and finally a session is initiated with the authenticated teller). In both cases, the information provided is checked for validity. If the information is valid, then the teller terminal becomes active and a session with the branch computer is started.  A changed password is valid only if (i) it is not equal to the old password and (ii) it matches what the user enters when  asked to confirm the new password.

• An active teller terminal displays a dialog box that invites a user to enter an account number.  If an account number is entered, the user is invited to choose Save Bank State, Client Info, or Do Transaction.
  • If Save Bank State is selected, then the bank server writes all current account and client information to disk in a file called Bnum.table.  where num is a branch number. Each time the server is started, it reads this file to initialize the account and client information.
  • If Client Info is selected, then execution proceeds as follows:
    1. Clicking Client Info causes client data for the given account to be displayed. The customer's name, address, social security number, employer, and annual income are displayed, as well as the account's type (checking or savings) and balance.
    2. Any of these fields except the account number may then be changed by editing the  displayed text. Clicking Enter then causes the client data stored by the bank server to reflect the changes. (Phase III will be concerned with implementing a more selective policy regarding client data access and update.)
    3. Clicking Close Info causes the teller terminal to revert back to the main window.  While the client info window is active the main window is disabled.
    4. The Do Transaction button works just as it did for the ATMGUI.

What to Do and How to Do It

Implement an authentication scheme for teller terminals. (You will implement the remainder of the authorization mechanism as Phase III.) Deciding on an authentication mechanism is the first step, and the following information may be helpful in making that decision:

• It is not considered reasonable to expect bank staff to remember and/or input very long strings to authenticate themselves. This precludes using public key cryptography as a source of a "secret" used in proving an identity.
• Because the communications line between the teller terminal and the branch computer system is passively insecure, that line should not carry cleartext passwords or other cleartext that would allow an attacker monitoring the line to later start a session by impersonating bank staff.
• The bank server's memory and the teller terminal's memory is passively insecure, and anything written to the hard drive can be read by an attacker. Minimize the exposure of passwords and other secrets by keeping them in plaintext form no longer than is absolutely necessary.

We have already written Java applications that implement some of the teller terminal 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\PhaseII.Goodies

Download everything there into your own, new directory.

Class TellerGUI displays the login dialog box and is invoked by class TellerOperations. You have access to the source for TellerOperations, and the source has comments indicating (the only) places in the file that you may change. (Making changes to other parts of TellerOperations will likely cause things to break.) You will notice that a skeleton of changePassword has been provided for you to flesh-out as needed.

TellerOperations uses the passively insecure communications line to communicates with BankOperations which, as before, is a Java application that simulates the functionality of the bank.

It would be wonderful if your Phase II submission continues to provide the functionality you implemented in Phase I. But this is not required and we will not be checking whether this ATM functionality works.

Finally, you need only support one teller terminal per bank.

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\proj03.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 re-copy 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 what method you employ for authentication and why you selected that method.  Also explain here what sorts of attacks could be used to compromise your system.

JAVA source files 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:

• The approach you employ for authentication.  Solutions based on Lamport's scheme have the potential to receive higher grades than solutions based on storing encrypted passwords. Solutions that allow the server to be shut down and restarted without requiring changes to data stored or used by clients for authentication will also receive higher grades.
• Is the discussion in Rational.txt compelling, complete, and accurate?
• Does the system operate correctly? How much functionality does it support? (How easily are compromised passwords handled and how securely is information stored at the branch computer, for example?)
• 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?