Varch use06

374 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
374
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Varch use06

  1. 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 inWe provide techniques to help vendors, independent test- the body of this paper. Verification of these properties, asing agencies, and others verify critical security properties well as the others we describe elsewhere in this paper, arein direct recording electronic (DRE) voting machines. a step towards the full verification of a voting machine.We rely on specific hardware functionality, isolation, andarchitectural 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 anywill help us verify other properties as well. Verification subsequent voter’s sessions1 .of these security properties is one step towards a fullyverified voting machine, and helps the public gain con- One way to understand this property is to consider afidence 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 indeliblying a prototype implementation based on the design in storing the ballot, it erases all traces of the voter’s actionsJava and C. from its RAM. This way, a DRE cannot use the voter’s choices in making future decisions. A DRE that achieves1 Introduction Property 1 will prevent two large classes of attacks: one against election integrity and another against privacy. AWith 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 a33, 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 votingmachines? 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 withsecurity 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 propertiesand 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 wasperformed 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 notand CNS-0524252. allow subsequent voters to vote.
  2. 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 hardwareDiebold AccuVote-TS electronic voting machine con- isolation techniques. This simple idea greatly reducessists 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) needsand 2. One problem with current DRE systems, in other to be examined during a code review for many securitywords, 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, theirnificantly reduces the size of the TCB for verification execution should be independent. We use hard resets toof 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 privacyplementations can be verified to be free of malicious breaches and ensuring that all voters are treated equallylogic. 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 preservesformal methods) or otherwise audited (e.g., in an infor- the voting experience that voters are used to with currentmal line-by-line source code review) before we can trust DREs. It is compatible with accessibility features, suchthe 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 featuressumes 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 overviewto 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, aand procedures: pre-voting, ballot preparation, audit trail processor, and a computer screen that presents a votermanagement, post-election, recounts, and an associated with election choices and records their selections so theyset of safeguard procedures. Our system only addresses can be counted as part of the canvass. These devicesthe active voting phase. As such, we do not claim that our often use an LCD and touch screen to interact with thesystem 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 toa 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 stepsindicates who they wish to vote for; and a vote confirma- for DRE-based voting. In the pre-voting stage, electiontion 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 beand confirm these selections before casting their ballot. very complex [24], containing not only a list of races andThe vote selection code is potentially the most complex values indicating how many selections a voter can makepart of the system, due to the need for complex user inter- for each race, but also containing copies of the ballotsface logic. However, if the confirmation process is easy in multiple languages, audio tracks for visually impairedto verify, we can verify many important security prop- voters (possibly also in multiple languages), fields thaterties 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 ballota fair comparison with our work, we look at source lines of code, whichexcludes 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. 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 GFigure 1: Major steps in the voting process when using DREs. The shaded portions are internal to the DREs. In thiswork, 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 thiserally print a “zero tape,” which shows that no one cast a particular measure has been used in practice. While theseballot 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, shemust first interact with election officials to prove that sheis eligible to vote. The election officials then give her 3 Goals and assumptionssome token or mechanism to allow her to authenticateherself to the DRE as an authorized voter. Once the DRE Security goals. For clarity, in the body of this paper weverifies the token, the DRE displays the ballot informa- focus on enabling efficient verification of Properties 1tion 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 1ice’s party affiliation. After Alice selects the candidates reflects a privacy goal: an adversary should not be ableshe wishes to vote for, the DRE displays a “confirmation to learn any information about how a voter voted besidesscreen” 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 ofreturn 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 shouldinvalidates 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 classesFinalization & 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 onethen prints a “summary tape,” containing an unofficial that, when mounted, has the potential of affecting a broadtally of the number of votes for each candidate. Poll number of deployed DREs. A classic example might be aworkers then transport the removable storage medium software engineer at a major DRE manufacturer insertingcontaining cast ballot images, along with the zero tape, malicious logic into her company’s DRE software. Priorsummary tape, and other materials, to a central facility work has provided evidence that this it is a concern forfor tallying. During the canvass, election officials accu- real elections [3]. Such an attack could have nationwidemulate 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 wholesaleAdditional steps. In addition to the main steps above, attacks is one of our primary goals. In contrast, a retailelection officials can employ various auditing and test- attack is one restricted to a small number of DREs or aing procedures to check for malicious behavior. For ex- particular polling location. A classic retail attack mightample, some jurisdictions use parallel testing, which in- be a poll worker stuffing ballots in a paper election, orvolves 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 thevote-tallying process with a third-party tallying applica- • Protects against wholesale attacks by election offi-
  4. 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 possiblegoals: 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 recordWe 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 motivationssigned or implemented. Also, we are less concernedabout 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 goual voting machine one-by-one, which is not practical to through a series of design exercises starting from currentdo 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 thator, 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 singleintegrity 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 theher own. Since this attack is possible, we also do not ballot, and administrative functions—are all a part of thetry 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 totion 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. Supposeprevent unauthorized modifications to the voting ma- after every voter has voted, the voting machine is turnedchine’s hardware or software. Consequently, the prob- off and then restarted. This is enough to ensure thatlem 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 startsgrades to the voting system firmware and software may up. Of course, the prior voter’s selections must still beoccasionally be necessary, we do not consider how to se- recorded on permanent storage (e.g., on disk) for latercurely distribute software, firmware, and patches, nor do counting, so we also need some mechanism to preventwe consider version control between components. the machine from reading the contents of that storageAttentive voters. We assume that voters are attentive. medium. One conservative strategy would be to simplyWe require voters to check that the votes shown on the require that any file the DRE writes to must always be
  5. 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 eFigure 2: Our architecture, at an abstract level. For the properties we consider, the VoteSelection module need not betrusted, 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) mayas the DRE does not have the ability to write to them. have an easier time reasoning about the casting processThus the set of files on permanent storage are partitioned if it is isolated from the rest of the voting process. Ininto two classes: a set of read-only files (which cannot our architecture, we take this approach in combining thebe 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 waitingoverwriting 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 theto manage the reset process. The BallotBox triggers the VoteConfirmation module has limited functionality, itResetModule after a ballot is stored. The reset module only needs limited support for GUI code; as we showthen reboots a large portion of the DRE and manages the in Section 6.1 we can more easily analyze its correctnessstartup process. We use a separate component so that it since its scope is limited. If the voter decides to modifyis 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 thennique we can implement that reduces the problem of en- VoteConfirmation. There are two ways to mediate theforcing Property 1 to the problem of enforcing a checklist voter’s interactions with the two components: 1) endowof 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 aterty 2, which requires the voter’s consent to cast in order a time. The latter approach has a number of favorablefor the ballot to be stored, we will again see how mod- features. Perhaps the most important is that it preservesifying 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. 6. to change their voting patterns, and can introduce the op- ing token. In our implementation, we use a magneticportunity for confusion or even security vulnerabilities. stripe card, but the token could also be a smartcard or aAnother advantage is cost: a second screen adds cost and piece of paper with a printed security code. Each votingcomplexity. 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 contentsappropriate 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 withVoteSelection 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 theand 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 theResetModule 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., aproval? 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 theTo 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 withavoid 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 VoteConfirmationtion module, acts as a gate to stop the ballot between the module. The VoteConfirmation module interacts withVoteSelection and VoteCore modules. The software in the voter via the IOMultiplexor, displaying a summarythe VoteConfirmation module does not send the ballot screen indicating the current selections and promptingto 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 ballotit 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 thatwe achieve this property based on the code and architec- the data that the VoteConfirmation module sends to theture. 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: adesign 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 fromproperties and sketch how we can verify them with the the VoteConfirmation module, the VoteCore atomicallycurrent 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 theprocess 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 both4.2 Detailed module descriptions complete, the VoteCore will trigger a reset by sending aVoter authentication. After a voter signs in at a polling 3 A ballot image is merely a list of who this voter has voted for. Itstation, an election official would give that voter a vot- need not be an actual image or picture.
  7. 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 ining 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 cannotnal 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 architecturefrom the reset, they will inform the ResetModule. Af- consequently reduces to verifying the physical separationter all components are awake, the ResetModule tells all of the hardware and verifying the interconnects betweenthe components to start, thereby initiating the next vot- them. Historically, the security community has focuseding 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 hasprocess; when a voter triggers a reset in this way, the fallen dramatically enough that today hardware isolationvoter’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 theEnforcing 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 describecussion 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 componentsrity of our design. Directly connecting the LCD and are used, one should ensure that the same versions oftouch 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 andtrol 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 ofmodule when she is actually interacting with mali- state; they can be either high or low, and typically arecious 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 othertrol over the LCD and touch screen at a time: either component (the receiver) will read the value of the wireVoteConfirmation 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 highprecedence: if it requests control, it is given exclusive until its controlling component is reset. We assume thataccess 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 ourOur 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 itponent cannot tamper with or observe the state or code receives an out-of-band signal to stop transmitting. Theof 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. 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 asUsing 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 votethe VoteCore module reads a valid token, it repeatedly selection phase to the vote confirmation phase, thesends the data on the token to VoteSelection until it re- VoteConfirmation module will receive a ballot from theceives 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 VoteSelectioncomponent creates a bitmap of an image, packages that module, and then only handle input and output for theimage into a message , and repeatedly sends that message VoteConfirmation module (ignoring any messages fromto 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 VoteSelectionquence 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 tounique button name and the x- and y-coordinates of the VoteConfirmation to repeatedly acknowledge that thisregion. The IOMultiplexor will continuously read from wire is high. After receiving this acknowledgment, theits 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 thesequence 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 willputs correspond to a virtual button and, if so, repeatedly clear all its input and output buffers and return to han-
  9. 9. dling the input and output for VoteSelection. The pur- spoofed cast button on the LCD and swallow the user’spose for the handshake between the VoteConfirmation vote, making the voter think that they have cast their votemodule and the VoteSelection module is to prevent the when in fact nothing was recorded and leaving the voterVoteConfirmation module from resetting and then im- with no way to detect this attack. In contrast, a physicalmediately triggering on the receipt of the voter’s previ- cast button allows attentive voters to detect these attacksous 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 coulditself). 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 aWe now discuss further aspects of our design that facili- vote. To ensure that a malicious VoteSelection moduletate 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 enableResets. Each module (except for the ResetModule) in- the cast button after it detects that the user paged throughteracts 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 processthe component and reset and start wires controlled by at any time, regardless of whether they are interactingthe 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 implementother component believes that it is handling the (i+1)-th a virtual cancel button or conditionally pass data to thevoter. 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 buttonhigh. The component then blocks until its start wire is enabled (and physically lit by an internal light) untilgoes high. After the ready wires for all components the VoteCore begins the process of storing a ballot andconnected to the ResetModule go high, the ResetModule canceling an authentication token.sets each component’s start wire high, thereby allowingall components to proceed with handling the first votingsession. 5 Prototype implementation Upon completion of a voting session, i.e., after re- To evaluate the feasibility of the architecture presented inceiving 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 PXA255component ready wires go low, meaning that the com- processor with a 400 MHz StrongARM core, 64 MB ofponents 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 fornents 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 bestCast and cancel buttons. Our hardware architecture way to engineer an actual voting system intended for useuses two physical buttons, a cast button and a cancel but- in the field. However, the gumstix have many advantageston. 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, whichhardware 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. 10. Figure 4: We show the front and back of a gumstix as Figure 5: The mounting board for a single component. Itwell as an expansion board through which the GPIO and contains three serial ports (along the top), 4 GPIO pinsserial 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 GPIOsoftware environment greatly simplified building our pin can be set in a number of modes. The processor canprototype. The gumstix, and our prototype, use a min- set the pin “high” so that the pin has a 3.3 volt differenceimal Linux distribution as their operating system. Our between the reference ground; otherwise, it is low andcomponents 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 apreter. Our choice of Java is twofold: it is a type-safe single wire is connected to more than two GPIOs, welanguage and so prevents a broad range of exploits; sec- could use a diode, which allows current to flow in onlyondly, several program verification tools are available one direction 4 . We currently rely on software to enforcefor verifying invariants in Java code [8, 19]. C# is an- that once a GPIO is set high, it cannot ever be set lowother natural language choice since it too is type-safe without first restarting the process; this is a property oneand the Spec# [5] tool could aid in verification, but C# could enforce in hardware via a latch, though our currentis 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 anas type-safety in choosing the implementation language NRESET pin. Applying a 3.3v signal to the NRESETsince 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 aof bugs. hard boot sequence. The gumstix are able to reboot in under 10 seconds without any optimizations, making the5.1 Implementation primitives NRESET pin nearly ideal to clear a component’s state during a reset. Unfortunately, the specifics of the rebootOur architecture requires implementations of two sepa- sequence causes slight problems for our usage. While therate 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 anotherthe gumstix. To do so, we expose connectors for the se- (or where selective components are reboot), setting therial ports via an expansion board connected to the main GPIOs high will inadvertently propagate a signal alongprocessor. Figures 4 and 5 show an example of such an the wire to the other components. Ideally, the pins wouldexpansion board. We additionally disable the getty ter- be low during reset. We surmise that designing a chipminal running on the serial ports to allow conflict free use for our ideal reset behavior would not be difficult givenof all three serial ports. The PXA255 processor has 84GPIO 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. 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 theThe magnetic swipe card (along the left) is used for au- VoteSelection component displaying referenda from thethentication, while the cast button is in the upper left November 2005 election in Berkeley, CA. We flipped acomponent. 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 sampleprototype 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 feasibilitythe 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 wiredcomponent process when the signal to its reset pin is re- together in accordance with Figure 3. We implement allmoved. 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 allquality implementation would enforce these semantics in of their interconnections. Communication uses physicaltrusted 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 connectedreader for authorizing voters to use the machine. A voter (connected via the USB network) to the PC for I/O. Itwould receive a card with authentication information on sends the compressed image it would ordinarily blit toit from poll workers upon signing in. The voter cannot the framebuffer to the PC so that the PC can blit it to itsforge 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 iswe 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 officialscan remove the flash card and transport it to county head- 6 Evaluationquarters after the close of polls. A deployed DRE mightuse stronger privacy-protection mechanisms, such as 6.1 Verifying the desired propertiesa 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 DREthe VoteSelection component would likely also use some only opens a given file read-only or write-only, but not

×