Internet voting feasibility study

Transcription

1 Internet voting feasibility study A summary Table of contents Introduction... 2 System functionality... 3 System requirements... 5 Information security... 6 Additional requirements concerning information security... 6 Residual threats Cost and benefit analysis... 8 Benefits... 8 Costs... 8 Cost factors... 8 Implementation alternatives... 9 Quality goals Integration with other systems Procuring the system and market overview Plan for implementation and deployment Summary v 1.0 1

2 Introduction On the request by the Ministry of Justice its Action Programme on eservices and edemocracy (SADe) and eparticipation Environment Project, Codento was asked to conduct a feasibility study on internet voting and its viability in Finland. Codento arranged three workshops with the internet voting working group and its appointed experts. The workshops yielded a 25-page feasibility study document of which this document is a summary. By internet voting, in this context, we understand voting in a consultative communal referendum by using voters own terminal equipment (desktop and laptop computers, tablets and mobile phone). Legally binding elections were not a main interestest of the feasibility study. Provisions on consultative municipal referenda are laid down by an act. According to the act on the procedure for holding municipal consultative referenda (656/1990), the voters can vote either by mail in advance (i.e. postal voting) or at a polling station during the voting day. When voting by mail, the voter encloses his/her vote in an envelope together with other identifying material and sends the envelop to the central election committee. The intention is to introduce internet voting along with other voting channels.. The current procedure of postal voting is so cumbersome that large cities are unable to arrange consultative referenda. Consultative referenda have less strict information security requirements than binding elections. Thus, a system which is secure enough for referenda is not secure enough for elections. Furthermore, it is not easy, if at all possible, to turn a referenda voting system into election voting system. This feasibility study deal with election related issues and considerations in less detailed manner than referenda. The Finnish government can either get a referendum voting system implemented by selected software companies or buy an already implemented system from the market. In order to decide v 1.0 2

3 which approach is the most suitable one, this document explores alternative ways of implementing the system. System functionality Internet voting is suitable for replacing or complementing voting by mail in advance before the actual voting / polling day. This is the simplest and easiest to understand alternative. Allowing voters to vote via internet during election day causes hard to solve complexities and information security issues. The internet voting system for consultative referenda works as follows. The systems has the following components Device for identifying the voter and performing cryptographic operations (secure ID card or mobile phone with security device or similar) Voter s terminal Voting application VETUMA - the identity service v 1.0 3

4 Voting server Ballot box database Tallying server Result database The system works as follows 1: The tallying server sends the public key K2 of the election committee to the voting server. 2: The voter downloads the voting application. The application can be either a native application for voter s terminal or a javascript application. 3: The voter identifies himself/herself using some method provided by VETUMA. The terminal gets to know voter s identity, or ID. 4: The terminal asks the voting server for referendum information (alternatives, voting area, etc) by giving voter s ID. 5: The voting server gives voter s terminal the public key K2. 6: The voter casts his/her vote V by using the voting application. 7: The terminal encrypts the vote using key K2. The result is K2(v). 8. The terminal uses the cryptographic device and signs the vote K2(V) and identity ID. The result is K1(K2(V), ID). 9: The terminal sends K1(K2(V), ID) to the voting server. 10: The voting server identifies the voter using the public key corresponding to the private key K1 and saves the pair (K2(V), ID) to the ballot box database. If the voter casts several votes, the last one counts. 11: When the referendum closes, the voting server sends all encrypted votes to the tallying server. v 1.0 4

5 12: The tallying server uses its private key and decrypts the votes and saves them in the result database. The tallying server than counts the votes and publishes the referendum result. The key K1 is necessary for preventing man-in-the-middle attacks. The referendum system may be secure enough without key K1 since the current voting by mail is not secure either. This system relies on trusting the voting application. If an attacker can replace the voting application, he can changes voters votes. Detecting this is very hard. System requirements There are some fundamental requirements for the referendum systems, or internet voting system in general. In addition the these requirements, there are some information security requirements, of which more details later. V1: Reliable identification of voter s identity and suffrage V2: One vote for one voter V3: Voting security, or secrecy of votes V4: Immutability of cast votes V5: Voter must be able to ensure himself/herself that the votes has been handled and saved by the system correctly. V6: The voter must be able to know, that the vote has been tallied properly. V7: Reliable verification of the voting results after the initial tallying. V8: Internet voting must be possible with common terminal devices. V9: The Finnish State must be the owner and administrator of the voting system. v 1.0 5

