1. Designing voting machines for verification
NAVEEN S ASTRY∗ TADAYOSHI KOHNO† DAVID WAGNER‡
Abstract code the correctness of a few security properties. For
clarity, we focus on two important security properties in
We provide techniques to help vendors, independent test-
the body of this paper. Verification of these properties, as
ing agencies, and others verify critical security properties
well as the others we describe elsewhere in this paper, are
in direct recording electronic (DRE) voting machines.
a step towards the full verification of a voting machine.
We rely on specific hardware functionality, isolation, and
architectural decision to allow one to easily verify these
Property 1 None of a voter’s interactions with the vot-
critical security properties; we believe our techniques
ing machine, including the final ballot, can affect any
will help us verify other properties as well. Verification
subsequent voter’s sessions1 .
of these security properties is one step towards a fully
verified voting machine, and helps the public gain con-
One way to understand this property is to consider a
fidence in a critical tool for democracy. We present a
particular voting system design that exhibits the prop-
voting system design and discuss our experience build-
erty. A DRE can be “memoryless,” so that after indelibly
ing a prototype implementation based on the design in
storing the ballot, it erases all traces of the voter’s actions
Java and C.
from its RAM. This way, a DRE cannot use the voter’s
choices in making future decisions. A DRE that achieves
1 Introduction Property 1 will prevent two large classes of attacks: one
against election integrity and another against privacy. A
With a recent flurry of reports criticizing the trustwor- DRE that is memoryless cannot decide to change its be-
thiness of direct recording electronic (DRE) voting ma- havior in the afternoon on election day if it sees the elec-
chines, computer scientists have not been able to allay tion trending unfavorably for one candidate. Similarly,
voters’ concerns about this critical infrastructure [17, 29, successful verification of this property guarantees that a
33, 38]. The problems are manifold: poor use of cryptog- voter, possibly with the help of the DRE or election in-
raphy, buffer overflows, and in at least one study, poorly sider, cannot access a prior voter’s selections.
commented code. Given these problems, how can we A second property is:
reason about, or even prove, security properties of voting
machines? Property 2 A ballot cannot be cast without the voter’s
The ultimate security goal would be a system where consent to cast.
any voter, without any special training, could easily con-
vince themselves about the correctness of all relevant Property 2 ensures the voter’s ballot is only cast with
security properties. Our goal is not so ambitious; we their consent; combined with other security properties,
address convincing those with the ability to understand the property helps ensure the voter’s ballot is cast in an
unmodified form.
∗ nks@cs.berkeley.edu. Supported by NSF CNS-0524252
In Section 8, we discuss additional target properties
and by the Knight Foundation under a subcontract through the Cal-
tech/MIT Voting Technology Project. for our architecture, and we discuss strategies for how to
† tkohno@cs.ucsd.edu. Supported by NSF CCR-0208842, prove and implement those properties successfully.
NSF ANR-0129617, and NSF CCR-0093337. Part of this research was
performed while visiting the University of California at Berkeley. 1 Note that we do allow certain unavoidable interactions, e.g., after
‡ daw@cs.berkeley.edu. Supported by NSF CCR-0093337 the ballot storage device becomes “full,” a voting machine should not
and CNS-0524252. allow subsequent voters to vote.

