Communications of the ACM
The problems and potentials of voting systems
Analyzing Internet Voting Security
The Secure Electronic Registration and Voting Experiment (SERVE) is an Internet-based voting system built by Accenture and its subcontractors for the U.S. Department of Defense FVAP (Federal Voting Assistance Program).1 FVAP's mission is to reduce voting barriers for all citizens covered by the Uniformed and Overseas Citizens Absentee Voting Act (UOCAVA), namely U.S. citizens who are members of the military services, their family members, and nonresident U.S. citizens. SERVE is intended to allow UOCAVA voters both to register to vote and to vote via the Internet, from anywhere in the world. It is meant to be a complete, Independent Testing Authority-qualified and state-certified voting system that collects real votes.
To participate, an eligible voter first enrolls in the SERVE program. After enrollment, the voter may register to vote, and then vote in one or two short sessions from any Internet-connected PC. The PC must run a Microsoft Windows operating system and either the Internet Explorer or Netscape Web browser. The browser must be configured to enable JavaScript, along with either Java or ActiveX scripting, and session cookies; no additional hardware or software is required.
When a person registers online to vote, his or her information is stored on the central Web server for later retrieval by the Local Election Official (LEO), at which point the LEO updates its database. When a person votes in the election, the completed ballot is stored on the central server and later downloaded by the LEO, who stores it for canvass. The communication between the user's Web browser and the central server is protected using the Secure Socket Layer (SSL) protocol. Once that connection is established, an ActiveX control is downloaded to the voter's PC and run to provide functionality not available in current browsers.
Besides being restricted to overseas voters and military personnel, the 2004 trial SERVE was to be limited to people who vote in one of 50 counties in the seven states (Arkansas, Florida, Hawaii, North Carolina, South Carolina, Utah, and Washington) that agreed to participate. The 2004 trial was expected to handle up to 100,000 votes over the course of the year (as many votes as a small state), including both the primaries and the general election. By comparison, approximately 100 million votes were cast in the 2000 general election. One goal was to determine if a similar system might be suitable for expansion to all six million UOCAVA voters.
Limited though it is, SERVE is a real voting system. Systems similar to SERVE might eventually be offered by Accenture or other vendors for use by all voters, instead of just a limited population. For these reasons we analyze SERVE not as an experiment, but as a real voting system whose use could be significantly expanded in future years.
Because the Internet is independent of national boundaries, an election held over the Internet is vulnerable to attacks from anywhere in the world.
Our Recommendations
Our findings and recommendations are summarized here.
Direct-recording electronic (DRE) voting systems have been widely criticized for various deficiencies and security vulnerabilities: that their software is totally closed and proprietary; that the software undergoes insufficient scrutiny during qualification and certification; that DREs are especially vulnerable to various forms of insider (programmer) attacks; and that DREs have no voter-verified audit trails (paper or otherwise) that could largely circumvent these problems. All of these criticisms of DREs apply directly to SERVE as well [4].
In addition, because SERVE is an Internet- and PC-based system, it has numerous other fundamental security problems that leave it vulnerable to a variety of well-known cyber-attacks (denial-of-service attacks, spoofing, viral attacks on voter PCs, and so forth), any one of which could be catastrophic.
Such attacks could occur on a large scale, and could be launched by anyone in the world, ranging from a disaffected lone individual to a well-financed enemy agency outside the reach of U.S. law. These attacks could result in large-scale, selective voter disenfranchisement, and/or privacy violation, and/or vote buying and selling, and/or vote switching even to the extent of reversing the outcome of many elections at once, including the presidential election. Some of the attacks could succeed and yet go completely undetected. Even if detected and neutralized, such attacks could have a devastating effect on public confidence in elections.
It is impossible to estimate the probability of a successful cyber-attack; but we show that the attacks we are most concerned about are quite easy to perpetrate. In some cases there are kits readily available on the Internet that could be modified or used directly for attacking an election. And we must consider the sentiment that a U.S. general election offers one of the most tempting targets for cyber-attack in the history of the Internet, whether the attacker's motive is overtly political or simply self-aggrandizement.
The vulnerabilities we describe cannot be fixed by design changes or bug fixes in SERVE. Instead, they are fundamental in the architecture of the Internet and of the PC hardware and software that is ubiquitous today. The vulnerabilities cannot be eliminated for the foreseeable future without a wholesale redesign and replacement of much of the hardware and software security systems in the PC and the Internet, or else some unforeseen radical security breakthrough(s).
We have examined numerous variations on SERVE; however, all such variations suffer from the same kinds of fundamental vulnerabilities. Regrettably, we cannot recommend any of them. We do suggest a kiosk architecture as a starting point for designing an alternative voting system with similar aims to SERVE, but which does not rely on the Internet or on unsecured PC software (see [3], Appendix C.)
A seemingly successful voting experiment in a U.S. presidential election involving seven states would likely be viewed by most people as strong evidence that SERVE is a reliable, robust, and secure voting system. Such an outcome would encourage expansion of the program by FVAP in future elections, or the marketing of the same voting system by vendors to jurisdictions all over the U.S., and other countries as well.
However, the fact that no successful attack is detected does not mean that none occurred. Many attacks, especially if cleverly hidden, would be extremely difficult to detect, even in cases when they change the outcome of a major election. A "successful" trial of SERVE in 2004 is the top of a slippery slope toward even more vulnerable systems in the future. (The existence of SERVE was cited as justification for Internet voting in the Michigan Democratic caucuses earlier this year.)
Like the proponents of SERVE, we believe that there should be better support for voting for members of the military overseas. Still, because the danger of successful, large-scale attacks is so great, we reluctantly recommend shutting down the development of SERVE immediately and not attempting anything like it in the future until the security problems of the PC and the Internet are resolved. The remainder of this article explains some of the reasoning behind these conclusions.
Vulnerabilities in SERVE
Because the Internet is independent of national boundaries, an election held over the Internet is vulnerable to attacks from anywhere in the world. Not only could a political party attempt to manipulate an election by attacking SERVE, but so could individual hackers, criminals, terrorists, and even other countries. There is no need to postulate a large conspiracy or highly sophisticated adversaries; many of the attacks we describe could be mounted by lone individuals with college-level training in computer programming. Here, we give a short description of a variety of attacks that can be mounted against SERVE.
Lack of Voter-Verified Audit Trail and Insider Attacks. Paperless DRE voting systems have been widely criticized because they are unauditable. There is no way for a voter to verify that the vote recorded inside the machine is the same as the vote he or she entered and saw displayed on the machine's screen; if serious problems subsequently occur in the canvass of the votes (which happens all too frequently), there is no independent audit trail of the votes to help resolve the problem. Voter verification is the only readily available effective defense against programmed insider attacks. Every argument about the need for voter verification and auditability that has been made about DREs applies essentially unchanged to SERVE (see www.notablesoftware.com/evote, www.verifiedvoting.org, and [1]).
Privacy. The privacy of SERVE ballots is protected using encryption. When the ballot is cast, it is encrypted during transmission over the Internet and decrypted at the central server. Once received, the ballot is separated from the voter's identity and the anonymous ballot is reencrypted so that only the LEO of the voter's district can read it. These encrypted ballots are stored at the central server and can be downloaded (in randomly reordered form) upon request by LEOs.
This architecture introduces several privacy risks. First, a LEO could deduce how voters in his or her precinct have voted by downloading votes from SERVE so frequently that the LEO gets at most one new vote and voter name each time. This would allow a curious LEO to infer how each individual voted. Second, the brief existence of cleartext ballots on the server introduces a risk that SERVE system administrators could view how individuals voted. Likewise, if SERVE machines were subverted by hackers, the privacy of all votes could be compromised. Third, SERVE's retention of encrypted ballots for 18 months or longer could compromise voter privacy if this information were to land in the wrong hands and old system keys were exposed.
Vote Buying/Selling. Vote selling is a problem in all elections, but it is a special concern for Internet voting, since large-scale vote buying and selling can be automated. During the 2000 presidential election, several Web sites were created to facilitate vote swapping between Gore and Nader voters. While the Gore/Nader swapping depended on the honor system and no money changed hands, a similar approach could be used with SERVE to provide enforced vote swapping or vote bartering services, or to purchase votes from SERVE voters.
The most straightforward vote-buying scheme would involve the selling of personally identifiable information and the voter's password or private key. One possible defense would be for SERVE to prohibit the submission of multiple votes from the same Internet address. This is not a strong defense, however, because a purchaser of votes could fool SERVE into thinking the votes were coming from different addresses, and because legitimate users often appear to come from the same IP address.
Another approach to vote buying would be for the buyer to provide the seller with a version of the SERVE ActiveX component that is modified to ensure the voting is done according to the wishes of the vote purchaser. There does not seem to be any way for SERVE to defend against this style of vote buying.
Large-Scale Impact. When voting is conducted at physical precincts on mechanical devices or with paper ballots, whatever vote manipulation occurs happens on a relatively small scale. By contrast, since SERVE is vulnerable to many different types of attacks, a significant percentage of votes cast over the Internet could be vulnerable. A single malicious party could potentially affect tens of thousands of votes cast through SERVE, whereas it is extremely unlikely that any single person could conduct vote fraud on such a large scale in existing nonelectronic elections. The table appearing here summarizes the major vulnerabilities we have identified in SERVE, along with our assessment of those vulnerabilities. The table describes, for each potential threat to SERVE, what skill is required by the attacker, the consequences of a successful attack, how realistic the attack is, and what countermeasures might be used to thwart the attack.
The remainder of this article details three of the most important of the vulnerabilities in SERVE; for further information see the original report [3].
Lack of Control of the Voting Environment
Perhaps the greatest challenge with Internet voting arises from the fact that electoral authorities do not have control over all the equipment used by voters. Since SERVE's voters can vote on their own computers or on computers controlled by others, third parties might be able to gain control of a large number of computers used for voting. Such attacks could result in the loss of voter privacy, disenfranchisement, or vote alteration without anyone, including the voter and election officials, noticing or detecting any problem.
The Computers. Voters' personal computers are unlikely to be as carefully defended as corporate ones, and hence voters' machines are especially susceptible to attack. Attacks can be easily automated; hackers routinely scan thousands or even millions of computers in search of those that are easiest to compromise. A relatively easy way to disenfranchise the voter is to disable ActiveX or Web cookies so that it is no longer possible to vote through SERVE. Alternatively, a malicious third party could cast an unauthorized ballot that appears to come from the voter.
A shared computer, for example at a cybercafe or public library, is even more insecure. The owner, the system administrator, or even a prior visitor could have installed remote spying or subversion software. Voting from workplaces entails similar risks. One study found that 62% of major U.S. corporations monitor employee's Internet connections, and more than one-third store and review files on employees' computers (see www.amanet.org/research/pdfs/ems_short2001.pdf).
The Software. Preinstalled software applications also pose risks. Backdoors placed in software and activated when a user tries to vote could invisibly monitor or subvert the voting process. Software security vulnerabilities could allow a remote attacker to take complete control of a computer using remote control software such as PCAnywhere or BackOrifice. Successful penetration of even well-defended computers is routine.
Viruses and Worms. One of the most dangerous forms of remote attack is a virus or worm that spreads itself and contains a malicious payload designed to take control of machines and wreak havoc with a future election [7]. Since virus-checking software defends against only previously known viruses, virus checkers often are unable to keep up with the spread of new viruses and worms. In 2001, the Code Red worm infected 360,000 computers in 14 hours, and in 2003 the Slammer worm [5] brought down many ATM machines and compromised many Internet hosts (see securityresponse.symantec.com/avcenter/venc/data/w32.sqlexp.worm.html). Modern worms are even more virulent, are often spread by multiple methods, are able to bypass firewalls and other defenses, and can be difficult to analyze. For example, it took quite a while to determine that SoBig.F was a Trojan horse designed to plant spam engines (see securityresponse.symantec.com/avcenter/venc/data/[email protected]).
Attackers can build new viruses, or modify existing viruses sufficiently that they will avoid detection. Virus construction kits are available on the Internet. In addition, attackers have the advantage that they can test new versions of viruses using the same publicly available virus checkers that potential victims use, thus confirming that the virus will not be detected before its release.
Perhaps the greatest challenge with Internet voting arises from the fact that electoral authorities do not have control over all the equipment used by voters.
Web Sites. A dangerous hybrid attack involves placing malicious content on specially chosen Web sites. For instance, an attacker with a vendetta against one candidate might booby-trap the Web site of that candidate, so that those who visit the candidate's Web site are unable to vote using SERVE. Such selective disenfranchisement might eliminate several hundreds or thousands of votes for a candidate, enough to throw the election to his or her opponent.
Spoofing and Man-in-the-Middle Attacks
In man-in-the-middle attacks the adversary interposes itself between legitimate communicating parties and simulates each party to the other. To simplify the discussion in the context of this article, we focus primarily on ways that a man-in-the-middle attack can subvert voter privacy, although the same general technique can be used for other attacks, such as vote buying.
The use of SSL does little to mitigate man-in-the-middle attacks on privacy. Any man-in-the-middle could act as an SSL gateway, forwarding application data between the voter and the vote server unaltered. The attacker could see all of the traffic by decrypting and reencrypting as communications pass between the two. In effect, the attacker would communicate using two SSL sessions, one between itself and the voter, and the other between itself and the vote server, and neither would know that there was a problem. These attacks are possible because the voter's browser does not verify that it is talking to the real SERVE Web server—only that it is talking to someone in possession of a valid SSL certificate (who could be an attacker).
Man-in-the-middle attacks also could be used to disenfranchise voters by spoofing the entire interaction with the voter. SERVE has some safeguards in place, but they assume the voter knows exactly what to expect from the voting experience; it is likely that an attacker could create a voting experience the voter would believe is real. Similarly, voters could be led to believe they registered successfully, when in fact they were communicating directly with an adversary instead of the legitimate registration server. The voters would discover when attempting to vote that they were not registered, but at that point there might be nothing they could do to resolve the situation.
Perhaps the most serious consequence of man-in-the-middle attacks is that attackers could engage in election fraud by spoofing the voting server and observing how a particular voter votes. If the vote is to the attacker's liking, the voter is redirected to SERVE's legitimate voting site. If the attacker does not like the vote, then the entire voting session is spoofed; in this case, the user thinks he or she has voted, but in fact the vote will not be received or counted by SERVE.
Denial-of-Service Attacks
Attacks in which legitimate users are prevented from using the system by malicious activity such as overloading the election Web server are known as denial-of-service attacks. A particularly nasty variant of denial-of-service attack is the distributed-denial-of-service (DDoS) attack. In this scenario, an attacker typically takes control of many computers in advance by spreading a custom-crafted virus or worm. In computer security jargon, the compromised machines are often known as zombies or slaves, because the attacker leaves behind hidden software that causes infected machines to blindly obey subsequent commands from the attacker. Automated tools for mounting DDoS attacks have been circulating among the hacker community since at least 1999 [2], and hackers routinely amass large zombie networks of compromised machines. In February 2000, major DDoS attacks were mounted against several high-profile Web sites, including CNN, Yahoo and eBay. It was later discovered that these damaging attacks had been perpetrated by a lone teenager located outside the U.S.
We expect that denial-of-service attacks could disenfranchise a substantial fraction of the SERVE population, and there seems to be little that SERVE can do to defend against such attacks.
Since 2000, DDoS attacks have become routine. One study recorded over 10,000 denial-of-service attacks during a three-week period in 2001 [6]. The Code Red worm, for example, contained code to mount a DDoS attack on the White House Web site. (Fortunately, the DDoS attack was deflected at the last minute.) In 2003, an Internet election in Canada was disrupted by a denial-of-service attack on Election Day. These are not isolated examples; it is all too easy to mount DDoS attacks, and the culprits are rarely caught.
If an attacker were to mount a large-scale denial-of-service attack that renders SERVE's voting service unavailable on Election Day, it would call into question the validity of the election and effectively disenfranchise large numbers of UOCAVA voters. Alternatively, network services could be knocked out or degraded for areas where a particular demographic is known to vote for a particular party, possibly modifying the outcome of the election. Detection of a selective disenfranchisement attack might be possible, but it is not clear how to respond—once polls close, there may be no good choices. We expect that denial-of-service attacks could disenfranchise a substantial fraction of the SERVE population, and there seems to be little that SERVE can do to defend against such attacks.
Conclusion
Because of space constraints, we have mentioned only a few of the possible attacks. These attacks depend on fundamental vulnerabilities in the current PC architecture (malicious code, for example) and in the Internet (such as spoofing and denial-of-service attacks). These attacks can be launched by anyone in the world, and in many cases may be successful while remaining completely undetected. Consequently, we conclude that Internet voting in general, and SERVE in particular, cannot be made secure for use in real elections for the foreseeable future. (See the full report [3].)
References
1. California Secretary of State Ad Hoc Touchscreen Voting Task Force Report; www.ss.ca.gov/elections/taskforce_report.htm.
2. Houle, K.J. and Weaver, G.M. Trends in Denial of Service Attack Technology. Technical Report, CERT Coordination Center (Oct. 2001).
3. Jefferson, D.R., Rubin, A.D., Simons, B., and Wagner, D. A Security Analysis of the Secure Electronic Registration and Voting Experiment (SERVE); www.servesecurityreport.org/.
4. Kohno, T., Stubblefield, A., Rubin, A.D., Wallach, D.S. Analysis of an electronic voting system. IEEE Security and Privacy (2004).
5. Moore, D., Paxson, V., Savage, S., Shannon, C., Staniford, S., and Weaver, N. Inside the Slammer worm. IEEE Security and Privacy (2003).
6. Moore, D., Voelker, G.M., and Savage, S. Inferring Internet denial-of-service activity. Usenix Security (2001).
7. Staniford, S., Paxson, V., and Weaver, N. How to own the Internet in your spare time. Usenix Security (2002).
Footnotes
1The authors are four of a group of eight computer scientists and security experts who reviewed the Pentagon's $22 million SERVE program for voting over the Internet. Shortly after the release of the full report in January 2004 [3], the Pentagon decided not to implement SERVE in the 2004 election, citing security concerns. It is still possible that a program similar to SERVE could be proposed for future elections. This article, derived from the full report, describes the security issues the authors identified with SERVE, most of which apply to Internet voting in general. To simplify the presentation, the present tense is used, even though there are no longer current plans to use SERVE in any election.
©2004 ACM 0001-0782/04/1000 $5.00
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.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2004 ACM, Inc.
No entries found