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.
Sincerely,
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,
http://www.votehere.com ) 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.,
http://phx.corporate-ir.net/phoenix.zhtml?c=106584&p=irol-newsArticle&ID=774350&highlight
), 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]
[1]
http://www.cbsnews.com/stories/2006/11/11/cbsnews_investigates/main2174376.shtml
[2]
http://www.heraldtribune.com/apps/pbcs.dll/article?AID=/20061210/NEWS/612100869/-1/NEWS0521
[3] cheating_with_unreliability Matlab model; contact me for details.
[4] Ken Thompson,
Reflections on Trusting Trust,
http://www.acm.org/classics/sep95 , discusses this attack as applied to
any kind of software.
[5] Crane,
Malware Loader,
http://vote.nist.gov/threats/papers/malware_loader.pdf.
[6] See, e.g.,
The Machinery of Democracy: Protecting Elections In
An Electronic World, App.J.,
http://www.brennancenter.org/stack_detail.asp?key=97&subkey=36343&proj_key=76
[7]
http://www.aclu.org/votingrights/gen/27476prs20061121.html (search
for "early voting").
_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= 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