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