Re: Important Voting System Report

From: David Jefferson <d_jefferson_at_yahoo_dot_com>
Date: Fri Dec 05 2003 - 14:14:58 CST


Would you mind if I forward this message to David Dill's list (which I am pretty sure
you are on)? Or maybe you'd like to post it yourself.


--- "Douglas W. Jones" <> wrote:
> The State of Ohio, responding to the report from Johns Hopkins
> about
> security problems with Diebold's DRE voting machine, asked two
> companies
> to do independent audits of the voting systems approved for
> use in
> Ohio. Of these two, one is near worthless, but the other is a
> treasure
> trove. I recommend the Compuware report:
> I recommend it for two separate features:
> 1) It contains work-flow/process-model flowcharts and other
> top-level
> descriptions of 4 competing voting systems. This is the
> first
> head-to-head "consumer's reports" style comparison of
> voting products
> ever to reach the public domain. This material is
> shallow, but still
> extremely useful, particularly as an introduction to how
> DRE voting
> systems work.
> 2) It contains a summary report of the source code audits of
> the 4
> systems, reporting serious security flaws in all of them.
> As I've
> been saying since the Diebold mess began, there's nothing
> special
> about Diebold, theirs is simply the first system that
> anyone has
> put to a public test.
> They've also put together a set of criteria that they believe
> that
> voting systems should conform to, but there are deep flaws in
> these
> criteria. They blindly demand that certain information be
> encrypted,
> for example, instead of thinking it through. For example,
> they require
> that ballot format data and reports of precinct results be
> encrypted.
> In fact, ballot formats are public information, published in
> the paper
> or sent out in voter booklets long before the polls open, and
> similarly,
> vote totals from the precinct should also be public. The best
> practice
> is to print and post these at the precinct before any
> electronic
> transmission (by sneakernet or modem).
> Therefore, anything that obscures this data is actually a bad
> idea.
> Apparently, the Compuware folks didn't understand that what we
> want with
> these files is strong authentication. Crypto technology is of
> crucial
> importance in authentication, but if you don't understand that
> you're
> authenticating the data, not obscuring it from eavesdroppers,
> you'll
> very likely abuse the cryptosystem. From the point of view of
> design
> for minimum complexity and maximum transparency, I'd rather
> not encrypt
> the data for transmission, but just compute a
> cryptographically secure
> checksum for authentication. That way, the data itself is
> subject to
> a minimum of transformation.
> Another weakness of this report is that they repeatedly say
> "we were
> unable
> to exploit this attack", and they seem to take that as
> evidence that
> the security of the system might be sufficient to protect
> against that
> attack. That's a dangerous assumption! Some attackers know
> lots more
> than I do, and I think this is true across the board.
> Finally, their source code audit looks superficial, in some
> ways. They
> say "visually inspected to determine that the source code is
> modularized"
> with, for example, no study of the effective use of modular
> design. I
> can modularize a program several ways -- some of these
> approaches to
> modularity will make proof of certain properties of the
> software
> trivial,
> while others will obscure those same properties. The mere
> presence of
> modules does nothing in this regard. In this respect, the
> audit is
> similar
> to the FEC/NASED audits -- they look at and count the trees,
> but I'm not
> sure they see the forest.
> All of that criticism aside, however, this report is worth
> reading.
> (it's long, though, well over 100 pages).
> Doug Jones
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Wed Dec 31 23:17:05 2003

This archive was generated by hypermail 2.1.8 : Wed Dec 31 2003 - 23:17:18 CST