Keywords

1 Introduction

In on-site elections, voter’s privacy and ballot integrity are protected by guaranteeing physical isolation when casting the ballot, and through a set of audit procedures by multiple and independent trustees. Internet voting (i-voting) eludes the call for physical presence of the agents involved in the voting process, which eases both the voting experience and the tallying process. Certainly, i-voting enables voters’ ubiquity and the use of any personal device to cast a vote, and its digital nature makes it possible to conduct the whole election process without human intervention. Nonetheless, i-voting comes with several risks and pitfalls: the voter may cast the vote from anywhere, resulting in high possibility of coercion or vote-selling; the vote cast could go through an uncontrolled channel; remote authentication increases the chances of impersonation, and moreover, the voter casts a vote from her device, making it difficult to do a massive-scale, effective security assessment [14].

An electronic voting protocol must satisfy four main properties [4]: universal verifiability which allows an external party to verify that all steps of the election went as expected, ballot secrecy which guarantees that a voters election remains secret, eligibility verifiability which allows verification that all counted votes were cast by an eligible voter, and, finally, coercion resistance which gives the voter the possibility of escaping coercion without the coercer noticing. Current literature presents several solutions offering coercion-resistance; however these are not usable in real-scale elections, either by the complication towards the voter or by the complexity of the solution. Proposed solutions in the non-hybrid i-voting setting are one of two types: (i) the voter ends up the registration phase owning many means of authentication (such as credentials and/or passwords) where only one is valid to cast a vote, enabling to cheat the coercer; (ii) the voter is capable to vote many times and the last vote counts, hence overwriting the coerced vote with the desired one.

One of the principal premises of our protocol is that it is not based in the requirement of the ownership of public/private key pairs by the users in order to foster the usability of a secure i-voting scheme. Requiring voters to transport, remember or store several credentials complicates voter’s experience. For these reasons we have decided that the re-voting setting was preferable for our scheme.

The remainder of this work is organized as follows. Related work is presented in Sect. 1.1 followed by a short description of our contribution. Section 2 introduces the parties and the notation used in our protocol followed by a description of the latter in Sect. 3. Finally, we conclude our work and present possible lines of improvement in Sect. 4.

1.1 Related Work

Re-voting has been proposed in several constructions in current literature [16]. The main challenge that one finds when allowing multiple voting for coercion resistance is filtering, which consists in accepting only one vote per voter (normally the last one). It is a challenge because, in order to mitigate coercion attacks, voting must be deniable, meaning that the adversary must not be able to determine whether a specific voter re-cast her ballot, or more generally, not be able to know which of the voters re-voted. Concurrently, universal verification and proof that the process happened as expected must be provided.

The JCJ protocol [15] allows multiple voting, but the filtering phase is not deniable. One can determine whether her own vote has been filtered. Moreover, the filtering has a complexity of \(\mathcal {O}(N^2)\), where N is the number of votes. The latter was most recently improved by Araújo et al. [2], still not satisfy deniability. The hybrid protocol presented by Spycher et al. [21] allows the voter to cast a vote in an electoral school, and therefore overwrite any previously cast votes. However, this results in the requirement of presence accessibility of the voter. Another used method is to do the filtering as a black box protocol. Trust is given to a server which will filter all votes and publish the result [11]. Such a method avoids any tracking or knowledge of which votes have been filtered, but verifiability is completely lost.

