**Threats to Voting Systems and NIST Voting Standards Work**

**John Kelsey, NIST, September 2005**

**DRAFT**

1 Introduction

As part of its work writing voting standards, NIST has been working out
potential attacks against existing and future voting systems. In this
note, we discuss the current status of these efforts, their purpose, and
their likely impact on NIST\'s voting standards work.

Understanding the potential attacks against a given class of voting
system is a requirement for developing meaningful standards to secure
it. A real discussion of attacks needs to consider many factors, such as
the resources required to carry out the attack, the impact of likely
countermeasures, and the usefulness of the attack in accomplishing some
attack goal. Previously, we have considered the set of attack goals and
attacker resources in some detail; we are currently applying the results
of this work, along with a large amount of unconnected security
observations and potential attacks which we developed as part of writing
the VVSG.

When we understand the sets of attacks that might be used to tamper with
an election outcome, violate voter privacy, discredit or disrupt an
election, we will know what must be defended or prevented to avoid these
attacks. Among other things, this information can inform standards
writing as follows:

a\. Which voting system architectures should be allowed in future
standards?

b\. What design elements (e.g., wireless networking, paper rolls) either
should be prohibited in future standards, or should be subject to
special controls to address known attacks?

c\. What technical and procedural countermeasures must be in place to
prevent the known attacks?

1.1 Which Attacks are Practical?

One of the most important parts of analyzing possible attacks is
determining which attacks are really practical threats. That is, if
there are existing, widely-used countermeasures which would block the
attack, or if the attack requires a conspiracy of hundreds or thousands
of insiders, then there\'s limited value in trying to block it with
additional testing or procedures.

The most important constraints on attacks are:

a\. The resources required, especially the number of conspirators who
must remain silent for the attack to go undetected. For example, chain
voting and other vote-buying schemes require a conspiracy size about as
big as the number of votes injected into the election. On the other
hand, tampering with the paper ballots on the way to a central counting
center allows a relatively small conspiracy to change a large number of
votes.

b\. The level of insider access required, especially the number of
election insiders (election officials, voting system vendor employees,
and the like) required for the attack to work. For example, some kinds
of attack on DRE+VVPAT and POOS systems have the property that they
require tampering with both the software in the voting machine or
scanner, and also with the paper ballots. These are inherently harder to
accomplish than attacks that only require corrupt election officials or
that only require corrupt programmers at the voting system vendor.

c\. How widespread and practical are countermeasures that would detect
or prevent the attack. For example, if local totals from each polling
place are openly posted before these totals are transmitted
electronically to a tabulation center, then tampering with those
electronic transmissions is not a very effective attack\--a cheap,
widely used countermeasure is sufficient to defeat it. On the other
hand, some countermeasures are more expensive, and are seldom used. For
example, most software tampering of DRE voting systems can be
effectively caught by extensive enough parallel testing. However, this
level of parallel testing adds both capital and operating cost, and so
far, we have not seen extensive use of it. Thus, we can\'t assume its
use will block this class of attack.

2 Developing Lists of Attacks at NIST

2.1 Prior NIST Work

In writing the VVSG, we developed a large number of attacks on voting
system architectures. Although these attacks were typically pretty
abstract, they informed some of our decisions, though the tight schedule
of the initial VVSG prevented incorporation of many of the defenses we
were able to work out.

2.2 Brennan Center Work

While NIST worked on the VVSG, the Brennan Center was working
independently on an extensive catalog of threats. They introduced a
methodology for evaluating possible attacks on voting systems in terms
of conspiracy size needed to sway a close presidential election. Using
data from a close Presidential election in Washington state, they were
able to get hard numbers for much of their analysis.

The Brennan Center\'s work is ongoing; they have given NIST access to
their intermediate work product, and we have shared our own incomplete
threat analyses with them.

2.3 Threat Workshop and Outputs

In October, NIST and the Brennan Center plan to hold a workshop open to
the public on threats to voting systems. Our plan is to discuss several
of the most potentially damaging threats to voting systems at the
workshop, in an environment with computer security experts, election
officials, experts on voting standards, and even the rare person who
fits two or more of these descriptions at once. At the end of these
discussions, we hope to have:

a\. A much better understanding of the real-world impact of the
categories of attacks discussed.

b\. Some level of consensus among the participants about the importance
of various attacks, and thus of likely countermeasures.

NIST will use the output from this workshop to tune our future standards
to address the most damaging threats.

4 Summary: Likely Impact on Voting System Standards

Our work on threats to voting systems has an enormous impact on what
standards we propose; without a good understanding of the potential
attacks, it is hard to develop good defenses. We expect the attacks we
analyze to impact voting standards in at least three ways:

a\. Determining the voting system architectures and technology which is
acceptable in future voting systems.

b\. Determining specific technical and procedural countermeasures which
we can write into future standards.

c\. Determining intermediate steps in these attacks which can then be
used as targets in open-ended evaluation of voting systems.