Re: draft of text for new OVC-sponsored bill

From: Ronald Crane <voting_at_lastland_dot_net>
Date: Tue Jan 20 2009 - 13:51:15 CST
cls wrote:
I'm especially alarmed at sweeping that nagging image verification
problem under the rug.  It's the Achilles Heel of this whole approach.
Nobody has yet described to me how I can convince an electronic voting
skeptic that the image he just voted on was built from the exact sources
his expert inspected on the Registrar's web site last week.
Ja, not to mention firmware-based attacks that instrument the image, so that an attacker can cheat even if we somehow verify that the correct image has been loaded into every machine.
I'm leaning towards admitting it's intractible during the time frame
of interest, and insisting on a design that *doesn't care* about
any particular software installation.  Open source is important, but
not for solving this particular security problem.  I want a solution
that can blow the doors off the hand-marked, hand-counted, no-computers-
in-the-whole-chain luddite bandwagon.  I can't do that if my solution
depends on being able to verify and authenticate CD images.
The cryptographic strength and verifiability of those paper ballots,
(and the simplicity and verifiability of their custody protocol)
has to do it alone.
Crypto (or "end-to-end" (E2E)) voting systems are still vulnerable to a variety of attacks, particularly if they use a computational device to present the ballot or to collect the voter's selections. There are at least three kinds of attacks:

1. DoS. The machines selectively can impede, delay, or prevent voters from voting. This attack can range from the heavy-handed (e.g., repeatedly crashing and rebooting; locking up) to the subtle (e.g., making voting take longer by making the GUI laggy, or by lengthening the time to reinitialize for a new voter). Or, officials can simply cheat by manipulating machine allocations, as seems to have happened in Ohio's 2004 Presidential race. .

2. Presentation attack. The machines can selectively omit candidates from the ballot, reorder it, change the race headings to de-emphasize certain races, or make it easier or more difficult to select certain candidates. This attack could be very effective; in 2006, there was a massive (13%) undervote in Florida CD 13 (Sarasota), which quite possibly flipped the result. Officials attributed it to incorrect race headings. . There's no reason that a presentation attack on race headings couldn't produce a similar effect.

3. Social engineering attack on E2E protocol. E2E can provide strong security guarantees, but they're valid only if the user and machine follow the correct protocol. An attacker can program the machine to guide the user to perform an incorrect protocol, thus voiding the guarantees. Since E2E protocols (e.g., VHTI) are unintuitive, most voters won't realize that something has gone wrong. And even if a voter notices a problem, officials are almost certain to attribute it to "voter error" or "a glitch".

That said, it's still possible to wage these attacks on hand-filled paper ballot systems, including ones that use E2E (e.g., ThreeBallot), but it's more difficult. A DoS attack is obvious (Where are the ballots?), while presentation attacks can be caught by randomly auditing the ballots. It's not quite so clear that ballot audits could catch social engineering attacks on E2E, though correct instruction posters in the polling place could help a lot.

Computers are wonderfully powerful tools, but they are not necessarily suitable for every purpose.


OVC-discuss mailing list
By sending email to the OVC-discuss list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Thu Jan 7 00:09:47 2010

This archive was generated by hypermail 2.1.8 : Thu Jan 07 2010 - 00:09:57 CST