deﬁning an architecture for blockchain e-voting systems ... · relevant domains which are in this...

Defining an architecture for blockchain e-votingsystems

Utrecht UniversityBachelor thesis - Information Science

W.B. [email protected]

5516072

M.L. van der [email protected]

4176405

Supervisor 1dr. Sergio España Cubillo

[email protected]

Supervisor 2dr. Christof van Nimwegen

[email protected]

July 7, 2017

mailto:[email protected]




Preface

This Bachelor thesis will be the completion of the Bachelor program of Information Science atUtrecht University. This thesis project taught us a lot about blockchain and voting processes ingeneral. Before the project we were curious about the technology but did not know how it workedin detail since the domain is relatively new and complex. We therefore enjoyed working on thethesis a lot and we hope that this research provide useful information for anyone who is inter-ested in blockchain technology and electoral processes.

We would like to thank all the people that have been involved in establishing this thesis withspecial thanks to our supervisor dr. Sergio España Cubillo for giving us valuable feedback andpointers to complete this thesis. Moreover, we also want to thank Joep Meindertsma from ARGUfor his exceptional feedback on the intermediate deliverables of this thesis, which really helped usduring the design process of the proposed architecture. Besides, we also want to thank Joachimde Koning and Robert de Groot from Internet of Coins for their technical feedback on the pro-posed architecture.

Yours sincerely,

W.B. Liefhebber & M.L. van der LaanUtrecht July 7, 2017

1

Abstract

This thesis defines an e-voting architecture based on blockchain technology. Within current de-centralized blockchain e-voting implementations there are several problems under which poorprivacy protection of voting behavior and inappropriate use of blockchain technology. Theseproblems have led to a situation in which current blockchain e-voting systems actually are not anysafer than centralized e-voting systems that do not use blockchain technology. Therefore, in thisthesis, there will be described how e-voting processes can potentially be enhanced by applyingblockchain technology in an appropriated manner. This is done by presenting an implementation-independent ’blueprint’ of a set of interrelated components, which is also called a (software) ar-chitecture.

First of all, in order to create an architecture, it is important to provide an in-depth analysis of therelevant domains which are in this case electoral processes, blockchain e-voting implementationsand information security. This analysis revealed that each electoral process has its own set offlaws which resulted in a few companies that tried to solve these problems with blockchain. Inorder to better understand how these implementations work, the domain analysis also containsan in-depth analysis of how blockchain works. This analysis revealed that blockchain can po-tentially solve some serious problems which centralized solutions cannot solve such as preciselytrack actions, immutable data and prevent that a vote can be casted multiple times by a singlevoter. The domain analysis also revealed that the use of a blockchain that can only be altered by asingle party is undesirable and eliminates almost all strengths of blockchain. Besides, the domainanalysis also indicated that voting from the voters’ own device is undesirable since there cannotbe guaranteed that the device does not contain malicious software.

The results of the domain analysis were used in order to create an architecture which tries tosolve the problems in current e-voting implementations. This has led to a proposal which usescryptographic techniques such as linkable ring signatures in order to preserve privacy on theblockchain. Moreover, by using public key cryptography there has also been researched how toprevent disclosure of voting behavior during election day. Together with these important factors,this architecture also contains practicalities like synchronization of nodes, the internal softwarestructure of the voting booths, generating truly random numbers and more.

Although the proposed architecture is not used in an actual election yet, the proposal has beenvalidated with help of experts in the domain of both e-voting and blockchain. This has led to adesign which has acceptance of the experts in the domain but it still needs to be researched in areal situation whether security measures like linkable ring signatures really preserve privacy ofthe voting behavior.

Keywords: E-voting, blockchain, linkable ring signature technology, encryption, voting processes

2

Contents

1 Introduction 7