2. Current DREs are not amenable to verification of these architecture splits the vote confirmation code into a sepa-
security properties; for instance, version 4.3.1 of the rate module whose integrity is protected using hardware
Diebold AccuVote-TS electronic voting machine con- isolation techniques. This simple idea greatly reduces
sists of 34 7122 lines of vendor-written C++ source code, the size of the TCB and means that only the vote con-
all of which must be analyzed to ensure Properties 1 firmation logic (but not the vote selection logic) needs
and 2. One problem with current DRE systems, in other to be examined during a code review for many security
words, is that the trusted computing base (TCB) is sim- properties, such as Property 2.
ply too large. The larger problem, however, is the code Second, we use hardware resets to help ensure Prop-
simply is not structured to verify security properties. erty 1. In our architecture, most modules are designed
In this paper, we develop a new architecture that sig- to be stateless; when two voters vote in succession, their
nificantly reduces the size of the TCB for verification execution should be independent. We use hard resets to
of these properties. Our goal is to make voting systems restore the state of these components to a consistent ini-
more amenable to efficient verification, meaning that im- tial value between voters, eliminating the risk of privacy
plementations can be verified to be free of malicious breaches and ensuring that all voters are treated equally
logic. By appropriate architecture design, we reduce the by the machine.
amount of code that would need to be verified (e.g., using Our architecture provides several benefits. It preserves
formal methods) or otherwise audited (e.g., in an infor- the voting experience that voters are used to with current
mal line-by-line source code review) before we can trust DREs. It is compatible with accessibility features, such
the software, thereby enhancing our ability to gain confi- as audio interfaces for voters with visual impairments,
dence in the software. We stress that our architecture as- though we stress that we do not implement such features
sumes voters will be diligent: we assume that each voter in our prototype. It can be easily combined with a voter-
will closely monitor their interaction with the voting ma- verified paper audit trail (VVPAT). Our prototype imple-
chines and look for anomalous behavior, checking (for mentation contains only 5 085 lines of trusted code.
example) that her chosen candidate appears in the confir-
mation page.
We present techniques that we believe are applicable 2 Voting overview
to DREs. We develop a partial voting system, but we em-
phasize that this work is not complete. As we discuss in DREs. A direct recording electronic (DRE) voting ma-
Section 2, voting systems comprise many different steps chine is typically a stand-alone device with storage, a
and procedures: pre-voting, ballot preparation, audit trail processor, and a computer screen that presents a voter
management, post-election, recounts, and an associated with election choices and records their selections so they
set of safeguard procedures. Our system only addresses can be counted as part of the canvass. These devices
the active voting phase. As such, we do not claim that our often use an LCD and touch screen to interact with the
system is a replacement for an existing DRE or a DRE voter. Visually impaired voters can generally use alter-
system with a paper audit trail system. See Section 7 for nate input and output methods, which presents a boon to
a discussion of using paper trails with our architecture. some voters who previously required assistance to vote.
Technical elements of our approach. We highlight two Pre-election setup. The full election process incorpo-
of the key ideas behind our approach. First, we fo- rates many activities beyond what a voter typically ex-
cus on creating a trustworthy vote confirmation process. periences in the voting booth. Although the exact pro-
Most machines today divide the voting process into two cesses differ depending on the specific voting technol-
phases: an initial vote selection process, where the voter ogy in question, Figure 1 overviews the common steps
indicates who they wish to vote for; and a vote confirma- for DRE-based voting. In the pre-voting stage, election
tion process, where the voter is shown a summary screen officials prepare ballot definition files describing the pa-
listing their selections and given an opportunity to review rameters of the election. Ballot definition files can be
and confirm these selections before casting their ballot. very complex [24], containing not only a list of races and
The vote selection code is potentially the most complex values indicating how many selections a voter can make
part of the system, due to the need for complex user inter- for each race, but also containing copies of the ballots
face logic. However, if the confirmation process is easy in multiple languages, audio tracks for visually impaired
to verify, we can verify many important security prop- voters (possibly also in multiple languages), fields that
erties without analyzing the vote selection process. Our vary by precinct, and fields that vary by the voter’s party
2 Kohno et al. count the total number of lines in their paper [17]; for
affiliation for use in primaries. Election officials gener-
ally use external software to help them generate the ballot
a fair comparison with our work, we look at source lines of code, which
excludes comments and whitespace from the final number. Hence, the definition files. After creating the ballot definition files,
numbers cited in their paper differ from the figure we list. an election worker will load those files onto the DRE vot-

