Field Validation of Voting Systems
From Trust The Vote
"How do I know that this voting machine is the right one?" is a key practical question in voting systems technology. (For "right", you can substitute any number terms: good, trusted, trustworthy, certified, L&A-tested yesterday ...).
The term "Field Validation" is sometimes used to address this important concept and practice for voting devices, as a term for a requirement: people should be able to answer that question, by performing field validation of specific devices. A more techie form of the question is: how do I know that this voting device is running the software that it is supposed to be running? That's an important question for a number of reasons including trust and law. The legal issue is that in most U.S. states, it is only "certified voting systems" that are legal to use in government elections -- and a key part of a voting system is the voting devices used by voters and election officials, such as optical ballot scanners, electronic ballot marking devices, ballot tabulators, etc. Certified systems are those that have completed a regulatory review process that is supposed to determine if the voting system and all its components (including voting devices) meet standards for required functionality, reliability, etc. So, a certified voting device is supposed to be running only one exact set of software, that was subjected to review and testing in the certification process.
Contents |
Validation is Partly a Trust Problem
The trust issue is we should only only trust specific certified software to operate a voting device. Any other software could be doing literally anything, including inaccurately recording ballots and votes.
So how do you tell whether a specific device is running a specific set of software, and nothing else? That is the "field validation" problem.
For current voting devices, this is a hard problem, for a number of reasons including one that should be familiar from usage of your typical PC. To examine all the software on the computer, without actually running that software (you can't rely on unknown software to examine itself and report truthfully), you have to run some *other* software on the physical device -- validation software -- that examines every part of the hardware that can contain software, and compare that software to a known baseline, to seek an exact match to that baseline. If that baseline is complicated, then so is the validation software. And if the baseline is proprietary information, then the validation software is proprietary too. If the baseline is unknown (as fr a typical PC, alas for some voting devices) then you can't validate at all.
And then there is validation software -- we have to ask, why do we trust the validation software? (Quis custodiet custodies, who watches the watchers?)
Simple Baseline, Easier Validation
For OSDV's voting system components, field validation is a much simpler proposition, because of a simple architecture feature that's different from most PCs (and current voting devices), but similar to the well used methods of "software appliances." Here's how it works. A voting device in action consists of two parts: read-only boot media that contains the entire bootable system image for the device; and commodity hardware that runs the system image, but doesn't contain any data needed for the system to run. Unlike your typical PC, the internal hard drive starts out empty, and is only used for "scratch space" by the running software.
So what is the baseline, and what is the field validation software? The baseline is simply the entire contents of the boot media. A certified system will consist of a number of different boot images (for various devices), and each one has a unique checksum. To tell whether you are about to start running a certified device, you need a list of the certified checksums, you need the ability to compute the checksum of a boot disk in hand, and you need the ability to compare the just-computed checksum with the correct checksum on the list of certified checksums.
Validation: Chicken and Egg
The next question of course, is how do you re-compute the checksum of your boot media? With a computer and software, of course, which raises the same question of how you should trust that software. That question can quickly get us into theoretical chicken-and-egg-itis, but here is a way that it might work in practice. First, the baseline checksum should be performed using a common standard algorithm, such as SHA-1, which has multiple different implementations, including open-source ones. The field computation should use one or more such common SHA-1 software implementations, running on one or more standard PCs.
Of course, we still haven't completed eliminated the risk of the PCs having been compromised by malicious software, or the SHA-1 software being malicious, and the boot image being malicious, all conspiring to report the correct checksum for an imposter boot image. But we have raised a high bar for this conspiracy, especially by using multiple different computers and checksum software implementation. The cheapest way to overcome that bar is with corrupt election officials performing the field validation check - but once we are considering "insider attacks" there are a lot easier ways to rig a system.
If you want more assurance than using potentially untrustworthy PC systems and software, you could instead boot a PC off a boot medium for a system that is trusted to accurately report and compute a SHA-1 checksum when you give it some removable media such as the boot media for a voting device. Of course, you now have the chicken-and-egg problem of gaining the basis for trust in that checksum-making system's boot image. At some point you always end up there, and manage he situation with physical, procedural, and people security measures.
Summary
But getting back to the main idea, this is not rocket science by any stretch of the imagination. We have a system architecture that was defined with ease of field validation in mind (among other beneficial properties). The result is straightforward: the baseline is established as part of the certification process, and the field check is based on testing one physical artifact for a match with the established baseline.
