Deliverable D 7.2€¦ · Web viewAn Internet-Based Electronic Voting System (Contract Number:...

Quality and Reliability University of the Aegean Amaroussion

An Internet-Based Electronic Voting System(Contract Number: IST-2000-29518)

Financed: EU-IST-2000 Project acronym: e-VOTE

Date: 18-06-2002 Recipients: Project OfficerPartners

Deliverable Code: D7.2 Work Package: WP-7

Classification: Public Version: 3.0

Deliverable title: Consolidated Prototype 1 DocumentationAuthors: H. Grabow

Collaborators: S. Ikonomopoulos, V. Tsoumas, C. Lambrinoudakis, M. Karyda, G. Salomonsen, G. Georgaroudi, N. Tasopoulos, C. Vasiliou, L. Mitrou, S. Gritzalis, G. Pernul, D. Gritzalis

Internal Reviewers: S. Katsikas , K. Blathras

External Reviewer: P. Samarati

Summary: The scope of this deliverable is to present a comprehensive overview over the actual state of the e-VOTE system and the work done so far. It is emphasised that the development of the e-VOTE system will be performed in three consecutive rounds. The current deliverable is a consolidation of e-VOTE Deliverables D 3.1, D 4.1 and D 7.1 presenting the according results after the first round. In general, the deliverable can be divided into two parts. Part 1 mainly concentrates on the specification of the e-VOTE prototype 1 system. This comprises especially the used voting model, the different user/functional requirements as well as the system architecture. Part 2 on the other hand elaborates on the tests of prototype 1 as well as on the evaluation results gained thereby.

Keywords: Voting Model, System Architecture, User/Functional Requirements, Voting Protocol, e-VOTE Services, Prototype 1 Test and Evaluation

Document code: e-VOTE/WP-7/D7.2/3.0/18-06-2002

University of Essen University of the Aegean Cryptomathic Quality and Reliability Athens University of Economics and Business

e-VOTE: An Internet-based Electronic Voting System IST-2000-29518

Document History

Date Version Author Type of Action11-06-2002 0.1 H. Grabow (ESSEN) Initial Draft of the Deliverable12-06-2002 0.2 H. Grabow (ESSEN) Consolidation of Deliverables D 3.1, D 4.1 and

D 7.1 as well as modifications to the structure of the document

14-06-2002 0.3 H. Grabow (ESSEN) Modifications to the general structure of the document, modifications to Chapter 1 as well as minor corrections

14-06-2002 1.0 H. Grabow (ESSEN) Final Version sent for Internal Review (Q&R)16-06-2002 2.0 K. Blathras, N. Tassopoulos

(Q&R)Internal Review

18-06-2002 3.0 S. Katsikas & C. Lambrinoudakis (AEGEAN)

Second round of Internal ReviewSent to the External Reviewer (P.Samarati)

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 2 of 188


Executive Summary

This document constitutes the public Deliverable D 7.2 (WP7) of the e-VOTE project and its goal is to present a comprehensive overview over the actual state of the e-VOTE system and the work done so far. It is emphasised that the collection and analysis of user requirements, as well as the functional specification, development and test respective evaluation activities, of the e-VOTE system will be performed in three consecutive rounds. The current deliverable presents the according results after the first round (i.e. prototype 1). More specifically, the following objectives will be pursued:

Provide a concise description of the methodology adopted for the iterative collection, analysis, definition and consolidation of user/functional requirements for an electronic voting system.

Identify the desired (functional and non-functional) properties of a successful electronic voting system.

Specify and provide a functional description of the voting services that the system should support. Emphasis will be given to the technical infrastructure that the services ‘impose’ to their end-users (voters).

Provide a high level description of the voting protocol to be implemented, as well as an overall description of the e-VOTE system architecture. Emphasis is given in specifying the architecture of the e-VOTE prototype 1.

Define the system services and functions that are necessary for satisfying the stated requirements (with emphasis on Prototype 1).

Provide an analytical description of the tests that will be performed with the pilot system as well as its prototypes, targeting at extensive testing of all system services, interoperability issues, usability, system security and user acceptance.

Report on the evaluation results of the first test round and on any technical, functional or user acceptance problems identified thereby.

The current deliverable is a consolidation of e-VOTE deliverables D3.1 (“User Requirements: Prototype1”; Doc. Code: e-VOTE/WP-3/D3.1/FD/3.0/08-02-2002), D4.1 (“Functional Specifications: Prototype 1”; Doc. Code: e-VOTE/WP-4/D4.1/3.0/16.04.2002) and D7.1 (“Prototype 1 Validation”; Doc. Code: e-VOTE/WP-7/D7.1/2.0/10-06-2002). In general, the document can be divided into two parts. Part 1 (Chapters 1 - 7) mainly concentrates on the specification of the e-VOTE prototype 1 system. This comprises especially the used voting model, the different user/functional requirements as well as the system architecture. Part 2 (Chapters 8 - 16) on the other hand elaborates on the tests of prototype 1 as well as on the evaluation results gained thereby.

Part 1: Prototype 1 Specification

Chapter 1 (“Methodology of Work”) provides an overview of the Rational Unified Process (RUP) methodology that has been adopted by the consortium for capturing the user/functional requirements. According to the methodology, the first step to be done is to construct a voting model and thus to ensure that all involved parties have a common understanding of the voting process(es) to be automated.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 3 of 188


The above mentioned voting model as well as the different use cases identified therein are described in detail in Chapter 2 (“Voting Model”). Chapter 3 (“E - Vote RequirementsSpecification”) for each use case lists the functional and non-functional requirements for the e-VOTE system as these were derived from the voting model.

Chapter 4 (“State of the art on electronic voting technologies”) assesses existing e-voting protocols, identifying major risks, limitations and deficiencies related to them. Furthermore, Chapter 5 (“e-VOTE Architecture”) provides a high level description of the voting protocol used for the e-VOTE prototype 1 as well as the e-VOTE system architecture.

Chapter 6 (“e-VOTE Services Scenarios and Definitions”) classifies e-VOTE services according to the nature of the requested service as well as according to the system phase during which the service is being rendered. Based on this, Chapter 7 (“e-VOTE Services”) provides a detailed description of the specific services that will be supported by the e-VOTE system.

Part 2: Prototype 1 Test and Evaluation

Before explaining in detail the test and evaluation activities, Chapter 8 (“e-VOTE Prototype 1:Overview”) summarises the extend to which the identified use cases and their according user/functional requirements were implemented in the first prototype of the e-VOTE system. Furthermore, Chapter 9 (“e-VOTE Prototype 1: Methodology of Trials”) presents the methodology adopted for the validation of e-VOTE prototype 1, as well as the different type of tests conducted, namely: Basic Tests (BT), Capability Tests (CT) and Behaviour Resolution Tests (BRT).

Chapters 10 (“Description of Basic Tests (BT)”) and 11 (“Results of Basic Tests”) describe the Basic Tests conducted together with their results.

Chapters 12 (“Description of Capability and Behaviour Resolution Tests (ESSEN)”), 13 (“Results of Capability and Behaviour Resolution Tests (ESSEN)”), 14 (“Description ofCapability and Behaviour Resolution Tests (AEGEAN)”) and 15 (“Results of Capability andBehaviour Resolution Tests (AEGEAN)”) describe the Capability and Behaviour Resolution Tests conducted at the two pilot sites (ESSEN and AEGEAN respectively) together with their results.

Chapter 16 (“Test Conclusions”) summarises the findings and comments on the results of the e-VOTE prototype 1 tests.

The document concludes with a list of references (Chapter 17) and two appendices, containing important material used during the tests. Chapter 18 (“Appendix A - Questionnaires”) presents the two questionnaires that had to be answered by the test participants in order to evaluate their experiences with the e-VOTE system (good/bad aspects, necessary improvements, chances, risks, etc.), whereas Chapter 19 (“Appendix B – Ballot”) shows the ballot that was used for the simulated election.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 4 of 188


Table of Contents

1 METHODOLOGY OF WORK.......................................................................................7

1.1 Business Modelling......................................................................................................................9

1.2 Requirements Specification........................................................................................................10

2 VOTING MODEL...........................................................................................................13

2.1 General Elections.......................................................................................................................132.1.1 Business Use Case Model................................................................................................................13

2.1.1.1 Adjust Election Districts..............................................................................................................152.1.1.2 Update list of voters....................................................................................................................152.1.1.3 Provide Authentication Means....................................................................................................152.1.1.4 Set-up Election Centres...............................................................................................................162.1.1.5 Create Ballots..............................................................................................................................162.1.1.6 Authenticate Voter.......................................................................................................................172.1.1.7 Cast Vote.....................................................................................................................................172.1.1.8 Tally Votes...................................................................................................................................172.1.1.9 Consolidate Votes........................................................................................................................172.1.1.10 Verify Result Integrity.................................................................................................................17

2.1.2 Business Object Model....................................................................................................................172.1.2.1 Adjust Election Districts..............................................................................................................172.1.2.2 Update list of voters....................................................................................................................182.1.2.3 Provide Authentication Means....................................................................................................182.1.2.4 Set-up Election Centres...............................................................................................................192.1.2.5 Create Ballots..............................................................................................................................202.1.2.6 Authenticate Voter.......................................................................................................................202.1.2.7 Cast Vote.....................................................................................................................................212.1.2.8 Tally Votes...................................................................................................................................222.1.2.9 Consolidate Votes........................................................................................................................222.1.2.10 Verify Result Integrity.................................................................................................................23

2.2 Internal Elections........................................................................................................................242.2.1 Business Use Case Model................................................................................................................24

2.2.1.1 Adjust Election Districts..............................................................................................................242.2.1.2 Determine Voters.........................................................................................................................242.2.1.3 Provide Authentication Means....................................................................................................252.2.1.4 Consolidate Votes........................................................................................................................25

2.2.2 Business Object Model....................................................................................................................252.2.2.1 Adjust Election Districts..............................................................................................................252.2.2.2 Determine Voters.........................................................................................................................252.2.2.3 Consolidate Votes........................................................................................................................25

2.3 Decision-Making........................................................................................................................252.3.1 Business Use Case Model................................................................................................................25

2.3.1.1 Adjust Election Districts..............................................................................................................262.3.1.2 Determine Voters.........................................................................................................................26

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 5 of 188


2.3.1.3 Provide Authentication Means....................................................................................................262.3.1.4 Create Ballots..............................................................................................................................262.3.1.5 Tally Votes...................................................................................................................................262.3.1.6 Consolidate Votes........................................................................................................................262.3.1.7 Verify Result Integrity.................................................................................................................26

2.3.2 Business Object Model....................................................................................................................262.3.2.1 Adjust Election Districts..............................................................................................................262.3.2.2 Determine Voters.........................................................................................................................262.3.2.3 Create Ballots..............................................................................................................................272.3.2.4 Consolidate Votes........................................................................................................................27

2.4 Polls............................................................................................................................................272.4.1 Business Use Case Model................................................................................................................27

2.4.1.1 Adjust Election Districts..............................................................................................................272.4.1.2 Determine Voters.........................................................................................................................272.4.1.3 Provide Authentication Means....................................................................................................272.4.1.4 Create Ballots..............................................................................................................................272.4.1.5 Authenticate Voter.......................................................................................................................282.4.1.6 Cast Vote.....................................................................................................................................282.4.1.7 Tally Votes...................................................................................................................................282.4.1.8 Consolidate Votes........................................................................................................................282.4.1.9 Verify Result Integrity.................................................................................................................28

2.4.2 Business Object Model....................................................................................................................282.4.2.1 Adjust Election Districts..............................................................................................................282.4.2.2 Determine Voters.........................................................................................................................282.4.2.3 Provide Authentication Means....................................................................................................282.4.2.4 Create Ballots..............................................................................................................................282.4.2.5 Authenticate Voter.......................................................................................................................292.4.2.6 Cast Vote.....................................................................................................................................292.4.2.7 Tally Votes...................................................................................................................................292.4.2.8 Consolidate Votes........................................................................................................................292.4.2.9 Verify Result Integrity.................................................................................................................29

3 E - VOTE REQUIREMENTS SPECIFICATION.......................................................30

3.1 General Elections.......................................................................................................................303.1.1 System Use Cases............................................................................................................................31

3.1.1.1 Authenticate Actor.......................................................................................................................323.1.1.2 Authenticate Key Actors..............................................................................................................373.1.1.3 Modify System State....................................................................................................................393.1.1.4 Manage Election Districts...........................................................................................................413.1.1.5 Manage Election Units................................................................................................................443.1.1.6 Provide Election Parameters......................................................................................................463.1.1.7 Manage Voters............................................................................................................................503.1.1.8 Provide Authentication Means....................................................................................................553.1.1.9 Manage Parties...........................................................................................................................583.1.1.10 Manage Candidates.....................................................................................................................613.1.1.11 Preview Ballots...........................................................................................................................643.1.1.12 Provide Party Info.......................................................................................................................663.1.1.13 Cast Vote.....................................................................................................................................673.1.1.14 Tally Votes...................................................................................................................................713.1.1.15 Verify Result Integrity.................................................................................................................73

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 6 of 188


3.1.2 System Wide Attributes...................................................................................................................74

4 STATE OF THE ART ON ELECTRONIC VOTING TECHNOLOGIES...............77

4.1 Assessment of voting protocols currently in use and related risks.............................................774.1.1 Blind Signatures...............................................................................................................................774.1.2 Untraceable Network Communication.............................................................................................774.1.3 Trusted hardware..............................................................................................................................784.1.4 Homomorphic Encryption................................................................................................................78

5 E-VOTE ARCHITECTURE..........................................................................................79

5.1 Entities in a Voting System........................................................................................................79

5.2 High-level description of the voting protocol to be implemented..............................................805.2.1 Production of Votes.........................................................................................................................805.2.2 Verification of Validity of Votes.....................................................................................................805.2.3 Counting Votes................................................................................................................................805.2.4 Decrypting the Result.......................................................................................................................815.2.5 Independent Verification..................................................................................................................815.2.6 Performance Issues..........................................................................................................................815.2.7 Authentication Layer........................................................................................................................815.2.8 Compliance with Requirements.......................................................................................................825.2.9 Future Directions..............................................................................................................................82

5.3 Secrecy of Votes.........................................................................................................................82

5.4 Authentication of Voters............................................................................................................835.4.1 Password Based Authentication (PBA)...........................................................................................835.4.2 PBA. One password - PKI at the back end......................................................................................835.4.3 PBA – Two Passwords.....................................................................................................................835.4.4 PBA. Two passwords - PKI at the back end....................................................................................845.4.5 PBA with a Second Authorisation Channel.....................................................................................845.4.6 PBA with a second Authorization Channel and PKI.......................................................................845.4.7 Chip Cards supporting PKI..............................................................................................................845.4.8 USB Tokens supporting PKI............................................................................................................855.4.9 Authentication of Election Administrators......................................................................................855.4.10 Authentication of Servers.................................................................................................................855.4.11 Two Example Architectures.............................................................................................................85

5.5 Possible Extensions....................................................................................................................905.5.1 Protection of Voting Front Ends against Hackers............................................................................905.5.2 Protection against Vote Buying (1)..................................................................................................905.5.3 Protection against Vote Buying (2)..................................................................................................915.5.4 Additional Performance for secret Votes.........................................................................................91

5.6 e-VOTE Prototype 1 architecture...............................................................................................92

6 E-VOTE SERVICES SCENARIOS AND DEFINITIONS.........................................93

6.1 Introduction................................................................................................................................93

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 7 of 188


6.2 Classification of e-VOTE services.............................................................................................936.2.1 Introduction......................................................................................................................................936.2.2 Service classification according to the nature of the service...........................................................946.2.3 Service classification according to the system phase.......................................................................94

6.3 e-VOTE interaction scenarios....................................................................................................956.3.1 Voter – e-VOTE system...................................................................................................................956.3.2 Election Organiser – e-VOTE system..............................................................................................95

7 E-VOTE SERVICES.......................................................................................................97

7.1 From scenarios to e-VOTE services...........................................................................................97

7.2 e-VOTE Services and Service Blocks........................................................................................97

7.3 e-VOTE Services........................................................................................................................98

7.4 e-VOTE Service Blocks.............................................................................................................99

8 E-VOTE PROTOTYPE 1: OVERVIEW....................................................................101

9 E-VOTE PROTOTYPE 1: METHODOLOGY OF TRIALS...................................104

9.1 Methodology of Trials..............................................................................................................1049.1.1 Trials Coverage..............................................................................................................................1049.1.2 Criteria for Trials Specification.....................................................................................................104

9.2 Testing Procedures...................................................................................................................1059.2.1 Test Environment and Resources...................................................................................................105

9.2.1.1 Pilot/Prototype Set Up..............................................................................................................1059.2.1.2 Hardware & Software...............................................................................................................1059.2.1.3 Participants...............................................................................................................................105

9.2.2 Test Case Steps..............................................................................................................................1079.2.2.1 Software Based Tests (SBT)......................................................................................................1079.2.2.2 Tests with Real Users (RUT).....................................................................................................107

9.2.2.2.1 Step 1: Initial Meeting.....................................................................................................................1079.2.2.2.2 Step 2: Pre-Test Questionnaire........................................................................................................1089.2.2.2.3 Step 3: Test of the e-VOTE prototype.............................................................................................1089.2.2.2.4 Step 4: Post-Test Questionnaire......................................................................................................1089.2.2.2.5 Step 5: Conclusion Meeting............................................................................................................1089.2.2.2.6 Step 6: Evaluation and Test Case Report........................................................................................108

10 DESCRIPTION OF BASIC TESTS (BT)...................................................................109

10.1 Testing the Stand-alone Operation of e-VOTE Prototype 1 Modules.....................................109

10.2 Manual Inspection of Messages...............................................................................................111

10.3 Verify that the System has been Set-Up correctly...................................................................11210.3.1 Check Application Server..............................................................................................................11310.3.2 Check Database Server..................................................................................................................114

10.4 Verify that the System Operates...............................................................................................11510.4.1 Authenticate Actor.........................................................................................................................11510.4.2 Provide Election Parameters..........................................................................................................11610.4.3 Manage Voters...............................................................................................................................11710.4.4 Provide Authentication Means.......................................................................................................118

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 8 of 188


10.4.5 Manage Candidates........................................................................................................................11910.4.6 Preview Ballots..............................................................................................................................12010.4.7 Cast Vote........................................................................................................................................12110.4.8 Tally Votes.....................................................................................................................................12210.4.9 Verify Result Integrity...................................................................................................................123

11 RESULTS OF BASIC TESTS......................................................................................124

11.1 Results from the Tests on the Stand-alone Operation of e-VOTE Prototype 1 Modules........124

11.2 Results from the Tests on the Manual Inspection of Messages...............................................124

11.3 Verification that the System has been Set-Up correctly...........................................................12511.3.1 Check Application Server..............................................................................................................12511.3.2 Check Database Server..................................................................................................................125

11.4 Verification that the System Operates......................................................................................12511.4.1 Authenticate Actor.........................................................................................................................12511.4.2 Provide Election Parameters..........................................................................................................12611.4.3 Manage Voters...............................................................................................................................12611.4.4 Provide Authentication Means.......................................................................................................12611.4.5 Manage Candidates........................................................................................................................12611.4.6 Preview Ballots..............................................................................................................................12711.4.7 Cast Vote........................................................................................................................................12711.4.8 Tally Votes.....................................................................................................................................12711.4.9 Verify Result Integrity...................................................................................................................127

11.5 Sub-conclusion.........................................................................................................................128

12 DESCRIPTION OF CAPABILITY AND BEHAVIOUR RESOLUTION TESTS (ESSEN).........................................................................................................................129

12.1 Capability Test with Real Users (CT-RUT).............................................................................129

12.2 Behaviour Resolution Tests with Real Users (BRT-RUT)......................................................13112.2.1 Penetration Testing – Casting Multiple Votes...............................................................................13112.2.2 Penetration Testing – Unauthorised Access...................................................................................133

13 RESULTS OF CAPABILITY AND BEHAVIOUR RESOLUTION TESTS (ESSEN)........................................................................................................................................136

13.1 Capability Test with Real Users (CT-RUT).............................................................................136

13.2 Behaviour Resolution Tests with Real Users (BRT-RUT)......................................................13613.2.1 Penetration Testing – Casting Multiple Votes...............................................................................13613.2.2 Penetration Testing – Unauthorised Access...................................................................................137

13.3 Further Evaluation Results gathered from the Questionnaires.................................................13713.3.1 Pre-Test Questionnaire...................................................................................................................13713.3.2 Post-Test Questionnaire.................................................................................................................143

13.4 Further Evaluation Results gathered from the Conclusion Meeting........................................150

14 DESCRIPTION OF CAPABILITY AND BEHAVIOUR RESOLUTION TESTS

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 9 of 188


(AEGEAN)....................................................................................................................151

14.1 Capability Tests (CT)...............................................................................................................151

14.2 Behaviour Resolution Tests with Real Users (BRT - RUT)....................................................15214.2.1 Penetration testing – Information gathering...................................................................................15314.2.2 Penetration testing – Invalid input.................................................................................................154

14.3 Software Based Behaviour Resolution Tests (BRT - SBT).....................................................15514.3.1 Performance Test of Election Setup Page - I.................................................................................15614.3.2 Performance Test of Election Setup Page - II................................................................................15714.3.3 Performance Test of Election Vote Page - I..................................................................................15814.3.4 Performance Test of Election Vote Page - II.................................................................................16014.3.5 Performance Test of Election Counting Page - I...........................................................................161

15 RESULTS OF CAPABILITY AND BEHAVIOUR RESOLUTION TESTS (AEGEAN)....................................................................................................................164

15.1 Capability Tests (CT)...............................................................................................................164

15.2 Behaviour Resolution Tests with Real Users (BRT - RUT)....................................................16515.2.1 Penetration testing – Information gathering...................................................................................16515.2.2 Penetration testing – Invalid input.................................................................................................165

15.3 Software Based Behaviour Resolution Tests (BRT - SBT).....................................................16615.3.1 Performance Test of Election Setup Page - I.................................................................................16615.3.2 Performance Test of Election Setup Page - II................................................................................16615.3.3 Performance Test of Election Vote Page - I..................................................................................16815.3.4 Performance Test of Election Vote Page - II.................................................................................16915.3.5 Performance Test of Election Counting Page - I...........................................................................169

16 TEST CONCLUSIONS.................................................................................................171

17 REFERENCES..............................................................................................................172

18 APPENDIX A - QUESTIONNAIRES.........................................................................174

18.1 Pre-Test Questionnaire.............................................................................................................174

18.2 Post-Test Questionnaire...........................................................................................................182

19 Appendix B – Ballot........................................................................................................186

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 10 of 188


1 Methodology of Work

Taking into account suggestions and considerations found in [ix], the consortium’s decision was to adopt the Rational Unified Process (RUP) [xxiv] for modelling the e-VOTE workflows. This Section provides an overview of the methodology.

The Rational Unified Process is the synthesis of several older software development processes, exhibiting the following characteristics:

Use Case Driven: A use case is a piece of functionality in the system that gives a user a result of value. Use cases capture functional requirements (what the system should do) additionally connecting each requirement with one or more users of the system. In that way they both force developers to think in terms of value to users and drive the whole development process, since design and implementation models are developed on the basis of a use – case model. The benefit is that the development process becomes robust and manageable, as it is tightly coupled to the specification, design, implementation and testing of use cases.

Figure 1. The Rational Unified Process in a glance (Source: [xxiv])

Architecture Centric: While use cases drive the development process, their successful design and implementation heavily depends on the selection of software architecture. In the case of e-VOTE, for example, the emphasis should be on the system security. It is thus vital to early create a rough outline of the architecture. Although the use cases do not themselves impose architectural decisions, a general understanding of them is necessary in order to create the architectural outline. By being architecture centric, the development process allows for a system that both fulfils current requirements but also copes with future enhancements and changes.

Iterative and Incremental: The Rational Unified Process divides software projects into smaller pieces of work or miniprojects. Each miniproject is an iteration that results in an increment. Iterative development was foreseen in e-VOTE early at its inception, so the

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 11 of 188


development process selected fits naturally with the project workplan. During each iteration, developers identify and specify the relevant use cases, providing refinements where necessary, create a design using the chosen architecture as a guide, implement the design in components and verify that the components satisfy the use cases.

The Rational Unified Process uses the Unified Modelling Language (UML) [xvii] to visually describe its models. From a management perspective, the software lifecycle of the Rational Unified Process is decomposed over time into four sequential phases:

Inception: During this phase the system to be built is envisaged and an agreement between all stakeholders on its lifetime objectives is made. The primary objectives of the first iterations during this phase are to estimate the overall cost and schedule for the entire project, preparing the supporting environment for the project and estimating potential risks. This iteration coincides with the work performed until the date that the contract was signed. During later iterations of this phase – the time corresponding to the early WP3 tasks of this project – business modelling and requirements capture are performed, and the primary scenarios of operation that will drive the major design trade-offs are identified.

Elaboration: During this phase the majority of the use cases are specified in detail and the system architecture is designed in a way to cope with the requirements imposed by the inception phase and the use cases specified. At the end of this phase the activities and resources required to complete the project can be assessed and scheduled. For the e-VOTE project this phase corresponds to the med and latter tasks of WP3 and WP4.

Construction: During this phase the system is developed. Iterations during this phase lead to subsequent system increments (starting from a prototype) gradually implementing all use cases identified in the elaboration phase. Thus both the system itself and the use cases identified can be refined to better match the scope of the project. By the end of this phase the pilot system is developed and tested by users. Although defects may still exist, this is the system almost finished. This phase corresponds to the tasks of WP6 and WP7 of the current project.

Transition: According to the original methodology, during this phase the system is evaluated by a moderate numbers of users and final adjustments and amendments are made prior to full scale installation. This phase includes activities as training, on – site help provision and error correction after installation. For e-VOTE the transition phase is identified within the tasks of WP8.

Requirements capture has always been a difficult task in software engineering, primarily because of the culture differences between developers and users. In the context of the adopted methodology two major guidelines drive the requirements capture process: The language of the problem domain – rather than computer science jargon – is used to describe and validate the outcome of the requirements capture process, and modelling conventions (such as drawings to describe concepts) are kept to a minimum.

A typical workflow of the requirements capture process includes the following steps (which may be performed in parallel):

Understand System Context: One or more models (business model) of the current processes and workers are constructed. In that way developers familiarise themselves with the problem at hand and the potential system users – thus facilitating communication. Furthermore, a good understanding of the system to be built, from the user point of view, is also achieved, facilitating awareness of objections, suggestions and proposed solutions from both sides.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 12 of 188


List Candidate Requirements: During the inception and elaboration phases, people usually come up with several ideas that may turn into real requirements1. A list of these ideas is maintained since it contributes to the definition of the system use cases and the requirements resulting from them.

Capture functional Requirements: This is actually equivalent to finding and describing the use cases the system will support. Throughout the iterations of the elaboration phase system analysts may also specify how the user interface will look like during these use cases, by making specific proposals and exchanging ideas with the potential users.

Capture non-functional Requirements: The non-functional requirements are related to the underlying system structure and normally they have a severe impact on architectural decisions. Non-functional requirements can be specific to a use case or they can be system wide. Specifically for the e-VOTE system, non-functional requirements are expected to focus on security and accessibility issues.

In the following subsections we will describe the steps, as well as the notation used to formulate the conceptual model and the e-VOTE requirements specification.

1.1 Business Modelling

Business models are used for describing:

a) The business processes through the “business use case model” and

b) The way that business processes are realised through the “business object model”

In UML business use cases – just as normal use cases – are depicted with an oval icon:

Use Case Name

Figure 2. The Business Use Case Symbol

Each use case is connected with the actors that use it. Actors are depicted with the following icon:

Business Actor Name

Figure 3. Business Actor Symbol

In the case of e-VOTE, an obvious business use case is that of casting a vote. This use case

1 A very common mistake during this phase is to consider possibly interesting (for the developers) features of the final system as actual ‘requirements’. In e-VOTE special attention has been taken to avoid such phenomena.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 13 of 188