3. V o t e r s i g n i n a t p o l l i n g
D e s i g n b a l l o t
s t a t i o n
V o t e r a u t h e n t i c a t i o n
I n s t a l l b a l l o t
V o t e r i n t e r a c t i o n F i n a l i z e b a l l o t s S u m u p v o t e s
P r i n t z e r o ( t a p e
V o t e s t o r a g e
P R E 1 V O T I N G A C T I V E V O T I N G P O S T 1 V O T I N G C A N V A S S I N G
Figure 1: Major steps in the voting process when using DREs. The shaded portions are internal to the DREs. In this
work, we mainly address voter authentication, interaction, and vote storage.
ing machines. Before polls open, election officials gen- tion, although we are unaware of any instance where this
erally print a “zero tape,” which shows that no one cast a particular measure has been used in practice. While these
ballot prior to the start of the election. additional steps can help detect problems, they are by no
means sufficient.
Active voting. When a voter Alice wishes to vote, she
must first interact with election officials to prove that she
is eligible to vote. The election officials then give her 3 Goals and assumptions
some token or mechanism to allow her to authenticate
herself to the DRE as an authorized voter. Once the DRE Security goals. For clarity, in the body of this paper we
verifies the token, the DRE displays the ballot informa- focus on enabling efficient verification of Properties 1
tion appropriate for Alice, e.g., the ballot might be in Al- and 2 (see Section 1), though we hope to enable the effi-
ice’s native language or, for primaries, be tailored to Al- cient verification of other properties as well. Property 1
ice’s party affiliation. After Alice selects the candidates reflects a privacy goal: an adversary should not be able
she wishes to vote for, the DRE displays a “confirmation to learn any information about how a voter voted besides
screen” summarizing Alice’s selections. Alice can then what is revealed by the published election totals. Prop-
either accept the list and cast her ballot, or reject it and erty 2 reflects an integrity goal: even in the presence of
return to editing her selections. Once she approves her an adversary, the DRE should record the voter’s vote ex-
ballot, the DRE stores the votes onto durable storage and actly as the voter wishes. Further, an adversary should
invalidates her token so that she cannot vote again. not be able to undetectably alter the vote once it is stored.
We wish to preserve these properties against the classes
Finalization & post-voting. When the polls are closed, of adversaries discussed below.
the DRE ensures that no further votes can be cast and
Wholesale and retail attacks. A wholesale attack is one
then prints a “summary tape,” containing an unofficial
that, when mounted, has the potential of affecting a broad
tally of the number of votes for each candidate. Poll
number of deployed DREs. A classic example might be a
workers then transport the removable storage medium
software engineer at a major DRE manufacturer inserting
containing cast ballot images, along with the zero tape,
malicious logic into her company’s DRE software. Prior
summary tape, and other materials, to a central facility
work has provided evidence that this it is a concern for
for tallying. During the canvass, election officials accu-
real elections [3]. Such an attack could have nationwide
mulate vote totals and cross-check the consistency of all
impact and could compromise the integrity of entire elec-
these records.
tions, if not detected. Protecting against such wholesale
Additional steps. In addition to the main steps above, attacks is one of our primary goals. In contrast, a retail
election officials can employ various auditing and test- attack is one restricted to a small number of DREs or a
ing procedures to check for malicious behavior. For ex- particular polling location. A classic retail attack might
ample, some jurisdictions use parallel testing, which in- be a poll worker stuffing ballots in a paper election, or
volves sequestering a few machines, entering a known set selectively spoiling ballots for specific candidates.
of ballots, and checking whether the final tally matches Classes of adversaries. We desire a voting system that:
the expected tally. Also, one could envision repeating the
vote-tallying process with a third-party tallying applica- • Protects against wholesale attacks by election offi-

4. cials, vendors, and other insiders. confirmation screen do indeed accurately reflect their in-
tentions; otherwise, we will not be able to make any
• Protects against retail attacks by insiders when the guarantees about whether the voter’s ballot is cast as in-
attacks do not involve compromising the physical tended. Despite our reliance on this assumption, we re-
security of the DRE or the polling place (e.g., by alize it may not hold for all people. Voters are fallible
modifying the hardware or software in the DRE or and not all will properly verify their choices. To put it
tampering with its surrounding environment). another way, our system offers voters the opportunity to
verify their vote. If voters do not take advantage of this
• Protects against attacks by outsiders, e.g., voters, opportunity, we cannot help them. We do not assume
when the attacks do not involve compromising that all voters will avail themselves of this opportunity,
physical security. but we try to ensure that those who do, are protected.
We explicitly do not consider the following possible
goals: 4 Architecture
• Protect against retail attacks by election insiders We focus this paper on our design and implementation
and vendors when the attacks do involve compro- of the “active voting” phase of the election process (cf.
mising physical security. Figure 1). We choose to focus on this step because we be-
lieve it to be one of the most crucial and challenging part
• Protect against attacks by outsiders, e.g., voters,
of the election, requiring interaction with voters and the
when the attacks do involve compromising physical
ability to ensure the integrity and privacy of their votes.
security.
We remark that we attempt to reduce the trust in the can-
On the adversaries that we explicitly do not consider. vassing phase by designing a DRE whose output record
We explicitly exclude the last two adversaries above be- is both privacy-preserving (anonymized) and integrity-
cause we believe that adversaries who can violate the protected.
physical security of the DRE will always be able to sub-
vert the operation of that DRE, no matter how it is de- 4.1 Architecture motivations
signed or implemented. Also, we are less concerned
about physical attacks by outsiders because they are typi- To see how specific design changes to traditional vot-
cally retail attacks: they require modifying each individ- ing architectures can help verify properties, we will go
ual voting machine one-by-one, which is not practical to through a series of design exercises starting from current
do on a large scale. For example, to attack privacy, a DRE architectures and finishing at our design. The exer-
poll worker could mount a camera in the voting booth cises will be motivated by trying to design a system that
or, more challenging but still conceivable, an outsider clearly exhibits Properties 1 and 2.
could use Tempest technologies to infer a voter’s vote Resetting for independence. A traditional DRE, for ex-
from electromagnetic emissions [18, 37]. To attack the ample the Diebold AccuVote-TS, is designed as a single
integrity of the voting process, a poll worker with enough process. The functions of the DRE—validating the voter,
resources could replace an entire DRE with a DRE of presenting choices, confirming those choices, storing the
her own. Since this attack is possible, we also do not ballot, and administrative functions—are all a part of the
try to protect against a poll worker that might selectively same address space.
replace internal components in a DRE. We assume elec-
Let us examine one particular strategy we can use to
tion officials have deployed adequate physical security to
better verify Property 1 (“memorylessness”), which re-
defend against these attacks.
quires that one voter’s selections must not influence the
We assume that operating procedures are adequate to voting experience observed by the next voter. Suppose
prevent unauthorized modifications to the voting ma- after every voter has voted, the voting machine is turned
chine’s hardware or software. Consequently, the prob- off and then restarted. This is enough to ensure that
lem we consider is how to ensure that the original design the voting machine’s memory will not contain any in-
and implementation are secure. While patches and up- formation about the prior voter’s selections when it starts
grades to the voting system firmware and software may up. Of course, the prior voter’s selections must still be
occasionally be necessary, we do not consider how to se- recorded on permanent storage (e.g., on disk) for later
curely distribute software, firmware, and patches, nor do counting, so we also need some mechanism to prevent
we consider version control between components. the machine from reading the contents of that storage
Attentive voters. We assume that voters are attentive. medium. One conservative strategy would be to simply
We require voters to check that the votes shown on the require that any file the DRE writes to must always be

5. V o t e S e l e c t i o n
L C D a n d
I O M u l t i p l e x o r
T o u c h S c r e e n
V o t e C o n f i r m a t i o n
V o t e C o r e
T o k e n
R e a d e r
R e s e t M o d u l e
Figure 2: Our architecture, at an abstract level. For the properties we consider, the VoteSelection module need not be
trusted, so it is colored red.
opened in write-only mode, and should never be opened The consent property in consideration requires audi-
for reading. More generally, we can allow the DRE to tors to confidently reason about the casting procedures.
read from some files, such as configuration files, as long An auditor (perhaps using program analysis tools) may
as the DRE does not have the ability to write to them. have an easier time reasoning about the casting process
Thus the set of files on permanent storage are partitioned if it is isolated from the rest of the voting process. In
into two classes: a set of read-only files (which cannot our architecture, we take this approach in combining the
be modified by the DRE), and a set of write-only files casting and confirmation process, while isolating it from
(which cannot be read by the DRE). To summarize, our the vote selection functionality of the DRE. With a care-
strategy for enforcing Property 1 involves two prongs: ful design, we only need to consider this sub-portion to
verify Property 2.
1. Ensure that a reboot is always triggered after a voter
From our DRE design in the previous section, we in-
ends their session.
troduce a new component, called the VoteConfirmation
2. Check every place a file can be opened to ensure module. With this change, the voter first interacts with
that data files are write-only, and configuration files a VoteSelection module that presents the ballot choices.
are read-only. After making their selections, control flow passes to the
VoteConfirmation module that performs a limited role:
There must still be a mechanism to prevent the DRE from presenting the voter’s prior selections and then waiting
overwriting existing data, even if it cannot read that data. for the voter to either 1) choose to modify their se-
We introduce a separate component whose sole job is lections, or 2) choose to cast their ballot. Since the
to manage the reset process. The BallotBox triggers the VoteConfirmation module has limited functionality, it
ResetModule after a ballot is stored. The reset module only needs limited support for GUI code; as we show
then reboots a large portion of the DRE and manages the in Section 6.1 we can more easily analyze its correctness
startup process. We use a separate component so that it since its scope is limited. If the voter decides to modify
is simple to audit the correctness of the ResetModule. the ballot, control returns to the VoteSelection module.
We emphasize this design strategy is not the only way Note the voter interacts with two separate compo-
to verify this particular property. Rather, it is one tech- nents: first the VoteSelection component and then
nique we can implement that reduces the problem of en- VoteConfirmation. There are two ways to mediate the
forcing Property 1 to the problem of enforcing a checklist voter’s interactions with the two components: 1) endow
of easier-to-verify conditions that suffice to ensure Prop- each component with its own I/O system and screen;
erty 1 will always hold. 2) use one I/O system and a trusted I/O “multiplexor”
Isolation of confirmation process. In considering Prop- to manage which component can access the screen at
erty 2, which requires the voter’s consent to cast in order a time. The latter approach has a number of favorable
for the ballot to be stored, we will again see how mod- features. Perhaps the most important is that it preserves
ifying the DRE’s architecture in specific ways can help the voter’s experience as provided by existing DRE sys-
verify correctness of this property. tems. A voting machine with two screens requires voters

