Electronic Voting System (Phase III): Trapdoors and Trojans

Due: 10:00am Tuesday, April 20, 2004

General Instructions. Students are required to work together in groups of size 3 or 4. An assignment submitted on behalf of a "group" having fewer than 3 students will receive a grade of F. All members of the group are responsible for understanding the entire assignment and will receive the same grade.

You need not work in the same group for this phase as you did for Phase II.

No late assignments will be accepted.

Academic Integrity. Collaboration between groups is prohibited and will be treated as a violation of the University's academic integrity code.

Purpose of Assignment

Losing a needle in a haystack is easy; finding one is not. The same holds for planting versus detecting trapdoors in software systems. However, unlike lost needles in haystacks, experience in planting trapdoors does provide a useful background for finding them. This assignment will help you get that background.

In doing this assignment, you are not restricted to using your own group's Phase II implementation. Feel free to use a working implementation from another group, if you feel this would simplify your task.

The Task at Hand

A variety of behaviors would constitute a compromised election:

• An attacker setting the outcome of the election, independent of what candidate a majority of the registered voters actually select.
• An attacker setting for which candidate one or more voters cast their votes, independent of how each voter actually voted.
• An attacker voting one or more times in a given election without being a registered voter in that election.
• An attacker, who is a registered voter, voting multiple times in a given election.
• An attacker blocking one or more specific voters from casting votes.
• An attacker learning which candidate received votes from one or more specific voters.
• An attacker who is a registered voter learning what candidate has the most votes in an open election.
• An attacker learning which candidate received votes from any specific voter.

For this phase, modify a working Phase II implementation in a way that permits attackers to compromise elections in one or more of the ways outlined above, where your modifications to the source for Phase II are not readily apparent to somebody visually inspecting the source code or testing the system. (Assume inspectors do not have access to the source for the Phase II you started with, so running diff or some similar tool is not an option for them.) This exercise should demonstrate just how easy it is to sabatoge our electronic voting system from the inside by creating infrastructure that allows elections to be compromised.

Design Notes

• Assume that the attacker will execute a program on some workstation that is connected to the network on which the electronic voting system runs. Thus, the attacker has the means to communicate with any software that is part of the electronic voting system. For your prototype deployment (and for grading), the attacker's program will be executed on the workstation that is hosting the client and server.

• Software producers sometimes distribute their source code in a form that is difficult to read. Variable names are changed to nonsensical strings, comments are deleted, and indentation is altered so that readers will have difficulty understanding how the program works; control structures might even be changed to equivalent but less obvious forms. This is a form of "security by obscurity" and it thus has limited value for implementing confidentiality. Such source code obfuscation for our electronic voting system would make it more difficult to grade your assignment and might make it only slightly easier to "hide" trapdoors that you create, so we prohibit the use of obfuscation for your source code. Trapdoors you create should instead be hidden by disguising them as clever features, as design or implementation optimizations, or in other ways. Be clever and impress us!

• Denial of service attacks are out of bounds for this phase. Attackers are not permitted to attempt these; trapdoors that enable them or depend on them are not considered acceptable solutions for this phase.

• Only one system is deployed in an election, so all of your trapdoors must coexist in that single system. Make a choice among mutually incompatible trapdoors, including only the "best" one in the solution you submit.

• Serious attackers will have access to a large body of 3rd-party software for network monitoring, control, and other things. Nevertheless, please do not depend on such software for the attacks that you design, simply because the course staff (alas) who must grading your submission will not have the time to install and master these tools.

Submission and Grading

Submission Procedure. Create a .zip file containing the files you wish us to grade. Then submit this .zip file using CMS Your .zip should contain the following files (at least):

TEAM.txt which contains the names (and net-ids) for all team members. Also, for each team member give a 1 or 2 paragraph description of the tasks this team member performed and the number of hours this required.

README.txt which contains:

• Instructions for installing, compiling, and running your software on our Windows system.
• An explanation of each of the 5 (or fewer) trapdoors you added to the Phase II base you started with. This explanation should include:
  • What kind of attack this trapdoor enables. This might be one of the behaviors described above in the definition of a compromised election or some other misbehavior you believe interesting.
  • What changes you made to the original Phase II code and where we can find those changes in the source you submitted.
  • How an attacker employs this trapdoor to perpetrate an attack.
• A tutorial that the grader can follow to start your software and to compromise an election using any additional "attack software-tools" you constructed and provided for this purpose. (Try to make these tools reasonably easy to use, but don't go overboard on the user interface.) Expect the grader to spend at most 20 minutes on this task, and give instructions the grader can follow to launch attacks and observe their impact.

The C# source needed to compile and test your system.

Any other files (e.g., files containing public keys) required for the operation of your system.

Grading. The quality of a trapdoor is defined by (i) how well hidden it is so detection is unlikely and (ii) the extent to which it helps an attacker compromise an election. In the behavior list for compromised elections that is given above, earlier elements are more serious than later ones; higher-quality trapdoors are those that facilitate more-serious compromises.

Part of this assignment involves developing an aesthetic for the trade-off between the power of a trapdoor and the ease of hiding that trapdoor from inspectors. In any real deployment, if an inspector found even a single trapdoor, then the voting system would be disqualified from service. So opting for fewer and more subtle trapdoors is the prudent strategy---and our grading will reflect that.

In light of these considerations, your grade on this phase will be determined by the quality of the trapdoors you create. Think in terms of designing at most five trapdoors. However, grades will not necessarily correlated with the number of trapdoors you provide. Low-quality trapdoors---because they are not well hidden or are ineffectual---will be grounds for assigning a lower grade to this phase (even to the point of detracting from high marks you might earn by also providing high-quality trapdoors).