can be depicted as shown in Figure 4 below:

Voter Vote Casting

Figure 4. A Use Case example: Vote Casting

Each use case focuses on the role and purpose of the business use case, its goals and its workflow. Note that the workflow description in that level describes what the corresponding process does to deliver the desired goals. The way this is achieved is described in the business object model.

The business object model provides a description of how the business use cases are realised. The model includes “workers” and “business entities”. A business worker is depicted with the symbol of Figure 5, while a business entity with that of Figure 6.

Business Worker

Figure 5. Business Worker Symbol

Business Entity

Figure 6. Business Entity Symbol

The business object model may include several UML diagrams namely: class diagrams, activity diagrams, collaboration/sequence diagrams and state chart diagrams. For a detailed description of these diagrams the reader is referred to [xxiv].

1.2 Requirements Specification

Requirement specification is the description of the required system [ix]. In RUP requirements take the form of use cases. Note that “system use cases” introduced during this workflow are fundamentally different from the business use cases of the conceptual business model since the former describe functionality of the system that will be delivered while the latter describe functionality of the current business processes. The majority of system use cases, of course, have a direct correspondence to business use cases. Indeed the RUP provides guidelines for transformation of business use cases to system use cases, where business workers become actors of the system and use the new functionalities provided (or become obsolete in the new system).

In early iterations, involving requirements specification, use cases are described in a high level format (“high level use case”). A typical high-level system use case description consists of the following:

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 14 of 188


Use Case The name of the system use case.

Description A high level narrative description of the use case.

Purpose The goals that actors can achieve with the specific use case.

Related Business Use Case(s)

The business use case(s) this system use case derives from. Note that it is not necessary to have related business use cases since the system may introduce functionality not supported by the current business process.

Actors The actors participating in the use case.

Type System use cases are categorised as: primary (corresponding to major system functions), secondary (corresponding to minor or rarely used system functions) and optional (corresponding to system functions that may not be implemented).

Preconditions The conditions that must be met before the actor can perform the use case

In addition to the functional requirements expressed through the system use cases, the system will exhibit several non-functional requirements. Non-functional requirements can either be specific to a use case or they may pertain to the system as a whole. These supplementary requirements have been grouped into the following categories:

Security: Aim to support the main security properties as confidentiality, integrity, availability and accountability both in application and system level; they also provide for non-repudiation, anonymity and source verification.

Performance: Deal with issues like speed, efficiency, availability, accuracy, throughput, response time, recovery time, or resource usage.

Reliability: Include attributes as frequency / severity of failure, recoverability, predictability, accuracy and mean time between failure (MTBF).

Usability: Deal with issues like consistency in the user interface, online and context-sensitive help, quality of user documentation, training materials etc.

Supportability: Requirements related to system maintenance, adaptation, installation etc.

As more understanding of the system is achieved, system use cases are enriched with more details and become “expanded” use cases. These are usually described in a conversational style between the actors and the system2. A typical expanded system use case enhances the “description” field above with a “Course Of Events” description in the following format:

Typical Course of Events

2 In [ix] the author advances the categorisation further, defining essential (architecture independent) and real (in terms of system design) use cases. We consider this advance as excessive, since during the design phase all use cases will be accompanied by realization diagrams indicating how the design anticipates the implementation of the use case.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 15 of 188


Actor Action System Response

1. Voter asks to be authenticated 2. The system asks for user name – password

3. The voter enters required information 4. The system authenticates the user and presents available options

5. Voter selects:a. Option A - See DP-1b. Option B - See DP-2

Alternative Course of Events

Step 4: The system cannot authenticate the user. The authentication attempt is logged and the system asks for user name – password again.

Description of Decision Points

DP-1: User Selects Option A



Alternative Course of Events

….

DP-2: User Selects Option B



Figure 7. Typical Expanded System Use Case Format (Based on [ix])

As indicated in Figure 7, the system use case includes a decision point (step 5). In that case either the most common workflow (if other branches are rare) is described, or for the benefit of a better use case explanation more options are described.

Since this deliverable depicts the final outcome of the entire user/functional requirements specification workflow, only the expanded use cases, and not the high level ones, are included (see Chapter 3) in order to avoid duplication and reduce the size of the document.

After this introductory part, we will now go into the deeper details by first of all taking a closer look at the Voting Model that has been constructed for the e-VOTE project. Based on this model and the identified use cases the specific user/functional requirements attached to them will be presented.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 16 of 188


2 Voting Model

The business model is being utilised for both understanding the domain model and establishing communication between developers and users (Chapter 1). Specifically for the e-VOTE project the construction of the Voting Model has been considered necessary for an additional reason. Users – especially legal experts – expressed from the very early stages of the project their strong belief that the system should support all the transparency mechanisms that currently apply to the conventional voting process. As an example, the system should have the ability to verify that the number of ballots cast in a certain region matches the number of persons recorded as having voted. It is therefore evident that the great majority of requirements should and will originate from the voting process as it is currently conducted.

The voting model, presented in this Chapter, has been kept generic enough to be applicable to the common constitutional principles of all EU member states. Nevertheless, since there are slight differentiations of the legislative framework from one country to the other, it is evident that there are variations on the voting process. However, such variations neither affect the completeness nor the correctness of the voting model.

Although the voting process may be generally visualised in the context of an electoral procedure, e.g. general elections, four different application domains have been identified:

1. General Elections

2. Internal Election Procedures, e.g. at Universities, Trade Unions etc.

3. Decision-Making e.g. Referendum

4. Polls of indicative or advisory nature

The above procedures, although organised and conducted in a similar way, are governed by different laws and regulatory frameworks. However, the functional and non-functional characteristics of a system capable to support General Elections is a superset of the respective characteristics of a system supporting other types of voting procedures, even though some activities may be different.

Because of this, the voting model constructed during this first round of the user requirement elicitation process has focussed on general elections. Voting models for internal election procedures, decision-making and polls are presented by simply highlighting their differences from the general elections voting model. This approach leads to both a concise voting model and a structured set of requirements suitable for facilitating the analysis and design of the system to be developed.

2.1 General Elections

2.1.1 Business Use Case Model

General elections – at least in the context of the European Union – are synonymous with democracy. Despite the variety of electoral systems3, legislative frameworks and infrastructure, elections in all member states share the following common principles:

3 These can generally be categorised as plurality-majority, semi-proportional and proportional systems [i]

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 17 of 188


Generality: All citizens, unless otherwise stated by adjudication, above a certain age have the right4 to participate in an election process. This means that:

1. The ability to participate in an election process (eligibility) must be founded on the law and should be controllable according to the law.

2. Voting possibilities and technologies should be accessible by every voter.

3. Due to the lack of necessary infrastructure and to the digital divide, e-voting should be, for the time being, considered only as an alternative way of exercising one’s voting rights.

4. The democratic principle (i.e. every eligible voter should be allowed in the election process) results in the necessity for publicly available infrastructure (e.g. public internet kiosks, internet voting through government offices, etc.) through which citizens can exercise their voting rights.

Freedom: The principle of free elections requires that the entire election process is conducted without any violence, coercion, pressure, manipulative interference or other influences, exercised either by the state or by one or more individuals. The voting process is thus organised in a way that ensures:

Uncoercibility: the voter must be able to vote personally and without any extraneous influence

Freedom of voters’ decision: the capability to cast a consciously invalid vote should be provided and guaranteed.

Equality: The principle of equality applies to:

1. political parties, candidates etc., participating in the elections. Specifically:

Equal Accessibility: the structure and appearance of ballots should not favor or discriminate against any of the participating parties.

Integrity: the decision of the voter, as expressed through the online ballot, is transmitted and counted without any kind of modifications or/and interferences. A valid cast vote must not be altered or removed in the course of the voting process.

Transparency: All parties should have equal opportunities to the elements of the voting procedure, in order to verify its integrity and proper organisation.

2. the voting rights of each voter. Specifically:

Eligibility: Only eligible voters can cast a vote

Non - reusability: Each eligible voter can only vote once

Non - changeability/ Integrity: No one can duplicate his/her or someone else’s vote or modify someone else’ s vote

Verifiability: The voter, or his representatives, should have the possibility to verify that his vote has been calculated in the final tally

Accessibility: Voters should be provided with indiscriminating access to the voting infrastructure

Secrecy: Nobody should be able to link a ballot to a voter. This implies that:

4 In some EU member states: the obligation

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 18 of 188


Registration, authentication and voting must be clearly and evidently separated.

Votes must be validated separately and independently from voter authentication

No voter should be able to prove that he/she voted in a particular way

Directness: Electors directly select their representatives. Therefore:

No intermediaries chime in the voting decision (i.e. no person can be authorised to vote for another person)

Each and every ballot must be directly recorded and counted.

These attributes pertain to the business use cases (Figure 1) – and their implementations – and comprise the business use case model for the general elections voting process. It can be noticed that the model does not support mechanisms for specifying the eligibility criteria for voters. It has been assumed that information about the entire population – whether someone is eligible to vote or not – is available.

The identified business use cases are depicted in Figure 8. A description for each one is provided in the following sections.

2.1.1.1 Adjust Election Districts

This process is rather rare and is only performed by the state, usually after a census, in order to improve the representation of the constituency. The election districts are well defined early before and during the election.

2.1.1.2 Update list of voters

This process is typically performed for identifying the eligible voters and thus facilitating either the provision of authentication means or the construction of the ‘voter lists’ for the election centres (electors vote using some form of identification e.g. identity cards or passports). In general, all persons above a certain age have the right/obligation to participate in the election process. In some member states, where voters explicitly request from the state to be provided with authentication means, this process is not performed at all and the constituency consists of the persons who have requested – and granted – authentication means valid for the specific election.

2.1.1.3 Provide Authentication Means

This process is performed for providing voters with authentication means and thus ensure that only eligible ones can vote. The responsibility for the provision of authentication means can either lie with the state or with the voter. The process terminates after all voters have acquired the required means of authentication in a non-discriminative way. In some member states the specific process is not applicable, since voters can use their identity card or passport to vote.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 19 of 188


Election Centre Appointed Personnel

Tally Votes

Consolidate Votes

Interested Third Party

Authorised Election Centre Superv isor

Verif y Result Integrity

Authenticate Voter

Cast Vote

Voter

Update List of Voters

Adjust Election Districts

Create Ballots

Set Up Election Centers

Election Organiser

Voter Prov ide Authentication Means

Figure 8. Business Use-Cases of the Voting Procedure for General Elections

2.1.1.4 Set-up Election Centres

This process is performed after elections districts have been finalised and prior to the voting event. The goal is to provide the necessary infrastructure – in terms of people and equipment – to allow for smoothly carrying out the election. During this process the personnel along with the authorised individuals for supervising the process at each election centre are defined.

2.1.1.5 Create Ballots

This process starts after election districts have been defined. Each party5 provides a discrete ballot format and a list of representatives per election district. The state creates the ballots and distributes them to representative parties, election centres’ personnel and all authorities responsible for the election process.

5 The reference is for parties legitimate to participate in the current election

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 20 of 188


2.1.1.6 Authenticate Voter

This process is performed in order to ensure that the voter is eligible to vote but also that he/she is the one the he/she claims to be.

2.1.1.7 Cast Vote

This process is performed after the voter has been authenticated. The authorised individual, in the election centre, records the fact that he has voted. An immediate result of the equality principle is that the voter is not allowed to vote again for the same election.

2.1.1.8 Tally Votes

This process aims to validate votes and determine the total number of votes each participating party has received, along with white or invalid votes. The process takes place after the end of the election in every election centre and finishes when all votes have been directly validated and tallied.

2.1.1.9 Consolidate Votes

This process aims to consolidate tallied votes, along with the list of persons that have voted in the election centre, from election centres to a central repository of the election authorities. The process starts independently at each election centre after the tallying has finished.

2.1.1.10 Verify Result Integrity

This process is triggered if a voter - or any other interested party - requests to verify that one or more of the election procedures described above has been conducted properly. In all cases the state, using the records kept during the corresponding procedure, should demonstrate that fact.

2.1.2 Business Object Model

This Section provides descriptions on how the business use cases are realised and identifies the involved business workers and business entities.


The business workers and entities involved in this process – along with their relationships – are depicted in the following figure:

Census Result

Election Organiser

Election District List

Figure 9. Business Workers and Entities for the Adjust Election Districts Business Use Case

The following steps are taken to realise this business use case:

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 21 of 188


1. The election organisers acquire the latest official census result.

2. According to the distribution of the population they amend the election districts to better reflect the constituency.

3. The election districts are notified to the appropriate authorities

2.1.2.2 Update list of voters

The business workers and entities involved in this process – along with their relationships – are depicted in the following figure:

Census Result Voter List

Election Organiser

Figure 10. Business Actors, Workers and Entities for the Update List of Voters Business Use Case

The following steps are taken to realize the use case:

1. The election organisers acquire the latest official census result.

2. Persons who – at the time of the election – will be over a certain age are included in the voter list. The only exception is for people that have been convicted to attainder or condemned, by judicial judgement, to vote exclusion.


This process, when applicable, provides the voter with authentication means for the election.

Authentication Mean

Election Organiser

Voter

Figure 11. Business Actors, Workers and Entities for the Provide Authentication Means Business Use Case

The flow of events of the process is as follows:

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 22 of 188


1. The election organisers create specific authentication means for every voter.

2. The authentication means are either sent by the state to the voters, or the voters have to request and receive the means from the appropriate state authority.

2.1.2.4 Set-up Election Centres

This business use case is under state control and leads to the creation of election centres that ensure that everyone has access to the voting infrastructure as dictated by the equality principle.

Election Center Authorised Election Centre Supervisor


Election Organiser

Figure 12. Business Workers and Entities for the Set up of Election Centres Business Use Case

The flow of events for this business use case is as follows:

1. The election organisers define some public places as election centres.

2. They also appoint one person, able to guarantee the integrity of the election centre operations, as the supervisor of each election centre

3. A number of other persons are appointed to support the election centre and the tallying process.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 23 of 188



This business use case is realised through the workers and entities depicted in Figure 13.

Election District Ballot


Ballot Format Candidate List

Election Organiser

Party Representative

Figure 13. Business Actors, Workers and Entities for the Create Ballots Business Use Case

The steps taken to realize the use case are the following:

1. Each party representative provides the election organisers with the list of candidates per election district and the party logo that will be used on the ballot.

2. The election organisers create the ballots for each election district and distributes them to election centres’ personnel and to all authorities responsible for the election process.


This business use case is realised through the entities of Figure 14. Its course of events is as follows:

1. The voter visits the election centre he belongs to.

2. The centre personnel authenticates him using the provided authentication means.


Authentication Mean

Voter

Figure 14. Business Actors, Workers and Entities for the Authenticate Voter Business Use Case

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 24 of 188


2.1.2.7 Cast Vote

This business use case is realised at the election centre by the entities of Figure 15. Its course of events is as follows:


Vote

Participation Record

Voter Election District Ballot


Authorised Election Centre Supervisor

Figure 15. Business Actors, Workers and Entities for the Cast Vote Business Use Case

1. The authorised election centre supervisor provides the voter with all ballots for the corresponding election district (a white ballot included6). She/he ensures that the sequence of the ballots at hand is different for each voter in order to avoid favouring a specific party. Party representatives supervise this step to verify the change of ballot sequence and that all ballots are provided to the voter.

2. The voter recedes in a private area of the election centre and chooses one of the ballots as his vote.

3. He/She casts his vote in the presence of the election personnel in such a way that its contents are concealed

4. The election centre personnel records the fact in the participation record.

2.1.2.8 Tally Votes

This business use case is also realised at the election centre by the entities of Figure 16 and with the following list of events (all steps are supervised by party representatives):

1. The election centre supervisor, with the help of the election centre personnel, opens and validates each and every vote.

2. Valid votes (including white ones) are counted and added to the results of the election centre

3. After all votes have been tallied their number is compared, as a verification measure, to the number of voters who have cast a vote at the election centre.

4. The result is transferred to the election organiser’s appointed authority and is added to 6 In states where the law foresees it

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 25 of 188


the election poll

Vote


Authorised Election Centre Supervisor


Election Centre Result

Election ResultElection Organiser

Figure 16. Business Workers and Entities for the Tally Votes Business Use Case



Vote

Election Organiser

Participation RecordAuthorised Election Centre Supervisor

Figure 17. Business Workers and Entities for the Consolidate Votes Business Use Case

This process is realised by the election centre supervisor with the help of one or more election organisers. The election centre supervisor carries the votes and the participation record from the election centre to a central repository. The votes are kept there for as long as the

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 26 of 188


corresponding states’ law designates.



1. A voter, party representative or any other interested third party makes a request to verify that the election procedure(s) described above has been conducted properly

2. The election organisers retrieve the record of the procedure in question and demonstrate the steps followed during the procedure and their outcome, possibly using the participation record(s) and the votes of one or more election districts.

VoterInterested Third Party

Participation Record Vote

Election Organiser


Figure 18. Business Actors, Workers and Entities for the Verify Result Integrity Business Use Case

2.2 Internal Elections


In this Section the differences between business use cases realising general elections and those realising internal elections are highlighted. In the following, it is assumed that the global principles of Section 2.1.1 (Business Use Case Model for General Elections) apply, unless otherwise stated. The deviations– if any – are depicted in the Use Case description. In general the business use cases for internal elections are the same in name and number with the ones for general elections. Along these lines the election organisers should treat voters personal data in a manner compliant with data protection legislative and regulative framework. Indicative cases are eligibility criteria selection and authentication means provision. The reader is thus referred to Figure 8 for a complete list of business use cases. A description for each business use case that is differentiated from the respective one for General Elections follows:

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 27 of 188



The Election Districts population may reduce to a single Election District. Generally, a census is neither obligatory, nor necessary.

2.2.1.2 Determine Voters

This use case is equivalent to the general elections “Update list of voters” use case. The different name denotes the fact that in the case of internal elections, eligibility criteria can be defined at will by the organisation.


During the election process voters may employ the authentication means already in use during their other activities in the organisation.


The consolidation level depends on the extent of the Internal Elections process. For small constituencies, the consolidation process may reduce to the tallying process (i.e. Section 2.1.2.8); thus this use case may be redundant.


This Section identifies the business workers and business entities participating in the internal elections voting process model, and provides descriptions on how the business use cases are realised (only for the business use cases that are differentiated from the General Elections ones). It is stressed that since organisations and not the state conduct internal elections, all roles specified in the general elections object model correspond to members of the organisation.


This business use case is realised in the following way:

1. Members of the organisation responsible for conducting the internal election acquire the personnel list from the appropriate departments (if applicable).

2. According to the distribution of members in various departments several election “districts” may be created to better reflect the constituency.


The following steps are taken to realise the use case:

1. Members of the organisation responsible for conducting the internal election acquire the personnel list from the appropriate departments (if applicable).

2. Persons who – at the time of the election – will satisfy certain eligibility criteria, set by the organisation that conducts the election process, are added to the voter list.


In general there is no difference with the general election case. In case of small constituencies, though, the consolidation process may reduce to the tallying process (see Section 2.1.2.8).

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 28 of 188


2.3 Decision-Making


The current Section highlights the differences, in terms of business use cases, between the decision making process and general elections. It is assumed that the global principles of Section 2.1.1 (Business Use Case Model for General Elections) apply, unless otherwise stated. Throughout a decision-making process the election organisers should treat voters personal data in a manner compliant with data protection legislative and regulative framework. Indicative cases are eligibility criteria selection and authentication means provision.




This use case is equivalent to the general elections “Update list of voters” use case. The different name denotes the fact that in the case of decision-making, eligibility criteria may vary.


During the election process voters may employ authentication means (if applicable) that they already possess.


The ballot is constructed solely by the election authority and the voter is presented with predefined multiple choices, concerning the “decision-making subject”.

2.3.1.5 Tally Votes

Lack of transparent public control may be acceptable.


The consolidation level depends on the extent of the Decision-Making process. For small constituencies, the consolidation process may reduce to the tallying process (i.e. Section 2.3.1.5), thus this Use Case may be redundant. Lack of transparent public control may be acceptable.




This Section identifies the business workers and business entities participating in the decision making voting process model, and provides descriptions on how the business use cases are realised (only for the business use cases that are different from the General Elections ones).

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 29 of 188



This business use case is realised in a way similar to that described for general elections (Section 2.1.1.1). However, variations in the way election districts are determined may exist.


As part of the decision-making procedure, this business use case is realised as follows:

1. The election organisers may acquire the latest official census result.

2. Persons who at the time of the election satisfy certain eligibility criteria are included in the voter list.


This business use case is realised as in general elections (Section 2.1.2.5) but without the party representatives, who in this case do not exist. The steps taken for realising the use case are the following:

1. The state provides the list of “decision choices” per election district and the appropriate ballot format.

2. The election organisers generate the ballots for each district and distribute them to the election centres personnel and all authorities responsible for the election.


In case of small constituencies, the consolidation process may reduce to the tallying process (Section 2.1.2.8).

2.4 Polls


Following the same methodology as in Internal Elections and Decision Making, this Section presents the business use cases for polls that are different from the respective use cases for general elections. Throughout a poll the process organisers should treat voters personal data in a manner compliant with data protection legislative and regulative framework




This use case is equivalent to the general elections “Update list of voters” use case. The different name denotes the fact that in the case of polls, eligibility criteria may vary or it may not be obligatory to compile lists, if everyone is allowed to vote.


Provision of authentication means may not be necessary.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 30 of 188



The ballot is constructed solely by the election authority and voters are presented with predefined multiple choices or/and with alternative ways of opinion expression (e.g. such as free text, notes etc), about the “poll subject”.


The realisation or not of this use case depends on the characteristics of the poll; such characteristics are for example whether the voter should satisfy some eligibility criteria or not, whether someone can vote more than once etc.

2.4.1.6 Cast Vote

Voters may be allowed to vote more than once.

2.4.1.7 Tally Votes



The consolidation level depends on the extent of the Poll process. For small constituencies, the consolidation process may reduce to the tallying process (i.e. Section 2.4.1.7), thus this Use Case may be redundant. Lack of transparent public control may be acceptable.




This Section identifies the business workers and business entities participating in Polls and provides descriptions on how the business use cases are realised (only for the business use cases that are different from the General Elections ones).


A poll may be conducted irrespectively of election districts (making this use case non applicable) or variations in the way election districts are determined may exist.


In case that voter lists must be compiled (implying that not everyone is allowed to participate in the poll), the following steps are taken for realising the use case:

1. The poll organisers may acquire the latest official census result.

2. Persons who at the time of the election satisfy certain eligibility criteria are included in the voter list.


In the majority of polls, provision of authentication means is not necessary.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 31 of 188



This business use case is realised as in general elections (Section 2.1.2.5) but without the party representatives, who in this case do not exist. The steps taken for realising the use case are the following:

1. The state provides the “poll subject” per election district and the ballot format

2. The poll organisers generate the ballots for each district and distribute them to election centres personnel and all authorities responsible for the poll.


In most cases this use case will be non-applicable, since no voter authentication will be required (see Section 2.4.1.5).

2.4.2.6 Cast Vote

The course of events for this use case is as follows:

1. The authorised election centre personnel provides the voter with the ballot for the corresponding election district. No party representatives are necessary to supervise this step.

2. The voter recedes in a private area of the election centre and chooses one of the choices on the ballot as his vote. The vote is not necessary to be cast in such a way that its contents are concealed

3. The election centre personnel may record the fact in the participation record, but the voter may not be restricted to vote again.

2.4.2.7 Tally Votes

This use case is also realised at the election centre as follows:

1. No party representatives are necessary to be present for the tallying process.

2. Comparison between number of tallied votes and number of voters cannot be made, since a voter can vote more than once.

3. The result may be transferred to the authority appointed by the state and added to the poll result.


It may be unnecessary for small constituencies, as this use case can reduce to the tallying process (i.e. Section 2.4.2.7)


Since only limited trust can be placed on the accuracy of the poll, this use case is of minor importance.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 32 of 188


3 E - Vote Requirements Specification

The current Chapter deploys the e-VOTE requirements specification in the format described in Section 1.2. The specification consists of a list of system functions that have been derived from the business use cases of the voting model (presented in Chapter 2). Special focus has been given to the automation, to the maximum degree possible, of the voting process.

3.1 General Elections

This section describes the voting requirements in the context of the general elections process. Throughout the specification special care has been taken to satisfy the global system requirements, namely:

1. The system’s capability to preserve the fundamental principles pertaining to democratic elections (see Section 2.1.1),

2. through transparent and publicly known methods and techniques, as is the case with “conventional” elections

An immediate consequence of the first requirement is that voters should be aware of all parameters affecting the final result. It is thus necessary to prohibit changes to election districts, candidate parties etc. after a specific point in time. However, under certain circumstances, the system should allow the modification of specific system parameters, e.g. correction of a spelling mistake in a ballot or in the name of an election district, by authorised actors. After the election process has been concluded, no modifications should be allowed.

The system operation is thus organised in accordance with the three distinct stages that are illustrated in the state diagram of Figure 19.

Election in Progress

Election Setup

Election Concluded

Start Election

End Election

Figure 19. State Diagram of the e-VOTE System

The system initiates at state 1, i.e. “Election Set-up” and makes a transition to state 2, i.e. “Election in Progress”. The transition is enabled through a dedicated system use case. Having

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 33 of 188


reached the election ‘end-time’, as this was specified by some authorised actor, the system automatically transits to state 3, i.e. “Election Concluded”.

3.1.1 System Use Cases

The use cases that will be supported by the system to be developed are described in the current section. Although the majority of the system use cases correspond to the business use cases, additional ones, not directly related to the voting model, have been identified. The complete set of system use cases is depicted in Figure 20 and is then described in expanded format (see Section 1.2 -- with the note that the “Use Case Name” coincides with the section heading, while the narrative description of the use case follows the section heading).

Authenticate ActorManage Election Units

Authenticate Key Actors

Manage CandidatesAuthenticate Voter

Prov ide Party Inf o

Cast Vote

Tally Votes

Manage Election Districts

<<include>>

Manage Voters

Prov ide Authentication Means

Authenticate Organiser

<<include>>

Manage Parties<<extend>>

Initiate Election Procedure

Prov ide Election ParametersModif y Sy stem State

Verif y Result Integrity

Elections Organiser

Party Representativ e

Voter

Prev iew Ballots

Figure 20. System Use Cases for General Elections

Note that the actors depicted in the previous figure are the following7:

7 For a definition of these terms, along with those of the business actors and entities used in the conceptual model, the reader is referred to the e-Vote glossary.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 34 of 188


Voters Election Organisers Party Representatives

This is in accordance with the methodology description in paragraph 1.2, where it has been stated that the business actors of the business object model either become actors of the information system or their responsibilities are taken over by the system itself.

Any one of the aforementioned e-VOTE actors in order to gain access to the system must be authenticated through the Authenticate Actor (3.1.1.1) use case.

An additional class of actors (not clearly indicated in the previous Figure) is the “Key Actors” who are groups (more than a single person) of Election Organisers and/or Party Representatives and have advanced privileges on the system through the Authenticate KeyActors (3.1.1.2) use case.

3.1.1.1 Authenticate Actor

This use case can be seen as a prerequisite prior to any interaction of an actor with the system.

Purpose Provide access to the system functions in accordance with the authorisation level (privileges) of the actor

Related Business Use Case(s) 2.1.1.6

Actors All

Type Primary

Preconditions None

Two logical entities (or sets of logical entities) interact in this scenario: the Actor and the e-VOTE system (which is actually a set of logical entities).

a) User RequirementsAttribute

CodeAttribute Category

Description

Voters Key Actors

NF3.1.1.1.1 Security The voters should be allowed a limited number of unsuccessful authentication attempts (e.g. 5). In case that the limit is exceeded, their authentication means should be invalidated; in order to have the chance to re-participate in the voting process, a new authentication means should be issued and assigned to the voter.

Users should be authenticated only from specific terminals, within a predefined time window, using a combination of advanced authentication means, such as biometrics or/and smartcards.

