An Independent Audit Framework for Software Dependent Voting Systems

Transcription

1 An Independent Audit Framework for Software Dependent Voting Systems Sujata Garera Johns Hopkins University Baltimore, MD Aviel D. Rubin Johns Hopkins University Baltimore, MD ABSTRACT The electronic voting machines known as Direct Recording Electronic (DRE), that are used in many states in the US have been shown to contain security vulnerabilities [16, 9, 3]. One of the problems is that the elections held on these machines cannot be independently audited. In this paper we address this issue by designing a new all-electronic independent audit framework for DRE voting systems. Our framework leverages system virtualization concepts and image recognition techniques to maintain an audit of the vote totals. The architecture we present is a step towards meeting the software independence requirements as defined by Rivest et al. [21,2]. Wehaveimplementedaprototypeusingthe Diebold Accuvote TS DRE voting software and the XEN hypervisor and demonstrate that our system can achieve a robust election audit with negligible overhead. Categories and Subject Descriptors D.2 [Software]: Software Engineering; D.2.11 [Software Engineering]: Software Architectures Domain-specific architectures General Terms Design, Reliability, Security Keywords Software Independence, Virtualization, Voting Audit 1. INTRODUCTION The US presidential election in 2000 exposed problems with accuracy and usability in the US voting system. Many of these issues stemmed from voting equipment problems such as the hanging chad in punch card ballots. To address these concerns the US governments pushed for a reformed election system to be administered before the next presidential election in This lead to the widespread de- Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CCS 07, October 29 November 2, 2007, Alexandria, Virginia, USA. Copyright 2007 ACM /07/ $5.00. ployment of electronic voting machines, popularly known as Direct Recording Electronic (DRE). While electronic voting machines offer potential improvements in usability, they have inherent security problems. Kohno et al. [16] analyzed the DRE software built by Diebold Inc. and show that the software does not meet minimal security standards. The authors provide substantial evidence demonstrating various flaws in the Diebold software, ranging from incorrect use of cryptographic primitives to poor software development practices. Feldman et al. [9] demonstrated that it is easy to install a vote stealing virus in these DRE machines. The virus steals votes from one candidate and assigns them to another, keeping the overall vote totals intact. More recently, Wagner et al. [3] conducted a complete top to bottom review of the Diebold voting system and showed that the system contains serious design flaws that an adversary could exploit to change the election outcome. Clearly there is a need for an independent audit system. NIST recently defined the notion of software independence for a voting system [21, 2]. (We explore this notion in detail in Section 2.) One of the key ingredients of software independence in voting is an independent audit mechanism that will work even if there are bugs in the voting system software. While voting systems such as the optical scan, or the DRE-VVPAT (Voter Verifiable Paper Audit Trail) provide means of independent audit, not all states in the US deploy these. Furthermore recent experiments by Goggin and Byrne [12] demonstrate issues concerning reliability of auditing using the VVPAT. In this paper we design an all-electronic framework for independent audit of the vote totals. Our design does not impose many hardware and software changes in the current DRE systems and maintains the usability of the DRE interface. The work we present here does not advocate that DRE systems should be deployed. This research is an effort towards developing a framework which can be deployed in states that do not use any means of independent audit. Note that our threat model does not include privacy and fault tolerance issues that arise in a voting system. Our primary contribution is an audit framework that can be easily deployed and which is extensible. The goal of our research is to provide a proof of concept. Our framework determines the vote cast through image comparison methods. We implement our technique in the device model of the XEN hypervisor, thereby eliminating the need to trust the Windows OS that runs the voting machine. We further show that our framework is robust against bugs in the voting machine by demonstrating that even if the 256

