Secure Application Ideas

These are some ideas that have been kicking around in my head for a while. Take them as they are, I don’t claim they are fully baked and ready for the wild. They do represent some of my core objectives. Create systems that offer security to the user, along with instilling a sense of trust and safety for people impacted by the systems.

A case for election systems secured by blockchain

The security of the voting system is critical to a democratic society. All current voting systems are subject to errors and minulipution. With counting errors of up to 3%, misconfigured servers and outright hacking and changing vote totals. We need a voting system that is easy for all eligible citizens to use, secure from attacks, and counts all ballots accurality. I’m personally a fan of companies designing different systems and allowing the market to decide what is the best. Maybe it’s time for the government to step in, put out exact specifications for voting systems and their configuration. Let the market build them, then turn red teams lose on them to find any security holes then fix them. STIGS should also be routinely published to keep these machines safe.

This paper is intended for the non-technical reader. If you are not familiar with blockchain technology, please read “Blockchain a Primer” that I wrote to give you the baseline knowledge you will need to understand some of the security aspects I’m presenting.

System Requirements:

  • Voting machines must be easy to use, such that any person who is eligible to vote can walk up and cast their votes with little or no assistance. Usability needs to be addressed by an expert in User Interface Design.
  • A ballot that is cast must be recorded accurately on the voting machine.
  • Once a ballot is cast, it can not be changed.
  • All ballots must be counted accurately.
  • All ballots that have been cast must make it all the way through the system, untampered with.
  • A ballot must spend as little time as possible in the system, prior to being published. The longer the ballot is in the system, the longer a bad actor has to decrypt and attack a ballot or series of ballots. For this reason, there is a need to optimize throughput without compromising security. Minimizing the time a ballot spends in the system, will also increase public confidence in the results the system produces.
  • The certifying node must be outside of the system, it can not see into the system because the decryption keys are held by the certifying node. Ballot information can not be read until it has made it all the way through the system and the encrypted blockchain has been published.
  • The system must use wired connections. Sorry guys, wireless is a great convenience; however, it is too insecure to be used. SOP for secure systems is to use a wired connection. Using a wired connection for all nodes is the system will reduce the attack surface.

Public confidence:

Most elections systems are decentralized, that leads to difficulty to change the outcome of an election. However, there is a problem with a decentralized election system. The attack surface is large with differing levels of security. This makes for a target rich environment. I can drive up to a polling station, hack into the wifi that the voting machines are using, or have an election management system connected to the internet with remote access software installed, I may not be able to change the outcome of an election, but I can cast doubt on the validity of the election. This leads to people believing their elected officials don’t represent them, and reduces the sense of safety and security of the population.

The key objective of a voting system is for the public to have confidence in the results of the election. The system I’m describing will make available to the public an encrypted blockchain along with the unencrypted results of the ballots as they pass through this the system. When voting is closed the key to decrypt the blockchain will be released to the public to verify the  publicised ballots, against the encrypted blockchain.

Description:  This system will consist of four different machine types, voting machines that  citizens used to cast their ballots. Endorsing nodes that will place the encrypted ballots on the blockchain.  A publishing node that will published the encrypted blockchain to the public in real time. And a certifying node that will decrypt the blockchain and publish the unencrypted results in real time.

Once voting is closed and all voting machines have reported ballots all the way up to the publishing node and the certifying node finishes decrypting and publishing the ballots, the certifying node will release the decryption key to the public for the public to verify the results of the election.

Voting Machines (VM):  

Voting machines are built to record and transmit encrypted ballots accurately and securely.  On set up, the voting machine has a certificate loaded on it to register the voting machine on the endorsing node private network. After the voting machine has been placed into the endorsing nodes network, the voting machine will download the certifying nodes public key that will be used to encrypt the ballots. By encrypting the ballots on the voting machine, we protect them from being altered while they are being processed through the system.

When a citizen cast their ballots, the voting machine records the timestamp of the vote in the header. In addition because it is conceivable that two ballots are cast at the same time and have the same votes, grab the CPU serial number and save that in the header of the ballot. The combination of timestamps and CPU serial number will ensure a unique combination. In addition having the CPU serial number will help in any investigation where there may be questions about ballots that were cast.

The polling place is also populated in the header. We can assume that votes cast in a polling place will have a similar distribution of vote results across all machines. A bad actor can use a voting machine that had been to cast multiple ballots for the results he/she is interested in, using the vote of the people that did not show up to vote. This would show, a voting machine, significantly deviating from the vote distribution of the other machines at the polling place.

Once  we have these header elements, a hash is taken of the ballot and recorded in the header. A unique hash of the ballot is required to prevent a replay attack where a ballot is sent to an endorsing node more than once. Once the header is populated, the ballot is encrypted using the Certifying nodes public key. The encrypted ballot is saved to local storage, then transmitted to an endorsing node.

