Yesterday I chaired an interesting panel on Internet Voting at CFP. Participants included Amy Bjelland and Craig Stender (State of Arizona), Susan Dzieduszycka-Suinat (Overseas Vote Foundation) Avi Rubin (Johns Hopkins), and Alec Yasinsac (Univ. of South Alabama). Thanks to David Bruggeman and Cameron Wilson at USACM for setting up the panel.

Nobody advocated a full-on web voting system that would allow voting from any web browser. Instead, the emphasis was on more modest steps, aimed specifically at overseas voters. Overseas voters are a good target population, because there aren't too many of them -- making experimentation less risky -- and because vote-by-mail serves them poorly.

Discussion focused on two types of systems: voting kiosks, and Internet transmission of absentee ballots.

A voting kiosk is a computer-based system, running carefully configured software, that is set up in a securable location overseas. Voters come to this location, authenticate themselves, and vote just as they would in a polling place back home. A good kiosk system keeps an electronic record, which is transmitted securely across the Internet to voting officials in the voter's home jurisdiction. It also keeps a paper record, verifiable by the voter, which is sent back to voting officials after the elections, enabling a post-election audit. A kiosk can use optical-scan technology or it can be a touch-screen machine with a paper trail -- essentially it's a standard voting system with a paper trail, connected to home across the Internet. If the engineering is done right, if the home system that receives the electronic ballots is walled off from the central vote-tabulating system, and if appropriate post-election auditing is done, this system can be secure enough to use. All of the panelists agreed that this type of system is worth trying, at least as a pilot test.

The other approach is use ordinary absentee ballots, but to distribute them and allow voters to return them online. A voter goes to a web site and downloads a file containing an absentee ballot and a cover sheet. After printing out the file, the voter fills out the cover sheet (giving his name and other information) and the ballot. He scans the cover sheet and ballot, and uploads the scan to a web site. Election officials collect and print the resulting file, and treat the printout like an ordinary absentee ballot.

Kevin Poulsen and Eric Rescorla criticize the security of this system, and for good reason. Internet distribution of blank ballots can be secure enough, if done very carefully, but returning filled-out ballots from an ordinary computer and browser is risky. Eric summarizes the risks:

We have integrity issues here as well: as Poulsen suggests (and quotes Rubin as suggesting), there are a number of ways for things to go wrong here: an attacker could subvert your computer and have it modify the ballots before sending them; you could get phished and the phisher could modify your ballot appropriately before passing it on to the central site. Finally, the attacker could subvert the central server and modify the ballots before they are printed out.

Despite the risks, systems of this sort are moving forward in various places. Arizona has one, which Amy and Craig demonstrated for the panel's audience, and the Overseas Vote Foundation has one as well.

Why is this less-secure alternative getting more traction than kiosk-based systems? Partly it's due to the convenience of being able to vote from anywhere (with a Net connection) instead of having to visit a kiosk location. That's understandable. But another part of the reason seems to be that people don't realize what can go wrong, and how often things actually do go wrong, in online interactions.

In the end, there was a lot of agreement among the panelists -- a rare occurrence in public e-voting discussions -- but disagreement remained about how far we can go safely. For overseas voters at least, the gap between what is convenient and what can be made safe is smaller than it is elsewhere, but that gap does still exist.

I've previously summarized my own testimony and other plaintiffs' witnesses' testimony in the New Jersey voting machines trial, Gusciora v. Corzine.

The defendant is the State of New Jersey (Governor and Secretary of State). The defense case comprised the following witnesses:

Defense witness James Clayton, the Ocean County voting machine warehouse supervisor, is a well-intentioned official who tries to have good procedures to secure the Ocean County voting machines. Still, it became apparent in his testimony that there are security gaps regarding transport of the machines, keys to the machines, and security at polling places before and after election day.

Richard Woodbridge is a patent attorney who has chaired the NJ Voting Machine Examination Committee for more than 20 years. It's not clear why the defendants called him as a witness, because they conducted only a 15-minute direct examination in which he didn't say much. On cross-examination he confirmed that his committee does not conduct an independent analysis of software and does not consult with any computer security experts.

Robert Giles, Director of Elections of the State of New Jersey, testified about experimenting with different forms of seals and locks that New Jersey might apply to its AVC Advantage voting machines. On cross examination, it became clear that there is no rhyme or reason in how the State is choosing seals and other security measures; that they're not getting expert advice on these matters. Also he admitted that there are no statewide control or even supervision of the procedures that counties use to safeguard the voting machines, the results cartridges, keys, and so on. He confirmed that several counties use the cartridges as the official tally, in preference to paper printouts witnessed and signed (at the close of the polls) by election workers.

Edwin Smith testified as an expert witness for the State defendants. Mr. Smith is vice-president and part owner of Sequoia Voting Systems. He stands to gain financially depending on the verdict in this trial: NJ represents 20% of Sequoia's market, and his bonuses depend on sales. Mr. Smith testified to rebut my testimony about fake Z80 processors. (Wayne Wolf, who testified for plaintiffs about fake Z80s, testified after Mr. Smith, as a rebuttal witness.) Even though Mr. Smith repeatedly referred to replacement of Z80s as "science fiction", he then offered lengthy testimony about methods to try to detect fake Z80s. This gave credence to the fact that fraudulent CPUs are not only a possibility but a real threat.