2 voting software has been maliciously altered to flip the votes, the auditing framework will still count the votes accurately. We do point out however, that with our framework trust needs to be placed in the XEN hypervisor. Eliminating this trust altogether is an area of future work. 2. SOFTWARE INDEPENDENCE Voting systems today need to meet several requirements including an accurate tally, privacy of the votes, usability of the interface and security against external attacks. Consequently, the resulting voting software is complex and is difficult to evaluate. Errors in the software, both accidental and intentional, can go un-noticed during all phases of development, during testing and even during certification. Furthermore such errors can also result in changes to the election outcome. While parallel testing methods [13] are useful in detecting some types of software errors, they are not sufficient for auditing elections. To address these concerns the notion of Software Independence was introduced by Rivest et al. [21]. Rivest et al. define Software Independence as follows: Definition 1. Software Independence: Avotingsystem is software-independent if an undetected change or error in its software cannot cause an undetectable change or error in an election outcome [21, 2]. Definition 2. Strong Software Independence: Avoting system is strongly software-independent if an undetectable change or error in its software, cannot cause an undetectable change or error in an election outcome, and moreover, a detected change or error in an election outcome (due to change or error in the software) can be corrected without re-running the election. Voting systems such as the DRE-VVPAT, when implemented properly, can potentially meet the software independence definition. The independent paper audit trail allows for detection of errors in the tallies. Of course, this assumes that voters actually check the paper records. Paper ballots counted by optical scanners, with spot random audits, are even better examples of software independent systems. We point out that the notion of software independence is also applicable in other domains. Take for example online gaming systems such as poker. Current poker systems provide no means of independent verification of a fair game, that is these systems are software dependent. Hence an error in the software can lead to the game being biased towards one player for instance a software bug in the random number generator used to deal the cards to the player can be exploited to cheat at the game. On the other hand, systems such as ATM machines, are software independent. Specifically, the transaction receipt canbeverifiedbytheusertoensurethathis/hertransaction updated his account balance correctly. Furthermore, in an event of an error the user can use this receipt to prove the flaw to the bank and thus ensure that the error is corrected, indicating that ATM machines achieve strong software independence. In the following section, we describe the high level virtualization concepts which moves us a step closer to software independence for DRE systems. We point out that our current framework achieves strong software independence for Virtual Machine Virtual Machine Application Application Application OS OS OS Virtual Machine Monitor Physical Hardware Virtual Machine Figure 1: A typical virtual machine architecture. Notice that the OS and applications are completely encapsulated and do not interact with the OS and applications residing in separate virtual machines the voting system only under certain conditions. Of course, we recognize that the audit system that we built is itself not software independent, but the idea is that in practice, the audit framework would be developed separately from the voting system, thus we consider our work a step towards software independence rather than true software independence. 3. ENCAPSULATION THROUGH VIRTUALIZATION Encapsulation is a technique of hiding the internal implementation details of an object from its external view [18, 19]. It is the common method of virtualization of systems and applications today. Virtualization, in its original sense, describes the process of using hardware and software to create a virtual machine. This concept originated in the 1960s. Popek and Goldberg in 1974 [20] formalized the requirements for system virtualization. They define a system virtual machine as one which is capable of virtualizing a full set of hardware resources (processor, memory, storage and peripherals). They further define a virtual machine monitor (VMM) which is the software interface that provides the abstraction of a virtual machine. The VMM creates the environment for a virtual machine. The system that runs the VMM is popularly known as the host, and the virtual machine system is commonly referred to as the guest. In system virtualization the guest system is usually an entire operating system. To an external user, the guest system appears as if it is running directly on the hardware. That is the guest operating system and its applications are completely encapsulated inside a virtual machine as depicted in Figure Applications of Virtualization Virtualization has a vast number of applications in security. Dunlap et al. [7] implement a replay service for virtual machines. Their system, ReVirt, logs information to replay long term execution of the virtual machine. Such an architecture is very useful for forensics, that is analyzing intrusions and attacks that might have occurred on the system (virtual machine). King et al. [15] introduce the notion of 257

