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, which is as good as one can
reasonably expect a 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
- 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 temporary storage is undesirable, the voters can be
added after the election is started, and their addresses
will never be stored in cleartext.
- 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.
- 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.
- The supervisor uses the URL in the email to start the
election. Providing the URL proves that the supervisor presented a
real e-mail address.
- The server hashes the provided authorization key and
control key to make sure they match the stored hashes.
- 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.
- The cleartext voter e-mail addresses and the
corresponding voter keys are now forgotten by the server.
Voting
- The voter sends the server a ballot b that
includes the voter key v.
- 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.
- The server generates a fresh nonce r that serves
as the voter receipt.
-
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.
-
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):
-
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.
-
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.
-
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.
-
It sends v to the e-mail address e, so the
voter can later use it to vote.
-
The server forgets a, e and v.
Public election protocol
A 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
- The voter sends the server a ballot b that
includes the voter IP address IP and the
authorization key.
-
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.)
-
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.
-
The server forgets x and IP.
-
The server generates a fresh nonce r to use as the
voter receipt.
-
As in private elections, the server records the ballot indexed
by the hash of the receipt and the private host key.
-
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 a 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).