The Latest Spin From Voting Machine Makers: What Problems?

Last week, I testified before the Texas House Committee on Elections (you can read my testimony). I've done this many times before, but I figured this time would be different. This time, I was armed with the research from the California "Top to Bottom" reports and the Ohio EVEREST reports. I was part of the Hart InterCivic source code team for California's analysis. I knew the problems. I was prepared to discuss them at length. Wow, was I disappointed. Here's a quote from Peter Lichtenheld, speaking on behalf of Hart InterCivic:

Security reviews of the Hart system as tested in California, Colorado, and Ohio were conducted by people who were given unfettered access to code, equipment, tools and time and they had no threat model. While this may provide some information about system architecture in a way that casts light on questions of security, it should not be mistaken for a realistic approximation of what happens in an election environment. In a realistic election environment, the technology is enhanced by elections professionals and procedures, and those professionals safeguard equipment and passwords, and physical barriers are there to inhibit tampering. Additionally, jurisdiction ballot count, audit, and reconciliation processes safeguard against voter fraud.

You can find the whole hearing online (via RealAudio streaming), where you will hear the Diebold/Premier representative, as well as David Beirne, the director of their trade organization, saying essentially the same thing. Since this seems to be the voting system vendors' party line, let's spend some time analyzing it.

Did our work cast light on questions of security? Our work found a wide variety of flaws, most notably the possibility of "viral" attacks, where a single corrupted voting machine could spread that corruption, as part of regular processes and procedures, to every other voting system. In effect, one attacker, corrupting one machine, could arrange for every voting system in the county to be corrupt in the subsequent election. That's a big deal. At this point, the scientific evidence is in, it's overwhelming, and it's indisputable. The current generation of DRE voting systems have a wide variety of dangerous security flaws. There's simply no justification for the vendors to be making excuses or otherwise downplaying the clear scientific consensus on the quality of their products.

Were we given unfettered access? The big difference between what we had and what an attacker might have is that we had some (but not nearly all) source code to the system. An attacker who arranged for some equipment to "fall off the back of a truck" would be able to extract all of the software, in binary form, and then would need to go through a tedious process of reverse engineering before reaching parity with the access we had. The lack of source code has demonstrably failed to do much to slow down attackers who find holes in other commercial software products. Debugging and decompilation tools are really quite sophisticated these days. All this means is that an attacker would need additional time to do the same work that we did.

Did we have a threat model? Absolutely! See chapter three of our report, conveniently titled "Threat Model." The different teams working on the top to bottom report collaborated together to draft this chapter. It talks about attackers' goals, levels of access, and different variations on how sophisticated an attacker might be. It is hard to accept that the vendors can get away with claiming that the reports did not have a threat model, when a simple check of the table of contents of the reports disproves their claim.

Was our work a "realistic approximation" of what happens in a real election? When the vendors call our work "unrealistic", they usually mean one of two things:

• 1
• 2
• 3
• Next page »
View as a single page