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,

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.

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:

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


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:


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: