Georgia Secretary of State Cathy Cox (D) casts the "inaugural" ballot on the new electronic voting system,
responding to the question "Which state is the first in the nation in efforts to reform elections?"
Secretary Cox, of course, chose Georgia from the states listed.  Note the "e" Card Smartcard Reader to
the side of the machine illustrating the general set up of the system allowing homebrew smartcards and multiple smartcards by unscrupulous voters.. 

end Page 7

MACHINE\Software\GlobalElectionSystems\AccuVote-TS4) . If the program fails to load
the registry information, it believes that it is uninitialized and therefore creates a new instance of the
CTSRegistryDlg class that asks the administrator to set up the machine for the first time. The administrator
chooses, among other things, the COM port to use with the smartcard reader, the directory locations
to store files, and the polling location identifier. The CBallotStationApp::DoRun() method then
checks for the presence of a smartcard reader and, if none found, gives the administrator the option to
interact with the CTSRegistryDlg again.

The DoRun() method then enters a while loop that iterates until the software is shut down. The
first thing DoRun() does in this loop is check for the presence of some removable media on which to
store election results and ballot configurations (a floppy under Windows or a removable storage card on
a Windows CE device). It then tries to open the election configuration file election.edb. If it fails
to open the configuration file, the program enters the CTSElectionDoc::ES_NOELECTION state and
invokes CBallotStationApp::Download(), which creates an instance of CTransferElecDlg to
download the configuration file. To do the download, the terminal connects to a back-end server using either
the Internet or a dial-up connection. The program then enters the CTSElectionDoc::ES_PREELECT
state, invokes the CBallotStationApp::PreElect() method, which in turn creates an instance
of CPreElectDlg. The administrator can then decide to start the election, in which case the method
CPreElectDlg::OnSetForElection() sets the state of the terminal to CTSElectionDoc::ES_
ELECTION.

Returning to the while loop in CBallotStationApp::DoRun(), now that the machine is in the
state CTSElectionDoc::ES_ELECTION, the DoRun() method invokes CBallotStationApp::
Election(), which creates an instance of CVoteDlg. When a card in inserted into the reader, the reader
checks to see if the card is a voter card, administrator card, or ender card. If it is an ender card, or if it is an
administrator card and if the user enters the correct PIN, the CVoteDlg ends and the user is asked whether
he wishes to terminate the election and, if so, the state of the terminal is set to CTSElectionDoc::
ES_POSTELECT. If the user entered a voter card, then DoVote() is invoked (here DoVote() is an
actual function; it does not belong to any class). The DoVote() function finds the appropriate ballot for
the user’s voter group or, if none exists, opens the nonpartisan ballot (recall that the system is designed to
allow voters to vote by group or party). It then creates an instance of CBallotDlg to display the ballot
and collect the votes.

We recall that if, during the election process, someone inserted an administrator or ender card into the terminal
and choses to end the election, the system would enter the CTSElectionDoc::ES_POSTELECT
state. At this point the voting terminal would offer the ability to upload the election results to some back-end
server for final tabulation. The actual transfer of results is handled by the CTransferResultsDlg::
OnTransfer() method.

We will present more details about the Diebold system in the following sections.


3 Smartcards

While it is true that one can design secure systems around the use of smartcards, simply 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.


3.1 Homebrew smartcards

Upon reviewing the Diebold code, we observed that the smartcards do not perform any cryptographic operations.
note 3 For example, authentication of the terminal to the smartcard is done “the old-fashioned way:” the
terminal sends a cleartext (i.e., unencrypted) 8-byte password to the card and, if the password is correct, the
card believes that it is talking to a legitimate voting terminal. Unfortunately, this method of authentication is
insecure: an attacker can easily learn the 8-byte password used to authenticate the terminal to the card (see
Section 3.3), and thereby communicate with a legitimate smartcard using his own smartcard reader.

