Is E-Voting Fundamentally Flawed?
One Johns Hopkins study could be Diebold's Cassandra song.
Lance Ulanoff - PC Magazine

Oct. 13

On November 2, hundreds of thousands of Americans will step into electronic voting booths, many of them for the first time. They'll likely be confronted with a touch screen that steps them through the local and national candidates, as well as the local propositions that are usually stuffed onto the ballot.

This is not, as we all know, just any election year. We're choosing our next president—the incumbent or a new one. As a result, the performance of these electronic voting systems will be watched with keen eyes and worried minds. Will they be accurate? Are they secure? Can you have such a thing as a virtual hanging chad? My gut tells me that these systems will work flawlessly next month, but the concern is well founded.

An exhaustive 2003 report from the Johns Hopkins University (Analysis of an Electronic Voting System, July 23, 2003) outlines more than half a dozen key ways in which the security, accuracy, and overall functionality of an electronic voting system—a Diebold AccuVote-TS, to be precise—could be compromised. According to Diebold spokesperson David Bear, the AccuVote-TS is currently in use in 40 states across the U.S. Of those, just Georgia employs it statewide; Maryland uses it everywhere outside Baltimore. The report's conclusions are derived from an analysis of voting-system code left on a Diebold FTP site. A reporter claimed that she stumbled onto the FTP site while doing a Google search. Diebold was aware of the code's existence and its accessibility and does not deny that it's theirs. The Johns Hopkins research team did not actually get the files from the Diebold site, however. As they tell it, they found a copy of them on a New Zealand server. Bear told me that "we haven't denied it's our code, but it's incomplete, outdated, and never run in an election."

So the Johns Hopkins study is, to a certain extent, an extrapolation from a central idea that could be flawed. Even so, the study also looks at aspects of the e-voting system beyond the code. Taken as a whole, the report does not paint a comforting picture.

I read through the study and then caught up with one of its authors, Rice University computer sciences professor Dan Wallach. Wallach's been teaching graduate students about building secure and robust online systems for the past six years. He worked on the study with another professor, Tadayoshi Kohno of Johns Hopkins, and two graduate students. With the report now a good year and a half old, I thought it would be illuminating to walk Wallach back through some of the key charges leveled against Diebold and see if he had in any way modified his views, and to see how, with the election just weeks away, Diebold's Bear is answering the charges leveled against his company.

The code held a "gold mine" of information for Wallach and his team. It was actually a CVS (Concurrent Versions System) archive, which means that two years' worth of coding iterations was stored in the files, and researchers could literally roll back and forth through the code to see what was done at any given point in time.

"The design and engineering of the system was astonishingly shoddy and naïve," recalled Wallach.

Even so, what the researchers looked at was, by their own admission, clearly a work in progress full of engineering comments and half-baked coding. Wallach and his team made the leap that these things indicated sloppy and easily hackable code. But without the completed code, I'm not sure of how they could have reached that conclusion. Wallach also told me that his team believed that the last code-check-in date, April 2002, was indicative of it being used in the November 2002 elections in Georgia. Normally, Diebold would submit the code for certification a few months before it's used in a live election.

The researchers also questioned the use of C++ for the original code, calling it an "unsafe language." Microsoft Windows is largely written in C++, and most UNIX systems are written in a combo of C and C++. It's not impossible to write good code in C++, but it's much harder than using modern code. "Modern code has features to help prevent you from making the most common mistakes," contended Wallach.

But Diebold's Bear told me the Hopkins study was deeply flawed and that the conclusions it reached were based on results derived by running the code on a system it was never meant to be used on. He also said that the researchers' labs-based testing was worlds away from a real-world voting environment. "[The] most grievous [assumption] is someone could hack into the system, without noticing that the touch-screen systems are standalone units—[the] biggest misperception of their study."

Some of the concerns in the report revolved around the system's reliance on smart cards. There are two kinds used with these systems: One is the card voters receive and use when they vote—it identifies the proper ballot and is then erased and given back to the voter, who then returns it to the voting official. The other is the administrator card that is used to configure each voting booth and end the elections. The Johns Hopkins study paints a scenario of hackers creating home-brewed cards—if they know the protocol—that would allow voters to vote multiple times. A hacked admin card could, the researchers claim, lead to the ballot being set up in such a way to nullify one candidate's results or even end the election in that booth prematurely.

I asked Wallach about what problems he sees with the smart-card protocol used on the AccuVote-TS machines. "The way Diebold designed the smart-card protocol is insufficient for the task they wanted to do. It is possible to do a better security card. It's a homework assignment for my security class."

Bear confirmed to me that the AccuVote-TS does use smart cards for the voters and as an admin tool, but Diebold is confident in the passcode and physical security measures in place to protect the cards. Even if one buys the assumption that someone could make his or her own smart card, Bear said the polling-place environment is not exactly conducive to surreptitiously slipping it into the mix. "If someone wanted to disrupt an election, it would be much easer to knock over a machine," he added. And even the largely critical study noted that someone will be keeping count of the number of people entering the booth. If 20 go in and the e-voting system accounts for 400 voters, then we'll know something's amiss.

Encryption is also addressed in the report. The Wallach team wrote that the cryptography in the coding they saw was subpar and deeply flawed, because all the Diebold voting systems, the report contends, used the same key. "Imagine if every car manufactured had the same ignition key. It wouldn't be long before people realized you could start any car with your key. That's precisely what Diebold did with their crypto," Wallach told me.

But accessing the encryption key on any voting system isn't that easy. You have to have access to a voting machine and then the code that runs it. Unfortunately, that's exactly the researchers' and Wallach's point. If what they were looking at was Diebold's real commercial code, then, Wallach believes, many, many people already have access to the exact key in use on machines across the U.S. This presupposes that the code the researchers found is real, that someone can figure out how to get a dummy smart card into the voting kiosk, and that it all works.

The security is so low on these systems, the report contends, that the researchers think it appears to rely on "security through obscurity." In other words, the system is theoretically secure because the relatively low security mechanisms are hidden from public view. I think Microsoft originally developed OS code this way until it realized (or acknowledged) that hackers would spend hours, days, even years digging for vulnerabilities to exploit.

Bear countered by telling me that the researchers are just flat wrong. The encryption key is not the same on all systems, said Bear. Following a third-party assessment of the voting system, Diebold enhanced the systems so that administrators could set dynamic passcodes. But this is an enhancement that was only added in those jurisdictions that requested it. I asked Bear if that means that all other AccuVote-TS systems still had the same encryption code. "Quite honestly, I don't know if there are any that are that way," he replied.

Connectivity to central databases and the outside world is also an issue for the Johns Hopkins brain trust. According to the report, the Diebold AccuVote-TS system, in some cases, will communicate via modem or even wireless Internet with central databases. On the wireless side, the transmission could be intercepted. But I was more entertained by the DoS (denial of service) scenario. Actually, it's not a scenario. It really happened once. All the voting machines attempted to "phone home" at once with their data and essentially created a DoS situation on the server, which then blocked all incoming calls and caused the vote tallies to be delayed by more than a day. This was the rare issue that Wallach actually acknowledged has been addressed. Most election officials no longer use the system's built-in modems; they instead hand-deliver the memory cards to the central board of elections in their jurisdiction.

For my money, however, the biggest problem with Diebold's e-voting machines is the lack of a paper audit trail. The Diebold voting kiosks have no printout. There's nothing for voters to carry off with them to verify that their ballots have been registered. Sequoia Voting Systems [[<

There is, according to Diebold's Bear, a good reason that the AccuVote-TS does not provide paper receipt for voters—no form of traditional voting provides paper receipts. He's right, of course. I've been voting for over 20 years, and though I've used various lever and punch systems, not one of them has offered me a way to verify that the booth accurately captured my votes. I always walked away and trusted the system. Perhaps we all did until Florida 2000.

And that, of course, is the point. This election will leave no margin for error or even the possibility of one. Neither Wallach nor Bear convinced me 100 percent that e-voting systems will be trustworthy or not. Diebold has clearly made changes to its system that may or may not have been driven by the Johns Hopkins research findings—I tend to believe that some were—but are they enough? I asked Wallach if he's still concerned about the November elections, and his response was chilling.

"I'm certainly concerned, and my biggest concern is that it's really too late to address the problem for November 2nd. The election officials, who could have done something about the problem, instead dismissed us and dismissed the report, and now it's too late to make changes. My crystal ball doesn't tell me if we're going to have a major meltdown on November 2nd. If something goes wrong, if there are irregularities, if exit polls do not synch with election tallies, then people will have legitimate reasons to suspect that things are wrong, and that could undermine confidence in the entire electoral system."