[E-voting] UK govt circular mentions open-source e-voting

Craig Burton caburt at alphalink.com.au
Fri Jul 22 08:37:51 IST 2005


Marian,
I'm aware of the risks of networking; there are no secure channels, for 
sure.  Any use of the network has to take as wrote the use of PKI, an 
infrastructure for key exchanges (perhaps in training for poll staff) 
and many a priori components.  My suggestion is that the DRE be 
networked as a thin client and boot from a trusted repository of 
software.  Such as from NIST in the US.  In my mind, risky as it is, it 
is less risk than three issues with DREs - they they record votes in 
their dodgy internals; vote transport is physical on delicate media and 
that they each have their own internal, accessible, hackable software.  
This networked machine would be like an EFT card terminal (with a bigger 
screen), not a PC.

Submitting your vote to the central service would provide evidence if 
its being received, for example - not possible with paper.

I see no reason why a networked DRE could not also print a ballot. 

The poll officer currently can't be expected to perform any kind of 
technical tests and the machine should not self-test.  OTOH if the 
machine downloads its software, arbitrary remote tests can be executed 
against that software on that machine.  It would be harder to tamper a 
machine like this as the tampering would need to be occur in hardware 
and then attempt to bypass the downloaded software, but provide the 
answers only the downloaded software would know.

All votes would be asymmetrically encrypted.  Observing the channel out 
of the DRE would not reveal votes but would show the voting session 
ended properly.  Suspect or broken DREs would be detected instead of 
providing bad vote data to the tally.

As thin clients the machines could be more generic and so for any one 
station, some machines could boot up as register machines, others as 
information kiosks and others as evoting machines, all from the code 
repository.

The missing pieces of the idea are the authentication processes by which 
the polling staff would authenticate such machines, themselves /and/ the 
central service.  But I'm sure it can be done.  Whatever process it was, 
it would have to be easily taught to a nonagenarian and it has to place 
poll staff in a position where they are physically needed to 
authenticate the services.  Still, all poll officers get two hours 
training.  It would be easier than what DRE support requires at present:

/The staff responsible for these devices (poll watchers) are usually 
undertrained volunteers, often elderly retirees with little experience 
with electronic devices, much less computers. Overall system management 
responsibility is completely decentralised and has low priority in all 
locations./ -- Lynne Landes et al 2002


In terms of scrutiny, the DRE would simply have less to trust and rely 
on inside of it.  The central service would be attended by all manner of 
partisan geeks, the general public and others.  The DRE could also be 
inspected by third party services knowing its address.  Can I say that 
with paper votes, no individual or even a small number of individuals 
can see all ballots go in the box.  Online they can.

As a double-blind against the central service, poll stations could keep 
one DRE for parallel testing but not tell the central service which one 
it was until close of polls. Then the central service could pull all 
votes from this DRE.  Officials, psephologists, geeks etc with private 
keys willing etc etc. 

Best,
Craig.


Marian Beddill wrote:

> And, dear Craig, I strongly believe that: "....No DREs /should ever be 
> networked/....." if the goal of elections is to have them trustworthy, 
> and to convince the electorate that they are trustworthy. 
>
> Hacking is a fact of life of networks. And the best firewall is no 
> live connection of any type.  Any connection is a gateway, and the 
> slightest twist of even one member of the trusted crews would open the 
> gate to shenanigans.  Even the steps needed to load the election, and 
> to extract the electronic results via any electronic media, are 
> themselves channels for potential fraudulent interference. True both 
> for poll-site machines (DRE's etc) and central tabulators, and any 
> stages in-between.
>
> So there needs to be, imho, a parallel "data channel" directly from 
> the voter to the tally for auditing and verification purposes, and 
> that data must be "human readable without an interface".  For all 
> practical purposes, that means a paper ballot, at the voting site, 
> that the voter sees (or is in a position to see - he might not 
> bother).  Auditing will mean a twin count - one of the digital record 
> (of the whole election, naturally) - the other of the paper ballots 
> (at least a notable random sample of them), with a published report of 
> the double-check. Nothing less can serve.
>
> The previously proposed "VoteHere" system does not meet that criteria, 
> because even if there are two tracks, both are electronic, and need a 
> machine interface to read them, thus there is opportunity for error or 
> fiddling in both tracks.  Anyway, I hear that VoteHere may have parked 
> or downplayed their encryption online voting verification system. At 
> least, they are now pushing a system that track ballots, not votes.
>
> Marian Beddill
>
> At 7/21/2005  09:06 PM, you wrote:
>
>> I actually think VoteHere's solution which provides 
>> proof-of-inclusion over-automates the process.  I still believe that 
>> there could be some adequate mix of human scrutiny and automation.  I 
>> agree no one can oversee a black box.  
>
>
>> I concede that systemic problems of partisan interest, lying, bribery 
>> and so on have to be considered as they have always been there and 
>> always will be - electronic, paper, pebbles-in-urns etc.  Removing 
>> these players from the game isn't the answer.  Instead they need to 
>> be compelled to play fair.
>>
>> Probably we won't agree on whether security or apathy is a bigger 
>> risk.  If no one cares, no one will care about security, but if 
>> everyone cares and somehow the security is rubbish, the elections 
>> will get thrown.
>>
>> With regard to BBV, I refer to their publicity of the Diebold FTP 
>> site early on which exposed the DRE code.  The publicised hack on the 
>> tally database seemed more recent.  It's all good, really.  I'm glad 
>> I'm not them.
>>
>> If you got this far, here is an proposal:   All DREs /should be 
>> networked/.  By this I mean for remote observation by privileged 
>> onlookers, their use of fully encrypted, electronic transport of 
>> votes and their /entire programmable functionality being/ /downloaded 
>> on boot/.  Like lying and cheating, I think DREs are a fact of life 
>> now but isolated, programmable, self-checking machines have to go.  
>> My proposal is to /let in the observers/, centrally control the 
>> software, collect, receipt and confirm vote submissions from (a) 
>> authorised central point(s).  As Ted Selker said : there will only be 
>> voter-verified inclusion when the voter can confirm their vote is in 
>> the central count /while they are still in the polling booth/.   The 
>> scheme would require adequate authentication of poll staff and 
>> machines to the central service and vice versa but I won't try my 
>> luck any further for now.
>>
>> Cheers,
>> Craig.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>E-voting mailing list
>E-voting at lists.stdlib.net
>http://lists.stdlib.net/mailman/listinfo/e-voting
>http://evoting.cs.may.ie/
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.323 / Virus Database: 267.9.2/55 - Release Date: 21/07/2005
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.stdlib.net/pipermail/e-voting/attachments/20050722/78f22455/attachment.htm


More information about the E-voting mailing list