SYSSEC: December 2007 Archives


December 14, 2007

Ohio just published the results of their voting system review. They examined Hart, Premier Election Systems (formerly Diebold) and ES&S. Hart and Diebold were part of the California TTBR and a skim of the TOC and a sampling of the sections suggests that these reports mostly confirm the California/UC result (with one interesting new Hart vuln that allows an attacker with physical access to the interfaces to emulate keypresses, thus automating vote injection.) ES&S was not part of the UC review (but a smaller review was done afterward) and the Ohio team seems to have found serious problems in the ES&S system as well.

December 13, 2007

San Francisco has selected Sequoia Voting Systems voting machines, replacing their current ES&S systems. Reading the coverage, it's clear that whether SVS would open source their software was a big issue. It's not clear, however, whether SVS actually agreed to. Here's the Merc:
"This is a good system in front of us," Alioto-Pier said. "We should be excited for having it." She added that she felt open-source voting was important, but not readily achievable currently.

"Many of us are holding our noses around this vote," said Supervisor Tom Ammiano, who also opposed the resolution but acknowledged the agreement contained "some positives."

Ammiano said Sequoia had agreed to a third-party inspection of its source code and to bring its software into open-source compliance within a year.

Ammiano said a long-term solution might be for San Francisco to consider furnishing its own computer voting systems, to 'ensure that open source and transparency will happen,' he said.

The Examiner doesn't say anything about such a commitment:

"Until we take a stand and either force the vendors to open their source code to us or develop or own open source voting systems, really, what we did this past cycle is the only way that we can guarantee that every voters vote gets counted," he said.

Supervisor Sean Elsbernd countered that opponents "need to be a little bit more real" about The City's choices.

"Let's vote down this contract, and then what? We get to keep ES&S, the frauds. We cannot do that," Elsbernd said.

Supervisor Gerardo Sandoval said that with three elections on the horizon that The City needed to approve the contract.

"These elections are too important to have the results tabulated a month after the rest of the country knows what happens," he said, adding, "We can deal with the open- source issue at a later time."

I can't really tell whether SVS promised anything or not, but I'm not sure it really matters much one way or the other. First, if what you're concerned about is openness about the software the election is running, you don't need open source; you need published source. Open source software is about your ability to copy it and use it for your own purposes, but it's not clear why that's important for running elections. It's not like we're going to have election software up on SourceForge and then have the State of California compile the head of tree six weeks before the election. I suppose it's sort of possible that you would want to allow independent vendors to use Sequoia's software on their own hardware platforms, but given the certification requirements for the hardware—and the fact that each vendor has their own hardware—that seems fairly problematic.

If you're concerned about the security of elections, what you really need is to know that the software running the elections can be and has been reviewed. At most, though, that would require that the vendors publish copies of their source code so that people could review it. In this case, though, the software in question has already been reviewed fairly intensively, and the reviewers found fairly serious vulnerabilities. Given that, it's not clear how much you'd really learn about the security of the system from having the source code public so that people could informally review it.