6. to change their voting patterns, and can introduce the op- ing token. In our implementation, we use a magnetic
portunity for confusion or even security vulnerabilities. stripe card, but the token could also be a smartcard or a
Another advantage is cost: a second screen adds cost and piece of paper with a printed security code. Each voting
complexity. One downside is that we must now verify token is valid for only one voting machine. To begin vot-
properties about the IOMultiplexor. For example, it must ing, the voter inserts the token into the designated vot-
route the input and output to the proper module at the ing machine. The VoteCore module reads the contents
appropriate times. of the token and verifies that the token is designated to
In the the final piece of our architecture, we introduce work on this machine (via a serial number check), is in-
a VoteCore component. After the voter interacts with the tended for this particular election, has not been used with
VoteSelection system and then the VoteConfirmation this machine before, and is signed using some public-
module to approve their selection, the VoteCore compo- key signature scheme. If the verification is successful,
nent stores the ballot on indelible storage in its BallotBox the VoteCore module communicates the contents of the
and then cancels the voter’s authentication token. Then, voting token to the VoteSelection module.
as we described above, it initiates a reset with the Vote selection. The VoteSelection module parses the
ResetModule to clear the state of all modules. ballot definition file and interacts with the voter, allow-
Let us return to our original property: how can we ing the voter to select candidates and vote on referenda.
verify that a ballot can only be cast with the voter’s ap- The voting token indicates which ballot to use, e.g., a
proval? With our architecture, it suffices to verify that: Spanish ballot if the voter’s native language is Spanish
1. A ballot can only enter the VoteCore through the or a Democratic ballot if the voter is a Democrat voting
VoteConfirmation module. in a primary. The VoteSelection module is intended to
follow the rules outlined in the ballot definition file, e.g.,
2. The VoteCore gives the voter the opportunity to re- allowing the voter to choose up to three candidates or to
view the exact contents of the ballot. rank the candidates in order of preference. Of course, the
VoteSelection module is untrusted and may contain ma-
3. A ballot can only be cast if the voter unambiguously
licious logic, so there is no guarantee that it operates as
signals their intent to cast.
intended. The VoteSelection module interacts with the
To prove the last condition, we add hardware to simplify voter via the IOMultiplexor.
an auditor’s understanding of the system, as well as to Vote confirmation. After the voter is comfortable with
avoid calibration issues with the touch screen interface. her votes, the VoteSelection module sends a descrip-
A physical cast button, enabled only by the confirma- tion of the voter’s preferences to the VoteConfirmation
tion module, acts as a gate to stop the ballot between the module. The VoteConfirmation module interacts with
VoteSelection and VoteCore modules. The software in the voter via the IOMultiplexor, displaying a summary
the VoteConfirmation module does not send the ballot screen indicating the current selections and prompting
to the VoteCore until the CastButton is depressed; and, the voter to approve or reject this ballot. If the voter ap-
since it is enabled only in the VoteConfirmation module, proves, the VoteConfirmation module sends the ballot
it is easy to gain assurance that the ballot cannot be cast image3 to the VoteCore module so it can be recorded.
without the voter’s consent. Section 6.1 will show how The VoteConfirmation module is constructed so that
we achieve this property based on the code and architec- the data that the VoteConfirmation module sends to the
ture. VoteCore module is exactly the data that it received from
There is a danger if we must adjust the system’s ar- the VoteSelection module.
chitecture to meet each particular security property: a
design meeting all security properties may be too com- Storing votes and canceling voter authentication to-
plex. However, in Section 8, we discuss other security kens. After receiving a description of the votes from
properties and sketch how we can verify them with the the VoteConfirmation module, the VoteCore atomically
current architecture. Isolating the confirmation process stores the votes and cancels the voter authentication to-
is a key insight that can simplify verifying other prop- ken. Votes are stored on a durable, history-independent,
erties. The confirmation process is at the heart of many tamper-evident, and subliminal-free vote storage mech-
properties, and a small, easily understood confirmation anism [25]. By “atomically,” we mean that once the
process helps not just in verifying Property 2. VoteCore component begins storing the votes and can-
celing the authentication token, it will not be reset until
after those actions complete. After those actions both
4.2 Detailed module descriptions complete, the VoteCore will trigger a reset by sending a
Voter authentication. After a voter signs in at a polling 3 A ballot image is merely a list of who this voter has voted for. It
station, an election official would give that voter a vot- need not be an actual image or picture.