3 time-traveling virtual machines and demonstrate its usefulness in finding non-deterministic bugs. Garfinkel and Rosenblum introduced a virtual machine introspection based architecture [11]. In their system, they shift the intrusion detection to the VMM level and the host to be monitored is placed in a virtual machine. The architecture we deploy in this paper, is very similar to that presented in [11]. In particular, to achieve independence from the voting machine we shift the audit mechanism to the VMM level. We detail this architecture in Section 3.2. Today, system virtualization can be accomplished through various methods. Emulation techniques [17, 1] simulate the entire hardware allowing an unmodified guest OS execution. Full virtualization [24] simulates just enough hardware for that purpose. Paravirtualization [6], on the other hand offers an interface which can be used by modifying the guest OS. Hence systems such as XEN cannot run closed source operating systems such as Windows unless the processor has support for virtualization technology [5]. With virtualization technology, full virtualization can be achieved in paravirtualization systems like XEN. 3.2 Virtualization and Software Independence With system virtualization one can achieve software independence for voting systems, with respect to the voting system software. The voting machine software can run inside the guest OS and an independent audit/monitoring mechanism can execute in the VMM or on the host OS. The audit mechanism is hence isolated from the voting software. Once again we point out that this assumes that the host OS is trusted. Recall that the goal of this research is to provide a mechanism for achieving software independence with respect to the voting system software in an environment where a decision has been made to use paperless electronic voting. We use XEN [6] to build an independent audit framework for the Diebold Accuvote TS DRE machine. The source code for XEN is freely available and we had access to the Diebold DRE source used in the analysis by Kohno et al. [16]. Note that this DRE runs on Windows. Thus, we require a processor which supports virtualization technology to run an unmodified Windows OS inside a virtual machine created by the XEN VMM. Figure 2 shows the basic architecture for instrumenting an independent audit. Domain-0 (Host OS) is an administrative VM in XEN responsible for controlling access to resources requested by the Guest OS. All interaction to and from this domain, has to go via the XEN VMM layer. The voting machine is run inside the Guest OS and hence is isolated from the Host OS and the XEN VMM. We implement our audit mechanism inside the Qemu Device Module (Qemu-DM) in the Host (Domain-0). The Qemu Device Module provides an abstraction of a PC platform to the Guest OS. This includes the devices such as the keyboard, mouse and VGA. Hence all input/output requests from the guest are handled by the Qemu-DM. The Qemu-DM is a good candidate for implementing the audit mechanism, because all user inputs to the voting machine (such as candidate selection) can be captured directly by the Qemu-DM. As depicted in the figure when an I/O request needs to be serviced, control passes into the Xen VMM. This is known as a VM Exit. When the I/O request is handled the control is returned to the Guest VM. This is known as a VM Entry. During a VM Exit the Guest is suspended until a VM Entry Qemu-DM (VoteAudit) Domain 0 Host (Linux OS) XEN VMM Voting Machine Guest VM (Windows OS) I/O Request I/O Handled Figure 2: Audit framework architecture in XEN occurs into the respective VM. This indicates that the Guest cannot alter the user input during a VM Exit, and hence the Qemu-DM can capture the correct input (candidate choice) as entered by the voter. Note that through virtualization the audit mechanism is isolated and independent from the voting machine software. This indicates that while errors in the voting machine software can cause changes in the outcome, these changes cannot be propagated to the audit mechanism. Thus irrespective of errors in the voting software, a correct vote count will always be maintained at the Domain-0 level of our architecture. This architecture thus achieves software independence, as defined in Definition 1, for DRE voting systems. In what follows we detail our audit algorithm and our implementation in Qemu-DM. We detail how the users voting choice is correctly captured and counted. We further discuss the complexity and performance implications of our algorithm and discuss how the algorithm can be improved. 4. AUDIT ALGORITHM The basic intuition behind our audit mechanism, is capturing the voter s choice (candidate selection) as it is entered and accordingly incrementing the respective candidate counter. On a DRE machine a voter enters his/her input to the system via a touchscreen. 1 Duringavotingsession,avoter interacts with several screens (GUI front end) of the voting software. These include, language selection screen, candidate selection screen, vote confirmation screen and the vote recorded screen. An election official, on the other hand can also interact with administrative screens in the voting software, such as the post election reporting screen. Note that the layout of the screens and the candidate ordering is decided by the ballot definition file which is created before the election occurs. The first phase of our algorithm, involves a priori identification of certain screens in a voting session. This concept of a priori screen selection is similar to the notion of prerendered user interfaces as popularized by Yee et al. [27]. However, the authors in [27], use the pre-rendered interface to reduce the complexity of the voting system and thereby ease software verification. This is different from our goal of 1 Since we did not have access to a touchscreen, we simulate the voter input via mouse clicks. 258

