Keywords

1 Introduction

Since the first implementation of remote electronic voting in the 90s [4], the process of dissemination of internet voting did not meet the initial and promised expectations. Several countries experimented with the possibility of adding internet voting systems to their electionsFootnote 1, but it just turned into a reality in a reduced number of them: Estonia, Canada, Australia, Switzerland or Norway, amongst others. The Estonian case is the most prominent success story, using Internet Voting uninterruptedly since 2005 in all elections [1] an reaching high levels of acceptation [2] and cost efficiency [3, 4].

The dissemination of internet voting technologies is challenged by a complex set of factors that affect different layers of administration, law, society and technology [5] and that should be achieved in a constant dialogue between themselves: dealing with complexity in electoral management, reforming electoral laws, ensuring transparency, neutrality and participation and ensuring secure and risk-free technological apparatus. The latter factor, has been constantly labelled as an important element not only for the correct functioning of the internet voting and its integration in the electoral systems, but also as an element projecting trust in the society where the system is being implemented [6,7,8].

Pursuing the same goal, the creation of trust as a key element for the adoption of internet voting systems, the Council of Europe (CoE) proposes a set of recommendations to guide the process of implementation of electronic remote voting systems [9]. The CM/Rec(2017)5 updates the previous Recommendations from 2004 and integrates lessons learned from previous experiences and developments in the electoral field to create a useful and up-to-date document. Specifically, proposes a set of Principles, Standards and Requirements that every electronic voting system should fulfil for the development of elections and for reinforcing the democratic principles that are the common heritage of its member states [10]: Elections should be Universal, Equal, Free and Secret, should meet a set of regulatory and organizational requirements, should be transparent and allow observation and should be accountable, and should use reliable and secure systems.

In view of the aforementioned list, this paper presents an analysis on how the system nVotes fits within the CoE requirements. The ultimate goal of the authors is not to judge from a rigid immovable or infallible point of view for the sake of pin pointing shortcomings, but to establish a comprehensive, multi-faceted evaluation in order to improve the knowledge and security level in the deployment of e-voting systems.

2 Related Works

The research work of Bräunlich, Grimm and Richter in 2013 [111] is considered one of the most relevant to date. The authors presented the first interdisciplinary collaboration which has transformed legal requirements into technical criteria. Specifically, they established thirty Technical Design Goals (TDG), using the KORA methodology (Konkretis-ierung Rechtlicher Inforderungen, Concretization of Legal Requirements) [12]. This methodology had been used previously for mobile devices amongst others.

Neumann combined the previous methodology of Bräunlich, Grimm and Richter with the Common Criteria for IT-Security Evaluation [13] and established sixteen technical requirements to relate the legal criteria to Bräunlich’s TDGs.

While Neumann’s work [14] has critically contributed to constructing a very valuable framework, it still had room for improvement from a practical standpoint:

On the one hand, the security evaluation framework is aimed at schemes rather than entire systems, with the author himself coming across an example of a structural flaw that would not be identified using his evaluation scheme: “for instance, the Vote Forwarding Server and the Vote Storage Server of the Estonian Internet voting scheme are developed and maintained by the same vendor” [14, p. 135].

Additionally, the security evaluation assumes that the voters will use the authentication tools sufficiently. Unfortunately, the tendency of the voters is not to verify: for instance, one of the largest electoral e-voting initiatives which took place in New South Wales in 2015, showed that only 1.7% of 283.669 votes were verified [15].

Furthermore, Neumann’s framework is based on probabilistic attack strategies through Monte-Carlo simulations [14]. While represeting an interesting approach indeed, it is less useful for a practical evaluation standpoint. As a result, the author concludes: “we therefore recommend to incorporate the security evaluation framework into a larger decision-support system for elections officials” [14, p. 138].

Following with the above recommendation, a decision-support system was proposed by Marcos, et al. as a practical evaluation framework [16]. It is in accordance with the guidelines from the 2017 Council of Europe’s (“Guidelines on the implementation of the provisions of Recommendation CM/Rec(2017)5 on standards for e-voting”) [17] and deals with the five key principles of a democratic election (universal, free, equal, direct and secret) detailed in the same document.

