DC's Internet Voting Pilot

From: <SomeThoughts_at_aol_dot_com>
Date: Fri Jul 02 2010 - 21:43:10 CDT

More details are coming out about the DC Internet Voting Pilot.
It's not encouraging.
The overview of the system is in the 2nd paragraph.
On the web page, there is a comment left
by (someone purporting to be) G.A. Miller, CEO if the Open Source
Digital Voting Foundation that is implementing this pilot. He says:
"One clarification, Eric, to an otherwise fair assessment pending more
details except one small thing: the qualified overseas military voters who
choose to participate in this assessment Pilot can still choose to return
their ballots the usual way: paper by surface mails. Your last point suggested
no paper return. Incorrect."
Fundamentally, it allows a voter to cast a ballot with no paper ballot.
Completely digital, therefore, photoshop-able, among other problems.
Jim Soper

By EKRon July 1, 2010 2:21 PM _Permalink_
(http://www.educatedguesswork.org/2010/07/dcs_internet_voting_pilot.html) | _Comments (5)_
(http://www.educatedguesswork.org/2010/07/dcs_internet_voting_pilot.html#comments) |
_Voting_ (http://www.educatedguesswork.org/voting/)

Last week, the DC Board of Elections and Ethics and the Open Source
Digital Voting foundation announced that they were going to do a pilot Internet
Voting project for overseas and military voters _[*]_
(http://www.osdv.org/about/osdv-news-press/district_of_columbia_adopts_osdv_technology) . (In the
US, this sort of voting often gets called UOCAVA, after the _Uniformed and
Overseas Citizens Absentee Voting Act_ (http://en.wikipedia.org/wiki/UOCAVA)
, which covers this case). UOCAVA voters are often in remote locations with
poor mail access, so traditional Vote By Mail doesn't work very well,
making it an apparently attractive use case for technological fixes. That's why
there have been (at least) two previous efforts to apply Internet voting
technology to UOCAVA voters: _SERVE_
(http://en.wikipedia.org/wiki/Secure_Electronic_Registration_and_Voting_Experiment) and _Operation Bravo_
(http://www.operationbravo.org/pilot_projects.html) . That said, there have also
been significant technical concerns about this kind of technology (_SERVE
report_ (http://www.servesecurityreport.org/) , _more positive report on
Operation Bravo_ (http://www.eecs.berkeley.edu/~daw/papers/scytl-odbp.pdf) ).
Details about the DC pilot are pretty thin on the ground, but I've managed
to get an overview of what's public from John Sebes from OSDV. The basic
idea is like this:
    * DC BOEE operates a Web site where you can download blank ballots in
PDF form.
    * You either fill in the ballot with local PDF tools or print it,
fill out, and scan.
    * You upload the filled-in ballot to the DC BOEE site.
    * The filled-in ballots are printed out and fed into an optical
scanner just like vote-by-mail ballots.
    * There is no offline return of paper ballots. [See comment on web
page by G.A.Miller]
Now, obviously you'd want to do HTTPS (HTTP over TLS) for this, but there
are still a large number of potential security vulnerabilities here. The
rest of this discussion is based on the assumption that the system is as
constructed as above.
Attacks on the Server
The attacks that typically come to mind first are attacks on the ballot
distribution and acceptance site. In this design, that site is open to the
Internet and by definition pretty much anyne can talk to it, so that leaves
it open to a variety of attacks. The two main attacks we need to be
concerned about are compromise of the site and denial of service attacks.
In the design I just described, an attacker who manages to compromise the
site can effectively replace any ballot with a ballot of his choosing.
Within the limits of having the number of ballots roughly match the number of
registered voters, they can also remove and and insert ballots, etc. In
addition, they can track how everyone has voted. In effect, they have complete
control of the election. Needless to say, this is bad.
Obviously, you can imagine hardening the site in some number of ways
(firewalls, IDS, aggressive logging to offline storage, audits, etc.), but that
just reduces the risk rather than eliminating it completely. Moreover, this
doesn't do anything about insider attack: the election officials have
complete control over this machine and we don't have any good way to verify what
they have done with it (this is basically an intractable problem). This
attack can be mounted by a single person, so this sort of system is
significantly more vulnerable to a single point attack either by an insider or an
outsider than is a traditional paper-based absentee system.
Another issue we need to be concerned about is Denial of Service attacks on
 the Web server. An attack like this has the potential to disenfranchise
large numbers of voters. And since the demographics of UOCAVA voters differ
from those of other voters, a DoS attack has the potential for differential
Software Attacks on the End-User Client
Because voters are voting on their own computers, there is of course a
risk from compromise of those machines. The average user's computer isn't very
well maintained and though estimates for the fraction of machines which
are malware infected vary, it's clear that the numbers are large. It wouldn't
be particularly hard to develop a piece of malware whose payload changed
people's votes. There are several potential attack vectors here:
    * Modify the ballots on download (before the user fills them out)
    * Do a "presentation attack" on the ballot marking mode of the PDF
viewer, where the voter attempts to vote for Hamilton but the viewer records
Burr (this doesn't work on hand-marked ballots).
    * Modify the scanned ballots before submission.
    * Send a copy of the ballots to some third party.
    * Selectively create failures for voters who are voting the "wrong way
In essence, every attack people have proposed on DREs is suddenly an attack
 on this system as well. Some of these attacks may be detectable but in
general one can't recover from them. And the available evidence suggests that
users are pretty oblivious to even fairly blatant attacks. _[*]_
(http://chil.rice.edu/research/pdf/EverettDissertation.pdf) .
Attacks on the End-User
Finally, there are attacks which don't require machine compromise. Voters
connect to the election site via the Web, so a network attacker who
intercepts that connection can steal ballots, modify ballots, etc. Of course, we
would expect the connection to be secure, but at least some unsophisticated
users are likely to override whatever warnings the browsers pop up; the
available data on user interaction is that people do this quite often _[*]_
(http://lorrie.cranor.org/pubs/sslwarnings.pdf) .
I should note that like any vote from home system, there is also a
significant risk of compromise of voter privacy, since an attacker can look over
your shoulder as you vote.
Bottom Line
As far as I can tell, a system of this type offers significantly worse
security properties than in-person voting (whether opscan or DRE), since it
has all the security flaws of both plus a much larger attack surface area.
[Note that the intermediate opscan step offers only marginal security benefit
because it's based on electronic records which are untrustworthy.] It also
offers inferior security properties to traditional vote by mail. The
primary benefit is reducing voter latency, but clearly that comes at substantial

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 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 Sat Jul 31 23:17:02 2010

This archive was generated by hypermail 2.1.8 : Sat Jul 31 2010 - 23:17:02 CDT