Re: [OVC-discuss] draft of text for new OVC-sponsored bill

From: Alan Dechert <dechert_at_gmail_dot_com>
Date: Tue Jan 20 2009 - 15:42:51 CST

Okay, maybe I missed that part.

Anyway, this thread is about the bill. The system we are working on is not finished by a long ways. The bill might make it possible for a different system to get certified that is even better.

Why don't you help with the bill text instead of minutiae about how our system works before it's even close to being finished?

AD

  ----- Original Message -----
  From: Ronald Crane
  To: Open Voting Consortium discussion list
  Sent: Tuesday, January 20, 2009 1:33 PM
  Subject: Re: [OVC-discuss] draft of text for new OVC-sponsored bill

  First, did I say "hand counted" or "hand filled"? Did I object to computational ballot counting (with audits), or did I object to computational ballot presentation, selection, and recording?

  Second, as I noted, the system you're proposing has some serious security flaws. I believe that the benefits of accessibility for certain disabled voters probably outweigh those flaws. Not so for the general voting public.

  -R

  Alan Dechert wrote:

    Ron, we've been around and around on this one for ages. Hand-counted hand-marked paper ballots (HCPB) are simply not an option for the kind of election system we have in the US -- especially in urban areas where 80 percent of the population lives.

    You ought to review some of the discussion at change.org on this.

    http://www.change.org/ideas/idea_comments?idea_id=move_the_country_towards_transparent_election_systems&page=2

    I always challenge HCPB advocates to come up with numbers....

    Alan

      ----- Original Message -----
      From: Ronald Crane
      To: Open Voting Consortium discussion list
      Sent: Tuesday, January 20, 2009 12:23 PM
      Subject: Re: [OVC-discuss] draft of text for new OVC-sponsored bill

      Probably everyone but Diebold, et al, agrees that open-source computational voting systems are likely to be more secure than closed-source computational voting systems. But are they safer than hand-filled paper ballot systems? I don't think so, because of the attacks I mentioned, and other attacks (e.g., on "voter verification").

      I think that we should use computational ballot presentation and recording devices only to assist disabled voters to vote independently. I believe that their advantages (e.g., definiteness of ballot markings and overvote/undervote checking) are heavily outweighed by their security risks when used by the general voting population.

      -R

      laird popkin wrote:
Keep in mind that security isn't an absolute, but is a matter of
presenting sufficient costs and risks around an attack that the attack
is deterred.

So, while in an absolute sense any software system has the same issue
(you cannot 100% prove that all of the machines are running the
correct software), open software is (IMO) significantly more open to
validation because every step in the process can be open to
inspection, while a proprietary voting system relies on hiding the
code to protect the vendor's IP.

For example, you can validate that the software is correct by
independently compiling your own copy and comparing the binaries,
proving that the vendor's compiler didn't sneak code in, and that the
source wasn't modified. You could distribute the executable and data
files on CD's, with witnesses validating the duplication,
distribution, etc., and boot the PC's from CD to run the election.

Given such an approach there are still possible attacks, such as BIOS
hacking, or threatening to shoot voters unless you can watch them vote
"properly", but in terms of the specific issue of software validation,
open source software is (IMO) certainly safer than running a vendor
loading modified software in "black box" voting machines. :-)

- LP

On Tue, Jan 20, 2009 at 2:51 PM, Ronald Crane <voting@lastland.net> wrote:
  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.
http://www.harpers.org/archive/2005/08/0080696 .

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.
http://www.heraldtribune.com/apps/pbcs.dll/article?AID=/20061115/NEWS/611150751
. 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.

-R
_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
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 http://gnosis.python-hosting.com/voting-project/

    

  

--------------------------------------------------------------------------
      _______________________________________________
      OVC-discuss mailing list
      OVC-discuss@listman.sonic.net
      http://lists.sonic.net/mailman/listinfo/ovc-discuss
      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 http://gnosis.python-hosting.com/voting-project/
----------------------------------------------------------------------------
_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
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 http://gnosis.python-hosting.com/voting-project/

------------------------------------------------------------------------------

  _______________________________________________
  OVC-discuss mailing list
  OVC-discuss@listman.sonic.net
  http://lists.sonic.net/mailman/listinfo/ovc-discuss
  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 http://gnosis.python-hosting.com/voting-project/

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
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 http://gnosis.python-hosting.com/voting-project/

==================================================================
= 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