The Case of the Diebold FTP SitePart of the Voting and
Elections web pages |
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 wrote this 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, available in revised form from Bev Harris's web site] The accompanying editorial, by the operators of the 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?] 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.
Prior to the disclosures and debate described above, we knew that Diebold Corporation had purchased Global Election Systems, which had purchased I-Mark Systems, the 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 I saw, when it came before the Iowa Board of Examiners for Voting Machines and Electronic Voting Systems soon after that. 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]
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.
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.
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, when asked about this, 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. 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.
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!
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, 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! This problem was also discussed in my testimony before the House Science Committee. [See Problems with Voting System Standards]
I hope 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, an 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.
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:
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:
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).
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?
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 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.
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. [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 paper by Kohno, et. al, 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 SystemFolks:
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-5823Excerpt 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://www.cs.uiowa.edu/~jones/voting/dieboldftp.html
The Case of the Diebold FTP Sitefor 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 called for decertification of the Diebold AccuVote optical mark-sense voting system. The work done by Kohno, et al, 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 they are fixed to eliminate the security flaws identified in Kohmno, et al.
Originally posted 7/21/2003; revised, expanded and corrected 7/22.
Section 5 was added on 7/23/2003.