The Economist Case Study: Blockchain-based Digital Voting System. Team UALR. Connor Young, Yanyan Li, and Hector Fernandez

Transcription

1 The Economist Case Study: Blockchain-based Digital Voting System Team UALR Connor Young, Yanyan Li, and Hector Fernandez University of Arkansas at Little Rock

2 Introduction Digital voting has been around for several years now, but it is still slowly being adopted by election bodies around the world. (1) In spite of technology that protects the confidentiality, integrity, and privacy of our data, digital voting systems still raise concerns of election fraud or data leaks. (2) (3) Blockchain, the distributed database technology behind Bitcoin, seems like a good fit for digital voting systems, providing a way to keep transactions private, and mechanisms to prevent data alteration. But blockchain alone is not enough to address other concerns that come up during elections: how to make sure that the person voting has the right to do so while keeping her identity disconnected from her vote, how to guarantee that the voter can exercise her right to vote without external influences, and how to reassure people concerned with the results of the election that the votes have not been tampered with. The option to handle other requirements, such as allowing for null or undecided votes, or keeping the tally of votes secret until the end of the election should also be available. We cover these concerns in the following pages, presenting what we believe are suitable solutions for each one. Additionally, it is our opinion that using the methods suggested can work with or without blockchain as the storage method. Analysis Blockchain, as implemented in Bitcoin, makes it computationally hard to alter a transaction within its transaction history, providing integrity. Likewise, the distributed mining process of blockchain means that integrity is preserved without relying on trust. (4) Those two properties of blockchain make it suitable to hold the record of votes and protect its integrity. And although the

3 anonymity offered by Bitcoin is considered strong, it may not be strong enough to preserve the anonymity of the voters. (5) If we were to assign each candidate an address to be used within a blockchain system, one could still analyze the transactions to determine the distribution of the votes, which could in turn lead to which candidate each address belongs to. This would not be ideal in a country which prohibits interim results. It is clear then that more mechanisms than the ones provided by blockchain are needed for secure and reliable voting. For this particular case study sponsored by The Economist, the following issues need to be addressed: privacy of the voters and the ability to check their votes, voting under duress, preventing leaks of interim results, undecided voters, and measures to satisfy inquiries about the voting after the election is over. We cover each one separately in the next sections. Privacy and the Ability to Check Votes While a significant portion of citizens have no problem telling the world that they have voted, not everybody has the same opinion about revealing for whom or for what they voted, both as a matter of privacy and as a matter of personal safety. Privacy in the context of an electronic voting system includes not only keeping the casted vote unrelated to the voter, but also not revealing any personal information about the voter in the greater context of cyber security. We believe this calls for two subsystems: a verification system and a voting system. With the verification system, we can verify that a given address has provided the necessary information to vote (such as ID, SSN, etc.), and that the identification has not been used previously (a single vote per ballot per person). The verification system can then provide a single vote (or some established value of BTC, depending on the implementation). This vote will contain a signature of the verification system, allowing the voting system to recognize it as authorized.

4 From there, the voting system (which keeps track of all transactions for each ballot) will evaluate and hold on to the transactions until the end of the voting period, at which point it will complete all transactions (the details of why transactions are not immediately completed will be mentioned later). This is similar to how miners in the standard Bitcoin blockchain system work. We recommend that unless a well-established system is used in implementation (such as Bitcoin), a proof of stake concept is implemented to verify the blockchain. For the proof of stake concept, we recommend that the stake be an additional specialized s-vote which is received at the same time as the actual vote. This s-vote is not spent, rather it is used to determine a particular user s stake in the event that they choose to aid in verifying the public ledger. Essentially, this means that the more a user participates in voting (using a valid form of identification) the more stake they have in upholding the system. In our opinion, this allows for the users to submit verification of their identity and vote even through a smartphone, provided they can log in to their account on the system. Because the transactions can be held by anybody, they can be recounted and verified at will by the public after the election period has ended. Voting Under Duress Whether there is pressure from employers, coworkers, or family members to vote a certain way, or direct threats from political parties against those who vote for a different candidate, it is the voter s right to vote for the candidate or option of her choosing. For this purpose, we offer two potential solutions, which could also be implemented together. First, we recommend the ability to return to the system after voting and issue an invalidate command from an account. This command would be sent to the voting system and would call for a vote from an ongoing ballot

