WOTE '01 - 20 Minute Presentation by Marilyn Davis, August 28, 2001
I'll start by breaking down our problem. What constitutes a trustable voting system?
There are two avenues for "trusting" a system. One is security, that it be trustworthy in the eyes of the experts. Even more desirable is "transparency", so that the voters can see exactly what is happening and the question of trust is put to rest.
There are two phases in voting: Registration, and the Voting itself. (See Slide 1) The system I'll be describing addresses the security of voting and assumes a good registration system.
Voting security has two aspects. Most important is integrity, where the vote is counted correctly. The system I will describe ensures the integrity of the vote from internal attack.
The second issue is privacy. My system does not ensure privacy. I'm here looking for ideas for providing a privacy layer, and/or hoping that some of the crypto folks will suggest a solution for that part of the problem.
Slide 1. 1. Registration. My talk is not about this. 2. Voting. \ \ Threat | From | From \ Source | Inside | Outside Provide | | | | Integrity | X | --> Registration Process | | --> Attack on the mail client | | Privacy | ??? | ??? X Covered by eVote(R) ??? Can we protect the privacy of stored votes? -------
Threats on a voting system have two possible sources: inside the system and outside the system. Historically, almost all attacks on voting have come from inside.
The eVote(R)/Clerk system demonstrates that we have integrity secured from inside attack. Basically, the technology I'm going to zip through is possible because we *keep* the ballots. So I'm here with the question, can we secure privacy for stored ballots?
When the task is to make the system secure from attack from inside the system, there are two problems to solve (See slide 2).
Slide 2. 1. Architecture: Independence from the Administrator. 2. Network Layer: Redundant Checks. ----
1. The system has to run without the system administrator's help, once it's installed. The users must administer the vote and the system administrator is out of the picture. The software must take care of itself and the data, with the help of the users.
2. The vote sites are networked and the votes are distributed over the network nodes. We must provide that each site on the network can be checked by any other site on the network.
Number 1 is accomplished by using a specialized data base server, written expressly for keeping votes. A vote system that relies on a generalized database server has a point of flexibility in the middle of the solution. See Slide 3. All sorts of data schema, or formats, can be saved across the database server's interface. Like in a biological system, a layer of flexibility creates a volume of complexity, and weakness. Worst of all, in the usual data-keeping method, the system administrator is responsible for data management and for poll administration.
eVote(R) uses a different model of software design as shown in Slide 4. It relies on a specialized database server, The Clerk. The Clerk only stores votes and only a few vote types. Calls into The Clerk look like CreatePoll, DropPoll, and WhoVoted, rather than the simple storage of generalized data records.
This specialized server has a steel pipe instead of a joint in the middle as shown in Slide 5. This invites development of a layer of complexity at both ends of the software design, giving the user total power over the vote system on one end, and totally automating data management tasks on the other.
So, this architecture trick takes the system administrator out of the picture and we achieve independence.
The Network Layer
The specification for the network layer makes no attempt to guarantee the privacy of the votes.
Currently, when the author of a poll wishes to close that poll to further voting, she sends an "eVote close" command in an email message. See Slide 6. eVote sends back a confirmation message, 2 in the figure, which contains a random key in the subject line. When the message is returned, 3., the software marks the poll as closed and sends the final tally to the list members, 4.
For the network layer, diagrammed in Slide 7, the "eVote close" command on non-public poll types will be significantly enhanced to spark a human/computer collaboration to realize a cross-network check of vote data that involves at least three eVoted facilities. Achieving accountability also requires the participation of the users.
The new "eVote close" command will accept an optional argument: the warning-time:
eVote close 48
The poll will close 48 hours from when the warning messages are sent, giving the participants a last chance to vote or to change their votes.
In response to a "eVote close 48" sent to the list address, by the author of the poll, eVote will respond with a confirmation message sent back to the author's address. These are messages 1 and 2 in Slide 7.
The confirmation message has a random key to confirm the user's intention, and a public encryption key to verify the poll. A different public/private key pair will be generated for each non-public poll. These keys are for non-repudiation only, not to ensure privacy.
The point of non-repudiation in the networked eVote(R)/Clerk facilities is not only to prevent eVote installations from denying the email they send, but also to foil users who claim false receipts.
Here, the author chose to send the message to the facility at bob.net, message 3.
Bob.net generates some random text, 4, encrypts it with the poll's public key and sends this, along with the forwarded confirmation message back to alice.net.
Alice.net checks the confirmation key to verify that the communication from bob.net was the one initiated at alice.net and by the appropriate user.
Alice.net also decrypts the random text and sends that back to bob.net to verify the public/private key pair and alice.net's legitimacy, 5. With this verification message comes the vote data needed so that bob.net can send a "CLOSE WARNING" with a pending receipt to each voter before the poll closes.
The data message sent from alice.net to bob.net contains a data package for each voter. Each voter's package has two parts. The first part is the the email address and vote. These are sent as clear data. The second part is the non-repudiation MAC (Message Authentication Code) for the first part. The MAC is encrypted with the poll's private key.
Each voter's package is the "pending receipt" for that voter. It is embedded into the "CLOSE WARNING" message that is sent to that voter, 6.
Bob.net checks that alice.net was able to decrypt the random message; checks the statistics on the poll from the clear data; and verifies each voter's data package by decrypting and checking the MAC using the poll's public key, still remembered from the confirmation message. Bob.net sends each voter her vote as clear data, and that voter's encrypted MAC.
The process is repeated after the poll is closed so that each voter receives a "CLOSED" message which contains, besides the voter's final receipt, the final tally for the poll.
Any voter will be able to forward her "CLOSE WARNING/pending receipt" or her "CLOSE/final receipt" message to any of the Clerk addresses, 7.
When carl.net verifies a receipt, it sends random text, 8, which is encrypted with the poll's public key, to alice.net. Alice.net returns the decrypted message, 9, to verify the poll's key pair. Bob.net checks that returned message and checks that the MAC is correct for the vote, and, if the MAC and the key pair are verified the voter will be sent a verification of the receipt, 10.
Or, if the receipt cannot be validated, an advisory message will be sent to the voter, to the owner of the email list, and to eVotefirstname.lastname@example.org.
Slide 8 is the same as slide 7 but with the threat model along side, justifying each step in the process.
When it's time for the poll to close, the process is repeated with a different eVote(R)/Clerk on the network.
Comments and questions?