The Case of the Diebold FTP Site

Part of the Voting and Elections web pages
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science

Copyright © 2003. This work may be transmitted or stored in electronic form on any computer attached to the Internet or World Wide Web so long as this notice is included in the copy. Individuals may make single copies for their own use. All other rights are reserved.

Contents

  1. Background
  2. What We Already Knew
  3. What Can We Learn from the Diebold FTP Site
  4. A Warning
  5. Some Disturbing Answers
  6. Rebuttals
  7. Retractions and Reactions
  8. Conflicts of Interest
  9. The SAIC (and other) Risk Assessments
  10. Consequences

For a summary of this story, as of Aug. 6, 2003, see . The Diebold AccuVote TS Should be Decertified.


1. Background

On Feb. 4, 2003, employees of Diebold Election Systems admitted that they had been using an insecure FTP server to exchange and update some part of Diebold's software. Bev Harris had discovered the server by doing a Google search, and she wrote it up in the on-line journal Scoop. [See Scoop, Feb 5, 2003 and Scoop, Feb 10, 2003] This FTP server was taken offline on Jan 29, and it is alleged to have contained files with names like "rob-georgia.zip", large parts of GEMS (the Global Election Management System), and unknown other software.

Not surprisingly, this disclosure fueled considerable speculation about some vast conspiracy undermining democracy. On April 23, 2003, Britain J. Williams, chair of the NASED Voting Systems Board Technical Committee, wrote a rebuttal to the charges raised by Bev Harris. [See the PDF or HTML versions of this letter] This letter is as a defense of the procedures used by the State of Georgia and the FEC/NASED certification process on which Georgia certification rests. [see the FEC and NASED websites] It shows, among other things, that Georgia has stronger defenses, in some respects, than my own state of Iowa.

The Williams letter assures voters that whatever was found on Diebold's FTP site is irrelevant to the conduct of elections in Georgia because the only path from that site into a voting machine is through the FEC/NASED process and Georgia's certification tests. The letter also contains a bit of denial, for example, a statement that "the contents, or even existence, of the 'rob georgia' folder has not been established."

