Skip to main content

Some thoughts on e-Voting vulnerabilities.


I'm a little bit surprised about today's Schneier blog post "Security Vulnerability of Switzerland’s E-Voting System



Just to add some context before continuing:  I've been researching into that specific e-Voting system since 2022.  I've reported quite a few vulnerabilities (I hold the 1st place in the 'SwissPost e-Voting' Bug Bounty program), also publishing detailed write-ups for some of these security issues. Even today I got some really bad vulnerabilities still being reviewed.

I understand, and support, all the precautions about e-Voting technologies security people usually express. That said, I can't understand the commonplace assertions that depict e-Voting as an unsolvable problem in general terms, which would irremediably leave us with just the 'paper' option. 

However, the worst part is that the issue described in that article, that apparently sustains the subsequent reasoning, is not even a vulnerability but a malware-based social engineering attack. Long story short: the claimed 'vulnerability' is that the e-Voting protocol is not explained in the printed documentation received by the voters, so if your computer is infected, the malware can modify the victim's browser to  show a malicious Swiss Post eVoting website in order to guide the voter through a different UI to 'bypass' the printed 'security codes', which provide the voters with the ability to validate the individual verifiability.

This is a social engineering attack because even if the full protocol is explained in the printed documentation you receive, the malware already present in your computer would simply adapt its approach by injecting into the locally rendered view of the Swiss Post e-Voting website that "a last-minute change introduced by the Chancellery has modified the protocol previously laid out. Please follow the new instructions.". Or, "Please scan the printed documentation you received and upload the image by using this webform to continue the voting process", and so on...

This situation is even easier to understand by extrapolating it to the 'analog world': the day of the election, while you're on your way to the polling station, you run into someone who eventually tricks you into changing your vote. It may happen, but I wouldn't claim that 'analog' voting is useless as a result.

There are some parts in the original description of the 'vulnerability' that I consider a little bit over the top, to be honest. 

"Even with a Master’s degree in computer science, I have difficulties matching the source code to the public documentation and the theoretical protocol. While third parties have formally verified the cryptographic protocol [7], it is difficult to compare the provably correct theoretical protocol to the actual implementation by Swiss Post due to the code size and complexity (over 60,000 lines of Java code, distributed over almost 800 files). Additionally, the possibility for an attacker to force clients to deviate from the intended protocol has not yet been thoroughly studied, leading to vulnerabilities like the one whose risk we showcased."

I don't even have a degree and I profoundly disagree with the previous statement: I've reviewed some of the largest codebases in the world, and this is the conclusion I mentioned in "Finding vulnerabilities in Swiss Post’s future e-voting system - Part 1", published a year ago. 

"Swiss Post e-voting platform is a quite complex system, comprised of different technologies, whose codebase is approximately 150,000 lines of code, most of them Java but also Typescript for the front-end applications. Please note that a significant part of the code is dedicated to implement custom cryptographic protocols and operations.  Despite this, code and component interactions are surprisingly easy to follow as everything is highly documented: cryptographic protocols, architecture, operations...The entire system seems to have been designed, defined and implemented in such a way that a 3rd party may properly audit it.  Actually Swiss Post paid special attention to this aspect by requesting an external auditability report."

This is also corroborated by independent reports, which provide formal metrics to back those conclusions. 

I know it's likely an unpopular opinion within the infosec community, but I see e-Voting as something positive that will facilitate the right to vote for many people in different situations and/or certain conditions. I also acknowledge that a massive undertaking is required to guarantee significant public trust levels around these technologies. SwissPost's approach to this task, which prioritizes transparency and open source, is, under my point of view, the right one.

E-Voting criticism is obviously legitimate and necessary, not in vain I periodically try to break the SwissPost e-Voting system, publicly detailing the outcome of these efforts. However, I think that we should refrain ourselves from challenging maths and code with either vague claims or commonplace assertions. 


Popular posts from this blog

