Summary
During one of our recent elections a security researcher reported to Voatz that the size of an encrypted ballot submission from our web voter portal could potentially reveal which candidate a voter had selected to someone able to observe that voter’s encrypted network traffic. We confirmed the finding and deployed the correction promptly to the web portal frontend. The researcher then verified the correction independently and confirmed in writing that the issue is resolved.
No vote was altered, no voter data was exposed to Voatz, to any jurisdiction or to any third party, and no backend, database or tally was affected. The mobile applications were not affected.
What was reported
The researcher examined the JavaScript of the web voter portal frontend and wrote to us with two concerns, both of which she described as previously published and still unresolved.
- The length of the encrypted ballot submission varied with the length of the selected candidates’ names, so an observer of a voter’s encrypted traffic could infer the selection from the size of the request alone.
- The key exchange that sets up the portal’s additional encryption layer was not authenticated independently of the TLS connection.
The first concern was correct for the web client as it stood at the time of her report, and this statement describes how it was corrected. The second is a property of every browser-delivered application and is addressed below.
What the property was, and what it was not
When a voter submits a ballot through the web portal, the browser encrypts the ballot with an additional layer before sending it over the TLS connection. That layer preserves the length of what it encrypts. Because the ballot named the selected candidates, a ballot naming a candidate with a long name produced a slightly longer request than one naming a candidate with a short name. The difference was a few bytes.
To make use of this, an attacker would have needed to capture a specific voter’s encrypted traffic from a position on that voter’s own network path, such as a compromised home router or public Wi-Fi, know which ballot style the voter was completing, and match the observed request size against the candidate names on it. The attacker could not read the ballot, change it, prevent it, or learn anything about any other voter.
The property did not involve and did not affect:
- the recording, storage or counting of any vote;
- any backend, database or tally;
- the confidentiality of any ballot to Voatz, to the jurisdiction or to election staff;
- the mobile voting applications, which have always padded candidate names to a common length;
- voter identity verification or eligibility checks.
What we did
On receiving the report we changed the voter portal frontend so that every ballot submission is padded to a fixed size before it is encrypted. The encrypted request is now the same length whatever the voter selects: a full ballot, a ballot with some contests left blank, a blank ballot and a declined ballot all produce identical traffic. No change to the backend was needed, and no voter had to do anything differently.
The correction was built, tested and deployed to the voter portal without delay. Before deployment to the live portals we verified it on our test environment, which runs the identical production code, by measuring nine submissions chosen to differ as widely as the ballot allows, including candidate names differing by thirteen characters. Every encrypted submission was the same size, and six of the nine were cast and accepted by the backend as normal ballots. After deployment we confirmed from our logs that all ballots were being accepted and receipted as before.
The researcher then examined the change, compared it with the version she had analysed, identified the padding routine, and confirmed to us in writing that the issue is resolved.
The mobile applications
The Voatz mobile applications were not affected by this finding. For the apps, the backend extends every candidate name on a ballot to a common length before the ballot is delivered, and the backend will not create or accept a ballot style without this protection, so the size of a vote from the apps has not depended on the selection.
The researcher’s second concern, that the key exchange protecting the session is not authenticated independently of TLS, drew on reports published about earlier versions of the mobile applications. In the current iOS and Android apps the backend signs its session key, together with the client’s key and the device identity, under a long-term key whose public half is built into the app. The apps refuse any session whose signature is missing or invalid, on every production backend. An attacker who intercepted the connection could not substitute the backend’s key.
For a web application that protection cannot be delivered in the page itself, because the code that would check a signature arrives over the same connection an attacker is assumed to control. This is a property of every browser-based application, not of our design. The web portal’s defences against interception are therefore at the transport layer: HTTP Strict Transport Security with preloading, a strict content security policy, TLS 1.2 or later, and certificate transparency. Our additional encryption layer, which the researcher examined, is defence in depth against passive capture, as she noted.
What comes next
We will continue to offer jurisdictions the option of mailed return codes, the approach used in Switzerland, which gives voters a way to confirm that the ballot recorded for them matches what they cast, independently of the web portal. That option carries significant additional postage and printing costs over and above what a jurisdiction already pays for its election, and to date adoption of this technique has been quite slow globally. We will keep offering it.
Acknowledgement
We thank the researcher for a clear, courteous outreach and for taking the time to verify the correction. She asked for nothing in return. Independent and collaborative scrutiny of this kind makes election systems better, and we welcome it.
Researchers who find a security issue in a Voatz system can report it under our disclosure policy, through our bug bounty program, or directly to the Chief Security Office at cso@voatz.com.