To the best of our knowledge, current filtering schemes that offer a deniable voting scheme which, at the same time have public verifiability, are the ones proposed by Achenbach et al. [1] and Locher et al. [18]. In a protocol where a Public Bulletin Board (PBB) is used in order to allow verifiability, the filtering process must be done after the mixing, otherwise, a voter (and thus the coercer) would know whether her vote was filtered or not. However, after the mixing, it is no longer possible to know which is the order of the votes, and therefore, before inserting the votes in the mix-net there must be some reference of their order. This solution faces this by performing Encrypted Plaintext Equivalence Tests (EPET) on the credentials for all votes against all lately cast votes before mixing. This consists in performing a PET (a cryptographic tool to compare two plaintexts without decrypting any of them) whose output is encrypted, and if any of the comparisons among the credentials is equivalent, then the output of the EPET hides a random number (alternatively, the encrypted number will be a one). Votes are then included in a mix-net. The filtering phase happens after mixing by decrypting the EPET, and only votes which output a 1 will be kept. These solutions are very interesting as they achieve the deniability property with no trust in any of the servers. However, to offer this there is a high increase in the complexity as the EPET have to be performed for each pair of votes, resulting in a complexity of \(\mathcal {O}(N^2)\) prior to the mixing, and in \(\mathcal {O}(N)\) decryptions and zero-knowledge proofs of correct decryption during the filtering.

These filtering schemes are implemented by comparing the voting credentials, requiring voters to maintain voting credentials throughout the whole election.

1.2 Our Contribution

In this paper, we present an i-voting scheme to achieve a reasonable balance between security and usability. We slightly increase the trust assumptions on some entities in the different stages of the voting process. On this basis, we show that it is not necessary to sacrifice usability to implement means for granting coercion-resistance, election verifiability, and ballot secrecy. As a matter of fact, our protocol provides a user-friendly interface for voters and, simultaneously, reduces the computational cost of the tallying phase with respect to existing solutions [15, 17, 18]. Our construction generates anonymous digital certificates each time a user casts a vote so that she does not need to remember, transport or possess any kind of cryptographic keys and/or secret apart from her authentication credentials. We mitigate coercion by using the solution of re-voting. Our construction achieves the deniability property by using concepts of the ‘Millionaires Protocol’ [6].

2 Parties and Building Blocks

The parties involved in the voting protocol are the following: (i) the electorate, given by the set \(V=\lbrace V_1, V_2,\ldots ,V_n\rbrace \) of n actual voters among \(n_e\) potential voters; (ii) the t trustees \(T=\lbrace T_1,T_2,\ldots ,T_t\rbrace \), which hold a share of the master voting key. In order to decrypt a ciphertext encrypted with this key, at least \(k\le t\) trustees must cooperate; (iii) the Certificate Authority, CA; (iv) the Voting Server, VS, which validates and posts the votes; (v) the Tallying Server, TS, which performs the filtering and counting of votes and (vi) the Public Bulletin Board, PBB, which acts as an append-only public ledger where votes, proofs (to prove re-encryption, shuffle and decryption), and all intermediate steps until the tally are posted. A specification of a possible construction is explained in [13].

The building blocks for the voting protocol are the following.

Elliptic Curve Cryptography (ECC): Let \(\mathcal {E}\) denote an elliptic curve defined over a finite field \(\mathbb {F}_p\), being p a prime number, and G a generator of \(\mathcal {E}\), with prime order, q. Without loss of generality, we assume that \(p=q\). The key generation algorithm, \(\texttt {KeyGen}(\mathcal {E}, G, q)\) outputs an asymmetric public-private key pair (pk, sk) such that \(sk\in _R\mathbb {Z}_q^*\) and \(pk = sk \cdot G\). Encryption function \(\texttt {Enc}(pk, M)\) takes as input a public key pk and an elliptic curve point \(M\in \mathcal {E}\) and returns a ciphertext \(\gamma = (\gamma _1, \gamma _2) = (r\cdot G, M + r\cdot pk)\) for \(r\in _R\mathbb {Z}_q^*\). The decryption function \(\texttt {Dec}(sk, \gamma )\) takes as input a private key sk and a ciphertext \(\gamma \), and returns the elliptic curve point \(M = \gamma - sk\cdot \gamma _1 = M + r \cdot pk - sk \cdot r \cdot G\). Finally, the signature function \(\texttt {Sign}(sk, M)\) takes as input a private key sk and a message \(M\in \mathcal {E}\), and outputs a signature on M, following [19]. For the sake of simplicity, when using \(\texttt {Sign}(sk, M)\), we refer both to the message and the signature of the latter.

