Introduction

My name is John William Washburn. I reside at [redacted]. I have been asked to elaborate on my concerns regarding internet accessible voting machines.

I have been a software developer from 1985 through 1994; first as a Fortran and Pascal programmer and then as a developer of Windows applications and device drivers. From 1994 to the present I have been working in the field of software quality assurance in several capacities. I have also held certifications from the Milwaukee-based ASQ. Software development continued as an avocation and because of this I have written Windows applications in every version from 1.03 to present version Windows XP. I am also fluent in C/C++, Java, Perl, ASP, Visual Basic as well as dozens of other obscure programming and scripting languages. During this time I have maintained an intense interest in computer security as well as software quality.

This should indicate I am not adverse to technology. Still, when it comes to elections in the state of Wisconsin, the system I would prefer is no voting machinery at all except for a good counting scale. Yes, I would like to see people count ballots at all polling places by hand. Aside from being cheaper than voting machines, I believe such a system with counting scales would be both more secure against fraud and more accurate. The counting scale should have a capacity of 20-25 Kg and a resolution between 1 to 3 grams. Such a scale from Rice Lake Weighing Systems costs $1600 with no volume discount. Counting scales have no ongoing programming costs. Calibrating the scale with a tare of 250 ballots takes approximately 1 hour minutes. Using a counting scale allows for permanent paper ballots, the ability to recount manually, and would reduce errors and costs substantially.

The ballot counting would be done by having the local board of canvasser separate out the ballots by candidate, no vote cast, write-ins, and straight party preference. The actual counting of the resulting stacks of ballots is done with the counting scale. The display from the counting scale is the number of ballots on the scale. Tallying then proceeds as outlined in WI Statutes 7.51.

On strict hand counting, I am in a small minority. But, the danger posed by voting machines which can communicate with other devices is significant. In my opinion benefits to election officials, if any, are dwarfed by the dangers arising from testing and security. In both software quality and computer security: Complexity is vulnerability. Any communication path makes software harder to test and harder to secure.

Testability

Communication limits the validity of the testing required under WI Statutes 5.84 on 3 points

1. Machine software must be “frozen” before an election and not altered until the canvasses (local, municipal, county and state) are completed

2. Change detection is difficult

3. Non-certified software has been run

Frozen Code

Such communication capability is sold by device vendors as a positive. The NIC cards, WI-Fi cards, USB ports or disk drives (both floppy and hard) allow the software on the machine to be maintained more easily and more cheaply. I agree with both statements. Communication capability and mutable software is a great benefit to the vendor of voting machinery and the programmer of voting machinery. I contend mutable software is an undesirable feature in voting equipment because there is no benefit to the voting public or to the election officials administering the election.

After the testing performed by a clerk or commissioner, the software tested must be “frozen” and “static” until the election canvassing is complete. The more frozen and more static the software is the better. The goal of voting machinery design is not the convenience of the programmer or to reduce the costs borne by the vendor to create useable software. The goal for using voting machinery is to provide more reliable and more secure election results for the State of Wisconsin.

The Scantron-like systems have the programming “burned” into a card which is inserted into the machine. In order to alter the programming of a machine, I need to burn a new card, remove the card, and replace the old card with new card. This assumes I can “burn” a replacement card ahead of time and the programming on the card works correctly. With communicating voting machines I can upload the replacement code from a diskette, a USB flash drive, my palm pilot via the WiFi, or from my server via the IP address of the NIC card.

Every communications path (Internet, USB port, NIC card, Ethernet, WiFi port, disk drive, smart card, etc.) erodes the ability to freeze the code. This erodes the ability to prevent software upgrades between the time the software was tested and certified and the time polling with the software ends.

Detecting Changes

This leads to the second point: communications paths (Internet, USB port, NIC card, Ethernet, WiFi port, disk drive, smart cards, etc.) erode the ability to know if the software has been upgraded or changed after testing has been completed. Because of this, the clerk may have no way of knowing if the code she/he tested is the same code actually executing on the machine on election day. If you do not know if the software has changed, how do you know if another test is in order?

Uncertified Software

The 2 prior points could be dismissed as the delusions of a voting machine rube. Unfortunately, the voting machinery systems from all 3 major vendors (ESS, Diebold and Sequoia) have been found in other elections and other jurisdictions to be running software at version levels higher than the version certified and tested. For more details on these instances I would refer you to the work of Beverly Harris, Jim March, the California Secretary of State in her committee’s report on touch screens at http://www.ss.ca.gov/elections/taskforce_report_entire.pdf and the Qui Tam and Sacramento suits against Diebold in California.

For software quality: Complexity is vulnerability.

Security

Voting machines with communication capabilities open up the possibility of a new KIND of vote fraud. Classic frauds of the past include: stealing ballot boxes in transit to counting locations, swapping ballot boxes while in transit to counting locations, stuffing ballot boxes, halter voting (Voto de Cabresto) and others. All require access to the voting equipment, the elector or both. Voting equipment which can communicate via TCP/IP, modem or other electronic means, creates the possibility a single person from a remote location can manipulate the results on or substitute new software on many machines. For example, I could remotely rearrange the order of candidate names stored in the executable code or stored on the database. Using the Wisconsin ordering from November 2, 2004 this creates the following changes.

John Kerry	to	Micheal Badnarik
George Bush	to	David Cobb
Micheal Badnarik	to	John Kerry
David Cobb	to	George Bush
Ralph Nader	to	Ralph Nader
Jim Harris	to	Jim Harris
Walter Brown	to	Walter Brown

The software will still record on the database

100 votes for election 1 candidate 1,

100 votes for election 1 candidate 2,

1 vote each for election 1 candidates 3 through 7.

The proposed name change takes up the exact same memory. Thus, this re-arrangement is feasible even in EPROM-based or smart card programming, let alone an MS Access or SQL database. With IP access or other networking access, dozens or hundreds of such uploads are possible and can be done in minutes.

If done at the correct time, the results which print on the tape total would read:

100 votes for election 1 candidate 1 (Badnarik),

100 votes for election 1 candidate 2 (Cobb),

1 vote each for election 1 candidates 3 through 7: (Bush, Kerry, Nader, et. al.).

Absent any other indication, other than your surprise at the will of the voters, these numbers must be accepted as correct according to 7.51(2)(h).

I concede this fraud may be unlikely. But, currently it is only possible if I can corrupt the software “burned” into the PROM and the bogus software counts the first 25-75 ballots correctly in order to provide proper results during the 5.84 testing. Communicating voting machines add the possibilities of remote and real-time tampering to the threat matrix which must be considered.

For software security: Complexity is vulnerability.

Complexity increases the attack surface of a software system. Attack surface is number of points of vulnerability a piece of software presents to the external world or to corrupt/disgruntled insiders. For security the goal is to minimize the attack surface. Communication paths increase the attack surface; not minimize it.

So far I have spoken about malicious changes. There are risks posed by well-intentioned patches and changes. If the patch software is faulty, the machine may stop working. This is because complexity of a system also determines the number of failure modes for a system. If you want robust systems, simple is preferred over complex.

For software reliability: Complexity is vulnerability.

For software quality: Complexity is vulnerability.

Links:

http://www.newscientist.com/article.ns?id=dn4584

http://www.blackboxvoting.org/

http://www.serendipity.li/jsmill/bbv_050119.htm

http://avirubin.com/vote.pdf