Online Voting in Government Elections – How Safe?

This is a two part essay by BigPulse founder Ralph McKay.

Part 1. explains why BigPulse is cautious about the use of online voting in government elections.

Part 2. reviews the New South Wales Electoral Commission's iVote system which harvested 280,000 online votes in the 2015 state election. This example illustrates many of the security risks discussed in part 1. as well as the potential for voters to be misled on vote security.

PART 1. Remote online voting works for non-government but not government elections

Introduction
Vote receipts – coercion and vote buying risk
Election verification – essential for electronic voting
Real vote receipts – required for secure verification
Published vote receipts – create a transparent audit trail
Election vote count verification protocol
Secret voting
Motivation to attack
Client side malware risk – man-in-the-middle attack
Independence of engineers
Hush risk
Technical skill
Scientific opinion – no known solution

Introduction

BigPulse is one of a few global leaders in the non-government online voting industry – clients in 35 countries, voters in most countries and a 15 year track record. 12 million votes harvested in more than 30,000 separate online voting projects with an average of 3.2 contests per project. No credible evidence exist of a single vote lost or miscounted.

Clearly for non-government elections online voting can be more secure than paper voting – which is often heavily trust-based and error prone.

Many people having experienced the simple elegance of online voting in non-government elections, and seen their vote verified, then ask why not online voting for government election?

However there are critical differences with government electronic elections which create serious security issues – particularly with remote online voting and phone voting is even less secure.

Vote receipts – coercion and vote buying risk

There is a long standing almost universal objection among politicians and electoral authorities to the use of vote receipts in government elections. The objection arises from a concern that vote receipts can facilitate illegal coercion and vote buying. There is some debate about the magnitude of coercion and vote buying risks in developed nation government elections. However the objection remains widespread.

This means electoral authorities adopting remote electronic voting will typically not issue vote receipts or use low grade vote receipts or limit the way receipts can be used. This creates a major security hole in government elections using remote electronic voting for which there is no known solution. However vote receipts are standard practice in non-government elections because coercion and vote buying is typically not considered a significant risk in the non-government election industry.

Election verification – essential for electronic voting

Verification is essential in electronic voting because of the intractable black-box problem. There are countless ways software can malfunction or be secretly altered or votes misrepresented and skillfully hidden from detection. The entire vote count can be controlled invisibly from within the black-box servers – the intended votes may not have even reached the election servers. The only way to be certain about the integrity of any electronic voting process is to verify externally that all votes are recorded and counted correctly and that no fake votes are included in the count – the election verification.

For a typical election it is not practical to verify absolutely the integrity of all votes counted. However the ability to verify individual votes securely is a significant deterrent for anyone with the capacity to interfere and is especially important for government elections.

Real vote receipts – required for secure verification

A real vote is a full take-home verifiable vote receipt. A full receipt includes a unique randomly assigned identifier and the voter's ballot selection or can be used in a secure way to confirm the voter's selection. "Take-home" means the voter has full control over access to the vote receipt. "Verifiable" means a way to know that the receipt is authentic. Other details may be included in the vote receipt. Secure election verification requires that real vote receipts are issued securely to each voter.

Voters may be given a means to use their vote receipt to confirm that their vote intention is recorded on the election server. However simply confirming the recording of a vote does not prove that the vote was counted or counted correctly.

Published vote receipts – create a transparent audit trail

A standard in non-government elections, led by BigPulse, is the ability to publish all vote receipts with all personal identifiers are removed – creating a transparent audit trail. Easy access to the full list of vote receipts enables voters to identify their unique vote receipt in the published list. The list of vote receipts also enables voters and auditors to independently check the vote counts. This is a critical aspect of an electronic election verification process.

Election vote count verification protocol

The following seven processes describe an election vote count verification protocol. It enables the vote count integrity of a secret voting election or referendum to be verified without reference to the black-box servers used to harvest the votes. In fact the protocol is fully independent of any method of harvesting the votes.

The quality of the vote count verification depends on both the implementation quality of each of the seven processes in the protocol and the level of voter participation in the verification process. However a robust implementation of the protocol, even with no voter participation in the verification process, can significantly enhance the vote count integrity. Anyone with a desire and means to secretly manipulate the vote count will be less motivated to act corruptly if it is known that a secure verification protocol exists.

1. Issue full take-home receipts to all voters
2. Provide a secure method for transferring vote receipts to voters
3. Issue tamper proof vote receipts
4. Provide receipt owners with ready access to the full list of vote receipts with all personally identifiable information removed from each vote receipt
5. Provide a means for receipt owners to verify receipt number uniqueness
6. Provide a means to detect any fake receipt numbers (not issued) in the full list of vote receipts, and
7. Provide a means for voters to confirm the full list of all candidates and candidate presentation order as it appeared in the voter's ballot.

Notes:

Process 1.
Nothing can be verified independently without real vote receipts.

Prcess 2.
Required to protect vote secrecy.

Process 3.
If vote receipts can be altered by the the receipt owners it provides a way to discredit the election integrity.

Process 4.
This enables voters to locate their own receipt in the counted list and also enables independent verification of the vote count.

Process 5.
A vote count can be corrupted by issuing the same receipt number to many people who voted with identical selections.

Process 6.
This ability along with process 5. enables the existence of any fake votes to be detected.