NF3.1.1.1.2 Security During the authentication process, the voters should not have direct access to the e-VOTE host system.

Key Actors should not be privileged users at system level.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 35 of 188

bts, 03/01/-1,

Σελίδα: 35Κώστα, εάν έχει γραφτεί από τη συνάντηση, απλά αγνόησέ το


Attribute Code

Attribute Category

Description

Voters Key Actors

NF3.1.1.1.3 Security The authentication process should lead to limited and controlled access to the e-VOTE system under the lower privileges possible, or no access at all.

Timeout between unsuccessful attempts should increase after every failure. A maximum number of 3 attempts should be allowed (after that, special authorization should be given by authorized election officers in order to unlock the terminal).

NF3.1.1.1.4 Security Successful authentication should grant access to the e-VOTE system solely through the user interface.

The system should be able to incorporate alternative authentication methods and means of equal strength as technology in the field advances.

NF3.1.1.1.5 Security The system should provide a hook for an open API to easily incorporate new authentication means.

Common requirements for all types of users

NF3.1.1.1.6 Usability Voters should be able to participate in the voting process with minimum knowledge of the implementation of the e-Vote system.

NF3.1.1.1.7 Performance The authentication process should be completed within a reasonable time window after information submission (e.g. no more than 10 seconds)

NF3.1.1.1.8 Usability The authentication interface should be user-friendly even for non-computer literate persons.

NF3.1.1.1.9 Usability Messages to users during the authentication process should be clear and unambiguous.

NF3.1.1.1.10 Reliability The Mean Time Between Failures (MTBF) must be set to the minimum during the authentication process

NF3.1.1.1.11 Security The authentication data should be transmitted in a secure and reliable way even under Public Networks.

NF3.1.1.1.12 Security Widely-adopted EU security directives, such as the guideline for digital signatures, should be employed for user authentication.

NF3.1.1.1.13 Security The authentication process must be treated as an atomic

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 36 of 188


Attribute Code

Attribute Category

Description

Voters Key Actors

transaction.

NF3.1.1.1.14 Security Abnormal interaction or unexpected input data to the authentication process should be treated properly.

NF3.1.1.1.15 Security No application or system-specific information should be revealed during the authentication process, in case of abnormal application termination or during infrastructure failure.

NF3.1.1.1.16 Security All authentication attempts, successful or not, should be logged.

b) Functional RequirementsRef. # Function Function

CategoryNotes Required

Function Attribute(s)

Attribute Details and Constraints

Implemented in Prototype

1

SYSTEM FUNCTIONS

R3.1.1.1.1 Expose a well defined Authentication API

Hidden Security The system should be able to incorporate alternative authentica-tion methods and means as technology advances.

R3.1.1.1.2 Provide an Authentication User Interface with relevant options

Evident Ease of use The authentication interface should be unambiguous and easy to use, even for a non computer-literate voter

R3.1.1.1.2.1 Provide actor credentials8

Evident

R3.1.1.1.3 Validate actor credentials

Hidden Security In case of voter authen-tication, an underlying trust-enhancing infrastructure (i.e. TTP) should be in place, in order to successfully validate actor credentials

R3.1.1.1.3.1 Set timeout for actor credentials verification

Hidden A reasonable timeout should be defined, after which the verification results delivery process is terminated. Possible reasons include unavailability of e-VOTE authentication mechanisms, infrastructure failure, etc.

User Friendliness

The re-authentication process should be tried for a predefined number of times (i.e. defined in the Use Case 3.1.1.6), before the authentication is considered invalid and the actor disconnects from the e-VOTE system.

R3.1.1.1.4 Notify actor for actor

Evident The system notifies the actor on actor authentica-

8 In Prototype 1, the authentication method will be password-based; more advanced means of authentication will be employed in the next phases

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 37 of 188


Ref. # Function Function Category

Notes Required Function

Attribute(s)



1

authentication results

tion results, and, if success-ful, presents available system options according to actor privileges. For election organisers the options correspond to system Use Cases 3.1.1.6, 3.1.1.7, 3.1.1.8, 3.1.1.10, 3.1.1.11, 3.1.1.14 and 3.1.1.15, while for voters to system use case 3.1.1.13.

SYSTEM ATTRIBUTES

R3.1.1.1.5 Log all authentication attempts, suc-cessful or not.

Hidden All operations related to authentication attempts should be logged

Security,

Audit

The system should log all actions, as indicated in Section 3.1.2 (Logging)

R3.1.1.1.6 Invalidate actor credentials.

Hidden The system should invali-date actor credentials after a predefined number of unsuccessful authentication attempts (defined in the Use Case 3.1.1.6).

In order for an actor to have the chance to re-participate in the voting process, new authentication means should be issued and assigned to the voter.

R3.1.1.1.7 Assigned privileges in actors are valid only at the e-VOTE application level9

Hidden Security The e-VOTE system should grant to authenticated actors only application-wide privileges; system privileges (i.e. at an operating system level) should be disallowed by default for all actors

c) Typical Course of Events:Actor Action System Response

1. Actor asks authorisation to use the system

2. The system asks for user authentication means

3. The user provides the means requested

4. The system authenticates the user and presents available system options according to actor privileges. For election organisers the options correspond to system use cases 3.1.1.4 - 3.1.1.12 and 3.1.1.14 - 3.1.1.15, while for voters to system use cases 3.1.1.12 and 3.1.1.13.

9 This requirement implies the existence of various actor groups with different and well-defined privileges. For Prototype 1, no distinctions between Key Actors will be defined. On the other hand, voters have access to the system only through the authentication and the vote casting interfaces.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 38 of 188


d) Alternative Course of Events:

Step 4: The system cannot authenticate the actor. The authentication attempt is logged and the system provides the actor with the option to re-attempt authentication. After the predefined number of unsuccessful attempts the system invalidates the user’s authentication means. In order to regain valid authentication means actors should perform use case 3.1.1.8 (ProvideAuthentication Means).

3.1.1.2 Authenticate Key Actors10

This use case extends the previous use case in an attempt to increase security. It is realised by requiring concurrent authentication, through the Authenticate Actor (3.1.1.1), of more than one actor (election organisers and/or party representatives) in order for one of them to gain access to the system.

In addition to the Required Attributes for System Use Case “Authenticate Actor (3.1.1.1)” the following ones must apply:

a) User RequirementsAttribute Code Attribute

CategoryDescription

NF 3.1.1.2.1 Security, Reliability

The authentication process must be completed within a certain time window in which all actors should be authenticated. The transaction must be treated as atomic (all-or-none authentication).






1

SYSTEM FUNCTIONS

R3.1.1.2.1 Provide a Key Actor Authentication Interface with relevant options

Evident

R3.1.1.2.2 Request authentication of multiple Key Actors

Evident Security,

Audit

In order for the Key Actors to perform certain actions (e.g. alter election parameters during the election phase), a successful chain of authentications should take place11.

R3.1.1.2.3 Receive Key Actors’ credentials

Evident

10 In Prototype 1, no distinctions between key actors will be made; thus, this use case will not be implemented in Prototype 1

11 This requirement implies the existence of various actor groups with different and well-defined privileges. In Prototype 1, no distinctions between Key Actors will be made.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 39 of 188




Attribute(s)



1

R3.1.1.2.4 Verify Key Actors’ credentials

Evident Security The system should verify the authorisation level requested by the Key Actors

R3.1.1.2.4.1 Provide appropriate level of clearance to authenticated Key Actors12

Hidden Security,

Audit

The Key Actors’ credentials should be sufficient for the requested action to take place13

SYSTEM ATTRIBUTES

R3.1.1.2.5 Authenticate Key Actors in an All-Or-Nothing manner

Hidden The transaction must be treated as atomic (all-or-none authentication).

Security, Reliability

The authentication process must be completed within a certain time window in which all actors should be authenticated.

R3.1.1.2.6 Logging Hidden All operations related to key actor authentication should be logged

Security,

Audit


c) Typical Course of Events:Actor Action System Response

1. Actor asks for authorisation to use the system

2. The system asks for user authentication means

3. The user provides the means requested

4. The system checks the required number of necessary users and their respective privileges. The system authenticates the user and, if necessary, prompts the remaining users to authenticate themselves in order to allow access to the system

5. If necessary all other actors perform the authentication procedure

6. The system provides access to system special functions, according to the user request and the provided level of clearance.


Step 4: The system cannot authenticate one of the users. The authentication attempt is logged and the system provides the ability to re-attempt authentication. After the predefined number of unsuccessful attempts the system invalidates the user’s authentication means (as described in use case 3.1.1.1 - Authenticate Actor) and the authentication process fails for the entire group.

12 This requirement implies the existence of various Key Actor groups with different and well-defined privileges. In Prototype 1, no distinctions between Key Actors will be made.

13 This requirement implies the existence of various actor groups with different and well-defined privileges. In Prototype 1, no distinctions between Key Actors will be made.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 40 of 188


3.1.1.3 Modify System State14

This use case is used to perform the system transition from one state to another. As already described, the system states are the following:

1. Election Set-up: During this stage use cases 3.1.1.4 to 3.1.1.12 can be performed by actors who have successfully completed the authentication procedure.

2. Election In progress: During this stage the election procedure is in progress, i.e. use cases 3.1.1.12 and 3.1.1.13 are performed. In exceptional cases, some of the election set-up use cases can also be performed after properly authorised actors have been authenticated using the “Authenticate Key Actors” use case.

3. Election Concluded: In this stage only use cases 3.1.1.14 and 3.1.1.15 can be performed.

Purpose Modify System State

Related Business Use Case(s) --

Actors Election organisers, Party representatives (optionally)

Type Primary

Preconditions 1. The actor is officially authorised to change the current state of the system

2. The actor has successfully completed the “authenticate key actors" procedure (use case 3.1.1.2)

3. The transition from state 2 to state 3 will be automatic and will be based on the election end-time specified during the election set-up

a) User Requirements

Attribute Code Attribute Category Description

NF3.1.1.3.1 Usability The user interface should be user-friendly even for non-computer literate persons, unambiguous and consistent with a minimum of computer platform requirements

NF3.1.1.3.2 Reliability Only the key actors should be logged on the system for this use case to take place. All key actors should confirm the state change

NF3.1.1.3.3 Performance All system state changes should be managed in a reasonable period of time, proportional to the extent of the change performed

NF3.1.1.3.4 Reliability Automated and manual consistency checks should be performed before the system state modification takes place and appropriate messages indicating possible inconsistencies must appear.

14 This use case will not be implemented in Prototype 1.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 41 of 188


NF3.1.1.3.5 Usability Comprehensive reporting capabilities should be in place in order to facilitate checks for election data discrepancies.

NF3.1.1.3.6 Security The election parameters should be stored in a secure way. The updated election parameters should be distributed to all interested entities and parties for clarity.






1

SYSTEM FUNCTIONS

R3.1.1.3.1 Display Current State

Evident

R3.1.1.3.2 Provide “Transition to state YYY” option

Evident YYY is any state valid for transition from the one the system is currently in

R3.1.1.3.3 Display confirma-tion dialog

Evident Security This dialog (along with extra information about confirmations performed so far) will be displayed to the rest of key authors participating in the use case

R3.1.1.3.3.1 Verify system is in position to change state

Hidden Consistency In case there are pending transactions for the current state the action can not be completed

R3.1.1.3.3.2 Notify actor for inability to perform state change

Evident See previous function

R3.1.1.3.4 Perform state change

Hidden The system should internally perform all operations necessary to make the transition to the desired state

R3.1.1.3.4.1 Notify Actor for successful state change

Evident

SYSTEM ATTRIBUTES

R3.1.1.3.5 Logging Hidden All operations related to system state modification should be logged

Security, Audit The system should log all actions, as indicated in Section 3.1.2 (Logging)

c) Typical Course of EventsActor Action System Response

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 42 of 188


1. An election organiser selects to make a system state transition

2. For transition from state 1 to 2 the system checks that there is no pending information (e.g. all voters have been assigned to election districts)

The system asks the actor to confirm that all procedures have been properly concluded and the system is ready to change state

3. The user confirms the state transition

4. The system performs the transition

3.1.1.4 Manage Election Districts15

This is expected to be a rarely used use case since election districts usually remain unchanged. It optionally uses system use case “Manage Election Units, 3.1.1.5”.

Purpose Create, view and modify different sets of election districts for one or more election procedures.


Actors Election organiser

Type Secondary

Preconditions 1. The actor is officially authorised to perform changes in one or more election districts.

2. The actor has successfully completed the authentication procedure (use case 3.1.1.1)

3. The system is at the “election set-up” stage.



NF3.1.1.4.1 Usability The user interface should be user-friendly even for non-computer literate persons, unambiguous and consistent with a minimum of computer platform requirements

NF3.1.1.4.2 Performance The portion of time necessary for managing a district should be less than the time spent for data input.

NF3.1.1.4.3 Usability The system should be able to import an electronic list of districts.

NF3.1.1.4.4 Security Abnormal interaction or unexpected input data to the district management process should be treated properly.

b) Functional Requirements

15 This use case will not be implemented in Prototype 1

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 43 of 188




Attribute(s)



1

SYSTEM FUNCTIONS

R3.1.1.4.1 Provide actor with a relevant well-defined interface

Evident Interface metaphor

The system must provide actors with a meaningful list of choices

R3.1.1.4.1.1 Manage actor’s choice accordingly

Evident Actor’s choice must be treated accordingly

R3.1.1.4.2 Check system’s state

Hidden Consistency The system should be in the Election Set-up phase in order to perform this operation; in order to perform this operation in the Election in Progress phase, the Authenticate Key Actors use case must be activated.

R3.1.1.4.3 Permit district data editing only during the “election set-up” phase

Evident

R3.1.1.4.4 Receive Actors input

Evident

R3.1.1.4.4.1 Verify input data

Hidden Security Input provided by actors must be relevant and meaningful to the system

SYSTEM ATTRIBUTES

R3.1.1.4.5 Logging Hidden All operations related to election district management should be logged

Security,

Audit



1. A key actor (election organiser) selects to manage election districts

2. The system provides the actor with the set of available election districts and the ability to select some for further processing or to create a new election district.

3. The actor asks the system to create an election district. Optionally the user

4. The system requests the name of the election district and the state area that it

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 44 of 188


may decide to:

a. Delete an election district (DP-3a)

b. Modify an election district (DP-3b)

includes.

5. The actor enters required data 6. The system informs the user about the success or failure of the operation


DP-3a: Delete an election district

Typical Course of EventsActor Action System Response

3a. The actor asks the system to delete an election district

4. The system checks to see if there are any voters who have been assigned to that particular election district. In that case it warns the user once more and informs him that he is able to re-assign voters to election districts with use case 3.1.1.7.

5. User confirms deletion 6. The system attempts to perform the deletion and informs the user about success or failure of the operation

DP-3b: Modify an election district


3b. The actor asks the system to update an election district

4. The system presents current information to the user to view and modify

5. User modifies data and asks the system to perform the update

6. The system informs the user about the success or failure of the operation

3.1.1.5 Manage Election Units16

An “election unit” is defined as the systems counterpart of an “election centre”. In the conceptual voting model the election centre is central to the election procedure since it is the fundamental tallying point. In the case of electronic voting in a controlled environment, where machines are provided by the state, all votes cast from a certain “electronic” election point should be able to be traced back to that point. It is thus expected that election districts will have at least one election unit.

Purpose Create, view and modify election units for one or more election procedures.




e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 45 of 188


Type Primary

Preconditions 1. The actor is officially authorised to modify election units of an election district


3. The election district for which the election units will be modified exists in the system.




Same as in Section 3.1.1.4, “Manage Election Districts”






1

SYSTEM FUNCTIONS


Evident The system must provide actors with a meaningful list of choices

Interface metaphor





R3.1.1.6.3 Permit election unit management only during the “election set-up” phase

Evident

R3.1.1.6.4 Receive Actor’s input

Evident

R3.1.1.6.5 Check that election unit corresponds to existing elec-tion district

Hidden Consistency All election units should belong to a specified election district.

R3.1.1.6.6 Verify input data


e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 46 of 188




Attribute(s)



1

SYSTEM ATTRIBUTES

R3.1.1.6.7 Logging Hidden All operations related to election district management should be logged

Security,

Audit



1. The election organiser selects to modify the election units of an election district

2. The system provides the actor with the set of available election units for that district and the ability to select some for further processing or to create a new one.

3. The remaining use case steps are exactly the same with the respective steps of system use case 3.1.1.4 (Manage Election Districts). The information provided for an election unit is its coded name and the state region in which is located.

3.1.1.6 Provide Election Parameters

This use case is employed for feeding the system with a set of parameters for the election procedure. Currently, with respect to the context of Prototype 1, the following parameters have been identified as necessary:

1. The type of the election (i.e. General elections, Internal elections, Decision-Making, Poll)

2. The date when elections will take place (including the election start and end time)

The following parameters have been identified as pertinent:

Parameter Comment Attribute Category

Alterable in voting phase

Output distribution list Sets of actors – groups which (may, must or should) have access to the election parameters17

Mandatory NO

Party or other The individuals which certify Mandatory NO

17 This requirement implies the existence of various actor groups with different and well-defined privileges. In the context of Prototype 1, there are no specific actor groups defined in the e-VOTE system

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 47 of 188




interested parties representatives20

and complement the process, e.g. they may contribute during the system state modification

Election start/end dates For the majority of the election events, start and end dates coincide

Mandatory NO

Election start/end times The election start time should be before the election end time, and should allow for a reasonable time window (i.e. several hours) in order to facilitate the voting process

Mandatory NO

Maximum number of parties18

The maximum number of parties to participate in the election / the voter can vote

Mandatory NO

Maximum number of voters

The maximum number of voters the system supports for the current election

Mandatory NO

Maximum number of voter choices (M)19

The voter choices should be at most M in order for the vote to be valid

Mandatory NO

Exact number of voter choices (E) 22

The voter choices should be exactly E in order for the vote to be valid

Mandatory NO

Ballot format It should include the party logo, ballot font size and colour, paragraph spacing, order of ballot elements, etc.

Mandatory NO

Invalid ballot requirements

According to the election rules, this requirement may be related (among others) to the requirements “Maximum number of voter choices” and “Exact number of voter choices”. It should be noted that the invalid ballot requirements should be customized according to the framework of the specific election

Mandatory NO

18 For the Prototype 1, the number of parties will be 1 (i.e. poll)19 For the Prototype 1, M will be 1 (i.e. poll)

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 48 of 188




Maximum number of unsuccessful/uncompleted vote attempts without re-authentication

Defines the number of uncompleted vote attempts i.e. when a voter initiates the vote casting but she/he never completes it; this requirement pertains to a voter who iteratively “almost-completes” the vote casting, therefore s/he consumes e-VOTE server resources

Mandatory NO

Table 1: Desired Election Parameters

Purpose Specify various parameters for the election that is going to take place

Related Business Use Case(s) --


Type Primary

Preconditions 1. The actor is officially authorised to set parameters for the election to the system





Same as in Section 3.1.1.4, “Manage Election Districts”

NF3.1.1.6.1 Security The election parameters should be stored in a secure way. The election parameters should be distributed to all interested entities and parties for transparency.






1

SYSTEM FUNCTIONS

R3.1.1.6.1 Check system phase and notify actor

Evident Modification of election parameters should be permitted only in the pre-election phase

Reliability, Trust enhancement

In order to set/modify election parameters, the system should be in the pre-election phase. In

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 49 of 188




Attribute(s)



1

case that the system is in the election phase and election parameters exist which have been defined as alterable at election phase, the Authenticate Key Actors procedure should be followed via function R3.1.1.6.6

R3.1.1.6.2 Set election parameters

Evident Validity The parameters should adhere to logical constraints (e.g. the date of the election should be in the future, the election start time should be before the election end time, etc).

R3.1.1.6.2.1 Define the alterable election parameters in the voting phase

Evident Audit,

Trust enhancement

The alterable election parameters in the voting phase should be defined according to the framework of the specific election.

R3.1.1.6.2.2 Check election parameter data

Hidden Security, Reliability

The system should deal successfully with malformed interaction and/or unexpected input.

R3.1.1.6.2.3 Notify actor about the validity of the election parameters

Evident Validity If logical inconsistencies exist (e.g. no candidates/choices for the election are in place), the relevant functions should be activated

R3.1.1.6.4 Store the election parameters in a secure way

Hidden Security,

Audit

In order to enhance the security and audit processes, the election parameters should be stored in a secure server, different than the machine running the e-VOTE system.

R3.1.1.6.5 Set voting protocol parameters

Evident Voting protocol parameters may include cryptographic algorithms, key lengths, etc. These parameters depend heavily on the particular voting protocol to be used.20

R3.1.1.6.6 Require Key Actor authentication in voting phase

Evident Security,

Reliability,

Trust enhancement

The Authenticate Key Actors procedure should be activated in case the actor wishes to set/modify election parameters in a system phase other than the pre-election one

20 In Prototype 1, the voting protocol parameters will be hard-coded in the system

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 50 of 188




Attribute(s)



1

SYSTEM ATTRIBUTES

R3.1.1.6.7 Logging Hidden All operations related to the setup of election parameters should be logged

Security,

Audit



1. An election organiser requires to access the parameters for the current election

2. The system provides the actor with the set of parameters and their values for the current election.

3. The actor asks to modify one of the parameter

4. The system, if the actor is authorised to perform this kind of action, asks for the parameters’ new value

5. The user enters the new value 6. The system updates the value

3.1.1.7 Manage Voters

This system use case is the counterpart of business use case 2.1.2.2 (Update list of voters). The fundamental assumption is that – almost – all citizens above a certain age are eligible to participate in the election procedure. It is thus practically impossible for election organisers to manually enter all voters into the system. The system should thus allow importing an electronic list of voters.

The fundamental assumption is that it is practically impossible for election organisers to manually enter all voters into the system. The system should thus allow importing an electronic list of voters.

Purpose Import, insert, view and modify voters for one or more election procedures.



Type Primary

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 51 of 188


Preconditions 1. The actor is officially authorised to perform changes in the eligible voters list

2. The actor has successfully completed the authentication procedure

3. The election district where voters will belong has been specified in the system

It should be noted that, in the context of Prototype 1, the precondition 3 stated above is not mandatory, since the election type (poll) does not dictate the existence of a district for a poll to take place (in other words, the existence of a unique, default district is implied).



NF3.1.1.7.1 Security The system should be able to import an electronic list of voters from different sources and formats. The voter lists should be complete, correct and up-to-date. The list of voters should not be transmitted to the system, but delivered through secure physical means.

NF3.1.1.7.2 Security The system should deal successfully with malformed interaction and/or unexpected input.

NF3.1.1.7.3 Security The system should log all actions, as indicated in Section 3.1.2 (Logging).

NF3.1.1.7.4 Security Voters should be assigned to correct districts and/or election units. No voter should be assigned to more than one district and/or election unit.






1

SYSTEM FUNCTIONS




R3.1.1.7.1.1 Manage actors choice accordingly


R3.1.1.7.2 Check system phase

Hidden Consistency,

Reliability, Trust enhancement

The system should be in the Election Set-up phase in order to perform this operation; in order to perform this operation in the Election in Progress phase, the Authenticate Key Actors use case must be

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 52 of 188




Attribute(s)



1

activated.

R3.1.1.7.2.1 Notify actor for the system phase

Evident Modification of voters list should be permitted only in the pre-election phase

Validity In order to set/modify voters list, the system should be in the pre-election phase. Other-wise, the Authenticate Key Actors procedure should be followed via the “Require Key Actor authentication in voting phase” (R3.1.1.7.3) function

R3.1.1.7.3 Require Key Actor authentication in voting phase

Evident Security,

Reliability,

Trust enhancement

The Authenticate Key Actors procedure should be activated if the actor wishes to set/modify voters in a system phase other than the pre-election one

R3.1.1.7.4 Import voters’ list

Evident Interoperability,

Security

The system should be able to import an electronic list of voters from different sources and formats. The voters lists should be complete, correct and up-to-date. The list of voters should not be transmitted to the system, but delivered through secure physical means21.

R3.1.1.7.4.1 Check voters list



R3.1.1.7.5 Add, edit, delete voters22

Evident The voters’ data stored by the system should not violate the Data Protection legislation.

R3.1.1.7.5.1 Check input data



R3.1.1.7.6 Present voter’s data according to selection criteria

Evident The system prompts for a set of criteria used to define a subset of eligible voters to display e.g. part of their surname

R3.1.1.7.7 Store voters’ list in a secure way

Hidden Security,

Audit

In order to enhance the security and audit processes, the voters’ list

21 For Prototype 1, a single format for voters list will be supported.22 For Prototype 1, the minimum information provided for the voter consists of surname and name. Optional

information include sex, father’s name, mother’s name, husband surname (for married women bearing their husband’s surname), date of birth, entity identification number (country specific), and electronic address; all these must be kept confidential

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 53 of 188




Attribute(s)



1

should be stored in a secure server other than the machine running the e-VOTE system.

SYSTEM ATTRIBUTES

R3.1.1.7.8 Logging Hidden All operations related to voter data management should be logged



1. The actor selects to manage voters

2. The system prompts for a set of criteria used to define a subset of available voters to display e.g. part of their surname.

3. The actor fills in the criteria 4. The system displays the corresponding set of voters, the size of which depends on the num-ber and values of the selection criteria, and provides the ability to select some for further processing or to create/import new ones.

5. The actor selects to import voters from a file. Optionally the actor may select to:a. Manually create a voter (DP-5a)b. Delete a voter (DP-5b)c. Modify a voter (DP-5c)d. Provide authentication means for a voter (DP-5d)

6. The system asks the actor to select one of the existing election districts/unit (it also provides him the ability to create a new election district/unit). The election district/unit selected is the one the voter will vote in.

7. The actor selects the desired election district

8. The system prompts for the location of the file to import voters from.

9. The actor indicates the file’s location

10. The system imports the voters notifying the actor for the success or failure of the operation. The information provided for the voter consists of sex, surname, name, father’s name, mother’s name, husband surname (for married women bearing their husband’s surname), date of birth, birth identification number, and address.


Step 7: In case the election district the voter(s) will be assigned has not yet been defined in the system, the actor must first create that election district as described in system use case 3.1.1.4

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 54 of 188


(Manage Election Districts)


DP-5a: Manually create a voter


5a. The actor asks the system to create a voter

6. The system prompts the user for information about the new voter.

7. User provides required information and asks the system to store it

8. The system attempts to perform the insertion / addition and informs the user about success or failure of the operation

DP-5b: Delete a voter


5b. The actor asks the system to delete a voter

6. The system asks for a onformation

7. User confirms deletion 8. The system attempts to perform the deletion and informs the user about success or failure of the operation

DP-5c: Modify a voter



5c. The actor requires to update a voter’s information

6. The system presents current information to the user to view and modify

7. User modifies data and asks the system to perform the update

8. The system informs the user about the success or failure of the operation

DP-5d: see system use case 3.1.1.8 (Provide Authentication Means)


This use case is used by election organisers for providing voters and party representatives with authentication means. The election organisers acquire authentication means directly by the system23.Purpose Create and distribute authentication means to all actors


Actors All

23 Possibly under the supervision of party representatives and/or judicial authorities

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 55 of 188


Type Primary

Preconditions The actor(s) exist(s) in the system



NF3.1.1.8.1 Security Authentication means must be created, stored and communicated to voters / party representatives in a secure way.

NF3.1.1.8.2 Performance The entire authentication means delivery process should be completed within a reasonable amount of time.

NF3.1.1.8.3 Performance The maximum amount of time required for mass creation and delivery of authentication means should be calculated and its feasibility be ensured.






1

SYSTEM FUNCTIONS




R3.1.1.8.1.1 Manage actors choice accordingly


R3.1.1.8.2 Select actor and key actor authorisation means24

Evident The provision of authentication means should include options such as strength of authorisation mechanism (i.e. password, cryptic id, digital pseudonym, etc), selection of distribution means (i.e. electronically, physically, mix), additional proofs etc25. For key actors, the provision of cryptographic keys embedded in smart cards or similar tokens or biometric techniques is under consideration26.