4 Post Election Not Voted where I = 100 P w P h x=0 y=0 δ(x, y) w h (1) Voted for A 7 10 Blank Ballot 8 Vote Recorded 9 Voted for B Figure 3: State diagram representing audit logic utilizing these a priori selected screens, to achieve a secure and independent election audit. 4.1 A priori Screen Selection. We identify the important screens of a voting session a priori. For our algorithm, these include the candidate selected screens, vote recorded screen, blank ballot cast screen and post election screen. We denote these as key screens of an election. We use the Qemu-DM to capture and store these screen pixmaps through the VGA capture interface exported by XEN. Note that these screen pixmaps are created only on user input (left mouse click) on the screen in consideration. In the Appendix we have included the important screen pixmaps obtained from the Diebold DRE software. Figures 9, 10, 11, 12 and 13 are the key screens. Each of these images are 2.3MB PPM type (portable pixel map) files and they are stored on the Host OS disk. The section that follows details how these screen pixmaps are used for auditing a voting session. 4.2 Identifying the Voter Selection. Figure 3 shows the basic state diagram of our audit mechanism. Note that each of the key screens has a corresponding state in the state diagram. Since we are dealing with an election between two candidates we have two states each corresponding to a voter having selected a particular candidate. To determine if the voting session has reached a particular state, or in other words to identify the voter selection, we compare the current input screen to the screens stored on the Host OS. Note that this comparison is performed on every input (mouse click) on the current input screen. Further note that unlike the a priori selected screens, which are stored on disk, the current input screen just has to be read from memory. Our comparison metric essentially determines the percentage number of pixels that differ between the current screen in consideration and the stored key screen. Let C denote the current screen, K denote a key screen, and pixel S(x, y) denote the pixel at location (x, y) of screen S. Each screen has a resolution of w x h pixels. The image difference metric, I, is then computed as follows. j 1 if pixelk(x, y) pixel δ(x, y) = C(x, y) 0 otherwise If I lies under a threshold t, then the images are similar. Otherwise, they are marked as different. Using this metric we determine the current state of the voting session. When a candidate has been selected and the vote has been recorded (transitions 1 and 7 or transitions 3 and 9 in Figure 3), the respective candidate counter is incremented. For a blank ballot (transitions 2 and 8) no counter is incremented. If a voter decides to review his choice then the audit logic is reset to the state not voted as indicated by transitions 4, 5 and 6. Only when the state vote recorded is reached the respective candidate counter is incremented. After the vote is recorded, the audit logic is set back to the not voted stated as indicated by transition 10. The results of the election are written to persistent storage (disk) on transition 12, which occurs when an election official inserts an administrator smart card to end the election. 4.3 Setting the threshold t. The percentage pixel difference threshold, t, should be set carefully. If this threshold is large, then it is possible that the current screen could be interpreted incorrectly. At thesametimethethresholdshouldbeabletotoleratesmall percentage differences. For instance there are portions of the screen that display the total votes recorded at a given time. As a result different instances of a screen in consideration, will not always be identical. Hence using a cryptographic hash (perfect image matching) for screen comparison is not suitable unless the non-static portions of the screens being compared are avoided. Image Difference Metric (I) Screen For Candidate A Screen For Candidate B Screen Vote Recorded (2) Screen of Voting Software Figure 4: sessions Image difference metric I over 2 voting Figure 4 shows a plot of the image difference metric, I, between the stored key screens and the current screen of an election. Note that while we have 5 key screens, for 259

5 Number of False Image Matches Candidate A Screen Candidate B Screen Vote Recorded Screen Blank Ballot Screen Post Election Screen Percentage Pixel Difference Threshold (t) Figure 5: Number of false image matches against t clarity purposes we have only depicted 3 of these screens on the graph. The horizontal axis on the graph depicts the current screen of a voting session. This graph was plotted over two voting sessions one in which the candidate A was selected and the other in which the candidate B was selected. Screen 10 and 17 correspond to the screens when candidate A and B were selected respectively. Screen 12 and 19 denote different instances of the vote recorded screen. The graph clearly indicates that our image difference metric can identify when a vote was cast and when it was recorded with 100% accuracy. In Figure 5 we plot the number of false image comparisons against varying threshold t. A positive false image match occurs when two different images have been identified to be the same. A negative false image match occurs when two similar images have been identified to be different. This graph was plotted over 5 voting sessions, the details of which are indicated in Table 1. 2 Note that the points corresponding to (0, 2) (a negative false match) in the graph indicate that, when the threshold t = 0%, 2 screens corresponding to Candidate A selection, and 2 screens corresponding to Vote Recorded were not identified correctly. In other words the zero threshold set did not tolerate small differences in 2 instances of the same image. This justifies our argument that a cryptographic hash and hence perfect image matching is not suitable for this algorithm. Further, we find if the threshold t is set between [0.06, 1.42] then very small changes on the screens in consideration can also be tolerated. If the threshold is increased beyond 1.42, then as depicted in the graph, the number of false image comparisons increases. Hence t should be set within the range [0.06, 1.42]. To set a right value for t within this range, we also consider the similarity between candidate names. Specifically, an attacker can alter the ballot definition such that the order of the candidate names is reversed (see Figure 14 and Figure 15 in Appendix). If the candidate names are very different then the audit mechanism can detect such a name swapping attack even if the threshold is set to the 2 Note that a cancelled vote indicates that the voter had selected a candidate but decided to cancel his vote by removing his voter card from the machine. Voting Action Screen in Consideration 3votescastforA, 2 of which were cancelled Number of Correct Image Matches A selected 3 1 vote cast for B B selected 1 1 blank ballot Blank ballot 1 cast 3 votes recorded Vote recorded 3 Post election operation Post election 1 Table 1: Voting actions and image comparisons corresponding to graph in Figure 5. maximum possible value. However if the candidate names are very similar, then it is possible that the audit mechanism will record the votes incorrectly. To ensure a correct audit in this scenario, the threshold t should be set taking into account the similarity between candidate names. We use edit distance to quantify this similarity. Figure 6 shows variation in the image difference metric against the edit distance between the candidate names. Image Difference Metric Edit Distance between Candidate Names Figure 6: Image difference metric I against edit distance. Note that I is computed over the candidate selection screens with correctly ordered names and flipped names respectively. Note that this curve is an approximation, considering that for different sets of candidate names, I can have slightly varying values for a particular edit distance. We observe that when the candidate names are very similar, that is their edit distance lies between [1, 4], the image difference metric is less than 0.1. For our experiments the edit distance between the candidate names was 11 and hence we set our pixel difference threshold t = 1. Only if the image comparison metric, I, is greater than 1% we mark the screens being compared as different. This threshold is sufficient to detect the name swapping attack. We discuss this attack further in Section 4.5. In the following Section we discuss the complexity and performance of our algorithm. We further improve the algorithm to increase its efficiency and compare its performance 260

