forked from andrewcmyers/civs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsec_priv.html
executable file
·381 lines (346 loc) · 15.1 KB
/
sec_priv.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Condorcet Internet Voting Service</title>
<link rel="canonical" href="@CIVSURL@/sec_priv.html">
<link rel="stylesheet" type="text/css" href="style.css">
<link href="@CIVSURL@/images/check123b.png" rel="shortcut icon">
<script src="ezdom.js" type="text/javascript"></script>
<script src="civs_hdr.js" type="text/javascript"></script>
</head>
<body>
<script type="text/javascript">
var body = document.getElementsByTagName('body')[0]
body.appendChild(create_header("Security and Privacy"))
</script>
<div class="contents">
<div class="normal_text">
<h2>Summary</h2>
<p>The Condorcet Internet Voting Service is designed to protect the security and
privacy of participants. Some important guarantees it offers
include the following:
<ul>
<li>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.
<li>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.
<li>E-mail addresses of voters are erased immediately after the election
begins.
<li>The election supervisor can determine whether a voter has voted
only with the permission of the voter and only after the election has ended.
<li>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.
<!-- <li>
Voters receive a receipt that
enables them to check that their vote was cast correctly. (Not yet implemented)
The issue is that there is also value in preventing voters from proving how they
voted on the issue. Technical issues remain to be resolved about how
to reconcile these integrity and repudiation properties. -->
</ul>
The remainder of this document describes why these goals are
believed to be met.
<h2>Election types</h2>
<p>
CIVS supports both <i>public</i> and <i>private</i> 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.
</p>
<p>
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.
</p>
<h2>Keys</h2>
<p>
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.
<ul>
<li>The server has a <i>private host key</i> <i>k</i>
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).
</li>
<li>Each election has an <i>election identifier</i> 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.
</li>
<li>For each election there is a <i>control key</i>
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.
</li>
<li>For each election there is also an <i>authorization key</i>
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.</li>
<li>Each voter receives a unique <i>voter key</i> 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.
</li>
</ul>
<h2>Private election protocol</h2>
<h3>Election creation</h3>
<ol>
<li>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.
<li>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.
<li>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.
<li>The supervisor uses the URL in the email to start the
election. This proves that that the supervisor presented a
real e-mail address.
<li>The server hashes the provided authorization key and
control key to make sure they match the stored hashes.
<li>For each e-mail address, the server performs the steps described
below under <a href="#adding"><strong>Adding
voters</strong></a>. 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.
<li>The cleartext voter e-mail addresses and the
corresponding voter keys are now forgotten by the server.
</ol>
<h3>Voting</h3>
<ol>
<li>The voter sends the server a ballot <i>b</i> that
includes the voter key <i>v</i>.
<li>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.
<li>The server generates a fresh nonce <i>r</i> that serves
as the <i>voter receipt</i>.
<li>
The server records the ballot indexed by the hash of the
voter receipt and the private host
key: {<i>r</i>, <i>k</i>}<sub>MD5</sub>. Thus
information on the server doesn't allow the identity of the
voter to be determined from the ballot.
<li>
The server reports the receipt <i>r</i> to the voter and
then forgets <i>r</i>. This enables later checking that the
ballot was cast properly, but only with the participation
of the voter.
</ol>
<h3><a name="adding">Adding a voter</a></h3>
Given an e-mail address <i>e</i>, the server performs the
following steps when a voter is added (either during
election creation or later from the election control page):
<ol>
<li>
A voter can only be added by presenting the authorization
key <i>a</i>, which is known by the supervisor but not stored on the
server. It is, however, available at election creation time.
The server stores {<i>a</i>}<sub>MD5</sub> to allow checking
whether the correct authorization key is presented.
<li>
The server computes <i>v</i> = {<i>e</i>, <i>a</i>, <i>k</i>}<sub>MD5</sub>,
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 <i>k</i> prevents the
supervisor from forging a voter's key.
<li>
The server looks up {<i>v</i>}<sub>MD5</sub> in the current set of
(hashed) voter keys. If it is already there, it
reports an error; otherwise, {<i>v</i>}<sub>MD5</sub> is added
to the set of voter keys.
<li>
It sends <i>v</i> to the e-mail address <i>e</i>, so the
voter can later use it to vote.
<li>
The server forgets <i>a</i>, <i>e</i> and <i>v</i>.
</ol>
<h2>Public election protocol</h2>
<p>
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.
</p>
<h3>Election creation</h3>
<p>
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.
</p>
<h3>Voting</h3>
<ol>
<li>The voter sends the server a ballot <i>b</i> that
includes the voter IP address <i>IP</i> and the
authorization key.
<li>
The server computes <i>x</i> = {<i>IP</i>, <i>a</i>,
<i>k</i>}<sub>MD5</sub> as the voter key.
(Secure in the sense that it does not permit
the voter's identity to be determined.)
<li>
The server adds the hash of this <i>v</i> 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.
<li>
The server forgets <i>x</i> and <i>IP</i>.
<li>
The server generates a fresh nonce <i>r</i> to use as the
voter receipt.
<li>
As in private elections, the server records the ballot indexed
by the hash of the the receipt and the private host key.
<li>
The server reports the receipt <i>r</i> to the voter and
then forgets <i>r</i>. This enables later checking that the
ballot was cast properly, but only with the participation
of the voter.
</ol>
<p>
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.
</p>
<h2>Data Storage</h2>
The following global information is stored on the server.
<ul>
<li>The server's private key (also called the private host id).
<li>A seed used as part of the nonce generation procedure.
</ul>
The following per-election information is stored on the server.
<ul>
<li>Election identifier
<li>Clear text voter emails, <em>before</em> the election is started.
At the time the election begins, these are erased.
<li>The hash of the election control key.
<li>The hash of the election authorization key.
<li>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.
<li>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.
<li>The list of ballot keys. A ballot key is the hash of a voter
key and corresponding receipt.
<li>The map from ballot keys to ballots.
</ul>
The election supervisor is sent the following information by email.
<ul>
<li>Election control key
<li>Election authorization key
</ul>
Each voter possesses the following.
<ul>
<li>Voter key (in a private election)
<li>Authorization key (in a public election)
<li>Ballot receipt (after voting)
</ul>
<h2>Attacks</h2>
<p>
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.
</p>
<ul>
<li><strong>Malicious voter.</strong> 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.
<li><strong>Malicious election supervisor.</strong> 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.
<li><strong>Intruder with read-only access.</strong>
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.
<li><strong>Intruder with read-write access.</strong> 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).
<!-- <li><strong>Election supervisor who is also an intruder
with read-write access.</strong>
<li><strong>Malicious CIVS server operator.</strong> -->
</ul>
</div>
</div>
</body>
</html>