On July 8, 2003, Bev Harris posted the results of a preliminary examinaton of the files lifted from the Diebold FTP server. [See Scoop, July 8, 2003, Inside a U.S Election Vote Counting Program or Bev Harris's blackboxvoting.com web site; available in revised form from Bev Harris's blackboxvoting.org web site] The accompanying editorial, by the operators of the Scoop web site, included the the Internet address of a server from which this material could be downloaded and advice on how to crack the passwords. [See Scoop, July 8, 2003, Bigger than Watergate] The editorial urges people to make copies of the Diebold files and discuss what they find, and Harris created an on-line forum for this discussion of what was found. [See http://www.blackboxvoting.org/cgi-bin/dcforum/dcboard.cgi]

On July 9, Bev Harris posted specific rebuttals to the defense offered by Britain Williams in his April 23 letter. [See Scoop, July 10, 2003] This posting includes an extended transcript of an interview with Rob Behler, the 'rob' to whom the 'rob georgia' folder had been addressed. A more complete transcript of this interview is available. [See What really happened in Georgia? reposted at [IP] Interview with Georgia Diebold Election Machine installer] This interview makes it clear that the 'rob georgia' folder had nothing to do with an attempt to rob the state of Georgia, but it also makes it clear that the Georgia certification tests were, in reality, somewhat weaker than Williams had claimed, and that patches were indeed downloaded for these tests directly from the Diebold FTP site without passing through the FEC/NASED certification procedures, on the strength of a phone call to the source code auditor to determine that he wouldn't have considered the code in question to be subject to audit.

2. What We Already Knew

Prior to the disclosures and debate described above, we knew that Diebold Corporation had purchased Global Election Systems in 2001, which had purchased I-Mark Systems back in 1997; I-Mark was the original developer of the Electronic Ballot Station. Global had previously acquired the AccuVote mark-sense system, so naturally, they coined the name AccuTouch for the I-Mark Electronic Ballot Station. This system first passed through the FEC/NASED certification process on 9-10-96, in a kiosk configuration that incorporated CRT monitor. This original hardware was replaced by a portable flat-panel version that was certified on 12-5-97. That was the first version of the hardware I saw, when it came before the Iowa Board of Examiners for Voting Machines and Electronic Voting Systems on Nov 6. 1997. [The minutes of this meeting indicate that Bob Urosevich and Barry Herron represented Global Election Systems at that meeting.] The sales material from Governmental Business Systems provides a good summary of the overall use of the Global System. [See http://www.gbsvote.com/wi/accuvotets.htm]

ISO 9000

Diebold has emphasized, in some of their presentations about this system, that it was developed under an ISO 9000 compliant development process. While it is worth noting that ISO 9000 does not guarantee quality in the product, it does demand use of a well-documented quality assurance system. The important thing is that the system is well documented and that management structures are in place to assure that it is used. ISO 9000 does not guarantee effective quality assurance, only that failures should be tracable to problems that should be evident in the documentation.

Compatability and Modes of Use

The Electronic Ballot Station, in both its kiosk form and its portable flat-panel form, is built from IBM PC compatable parts. In the now widely used flat-panel form, it consists of a wedge-shaped enclosure holding a PC motherboard, flat-panel display and various anciliaries including a smartcard reader, disk, network interface, and a compact internal uninterruptable power supply. Aside from packaging, it is a full featured PC, and when security seals are removed from the various ports on the side, it can be used as one by adding appropriate devices.

The same hardware that runs as an Electronic Ballot Station can also run other software, specifically, the Electronic Poll Book software. There are two practical ways to use the AccuTouch (or AccuVote Touchscreen System) in a polling place: In one, the polling place handles voter sign-in conventionally and has a stock of several hundred pre-recorded smartcards, each of which can be used to enable one voter to cast one ballot on an Electronic Ballot Station. In the other, each polling place has an Electronic Poll Book at the registration table that is used to record, on demand, the authorization card for each voter. Global originally suggested using the same hardware to run the Elecronic Poll Book as they use for the Electronic Ballot Station, but I believe it is as easy to use a commodity laptop with a commodity external smart-card interface for this function.

There is a third alternative to the above two. Originally, I-Mark Systems had intended what they called the "vote anywhere model". In this model, the voter registration cards sent to each voter would be smartcards, allowing a voter to walk up to any voting machine in the county and cast a vote using only his or her voter registration card. In the extreme discussed in early I-Mark sales literature, unattended kiosk-format Electronic Ballot Stations were to be available in public places such as libraries and shopping malls. I have not heard of any jurisdiction issuing smartcards to voters.

Use of Third-Party Commercial Off-the-Shelf Components

From the start, it was clear that the AccuTouch Electronic Ballot Station used a version of Windows and various Microsoft Office components. At the examination in Iowa on Nov 6, 1997, when asked about this, one of the representatives of Global stated, firmly, that the version of Windows they used was purely unmodified commercial off-the-shelf software, and therefore not subject to a source code audit under the FEC/NASED certification rules. [This must have been either Bob Urosevich or Barry Herron, the two company representatives who were present at that meeting.] I discussed potential problems with this in my testimony before the House Science Committee on May 22, 2001. [See Problems with Voting System Standards]

The FEC/NASED Voting System Standards require that all software used in voting systems be passed through a source-code audit, but there is an exemption, in both the 1990 and 2002 editions of this standard, for unmodified third-party 'COTS' software, that is, commercial off-the-shelf software produced by a third party that has not been modified for use in the voting context. Use of Microsoft Windows and Microsoft Office clearly qualifies for this exemption.

The standards do require, however, that all third-party components be documented! For hardware components, this typically means vendor, model, model number and revision number, and the same requirement should be applied to software. That is, the vendor should not be allowed to state merely that a product is approved for use on Microsoft Office, but rather, the vendor must state the version on which it has been certified, and a change of version should require recertification. There is an excellent examples of a revision to Windows that actually destroyed voter privacy on an early version of the Fidlar and Chambers direct recording electronic voting machine. I discussed this example in my testimony before the House Science Committee cited above.

Unfortunately, the configuration documentation required by the FEC/NASED certification process is not public record, and in fact, all of the detailed technical documentation given by the vendor to the independent testing authority and the report of that independent testing authority is covered by nondisclosure agreements between the testers and the vendor. Only the fact of certification is public. Many states require configuration disclosure, however, and in many cases, these disclosures are, to varying extents, public. The states, however, have been sloppy and inconsistant about this! In Iowa, for example, it took us several years before we understood how partial the descriptions we were being given were; we have only recently begun to crack down on sloppy configuration disclosures, and to make a point of asking for model and revision numbers!

There is some debate about the word "unmodified". The narrowest interpretation would consider a third-party commercial off-the-shelf component to have been modified only if the source code for that component was changed. At the other extreme, any change to the out-of-the-box configuration of the component would count as modification. I suspect that extreme is wrong, but I also believe that the changes to the out-of-the-box configurations should be documented and subject to audit. If they claim to be using Microsoft Office XP with Service Pack 3, but with Word, Outlook, PowerPoint, FrontPage and SharePoint deleted, then this should be clearly stated and the audit should verify this configuration change.

Self Modifying Code

The FEC/NASED Voting System Standards explicitly forbid self-modifying code. There are several reasons for this prohibition, but the most important is the following: It is difficult to debug, prove the correctness of or audit software that is dynamically created at run-time. It is far easier to audit code that exists, in total, at the time of the audit.

There are disagreements about the nature of self-modifying code! Some would define it narrowly in terms of machine instructions that are overwritten by other instructions at run-time, while others define it broadly to include any dynamic linkage or interpretive execution, since all of these can be used to change the function of code after the fact.

Microsoft Windows makes extensive use of dynamically linked libraries and Microsoft Applications generally include interpreters for Visual Basic. In addition, it is natural to use mechanisms that border on interpretive for such things as formatting, as with HTML, or report generation, as with the ancient RPG language. The same considerations could lead to use of such mechanisms for ballot layout and canvassing, and in the past, it has been common for systems that border on being interpretive to evolve into fully developed general purpose interpreters; this happened with RPG. Depending on the interpretation of the restrictions on self-modification in the FEC/NASED Voting System Standards, use of these mechanisms could be problematic, and even if they are considered acceptable under the standards, their abuse introduces the possibility of security loopholes!

Communication and Security

AccuTouch Electronic Ballot Stations can be run in isolation, but the 1990 FEC/NASED Voting System Standards required that the totals for the precinct be automatically consolidated at the precinct, and this requires some communication between the machines at the precinct when more than one direct recording electronic voting machines is used. Some voting system vendors have opted to use local area networks for this, notably Fidlar and Chambers (which became Fidlar Doubleday), while others have opted to use hand-carried cartridges of various sorts; Diebold uses PCMCIA cards, ES&S uses special and somewhat chunky custom built bricks).

Once the data for the precinct is consolidated, it may be printed at the precinct, as is required in many jurisdictions, and it may be transmitted by any of several communications options to the central offices, where precinct reports may be tabulated and printed using GEMS. Among these options are the option of hand carrying the precinct results in a PCMCIA card and the option of transmitting the results by modem.

Programming the AccuTouch machine for a particular election is also done using PCMCIA cards written on the GEMS system at the central offices and then loaded into the voting machine, and the permanent record of the election that is stored for recount purposes is stored on a PCMCIA card (with a duplicate record stored on the internal hard drive of the voting machine in case of failure). The 2002 Examination Report for the state of Washington contains a good summary of the use of PCMCIA cards on this system. [See Sam Reed report of Sept 6, 2002]

The security of all of these network links, including those involving hand carried data, is critical! It is noteworthy that PCMCIA cards are about the size of playing cards and we know that sleight of hand trickery with playing cards is a highly developed art, so cryptographic security of the data on these cards is just as essential as it is for data transmitted over a public network.

In additional discussion at the first Iowa examination of the AccuTouch system on Nov 6, 1997, it came out that neither the technical staff nor salespeople at Global Election Systems understood cryptographic security. They were happy to assert that they used the Federally approved Data Encryption Standard, but nobody seemed to understand key management, in fact, the lead programmer to whom my question was forwarded, by cell-phone, found the phrase key management to be unfamiliar and he needed explanation. On continued questioning, it became apparent that there was only one key used, company wide, for all of their voting products. The implication was that this key was hard-coded into their source code!

The minutes of the meeting reflect this discussion but do not mention the cellphone conversation:

Dr. Jones also expressed concern about data encryption standards used to guarantee the integrity of the data on the machine. DES requires the use of electronic keys to lock and unlock all critical data. Currently all machines use the same key. Dr. Jones stated that this is a security problem. However, the use of a single key for all machines is not a condition that would disqualify the system under Iowa law.

The Iowa Secretary of State's office routinely forwards the minutes of these meetings to the vendor in question, so they did have both written and verbal notice of this serious security flaw; in addition, I wrote several paragraphs on this topic to the Elections Division of the Secretary of State's office on December 23, 1997:

[This] raises another issue that reflects a weakness in both the FEC standards and Iowa law. This weakness has been clearly present in all of the electronic reporting systems we have examined this year! The Wyle report takes it for granted that the use of DES encryption plus CRC error checking provides a sufficient guarantee of accuracy and integrity.

This is not true! First, as the Global representative I talked to informed me, the I-Mark system uses only a single DES key for all voting machines they manufacture. This is comparable to the situation you would expect if all ATM cards issued by some bank had the same PIN!

Unfortunately, there is no record of whether the Elections Division did or did not forward a copy of this note to the vendor.

I have frequently used this problem as an example of the weakness of the voting system standards; for example, I used it in my testimony before the House Science Committee in 2001. [See Problems with Voting System Standards]

I had hoped that this problem has long since been solved! At the examination, I explained to those present that the best practice was to dynamically create encryption keys at the time machines were configured for a particular precinct, so that only those machines were able to report results that would be interpreted as coming from that precinct. I also noted that it was not as important to encrypt the data as it was to use cryptographically secure signatures on the data. The big issue is the authenticity of the data reported from the precinct, not the secrecy, and in fact, in many jurisdictions, precinct totals are printed and posted in public prior to transmission as a measure to ensure that the canvassing process that computes overall vote totals can be audited.

3. What Can We Learn from the Diebold FTP Site

First, given what we already know about Diebold's products, it is no surprise to find Microsoft Access at the heart of their system. Questions about the appropriateness of using Microsoft products, in general, or about the appropriateness of using Microsoft Office components in an application that is critical to national security are very appropriate here, but nothing revealed by the Diebold FTP site is likely to change the answers to these questions. It was clear years ago that use of Access, Office and Windows is inappropriate in critical or high-security applications. [See Microsoft Access, when to use it and when not to use it or Microsoft Access -- Is it the right database for you?]

What we can learn from the Diebold FTP site are the answers to some very specific questions; had software from another vendor become available for an outside audit, I would likely have asked very similar questions, so this list should not be taken as implying any particular prejudice against Diebold's products:

  1. What third-party commercial off-the-shelf components are actually present in Diebold's software? We know that the contents of the FTP site are not, officially, the versions used in the certified versions of the software, but if we find evidence in these files that some third-party software was included in one or more versions of their system, we have strong reason to ask if that sofware was included in the configuration documents required for FEC/NASED certification and also required by several of the states for state certification.

    If comparison of what is found from the Diebold FTP site does not match prior disclosures under the FEC/NASED process or to the states, then we must ask:

  2. What changes, if any, were made to commercial off-the-shelf components? Were they installed out-of-the-box, or were the installations customized in any recognizable way? If the installation was customized, is there any evidence that the extent of customization was documented in the various configuration documents required by the FEC/NASED process or the states?

  3. Was any third-party software included in the system that was not commercial off-the-shelf software? If so, was the source code for this software included in the FEC/NASED certification process?

    If such software was included and the source code was not disclosed, there is a problem! Only commercial off-the-shelf software is exempt from the FEC/NASED source code review process. All other third-party software must be reviewed, including open-source freeware,

    Again, as above, failures to disclose non-commercial components could be either evidence of fraud or evidence of quality-control failures (an ISO 9000 issue).

  4. What uses of dynamic linkage are made by Diebold's voting system? are these necessary? Are there adequate protections to prevent dynamic linkage to code that has not itself been certified, or is it possible to cause linkage to code added to the machine later, for example, by a crook?

    There are companion questions to this: What uses of interpreters are made? Are they necessary? For each, are the protections adequate to prevent interpretation of code that has not itself been certified, or is it possible to cause interpretation of code added to the machine later, for example, by a crook?

  5. Do the current versions of the Diebold system use appropriate encryption methods and key management to guard the integrity of all data transmitted over external communications links, including hand-carried PCMCIA media? Whether or not they have replaced DES with a stronger encryption system, they should not be claiming that their encryption mechanisms are strong unless they can guarantee that their encryption keys have not been exposed through their FTP site! Ideally, new and randomized encryption keys should be generated by GEMS as the PCMCIA cartridges are created for each precinct.

4. A Warning

Note that the answers to many of these questions requires that someone who has access to the paperwork from the FEC/NASED process either see the material from the Diebold web site or see a report on what is found in the Diebold web site by others. Since access to the FEC/NASED certification documents is frequently covered by nondisclosure agreements, direct comparison with these documents may be difficult.

On the other hand, if someone who has access to these documents sees that examination of the Diebold web site has revealed something that ought to have been noted in these documents and was not, then I suspect that a public statement of this fact would not violate a nondisclosure agreement. Furthermore, it would seem to me that there is an overwhelming public interest in the disclosure of any apparent omission or inaccuracy found in the documentation submitted by any voting system vendor to the FEC/NASED process.

Whatever the answers to the above questions, any examination of the data extracted from the Diebold FTP site raises additional moral and legal questions. This data may be stolen property, although Diebold's placement of the data on an unsecured and fairly friendly appearing FTP site may constitute an invitation to public download and examination. Nonetheless, the entertainment industry's grip on the interpretation of copyright law is making the copying of electronic media, in all forms, increasingly problematic. On the plus side, for the researcher interested in this material, there are, apparently, no copyright notices in most of the files, but it is my understanding that the absence of such notices does not mean there is no copyright. Furthermore, some of the files are, apparently, encrypted, although Bev Harris tells me that encryption came and went from day to day. As I understand things, the unauthorized distribution of encryption keys for access to copyrighted data and the use of cryptanalytic software to find these keys is a threat to the DVD industry and therefore, in many jurisdictions, it is illegal.

Of course, the fair use doctrine allows quotation from copyrighted work for the purpose of review, and the work that needs to be done here is clearly an example of review, just as much as any literary review of a novel. Furthermore, so long as the copies are made for noncommercial purposes, that is, they are not used to run elections, the damage done to the copyright holder is minimal. A negative review by a book reviewer may severely damage the market for a book, but that damage can't be recovered by a lawsuit against the reviewer unless the reviewer lied about the book. On the other hand, book reviewers are expected to buy their books, not download them in encrypted form from the publishers web site and then crack the password.

There is a second issue that people must face before setting out to download copies of or examine the material from the Diebold FTP site. While novelists are not punished for having read other novels before they write their own novels, the interpretation being made of software rights today is quite different. If a programmer reads one piece of software and then develops software to do the same thing, that new sofware is considered tainted, and the developer of the original may have a legal claim to it! This is the basis of a major argument underlying the current lawsuit by SCO against IBM over IBM's contributions to Linux after having had access to the original Unix source code under licence from Bell Labs. Therefore, programmers interested in developing their own voting applicatons should probably be very careful to limit their exposure to any source code extracted from the Diebold FTP site.

That said, I believe that there is a compelling public interest in obtaining the answers to the above questions! Several of us have been warning for some time about weaknesses in the current FEC/NASED certification process, but public discussion of this process has been hampered, to a significant extent, by the fact that there has been no public access to any source code that has passed through the FEC/NASED mandated review process, and indeed, even the reports of the source code auditors under this review process are confidential.

There are parallels between this case and the case of the Pentagon Papers, where it is clear that they were, indeed, stolen property, but it was also clear that there was a compelling public interest in their disclosure and therefore the attempt by the government to suppress their publication was put down in the courts.

5. Some Disturbing Answers

On July 24, 2003, Tadayoshi Kohno, Adam Stubblefield, Aviel D. Rubin and Dan S. Wallach released a report on their examination of unencrypted code they had recovered from Diebold's web site. This paper has become known as the Hopkins paper. [See Analysis of an Electronic Voting System] (It is worth noting that I was unaware of this paper while I wrote the first 4 parts of this work!) This paper confirms that the Diebold web site contained not only code for the GEMS system used to manage elections, but also code for the AccuTouch terminal. Furthermore, this paper makes it quite clear that the errors I had pointed out to representatives of Global Election Systems when they first came to Iowa with the AccuTouch system have not been corrected in code that was available on Diebold's server half a decade later.

On reading the Hopkins paper, I immediately called for the decertification of Diebold's direct recording electronic voting system. I believe this is entirely justified by the magnitude of the security flaws identified in that paper, and completely independently, I believe it is justified by the fact that Diebold's predecessor, Global Election Systems, knew about that one flaw and did nothing to correct it over half a decade. Here is my call for decertification, in the form it was forwarded by Sandy Steinbach, Director of Elections for the Iowa Secretary of State's office. I have edited the E-mail addresses out of the mail header and replaced them with notes on affiliations of the recipients. The body of the E-mail is preserved with all my original typos.

From: "Sandy Steinbach"
Date: Wed Jul 23, 2003 04:47:04 PM US/Central
To: "Tom Wilkey" -- New York Elections office
  "Doug Lewis" -- The Election Center
  "Linda Lamone" -- Maryland Elections office
  "Brit Williams" -- Kennesaw State University
  "Douglas W Jones" -- Iowa Board of Examiners
  "Marilyn Jo Drake" -- Iowa Board of Examiners
  "Mike Mauro" -- Iowa Board of Examiners
Cc: "Chris Scase" -- Iowa Attorney General's Office
  "Tom Tully" -- Iowa Secretary of State's Office
  "Chris Ludlow" -- Iowa Secretary of State's Office
Subject: FYI Diebold Voting System

Folks:

Below is an excerpt from an email I received today from Dr. Douglas W. Jones, a professor of computer science at the University of Iowa and a member of the Iowa Board of Examiners for Voting Machines and Electronic Voting Equipment. I thought you would be interested in this.

Sandra J. Steinbach
Director of Elections
Office of the Iowa Secretary of State
515-281-5823

Excerpt from Dr. Jones' email:

Avi Rubin is publishing a paper tomorrow that will be discussed in the New York Times (I learned about it from a reporter for the Times). In this paper, he reports the results of his detailed audit of the source code for the Diebold (formerly Global) AccuTouch (or AccuVote DRE system). To my knowledge, this is the first time any code that has been certified to comply with the FEC/NASED voting system standards has come before any independent outside review.

This review is because the code was left, in openly accessible form, on Diebold's FTP site. See

http://homepage.cs.uiowa.edu/~dwjones/voting/dieboldftp.html
The Case of the Diebold FTP Site

for history of this strange story. As soon as I get a web link for Rubin's writeup (tomorrow, I assume), I will post it to that page as well.

Anyway, what has been revealed about the Diebold voting system is damning enough that I believe the system should be immediately decertified.

I did not call for decertification of the Diebold (previously Global) AccuVote optical mark-sense voting system. The work done by the Hopkins group calls into question the reliability of electronic reports from that system to the vote counting center, but with mark-sense voting machines, we have the actual paper ballots from the voters to recount, and (at least in Iowa), we require two paper copies of the precinct totals to be printed before any electronic transmission of the totals, one to be posted in public at the precinct, and the other to be hand carried to the vote counting center. This paper trail can be relied on even if the electronic transmission is corrupted or subverted.

In states that allow the official canvass of an election to be computed entirely from electronically transmitted totals, I believe it would be proper to decertify the Diebold's optical mark-sense system, or at least, to cease using the electronic communication features until such time as the vendor can demonstrate that they have eliminated the security flaws identified in the Hopkins paper.

Limitations of the Hopkins Paper

The Hopkins paper is not without its faults. Rebecca Mercuri posted a broadside to the web on July 24, 2003 that makes several important points. [See: Critique of "Analysis of an Electronic Voting System"]

I entirely agree with Mercuri that the biggest issue raised by the Hopkins paper deals not with Diebold but with the adequacy of the current FEC/NASED Voting System Standards. These standards are woefully inadequate when it comes to almost every aspect of security. Under the 1990 standards, the source code auditors who read the code for the I-Mark Electronic Ballot Station back in 1996 described it as the best voting system software they'd ever seen! This is despite flaws I found, without looking at the code, shortly after that, and it is despite the flaws that the Hopkins group identified that must have been present then. This brings into question not only Diebold's code, but the our entire current system for voting system certification.

In her critique, Mercuri notes, and I agree, that Diebold (and their predecessors Global and I-Mark) should not be criticized for their choice of C++ as an implementation language. In the first place, it takes years to develop a good voting system, and we should expect a mature system to use a language that looked like a good choice when development of that system began, without regard to languages that are considered, today, to be the best choice for new development.

In addition, it may actually be inappropriate to begin developing a voting system, or, for that matter, any software that is supposed to be subject to external audit, in a new language. The problem is, if you want your product to be auditable, you want to develop it in a language with a large user community that has had several years in which to develop mature coding standards. C++ remains an excellent choice when judged by this criterion, while Java has only recently grown in use to the point where it begins to qualify.

Mercuri also notes that the Hopkins group worked without clear knowledge of exactly the system on which the Diebold software runs. Indeed, they did not run it on an AccuTouch (or AccuVote Touchscreen) system, and they were unaware, apparently, that it was originally developed to run under Windows 95. At some point, I am unaware when, the product was moved to Windows CE (a sensible move, but see the next paragraph). The original I-Mark voting kiosk, on which this software was originally developed, was an off-the-shelf PC compatible system packaged in a kiosk housing and running Windows 95, and the first version of this system repackaged in a portable wedge-shaped enclosure still ran Windows 95.

On October 23, Joseph Holder, digging through archived Diebold internal E-mail, uncovered E-mail dated July 2, 2002 from Talbot Iredale at Diebold containing a dialogue with Rary Runyan about the installation of Windows CE version 3.00 release 20702. It is clear from this dialogue that Diebold considered it within their authority to install new releases of Windows CE to fix minor bugs in the voting system, even within a month of the use of that system in some election. It is also apparent from the discussion of application specific features discussed in the list of bug fixes that this version of Windows CE was very specific to the Diebold application. [See Re: WinCE 3.00 July 2, 2002 Release].

There is also the issue of election practices. Some of the criticism in the Hopkins paper is based on the assumption that the voting machine might be connected to a network. That is not the intent of the design, and the manuals for use of this system make it clear that all communication with the machine, prior to the time the modem is connected for reporting the results of an election, is done by hand carried PCMCIA cards.

I believe that these limitations do not seriously detract from the essential contribution of the Hopkins paper! The lack of evidence of any key management tools for the DES keys that are essential to the security of their PCMCIA cards and their modem-based communication of election results remains a fatal flaw, as does the complete lack of reasonable safeguards to secure the the smartcard interface.

The biggest issue Mercuri raises in her critique is that we have no evidence that the code that was found on the Diebold FTP site is actually the code running in any voting machines. This is true. We also have no evidence that it is not being used in any voting machines! The evidence we do have, however, is that code that was examined dates from around the years 2000 and 2002, while my stern warning to representatives of Global Election Systems about key management problems was delivered on Nov 6. 1997, not long after Global acquired I-Mark Systems, close to three years before the earliest version of the code examined by the Hopkins group. Whether or not this defect has been fixed today, the fact that it went unacknowledged for at least 3 and possibly 5 years is entirely unacceptable!

6. Rebuttals

On July 25, 2003, Diebold Corporation posted a rebuttal to the Hopkins Paper, posted to http://www.diebold.com/technical.htm and entitled Diebold - Technical Response To The Johns Hopkins Study On Voting Systems. On July 29, Bev Harris posted a response to this initial rebuttal to Scoop. [See Scoop, July 29, 2003] In her response, Harris shows how the version numbers from code found on Diebold's FTP site relate to the version numbers listed as having been approved on the NASED web site. This demonstrates that the versions tested by the Hopkins group were certainly closely related to production code. She points out that Diebold's claim that their software is constandly updated and improved suggests a development process that is far from what would be expected under a clean ISO 9000 development process, and she addressed several other points.

Diebold's first response was removed from the web and replaced with a collection of new material on July 29, all posted indexed under the "DIEBOLD IN THE NEWS" section of http://www2.diebold.com/default.htm.

These new postings included a rewrite of the original technical response [see Summary technical analysis of recent voting system report] and a press release [See Diebold Election Systems exposes flaws found in recent voting system report]. These preliminary responses were expanded on in the detailed technical response posted on July 30 [See Checks and balances in elections equipment and procedures prevent alleged fraud scenarios]. This latter document is a line by line examination of the allegations made in the Hopkins paper, far more thorough than Rebecca Mercuri's critique or anything I have posted above. It really cannot be read without a copy of the original Hopkins report in hand!

In summary, most of the Diebold rebuttal correctly identifies the weaknesses of the Hopkins report. Their detailed rebuttal is correctly named; it is indeed the case that procedures outside the software are central to defending against many of the attacks identified in the Hopkins paper. I have long held, voting systems cannot be properly evaluated out of context, and that the procedures and physical context in which they are used are as important as the mechanisms and machinery itself.

While most of the charges in the Hopkins paper are addressed effectively in this series of rebuttals, not all are, and the charges that remain are serious ones! The allegation numbers and responses quoted here are from Diebold's July 30 rebuttal:

Allegation #16 (p. 7):
"They may also be transmitted over Internet or dial-up connection."
Diebold Response
... in practice, the election data is not transferred over the Internet or dial-up connection. The election data (election.edb) is transferred to memory cards over disconnected local area networks at election central.
My Added Comment:
Security of PCMCIA cards requires the same level of care as security of netowrk transmission. Hand carried PCMCIA cards can be read and reprogrammed by pocket-sized computers! They are small enough for sleight-of-hand manipulation, and therefore, they are as vulnerable to attack as network packets -- true, the attacks are different, but strong cryptography is as justified for those hand carried PCMCIA cards as it is for any network communication!

Allegation #19 (p. 6)
"... we observed that the smartcards do not perform any cryptographic operations."
Diebold Response
Hypothetically, it would be possible to reverse engineer the password using the means described, but to describe the process as "easy" is an exaggeration.
My Added Comment:
This is an admission of weakness cloaked as a defense. The only question is, how hard should it be to crack a system. Does it need to stand up to a casual hacker, or should it also be defended well enough to fend off, say, a PhD student in computer security with no scruples and a strong desire to change the outcome of some election?

Allegation #21 (p. 9):
"Again, given the privacy of voting booths, an attacker using such a card reader would be unlikely to be noticed. ... an attacker could quickly gain enough insight to create homebrew voting cards ..."
Diebold Response
This is possible in theory ... Since the perpetrators would need to be at the polls, and sign in, this would seem to be a high personal risk for the few fraudulent votes that could be cast.
My Added Comment:
Again, they have admitted the technical point, while relying on polling place procedure. The vulnerability of actual polling places will be very low if there are only a few voters present, but the vulnerability goes up considerably if the crook shows up with the crowd and doesn't bother to sign in. Note that, in the old days of lever machines, the election workers primary job was to watch the machines and make sure that only authorized voters stepped into a machine and that each one cast only one vote. Nowadays, with modern security technology, poll workers will expect the smartcards or other enabling technology to assure this, and they may not be as vigilant as they once were. As Diebold points out, however, this entire approach to election fraud is only good for retail fraud, allowing a few extra votes to be cast by each participant. Retail fraud, however, is an old and widespread problem. That's one way that the classical dirty political machine remained in power, relying on the local ward boss to somehow stuff the ballot box as needed in each ward.

Allegation #22 (p. 10):
"More simply, instead of bringing multiple cards into the voting booth, the adversary could program a smartcard to ignore the voting terminal's deactivation command. Such an adversary could use one card to vote multiple times."
Diebold Response:
This is incorrect. We are not aware of a way to program the smartcard in such a way..."
My Added Comment:
I admit, I don't know my way around smartcards, but if I were trying to do this, I'd write an emulator for the smartcard in question that I could run on my PDA, and connect this through a short cable to a carefully built smartcard interface (it would look like a card, with contact pads in the right place and a cable coming out the edge of the card. This would be very similar to the tool an attacker would use to wiretap the dialog between the real smartcard and the machine in order to get the password. It wouldn't need to emulate the full card, just to carry out the expected dialog between smartcard and voting machine.

Allegation #26 (p. 10):
"Using a homebrew administrator card, ... if a malicious voter entered an administrator card ... the voter would be able to terminate the election ... an interesting denial of service attack.
Diebold Response:
While possible in theory ... the voter would have signed the roster to gain access to the voting machine, ... making this a high-risk attack.
My Added Comment:
Again, Diebold has admitted the weakness in their system and placed the burden on the poll workers. If an attacker manages to get to a voting machine without signing in, the risk to the attacker goes way down. See my comments on Allegation #21 for more on this.

Allegation #27 (p. 10):
"Even if the poll workers were later able to resurrect the systems, the attack might succeed in deterring a large number of potential voters ..."
Diebold Response:
Administratively "closing" or even "deleting" an election ... is an entirely reversible operation...
My Added Comment:
No it is not! Once a voter walks away from a polling place in disgust because the lines are long and the poll workers are busy untangling some kind of equipment snafu, whether caused by an attacker or accident, that voter's vote has been lost and no successful restart of the voting machinery will recover that voter's vote!

Allegation #28 (p. 10):
"First, hard-coding passwords in C++ files is generally a poor design choice."
Diebold Response:
This issue has since been resolved ...
My Added Comment:
This can be read as an admission that they indeed made this mistake in what we can infer were all versions of their code prior to late 2002. We must therefore ask whether their new passwords are genuinely more secure or have they merely been moved from the source code to an insecure configuration file.

Allegation #34 (p. 10):
"While the data stored internally on each voting terminal is not as accessible to an attacker ... exploiting such information presents a powerful attack vector, especially for an election insider."
Diebold Response:
It is an attack vector only for an election insider at election central ...
My Added Comment:
Here, it seems Diebold and Hopkins agree that the code offers no defense against the insider. We therefore must demand that all relevant insider actions be conducted in the open, with observers from opposing parties present. As the election officials in Geneva Switzerland have said, their biggest mistake with the first elections they conducted using their new Internet voting system was the failure to train the partisan observers adequately so that they can actually understand what they are watching at election central. If all the observers can make of the activity they see is that magic is being performed, the presence of observers assures nothing useful!

Allegation #39 (p. 14):
"While the current method of implementing the counter is totally insecure ..."
Diebold Response:
... In fact, we are not aware of a hardware device that could serve this purpose ..."
My Added Comment:
Looking back at the 1990 FEC standards and its discussion of the public and protective counters, it is clear that the authors envisioned the public and particularly the protective counter to be distinct hardware devices, completely independent of any microprocessor in the voting machine. A typical implementation that satisfies this requirement would be an odometer mechanism in a sealed box with a glass window over the counter and a solenoid that would advance the count by one for each increment pulse. The public counter would have a reset button, the protective counter would have no way to reset it short of physically breaking into the sealed box. The authors of the standard were clearly thinking in terms of the way this function was done in lever machines.

Allegation #40 (p. 14):
"... All of the data on a storage device is encrypted using a single, hardcoded DES key: ... F2654hD4 ..."
Diebold Response:
An attacker would need access to both the source code and the physical storage.
My Added Comment:
They have not disputed the assertion that their key was hard coded in their system! Thus, while they may have changed the key from the value they evidently used between 2000 and 2002, their defense suggests that they see no reason to adopt stronger key management! The claim from the Diebold product information web page for the AccuVote-TS system, [see http://www2.diebold.com/dieboldes/accuvote_ts.htm] still says that they use world-class encryption technology. It is not "world-class" to use a fixed key that is hard coded into the application, and it has not been so since before World War II! World class encryption requires key management, multiple keys, and well defined key distribution protocols, the absence of which Diebold does not seem to be disputing!

Allegation #44 (p. 15):
"... First, DES keys can be recovered by brute force ..."
Diebold Response:
There are stronger forms of compression than DES ... To mount such an attack, poll workers would have to collectively bring to bear the resources outlined ...
My Added Comment:
They do not dispute their use of DES, an encryption standard that is no longer considered world class, and indeed, a standard that was believed by many to be second-rate even at the time it was introduced. Furthermore, they have not claimed to use a key management policy that would automatically assign new unique keys to each polling place and for each election, and a claim to world-class encryption demands such a policy. Without such a policy in place, cracking the key for one election would be very likely to allow an attack on the data from multiple polling places or worse yet, cracking the key for one election would allow an attack on the data for subsequent elections.

Allegation #45 (p. 15):
"Jones reports that the vendor may have been aware of this design flaw in their code for several years ..."
Diebold Response:
We were not able to find such a claim in the Jones paper.
My Added Comment:
See Section 2 of this work What We Already Knew, Subsection on Communication and Security, in the final 2 paragraphs. This text is substantially as it was on July 23, 2003, except for the addition of dates on July 25 and the names of the Diebold representatives present at the meeting, added August 4. Bov Urosevich, later president of Diebold Election Systems, was present at the meeting back on Nov 6, 1997, as was Barry Herron, their sales representative.

Allegation #51 (p. 16):
"While the voter's identity is not stored with the votes, each vote is given a serial number ... generated by a linear congruential random number generator ... seeded with static information.
Diebold Response:
... There is no need for "security" here. The only intent of this code is to pseudo-randomize the order of ballots for purposes of display and reporting, as required in some states.
My Added Comment:
Diebold is wrong. There is need for security here. If the sequence of pseudo-random numbers is known, and the sequence in which voters actually entered the booth has been recorded (as a poll-watcher can easily do), then we can recover any particular voter's ballot from the report of individual ballots. This allows an insider working at election central to check this report (I'd use a pocket camera to take photos of the report), in cooperation with a poll watcher, to confirm whether the paid voters have earned their pay by voting the required way. Vote buying schemes that rely on insiders at the vote count cooperating with poll-watchers date back many years, and therefore, strong randomization schemes are justified here! I've worked as a poll watcher, I know that perfect records are hard to keep, but I also know that I can correct my records if I can talk a few voters into signing their ballots with pre-selected write-in votes or funny patterns of yes-no votes on the judicial retention ballot.

Allegation #53 (p. 16):
"Physical access to the voting results may not even be necessary to acquire the voting records if they are transmitted across the Internet."
Diebold Response:
... Results are not transmitted over the Internet.
My Added Comment:
But we know that result transmission uses telephone, PPP, and a username and password, from Page 14 of the Hopkins report, quoted in Allegation #40. Therefore, it is quite possible that election central will have a LAN connected using Internet protocol, perhaps used to connect a modem bank with a single PC. This LAN may not be as vulnerable as the public Internet, but it is vulnerable to packet snooping and several other attacks, and must therefore be carefully secured. Furthermore, if an adversary can dial into the PPP host and await connections, Trojan horse applications on the voting system could communicate with the adversary using PPP without talking to the GEMS system at all.

Allegation #54 (p. 16):
"The Diebold voting machines cannot work in isolation ..."
Diebold Response:
This is false. ... The primary form of output for the Ballot Station is the result tape ...
My Added Comment:
Diebold is wrong. Just because communication is accomplished using hand carried media such as the PCMCIA cards used to program the machine before the election and the printout used as the official election record does not mean that the machine is isolated. See my response to allegation #16! Hand carried PCMCIA cards need just as much protection as network communications. Furthermore, the printout from the machine is not necessarily the final result unless we make this printout before we make any modem connection that could admit an intruder; here, the Diebold system, because of its weak security, relies unnecessarily on strict adherence to correct polling place procedures. Not only that, but we are under increasing pressure to use the electronic record for canvassing, generally the one in the hand-carried PCMCIA card taken from the voting machine, but in the not-too-distant future, we may be pressured into using the result from the modem! That paper record wasn't even an option with Global's system when it was offered for sale to Iowa in 1997, and today, I gather that many jurisdictions don't look at it unless there's a call for a recount.

Allegation #77 (p. 16):
"an audio library called 'fmod' is used ... there is no proof that fmod itself does not contain a backdoor."
Diebold Response:
Fmod is merely a sound library. The possibility of tampering with encrypted results record through the playing of an audio sound is, at best, "academic."
My Added Comment:
Again, by admitting that this is an academic possibility, Diebold has admitted the point. I agree that it's a pretty remote possibility right now, but if a system is vulnerable to a sufficient number of academic attacks, there is a possibility that the attacker will go to school, learn how to think like an academic, and exploit one of these!

I have several smaller quibbles with Diebold's response to the Hopkins paper, but I will not belabor them here because, compared to the points above, they are relatively unimportant.

On July 23, 2003, the authors of the original Hopkins report posted their own response to Diebold's attempted rebuttal. This is a narrative reply, as opposed to Diebold's point by point analysis or my point by point reply given above. [See Response to Diebold's Technical Analysis]

Further evidence of the inadequacy of election procedures on which Diebold rested their defense continues to crop up. For example On October 23, Joseph Holder, digging through archived Diebold E-mail, uncovered E-mail dated Nov 6, 2000 quoting Talbot Iredale at Diebold; this exchange makes it clear that Diebold was allowing GEMS-1-17-7-6 to be downloaded from the Diebold election site into machines in the counties within 24 hours of election day, directly, without any apparent provision for oversight by state examiners. [See Re: GEMS-1-17-7-6].

7. Retractions and Reactions

The pattern of Diebold's initial response was clear -- attack the attackers, and pull in as much support as possible from those with a vested interest in DRE voting. For example, on August 3, the an AP news-wire report carried on the WAVY TV web site reported that Virginia had decided to use Diebold's system, and that Britain J. Williams, acting as an advisor to the state of Virginia, had joined Diebold in condemning the Hopkins analysis, and that he said that the authors owed Diebold "a public apology." [See State Board of Election Officials OK Touch-Screen Voting in Norfolk.]

On August 5, Diebold made a presentation to a group of Securities Analysts in which they outlined their response. In this conference, Greg Geswein, Senior Vice President and Chief Financial Officer, presented a slide (slide 5 of 24) giving Diebold's management philosophy, stating, among other things, "We believe in open disclosure." Tom Swidarski, President, Diebold Election Systems presented this (slide 8 of 20):

CURRENT ISSUES

Swidarski's presentation showed that they have 47,000 touch-screen voting systems in place, of which 22,000 are in Georgia and 16,000 in Maryland, with 4 California counties using 7,700 between them, and the remainder in single counties in Texas, Virginia and Indiana (slide 13 of 20). Their campaign to break into the Ohio marketplace includes a statewide blitz of demos, marketing aimed at the Secretary of State's office and at each county (slide 14 of 20). [The PDF files for these presentations were available on the web at Diebold 2003 Investment Community Conference Presentations.]

Note that by this time, Bob Urosevich was no-longer being listed as president of Diebold Election Systems! He was listed as president in their First Quarter Newsletter [see Diebold - Customer Communications - News & Happenings], but as of August 12, that was the only reference to him on the Diebold corporate web site.

(Note added later: By December 2003, Urosevich had re-emerged as president of Diebold Election Systems, explicitly stating his company's negligence to the California Voting Systems Panel and announcing the creation of a new standards compliance officer. [See Voting Machine Maker Dinged, by Elise Ackerman, San Jose Mercury News, Dec. 17, 2003, and see Diebold Election Systems Announces Restructuring of Compliance and Certification Processes Diebold Press Release, Dec. 18, 2003.])

One disturbing element of the efforts mounted in defense of Diebold has been letters to officials at Johns Hopkins University asking for retraction of the Hopkins report or action against members of the Hopkins team. This came out in discussions at the August 6 USENIX Security Symposium and was quoted in the Toledo Blade and the Pittsburgh Post-Gazette the next day. [see Voting by touch has weakness, experts say or Computer voting viewed skeptically]

By August 11, the Diebold story had made not only the New York Times, but also the Washington Post, the Pittsburgh Post Gazette, the Atlanta Journal Constitution, The Arizona Daily Star, MSNBC, The Toledo Blade, and NPR's All Things Considered. It was not, however, the Media Blitz that Diebold had hoped for. Although a few outlets did run the story following Diebold's lead, much of the coverage was well balanced, based on extensive interviews with all sides. Generally, the local media in states that currently use or are considering buying Diebold equipment are the ones that have covered this story with the most care.

Diebold's denial that the code tested by the Hopkins group, while strident, had already been retracted by August 4, when, according to Wired News: More Calls to Vet Voting Machines, Mike Jacobsen, a spokesman for Diebold, "confirmed that the source code Rubin's team examined was last used in November 2002 general elections in Georgia, Maryland and in counties in California and Kansas."

Curiously, this and several other parts of the wired article were rewritten at some point on or soon before August 11, and replaced by far more carefully worded quotes from John Kristoff, director of corporate communications for Diebold and presumably Mike Jacobsen's boss. The outright admission Slate had originally quoted was replaced by Kristoff saying tha the code examined by the Hopkins group "on the whole is not the same" as production code, and that Diebold cannot determine whether the lines of code that raised concern for Rubin were used in machines in the field.

Wired did not change the dateline on their on-line text when they made this change, but the carefully worded replacement still suggests that large parts of the code examined by the Hopkins group were indeed present in production systems. The phrase "on the whole is not the same" is only likely to be used if they could not honestly say "not substantially the same". That is, except for small parts, the code examined by the Hopkins group must have been substantially the same as the code used in production.

The newest version from Diebold, the AccuVote TSX, apparently allows wireless transmission of precinct results to the GEMS server, but Diebold defends this, saying that the electronically transmitted results are only unofficial results, while the official canvass depends on hand-carried records. This subject was discussed in the Acron Beacon Journal on August 15, 2003. [See: E-voting becomes touchy topic.] Unfortunately, the specific details of canvassing are a matter of state law, outside of Diebold's control, and in addition, the Diebold operating instructions apparently call for the connection to the server to be established prior to computing the precinct totals. This means that the memory cards holding the official results for each precinct are exposed to corruption by any network insecurity, and therefore, that the official canvass can be corrupted if someone hacks into the machine. Furthermore, it is emerging that the version of Windows CE used by Diebold is both heavily customized and full of dynamically loaded libraries. As a result, there are strong grounds for the conclusion that the operating system is not unmodified commercial off the shelf software (COTS), and that with this extensive use of dynamic linkage, we cannot even tell if the system being run on a particular voting machine resembles the system that was disclosed in the configuration documents submitted with this system when it went through the FEC/NASED approval process.

Perhaps the biggest development in early August was the agreement by the state of Maryland to submit Diebold's system to an independent, third-party audit. This audit is to be conducted by Science Applications International Corp. of San Diego, a company with a decent reputation in the security arena, and Diebold has granted this company access to its code under a nondisclosure agreement. [See Wired News: E-Vote Machines Face Audit] Unfortunately, as it emerged later, SAIC may be entangled in some conflicts of interest in the voting systems arena, see the next section! The SAIC report, with significant deletions, was released by the state of Maryland on September 24, 2003 and is the subject of a later section of this work. [See: Risk Assessment Report: Diebold Accuvote-TS Voting System and Processes, SAIC-6099-2003-261, Sept 2, 2003]

The State of Ohio has also reacted positively. First, on August 5, the Dana Walch, Director of Election Reform, in the Ohio Secretary of State's office, issued a memorandum to all election vendors asking 24 questions about information security. These questions addressed both voting system security and general secure development practices, and they were phrased in the form "do you follow practice X?" and then "if you do not follow practice X, will you commit to doing so?" Vendors were only given one day to respond! The biggest weakness of this list of questions was its focus on the use of Certified Informtion Security Auditors and Certified Information System Security Professionals -- these certifications are not seen as being very demanding by those doing security research, but it is my guess that most vendors have not subjected themselves to internal audits anywhere near as challenging as those demanded by this memo.

The story in Ohio is complicated by the fact that Sequoia Voting Systems was bumped from the list of DRE system vendors contending for the right to sell machines in Ohio on August 8, 2003. On August 11, Sequoia threatened legal action. This was reported in the Cleveland Plain Dealer on August 13. [See Voting-machine firm threatens action against state.] The Plain Dealer also ran a story on Diebold's aggressive posture in Ohio on August 10. [See To win contract, Diebold offers the state a carrot.]

On August 15, 2003, Ohio Secretary of State J. Kenneth Blackwell reported that "our initial inquiries into security issues regarding E-voting devices leaves some unanswered questions." Presumably, this is a reference to unsatisfactory answers to the questions Ohio posed to voting system vendors on August 5. As a result, he said, "we will put these voting devices through an extensive security assessment and validation process." Ohio opted to use Science Applications International and InfoSentry Services for this. This story was reported in Washington Technology, [See Ohio holds on voting machine purchase.]

On August 22, 2003, Roxanne Jekot, a 51-yer-old computer programmer attended a meeting on computerized vote tabulation in Georgia and offered an open challenge, saying that she and a few expert friends could crack the Diebold system in a matter of minutes. The dare was accepted by Cathy Cox, Georgia Secretary of State, and Brit Williams, long-time voting systems examiner for Georgia. It will be interesting to see how this story plays out! For the challenger, the risk is that the system used for the challenge will be rigged with added security measures that are not the same as those used in the polling place. For the state and Diebold, the risk is that the outside challenger will get through whatever security measures happen to be in place for the challenge. [See ajc.com | Metro | Dare accepted on electronic voting machines.]

Roxamme Jekot's own account of the challenge is that, after sitting through the "dog and pony show" asking reasoned questions and challenging information with facts, she asked: "So, Dr. Williams, if I agreed to bring a team of computer professionals to Kennesaw to show you how to hack an election, would you accept that challenge."

Another late development is the discovery by Jim March, reported on Sept 3, 2003, of what appears to be a file of ballot images collected at 3:31pm on 3/5/02 that was included in the data on the Diebold FTP site. The data within this file, sloprimary2002ORIG.mdb, is apparantly fully consistant with it being an actual tally of the votes midway through the primary election that was held in San Louis Obispo County, California, on that day. This tally probably represents absentee and "postal precinct" votes that were tallied at the county offices during the day. In fact, this is normal procedure for postal votes in most states. Tabulation may legally begin when the polls open, so long as no totals are released until after the polls close. What this does not explain is how Diebold came to be in possession, on their web site, of this data! The password Jim March found for this file, Sophia, suggests the possible identity of its creator. The county Registrar apparently recalls a Diebold employee named Sophia who was there during that election. [See http://www.equalccw.com/dieboldtestnotes.html for Jim March's original report on this set of files.]

This brings into question Diebold's assertion that the security loopholes in their voting system are of no importance because procedural safeguards prevent their exposure. In fact, it appears that such procedural safeguards were not in place in San Louis Obispo County, despite the presence of on-site supervision by a Diebold employee. Somehow, the GEMS system being used to accumulate absentee and postal ballots was connected to the internet -- the presence of this preliminary file on an internet server is proof. Furthermore, E-mail from Robert Chen within Diebold, sent on October 28, 2002 and, much later, leaked to Bev Harris, shows that the GEMS system in Almedia County was on-line, reachable directly from the outside world. [See Bev Harris posting of Friday Sept. 5; Note, this material was apparently also posted to Bev Harris' web site at Black-Box voting, but that entire web site was taken down by her ISP almost immediately shortly after Bev Harris posted this material; that site has since moved to a new ISP.]

Sometime over the Summer of 2003, a 1.8 gigabyte archive of internal Diebold E-mail was leaked Brian McWilliams, a business and technology reporter. This archive represents the state of Diebold's internal e-mail lists as of March 2, 2003. Initially, the focus of this story was that, despite Diebold's efforts to secure their servers, hackers were still obtaining inside information, and McWilliams actually deleted the leaked memos from his disk because they occupied too much space. [See Brian McWilliams, New Security Woes for E-Vote Firm, August 7, 2003, Wired News.]

In fact, these memos were leaked by an insider, apparently in response to the Hopkins Report; they were not uncovered by an outside hacker. After failing to get the attention of McWilliams, on September 5, one of these memos, the "smoking gun memo" was posted to Bev Harris's web site, BlackBoxVoting.org. This memo, from Ken Clark in reply to a question by Nel Finberg, was posted to Diebold's internal support mailing list on October 18, 2001. The memo makes it clear that Metamor, the source code auditor operating under the FEC/NASED voting system standards, had raised questions about the security of GEMS and the integrety of the audit trails, since these can easily be changed by using Microsoft Access. Diebold convinced Metamor that this was a non-issue because it is up to the customer to secure the system, despite the fact that Diebold was aware that this security was being routinely breached: "Jane (I think it was Jane) did some fancy footwork on the .mdb file in Gaston [county Florida?] recently, I know our dealers do it. King County is famous for it. That's why we've never put a password on the file before." [See BlackBoxVoting on Diebold's Internal Memos or Alteration of Audit Log Access.]

On receipt of this leaked memo, Bev Harris immediately passed it on to a number of people (including myself), and she tracked down the source of the leak and asked if there was anything more. On receipt of the entire memo collection, she began digging into it and began publicizing the results of her investigation on September 10, 2003. The short summary of her work in Scoop 2 days later was the first most of us saw of this. [See Scoop: Diebold Confirms U.S. Vote Count Vulnerabilities, posted to the web Friday 12 September 2003.]

From this, it becomes very clear that Diebold's assertion that election procedures provide adequate safeguards is not so much an assertion about the quality of these procedures in real polling places, but rather, it is an assertion that the Diebold is not responsible for assuring the security of the vote, they are merely supplying equipment to the states and counties, and it is up to the states and counties whether these machines are used securely or not. Certainly, this is legally true, but it also seems to be the case that Diebold could provide much stronger tools! Furthermore, while Diebold's suggested procedures for election management allow for secure procedures, they are far from requiring them. Diebold's manual for their election day field technicians provides further documentation of the near complete lack of advice about security provided by Diebold to their customers. [See Election Support Guide, Revision 1.0, October 21, 2002, Diebold Election Systems.]

Initially, there were serious questions about the authenticity of the leaked Diebold memos, but Diebold's legal actions against the web sites holding those memos were very effective at putting those questions to rest. Diebold began a campaign attempting to shut down web sites that were distributing Diebold material before these leaks became an issue. In a letter dated Sept. 4, 2003, Nancy L. Reeves of the Walker and Jocke law firm wrote a letter on behalf of their client, Diebold, that demanded removal of http://www.equalccw.com/voteprar.html (a page of interesting links, many to material Diebold did not want released), and http://www.equalccw.com/dieboldtestnotes.html (a page containing links to GEMS code at the time the Reeves letter was written, but that also contained links to the "smoking gun memo" by the time the letter was received). Jim March responded to this demand with a forceful statement to his ISP and to Diebold's lawyers asserting the right to post Diebold's material and taking full responsibility for posting it, thus absolving his ISP from any legal responsibility for the material and preventing the ISP from complying with the demand from Diebold's lawyers. [See BBV: Jim March gets his Cease & Desist -- and responds.]

Matthew Allen copied several of Jim March's files to his web site, and within 28 hours, he received a note from his ISP informing him that the files had been deleted (on September 11, 2003) in response to E-mail received on September 11 by his ISP from, Nancy Reeves at Walker and Jocke on behalf of Diebold. [See Scoop: Website Shutdown By Diebold, Matthew Allen's narrative describing this story, and the E-mail to Mathew Allen's ISP and the ISP's reply.]

Diebold's response to this was interesting. When they could not get the material removed from the web, they went after at least some sites that held links to that material. During the night of Thursday Sept 25 (before 2AM Friday morning), Diebold's lawyers issued a pull-down demand, probably something very similar to the demand sent to Jim March's ISP, for the BlackBoxVoting.org web site, citing a link on that site to material Diebold claims is under copyright, apparently at Jim March's site. Everything on the BlackBoxVoting site was confiscated by the ISP, AI Technology Inc, although the legal action apparently mentioned only one link explicitly. Note that Bev Harris' other site, BlackBoxVoting.com was not involved. (the shutdown of BlackBoxVoting.org invalidated several links in this file; links have been added to alternative sources for all the material cited by those links, but the orignal links have been left in place, awaiting the restoration of the web site in question.)

I warned of the possibility of such legal action in Section 4 over a month before this development, but Diebold's action is more extreme than I expected. Considering a link, a form of bibliographic citation, to be a copyright violation is a very dangerous idea. The right to cite, which is to say, the right to talk about or refer people to the content of a copyrighted work is quite different from the right to copy it!

The fragility of Diebold's legal grounds for these copyright complaints makes me wonder if their response is an example of a SLAPP action -- a Strategic Lawsuit Against Public Participation; SLAPPs have been carefully explored as a tool for silencing public activism in the environmental domain. The idea is not to have an argument that will hold up in open court, but rather, to have deep enough pockets that you can tie up your opposition indefinitely in a pre-trial legal morass. The outcome of the court case is irrelevant. The key is to scare those who might be tempted to speak out during the period when public debate can still influence a government policy or regulatory decision.

On October 16, 2003, the Electronic Frontier Foundation announced that it would defend an internet service provider, the Online Policy Group, and a website run by the Independent Media Center against copyright infringement charges stemming from IndyMedia's publishing of links to the same Diebold memos. According to the EFF, dozens of web sites were the targets of the Diebold take-down order. [See EFF: ISP Rejects Diebold Copyright Claims Against News Website]

By late October, a loosely coordinated campaign was underway at colleges and universities across the country to keep the Diebold E-mail archive available on-line, and Diebold's continued aggressive pursuit of copyright protection for it's E-mail continued to raise the public profile of this story. [See "File Sharing Pits Copyright Against Free Speech", by John Schwartz, The New York Times, Nov 3, 2003.] By the end of the month, the entire affair was being described as a game of whack a mole between Diebold and their opponents. [See: Students sue over voting vulnerability by Lindsay McGregor, Daily Princetonian, November 6, 2003.]

On November 17, lawyers representing Diebold and lawyers representing the Electronic Frontier foundation and the Stanford Center for Internet and Society argued this copyright issue before Judge Jeremy Fogel in San Jose California. Diebold argued that putting the Diebold memo collection on-line with no transformation or creative additions was copyright infringement, as was posting web pages with links to these memos. The fact that Diebold's lawyers felt compelled to mention the lack of transformation or creative addition in their argument suggests that the same material with added commentary, for example, editorial comments on the memos explaining their significance, might be easier to defend than the same material without such additions. [See Students fight e-vote firm's DMCA claims, by Declan McCullagh, , Nov 17, 2003.]

On November 24, 2003, Diebold threw in the towel, with a letter to The United States District Court, Northern district of California in San Jose, regarding the lawsuit brought by the Online Policy Group against Diebold, notifying the court that they were withdrawing their existing DMCA notifications and had decided not to issue further notifications for the memos. [See: Resp. to Plaintiffs' post-hearing ltr and supp. ng decl. and req. for early status conf. or ref. to mediation, Case No. 03-4913JF filed by Mittelstaedt and Sand, Nov 24, 2003.]

8. Conflicts of Interest

On August 17, Avi Rubin issued a press release in an effort to preempt the news story that had surfaced reporting that he had a conflict of interest because of his relationship with Vote Here, Inc, that could be expected to bias any research he did on the Diebold system. [See STATEMENT OF AVI RUBIN ON RELATIONSHIP WITH VOTEHERE INC. In this press release, he emphasized that his relationship with VoteHere was minimal and that he was terminating it immediately. This release was the basis of an AP Newswire story that was widely carried by many papers on Aug 20. [See Scientist Quits Election Software Board, Kansas City Star, Aug 20, 2003]

The preemption worked, to an extent, in that the initial stories reporting his conflict of interest included his termination of relations, but the emphasis was on the appearance of conflict, not on the nature of the terminated relationship. See, for example, this, in the Atlanta Journal Constitution on August 19. [See ajc.com | Metro | Voting study leader admits conflict of interest.] The lead paragraph was

A Johns Hopkins University researcher acknowledged Tuesday that he had a financial stake in a competitor when he co-authored a study declaring Georgia's touch-screen voting system "fundamentally flawed."

It is worth noting that the status of VoteHere as a Diebold competitor was, itself, a very recent development. For years, VoteHere has had a minor presence in the world of elections. They began with a proposal for a cryptographic foundation for voting that might be applicable to Internet voting, but as time passed and the market failed to develop in that direction, their business model changed. By early 2003, VoteHere was offering their technology to manufacturers of direct-recording-electronic voting machines, with limited success. In short, for a vendor to admit that they needed the kind of technology VoteHere offered, they could be seen as admitting that their own internally developed security models were insufficient. Nonetheless, on August 4, VoteHere and Sequoia Voting Systems reached an agreement to incorporate VoteHere's technology into Sequoia's AVC Edge Touch Screen Voting System. [See: VoteHere Aug 4. 2003 Press Release.] Only with the completion of this agreement did VoteHere become, in any real sense, a Diebold competitor.

The Rubin/VoteHere relationship is not the only conflict of interest to turn up in this story! SAIC, Science Applications International Corp., the consulting firm hired by Ohio and Maryland to review the security of the Diebold system, turns out to have developed voting software in consultation with Diversified Dynamics (later purchased by Northrop Grumman), and several board members of VoteHere have also served on the board of SAIC. These conflicts were reported on August 20 by Lynn Landes. [See Voting machine fiasco: SAIC, VoteHere and Diebold.] This story has been carried widely in various weblogs and on various conspiracy theory web sites, but not in the "legitimate press." In part, this may be because, until SAIC comes up with a report on the Diebold system, the allegation of a potential conflict of interest is not really newsworthy.

More recently, it has emerged that SAIC has been in negociations with Hart Intercivic (a Diebold competitor) to invest $5 million in that company. This might have been a far clearer conflict of interest than the interlocking directorships and old work with Diversified Dynamics, and it led Ohio to withdraw from its decision to rely on SAIC for an outside opinion on the Diebold system. [See Ohio replaces voting machine reviewer in the Cleveland Plain Dealer, Sept 9, 2003.] In fact, however, this may be yet another example of initial appearances being more serious than the realityh. Here is a statement from Bill Stotesberry at Hart Intercivic on this issue, written on October 3:

SAIC's investment in Hart was actually an investment by an SAIC organization separate from that involved in the Ohio reviews. The specific investments made by this SAIC investment arm were unknown, at the time, to the security review team within SAIC.

SAIC's investment was as a limited partner in an independent venture fund that invested in Hart. When we became aware that SAIC was being considered as the security review vendor, we immediately contacted SAIC, and SAIC subsequently informed the State of the situation. Being under an NDA with our investor, we also obtained permission from both SAIC and our investor to independently alert the State. The State's action then followed.

So, it seems, Hart and SAIC both acted responsibly when this potential conflict came to their attention, and it is highly unlikely that it influenced the SAIC report done for the state of Maryland.

Diebold, milked the Rubin/VoteHere conflict for all it was worth when it came to light, and echoes of that public relations effort continue to color the perceptions of many about the validity of the Hopkins report. Diebold's August 19 Press release responding to Rubin's press release expresses "shock and dissapointment." [See Diebold Investor Relations, Diebold Responds to Johns Hopkins Professor's Disclosure of Relationship With Voting Industry Competitor.] This was circulated with a remarkably well-crafted set of supporting documents that selectively pick from the circulated media reports to build Diebold's case.

Meanwhile, the Information Technology Association of America, or ITAA, has put together a draft plan to "Create confidence and trust in the elections industry and promote the adoption of technology-based solutions for the elections industry. Repair short-term damage done by negative reports and media coverage of electronic voting. Over the mid- to long-term, implement strategy that educates key constituencies about the benefits of public investments in electronic voting, voter registration and related applications." This includes a timetable calling for membership in the task force to be finalized on August 29, 2003, with a teleconference on September 3, very fast public opinion surveying (to provide a "scientific" basis for their work?) and then, on October 14, a "launch event" to attract attention to their work. Curiously, Ronald J. Knecht is both a senior vice president at SAIC and a director of the ES division of ITAA that drafted the above plan, deepening the conflict of interest questions surrounding any work eventually done by SAIC. [See Scoop: Sludge #156 - SAIC Connected to E-Voting Whitewash.]

It appears that this plan did not come to fruit, but on December 9, 2003, newly formed Election Technology Council, formed by the major voting system vendors under the ITAA umbrella, announced the need for a code of ethics. [See Under fire, e-vote companies form a trade group, by Paul Festa, CNET, Dec. 9, 2003, and E-Voting Vendors Seek Credibility, by Grant Gross, PCWorld, Dec. 9, 2003.]

Another odd conflict of interest that has come up involves Gilbert J, Glenn, a lobbyist registered in the state of Maryland to represent both Diebold and SAIC. It is quite common to find one lobbyist representing two different corportions, but it is odd, to say the least, when the work of one of those corporations is called into question and the state then contracts with the other one to investigate the issue. Quite properly, the Governor of Maryland asked the State Ethics Commission to examine this connection when it came to light on September 26. [See Ethics Panel to scrutinize Md. lobbyist in the Baltimore Sun, September 27, 2003.]

The most bizarre conflict of interest issue to come out of this whole story is raised by a letter dated August 14, 2003 from Walden O'Dell, Diebold's CEO, to Central Ohio Republicans. In this letter, O'Dell says that he is "committed to helping Ohio deliver its electoral votes to the President next year." If it were the case that Diebold's machinery offered the possibility of a real audit of an election, in the same way that corporate accounting systems are supposed to be auditable, partisan bias on the part of the vendor would not be a problem, but this is not the case with direct recording voting machines such as the Diebold AccuVote TS. [See Democrats want election machine firm thrown out, in the Port Clinton News Herald, August 27, 2003 and Voting machine controversy, in the Cleveland Plain Dealer, August 28.]

As was the case with the Rubin -- VoteHere conflict, O'Dell's apparent conflict of interest appears to have been entirely unanticipated by those involved. After the queston came up, O'Dell's response was a baffled apology. [See Diebold executive to keep lower profile, in the Cleveland Plain Dealer, Sept. 16, 2003.]

Almost immediately after the Hopkins report came out, groups of handicapped rights activists began loudly defending Diebold. Writers campaigning on behalf of disability rights almost immediately began to characterize opponents of excessive reliance on computers as "a rising chorus of geeks." [See AAPD Disability Vote Project, Campaigning for Computerized Voting, Oct 30, 2003] There has even been well managed disruption of a professional meeting by handicapped rights activists, at the USACM Workshop on Voter-Verifiable Election Systems, where demonstrators (including Jim Dickson of the AAPD Disability Vote Project) stormed the meeting and took over the microphone to deliver their message supporting direct recording electronic voting machines and opposing all forms of voter-verified audit trails as being inherently inaccessible to the handicapped.

This strident opposition to voter verifiability has baffled those who want voter verifiability, since supporters of verifiability certainly do not oppose the rights of handicapped voters. There is a strong possibility, however, that this strident support for direct recording electronic technology is not the result of dispassionate analysis, but the result of a partnership. On November 1, 2000, Diebold and the National Federation of the Blind settled a lawsuit with Diebold centering on issues of accessibility of automated teller machines. This settlement involved Diebold, the NFB and the Disability Rights Council of Greater Washington, and while the focus was on ATMs, there was also a five-year $1,000,000 grant from Diebold to the NFB Research and Training Institute for the Blind. [See NFB Settles ADA Lawsuit with Diebold, and see The Braille Monitor, Dec 2000 Edition, Late-Breaking News Diebold and NFB Partner to Develop Next Generation Voice-Guided ATMs]

This, of course, does not imply that handicapped activists are acting as conscious agents of Diebold, but rather, that working in partnership with the company, many handicapped activists may have developed a loyalty that colors their perception of Diebold and of all stories that touch on the partnership that they have developed.

By June 2004, as stories of problems with direct-recording electronic voting machines became more widely known, this alliance began to unravel. The Ohio chapter of the NFB had filed suit on April 20 to force Ohio to install DRE voting systems immediately, but in mid June, they dropped the suit, explicitly recognizing that security concerns must be balanced with accessibility. [See Blind group withdrawing voting machine lawsuit Lancaster Eagle-Gazette, June 15, 2004.]

9. The SAIC (and other) Risk Assessments

In early August 2003, in response to the findings reported in the Hopkins report, the state of Maryland asked Science Applications International Corp. of San Diego to perform an independent risk assessment of the Diebold AccuVote-TS system. The SAIC report was released to the public, with significant redactions by the State of Maryland on September 24, 2003. This section summarizes the findings of that report and identifies some of its strengths and weaknesses. [See: Risk Assessment Report: Diebold Accuvote-TS Voting System and Processes, SAIC-6099-2003-261, Sept 2, 2003]

On Nov. 13, 2003, Frank Schugar, who led the SAIC study, told Avi Rubin that SAIC had nothing to do with the redactions. The decision to redact was made by Maryland, and it is the state that decided what sections to redact. This discussion occurred at a hearing of the Maryland House Ways and Means Committee.

An executive summary of the executive summary of the SAIC report might say: "The Hopkins report said that the Diebold AccuVote TS is very insecure. Diebold's rebuttal said that these flaws are not problems because checks and balances in elections equipment and procedures prevent alleged fraud scenarios. SAIC says that the Hopkins report is right, the system is very insecure, furthermore, SAIC says that Diebold is right, checks and balances in election policies and procedures could secure the system, but in fact, the policies and procedures they studied in Maryland provide no such assurance! Security loopholes in the Diebold system must be eliminated, and security loopholes in Maryland's policies and procedures must be eliminated"

The final paragraph of the executive summary of the SAIC report comes close to saying much of this:

The system, as implemented in policy, procedure, and technology, is at high risk of compromise. Application of the listed mitigations will reduce the risk to the system. Any computerized voting system implemented using the present set of policies and procedures would require these same mitigations. [Page V, final paragraph.]

This is harsh criticism of the polling place and canvassing policies and procedures of the State of Maryland, as well as harsh criticism of the technology offered by Diebold. Maryland's policies and procedures for the conduct of elections are in no way unusual, so in fact, there is good reason to suspect that the election procedures of other states would be similarly judged if they were subject to a similar risk assessment.

In mentioning policy, procedure and technology, this paragraph hints at an understanding of the defense in depth strategy, a strategy that states that defenses are layered, assuming that it will only be a matter of time before an adversary finds an exploitable vulnerability in a system. [See Defense in Depth updated June 24, 2003, one of the National Security Agency Security Recommendation Guides.] Unfortunately, in their anaylsis of the Diebold AccuVote TS system, SAIC did not take the lessons of the defense in depth strategy to heart. They appear to consider a threat posed by a technical flaw to be adequately addressed if election procedures, properly carried out, would prevent that flaw from being exploited. A defense in depth strategy must assume that each layer of the defense is likely to fail, so in designing polling place procedures the assumption must be made that the voting machines contain many technical vulnerabilities, and in designing the voting machines, the assumption must be made that the polling place procedures are flawed. You not only lock your office, but you also password protect your computer! One layer is not enough.

The SAIC report's concurrence with the Hopkins report is explicitly given on page III of the executive summary as well as in Section 2.4 (on page 9) of the body of the report. They point out that the major weakness of the Hopkins report was admitted in that report itself, that it did not study the actual context of use of the system, and they agree with Diebold that many of the security flaws of the Diebold system are covered by polling place and canvassing procedures. Unfortunately, many is not all, and the SAIC report comes down harshly on both procedural and technical flaws.

I strongly concur with all of the recommendations of the SAIC report, but some of these recommendations are insufficient. These are summarized here:

Despite the redactions in Section 2.1.4, the presence of this recommendation is confirmation that the weaknesses I had noted on Nov. 6, 1997 [see Section 2 of this work, What We Already Knew, Subsection on Communication and Security.] and that were rediscovered by the Hopkins group [See Allegations #40, 44 and 45 in Diebold's attempted rebuttal Checks and balances... .] Furthermore, since SAIC examined the current certified version of the code, the version number of which was redacted in the body of the text but exposed in Appendix D as 4.3.1.5, this seriously damages Diebold's claims that the the flaws reported in the Hopkins study were in old code that is not used in real elections.

That aside, the SAIC recommendation is weak because it allows me to believe that it applies only to transmission, although the redactions leave this a bit vague. It is crucial that this recommendation be interpreted broadly, applying not only to transmission using modems, radio or the Internet, but also to what Diebold's Election Support Guide dated October 21, 2002 refers to as sneakernet in Section 13, item 1. [leaked to Jim March and available at www.equalccw.com/ElectionSupportGuide.pdf.]

The term sneakernet is widely understood in the field of computer networking to refer to telecommunication done by manual transfer of data from one machine to another, for example, by a person walking across the room wearing sneakers. It really is the case that such hand-transfer of data introduces many security problems that are very similar to those introduced by electronic networks, and these data transfers must therefore be guarded with equal care. Consider, for example, the fact that viruses emerged as a threat to personal computers long before electronic networks were common. They were transmitted by hand-carried floppy disks, not E-mail on the Internet!

Unfortunately, PCMCIA cards do not offer security much greater than an unsecured modem for data transmission. Physical ballot boxes are big. It is easy to ask that a ballot box be handled and transported in the joint custody of two polling place workers, members of opposing parties who each monitor the other to make sure that the box is not opened and that no substitutions are made.

In contrast, PCMCIA cards are the size of playing cards, trivialy subject to sleight of hand substitution, and readable by devices as small as a PDA. It is not clear that joint custody means anything in this context! If polling place procedures leave the card in the hands of one person for a few seconds, substitutions could be made, and if two such opportunities are found within a few minutes of each other, arbitrary alterations to the substituted card could be made. Therefore, strong cryptographic techniques must be used to protect the data on the PCMCIA card!

The redaction in Section 2.2.1 makes it difficult to assess this, but so far as I know, it is extremely difficult to verify, after the fact, that the software running on a computer is the software authorized for use on that computer. Use of a strictly managed chain of custody, as required for the handling of evidence in criminal cases, is about the only viable solution for a complex computer system. There is no reason to believe that self-reported version numbers provide any safeguard against the inclusion of unauthorized software, nor is there reason to believe that a self-check done by a product assures much. About the only way to genuinely verify that the correct version is loaded after the fact is to extract the read-only storage media from which the system runs and compare them with their expected contents using comparison machinery from a trusted source. Use of this model requires extreme design simplicity, and argues against the inclusion of any dynamically configured components, since these make such comparison extremely difficult.

Again, the redactions make it hard to criticize this, but apparently, despite repeated public assurances from Diebold that GEMS servers are not connected to networks, the Maryland centeral GEMS system was. Furthermore, Diebold's Election Support Guide dated October 21, 2002 [leaked to Jim March and available at www.equalccw.com/ElectionSupportGuide.pdf.] makes it clear, in Section 13, item 1 (on page 23) that Diebold was equally happy to have results distributed to the press using LAN connections, FTP transfers, HTTP transfers or "sneakernet" (hand-carried data). Only the latter can be considered secure in this context, and even then, such security can only be trusted if there is a trivial proof that the data transfer is one-way, outgoing only, from the GEMS server. One way to assure this is if only new or bulk-erased disks are ever loaded into the disk drive on the GEMS system, instead of allowing one disk to be alternately loaded on one system and the other.

But, that deals only with one of the paths into the GEMS server. If the GEMS machine serves a pool of modems that are used to make connections with the voting machines at the precincts, then GEMS is already connected to a public network, the telephone system. Depending on how the modems are managed, this is just as dangerous as the Internet, and in fact, it can be considered part of the Internet, because a huge number of computers connect to the Internet using the telephone network.

There are several risks that must be addressed here. First, that an outsider could dial in to the GEMS server and corrupt data on that server directly, and second, that an outsider could dial in to the GEMS modem bank and 'tunnel through' that modem bank to a machine at the polling place, connecting to that machine and corrupting data there. Because the Diebold AccuVote machines at the polling place use the PPP protocol to connect to GEMS, the nature of the PPP server connected to the GEMS machine determines whether this attack is feasible.

Diebold's Election Support Guide [leaked to Jim March and available at www.equalccw.com/ElectionSupportGuide.pdf] offers several options, in section 11.3.2 (page 19) in this regard, and it offers no advice for any of these options for how to configure the modem pool and PPP server to prevent 'tunneling through'. This is a crucial barrier to such an attack. In general, PPP servers, particularly "intelligent port servers" such as Diebold's suggested option 2, are delivered, out of the box, with no effective logging of connections and no effective security against use to establish arbitrary network connections.

Yet again, the redactions make it hard to criticize this, but there are good reasons, in this case, to make such redactions. If the author of a Trojan Horse feature in the software knows the testing that will be applied, it is a trivial matter to design a Trojan that will hide through such tests and only emerge during a real election. The classic Trojan, one I proposed on April 13, 2000 [see E-voting -- Prospects and Problems, presented at the Tau Beta Pi Paul D. Scholz Symposium in Iowa City], and one I am sure is not original to me, is as follows: The illicit software checks the date, and if the date is not the first Tuesday after the first Monday in November and the time is not after 8 AM and before 6 PM, the software lies dormant.

If your adversaries know that the testing will only last 3 hours, they can add a clause, making the Trojan remain dormant until the polls have been open for 4 hours. If your adversaries know that the testing will only involve 20 test ballots, they can add a clause, making the Trojan become active only if 50 or more ballots have been cast. If your adversaries know that the testing will be done by machine, they can add a clause looking for realistic arrival distributions in the votes. There is no end to the options that the author of a Trojan could employ to evade detection during logic and accuracy testing!

This weakness [mostly redacted] is of fundamental importance. The 1990 and later FEC voting system standards have always required that voting systems produce an audit log of key events in the voting system's history (for example, the times of opening the polls, closing the polls, testing, and reporting), but these audit logs are not subject to any kind of routine inspection. They are retained only in case a question arises, so if a crook does subvert the system cleverly enough to avoid an official investigation, even if that subversion is blatantly visible in the audit logs, it will not be detected!

I find this assumption dangerous. There are stories of voters who are so offended by the lack of privacy provided by low-cost booths used for DRE voting that they bring umbrellas to the polls and hide behind them while they vote. Laws in most states makes it illegal for anyone, including a polling place worker, to violate the privacy of a voter while voting, and as a result, the polling place workers avoid standing close or looking closely at what a voter is doing while voting.

Furthermore, in the winter, when many voters will be wearing voluminous clothing, huge amounts of material may be hidden. It is easy to imagine carrying a working computer system and all the hardware needed to subvert the smart-card system of the voting machine under a winter coat unless the election officials are the only ones allowed to touch the smartcards and unless the machine makes some kind of visible or audible signal to immediately attact a polling place worker to the booth when the voter presses the cast-ballot button.

Other Criticisms of the SAIC report

Others have released critiques of the SAIC report. Among them is an anonymous and short but detailed critique that was passed on to David Dill at Stanford on September 25. [See http://www.geocities.com/rubinsaic/.] This focuses on Appendix B of the report, in which the security vulnerabilities detailed in the Hopkins Report are matched against current and proposed state election practices. The author concludes that of the 12 main vulnerabilities in Diebold's software identified in the Hopkins Report, only 4 are definitely repaired by implementing the recommendations in the SAIC study.

The VerifiedVoting.org critique by David Dill, posted September 26, is also interesting. [See Commentary on the SAIC report.] This points out that the redactions to the SAIC report involved deletion of more than half of the text, and it points out that the reference to Trojan horse attacks or Trojans in the SAIC report conflates several different potential attacks, including real Trojan horses riding on third-party components such as printer drivers and window managers, and insider attacks from within the voting system software vendor and attacks from insiders in the state or county election office.

The InfoSENTRY and Compuware Reports

On December 2, 2003, Ohio Secretary of State J. Kenneth Blackwell released the results of the audit he had ordered on August 15, along with a press release ordering electronic voting device vendors to resolve the security weaknesses uncovered in the examination. In addition, he stated that Ohio would request an extension to the deadline established by the Help America Vote Act in order to allow manufacturers time to correct these deficiencies. [See Blackwell Seeks Improvements and Additional Security Assurances from Electronic Voting Machine Vendors, press release, Dec. 2, 2003, Ohio Secretary of State.]

The summary report from Info Sentry Services, 63 pages total, says very little about the voting systems, while focusing on issues of certification and security planning. There is considerable emphasis on business continuity planning for both the state and vendors, on compliance with the state's "Information Security Framework", on the use of Certified Information Security Auditors, security awareness and training programs, Capability Maturity Models (CMM), configuration management, use of the ISO/IEC BS7799 Code of Practice and Management Standard. [See DRE Security Assessment, Volume 1, Computerized Voting Systems, Summary of Findings and Recommendations, InfoSENTRY, 21 November 2003.]

In short, one could caracature the summary recommendations by saying that they are the recommendations of one information security professional working to increase the likelihood that job openings for similar information security professionals will be created in Ohio and in the voting system vendors selling to Ohio!

If there is any technical content to the InfoSentry findings, it is not in Volume 1. I am not aware of any other volumes of the InfoSentry reports having been released. At least Volume 1 has not been redacted, but we can only infer the existance of other volumes from the numbering of the first volume.

As was the case with the SAIC report, however, some of the recommendations disclose huge flaws in state election procedures. InfoSENTRY Recommendations 2 and 3, pages 23 and 24, are of particular importance:

Apparently, in Ohio, as is apparently the case in most other states, incidents that suggest potential weaknesses in voting systems generally go unreported, are not uniformly reported, or are reported to people with no obligation to attend to those reports, and the reports, if they are made, are not currently stored in any uniform way. This systematic weakness means that major flaws could crop up repeatedly without raising any serious questions about the systems in use unless and until outsiders got wind of them!

The Compuware report does not appear to represent part of a larger document. It reveals technical details that were redacted in the SAIC report, in addition to covering not only Diebold's products but also competing products from ES&S, Hart InterCivic and Sequoia. The tables comparing these systems (on pages 20 and 21) reveal some real diversity in the technical approaches being taken by different voting system vendors. [See Direct Recording Electronic (DRE) Technical Security Assessment Report, Compuware Corporation, 21 November 2003.]

The work-flow/process-model flowcharts for these systems given by Compuware are actually useful. I would recommend these to anyone looking for a good third-party description of how these systems work, at a summary level. The threat lists in this report are also useful at a summary level.

There is something superficial looking about the table of "requirements tested and test results" given in the report, but it does confirm many of the security weaknesses identified by the Hopkins Report and confirmed by the SAIC report for the Diebold system. Unfortunately, there are many weaknesses of this study. It appears to miss most of the weaknesses in smartcard use identified in the Hopkins Report; in many cases, if they were unsuccessful in carrying out an attack, they conclude that the safeguards against the attack are adequate. It is not safe to assume that your attacker is no smarter than you are!

In one case, the report sets an incorrect requirement for voting systems:

On the other hand, some of the results of their tests are stunning, for example:

The comments on the security of voting systems provided by vendors other than Diebold (ES&S, Hart Intercivic, Sequoia) provided by the Compuware report breaks new ground. There is considerable information here on the ES&S iVotronic that is not found in the software source-code reviews produced under the FEC/NASED process. I have not had access to similar reports for Hart Intercivic or Sequoia, but it is fair to assume that these are similarly inadequate.

The RABA Report

On January 20, RABA Technologies of Columbia Maryland released their Trusted Agent Report on the Diebold AccuVote-TS Voting System; this came to public attention on January 29, when it was the subject of a New York Times article. This report was commissioned on November 10, 2003 by the Maryland Department of Legislative Services as an independen examination and critique of the Hopkins Report, the SAIC Report, and Maryland's election practices and procedures. [See Trusted Agent Report -- Diebold AccuVote-TS Voting System, RABA Technologies, Jan. 20.]

It is important to understand that this report worked with the State of Maryland's voting system security action plans that were formulated as responses to the SAIC report, and they also referenced the CompuWare report. Their "red team" exercise, attempting to hack the Diebold AccuVote TS and GEMS systems was done on January 19, 2004, after studying (under a standard non-disclosure agreement), Diebold's source code for about a week, and with access to a GEMS server and 6 AccuVote TS machines. Apparently, this study used versions of Diebold's code that included responses to security weaknesses exposed in the Hopkins report, but they do not seem to have stated the exact versions they tested.

The important contributions of the RABA report include the demonstration of physical security problems! It turns out that all machines not only had identical DES keys, but also identical physical keys on the security panels covering the various PCMCIA and other sockets! Not only that, but the locks could be picked in only a few seconds. In contrast, it is worth noting that the locks on classical mechanical lever voting machines are quite resistant to picking. They recommended the use of adhesive tamper-evident security seals can at least help detect tampering with these locks.

Another important contribution is the demonstration, with a laptop computer, of the possibility of arbitrarily reprogramming the smartcards used with the AccuVote TS. In addition, they mapped out the effort required to do this with a PDA, although they did not actually do this. This confirms, very directly, the security weaknesses of the smartcard system employed by the AccuVote TA.

It is somewhat bizarre that they had to read the source code to discover that there existed a class of Security Key Cards that could be used to change the default passwords. These cards pose new risks, because their contents are not secured, but they allow the uniform default passwords to be changed. The RABA report suggests that all of the default passwords be changed immediately using this interface, and that tamper-evident seals be used to secure the interface for these cards. This, of course, creates a massive key-management problem, requiring administrative efforts that the state may well be unable to support without tools that do not exist.

Finally, this exercise showed that the GEMS servers, as currently configured, needed several security upgrades. As configured, these machines were still vulnerable to a serious worm that had spread like wildfire 6 months previously, the Blaster worm, and they were physically configured with no protection against booting from such inconspicuous devices as USB Flash Drives. Physical and procedural measures can clearly lower some of these risks, but there are good reasons to wonder if county election offices can be trusted to keep such machines up to date without considerable assistance.

Their long-term conclusion matches my own: In the long run, we cannot rely on these procedural solutions. We must adopt a defense in depth model, and this will force us to move toward the use of a voter verified paper trail.

10. Consequences

On October 30, 2003, Marc Carrel, Assistant Secretary of State for Policy and Planning for the state of California said that California was halting the certification process for new voting machines manufactured by Diebold Election Systems. The reason given was "disconcerting information" that Diebold may have installed uncertified software on its voting systems, apparently in Almeda County. [See Wired News, Nov. 3 2003: California Halts E-vote Certification]

On November 12, California Secretary of State Kevin Shelly ordered an audit of all California voting systems to determine if there was any software installed without authorization. By this time, it was clear that Diebold had in fact installed uncertified software in the machines Almeda County had used in the October 7 and November 4 2003 elections. [See California Secretary of State Press Release, Nov. 12, 2003] [See Elections Flap Spurs State Audit, Oakland Tribune, Nov. 13, 2003]

The Los Angeles Times quoted Connie McCormack of the Los Angeles election office as saying, in response to this audit: "All of us have made changes to our software - even major changes - and none of us have gone back to the secretary of state. But it was no secret we've been doing this all along." This makes it very clear that election procedures, as carried out in practice, are very careless about following state regulations. If we rely on these regulations to patch security weaknesses in our voting technology, we must demand far stronger enforcement! [See: Secretary of State Orders Audit of All Counties' Voting Systems, Los Angeles Times, Nov. 13, 2003.]

The results of this audit were discussed at the December 16 meeting of the California Voting Systems Panel. Of 17 California counties using Diebold software, all 17 counties were using software or firmware versions that had not been certified by the Secretary of State! The latest version of Diebold's GEMS software certified in California was 117.17; the audit found that the versions in use in the state were 117.20, 117.22, 117.23, 118.18, and 118.18.02. Three counties were running versions that had not yet passed through the FEC/NASED certification process. The complete report of this audit is supposed to be available. [See Minutes, Meeting of the State of California Secretary of State Voting Systems Panel, Dec. 16, 2003. and see Voting Machine Maker Dinged, by Elise Ackerman, San Jose Mercury News, Dec. 17, 2003.]

California is not alone in having widespread use of uncertified voting system software. On February 3, 2004, the chief of the Florida Voting System Certification Bureau, Mr. Kraft reported to the Florida Senate Committee on Ethics and Elections that half of the counties in Florida had been found to have some sort of uncertified election software in use! CD recordings of this meeting are apparently available.

Will congress act on this story? This remains to be seen, but the Congressional Research Service has produced a decent digest of this story, as of Nov. 4, 2003. [See: Eric A. Fischer, Election Reform and Electronic Voting Systems (DREs): Analysis of Security Issues, RL32139, Congressional Research Service, Nov. 4, 2003] Bob Graham introduced the Voter Verification Act in the Senate on December 9, the Senate companion to Russ Holt's bill HR2239, that had been languishing in the House, slowly picking up cosponsors for many months. [See: Graham Introduces Legislation to Ensure America's Votes Count, Senator Bob Graham, Press Release, Dec 9, 2003]

On November 21, 2003, California Secretary of State Kevin Shelly announced that, by 2006, all voting machines used in the state of California must be equipped to provide for a voter-verified paper audit trail. [See: Kim Zetter, E-Votes Must Leave a Paper Trail, Wired News, Nov. 21, 2003. ] In support of this announcement, Shelly posted, on the California Secretary of State's web site, a blunt and strongly worded press release, and equally blunt but somewhat more detailed letters to county election officials, voting system manufacturers, the state voting system's panel and the Federal Election Commission, detailing the new state requirements and what the state wants from each of these groups. [See: http://www.ss.cs.gov/elections/touchscreen.htm the California Secretary of State's web page on Touch-Screen Voting Systems.]

Also on November 21, it was reported that Los Alamos County, New Mexico, had also rescended its earlier decision to purchase direct recording electronic voting machines. [See: Los Alamos Reconsiders Touch Screen Voting, Slashdot, Nov. 21, 2003. ]

Also, on November 21, Congressman and Presidential Candidate Dennis J. Kucinich requested a hearing before the House Judiciary Committee on Diebold's abuses of the Digital Millennium Copyright Act. His request focused on the cease-and-desist letters being sent by Diebold to those hosting copies of Diebold's internal memos or hyperlinks to sites hosting those memos. In addition to asking for this hearing, Kucinich has posted links to some of the key Diebold memos on his web site, thus offering some protection against take-down orders since it is impolitic, to say the least, to attack a congressman's ability to cite copyrighted material. [See Kucinich Requests House Judiciary Committee Hearing on Diebold's Abuses of Digital Millennium Copyright Act, press release, Nov. 21, 2003.] [See http://www.house.gov/kucinich/issues/voting.htm Kucinich statement on voting rights.]

On December 10, Nevada Secretary of State Dean Heller followed California's lead, and announced that all DRE machines purchased for the 2004 general election must offer a "voter verifiable paper receipt". In this, he was encouraged by Senator John Ensign, who had long held that his contribution to the Help America Vote Act of 2002 had been intended to require something equivalent, although in practice, it has not been interpreted that way. [See Secretary of State Heller Announces Direct Recording Electronic Voting Machine Choice, press release, Dec. 10, 2003.]

On December 16, Washington Secretary of State Sam Reed followed suit, although instead of doing it by administrative fiat, he proposed legislation that would require voter verified paper audit trails. [See Reed requires paper audit trail, press release, Dec, 16, 2003.]

On February 4, 2004, Palm Beach County Florida committed to move to a voter-verified paper trail, as soon as this could be made available for their still-new direct-recording electronic voting machines. [See Printers approved for ATM-style voting machines USA Today, February 4, 2004.]

With all of this bad news in the air, Diebold announced on December 18 2003 that it was restructuring its compliance and certification process, and overseen by a compliance and certification officer (a new position). This can be seen as a direct response to the SAIC, Compuware and InfoSENTRY reports, all of which asked that the states demand a greater emphasis on this issue from Diebold and the other voting system vendors. [See Diebold Election Systems Announces Restructuring of Compliance and Certification Processes Diebold Press Release, Dec. 18, 2003.]


Originally posted 7/21/2003; revised, expanded and corrected 7/22.

Section 5 and a table of contents was added on 7/23/2003.

Section 6 was added on 7/25/2003, and vaguely cited dates earlier sections were firmed up.

Section 6 was revised and considerably expanded between 7/30/2003 and 8/1 to reflect shifts in Diebold's response to this story, and a few small errors in Section 5 were corrected.

The names of those present at the Nov 6, 1997 meeting of the Iowa Board of Examiners were added to section 2 on Aug 4, 2003, and quotes from the minutes were added to section 2 on Aug 8.

Work on section 7 began on August 11.

Work on section 8 began on August 24.

Work on section 9 began on October 2.