7. message to the ResetModule. Looking ahead, the only for achieving strong isolation. We execute each mod-
other occasion for the ResetModule to trigger a reset is ule on its own microprocessor (with its own CPU, RAM,
when requested by VoteCore in response to a user wish- and I/O interfaces). This relies on physical isolation in
ing to cancel her voting session. an intuitive way: if two microprocessors are not con-
Cleaning up between sessions. Upon receiving a sig- nected by any communication channel, then they cannot
nal from the VoteCore, the ResetModule will reset all directly affect each other. Verification of the intercon-
the other components. After those components awake nection topology of the components in our architecture
from the reset, they will inform the ResetModule. Af- consequently reduces to verifying the physical separation
ter all components are awake, the ResetModule tells all of the hardware and verifying the interconnects between
the components to start, thereby initiating the next vot- them. Historically, the security community has focused
ing session and allowing the next voter to vote. We primarily on software isolation because hardware isola-
also allow the VoteCore module to trigger a reset via the tion was viewed as prohibitively expensive [32]. How-
ResetModule if the voter decides to cancel their voting ever, we argue that the price of a microprocessor has
process; when a voter triggers a reset in this way, the fallen dramatically enough that today hardware isolation
voter’s authentication token is not canceled and the voter is easily affordable, and we believe the reduction in com-
can use that token to vote again on that machine at a later plexity easily justifies the extra cost.
time. Although the VoteCore has access to external me- With this approach to isolation, the communication el-
dia to store votes and canceled authentication tokens, all ements between modules acquire special importance, be-
other state in this component is reset. cause they determine the way that modules are able to in-
teract. We carefully structured our design to simplify the
Enforcing a trusted path between the voter and the connection topology as much as possible. Figure 3 sum-
VoteConfirmation module. Although the above dis- marizes the interconnectivity topology, and we describe
cussion only mentions the IOMultiplexor in passing, several key aspects of our design below.
the IOMultiplexor plays a central role in the secu- We remark that when multiple hardware components
rity of our design. Directly connecting the LCD and are used, one should ensure that the same versions of
touch screen to both the VoteSelection module and the code run on each component.
VoteConfirmation module would be unsafe: it would
Buses and wires. Our hardware-based architecture em-
allow a malicious VoteSelection module to retain con-
ploys two types of communication channels: buses and
trol of the LCD and touch screen forever and display a
wires. Buses provide high-speed unidirectional or bidi-
spoofed confirmation screen, fooling the voter into think-
rectional communication between multiple components.
ing she is interacting with the trusted VoteConfirmation
Wires are a simple signaling element with one bit of
module when she is actually interacting with mali-
state; they can be either high or low, and typically are
cious code. The IOMultiplexor mediates access to the
used to indicate the presence or absence of some event.
LCD and touch screen to prevent such attacks. It en-
Wires are unidirectional: one component (the sender)
forces the invariant that only one module may have con-
will set the value of a wire but never read it, and the other
trol over the LCD and touch screen at a time: either
component (the receiver) will read the value of the wire
VoteConfirmation or VoteSelection may have control,
but never set it. Wires are initially low, and can be set,
but not both. Moreover, VoteConfirmation is given
but not cleared; once a wire goes high, it remains high
precedence: if it requests control, it is given exclusive
until its controlling component is reset. We assume that
access and VoteSelection is locked out. This allows our
wires are reliable but buses are potentially unreliable.
system to establish a trusted path between the voter in-
To deal with dropped or garbled messages without in-
terface and the VoteConfirmation module.
troducing too much complexity, we use an extremely
simple communication protocol. Our protocol is con-
4.3 Hardware-enforced separation nectionless and does not contain any in-band signaling
(e.g., SYN or ACK packets). When a component in our
Our architecture requires components to be protected architecture wishes to transmit a message, it will repeat-
from each other, so that a malicious VoteSelection com- edly send that message over the bus until it is reset or it
ponent cannot tamper with or observe the state or code receives an out-of-band signal to stop transmitting. The
of other components. One possibility would be to use sender appends a hash of the message to the message.
some form of software isolation, such as putting each The receiver accepts the first message with a valid hash,
component in a separate process (relying on the OS for and then acknowledges receipt with an out-of-band sig-
isolation), in a separate virtual machine (relying on the nal. This acknowledgment might be conveyed by chang-
VMM), or in a separate Java applet (relying on the JVM). ing a wire’s value from low to high, and the sender can
Instead, we use hardware isolation as a simple method poll this wire to identify when to stop transmitting. Com-