6 Complete Partial Complete Partial with I with I with SHA with SHA (ms) (ms) (ms) (ms) Best Average Worst Table 2: Time overhead during image comparison on a mouse input. The table depicts both comparison using the image difference metric I and using SHA-1 hash. These measurements were taken over an election with 6 voting sessions. against the performance of image comparison using a cryptographic hash. 4.4 Complexity and Performance The complexity of the algorithm relies on the resolution of the VM screen. The image difference metric computation takes wh iterations for a VM screen of resolution w x h pixels. Further, if we have n candidates in an election, then a maximum of n + 3 screen comparisons will take place on a mouse input. 3 Hence, in the worst case our complexity is O(nwh). This complexity consequently affects the performance of an election. We implemented our algorithm on an Intel Mac Mini, 1.66GHz, 2GB RAM with Virtualization Technology support. Our host OS, an Ubuntu distribution (Linux 2.6), was allocated 1.5GB of memory and our guest, Windows XP, was allocated 512MB of memory. We remind the reader that the audit algorithm is run on the Host machine. The VM screen was of a resolution of 1024x768. To measure the performance overhead, we conducted an election with 6 voting sessions. This involved around 50 mouse inputs. On the host machine, the image comparison on a mouse input produces an added overhead of 446ms (averaged over 50 time measurements). We point out that this delay also includes the latency involved in reading the a priori stored 2.3MB key screens from disk into memory. Partial Image Comparison. We improved the efficiency of our algorithm by performing partial image matching instead of complete image matching. We compare only important portions of the candidate selection screen. Such partial image matching reduces the complexity due to the reduction in w and h during comparison. In our implementation, we compared only the candidate selected buttons and names (Refer to the Figures 9 and 10 in the Appendix). This reduced w x h from 1024x768 to 756x200. As a result, the image comparison overhead reduced to 283ms on average. Comparison with Hashing. For completeness we also compare image comparison using the image difference metric to image comparison using cryptographic hashing. As we indicated previously, portions of the key screens display information that changes. For instance the vote recorded key screen displays the continuously changing vote totals. Hence in order to use a cryptographic hash for comparison, it is essential that these non-static por- 3 The additional 3 screens correspond to blank ballot, post election and vote recorded screens. tions of the screen in consideration should not be incorporated when taking the hash. We achieve this by standardizing those portions of the screens being compared. As a result the image comparison using hashing requires additional image processing as compared to comparison using the image difference metric. We computed the overhead required for both complete and partial image comparison. For our implementation we chose to use the SHA-1 cryptographic hash. Table 2 depicts the overhead required for all of our algorithms. As expected we find that comparison using SHA-1 has a higher overhead than when using the image difference metric. The table depicts best case, average case and worst case times. In the best case scenario, only one image comparison will be required in order to determine the state of the voting machine. In the worst case, n + 3 comparisons will be required. 4 Our results clearly indicate that the image difference metric, I, produces a lower overhead in all scenarios as compared to hashing. Partial image comparison using I is the most efficient performance wise amongst the algorithms indicated in Table Achieving Strong Software Independence Currently our audit mechanism achieves strong software independence (refer to Definition 2) with respect to the voting system software only to a certain degree. In particular, if the voting software has been modified, so as to alter the votes, but ballot definition file has not be modified, then our current prototype will still maintain a correct audit on the host level. Recall that the ballot definition file defines the layout of the voting screens including the candidate ordering. In Attacks I and II detailed below we assume an adversary who is motivated to change the results of an election by swapping the votes between the candidates. Attack III however, assumes an adversary who is more inclined towards disrupting an election through a DOS attack. Attack I - Unaltered Ballot Definition. We altered the Diebold software to maliciously flip the votes for the candidates. In other words, votes cast for candidate A were recorded for candidate B and vice versa. 5 This was accomplished by altering just two lines of code, as indicated in the code snippets in Figure 7. As a result, the election results maintained in the guest OS were incorrect, but as the ballot definition was unaltered, the election results maintained by our audit system on the host OS were accurate. Hence our audit mechanism achieved strong software independence in this scenario. Attack II - Name swapping attack. Now, if the ballot definition is altered, for example the candidate names on the screen are reordered to launch a name swapping attack, then while the audit framework cannot correctly record the voter s choice, the algorithm detects that an error has occurred. In Figure 3, transition 11 is an undesired transition. The audit mechanism goes directly from the not voted state to the vote recorded state. This transition only occurs if the image comparison cannot determine the voter s choice, which in turn occurs if the ballot definition has been altered. 4 Recall that n denotes the number of candidates in the election. For our implementation n = 2. 5 Note that blank ballots were not considered in this attack. 261

