Summary

The Condorcet Internet Voting Service is designed to protect the security and privacy of participants. Some important guarantees it offers include the following:

• No e-mail addresses are released to any third party. The e-mail address of the election supervisor is made known to the designated voters.
• The identity of a voter is known only to the election supervisor and the individual voter. The election supervisor knows how many voters cast votes, but has no other information about whether or how a given voter voted.
• E-mail addresses of voters are erased immediately after the election begins.
• The election supervisor can determine whether a voter has voted only with the permission of the voter and only after the election has ended.
• There is considerable protection against people who break into the CIVS server. Some information is stored in cleartext on the server: the names of the choices and the description of the election. However, using only information stored on the server it is not possible to determine who the voters are or how they voted. Even if one guesses who a voter is, for private elections it is not possible to determine whether that individual is a voter or whether or how they voted. For public elections, it is not possible to determine how a voter voted, and it is only possible to know whether a voter voted if one has the authorization key for the election.

The remainder of this document describes why these goals are believed to be met.

Election types

CIVS supports both public and private elections. In private elections the election supervisor specifies the list of voters; in public elections there is no list of voters and anyone receiving the appropriate election URL is able to vote. A private election offers much stronger security and authenticity guarantees. In particular, in public elections the IP address of the voter is used to determine whether that voter has already cast a vote. A malicious voter can easily cast multiple votes, and this is as good as one can reasonably expect an public election to be. For private elections, voters receive a unique key by e-mail that permits them to vote just once. Further attempts to vote will be rejected. Voters can also be reissued voter keys without giving them the ability to vote again.

CIVS sends various information by e-mail. It assumes that e-mail is a secure, reliable medium. If your e-mail is compromised, this would permit the attacker to impersonate you as a voter or as an election supervisor. If e-mail is unreliable, voter keys could be lost in the mail. However, voter keys can be reissued without creating the possibility that a voter gets an extra vote.

Keys

CIVS works by generating several different keys that serve as capabilities. These 64-bit keys are generated using a combination of random noise and secure hashing.

• The server has a private host key k that is a secret input to the nonce generation process. The private host key can be set automatically using random data or defined by the service manager at installation time. Compromising the private host key is not very useful to an attacker (it was in the older CIVS protocol).
• Each election has an election identifier that names the election and is used to find the corresponding storage. Possession of the election identifier enables viewing of the results of the election when they are made available, but little else.
• For each election there is a control key that gives the ability to control the election as supervisor. It is generated as a random nonce. This key is mailed to the supervisor when the election is created, and it is not stored on the server, providing some protection against misuse by intruders.
• For each election there is also an authorization key that gives the ability to authorize voters in an election. The authorization key is also mailed to the supervisor at the beginning of the election. Like the control key, the authorization key is not stored on the server, protecting the anonymity of voters.
• Each voter receives a unique voter key that gives the right to vote on the election. Voter keys are computed using a secure hash of the voter's e-mail address, the authorization key, and the private host key. Voter keys are not stored on the server and cannot be used to determine how a voter voted.

Private election protocol

Election creation

1. The supervisor requests the creation of a new election, providing the election description and a list of voter e-mail addresses. These addresses are (temporarily) stored on the server. If this is undesirable, the voters can be added after the election is started, and their addresses will never be stored in cleartext.
2. The server generates three fresh nonces to use as the election identifier, as the authorization key for this election, and as the control key. All three are sent to the supervisor in e-mail in a URL.
3. The election identifier is stored on the server; the server stores the MD5 hash of the control and authorization keys and then forgets the keys.
4. The supervisor uses the URL in the email to start the election. This proves that that the supervisor presented a real e-mail address.
5. The server hashes the provided authorization key and control key to make sure they match the stored hashes.
6. For each e-mail address, the server performs the steps described below under Adding voters. This results in the creation of a list of valid voter keys, which are mailed to the corresponding e-mail addresses. The server stores the hashes of all of the voter keys.
7. The cleartext voter e-mail addresses and the corresponding voter keys are now forgotten by the server.

Voting

1. The voter sends the server a ballot b that includes the voter key v.
2. The server checks whether the hash of the voter key is in the set of valid hashed keys, and whether a ballot has already been cast using the voter key. It reports an error if appropriate.
3. The server generates a fresh nonce r that serves as the voter receipt.
4. The server records the ballot indexed by the hash of the voter receipt and the private host key: {r, k}_MD5. Thus information on the server doesn't allow the identity of the voter to be determined from the ballot.
5. The server reports the receipt r to the voter and then forgets r. This enables later checking that the ballot was cast properly, but only with the participation of the voter.

Adding a voter

Given an e-mail address e, the server performs the following steps when a voter is added (either during election creation or later from the election control page):

