Secure Client Platforms for Remote Internet Voting

Transcription

Technische Universität Darmstadt
Department of Computer Science
Cryptography and Computer Algebra
Prof. Dr. Johannes A. Buchmann
Diploma Thesis
Secure Client Platforms for Remote Internet
Voting
Author : Johannes Clos
Advisor : Axel Schmidt
Date of submission : February 14, 2008
Erklärung
Ehrenwörtliche Erklärung
Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit
den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus
den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese
Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Darmstadt, den 14.02.2008
Johannes Clos
iii
Contents
1 Introduction
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Objective of the Paper . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Fundamentals of Voting
2.1 Definitions . . . . . . . .
2.1.1 Election . . . . .
2.1.2 Electoral System
2.1.3 Voting Scheme .
2.2 Voting in Germany . . .
2.2.1 Voting Machines
2.2.2 Absentee Voting .
1
1
2
2
.
.
.
.
.
.
.
5
5
5
6
6
7
9
11
3 Remote Internet Voting
3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Protection Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 E-Voting versus E-Commerce . . . . . . . . . . . . . . . . . . . . . .
13
13
15
17
4 Cryptographic Techniques
4.1 Requirements for Communication Channels
4.1.1 Anonymous Channel . . . . . . . . .
4.1.2 Untappable Anonymous Channel . .
4.1.3 Public Bulletin Board . . . . . . . .
4.2 Building Blocks of RIV . . . . . . . . . . . .
4.2.1 Threshold Encryption . . . . . . . .
4.2.2 Mixnets . . . . . . . . . . . . . . . .
4.2.3 Blind Signature Schemes . . . . . . .
4.2.4 Homomorphic Encryption . . . . . .
.
.
.
.
.
.
.
.
.
19
19
19
19
20
20
20
21
24
26
5 Current Employment of RIV
5.1 Europe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 CyberVote Project . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 Council of Europe’s Recommendations . . . . . . . . . . . . .
29
29
29
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
v
Contents
5.2 Country Reports . . . .
5.2.1 Switzerland . . .
5.2.2 Estonia . . . . .
5.2.3 The Netherlands
5.2.4 Great Britain . .
5.2.5 United States . .
5.3 Discussion . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
34
36
38
41
43
6 Secure Platform Problem
6.1 Characteristics of the Platform
6.2 Malicious Software . . . . . . .
6.2.1 Trojan Horses . . . . . .
6.2.2 Viruses . . . . . . . . . .
6.2.3 Internet Worms . . . . .
6.2.4 Mobile Code . . . . . . .
6.3 Effects on RIV . . . . . . . . .
6.4 Counteractive Measures . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
46
46
46
47
48
49
50
.
.
.
.
.
.
.
53
53
54
54
59
65
71
76
.
.
.
.
.
79
79
80
83
85
90
7 Methods of error detection
7.1 Test Ballots . . . . . . . . . . . . . . .
7.2 Voter-Verifiable Voting Protocols . . .
7.2.1 Neff’s Voting Scheme . . . . . .
7.2.2 Chaum’s Visual Crypto Scheme
7.2.3 Ryan’s Prêt à Voter Scheme . .
7.2.4 Chaum’s Scantegrity Scheme . .
7.3 Evaluation of detection methods . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8 Methods of error prevention
8.1 Trusted Hardware Devices and Voting-CDs
8.2 Code Voting . . . . . . . . . . . . . . . . .
8.3 Multiple Casts . . . . . . . . . . . . . . . .
8.4 Trusted Computing . . . . . . . . . . . . .
8.5 Discussion of the presented methods . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9 Conclusion
91
Bibliography
95
A Abbreviations
vi
103
List of Tables
7.1
7.2
7.3
7.4
Neff’s voting scheme - Source: modified from [KSW05] . . . . . . . .
Possible sequence for an adoption of Chaum’s scheme to RIV - Source:
modified from [KSW05] . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocol sequence of Prêt à Voter . . . . . . . . . . . . . . . . . . . .
Comparison of the evaluated voter-verifiable voting schemes . . . . .
57
62
67
77
vii
List of Figures
2.1
Categorization of voting schemes - Source: modified from [Sta05] . . .
6
3.1
Categorization of vote classes - Source: modified from [VK06] . . . .
15
4.1
4.2
4.3
Functioning of a single mixnet server - Source: modified from [Wag06]
Decryption mixnet - Source: modified from [Wag06] . . . . . . . . . .
Audition of teller i - Source: modified from [CRS04] . . . . . . . . . .
22
23
24
7.1
7.2
7.3
7.4
Representation of a verifiable choice - Source: modified from [KSW05]
The parity cell patterns - Source: [BR03] . . . . . . . . . . . . . . . .
Possible combinations of bit patterns - Source: modified from [Cha04]
Bit patterns of the transparency layers, resulting image - Source: modified from [Sta05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 The filled in ballot - Source: modified from [RP05] . . . . . . . . . . .
7.6 Outline of the voting process - Source: modified from [CRS04] . . . .
7.7 Layers of the onion - Source: modified from [CRS04] . . . . . . . . .
7.8 Anonymizing mix with n tellers - Source: modified from [CRS04] . . .
7.9 Ballot structure and layout of the board - Source: modified from [Cha07]
7.10 Filled in ballot and obtained verification information - Source: modified from [Cha07] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.11 Auditing the tally - Source: modified from [Cha07] . . . . . . . . . .
55
60
60
8.1
8.2
86
87
Example for a trusted platform - Source: modified from [ASSV06] . .
Chain of Trust - Source: [Stu07] . . . . . . . . . . . . . . . . . . . . .
61
66
67
69
69
72
72
74
ix
1 Introduction
1.1 Motivation
The creation of the internet funded a wide range of ideas on how to increase the efficiency of the democratic1 systems. In this context the term e-democracy is commonly
used. It includes the subjects of e-government which stand for modernization and
simplification of administration processes supposedly leading to higher efficiency and
transparency in the public sector2 . But as a matter of fact the settings of e-democracy
lie beyond the typical applications discussed in the context of e-government. Effectively the borders are set by the respective corpus of legislation of modern democracies
[BN02]. With the introduction of digital signatures3 the ambitious project of Remote
Internet Voting (RIV) seemed to be within reach. The term translates to the reform
of our current voting procedures due to the rapid growth of computer usage and
promises such as higher voters’ participation and a reduction of the cost of elections4 .
On the other side the possible risks must not be underestimated. The necessity of
1
(Greek: demos = people, kratein = to govern) government of the people, by the people and for
the people
2
A good example for the implementation for e-government techniques is to be found in the European
country of Estonia. After the establishment of an infrastructure that guarantees free internet
usage to every citizen in 1999 services were introduced to create methods of interaction between
citizens and their government, e.g. a website was created to give citizens the possibility to post
statements and proposals for new laws and directives, vote for them, and direct them to the
administration. Furthermore the nationwide enrollment of a public key infrastructure was set
up through the distribution of an identification card that includes a chip to ensure the secure
storage of private keys. Hereby binding digital signatures were effectively enabled giving people
the possibility to sign and submit official documents from their computer.
3
In 2001 the EU-Directive 1999/93/EC [Hof07] found its realization in German law. Binding digital
signatures now represent a legal equivalent to traditional signatures.
4
Currently many countries suffer from a decreasing participation during traditional elections. Low
turnout being a problem for the legitimation of democratic systems, the idea occurred to reduce
people’s personal cost for participation. Remote voting makes it more comfortable for the voter
to cast a ballot. That is one of the reasons why many people see Remote Internet Voting as a
big chance for democratic systems in general (especially in participative democracies with a high
number of elections and referendums). This leads to the widespread opinion that countries could
miss a chance if they do not amend their electoral law through adding the feature of RIV. Fearing
they could fall behind, it is often overseen that current systems do not fulfill the requirements of
a strict interpretation of the electoral law.
1
1 Introduction
the voters’ trust in the election system and its acceptance cannot be stressed enough.
As the act of voting has to be regarded as the core of democracy (it represents the
most general and simple form of public participation, a fundamental prerequisite of
all democratic systems) all attempts of a reform have to be classified as critical and
the discussion accompanying a possible introduction of RIV needs to be lead with
the sum of all technical and social arguments taken into consideration.
1.2 Objective of the Paper
While a lot of actions have been taken to enhance voting protocols in order to make
them more secure, the technical devices used as interfaces between a voter and the
voting protocol have not yet received enough attention. This thesis deals with the
issue of insecure client computers used as voting platforms. Currently it represents
one of the major obstacles against RIV. Therefore it sketches RIV, describes its most
common cryptographic techniques and evaluates its usage in Estonia, Switzerland,
the Netherlands, Great Britain and the USA. Subsequently, the thesis picks up the
experiences and analyzes the structure of personal computers commonly used as client
machines, as well as their risks. Besides exposing the problem, possible ways to make
the platforms more reliable, thus trustworthy, are described. As possible security
enhancements for voting platforms consist of detective as well as preemptive mechanisms, both mechanisms will be presented. Furthermore, by estimating the complex
adaptation of these mechanisms, it is tried to give an evaluation of the different
proposals. In the end, an implementation is recommended which seems to be most
promising for the attempt to make client machines a more secure entity.
1.3 Outline
We start with a definition of some important electoral terms leading to a historical
description of electoral laws and the voting system currently being used in Germany.
Hereby the reader is supposed to get a general idea of the current situation and the
development so far. Afterwards the terms Absentee Voting and Voting Machines will
be explained to a deeper extent, since the first one represents an already being used
remote voting system whereas the latter describes an alternate type of electronic
voting that currently causes quite a stir. These two terms are introduced with the
intention of giving a clear boundary definition. After a clarification of the terms
Remote and Electronic Voting the reader is introduced to RIV and the prior is distinguished from the topic of the thesis. In this context the protection goals are listed
and the fundamental differences between Electronic Commerce and Electronic Voting
are discussed. Among others the most important cryptographic techniques used in
2
1.3 Outline
voting protocols are Mixnets, Homomorphic Functions and Blind Signatures. These
will be explained in chapter 4 that also deals with specific communication channels.
But while RIV is still a fairly new topic enclosing a lot of unfinished construction sites
it has already been used several times for real-life elections and thereby lost a little
bit from its cutting-edge character. In the next chapter, an overview of countries is
given that support such programs, or have run pilots or binding elections over the
internet, to present a picture of how widely spread this election type is. Additionally
there is a detailed description of the kind of elections RIV is currently used for. Furthermore, the succeeding discussion summarizes the lessons learned from practical
implementation so far.
Since the infrastructure is the internet which, by itself, is highly insecure, the usage of cryptographic protocols is fundamental to guarantee the correct functioning
of every single element of the digital election (registration, voting, tallying and most
definitely recounting). So far many efforts have been made to provide secure communication. Nevertheless, there is one big threat remaining, due to the fact that client
computers are highly insecure. Today’s personal computers run standard operating
systems and software while users often are not skilled enough to maintain their computers in a sufficient way. Therefore there is a high chance that voters’ browsers (or
other software, potentially including their operating system) may be compromised
and may thus not behave as the user wishes it to (even while deceiving the user
into thinking that it is). Generally speaking it has to be assumed that the voting
platform is open for all kinds of malicious software (malware) hidden in a piece of
software that the user is unaware of, since detection is based on old definitions in a
malware dictionary (if detection is used at all) and the actions taken to secure the
system are mostly reactive. Since the weakness can be exploited automatically on a
large scale it is considered as the Achilles heel of RIV. As a consequence the software
could possibly interfere with the voting act by showing the voter a fake ballot and
sending a ballot filled in with the intruder’s choice to the election authority. Malware
also threatens other protection goals. An attacker could for example follow up on how
someone casts a vote. Additionally the voter can be hindered from casting a vote at
all. Consequently insecure platforms result in jeopardizing the voting principals when
a ballot is cast from them. Highly sophisticated Trojan horses and worms possess this
ability. Appearing in stealth mode they can run without being recognized by common
virus detection systems. Thereby it becomes evident that a typical computer user is
not able to realize whether such code runs on his PC or not.
As an entry point to the principal topic the flaw is described more detailed. While
examining the risks of insecure voting clients, the clients have to be distinguished
by type because a voting client could be any service access device ranging from
personal computers to personal digital assistance devices, or even cellular phones.
Since voting clients cover a broad bandwidth in technical specification and in their
ways of connecting to the internet, different kinds of attacks might be possible. The
3
1 Introduction
discussion will show how the clients differ from each other but will concentrate on
personal computer usage for the subsequent chapters.
In order to notice and prevent attacks on voting clients some of the most promising
methods are evaluated. The strategies that promise to secure voting clients during
RIV include the following.
Voter-verifiable protocols focus on the issue of non-reliable voting systems. In
this context the principles of protocol designs for non-reliable voting machines
(Neff, Chaum) and enhancements to optical scan voting (Ryan, Chaum) are
explained. Subsequently it is shown to which extent each of them is suitable
for a transfer onto a possible usage within RIV and which changes have to be
applied.
Code sheets and test ballots, introduced by Opplinger in [Opp02], provide an
interesting possibility to prevent automatic election fraud. Therefore sheets
with special codes for each election choice are distributed via a secure channel
(e.g. letter post). If each ballot paper is unique a possible intruder cannot fake
a ballot, since changing it would presume one knows the mapping between the
codes and the election candidates. On the other hand test ballots provide an
easy way of testing the proper functioning of the voting system.
The idea behind multiple casts as introduced by Volkamer and Grimm in [VG06]
does not provide client security. It rather makes up for its absence. By admitting repetitive votes a later cast vote could overwrite a previous one which might
have been cast coerced or from a hijacked platform. It is obvious that multiple
casts must prohibit multiple votes of the same person. It will be shown how
this feature could be implemented and discussed whether it fulfills the principle
of equality.
Trusted Computing as presented by Alkassar et al. in [ASSV06] is another way
to ensure client safety. The chapter gives insight into the basic functioning of
Trusted Computing and shows how it can enhance RIV in a way that turns
voting clients providing the necessary hardware into verifiable machines.
The conclusion of the work provides an analysis of the presented methods. This
should answer the question as to what extent they present possible solutions to the
attacks that appear through the usage of PCs as voting platforms for RIV. Additionally, these methods are reviewed concerning some associated social aspects. Trying
to reach the goal of secure client platforms the conclusion closes with an attempted
outlook for the utilization of remote internet elections in the nearer future.
4
In the first part of this chapter voting is conceptualized by giving the definitions for
an election, an electoral system and a voting scheme. Afterwards the development of
voting in Germany is explained. Thereby two important innovations to the electoral
practice consisting of remote and electronic voting represented by absentee voting
and direct recording electronics are highlighted. Both constitute important changes
to the electoral law in Germany. By going into the details it is intended to define
the characteristics of different voting schemes in contrast to each other. This is
particularly important because electronic and remote voting show two of the main
characteristics of RIV.
2.1 Definitions
2.1.1 Election
Elections can be defined as the democratic method to appoint people to entities of
representation and executive positions [Noh07]. Their usage ’may well be the best
possible approximation to popular control of government that can be achieved in
modern, industrialized mobile mass society’ [Mil72]. In this context the citizens in
a given society periodically have to answer the question who should be selected to
govern for a period of time. Elections serve the purpose to obtain accurate data representing a set of participants’ answers to this question. In effect one vote can be seen
as a single participant’s answer to this question in its physical representation. It consists of a selection, generally from a predetermined set of answers, called candidates.
But, depending on the set of rules that regulates the election, the selection can also
be independent of a default list. This is also known as a write-in vote. Ballots are
groups of questions combined into a certain structure. Each question of an election is
refered to as a single race. The electoral law includes legal requirements that organize
elections. For example it consists of legal requirements that regulate the eligibility of
participants in an election. Every person entitled to participate is called a voter.
5
2.1.2 Electoral System
An electoral system includes the mode by which the voter can express a political
preference and of how the vote is translated into decisions regarding the occupation
of mandates and the composition of representative conventions. In case of parliamentary elections an electoral system translates the data of votes by specific measures
into parliamentary seats. In a narrow interpretation it regulates this process by localizing constituencies, defining the rules of candidature as well as vocalization and
committing to the accounting of votes [Noh07]. In a wider interpretation it can also
affect matters of the voting scheme. Majority and proportional vote are commonly
referenced as two examples for different electoral systems.
2.1.3 Voting Scheme
As described in [Sta05] voting schemes are commonly refered to as protocols that
define the procedure which turns cast votes into a final tally. As a result the term
can also be interpreted as any method that can successfully manage an election. Doing
so, voting schemes can be differentiated by their technical nature. On the one hand
traditional voting schemes are schemes such as ordinary paper ballots, mechanical
recording machines and punch-card ballots. Absentee voting as described in Chapter
2.2.2 is seen as a traditional voting scheme as well. By contrast electronic voting
schemes use electronic devices to conduct an election. Direct recording electronic
machines as introduced in Chapter 2.2.1 and RIV as presented in Chapter 3 can be
classified as such. The categorization of specific voting schemes can be seen in Figure
2.1.
Voting Schemes
Traditional
Voting
Paper
Ballots
Absentee
Voting
Mechanical
Recording
Machines
Electronic
Voting
Remote
E−Voting
Internet
Voting
Poll Station
E−Voting
DRE
Machines
Figure 2.1: Categorization of voting schemes - Source: modified from [Sta05]
6
2.2 Voting in Germany
The first use of paper ballots to conduct an election appears to have been in Rome
in 139 BCE. Nevertheless many forms of voting have been practiced since then. We
will now give an overview of the electoral system in Germany followed by the main
aspects related to the development of electoral law.
In addition to the elections for the European Parliament Germany has parliamentary elections of universal kind for the Bundestag (the state parliament), in each of
its federal states, and for the parliaments of cities, counties and boroughs. Furthermore direct elections are practiced for the appointment of district administrators and
mayors (local elections).
Altogether the operation of elections is organized by the electoral laws that can
be found in the Constitution, Bundeswahlgesetz (federal election law) and Bundeswahlordnung (federal electoral regulations on the national level and similar laws
on the state level). Thereby the electoral system of Germany includes personalized
proportional representation which is a mix between proportional representation and
majority vote with the proportional component being the overall decisive factor. Half
of the members of the Bundestag are elected through a majority vote (one candidate
for each electoral district). At the same time the citizens can use their second vote
for a party of their choice. The overall strength of parties represented in the Bundestag exclusively results from the number of nationwide cast second votes [vP03].
The parliamentary elections are carried out in obedience to the principles named in
the German Constitution (Art. 38 GG). These require the elections to be
universal: No citizen should be excluded from her right to vote.
direct: No intermediates, e.g. deputies, are assigned to vote in someone else’s
name.
free: Neither governmental nor any other coercion is allowed. This should
assure a free choice between competing parties.
equal: All voters have the same amount of votes which are equal in weight.
secret: The voter’s decision, represented by a voter marking his choice on a
ballot, is confidential. Open and public votes are invalid.
Unlike other countries (e.g. Belgium, Luxembourg) the electoral law of Germany
doesn’t commit the citizens to vote (compulsory voting). The possibility to vote
is rather seen as a basic right. It is usually controlled by a specific voting district
where the citizen is registered. Therefore eligible voters are listed in special registers
maintained by the local authorities.
Besides parliamentary elections Germany knows a variety of non-parliamentarian
elections, amongst others for workers’ councils, universities’ boards and governing
7
boards of social security institutions. The decision-making abilities of these boards
are altogether very limited. This is the main reason for less strict requirements during
these elections.
Before the principles of democratic elections (as named above) became widely accepted there were a number of different electoral laws. Prussia, for example, introduced a three-class system of voting in 1849, where the voting population was divided
into three groups with a different weighting of votes. The allocation to a certain group
depended on the citizen’s income and the taxes he paid. The election was conducted
in public and oral and by these means was not secret. Furthermore it was indirect
since electoral deputies were elected. In 1918 it was abandoned. Universal female
suffrage was, similar to universal manhood suffrage, established in a step-by-step
process.
Taking a look at the history of voting shows that the situational context and formal
design of how we vote has always been a controversial topic. Electoral regulations
tend to influence who votes, how we vote and also affects the outcome of elections.
Indications for this not only exist within the central questions of electoral law in the
19th century (whether or not open or secret elections should be conducted and, if
at all, votes should be counted equally). Historic examples reach from the consequences of ostracism 1 in ancient Greece to viva voce 2 in medieval England and USA
and the permission of voting machines in Scandinavia in 1950’s. Electoral laws are
rarely neutral. Instead they always favor certain actors and discriminate others. Each
amendment of electoral laws led to political rejections and changed the voting behavior. But even though new benchmarks of political and technical development came
up within the past hundred years the typical way of how elections are conducted has
hardly changed since the last reformation of electoral laws. With the introduction of
polling booths and the Australian Ballot 3 , the system of voting in which voters mark
their choices in privacy on uniform ballots, printed and distributed by the government
or designate their choices by some other secret means, the evolution of the voting act
seems to have found its climax [Dom07]. The usage of paper and pen, counting of
votes by hand and voting in the domestic voting district are still best practice. But
despite the stability the electoral law highly depends on the changing political and
constitutional developments. Between 1956 and 2002 the German electoral law was
modified by 34 amendments that document the continuing need for changes4 . Some
1
Aristotle claims Cleisthenes was responsible for the institution of ostracism. It allowed the citizens
to send a fellow citizen into temporal exile if he was getting too powerful. The term ostracism
was derived from ostrakon, the Greek word for a piece of broken pottery on which the citizens
wrote the name of their candidate. [Car07].
2
Viva voce describes the practice of voting by publicly calling one’s election choice during a convention of voters [Jon03].
3
Victoria and South Australia were the first states to introduce ballot secrecy in 1856.
4
The vast majority of these amendments dealt with administrative topics such as the customization
8
of them are of great importance such as the introduction of the absentee vote in 1956
and voting machines in 1975. While absentee voting lowers the personal cost the
governmental operation of voting machines tries to simplify and speed up the tallying process. The combination of both, an automated counting and more comfortable
vote cast clearly points in the direction of RIV.
2.2.1 Voting Machines
Voting machines are usually the first thing that comes to one’s mind when hearing
the term electronic voting. Basically RIV and voting machines have in common that
they both make usage of electronic devices (terminals) as an interface between voter
and ballot. Voting machines can be defined as being standalone technical devices
used to define ballots, to cast and especially to count votes, and possibly to produce
some audit trail information - all done by a single machine. The first machines were
mechanical but nowadays it is common to use electronic voting devices. Voting machines are most often referenced as machines with direct recording electronic (DRE).
After the election they produce a tabulation of the voting data stored in a removable memory component (and eventually as printed copy). Elections for the German
Bundestag and for the European Parliament are only legal if conducted with ’standalone’-devices. That is to say voting machines can only be part of a local network
at the polling station. They can’t be connected to a countrywide network where the
election results are sent to a central tallying server [oG07c].
According to the promoters of voting machines the benefits include a higher accuracy, faster results, lower costs, easier voting for disabled people and the elimination
of invalid votes. Problematic is the fact that the usage of voting machines puts
important steps of the voting procedure inside a black box. Thereby the positive
aspect of having a public verifiable election is eliminated. Most people cannot reconstruct what happens to the votes inside the machine and how the results are
calculated. The integrity of an election highly depends on the proper functioning of
the devices and their security against manipulation. Everybody has to rely on the
ability of experts who test the source code and analyze the components. In Germany the law for voting machines regulates the procedure of accreditation [oJ07]. It
assigns the National Metrology Institute providing Scientific and Technical Services
(Physikalisch-Technische Bundesanstalt) with its duty to control the compliance of
the following requirements:
correct implementation of the voting process
secure storage of cast ballots
guarantee of privacy
of the voting districts.
9
correct counting of cast ballots
usability of the machines
secure and long-lasting construction
security in case of malfunction
insensitivity against mechanical, climatic and electro-magnetic environmental
influences
However, the institute does its testing only on a sample machine. All others are
distributed by the vendor directly. A further point of criticism is caused by the
fact that recounting of electronically cast votes is often not practicable due to the
lack of voter verifiable paper trails (VVPT). The lack of transparency is another
disadvantage. While traditional elections allow the voters to observe the tallying
process DRE so far does not offer this feature. This illustrates a serious problem
of DREs especially looking at real-life deficiencies throughout elections like the ones
during the elections for the US-presidency in 2004. The result of Florida included
an electronic miscount of 18.000 votes [Kru07]. So far methods of audition are not
intended by most voting machine producers. We will cover this topic to a deeper
extent during Chapter 7.
Recently DREs have continually failed to provide the standard of a trustworthy
voting system. A security check of electronic voting machines by computer scientists
of the University of California uncovered more than a dozen security risks throughout
all tested machines. A team of experts was assigned by the California election supervisor with the investigation of eight already used and certified e-voting-systems from
market-leading companies (such as Diebold, ES&S, Hart Intercivic and Sequoia). The
scientists uncovered severe security problems and required massive system-updates
on hardware and software prior to a possible recertification. In a decision issued in
August 2007 the Secretary of State withdrew the certification of all vendors for the
time being [oS07]. Other countries have completely abandoned the usage of voting
machines. In 2006 Italy already stopped all ongoing projects with voting machines
due to irregularities discovered during its parliamentary elections at the beginning
of the year [Zie06]. The most recent decision was taken in the Netherlands. After
the Dutch group ’Wij vertrouwen stemcomputers niet’ and the German ’Chaos Computer Club’ published alarming facts that showed how easy it is to reconfigure the
machine by exchanging the Erasable Programmable Read Only Memory (EPROM)5
the dutch government was in doubt whether voting machines could be safely used. An
appointed commission was supposed to investigate this topic. Amongst other things
the authors of the final report criticized the lacking of VVPT in a final report and
5
Since the EPROM stores the voting software, this attack illustrated the infiltration of a voting
system with a manipulated software. If designed properly, this software has the potential to
effect the counting without election officials noticing.
10
advised to reconsider the ’Regulations for approval of voting machines 1997’. Thereafter the Secretary for the Interior immediately announced that the certification will
be withdrawn [Com07a].
2.2.2 Absentee Voting
While talking about remote internet elections absentee voting is sometimes used as
a reference. This is because both are conducted in a remote way. Supporters of an
absentee vote argument with its smooth introduction and the high acceptance within
the population. At the same time opponents fear the reinforcement of problems
related to the loss of privacy.
Traditionally the definition of an absentee vote is that it is cast by a citizen who is
unable vote at his regular polling place on an election day. As a result it is independent
of time and location of the presence demanding election using a ballot box. Since the
postal way takes its time absentee voting can also be referred to as voting in advance.
Absentee voting was established in Germany in 1956 with the introduction of the
federal election law and firstly used during the Bundestag elections in 1957 [Jes03].
The voter is required to apply for the absentee vote after receiving the polling card.
But the ballot paper will only be sent to citizens who
1. cannot be in the voting district on the day of election due to important reasons.
2. moved to another voting district after the time period of electoral registration
has started.
3. cannot attend the election due to professional reasons, illness, high age or physical problems.
Since these reasons are not checked anybody may proclaim that this is the case.
Absentee voting as a deviation from the strict requirements of the personal election
is interpreted by the Federal Constitutional Court (FCC) as a thorough hole of this
principle. But at the same time it considers it as being consistent with the constitution. In the decisions of the FCC concerning absentee voting in 1967 and in the
second judgment 1981 the possibility of absentee voting was strengthened. For groups
of people who cannot attend on election day due to reasons as stated above should
exist the possibility of an absentee vote if they can be accredited. Nevertheless, the
absentee ballot should remain the exception [Feh07].
The decisions of the FCC took place at a point in time where just a little portion
of voters (1957: 4,9 %, 1980: 13 %) preferred this procedure. But the percentage of
absentee voters increased steadily: 1998 the percentage was 16 and in 2002 almost
11
every fifth eligible voter made use of it. In large cities like e.g. Munich (31 %) and
Hamburg (28 %) it cannot be called an exception anymore [Ker04].
During the previous chapter the terms election, electoral system and voting scheme
were defined. In addition they were applied to Germany by giving some background
information about held elections, amendments of the electoral law and thereby affected voting schemes. As demonstrated the biggest impact on voting was caused by
amendments of the electoral law that included absentee voting and DRE machines in
the process. Illustrating the characteristics of these systems revealed hints that yield
in the direction of a stronger application of RIV in the future.
12
In this chapter RIV is defined by assembling its different elements. They are described
before the details of inevitably required protection goals are addressed. While ecommerce and online-banking became widely accepted in our society many people
tend to believe that if they are possible RIV must be possible, too. This prejudice is
clarified in sequence.
3.1 Definition
RIV combines the characteristics of electronic, online and remote voting schemes.
The main difference between traditional and electronic voting (e-voting) consists of
the respective underlying scheme. E-voting scenarios map the process of voting onto
digital technology. Technologies are DRE machines (voting machines, optical scanners
and voting pens) and RIV. The phases of digital voting scenarios are quite similar to
the traditional approach. In the preparation phase voter and candidate lists need to
be prepared, ballots have to be designed and the according infrastructure is set up.
The next phase consists of registration where voters are obliged to register and proof
their identity before being admitted for voting. This procedure is optionally and its
details depend on the election law of a country. During the voting period voters cast
their ballots after authenticating themselves. In the end the votes are counted, the
tally is prepared and finally published.
Per definition the usage of voting terminals connected to a network as well as the
casting of votes that are transferred to another computer where they are stored and
counted is called online voting [oG07b]. It represents a specialization of e-voting. In
reference to [Ins01] three different groups of online voting are distinguished depending
on where the voting terminals are located:
Poll site-voting system: The terminal is located in a safe environment like a polling
station. In contrast to voting machines the terminal sends the results to a server
for further counting. Since polling stations are staffed the voting terminals used
here are administrated.
Kiosk e-voting system: The terminals are computers/ATM-like machines with special hardware and are situated at fixed locations (e.g. kiosks, libraries). For
13
this reason the system does not provide the same convenience as the cast of
a remote vote. The machines are not under permanent staff-control but they
are assumably protected against the problems that voters’ private computers
have (for example insufficient prevention of attacks through a lack of security
mechanisms) because the software that runs on kiosk systems is most likely
unaccessible. The configuration is provided by administrators instead.
Remote Internet Voting System: This type of system allows voters to cast their
votes from any computer or digital device connected to the internet or to a
private network, typically from home or at work. Devices such as personal
digital assistants, personal computers, mobile phones and even game machines
could be used to access these systems.
Remote voting is characterized by the fact that voters do not have to visit a special
location to cast a vote. Instead voters get the possibility to vote from wherever they
are. This lowers the personal cost for the voter1 . But to make this possible a reliable
communication channel is required. Absentee voting is the traditional application
and uses postal mail for its purpose. The internet offers different communication
channels. Regardless of the channel, remote systems demand from the voter to vote
in a responsible way that eliminates coercion and guarantees privacy. It is safe to say
that in the context of online voting poll-site voting does not represent a remote voting
system. The kiosk e-voting system partly shows characteristics of a remote system,
but only RIV distinguishes clearly enough from presence voting. A categorization
of the named voting systems by the terms presence and distance voting is shown in
Figure 3.1.
1
’The cost factor that might be reduced is the time and effort that it takes to go to the electoral
office and cast a vote in person. However, there are other cost factors involved in electoral
participation, most noteworthy among them being the time and effort that it takes to acquire
subjectively sufficient information to cast a ballot. Those other costs seem to remain unaffected
by e-voting’ [Sch02]
14
3.2 Protection Goals
Traditional
Voting
Presence Voting
Distance Voting
Voting through polling box
Absentee voting
Mechanical Recording
Machines
Electronic
Voting
DRE Machines
Remote Internet Voting
Networked Voting Machine
(voting at polling station)
Kiosk e−voting system
Figure 3.1: Categorization of vote classes - Source: modified from [VK06]
For RIV generic computers serve as voting platforms by running some kind of
voting software plus various other possibly insecure software on top of a more or
less stable operating system. Chapter 7 talks about the platform’s structure and
the resulting security problems. It is obvious that these problems are beyond the
control of electoral administrators. Naturally they affect the security required by the
guidelines of electoral laws that remain a prerequisite for RIV as well as for all other
possible types of voting used during elections.
3.2 Protection Goals
In order to assure the political election principles mentioned before RIV needs to
achieve a variety of protection goals. The following security requirements for remote
internet voting systems are the most important ones for the further course of this
thesis [SP06]:
Eligibility: It is necessary that only valid voters are eligible to vote. The predetermined criteria for eligibility depends on the election law of each country.
The voting system has to verify the voter’s validity and ensure that each entity
can cast only a permitted number of votes.
Anonymity: Anonymous voting achieves privacy and prevents the identification of a voter from his vote. As a pre-condition it has to prohibit the traceability between vote and voter.
Coercion resistance: A voting system is defined as coercion resistant if it is
infeasible for a voter to cooperate with a coercer and prove to him that he voted
in a certain way, abstained from voting, or disclose his secret keys.
15
Accuracy: Accuracy requires the voting system to be error-free. Theefore the
voters’ ballots have to be cast as intended and counted as cast during tallying.
Modified, duplicated or erased votes are not tolerable.
Robustness: The voting scheme has a limit of tolerance by which minor technical errors can be tolerated.
Correctness: Every valid vote, no matter how it was cast, has to be included
in the final tally and counted correctly (of course only if it is not a repeated
vote).
Verifiability (universal and individual): The voters’ trust in a voting system is a prerequisite for the acceptance of the results. Creating trust in the
integrity of a voting system requires an independent verification along each
translation step of the election. Universal verifiability requires that anyone is
able to verify the correctness of the voting process and its result, whereas individual verifiability convinces each voter that his personal vote was correctly
recorded.
Usability: The design of a voting system has to consist of intuitively and easily
usable interfaces and needs to render a usage possible for handicapped persons.
In the course of this thesis it can be seen that insecure voting platforms especially
affect the goals of anonymity, accuracy, coercion resistance and correctness. For this
reason and the additional goal of transparency during the election voting systems
strongly benefit through verifiability. Nevertheless receipt freeness additionally plays
an important role because individual verifiability usually comes along with receipts.
Receipt freeness: The voter has to be prohibited from gaining certain information (refered to as a receipt) that might be used by him to prove his voting
decision to an attacker or coercer.
To be consistent with legal principles all of the requirements have to hold during
the entire election, including voting clients, the communication channel and voting
servers. While the single requirements are achievable, there is no protocol up to date
that fully meets all the said requirements at once.
Obviously some of the named requirements seem to be at odds with each other.
For example it is not obvious how anonymity and verifiability can be achieved at
the same time. [Smi05] shows how some of the desires are simultaneously achievable
while seemingly being incompatible.
In order to realize safe voting schemes clearly defined rules of communication between the involved entities ensure the treatment of requirements. Voting protocols
play this role by making use of standardized guidelines regarding syntax, semantics
and synchronization of the data transfer. The least ambiguity threatens the correctness of the entire election. The fundamental cryptography of voting protocols
16
3.3 E-Voting versus E-Commerce
exceeds the one of traditional communication protocols since its requirements are
significantly stronger. The cryptographic primitives are explained in Chapter 4. Altogether research on protocols has reached a stage where important requirements like
correctness, robustness, anonymity, coercion resistance and verifiability are possible.
3.3 E-Voting versus E-Commerce
Today financial transactions to the amount of millions of dollars are made via the
internet. It is a common and widespread opinion that it should be also possible to
use the same medium for digital voting as well. Thereby it is often overseen that
digital voting and digital commerce show fundamental differences. For this reason it
does not make sense to transfer the feasibility of e-commerce onto remote e-voting.
There are several reasons for this (see [Riv02] for more details):
Financial transactions are performed online, but there is always a separate
offline process for checking them and for correcting any errors detected (the
buyer typically gets a transaction receipt). Since this is not the case for evoting so far, the prevention of fraud and error, while having no chance of
retroactive correction, has to be guaranteed.
Electronic commerce includes the possibility to dispute a transaction if something did not work correctly. With e-voting in contrast there is always a deadline
that has to be met. Disputing an election requires many objections commonly
settled in court.
Concerning electronic commerce, the involved parties can be identified by transaction records. This is substantially different from electronic voting where the
cast of a ballot should in no way identify the voter, as this violates the voter’s
privacy and anonymity. Furthermore, this would subject them to coercion.
The profile of an attacker in the electoral scenario is much different from such in ecommerce. People that aim at making some quick cash by manipulating transactions
certainly have to be skilled. But their profile is definitely lower compared to some
foreign power with its intelligence apparatus and serious funding. They are motivated
by the ability to change the outcome without anyone noticing. Among others the
adversaries of an election system are foreign governments with powerful interests at
home and abroad.
17
En route to a definition of the term RIV this chapter explained the characteristics of remote, electronic and online voting schemes. Similar to absentee voting
the voting process is uncontrolled regarding the enforcement of privacy during RIV.
Importantly, the private voting platforms of a RIV system are uncontrolled as well.
In this context the protection goals were defined. In order to achieve secure client
machines anonymity, accuracy, correctness, coercion resistance and verifiability are
of particular interest. Finally the fundamental differences between remote e-voting
and e-commerce were pointed out.
18
The voter’s anonymity and authenticity are important protection goals during voting. But anonymity is far from being a standard feature while communicating over
the internet. An eavesdropper can for example reveal the origin of electronic correspondence by observing the internet traffic and correlating it with the originating
IP-address. Later on, the identity of the originator can be determined by tracing
back the IP to an individual user. However, voting protocols rely on the anonymity
of the voter. In this respect, this chapter defines some requirements for the communication channel before the functioning of important cryptographic measures for their
achievement is illustrated. These are mixnets, homomorphic encryption and blind
signatures. For a better understanding of these measures some knowledge of the basic cryptographic principles (public key cryptography, hashes, digital signatures etc.)
is advised. For a detailed explanation the reader is refered to [Buc04].
4.1 Requirements for Communication Channels
4.1.1 Anonymous Channel
The characteristic of an anonymous channel is that it guarantees anonymous communication. Voting scenarios especially require anonymous voters. In effect, the recipient of a casted vote cannot detect the identity of its sender. Methods for achieving
this type of communication will be illustrated in the following chapter. As noted by
[Rja02] it is important that an anonymous channel does not have to be untappable.
4.1.2 Untappable Anonymous Channel
In contrast to the prior a further requirement is added here. This is the physical
security of the transmission of a message. As a result no one should be capable of intercepting the transmission of a message and of sharing the content of a message with
a third party. In practice, the implementation of untappable anonymous channels is
19
hard because it would require perfect secrecy1 .
4.1.3 Public Bulletin Board
Generally an electronic bulletin board is a possibility to make information publicly
readable. In the context of RIV it enables different forms of verification. If a voting
protocol’s definition requires proofs of correctness to be posted on a bulletin board,
everyone might double-check if their votes were cast as intended. But while everybody
can read the postings it is important that write access is exclusively given to certain
registered and authorized users. These users can write to an assigned personal area
whereas the deletion of previous postings is prohibited. Besides universal verification,
bulletin boards enable access control (before information is posted in the user’s area
it is verified) and provide communication channels between participants. If used for
voting schemes bulletin boards typically display the information through the usage
of web servers.
4.2 Building Blocks of RIV
4.2.1 Threshold Encryption
Threshold encryption describes a possibility to reconstruct a secret from the shared
knowledge of several participants in a fault-tolerant way. Doing so one can lower the
probability of an unauthorized person gaining access to sensible information because
there is no need in trusting a single person. As described by Shamir in [Sha79]
threshold encryption can be very helpful in the management of cryptographic keys.
On this account it is an important measure to assure a more robust tallying process
for RIV.
According to Shamir a (t, n) threshold scheme is required to divide the secret data
D into n shares D1 , . . . , Dn such that
1. the knowledge of any t or more pieces Di , where i ∈ 1 . . . n, makes D easily
computable.
2. knowledge of any t − 1 or fewer Di pieces leaves D completely undetermined
(in the sense that all its possible values are equally likely).
1
Let M be the set of plaintexts, K the set of keys and C the set of ciphertexts. An encryption
scheme E : M → C is unconditional secure (perfect secure) if P (m|c) = P (m) holds for all
m ∈ M and all c ∈ C and if the probability distribution of the keyspace is of equal distribution
and a single key k exists for every plaintext m and ciphertext c such that Ek (m) = c [Buc04].
20
The threshold factor t determines the smallest number of shares necessary for
the reconstruction. The cooperation of t participants is sufficient to reconstruct the
secret whereas less than t of the shared secret carriers have no chance to obtain any
relevant information about the secret. As a result the choice of the parameters t and
n determines the strength of the system.
It is assumed that the definition of a polynomial of degree n requires n + 1 points.
In order to share a secret S with a (t, n) threshold scheme it is necessary to produce
n shares. The first step consists of choosing t − 1 coefficients
a1 , a2 , . . . , at−1 .
The secret S is considered to be a number and used as the coefficient a0 . Next the
polynomial can be built as
f (x) = a0 + a1 x + a2 x2 + · · · + at−1 xt−1 .
Now the shares that are given to the participants can be calculated by constructing n
points of the polynomial. Using the values i = 1, . . . , n these are retrieved as (i, f (i)).
For the reconstruction of the secret any subset of t of these pairs are sufficient to
determine the coefficients of the polynomial by interpolation.
4.2.2 Mixnets
Mixnet-schemes as presented by Chaum [Cha81] are intended to establish anonymity
for the originator of a message. Besides the establishment of an untraceable email system mixnets can be used for achieving anonymization of web traffic. For anonymous
channels the purpose of achieving anonymity during RIV is of particular importance.
We will now explain the functioning of a simple mixnet-scheme and enhance it with
encryption functionality. For proofing the correctness of mixnets a survey of verifiable
mixnets is added.
The goal of a mixnet scheme during RIV is to create anonymity for the voter.
Under normal circumstances messages sent over the internet contain information
about their origin. Mixnets reshape the communication between sender and receiver
to make it unlinkable. The idea is straightforward and can be described by an analogy.
Let’s imagine ten people putting boxes of the same size, color and weight into an
intransparent bag. Next, it is laced up and shaken with the boxes still being inside.
It is clear that afterwards no one can tell which box belongs to whom. A mixnet works
very similar by re-ordering a batch of received messages. In order to prevent unique
messages from being recognized, all messages have to be transferred into uniform
appearance first. To this end, short messages are stuffed with random bits until they
reach a certain length. Larger messages have to be divided into shorter fragments.
21
Additionally the messages are encrypted. Otherwise sender and receiver could be
identified by simply looking at the headers of the messages. Next, the batch is
shuffled randomly by a mix. If a proper permutation of the received input2 is applied
before resending the output the first step is taken. Now the output batch differs from
the incoming in order of appearance of the elements (Figure 4.1). Additionally the
elements of the batch cannot be distinguished. That way an adversary who observes
the communication cannot reveal the identity of the messages.
m2
m4
m1
m6
m5
m3
m1
m2
m3
m4
m5
m6
Figure 4.1: Functioning of a single mixnet server - Source: modified from [Wag06]
But so far the reached anonymity depends only on one single mix. This is not
satisfying because the permutation can be easily annulled by a corrupt mix-operator.
To avoid the possibility of revealing the mapping between input and output further
mixes are needed to form a mixnet. This helps to maintain the original goal of
anonymity while not having to trust a single entity. In consequence a chain of several
servers is needed.
There are n mixes in the mixnet, where πi is equivalent to a single mix with
i = 1, . . . , n.
π ′ = π1 ◦ π2 ◦ ... ◦ πn .
The resulting mixnet π ′ represents the n-fold concatenation of mixes. In the formula
above ◦ represents the concatenation of two mixes. It is obvious that the connection
between input and output of the resulting mixnet can only be restored if every single server πi out of the n mix servers is corrupted and willing to reveal its secret
permutation.
Decryption mixnets require the participants to run a special software that encrypts
the message that is supposed to be anonymized multiple times. The number and
order of encryptions depends on the number of involved mixes and their sequence.
Originally this is achieved by encrypting each message with the public keys of all
mixes during an initial encryption phase. Then each mix first partially decrypts and
2
For the functioning it is not important what the content of the communication is. For example it
can consist of messages or HTTP-requests.
22
then mixes the messages it permutes. Mix by mix one layer of encryption is peeled off
until the final mix restores the original cleartext. In Figure 4.2 the input of the mixnet
consists of six messages, where each E(m) represents a multiple encrypted message.
The intermediate mixes can neither see the plaintext nor the original sender and final
receiver of the messages. All they learn is the address of the following mix. After
the batch is finally processed by all n mixes the communication is anonymized. As a
result the output batch does not correlate with the input batch anymore.
Mixnet
E(m1)
E(m2)
E(m3)
E(m4)
E(m5)
E(m6)
Mix 1
...
Mix n
mx
mx
mx
mx
mx
mx
Figure 4.2: Decryption mixnet - Source: modified from [Wag06]
Within re-encryption mixnets each mix mixes and additionally reencrypts its input
before resending. The idea behind is the fact that without reencryption the resulting
messages do not change. This makes it easy to recover the voter related to it. Our
concern is an implementation for protocols of RIV where the tallying is conducted
in the end. In between mixing and tallying the decryption has to take place. [RS06]
explains how a re-encryption mixnet can be implemented by using a Threshold ElGamal Cryptosystem where all authorities responsible for running the mixnet jointly
generate the system parameters using a distributed key generation protocol. In the
end, the encrypted ballot in the final output can only be decrypted if all authorities
participate in this.
Verifiable Mixnets
The integrity goal is that all plaintexts at the input of the mixnet yield the same
decrypted ciphertexts at the output of the mixnet. To prove this goal a mixnet
operator would have to reveal all of the secrets like practiced permutations and used
keys. This would destroy the established anonymity that was just achieved by setting
up the mixnet. To serve the original purpose while reaching verifiability without
giving away the secrets one can make use of a zero-knowledge interactive proof (ZKIP)
as presented in [Buc04, Wag06]. To show correct functioning every mix-server would
have to participate in such a ZKIP to proof.
A ZKIP has the requirement that the verifier does not know a secret the prover
possesses. The goal of the prover is to convince the verifier of his knowledge of the
23
secret without revealing it. The most important aspect of a ZKIP is that for the
verifier it can be mathematically proven not to have learned anything about the
secret while becoming totally convinced of the prover’s knowledge of the secret. In
practice, a ZKIP must have an efficient run-time to be seriously considered.
One implementation of a ZKIP for mixnets is given through randomized partial
checking. Based on the usage of two mixing rounds it is made possible to uncover
half of the connections and still verify the correct functioning of the server. While
going down the intermediate messages of each mixing server (represented by the
middle column) the verifier randomly chooses whether to uncover the left or the right
mixing round. This procedure is illustrated in Figure 4.3. As a result, randomized
partial checking allows to audit the server while maintaining the achieved anonymity.
For a deeper discussion of randomized partial checking and verifiable mixnets the
reader is refered to [JJR02] and [Che07].
Telleri
L
L
from
Telleri−1
R
L
R
to
Telleri+1
L
Figure 4.3: Audition of teller i - Source: modified from [CRS04]
4.2.3 Blind Signature Schemes
Conventional digital signatures succeed in creating secure authentication. After a
message was signed a verifier can verify the signed message with the public key
matching the private signature key. For successful verification of the signature the
result needs to match the plaintext. Since this mechanism reveals the identity of
the signer it is not ideal for a usage during RIV. As first mentioned by Fujioka et
al. [FOO93], blind signatures make anonymous authenticity possible by including
a couple of additional steps. An analogy can be seen in a message sealed in an
envelope and additionally including a sheet of carbon paper. The originator puts
the envelope into another envelope that is passed to a trustee with administrative
functionality. The trustee takes off the outer envelope. The inner envelope has the
address of the originator written on it. Thereby the trustee can decide whether
the originator is eligible to be authenticated. If so, the trustee signs the envelope
on the outside of the envelope. Of course, the carbon paper passes the signature
down to the message. Since it is invisible what is inside, the signing of the message
happens blindly. Afterwards the message is returned. After unblinding by removing
24
the envelope the sender gets a message signed by the trustee. Blinded signatures are
the digital equivalent of this procedure. In the case of a voting scenario, the message
is of course a ballot. It can now be filled out and returned to a tallier.
According to Chaum [Cha83] blind signatures require
A signing function s with a publicly known inverse s’ so that s′ (s(x)) = x.
Additionally it should not be possible to derive s from s’.
A blinding function b with an inverse b’ such that b′ (s(b(x))) = s(x). It is
important that b and b’ are only known to the originator. Furthermore, it is
important that s and b(x) reveal nothing about x.
As one example, RSA can be used as a procedure for blind signatures. Traditionally,
the RSA signature is built as follows
md mod n
where d is the secret factor, n the RSA module and m the plaintext message. The
matching public factor is called e. The calculation of d and e requires that the
following holds3 :
de ≡ 1 mod n
(4.1)
For a blind signature a random factor r (with r ∈ Zn ), is used that is a relative
prime to n. Therefore the greatest common divisor (gcd) of both has to be equal to
one.
gcd(r, n) = 1
Next the blinding factor bf is calculated by taking r to the power of e.
bf = r e
In order to blind the message the voter multiplies the message with the blinding
factor.
m′ ≡ m · r e mod n
Then the voter sends m’ to the signing authority, where it is signed with the
corresponding private key.
3
See [Buc04] for details on the calculation.
25
s′ ≡ (m′ )d mod n
The resulting s’ is equivalent to the signed inner envelope. It is returned to the
originator. To remove the envelope the voter multiplies s’ with the inverse of r.
s ≡ s′ · r −1 mod n
The voter has now succeeded in obtaining the true signature s of m. As a result,
the voter’s message has a signature the voter could not have constructed on his own
because it is subject to the signer’s secret key d. The scheme’s security is subject
to the hardness of factoring module n into its primes. The signature scheme is blind
since r is random. It does not allow the signer to learn about the message even if he
can solve the underlying hard problems.
Because of (4.1) the correctness of the above assumptions can be shown:
s ≡ s′ · r −1 ≡ (m′ )d · r −1 ≡ md · r de · r −1 ≡ md · r · r −1 ≡ md mod n
As mentioned above, RSA relies on factoring being mathematically hard. New
forms of computing as well as the finding of an easier mechanism to solve this problem
might eventually make classic cryptographic mechanisms useless. For information
about blind signature schemes based on the hardness of other problems the reader is
refered to [Nau07]. Further information about implementing blind signatures can be
obtained from [FOO93].
4.2.4 Homomorphic Encryption
Homomorphic encryption for anonymous voting was introduced by Benaloh [Ben87].
The basic concept is to publish the signed and encrypted ballots together with a proof
of validity. After the verification of signature and proof an encrypted sum of all votes
can be obtained by taking advantage of the homomorphic property. Afterwards, the
final tally can be decrypted by the tallying server. This procedure effectively hides
the contents of the original ballots while providing a publicly computable tally.
A homomorphism is the mapping between two algebraic structures (e.g. groups,
rings or vector spaces) preserving the original structure. Several different homomorphisms are known. The most well-known is the group homomorphism with the basic
rules as defined below.
Let (G, ⊕) and (H, ⊗) be two groups. Now a function h : G → H is needed such
that for all u and v in G it holds that
26
h(u ⊕ v) = h(u) ⊗ h(v)
.
From this property, one can deduce that h maps the identity element eG of G to
the identity element eH of H, and it also maps the Inverse of G to the Inverse of H
in the sense that h(u−1 ) = h(u)−1 . Hence one can say that h ’is compatible with the
group structure’.
As an example (R, +) and (R+ , ·) are chosen as our groups and ex : (R, +) → (R+ , ·)
as the function that transfers R into R+ . Now the following equation has to hold.
∀u, v ∈ R :
eu+v = eu · ev
For the sake of completeness, two things have to be added: We have to show that
the identity element exists in both groups and that the encryption maps the Inverse
of R to the Inverse of R+ . Here, the identity element eR+ = 1 and the identity element
eR = 0 (since adding 0 and multiplying with 1 simply has no effect for the members
of R and R+ ).
1. e0 = e0 · 1 = e0 · e0 · (e0 )
2. e(−m) = e(−m) · em · (em )
−1
−1
= e(0+0) · (e0 )
−1
= e(−m+m) · (e0 )
= e0 · (e0 )
−1
−1
= e0 · (e0 )
=1
−1
= (e0 )
−1
Now let M be the group of all plaintext messages (or filled-out ballots) with the
group operation ∗. Analogous C is the group of all encrypted messages with the group
operation •. An encryption scheme is called (∗, •)-homomorph if the following holds
for all plaintexts m ∈ M, encryption functions E, keys k and encryptions E(m) ∈ C.
∀m1 , m2 ∈ M :
E(m1 ∗ m2 ) = E(m1 ) • E(m2 )
The homomorphic encryption can be illustrated by using RSA as the encryption
function.
For (M, ·) let M be the set of plaintext messages. The group order here is |G| = n.
Encryption with public key e transfers M into (C, ·), the resulting set of encrypted
messages. Again, m1 , m2 ∈ M represent two plaintext messages with the matching
encryptions c1 , c2 ∈ C:
c1 = m1 e mod n and c2 = m2 e mod n
27
Then the multiplication of the encrypted messages is an encryption of the multiplied
plaintext messages:
c1 · c2 = m1 e · m2 e mod n
During this example the operations of both groups are defined as multiplication by
components. Indeed can ⊕ and ⊗ be the same operation.
For election systems, a scheme where the encrypted votes are added is preferred.
The main advantage of an additive homomorphism is the operational characteristic
of the shortest runtime. See [Sch07b] for more details upon this.
The essence of this section was the definition of different communication channels and the illustration of the most important cryptographic techniques that are
used as building blocks for RIV. Mixnets as well as homomorphic encryption succeed
to achieve anonymity in differing ways. Blind signatures follow a slightly different
approach by providing anonymous authenticity. Further threshold encryption was
proposed as a mechanism to make voting schemes more robust.
28
This chapter describes the most recent events in the context of adopting RIV for
real elections. The first part deals with happenings on the supranational level of the
European Union such as the CyberVote Project and Council of Europe’s Recommendations for e-voting in general. The succeeding part will go into the details of national
programs of RIV. We chose Estonia, Switzerland, the Netherlands and Great Britain
because these countries already run more or less advanced programs. Additionally
the United States were examined because they already acted as a pioneer in the context of voting machines. These countries will be looked at relating to reasons for
introduction, type of elections during which RIV was used, applied voting protocols
and gained experiences.
5.1 Europe
5.1.1 CyberVote Project
The CyberVote Project [Pro03a] was launched by the European Commission (EC)
in September 2000. It was partially funded by the EC and aimed at demonstrating
the possibility of fully verifiable online elections guaranteeing absolute privacy of the
votes and using fixed and mobile internet terminals. The project’s objective was to
contribute to the development of a democracy in Europe by enabling the use of a modern electronic voting system. Another goal was to implement a trustworthy e-voting
protocol which could be integrated to existing infrastructures for the identification of
voters.
The CyberVote design was driven by solutions which had to allow the user authentication while guaranteeing the ballot’s secrecy, sanctity and integrity, on the
one hand, as well as the voter’s freedom of expression, the user-friendliness and the
acceptability of the system on the other hand.
The project was carried out by a consortium and involved partners from industry
(EADS Matra Systèmes & Information of France, Nokia Research Centre of Finland,
British Telecommunications of the United Kingdom), universities (K.U.Leuven Research & Development of Belgium, Technische Universiteit Eindhoven of the Nether-
29
lands) and potential users (Freie Hansestadt Bremen of Germany, Mairie d’Issy-lesMoulineaux of France, Kista Stadsdelsnämnd of Sweden).
The final voting system is a homomorphic public-key threshold encryption scheme.
It is able to handle multiple and concurrent elections and different versions of cryptographic protocols. Voters’ identification is handled through smartcards or a login
with secret PIN codes. The software was implemented in Java and HTML to come
up with a platform independent voting application. The voting itself was possible
through internet connected computers, java enabled mobile phones and PDAs.
After the development of the voting system the CyberVote project involved its
testing in different elections in 2002/2003. The first test was held in December 2002
in the French town of Issy-les-Moulineaux. The second test took place in Germany
in January 2003 at the University of Bremen. The trial covered the elections of the
three representative bodies of the University. The turnout of internet votes was quite
low during both elections. The last test took place in the Swedish city of Kista.
The target audience were elderly citizens. Much work was needed to attract these
voters. Although the trial was open all day for an entire week, roughly 200 voters
participated in the electronic voting. In July 2003, the CyberVote project has ended
officially. According to the final report the pilot elections encountered only minor
problems1 but the overall achievement of the project was successful.
However, an intermediate report stresses the vulnerability of voting clients to different groups of malware that might affect the voting software, or allow remote control
of the client, or allow an intruder to get access to the computer’s screen and keyboard
[Pro03b].
5.1.2 Council of Europe’s Recommendations
The Council of Europe (CoE) is an organization of 46 member states, from in and
around Europe. It is not directly connected to the European Union (EU), though
all current EU member-states are members of the CoE. According to its statute the
aim of the CoE is to ’achieve a greater unity between its members for the purpose
of safeguarding and realizing the ideals and principles of their common heritage and
facilitating their economic and social progress’ [oE07]. In terms of voting the CoE
has the clear purpose in protecting democracy, the rule of law, and human rights.
The Recommendations [oE04] were adopted by the Committee of Ministers in
September 2004 and set out a blueprint for governments currently using or planning to use e-voting for elections and referendums. It is based on the experience
1
Primarily due to trouble with the Java Runtime Environment (JRE) a compatibility test with a
Mac was not successful during trial in Kista.
30
5.2 Country Reports
gained by Member States during pilot projects as well as on knowledge from legal
and technical experts.
The main aspects are common-sense and include the following:
e-voting shall respect all the principles of democratic elections and shall be as
reliable and secure as elections which do not use electronic means.
the interconnection between the legal, operational and technical aspects of evoting set out in the Recommendations must be taken into account on application.
while they are not required to change their voting procedures, Member States
should consider reviewing their relevant domestic legislation in the light of the
recommendation.
Although it is not binding, the recommendation, described by the CoE as ’the
first international legal text on e-voting’, is nonetheless a valid and internationally
agreed point of reference in terms of emerging e-voting standards and the general
requirements for implementing e-voting systems. It clearly calls on the governments
of the Member States to ensure that their e-voting systems meet the standards and
requirements set out in the three appendices of the Recommendations relating to
legal, operational and technical aspects. It is particularly stressed that in case of
e-voting the voter must be able to obtain some sort of confirmation for his vote. Also
it should be possible for the voter to correct it if necessary without the secrecy of the
ballot being violated.
The CoE standards are not ambitious in the sense that they do not aim to meet
particularly challenging quality criteria. In fact, the specific role of the Recommendations are stated in a generic form. In their analysis McGaley and Gibson [MG04]
criticize the Recommendations because of their lack of adhering to the properties
of requirement models in software design. From a software engineer’s view overand under-specifications result in too concrete and abstract regulations. In addition,
redundancy and repetitions increase the risk of the underlying requirements model
being misunderstood.
5.2 Country Reports
5.2.1 Switzerland
The voting participation in Switzerland averaged to 58 % from 1945 to 1997. This
number represents one of the lowest turnouts of democratic countries [Noh07]. From
1967 until today it declined in a percentage of 10 %. The possibility of mobilizing
31
especially young people to take part in elections is one of the main motivations for
the country’s work and interest in RIV [dMV07]. Another reason that supports this
project is the fact that Swiss citizens vote four to five times a year, sometimes even
more. Through its various elections and referendums the system of ’direct democracy’
asks for this. In this context it seems more comfortable for the citizens to vote at a
random place and in a given time period.
The work on RIV in Switzerland began in 2000 with the appointment of a working
group led by the Federal Chancellery (consisting of representatives from the Federal Government, the cantons, and computer experts). Its intention was to discuss
the topics of electronic administration (’guichet virtuel’) as well as remote electronic
voting (’vote électronique’) [Ker04]. The electronic voting group was supposed to investigate chances and risks of RIV. Further goals of the working group consisted of the
harmonization of voters’ registration as a fundamental prerequisite, the organization
of pilot projects for electronic elections, the search for methods of implementation for
the electronic signing of referendums, and ways for the proposing of candidates. The
Federal Chancellery authorized the three participating cantons (by name Geneva,
Neuchâtel and Zürich) to conduct several pilots during national referendums based
on a legal basis respecting the Council of Europe’s Recommendations [Ker04]. The
trials follow a similar scheme, which is a system of prior voter identification where
every person entitled to vote is sent a random secret by mail. These secrets are saved
anonymously and are used for the authentication of the voter during the election. As
a result, the encrypted ballot is only saved and counted if the secret is valid and has
not already been used for a prior vote. This method by itself ensures the anonymity
of the voting act because no one knows the mapping between voter and secret except the voter himself [VK06]. A complete technical description of the used voting
protocol has not been published. But a general description [dMV07] implies that the
protocols of Zürich and Geneva both rely on anonymous channels based on mixnets.
Geneva was the first canton that tested RIV. It took place in the borough of Anières
in 2003 and especially benefited from Geneva’s pre-existing central voting registers.
Since then the canton held seven additional trials. Currently the usage of RIV is only
intended as an additional voting method [oG07a].
For the pilot project in the canton of Zürich the first step consisted of establishing a
digital and central register of eligible voters for the entire canton. The sent out secret
is written on the voter’s polling card and protected by a seal. The polling card with
its information grants access to the voting system. Then an electronic ballot paper
can be filled in. By entering the secret code the vote is effectively transmitted and
deposited. The voting scheme of Zürich also makes use of code voting. Here the voter
does not vote by choosing the name of a candidate. Rather one chooses a number from
an individual and personalized code table included on the polling card and received
via mail. These tables are freshly generated for each election. Zürich uses code voting
32
5.2 Country Reports
only for the purpose of encryption via mobile phones. A demonstration of its voting
scheme can be found at [oZ07]. In general code voting presents an interesting method
to prevent election fraud over insecure client platforms and will be further explained
in Chapter 8.2. The first test during a national referendum took place in 2005. On the
occasion of a confederated referendum, Zürich executed further testings of its voting
scheme in chosen voting districts in June 2007. This was the third time that RIV was
applied during a confederated referendum. Eligible voters were able to chose between
casting a vote traditionally, or electronically by using RIV or sending a message from
their mobile phones. According to its organizers the pilot experiments succeeded
without special occurrences [Bun06].
Neuenburg held pilots of RIV during the same referendum. It represented the fifth
application of the system within the scope of a confederated referendum. The first
test took place in 2005. The canton’s citizens entitled to vote had the possibility to
cast their vote traditionally or electronically by using RIV. Neuenburg also intends
to establish RIV as a third alternative to the traditional ways of voting. Therefore
people who want to take part in it must register in time through an official internet
portal (’Guichet Unique’) that offers other services as well [Spe07].
Results
The pilot trials in Switzerland were evaluated several times and under different aspects. Already in 2002 the chancellery of the state of Geneva published the final
report of the committee that was appointed to evaluate the security of the application of RIV [Bun02]. Its result was that the pilots had a reasonable level of security.
At the same time it stressed the problems of server authenticity and platform security.
The chancellery then appointed the expert Rolf Opplinger to study and comment on
the suggestions made in the committee report. According to him the secure platform
problem is known to be hard in the scientific community where an implementation
of RIV on a larger scale and in a sufficiently secure way is not regarded as feasible.
For this reason Opplinger advised different mechanisms to secure the platforms some
of which already found partial realization in the voting system of Geneva [Opp02].
The Swiss system, however, has been criticized for its use of proprietary software
and for the ease of allowing coercion and vote-selling. Nevertheless Swiss officials
draw a positive conclusion based on their pilot trials of secure RIV being possible.
Still this conclusion bears some risks as the evaluation also states that the ongoing
security depends on maintaining control of continually changing threats and risks.
Potential risks and sources of danger still exist in hackers, viruses, Trojan horses or
the like [Bun06]. They demand further methods of protection from the voter. Since
the threats are continually changing the security measures also have to be continually
improved (which again results in increasing personal costs) [BB06].
33
For the future, the Swiss government is determined to continue further testings of
the e-voting project. According to a new law pilots are limited to a maximum of 10%
of entitled voters until 2011. At the same time the government demands from the
cantons to create a country-wide register for enlisted voters in order to enable RIV
for the Swiss citizens living abroad until 2009 [Wil07].
5.2.2 Estonia
The basis for the application of RIV in Estonia is its infrastructure of free internet
usage for every citizen established in 1999, and the nationwide public key infrastructure consisting of a distribution of identification cards that enable a secure storage of
private keys and binding digital signatures. In 2005, Estonia for the first time offered
the possibility of RIV to its citizens during local elections [Thi07]. Every Estonian
could choose it as an additional method of voting. As this was the first time RIV was
used for binding elections, there was an enormous response by observers. Afterwards
two Estonian parties objected RIV for the reason that the secrecy of the vote could
not be ensured and that the system was not transparent. But their criticism did not
prevent further application. In March 2007, the next step was taken by the usage
during the Riigikogu (parliamentary) election. It represents the first usage of RIV in
a binding countrywide election so far. Of course one has to keep an eye on the basic
local parameters. Estonia is a very small country with a total of 1.3 million inhabitants (approximately the size of Munich). According to [UMM06] the motivation
for RIV in Estonia is, due to a low participation rate, to create an additional voting method with the aim of increasing the voter turnout (similar as in Switzerland)
besides fighting a possible political alienation.
Specifically the scheme has the following features. The legislation offers all voters
with digitally enabled ID cards the possibility to cast their votes in an advance voting
period (from six to four days before the election day). During this period an interesting security feature is provided by giving the voters’ the opportunity of casting
multiple ballots. The Estonian election law provides e-voters with the right to alter
a vote that was cast by electronic means infinitely with additional electronic votes.
This presents an evident security feature since e-voters whose voting act is disturbed
by a person trying to gain influence on their decision now have the possibility to
simply cast another vote. A timestamp indicates the latest cast. New problems arise
through the necessity of verifiable timestamps. But Estonian law still guarantees the
primacy of the paper ballot. This can be seen by the fact that a cast paper ballot
on election day overrides all previous electronic votes. We will take a closer look at
multiple casts in Chapter 8.3.
The Estonian scheme as described by [OSC07a] and [Com05] makes use of the so
called envelope method. First the voter’s ID card must be inserted into a smart card
34
5.2 Country Reports
reader. To proceed, the voter inputs a first personal code (PIN1). Upon voting a
voter makes a choice that is encoded with the public key of the election server. This
presents the inner envelope. Next the voter must approve his choice by digital signing,
thus providing the outer envelope. Therefore the voter must enter a second personal
code (PIN2). The signed and encoded vote is stored until the election day, with the
aim of ascertaining that the person has cast only one vote. After this is checked
and repeated votes have been eliminated the outer envelopes (digital signatures) are
separated from the inner envelopes (encrypted votes). During this step voter lists are
compiled from the outer envelopes. Inner envelopes (which are not associated with
the identity of the voter anymore) are forwarded to the tallying computer that has
the decryption key of the system. Because of its particular importance the server is
not connected to the internet. Assurance of the voter’s anonymity is only provided
by the fact that the signatures on the votes are removed before they are passed to
the tallying instance. For this reason the National Electoral Committee stresses that
at no point a party is supposed to be in possession of the digitally signed e-vote and
the private key of the system [Com05].
Results
From a technological point of view the secret used for authentication purposes in
Estonia consists of several elements (hybrid authentication). Here the authentication
consists of possession (of the smartcard) and knowledge (PIN numbers). Together
they are more secure than an authentication scheme that relies on either one. This
can be seen as a big advantage in comparison to the Swiss method of authentication.
Madise and Martens [UMM06] point out that the layout of the scheme also has
the theoretical drawback of providing privacy only to a certain extent. This is the
case because, due to the open signature, there is no way of keeping it secret if a
person has voted or not. In practice this presents no problem since the fact whether
a person entitled to vote did participate in voting is not regarded as a part of the
principle of secrecy. Voter lists that contain information about participation and
chosen voting method are preserved in the archive and can be accessed (countries with
compulsory voting might favor voting schemes with this functionality). Furthermore
it is stated that the major risks for RIV are various attacks that could be used
to compromise the voting results, to break the voter’s anonymity, or to interrupt
the elections. The vulnerabilities behind these attacks arise from the fundamental
properties of the internet architecture and current PCs. Also seemingly successful,
e-voting trials usually do not prove the security of the system. This is justified by
the fact that it is difficult to prove that no security breach has occurred and, if none
occurred, successful trials cannot eliminate security risks for future elections.
The question of this new possibility’s effect on the voter turnout cannot be clearly
35
answered. The reports for the Council of Europe were based on a telephone survey
after the elections in 2005/2007 and conducted concomitantly with the elections. The
prior one concludes that RIV will probably not motivate those people who principally
do not participate in any voting act. Still it proclaims that a slight increase of turnout
might be possible. If this is the case, it must be assumed it does so only within those
groups of voters that vote occasionally [Tre05]. In 2007 the follow-up report comes
up with the estimated figure of a possible 0.5% lower turnout without the feature
of RIV. This estimation is based on the figures of 5.4% e-voters of all participating
voters (opposed to 1.9% in 2005) and the result of the survey saying that roughly
one tenth of the e-voters would not have voted without having had the possibility to
vote by internet. Consequently it did not present a significant impact on the overall
turnout [Tre07].
5.2.3 The Netherlands
The Remote Voting Project in the Netherlands (in Dutch: ’Kiezen op Afstand’) was
kicked off by the Dutch Ministry of the Interior and Kingdom Relations in 2000.
Intentionally the project was supposed to facilitate voting for the Dutch citizens
by two experiments. The first one intended to enable voting in any polling station
within a voter’s municipality (’Stemmen in een willekeurig stemlokaal’). Instead of
the former informative polling card the voter now received an indispensable one. Since
the passport was not sufficient to vote at someone’s own polling station anymore the
polling card really was indispensable. For the present thesis the second experiment
is significantly more interesting because it deals with the implementation of internet
voting for the Dutch voters abroad.
The first use of RIV in the Netherlands took place during the elections for the
European Parliament in 2004 where a proprietary voting application was utilized. At
the Dutch parliamentary elections in November 2006 RIV was applied for the second
time. But this time the Rijnland Internet Election System (RIES) was used. The
property of voters being able to check their vote and everybody being able to check
the final outcome makes RIES transparent and presents a major advantage over the
prior. Nevertheless, RIV was strictly limited to expatriates who were requested to
explicitly register in advance (meanwhile the regular postal way of voting was also
available to Dutch citizens living abroad as well as posting a ballot through a proxy).
The time period for the registration ended two month prior to the actual election
day. RIES was developed for usage during the Rijnland Water Board elections. The
boards administrate all matters dealing with water politics (building of dikes, water
quality and the like) and do not depend on the electoral law. Their decisions are of
essential significance concerning the threat of floods. Contrary to its importance, the
elections to the Rijnland Water Board traditionally have a very low turnout because
36
5.2 Country Reports
citizens seem not to be fully aware of the actual impact on their everyday life. In 2004
RIES was used for the first time during the Water Board elections in the provinces
of ’Rijnland’ and ’De Dommel’.
Technically RIES is based on the use of hash functions. Before the election a preelection table (reference table) is published containing, for each voter, key-less hashes
of all possible votes and their linking to the candidates. At one point the voter
receives a voting code for authentication by post. After entering it one can choose
the political party of choice and a candidate from this party. This is possible during a
certain time period prior to the election day. During the election a post-election table
is created. First the voters have to hash their votes, this time using their personal
secret keys. This results in a so called technical vote. The technical votes are sent to
the vote server who is going to publish them. Additionally the voter is recommended
to save a personal version for verification purposes. The vote server can now build a
key-less hash of the technical votes and use them for building the post-election table.
Afterwards it will also be published. A voter can verify his own vote by checking
if the technical vote appears on the post-election table. It is also possible to see if
it appears as a vote for the chosen candidate. For the final calculation it has to be
checked if a hash appears in the reference table. If it does, the vote is valid and the
indicated candidate’s sum can be incremented. Anybody who cares to download the
pre- and post-election tables may independently count the votes. Thus, a vote that
has been registered wrongly, or not at all, can be detected. Given the received votes,
an incorrect result can be detected as well. Additional technical information about
RIES can be found in [HJP05] and [Kru06].
Results
Hubbers et al. [HJP05] mention several threats in their summary. First of all the
company that designed the scheme plays the role of an authority and generates the
secret keys. According to the creator of the survey compartmentalization or a stronger
separation of powers should be accomplished by having more parties taking over
responsibilities. Especially the key management process should be accomplished in
a distributed way. Also the keys must be destroyed at the right time in order to
prevent misuse. Another serious threat is seen in malware on the voter’s PC that can
modify the votes (even so fraud can be detected). An alternative to protect against
such malware is seen by the usage of candidate identities that are different for each
voter (code sheets). In response to this security problem the Dutch government
commissioned the development of an open-source voting system in 2003/2004 that
was based on code sheets [KMC+ 05]. Trying to manipulate a vote now the malware
does not know how to select the desired option. Code Voting will be covered more
precisely in Chapter 8.2.
37
The OSCE Assessment [OSC07b] of RIES found broad consensus amongst both, developers and critics of electronic voting. Besides the threats named above it criticizes
that designers surrender protection against coercion in favor of greater transparency.
Possessing a voter’s authorization code and technical vote anyone can determine the
actual vote. It concludes that RIES is not a suitable system for the possible expansion
of RIV to the general population and encourages the development of an open source
version free of proprietary issues and secret functionality.
The Dutch elections make it very hard to come up with a result regarding the voter
turnout. The Rijnland Water Board elections suffered a historically low turnout while
using RIV in 2003 and 2004. It decreased to 17% in ’Rijnland’ of which 31% voted
via the internet. ’De Dommel’ showed a similar turnout.
Altogether the Dutch Electoral Commission seems to have experimented with RIV
in a careful way [PvH07]. A commission for the development of the future electoral
process was appointed. It recommends the Ministry of the Interior and Kingdom
Relations to make RIV the regular voting method for expatriates only. In its report
the commission arguments that during the trials it was found to improve access.
Additionally it says that ’a large majority of these voters explicitly wishes to vote
using the internet’ and that ’postal voting should be retained for those Dutch citizens
who do not have internet access or are unable or unwilling to use it’ [Com07a].
Currently there exists no plan to apply RIV for binding elections on a countrywide
perspective in the nearer future.
5.2.4 Great Britain
The British government started exploring the options of RIV in 2002. The main
motivation for this, besides the lowering of costs, an increased turnout and better
accuracy, was to provide the voters with more choices to cast their ballots. In order
to hold pilots local authorities have to submit proposals. After a review the Secretary
of State for Justice decides which proposals are accepted. Additionally a federal
Electoral Commission was assigned to review the administration and processing of
elections, including every electoral pilot scheme. In order to support further pilots
with RIV, the Commission emphasized that a wider enrollment of these methods in
Great Britain should only become possible after security and reliability have been
fully tested and proven, and can command a wide public confidence. Additionally,
the necessary costs for a secure and reliable system must lie within a frame which
could reasonably be met. Furthermore, the Commission demands from the tested
systems to increase the transparency of the solutions adopted in order to ensure
continued stakeholder acceptance of the technology, and to follow a centrally managed
accreditation and certification process to provide independent assurance of e-voting
solutions. This is supposed to enable local authorities to make a well-informed choice
38
5.2 Country Reports
regarding the use.
First pilots were held in the following years. In 2002, pilots of RIV were only
conducted in a small number of wards of 14 local authorities. Following these test
runs the Communications-Electronics Security Group (CESG) conducted a security
study that came up with a solution that does not rely on trust in client systems.
The solution consisted of pre-encrypted ballots based on a full implementation of
code sheets as presented in Chapter 8.2. The pilots of 2003, conducted authoritywide pilots, based on a larger number of participants, and partly implemented the
proposals of the CESG. However, the full implementation was only used for remote
voting via mobile phones. For the usage of RIV the voter had to select an option
from a rendered representation of the ballot in his browser. Later on this option was
translated into a code. As a result the intended protection against malicious software
was not accomplished [Com03].
In the run-up to the local government elections in 2007 seven applications for pilots
using RIV were received. According to the final report of the Electoral Commission
several applications already demonstrated insufficient understanding of important
security issues in this early stage (especially lack of documentation as well as effective
project and risk management plans). Afterwards local authorities were notified of
these concerns and had to address them. Finally, after the Electoral Commission was
satisfied, pilot schemes in the five councils of ’Rushmoor’, ’Sheffield’, ’Shrewsbury &
Atcham’, ’Southbucks’ and ’Swindon’ were approved. All of them involved the use
of a paper-based pre-registration process in which electors had to provide personal
identifiers in order to be issued with the credentials for RIV. Swindon was the only
council that piloted the use of supervised, networked electronic facilities at polling
stations and allowed electors to vote at any polling station within the borough. The
intended learning from these pilots focused on building up the evidence gained from
the 2003 pilots and on assessing the impact of requiring electors to provide personal
identifiers in order to register [Com07c].
Results
All pilots relied on proprietary software with its source code being unavailable in time.
This is why the certification did not provide any measures to increase the transparency
of the voting system (due to the lack of verifiable checkpoints or audit trails). The
lack of certain certification steps for the systems and their operation meant that the
technology’s validity had to be taken for granted. The evaluation of the pilots in
2007 by the Electoral Commission classifies this as a major shortcoming. In spite
of variations between the different pilots, the quality and testing procedures were
found to be inadequate in all cases. Significant quality management failings included
the lack of evidence concerning effective configuration management, comprehensive
39
testing, strong technical development processes or detailed design documentation.
Best practice in security governance was not followed and the security assurance was
below the one associated with typical governmental IT projects.
The report also lists that it is not feasible for local authorities themselves to realize
the degree of scrutiny required to achieve sufficient security assurance in terms of
timescales, costs or the type and level of required resources. Therefore a significant
centrally guided evaluation and testing provided outside the context of an election is
indispensable. This would be achieved best through the provision of an accreditation
and certification scheme. The certification process should involve an evaluation of
technology, including a more detailed design, or code review, for critical components
of the system. Further investigation is required to identify the optimum approach
and level of detail to be undertaken in this field. Extensive testing is required, including the conduct of a mock election, suitability and accessibility testing, security
penetration testing of the standard configuration as well as volume and stress testing.
But the Commission finds that even with the implementation of commercial best
practice security methods and assurance, there are residual risks associated with the
use of remote e-voting channels compared to other remote voting channels. These
principal risks include:
the compromise of voting devices, such as home computers, by viruses or other
malicious software
attacks by people with privileged access to the system, either system developers or system administrators (this is also a significant risk for supervised RIV
channels)
DoS attacks, which can have a particularly high impact given the short
timescales associated with elections
Summing up the findings of the Electoral Commission’s evaluation in [Com07c],
the 2007 pilots seemed to work. But the level of risk placed on the availability
and integrity of the electoral process was unacceptably high. There are wider issues
(related to the underlying security and transparency) that need to be addressed in
order for the benefits of pilots to take effect. One specific point of criticism stressed
by the Commission is the absence of a clear strategy. This lead to the situation that
promising attempts (such as the usage of pre-encryption and independent verification
services) resulting from the previous evaluation of the 2003 pilots, have not been
tried out any further. Therefore, the Commission currently does not recommend the
conduction of further pilots [Com07b].
40
5.2 Country Reports
5.2.5 United States
The U.S. Department of Defense kicked of the Federal Voting Assistance Program
(FVAP) in 1986. Its mission was to reduce the barriers of registration and voting for
American citizens who reside outside of the USA, especially military personnel and
their dependents. Both groups are covered by the Uniformed and Overseas Citizens
Absentee Voting Act (UOCAVA). There are different reasons for the American interest in RIV [JRSW04]. Applying for registration forms and absentee ballots from
the home county, receiving them, and then sending them back is a time-consuming
and unreliable process, and must be accomplished in a timely manner to avoid legal
deadlines. The process is especially hard for people who are mobile, or who are located at places with a poor mail service. This partly applies to a large amount of
American soldiers based in different regions of the world. Furthermore, due to the
U.S. system of majority voting (similar to Great Britain) past elections have shown
the importance of accurate and verifiable counting. Sometimes some hundred votes
effect the outcome of an entire election [Way01].
One of the first studies of RIV was conducted by the California Internet Voting
Task Force (CIVTF) that was commissioned by the Secretary of State in the year 2000
[For00]. It was also the first one to clearly articulate numerous security problems in
general. The Secure Electronic Registration and Voting Experiment (SERVE) was the
follow-up of a previous FVAP voting system called Voting Over the Internet (VOI).
VOI ignored key parts of the internet voting security problem by completely excluding
the citizen’s workstation from the security perimeter of the system. A report on VOI
published by the FVAP in 2001 recommended to continue the research for adequate
security measures to counteract especially the malicious software threat and denial
of service attempts. Disregarding the fact that 4 years after 2000 many security
problems mentioned by the CIVTF remained unsolved, and ignoring the result from
the VOI report, officials seriously considered SERVE [JRSW04].
SERVE was designed for deployment during the 2004 primary and general elections.
Its name (especially the term experiment) is misleading since it was intended for the
counting of real votes and not just a trial. It was planned to restrict it to overseas
voters and military personnel and additionally limit it to people who vote in one of 50
counties in the seven participating states (Arkansas, Florida, Hawaii, North Carolina,
South Carolina, Utah, and Washington). The program was expected to handle up to
100,000 votes over the course of the year, including both, primaries and the general
election (By comparison, approximately 100 million votes have been totally cast in the
2000 general election). But the eventual goal of SERVE was to determine a similar
system to be suitable for the future expansion to the entire population of eligible
overseas citizens, plus military personnel and their dependents. This population is
estimated to number about 6 million, so the 2004 SERVE deployment must be judged
as a prototype for a very large possible future system.
41
To participate in SERVE, an entitled voter first had to enroll, which had to be done
electronically if the voter was in possession of suitable military ID, or by presenting
suitable citizenship and ID documents face-to-face to a trusted agent (e.g. some sort
of official person similar to that of a notary public). Then, before being able to vote,
the voter had to register. Registration and voting were possible in one or two short
sessions from any PC connected to the internet. Requirements for participating were
a Microsoft Windows operating system, a web browser, JavaScript, either Java or
ActiveX scripting, and additionally it had to permit session cookies. SERVE was
designed as a web-based service. After establishing a connection voters were able
to register and vote through the web interface. SERVE required direct interaction
between the voting service and the Local Election Official (LEO) in the voters’ home
precincts. Thus, when people registered to vote, their information was stored on the
central web server for the purpose of a later download by the LEO (for an update of
its database). After a vote was cast the completed ballots were stored on the central server, and later downloaded by the LEO, who stored it for later canvass. The
communication between the user’s web browser and the voting application on the
central server was protected by using the encryption and authentication built into
the Secure Socket Layer (SSL) protocol. Once that connection was established, an
ActiveX control was downloaded to the voter’s PC, because the voting application
required functionality that was not available in current standard browsers. For Internet Explorer users, the ActiveX control ran natively on the voter’s machine. For all
others a Java applet ran to interpret the ActiveX.
In 2003 the FVAP assembled the Security Peer Review Group (SPRG) consisting
of a group of experts in computerized election security, whose job was to evaluate the
scheme of SERVE. Their report, published in 2004, consisted of technical criticism
of the scheme, and over and above criticism of the entire project [JRSW04]. After
the findings were published in the Washington Post the Pentagon discontinued the
project [Kea07]. Nevertheless, an expansion of the usage of RIV technology for the
UOCAVA citizens is still intended by the Department of Defense. As a new project the
Integrated Voting Alternative Site (IVAS) allowed eligible absentee voters to request
and receive their absentee ballots over the internet. Taking part in it the voter
could request a ballot via a secure connection to the IVAS website. After the LEO
approved the request, IVAS notified the voter via email that the ballot was available
to download. Next the voter could download and print the ballot, mark it by hand
and return it by mail to the LEO. IVAS was applied in the general elections in 2004
and 2006. In 2007, a report published by Department of Defense compliments IVAS
and calls the development of a secure RIV scheme possible without mentioning the
fundamental criticism of VOI and SERVE [oD07]. However, IVAS does not provide
any mechanisms to encrypt or authenticate ballots. Therefore Jefferson et al. call it
less secure than SERVE [JRS07]. In the same report they repeat the arguments of
2004, most importantly saying that the described vulnerabilities ’are fundamental in
42
5.3 Discussion
the architecture of the internet and of PCs and their software’.
Results
Evaluating SERVE, the SPRG found many possible vulnerabilities that could enable
attacks on the system. They ranged from the closed software and a lacking of VVPT
to a variety of cyber attacks such as insider attacks, DoS attacks, spoofing, automated
vote buying, or viral attacks on voters’ PCs. The group estimated the most serious
attacks to be very easy to perpetrate. Since the problems were based on the nature
of the system they did not recommend an overhaul. The great danger of a successful
large-scale attack lead to their recommendation of shutting down the development
of SERVE instead, and not attempting anything like it in the future until both the
internet and home computer infrastructure had been fundamentally redesigned. This
recommendation was repeated by Jefferson et al. in 2007 clarifying the fact that the
most dangerous vulnerabilities apply to every RIV scheme because the weaknesses
’cannot be eliminated for the foreseeable future and it is quite likely that they will
never be eliminated without a wholesale redesign and replacement of much of the
hardware and software security systems that are part of, or connected to, today’s
internet’.
5.3 Discussion
As the different experiences of countries with RIV in trials and binding elections
have shown, a state of secure and reliable application has not been reached so far.
All countries’ schemes had in common that the source code was not available to the
public. Therefore the transparency of the voting system, commonly an important
necessity for people’s trust, could only be partly established. That was the case for the
elections in Estonia as well as for the trials in Holland, Great Britain and Switzerland
and one of the reasons for the abandonment of SERVE in the USA. Since the firms who
designed the voting schemes in Great Britain and Switzerland were separately chosen
by each of the regarding counties there was no common level of security. Anyway,
Rivest [Riv02] states there are also advantages to a variety of voting technologies
within the same country. The first argument is that they provide resistance to an
adversary’s attack, as there is no common point of vulnerability for the whole system.
Secondly ways are needed to gain experience with new voting systems. One good
way is to allow individual counties to experiment with techniques that are different
from the state-wide norms. Another problem is the concentrated knowledge of a
scheme and its important secrets (like decryption keys) as seen in Holland. It is
not tolerable that the public must trust the vendors without any possibilities of
43
verification. Additionally, insider attacks are more likely, the shortcomings of a system
are definitely best-known to the people who designed it. Furthermore, a voting system
designed for a specific purpose is not scalable in the sense of transferring it to a
different context. There is a huge difference between the security requirements for a
small, unbinding or a large-scale, binding election. Due to its much higher importance
the latter definitely requires a rethinking of the design. One key factor of a good voting
system is the method of authentication. Estonia gains profit by its already enrolled
public key infrastructure. The Estonian form of severe authentication, based on a
secret and the possession of a smartcard shows big benefits compared to a password
based scheme (Holland, Switzerland, Great Britain, USA). Even more severe forms of
authentication, like biometrics, have not been used in any of the compared countries.
Another lesson learned regards the importance of election management. The different
steps of software development have to be followed and respected, the requirements
have to be defined clearly and understandable and the organization, certification and
evaluation of schemes must be conducted by a central authority with expert knowledge
rather than local voting officials. Especially the evaluation of the electoral committee
in Great Britain showed the importance of a system’s testing. Testing is already a
very important phase during normal software enrollment, but for security sensitive
systems it gains even more importance. And, as mentioned in several evaluations,
the absence of bugs does not proof its correctness. In addition, Great Britain and
the security evaluation of SERVE demonstrated the importance to keep in mind
the results of previous studies. The greatest correlation between the schemes of all
investigated countries are possible attacks based on the nature of the infrastructure
and platforms. The possibility of a denial of service (DoS) attack is always present,
and poses a big threat to the internet being an insecure network. While cryptography
can ensure privacy, integrity and authenticity it is not possible to eliminate the risk
of a malfunction of the internet. If the adequate servers are disabled by too many
requests and voters are prevented from casting their votes, an election is at stake.
Elections have the property of being temporally restricted. For this reason the voting
process has to be guaranteed within a certain time period. Within this period Estonia
monitored the network traffic with the intention to find out if a DoS attack has
occurred. But this is not a serious possibility of prevention. Two months after the
election, Estonia suffered a severe DoS attack shutting down many governmental and
administrative servers [Bus07]. This showed that in case of a distributed DoS (DDoS)
attack, there is hardly anything that can be done. At least as severe, however, are
the threats caused by insecure voting platforms. Every country report mentions the
unsolved risks of voting clients as a major problem. It will be explained in depth
during the next chapter.
44
In agreement the previous country reports as well as many other papers (for example
[For00], [Rub00], [Riv02], [VK06]) have identified current voting platforms as the
most problematic entities within the process of RIV. In the following chapter the
nature of the possible attacks is explained based on the characteristics of the used
platforms.
6.1 Characteristics of the Platform
Voting platforms for e-voting represent a highly complex recording entity that replaces
pen and paper of traditional voting schemes. For this thesis the voting platforms of
interest are PCs that run operating systems and software under control of the voter.
In contrast to DRE machines (that are more or less closed systems that count the
votes and locally run the voting application) the PCs of RIV act only as the interface
between the voter and the used voting software. Voting platforms and especially PCs
consist of hardware components that build a fundament for the software that runs on
top. A platform structure includes the processor, different memory entities as well as
input and output units. Input devices are typically keyboard and mouse while output
can be generated on a monitor or through a printer. However, the named devices are
only examples and far from being complete. The devices communicate with each other
over a bus and need drivers to be detected by the operating system. Talking about
PCs as multipurpose machines, the user typically installs applications for special
needs on top of this. Therefore the sum of hardware and software configuration is
extremely diverse. Most importantly its administration is the user’s private affair. It
is totally uncontrolled by official administration and possibly unmaintained by the
owner of the platform. As a result we must deal with new threats that cannot be
solved by traditional cryptography. So far the problem was often neglected. Most
voting schemes assume secure voting platforms and therefore only ensure secrecy and
the integrity of voting from the point thereafter (including the communication channel
and servers). For example [Sch00] hypothetically relies on trusted hardware and
operating systems. In reality, however, this is not the case. When [MD04] introduced
Common Criteria to RIV the usage of standard criteria to evaluate and certify internet
voting systems was their goal. But again, one necessary prerequisite consisted of the
45
used platforms being really secure. This is an example of the precariousity of the
topic.
6.2 Malicious Software
PCs have the drawback of being vulnerable to many influences. The typical and wellknown hazards are Trojan horses, viruses and computer worms. They are generally
referenced as malicious software (malware) because they intend to do diverse harm
to computers [Tan01]. The usage of other technical devices such as mobile and smart
phones as platforms for internet voting also face these threats. We have recently
experienced the first virus for mobile devices [BBC04] and it is quite realistic to expect
an increase of malware on such devices while they advance in computing power and
networking functionality.1
6.2.1 Trojan Horses
A Trojan horse is a seemingly innocent program that contains hidden code (malicious
payload) to perform other actions than expected by the user. In the case of RIV this
special feature could read the temporary files of a voting software and send them over
a hidden channel to the software’s author. Other possibilities include interference
with the voting process in order to change the voter’s choice before it is treated
cryptographically by the voting software and sent out to the collecting server and
the opening of backdoors that allow remote administration. In contrast to viruses
and worms that infect computers against their owner’s will, a Trojan horse is often
installed on purpose because of its appearance as a good program.
6.2.2 Viruses
Viruses are programs that (similar to biologic viruses) reproduce themselves by attaching their code to another program. Once the main program is started they infect
other programs on the machine. They also contain special payload that is executed
1
Nevertheless mobile phones are also vulnerable to other kind of attacks as well. Talking about
the Global System of Mobile Communication (GSM), a drastic scenario would be the shutdown
of the mobile services. This presents a threat for the principle of a universal election (where
no one is excluded) and is caused by the fact that mobile phones always communicate with the
closest base station. This base station could be operated by an attacker since authentication
during GSM only happens one-sided. The attacker would then stop the service because the
communication is not passed on to the base station controller. For more details on secure mobile
communication the reader is refered to [Eck04].
46
6.2 Malicious Software
afterwards. The damage scenario of the payload includes several threats. The code
can cause the consuming of computer’s resources until a full process table prohibits
any other process from starting. But it can also erase, modify, destroy, or steal files.
For an election scenario a virus is likely to be programmed with a specific target
depending on the nature of the voting system. At its beginning, a virus was spread
by infected files on floppy disks. There are many kinds of viruses distinguishable by
their different ways of execution. The most important examples are Companion, Executable Program, Memory Resident, Boot Sector, Device Driver, Macro and Source
Code Viruses. Companion Viruses are started instead of another program. Executable Program Viruses attach themselves to another program by overwriting, and
enhance them with a malicious feature. If the original program keeps on functioning
normally, they are also referred to as parasitic. Memory Resident Viruses hide in
memory and jump on a system call. As they do not cause a lot of disk activity,
they are less conspicuous and therefore harder to detect. Boot Sector Viruses used
to be very common. They overwrite a clean master boot record or boot sector and
are executed every time a computer is turned on. No further actions by the user are
needed. The device drivers of a computer system are usually loaded at start time. If
one of them is infected with a parasitic virus, the virus will always be officially loaded
at boot time from there on. Since drivers run in kernel mode this Device Driver Virus
can capture the system call trap vector. Macros are comfortable routines of programs
such as Word and Excel written in Virtual Basic and usually attached to other program functions. Macro Viruses are macros containing malicious code. They are fairly
easy to create, which means to write a virus of this kind less skills are necessary than
for the interference with boot sectors.
6.2.3 Internet Worms
Internet worms are typically self-replicating computer programs making usage of
bugs in network protocols, applications and operating systems. Unlike viruses, they
do not need to attach themselves to an existing program. Internet connections enable
infections of files outside the host system, possibly servers in a local network. But
the spreading of a worm can also happen by attaching an itself to an email and
broadcasting it to a mailing list. After the arrival and execution by an unskilled user,
the worm is released and might mail itself to every person noted in the user’s address
book. A nice subject line increases the probability of execution.
One of the first major internet worms was the Morris Worm (followed by the mass
mailers Melissa and Loveletter, Code Red and Nimda, two internet disrupting Windows worms, then the continued presence of the mass mailer in Sober, MyDoom,
Stration). As a result to the replication traffic they most definitely harm the functioning of a network in their attempt to spread. But the payload often contains
47
code that has other goals than just spreading the worm, including the deletion and
encryption of files or the previous mentioned sending of files via email. The installation or modification of a program with the intention of allowing to bypass normal
authentication or to secure remote access to a computer (backdoor) is also possible.
[Rub00] especially highlights that malicious payload and its delivery mechanisms
have advanced in sophistication and automation in the past couple of years. Naturally malware makes use of the detection escape mechanisms mentioned above. The
attacks have also become more sophisticated in the sense that they can do more
damage, are more likely to succeed, and disguise better than before. Besides they are
more automated because more and more toolkits have been developed to enable unsophisticated computer users to launch the attacks. While talking about the future of
malware Schneier differentiates a new manifestation of worms [Sch07a]. He mentions
’old-style’ worms were mainly written ’for fame’ by spreading as quickly as possible,
whereas newer worms’ programmers have other goals like taking over computers for
assembling botnets. A botnet consists of many computers that run a program (typically a worm) attaching them to common control infrastructure. To gather a large
botnet these worms spread more subtly and can sit dormant for a long time. Later
the botnet can be used for various purposes (e.g. DoS attacks, spambots, information
theft). Using the newer Storm worm (formerly Peacomm) as an example shows the
more sophisticated techniques in contrast to traditional viruses.
The delivery mechanism changes regularly. Spreading via email it accommodates the subject line to important news.
The worm’s payload morphs really quick (30 minutes), making typical antivirus
and intrusion detection techniques less effective.
Worms attack anti-spam sites that focus on identifying it.
Rather than having all hosts communicate to a central server or set of servers,
these worms use peer-to-peer networks for communication (making the botnet
much harder to disable).
6.2.4 Mobile Code
Another aspect while talking about client security is mobile code that might be used
for displaying the voting application. While viruses and worms enter the client platform without the voter’s knowledge and against his will, foreign code is often imported
and run on purpose by computer users. [Tan01] defines mobile code as ’programs that
are shipped from one machine to another for execution on the destination machine’.
There are many varieties of mobile code. One possible form is an applet. Applets
are software components that consist of a finite number of functions and run in the
48
6.3 Effects on RIV
surrounding of other applications (containers). The function of an applet usually expands the capability of its container (for example a web browser) by adding non-static
options that enable interaction with the user. In contrast to a servlet, applets only
execute on the client platform. Other examples include agents and PostScript files.
The biggest concern with mobile code is that an applet is imported by a process into
its address space. During its execution the mobile code is running as part of a valid
user process and inherits the user’s rights. Running applets as separate processes
looks like a good idea. But applets often interact with each other and with their
container. So running applets as different processes would make the concept infeasible. Sandboxing, interpretation and code signing present other methods of dealing
with applets in a more thorough way. Computer users, however, first have to get
accustomed to these mechanisms.
6.3 Effects on RIV
Our concern applies to influences threatening data confidentiality and integrity as
well as the system’s availability as a whole, because they affect the protection goals
of voting. Specifically a system’s unavailability potentially threatens the goal of
an election being robust. If the confidentiality cannot be guaranteed, it affects the
required anonymity whereas the lost integrity of a vote affects the overall accuracy
of the voting procedure. The named hazards do not exclude each other. They rather
cooperate in order to affect the election. One possibility of an attack vector consists
of a worm that smuggles hidden code into a computer system. Theoretically, the
code could then open a backdoor for remote administration of the PC, wiretap the
keyboard to get information about voting credentials, check upon memory entries of
the voting software or participate in DoS attacks - just to name a few. Sure enough
there are other possibilities. But attacks that remain unnoticed by the voter are not
the end of the line yet. With a PC, the voter can also generate receipts that are
unintended by the voting scheme (for example by taking screenshots) or generate
fake receipts to challenge an election. Unintended receipts pose an additional threat
to the protection goal of elections being receipt-free. We will show this in the context
of verifiable voting schemes in Chapter 7.2. To estimate the danger of these attacks
it is important to make the following clear: Elections have always been subject to
fraud. But in traditional elections, an attacker was not able to affect the outcome of
an election all by himself. To do so, the corruptness of the central tallying process,
or any other form capable to exercise massive influence, was needed. Voter coercion
and the tampering of ballots usually required physical presence. Therefore, this kind
of attack was hard to achieve on a large scale. RIV, however, makes fraud much
easier because vote tampering is now possible with the help of digital tools as named
above. Thus, the danger is much greater, since this can happen in an automated
49
way. Nevertheless the attacker can do so via the internet and does not need to be
locally present. As a result, anybody might radically alter election results (at least in
theory). This fact dramatically extends the known adversary model of elections. At
the bottom line, digital elections bear incredibly large risks that could be exploited
by foreign governments as well as single perpetrators.
6.4 Counteractive Measures
Firewalls have the purpose to prohibit the spreading of worms by closing irrelevant
ports of a computer system and signaling any ’strange’ behavior including access attempts by untrusted internet computers. They do not provide detection functionality.
Their security, again, depends on the computer user’s know-how. If one does not understand the meaning of a message there is a good possibility of access allowance.
Anti-virus software is the traditional protection mechanism against viruses. To
detect a virus it scans the local hard disk and RAM for known signatures. Nowadays
most vendors of anti-virus software expand the detection capability into other malware as well. Still it has the important drawback of being only able to find known
malware. A worm that hides very well while spreading and only executes its payload
after enough computers are affected, has a good chance to cause great damage. Once
known, the vendors will update their detection rules with its signature. The original
worm can only be detected, if people update their malware definitions regularly. Even
if detected, the elimination of the virus might not be achieved while the system is
running. The detection of unknown viruses and worms is possible by their behavior.
But these heuristically based functions are not reliable. Additional threats are posed
by new virus types. Retro Viruses for example, have the goal to limit the functioning
of firewalls and anti-virus software. Polymorphic and Metamorphic Viruses are programmed in a way that enables their mutation and the evolution to a next generation.
Variable re-encryption or source code mutation are very capable methods.
Intrusion Detection Systems (IDS) monitor the traffic caused by a computer system
and its applications for attacks and security breaches. Their utilization can help to
optimize the overall configuration of a system. To prevent, limit, or react to potential
damage it is required to detect preparative attacks in time. Network-based IDS use a
sensor to catch all packets that come to a network interface. Next, IDS analyze the
packets that cross the network, check if they contain suspicious content and decide
how to react according to signatures of previously stored scenarios. While interacting
with a firewall new rules could be created to block the originating IP address of
an attack. Another possibility is to send security alerts to the administrator of the
computer network or system. Host-based IDS work similarly but require a security
guideline by the operating system. Here the state of a computer system is monitored
50
6.4 Counteractive Measures
by checking if the dynamic behavior (e.g. changes to registry, temporary variables,
RAM, the file-system, log and kernel files) complies with the expected behavior. In
case of suspicious behavior the user is alarmed. The basis is formed by the assumption
that an intruder leaves detectable traces.
In order to set up a more secure computer system, users have to decide upon a
combination of the named measures. Out of the box protection entails additional
expenses whereas personal customization requires more experienced users. Once running the protective system has to be configured and administered. In this context the
user needs to configure the firewall, determine the right time to scan the system for
malware and keep the definitions up to date. Further the user needs to be aware of
the correct treatment of dubious emails. Altogether this is a task that overburdens
most regular computer users. In addition, the illustrated measures are only valuable
for known threats. Unknown attacks that have the purpose to interfere with a single
election and that are released just in time still pose a big threat.
51
Besides the risk of running malicious code the main drawback of electronic voting
platforms is that their functioning is not obvious to the voters. Talking about DRE
one faces the additional problem of tampered hardware chips that might include code
for an incorrect tallying of the cast votes. With regard to RIV the voting scheme’s
correct functioning might be severely restricted by insecure platforms and the involved
risks. The most severe problems were described in the previous chapter. Therefore
electronic voting platforms have to be generally referenced as being untrusted. In
order to develop strategies for more secure remote voting platforms a first step consists
of the attempt to make possible malfunctions visible. Trying to fulfill this purpose
the following section is dedicated to methods of detection. If no errors are detected
these methods can establish trust.
The methods of detection introduced here are test ballots and voter-verifiable protocols. Test ballots have the purpose to test the voting system before a counting vote
is cast on it. Voter-verifiable protocols pose a different approach. They also test the
voting system but do so under real conditions. For this purpose they provide voters
with a receipt that they can use for the purpose of verification. Then, in case of
encountering a problem during the election, voters can use this receipt to dispute the
election.
7.1 Test Ballots
To verify the correct construction of the ballot and the functioning of the tallying
servers, voters and voting administrators have the further possibility of testing the
system with test ballots. For this purpose they can cast one or several dummy votes
that have to be generated by the voting client and processed by the system. Doing
so the tally has to return the correct number of votes as cast. Similar to voterverifiable protocols test ballots might help to increase the voter’s trust in the system
by providing correct dummy results. If conducted by officials, test ballots can simply
be cast prior to the start of the real voting process. But the practicability issue
remains unclear, if the voter is supposed to cast the test ballot. This is the case
because the voting system requires a way to distinct between real and dummy votes.
Further it is beyond question that sophisticated malware could be developed such
53
that it is possible to distinguish between test and true ballots. Regardless to these
problems, test ballots present a simple method for detecting low-profile attacks that
might as well be caused by malicious software. In this context Opplinger notes that
’test ballots can also be seen as an intrusion detection system specifically designed and
used for RIV’ [Opp02]. In compliance with the following protocols test ballots only
make malfunctions visible. Therefore it makes sense to combine them with additional
preventative approaches.
7.2 Voter-Verifiable Voting Protocols
This section introduces four different voting protocols that also attempt to make up
for the lack of trust. None of the protocols prohibit attacks such as vote tampering or
the loss of privacy. Instead they make a big effort in enabling methods to detect the
prior. Their method of choice is to make a vote cast verifiable by providing physical
receipts that enable public auditing without violating voter privacy. Until now most
e-voting schemes tried to bypass printouts of the ballot because they could be used as
a proof for vote buying and coercion. This is not the case for the following protocols
because the printouts contain reduced information. Generally, the verification can be
either individual or universal. Individual verification consists of a proof method for
every voter ensuring that a vote was counted as cast. In contrast universal verification usually tries to proof the correctness of the complete tallying process to anyone
interested. Each of the protocols provides a different approach and achieves the goal
of a voter-verifiable voting protocol to a different extent. Being originally intended
for the usage in combination with DRE it is additionally attempted to sound the
possibility of an application for RIV. On this behalf the foundations of the protocols
are examined for possible problems. While presenting the protocols the term ’voting
system’ is used for both, voting machines and systems of RIV.
7.2.1 Neff’s Voting Scheme
The goal of Neff’s voting scheme is to gain universal verifiability for DRE. In the
last years the American public’s trust in correct tallying reached a low level [Fis04].
Neff’s scheme responds to this by making it possible to prove whether or not the used
voting protocol worked correctly, and especially whether or not the voting platform
did fulfill its job in a sound way. This is accomplished by providing the voters
with a strip of paper that provides receipt freeness since it does not reveal anything
about their choice, except on a personal basis. With this receipt and the printed on
information the voters can later verify whether their votes were correctly recorded.
The application of an anonymizing mixnet permits to verify if the tallying was correct
54
and the votes were counted as cast. So far the protocol is only intended for voting
machines, but an extension to internet voting might be worth considering. After the
protocol’s explanation some critical remarks are made about its possible drawbacks.
Protocol Functioning
Before explaining the protocol in practice, the voting system needs to be initialized.
For the computation of a master public key the trustees perform a distributed key
generation protocol. As a result the final decryption is only possible if all trustees of
the cryptosystem work together. Additionally a security parameter l is introduced.
This parameter determines the system’s level of security. The interaction of this
security parameter and the level of security will become clear in the following. For
reasons of simplification, the election is assumed to be a single race of n candidates
C1 , . . . , Cn . After choosing one candidate the voter has to communicate his decision
to the voting system. Let us assume this is candidate Ci with i being in range from
1 to n. The first action of the voting system is the construction of a verifiable choice
(VC) as an encrypted representation of the voter’s chosen candidate Ci . This can be
seen in Figure 7.1.
1
C1
0
2
1
1
.
.
.
Ci
1
1
0
1
1
1
1
1
0
0
...
1
0
0
0
.
.
.
0
...
1
.
.
.
.
.
.
0
l
.
.
.
.
.
.
.
.
.
Cn
3
1
.
.
.
1
...
0
1
Figure 7.1: Representation of a verifiable choice - Source: modified from [KSW05]
Precisely it is a matrix that consists of n rows (every candidate is represented by
one row) with l ballot mark pairs (BMPs). Each of the BMPs consists of an encrypted
ciphertext Enc(b1 , b2 ) of the plaintext bits b1 , b2 ∈ {0, 1}. By definition, for k = 1 . . . l,
i = 1 . . . n, j = 1 . . . n and i 6= j, the k-th BMP of an unchosen row j is Enc(bjk , ¬bjk )
and the k-th BMP of a chosen row i is Enc(bik , bik ). After decrypting the chosen ballot
row i again it only consists of pairs (0, 0) and (1, 1). Since all other unchosen rows
consist of the bit-pairs (0, 1) and (1, 0) the chosen candidate Ci is clearly indicated
and can be identified and counted by a tallying server. The encryption function in
this context has the requirement of being randomized and deterministic1 . The ballot’s
sequence number (BSN) and the hashed VC are then printed.
1
Deterministic encryptions always produce one cipher for the same plaintext and a given key. Of
55
Next the hashed VC and the BSN is printed as a receipt. Later this information
can be checked mathematically for its correct construction. In order to provide another level of verification the protocol tries to convince the voter that each BMP in
his chosen row i is of the correct form (bik , bik ) and on account of this was cast as
intended. For this purpose Neff’s scheme uses the concept of pledge bits. For the
chosen candidate in row i all BMPs contain Enc(bik , bik ) with bik being either 0 or
1. For each BMP in this row the pledge bit is simply the decrypted bik (which originally occurred on both positions of the BMP). The pledges have to be printed on
the receipt as well. Therewith the voting system has committed itself. Now the voter
has to select a challenge bit string ci for the row i of a chosen candidate. Each of
its bits represents one BMP, where the k-th bit equal to 0 means ’I want to verify
the left position’ and equal to 1 means ’I want to verify the right position’ of the
k-th BMP. This challenge is communicated to the system. Now the voting system
in turn has to provide a proof of correctness. This is done by the construction of an
opened verifiable choice (OVC) according to the voter’s challenge ci . It consists of
opened encryptions for one bit in each BMP. An opened encryption basically consists
of the voting system separately posting the encryption’s random factor (used during
the construction of the VC) for the positions indicated by the voter’s challenge. This
is sent to the bulletin board. From there the voter can receive the random factor
and start another type of verification known as the concept of fake and real proofs.
Thereby it becomes possible for the voter to individually verify the voting system
for its correct functioning. Together with the talliers’ public key he can encrypt the
received pledges using the random factor provided on the OVC and check whether
his own encryption really appears in the row for the chosen candidate and at the
positions corresponding to his chosen challenge. The BMPs of the unchosen rows are
also half-opened because the voter’s choice has to be hidden from anybody else. This
is referenced as a fake proof. Such a proof is indistinguishable from the real one. In a
real proof, the DRE commits to the pledge, then the voter enters a random challenge
and the DRE responds to it. In the fake version, the voter first gives the random
challenge and then the DRE commits and responds. Neither of the proofs reveals
any information about the vote itself. The purpose of the fake proof is the indistinguishable treatment of chosen and unchosen rows. Without it, the voter’s chosen row
is obvious for any observer (because then it is the only partly encrypted row on the
OVC). The opened encryptions are constructed according to the one of the chosen
row. To reduce the risk of vote buying and coercion, it is possible for the voter to
choose whether he wants to specify only the challenge for his candidate row ri or for
all of the unchosen rows as well. If he chooses not to do so, the voting system by
itself selects l -bit challenges cj for the unchosen rows rj , opens the encrypted BMPs
course the encryption hides the binary number but the visible pattern reveals the chosen row.
For the sake of a secret ballot this has to be prohibited. By using random elements during
encryption a given plaintext encrypts to one out of several possible ciphers which avoids the
appearance of a pattern.
56
according to them for the construction of the OVC, and finally sends the OVC to the
bulletin board for its publishing.
The overall protocol design is illustrated in Figure 7.1.
1.
2.
3.
4.
5.
6.
Voter → voting system:
Voting system → printer:
Voting system → bulletin board:
i
BSN, hash(V C)
p1 , . . . , pn
ci
c1 , . . . , cn
OVC
Table 7.1: Neff’s voting scheme - Source: modified from [KSW05]
For the purpose of changing a ballot the cheating voting system would have to
use BMPs of the form (b, ¬b) for the intentionally chosen row. But it has a very
low chance of getting away with it since it committed itself to the pledges (step 3)
before it gets to know the challenges of the voter (step 4). By telling the voting
system to uncover the left or the right position of a BMP, as it is done through the
challenges, chances are only P = 12 that a voter does not detect if the voting system
manipulated a BMP in his chosen row. Since this is done for all of the BMPs in this
row, the probability of the voter not detecting the cheating voting system is reduced
to P = 21l and depends on the previous mentioned security parameter l.
Adaptation to RIV
An adaptation of Neff’s protocol for an election conducted online might be possible.
Regarding the problem of insecure platforms precautions will become necessary. For
an implementation it is especially important that the protocol’s sequence does not
change. This is important for a correct functioning. In respect to a customization
the calculation of VC, hashed VC, pledges and OVC has to be done by the voting
software (most likely mobile code such as an applet). Therefore the software is now
the centerpiece of the verification purpose (together with the talliers, where nothing
changes). Verification can only happen if voters have a local printer connected to
their computers, which is assumed as a matter of fact. But while an official printer
might ensure the validity of a printout and prevent forgery through special paper,
this is not the case with private printers. Instead the printout needs to be signed by
the authentic voting software.
57
Security Problems
The risk of coercion and vote buying is prevented by the fact that the voter can
choose some/all challenges himself. If he could not do so someone might tell him
what candidate to vote for as well as the challenge to choose for the corresponding
row. Then the voter could proof that he carried out the order by presenting the
receipt (with the coercer’s challenge in the respective row). The coercer could finally
verify if the voter voted in the way he was told by encrypting the printed pledges with
the random numbers of the OVC and the available public key (the steps of regular
voter verification). The result should be the same as the one that is written onto
the bulletin board. While this is ruled out, there is another major protocol problem
which might be caused by a voting system that cheats by using BMPs that are not
conform to the standard encoding. This way, the malicious software might eventually
prevent someone from voting. For example the ballot’s encoding could be unclear in
the way that the row of an unselected candidate might consist of both possible BMPpatterns, identical bit pairs (1, 1) or (0, 0) and mixed bit pairs (0, 1) or (1, 0). During
the current state of the protocol, this would represent a violation of the protocol rules
that should lead to its termination. The voter has neither a chance of detection nor of
proofing its occurrence, so there is no full auditability. The problem might be solved
by allowing unchosen rows to be encoded by a mixture of identical and mixed BMPs.
But the extension would also stop random errors from being detected. At this point
the protocol needs to be clarified.
An additional problem regarding the ballot encoding exists in the possibility of a
malicious voting software using BMPs with identical bits - not only for the chosen
but also for the unchosen rows. If this is the case the talliers do not know which row
represents the original choice of the voter. So finally they would have to mark the vote
as being invalid. The main reason for the presence of this gap in the protocol’s current
state is the voter lacking a possibility to check for its occurrence. This circumstance
clearly represents more than an underspecification of the protocol since it fails to
provide the promise of full auditability.
As shown by Karlof et al. [KSW05], message reordering attacks and subliminal
channels form additional risks. If an attacker succeeds in compromising the voting
software by infiltrating code that leads to a different sequence of events, message
reordering becomes possible. Therefore the voting system has to learn the voters
challenge before computing the VC. Knowing the challenge for the chosen row enables
the voting application to calculate a fake proof for an unchosen line that is realized
by the voter as a real proof. This clearly breaks the security of the voting system.
Furthermore, subliminal channels are a possibility of attacking the principle of privacy. They are a problem if critical information can be hidden inside of an encrypted
ballot without being noticed. This is the case if several valid representations or en-
58
cryptions of the voter’s choice are possible. One prerequisite of subliminal channels is
the usage of bulletin boards that are public and anonymously accessible. If the voting
platform can choose the representation for the bulletin board, then this choice can
represent a subliminal channel. The detection of subliminal channels is very difficult.
A ballot might look perfect for anybody lacking specific knowledge of how to decode
the subliminal channel. In practice, adversaries could for example danger the voters’
privacy by including some Trojan code into the voting software. Then they could
sell the information on how to access the subliminal channel to a coercer. Neff’s
protocol is especially vulnerable to random subliminal channels. Random values are
used in many different ways to establish security during the protocol. For encryption schemes they enable attackers to extract information about encrypted messages.
However, the usage of random values makes subliminal channel attacks possible for
randomized encryption schemes, especially if the client platform can choose these
random values. Thereby different valid ballot representations become possible. As
shown earlier, each BMP is encrypted in a randomized way (for example ElGamal).
Let’s call the randomness that is used to encrypt b in the VC ω. For the OVC,
each BMP is partly decrypted and thereby reveals half of the random value ω. In
consequence a malicious voting system could embed |ω|/2 data-bits for each BMP
(or |ω| if it uses the same ω for both encryptions). For an election with 8 races and 5
candidates per race this adds up to a total of 51,200 bytes of information that could
leak per ballot. This is sufficient to embed the voter’s choice.
7.2.2 Chaum’s Visual Crypto Scheme
Chaum’s voting protocol focuses on creating transparency for DRE machines. By the
use of end-to-end auditing mechanisms, the correctness of the protocol can be proven
for each election step. For this purpose the scheme utilizes three different, pre-existing
elements. These are visual cryptography, mixnets and randomized partial checking.
The idea of visual cryptography was introduced by Naor and Shamir [NS95] with
the intention to cipher in a way that permits the human visual system to recover
an encrypted message. The basic functioning is similar to the one of see-through
numbers as a security feature on bills. But instead of printing parts of a splitted
image on either layer (where filling in the gaps is easily possible) visual cryptography
uses a more sophisticated method to avoid human associativity. Mixnets, as described
in Section 4.2.2, provide the anonymity of votes by covering the communication link.
Randomized partial checking is used to detect cheating trustees. The explanation
of Chaum’s voting scheme starts by giving an overview and a description regarding
the protocol’s implementation of visual cryptography. This is followed by a short
consideration of a visual cryptography scheme for RIV. The experienced security
problems of the Chaum’s protocol are mentioned in succession.
59
Chaum’s voting scheme uses visual cryptography. The underlying idea is to provide
the voter with an encrypted receipt he can use for verification, yet achieving receipt
freeness by not providing a proof for the original choice. The construction of the
receipts works as follows. Both layers are generated in such a way that only the
combination of both reveals the voter’s original choice. Therefore, the original choice
is encoded as two layers with a grid of m × n parity cells. Each of these parity
cells consists of four pixels, two black and two white, whereupon each color is sorted
diagonally. As a result only the following two parity cell patterns are possible.
Figure 7.2: The parity cell patterns - Source: [BR03]
Black pixels are opaque and white pixels are more or less translucent. As a result,
the combination of two different patterns returns a totally opaque one, whereas the
combination of two identical patterns returns the original semi-opaque one. The four
different combinations with their possible outcomes can be seen next.
Figure 7.3: Possible combinations of bit patterns - Source: modified from [Cha04]
The voter’s visual checking verifies whether the voting system calculated the layers
correctly and is the first verification step of the scheme. Figure 7.4 illustrates how
this mechanism combines two fuzzy looking sheets into a readable image that displays
the letter ’e’.
60
TOP layer
BOTTOM layer
RESULT
Figure 7.4: Bit patterns of the transparency layers, resulting image - Source: modified
from [Sta05]
In the first step of the protocol, the authenticated voter makes his choice and
submits it to the voting system by entering it with the given input device. Thereafter
the voting system generates two receipts by printing grids of black or white pixels
onto two transparent sheets. Each layer by itself looks like random noise and does
not reveal anything about the original choice. This represents the encryption. The
original choice can only be seen if both layers are aligned correctly. Using the visual
senses of the voter is advantageous for our purpose, because visual checking can
replace complex computations and thereby open the voting scheme to the public.
Next, the voter verifies whether the aligned receipts show the original ballot image.
If this is the case, the voting system proceeds by printing a ballot sequence number
(BSN) and some additional information on each receipt. This information is necessary
for the trustees’ decryption later on and refered to as the top doll and the bottom doll
(DT,DB)2 . Afterwards the voter is expected to choose one of the layers as a receipt.
This information is also passed to the voting system. In the protocol’s final step the
voting scheme appends signatures to the printed information. Importantly, the voter
is assured verifiable integrity by providing different signatures for the BSN and the
2
The name comes from the Russian Matrjoschka dolls. The latter consists of several dolls that are
hidden inside the biggest one. It has the additional characteristic that it can be disassembled.
By doing so the next smaller doll is uncovered.
61
receipt information. The BSN is signed by the voting system, whereas the signature
of the receipt information depends on the voting system’s layer specific key kx (where
x represents top or bottom). A schematic overview of the protocol is illustrated in
Table 7.2.
1. Voter → Voting sytem:
candidate choices
2. Voting system → Printer:
transparency images
Visual check of the correct construction. If successful, the protocol proceeds:
3. Voting system → Printer:
BSN, DB, DT
4. Voter → Voting system:
c, where c ∈ top, bottom
5. Voting software → Printer: signkc (BSN),
signko (signkc (BSN), DT, DB, chosen
transparency)
Table 7.2: Possible sequence for an adoption of Chaum’s scheme to RIV - Source:
modified from [KSW05]
Subsequently it is the voter’s turn to separate the receipts and destroy the unchosen
one in order to prevent the visibility of his original choice. The chosen receipt may
be used for the first verification step. Independent observers can test the authenticity
and correct construction of the receipts based on digital signatures and the calculated
doll. Just as well the voting system keeps only an electronic copy of the chosen receipt
and posts it on a bulletin board for additional verification. Thus, each voter can check
for the correct recording of his vote by looking for a copy of his receipt on the bulletin
board. The next step of the protocol consists of the tallying. In order to decrypt the
votes, a batch of posted votes is sent through a decryption mixnet. The output of the
mixnet consists of the original choices in anonymized form. The output of each mixing
step is also posted on the bulletin board for further auditing. Now the calculation of
the final tally is possible. To ensure its correctness, it may be recalculated by anyone
interested.
The achievement of Chaum’s protocol relies on the fact that, at the point of the
layers’ creation, the voter’s decision, whether to choose the top or bottom layer, is
not known. Therefore, the chance for the detection of a malformed layer is 50%.
Hence the probability for the detection of n malformed layers is 1 − 21n . Randomized
partial checking gives the same probability for the detection of a trustee altering a
vote. The reason for this is that each trustee executes two rounds of mixing. These
probabilities tend to become very small for an increasing number n. As a result, one
can say that the correctness of the final tally is strongly verifiable.
As seen, visual cryptography requires the voting system to construct a top and a
bottom layer such that a decryption is possible by placing them on top of each other.
62
For this purpose a different representation of the ballot image is needed. Technically
the combinations shown in Figure 7.3 can be illustrated by a truth table as well.
Therefore one of the parity cell patterns is considered as the binary digit ’1’ and
the other one as the binary digit ’0’. The operation that pictures the explained
watermark constraint is defined as the visual operator ⊕v . As seen before, three
different outcomes are possible. For the binary representation both of the semi-opaque
patterns are interpreted as being ’0’ and the fully opaque pattern is considered to be
’1’. This gives the following table:
0 ⊕v 0 = 0
0 ⊕v 1 = 1
1 ⊕v 0 = 1
1 ⊕v 1 = 0
In practice the ballot image needs to be represented in a way that the letters stand
out from the background. In our case letters are made up off semi-translucent and the
background of fully opaque pixel patterns (as can be seen in the resulting image of
Figure 7.4). Thereafter the image is translated into a binary representation whereas
semi-opaque patterns are interpreted as ’0’ and fully opaque patterns as being ’1’.
On this basis the binary representation of the ballot image (consisting of m × n
bits) is split into a top and a bottom part. The process is called checkerboarding
because it divides the image in top and bottom strings according to a checkerboard
with alternating black and white fields. Respectively the ’black’ binary digits form
the top string (B t ) and the ’white’ binary digits form the bottom string (B b ). As a
result each of the strings consists of m×n
bits.
2
By calculating l hashes from the signed BSN with different seed values, where l is
the number encryptions/decryptions performed by the trustees, we come up with l
variables dl . The xor of all the variables dl respectively forms the binary strings W t
and W b for top and bottom layer.
W t = ⊕dtl , W b = ⊕dbl
Sequentially another xor operation forms the binary strings Rt and Rb .
Rt = W b ⊕ B t and Rb = W t ⊕ B b
One can say that the swapping between the top and bottom enhances the encryption by diluting the ballot image with random noise woven in between the two layers.
In the final step Rt , W t and Rb , W b are checkerboarded again to form the top and
63
bottom layer. This time the checkerboard consists of alternating the binary numbers
of both strings to form a matrix with the original dimensions.
After the vote cast, both, voter and voting system, possess only the chosen layer.
In order to decrypt and obtain the original ballot image the talliers have to use the
value of the provided dolls printed on the receipt. The calculation of the dolls is
based on an encryption of the d hashes that were formed during the construction of
top and bottom layer. For i ranging from 1 to l, every di is encrypted several times
with all of the talliers’ public keys in succeeding order.
Doll = {dl−1{dl−2 {. . . {d1 {d0 }P KT0 }P KT1 . . . }P KTl−3 }P KTl−2 }P KTl−1
Only if all of the talliers cooperate and incrementally decrypt the dolls, it is possible
to uncover the d -variables that are needed for reconstructing the unchosen layer.
More details on the calculation of the layers, dolls and the details of verification can
be obtained from [Cha04], [BR03] and [Sta05].
Adaptation to RIV
Talking about the protocol’s functioning transferred to RIV, the basic steps are
skipped to rather concentrate on the occurrence of problems. Normally both layers
are printed out as two overlaid pixel patterns that can be checked visually according to the watermark example. If this works out, the voting system prints the dolls
and signatures onto the layers before the voter chooses one of them. The other one
is destroyed. A mapping of this onto RIV is hard for different reasons. First, the
visual check must happen in a different way. After the calculation of the layers it
could happen on screen, using a layer that was locally printed. Holding the printout
against the screen should reveal the originally chosen candidate. As before the visual
check requires both layers being exactly laid on top of each other as well as the same
resolution. If the visual check proceeds as expected (showing the compliance with the
original ballot image) the voter needs to signal his satisfaction to the voting system.
Now the voting system should print the dolls and signatures on both of the transparency images. Therefore, either the already printed receipt would have to be fed
into the printer again or another receipt enhanced with this information is printed.
Either way the voter gets a hold of both layers and most likely keeps them. This
definitely violates the original intention of preventing coercion. Normally the voter is
assumed to choose a layer and dispense the unchosen one. Again, the receipt needs
to be reprinted, this time with the adequate signature. Naturally the repeated printing affects the overall usability. In order to register a malfunction the voter would
for example have to compare reprinted information with the information that was
previously printed. Another important method of verification consists of using the
64
dolls on the printout for a calculation that shows whether they were correctly formed.
Originally this was supposed to happen regularly at the polling station. Employing
the protocol for RIV, the voter would have to visit a special verification place. Thus
another problem is raised by the fact that the inconvenience makes this form of verification more likely not to happen. For this reason a mechanism of digital verification
is anticipated.
Security Problems
One issue concerning the robustness of the protocol is the reliance in the trustees.
If only one trustee refuses to decrypt, the whole tallying process is in danger. This
problem exists for every decryption mixnet. To produce relief for this, Ryan [RS06]
advices to rather incorporate a re-encryption mixnet in combination with a keysharing threshold technique. Additionally the protocol’s complexity is noted to be
very high. Because the functioning is hard to understand for the average voter he has
to ’trust’ the corresponding mathematics. However, this is not an exclusive problem
of this scheme. Yet another problem is the possibility of malfunctions escaping from
detection. If the order of the voting protocol is slightly changed, the voter can be
fooled in his verification attempt. The cause might be a corrupt DRE as well as, in
case of the protocol’s adaptation for RIV, a tampered voting software. Either way,
the problem arises if the protocol behaves differently without attracting the voter’s
suspicion. In practice the voting software simply asks the voter if he chooses the top or
bottom layer before the calculation of the onion-values. Then the answer can be used
for falsely calculating the layer that most likely will not be checked. Normally the
voting system commits to transparency image, sequence number, and dolls before
the voter makes his choice between top and bottom. Here, the voter reveals this
important information too early and lets the adversary gain profit through his simplemindedness. This security issue was raised by Karlof et al. in [KSW05]. According
to them, Chaum’s protocol is also vulnerable to semantic subliminal channels. These
channels are of a different nature than the subliminal channels possible in Neff’s
protocol. Since here the scheme encrypts an image of the ballot rather than an ASCII
version, the voting system could embed subliminal challenge information by choosing
special representations of the ballot. One representation might be a special font. The
voter would not realize the occurrence because during verification he mainly cares for
the content. For him the form used for the purpose of representation is negligible.
7.2.3 Ryan’s Prêt à Voter Scheme
The goal of Prêt à Voter is to assure the voters of an accurate vote recording and
counting in the final tally while making the usability more intuitive. In contrast to the
65
first two schemes it uses optical scanning for the recording of a traditional vote. Prêt
à Voter as presented by Ryan [RP05] and Chaum et al. [CRS04] is based on Chaum’s
Visual Crypto scheme but applies a different way of representing an encrypted vote
value in the ballot receipt. Instead of the visual cryptographic technique the voters
can deal here with more familiar-looking ballots.
The preparation phase starts with an authority that creates the ballots. Therefore
the candidate list is changed from the election’s basic order. By doing so ballots get
a unique appearance. During Prêt à Voter each ballot consists of two parts: On the
left hand side the candidates are listed in random order of the official ballot order,
on the right side a voter can mark a certain row according to the position of a chosen
party or candidate. On the bottom this strip also contains a unique onion value that
is necessary for the extraction and counting of votes. A sample ballot can be seen in
Figure 7.5.
After the voter marked the according row, both parts are separated and the one with
the list of choices is destroyed. The other one is processed by the system (meaning
its digitalization by an optical scanner in the original version) before being handed to
the voter as a receipt. It does not present a proof of voting for a certain candidate or
party because each ballot paper looks different in the way that the list of candidates
appears in a random order. Thereby coercion and vote-buying can be avoided. As
long as the strips are not attached to each other the strip with the voter’s choice on
it does not indicate for what candidate a vote was cast. The protocol steps can be
seen in Table 7.3
Cyan
Turquoise
Pink
Grey
Maroon
Pink
Grey
Maroon
Turquoise
Cyan
7rj94K
(base ordering)
(LH−strip)
(RH−strip)
Figure 7.5: The filled in ballot - Source: modified from [RP05]
66
1.
2.
3.
4.
Voting system generates ballot: ballot = candidate list + vote
candidate choice
Vote is detached from the candidate list and scanned by the voting system.
Voting system → voter:
vote
Table 7.3: Protocol sequence of Prêt à Voter
After the election is closed, all processed receipts are sent to a central tabulation
server that posts the votes to a generally trusted bulletin board. Now voters have
the possibility to individually verify, if their vote was recorded correctly by looking
at these posts. To do so, one has to find the value of the onion printed on the paper
receipt and compare the location of his mark with the one published. To proof the
correct functioning, both of them have to be identical. As a final step the extraction
and counting of the vote takes place. Encrypted with the public keys of the tellers, the
basic candidate list can be reconstructed from the onion - assuming all of the secretsharing tellers cooperate. Only when cooperating the tellers can jointly conduct the
required anonymizing decryption mix to the batch of posted receipts. The output is a
batch of decrypted, anonymous votes ready to be interpreted. See [RP05] for details.
The overall tallying process appears in Figure 7.6.
The onions as printed on the voter’s receipt represent the only information that
helps to reconstruct the original candidate list from the order of the voter’s ballot.
The construction of the cyclic shift and the onion is shown next. It is the prerequisite
for a tallying and comparable to the construction of the dolls as explained in Section
7.2.2.
A basic necessity for the preparation of the onion are the seeds. For each ballot the
authority generates a unique and random one. If there are k tellers a seed consists of
Turquoise
Cyan
Grey
Pink
Maroon
Pink
Tellers
Maroon
Grey
Cyan
Turquoise
7rj94K
LH−strip
RH−strip
processed RH−strip
base ordering
Figure 7.6: Outline of the voting process - Source: modified from [CRS04]
67
2 ∗ k values that are called germs.
seed := g0 , g1 , g2, . . . , g2k−1
The offset of the candidate list from the base ordering is based on these germs. First
each of the germs is hashed (using a publicly known cryptographic hash function).
Here v represents the number of candidates on the list and determines the number
range to be Zv .
di := hash(gi ) mod v; i = 0, 1, 2, . . . , 2k − 1
The cyclic offset ⊖ that will be applied to the base ordering of the candidate list
as a number of cyclic shifts is now computed as the sum of these values. Afterwards
the personalized ballot is printed.
⊖=
2k−1
X
di mod v
i=0
To audit the tellers while ensuring the voters’ anonymity the scheme uses randomized partial checking. Therefore each teller performs two mixes and is provided with
two keypairs, each consisting of a private key and its public counterpart. Then the
onion is built by nested encryption as follows. To start with, D0 is generated which
is supposed to be a random seed that is unique for each ballot. The first teller uses
the first public key and encrypts g0 and D0 . The result is D1 which is encrypted with
the second public key. To form a verifiable mixnet 2 ∗ k encryptions are applied for
k tellers and the final result is D2k .
D2k = {g2k−1, {g2k−2 , {. . . , {g1 , {g0 , D0 }P KT0 }P KT1 . . . }P KT2k−3 }P KT2k−2 }P KT2k−1
This is illustrated graphically in Figure 7.7. Moving from the inside to the outside
each box represents an encryption with the appropriate teller’s public key. Finally,
the outer box represents the used onion value D2k .
68
g2k−1
...
g1
go
Do
= D1
= D2
= D2k
PK T0
PK T1
PK T2k−1
Figure 7.7: Layers of the onion - Source: modified from [CRS04]
To reveal the true votes from the batch of collected ballot strips the original order
first has to be recovered. Therefore, the construction of the onions has to be reversed.
To start with, r2k represents the encoding of the place where a voter placed his mark
on the ballot. Each teller needs to decrypt the message received by the previous
teller using its private keys. If the message was (r2i , D2i ), then stripping the onion by
one layer reveals D2i−1 and g2i−1 . After hashing the germ, di is calculated exactly as
above and subtracted from r2i to form r2i−1 . Now the two parts (r2i−1 , D2i−1 ) form a
new pair for the second round (each teller executes this operation twice with its both
keys). The resulting pair is passed to the next teller. After all of the tellers have
done so, the resulting r0 is the encoding of the voter’s mark in the base ordering of
the voters and ready to be counted. For a mixnet with n tellers 2 ∗ n mixing steps
occur. This scenario is illustrated in Figure 7.8.
ballots
votes
...
...
Teller n
Teller i
Teller 0
Figure 7.8: Anonymizing mix with n tellers - Source: modified from [CRS04]
Similar as for Chaum’s Visual Crypto scheme, Prêt à Voter allows universal and
individual verification. First of all, the correct construction of the ballot can be
verified. Therefore a random number of unused ballots is chosen. The matching
onions have to be decrypted by the tellers. Subsequently, the resulting germs are
returned to the auditor. Now the auditor can recalculate the onion to see if it matches
the printed one. Additionally he can recalculate the offset value and verify, if it
matches the one applied. These tests may be carried out by anyone interested since
the verification algorithms are publicly known. However, to keep anonymity this
method is only intended for blank ballots. In addition the vote recording can be
individually verified by each voter. This is done in the same manner as for Chaum’s
69
protocol. A voter just has to check the bulletin board for the correct appearance of
his receipt information. More generally, the tellers’ successive postings on the bulletin
board and the usage of randomized partial checking offer a verification of universal
kind.
Adaptation to RIV
Adopting the protocol for RIV seems theoretically possible. One advantage over
Chaum’s Visual Crypto scheme is that Prêt à Voter works without visual checks
that are hard to realize with home computers and standard printers. As for the
other protocols, the feasibility of verification partly solves the problems of insecure
platforms. After filling in the right side of the ballot it is printed as a receipt. In
order to avoid false receipts it needs to be signed by the ballot’s issuer. Again, the
printed receipt has to fulfill the purpose of being a proof of evidence in case the vote
cannot be found on the bulletin board. At the same time it makes the vote recording
verifiable. For the adaptation it is especially important to prohibit the printing of
the left side (candidate order) for the avoidance of coercion. This is troublesome
because the complete avoidance is impossible for a voting platform that is under
private control. A simple digital image (the voter himself can photograph his screen)
might already be sufficient to convince a coercer. A screenshot of the ballot with
both sides next to each other might present a piece of evidence for the voter’s choice.
If this proof is produced by the voter, it effectuates coercion, if it is done behind his
back (by some corrupt software), it threatens the principle of privacy. Consequently
it is necessary to find a way that makes such images useless. Chapter 6 pointed out
how uncontrolled environments especially endanger privacy due to their receptivity
for remote control. This kind of problems have not been treated and need to be
addressed if an adaptation is seriously considered.
Security Problems
Ryan and Peacock describe some potential weak points of Prêt à Voter in [RP06].
One of the mentioned problems is the openness for chain voting. In order to influence
other voters the coercer first needs to get a hold of a blank ballot (e.g. from a corrupt
election official). After marking it with his personal choice it is passed to a voter.
Along the way the coercer also promises the voter a reward, if he returns with a
blank ballot from the polling station. If the election scheme uses personal ballots,
the returned blank ballot fungates as a proof for the successful exercise of influence.
At the same time the coercer can now repeat the procedure. However, chain voting
is a problem caused by the poll-site based nature of a traditional voting scheme. It
does not apply to RIV because here virtual ballot forms are generated on demand
70
and cannot be exchanged. Other weak points are seen in the trust assumptions made
for authorities and voting software. Ryan and Peacock mention the required trust
of the authority not leaking confidentiality through seed based subliminal channels
as well as the possibility of invalid signatures, insufficient ballot verification, and the
unreliable destruction of the left-hand strips. Same as for Chaum’s Visual Crypto
scheme, the usage of a decryption mixnet also affects the robustness of the scheme.
For this purpose Ryan proposed to replace the mentioned decryption mixnet with a
re-encryption mixnet as described in [RS06].
7.2.4 Chaum’s Scantegrity Scheme
Similar to Prêt à Voter, Scantegrity intentionally provides a paper-based voting
scheme like optical scanning, with a verification mechanism as additional security
feature. Again, this security feature tends to win the voters’ trust by giving them the
chance to verify the complete processes of vote recording and tallying as a whole.
The general procedure as explained in [Cha07] consists of four stages including prevoting, voting, pre-audit and audit. During the pre-voting phase ballots are generated. They only differ in the letters attached to the candidates’ names and the
unique serial number that is printed on the upper right-hand corner. The letter A
on top and B underneath shows that it is the original candidate order, whereas B
atop and A underneath indicates a flipped order. For audition the scheme makes use
of a bulletin board. In the first column of the bulletin board the ballots’ sequence
numbers are listed, whereas the last column, on the far right, lists the election results,
filled simultaneously by posting the results. It is important to mention that the result column appears in random order and is therefore independent from the order of
the first column. The bulletin board consists of two additional columns in between,
containing digital envelopes 3. Each of these two columns has one digital envelope per
row and includes a space that is later filled with a letter. The first column of digital
envelopes on the left, adjacent to the serial number column, is in the same order.
The second digital envelope column has a row order that neither relates to the serial
number column nor to the results column, but it provides an extra level of indirection,
which allows effective audits still being able to preserve ballot secrecy. The encrypted
content of the digital envelopes is only decrypted during the audit phase. The initial
state of the ballots and the bulletin board can be seen in Figure 7.9.
3
All of the digital envelopes represent encrypted messages that can be decrypted by authorized
keyholders.
71
A
T. Jefferson
T. Jefferson
B
J. Madison
B
J. Madison
A
T. Jefferson
3403
J. Madison
A
T. Jefferson
3405
not swapped
swapped
A
not swapped
not swapped
3402
3404
B
A
T. Jefferson
B
J. Madison
A
T. Jefferson
B
J. Madison
3406
Pre−Voting Printing and Posting
J. Madison
swapped
swapped
3401
B
3401
?
3402
?
3403
?
3404
?
3405
?
3406
?
Ballots
Figure 7.9: Ballot structure and layout of the board - Source: modified from [Cha07]
During the voting phase the voters are supposed to make their choice, mark it on
the ballot, and detach the serial from the ballot. An important feature is the barcode
which is printed halfway on the serial segment, halfway on the main ballot. Thus, it
can be proven during the audit phase that serial segment and ballot at one point were
connected. Before the ballots are cast, the voters have to make a decision whether
they want to participate in the audit process or not. If they decide to do so they
have to make a note of (or at least remember) the letter next to their election choice.
This situation is illustrated in Figure 7.10. The reason for this will become clear in
the next paragraph.
3403
B
J. Madison
A
T. Jefferson
Ballot provided
to the voter
3403
B
J. Madison
A
T. Jefferson
A
What the voter leaves
in the ballot box
What the voter
takes home
Figure 7.10: Filled in ballot and obtained verification information - Source: modified
from [Cha07]
Scantegrity realizes voter verification as follows: If voters decide to verify the voting
process they can do so by looking at the public bulletin board. In the first column they
have to locate their personal sequence number. Right next to it, in the corresponding
second column, a letter can be found. This letter was extracted from the scanned
72
ballot and posted by election officials. It is obvious that it has to match the ballot’s
letter next to the voter’s chosen candidate. If the memorized and displayed letters
match, then, for a start, the vote was at least recorded. If voters believe that what was
posted on the bulletin board does not match the published letter, an in-person dispute
resolution can be conducted. To perform an in-person voter check of the ballot the
voter first needs to tell a trusted party the serial number from the chit. After issuing
a complaint, election officials have to locate the adequate ballot. Afterwards they
have to transfer it to an envelope that just reveals the upper right-hand corner with
parts of the bar code. Now the voter can take the kept sequence segment to see if the
present ballot is the correct one. The letter and election choice itself are hidden of
course. For still being able to verify the mistrusted letters, the selected ballot needs
to be transferred to an envelope that exposes both, candidate names and the letters,
but not the sequence number. The transfer could be done while the envelopes are
turned upside down and while a verifying person or trusted party is present. Now
another ballot with an analogue letter, but different candidate ordering, is treated
the same way. By doing so, the verifying person can be convinced that the processed
letter is the correct one, without revealing the secret vote. This is possible because
two partly decrypted ballots with the same letters marked can still present opposing
votes, and either one might be the adequate ballot. Without a second envelope the
sequence number could be matched to the vote.
Yet this is not a proof of the vote’s integrity. So far it was only shown that the
process of scanning worked out and the ballot was indeed recorded by the election
system. Due to the fact that the candidates are listed in random order, one letter
does not always represent the same candidate. To ensure that the letter ’A’ in the
picture above is truly counted as a vote for ’T. Jefferson’ another chain of evidence
is needed as the final auditing. It proceeds as follows:
On the bulletin board the sequence number and the second columns’ entries are
listed in the same order. During the course of the election, the results will be posted
in the last column but this time in random order. The third column’s entries neither
correspond to the order of sequence numbers. The path leading from a sequence
number to the corresponding result, is hidden by the information posted in the envelopes of column 2 and 3. Both of them can never be opened at the same time
because the inside numbers indicate the correct row of the next column and would
finally reveal the original vote (this would break the principle of secrecy). But only
one of the envelopes being decrypted would not be sufficient to connect a voter to
the matching vote. This rule is incorporated by the fact that some digital envelopes
of the second column are randomly opened (for example by tossing a coin) by the
election officials publishing the decryption keys. The information revealed consists of
a pointer to the corresponding row in the next column, and one of the strings ’same’
or ’differ’. Following the pointer, the entry in the subsequent column consists of a
pair of one letter and one envelope each. The letter here depends on the previous
73
string. The string ’differ’ changes the following letter and for ’same’ it remains. By
revealing the strings, everybody can verify that the posted intermediate letters of
the third column are correct. As said before, a complete path cannot be tolerated.
That is why the unreferenced envelopes are opened in the third column. After decrypting the information, a number points to the final result, and a string tells us
whether the final result (symbolized by the letters) is, again, same or different from
the letter in the previous column of the verification chain. In the end, each particular chain is partly opened in an unpredictable manner. Only in case of a spoiled
ballot the chain is completely opened. Here it can be seen that in case of an inverted
candidate order on the ballot there is an odd number of ’differs’ in the envelopes
(differ-same/same-differ), and that in case of an alphabetical order the number of
’differs’ is even (differ-differ/same-same). The procedure can be seen in Figure 7.11.
Audit completion
3401
A
3402
B
3403
A
3404
B=
Jefferson
2,differ
B
4,same
B
4,differ
B=
Jefferson
A=
Madison
A
3405
A
B
3,same
A=
Madison
3406
A
A
5,same
B=
Jefferson
Figure 7.11: Auditing the tally - Source: modified from [Cha07]
As voters were able to check the postings in column one (and the dispute resolution
procedure), it can be assumed with high probability that these letters were posted
correctly. For manipulation purposes one would have to post incorrect letters in the
second to last column, or incorrect results in the last one. But for every incorrect
posting there is a probability of P = 21 that it is detected (if the envelope leading to
it, is opened, it is revealed). Mathematically, this gives a negligible small probability
for n manipulated votes staying undetected.
Adaptation to RIV
Attempting to adapt the Scantegrity for RIV, the protocol starts with the ballot
generation. Doing so, we instantly face the problem of the ballots’ representation.
Looking at the traditional approach, the ballot needs to be digitalized while finding
an equivalent concept to the barcode (to enable a later proof for receipt and vote
belonging together). By assuming that the voting system still has to proof its trustworthiness strong interest consists to make it subject to appeal. In that case, the
74
authenticity of the receipt, and the clear classifiability of receipt and vote slip, are
mandatory. The authentication of the receipt can easily be assured with a digital
signature by the voting system. The classification however, of receipt and vote as one
entity, is rather complicated. A big problem is based on the fact that the anticipated
separation of the ballot into vote and receipt would make a previously attached overall
signature invalid. Even so there are other cryptographical measures that can accomplish the task, e.g. a hash of both parts could be calculated. In practice, the ballot is
displayed electronically by the voting software. After the voter has marked his choice,
the voting software needs to sign vote and receipt separately with the matching keys.
Then the receipt is passed to the voter by printing it on a local printer. At the same
time the vote is sent to the election server for further posting and processing. Since
the interest is directed towards getting an abstract idea, further details are skipped.
After the voting phase the receipt’s signature can be easily verified (and therefore
assure voter and authority of the ballot’s correctness) and the hash proofs that receipt and ballot have been attached at an earlier time. Anonymity can be ensured
by using a public bulletin board and partly opened verification chains as explained
in the standard variant. After finishing the tally, the pre-audit and audit phase take
place in the same way as before. Therefore, the feasibility of Scantegrity’s adaptation
to RIV seems practical. However, due to insecure clients loss of privacy and possible
coercion remain threatening and demand further attention.
Here, the main problem consists of the integration with RIV. In its original conception, it allows an end-to-end audit and the confirmation of the election results.
At this point, it is hard to imagine how the protocol steps can be implemented in
such a manner to come up with a practical voting scheme. Especially a proof for the
correlation between detached receipt and vote (as the rest of the ballot) is difficult.
Security Problems
For the same reason as for Prêt à Voter, chain voting is also possible for Scantegrity.
Chain voting is caused by a shortage of ballots during paper-based elections. Therefore the availability of sufficient blank ballots might circumvent the threat. For the
same reason as for Prêt à Voter, it is not seen as a security problem for the adaptation to RIV. Other problems are based on the the paper-based voting procedure.
The voting scheme is open to vote selling and coercion because a voter simply needs
to create an image of his filled in ballot. The built-in cameras of cellular phones suit
this purpose. However, this is not a unique problem of Scantegrity and applies to
other protocols as well. Some trust assumptions have to be made for Scantegrity as
well. For example the possibility of invalid signatures given by the voting system and
insufficient ballot verification by the authority have to be ruled out. A different kind
of problem is caused by the ballots’ sequence numbers. Thereby the confidentiality is
75
affected because the numbers could be used to determine individual votes. For this
reason many countries prohibit the unique labeling of ballots in their election laws.
7.3 Evaluation of detection methods
Test ballots help to detect constant malfunctions of the client platforms. If no errors
occur prior to an election this, however, does not indicate the correctness of the
succeeding election. Therefore test ballots, if at all, only convince the election helpers,
they will not affect the voters’ belief in the correctness of the election results. That
is why test ballots are not considered as the most valuable assurance benefit.
In contrast, the evaluated protocols break new grounds by giving voters the opportunity to individually verify their ballot cast. For this reason, all of them allow
a personal check by the voter that shows the correct recording. Requiring a trusted
bulletin board that displays the processed votes, every voter can compare if his receipt
is correctly displayed. If not, he can use it to dispute the election. Individually, the
protocols go separate ways to proof the correct ballot generation. Especially Neff’s
scheme, the Visual Crypto scheme and Prêt à Voter share that they provide voter
receipts that contain some sort of identification number and verifiable calculations for
another proof of correctness. Still all of the protocols achieve universal verification
by adding mechanisms for a transparent tallying.
Additionally paper receipts provide a potential basis for a VVPT that is valuable for
election verification in the traditional sense. However, this remains only a possibility
if the paper receipts carry the cast vote and are centrally collected. Then a recount
would be possible. It is especially hard for elections where the receipts need to
be collected from the voters first. For the introduced protocols only Scantegrity
and Prêt à Voter as proposed by Ryan in [Rya07] fulfill the required criteria for a
VVPT. Further it was shown that the robustness of Chaum’s Visual Crypto scheme
and Ryan’s Prêt à Voter are afflicted with the application of decryption mixnets.
However, this is not considered to be a serious problem, since it can be corrected by
using re-encryption mixes in combination with threshold encryption as proposed by
Ryan.
In detail, the protocols’ specific verification methodologies, encountered security
problems, original implementation as well as problematic issues of the adaptation for
RIV are shown in Table 7.4.
76
7.3 Evaluation of detection methods
Voting
Scheme
Intended
Usage
Methods of
Verification
Security
Problems
Adaptation
Difficulties
Neff ’s
scheme
Voting machines
Verifiable choice,
pledge
bits,
hashes, verifiable
mixnet
Mix of identical
and mixed BMPs,
message reordering,
subliminal
channels
Loss of privacy
and
coercion
resistance,
need
for local printer
Chaum’s
Visual
Crypto
scheme
Voting machines
Visual cryptography, dolls, verifiable mixnet
Reliance
in
trustees, message
reordering,
semantic subliminal
channels
Loss of privacy
and coercion resistance, need for
local printer and
high-resolution
print-out
à
Optical scanning
of paper ballots
Shifted candidate
order,
detached
candidate
list,
onions, verifiable
mixnet
Reliance
thority,
voting,
receipts
in
Loss of privacy
and
coercion
resistance,
need
for local printer
Scantegrity
Optical scanning
of paper ballots
Shifted candidate
order, dispute resolution, verifiable
mixnet
Reliance
thority,
voting,
receipts
in
Loss of privacy
and
coercion
resistance,
need
for local printer,
proof for correlation
between
receipt and vote
Prêt
Voter
auchain
illegal
auchain
illegal
Table 7.4: Comparison of the evaluated voter-verifiable voting schemes
77
After talking about the possibilities of fraud detection possible attempts to make up
for insecure voting platforms are of specific interest. For this purpose five possible
methods were found that are taken into account here. Two of them, namely trusted
hardware devices and secure voting software distributed on a live-CD distinct for
voting, can be dismissed due to cost issues and compatibility problems. Therefore
the following chapter concentrates on the remaining methods of code voting, mulitple
casts and trusted computing. Afterwards the different approach to each of them should
have become clearer.
8.1 Trusted Hardware Devices and Voting-CDs
Trusted hardware devices require special security hardware being connected to the
voter’s PC (that only provides the connection to the internet). This device has to
display the ballot, execute all of the cryptographic actions and must be closed for
external software. For these reasons, it is far more costly than a typical smartcard
reader. Taxing the actual costs for a usage during an election in Germany (assuming
60 million eligible voters and a unit prize of 50 euro) easily results in billions (even
excluding conceptual design). Live-CDs are far cheaper in terms of production costs.
In the simplest version they require a minimal, secure operating system with drivers
for the broadest possible support for network- and display devices. Instead of a special
voting software, applets could be used. Then the included browser would function
like the voting software. This raises the question of how the server is supposed to
distinct if the voter uses the ’clean’ or any other operating system. Another drawback
is based on the fact that live-CDs require the voters being able to boot it. Assuming
unskilled users with out-of-date hardware it seems only too probable that this cannot
be handled by the vast majority. Necessarily, special purposed hardware devices as
well as live-CDs need to be constructed by a trusted manufacturer. The development
of either one is highly complex and demands expert knowledge. See [Eck04] for more
details on the development process.
79
8.2 Code Voting
The treatment of the secure platform problem demands new measures. Verification
by itself does not solve the issue. One could be the previously mentioned voting in
controlled environments. Unfortunately this is contrary to our picture of RIV. For
this reason other security measures are necessary. Code voting is a very effective
way to solve the issues of privacy and integrity. It can protect against automatic
vote manipulation at the voter’s computer and thereby become very precious for the
purpose of making client platforms more secure. The chapter starts with a general
explanation before going into the details on how the practical implementation of code
voting might work.
Code voting was first mentioned by Chaum [Cha01] and is based on the creation
of code numbers. Opplinger referenced the idea as code sheets [Opp02]. The main
idea behind code voting was to safeguard voting privacy. During the voting process,
threats caused by spyware and other malicious software are considerably smaller if
the identification of a specific vote is not possible anymore. The usage of random
looking strings (codes) to cast a vote provides this feature. On the one hand the
integrity of the vote is protected because no one but the voter should know the
codes and their meaning. The integrity of the ballots is only at risk if the voter
lets others access his personal codes. On the other hand, this guarantees privacy
because someone monitoring the voter’s actions (for example through the usage of
remote administration) cannot draw a conclusion from the code that is entered. For
encrypted votes this is not the case because an adversary can access the vote before
it is cryptographically secured.
[Opp02] lists three different types of code voting:
In a full implementation, code numbers and verification numbers are used. After a vote was cast by entering the appropriate code, the server sends back a
verification number to the voter. With this code, the voter is able to verify that
the vote was cast to an authentic server and that it was properly registered
there.
A code number-only implementation excludes the server authentication and uses
only code numbers. Still the voter is advised to check the server’s public-key
certificate before voting. This is a risky procedure since many people do not
know what details they have to pay attention to.
The verification number-only implementation naturally cannot provide ballot
secrecy in the case of spyware and remote administration tools residing on a
computer. He also notes that without using code numbers it is possible for the
voter to ignore the verification numbers sent by the server. This is due to the
absence of a technical device that enforces manual verification.
80
8.2 Code Voting
The foundation for the usage of code voting consists of the creation of code numbers. In order to make the probability of malicious software guessing a code number
negligible, one prerequisite is that the codes have to be (pseudo-)randomly chosen
from a large range of numbers. If a number consists of ten bits then the probability
1
of correctly guessing it would be P = 1024
. This is believed to be difficult enough.
Ten bits can be represented by four decimal digits. Consequently, four digits are sufficient to encode a code number (leaving some redundancy to detect errors). Besides,
for a full implementation of code numbers the server additionally needs to generate
random confirmation codes. Of course, it is necessary for the codes to be generated
in a secure environment. One option for the composition of code numbers is a serversided generation. Therefore the server has to be located in a safe environment and
the generated data must be stored in a secure database. After their generation, the
codes have to be secretly distributed to the voters. This could be achieved through
a personalized code card (with code numbers as well as a voting and confirmation
code printed on it) that is transported by using postal mail. Electronic distribution
via the internet is no option. This is because a code sheet present on the local computer would enable residing malicious software to change the ballot according to its
creator’s interest1 .
Having accomplished the setup, voting itself consists of entering the appropriate
code number (the one that appears next to the candidate of choice on the code sheet)
into a field on the voting web page. For verification purposes, Helbach suggests
to use different confirmation codes, one for every possible choice [Hel07]. While
providing the voter with an accurate method of verification this protocol also asks for
trouble because it lacks the property of receipt-freeness. The combined possession of
confirmation-code and code card makes it possible for the voter to proof his choice to
an attacker. To return to receipt-freeness, the proposed voting scheme includes the
possibility of multiple casts. Multiple casts (also refered to as vote updating) make it
possible to revoke a possibly influenced vote by simply overwriting it. Of course, they
demand special forms for recognizing the actual vote that is to be counted (for more
details see Chapter 8.3). For protecting the confidentiality and integrity of the ballot
during transmission, the author of the scheme sees no necessity for encryption and
digital signatures. He rather sees the confidentiality of the original choice protected
’by the fact that the Transaction Authentication Number (TAN) is only a randomly
chosen handle to this name, known only to the central database and to the voter’ and
its integrity protected ’by the fact that the TAN’s are sparsely distributed in a large
number space’. Since authentication is done through a code as well no signature is
required. This means, someone observing the network traffic cannot gain information
1
All of the above, regarding generation, distribution and storage, applies for Transaction Authentication Numbers (TANs) as well. But there is a big difference in their impact for security. While
TANs only provide a method of authenticating a financial transaction voting codes are supposed
to provide integrity as well as privacy while the feature of authentication is also included.
81
about somebody else’s voting behavior because the vote is additionally covered until
the server-sided retranslation. Nevertheless, a correlation between voter and vote is
possible thereafter.
During the final phase of the voting process, the codes need to be retranslated into
the real candidates. In order to present the final tally, once the election phase is over
and all eligible and coded votes have been stored in a database, the tallying servers
need access to the retranslation schemes. Finding the correct retranslation scheme
obviously depends on the identification of the voters. As noted by Joaquim and
Ribeiro [JR07], this has the important drawback that cryptographic voting protocols
protecting voters’ privacy and preventing vote manipulation at server side cannot
be used anymore. Instead they suggest the usage of a paper based code card and
a voting card that is similar to a smartcard. Again, the distribution of the codes
is carried out on the code card. But this time the codes are only used for covering
the local communication between the voter and his voting card. This card carries
the private key of the voter as well as the public key of the election authority and
the retranslation codes necessary for translating secret codes into candidate codes.
After retranslation, the card is supposed to execute all cryptographic computations
in the trusted environment. The proposed protocol also uses a full implementation
of code numbers, but this time with two different confirmation codes. The first one
has to be entered by the voter. This requirement gives him a chance to additionally
check his selected code option before the vote protocol proceeds by transmitting the
information to the voting card. If it is correct, the entered code is then translated to
a true candidate code, ciphered with the election’s public key and signed with the
voter’s private key. Afterwards it is sent to the bulletin board. If the signature verifies correctly, the bulletin board publishes the signed and encrypted code and returns
a signed hash of the voter’s vote. The voting card releases the second confirmation
code (the confirmed-vote delivery code) only if the signed hash corresponds to the
issued vote. The confirmed-vote delivery code has to match the one printed onto
the voter’s code card and, in contrast to the prior protocol, is the same for every
successful vote delivery. For this reason, this model does not violate the principle
of receipt-freeness. It certifies only a correct sequence of protocol steps (rather than
the actual recording of a cast vote). Since the retranslation of codes does not happen server-sided this model approach can be embedded in any other cryptographic
voting protocol to achieve extended privacy and integrity for the entire election. A
sample implementation possibility consists of using re-encryption mixnet for creating
integrity and anonymity at the server side and code voting for the same on voting
platforms. Joaquim and Ribeiro suggest this before the votes are finally decrypted
and counted.
As mentioned before, code voting was used for the purpose of encrypting votes cast
with cell phones during the elections in the Swiss canton of Zürich. The advice for
an application during PC-based RIV was not further considered pointing out that
82
8.3 Multiple Casts
its possible usage was not user-friendly. Pilot schemes in GB also used codes for
the vote cast from cell phones but did not specify why they were not used for RIV.
The Netherlands have developed the mentioned prototype for a voting system. But
in practice codes are only used for the identification of the voter. Nevertheless, the
usage of code voting is strongly anticipated for the purpose of client security either
by a full or a code number-only implementation. The full implementation ensures
a verification mechanism not being necessary at all costs since verification could be
possibly provided by other means. But if it is used in the way as described above (with
the verification codes varying depending on the cast vote) the protocol turns out more
complex as additional security arrangements like multiple casts have to be taken. The
idea of using smartcards as a trusted anchor is not new (being the typical application
of a smartcard). In the context of voting, however, the voting card is definitely an
interesting idea that needs to be examined. The main counter-arguments are the
requirement of an available smartcard infrastructure with additional distribution of
hardware and skilled users. For these reasons, a possible deployment of this protocol
variant is expected to be rather impractical.
8.3 Multiple Casts
Multiple casts give voters the possibility of repeated voting in a timely distributed
way. In some countries this form of voting is already possible. Lately, they have been
used in practice with RIV during the Estonian elections. Our interest in multiple casts
is because they bear the possibility to make up for the problem of casting a vote from
potentially insecure platforms. Further they present a way to prohibit coercion. If
this applies, a voter can simply overwrite the vote. In the previous chapter, it could
be seen that multiple casts present an additional security feature for code voting. This
chapter starts by talking about the technical aspects, especially the details of different
implementations. In this context, some of the resulting problems are named, before
concluding how they provide a way to face the danger of uncontrolled environments.
The possibility of repeated voting allows voters not only a timely but also a locally
distributed vote cast until the end of the election day. Usually a voting phase of
several days forms the basis of multiple casts. During this phase, voters may vote for
an undefined number of times. The act of voting can either happen in the traditional
way or through online-voting by making use of the internet. At a certain point in
time the voting phase usually ends. This could be the final deadline for the entire
election. But another possibility is to allow mixed forms of voting (online, postal and
traditional). In that case, online voting could precede and the election day might be
dedicated to an additional paper-based voting in the polling station.
Volkamer and Grimm [VG06] list four different forms of multiple casts during online
83
voting:
Exclusive online voting
Exclusive online voting presents the most simple form of repeated voting. Authorized voters can vote as often as they want using an online voting channel.
Decision-taking before the election
Within this form, voters can either vote on paper or use an online channel.
This requires the voters to decide upon the channel prior to the election. Then
different electoral registers are built depending on the voters’ decision. This
creates a clear boundary that ensures the usage of one channel or the other. In
succession, authorized online voters can repeatedly vote whereas paper-based
voters can vote only once (using their postal voting ballot or voter card for a
vote cast at the polling station).
Decision-taking during the election
This form allows the voter to decide at any point of time during the election
how to cast his vote. Then, by casting an online-vote he ultimately decides not
to vote with a paper ballot. Online-voters can recast their vote ad infinitum.
At a certain time online polls are closed and an electoral register is printed that
lists everybody who has not yet voted. A basic condition for this form is that
voters receive both an authentication token for online voting and the typical
voting card for paper-based voting.
No need for ultimate decision-taking
In the case of the previous variant, online voters cannot react to the latest
political events and surveys because the polls close before the final election day.
In this form, remote votes and especially online votes can be cast until the end
of the election day. Only the casting of a ballot in the polling station could
terminate online voting earlier. In that case, officials have to be provided with
a method to somehow filter postal ballots and the ones cast online since voting
in-person is supposed to overwrite all others. There exists also the theoretical
possibility to allow an additional online voting after the occurrence of in-person
voting in a polling station. However, this last case is not considered as being
important since it does not help to adjust the previous mentioned problems.
In consequence, there are some questions that have to be addressed while considering multiple casts. First of all, there is the problem of how to assign the correct
casting time to a voter’s cast ballot. This is definitely a fundamental requirement.
Otherwise the tallying servers would not have a chance to recognize the ballots they
have to count. Neither the voter’s computer nor the tallying servers’ time fulfills
the requirement (the first one is too easy to be changed and the second might be
attached to a ballot after an instant transmission is prevented by an attacker). Instead there should be a mechanism that integrates a trusted timeserver for granting
84
8.4 Trusted Computing
reliable timestamps. Another problem arises in the context of fairness. Naturally it
is effected if only online-voters can cast new votes over and over while people that
cannot vote online (because they do not possess a PC) are excluded.
There are certain arguments for multiple casts such as the previously mentioned
overcoming of the fact that remote and early voters are not able to respond to shortterm political events, the reduced personal cost to cast a ballot by allowing the voter
to decide by himself at what time he wants to vote and the lower sensitivity of the
voting system to DoS attacks. But for our purpose, the main argument is that it
makes the entire voting system more stable. The reboot of a computer after a blue
screen in the middle of the voting process has the effect that the voter does not know
if the vote was counted or not. Normally, there is nothing that can be done in this
situation. With an implementation of multiple casts the voter could cast another vote
that (if the other was counted) updates the previous one. The same is possible in case
of a system breakdown due to other reasons. This shows that the feature of multiple
vote casting indeed helps to prevent manipulation attacks through malware. After
a voter identifies an incorrect system behavior he can now take measures. Serving
the purpose of identification, it has to be made clear to e-voters that they have to
reassure themselves whether their cast ballots are listed correctly on a bulletin board.
The verification schemes from above could fulfill this purpose. If verification does
not succeed, an additional vote cast from a different (hopefully more secure) voting
platform or even on paper might solve the issue. For the issue of privacy this is the
case as well. As Volkamer and Grimm put it, ’the information from the malicious
code cannot be used to break the election secrecy because the voter could cast later
on another ballot from another device’. By the same modality, multiple casts also
promise to make voting resistant against coercion.
The main idea of Trusted computing (TC) is the creation of a technology that allows
hardware and software to enforce certain rules the computer consistently behaves
by. In accordance to this, the original purpose of TC was the application of Digital
Rights Management (DRM). In the context of RIV, especially the Remote Attestation
(RA) of machines and programs running upon them could allow the certification of
a voting platform. This section begins with a general explanation of TC before it is
shown how the issue of insecure home computers could be theoretically solved using
RA. By presenting the prototype of a protocol with TC an illustration of a possible
implementation is tried. The examination concludes with some critical remarks.
As specified by the Trusted Computing Group (TCG)2 every trusted computing
2
The TCG develops industry standard specifications for trusted computing building blocks and
85
consists of a minimal Trusted Computing Base (TCB) that includes hardware and
software that is necessary to enforce rules established through formally stated security
requirements. If the TCB works as required there should be no way to compromise
the system security. As noted by Stumpf [Stu07] the TCB consists of a Trusted
Platform Module (TPM), a passive hardware module that is similar to a PC-bound
smartcard with the following functions:
Hardware-based random number generator (used for the key generation).
Hash calculation (essential for the trusted boot).
Hardware-protected memory (for storage of restricted usage keys).
Creation of signed integrity information.
Conventional
Operating
System
Online Voting
Unlike smartcards, the TPM is not migratable. It includes an Endorsement Key
(EK) and an Endorsement Key Certificate that allow the identification of the computer platform the TPM is associated with and it further offers a reporting function
that enables other components to receive a signed acknowledgment of the system’s
configuration. The latter allows the validation of whether the platform currently
has the desired configuration [Eck04]. Figure 8.1 shows the necessary elements for a
trusted voting platform. They consist of TPM, the system monitoring hypervisor, a
trusted software layer, and the software used for online voting.
Trusted Software Layer
Hypervisor
untrusted
trusted
Existing Hardware
TPM
Figure 8.1: Example for a trusted platform - Source: modified from [ASSV06]
Most importantly for building secure voting platforms, the TPM enables anonymous attestation. A prerequisite for this is the realization of a secure boot sequence.
It consists of the kernel of the platform’s operating system calculating hash-values
that depend on each other and the system’s configuration. The sum of these metrics
constitute a Chain of Trust. For the purpose of calculating the base value, the TPM
acts as the Root of Trust. Beginning with this calculation, also known as the Core
software interfaces across multiple platforms. The list of members includes major software and
hardware vendors (such as AMD, Hewlett-Packard, IBM, Infineon, Intel, Lenovo, Microsoft and
Sun) [TCG07].
86
Root of Trust Measurement (CRTM), the system subsequently calculates more checksums, one for every step of the boot sequence and signs them with the corresponding
Attestation Identity Key (AIK). The AIK is an internally created key signed by the
EK. To allow a trusted third party to see if the signed hashes truly originate from an
authentic TPM the AIK additionally needs a matching certificate issued by a trusted
Certificate Authority (CA)3 . As a result, AIKs serve as pseudonyms for various purposes. In Figure 8.2 the steps of the Chain of Trust consist of the CRTM as well as
gradual hash calculations for Read Only Memory (ROM), Basic Input Output System (Bios) and Master Boot Record (MBR), until the kernel of the operating system
is finally reached. The entire boot sequence is logged and stored in the Protected
Configuration Registers (PCR) of the TPM. For every step, the calculated hash code
has to be validated. The building of the Chain of Trust only succeeds if this succeeds.
After all, the system’s security strongly depends on the integrity of the Root of Trust.
If an incorrect value occurs the boot process should be stopped. But if correct, the
building of a secure path from the TPM to the corresponding security-sensitive application succeeds. Anonymous attestation is achieved by the voting platform sending
the hashed system configuration that is additionally signed with its AIK. The voting
application could then check the soundness of the AIK with the issuer of the certificate. Afterwards, it has to approve the metric of the system configuration. Only
then, the voting platform gets the permission to vote.
start
CRTM
hash
start
ROM
hash
start
BIOS
hash
start
MBR
hash
start
Kernel
Figure 8.2: Chain of Trust - Source: [Stu07]
Based upon this, the usage of TC requires an adjustment of voting protocols as
shown by Alkassar et al. [ASSV06]. Because the participating servers and clients
do not know each other voting protocols require methods of authentication. The
application of trusted platforms on client and server side allows the simplification
of potential protocols to encryption and signing for the establishment of a secure
communication channel. As described above, respective attestation is achieved by
exchanging the current platform configuration. In a first registration step, the remote
attestation protocol is conducted between voter and authentication server. In doing
so, they exchange their public sealing keys SKE and the result of the secure boot
that was stored in the PCR. Each of the messages is signed with the sender’s private
AIKD . Additionally, the certificate for the public AIKE is added. This gives the
receiver the possibility to have it validated by the originating CA. Afterwards voter
and server can check whether the configuration of their voting platform is satisfying
3
To certify the public part of the AIK, the user also needs to send the public EK to the chosen
CA. With this, the user’s platform can be identified. As a result, a corrupt CA might uncover
the identity of an AIK. For our purpose, a privacy respecting CA is assumed.
87
and whether it possesses the respective encryption keys.
1.
2.
V oter → Server1 :
Server1 → V oter:
signAIKDV (P CRV , SKEV ), CertAIKEV
signAIK S1 (P CRS1 , SKES1 ), CertAIK S1
D
E
In the next step, the voters have to provide a proof of themselves being eligible to
vote. This is done by sending an encrypted and signed message with their ID and
PIN code. With the valid signature, the client platform indicates to the voting server
that it is in the signaled state with the authentic voting software running on the
trusted platform. The decryption of this message is only possible for the server if this
is the case (because the TPM only then releases the decryption key). In response,
the server only replies with an encrypted and signed message consisting of the voter
ID and an ’ok’ if the server’s eligibility check has a positive result. Now the voting
software has to check this message by the same criteria. The registration phase only
completes in case of an ’ok’. In this case, the voting software proceeds and displays
the ballot.
3. V oter → Server1 : signAIKDV (encSK S1 (ID, P IN))
E
4. Server1 → V oter: signAIK S1 (encSKEV (ID, ok))
D
After acknowledging his decision the voter’s voting software first informs the voting
server of the ballot cast. Based on this information, the server can mark the corresponding voter in the electoral register to prohibit multiple votes. He additionally
answers the message by signaling that he has done so.
5. V oter → Server1 : signAIKDV (encSK S1 (ID, voted))
E
6. Server1 → V oter: signAIK S1 (encSKEV (ID, f lagged))
D
Before the final steps of the main voting protocol take place an additional attestation is necessary, this time between the voter and the tallying server. Here a
connection between TPM (comparable to the voter’s id) and the encrypted vote is
not tolerable because of the privacy requirement. For this reason, the voter uses different keys. As before, after the attestation protocol finishes the tallying server and
the voter have exchanged the platform configuration and the new encryption keys.
88
7. V oter → Server2 :
8. Server2 → V oter:
signAIKD′V (P CRV , SKE′V ), CertAIKE′V
signAIK S2 (P CRS2 , SKES2 ), CertAIK S2
D
E
The main voting protocol basically consists of two steps. One is the voter sending
the vote to the tallying server. The server believes that an authentic voting software
running on a trusted platform only sends the ballot if the voter’s right to vote was
checked during earlier protocol steps did happen. Afterwards the tallying server
signals the successful transmission by sending its ’ok’. Again, both messages are
encrypted and signed. Now the voting software can display the successful transmission
to the voter. After the election is over the stored votes only need to be decrypted
and counted.
9. V oter → Server2 : signAIKD′V (encSK S2 (vote))
E
10. Server2 → V oter: signAIK S2 (encSKE′V (ok))
D
The client software of a remote voting application needs to run on any voting platform, interact with the voter, and establish a connection with the voting server. The
attestation of the necessary hardware (I/O device drivers, network protocol stack and
network adapter driver) and present software demands metrics that must be calculated by a secure operating system. Without this, the concept of trusted platforms
would not be feasible.
Especially with the functionality of secure boot sequence and the possibility of
anonymous attestation TC theoretically provides mechanisms to achieve trustworthy
voting platforms. With TC, a client computer that runs certain malware could be
prevented from interfering with the voting software. Since TC also controls the internal communication sequence and, in the case of RIV, establishes a trusted path
between user and voting platform the voter’s private choices can neither be altered
nor read during the cast. Unwanted malicious software as well as foreign communication channels that are not part of the vote casting process could be detected and
would have to cause an instant protocol termination. Alkassar et al. argue that TC
not only prevents malware from accessing critical applications on the client computers, but that it also protects from corrupt voters and manipulated voting software.
Additionally, the sealing of the incoming messages by the voting server makes voting even more secure because it would make processing only possible for the correct
voting application on the appropriate platform.
While TC appears to be beneficial in theory, there are some serious issues that
remain critical in practice. When talking about a secure boot and the establishing of
89
a Chain of Trust it is important to stress that not every component of a system can be
covered. For example, most drivers are dynamically loaded and possess administrative
rights. It is an open question how to decide which components are critical. Vacancies
in the Chain of Trust are therefore more than likely. In consequence, it is possible for
malicious software to make use of applications that are covered [Eck04]. In practice,
this leads to the problem of acceptance. Voters that are prohibited from voting might
not understand the reason and feel excluded. Moreover, there are also technical
problems concerning the maturity of the currently deployed technology [SSS06] and
concerning the revocation of cracked machines [BCC04].
8.5 Discussion of the presented methods
Code Voting presents a simple way to react to some of the dangerous hazards named in
Chapter 6 by covering up the voter’s choice. Two different approaches of code voting
were presented during this chapter. One was the consistent usage of codes during the
overall voting process. In order to consider it, there needs to be a way to disassociate
the used codes from the identity of the voter while retranslating. The other possibility
facilitates smartcards. As a result, the codes cover only the communication of the
platform, namely between the voting software and an externally connected smartcard.
The usage of code voting is compatible with most voting protocols. We categorize the
usage of codes as an important improvement for guaranteeing the necessity of a private
and unaltered vote. Multiple casts are effective in adjusting the problems caused
by insecure problems as well as coercion. A precondition for this are possibilities
to detect them. Importantly, the recasting of a vote does not prevent election fraud
from happening. In addition, multiple casts make the voting system more complicated
because they require a safe implementation that prohibits voters to cast several votes.
At last, TC was tested for the same purpose. Theoretically, it provides a technical
innovation that re-organizes the functioning computer platforms such that unwanted
changes of system configuration can be detected. As a result, remote attestation
can help to proof the security of a platform to a verifier and the implementation of
other mechanisms could be omitted. Thereby voting protocols could benefit from
a reduced complexity. Apart from the fact that functioning and effects of TC are
highly controversial it can be seen as a mechanism that might effectively secure open
platforms (such as a PC) for vital applications (such as voting software) to run on.
90
9 Conclusion
DRE-based voting machines have earned a lot of criticism lately. Recent security
reports brought about a negative rebound that led to a declining usage in many
countries. This affected the perception of RIV as well, because it is also an electronic
voting scheme. So some of the mentioned criticism applies for both. The functioning here and there mainly relies on the adaptation of a secure voting protocol that
runs on top of a computer system representing the voting platform. This thesis has
demonstrated that especially the remote form of internet voting is even more endangered. It was made clear that, together with insecure networks, the design of client
platforms presents the major obstacle against RIV. This has not changed since the
first description of the problem in [Rub00]. Today’s computers suffer more than ever
from malicious software. It was shown how this might affect the principles of voting.
For this reason, PCs as client platforms for RIV currently cannot be considered a
trusted entity.
The easiest way to solve the problem would be to simply distribute the responsibility for the functioning of a voting platform onto the voters. However, talking about
voting and its importance for democratic systems as mentioned at the beginning of
the thesis, this is not an option. That is why conducting elections that enable a
secure vote cast by the principles of the specific electoral law is considered as a duty
of the government.
Transparency of the voting process is particularly important. Voting protocols
that offer verifiable voting respond to this issue. Individual verification can help
to eliminate personal worries whether a vote was recorded correctly. Vice versa it
might as well inform someone that a sent ballot has not been recorded. Assuming
that all other steps of the voting process work correctly, this is a promising method
for checking if one’s voting platform is properly functioning. Furthermore, universal
verifiability provides provable arguments for the correctness of electronic elections. By
giving voters the possibility to verify the recording of every vote as well as the correct
tallying, they can take on the role of election observers. A voter who does not trust
the voting system, but has access to methods for auditing it, might as well use them.
If he does not succeed in proofing the system wrong he might eventually change
his opinion. Consequently, mechanisms of voter-verification can create substantial
trust in electronic voting systems that are too complicated to be transparent. Our
attempts of adapting the chosen protocols for RIV have revealed different problems
91
9 Conclusion
that need to be regarded separately. However - all of them have in common that
an adaptation for a remote usage was unintended. Therefore the protection goal of
coercion resistance cannot be guaranteed.
In this thesis several strategies were presented that promise to bridge the gap for
typical client computers. Currently, the most promising mechanism for the prevention
of attacks on client platforms seems to be code voting. As has been shown, it succeeds
in achieving integrity and privacy through secret ballots for the process of RIV on
a fairly simple basis. Furthermore, it can be combined with most current voting
protocols, nearly independent of the voting style. The only prerequisite is a race
between a prior-determined amount of choices. So write-in voting is not supported.
Still code voting enables its combination with voter-verifiable protocols. Intending to
vote with codes, one would be confronted with a rather cryptic-looking ballot. Instead
of candidate names the voter has to deal with cryptic characters whose meaning first
needs to be looked up on a code sheet. Despite the criticism of bad usability, this can
be considered as a minor problem. To reveal the voter’s original choice the attacker
would need to get hold of the translation table. This means that by code voting, the
exposure of privacy is reduced to a level known from absentee voting. Due to the
nature of remote voting systems it is hard to do any better than this. A combination
of code voting with smartcards also makes a different implementation possible. Here
the decryption tables for the codes do not have to be stored in a central database.
Instead, they are distributed with the card. However, this is strongly related to legal
concerns such as the establishment of a countrywide smartcard infrastructure and
voters purchasing additional hardware such as smartcard readers. Other problems
consist of the unfulfilled protection goals of coercion resistance and completeness.
As mentioned before, so far most voter-verifiable protocols fail to solve the issue
of coercion resistance. In fact, Helbach [Hel07] refers to multiple casts as a good
measure to be used for the avoidance of vote selling. Intuitively it sounds reasonable
to eliminate coercion as well as other threats by simply overwriting a coerced vote.
But in practice it is no more than a measure of adjustment and does not prevent from
threats. Another severe effect can be seen in its impact on general voting behavior.
Instead of making a careful decision based on long-term personal views, voters might
start reacting to current affairs and the results of surveys. Its practice is neither
common for democratic elections nor for voting protocols. For these reasons the
usage is not advised. Promising in this context is the work of [Web06] and [MaKo06].
In the author’s opinion, code voting should be included in future RIV systems. The
main reason for this is its effectiveness in creating valuable security by straightforward
mechanisms. Verifiable voting is also promising, but requires further accommodation
for the safe use with remote systems.
Most likely the situation will change with the appearance of trusted computing
systems. It was explained how voting schemes might benefit from its usage. Most
92
importantly, the initiative is approved because of its promises to create confidence
in the platforms’ integrity and authenticity. In addition, TC helps to simplify voting protocols by providing the responsibility of trustworthy clients. But the correct
functioning cannot be verified with its own measures. For this and other reasons, TC
does not represent an option for the time being. Instead, the approach to client and
network security must be critically observed while trying to clarify the question as to
what extent definitions and other important aspects remain unclear.
Every amendment of the electoral law was accompanied by controversial discussions. As for every introduction of security critical mechanisms, promised benefits
and estimated negative consequences have to be weighed up against each other. The
promise of a better participation, and therefore higher legitimacy for a democratic
system, is surely tempting. But social and political scientists are doubting these arguments. Ewert et al. [EFK06] for example opine the view that the turnout of an
election is not affected by the necessity of a short walk to the polling station. They
believe that the state of a democratic system, and especially the importance of an
election, rather play a more decisive role. Carrying on this line of argumentation, the
reduction of personal costs is not so important.
Regardless of this question, the compliance with the election primitives is fundamental. The issue of secrecy has to be treated specially because it is hard for remote
voting systems to fully guarantee this protection goal. For absentee voting the constraint of secrecy has been tolerated because it is a supplemental form of voting, and
officially associated with strict regulations. Here, the benefits are more important
than the losses.
Meanwhile the prospect of RIV often remains unclear, because the broadness of
possible usage is not well defined. If, as often argumented, RIV is introduced as a
sequel to absentee voting (only with different means, and the participating group
defined by the strict guidelines mentioned before), it has to be measured by the same
rules. However, some arguments used for RIV point in the direction of establishing
it as a primary voting technique. In order to seriously achieve a cost reduction for
elections, economization would imply the elimination of traditional voting at some
point. Perspectively, the observed countries deal quite differently with this issue of
RIV. Estonia introduced RIV as an additional method of voting for all citizens. The
Netherlands and Switzerland are working on an introduction of RIV as a method
of voting for the citizens abroad only. The Electoral Commission of Great Britain
opposes any further pilots, because there is no general strategy for a modernization
of the electoral system. Additionally, the trials have shown that the aspired cost
reduction is questionable.
To find out about the voters’ acceptance of voting schemes that include preventative methods, as well as about mechanisms for verification, further testing is advised,
preferably during elections that are not legally binding (e.g. workers’ councils, univer-
93
9 Conclusion
sities’ boards or governing boards of social security institutions). Here, the proposed
methods can be further evaluated within borders of adequate control and limited
danger. With regard to the incapability of current voting schemes to fully guarantee
the principles of voting, it is necessary to dissociate from the broad usage of RIV
techniques for legally binding elections such as parliamentary elections at present.
94
Bibliography
[ASSV06] A. Alkassar, A. Sadegi, S. Schulz, and M. Volkamer. Towards Trustworthy
Online Voting. 2006.
[BB06]
Nadja Braun and Daniel Brändli. Swiss E-Voting Pilot Projects: Evaluation, Situation Analysis and how to proceed. In Electronic Voting 2006,
pages 27–36. Robert Krimmer, 2006.
[BBC04]
BBC. First mobile phone virus created. http://news.bbc.co.uk/1/hi/
technology/3809855.stm, 2004. last visited 05.18.2007.
[BCC04]
E. Brickell, J. Camenisch, and L. Chen. Direct anonymous attestation.
In Proceedings of the 11th ACM conference on Computer and communications security, pages 132–145, NewYork, NY, USA, 2004.
[Ben87]
J. Benaloh. Verifiable Secret-Ballot Elections. PhD thesis, Yale University,
1987.
[BN02]
Hubertus Buchstein and Harald Neymanns. Online-Wahlen, chapter Einleitung, pages 7–22. Hubertus Buchstein and Harald Neymanns, 2002.
[BR03]
Jeremy Bryans and Peter Ryan. A dependability analysis of the Chaum
digital voting scheme. Technical Report CS-TR-809, University of Newcastle upon Tyne, July 2003.
[Buc04]
Prof. Dr. Johannes Buchmann.
Einführung in die Kryptographie.
Springer, Berlin Heidelberg, third edition, 2004.
[Bun02]
Schweizerischer Bundesrat. Bericht über den Vote électronique - Chancen, Risiken und Machbarkeit elektronischer Ausübung politischer Rechte.
Technical report, 2002.
[Bun06]
Schweizerischer Bundesrat. Bericht über die Pilotprojekte zum Vote
électronique. Technical report, 2006.
[Bus07]
Nikolas
Busse.
Krieg
im
Cyberspace.
http://
www.faz.net/s/Rub4C34FD0B1A7E46B88B0653D6358499FF/
Doc~E8FC83492878245149FFE5322F9A5F182~ ATpl~Ecommon~Scontent.
html, November 2007. last visited 12.19.07.
[Car07]
Paul Cartledge. Ostracism: selection and de-selection in ancient Greece.
http://www.historyandpolicy.org/papers/policy-paper-43.html,
2007. last visited 12.14.07.
95
Bibliography
[Cha81]
David Chaum. Communications of the ACM, volume 24(2), chapter Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms,
pages 84–90. 1981.
[Cha83]
D. Chaum. Blind signatures for untraceable payments. In In Crypto’82,
pages 199–203. New York: Plenum Press, 1983.
[Cha01]
David Chaum. SureVote: Technical Overview. In Proceedings of the
workshop on trustworthy elections (WOTE’01), 2001.
[Cha04]
David Chaum. Secret-Ballot Receipts: True Voter-Verifiable Elections,
2004.
[Cha07]
David Chaum. The Scantegrity System - An Introductory Whitepaper
and Example. http://www.scantegrity.org/papers/whitepaper.pdf,
2007. last visited 12.4.07.
[Che07]
Jun Chen. Verifiable Mixnets Techniques and Prototype Implementation.
Master’s thesis, Darmstadt University of Technology, 2007.
[Com03]
The Electoral Commission.
Technical Report on the May 2003
pilots.
http://www.electoralcommission.org.uk/files/dms/
Copyofcoverandreport-final_11369-8944__E__N__S__W__.pdf,
November 2003.
[Com05]
The National Election Committee. E-Voting System. Technical report,
2005.
[Com07a] Election Process Advisory Commission.
Voting with confidence - Summary, Conclusions and Recommendations.
http:
//www.minbzk.nl/bzk2006uk/subjects/constitution-and/press_
releases?ActItmIdt=109259, 2007. last visited 11.14.07.
[Com07b] Electoral Commission. Electoral Commission calls for end to ’piecemeal’ election pilots.
http://www.electoralcommission.org.uk/
media-centre/newsreleasereviews.cfm/news/657, 2007. last visited
12.5.07.
[Com07c]
The Electoral Commission. Summary of Electronic Voting - May 2007
electoral pilot schemes. http://www.electoralcommission.org.uk/
files/dms/Electronicvotingsummarypaper_27194-20114__E__N__S_
_W__.pdf, August 2007.
[CRS04]
David Chaum, Peter Ryan, and S.Schneider. A Practical, Voter-Verifiable
Election Scheme. Technical report, University of Newcastle upon Tyne,
December 2004.
[dMV07]
Marie-Fleur Auf der Maur and Samuel Vontobel. Case Studies on Evoting. Master’s thesis, University of Freiburg, Switzerland, 2007.
96
Bibliography
[Dom07]
Mario Domgörgen. Vernetzte Demokratie. Internetwahlen in Deutschland.
Master’s thesis, Rheinische Friedrich-Wilhelms-University Bonn, 2007.
[Eck04]
Prof. Dr. Claudia Eckert. IT-Sicherheit. Oldenburg Wissenschaftverlag,
München, third edition, 2004.
[EFK06]
Burkhard Ewert, Nermin Fazlic, and Johannes Kollbeck. E-Demokratie
- Stand, Chancen und Risiken. http://www.bpb.de/files/5XSXDC.pdf,
2006. last visited 12.1.07.
[Feh07]
Martin Fehndrich. Briefwahl. http://www.wahlrecht.de/lexikon/
briefwahl.html, 2007. last visited 11.14.07.
[Fis04]
Thomas Fischermann. Neue Maschinen, neues Ergebnis? Zeit.de, 2004.
[FOO93]
A. Fujioka, T. Okamoto, and K. Ohta. Advances in Cryptology AUSCRYPT 1992, chapter A practical Secret Voting Scheme for Large
Scale Elections, pages 244 – 251. 1993.
[For00]
California Internet Voting Task Force. A Report on the Feasibility of
Internet Voting. Technical report, 2000.
[Ges07]
Hans Geser. E-Voting projects in Switzerland. http://socio.ch/
intcom/t_hgeser12.htm, 2007. last visited 09.16.07.
[Hel07]
Jörg Helbach. Secure Internet Voting with Code Sheets.
Proceedings Vote-ID, 2007.
[HJP05]
Engelbert Hubbers, Bart Jacobs, and Wolter Pieters. RIES - Internet
Voting in Action. 2005.
In Pre-
[HKM+ 07] J. Helbach, R. Krimmer, A. Meletiadou, N. Meißner, and M. Volkamer.
Zukunft von Online-Wahlen. Datenschutz und Datensicherheit, (31):434–
440, 2007.
[Hof07]
Dirk Hoffmann. Benchmarking of existing national legal e-business
practices.
http://ec.europa.eu/enterprise/ict/policy/legal/
2006-bm-cr/germany.pdf, 2007. last visited 11.14.07.
[Ins01]
Internet Policy Institute. Report of the Noational Workshop on Internet
Voting: Issues and Research Agendas. March 2001.
[Jes03]
Eckhard Jesse. Reformvorschläge zur Änderung des Wahlrechts. Wahlsystem und Wahlrecht, Aus Politik und Zeitgeschichte, 2003.
[JJR02]
M. Jakobsson, A. Juels, and R. Rivest. Making mix nets robust for electronic voting by randomized partial checking. In Proceedings of the 11th
USENIX Security Symposium, 2002.
[Jon03]
Douglas W. Jones. A Brief Illustrated History of Voting. http://www.
cs.uiowa.edu/~ jones/voting/pictures/, 2003. last visited 12.14.07.
97
Bibliography
[JR07]
R. Joaquim and C. Ribeiro. Code Voting Protection Against Automatic
Vote Manipulation in an Uncontrolled Environment. In Pre-Proceedings
Vote-ID, 2007.
[JRS07]
David Jefferson, Avi Rubin, and Barbara Simons. A comment on the
May 2007 DoD report on Voting Technologies for UOCAVA Citizens.
http://servesecurityreport.org/SERVE_Jr_v5.3.pdf, June 2007.
[JRSW04] D. Jefferson, A. Rubin, B. Simons, and D. Wagner. A Security Analysis
of the Secure Electronic Registration and Voting Experiment (SERVE).
January 2004.
[Kea07]
D. Keating. Pentagon Calls Off Voting by Internet. The Washington
Post, June 2007.
[Ker04]
Norbert Kersting. Online-Wahlen im internationalen Vergleich. In Modernes Regieren / E-Government, number 18, pages 16–23. Bundeszentrale
fü r politische Bildung, 2004.
[KMC+ 05] Joseph R. Kiniry, Alan E. Morkan, Dermot Cochran, Fintan Fairmichael,
Patrice Chalin, Martijn Oostdijk, and Engelbert Hubbers. The KOA
Remote Voting System: A Summary of Work To-Date. 2005.
[KP07]
David Knöri and Elisabeth Prader.
So funktioniert das Zürcher
E-Voting. http://www.infoweek.ch/archive/ar_single.cfm?ar_id=
15991\&ar_subid=3\&sid=0, 2007. last visited 10.26.07.
[Kru06]
Lucas Kruijswijk. I-voting with RIES analyzed. 2006.
[Kru07]
Paul Krugman. When votes disappear. http://www.truthout.org/
docs_2006/112406C.shtml, 2007. last visited 11.29.07.
[KSW05]
Chris Karlof, Naveen Sastry, and David Wagner. Cryptographic Voting
Protocols: A Systems Perspective. Technical report, University of California, Berkeley, 2005.
[MaKo06] Filip Zagó rski Mirosl aw Kutyl owski. Verifiable Internet Voting
Solving Secure Platform Problem. http://zagorski.im.pwr.wroc.pl/
felippo/papers/Verifiable_Internet_Voting.pdf, 2006. last visited
12.5.07.
[MD04]
M.Volkamer and D.Hutter. From Legal Principles to an Internet Voting
System. 2004.
[MG04]
Margaret McGaley and J. Paul Gibson. A Critical Analysis of the Council
of Europe Recommendations on e-voting, 2004.
[Mil72]
L.W. Milbrath. Political Participation. 1972.
[Nau07]
Frank Nauheimer. Development of a lattice based blind signature scheme.
Master’s thesis, Darmstadt University of Technology, 2007.
98
Bibliography
[Naz07]
Jose Nazario.
Estonian DdoS Attacks - A Summary
to
date.
http://asert.arbornetworks.com/2007/05/
estonian-ddos-attacks-a-summary-to-date, 2007.
last visited
09.10.07.
[Noh07]
Dieter Nohlen. Wahlrecht und Parteiensystem, volume 5. Verlag Barbara
Budrich, 2007.
[NS95]
M. Naor and A. Shamir. Visual Cryptography. In Proc. Advances in
Cryptology, Eurocrypt 94, pages 1–12. Springer-Verlag, 1995.
[oD07]
Department of Defense. Expanding the Use of Electronic Voting Technology for UOCAVA Citizens. http://servesecurityreport.org/
DoDMay2007.pdf, May 2007.
[oE04]
Council of Europe.
Legal, Operational and Technical Standards for E-Voting.
CoE Publishing, http://www.coe.int/t/e/
integrated_projects/democracy/02_activities/02_e-voting/01_
recommendation 2004.
[oE07]
Concil of Europe.
Statute of the Council of Europe.
url=http://conventions.coe.int/Treaty/EN/Treaties/Html/001.htm,
2007.
[oG07a]
State of Geneva. E-Voting. http://www.geneve.ch/evoting/english/
welcome.asp, 2007. last visited 12.15.07.
[oG07b]
Federal Ministry of Germany. Online-Wahlen. Lexikon der Innenpolitik,
http://www.bmi.bund.de, 2007. last visited 10.23.07.
[oG07c]
Federal Ministry of Germany. Wahlgeräte. Lexikon der Innenpolitik,
http://www.bmi.bund.de, 2007. last visited 11.13.07.
[oJ07]
German Federal Ministry of Justice. Verordnung über den Einsatz von
Wahlgeräten bei Wahlen zum Deutschen Bundestag und der Abgeordneten des Europäischen Parlaments aus der BRD. http://bundesrecht.
juris.de/bwahlgv/index.html, 2007. last visited 11.14.07.
[Opp02]
Rolf Oppliger. Addressing the Secure Platform Problem for Remote Internet Voting in Geneve, 2002.
[oS07]
California Secretary of State. Top-To-Bottom-Review. http://www.sos.
ca.gov/elections/elections_vsr.htm, 2007. last visited 11.14.07.
[OSC07a] OSCE/ODIHR. Republic of Estonia, Parliamentary Elections, 03.04.07,
June 2007.
[OSC07b] OSCE/ODIHR.
March 2007.
The Netherlands, Parliamentary Elections, 11.22.06,
99
Bibliography
[oZ07]
City of Zurich. E-Voting Demo. http://evotingdemo.zh.ch, 2007. last
visited 10.26.07.
[Pro03a]
EU Cybervote Project. Final Report. http://www.eucybervote.org/
MSI-WP6-D21-v1.0.pdf, 2003. last visited 10.21.07.
[Pro03b]
EU Cybervote Project. Report on Review of Cryptographic Protocols
and Security Techniques for Internet Voting. http://www.eucybervote.
org/TUE-WP2-D6V1v1.0.pdf, 2003. last visited 10.21.07.
[PvH07]
Wolter Pieters and Robert van Haren. E-Voting Discourses in the UK
and the Netherlands. 2007.
[Riv02]
Ronald L. Rivest. Electronic Voting.
SpringerVerlag, LNCS 2339, 2002.
[Rja02]
Zuzana Rjašková. Electronic Voting Schemes. Master’s thesis, Comenius
University, Bratislava, 2002.
[RP05]
P. Y. A. Ryan and T. Peacock. Prêt à Voter: a Systems Perspective.
Technical report, University of Newcastle upon Tyne, 2005.
[RP06]
P. Y. A. Ryan and T. Peacock. Threat Analysis of Cryptographic Election Schemes. University of Newcastle upon Tyne, Computing Science,
Technical Report Series, No. CS-TR-956, 2006.
[RS06]
P. Y. A. Ryan and S. A. Schneider. Pret a Voter with Re-encryption
Mixes. In European Symposium on Research in Computer Security, number 4189 in Lecture Notes in Computer Science. Springer-Verlag, 2006.
[Rub00]
Aviel D. Rubin. Security Considerations for Remote Electronic Voting
over the Internet. Communications of the ACM, 2000.
[Rya07]
P. Y. A. Ryan. Pret a Voter with a Human-Readable, Paper Audit Trail.
University of Newcastle upon Tyne, Computing Science, Technical Report
Series, No. CS-TR-1038, 2007.
[Sch00]
Berry Schoenmakers. Fully Auditable Electronic Secret-Ballot Elections.
http://www.xootic.nl/magazine/jul-2000/schoenmakers.pdf, 2000. last
visited 11.29.07.
[Sch02]
Hermann Schmitt. Second-Order Elections to the European Parliament: Is E-Voting the Solution? http://www.mzes.uni-mannheim.de/
publications/papers/HS_Florence.pdf, 2002. last visited 11.28.07.
[Sch07a]
Bruce Schneier. Gathering ’Storm’ Superworm Poses Grave Threat to PC
Nets. http://tinyurl.com/2xevsm, 2007. last visited 11.23.07.
[Sch07b]
Jörn Schweisgut. Elektronische Wahlen unter dem Einsatz kryptografischer Observer. PhD thesis, Justus-Liebig-University Gießen, 2007.
100
Financial Cryptography ’01,
Bibliography
[Sha79]
Adi Shamir. How to share a secret. Communications of the ACM, November 1979.
[SHNR06] G. Skagestein, A. Haug, E. Nødtvedt, and J. Rossebø. How to Create
Trust in Electronic Voting over an Untrusted Platform. In Electronic
Voting 2006, pages 107–116, Bonn, 2006. Robert Krimmer.
[Smi05]
Warren D. Smith. Cryptography meets voting. 2005.
[SP06]
Krishna Sampigethaya and Radha Poovendran. A framework and taxonomy for comparison of electronic voting schemes. Computers Security,
25:137–153, 2006.
[Spe07]
Tom Sperlich. Zürichs e-Voting-Projekt erhält Auszeichnung der Vereinten Nationen. c’t - magazin für computertechnik, 2007.
[SSS06]
Ahmad-Reza Sadeghi, Marcel Selhorst, and Christian Stüble. TCG Inside? A Note on TPM Specification Compliance. In Proceedings of the 1st
ACM Workshop on Scalable Trusted Computing, Fairfax, Virginia, USA,
November 2006.
[Sta05]
Julie Ann Staub. An Analysis of Chaum’s Voter-Verifiable Election
Scheme. Master’s thesis, University of Maryland, 2005.
[Stu07]
Frederic Stumpf. Attestation eines TC-geschü tzten Systems. Lecture
notes of the CAST Workshop on Trusted Computing, May 2007.
[Tan01]
Andrew S. Tanenbaum. Modern Operating Systems. Prentice Hall, Upper
Saddle River, NJ07458, second edition, 2001.
[TCG07]
TCG.
About the Trusted Computing Group.
https://www.
trustedcomputinggroup.org/about/, 2007. last visited 12.7.07.
[Thi07]
Siegfried Thielbeer. Im Wohnzimmer wählen. FAZ, (232), October 2007.
[Tra07]
Ian Traynor. Web attackers used a million computers, says Estonia. http:
//www.guardian.co.uk/international/story/0,,2082584,00.html,
2007. last visited 09.10.07.
[Tre05]
Alexander H. Trechsel. Report for the Council of Europe E-Voting in the
2005 local elections in Estonia. http://www.coe.int/t/e/integrated_
projects/democracy/02_Activities/02_e-voting/00_E-voting_
news/FinalReportEvotingEstoniaCoE6_3_06.asp, 2005. last visited
12.16.07.
[Tre07]
Alexander H. Trechsel. Internet voting in the March 2007 Parliamentary
Elections in Estonia. Report for the Council of Europe, 2007.
[UMM06] Ülle Madise and Tarvi Martens. E-Voting in Estonia 2005. The first practice of country-wide binding Internet voting in the world. In Electronic
101
Bibliography
Voting 2006, pages 15–26. GI Lecture Notes in Informatics, Robert Krimmer, 2006.
[VG06]
M. Volkamer and R. Grimm. Multiple Casts in Online Voting: Analyzing
Chances. In Electronic Voting 2006, pages 97–106, Bonn, 2006. GI Lecture
Notes in Informatics, Robert Krimmer.
[VK06]
Melanie Volkamer and Robert Krimmer. Die Online-Wahl auf dem Weg
zum Durchbruch. Informatik Spektrum, (29):98–113, 2006.
[vP03]
Volker von Prittwitz. Vollständig personalisierte Verhältniswahl. In
Wahlsystem und Wahlrecht. Bundeszentrale fü r politische Bildung, 2003.
[Wag06]
David Wagner. CS 276: Cryptography - Lecture 24. http://www.cs.
berkeley.edu/~ daw/teaching/cs276-s06/l24.ps, April 2006. last visited 11.10.07.
[Way01]
Erika Wayne. Election 2000 Chronology. http://www.law.stanford.
edu/publications/stanford_lawyer/issues/60/election2000_
chronology.html, 2001. last visited 10.5.07.
[Web06]
Stefan Weber. A Coercion-Resistant Cryptographic Voting Protocol Evaluation and Prototype Implementation. Master’s thesis, Darmstadt
University of Technology, 2006.
[Wil07]
Hans-Urs Wili. Änderung der Bundesgesetzgebung über die politischen
Rechte per 1.1.2008 in Kraft gesetzt. http://www.bk.admin.ch/themen/
pore/evoting/00773/index.html?lang=de, 2007. last visited 12.16.07.
[Zie06]
Peter-Michael Ziegler. Italien stoppt Wahlcomputer-Projekte. c’t - magazin für computertechnik, 2006.
102
A Abbreviations
AIK
Attestation Identity Key
ATM
Automated Teller Machine
BIOS
Basic Input Output System
CA
Certification Authority
CIVTF
California Internet Voting Task Force
CoE
Council of Europe
CRTM
Core Root of Trust Measurement
DDoS
Distributed Denial of Service
DoS
Denial of Service
DRE
Direct Recording Electronic
EC
European Commission
EK
Endorsement Key
EPROM
Erasable Programmable Read-Only Memory
FVAP
Federal Voting Assistance Program
FCC
Federal Constitutional Court
IDS
Intrusion Detection System
IVAS
Interim Voting Assistance System
LEO
Local Election Official
MBR
Master Boot Record
OVC
Opened Verifiable Choice
PCR
Protected Configuration Registers
PIN
Personal Identification Number
103
A Abbreviations
104
PK
Public Key
PKI
Public Key Infrastructure
RA
Remote Attestation
RIV
Remote Internet Voting
ROM
Read Only Memory
SERVE
Secure Electronic Registration and Voting Experiment
SK
Sealing Key
SPRG
Security Peer Review Group
SSL
Secure Socket Layer
TAN
Transaction Authentication Number
TC
Trusted Computing
TCB
Trusted Computing Base
TPM
Trusted Platform Module
UOCAVA
Uniformed and Overseas Citizens Absentee Voting Act
VC
Verifiable Choice
VOI
Voting Over the Internet
VVPT
Voter Verifiable Paper Trail
ZKIP
Zero Knowledge Interactive Proof

Secure Client Platforms for Remote Internet Voting

Transcription

Similar documents

Soziale Netzwerke - Hochschule Augsburg

URL - David Terhart

Deluxe mit Sängerin

Freie und Hansestadt Hamburg Bezirksamt Altona