Tag Archives: Drew Springall

CCS’14: Security Analysis of the Estonian Internet Voting System


Estonian Internet Voting security report published in May, 2014 has been submitted to ACM Conference on Computer and Communications Security (CCS’14).
Here is a list of changes made into CCS’14 article:

  •  Author list reordered moving PhD students to the beginning.
  • Additional author “Zakir Durumeric” added (he was mentioned in acknowledgements section before).
  • Abstract added.
  • Added to introduction:
    “People around the world look to Estonia’s example, and some wonder why they can’t vote online too [54].”
  • Added to introduction:
    “Despite these concerns, the system has not previously been subjected to a detailed independent security analysis.”
  • Removed from introduction:
    “The weakness of the Estonian system stems from its basic design”.
  • Added to introduction:
    “As recently as May 2014, attackers linked to Russia targeted election infrastructure in Ukraine and briefly delayed vote counting [10].”
  • Added to introduction:
    “We returned to Estonia in May 2014 and shared these findings with election officials and the public. Unfortunately, government responses ranged from dismissive to absurd. The National Electoral Committee stated that the threat vectors we consider have already been adequately accounted for in the design, and that the attacks we describe are infeasible [26]. We disagree on both counts, but readers can review the evidence and reach their own conclusions. Prime Minister Taavi Rõivas and President Toomas Hendrik Ilves insinuated to the media that we had been bought off by a rival political party seeking to disparage the system. This we vehemently deny, but it illustrates how the Estonian public discourse concerning election technology has become dominated by partisanship. We hope that the country can separate technical reality from political rhetoric in time to avert a major attack.”
  • Added paragraph:
    “Estonians can also use mobile phones with special SIM cards for authentication and signing, through a system called Mobile-ID [14]. In the 2013 election, 9% of online votes were cast using this method [19]. We exclude Mobile-ID from our analysis because we did not have access to the external infrastructure that would be needed to test it.”
  • Added footnote:
    “Estonia used the system again, shortly after we made our findings public, for May 2014 European Parliament elections. There were only minor changes to the software and procedures. The fraction of votes cast online increased to 31%.”
  • “Instead, officials decided to use a worker’s personal USB stick to transfer the files to an Internet-connected Windows laptop” now additional clause follows: “, where the results were officially signed.”
  • The first paragraph of “Insufficient Transparency” subsection rephrased removing “we have been impressed by the initial steps towards transparency…”
  • Two paragraphs added to the section “Vulnerabilities in Published Code”:
    “Nonetheless, we discovered some minor bugs and vulnerabilities while examining the code in order to conduct our other experiments. We disclosed these issues to the Internet Voting Committee in May 2014.
    One of the problems we found allows a denial-of-service attack against the voting process. If a client sends an HTTP request containing unexpected header fields, the server logs the field names to disk. By sending many specially crafted requests containing fields with very long names, an attacker can exhaust the server’s log storage, after which it will fail to accept any new votes. In the 2013 election, the size of the log partition was 20 GB. We estimate that an attacker could fill it and disable further voting in about 75 minutes. Curiously, the vulnerable code is only a few lines from the comment, “Don’t write to disk; we don’t know how large the value is.” This indicates that the developers were aware of similar attacks but failed to account for all variants.
    A second problem we discovered is a shell-injection vulnerability in a server-side user interface that is intended to allow operators to perform pre-determined administrative tasks. The vulnerability would allow such an operator to execute arbitrary shell commands on the election servers with root privileges. Under current procedures, this is moot, since the same workers perform other administrative tasks at the command line as root. However, shell injection vulnerabilities can be exceedingly dangerous [67], and the fact that the issue was not detected in advance of the election is a reminder that open source cannot guarantee the absence of vulnerabilities [44].”
  • Added paragraph:
    “Virtual machines we used to reproduce the election, together with source code for our demonstration attacks, are available online at https://www.estoniaevoting.org.”
  • Added to “Threat Model” section:
    “More recently, in May 2014, attackers linked to Russia targeted election infrastructure in Ukraine, which uses a computerized system to aggregate results from around the country. The attackers reportedly attempted to discredit the election process by disrupting tallying and causing the system to report incorrect results [10].”
  • Removed paragraph:
    “It took less than two man-weeks to devise, implement, and test this server-side vote-stealing attack. The majority of this time was spent finding an appropriate and sufficiently silent way to insert the trojan into the OS installation procedures, due to unfamiliarity with the Debian package system and installation process.”
  • Added paragraph:
    “In fact, during the pre-election server setup process in 2013, workers used an incorrect version of the evote_post.sh script that failed to install the evote_analyzer package on the VFS. Administrators later had to manually install this package during the voting period, after they realized that the server was not reporting all expected log data [56]. This provides a case-in-point example of a failure of the procedural protections to ensure that only the correct software gets installed on the server machines.”
  • Added paragraph:
    “Zero-day exploits are yet another potential attack vector, and a source of many “known unknowns.” One illustration of this is the OpenSSL Heartbleed bug [34], which was not disclosed until April 2014. The front-end server used during the 2013 election was vulnerable to Heartbleed, and an attacker who knew about the bug likely could have exploited it to extract the server’s TLS private key. Then, using a man-in-the-middle attack on connections from voters, they could have selectively prevented certain voters’ ballots from being received by the real server.”
  • Added completely new subsection:
    “5.3 Attacking Ballot Secrecy
    While our experiments focused on attacks against the integrity of election results, we also considered ballot secrecy issues, since the secrecy of the voter’s ballot is a critical defense against voter coercion and vote buying. The I-voting system implements a relatively strong protection against in-person, individual coercion by allowing voters to cast replacement votes online or to cancel their electronic ballots entirely and vote in person on election day. More sophisticated attacks remain possible, however, including spyware on the voter’s PC or smartphone, as well as server-side attacks.
    Server-side attacks on ballot secrecy are particularly troubling, since preserving ballot secrecy is a main goal of the system’s cryptographic double-envelope architecture. The voting design attempts to ensure that votes remain private by breaking the association between voters’ digital signatures from their plaintext votes. The encrypted ballots are separated from the signatures and copied to an isolated machine before being decrypted and counted. Note that this machine, the counting server, has access to the complete association between the encrypted ballots and the plaintext votes. An attacker who can smuggle this information out through a covert channel can compromise every voter’s secret ballot.
    Unfortunately, the tabulation procedures offer multiple possibilities for exfiltrating this information. When tabulation is complete, officials use the counting server to burn a DVD containing both vote totals and log files. Suppose for simplicity that the attacker is a dishonest insider with access to this DVD and to the complete set of signed, encrypted ballots (e.g. from a backup disk) and some mechanism for infecting the counting server with malicious code, such as the routes discussed above. The counting server malware can sort the encrypted ballots and leak the voter choices corresponding to each as a sequence of integers in the same order. Since there is typically only one race, only a few bits per ballot are needed to determine the choices of all voters. The malware could steganographically encode this data into the log files through the order of entries, or it could simply write this information to unallocated sectors of the disc. The attacker can then decode this information and use it to associate every voter’s digital signature (and hence, their identity) with their vote.”
  • Bibliography reference added to conclusion sentence:
    “Certainly, additional protections could be addded in order to mitigate specific attacks (e.g. [48])”
    [48] points to: “H. Lipmaa. A simple cast-as-intended e-voting protocol by using secure smart cards, May 2014.”
  • Removed the section “About the Authors”.
  • Added “supported by Google/ATAP” in aknowledgements.
  • Added picture of authors (without Hursti) made in Tallinn May 2014.