Furthermore, there is no authentication of the smartcard to the device. This means that nothing prevents
an attacker from using his 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 many smartcard
vendors sell cards that can be programmed by the user. An attacker who knows the protocol spoken by the
voting terminal to the legitimate smartcard could easily implement a homebrew card that speaks the same
protocol. Even if the attacker does not a priori know the protocol, an attacker could easily learn enough
about the protocol to create new voter cards by attaching a “wiretap” device between the voting terminal and
a legitimate smartcard and observing the communicated messages. The parts for building such a device are
readily available and, given the privacy of voting booths, might be unlikely to be noticed by poll workers.
An attacker might not even need to use a wiretap to see the protocol in use. Smartcards generally use the
ISO 7816 standard smartcard message formats. Likewise, the important data on the legitimate voting card
is stored as a file (named 0x3D40 — smartcard files have numbers instead of textual file name) that can
be easily read by a portable smartcard reader. Again, given the privacy of voting booths, an attacker using
such a card reader would be unlikely to be noticed. Given the ease with which an attacker can interact with
legitimate smartcards, plus the weak password-based authentication scheme (see Section 3.3), an attacker
could quickly gain enough insight to create homebrew voting cards, perhaps quickly enough to be able to
use such homebrew cards during the same election day.

The only impediment to the mass production of homebrew smartcards is that each voting terminal
will make sure that the smartcard has encoded in it the correct m_ElectionKey, m_VCenter, and
m_DLVersion (see DoVote() in BallotStation/Vote.cpp). The m_ElectionKey and m_
DLVersion are likely the same for all locations and, furthermore, for backward-compatibility purposes it
is possible to use a card with m_ElectionKey and m_DLVersion undefined. The m_VCenter value
could be learned on a per-location-basis by interacting with legitimate smartcards, from an insider, or from
inferences based on the m_VCenter values observed at other polling locations.

It is worth pointing out that both the smartcards and readers supported by the code are available commercially
over the Internet in small quantities. The smartcards, model number CLXSU004KC0, are available
from CardLogix note 4 , where $33.50 buys ten cards. General purpose CyberFlex JavaCards from Schlumberger
cost $110 for five cards note 5 . Smartcard reader/writers are available in a variety of models for under $100 from
many vendors.

In the following two subsections we illustrate what an attacker could accomplish using homebrew smart-cards
in voting terminals running the Diebold code.

3 This, in an of itself, is an immediate red-flag. One of the biggest advantages of smartcards over classic magnetic-stripe cards
is the smartcard’s ability to perform cryptographic operations internally with physically protected keys. Since the smartcards in the
Diebold system do not perform any cryptographic operations, they effectively provide no more security than traditional magnetic-stripe
cards.
4 http://cardlogix.com/product_smart_select_most.asp
5 http://www.scmegastore.com


3.1.1 Multiple voting

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 changing the card’s type, which is stored as an 8-bit byte
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.

Will the adversary’s multiple-votes be detected by the voting system? To answer this question, we
must first consider what information is encoded on the voter cards on a per-voter basis. The only per-voter
information is a “voter serial number” (m_VoterSN in the CVoterInfo class). Because of the way the
Diebold system works, m_VoterSN is only recorded by the voting terminal if the voter decides not to place
a vote (as noted in the comments in TSElection/Results.cpp, this field is recorded for uncounted
votes for backward compatibility reasons). It is important to note that if a voter decides to cancel his or her
vote, the voter will have the opportunity to vote again using that same card (and, after the vote has been cast,
m_VoterSN will not be recorded).

Can the back-end tabulation system detect multiple-vote casting? If we assume the number of collected
votes becomes greater than the number of people who showed up to vote, and if the polling locations
keep accurate counts of the number of people who show up to vote, then the back-end system, if designed
properly, should be able to detect the existence of counterfeit votes. However, because m_VoterSN is only
stored for those who did not vote, there will be no way for the tabulating system to count the true number of
voters or distinguish the real votes from the counterfeit votes. This would cast serious doubt on the validity
of the election results. We point out, however, that we only analyzed the voting terminal’s code; we do not
know whether such checks are performed in the actual back-end tabulating system.


3.1.2 Administrator and ender cards

As noted in Section 2, in addition to the voter cards that users use when they vote, there are also administrator
cards and ender cards. These cards have special purposes in this system. Namely, the administrator
cards give the possessor the ability to access administrative functionality (namely, the administrative dia-log
BallotStation/AdminDlg.cpp), and both types of cards allow the possessor to end the election
(hence the term “ender card”).

