DC voting trials

The DC voting trials were part of a system that was going to be used by military and overseas voters to vote in upcoming elections. The election officials behind this system invited the tech community to try to find vulnerabilities in their system. Unfortunately for them, the DC voting trials were broken into via a simple shell injection, and rather quickly. the University of Michigan team was able to run code by renaming the file extension on the ballots that they uploaded. They used this vulnerability to log on as an administrator, to delete and add votes, and to play the University of Michigan fight song in voters' browsers. Still, this vulnerability was the tip of the iceberg, according to Alex Halderman, who helped take down the system. He noted that, though fixing that specific vulnerability would be relatively simple, it would be significantly more difficult to make the entire system secure.

For this reason (in addition to the other possible security risks inherent in the system's design) it probably would not be a good idea to use this system in future trials unless it is significantly upgraded.

Infrastructure attack protection
All internet voting systems are vulnerable to denial-of-service attacks. There are defenses against these kind of attacks, but they can't stand up to an adversary given sufficient computing power. In the event of such a situation voters would have to vote in person (or by mail)

Outsider hacking protection
The DC voting trials have been empirically proven to be insecure in regards to outside hacking attempts. It was vulnerable to shell injection - users can upload files with any extension/name which the server will execute as code. It's a simple problem to fix, but as Alex Halderman, head of the team that broke into the system, wrote, "it will be vastly more difficult to make the system secure."

Malware and virus protection
It may be tricky to devise a virus that is able to change the results on hand-filled out PDF files. That said, some ballots are filled out with PDF tools and those are quite vulnerable to viruses. A virus could also facilitate man in the middle attacks.

Man in the middle attack protection
Network attackers can intercept ballots and modify them in theory - this may be hard to do with scanned ballots however. Though there could be just one ballot file that other ballot files get replaced by - this may or may not work. Also, it doesn't seem like end to end encryption was used, which may be a source of further problems. However, it should be noted that there doesn't seem to be a detailed security analysis out there regarding this issue - most coverage focused on the greater problem of shell injection vulnerability.

Insider attack protection
Suffers from the same problem as optical scan systems in terms of installing the right software, and then some (because the website has to be dealt with). Having the right software on the optical scan machine is one thing - what about on the DC BOEE website? Doubly insecure here. Also votes can be easily deleted.

Coercion resistance
Since the DC voting trials are very similar to vote by mail (you print out a PDF of a blank ballot and then upload that to the DC website) they suffer from the same problems regarding coercion and vote selling. There was no effective solution in place to deter voters from doing so.

Ensuring one person, one vote
I can't find a good resource answering the question of how authentication takes place, and whether it is sufficient to prevent voters from voting multiple times. But assuming the rest of the system holds then I would assume that in theory only registered voters could vote, and that voters could vote only once.

Counting and tallying accuracy
Even assuming the security of the system it's unlikely that it will record votes accurately. Voters may not have access to a scanner of high quality - in this regard it suffers from the same problems as VBM but with the added issue of scanning/printing of ballots.

Voter anonymity
Theoretically the printed ballots wouldn't need to have the name of the voter on them (as that's handled by the BOEE site) thus no single part of the system can know what individuals vote for. However, it might be possible to mass-download ballots off the BOEE website (if you had the necessary access) which would give the adversary the voters' name, contact information, and vote content.

Voter verifiability
Ultimately for the DC voting trials, no method was in place that allowed voters to ensure that their vote was a) actually recieved and b) recorded correctly.

Immediate results protection
Votes are stored encrypted on the server (but they can be easily deleted) so it's likely that this condition is met (provided that key shares are distributed correctly)

Ease of performing a recount
It's impossible to perform a recount with this system. Once the adversaries from the University of Michigan broke into the system and changed the real votes to fictitious ones there was no backup in place with which they could use to restore the old votes. Even then, having backup copies would not fully solve the problem.

Usability
The DC voting trials, in terms of ease of use, suffer from the same problems as vote by mail with the added factor of having voters deal with a scanner.

Transparency
The DC voting trials never got to the stage where they allowed voters to cast their ballots. However, officials who ran the election openly invited the community to see if they could find any security vulnerabilities. This was a great step as otherwise the vulnerabilities might have gone unnoticed, possibly allowing an adversary to exploit the same security holes during the actual election.