A3C EVOTING A nonymous C ounters & C ollaborative C lustering E-Voting

1. A3CEVOTINGAnonymous Counters & Collaborative Clustering E-Voting Justin Gray Osama Khaleel Joey LaConte Frank Watson

2. Agenda • Introduction / Overview. • A3C system init. • Ballot Generation Computer (BGC) init. • Counters init. • Voting process. • Conclude voting. • Publish results.

3. overview • Why A3C ? • The original idea is inspired from the Byzantine Generals' Problem. • A cluster can be formed dynamically on the fly. • Counters are selected randomly (anonymously). • The main idea: • Building an overlay network of the EAS faculty member’s computers. • selecting 3-4 counters randomly. • Using PKI to secure the system. • Publishing final results by all counters.

4. A3C system init: • Usually, this will be done only once to initialize the system and build the Public Key Infrastructure (PKI). • A server will be dedicated to act as a CA. • Assuming clients have static IPs, a pre-configured list of allowed IP / PW pairs will be set on the server. • Passwords are delivered offline. (prevents IP spoofing) • A list of the same allowed IPs is available with the software (XML file). • The server’s public key is embedded in the client program.

5. A3C system init: (cont.) • When the Java client program starts, a public/private key pair is generated. • The public key and the password are encrypted using the Server’s Pub Key, and sent to the server. • The server checks the IP and the PW against the list, If OK, generates a digital certificate (DC), sends it to the requesting entity, and broadcasts it to all other IPs. • A client is able to request issued DCs.

6. BGC init. • When a faculty member wants to start a ballot, it becomes the Ballot Generation Computer (BGC). • The BGC will: • Create and sign a ballot, and select who can vote. • Select 4 random IPs to be the counters. • Generate a list of onetime-use IDs, and send it along with the selected voters to the counters. • Send the signed ballot to the selected voters.

7. Counters init. • Once a computer receives a message says “you are a counter”, it: • waits to get the onetime-use IDs generated by the BGC. • Generates a temp pub/prv key pair, and sends the temp public key associated with a temp ID to each voter. • This is done so that, • Counters are kept anonymous. • Only counters can decrypt and record votes. (each uses its own private key). • Voters can’t vote twice with this temp ID. • Generates a temp symmetric key. This key will be used for: • Encrypting the onetime-use IDs. • Encrypting the submitted votes (locally).

8. Voting process • Voters receive the signed ballot. • In our case, a JTable shows up lets the voter select some choice and VOTE. • The vote choice + the onetime-use ID are encrypted using the temp pub key (for each counter) and sent to all members. (4 times!) • The counters (that have the respective temp private keys) are the only ones that can: • Decrypt the vote. • Check that the ID exists, and hasn’t voted yet. • Record the vote in the encrypted local file. (symm. key) • A counter generates a receipt containing a hash of user’s vote/ID, signs it with its temp private key, and sends it to the voter.

9. Conclude voting • We can do this in two ways: • Either, the BGC specifies a voting period, and this period will be sent to the counter, so they can end voting after a certain amount of time. • Or, the BGC will be able to send a special message (i.e. “End Voting”) to the counters to end the process.

10. Publish results • Once the counters receive the “End Voting” message, OR the voting period specified by the BGC expires, they will: • Tally up votes. • Sign the result using their temp private keys. • Broadcast it. • Voters will use the temp public keys to VERIFY and SHOW the result for each counter. • 4 results will be received, so that voters can compare. • Redundancy is our key to make voters assured of correctness.