Saving the encrypted ballot on the local drive will allow validation of ballots that were cast in the event of an audit. Encrypting the ballot on the Voting Machine also ensures the security of the ballot, between the time the ballot is submitted to the Voting Machine, to the time it is decrypted and published by the certifying node.

In the event of network connectivity issues, the ballot is placed into a queue on the voting machine, then sent to an endorsing node when network connectivity is reestablished.

After voting is closed for the polling place. The voting machine will send a last record to the blockchain, containing Polling Place, CPU Serial Number, Timestamp, and number of ballots cast.  

Endorsing nodes (EN):

The purpose of the Endorsing Node is to accept ballots from the voting machines and place them onto the blockchain.

There exists 1..N endorsing nodes that accept the ballots from voting machines and place the ballots onto the blockchain. The EN places 1 .. n ballots into a block to be sent to the blockchain. In the header of the block is placed, timestamp, machine name, CPU Serial Number, number of ballots being sent, prior hash, and current hash.

The EN gets the prior hash value from the publishing node and calculates a current hash that meets the required difficulty. Once the EN has the hash, it sends the block to the blockchain to be published. If the publishing node accepts the block, the EN will start working on placing the next block onto the blockchain. If the publishing node does not accept the block because another EN beat the EN, the publishing node will send to to the EN the last hash and the EN will work a new hash value for the block then send to the publishing node. This process is repeated until the publishing node accepts the block and all ballots have been placed on the blockchain.

In the event more ballots arrive on the EN, and the block is rejected by the publishing node, the additional ballots can be added to the block for the next try. My test have shown that time to hash and memory usage increases slowly and linearly as the size of the block increases. When memory starts to swap out to temp space, the time to hash increases exponentially. Therefore, we have the option of adding ballots to the block, up until before we experience a performance degradation. Test will need to be performed on the EM to determine the max size of a block we can efficiently hash.

The method of placing a block onto the blockchain is modified. Because the blockchain will grow rapidly, it would be difficult to keep a full copy of the blockchain on every EN and use the rules of consensus about the longest blockchain being the valid one. This would cause many of the endorsing nodes to fall behind, as they would have to replicate the new blocks prior to working on the next set of blocks. Instead we are going to use first block to arrive at the Publishing Node to build the blockchain. If a EN does start to fall behind, then the difficulty factor of performing the hash can be adjusted down to speed up getting blocks onto the blockchain for the slower EN. Prior to adjusting a EN’s difficulty factor a log entry will be required on the blockchain noting the adjustment for that EN.

Once the endorsing nodes receive the final vote report from a voting machine, it will be removed from the whitelist and can not send any more data into the system.

Publishing Node (PN): The purpose of the publishing node is to publish an encrypted version of the blockchain to the public and the Certifying Node. The PN accepts a block from EN’s and places them onto the blockchain. When a block comes in, the PN checks to see if the prior hash in the submitted block matches the last current hash on the blockchain and the difficulty factor of the submitted block meets the requirements. If these conditions are true then the PN places the block on the blockchain, and sends a success signal to the EN. If the prior hash of the submitted block does not match the current hash of the last block, then the PN sends the current hash of the last block back to the EN, for the EN to try again.

Because we can uniquely identify each ballot by Polling Place, CPU Serial Number, Timestamp, and hash that is in the header, we are going to allow ballots to be placed on the blockchain multiple times because this is easily detectable. I can not come up with a good reason this would ever happen, the only thing I can think up is a bad actor doing a replay attack. Now, using a rejection algorithm based on a duplicate hash between two ballots, might not fly with the general public. The reason for this is the many people in the general public do not have an understanding of cryptography, hashes and hash collisions. If it is published that ballots will be rejected automatically because of a duplicate hash, the full public might not have confidence that every vote was counted. However, by allowing a ballot to get on the blockchain more than once, we can reject the duplicate ballot publically and as my papa usto say, “Someone has some explaining to do.” And by exposing the fraud with the concrete evidence  from the published encrypted blockchain and the decrypted results, then that increases confidence the government is serious about all ballots being counted accurately.

Certifying Node (CN): The purpose of the Certifying Node is to hold the encryption and decryption keys for the system, publish the decrypted ballots, when polling has closed, all voting machines have reported their final summaries and those summaries have been placed on the blockchain, the certifying node releases the decryption key to the public.

By placing both the encrypted blockchain and decrypted results to the public realm in realtime, the public can see the ballots have been secured, and by placing them into a blockchain, it increases the sense of security, because if any attempt is made to modify ballots the blockchain becomes invalid and is easily detectable.