Thoughts On Computers In Voting by Douglas Jones, Ph.D.

Reproduced under the Fair Use exception of 17 USC § 107 for noncommercial, nonprofit, and educational use.

| Chapter 2 — Essays On Voting Problems |

| Next — If You Want To Win An Election, Just Control The Voting Machines by Thom Hartmann |

| Back — Perspective On Election Processes by Peter Neumann |

It's election day, and as chair of the Iowa State Board of Examiners for Voting Machines and Electronic Voting Systems , it seems like a fair time to pause and think about the state of the art.

Over the past several years, an important trend has been evident in the voting machines that have come before our board for approval in Iowa. This is the replacement of custom-built software with off-the shelf commodity software, usually some variant of Windows and largely dependent on Microsoft Office.

Computers in voting machines are old technology at this point, whether they're used for central count systems based on punched cards or mark sense readers, or whether they're precinct count systems based on mark sense or direct recording electronic voting machines. There are still lever machines in use, of course, but those haven't been changed in years and therefore, we don't see them coming up for examination.

Under the current Federal Election Commission (FEC) guidelines for electronic voting systems, all custom-built software is subject to examination by an independent third party. On the other hand, "industry standard components" are acceptable, as is. The FEC has no enforcement power, but the FEC guidelines have been enacted into the voting law of numerous states.

The reason this concerns me is that we see a larger and larger fraction of the software inside the voting system becoming proprietary product of a third party and exempt from the requirement that it be available for a source code inspection. Furthermore, the size of commercial operating systems is immense, so an effective inspection is very hard to imagine!

What threat does this present?

Top

If I wanted to fix an election, not this year, but four years from now, what I might do is quit my job at the University of Iowa and go to work for Microsoft, seeking to insinuate myself into the group that maintains the central elements of the window manager. It sounds like it might be fun, even if the job I'd need would largely involve maintenance of code that's been stable for years.

My goal: I want to modify the code that instantiates a "radio button widget" in a window on the screen. The specific function I want to add is: If the date is the first tuesday after the first monday in a year divisible by 4, and if the window contains text containing the string "straight party," and if the radio buttons contain, at least, the strings "democrat" and "republican," one time in ten, at random, switch the button label containing the substring "democrat" with any of the other labels, at random.

Of course, I would make every effort to obfuscate my code. Obfuscated coding is a highly developed art! Having done so, what I'd have accomplished is a version of windows that would swing 10 percent of the straight party votes from the Democratic party to the other parties, selected at random. This would be very hard to detect in the election results, it would be unlikely to be detected during testing, and yet, it could swing many elections! [For an example of this happening see Franklin County, Indiana, in November 2004 election.]

This is just one example attack! There may be similar vulnerabilities, for example, in the off-the-shelf database packages being used for ballot storage and counting.

I don't mean for this example to reflect any ill feelings toward Microsoft, but it is true that their software is used in the vast majority of new voting systems I've seen. This threat does not require any cooperation from the vendor of the window manager or other third party component exempt from source code inspection. All it requires is a mole, working their way into the vendor and producing code which is not detected by the company's internal testing and inspection. Obfuscation is easy, and the art of the "easter egg" in commercial software makes it very clear that huge numbers of unofficial features are being routinely included in commercially released software without the cooperation of the software vendors. (OK, I know that some easter eggs are officially approved.)

Having said this, it is worth noting that Microsoft has indicated a preference about the outcome of today's presidential election, and there are excellent reasons to treat proprietary software produced by a partisan agency with great suspicion when it is included in a voting system!

My conclusion? The time has come for computer professionals to press for a change to the guidelines for voting machines, asking that all software included in such machines be either open source, available for public inspection, or at least open to inspection by a third party independent testing authority. There are no technical obstacles to this! Linux, Free BSD and several other fully functional operating systems are available and will run on the hardware currently being incorporated into modern voting machines!

But, this is not the end of the problem! How do you prove, after the fact, that the software in the voting machine is the software that was approved by the board of examiners and tested by the independent testing authority? No modern machine I'm aware of makes any real effort to allow this proof, although several vendors do promise to put a copy of their source code in the hands of an escrow agency in case a question arises. [See Marion County, Indiana, November 2003 election for example of ES&S using unapproved software and then switching.]

Top

| Chapter 2 — Essays On Voting Problems |

| Next — If You Want To Win An Election, Just Control The Voting Machines by Thom Hartmann |

| Back — Perspective On Election Processes by Peter Neumann |

Last modified 6/14/09