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