A3C EVOTING Anonymous Counters

1
A3C EVOTINGAnonymous 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
  members 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 servers 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 Servers 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 cant 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 hasnt voted yet.
• Record the vote in the encrypted local file.
  (symm. key)
• A counter generates a receipt containing a hash
  of users 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.