Re: Initial thoughts on technical design

From: Alan Dechert <adechert_at_earthlink_dot_net>
Date: Wed Jul 30 2003 - 13:52:37 CDT

- ----- Original Message -----
From: "David Mertz, Ph_dot_D_dot_" <voting-project_at_gnosis_dot_cx>
To: <voting-project@lists.sonic.net>
Sent: Wednesday, July 30, 2003 10:59 AM
Subject: Initial thoughts on technical design
Message-ID: <8175@initial.digest>

> With my technical hat on, I want to propose several design ideas for the
> system. I have not yet had the opportunity to review the FEC
> guidelines, and it is also possible that I have missed something in
> prior discussion and/or on Alan's website or associate documents. So be
> gentle if I am being redundant.
>
A lot of this has been discussed. However, there is a good point here,
namely, that a lot of it is scattered about. Thus, we have enlisted Van and
Ed to pull together a Requirements and Specification for the demo project
(emphasize, "demo"). While the code for the demo will likely be entirely
throw away, these documents will probably be adaptable for the larger
project to develop the production system.

Haven't heard from Van or Ed today.....

...........

> - Security issues should be considered carefully at all levels. But in
> particular, I believe we should try to minimize the disruption caused
> by damage to voting machines at each possible stage. I.e. a machine
> might crash and/or corrupt data before, during, or after the voting
> period; each scenario should be well understood.
>
I have suggested that the voting machine write a log file (not human
readable) to both the harddrive and floppy (or other media) as voting
proceeds. You should be able to unplug the machine in the middle of a
voting session and have it reboot to exactly the same place it was at. I'm
not sure if we need to have this ready for the demo. Mostly, the demo is to
give people the look and feel of what it will be like to vote with our
machine. If it's not too much trouble, we could demo the crash-recovery
scheme.

> - I believe that ballots should contain authentication information to
> provide a detection mechanism if forged ballots are placed in ballot
> boxes (or saved on removable media or transmitted over wires). The
> same mechanism should be applicable to both the paper ballot and to
> the XML data file that contains the ballot content.
>
> The scheme I propose is as follows:
>
> 1. When a machine is "initialized" at the beginning of the voting
> period, it generates a private key (priv) using a symmetric
> encryption algorithm like AES. This key is held internally within
> the machine, and is NOT accessible externally during the voting
> period.
>
Yes, we have proposed something like this. Each ballot will have some
identifying markings on the paper ballot that will be unique to the PC and
run time. Test ballots will be printed and stored when the machine is
started.

> 2. Each machine has a permanent plaintext serial number that is
> printed on paper ballots and stored in XML ballot files. The
> number could be printed on the front of the physical machine if
> desired--i.e. it is public information.
>
I have proposed each machine have a one digit number (combined with state,
county, and precinct, this number would be unique). The ballot number would
be a concatenation of the PC number and a random 3-digit number.

This would give 10,000 possible ballot numbers where the average is about
500 ballots cast on Election Day at a precinct.

It's inconceivable that you'd have more than ten voting machines for one
precinct, although we may want to study the parameters in a little more
detail. Probably, we don't need to get too involved in this for the demo.

> 3. Each time a voter accesses a machine to vote, a random session
> number is generated. This session number should NOT be tied to a
> timestamp in a way that allows reconstruction of voting times
> (since that might be correlatable with individual voters, and
> puncture anonymity).
>
The 4-digit number I described above would be the same as this number you
describe. Right?

> 4. A voter selects a set of candidates and issues according to
> whatever interface is decided on. But basically, these selections
> are just a list of data values from a security perspective.
>
> 5. Printed on the paper ballot and stored in the XML ballot document
> is the following information:
>
> MACHINE-ID
> SESSION-ID
>
I think the ballot number I describe includes these.

> VOTE-SELECTIONS
> HASH = Hash( MACHINE-ID + SESSION-ID + VOTE-SELECTIONS )
> SIGNATURE = E{priv}(HASH)
>
> 6. When the voting period ends, the machine is "finalized", which
> discloses the private key, priv. At this point priv is public
> information--it can be published in a newspaper or generally
> circulated. One private key is disclosed per machine per voting
> period.
>
I'm not sure about this. The voter goes to the machine anonymously. The
ballot number cannot be tied in any way to a specific voter except that the
voter sees it.

Alan
Received on Wed, 30 Jul 2003 11:52:37 -0700

This archive was generated by hypermail 2.1.8 : Wed Aug 06 2003 - 12:50:26 CDT