Contents
Return to Top
- Background
- What We Already Knew
- What Can We Learn from the Diebold FTP Site
- A Warning
- Some Disturbing Answers
- Rebuttals
- Retractions and Reactions
- Conflicts of Interest
- The SAIC (and other) Risk Assessments
- Consequences
For a summary of this story, as of Aug. 6, 2003,
see .
The Diebold AccuVote TS Should be Decertified.
Return to Table of Contents
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.
Return to Table of Contents
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!
Return to Table of Contents
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.
Return to Table of Contents
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:
- 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:
- Was this software present in the code submitted to the
FEC/NASED certification process or to any of the states?
- If present, was this software included on purpose by Diebold or
its predecessors, or was its inclusion inadvertent?
- If the software was inadvertently included, this would
be evidence of serious quality control problems and
possible failures in the ISO 9000 process.
- If the software was intentionally included, there is the
possibility that the nondisclosure was itself an accident.
If so, this would be evidence of poor configuration management,
a serious quality control problem and a possible ISO 9000
failure.
- If the software was intentionally included, there is also
the remote possibility of genuine fraud, the kind of thing
the conspiracy theorists have come to expect.
- 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?
- 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).
- 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?
- 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.
Return to Table of Contents
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.
Return to Table of Contents
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://www.cs.uiowa.edu/~jones/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!
Return to Table of Contents
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].
Return to Table of Contents
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
- Diebold taking an aggressive stance to correct false
assumptions in Rubin report
- Information blitz to targeted media and customers
- Continued strengthening of processes and security
- Hot states: California (San Diego) and Ohio
- San Diego update
- Ohio update: Approved vendor llist, August 15
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.]
Return to Table of Contents
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.]
Return to Table of Contents
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:
- Apply crytpgraphic protocols to protect transmission of vote tallies.
[Page IV of the executive summary, based on Section 2.1.4 (page 5) of
the report.]
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!
- Require 100 percent verification of results transmitted to the media
through separate count of PCMCIA cards containing original votes cast.
[Page IV of the executive summary, based on Section 2.1.4 (page 5) of
the report.]
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!
- Verify through established procedures that the ITA-certified version
of the software and firmware is loaded prior to product implementation.
[Page V of the executive summary, based on Section 2.2.1 (page 5) of
the report.]
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.
- Remove the SBE GEMS server immediately from any network connections.
Rebuild the server from trusted media to assure and validate that the
system has not been compromised. Remove all extraneous software not
required for AccuVote-TS operation. Move the server to a secure
location.
[Page V of the executive summary, based on Section 2.2.2 (page 5) of
the report.]
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.
- Modify procedures for the Logic and Accuracy (L&A) testing to include
testing of time-oriented exploits (e.g., Trojans). [Redacted]
[Page V of the executive summary, based on Section 2.2.2 (page 5) of
the report.]
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!
- There is no evidence in the public version of the report that
the weakness exposed in Section 2.3.1 (page 8) has been addressed
in the executive summary.
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!
- In section 2.4 (page 9), in the review of the Rubin Report (the
Hopkins Report), it assumed that "the openness of the DRE voting
booth" mitigates some significant part of the report's findings.
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
Return to Table of Contents
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
Return to Table of Contents
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:
- The Secretary of State, working in close coordination with local election
officials, should establish a statewide election information system security
incident reporting structure.
- The Secretary of State should examine the feasibility and cost of creating
a statewide voting system defect and repair database.
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:
- Requirement 1.28: Any data transmitted shall be encrypted over
communication links.
Formally, there is no need for encryption of vote totals when they are
transmitted from the precinct. Classic procedures followed in many states
require that these totals be revealed publicly prior to transmission, for
example, by printing them on paper in duplicate, one copy to be posted at the
polling place, one to be retained with the polling place records. What is
required is not encryption, as such, but rather, authentication, in the form
of a digital signature. A classic way to compute this is to transmit the
checksum of the encrypted data along with the plaintext. A user wishing to
corrupt the plaintext would then need to know the encryption key in order to
compute the correct checksum to go with the modified data.
On the other hand, some of the results of their tests are stunning, for
example:
- Requirement 2.09: The system shall password protect supervisor
functions.
They report: "The Password or PIN used
for the supervisor smart card is the same for all cards by Diebold. It
is a 4-digit number and was guessed on the third attempt, and we
gained access to the supervisor functions on the AccuVote-TS. The
four-digit PIN is a factory default from Diebold and cannot be changed.
(Elsewhere, the report reveals that this PIN is 1111.)
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
Return to Table of Contents
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.
Return to Table of Contents
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.]
Return to Table of Contents|Return to Top
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.
HOME
