I didn't know about this requirement, but it makes sense. Here is why:
A computer doesn't understand the language a programmer writes in. It understands a very abstract language called
machine language composed entirely of numbers. It's very hard for humans to read and write machine language.
Most programs in general use are written in a
higher-level language and
compiled. A compiler is a program that reads the human-written program, and writes a machine language program that should do the same thing. Compilers are standard items, and if you have a bunch of binaries (the machine language program written by a compiler) and the source (what the programmer wrote) you can compile it yourself and verify that the binary in the machine matches the source you were given.
When an language is
interpreted it's not converted into machine language. In olden days it wouldn't be converted into anything; it might be dumped into the machine in straight text form just as the programmer wrote it. That's very inefficient, and most modern interpreters compile their code into an intermediate form called
p-code. As with a compiler, you can double check to make sure the p-code you have matches the source it's supposed to represent.
BUT, unlike machine code, the machine still doesn't know how to run p-code. It depends on another program, the
interpreter, to read the p-code and perform the actions it specifies. Since p-code operations can be very complex, there is much opportunity for the interpreter in the machine to do something other than what it's supposed to do. You generally
don't get the source code for the interpreter, since it's usually written by some company like Microsoft. This makes it much harder to guarantee that the code you are given and which runs correctly in the test machine will do the same thing in the field.
I would note additionally that a complex operating system like Windows offers a similar set of vulnerabilities, for the same reason; the compiled program calls Windows to do many complex things like reading the touchpad, drawing to the display, and recording results to the local mass storage device. If the operating system were compromised -- and you can't tell that without the source code -- then it could apply rules that make it work correctly most of the time, but fail by design to record wrong results in an election. An open-source operating system like Linux would be better, because you can compile it yourself and examine the source code, but it's such a vastly complicated affair that there aren't many experts around capable of guaranteeing its integrity even though it's open. Tabulating votes is a much simpler exercise than being a general-purpose operating system.
Most security experts prefer for systems like this to be developed in an
embedded manner, which is to say with no operating system at all, and the application directly controlling the hardware. That way if you verify the application, you have verified the entire system. Of course this is more expensive, because you can't depend on commodity drivers for video, sound, and touchpad hardware. You can't just pull any commodity hardware off the shelf and incorporate it into your system.
But then again, what is the security of our elections worth? Read the
Risks Digest sometime and you'll see that even devices like ATM's, whose owners care very deeply about their security, have disturbingly frequent problems for these exact reasons. And that's not even given an owner who is out to cheat the machine himself.