Mr. Smith also confirmed that it is a security risk to connect WinEds computers (that prepare electronic ballot definitions and tabulate results) to the Internet, and that those counties in NJ that do so are making a mistake.

Paul Terwilliger testified as a witness for the defense. Mr. Terwilliger is a longtime employee and/or contractor for Sequoia, who has had primary responsibility over the development of the AVC Advantage for the last 15 years. Mr. Terwilliger admitted that in 2003 the WIPO found that he'd acted in bad faith by cybersquatting on the Diebold.com domain name at the request of Sequoia. Mr. Terwilliger testified that it is indeed possible to program an FPGA to make a "fake Z80" that cheats in elections. But, he said, there are some methods for detecting FPGAs installed on AVC Advantage voting machines instead of the legitimate (Some of these methods are impractical, others are ineffective, others are speculative; see Wayne Wolf's report.) This testimony had the effect of underscoring the seriousness of the fake-Z80 threat.

Originally the defendants were going to rely on Professor Michael Shamos of Carnegie Mellon University as their only expert witness. But the Court never recognized him as an expert witness. The Court ruled that he could not testify about the security and accuracy of the AVC Advantage, because he had not offered an opinion about security and accuracy in his expert report or his deposition.

The Court did permit him to testify in general terms. He said that in real life, we have no proof that a "hacked election" has ever occurred; and that in real life, such a hack would somehow come to light. He offered no studies that support this claim.

Professor Shamos attempted to cast doubt in the Court's mind about the need for software independence, and disparaging precinct-based optical scan voting (PCOS). But he offered no concrete examples and no studies regarding PCOS.

On many issues, Professor Shamos agreed with the plaintiffs' expert: it's straightforward to replace a ROM chip, plastic-strap seals provide only a veneer of protection, the transformed machine can cheat, and pre-election logic-and-accuracy testing would be ineffective in detecting the fraud. He does not dispute many of the bugs and user-interface design flaws that we found, and recommends that those should be fixed.

Professor Shamos admitted that he is alone among computer scientists in his support of paperless DREs. He tried to claim that other computer scientists such as Ted Selker, Douglas W. Jones, Joseph Lorenzo Hall also supported paperless DREs by saying they supported parallel testing--implying that those scientists would consider paperless DREs to be secure enough with parallel testing--but during cross-examination he backed off a bit from this claim. (In fact, as I testified in my rebuttal testimony, Drs. Jones and Hall both consider PCOS to have substantially stronger security, and to be substantially better overall, than DREs with parallel testing.)

Parallel testing is Professor Shamos's proposed method to detect fraudulent software in electronic voting machines. In order to catch software that cheats only on election day, Professor Shamos proposes to cordon off a machine and cast a known list of test votes on it all day. He said that no state has ever implemented a satisfactory parallel testing protocol, however.

Summary of the defendant's case

One of the plaintiffs' most important claims--which they demonstrated on video to the Court--is that one can replace the firmware of the AVC Advantage voting machine with fraudulent firmware that changes votes before the polls close. No defense witness contradicted this. To the extent that the defense put up a case, it hinged on proposed methods for detecting such fraudulent firmware, or on proposed methods for slowing down the attack by putting tamper-evident seals in the way. On both of these issues, defense witnesses contradicted each other, and plaintiffs presented rebuttal witnesses.

Short version: we now have gobs of voting system ITA reports, publicly available and hosted by the NSF ACCURATE e-voting center. As I explain below, ITA's were the Independent Testing Authority laboratories that tested voting systems for many years.

Long version: Before the Election Assistance Commission (EAC) took over the testing and certification of voting systems under the Help America Vote Act (HAVA), this critical function was performed by volunteers. The National Association of State Election Directors (NASED) recognized a need for voting system testing and partnered with the Federal Election Commission (FEC) to establish a qualification program that would test systems as having met or exceeded the requirements of the 1990 and 2002 Voting System Standards.^*

However, as I've lamented many, many times over the years, the input, output and intermediate work product of the NASED testing regime were completely secret, due to proprietary concerns on behalf of the manufacturers. Once a system completed testing, members of the public could see that an entry was made in a publicly-available spreadsheet listing the tested components and a NASED qualification number for the system. But the public was permitted no other insight into the NASED qualification regime.

Researchers were convinced from what evidence was available that the quality of the testing was highly inadequate and that the expertise didn't exist within either the testing laboratories to perform adequate testing or the NASED technical committee to competently review the ultimate test reports submitted by the laboratories (called Independent Testing Authorities (ITA)). Naturally, when reports of problems started to crop-up, like the various Hursti vulnerabilities with Diebold memory cards, the NASED system scrambled to figure out what went wrong.

I know have more moderate views with respect to the NASED regime: sure, it was pretty bad and a lot of serious vulnerabilities slipped through the cracks, but I'm not yet convinced that just having the right people or a different process in place would have resulted in fewer problems in the field. To have fixed the NASED system would have required improvements on all fronts: the technology, the testing paradigms, the people involved and the testing and certification process.

