Re: Important Voting System Report

From: Rick Gideon <rick_at_openvoting_dot_org>
Date: Fri Dec 05 2003 - 20:20:13 CST

On Fri, 5 Dec 2003, Alan Dechert wrote:

> Doug,
> > ....... This material is shallow, but still extremely useful, particularly
> > as an introduction to how DRE voting systems work.
> >
> I agree. Especially with the "shallow" part. Example:
> pg 106
> Requirement 3.41
> ---------------
> The Tally software shall not
> allow modification of the vote
> count.
> Test Scenario
> -------------------
> Try to modify the vote tally in the UES
> software using a tool such as MS Excel
> or MS Access.
> Test Results
> ---------------------
> The Tally software stores data in a
> set of ISAM file structures. These
> data structures are not ODBC
> compliant and could not be
> accessed from MS Excel.
> Um, what about another tool? For example, something that is neither MS
> Access nor MS Excel?

Exactly. It seems like their testing was limited. Especially when you see
comment such as:

[Page 4] For example, we investigated the transfer of the
ballot definition data from the respective election management software
programs to the DRE, but we did
not investigate the election management application itself.

[Page 5] The following tasks were within the scope of Compuwares

Created test scenarios For each specific DRE, wrote test scenarios
designed to reveal whether
the security requirements above were met by the DRE.

[Page 8] Note: Given the short time frame of the project, it was not
possible to review every single line of code in
all of the applications. Review of the code was done using a sampling of
code files from these
applications. Analysis from the sampling of code files was extrapolated to
the overall architecture of the

So they based their testing methodologies off of existing NIST standards,
which is fine, but basically made it up as they went from what I am
seeing. Have to have some starting point with the NIST standards.
But the lack of complete
code review is lacking in my eyes. Which makes all of the errors which
they did catch even more signifigant due to the lack of full code review,
which would have increased the number I am sure.

The report is a great look into the workings of a DRE and what the
"competition" has going for itself and how OVC can overcome and learn from
any possible issues which may come up on the elections side and what
danger areas to be on the watch for. It is a shame that although this
report shows the vulnerabilities of such devices that the SoS of Ohio is
willing to reconsider once they fix these errors, even if they weren't
100% complete.

The BBV world is beginning to see more big name press covering this issue
and it is becoming a very hot topic everywhere, lots of things are
happening very quickly anymore.

= 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