3 Evaluation Methodology

As previously stated, while Neumann’s work set out an irrefutable improvement, it constitutes a scheme evaluation tool with probabilistic proofs as its core with Monte-Carlo simulations rather than a practical evaluation framework tool for election officials and other stakeholders involved in the democratic processes.

In 2018, Panizo et al. proposed an extended evaluation approach [19] in the context of the Spanish Constitution [18] and the CoE’s e-voting recommendations [17]:

  1. 1.

    Defining an homogeneous series of e-voting requirements with the KORA methodology [12] as its basis, together with the CC and ISO 27001-IT Grundschutz guideline [13], their assimilation by Simic-Draws et al. [20], the Guidelines of the Council of Europe [17] and Neumann’s methodology [14].

  2. 2.

    Formal conformity between point 1 and Bräunlich’s TDG’s [11], as in Fig. 1.

  3. 3.

    Consultation with more than 30 international experts in e-voting (Research and Industry Experts or RIE, selected using the snowball [21] and judgement [22] sampling methodologies) to review the evaluation framework and add weighting factors.

  4. 4.

    Formal definition of the practical evaluation framework, including two sine-qua-non requirements (E2Ev and Coercion Resistance) and 41 evaluation items.

    Fig. 1.
    figure 1

    Integration of Panizo [19] and Bräunlich [11]

    Full size image

The work in [16] established for the first time a correlation between the end to end verifiability (E2Ev) and coercion resistance (CR) to the legal requirements for a democratic process and the Council of Europe:“The five key principles of electoral law are: universal, equal, free, direct and secret suffrage and they are at the root of democracy” (article 68 of the Spanish Constitution [18]).

Specifically, Marcos et al. Set out the equivalence of the aforementioned five key principles, into a formal authentication of the E2Ev the universal, free, equal and direct properties and its coercion resistance for the secrecy prerequisite (based on the findings by Hirt and Sako on the matter in [46]).

The methodology presented to this point is solid from a legal point of view but still lacks the technical and practical approach necessary for a complete evaluation.

In order to solve the shortcomings, five practical requisites were introduced, partially based on the research by Benaloh, Rivest, Ryan and Volkamer [23, 24]. Subsequently, the requisites were codified, refined and subdivided into 73 specific items by means of a partial application of Zissis and Lekkas [25] and New Zealand’s Department of Internal Affair’s Communication on e-voting [26]Footnote 2.

As a final step, e-voting RIEs from Canada, France, Norway, Switzerland, Germany and Spain among other countries were consulted to assign a weighting factors.

The following Fig. 2 visually represents the complete evaluation methodology:

Fig. 2.
figure 2

Complete evaluation framework [16]

Full size image

The sine-qua-non requirements (end-to-end verifiability and coercion resistance, representing the five compulsory principles of a democratic election), which evaluation is not a numerical value related to performance but instead in terms of “holds” (○) or “does not hold” (×). There is a third possibility, when the property “stands under determined, credible assumptions” (∆).

The second quantifiable and additional criteria, totaling 10 requirements, are evaluated from 0 to 10. In order to obtain the numerical evaluation for each criterion, the corresponding measurable sub-items are evaluated with three possible outcomes: non-compliant (×), partially compliant (∆) and compliant (○).

Due to space constraints, the evaluation framework design, implementation and constituent requirements has been simplified. For a full explanation, the reader can refer to Dr. Marcos’ Ph.D. thesis which originated the methodology [27].

It is relevant to mention that this practical evaluation methodology has also been applied to Helios Voting and published by the IEEE [19].

4 nVotes Analysis

4.1 Introduction

nVotes [28] is a remote e-voting system developed by the Spanish company Agora Voting SL in 2014. Its roots trace back to 2009 and the Internet Party, although the developing team has since then dropped any political affiliation and nVotes is currently an apolitical project.

Until 2017, nVotes was known as Agora Voting and under such moniker it was one of the 18 European start-ups to be accepted in the Impact Accelerator project, and awarded with 100,000 EUR [29].

According to their website, nVotes has been used to cast over 2 million votes for over 150 clients, including Public Administrations like the Barcelona Provincial Council, Madrid City Council; Political Parties like Podemos, Ahora Madrid and Barcelona en Comú, as well as Education Institutions like UNED University in Spain.