8. V o t e S e l e c t i o n
L C D a n d
I O M l t i p l e x o r
u
T o c h S c r e e n
u
V o t e C o n f i r m a t i o n
C a t
s
t t o n
B u
C a n c e l
V o t e C o r e
T o k e n
t t o n
B u
R e a d e r
R e e t M o d l e
s u
W i r e R e a d y w i r e B u s
C o n n e c t i o n t o I O d e v i c e
R e e t i g n a l S t a r t w i r e
s s
Figure 3: Our architecture, showing the hardware communication elements.
ponents that need replay protection can add a sequence writes the name of the region to the VoteSelection mod-
number to their messages. ule until it has new voter input. Naming the regions pre-
vents user input on one screen from being interpreted as
Using buses and wires. We now describe how to in- input on a different screen.
stantiate the communication paths in our high-level de-
sign from Section 4.2 with buses and wires. Once When the voter chooses to proceed from the vote
the VoteCore module reads a valid token, it repeatedly selection phase to the vote confirmation phase, the
sends the data on the token to VoteSelection until it re- VoteConfirmation module will receive a ballot from the
ceives a message from VoteConfirmation. After stor- VoteSelection module. The VoteConfirmation mod-
ing the vote and canceling the authentication token, the ule will then set its wire to the IOMultiplexor high.
VoteCore module triggers a reset by setting its wire to When the IOMultiplexor detects this wire going high,
the ResetModule high. it will empty all its input and output bus buffers, re-
To communicate with the voter, the VoteSelection set its counter for messages from the VoteSelection
component creates a bitmap of an image, packages that module, and then only handle input and output for the
image into a message , and repeatedly sends that message VoteConfirmation module (ignoring any messages from
to the IOMultiplexor. Since the VoteSelection module VoteSelection). If the VoteConfirmation module deter-
may send many images, it includes in each message a se- mines that the user wishes to return to the VoteSelection
quence number; this sequence number does not change if module and edit her votes, the VoteConfirmation mod-
the image does not change. Also included in the message ule will set its wire to the VoteSelection module high.
is a list of virtual buttons, each described by a globally The VoteSelection module will then use its bus to
unique button name and the x- and y-coordinates of the VoteConfirmation to repeatedly acknowledge that this
region. The IOMultiplexor will continuously read from wire is high. After receiving this acknowledgment, the
its input source (initially the VoteSelection module) and VoteConfirmation module will reset itself, thereby clear-
draw to the LCD every bitmap that it receives with a new ing all internal state and also lowering its wires to the
sequence number. The IOMultiplexor also interprets in- IOMultiplexor and VoteSelection modules. Upon de-
puts from the touch screen, determines whether the in- tecting that this wire returns low, the IOMultiplexor will
puts correspond to a virtual button and, if so, repeatedly clear all its input and output buffers and return to han-

