Techdirt is reporting that voting machines in California, manufactured by Sequoia Voting Systems, allows you to cast multiple votes if the machines are placed in “manual mode.” Apparently the machines emit a “loud beep” when the “manual mode” button is pressed, but that hardly strikes me as an adequate safeguard, especially given that poll workers often receive limited training.
I’ve been beating up on Diebold lately, but the fundamental problem isn’t Diebold-specific. The problem is simply that e-voting is needlessly complex (and therefore error-prone) and inherently insecure. That will continue to be true no matter who’s manufacturing the machines.
Via Slashdot, Diebold is pissed off about HBO’s new documentary “Hacking Democracy.” They say it’s full of inaccuracies. For example:
The first of these material errors is the statement that Diebold tabulated more than 40 percent of the votes cast in the 2000 Presidential election. Diebold was not in the electronic voting business in 2000. Diebold purchased Global Election Systems in 2002, but Global had at the time only eight percent of the market.
Oh wait, it turns out that they haven’t actually seen the film. But they say the promotional materials on HBO’s website suggest the film contains these errors. Of course, they couldn’t be bothered to provide a URL or an in-context quote of the claims in question, so for all I know Diebold is wildly misrepresenting what it says on the website, which could be different from what the documentary says.
Continue reading →
The Miami Herald is reporting that at least one voter in Florida claims that voting machines registered a vote for a Republican after he attempted to vote for a Democrat:
Debra A. Reed voted with her boss on Wednesday at African-American Research Library and Cultural Center near Fort Lauderdale. Her vote went smoothly, but boss Gary Rudolf called her over to look at what was happening on his machine. He touched the screen for gubernatorial candidate Jim Davis, a Democrat, but the review screen repeatedly registered the Republican, Charlie Crist.
That’s exactly the kind of problem that sends conspiracy theorists into high gear–especially in South Florida, where a history of problems at the polls have made voters particularly skittish. A poll worker then helped Rudolf, but it took three tries to get it right, Reed said.
”I’m shocked because I really want . . . to trust that the issues with irregularities with voting machines have been resolved,” said Reed, a paralegal. “It worries me because the races are so close.”
Broward Supervisor of Elections spokeswoman Mary Cooney said it’s not uncommon for screens on heavily used machines to slip out of sync, making votes register incorrectly. Poll workers are trained to recalibrate them on the spot–essentially, to realign the video screen with the electronics inside. The 15-step process is outlined in the poll-workers manual.
The first time I read that, it sounded like nonsense, but after re-reading it I think I can guess what this is trying to say: my guess is that the touch-sensitive electronics are mis-aligned with the screen, so that the machine registers touches as being offset from their actual location.
For example, suppose that the screen is mis-aligned such that each touch is registered as being one inch above its actual position on the screen. In that case, if the Republican candidate’s button were an inch above the Democratic candidate’s button, pressing the screen in the center of the Democrat’s button would register as a press in the center of the Republican button. To vote for the Democrat, you would have to touch the screen an inch below the Democrat’s button. Voter who weren’t paying attention would accidentally vote for the Republican without noticing.
So it sounds to me like this glitch is entirely benign. But here’s the problem: if such glitches are common, they become a good way to mask real tampering. You could, for example, write a program that simulates this glitch in Republican-heavy precincts, while working correctly in Democrat-controlled precincts. In a close election, that might be enough to tip things in favor of the Democrats, and it would be extremely hard to prove afterwards.
Yesterday Ed Felten linked to a Washington Post story about Diebold’s hush-hush recall of 4700 AccuVote-TS voting machines last year. Apparently they had motherboard defects that caused some of them to randomly crash. As Felten explains today, the machines tended to crash at the most inconvenient time possible. He quotes a report on Maryland’s 2004 election:
Election judges and technical staff reported that many of these units froze when the voter pressed the Cast Ballot button. This leads to great confusion for judges and voters. The voter leaves the polling place with little or no confidence that their vote was counted. In many cases, the election judges are unable to provide substantial confirmation that the vote was, in fact, counted.
As Felten explains, this is bad news:
You’d be hard pressed to pick a worse time for a voting machine to crash. The voter has made his selections, confirmed them on the ballot review screen, and now wants them to be recorded. When the Cast Vote button is pressed, the machine reads the intended votes out of its temporary RAM memory and copies them into the official ballot record file, which lives in the machine’s flash memory. If the machine crashes just before the vote is copied, the vote is lost. If it crashes just after the vote is copied, the vote is recorded. It won’t be immediately obvious which case you’re in–hence the confused voters and poll workers.
Obviously, every voting system has problems. But the nice thing about paper ballots is that it’s almost always possible to recover from equipment malfunctions. If there’s doubts about whether an optical-scan or punch-card machine is counting votes correctly, you can run the ballots through another machine or count the votes by hand. Recovering votes from a malfunctioning e-voting machine requires computer forensics skills, and even then it’s a dicey proposition.
Felten’s post makes some other good points about the frightening implications of this kind of bug. Go read the whole thing.
One of the important points made in Jon Stokes’s write up of e-voting is how much easier it is to hide malicious code in a program than it is to find it. This was also a point that Avi Rubin made quite well in Brave New Ballot, when he describes a computer security course he taught in 2004:
I broke the class up into several small groups, and we divided the semester into thirds. In the first third, each group built an electronic voting machine that it demonstrated to the rest of the class. These machines were basically simple programs that allowed a user to make choices among several candidates in different races and that were required to keep an electronic audit log and produce the final tallies when the election was over. The groups then devoted the second third of the term to planting a back door in their voting machines–a mechanism by which a voter could cheat and change the vote totals and the audit logs so that the change would be undetectable. Each team had to turn in two versions of its system, one that worked properly and one that “cheated,” with all the code for both.
The groups spent the last third of the semester analyzing the machines and code from the other groups, looking for malicious code. The goal of the project was to determine whether people could hide code in a voting machine such that others of comparable skill could not find it, even with complete access to the whole development environment. Each group was assigned three machines from other groups–one good one, one bad one, and one chosen at random, but none of them identified as such. That was for the students to figure out by analyzing the code and running the machines. Admittedly, this setting was not much like that of a real manufacturer, in which there would be years to develop and hide malicious code in a code base that would be orders of magnitude larger and more complex than in our little mock-ups. Furthermore, the students had all just spent more than a month developing and hiding their own malicious code, so they had a good idea of what other groups might try. Conversely, in practice, auditors would have considerably more time to analyze and test potential code for problems. Still, I expected the results to be revealing, and I was not disappointed.
Many of the groups succeeded in building machines in which the hidden code was not detected. In addition, some fo the groups succeeded in detecting malicious code, and did so in a way that in and of itself was enlightening. In one case, the student discovered the cheating almot by accident because the compiler used by the programmer was incompatible with the one used by the analyzing team. The experiment demonstrated, as we suspected it would, that hiding code is much easier than finding hidden code.
I think this is a big part of the reason that computer security experts tend to be so skeptical of claims that independent testing has “proven” that a company’s voting machine code was secure. Even if the “independent” firm were genuinely independent, (which it usually isn’t) and even if they were to do a truly exhaustive security audit, (which judging from the Rubin and Felten reports, they usually don’t) it would still be unlikely that they would be able to detect malicious code that was inserted and camouflaged by a relatively talented programmer.
For years, Jon “Hannibal” Stokes has been writing incredibly detailed articles on CPU architecture. He’s particularly good at presenting a lot of in-depth technical information in a way that’s accessible to moderately tech-savvy people. I’m much more capable of pretending to understand CPU architectures after reading his articles.
Now he’s turned his attention to voting machines, and he does his usual thorough and clear job explaining “How to steal an election by hacking the vote”:
hat if I told you that it would take only one person–one highly motivated, but only moderately skilled bad apple, with either authorized or unauthorized access to the right company’s internal computer network–to steal a statewide election? You might think I was crazy, or alarmist, or just talking about something that’s only a remote, highly theoretical possibility. You also probably would think I was being really over-the-top if I told you that, without sweeping and very costly changes to the American electoral process, this scenario is almost certain to play out at some point in the future in some county or state in America, and that after it happens not only will we not have a clue as to what has taken place, but if we do get suspicious there will be no way to prove anything. You certainly wouldn’t want to believe me, and I don’t blame you.
So what if I told you that one highly motivated and moderately skilled bad apple could cause hundreds of millions of dollars in damage to America’s private sector by unleashing a Windows virus from the safety of his parents’ basement, and that many of the victims in the attack would never know that they’d been compromised? Before the rise of the Internet, this scenario also might’ve been considered alarmist folly by most, but now we know that it’s all too real.
Continue reading →
It seems that the United States isn’t the only country having problems with e-voting. They’re having problems up in Canada too. Mike at Techdirt is on the case:
Following a report by Quebec’s electoral chief that runs through all of the problems Quebec had with e-voting machines last year, the government has extended an injunction against e-voting machines that had been put in place after the problems in the election became clear. The elections official admits that there’s no way to tell if last year’s election results were accurate or fair–but that there’s nothing that can be done now. Some opposition politicians, however, are thinking of trying to force the election to be wiped out and held again, claiming that the results clearly were incorrect. To make it even more fun, the firm that supplied the e-voting machines, PG Elections, is apparently upset that Quebec hasn’t paid their bill in full for the machines that didn’t work properly. Even worse, they seem to shrug off the problems: “We have to admit that we did have a few problems,” but he then suggests you have to give them some leeway because “It was the first time all Quebec municipal elections were held on the same day and that so many used electronic voting.” I’m sorry, but if the one thing your machines are supposed to do is handle the election and count people’s votes, it really needs to do that–and trying to brush it aside because it was the first time so many of your machines were being used isn’t just a bad excuse, it’s a reason no one should use your machines again.
Damn straight. I mean, seriously, when’s the last time you heard Ford say “Yeah, our cars tend to break a lot. But give us a break! We’ve never produced this many cars in a single year before.” Vendors need to demonstrate their products are secure before they’re used in real elections.
I’ve finished reading Brave New Ballot, Avi Rubin‘s new book on the hazards of e-voting. Brave New Ballot is something of an oddity; it’s virtually a tech policy tell-all. It provides a personal, in-depth look at his crusade against paperless, unverifyable voting from July 2003, when he and his grad students started work on their famous report detailing the flaws in Diebold’s source code, to November 2004, the first presidential election since the widespread adoption of e-voting. We get to meet his allies in the e-voting fight, his opponents in the computer security community and among state officials, and a variety of other figures who shaped the e-voting debate during 2003 and 2004.
The most depressing thing I learned from the book is that Diebold’s response to the Felten paper was part of a pattern. When Rubin described security vulnerabilities in their products, Diebold could have taken the opportunity deployed smoke and mirrors to discredit the study, just as they did with Felten’s study last month.
Even more disturbing was that many state election officials, especially those in Georgia and Maryland, reacted the same way. They could easily have taken the paper’s criticisms back to Diebold and demanded immediate actions to address the flaws Rubin identified. Instead, at least as Rubin tells it, they were some of Rubin’s most dogged critics.
Rubin’s book is delightfully readable. I read it cover to cover over the weekend. It’s structured as a personal narrative, but Rubin does a good job of weaving in the technical and theoretical arguments against paperless voting along the way.
In addition to being a good introduction to the e-voting issue, I think it’s also worthwhile reading for aspiring geek activists in general: Rubin describes himself as relatively apolitical prior to his involvement in the e-voting issue, and he offers some insights on striking a balance between being an activist and being an independent, objective expert. He discusses the mini-scandal that erupted when it was revealed that he was on the advisory board of one of Diebold’s “competitors.” Rubin says (and I believe him) that the connection was tangential and the company wasn’t really a Diebold competitor. But that didn’t stop his critics from bringing the issue up any time they needed a convenient way to discredit him.
All in all, it’s well worth the read. I encourage you to grab a copy.
I’m reading Avi Rubin’s Brave New Ballot. I’ll have more to say about it when I’ve finished reading it (it’s excellent so far) but I wanted to comment on a passage that caught my eye. On pp. 185-189 Rubin discusses a proposal by Brit Williams to secure voting machines by comparing a hash of each voting machine’s software to a pre-computed hash in a centralized repository:
In the library that Williams envisioned, a cryptographic hash, also called a fingerprint, would be computed on the binary after the software is compiled. The hash would be stored in a secure location, and whenever a machine is rolled out, its software would be rehashed and the hash compared to a stored value, just as fingerprints might be compared. If they match, the software is authentic. If they don’t match, officials are alerted to a problem and can deal with it through predetermined procedures.
Rubin identifies several problems with this idea. He notes that software binaries can change frequently for legitimate reasons, so the library would have to be constantly updated with additional hash values. In addition, he notes that this does nothing to counter threats from insiders; if somebody is in a position to introduce malicious code into machines, he might also be able to introduce a malicious hash value into the library.
Continue reading →
Wired has an article presenting David Wagner and Ed Felten’s recommendations for more secure voting machines. Their specific proposals–voter-verified paper trails; simpler, publicly available source code; ditch removable memory cards–all sound sensible to me. But I think it’s striking that in summary, what they advocate is transforming voting machines into glorified printers:
Touch-screens are easy to use and are flexible enough to accommodate disabled voters and multiple languages. Optical-scan devices provide reliable paper trails.
We recommend a third alternative that combines the best attributes of both–a ballot marking machine, such as one made by Election Systems and Software.
These devices let voters make their choices on a touch-screen. But instead of directly recording the votes digitally onto a memory card, the machine prints the votes onto a full-size paper ballot. Voters or election officials then place the completed ballots onto an optical-scan reader (.pdf), where the votes are recorded digitally.
I suppose this would marginally reduce the error rate by ensuring that all paper ballots are marked clearly. But on the other hand, more complexity means more potential for failure. Printers jam, software has bugs, power cords get tripped over, etc. And even if the machines work flawlessly, it’s not clear to me that it would be worth spending millions of dollars just to save voters the trouble of marking their own ballots.
Update: Felten points out that these are Wired‘s recommendations after talking with Wagner and Felten, and so not all of the recommendations reflect Wagner or Felten’s personal views. My mistake.
The Technology Liberation Front is the tech policy blog dedicated to keeping politicians' hands off the 'net and everything else related to technology.