Thoughts on Computers in Voting

Posted on Tue, Nov. 7 2000 at 16:43:41 CST by
Douglas W. Jones
from the University of Iowa, Iowa City, Iowa, in

comp.risks Volume 21: Issue 10

Indexed on the web at

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 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?

If I wanted to fix an election, not this year, but 4 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 November] 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 10, 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 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!

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 to 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? [I think that] 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 [open source] 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 excrow agency in case a question arises.

[Note added by Peter G. Newman to the comp.risks posting:]

Rebecca Mercuri is just putting the finishing touches on her PhD thesis on the subject of electronic voting, at the University of Pennsylvania. I highly recommend you contact her for a copy, which should be available very soon. For everyone else, we will announce it here when the thesis is ready. Also, my book *Computer-Related Risks* has lots of background on risks in electronic elections and what to do about them. Rebecca has carried the analysis much further than I did. Her thesis will be a very valuable contribution that significantly raises the bar as to what should be demanded, not just hoped for, plus an analysis of the residual risks that would still remain.

Note added Nov 8, 2000: Words above in square brackets were added to this web page and are not part of the original risks posting.