7 File Name: RecordVoteDlg.cpp Line #203 Original Code: BOOL vote = resultsrecord.getvote(candidx++); Altered Code: BOOL vote =!(resultsrecord.getvote(candidx++)); File Name: BallotCell.cpp Line #1491 Original Code: BOOL voted=(candcell.getvote()==voted? 1 : 0); Altered Code: BOOL voted=!(candcell.getvote()==voted? 1 : 0); Figure 7: Original and altered lines of code in the Diebold software. We just added two negations to flip the votes from one candidate to another. Furthermore, this transition will occur provided the percentage pixel difference threshold, t, has been set in accordance with the edit distance between the candidate names. Hence, if during an audit, transition 11 is encountered, an alarm notification is sent to the XEN VMM which in turn fails safe by forcefully shutting down the guest VM. Attack III - Denial of Service. An adversary can also try and instrument a DOS attack by changing the entire ballot definition, and as a result causing each comparison to the key screens to fail. This would cause the audit mechanism to continuously stay in the state Not Voted. To deal with this attack scenario, we associate each state with a time threshold W. If the audit mechanism stays in a state for more than W hours then an alarm is raised and XEN fails safe. This threshold W must take into account the maximum time required for a voter to cast his vote. A recent study by the New York State Board of Elections showed that a person with special needs can take from 18 to 45 minutes to vote on ballot marking systems [23, 8]. Assuming that the time to vote on a DRE could be higher we set the threshold W = 2 hours. Although strong software independence is not achieved in Attack II and Attack III (that is a detected software error causes a change in the election outcome), the attack is still detected by the audit mechanism. 4.6 Analysis of the Trusted Computing Base Current DRE systems are built on the Windows operating system and consequently have a massive trusted computing base (TCB). In our architecture, we shift the trust from the DRE system to the Linux and XEN kernel. DRE System (SLOC) Windows OS: 40 million DRE and Audit Framework (SLOC) Linux OS: 5 million (linux xen) DRE: XEN: Audit Framework: 350 TCB Size: 40 million TCB Size: 5.5 million Table 3: TCB comparison Table 3 compares the approximate TCB size in Source Lines of Code (SLOC) between a DRE system and our audit framework. The lines of code for Windows were obtained from [26] and those for the Linux-XEN kernel and DRE were computed using the SLOCCount toolkit [25]. As indicated, eliminating trust from Windows significantly reduces the TCB size from around 40 million lines of code to around 5.5 million lines of code. Furthermore, our audit framework is open source. Hence the task of source code auditing and validation is considerably easier compared to auditing the DRE software. 5. SECURITY ANALYSIS In this section we provide claims discussing the security of our audit framework. In the discussion, F refers to the audit framework, A denotes the adversary and V denotes the voter. Claim 1. Assuming a single processor architecture, while F is capturing the VGA screen i, A cannot display a screen i to the voter V, andtransmitascreenj, j i to F. Proof. In Figure 8 we show the current architecture of the framework F. As shown in the figure, there is a shared memory area implemented between the Qemu-DM and the Guest OS. This memory area is for VGA writes and reads and is accessible to the adversary A that controls the Guest OS. 6 Qemu-DM Vote Audit Domain 0 Host (Linux) Shared VGA Memory VGA Read VGA Write XEN VMM Voting Machine Guest VM (Windows OS) I/O Request I/O Handled Figure 8: Audit framework architecture including VGA memory While it is possible for A to alter the memory region and hence the VGA screen, this modification of the memory region cannot be accomplished by A when F is capturing the VGA screen. We remind the reader that screen capture is performed on an input from the voter V, that is on a mouse click. In addition, during a mouse interrupt, the XEN-VMM gets a notification of an I/O request and a VM Exit occurs. As a consequence, the thread that controls the Guest OS is suspended (assuming a uni-processor architecture) until 6 Dong et al. [5] point out that originally every VGA write would cause a VM Exit into the XEN VMM. This design resulted in a huge performance overhead. Hence to speed up VGA writes a shared memory buffer was implemented between the Qemu-DM and the Guest OS. 262

