Clean elections. An anonymous and transparent voting system

Clean elections is a proposal for an electronic voting system built on a Proof of Authority blockchain, where dedicated voting machines act as validators. Citizens identify themselves with their national ID and fingerprint; votes are anonymized (grouped and shuffled before submission), recorded on a public, fully open-source blockchain that anyone can sync and audit, and each voter can privately verify their own vote was counted. The design covers mesh networking between machines, code verification (by peers and via a mobile app), resilient block queuing so no vote is lost, and NFC maintenance cards for upkeep.

Overview

On internet, I’ve only seen essays about how the blockchain could be used for a voting system, but nobody has drafted it yet.

Main concepts of the voting system

The voting system, from now on “system” and physical voting devices, from now on “voting devices” should meet with the following requirements:

1. Allow the citizen to identify themself in a machine with his physical ID. Or by an online platform, but this draft is focused on physical side for now. Every citizen will be assigned an electoral table for security reasons.

2. All machines must create a network of validators, testing among them that the software every one is running is the original. Based on a Proof of Authority blockchain.

3. The system must allow the voter to verify, whether the software a specific machine is running, is the original, through a comparison with the public git repository.

4. All the code must be open source without exception.

5. The citizen should be able to identify his vote into the blockchain and check that his vote has been added successfully.

6. In addition to the selected person or party, the block could contain basic information for instance validator id, election id, electoral table, city/town; or other data for statistics.

7. The system must give to the voter anonymity regarding his vote. Whatever way must give to the voter the option of check his vote in the blockchain, but just him must be able to correlate the block with him.

8. Security measures will be necessary in order to prevent impersonations as fingerprint and access control. Almost all developed countries have fingerprint database of their citizens nowadays.

9. Voting machines will only have a basic firmware, a hardware security module which will save private keys, RAM and non-volatile memory to keep the blockchain and the queue of votes.

10. Specialized group of maintainers, 1 maintainer card per machine. Only the person with that card can enter maintenance mode.

11. A PKI will be used to identify which validator submitted a vote to the blockchain and verify the integrity.

1. Identification

A device with a screen, preferably tactile and with an ID reader. Physical check by police or special group of a public organization as extra security to verify that is not impersonating other person.

2. Network of Validators

All the voting devices would create a full mesh topology, connected among them and verifying in real time every validator is running the original code.

The validators will be connected among them, preferable without an intermediary server, using Nebula¹.

2.1. Blockchain Infrastructure

The blockchain will be a Proof of Authority, the voting machines would be the only authorized to add blocks, and anyone will be able to save a copy of the blockchain, taking part on the synchronization. However, as voting machines will be within a private network they won’t be able to communicate directly with an external network.

How can we resolve it? I propose a proxy, which would be within the network and will be the responsible for replicating the blockchain to public validators, big servers, hosted by government. Furthermore, any one will be able to take part in, synchronize the blockchain with the servers hosted by the government, and in that way, contribute in the transparency of the infrastructure.

2.2. Blockchain nodes & genesis block

Here we should separate the two kind of nodes.

1. On one hand the voting machines, which are the only nodes with write permissions — known as validators.

2. On the other hand, public nodes with read-only permissions only spread the blockchain of the validators

Voting machines will have a private and public key saved securely within a hardware security module. The genesis block will add the public keys of the voting machines (validators), and define the rules of consensus, such as:

• 2/3 of the validators must agree to add new ones within the network.
• 2/3 of the validators cryptographically sign the block header with their private key, to authorize a valid block. Once signature threshold met, block is committed to the chain. If a block is not valid, the validator will be isolated and enter maintenance mode, nobody would be able to vote in it until the issue is figured out.

2.3. Begin a votation

A randomized system would select a different voting machine to start a votation, this will offer the opportunity to locations around the country. The validator will add the election ID and important information about it.

At the moment of starting a new election, each validator will create and upload to the blockchain a new and short-lived public key derived from his main private key. Why?

It’s the way of the voting machines to say, “I participate in the vote of the election with ID:”X” and this is the momentary public key I’m going to sign my blocks from now on for these elections. I sign this block with my master private key, so you can confirm I’m the node I say be”.

At the moment of finishing a election, each voting machine will add a similar block, denying the future use of the short-lived key, saying something like “I’ve finished the vote for the election with ID:”X”, from now on my momentary public key “X” is erased forever and future blocks with that key can’t be accepted. I sign this block with my master private key, so you can confirm I’m the node I say be”.

1. This allow us to mark the end and beginning of elections.

2. That guarantee a reliable system, no one can alternate the result after the voting has finished. 

