[E-voting] BREAKING NEWS: Massive decertification of California electronic voting machines

Catherine Ansbro cansbro at eircom.net
Sat Aug 4 11:04:35 IST 2007


California Secretary of State Debra Bowen was elected in Nov. 2006 on a 
platform that she would undertake a thorough testing and investigation 
of California's election systems and electronic voting machines in 

Over a 4-week period tests were carried out by separate teams.  The 
tests included source code review (to the extent source code was made 
available) and penetration threat testing.  The results were damning.

Links to the decertification decisions and to all the public testing 
reports are here:

Comprehensive accessibility evaluations were also done.  The results 
were equally disturbing.  (Supposedly, these electronic voting machines 
were purchased in order to allow equal access by disabled voters--but 
they did not achieve this goal.)

I read the University of California's Red Team Overview report and it is 
hair-raising stuff.  In addition to the number and severity of the 
vulnerabilities discovered by the two Red Teams, the obstruction and 
lack of cooperation of the vendors was noteworthy.  Also, the limited 
time frame for testing limited the results.  But even so the results are 
gob-smackingly shocking.  The vulnerabilities were so profound that some 
details were put into second, Private, reports which were issued only to 
election officials and vendors.

I've seen large sections of the source code test results for one system 
and it is equally hair-raising.
Jerry Berkman's abridged version of the Sequoia source code review 
follows below.

This is a massive wake-up call for anyone thinking of considering 
electronic voting of any kind in Ireland or elsewhere.  Note that the 
optical scanners also did not pass muster (lost their approval, and will 
be reapproved only under certain conditions).


Since we use Sequoia equipment in Alameda County, CA, I decided
to read the Sequoia source code review:


It is very long; I quit after the main text and
skipped the Appendices. I thought I'd summarize
some of the findings. Many are unbelievable.
Sequoia must have been isolated from good
programming practices and modern security
practices for 10 years.

For most of the below, I did cut and paste. A few
places, I summarized instead.

- Jerry

*Executive Summary*

We found significant security weaknesses
throughout the Sequoia system. The nature of these
weaknesses raises serious questions as to whether
the Sequoia software can be relied upon to protect
the integrity of elections. Every software
mechanism for transmitting election results and
every software mechanism for updating software
lacks reliable measures to detect or prevent

Many of the most significant vulnerabilities we
found - those likely to be especially useful to an
attacker seeking to alter election results - arise
from four pervasive structural weaknesses:

- Data Integrity. The Sequoia system lacks
effective safeguards against corrupted or
malicious data injected onto removable media,
especially for devices entrusted to poll workers
and other temporary staff with limited authority.

- Cryptography. Many of the security features of
the Sequoia system, particularly those that
protect the integrity of precinct results, employ
cryptography. Unfortunately, in every case we
examined the cryptography is easily circumvented.

- Access Control. The access control and other
computer security mechanisms that protect against
unauthorized use of central vote counting
computers and polling place equipment are easily

- Software Engineering. The software suffers from
numerous programming errors, many of which have a
high potential to introduce or exacerbate security
weaknesses. In general, the software does not
reflect defensive software engineering practices
normally associated with high-assurance critical

*Ch. 3 Systemic and Architectural Issues*

*3.1 Data Integrity*

much of the data that determines the outcome of an
election - precinct results, voting machine
configuration files, ballot definitions, and so on
- reside on removable media that may pass through
several sets of hands.

Unfortunately, the software mechanisms that
safeguard these critical election components are
largely ineffective or absent from the Sequoia
system, making the system completely dependent on
the physical security of its components

The standard audit mechanisms used in California
(such as 1% recounts and parallel testing) may be
only marginally effective in detecting and
recovering from the attacks against data integrity
we discuss in this section.

*3.1.1 Integrity of Precinct Results, Edge
Results Cartridges*

Besides altering the results for the precinct,
additional attacks are also possible. Counterfeit
extra returns for precincts other than the one
from which a cartridge originated can be added to
a Results Cartridge. These extra results are added
to the other precincts' totals when read into
WinEDS but are not listed in several of the tally
audit reports that WinEDS generates, making the
attack difficult to detect and isolate. See
Section 4.1.23.

Finally, there are potential avenues for corrupt
Results Cartridges to attack the WinEDS system

