The New South Wales iVote System: Security Failures and Verification Flaws in a Live Online Election

1 Introduction

• The study examined the largest Internet-voting deployment to date, against a backdrop of rarely used online voting in significant public elections and established security risks.The risks include compromise of election servers, voter devices, the intervening network, and voter authentication.Source: §1 · p. 1
• The iVote flaws could expose secret ballots, substitute votes, and sidestep verification, despite years of planning and pre-election assessment.The authors describe these findings as evidence of risks from conducting Internet voting with existing security technologies.Source: §1 · p. 2
• 66,000 votes were cast during the five days iVote remained vulnerable before NSWEC patched its network security flaws.Source: §1 · p. 2
• The final Legislative Council seat was decided by 3,177 votes, far fewer than the votes cast while iVote was vulnerable; whether anyone exploited the opportunity is unknown.Source: §1 · p. 2
• The case reinforces prior concerns about Internet-voting systems and shows that pre-election review cannot guarantee security; web-platform and TLS brittleness may conflict with election security demands.Source: §1 · p. 2
• The iVote verification protocol used telephone vote-reading, which reduced voter privacy while offering limited integrity assurances, and had not undergone extensive public review.The authors recommend refraining from high-stakes online elections until fundamental security advances are made.Source: §1 · pp. 2–3

2 iVote Background

• Registration and voting were available by telephone, Internet, or NSWEC polling-place computer, with four steps in the online process.Source: §2 · p. 3
• After voting, users received a 12-digit receipt and could optionally hear their vote read back by telephone or check online whether it was included in the final count.The telephone service stopped at poll closing; the online receipt service remained available afterward.Source: §2 · p. 3
• Although reports described encryption and vote processing, server-side source code was not released, and protocol drafts differed from election-time behavior.Source: §2 · p. 3
• Voters could qualify for iVote by self-certifying that they would be outside the state on election day; about 280,000 votes, or 5% of counted ballots, were cast through it.Source: §2 · p. 3
• Most browser-loaded resources came from the core voting server, but the Piwik analytics JavaScript came from an external server.Source: Figure 1 · p. 4

3 Vulnerabilities in iVote

• The main iVote HTTPS server met security best practices, but the application also loaded JavaScript from PiwikPro, whose server had an F-grade configuration that enabled code injection without browser warnings.The external server supported 512-bit export-grade RSA and ephemeral Diffie-Hellman cipher suites.Source: §3 · pp. 5–6

3.1 Vulnerability to the FREAK attack

• FREAK let a network attacker downgrade vulnerable browsers to export-grade RSA, then exploit a long-lived PiwikPro connection to attack multiple voters.The researchers sustained such connections for 17–21 hours and factored one temporary key; staggered connections could have enabled continuous attacks for about $100 per 12-hour period.Source: §3.1 · pp. 6–7

3.2 Vulnerability to the Logjam attack

• Logjam affected all popular browsers and could let an attacker break the PiwikPro server’s fixed 512-bit Diffie-Hellman group, then intercept iVote sessions.After precomputation, individual key exchanges using the same parameter value could be broken in about 90 seconds, without a noticeable delay to voters.Source: §3.2 · pp. 7–8

3.3 Proof-of-concept, exploitability, and responsible disclosure

• A proof-of-concept injected JavaScript that changed votes; the authority disabled Piwik after 66,000 votes had been cast, while the final Legislative Council margin was 3,177 votes.The injected code also sent the intended vote and authentication credentials to an attacker-controlled command-and-control server.Source: §3.3 · pp. 8–10
• The exploit replaced third-party JavaScript that ran in the iVote session, allowing it to alter votes as they passed to the encryption worker.The researchers tested only on their own votes in the practice system, which they said was identical in relevant respects to the live system.Source: §3.3 · pp. 8–9

4.1 Simple verification avoidance

• Telephone verification shut down at poll closing, and a man-in-the-middle attacker could also direct voters to a fake verification number or delay the receipt until they left the site.Near the deadline, the attacker could alter a vote knowing it could no longer be checked by phone.Source: §4.1 · p. 10

4.2 Using the “clash” attack to reduce verification failures