{#participate-in-election}

To participate in a election the maintenance card will be required with the ID which we want the machine to participate in.

2.4. Blockchain disasters resilience

As said in the point 7.1, the voting machines will add blocks to the Blockchain after a threshold or a span of time is reached. But what happens if a machine die, lost the connection or is distroyed?. Would the votes been lost?

The system must ensure that not a single vote is lost, for that reason I suggest:

• Validators will keep an offline copy of the entire Blockchain in a non volatile memory.
• Validators also will keep a synchronized copy of the queue of blocks waiting for submitting. That means that when someone votes, the voting machine will create the block with all the information. Afterwards, it will be signed by the voting machine and validated by the rest of validators. If the block pass all the requirements, it would be added to a queue. As the blocks are already signed and validated, it doesn’t matter which upload it to the blockchain. The system will detect when a group of blocks have to be submitted.

This structure guarantee not a single block is lost.

3. Code verification

Nodes will verify that each one is running the original version of the software.

How? Here some important points:

1. Nodes can’t do the verification locally. Altered code could forge the data.

2. The code will be only accessible by a local connection. Voting devices won’t have internet access, just with the proxy server.

What I propose is:

• After the code is downloaded we can check it integrity by:
• Hash verification against the original code hosted on a public git repository, deliver by the proxy server.
• Git comparison using git --no-index diff.

3.1. Local verification using a mobile app

An open source application will be developed with camera, WiFi and cellular network permissions.

Moreover, the machines will need NIC (Network Interface Controller) in order to create a hot spot with dynamic authentication.

Flow:

1. The user press the button “Verify with my phone” on the machine screen.

2. The machine generate a random password and create a hot spot which will permit just 1 connection.

3. Display a QR which would have to be scanned with the mobile application.

4. The string will contain the random password, previously generated, encrypted with (symmetric encryption).

5. Using the Open Source application, the user will scan the QR and get the password for the hot spot. But it will be symmetrically encrypted.

6. The user will be asked for a token to decode the encrypted password. It will be the WiFi token displayed in the screen.

7. After inserting the token, the application will be able to get the password and connect to the access point. This ensure that only 1 person, with physical access to the machine can use the verification method.

8. With a local connection opened, the app will do the same process than the validators. After confirmation all is correct, the voting machine will close the connection, switch off the hot spot and regenerate a new WiFi token for future verification.

9. If the validation is not passed and is confirmed by other validators, the voting machine will start the isolation process.

4. Open source

All the code, from the voting machine to the mobile application and infrastructure scheme HAVE TO BE OPEN SOURCE AND PUBLICLY DOCUMENTED. it’s an obligatory requirement, every citizen or stakeholder should be able to check the infrastructure and code used.

Of course, sensitive information – such as server IPs, secret keys and any other data relevant to the security of the network – won’t be released.

5. Vote identification

The citizen will be able to identify what votes of the whole blockchain belongs to him but always preserving the anonymity. For that I’ve thought in three possible ways:

1. The user would receive a paper with the transaction ID and a QR. As this sort of IDs usually are long strings, the QR will redirect to the blockchain explorer directly, without having to write down the long string. { #vote-id}

2. Using the same National ID’s certificates, we could encrypt the transaction id with the citizen public key. The citizen with his private key and any id reader may scan the blockchain and identify those blocks that belong to him. No paper, no qr, no long strings; just open the app, read your id with NFC and voilà!

3. As National IDs contain certificates, the system could encrypt the transaction ID with the citizen’s public key and send it to him through a government portal. He will be the only one capable to decode it.

Sincerely, I don’t really know what the best option is, a combination of options 1 and 2 seems to be the best set up.

6. Block information

In addition to the principal information, what the person have voted, every block should contain:

1. ID of the voting machine that added the block. The same as the one that signed it.

2. ID of the election that is taking part and to wich it belongs.

The following information might be added in the block when the voting machine upload the first block with the temporary keys:

1. City or village where the voting machine is based at that time, though they should be in the same site forever.

2. ID of the electoral table where the voting machine is situated. Each citizen will be assigned an electoral table, as normal.

7. Vote anonymity

As said several times in the previous points, the vote has to be anonymous and untraceable, but the system might have a flaw. If someone vote physically and that vote is instantly uploaded to the blockchain, someone might trace that vote with the person that has just voted.

To prevent that malicious behavior the network should work in the following way:

1. Every voting machine will upload votes in group and in random order. E.g.: groups of 10 and votes mixed in random order. Every time a voting machine reach this number, it will add all the blocks to the public Blockchain. If after a limit of time the minimum hasn’t been reached, the votes available will be uploaded.

2. The ID of the electoral table might be a token, no public, used to create statistics in a public website once the elections are over. { #7.1-anonymity }

3. The city or village of each vote will be in clear text so as to real time information on a public website. Once the elections have finished or after some hours, electoral table information might be shown on the website. For instance, every 4 hours release stats, enabling people to find out which option is winning in their city and electoral table.

8. Security measures

In order to prevent impersonation several securities measures will be added, both classic and modern ones.

1. Electoral tables will identify each voter as normal with a physical access control, letting him know whether he has to vote in that electoral table or he’s already voted. A classic list paper might suit, however, both the voting machine and the blockchain have the final say.

2. At the moment of voting, each citizen will have to insert his National Id into the reader, the machine will identify him and require his fingerprint. The fingerprint and required information of the National Identity Card will be end-to-end encrypted on site and in transit and sent to a police software for verification. Obviously, these keys, IPs and endpoints has not to be public and they could be within the private network.

3. In order to prevent duplication, every voting machine will verify that a person has not already voted. For that we could have two ways:

4. Point 2 of vote identification. If there is no record, the person hasn’t voted yet.

5. Create a private database hosted by government which will save only ID of those people who have voted. It would be only accessible by the private network. The public administration might need to know whether a person voted for different reasons, such as statistics or security requirements. This will fit this requisite.

6. In order to prevent impersonation of a voting machine, a threshold of validators must sign his entry or expulsion. For example, the network must be able to expulse a voting machine if it’s stolen.

[Create image]

9. Firmware & hardware of the voting machines

9.1 Firmware

Voting machines will have a FOSS firmware, which will do:

1. Set up the git repository from where the clean elections software will be downloaded.

2. Save the machine ID. That ID is unique, unmodifiable and is part of the motherboard, like a MAC. It’s the only way to identify a physical machine with the public identificator.

3. Generate a password for “maintenance mode” and save it in the hardware security module.

4. Generate the private and public keys for the validator.

5. Configure and put the validator in the private network. If it’s new, it’s going to be added to the blockchain. If the unique ID is already in the blockchain, the old certificate will be invalidated and the new one added. Both ways need a threshold of validators to accept him

[IMAGE]

9.2 Hardware

Each voting machine will require:

1. A tactile screen.

2. A NFC reader in order to scan the National Identity Card.

3. A fingerprint reader.

4. A NIC in order to be able to connect with the private network of validators, external services and set up the hot spot for local verification using a mobile

5. A hardware security module, e.g.: TPM. To save private keys, maitenance passwords, machine identification, etc.

6. A motherboard with an unique ID, used to identify the machine in the configuration process.

7. On and restart button, not visible to the user.

8. A factory reset button, not visible and used in exceptional uses, such as loss of the maintenance card. The machine ID won’t be changed because it’s part of the motherboard.

9. 8-16 GB of RAM to fast access to queues and blockchain information.

10. 500-1000GB of non-volatile memory, preferebly high speed enterprise NVMe with high DWPD (Drive Writes Per Day).

Optional accessories:

1. eSIM and GPS. Every voting machine might be localized in real time at the moment of participating in a election (6. Block Information). It might avoid location forgery, for instance, saying that a voting machine is into a city and a electoral table when he’s really somewhere else, that way altering the electoral census.

[Representative image]

10. Maintainers

We have talked about security measures before, but what happen if there is any error that require attention over a validator, such as:

• A voting machine doesn’t pass the code verification test and is isolated and disconnected from the network.

• A block from a voting machine hasn’t passed the validations and the machine is isolated and disconnected from the network.

• A voting is selected to start an election and add the first block with all the information required.

• We need to change private keys or configuration into a voting machine.

To address this issue I have though in a system, where every voting machine will have just one NFC card linked to him. How? Very easy.

The firmware of the voting machine will generate an identification token for maintenance mode. That token will be saved into a NFC card which will have to be inserted at that moment.

The firmware will require a valid NFC card to be inserted and it won’t start the configuration process until it’s detected.

But we can’t save the token unencrypted, because if not anyone could copy it. So, the firmware will generate a password and encrypt several blocks of the card symmetrically.

[Image or representation]

The maintenance card will contain:

1. The machine ID in clean-text but in read-only mode. To allow to read the card and identify whose is it.

2. Election id, manually written by maintainer. Allow the voting machine to know what election it’s participating in.

3. Encrypted blocks where keep the identification token, only accessible by the voting machine that inserted it.

[image of the blocks]