*3.1.1 Integrity of Precinct Results, Insight*

The behavior of Insight optical ballot scanners is
controlled by firmware and ballot definition data
stored on the same removable MemoryPacks that hold
the machines vote tallies.

*3.1.2 Integrity of Precinct Voting Firmware and Software, Edge*

Edge touchscreen DREs are controlled by firmware
and ballot definition files contained on (or
loaded through) removable PCMCIA cartridges

Several aspects of the VVPAT behavior, including
the speed at which it scrolls, the density of the
print, and so on, are under the control of the
Edge firmware and thus reduce the value of the
VVPAT record in the presence of malicious Edge
firmware. Corrupted firmware could be configured
in a way that prints misleading information on the
VVPAT printoutorthatpreventsthe voter from clearly
seeing how their vote is recorded on the VVPAT

*3.1.2 Integrity of Precinct Voting Firmware and
Software, HAAT and Card Activator*

The USB- and PCMCIA-based configuration mechanisms
used on the HAAT and Card Activator provide a rich
vector for viral propagation of malicious
firmware, and potentially for corruption of the
Edge and WinEDS.

*3.1.3 Detection and Auditing of Corrupted

Two audit protocols are routinely employed in
California elections to detect corrupted voting
machine firmware: Parallel Testing and 1% Recount
Audits. Unfortunately, neither protocol is likely
to detect the precinct-based firmware corruption
attacks against Edge DREs discussed in this

*3.1.3 Detection and Auditing of Corrupted
Firmware, 1% Recount Audits*

It may be possible to construct Edge firmware that
prints incorrect VVPAT records (matching the
incorrectly recorded electronic records) but in a
way that escapes the notice of voters when they
cast their ballots.

*3.1.3 Detection and Auditing of Corrupted
Firmware, Parallel Testing*

While this procedure may detect certain kinds of
unreliable or corrupt firmware delivered from the
vendor, it will not detect the precinct-based
firmware corruption attacks discussed in this
chapter. In these attacks, the corrupt firmware
is loaded after the machines have been delivered
to the precincts, and so escape the possibility of
being subject to parallel tests.

*3.2 Cryptography*

Many of the security features of the Sequoia
software, particularly those that verify the
integrity of precinct results and that safeguard
against the introduction of malicious software and
firmware, employ cryptography. Unfortunately, in
every case we examined the cryptography provides
only ineffective protection. This is a pervasive
failure, with fundamental cryptographic errors
throughout the software. We could not find a
single instance of correctly used cryptography
that successfully accomplished the security
purposes for which it was apparently intended.
The cryptographic protection in the Sequoia system
was effectively neutralized by several poor design
decisions compounded by a range of implementation

*3.2.1 Hardcoded Keys*

