Some details of Curtis' statements don't check out. West Palm Beach city didn't use touch-screen machines in 2000, something Curtis didn't know when Wired News spoke to him. It was the pregnant chad controversy in that year's presidential election that led Palm Beach county, where West Palm Beach resides, to replace its much-maligned punch-card system with touch-screen machines made by Sequoia Voting Systems in December 2001.But Curtis said the program could have been adapted for use in the counting software used with punch-card machines and optical scan machines, or it could have been used on the new touch-screen machines in 2002, the year Feeney was elected to Congress.Adam Stubblefield, a graduate student in computer science at Johns Hopkins University who co-authored a now-famous report (.pdf) about Diebold's voting machine code last year, thinks the chances that Curtis' code was used in a voting machine are nil."(Curtis) clearly didn't have the source code to any voting machine, and his program is so trivial that it would be much easier to rewrite it than to rework it," said Stubblefield.Stubblefield also found fault in Curtis' statement that any malicious code would be detected in a source code review. This would be true only for unsophisticated malicious code, like Curtis' prototype.Despite Curtis' concerns about statements Yang and Feeney supposedly made regarding election fraud, Curtis didn't tell the FBI or election officials in West Palm Beach about them, even after the 2000 election thrust Florida into the international spotlight.
6 ConclusionsUsing publicly available source code, we performed an analysis of the April 2002 snapshot of Diebold’sAccuVote-TS 4.3.1 electronic voting system. We found significant security flaws: voters can trivially castmultiple ballots with no built-in traceability, administrative functions can be performed by regular voters,and the threats posed by insiders such as poll workers, software developers, and janitors is even greater.Based on our analysis of the development environment, including change logs and comments, we believethat an appropriate level of programming discipline for a project such as this was not maintained. In fact,there appears to have been little quality control in the process.For quite some time, voting equipment vendors have maintained that their systems are secure, and thatthe closed-source nature makes them even more secure. Our glimpse into the code of such a system revealsthat there is little difference in the way code is developed for voting machines relative to other commercialendeavors. In fact, we believe that an open process would result in more careful development, as morescientists, software engineers, political activists, and others who value their democracy would be payingattention to the quality of the software that is used for their elections. (Of course, open source would notsolve all of the problems with electronic elections. It is still important to verify somehow that the binaryprogram images running in the machine correspond to the source code and that the compilers used on thesource code are non-malicious. However, open source is a good start.) Such open design processes haveproven successful in projects ranging from very focused efforts, such as specifying the Advanced EncryptionStandard (AES) [23], through very large and complex systems such as maintaining the Linux operatingsystem. Australia is currently using an open source voting system10 .