lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Sep 2004 10:01:59 -0400
From: Claudius Li <aprentic@...tae.net>
To: bugtraq@...urityfocus.com
Subject: Re: Diebold Global Election Management System (GEMS) Backdoor Account    Allows Authenticated Users to Modify Votes


I usually stay comfortably hidden in lurkland but I'm a bit confused. Maybe someone here can enlighten me.

A few years ago I read Bruce Schneiers Applied Cryptography. Everything in the book which I tested or looked up independantly turned out to be true and it enjoyed an excellent reputation in our computer science department.

This book has a whole section on electronic voting. In it, Mr. Schneier lists several thing which we expect a voting system to provide; anonymity, accountability, verifiability, and others. He also points out that there is a theoretical limit to the level to which all of these can be satisfied. That is, we can never guarantee all of them with 100% confidence. This limit seems to extended to all voting systems whether they are electronic, paper based, clay-shards-in-an-amphora, or raised hands.

But we can choose the levels at which we will guarantee each characteristic and get them to levels at which we are comfortable. Mr. Scneier also presented an open protocol using public key cryptography which does just that. It doesn't involve hidden code, it doesn't require an actual physical paper trail and, as far as I know, noone has ever pointed out any flaws in it.

So my question is, given that this seems to be a solved problem why is there so much debate on finding the solution? Surely I am missing something obvious.

	-Claudius Li

On Wed, Sep 22, 2004 at 03:13:41AM -0700 or thereabouts, Mike Ely wrote:
> Alright, I'll bite.  After reading the blackboxvoting.org allegations,
> and your response, I have a few more questions I'd like to see
> answered.  I'll take them point-for-point from your response: 
>  
> > On Tue, 2004-09-21 at 08:05, pressinfo@...bold.com wrote: 
> In-Reply-To: <20040831203815.13871.qmail@....securityfocus.com> 
> >  
> > Diebold strongly refutes the existence of any "back doors" or "hidden
> codes" in its GEMS software.   
> Please explain the purpose of leaving in the apparent debug mode that
> blackboxvoting has described.  If the mechanism described is not a debug
> mode, what does it do, and why would it be in production software? 
>  
> >These inaccurate allegations appear to stem from those not familiar
> with the product, misunderstanding the purpose of legitimate structures
> in the database.  These structures are well documented...  
> Can you please provide a link to this documentation, and perhaps an
> explanation that offers more detail as to why you believe blackboxvoting
> is wrong? 
>  
> >and have been reviewed (including at a source code level) by
> independent testing authorities as required by federal election
> regulations. 
> Leaving aside the question of who paid these "independent testing
> authorities," I would kindly suggest that if there is any mechanism
> which the US public should be allowed to subject to a high degree of
> scrutiny, it would be the mechanism by which we elect the people who
> will be making decisions for us.  There was no question as to how
> punchcard machines worked - anybody with a screwdriver and some
> mechanical aptitude could figure that out in a very short time.  The
> problem wasn't with how they worked; it was how well they worked that
> led to grief.  However, as a voter and a US citizen, I do feel that I'd
> like to have the right to get my own second opinion on your software,
> including any versions certified after the infamous GEMS code leak. 
> Please provide all GEMS sourcecode to the US public for further
> examination. 
>  
> > In addition to the facts stated above, a paper and an electronic
> record of all cast ballots are retrieved from each individual voting
> machine following an election.  
> The key problem here is that this paper record is created >after< the
> election, leaving voters at the whim of any compromise that may occur to
> a given machine >during< the election.  In a paper ballot situation, the
> ballot box sits in plain sight during the entire election, and is
> physically locked at the close of the election.  In the case of your
> system, each voting booth takes the place of the ballot box for the
> duration of the election, and is hidden behind a curtain or partition
> with many anonymous people during this process.  For the voter, there is
> no guarantee that what is being stored to computer memory has anything
> to do with the selections he or she just made, and no paper trail is
> created until often hours after a voter has left the polling area. 
> Without an immediate paper trail being generated, the voter is at the
> whim of whatever software happens to be loaded onto the touchscreen
> computer in front of him or her. 
>  
> > The results from each individual machine are then tabulated, and
> thoroughly audited during the standard election canvass process. Once
> the audit is complete, the official winners are announced.  Any alleged
> changes to a vote count in the election management software would be
> immediately discovered during this audit process, as this total would
> not match the true official total tabulated from each machine.   
> Again, this makes the assumption that the totals printed out of the
> machine after all the voters have left would correctly reflect the
> intent and belief of the voters who used it. 
>  
> Unfortunately, without a voter-verifiable paper trail, it is possible
> for a successful attack to occur.  Without the minimal safeguards
> mentioned above, this attack could go undetected.  Regardless of how
> many votes are compromised, any stolen vote is too many.  Please take
> the neccessary steps to ensure the complete integrety of the US election
> process. 
>  
>  
> > >From: "Jrme" ATHIAS <jerome.athias@...amail.com> 
> > >To: bugtraq@...urityfocus.com 
> > >Subject: Diebold Global Election Management System (GEMS) Backdoor
> Account 
> > >    Allows Authenticated Users to Modify Votes 
> > > 
> > > 
> > > 
> > >Date:  Tue, 31 Aug 2004 00:38:05 -0400 
> > >Subject:  http://www.blackboxvoting.org/?q=node/view/78 
> > >  
> > >BlackBoxVoting.org reported a vulnerability in the Diebold GEMS
> central tabulator. 
> > >  
> > >A local authenticated user can enter a two-digit code in a certain
> "hidden" location  
> > >to cause a second set of votes to be created on the system.  This
> second set of votes  
> > >can be modified by the local user and then read by the voting system
> as legitimate  
> > >votes, the report said. 
> > >  
> > >GEMS 1.18.18, GEMS 1.18.19, and GEMS 1.18.23 are affected. 
> > >  
> > >The vendor was reportedly notified on July 8, 2003. 
> > > 
> > >  
> > >Solution:  No vendor solution was available at the time of this
> entry. 
> > >  
> > >Vendor URL:  www.diebold.com/dieboldes/GEMS.htm (Links to External
> Site)  
> > >  
> > >
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