The cryptosystem is probabilistic and additively homomorphic, i.e., given two ciphertexts \(\texttt {Enc}(pk, M_1)\) and \(\texttt {Enc}(pk, M_2)\), then

$$\begin{aligned} \texttt {Enc}(pk, M_1)&\,\oplus \,\texttt {Enc}(pk, M_2) = (r_1G, M_1 + r_1 pk) + (r_2G; M_2 + r_2 pk) \\&= ((r_1 + r_2)G, M_1 + M_2+(r_1+r_2)pk) =\texttt {Enc}(pk, M_1\oplus M_2), \end{aligned}$$

where \(\oplus \) is the operation defined in ciphertext and plaintext spaces.

Threshold Cryptography: Due to the homomorphic nature of the cryptosystem we use, the voting private key is generated in a distributed manner by T, and thus decryption also demands the collaboration of all trustees. In other words, we impede any single trustee to access any private key [10].

Non-Interactive Zero-Knowledge Proofs (NIZKP): We will use the Fiat-Shamir heuristic [9] (using a hash function modeled as the random oracle) in order to make Zero-Knowledge Proofs non-interactive. Different constructions of NIZKP, to prove correct ballot generation [8], correct decryption of the final result and correct re-encryption of a ciphertext [20] are used.

Anonymous Credentials: Our scheme uses anonymous credentials during the registration phase and vote cast. The only requirement of these credentials is that they certify certain attributes which are used to group voters by electoral colleges and filter votes cast by the same voter [3, 5, 7].

Verifiable Re-Encryption Shuffles: In order to offer coercion resistance in a private way, we use verifiable shuffles [12]. These allow an entity to produce a shuffle of a list of homomorphic ciphertexts, in such a way that it is infeasible for a computationally bounded adversary to relate ciphertexts in the input list with ciphertexts in the output. Moreover, this is done in a verifiable manner.

3 Description of Our Protocol

This section presents an overview of the protocol using Figs. 1 and 2 followed with a more exhaustive explanation of the three parts of our protocol: pre-election, election and tally phases. Note that the election phase is divided into the certification, voting, and verification phase.

Fig. 1.
figure 1

Pre-election and certificate generation

Full size image

3.1 Pre-election Phase

This phase begins by generating, with \(\texttt {KeyGen}(\mathcal {E}, G, q)\), the different keys of the servers. The keys of CA, VS, and TS are generated by each authority. The master voting keypair, \((\pi , \sigma )\), is distributively generated amongst the trustees. Each trustee \(T_h\), \(1\le h \le t\), ends up with the pair \((\pi , \sigma _h)\), being \(\sigma _h\) the share of \(T_h\) of key \(\sigma \). Such protocols allow a set of trustees to compute a public key pair. This public key is directly computed from the different shares of the private key. Note that the ‘full’ private key is never computed [10]. Then, VS, with its keypair, \((pk_{VS}, sk_{VS})\), takes as input \(n_e\) and randomly generates different voting identifiers, \(VId_i\in \mathcal {E}\), \(1\le i \le n_e\). It then commits to these values by encrypting all of the \(VId_i\)s, \(VC_i = \texttt {Enc}(pk_{VS}, VId_i)\). These values are published in the PBB together with the signature of VS for \(VC_i\), \(\texttt {Sign}(sk_{VS}, VC_i)\).

Fig. 2.
figure 2

Vote and tallying phases

Full size image

3.2 Election Phase

This phase comprises all steps that are taken while the election process is open. Note that a voter needs to follow a certification phase for each vote cast, which allows to avoid coercion without a high increase in computational complexity whilst simplifying the task for voters to cast votes multiple times even from different devices.

