This semester's class project is to design and implement a prototype secure voting system. The main idea is to design a system such that people can vote from any poll site in the country, and not have to be physically present in their home district. With this system, we could eliminate the need for absentee ballots, which are known to be very insecure. The project is totally unconstratined. You can assume whatever you want about the voting machines, how they are connected, and how they communicate. However, you have to justify the assumptions. Some of the challenges are: - each home district has a unique ballot, so if someone from county A is voting in county B, he must be presented with a valid ballot for A - the district where someone votes has to be able to authenticate someone when they walk in the door, so you cannot expect a book with signatures of all voters - if you use the Internet for anything, you have to assume vulnerability to denial of service attacks and the potential for hacking - try to conserve cost as much as possible Projects should be done in groups of 2-4 students. Part 1 of project 20% ----------------- This part of the project is due 9 a.m. on 2/20. Before designing a system, it is important to identify the requirements, both functional and from a security standpoint. This is an important phase of the project. For part 1, you should do the following: 1. Survey the literature of electronic voting for all work that has been done to date related to the problem of voting from remote poll sites. This should include the assigned readings in the class as well as anything else you can find, either published or on the Net. Write a report of all pervious work on this specific problem, citing all sources. 2. Generate a list of functional requirements and a list of security requirements. Identify which requirements you think need to be met, and which ones might be too expensive or unrealistic. Produce a short (1 page) report describing the requirements that you will try to meet with your system. 3. One member of the group should prepare a short presentation for the class on the previous work on the specific problem and of the short report on the requirements that you plan to handle in your design. 4. Begin thinking about the different types of designs you might decide to use. Part 2 of project 30% ----------------- This part of the project is due 9 a.m. 3/6. 1. Generate a design for the electronic voting system that meets the requirements from part 1 of the project. Identify all of the components, design all of the protocols, pick all of the algorithms and parameters, such as key length. 2. The report that you will turn in is a specification of the design. It should include protocol flows and everything you've done to analyze it to try to make it secure. The specification should be detailed enough that someone could just go and implement it. The report should then discuss why the design decisions were made and what the big tradeoffs were. 3. One member of the group should prepare a short presentation for the class describing the design tradeoffs and the choices you made. Then, walk the audience through the design. 4. Make your specification and your report available to the rest of the class on the Web after the presentations. Part 3 of project 10% ----------------- This part of the project is due 9 a.m. 3/20 1. You will be assigned one of the other groups as your target. Read their specification document and the report of the tradeoffs. 2. Analyze the security of the scheme. Try to identify weaknesses and points of attack. 3. Write a critique of the other group's scheme. The critique should read like a security ananlysis report. Identify strengths as well as weaknesses. 4. Turn in one copy of the report to me, and give another copy of the report to the target group. 5. There will be no class presentation of this part, as we are not in the business of embarassing people in front of the class. Part 4 of project 40% ----------------- A progress report on this part is due 9:00 a.m. on 4/10. This should be a one or two page write-up of how you are doing so far. The final part of the project is due 9:00 a.m. on 5/1. 1. Redesign your system, if needed, based on feedback from the group that evaluated your project. 2. Implement a prototype of your system. You can use any programming language you like, and any software tools you can find. If you do use any software packages, make sure that they are relevant, and that they actually make the system more secure and not less. Remember that complexity (i.e. lines of code) make systems more vulnerable, not less. Also, make sure to document what you did and what you used off the shelf. An example software package is a crypto library. You want to find a good one and not develop your own from scratch! Your prototype should show how a person registers to vote, shows how voting takes place, how hometown ballots are distributed, and how votes are tallied. It should also show how disputes are resolved, and if there is universal verifiability, how that is achieved. Basically, it should show off the system. My recommendation is that at least one person in the group be in charge of user interface implementation. 3. Here's what you turn in: - a report describing the implementation and discussing the tradeoffs that were encountered. Include screen shots and a walk through of the system when it is running. - code listings for all code written by you. Code should be well documented. - a description of all of the weaknesses of the implementation, what is missing, what could not be done, and why - finally, the report should make recommendations as to whether real public elections in the US should allow remote poll site voting, and include justification based on what was learned working on this project. 4. One member of the group will present the system to the class. The presentation should include an explanation of the design and the implementation, and a demo. If you cannot demo on a laptop, then provide screen shots and walk the class through the demo, and then I will meet you outside of class for a demo. Preferrably, try to arrange for a demo in class.