August 2007
Electronic Voting Machines (1 August 2007)
Are Secure Systems Possible? (3 August 2007)
Dealing With Security Problems (6 August 2007)
Minnesota Court Orders Release of Alcohol Breath Tester Source Code (10 August 2007)
Safes, Locks, and Override Codes (14 August 2007)
The Skype Outage (20 August 2007)
Defending Against the Owner (24 August 2007)
The Amtrak Ticket System Outage (26 August 2007)
Update on the Amtrak Outage (28 August 2007)
The FBI and Computer Security (Updated) (29 August 2007)

Electronic Voting Machines

1 August 2007

Lots of other people have already commented on the California voting machine evaluation. See, for example, blog posts by Avi Rubin, Bruce Schneier, and Ed Felten (links to their blogs at the upper left of this page). I won’t bother adding my two cents.

The responses to the evaluation by the vendors have been predictable. The study was unrealistic, it ignores process, an enemy wouldn’t have full access to the source code, etc. But these responses ignore the first two questions that any security professional asks when doing an evaluation: what are you protecting, and against whom?

In the US, most elections are run by political appointees. Over the years, a variety of procedures have been adopted to try to prevent fraud; most of them involve some form of multi-party access. For example, ballot counting is overseen by representatives of all parties. That said, there is often a lot of opportunity for mischief by the party in control in some jurisdiction; if nothing else, they control what machines are purchased. This issue is finally drawing some much-need scrutiny.

The security question, then, is this: are today’s processes, designed for older generations of voting technology, sufficient to protect electronic voting machines? Put more bluntly, given the ease of replacing code, opening locks, and bypassing seals — as described quite vividly in every independent study I’ve seen — are electronic voting machines and the associated processes secure against attacks by insiders? Remember that these insiders have a lot of money and skill, and demonstrably have the motive. Do they have the means? The conclusions of the reports are quite damning with respect to the ease of certain attacks; the real question is whether or not would-be insider attackers have sufficient access. The attacks are fast and easy; I strongly suspect that they’re quite practical, given just a bit of luck.

I should note that I do agree with the vendors and election officials that process is important. I told Avi Rubin that before he released his famous paper on Diebold voting machines; he recounts that story in his book Brave New Ballot. Do we have the right processes today? Look at these pictures, from the ITU and the BBC about the start of an election: the ballot boxes are shown to be empty before the voting starts. What are the high-assurance electronic equivalents? Remember that processes can be attacked with technology; see the "Stuffer’s ballot box" for an old example. And remember that I said "high assurance"; what really happens when the buttons are pressed to show that a voting machine has been cleared?

Ironically, for all that I’m a security expert, my real concern with electronic voting machines is ordinary bugs in the code. These have demonstrably happened. One of the simplest cases to understand is the counter overflow problem: the voting machine used too small a field for the number of votes cast. The machine used binary arithmetic (virtually all modern computers do), so the critical number was 32,767 votes; the analogy is trying to count 10,000 votes if your counter only has 4 decimal digits. In that vein, the interesting election story from 2000 wasn’t Florida, it was Bernalillo County, New Mexico; you can see a copy of the Wall Street Journal story about the problem here.

Our voting machines are badly broken. Fixing them means accepting the technological limitations and designing a system around them, not asserting that they do not exist. It also means fixing what technical problems we can.


Update: Matt Blaze’s blog now discusses the review, too. (Matt was one of the reviewers and couldn’t speak publicly until his report was released.)
https://www.cs.columbia.edu/~smb/blog/2007-08/2007-08-01.html