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
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
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
- 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
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
- 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
- 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
- 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.
- 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.)
- 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.
- 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
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
- 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
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
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
- README.txt which contains
- The names and a description of the contents for the other files in
- 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
- 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
- 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
- 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
- How completely does the sample-execution script exercise your system.
- Is the source code easy to understand and does it exhibit good
- Is it possible to successfully attack your system?