[LINK] [UK] Call for e-voting to be scrapped amid security fears

[Craig Sanders]

On Wed, Jun 27, 2007 at 08:19:21AM +1000, Rick Welykochy wrote:
> My comments were aimed squarely at the e-voting work station itself.
> My guess is that this software in particular is not rocket science.

it's not only the hardware - software that behaves well under light
to moderate loads can do really strange things when put under a heavy
load - and in voting situations, you often get insanely heavy loads in
a short period of time (e.g. polling booths might be open from, say,
8am to 6pm...but almost all voters might actually come in between 10am
and 4pm. warning: made up example ONLY, not to be mistaken for actual
real-world data)



> The problem of aggregating all the results from myriads of work
> stations in a secure, reliable and timely fashion is a different one
> (imho) and was not mentioned as a source of problems in the original
> article.

aggregation of results isn't really the problem, that doesn't have to be
real-time and isn't even particularly difficult anyway. it can be done
after the election is over. 

it's taking the votes, which has to be done in real-time while the voter
is there in the booth (or online), that is the tricky bit.

and remember, it's all encrypted - so higher CPU utilisation for each
"page", and no caching (so higher bandwidth).


> >even considering the quality of their system and the integrity of
> >the people in the company, i'm still very much against e-voting. the
> >risks are too great, and the benefits too trivial....at least for
> >government elections (their system is also used for union ballots and
> >shareholder votes etc).
>
> Out of curiosity, what OS and platform was used for the system you
> worked on, Craig?

linux (initially RHEL, but one of the reasons they hired me was
to convert their servers over to debian. also for my expertise in
load-balancing), apache, perl, java (incl. some really neat java crypto
stuff).  LVS load-balancing. mysql clustering. heartbeat failover.
probably other stuff ive forgotten.

the only thing i didn't like about what they were using was mysql
- without triggers and stored procedures (partially - and poorly -
implemented now in recent mysql), you have to rely on the application
code to implement your audit trail, rather than have the db itself do it
whenever a record is updated (i.e. with triggers, you can set it up so
that any time a record is created/deleted/updated, the event is logged
in an audit log table).

IMO, trusting the application layer to do that is akin to trusting a
burglar NOT to walk in through a wide-open door when they can see a
large pile of cash free for the taking.




overall, their software is good and i'd say as secure as any e-voting
software is likely to be. i still wouldn't want to trust the elections
of the country i live in to it. not because there's anything wrong with
their software but because it just isn't worth the risk.

manual counting, as done in australia, has the unbeatable advantage of
many eyes (from ALL interested parties, rivals and opponents of each
other) scrutineering the results. you just can't replace that kind of
audit/security with a bunch of computers and a handful of geeks.

craig

-- 
craig sanders <cas at taz.net.au>

Except for Great Britain. According to ISO 9166 and Internet reality
Great Britain's toplevel domain should be _gb_.  Instead, Great Britain
and Nortern Ireland (the United Kingdom) use the toplevel domain _uk_.
They drive on the wrong side of the road, too.
		-- PERL book (or DNS and BIND book)