All excellent information, and well reasoned. However, I take issue with the 100% requirement for paper ballots. It is concievable that PKI infrastructure be used for a verifiable electronic-only voting system... Assuming every citizen had their own key pair.
The situation would be analagous to GPG-encrypted e-mail... albeit with truckloads of extra security measures (some regulatory, some electronic). I'm not saying it would be easy... just possible. --tim On 4/14/06, Jack Carroll <[EMAIL PROTECTED]> wrote: > Rather than try to recap everything I've been doing for the last > year, let me point you to www.democracyfornewhampshire.com. We have just > succeeded in passing a law to permanently outlaw vote recording machines in > New Hampshire. Ballot counting machines are still allowed, but all recounts > must be performed "without mechanical, electronic, or optical devices". > Our Secretary and Assistant Secretary of State are two of the top > experts in the country on how to run an honest election, and the state > legislators I've met are pretty knowledgable too. Some central principles > have become generally accepted after much discussion. > Two key ideas: > 1. A tamper-proof election requires durable paper ballots, which the voter > can directly verify as a correct expression of the intended votes, before > handing it in to the ballot box. The election officials see the marks in > the voter's own hand, without any possibility that some device might have > corrupted them. > 2. Recounts can be conducted as many times as necessary, until everyone is > satisfied that the result is correct. New Hampshire election results are > verifiable. It's not enough that they're correct -- they're _provably_ > correct. > > There's none of this baloney about a "voter-verifiable paper trail". > There's the voter-marked ballot, and nothing else. Keep it simple, keep it > visible. > _Everything_ about New Hampshire elections is done in the plain > sight of the public. The statutes are extremely explicit about the > procedures to be followed, to ensure ballot security while making everything > public and verifiable. > > Now, I think there's a place for open source software in ballot > counting machines. A provably correct ballot counting machine can save > enough labor to justify solving the formidable problems involved. But > there's a lot more to it than just opening up the firmware source code to > public verification. For one thing, the hardware has to be provably > correct, both at design time and at run time, otherwise correct firmware > means nothing. > Here's how I'd go at it. > Start by putting a state regulatory agency in charge of approving > standards and specifications for the design of vote recording machines. > Harvest ideas from other regulatory agencies that approve safety-critical > hardware and software, such as Underwriters Laboratories and the Federal > Aviation Administration. From UL 372 I'd take fail-safe design and formal > Failure Mode Effects Analysis. This means that every physically possible > failure of any component must be either analyzed or tested, and formally > shown to result in a safe condition -- which means that it can't cause > an incorrect result without giving clear indication that it has failed. > >From RTCA/DO-178 and RTCA/DO-254 I'd take structured engineering discipline, > which is extremely painful to follow, but demonstrates exhaustive logical > proof that the hardware logic and the firmware is free of errors. > Divide the development into clear phases. First, the writing of > regulatory rules and the adoption of standards and specifications. Every > decision the state regulators make must be done through rulemaking actions, > which means publishing a public notice, allowing sufficient time for > comments and testimony, and then making the decision. > Next, requirements capture. Do surveys and hold hearings to > determine the required functionality and features. > Then, compile and issue a design specification. After that, invite > bids from engineering firms for the design work, and issue contracts for > design. > Now, here's the real key: the state board approves all Engineering > Change Orders through its rulemaking process. Before any drawing can be > approved or revised, it must be put into the public record and published, > and the board must announce the proposed ECO as a rulemaking action for > public analysis and comment. There must be _NOTHING_ in a piece of > electoral equipment that is hidden from public knowledge and criticism. > That principle is fundamental to squashing conspiracy theories. Will that > slow things down? Oh, yeah. It would probably add a couple of years before > a full set of drawings would ever get signed off. But we only need to get > one design approved, and its service life would be measured in decades. > Only when a complete set of drawings has been approved after public > hearings would the state invite bids to actually manufacture the hardware. > As for the firmware, its source code would also be in the public > record and approved by state ECO, but it doesn't stop there. The complete > tool chain should also be open source, both source and executable, and the > build process should be performed on isolated, state-owned computers. The > source and object code of everything would go into the public record, and be > placed on line with the Secretary of State's electronic signature, so that > anyone could perform the build process independently, and verify it. The > Secretary of State's office would distribute the executables as certified > copies in the form of OTP EPROMs, which the machines would execute directly > from the ROM socket so that there would be no possibility of internally > stored copies doing something different from the official approved source > code. The EPROMs would bear handwritten signatures, certifying > authenticity. They would be delivered along with the ballots by trusted > courier, with documented chain of custody. > The configuration file that sets up the machine for a particular > election should reside in a separate OTP EPROM, so that executable code > couldn't be tampered with. It should be a plain text file, in a publicly > documented format, with the original in the public record and a verifiable > distribution procedure. > There's more, but you get the idea. > > As for vote recording machines, the only justification I can see for > one is to allow a blind voter to cast a ballot without taking an assistant > into the voting booth (see RSA 656:20, if I remember the statute correctly). > Here's my reasoning: if we accept as an absolute requirement for > election integrity that every vote must be recorded as human-readable marks > on a durable paper ballot, and in no other form, then no device, no matter > how complicated, can save either the voter or the election officials any > time, compared to marking by hand with a pen. And the pen is orders of > magnitude cheaper and more reliable than any other device that could perform > the same function. Therefore, for any voter who can see the ballot, > developing anything to replace the hand-held pen is an absolute waste of > money and can only introduce possibilities for malfunction and tampering > that otherwise would not exist. > Theoretically, a vote recording device might be considered for the > exclusive use of blind voters. However, once a ballot goes into the box, > there is no possibility of detecting a recording error and recovering from > it. Therefore a device like that demands extreme reliability and resistance > to tampering. To guard against an undetected error, there should be a > completely separate device to read the marked ballot back to any voter who > can't see the marks. > It's apt to be horrendously expensive to develop, and the population > needing it is very small. The cost effectiveness is dubious, to put it > mildly. We in New Hampshire are notorious for insisting on thrifty and > cost-effective use of our tax money. > But, maybe that problem could be solved without some complicated > computer-controlled whizbang. How about a molded plastic template to hold a > ballot, with guide holes identified by Braille letters or numbers? The > voter would play spoken instructions on a common, off-the-shelf audio > cassette recorder, which would identify candidates and propositions with > particular guide holes. The blind voter would then mark the paper ballot > with a pen, the same as anyone else. > > There's one place in all this for conventional open-source software > running on off-the-shelf hardware, though. An unofficial count. This is my > one original idea. > NH law provides for election inspectors from the opposing parties, > who are part of the official ballot counting team. They might be permitted > to run the ballots through a privately owned scanner, for an unofficial > count using hardware and software completely independent of the approved > design. It wouldn't be eligible to be certified as the official result, but > it would serve as a quality control check on the counting process. That > gives the parties a rational way to decide when to spend the money for an > official hand recount. In effect, that wraps fault tolerance around the > outside of the whole process. > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