9. dling the input and output for VoteSelection. The pur- spoofed cast button on the LCD and swallow the user’s
pose for the handshake between the VoteConfirmation vote, making the voter think that they have cast their vote
module and the VoteSelection module is to prevent the when in fact nothing was recorded and leaving the voter
VoteConfirmation module from resetting and then im- with no way to detect this attack. In contrast, a physical
mediately triggering on the receipt of the voter’s previ- cast button allows attentive voters to detect these attacks
ous selection (without this handshake, the VoteSelection (an alternative might be to use a physical “vote recorded”
module would continuously send the voter’s previous se- light in the VoteCore). Additionally, if we used a vir-
lections, regardless of whether VoteConfirmation reset tual cast button, miscalibration of the touch screen could
itself). trigger accidental invocation of the virtual cast button
against the voter’s wishes. While calibration issues may
still affect the ability of a user to scroll through a multi-
4.4 Reducing the complexity of trusted screen confirmation process, we anticipate that such a
components problem will be easier to recover from than touch screen
miscalibrations causing the DRE to incorrectly store a
We now discuss further aspects of our design that facili-
vote. To ensure that a malicious VoteSelection module
tate the creation of implementations with minimal trusted
does not trick the user into pressing the cast button pre-
code.
maturely, the VoteConfirmation module will only enable
Resets. Each module (except for the ResetModule) in- the cast button after it detects that the user paged through
teracts with the ResetModule via three wires, the initial all the vote confirmation screens.
values of which are all low: a ready wire controlled by We want voters to be able to cancel the voting process
the component and reset and start wires controlled by at any time, regardless of whether they are interacting
the ResetModule. The purpose of these three wires is to with the VoteSelection or VoteConfirmation modules.
coordinate resets to avoid a situation where one compo- Since the VoteSelection module is untrusted, one pos-
nent believes that it is handling the i-th voter while an- sibility would be to have the IOMultiplexor implement
other component believes that it is handling the (i+1)-th a virtual cancel button or conditionally pass data to the
voter. VoteConfirmation module even when the VoteSelection
The actual interaction between the wires is as follows. module is active. Rather than introduce these complexi-
When a component first boots, it waits to complete any ties, we chose to have the VoteCore module handle can-
internal initialization steps and then sets the ready wire cellation via a physical cancel button. The cancel button
high. The component then blocks until its start wire is enabled (and physically lit by an internal light) until
goes high. After the ready wires for all components the VoteCore begins the process of storing a ballot and
connected to the ResetModule go high, the ResetModule canceling an authentication token.
sets each component’s start wire high, thereby allowing
all components to proceed with handling the first voting
session.
5 Prototype implementation
Upon completion of a voting session, i.e., after re- To evaluate the feasibility of the architecture presented in
ceiving a signal from the VoteCore component, the Section 4, we built a prototype implementation. Our pro-
ResetModule sets each component’s reset wire high. totype uses off-the-shelf “gumstix connex 400xm” com-
This step triggers each component to reset. The puters. These computers measure 2cm by 8cm in size,
ResetModule keeps the reset wires high until all the cost $144 apiece, and contain an Intel XScale PXA255
component ready wires go low, meaning that the com- processor with a 400 MHz StrongARM core, 64 MB of
ponents have stopped executing. The ResetModule sub- RAM, and 16 MB of flash for program storage. We en-
sequently sets the reset wire low, allowing the compo- able hardware isolation by using a separate gumstix for
nents to reboot. The above process with the ready and each component in our architecture.
start wires is then repeated. We do not claim that the gumstix would be the best
Cast and cancel buttons. Our hardware architecture way to engineer an actual voting system intended for use
uses two physical buttons, a cast button and a cancel but- in the field. However, the gumstix have many advantages
ton. These buttons directly connect the user to an indi- as a platform for prototyping the architecture. In con-
vidual component, simplifying the task of establishing junction with an equally sized expansion board, the pro-
a trusted path for cast and cancel requests. Our use of a cessors support three external RS-232 serial ports, which
hardware button (rather than a user interface element dis- transmit bidirectional data at 115200 kbps. We use se-
played on the LCD) is intended to give voters a way to rial ports as our buses. Additionally, each gumstix sup-
know that their vote will be cast. If we used a virtual cast ports many general purpose input/output (GPIO) regis-
button, a malicious VoteSelection module could draw a ters, which we use for our wires. Finally, the XScale

