Design Project #2 - A "Smart" and Secure MIT Card

Updates to DP2

• (8 April) revised Your instructor may want your report to be turned in as a double sided printout

I. Introduction

When magnetic cards were being debated before their introduction in 1993/94, we undertook a card project in 6.033. More recently, the MIT-Microsoft I-campus partnership provides an excellent opportunity to introduce a smarter and more secure system for daily use. In fact, this issue has already received some attention as part of a student proposal by Chris Lesniewski-Laas et al., sent to the I-campus program.

Your task is to explore the issues involved in making this system work, paying attention to the technological aspects of the problem, but not ignoring important social aspects such as privacy and convenience. Your report should explain:

• What the best choices are,
• How you reconcile sometimes conflicting goals, and
• How to keep the complexity of your design under control.

II. Application requirements

Among other things, the system should allow members of our community to:

• Open doors and other entrances by virtue of their belonging to specific sub-groups of the MIT community, or to the community itself. This might include controlling access to dormitories, and lab or building doors.
• Authenticate themselves to various campus services: computers (on Athena), libraries, athletic facilities, parking lots, etc. It should be easy to use this in different physical environments so that one could (for example), easily authenticate to a parking lot gate before driving through, much like the current magnetic cards allow today.
• Demonstrate proof of membership in various subgroups. For example, the 6.033 staff decides that students are allowed access into the 5th-floor lobby of building NE-43 at certain times of the day as long as they are registered for the class. Such a policy should be easy to install and enforce. Accordingly, it should also be easy to update these lists when membership changes.

The card does not have to support any form of electronic commerce.

Here are some other considerations to keep in mind:

• In many cases, individual privacy should be preserved. In the most basic sense, we do not want a "big brother" in the system keeping track of the times at which particular individuals entered or left a building. A more difficult goal might be to prove membership in a group without revealing the user's identity. Your system may decide to record all entries, some selected subset (e.g. only the unsuccessful ones), or even none at all. Describe your rationale for the choice you made, remembering that the people running the MIT security system may change their mind about the information they want in the future.
• There are some social implications of using the card as the main access to labs and other rooms in a building. With the current combination or conventional locks, it is easy to tell your friends or colleagues what the combination is or give them the key to enter a room. If students have to ask official permission to be allowed in another lab, they may decide it isn't worth it, and this may reduce communication. This is an example of delegating membership in a group. Think about how your system might handle such issues.
• There are also certain abuses that various administrators would like to avoid. For example, the campus parking software would like information to prevent people from using their card to park two cars. Such violations are called "pass-back violations"---one person passes his or her ID card to a friend, and the authorities are interested in preventing repeated pass-back violations.

In summary, the intended uses include: authenticating individuals (proving identity), managing groups (including creation, deletion and maintaining membership lists), authenticating group membership (proving membership in a group, possibly anonymously), and optionally delegating membership in a group to others for some period of time.

III. What is a "smart" card?

A smart card is simply a plastic card with a chip including a microprocessor and non-volatile RAM. Contact-less smart cards are now available that use inductive coupling or radio-frequency fields both to energize the card and to communicate. A key virtue of smart cards over magnetic stripes is that the data in their memory is not necessarily exposed to every reader in which the card is placed. They are much harder to copy (replicate) than magnetic stripe cards. Furthermore, because there is a processor on the card, it can engage in a protocol with a card reader without divulging sensitive information. Thus, one can put secret keys on the card and have its processor engage in an authentication protocol with a card reader. Some smart cards also have the ability to require the user to first authenticate to the card itself by entering some sort of PIN (or password) first.

An example of a simple authentication protocol involving a card reader might go something as follows:

1. Card proves ownership of a private key corresponding to a public key.
   • card presents its public key to card reader
   • card reader sends a randomly chosen challenge C to card
   • card returns a signed version of C to card reader
   • card reader verifies signature of C using previously supplied public key
2. Card demonstrates membership in a group
   • card reader supplies public key of group manager to card
   • card supplies certificate: a version of its public key (above) signed by group manager.