The EAC has since taken over testing and certification. Their process is notable in its much higher level of openness and accountability; the test plans are published (previously claimed as proprietary by the testing labs), the test reports are published (previously claimed as proprietary by the vendors) and the process is specified in detail with a program manual, a laboratory manual, notices of clarification, etc.

This is all great and it helps to increase the transparency of the EAC certification program. But, what about the past? What about the testing that NASED did? Well, we don't know much about it for a number of reasons, chief among them that we never saw any of the materials mentioned above that are now available in the new EAC system.

Through a fortunate FOIA request made of the EAC on behalf of election sleuth Susan Greenhalgh, we now have available a slew of ITA reports from one of the ITAs, Ciber.

The reports are available at the following location (hosted by our NSF ACCURATE e-voting center):

http://accurate-voting.org/docs/ita-reports/

These reports cover the Software ITA testing performed by the ITA Ciber for the following voting systems:

• Automark AIMS 1.0.9
• Diebold GEMS 1.18.19
• Diebold GEMS 1.18.22
• Diebold GEMS 1.18.24
• Diebold AccuVote-TSx Model D
• Diebold AccuVote-TSx Model D w/ AccuView Printer
• Diebold Assure 1.0
• Diebold Assure 1.1
• Diebold Election Media Processor 4.6.2
• Diebold Optical Scan Accumulator Adapter
• Hart System 4.0
• Hart System 4.1
• Hart System 6.0
• Hart System 6.2
• Hart System 6.2.1

I'll be looking at these in my leisure over coming weeks and pointing out interesting features of these reports and the associated correspondence included in the FOIA production.

^*The distinction between certification and qualification, although vague, appears to be that under the NASED system, states did the ultimate certification of a voting system for fitness in future elections.

Sometimes, working on voting seems like running on a treadmill. Old disagreements need to be argued again and again. As long as I've been speaking in public about voting, I've discussed the need for voting systems' source code to be published, as in a book, to create transparency into how the systems operate. Or, put another way, trade secrecy is anathema to election transparency. We, the people, have an expectation that our election policies and procedures are open to scrutiny, and that critical scrutiny is essential to the exercise of our Democracy. (Cue the waving flags.)

On Tuesday, the Election Technology Council (a trade association of four major American voting system manufacturers) put out a white paper on open-source and voting systems. It's nice to see them finally talking about the issue, but there's a distinctive cluelessness in this paper about what, exactly, open source is and what it means for a system to be secure. For example, in a sidebar titled "Disclosed vs. Open: Clarifying Misconceptions", the report states:

... taking a software product that was once proprietary and disclosing its full source code to the general public will result in a complete forfeiture of the software's security ... Although computer scientists chafe at the thought of "security through obscurity," there remains some underlying truths to the idea that software does maintain a level of security through the lack of available public knowledge of the inner workings of a software program.

Really? No. Disclosing the source code only results in a complete forfeiture of the software's security if there was never any security there in the first place. If the product is well-engineered, then disclosing the software will cause no additional security problems. If the product is poorly-engineered, then the lack of disclosure only serves the purpose of delaying the inevitable.

What we learned from the California Top-to-Bottom Review and the Ohio EVEREST study was that, indeed, these systems are unquestionably and unconscionably insecure. The authors of those reports (including yours truly) read the source code, which certainly made it easier to identify just how bad these systems were, but it's fallacious to assume that a prospective attacker, lacking the source code and even lacking our reports, is somehow any less able to identify and exploit the flaws. The wide diversity of security flaws exploited on a regular basis in Microsoft Windows completely undercuts the ETC paper's argument. The bad guys who build these attacks have no access to Windows's source code, but they don't need it. With common debugging tools (as well as customized attacking tools), they can tease apart the operation of the compiled, executable binary applications and engineer all sorts of malware.

Voting systems, in this regard, are just like Microsoft Windows. We have to assume, since voting machines are widely dispersed around the country, that attackers will have the opportunity to tear them apart and extract the machine code. Therefore, it's fair to argue that source disclosure, or the lack thereof, has no meaningful impact on the operational security of our electronic voting machines. They're broken. They need to be repaired.

The ETC paper also seems to confuse disclosed source (published, as in a book) with open source (e.g., under a GPL or BSD license). For years, I've been suggesting that the former would be a good thing, and I haven't taken a strong position on the latter. Even further, the ETC paper seems to assume that open source projects are necessarily driven by volunteer labor, rather than by companies. See, for example:

... if proprietary software is ripped open through legislative fiat, whatever security features exist are completely lost until such time that the process improvement model envisioned by the open source community has an opportunity to take place (Hall 2007).

There are plenty of open-source projects that are centrally maintained by commercial companies with standard, commercial development processes. There's no intrinsic reason that software source code disclosure or open licensing makes any requirements on the development model. And, just because software is suddenly open, there's indeed no guarantee that a community of developers will magically appear and start making improvements. Successful open source communities arise when distinct developers or organizations share a common need.