6 V10: The system and its source code must be available for inspection to citizens, organisations, experts, and election observers. V11: The system must be usable for people with disabilities. V12: The system must be impartial. V13a: The system must be compatible with the current voting administration system. V13b: The system must work without the current voting administration system. The system presented above does not meet requirements V5 and V6.This is acceptable since the current procedure - voting by mail - does not meet the requirements either. Information security Analysing information security of the proposed system is not straightforward for several reason. First, the exact purpose and use of the system is not yet clear, mostly due to missing legislation. Second, even though the system is intended for referenda, there were discussions about using similar kind of system for binging elections. The risks and threats differ significantly between referenda and elections. In addition, information security community insist on starting from most demanding scenarios. In this case, that would be elections, which were not the main concern here. The most significant threats are The selected vendor may not be able to build secure enough a system Security of voters terminals and their software. Denial of service attacks against the referendum system or some other essential, integrated system. Operator errors and mistakes. Missing or ignored security procedures. Lack of vigilance while an referendum is ongoing. Additional requirements concerning information security There are several additional system requirements from the information security point of view. v 1.0 6

7 V14: The system must be able to handle information of ST 1 IV security level. Some functional requirements may require even ST III level. Should the system be designed for elections, the requirement would be even stricted (ST II). V15: The level of information security of the system must be elevated. V16: The level of ICT preparedness of the system must be high. V17: Should the system be used during the election/referendum day, its availability must exceed JHS 174 requirements. V18: The design of referendum processes, including creation of key pairs, must be very careful in order to minimize any errors. V19: Referendum processes must be carried out with care and must yield documented and verifiable results. V20: The system must keep comprehensive logs at several levels (operating system, communication, database, application). The logs must be designed so that no combination of them breaks the secrecy of referendum. V21: The system must allow and enable OSCE election monitoring. V22: There must be enough resources for detecting and preventing information security threats and attacks during the referendum/elections. V23: No single person must be able to manipulate the results. Residual threats. The following threats will remain even after the previous requirements are met. 1 ST = suojaustaso, or Protection Level v 1.0 7

8 Security of voting depends of security of users terminals. It is very hard to make sure that the terminals do not contain any malicious software and work as intended. If key K1 is not used (see figure 1), this is next to impossible. The vendor of the system and its employees play a key role in information security. In case they are not trustworthy, the system will not be. This can be mitigated by third-party testing, open sourcing the code, etc, but some risk remains. The staff operating the system will have wide permission in order to operate the system. Novel methods must be devised to prevent them abusing their permissions. The system depends on external systems (e.g VETUMA identity verification system for user identification). Any denial of service attacks may cripple the referendum system. The notion of archiving is open. Any long term archiving is a risk. These residual risks must be mitigated before the system is taken into use. Cost and benefit analysis Benefits The main benefits of internet voting are: less manual work required more participation in the democratic processes possibility to arrange referenda in large cities voting easier for disabled people easier voting abroad Only the first benefit can be readily studies in terms of money. In short, elections in Finland tend to cost about 5 /vote, ⅔ of which is administration and manual counting costs.this is the amount which might be saved by using internet voting. Costs Cost factors There are several alternative systems, costs of which we consider. In order of increasin cost, the alternative are: 1. Only checking voters identities, voting in advance with together letter voting, voting only once, no voting on election day. v 1.0 8

9 2. As with #1, but possibly voting many times, the last vote counts. 3. As with #2, but also voting during election day. 4. As with #1, but encrypting/signing the vote 5. As with #2, but encrypting/signing the vote 6. As with #3, but encrypting/signing the vote Implementation alternatives The cheapest alternative is the #1. It costs more or less twice the amount kansalaisaloite.fi cost. Alternative #2 requires the servers to identify votes and only count the last vote (by internet or by mail). Alternative #3 requires high availability and fault tolerance. The alternatives #4, #5 and #6 require encryption and electronic signatures, which in turn require some equipment to perform the operations. Since referenda do not require this level of information security, we shall not estimate the costs of these alternatives. We estimate the following cost structure for systems #1, #2 and #3. Maintenance includes system maintenance, bug corrections and small improvements as well server costs and similar. Operation includes personnel costs in operations and monitoring. System Procurement Annual maintenance Annual operations System #1: kansalaisaloite + ballot box System #2. 1+enhanced terminal SW + secure ballot box System #3. 2+ dublication + high availability X X/6 100 k 1.5 * X = Y Y/6 100 k 3.25 * X = Z Z/6 200 k Including electronic signature would add 20% to these costs. We can compare the costs to the benefits (saving 4 per vote) if we make the following assumptions. several ballots ongoing at any time v 1.0 9

