Technical Specification For Voting Machines

Voting Machine Technical Specification Project

[NOTE: Please address non-technical issues on SecuringVotingMachines. Take arguments in favor of older counting methods to VotingMachineDiscussion or some other, more appropriate page. Some discussion moved there to reduce page clutter.]

The window for getting this spec submitted for the 2004 election has closed, but the quest for a secure voting machine spec continues. Now there are Congressional committees and independent research groups trying to address the very issued we have been thrashing out here. How about that?!

This is really, really needed in The Good Ol' US of A before we have our next major election. Otherwise, we may not need to hold any more elections, since the people who make -- and program -- the voting machines are all from one political party. Once a spec is in place maybe people from around the world will be interested. Maybe not.

So! Let's put our bright little minds together to come up with a fairly simple description for a layered voting machine design. It should have an open, formula architecture for the hardware, have software that is 100% Java (for transparency and testability), and have a bulletproof auditing and logging subsystem that is encrypted and protected by vicious dogs.

No discussion of electronic voting and voting machines is complete without reference to the work of Dr. Rebeca Mercuri: http://www.notablesoftware.com/evote.html. It would be wise for contributors to this page to do a little research first so as to make informed observations and contribute worthwhile suggestions to this discussion. Note also that most other online articles quote heavily from Dr. Mercuri's work, so this is the primary source for voting machine references. The other site of note is Black Box Voting [http://www.blackboxvoting.org], the source for ongoing news pertaining to electronic voting mechanisms. (Note: do not refer to www.blackboxvoting.com by mistake; you will be taken in a very different direction.)

We need to talk about a limited range of technical matters concerning voting machines and automated vote counting systems, since these boxes are here to stay and we have to make the best of them. There is a clutter of clatter to replace the former deafening silence in the Internet community about the technical solutions to the problems of voting machines. We need to bring some of these issues to a resolution.

Here is an article discussing security flaws in existing voting machine software that y'all might be interested in:

http://www.circleofsouls.net/modules.php?op=modload&name=News&file=article&sid=48

Yeah, this is a reference to Mercuri's work yet again. How many more article references are we going to get like this?

And you might be interested in this project:

http://www.fairvote.org/ChoicePlus/

Now, this is a Good Idea®. Choice Plus had talked about their stuff as being open source for the Aussie project, but it wasn't published on their site (I found it elsewhere). Maybe we'll get a chance to see something good through the Center for Voting and Democracy. However, keep in mind that this solution is still in C, so it doesn't really meet the Java transparency requirement.

General

Colors used on the screen will not be significant in feedback operations -- only their contrast will be. Colors must be neutral to color blindness.
Sounds must be unique in context; alerts must be significantly different from confirmations.
Feedback/confirmation must be both visible and audible. [Note: how to specify so that the widest range of handicaps is accommodated by the machine?]

Verification & Validation

There must be no possibility of the displayed candidate's name being different from the voter's selection. For touch screen and ATM-style systems this means that the candidate's name needs to be in a box that is no less than 2 em spaces high, with a margin of at least one em space, with the candidate's name in the center of the box in both vertical and horizontal axes. During calibration the touch registration can not be off of the screen position by more than [XXX distance] as measured directly on the screen. For ATM-style screens the center of the candidate box can not be vertically offset from the button by more than [XXX distance] as measured directly on the screen.
For touch screen and ATM-style machines the user's selection must be fed back by audible and visual means. The machine will make some distinguishable sound to indicate a valid vote was cast, and the screen will change color (see above) or flip background/foreground colors to highlight the selection made.
The voter must have the option of canceling or changing his vote before it is recorded. The display/sound will confirm this.
When the voter has completed voting the machine issues a paper receipt as proof of vote. This receipt will contain a PGP ID for the ballot cast. Should the voting machine have some issue in testing later the election commission can issue a public notice of vote receipts (a list of PGP IDs) and those with matching printed receipt IDs can re-cast their votes. The PGP may also be useful in recreating a complete ballot [although how is still in question].

Voter Operations

Under vote: The machine informs the voter that he still has votes to cast, but doesn't force him to cast those votes.
Over vote: On touch screen and ATM-style machines the voter simply can't over-vote. On optical scan machines the scanner informs the voter immediately so the voter has an opportunity to declare a spoiled ballot and re-cast.

Logging and Audit Trail

The machine makes an internal log (with hardcopy) of all operations. This log must be visible to the outside world but can't be altered until the votes have been tallied and the election is closed.
The machine's log of ballots must not be visible at all until the final tally is done.

Remote Operations

Only status logs can be pulled remotely.
End-of-day tallies can only be push operations and can only occur once. Tally reports are verified complete before the operation is marked complete.

Under the heading Remote Operations the spec suggests that logs be pulled remotely, but tallies be excluded from this.

I suggest that it is a major mistake to allow any remote access other than the prescribed tally collection (a one-shot push).

Also, the logging and auditing description is terribly weak. The rest looks like a good start, and a good idea. But we haven't much time, if y'all are serious about this. Get after it with a vengeance, please.

-- JimSawyer?

Yeah, Jim, you're right -- there isn't much time. Officially the federal election organization (commission? committee?) window closes early in January 2004.

The idea of the remote pull for machine status logs was so that the machine could be tested while in operation without taking it out of service. A member of the Board of Election Commissioners, for example, could verify that the machine is operating without problems, but couldn't tell how many ballots had been cast or for whom.

This spec is very weak as yet. The logging and auditing are just one weak aspect. Feel free to contribute.

Some suggested specifications:

Must allow for recounts/allow audits (i.e., only maintaining a running total is not sufficient)
Must not lose votes due to power loss, etc.
Must be tamper evident (physically and electronically)
Must be verifiably set to zero at the start of election
Must be easily maintainable (equipment used heavily one day a year and then sits in storage).
Must be easily and uniformly configured for slate of candidates
Must prevent updates to the slate of candidates
Must be easy to TestTheSystem
Must be secure and protect votes during maintenance. If a machine fails on election day, it must not lose votes already cast, the maintenance personnel must not be able to read current votes, add or delete votes.
Must allow secure independent validation of the previous voting attempt without revealing details of the vote. If a voting machine fails, a voter should be permitted to vote again on another machine, however, a polling place official must be able to verify the vote failed prior to granting this permission.

See: SecuringVotingMachines, OpenSourceVotingSoftware

CategoryVoting