4.2 Main Characteristics

As previously mentioned, the methodology presented in Sect. 3 has been already applied to other relevant e-voting tools, including Helios Voting [19] or iVote by Scytl [30]; in both cases with numerous bibliography and research resources available:

  • Helios Voting is a very well-known open source e-voting system [31], which has been used as blueprint for several variations and improvements such as Helios KTV [32] or Belenios [33].

  • Scytl is probably the most widely used e-voting system at a global level, including numerous legally-binding elections and pilots for a total of over 100,000 processes managed and more than 200 employees. The information available ranges from research papers to Government reports and corporate presentations.

In the case of of nVotes, the available bibliography is much more limited due to the fact that they are neither a research standard tool, nor a global company. In order to complement the publicly available information, the authors of this document got in touch with nVotes and they key people have always been open and supporting in providing all the available information and answers to the questions raised.

Additionally, the authors were provided with two documents named “Technical Overview” and “Client Action Protocol”, which have been extremely useful for conducting the analysis. They are at the reader’s disposal upon request to the authors since they have not been published before.

nVotes Scheme Components and Cryptographic Primitives.

According to the information included in the “Technical Overview” and complemented with a Q/A with nVotes technical team, the key elements are:

  • Registry: The registration database programmed in Python. It includes the SMS service platform Esendex [34], server certificate with TSL support, Cloudfare [35] and Fail2ban [36] for protection against DDoS attacks and hardware redundancy 1 + 1.

  • Virtual Polling Station: TLS server validation, cast-or-audit voting javascript (similar to that of Helios Voting [31]), random number generator (not specified), HMAC client authentication, Election Manager with Scala REST API, Postgresql database and similar to the Registry case, Cloudfare and Fail2ban DDoS protection.

  • Electoral Authority: HTTP distributed queue, TLS client/server authentication, mixnet library Verificatum [37] and tabulation library OpenSTV [38].

  • Election Verificator: a Python/Java.

With regards to the main cryptographic primitives, they are the following:

  • El Gamal Homomorphic Encryption [39]

  • Pedersen Threshold Distributed Key Generator [40]

  • Verificatum verifiable mixnet [37]

  • Fiat-Shamir heuristic to convert Zero Knowledge Proofs into Non-Iteractive Zero Knowledge Proofs [41]

  • Schnorr Signature [42] to make the ElGamal Encryption IND-CCA2.

nVotes Voting Sequence.

As presented in the “Technical Review” and “Client Action Protocol” documents, the voting procedure is as follows:

  1. 1.

    Authorities distributedly generate the Election’s Public Key with Pedersen [40].

  2. 2.

    Eve (voter) access the Registry site and provides the required personal information, including a security code which has been sent independently by SMS.

  3. 3.

    The Registry system compares the information provided with the census. If it is correct, Eve is forwarded to the Virtual Polling Station.

  4. 4.

    Eve fills her vote, encrypts it and sends it. Alternatively, she can audit it but in such case, the cast vote is no longer valid and will not be tallied. This cast-or-audit approach is also implemented in Helios Voting [31].

  5. 5.

    Once the vote casting period ends, the authorities jointly proceed with the mix and decryption of the ballots.

  6. 6.

    The decrypted votes are tallied.

  7. 7.

    The election results are published, together with the tally results, the vote’s ciphertexts as well as the mixnet and decryption Zero Knowledge Proofs.

  8. 8.

    Voters and third parties can download and execute the election verificator.

Once nVotes has been introduced, together with its associated scheme components, cryptographic primitives and voting process, the practical evaluation methodology for e-voting systems [16] can be applied.

The analysis is intended to be a sort of a guideline, which introduces strengths and potential weaknesses in order to establish a safe range if utilization and to offer directions as to how to improve the voting system.

4.3 End to End Verifiability

Unfortunately, there is no formal, universal definition for end-to-end verifiability (E2Ev). Additionally, symbolic analysis of security protocols still find associative and commutative operators are out of reach. It is then not possible to analyze a homomorphic property [43] such as:

