Introduction

This project will give you a chance to explore both sides of the security issues involved in building and verifying direct-recording electronic (DRE) voting systems. DRE systems record votes electronically, without necessarily producing a paper record. Their use has been advocated recently, especially after the problems in Florida during the 2000 presidential election. DRE systems promise greater accuracy of recording, increased accessibility for people with various physical handicaps, and no hanging chads. They also put tremendous amounts of trust in the computer to correctly record the votes - if the computer system is wrong, there is no written backup to fall back on. Therefore, security flaws in DRE systems can be called, without exaggeration, threats to democracy.

The project is split into three phases. In the first phase, you will play the part of a co-opted voting machine vendor intent on damaging the election in some way; in the second, you will be an auditor trying to spot problems that may have been introduced. In the last phase, you'll use what you've learned about cryptographic protocol verification to find a solution to a problem discovered in a real voting system.

Related reading

Partners

You're expected to work with a partner. You can choose any partner you like, and if you really want to change partners after each phase, that's okay. We'll allow at most one group of three people, and that's only if we need it to keep the class balanced. Rather than trying to split the work in half, with each partner doing their half, we strongly recommend that you work together, side-by-side, on everything (design, analysis, the works) with only one computer. Change off who is typing once in a while, but go at it together. This style, sometimes called pair programming has been shown time and again to keep people working efficiently. Also, in terms of security analysis or other forms of devious thinking, it's amazingly helpful to have somebody else there to bounce ideas around. Your work, and your grade, will be that much better.

Please report your partner pairings to Seth Nielson, our T.A. You'll also want to set up a web site where you will post all of your results. Make sure that it works and send that to Seth as well.

Grading

Each phase will be graded equally, even though we've given more time to some phases than others. Rather than trying to give you an exact breakdown or point system, we'll be applying a more wholistic approach. You'll be rewarded for being creative. You'll be penalized if your design is obviously broken.

Due date: Wednesday, 14 September 2005, 11:59am

Premise

Assignment

There are any number of ways you could use your position as the supplier of voting machine technology to introduce problems into an election. The obvious thing to do is steal the election by modifying your machine to occasionally change votes to a preferred candidate. There are other nasty things you might do, though - if all of your machines produce uncertain or garbage results, you could cause electoral chaos. You might try to selectively disenfranchise some group of voters you don't like. Be creative; find a way to modify the machines that will create problems of your choice in the electoral system.

You'll implement your changes against Hack-a-Vote's current product. The user interface has already passed approval testing, so don't modify what is seen by an ordinary voter. It's important to keep your changes small in scope and hard to detect via a source code inspection, because later, your classmates will be scrutinizing your codebase trying to figure out what you did. Cleverness in hiding your changes is therefore crucial to your success.

The Hack-a-Vote source code is online
Javadoc is also available.

You only have to worry about your changes being spotted before the election; afterwards, your benefactors have arranged for you to be flown to a location with sandy beaches, scantily clad members of the preferred sex, and no extradition treaties with the United States.

You should submit:

1. A file called yourname-vote.tar.gz which represents your modified version of the Hack-a-Vote system, where yourname is the username of one of your group members.
2. A short report in HTML or PDF format that describes the nefarious modifications that you've made, and why. Come up with a scenario describing who has bribed you to make these changes and how they expect to benefit from them.

Please place these files on the web site mentioned above. Do not make your documents globally visible. Don't link to them from your home page. Just make sure somebody can type the URL into a browser and download the files. E-mail those URLs to Seth.

Please keep your modifications private until after the end of Phase Two. You don't know which group is going to get your code to analyze, and the less they know, the better off you are.

Due Date: Thursday, 29 September 2005, 11:59am

Premise

Real voting machines are audited before they can be sold. Generally, this auditing is done by certified private laboratories that test all manner of functionality and failure modes. These laboratories submit a report with their recommendations to the vendor and interested voting authorities.

Assignment

You will now play the part of an overworked contract auditor. Your job is to analyze the code of two voting systems submitted to you, determine if there are any security problems with it, and write a report (in HTML or PDF format) for the voting officials that indicates what, if any, problems you found and what should be done to mitigate them. You'll receive two codebases with the work of two of the other groups in the class. Read the source code, compile and run it, debug it, do whatever you can to figure out what sorts of Trojan horses may have been introduced. Be sure to answer the following questions:

1. What approach did you take to analyze the code? Describe in detail, including software tools you used. Include approaches you tried that didn't work. Why didn't they work? Knowing what you do now after having analyzed the code, how would you have approached your analysis differently?
2. What problems exist in this voting system?
3. If you found problems that seem to have been introduced deliberately, what do you think the motivation was for introducing them? Who is likely to benefit from the modifications you found?
4. Could you have found these problems if you had not had access to the source code of the voting machine? Why or why not? How much did access to the source speed your analysis?

You probably also want to look over the 2002 "final" voting standards from the Federal Election Commission. Section 6 on the "voting standards" talks about security. In theory, real voting systems are supposed to meet these standards (even though most current systems have not been certified to these standards yet).

Pretend that you don't have the official source code from Phase One from which you could otherwise have computed the diffs. You'll have to be more clever than that. Make your report available at a web page accessible to anyone and e-mail the URL to Seth.

(Incidentally, you will get to read the reports that other groups write about your system. This will help you see how successful you were in phase one.)

Due Date: Friday, 7 October 2005, 11:59am

Why do things manually if we can bring some fancier tools to bear on the problem? What better to read a computer program for bugs than another computer program? Seth is going to take your work on phase 2 and distribute it back to the groups that you analyzed. That means that you'll be getting feedback from two other groups on your own project. You can now see what they found and what they missed.

Your assignment: you will run your own (phase 1) version of Hack-a-Vote through two automated bug-finding tools: Fortify and FindBugs. You must then write up:

• Did either automated tool find your hacks?
• Did either automated tool find other interesting bugs that may potentially be exploited?
• Did either automated tool give output that was unhelpful or even false (i.e., claiming something as a bug that is actually correct)?
• Given what you know about your own hacks and about what these tools could or could not find, hypothesize what kind of automated tool could have found your hack. What sort of analysis would be necessary to discover what you did?

You can download FindBugs from the FindBugs web site. Fortify is a commercial product. The vendor has graciously offered to let you use their product for your Comp527 project. Download and installation instructions will be handed out in class.

Johns Hopkins/Rice study of the Diebold election system

The original idea for Hack-a-Vote came from David Dill at Stanford. Both the code and this assignment were written by David Price (Jones '03, now at UT Law School). Darwin Cruz and Brian Armstrong also contributed to the Hack-a-Vote codebase.