• A clash-style attack could reuse the credentials of a like-minded voter who had already voted, making verification appear correct when the target’s choices matched.If the choices differed, the target would detect a problem by using verification, but not by contacting the receipt service alone.Source: §4.2 · pp. 10–11
• Good prediction of voter behavior could make the clash attack generate far fewer complaints than manipulated votes; the verification design offered no evidence to distinguish attacks from voter error.The authors say the complaint rate could underrepresent manipulated votes, potentially allowing an incorrect result to stand in a post-election legal challenge. The attack was not tested during the election because that would interfere with real votes.Source: §4.2 · pp. 10–11

5.1 Integrity, auditing, and verification

• iVote’s design cannot match ordinary post-election scrutineering assurance: a joint compromise of the Core Voting System and Verification Service could undetectably alter votes.The Verification Service could misreport a voter’s selection, while the systems could present consistent misrepresented votes to the Auditor.Source: §5.1 · p. 12
• The audit process is incompletely described, leaving unclear whether compromising the Core Voting System and Auditor could alter votes undetectably or what data independent observers may inspect.Votes could also be removed after appearing on the verification server when a voter re-registers or votes through another channel, with no clear published account of how removal is checked.Source: §5.1 · p. 12
• The implemented vote encryption differed from published descriptions: the client used a symmetric-key digital envelope encrypted to both servers, raising privacy and integrity implications.The passage also notes that the code’s signing process is undocumented, leaving unclear how a web server could forge a vote signature or whether it would need to alter client JavaScript.Source: §5.1 · pp. 12–13

5.2 Privacy

• The telephone verification service creates privacy and coercion opportunities absent from traditional paper voting, including credential-based vote buying or coercion.A buyer could use the Receipt Server to check whether a voter later changed selections.Source: §5.2 · p. 13
• Potential identity-to-ballot links remain at multiple system points, including identifiable phone verification and combined compromises of registration and another server.The design relies on destroying electronic links between identity and ballots, which is harder to ensure irrevocably than physical separation in postal voting.Source: §5.2 · pp. 13–14

5.3 Usability and operations

• Two parties were omitted from the ballot’s “above the line” section until 19,000 votes had been cast, and voters faced navigation problems across 394 candidates.The system was suspended for six hours; the authors suggest these problems indicate inadequate pre-deployment testing of core voting functionality.Source: §5.3 · p. 14

Security: the difficulty of correcting known problems in time, and unknown problems at all

• The iVote ballot had usability and ballot errors: two parties were mistakenly omitted from the “above the line” section for the first 19,000 votes, and accessing all 394 candidates required horizontal and vertical scrolling.Source: Figure 5 · p. 15
• Zero-day vulnerabilities may be unknown and unpatchable, while rapid fixes can introduce vulnerabilities or conceal fraud; FREAK’s patch also blocked Logjam only by luck.Logjam could have compromised connections to popular browsers, and was not publicly disclosed until two months after the election.Source: Security: the difficulty of correcting… · p. 15

Fragility: standard web development practices are inadequate for critical applications such as elections

• Third-party code expands election-system exposure to provider insiders, including unknown employees, even without a vulnerable external server.The paper argues that high-stakes elections require a technical approach different from typical IT systems.Source: Fragility: standard web development… · p. 16

Verifiability: when does an advertised verification mechanism truly provide verifiable evidence of a correct election outcome?

• A claim that an Internet voting system is verifiable needs a complete system description and a clear supporting argument; otherwise its protocol may be incomplete, erroneous, or manipulable.The authors note that iVote’s verification mechanism was not based on a peer-reviewed end-to-end scheme and lacked detailed public review before the election.Source: Verifiability: when does an advertised… · p. 16

• The flaws could expose voters’ secret ballots, substitute replacement votes, and sidestep iVote’s verification mechanism.Source: §7 · p. 17
• Keeping iVote’s source code and detailed design secret prevented independent analysts from alerting officials to these specific problems before the election.Source: §7 · p. 17
• The authors recommend avoiding large-scale Internet voting until fundamental computer-security advances, and specify safeguards if tests proceed.They call for restricted eligibility, peer-reviewed verification, open design and implementation, and public disclosure of risks.Source: §7 · p. 17
• Neither evidence of exploitation nor adequate proof that the vulnerabilities were not exploited was available, making the exposure a serious electoral-process failure.Source: §7 · p. 17