Weird Wired article

On the ongoing "problems" with eVoting (linky), which are basically summed up as:

• General purpose PCs are inherently insecure and vulnerable to viruses and other attacks that could compromise votes without detection.
  
• Denial of service attacks could disenfranchise voters.
  
• Database hacks could change vote tallies.
  
• Putting voting into the home would destroy poll-booth privacy, exposing voters to intimidation and bribery.

Subversion at or near the client

First point concerns keyloggers / trojans et al on the client altering the voters intended selection on a ballot. A simple mechanism to address this is the pre-encrypted ballot (detailed description is here) which basically goes:

1. Voter receives list of candidates and an assigned PCIN (Personal Candidate Indentification Number) and response code pair for each candidate.
2. When voting the voter enters the PCIN for their choice rather than picking from a list
3. The voting system returns the response code for the candidate

This prevents two different attacks at two different locations, the attacks being:

• Exposure of who the voter voted for (the PCIN is a random number on the wire / at the client, it doesn't identify the candidate without the original list).
  
• Alteration of the selection (since an alteration would return the wrong response code, and since the attacker wouldn't know the correct response code couldn't fake it)
  

With the locations being at the client and a Man in the Middle attack (the most common approach to exposure / alteration on the wire when using SSL).

Denial Of Service

Any solution to the eVoting problem worth its' salt will have this solved in the Internet cloud well before packets get close to the actual webservers of the voting system.

Then you've got geocaching of the front end, someone in China or some quasi-fictional terrorist can hammer on the webservers all they like, they'll only be hitting the one that's down the road from them.

Quite frankly the thought of running a general election without active packet filtering in the Internet cloud or geocaching should be an automatic barrier to adoption of the system.

DB Hacks changing ballot tallies

I still don't get this one, I've heard it as an argument many times before. Basically it goes : "The tally is only a number in a database so it can be altered". To which the answer seems to be : "Yes the tally is only a number... the 25 million ballots in the ballot storage, ballot verifier and auditing systems aren't." Who would seriously run an election where the only storage of voters intent was to increment a tally when we receive a ballot? No one that's running my general election that's for damn sure (just think of the locking issues).

I suppose the next argument would be that you only need to alter the stored ballots... and the verifier ballots... and the audit ballots... each stored in separate databases in separate systems (with separate message verification processes and procedures) on a network that will have been audited to national security standards by people that don't officially exist. Yes only change all those ballots, making sure that every ballot is changed the same way in all three systems. And if we add in the pre encrypted ballots where only the PCIN is stored on the ballot until the counting stage you can only invalidate ballots in storage as you won't know who to change the PCIN to.

Voting at home

Voting selling and coercion are very real dangers when you move the polling place into everyones homes. However, we can mitigate this somewhat with the following provisions:

• Voter verification systems that don't explicitly state who was voted for
• Multiple votes per vote, where only the last vote counts (subject to adjudication during the counting process)

To be honest, this is probably the only real problem with the concept of remote eVoting. All the others are implementation details that are solvable by building a well designed, well coded, well tested, well audited, well monitored and well verified eVoting system.