Date: Sun, 26 Sep 2004 10:16:09 -0700
From: Nicholas Knight <nknight@...awaynet.com>
To: bugtraq@...urityfocus.com
Subject: Re: Diebold Global Election Management System (GEMS) Backdoor   
 	Account    Allows Authenticated Users to Modify Votes


Jeremy Epstein wrote:

> As someone who's been involved in the electronic voting controversy, I'd
> like to add a few points:
> 
> (1) I agree that source code should be inspected by someone truly
> independent and competent, and that the standards for approving voting
> machines should be stronger.  However, that's NOT the same as open source.
> And I'd strongly discourage folks from calling for open source, as it plays
> directly into the hands of folks like Diebold, who claim that the people
> (like me) who want Voter Verified Paper Audit Trails (VVPATs) are really
> trying to kill free enterprise.  [Yes, I know all the examples of businesses

You might not want to go there, but some of us do, and we're not going
to be cowardly about it. The election system has traditionally, and for
a very good reason, been completely transparent. No part of it was
inaccessible to the general public until Diebold came along. I'm not
willing to settle for a paper trail.

> (2) WRT the web page showing a "Sun server when discussing Windows", I hope
> people realize that web pages for companies are made up by marketing people
> who don't understand the difference.  Don't hold that against them... There
> are plenty of real reasons to oppose Diebold.

A marketing department is something you keep in a locked cage like the
wild animal it is, and whatever it spits out you filter through sane
people before use. A company that fails to do this gets no sympathy from
me, only suspicion.

> (3) WRT requiring that the technology protect itself in case the users
> don't, that's simply unrealistic.  In *any* real computer system, there are
> expectations about the environment (e.g., the administrators aren't hostile
> to the functioning of the system).  It's important to state what those
> expectations are, but there will ALWAYS be some that rely on non-technical
> means.  The important part about election systems is that they be explicitly
> stated, and they be enforceable using non-technical means (e.g., by having
> locks on doors).  The problem today is that some of the assumptions (e.g.,
> the vendor provided software doesn't have any bugs) are clearly unrealistic.

Unrealistic? It is a *voting system*! It does exactly *one* *very*
*simple* thing! If it cannot do it bug-free, its developers are
incompetent and should not be allowed anywhere near a compiler, much 
less the key to democracy.

> (4) WRT getting one set of software approved, and then installing another...
> that's an old problem in any environment.  The way it's supposed to work in
> election systems is that a particular version is approved, and it's illegal
> for the vendor to install something different.  If there are teeth in the
> law, and the vendor can be fined for installing illegal software, then it's

Fined? They should be charged with *treason*.

> Bottom line, election systems are no different than any other systems in
> that the security of the whole system is based on risk management.  While we
> should have higher expectations of election software than office automation
> software, let's recognize what it is.  IMHO, VVPATs are the only real way to
> go.

Paper trails are a safeguard to be used in the event the system doesn't
work, but they're *less accurate* than a *working* electronic voting
system would be. We have an unprecedented opportunity here to count
every vote with perfect precision through electronic voting systems.
Unless every aspect of those systems is open to public review, we're
throwing that opportunity away.

Powered by blists - more mailing lists