IV. Design tools

Cryptographers have invented a rich set of protocols for handling problems similar, equivalent, or related to the problems described in this assignment. While you are free to explore the cryptographic literature for inspiration to your heart's content, we ask that you stick to the following fundamental primitives:

1. symmetric encryption/decryption
2. symmetric-key MAC's and verification
3. public-key encryption/decryption
4. digital signatures and verification
5. signature or MAC of a challenge to prove possession of a key
6. key generation for symmetric or public-key algorithms
7. cryptographic hashes

You do not need to use all of these primitives in your design. A subset may suffice.

In your design, please use only these primitives and protocols which make use of these primitives. Remember that it is very difficult to come up with a cryptographic protocol that is immune to attack --- if you need a protocol to achieve some goal, it is best that you use one that we have provided you or that is published in the literature.

We do not want you to explore "zero-knowledge protocols," "blind signatures," and other more elaborate schemes here. (Not because they aren't potentially useful---they are---but because this isn't a crypto course and we want this assignment to stay within some reasonable bounds.) We realize that this requirement may eliminate from consideration some solutions with better security or privacy properties; that's OK for this assignment.

Note that the primitives above enable basic ``certificates'' to be formed. For example, Alice may sign a statement of the form:

"Anyone holding the private key corresponding to the public key [specify algorithm type and parameters] may enter door 1234 between the hours of 9AM to 5PM until January 1, 2001."

You should assume that the smart card platform used has the following capabilities:

• It can perform all of the fundamental operations listed above sufficiently quickly.
• There is sufficient storage on the card to store many keys, certificates, or whatever.
• If you decide that your card will generate its own keys, you may assume that the card has access to a good source of randomness.
• Bandwidth to the card is not an issue.
• Supplying power to the card is not an issue.

V. Design considerations

Here are some issues to think about in your design. The list is not comprehensive, and some of the issues may not be relevant to your particular design. You might come up with and discuss some other important issues as well.

