Why End-to-End Verifiability Fails Against Real-World Client-Side Attacks

TLDR: End-to-end verifiability (E2E-V) in internet voting systems provides cryptographic proof that a ballot was counted correctly, but it offers zero protection against client-side compromise. Attackers don't need to break the crypto when they can simply phish, smish, or deploy malware on the voter's device to alter the ballot before it is even encrypted. For security researchers and pentesters, this highlights that cryptographic integrity is irrelevant if the input source is fundamentally untrusted.

Cryptographic protocols are often treated as a panacea for security failures. In the context of internet voting, E2E-V is the current industry darling, marketed as the mechanism that finally makes remote voting as secure as a physical ballot box. The logic is elegant: use homomorphic encryption or mix-nets to ensure that every vote is recorded and tallied without revealing the voter's identity. If you are a researcher, the math looks solid. If you are a pentester, you know that the math is only as strong as the environment where it runs.

The Fallacy of the Cryptographic Loop

The fundamental flaw in relying on E2E-V for government elections is the assumption that the voter's device is a secure, isolated environment. It is not. When we talk about internet voting, we are talking about a massive, heterogeneous fleet of mobile devices and home computers, most of which are running unpatched software, vulnerable browsers, and a litany of third-party applications.

E2E-V protects the data in transit and at rest on the server. It does nothing to protect the data at the point of origin. If an attacker has successfully deployed a keylogger or a man-in-the-browser (MitB) attack, they can intercept the user's intent, modify the ballot payload, and then allow the legitimate E2E-V process to encrypt and submit the malicious data. The system will report that the vote was "correctly cast and counted," because, from the perspective of the cryptographic protocol, it was. The protocol has no way of knowing that the user's intent was subverted before the encryption step occurred.

The Real-World Attack Surface

During a penetration test, we rarely target the core cryptographic primitives of a system because they are usually implemented by libraries that have been audited to death. Instead, we look for the path of least resistance. In an internet voting scenario, that path is almost always social engineering.

Attackers do not need to exploit a zero-day in the voting platform's backend. They use T1566.002 (Spearphishing Link) or T1566.003 (Spearphishing via Service) to deliver malicious payloads. Smishing—SMS-based phishing—is particularly effective here. By sending a message that mimics an official election notification, an attacker can direct a voter to a counterfeit app or a malicious web portal.

Once the user is on the malicious site, the attacker can perform a variety of actions:

• Credential Harvesting: Stealing the authentication tokens required to access the voting portal.
• Payload Modification: Injecting malicious JavaScript to alter the selection on the ballot before the user hits "submit."
• Session Hijacking: Using A01:2021-Broken Access Control to take over the user's session after they have authenticated.

The impact of these attacks is magnified by the scale of the target. A single successful smishing campaign targeting a specific demographic can alter thousands of votes. In many jurisdictions, elections are decided by margins of less than one percent. You do not need to compromise the entire election management system to change the outcome; you only need to compromise enough individual voters to flip the margin.

Why Recounts Are a Digital Nightmare

One of the most dangerous aspects of moving to a fully digital, E2E-V system is the loss of physical auditability. In a traditional paper-based election, a recount involves physically re-examining the ballots. If a machine is compromised, the paper trail remains the source of truth.

In a digital-only system, a recount is often just a re-run of the same flawed software. If the system was compromised by malware that altered the votes at the point of entry, the digital logs will consistently show the same fraudulent results. The only way to "recount" in a digital system is to conduct a complete re-vote, which is logistically impossible in a high-stakes government election. This is why distributed denial-of-service (DDoS) attacks are so effective against these systems. An attacker doesn't need to change the votes; they just need to prevent the votes from being cast, effectively disenfranchising a specific segment of the population.

Defensive Realities

Defending against these threats requires moving beyond the "cryptography is enough" mindset. If you are building or auditing these systems, you must assume the client is compromised. This means implementing robust device attestation, using hardware-backed security modules (HSMs) where possible, and ensuring that the voting application is hardened against common web vulnerabilities as outlined in the OWASP Top 10.

However, the most effective defense is architectural. If the risk of client-side compromise cannot be mitigated, the system should not be used for high-stakes elections. We need to stop pretending that we can secure the entire internet-connected ecosystem of the average voter.

When you are on an engagement, look at the voting application not as a secure vault, but as a web app that is one malicious link away from total compromise. If the system relies on the user's device to maintain the integrity of the vote, it is fundamentally broken. The next time a vendor claims their system is "unhackable" because of E2E-V, ask them how they plan to handle a smishing campaign that targets their users' mobile devices. The silence will tell you everything you need to know.