26-07-2012, 11:31 AM
Analysis of an Electronic Voting System
vote.pdf (Size: 114.72 KB / Downloads: 18)
Abstract
We present a security analysis of the source code to one such
machine used in a significant share of the market. Our analysis shows that this voting system is far below
even the most minimal security standards applicable in other contexts. We identify several problems
including unauthorized privilege escalation, incorrect use of cryptography, vulnerabilities to network
threats, and poor software development processes. We show that voters, without any insider privileges,
can cast unlimited votes without being detected by any mechanisms within the voting terminal software.
Furthermore, we show that even the most serious of our outsider attacks could have been discovered
and executed without access to the source code. In the face of such attacks, the usual worries about
insider threats are not the only concerns; outsiders can do the damage. That said, we demonstrate that
the insider threat is also quite considerable, showing that not only can an insider, such as a poll worker,
modify the votes, but that insiders can also violate voter privacy and match votes with the voters who
cast them. We conclude that this voting system is unsuitable for use in a general election. Any paperless
electronic voting system might suffer similar flaws, despite any “certification” it could have otherwise
received.
Introduction
Elections allow the populace to choose their representatives and express their preferences for how they will
be governed. Naturally, the integrity of the election process is fundamental to the integrity of democracy
itself. The election system must be sufficiently robust to withstand a variety of fraudulent behaviors and
must be sufficiently transparent and comprehensible that voters and candidates can accept the results of
an election. Unsurprisingly, history is littered with examples of elections being manipulated in order to
influence their outcome.
The design of a “good” voting system, whether electronic or using traditional paper ballots or mechanical
devices, must satisfy a number of sometimes competing criteria. The anonymity of a voter’s ballot must be
preserved, both to guarantee the voter’s safety when voting against a malevolent candidate, and to guarantee
that voters have no evidence that proves which candidates received their votes. The existence of such
evidence would allow votes to be purchased by a candidate. The voting system must also be tamper-resistant
to thwart a wide range of attacks, including ballot stuffing by voters and incorrect tallying by insiders.
Another factor, as shown by the so-called “butterfly ballots” in the Florida 2000 presidential election, is the
importance of human factors. A voting system must be comprehensible to and usable by the entire voting
population, regardless of age, infirmity, or disability. Providing accessibility to such a diverse population is
an important engineering problem and one where, if other security is done well, electronic voting could be
a great improvement over current paper systems. Flaws in any of these aspects of a voting system, however,
can lead to indecisive or incorrect election results.
System overview
The Diebold AccuVote-TS 4.3.1 system we analyzed [9], which was written in C++, was designed to run on
a Windows CE device, an example of which is shown in Figure 1. The code also compiles and runs (with
slightly different configurations) on regular Microsoft Windows machines, thus enabling us to verify that
the code represents a complete system. We shall refer to a device running the vote collection software as a
voting terminal. Below we describe the process for setting up and running an election using the Diebold system. In some
cases, where election procedures and policies might vary or where we have insufficient information from
studying the code, we will state our assumptions. We note that, even in cases where election policies and
procedures might provide protection against design shortcomings, those policies and procedures depend on
poll workers who may not fully understand or be able to carry out their responsibilities. As a result, any
failure in the design of the voting system may very well be abused to compromise an election.
Smartcards
While it is true that one can design secure systems around the use of smartcards, merely the use of smartcards
in a system does not imply that the system is secure. The system must use the smartcards in an intelligent
and security-conscious way. Unfortunately, the Diebold system’s use of smartcards provides very little (if
any) additional security and, in fact, opens the system to several attacks.
Exploiting the lack of cryptography: Creating homebrew smartcards
Upon reviewing the Diebold code, we observed that the smartcards do not perform any cryptographic operations.
This, in and of itself, is an immediate red flag. One of the biggest advantages of smartcards over
classic magnetic-stripe cards is the smartcards’ ability to perform cryptographic operations internally, and
with physically protected keys. Because of a lack of cryptography, there is no secure authentication of the
smartcard to the voting terminal. This means that nothing prevents an attacker from using his or her own
homebrew smartcard in a voting terminal. One might naturally wonder how easy it would be for an attacker
to make such a homebrew smartcard. First, we note that user-programmable smartcards and smartcard readers
are available commercially over the Internet in small quantities and at reasonable prices. Second, an
attacker who knows the protocol spoken between voting terminals and legitimate smartcards could easily
implement a homebrew card that speaks the same protocol. We shall shortly consider how an attacker might
go about learning the protocol if he or she does not know it a priori.
Casting multiple votes
In the Diebold system, a voter begins the voting process by inserting a smartcard into the voting terminal.
Upon checking that the card is “active,” the voting terminal collects the user’s vote and then deactivates the
user’s card; the deactivation actually occurs by rewriting the card’s type, which is stored as an 8-bit value
on the card, from VOTER_CARD (0x01) to CANCELED_CARD (0x08). Since an adversary can make
perfectly valid smartcards, the adversary could bring a stack of active cards to the voting booth. Doing
so gives the adversary the ability to vote multiple times. More simply, instead of bringing multiple cards
to the voting booth, the adversary could program a smartcard to ignore the voting terminal’s deactivation
command. Such an adversary could use one card to vote multiple times. Note here that the adversary could
be a regular voter, and not necessarily an election insider.
Conclusions
Using publicly available source code, we performed an analysis of the April 2002 snapshot of Diebold’s
AccuVote-TS 4.3.1 electronic voting system. We found significant security flaws: voters can trivially cast
multiple ballots with no built-in traceability, administrative functions can be performed by regular voters,
and the threats posed by insiders such as poll workers, software developers, and janitors is even greater.
Based on our analysis of the development environment, including change logs and comments, we believe
that an appropriate level of programming discipline for a project such as this was not maintained. In fact,
there appears to have been little quality control in the process.
vote.pdf (Size: 114.72 KB / Downloads: 18)
Abstract
We present a security analysis of the source code to one such
machine used in a significant share of the market. Our analysis shows that this voting system is far below
even the most minimal security standards applicable in other contexts. We identify several problems
including unauthorized privilege escalation, incorrect use of cryptography, vulnerabilities to network
threats, and poor software development processes. We show that voters, without any insider privileges,
can cast unlimited votes without being detected by any mechanisms within the voting terminal software.
Furthermore, we show that even the most serious of our outsider attacks could have been discovered
and executed without access to the source code. In the face of such attacks, the usual worries about
insider threats are not the only concerns; outsiders can do the damage. That said, we demonstrate that
the insider threat is also quite considerable, showing that not only can an insider, such as a poll worker,
modify the votes, but that insiders can also violate voter privacy and match votes with the voters who
cast them. We conclude that this voting system is unsuitable for use in a general election. Any paperless
electronic voting system might suffer similar flaws, despite any “certification” it could have otherwise
received.
Introduction
Elections allow the populace to choose their representatives and express their preferences for how they will
be governed. Naturally, the integrity of the election process is fundamental to the integrity of democracy
itself. The election system must be sufficiently robust to withstand a variety of fraudulent behaviors and
must be sufficiently transparent and comprehensible that voters and candidates can accept the results of
an election. Unsurprisingly, history is littered with examples of elections being manipulated in order to
influence their outcome.
The design of a “good” voting system, whether electronic or using traditional paper ballots or mechanical
devices, must satisfy a number of sometimes competing criteria. The anonymity of a voter’s ballot must be
preserved, both to guarantee the voter’s safety when voting against a malevolent candidate, and to guarantee
that voters have no evidence that proves which candidates received their votes. The existence of such
evidence would allow votes to be purchased by a candidate. The voting system must also be tamper-resistant
to thwart a wide range of attacks, including ballot stuffing by voters and incorrect tallying by insiders.
Another factor, as shown by the so-called “butterfly ballots” in the Florida 2000 presidential election, is the
importance of human factors. A voting system must be comprehensible to and usable by the entire voting
population, regardless of age, infirmity, or disability. Providing accessibility to such a diverse population is
an important engineering problem and one where, if other security is done well, electronic voting could be
a great improvement over current paper systems. Flaws in any of these aspects of a voting system, however,
can lead to indecisive or incorrect election results.
System overview
The Diebold AccuVote-TS 4.3.1 system we analyzed [9], which was written in C++, was designed to run on
a Windows CE device, an example of which is shown in Figure 1. The code also compiles and runs (with
slightly different configurations) on regular Microsoft Windows machines, thus enabling us to verify that
the code represents a complete system. We shall refer to a device running the vote collection software as a
voting terminal. Below we describe the process for setting up and running an election using the Diebold system. In some
cases, where election procedures and policies might vary or where we have insufficient information from
studying the code, we will state our assumptions. We note that, even in cases where election policies and
procedures might provide protection against design shortcomings, those policies and procedures depend on
poll workers who may not fully understand or be able to carry out their responsibilities. As a result, any
failure in the design of the voting system may very well be abused to compromise an election.
Smartcards
While it is true that one can design secure systems around the use of smartcards, merely the use of smartcards
in a system does not imply that the system is secure. The system must use the smartcards in an intelligent
and security-conscious way. Unfortunately, the Diebold system’s use of smartcards provides very little (if
any) additional security and, in fact, opens the system to several attacks.
Exploiting the lack of cryptography: Creating homebrew smartcards
Upon reviewing the Diebold code, we observed that the smartcards do not perform any cryptographic operations.
This, in and of itself, is an immediate red flag. One of the biggest advantages of smartcards over
classic magnetic-stripe cards is the smartcards’ ability to perform cryptographic operations internally, and
with physically protected keys. Because of a lack of cryptography, there is no secure authentication of the
smartcard to the voting terminal. This means that nothing prevents an attacker from using his or her own
homebrew smartcard in a voting terminal. One might naturally wonder how easy it would be for an attacker
to make such a homebrew smartcard. First, we note that user-programmable smartcards and smartcard readers
are available commercially over the Internet in small quantities and at reasonable prices. Second, an
attacker who knows the protocol spoken between voting terminals and legitimate smartcards could easily
implement a homebrew card that speaks the same protocol. We shall shortly consider how an attacker might
go about learning the protocol if he or she does not know it a priori.
Casting multiple votes
In the Diebold system, a voter begins the voting process by inserting a smartcard into the voting terminal.
Upon checking that the card is “active,” the voting terminal collects the user’s vote and then deactivates the
user’s card; the deactivation actually occurs by rewriting the card’s type, which is stored as an 8-bit value
on the card, from VOTER_CARD (0x01) to CANCELED_CARD (0x08). Since an adversary can make
perfectly valid smartcards, the adversary could bring a stack of active cards to the voting booth. Doing
so gives the adversary the ability to vote multiple times. More simply, instead of bringing multiple cards
to the voting booth, the adversary could program a smartcard to ignore the voting terminal’s deactivation
command. Such an adversary could use one card to vote multiple times. Note here that the adversary could
be a regular voter, and not necessarily an election insider.
Conclusions
Using publicly available source code, we performed an analysis of the April 2002 snapshot of Diebold’s
AccuVote-TS 4.3.1 electronic voting system. We found significant security flaws: voters can trivially cast
multiple ballots with no built-in traceability, administrative functions can be performed by regular voters,
and the threats posed by insiders such as poll workers, software developers, and janitors is even greater.
Based on our analysis of the development environment, including change logs and comments, we believe
that an appropriate level of programming discipline for a project such as this was not maintained. In fact,
there appears to have been little quality control in the process.