Replies

" Perhaps you don't view insider attacks as a real threat, "

With paper ballots, the insider fraud is well established and can be done by almost any group of insiders. Little technical skill is needed, just adherence to simple guidelines.

Insider fraud with electronic machines means much fewer people with the ability to pull it off, and much more chance of being caught.

I've yet to see proof, audited proof, that the Princeton fraud is untraceable, and that was my initial point- they have made scary assertions without any backup, independent analysis, or peer verification. I doubt that someone could add in residue-less code, have it alter the way the system runs, then have it completely remove itself autonomously. You disagree, OK, I respect your point of view, you have some good ideas, but I need to see proof that it is possible.

With a human in the loop, perhaps it is. Some of the projects I'm working now involve testing whether or not a customer has monkeyed with the code. Even with a human to scrub things, detection is highly probable. With no human, relying on autonomous code to cover its own tracks is not a good way to go. There are so many things that change when you diddle with a deep-down routine that it's hard to change one thing back without changing another, or leaving behind a scrap used to delete something else.

I agree that any system should be unhackable, but not all the bulletproof needs to go into code. Procedure and opsec can count as heavily as software.

I agree that any system should be unhackable, but not all the bulletproof needs to go into code. Procedure and opsec can count as heavily as software.

Actually, what's best is to provide hardware that can prove (1) the contents of the media containing all code and election parameters can be write-protected; (2) such media can be read after being write-protected, but before the election, by members of both parties, without actually having to execute code on the medium; (3) during the election, anyone can see that the correct media are being used; (4) after the election, the media can be re-read by both parties and confirmed to be unaltered.

It's trivial to design hardware meeting those requirements. Something like an 80C32 may be a tiny bit underpowered if one wants a nice fancy graphical display (using a processor-based display would add its own issues) but if all the unit has to do is show some canned messages it shouldn't be too hard.

So, for the main unit, include a controllerless LCD, an 80C32 or ROMless equivalent, some buttons, a printer, couple edge connectors, a few glue logic chips (74HC138, 74HC00, etc.). Each plug-in cartridge would simply contain a 128Kx8 flash memory chip, a small glue chip (probably 74C00), two resistors, and a bypass cap, with a multi-segmented card edge such that certain pins could be physically protected aganst access by a removable block. The housing would be constructed of transparent material to allow visual inspection, and would be protected against tampering by seals of all interested parties.

The code storage cartridge would have the /WE pin blocked off (pulled high by internal resistor) and sealed after the code was loaded. It would remain blocked off and sealed until after it was adequately inspected post-election.

The ballot storage cartridge would have one of its data pins blocked off (and pulled to the another's state) in such fashion as to allow byte-write operations to take place (writing 7 bits of useful data) but not allow any sort of erase operations to take place. The glue-logic chip would be used to prevent the use of funny voltage levels to get around that restriction. I don't remember off-hand the exact operation sequences required for writing vs. erasing, but I think this would be doable even with something like a 74HC00.

I could design the whole thing in less than a month. Entirely open code, since there's really not much to it. To get around CPU horsepower limiations, I'd simply keep candidate names as bitmaps and arrange the display code to simply show different bitmaps (stored in non-writable flash) on different parts of the screen. The 8x32 can't run code from anything but the external ROM, so there'd be no danger of someone inserting a fake cartridge, powering the machine up, having the code copy itself to ROM, and then putting in the real cartridge (whose code would not actually be used).

I could do this thing in less than a month. Not a whole lot of bells and whistles, but much more immune to insider tampering than anything Diebold has proposed.

Also, with paper ballots, how can one tamper with those if there is even one honest person who monitors the ballot box continuously until such time as he puts an effective tamper-reistant lock on it, and if all occasions when the box is unlocked in future are likewise monitored by at least one honest person?

To be sure, some places put in rules to prevent honest people from monitoring their election conduct, but that's a problem with the rules, not the balloting medium.