The only way to truly know what is running in a computer at any given moment is to observe its behavior: give all possible inputs, measure its corresponding outputs, and then check to see if the inputs and outputs you observe match the specification.

It is reasonable to ask if computer software is always tested before use, why bother to double-check after the fact? Unfortunately, you really have no guarantee that a given computer program's behavior as measured, say, at 10:00 AM will have any relationship to the same program's execution at noon. Computers have clocks and can tell time, and can easily be programmed to behave differently at different times, on different dates – or under an endless variety of different circumstances.

When it comes to systems processing high-value transactions of interest to potential criminal embezzlers - like money or votes - the inherent limitations of point-in-time behavioral testing make it unacceptably risky. Instead, some kind of computer behavioral monitoring system is required to record a vulnerable system's inputs and corresponding outputs while it is processing critical transactions. This would provide all the information needed to enable a human auditor or another automated auditing system to spot processing errors or manipulation of the transactions. But as I will point out, the inherent nature of voting severely limits our ability to monitor the behavior of voting systems.

Independent inspection and certification of source code has no real benefit. If a malicious insider at Diebold or ES&S truly wanted to corrupt vote tabulation logic, they would hardly put it in the official release handed over for review. There’s simply no reason to trust that any software delivered for inspection bears any relationship whatsoever to the logic that actually runs on voting devices in an election.

Since real-world computer systems involve complex inventories of hundreds or even thousands of application program modules, firmware, device drivers and operating system components, static inspection alone will never be able to reliably determine what those components will actually do at any given point in time. There’s simply no reason to believe that a given executable binary file corresponds to the given source code, and no way to truly know what the executable is doing - except by running it. Static inspection is not a security measure.

If source code inspection could allow us to reliably predict how a particular instance of a program will actually work in the field, Microsoft Windows would be a rock-solid, bulletproof product - after all, tens of thousands of programmers spend their professional careers scrutinizing its source code every day. It’s simply absurd for serious IT professionals to state that it would be anything more than a sham to “inspect” whatever source code a vendor supplies. Worse yet, it misleads the public, making it seem as if IT professionals have the power to “know” the source code is benign, and to “know” precisely what it will and won’t do, and to “know” where and how it is actually running in a particular device in the field - when of course, we do not.

Nor can we test security into software. It is a truism in my profession that the purpose of testing is to find “bugs” - not to indicate that a piece of software contains no flaws. It’s a subtle point, but what it really means is that if I’ve found 100 errors, there is simply no magic oracle that will then tell me “well, that’s all, we’re done, no more bugs”.

If it was possible to test quality - much less security - into any piece of software Microsoft Windows would also be the bug-free, highly secure platform we all know it to be, since Microsoft has the world’s most sophisticated automated testing tools, thousands of paid testers, and hundreds of thousands of people worldwide who volunteer to help. Yet even so several critical Microsoft security defects have been reported every month for the last several years. But not to pick on Microsoft; Secunia, a Danish company, maintains an online listing of security issues in popular software; in every case these flaws were discovered after completion of formal testing. The list itself is currently over 700 pages long.

As socially-responsible professionals we must openly acknowledge the inherent limitations of our ability to ensure voting is as trustworthy as a critical national security system should be. We cannot and should not ask the public to simply trust the outcome of any testing and certification process, no matter how many “experts” say so.

I know that some may at this point draw an analogy between computerized banking and computerized voting. For example, Michael Shamos, a noted advocate of computerized voting, and a long-time consultant to states on the certification of their electronic voting systems has stated:

“ Why should voting systems be held to a standard of perfection when nothing else in society is? Nonetheless, electronic voting watchdogs insist that election equipment must be perfect or it is totally unusable. The analogy between voting systems and the bank is particularly apt because (1) the chance of a system being tampered with successfully is low; (2) even successful tampering does not necessarily result in the wrong candidate being elected; and (3) only a small portion of the vote is cast on one machine.”

Unfortunately, computerized voting and computerized banking actually have almost nothing in common.

One reason why electronic financial transactions are as secure as they are (by which I only mean that embezzlement is the exception and not the rule) is that while financial transactions are private, they are hardly anonymous; you need to prove your identity to all the other counterparties involved. Each counterparty gets and keeps their own independent records of the transaction, all counterparties are strongly motivated to spot discrepancies and compare their records with others, while procedures relating to resolution of financial disputes are legally mature.

Why are voting systems so different? In contrast with banking, voting is both a private and an anonymous transaction. Applying counterparty-based financial auditing mechanisms to voting transactions as they occur would compromise the confidentiality of the vote and voter.

To meet the standards of banking, not only would multiple independent copies of audit records fully describing the voter’s identity and ballot choices need to be generated and shared with multiple parties, 100% of those transaction records would be routinely audited and the results double-checked by external auditors as well as the voters themselves.

Although some computer scientists feel they can maintain both voter privacy and vote count integrity by some magical all-electronic secret internal audit, ultimately there is no reliable means to do so. At the moment of creating the electronic audit record, the computer could be programmed to electronically assert you input “Smith for Governor" even though you actually input "Jones for Governor". Every such all-electronic auditing scheme, no matter how elaborate, would from that point on then simply record a lie with every appearance of the truth.

The only way voters can protect themselves from such a consistently-told electronic lie is with some kind of corresponding tangible, visible record that can be used as a proof you really voted for Jones. Unlike in banking, we cannot give a voter a receipt or a monthly statement; the best we can do is receive from the voter an anonymous receipt that says the equivalent of "Someone Voted for Jones", and then entrust it to the electoral authorities to count (by hand or machine) and to retain for future auditing or recounting.

In voting, on the other hand, only a relative few states routinely audit their paper ballot records (if they have any) and then in only a few percent of the precincts are any ballots checked at all. Yet if a bank audited only a few percent of its accounts - or none at all unless one of their depositors paid for it themselves - its customers would flee, regulators would shut it down, and under current Sarbanes-Oxley legislation, its Board of Directors would face possible jail time.

To its credit the state of New Hampshire has avoided purchase and deployment of the most risky and problematic class of voting equipment: Direct-Recording Electronic voting equipment (with or without a so-called “voter verified paper audit trail”). By legally enshrining a voter-marked paper ballot, whether tallied by people or by machines, as the definitive record of voter intent, New Hampshire is far better prepared than many other states to ensure the integrity of its democratic processes.

 1  |  2  |  3  |  4