What Are the Technical Risks in Computerized Vote Counting?

There are many risks in counting votes by computer, most of which are general risks in any computerized transaction which is meant to be accurate, reliable, and secure. However, these risks are magnified in vote counting because the outcomes of elections affect everyone in the district holding the election. In the case of Presidential elections, the result affects (at least indirectly) everyone in the country. So, we must pay particular attention to possible sources of inaccuracy, tampering, and fraud in computerized vote counting systems.

Accuracy and Reliability

Of course, accuracy and reliability must be assured before a computer vote-counting system can be considered for real use. But how can these factors be assured? Voting districts in large cities may have upwards of one million registered voters. As a result, the computer code to count all of those votes is generally extremely long and complex. Anyone whose has written code knows that even a single character error (such as a missing or extra semi-colon) can completely change the semantics of the program. As the amount of code increases, the probability of such an error occuring skyrockets. Egregious errors will be caught in testing, but obscure errors may pass through months of testing, only to appear during the actual election when accuracy is crucial.

Another potential source of inaccuracy is in the computer hardware which runs the vote-counting software. It was a major news story when the first Pentium(R) processors were found to have a calculation error in the floating-point unit. Had an election occurred before the error was found and the votes been counted on one of those machines, even 100% error-free software may have mistallied the votes because the computer hardware's arithmetic was wrong. The potential for problems becomes worse when votes are counted on hardware systems which are not so well used -- a minor arithmetic error in a chip may go unnoticed for months or years, mistallying several elections along the way.

Intentional Tampering

Intentional tampering with computer vote-counting systems opens the door for numerous problems. The general public, as well as most elections officials, are not familiar with the intricacies of writing computer software. So how could they know if the authors of the software or some hacker along the way built a bias into the system? I will describe several possibilities for such an intrusion that would likely not be noticed until after the election has occurred (thus nullifying the usefulness of the vote-counting system) or possibly not at all.

Security Holes

A vote-counting sytem would presumably have some form security ensuring that, on election day, only the elections officials would be allowed access. However, it is unlikely that these officials wrote the software themselves. It is a well-known fact in the computer industry that authors of security systems sometimes add a "backdoor" entry into the system which only they know about. The authors may demonstrate to the elections officials that the system is totally safe and secure, and this may even be verified by a third party. But it is easy to make the backdoor so totally obscure that no one would ever think to try it, save of course the person who put it there in the first place. So, on election day, the author gets to vote as many times as he wants, whereas everyone else gets to vote only once.

Trojan Horses and Timebombs

Another possibility for tampering is known as a "timebomb" -- a portion of the code that only gets activated on the date of the election. Simple timebombs can be easily defeated by setting the date on the computer used for testing to the date of the election. But a more elaborate timebomb could use a number of alternate means to find out the actual date and only activate itself when it really is election day. One possibility would be to scan the entire system to see if the computer's clock is suspiciously far ahead of the most recently modified file. If the system were attached to a computer network, the system could query some or all of the other computers on the network to find out what date they think is correct. A really clever timebomb may only activate itself if the date is correct and the operator holds down (or does not hold down) a special key at a specific point in the software's execution. So, the only way to detect all timebombs would be to reproduce exactly the operating environment of the election day when testing, which may not be possible.

A so-called "trojan horse" could also be inserted which only activates itself on specific inputs. Most systems use punchcards or optical scanners which tell the software whether or not each hole has been punched or each bubble darkened. Most ballot cards are totally general to save on printing costs, and as such just have as many holes/bubbles as will fit on the ballot card, to accomodate even the largest election. A trojan horse could be set to activate itself on only one specific combination of the possible inputs (say to add 1,000 bogus votes for candidate X). On a ballot with four hundred punch-holes, each of which could be punched out or not, the number of voting possibilities is two to the four hundredth power, or a one followed by one hundred twenty zeroes. Thus it would not be even remotely possible to send every possible ballot card through the vote-counting system to ensure that it functioned as expected on each one.

Source Code Inspection

As a response to these issues, many election districts have mandated that all the source code to any computerized vote counting system be put in escrow so it can be examined if allegations of tampering arise. However, understanding code that someone else has written is generally quite challenging and time consuming, even when the code is fully documented. Unfortunately, in an effort to save time, many programmers fail to include good documentation in their code. A deceitful programmer could intentionally leave undocumented a particularly hairy portion of the system's code so that no one else could determine exactly what it does. So even under review by a knowledgeable programmer, a piece of biased code could go unnoticed.

Furthermore, it is possible to tamper with a vote-counting system in such a way that it is not reflected in the source code. Computer software is generally written in textual form so as to be human-readable and human-writable, then converted into machine-readable form (an executable program) by another program called a compiler. Compilers are software programs just like any other, so they have source code as well. A devoted hacker could modify the compiler to automatically insert some of his own code at a specific point in the vote-counting system's executable program, even though those instructions do not appear in the source code. Then each time the system were compiled, the hacker's code would be inserted without any indication to the legitimate author that anything abnormal was occurring.

Such tampering would be almost impossible to detect because there is no evidence of it in the vote-counting system's source code. If such tampering were suspected, the system's executable program would have to be reverse-engineered into assembly-language source code. Since comments (documentation) are not included in executable programs, the reverse-engineered code would have no documentation whatsoever. It is difficult to determine the effect of a few hundred lines of undocumented assembly source, and essentially impossible for a few hundred thousand. Even supposing someone spent the time to figure out what each line does, the hundreds of thousands of lines or more would have to be searched to find the few that alter election results -- somewhat akin to finding a needle in a haystack without knowing whether or not the needle exists at all.

To complicate things even further, the hacker could further modify the compiler's source code to automatically re-insert his changes into the compiler itself, even if they are later removed from the compiler source. This is possible because typically, the compiler's source is translated to an executable program by the previous version of the same compiler. Thus, the human-readable source for the compiler as well as for the vote-counting system itself would show no signs of tampering, but the resulting system would miscount votes according to the invisible changes made by the hacker. This would take quite a determined and knowledgeable hacker to pull it off, but it is certainly not outside the realm of possibility, especially when big industry is willing to pay a million dollars to ensure the outcome of the election is favorable to them.

Return to Start


Last Updated: June 8, 1996