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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Sep 2004 03:59:21 -0400
From: Bob Toxen <bob@...ysecurelinux.com>
To: Jeremy Epstein <jeremy.epstein@...methods.com>,
	bugtraq@...urityfocus.com
Subject: Re: Diebold Global Election Management System (GEMS) Backdoor Account    Allows Authenticated Users to Modify Votes


Diebold having "swore up and down" that their closed-source system
is secure and then it's been proven otherwise is exactly why we
NEED an open source solution or go back to punched card/mechanical
solutions.

Open Source in this case does not need to be free source.  Diebold can
get a software patent if they want while still keeping the source
available by audit by everyone.

In answer to the other poster's question as to why didn't Diebold
use Schneier's public methods, I suggest that it was some combination
of arrogance and stupidity.  I've discussed in the past ways to
have cryptographically-signed records originated on each voting booth
device and which travel all the way to the final tallying systems.
The would would stop a LOT of potential tamper points.

Best regards,

Bob Toxen
Author,
"Real World Linux Security: Intrusion Detection, Prevention, and Recovery"
2nd Ed., Prentice Hall, (C) 2003, 848 pages, ISBN: 0130464562
Also available in Japanese, Chinese, and Czech.

On Thu, Sep 23, 2004 at 06:21:03AM -0400, 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
> based on open source, but that's not what this is about.]  As an example,
> Harris Miller, the president of ITAA (www.itaa.org), a politically
> influential consortium of technology vendors, is on record as having equated
> the VVPAT groups with the open source community.  So rather than putting
> your energy into trying to get Diebold et al to move to open source, it
> would be far more productive to put your energy into VVPATs.  Towards that
> end, I'll encourage everyone participating in this discussion to look at
> www.verifiedvoting.org.  VVPATs can give us the assurance we need of
> accurate elections, without delving into the political morass of open source
> and related topics.
> 
> (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.
> 
> (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.
> 
> (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
> a reasonable non-technical measure.  Of course, one could also use things
> like cryptographic checksums to verify that what's installed is what was
> approved.  That still requires non-technical elements, such as that the
> people who ran the checksums weren't deliberately trying to cover up a
> change, the checksums were protected from tampering, the software that
> calculated the checksums wasn't subverted, etc.  [For those of us old enough
> to remember, vendors were required to address this as part of "Orange Book"
> evaluations, and are now required to address it as part of Common Criteria
> evaluations.]
> 
> 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.
> 
> --Jeremy


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