Voting: July 2010 Archives


July 10, 2010

As with last year, EVT/WOTE will be having a Rump Session:
For the second year in a row, this year's EVT/WOTE includes a Rump Session, scheduled at the all-new and more convenient time of 5:00 p.m. on Monday, August 9.
This session will no doubt include results more important--and simultaneously more hilarious--than any to be presented at the main workshop. If we're lucky, Mark Lindeman will sing again. However, this can only happen if you (yes, this means you!) submit.

Acceptable topics include:

Work in progress
Work that you haven't had time to start
Work that you will do if you ever get some free time
Work that should not be started at all
Each presenter will have between 4 and 7 minutes, depending on the number of submissions and an as-yet-undetermined and most likely arbitrary evaluation formula.

Submissions should be directed to the Rump Session Chair, Eric Rescorla, at Please provide a talk title, the presenter's name and affiliation, and an estimate of how much time you would like.
Main CFP here.

July 2, 2010

Greg Miller corrected an error in my previous post on the DC Internet voting pilot:
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.

I followed up with John Sebes from OSDV and got some clarification on the situation. Voters have three ballot return options.

  • Print the ballot out, fill it in on paper, then scan and return via the Internet.
  • Fill out the ballot on your computer and return via the Internet.
  • Print the ballot out, fill it in, and then mail it back.

So, you can return the ballot either via the Internet or via mail but not both.

I've already written about the first two cases, but not the third; hence this post. Clearly, paper mail return is more secure than Internet return, since we don't have to worry about tampering of the user's completed ballot either by his computer or by the board of election server. However, we still have to worry about tampering with the blank ballot, which can happen in either location.

The simplest attack is just to swap the descriptions for candidates. As I understand the situation, optical scanners only look at which opscan targets is filled in, but ignore marks outside of those regions. So, if I swap the names Jefferson and Burr, then when the voter thinks he's voting for Jefferson this turns into a vote for Burr. Since the voter has no real way of knowing what order candidates appear on the ballot it's unlikely the voter would detect this attack. The attack is trivially detectable at election central by examining the ballots (and possibly mechnically), provided you know the order of candidates on the ballot. (I don't know if any jurisdictions send out multiple ballots with rotated names, but if so, this detection becomes an accounting problem.)

Not only is the simple attack detectable, it's presumably recoverable: since the voter doesn't know what the ballot order is supposed to be, they're voting on the basis of the names on the ballot, so voter intent is clear and you can just process the ballots based on the names. OCR would probably work here, but in the worst case you could just process the ballots manually. However, we can imagine situations in which an attacker could damage the ballot in ways that wouldn't be plausibly recoverable. This is easiest with propositions: remember that voters don't know the exact wording of the propositions and may not remember the proposition numbers. So if, for instance you not only switch the targets but also swap proposition numbers or reword the propositions, then voter intent becomes a lot less clear. This is of course harder with candidates rather than propositions, but you could, for instance, swap political parties. It's important to remember that all an attacker has to do to affect the election is to preferentially remove the votes of voters who are likely to vote in a given way. Changing them is better, but just invalidating them is still powerful.

So while electronic ballot distribution is more secure than electronic ballot return, there still seem to be a number of potential attacks that would be more difficult to mount en masse with conventional paper-based ballot delivery.


July 1, 2010

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 [*]. (In the US, this sort of voting often gets called UOCAVA, after the Uniformed and Overseas Citizens Absentee Voting Act, 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 and Operation Bravo. That said, there have also been significant technical concerns about this kind of technology (SERVE report, more positive report on Operation Bravo).

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.
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 disenfranchisement.

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. [*].

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 [*].

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 risk.