Comp527: Voting (in)security

Due dates

See the Calendar.

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

We wrote a paper about 2003's Hack-a-Vote experience that appeared in an IEEE magazine. You can also see the slides from a talk I gave on the same topic.

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 the course TA.

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.

Phase One: Crouching Bug, Hidden Trojan

Premise

You are the development team for Hack-A-Vote Election Systems, a major election vendor that has contracts with several U.S. states and counties to supply voting machines. Unfortunately for democracy, you are of questionable moral character, and you've been offered a large sum of money to sabotage Hack-A-Vote's flagship election product.

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 official Hack-a-Vote source code and Javadocs can be found in our Subversion repository.

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. (You may use ZIP instead of tar/gzip. Do not use anything bizarre and proprietary like StuffIt or WinRAR; your peers will hate you.)

  2. A short report in HTML or PDF format (not Word!) 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.

To submit your code and report, see the Subversion page, in particular the section on turning in Phase I.

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.

Phase Two: Crime Scene Investigation

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; not Word!) 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.

(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.)

To turn in Phase 2, check each report into the Subversion repository alongside the code it pertains to. That is, if you (in team 40) received team 60's code in the directory teams/40/phase2/team60/, check your report in as .../team60/report.pdf.

Phase Three: Cancelled

Get started on the FinalProject instead.