Technical Response To The Johns Hopkins Study
MEDIA RELEASE FROM: DIEBOLD "We won't rest."
July 25, 2003
Technical Response To The Johns Hopkins Study On Voting Systems
Diebold is in the process of performing a complete review of the lengthy research article about one of Diebold’s election products, dated Wednesday, July 23.
A prior version of Diebold’s touch screen software was analyzed while it was running on a device on which it was never intended to run, on an operating system for which it was not designed, and with minimal knowledge of the overall structures and processes in which the terminal software is embedded. In addition, many of the weaknesses attributed to the operating system on which the software was tested are inapplicable to the embedded operating system actually used by Diebold. As a result, many of the conclusions drawn by the researchers are inaccurate or incomplete with respect to the security of this particular element of Diebold’s voting system.
The researchers installed and analyzed a prior version of the AccuVote-TS software on a typical personal computer, on which a generally available Microsoft® operating system was installed. This personal computer on which the software was analyzed also had an internet or continuous modem connection, a keyboard, and disk drives. The exploitation of many weaknesses attributed to Diebold’s software resulted from this configuration, which does not exist when the software is used in a Diebold voting terminal.
A continuous or unmonitored internet or modem connection would be necessary in order for last minute or stealth changes to be downloaded to a voting terminal. As installed by Diebold, this voting terminal contains neither. Diebold does not connect its voting terminals to the internet. All downloads to the terminals for purposes of programming take place over a secure connection to an isolated server, to which the voting terminal is generally only briefly connected. Once the changes have been made, the terminal is disconnected, the software tested, the terminal is locked and a tamper-indicating device affixed.
Unlike the personal computer on which the analysis was performed, the voting terminal does not have a standard keyboard or disk drives, and the redundant memory is physically locked into the machine. This makes unavailable the easy access required to accomplish some of the other security breaches that have been suggested.
Similarly, unlike the personal computer on which the analysis was performed, the card reader is an integrated portion of the terminal. This prevents the signal monitoring which, it was suggested, could easily be used to capture the data needed to create a “homebrew” voting card. Further, because the actual voting booths are not the enclosed structures the researchers may be used to, it was inaccurately suggested that it would be easy to use a readily available device to capture the data without detection. The data which would be needed to create voting cards varies from election to election, so creating voting cards would be difficult without access to such captured data.
Similarly, the suggestion that election results would be intercepted and modified during uploading is unrealistic. First, any results transmitted via modem are always considered unofficial results; the official results are transported solely by means of a memory card, which is locked into the system during voting. Any modified unofficial results would not match the official results and would immediately be rejected. In addition, it is very unlikely that any individual would have all the information required to implement such an attack.
Beyond the code analysis, the researchers suggested that Diebold lacked an adequate change control process. Systemic control is in place, both internally and externally. Diebold’s extensive change control process is not embedded in its source code, nor would it be expected to be. In addition to the internal programming group and quality control, the software is tested externally by independent testing authorities. Once delivered to the customer, the software is tested for logic and accuracy both before and after each election. An individual intent on inserting malevolent code, would require the cooperation of the programmers, the quality assurance group, the independent testing authorities, the multiparty observers, and poll workers.
In addition, programmers draft code to deal with party IDs, candidate IDs, precinct IDs, and other generic object identifiers, not individual identified candidates or parties. The actual information associated with these identifiers is entered by individuals in a particular election jurisdiction. Because the specific association between a generic identifier and a particular candidate is not predictable in advance, it would be nearly impossible for a programmer to craft programming to favor a particular candidate or political party without the active cooperation of the individual in the election jurisdiction who formats the ballots. It is extremely unlikely that this kind of cooperation would occur in the first place or, if it did occur, would go unnoticed by the quality assurance group, the independent testing authority, the multiparty observers, and poll workers.
The democratic process is a fiercely held right in the United States, and election officials have long been on guard against mishap and fraud. They have implemented a comprehensive list of safeguards, which protect the integrity of the election process. These safeguards did not end when electronic voting entered the picture, and in fact have been increased. Electronic voting offers an opportunity to make voting more accessible and independent than ever before, particularly to individuals who are sight impaired or who speak another language. To require that each portion of the system be impervious to security breaches ignores security features in place in each other element of the physical system, and the systemic protections in place that extend far beyond the devices on which the votes are cast and tallied.