See my preliminary design in block diagram form here.
A study has been done by Princeton on the Diebold machines, you can read the whole thing here.
As a professional in the field, here is my opinion.
I'm not happy to say it, but the Princeton study is correct. The Diebold machine can be hacked if it operates in the manner they have described. The fundamental flaw in the design of these machines (which Princeton doesn't talk about), is that that vote recording is done under software control.
The Diebold unit is essentially a PC'ish type machine using ordinary memory technologies(Flash, DRAM, etc) and a general purpose CPU running Windows CE.
Whenever you have something under software control, where the software isn't running out of a mask programmed ROM (or 1-shot non-erasable EPROM) there is going to be the chance of a hack. This is particularly true if the software is allowed to do the counting rather than special purpose counting hardware that isn't alterable via software.
What is needed is a different hardware design. One where the general purpose CPU and software are only capable of providing display information to the voter. To beat the possibility of a hack, it is absolutely necessary for vote casting and counting to be a dedicated hardware function that uses a completely independent bank of hardware accumulators and vote buttons that the CPU and software have no physical connection to that would allow for a change.
It is essential that the CPU and software have no hardware mechanism to read/query the selection status of the hardware registers contining the pending ballot selections.
The only thing the CPU/software should be allowed to do is setup the selection criteria for a particular screen full of candidates. By this I mean the the voting buttons that correspond to candidates or initiatives would need to be put into a mode allowing for mutually exclusive selection(a normal race), or a multiple select mode(approval of a slate of judges) for any particular screen full of vote stuff.
The CPU/software must only know of the mode the vote buttons are to be configured to and nothing else. Pure unhackable hardwired logic gates must handle the operation of the buttons and vote selections (I'd be willing to allow for a small mask programmed single chip microprocessor like something in the Intel 8051 family of microcontrollers).
Key design point -- the logic(or microcontroller) handling counting and voter button presses, must be COMPLETELY OBLIVIOUS to anything other than button presses and counting. It MUST NOT be aware of anything associated with what those presses and counts map to. Obviously, that logic or microcontroller must be unalterable in the field (mask programmed at the factory) and soldered down.
The CPU/software can set the logic/microcontroller's mode for a vote, but it won't be able to see what was recorded or alter it.
What I've outlined here is a major architectural change in the way these voting machines have been designed in the past, but it is a necessary change if absolute integrity is to be guaranteed.
This crap Princeton described of passing memory cards around with software that automatically loads, and vote counts on them is completely bogus.
The only way you should be able to suck the votes out of a machine is by pluggin a specialized vote sucker device into a port hooked up to the tally logic/microcontroller. You want dedicated counting hardware to say what its vote count was, not some general purpose CPU like in the Diebold machine. The Diebold architecture is fundamentally flawed.