1. Clearly think through the set of problems being solved by the smart MIT card. How does it improve on the current magnetic stripe system? Articulate the benefits and disadvantages of your system over the current stripe system? You may also consider the benefits and drawbacks of your system over conventional mechanical keys and locks (which don't log anything!).
2. What different parties (or classes of parties) are involved in the system? What kinds of different goals might each class of user of the system have?
3. What is the overall architecture of your system? Is it centralized, with trusted servers with a public-key database of principals involved in every transaction of a smart card? Or does it permit individual card readers to make autonomous decisions? What are the merits and demerits of either approach, and which did you pick? Which parties are trusting which components, and in what way? Do you assume the existence of any infrastructure (e.g. synchronized clocks)? Is it reasonable to assume such infrastructure?
4. The issue of key management and distribution is particularly important in the design of cryptographically secure systems. Be sure to describe clearly what cryptographic keys are generated and by whom, and how they are protected, stored, and shared. You may also wish to discuss how to recover if certain cryptographic keys are discovered (say by reverse engineering of a card).
5. How is group management done in your system? How easy is it to create a new group of principals and allow them to gain access to some facility or resource? Handling this includes thinking about the following:
   • Configuration. What does it take for the owner of a service or group (e.g., the 6.033 student list or the set of people who can enter my office room) to add, delete, and modify principals from that group? What information is required for this and where is it stored?
   • Delegation. Taking the lab door example above, does your system allow the 6.033 staff to allow 6.033 students to enter a lab room without bothering some other administrator? Can the student pass this privilege on to someone without the knowledge/permission of the staff?
   • Revocation. How does your system deal with group membership management when people have left a group? What about people leaving the MIT community? A plausible approach might involve expirations on certificates, certificates being usable for a certain number of (attempted or successful) uses of a service, or certificate revocation lists being published, or combinations of these techniques.
   • Compromise. How does your system handle lost cards? Stolen cards? Cards that are stolen and returned without the owner realizing it?
6. How should one handle the wide range of social concerns such as individual privacy that improved identification may raise? Does your system have mechanisms that prevent or discourage abuse? What information is logged and by whom? How hard is it to get access to information that is not logged?
   One way to think about privacy is to ask yourself: "Given that I've obtained some convenience, what have I lost in comparison to a world where all doors were opened with conventional mechanical rather than computerized keys?" (On the other hand, perhaps you have gained some advantages...)
7. Security and tamper resistance. Someone hacking into a computer/reader on a door or other such places shouldn't be able to wreak havoc. Does your system handle the possibility of bogus card readers? (This case is similar, for example, to the case where fake ATMs were installed to steal ATM card PINs.)
8. If you are familiar with how Athena's user and list management works, and would like to integrate your system with it, please do so. However, make sure to describe clearly what Athena's environment provides and describe the details of the integration.

VI. Your report

VI.1. Suggestions on Writing Style

Your paper should be as long as is necessary to explain the problem, your solution, the alternatives you considered, and the reasons for your choices. It should be no longer than that. The body of your paper must not exceed ten 11-point, single-spaced pages in length. Please also use 1-inch margins.

A good paper begins with an abstract. The abstract is a very short summary of the entire paper. It is not an outline of the organization of the paper! It states the problem to be addressed (in one sentence). It states the essential points of your solution, without any detailed justification. And it announces any conclusions you have drawn. Good abstracts can fit in 100-150 words, at most.

The body of your paper should expand the points made in the abstract. Here you should:

1. Explain the problem and the externally imposed constraints. You should explain to your intended audience the background of the problem in terms that the audience can understand.
2. Explain and elaborate your solution. Be sure to explain the approach or architecture conceptually before delving into details, components, and mechanics. (Remember, you aren't writing a mystery novel!) Present any analysis clearly and concisely.
3. Show how your solution satisfies the constraints and solves the problem (or how it fails to do so); explain how the properties of your solution that result from choices you have made in your design are reasonable or desirable in the context of the problem statement.
4. Briefly describe the alternative approaches that you considered and rejected, and why you rejected them. Your paper will be more convincing if you say not just why your idea is good, but why it is better than the alternatives. (For example, if another approach would meet all of the objectives perfectly, but the cost would be 100 times higher, then you should mention that as a reason for choosing your less general but cheaper approach.)
5. Document your sources, giving a list of all references (including personal communications). The style of your citations (references) and bibliography should be similar to the styles in the technical papers you're reading in this class. In particular, a bibliography at the end and no citations in the text of your paper is insufficient; we'd like to see what specific pieces of information you learned from where as we read your paper.

Write for an audience consisting of colleagues who took 6.033 five years ago. That is, they understand the underlying system and network concepts and have a fair amount of experience applying them in various situations, but they have not thought carefully about the particular problem you are dealing with.

Assume that your paper will also be used to convince the MIT Card Office that you have a viable design. Give enough detail that they can turn the project over to their Information Technology programmers for implementation with some confidence that you won't surprised by the result.

VI.2. How do we evaluate your report?

When evaluating your report, your instructor will look at both content and writing.

Some content considerations:

• Does your solution actually address the stated problem?
• Do you explain your decisions and the trade-offs?
• How complex is your solution? Simple is better, yet sometimes simple won't do the job. But unnecessary complexity is bad.
• Does your solution fit well with the rest of the system? If your solution requires modifying every piece of hardware, software, and data in sight, it won't be credible, unless you can come up with a very good story why everything needs to be changed.
• How extensible is your design? Are there opportunities for later addition of desirable features that you decided to omit?
• Is your analysis clear?

• Is the report easy to comprehend?
• Is it well organized and coherent?
• Does it use diagrams where appropriate? (A frequent problem when people use word processors is that they try to express everything in words, either because the word processor doesn't make it easy to include diagrams, or they haven't ever learned how to use the drawing features. Pictures can communicate some ideas far better.)
• Does it use the concepts, models, and terminology introduced in 6.033? If not, does it have a good reason for using a different universe of discourse?
• Does it address the intended audience?
• Is there a good abstract and bibliography?

VII. Schedule