Comments on your top-to-bottom voting systems review

From: Ronald Crane <voting_at_lastland_dot_net>
Date: Fri Mar 30 2007 - 18:40:11 CDT
Dear Sec. Bowen:

Attached are my comments on your top-to-bottom voting systems review criteria. These comments are not comprehensive of my concerns, since I know that others (e.g., the Open Voting Consortium) already have submitted comments that raise some of those concerns. Thank you for making this review a priority, and for soliciting public comments.


Ronald E. Crane

1. The review defines the potential attacks upon voting systems too narrowly, thus omitting many attacks that can prevent an election from being conducted fairly. "Untraceable vote tampering" does not include, for example::

a. Attacks that attempt to deceive the voter about the proper contents of the ballot. These can include reordering the ballot, dropping candidates from the ballot, deleting or de-emphasizing headers between races, and possibly other more-subtle attacks. While some consider these to be "fringe" attacks that are unlikely to affect an election's fairness, I believe that the evidence rebuts this view. For example, Sarasota, Florida experienced a mysterious 13% undervote in the highest-profile race on the ballot, an event widely considered to have changed the race's outcome. [1] Many now attribute the undervote to officials' failure to program their DREs to adequately visually separate the undervoted race from another race. [2] Officials claim that the omission is innocent, but an attacker could program a DRE to wage an identical attack.

b. Attacks that attempt to affect a voter's choice of candidate, such as by selectively modulating the sensitivity of a touch-screen device, or selectively mis-aligning it, to make it easier or more difficult to select certain candidates.

c. Attacks that attempt to deceive the voter about the appropriate procedure. In one such attack, the attacker programs a DRE w/VVPT to selectively skip printing the VVPT, and also to skip displaying the corresponding prompts. When the voter finishes voting, the DRE records the attacker's selections, then prints a matching VVPT. The voter -- who might very well not understand the paper trail's purpose, or even know about its existence -- might well not detect that anything is amiss. And if she does, pollworkers may well attribute it to a "glitch".  Similarly, an attacker might program a cryptographic DRE (e.g., VoteHere, ) to rearrange the procedure so that any cryptographic commitments are meaningless. Since very few voters are familiar with the proper procedure or understand its importance, this attack is likely to escape notice unless the machines are subject to rigorous random parallel testing in every election.

Similarly, "denial of service attacks[s]" is defined to omit the possibility of delay-of-service attacks. In these attacks, the attacker does not program machines to be "inoperable for voting," but instead programs them to lengthen the average amount of time required to vote, thus lengthening lines and leading to voter frustration and consequent vote loss. The attacker might lengthen voting times by introducing delays at various points (e.g., when inserting their voting card, when changing pages, when printing the VVPT, on the review screen, etc.) such that any individual delay seems acceptable, but so that the cumulative total of delays substantially lengthens average voting times. To see the effect, a simulation predicts total frustration-related vote loss of about 1% where 500 voters share 4 machines in a 14-hour voting day, voting takes an average of 5 minutes, and voters leave in frustration after a mean wait of 60 minutes with a 30 minute standard deviation. The vote loss rises to about 3% if an attack lengthens average voting times to 6 minutes, to about 7% for average voting times of 7 minutes, and to about 28% if average voting times reach 10 minutes. [3] Selective application of this kind of attack easily could skew an election.

2. Source code reviews are inadequate for many reasons. First, the source code provided by a vendor is not necessarily the same source used to build the voting application that is installed in machines on election day. Second, the tools used to build the voting application can introduce an attack program, even if the source is clean. [4] Third, the operating system, firmware, and even hardware can be engineered to load an attack program, even if the originally-loaded voting application itself is clean. [5] Moreover, the source code reviews do not permit members of the general public to scrutinize the source or to submit comments on it.

3. The criteria omit evaluation of electronic pollbooks. I do not know whether California has certified any electronic pollbooks (e.g., ), but if it has, the review has to cover them, since attacks waged upon them or using them can prevent an election from being conducted fairly. For example, an attacker might program a pollbook to impede voting by making it difficult or time-consuming to determine whether voters are eligible to vote, to falsely indicate that a certain voter is not eligible, or even -- in cooperation with an attack on associated DREs -- to stuff the ballot box by casting votes in the names of voters who did not vote at the polling place.

4. The DRE "voter verifiable paper record" criteria ((II)(2)(f)) are meaningless from a security perspective. An attacker can program the software to misrecord the voter's selections and to print a correspondingly-falsified VVPT while simultaneously presenting a "nonvisual confirmation" that accurately summarizes the voter's selections. This kind of system should be viewed -- at best -- as a means of assisting disabled voters to discover errors in their selections, and not as a security measure.

5. More generally, there also has to be a review of election procedures. Reviewing voting systems themselves is vitally important, but reviewing the procedures surrounding their use is just as important. For example, the state's mandatory 1% random hand audits are statistically insufficient to detect many potential attacks, even assuming that officials generally conduct them correctly (e.g, that they select the precincts to be audited publicly and randomly after the preliminary precinct totals are publicly posted). The number of precincts to audit should not be fixed, but should be based upon the apparent margin of victory -- closer races require more auditing. [6] Similarly, there have to be well-thought-out procedures for action when an audit discovers discrepancies, for when a voter reports a problem that could indicate an attack, and so forth. There is a tendency among some to dismiss problem reports as "voter error" or "glitches," or to "stick it out" with machines that are clearly performing incorrectly. This is inappropriate, and easily can lead to corrupted elections. For example, officials in Sarasota continued to use their DREs long after it became apparent that voters were failing to see the congressional race due to defective ballot programming. [7]

[3] cheating_with_unreliability Matlab model; contact me for details.
[4] Ken Thompson, Reflections on Trusting Trust, , discusses this attack as applied to any kind of software.
[5] Crane, Malware Loader,
[6] See, e.g., The Machinery of Democracy: Protecting Elections In An Electronic World, App.J.,
[7] (search for "early voting").

OVC-discuss mailing list

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sat Mar 31 23:17:09 2007

This archive was generated by hypermail 2.1.8 : Sat Mar 31 2007 - 23:17:09 CDT