10 procurement cost euros maintenance euros a year operations euros a year, twice that for the high-availability system depreciation in 5 years Internet votings saves 1,5 per vote as a conservative estimate These assumptions give break-even points for system #2 and #3 as and voters per year, respectively. The following table shows the exact numbers. Annual expenses System Procurement cost Depreciation, 5 years Maintenan ce Operations Annual votes required for breakeven 1. Only voter identification, no multiple voting, advance voting only 2. As #1, but possibility to vote many times (last vote counts) 3. As #2, but also voting during election day 0% % % % % % % % % The table shows also ±30% confidence levels. v

11 The number of annual votes required for break-even are quite low. This means that from costbenefit point of view, a system for internet voting in non-binding referenda would make sense. For binding elections, the cost estimates are much higher due to stricter security requirements. Furthermore, it is not feasible to try to develop an election system from referendum system. Adding security is usually much harder than relaxing security. Quality goals The internet voting system has high quality goals. Only a high quality system will be dependable and gain the trust of voters and society in general. High quality comes from being open source, being audited and verified by several independent people and organizations. The system must be open for inspection. In addition to audits, the software development process used for implementing the system must be of high quality. This includes requirements analysis and tracing, automated building and testing, comprehensive code reviews and understanding the assumptions on which the system relies. Integration with other systems The internet voting systems is not a stand-alone system. It needs services from other systems. The most important integrations are Election information system (vaalitietojärjestelmä) Population information register (väestötietojärjestelmä) VETUMA identity system Operation systems Monitoring systems Users terminals The election information system provides information about voters, voting districts, and similar issues. It also provides results for media. The internet voting system would benefit from using these existing services. v

12 Population information register can provide information about voting districts and voters in case the election information systems is not used due to e.g. cost issues. This maybe be the case with referenda, but not with proper elections. VETUMA verifies identities of voters and election officials. It does not provide electronic signatures and thus some other system is necessary for that. In the figure 1, the K1 is used for signatures. The operators use operation systems. They are, in fact, part of the internet voting system and created by the same vendors. The monitoring systems are necessary for verifying that the internet voting system works as it should and that there are no attacks on it. Monitoring systems must provide write-only-once logging services. The users of operation and monitoring systems must not be same individuals. Users terminals must be able to perform the necessary operation without risking the secrecy and security of voting: signing and encrypting the vote, making sure that the vote was cast properly all the way to the result server. Even though any modern terminal should be usable, there may well be some restrictions (e.g. voting and verifying using different terminals as in Estonia s case, etc). Procuring the system and market overview The internet voting system should be open source, since no closed system would gain enough trust. Without trust, the system would not be used and voting results might be easily contested. During the market survey in 2014, no vendor was willing to provide an open source system. This is not a big problem, since implementing a system for internet referendums is well within capabilities many Finnish software companies. There should not be any problems with finding companies willing to use open source. It is recommendable to procure an open-source systems from a vendor that uses agile, iterative development processes. The processes will also allow procuring work from competent designers and coders from many companies. For a referenda system, a team of less than 10 competent designers, coders, testers and security experts will be sufficient. v

13 Plan for implementation and deployment The internet voting should be implemented in increments. Also, its deployment should be incremental, done with several pilot deployments. The pilots should proceed from simple, notso-important cases towards referenda. This way it will be possible to take user feedback into account. Summary As a summary, the following observations arise. A system for conducting referenda in the internet is rather light weight and simple to implement. Procuring such a system is recommendable, since its usage would create significant experiences for refining requirements of a proper internet election system. The systems for referenda and elections are so different, that a single system is not sufficient. The referenda system can and should be deployed incrementally. A system for proper, binding elections is most likely rather expensive to implement. Conducting proper elections via internet is very difficult given the current state-of-the art information security knowledge. If the referenda system is in use during the referendum day, it will be very hard to recover from any errors or attacks. The system will not be very reliable. Use of internet voting during the referendum/election day is not recommendable. If an attacker is able to alter the voting software in users terminals, the attacker can change votes at will. Preventing this kind of attack is extremely hard. v