De-Anonymization attacks against Proton services

  In November 2021 YesWeHack invited me to participate in a private bug bounty program organized by  Bug Bounty Switzerland on behalf of Proton AG.  The scope of the program was quite interesting and heterogeneous, as it covered most of the applications and services offered by Proton, such as ProtonMail and ProtonVPN. As a result, multiple technologies and codebases were in scope, ranging from typescript, in the open-source part of Protonmail, to .NET/Swift used by ProtonVPN apps for Windows and macOS respectively. Proton is well-known for its privacy-driven services offer, so they are based on Switzerland where the legislation seems to match Proton's requirements to provide that kind of services: thus maximizing the privacy of their communications, minimizing the amount of data they log from their users while keeping a law-abiding status.  It wouldn't be realistic to think of Proton users as an homogenous group; you may be using Proton because you're genuinely w...

What Really Happened in Chernobyl During the Beginning of the Russian Invasion?

This blog post contains the web version of my research paper: " Seeing Through the Invisible: Radiation Spikes Detected in Chernobyl During the Russian Invasion Show Possible Evidence of Fabrication ", which was unveiled at BlackHat USA 2023 . It is intended to ease the indexing and dissemination of the information collected during this research.  In a few days, I'll be in Brussels presenting this research.  The original paper (PDF) can be downloaded here . Additional references: https://www.wired.com/story/chernobyl-radiation-spike-mystery/  (Kim Zetter) https://www.zetter-zeroday.com/p/radiation-spikes-at-chernobyl-a-mystery  (Kim Zetter) https://medium.com/war-notes/chornobyl-3-92216d21b223  (Olegh Bondarenko) INDEX Foreword Executive summary Introduction 1. Physical      1986      Resuspension      Transport      Humidity      Traffic 2. Cyber    ...

Finding vulnerabilities in Swiss Post's e-voting system: part 3

Exactly two years ago I brought my blog back to life, after many years of hiatus, with " Finding vulnerabilities in Swiss Post’s future e-voting system - Part 1 ". That was the first of a series of blog posts covering that system. During these two years I've been periodically assessing the security posture of this e-voting solution, as part of their Bug Bounty program , which I personally recommend.   Since the first time I reviewed their codebase a lot of things have changed, for good, as many areas have been dramatically improved. To be honest, from a security perspective the codebase back then was kind of a mess.   When the first Swiss Post e-voting platform was published, back in 2019, it faced some public scrutiny, mostly from the academic community.  As a result, some significant issues were uncovered , so eventually Swiss Post decided to suspend the deployment of the system. That first version had been developed by Scytl , Spanish company specializ...

Beware of Java's String.getBytes

Sometimes there are subtle bugs whose origin can be found in some quirks from the underlying language used to build the software. This blog post describes one of those cases in order to let both fellow security researchers and developers, who didn't know about it, become aware of this potential vulnerable pattern. In fact, I'm pretty sure that similar bugs to the one herein described likely affect a bunch of products/codebases out there. In previous posts , I've already described some bugs in the Swiss Post's future E-voting system. While reading their  Crypto-Primitives specification , which among other things describes the custom Hashing algorithm Swiss Post implemented, I noticed something potentially interesting. Basically, there are 4 different types that are supported: byte arrays, strings, integers and vectors. Before being hashed, strings are converted to a byte array via the ' StringToByteArray ' algorithm. However, by comparing ' StringToByteArray...

Losing control over Schneider's EcoStruxure Control Expert

  During Q2 2022, in view of the geopolitical situation that unfolded after the Russian invasion of Ukraine, I decided that it wouldn't do any harm to kill some bugs in some of the main players within the ICS arena. I focused in those software frameworks that are running on the engineering workstations so, if compromised, attackers would be in a privileged position to manipulate controllers logic, thus enabling sophisticated attacks with a potential physical impact (i.e triton). I responsibly reported a bunch a unauthenticated remotely exploitable bugs to the corresponding vendors. In one case, after being ignored for months, I had to resort to the 'twitter, do your magic' approach and tweeted that I would be disclosing the issues if the situation persisted. It took just few hours for the vendor to get back to me. The positive side is that they found the bugs interesting and all that mess ended up in paid work.   This blog post covers a similar scenario in a different ven...