% fortune -ae paul murphy

Hacking the vote

Since tomorrow is election day in the United States, I thought I'd add one more comment about e-voting.

Here's a bit from an October 8th, 2008, article in Science Daily under the title Hack-a-vote: Students Learn How Vulnerable Electronic Voting Really Is

Undergraduate and graduate students in an advanced computer security course at Rice University in Houston are learning hands-on just how easy it is to wreak havoc on computer software used in today's voting machines.

As part of his advanced computer science class, Rice University Associate Professor and Director of Rice's Computer Security Lab Dan Wallach tests his students in a unique real-life experiment: They are instructed to do their very best to rig a voting machine in the classroom.

The page quoted above contains several links to related stories from the same site outlining various concerns about the integrity of these systems, all of which also have two other things in common with the story quoted:

  1. Not a single one of the researchers quoted here, or elsewhere as far as I know, point out that the problem isn't the voting machine, it's the system architecture within which these are used that's at fault; and,

  2. Every single one of the papers I've read on this makes the implicit assumption that someone trying to use e-voting to commit fraud would attack the e-voting machines.

Computer hacking works brilliantly on NCIS and other television shows but, in real life, it usually makes a lot more sense to subvert people than machines. Think for a minute about the numbers: what would reprogramming even a few hundred voting machines get you in a national or state wide election? The answer, of course, is "not enough to justify the risk."

Thus if I were asked how to commit voting fraud in an American election, I'd go for the traditional stuff: getting pre-stuffed ballot boxes ready for their miraculous appearance during recounts, having lots of highly visible lawyers around to intimidate any electoral official forced to make a decision, create a couple of million fake voters to mislead pollsters and create opportunities for people to vote both early and often.

Computerized voting should have put an end to these kinds of fraud - and my Sun Ray based proposal would do exactly that because all data is transmitted and tabulated live with registrations verified on line - but past and present client-server evoting implementations have actually had the opposite effect.

The reason it's had that effect hasn't been that the machines are easily hacked (although I believe they are) -it's that the data collection process combines with the registration and voting processes to create new opportunities for large scale fraud.

Imagine, for example, that one of the people taking data from individual evoting machines to create poll and district totals is a fraudster. Under what circumstances do you think the people watching this process would notice if he substituted a pre-made electronic record of his own for the real one, and then sent the real record to a confederate with access to the physical ballot transportation and storage system and the ability to stuff in just the right number of ballots to make recounts match the electronic record?

My answer? I think there are lots of opportunities to do this and nothing in either the technologies nor the audit make it either very difficult or very risky.

The bottom line for a fraudster is simple: compared to rigging a few voting machines, processes which take advantage of time and focus gaps in the vote management process require that less manpower per vote delivered and don't leave trails for auditors to find.

The bottom line for the rest of us is that in existing evoting technologies the problem isn't that the machines are so easily corrupted, it's that their role in the overall process creates new opportunities for socially engineered fraud - and that's where my Sun Ray idea really shines because eliminating the client-server architecture also eliminates the flaws it brings into the process.

(Note: links to zdnet no longer work; the prior docs mentioned can be found on my site at:

Dancing on E-voting's grave Resurrecting E-voting

and:

An open Letter to Larry Ellison


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.