eVotingProject: Hack-a-Vote

Thanks to http://accurate-voting.org/ and Dan Wallach for permission to use this project.

Overview

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 two 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.

Dan Wallach and his team 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 Dan Wallach gave on the same topic.

Part 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. However (see clarification above), you are allowed to insert error messages, disable buttons and otherwise make small changes to the user interface.

Note that it's important to keep your changes small in scope and hard to detect via a source code inspection.

The official Hack-a-Vote source code and Javadocs can be found in the distribution below:

• hackavote.tgz: hackavote.tgz

Move the hackavote.tgz to its own directory and use tar xzvf hackavote.tgz to unpack the archive in that directory.

Read the README, it tells you how to use the system. The README provides a good explanation of how to use system. However, the short version is:

• Use ant to compile the code. This will place the compiled code into the build directory.
• Change directory to build, run java Console to display the voter PINs.
• Copy the configuration file form from the parent directory (cp ../form .) into the build directory because BallotControl assumes that the configuration file form is in the same directory as the executable. Now cast a vote by running java BallotControl.
• When you have voted early and often, stop the election. You can do this by entering a voter PIN into BallotControl, entering the administrator password (secret) and clicking on the button election over. The results are written to the directory ballotbox.

You only have to worry about your changes being spotted before the election; afterward, 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 New Zealand.

What to Submit

You should submit:

• A file called yourname.tar.gz which represents your modified version of the Hack-a-Vote system, where yourname is your username and group is the name of one of your group members. (You may use ZIP instead of tar/gzip.)

• A report in PDF format that describes the nefarious vulnerabilities that you've introduced, and why.

To submit your code and report, see the submission page, in particular the section on turning in Phase 1. Please keep your introduced vulnerabilities and associated code 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.

Report Format

Refer to this this page for the format.

Phase Two: Crime Scene Investigation

Premise

Real voting machines are (allegedly) 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 the 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. Below you will see two codebases from a previous year. 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:

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? What problems exist in this voting system?

If you found problems that seem to have been introduced deliberately, what do you think the motivation was for introducing them (ie what vulnerability has been introduced)? Who is likely to benefit from the modifications you found?

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?

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.

What to Submit

You should submit a report in PDF format that describes the results of your auditing of the code.

Report Format

Here is a rough outline with some notes on how much I am expecting you to write.

Codebase to Analyse

Daniel, Trae and Rui

• t9-src.zip

Abdul, Marco and George

• t1-src.zip

Grading of Phase One and Two

A grading rubric will be used.