|
PRO (YES)
Aviel Rubin et al., in their 2003 technical report "Analysis of an Electronic Voting System" (Johns Hopkins University Information Security Institute Technical Paper TR-2003-19, July 23, 2003), state:
"We also saw no evidence of any change-control process [the management process for requesting, reviewing, approving, carrying out and controlling changes to a software product] that might restrict a developer's ability to insert arbitrary patches to the code. Absent such processes, a malevolent developer could easily make changes to the code that would create vulnerabilities to be later exploited on Election Day."
07/23/2003 Aviel Rubin 
Ronald Crane, J.D., et al. write in their 2005 paper "A Deeper Look: Rebutting Shamos on e-Voting" available online at Verified Voting Foundation's website:
"Shamos consistently overestimates the amount of effort required for a dishonest [programmer] to install and operate cheating software...For example, a cheat that moves 1-2% of the votes from one major party's candidate to the other's would be very unlikely to be detected in the vast majority of precincts, as long as it can discern tests from actual voting...
Further, a cheat need not be so unsophisticated as to move a constant fraction of votes. It could observe the voting and move votes only when required, using some sanity checks (e.g., never more than 5% of the votes, never reduce a candidate's total to below some small number, etc.) to avoid triggering suspicions.
...even honest vendors routinely distribute an 'update' to each jurisdiction prior to each election to distribute bug fixes and enhancements. If the voting system uses Shamos's 'ultimate protection against malicious code,' [keeping candidate and party names segregated from the software by presenting them as graphic files] the image-generation program surreptitiously could include the election information."
2005 Ronald Crane
Verified Voting Foundation's Frequently Asked Questions section of their website (accessed 05/01/2007) includes the following entry:
"Testing [electronic voting systems] for security problems, especially if they were intentionally introduced and concealed, is basically impossible. Consider the cute surprises inserted by programmers into commercial software that are triggered by obscure combinations of commands and keystrokes, called 'Easter eggs.' These routinely slip through vendor's quality assurance testing, including the amazing flight simulator that is hidden in Microsoft Excel '97. An Easter egg slipped into a voting program would never be detected. If the Easter egg allowed a voter to modify the votes inside the machine, it could change the whole election."
05/01/2007 Verified Voting Foundation
David Jefferson, Ph.D., posted his July 31, 2005 "Response to the Election Center's Document: DREs and the Election Process" on the website of Georgians for Verified Voting:
"DRE software, and the associated development and distribution processes, should be designed so that attacks are virtually impossible; but sadly, they are not...
Almost certainly 1% or 2%, or in some cases more, of all votes cast nationally on a particular vendor's equipment could be switched without detection, changing the outcome of many races across the country, including even the presidency in a close election such as we had in 1960 or 2000. There seems to unwarranted presupposition that the goal of an attack would be to rig the outcome of some particular election. A much more powerful attack, and one more suited to the vulnerabilities in DRE technology, would be to change the outcome of a large fraction of all very close elections in the nation, without targeting any particular one...
Contrary to intuition of people not skilled in security analysis, making the software ignore the pre-election test or tests and only initiate itself on election day is easy to do...The only kind of pre- or post-election test that would have any hope of detecting a well-designed fraud embedded in DRE code would be a test that looked exactly like a real election to the software, i.e. a test that takes about 13 hours and has the right kind of vote timing and frequency of human errors, the right range and distribution of votes, and had all the other details exactly right. Even with such a carefully-designed test, fraud still might not be detected because cheating could be randomized so that it is not repeatable, and is therefore difficult to distinguish from a timing bug or operator error...
The easiest mode of attack is to tamper with the software while it is in development, or during upgrades, bug fixes, or other software modifications, so that the tainted code is loaded onto the chips through the regular distribution channels. With that kind of attack, one never has to go near the voting machines, or ever set foot in the counties that use them, in order to swing elections."
7/31/2005 David Jefferson
| |
 |
|
CON (NO)
Diebold Election Systems, Inc. released a paper titled "Checks and Balances in Elections Equipment and Procedures Prevent Alleged Fraud Scenarios" on July 30, 2003 on its website as a direct response to the Aviel Rubin et al. paper "Analysis of an Electronic Voting System." The Diebold article states:
"It would be realistically impossible for a malevolent software developer within the company to successfully insert suspect code. Diebold Election Systems has multiple procedural checks against just such a possibility. Making such changes would require a conspiracy among nearly all the developers in the company, in addition to members of the quality assurance group...[A]ny malicious code would not survive the code review process conducted by the independent testing authority. Even if missed by the ITA, logic and accuracy tests conducted by the local and state entities would almost certainly expose any malevolent behavior.
Furthermore, once malevolent code was inserted, it would be discoverable in perpetuity. It simply would not be possible to install software on tens of thousands of units undetected."
6/30/2003 Diebold Election Systems, Inc.
Michael Shamos, Ph.D., J.D., writes in his paper "Paper v. Electronic Voting Records - An Assessment," published in the Proceedings of the 14th ACM Conference on Computers, Freedom and Privacy (2004):
"Insertion of malicious code by the machine manufacturer has two subcases. In the first, the manufacturer delivers software to a jurisdiction with prior knowledge of the ballot layout, candidate names, etc. for each precinct in the jurisdiction. The machine is programmed to behave perfectly before and after the election but to switch votes to favored candidates during the election. Countermeasures [for such a scenario] are parallel testing and keeping candidate and party names segregated from the software by presenting them as graphic files.
In the second subcase, the manufacturer has no foreknowledge of the details of any specific election but distributes master software that causes candidates of a particular party to win all the future elections. The practical possibility of such a scheme is nil...It is not possible to move a constant fraction of votes from one party to another in each jurisdiction without it being obvious that manipulation is going on...
This nightmare scenario, in which a small number of programmers manipulate the politics of the United States by injecting malicious software into voting machines has more in common with spy novels than it does with reality."
2004 Michael Shamos
The Election Technology Council states in the Frequently Asked Questions section of their website (October 2005):
"Before the fact vote rigging [is] difficult if not impossible...The concern that unscrupulous programmers will try to rig elections through deceptive software has led to specific processes and policies to avoid such an event. For example, software code passes through numerous internal and external checks before use in an actual election, including rigorous certification testing by independent certification bodies. Voting system software is engineered months in advance of actual elections, making it very unlikely for programmers to know who candidates will be and impossible to know how their names will appear on ballots. The source code is held in escrow by various state and federal officials, and local officials do not have access to it, thus preventing code changes at the local level."
2005 Election Technology Council
Neil McClure, Vice President of electronic voting machine manufacturer Hart InterCivic, Inc., stated in testimony before the U.S. Election Assistance Commission on May 5, 2004:
"[To] alter cast vote records as they are recorded for some desired outcome, malicious software code specific to a particular DRE must be written that shows the voter one outcome that records another...In order for the attacker to remain anonymous and/or perpetrate the attack, the malicious code must remain undetected or hidden.
The malicious code would need to overcome...thousands of different ballot styles in the electronic ballot definition, not including the differences in presentation created by languages or ballot rotation. While the presidential race appears as the first contest, the order of the candidates and the language used can change for different presentations of the ballot, requiring the malicious code to possess control over these functions.
A common claim is that the malicious code need only search for party name and make decisions on vote alteration based on these criteria. In the case of the eSlate [DRE manufactured by Hart InterCivic, Inc.], when instructed by ballot style to display the party name, the party name is converted to a graphic image...The point here is that the selection displayed to the voter has no reference to the party affiliation in the software code...[T]he malicious code becomes much more complex, thereby increasing its size. As the size of the [malicious] code increases, the ability to hide it decreases."
5/5/2004 Neil McClure
| |