[LINK] The Register on vote hacking

[Grant Bayley]

The thing that baffles me here is the fact that everyone's running around
calling it "Internet voting", "On-Line voting" and basically everything
other than "electronic voting".

I can't think of a single reason you'd want to connect any sort of
electronic voting infrastructure to the Internet or even to a
telecommunications network. Ever. The sort of architecture I'd envisage is
something like the following:

At each polling place you'd have a PC with a locked case.  The PC would
have a VGA (video) connector, a USB connector (for a keyboard), a CD-ROM
drive, 2 x hard drives, a Stallion EasyConnection Multiport Serial Adaptor
and a parallel port.  To the PC would be connected a dot matrix printer,
outputting it's information into a locked box akin to a ballot box.  The
computer would utilise a UPS (Uninterruptible Power Supply) in the event
of a power outage.

The PC would boot from a CD-ROM with a stripped down Unix-like operating
system containing drivers for the video card, the USB keyboard (but no
other USB devices), hard drives, the Stalllion Serial Adaptor and the
parallel port/printer configuration.  The scarcity of drivers in this
configuration limits the "on-site" tampering that might be carried out
from the console.  The Stallion device would have as many ports as are
required terminals at the polling place (from 8 to 64).

The hard drives are only used for mirrored storage of incoming vote
information and are not used for the operating system nor virtual memory
swap space. The dot-matrix printer is used for a "last resort" printout
of votes, printing both raw votes and cumulative totals as decribed below.

The reason for advocating a serial-based connection between the polling
place server and the voting terminal is relatively clear:

1) It is an unshared medium for votes to pass across the room to the
polling place server.

2) They provide a way for polling place staff to lock/unlock a
voting terminal.  By default, a voting terminal is locked (ie
fail-closed).  When a voter is marked off on the (printed) electoral roll
in the usual fashion, the polling place attendant visually notes that a
particular voting terminal is not in use and unlocks it with a signal from
the polling place server which travels across the serial connection.  This
signal contains information about what electorate the user is voting in
and hence what candidates names are and potentially what language the
ballot should be presented in etc. The voter proceeds to this terminal and
is asked to place their vote on it.  Once placed, the voter is asked to
confirm their vote as displayed on the voting terminal with a Yes/No
answer.  If confirmed, the vote is transmitted across the serial cable to
the polling place server and appropriately recorded.  If not confirmed,
the voter is asked to amend their selection.  Because the voting terminal
number is not recorded against their entry on the electoral roll (which is
still "on paper"), the ability to correlate a vote from a particular
terminal with a name is nil.  (Question: do we apply a timeout to the
"unlocked" status of the terminal?  Is there a legislative restriction
that would prevent someone from entering the polling place at 9am and not
actually casting a vote until 4:59pm, typing up the terminal all day?
There's an obvious denial of service if you have N devious friends where N
is the number of terminals in a polling place...)

3) Because the polling place server would keep a stateful record of what
terminals are locked/unlocked at any one time only a single vote coming
through on an unlocked terminal is recorded until the polling place
server unlocks the terminal again at some later stage. The serial
connection also provides a means to "rate-limit" data coming from a faulty
terminal or one that has been tampered with (drop the speed to 300 baud?).
A shared medium such as Ethernet provides a much richer featureset that
just isn't required here. (Note: Although we've already specified that
terminals "fail closed", the terminal should be made to ACK the unlock
command upon successful display of the voting options on the screen).

The logging is where things need to be rather creative.  The data as it
comes in is logged to both drives at once.  Given modern hard drive sizes,
the protocol for logging the data should be small enough to fit all votes
for an entire electorate onto the drives of one polling booth (would that
be a reasonable spec, assuming all voters turn up at one booth...?) yet
voluminous enough to record a few variables from each vote:

1) The electorate that the voter is voting for (this means "postals" are
just as quick to tally as "locals").

2) The voting selections for a lower house candidate (incl. preferences)

3) The voting selections for an upper house candidate (incl. preferences)

