Ohio/Compuware security review of Hart et.al.

[Neal McBurnett <neal@xxxxxxxxxxxxxxxxx>]

The County Clerks's recommendation for Boulder, to be discussed at the
upcoming commissioners meeting, involves several systems from Hart
InterCivic: "Ballot Now" for scanning, their Ballot Origination
Software System (BOSS) Election Management Software, their Tally
software, and perhaps something called eadmin(?).

I've been looking for an unbiased sense for how the systems work
together and a sense of what security issues to consider.

Here is one.  The Ohio security review noted at our site

 http://coloradovoter.net/moin.cgi/OtherResources

includes two analyses of Hart InterCivic and some of its election
systems.  The county is no longer considering the eSlate 3000 DRE,
which was a focus of the studies.  But other components that were
assessed at least to some degree are part of the Clerks's
recommendation for Boulder.  It unfortunately does not address the
"Ballot Now" system that will consideration at the upcoming
commissioners meeting.

One analysis is a review of the software, hardware, etc by Compuware:
 http://www.sos.state.oh.us/sos/hava/files/compuware.pdf

The other is a review of the corporate security and development
practices of the company by InfoSENTRY:
 http://www.sos.state.oh.us/sos/hava/files/InfoSentry1.pdf

The Ohio report has been criticized for overlooking important issues
that had already been identified by other researchers.  For example it
doesn't require a voter-verified paper ballot, which many other
commentators have insisted on.  But it seems like one of the best
places to start.

PDF page 143 (document page 137) of the Compuware report gives an
overview of the Hart system, introducing these components and
definitions:

 Ballot Origination Software System (BOSS) Election Management Software
 Tally software
 SERVO software
 eSlate 3000
 Judge's Booth Controllers (JBCs)
 Mobile Ballot Box (MBB)

 Board of Elections (BOE)

The many "High Risk" problems found with the eSlate 3000 are troubling
given that the system had passed all the previous certification
requirements.  This gives strong support to the arguments that
existing certification procedures are inadequate, and for requiring
full disclosure of all the software for the elections systems that we
rely on, as I argue at

  http://bcn.boulder.co.us/~neal/elections/disclosure.html

I haven't read the whole report yet, but while scanning to find out
what the SERVO software does, I ran across this quote from PDF page
187:

 Test number 3.41

 Test Scenario: Try to modify the vote tally in the Tally software
 using a tool such as MS Excel or MS Access.

 Test Result: The BOSS software uses Sybase SQLAnywhere 7.0 to store
 results. The Database has been configured using Microsoft s ODBC
 drivers .The passwords have been hard coded in the driver
 properties. Using MS Access we were able to create an external link to
 the BOSS, SERVO, and Tally databases and read and manipulate the data.

 Risk identified: An external link was created to the BOSS, Servo, and
 Tally databases, and the data was read and manipulated. There is a
 risk that the data contained in the Ballot and Tally databases can be
 read and modified by an unauthorized person who has access to the
 system and the ability to use or install any basic data access
 program that uses ODBC for its driver.

And on PDF page 190:
 3.41 Risk Likelihood: Low   Impact Rating: High   Risk Level: Low

The risk of this sort of modification was highlighted in the Johns
Hopkins report on Diebold last July.  It isn't clear to me why a
similar risk would be rated "Low" by Compuware.

They say on PDF page 193 under Recommended Risk Mitigation Strategies:

 3.41 - We recommend the Secretary of State require that administrative
 policies and procedures be put into place to require use of proper
 Windows login security on the EMS server and to prevent unauthorized
 access, and not contain any additional software that would allow
 access to the EMS database.

I don't think we should buy a system with that sort of risk.  But note
that I'm not singling Hart out here - Ohio found major flaws with all
the systems they analyzed, and this particular problem is widespread.
It was a problem with the Diebold software that was used in the last
two elections in Boulder.  .So is reliance on notoriously vulnerable
Windows software.

I think we are at a turning point in elections technology.  Internet
technology, modern cryptography and modern software engineering has
gotten us to the point where secure systems don't have to trust any
single person.  This is a principle of election procedure also, as
laid out at the recent NIST symposium by the widely respected
elections official and scholar Douglas W. Jones:

 Why trustworthy voting systems require institutionalized distrust.
  http://www.cs.uiowa.edu/~jones/voting/nist2003.html

So for election systems of the future, I would expect to see something
done to really address the risk of a single individual subverting the
final tally machine.

For example, I'd suggest secure write-only logging of the
batch-by-batch election results, so that an independent process
managed by a different person can verify the final outcome.

In combination with hand-counting of randomly-selected ballot batches,
checked against the logged results, I think this sort of approach
would go a long way towards increasing voter confidence and thus help
increase voter turnout.

I expect that the NIST and EAC will incorporate stronger protections
in the standards they are working on.  And I hope to see vendors come
forward soon with systems that address these sorts of concerns and
that exceed the standards.


For now, I think we should avoid locking ourselves in by buying a
system now.  We should lease for the time being.  The system we buy
should last a long time, rather than being viewed in a few years as
old, insecure technology.

Cheers,

Neal McBurnett                 http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60