Comp 527: Soda machine project
up to main page
Due Dates (see below)
Scott Crosby's cryptyc tutorial: PDF
This year's smartcard tutorial: PDF
RSA parameter generating code: Owlnet (Sun)
Linux Mac OS X Source
(C, requires OpenSSL)
Grading guidelines
Introduction
This project has three milestones. They'll be graded evenly, and the aggregate
grade will count for 30% of your final grade. You will work in groups of two
(or one three-person group if we're odd) and may choose your partner as you
desire.
Milestone 1 will be to design your system, on paper, and to formally prove
that your cryptographic protocol is secure, using cryptyc.
For milestone 2, you will be given another group's output from the first milestone
and asked to study it. For the third milestone, you will implement your design
using smartcards generously donated to us by Schlumberger.
Overview
In our universe, we have three types of parties: a unique bank, a set of users,
and a set of soda machines. Users all have a bank issued smart card which they
are able to deposit money on at the bank. They can then use their smartcard to
purchase tasty beverages at the soda machines. At the end of each month, the soda
machines submit payment requests to the bank which then distributes the money.
Of course, this universe is full of security problems. What prevents an evil
user from making a fake smartcard and stealing soda? What prevents an evil soda
machine from debiting a user's smartcard for more money than the cost of a soda?
Your design will need to address these problems, and more. The next section
provides a (hopefully) complete specification for your design. If you need any
clarifications, please post on rice.owlnews.comp527.
We'll see your questions and post responses (and update this web page, as appropriate).
Specification
- The bank is trusted by all legitimate users and soda machines.
- The bank must be able to initialize and add money to user's smartcards.
No other party should have this ability.
- The bank must be able to provide secret information to a soda machine that
allows it to debit money from the smartcards and collect money from the bank
at the end of each month. You may assume this initial transfer of secret information
is secure. The bank has no guarantee that the soda machine will behave properly
(e.g. run bank supplied software) after the secret information has been relayed.
- Each month, the bank must be able to take a report from each soda machine
showing how much money has been spent from each card. Given this report (and
any required number of smartcards), the bank must be able to determine if
a soda machine is lying and identify the lying soda machine(s). The soda machines
have a secure channel to transport this report to the bank (i.e., don't worry
about how the reports get from the soda machines to the bank). This is
meant to model a soda employee physically removing a card containing the report
and hand-carrying it to the bank. The channel is, thus, uni-directional. However,
there's nothing to stop the machine from making a false report.
- Each month, the bank must be able to retrieve a report from each smartcard
showing what purchases were made. Any purchase that was made by a smartcard,
but not reported by any soda machine should be refunded to the smartcard.
The user must not be able to cheat the bank out of money in this fashion.
- The smartcard is considered physically secure. We assume that no attacker
(or legitimate user) can read arbitrary data off of the smartcard.
- The initial communications link between the smartcard and the bank used
for programming the smartcard is considered secure. The communications link
between the smartcard and the soda machines and the later connections between
the bank and the smartcards is not.
- Smartcards should refuse to give money to soda machines which have not been
assigned secret information by the bank.
- By giving their smartcard to a soda machine and selecting a product to purchase,
a user is able to purchase a soda (or rather your program will just indicate
when the soda was delivered). If the user's smartcard has sufficient funds,
the smartcard will be debited and the "virtual" soda will be delivered. If
not, the user should be told what went wrong.
- The soda machine should be able to display the price of each soda and the
smartcard balance, both before and after each transaction. We assume that
if the smartcard balance decreases without the user receiving a soda (or our
simulated soda in this project), the user will notify bank immediately (or,
when the user next checks the card's balance). Thus, you only need to provide
a method with which the user can prove to the bank that the soda machine debited
money from the card. Presumably, if the bank detects a pattern of users reporting
a given cheating soda machine, the machine will be caught.
- The soda machines may not communicate with the bank, except during their
initial setup and when transferring their reports at the end of each month.
- Do not use the smartcard hardware PINs. Three incorrect entries of this
PIN and the smartcard will kill itself. The PIN should never be changed and
you may simply assume that an attacker cannot guess the PIN and reprogram
the card. Only the bank (and not the user) knows the PIN. This makes sense
in the real world as "custom" smartcards would be deployed that would not
be reprogrammable.
Your Submission
Milestone |
Deadline |
Details |
1 |
Wed, Sep 18, 11:59pm |
- Design Document
- This should outline how your system achieves all of the design specifications.
Your design should include a list of attack scenarios that you intend
your system to be robust against and explain how you get that robustness.
See milestone 2 for more on this.
- Protocol Proof
- Using cryptyc, you will model (1) the protocol spoken between the
smart card and the soda machine and (2) the protocol spoken between
the soda machine and the bank. You may choose to model them separately,
or as a three-party protocol that occurs simultaneously, but be sure
that any compromises that you make in modelling are reflected in your
design documents.
You will be graded on completeness and attention to detail, but you won't
be graded on correctness. We want to see that you thought about the issues
in your design and that you managed to produce a cryptyc model that reflects
your design and has some meaningful proof of correctness.
Your final submission should be a URL. Your documents should be available
as web pages that are readable by anybody. You may use HTML or PDF for
individual files. Other document formats are not acceptable.
|
2 |
Wed, Sep 25, 11:59pm |
You will be given one of the URLs from another team and
asked to analyze their work. You will be studying their design, and formal
model, from the perspective of an attacker looking to game the system. You
will produce a report, again available as a URL and written with either
HTML or PDF, documenting your results. While there is no pre-set way to
produce such a document, a good idea would be to come up with a list of
attack scenarios (maybe the same scenarios you used in milestone 1) and
try to convince yourself that the design before you is robust against these
attacks. Write down what you find, both positive and negative. If you come
up with a weakness, particularly with the cryptyc model, it would be good
to provide an exploit. I expect these reports will be 5-8 pages of printed
text, including excerpts taken from the other team's documents. |
3 |
Fri, Oct 11, 11:59pm |
Now that you've gotten the above feedback, it's time to actually implement
this using smart cards. By late September, we'll schedule tutorials on
smartcard programming. You might want to consider, while working on the
first milestone, how to keep things simple in your smartcard. A smartcard
isn't exactly the world's fastest computer!
- Code
- You should include three separate programs: the bank software, the
soda machine software, and the software that runs on the smartcard.
Please place these in a world readable directory. This directory should
include three subdirectories: bank, soda_machine, and
smartcard. These correspond to each program and each should include
a README file that explains how to run and operate the appropriate program.
The code will be submitted by providing the path to the directory that
contains these three directories. Your code will be graded on clarity,
completeness, and how closely it follows your design document. Easy
to use GUIs for both the bank and the soda machines are a must. Please
clearly comment what parts of each program provide each part of your
design.
|
In general, your submissions will be done by e-mailing Dennis
with the URLs or directories in question. The deadlines are firm since
the milestones all build upon each other.
Advice
Strive for simplicity. If you must use 'deep mathematics' (e.g., blinded signatures,
zero knowledge, etc) you must state why, and why simpler techniques won't
work; avoid using public key cryptography unless you absolutely need it. Likewise,
when we ask you to discuss different attack scenarios and how you'll address them,
you should think ``out of the box'' on this. Imagine all the different ways things
could go wrong. For example:
- A user determines the key(s) inside her own card (allowing the creation
of counterfeits?)
- A user and soda machine collude (to overcharge the bank?)
- A user determines a key from a soda machine (to lie to the bank about the
machine's activities?)
- A soda machine determines the keys of a user (to lie to the bank about user's
purchases?)
- And so forth...
You'll want to add a lot more and elaborate these scenarios. Feel free to discuss
these scenarios on the course newsgroup. Just don't discuss how you plan to
address them. On the other hand, don't feel obligated to address each and every
thing you hear about on the newsgroup.
Now, in your design document, for each such potential weakness in your list,
you need to state why the attack is addressed, is irrelevant, or whatnot. For
example, you might write why the attack...
- Doesn't matter (a user and soda machine collude to steal soda from a machine?
Huh?).
- Can't happen because of some particular design feature in your protocol.
- Isn't within the design requirments (we can assume that the bank won't trick
anyone).
- Has been 'proven impossible' by cryptyc.
- May be perfectly feasible, but you're just not sure. (Honesty is better
than cluelessness.)
Of course, you may also come up with attacks and/or potential weaknesses specific
to your own implementation. List those as well.
Finally, you might find it entertaining (and enlightening) to read the results
of a paper-only design problem that was offered as an exam
question at Cambridge.
Thanks
This assignment was originally designed with the help of Adam Stubblefield
and wouldn't have been possible without the generous donation of smartcards
by Schlumberger. Scott Crosby also had extensive suggestions and feedback toward
this year's revisions of the assignment.
Dan Wallach, CS
Department, Rice University
Last modified:
Wed 02-Oct-2002 13:06