Design protocols and add code necessary for enrolling and authenticating
users in your social network system.
Assume an adversary that is capable of (at least) the following
kinds of attacks.
-
Reading and/or modifying messages sent between the Social Network Server and
the Client GUI.
-
Injecting arbitrary messages destined for the Social Network Server or
for the Client GUI.
-
Causing an arbitrary program to be executed on the same computer that
executes the
Social Network Server (but not while that computer is
actually running the Social Network Server).
-
Accessing any long-term storage (e.g., disk) used by the Social Network server.
(Recall, no long-term storage is connected to the computer that runs the
Client GUI).
Recall, you are restricted to using certain Java functionality and packages.
Review that list in the general description for the project.
Also, review the restrictions described there concerning keys and secrets.
Resist the temptation to build or access implementations
of standard industrial-strength KDC protocols,
such as Kerberos, Needham-Schroeder, Otway-Rees, TLS, SSH, etc.
Instead, think about what properties your
system requires when authenticating users and what set-up assumptions are reasonable.
A simpler protocol that you design yourself for this application should suffice!
Do you need a protocol that authenticates a human user to the Client GUI?
One that authenticates a human user to the Social Network Server?
Or one that authenticates the Client GUI to the Social Network Server?
Etc.
We impose no restrictions
on what information a user could be expected to enter
prior to accessing the systems, but
unreasonable expectations are unlikely to attract a large user base (or to be rewarded
with a high grade).
Here are some common mistakes to avoid.
(If you find any of these hints cryptic, then do some reading.
An educational goal of this course is helping you
to become comfortable with learning relevant technical content, as needed.)
-
It is a mistake to believe that encryption alone protects the integrity of
messages.
-
It is a mistake to use ECB (Electronic Code Book) mode encryption.
-
It is a mistake to use random numbers that haven't been provided by
a secure random number generator.
-
It is a mistake to choose key and nonce lengths that are too short or that have
unjustified lengths.
-
It is a mistake to ignore cryptographic issues connected with
"padding" when using a block cipher.
-
It is a mistake to make assumptions about when and how content on
memory or disk becomes unreadable, unless you have employed the special
routines available for deletion of such information.
Submission Procedure.
All submissions should be made through
CMS.
Submit the following files (at least) as part of a .zip:
-
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 system.
Expect the grader to spend approximately 10 minutes on this task, so try the process
yourself with a stopwatch to
check whether the grader might be able to fulfill your expectations.
- A tutorial that the grader can follow to run your software and observe
that it does what it should.
-
PROTOCOL.txt
A description of the authentication protocol. (At most 4 pages of text.)
-
Briefly state the goals of the authentication protocol.
When the protocol ends, what should each principal believe?
-
Explain any set-up assumptions. This is also the place to explain the
enrollment protocol you implemented.
-
List the message-exchange
steps for authenticating a user, using the style
employed in the readings and lecture to document
the sequence of steps and depict the contents of each message.
-
Explain the basis for your choices of nonce sizes and key lengths.
-
Itemize the files, classes, and routines the grader should consult
to see the implementation of your protocols.
-
Source files that contain the source code needed to compile and run your system.
Grading Process.
Sign-up for a 1-hour system demo and group interview.
The sign-up sheet will be posted outside Upson 4115 at or before
11:25am on Friday 3/16.
Interviews will be scheduled starting on March 26, 2012
(location to be announced).
Your entire group must be present for the interview.
At the interview, a member of the course staff will:
-
Attempt to follow your instructions in README.txt
to "install" your system on a test machine.
-
Attempt to follow your instructions in README.txt
to operate your system and observe it working as it should.
-
Discuss design decisions.
-
Discuss you implementation, and review your code for clarity and style.