E-Voting has many potential implementations. This is an example of the central server approach to Internet based E-Voting.
There are many potential implementations of E-Voting. For instance, e-voting might be as easily accomplished by using a ballot counting machine in your local polling place. E-Voting by way of the Internet is usually the most desired implementation.
As described in our E-Voting Requirements, which are similar to Traditional Voting Requirements though more in-depth, there are certain guidelines that modern Internet based E-Voting systems should follow. These guidelines are optimistic in theory but potentially unfeasable in practice. The implementation of E-Voting described here meets most of the criteria, and the unmet criteria will be duly noted.
A popular implementation of Internet based E-Voting relies on the concept of a central server. This central server is responsible for storing ballots before and after they are completed, verifying voter identities and aiding in vote counting. In addition to the central server, there are also many collection servers. Collection servers will collect ballots and allow for verification of votes. Finally, there is the client that the voter uses to obtain the ballot, vote, and disperse the results of that action.
This list describes step-by-step the procedure this central server based implementation will follow. The flowchart helps to visualize the steps over time.
If a voter would like to verify their vote has properly been recorded, they can query the collection servers for the already known client hash. If it is found, the ballot that accompanies it can be hashed with the already known client secret key. If the found hash matches with the just calculated hash, the vote has been properly recorded on that collection server, and the process must then be repeated on many up to some threshold.
The votes on the central server can be audited by comparing the hash of the server secret key and the ballot to the central server hash, and also comparing that central server hash to many collection servers in a similar way as a voter would verify their vote.
This approach is relatively obvious. A central server allows for a source of truth to exist for votes cast, but sources of variability to exist for confirming the votes were cast in a particular way. This might be a first pass at an online based system, but as one considers the system and its qualities, there are definitely criticisms of this approach (in no particular order).
What are the criticisms of this approach? The rabbit hole is deep.
Since votes are recorded and counted by the central system, it needs to be infallible &mbash; no intent or idenity leaking may be possible, though is counterbalanced by the collection servers also hosting the same vote information.
The voter obtains a ballot with a serial number that the central server keeps until the ballot is returned later. If that serial number is not decoupled at that point, the central server knows the direct identity of the voter.
Local elections are generally smaller affairs than larger regional or national votes. In this kind of situation, running numerous collection servers will be difficult despite being an integral part of the plan. Larger elections might fare well in this system, but local votes will suffer.
The client must be safe and secure, because if it is not, all of the cryptographic hashing will not maintain the integrity of the voters’ intent.
Let's begin with an example. People might have an average Windows 10 laptop with the latest security updates from Microsoft, running the latest version of Norton Antivirus and using an updated version of Chrome. Sounds like the perfect life, right?
Then a person tries to go to a hypothetical "vote.gov" and proceeds to vote. With 91% detection rate, and more than 60 million Windows 10 installations, there might be 5,400,000 compromised computers. When the voter hits the submit button but before the client submits the ballot to the server, the rogue virus eV0T3 changes the vote — and suddenly the wrong vote is submitted, and less the person checks, they are nonethewiser.
How do we secure the client? So the browser needs to be secure – it cannot leak voter information (like identity or the ballot choices). That means HTTPS, right? Well, HTTPS is good but not the end-all-solution. Just because you expect it and maybe even see does not mean it actually is working as you expect.
Assuming the browser and connection are secure, what about the host OS? What stops a rogue virus, trojan or other malware from changing votes or viewing the ballot? There is just not that much! How is it possible to prevent a program from screen recording and capturing that information? How is it possible to prevent a strange but possible program from only allowing check marks next to Independent candidates' names? It is not possible.
If that is the case, a clean operating system is required. A phone running iOS might be okay, right? To use Internet based E-Voting, we need to use a closed source operating system and an expensive device. That probably will not fly.
Protecting the client is just not easy. It's downright impossible. There are too many configurations of standard hardware and software, and a mind boggling insane amount of malicious software combinations as well.
The voter has a token which can verify they voted in a specific way, which means coercion is a potential problem that could arise. If a person was forced to reveal the client secret key, they have effectively revealed which ballot they cast.
The collection servers must be operated by many individuals and organizations so that the bias of one collection server entity cannot invalidate any single vote.
In October 2015, Apple sold 13 million new iPhones 6S units over its opening weekend. Between preorders and in store sales, the backend system that Apple uses to handle the sales had to accommodate 13 million sales in just 72 hours. In years past, Apple has struggled to maintain the uptime and reliability of its servers during such opening weekends, causing significant frustration and perhaps lost sales. In 2008's presidental election, more than 128 million people voted, the majority of which voted within just a few hours. There were 10 times more voters than iPhone buyers, and even then, the Apple servers struggled to accommodate their much smaller volume. The scale is tough, even for the wealthiest company in the world, and likely, it will be difficult for the government that built a broken health insurance portal. Nothing is easy.
In our list of E-Voting Requirements, a system should have most if not all of these aspects satisfied. Some details of the implementation are undefined here, so those requirements are marked as satisfied. Which requirements are not met? Here's a brief list:
There are likely other objections to this approach that would cause significant difficulty in its real world application.
If you like video, Computerphile made a great video on some of the problems of e-voting. Check it out.
A less obvious solution to Internet based E-Voting is an implementation similar to that of BitCoin. An overview of BitCongress is addressed in a whitepaper. BitCongress can be summarized as a peer-to-peer online e-voting system that avoids a central server which uses hash-based proof of work and proof of tally systems to make records that cannot be changed easily. This system is substantially more complex than the one addressed above, however, it offers advantages that system above simply is incapable of offering.
Internet based E-Voting is a complex issue that will be discussed for many more years to come. At present, it would be easy to argue that traditional voting methods are better implementations simply because they adhere to the voting requirements better, not to mention their greatly reduced cost.
Despite all of the problems of basic centralized e-voting implementations here, there are some great implementations out there in the world already. Check out Current E-Voting for more.