4) The voting selections for any referendum questions.

The only problem I can forsee is the potential need to separate the lower,
upper and referendum selections into separate entries to prevent statistical
analysis of votes at the level of a single vote even though the vote
itself cannot be linked to any particular voter (ie to prevent "87% of
Labor voters voted "No" on the referendum question"). I'm not sure if
there's any precedent here or even any need to worry. (I'll let LINKers
debate this...)

Each vote is an entry in a database, we'll presume.

Simultaneous to this, the polling place computer is buffering output to
the dot matrix printer.  Every couple of minutes the printer runs off a
page or two of raw vote information.  I mention buffered output to prevent
obvious traffic analysis/comparison with printed votes against individual
voters that may still be in the polling place and also to allow nominal
separation of votes for each house etc as described above if necessary.
The output from the dot matrix printer is going into a locked box, similar
the ballot boxes we're used to.  This information is intended to act only
as a last resort and as a permanent record of the votes (are voting slips
currently held for any length of time?). 

The individual voting terminals are, for the want of a better description,
as dumb as the user interface will allow.  They need to be friendly enough
to cater for for the majority of voters that have no language or physical
disability requirements yet be flexible enough to display multiple
languages, large type etc.  This pretty much rules out VT100's (grin).
Are there dumb-ish terminal devices out there that boot from an internal
source and have a serial port?  I don't know offhand.

At the close of ballots at the end of the day, the computer would be
instructed to display the various tallies for each electorate from which
votes were recorded on screen.  The AEC representative would then relay
this information (presumably by phone - is this how they do it now?) to
the master tally room.  If there was any doubt about the vote, the
printout and the identical hard drives would form the basis for an
analysis/manual tally that doesn't rely on "pregnant chads" or any of the
sort of nonsense that we're seeing in Florida.

(I'll mention at this stage that it would be nice to have all parts of
this system as "open source" to promote widespread peer-review of the
processes, operating systems, hardware platforms and methods)

Please note, my suggested usage of things like printed electoral rolls,
the lack of suggestions about modems dialling into submit results to the
AEC etc are two things:

1) An admission that there's just too many holes that can be poked in such
an architecture.  In short, I don't trust the bureaucrats not to outsource
it (#include <John_Fahey_CSIRO_Joke.h>)

2) A way of placating the legitimate privacy concerns stemming from things
like working out who has voted in what way, etc.

Overall, this isn't about "Internet" or "On-Line" voting - it's about
devising an electronic voting system that doesn't lend itself to obvious
means of tampering, vote stacking, hacking, cracking or whatever people
want to consider a threat.

Would there be value in properly documenting a hardware and software
platform and set of protocols that does this?

Grant

-------------------------------------------------------
Grant Bayley                         gbayley@ausmac.net
-Admin @ AusMac Archive, Wiretapped.net, 2600 Australia
 www.ausmac.net   www.wiretapped.net   www.2600.org.au
-------------------------------------------------------

On Thu, 16 Nov 2000, Chirgwin, Richard wrote:

> http://www.theregister.co.uk/content/1/14767.html
> 
> >Hack the Vote!
> >By: Kevin Poulsen
> >Posted: 15/11/2000 at 18:33 GMT
> >
> >In the wake of the Florida vote-count controversy, simple point-and-click 
> >Internet elections would seem an attractive 21st Century alternative to 
> >traditional cardboard and paper. But before choosing a President becomes as
> >simple as ordering a paperback from Amazon.com, security experts have to
> >surmount an obstacle that makes butterfly ballots look like a cake walk:
> the
> >potential that malicious hackers could create custom programs that target
> >voters' PCs en masse, and steal Internet elections. 
> >
> >"That's the big problem that everybody's working on," says Deborah
> Phillips,
> >president of the non-partisan Voting Integrity Project. "It's that scenario
> 
> >that's keeping people up nights." 
> [snip]
> 
> Yeah, I know, it will happen like it or not...I could imagine myself
> advocating vote hacking just to protect democracy from the technocracy!