$$ {\text{enc}}\left( {{\text{pk}};{\text{ v}}_{ 1} } \right) \, \,* \, \,{\text{enc}}\left( {{\text{pk}};{\text{ v}}_{ 2} } \right)\, = \,{\text{enc}}\left( {{\text{pk}};{\text{ v}}_{ 1} \, + \,{\text{v}}_{ 2} } \right) $$
(1)

and therefore, a case by case analysis has to be conducted for each system.

Currently, probably the most widely accepted definition of E2Ev is the one by Benaloh et al. in [23] and is comprised of the properties: “Cast as intended”, “Recorded as cast” and “Tallied as recorded”.

For the first and second items, nVotes presents a similar approach to that of Helios Voting: the voter can audit her vote until she is convinced that it is trustable. Once cast, she receives a hash of the encrypted vote, which she can check on public bulletin board. Finally, for the tallied as recorded condition, ElGamal together with Verificatum mixnet [37] and Schnorr [42] are implemented.

Consequently, on the question of nVotes being E2Ev or not and similar to the analysis in [18] for Helios Voting, it can be considered end to end verifiable assuming that:

  • The cast and audit mechanism is used by a large enough number of voters so that ballot alteration will not go unnoticed.

  • The Election Authorities and the Bulletin Board (BB) are honest.

  • An attack which gains control of the Registry/Ballot is detected.

For the first precondition, Acemyan in [44] and the New South Wales case [15] have shown that voters’ ballot verification percentage is quite low and they should not be responsible of part of the security of an e-voting system.

As for the other two prerequisites, in a perfect scenario nVotes would be compliant but in real elections, both the Election Authorities and/or the BB can illegally introduce votes (ballot stuffing). For public, legally binding elections, it is not acceptable.

To sum up, provided that nVotes implementation is limited to elections with a low risk of corruption such as student government bodies, local clubs, online groups, and other education-related organizations, the pre-assumptions could be acceptable. For other, more demanding types of elections, E2Ev cannot be recommended.

Evaluation:

∆. E2Ev holds if the preconditions set in nVotes’ Technical Overview document are accepted and its use is limited to low corruption risk elections.

4.4 Coercion Resistance

Assuming probably the most accepted definition of privacy levels by Juels et al. [45] and the proof by Hirt and Sako [46] that receipt-freeness is not enough for preserving it in electronic elections, the required level is Coercion Resistance. It implies that a voter cannot provide to an attacker any proof of her vote or even whether she voted or nor, even if she is willing to cooperate.

As for nVotes, the voter receives a verification code after casting the ballot, therefore she can prove it to a potential attacker.

Additionally, the Election Administrator of an Election can verify whether an specific person in the census has voted or not, which clearly compromises the privacy.

Evaluation: X.

Does not hold.

4.5 Inviolability (I-n)

nVotes’ Technical Overview document includes an integrity, privacy and availability analysis. The authors include the possibility of “ballot stuffing” if the Election Administrators are corrupt and of DDoS attacks despite implementing specific tools [35, 36].

There have also been questions raised about the census integrity used in consultative referenda [47, 48] and the separation between the tally administrator and the census administrator, which can be the same person and thus lead to potential collusions (I-4).

Safe authentication protocols, tracking tools, Risk Assessment and modularity principles are partially compliant, with room for improvement (Table 1).

Table 1. Inviolability in nVotes
Full size table

Evaluation: 4/10 Points.

The inviolability policy presents vulnerabilities which, for private elections (while being very serious), are ultimately up to the organizer whether to take the risk or not. For legally binding public elections, they are not acceptable and nVotes inviolability should be improved before being used in such environment.

4.6 Usability (U-n)

nVotes presents a satisfactory performance in terms of simplicity and clarity in the voting process (U-1, U-3) as well as in intuitiveness and lexicon choice both for the voter and the administrators.

Concerning the aspects to be improved, there is no version adapted to collectives with special needs, the SMS authentication might prove challenging for the elders and the verification codes are too long and “imposing” voters with no technical background. An intermediate usability layer might be advisable. Overall, usability is satisfactory while it could be enhance with some simple, easy to implement changes (Table 2).

Table 2. Usability in nVotes
Full size table