Before I go on, I'll note that the ETC report has cherry-picked citations to support its cause, and those citations are neither being used honestly nor completely. The above citation to Joe Hall's 2007 EVT paper distorts Hall's opinions. His actual paper, which surveys 55 contracts between voting system manufacturers and the jurisdictions that buy them, makes very specific recommendations, including that these contracts should allow for source code review in the pre-election, post-election, and litigation stages of the election cycle. Hall is arguing in favor of source code disclosure, yet the citation to his paper would seem to have him arguing against it!

So, how would open source (or disclosed source) work in the commercial voting machine industry? The ETC paper suggests that it might be difficult to get an open-source project off the ground with distributed development by volunteers. This is perfectly believable. Consequently, that's not how it would ever work. As I said above, I've always advocated for disclosure, but let's think through how a genuine open-source voting machine might succeed. A likely model is that a state, coalition of states, or even the Federal government would need to step in to fund the development of these systems. The development organization would most likely be a non-profit company, along the lines of the many Federally Funded Research and Development Centers (FFRDCs) already in existence. Our new voting FFRDC, presumably sponsored by the EAC, would develop the source code and get it certified. It would also standardize the hardware interface, allowing multiple vendors to build compatible hardware. Because the code would be open, these hardware vendors would be free to make enhancements or to write device drivers, which would then go back to the FFRDC for integration and testing. (The voting FFRDC wouldn't try to take the code to existing voting systems, so there's no worry about stealing their IP. It's easier to just start from scratch.) My hypothetical FFRDC model isn't too far away from how Linux is managed, or even how Microsoft manages Windows, so this isn't exactly science fiction.