Process 7.
This alerts voters to any misrepresentation of the ballot – strictly speaking this is not part of the vote counted verification protocol but closely related.

Comments:

Process 4. is the essential feature that actually enables independent verification. The quality of the other six processes determine the standard of verification.

A useful point scoring system is to assign four points to process 4 and one point each for the other six processes; making 10 points the top score. With this weighted scale it is not possible to score above four if process 4. is missing because processes 5. and 6. depend on the existence of process 4.

Transparency of source code is not included in this verification protocol. The computer code is inside the black-box, whether open source or not. Anything that relies on an assumption of what is inside the black box cannot be part of a genuine independent election vote count verification protocol.

A robust vote count verification process does not guarantee vote secrecy is protected but it must not compromise vote secrecy.

Coercion and vote buying risk is not managed by the election vote count verification protocol, in fact, it clashes with coercion risk management management. This creates a problem for government elections.

Most, if not all, of these seven election verification processes are likely to be missing in government electronic elections with remote voting. However a much higher election verification standard can apply for non-government online elections – particularly because of the acceptance of real vote receipts. However the perfect large electronic election verification process does not exist at this time and this presents a greater risk for remote voting in government elections.

The above section can be accessed directly at Electronic election vote count verification protocol

Secret voting

The electors' vote intentions can be reflected perfectly in the count and verified yet vote secrecy may have been compromised. There is no way to verify secrecy. For this reason it is especially important that voters be accurately informed, or be given easy access to, the vote secrecy standard used in the technology.

Keeping the secret is what makes secret voting hard to do online and electronically in general. The safest way is also the least practical, that is, to issue voting accounts double blind and to vote from an IP address that cannot be used to identify the voter. Failing that the quality of vote secrecy protection depends on the technology system's ability to keep the links between votes and voters as secure as possible. It is possible to store votes on an election server with no links, direct or indirect, to the voter's identity. This is secure if the process of transferring votes to the election server is secure and the de-linking process at the server can be trusted.

However, with government elections, the concern for coercion and vote buying risk creates a need to prevent voters from proving how they voted. This risk can be managed by allowing voters to change votes. The change vote option requires a link to be retained, on the election server, between votes and voters voting accounts. This process of managing the coercion risk creates two problems for government elections. First, the retained link has the potential to compromise vote secrecy. Second, vote receipts cannot be published because this would enable coercers to discover that the coerced had change their votes. Voters may accept the lower standard of secrecy protection, that is the retained link. However not publishing receipts means the election result relies fully on the integrity of the black box servers with no objective verification of the election.

When electronic links are retained between votes and voters the electoral authority must also consider its obligation to correctly inform voters about the security standard of vote secrecy protection. The worst case risk for the electoral authority is that votes with their links to voters identity are stolen from the election server after having informed voters that votes are absolutely secure.

Motivation to attack

The motivation for criminal elements to interfere in a government election is vastly higher than in the typical non-government election. The possibility of secretly controlling the seat of power in a democracy from a single point, an online computer, from anywhere in the world is a magnetic lure for criminal elements – rogue hackers to state backed elite cyber attack units associated with totalitarian governments. The objective may simply be to gain experience for a later time when a particular outcome may have more strategic importance. Electronic voting systems that do not produce a secure audit trail are the most attractive targets for attack. It hands the most astute attackers a chance to operate in pin point darkness, never to be detected. The real competition, particularly in a close contest, could be in the virtual underworld – which corrupt element outsmarts the other.

Client side malware risk – man-in-the-middle attack

A form of vote tampering which is very difficult for any government electoral authority to control is malware installed on voters' computers designed to interfere with what the browser presents on the screen. For example some candidates could be hidden from view or votes changed. With many people voting and a secure verification system this kind of interference is likely to be detected. However it can be used to spoil the election. The resources and motivation required means this a much smaller risk in non-government elections which are also much easier to re-run in the event of a spoiled election.

Independence of engineers

"Independence" means not having a reason to be biased or interested in the election outcome, other than its integrity. Of most interest here is the very small number of IT engineers with authorised access to the vote processing servers. For non-government elections it is normally easy to find an election service provider who is expected to be independent. However it is hard to imagine a government election where all engineers with access to the vote processing servers are truly independent. Anyone who votes, and many who don't vote, have an interest in the outcome of government elections.

In electronic elections a very small number of engineers can be expected have the technical ability to quite easily manipulate the election result in a manner that is undetectable. This means the integrity of electronic voting in government elections rests on the integrity of a small number of invisible engineers – unless the external vote verification process is absolutely secure.

Engineers are mostly very honest people. However the potential for an authorised engineer with a secret intense interest in the outcome of a government electronic election cannot be eliminated. The risk – in any electronic election without secure verification process – is that such a person yields to the temptation to secretly determine who holds the seat of power.

Authorised engineers, if tempted to act corruptly, could know the result of the vote count before it is announced and thereby know exactly how to manipulate the result to produce a tailored outcome. Secret software could even be developed and employed to automate the manipulation process – producing a tailored result instantly while the corrupt engineers create an illusion of being safely uninvolved at a distance at counting time.

Hush risk

How will honest authorised engineers react if they discover an error in their work, or interference from a hacker, which irreversibly corrupts a government election result. If the election verification process is weak and easily defeated the engineers have a choice of disclosing the issue and taking responsibility for a failed government election or keeping quiet knowing that no one will ever know. Is this a fair risk for democracy?