Evaluation: 6/10 points.

4.7 Monitoring/Auditing (MA-n)

This aspect is especially relevant for nVotes due to the possibility of Ballot Stuffing if the Administrators are corrupt or collide or due to DDoS attacks.

Probably due to the nature and scope of the elections managed, the Monitoring and Auditing Protocol is based on the Administrators training. According to nVotes’ team, a unified protocol including all the auditing activities is currently being generated.

Until then, nVotes generates retrievable logs, and provides information and data in an easily understandable format. Even so, at this point the Monitoring/Auditing Protocol is still largely to be developed and implemented; therefore not satisfactory (Table 3).

Table 3. Monitoring/Auditing in nVotes
Full size table

Evaluation: 3/10 points.

4.8 Software Development (SWD-n)

nVotes displays an overall solid Software Development (partly because of its open source approach), with a satisfactory performance in usual software engineering practices (SWD-1), FAQ (SWD-4), impartiality (SWD-5), ballot cast termination (SWD-8), compatibility (SWD-9), third party access (SWD-10), and protocolized application (SWD-13).

Regarding the distributed approach (SWD-2), it has been correctly implemented for key generation and encryption/decryption but there is no separation between the census and the bulletin board. If the same person is responsible for both of them, there is an important risk of collusion.

Finally, the primitives are well implemented but some of them have been already been proven flawed and should be reviewed (SWD-11). Additionally, more frequent updates would be preferable (SWD-14) (Table 4).

Table 4. Software Development in nVotes
Full size table

Evaluation: 7/10 points.

4.9 Scalability (S-n)

nVotes has managed elections up to 150,000 votes in consultative referenda of political parties, although they didn’t managed many of the ex_software activities, which were handled by the Party itself.

So far, the system has proved to be scalable to the amount of votes already managed in private elections. The shortcomings related to monitoring, ex-software development and potential collusion request a further in-depth improvement before being considered for introduction in public binding elections (Table 5).

Table 5. Scalability in nVotes
Full size table

Evaluation: 5.5/10 points.

4.10 Ex-Software Development (ESWD-n)

Ex_Software development is intimately related to the increased complexity of public binding elections. The lower the score in this category, the less recommended it is for the analyzed e-voting system to be implemented for such type of elections.

In the case of nVotes, it has been deployed only for private elections and referenda, and therefore has not implemented ESWD1-4, ESWD6-7, and ESWD-10.

The aspects in which the development is satisfactory are: authentication by alternative channels (ESWD-11) and the master initialization protocol (ESWD-12).

As for the communication/problem solving/back up policy (ESWD5, 6, 8, 9, 14, 15), nVotes stated that they offer different levels of services according to the needs and budget of each election. They can even let the client handle most of the activities related to back-up protocols, responsibilities attributions etc.

While that could make sense from a business perspective, the security implications in case of a misuse or a scandal, and the potential impact in the reputation of nVotes, advice against allowing the election organizer to handle such sensitive actions (Table 6).

Table 6. Ex_Software Development in nVotes
Full size table

Evaluation: 4/10 points.

4.11 Incidents and Attacks Protocol (IAP-n)

Due to the track record of elections managed by nVotes, they do not have a proper protocol in place, presenting only partial compliance in distributed/modular approach and actions taken towards limiting the risk of an attack with the introduction of Cloudfare [35] and Fail2Ban services [36].

In conclusion, nVotes needs to develop a proper Incidents and Attacks Protocol before being used for legally binding, public elections (Table 7).

Table 7. Incidents and Attacks protocol in nVotes
Full size table

Evaluation: 4/10 points.

4.12 Versatility (V-n)

nVotes can be used by the voter with a standard internet connection, hardware and Operative System. While it works in most of the available browsers and devices, there is no compatibility study available.

Regarding the existence of different versions depending on the type of election (yes/no, 1/N, N/M, order etc.) there are no adapted versions but according to the data in Verificatum [37], its performance is satisfactory enough to not require adapted versions. The authors believe that such statement is only partially true and largely depends on the range of the election.

Finally, the score against the WCAG 2.0 standard was good but not brilliant (A) (Table 8).

