This letter was sent to the EAC on October 13 2009 by Verified Voting Foundation Board of Advisors member Joseph Lorenzo Hall and Aaron Burstein.
We write to you on behalf of those individuals listed below from the California Secretary of State’s Top-To-Bottom Review (TTBR) in 2007. The TTBR was an unprecedented, in-depth evaluation of California’s voting systems, which allowed investigators to gain a better understanding of their vulnerabilities. As you know, the EAC recently certified Premier’s Assure 1.2 voting system as conforming to the 2002 Voting System Standards (VSS). This system was tested by iBeta Laboratories (iBeta), one of the accredited Voting System Test Labs (VSTLs). According to the posted test plan—the roadmap for a VSTL’s evaluation of a voting system during certification testing—for Premier Assure 1.2, iBeta interpreted the TTBR studies of the Premier system’s predecessor to have “concluded that the vulnerabilities within the system depend almost entirely on the effectiveness of the election procedures.” On the basis of this interpretation, iBeta developed a test plan that called for “no additional testing” of the Premier system’s security properties. The EAC approved this plan. Taken together, iBeta’s misunderstanding of the significance of the TTBR findings and the EAC’s approval of a test plan that was designed around this misunderstanding, represent a missed opportunity to use the testing and certification process to improve voting system integrity and reliability.
iBeta misunderstands the results of the TTBR. The TTBR concluded that the number, extent, and severity of these vulnerabilities were so substantial that the technological security mechanisms were completely inadequate to protect the integrity and security of both the systems and of the election.1 This directly contradicts the statement that “the vulnerabilities within the system depend almost entirely upon the effectiveness of the election procedures.” The vulnerabilities are present, regardless of the election procedures. The team concluded that these flaws were so severe as to render the system’s technological security measures essentially without value; these vulnerabilities could only be mitigated by the strictest of procedures. The California Secretary of State’s response to the TTBR was to decertify two systems until their respective vendors, one of which was Diebold,2 fixed many problems with their security mechanisms. Even now, these machines are subject to strict new procedural rules designed to mitigate the vulnerabilities which remain. Such drastic measures were necessary precisely because the underlying vulnerabilities were not detected and analyzed during conformance testing.
iBeta’s light treatment of the TTBR results, therefore, should not have received the EAC’s approval. If Premier sought only administrative approval of small changes to a legacy system, the approved test plan would be less of a cause for concern. iBeta’s testing of the Premier system, however, was conducted under the new EAC certification program that serves as the foundation for testing under the 2005 VVSG and subsequent standards. Conformance testing under the EAC framework is one of the principal ways to detect and cure common classes of basic vulnerabilities in voting systems. The EAC should use its VSTL oversight to require test labs to conduct thorough evaluations of voting system vulnerabilities during conformance testing, so that vendors will fix vulnerabilities before systems are certified and sold.3
When the EAC allows a VSTL to disregard important sources of information about a voting system’s vulnerabilities, it weakens the testing and certification process’s ability to detect and fix vulnerabilities at a relatively early stage.
We recommend that VSTLs should be required to examine each flaw and/or vulnerability described in these reports for specific systems and verify that each flaw is corrected or that specific measures are documented and recommended by the manufacturer for the voting system’s maintenance and use. Many of the vulnerabilities can be corrected by relatively typical types of software modifications, the type that are routinely corrected in software that has a much shorter update schedule. For example, common buffer overflow mistakes can be corrected by range-checking variables when they are manipulated.
Of course, addressing some of the more complex vulnerabilities discovered in these studies would require significant changes to a given system’s architecture. For example, vulnerabilities in how software is installed on some systems would require significant redesign in order to add authentication to the software installation functionality. In these cases, security testing should extend to the manufacturer’s recommended policies and procedures. These must provide a recommended default level of physical security and careful election media handling, for example, so that a jurisdiction that follows the recommendations will mitigate the risks posed by known vulnerabilities.
Joseph Lorenzo Hall
Matt Bishop, Principal Investigator, Professor, Department of Computer Science; University of California, Davis
David Wagner, Principal Investigator, Professor, Computer Science Division; University of California, Berkeley
Matt Blaze, Associate Professor, Computer & Information Science; University of Pennsylvania
J. Alex Halderman, Assistant Professor, Department of Electrical Engineering and Computer Science; University of Michigan
Candice Hoke, Associate Professor of Law, Cleveland-Marshall College of Law; Cleveland State University
Richard Kemmerer, Professor, Department of Computer Science; University of California, Santa Barbara
Deirdre Mulligan, Assistant Professor, School of Information; University of California, Berkeley
Elliot Proebstel, Department of Computer Science; University of California, Davis
Eric Rescorla, Principal, RTFM, Inc.
Hovav Shacham, Assistant Professor, Department of Computer Science and Engineering; University of California, San Diego
Giovanni Vigna, Professor, Department of Computer Science; University of California, Santa Barbara
Dan Wallach, Associate Professor, Department of Computer Science; Rice University
CC: Senator Charles Schumer, Chairman, U.S. Senate Rules and Administration Committee
Senator Robert Bennett, Ranking Member, U.S. Senate Rules and Administration Committee
Congressman Robert Brady, Chairman, U.S. House Committee on House Administration
Congressman Dan Lungren, Ranking Member, U.S. House Committee on House Administration
Commissioner Gineen Bresso Beach, Chair, U.S. Election Assistance Commission
Commissioner Gracia Hillman, Vice-Chair, U.S. Election Assistance Commission
Commissioner Donetta Davidson, Commissioner, U.S. Election Assistance Commission
Executive Director Thomas R. Wilkey, U.S. Election Assistance Commission
Secretary of State Trey Grayson, President, National Association of Secretaries of State
Secretary of State Debra Bowen, California Secretary of State
Secretary of State Jennifer Brunner, Ohio Secretary of State
Peggy Nighswonger, President, National Association of State Election Directors
Spencer Overton, Principal Dep. Asst. Attorney General, Office of Legal Policy, U.S. Department of Justice
Jon Crickenberger, Voting System Testing Program Manager, NIST/NVLAP
Carolyn Coggins, QA Director—Voting, iBeta Quality Assurance
Frank Padilla, Program Manager for Voting System Test Programs, Wyle Laboratories
Brian Phillips, President and CEO, SysTest Laboratories
Kelly A. Rohacek, ITL Practice Director, CIBER, Inc.
- Other studies, such as the EVEREST study that the Ohio Secretary of State sponsored, reached similar conclusions. ↩
- At the time of the TTBR, Diebold, Inc. had yet to change the name of its election systems subsidiary from Diebold Election Systems to Premier Election Solutions. ↩
- We recognize that it is unlikely that any evaluation process will find all vulnerabilities in a system. Finding and eliminating some vulnerabilities, however, can reduce security risks. Accordingly, it is imperative that the testing and certification process uses directly relevant, readily accessible information to find vulnerabilities. ↩
- Affiliations are provided for identification purposes only. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors. ↩