Technical skill

High security electronic voting software is highly complex technology. Electoral authorities have a long history of low technology paper-based voting. Few electoral authorities have the technical skill to properly evaluate leading edge voting software technology. If the appropriate questions are not asked and the testing process and security risks not thoroughly understood, the electoral authority can be easily led astray by software vendors.

The most publicised example is the 2010 Washington, D.C. internet voting trial. In this case the District held a mock election where the public was invited to attempt to compromise security. The system was hacked within 48 hours, every vote was changed and almost every secret vote revealed. The intrusion was not detected for nearly two days. The trial was suspended. The District's electoral authority was naive in procurement but wise in testing. Democracy was not compromised.

Scientific opinion – no known solution

Most (some say all) leading internet security experts and scientists across the world who have studied electronic voting agree on the subject of online voting and telephone voting in government elections with secret ballots. It's not safe. It's known as the most difficult computer security issue ever attempted with no known solution. Many of these experts are associated with Verified Voting Foundation. David Jefferson, a computer scientist at Lawrence Livermore National Laboratory, and Board Vice-Chair of the Verified Voting Foundation, in his essay, If I can bank online why can't I vote online argues that "online voting is an exceedingly dangerous threat to the integrity of U.S. elections".

PART 2. Case Study – New South Wales Electoral Authority iVote system March 2015

Introduction
NSWEC pre-launch confidence in iVote security
Security scientists warn iVote is not safe
Voting started – serious flaws discovered, media reports and publications
BigPulse warned NSWEC about iVote security flaws
Poor testing – lessons not learnt
iVote's verification process seriously flawed
Vote secrecy at risk
Vote tampering risks
Flaws in iVote's re-vote process which attempts to defeat coercers
iVote is a trademark
Conclusion – iVote not safe, voters misinformed

Introduction

This example illustrates many of the security risks faced by government electoral authorities mentioned in Part 1. of this essay. It draws almost totally on publicly available information. The example illustrates the importance of rigorous pre-launch testing and providing correct information to voters about vote security standards. It also illustrates the difficulty of attempting to manage coercion risk with remote electronic voting.

There is no criticism of the software vendor's technology implied here. Many of the security issues discussed here are an inevitable consequence of the way the vendor's client, the NSW Electoral Authority, used the technology. The NSWEC attempted to provide secure vote verification technology, while also attempting to manage coercion risk, man-in-the-middle attack and vote secrecy – the solutions clash causing a serious degrading of the verification process and weakened standards on vote secrecy. However this example does raise a question about the social obligation of voting technology vendors. Should voting technology vendors take an interest in the way clients represent the technology's security standards to voters? For example, BigPulse does not knowingly allow its clients to misrepresent security standards to voters and enforces various disclosure standards.

In March 2015 New South Wales State General Election the NSW Electoral Authority (NSWEC) harvested and counted 280,000 online and telephone voting with its iVote system. That is about 5 per cent of the total vote – a very large increase on the 46,000 votes harvest with its earlier model iVote in the 2011 state election.

Online and telephone voting was available for anyone with a disability because of that disability caused a difficulty voting at a polling place or without assistance and to people not be in NSW throughout the hours of polling on election day.

One obvious difference in the 2015 iVote promotion compared to 2011 was the claim that votes can be securely verified as recorded correctly and also verified as counted. Strong assurances were made about vote integrity and secure vote secrecy.

Well before the election launch date BigPulse and at least one network security scientist independently warned the NSWEC that iVote was not secure as specified.

After 19,000 people had voted in the election using iVote a basic testing failure was revealed – two political parties had been left off part of the ballot. After 66,000 people had voted two respected computer networks security scientists from two leading universities demonstrated a security flaw exposing online votes to tampering risk. The scientists alerted the appropriate authorities, waited until the issue was fixed then published their discovery.

Yet a few days after close of voting the NSW Electoral Commissioner Colin Barry, proclaimed "a great success .. the staggering increase in voters using the iVote system demonstrates that confidence and demand for secure online voting systems is growing despite ill-intended efforts to discredit its integrity," Computerworld 31 March, 2015.

It is not necessary to view a single line of iVote code to know that the iVote election verification process is seriously flawed. As explained in Part 1. the attempt to manage coercion risk with remote electronic voting inevitably clashes with the verification process.

NSWEC pre-launch confidence in iVote security

The NSWEC had four years to prepare for the 2015 election. On March, 2nd 2015, two weeks before the start day for online voting, the NSWEC released its 102 page iVote System Security Implementation Statement. The following extracts are taken from the forward written by NSW Electoral Commissioner, Colin Barry,

"With the implementation of an updated iVote® system for the 2015 State General Elections, NSW is again at the forefront of online voting worldwide."

"Critics of online voting raise threats to the integrity of such systems from unauthorised access and manipulation. This Security Implementation Statement outlines how NSW Electoral Commission plans to secure the system and develop procedures to address perceived threats."

"I am particularly pleased with the introduction for 2015 of the ability of an elector using iVote® to verify their vote, which provides additional assurances of the integrity of electronic voting in NSW. "

Similar confidence about the security of iVote was expressed by Richard Carroll from the NSWEC about a month earlier as published February 4th on the ABC website,

