1. Evoting using collaborative clustering Justin Gray Osama Khaleel Joey LaConte Frank Watson

2. Overview Assumptions / Introduction Detailed layout of the system Security

3. Assumptions The computer has a static IP address and is powered “on” all the time. The user has administrative privileges to the computer. The IT department has one unused server also with a static IP address.

4. What we’re planning to do We’re going to make all the faculty machines part of an overlay network. The machines communicate with each other and randomly select (3-4 computers) to act as counters. When someone casts a vote, the encrypted data is sent counters and tallied. We’ll use PKI to securely communicate the between the different counters. When the election is over the counters broadcast the information to the other machines in the network.

5. What inspired this design Byzantine fault tolerance – this idea is used in failsafe systems (such as aircraft) where there is redundancy to make sure the decision is correct. We have three or four hidden and random counters which are sent data. If one of them miscounts or is compromised, the other counters in the cluster will help validate the vote.

6. Adding to the Voting Cluster 1. System admin adds the user’s credentials to the server. 2. Software is installed in the faculty’s member’s computer and the computer sends the server its public key. 3. The server replies back with a signed certificate using the client’s public key. 4. A signed message is sent to all the computers in the network a new computer is added to the cluster and updates them with new computer’s certificate.

7. Adding a machine to the cluster (cont.) The system will have a server that will be responsible for adding other machines to the voting cluster, plus providing CA services. The server will be pre-configured with a list of legitimate IP addresses that can join the cluster. Once the service starts on the client side, it sends a request (including IP, machine name, MAC, …) to the server to add itself. The server checks the IP (or maybe the MAC) against the allowed list, and records other information.

8. Certificates distribution The next step the client should do is to generate a public/private key pair. We provide the server’s public key integrated (hard-coded) in the client software. So, the client will use the server’s PK to encrypt his/her PK, and then send it to the server. The server decrypts it using its private key, generates a certificate, and broadcast it to all joined machines so each machine can sign a ballot and authenticate other machines.

9. Voting Process 1.Ballot Creation Distribute Ballot Randomly select counters 2.User Votes Submit completed vote to counters Generate receipt

10. Voting Process 3.Counting Votes 4.Recount Votes May occurs if discrepancy Collect printed receipts Heartbeat / NTP Tally results

11. Security PKI –This evoting system makes heavy use of PKI, inasmuch as every member of the cluster has their own private key, they also have the public key for every other member of the cluster. This allows all the nodes to communicate with each other securely. –By securely, we mean that every voter is able to know that the message they received came from whom it was supposed to come from, and they can rest assured that only they were able to read the message destined for them.

12. Security Encryption –Encryption is used primarily at two levels in this system Message level –All messages are signed and encrypted. This includes messages related to joining the cluster, and messages related to voting. Log level –All votes are stored in an encrypted form in a file that can be retrieved in case of catastrophic failure. Votes are kept in a hash form to ensure that the voter who casts a vote remains anonymous.

13. Security Distributed Voting –The distributed nature of this system has its own security benefits. Vote tampering –Since the vote counters are chosen at random from within the cluster, it would be difficult to find and attack a vote counter.