Certification: The voter authenticates to the CA, which responds with a one-time use anonymous certificate with a re-encryption, \(VC_i'\), of the respective \(VC_i\). With the certificate, \(CV_i\), CA includes a NIZKP of correct re-encryption of \(VC_i\).

Voting Phase: The cast of the vote involves \(V_i\) in a ‘regular vote-cast protocol’. The voter selects a candidate, encrypts her choice, \(v_i\), with the master voting public key, \(\pi \), signs it using the voter private key \(sk_{CV_i}\), and creates a NIZKP, \(\theta _i\), proving that the vote has a correct form, together with \(VC'_i\). She then sends it to VS. The latter verifies correctness and publishes this information in the PBB together with \(VC'_i\): \(\left( CV_i, VC'_i, \texttt {Sign}(sk_{CV_i}, \texttt {Enc}(\pi , v_i)),\theta _i\right) \). The elements in the PBB will have assigned a counter, which orders the entries by the time of reception (a counter between 1 and the total number of votes would suffice).

Verification Phase: The voter is now able to check that the vote has indeed been recorded as cast using a search engine in the PBB with a reference of the certificate, which is unique per vote cast. Any third party is able to check that all votes recorded in the PBB come from a certified voter, the \(VC_i'\) is related to the certificate, and the votes have a correct format. Note that voters may repeat the protocol until this step as many times as they wish from different devices.

3.3 Tallying Phase

At this point, the election process is closed and all votes from the voters have been stored. There is possibly more than one vote from some voters; hence, before proceeding to the tallying, it is necessary to do the filtering. If the filtering is made in an unprovable manner, high levels of trust is put in the VS.

On the other hand, if all the counters (or timestamps, any reference of the time when the vote was cast) together with each one of the votes are published, coercion could easily happen, as this information could be individually identified. We therefore make use of a proof determining whether \(a>b\), with a, b being the counters of the objects in the PBB, without giving any other information of a, b.

Public Filtering: To do the filtering in a secret and provable way, we use the following result which we derive from a work presented in [6]. For an affine point R in the elliptic curve \(\mathcal {E}\) and \(C_1, C_2\in \mathbb {Z}^+\) whose expressions in bits are denoted by \(C^{(j)}_h\), \(1\le j \le k\), \(1\le h \le 2\), let

$$\begin{aligned} A_j&= R+\gamma ^{(1,j)}_2 - \gamma ^{(2,j)}_2+\sum _{d=j+1}^k 2^d \left( \gamma ^{(1,d)}_2-\gamma ^{(2,d)}_2\right) ,\\ B_j&= \gamma ^{(1,j)}_1-\gamma ^{(2,j)}_1 + \sum _{d=j+1}^k2^d\left( \gamma ^{(1,d)}_1 -\gamma ^{(2,d)}_1\right) ,\\ \gamma ^{(i,j)}&= (\gamma ^{(i,j)}_1, \gamma ^{(i, j)}_2) = \texttt {Enc}(pk, (2-C^{(j)}_i) \cdot R). \end{aligned}$$

Then, \(C_1\) is greater than \(C_2\) if and only if there exists the infinity point of the elliptic curve \(v_j = \infty \in \mathcal {E}\) with \(v_j = A_j - dB_j\), for some \(j\in [1, \lfloor \log _2(\max (C_1, C_2))\rfloor ]\).

This result allows us to go through the filtering without revealing any information to a coercer and without having to trust any entity. The role of the TS is merely for completeness purposes, as it has to add a proof of correctness. We now describe the steps taken in the filtering phase. Once the election is closed, the information displayed in the PBB is:

$$ \left( C_i, CV_i, VC'_i, \texttt {Sign}(sk_{CV}, \texttt {Enc}(\pi , (v_i)),\theta _i\right) , $$

where \(C_i\) is simply an increasing counter in the PBB. TS begins by removing redundant information for this step. That is, the only information of interest for the filtering are the counters, \(VC'_i\), and \(\texttt {Enc}(\pi , v_i)\) (without the signature). TS, by using its public key, generates another table and publishes it in the PBB:

$$ \left( \texttt {Enc}(pk, C^{(j)}_i)_{j=1}^k,\texttt {Enc}(\pi , v_i),VC'_i\right) . $$

The encryption of the bits of the counters is done with randomness zero, to make it easily verifiable. Next step consists in producing a verifiable re-encryption shuffle, where the resulting list of ciphertexts, \(\left( \texttt {Enc}'(pk_{TS}, C^{(j)}_i)_{j=1}^k,\texttt {Enc}'(\pi , v_i),VC''_i\right) \), is published in the PBB. After the mixing, TS requests VS to decrypt the \(VC''_i\) including a proof of correct decryption, \(\varTheta ^1_i\), resulting in:

$$ \left( \texttt {Enc}'(pk_{TS}, C^{(j)}_i)_{j=1}^k,\texttt {Enc}'(\pi , v_i),VId_i,\varTheta ^1_i\right) . $$

Now it is possible to proceed to the filtering phase. Note that the TS has access to the counters (it can decrypt each one of them) and therefore, proceeds to do the filtering by comparing VId’s. It decrypts each counter (not publicly) and publishes only the last vote cast by each \(VId_i\). It now needs to prove that the process was done in an honest manner for which it adds, for each \(VId_i\), a NIZKP, \(\varTheta ^2_l\), that there exists \(v_l\), as it was mentioned above, that decrypts to \(\infty \) for each of the filtered \(VId_j\) with \(VId_i=VId_j\) for some \(l\in \lbrace 1,\ldots , k\rbrace \). Let S denote the subset of the filtered votes and \(S_i\) denote the subset of votes having the same VId as \(VId_i\). The TS, after filtering, publishes:

$$ \left( \texttt {Enc}'(pk_{TS}, C^{(j)}_i)_{i=1}^k,\texttt {Enc}'(\pi , v_j),VId_j, \left( \varTheta ^2_j\right) _{s\in S_j}\right) _{j\in S}. $$

Any third party can compute all values \(v_l\) for each pair of counters, as there is the encryption of each of the bits published in the PBB. Together with the proof of correct decryption to \(\infty \), it is universally verifiable that the filtering phase has been done in an honest way, and only the votes with the higher counter (and therefore, the last vote cast by a certain voter) are accepted and proceed to the tallying phase. Furthermore, this result is reached without the need of doing PETs between each pair of votes, as presented in [1] or [18], simplifying the computational cost of the filtering phase asymptotically, as our construction, in comparison to the \(\mathcal {O}(N^2)\) complexity of these protocols, uses a filtering that has complexity \(\mathcal {O}(n\cdot n_v)\), where \(n_v\) is the maximum number of votes cast by a single voter. Moreover, our scheme only requires the interaction of two entities and a single proof of correct decryption for each pair of votes sharing the same VId, while the proper execution of PETs is done in a distributed manner.

Tallying: Finally, the tallying phase happens in a straight forward way for schemes using threshold homomorphic encryption. TS calculates the full encrypted result by adding all ciphertexts accepted after the filtering

$$ \texttt {Enc}(\pi , v_{\texttt {Final}})=\sum _{i=1}^n \texttt {Enc}(\pi , v_i)=\texttt {Enc}\left( \pi , \sum _{i=1}^nv_i\right) . $$

Then, the result goes through the group of trustees T holding the different shares of the private key, ending with the decrypted result. With this, a proof of correct decryption is added. Any auditor or third party can calculate the sum of all the ciphertexts and verify that the result is a proper decryption of such a product.

4 Conclusion and Future Work

We have presented a protocol which is coercion-resistant, with low requirements for deployment, and with a friendly voting experience. The complexity is also improved in comparison to existing schemes, and, while the assumptions are not optimal in comparison to some other electronic voting schemes (trust is needed in the CA and VS to offer coercion resistance), these allow an organization to employ remote voting elections in a secure, deployable and verifiable manner without the requirement of voters having cryptographic keys. Our current lines of investigation are directed towards a formal proof of the security requirements of our model together with an implementation of the protocol to test performance evaluations of the later.