Researchers have found a new vulnerability in a Swiss e-voting platform that could point to the existence of previously unknown security flaws in the iVote platform used by New South Wales.
The revelations come in the wake of increased scrutiny of iVote following its performance during the weekend’s NSW election, with the NSW Electoral Commission (NSW EC) confirming on Friday that there were problems with the e-voting application’s registration system.
The problems led to the commission’s call centre being overwhelmed by enquiries from frustrated voters.
Earlier this month the trio of researchers — Sarah Jamie Lewis from the Open Privacy Research Society, Université catholique de Louvain’s Olivier Pereira and Vanessa Teague from the University of Melbourne — revealed a serious flaw in the Swiss platform that they said could allow an attacker to potentially manipulate the results of a vote but still produce audit data that passed the platform’s verification process.
That vulnerability in the Swiss Post-operated sVote platform was subsequently patched, according to Swiss Post. Key components of NSW’s iVote platform have been built by Scytl, the same software company that helped develop sVote, and the NSW EC acknowledged the presence of that vulnerability in iVote.
However, the NSW EC downplayed the potential for the vulnerability to be exploited because of the necessity for a corrupt insider to leverage the exploit.
In response to the latest findings, the NSW EC issued a statement to Computerworld saying that it is “confident that the new issue [the researchers] describe in the Swiss Post system is not relevant to the iVote system” though it was unclear whether that is because the vulnerability is not present or considered unlikely to be exploited, or whether the vulnerability is not exploitable in exactly the same fashion as it can be with sVote.
The new sVote vulnerability allows the creation of false decryption proofs, according to a paper produced by the researchers.
The exploit they discovered means, with certain limitations, that an attacker could create a false decryption proof that would verify despite being different from the original plaintext ballot cast by a voter.
“This could, for instance, be used by a cheating decryption service to change valid votes into nonsense that would not be counted,” the paper states. “This attack could have a political effect if the attacker knew which votes supported a party it wanted to harm.”
The researchers said that the exploit appeared to have two limitations. One is that in order to fake the decryption proof the attacker needed to know the randomness that is used when a vote is encrypted. They offer two possible scenarios where this could happen: The use of a subpar random number generator or through the corruption of a voting client.
The second is that, at least in the in the case of the Swiss system, an attacker would only be able to produce a nonsense vote rather than a valid vote cast in a manner different to what a particular voter intended. Such an attack could still potentially be used to nullify votes that the attacker disagreed with, the researchers said.
The exploit will probably leave evidence that something went wrong, the researchers state.
However, they add: “If the decryption proofs were mistakenly believed to be sound it seems much more likely that the problem would be attributed to misbehaviour by the clients and the vote receiving components.”
If the vulnerability is present in iVote, potentially the second limitation may not apply — but it depends on the way that votes are encoded.
“We know in Switzerland it’s very unlikely to produce valid votes via this method — and in New South Wales we just don’t know,” Teague told Computerworld. The NSW EC is yet to publicly release the iVote source code, though it did recently launch a source code review program that required participants to sign a deed of confidentiality and privacy with both it and Scytl.
The new paper states that the researchers can’t rule out there are other ways to exploit the same weakness, which relates to an error in the implementation of the Fiat-Shamir heuristic.
The researchers also detailed a range of other problems they identified with sVote but wrote that it was not clear whether they would immediately lead to exploits.
Lewis, Pereira and Teague note that although they are a small team that has been investigating the sVote code base for the first time, in just a few weeks and despite only spending a “small fraction” of their time on the issue they found “critical breaks of both the main components of the proof that there is no server-side fraud — the complete verifiability property”.
The paper notes that the previous sVote vulnerability they discovered was also present in iVote, and that it appears iVote and sVote share a significant amount of code. As a result, the same problems may be present in iVote. “We don’t know for sure they apply,” Teague told Computerworld.
Scytl provided the core iVote voting system that has been used since 2015 and in 2018 won a contract to upgrade the system ahead of the state election.
Teague in 2015 revealed the existence of other significant vulnerabilities in the e-voting platform that allowed potential man-in-the-middle attacks.
The NSW EC has previously pledged that it will increase the transparency of iVote, with the commission saying it plans to make available the source code of key components of the application following the state election.
Scytl and Swiss Post have been approached for comment.