by Joseph Kiniry and Daniel Zimmerman
An open engine for checking ballots
Remote voting can help people who cannot reach the polls or rely on the mail. At the same time, moving voting outside a controlled polling place creates security challenges that deserve particular care: more software and infrastructure can stand between a voter’s choices and the reported result, and failures may be difficult for voters or officials to detect.
Governments are using remote electronic voting in several quite different forms. Estonia has used binding internet voting since 2005. Switzerland has conducted more than 300 federal trials. In the United States, some military and overseas voters return marked ballots by email, fax, or an online system, depending on state law.
We have spent decades evaluating, breaking, and building voting systems, and we know how much can go wrong between a voter’s choices and the reported result. When we had the chance to take a concrete step toward more trustworthy remote voting, we took it and built VoteSecure. Our release post tells the story of that work.
VoteSecure tackles one part of the larger problem: protecting and checking the path a ballot follows through a remote voting system. We built it as a component that a voting-technology vendor can place inside a larger product. People sometimes discuss VoteSecure as though it were the whole product, so we want to explain where it fits.
The engine and the car
To understand what VoteSecure contributes, we should first establish where it sits within a complete remote voting system, the kind a jurisdiction might eventually use for a high-stakes election. Think of VoteSecure as the engine of a car.
The protocol is the blueprint for the engine. It is the published set of cryptographic rules that describes how ballots are protected and checked. The software development kit, or SDK, is one working engine built from that blueprint: open-source software that implements those rules. We have released initial versions of both for voting-technology vendors to evaluate and build around.
The car
The vendor still has to build the car. A complete voting system needs an app for voters, tools for election officials, identity checks, servers, storage, user interfaces, operating procedures, and support. Different jurisdictions will make different choices about these parts. VoteSecure gives them a common engine whose behavior is published and can be checked. Vendors do not each have to invent this sensitive machinery from scratch, and outside experts can study the same foundation wherever it is used.
Here, “VoteSecure” refers to the protocol and the SDK. We built the engine from established, well-studied cryptographic techniques and published both its design and its implementation for others to inspect, test, and improve.
What changes when the engine is inside
When a voting app says, “Your ballot was submitted,” the voter would normally have to take that statement on trust. VoteSecure gives the voter and others ways to check what happened, making the path from a voter’s choices to the final set of ballots checkable. Cryptographers call this end-to-end verifiability.
A voter makes choices in an app supplied by the system vendor. Before casting the ballot, the voter can use a separate device to check that the encrypted ballot contains those choices. After casting it, the voter receives a tracking code and can later confirm that the same encrypted ballot appears in the election’s public record. At the end of the election, the system publishes evidence that the recorded ballots were processed without any being added, removed, or changed. These are three fundamental properties that the election-security research community agrees any voting system should guarantee. Existing voting methods, including supervised and early voting, do not necessarily make all three independently verifiable:
Cast as intended. Before casting a ballot, a voter can use a second device to check the actual encrypted ballot. The second device gives the voter an independent view instead of asking the voting device to check its own work. If the choices do not match, the voter does not cast that ballot and follows the system’s process for retrying the check or reporting the problem.
Recorded as cast. The voter receives a tracking code and can use it to confirm that the public record contains the same encrypted ballot they submitted.
Counted as recorded. The system publishes mathematical evidence showing that every eligible ballot passed through the mixing and decryption process, without any ballot being silently added, removed, or changed. VoteSecure then hands the verified, anonymous ballot records to the surrounding system for printing or tabulation. The rules for calculating the election result and the tabulator that applies them are parts of that larger system. This sequence follows the election lifecycle and requirements around which VoteSecure was developed with election officials.
Together, these checks are designed to provide what election-security researchers call software independence. When the surrounding system implements VoteSecure correctly and voters and auditors perform the required checks, a bug or malicious change to the software cannot silently change the ballot record. Under those conditions, the evidence can expose ballot box tampering whether it began outside or inside the election office.
Note that the voter-facing checks are voluntary, and their protection depends on voters performing them. VoteSecure supplies the mechanism. A complete system must make the checks easy to understand and use.
Public evidence, private votes
Public evidence must preserve ballot secrecy. A VoteSecure tracking code refers to an encrypted ballot, not to a readable vote. Before the ballots are decrypted, the trustees verifiably shuffle them to break the public link between each encrypted ballot and the anonymous ballot that emerges. They then use separate key shares to decrypt the shuffled ballots, so no single trustee can decrypt ballots alone. The process also produces public evidence that the shuffle and decryption were performed correctly.
The evidence can therefore be published for independent checking without revealing which voter cast which ballot. Election officials, political parties, researchers, and others can build or use independent tools to perform these checks without needing permission from Free & Fair, a vendor, or the election operator.
Building the complete system
VoteSecure supplies one security-critical layer: publicly checkable evidence about whether ballots were prepared as intended, recorded as cast, and counted as recorded, subject to its stated assumptions and the required checks.
Turning that engine into a deployable voting system remains substantial product-engineering and election-administration work.
Among other things, a complete system must provide:
Applications and endpoints. Build, distribute, and update the voter and checker applications; preserve the checker’s independence; protect credentials and personal information; and plan for compromised devices beyond the assurances that VoteSecure provides.
Identity and privacy. Authenticate eligible voters while preserving the separation between voter identity and the anonymous ballot that is ultimately tabulated.
Reliable operations. Operate and monitor the servers and public record, protect availability, respond to incidents, recover safely from failures, and provide appropriate fallback channels.
Election procedures. Make ballot checking usable and accessible; define how failed checks are reported and investigated; establish remedies; and correctly tabulate the anonymous ballots VoteSecure produces.
Independent assurance. A complete system must be tested at realistic scale, subjected to independent security and usability review, corrected when vulnerabilities are found, and taken through whatever certification or conformance process applies.
Building a complete voting system around VoteSecure remains substantial work, but that work is concrete: a vendor can build to published requirements, independent reviewers can test the complete system, and a jurisdiction can decide whether the resulting evidence is strong enough for a particular use. VoteSecure aims to provide a common, open, and inspectable starting point for that work.
Where things are today
We have released initial versions of the VoteSecure protocol and SDK. The SDK includes automated integration tests of its internet-facing protocol actors and trustee workflows. We have also published the specifications and threat model that state what VoteSecure assumes, what it protects, and what remains outside its scope.
Independent researchers identified three issues in the initial releases. They were corrected in versions 1.1 and 1.1.1 through a minor protocol change and additional implementation and procedural checks, with advisories and updated documentation published alongside the fixes. No version of VoteSecure has been used in a public election. Finding and correcting issues before deployment is the purpose of developing the work in the open, and that review should continue.
What comes next
Remote voting is already being used, and additional systems will likely be built. If more systems are built, their security-critical cores should not be closed machinery or cryptography reinvented by each vendor. That is why we developed VoteSecure now: to give vendors an open, inspectable engine for one security-critical part of a remote voting system.
Vendors can begin evaluating VoteSecure and prototyping integrations now. The security protocols underlying the internet became dependable through implementation, public analysis, and revision; VoteSecure should be developed in the same way. The next steps we see are to measure its performance at realistic election sizes, strengthen the formal analysis and assurance evidence, support independent review, build reference applications that voters and election officials can try, and develop a path toward testing and certification of complete systems.
VoteSecure’s next stage should involve a broader community of implementers, reviewers, election officials, and institutions. Any confidence in VoteSecure should rest on sustained examination, testing, criticism, correction, and continued review. If you are interested in helping build, evaluate, or improve it, please get in touch. General questions and proposed improvements belong in the VoteSecure repository. Suspected security vulnerabilities should follow our responsible-disclosure process.