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

Craig Burton caburt at alphalink.com.au
Thu Jul 21 09:28:05 IST 2005


Your post does introduce the myriad weak points in the current system.  
I can't defend them!
You should know I work for an evoting company, but it is pursuing remote 
e-voting to augment postal voting.  Presently, this does not take place 
in the public sector and all pilots I am aware of (except Estonia and 
Spain) have been halted.

I'm pretty sure that one or some of Diebold et al are likely to get 
their systems through in the end, its a matter of what they can be 
forced to change.
I would advocate DRE's carrying no software at all, no hard drive, no 
memory, only the touch screen, power source, audio hardware etc.
The core functionality would be provided in some other way, such as on a 
smart card or better tamper-proof device which can be more easily 
protected and managed.  Each could be a throw-away device configured 
("burnt") for that election and poll place.

I agree the vote transport needs to be different. It has to at least be 
a WORM medium of some sort.
You should not be able to dial into a DRE if there is anything important 
that can be interrupted, observed or changed by doing so.
The tallying machines and staff bribery.   Out of scope for me!

Your point about checksums - can I ask for a link?  I wonder if some 
other code signature would work or whether the hack in question gets 
around code checking altogether.  I suspect the latter; below I suggest 
that any kind of  integrity check has to be performed on the DRE from 
some trusted external service - a dongle, a networked service or 
something else its a self-check. 
Even then, I'm yet to understand how an adequately hacked current DRE 
machine could not report "alls well" to an external source.


cansbro at eircom.net wrote:

>Hi Craig,
>I don't have any objections to the argument that open-source is a safer way
>to develop code.  That's not my point.
>My point is that there is no way to safeguard the implementation of
>code--any code in our current election systems.
>Take the proposed Irish system.  It's now been sitting in various storage
>locations.  There is no way someone could prove to my satisfaction that no
>unauthorized person had access to these machines before or since they were
>put in storage.  So-called security seals have already been shown to be
>ineffective (e.g., broken seals were just ignored and machines were used
>Let's say you ran a checksum.  Well, machines in the US have shown that
>they can be hacked without showing a problem in the checksums.
>Or, the Irish machines could be accessed by modems on the day.  All the
>previous open-source checking would then be meaningless.
>Or, someone could gain access to the central vote counting computer.  Maybe
>they could do this right after a security check had been done. Or, they
>could bribe whoever was doing the checking so they'd use a programme that
>wouldn't reveal the changes.
>There are almost countless points of vulnerability--and open source
>provides no security or answer to these problems.
>Some of the problems could only be revealed by a forensic examination of
>hardware or memory cards.  Do you really think any jurisdiction is going to
>do a forensic examination of all hardware and software for every election? 
>Points have recently been raised at BBV (where horrendous memory card
>exploits have been demonstrated) that show that it's not even enough to do
>a forensic examination of memory cards after an election, but one would
>also have to do the same to some unused memory cards because there are ways
>of tampering that can disappear after use.
>I am a BIG FAN of open source.  And I do not see it as a "solution" to the
>many points of vulnerability in election systems.
>If someone were forcing electronic voting down my throat (ugh) would I
>prefer open source to proprietary code?  Yes.  But either way would still
>make me gag.  Neither option provides any guarantee that votes will be
>counted accurately and reliably free from serious risk of hacking.
>Original Message:
>From: Craig Burton caburt at alphalink.com.au
>Date: Thu, 21 Jul 2005 15:43:50 +1000
>To: e-voting at lists.stdlib.net
>Subject: Re: [E-voting] UK govt circular mentions open-source e-voting
>An incident where someone was able to contribute code to the Linux 
>kernel which had a very subtle Trojan in it is a good example of how at 
>least one OSS acceptance methodology is quite robust.  That is, even 
>though it looks like another hack (a root kit) allowed the contribution 
>of malware in the first place, the use of a proper source control system 
>overseen by a number of people caught this hack in a very short time.  
>It is my opinion that the loose association among contributors to this 
>and other OSS projects has resulted in hardened acceptance mechanisms 
>being more common.   In contrast, I have seen weaker controls and weaker 
>process over access to source codes within private companies where I 
>have worked.   The strength of the acceptance system is possibly assumed 
>to be perimeter security, or that all insiders are trustworthy.
>The media painted the attempted Linux hack as a bad thing, in fact it is 
>a good thing.
>An evoting application could be an open source development in my 
>opinion, with contributions from untrusted sources, if the acceptance 
>and code control mechanisms are good enough.  If the software was then 
>code-audited, compiled and signed by some testing lab this would be 
>better.  But being able to check the signature on the running code would 
>require a trusted supervising application or trusted device and probably 
>network to a common trust party hosting a verification and revocation 
>service.  At least the openness of the development might attract 
>computer science classes of students to pick through the code.
>cansbro at eircom.net wrote:
>>I hope that some folks over there realise that open source is NOT an answer
>>to avoiding election fraud.  
>>There are too many points of vulnerability.  Virtually impossible to ever
>>prove that what was run on a machine was only what was tested/approved. 
>>Too easy to manipulate (e.g. put in a trojan that does its business then
>>removes all trace of itself).  No chance that every voting machine and
>>every piece of software will underdo forensic testing to prove that all was
>>well.  No chance that fraudulent results could be counted on to be
>>obviously fraudulent--in fact, fraud is more likely to avoid drawing
>>attention to itself.
>>I sure hope they wake up over there.  There's problems with a group in the
>>USA trying to promote open source as a solution.  They are ignoring the
>>horrendous problems revealed by recent security tests that show the
>>machines were designed in a way to facilitate hacking through various
>>modalities.  (see blackboxvoting.org for details)
>>Original Message:
>>From:  A.J.Delaney at brighton.ac.uk
>>Date: Wed, 20 Jul 2005 16:22:00 +0100
>>To: e-voting at lists.stdlib.net
>>Subject: [E-voting] UK govt circular mentions open-source e-voting
>>Hey all,
>>We're not an open-source group, yada yada, however this may be of
>>interest to some
>>" E-voting: with the transition to e-voting, political parties
>>or the public might wish to inspect any software used in
>>the process to counter electoral fraud or vote-rigging.
>>Some say that OSS is one possible way of doing this
>>because the source-code is freely available to anyone
>>wishing to scrutinise it."
>E-voting mailing list
>E-voting at lists.stdlib.net
>mail2web - Check your email from the web at
>http://mail2web.com/ .
>E-voting mailing list
>E-voting at lists.stdlib.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.stdlib.net/pipermail/e-voting/attachments/20050721/81d18071/attachment.htm

More information about the E-voting mailing list