10. Figure 4: We show the front and back of a gumstix as Figure 5: The mounting board for a single component. It
well as an expansion board through which the GPIO and contains three serial ports (along the top), 4 GPIO pins
serial ports are soldered. The quarter gives an indication and a ground pin (along the right side), as well as a gum-
of the physical size of these components. stix processor board mounted atop an expansion board.
processor supports an LCD and touch screen interface.
on our expansion board and allow two components to be
The gumstix platform’s well-designed toolchain and interconnected via their exposed GPIO pins. Each GPIO
software environment greatly simplified building our pin can be set in a number of modes. The processor can
prototype. The gumstix, and our prototype, use a min- set the pin “high” so that the pin has a 3.3 volt difference
imal Linux distribution as their operating system. Our between the reference ground; otherwise, it is low and
components are written in Java and run on the Mi- has a 0 voltage difference between ground. Alternatively,
crodoc J9 Java VM; its JIT provides a significant speed a processor can poll the pin’s state. To enforce the uni-
advantage over the more portable JamVM Java inter- directional communication property, particularly when a
preter. Our choice of Java is twofold: it is a type-safe single wire is connected to more than two GPIOs, we
language and so prevents a broad range of exploits; sec- could use a diode, which allows current to flow in only
ondly, several program verification tools are available one direction 4 . We currently rely on software to enforce
for verifying invariants in Java code [8, 19]. C# is an- that once a GPIO is set high, it cannot ever be set low
other natural language choice since it too is type-safe without first restarting the process; this is a property one
and the Spec# [5] tool could aid in verification, but C# could enforce in hardware via a latch, though our current
is not supported as well on Linux. We view a rich sta- prototype does not do so yet.
ble of effective verification tools to be just as important
In addition to the GPIOs, the PXA255 exposes an
as type-safety in choosing the implementation language
NRESET pin. Applying a 3.3v signal to the NRESET
since software tools can improve confidence in the voting
pin causes the processor to immediately halt execution;
software’s correctness. Both can eliminate large classes
when the signal is removed, the processor begins in a
of bugs.
hard boot sequence. The gumstix are able to reboot in
under 10 seconds without any optimizations, making the
5.1 Implementation primitives NRESET pin nearly ideal to clear a component’s state
during a reset. Unfortunately, the specifics of the reboot
Our architecture requires implementations of two sepa-
sequence causes slight problems for our usage. While the
rate communications primitives: buses and wires. It is
NRESET wire is held high, the GPIO pins are also high.
straightforward to implement buses using serial ports on
In the case where one component reboots before another
the gumstix. To do so, we expose connectors for the se-
(or where selective components are reboot), setting the
rial ports via an expansion board connected to the main
GPIOs high will inadvertently propagate a signal along
processor. Figures 4 and 5 show an example of such an
the wire to the other components. Ideally, the pins would
expansion board. We additionally disable the getty ter-
be low during reset. We surmise that designing a chip
minal running on the serial ports to allow conflict free use
for our ideal reset behavior would not be difficult given
of all three serial ports. The PXA255 processor has 84
GPIO pins, each controlled by registers; we implement 4 Even this may not be enough, since an actual diode does not be-
wires using these GPIOs. A few of the pins are exposed have as the idealized diode we rely upon.

11. Figure 6: A picture of our prototype implementation.
There is one board for each component in the system. Figure 7: The right image shows a screenshot of the
The magnetic swipe card (along the left) is used for au- VoteSelection component displaying referenda from the
thentication, while the cast button is in the upper left November 2005 election in Berkeley, CA. We flipped a
component. coin to choose the response shown on this screen.
sufficient hardware expertise. Since the microprocessors kind of removable storage device to store the ballot def-
in our platform do not exhibit our ideal behavior, in our inition file. In our prototype, we hard-code a sample
prototype we have a separate daemon connected to an ballot definition file into the VoteSelection component.
ordinary GPIO wire that stops the Java process running This suffices for our purposes in gauging the feasibility
the component code when the reset pin goes high and of other techniques.
then resets all wire state to low. The daemon starts a new Our prototype consists of five component boards wired
component process when the signal to its reset pin is re- together in accordance with Figure 3. We implement all
moved. This is just a way of emulating, in software, the of the functionality except for the cancel button. See Fig-
NRESET semantics we prefer. Of course, a production- ure 6 for a picture showing the five components and all
quality implementation would enforce these semantics in of their interconnections. Communication uses physical
trusted hardware. buses and wires. The I/O multiplexer, after each update
We use a Kanecal KaneSwipe GIT-100 magnetic card operation, sends an image over a virtual bus connected
reader for authorizing voters to use the machine. A voter (connected via the USB network) to the PC for I/O. It
would receive a card with authentication information on sends the compressed image it would ordinarily blit to
it from poll workers upon signing in. The voter cannot the framebuffer to the PC so that the PC can blit it to its
forge the authentication information (since it contains a display. The gumstix only recently supported LCD dis-
public key signature), but can use it to vote once on a plays, and we view our PC display as an interim solution.
designated DRE. The reader has an RS-232 interface, so The additional software complexity for using the LCD is
we are able to use it in conjunction with the serial port minimal as it only requires blitting an image to memory.
on the gumstix. Figure 7 shows our voting software running on the
gumstix. We used ballot data from the November 2005
Finally, our implementation of the VoteCore compo-
election in Alameda County, California.
nent uses a compact flash card to store cast ballot im-
ages and invalid magcard identifiers. Election officials
can remove the flash card and transport it to county head- 6 Evaluation
quarters after the close of polls. A deployed DRE might
use stronger privacy-protection mechanisms, such as 6.1 Verifying the desired properties
a history-independent, tamper-evident, and subliminal-
free data structure [25]. For redundancy, we expect a Property 1. Recall that to achieve “memorylessness”
deployed DRE to also store multiple copies of the votes we must be able to show the DRE is always reset af-
on several storage devices. A full implementation of ter a voter has finished using the machine, and the DRE
the VoteSelection component would likely also use some only opens a given file read-only or write-only, but not