"People's vote is completely secret. It's fully encrypted and safeguarded, it can't be tampered, and for the first time people can actually after they've voted go into the system and check to see how they voted just to make sure everything was as they intended."

The confidence expressed by the NSWEC here appears to clash with respected scientific opinion.

Security scientists warn iVote is not safe

Stanford PhD Vanessa Teague, Honorary Fellow in the Department of Computing and Information Systems at University of Melbourne, specializing in electronic voting, with a focus on cryptographic schemes for end-to-end verifiable elections, published her concerns about iVote, March 11, 2015, The Conversation. Teague wrote, in reference to the iVote published security statement,"it still doesn’t answer many of the concerns I have been raising with the commission for more than a year – particularly over vote privacy and verifiable election integrity”.

Voting started – serious flaws discovered, media reports and publications

In the first eight days of voting two serious flaws became public knowledge.

The first was discovered by a voter on the second day of voting, iVote was taken offline for several hours to correct an error in the online ballot form, NSW election 2015: NSW online ballot paper error 'disadvantaged' parties, court action flagged, The ABC, March 18th. Two political groups were left out of part of the online ballot. 19,000 people had already voted. NSW state election 2015: Legal challenge looms over upper house iVote error, Sydney Morning Herald, March 30th. This ballot presentation error illustrates a failure in the most basic form of pre-launch testing and with only one election under management at the time. Such errors are extremely rare at BigPulse which often has several hundred elections under simultaneous management. The difference is experience and testing standards.

The second security incident, a FREAK attack vulnerability, Thousands of NSW election online votes open to tampering, The Conversation, March 23rd.

Apparently the vulnerablity existed for six days during which 66,000 votes were harvested. The risk hole, that is vulnerability, was discovered by Vanessa Teague and J. Alex Halderman, an assistant professor of computer science and engineering at the University of Michigan and director of Michigan’s Center for Computer Security and Society – both are on the Verified Voting Foundation Advisory Board. They analysed the public iVote test voting site and discovered a fairly obvious critical vulnerability which, "could be used by an attacker to steal votes". The two scientists concluded, "NSWEC should cut its losses and back away from voting online at least until there are fundamental advances in computer security. "

While the NSWEC responded by removing the vulnerability it denies it was a serious risk, Response from the NSW Electoral Commission to iVote Security Allegations, NSWEC website, March 25th and iVote system isn't vulnerable: NSW Electoral Commission, The Advocate March 28th.

The NSWEC reacted with comments like, "The spokesman went on to point out any claims made by Dr Halderman and Dr Teague when it comes to online voting should be taken with a grain of salt." While also stating, "We recognise their academic standing... but they are, in this situation, anti-internet voting", CNET, March 24th.

"Sadly, NSW officials seemed more interested in protecting their reputations than the integrity of elections." New South Wales Attacks Researchers Who Found Internet Voting Vulnerabilities, Electronic Frontier Foundation April 6th.

Other media reports and papers:

Media:
Freedom to Tinker blog, March 23, 2015 Security flaw in New South Wales puts thousands of online votes at risk
ABC, March, 23, 2015 NSW election 2015: iVote flaw 'allowed vote to be changed'; electoral commission fixes vulnerability,
Lifehacker, March 23, 2015 The Big Security Flaw In NSW Online Voting
Crikey, April 20, 2015 How iVote puts democracy at risk.

Papers published:
J. Alex Halderman and Vanessa Teague, June 2015 The New South Wales iVote System: Security Failures and Verification Flaws in a Live Online Election
Ralph McKay, Founder BigPulse.com, September 2015, Submission to Joint Standing Committee on Electoral Matters Inquiry into the 2015 NSW state election.

BigPulse warned NSWEC about iVote security flaws

The NSWEC’s iVote is a response to voter demand for online voting in government elections. A large part of that demand has been generated by BigPulse’s successful security record in non-government elections in the same state.

BigPulse does not knowingly allow its technology to be used in a way that can mislead voters or with security settings which are clearly inappropriate. Therefore in the iVote procurement phase BigPulse responded to the NSWEC’s 2013 call for Expression of Interest (EOI) by commenting on the obvious inconsistency between the stated objective for a secure voting system and the published iVote specification. For example in December 2013 BigPulse stated, "Change vote is requested to limit coercion along with the ability to publish receipts. These appear to be conflicting requirements." BigPulse also expressed concern about exposing vote security to the telco networks.

However, the NSWEC excluded BigPulse from its iVote tendering process without seeing or testing BigPulse technology and without asking any direct questions about the technology or pricing. The explanation for this exclusion was vague and very difficult to obtain. The alternative open to the NSWEC was to engage with BigPulse to explore the security concerns and gain from experience. Other vendors were also excluded. It's unknown how many vendors commented on the security concerns.

As a matter of public interest, on several occasions BigPulse raised iVote security and procurement concerns with Gareth Ward MP, Chair, Joint Standing Committee on Electoral Matters. Mr Ward forwarded these concerns to the Electoral Commissioner but no questions were answered. On February 19, 2015 Mr Ward stated, "The NSW Electoral Commissioner is independent. I am very confident that the iVote System will enhance pathways for voters at this election."