Just as an adversary can manufacture his or her own voter cards, an adversary can manufacture his or
her own administrator and ender cards (administrator cards have an easily-circumventable PIN, which we
will discuss in Section 3.2). This attack is easiest if the attacker has knowledge of the Diebold code or can
interact with a legitimate administrator or ender card. However, an attacker without knowledge of the inner-workings
of the Diebold system and without the ability to interact directly with a legitimate administrator
or ender card may have a difficult time producing a homebrew administrator or ender card since the attacker
would not know what distinguishes an administrator or ender card from a normal voter card. (The distinction
is that, for a voter card m_CardType is set to 0x01, for an ender card m_CardType is set to 0x02, and
for an administrator card m_CardType is set to 0x04.)

As one might expect, an adversary in possession of such illicit cards has further attack options against
the Diebold system. Using a homebrew administrator card, a poll worker, who might not otherwise have
access to the administrator functions of the Diebold system but who does have access to the voting machines
before and after the elections, could gain access to the administrator controls. If a malicious voter entered an
administrator or ender card into the voting device instead of the normal voter card, then the voter would be


able to terminate the election and, if the card is an administrator card, gain access to additional administrative
controls.

The use of administrator or ender cards prior to the completion of the actual election represents an interesting
denial-of-service attack. Once “ended,” the voting terminal will no longer accept new voters (see
CVoteDlg::OnCardIn()) until the terminal is somehow reset. Such an attack, if mounted simultaneously
by multiple people, could shut down a polling place. If a polling place is in a precinct considered to
favor one candidate over another, attacking that specific polling place could benefit the less-favored candidate.
Even if the poll workers were later able to resurrect the systems, the attack might succeed in deterring
a large number of potential voters from voting (e.g., if the attack was performed over the lunch hour). If
such an attack was mounted, one might think the attackers would be identified and caught. We note that
many governmental entities do not require identification to be presented by a voter, instead allowing for
“provisional” ballots to be cast. By the time the poll workers realize that one of their voting terminals has
been disabled, the perpetrator may have long-since left the scene.


3.2 Unprotected PINs

When a user enters an administrator card into a voting terminal, the voting terminal asks the user to enter a
4-digit PIN. If the correct PIN is entered, the user is given access to the administrative controls.

Upon looking more closely at this administrator authentication process, however, we see that there is a
flaw with the way the PINs are verified. When the terminal and the smartcard first begin communicating,
the PIN value stored on the card is sent in cleartext from the card to the voting terminal. Then, when the user
enters the PIN into the terminal, it is compared with the PIN that the smartcard sent (CPinDlg::OnOK()).
If these values are equal, the system accepts the PIN. Herein lies the flaw with this design: any person with
a smartcard reader can easily extract the PIN from an administrator card. The adversary doesn’t even need
to fully understand the protocol between the terminal and the device: if the response from the card is n bytes
long, the attacker who correctly guesses that the PIN is sent in the clear would only have to try n ¡ 3 possible
PINs, rather than 10,000. This means that the PINs are easily circumventable. Of course, if the adversary
knows the protocol between the card and the device, an adversary could just make his own administrator
card, using any desired PIN (Section 3.1.2).


3.3 Terminal-to-card authentication

Let us now consider how the terminal authenticates to the card in more detail (note that this is different
from the Administrator PIN; here the terminal is being authenticated rather than the user). The relevant code
from VoterCard/CLXSmartCard.cpp is listed below. The code is slightly modified for illustrative
purposes, but the developers’ comments have been left intact.
SMC_ERROR CCLXSmartCard::Open(CCardReader* pReader)
{
... [removed code] ...
// Now initiate access to the card
// If failed to access the file then have unknown card
if (SelectFile(0x3d40) != SMC_OK)
st = SMC_UNKNOWNCARD;
// Else if our password works then all done
else if (Verify(0x80, 8, {0xed, 0x0a, 0xed, 0x0a, 0xed, 0x0a, 0xed, 0x0a})
== SMC_OK)
st = SMC_OK;
// Else if manufactures password works then try to change password
else if(Verify(0x80, 8, {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08})