R3.1.1.8.3 Retrieve list of voters

Evident

R3.1.1.8.4 Create credentials for voters or key

Evident

24 In the context of Prototype 1, there are no key actors groups along with privileges definition in order to formulate a hierarchy of roles.

25 In the context of Prototype 1, the provision of authentication means results to password generation.26 In the context of Prototype 1, the provision of authentication means results to password generation.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 56 of 188




Attribute(s)



1

actors27

R3.1.1.8.4.1 Notify actor about operation completion

Evident

R3.1.1.8.5 Store credentials of voters28

Hidden Audit The voters’ credentials are kept for verifiability reasons

R3.1.1.8.6 Deliver credentials to voters

Evident When the delivery of credentials is performed offline, this function is omitted.

R3.1.1.8.7 Store credentials of key actors29

Hidden Audit The voters’ credentials are kept for verifiability reasons

R3.1.1.8.8 Deliver credentials to key actors30

Evident In case the delivery of credentials is performed offline, this function is omitted.

SYSTEM ATTRIBUTES

R3.1.1.8.9 Provide an open API to easily in-corporate new authentication means

Hidden Security To allow the system to cope with advancements in authentication technology

R3.1.1.8.10 Log all attempts to generate authentication means, suc-cessful or not.

Hidden Voter data management Security,

Audit


R3.1.1.8.11 Complete process in a timely and feasible way

Hidden Performance The entire process of generating authentic-cation means (and delivery, if performed electronically) should be completed within a reasonable amount of time.


1. The election organiser selects to provide authentication means for one or more voters / party representatives

2. The system creates authentication means (physical or electronic) for each selected voter / party representative

27 In the context of Prototype 1, the provision of authentication means will take place only for voters.28 In the context of Prototype 1, the credentials of the eligible voters are stored in the e-VOTE system with no special

protection mechanisms in place, for verifiability reasons.29 In the context of Prototype 1, no credentials for key actors will be created.30 In the context of Prototype 1, no credentials for key actors will be delivered.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 57 of 188



Step 2: If the voter / party representative has been already provided with authentication means the system informs the election organiser by offering two choices: To invalidate the authentication means provided and create new ones or to cancel the operation. In the first case the system provides a way to inform the voter.

3.1.1.9 Manage Parties31

Purpose To notify the system about candidate parties for an election


Actors Election Organisers

Type Primary

Preconditions 1. The actor is officially authorised to perform changes in the candidate parties list




NF3.1.1.9.1 Security The system should be able to import an electronic list of parties from different sources and formats. The list of parties should be complete, correct and up-to-date. The list should not be transmitted to the system, but delivered through secure physical means.


NF3.1.1.9.3 Security The system should log all actions, as depicted in Section 3.1.2 (Logging).





Implemented in

Prototype 1

SYSTEM FUNCTIONS

R3.1.1.9.1 Provide actor with a relevant well-defined




e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 58 of 188




Attribute(s)


Implemented in

Prototype 1

interface





R3.1.1.9.3 Permit party data editing only during the “election set-up” phase

Evident See above function

R3.1.1.9.4 Receive party input

Evident Actor should be able to enter information about the party (e.g. the party name, its logo, the leading person)

R3.1.1.9.4.1 Verify input data


SYSTEM ATTRIBUTES

R3.1.1.9.5 Logging Hidden All operations related to party data management should be logged

Security,

Audit



1. An election organiser requires to manage candidate parties

2. The system provides the actor with the set of candidate parties (from the last election) and the ability to create a new party or select one for further processing

3. The actor asks the system to create a candidate party. Optionally the user may decide to:a. Delete a candidate party

(DP-3a)b. Modify a candidate party

(DP-3b)c. Manage candidates for that

party (DP-3c)

4. The system requests the name of the candidate party, and the logo of the party that will be used for the ballot

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 59 of 188


5. The actor provides requested information and indicates the position of the logo file for the party ballot (which he has previously acquired by the party representative)

6. The system stores the information about the new party


DP-3a, DP-3b: For either choice the steps involved are identical to the corresponding steps of the system use case 3.1.1.4 (Manage Election Districts)

DP-3c: See system use case 3.1.1.10

3.1.1.10 Manage Candidates

This system use case extends use case 3.1.1.9.

Purpose To insert, modify or delete a party’s candidates for a specific election district



Type Primary

Preconditions 1. The candidate’s party exists in the system

2. The actor is officially authorised to perform changes in the candidate list

In the context of Prototype 1, the following issues should be noted:

1. No election districts are defined (i.e. refer also to Section 3.1.1.4 “Manage ElectionDistricts”, since the election type (poll) does not dictate the existence of a party for a poll to take place.

2. Precondition 1 stated above is not mandatory for Prototype 1, since the election type (poll) does not dictate the existence of a party for a poll to take place.



NF3.1.1.10.1 Security The system should be able to import an electronic list of candidates from different sources and formats. The list of candidates should be complete, correct, up-to-date and every candidate should be linked to a specific party. The list should not be transmitted to the system, but delivered through secure physical means.


e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 60 of 188



NF3.1.1.10.3 Security The system should log all actions, as depicted in Section 3.1.2 (Logging).





Implemented in

Prototype 1

SYSTEM FUNCTIONS




R3.1.1.10.1.1

Manage actor’s choice accordingly


R3.1.1.10.2 Check and notify actor for the system phase

Evident Modification of candidates list should be permitted only in the pre-election phase

Consistency In order to set/modify the candidates list, the system should be in the pre-election phase. Otherwise, the Authenticate Key Actors procedure should be followed via the “Alter candidate list in voting phase” (R3.1.1.10.3) function

R3.1.1.10.3 Alter candidate list in voting phase

Evident Security,

Reliability,

Trust enhancement

The Authenticate Key Actors procedure should be activated in case the actor wishes to set/modify election candidates in a system phase other than the pre-election one

R3.1.1.10.4 Import Candidates List

Evident Interoperability,

Security

The system should be able to import an elec-tronic list of candidates from different sources and formats. The can-didates’ list should be complete, correct and up-to-date. The list of candidates should not be transmitted to the system, but delivered through secure physical means32.

R3.1.1.10.4.1

Validate candidates data



R3.1.1.10.5 Add, Edit, Delete candidates

Evident Candidate information may include name, surname, sex, father’s name, mother’s name, husband

Privacy The candidates’ data stored by the system should not violate the Data Protection

32 For Prototype 1, a single format for candidates list will be supported.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 61 of 188




Attribute(s)


Implemented in

Prototype 1

surname (for married women bearing their husband’s surname), date of birth, entity identifica-tion number (country specific), and electronic address. All these must be kept confidential33

legislation.

R3.1.1.10.6 Store candidates’ list in a secure way

Hidden Security In order to enhance the security and audit processes, the candidates’ list should be stored in a secure server different than the machine running the e-VOTE system.

SYSTEM ATTRIBUTES

R3.1.1.10.7 Logging Hidden All operations related to candidate data management should be logged



1. The use case initiates after the election organiser has selected a candidate party to work with. The actor selects to manage candidates for that party

2. The system presents the election districts defined so far and prompts the user to select one in order to manage its candidates for that party

3. The user selects the desired election district.

4. The system displays the candidates of the party for the selected election district and provides the ability to insert a new candidate, or to modify or delete information about a specific candidate.

5. The actor selects to insert a new candidate. The user may also decide to:a. Delete a party candidate (DP-5a)b. Modify a party candidate (DP-5b)

6. The system requests information on the candidate. The information the system retains about candidates are the party in which they belong, surname, name, father’s name, mother’s name, husband surname (for married women bearing their husband’s surname), date of birth, registry book number -if applicable- and occupation.

7. The actor provides necessary information

8. The system stores the provided information about the candidate


33 For Prototype 1, the minimum information provided for the candidates consists of name and surname.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 62 of 188


DP-5a, DP-5b: For either choice the steps involved are identical to the corresponding steps of the system use case 3.1.1.4 (Manage Election Districts)

3.1.1.11 Preview Ballots

Purpose Check the content and format of the ballots that will be used in the election

Related Business Use Case(s)

2.1.1.5, 2.1.1.7

Actors All

Type Primary

Preconditions The ballot logo for the parties and all candidates have been inserted in the system

In the context of Prototype 1, the following issues should be underlined:

1. The precondition “The ballot logo for the parties and all candidates have been inserted in the system” is not mandatory, since no parties are defined in the context of Prototype 1 (also refer to Section 3.1.1.9 “Manage Parties”).



NF3.1.1.11.1 Reliability Ballots should be created correctly and timely upon request.

NF3.1.1.11.2 Security No information irrelevant to the voting process should appear on the ballot.






1

SYSTEM FUNCTIONS




R3.1.1.11.1.1



R3.1.1.11.2 Add, Edit, Delete electronic ballot format

Evident Interface Metaphor

Electronic Ballots should be similar in form to real-world ones. The system should also provide the capability to define an “invalid” and a “white” ballot.

R3.1.1.11.3 Create electronic ballot

Hidden Reliability Ballots should be created correctly and timely upon request.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 63 of 188




Attribute(s)



1

Ballots should be created automatically according to the candidates34

R3.1.1.11.3.1

Display ballot Evident Security, Reliability

The system should deal successfully with malformed interaction and/or unexpected input.Expose the minimum possible information, in order to facilitate the voting process. No system/application specific information should be disclosed through the ballot

SYSTEM ATTRIBUTES

R3.1.1.11.4 Logging Hidden All operations related to ballot preview should be logged



1. The actor asks the system to preview ballots

2. The system prompts the actor for the election district he wishes to preview the ballots35

3. The actor selects the election district

4. The system displays available ballots for the election district

3.1.1.12 Provide Party Info36

Purpose Provide Information about candidate parties

Related Business Use Case(s) -

Actors All

Type Optional

Preconditions -

Cross References -



NF3.1.1.12.1 Security No information other than publicly available

34 In Prototype 1 there is a single ballot35 It should be noted here that “ballots” are created automatically according to the parties and candidates

for each election district36 This use case will not be implemented in Prototype 1.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 64 of 188


regarding the party should be provided.






137

SYSTEM FUNCTIONS




R3.1.1.12.1.1



R3.1.1.12.2 Display Party List with the ability to select a party

Evident

R3.1.1.12.3 View information about the selected party

Evident

R3.1.1.12.4 Display information about a party

Evident Basic information about the party (e.g. the party name, its logo, the leading person, etc) and a sample ballot format should be displayed to the user

R3.1.1.12.5 Display the list of candidates per election district

Evident

SYSTEM ATTRIBUTES

R3.1.1.12.6 Logging Hidden All operations related to party information data management should be logged



1. The actor selects to view information about candidate parties

2. The system prompts for the candidate party

3. The actor selects the desired candidate party

4. The system returns all available information about the parties, its logo and the list of candidates per election district

37 Note that this use case is optional. However, should it be implemented, all related functions should be implemented too.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 65 of 188


3.1.1.13 Cast Vote

Purpose Facilitate electronic voting


Actors Voter

Type Primary

Preconditions The voter has been authorised to cast his vote (system use case 3.1.1.1)

Two logical entities (or sets of logical entities) exist which interact in this scenario: the Actor and the e-VOTE system (which is actually a set of logical entities).



NF3.1.1.13.1 Security No vote can be linked to a voter

NF3.1.1.13.2 Security No voter can vote twice

NF3.1.1.13.3 Security No one can duplicate or change his or someone else’s vote

NF3.1.1.13.4 Security No one can “see” what others have voted

NF3.1.1.13.5 Security Voter casts vote alone with no pressure (uncoercibility)

NF3.1.1.13.6 Security An undeniable proof (receipt) has to be delivered to the voter in order to:1. prove that he/she has cast a vote.2. achieve non-repudiation of vote casting.

NF3.1.1.13.7 Security Data should be transmitted in a reliable (accurate and confidential) way.

NF3.1.1.13.8 Security The e-VOTE system should be transparent to the voter, in such a way that he can virtually vote from everywhere

NF3.1.1.13.9 Security Logging of all actions takes place, as defined in Section 3.1.2 (“Logging”)

NF3.1.1.13.10 Performance A voter should be able to cast a vote on average in less than 4 minutes, from the moment that he/she has been authenticated by the system.

NF3.1.1.13.11 Usability The voter should have the option of casting an invalid vote.

NF3.1.1.13.12 Usability As the voter has not cast his vote yet, he should be able to change his choices at will or even abandon it.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 66 of 188






Implemented in

Prototype 1

SYSTEM FUNCTIONS

R3.1.1.13.1 Check already cast vote

Hidden Consistency If the voter has already cast a vote, the system must be able to identify any attempt to vote again

R3.1.1.13.2 Display Ballot

Evident Interface Metaphor

The ballot should look similar to the physical one38

R3.1.1.13.3 Vote Casting

Evident Security (a) No ballot can be linked to a voter(b) No Voter can vote twice(c) No one can duplicate someone else’s vote, nor cast a modification of somebody else’s vote.(d) No one can see what others have voted(e) No one can vote on behalf of someone else, nor change what someone else votes.(f) Voter has the ability to cast an invalid ballot(g) Voter has the ability to cast a blank ballot

R3.1.1.13.3.1 Ability to cast up to a predefined maximum number of choices (i.e. up to M)39

Hidden

R3.1.1.13.4 Validate vote

Hidden The system validates the cast vote

R3.1.1.13.5 Generate vote proof

Hidden

R3.1.1.13.6 Deliver proof of voting

Evident The voter should be informed that the voting process has been successfully completed

Audit,

Trust Enhancement

It should not be possible to associate the proof to the choice of the voter

R3.1.1.13.7 Confirm (possibly invalid) vote casting

Evident

R3.1.1.13.8 Cancel vote casting

Evident

38 In Prototype 1, a ballot with basic options will be made available to voters.39 The number M may has been set up in the “Provide Election Parameters” procedure; in the context of Prototype 1,

M should be equal to 1 (i.e. “1 out of L” election)

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 67 of 188




Attribute(s)


Implemented in

Prototype 1

R3.1.1.13.9 Record vote casting success

Hidden

R3.1.1.13.10. Verify validity of the vote cast

Hidden

R3.1.1.13.11 Store vote in a secure way

Hidden Security,

Performance,

Audit

The e-VOTE system stores the vote cast in a different machine than the one that is running the e-VOTE system

SYSTEM ATTRIBUTES

R3.1.1.13.12 Logging Hidden All operations related to vote casting should be logged



1. The voter selects to cast his vote 2. The system checks that the voter has not cast his/her vote and presents the available ballots for the election district that he/she is assigned to40

3. The voter selects the ballot he desires

4. The system prompts for the candidates the voter prefers

5. The voter selects the desired candidates

6. The system records both the fact that the voter has voted and that the vote is cast

3.1.1.14 Tally Votes

Purpose Calculate the election result

Related Business Use Case(s) 2.1.1.8, 2.1.1.9

Actors Election Organisers41

Type Primary

Preconditions The election procedure has ended


40 As with the “preview ballots” use case, ballots are created automatically according to the parties and candidates in the system for the voter’s election district

41 Possibly under the supervision of party representatives and / or judicial officers

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 68 of 188



NF3.1.1.14.1 Security It must be impossible to tally the votes before the voting process officially ends.

NF3.1.1.14.2 Public Trust The integrity of the tallying process should be ensured by the participation and active involvement of interested parties’ representatives during the tallying process.

NF3.1.1.14.3 Security After the tallying process, the attributes (NF3.1.1.13.1, NF3.1.1.13.2, NF3.1.1.13.3, NF3.1.1.13.4) should be effective.

NF3.1.1.14.4 Security Votes and relevant evidence should be stored in a secure way


NF3.1.1.14.6 Availability After the election has finished, the e-VOTE servers must be isolated from any external or /and public network (if applicable)






1

SYSTEM FUNCTIONS

R3.1.1.14.1 Check election phase

Hidden Security,

Trust Enhancement

The system should be able to identify the current election phase.

The system should be in the Election Concluded phase in order to perform this operation.

R3.1.1.14.2 Prohibit tallying before election end time

Evident Notify for the election end time

Security,

Trust Enhancement

It must be impossible to tally the votes before the voting process officially ends.

R3.1.1.14.3 Isolate e-VOTE system

Hidden Availability After the election has finished, the e-VOTE system must be isolated from any external or /and public network (if applicable)

R3.1.1.14.4 Store votes in a secure way

Evident

R3.1.1.14.5 Prohibit election information provision before tallying end time

Evident Interface metaphor,

Security,

Trust Enhancement

It must be impossible to provide election information before the tallying process ends.

R3.1.1.14.6 Notify for the tallying period

Evident

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 69 of 188




Attribute(s)



1

end time

R3.1.1.14.7 Provide election information

Evident The system should be able to present the voting result in a variety of views42

SYSTEM ATTRIBUTES

R3.1.1.14.8 Logging Hidden All operations related to vote tallying should be logged



1. The actor requests to be informed about the voting result

2. The system presents the voting result along with different views of the result (e.g. by election district)

3. The actor selects the desired view

4. The system presents the desired view


Purpose Verify that system use cases have performed the required actions as expected and in a timely manner



Type Primary

Preconditions -



NF3.1.1.15.1 Security It must be impossible to verify the election results before tallying process officially ends.

NF3.1.1.15.2 Public Trust Verification of the integrity of the voting result should be ensured by the participation and active involvement of interested parties’ representatives during the verification process.

NF3.1.1.15.3 Security After the verification process, attributes (NF3.1.1.13.1, NF3.1.1.13.2, NF3.1.1.13.3, NF3.1.1.13.4) should be effective.

42 In Prototype 1, a single view will be implemented.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 70 of 188


NF3.1.1.15.4 Security Verification evidence and results should be stored in a secure way







1

SYSTEM FUNCTIONS

R3.1.1.15.1 Provide reasonable assurance for the election result integrity

Evident Trust Enhancement

The system should be able to provide reasonable assurance for the integrity of the election result

R3.1.1.15.2 Verify Vote Calculation

Evident Trust Enhancement

The system should be able to demonstrate that all votes have been tallied correctly.

SYSTEM ATTRIBUTES

R3.1.1.15.3 Logging Hidden All operations related to the verification of result integrity should be logged

Security,

Audit



1. The organiser asks the system to verify the integrity of a system use case

2. The system prompts the actor for the desired election district

3. The actor selects the desired election district

4. The system returns the number of persons that have voted in all election units of the election district against the corresponding number of votes43

3.1.2 System Wide Attributes

Non-functional requirements can be specific to a use case or they can be system wide. Thus, these requirements may cover a broad range of use cases.

Attribute Code

Attribute Group

Attribute Details and Constraints Implemented in Prototype

1Logging Security All internal system operations related to voters must be logged

without sacrificing voter’s secrecy and/or confidentiality.

Logging Security Detailed application and system logs should be kept in a process call level. Logs should be kept.

43 Further integrity tests are required but have not been defined yet

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 71 of 188


Attribute Code

Attribute Group


1Abnormal interaction or unexpected input handling

Security The system should treat properly abnormal interaction or unexpected input data in all system functions in a way such that the system functionality is preserved and no system/application specific information is disclosed (e.g. abnormal interaction may include abnormal termination of the authentication process or vote casting, whereas unexpected input data may include control characters in an input field of an interface, modified fields of message packets, etc).

Cryptographic Services

Security The system should be able to use all necessary cryptographic services, as defined in Section 7.4 “e-VOTE Service Blocks”

Data Protection Security Information processing should be compliant with national and international data protection legislation framework

Adequate controls should be in place to ensure with reasonable assurance that data protection principles are enforced in an effective and efficient way.

Uncoercibility Security Voters should cast their votes alone with no pressure.

System Availability

Security The availability of the e-VOTE system while the election is in progress must be maximum

System Availability

Performance - Security

Alternative general support (e.g. back end facilities) and election site(s) should be available in case of failure, caused by deliberate – or accidental – actions.

System Availability


The Mean Time Between Failures (MTBF) should be minimum during the election process

System Availability


Updated e-VOTE backups (both host system and application) should be readily available in order to restore the system in case of a disaster.

Integrity Security Users should administer the system only from specific terminals, within a predefined time window, using a combination of strong authentication means, such as biometrics or smart cards.

Integrity Security The minimum necessary software and hardware components should be installed on the machine hosting the e-VOTE system.

Integrity Security The maximum possible level of operating system security enhance-ment should be applied to all machines of the e-VOTE system.

Integrity Security It should be impossible for a user to escalate his/her system privileges (in terms of the functions he/she is authorised to use).

Integrity Security It should be allowed, under certain emergency circumstances, to modify selected parts of the system when in use.

Client Integrity Security Breaches to the security of the client should not have an impact to the security of the system

Accountability Security All e-VOTE system-related actions, successful or not, should be logged.

Accountability Security Only the absolutely necessary entities44 should have logical and/or physical access to the e-VOTE system.

Accountability Security Adequate segregation of duties must be enforced between the authorised personnel.

User-friendliness Usability The system responses should clearly indicate to the user the result of the respective action she/he performed.

Flexibility Usability The system should be able to electronically import, in various

44 For Prototype 1, no formal roles and entities will be defined.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 72 of 188


Attribute Code

Attribute Group


1formats, election data concerning parties, candidates etc.

Flexibility Usability The system should be able to electronically import, in various formats, election parameters (such as type of election and relevant restrictions, eligibility criteria etc.)

Flexibility Usability The system should be able to produce reports at various levels of detail, based on criteria chosen by the user.

Error-checking Reliability There should be provision for checking the consistency of the e-VOTE system after every modification (e.g. existence of voters not belonging to an existing district – even via respective election units – should raise an alarm to the user).

Data assets Security Data assets must be protected from: Unauthorised disclosure, Unauthorised modification and fabrication. Denial of authorised access

Hardware Assets Security All hardware assets must be protected from becoming lost, stolen, unavailable, or unusable.

Software Assets Security All software assets must be reasonably protected from becoming deleted, lost, stolen, modified, or fabricated.

Storage Media Security All data and information used must be stored (when and if needed) in secure (protected and tamper-proof) storage media.

Human Assets Security Individuals responsible for crucial system operations must be carefully selected.

Encryption Security Sensitive data and information exchanged between computers of the e-VOTE system must be in an encrypted form.

Application of Physical Controls

Security Application of physical security measures such as door locks, guards, physical site planning etc.

Accessibility Usability There should be support for use by disabled persons such as equally weighted methods of authentication and visual information representation methods. Different languages should also be supported.

Communications Security Information regarding ANY of the above functions should be private even if transmitted over public networks

Table 2: System Wide Attributes

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 73 of 188


4 State of the art on electronic voting technologies

In this Chapter, an overview of technologies currently used in electronic voting is provided. The aim is to justify our choice in regard to the e-VOTE system voting protocol.

4.1 Assessment of voting protocols currently in use and related risks

The primary difficulty in implementing secure e-voting protocols is to simultaneously fulfil the user as well as the legal and regulatory requirements; such as ensuring secrecy of votes, that only eligible voters can vote, that they only vote once etc. Furthermore, it is essential for the vote tallying process to be universally verifiable.

Several approaches have been adopted in electronic voting. Some indicative ones are briefly discussed in the sequel.

4.1.1 Blind Signatures

A blind signature is a digital signature provided by a trusted party. The key feature is that the trusted party checks the identity of the party requesting the signature while the signature generation is performed in such a way that the trusted party need not know the text (or the hash value of the text) that it signs.

When used for voting, a trusted party is installed, for signing all votes with blind signatures. Thus, the voter produces a vote, has it blindly signed by the trusted party and submits it.

In principle this suffices to provide for the secrecy required with regard to an electronic voting system. There are also no particular performance problems.

However, Internet voting using blind signatures cannot provide adequate untraceability, since the central server(s) tallying the votes can trace back where the votes were cast. Secrecy of votes is also required in cases where voting takes place at election sites, because a record of where and when a vote was cast, combined with a record of who voted where and when (for example by an election official with a good memory) can completely compromise the secrecy of voting.

Thus, the blind signature mechanism is insufficient, unless combined with means for providing untraceable network communication; this is discussed next.

Furthermore, it is prerequisite that the party providing the blind signatures is unconditionally trusted, since it has the means for producing fake votes.

4.1.2 Untraceable Network Communication

In order to make network communication untraceable, a layer of encryption must be introduced and the order of outgoing messages must be randomised with respect to the order of the incoming messages. If not, monitoring incoming and outgoing messages, in each of the nodes through which the messages pass, suffices to trace messages back to their origin.

Combined with blind signatures, this mechanism can provide a certain level of security. However, the requirement for unconditional trust in the party producing the blind signatures

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 74 of 188


remains an open issue (solving it would require a secret sharing mechanism like that applied in the protocol chosen to be implemented in the e-VOTE system). In this case, universal verifiability can be achieved by combining logs from the party producing blind signatures with logs of the party performing the vote tallying.

4.1.3 Trusted hardware

Another option is to use trusted hardware for providing security. With this approach, performance can be acceptable. Initial costs are higher compared to a software based solution, but in the large picture this may also not be a serious problem.

The main problem, however is of a principal nature. The hardware (and in particular the software embedded in it) must be unconditionally trusted; this is unfortunate, since any government may influence the provider of the hardware.

4.1.4 Homomorphic Encryption

In this approach a special crypto system is used for encrypting votes, facilitating counting of votes in encrypted form. Votes are delivered encrypted together with a non-interactive zero-knowledge proof that they are encryptions of correctly filled votes. Since votes are counted in encrypted form and are never decrypted, their authenticity can be directly established.

If the key used for decrypting the result is secret shared, the unconditional trust can be distributed on persons and organisations in the most appropriate way. A number of practical obstacles remain, but there are no principal problems with this approach except for performance and the issue that the encryption may at some point be broken.

The key to better trust properties is that mathematical properties are trusted rather than persons or organisations. Thus it is not in the power of any government or any vendor of the system to tamper it without being easily revealed.

This approach has been taken by the Cybervote project [iii]. To the best of our knowledge they use homomorphic encryption based on the El Gamal crypto system [xxvi]. This makes some elections possible but scales very poorly with regard to the number of candidates.

The e-VOTE project will follow the same approach, utilising, however, a voting protocol based on the generalised Paillier crypto system that appeared a few months before the project started. In particular, it is the first system based on homomorphic encryption, supporting elections with hundreds of candidates in a practical and economically feasible way.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 75 of 188


5 e-VOTE Architecture

In parallel with all the above and in conjunction with Section 4.1, a sketch of the extensible and scalable e-VOTE architecture is described. Main strongholds are established in three directions: better performance with full security than what has been implemented earlier (polynomial instead of exponential growth in the number of candidates), ability to adapt to different user requirements, in particular by offering several authentication models and cost efficiency per voter.

The voting protocol that will be implemented by the e-VOTE system is presented together with its strongholds and future directions. Furthermore, different authentication models are discussed and two architectures are sketched corresponding to different user requirements with regard to authentication model.

5.1 Entities in a Voting System

This Section presents the basic entities found in many voting systems. However, not all entities need to be present while additional entities may exist.

A voting front-end: An application from which the voters can vote. This can for example be a web server, making it possible for voters to vote from home or from work, or an application installed in a voting site.

The message board: The unique server, where votes are collected and counted.

A pre-message board: Very simple optional servers, used for performing performance-demanding operations on votes, prior to their arrival to the message board. As a rule of thumb, pre-message boards are only necessary if there are more than 20.000 voters, a non-trivial number of candidates and requirements for secrecy of votes.

A tally server: An optional server, run for example by each political party. Used for decrypting the result of an election, after the election process has finished. Tally servers typically are very simple.

An administration client: If not qualified by a server type, it is a client for handling administrative tasks on the message board.

An election generation application: An application used for starting up the election process. That means enrolling voters, generating a voting key, sending out authentication information to voters etc. Because secrecy of votes is required, an election generation application independent of the message board is necessary for security reasons. We will often use the word registration client instead, when the details of registering information of voters dominate the discussion.

A CA: A Certification Authority issuing certificates. This may be a public certification authority or a certification authority used for the voting solution only

A LRA. Local Registration Authority. Application with which voters, administrators and servers are registered for certification by the CA.

A signature server: A server that stores secret keys of voters in secure hardware.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 76 of 188


5.2 High-level description of the voting protocol to be implemented

The voting protocol to be implemented in the first prototype of the e-VOTE system is the Damgaard-Jurik-1 voting protocol.

The Damgaard-Jurik-1 voting protocol is based on a homomorphic encryption scheme, the so-called generalized Paillier [xxii] encryption scheme. A secret sharing mechanism is used to prevent any single entity from being able to decrypt votes.

Such schemes have existed for a few years; in the past few years homomorphic encryption schemes based on the El Gamal and EC El Gamal [xxvi] have been preferred. These protocols have properties similar to these of the Damgaard-Jurik-1 protocol [xxii], with the exception of one important property: There exists an efficient decryption algorithm for the generalised Paillier, but not for the homomorphic El Gamal. This allows the e-VOTE consortium to implement a more efficient packing of votes than what can be applied for El Gamal and EC El Gamal.

The work is progressing aiming to define a more efficient voting protocol to be implemented in the pilot e-VOTE system. Furthermore, additional security features and/or support for several types of election process can also be included.

5.2.1 Production of Votes

With respect to the voting protocol (technically speaking), all elections are considered to be a choice of one out of L candidates. The L candidates include the blank and possibly the invalid vote (candidate choice simulating a vote with a wrong number of crosses, text or drawings written on them etc.). Candidates are sequentially numbered from 0,…, to L-1.

A clear text vote is represented as a number Mj, where M is a number higher than the number of voters and j is the chosen candidate.

The clear text vote is encrypted, and a non-interactive zero-knowledge proof that the cipher-text vote is of the form Mj for j [0,..,L-1] is produced.

An encrypted vote will, in the following, always denote the pair of the cipher text and the corresponding zero-knowledge proof.

5.2.2 Verification of Validity of Votes

When the message board receives a vote, the zero knowledge proof that the vote is on the correct form is verified.

5.2.3 Counting Votes

The generalised Paillier crypto system is homomorphic, meaning that for each pair of cipher texts E(v1) and E(v2) we have

E(v1) E(v2) = E(v1+v2)

Thus, valid votes can be counted on encrypted form by multiplying in cipher texts.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 77 of 188


5.2.4 Decrypting the Result

In order to prevent any single entity from decrypting votes, the secret key is shared between several servers, the so-called tally servers. The secret sharing mechanism used allows to use any number of tally servers and to set any threshold for the number of tally servers, which need to cooperate in order to decrypt the result. These numbers must be selected by election organisers for each individual election.

When the message board has counted the votes, it submits the product of the votes to the threshold servers.

Each cooperating threshold server uses its share of the secret key to produce a decryption share. The decryption shares are sent back to the message board together with a non-interactive zero-knowledge proof that they are correctly computed.

The message board verifies the proofs that decryption shares are correctly computed. When it has the necessary number of correct decryption shares, it is capable of decrypting the result of the election.

The decrypted result is on the form

a0 M0 + a1 M1 + … + aL-1 ML-1,

where a0 is the number of votes for candidate 0, a1 is the number of votes for candidate 1, etc.

5.2.5 Independent Verification

If the votes, the decryption shares and the decrypted result are published, it is possible for an independent verifier to verify that the votes were counted correctly.

5.2.6 Performance Issues

Better performance is achieved with the protocol chosen than with similar schemes based on El Gamal [xxvi]. The reason is that with El Gamal, if votes were on the form chosen, it would be necessary to run through all possible outcomes of the election in order to decrypt the result. This procedure takes the number of voters lifted to the number of candidate’s steps, each of a complexity similar to producing a RSA signature.

With the current implementation, we are realistically able to handle elections with up to about 200 candidates and 50.000 voters with single computer systems. If the number of candidates is increased, the number of voters must be decreased and vice-versa.

If verification of proofs is carried out in parallel on more computers, better performance can be achieved. In particular, if election districts have distinct candidates (like in Denmark), this scales up to a general election in Denmark with 1000 candidates and 4.000.000 voters all in all. In such a case, only the largest election districts will have to use very powerful hardware or subdivide themselves into smaller, virtual election districts.

5.2.7 Authentication Layer

Authentication of the messages will be achieved by using digital signatures and will be compliant with signature laws (simplified administrative procedures may thus be applied in the trials).

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 78 of 188


The structure of the PKI and the voting protocol are completely independent. Two overall structures of PKI meeting different user requirements will be given in Section 5.4.11.

5.2.8 Compliance with Requirements

The voting protocol complies with secrecy of votes and possibility of independent verification. Compliance with other requirements can be ensured by the authentication mechanisms, design of the voting system and administrative procedures applied.

5.2.9 Future Directions

Future work regarding the voting protocol include the following issues: Performance of the construction and verification of non-interactive zero-knowledge

proofs. Protection against hacking the computers of the voters. Currently, this can be achieved

for small elections; its scalability will be enhanced by improving the protocol. Distributed key generation. This is in order to prevent that the secret shares are

produced on one computer, as it is currently the case. Instead, they shall be produced by a secure protocol between the tally servers.

Enhancement of the protocol with possibilities for votes on more candidates, more candidates from the same party etc. Τhe enhanced protocol that will satisfy these cases as well will be specified as soon as the performance has been improved.

When enough improvements have been achieved, a new voting protocol will be specified. The scientific research in this direction is in progress and we will soon be able to realise a number of improvements enough yet to justify the specification of a new protocol.

5.3 Secrecy of Votes

As mentioned earlier, the e-VOTE consortium is developing toolkits for generation and handling of votes using the Generalized Paillier homomorphic crypto system [xxii].

A standard for the formatting of messages using ASN.1 notation ([xx]) is being specified, which provides support for the Damgaard-Jurik-1 voting protocol [xxii] so far, but will be extended in the future.

Relevant toolkits that have already been implemented are available in JAVA and ANSI C. The JAVA toolkits contain all functionality necessary to vote from a web browser (and more), whereas the ANSI C toolkits support all functionality.

At present, elections where voters can make a choice of one out of L candidates are supported. Moreover, blank votes and invalid votes are supported.

We describe briefly the steps supported by these toolkits, leaving out steps having to do with the authentication of voters:1) Generate the voting key and a structure containing data about the election. (ANSI C only).