8 the I/O request is handled and a VM Entry occurs. Thus, as A does not have control over the Guest OS during the mouse interrupt (and the screen capture), A cannot alter the shared VGA memory region. 7 Hence the audit framework F will always capture the screen i as displayed to the voter V. Claim 2. If A has not altered the ballot definition, F will always count the vote as it was cast by V. If the ballot definition is altered then F will raise an alarm. Proof. From Claim 1, it follows that the audit framework F will always capture the screen which the voter V viewed when entering his input. Further, since the image comparison algorithm in F, is executed on every input from the voter, F will capture the voters candidate choice correctly and hence the vote is counted as it was cast. Now, if the ballot definition is altered then as discussed in Section 4.5, F will either encounter an undesired transition or a time out, and as a result F will raise an alarm. 6. CONCLUSION AND FUTURE WORK In this paper we introduced a new framework for independent audit of DRE voting software. Our framework leverages system virtualization in order to remove reliance on the software in a DRE. The audit algorithm uses an image comparison technique to determine the vote cast by the voter. Our improved algorithm introduced an overhead of only 283ms on a mouse click. We analysed the security of our scheme and showed that it is hard for an adversary to prevent a vote from being counted as it was actually cast, and not be detected. Our current framework is extensible and opens up quite a few avenues for future work. We have not addressed the threat of Virtual Machine based root kits [14] in our architecture. If an adversary were able to install a VM root kit below the Guest VM, it is possible that he can intercept the communication between the Guest and the VMM and maybe even change the information being passed. King et al. suggest several measures to detect a VM root kit. These include using trusted computing platforms like Intel s LaGrande Technology [4], or a secure VMM [10]. We seek to extend our audit framework to detect and prevent VM root kits in future work. In our architecture we rely on software isolation techniques as they permit us to design a framework without any changes to the DRE hardware or software. We reduce the TCB size to around 5.5 million lines of code from 40 million lines of Windows code. While the open source nature of the audit framework makes the task of auditing and validation easier, the TCB size is still quite huge. Hardware isolation methods as introduced by Sastry et al. [22] would be even more instrumental in reducing the TCB size further with a few changes to the DRE hardware and software. Exploring such audit architectures is another possible area of future work. Acknowledgments We thank Yoshi Kohno for providing us with the Diebold software. We thank Edward Felten, Ariel Feldman and 7 It is possible that the adversary alters the memory region after the Guest OS resumes control. However this would not affect the correctness of the audit considering the screen capture takes place when the Guest is suspended. Alex Halderman for providing us their implementation of the GEMS server which allowed us to customize the ballot definition file. We thank David Wagner and Ryan Gardner for their useful feedback on this work. We thank the anonymous reviewers for their comments on this work. We also thank the Xen development team for their prompt responses to our questions on the mailing list. This research is funded by the NSF grant CNS REFERENCES [1] Fabrice Bellard. QEMU, a Fast and Portable Dynamic Translator. In Proceedings of USENIX 2005 Annual Technical Conference, FREENIX Track, pages [2] William Burr, John Kelsey, Rene Peralta, and John Wack. Requiring Software Independence in VVSG 2007: STS Recommendations for the TGDC, [3] Joseph A. Calandrino, Ariel J. Feldman, J. Alex Halderman, David Wagner, Harlan Yu, and William P. Zeller. Source Code Review of the Diebold Voting System, [4] Intel Corp. Lagrande technology architectural overview, [5] Yaozu Dong, Shaofan Li, Asit Mallick, Jun Nakajima, Kun Tian, Xuefei Xu, Fred Yang, and Wilfred Yu. Extending Xen with Intel Virtualization Technology. Intel Virtualization Technology, 10, August, [6] B.Dragovic,K.Fraser,S.Hand,T.Harris,A.Ho, I. Pratt, A. Warfield, P. Barham, and R. Neugebauer. Xen and the Art of Virtualization. In Proceedings of the ACM Symposium on Operating Systems Principles, October [7] George W. Dunlap, Samuel T. King, Sukru Cinar, Murtaza A. Basrai, and Peter M. Chen. ReVirt: enabling intrusion analysis through virtual-machine logging and replay. In Proceedings of the 5th symposium on Operating systems design and implementation, volume 36, pages , New York, NY, USA, ACM Press. [8] William A Edelstein. New Voting Systems for NY-Long Lines and High Cost, November [9] Ariel J. Feldman, J. Alex Halderman, and Edward W. Felten. Security Analysis of the Diebold AccuVote-TS Voting Machine. In Proceedings of USENIX/ACCURATE Electronic Voting Technology Workshop, [10] Tal Garfinkel, Ben Pfaff, Jim Chow, Mendel Rosenblum, and Dan Boneh. Terra: A Virtual Machine-Based Platform for Trusted Computing. In Proceedings of the 19th Symposium on Operating System Principles, October [11] Tal Garfinkel and Mendel Rosenblum. A Virtual Machine Introspection Based Architecture for Intrusion Detection. In Proceedings of Network and Distributed Systems Security Symposium, February [12] Stephen N. Goggin and Michael D. Byrne. An Examination of the Auditability of Voter Verified Paper Audit Trail (VVPAT) Ballots. In Proceedings of USENIX/ACCURATE Electronic Voting Technology Workshop,