The NSWEC EOI indicated a preference for vendors with prior experience in government elections. This illustrates a procurement risk for electoral authorities. Service providers with the highest security expectations in the way their technology is used are unlikely to have such experience. Part 1. of this essay explains why.

Poor testing – lessons not learnt

The iVote security statement mentions "lessons learnt from the international incidents". One example given is the Washington, D.C. internet voting trial mentioned in part 1 of this essay – hackers from the public were invited to find security risk holes prior to live voting. Yet the NSWEC did not invite the public to rigorously test and attempt to hack into the system prior to live voting. It appears the lesson NSWEC took from Washington, D.C. was to avoid the risk of pre-launch bad press that can follow rigorous public testing of a voting system that does match the claimed security standards. As a consequence at least one serious risk hole was found too late – raising the suspicion that others exist.

The 2011 version of iVote misrecorded 43 votes, which appeared with the letter “N” in the box(es) where preference numbers are supposed to go. Clearly its 2011 US-sourced technology was not tested properly for the task. Incredibly iVote 2011 did not offer voters any form of vote verification tool. The latest model iVote is supplied by the Spanish-based company Scytl – as Dr Teague mentions in The Conversation, the same company that provided Norway’s online voting system that was discontinued last year after a software bug caused votes to be only very weakly hidden from election officials.

The NSWEC did apparently invite interested people to review the iVote source code but on the legal condition of a strict hush clause preventing reviewers from talking in public about their findings until after the period when the election could legally be challenged. This is not the way to attract the most talented code reviewers. If vote security matters above all else, as it should, the most talented bug finders ought not be repelled with a hush clause that acts against the public interest.

iVote's verification process seriously flawed

iVote uses a two step verification process – a "vote-as-cast verification" service available before vote close intended to confirm the vote intention is recorded correctly. A second step, "vote counted verification", available for a period after vote close, is intended to inform the voter if the vote was actually counted.

This iVote method scores very poorly on the Election vote count verification protocol mentioned in part 1 of this essay. The phone voting aspect scores 1/10 only if the phone issued receipts are counted as full take home receipts. The online voting aspect of iVote could score 2/10 for issuing more secure vote receipts. The use of a separate verification channel that is, verification by a phone is an attempt to defeat man-in-the-middle attack. At best all it does is confirm that the vote intention is recorded on the iVoter server. However it does this at the risk of compromising vote secrecy. The attempt at "vote counted" verification is not a real verification. A harsher scorer would mark iVote lower for promoting insecure verification as secure.

iVote does issue vote receipts which is unusual for a government election. At first glance this may appear to offer the opportunity for data to assist research into vote coercion and vote buying risks. However the coercion risk management process is so seriously flawed it is doubtful that any useful ceorcion data could be obtained. Also the iVote vote receipt is not always a reliable real vote receipt as defined in part 1 of this essay. Phone voting receipts are transmitted back to voters insecurely by phone. The phone vote receipts rely totally on the voter's ability to accurately manually record the 12 digit receipt number. Voters could mistakenly or mischievously claim the receipt misrepresents the vote that was submitted. A similar issue exists for online voting if the vote receipt is not printed or electronically recorded as soon as received.

The most serious weakness in iVote's verification process is the way the receipts are used.

The first step, "vote-as-cast verification" process involves phoning a designated 1300 number entering the 8 digit iVote number, 6 digit PIN and 12 digit receipt number to hear the recorded preferences. Apart from being slow and clumsy which will deter many, the process has obvious security weaknesses related to phone transmission – it can compromise vote secrecy. This first stage "verification" process achieves nothing more than informing the voter that iVote, or someone interfering, knows the voter's intention.

The "vote-as-cast verification" process attempts to defeat man-in-the-middle attack and any failure to record the vote correctly or claims of misrecording by allowing re-voting. However this re-voting idea fails completely for last minute votes because the "vote-as-cast verification" shuts down at the time of poll close. This sudden shut down no doubt relates to the fact that any chance to correct a mis-recorded vote is lost after poll close. The sudden shut down also relates to the fact that iVote's vote receipts are not tamper proof.

The second stage, "vote counted verification" – a webpage asking for a receipt number only, returns the words, "Confirmed. The voting receipt number listed below was included in the count. An identical "verification" page response could be made to appear without the receipt number even leaving the voter's computer. All this verifies to the voter is that iVote can detect a valid receipt number. There is no way the voter can tell if the vote was actually counted. The voter has to trust iVote.

This means the election result could be secretly corrupted and remain undetected because voters have no way of knowing for sure if votes were counted or counted correctly or if fakes were included in the count.

The central feature of an electronic verification process is missing in iVote. iVote does not publish a list of vote receipts with vote preferences after vote close – that is, it does not produce a transparent audit trail. So the vote counts cannot be verified as defined in part 1 of this essay. This is curious because the iVote RFT V1.0 document published November 2013 states, .. a full list of all formal votes with all preference markings is provided for any member of the public to undertake their own vote count and compare to the results published on the NSWEC virtual tally room website."

Why did NSWEC not follow through with this fundamental election verification tool – a published list of vote receipts?

Potential reasons for not publishing vote receipts include:
1. The risk that some voters discover their receipt number does not appear in the list or the attached vote preferences are wrong;
2. A concern that receipt numbers were not securely protected at all times;
3. A published list of receipt numbers would reveal which receipt numbers were associated with votes actually counted. This would alert coercers who were not aware the coerced had re-voted in secret. This would betray the trust of these coerced voters and could also endanger their safety.

