Design Project #2: Electronic Transcripts

Your design project report is due on May 9th in recitation.

Questions and answers about DP2 will also be posted here; check periodically for updates.

Introduction

The U.S. Secretary of Education has commissioned a study to determine the feasibility of using cryptographically authenticated grade records as a substitute for the current procedure of sending paper transcripts directly from a college's registrar to the admissions offices of graduate schools to which students are applying. The basic idea is that, at the end of each semester, the instructor of a subject will give each student in the subject an AGR (Authenticated Grade Record), which is a string of bits that represent the student's grade in that subject. The instructor would cryptographically sign the AGR. Instead of obtaining a printed transcript to send to a graduate school, a student can just send his collection of AGR's.

The Secretary of Education wants to explore the AGR approach because it might yield four benefits. First, it could decrease the amount of paperwork involved in applying to graduate school. Second, it could make it harder for students to forge or modify transcripts, or use other students' transcripts. Third, it might give a higher level of confidence to grades reported from schools that no longer exist. Finally, an AGR system could allow the student, or anyone else, to maintain verifiable copies of grades; this requirement means that schools need not bear sole responsibility for keeping backup records of grades.

System Goals

The Secretary of Education has stated the following list of goals for the AGR system. It is not clear that a design could satisfy all of the Secretary's goals; you will probably have to make tradeoffs among these goals, sacrificing some to satisfy others. Part of your job is to choose a good set of tradeoffs, and to explain why your choices make sense.

• Instructors should be able to create AGR's at the end of each semester using just software running on their own computers, and perhaps cryptographic key material or certificates obtained from their university.
• A graduate school should be able to verify the authenticity of an AGR by consulting the AGR and publically available information. It's reasonable for the U.S. Department of Education to publish useful information from time to time, but the amount should be kept to a minimum.
• There should be some way for a graduate school to decide if a student has received an undergraduate degree.
• It should not be possible for students to hide bad grades from graduate schools.
• Any sensitive key material that your system uses might be lost, stolen, or abused. There should be a limit to the problems (for example, potential for forged or unverifiable AGR's) resulting from compromised keys. If there are keys whose compromise would be catastrophic, the design should include a credible plan ensuring that compromise of those keys is extremely unlikely.
• Over time, schools come and go. Ideally, a student's AGR's should be useful for the student's entire life, regardless of whether or not their undergraduate school is still in operation.
• It should be very likely that someone's grades should last as long as their lifetime, even if their house burns down or their school's computer center is wrecked in a hurricane.
• The AGR system should be able to handle as many corner cases as possible. For example, a student might take subjects from more than one undergraduate school, or take a subject more than once. A school might want to change a student's grade (up or down) after issuing an AGR to the student for that subject.
• The AGR system should be easy to understand and use for all concerned.

Design Requirements

• What is the format of an AGR?
• What algorithm does an instructor use to create an AGR?
• How does the instructor obtain whatever cryptographic key material is required to create an AGR?
• How do instructors ensure that they issue AGR's to the correct students?
• How does a graduate school decide if the AGR's that a student presents in the application really belong to that student?
• What algorithm does a graduate school use to verify an AGR?
• How does a graduate school decide if a student has received an undergraduate degree?
• Why is it unlikely that a student could forge or modify an AGR, or use another student's AGR?
• For each piece of sensitive data (e.g. cryptographic private key) in your design, how do you cope with that data being lost? How do you cope with it being stolen? Alternately, how do you ensure that the key has a very low probability of being lost, stolen, or abused?
• If the Department of Education needs to exchange information with individual schools, or publish information, what is the format and purpose of that information?
• Please provide a table listing all the significant assumptions that a graduate school must make to trust that an AGR is authentic.
• What weaknesses does your design have? What are the most likely ways that students could abuse your system? What parts of your design are users likely to find the least convenient?

Your Report

Your report should answer the specific questions listed above under Design Requirements. A reader should also be able to understand how your design would work in a typical scenario such as the following:

1. Alyssa Hacker takes some set of MIT subjects as an undergraduate, and receives grades for them.
2. One summer Alyssa takes a class at Northeastern and receives a grade.
3. In the fall of her senior year, Alyssa applies to Harvard's PhD program in Computer Science; her application includes all her grades.
4. Harvard receives Alyssa's application and processes it; part of the processing involves validating the authenticity of Alyssa's grades.
5. In the spring of her senior year, Alyssa receives an undergraduate degree in computer science from MIT's EECS department.
6. When Alyssa starts at Harvard, Harvard checks that MIT really did award her an undergraduate degree.

Your paper must not exceed ten 11-point, single-spaced pages in length. Please use 1-inch margins. Don't forget to use diagrams where appropriate.

Writing Suggestions

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. Again, please make sure your paper is no longer than ten pages.

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. Give enough detail that your design could be turned over to some programmers for implementation with some confidence that you won't surprised by the result.

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

Go to 6.033 Home Page

Questions or Comments: 6.033-tas@mit.edu