Virtually all cryptographic key material in the
Sequoia system is permanently hardcoded into the
software source code (and is apparently identical
in all hardware shipped to different
jurisdictions). `

*3.2.2 Poor Algorithms and Protocols*

every one of the cryptographic algorithms used in
the Sequoia system is either obsolete and known to
be weak, is an ad hoc design with obvious flaws,
or is used in a manner that does not provide the
stated or required security properties.

*3.3.1 Access Control in Central Elections

Because the Sequoia design enforces access control
only in the client, the extensive access control
system in WinEDS can be completely circumvented by
communicating directly with the database.

*3.3.1 Data Wizard*

Any WinEDS user, even a user with all 615 access
rights turned off, can use the Data Wizard. The
Data Wizard is incorrectly implemented; it fails
to import data. However, it can erase entire

*3.3.1 Platform Access Control*

The Optech 400C system was set up with only one
user account, WinETP, with administrator access
and no password. On the laptop running the WinEDS
client and the SQL server, the user Tally running
WinEDS had sufficient permissions to install
additional software. These privileges allow any
WinEDS or WinETP user logged on to the respective
system to have full control over these machines,
regardless of their privileges in WinEDS or

My Summary: Optech 400C as provided by Sequoia had
lots of extra software including "Windows Movie
Maker, MSN Gaming Zone, NetMeeting, Outlook
Express, Minesweeper, and 3-D Pinball"; it really
should have minimal software.

*3.3.2 Access Control in Polling Station

software on the HAAT or Card Activator will not
prevent someone with minimal access from replacing
the firmware of the device. Such replacement can
be performed without any need to physically access
its internals. In other words, tamper-evident
seals are insufficient to protect the integrity of
these devices.

*3.4 Defensive Software Engineering*

*3.4.1 Complexity, Code Size* The Sequoia
system consists of approximately 800,000 lines of
code in 10 different languages, including 4
different assembly languages. In addition, the
system makes use of at least 6 interpreted
languages. The sheer size of the Sequoia code
base and the breadth of languages make
understanding and analysis difficult in any time

*3.4.2 Interpreted Code*

none of this interpreted code is reviewed as part
of the normal certification process.

My Summary: they did not review the six

*3.4.3 Input Validation*

My Summary: Input validation is weak or missing.
The code often doesn't check for buffer overflows,
integer overflows, and format string errors.

*3.4.4 Implicit Assumptions*

*3.4.5 Error and Exception Handling*

the weak input validation (as described in Section
3.4.3) is often insufficient in preventing errors
produced in one component from cascading to

*3.4.6 System Unreliability*

We found using WinEDS, even in a normal context,
unreliable. If users have an expectation of
unreliability, an attacker does not need to be
concerned about writing exploit code with
sophisticated cleanup routines.

*3.4.7 Documentation Inconsistency*

Insufficient Documentation Inconsistency Across
Systems Examples of Substantive Inaccuracy:

the WinEDS Software Specification claims that the
system uses Triple DES encryption for the early
vote collection process, when in fact the
implementation in source is only single DES.

*3.4.8 Unused Code*

My Summary: dangerous from a security point of view.

*3.4.9 Software Testing*

The test specifications we were provided seem to
focus on getting the overall correct result given
correct input. However, exploiting the behavior of
a system when given incorrect or malicious input
is the primary attack vector used by malicious
users. Thus, testing with incorrect input is

My Summary: there should be independent tests of
each modules, but these were not given to the
team, and probably don't exist as there are many
routines that do not work, e.g. "Change Password"
for administrator, import function of Data Wizard
tool in WinEDS, etc.

The prevalence and severity of problems present in
the Sequoia system suggest that the independent
testing process failed to detect or address these
issues as well.

*Chapter 4 - Specific Weaknesses and their Implications*

*4.4.11 Provisional voting mode is poorly

When voting provisionally on an Edge using a
provisional Voter Card, the only indication to the
voter that the vote is being cast provisionally is
the string - Provisional Voter - on the VVPAT

Combined with weaknesses in Section 4.4.7 and
Section 4.5.4, official votes may be recorded
provisionally without detection by the voter or
poll worker. This effectively removes the votes
from the official tally. Election officials will
be unable to resolve these votes since no voter
identification will be associated with the
provisional voter ID. This provides an avenue for
attackers to both add and remove votes from the
official tally. Section 5.2.2 discusses possible
attack scenarios using provisional voting mode.

*4.4.12 Malformed font files allow loading of
arbitrary files.*

Using a malformed font file on a Results
Cartridge, it is possible to copy arbitrary files
outside of the root directory.

*4.4.16 Memory allocation may cause integer

My Summary: Edge uses customized versions of
calloc() and malloc() with bugs in them.
Customized versions are a bad idea.

*4.4.17 Bar codes on VVPAT receipt are

If enabled, the voter-verified paper audit trail
includes bar codes which have a numeric
representation of voter information and votes

*4.6.3 Integrity checking of the HPX and APX is
performed by the HPX and APX themselves,

A modified HPX chip or a MemoryPack with a
modified APX could skip their own integrity checks
and proceed to take control of the Insight (see
Section 4.6.2).

*4.9.1 Windows will execute autorun files on U3
USB smart drives.*

The Windows laptop provided to the Red Team
executes autorun files from U3 USB start drives
automatically. If U3 USB smart drives are used
and reused to prepare HAATs for an election, a
compromised HAAT can take control over WinEDS.

*4.9.2 WinEDS Windows version and configuration

The precise version of Windows over which WinEDS
runs is not specified, nor are the elements that
should be included in or excluded from its
configuration. Because the precise platform and
configuration is not specified, there is no way to
assure that potential security vulnerabilities
introduced by interactions between WinEDS and
various Windows bugs and features do not occur.

More information about the E-voting mailing list