8/3/2019 Designing Electronic Voting
1/73
8/3/2019 Designing Electronic Voting
2/73
Contents
Introduction 3
Aims of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 System Analysis 8
1.1 Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Generic Requirements . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Conventional Elections . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 On Revoking Ballots . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6 E-voting Requirements . . . . . . . . . . . . . . . . . . . . . . . 15
1.6.1 Functional Requirements . . . . . . . . . . . . . . . . . . 151.6.2 Non-functional Requirements . . . . . . . . . . . . . . . 18
2 System Design 20
2.1 Theoretical Basis . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Model of the Real World . . . . . . . . . . . . . . . . . . 21
2.1.2 Electronic Voting Scheme . . . . . . . . . . . . . . . . . 21
2.1.3 Public Key Infrastructure . . . . . . . . . . . . . . . . . . 23
2.1.4 Time-stamping . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.5 Bulletin Board . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.6 Threshold Encryption and Signature . . . . . . . . . . . . 27
2.1.7 Implementations of EVS . . . . . . . . . . . . . . . . . . 30
2.1.8 On the Freedom of Choice . . . . . . . . . . . . . . . . . 34
2.2 Designing Framework . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.1 Real World Model . . . . . . . . . . . . . . . . . . . . . 35
2.2.2 Computing Device . . . . . . . . . . . . . . . . . . . . . 36
2.2.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1
8/3/2019 Designing Electronic Voting
3/73
2.2.4 Threshold Trust . . . . . . . . . . . . . . . . . . . . . . . 38
2.2.5 Connection . . . . . . . . . . . . . . . . . . . . . . . . . 402.2.6 PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.2.7 Time-stamping . . . . . . . . . . . . . . . . . . . . . . . 47
2.2.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3 Design for Bulletin Board . . . . . . . . . . . . . . . . . . . . . . 48
2.3.1 Some Simple Ideas . . . . . . . . . . . . . . . . . . . . . 49
2.3.2 Synchronous Environment . . . . . . . . . . . . . . . . . 50
2.3.3 Asynchronous Environment . . . . . . . . . . . . . . . . 51
2.3.4 Practical Solutions . . . . . . . . . . . . . . . . . . . . . 52
2.4 Design Pattern for E-voting System . . . . . . . . . . . . . . . . 53
2.4.1 Computing Result . . . . . . . . . . . . . . . . . . . . . 57
2.4.2 Meta Process . . . . . . . . . . . . . . . . . . . . . . . . 61
2.4.3 Design for Single Authority EVS . . . . . . . . . . . . . 61
2.4.4 Design for Multiple Authority EVS . . . . . . . . . . . . 63
2.4.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 65
3 Summary 66
Resumee (In Estonian) 68
Bibliography 69
2
8/3/2019 Designing Electronic Voting
4/73
Introduction
Recently, the topic of implementing electronic voting (e-voting) has become very
popular: multiple workshops have been held, there exist firms that provide cor-
responding services, real attempts of e-voting have taken place, media is eagerlycovering this topic. The main purpose of electronical elections is allow voters to
vote from as many locations as possible, ideally from their personal computing de-
vices. An intermediate option would be to have specialized computers (kiosks) be
deployed everywhere like ATMs (automated teller machines) currently are. Com-
munication media would probably be Internet or something similar. The justifi-
cation is that it would be more convenient, which would increase voter turnout.
Also, one might expect that in future e-voting would become less expensive than
conventional voting. At the current time e-voting is viewed as a complement to
conventional elections because, for instance, not all people have access to comput-
ers and Internet (or skills to use them).
Despite its tempting simplicity, this problem is much more complex than itseems at the first moment. The main issues are security and reliability. The prob-
lem of organizing e-voting consists roughly of three parts:
Solving problem mathematically, which includes formulating model of the
real world (e.g. formalizing the notion of trust), stating requirements, and
finally finding a mathematical construction and proving that it satisfies these
requirements. Such construction is called electronic voting scheme (EVS):
a collection of protocols and algorithms, which implement e-voting within
formulated model of the real world. I will call all this theoretical activity.
Provided there is an EVS, it is needed to implement it. In particular, real
world model, which was used, must be implemented. Besides that, EVS
has usually relatively simple structure (nevertheless being complex mathe-
matically), which assumes some inputs and produces some outputs. It does
not consider the process of preparing input data and consuming output data.
Also, e-voting must be somehow integrated into existing conventional voting
3
8/3/2019 Designing Electronic Voting
5/73
process. Real implementation must consider the whole iterative process of
organizing elections. I will call this technical activity.
Finally, e-voting will inevitably differ from conventional elections: voter
must perform different actions, there are different (and probably bigger) se-
curity threats, different demographical groups have different level of access
to the Internet, etc. For this reason politicians and sociologists must evaluate
impact of e-voting on the democratic process and decide whether it is useful
at all and provide suggestions what should be changed. Besides that, laws
must be changed to accommodate e-voting into conventional voting process.
I will call this political activity.
Theoretical activity belongs to the field of cryptography and has lasted for at
least twenty years. The most influentious papers in this field are (personal opinion):
[Cha81], [Ben87], [BT94], [CGS97]. Reader can find a partial overview of this
topic in my semester work [Myr00]. Basically, it can be said, that there exist
solutions of acceptable security and complexity, although there is enough place for
further advances.
There exist some number of firms, which provide e-voting solutions. The most
well-known of them are probably [VoteHere.net] and [Election.com]. The first
of them provides (at least) some description of their technology and is based on
[CGS97], which is a good cryptographical construction. On the other hand the
second of them has received more media attention, but does not present any de-
scription of their technology at their web site (which is a disadvantage, to my opin-
ion).
A number of workshops have been conducted, which concentrated on political
and technical aspects: National Workshop on Internet Voting [IPI], Voting Integrity
Project [VIP], California Internet Voting Task Force [CIVTF]. Their major finding
is that although there is enough theoretical basis for implementing e-voting, tech-
nologically it is not possible to make systems secure enough. The biggest problem
is insecurity of conventional personal computers and Internet. At the same time
they propose using e-voting kiosks in near future.
Aims of the Thesis
This thesis can be viewed as continuation of my semester work [Myr00], where
I dealt with theoretical problems of e-voting. In this work I will concentrate on
the technical aspect: I will try to formulate requirements for the system and out-
line system design. Software engineering ideology and notation (UML) will be
followed throughout the text.
4
8/3/2019 Designing Electronic Voting
6/73
Although it is clear that risks of voting from usual PCs over Internet are too
high, it is still interesting to design e-voting system and see where and why theserisks come up.
Acknowledgement
I would like to express my gratitude to Helger Lipmaa for introducing me to this
subject and motivating me to deal with it and also for pulling me into Estonian
e-voting project [LipMy01].
Notation
As a potential reader might have theoretical computer science (and not software
engineering) background, I will describe shortly notation used. Two types of UML
diagrams are used: static structure and activity. Notation is used and interpreted
quite freely, which should be normal from the viewpoint of UML. There are also
some other types of diagrams used, but their meaning should be evident or will be
explained separately.
Static structure diagram sample is presented on Figure 1. It depicts Factory (a
class) that produces Cars (dashed line signifying dependency or direction of flow).
Cars have names (an attribute) and operations Car::Start() and Car::Stop()
(methods). Each car has at most one Owner, each owner can have many cars (arrow
with 1 and * signifying one-to-many relationship). Car consists of Wheels(rhomb signifying aggregation). Car is a kind of Beeper, though it can Beep()
(triangle signifying generalization, interface signifying a set of methods that some
class should implement).
Activity diagram sample is presented on Figure 1. It is supposed to describe
state transitions and flow of a process. The upper black dot signifies beginning
of the process (initial state), the one at the bottom is the final state. Bubbles sig-
nify either activity or state, arrows depict transitions. On this diagram Work1 and
Work2 are performed in parallel, state Complete is reached when both of these
activities complete.
System architecture diagram sample is presented on Figure 1. Here three-
dimensional bar depicts a subsystem, simple rectangle depicts a process (I also in-terpret it as a user), rounded rectangle signifies an object(or data), cylinder depicts
datastore, grey bar between database and computer signifies a boundary. Lines
and arrows are used freely to signify relationships and directions of dataflow.
5
8/3/2019 Designing Electronic Voting
7/73
Factory
+start()+stop()
+name
Car Owner
*
1
Wheel
1
*
+beep()
interfaceBeeper
Figure 1: UML Static Structure Diagram Sample.
Prepare
Work1 Work2
Complete
Figure 2: UML Activity Diagram Sample.
6
8/3/2019 Designing Electronic Voting
8/73
Computer
Program
Programmer
Database
Figure 3: System Architecture Diagram Sample.
7
8/3/2019 Designing Electronic Voting
9/73
Chapter 1
System Analysis
In this chapter I will try to describe the problem of e-voting in detail and formu-
late requirements for e-voting system. This would be a basis for designing and
implementing such system.
1.1 Domain Model
The basic entities involved in elections are depicted on Figure 1.1.
+id
Person
+name
Election
Voter Ballot Type
+name
Option
1 *
1
*
1
*
1
*
* 1
Figure 1.1: Domain model.
Person Any person that may participate in some election. I assume that each
person has unique identifier.
Election Specific election. I assume that elections are identified by a unique name.
8
8/3/2019 Designing Electronic Voting
10/73
Voter A person participating in election. Many voters can participate in election.
Each person can be a voter in many elections. Voter is identified by personsidentifier and name of the election.
Ballot Type Different voters can be presented with different ballot types at some
election. Ballot type consists of some number of options amongst which
voter will have to select one.
Option One option belonging to some ballot type. Options are identified by
names. Option names are unique within corresponding ballot type.
At real election voter might be required to answer to multiple questions. In my
model this can be modelled with multiple simultaneous elections. If it is impor-
tant that voter answers correctly to each question, it can be easily enforced with
technical or administrative methods.
In addition I present the following definitions:
Definition 1.1.1 Ballot - an option from some ballot type chosen by a voter.
Definition 1.1.2 Tally - a set of ballots from voters of some election. Each voter
can have at most one ballot.
Definition 1.1.3 Election Result - calculated from tally, where for each ballot type
it is said how many times each option was selected.
1.2 Generic Requirements
Any election system (either conventional or electronic) must at least satisfy the
following requirements:
Functional Requirements System must allow forming lists of eligible voters,
needed ballot types, and assigning each voter corresponding ballot type.
Each voter must have opportunity to cast at most one vote by selecting one
option from his ballot type. In the end election result must be calculated.
Freedom of Choice Nobody can affect voters choice. Voter should make his de-cision himself. It is a complex problem how to define such requirement
formally, but basically there are two options:
Privacy Nobody can learn how a person voted without cooperating with
him.
9
8/3/2019 Designing Electronic Voting
11/73
Incoercibility Nobody can learn how a person voted even if cooperating
with him is possible. This includes that voter cannot prove how hevoted. Of course, voter could just tell coercer how he voted, but coercer
would not have any means of verifying this claim.
Interested reader can find longer discussion of this subject in [Myr00].
1.3 Conventional Elections
It is important to stress that e-voting is viewed as a complement to conventional
non-electronic voting systems. So it is reasonable to review how such systems are
functioning.
ElectionOrganizer Intermediate
OrganizerVotingLocation
1
*1
*
Figure 1.2: Conventional elections.
The structure of the system is usually hierarchical. Normally there is one orga-
nization, which is responsible for organizing election. I call it Election Organizer.On the other hand there is some number of hierarchy leaves, where people can ac-
tually vote. I call them Voting Locations. Voting locations and election organizers
communicate through intermediate organizers, which group some number of vot-
ing places (usually on geographical basis). Different ballot types can be used at
different voting locations.
Each voter is assigned to one main voting location (close to his residence),
where he can normally vote. In such setting it is possible to prevent voters from
overvoting (voting more than once). Different voting technologies can be used
there. One possibility is to use paper ballot, where options are presented and voter
has to select one of them. After that ballot is casted into a sealed box. Later all
ballots are taken out of the sealed box and counted. The counting process can be
automated, for example, by means of optical scanning. All of the technologies
assure that after voter has casted his ballot, it is not possible to link voters identity
and his ballot, which ensures privacy. In fact, incoercibility is also guaranteed
because voter is casting his ballot in a private voting booth, which implies that
voter cannot prove how he voted (of course, in real world such claims are always
10
8/3/2019 Designing Electronic Voting
12/73
relative to how much determined is the adversary). It is important to point out that
after voter has casted his vote, it is not possible to remove his vote from the tally,which might be useful, if later it turns out that voter was not eligible to vote.
If voter does not want to vote at his main voting location, there are some pro-
cedures for absentee voting, which allow him to vote from a broader number of
locations (e.g. even from home). In this case special measures must be taken to
prevent voter from voting more than once (overvoting). One possible solution is
that voter puts his ballot into a clean envelope, seals it, and then puts this envelope
into a new one, where he writes his identification. After that all envelopes from one
voter must arrive at the same place, where it can be ensured that he did not vote
more than once. Also, if voter is not prevented from voting at his main voting lo-
cation, it must be ensured that he did not use both voting procedures. This implies
that the best place for gathering voters envelopes is at his main voting location. If
it is decided that voters envelope should be counted, external envelope is removed
and the second clean envelope (which cannot be linked to voters identity) is put
into a bigger pool of clean envelopes of other voters. After that voters ballots can
be processed without compromising voters privacy. If voter is obliged to form his
ballot in a private voting booth, incoercibility is also guaranteed, but if ballot can
be composed at any place (e.g. at home and then sent by mail) someone could have
been watching how voter is filling his ballot.
Election results at each voting location are passed up the hierarchy to the in-
termediate organizers and finally to the main organizers (separately for each ballot
type). At every level information passed from lower nodes is summed up and then
passed to the parent node. Integrity of the process is ensured by the presence of ob-
servers, whose function is to verify that everything is performed as needed (votes
are counted correctly, voter privacy is maintained). Distributed nature of the system
ensures that violations of voting process at some node will not poison the whole
voting system and though will have only limited effect on election result.
A separate problem is compilation of lists of people who can vote at each voting
location. Probably the best solution is to have a database of all people from which
lists of voters can be generated, but this is not always the case.
1.4 Trust
E-voting system must be trusted by all entities, whom decisions made using it
may concern. In the case of a country, the system must be trusted by all citizens,
government, organizers themselves (hopefully) and also it must be approved by the
international community.
The problem of verifying that system corresponds to its requirements is very
11
8/3/2019 Designing Electronic Voting
13/73
common in the field of software engineering. Requirements can be usually divided
into the following groups:
Functional Which functions should the system be able to perform.
Efficiency Limitations on time, memory, and communication channel bandwidth
requirements.
Dependability To what extent one could rely (depend) on the system, including:
Reliability Limits on statistical measure of frequency of faults. Is related to
availability.
Availability Minimum acceptable percentage of time, during which system
performs correctly. Is related to reliability.
Safety Limits on the measure of loss in the case of big failures.
Security What functions should system prevent from performing. In gen-
eral, such requirements are application specific, but the most usual ones
are:
Access Control Policy defining which system users can perform
which operations.
Confidentiality Policy defining which system users are supposed to
see which data.
Integrity Policy defining how data present in the system can be en-
tered, modified, and deleted.
Most of requirements can be assigned meaningful numeric measures, but in
practice it is almost never possible to measure them directly. Functional and effi-
ciency requirements can be measured to some extent by testing, but dependability
and in particular security is not measurable directly almost at all (also it is very
rare when systems can be built so that their correctness can be proven formally). A
typical solution is to evaluate parameters indirectly, by measuring the quality of the
process of creating and maintaining the system, which gives of course very vague
results. The following aspects are usually taken into consideration:
Whether best practices and common sense are used.
To what extent system has been subject to testing, formal verification.
Presence of continuous process of improvement of systems quality.
In the case of security, important additional criterions are:
12
8/3/2019 Designing Electronic Voting
14/73
For how long the system has withstood real or theoretical attacks by other
interested parties.
Presence of continuous process of prevention, detection and reaction to pos-
sible attacks.
In general specialists proficient in one field are not able to verify systems from
the other fields. A general way to ensure quality of a system is to have specialists
others than those who created it review it and express opinion. In the case of
approval verifiers would become partially responsible for that system themselves.
Figure 1.3 describes components of hypothetical e-voting system, and also spe-
cialists that are responsible for them, who must be trusted to some extent.
Theory Scientists are responsible for developing corresponding theory, the quality
of which must be ensured by peer review.
Hardware and Software Engineers are supposed to provide hardware and soft-
ware, which must be certified.
Servers E-voting system consists of one or more server computers, which are set
up and maintained by the operators. Integrity of servers could be ensured by
the presence of observers.
E-voting system E-voting system itself is set up and maintained by the organiz-
ers. Integrity of the whole process could be also ensured by the presence of
observers.
Network Network connecting servers and voters computing devices is set up and
maintained by the providers.
Voters computers Voters computing devices are set up and maintained by ad-
ministrators. In many cases voters are administrators of their computers
themselves.
Careful reader has probably noticed that network and voters computers do not
have certifiers. This is mostly a reflection of existing situation. It is very hard
to certify in any sensible way network, which spans the whole world (Internet).
Although users computers could be certified, it is not done massively at the current
moment. Also in the case of contemporary personal computer (PC), it might not be
a very sensible activity, because voter would be able to misconfigure his computer
right after certification. So voter computers certification bears any sense only to
the voter himself (and may be to computers administrator), but not the rest of the
world.
13
8/3/2019 Designing Electronic Voting
15/73
Theory
Hardware
Network
Servers
E-voting system
Voters' computers
Software
Scientists
Engineers
Operators
Organizers
Providers
Administrators
Figure 1.3: Components of hypothetical e-voting system.
14
8/3/2019 Designing Electronic Voting
16/73
1.5 On Revoking Ballots
Before stating the requirements for e-voting system, one more issue of integrating
conventional elections and e-voting must be considered. Revoking ballots means
removing some voters ballots from the tally before counting it. It is useful when
there are two or more facilities for casting a ballot, which take place simultane-
ously. There are two ways to prevent overvoting in such situation:
When voter is casting his ballot it is checked whether his has already done
that using the other facility.
After election is over it is checked if someone voted using both facilities and
then this voters ballot must be revoked from one of the two tallies.
As it is not possible to revoke ballots in conventional voting, introducing e-
voting would require one of the following:
E-voting to allow revoking ballots.
E-voting and conventional voting not taking place at the same time, but se-
quentially.
To have a database where for each voter it would be recorded if he has al-
ready voted and to maintain online connection between this database and all
voting locations.
Its clear that the first option is the most preferable as it requires the least re-
sources (does not require database) and is the most convenient (conventional elec-
tion and e-voting can take place at the same time).
1.6 E-voting Requirements
Now requirements for e-voting system can be stated.
1.6.1 Functional Requirements
System must support the following activities:
Organizers use cases Elections organizer must be able to perform the following
operations:
Prepare election First, election information must be prepared:
15
8/3/2019 Designing Electronic Voting
17/73
Enter election parameters It must be possible to create new election
record and enter general parameters like name and time periodduring which it should take place.
Enter voter list After that voter list must be entered somehow. Be-
sides that some form of voter identification must be provided. It
is reasonably simple, if there exists database of all voters, from
which this list could be retrieved with corresponding query. On
the other hand, if voters are supposed to register at election (as in
USA), it would require a separate software module to fulfil this
requirement.
Enter ballot types Further, system should support entering different
ballot types and options.
Map voters to ballot types Finally system should allow creating
mapping between voters and ballot types. Normally it would be
possible to devise this mapping from supplementary information
about voters, if it is available. For example, if ballot types are
assigned based on where voter lives.
Conduct election Having prepared election information it should be pos-
sible to conduct it. It is conceivable that system would start and stop
election automatically based on the time period entered when creating
election information.
Start election
Pause election
Stop election
Finish election After election has been conducted, it is needed to make con-
clusions.
Revoke voters System must allow to leave uncounted ballots of some
voters. It is an optional but very desired requirement, which was
discussed in Section 1.5.
Compute result After that result must be computed: for each ballot
type it must be calculated how many times this option was se-
lected.Output result Finally election result must leave the system and enter
external world. One option is to print it on paper. The other option
is to produce digitally signed document.
Archive election As the last step election information must be archived to
durable media.
16
8/3/2019 Designing Electronic Voting
18/73
Save election information The following information must be
archived:
Election information: voter list, ballot types, mapping be-
tween voters and ballot types.
Binary representation of casted votes or any other informa-
tion based on which election result was computed (and can be
recomputed), if possible.
The list of voters whose ballots were revoked when computing
election result.
Official election result as computed before.
Verify archived information It must be possible to verify that all
archived information is correct, in particular that archived electionresult matches other archived information.
Figure 1.4 illustrates the main process of e-voting system from the
viewpoint of organizer.
Preparing election
Conducting election Revoking voters
Computing result Archiving
Figure 1.4: Voting process.
Voters use cases Voter must be able to perform the following operations:
Select election As there might be many elections taking place simultane-
ously, voter must be able to select which election he wants to work
with.
See ballot and make a choice After having selected election, voter must be
able to see the options and select one of them.
17
8/3/2019 Designing Electronic Voting
19/73
Submit ballot Finally he must be able to submit his ballot to the system.
Change or delete ballot Optionally it might be allowed to change or even
delete previously submitted ballot.
Access Control It should be possible to define for each system operation, which
users can perform it.
1.6.2 Non-functional Requirements
Convenience and Usability System must be convenient to use, especially for vot-
ers. This includes:
Simplicity Performing voting process should be as simple as possible.Graphical representation of ballot should be intuitive (probably it
should look like paper ballot).
Mobility Ability to vote from as many places and devices as possible.
Revisability Ability to change or delete previously submitted vote.
Efficiency It should be possible to complete voting process as fast as pos-
sible. Software delays (time during which software is performing ac-
tions, not waiting for user input) should not be longer than (say) 1
second (conventional web applications). The final step of submitting
vote should not last longer than 1 minute (say).
Efficiency Voters software efficiency has already been discussed. Organizers
software efficiency should be as follows:
Election information preparation should act as a usual application
where software delays should not be longer than (say) 1 second.
The process of conducting elections should be efficient enough to en-
sure required speed of voters actions.
The final stages of election like computing result, archiving or verifying
election data should not last more than a couple of hours.
Freedom of Choice Besides functional requirements, system must satisfy thefreedom of choice requirement, which was discussed in Section 1.2.
Privacy Is considered a minimum requirement and is necessary.
18
8/3/2019 Designing Electronic Voting
20/73
Incoercibility In general, incoercibility is very useful, but in the case of e-
voting it can never be ensured completely: if people can vote at anypossible location (including at home) it is possible that someone will
be looking over shoulder how someone is voting. So probably it is
enough to ensure that coercibility cannot take place at a larger scale,
than it is possible by physically attending when someone is voting.
Dependability Its clear that e-voting system must be much more reliable than
conventional software. There are two ways how system might be malfunc-
tioning:
Some operations cannot be performed (voter cannot vote, result cannot
be computed).
System looks like working correctly, but it is not (voters software
silently selects different option, some voters ballots are silently omit-
ted, result is computed incorrectly).
The second type of faults is clearly more dangerous.
19
8/3/2019 Designing Electronic Voting
21/73
Chapter 2
System Design
In this chapter I will describe different options for implementing e-voting system.
I will also try to compare them and evaluate risks. First, an overview of theo-
retical basis will be given and then design for different parts of the system will
be described. It is important to stress that design for such system does not mean
only software design, but also design of the organization and the process, and also
possibly hardware.
As it was already mentioned the main problem of implementing e-voting is se-
curity. Security is almost always relative - it can be broken with some investment
of resource (money and/or time). Although the benefits of breaking e-voting sys-
tem cannot be completely measured (for instance in money), it can still be argued
that adversary would not spend more resource on breaking e-voting than he would
gain from breaking it. This implies that elections of different importance would
require different minimum level of security.
2.1 Theoretical Basis
Before designing the real system, e-voting problem must be analysed and solved
mathematically. In fact, this problem belongs to the field of cryptography. In this
text an overview of the topic will be given. Those interested in more details can
find them in [Myr00]1.
1This implies that references to sources will only be given when necessary. Interested reader can
find them in [Myr00].
20
8/3/2019 Designing Electronic Voting
22/73
2.1.1 Model of the Real World
First a simplified model of the real world must be introduced, within which it would
be possible to describe possible solutions and evaluate them. The following terms
are introduced:
Actor Actor is any entity (person, computer), which is assumed to have an iden-
tity. Actors have ability to perform polynomially-bounded randomised com-
putations and have means of keeping secret information. Also, actors are
assumed to have synchronized clocks: there should be upper limit on clock
value and speed difference.
Connection Besides that, actors are able to communicate with each other. Mes-
sages can be sent between addresses, but not actors (no identification). Com-munication is dependable (sent messages are always received in the order of
sending) and is synchronous (the time message is delivered from sender to
receiver has upper bound). At the same time communication is not anony-
mous and not private. This means that it might be possible to find out which
actor sent or received some message and also any actor might be able to read
any message. I call such connection public.
In principle one could also think of private, untappable communication with
reliable identification (see [Myr00]), which is actually very useful when tar-
geting at incoercibility, but such assumption is very hard to implement in
reality (every voter would need such communication channel), so I will omit
it.
Threshold Trust Often constructions are formed out of similar components
(actors) so that their properties hold as long as at most
components
fail to fulfil some requirement.
For instance critical services are often constructed to be reliable as long as at
least components out of are working correctly and are able to commu-
nicate (equivalent to requirement that at most
components will fail).
Security is often ensured as long as no more than
components perform
some specific operations (are dishonest).
Motivation for such approach is that it might be simpler to ensure such re-
quirement than ensuring that one specific component would not fail.
2.1.2 Electronic Voting Scheme
The aim of theoretical activity is to define and design a simple construction, which
would abstract the real world problem of organizing e-voting. Such construction is
21
8/3/2019 Designing Electronic Voting
23/73
called Electronic Voting Scheme (EVS). The following types of actors are defined:
Voter Actor that will vote in election.
Authority Actor that will organize election.
One and the same actor can belong to more than one set. It is assumed that:
There is one ballot type with L options, which are known to all actors.
All actors know identities of authorities and have means of communicating
with them (e.g. know addresses at which they send at receive messages).
All actors know identities of all voters.
Some of the voters have selected one option and intend to cast it.
Electronic voting scheme is a set of protocols (algorithms) for actors, which
allow voters to send their ballot with selected option to authorities and authorities
to compute election result and make it available to all actors. EVS must satisfy the
following requirements:
Correctness Election result must be computed correctly based on all ballots sub-
mitted by the voters.
Freedom of Choice Either privacy or incoercibility, as discussed previously.
It is very typical to require EVS to be verifiable in order to ensure correctness:
computation results of authorities must be verifiable by any actor. This usually
means that authorities must provide computational proof of correctness of elec-
tion result.
Each EVS should define:
Means of actor identification.
To what extent actors must be trusted to perform according to prescribed
protocols. Basically, there are two options:
Assume that actor is honest - i.e. follows protocols.
Assume threshold trust towards actors (usually applied only to au-
thorities).
22
8/3/2019 Designing Electronic Voting
24/73
2.1.3 Public Key Infrastructure
Situation when actors need to communicate secretly and with reliable identifica-
tion, but can use only public communication channel without reliable identifica-
tion, is very typical. In order to address it, a framework called Public Key In-
frastructure has been developed. The basis for PKI is public key cryptography,
which defines a set of interfaces with special properties, which must be satisfied by
corresponding implementations. These interfaces are depicted on Figure 2.1.
+binary
Public Key
+binary
Private Key
Key Pair
1 1
1
1
+Generate()
interface
Key Generator
+Encrypt()+Decrypt()
interfaceEncryption Algorithm
+Sign()+Verify()
interfaceSignature Algorithm
+Compute()
interfaceDigest Algorithm
Figure 2.1: Encryption and signature algorithms.
Digest Algorithm::Generate() takes as input any binary sequence
and produces hash of fixed length (say 128 bits). Digest algorithm is sup-
posed to be collision resistant - it should be infeasible to find two different
binary sequences having the same hash.
Key Generator::Generate() is an algorithm that randomly generates
a pair of two keys of specified bit length (e.g.
bits). These keys areused as inputs to Encryption Algorithm and Signature Algorithm
methods.
Encryption Algorithm::Encrypt() takes as input a Public Key
and a binary sequence of any length (called plaintext) and produces a bi-
nary sequence of comparable length (called ciphertext). Encryption Al-
23
8/3/2019 Designing Electronic Voting
25/73
gorithm::Decrypt() takes as input Private Key and performs reverse
transformation from ciphertext to plaintext (which was encrypted using thepublic key from the same key pair). It is required that actor k nowing the
public key (but not private), some number of ciphertexts and corresponding
plaintexts, would not be able to devise any information about the plaintext
corresponding to some other ciphertext.
Signature Algorithm::Sign() takes as input Private Key and a bi-
nary sequence of fixed length and produces another binary sequence of fixed
length called signature. Length of input and output sequences is compara-
ble to the length of the key. Signature Algorithm::Verify() takes
as input Public Key, binary sequence, and signature and checks that this
signature was produced from that binary sequence with corresponding pri-vate key. It is required that actor knowing the public key (but not private),
some number of binary sequences and their corresponding signatures would
not be able to produce signatures for any other binary sequence. In order to
sign binary sequences of any length, digest is computed from them and then
signed.
There exist cryptographical algorithms that satisfy these interfaces, whereas it
is important to assume that actors have only polynomially limited computational
power2.
Now, if two actors
and
generate themselves pairs of keys, exchange some-
how their public keys, and keep their private keys in secret, they get ability to com-municate secretly and with identification: when actor
wants to send message
to actor
, it signs it with his private key, encrypts with
s public key and then
sends resulting message to . No other actor who might learn message , but
does not know
s private key cannot devise any information about the message
. At the same time
is able to verify
s signature, which could have been
produced only by some actor knowing
s private key (which is supposed to be
kept in secret). Some encryption algorithms have an interesting property: is able
to prove to someone else knowing message
that he sent message
, without
revealing any information about his private key.
Despite the beauty of such solution, there is one problem: actors need to ex-
change their public keys somehow. It is not possible to do it over the public con-nection, because it is not possible to ensure who did the public key come from. In
2It should be stressed that there also exist many variations that do not exactly fit into this descrip-
tion. Also not all encryption and signature algorithms have complementary counterpart in the sense
of sharing the same key pair. This means that there exist encryption algorithms that do not have
complementary signature algorithm, which could use the same key pair and vice versa.
24
8/3/2019 Designing Electronic Voting
26/73
fact, in such setting this problem is not solvable at all: at some moment commu-
nication with reliable identification is necessary. So at best one may require suchcommunication to take place only once. PKI provides the following construction
to deal with this problem:
All actors are assumed to have identity, which has a unique identifier, which
can be represented as a binary string.
A special construction called certificate is introduced. It consists of:
Subjects public key (in binary representation).
Subjects identity (binary representation of its identificator).
Some optional attributes explained later.
Issuers identity.
Signature of all preceding items verifiable with issuers public key.
Certificate is interpreted as a statement that binds contained public key to the
subjects identity. If someone having such certificate has reasons to trust is-
suer of the certificate and he knows issuers public key, he would have reason
to believe that specified public key belongs to the subject. Certificate may
allow (trust) or forbid (not trust) the subject to issue certificates himself. Ac-
tor who is trusted to issue certificates is called Certification Authority (CA).
Certificate may also be limited to some field of activity. Such information
can be recorded in the attributes of the certificate.
If actor has some number of certificates one could think of a graph, where
nodes are identities and arcs signify certificates connecting issuer to the subject.
Besides that, some nodes have associated certificates, which are assumed to be-
long to corresponding identities. Different nodes, certificates, and arcs can have
different level of trustworthiness. After that derivations can be made on this graph
(transitive closure).
The simplest form of such graph is a tree: there is one root CA, which might
certify some number of intermediate CAs, which finally certify all interested actors.
It is assumed that everybody trusts the root CA. In order to get into this framework
one would have to prove his identity to some of the CAs (what cannot be donewithin our model and so must be done externally) and provide his public key. After
that, a certificate would be generated that would be trusted by everybody.
It is important to point out that all this framework holds as long as actor is
willing to keep his private key in secret. Nothing prevents him from revealing it to
someone else. Also in real life someone might steal someones private key and for
25
8/3/2019 Designing Electronic Voting
27/73
this reason CAs are supposed to provide means of checking whether certificate is
still valid. This can be accomplished, for instance, by providing certificate database(containing either valid, revoked, or both kinds of certificates) which can be queried
online, or by periodically publishing certificate revocation lists (CRLs).
2.1.4 Time-stamping
Time-stamping is a complementary to PKI service, which allows binding arbitrary
message to a moment in time. This is done by creating an additional time certificate
message. At least two flavours of time-stamping exist:
Absolute Allows determining reasonably small interval
, within which
the message received time certificate. Such construction is of any use onlywhen actors clocks are synchronous.
Relative Allows determining for any two messages and having time certifi-
cates, which of them received the time certificate earlier.
Time-stamping service (TSS) is supposed to be implemented by one trusted
actor or by
actors with threshold trust. Actors forming such service are called
Time Stamping Authorities (TSAs). In ideal, time certificates should allow com-
paring them without the need for contacting TSS (offline verification).
Observing time certificate of a message proves that message was created before
the moment in time associated with this certificate. If a signed message incorpo-
rates time certificate of any message (e.g. empty), one could conclude that messagewas created after the moment in time associated with the certificate.
One of the most important applications of time-stamping is in the situation
when someones certificate is revoked (e.g. due to private key leak). In such sit-
uation time certificate could be used to prove that message was signed before the
certificate was revoked.
2.1.5 Bulletin Board
Often a service called Bulletin Board (BB) is assumed to exist. It is supposed to
allow each actor to send signed messages to it. After that every actor should even-
tually be able to see all messages in the order they were sent. Sender of a messageshould be sure whether sending message succeeded. Such requirements are called
atomicity. Also events are usually defined at which bulletin board starts and stops
receiving messages. If ordering of messages in not important, the construction is
called reliable store.
26
8/3/2019 Designing Electronic Voting
28/73
The dynamics of a bulletin board could be described by latency (how long does
it take after the message was sent to become readable for everyone) and monotonic-ity (guarantee that if someone has seen a message at the bulletin board, then at each
successive read this message will be visible to every reader). Monotonicity for one
specific reader could be called read repeatability.
For the purpose of proving time-outs (in order to accuse some actor of not
participating) it is very desirable that bulletin board would be able to tell with a
reasonable precision at which moment message was sent. Such property could
be called absolute time-stamping (as opposed to relative ordering provided by the
bulletin board in any case).
In a modification of bulletin board called atomic multicast it is supposed to for-
ward messages to some number of subscribers. Note, that this is not the same when
some actor sends a message to a group of actors himself because, for instance, there
is no guarantee that one and the same message will be sent to everybody. If order-
ing of messages is not important, the construction is called reliable multicast. It
should be clear that atomic multicast can be implemented with bulletin board by
polling it periodically, which might not be as efficient, of course.
A simplification of bulletin board (and atomic multicast) is to maintain a sep-
arate single writer multiple reader bulletin board for each actor. In this situation
ordering of messages can be devised for each actor separately. Even in such setting
one actor can prove that his message was sent after some other message by some
other actor by including in the former message the hash of the latter.
It is relatively simple to implement bulletin board if there is one actor every-
body would trust. Otherwise a system consisting of multiple actors with threshold
trust on them must be devised.
It should be clear that full-blown time-stamping exists iff full-blown bulletin
board exists. Still, from the viewpoint of efficiency they have different profile:
bulletin board requires much more storage and at the same time time-stamping
might be required to process much more messages and exist for longer period of
time.
For the purpose of e-voting it is enough to have a single-writer bulletin
board for each actor with reasonable latency, repeatable read, and absolute time-
stamping. Monotonicity is desirable, but is not a requirement. The number of
messages at each bulletin board would be fairly small (say
).
2.1.6 Threshold Encryption and Signature
Conventional encryption and signature algorithms can be extended in such a way
that private key would be split into
parts (shares), which would be given to differ-
ent actors, so that decryption and signing could be performed only if (threshold)
27
8/3/2019 Designing Electronic Voting
29/73
share holders decide so. Such construction is very useful in the context of threshold
trust. Figure 2.2 depicts relevant constructions.
+Generate()+Reconstruct Public Key()+Reconstruct Private Key()
interfaceThreshold Key Generator
+Encrypt()+Partial Decrypt()+Reconstruct()
interfaceThreshold Encryption Algorithm
+Partial Sign()+Reconstruct()+Verify()
interfaceThreshold Signature Algorithm
+binary
Private Key Share
+Verify()
+binary+proof of correctness
Partial Decryption
+Verify()
+binary+proof of correctness
Partial Signature
+binary
Public Key
+binary
Private Key
+Verify()
+binary
Public Output
Figure 2.2: Threshold encryption and signature algorithms.
It is assumed that each of
actors has his own private key and corresponding
certificate is available to all others. It is also assumed that actors communi-
cate through the bulletin board (or even better with atomic multicast).
Each of
actors is supposed to execute Threshold Key Genera-
tor::Generate(), which:
Takes as input actors key pair. Outputs Private Key Share (supposed to be kept in secret) and
also Public Output with actors signature (supposed to be made
available to everyone).
Public Outputs can be verified with Verify() method. Those that do
not pass this verification should be ignored further.
28
8/3/2019 Designing Electronic Voting
30/73
Threshold Key Generator::Reconstruct Public Key() can
construct a Public Key based on Public Outputs present on thebulletin board. Public key can be used by conventional Encryption
Algorithm to encrypt and Signature Algorithm to verify signature.
In principle a conventional Private Key can be reconstructed with help
of Threshold Key Generator::Reconstruct Private Key(), al-
though it is not usually used.
Threshold Encryption Algorithm::Encrypt() takes as input Pub-
lic Key and works exactly as conventional Encryption Algorithm. In
order to decrypt a ciphertext,
actors must execute Threshold Encryp-
tion Algorithm::Partial Decrypt(), which:
Takes as input ciphertext and actors Private Key Share.
Produces Partial Decryption.
Partial Decryption consists of:
Binary information.
Computational proof of correctness, which can be verified with
Verify(), which takes as input Public Outputs present at the bul-
letin board. Those partial decryptions that do not pass this verification
should be ignored further.
Finally plaintext can be reconstructed from Partial Decryp-
tions of actors with help of Threshold Encryption Algo-
rithm::Reconstruct() .
In order to sign a plaintext,
actors must execute Threshold Signature
Algorithm::Partial Sign(), which:
Takes as input plaintext and actors Private Key Share.
Produces Partial Signature.
Partial Signature consists of:
Binary information.
Computational proof of correctness, which can be verified with
Verify(), which takes as input Public Outputs present at the bul-
letin board. Those partial signatures that do not pass this verification
should be ignored further.
29
8/3/2019 Designing Electronic Voting
31/73
Finally signature can be constructed from Partial Signa-
tures of actors with help of Threshold Signature Al-
gorithm::Reconstruct() . Threshold Signature Algo-
rithm::Verify() takes as input Public Key and works exactly as
conventional Signature Algorithm.
It is important to point out that:
Both threshold decryption and signature operations can be performed only
by
or more actors or by all actors, the Public Output of which passes
Verify() (which is relevant if their number is less than ).
Decryption operation result cannot be incorrect due to proofs of correctness
of partial decryptions (signature operation result can always be verified di-
rectly). This can also be used in the case
.
2.1.7 Implementations of EVS
In this section I will outline possible implementations of electronic voting scheme.
The simplest solution is Single Trusted Authority Solution, where there would be
one authority (actor), everybody would trust. In such case every voter would sign
representation of his ballot with his private key, encrypt it with authoritys public
key and send it to him. Later authority would decrypt these votes, verify signatures,
compute result, and make signed result available to all others. In such situation
authority is trusted to:
Accept ballots from all voters3.
Count them correctly.
Not to use single decrypted ballots (intermediate results of computation) in
any other operation and discard them.
Despite the naivety of such solution, it can be made reasonably safe in real life.
There exist many other more or less secure solutions, but the best of them (such
statements are always subjective) follow the pattern, which is usually called Mul-
tiple Authority Solution. The algorithms and data structures involved are depictedon Figure 2.3.
3Multiple ballots could be accepted and the latest of them used - this would allow modifying vote.
Also, there could be a ballot of special form that would require authority not to count it, which would
enable voter to delete previously submitted ballot.
30
8/3/2019 Designing Electronic Voting
32/73
+Verify()
+encrypted information+proof of correctness+signature
Voter's Ballot
+Verify()
+computation result+proof of correcntess+signature
Authority's Output
+Verify()
+information+signature
Authority's Setup Information
+Generate Ballot()
interface
Voter's Algorithm
+Setup()+Compute()
interfaceAuthority's Algorithm
+Compute Result()+Verify Result()
interfaceConsumer's Algorithm
Figure 2.3: Multiple authority EVS.
31
8/3/2019 Designing Electronic Voting
33/73
It is assumed that there are
authorities and each actor has a pair of public
and private keys and certificates of all other actors. It is also assumed that ac-tors communicate through the bulletin board (it would be good if authorities
could communicate through atomic multicast).
First authorities jointly execute a setup phase, during which each authority
must execute algorithm Authoritys Algorithm::Setup(), which:
Takes as input authoritys key pair.
Might communicate with other authorities.
Outputs a piece of private information that authority should keep in
secret and also public Authoritys Setup Information with au-
thoritys signature.
The correctness of setup information can be verified with Authoritys
Setup Information::Verify(). Those setup informations that do not
pass verification should be ignored further. Resulting setup information must
be available to all actors.
Further, during voting phase each voter can generate his ballot using
Voters Algorithm::Generate Ballot(), which:
Takes as input voters key pair, selected option, and Authoritys
Setup Information from all authorities.
Outputs Voters Ballot.
Voters Ballot consists of:
encrypted information about voters choice.
Computational proof of correctness, which can be used to
check that encrypted information was formed correctly without
the need for decrypting.
Voters signature.
Voters ballot can be verified with Voters Ballot::Verify(). Those
that do not pass this verification should be ignored further. All voters ballotsshould be made available to all actors.
After that, during tallying phase each authority executes Authoritys
Algorithm::Compute() , which:
32
8/3/2019 Designing Electronic Voting
34/73
Takes as input authoritys key pair, private information generated dur-
ing setup phase, Authoritys Setup Information from all au-thorities, and voters ballots.
Verifies voters ballots using Voters Ballot::Verify() and se-
lects one correct ballot for each eligible voter. All authorities must
produce exactly the same list of ballots.
Produces Authoritys Output.
Authoritys Output consists of:
computation result explained later.
proof of correctness of computation result.
Authoritys signature.
Authoritys output can be verified with Authoritys Algo-
rithm::Verify(). Those that do not pass verification should not
be used further.
Finally every actor can execute Consumers Algorithm::Compute
Result(), which:
Takes as input Authoritys Setup Information from all author-
ities, and Authoritys Output from exactly different authorities.
Computes election result telling how many times each option was se-lected. This step can take a long time.
This result must be verified with Consumers Algorithm::Verify
Result(), which:
Takes as input Authoritys Setup Information from all author-
ities, voters ballots, Authoritys Output from exactly different
authorities, and the computed result.
Verifies voters ballots using Voters Ballot::Verify() and se-
lects one correct ballot for each eligible voter. Selected ballots must be
exactly the same as when authorities selected them.
Verifies Authoritys Output from those authorities with Ver-
ify() method.
Verifies that election result was computed correctly from Author-
itys Output from authorities. Result verification is remarkably
faster than result computation.
33
8/3/2019 Designing Electronic Voting
35/73
It is of crucial importance, that every actor sees the same Authoritys
Setup Information from every authority and the same Voters Ballot
from every voter (which might not be the case if some actor could send differ-
ent information to different actors). This condition implies that all information
should be posted to the bulletin board. It is important to point out that even if this
condition does not hold, wrong election result cannot be computed, because some
verification would fail. As voters ballots are sent to the bulletin board, it is pos-
sible to allow voters sending multiple ballots, amongst which the latest would be
selected. Also there could be a ballot of a separate form that would require author-
ity not to count it. This would allow deleting previously casted vote, although this
might not be secret.
Also the following holds:
Election result can be computed as long as there are at least
authorities,
which follow algorithms. Election result can never be computed incorrectly
(to be more precise it can happen with negligibly low probability).
Information on choices of individual voters can be extracted if at least
authorities that produced correct Authoritys Setup Information de-
cide to do that. Also all authorities together that produced correct Author-
itys Setup Information can do the same (it is relevant in the case
when the number of such authorities is less than
).
All this implies, that no actor should proceed further if the number of authorities
that produced correct Authoritys Setup Information is less than .
Careful reader has probably already noticed similarity of this construction with
threshold encryption and signature. An example of such EVS would be variations
of [CGS97] with shared public key (threshold) generation in the setup phase (see
[Myr00]). Another option is for instance [CFSY96].
2.1.8 On the Freedom of Choice
As it was already mentioned, freedom of choice requirement implies either privacy
or incoercibility, whereas the former is obligatory and the latter is optional. All
patterns for EVS described in Section 2.1.7 ensure privacy, but do not guarantee
incoercibility. The simplest way to prove how voter voted is to reveal his privatekey. Fortunately, in real life private keys are associated with voters identity and
might be used to access different services like banks, which implies that actor
would not have motivation to reveal his private key. But this does not solve the
problem, because it is possible to prove how voter voted without revealing the
private key (private key is only used to sign). See [Myr00] for more details.
34
8/3/2019 Designing Electronic Voting
36/73
Generally, in an environment with only public (tappable) communication inco-
ercibility is provably not possible. If PKI is introduced and it is assumed that voterdoes not want to reveal any information about his private key, it might be possible
to deduce EVS that would satisfy incoercibility, but I am not knowledgeable of any
such construction.
Another option is based on observation that incoercibility is not achievable
because voter can see intermediate computation results and is able to sign any
message. This leads to a solution, where there would be a specialized device,
which would ask voter which option to use, perform all computations, sign result
and then pass it over to the voter, so that he would not be able to see intermediate
results and would not be able to sign arbitrary messages. Unfortunately it is very
hard to imagine that such solution would justify itself economically.
2.2 Designing Framework
Electronic voting schemes are built upon real world model and supporting services
like PKI and bulletin board. In this section I will consider options for implementing
these prerequisites. In short, they can be called computer and network security.
Bulletin board will be covered in a separate section because it is more application-
specific. Once such framework is implemented, one can concentrate on essential
problems of implementing e-voting.
2.2.1 Real World ModelPreviously, real world abstraction was introduced in terms of actors being capable
of performing randomised computations. In reality actors are often represented
by people (or even organizations) which use their computing devices to perform
computations. Also software must be written for these devices. For this reason it
seems sensible to introduce the following requirements:
Computing Device The computing device must be:
Correct Execute instructions of provided software correctly.
Untappable Computing devices memory should not be readable by any-
body else than devices owner. This includes both volatile and perma-nent memory.
Randomised Computing device should provide a source of random bits for
use in randomised cryptographical algorithms.
Synchronized Clock All computing devices should have synchronized
clocks.
35
8/3/2019 Designing Electronic Voting
37/73
Software Software used must be correct- it must correspond to the algorithms and
specifications. Besides that, most of the people do not write their softwareon their own. This implies that correct software must be somehow delivered
to the computing device.
2.2.2 Computing Device
In general, computing devices are designed to be correct (and lately untappability
has become a widely accepted requirement). In order to prevent computer from
being secure the following must be done:
Gain access to the computer either virtually or physically 4 .
Execute software instructions.
Computer cannot be viewed without software running on it (OS, application
software, shared libraries), which might have occasional or intentional bugs, which
enable external entities to manipulate computer, including executing any software
instructions and inspecting permanent or volatile memory.
In the context of contemporary personal computer, the following problems ex-
ist:
General purpose software is written with emphasis on functional require-
ments and not so much dependability (because the former, not the latter gives
profit, unless the latter is critical). As a result, contemporary software sys-tems are flooded with security vulnerabilities.
Another problem related to contemporary ways of software distribution: lots
of programs are installed, and usually installation programs have full access
to the system and can modify any feature of it, including introducing back-
doors for unauthorized access to the system from outside. Although software
firms might not have motivation to do such things themselves, it is enough
to have one of their employees to do that.
Many people can gain virtual or physical access to the computer.
In general the following can be done to ensure computing device to be correctand untappable:
Use minimal, fixed, verified set of necessary software (including operating
system).
4There also exist ideas how to wiretap computer from distance by measuring magnetic field, etc.
36
8/3/2019 Designing Electronic Voting
38/73
Use refined access control system, which gives minimum needed rights to
the installed software by default.
Limit access (including physical) to only relevant personnel.
It is generally agreed that contemporary PC is quite insecure (not enough cor-
rect and untappable). At the same it is probably possible to create secure comput-
ing device, because most of the problems exist due to historical reasons or lack of
economical motivation. Also, the smaller and more specialized the system is, the
simpler it is to make it secure.
A clear borderline should be drawn between the limited number of computers
used by organizers and almost unlimited number of computers used by the voters.
The amount of resource that can be invested into securing organizers computers is
orders of magnitude higher than for voters computers, which should generally be
used as is.
What regards securing voters computers, two trends should be mentioned.
First, recently multiple different handheld mobile devices have become affordable
to large masses. Designing such device from scratch gives a good opportunity to
implement robust security from the ground up. Also some devices could be cre-
ated with fixed set of preinstalled unmodifiable software, which would increase
security of such device a lot. In practice such devices are not principally more
secure than usual PCs. Another idea is to have a tamperproof device (called smart-
card) having a processor and memory chip, but otherwise being not self-contained,
and keep there some well managed (even better, fixed) software and data (secrets).
The latter could be in secret even from the owner of the card himself (e.g. private
key). Smartcards have an interface through which other devices can communicate
with them. Smartcards are activated by entering PIN code, which is usually passed
through the device to which smartcard is attached. Definitely smartcards have their
own security threats (see [Sch99]), most remarkable of them is that the device to
which smartcard is attached, after the PIN code has been entered, can manipulate
the card in any uncontrolled way (sign any messages) and also reveal PIN to any-
one else. This implies that device to which smart card is attached must be rather
secure itself. Another problem is that most of existing computers are not equipped
with smartcard readers and it will probably take a long time before they become
widely adopted.
Besides being correct and untappable, the computing device has to be ran-
domised. Randomness can be retrieved from special physical device or a crypto-
graphic primitive (algorithm) called pseudorandom bit generator, which must still
be seeded with small random piece of information, which is usually collected based
on the behaviour of the computing device, which depends on (unpredictable) ac-
tions performed by the user.
37
8/3/2019 Designing Electronic Voting
39/73
The best what can be done to keep computing devices clocks synchronous is
to use periodically Network Time Protocol ([NTP]) to synchronize them with sometime servers clock. Simple NTP (SNTP), suitable for usual computers, provides
accuracy of 1 second, which should be sufficient. Also care must be taken to avoid
bugs when dealing with time zones.
2.2.3 Software
Software correctness is a direct implication of the quality of software development
process. In order to increase trust towards software, development process, source
code, and supplementary documentation must be reviewed and certified by some
external trusted parties. After there exists trusted source code from which software
can be built, it must be delivered and deployed at the computing device. A problemarises here, because despite the fact that the source code of the software was certi-
fied, it does not imply in any way that the binary distributable that is received was
built from that source. The solution is to require software p ublisher and certifiers
to sign the distributable and express in this way their trust towards software with
respect to specified purpose. In this case each certifier would need to receive the
source code, inspect it, build binary distributable, and finally sign it. This implies
that all certifiers should be able to produce exactly the same distributable, which
means that the build tool (compiler) must be deterministic (which they hopefully
are, or at least can be made quite easily). It is natural to expect that framework for
expressing trust by signing binary distributable should be a part of PKI. We will
see later to what extent it is supported now. Another option is to require certifiersto sign the source code, distribute it, and expect end-users to build it themselves,
which is quite unrealistic and also time-consuming.
2.2.4 Threshold Trust
The first evident rule is that each component must be made reliable and secure as
much as possible. The following component failure scenarios and countermeasures
could be considered:
Random Failure Failure events of different components must be made indepen-
dent (in the sense of theory of probability). In this case probability that morethan
components will fail is:
38
8/3/2019 Designing Electronic Voting
40/73
where
is probability of failure of one component. For instance if
,
and , the probability of failure of threshold trust is less than
. Note that
cannot be too small, because for instance
in the case of
the probability of failure would be
.
On the other extreme, if the events of failure are completely dependent (i.e.
if one component fails, all components fail) no advantage is gained as com-
pared to case
.
Active Adversary It must be ensured that each component must be broken sep-
arately from the others so that adversary would need proportionally more
resource to break
components.
Colluding Components Actors, which control components (or indeed are them)should not wish to cooperate with each other to break the service. This is
largely a political issue of selecting actors.
Described countermeasures require components to be independent. The fol-
lowing could be done to ensure independency:
Independent implementations and manufacturers (hardware, OS, libraries,
software).
Independent resources:
Physical location Power supply
Network
Different operators and organizations.
An interesting issue arises in the context of reliability (where service remains
working as long as
components are functioning correctly and can communicate)
when components can be fragmented into two or more segments that cannot com-
municate with each other (e.g. network failures). In such situation components in
each segment would consider components in the other segment failed as it is not
possible to decide whether connection has failed or component is not communicat-ing intentionally. Now, if there are two segments each containing
components,
each of them could form the service on its own, leading to the situation of split
mind. If this is an issue, protocols and algorithms should be designed to avoid
such situation. The simplest way is to require
or at least to require that
one can contact more than components.
39
8/3/2019 Designing Electronic Voting
41/73
2.2.5 Connection
Connection between computing devices must be dependable: it should be possible
to send a message from one address to another without a failure. There are two
ways of assessing system dependability: how system acts on average (reliability)
and what can happen in the worst case, especially, if some entity is interested in
bringing the system down (safety, security).
Internet is the first and probably the only candidate for connection implemen-
tation. It provides functionality to send messages between nodes (computing de-
vices) having IP addresses. Internet can be viewed as a collection of interconnected
local networks (segments) and consists of the following basic components which
are built one on upon another:
Physical link layer Physical devices providing local packet (message of limited
size) sending functionality within one segment, which may have its own
address system (OSI 5 physical and link layers.)
Network layer Provides means of sending packets between any IP addresses.
Special computing devices called routers are used to join segments and find
suitable path for each packet. Packet sender does not get trustworthy infor-
mation about whether packet has reached its destination. Nothing is done if
packet sending fails. Packets can be received in an order different from the
order of sending. (OSI network layer.)
Transport layer Provides means of establishing virtual connection between any
two IP addresses, where messages of any size can be sent in both directions.
Messages are split into packets, which are sent separately. Receiver is sup-
posed to send acknowledgement about receiving each packet. Packets that
do not reach destination (which are not acknowledged by the receiver) are
resent. As a result, sender has a good evidence of whether message has
reached the target. Also the order of messages (in one direction) is guaran-
teed to remain the same. (OSI transport layer)
Domain Name System (DNS) IP addresses are numeric and hard to memorize.
To solve this problem, each Internet node can be assigned one or more sym-
bolic name, which is easier to remember. DNS provides a service of mapping
symbolic names to IP addresses. DNS service is implemented as a world-
wide distributed hierarchical set of computers, each of which keeps a part of
this information and is supposed to know where to get the rest.
5OSI (Open System Interconnect) reference model - an ISO standard defining seven layers of any
network implementation. In practice nobody follows it precisely, but it is a good reference model.
See [OSI].
40
8/3/2019 Designing Electronic Voting
42/73
Applications Networked applications making use of previously described compo-
nents.
On the average it can be said that reliability of Internet is acceptable, but in
the presence of active adversary Internet is by no means dependable. Further, the
following context will be assumed (although most of arguments apply to any sit-
uation): application server (implemented by a limited number of nodes) to which
multiple clients (nodes) connect.
When attacking in described context, the following direct aims can be set:
Prevent nodes from communicating with each other (clients from connecting
to server).
Modify transmitted information.
Create illusion of communication with fake address (either DNS or IP).
The attacks themselves can be classified into the following groups:
Damage, modify, fake, or overload components of the infrastructure:
Links
Routers
DNS servers
Nodes (application server, client)
Although originally Internet was designed to resist nuclear attack, thereshould be multiple independent paths between any nodes without common
links, at the current moment Internet has become mostly hierarchical with
relatively low level of redundancy: both from the viewpoint segment con-
nections and DNS. As a result, for most of node pairs it is possible to find
an intermediate link or server (router or DNS server), which when removed
would disconnect these nodes one from another. Also, it should be relatively
simple to disconnect specific node from most of the others by breaking link
or intermediate server close enough to it. In addition, if attacker penetrated
some link or intermediate server (or the attacker is indeed the operator of the
component), he would be able to imitate communication with any IP address
behind him. Finally, there exist effective methods to overload communi-cations infrastructure, known as Denial of Service attacks (DoS), discussed
later.
It is important to point out, that most of components of the infrastructure
belong to one specific entity, which must be trusted in order to rely on the
connection.
41
8/3/2019 Designing Electronic Voting
43/73
Damage, modify, or fake data of:
Local routing (within one segment)
Routers
DNS
As a result packets would be sent to wrong destinations, or would not reach
targets at all.
Attack protocols of any layer (link, network, transport) in order to break,
modify, or fake connections.
The following weaknesses of the infrastructure are usually employed:
Ability to gain physical or virtual access to infrastructure components, pos-
sibly with help of so called social engineering, which targets at human
beings instead of surpassing technical or computational protection methods.
Bugs in underlying software: operating system, networking components,
protocol implementations, application software. Probably the most impor-
tant of them is so called buffer overflow error, where memory area right
after the buffer is overwritten when writing to buffer too long data without
proper size checking.
Finally the basic protocols (ARP, ICMP, RIP, IP, TCP, DNS, etc) themselves
have security vulnerabilities, which can be used against the aims of the in-
frastructure.
As an example, lets consider an attack of overloading infrastructure compo-
nents called Denial of Service (DoS). The general idea is to send more garbage
information than link or intermediate or application sever can process with an aim
to consume some kind of resource: either bandwidth, computational power, or for
instance memory. As a result legitimate users would not get through. Attacks
can be (and usually are) initiated from multiple nodes, the total resource of which is
higher than one of the victim (in this case attack is called Distributed DoS). Attacks
can be application specific in such a way that attacker needs much less resource to
generate the garbage than the victim to process it, for instance if victim tries todecrypt sent messages. As a result less resource is needed to bring the component
down. One could ask why attacker would have more resource than the victim. On
one hand states elections is an important event and so a lot of resource could be
spent to bring it down. On the other hand attacker is always one step ahead of
victims operators: first they set up some resource, and then attacker has a chance
42
8/3/2019 Designing Electronic Voting
44/73
to gain enough resource to run DoS. Finally, as experience shows it is relatively
simple to break into multiple Internet nodes and manipulate them externally. Alsoprotocol vulnerabilities can be exploited to direct big traffic towards specific node.
Although there is no complete cure for this problem, partial solutions and guide-
lines exist, which lead to attacker needing much more resource to launch the attack,
see [Ero00].
In general, the following countermeasures could be taken to prevent described
attacks:
Proper development process of protocols, software, and hardware.
Proper infrastructure surrounding Internet components, including refined ac-
cess control policy and attack prevention, detection, and response.
Systematic redundancy of connections (bandwidth, independent paths) and
nodes (fail-over and load-balancing clusters)
Legal measures with big punishments for network disruption, which implies
that it should be possible to trace back to the originators of attacks.
The first two of described items are directly related to previously discussed prob-
lem of correctness of software and computational device. In general, only global
measures can rise dependability of Internet substantially.
At the same time the problem of identification can be completely solved within
PKI with help of such cryptographic constructions as Diffie-Hellman key ex-
change, message authentication codes, symmetric encryption, and so on. In short,
provided two connection endpoints have certificates and are able to establish con-
nection, it is possible to establish communication channel, which would provide:
Authenticity It is clear which PKI identity sent received data.
Integrity Data cannot be modified between connection endpoints.
Confidentiality Data cannot be wiretapped between connection endpoints.
Non-repudiation Ability to prove that received data was sent by corresponding
PKI identity.
There exist implementations of this approach for network layer ([IPSec]), transport
layer ([TLS]), and DNS system ([DNSEXT]). These protocols also help rising the
quality of connection establishment, because non-repudiation helps proving that
some component behaved incorrectly (e.g. provided incorrect information), but
only post factum. Also, this measure will be effective only when most of Internet
nodes start following them, which is not the case at the current method.
43
8/3/2019 Designing Electronic Voting
45/73
Besides that, network was required to be synchronous: there should exist upper
bound on how long does it take from the moment message is