Saturday, 18 November 2006

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.


Jason Kitcat said...


* The pre-encrypted ballot system you suggest does not solve the problem of trust. Just because the web browser shows you the number you expect does not prove that your vote was stored and counted as you intended.

* Denial of Service can be rivers of packets, electricity failures, ISP attacks, election-specific trojans etc. For example it would be easy to write some malicious code which detected when a user tried to access the voting site URL and block it or better yet, spoof it.

* The reason DB hacks get mentioned so often is that these holes have been shown to exist in the e-voting systems used today. Of course it's poor design, but such systems are in widespread use. With better design perhaps you need to modify a million files on one central counting machine - logistically that's still a minor task compared to modifying a million paper votes.

* I appreciate you recognising the problems of voting from home or work as it does breach the UK Human Rights Act.

* A certified e-voting system can be brilliant, but if the code used on election day isn't that used for certification (as has happened several times) then certification is useless.

The arrogance some technologists portray in assuming that massively complex technology can be sufficiently reliable to run our elections is astonishing.

Bruce Schneier summed it all up when he wrote that "building a secure Internet-based voting system is a very hard problem, harder than all the other computer security problems we've attempted and failed at. I believe that the risks to democacy are too great to attempt it."

Daniel Gray said...

Apologies for not getting back to earlier in the week, been visiting secure hosting centers. Quite interesting experience that should lead to an article in itself.

Not really fair that first point is it? A colleague said it was like saying that ABS doesn't allow you to see in the dark, that's what headlights are for. The pre-encrypted ballot is designed solely to ensure that the vote you intended to cast reached the voting system and was at least recognised correctly. As to whether that vote is stored / counted correctly it comes down to trust in the system, the pre-encrypted ballot protects against where we can't have trust. i.e. the Internet cloud.

I'll get back to you on that client blocking point, need to check with a PM that I'm not going to break commercial confidentiality around that as we have a solution to the problem. As to spoofing, that's definitely been solved as well. Included in your ballot pack is a site verification code and response code. Simply enter the verification code and if you get the response code you know you're talking to the correct end point. (doesn't mitigate Man in the Middle, but the pre-encrypted ballot does)

You're not really getting it about the databases are you? Duplication of data in multiple databases on separate systems with proper data verification procedures ensures that alterations CANNOT be made in a single place. Altering data in a database is easier, but getting to the verification systems would be HARD, very hard in fact.

You cite the problems the Americans have had where certificated code is not what is run on election day. Who is to say that that will definitely happen in the UK? Checking that the certificated code is the code on a system is relatively straight-forward (much easier than hiding vote rigging changes in the code) and should well be within the wit of our electoral authorities if given correct procedural advice (which they would, involvement of Government security agencies is a given at this point in the game).

Thanks for the arrogance line, been a long time since anyone called me that. Let me reverse it for you and see how you like it:

"The arrogance some technologist portray in assuming that massively complex technologies cannot be sufficiently reliable to run our elections is astonishing."

Particularly given that you have no experience in building the kind of system we are talking about. Ever written banking software? Weapons guidance software? The kind of people I'm working with have (as have I), and I have faith and trust in our ability to pull together such systems. Yes it won't be 100% water tight security wise, but nothing is. However the very best brains and technology are being put behind this problem, and for you to assume (from your ivory tower) that it's all a waste of time and we're deluded is frankly astonishing. The code in GNU.Free is very low quality and wouldn't get close to passing a code review where I work. Exception black holes, poor comments, cross-threading, lack of locking, I could go on but I don't want to embarrass you further. When you've built anything bigger than poorly secured CMS software, or a voting system that addresses 5% of the problem domain get back to me and maybe then you can call me arrogant. Until then, don't assume you know it all. Because you don't.