Talk by Marilyn Davis

San Francisco Cyberpunks Talk, June 9, 2001

I'm going to speak only to one security concern, the *un*usual one: "protecting the voters from the administrator of the vote". While Brand X vote-systems concern themselves with preventing external attack from voters and external subversive forces, eVote focuses on preventing attack from the incumbent powers, those currently in control, and those historically shown to be the most interested in attacking the democracy system.

Both security concerns must be answered, but this one, protecting the voter from the administrator is today's topic.

First I will tell how the eVote/Clerk software was motivated; and how that motivation led to a radical divergence from the usual architecture for data-intensive applications. We'll see that this unusual architecture protects, to some extent, the voter from the administrator. Then, I'll talk about the network layer planned that includes some encryption implementation intended to lock the administrator away from the opportunity to falsify a poll. Please tell me if I'm wrong.

eVote was conceived, back in the 80's when BBS's and conferencing systems came on the scene, with the intention of emulating, online, a perfect democracy for online groups. There was no intention of using it in elections.

Elections, or any big-vote type of democracy was criticized in 1982 by Jean Betheke Elshtain, a political scientist, as being an "interactive shell game [that] cons us into believing that we are participating when we are really simply performing as the responding `end' of a prefabricated system of external stimuli." Elshtain complains that these systems are not "democracies", but "plebiscites". "In a plebiscitary system, the views of the majority, ..., swamp minority or unpopular views. Plebiscitism is compatible with authoritarian politics carried out under the guise of, or with the connivance of, majority views. That opinion can be registered by easily manipulated, ritualistic plebiscites, so there is no need for debate on substantive questions."

Another political theorist, Brian Fay, has said about democracy that what "is most significant is the involvement of the citizens in the process of determining their own collective identity." Thus, the primary activity of a real democracy is discussion, not voting. In a real democracy, there is facility to bring up issues, exchange opinions, poll ourselves, re-discuss, and re-poll, until consensus is reached.

By "consensus", I mean the style of consensus decision-making practiced by Kuna Indians in Panama (perhaps the only tribe still unconquered and still living on their original land), Quakers, my Zen Center, by many activist groups, and by some groups of people who live together. These groups don't act until all agree - or, at least, no one disagrees. Every individual is completely empowered as an individual because everyone has veto power.

You may "stand-out" of the vote if you still disagree with an action, but don't wish to block the group.

Consensus, where no one disagrees, is much easier to achieve than unanimity, where everyone agrees. However, the consensus process is a tedious and tiresome process and it requires that the group be strongly connected in purpose and that they each be committed to the process itself.

Here's how consensus works. After an issue comes forward and is discussed, there will be a call for a show of hands. If all agree, or abstain, except a few, these few are required to state their objections. I once saw a whole meeting turn around at this point -- when a quiet person whom I had never heard speak before was forced to state his objection. It was an excellent objection that no one else had thought of. Everyone rallied around the new point of view and consensus jelled.

These meetings can go on and on, all afternoon and night. But, whenever a group really needs a decision, they always manage to pull together on one. Like I said, it's a terribly arduous process but one that almost always produces the best answer.

This tedious process has much to gain from an online implementation: the participants can participate in their own time, the record of the meeting is automated and exact, the polling is automated and exact.

So, in order to bring the consensus process to the computer medium, four features were required:

  1. The polling is integrated with the discussion.

  2. Everyone has the power to initialize a poll.

  3. Voters can change their votes while the topic is still under discussion.

  4. Voters can see each others' votes to emulate a show-of-hands.

Also, I wanted to provide secret votes for PTA elections and such.

Note that feature 3, that voters can change their votes, means that the vote must stay identified with the voter, which, without encryption, produces a security hole in that privacy could be breached by a clever hacker or by the system administrator. eVote does not answer this security concern yet. So far, we are only concerned with emulating true democracy and ensuring absolute accountability.

Feature 2, that anyone can initialize a poll, requires, in database terminology, that the user can update the schema. Generalized database management systems, Oracle, Informix, etc., are not suitable for providing this facility. Reading from "Object Data Management" by R.G.G. Cattell: "... no automatic and satisfactory schema-evolution capability is possible because generalization to a variety of data types necessitates too many possible transformations of the schema and the data."

It is the *generalization* of traditional database systems that shoots us in the foot when we want to provide flexibility and power to the user. As in all engineering, whenever we introduce a point of flexibility, we introduce a point of complication. In our case, as the voting system runs, the specific vote data must be transformed into the generalized format for storage and transformed again, back to the natural format, on retrieval. This complicates the code and slows down the processing.

If we avoid this point of complication at the database interface, we release a "degree of freedom" that allows us to build a layer of complication both at the user end, and at the server end. The result is that the user has all the power in the system and the administrator's tasks are all automated.

A generalized data management system can only supply the voting application programmer with low-level data-serving functions, like "save-record" and "fetch-record". The Clerk, the specialized vote-server, provides high-level calls as shown in <http://www.deliberate.com/w4g/conf97/freedom1.html>

Not only are the high-level calls brought to the application programmer so that the user has control of the system; but also the code is compiled before the poll questions are known, the administrator is usually unaware of the poll questions as the polls open and close. The administrator's responsibility, and therefore power, has disappeared. See <http://www.deliberate.com/w4g/conf97/freedom4.html> and <http://www.deliberate.com/w4g/conf97/freedom5.html>

As I mentioned, the name of the vote-server is "The Clerk". "eVote®" is the name of any user-interface that relies on The Clerk.

The user interfaces are released as open source software but, because The Clerk's main feature is that it protects the users from the administrator, the source is secret.

I'd like to release the source to The Clerk under GPL, but, in order not to compromise the accountability of polls, we need a networked security layer in place.

The specification for the network layer makes no attempt to guarantee the privacy of such polls. Privacy will be the subject of a future release. This current work is designed to be the minimum required for absolute accountability of the polls; so that the source can be released and the free software communities can develop guarantees against attacks on privacy.

The current version, eVote®/Clerk 2.5, is an email interface for voting. When there is a non-public poll, i.e., one where the votes are not public, the user who initiated the poll sends an "eVote close" command in an email message to close the poll to further voting. See Slide 1. 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 GPL-ed version, 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.

The default warning-time will be 24 hours.

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

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/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 eVote-owner@alice.net.

Comments and questions?