Electronic Voting System

Electronic Voting System (Phase II): Bogus Clients and Client Crashes

Due: 10:00am Thursday, April 1, 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 I.

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

Authenticating a processor is one thing; authenticating a human is quite something else. This assignment will enable you to gain familiarity with the issues involved---technical issues and human factors. The assignment will also demonstrate how eliminating vulnerabilities can sometimes simplify the task of recovering from failures.

In doing this assignment, you are not restricted to using your own Phase I implementation. Feel free to use an implementation from another group, if you feel this would simplify your task.

Vulnerabilities To Address

Extend your or some other group's Phase I implementation to eliminate the following vulnerabilities:

Unauthorized human voters casting votes.
Authorized human voters casting more than one vote in the same election.
Rogue programs casting votes without consent or participation of a human voter. That is, defend against programs that an adversary might write and deploy on the network in order to cast votes by itself for one or another candidate. However, you may assume that the adversary is unable to compromise a client machine that is in use by a voter.
The computer or software running the client crashing or the TCP connection linking the client and server breaking. (Assume the computer executing the server never crashes.)

Design Notes

Voter Authentication. Authorization checks for determining whether a vote should be counted are best located in the server, since the server must already be trusted for other reasons. The server should, therefore, implement

a means to authenticate a (human) voter, and
a means to determine whether a vote being cast by that voter is authorized and thus should be counted in the given election.

To avoid trusting the client system with a secret for any extended period of time, it is best that it be the voter (and not the client) who remembers any secrets being shared with the server.

You may assume that, in order to register, the human voter will be physically present at the site hosting the server. So augment the server management interface with a GUI that allows an election official to register a voter in any given election E for which that voter should be authorized --- votes received by a server are ignored if the voter is not found to be registered at the time the vote is received. You will want to provide some means by which the voter can use a GUI at the server to enter some sort of (secret) pass phrase which, thereafter, is used to authenticate that voter in connection with election E. (A voter must separately register for each different election in which that voter is authorized to cast votes.)

The server management interface should also allow an election official to remove a voter from the registered voters for E. The election official should have to type the entire voter's name into the GUI in order to accomplish this remove operation, and vote counts are unaffected by performing this remove operation (even if a vote from this voter has already been added).

The lists of voters and any information derived from associated pass phrases should be preserved across invocations of the server in order to eliminate the need for voters to reregister for an election the next time it is repeated.

The client's GUI must also be modified so that each voter is prompted for a secret pass phrase when casting a vote. The client system should not store the secret pass phrase in memory or on disk any longer than necessary, as a defense against attackers that might compromise the client system after a vote has been cast. The interpretation of "necessary" in the previous sentence is a matter of taste; a voter should be willing to retype a secret pass phrase if (for example) there has been a crash or after a long period of inactivity but (for example) could justifiably be annoyed at having to retype the secret pass phrase before each message is sent as part of the voting protocol.

If the User Name/Pass pharse pair supplied to the server is invalid, the server should disregard the vote and return the appropriate message. If only one out of the two (User Name and Pass phrase) is valid, the server should not indicate which one was valid because it simplifies the brute force attack. So please make sure you client does not display "Invalid User Name" or "Invalid Pass phrase" but only "Invalid UserName/Pass phrase" message.

Crashes and Disconnects. We can leverage functionality that prevents a single voter's multiple votes from being counted when attempting to tolerate client crashes and/or broken TCP connections. After a client crashes, simply start that client again from the beginning; if a TCP connection breaks, simply start the client again from the beginning and have the server terminate the thread serving that connection.

Authorization. A vote should be considered authorized if (i) it was cast by a voter who is registered for this election and (ii) this same voter has not already cast a vote for this same election. Only authorized votes should be counted. To implement authorization, the server must not only manage a list of voters who are registered to vote in each election but the server must also store information about who has voted.

Storing a list that contains only the names of voters who have voted in each election might not suffice. Consider the following scenarios.

Scenario I. A registered voter attempts to cast a vote, but the client system crashes before the GUI displays "Vote Tallied" message. So, the voter restarts the client, votes again for the same candidate, and this time there is no crash.
Scenario II. A registered voter succeeds in casting a vote. That voter then attempts to vote a second time, but for a different candidate.

In Scenario I, depending on when the client system crashes, it is possible that the server will see two (identical) votes being cast on behalf of this voter. The server must consider the first vote to be authorized (hence it is counted) and the second vote to be unauthorized (hence, not counted). After the client is restarted and the vote was cast for the second time, the client's GUI should display the "Vote Tallied" message (since a vote from this voter for this candidate has been counted).

In Scenario II, the client GUI should display the "Vote Tallied" message after the first vote but not after the second. Since the client distinguishes between the two scenarios (by displaying different messages), the server must provide enough information to make this distinction. And that implies the server must store more than the identity of each voter who has successfully cast a vote.

Note, providing a "receipt" that allows a (human) voter to prove he/she voted for a specific candidate is arguably unwise, because it allows voters to sell their votes. So be careful that an acknowledgment does not allow a voter to prove how it voted to others. Also be careful that acknowledgements do not allow attackers to deduce what votes were cast, either by reading acknowledgment messages or by abusing the protocol and communicating with the server.

Long Lived Servers. It should be possible for an operator to stop the server using the server management interface. Stopping the server should cause all open elections to become closed.

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

The names and a description of the contents for the other files in the directory.
Instructions for installing, compiling, and running your software on our Windows system. You do not need to provide a detailed explanation of how to use your program, unless some part of it is particularly unintuitive.
An explanation of the modifications you made to the Phase 1 solution you started with. A diagram of the messages exchanged between the client and server by your protocol, and their contents, is MANDATORY. We will read through your code, but we want to understand how it works by reading your writeup first.
A tutorial that the grader can follow to start your software and to convince himself that your system implements the required functionality. Expect the grader to spend at most 10 minutes on this task.

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.

Optional Part. For extra credit, include a file called AnonymityExtensions.txt containing a discussion (in at most 2 pages) of how to augment the system architecture and your protocols to prevent the server from correlating the identify of a voter and the vote being cast--even temporarily. Outline your solution as a list of protocol steps---here's an example outline for a protocol that might have been used in Phase I.

1.  client --> server:  E
2.  server --> client:  list of candidates c1, c2, ... cn in election E
3.  client --> server: ci  (where ci is one of c1, c2, ... cn)
4.  at server:  E[ci] := E[ci]+1

Then follow the outline with an explanation of why you think it works. Extra credit will be awarded only if all the required parts of this project work properly, are well documented, etc. We encourage you to consult the published literature in solving this optional part, but we expect a solution that is tailored to the particular protocols that you already have implemented for this phase.

Grading. Your grade will be based on the following elements:

How your system design handles
- Unauthorized human voters casting votes.
- Authorized human voters casting more than one vote in an election.
- Rogue programs casting votes without participation of a human voter.
- Client crashing in the middle of the protocol.
- TCP connection breaking in the middle of the protocol.
- Pass phrases voters create for authenticating themselves.
Does the system operate correctly?
How easy is it to follow the README file installation and the tutorial you provided?
How completely does the tutorial you provided exercise your system.
Is the source code easy to understand and does it exhibit good structure? We are particularly keen that the code remain easy to understand and modify for subsequent phases.
[Extra Credit] The protocol for the optional anonymity problem outlined above.