9 [13] Douglas Jones. Parallel testing during an election. shtml#parallel. [14] Samuel T. King, Peter M. Chen, Yi-Min Wang, Chad Verbowski, Helen J. Wang, and Jacob R. Lorch. Subvirt: Implementing malware with virtual machines. In Proceedings of IEEE Symposium on Security and Privacy, pages , [15] Samuel T. King, George W. Dunlap, and Peter M. Chen. Debugging Operating Systems with Time-Traveling Virtual Machines. In Proceedings of USENIX 2005 Annual Technical Conference, General Track, pages [16] Tadayoshi Kohno, Adam Stubblefield, Aviel D. Rubin, and Dan S. Wallach. Analysis of an Electronic Voting System. In Proceedings of IEEE Symposium on Security and Privacy, volume 00, page 27, Los Alamitos, CA, USA, IEEE Computer Society. [17] Kevin Lawton, Bryce Denney, N. David Guarneri, Volker Ruppert, and Christophe Bothamy. Bochs, the cross platform IA-32 Emulator. [18] Theodore A. Linden. The use of abstract data types to simplify program modifications. In Proceedings of the 1976 conference on Data : Abstraction, definition and structure, pages 12 23, New York, NY, USA, ACM Press. [19] David L. Parnas. Designing software for ease of extension and contraction. In Proceedings of the 3rd International Conference on Software engineering, pages , Piscataway, NJ, USA, IEEE Press. [20] Gerald J. Popek and Robert P. Goldberg. Formal requirements for virtualizable third generation architectures. Communications of the ACM, 17(7): , [21] Ronald L. Rivest and John P. Wack. On the notion of Software Independence in Voting Systems, [22] Naveen Sastry, Tadayoshi Kohno, and David Wagner. Designing voting machines for verification. In Proceedings of the 15th conference on USENIX Security Symposium, pages 22 22, Berkeley, CA, USA, USENIX Association. [23] AE Svizzero. Authorization Testing for HAVA Plan B Ballot Marking Devices, May VendorAuthorization.pdf. [24] VMware. Vmware products. [25] David A. Wheeler. SLOCCount toolkit. [26] Wikipedia. Source Lines of Code. [27] Ka-Ping Yee, David Wagner, Marti Hearst, and Steven Bellovin. Prerendered User Interfaces for Higher-Assurance Electronic Voting. In Proceedings of the USENIX/ACCURATE Electronic Voting Technology Workshop, Appendix The following figures depict the pixmaps captured by the Qemu-DM and stored on the host OS. Figure 9 and Figure 10 depict the candidate selection screen. Note that since we conducted an election with 2 candidates we have two such screens. Figure 11 depicts a blank ballot being cast and Figure 12 shows when the vote cast by the voter is recorded in the system. Figure 13 shows that the screen after the election has been completed. Finally, Figures 14 and 15 show the screens after the ballot definition is altered. Figure 9: Candidate A (Jon Stewart) selection screen Figure 10: Candidate B (Stephen Colbert) selection screen 264

10 Figure 11: Screen showing a blank ballot being cast Figure 14: Screen showing altered ballot definition (candidate names flipped) with Candidate B selected Figure 12: Screen showing a vote has been recorded Figure 15: Screen showing altered ballot definition (candidate names flipped) with Candidate A selected Figure 13: Screen after election is complete 265