A Report from the Public Monitor of the Cuyahoga County Board of Elections

From: Joseph Lorenzo Hall <joehall_at_gmail_dot_com>
Date: Fri Feb 23 2007 - 11:00:26 CST

(sorry for any cross-posting. -Joe)

----
http://josephhall.org/nqb2/index.php/2007/02/22/ccoh_pubmonreport
# A Report from the Public Monitor of the Cuyahoga County Board of Elections
After the 2006 primary disaster in Cuyahoga County, Ohio, where tens
of thousands of absentee ballots had to be hand-counted due to a
printing problem, the County Board of Elections appointed a public
monitor to oversee the conduct of elections. That public monitor
effort is lead by [Candice Hoke][1], a law professor at Cleveland
State University's (CSU) [Cleveland-Marshall College of Law][2] and
Director of CSU's Center for Election Integrity.
Cleveland's local Fox News broke a story today about a report from the
public monitor on possible legal noncompliances at the Cuyahoga County
Board of Elections (CCBOE) ([*"I-Team Investigates Election
Security"*][3]). The Fox reporting focuses on a few serious issues
raised by the report:
*   there was one administrative level of access and only one user
account (`admin`) for the Election Management System (EMS) server used
by five different people;
*   while two keys from different political parties are needed to open
the ballot vault, these keys are stored side-by-side, on the same key
ring, in an unlocked compartment;
*   the surveillance footage from the tabulation room was destroyed
four weeks after the election, and;
*   a "cable" was mistakenly left attached to the EMS server before
election day.
These things are serious from a physical and computer security
perspective, but there's more to this story than simply these issues.
I'd like to focus on what the report points out that wasn't
highlighted in the Fox News story.
If you'd like to follow along, I'd suggest downloading the following documents:
1.  The only recently-released report from January 8, 2007 written by
the public monitor ([*"RE: Monitor Report Possible Legal Noncompliance
in the November 2006 Election"* (PDF)][4]), and;
2.  The letter dated February 15, 2007 from the CCBOE Board to the
Ohio Secretary of State (SOS) requesting a technical expert to help
evaluate the public monitor's report ([*"CCBOE Board Letter to
Secretary of State Jennifer Brunner"* (PDF)][5]).
*(Note: these documents originally resided [here][6] and [here][7] on
the Fox News site. I've chosen to mirror them at the above locations
just in case they eventually disappear from the Fox site.)*
Let's start in reverse chronological order. The CCBOE letter asks the
SOS for "assistance in identifying an independent **Windows
certified** engineer to conduct a review of the report [...]"
(emphasis added). They maintain that this help is needed because
"neither the Board nor the Monitor has the technical certification to
fully review the questions that have been raised in the report."
First, as you will see below, I think the report stands well on its
own as a testament to the high quality technical ability and scrutiny
of the public monitor. Second, the report raises a lot of serious
questions that are not purely technical, but relate to the difficulty
that the CCBOE is having in following the letter of the law. Finally,
it is clear from the request for a "Windows certified" technical
expert that the CCBOE does not understand what this situation is in
need of: forensics experts versed in both general principles of
computer security as well as the specifics of Windows and, more
importantly, Diebold Election Systems, Inc.'s (DESI) Global Election
Management System (GEMS). If I were the CCBOE or the SOS, to get to
the bottom of the myriad of issues brought forth by the monitor's
report, I would want someone that new quite a bit about forensics,
computer security and voting systems.
That brings us to the report itself. In addition to the issues
highlighted by the Fox News team, there are a host of other
irregularities that need further investigation. Here is a quick list
of some of the less technical instances of possible legal
noncompliance:
*   The DESI voter-registration product (DIMS) has a "merge records"
function with a hair-trigger and no "Undo" ability. This seems to have
contributed to a number of voters being dropped from the rolls. The
CCBOE has still not put in place any remedial processes and DESI has
yet to provide a fix.
*   There were a lot of problems in complying with Ohio's strict poll
worker requirements (number per precinct, parties in precinct, etc.).
Unfortunately, the DIMS registration product would often "scramble,
delete or [loose]" information from voter registration records. Also,
unknown errors in how DIMS reports these statistics per polling place
resulted in the CCBOE erroneously believing it had met its staffing
requirements and unfortunately turned away hundreds of interested poll
worker applicants.
*   The intense pressure to prepare all the DRE machines leaves an
inadequate amount of time for the polling place locations manager to
ensure that polling places are meeting legal requirements including
disability access.
*   There are unexplained large discrepancies between the number of
people that signed poll books and the number of ballots cast in some
polling places. Explanations might include:
   *   people skipping the line to sign-in and voting anyway;
   *   poll workers assigning the wrong precinct identifier to voters
in polling places with multiple precincts, and/or;
   *   people getting tired of waiting to vote after having signed in
and fleeing the polling place.
*   Indicted (and [now convicted][8]) employees involved in charges of
election fraud handled memory cards and voted absentee ballots,
contrary to CCBOE claims that these individuals had been moved to
non-sensitive duties. (Note: this is based on second-hand information,
so may not be the case. It deserves some investigation, though.).
*   Some non-citizens and immigrants lacking green cards have handled
ballots and performed tasks assigned to "unaffilated" political party
status, despite that they cannot vote nor register to vote. Also, for
individuals that do not have a "green card", they may be more
vulnerable and susceptible to coercion and intimidation.
All this being said, the entire second half of the report focuses on
technical and security issues. This is where the hard work and real
technical ability of the public monitor and her staff really shines
through.
The report first points out that, contrary to a court order and SOS
directive, absentee ballot vote reports were printed the day before
election day. That is to say that while a court allowed the CCBOE to
begin scanning in absentee ballots early, before election day, it
stipulated that no one should have access to those results until after
the polls closed on election day. However, the facts show that someone
violated this order by printing results reports that would have shown
aggregate results for these early scanned absentee ballots. What's
more strange is that the GEMS audit log shows no results reports
printed while the Windows System Log shows 7 such reports printed. As
GEMS audit logs are easily manipulated without a password, this could
indicate that the individual who violated the court order attempted to
hide their tracks. What use would this information be? It could be
used to target certain precincts on election day in a very close race
or inform other types of tampering with vote results.
Further, a network cable, used to program optical scanners in the
basement over the network, was mistakenly left attached to the GEMS
server over night one night. It is unknown what types of network
connections, if any, were made to the GEMS server during this period
of time. One anomaly, however, did appear: the GEMS clock, which had
been reasonably correct before had been set forward 11+ hours.
In terms of other networking vulnerabilities, a "jump drive" flash
memory module was used to ferry results reports from the GEMS server
to the web server on election night but this piece of hardware was
never certified nor examined. To reduce the possibility of a malicious
attack through this channel, the monitor recommended that they burn
CDROMs. This suggestion was rejected.
Unfortunately, the Windows Security Events log only shows one entry:
cleared by an administrator on December 8, 2005. There were no
security events relating to data security recorded at all in 2006. It
appears that the manufacturer cleared this log and then configured it
so that *it would not* log security-relevant events. This is
unfortunate as it would help to piece together some of this puzzle.
Finally, there were significant interaction problems between GEMS and
DESI's JResults server, a Java-based results reporting tool. While
running these two applications concurrently, the monitor observed
"several troubling occurrences". It is unclear if JResults has ever
been certified and under what conditions it should be running while
GEMS is running.
**Bonus:** It appears (from page 34 of the PDF) that future versions
of GEMS will operate not on a JET/MS Access database but using SQL.
Probably Microsoft SQL.
[1]: http://www.law.csuohio.edu/faculty/faculty_list.html#hoke
[2]: http://www.law.csuohio.edu/
[3]: http://www.myfoxcleveland.com/myfox/pages/Home/Detail;jsessionid=442E018041F1C9BF56C70E3839C36555?contentId=2467913&version=1&locale=EN-US&layoutCode=VSTY&pageId=1.1.1
[4]: http://josephhall.org/ccoh/20070108_publicmon_report.pdf
[5]: http://josephhall.org/ccoh/ccboe_letter.pdf
[6]: http://media.myfoxcleveland.com/DOC050.PDF
[7]: http://media.myfoxcleveland.com/DOC051.PDF
[8]: http://www.guardian.co.uk/worldlatest/story/0,,-6369252,00.html
--
Joseph Lorenzo Hall
PhD Student, UC Berkeley, School of Information
<http://josephhall.org/>
_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Wed Feb 28 23:17:23 2007

This archive was generated by hypermail 2.1.8 : Wed Feb 28 2007 - 23:17:27 CST