Table 8. Versatility in nVotes
Full size table

Evaluation: 5/10 points.

4.13 Cost (C-n)

Cost in a sensitive issue for e-voting systems. Most of them are not transparent in their pricing policy. That is understandable to a certain point, but even the cheapest option should offer a sufficient security level.

nVotes used to have a very clear, direct policy with 3 plans with a fix cost of 0.2 EUR per voter plus other associated costs. In its simplest version, it was possible to organize a 1.000 voter election with all the required elements for a little over 1.000 EUR. Currently, the policy has changed and there is no clear indication of the cost for the organization of an election.

While probably still an affordable option, the authors believe that the previous, more transparent approach was better from a user’s point of view (Table 9).

Table 9. Cost in nVotes
Full size table

Evaluation: Review (6/10 points).

4.14 Maintenance (M-n)

Both from a software and ex-software perspective. On the software side, nVotes is an open source project and therefore very open and verifiable. It is regularly updated. Regarding the ex_software aspect, there is not much improvement and it would be very advisable in order to extend the safe utilization range of the system.

As for everlasting privacy and post-quantum security, nVotes team is working on it but there is no expected imminent announcement.

Finally, the maintenance cost is quite limited and performed internally (Table 10).

Table 10. Maintenance in nVotes
Full size table

Evaluation: 6.5/10 points.

5 Final Results and Conclusion

nVotes [218] is a remote e-voting system developed by the Spanish company Agora Voting SL and active since 2014. It has managed a total of 2 million votes with up to 150.000 votes in the same election.

In order to complement the relatively limited publicly available information for the analysis in this article, they have been diligent and helpful and the authors with like to extend their gratitude for their availability.

The ultimate goal of the analysis is not to judge from a rigid, “infallible” perspective for the sake of it, but to try contribute to a gradual and secure implementation of e-voting solutions in the democratic processes.

The formula and table below summarize the findings and scores of nVotes (Table 11):

Table 11. Practical Evaltuation Methodology [16] applied to nVotes
Full size table
$$ \sum\nolimits_{i = 1}^{n} {\frac{{f_{1} \cdot w_{1} + \cdots + f_{n} \cdot w_{n} }}{n}} \cdot \frac{n}{t} = \sum\nolimits_{i = 1}^{n} {\frac{{f_{1} \cdot w_{1} + \cdots + f_{n} \cdot w_{n} }}{t}} $$
(2)

Due to the nature of the elections in which nVotes has been deployed, it is in an intermediate position between Helios Voting and Scytl’s iVote systems. nVotes can manage elections with a number of voters that Helios Voting has not been able to proof so far while showing serious shortcomings in legally binding elections, where a strong infrastructure, ex-software policies and monitoring/auditing protocols are a must.

Therefore, currently nVotes’ safe range of use is that of private elections.

The areas in which nVotes presents a stronger performance are:

  • Open source approach, with good software engineering and possibility of review by researchers/academia.

  • Intuitive, simple and user-friendly interface for both the voter and the administrators.

  • Compatibility.

  • Open standards, modularity.

  • Support service during the elections.

Conversely, the aspects which should be improved include:

  • No proper Audit/Monitoring or Incidents/Attacks protocols in place

  • Policy for credential, access and permit distribution. Currently allows for collusion to happen between the census administrator and the election administrator

  • Ex_software development

  • Certain cryptographic primitives implemented are vulnerable [41]

  • No version for voters with special needs

Additionally, the election administrator can know whether a voter has voted or not and a voter with a fake ID might be able to authenticate to vote. Even for private elections, it should be an issue to be solved.

In short and considering all the points reviewed in the analysis, the authors estimate that nVotes is currently not ready to be introduced for public, politically binding elections due to the limitations in auditing, monitoring, backup and potential collusion. Its current secure rage is that of private elections, always taking into account the highly recommended distribution of administrative roles.

To conclude, the authors hope that it can contribute, even if modestly, to improve the knowledge and security level in the deployment of e-voting systems, through the comprehensive, multi-faceted results presented. Nonetheless, in order to make the best possible decision, Elections Officials should also consider complementing the information contained in this document with other inputs from different, more atomistic and cryptographically formal analyses.