Voting project

DUE 12/05 23:59


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.

DRE promise greater accuracy of recording and increased accessibility for people with various physical handicaps. 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 protocols to find a solution to a problem discovered in a real voting system.

Part 1: Damaging the election (40%)


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.


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. Cleverness in hiding your changes is therefore crucial to your success.

The Hack-a-Vote source code is found on the main assignment page.

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, blue skies, and no extradition treaties with New Zealand.


You should submit

A file called yourname-vote.tar.gz or which represents your modified version of the Hack-a-Vote system, where yourname is your username.

A short report in PDF format that describes the nefarious modifications that you've made, and why. This should be on the order of 2-3 pages and include code snippets. Come up with a scenario describing who has bribed you to make these changes and how they expect to benefit from them. You will also be demo'ing this to Ian after the break.


Rather than trying to give you an exact breakdown or point system, we'll be applying a more holistic approach. You'll be rewarded for being creative. You'll be penalized if your design is obviously broken.

The criteria for comparing the submissions are:
  • Creativity of solution (for example, an obvious inclusion of IF MY_CANDIDATE GOTO WIN would rank lower than one involving multiple components each subtly changed as would a simple implementation of the simple hack from the article).
  • How well does it work (you get to demonstrate it to me after the break, you can get partial credit if it doesn’t work btw).
  • Ability to communicate what was done (report reads well, covers all required aspects
and is spell checked).

The overall result will be a letter grade based upon the criteria above.

You should submit only ONE backdoor, your best most creative one.


The provided Makefile is used to re-compile the system before installation.

All the voting machines are connected to each other on a LAN but have no Internet connectivity.

You not allowed to make any visible changes to the user interface.

Part 2: Saving the election (40%)


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.


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

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


You should submit a short report (in PDF format) for the voting officials that indicates what, if any, problems you found. Describe how you went about doing the analysis and include code snippets as appropriate. This report should be no more than 8 pages long.


Rather than trying to give you an exact breakdown or point system, we'll be applying a more holistic approach. You'll be rewarded for being creative. You'll be penalized if your design is obviously broken.

The criteria for comparing the submissions are:

  1. Did you find the backdoors you were given?
  1. Did you understand how the backdoor is activated?

  1. Did you understand the effect of the backdoor on the election?
  1. Did you follow a systemic approach trying a range of techniques?

  1. Did you reference the FEC election standards?

  1. What is the quality of writing and presentation?
The overall result will be a letter grade based upon the criteria above.

Phase Three: Back to the Future (20%)

You've spent some time learning about designing correct cryptographic protocols. One place in some election systems where a crypto protocol is appropriate is when the user is authenticated as a properly registered voter who has not voted before. Many DRE systems use a smart card issued to the voter either at the polling place or before the election to perform this authentication.

It's important that the protocol used allows the voter to remain anonymous, since a secret ballot is a goal of the election system. It's also important that the voter not be able to supply proof of his ballot choices to a third party; this prevents vote-buying and undue influence by employers, family members, and so forth.

Diebold's AccuVote-TS system, which has been used in actual elections, uses the following protocol:
  1. User inserts smartcard into machine, which prompts for a PIN.
  2. Machine sends the PIN to the Card.
  3. Card returns to the Machine either OK or Not OK
  4. Card responds "OK" iff the PIN is correct and this is the first use.

This protocol does not use cryptography improperly - it just doesn't use cryptography at all! The major problem here is that a voter could sneak in his own card that always responds "OK." This would permit multiple votes.

Your job is to produce a model for smartcard distribution and a protocol that meets the following security goals:
  1. Only registered voters may vote.
  2. All registered voters have the opportunity to vote.
  3. No one may have more than one vote tallied. (You may solve this either by making multiple votes impossible, or by detecting multiple votes).
  4. No ballot image can be traced back to the voter who cast that ballot by anyone, including the election authority. Be sure to describe when information is deleted, if your protocol makes throwing away information necessary.
  5. Voters cannot prove that they voted for particular candidates. You may assume that votes are cast in a private environment and the voter's interaction with the system is not observed by anyone else.

Voters are divided into precincts, districts served by one central polling place. A voter may vote only at the polling place for his or her precinct, but there may be several voting machines at the precinct, and the voter will use whatever machine comes available first.

You may assume that there is an out-of-band method of identifying registered voters and providing them with their correct smartcards; however, you may not assume that registered voters will necessarily be motivated to keep their smartcards to themselves. Think about the problems that might be caused by voters trading or selling cards, and the methods (technical and administrative) that you would use to mitigate these problems.

You should use the notation introduced in the textbook to describe security protocols.

Your submission

  1. Design document: A report (PDF) that describes your scheme in detail, and the administrative actions by the voting authorities that would be required to support it. Be sure to sure to include a list of attack scenarios that you intend your system to be robust against. Argue in your report that your approach is correct, that it meets the security goals above, and that it is in fact robust against the attack scenarios you considered.
  2. Protocol Proof: Using BAN logic, model the protocol(s) spoken between the smart card and the voting machine, and also between the smart card and any other devices it may need to speak to. Be sure that any compromises you make in order to produce a BAN model of your system is documented.


You will be graded on completeness and attention to detail, but you won't be graded on correctness (you should make an argument but I'm not expecting it to be perfect, its more the attempt that counts). We want to see that you thought about the issues in your design and that you managed to produce a BAN model that reflects your design and has some meaningful proof of correctness.

The criteria for comparing the submissions are:
  • Use of informal reasoning to support argument around correctness
  • Completeness (with respect to the desired policy)
  • Attention to detail (how precise is your description of the protocol)
  • Use of standard notation to describe the protocol
  • Use BAN logic to attempt a formal argument about belief in the authenticity of the voter

The overall result will be a letter grade based upon the criteria above.


Strive for simplicity. If you must use 'deep mathematics' (e.g., blinded signatures, zero knowledge proofs, etc) you must state why, and why simpler techniques won't work; avoid using public key cryptography unless you really need it. Likewise, when we ask you to discuss different attack scenarios and how you'll address them, you should think "out of the box." Imagine all the different way things could go wrong. For example: * A user determines the key material inside her own card (allowing the creation of counterfeits?) * Many voters collude to introduce some problem into the system * A malicious party arranges for a voting machine to fall off a truck on the way to the poll site and so on.

You'll want to add more and elaborate on these scenarios. Feel free to discuss them on the course forum, but don't discuss how you plan to address them.

If you don't believe an attack is feasible because of some external administrative procedure ("We strip- search all voters to make sure they haven't brought in a hacked smartcard"), say so, but back up what you say with a sound argument.