The secret key is not exported. Instead a number of secret shares, each containing a part of the secret key, are exported encrypted under passwords and optionally under a public key also. The shares work in the following way: If more than a number of shares determined in the key generation process are used to decrypt, an encrypted message can be decrypted completely. If fewer shares are used, no information on the content of the encryption can be gained.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 79 of 188

Maria Karyda, 03/01/-1,

Σελίδα: 79Tι πίνανε όταν τα έγραφαν αυτά, μπορεί να μου πει κανεις???


2) Generate an encrypted vote for a particular candidate. (Done by the voter, typically on a web browser using the JAVA toolkit.)

3) Verify that an encrypted vote is an encryption of a legal vote. This is done without inferring any information about the vote other than that it is an encryption of a legal vote. (This is done by the message board or by a pre-message board.)

4) Count votes on encrypted form. (Done by the message board.)

5) Decrypt the result. This is done by the message board, in co-operation with at least the necessary minimal number of the tally servers.

These are the steps taken during an election. An additional generic user requirement is that it must be possible to recount the votes. This is done by repeating step 4 above and by verifying that the decrypted result is a decryption of the encrypted result, using the generalised Paillier public key only.

5.4 Authentication of Voters

Making the right choice of the authentication model for voters is decisive. The model must, at the same time, be secure enough for the purpose and convenient to vote. We have at our disposal a large variety of authentication means. A number of possibilities, which cannot be recommended, have also been included for reasons of completeness and for facilitating the understanding of the choices we make.

It should also be noted that in each case where a PKI is employed, either a public PKI or a customized PKI for voting could be used.

At the current stage we have not decided on the authentication means for the final pilot – this will have to be agreed between the users and the providers. However, the architecture of the system is independent of the exact means of authentication, provided that PKI is used.

5.4.1 Password Based Authentication (PBA)

An authentication model can be built securing each vote by a MAC value (i.e. Message Authentication Code) based on a password.

This model cannot be recommended however, since it cannot reach a decent level of security – some server will know the passwords or derived values of the passwords, and will be capable of faking or modifying votes.

5.4.2 PBA. One password - PKI at the back end

In this case, each user receives one password, which is used for issuing a certificate.

As for Section 5.4.1, this model cannot reach a high level of security. However, the back-end will also support other, PKI-based authentication models, so that the level of security can easily be increased when required.

5.4.3 PBA – Two Passwords

By having two passwords, generated by different servers and verified by different servers, it is possible to reach an acceptable level of security.

The disadvantage is that two servers must also be involved in verifying the authentication information for each authentication attempt. In particular, two independent servers must be involved for each verification of the election result.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 80 of 188


5.4.4 PBA. Two passwords - PKI at the back end

This case resembles the previous one. The difference is that the verification of authentication information is simple.

Such an option is possible by using a certification authority for issuing certificates as the users vote. One password is generated by the application used to register voters; the certification authority itself generates another password.

5.4.5 PBA with a Second Authorisation Channel

This option can be made at least as secure as two passwords when it comes to the level of security for authenticating a user against a system. However, it also has the same disadvantage, namely that two servers must be involved in any verification of authentication information.

5.4.6 PBA with a second Authorization Channel and PKI.

This option also provides a high level of security, as in the case of two passwords. Furthermore, the verification of authentication information is easy, because of the PKI.

The e-VOTE consortium is capable of supporting password-based authentication with a second authorisation channel and PKI in the back end by including a signature server.

The signature server is actually split up in two different servers, allowing security on a level at least as high as for two passwords, when generating signatures.

In contrast to other models, a signature server logs all signatures, such that the number of authentication attempts can be centrally monitored. Because keys are generated and stored centrally, they will be strong and well protected.

As a second authorisation channel, the following is currently supported: A card with one-time passwords.

A mobile phone.

An electronic token, memorising one-time passwords.

Compared to two passwords and PKI in the back end, this is a better but also more expensive solution. If the voting keys must also be used for purposes other than voting, or if they must be used repeatedly and mobility is required or security requirements are particularly high, this solution looks very promising.

5.4.7 Chip Cards supporting PKI

With this solution, the chip card contains a secret key, which the voter can use by entering a password.

The security level is rather good but mobility is rather bad because readers must be installed at all computers from where votes can be cast.

If voters already are using chip cards for another purpose this is a good solution.

The e-VOTE consortium is capable of supporting chip cards.

5.4.8 USB Tokens supporting PKI

Like chip cards supporting PKI except that the mobility is better because USB 1.0 is supported by most hardware.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 81 of 188


Recommended if voters already have USB tokens integrated with the PKI to be used, if a relatively low number of voters vote regularly or if the voting keys must be used for other purposes also.

The e-VOTE consortium is capable of supporting USB tokens.

5.4.9 Authentication of Election Administrators

Security considerations are similar to those for the authentication of voters. However, some conditions may differ, leading to a different authentication model for election administrators. For example, in cases where only a few election administrators exist, per-unit costs are less important compared to one-time costs. Further, election administrators are more likely to operate the system from a secure environment only.

As a conclusion, chip-cards and USB tokens are more attractive compared to the options for the authentication of voters.

5.4.10 Authentication of Servers

Like authorisation of users and administrators, using a PKI is recommended. Servers differ from persons in the sort of authentication models. If the key of a server must be protected well, the key must typically be stored in a hardware box. The current position of the consortium is that the costs for supporting hardware boxes must be scheduled at a point in time closer to the start of commercial exploitation. Thus, this will not be pursued further in the design deliverables.

A web front end is a special case, since it will typically make use of SSL [ii] built into the web server rather than e-VOTE software for securing the communication with a web browser. A SSL server certificate must be issued, either from a public CA or a CA certified by a public CA.

5.4.11 Two Example Architectures

We provide two example architectures of a voting system. One with authentication based on two passwords used for issuing certificates and another using a signature server, in addition to the certification authority. The main difference between the two solutions seen from the voter’s point of view, is that with the first system (s)he receives two passwords for each election, which allows him(her) to vote from anywhere for each particular election. With the second alternative the voter receives credentials, which allows him(her) to vote again and again from anywhere. Some communication lines and tools, which are not essential for the understanding, have not been included in the description.

It should be noted that the architecture described first is the one complying with the user requirements for general elections; such elections are not frequent so it makes sense to give voters re-usable credentials. From a commercial point of view the second architecture may, however, be more promising, because it can be introduced together with other systems, which require security, and because the costs of each election are smaller than for the first one (voters need only be notified by one email, rather than by two physical letters).

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 82 of 188


Registration client CA

Webbrowser

Webserver

Messageboard

Tallyserver

Tallyserver

Administrativeclient

Voter

Decryption shares

Figure 21. Voting System Sketch

The above Figure shows a sketch of a voting system providing secrecy of votes, where voters receive two passwords for each election, which are then used for voting.

The CA server has been already implemented (not in the framework of the e-VOTE project), while the WEB browser can be any third party product. All the remaining servers depicted in the above figure will be implemented by the e-VOTE consortium.

We briefly list the main steps that must be carried out within different phases: when installing the e-voting system, before an election, during an election and after an election.

During installation: Two CAs are set up for certifying users and servers. Furthermore two LRAs (Local

Registration Authorities) are set up for registering users and servers manually at the CAs.

A SSL server certificate from a public CA is installed in the web server.

The individual servers of the voting system are set up. User accounts are made with user name and information allowing the system to identify the certificate of the users. The servers are registered with each other.

Just before an election: The central information about the election (e.g. the candidates available) is entered into

the system (possibly on the registration client or alternatively on the message board).

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 83 of 188


A new CA is set up for certifying the voters. Furthermore, a new LRA is set up in the certification authority for registering voters. This LRA is run from the registration client instead of the LRA application.

The registration client receives a list of voters. It registers the voters in the certification authority as well as on the message board.

Messages are sent to each voter from the registration client and the CA, respectively, by physical mail. Each of the messages contains a password (actually a password and a cryptic user identity).

The registration client creates the homomorphic voting key and sends:

o The public key to the message board, from where it can be fetched by the web server.

o The decryption shares to the tally servers encrypted under secret PKI keys of the tally servers.

The message board and the Web Server open up for voting when the time of the electronic election arrives.

During an election:

Each voter downloads an applet, allowing him/her to vote.

First the voter is asked to input his/her passwords.

In the applet, a public/private key pair is created together with a protected request for a certificate.

The protected request is returned to the web browser, which passes it on to the CA. The CA returns a certificate chain containing the certificate of the voter and of the CA as response.

The voter is asked to vote, i.e. to pick one out of a number of options.

The encrypted vote is created by the applet. Included in the vote message is the vote itself and a non-interactive zero-knowledge proof that it is an encryption of a legal vote.

The vote is signed.

The vote is sent to the web server, which logs it and passes it on to the message board.

The message board verifies the signature on the vote. If the signature is correct and is from an eligible voter who has not already voted, it proceeds; otherwise the vote is thrown away.

The message board verifies the proof that the vote is an encryption of a legal vote. If the proof is correct it proceeds; otherwise the vote is thrown away.

A receipt is returned to the voter.

After the election:

The message board multiplies the encrypted votes. This product is the encryption of the result of the election.

The encrypted result is signed by the message board and sent to the tally servers.

At each tally server, an election official determines whether or not to create a decryption share.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 84 of 188


The shares of those tally servers, which created a decryption share, are sent back to the message board. The message board combines the shares to get the clear text result.

The message board publishes the result of the election.

The homomorhic public key, the votes and the decryption shares are stored by the message board and can be used later for independent verification of the election.

The secret shares should as much as possible be deleted after the election is finished.

The next example architecture to be described involves a signature server. It is a more ambitious system, aiming at setting up credentials once and for all, such that voters can be notified by insecure email about each election, but still such that they can vote from any web browser. Further, with this system the keys and certificates can be used for other purposes, like securing email, also.

Voter

Decryption shares

CA

Tallyserver

Administrativeclient

Registration client

Webbrowser

Webserver

Messageboard

Tallyserver

Signatureserver

Figure 22. Voting System Sketch with Signature Server

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 85 of 188


We also briefly list the main steps, which must be carried out when installing the system, before an election, during an election and after an election. For this system there is a distinction between the first time a voter votes and later times the same voter votes. During installation:

Two CAs are set up for certifying users and servers. Further two LRAs (Local Registration Authorities) are set up for registering users and servers manually at the CAs.

The signature server is installed and set up. In fact a signature server must be distributed between two servers, a signature server and an authentication server when it is used in a high security context.

A SSL server certificate from a public CA is installed in the web server.

The individual servers of the voting system are set up. User accounts are made with user name and information allowing the system to identify the certificate of the users. Further the servers are registered with each other.

Just before an election:

The central information about the election (e.g. the candidates available) is entered into the system (probably on the registration client, it can also be on the message board).

If this is the first election, a new CA is set up for certifying the voters. Further a new LRA is set up for registering voters. This LRA is run from the registration client instead of the LRA application. Registration information is sent to the signature server, which also registers voters in the CA.

The registration client receives a list of voters. It registers the voters in the signature server as well as on the message board. The signature server registers the voters in the CA.

Messages are sent to each voter. Existing voters will only have to be notified by the registration client, possibly by insecure email. New voters have to receive credentials from the signature server by physical mail.

The registration client creates the homomorphic voting key and sends:

o The public key to the message board, from where it can be fetched by the web server.

o The decryption shares encrypted under secret PKI keys of the tally servers to the tally servers.

The message board and the Web Server open up for voting when the time of the electronic election arrives.

During an election:

Each voter downloads an applet, allowing him/her to vote.

The voter is asked to vote. i.e. to pick one out of a number of options.

The voter is asked for his/her credentials. Depending on whether this is the first time this voter votes, the credentials may be credentials for generating and/or activating his/her private key, or credentials for using his/her private key. Examples of credentials for using the private key are given in the section about password based authentication with a second authentication channel and PKI in the back end.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 86 of 188


The encrypted vote is created by the applet. Included in the vote message is the vote itself and a non-interactive zero-knowledge proof that it is an encryption of a legal vote.

The vote is signed.

The vote is sent to the web server, which logs it and passes it on to the message board.

The message board verifies the signature on the vote. If the signature is correct and is from an eligible voter who has not already voted, it proceeds; otherwise the vote is thrown away.

The message board verifies the proof that the vote is an encryption of a legal vote. If the proof is correct it proceeds; otherwise the vote is thrown away.

A receipt is returned to the voter.

After the election:

The message board multiplies the encrypted votes. This product is the encryption of the result of the election.

The encrypted result is signed by the message board and sent to the tally servers.

At each tally server, an election official determines whether or not to create a decryption share.

The shares of those tally servers that created a decryption share are sent back to the message board. The message board combines the shares to get the clear text result.

The message board publishes the result of the election.

The homomorhic public key, the votes and the decryption shares are stored by the message board and can be used later for independent verification of the election.

The secret shares should as much as possible be deleted after the election is finished.

5.5 Possible Extensions

In this section we list a number of options, which the e-VOTE consortium can potentially provide, but which have not been implemented and are not scheduled for implementation in the near future.

5.5.1 Protection of Voting Front Ends against Hackers

The voting front end is supposed to run in an applet on a web browser at the home or the working place of the voter. Thus it cannot be protected by a firewall etc.

Although it presents considerable difficulties, good protection can be achieved by suffering only a small decline in usability, through a mixture of technical solutions and administrative procedures. When this is however combined with the requirement for secrecy of votes, it becomes very processing power demanding, so an analysis of the voting scenarios in the individual solutions is necessary in order to determine whether it can be feasibly applied for each particular voting solution.

5.5.2 Protection against Vote Buying (1)

In this case as well the voter is supposed to vote from home or from his/her working place. The kind of attacks we address here are attacks where a third person looks “over the shoulder”

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 87 of 188


of the voter when he/her votes.

This can be part of vote buying, but also it can occur if for example a husband or employer looks over the shoulder during the voting process.

Again a solution can be implemented as a mixture of technical and administrative features. We refer to it as the Høje Tåstrup model [xxxiii]. The basic idea is that there will be a slip in time after the electronic election, where it is possible to replace the electronic vote by a manual vote. Thus voters, who have felt intimidated during the electronic voting process, can go to a voting site and change their vote.

5.5.3 Protection against Vote Buying (2)

Ιn this section we address the following attack: A vote buyer produces an encrypted vote, which is distributed electronically. Further he/she distributes an application for signing votes, which the vote sellers can use to sign the vote and pretend that it is their own.

This vote buying attack is rather strong when secrecy of votes is applied, because the vote sellers need not know, which candidate or party they sell their vote to. Thus it is easier to get away with than traditional vote buying. Furthermore, it is easier to produce documentation that the vote sellers actually voted as prescribed. (Their votes are publicly available for independent verification.)

The situation for this attack is as follows (provided that we are careful with the handling of user seed for the non-interactive zero-knowledge proofs):

With the protocol for producing secret votes, the message board will discover this attack and throw out sold votes.

If protection against vote buying 1 is implemented, vote sellers will be unable to prove that they voted as desired.

5.5.4 Additional Performance for secret Votes

The performance demanding tasks are the production of the proofs that votes are correct on the voter’s web browser and in particular the verification in the message board, that the proofs are correct.

In order to scale properly, pre-message boards can be introduced. There can be as many pre-message boards as desired. Each pre-message board is used for verifying proofs of votes. After a successful verification, the pre-message board adds a signature on the vote, which the message board will then use as evidence that the vote is correct.

Notice that in this way, in order to scale up beyond the performance offered by a single computer, only very simple applications need run in parallel. In particular a complicated synchronization of databases is not necessary.

It is of course more attractive to improve the performance of the voting protocol. Performance improvements of the voting protocols will thus be pursued first.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 88 of 188


5.6 e-VOTE Prototype 1 architecture

The e-VOTE Prototype 1 will make use of the Damgaard-Jurik-1 voting protocol [xxii] with secrecy of votes and cryptographic support with 1024 bit RSA keys. Voters will generate private 1024 bit RSA keys that will be used for signing votes.

The architecture presented in Figure 22 will be used. The main missing features, which make it a prototype rather than a pilot, are:

Instead of an e-VOTE registration client an existing registration client will be used. Furthermore, a simple-minded executable for generating the voting key and the secret shares will be developed. The shares will be protected with passwords.

Instead of the message board and the tally servers, an executable performing the counting and share decryption will be utilised.

Generation of ballots etc. will not be supported through a Graphical User Interface (GUI). Instead a lot of information will be hard-coded.

Data will be stored in files rather than in a database.

Administrator roles have not been defined and administrators do not possess authentication means.

Therefore the first prototype will allow voters to vote using the correct protocol, without imposing any restrictions on the web interface. However, only a minimum of administrator tasks and procedures will be available for testing.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 89 of 188


6 e-VOTE Services Scenarios and Definitions

6.1 Introduction

Electronic government (or e-government) is the use of technology in order to enhance the performance of the government, aiming to improve the delivery of services and information to the citizens. It offers them continuous access to government information and services, ending the long lines at government offices and eliminating the need to fill out paper forms.

Electronic Democracy (or e-Democracy) systems, which may in turn be viewed as parts of e-Government systems, form a broad class of systems related to public services targeted at informing citizens on political issues. Such systems may also cater for online discussions between citizens, possibly involving politicians too. These systems may also include mechanisms for online polls, which may be used for conducting informal surveys, without seeking a high level of accuracy of the result.

Online voting systems are much more formal than online polling systems, because they seek (or should seek) to accurately reflect the voters’ preferences. In this context, electronic voting is the most eminent expression of electronic democracy, facilitating the citizen’s active participation in important decisions. The ideal participation model would be a distributed one, in which an interconnected voter expresses her/his opinions in an accurate and secure manner.

However, increased user interconnectivity and mobility, as well as reliance upon electronic communications means that more information is being transmitted electronically, so that more information is becoming vulnerable to attacks such as eavesdropping, non-authorised modification and masquerade.

The following user requirements have been identified for the e-VOTE system: authorisation, ease of use, friendliness, performance, reliability, availability, robustness, privacy, security, auditability, trust enhancement. These requirements lead to a list of services that the e-VOTE system must support. The services are the link between the user needs and the functions of the e-VOTE system.

In the following sections, classification schemes of e-VOTE services are given and two scenarios of possible interaction are examined. The variable that differentiates the scenarios and hence the required services, is the type of the communicating entity (actor).

6.2 Classification of e-VOTE services

6.2.1 Introduction

In general, e-VOTE services can be classified into the following categories:

Primary services, which are mandatory for participation, completion and verification of the election process45

Secondary services, which are minor or rarely used system functions

45 It should be noted that the characterisation of a service as primary, secondary or optional heavily depends on the election type the particular service supports (for instance, the authentication service is a primary requirement for general elections, whereas it is an optional one for polls).

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 90 of 188


Optional services, which may not be implemented.

Furthermore, two additional considerations can serve as the basis for classifying further the provision of e-VOTE services – namely, the e-VOTE services can be classified according to:

The nature of the requested service, and

The system phase (namely Set-up, Election in progress, Election Concluded), during which the service is rendered.

6.2.2 Service classification according to the nature of the service

The e-VOTE system will provide services fulfilling to the user requirements captured in Chapter 3. Thus, the e-VOTE system deals with two different kinds of actors: voters, and election organisers. The latter have the ability to influence the e-VOTE system state in the Election in Progress phase, under certain conditions.

Therefore, two fundamental types of interaction are defined:

Voting services provision takes place between voters and the e-VOTE system. It is an interaction where the legitimate voter participates to the election process, facilitated by the e-VOTE system.

Election management operation takes place between election organisers and the e-VOTE system. Initiated by the election organisers, a management operation modifies and/or verifies a certain aspect of the e-VOTE system behaviour.

6.2.3 Service classification according to the system phase

The e-VOTE system will provide services before, in the course of, or after, the election process phase, depending on the type of service offered. This means that e-VOTE services can be classified as prior to the election process (Election Set-up phase), in the course of the election process (Election in Progress phase), and after the election process (Election Concluded phase).

Set-up phase: only the election organisers should have access to the e-VOTE system prior to the election. Election organisers set up the e-VOTE system and the supporting components.

Election in progress phase: the entities accessing the system are mainly the voters, which authenticate themselves to the e-VOTE system, may receive election-related information and finally cast their votes. Election organisers would access the system typically for starting/ending the election and, under special conditions, modify parts of the system in a controlled way.

Election concluded phase: only the election organisers should have access to the e-VOTE system after the election conclusion, for tallying the votes, verifying the result integrity and publishing the results.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 91 of 188


6.3 e-VOTE interaction scenarios

In order to consider the various options for the services that the e-VOTE system will offer, two scenarios of possible interactions are examined in this section. The variable that defines the scenarios hence the services needed in each, is the type of the communicating entities (i.e. voters, and election organisers). It should be noted that security features should be embodied into the services, where necessary.

The services that are required in each scenario depend on the nature and on the sensitivity of the information to be communicated.

6.3.1 Voter – e-VOTE system

Voters exchange information with the e-VOTE system during the election process in order to cast their vote. The most typical information exchanges are:

Access to the virtual voting place: a voter connects to the e-VOTE system (typically a web site) through a networked workstation.

Voter authentication: a voter presents her/his credentials to the e-VOTE system.

Vote cast: a voter is presented with a paper-like ballot representation and casts her/his vote.

Vote casting receipt: a voter receives a receipt for the vote s/he cast and walks away. It should be noted that the vote casting and receipt delivery should ideally be carried out by a single action of the voter (“push-button vote”).

Election result information obtaining: a voter accesses a public information delivery system (typically a web site) to obtain information about the election result.

6.3.2 Election Organiser – e-VOTE system

The most representative case to describe this scenario, is an election organiser who prepares the system for an election. The various types of information exchanged between an election organiser and the e-VOTE system are:

Election data management during the Election Set-up phase: the election organiser has the ability to perform operations such as the management of election districts, election units, parties, candidates and voters, the provision of election parameters as well as the provision of authentication means to voters and election organisers. (S)he can also preview ballots according to the available parties/candidates/districts information, and provide party information. All the above actions are performed after successful authentication to the e-VOTE system.

Controlled system alteration during the Election in Progress phase: election organisers may, under special conditions, alter certain characteristics of the system; for this purpose, an additional group authentication procedure is required before one is allowed to perform a subset of the functions available to election organisers during the Election Set-up phase.

Modification of the system state: the election organiser should be able to start / stop the election.

Tallying of the election result: after the end of the Election in Progress phase, the election organiser tallies the votes cast

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 92 of 188


Publish the result: the election organiser publishes the election results.

Election result assurance: the election organiser provides reasonable assurance concerning the accuracy, privacy and integrity of the election.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 93 of 188


7 e-VOTE Services

7.1 From scenarios to e-VOTE services

The services that the e-VOTE system will support must be derived from the scenarios described in the previous Chapter. The scenarios have been classified according to the various types of the transacting parties. Accordingly, the service requirements have to be examined with respect to the type of the transacting actor, be it a voter or an election organiser.

Finally, there are also several non-functional requirements that the e-VOTE system must support, which do not depend on the type of the transacting parties, but rather support the trust and the functionality of the e-VOTE system as a whole, and apply to all the examined scenarios. These services are related to security, ease of use, performance, availability, reliability, audit and trust enhancement services, and will be examined in the next section.

7.2 e-VOTE Services and Service Blocks

The user requirements mentioned in Chapter 3 (E - Vote Requirements Specification) and the scenarios described in Section 6.3, have led to a list of services which the e-VOTE system must support. These services are the link between the user needs and the functions of the e-VOTE system. The services are divided logically in two levels:

e-VOTE Services (or First Level Services), which are groups of related services at a higher abstraction level, that the potential actor sees as a distinct operation; and

e-VOTE Service Blocks (or Second Level Services), which are the building blocks the e-VOTE Services are built upon. The Service Blocks are not necessarily visible to the potential actor and are strongly related to non-functional requirements.

In the following, the e-VOTE Services and the e-VOTE Service Blocks will be referred to, for simplicity, as Services and Blocks respectively.

The e-VOTE User Requirements as defined in Chapter 3, imply that the required services should adhere to certain restrictions. As an example, the user requirement “No one can duplicate or change his or someone else’s vote” implies the existence (and use) of integrity mechanisms in order to ensure message accuracy, etc. In the following, the described services make use of such mechanisms, which, in turn, (may) imply the existence of certain frameworks/infrastructures (i.e. the use of digital signatures as an integrity check enabler may imply the existence of public/private key pairs assigned to entities such as voters and functional entities of e-VOTE, a PKI infrastructure, etc.).

In the following paragraphs, a description of the aforementioned e-VOTE services is given. From a functional point of view, both physical entities communicating with the system (i.e. voter, general public, key actor, etc.), and functional components of the e-VOTE system, will be referred to as functional entities (or simply entities) interchangeably, unless explicitly stated otherwise. This clarification is necessary, since even a physical entity (e.g. a voter) interacts with the system via a well-defined functional unit (i.e. in case of a voter, the voting functional unit), providing the physical entity with the necessary facilities to fulfil her/his goal. Thus, the functional unit interacts with the e-VOTE system on behalf of the physical entity.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 94 of 188


Figure 23 depicts the relationship between e-VOTE Services and e-VOTE Service Blocks. The reader should note the fact that a single Service Block may provide services to more than one Service.

Figure 23. e-VOTE Services and Service Blocks

7.3 e-VOTE Services

In order to support the interaction with a voter, the e-VOTE system must support the following services:

Registration, in order to obtain a unique identity and initiate her/his secure interactions with the system. It should be noted that, in the context of Prototype 1, the voters might not be registered through the e-VOTE system itself.

Authentication, in order to provide controlled access to the system with appropriate rights, through a strong access control scheme.

Voting, for exercising the right of participation to the democratic process and anonymous opinion expression. It also includes the election participation receipt, in order to ensure that the voter can undoubtedly prove her/his participation to the election.

Election result verification, in order to have the ability to assure (the voter himself, or by trusting other parties, as independent verifiers) the election accuracy, anonymity and integrity.

In case the transacting entity is an election organiser, the services derived from the described scenarios are:

Registration, in order to obtain a unique identity and initiate her/his secure interactions with the system. It should be noted that, in the context of Prototype 1, the election organisers might not be registered through the e-VOTE system itself.

Authentication, in order to provide controlled access to the system with appropriate rights, through a strong access control scheme.

Election data management, in order to facilitate the election set-up process during the Election Set-up phase.

System state modification, in order to facilitate the starting and ending of the Election in Progress phase.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 95 of 188

e-VOTE Service Block

e-VOTE Service





e-VOTE Service


Exception mechanisms, in order to facilitate the controlled alteration of the system during the Election in Progress phase.

Election result tallying, in order to provide the election result and to publish it.

Election result assurance: in order to allow the election organiser to provide reasonable assurance concerning the accuracy, privacy and integrity of the election.

7.4 e-VOTE Service Blocks

e-VOTE Service Blocks are the building blocks that e-VOTE Services are built upon. They are services of a lower level, which are not always visible to the user of the system; nevertheless, their correct function is vital for the proper operation of the e-VOTE system. Some of them are essential on their own (i.e. Cryptographic Facilities), whereas other play significant role in operations of a higher level (i.e. Authentication in order to provide the Voting Services). A Service Block may participate in more than one combination of actions in order to provide a service of the same or higher level. Service Blocks are related to the non-functional (NF) requirements identified in Chapter 3.

The following e-VOTE Service Blocks have been identified:

Cryptographic Facilities, which are related to the Security non-functional requirement and are divided into two distinct categories:

o Digital Signatures. In order to satisfy the message authenticity and integrity user requirements, the e-VOTE system should offer digital signature services. The provision of digital signatures implies the existence of a Public Key infrastructure (PKI).

o Encryption. The security requirements on the information exchanged with(in) the e-VOTE system are confidentiality, integrity, time-stamping and non-repudiation. The relevant e-VOTE services are likely to be performed in a series of actions where encrypted information will be digitally signed and time-stamped. The cryptographic systems employed may cover one or more of the relevant issues (hashing, digitally signing, encrypting, recovering and exchanging keys, etc.).

Actor Interfaces, which are related to the Usability non-functional requirement. Actor interfaces are presentation elements, which facilitate actor interaction with the e-VOTE system. These elements typically are part of another service (e.g. authentication, election data management etc), and they should be unambiguous, easy to use even by a non-computer literate person, guide the actor through a well-defined interface which simulates a familiar, real-world election process, and finally, provides for comprehensive help when necessary.

Trust Enhancement Mechanisms, which are related to the Public Trust non-functional requirement and aim to promote the confidence of the general public, in the accuracy and integrity of the election process. Trust enhancement mechanisms may use other Service Blocks (i.e. Cryptographic Facilities).

Logical Cohesion Mechanisms, which support the Security and Availability non-functional requirements. These mechanisms check the data entering the e-VOTE system for their logical cohesion (e.g. the date of the election is in the future). Furthermore, these mechanisms handle unexpected input to the system, in order to safeguard the e-VOTE normal operation.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 96 of 188


Infrastructure-related Mechanisms, which are related to the Performance and Reliability non-functional requirements and aim to establish a stable environment within which e-VOTE operates; interoperability with other applications/systems, as well as availability and robustness against intentional or unintentional actions/events, are the main objectives of this Service Block.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 97 of 188


8 e-VOTE Prototype 1: Overview

This Chapter summarises the extend to which the different use cases and their according user/functional requirements, described in Chapter 3 (E - Vote Requirements Specification), were implemented in the first prototype of the e-VOTE system. With respect to the functionality provided by prototype 1, some use cases will either be partially implemented or not implemented at all. The functionality of these use cases will be implemented in Prototype 2 and/or in the e-VOTE Pilot system.

For clarification, the use cases that will be implemented in prototype 1 are indicated in Table3. Please note that a “Partial” indication in the “Implementation Extent” field denotes that the implementation of the respective user/functional requirements will be improved in subsequent phases (Prototype 2 & Pilot), whereas “N/A” (Non Applicable) indication denotes that the implementation of the respective user/functional requirements will be postponed for subsequent phases (Prototype 2 & Pilot).

Use Case Name Implemented in Prototype 1 Implementation Extent

Authenticate Actor YES Partial

Authenticate Key Actors NO N/A

Modify System State NO N/A

Manage Election Districts

NO N/A

Manage Election Units NO N/A

Provide Election Parameters

YES Partial

Manage Voters YES Partial

Provide Authentication Means

YES Partial

Manage Parties NO N/A

Manage Candidates YES Partial

Preview Ballots YES Partial

Provide Party Info NO N/A

Cast Vote YES Partial

Tally Votes YES Partial

Verify Result Integrity YES Partial

Table 3: Use Cases implementation in Prototype 1

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 98 of 188


Furthermore, the use cases are categorised with respect to the system phase in which they are activated (namely, Election Set-up, Election in Progress and Election Concluded system phases, or Election Set-up, Voting and Tallying phases respectively). In exceptional cases, some of the election set-up use cases can also be performed after properly authorised actors have been authenticated using the “Authenticate Key Actors” use case. The categorisation of use cases according to the system phase activation is depicted in Table 446.

Section Use Case NameActive In System Phase

Election Set-up

Election in Progress

Election Concluded

3.1.1.1 Authenticate Actor

3.1.1.2 Authenticate Key Actors

3.1.1.3 Modify System State47

3.1.1.4 Manage Election Districts

3.1.1.5 Manage Election Units

3.1.1.6 Provide Election Parameters

3.1.1.7 Manage Voters


3.1.1.9 Manage Parties

3.1.1.10 Manage Candidates

3.1.1.11 Preview Ballots

3.1.1.12 Provide Party Info

3.1.1.13 Cast Vote

3.1.1.14 Tally Votes


Table 4: Categorisation of Use Cases according to system phase activation

46 The “” indication denotes election set-up use cases which can be performed during “Election in Progress” phase, after properly authorised actors have been authenticated using the “Authenticate Key Actors” use case

47 The system transition from one state to another is deemed to be the first and last, respectively, actions of the Election in Progress system phase

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 99 of 188


9 e-VOTE Prototype 1: Methodology of Trials

This Chapter provides the organisational and implementation plan of the e-VOTE prototype 1 trials round. The trials consist of several test cases aiming to evaluate the functionality supported by the “System Under Test” (SUT) --e-VOTE prototype 1. Its evaluation is done in accordance to the quality components and metrics specified in the e-VOTE Quality Strategy (WP5). Apart from the specific objectives and expectations of the trial round, the tests provide valuable feedback to the system designers and developers, as well as to the Quality Strategy itself.

9.1 Methodology of Trials

9.1.1 Trials Coverage

Taking into account the inherent complexity of the e-VOTE system, in terms of supported functionality, and thus the difficulty to design a full “Test Suite” for the trials, the consortium has adopted the classification methodology of ISO 9646 as a guideline for the specification of a fair number of tests.

Specifically, according to the ISO Testing Standard (ISO 9646) terminology three classes of tests are defined:

Basic Tests (BT) : a small number of tests (1 or 2) aiming to demonstrate that the system has been correctly installed. It is not feasible to perform other tests if any of the Basic Tests fail.

Capability Tests (CT) : a moderate number of tests, aiming to demonstrate the ability of the System Under Test (SUT) to perform basic sets of functions.

Behaviour Resolution Tests (BRT) : tests aiming to verify that the System Under Test behaves correctly under a wide range of situations, determined by several different factors. Such factors can be protocol options, parameters, execution patterns, etc. Behaviour Resolution tests fall in two sub-categories:

Valid : as the name suggests, these tests verify the correct behaviour of the System Under Test under legitimate conditions (event sequences, parameter values, etc.).

Invalid : these tests verify that the System Under Test acts “as it should” under circumstances such as unexpected events, parameters out of range, invalid or unsupported options, negotiation failures and invalid combinations of parameters.

9.1.2 Criteria for Trials Specification

The first round of trials includes the appropriate number of representative tests for evaluating the technical and organisational characteristics of the system. The precise specification of each test case has been based on the guidelines of Section 9.1.1 and on the technical, organisational and financial evaluation criteria presented in Section 2.3 of deliverable “D1.2: Detailed Project Plan - Scale and Methodology of Trials”.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 100 of 188


Specifically the trials suite consists of:

Some simple Basic Tests (BT) performed by the e-VOTE system developers in order to ensure that the “System Under Test” has been correctly installed.

a fair number of Capability Tests (CT) for validating predetermined system functionality. Depending on the “Trial Parameters” (Number of Participants, Participant Characteristics, refer to Table 5), the same Capability Tests have been performed more than once (in the two pilot sites - ESSEN and AEGEAN).

a fair number of Valid and Invalid Behaviour Resolution Tests (BRT) for observing the system behaviour during extreme or invalid use scenarios. Special emphasis, through this group of tests, has been given to the verification of the voting protocol integrity.

9.2 Testing Procedures

9.2.1 Test Environment and Resources

9.2.1.1 Pilot/Prototype Set Up

During this first round of trials, the pilot sites were:

University of Essen and

University of the Aegean

The “System Under Test” (e-VOTE prototype 1) has been set up in accordance to the standard requirements and the capacity for a successful testing procedure. All configuration options were activated in order to select the maximum variety of services during the evaluation.

9.2.1.2 Hardware & Software

Before the trials the hardware and software of the “System Under Test” has been recorded and documented in a Test Environment form. Furthermore it has been assigned an Environment Identification Code (EIC).

The e-VOTE prototype 1 servers were located at the premises of Quality and Reliability in Greece and were accessed by the two Universities through the internet.

9.2.1.3 Participants

Test participants were persons (engineers) involved in the development of the prototype 1 system (mainly during the Basic Tests - BT), students from the Computer Science Department of the University of Essen and legal experts. The necessary corrective actions have been taken ensuring that the evaluation objectives were met.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 101 of 188


Basic Tests (BT) Capability Tests (CT) Behaviour Resolution Tests (BRT)

Objectives Ensure that the system has been

correctly installed

Ensure that the system performs correctly a

predetermined set of functions

Observe system behaviour while modifying its

functional parameters or simulating invalid / extreme use cases

Evaluation CriteriaTechnical

N/A

a) Conformity with User Requirements and Functional Specifications

b) System performance (limited for Round 1)

a) Same as CT but in the context of the BRT objectives

b) Voting Protocol Integrityc) System Performance

(limited for Round 1)Organisational

N/A

a) Compliance with Legal and Constitutional requirements

b) System scalability (N/A for Round 1)

c) User-Friendliness (N/A for Round 1)

d) Compliance with Sociological and Behavioral Requirements (N/A for Round 1)

N/A

Financial N/A Cost Parameters (N/A for Round 1)

N/A

Trial ParametersType of Voting

Procedure 48POLL

Number of Participants

Less than 10 Maximum number of Users: 100

From a few tenths to several hundreds

Participant Characteristics

Engineers and developers of the e-VOTE consortium

a) Computer Science Students b) IS security engineersc) Legal Experts

Expectation Obtain a system capable to

accommodate the designed trials (CT & BRT)

a) Validate system functionality

b) Identify problems / deficiencies

c) Produce a system evaluation report

a) Validate system behaviour under a wide range of use scenarios

b) Identify problems / deficiencies

c) Produce a system evaluation report.

Table 5: Criteria for Trials Specification

48 A definition - description of each voting procedure can be found in Chapter 3 or in the project deliverable D3.1: “User Requirements : Prototype 1”

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 102 of 188


9.2.2 Test Case Steps

Information specific to each Test Case has been explicitly documented (purpose, set-up characteristics, procedure followed, etc.) through the Test Case Form. Furthermore, each test case has been assigned a unique decimal Test Case Identification Code (TCIC), followed by the test case version identification number. In order to resolve interoperability problems the EIC will be utilised for tracing the test environment.

Depending on the test case type and objectives the validation - evaluation of the “System Under Test” has been based on both Software Based Tests and on Tests with the involvement of Real Users.

9.2.2.1 Software Based Tests (SBT)

Before involving real users in a trial it is necessary to ensure that the system under test performs correctly. For instance, it is unavailing to initiate a validation-evaluation session with real users if:

The system interfaces do not display correctly

There are hardware, communication or software problems

The system does not count votes correctly

Several users can not be supported concurrently

The system becomes unstable or its performance deteriorates when a large number of users try to cast their votes over a short period of time.

It becomes apparent that there are system properties, like load performance test, stress testing, response time under high load, maximum number of supported concurrent users etc, that can only be tested through a high number of concurrent users.

Since this is unrealistic with real users, the consortium has overcome this problem through the implementation of Software Based Tests (SBT), which facilitate the creation of as many virtual users as necessary for testing a specific system property or function. Under no circumstances a test with real users can be carried out if the e-VOTE prototype fails in any of the software based tests.

9.2.2.2 Tests with Real Users (RUT)

The tests based on the participation of Real Users (RUT) have been conducted through the following steps:

9.2.2.2.1 Step 1: Initial Meeting

Prior to the test it is important to brief the users about the characteristics and goals of electronic voting in general. Furthermore, it is necessary to present the e-VOTE project with special emphasis on the characteristics and functionality of the prototype system under test. The aim of the meeting was to motivate the users by making them realise the benefits of the system and the importance of the tests. A final objective of the meeting was to arrange a timeplan for the tests, ensuring the availability of all users.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 103 of 188


9.2.2.2.2 Step 2: Pre-Test Questionnaire

Prior to the test each user was asked to fill in a Pre-Test Questionnaire. The purpose of this questionnaire was to collect statistical information about the test participants, their normal voting behaviour and their expectations from an internet based electronic voting system.

The Pre-Test Questionnaire was available on-line, as HTML pages (http://www.wi-inf.uni-essen.de/~ifs/platform/questionnaires/pre_test/page1.php), and the answers were automatically stored in a database for easing their processing and evaluation tasks. Please refer to Section 18.1 (Pre-Test Questionnaire) for the final version of the questionnaire used during the validation of the first prototype.

The users after having completed the questionnaire were provided with the link to the e-VOTE prototype 1 system (https://phobos.instore.gr/evote/vote.html).

9.2.2.2.3 Step 3: Test of the e-VOTE prototype

The users interact with the e-VOTE prototype according to the specifications of the test case. After having cast their vote the users were provided with the link to the Post-Test Questionnaire (see next step).

9.2.2.2.4 Step 4: Post-Test Questionnaire

Similarly to the Pre-Test Questionnaire, the users were prompted to answer the Post-Test Questionnaire. The purpose of this second questionnaire was to record the user experiences with the system, their comments/criticisms and finally any problems/deficiencies that were identified.

The Post-Test Questionnaire was available on-line, as HTML pages (http://www.wi-inf.uni-essen.de/~ifs/platform/questionnaires/post_test/page1.php), and the answers were automatically stored in a database for easing their processing and evaluation tasks. Please refer to Section 18.2 (Post-Test Questionnaire) for the final version of the questionnaire used during the validation of the first prototype.

9.2.2.2.5 Step 5: Conclusion Meeting

Having completed all the above steps the test participants met again discussing their experiences and possible problems but also expressing their personal comments and suggestions for the system.

The aim of this conclusion meeting was to collect from the test participants information that was difficult or even impossible to get through the questionnaires.

9.2.2.2.6 Step 6: Evaluation and Test Case Report

The last step of each test case was the evaluation of the results by processing the information collected through the questionnaires and the conclusion meeting. Depending on the evaluation corrections/modifications/improvements to the system may be decided.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 104 of 188

http://www.wi-inf.uni-essen.de/~ifs/platform/questionnaires/post_test/page1.php

http://www.wi-inf.uni-essen.de/~ifs/platform/questionnaires/post_test/page1.php

https://phobos.instore.gr/evote/vote.html

http://www.wi-inf.uni-essen.de/~ifs/platform/questionnaires/pre_test/page1.php

http://www.wi-inf.uni-essen.de/~ifs/platform/questionnaires/pre_test/page1.php


10 Description of Basic Tests (BT)

This Chapter describes the Basic Tests that were conducted during the first round of trials (e-VOTE prototype 1).

The information provided through the first row of each “test case table” is as shown below:

Identifies the “Pilot Site” and the “Trial Round”

(Prototype 1 / 2 and Pilot system)

This is the test case code, where:BT: Basic TestCT: Capability TestΒRΤ: Behaviour Resolution TestSBT: Software Based testRUT: Test involving Real Users

ESSEN-PR1 Basic Test: BT-1

while the rest of the table provides the objectives, the trial parameters and the expectations for the specific test case.

Since the e-VOTE prototype 1 system was installed at the premises of Quality and Reliability (the two pilots were accessing the system through internet), the Basic Tests were performed there by e-VOTE developers and engineers from Quality and Reliability (Q&R) as well as by security experts from Cryptomathic (CRM).

10.1 Testing the Stand-alone Operation of e-VOTE Prototype 1 Modules

Q&R-PR1 Basic Test: BT-0001-1

Objectives Validate the correct behaviour of prototype 1 stand-alone modules

Trial ParametersType of Voting Procedure Internal (University of Essen) Poll

Number of Participants Less than 10Participant Characteristics Engineers and developers of the e-VOTE consortium (from Q&R and

CRM)

Expectation Validation of the independent system modules

Module tests were done automatically, verifying that stand-alone modules in the system are behaving as expected. The following table serves as an overview of test cases covered by the module tests

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 105 of 188


TCIC : BT-0001-1-1

Name Date EIC Tested ByVoting functionality module test.

27/05/2002 -- CRM

Purpose

Verify that the toolkits for homomorphic encryption and signature generation/verification perform correctly.

Set Up

Test program. Remember to use the correct version of crmjniev.dll and of the java classes.

Expected Results

Only informative messages are written on the screen.

Schematic overview of the module test:

No Property tested Test Program Be sure to check Modules

1. An election can be generated together with shares.

ElectionTest.java Jserver

2. A vote can be generated using the data form the election generation. (Interoperability between JAVA and C Toolkits.)

ElectionTest.java java_for_browsers

Jserver

3. Votes can be counted using the JAVA toolkit. Correct votes are accepted.


4. A decryption share can be generated of the product of votes from 3.


Jserver

5. The decryption shares can be combined to a decrypted result.

ElectionTest.java The result written on the screen must be correct. Currently candidate nr. 1 gets 3 votes and no other candidate is voted for.

Jserver

6. Up-time and rarely occurring bugs.

ElectionTest.java 1000 full elections (with 3 voters) must be tested in the same program session.

java_for_browsers

Jserver

7. Up-time and rarely occurring bugs.

ElectionTest.java Three elections with 300 voters must be tested in the same program session.

java_for_browsers

Jserver

8. Multithreading properties of native code.

ElectionTest.java 10 concurrent sessions must run correctly for 8 hours using the same instance of the library.

Java_for_browsers

Jserver

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 106 of 188


10.2 Manual Inspection of Messages


Objectives Manual Inspection of prototype 1 Messages



CRM)

Expectation Verify Security Properties

The manual inspection of messages primarily aims to ensure that the security properties are as expected. For instance that the intended encryption algorithms are used with the intended key lengths.

TCIC : BT-0002-1-1

Name Date EIC Tested By

Check key shares 27/05/2002 -- CRM

Purpose

Check that the decryption shares are protected under passwords using a very strong encryption. (Otherwise the key shares could be broken with time)

Set Up

Module test

Expected Results

The message must be on PKCS8 format. The key derivation function must be PKCS5-PBKDF2 over 256 bit AES keys generated using the PKCS5-PBES2 key derivation scheme. The number of iterations must be 6000 and the encryption function must be AES cipher block chaining with a 256 bit AES key.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 107 of 188


TCIC : BT-0002-1-2

Name Date EIC Tested ByCheck voting key length.

27/05/2002 -- Q&R

Purpose

Make sure that the strength of the encryption of votes is no less than desired.

Set Up

Inspect the Election structure using a tool capable of decoding ASN.1 messages. For example the dumpasn1 freeware tool.

Expected Results

The length must be 1024 bits or the bit length set by the user in the GUI.

10.3 Verify that the System has been Set-Up correctly


Objectives Ensure that the e-VOTE prototype 1 system has been correctly installed



CRM)

Expectation Set-up and initialise the e-VOTE Prototype 1 system

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 108 of 188


10.3.1 Check Application Server

TCIC : BT-0003-1-1


Check Application Server

27/05/2002 BT-0003-1-E1 Q&R

Purpose

Check that the Application Server is running.

Verify that the e-VOTE application is up.

Set Up

Open the browser and type the following URL https://phobos.instore.gr/evote/vote.html

Expected Results

The authentication screen appears and the user is prompted to enter his User Number.

At the same time the applet is loaded to his browser and a message appears at the bottom of the browser indicating that the Vote applet has started.

EIC: BT-0003-1-E1

Hardware Software

Item Description Item Description

PC PC Workstation Internet Browser MS Internet Explorer Netscape Navigator

Internet Connection Modem Required Java Plug in Browser Plug in to run Java Applets.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 109 of 188



10.3.2 Check Database Server

TCIC : BT-0003-1-2


Check Database Server

27/05/2002 BT-0003-1-E2 Q&R

Purpose

Check that the Database Server is running.

Verify that the e-VOTE application is up.

Set Up

Open the browser and type the following URL https://phobos.instore.gr/evote/setup.jsp.

Insert all the election parameters into the input boxes.

Press Save.

Expected Results

If the parameters entered were in correct format, a new record is generated into the database holding the election information.

EIC: BT-0003-1-E2

Hardware Software



Internet Connection Modem Required RDBMS Oracle 9i.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 110 of 188

https://phobos.instore.gr/evote/setup.jsp


10.4 Verify that the System Operates


Objectives Perform some preliminary manual tests (in relation to the functionality supported by prototype 1) for ensuring that the e-VOTE prototype 1

operates as expected


Number of Participants Less than 10Participant Characteristics Engineers and developers of the e-VOTE consortium (from Q&R)

Expectation Validate that the e-VOTE Prototype 1 SUT is capable to accommodate the specified CT and BRT

10.4.1 Authenticate Actor

TCIC : BT-0004-1-1


Authenticate Actor 27/05/2002 BT-0004-1-E1 Q&R

Purpose

Provide access to the system functions in accordance with the authorisation level (privileges) of the actor.

Set Up

Connect to the application and enter the User Number in the box provided.

Press the Authenticate button to continue the process.

Expected Results

1. If the User Number entered was valid (checked at the INCA database) the result will be a screen that shows the ballot to continue the voting process.

2. If the User Number was invalid the result will be a screen showing an authentication error and a link to return to the authentication screen.

Notes

When you press the Authenticate button you will notice a screen notifying you that your User Number is being checked and the result will appear on the next page.

EIC: BT-0004-1-E1

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 111 of 188


Hardware Software




10.4.2 Provide Election Parameters

TCIC : BT-0004-1-2


Provide Election Parameters

27/05/2002 BT-0004-1-E2 Q&R

Purpose

Specify various parameters for the election that is going to take place.

Set Up

Connect to the application to enter the Election parameters. Insert the following fields into the input boxes:

Election Name – Maximum Number of Voters – Number of Shares – Tolerable Number of Cheating Servers - Candidates (See BT-0004-1-5)

Press Save.

Expected Results

1. If the parameters entered were in correct format (ex. Numeric) a screen appears informing the user that the election setup was completed successfully.

2. If the parameters were entered incorrectly a screen appears listing all the possible errors associating with the parameters entered (ex. Number of Voters is not Numeric). A link returns you to the Election Setup Page to restart the procedure.

Notes

When the process finishes correctly, the election parameters are stored on the database to be used for future process.

EIC: BT-0004-1-E2

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 112 of 188


Hardware Software



Internet Connection Modem Required

10.4.3 Manage Voters

TCIC : BT-0004-1-3


Manage Voters 27/05/2002 BT-0004-1-E3 Q&R

Purpose

Import and delete voters’ list for the election procedure and store it in a secure way.

Set Up

Connect to INCA server (Certificate Server).

1. Use the enrollment tool to import the list of voters into the INCA database.

2. Use the Registration Manager to view and delete the users from the database. Select a user and press Delete.

Expected Results

1. The INCA server inserts the voters’ data into the database (Oracle).

2. The user is deleted from the database.

Notes

For Prototype 1 the minimum information provided for the voter consists of username and e-mail address.

EIC: BT-0004-1-E3

Hardware Software


PC PC Workstation RDBMS Oracle 9i

JDBC Java Libraries

InCA Certificate Cryptography Server

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 113 of 188


10.4.4 Provide Authentication Means

TCIC : BT-0004-1-4


Provide Authentication Means

27/05/2002 BT-0004-1-E4 Q&R

Purpose

Create and distribute authentication means to voters

Set Up

Connect to INCA server (Certificate Server).

Use the enrollment tool to import the list of voters into the INCA database (see BT-0004-1-3).

Expected Results

The INCA server will produce a unique User Number for each user. In order to create a certification during the election procedure the user must insert his User Number. At the same time, an e-mail notification is forwarded to the e-mail address of each user in order to inform them of their User Number.

Notes

For Prototype 1 the minimum information provided for the voter consists of username and e-mail address

In the context of Prototype 1, the above information is stored in the INCA database with no special protection mechanisms in place, for verifiability reasons.

EIC: BT-0004-1-E4

Hardware Software


PC PC Workstation RDBMS Oracle 9i

Mail Server For sending e-mail notification

JDBC Java Libraries

InCA Certificate Cryptography Server

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 114 of 188


10.4.5 Manage Candidates

TCIC : BT-0004-1-5


Manage Candidates 27/05/2002 BT-0004-1-E5 Q&R

Purpose

Insert candidates for the election that is going to take place.

Set Up

Connect to the application to enter the Election parameters.

Enter the names of the Candidates in the appropriate input box and press the add button to fill the list box above with these names.

Press Save.

Expected Results

If the Candidates list is not empty and the other election parameters entered were in correct format, a screen appears informing the user that the election setup was completed successfully.

If the Candidates list is empty a screen appears informing that you may enter the names of the Candidates. A link returns you to the Election Setup Page to restart the procedure.

Notes

For Prototype 1 the names of the Candidates were replaced with lectures in order for the testers to vote for the most interesting one.

EIC: BT-0004-1-E5

Hardware Software




e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 115 of 188


10.4.6 Preview Ballots

TCIC : BT-0004-1-6


Preview Ballots 27/05/2002 BT-0004-1-E6 Q&R

Purpose

Display Ballot to the voters.

Set Up

Dependencies: Successful Completion of BT-0004-1-1.

Expected Results

If the Authentication process (BT-0004-1-1) was successful the result will be a screen that shows the ballot to continue the voting process. The ballot presents the candidates in a list and an option button for each one in order for the voter to select one and cast his vote.

Notes

For Prototype 1 the ballot presented to the voters’ displays a number of lectures to be voted as the most interesting one.

EIC: BT-0004-1-E6

Hardware Software




e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 116 of 188


10.4.7 Cast Vote

TCIC : BT-0004-1-7


Cast Vote 27/05/2002 BT-0004-1-E7 Q&R

Purpose

Facilitate electronic voting

Set Up

Dependencies: Successful Completion of BT-0004-1-6.

Select a candidate and press Vote.

Expected Results

The vote is being tested. Depending on the results of the tests the following screens will appear:

If the vote is correct (created – signed – verified) and the voter has only voted once, the result will be a screen showing that the voter has voted correctly and the vote is stored into the database.

If the voter has already cast his vote and tries to cast a vote again, the result will be an error message indicating that the voter has already voted.

If the vote has not been created, the result will be a screen showing that error.

If the vote has not been signed, the result will be a screen showing that error.

If the vote has not been verified, the result will be a screen showing that error.

Notes

The verification process is made through a communication with the InCA server.

EIC: BT-0004-1-E7

Hardware Software




e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 117 of 188


10.4.8 Tally Votes

TCIC : BT-0004-1-8


Tally Votes 27/05/2002 BT-0004-1-E8 Q&R

Purpose

Calculate the election result.

Set Up

Connect to the application to see the Election Results and type the following URL:

https://phobos.instore.gr/evote/result.jsp

Press the View Results button to see the results.

Expected Results

A new screen appears showing the list of candidates and the corresponding votes each one received.

Notes

The votes are read from the database decrypted, decoded and calculated.

EIC: BT-0004-1-E8

Hardware Software




e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 118 of 188

https://phobos.instore.gr/evote/result.jsp


10.4.9 Verify Result Integrity

TCIC : BT-0004-1-9


Verify Result Integrity

27/05/2002 BT-0004-1-E9 Q&R

Purpose

Verify that the sum of votes for each candidate as given by the counting procedure, equals the number of votes stored in the database.

Set Up

Sum the vote count stored on the database table (Running an SQL command) and compare the results to the results on the tally page.

Expected Results

If the results are the same, then the integrity of the voting process is verified.

Notes

In Prototype 1 this functionality is partially completed.

It will be fully implemented in the next Prototypes.

EIC: BT-0004-1-E9

Hardware Software



Internet Connection Modem Required RDBMS Oracle 9i

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 119 of 188


11 Results of Basic Tests

The results of testing are the assembly of the bugs that remain after the debugging process has ended. That means that bugs, which have been identified, corrected and have been tested to have been removed will not be included here but that other bugs and test cases, which have not been carried out, are reported.

11.1 Results from the Tests on the Stand-alone Operation of e-VOTE Prototype 1 Modules

Test Evaluation Form

TCIC Date Evaluated By Notes

BT-0001-1-1 27/05/2002 CRM

Results

As expected.

11.2 Results from the Tests on the Manual Inspection of Messages



BT-0002-1-1 27/05/2002 CRM

Results

As expected.



BT-0002-1-2 27/05/2002 CRM

Results

As expected.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 120 of 188


11.3 Verification that the System has been Set-Up correctly

11.3.1 Check Application Server



BT-0003-1-1 27/05/2002 Q&R

Results

As expected.

11.3.2 Check Database Server



BT-0003-1-2 27/05/2002 Q&R

Results

As expected.

11.4 Verification that the System Operates

11.4.1 Authenticate Actor



BT-0004-1-1 27/05/2002 Q&R

Results

As expected.

As expected.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 121 of 188


11.4.2 Provide Election Parameters



BT-0004-1-2 27/05/2002 Q&R

Results

As expected.

As expected.

11.4.3 Manage Voters



BT-0004-1-3 27/05/2002 Q&R

Results

As expected.

As expected.

11.4.4 Provide Authentication Means



BT-0004-1-4 27/05/2002 Q&R

Results

As expected.

11.4.5 Manage Candidates



BT-0004-1-5 27/05/2002 Q&R

Results

As expected.

As expected.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 122 of 188


11.4.6 Preview Ballots



BT-0004-1-6 27/05/2002 Q&R

Results

As expected.

11.4.7 Cast Vote



BT-0004-1-7 27/05/2002 Q&R

Results

As expected.

As expected.

As expected.

As expected.

As expected.

11.4.8 Tally Votes



BT-0004-1-8 27/05/2002 Q&R

Results

As expected.

11.4.9 Verify Result Integrity



BT-0004-1-9 27/05/2002 Q&R

Results

As expected.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 123 of 188


11.5 Sub-conclusion.

The system works, or has only minor flaws which will not influence the trial significantly.

The system has bugs that must be corrected before the trial. This can be done safely and in time.

The system still has major flaws. The trial cannot be carried out in a responsible manner at the planned time.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 124 of 188


12 Description of Capability and Behaviour Resolution Tests (ESSEN)

This Chapter describes the work conducted by University of Essen during the validation of the e-VOTE prototype 1 system. The election process simulated was a poll. In addition to interacting with the e-VOTE system, each tester was asked to answer some questionnaires. These are of high importance for validation purposes. Having completed the tests, this validation reveals the testers opinion for the e-VOTE system, good/bad aspects, occurred problems, etc. Thus, the gathered information is especially useful with regard to the further development of the e-VOTE system as well as to the other two test rounds that will be performed at later stages.

Within the subsequent Chapters a detailed description of the different test cases carried out during the trials in Essen, as well as a description of the test environment utilised is given. The results of each test case are listed in Chapter 13.

12.1 Capability Test with Real Users (CT-RUT)

ESSEN-PR1 Capability Test: CT-0001-1-E-RUT

Objectives Validate the functionality of e-VOTE Prototype 1

Evaluation CriteriaTechnical A comprehensive use case scenario aiming to assess the conformity with

the User Requirements and to evaluate the e-VOTE Prototype 1 functionality


Number of Participants 81Participant Characteristics Students from the University of Essen

Computer literate and familiar with the use of InternetNo other expertise related to the project

Expectation a) e-VOTE Prototype 1 system has been validated.b) All identified problems / deficiencies have been recorded.