Point 1. would require a serious failure of iVote technology or the intended vote not actually reaching the iVote server as with the FREAK attack vulnerability. Point 2. is a valid concern particularly in the case of phone voting and for anyone using the phone based vote "verification" service. Receipt numbers were subjected to the risk of illegal harvesting with associated phone numbers in the telco networks. Point 3. illustrates a fundamental flaw in the iVote design which impacts all government remote electronic voting. That is, iVote allows voters to change their vote to trick coercers but this defeats any chance of using a meaningful transparent election verification process.

Vote secrecy at risk

iVote allows people to change their vote. This implies a link is retained between each vote and the voter's iVote account. This raises a question about the ability of anyone who gains access to the server to detemine how people voted – particularly as the votes are obviously decrypted during "verification" when the voter's preferences are sent back to the voter by telephone. Of course votes enter the iVote server linked to IP addresses.

The iVote FAQ states, enter your iVote® number, PIN and receipt number and hear your preferences as voted. " Therefore the "vote-as-cast verification" service involves data, which links the voter's iVote account and personal vote receipt number, being transmitted to iVote via a personal phone call. This results in the voter's vote preferences being sent back though the same phone line.

It is difficult the see how iVote's "vote-as-cast verification" is not a trust based system. Trust that people with authorised access to the iVote servers are not viewing secret votes. Trust that no one can hack into the iVote servers. Trust that vote preferences, registration numbers, PINs and receipt numbers are not tapped during transfer through telco networks.

The existence of phone tapping technology is not a secret. iVote telephone votes appear to be exposed to unencrypted transfer through parts, if not all, of the telco network – is all data passing through telco central servers securely encrypted? NSWEC has no control over these telco servers. It appears unlikely that NSWEC even knows the identity of all, if any, telco employees and contractors who have authorised access to relevant telco servers. Nor does NSWEC control the security standards of these telco servers known to be highly attractive targets for hacking.

Vote secrecy can be compromised without the voter or the electoral authority knowing about it. And there is no way to verify that secrecy was not compromised.

Vote tampering risks

The main point about vote tampering risk is that there are so many possibilities. This is why it is essential for the vote and election verification processes to be secure. Examples include: client side malware allowing man-in-the-middle attack – as with the FREAK attack vulnerability, phone vote tampering while in transmission through telco networks and countless potential for bugs and unauthorised code changes in the iVote servers.

The "vote-as-cast verification" service is performed with a telephone call. The telephone idea is obviously intended to make it easier for voters to detected corruption in online votes caused by any client side malware. However the phone verification channel has two obvious weak points. It makes the verification process so slow and clumsy that many people are likely to ignore it. Phone verification also creates additional vote secrecy risk because it exposes all verified votes to insecure phone transfer. This fact alone is likely to deter many from verifying their votes. People voting by phone are also verifying via the same phone channel which means any telco-based interference could easily remain undetected on phone votes.

People voting with iVote have no way of knowing for sure if their vote receipt number is unique. A simple way that iVote could deceive voters even if iVote did produce a transparent audit trail, is to issue many voters – who submitted the same ballot selections – with fake vote receipts all showing the same receipt number and ballot selection while actually recording different ballot selections and different receipt numbers. The "vote-as-cast verification" software could be altered to mask this form of vote corruption. The "vote counted verification" page would return "vote counted" for everyone affected holding the same receipt number – but only one of the intended votes is counted. The fake receipt numbers and attached votes are counted and remaining unknown to voters. This risk is less when the system is known to be properly tested and security well controlled. However it illustates the kind of hidden risks in a black-box electronic voting system when the verification process is weak.

Anti-coercion management in the NSW Electoral Commission's iVote system – betraying electors' trust, endangering voter safety

Vote corruption and loss of vote secrecy are not the only concerns when naïve electoral authorities venture into online voting. Amateur attempts to manage coercion risk can even endanger the safety of vulnerable electors. There exists compelling evidence that the NSW Electoral Commission fell into this design trap with its iVote technology in the NSW 2015 State Election.

The obvious way to manage coercion risk in remote electronic voting is to allow electors to re-vote in secret to defeat the coercer – the re-vote cancels the earlier coerced vote from being included in the final vote count. In this special case of coercion-motivated secret re-voting the electoral authority not only has the usual obligation to protect the secrecy of the elector’s vote preferences – but also the unusual obligation to protect the secrecy of the act of re-voting.

This additional secrecy requirement lays the trap for amateurs. It means electors cannot be offered an authentic vote-counted verification mechanism because a coercer can use such a mechanism to detect when a coerced vote was cancelled by a re-vote.

Enabling coercers to discover they were tricked with a secret re-vote betrays the trust of the coercion-motivated re-voter. This form of privacy breach can obviously be a cause of distress for both the coerced and coercer. In the case of remote online voting in the household, for an unstable coercer this may even be a potential trigger for domestic violence.

In a practical sense, coercion-motivated secret re-voting is incompatible with a transparent vote count audit or even a limited vote counted mechanism.

Curiously, iVote attempts to offer both coercion risk management along with an obscure form of vote counted verification service – a serious design flaw.

