PART I: BASIC INFO 1. What is the name of the Project? MIT Cryptographic Card 2. Has the project ended? No 3. If the project is still running, please provide an estimated date for completion. Otherwise, enter the actual end date. Sept. 2002 4. Please list the MIT people involved in this project and their roles. Christopher Laas: principal investigator Jen Selby: new convert 5. Please list the software technologies employed by this project, and how they are being used. cryptography embedded software (smart cards) distributed systems PART II: OBJECTIVES 6. Please provide a brief (2 paragraph) summary of the overall project objectives. The project aims to develop a smart-card-based security infrastructure for the MIT campus, performing the functions of authentication and authorization for all current cardholders. The platform developed by the project should be sufficient to subsume all of the functions of the current MIT Card; in addition, it will perform all these functions without compromising either the security interests of the provider or the privacy interests of the card-holding user. Fundamentally, a cryptographic public key infrastructure such as this project intends to create is a framework that allows individuals and organizations to define and enforce contracts about the way information about them is collected and handled. The individuals using the system will be empowered by this new ability; the organization administering the system will benefit by the security improvement over mag-stripe technology, and by the goodwill that results from an open trust relationship. A trust relationship in which individuals exert control over information about them is especially important in an academic environment, where freedoms of expression, movement, and action are particularly valued. 7. Please discuss your progress relative to your originally proposed schedule. Overall, progress has been slower than initially expected, basically because finding people with talent and with time to work on the project has been much harder than we expected. Because I worked on the project full-time over the summer, our summer schedule proceeded essentially as expected; however, as term began, the project fell into a predictable-enough slumber. Most of the schedule items up through January 2001 have in fact been completed: I've written comprehensive design documents, have done a wide survey of existing hardware and software related to the task, and have a large chunk of the software protocols worked out. However, the software development slated for Fall 2000 and the design release slated for January never happened, due to hosage. 8. Which milestones have been completed? A full scope document has been written; the evaluation of existing systems has been done. That makes two out of three for the first year. 9. Do you wish to modify any of the original milestone deliverables or dates? If so, please explain. I still hope to release the design documents for public inspection, but they need some touching up; I'm currently pushing to finish them by the end of term. The software effort is beginning late, but now that I have made some headway in hiring, we may see some real progress soon. If we have a successful summer, we may be able to get back on schedule without much trouble. To tell the truth, I figured that term-time would be slow, and took that into account when I wrote the schedule in the first place. Finally, most of the references to hardware development in the schedule are now irrelevant, since we decided early on that the hardware platform would not be developed in-house. 10. If necessary, please provide an updated timetable and set of milestones. The following modifications should be made to the schedule: Spring 2001 Begin development of a reference software implementation. May/June 2001 Release initial system design for peer review. Also, all mention of in-house hardware should be removed as irrelevant. PART III: RESULTS 11. Please list 3-5 project accomplishments for this six-month period, with a brief one paragraph description of each. In very roughly chronological order: The requirements for and constraints on the system have been extensively documented. The system must implement identification, group authorization, pocket-change, and administrative functions at minimum; it must scale to encompass a large organization; and must admit of decentralized control and yet incorporate sound data quality and privacy policies. Potential hardware platforms for the user token were reviewed, including several smart cards, the "iKey", the Gemplus CAFE token, and PDAs. Of course, no existing hardware platform is ideal for the demanding application in mind, but there are promising possibilities. The design of the system has been described in detail; in particular, the protocols to be used in the system for the identification, cash, group authorization, and administrative functions have been specified. The hierarchical organization of the system, and the various abstraction barriers and interfaces, have been documented. As a result of independent interest, a new privacy-protecting practical group authorization protocol had to be designed, based on the Ohta-Okamoto-Koyama system for group authorization. If given some time to work on this, I will turn it into a proper paper suitable for publication. 12. What are the major conclusions and results of the project to date? The project is still in its design phase, and hence few conclusions have been made. The original possibility of developing hardware in-house has been discarded as impractical given budget and time constraints, but this is hardly a general conclusion. As I mentioned above, the group identification protocol is of independent interest, as it is the first protocol with reasonable performance which could protect the privacy of private-key-users in an access control hierarchy. 13. Please list all publications resulting from this project. Where possible, provide web links to the actual publications. A Secure Successor to the MIT Card (Scope document, rough draft) http://www.mit.edu/afs/sipb/project/mitcard/doc/functions/functions.pdf Protocols for Use in the New Identification Scheme (rough draft) http://www.mit.edu/afs/sipb/project/mitcard/doc/protocols/protocols.pdf (The other documents in the hierarchy are working drafts, not in the same state of completion as the above, essentially final, drafts.) 14. For all publications without web links, please combine the electronic copies into a single zip file and attach it. N/A 15. Please list all public presentations of the project work (eg, lectures or conferences). Include the date, location, type of audience, and a web link to the presentation. N/A 16. For all presentations without web links, please combine the electronic copies into a single zip file and attach it. N/A 17. Please provide web links to any project-related websites, demos or working systems. Remember to include any login information necessary to access the sites. N/A 18. Please list any materials currently being developed as part of this project (eg, software or scholarly reports). We're beginning development of a reference software implementation. PART IV: COLLABORATION 19. Who at Microsoft have you collaborated with during the last six months? Describe the collaboration. I worked in the Cryptography group at Microsoft, and especially with my friend Josh Benaloh. Microsoft provided a good environment for my design process; and Josh, in particular, was a great sounding board for my ideas and also a fount of knowledge about the issues of practical cryptography. 20. Who at MIT have you collaborated with during the last six months? Describe the collaboration. The SIPB has been an invaluable asset when it comes to down-to-earth computer systems work. I probably haven't drawn on the LCS crypto group as much as I should have, however. 21. Who outside of MIT and Microsoft have you collaborated with during the last six months? Describe the collaboration. I spent a lot of time trying to break through Gemplus's corporate barrier, but it was essentially a one-way thing --- the people I needed to talk to there were too hosed to help much. Maybe I should try again. PART V: FEEDBACK 22. What challenges are you currently facing? How can we help? The primary challenge is, predictably enough, hosage. The project can only progress if it's possible to devote some significant chunks of time exclusively to it, and this is an unusual circumstance with undergraduates. Some projects have disintegrated under this pressure, and this one has suffered attrition. I've found that in my experience at MIT, any given project can only survive if there's one or two leaders who really care about it, and a certain critical mass of other people who can devote some mindshare to it. For the past few months, this project hasn't made much progress because of a lack of the second factor; the reason it hasn't disintegrated like others that initially had more people is that it does have a core person who really cares about it. I think the best way to get it back on track is to reach the critical mass of other contributors. Currently, I'm trying to fill those slots with undergraduate hires; they usually have to learn quite a bit before they can contribute much technical help, though, which is discouraging for them. Solving this problem is largely a matter of time and money; offering unusually high wages will help to induce hosed undergrads to substitute more sleep for work, and allowing a bit of time for training may leave us with some smart reliable workers. It would be a great help to be able to hire an MEng student as an RA working on the project; an MEng student would be much more likely to have the necessary background, and would also be more likely to devote a big chunk of time to the project. I don't think it's obvious that we can clear the administrative and budgetary hurdles, though, so I'm not sure it's a feasible solution. Finally, I'll have to admit that a major challenge the project faces as long as it consists primarily of me is my own hosage: I'm taking five MIT classes, running the Underground Guide, preparing for entering the PhD program, searching for an apartment in the Cambridge area, searching for a summer job so that I can pay for said apartment, and on top of it, trying to make headway on this project. I'm not sure there's anything you can do about this (though suggestions are appreciated! :) but I felt it would be only honest to mention it. 23. Please provide the Joint Steering Committee with comments on how the iCampus process is proceeding from your point of view, and any suggestions for improvement. I'm not sure if you're asking for reflection on the iCampus project in general, or on this project in specific, so I'll address both. I've heard that some of the student projects seem to be floundering in one way or another. Partially, this is possibly due to the inexperience of undergraduates in running major, largely independent, projects. However, it's also possibly due to the makeup of the groups; if they're just composed of a bunch of people who thought it might be neat to hack on a problem for a while, they might disintegrate under the strain of undergrad existence. Perhaps in the next round you should consider whether groups have one or two core people who are going to keep a project moving by sheer will (because sometimes that's what it takes). But perhaps I'm prejudiced. In any case, when I've asked for iCampus support, I've gotten it in as timely a fashion as could be expected; the problem in that arena has mostly been that it hasn't even occurred to me to ask for iCampus support. For example, I didn't even know that I should talk to Bill Fitzgerald about hiring until recently. Perhaps a document summarizing what other groups are doing through iCampus would help? I think the iCampus support has been fine, altogether. The slowdown in my project has been primarily due to the problem which always plagues MIT undergraduates: lack of time to actually do the substantive work. I'm not sure administrative changes can do away with that problem very easily.