5 to be ignored. Keep in mind that this only applies to a single vote coming from the same address and signed with the same private key (ensuring that no external sources can forge the invalidate call without access to that particular account s private key). We considered a revote call which would allow for a user to change their vote, but on reflection that could encourage voting under duress (allowing a third-party to physically force a vote change on a person). The second recommendation is a silent-alarm passcode. This is based on a concept commonly used in businesses which require keypad entry, in which the user would assign a second password in addition to their first which tells the system that the user is currently under duress. The system could even appear to function normally at this point (verifying and voting), but also attaching a null flag (telling the voting system to ignore it upon count) or an invalidate message (as previously described). The system could even include an option to alert authorities, if so desired. Availability of Interim Results It has been suggested that the existing Bitcoin blockchain could be used for digital voting due to the anonymity provided in the transactions. (6) However, the Bitcoin blockchain would not keep interim results secret until the end of the election. What we recommend for these purposes is that a separate public-private keypair is used for each ballot. A user s device would first encrypt the address of the candidate voted for with the user s account s private key (effectively scrambling it). It would then encrypt the now encrypted address with the particular ballot s public key (ensuring it cannot be viewed until the private key is released). Finally, the entire transaction would be encrypted with the account s private key (as normal, to ensure a secure transmission to the voting system). The question becomes who would hold the ballot private key

6 until the election period has ended. While this key is secret, nobody can view which candidate has received votes; they can only view which addresses have sent votes. As such, it is important that the key stay secret and be held in a way that prevents its misuse. In the event that no trustworthy third party can be determined, our recommendation is that the key be split among the candidates. In this way, each candidate only has a portion of the key, rendering it useless until combined. At the end of the election period, each candidate must give up their portion of the key, which would then be released to the public so that they may verify the election results. Undecided voters We recognize that in some elections it may be harder to choose one candidate over another of equal talent or lack thereof and that some voters use their undecided ballots as a means to protest the lack of suitable candidates. To accommodate those voters who are undecided or unable to finish the voting process, we suggest that each vote also contain a signature of the particular ballot it was verified for. This is a property that is already existent in the system we have described. After verifying with the verification system that your identification is legitimate and currently unused for the particular ballot being requested, the vote transaction would also include a combined signature of the verification system, the vote s ID, and the ballot it is associated with. If this vote were used in a later election, it would contain an improper signature for that ballot. If one wanted to calculate the number of undecided votes, all they would have to do is calculate the number of people who registered and subtract the number of votes received, as any unreceived votes would be considered as undecided.

7 Voting Aftermath With a combination of an encrypted blockchain and a secret key that is used at the end of the election, both the integrity of the transaction chain is preserved, and the secrecy of the results until the end. Furthermore, those two mechanisms would address the concerns of people who would question the integrity of the election once the results are in. The blockchain would make it computationally impractical to alter votes once casted. Even transactions that would void any votes would not alter the original vote, but would generate a call to ignore the original vote. And by using the ballot private key to decrypt the totals at the end, there would be no practical way to know any results mid-election. Approach We opted for a simple solution that uses blockchain to store the results of the election. Although simple, each concern is addressed by the properties of the system. This system is well-suited to be used as a cellphone app, but is applicable for any computational device.

8 Figure 1. Sample Overview of Digital Voting System The system we propose consists of a Voter Registration Server, which validates the user who wants to vote, a Voting Server, which processes the ballots casted, and the User App. This system, demonstrated in Figure 1, is designed with blockchain compliance in mind. The Voting Server is the distributed system that allows the public to view all transactions (by downloading and being a part of the system), whereas the Voter Registration Server is some form of verification server (distributed or otherwise) held by the organizer of the election and meant to verify each voter s identity. The Voter Application is the device which the user uses to vote. The Voter Registration Server does not record user addresses to be used by the Voting Server, and the Voting Server does not have access to the Voter Registration Server. Each member of the system (the Voting servers, the Voter Registration server, and the Voter Application) will contain a public-private keypair for use in securing messages mid-transmission and verifying the

9 origin of the messages. Voter verification is generated via the organizers roster of registered voters. Vote organizers generate a unique keypair for each proposition or position being voted on, and the public key is shared with each registered voter after they ask for a particular ballot. Voter gets one vote per position or proposition being elected, and a signature from the verification system and ballot (used to determine a valid vote for a particular ballot). When a user votes, the transaction is transmitted securely to the voting serve. The vote transaction includes the ID of the candidate or Yes/No value for the proposition concatenated to a timestamp, encrypted with the public key associated with the position/proposition, the hash of which is returned to the voter. After the election period has ended, the voting system uses the private key of the position/proposition to decrypt the vote and adds it to a tally. This private key is the split key that has been distributed to the candidates/keyholders. The candidates would come together at the end of the election and hand over their part of the key, guaranteeing that the final results would not be known until the end. Should the vote be casted under duress, the user has the option after the fact to invalidate her vote using the hash of her vote. References (1) (2) (3)

10 (4) Nakamoto, S. Bitcoin: a peer-to-peer electronic cash system (5) Ober, M., Katzenbeisser, S., Hamacher, K. Structure and anonymity of the bitcoin transaction graph (6)