2 Research methodology 82.1 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Design Science Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Problem Investigation 103.1 Structured Literature Review (SLR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Identification of research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.2 Selection of relevant studies and evaluation of quality parameters . . . . . . 113.1.3 Collecting relevant knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.4 Data synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Domain analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.1 Information security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Electoral process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.3 Blockchain technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Stakeholders and goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.1 Candidate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.2 Voter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.3 Proxy voter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.4 Member of polling station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.5 Central Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.6 Hacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.7 Goal modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4 Success criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Treatment design 364.1 What is an architecture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2 Architectural style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.1 MVC-architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.2 Synchronization between nodes . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.3 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.4 Generating random numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.5 Usage of public and private keys . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.6 Light Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 Requirements for a blockchain architecture . . . . . . . . . . . . . . . . . . . . . . . 404.3.1 User stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.2 Technical requirements and constraints . . . . . . . . . . . . . . . . . . . . . 43

4.4 E-voting blockchain architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4.1 Non-technical specification: BPMN 2.0 models . . . . . . . . . . . . . . . . . 454.4.2 System interaction specification: Use Cases . . . . . . . . . . . . . . . . . . . 504.4.3 High-level technical specification: UML Component Diagram . . . . . . . . 584.4.4 Low-level static technical specification: UML Class Diagram . . . . . . . . . 594.4.5 Low-level dynamic technical specification: UML Sequence Diagram . . . . 63

3

CONTENTS 4

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5 Treatment validation 705.1 Validation of non-technical specification . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.1.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.1.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2 Validation of system interaction design and high-level technical specification . . . 725.2.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3 Validation of static and dynamic low-technical specification . . . . . . . . . . . . . 755.3.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6 Discussion 796.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7 Conclusion 81

Appendix A Glossary 86

Appendix B Infographic 91

List of Tables

3.1 Proposed constructs including their synonyms . . . . . . . . . . . . . . . . . . . . . 103.2 Collected literature per search engine with quantities which indicates how many

papers were included and excluded (SLR step 2), inspired by Da Silva et al. [1]. . . 123.3 Total amount of papers that will be analyzed (SLR step 3), inspired by Da Silva et

al. [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4 Overview of electoral processes and their (current) concerns. . . . . . . . . . . . . . 243.5 An overview of blockchain e-voting implementations . . . . . . . . . . . . . . . . . 28

4.1 An overview of all user stories including requirement classification and prioritization 414.2 An overview of all technical requirements including prioritization . . . . . . . . . . 434.3 An overview of all technical constraints. . . . . . . . . . . . . . . . . . . . . . . . . . 444.4 A step-by-step description of how a potential voter can register him- or herself . . 514.5 A step-by-step description of how a voter can cast a vote . . . . . . . . . . . . . . . 534.6 A step-by-step description of how the votes are being count . . . . . . . . . . . . . 564.7 A step-by-step description of the CA prepares the elections . . . . . . . . . . . . . . 57

A.1 A glossary of all important concepts that are used throughout this research . . . . 90

5

List of Figures

2.1 Design Science Approach, design cycle by Wieringa [2]. . . . . . . . . . . . . . . . . 9

3.1 Intersection between the four constructs defined during SLR step 1. . . . . . . . . . 113.2 An overview of a hashing process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 An overview of an encryption process, inspired by Pfleeger & Pfleeger [3, Figure

2-18]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 Roadmap of the Dutch House of Representatives election. . . . . . . . . . . . . . . 163.5 BPMN 2.0 model of the process of voting in the Netherlands, inspired by Kiesraad [4]. 173.6 BPMN 2.0 model of the process of counting voting in the Netherlands, inspired by

Kiesraad [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.7 Roadmap of the United States presidential elections, inspired by USA.gov [5]. . . . 193.8 BPMN 2.0 model of the voting process in Bergen (NJ) county, USA, inspired by The

Hall Institute of Public Policy [6] and VerifiedVoting.org [7]. . . . . . . . . . . . . . 203.9 BPMN 2.0 model of the counting process in New Jersey, USA, inspired by The Hall

Institute of Public Policy [6] and VerifiedVoting.org [7]. . . . . . . . . . . . . . . . . 213.10 BPMN 2.0 model of the voting process and adding proposals on an online social

lobby platform, inspired by ARGU [8]. . . . . . . . . . . . . . . . . . . . . . . . . . . 233.11 Overview of blockchain headers of different blocks, inspired by BitcoinWiki [9] and

Wander [10]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.12 iStar 2.0 model of the stakeholders and goals in an electoral process. . . . . . . . . 33

4.1 An overview of the architectural style including typical steps that are taken in orderto communicate between nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 An overview of the registration process of the proposed system architecture. . . . . 464.3 An overview of the voting process of the proposed system architecture. . . . . . . 484.4 An overview of the components and subsystems within the blockchain e-voting

system (connection between subsystems inspired by Fakhroutdinov [11]). . . . . . 594.5 UML Class Diagrams of the proposed blockchain e-voting system. . . . . . . . . . 624.6 UML Sequence diagram for use case 1: Registration of a voter. . . . . . . . . . . . . 644.7 UML Sequence diagram for use case 2: Casting a vote. . . . . . . . . . . . . . . . . 654.8 UML Sequence diagram for use case 3: Counting votes. . . . . . . . . . . . . . . . . 664.9 UML Sequence diagram for use case 4: Preparation for election. . . . . . . . . . . . 67

B.1 Infographic, a short paper-based presentation of what has been done during theexecution of this thesis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6

Chapter 1

Introduction

The right to vote is one of the pillars of modern democracy and gives people the power to expressand push their ideas into a certain direction. Voting can be done on multiple levels of complexityfrom electing a new President of the United States to deciding about which pizza is going to beordered with a group of friends. Because voting and making decisions is such an important fac-tor in society, the government (and other (e-)voting organizations) can simply not afford to makemistakes. Recently, there were issues found involving the voting system used for the House ofRepresentatives elections in the Netherlands. The Dutch government found out that the currentlyused software is insecure because hackers are able to influence the results of the election [12]. TheDutch government therefore decided to get rid of the software systems and start counting ev-erything by hand (which is not only error-prone but also time-consuming). The 2017 generalelections in the Netherlands have shown that this is not a fault-proof solution, because almost10.000 votes disappeared and more than 1.000 votes were accidentally assigned to the wrong per-son or party [13]. The Netherlands is not the only country who struggled with insecure (e-)votingsoftware. In Virginia, USA [14, 15], anyone who voted between 2003 and 2015 could be exposedto hacking activities (e.g. vote alteration). Other variants of frauds found in other electoral pro-cesses are people who vote multiple times, inappropriate proxy voting, impersonation problemsand more [16]. In other words, there are multiple threats to the validity of current (e-)voting sys-tems and it is therefore important to investigate alternatives for these voting systems.

Blockchain is a technological innovation which makes it possible, if used properly, to guaran-tee data immutability in a distributed manner. This implies that blockchain technology can beapplied in order to make auditing fault proof which is of large interest in many domains like ac-counting and banking but also electronic voting. In other words, according to Antonopoulos [17]blockchain technology gives the opportunity to: ‘shift from trusting people to trusting math’. In thecontext of blockchain technology distributed means that every computer in the network has acopy of the entire system which makes it possible to verify every action from every computerin the network. Furthermore, data immutability is phenomenon which describes a situation inwhich data can only be created and not edited, updated or deleted.

In conjunction with the description above, the main goal of this research is to investigate howblockchain technology can contribute to a transparent voting process in order to enhance the overall securityof (e-)voting systems.

7

Chapter 2

Research methodology

Based on the problem stated in chapter 1, this chapter will focus on defining research questionsthat will analyze these problems. In section 2.1 an overview of the research questions includingpossible treated subtopics will be given. After that, in section 2.2, the Design Science approach isexplained and the three stages are connected to the research questions. This section also indicatesprecisely which tasks are executed during the research.

2.1 Research questions

Regarding the goal mentioned above, there are multiple research questions (RQ) that should beanswered. First of all, the first research question (RQ1) will show what blockchain is and to whichextent it is currently used (which give insights into how blockchain can help voting systems).Additionally, it will give insight in the domain of (e-)voting systems as currently look like withoutthe use of the blockchain. The second research question (RQ2) will show how a blockchain votingsystem should look like. This means that the architecture is described, including what is requiredwithin the infrastructure of the system regarding the context the system operates in (e.g. enoughrunning nodes). Lastly, the third question (RQ3) will describe multiple aspect related to privacy,authorization and integrity. For example, preventing that identity can be exposed by the contentof votes, verifying that someone has the rights to vote about an item (authorization) and that dataremains consistent. Furthermore, security aspects such as data consistency (data not altered) aredescribed. The following research questions will be covered:

• RQ1: How do current voting and blockchain systems operate within their own context andhow can they be aligned?

• RQ2: How should the architecture of a blockchain e-voting system be structured?

• RQ3: How can fraud be prevented by the use of blockchain technology compared to current(e-)voting systems?

2.2 Design Science Approach

For this research project, the Design Science approach as defined by Wieringa [2] is used. Thisresearch methodology consists of two cycles: the engineering cycle and design cycle. The engi-neering cycle consists of the entire process from defining and investigating the problem to imple-menting and evaluating a treatment. Contrary to the engineering cycle, the design cycle containsthree steps which again starts with investigating the problem but stops after validating the treat-ment (see Figure 2.1). The following three phases are defined in the design cycle:

• Problem investigation: This phase consists of describing the current situation with a cer-tain problem containing additional information such as why there is a problem and whichparties are involved.

8

CHAPTER 2. RESEARCH METHODOLOGY 9

• Treatment design: This phase consists of specifying requirements and investigating if theserequirements contribute to the goals described in the first phase. Additionally, the artifact ofthe research project is created during the treatment design phase, containing the treatmentto the problem mentioned in the first phase.

• Treatment validation: In this phase there will be tested whether the artifact meets the earlierproposed requirements.

Figure 2.1: Design Science Approach, design cycle by Wieringa [2].

Below, there will be described how the three phases mentioned above are executed within thecontext of this thesis:

• Problem investigation: In order to better understand how voting systems and blockchainsystems currently operate within their own domains (RQ1), we will conduct a Structured Lit-erature Review (SLR). The methodology of the SLR will be based on that of Kofod-Petersen[18]. Besides, to gain a greater insight in the domains, we will also conduct a domain analy-sis, investigate how blockchain from a technical point of view looks like, identify the stakeholdersand define success criteria which are used in the treatment validation phase to validate thetreatment design.

• Treatment design: Within the phase of treatment design, the respective domains of (e-)voting, blockchain and information security will be integrated. For integration of thesedomains, we will develop an architecture (or blueprint of the system) which describes thestructure of the blockchain e-voting system (RQ2). In order to structure this system we willdefine requirements based on the problem investigation phase, describe both the dynamic andstatic structure of the system and define a step-by-step precise communication model between thesystem and the stakeholder.

• Treatment validation: In the third phase of the design cycle, there will be tested whether thearchitecture developed in the treatment design phase is sufficient in a way that it preventsfraud compared to current (e-)voting systems (RQ3). Validation of this developed architec-ture will be performed by conducting semi-structured interviews with stakeholders, wherebywe use the generic requirements, architecture models and success criteria developed in theproblem investigation and treatment design phase.

Chapter 3

Problem Investigation

In this chapter the first phase of the Design Science Cycle will be explored namely the probleminvestigation phase. At the end of this phase an answer to RQ1 will be provided (How do currentvoting and blockchain systems operate within their own context and how can they be aligned?). This chap-ter will start with a so-called Structured Literature Review (section 3.1) followed by the domainanalysis of the most important areas (i.e. information security, electoral process and blockchain insection 3.2). After that, the stakeholders and their goals are determined (section 3.3), the successcriteria for validating the design are defined (section 3.4) and the chapter will be closed with aconclusion that answers RQ1 (section 3.5). To provide an overview of all mentioned importantconcepts, a glossary is provided in Appendix A.

3.1 Structured Literature Review (SLR)

A so-called Structured Literature Review (SLR) can be defined as: “a formal way of synthesizing theinformation available from available primary studies relevant to a set of research questions” [18]. There-fore, this methodology developed by Kofod-Petersen [18] (SLR in Computer Science) suits thisresearch because it supports retrieval of relevant information regarding the research questionschapter 2. The SLR methodology consists of five distinctive phases including identification of re-search (3.1.1), selection of relevant studies, evaluation of the quality parameters (3.1.2), collectingrelevant knowledge (3.1.3) and synthesize the data (3.1.4).

3.1.1 Identification of research

According to Kofod-Petersen [18] the most important task in this phase is to identify all relevantliterature based on specifying main constructs. Relevant literature regarding this thesis containsinformation about blockchain technology, e-voting, electoral voting processes and security. Thesecan be defined as the main constructs during the SLR step one. In Table 3.1, an overview is givenof all related constructs and their synonyms.

Table 3.1: Proposed constructs including their synonyms

Blockchain E-voting Electoral process SecurityTerm 1 Bitcoin Voting Electioneering CryptographyTerm 2 Smart contracts Electronic voting Elections Cyber securityTerm 3 CryptocurrencyTerm 4 Distributed Ledger Technology

In order to find the most relevant literature, it is important to search for information that is relatedto all four groups or in other words: ".. the intersection of the sets” [18]. The literature found in theintersection of all groups contains relevant data in a way that the literature that is retrieved willshow an interface with all the (main) constructs (see Figure 3.1).

10

CHAPTER 3. PROBLEM INVESTIGATION 11

Figure 3.1: Intersection between the four constructs defined during SLR step 1.

In order to find the intersection between the four main constructs described above, it is importantto state a search strategy based on boolean operators (∧ and ∨) which are compatible with thesearch engines that are used in the context of this research (i.e. Google scholar, Scopus and Sci-ence Direct). With this search strategy, only relevant information is retrieved regarding the topicsof this thesis because the literature contains all relevant topics or main constructs by performingthis search strategy. The following generic query is used to retrieve the literature:

([Blockchain, Bitcoin]∨ [Blockchain, Smart contracts]∨ [Blockchain, Cryptocurrency]∨ [Blockchain, Distributed Ledger Technology]) ∧ ([E-voting, I-voting] ∨ [E-voting,Voting] ∨ [E-voting, Electronic voting]) ∧ ([Electoral process, Electioneering] ∨ [Elec-toral process, Elections]) ∧ ([Security, Cryptography] ∨ [Security, Cyber security])

This query is used multiple times in a way that a single term between the square brackets is cho-sen for a certain proposition. For example, one of the main constructs is blockchain, but basedon the synonyms we stated above the term ’Blockchain’ can be replaced by for example ’Smartcontracts’ when the word ’Blockchain’ is not included. This means that we will find literature thatincludes at least the four main constructs, but these main constructs can be individually replacedby their respective synonyms (note: blockchain and smart contracts are not exactly the same but weare also interested in articles that only mention smart contracts). An example of the proposed genericquery in a specific case would be:

(Blockchain ∨ Smart contracts ∨ Cryptocurrency) ∧ (E-voting ∨ Voting ∨ Electronicvoting) ∧ (Electoral process ∨ Elections) ∧ (Security ∨ Cyber security)

3.1.2 Selection of relevant studies and evaluation of quality parameters

Based on the terms and concepts in the previous section, it is important to define which literatureis included and which is not. First of all, it is important to only take papers into account that havea point of contact with at least one term of each group (intersection of the constructs). Besides,criteria are being set in order to control the amount of articles that will result from the query (SLRstep 2, subsection 3.1.1), as suggested by Kofod-Petersen [18]. During the selection process, thefollowing procedure will be applied:

• Only English literature

• Only literature whereby the full-text is accessible

• Non-scientific material will not per se be removed (e.g. books)


Besides these specific criteria, more generic principles such as filtering duplicates and removingsame content from different sources will also be eliminated. Moreover, the following seven ques-tions are used to judge the literature based on their content (SLR step 3) and could therefore becalled ’quality parameters’ (partially taken from [18]):

• Q1: Is there a clear statement of the aim of the research?

• Q2: Is the study placed in context of other studies?

• Q3: Are system or algorithm design decisions justified?

• Q4: Is the test data reproducible?

• Q5: Is the experimental procedure thoroughly explained and reproducible?

• Q6: Are the performance metrics used in the study explained and justified?

• Q7: Are the test results thoroughly analyzed?

• Q8: Is the material related to RQ1, RQ2 or RQ3?

3.1.3 Collecting relevant knowledge

In this section, there will be represented what has been found during the process of searchingliterature. For every paper, article or patent the selection criteria and the quality parameters areused to determine whether the literature will be used throughout this thesis or not. For the col-lection of the information, multiple search engines are used under which Google Scholar, Scopusand ScienceDirect. An overview of SLR step 2 (as seen in [18]) is given in Table 3.2.

Table 3.2: Collected literature per search engine with quantities which indicates how many paperswere included and excluded (SLR step 2), inspired by Da Silva et al. [1].

Digital library Amount of collected papers Included papers Excluded papersGoogle Scholar 29 29 0Scopus 17 17 0Science Direct 7 1 6Total 53 47 6Percentage 100% 88.67% 11.33%

As seen in Table 3.2, 88.67% of the total collected papers were included, because almost all paperswere written in English and were fully accessible. Regarding the relevance of the material, only31.91% of the included papers will be analyzed. An overview of the total amount of papers thatwill be analyzed (SLR step 3, as seen in [18]) will be given in Table 3.3.

Table 3.3: Total amount of papers that will be analyzed (SLR step 3), inspired by Da Silva et al. [1].

Digital library Papers Duplicate papers Irrelevant papers Total selected papersTotal 47 2 30 15Percentage 100% 4.26% 63.83% 31.91%

3.1.4 Data synthesis

In this section, there will be elaborated on the so-called data synthesis which implies that metricsare defined. These metrics indicate how much information there has been extracted in the previ-ous section. There has been decided to use two metrics, namely precision and recall. Precisioncan be defined as the set of relevant articles in the total amount of discovered articles (takes truepositives and false positives into account) while the recall can be seen as the probability that the


query proposed earlier returns something truly relevant [19].

precision = |relevant documents⋂

retrieved documents||retrieved documents| = 47

⋂53

53 = 88.67%

As seen above, the precision value is very high. From all the documents that were retrieved,88.67% of these were relevant according to the criteria set in SLR step 2. This precision is highdue to the fact that almost all the papers passed the selection criteria in SLR step 2, which were alimited amount containing general aspects such as language and accessibility.

recall = |relevant documents⋂

retrieved documents||relevant documents| = 15

⋂47

47 = 31.91%

Furthermore, during SLR step 3, the relevant documents from SLR step 2 were evaluated andanalyzed regarding their relevance to the topics used within the context of this thesis. As seenearlier, multiple quality parameters were presented in order to judge this literature on their rel-evance. From the 47 documents that were selected in SLR step 2, 15 documents are relevant forthis thesis, representing 31.91% of the relevant documents (after checking the quality parametersdefined in SLR step 3).

3.2 Domain analysis

In this section there will be elaborated on the so-called domain analysis. In this analysis the do-mains that are relevant to answering the research questions stated in chapter 2 will be analyzedand explained. In the context of this thesis, we earlier proposed four main constructs during SLR.These constructs are accommodated under three domains because e-voting has both a point ofcontact with blockchain as with electoral processes. Therefore, the domains are information secu-rity (3.2.1), the electoral process (3.2.2) and blockchain technology (3.2.3). For each domain therewill be elaborated on where it stands for, how it is relevant to the proposed research questions,the most important aspects and current applications or processes.

3.2.1 Information security

First of all, information security can be seen as the act of protecting computers against undesirableactions on information, in order to protect valuable assets [20]. The so-called security triad is anaspect of great importance for blockchain e-voting technology. The security triad can be seen asfew key factors that help to identify the level of security of a particular system [20]. All threedeterminants need to be ensured in order to provide a safe system. The explanation for thisphenomenon is that the security of a specific system is only as strong as the weakest link in thecomplete chain. Therefore, it is important to give enough attention to all three determinantsin order to provide a strong and solid system. The security triad consists of three distinctivedeterminants, namely [3]:

• Confidentiality: The only entities (e.g. persons and other computers) that can access thecomputer resources are the ones that are authorized

• Availability: The system must be available when the users wants it to be available

• Integrity: There can be guaranteed that the data is complete and not altered (by unautho-rized access)

To make the security triad more powerful, it can be extended by additional aspects [20]. A few ofthose additional aspects are [3, 20]:

• Authentication: Ability to confirm the identity of the user, to reveal that person the userclaims to be is correct

• Non-repudiation: Every action that happens inside the system, can be traced back to anindividual


• Auditability: Every action that happens inside the system, can be traced back to a particularasset

Beside these determinants, another important subset of computer security is cryptography. Cryp-tography can be seen as “the study of mathematical techniques related to aspects of information securitysuch as confidentiality, data integrity, entity authentication, and data origin authentication” [21]. Cryp-tography is important to both the domain of blockchain and information security itself becauseit provides tools to protect information against a wide variety of attacks. Besides, cryptographyis inherently related to blockchain technology because in order to store information securely onthe blockchain, cryptographic techniques could be used (i.e. hashing). An overview of hashingworks can be found in Figure 3.2. The hashing algorithm makes sure that some text is turned intoscrambled ciphertext whereby the process of reversing this ciphertext to plaintext is impossible.

Figure 3.2: An overview of a hashing process.

Additionally, within cryptography an important concept is encryption and decryption. Encryp-tion can be seen as the process of transforming plaintext into unreadable ciphertext by an algo-rithm, according to Pfleeger & Pfleeger [3]. In order to transform the plaintext, it is importantto put a dependent factor to the algorithm so that it produces different outputs based on thisdependent factor (see Figure 3.3). In this context that dependent factor is called the key. Whenthe same key is both used for encryption and decryption the algorithm is called symmetric andif there are two related keys for encryption and decryption it is called asymmetric. In the case ofasymmetrical encryption the key to encrypt the data is often kept public and the key to decryptis kept private. An important distinction between encryption and hashing is that encryption canbe reversed while hashing is an irreversible process. In the context of e-voting this is importantbecause the data that is submitted by the voters must be kept private from malicious personsand organizations. More information about how blockchain and cryptography are related can befound in subsection 3.2.3.

Figure 3.3: An overview of an encryption process, inspired by Pfleeger & Pfleeger [3, Figure 2-18].

Although it seems that information security itself consists of a purely technical domain, this is notthe case because humans are often involved and often the weakest link in the security chain [22].Moreover, humans make mistakes (also called human errors), but also perform ‘deliberate acts’whereby a person misuses corporate data on purpose [23], such as altering the results of a votingprocess on purpose. Because the human is an important determinant in computer security, riskmanagement is another sub domain of information security. There are several concepts that areimportant in risk management, according to Pfleeger & Pfleeger [3]:

• Vulnerability: A particular weakness in the system that can be exploited by a maliciousentity (e.g. humans and other computers)

• Threat: Set of actions that together can cause an exploit

• Control: A certain entity (i.e. technique, procedure or action) that reduces the vulnerability


3.2.2 Electoral process

In this section there will be looked at several concrete examples of how a certain election takesplaces in a certain domain. In this section we will therefore look at three specific situations: TheDutch House of Representatives election, presidential elections of the United States of Americaand an online social lobbying platform. For each of these voting processes, its characteristics willbe explained, its purpose in society, how the voting is being performed and concerns regardingthe system are being determined and explained.

Dutch House of Representatives elections

The Dutch House of Representatives (in Dutch: ’Tweede Kamer’) elections are used to assign the150 seats of the Dutch Parliament [24]. Therefore, the Dutch people have a certain amount of in-fluence in who is going to be included in the Parliament. In Figure 3.4, an overview of the electionprocess is presented in the form of a BPMN (Business Process Modelling Language) 2.0 model.

First of all, the Dutch voting systems, compared to for instance the system in the USA, is based onproportional representation (PR). This implies that the amount of votes are directly translated to acertain amount of seats in the House of Representatives. For example, if a political party receives30% of the votes, that political party will receive 30% of the seats in the House of Representatives[25]. The total amount of votes are divided by the amount of seats that are available, namely 150.The amount that will result from that formula is called an electoral quota (in Dutch: ’Kiesdeler’).When a political party divides its total amount of votes by the electoral quota, it will show howmuch seats they are entitled to obtain [26]. In the Netherlands, the voting threshold (in Dutch:’Kiesdrempel’) is one seat. This implies that to take part in the House of Representatives, a politicalparty must obtain at least one seat (one time the electoral quota). Otherwise, the political partydoes not take part in the House of Representatives. For example, when 10 million people voteduring the general elections, the electoral quota is 10.000.000

150 = 66666, 67 votes. A political partymust at least obtain 66667 votes to obtain a seat in the House of Representatives. When a politicalparty obtains one million votes during the elections, it will receive 10% of the total amount ofseats, which is exactly 15 seats of the total amount. In practice, the numbers of votes that partiesreceive are not likely to look like this. For example, a party may receive 5,3 percent of all totalvotes. The amount of votes that is missing after assigning all true obtained votes will be dividedto the parties that have the most rights to obtain another seat. Afterwards, the political parties thatobtained one or more seats will be divided over the room regarding the total amount of votes andpolitical preferences. After this process is completed, the cabinet has to be formed. The cabinetis a set of political parties or politicians that work together to push certain legislation, wherebythe total amount of politicians in the cabinet has a majority in the House of Representatives. Theinformant will consult all parties that made it to the House of Representatives (obtained at leastone seat) to get information about their preferences and demands. The informant will unify allparties that want to participate in the cabinet. The total amount of seats of this parties should beat least 76 in order to get a majority in the House of Representatives. For example, in the electionsof 2017 at least four parties need to form a cabinet in order to get over the threshold of 76 [24].Eventually when no agreement on forming a cabinet is reached, re-elections will take place.


Figure 3.4: Roadmap of the Dutch House of Representatives election.

Regarding the process of voting, the Dutch system is based on paper ballots, whereby no votingmachines are involved. People receive their voting pass at home by mail. When it is election day,people go to a local polling station to redeem their voting right or decide to proxy vote (i.e. votefor someone else). If the individual proxy votes, the person will bring out two votes maximumduring the voting process instead of one (two paper ballots instead of one). Once the voters ar-rive at the polling station, their identity will be checked and matched if the identity displayedon the voting pass and the identity card are equal. When the identities match, the specific per-son is allowed to vote and to receive a paper ballot where he or she can mark his or her politicalpreference. The voter will be highlighted (on the authority pad) to make sure it is not possibleto vote more than one time. In the Netherlands, this paper contains all politicians (and parties)where people can vote for. The voter is only allowed to color one box red to vote for a particularpolitician out of all the boxes that are available. Afterwards, the voter folds back the paper andthrows it into a sealed box (ballot box) to cast the vote. If the voter wants to change his or her votebefore casting, this is possible by asking a new paper ballot. The old paper ballot is marked inorder to not let it count in the counting process. The process of counting votes has changed overthe years. Currently, the votes are being count by hand (which is error-prone), because electronicsystems in the past were unsafe and insecure to prevent hackers from altering the results of theelection [12]. First of all, the unused ballot papers are sealed to prevent them being used in thecounting process. Afterwards, the ballot box is opened and the counting process will start. Thepapers ballots will be organized and categorized based on the vote on political party and theirrespective party members. These stacks will be counted and filled onto the report that is beingset up by the chairman of the polling station. When all members of the polling station agree, thereport is being signed by them. Then the results are made public and the paperwork and voteswill be packed and transported to the town hall [4]. An overview of this process can be foundin Figure 3.5 and Figure 3.6. To maintain the simplicity of the model, only a positive scenariois included. This means that after some tasks (for example after the task ’Identity is checked andconfirmed’, there is no alternative path included where the process goes ’wrong’ (the identities’always’ match in the model, although this is not always the case whereby the voter leaves thepolling station).

During the elections, the identity of the voter is important. The voter has to show that he or shehas the right to vote (by bringing an ID and a paper ballot) but within the context of this electionit is important that it is not possible to trace the vote back to the (original) voter due to privacyconcerns (the vote is casted without a voter ID, and stored in a sealed box).


Figure 3.5: BPMN 2.0 model of the process of voting in the Netherlands, inspired by Kiesraad [4].


Figure 3.6: BPMN 2.0 model of the process of counting voting in the Netherlands, inspired byKiesraad [4].

Observing the House of Representatives elections in the Netherlands, the status of the system canbe judged by:

• Votes disappeared: During the counting process, it may be possible that (because of count-ing by hand) ballot papers are left out. This means that although the vote is valid, the votedoes not count because it is not taken into account during the counting process. Intendedor not intended, it might also be the case that ballots can being made invalid or destructed.For example, a member of the polling station may color another box or tear apart the ballotpaper which makes it invalid, which leads to vote disappearance.

• Votes altered: An example of vote alteration in this context would be that a member of thepolling station accidentally assigns a vote to the wrong candidate or party, for example byputting it on the wrong stack. This will alter the ’vote data’ of the ballot paper.

• Misuse of proxy voting: This electoral process is currently vulnerable to the misuse of proxyvoting in a way that the person who casts the vote may intentionally or unintentionally votefor another party or person then the person has suggested.


• Misrecording of votes: Since votes are counted by hand it is almost impossible to preventmistakes when counting votes, whether on purpose or not.

• Voter impersonation: The Dutch electoral process is safeguarded against voter imperson-ation since the voter needs to give his or her ID-card before the ballot paper is provided.

• Secret ballot voting: This electoral process supports secret ballot voting because when aparticular voter brings out a vote, the ballot paper cannot be tracked by a particular person.

United States presidential elections

In the United States presidential election there are several stages which together decide who isgoing to be president and who is going to be vice president. Figure 3.7 illustrates every stagecontaining additional explanation. The most important finding shown in this figure is that votinghappens multiple times during the election, in contrast to what we have seen at the House of Rep-resentatives elections in the Netherlands. First of all, party members from a particular politicalparty (e.g. Democratic or Republican party) can vote for their favorite candidate of their party.The results of this primary round (primaries and caucuses) will be used in the so-called NationalConvention whereby every political party selects a candidate that is going to try to become pres-ident. Most of the time the winner of the primaries will also win the national convention whichimplies that the national convention is more of a formality than it really is a decisive factor [27].Nevertheless, the National Convention is the second time in the US presidential election that thegeneral population can vote. Thirdly, after the National Convention, the general population willvote for one of the candidates that were presented at the several conventions of the political par-ties (both a president and vice president). This vote will be taken into account in the ElectoralCollege. The Electoral College is a group of people who have the final call on who is going tobe president. Every state get a number of electors based on their representation in the congress.The candidate who gets more than 270 votes from the electors (538 in total), wins the electionand become president [5]. Most states require the elector to vote on the candidate with the so-called ‘popular vote’ (the candidate that has the most votes) but since not all states require that, theElectoral College is not only a formality [28].

Figure 3.7: Roadmap of the United States presidential elections, inspired by USA.gov [5].

Regarding the systems that are used during the US presidential elections, each state can choosewhich type of system they want to adopt and use. This also implies that on the level of statesthere might be determined if for example votes are required to be able to be traceable back to thevoter. According to Osgood [29] country-wide adoption of blockchain will be near impossiblein the United States because the process of voting is governed at the level of individual statesinstead of the federal level. Although a country-wide adoption may not be possible, at the levelof individual states results might still get altered. As seen earlier, in the state Virginia anyone whovoted between 2003 and 2015 could be exposed to hacking activities such as vote alteration [14,15].In this section we therefore pick a US state as example and illustrate how the process is taken place


and if there are any problems. Contrary to the Dutch elections, some states are using electronicvoting machines for the US presidential elections. To give an example of a voting system contraryto the Dutch system of voting, Figure 3.8 shows the voting process during elections assisted byan electronic voting system in New Jersey.

Figure 3.8: BPMN 2.0 model of the voting process in Bergen (NJ) county, USA, inspired by TheHall Institute of Public Policy [6] and VerifiedVoting.org [7].


Figure 3.9: BPMN 2.0 model of the counting process in New Jersey, USA, inspired by The HallInstitute of Public Policy [6] and VerifiedVoting.org [7].

First of all, in New Jersey citizens are required to register themselves for the elections in orderto be able to vote on the election day. This process must be finished 21 days before the electionday. Once the election day is started, the polling stations open at 6AM. Then, voters will comein. When voters are unable to vote on the election day, it is possible to so-called ’absentee’-votein person or by mail. In person is possible until the last day before the official election day, at oneprovided location. In addition to that, absentee ballots can be send by mail to a specified addressone day before the official election day [30].

In contrast to the Dutch elections, in New Jersey voters are not required to show their ID becausethey already identified themselves by setting up the register document. The voter will providethe board workers his or her name and address whereby the board working will verify these con-ditions to see if the voter has completed the register process. After that, the voter will sign theauthority pad whereby the board worker will verify if the signature of the authority pad and theregistry form match. Then, the voter is allowed to go to the electronic voting system in order tocast his or her vote. He or she will receive a ticket for the system which is teared in half by a boarddirector before entering. This will eliminate the chance of voting multiple times. Once in frontof the system, the voter has to select a candidate and sometimes will have to answer (multiple)questions in order to finalize the vote. When the specific candidate is not on the list, the voter canmanually type in the name of the candidate. When the voter has filled in all his or her preferences,the voter will push the red button to cast the vote. When this process is done, the voter will leavethe polling station [6,7]. The elections will close at 8 PM and after that moment the votes are beingcount (see Figure 3.9). Within a state (like New Jersey) this might differ per county whereby somecounties (e.g. Bergen) do automatic vote counting will others (e.g. Burlington) count by hand.To make the situation even more complex, counties within a state also differ in which software


they use to count the votes (e.g. Bergen uses AVC Advantage while Sussex uses iVotronic), andsometimes the voting process is done by using a system while sometimes the counting process isdone manual [31]. The great majority of the counties in New Jersey are using automatic countingtechnology. Firstly, this process will require that the RAM cartridges that stored the vote data arebeing removed and either transported physically or send by a modem to the tabulation facility.When the data is arrived at the facility, the cartridges are being read out and all the data is storedinto a vote tabulation database. Then, all cartridge data is combined and results will be producedand shown to the public.

Observing the US presidential elections voting systems in New Jersey, the status of the systemcan be judged by:

• Votes disappeared: In this electoral process, votes cannot disappear because voting hap-pens fully electronically. However, during the process of counting votes (see Figure 3.9),the cartridges can be either transported physically or by a modem. When being transportedphysically, there is a chance of destruction of the cartridges which contain the vote data.

• Votes altered: Since transport of cartridges happen physical or through modem (see Fig-ure 3.9) the chance exists that they can be compromised. For example, by sending the car-tridge data via a modem, it is possible to execute a man-in-the-middle attack which canresult in unauthorized modification of data. Furthermore, during transport it is possiblethat the data on the cartridge is altered (by reading the cartridge and editing the data beforedelivering it to the tabulation facility).

• Misuse of proxy voting: The process of proxy voting is vulnerable to misuse because votingoptions send by mail can be compromised.

• Misrecording of votes: When the candidate is not on the list, it is required to manually typein the name of the candidate [6]. Typing errors may occur during the voting process whichresults in ignoring the vote.

• Voter impersonation: In New Jersey, an ID is not required when a voter casts his or hervote. Because of the registration prior to the elections, this step is left out during the votingprocess. This makes the process therefore vulnerable to voter impersonation because theidentity of the person who claims to be that person is not checked (only by signature).

• Secret ballot voting: In the United States it is not required to keep votes secret like forexample in the Dutch elections. Therefore, this electoral process does not support secretballot voting.

Online social lobbying platforms

Regarding online social lobbying platforms, these types of platforms are more accessible for peo-ple compared to the situations described earlier in this section because (in most cases) everybodycan register without requirements. These platforms contain possibilities for people to add newproposals containing their wishes and demands whereby other people can vote about these sub-jects. In contrast with the situations described earlier, this voting process is (mostly) not aboutselecting a particular candidate but about voting about a specific subject or piece of text. In thiscase, people log into the site or forum and either are going to vote about a specific case or pro-pose one. When voting about a specific case, people show if they vote for, neutral or against acertain statement. Sometimes, they might be able to add new arguments or indicate which ar-guments were most valuable for coming up with their vote. Then the vote is submitted onto thewebsite. When creating a new proposal, mostly the user will have to come up with a fair amountof background information and arguments to start the debate about the subject. Then the pro-posal is submitted and people will be able to vote on it. An overview of this progress is shown inFigure 3.10, containing a BPMN 2.0 model.


Figure 3.10: BPMN 2.0 model of the voting process and adding proposals on an online sociallobby platform, inspired by ARGU [8].

Regarding the privacy of the voters, it is important in a platform or context like online sociallobbying platforms that the identity of the voter can be traced back. Especially when addingcomments or arguments to a certain subject, it is important to trace back the source of the infor-mation. This is in contrast with the other situations described above, because in these cases it isimportant to respect the privacy of the voter and keep votes anonymous (although in the case ofthe US presidential elections this may differ per state and per county). Observing the process ofthe social lobby platform, the status of the system can be judged by:

• Votes disappeared: Since every step of the process is fully automatic, disappearing votesare unlikely when database access is properly enforced.

• Votes altered: Vote data can be hacked and altered (in a system where proper securitymeasure are not implemented).

• Misuse of proxy voting: Not applicable in this situation because proxy voting is not a func-tion which occurs in the system.

• Misrecording of votes: Since every step of the process is fully automatic, misrecording ofvotes does not happen in this context.

• Voter impersonation: In this context voting impersonation is also a problem because theidentity of a certain user cannot be verified.

• Secret ballot voting: Since accounts of users aren’t verified, somebody can cast a vote inanonymity by choosing an alias when the account is created.

Overview of the current electoral processes

Multiple examples of electoral processes have been presented and although they look different,they share some important characteristics. First of all, within each system people can vote abouta particular subject and cast this vote. Only the context differs, for example electronic (such as theUS presidential elections) and paper-based (Dutch House of Representatives elections). Further-more, the privacy towards voters may be different. Within some processes it is important to havetraceability of the person’s identity who casted a vote, for example with Online Social Lobbyingplatforms. Within another context, such as the Dutch House of Representatives elections, it isundesirable to be able to trace back the identity of the person behind a specific vote (also called asecret ballot). Therefore, although the process may have the same intentions (vote about a specificproblem), the context of the process is very important regarding multiple aspects.

Since every system is judged by the same criteria, there can now be given an overview of whichproblems are occurring in which systems. In Table 3.4 there is a systematic overview of what


has been provided in this section. When a minus (-) is defined, this implies that the problemoccurs within the system, while when a plus is defined (+) this means that the electoral process isresistant to the problem. When a slash (/) is defined, this implies that the problem is not relevantto the context of the electoral process.

Table 3.4: Overview of electoral processes and their (current) con-cerns.

Occurring problems Dutch House of Rep-resentatives elections

US Presidential elec-tions

Online social lobbyingplatforms

Votes disappeared - - -Votes altered - - -Misuse of proxy voting - - /Misrecording of votes - - +Voter impersonation + - -Secret ballot voting + - -

As seen in Table 3.4, all current electoral processes contain multiple concerns. Some of them areresistant to some problems by having a different approach to vote, while enabling other vulnera-bilities that electoral processes do not have. There can also be concluded that some concerns areshared in multiple processes (such as vote alteration). In the next section (subsection 3.2.3), wewill take a closer look to current implementations of blockchain e-voting systems to see whichproblems they solve and more importantly, in the context of this thesis, which they do not solve.

3.2.3 Blockchain technology

As stated earlier in chapter 1, blockchain technology can be seen as a distributed database wherebyevery participating computer has the ability to verify the activities in the network [32]. This sec-tion contains a technical description of blockchain, the difference between public, private andconsortium blockchains, mining and an overview of existing applications.

Technical description

There are several important technical concepts within the context of blockchain technology, suchas Merkle trees, transactions, nodes, blocks, forks and the consensus. This paragraph will consistof an explanation of the key concepts and the relationships between them.

First of all, the concept blockchain can be seen as the name suggests: a chain of blocks. Blockrefers to a collection of transactions which are chained [33]. In context of blockchain, a transactioncan be seen as any entity that holds value (e.g. vote on certain candidate or a bitcoin transfer froma certain wallet) and thus is stored in a single block. In other words, to chain the transactions inblocks on the blockchain it is necessary to inherently make the blocks related to each other (seeFigure 3.11). This is done by the concept of hashing which can be seen as the practice of reducingdata of any length to a fixed length (e.g. 32-bits) [34]. Each header of a block in the blockchaincontains a field with a calculated hash over the previous block header in the chain. In this waythe chain can only be valid when it is in the right order with the right blocks. If a block is missing,(fraudulently) altered or placed in wrong order, the hashes in the header will be entirely differentand thus will be rejected. Caiazzo & Chow [33] support this statement: "if the transaction data ofany block were changed, the fingerprint of all of the subsequent blocks would also have to change. Thisstrategy of generating fingerprints protects against malicious tampering". This rejection can be donewhen the node (i.e. computers that have a local copy of the blockchain) that produces the rejecteddata communicates with the other nodes. A node comes in two variants namely full nodes andLight Clients whereby a full node has the entire state of the blockchain stored locally while theLight Client only has a (necessary) part of the state stored. When a blockchain network becomeslarge (i.e. gigabytes of data) it becomes infeasible for smaller clients to retrieve the entire state of


the blockchain when someone wants to join the network. In order to prevent this problem theintroduction of a Light Client is necessary so that only a part of the blockchain state is needed inorder to use the blockchain. It is possible to establish a Light Client with help of Merkle Trees [35].

The cryptographic concept of Merkle trees is used for transactions inside a single block. A Merkletree is a mathematical tree whereby ’a leaf value can be verified with respect to a publicly known rootvalue and the authentication data of the leaf’ [36]. The ’publicly known root value’, also called theMerkle root, is important so that only the relevant part of tree needs to be used to verify newtransactions in a particular block (i.e. only the path from leaf to root). Besides, the Merkle root isalso used to verify the order of the chain [36]. Moreover, ’authentication data of the leaf’ impliesthat the data itself is also used to verify new transactions in the block. This is possible becauseevery new leaf in the tree is based on the value of the parent and therefore creates an inherentrelation between all direct children in the tree.

The relationship between existing and new blocks in the chain can change over time by a tempo-rary, soft or hard fork. When a temporary fork occurs it implies that some blocks can be verifiedparallel to each other [37]. For the other two concepts (i.e. hard and soft fork) it is important tounderstand that blockchain is a distributed technology. There may exist the possibility that overtime two or more nodes in the network start to disagree with each other about the rules that wereestablished to add new blocks in the chain (consensus). When forward compatibility is main-tained (i.e. new blocks of disagreeing node can still be added) it is called a soft fork, and whenthere is no forward compatibility it is called a hard fork [37].

Figure 3.11: Overview of blockchain headers of different blocks, inspired by BitcoinWiki [9] andWander [10].

Again, Figure 3.11 illustrates that a block consists of a header and a Merkle tree whereby thefollowing header fields are taken into account (specific to the algorithm used in Bitcoin so thisheader is only used as illustration [9]):

• Version number: The particular version of blockchain protocol which

• Timestamp: The time when the block was created

• Bits: A hash which is used in order to determine the difficulty of creating new blocks

• HashPrevBlock: The calculated hash over the previous block which makes it possible tochain the blocks together

• HashMerkleRoot: The hash value which ties the transactions and the chains of blocks to-gether

• Nonce: A field which is important in the context of creating blocks because it contains thehash that needs to be calculated


In subsection 3.2.1 the concept of public and private keys were explained. In the context of manyblockchain applications like e-voting and the Bitcoin protocol, this is an important concept. Witha Bitcoin wallet the public key is used to look up information like transactions and balance but theprivate key is necessary for performing transactions [38]. In the context of e-voting it is the casethat the public and private key are going to be used in order to protect the votes against maliciouspersons and organizations but also to keep voter identities and their respective votes private.

From this technical analysis there can be concluded that blockchain can:

• Precisely track actions: Since the transactions inside a block are intertwined by the Merkleroot and the block is intertwined with the other blocks by the ’previous block’-header, itopens up the possibility to track precisely what happens in the blockchain. When blockchaintechnology is implemented properly it becomes impossible to switch, remove or alter blocksand transactions.

• Solve the double spending problem: Since actions can be tracked so precisely in the blockchain,it is even possible to state that a single asset inside the blockchain (e.g. a vote or bitcointransfer) can only be spend once.

• Intervene if an illegal action take place: Opposed to a central stored database, in blockchainevery node can validate whether a certain action confirms the consensus protocol. When aparticular agent performs an action that does not align with the consensus (the rules thatare defined for adding a block), the other computers in the network can decide to decline.

Private, Public and Consortium blockchains

Blockchain comes in three main types regarding which party can add transactions to the blockchain.First of all, there is the public blockchain whereby everyone is allowed to add transactions to theblockchain [39]. In order to prevent malicious actions it is important in public blockchains toput some economic value on creating transactions. For example, in Ethereum in order to createtransaction, it is necessary to pay a small amount of Ether (i.e. the currency of the Ethereumplatform). Contrary to public blockchains there are private blockchains which implies that theseledgers are controlled by a single party [39]. A mechanism to prevent malicious actions in a pri-vate blockchain does not make sense because there is just one single party controlling the entireblockchain. Therefore, the main problem with private blockchains is that it can solely be used asaudit control by a Central Authority (CA, not to be confused with a Certificate Authority). Forsome industries this is still an important instrument because it makes it possible to precisely trackaction within a system for a particular party (e.g. accounting or banking) although it is possible todelete transactions. However for e-voting, the problem of private blockchains is strongly unde-sirable because it makes it effortless for a malicious authority to manipulate election results (i.e.just add transactions with votes for the desired object or candidate).

Somewhere between the public and private blockchain there is a hybrid solution called the con-sortium blockchain which implies that two or more parties are eligible to add transactions to theblockchain (partially decentralized) [39]. When these parties are independent of each other orthere are a lot of parties involved the disadvantages of the private blockchain may be ruled out.However, it still remains a problem when a certain party owns a greater part of the computationalpower or economic value (depends on the used mining algorithm, see next paragraph) in the net-work. When this occurs this party has the possibility to exploit the blockchain with a so-called51%-attack [39]. This implies that the respective party now has the possibility to create, alterand delete transactions and blocks without consensus of the other parties. However, there mustbe said that altering and deleting blocks and transaction may be computationally difficult withinlarge blockchains because the hashes in the block headers and transactions need to be recalculatedin order to have a valid chain.


Mining

In the context of blockchain an often discussed concept is that of mining. In a public blockchainmining is used in order to make sure that the transactions are validated and new blocks are cre-ated. In order to prevent malicious behavior on the blockchain, there has been chosen to makemining new blocks mathematically difficult. This implies that in order to mine new blocks it costscomputational power, whereby the more computational power system-wide, the more difficultthe computational problems become to mine [39]. Since there are not many people that want toput their computational power for free in the network there has to be something that rewards theminers. This is why all blockchain systems have some kind of currency, like the Bitcoin or Etherin case of Ethereum.

In order to put blocks on the blockchain there are two types of algorithms that can be used namelyProof of Work (PoW) and Proof of Stake (PoS). These two algorithms differ in the way how min-ers are rewarded for a new mined block. It is thereby important to mention that all miners areinvolved in a new block which implies that the reward must be split among these miners. InPoW the invested mining power (work) of the miner is used as measure for the reward he or shegets while a PoS algorithm rewards the miner by the percent of the currency he or she has. Forexample, when the miner has 1% of all the Bitcoins he or she gets 1% of the mined block valuebecause the miner has a 1% stake in the mining process. It is important with PoS that one partydoes not owns more than 51% of the total currency, because at that point this party can accepttransactions without influence of the consensus. Besides, with PoW it is important that one partydoes not own 51% of the computational power in the network because this will lead to the samesituation with PoS when a party has 51% of the total currency is possessed by a single party [39].

Current blockchain e-voting applications

As stated by Czepluch et. al. [40], using blockchain technology within the domain of e-voting hasa lot of benefits. They state that vote processes can be potentially be automated which removeshuman errors and reduce work time, simplify the process of voting, appreciate the anonymityof voters and reduce significant risks that electronic elections has to deal with [40]. In order tojudge current implementations of blockchain e-voting applications we decided to not model ev-ery process like done in subsection 3.2.2. Instead, the analysis of Osgood [29] will be used whichprovides a clear overview of the implementations that are on the market. The reason why we didnot model every process is that most implementations aren’t open to public and therefore cannotbe tested and analyzed. An overview of the current applications and their strengths and weak-nesses can be found in Table 3.5.

First of all, FollowMyVote requires the user to install the necessary software modules (online vot-ing booth) on their PC, smartphone or tablet, whereby voters have to authenticate themselvesas legal voters by uploading personal documents such as a photo of an ID-card [41]. When theapplication is installed, the users upload their material in order to gain access to the ballot. Afterthat, the user can submit its ballot into a blockchain-based ballot box. Within the context of Fol-lowMyVote, it is made possible for users to change their vote after it has been cast. As concludedby Osgood [29], FollowMyVote has many security flaws in the system: "authentication of the user isquite hard, remote voters can easily be intimidated, and voter’s personal computer could be compromised".Besides the problem that authorization is hard, it is also vulnerable to impersonation, since onlya copy (photo) of an ID-card could make a local machine (such as a smartphone) legal to gainaccess to vote under a specific identity. When someone obtains an ID-card of someone else, heor she could easily gain (unwanted) access. Furthermore, votes can be altered or disappearedbecause by using software that installed at the smartphone or personal computer of the user, thise-voting implementation can be compromised and the votes can be altered. Furthermore, proxyvoting can be performed by the use of own devices because it isn’t necessary anymore to be phys-ically available at some place. Although the project is still active, it is currently out of funding [41].


Secondly, Votebook [42] proposed a system which is similar to the process people know it nowa-days in the US, whereby a voting system is used to cast votes. The voters have to register beforethe election day in order to attend the elections whereby each voting system is connected by aVirtual Private Network (VPN). After casting the vote, the voter identification number (voter ID)will be encrypted with the key of the CA and the choice of the candidate will be added in plain-text to a block on the blockchain. Receipts are being printed (paper ballots) whereby one will bestored at the polling station and one will be handed over to the voter. Afterwards, the blockchainis released to the public and votes are being counted [42]. The developers of Votebook decidedthat only the CA has access to the blockchain (i.e. a private blockchain).

VoteWatcher [43] also proposed a system whereby voting is done on paper ballots and these arescanned and stored in a (local) blockchain. This solution is almost similar to the one Votebook hasproposed (i.e. authorization happens in person with help of the CA). The final blockchain will befilled from multiple local blockchains. These local blockchains are running at each voting stationwhere people are able to vote. Local blockchains aren’t convenient because it destroys a part ofthe functionality of the blockchain namely the shared consensus (i.e. rules which decide what canbe added to the blockchain) between nodes because the participating devices aren’t connected toeach other. This makes this system therefore more vulnerable than when the blockchain is con-nected with other nodes.

According to Osgood [29], VoteWatcher’s belief is that voting from own devices is still not pos-sible because of security issues, compared to the solution FollowMyVote [41] proposed. Vote-Watcher uses scanners (Optical Mark Recognition software) to scan the paper ballots [43]. Byscanning these ballots, the results will be uploaded on the (local) blockchain. Regarding the con-cerns mentioned earlier, by using paper ballots, there still exists a chance of the votes being alteredor being disappeared because ballot papers can be left out of the scanning process or the tickedboxes can be altered on the paper itself whereby the result of the scan is different. Additionally,using paper ballots also contains the risk of paper ballots being destructed or become invalidwhich implies that it is not possible anymore to correctly retrieve voting data (for example aboard member makes the ballot paper unreadable for the scanner). To overcome this problem,VoteWatcher makes sure that voters scan the ballots themselves and confirm that the scanner hasscanned the right selection the voter has made [43]. Votebook’s solution [42] contains printingreceipts whereby the paper ballots will only function as an evidence or proof of what has beenvoted. Furthermore, disappearance of data can also occur when the election is completed. Afterthe election is completed, the data is stored on a DVD to serve as a backup. If in some way thisbackup is disappeared or modified unauthorized, the organization cannot know which version(i.e. the backup or the blockchain) is correct. This implies data or votes can disappear after theelection.

Table 3.5: An overview of blockchain e-voting implementations

Occurring problems Votebook FollowMyVote VoteWatcherVotes disappeared - - -Votes altered - - -Misuse of proxy voting - + -Misrecording of votes +/- + +/-Voter impersonation - - -Secret ballot voting - - -


Within this analysis of all current available blockchain e-voting applications, there are multipleshared concerns that are unsolved by the current implementations:

• Votes disappeared: In Votebook’s solution votes can still disappear because only the CAhas access to verify what is added to the blockchain. This implies that the CA owns morethan 51% of the computational power of the nodes which implies that votes can be deleted(although in large blockchain systems this might be hard, see the paragraph ’Public, privateand consortium blockchains’). Moreover, VoteWatcher is also vulnerable for votes that dis-appear because local blockchains are used which implies that there are no other nodes toverify whether the transaction is valid. Besides, FollowMyVote is also vulnerable to disap-pearance of votes because if the own device of the voter has malware installed, it may bepossible that the vote is never written into the blockchain while the voter may think this isthe case. Moreover, if a vote is saved into the blockchain, in case of FollowMyVote, it be-comes less likely that destruction is not possible anymore because the blockchain is public(i.e. less likely to be vulnerable to 51% attacks). With Votebook and VoteWatcher destructioncan still happen because transaction can potentially be removed from the blockchain, whichimplies that votes can disappear.

• Votes altered: All three implementations also suffer from unintentional alternation of votes.This is the case because like described in ’Votes disappeared’ both Votebook and Vote-Watcher are private blockchains and FollowMyVote is vulnerable to malware.

• Misuse of proxy voting: Because voting is done from own device FollowMyVote solves thisproblem while Votebook and VoteWatcher do not take proxy voters into account.

• Misrecording of votes: Regarding the process of counting votes it seems to be the case thatmisrecording votes is not likely. However, it also important to check whether the current im-plementations have the possibility to correct votes after they have been casted. For example,a vote can be casted correctly, but the option that was filled in (intentionally or not inten-tionally) was wrong. Within a blockchain system this becomes challenging because oncedata is stored on the blockchain it is difficult to remove the data (if properly implemented).Only FollowMyVote has functionality regarding casting a second vote where Votebook andVoteWatcher do not have that possibility. Since misrecording during counting is unlikely(opposed to the Dutch situation) but it is desirable to let voters recast their vote, Votebookand Votewatcher have a +/- while FollowMyVote has a +.

• Voter impersonation: In none of the cases voter impersonation was solved. This is the casebecause it is dependent on the process or the context where the system is operating in, butnone of the proposed applications described how this can be prevented.

• Secret ballot voting: Regarding secret ballot voting as seen in Table 3.5, none of the currentimplementations has successfully implemented a solution that contains the possibility tolet people vote in anonymity. Although for example Votebook [42] included secret ballotvoting, it is still possible to trace back identities for the CA. This is the case because thevoter ID is encrypted with a symmetric key of the CA, which implies that the CA can readall the voter ID’s. In this case, the CA could identify which person has voted for which partyor option. This is unwanted in a business situation when for example voting about loweringsalaries or firing people, whereby you want that employees can vote in full anonymity (alsoto the CA). Therefore, also Votebook (and the other implementations) do not perform fullsecret ballot voting. Due to the fact that each node has a local stored copy of the data,it is important that privacy sensitive data is protected by encryption schemes which alsoexcludes the CA from looking into the data. This is the case because voting behavior insome situation might be used against a voter.

Furthermore, none of the implementations made sure that the results are only visible after theelections. For example, during National elections it is undesirable when results are visible earlybecause undecided voters may be biased towards the most popular options. This implies thatall the current implementations of blockchain e-voting lack important mechanisms regarding pri-vacy related aspects.


Current blockchain applications in other domains

According to multiple sources [29,32,40], the most well-known current implementation of blockchaintechnology is Bitcoin. As seen in [32]: ’the Bitcoin protocol is used for the biggest peer-to-peer based pay-ment system and was developed as an alternative to conventional money’. According to Wright and DeFilippi [44], the Bitcoin protocol does not depend on a bank or government and is located in a de-centralized blockchain to establish a digital currency. Wright and De Filippi [44] also state that theBitcoin protocol is much faster in transferring funds compared to current payment systems. Fur-thermore, the Bitcoin protocol eliminates the problem of double spending of coins. Osgood [29]showed that before transactions are put on the blockchain, these are extensively verified to makesure that the assets have not been spend earlier. Osgood [29] also states that within the Bitcoinprotocol, due to its transparency, ’each user knows the current amount of Bitcoins of all users’.

Combinations of blockchain and other domains are endless. According to Swan [45], blockchaintechnology can be applied in other domains as stated above including health care (by healthcoins), academic publishing (journal coins), identity verification and many more. For example, byintroducing blockchain to the (e-)health domain, Swan [45] states that price transparency, healthrecord storage and health research could profit from this introduction.

A platform which gain traction lately is the Ethereum platform of Vitalik Buterin. This pub-lic blockchain platform has a generic approach whereby content of transaction consists of code(called Smart Contracts) which can be executed by a Virtual Machine. This implies that all theapplications named in this paragraph like Bitcoin can potentially built upon Ethereum. Ethereumhas therefore a lot of potential and is after Bitcoin the largest blockchain system on the market [46].

3.3 Stakeholders and goals

In this section, the stakeholders and their respective goals for this particular subject are definedand explained. Because every voting system has another origin, it also has other stakeholders(e.g. the Dutch electoral system does not know the concept of the Electoral College). There hastherefore been decided to only take the most common ones into account. For every stakeholderthere will be elaborated what their role is in the system and what their goals are. The followingstakeholders are defined: candidate (3.3.1), voter (3.3.2), proxy voter (3.3.3), member of a pollingstation (3.3.4), Central Authority (3.3.5) and hacker (3.3.6). After that, a model will be providedincluding the stakeholders and their goals by using iStar 2.0 (3.3.7).

3.3.1 Candidate

First of all, a candidate is someone who is selected by others to have the rights to do something.For each voting system the amount of candidates can differ. Within the context of elections suchas the Dutch general election, people can vote for multiple political parties and even for specificmembers of these parties. For a certain election round, these parties (and individual members)have their own ideas which were presented before the elections. In contrast, other voting systemscould have a limited amount of options to choose from such as the US presidential elections.

While in a lot of cases the ’object where people can vote for’ contains candidates (such as general elec-tions or selecting the best athlete during a sports match), other cases do not involve candidates.In these cases a decision has to be made (based on democracy). For example, when decidingabout a specific problem (lowering salaries or firing employees), there are no (direct) candidatesinvolved. This means that the implementation of a candidate is common, but not required in aspecific voting system. When a candidate is chosen as an object where people can vote for, thegoal of the candidate is to gain enough votes so that the candidate can have some sort of impactafterwards. In other words, a candidate wants to be chosen out of all the other candidates. Mostof the candidates therefore go on political campaigns to convince people to vote for him or her. A


concrete example would be that a US presidential candidate wants to become president in orderto actively push his or her agenda.

3.3.2 Voter

A voter can be seen as someone who is eligible or legal to vote. A voter makes a decision basedon their own beliefs to select one of the options that is available during the voting process. Thecombination of the votes that the voters produce will be used in order to determine the results ofthe election. The goal of the voter is, like the candidate, to have some sort of impact on the results.Since in many elections there are many people that are voting, the impact on the results are rathersmall which is called the Downs paradox in rational choice theory [47]. This means that theremust some good reasons why people have this goal since their impact is small. According Blaiset. al. [47] there are several reasons why people vote like political interest, identification with oneof the political parties and previous voting behavior.

3.3.3 Proxy voter

A proxy voter can be seen as someone that is authorized to vote for another person. This otherperson may be not in the country when the election are, physically disabled or just does not wantto vote by him- or herself. The proxy voter has a goal to vote for the other person and select theright choice on the ballot paper. In the Netherlands it is necessary to provide a copy of the ID-cardincluding the signature and the paper which states that the other person has the right to vote [4].

3.3.4 Member of polling station

Within most electoral processes, people are able to cast their votes at a (local) polling station (likein the Dutch House of Representatives elections). These polling stations contain members thatperform certain tasks in order to execute the elections in a proper and secure way. Therefore,a member of the polling station can be seen as the person who makes sure that the electionsare executed properly. This is also the goal of the member of the polling station, while in mostcases these people also have the goal to contribute to the process of the elections. For example,a member of the polling station will verify the identity of a voter within the Dutch House ofRepresentatives elections (as seen in Figure 3.5).

3.3.5 Central Authority

The CA can be seen as the party that runs the election and oversees the execution of the elections.The goals for these central authorities are that the elections run smoothly, without errors andhave a legitimate outcome. This implies that the goals are that there is no misrecording of votes,no ballot invalidation, no vote alteration and disappearance and that the people who vote arelegal to vote.

3.3.6 Hacker

A hacker is a certain person that uses security flaws to gain unauthorized access to systems. Thereare several types of hackers: black hat, white hat and grey hat [48]. A black hat hacker gains unau-thorized access to a system with the intention to make damage like stealing data, deleting data,modifying data or leave back doors. Contrary to the black hat hacker there is the white hat hackerwhich uses his or her hacking skills to point out security flaws to companies in order to make thesystem stronger and more secure. Between those two groups there are grey hat hackers whichcan be seen as hackers that choose what is ethically most suitable to him or her. This means thatin some cases the actions of this hacker can be seen as white hat and in some cases as black hat.

Within the context of voting systems, there will be hackers that have as goal to alter voter data andtry to influence the result of the elections without the consent of other parties. These hackers aretypically black hats, while a white hat hacker will have as goal to find security flaws in the voting


process. These security flaws will be used to prevent the black hat hacker and other maliciousparties to influence election results. In the context of this thesis, when we refer to a hacker, thismeans that it is a hacker with black hat motivations.

3.3.7 Goal modeling

To give an overview of the information in this section, Figure 3.12 presents an iStar model con-taining the goals and relationships between the different stakeholders. An iStar model is focusedon the question why certain goals are related to certain stakeholders. There are a few designconsideration that are worth to mention:

• A candidate is also a voter (’is-a’ relationship) because on election day in most elections,the candidate also brings out a vote. For example, during the elections in the Netherlands,candidates are able to vote. Within this process it is possible that they vote for themselves.

• A proxy voter has the exact same set of goals and tasks as a normal voter, therefore theproxy voter is modeled with a ’is-a’ relationship to the voter.

• To record a vote accurately, the voter is dependent on whether the goals of the hacker arefulfilled. Therefore, there is a dependency link between the voter and the hacker.

• For the same reason as the point above, all lines connected to the soft-goal ’increasing dis-trust public’ at the hacker received a ’+’, because it could also be possible that alteration,deletion or stealing vote data remains unnoticed and therefore does not create any distrustin the public.

• The top goal of the hacker (obstruct elections) can be fulfilled by only performing one of thethree goals that are directly connected namely steal vote data, delete votes or alter votes.Therefore, the design contains an ’OR’ relation instead of an ’AND’ relation whereby alltasks should be performed to fulfill the goal where it is linked to.

• The member of a polling station is also able to vote which implies that the member of apolling station has a ’is-a’ relation with the voter.

• The member of the polling station is part of the CA because it executes the elections andit keeps control or oversee the elections execution. Although this is the case there has beendecided to model it in a separate entity. A separate entity was necessary in order to annotatethat the member is part of the CA but has a different set of goals.


Figure 3.12: iStar 2.0 model of the stakeholders and goals in an electoral process.

3.4 Success criteria

In this section the success criteria are defined which are necessary in order to validate the de-sign which is created in the treatment design phase, following the methodology of Wieringa [2].This validation happens in the final stage namely the treatment validation phase. The followingsuccess criteria are defined (partially taken from [49]):

• Votes disappeared: It would be a success if votes do not disappear or less votes are dis-appearing (contrary to the current situation). In this context, disappeared means that forvarious (mostly unknown) reasons the vote did not make it to the counting procedure suchas votes are being deleted or destructed.

• Votes altered: It can be considered as a success when the choices that some voters made onthe ballot stay consistent when it arrives at the counting procedure (not edited in the mean-time). In current voting processes (e.g. Dutch elections but also blockchain implementationslike Votebook and VoteWatcher) there are moments when unauthorized adjustment of theballot is possible (see subsection 3.2.2 and subsection 3.2.3).

• Misuse of proxy voting: With proxy voting we mean that someone is authorized to votefor another person when he or she is unable to go to the voting booth (for example peoplewith disabilities). Since another person does the actual voting, there exists a chance thatthe authorized person ignores the wish of the person. Current voting processes are notprotected against this kind of malicious behavior and therefore it would thus be a successfactor if after the design phase and with the introduction of a blockchain e-voting systemthis problem can be solved.


• Misrecording of votes: This can occur when a (human or computer) interprets erroneouslywhat has been filled in on the ballot. In the Dutch elections this is especially a problem be-cause counting is done by humans [12]. It can be considered a success factor if the designensures that misrecording of votes is impossible. Moreover, it can also be considered a suc-cess if the architecture has proper working functionality regarding letting the voter correctearlier casted votes if some field is filled in wrong.

• Voter impersonation: It can be considered as a success if the design prevents voter imper-sonation and therefore guarantees confidentiality. Voter impersonation means that someonetakes someone else his or her identity (impersonation) in order to bring out a vote under thatidentity. It is even the case that in some states (like New Jersey), voters are not required tobring an ID-card with them [6]. Moreover, blockchain implementations like Votebook andVoteWatcher rely on the authorization process of the system and do not provide any solu-tion to this problem when the context lacks proper mechanisms.

• Secret ballot voting: It would be a success if the architecture supports a form of vot-ing whereby the ballots stay secret. As seen in subsection 3.2.3 none of the current ma-jor blockchain e-voting applications does support secret ballot voting properly. In subsec-tion 3.2.3 there is mentioned that the use of private blockchains is inconvenient due to thefact that it becomes much easier for the CA to delete or alter votes (contrary to currentelectoral processes). This implies that, from a technical point of view, the use of publicblockchains is the preferred choice. Since within a public blockchain system every partic-ipating node has (potentially) all data stored locally (i.e. voter ID including vote options),it absolutely necessary to take security measures in order to prevent unauthorized accessto voting behavior. Due to the distributed nature of blockchain, the deletion of informationthat is stored will become problematic; it may be the case that deletion of voting data iswanted after the elections. This can potentially result in a situation in which after decadesit is still be known which voter at that time voted for a particular person or object. Secretballot voting becomes therefore a much more important success criteria than in centralizedvoting systems.

3.5 Conclusion

In order to provide an answer to earlier stated research question one (in chapter 2, How do currentvoting and blockchain systems operate within their own context and how can they be aligned?), we firstconducted a Structured Literature Review (section 3.1). Performing this literature review was im-portant because it revealed relevant sources that had a point of contact with every major subjectthat is introduced in this thesis. These major constructs are security, electoral process, e-votingand blockchain technology. Furthermore, the most important domains were analyzed separately.First of all, the analysis of the domain of information security revealed that the security triadand cryptography are important sub domains of information security. Cryptography is impor-tant to blockchain technology because cryptographic techniques are used to connect the chain ofblocks together and connect the transactions inside a single block. Moreover, the security triadis a proper measure whether a certain system does comply with the standard security measuresin the industry. Secondly, in the electoral process domain, three electoral processes have beenanalyzed namely the Dutch House of Representatives elections, the US presidential elections andhow voting is done on online social lobbying platforms. The most important factor that was re-vealed during this analysis is that all of these electoral processes have their own set of problemswhich were sometimes overlapping (e.g. both the online social lobbying platforms and the USpresidential elections are vulnerable to voter impersonation). Furthermore, all the systems havein common that the voter is asked to choose from a range of options whereby the option withthe highest amount of votes will win for a particular state or certain polling. Thirdly, the do-main of blockchain was analyzed including a technical description of blockchain, different typesof blockchains, mining algorithms and current blockchain applications. An important finding inthe technical description is that the domain of information security is intertwined with blockchaintechnology because concepts like hashing and encryption are used in order to chain the blocks and


transactions. Besides, the analysis of the current blockchain e-voting applications indicated thatsome problems in electoral process are solved (e.g. misrecording of votes) while other problemsremain unsolved (e.g. misuse of proxy voting). Moreover, the analysis of the existing applicationsindicates that at the moment Bitcoin is the most popular application of blockchain followed byEthereum. Furthermore, the stakeholders and their respective goals were analyzed in order toindicate which parties are involved in e-voting systems and the interests each stakeholder hasregarding these systems. In order to determine whether blockchain technology is capable of pro-viding a transparent and secure electoral process the architecture will be validated with help ofthe success criteria of section 3.4.

The first research question can now be answered (How do current voting and blockchain systemsoperate within their own context and how can they be aligned?) by dividing the question into threedistinct parts namely how current voting systems operate, how blockchain systems operate andhow they can be aligned:

• How do current voting systems operate? The domain analysis of the electoral process(subsection 3.2.2) indicated that different elections use different systems. In the Nether-lands both voting and counting happens without intervention of a computer system whilein the USA this differs from state to state. In the case of the social online lobby platform,voting happens completely electronic. All of these systems have their own set of flaws withproblems like voter impersonation and misrecording of votes.

• How do current blockchain systems operate? The domain analysis of blockchain (subsec-tion 3.2.3) indicated that blockchain already gained some traction, with Bitcoin and Ethereumas most used applications. Each of these blockchain systems have their own mechanismwhereby public blockchains emphasizes on creating economical value for miners to makesure that the blockchain system stays available while private blockchains are used as in-ternal audit control mechanisms for companies. The main advantages of blockchain arethe possibility to precisely track actions, intervene when illegal actions happen and solvedouble spending of assets problem (see subsection 3.2.3 under technical description).

• How can they be aligned? Like described in subsection 3.2.3 there are already some at-tempts to align voting systems with blockchain technology (e.g. Votebook, FollowMyVoteand VoteWatcher). However, these implementations have some unsolved problems such asthe disappearance of votes. The domain of blockchain and voting can therefore be unifiedby developing an blockchain architecture which solves the problems that occurred in theelectoral processes (see Table 3.4) but also solves problems that are currently not solved byblockchain e-voting implementations (see Table 3.5). The success criteria (from section 3.4)can be taken in order to determine how successful the architecture is in solving the occurringproblems.

Chapter 4

Treatment design

Regarding the problems described in the Problem Investigation phase, which indicate that thereare threats to the validity of current (e-)voting systems, we will now describe a suitable solutionto this problem: a blockchain based e-voting System. To describe this system, we will proposean architecture. Firstly, we will describe what an architecture is (4.1), what the architectural styleof the proposed system will be (4.2), requirements regarding the functionality of the architecture(4.3) and we will describe how the architecture will look like regarding multiple points of view(4.4).

4.1 What is an architecture?

An architecture is often understood as the process of designing, planning and constructing build-ings [50]. In the context of this thesis an architecture will refer to a more specific form of con-structing a particular entity, namely a so-called ’software architecture’. A software architecturecan be seen as a set of interrelated software components that together solve a set of problems in aparticular domain [51]. Within the domain of blockchain e-voting these set of problems will referto the problems that current implementations have not solved yet, for example secret ballot vot-ing. The interrelated software components can be modeled in a wide variety of tools (e.g. UnifiedModeling Language (UML) or Archimate) and it does not necessarily say that an implementationwill be delivered when the treatment validation phase is done. Moreover, throughout the rest ofthe thesis when there is referred to an architecture there will be meant a software architecture.

4.2 Architectural style

In this section we will elaborate on the so-called architectural style. This architectural style can beseen as a set of decisions which together form the general look-and-feel of the system. Examplesof architectural styles are 2-tier, 3-tier and n-tier architectures but also Service-Oriented Architec-ture (SOA) and Model-View-Controller (MVC-)architecture (4.2.1). Furthermore, we will look atsynchronization (4.2.2), signatures (4.2.3) and the use of public and private keys within a systemthat is designed with help of this architecture (4.2.5).

4.2.1 MVC-architecture

The architecture that will be designed in this phase of the Design Science Cycle from Wieringa [2]will be a MVC-architecture. Within this architectural style there are three layers namely theModel, Controller and View. The Controller-layer consists of the routing mechanism of the appli-cation which pulls data from the Model-layer and gives this data to the View-layer. Besides, themodel can be seen as the layer that accesses data storage and has certain methods or proceduresthat makes it possible to extract information from its resources (like a database). The View-layer

36

CHAPTER 4. TREATMENT DESIGN 37

is concerned with presenting the information to the user [52]. There are two reasons why MVC-architecture has been chosen as architectural style:

• Blockchain is distributed: Most architectural styles are coupled to the idea that there is acentral storage place where the data is retrieved from. This is especially the case with n-tierarchitectures since the different layers are stored on different servers (e.g. HTTP servers,database servers, e-mail servers etc.). In the context of blockchain the notion of serversdoes not exist because all nodes in the network have the possibility to store the entire statelocally (hence decentralized). MVC is therefore more suitable because it is a more abstractarchitectural style which just states that some software module needs to be separated intothree distinct layers.

• MVC-architectures work well with graphic intensive systems: The architecture that isdesigned in this phase of the Design Science Cycle does not only consists of a blockchainwith votes, it is also required to have a user interface where options can be selected [52].

In Figure 4.1 an overview is given of the architectural style of this blockchain e-voting architec-ture. Each voting booth has an own MVC-architecture internally. A voting booth can be both acentral device or an own device (the latter is requested by stakeholders of this thesis and thus in-cluded). When the latter is chosen there cannot be guaranteed that the device is not compromisedand therefore it is safe, as we have seen earlier (see subsection 3.2.3). Like stated in the descriptionabove, blockchain has a distributed nature which implies that there is no central server where thedata is stored. Each voting booth is synchronizes with other voting booths by sharing their cur-rent state. When synchronization happens, the voting booth will verify whether the transactiondoes comply with the shared consensus. In Figure 4.1 a typical execution flow is presented by fol-lowing the numbers. First of all, some voter may press a button in the interface which triggers acontroller action (i.e. in Object-Oriented Programming (OOP) this would be a method of a class).After that, if necessary the data is passed to the model and the model will process it and return thedesired results (e.g. add vote to the block and let know that this has been successfully added). Inthe meantime, since a transaction has been added to the blockchain, it is necessary to synchronizethis action with the other voting booths or nodes in the network. The controller will then passthe necessary information to the view which is presented to the user. The view will generate thenecessary output to satisfy the user (e.g. print ticket and show message on the screen).

Figure 4.1: An overview of the architectural style including typical steps that are taken in orderto communicate between nodes.


The idea that a single block is based on a single voting booth and a transaction is a single voteis derived from the implementation of Votebook [42]. It is not strictly necessary to adhere thisstructure but it does mean that synchronization happens differently. The next paragraph doescontain more information about synchronization between nodes.

4.2.2 Synchronization between nodes

It is important to mention how the current state of the blockchain will be synchronized betweendifferent nodes. The distributed nature of blockchain technology makes it possible that everynode in the network has a sufficient state stored on its own machine to verify incoming transac-tions (i.e. in case of a full node the entire state and in case of a Light Client only the necessaryparts). In Figure 4.1 there is shown that each voting booth has an own copy of the blockchainthat is updated through the model layer of the MVC-architecture. Each block stands for a specificvoting booth which implies that when synchronization is necessary (i.e. a vote is casted) the in-formation will be shared with voting booth N - 1 and voting booth N + 1. When voting booth N +1 receives an message that a transaction has been added from voting booth N, voting booth N + 1will send this message to voting booth N + 2. In the meantime voting booth N + 1 will update thelocal copy of the blockchain by adding the received transaction of voting booth N at block N - 1(assuming that a single block represents a single voting booth). In this way, the blockchain is syn-chronized in a distributed manner whereby the voting booths that are geographically close willbe synchronized first. This prevents any form of double voting because synchronization will befaster than walking to another booth in polling station. This form of communication is inspiredby the Distance-vector routing protocol which also uses a distributed methodology in order toshare information on a network [53].

In case voting is done from own devices, it is important that synchronization happens by broad-casting to other participating devices. This is the case because the notion of voting booths thatare geographically close to each other cannot be derived because there are no polling stations. Itis therefore necessary to notify all participating device simultaneously in order to prevent doublevoting. This may have impact on the performance of voting procedure and may not be feasiblewhen elections on level of an entire country are held. According to Mercer [54], one of the great-est challenges currently with blockchain technology is that it is too slow for some use cases (e.g.payment processing on the scale of MasterCard which entitles to put thousands of transactionssimultaneously on the blockchain).

4.2.3 Signatures

In order to determine who has send a particular message, within the domain of information se-curity, so-called digital signatures are used [55]. This digital signature includes a certain messageand a certain sender who are coupled together. In the context of blockchain e-voting this is im-portant because there is a necessity to determine if somebody has already voted. The problemwith plain digital signatures (often used in Public-Key Infrastructure (PKI)) is that anyone canmake a connection with anyone and the identity is revealed [54]. The first property is undesirablebecause the CA (i.e. the entity that organizes the elections) wants to make sure that only a limitedsubset of individuals can vote while the latter property is undesirable because preservation ofprivacy is important in many election cycles (i.e. secret ballot voting).

In order to create a limited group of people which can be identified and tracked, a group of sci-entists created a schema which makes it possible to ’leak a secret’ [56]. In the context of plaindigital signatures this implies that this scheme makes it is possible to define a limited subset ofpeople (i.e. a group) whereby the identity of the individuals is not revealed when some actiontakes place in the group. More specific, when an action takes place in the group, there can beverified that somebody of the group have send that message but there is not revealed who thatparticular person is. The most important downside of group signatures is that the CA can revokethe anonymity whereby every member of the group can see what that particular individual didon the network. In the context of voting this is inconvenient because this will imply that the CA


can see what somebody has voted.

In order to overcome this limitation of group signatures, so-called ring signatures were intro-duced. The most important difference with the group signatures is that in a ring signature scheme,the CA does not have the right to revoke anonymity of the group members [54]. Although in somecases this may be inconvenient (i.e. situations where non-repudiation is an important aspect), inthe context of voting this makes it possible to let only the voter know what he or she has voted.There are different types of ring signatures which try to overcome different problems that areoccurring with plain ring signatures. For example, in plain ring signatures, it is not possible toverify whether a particular person has signed a particular message two times. Therefore, link-able ring signatures were invented which made it possible to verify whether a particular identityhas send multiple messages on the network [54]. It is important to mention that this is a morerestricting property than double spending a particular asset, which is already inherently solvedwith proper implementation of blockchain technology. This is the case because although doublespending of a single entity is not possible anymore, in the context of e-voting it is also importantto connect the asset to a particular person. In this way there can be prevented that a single personcasts two assets (i.e. votes) into the blockchain.

Ring signatures (both plain and linkable) are based on public key cryptography which impliesthat every individual in the group generates a public-private key pair. The public keys are trans-ferred to all the peers in the network and are used to sign messages. This implies that beforea message is send on the network, the message is encrypted with help of all public keys. Thereceiver(s) can now verify that the identity is from someone in the group by using all the publickeys of the group to calculate the hash of the message.

In the context of blockchain e-voting, linkable ring signatures are a convenient way to protectprivacy but also prevent double voting. After all, in chapter 3 there has been mentioned that secretballot voting is one of the success criteria in the context of validating this architecture. The linkablering signature scheme is used to encrypt the voter ID’s that are stored in a single transaction ina block in the blockchain. As seen earlier within some cases, this process is not necessary whenfor example it is important to derive the identity of the voter (for example with Online SocialLobbying platforms), but most types of context require this encryption. This requires that all thepublic keys of the voters are used within the consensus of the blockchain. In this way, the voter’sidentity (identification number such as a student number or BSN-number) will be never revealedand therefore the voter itself can only see what he or she has voted (unless the private key isshared). It does not make sense to also let the voter option be part of the ’ring’ because then itwould be impossible to count the options of the vote. For a technical and mathematical in-depthanalysis there will be referred to the literature [54, 56].

4.2.4 Generating random numbers

The linkable ring signature scheme described in the previous section is dependent on generationof truly random numbers. Computers are not enabled to generate truly random numbers becausecomputer cannot perform random actions. There is always a request from service which triggersthe computer to perform certain actions. An option would be to use a so-called Pseudo NumberGenerator which is like the name suggests not truly random. Like suggested by the stakeholdersof this thesis, a better option would be to let the user perform random actions like moving themouse for N seconds (see for an example how to generate a random string based on user input,such as liteaddress.org).

4.2.5 Usage of public and private keys

In addition to the previous explanation on ring signatures it is important to mention that publicand private keys are used in two separate distinct places in the system:

1. Ring signatures: As mentioned in the previous section, it is not convenient to store the


voter ID in plaintext on the blockchain. It is therefore important that the voter generates apublic-private key pair whereby the public key is shared with the CA and the private key isonly owned by the user (if he or she not decides differently).

2. Signing voter options: When voting options are stored in plaintext, the distributed natureof blockchain makes it possible to read current results from a single device. Since this prop-erty is undesirable for most elections, it is necessary to somehow protect the voter optionsagainst reading during election day. In order to solve this problem it is convenient to let theCA generate a public-private key pair (as opposed to the ring signature scheme wherebythe voter generates a public-private key pair). The public key is stored inside the consensusof the blockchain whereby the voter option, when stored on the blockchain, will be signedwith this public key. Since the voter options are now encrypted, intermediate results canonly be read when a person has the private key of the CA. In this way it is not possiblefor the nodes to read intermediate results before the election ends (and the CA releases theprivate key). Moreover, if the CA cannot be trusted it is necessary to establish a third inde-pendent party which has a key pair whereby the public key is also used to encrypt the voteroptions. Alternatives have been researched like the use of so-called time-based encryption.In time-based encryption the purpose is to lock the voting options during a specific timeslot during the election day. The voting options are then encrypted with a key which isimpossible to break open during the election day. This is a problem since every computerhas different computational power which implies that it is almost impossible to create a keythat cannot be broken during election day [57].

4.2.6 Light Clients

In chapter 3 there is already explained that participating nodes (i.e. own devices or voting booths)can come in two variants namely full nodes and Light Clients. It is important to mention thatLight Clients are a necessity in larger elections because if the blockchain is large it costs a lot oftime to synchronize the blockchain initially. When Light Clients are initialized it is necessary tomake sure that there are enough full nodes in the network in order to retrieve the entire stateof the blockchain. Especially in situation where voting from own device is done, it can becomea challenge to make sure that there are enough full nodes. After all, a voter is only interestedin bringing out his or her own vote and does not want to wait for hours in order to supportthe elections. It is therefore important to create a situation in which people are interested to runfull nodes. For example, in case of Bitcoin a full node is the only way to make sure that yourwallet is absolutely safe because only a full node has the full functionality to check for all typesof fraud (like double spending of assets) [58]. Moreover, a full node gives the opportunity tovalidate every incoming transaction which is important in order to mine new blocks (and thusearn bitcoins). Within this architecture there are two possible options regarding making sure thatenough full nodes are running. Firstly, if an already existing blockchain like Ethereum is chosen,the other application that run on this blockchain can make sure that there are enough full nodes.Secondly, if a public blockchain is built from scratch some kind of currency need to be introduced(e.g. a votecoin) in order to make it appealing enough for people that run full nodes in order tomine. By introducing a currency with economical value miners can run full nodes in order tomine coins and sell them.

4.3 Requirements for a blockchain architecture

In order to provide requirements for the architecture it is important to determine from whichsource these requirements are derived from. In this research the requirements will be derivedfrom the goals of the stakeholders (see section 3.3), success criteria (see section 3.4) and domainspecific concepts (e.g. the security triad in subsection 3.2.1 and the analysis of electoral processesin subsection 3.2.2). In subsection 4.3.1 there will be given the requirements based on the per-spective of the user of the system and in subsection 4.3.2 the requirements from a more technicalperspective are given.


4.3.1 User stories

In order to provide an overview of the requirements based on the perspective of the stakeholdersinvolved in this thesis study, Table 4.1 provides user stories which connects stakeholders to therequirements that they demand from the system. These requirements are separated in terms ofwhether the requirement is functional (i.e. a feature of the system) or non-functional (i.e. anattribute of the system). These user stories will be prioritized based on the MoSCoW-methoddescribed by Benyon [59] (the numbers will be used in Table 4.1):

1. Must have: Very important or fundamental aspects regarding the end product or final re-sult, without these requirements the product is not functioning properly.

2. Should have: The product is usable without these requirements, but these requirements aremuch desired to be included.

3. Could have: Could be more easily left out of the current development, but when there istime left it could be a good addition.

4. Won’t have: Requirements that are not included, but could become interesting when theproject continues in later development.

Table 4.1: An overview of all user stories including requirementclassification and prioritization

# User story Functional(F) or Non-Functional(NF)

MoSCoW pri-oritization

1 As a voter, I want to cast a vote F 12 As a voter, I want to check one or multiple options on the

ballotF 1

3 As a voter, I want to verify whether I’m eligible to vote F 24 As a voter, I do not want to receive a ballot that is invalid F 15 As a voter, I want to make sure that my vote is taking into

account when countingF 1

6 As a voter, I do not want that someone can impersonate myvote

F 1

7 As a voter, I want make sure that my vote is assigned to theright object (e.g. party or person)

F 1

8 As a voter, I do not want that my vote is made invalid ordestructed after submission

F 1

9 As a voter, I want a voting procedure that does not takemore time than necessary

NF 1

10 As a voter, I want to cast a vote in anonymity F 111 As a voter, I want to recast a vote F 212 As a CA, I want to have quickly insights in the results of the

electionNF 4

13 As a CA, I want that only people have access to the systemthat are authorized (confidentiality)

F 2

14 As a CA, I want the system to be available during the elec-tion day (availability)

NF 1

15 As a CA, I want that results are only available after the elec-tion

NF 2

16 As a CA, I do not want that an unauthorized person canmodify the voting data (integrity)

F 1

17 As a CA, I want that every action inside the system, can betraced back to a particular asset (auditability)

F 2


# User story Functional(F) or Non-Functional(NF)

MoSCoW pri-oritization

18 As a CA, I want to prevent that a particular voter can votemultiple times

F 2

19 As a CA I want to set guidelines for the execution of theelection

F 1

20 As a member of the polling station, I want to verify whethera certain voter is eligible to vote

F 2

21 As a member of the polling station, I want to have the pos-sibility to report any problems to the CA

F 3

22 As a member of the polling station, I want to authorize aneligible voter to vote

F 1

In Table 4.1 an overview of all user stories is given including whether it is a functional requirementor a non-functional requirement and the MoSCoW prioritization. First of all, there have beendecided to not let requirements overlap between stakeholders in order to prevent repetition. Forexample, a member of the polling station is in most cases also a voter and a proxy voter has thesame set of requirements as a voter. Furthermore, multiple stakeholders share the same goalsand therefore have shared demands towards the functioning of system. Besides, there are somedecisions made regarding the MoSCoW prioritization which need to be mentioned:

• Availability of system: There has been decided to give the availability of the system thehighest priority (see row 14 in Table 4.1). The reason for this decision is that without systemavailability, votes cannot be cast and therefore the system is not functioning properly.

• Authorization of the voter: Without authorization of the voter, voters are not allowed tovote (see row 22 in Table 4.1). Therefore, this is prioritized as a ’Must have’-requirementregarding the MoSCoW prioritization. The voter ID will be retrieved from either the votingpass or the ID-card of the voter (e.g. student card or employee card), depending on theimplementation.

Furthermore, there are also some requirements that are not applicable to a certain stakeholder butwhere derived from the current applications (see subsection 3.2.3) or observations of the electoralprocesses (see subsection 3.2.2). First of all, there has been observed that every time that a boardmember intervenes in an electoral process (see chapter 3), this potentially can cause problemsregarding the validity of the (paper) ballots. For example, in solutions where the voting processis still done on paper, board members can still invalidate the ballot papers, alter them or makethem disappear. Therefore, an important requirement is to set the intervention of the board mem-bers to a minimum. Regarding the solution of VoteWatcher [43], where they use paper ballots, theboard members’ role is limited. In this case, the board member is unable to alter the vote before orduring the counting process as seen in for example the Dutch House of Representatives elections(as seen in subsection 3.2.2). Furthermore, we have seen that within the electoral process of theDutch House of Representatives elections the board member was useful for verifying the identityof the person who wants to vote, while identification by using a system (such as FollowMyVote)was proven to be hard and insecure [29]. Therefore, the role of the board member should be ata minimum during the voting and counting process, but should be present when identities areverified (authorization). Regarding the process when voting happens from own device, authenti-cation methods that are known (such as SMS, e-mail or random readers) could be used to performthe authentication process. In case of national elections, this is not secure enough, but in othervoting processes (such as voting within a small company or with friends about a certain problem)this authentication method will be sufficient.


4.3.2 Technical requirements and constraints

In the previous section (see subsection 4.3.1) requirements from the perspective of the primaryand secondary stakeholders were proposed which give a proper indication what a certain stake-holder demands from the system. However, user stories are not suitable enough to express tech-nical requirements because these requirements are often not bounded to a particular stakeholderbecause the stakeholders in this context are non-technical users. This section will therefore pro-vide an elaboration on the technical side of the architecture whereby both technical and archi-tectural requirements will considered as equal in this context. These technical requirements arebased on the implementations of current applications of blockchain e-voting systems [29, 41–43].As already explained in chapter 3 these implementations solve particular problems that are nec-essary to include in this architecture in order to provide a solution which covers all problem areas(e.g. all blockchain e-voting implementations solve the problem of misrecording votes so this im-plementation must also have a solution to this problem). In Table 4.2 an overview of the technicalrequirements are given and in Table 4.3 an overview of the technical constraints are provided.The difference between a constraint and a requirement is that a requirement describes a desiredproperty of a system while a constraint ’limits’ the system in some way [60].

Table 4.2: An overview of all technical requirements including pri-oritization

# Requirement MoSCoWprioritiza-tion

Origin

1 The architecture consists of a single blockchain 1 n.a.2 The system will run within annotated time slot during the

election day2 IBM [61]

3 The system is required to be presented in multiple lan-guages

4 IBM [61]

4 The system print paper receipts to serve as backup and con-firmation

3 Votebook [42]& Vote-Watcher [43]

5 Counting of votes should happen without interference ofpeople

1 Problem inves-tigation

6 When not building on an existing public blockchain (e.g.Ethereum), a block in the blockchain will represent a votingmachine (i.e. own device or device in a polling station)

3 Votebook [42]

7 A transaction in a block in the blockchain will represent avote of a particular person

1 Votebook [42]

8 A transaction in the blockchain needs to store a uniqueidentifier called a voter ID

1 n.a.

9 The voter ID within a transaction will be encrypted withuse of a ring signature scheme

1 Architecturalstyle

10 A transaction in a block in the blockchain needs to store theoption(s) regarding the voter

1 n.a.

11 Options that are made by the voter will be encrypted withhelp of the public key of the CA


12 In case a polling station is used, a transaction needs to storethe identification number of the polling station


13 The public keys of all voters should be available for the con-sensus protocol


14 The CA needs to provide a piece of software where peoplecan generate a public-private key pair


15 The system should be able to run multiple rounds duringthe election process on the same blockchain

1 n.a.


# Requirement MoSCoWprioritiza-tion

Origin

16 a predefined program which is enabled to iterate over everytransaction in the blockchain

1 n.a.

There are some decisions made which need to be mentioned:

• A single blockchain: There has been chosen to track actions on single blockchain whichdoes not store privacy sensitive data in plaintext.

• Counting votes: Regarding row 5, it is important to mention that this requirement is de-rived from the analysis of the electoral processes in the problem investigation phase (seechapter 3).

• Paper backup: As stated by Osgood [29], the solutions of Votebook [42] and VoteWatcher[43] contain systems that provide a paper backup for the system. According to Osgood, itis convenient to have a paper backup in case something goes wrong within the digital sideof the elections. Within this thesis, we leave this paper backup as optional (when voting onown systems it is not very likely). The evidence paper that is printed could also be storedas a file on a local (own) device or send by SMS or e-mail.

• Generate public-private key pair: Although the more tech-savvy voters could use the Com-mand Line Interface (CLI) to generate a public-private key pair, the average voter needshelp. This specification therefore requires the CA to distribute a program among the voterswhich makes it easier to generate a public-private key pair (and print or save their votingpasses containing the voter ID encrypted by the generated public).

• Polling station identification number: The requirement describing the identification num-ber of a polling station has the lowest prioritization because it is context-dependent. Withinsome cases (such as the US elections) it is important that different regions can be defined.Therefore, we included the requirement so that a polling station device can be assignedto a specific region by adding a polling station id to the transaction. For the moment, weleave this addition out of the design, but it is important to show that this is possible withinthe design in the future. Besides, this number can also be used to guarantee efficient syn-chronization between nodes which is important when voting happens from central pollingstations (see subsection 4.2.2). When votes are casted from own devices it does not makesense to use polling station identification numbers because there is not known how closedevices are from each other (i.e. broadcasting is necessary).

Next to the requirements, the architecture will also be limited by some (technical) constraints. Anoverview of these can be found in Table 4.3.

Table 4.3: An overview of all technical constraints.

# Constraint Origin1 The voter should not be solely authorized by the system FollowMyVote [29]2 Voting software modules should not be installed on per-

sonal devices of the votersFollowMyVote [29]

3 A voting booth should only run software modules relatedto the voting process

Votebook [42]

4 In case of secret ballot voting, the voter ID should not berevealed to any instance other than the voter itself

n.a.

5 If voting in person, voting booths in a single polling sta-tion need to be stored in a consecutive sequence in theblockchain

n.a.

6 Synchronization between nodes needs to happen on a se-cure line with help of a Virtual Private Network (VPN)

Votebook [42]


# Constraint Origin7 In order to guarantee that the selected voter options stay

secret till after election, the voter must not release its privatekey

n.a.

8 In order to guarantee that election results stay secret duringelection day, the CA must not release the private key that isused to encrypt the voter options

n.a.

Regarding the constraints, as stated by Osgood [29], the FollowMyVote solution is not optimalregarding the authorization of the voter within elections. Therefore it is necessary to have a mem-ber of the polling station which checks the identification of the voter with the ballot (voter ID andidentification must be equal) when elections on a national scale are performed. Furthermore, itis important that the voting process does not happen on personal devices of the voters in criticalprocesses like national elections. As stated by Osgood [29], these personal devices are poten-tially infected with malware and are therefore not reliable. To sustain security, in these situations,voting should be performed on specially permitted devices which only contain software relatedto the elections. However, in less critical situations this should be less of a concern. Within thecontext of this thesis, we will also focus on own device voting since not all contexts require theseconstraints regarding the authorization process. In cases where voting happens within a smallgroup of people, an e-mail or SMS containing a verification code could be sufficient.

4.4 E-voting blockchain architecture

In this section, the proposed architecture including all relevant aspects is explained. Firstly, a non-technical specification will be described from a high-level perspective, by using BPMN 2.0 models(4.4.1). Secondly the system interaction is specified by the use of Use Cases (4.4.2). Thirdly, anUML Component Diagram is provided which will show the technical specification from a high-level perspective (4.4.3). Afterwards, low-level technical specifications are given in the form of aUML Class Diagram (4.4.4) and UML Sequence Diagrams (4.4.5).

4.4.1 Non-technical specification: BPMN 2.0 models

In this subsection, two figures will be presented containing BPMN 2.0 models. First of all, Fig-ure 4.2 will describe the registration process of the proposed blockchain e-voting system, whileFigure 4.3 will describe the voting process. The processes will first be explained and after thatdesign choices are mentioned.

In Figure 4.3, the registration process is described. The model starts with the CA sending mes-sages (by post, e-mail or any other type of communication) to the voters that are legal to vote.These people are informed that they are invited to take part in the elections and need to performsome actions to redeem their voting right. In order to create a voting pass, the person that wantsto register needs to log in to a web-based portal or within business context a tool located on theintranet. When the user has logged in correctly, he or she is able to launch the registration ap-plication within the browser environment. Within this application, the user can generate its ownpublic-private key pair which are needed to vote (or at least the public key is needed). The usercan print, safe or send his voting pass within the environment. On this voting pass, the voter’sidentity is stored in the form of an (by his or her own public key) encrypted voter ID, visualized ina QR code, inspired by Votebook [42]. It is important to mention that the application’s executionenvironment is only established on the client and on the server because this would lead to a situ-ation in which the CA knows which public key belongs to a specific voter. The user anonymouslycasts its public key to the CA and the CA will add all the received public keys to the consensus.


Figure 4.2: An overview of the registration process of the proposed system architecture.


Figure 4.3 describes the voting process of the proposed blockchain e-voting system. First of all,it is important to make a distinction between voting on own devices and voting from a pollingstation. Since the process is different in both ways, we included both paths in the BPMN 2.0-model. Regarding the implementation with the introduction of polling stations, the voter willfirstly enter the polling station. Afterwards, the voter will let check his or her identity wherebya local board member will verify the identification and checks the voting pass. After that, theboard member will give the documents back to the voter and tell him or her that he or she cango to the voting environment. Regarding own device voting, the identity of the voter is beingchecked by an authentication process that is known from other applications. For example, thevoter will receive a verification email or SMS containing specific codes to enter or a link to verify.After this process is done and the voter is verified to continue, he or she will enter the votingenvironment. Within this voting environment, the voter will fill in his or her personal preferenceor choice. This can be done multiple times until the voter is satisfied with his choice. When thisis done, the voter will scan his encrypted voter ID which is visualized by a QR-code. When theQR-code is valid and scanned properly, the system will put the data on the blockchain. Then, anevidence paper can be printed, saved or send (regarding the paper backup solution of Votebook[42] and VoteWatcher [43]). Afterwards, the voter can leave the voting environment or in case ofthe polling station he or she will leave the polling station.


Figure 4.3: An overview of the voting process of the proposed system architecture.


Regarding Figure 4.2 and Figure 4.3, there are some design choices that need to be mentioned:

• Authentication: Authentication is a difficult problem to tackle in the context of electronicvoting. This is the case because identifying on the internet who somebody is, is a ratherdifficult question to answer. Major technology giants such as Facebook are also interestedin this question because they do not want that the same person creates multiple accounts.For example, Facebook has stated in its policy that somebody cannot make more than oneaccount [62]. In the context of e-voting, this would mean casting multiple votes or votingunder a different identity. In order to solve the problem of authentication it is always re-quired to have a CA who knows the group of people that can vote and can identify themembers in the group. In case of internal company election, the CA is the company itself(which has employee identification numbers) and in case of the Dutch elections it is the gov-ernment (which has the voters’ BSN-number). Furthermore, we modeled the functionalityof verification SMS services, verification e-mails or random readers to provide authentica-tion based on how current services do it. Within some contexts, this might be enough (forexample a small business or within a classroom), but for other types of context this is notsuitable (general elections).

• More responsibility for the voter: The ring signature scheme requires some extra respon-sibility of the voter regarding keeping the QR-code, which includes the voter ID encryptedby the public key, secret. When the private key is released, the voter ID on the blockchainbecomes public which implies that others can see which option a particular person has se-lected. Although this seems like a disadvantage it actually can also work as advantagebecause some people may not want their vote to be secret. What the voter does with theprivate key is his or her own choice. Using this way makes it become easier to release thevote, but also easier to lose the vote. The way of having a voting pass (but this one loadedthe voter ID encrypted by the public key), is similar to the Dutch House of Representativeselections (as seen in subsection 3.2.2).

• Confirm evidence: There has been decided to model a ’confirm evidence’-task which sends,prints or saves a confirmation which states that the voter has voted. The reason why thistask has been modeled on such a generic level is that multiple domains require multipleforms of audition. For example, when a central polling station is used it may be beneficialto print a paper which is stored in the polling station to keep track of the votes. Opposed tothat, when voting from own device is enforced, it might be sufficient to just send an e-mailwith the confirmation.

• Voter ID: For the voter ID within the blockchain (see Figure 4.2), it is important that thisvalue describes the identity of a person. Within each context, this may be different. Forexample during the Dutch House of Representatives, this value might be a BSN-number,while in the case of elections at the Utrecht University, this might be a student number.Another example is the Online Social Lobbying Platforms that might use usernames or e-mail addresses as the unique identifiers.

• Proxy voting: Two types of voting are modeled. It is possible to vote from own devicesand at a (local) polling station. In case voting happens at a polling station the proceduresas described in the current voting systems (such as the Dutch House of Representativeselections) can be applied, whereby the blockchain e-voting architecture will increase trans-parency among the person who is proxy voted. For example, the person can check if thevoting option is recorded properly by the proxy. If this is not the case, it is possible tochange the vote by altering the vote in a second round. Contrary to that, when own devicevoting is allowed, proxy voting is trivial because voting from own device does not requireto be present at a physical or geographical specified location.

• Counting procedure not included: There has been decided to not include the procedure ofcounting all votes when the election is closed. The reason is that BPMN models are suitablein a situation where a high-level perspective (generally from user perspective) is desirable.Since the counting procedure is more technical and rather superficial on a higher abstractionlevel there has been decided to not model its procedure in the non-technical specification.


• Waiting for confirmation message: In Figure 4.3 the task ’wait for confirmation message’indicates that the device is placing the vote on the blockchain including encrypting the voterID. There has been decided to add this task because it is an important hook which is furtherelaborated in the more technical use cases (see next section subsection 4.4.2).

4.4.2 System interaction specification: Use Cases

According to Benyon [59], Use Cases are a semi-formal scenario representation. This means thata use case will show the behavior of the system within the context of the user, structured bya set of sequential steps or actions. Use Cases are important in order to illustrate from botha user and system perspective how the requirements and constraints are satisfied. Within thissubsection, four use cases will be described. These use cases will follow the sequential steps auser or election will go through, namely the registration process (see Table 4.4), voting process(see Table 4.5), counting process (see Table 4.6) and preparation for the election 4.7. For eachuse case, stakeholders and a primary actor, preconditions, success guarantees or post-conditions,success scenario, alternative flows, used user stories, technical requirements and constraints aredefined. The use cases can be found on the upcoming pages.


Table 4.4: A step-by-step description of how a potential voter canregister him- or herself

Use case 1: Registration of a voterPrimary actor VoterStakeholdersand interests • A voter wants to be verified that he or she is eligible to vote

• A CA wants that only people have access to the system that are authorized

Preconditions• Registration software for voters is ready to be distributed• Web portal is online (and accessible) for voters• CA has central storage which indicates which people are part of the groupof voters

Success guarantee(post-conditions) • The CA has verified the person

• The CA has successfully added the public key to the consensus• The voter obtained a voting pass

Main successscenario(basic flow)

1. The CA obtains data in the central database which contains the people thatare eligible to vote2. The CA sends message to the people who are eligible to vote which statesthat these people should register3. The voter receives the message of the CA4. The voter goes to the web portal of the CA5. The voter logs in to the web portal6. The voter launches the registration application within the web portal7. The voter hits create personal pass which indicates that the software startswith generating a pair of keys8. The voter hits the print button9. The system creates a voting pass containing the voter’s identity encryptedwith his or her own public key (QR code)10. The voter hits the submit button to send (only) the public key to the CA11. The voter closes the application and web portal12. The CA receives a public key13. The CA adds voters’ public keys to the consensus14. The CA sends message to the people that the registration process hasended

Extensions(alternative flow) 1. The CA has a list of people that want to participate (e.g. in a non-serious

situation where there is just someone that wants to invite some people to votefor something)6. The voter is not able to log in to the web portal7. The vote submits its old encrypted voter ID in order to generate a votingpass for the second round8a. The voter saves a voting pass file to his or her computer8b. The voter receives an email containing the voting pass14. The CA does not send a message that the registration process has ended


Use case 1: Registration of a voterUsed users stories

1. As a voter, I want to verify whether I’m eligible to vote2. As a voter, I do not want to receive a ballot that is invalid3. As a voter, I want to recast a vote4. As a CA, I want that only people have access to the system that are autho-rized (confidentiality)5. As a CA, I want that every action inside the system, can be traced back to aparticular asset (auditability)6. As a CA, I want to prevent that a particular voter can vote multiple times

Technicalrequirements 1. The system is required to be presented in multiple languages

2. The public keys of all voters that have registered should be available forthe consensus protocol3. The CA needs to provide a piece of software where people can generate apublic-private key pair4. The system should be able to run multiple rounds during the election pro-cess on the same blockchain

Constraints1. In order to guarantee that the selected voter options stay secret after elec-tion, the voter must not release its private key2. In order to guarantee that election results stay secret during election day,the CA must not release the private key that is used to encrypt the voter op-tions


Table 4.5: A step-by-step description of how a voter can cast a vote

Use case 2: Casting a votePrimary actor VoterStakeholdersand interests • The Board member wants to verify whether the voter is part of the group of

eligible voters• The CA wants to track election results during the day• The voter wants to cast a vote

Preconditions• The voter must be in possession of a voting pass containing the voter IDencrypted by the generated public key from the registration process• The voter must be registered• The CA must have added the public key to the consensus

Success guarantee(post-conditions) • Vote has been casted


1. The CA opens the elections according to specified time-frame in the con-sensus2. The voter goes to the polling station3. The voter shows the ID-card and voting pass to the board member4. The Board Member checks the ID-card and voting pass (authentication)5. The Board member hands back ID-card and voting pass6. The Board Member tells the voter that he or she can go to the voting booth(or voting system)7. The voter enters the voting booth/environment8. The voter fills in his or her own choice9. The system receives the voter’s option10. The voter shows the voting pass’ QR code to the system to scan the en-crypted voter ID11. The system receives the voter ID encrypted by the public key12. The system will encrypt the voter option with the public key of the CA13. The system will create a new transaction in which the encrypted voter IDand option are saved14. Depending on the architectural style (i.e. voting from own device or cen-tral polling station), the node will send a broadcast request or notify votingbooth N - 1 and N + 115. Some other node receives an request to update the local copy of theblockchain16. The other node will verify whether the action is legal by checking the con-sensus17. The consensus will use all public keys in order to verify whether the voteris part of the group18. The other node concludes that the action is legal19. The other node will update the local of the blockchain20. In the meantime, the voter has waited to receive a confirmation that thevoting has been cast successfully21. The system will print, save or send evidence paper (depending on context)22. The voter can now leave the voting environment


Use case 2: Casting a voteExtensions(alternative flow) 2. The voter downloads and launches the blockchain e-voting application for

voting on own device3a. The voter receives a verification e-mail to verify his or her identity3b. The voter receives a SMS to verify his or her identity3c. The voter uses a random reader to verify his or her identity4a. The voter presses the link in his email4b. The voter fills in the authentication code from his or her SMS5a. The voter is authenticated5b. The voter is not authenticated6a. The Board Member tells the voter to leave the polling station6b. The application tells the voter to start the voting process6c. The application tells the voter to leave the application18. The other node(s) conclude that the action is illegal and will thereforeblock the action

Used users stories1. As a voter, I want to cast a vote2. As a voter, I want to check one or multiple options on the ballot3. As a voter, I want to verify whether I’m eligible to vote4. As a voter, I do not want that someone can impersonate my vote5. As a voter, I want make sure that my vote is assigned to the right object(e.g. party or person)6. As a voter, I do not want that my vote is made invalid or destructed aftersubmission7. As a voter, I want a voting procedure that does not take more time thannecessary8. As a voter, I want to cast a vote in anonymity9. As a CA, I want that only people have access to the system that are autho-rized (confidentiality)10. As a CA, I want the system to be available during the election day (avail-ability)11. As a CA, I do not want that an unauthorized person can modify the votingdata (integrity)12. As a CA, I want that every action inside the system, can be traced back toa particular asset (auditability)13. As a CA, I want to prevent that a particular voter can vote multiple times14. As a member of the polling station, I want to verify whether a certain voteris eligible to vote15. As a member of the polling station, I want to have the possibility to reportany problems to the CA16. As a member of the polling station, I want to authorize an eligible voter tovote


Use case 2: Casting a voteTechnicalrequirements 1. The architecture consists of a single blockchain

2. The system will run within annotated time slot during the election day3. The system is required to be presented in multiple languages4. The system may print paper receipts to serve as backup and confirmation5. When not building on an existing public blockchain (e.g. Ethereum), ablock in the blockchain will represent a voting machine (i.e. own device ordevice in a polling station)6. A transaction in a block in the blockchain will represent a vote of a partic-ular person7. A transaction in the blockchain needs to store a unique identifier called avoter ID8. The voter ID within a transaction will be encrypted with use of a ring sig-nature scheme9. A transaction in a block in the blockchain needs to store the option(s) re-garding the voter10. Options that are made by the voter will be encrypted with help of thepublic key of the CA11. In case a polling station is used, a transaction needs to store the identifica-tion number of the polling station12. The public keys of all voters that have registered should be available forthe consensus protocol

Constraints1. The voter should not be solely authorized by the system2. Voting software modules should not be installed on personal devices of thevoters3. A voting booth should only should only run software modules related tothe voting process4. If voting in person, voting booths in a single polling station need to bestored in a consecutive sequence in the blockchain5. Synchronization between nodes needs to happen on a secure line with helpof a Virtual Private Network (VPN)6. In order to guarantee that election results stay secret during election day,the CA must not release the private key that is used to encrypt the voter op-tions


Table 4.6: A step-by-step description of how the votes are beingcount

Use case 3: Counting votesPrimary actor VoterStakeholdersand interests • If a candidate is involved in the election, he or she wants to know the results.

The same is applicable for the other involved stakeholders.• The voter wants to know the results• The CA wants to know the results

Preconditions• The time-frame stated in the consensus is reached• All nodes are synchronized

Success guarantee(post-conditions) • The results are published


1. The CA opens a single device which has a local copy of (the latest versionof) the blockchain2. The CA uses a predefined program which is enabled to iterate over everytransaction in the blockchain3. For each transaction, open the voter option field with the private key4. For each transaction, assign the voter option to the right person or object5. The produced information is released to the public6. The CA releases the private key which can be used to decrypt the votingoptions

Extensions(alternative flow) 6. The CA does not release the private key

Used users stories1. As a voter, I want make sure that my vote is assigned to the right object(e.g. party or person)2. As a voter, I do not want that my vote is made invalid or destructed aftersubmission3. As a voter, I want to make sure that my vote is taking into account whencounting4. As a CA, I want to have quickly insights in the results of the election5. As a CA, I want that results are only available after the election6. As a CA, I do not want that an unauthorized person can modify the votingdata (integrity)

Technicalrequirements 1. Counting of votes should happen without interference of people

Constraints1. Synchronization between nodes needs to happen on a secure line with helpof a Virtual Private Network (VPN)2. In order to guarantee that the selected voter options stay secret after elec-tion, the voter must not release its private key


Table 4.7: A step-by-step description of the CA prepares the elec-tions

: Preparation for electionPrimary actor CAStakeholdersand interests • The CA wants to submit the necessary parameters in order to start an elec-

tion

Preconditions• The CA does know the begin and end time of the election• The CA is familiar with the entities on which a particular voter can vote

Success guarantee(post-conditions) • The begin and end time of the election are specified in the consensus

• The entities (e.g. candidates) on which voters can bring out a vote are de-fined• The public key(s) for locking voter options during election day are specifiedin the consensus


1. The CA logs in to the web portal2. The system recognizes that the CA logged in and routes it to the adminpage3. The CA fills in begin time and end time of election4. The CA fills in the voting options5. The CA hits the submit button6. The system generates a public-private key pair7. The system adds the begin time, end time and public key to the consensus8. If there are already nodes that have the blockchain, the system triggers asynchronization mechanism9. The system shows the filled in parameters to the CA10. The CA saves the private key to a specified destination in order to openthe results after the election day11. The CA logs out of the web portal

Extensions(alternative flow) 2. The system sees that the user is a normal user which implies that he or she

will be routed to another page than the admin page10. The CA prints out the private key in order to open the results after theelection day

Used users stories1. As a CA I want to set guidelines for the execution of the election2. As a CA, I want that only people access to the system that are authorized(confidentiality)

Technicalrequirements 1. Options that are made by the voter will be encrypted with help of the public

key of the CA


: Preparation for electionConstraints

1. In order to guarantee that election results stay secret during election day,the CA must not release the private key that is used to encrypt the voter op-tions

4.4.3 High-level technical specification: UML Component Diagram

In Figure 4.4, a component diagram is presented. This figure describes various component andsubsystems that are included within the blockchain e-voting architecture. These components andsubsystems will be further divided into smaller entities like classes in models in the upcomingsections.

First of all, the CA portal can be seen as a subsystem containing a VoterDatabase and a Voter-Credential user interface (UI). Within this system, the process of voter identification and autho-rization is established. There has been decided to model the Voter Key Generator as a subsystemand not as a part of the tool since the subsystems are executed in a different environment. Theportal will be execute on the server side while the key generator will run client side in order toprevent that the CA can match the voter keys to identities. Within the Voter Key Generator sub-system there are three components, namely the KeyPairGenerator, the VotingPassGenerator andthe PublicKeySender. The KeyPairGenerator is dependent on the login in the web portal becauseonly people who are authorized can access. Furthermore, a Voting Pass and the sending processof the public key can only be done when a key-pair is generated. Within the component of theVotingPassGenerator, multiple other components can be located, such as a QR code generatorcomponent. Thirdly, a subsystem called Voting Booth is included which has three componentsthat are related to other subsystems. The VotingPassScanner (UI) is dependent on the Voting-PassGenerator of the Voter Key Generator subsystem. When the voter identity is known and theoption is filled in (via a VoterOption UI), evidence can be printed by using an EvidenceGenerator.Lastly, the blockchain is as a subsystem including three components namely Block, Consensusand Synchronization. A block is dependent on the voter option and is formalized by the consen-sus. The consensus is dependent on the PublicKeySender in a way that the consensus is filledwith public keys in order to verify if someone is part of a group or not (fueled by linkable ringsignature technology).


Figure 4.4: An overview of the components and subsystems within the blockchain e-voting sys-tem (connection between subsystems inspired by Fakhroutdinov [11]).

4.4.4 Low-level static technical specification: UML Class Diagram

In this section a UML Class Diagram will be given which is used in order to further divide themajor subsystems and its component of the earlier defined component diagram into classes, at-tributes and relations between classes. In Figure 4.5, the class diagram can be found. Within thismodel, there have been made various design choices which need to be mentioned and furtherexplained:

• Private key: There has been decided to create a class which models both a public and pri-vate key. As earlier mentioned the private key should not be publicly exposed. It is thereforeimportant that within the method which retrieves the private key an extra condition is mod-eled which checks to which class a certain object belongs (the ’get private key’-method). Forexample, it is not desirable to expose the private key to objects of the class Transaction.It is therefore necessary to throw an exception if a transaction object calls the ’get privatekey’-method.

• Applying MVC-pattern: Like described in earlier sections the architectural style requiredto implement the MVC-pattern. Normally the implementation would be established by us-ing the so-called Observer design pattern. In order to keep the model simple, there has been


decided to not use the Observer pattern. When this architecture is used for implementa-tion it would be convenient to extent the design with the Observer pattern if the system isextended with extra controller and view classes.

• Database connection: In order to model the database connection properly there has beenchosen to implement the Singleton pattern. This implies that during invocation of the pro-gram only a single instance of the database connection class is active. This is desirablebecause creating many database connections is resource intensive.

• Ring signature scheme class: It depends on the implementation platform where objects ofthe ring signature scheme class are instantiated. This is the case because different blockchainsystems have different ways of executing the consensus. For example, in Ethereum there isthe possibility to store smart contract code inside a single block [63]. Conceptually, thiswould imply that the objects of the Block class would instantiate the ring signature scheme.

• No factory patterns used: Normally it is convenient to separate usage and creation of ob-jects. In this class diagram there has been decided to not model this practicality because thiswould make the model unnecessarily complex.

• Session object is global: Although the class diagram does not contain dependencies witha Session object for the web portal, it is important to mention that this would be an objectthat is defined global. This would imply that every object can access this Session object inorder to determine whether the voter is signed in into the web portal or not. Moreover,it is necessary to destroy a user specific session when the public key is submitted becauseotherwise the CA can see which voter send a particular key. In order to prevent that anyonecan send public keys it is therefore necessary to create a generic session which indicates thata particular person sends its key from within the key generation programming in authorizedmanner.

• It is possible that multiple public keys are used to encrypt voter options: In order to pre-vent that the CA can open vote options during the election day it is possible to encrypt thevoter option with an additional public key from a third party. In this way it is only possibleto look into the results if both parties agree on that. In the class diagram the attribute foropening the voter options therefore consists of an array with one or more public keys.

• Storing the identification number of polling station depends on implementation: In casecentral polling stations are used it is important to store the polling station identificationnumber inside a transaction. In this way the voting booth knows which devices need tosynchronize first.

• What should be stored within the consensus? It is necessary to specify the begin and endtime of the election within the consensus. This is the case because it is otherwise possibleto vote after or before the elections. Moreover, it is also necessary to store all public keys ofthe voters that are participating and also the public key or set of public keys of the CA(’s)which are used to encrypt voter options. At the moment of casting the vote the set of publickeys will be retrieved from the consensus and added to the transaction in order to let theother nodes validate whether the encrypted voter ID is part of the linkable ring.

• Generating random numbers: The generation of a random string for the linkable ring sig-nature scheme happens from within the view by letting the voter perform a set of actions(like described earlier). This random string is passed to the ’generate voting pass’-methodin the ’UserController’-class.

• Generate voting pass for second round: In order to make sure that misrecording can beadjusted, it is possible to perform a second round during the election day. Within this secondround it is necessary for the voter to generate a new voting pass whereby the old encryptedvoter ID is passed to the CA. This old encrypted voter ID needs to be taken into accountwhen the votes are counted in order to prevent that the wrong voting options is taken intoaccount.


• Proxy voting: Regarding proxy voting and the risks we discussed earlier (such as peoplevoting something else instead of what the intention of the person who is proxy voted is),this is supported because the vote data can be reviewed by the person who is proxy voted.When something went wrong (such as a wrong party or option selected), it is possible totake part in the second round of the election. In this way, the proposed solution makes surethat proxy voting can be done at higher transparency for the person who is proxy votedthan for (e-)voting systems we know today (see subsection 3.2.2).

• Reuse the blockchain: Since an instantiation of a consensus will keep track of the electioncycles. It is possible to perform multiple elections on the same blockchain. The practicalinstantiated string in the ’Consensus’-class will then hold values like 1A, 1B, 2A and 2B forthe first and second round of the first and second election.


Figure 4.5: UML Class Diagrams of the proposed blockchain e-voting system.


4.4.5 Low-level dynamic technical specification: UML Sequence Diagram

In this section explanation about the low-level dynamic technical specification will be given.Within this analysis each use case from subsection 4.4.2 is illustrated whereby the sequence di-agrams explains how the class diagram of Figure 4.5 can be executed. More specifically, it il-lustrates how the objects of the classes are instantiated in order to execute the use cases. Sincethere are four use cases, there are four sequence diagrams, namely registration of a voter (seeFigure 4.6), casting a vote (see Figure 4.7), counting the votes (see Figure 4.8) and preparation forelection (see Figure 4.9).

There are some design choices that needs to be mentioned:

• The abstract view class: The abstract class View is used to model all views within both theweb portal (see Figure 4.6) and casting votes (see Figure 4.7). There has been chosen forthis approach because it would otherwise be necessary to model every delegation to a viewwith a separate object. Moreover, although not modeled explicitly, all those view classesdo have some shared functionality which needs to be encapsulated into a separate abstractclass (hence View).

• Only main success scenario is modeled: There has been decided to model only the mainsuccess scenario of each use case. The reason for this choice is that keeps the models rela-tively simple. Each use case has one or more alternative flows which would imply that themodels would become large if every case was included. In most cases the alternative path istrivial, for example filling in wrong credentials into the web portal would lead to a sendinga message to the user that he or she needs to try login again.

• Registration of voter and preparation for election are partially the same: This is the casebecause for both use cases the actor (voter or CA) needs to login into the web portal wherebythe system will route the actor to the right page (admin view for the CA and the key gener-ation view for the voter).


Figure 4.6: UML Sequence diagram for use case 1: Registration of a voter.


Figure 4.7: UML Sequence diagram for use case 2: Casting a vote.


Figure 4.8: UML Sequence diagram for use case 3: Counting votes.


Figure 4.9: UML Sequence diagram for use case 4: Preparation for election.


4.5 Conclusion

In order to provide an answer to research question two (in chapter 2, How should the architecture of ablockchain e-voting system be structured?), multiple aspects have been analyzed. The chapter startedwith analyzing the possible architectural style including an encryption scheme for securing theprivacy sensitive data within a transaction (i.e. vote) on the blockchain. Because blockchain is adistributed technology and the data within the blockchain is immutable (i.e. when the local copyof the blockchain is synchronized with the other nodes it is impossible to remove data), it is ab-solutely necessary to protect the content of the votes with an encryption scheme. Moreover, withhelp of BPMN there is also given a non-technical specification follow by a set of UML diagrams.

First of all, the system interaction specification was described with help of use cases. Within theuse cases a precise description of how the stakeholders and the system are interacting with eachother were given. Secondly, with help of a component diagram a coarse-grained description ofthe subsystems including components were given. These subsystems and components were fur-ther divided into classes, attributes and relations between them in a class diagram. Finally, in thesequence diagrams there was illustrated how the earlier defined use cases were executed withhelp of the class diagram (i.e. how the objects of the classes in the class diagram communicatewith each other).

Therefore, the architecture of a blockchain e-voting system is structured in the following way(RQ2):

• Architectural style: The voting devices will be structured with help of the MVC-architecturepattern since this architecture functions well in graphic intensive systems and also fits in thedistributed nature of blockchain technology. Besides, it depends on whether central pollingstations or own devices are used whether synchronization happens based on the Distance-vector routing protocol or broadcasting. Additionally, it is necessary to introduce linkablering signatures in order to make sure that the voter ID is only visible for the voter and that avoter can only bring out a vote once. Finally, the voting options should be encrypted with anextra public-private key pair which is in possession of the CA. In this way, it is not possibleto read the voting options during the election day. If the CA cannot be trusted it is necessaryto establish a third independent party which has a key pair whereby the public key is alsoused to encrypt the voter options. Finally, when larger elections are held the introductionof Light Clients are a necessity in order to make sure that synchronization does not take anunacceptable long time.

• Non-technical specification: The authentication of voters needs to happen with help of aCA. This is the case because only the CA has a unique identifier for each voter and hasverified who belongs to a particular unique identifier (e.g. student ID’s or employee ID’s).Moreover, in comparison with centralized e-voting systems, there is more responsibility forthe voter because in a blockchain system, that implements a linkable ring signature scheme,the voter needs to generate a public-private key pair. If the voter accidentally leaks theprivate key pair, everyone can see what he or she has voted.

• System interaction specification: There are four important process within the system namelypreparation for the election, registration of voters, casting a vote and counting the votes.Each of these processes has a set of fulfilled user stories, requirements and constraints.

• High-level technical specification: Within the system there are four major subsystems thateach fulfill a certain role in the system. The subsystem of generating keys makes sure thatboth the CA and the voter can generate a public-private key pair. Besides, the portal ofthe CA makes it possible to generate the voting pass and make sure that the linkable ringsignature scheme knows that the voter is an eligible voter. Moreover, the voting devicemakes it possible to scan the voting pass and cast a vote. Finally, the e-voting blockchainsubsystem makes sure that votes can be added to a local copy of the blockchain and afterthat synchronized with the other participating nodes.


• Low-level static technical specification: This specification indicated that the consensusshould store the begin and end time of the election, but also the two sets of public keyswhich are used to verify whether a voter is an eligible voter (i.e. public key is part of thering signature scheme) and encrypting the voter options. Moreover, it is possible to executein a second round in order to give the voter the opportunity to correct mistakes.

• Low-level dynamic technical specification: This specification illustrated how the use casescan be executed with help of the low-level static technical specification (the class diagram).This model was mainly used to check whether the class diagram could really be instantiatedand if thus the structure of static technical specification was correct.

Chapter 5

Treatment validation

In this chapter the treatment validation phase of the Design Science Cycle by Wieringa [2] willbe described. In this phase, like the name suggests, the design of the previous phase will bevalidated. In the context of blockchain e-voting it is difficult to test an implementation becausethat would imply that an election must be given with a working blockchain implementation tosimulate the (e-)voting process. Although this is the case, there still can be validated by askingexperts to validate each step in the treatment design phase. In this way, with caution, there canbe made some conclusion whether the architecture is going to solve the earlier stated problems.The results of the treatment validation phase will be evaluated with help of the success criteriathat are defined in chapter 3. Intermediate results are used in order to retrieve fast and timelyfeedback from the stakeholders and experts in the domain. This implies that the iterative natureof the Design Science methodology is optimal used (i.e. problem investigation, treatment designand treatment validation are edited multiple times in multiple iterations).

5.1 Validation of non-technical specification

In this section, both the procedure and results of the validation of the non-technical specification(i.e. blockchain e-voting process from a high-level perspective with help of BPMN 2.0) will begiven. A description of the procedure will contribute to the reproducibility this research sincethese questions can be used in order to reproduce the validation phase. Besides, the results ofthe validation session with the stakeholder will also be presented and important insights will begiven.

5.1.1 Procedure

In order to provide an answer to the main research question whether the designed non-technicalspecification is valid, there has been given a semi-structured interview with an expert in the vot-ing domain. In this context, semi-structured implies that the success criteria will be taken fromchapter 3 and will be formed to questions. These questions will give some support in structuringthe interview but suggestions and other feedback will also be taken into account. The interviewwill therefore be held based on the following questions (based on section 3.4):

1. Is it possible if voter impersonation happens?

2. Is it possible that the proxy voting mechanism can be misused?

3. Is it possible that votes can be misrecorded?

4. Is it possible that votes can disappear?

5. Is it possible that votes can be altered?

6. When voting, is it possible that the filled in option remains secret?

70

CHAPTER 5. TREATMENT VALIDATION 71

5.1.2 Results

In this section the results based on the semi-structured interview with the stakeholder are given.This results will be described with help of the earlier defined success criteria. For each successcriteria there will be suggested whether the current design solves the problem or not. Addition-ally, other results that were discussed during the interview will be given.

1. Is it possible if voter impersonation happens?Initially the architecture consisted of a mechanism whereby the board member could print QR-codes by filling in the voter ID. This could potentially lead to voter impersonation because theboard member can guess voter ID’s and print the QR-codes. This leads to a situation in which theboard member can impersonate voter ID’s of unused ballots.

2. Is it possible that the proxy voting mechanism can be misused?Initially the proxy voting mechanism contained a confirmation mechanism whereby the proxyvoter assigned another person which confirms his or her option. During the interview with thestakeholder, we came to the conclusion that this confirmation option is redundant because thechoice of the proxy voter is already stored in the blockchain. It did not make sense to let anotherperson confirm this decision. With or without removing this option, the stakeholder confirmedthat if proxy voting options are used, this system may be capable of preventing misuse of proxyvoting.

3. Is it possible that votes can be misrecorded?Within the domain of blockchain, also suggested by the stakeholder, it seems like if applied prop-erly blockchain technology inherently already solved the problem of prevention of misrecording.However, the initial architecture proposed in this interview did not have the possibility to altervotes after they have been casted. This is a challenging problem because the CA must preventduring the counting procedure that two votes of the same person are taken into account. There-fore, although blockchain technology already solves the problem by precisely tracking actions,the voter does not have the opportunity to correct wrong voting options.

4. Is it possible that votes can disappear?During the interview with the stakeholder we came to the conclusion that the initial designedtreatment contained a flaw concerning providing the voting pass. In the initial design there weretwo options namely that of the current Dutch electoral situation (a voting pass is used) or that thevoting pass is printed at the polling station. This last option is undesirable because in this way aboard member can misuse the system by printing QR-codes by guessing them based on the voterID. In an election where voter ID’s are long and random (e.g. Social Security Number) this is notreally a problem but in some elections (e.g. use employee number) a raw voter ID can be misusedby guessing them at the polling station. In this case a board member could print out multiple QR-codes and use this to alter votes. Although the problem can be detected, unused votes (in generalelections in countries this can often exceed 25%) are especially vulnerable to this hack because thevoter does not see that someone used his or her vote and nobody complains about it.

5. Is it possible that votes can be altered?During the interview, regarding the possibility to edit votes, there have only been discussed howFollowMyVote is vulnerable to this flaw. Initially, the interviewee did not understand why votescould be altered in FollowMyVote. We explained that there is always the possibility to malwareis installed on the devices of the voters, which can cause vote unauthorized alteration.

6. When voting, is it possible that the filled in option remains secret?Initially the system was designed in a way that there were two blockchains namely a ’voter’-blockchain and a ’registration’-blockchain. The stakeholder was not really convinced that thiswas viable solution because it still may be the case that votes are derived from time-stamps. Wediscussed alternatives with the stakeholder and came to conclusion that there is always some sortof trade off concerning the privacy. In a situation when two blockchains are used the technical


overhead becomes large which implies that there can be made more mistakes (i.e. human error)than with one blockchain. When one blockchain is used the data that is stored in the blockchainmust be prepared through a mechanism which makes sure that vote options and voter ID’s can-not be derived from each other. We discussed the phenomenon ’data perturbation’, a techniquenormally used by data scientists in order to protect data, by swapping rows with each other (thefirst ID will get the last name of a random other ID). The stakeholder had positive stances withthis solution but it still remains a difficult problem because in this case it is necessary to put thevotes in a queue in the voting machine and wait till there are enough votes to perturb the data.This implies that in this scenario the voting machine gets more responsibility. However, duringthis interview we were not aware that linkable ring signatures were a promising technique whichbrings less responsibility to the voting machines and instead focus on a mathematical sound the-ory.

Besides the assessment of the success criteria, there will also some other points mentioned duringthe interview:

• Voter ID: Regarding the voter ID, it is important to determine whether the CA can see whocasted a particular vote. In most cases, according to the stakeholder, this is not wanted dueto the fact that voting behavior can be used against a voter (for example within a company).Furthermore, it is needed that only the voter itself can see what he or she voted. Addition-ally, for the CA it is necessary to check if someone voted in order to prevent voting multipletimes.

• Physical printing not always necessary: Printing evidence paper is not necessary accordingto the stakeholder, although this step could still be included. Within the context of voting onown (local) devices, this step is not important because you do not cast the evidence paper ina ballot box. In this case it might also be the case that a document is downloaded, althoughwith blockchain it should be possible for the voter to track the vote based on his or her voterID (or the hash of the voter ID combined with other sources if done so).

5.2 Validation of system interaction design and high-level tech-nical specification

In this section the validation of both the system interaction design (see subsection 4.4.2) and ahigh-level technical specification (see subsection 4.4.3) will be given. In subsection 5.2.1 the pro-cedure will be described including the interview style and questions that form the guideline ofthe interview. Besides, in subsection 5.2.2 the results of this session will be given.

5.2.1 Procedure

In order to validate the system interaction design and the high-level technical specification therehas been decided to adhere the same procedure as with the validation of the non-technical speci-fication. This implies that the success criteria defined in chapter 3 will be used:

1. Is it possible that voter impersonation occurs?

2. Is it possible that the proxy voting mechanism can be misused?

3. Is it possible that votes can be misrecorded?

4. Is it possible that votes can disappear?

5. Is it possible that votes can be altered?

6. When voting, is it possible that the filled in option remains secret?


Additionally, it was also necessary to discuss the new proposed non-technical specification inorder to determine whether it is now valid. In order to validate the non-technical specificationthe same success criteria will be used whereby only parts that were not sufficient in the previoussession will be discussed. In order to avoid redundancy the results section contains an answerper success criteria instead of an answer with repetition of all success criteria per model.

5.2.2 Results

Similar to the results section of the non-technical specification validation (see subsection 5.1.2),the outcome of the following questions are described and elaborated in this section, regarding thesemi-structured interview with the stakeholder.

1. Is it possible that voter impersonation occurs?During the semi-structured interview there has been concluded that voter impersonation is some-thing that happens outside the scope of the system. This is the case because blockchain technologyis not meant to solve the problem of authentication (i.e. determine whether a certain person is aneligible voter). Before the semi-structured interview we already had the idea that this was thecase which was confirmed by the stakeholder during the interview. This implies that the successcriteria regarding the voter impersonation will not be solved which resembles the same conclu-sion as that of Votebook [42] and VoteWatcher [43].

2. Is it possible that the proxy voting mechanism can be misused?Regarding the proxy voting, both voting mechanisms have been discussed namely own devicevoting and voting from a central polling station. In case of own device voting, this will result inthe same situation as in FollowMyVote which implies that voters do not have to show up at ageographical location and thus the problem seems solved. Moreover, when voting happens froma central polling station it is required to give the voting pass to somebody that can be availableduring election day. This resembles the Dutch situation with the exception that within this archi-tecture it seems possible to check if the proxy vote is casted correctly.

3. Is it possible that votes can be misrecorded?The new solution did not change the outcome to this question, which implies that the use of thissystem still solves the problem of vote misrecording.

4. Is it possible that votes can disappear?Since the stakeholder initially suggested to take own device voting into account, we discussedwhether votes can disappear in such a situation. After explaining that devices could contain mal-ware which makes it possible to show a message to the voter that the vote has been casted butit is actually never stored on the blockchain, he agreed that this would be a problem in criticalsituations.

5. Is it possible that votes can be altered?As described at question 4, disappearance of votes is possible with own device voting which im-plies that unauthorized of votes is also possible. After all, since the device could be compromised,it is also possible that before synchronization with other nodes, the voting options in the trans-action is altered. However, the stakeholder suggests to include the possibility to vote from owndevice because in non-critical situations the risks are not that significant in contrast to the advan-tages.

6. When voting, is it possible that the filled in option remains secret?According to the stakeholder, the usage of linkable ring signatures seems promising regardingpreservation of privacy and therefore cast votes in anonymity (something which current e-votingblockchain implementation have failed to implement). Moreover, the stakeholder agreed that thevoter options should be locked with a key that is only in possession of the CA in order to preventthat every node can tap into voting behavior during election day. This is undesirable becausepremature publication can lead to biases (i.e. people tend to choose between the most popular


options). It is important that this key will be published after the elections so that the results canbe verified. On the other hand, the voter identity will remain secret by encrypting the voter ID.In this way, the CA can see the filled in vote options but it is not possible to see which person hascasted a particular vote.

During the interview, other points were mentioned that should be highlighted:

• Public blockchain: During the validation session with the stakeholder, we came to con-clusion that a public blockchain e-voting architecture is the most desirable (compared withprivate and consortium blockchains).

• CA: Regarding the CA (i.e. the party that hosts the election), this party is always involved inan election. The presented treatment during this validation session still had a flaw regardingthe amount of power the CA possesses. In this intermediate treatment the CA still had thepower to read voting options during the election because this party has the private key.Furthermore, when the CA loses its private key, which is used to encrypt all voting optionswith, it is not possible to produce a result because the voting options cannot be read. Duringthe interview, there has been concluded that at least a second CA must be involved whichalso generates a public-private key pair. The public key will be stored in the consensustogether with the public key of the main CA. In this way during election day, the CA cannotlook into results by decrypting the voter options because the second key is necessary inorder to see the results.

• Registering procedure: During the interview there has been concluded that within someelections, it is beneficial to dynamically add voters instead of a clear divided process con-taining a specific timeframe to register and a specific timeframe to vote (i.e. hand in thepublic key before the election starts). Separate processes may discourage people to vote ac-cording to the stakeholder because the people need to spend time at two distinct moments.Furthermore, when people forget to register, they cannot vote on election day. Initially thisthesis stated that this is necessary in order to let the ring signature scheme work. It is there-fore important to look into a solution for ad-hoc addition of voters during election day. Thiswill require that have extra administrative overhead. This is the case because the set of pub-lic keys changes overtime which requires to save the set of people (i.e. public keys) at timeof voting within a transaction (i.e. set of public keys must be coupled to a certain vote). Thisprinciple is illustrated in the low-level static technical specification (see subsection 4.4.4) bya ’Transaction’-class which has a set of keys as attribute.

• Introduction of Light Clients: As the stakeholder suggested regarding the component dia-gram (see subsection 4.4.3), within the current system all systems are full nodes. The disad-vantage of using full nodes is that the synchronization time will raise significantly if the elec-toral process is large scaled (i.e. elections with millions of people) and/or a public genericblockchain is used (like Ethereum). This is the case because if each node needs to store theentire state it takes an unacceptable amount of time to initially retrieve all transactions andblocks. This is especially the case when voting from own device is done because mobilephones lack the computational power to process gigabytes of data (e.g. Bitcoin currentlycontains dozens of gigabytes of data which all has to be synchronized and stored on thedevice). By using Light Clients, this problem can potentially solved since only a fraction ofthe blockchain needs to be synchronized (in more technical terms, the relevant branch of theMerkle tree (see subsection 3.2.3)).

• Downloadable executable: During the design of the BPMN models (see subsection 4.4.1and subsection 4.4.2), we included multiple steps to download an executable and launch itfrom an own device. During the semi-structured interview we concluded that it is better tohave an application in a web environment because in this case the voter does not need toinstall anything. Moreover, it is also possible that the keys are exclusively generated at theclient side so that the CA does not know who send which public key (which is stored in theconsensus).


• Requirements and user stories: The use cases also consist of a section with requirements,constraints and user stories. Together with the stakeholder these sections have also beenanalyzed in order to find missing aspects like incomplete user stories.

5.3 Validation of static and dynamic low-technical specification

Within this section a semi-structured interview will be described which emphasizes on the moretechnical aspects of defining the architecture. In order to analyze the technical aspects, the classdiagram from subsection 4.4.4 and the sequence diagrams of subsection 4.4.5 will be used in orderto determine whether, from a technical point of view, the success criteria are met. This interviewwas held with two blockchain experts and the stakeholder of the two previous session was alsopresent during this session.

5.3.1 Procedure

First of all, for a better understanding the infographic displayed in Appendix B is used as initialstarting point for the interview (although both stakeholders already studied the material beforethe start of the interview). This will help with explain the main points that have been foundduring the execution of this research. Moreover, the use cases, the class diagram and the sequencediagrams were used in order to give the interviewees insights in what has been done. There hasbeen chosen to not use the BPMN and component diagrams. The reason for this is that thesemodels have already been validated in earlier sessions and these two models are encapsulatedon a level of more detail in respectively the use cases and class diagram. As opposed to theinterviews with the stakeholder that were described in section 5.1 and section 5.2, this time themodels will be used as guideline for the interview (instead of the success criteria). There hasbeen chosen for this approach because an in-depth technical analysis will require to look into thestructure of the system. This structure is precisely described in these models. After the interview,it is therefore important that the technical feedback of the stakeholders will be translated to ahigher level perspective in order to assess whether the success criteria are met.

5.3.2 Results

Like described in subsection 5.3.2 the models of section 4.4 were used as guideline throughoutthe interview. The feedback per model will therefore be given in this section:

1. Infographic: During the elaboration on the infographic the stakeholders shared their opin-ion regarding their initial look on the models in this thesis. Initially without elaboration,the stakeholder was quite skeptical regarding the necessity of a CA in a distributed en-vironment like a blockchain system to lock voting options and collect public keys. Thestakeholder asked whether it is a proper idea to have a CA which locks the voting optionsduring election day. We explained to the stakeholder that it was important that voting op-tions should not be revealed because this can lead to biases among voters (i.e. voters willfocus on the most popular options). We therefore discussed alternatives for this solution liketime-based encryption schemes. Within a time-based encryption scheme a voting option islocked during a specific timeframe, for example from 9AM till 6PM. The problem with thiskind of encryption is that it is impossible to create encrypted voter options that will holdfor a particular timeframe since every computer has a different amount of computationalpower (i.e. for some computers it takes less computational power to brute force the votingoptions than the timeframe while for others it takes longer). The solution regarding lockingthe voter options with a public-private key pair of potentially multiple Central Authoritieswill therefore hold.

2. System interaction design (use cases): During the elaboration on the system interactiondesign the stakeholder revealed that he had a possible solution regarding correcting votingoptions after the vote has already been casted. The blockchain expert suggested to have sec-ond round during the elections with a second set of public-private key pairs which makes it


possible to cast a vote again as part of a new linkable ring. However, this does require extraadministrative overhead since the voter should be enabled to let the CA know that the otherencrypted voter ID present on the blockchain should be ignored when the votes are counted.Moreover, during the discussion, it also became clear that the expert also had an idea regard-ing simplifying and making the key generation process more solid. Like discussed duringthe presentation of the infographic, the stakeholder was quite skeptical that in a distributedenvironment a CA is necessary in order to collect the public keys for the linkable ring signa-ture scheme. In the current situation the voter needs to generate the public-private key pairwhich gives the voter, like described earlier, more responsibility. Moreover, the anonymityof voter becomes dependent of implementation details instead of a sound mathematicaltheory (complementary to the philosophy of queuing votes and use data perturbation inorder to guarantee anonymity, like discussed in the first interview). This is the case becausethe current architecture describes a system in which the submission of the public key needsto be done within the key generation program without leaking the voters’ identity whichis error prone from a programming point of view. The expert suggested that with help ofso-called ’Swarm intelligence’ the CA can generate public-private key pairs and distributedthem among the voters without knowing to which voter which key pair is sent. Althoughthe process of handing in public keys is not fault proof, the use of linkable ring signatures isa promising technique in order to guarantee secret ballot voting according to the stakehold-ers. Feedback regarding this aspect is not included in the architecture because this wouldimply that we need to create technical understanding of this phenomenon (a quick look inthe literature indicated that it is a mathematically inclined subject) and apply major changesin every part of the architecture.

3. Low-level static technical specification (class diagram): The low-level static technical spec-ification revealed that the interviewee suggested that the chosen MVC-structure can lead tosome redundancy in the controller and model classes. Although it is not plain wrong, areal-world e-voting blockchain implementation would better off by creating a set of mod-ules which eliminates the use of controller classes. Moreover, the stakeholder also indicatedthat the strong emphasize on the object oriented programming model was a proper choicebecause it makes it easier to use abstraction which is essential for blockchain systems. Fi-nally, during the interview, we came to the conclusion that the initial model did not takeinto account that a second voting round should be possible for people that want to overridetheir other vote. It was therefore necessary to extend the ’Consensus’-class with a secondbegin/end time and another attribute with a second collection of public keys for the linkablering signature scheme.

4. Low-level dynamic technical specification (sequence diagrams): The low-level dynamictechnical specification revealed that the model described in static technical specification canbe executed properly. Feedback regarding performing a second round during election dayfor people that have filled in a wrong voting options, revealed that adjustment of the staticmodel will also require to adjust the dynamic model (so that execution with a second votinground is possible).

5.4 Conclusion

In order to provide an answer to third research question (in chapter 2, How can fraud be preventedby the use of blockchain technology compared to current (e-)voting systems?), multiple interviews withexperts in the domain of e-voting and blockchain have been executed. First of all, in section 5.1 thearchitecture from a non-technical point of view has been analyzed to find initial flaws regardingthe proposed design. In this interview it became clear that the use of two separate blockchainsto guarantee anonymity is undesirable, that board members should not generate voting passesand that voting behavior should not be traced back to a specific individual. Besides, the systeminteraction design and the high-level technical specification have also been validated in a secondvalidation round with a e-voting expert (see section 5.2). In this interview it became clear that theproposed solution regarding guaranteeing secret ballot voting seems promising but needs to be


further researched in models that are more technical, authorization cannot happen without a CA,voting options should be locked during election day to avoid voting biases and Light Clients arenecessary in large scale elections or when public blockchains are used. Finally, the final technicalvalidation session revealed that the implementation of a second election round is necessary toguarantee that the mechanism of detecting double voting, locking the voter options with a key ofthe CA seems the only option to prevent voter biases and so-called ’Swarm intelligence’ can beused to prevent extra responsibility for the voters and make the architecture less error prone (seesection 5.3).

Like stated before, the results from these interviews need to be handled with caution since thearchitecture is not tested in a real election. Although this is the case, regarding the different typesof fraud that blockchain technology can prevent compared to current (e-)voting systems (RQ3):

• Votes disappeared: The initial design of the architecture presented in this thesis containedthe possibility to generate voting passes on the polling station (see section 5.1). This wasconsidered as a flaw because board members could print out unused voting passes by guess-ing voter ID’s and cast a vote. Besides, in subsection 3.2.3 it became clear that votes coulddisappear in Votebook and VoteWatcher due to the fact that private blockchains were used(exploit the blockchain with a 51% attack). This implies that these two implementation werevulnerable for disappearance of votes after submission to the blockchain. However, withinthe implementation of FollowMyVote, votes could also disappear before submission due tothe fact that the malware could potentially be installed on the voting devices. Voting fromown device in this architecture is thus also vulnerable for this type of fraud. Contrary tothat, this architecture contains the possibility to vote from a central polling station whichmakes it much harder to perform this type of fraud. This is the case because these devicesare more likely to be clean of malware because only necessary voting software is installed.Moreover, the voting pass can only be generated by the voter itself which makes it impos-sible for the board member to exploit the previously available flaw. There can therefore beconcluded that the architecture in this thesis may prevent disappearance of votes.

• Votes altered: Regarding altering votes unauthorized in chapter 3 it became clear that bothcurrent blockchain and centralized (e-)voting systems do not prevent this type of fraud.Procedures and design choices like manually delivering cartridges to other geographical lo-cations (elections in the USA), the use of private blockchains (Votebook and VoteWatcher)and voting from own device (FollowMyVote) made it possible to potentially alter votesunauthorized in all these electoral processes. As described in subsection 3.2.3, voting froman own device in critical electoral processes (such as the US elections and the NetherlandsHouse of Representatives elections) is not desirable due to the fact that there cannot be guar-anteed that devices are clean from malware. Besides, when voting is done from a centralpolling station and the devices only run the necessary software (like a voting booth) it be-comes much harder to alter votes unauthorized before submission to the blockchain. Thisin conjunction with describing measures that are necessary in order to make this architec-ture practically work on a public blockchain, it also becomes much harder to alter votesafter they are submitted to the blockchain. Therefore, with caution, there can be concludedthat this type of fraud may be possible to prevent with an implementation build with thisarchitecture.

• Misuse of proxy voting: Regarding the current blockchain e-voting architectures only Fol-lowMyvote had functionality regarding proxy voting. In subsection 3.2.3 there has beenconcluded that with FollowMyVote it is not possible to misuse the proxy voting mechanismdue to the fact that voting happens from the voters’ own device. Regarding the architecturepresented in this thesis, both voting from own device and from central polling station aremodeled. In both situations it seems that misuse of proxy voting can be prevented. Togetherwith the analysis of FollowMyVote there can be stated that misuse of proxy voting is a typeof fraud which seems to be solved by blockchain technology, as opposed to centralized (e-)voting systems like the electoral processes of the Netherlands and USA.


• Misrecording of votes: In subsection 3.2.3 it already became clear that, if properly imple-mented, blockchain inherently solves the problem of misrecording votes because countingvotes is done automatically. However, misrecording of votes also entitles that the votershould be enabled to correct (or change) voter options after the vote has been casted. Withinthe architecture this problem is solved with a second voting round during the election daywith a new linkable ring signature scheme which supported by the findings in the tech-nical interview with the blockchain experts (see section 5.3). Compared to Votebook andVoteWatcher it seems like there is made progress because this architecture models a situa-tion in which central polling stations are used with the possibility of correcting the castedvote. Like described in the previous point this is also an important factor for proxy votingbecause in this situation it is possible to cast a vote when the proxy voter has filled in thewrong options. There can therefore concluded that is likely that misrecording of votes is notpossible when an implementation based on this architecture is created.

• Voter impersonation: In section 5.2 it became clear that the problems regarding imperson-ation of voters cannot be solved with help of blockchain technology. It is always necessaryto have a CA who knows which people are eligible to vote in order to authorize the rightpersons. Regarding voter impersonation we therefore came to the same conclusion as theanalysis of VoteWatcher and Votebook: if the context of the system does not provide a propermechanism for authenticating voters, the blockchain system itself will also not be able to au-thenticate voters; based on the findings in this research, it seems like blockchain technologycannot prevent fraud regarding voter impersonation.

• Proper secret ballot voting mechanism: In this thesis the use of linkable ring signatures areproposed in order to guarantee that only the voter can see what he or she has voted duringelection day. In conjunction with the usage of public blockchain systems this has becomean important aspect because once data is stored on the blockchain it becomes challenging toget rid of the voting data after the elections (see subsection 3.2.3). As described in subsec-tion 5.3.2 the usage of linkable ring signatures is promising but the stakeholder annotatedthat the current architecture could be improved by a less error prone mechanism in orderto distribute the keys among the voters (future research needs to clarify which method isbetter: the mechanism proposed in this thesis or ’Swarm intelligence’ like the stakeholdersuggested). Based on these findings there can therefore be concluded that the current archi-tecture may guarantee prevention of fraud or revealing identities regarding secret ballot vot-ing. This implies that this research may made some progress compared to other blockchaine-voting implementations like FollowMyVote, Votebook and VoteWatcher (which all failedto deliver an implementation which prevents that the CA can read the ballot).

Chapter 6

Discussion

In this chapter the limitations of this thesis and further research possibilities on the intersectionof blockchain and e-voting will be given.

6.1 Limitations

First of all, during the thesis there was no room for validation by simulation because of the shorttime-frame of the thesis. This is a limitation because it was not possible to verify the proposed de-sign by executing election to see whether it worked practically. Therefore, there has been decidedto perform validation sessions with experts on this subject to verify the design. Furthermore,during this thesis only the first three steps of the Design Science Approach by Wieringa [2] are ex-ecuted. This implies that the architecture is just only a design and not a full implementation of theproposed system. Moreover, the proposed architecture contains some key management aspectsregarding both the CA and voter (i.e. they both need to generate public-private key pairs). Thiscould potentially cause problems because there is more responsibility assigned to voters than incurrent electoral processes (like the Dutch and American elections). Additionally, voting fromown device is included in this description but has, like described, some serious drawbacks whenused in critical situations like national elections. For example, there is always some chance that adevice is infected with malware which results in a situation in which a vote is not really added tothe blockchain while it seems like it is. Besides, totally decentralized elections without a CA arewith the current technologies impossible due to the fact that a CA is necessary in order to identifywho is an eligible voter.

6.2 Future work

Because of these limitations, there needs to be done further research on the behavior of the pro-posed system and the beneficial relationship between blockchain and e-voting. Firstly, the pro-posed system should be simulated in order to see how the design behaves within practice byexecuting the last steps of the Design Science Approach by Wieringa [2] (namely Treatment Im-plementation and Implementation Evaluation). The design contains the introduction of LightClients to enhance the synchronization process and to reduce the data storage on mobile devices.The use of Light Clients has some difficult practicalities like making sure that there are enoughfull nodes running during the election. This thesis does not contain a description how to exactlyestablish the use of Light Clients although the blocks in the blockchain have the capability to beused in a Light Client setting (i.e. by using Merkle trees) and that a voting currency is neededto make it interesting enough to run full nodes. This also implies that the usage Light Clients issomething that needs to be researched in future work. Moreover, it is also important to mentionthat when this architecture is used for implementation, the low-level technical static and dynamicspecification (class and sequence diagrams) need to be adjusted to the real-world situation. Thisis the case because this thesis does not take into account if an existing blockchain system is used(like Ethereum) or a new blockchain platform is built from scratch. Finally, it is also important to

79

CHAPTER 6. DISCUSSION 80

look in future work to the usage of so-called ’Swarm intelligence’, which was mentioned by theblockchain experts in technical validation session (see section 5.3). When ’Swarm intelligence’ isresearched it is important to compare the method of distributing keys in this architecture to thatof a situation in which ’Swarm intelligence’ is used and determine which method does preserveprivacy better.

Chapter 7

Conclusion

The main goal of this research is to investigate how blockchain technology can contribute to atransparent voting process in order to enhance the overall security of (e-)voting systems. Thisgoal was transformed into three research questions, which each answered an important facet ofpresenting a transparent and secure design. These three research questions were answered duringthe execution of the Design Science cycle in three distinct phases namely the problem investiga-tion phase (RQ1), the treatment design phase (RQ2) and the treatment validation phase (RQ3).

First of all, in the problem investigation phase (see chapter 3), a SLR was executed followed bya domain analysis of the three central domains in this thesis. The concepts of information secu-rity (like hashing and encryption) are important in order to explain how blockchain technologyworks properly. Moreover, this domain analysis also contained an analysis of the flaws in bothcentralized and blockchain voting systems. These were used in order to define success criteriawhich were used to validate the proposed treatment from the treatment design phase. Secondly,in the treatment design phase (see chapter 4), the architectural style of the proposed treatmentwas presented. Aspects as internal software structure, synchronization, technical mechanismsfor preservation of privacy and the usage of public key cryptography were introduced. Afterthat, it was necessary to define requirements from both the stakeholder and technical perspec-tive (based on the goals and stakeholders that were defined in the problem investigation phase).These requirements were used in order to create a set of models which together form the archi-tecture that is presented in this thesis. These set of models consisted of four use cases wherebyeach use case models an important sub process, a UML Component Diagram which contained acoarse-grained description of the subsystems and its component, a class diagram which indicatedhow the subsystems and components were further divided into classes and attributes and foursequence diagrams which showed how the use cases should be executed with help of the staticstructure proposed in the class diagram. Finally, in the treatment validation phase (see chapter 5),three interviews with stakeholders and experts in the domain of e-voting and blockchain weredescribed. In the first two interviews the stakeholder was explicitly asked whether the successcriteria were met while the last interview had a more technical character and was used to discussthe technical practicalities of the proposed architecture.

Current voting and blockchain systems are aligned by developing an architecture which tries tosolve the problems described in both current electoral processes and e-voting blockchain imple-mentations (RQ1). In order to try to solve these problems it was necessary to design the architec-ture with a set of important decisions such as linkable ring signatures, the internal structure of thevoting booths, give a description how truly random numbers should be generated and producea set of models which precisely annotate how to structure an implementation that is developedwith help of this architecture (RQ2). It became clear that disappearance of votes may be pre-vented, unauthorized altering votes on the blockchain becomes less likely, voter impersonation isan aspect that should be solved by the context of the system, a possible mechanism for preserveprivacy is presented and proxy voting resembles the Dutch situation but with the possibility tocheck whether the right voting options were casted (RQ3).

81

Bibliography

[1] T. S. Da Silva, A. Martin, F. Maurer, and M. Silveira, “User-centered design and agile meth-ods: a systematic review,” in Agile Conference (AGILE), 2011. IEEE, 2011, pp. 77–86.

[2] R. J. Wieringa, “Observational case studies,” in Design Science Methodology for InformationSystems and Software Engineering. Springer, 2014, pp. 225–245.

[3] C. P. Pfleeger and S. L. Pfleeger, Security in computing. Prentice Hall Professional TechnicalReference, 2002.

[4] Kiesraad.nl. (2017) Provinciale staten. [Online]. Available: https://www.kiesraad.nl/verkiezingen/inhoud/provinciale-staten

[5] USA.gov. (2017) Presidential Election Process. [Online]. Available: https://www.usa.gov/election

[6] The Hall Institute of Public Policy. (2012) What Happens When You Vote in NewJersey: A step-by-step Guide. [Online]. Available: https://www.youtube.com/watch?v=2bbmod3PG8M

[7] VerifiedVoting.org. (2016) Sequoia (Dominion) AVC Advantage. [Online]. Available:https://www.verifiedvoting.org/resources/voting-equipment/sequoia/avc-advantage

[8] ARGU. (2017) Nederland | Forum voor inhoudelijke discussie | ARGU. [Online]. Available:https://argu.co

[9] BitcoinWiki. (2017) Block hashing algorithm. [Online]. Available: https://en.bitcoin.it/wiki/block_hashing_algorithm

[10] M. Wander. (2011) How Bitcoin works. [Online]. Available: https://www.vs.uni-due.de/wander/20110629_Bitcoin_Wander.pdf

[11] Kirill Fakhroutdinov. (2017) UML Component Diagrams. [Online]. Available: http://www.uml-diagrams.org/component-diagrams.html

[12] RTL Nieuws. (2017) Met potlood stemmen onveilig: verkiezingsuitslag een-voudig te hacken. [Online]. Available: http://www.rtlnieuws.nl/nederland/politiek/met-potlood-stemmen-onveilig-verkiezingsuitslag-eenvoudig-te-hacken

[13] S. Bakker and J. Bunskoek. (2017) Van alles misgegaan bij optellen stem-men verkiezingen. [Online]. Available: https://www.rtlnieuws.nl/nederland/politiek/van-alles-misgegaan-bij-optellen-stemmen-verkiezingen

[14] B. Barnett. (2016) America’s Electronic Voting Machines Are Scar-ily Easy Targets. [Online]. Available: https://www.wired.com/2016/08/americas-voting-machines-arent-ready-election

[15] K. Zetter. (2015) Virginia Finally Drops America’s ‘Worst Vot-ing Machines’. [Online]. Available: https://www.wired.com/2015/08/virginia-finally-drops-americas-worst-voting-machines/

82

https://www.kiesraad.nl/verkiezingen/inhoud/provinciale-staten

https://www.kiesraad.nl/verkiezingen/inhoud/provinciale-staten

https://www.usa.gov/election

https://www.usa.gov/election

https://www.youtube.com/watch?v=2bbmod3PG8M

https://www.youtube.com/watch?v=2bbmod3PG8M

https://www.verifiedvoting.org/resources/voting-equipment/sequoia/avc-advantage

https://argu.co

https://en.bitcoin.it/wiki/block_hashing_algorithm

https://en.bitcoin.it/wiki/block_hashing_algorithm

https://www.vs.uni-due.de/wander/20110629_Bitcoin_Wander.pdf

https://www.vs.uni-due.de/wander/20110629_Bitcoin_Wander.pdf

http://www.uml-diagrams.org/component-diagrams.html

http://www.uml-diagrams.org/component-diagrams.html

http://www.rtlnieuws.nl/nederland/politiek/met-potlood-stemmen-onveilig-verkiezingsuitslag-eenvoudig-te-hacken

http://www.rtlnieuws.nl/nederland/politiek/met-potlood-stemmen-onveilig-verkiezingsuitslag-eenvoudig-te-hacken

https://www.rtlnieuws.nl/nederland/politiek/van-alles-misgegaan-bij-optellen-stemmen-verkiezingen

https://www.rtlnieuws.nl/nederland/politiek/van-alles-misgegaan-bij-optellen-stemmen-verkiezingen

https://www.wired.com/2016/08/americas-voting-machines-arent-ready-election

https://www.wired.com/2016/08/americas-voting-machines-arent-ready-election

https://www.wired.com/2015/08/virginia-finally-drops-americas-worst-voting-machines/

https://www.wired.com/2015/08/virginia-finally-drops-americas-worst-voting-machines/

BIBLIOGRAPHY 83

[16] Aceproject. (2017) Voting operations: Voter fraud. [Online]. Available: http://aceproject.org/ace-en/topics/vo/vog/vog05/vog05b

[17] A. Antonopoulos. (2014) Bitcoin security model: trust by computation. [Online]. Available:http://radar.oreilly.com/2014/02/bitcoin-security-model-trust-by-computation.html

[18] A. Kofod-Petersen, “How to do a structured literature review in computer science,” Docu-ment released as a guide to performing a Structured Literature Review at NTNU, vol. 19, p. 2014,2012.

[19] Wikipedia. (2017) Precision and recall - Wikipedia, the free encyclopedia. [Online].Available: https://en.wikipedia.org/wiki/precision_and_recall

[20] G. Stoneburner, C. Hayden, and A. Feringa, “Engineering principles for information tech-nology security (a baseline for achieving security),” DTIC Document, Tech. Rep., 2001.

[21] A. J. Menezes, P. C. Van Oorschot, and S. A. Vanstone, Handbook of applied cryptography. CRCpress, 1996.

[22] S. Katsikas, Information systems security: facing the information society of the 21st century.Springer, 2016.

[23] M. E. Whitman, “Enemy at the gate: threats to information security,” Communications of theACM, vol. 46, no. 8, pp. 91–95, 2003.

[24] Wikipedia. (2017) Dutch general election, 2017 - Wikipedia, the free encyclopedia. [Online].Available: https://en.wikipedia.org/wiki/dutch_general_election,_2017

[25] Wikipedia. (2017) Proportional representation - Wikipedia, the free encyclopedia. [Online].Available: https://en.wikipedia.org/wiki/proportional_representation

[26] Wikipedia. (2017) Kiesdeler - Wikipedia, the free encyclopedia. [Online]. Available:https://nl.wikipedia.org/wiki/kiesdeler

[27] A. LaTour. (2017) What’s The Point Of A National Convention? They Could Be MoreImportant Than Ever This Year. [Online]. Available: https://www.bustle.com/articles/150872

[28] Wikipedia. (2017) Electoral college (United States) - Wikipedia, the free encyclopedia.[Online]. Available: https://en.wikipedia.org/wiki/Electoral_College_(United_States)

[29] R. Osgood. (2016) The future of democracy: Blockchain voting. [Online]. Available:http://www.cs.tufts.edu/comp/116/archive/fall2016/rosgood.pdf

[30] VOTE.org, “New Jersey Absentee Ballot,” 2016. [Online]. Available: https://www.vote.org/absentee-ballot/new-jersey/

[31] State of New Jersey. (2017) Voting equipment inventory.[Online]. Available: http://www.nj.gov/state/elections/voting-equipment/voting-machine-inventory-by%20county-021511.pdf

[32] C. Meter, “Design of distributed voting systems,” arXiv preprint arXiv:1702.02566, 2017.

[33] F. Caiazzo and M. Chow. (2016) A block-chain implemented voting system. [Online].Available: http://www.cs.tufts.edu/comp/116/archive/fall2016/fcaiazzo.pdf

[34] Wikipedia. (2017) Hash function - Wikipedia, the free encyclopedia. [Online]. Available:https://en.wikipedia.org/wiki/hash_function

[35] V. Buterin. (2017) Light clients and proof of stake. [Online]. Available: https://blog.ethereum.org/2015/01/10/light-clients-proof-stake/

[36] M. Szydlo, “Merkle tree traversal in log space and time,” in International Conference on theTheory and Applications of Cryptographic Techniques. Springer, 2004, pp. 541–554.

http://aceproject.org/ace-en/topics/vo/vog/vog05/vog05b

http://aceproject.org/ace-en/topics/vo/vog/vog05/vog05b

http://radar.oreilly.com/2014/02/bitcoin-security-model-trust-by-computation.html

https://en.wikipedia.org/wiki/precision_and_recall

https://en.wikipedia.org/wiki/dutch_general_election,_2017

https://en.wikipedia.org/wiki/proportional_representation

https://nl.wikipedia.org/wiki/kiesdeler

https://www.bustle.com/articles/150872

https://www.bustle.com/articles/150872

https://en.wikipedia.org/wiki/Electoral_College_(United_States)

http://www.cs.tufts.edu/comp/116/archive/fall2016/rosgood.pdf

https://www.vote.org/absentee-ballot/new-jersey/

https://www.vote.org/absentee-ballot/new-jersey/

http://www.nj.gov/state/elections/voting-equipment/voting-machine-inventory-by%20county-021511.pdf

http://www.nj.gov/state/elections/voting-equipment/voting-machine-inventory-by%20county-021511.pdf

http://www.cs.tufts.edu/comp/116/archive/fall2016/fcaiazzo.pdf

https://en.wikipedia.org/wiki/hash_function

https://blog.ethereum.org/2015/01/10/light-clients-proof-stake/

https://blog.ethereum.org/2015/01/10/light-clients-proof-stake/

BIBLIOGRAPHY 84

[37] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten, “Sok: Researchperspectives and challenges for bitcoin and cryptocurrencies,” in Security and Privacy (SP),2015 IEEE Symposium on. IEEE, 2015, pp. 104–121.

[38] Blockchain.info, “Wallet Technical FAQ,” 2017. [Online]. Available: https://blockchain.info/nl/wallet/technical-faq

[39] M. Pilkington, “Blockchain technology: principles and applications,” Browser Download ThisPaper, 2015.

[40] J. S. Czepluch, N. Z. Lollike, and S. O. Malone, “The use of block chain technology in differentapplication domains,” The IT University of Copenhagen, Copenhagen, 2015.

[41] FollowMyVote. (2017) FollowMyVote: The Online Voting Platform of The Future. [Online].Available: https://followmyvote.com/

[42] K. Kirby, A. Masi, and F. Maymi. (2016) Votebook: A proposal for a blockchain-basedelectronic voting system. [Online]. Available: https://www.economist.com/sites/default/files/nyu.pdf

[43] VoteWatcher. VoteWatcher - The World’s Most Transparent Voting Machine. [Online].Available: http://votewatcher.com/

[44] A. Wright and P. De Filippi. (2015) Decentralized blockchain technology and the rise of lexcryptographia. [Online]. Available: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2580664

[45] M. Swan, Blockchain: Blueprint for a new economy. O’Reilly Media, Inc., 2015.

[46] CoinMarketCap. (2017) Cryptocurrency market captializations. [Online]. Available: https://www.coinmarketcap.com

[47] A. Blais and R. Young, “Why do people vote? an experiment in rationality,” Public Choice,vol. 99, no. 1-2, pp. 39–55, 1999.

[48] Wikipedia. (2017) Hacker - Wikipedia, the free encyclopedia. [Online]. Available:https://en.wikipedia.org/wiki/hacker

[49] Wikipedia. (2017) Electoral fraud - Wikipedia, the free encyclopedia. [Online]. Available:https://en.wikipedia.org/wiki/electoral_fraud

[50] Wikipedia. (2017) Architecture - Wikipedia, the free encyclopedia. [Online]. Available:https://en.wikipedia.org/wiki/architecture

[51] C. Canal, E. Pimentel, and J. M. Troya, “Compatibility and inheritance in software architec-tures,” Science of Computer Programming, vol. 41, no. 2, pp. 105–138, 2001.

[52] J. Deacon. (2009) Model-View-Controller (MVC) Architecture. [Online]. Available: http://www.battersea-locksmith.co.uk/briefings/MVC.pdf

[53] E. M. Royer and C. E. Perkins, “Multicast operation of the ad-hoc on-demand distance vectorrouting protocol,” in Proceedings of the 5th annual ACM/IEEE international conference on Mobilecomputing and networking. ACM, 1999, pp. 207–218.

[54] R. Mercer, “Privacy on the blockchain: Unique ring signatures,” arXiv preprintarXiv:1612.01188, 2016.

[55] S. Goldwasser, S. Micali, and R. L. Rivest, “A digital signature scheme secure against adap-tive chosen-message attacks,” SIAM Journal on Computing, vol. 17, no. 2, pp. 281–308, 1988.

[56] S. Meiklejohn. (2011) An exploration of group and ring signatures. [Online]. Available:https://cseweb.ucsd.edu/~smeiklejohn/files/researchexam-slides.pdf

https://blockchain.info/nl/wallet/technical-faq

https://blockchain.info/nl/wallet/technical-faq

https://followmyvote.com/

https://www.economist.com/sites/default/files/nyu.pdf

https://www.economist.com/sites/default/files/nyu.pdf

http://votewatcher.com/

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2580664

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2580664

https://www.coinmarketcap.com

https://www.coinmarketcap.com

https://en.wikipedia.org/wiki/hacker

https://en.wikipedia.org/wiki/electoral_fraud

https://en.wikipedia.org/wiki/architecture

http://www.battersea-locksmith.co.uk/briefings/MVC.pdf

http://www.battersea-locksmith.co.uk/briefings/MVC.pdf

https://cseweb.ucsd.edu/~smeiklejohn/files/researchexam-slides.pdf

BIBLIOGRAPHY 85

[57] K. Chalkias, F. Baldimtsi, D. Hristu-Varsakelis, and G. Stephanides, “Mathematical problemsand algorithms for timed-release encryption,” Bulletin of the Transilvania University of Brasov•Vol, vol. 2, p. 51, 2009.

[58] BitcoinWiki. (2016) Clearing up misconceptions about full nodes. [Online]. Available:https://en.bitcoin.it/wiki/Clearing_Up_Misconceptions_About_Full_Nodes

[59] D. Benyon, P. Turner, and S. Turner, Designing interactive systems: People, activities, contexts,technologies. Pearson Education, 2005.

[60] T. Graves. (2012) Requirements and constraints. [Online]. Available: http://weblog.tetradian.com/2012/10/31/requirements-and-constraints/

[61] E. Peter. (2005) Capturing Architectural Requirements. [Online]. Available: https://www.ibm.com/developerworks/rational/library/4706.html

[62] Facebook. (2017) Kan ik meerdere Facebook-accounts maken? [Online]. Available:https://www.facebook.com/help/975828035803295

[63] Sodility. (2017) Introduction to Smart Contracts. [Online]. Available: http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html

https://en.bitcoin.it/wiki/Clearing_Up_Misconceptions_About_Full_Nodes

http://weblog.tetradian.com/2012/10/31/requirements-and-constraints/

http://weblog.tetradian.com/2012/10/31/requirements-and-constraints/

https://www.ibm.com/developerworks/rational/library/4706.html

https://www.ibm.com/developerworks/rational/library/4706.html

https://www.facebook.com/help/975828035803295

http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html

http://solidity.readthedocs.io/en/develop/introduction-to-smart-contracts.html

Appendix A

Glossary

In this glossary most of the important terms and concepts are explained. In Table A.1 a clearoverview of the concepts that are used throughout the thesis is given.

Concept Explanation of the concept51% attack A phenomenon within the domain of blockchain technology whereby a

single party possesses more than 51% of the computational power (Proofof Work algorithms) or more than 51% of the assets (Proof of Stake algo-rithms). This makes it possible to add, delete or edit transactions withoutconsensus of the other nodes.

Architecture A blueprint or description of the components inside a systemAuditability Every action that happens inside the system, can be traced back to a par-

ticular assetAuthentication Ability to confirm that the user is how he or she says that he or she isAvailability The system must be available when the users wants it to be availableBallot paper A paper containing the available options to vote where the voter will

make its decisionBallot box The sealed container where the votes/ballot papers are disposed in after

selecting (one of) the available options.Bitcoin A cryptocurrency assisted by blockchain technology as underlying mech-

anismBlack hat hacker A hacker who hacks systems with the purpose of acting malicious once

entered the systemBlock A set of transactions within the chain of blocks including a header with

informationBlockchain A distributed database whereby every computer in the network has the

entire database and can therefore verify every transaction in the networkBroadcasting A way of communicating with other hosts whereby a message is send to

as much hosts as possibleBSN number A Citizen Service Number (BSN) can be seen as the unique identifier of a

personCabinet A set of political parties or politicians that work together to push certain

legislation, whereby the total amount of politicians in the cabinet has amajority in the House of Representatives.

Candidate Someone who is selected by others to have the rights to do somethingCentral Authority An entity which arranges the elections and knows which persons are part

of the group of votersCoalition See cabinetConfidentiality The only entities (e.g. persons and other computers) that can access the

computer resources are the ones that are authorized.

86

APPENDIX A. GLOSSARY 87

Concept Explanation of the conceptConsensus A protocol within a particular blockchain system which is used to unam-

biguously define which rules must be adhered in order to add transac-tions

Consortium blockchain A hybrid type of blockchain whereby a set of parties can only add trans-actions to the blockchain

Control A certain entity (i.e. technique, procedure or action) that reduces the vul-nerability

Command Line Inter-face (CLI)

An Operating System utility which makes it possible to run programswithout graphical interface

Cryptocurrency A currency that is established by using cryptographic techniques such ashashing

Cryptography A research within Computer Science which researches techniques cryp-tographic techniques

Data immutability A phenomenon which describes a situation in which data can only becreated and not edited, updated or deleted.

Decryption The process of transforming ciphertext back into plaintext with an algo-rithm and a key

Digital signature A mechanism which makes it possible to couple a certain sender with acertain message

Distance-Vector Rout-ing protocol

A routing protocol which is used in an ad-hoc fashion which implies thata node only communicates with nodes that are geographically close

Distributed LedgerTechnology

See blockchain

Double spending prob-lem

Phenomenon whereby (without protection) a digital asset (such as digitalcurrency) can be used or spend twice.

Downs paradox A paradox which describes a contradiction between the amount of effortthat must be given with the minimum of returned investment regardingcasting a vote

Ethereum Currently the second largest blockchain system in the world whichmakes it possible to store code inside transactions

Electoral College Final political body in the US presidential election process that picks apresidential candidate based on, but not necessarily forced by, the popu-lar vote.

Electoral process The process whereby some entity (i.e. candidate or party) can be chosenout of a number of options.

Electoral quota (NL:’Kiesdeler’)

The amount of votes divided by the amount of seats available in theHouse of Representatives, that will decide how much votes each placein the House of Representatives will stand for during proportional repre-sentation.

Encryption The process of transforming plaintext into ciphertext with an algorithmand a key

Ethereum Blockchain technology whereby the content of the transactions are codewhich can be executed by a Virtual Machine

E-voting Electronic voting or the process of using computers that provide facilita-tion in a particular voting process

Fraud The act of deliberately manipulating information in order to gain an ad-vantage on other parties

Fork In the context of blockchain, a moment in time whereby there are two ormore related but not necessarily independent chains

Forward compatibility The act of making sure that future blocks of other related chains can beadded to the blockchain

Full node A node which has the entire blockchain state stored locallyGovernment An organization that provides a set of services to the citizens of a country.


Concept Explanation of the conceptGrey hat hacker A hacker with a hybrid mentality which implies that he or she will some-

times be a white hat hacker and sometimes a black hat hackerGroup signature A security scheme which makes it possible to determine whether the

sender is part of certain group without revealing who exactly the mes-sage sent

Hacking The act of using security flaws in a system to gain unauthorized access.Hard fork A fork whereby forward compatibility is not guaranteedHashing The practice of reducing data of any length to a fixed lengthHouse of Representa-tives

A government body which is typically directly assigned by the citizensof the country

Immutable data In the context of blockchain technology, immutable data implies thatwhen the local copy of the blockchain is synchronized with the other par-ticipating nodes it is impossible to remove the data from the blockchain

Informant The informant will consult all parties that made it to the House of Rep-resentatives (obtained at least one seat) to get information about theirpreferences and demands

Integrity There can be guaranteed that data is complete and not altered unautho-rized

Light Client A node which has only a part of the blockchain state storedLinkable ring signature A special type of ring signature which makes it possible to determine

whether a certain voter has already voted or notMerkle root The root value of the tree of transaction within a single block to intertwine

the chain of blocks and transactionsMerkle tree A data structure that is used inside a set of transactions (block) in order

to verifyModel-View-Controller(MVC-)architecture

A software architecture whereby the system is split into three compo-nents namely a controller (routes traffic), a view (presentation logic) anda model (business logic)

MoSCoW-method Prioritization method to prioritize aspects based on four types (musthave, should have, could have, won’t have)

Municipality A government body which is typically more close (local) to people thanthe House of Representatives

Non-repudiation Every action that happens inside the system, can be traced back to anindividual

Node A single computer that has a local copy of the blockchain and is enabledto verify incoming transactions

Political party An entity within the political continuum which goal is to change societyaccording to their political vision

Polling station An organized place where people can vote during an election dayPresidential elections Elections with as goal to select the new president of a nationPrivate blockchain A type of blockchain whereby only a single party can add transactions to

the blockchainPrivate key A key that is often used for decrypting ciphertextProof of Work A blockchain mining algorithm whereby the miner is rewarded based on

the amount of computational power he or she invests in mining blocksProof of Stake A blockchain mining algorithm whereby the miner is rewarded based on

the amount of currency he or she owns at the time of miningProportional represen-tation

The amount of votes are directly translated to a certain amount of seatsin the House of Representatives. For example, if a political party receives30% of the votes, that political party will receive 30% seats in the Houseof Representatives

Proxy voting Somebody that votes for any other particular person or party


Concept Explanation of the conceptPublic blockchain A type of blockchain whereby everyone can add transactions to the

blockchainPublic key A key that is often used for encrypting plaintextPublic-Key Infrastruc-ture (PKI)

An entire landscape of security mechanisms (e.g. public-private key pairgeneration and digital signatures) which makes it possible to securelysend information on a network

Ring signature A specific type of group signature which makes it impossible for a CA torevoke rights regarding anonymity (i.e. voter ID cannot be read when itis encrypted with help of ring signatures)

Public-private key pair The combination of a public and private key pair which are mathemati-cally related to each other

QR-code A visual representation of a text message or stringRandom reader A device which is often used by banks in order to authorize the user

when a payment through the internet must be doneSecurity (Information) security can be seen as the act of protecting computers

against undesirable actionsSecurity triad The combination of confidentiality, integrity and availability which de-

termine how secure a system isSecret ballot voting A type of voting process which demands that the filled in voter options

are only visible for the voterService-Oriented Archi-tecture (SOA)

A software architecture whereby the system consists of isolated compo-nents which solve a single problem

Smart contracts Often used as synonymous for blockchain but actually a way of storingcode inside a transaction within the Ethereum blockchain network

Soft fork A fork whereby forward compatibility is guaranteedSynchronization A mechanism within the blockchain protocol which makes it possible to

validate communication between nodesTemporary fork Some blocks can be verified parallel. When this occurs this is called a

temporary forkThreat Set of actions that together can cause an exploitTransaction A single value holding entity inside a block inside the blockchain. For

example, a single vote on a person.Treatment Concept from the Design Science Cycle whereby a potential but not yet

proven solution to a problem is presentedVerification The process of determining the identity of a particular entity or personVirtual Machine An isolated part of the system which has its own resourcesVirtual Private Network(VPN)

A communication technology which facilities save communication be-tween hosts on a potential unsafe network

Vote alteration An act whereby some vote is altered without the consent of the one thatsubmitted the vote

Voter Someone who is eligible or legal to vote about a specific caseVoter identificationnumber (voter ID)

Unique identifier of a person. For example, a unique identifier could bea BSN-number (see BSN-number)

Voting booth See polling stationVoting pass (NL: ’Stem-pas’)

A proof that somebody can vote (used in Dutch elections)

Voting software Software which is used to run or enable the voting processVoting threshold (NL:’Kiesdrempel’)

The minimum amount of votes a political party must achieve before be-ing selected in the House of Representatives. For example, in the DutchHouse of Representatives, a political party must obtain at least one seat(more than 1/150 part of the total votes).

Vulnerability A particular weakness in the system that can be exploited by a maliciousentity (e.g. humans and other computers)


Concept Explanation of the conceptWhite hacker A hacker tries to enter system in unauthorized way in order to report

security breaches

Table A.1: A glossary of all important concepts that are usedthroughout this research

Appendix B

Infographic

Figure B.1: Infographic, a short paper-based presentation of what has been done during the exe-cution of this thesis.

91

deﬁning an architecture for blockchain e-voting systems ... · relevant domains which are in this...

Documents