In general, this test case can be seen as the simulation of an (electronic) election process: Each tester connects to the e-VOTE system, casts his vote49 and disconnects afterwards. By performing this comprehensive scenario a large variety of user respective functional requirements, adopted into the first prototype of the e-VOTE system, were evaluated. This includes for example the suitability of the user interface, the time needed for authenticating to the system and casting a vote, the system availability as well as the identification of possible errors, weaknesses and improvements. A more precise description of the whole testing procedure is given in Section 2.2.2.2.

49 In this sample poll the testers (students) were asked to choose the lecture they would rate as the most interesting one. The used ballot can be found in Chapter 19 (Appendix B – Ballot).

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 125 of 188


TCIC : CT-0001-1-E-RUT-1


Simulated (electronic) Election

27.-29.05.2002 CT-0001-1-E-RUT-E1A,CT-0001-1-E-RUT-E1B

ESSEN

Purpose

a) evaluation of the e-VOTE prototype 1 functionality (see Chapter 3 or deliverable D 4.1) as well as

b) assessing its conformity with the according user requirements (see Chapter 3 or deliverable D 3.1)

Set Up

1. Internet access from a site external to the e-VOTE system.

2. Perform the different steps as described in Section 9.2.2.2.

Expected Results

a) all (if any) problems and deficiencies of the e-VOTE prototype 1 system are identified and recorded

b) additional information about the testers attitude towards electronic voting in general and especially towards the e-VOTE system is gathered

The following table summarises the technical details of the departmental equipment that in most cases was used during the evaluation of the e-VOTE system. Since the students do not have the right to install any software on those PCs, the necessary Java Plug-In was installed by the system administrator.

EIC: CT-0001-1-E-RUT-E1A

Hardware Software


Computer HP e-Vectra Operating System Linux Redhat 6.2 or Windows NT 4.0 or Windows 2000

Processor Intel Celeron 566 Web Browser Netscape 4.78 or Netscape 6.1 or Internet Explorer 6.0

Memory 128 MB RAM Java Plug-In Browser Plug-In to run Java Applets

Internet Connection

Dedicated line (2 Gigabit)

In addition to that, many testers also performed the test from other locations (e.g. from their home or at work). Thus, in these cases the test environment differed from the one described above. The following table shortly summarises the alternative test environment.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 126 of 188


EIC: CT-0001-1-E-RUT-E1B

Hardware Software


Computer Personal Computer, Laptop

Operating System Windows 98, Windows XP, Windows 2000, Linux Kernel 2.4.18

Processor Duron 700, P2 400, P3 1 GHZ, Mobile P3 1,2 GHZ, P2 700, Thunderbird 900, Duron 800, P3 500

Web Browser Internet Explorer 5.0, Internet Explorer 6.0, Mozilla 5.0, Netscape Navigator

Internet Connection

Modem, DSL, ISDN

12.2 Behaviour Resolution Tests with Real Users (BRT-RUT)

ESSEN-PR1 Behaviour Resolution Test: BRT-0001-1-E-RUT

Objectives Observe the behaviour of the e-VOTE prototype 1 system while testing specific actions

Evaluation Criteria Technical Simulation of “invalid” use case scenarios (casting multiple votes,

getting access to the system without the correct authentication means), in relation to the functionality supported by the e-VOTE Prototype 1

system, for recording any unexpected system response.


Number of Participants 81Participant Characteristics Students from the University of Essen

Computer literate and familiar with the use of InternetNo other expertise related to the project

Expectation All identified problems / deficiencies have been recorded

12.2.1 Penetration Testing – Casting Multiple Votes

The goal of this test case was to verify that every eligible voter who connects to the e-VOTE system is only allowed to cast exactly one vote. This especially refers to user requirement NF3.1.1.13.2 (see Chapter 3 or deliverable D 3.1) as well as to functional requirement R3.1.13.1 (see Chapter 3 or deliverable D 4.150). The following table summarises the key data for this test case.

50 The reader is informed that there is a difference in the numbering of functional requirements between deliverable D4.1 and Chapter 3 of this document. Specifically, in D4.1 the functional requirements are referenced as R 5 .x.x.x instead of the R 3 .x.x.x used in the current document.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 127 of 188


TCIC : BRT-0001-1-E-RUT-1


PENTEST1 27.-29.05.2002 BRT-0001-1-E-RUT-E1A,BRT-0001-1-E-RUT-E1B

ESSEN

Purpose

a) evaluation of the e-VOTE prototype 1 functionality (see Chapter 3 or deliverable D 4.1) and


with special emphasis on the:

c) evaluation if it is possible to vote twice

Set Up


2. Identification of ways that allow the user to cast more than one vote.

Expected Results

a) the system does not allow the users to vote twice

b) possible problems or deviations from item (a) are identified and recorded

The following table summarises the technical details of the departmental equipment that in most cases was used during the evaluation of the e-VOTE system. Since the students do not have the right to install any software on those PCs, the necessary Java Plug-In was installed by the system administrator.

EIC: BRT-0001-1-E-RUT-E1A

Hardware Software





e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 128 of 188


Internet Connection


In addition to that, many testers also performed the test from other locations (e.g. from their home or at work). Thus, in these cases the test environment differed from the one described above. The following table shortly summarises the alternative test environments.

EIC: BRT-0001-1-E-RUT-E1B

Hardware Software





Web Browser Internet Explorer 5.0, Internet Explorer 6.0, Mozilla 5.0

Internet Connection

Modem, DSL

12.2.2 Penetration Testing – Unauthorised Access

The goal of this test case was to verify that only eligible voters are able to cast a vote and that no one can enter the system without the necessary authentication means. This especially refers to user requirement NF3.1.1.1.1 (see Chapter 3 or deliverable D 3.1) as well as to functional requirement R3.1.1.3 (see Chapter 3 or deliverable D 4.151). The key data for this test case is summarised in the following table.

51 The reader is informed that there is a difference in the numbering of functional requirements between deliverable D4.1 and Chapter 3 of this document. Specifically, in D4.1 the functional requirements are referenced as R 5 .x.x.x instead of the R 3 .x.x.x used in the current document.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 129 of 188


TCIC : BRT-0001-1-E-RUT-2


PENTEST2 27-29.05.2002 BRT-0001-1-E-RUT-E2A,BRT-0001-1-E-RUT-E2B

ESSEN

Purpose

a) evaluation of the e-VOTE prototype 1 functionality (see Chapter 3 or deliverable D 4.1) and


with special emphasis on:

c) entering the system without the correct authentication means

Set Up


2. Identification of ways that allow access to the e-VOTE system without having the valid authentication means (User Number).

Expected Results

a) entering the e-VOTE system is impossible without the correct authentication means

b) possible problems or deviations from (a) are identified and recorded

The following table summarises the technical details of the departmental computer pool that mainly was used during the evaluation of the e-VOTE system. Since the students do not have the right to install any software on those PCs, the necessary Java Plug-In was already installed by the system administrator.

EIC: BRT-0001-1-E-RUT-E2A

Hardware Software





Internet Connection


In addition to that, many testers also performed the test from other locations (e.g. from their

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 130 of 188


home or at work). Thus, in these cases the test environment differed from the one described above. The following table shortly summarises the alternative test environments.

EIC: BRT-0001-1-E-RUT-E2B

Hardware Software





Web Browser Internet Explorer 5.0, Internet Explorer 6.0, Mozilla 5.0

Internet Connection

Modem, DSL

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 131 of 188


13 Results of Capability and Behaviour Resolution Tests (ESSEN)

13.1 Capability Test with Real Users (CT-RUT)



CT-0001-1-E-RUT-1 30.05.2002 ESSEN

Results

This test case was mainly evaluated by using questionnaires and performing a conclusion meeting. Please refer to Sections 13.3 (questionnaires) and 13.4 (conclusion meeting) for the detailed description of the evaluation results.

13.2 Behaviour Resolution Tests with Real Users (BRT-RUT)

13.2.1 Penetration Testing – Casting Multiple Votes



BRT-0001-1-E-RUT-1 30.05.2002 ESSEN

Results

After having cast the vote it was impossible to cast another vote by using the BACK button of the web browser and pressing the VOTE button a second time.

Furthermore it was impossible to enter the e-VOTE system a second time with the same User Number. The system responds with an “Invalid User Number” message.

However, it was possible to cast more than one vote by using several browser windows. After entering the same User Number in all browser windows each window presented the ballot. Finally in each window the VOTE button was pressed which in all cases lead to a “Your vote is counted” message. This must be prevented.

Other ways of casting more than one vote have not been identified during the testing days.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 132 of 188


13.2.2 Penetration Testing – Unauthorised Access



BRT-0001-1-E-RUT-2 30.05.2002 ESSEN

Results

During the testing days the testers did not get access to the e-VOTE system without the valid authentication means (User Number).

However, if an attacker has only little knowledge about the used security mechanism or about the structure of the authentication means – and we generally must proceed from that – it is relatively easy for him to break into the system. In case that the attacker e.g. knows that each User Number consists of 16 digits, he only has to try out several combinations of digits and after some time he will be able to access the system.

Therefore, the use of simple User Numbers does not provide an appropriate degree of security. Advanced security mechanism must be adopted in order to use the e-VOTE system in real elections.

13.3 Further Evaluation Results gathered from the Questionnaires

This Chapter deals with the results of the two questionnaires that were used during the evaluation of the e-VOTE prototype 1 at the University of Essen.

13.3.1 Pre-Test Questionnaire

This section presents the results of the pre-test questionnaire (see Section 18.1) that was presented to the test participants prior to the evaluation of the e-VOTE system. Its goal was to gather information concerning the tester’s background, his familiarity with the particular technology and his expectations from Internet Voting Systems. In the following the structure of the questionnaire is pertained and each question is attached either with a graphical or textual representation of the testers answers.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 133 of 188


A. Statistical Information

a) Sex

b) Age

c) Qualification

All test participants were either students studying computer science or employees working at the computer science department of the University of Essen.

d) Have you Participated in an election before?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 134 of 188


If yes, in which kind of Election (multiple answers possible)?

B. Background Information

a) Do you consider yourself as computer literate?

b) What type of computer do you use?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 135 of 188


c) What Operating System(s) do you use (multiple answers possible)?

d) Where and how often do you use a computer?

e) How long have you been using the Internet?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 136 of 188


f) What type of Internet connection do you have at home?

g) Which web browser do you normally use?

h) Which forms of electronic communication do you normally use?

As ‘other’ forms of electronic communication the test participants named the following (with decreasing frequency):

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 137 of 188


1. Mobile Phone / SMS

2. Instant Messaging, ICQ

3. IRC (Chat)

i) What is your level of knowledge/expertise on the following areas?

j) Have you heard of or used ‘Electronic Voting (Systems)’ before?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 138 of 188


C. Political (voting) Aspects

a) What is your involvement in public affairs (multiple answers possible)?

b) How regularly do you vote?

c) How many times have you voted in an election?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 139 of 188


d) Do you have the option of voting from home (e.g. by postal vote) at general elections?

In case of ‘yes’, how often have you already voted from home?

In case of ‘no’, how far is the voting center from your home?

The answers to this question were varying between 200 meter and 5 kilometres.

e) How do you judge the general election voting process in your country?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 140 of 188


f) According to your opinion, if people had the option of voting from their home over the Internet, would the participation rate in elections increase?

g) Which of the following system characteristics do you consider ‘dominant’, in a positive or negative sense, with regard to electronic voting?

h) Do you trust the conventional way of voting?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 141 of 188


i) What is the level of trust you would have on an election conducted electronically over the Internet, as compared to the conventional process?

j) For which kind of political elections should Electronic Voting Systems be used?

k) Other POSITIVE aspects with regard to Electronic Voting?

The test participants answered this open question by especially pointing at the following aspects (in decreasing frequency):

1. Electronic Voting is easier and faster that the conventional way of voting

2. Electronic Voting is a big chance for the future

3. Electronic Voting is more flexible (“vote from everywhere”)

4. Using Electronic Voting Systems might increase the participation rate in elections

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 142 of 188


l) Other NEGATIVE aspects with regard to Electronic Voting?


1. Electronic Voting Systems are not secure (up to now)

2. Digital Divide

3. Contact persons are missing in case of problems or questions

D. Social Aspects

a) According to your opinion, how likely is in the future that voting over the Internet becomes part of our life?

b) How do you think that the problem of the ‘digital divide’ (discrimination between computer literate people and non-computer liberate) will affect Internet Voting in the future?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 143 of 188


E. General Comments


1. An Electronic Voting System is a good idea but elections could get manipulated more easily

2. Such a system must be easy to use and attractive to the user

3. Such a system must run on all standard web browsers

4. There must be any kind of proof that the voting system is secure

5. It is unlikely that such a system will be used in general elections

6. Such a system will not replace the conventional way of voting

13.3.2 Post-Test Questionnaire

This Chapter describes the results of the post-test questionnaire (see Section 18.2) that was presented to the test participants after the evaluation of the e-VOTE system. Its goal was to gather information about the evaluation of the e-VOTE prototype 1. In the following the structure of the questionnaire is pertained and each question is attached either with a graphical or textual representation of the testers answers.

A. Tutorials & Help Information

a) How would you describe the information offered during the following services?

b) What was missing or could be improved?


1. The system lacks further information and help functions

2. There was no ballot management

3. There was no information

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 144 of 188


B. User-Friendliness

a) Were the following services easy to use?

b) Did you encounter any problems while using the e-VOTE system in any of the following?

In case of ‘yes’, which problems did you encounter?


1. Login to the system required several attempts

2. Because of some reason the site reloads every time, the cursor is moved over the AUTHENTICATE respective the VOTE button

3. There was no possibility to vote under Linux

4. Severe problems with the Java Plug-In

5. The system is too slow

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 145 of 188


C. Functional Aspects

a) Did you face any functionality problems?

In case of ‘yes’, what kind of problems did face?


1. The authentication mechanism worked only on (at least) second try

2. Downloading Java should be omitted

3. Problems during Java download

b) Did you identify any system deficiencies?

In case of ‘yes’, what kind of deficiencies did you identify?


1. The system is too slow and too static

2. The used certificate was not trustworthy

3. After pressing the vote-button the system should ask once again if the selected choice is correct

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 146 of 188


c) Are you satisfied with the time required to authenticate to the system?

d) How long did it take you to authenticate to the e-VOTE system?

e) Are you satisfied with the time required for completing the whole voting procedure?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 147 of 188


f) How long did it take to complete the whole voting procedure?

g) Did you ever find the system unavailable?

In case of ‘yes’, for how long was it unavailable?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 148 of 188


D. Security Aspects

a) Are you convinced that the e-VOTE System provides the necessary level of security?

In case of ‘no’, can you please give any reasons for your answer?


1. The system misses information about how security is achieved

2. A simple password check is definitely not enough security

3. I’m afraid of hack attacks

4. SSL is missing

5. Don’t use a web browser because it may have security holes

b) Do you think that Electronic Voting Systems can be secure at all?

c) How could your level of trust, as far as the system security is concerned, be improved?


1. If I would have more information about technical details and how security is achieved

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 149 of 188


2. By using ID Cards

3. Casting a vote should only be done from a secure terminal

4. Don’t use a browser with Java Plug-In

5. The system must have more security options

d) Are you interested in how the security is achieved?

Can you please give any reasons for your answer?


1. This would increase the acceptance of such a system

2. I want to be sure about the protection of my personal data

E. Political (voting) Aspects

a) Is there anything in the electronic voting procedure that you would like changed?

In case of ‘yes’, what would you like changed?


e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 150 of 188


1. The user interface should be improved

2. More information and help functions are necessary

3. After pressing the VOTE button the system should ask once again if the selected choice is correct

4. The system should be faster

5. Support for different languages would be nice

6. Method of Authentication

b) Do you think that Electronic Voting is a good alternative to the existing procedure?

c) According to your opinion, if people had the option of electronic voting, would the participation rate in election increase?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 151 of 188


d) What is the level of trust you would have on an election conducted electronically over the Internet, as compared to the conventional process?

e) What would you prefer if you had the option of Electronic Voting?

f) Should Electronic Voting be the only option for someone to vote?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 152 of 188


In case of ‘no’, can you please give reasons for your answer?


1. Digital divide

2. Electronic Voting Systems should only be seen as an alternative way of voting

3. Serious security concerns

4. Not everybody has a computer and/or an Internet connection

5. The risk of manipulation is much higher

6. Going to the voting place is “part of our culture”

F. Social Aspects

a) According to your opinion, how likely is in the future that voting over the Internet becomes part of our life?

b) How do you think that the problem of the digital divide (discrimination between computer literate persons and non-computer literate) will affect Internet Voting in the future?

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 153 of 188


G. General Comments


1. The e-VOTE prototype looks quite promising

2. Such a system reduces the time required for voting

3. Installing Java should be omitted

4. The Vote-Applet did not work properly

5. The security aspects of the system should be explained in more detail

13.4 Further Evaluation Results gathered from the Conclusion Meeting

During the Conclusion Meeting the test participants had the opportunity to discuss their experiences and also express their opinion about the e-VOTE system.

In general, most of the testers had a positive attitude towards the first prototype of the e-VOTE system and considered it as a good alternative to the existing voting procedures (after some necessary improvements).

On the other hand, many testers raised their displeasure about the e-VOTE system and specifically they pointed out the following issues:

o In many cases (e.g. when using Linux, Solaris, Netscape Navigator or Mozilla) they were simply unable to cast their vote.

o The most successful tries could be recorded for the Internet Explorer and a Microsoft OS. Apparently only one tester was able to cast his vote over Linux Kernel in combination with a Mozilla web browser.

o After entering the User Number the system needed too much time to validate the credentials and present the ballot. Many testers cancelled their voting attempt after waiting 10-15 minutes.

o Furthermore, authorisation often worked only after the second or third try.

o For a few testers it was unacceptable that they were forced to install the newest Java Version (11,5 MB!).

o Furthermore, several testers had problems while downloading or installing Java.

o Some testers also refused to vote since the presented certificate was described as “NOT SECURE!!!”

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 154 of 188


14 Description of Capability and Behaviour Resolution Tests (AEGEAN)

This Chapter describes the Capability and Behavioural Tests that were conducted from the University of the Aegean during the first round of trials (e-VOTE prototype 1).

14.1 Capability Tests (CT)

AEGEAN-PR1 Capability Test: CT-0001-1-A-RUT

Objectives Ensure that the system performs correctly a predetermined set of functions

Evaluation Criteria Organisational Compliance with Legal and Constitutional Requirements

Trial ParametersType of Voting Procedure Internal (University of the Aegean) Poll

Number of Participants Approximately 5Participant Characteristics Legal Experts and Independent Security Experts

Expectation Ensure the conformity of the system with the legal requirements

TCIC : CT-0001-1-A-RUT-1


LEGALTEST-1 29 May, 2002 CT-0001-1-A-RUT-E1 AEGEAN

Purpose

Explore the conformity of the e-VOTE system with the constitutional requirements and the common principles of the legislative frameworks, as these were listed in Section 2.1.1 (Business Use Case Model) of the project deliverable 3.1 (Document Code: e-VOTE/WP-3/D3.1/FD/3.0/08-02-2002)

Set Up1. Internet access from a site external to the e-VOTE system.2. Legal experts are invited to use the system, participating in the Poll election process that

