designing electronic voting

Upload: anon452731347

Post on 07-Apr-2018

219 views

Category:

Documents


0 download

TRANSCRIPT

  • 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