Important Voting System Report

From: Douglas W. Jones <jones_at_cs_dot_uiowa_dot_edu>
Date: Fri Dec 05 2003 - 13:54:53 CST

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
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
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
while others will obscure those same properties. The mere presence of
modules does nothing in this regard. In this respect, the audit is
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