The ETC paper asks who would develop new features as might be required by a customer and suggests that the "lack of a clear line of accountability for maintaining an open source project" would hinder this process. In my hypothetical FFRDC model, the customer could commission their own programmers to develop the enhancement and contribute this back to the FFRDC for integration. The customer could also directly commission the FFRDC or any other third-party to develop something that suits their needs. They could test it locally in mock elections, but ultimately their changes would need to pass muster with the FFRDC and the still-independent certification and testing authorities. (Or, the FFRDC could bring the testing/certification function in-house or NIST could be funded to do it. That's a topic for another day.) And, of course, other countries would be free to adopt our hardware and customize our software for their own needs.

Unfortunately, such a FFRDC structure seems unlikely to occur in the immediate future. Who's going to pay for it? Like it or not, we're going to be stuck with the present voting system manufacturers and their poorly engineered products for a while. The challenge is to keep clarity on what's necessary to improve their security engineering. By requiring source code disclosure, we improve election transparency, and we can keep pressure on the vendors to improve their systems. If the security flaws found two years ago in the California and Ohio studies haven't been properly fixed by one vendor while another is making progress, that progress will be visible and we can recommend that the slow vendor be dropped.

A secondary challenge is to counter the sort of mischaracterizations that are still, sadly, endemic from the voting system industry. Consider this quote:

If policymakers attempt to strip the intellectual property from voting system software, it raises two important areas of concern. The first is the issue of property takings without due process and compensation which is prohibited under the United States Constitution. The second area of concern is one of security. The potential for future gains with software security will be lost in the short-term until such time that an adequate product improvement model is incorporated. Without a process improvement model in place, any security features present in current software would be lost. At the same time, the market incentives for operating and supporting voting products would be eliminated.

For starters, requiring the disclosure of source code does not represent any sort of "taking" of the code. Vendors would still own copyrights to their code. Furthermore, they may still avail themselves of the patent system to protect their intellectual property. Their only loss would be of the trade secret privilege.

And again, we've got the bogus security argument combined with some weird process improvement model business. Nobody says that disclosing your source requires you to change your process. Instead, the undisputed fact that these vendors' systems are poorly engineered requires them to improve their processes (and what have they been doing for the past two years?), which would be necessary regardless of whether the source code is publicly disclosed.

Last but not least, it's important to refute one more argument:

Public oversight is arguably just as diminished in an open source environment since the layperson is unable to read and understand software source code adequately enough to ensure total access and comprehension. ... However, effective oversight does not need to be predicated on the removal of intellectual property protections. Providing global access to current proprietary software would undermine the principles of intellectual property and severely damage the viability of the current marketplace.

Nobody has ever suggested that election transparency requires the layperson to be able to understand the source code. Rather, it requires the layperson to be able to trust their newspaper, or political party, or Consumer Reports, or the League of Women Voters, to be able to retain their own experts and reach their own conclusions.

As to the "principles of intellectual property", the ETC paper conflates and confuses copyright, patent, and trade secrets. Any sober analysis must consider these distinctly. As to the "viability of the current marketplace", the market demands products that are meaningfully secure, usable, reliable, and affordable. So long as the present vendors fail on one or more of these counts, their markets will suffer.

Update: Gordon Haff chimes in at cnet, on how the ETC misconceptions about how open source development procedures work are far from atypical.

Today Will Clarkson, Tim Weyrich, Adam Finkelstein, Nadia Heninger, Alex Halderman and I released a paper, Fingerprinting Blank Paper Using Commodity Scanners. The paper will appear in the Proceedings of the IEEE Symposium on Security and Privacy, in May 2009.

Here's the paper's abstract:

This paper presents a novel technique for authenticating physical documents based on random, naturally occurring imperfections in paper texture. We introduce a new method for measuring the three-dimensional surface of a page using only a commodity scanner and without modifying the document in any way. From this physical feature, we generate a concise fingerprint that uniquely identifies the document. Our technique is secure against counterfeiting and robust to harsh handling; it can be used even before any content is printed on a page. It has a wide range of applications, including detecting forged currency and tickets, authenticating passports, and halting counterfeit goods. Document identification could also be applied maliciously to de-anonymize printed surveys and to compromise the secrecy of paper ballots.

Viewed under a microscope, an ordinary piece of paper looks like this:

The microscope clearly shows individual wood fibers, laid down in a pattern that is unique to this piece of paper.

If you scan a piece of paper on an ordinary desktop scanner, it just looks white. But pick a small area of the paper, digitally enhance the contrast and expand the image, and you see something like this:

The light and dark areas you see are due to two factors: inherent color variation in the surface, and partial shadows cast by fibers in the paper surface. If you rotate the paper and scan again, the inherent color at each point will be the same, but the shadows will be different because the scanner's light source will strike the paper from a different angle. These differences allow us to map out the tiny hills and valleys on the surface of the paper.

Here is a visualization of surface shape from one of our experiments:

This part of the paper had the word "sum" printed on it. You can clearly see the raised areas where toner was applied to the paper to make the letters. Around the letters you can see the background texture of the paper.

Computing the surface texture is only one part of the job. From the texture, you want to compute a concise, secure "fingerprint" which can survive ordinary wear and tear on the paper, such as crumpling, scribbling or printing, and moisture. You also want to understand how secure the technology will be in various applications. Our full paper addresses these issues too. The bottom-line result is a sort of unique fingerprint for each piece of paper, which can be determined using an ordinary desktop scanner.

For more information, see the project website or our research paper.

Earlier this month I testified in Gusciora v. Corzine, the trial in which the plaintiffs argue that New Jersey's voting machines (Sequoia AVC Advantage) can't be trusted to count the votes, because they're so easily hacked to make them cheat.

I've previously written about the conclusions of my expert report: in 7 minutes you can replace the ROM and make the machine cheat in every future election, and there's no practical way for the State to detect cheating machines (in part because there's no voter-verified paper ballot).

The trial started on January 27, 2009 and I testified for four and a half days. I testified that the AVC Advantage can be hacked by replacing its ROM, or by replacing its Z80 processor chip, so that it steals votes undetectably. I testified that fraudulent firmware can also be installed into the audio-voting daughterboard by a virus carried through audio-ballot cartridges. I testified about many other things as well.

Finally, I testified about the accuracy of the Sequoia AVC Advantage. I believe that the most significant source of inaccuracy is its vulnerability to hacking. There's no practical means of testing whether the machine has been hacked, and certainly the State of New Jersey does not even attempt to test. If we could somehow know that the machine has not been hacked, then (as I testified) I believe the most significant _other_ inaccuracy of the AVC Advantage is that it does not give adequate feedback to voters and pollworkers about whether a vote has been recorded. This can lead to a voter's ballot not being counted at all; or a voter's ballot counting two or three times (without fraudulent intent). I believe that this error may be on the order of 1% or more, but I was not able to measure it in my study because it involves user-interface interaction with real people.

In the hypothetical case that the AVC Advantage has not been hacked, I believe this user-interface source of perhaps 1% inaccuracy would be very troubling, but (in my opinion) is not the main reason to disqualify it from use in elections. The AVC Advantage should be disqualified for the simple reason that it can be easily hacked to cheat, and there's no practical method that will be sure of catching this hack.

Security seals. When I examined the State's Sequoia AVC Advantage voting machines in July 2008, they had no security seals preventing ROM replacement. I demonstrated on video (which we played in Court in Jan/Feb 2009) that in 7 minutes I could pick the lock, unscrew some screws, replace the ROM with one that cheats, replace the screws, and lock the door.

In September 2008, after the State read my expert report, they installed four kinds of physical security seals on the AVC Advantage. These seals were present during the November 2008 election. On December 1, I sent to the Court (and to the State) a supplemental expert report (with video) showing how I could defeat all of these seals.

In November/December the State informed the Court that they were changing to four new seals. On December 30, 2008 the State Director of Elections, Mr. Robert Giles, demonstrated to me the installation of these seals onto the AVC Advantage voting machine and gave me samples. He installed quite a few seals (of these four different kinds, but some of them in multiple places) on the machine.

On January 27, 2009 I sent to the Court (and to the State) a supplemental expert report showing how I could defeat all those new seals. On February 5th, as part of my trial testimony I demonstrated for the Court the principles and methods by which each of those seals could be defeated.

On cross-examination, the State defendants invited me to demonstrate, on an actual Sequoia AVC Advantage voting machine in the courtroom, the removal of all the seals, replacement of the ROM, and replacement of all the seals leaving no evidence of tampering. I then did so, carefully and slowly; it took 47 minutes. As I testified, someone with more practice (and without a judge and 7 lawyers watching) would do it much faster.

Lawsuits! Everybody's filing lawsuits. Premier Election Systems (formerly Diebold) is suing SysTest, one of the EAC's testing authorities (or, more properly, former testing authorities, now that the EAC is planning to suspend their accreditation). There's also a lawsuit between the State of Ohio and Premier over whether or not Premier's voting systems satisfy Ohio's requirements. Likewise, ES&S is being sued by San Francisco, the State of California, and the state of Oregon. A Pennsylvania county won a judgment against Advanced Voting Systems, after AVS's systems were decertified (and AVS never even bothered showing up in court to defend themselves). And that's just scratching the surface.

What's the real problem here? Electronic voting systems were "certified", sold, deployed, and then turned out to have a variety of defects, ranging from "simple" bugs to a variety of significant security flaws. Needless to say, it takes time, effort, and money to build better voting machines, much less to push them through the certification process. And nobody really understands what the certification process even is anymore. In the bad old days, a "federally certified voting system" was tested by one of a handful of "independent testing authorities" (ITAs), accredited by the National Association of State Election Directors, against the government's "voluntary voting system guidelines" (the 2002 edition, for the most part). This original process demonstrably failed to yield well-engineered, secure, or even particularly usable voting systems. So how have things improved?

Now, NASED has been pushed aside by the EAC, and the process has been glacial. So far as I can tell, no electronic voting system used in the November 2008 election had code that was in any way different from what was used in the November 2006 election.

Regardless of whether we jettison the DREs and move to optical scan, plenty of places will continue using DREs. And there will be demand for new features in both DREs and optical scanners. And bug fixes. The certification pipeline must be vigilant, yet it needs to get rolling again. In a hurry, but with great caution and care. (Doesn't sound very feasible, I know.)

Okay, then let's coerce vendors to build better products! Require the latest standards! While brilliant, in theory, such a process is doomed to continue the practical failures (and lawsuits) that we're seeing today. The present standards are voluminous. They are also quite vague where it matters because there is no way to write a standard that's both general-enough to apply to every possible voting system and specific-enough to adequately require good development practices. The present standards err, arguably correctly, on the vague side, which then requires the testing authorities to do some interpretation. Doing that properly requires competent testing labs and competent developers, working together.

Unfortunately, they don't work together at all (never mind issues of competence). The current business model is that developers toil away, perhaps talking to their customers, but not interacting with the certification process at all until they're "done," after which they pitch the system over the wall, write a big check, and cross their fingers that everything goes smoothly. If the testing authority shoots it down, they need to sort out why and try again. Meanwhile, you've got the Great States of California and Ohio doing their own studies, with testers like yours truly who don't particularly care what the standards say and are instead focused on whether the machines are robust in the face of a reasonable threat model. Were the problems we found outside of the standards' requirements? We don't care because they're serious problems! Unfortunately, from the vendor's perspective, they now need to address everything we found, and they have no idea whether or not they'll get it right before they may or may not face another team of crack security ninjas.

What I want to see is a grand bargain. The voting system vendors open up their development processes to external scrutiny and regulation. In return, they get feedback from the certifying authorities that their designs are sound before they begin prototyping. Then they get feedback that their prototypes are sound before they flesh out all the details. This necessarily entails the vendors letting the analysts in on their bugs lists (one of the California Secretary of State's recommendations to the EAC), further increasing transparency. Trusted auditors could even look at the long-term development roadmap and make judgments that incremental changes, available in the short term, are part of a coherent long-term plan to engineer a better system. Alternately, the auditors could declare the future plans to be a shambles and refuse to endorse even incremental improvements. Invasive auditing would give election authorities the ability to see each vendor's future, and thus reach informed decisions about whether to support incremental updates or to dump a vendor entirely.

Where can we look for a a role model for this process? I initially thought I'd write something here about how the military procures weapon systems, but there are too many counter-examples where that process has gone wrong. Instead, let's look at how houses are built (or, at least, how they should be built). You don't just go out, buy the lumber and nails, hire people off the street, and get banging. Oh no! You start with blueprints. Those are checked off by the city zoning authorities, the neighborhood beauty and integrity committee, and so forth. Then you start getting permits. Demolition permits. Building permits. Electrical permits. At each stage of construction, city inspectors, the prospective owners, and even the holders of the construction loan, may want to come out and check it out. If, for example, there's an electrical problem, it's an order of magnitude easier to address it before you put up the interior walls.

For voting systems, then, who should do the scrutiny? Who should scrutinize the scrutineers? Where's the money going to come from to pay for all this scrutiny? It's unclear that any of the testing authorities have the deep skills necessary to do the job. It's similarly unclear that you can continually recruit "dream teams" of the best security ninjas. Nonetheless, this is absolutely the right way to go. There are only a handful of major vendors in the e-voting space, so recruiting good talent to audit them, on a recurring part-time basis, is eminently feasible. Meta-scrutiny comes from public disclosure of the audit reports. To save some money, there are economies of scale to be gained from doing this at the Federal level, although it only takes a few large states to band together to achieve similar economies of scale.

At the end of the day, we want our voting systems to be the best they can be, regardless of what technology they happen to be using. I will argue that this ultimately means that we need vendors working more closely with auditors, whether we're considering primitive optical scanners or sophisticated end-to-end cryptographic voting schemes. By pushing the adversarial review process deeper into the development pipeline, and increasing our transparency into how the development is proceeding, we can ensure that future products will be genuine improvements over present ones, and hopefully avoid all these messy lawsuits.

[Sidebar: what about protecting the vendors' intellectual property? As I've argued before, this is what copyrights and patents are about. I offer no objection to vendors owning copyright on their code. Patents are a bit trickier. If the auditors decide that some particular feature should be mandatory and one vendor patents it, then every other vendor could potentially infringe the patent. This problem conceivably happens today, even without the presence of invasive auditors. Short of forbidding voting machine patents as a prerequisite for voting system certification, this issue will never go away entirely. The main thing that I want to do away with, in their entirety, are trade secrets. If you want to sell a voting machine, then you should completely waive any trade secret protection, ultimately yielding a radical improvement in election transparency.]

California Secretary of State Debra Bowen has sent a letter to Chair Gineen Beach of the US Election Assistance Commission (EAC) outlining three proposals that she thinks will markedly improve the integrity of voting systems in the country.

I've put a copy of Bowen's letter here (87kB PDF).

Bowen's three proposals are:

• Vulnerability Reporting -- The EAC should require that vendors disclose vulnerabilities, flaws, problems, etc. to the EAC as the system certification authority and to all the state election directors that use the affected equipment.
• Uniform Incident Reporting -- The EAC should create and adopt procedures that jurisdictions can follow to collect and report data about incidents they experience with their voting systems.
• Voting System Performance Measurement -- As part of the Election Day Survey, the EAC should systematically collect data from election officials about how voting systems perform during general elections.

In my opinion, each of these would be a welcome move for the EAC.

These proposals would put into place a number of essential missing elements of administering computerized elections equipment. First, for the users of these systems, election officials, it can be extremely frustrating and debilitating if they suspect that some voting system flaw is responsible for problems they're experiencing. Often, when errors arise, contingency planning requires detailed knowledge about specific details of a voting system flaw. Without knowing as much as possible about the problem they're facing, election officials can exacerbate the problem. At best, not knowing about a potential flaw can do what Bowen describes: doom the election official, and others with the same equipment, to repeatedly encounter the flaw in subsequent elections. Of course, vendors are the most likely to have useful information on a given flaw, and they should be required to report this information to both the EAC and election officials.

Often the most information we have about voting system incidents come from reports from local journalists. These reporters don't tend to cover high technology too often; their reports are often incomplete and in many cases simply and obviously incorrect. Having a standardized set of elements that an election official can collect and report about voting system incidents will help to ensure that the data comes directly from those experiencing a given problem. The EAC should design such procedures and then a system for collecting and reporting these issues to other election officials and the public.

Finally, many of us were disappointed to learn that the 2008 Election Day survey would not include questions about voting system performance. Election Day is a unique and hard-to-replicate event where very little systematic data is collected about voting machine performance. The OurVoteLive and MyVote1 efforts go a long way towards actionable, qualitative data that can help to increase enfranchisement. However, self-reported data from the operators of the machinery of our democracy would be a gold mine in terms of identifying and examining trends in how this machinery performs, both good and bad.

I know a number of people, including Susannah Goodman at Common Cause as well as John Gideon and Ellen Theisen of VotersUnite!, who have been championing one or another of these proposals in their advocacy. The fact that Debra Bowen has penned this letter is a testament to the reason behind their efforts.

The recount of the 2008 Minnesota Senate race gives us an opportunity to evaluate the accuracy of precinct-count optical-scan voting. Though there have been contentious disputes over which absentee ballot envelopes to open, the core technology for scanning ballots has proved to be extremely accurate.

The votes were counted by machine (except for part of one county that counts votes by hand), then every single ballot was examined by hand in the recount.

The "net" accuracy of optical-scan voting was 99.99% (see below).
The "gross" accuracy was 99.91% (see below).
The rate of ambiguous ballots was low, 99.99% unambiguous (see below).

My analysis is based on the official spreadsheet from the Minnesota Secretary of State. I commend the Secretary of State for his commitment to transparency in the form of making the data available in such an easy-to-analyze format. The vast majority of the counties use the ES&S M100 precinct-count optical-scanners; a few use other in-precinct scanners.

I exclude from this analysis all disputes over which absentee ballots to open. Approximately 10% of the ballots included in this analysis are optically scanned absentee ballots that were not subject to dispute over eligibility.

There were 2,423,851 votes counted for Coleman and Franken. The "net" error rate is the net change in the vote margin from the machine-scan to the hand recount (not including change related to qualification of absentee ballot envelopes). This was 264 votes, for an accuracy of 99.99% (error, one part in ten thousand).

The "gross" error rate is the total number of individual ballots either added to one candidate, or subtracted from one candidate, by the recount. A ballot that was changed from one candidate to the other will count twice, but such ballots are rare. In the precinct-by-precinct data, the vast majority of precincts have no change; many precincts have exactly one vote added to one candidate; few precincts have votes subtracted, or more than one vote added, or both.

The recount added a total of 1,528 votes to the candidates, and subtracted a total of 642 votes, for a gross change of 2170 (again, not including absentee ballot qualification). Thus, the "gross" error rate is about 1 in 1000, or a gross accuracy of 99.91%.

Ambiguous ballots: During the recount, the Coleman and Franken campaigns initially challenged a total of 6,655 ballot-interpretation decisions made by the human recounters. The State Canvassing Board asked the campaigns to voluntarily withdraw all but their most serious challenges, and in the end approximately 1,325 challenges remained. That is, approximately 5 ballots in 10,000 were ambiguous enough that one side or the other felt like arguing about it. The State Canvassing Board, in the end, classified all but 248 of these ballots as votes for one candidate or another. That is, approximately 1 ballot in 10,000 was ambiguous enough that the bipartisan recount board could not determine an intent to vote. (This analysis is based on the assumption that if the voter made an ambiguous mark, then this ballot was likely to be challenged either by one campaign or the other.)

Caveat: As with all voting systems, including optical-scan, DREs, and plain old paper ballots, there is also a source of error from voters incorrectly translating their intent into the marked ballot. Such error is likely to be greater than 0.1%, but the analysis I have done here does not measure this error.

Hand counting: Saint Louis County, which uses a mix of optical-scan and hand-counting, had a higher error rate: net accuracy 99.95%, gross accuracy 99.81%.

Yes, we know that there's no such thing as a perfect voting system, but the Estonians are doing their best to get as far away from perfection as possible. According to the latest news reports, Estonia is working up a system to vote from mobile phones. This follows on their earlier web-based Internet voting. What on earth are they thinking?

Let's review some basics. The Estonian Internet voting scheme builds on the Estonian national ID card, which is a smartcard. You get the appropriate PCMCIA adapter and you can stick it into your laptop. Then, through some kind of browser plug-in, it can authenticate you to the voting server. No card, no voter impersonation. The Estonian system "avoids" the problem of voter bribery / coercion by allowing the voter to cast as many votes as they want, but only the last one actually counts. As I understand it, a voter may also arrive, on election day, at some sort of official polling place and substitute a paper ballot for their prior electronic ballot.

The threats to this were and are obvious. What if some kind of malware/virus/worm contraption infects your web browser and/or host operating system, waits for you to connect to the election server, and then quietly substitutes its own choices for yours? You would never know that the attack occurred and thus would never think to do anything about it. High tech. Very effective. And, of course, somebody can still watch over your shoulder while you vote. At that point, they just need to keep you from voting again. They could accomplish this by simply having you vote at the last minute, under supervision, or they could "borrow" your ID card until it's too late to vote again. Low tech. Still effective.

But wait, there's more! The central database must necessarily have your vote recorded alongside your name in order to allow subsequent votes to invalidate earlier votes. That means they've almost certainly got the technical means to deanonymize your vote. Do you trust your government to have a database that says exactly for whom you voted? Even if the vote contents are somehow encrypted, the government has all the necessary key material to decrypt it. (And, an aforementioned compromised host platform could be leaking this data, regardless.)

Okay, what about voting by cellular telephone? A modern cell phone is really no different from a modern web browser. An iPhone is running more-or-less the same OS X and Safari browser that's featured on Apple's Mac products. Even non-smart-phones tend to have an environment that's powerful and general-purpose. There's every reason to believe that these platforms are every bit as vulnerable to software attacks as we see with Windows systems. Just because hackers aren't necessarily targeting these systems doesn't mean they couldn't. Ultimately, that means that the vulnerabilities of the phone system are exactly the same as the web system. No better. No worse.

Of course, crypto can be done in a much more sophisticated fashion. One Internet voting system, Helios, is quite sophisticated in this fashion, doing end-to-end crypto in JavaScript in your browser. With its auditability, Helios gives you the chance to challenge the entire client/server process to prove that it maintained your vote's integrity. There's nothing, however, in Helios to prevent an evil browser from leaking how you voted, thus compromising your anonymity. An evil election server could possibly be prevented from compromising your anonymity, depending on how the decryption keys are managed, but all the above privacy concerns still apply.

Yes, of course, Internet and cell-phone voting have lots of appeal. Vote from anywhere! At any time! If Estonia did more sophisticated cryptography, they could at least have a hope at getting some integrity guarantees (which they appear to be lacking, at present). Estonians have absolutely no privacy guarantees and thus insufficient protection from bribery and coercion. And we haven't even scratched the surface of denial-of-service attacks. In 2007, Estonia suffered a large, coordinated denial-or-service attack, allegedly at the hands of Russian attackers. I'm reasonably confident that they're every bit as vulnerable to such attacks today, and cell-phone voting would be no less difficult for resourceful attackers to disrupt.

In short, if you care about voter privacy, to defeat bribery and coercion, then you want voters to vote in a traditional polling place. If you care about denial of service, then you want these polling places to be operable even if the power goes out. If you don't care about any of that, then consider the alternative. Publish in the newspaper a list of every voter and how they voted, for all the world to see, and give those voters a week to submit any corrections they might desire. If you were absolutely trying to maximize election integrity, nothing would beat it. Of course, if you feel that publishing such data in the newspaper could cause people to be too scared to vote their true preferences, then maybe you should pay more attention to voter privacy.

(More on this from Eric Rescorla's Educated Guesswork.)