In the lead up to the NSW 2015 State Election the NSWEC released its iVote System Security Implementation Statement which states, “The iVote® system has an anti-coercion mechanism in that it allows a user to re-vote during the voting period.”

This option to re-vote encouraged any coerced electors to trick their coercers by re-voting in secret. A re-vote is understood to cause the first vote to be cancelled. A coercer is likely to know the receipt number of the coerced person's first vote but not the re-vote. Receipt numbers are unique to each vote.

iVote also encouraged electors to "verify" which votes were counted using its "vote counted verification" service (https://cvs.ivote.nsw.gov.au/receipts/#/home). The iVote FAQ states, “How do I know that my vote was counted? From the Monday following Election Day, you can confirm your vote was included in the count by visiting ivote.nsw.gov.au select ‘Verify’ and enter the receipt number.”

This implies iVote enabled coercers to discover without effort when they were tricked with a re-vote and therefore betrayed the trust of the most vulnerable electors.

The author noticed this iVote design flaw when observing the NSWEC’s iVote literature during the vote-counted verification phase of the 2015 State Election. Immediately, that is, on April 5th 2015 and again on April 7th, the author alerted the NSWEC along with a comment on the danger for any coercion-driven re-voters. However the NSWEC did not respond until April 20th and the "vote counted verification" page was not removed. The NSWEC’s late response stated,

"Your comments have been considered but are not of sufficient merit to warrant any changes to the current iVote system. The Commission’s position on coercion in iVote is based on the paper prepared by Dr Smith of Sydney University which can be found on our website at http://www.elections.nsw.gov.au/__data/assets/pdf_file/0003/118380/NSWEC_2013_Report_V2.0.pdf."

The NSWEC response did not confirm or deny the existence of the design flaw. The response appears to rely solely on the assumption that coercion is not a risk that needs to be managed in NSW state elections. The response was inconsistent with the iVote System Security Implementation Statement which includes the comment,

“The iVote® system has an anti-coercion mechanism in that it allows a user to re-vote during the voting period.”

This comment demonstrates that the NSWEC believed coercion was a risk just prior to the 2015 State Election and that there was merit in managing it. Yet just several weeks later, at a time when the “mechanism” was being offered to NSW electors – having just been alerted to the danger it created for electors – the NSWEC apparently then adopted the position that coercion does not exist in NSW, by saying,

“not of sufficient merit to warrant any changes to the current iVote system.”

The NSWEC had received the design flaw alert from the author, and was informed of the danger it presented to vulnerable voters, yet it chose to leave the iVote vote counted service online and operating for many days.

Responding to the danger would have required the NSWEC to immediately remove the iVote “vote counted verification” website many days prior to the heavily advertised cut-off date. However this would have required a public explanation. An honest explanation would have severely damaged the iVote brand name and reputation of the NSWEC. It is difficult to escape the conclusion that the NSWEC placed higher priority on protecting its reputation than eliminating a danger it unwittingly created for the most vulnerable electors.

This behaviour is consistent with many other misplaced priorities in the NSWEC’s management of its iVote project which appear to place protection of reputation above vote security and transparency.

The NSWEC’s September 2015 submission to the NSW Parliament Electoral Matters Committee Inquiry into the 2015 NSW State Election provides further insight,

“The Commission sees coercion as a small risk because of the difficulty for any person or organisation to identify those individuals intending to vote remotely and in sufficient numbers, and then successfully subvert their vote to influence an election result. Such coercion would have to be of such a scale that the cost and risk would make it a barely viable option to attempt.”

Here the NSWEC ignores the possibility of coercion within the family home. This is consistent with an apparent strategy to avoid any discussion regarding a serious security flaw related to coercion-driven re-voting endangering voter safety. Moreover in a close election even a few isolated coerced votes can make a difference to the result. Significantly, the NSWEC referred to a “small risk” not a zero risk. With 280,000 electors a “small risk” could in fact represent a large number of people. Media reports have referred to an “epidemic” of domestic violence in the State of NSW. Given the potential for unstable coercers to react on discovering they were tricked, even one person at risk is too many.

It would be unwise to assume that any re-voting was not coercion-driven because there is no way to know for sure why an elector requested a re-vote. The NSWEC has not released statistics on re-voting. However it is very unlikely that with 280,000 remotely harvested votes no elector requested a re-vote. The PWC Electoral Commission NSW Post Implementation Review of the iVote Project FINAL Report mentions an, “EMA interface for multi vote removals” incident –“multi vote” appears to confirm the existence of re-voting.

The author has considered the possibility that iVote’s vote counted service was deliberately designed to misinform voters when re-voting occurred or that all votes from the same elector were assigned the same receipt number. Both options would be a concern with differing security implications. However the NSWEC has released technical documents which make clear that vote receipts were unique to each vote, as they should be. Further, the fact that the PWC audit report does not mention the re-voting design flaw also indicates it was not recorded as an incident. Therefore the possibility that the NSWEC secretly reacted by causing the iVote vote counted service to deliberately misinform voters, can be ruled out.

The NSWEC was given an obvious hint by the author that its iVote specification was seriously flawed in the lead up to the iVote procurement process. The following rhetorical question, published in the iVote Addendum 1 during the iVote Expression of Interest phase in December 2013, came from the author,
"Change vote is requested to limit coercion along with the ability to publish receipts. These appear to be conflicting requirements?"

The hint was ignored. The NSWEC responded at the time with,

"Voters are able to re-register, cancelling the original vote, and vote again. The receipt number is used to access a vote verification system to check their vote as described in Attachment 1."

The response demonstrated that the NSWEC was naïve in its understanding of electronic voting systems and associated risks. The risk was compounded by a procurement process destined to exclude vendors that would not permit such basic security failures. In a document that attempted to explain why BigPulse, the Australian leader in online voting technology and services, was blocked from competing in the iVote tender the NSWEC stated in reference to BigPulse,

“Extensive commentary on security with little attempt to describe relevance to NSWEC requirement”

Around April 20th, BigPulse founder, Ralph McKay, submitted a short comment on the iVote vote counted flaw in response to the FlagPost (Parliament of Australia library blog site) publication "iVote, therefore I am", March 16th. However the comment was not published. After about 20 days the web manager responded, "The section that has authored the post have considered your comment and have decided not to publish it" with reference to " ... reserves the right not to publish comments that are inconsistent with the objectives of FlagPost. This includes comments that are not relevant to the article, factually incorrect or politically partisan ..". None of which are true.

iVote is a trademark

iVote is a NSWEC registered trademark. The underlining core technology has changed since the mark was first promoted in the 2011 election. The continuity in use of the trademark may give voters a false impression of continuity in core technology. The track record of the technology and the experience gained in using that technology is very important.

The use of a registered trademark suggests the NSWEC has commercial ambitions for iVote. Indeed the iVote EOI documents published in November 2013 state, "The NSWEC retains the ability to sub-license the use of the iVote Core Voting System by other Australian and New Zealand election management authorities, both by such authorities installing the system themselves and by NSWEC providing iVote services using the NSWEC implementation of the system".

Conclusion – iVote not safe, voters misinformed

Statements from the NSWEC like, "People's vote is completely secret. It's fully encrypted and safeguarded," are likely to give voters the impression there are no loose bricks in the iVote security wall – that the highest possible data standard protects votes at every stage of the process.

In fact two scientists demonstrated that votes could have been tampered. Basic non-technical analysis shows that vote secrecy cannot be guaranteed; no one can know for sure if all votes were counted or counted correctly and that fake votes were not included in the count. The incomplete ballot in place at launch raises doubts about the quality of the entire iVote testing process – which did not include the public pre-launch testing that exposed the flaws in the Washington, D.C. internet voting trial. The iVote source code review hush clause repelled many of the most competent code reviewers.

The NSW Electoral Commissioner described iVote as at the forefront of online voting worldwide. Yet on the critical issue of vote verification iVote scores just 1/10 or 2 /10 for election vote count verification protocol – far below the accepted standard in use with leading online voting technologies in the non-government voting industry. On the critical issue of vote secrecy it is difficult to assign a quality score because there is no way to verify vote secrecy. However the iVote vote secrecy standard is known to be no higher than the standard of a telephone call.

No real votes are genuinely verified as counted correctly in iVote. This failure is largely a consequence of the attempt to manage coercion risk and man-in-the-middle attack with re-voting.

The NSWEC harvested a significant number of online votes in two consecutive general state elections using two different core technologies under prompted under the one brand name of iVote. The known mistakes and security failures is a sign the NSWEC is plunging too fast into online voting with limited experience directly relevant to the task. Of greater concern is the potential for unknown catastrophic security failures because the iVote system cannot guarantee that any vote is recorded correctly and no vote is genuinely verified as counted correctly.

Electoral authorities have an obligation to ensure voters are properly informed of the security standards protecting each vote and not to take unnecessary risks that can endanger the integrity of democracy.

Appendix

Comment submitted to publishers in April 2015.

It would be useful if the NSW Electoral Commission could explain a point of confusion in its iVote vote counted verification service. It affects 280,000 people who voted online in the NSW March state election.

If the verification service does what it claims to do, "confirm your vote was included in the count", it would seem to betray the trust and potentially endanger the safety of people who re-voted to trick coercers. People voting a second time, because they felt intimidated to vote against their intention the first time, would not expect the NSWEC to enable coercers to easily discover when they were tricked. But that's what the iVote verification service will be doing if it really does what it claims to do. On a re-vote all previous votes are assumed to be cancelled. A cancelled vote would alert a coercer that the coerced had re-voted.

I alerted the NSWEC to this concern on April 5th and again on April 7th. The NSWEC has not responded and the iVote "vote counted verification" webpage was not removed.

Perhaps the verification service deliberately misinforms to protect the coerced? This would mean people who voted twice will be informed, if they check, that both votes were counted. And none of the 280,000 electors could detect if an impersonator re-voted in their name.

Perhaps iVote issued the same receipt number for all votes believed to be from the same elector? It solves nothing, except the verification service could respond, "Confirmed. The voting receipt number listed below was included in the count." As iVote does. This statement will always be true regardless of which votes with the same receipt number were counted! Maybe the choice of words is just coincidence.

It would also help if the NSWEC explained to electors how a black-box computer can verify itself. No one else can.


TRUSTe European Safe Harbor certification
Segala certified logo
For visually disabled
ADA section 508 compliance



Contact · Privacy Statement


© JustIssues Pty Ltd 2000-2016
ACN 091 291 057 ABN 55 091 291 057
All rights reserved.