Software Rules
Rule 0: Software is not mechanical.
The WIMP (window, icon, menu, and pointer) mode of interaction often convinces us that software has physical reality, with pointers to move, sliders to drag, buttons to push, windows to overlap, and so on. The utter falsity of those metaphors goes unremarked in normal use, because designers expend great effort mimicking what we experience in real life.
The occasional mismatches can be devastating. For example, most people know that deleting a file makes it go away, a few know that the file may subsequently be recovered from the Trash (at least, sometimes), and everyone knows that emptying the Trash makes the file vanish completely. After all, that's what those operations do in real life, don't they?
Perhaps a better metaphor for emptying the Trash would be "putting the can out for curbside pickup by anyone," but it's not clear how to represent that with a glassy icon. Yes, some Trash folders have overwrite-on-delete options, but nobody knows that.
Software's lack of physical attributes invalidates all our metaphors and assumptions. As a consequence, things that should happen don't, things that can't possibly happen do, and our real-world experiences must not guide our assumptions.
Tampering with a mechanical voting machine leaves traces: bent levers, shaved cams, or perhaps filed-off gear teeth. After the fact, a straightforward inspection can reveal that votes were not recorded correctly, and even if you can't recover the correct values, you're aware of the problem.
Attack software running on a voting machine can manipulate the votes during the election, erase itself from both Flash memory and RAM, and leave no trace behind. No examination can find erased software, as nothing remains to be detected: An after-the-vote inspection will show only original, approved, certified software. If the altered vote patterns seem more-or-less reasonable, there will be no reason to suspect foul play.
Rule 1: Software is not visible.
Contrary to the friendly GUI metaphor that lets us think we're in control, we interact with software only on its own terms. Absent any provision for a user interface, software runs silently, invisibly, and uncontrollably.
The user interface of an electronic voting machine won't change after attack software has compromised its function, so simple observation can't detect the problem. Worse, testing the device cannot reveal hidden functions that do not change its behavior. Unless you know what the attack software will do, you almost certainly won't stumble over it through the user interface. You might, if you're lucky, detect anomalous voting patterns.
Conversely, attack software may present an invisible interface of its own: A "secret knock" involving no more than a sequence of taps at specific, albeit nominally inactive, touch-screen coordinates can activate hidden functions. That's not a practical mass-attack interface, but it can activate or control a preinstalled virus on a key machine.
Rule 2: Bad software drives out good software.
Some years ago, I read of an electronic gasoline pump that shortchanged customers by delivering less gasoline than indicated on its LCD panel. Surprisingly, the pump always passed the weights-and-measures inspection by delivering the correct amount to the inspector's 10-gallon can. It simply slowed delivery after 10 gallons, while continuing to tick the digits at the normal rate: If you paid for 20 gallons, you might get 18.
More recently, I attended a meeting that attempted to explain the electronic voting machines that will be used in our local elections. The number of test ballots required for each machine and the manpower required for each election defies description, but it's an effort that seems largely futile: Absent a hardware error, the machines will always produce the expected results during testing.
Testing can reveal the presence of errors that produce deviations from the software specifications, but generally cannot reveal crufty code that's either nonfunctional or is activated by undocumented inputs. Worse, no amount of testing can ferret out attack code designed to remain hidden, if only because of the number of "impossible" input sequences that could activate it.
In the simplest case, attack code can remain dormant until Election Day, move votes from one candidate to another without altering the total number of votes, then erase itself. That would pass every imaginable test administered through the normal UI, while corrupting the election beyond repair.
Worse, after a voting machine has been compromised, it cannot be restored to "factory certified" condition by any update process requiring code running on that machine. Because attack code can gain control during the system's boot process, it can mimic a successful update while remaining in full control.
It should be obvious that the only way to update code on a compromised machine is through a hardware interface that does not execute any code. As we've seen, though, a hardware update socket provides a convenient entry point for an attacker, so overall system security must reside outside the voting machine.
Rule 3: What one programmer can design, another can figure out.
As with hardware, you must assume the attackers are smarter, have better tools, and really want to get inside the voting machine's software. Writing code to compromise ordinary PCs has become a financially rewarding enterprise that attracts criminals, so what can we expect of software that directly affects national politics?