1. A voter can only be added by presenting the authorization key a, which is known by the supervisor but not stored on the server. It is, however, available at election creation time. The server stores {a}_MD5 to allow checking whether the correct authorization key is presented.
2. The server computes v = {e, a, k}_MD5, which is the voter key. Possession of the key does not permit either direct computation of the e-mail address or (in the absence of the authorization key) a dictionary attack to find the e-mail address. The use of the private host key k prevents the supervisor from forging a voter's key.
3. The server looks up {v}_MD5 in the current set of (hashed) voter keys. If it is already there, it reports an error; otherwise, {v}_MD5 is added to the set of voter keys.
4. It sends v to the e-mail address e, so the voter can later use it to vote.
5. The server forgets a, e and v.

Public election protocol

An public election works similarly to a private election. The difference is that every voter has the power to add himself as a voter: the URL generated at election creation time includes the authorization key. The voter's IP address is used instead of the voter's e-mail address as the definition of true identity.

Election creation

The election creation protocol for public elections is the same as for private elections except that voters are not added. The supervisor is provided with a voting URL that includes the election id and the authorization key. The supervisor can then distribute this URL through whatever out-of-band mechanism they deem appropriate.

Voting

1. The voter sends the server a ballot b that includes the voter IP address IP and the authorization key.
2. The server computes x = {IP, a, k}_MD5 as the voter key. (Secure in the sense that it does not permit the voter's identity to be determined.)
3. The server adds the hash of this v to the set of already used voter keys. If it is already in the set, the server reports an error. Note that this check does not defend against malicious voters who vote from multiple IP addresses; such voters are, unfortunately, not uncommon.
4. The server forgets x and IP.
5. The server generates a fresh nonce r to use as the voter receipt.
6. As in private elections, the server records the ballot indexed by the hash of the the receipt and the private host key.
7. The server reports the receipt r to the voter and then forgets r. This enables later checking that the ballot was cast properly, but only with the participation of the voter.

Because the IP address in an public election is hashed using the authorization key, server compromise does not enable the attacker to determine the IP addresses by dictionary attack. Of course, if the attacker has obtained the authorization key for that election (perhaps because the attacker is a voter in the election), a dictionary attack becomes possible.

Data Storage

The following global information is stored on the server.

• The server's private key (also called the private host id).
• A seed used as part of the nonce generation procedure.

The following per-election information is stored on the server.

• Election identifier
• Clear text voter emails, before the election is started. At the time the election begins, these are erased.
• The hash of the election control key.
• The hash of the election authorization key.
• The set of hashed authorized voter keys. Each element of the set is the hash of the voter's email (or IP address, in a public election), the election's authorization key, and the server's private key.
• The list of used hashed voter keys. This list is a subset of the previous list. The presence of an element in it indicates that the key has been used to submit a ballot.
• The list of ballot keys. A ballot key is the hash of a voter key and corresponding receipt.
• The map from ballot keys to ballots.

The election supervisor is sent the following information by email.

• Election control key
• Election authorization key

Each voter possesses the following.

• Voter key (in a private election)
• Authorization key (in a public election)
• Ballot receipt (after voting)

Attacks

This section describes what attacks might be mounted by attackers with various capabilities and how effectively the system defends against them. We assume here that email and the network are trusted components of the system.

• Malicious voter. In a private election, there is nothing that a malicious voter can do to damage confidentiality or integrity. In a public election, a malicious voter can vote multiple times by using a different IP address for each vote. If a voter in a private election claims that they did not receive their voter key, the same key can be reissued without giving them the ability to vote more than once.
• Malicious election supervisor. A malicious supervisor is capable of violating confidentiality and integrity in limited ways. The supervisor cannot learn how or whether a voter voted through normal use of CIVS. However, a supervisor could create an election and invite only one voter to vote in it. Similarly, the supervisor could invite himself to vote many times by providing different email addresses that he controls. Both problems can be mitigated if the election ID and the voting population are common knowledge. In the former case, this prevents a voter from being tricked into voting in the election; in the latter, the number of extra votes cast by the supervisor may be detected.
• Intruder with read-only access. Very little information is stored in cleartext on the server. An intruder could learn email addresses, if he manages to read the election data before the election is started. He could also learn elections results while an election is in progress, which is normally not allowed for private elections. In a public election for which the intruder knows the authorization key (perhaps because he is a voter in it), the intruder could guess IP addresses and query whether that IP address has voted. The intruder cannot learn how any voter has voted unless the voter provides the intruder with his ballot receipt.
• Intruder with read-write access. Clearly, such an intruder can arbitrarily corrupt the integrity of ballots that have been cast. He can also hijack control of an election, becoming supervisor, by installing new control and authorization keys. However, he cannot learn how previous or future voters have voted, because these ballots are protected by a nonce (the receipt).