has been implemented 3. The Legal people can consult (ask the opinion) of independent external security experts

regarding technical issues that they can not evaluate by themselves

Expected Results

Identification (if any) of the unsupported legal and constitutional requirements. It is stressed that these are mainly applicable to the “General Election” case, rather than the “Poll” case. However, the functionality implemented in prototype 1 exhibits the characteristics required for the “General Election” case and can thus be utilised for the specific test case.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 155 of 188


EIC: CT-0001-1-A-RUT-E1

Hardware Software


Stand-alone computer

PC OS MS Windows NT

Network connection

Ethernet LAN Web Browser MS Internet Explorer 6.0

14.2 Behaviour Resolution Tests with Real Users (BRT - RUT)

AEGEAN-PR1 Behaviour Resolution Test: BRT-0001-1-A-RUT

Objectives a) Observe the operational behaviour of the e-VOTE prototype-1 system by simulating “invalid” use cases

b) Verify the integrity of the voting protocol

Evaluation Criteria Technical Penetration tests for assessing the robustness of the voting protocol’s

attributes


Number of Participants Approximately 10Participant Characteristics Information and Communication Systems’ Security Experts

Expectation Any unexpected system response will be recorded

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 156 of 188


14.2.1 Penetration testing – Information gathering

TCIC : BRT-0001-1-A-RUT-1


PENTEST-1 27 May, 2002 BRT-0001-1-A-RUT-E1 Vassilis Tsoumas (AEGEAN)

Purpose

Identify network structure, operating systems and applications of the computers hosting the e-VOTE system.

Set Up


5. Free tools and utilities were used in order to gather information (i.e. port scanners, public services as whois, telnet, etc).

Expected Results

1. Minimum possible public information should be exposed to the Internet with respect to the network structure of the e-VOTE system.

2. A packet-filtering device should be in place in front of the e-VOTE system with respect to the Internet access, leaving access only to the necessary ports should be open on the e-VOTE system.

Notes

(With respect to the expected results)

1. Network structure information regarding the e-VOTE system is leaked through the respective nameserver by the means of zone transfers.

2. Information about the Web Server hosting the e-VOTE system is disclosed from the web site and the system banners.

3. A packet filtering device is in place in front of the e-VOTE system and the open ports are 80 (http), 443 (SSL) and 7777 (Oracle Containers for Java)

EIC: BRT-0001-1-A-RUT-E1

Hardware Software



PC OS MS Windows NT

Network connection


e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 157 of 188


14.2.2 Penetration testing – Invalid input

TCIC : BRT-0001-1-A-RUT-2


PENTEST-2 27 May, 2002 BRT-0001-1-A-RUT-E2 Vassilis Tsoumas (AEGEAN)

Purpose

Circumvent the normal application flow through the use of invalid input in the “User Number” field (https://phobos.instore.gr/evote/vote.html).

Set Up


2. Insertion of invalid strings into the “User Number” field – among the others, invalid input is very long strings, combination of letters and numbers, etc.

Expected Results

1. The e-VOTE system should not crash on invalid input.

2. The system should respond in such a way that no information is given away about the internal workings of the e-VOTE system.

3. The functionality of the system should be available on next request, even if the user does not close the web browser.

4. The system should respond in a timely fashion.

Notes

(With respect to the expected results)

1. The e-VOTE system is not crashed on invalid input.

2. In several invalid strings (i.e. “‘”), the user was presented with a system error, while the e-VOTE page was giving away a message like “Please wait… Your authentication request is checked”. The system afterwards has to be re-accessed through the “Back to authenticate” link or to be re-loaded from the starting page of the e-VOTE test site. The “Back” button of the web browser does not work (i.e. re-authenticates the voter with the given credentials). In some cases, after the invalid input, all the instances of the web browser should be exited (even if the other instances accessed other, unrelated sites) before the e-VOTE test site (i.e. https://phobos.instore.gr/evote/vote.html) could be correctly loaded once again (i.e. the applet could not be re-loaded correctly).

3. No information about the internal workings of the e-VOTE system is disclosed.

4. The system responds in a timely fashion.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 158 of 188




EIC: BRT-0001-1-A-RUT-E2

Hardware Software



PC OS MS Windows NT

Network connection


14.3 Software Based Behaviour Resolution Tests (BRT - SBT)

In order to perform the Software Based Tests on the e-VOTE system the Apache JMeter application has been used. It is a pure Java desktop application designed to load test functional behaviour and measure performance both on static and dynamic resources (html, JSP, Servlets, Java Objects). It has been also used for simulating a heavy load on the server to test its strength and analyse overall performance under different load types making a graphical analysis of that performance as well.

AEGEAN-PR1 Behaviour Resolution Test: BRT-0002-1-A-SBT

Objectives Observe the operational behaviour of the e-VOTE prototype-1 system by simulating “extreme” use cases

Evaluation Criteria Technical a) Simulation of extreme “use case” scenarios (load performance test,

stress testing, maximum number of supported concurrent users etc, in relation to the functionality supported by the e-VOTE Prototype-1

system, for recording any unexpected system response. b) Response time under high load


Number of Participants Simulated Users varying from tenths to hundredsParticipant Characteristics N/A

Expectation Any unexpected system response has been recorded

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 159 of 188


14.3.1 Performance Test of Election Setup Page - I

TCIC : BRT-0002-1-A-SBT-1


PTESP - I 27/05/2002 BRT-0002-1-A-SBT-E1 Q&R

Purpose

Test functional behaviour and measure performance of the Election Setup Page

(compilation and retrieval).

Set Up

Run the JMeter application. Enter the following parameters into the appropriate fields

(See Figure below).

URL: http://phobos.instore.gr:7777/evote/setup.jsp

Average Delay: 100 Milliseconds

Delay Deviation: 50 Milliseconds

Concurrent Threads: 10

Expected Results

Minimum time of page retrieval.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 160 of 188

http://phobos.instore.gr:7777/evote/setup.jsp


EIC: BRT-0002-1-A-SBT-E1

Hardware Software




Jmeter Application for measuring the performance

JRE Java Runtime

14.3.2 Performance Test of Election Setup Page - II



PTESP - II 27/05/2002 BRT-0002-1-A-SBT-E2 Q&R

Purpose

Test functional behaviour and measure performance of the Election Setup Page


Set Up


(See Figure 1).

URL: http://phobos.instore.gr:7777/evote/setup.jsp




Expected Results


e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 161 of 188

http://phobos.instore.gr:7777/evote/setup.jsp



Hardware Software





JRE Java Runtime

14.3.3 Performance Test of Election Vote Page - I



PTEVP - I 27/05/2002 BRT-0002-1-A-SBT-E3 Q&R

Purpose

Test functional behaviour and measure performance of the Election Vote Page


Set Up


(See Figure below).

URL: http://phobos.instore.gr:7777/evote/vote.html




Expected Results


e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 162 of 188

http://phobos.instore.gr:7777/evote/vote.html



Hardware Software





JRE Java Runtime

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 163 of 188


14.3.4 Performance Test of Election Vote Page - II



PTEVP - II 27/05/2002 BRT-0002-1-A-SBT-E4 Q&R

Purpose

Test functional behaviour and measure performance of the Election Vote Page


Set Up


(See Figure below)

URL: http://phobos.instore.gr:7777/evote/vote.html




Expected Results


e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 164 of 188

http://phobos.instore.gr:7777/evote/vote.html



Hardware Software





JRE Java Runtime

14.3.5 Performance Test of Election Counting Page - I



PTECP - I 27/05/2002 BRT-0002-1-A-SBT-E5 Q&R

Purpose

Test functional behaviour and measure performance of the Election Counting Page

(compilation and retrieval of the servlet processing the counting).

Set Up


(See Figures below)

URL: http://phobos.instore.gr:7777/evote/servlet/VoteCount

Constant Delay: 300 Milliseconds

Method : Post


Expected Results


e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 165 of 188

http://phobos.instore.gr:7777/evote/servlet/VoteCount


e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 166 of 188



Hardware Software





JRE Java Runtime

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 167 of 188


15 Results of Capability and Behaviour Resolution Tests (AEGEAN)

15.1 Capability Tests (CT)


TCIC Date Evaluated By NotesCT-0001-1-A-RUT-1 29 May, 2002 Legal Experts : L. Mitrou, G. Georgaroudi

(AEGEAN)Independent Security Expert: Dr. D. Lekkas

LEGALTEST

Results1. Generality:

The ability to participate in an election process (eligibility) must be founded on the law and should be controllable according to the law: Ensured through the registration module of the e-VOTE system which actually imports the up-to-date lists of voters

Voting possibilities and technologies should be accessible by every voter: This is an organisational issue and can be addressed by setting-up public election centres with terminals that can be used for electronic voting

2. Freedom: Uncoercibility: This is not yet supported by the e-VOTE prototype 1 system Freedom of Voter’s decision: The capability to cast a consciously invalid vote could not be

demonstrated through prototype 1. However, the architecture of the system allows a choice for an “invalid vote” in the ballot.

3. Equality: Integrity, Non-changeability: This has been demonstrated by the consortium. The legal experts have

accepted (after consulting the independent security expert, Dr. D. Lekkas) that the implemented security mechanisms satisfy the UR set. Although they have declared that before accepting a system that can be used for “General Election” they need to re-evaluate its security characteristics in a more detailed and systematic way.

Transparency: All parties should have equal opportunities to the elements of the voting procedure, in order to verify its integrity and proper organization. This is indeed supported by the e-VOTE system and its architecture.

Eligibility: Only eligible voters can cast a vote: This is achieved through the authentication mechanism. Several comments regarding the distribution mechanism of the existing “User Numbers” and the potential use of “authorisation tokens” were expressed and were taken into account by the consortium.

Non - reusability: Each eligible voter can only vote once. A problem has been recorded here (it has been already described in the results of test case BRT-0001-1-E-RUT-1).

Verifiability: The voter, or his representatives, should have the possibility to verify that his vote has been calculated in the final tally: This is supported through the “verify result integrity” use case. However, since the logging mechanisms were not implemented in prototype 1, the specific test was postponed for later trial rounds.

4. Secrecy: Nobody should be able to link a ballot to a voter. This implies that: Registration, authentication and voting must be clearly and evidently separated. Votes must be validated separately and independently from voter authentication No voter should be able to prove that he/she voted in a particular wayAll the above have been demonstrated by the consortium. The legal experts have accepted (after consulting the independent security expert, Dr. D. Lekkas) that the implemented security mechanisms satisfy the UR set. Although they have declared that before accepting a system that can be used for “General Election” they need to re-evaluate its security characteristics in a more detailed and systematic way.

5. Directness: Electors directly select their representatives. Therefore: No intermediaries chime in the voting decision (i.e. no person can be authorised to vote for another

person): Using the existing (implemented) authentication mechanism this requirement can not be guaranteed, assuming that the “eligible voter” decides to give his “User Number” to another person.

Each and every ballot must be directly recorded and counted. It has been demonstrated that this requirement is satisfied by the e-VOTE architecture.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 168 of 188


15.2 Behaviour Resolution Tests with Real Users (BRT - RUT)

15.2.1 Penetration testing – Information gathering



BRT-0001-1-A-RUT-1

28 May, 2002 Costas Lambrinoudakis (AEGEAN)

PENTEST-1

Results

6. The e-VOTE system network structure information (DNS zone transfers) should be communicated only to authorized hosts.

7. It should be noted that no application-specific information (such as platforms and versions) should be disclosed to a visitor of the web site.

15.2.2 Penetration testing – Invalid input



BRT-0001-1-A-RUT-2

28 May, 2002 Costas Lambrinoudakis (AEGEAN)

PENTEST-2

Results

The system seems robust with respect to invalid requests handling.

Unnecessary documentation (i.e. Apache documentation) should be removed from the system hosting the e-VOTE web site.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 169 of 188


15.3 Software Based Behaviour Resolution Tests (BRT - SBT)

15.3.1 Performance Test of Election Setup Page - I



BRT-0002-1-A-SBT-1

27/05/2002 Q&R

Results

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 170 of 188


15.3.2 Performance Test of Election Setup Page - II



BRT-0002-1-A-SBT-2

27/05/2002 Q&R

Results

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 171 of 188


15.3.3 Performance Test of Election Vote Page - I



BRT-0002-1-A-SBT-3

27/05/2002 Q&R

Results

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 172 of 188


15.3.4 Performance Test of Election Vote Page - II



BRT-0002-1-A-SBT-4

27/05/2002 Q&R

Results

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 173 of 188


15.3.5 Performance Test of Election Counting Page - I



BRT-0002-1-A-SBT-5

27/05/2002 Q&R

Results

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 174 of 188


16 Test Conclusions

The group of test persons has in general, positively accepted Internet voting although some have expressed their objections against it. Most of the participants in the testing group have anticipated that electronic voting will exhibit a high degree of applicability in the very near future. The participation in the electronic election was satisfactory and the system worked well for the vast majority of testers.

No criticism regarding the authentication model has been uttered from the voters. However, it will be interesting to see the reactions on authentication models employing two pieces of authentication information. Such models are necessary in order to reach the full level of authentication security.

Some discomfort was expressed, from computer literate voters, regarding the downloading of applets, knowing that this is often a troublesome technology to use. The difficulties with downloading applets were of course known to the e-VOTE consortium in advance. However, it is currently the only available technology that can support the required computations on the confidential data of the voter, without imposing any need for installing extra software at the voter’s computer.

The majority of the testers, but not all, were computer literate. At the University of the Aegean no particular problems were encountered due to a homogeneous population of web browsers, whereas at the University of Essen most of the students with non widely used web browsers were unable to vote.

At least one bug was still left in the system during the trial, causing some sessions to last too long or to be interrupted. Furthermore, one bug was left during the counting and required manual intervention (without compromising the process security and being invisible to the voters). The lessons learned can be summarised below:

In later trials it must be either specified which web browser versions with which JAVA versions are supported, or much more manual testing with different web browsers must be performed. Probably a combination of both is necessary.

It must be ensured that the performance of the system is not dramatically reduced as a result of several crashing sessions due to unsupported web browsers. This imposes high demands on the error handling in the web browser.

It is advisable to have a test round with the same data as in a real election in order to ensure that no untested boundary cases are present for the particular election.

For the first trial the SSL server certificate was not part of a certificate chain trusted by the web browsers. It was a mistake not to inform the users properly about that in advance.

Some older computers do not have the capacity to run the rather heavy computations or do not have the capability of running newer JAVA versions. (And there is nothing to do about it rather than ask them to vote manually or use another computer. Luckily enough this problem should pass over with time as computers become stronger.)

On the other hand, the system was actually there as a result of a successful co-operation, so except from these modifications in the testing procedures, no need for organisational changes in the project have been identified.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 175 of 188


17 References

i. “Administration and Cost of Elections Project Home Page”, available at http://www.aceproject.org

ii. A. Frier, P. Karlton and P. Kocher "The SSL 3.0 Protocol". Netscape Communications Corp., Nov 18, 1996.

iii. Berry Schoenmakers: "Fully Auditable Electronic Secret-Ballot Elections" XOOTIC, 2000

iv. Burton S. Kaliski Jr: “An Overview of the PKCS Standards”, RSA Laboratories 1993.

v. California Secretary of State Bill Jones, California Internet Voting Task Force, "A Report on the Feasibility of Internet Voting", January, 2000 available at http://www.ss.ca.gov/executive/ivote/

vi. California Secretary of State Bill Jones, California Internet Voting Task Force, Technical Committee Recommendations, January 2000

vii. Caltech/MIT Voting Technology Project

viii. Cay S. Horstmann, Gary Cornell: “Core Java Volume I - Fundamentals”, Sun Microsystems 1999.

ix. Craig Larman: “Applying UML and Patterns”. Prentice Hall, 1998.

x. CYBERVOTE (IST-1999-20338) Public Deliverable: “D3 - Project Presentation”.

xi. CYBERVOTE (IST-1999-20338) Public Deliverable: “D4 Electronic Democracy Projects (vol. 1)”.

xii. CYBERVOTE (IST-1999-20338) Public Deliverable: “D4 Legal Issues of Internet Voting (vol. 2)”.

xiii. CYBERVOTE (IST-1999-20338) Public Deliverable: “D4 User Requirements Analysis (vol. 3)”.

xiv. EasySign Technical White Paper Version 2, available at www.cryptomathic.com/products/easysign.html

xv. Eduardo Pelergi-Llopart, Larry Cable: “Java Server Pages Specifications v1.1”, Sun Microsystems 1999.

xvi. E-Government: The Next American Revolution, Prepared by Hart-Teeter for The Council for Excellence in Government, September 2000

xvii. Grady Booch, Ivar Jacobson, James Rumbaugh: “The Unified Modelling Language User Guide”. Addison – Wesley, 1999.

xviii. Hans – Erik Eriksson and Magnus Penker: “Business Modelling with UML – Business Patterns at Work”. Wiley Computer Publishing 2000.

xix. Hickman, Kipp, "The SSL Protocol". Netscape Communications Corp., Feb. 9. 1995.

xx. ISO/IEC 8824-1:1998 Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation, and ISO/IEC 8824-2:1998 Information

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 176 of 188

http://www.cryptomathic.com/products/easysign.html

http://www.ss.ca.gov/executive/ivote/

http://www.aceproject.org/


technology -- Abstract Syntax Notation One (ASN.1): Information object specification, available at www.iso.org

xxi. ISO/IEC 8825-1:1998 Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) , available at www.iso.org

xxii. Ivan Damgård, Mads Jurik: "A Generalisation, a Simplification and Some Applications of Paillier's Probabilistic Public-Key System", Public Key Cryptography, 119-136, 2001.

xxiii. Ivar Jacobson et al.: “Object – Oriented Software Engineering: A Use Case Driven Approach”. Addison – Wesley, 1992.

xxiv. Ivar Jacobson, Grady Booch, James Rumbaugh: “The Unified Software Development Process”. Addison – Wesley, 1999.

xxv. James Duncan Davidson, Danny Coward: “Java Servlet Specification v2.2”, Sun Microsystems 1999.

xxvi. Jason Hunter, William Crawford: “Java Servlet Programming”, O’Reilly 1998.

xxvii. Pascal Paillier: "Public-Key Cryptosystems based on Composite Degree Residue Classes". In Advances in Cryptology --- Proceedings of EUROCRYPT'99 (LNCS 1592), pages 223—238, Springer-Verlag, 1999.

xxviii. Peter Landrock "TTPs Overview - Concepts and Review of the State of Art from a Technological Point of View", 1997 Electronic Edition, Springer.

xxix. Ronald Cramer, Rosario Gennaro, Berry Schoenmakers: "A Secure and Optimally Efficient Multi-Authority Election Scheme". In Advances in Cryptology --- Proceedings of EUROCRYPT'97 (LNCS 1233), pages 103—118, Springer-Verlag, 1997

xxx. "Schoenmakers B., "Fully Auditable Electronic Secret-Ballot elections", XOOTIC, 2000"

xxxi. Stephen R. Schach: “Object-Oriented and Classical Software Engineering”, Mc Graw Hill, 2002.

xxxii. “The Java 2 Enterprise Edition Developer’s Guide”, Sun Microsystems 2000.

xxxiii. Voting Pilot in the local community of Høje Tåstrup, internal e-VOTE document, 2002

xxxiv. W. Richard Stevens: “UNIX – Network Programming”, Prentice Hall, 1990.

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 177 of 188

http://www.iso.org/

http://www.iso.org/


18 Appendix A - Questionnaires

18.1 Pre-Test Questionnaire

The purpose of this questionnaire was to gather information concerning the user’s background, his familiarity with the particular technology and his expectations from Internet Voting Systems.

1. Statistical information

Sex: Male Female

Age: >=18, <= 25 >=26, <=35

>=36, <= 45 >=46

Have you participated in an election before ? Yes No

If “YES” in what type of election process? ________________________________

Qualifications: _________________________________________________

2. Background information

a) Do you consider yourself as computer literate?Yes (explain ____________________________________________)

No

b) What type of computer do you use?Personal Computer

Workstation

Other _____________________________

c) What Operating System(s) do you use?Windows (95, 98, 2000, NT)

Unix / Linux / Solaris

Other _____________________________

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 178 of 188


c) Where and how often do you normally use a computer?

DailyOnce or more per

week

Once or more per

monthOccasionally Have never

used

at home

at school/college/university

at work

at public places (internet cafes, etc.)

Other:________________

d) How long have you been using the Internet?The e-VOTE evaluation is my first experience with Internet

Less than 6 months.

6 to 12 months.

More than 1 year

More than 2 years

More than 3 years.

e) What type of internet connection do you have at home?None

Modem

ISDN

DSL

Other: _____________________________

f) Which Web Browser do you normally use?Internet Explorer

Netscape Navigator

Other: _____________________________

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 179 of 188


g) What forms of electronic communication do you use?

DailyOnce or more per

week

Once or more per

monthOccasionally Have never

used

e-mail

WWW/Internet

ftp

Chat

Intranet (company network)

Other:________________

h) What is your level of knowledge/expertise on the following areas?

Low Adequate Very good Expert

Information Systems Security – Information Technology Security

Internet and Internet Security

Legal and regulatory framework on elections and data protection

Organisation and running of elections/ polls/referenda

Sociology and/or Psychology

i) Have you heard of or used “Electronic Voting” before?No

I have only heard of it

I have used it before

3. Political (voting) aspects

a) What is your involvement in public affairs?None

I am a member of a (student/professional/local etc.) union

I am an elected member of local/national authorities

I am a member of a political party

Other: _____________________________

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 180 of 188


b) How regularly do you vote ?

Never Rarely Often Always

General Elections

Internal/local elections

Referenda/Polls

c) How many times have you voted in an election?Never

Once

Twice or more

d) Do you have the option of voting from home (e.g. by mail) at General Elections?

If YES, how many times have you voted from home?_____________________________

if NO, how far is the voting center from home?

_____________________________

e) How do you ‘judge’ the ‘General Election Voting Process’ in your country?Easy to follow

Easy but tiring

Complicated

Not up to date

Other: __________________________

f) According to your opinion, if people had the option of voting from their home over the Internet, would the participation rate in elections increase?

Yes

No

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 181 of 188


g) Which of the following system characteristics do you consider as “dominant”, in a ‘positive’ or ‘negative’ sense, with regard to Internet Voting?

Ease of use (positive negative )

Accessibility (positive negative )

Availability (positive negative )

Complexity (positive negative )

Security (positive negative )

Other (please indicate)_____________________________

h) Do you trust the conventional way of voting?Yes

No

i) What is the level of trust you would have on an election conducted electronically over the Internet, as compared to the conventional process?

I would have the same amount of trust

I would trust the electronically conducted election less

I would trust the electronically conducted election more

j) For which kind of political elections should Electronic Voting Systems be used?They shouldn’t be used at all

They should only be used for simple referendums

They should only be used for polls

They should be used for any kind of elections (general elections, etc.)

k) Can you think of any other positive or negative aspects with respect to Electronic Voting?

Positive: __________________________

Negative: _________________________

4. Social aspects

a) According to your opinion, how likely is it in the future that voting over the Internet becomes part of our life? Can you give any reasons for your answer?

Unlikely, because: _____________________________

Quite likely, because: _____________________________

Very likely, because: _____________________________

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 182 of 188


b) How do you think that the problem of the ‘digital divide’ (discrimination between computer literate people and non-computer literate) will affect Internet voting in the future?

Digital divide will hinder the wide use of Internet Voting

Digital divide will not affect Internet voting significantly

5. General comments

Important Note : While participating in the test, casting you vote, and in order to answer the questions 3c, 3d and 3e of the post-test questionnaire, please remember to make a note of the following :

Time required to authenticate yourself

Time required for completing the entire voting procedure

Unavailability periods of the system

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 183 of 188


18.2 Post-Test Questionnaire

The purpose of this questionnaire was to gather information about the evaluation of the e-VOTE prototype 1 system. It can be noticed that some of the questions are the same with those in the pre-test questionnaire. The reason for this is to facilitate the comparison of the answers and thus identify the degree to which the e-VOTE system has influenced the user.

1. Tutorials & Help Information

a) How would you describe the information offered during the following services?

Insufficient Moderately satisfactory Satisfactory Too much

Credentials Validation

Ballot Management

Vote Cast

b) If you rated any services under a) with “Insufficient” or “Moderately satisfactory”, what was missing or should be improved?

Credentials Validation _____________________________________________

Ballot Management _____________________________________________

Vote Cast _____________________________________________

2. User-Friendliness

a) Were the following services easy to use?

Very easy Moderately easy

Moderately hard Hard

Credentials Validation

Ballot Management

Vote Cast

b) Did you encounter any problems/difficulties while using the e-VOTE system in any of the following? (If yes, please provide a short description)

No Service Yes

Authorisation / Credentials Validation

_____________________________

Voting _____________________________

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 184 of 188


3. Functional / Performance aspects

a) Did you face any functionality problems?No

Yes, ________________________

b) Did you identify any system deficiencies?No

Yes, ________________________

c) Are you satisfied with the time required to authenticate to the system? How long did it take?

No, it took me ____ seconds/minutes

Yes, it took me ____ seconds/minutes

d) Are you satisfied with the time required for completing the whole voting procedure? How long did it take?

No, it took me ____ minutes

Yes, it took me ____ minutes

e) Did you ever find the system unavailable? If so, for how long?No

Yes, it was unavailable for ____ minutes/hours

4. Security aspects

a) Are you convinced that the e-VOTE system provides the necessary level of security?

Yes, because ____________________________

No, because ____________________________

b) If you have answered question a) with “No”, do you think that electronic voting systems can be secure at all?

Yes, because ____________________________

No, because ____________________________

c) In what way would your level of trust, as far as the system security is concerned, be improved?

_____________________________

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 185 of 188


d) Are you interested in how security is achieved?Yes, because ____________________________

No, because ____________________________

5. Political (voting) aspects

a) Is there anything in the electronic voting procedure that you would like changed?Yes ______________________

No

b) Do you think that electronic voting is a good alternative to the existing procedure?Yes

No

c) According to your opinion, if people had the option of electronic voting, would the participation rate in election increase?

Yes

No

d) What is the level of trust you would have on an election conducted electronically over the Internet, as compared to the conventional process?

I would have the same amount of trust

I would trust the electronically conducted election less

I would trust the electronically conducted election more

e) What would you prefer, if you had the option of electronic voting?I would rather vote by going to a voting place.

I would rather vote by postal vote.

I would vote via an electronic voting system.

I would not vote at all.

f) Should electronic voting be the only option for someone to vote?Yes, because ____________________________

No, because ____________________________

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 186 of 188


6. Social aspects

a) According to your opinion, how likely is it in the future that voting over the Internet becomes part of our life?

Unlikely

Quite likely

Very likely

b) How do you think that the problem of the ‘digital divide’ (discrimination between computer literate people and non-computer literate) will affect Internet voting in the future?

Digital divide will hinder the wide use of Internet Voting

Digital divide will not affect Internet voting significantly

7. General comments

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 187 of 188


19 Appendix B – Ballot

Given below is a specimen of the ballot that was used during the simulated poll at the University of Essen. Please note that for reasons of simplicity and in order to ease the students (testers) it was decided to keep the German names of the lectures.

According to your opinion, which of the following lectures would you rate as the most interesting one?

Datenmodellierung und Datenbanksysteme

Grundlagen rechnergestützter betrieblicher Informationssysteme

IT – Organisation und Planung

Wirtschaftsinformatik I

Wirtschaftsinformatik II

Fallstudie „BWL“

Fallstudie „Wirtschaftsinformatik“

Informationssysteme I

Informationssysteme II

Informationssysteme III

Informationssysteme IV

Systemsicherheit I

Systemsicherheit II

Systemsicherheit III

Systemsicherheit IV

None (“white vote”)

e-VOTE/WP-7/D7.2/3.0/18-06-2002 Page 188 of 188

Date post:	05-May-2018
Category:	Documents
Upload:	nguyentuyen
View:	214 times
Download:	1 times

Deliverable D 7.2€¦ · Web viewAn Internet-Based Electronic Voting System (Contract Number:...

Documents