Coercion Mitigation for Voting Systems with Trackers: A Selene Case Study

Abstract

An interesting approach to achieving verifiability in voting systems is to make use of tracking numbers. This gives voters a simple way of verifying that their ballot was counted: they can simply look up their ballot/tracker pair on a public bulletin board. It is crucial to understand how trackers affect other security properties, in particular privacy. However, existing privacy definitions are not designed to accommodate tracker-based voting systems. Furthermore, the addition of trackers increases the threat of coercion. There does however exist techniques to mitigate the coercion threat. While the term coercion mitigation has been used in the literature when describing voting systems such as Selene, no formal definition of coercion mitigation seems to exist. In this paper we formally define what coercion mitigation means for tracker-based voting systems. We model Selene in our framework and we prove that Selene provides coercion mitigation, in addition to privacy and verifiability.

1 Introduction

Electronic voting has seen widespread use over the past decades, ranging from smaller elections within clubs and associations, to large scale national elections as in Estonia. It is therefore necessary to understand the level of security that electronic voting systems provide. In this paper, we define precisely what verifiability, privacy and coercion mitigation means for voting systems using so-called trackers, and we prove that Selene provides these properties.

Verifiability is an interesting voting system property, allowing a voter to verify that their particular ballot was counted and that the election result correctly reflects the verified ballots. One example of a system with verifiability is Helios [2], which is used in the elections of the International Association for Cryptologic Research [1], among others. However, the Benaloh challenges used to achieve verifiability in Helios are hard to use for voters [26].

Schneier [33] proposed using human-readable tracking numbers for verifiability. Each voter gets a personal tracking number that is attached to their ballot. At the end of the election, all ballots with attached trackers are made publicly available. A voter can now trivially verify that their ballot appears next to their tracking number, which gives us verifiability as long as the trackers are unique. Multiple voting systems making use of tracking numbers have been proposed and deployed. Two notable examples are sElect [27] and Selene [31]. Tracking numbers intuitively give the voters a simple way of verifying that their ballot was recorded and counted. However, other security properties must also be considered. In particular, it is necessary to have a good understanding of how the addition of tracking numbers affects the voters’ privacy.

Verifiable voting may exacerbate threats such as coercion, in particular for remote electronic voting systems (e.g. internet voting) where a coercer might be present to “help” a coerced voter submit their ballot. Coercion resistant voting systems [9, 25] have been developed. Coercion resistance typically involves voters re-voting when the coercer is not present, but this often complicates voting procedures or increases the cost of the tallying phase. Furthermore, re-voting might not always be possible and may even be prohibited by law.

Like verifiability in general, tracking numbers may make coercion simpler: if a coercer gets access to a voter’s tracker, the coercer may also be able to verify that the desired ballot was cast. While tracking numbers complicate coercion resistance, it may be possible to mitigate the threat of coercion. For instance, if the voter only learns their tracking number after the result (ballots with trackers) has been published, as in Selene, they may lie to a coercer by observing a suitable ballot-tracker pair. Coercion mitigation is weaker than coercion resistance, but may be appropriate for low-stakes elections or where achieving stronger properties is considered to be impractical.

1.1 Related Work

Privacy. Bernhard et al. [6] analysed then-existing privacy definitions. They concluded that previous definitions were either too weak (there are real attacks not captured by the definitions), too strong (no voting system with any form of verifiability can be proven secure under the definition), or too narrow (the definitions do not capture a wide enough range of voting systems).

The main technical difficulty compared to standard cryptographic privacy notions is that the result of the election must be revealed to the adversary. Not only could the result reveal information about individual ballots, but it also prevents straight-forward cryptographic real-or-random definitions from working. Roughly speaking, there are two approaches to defining privacy for voting systems, based on the two different questions: “Does anything leak out of the casting and tallying prosesses?” vs. “Which voter cast this particular ballot?” The first question tends to lead to simulation-based security notions, while the second question can lead to more traditional left-or-right cryptographic definitions.

Bernhard et al. [6] proposed the $\textsf {BPRIV}$ definition, where the adversary plays a game against a challenger and interacts with two worlds (real and fake). The adversary first specifies ballots to be cast separately for each world. In the real world, ballots are cast and then counted as usual. In the fake world, the specified ballots are cast, but the ballots from the left world are counted and any tally proofs are simulated. The adversary then gets to see one of the worlds and must decide which world it sees. The idea is that for any secure system, the result in the fake world should be identical to what the result would have been in the real world, proving that – up to the actual result – the casting and tallying processes do not leak anything about the ballots cast, capturing privacy in this sense.

Bernhard et al. [6] proposed MiniVoting, an abstract scheme that models many voting systems (e.g. Helios), and proved that it satisfies the $\textsf {BPRIV}$ definition. Cortier et al. [10] proved that Labelled-MiniVoting, an extension of MiniVoting, also satisfies $\textsf {BPRIV}$. Belenios [13] also satisfies $\textsf {BPRIV}$ [11].

The original $\textsf {BPRIV}$ definition does not attempt to model corruption in any part of the tally process. Cortier et al. [15] proposed $\textsf {mb-BPRIV}$ which models adversarial control over which encrypted ballots should go through the tally process. Drăgan et al. [18] proposed the $\textsf {du-mb-BPRIV}$ model which also covers systems where verification happens after tallying.

The other approach to privacy is a traditional left-or-right game, such as Benaloh [4], where the adversary interacts with the various honest components of a voting system (voters, their computers, shuffle and decryption servers, etc.), all simulated by an experiment. Privacy is captured by a left-or-right query, and the adversary must determine if the left or the right ballots were cast. The game becomes trivial if the left and the right ballots would give different tallies, so we require that the challenge queries taken together yield the same tally for left and right. In the simplest instantiation, the left and right ballots contain distinct permutations of the same ballots, so showing that they cannot be distinguished shows that the election processes do not leak who cast which ballots. Smyth [36] and Gjøsteen [20] provide examples of this definitional style. As far as we know, no definition in this style captures tracker-based voting systems.

The advantage of the traditional cryptographic left-or-right game relative to the $\textsf {BPRIV}$ approach is that it is easier to model adversarial interactions with all parts of the protocol, including the different parts of the tally process, though authors before Gjøsteen [20] do not seem to do so. In principle, the $\textsf {BPRIV}$ requirement that the tally process be simulatable is troublesome, since such simulators cannot exist in the plain model, which means that the definition itself technically exists in some unspecified idealised model (typically the random oracle model). In practice, this is not troublesome. Requiring balanced left and right ballots is troublesome for some systems with particular counting functions, but not if the system reveals plaintext ballots.

Verifiability. Verifiability intuitively captures the notion that if a collection of voters verify the election, the result must be consistent with their cast ballots. For voters that do not verify or whose verification failed, we make no guarantees.

Several definitions of verifiability have appeared in the literature, see e.g. [12] or [37] for an overview. Furthermore, the verifiability properties of Selene have been thoroughly analysed both from a technical point of view (e.g. [3, 31]) and with respect to the user experience (e.g. [17, 38]).

Coercion. Coercion resistance models a coercer that controls the voter for a period of time. We refer to Smyth [35] for an overview of definitions. A weaker notion is receipt-freeness, where the coercer does not control the voter, but asks for evidence that the voter cast the desired ballot. This was introduced by Benaloh and Tuinstra [5], while Chaidos et al. [7] gave a $\textsf {BPRIV}$-style security definition. Selene, as generally instantiated, is not receipt-free. Coercion mitigation is a different notion, where we assume that the coercer is not present during vote casting and is somehow not able to ask the voter to perform particular operations (such as revealing the randomness used to encrypt). This could allow the voter to fake information consistent with following the coercer’s demands. While the term coercion mitigation has been used to describe the security properties provided by Selene (e.g. in [23, 31, 38]), there seems to be no formal definition of coercion mitigation in the literature.

Selene. Selene as a voting system has been studied previously, in particular with respect to privacy [18]. But a study of the complete protocol, including the tally phase, is missing. The coercion mitigation properties of Selene have also been extensively discussed [23, 31], but have not received a cryptographic analysis.

1.2 Our Contribution

We define security for cryptographic voting systems with trackers, capturing privacy, verifiability and coercion mitigation. An experiment models the adversary’s interaction with the honest players through various queries.

To break privacy, the adversary must decide who cast which ballot. Our definition is based on a similar definition by Gjøsteen [20, p. 492], adapted to properly accommodate voting systems using trackers. To break verifiability, the adversary must cause verifying voters to accept a result that is inconsistent with the ballots they have cast (similar to Cortier et al. [12]). To break coercion mitigation, the adversary is allowed to reveal the verification information of coerced voters and must decide if the coerced voter lied or not. Selene is vulnerable to collisions among such lies; e.g. multiple coerced voters claim the same ballot. We want to factor this attack out of the cryptographic analysis, so we require that the coercer organises the voting such that collisions do not happen. For schemes that are not vulnerable, we would remove the requirement.

Our definitions are easy to work with, which we demonstrate by presenting a complete model of Selene (expressed in our framework) and prove that Selene satisfies both privacy, verifiability and coercion mitigation. Selene has seen some use [32], so we believe these results are of independent interest.

We developed our definitions with Selene in mind, but they also accommodate other tracker based voting systems such as Hyperion [30] and (with some modifications to accomodate secret key material used in the shuffles) sElect [27]. Furthermore, our models also capture voting systems that do not use trackers.

2 Background

2.1 Notation

We denote tuples/lists in bold, e.g. $\textbf{v} = (v_{1}, \dots , v_{n}$). If we have multiple tuples, we denote the jth tuple by $\textbf{v}_{j}$ and the ith element of the jth tuple by $v_{j,i}$.

2.2 Cryptographic Building Blocks

We briefly introduce some cryptographic primitives we need for our work. Due to space constraints we omit much of the details.

To protect voters’ privacy, ballots are usually encrypted. Selene makes use of the ElGamal public key encryption system [19], which is used to encrypt both ballots and trackers. Throughout this paper, we will denote an ElGamal ciphertext by $(x,w) := (g^r, m\cdot \textsf{pk}^r)$, where g is the generator of the cyclic group $\mathbb {G}$ (of prime order q) we are working in, $m$ is the encrypted message, $\textsf{pk}= g^\textsf{sk}$ is the public encryption key (with corresponding decryption key $\textsf{sk}$) and r is a random element in $\mathbb {Z}_{q}$ (the field of integers modulo q).

Cryptographic voting systems typically make use of zero-knowledge proofs to ensure that certain computations are performed correctly. We refer to [16] for general background on zero-knowledge proofs. In particular, we use equality of discrete logarithm proofs and correctness proofs for shuffles of encrypted ballots. The former ensures correctness of computations. The latter preserves privacy by breaking the link between voters and their ballots. It is necessary that the shuffles are verifiable to ensure that no ballots are tampered with in any way. We refer to [22] for an overview of verifiable shuffles. In Selene it is necessary to shuffle two lists of ciphertexts (ballots and trackers) in parallel. Possible protocols are given in [29] and we detail a convenient protocol in the full version [21].

Furthermore, in Selene, the election authorities make use of Pedersen-style commitments [28] to commit to tracking numbers.

3 Voting Systems with Trackers

We model a voting protocol as a simple protocol built on top of a cryptographic voting scheme in such a way that the protocol’s security properties can be easily inferred from the cryptographic voting scheme’s properties. This allows us to separate key management (who has which keys) and plumbing (who sends which message when to whom) from the cryptographic issues, which simplifies analysis.

Due to space limitations, we model a situation with honest setup and tracker generation, as well as a single party decrypting. The former would be handled using a bespoke, verifiable multi-party computation protocol (see [31] for a suitable protocol for Selene), while the latter is handled using distributed decryption.

3.1 The Syntax of Voting Systems with Trackers

A verifiable voting system $\mathcal {S}$ consists of the following algorithms (extending Gjøsteen [20]):

• $\textsf{Setup}$: takes as input a security parameter and returns a pair $(\textsf{pk}, \textsf{sk})$ of election public and secret keys.

• $\textsf{UserKeyGen}$: takes as input an election public key $\textsf{pk}$ and returns a pair $(\textsf{vpk}, \textsf{vsk})$ of voter public and secret keys.

• $\textsf{TrackerGen}$: takes as input an election public key $\textsf{pk}$ and a list $(\textsf{vpk}_{1}, \dots , \textsf{vpk}_{n})$ of voter public keys and returns a list $\textbf{t}$ of trackers, a list $\textbf{et}$ of ciphertexts, a list $\textbf{ct}$ of commitments, a list $\textbf{op}$ of openings and a permutation $\pi$ on the set $\{ 1,\dots , n \}$.

• $\textsf{ExtractTracker}$: takes as input a voter secret key $\textsf{vsk}$, a tracker commitment $ct$ and an opening $op$ and returns a tracker $t$.

• $\textsf{ClaimTracker}$: takes as input a voter secret key $\textsf{vsk}$, a tracker commitment $ct$ and a tracker $t$ and returns an opening $op$.

• $\textsf{Vote}$: takes as input an election public key $\textsf{pk}$ and a ballot $v$ and returns a ciphertext $ev$, a ballot proof $\varPi ^v$ and a receipt $\rho$.

• $\textsf{Shuffle}$: takes as input a public key $\textsf{pk}$ and a list $\textbf{evt}$ of encrypted ballots and trackers, and returns a list $\textbf{evt}'$ and a proof $\varPi ^s$ of correct shuffle.

• $\textsf{DecryptResult}$: takes as input a secret key $\textsf{sk}$ and a list $\textbf{evt}$ of encrypted ballots and trackers and returns a result $\textsf{res}$ and a result proof $\varPi ^r$.

• $\textsf{VoterVerify}$: takes as input a receipt $\rho$, a tracker t, a list $\textbf{evt}$ of encrypted ballot/tracker pairs, a result $\textsf{res}$ and a result proof $\varPi ^r$ and returns 0 or 1.

• $\textsf{VerifyShuffle}$: takes as input a public key $\textsf{pk},$ two lists $\textbf{evt}, \textbf{evt}'$ of encrypted ballots and trackers and a shuffle proof $\varPi ^s$ and returns 0 or 1.

• $\textsf{VerifyBallot}$: takes as input a public key $\textsf{pk}$, a ciphertext $ev$ and a ballot proof $\varPi ^v$ and returns 0 or 1.

• $\textsf{VerifyResult}$: takes as input a public key $\textsf{pk}$, a list $\textbf{evt}$ of encrypted ballots and trackers, a result $\textsf{res}$ and a result proof $\varPi ^r$ and returns 0 or 1.

We say that a verifiable, tracker-based voting system is $(n_{v},n_{s})$-correct if for any $(\textsf{pk}, \textsf{sk})$ output by $\textsf{Setup}$, any $(\textsf{vpk}_{1}, \textsf{vsk}_{1}), \dots , (\textsf{vpk}_{n_{v}}, \textsf{vsk}_{n_{v}})$ output by $\textsf{UserKeyGen}$, any lists $\textbf{t}, \textbf{et}, \textbf{ct}, \textbf{op}$ and permutations $\pi :\{1, \dots , n_{v}\} \rightarrow \{1,\dots , n_{v}\}$ output by $\textsf{TrackerGen}(\textsf{pk}, \textsf{sk}, \textsf{vpk}_{1}, \dots , \textsf{vpk}_{n_{v}})$, any ballots $v_{1}, \dots , v_{n_{v}}$, any $(ev_{i}, \varPi ^v_{i}, \rho _{i})$ output by $\textsf{Vote}(\textsf{pk}, v_{i}), i = 1, \dots , n_{v}$, any sequence of $n_{s}$ sequences of encrypted ballots and trackers $\textbf{evt}_{i}$ and proofs $\varPi ^s_{i}$ output by $\textsf{Shuffle}\left( \textsf{pk}, \textbf{evt}_{i-1}\right)$, and any $(\textsf{res}, \varPi ^r)$ possibly output by $\textsf{DecryptResult}\left( \textsf{sk}, \textbf{evt}_{n_{s}}\right)$, the following hold:

• $\textsf{DecryptResult}(\textsf{sk}, \textbf{evt}_{n_{s}})$ did not output $\bot$,

• $\textsf{VoterVerify}(\rho _{i}, t_{i}, \textbf{evt}_{n_{s}} \textsf{res}, \varPi ^r) = 1$ for all $i = 1, \dots , n_{v}$,

• $\textsf{VerifyShuffle}\left( \textsf{pk}, \textbf{evt}_{j-1}, \textbf{evt}_{j}, \varPi ^s_{j}\right) = 1$ for all $j = 1, \dots , n_{s}$,

• $\textsf{VerifyResult}\left( \textsf{pk}, \textbf{evt}_{n_{s}}, \textsf{res}, \varPi ^r\right) = 1$,

• $\textsf{VerifyBallot}(\textsf{pk}, ev_{i}, \varPi ^v_{i}) = 1$ for all $i = 1, \dots , n_{v}$, and

for any voter key pair $(\textsf{vpk}, \textsf{vsk})$, $ct$ in $\textbf{ct}$ and tracker $t$ in $\textbf{t}$, we have that

$$\begin{aligned} \textsf{ExtractTracker}(\textsf{vsk}, ct, \textsf{ClaimTracker}(\textsf{vsk}, ct, t)) = t\text{. } \end{aligned}$$

We will describe later how Selene fits into our framework, but we note that this framework also captures voting systems that do not use trackers for verification. Such protocols are simply augmented with suitable dummy algorithms for $\textsf{TrackerGen}$, $\textsf{ExtractTracker}$ and $\textsf{ClaimTracker}$.

3.2 Defining Security

We use a single experiment, found in Fig. 1, to define privacy, integrity and coercion mitigation. Verifiability is defined in terms of integrity. The experiment models the cryptographic actions of honest parties.

Fig. 1.

Security experiment for privacy, integrity and coercion mitigation. The bit $b''$ is not used in the experiment, but simplifies the definition of advantage. The adversary makes register and chosen voter key queries, followed by a single tracker generation query, followed by other queries. Queries in are only used for privacy and coercion mitigation. Queries in are only used for coercion mitigation. Queries in are only used for privacy and integrity (with $b$ fixed to 0). Queries in are only used for integrity.

The test query is used to model integrity. The challenge query is used to define privacy. The coerce and coercion verification queries are used to model coercion, again modified by freshness. The coerce query specifies two voters (actually, two indices into the list of voter public keys) and two ballots. The first voter is the coerced voter. The first ballot is the coerced voter’s intended ballot, while the second ballot is the coercer’s desired ballot. The second voter casts the opposite ballot of the coerced voter. In the coercion verification query, the coerced voter either reveals an opening to their true tracker, or an opening to the tracker corresponding to the coercer’s desired ballot, cast by the second voter, thereby ensuring that the coerced voter can lie about its opening without risking a collision (as discussed in Sect. 1.2). We note that this does not capture full coercion resistance, as that would require that the adversary is able to see exactly which ciphertext the coerced voter submitted (as, for example in [14]). In our definition, however, the adversary gets to see two ciphertexts, where one is submitted by the coerced voter, but he receives no information about which of the two ciphertexts the coerced voter actually submitted.

We make some restrictions on the order and number of queries (detailed in the caption of Fig. 1), but the experiment allows the adversary to make combinations of queries that do not correspond to any behaviour of the voting protocol. Partially, we do so because we can, but also in order to simplify definitions of certain cryptographic properties (such as uniqueness of results).

The adversary decides which ballots should be counted. We need to recognise when the adversary has organised counting such that it results in a trivial win. We say that a sequence $\textbf{evt}$ of encrypted ballots and trackers is valid if

• $L_{s}$ contains a sequence of tuples $(\textbf{evt}_{j-1}, \textbf{evt}_{j}, \varPi ^s_{j})_{j=1}^{n_{s}}$, not necessarily appearing in the same order in $L_{s}$, with $\textbf{evt}_{n_{s}} = \textbf{evt}$;

• $L_{v}$ contains tuples

  $$(i_{1}, j_{1}, v_{0,1}, v_{1,1}, ev_{1}, \varPi ^v_{1}, \rho _{1}), \dots , (i_{n_{c}}, j_{n_{c}}, v_{0,n_{c}}, v_{1,n_{c}}, ev_{n_{c}}, \varPi ^v_{n_{c}}, \rho _{n_{c}})$$

  such that $\textbf{evt}_{0} = (ev_{1}, \dots , ev_{n_{c}})$; and

• for any $k,k' \in \{ 1, \dots , n_{c} \}$ with $k \ne k'$, we have $i_{k} \ne i_{k'}$ (only one ballot per voter public key).

In this case, we also say that $\textbf{evt}$ originated from $\textbf{evt}_0$, alternatively from

$$ (i_{1}, j_1, v_{0,1}, v_{1,1}, ev_{1}, \varPi ^v_{1}, \rho _{1}), \dots , (i_{n_{c}}, j_{n_c}, v_{0,n_{c}}, v_{1,n_{c}}, ev_{n_{c}}, \varPi ^v_{n_{c}}, \rho _{n_{c}}). $$

Furthermore, we say that a valid sequence $\textbf{evt}$ is honest if at least one of the tuples $(\textbf{evt}_{j-1}, \textbf{evt}_{j}, \varPi ^s_{j})$ comes from a shuffle query. A valid sequence is balanced if the ballot sequences $(v_{0,1}, \dots , v_{0,n_{c}})$ and $(v_{1,1}, \dots , v_{1,n_{c}})$ are equal up to order.

An execution is fresh if the following all hold:

• If a voter secret key, a receipt or a tracker is revealed, then any challenge query for that voter contains the same ballot on the left and the right side.

• For any result query $\textbf{evt}$ that does not return $\bot$, $\textbf{evt}$ is balanced and honest.

• For any voter verification query $(j, \textbf{evt}, \textsf{res}, \varPi ^r)$, $\textbf{evt}$ contains an encryption of $v_{b,j}$ and $\textsf{VerifyResult}(\textsf{pk}, \textbf{evt}, \textsf{res}, \varPi ^r)$ evaluates to 1.

• For any encrypted ballot returned by a coerce query, if it is in an origin of any result query, the other encrypted ballot returned by the coerce query is also in the same origin of the same result query.

• There is no election key reveal query.

We define the joint privacy and coercion mitigation event $E_{p}$ to be the event that after the experiment and an adversary has interacted, the execution is fresh and $b' = b$, or the execution is not fresh and $b' = b''$. In other words, if the adversary makes a query that results in a non-fresh execution of the experiment, we simply compare the adversary’s guess to a random bit, giving the adversary no advantage over making a random guess.

In the integrity game, the adversary’s goal is to achieve inconsistencies:

• The count failure event $F_{c}$ is that a result query for a valid sequence of encrypted ballots and trackers results in $\bot$.

• The inconsistent result event $F_{r}$ is that a test query $(\textbf{evt}, \textsf{res}, \varPi ^r)$ evaluates to 1, $\textbf{evt}$ originated from

  $$ (i_{1}, \cdot , v_{0,1}, v_{1,1}, ev_{1}, \varPi ^v_{1}, \rho _{1}), \dots , (i_{n_{c}}, \cdot , v_{0,n_{c}}, v_{1,n_{c}}, ev_{n_{c}}, \varPi ^v_{n_{c}}, \rho _{n_{c}}) $$

  and there is no permutation $\pi$ on $\{1, \dots , n_{c}\}$ such that for $i = 1, \dots , n_{c}$, either $v_{b,i} = \bot$ or $\textsf{Dec}(\textsf{sk}, ev_{\pi (i)}) = v_{b,i}$.

• The no unique result event $F_{u}$ is that two test queries $(\textbf{evt}, \textsf{res}_{1}, \varPi ^r_{1})$ and $(\textbf{evt}', \textsf{res}_{2}, \varPi ^r_{2})$ both evaluate to 1, $\textbf{evt}$ and $\textbf{evt}'$ have a common origin, and $\textsf{res}_{1}$ and $\textsf{res}_{2}$ are not equal up to order.

• The inconsistent verification event $F_{v}$ is that a sequence of voter verification queries $\{(k_j, \textbf{evt}, \textsf{res}, \varPi ^r) \}_{j=1}^n$ all return 1, $\textbf{evt}$ is valid, and with $L_{v} = \left( (i_{1}, \bot , v_{0,1}, v_{1,1}, ev_{1}, \varPi ^v_{1}, \rho _{1}), \dots , (i_{n_{c}}, \bot , v_{0,n_{c}}, v_{1,n_{c}}, ev_{n_{c}}, \varPi ^v_{n_{c}}, \rho _{n_{c}}) \right)$ there is no permutation $\pi$ on $\{ 1,\dots ,n_{c} \}$ such that $\textsf{Dec}\left( \textsf{sk}, ev_{\pi (k_{j})} \right) = v_{b,k_{j}}$ for all $j = 1,\dots ,n$, i.e. that all the specified voters think their ballots are included in the tally, but at least one of the ballots is not.

We define the advantage of an adversary $\mathcal {A}$ against a voting system $\mathcal {S}$ to be

$$ \textsf{Adv}^{\mathrm {{\mathsf {vote{-}x}}}}_{\mathcal {S}}(\mathcal {A}) = {\left\{ \begin{array}{ll} 2 \cdot \left| {\text {Pr}}[{E_{p}}] - 1 / 2\right| &{} x = \textsf{priv} \text { or } x = \mathsf {c{-}mit} \text {, or} \\ {\text {Pr}}[{F_{c} \vee F_{r} \vee F_{u} \vee F_{v}}] &{} x = \textsf{int} \text{. } \end{array}\right. } $$

3.3 The Voting Protocol

The different parties in the voting protocol are the $n_{v}$ voters and their devices, a trusted election authority (EA) who runs setup, registration, tracker generation and who tallies the cast ballots, a collection of $n_{s}$ shuffle servers, one or more auditors, and a public append-only bulletin board $\textsf{BB}$. There are many simple variations of the voting protocol.

In the setup phase, the EA runs $\textsf{Setup}$ to generate election public and secret keys $\textsf{pk}$ and $\textsf{sk}$. The public key $\textsf{pk}$ is posted to $\textsf{BB}$.

In the registration phase, the EA runs $\textsf{UserKeyGen}(\textsf{pk})$ to generate per-voter keys $(\textsf{vpk}, \textsf{vsk})$ for each voter. The public key $\textsf{vpk}$ is posted to $\textsf{BB}$ and the secret key $\textsf{vsk}$ is sent to the voter’s device.

In the tracker generation phase, the EA runs $\textsf{TrackerGen}(\textsf{pk}, \textsf{sk}, \textsf{vpk}_{1}, \dots , \textsf{vpk}_{n_{v}})$ to generate trackers, encrypted trackers, tracker commitments and openings to the commitments. To break the link between voters and their trackers, the trackers are encrypted and put through a re-encryption mixnet before they are committed to. Each encrypted tracker and commitment is assigned to a voter public key and posted to $\textsf{BB}$ next to this key. Plaintext trackers are also posted to $\textsf{BB}$.

In the voting phase, a voter instructs her device on which ballot $v$ to cast. The voter’s device runs the $\textsf{Vote}$ algorithm to produce an encrypted ballot $ev$ and a proof of knowledge $\varPi ^v$ of the underlying plaintext. The encrypted ballot and the proof are added to the web bulletin board next to the voter’s public key, encrypted tracker and tracker commitment.

In the tallying phase, the auditors first verify the ballot proofs $\varPi ^v_{i}$, subsequently ignoring any ballot whose ballot proof does not verify. The pairs $(ev_{i}, et_{i})$ of encrypted ballots and trackers are extracted from the bulletin board and sent to the first shuffle server. The first shuffle server uses the shuffle algorithm $\textsf{Shuffle}$ on the input encrypted ballots and trackers, before passing the shuffled ballots on the next shuffle server, which shuffles the ballots again and sends the shuffled list to the next shuffle server, and so on. All the shuffle servers post their output ciphertexts and shuffle proofs on the bulletin board, and the auditors verify the proofs. If all the shuffles are correct, the EA runs $\textsf{DecryptResult}$ on the output from the final shuffle server, to obtain a result $\textsf{res}$ and a proof $\varPi ^r$. The auditors verify this too and add their signatures to the bulletin board.

In the verification phase, the EA tells each voter which tracker belongs to them (the exact details of how this happens depends on the underlying voting system). The voters then run $\textsf{VoterVerify}$ to verify that their vote was correctly cast and counted. For voting systems without trackers (such as Helios [2] and Belenios [13]), voters simply run $\textsf{VoterVerify}$ without interacting with the EA.

Security Properties. It is easy to see that we can simulate a run of the voting protocol using the experiment. It is also straight-forward for anyone to verify, from the bulletin board alone, if the list of encrypted ballots and trackers that is finally decrypted in a run of the protocol is valid.

For simplicity, we have assumed trusted setup (including tracker generation) and no distributed decryption. We may also assume that any reasonable adversary against the voting scheme has negligible advantage.

It follows, under the assumption of trusted tracker generation, that as long as the contents of the bulletin board verifies, we have verifiability in the sense that the final result is consistent with the ballots of voters that successfully verify. (Though we have not discussed this, one can also verify eligibility by verifying the bulletin board against the electoral roll. When Selene is used without voter signatures, it does not protect against voting on behalf of abstaining honest voters, though such voters could detect this.)

If at least one of the shuffle servers is honest and the election secret key has not been revealed, and the adversary does not manage to organise the voting to get a trivial win, we also have privacy and coercion mitigation.

4 The Selene Voting System

We provide a model of Selene and analyse it under our security definition. Relative to the original Selene paper, there are three interesting differences/choices: (1) We do not model distributed setup and tracker generation, nor distributed decryption. (2) The voter proves knowledge of the ballot using an equality of discrete logarithm proof. (3) We assume a particular shuffle described in the full version [21] is used. The latter two simplify the security proof by avoiding rewinding. The first is due to lack of space (though see [31] for distributed setup protocols, and [20] for how to model distributed decryption).

4.1 The Voting System

Let $\mathbb {G}$ be a group of prime order q, with generator g. Let $\textsf{E} = (\textsf{Kgen}, \textsf{Enc}, \textsf{Dec})$ be the ElGamal public key encryption system. Let $\varSigma _{dl} = (\mathcal {P}_{dl}, \mathcal {V}_{dl})$ be a proof system for proving equality of discrete logarithms in $\mathbb {G}$ (e.g. the Chaum-Pedersen protocol [8]). We abuse notation and let $\varSigma _{s} = (\mathcal {P}_{s}, \mathcal {V}_{s})$ denote both a proof system for shuffling ElGamal ciphertexts and a proof system for shuffling pairs of ElGamal ciphertexts. Our instantiation of Selene works as follows:

• $\textsf{Setup}$: sample and compute $(\mathsf {pk_v}, \mathsf {sk_v}) \leftarrow \textsf{Kgen}(1^{\lambda })$ and $(\mathsf {pk_t}, \mathsf {sk_t}) \leftarrow \textsf{Kgen}(1^{\lambda })$. The election public key is $\textsf{pk}= (\mathsf {pk_v}, \mathsf {pk_t}, h_{v})$ and the election secret key is $\textsf{sk}= (\mathsf {sk_v}, \mathsf {sk_t})$.

• $\textsf{UserKeyGen}(\textsf{pk})$: compute $(\textsf{vpk}, \textsf{vsk}) \leftarrow \textsf{Kgen}(1^{\lambda })$.

• $\textsf{TrackerGen}(\textsf{pk}, \textsf{vpk}_{1}, \dots , \textsf{vpk}_{n})$: set $\textbf{t} \leftarrow (1, \dots , n)$. Choose a random permutation $\pi$ on the set $\{1, \dots , n \}$. For each i, choose random elements , compute ElGamal encryptions $et_{i} \leftarrow (g^{r_{\pi (i)}}, \mathsf {pk_t}^{r_{\pi (i)}} g^{t_{\pi (i)}})$ and commitments $ct_{i} \leftarrow \textsf{vpk}_i^{s_{i}} \cdot g^{t_{\pi (i)}}$. Set $op_{i} = g^{s_{i}}$. The public output is the list of trackers $\textbf{t}$, the list of encrypted trackers $\textbf{et}$ and the list of tracker commitments $\textbf{ct}$. The private output is the list of openings $\textbf{op}$ to the commitments and the permutation $\pi$.

• $\textsf{ExtractTracker}(\textsf{vsk}, ct, op)$: compute $g^{t} \leftarrow ct\cdot op^{-\textsf{vsk}}$.

• $\textsf{ClaimTracker}(\textsf{vsk}, ct, g^{t})$: compute $op\leftarrow (ct/g^{t})^{1 / \textsf{vsk}}$.

• $\textsf{Vote}(\textsf{pk}, v)$: sample and compute $x \leftarrow g^r$, $\hat{x} \leftarrow h_{v}^{r}$ and $w \leftarrow \textsf{pk}_{v}^{r}v$. Compute a proof $\varPi ^{dl}\leftarrow \mathcal {P}_{dl}((g,h_v,x,\hat{x}), r)$ showing that $\log _{g} x = \log _{h_v} \hat{x} = r$. Output $c= (x,w)$, $\varPi ^v= (\hat{x}, \varPi ^{dl})$ and $\rho = v$.

• $\textsf{Shuffle}(\textsf{pk}, \textbf{evt})$: sample two lists and a random permutation on the set $\{1, \dots , n \}$. For each $((x_{v,i}, w_{v,i}), (x_{t,i}, w_{t,i})) \in \textbf{evt}$, compute $x'_{v,i} \leftarrow g^{r_{v,\pi (i)}}x_{v,\pi (i)}, w'_{v,i} \leftarrow \textsf{pk}_{v}^{r_{v,\pi (i)}}w_{v,\pi (i)}, x'_{t,i} \leftarrow g^{r_{t,\pi (i)}}x_{t,\pi (i)}$ and $w'_{t,i} \leftarrow \textsf{pk}_{t}^{r_{t,\pi (i)}}w_{t,\pi (i)}$. Compute a proof $\varPi ^s\leftarrow \mathcal {P}_{s}((\textbf{evt}, \textbf{evt}'), (\textbf{r}_{v}, \textbf{r}_{t}, \pi ))$ of correct shuffle and output $(\textbf{evt}', \varPi ^s)$.

• $\textsf{DecryptResult}(\textsf{sk}, \textbf{evt})$: for each $((x_{v,i}, w_{v,i}), (x_{t,i}, w_{t,i})) \in \textbf{evt}$, compute $v_{i} \leftarrow \textsf{Dec}(\textsf{sk}_{v}, (x_{v,i}, w_{v,i}))$, $t_{i} \leftarrow \textsf{Dec}(\textsf{sk}_{t}, (x_{t,i}, w_{t,i}))$ and proofs $\varPi ^{dl}_{v,i} \leftarrow \mathcal {P}_{dl}((g, x_{v,i}, \mathsf {pk_v}, w_{v,i} / v_i), \mathsf {sk_v})$ and $\varPi ^{dl}_{t,i} \leftarrow \mathcal {P}_{dl}((g, x_{t,i}, \mathsf {pk_t}, w_{t,i} / t_i), \mathsf {sk_t})$, proving that $\log _{g} \mathsf {pk_v}= \log _{x_{v,i}} (w_{v,i} / v_{i}) = \mathsf {sk_v}$ and $\log _{g} \mathsf {pk_t}= \log _{x_{t,i}} (w_{t,i} / t_{i}) = \mathsf {sk_t}$. Set $\textsf{res}\leftarrow \textbf{v}$ and $\varPi ^r\leftarrow (\{ \varPi ^{dl}_{v,i} \}, \{\varPi ^{dl}_{t,i} \}, \textbf{t})$ and output $(\textsf{res}, \varPi ^r)$.

• $\textsf{VoterVerify}(\rho , t, \textbf{evt}, \textbf{v}, \varPi ^r)$: parse $\varPi ^r$ as $(\{ \varPi ^{dl}_{v,i} \}, \{\varPi ^{dl}_{t,i} \}, \textbf{t})$ and check if $\rho \in \textbf{v}$, and $t\in \textbf{t}$, and that if $t= t_{i}$ then $\rho = v_{i}$, i.e. the ballot appears next to the correct tracker.

• $\textsf{VerifyShuffle}(\textsf{pk}, \textbf{evt}, \textbf{evt}', \varPi ^s)$: compute $d \leftarrow \mathcal {V}_{s}(\textsf{pk}, \textbf{evt}, \textbf{evt}', \varPi ^s)$.

• $\textsf{VerifyBallot}(\textsf{pk}, ev, \varPi ^v)$: parse $\varPi ^v$ as $(\hat{x}, \varPi ^{dl})$ and compute $d \leftarrow \mathcal {V}_{dl}((g, h, x, \hat{x}), \varPi ^{dl})$.

• $\textsf{VerifyResult}(\textsf{pk}, \textbf{evt}, \textsf{res}, \varPi ^r):$ parse $\varPi ^r$ as $(\{ \varPi ^{dl}_{v,i} \}, \{\varPi ^{dl}_{t,i} \}, \textbf{t})$ and compute $d_{v,i}\!\leftarrow \mathcal {V}_{dl}((g, x_{v,i}, \mathsf {pk_v}, w_{v,i} / v_i), \varPi ^{dl}_{v,i})$ and $d_{t,i}\!\leftarrow \mathcal {V}_{dl}((g, x_{t,i}, \mathsf {pk_t}, w_{t,i} / t_i), \varPi ^{dl}_{t,i})$ for all $i = 1, \dots , n$, where $((x_{v,i}, w_{v,i}), (x_{t,i}, w_{t,i})) \in \textbf{evt}, v_{i} \in \textsf{res}, t_{i} \in \textbf{t}$.

The correctness of Selene follows from the correctness of ElGamal, the completeness of the verifiable shuffles and the straight-forward computation

$$\begin{aligned} \textsf{ExtractTracker}(\textsf{vsk}, ct, \textsf{ClaimTracker}(\textsf{vsk}, ct, g^{t})) = ct\cdot \left( \left( ct/g^{t} \right) ^{1/\textsf{vsk}} \right) ^{-\textsf{vsk}} = g^{t} \text{. } \end{aligned}$$

Note that in the original description of Selene [31], the exact manner of which the voters prove knowledge of their plaintext in the voting phase is left abstract. However, several different approaches are possible. One may, for example, produce a Schnorr proof of knowledge [34] of the randomness used by the encryption algorithm. We choose a different approach, and include a check value $\hat{x}$ and give a Chaum-Pedersen proof that $\log _{h_{v}}\hat{x} = \log _{g}x$. Both are valid approaches, however our approach simplifies the security proof by avoiding rewinding.

4.2 Security Result

We say that an adversary against a voting scheme is non-adaptive if every voter key reveal query is made before the tracker generation query.

Theorem 1

Let $\mathcal {A}$ be a non-adaptive $(\tau , n_{v}, n_{c}, n_{d}, n_{s})$-adversary against Selene, making at most $n_{v}$ registration and chosen voter key queries, $n_{c}$ challenge and coerce queries, $n_{d}$ chosen ciphertext queries, and $n_{s}$ shuffle/chosen shuffle queries, and where the runtime of the adversary is at most $\tau$. Then there exist a $\tau '_{1}$-distinguisher $\mathcal {B}_{1}$, a $\tau '_{2,1}$-distinguisher $\mathcal {B}_{2,1}$, a $\tau '_{2,2}$-distinguisher $\mathcal {B}_{2,2}$ and a $\tau '_{3}$-distinguisher $\mathcal {B}_{3}$, all for DDH, $\tau _1', \tau _{2,1}', \tau _{2,2}', \tau _3'$ all essentially equal to $\tau$, such that

$$\begin{aligned} \textsf{Adv}^{\mathrm {{\mathsf {vote{-}x}}}}_{\textsf{Selene}}(\mathcal {A})&\le \textsf{Adv}^{\mathrm {{\textsf{DDH}}}}_{\mathbb {G},g}(\mathcal {B}_{1}) + 2 n_{s}(\textsf{Adv}^{\mathrm {{\textsf{DDH}}}}_{\mathbb {G},g}(\mathcal {B}_{2,1}) + \textsf{Adv}^{\mathrm {{\textsf{DDH}}}}_{\mathbb {G},g}(\mathcal {B}_{2,2})) \\&\mathrel {} + \textsf{Adv}^{\mathrm {{\textsf{DDH}}}}_{\mathbb {G},g}(\mathcal {B}_{3}) + \text {negligible terms,} \end{aligned}$$

where $\textsf{x} \in \{ \textsf{priv}, \mathsf {c{-}mit}, \textsf{int} \}$.

(Better bounds in the theorem are obtainable, but these are sufficient.)

4.3 Proof Sketch

We begin by analysing the integrity events. Count failures cannot happen. If we get an inconsistent result, then either the equality of discrete logarithm proofs used by the decryption algorithm or the shuffle proofs are wrong. The soundness errors of the particular proofs we use are negligible (and unconditional), so an inconsistent result happens with negligible probability. The same analysis applies to non-unique results as well as inconsistent verification.

We now move on to analysing the privacy event. The proof is structured as a sequence of games. We begin by simulating the honestly generated non-interactive proofs during ballot casting. This allows us to randomize the check values $\hat{x}_{v}$ in honestly generated ballot proofs, so that we afterwards can embed a trapdoor in $h_{v}$. The trapdoors allow us to extract ballots from adversarially generated ciphertexts. The shuffle we use also allows us to extract permutations from adversarially generated shuffles by tampering with a random oracle. This allows us to use the ballots from chosen ciphertext queries to simulate the decryption, so we no longer use the decryption key. The next step is to also simulate the honest shuffles, before randomising the honestly generated ciphertexts (including encrypted trackers) and the re-randomisations of these ciphertexts. Finally, we sample tracker commitments at random and compute the openings from tracker generation using the $\textsf{ClaimTracker}$ algorithm. This change is not observable, and makes the computation of tracker commitments and openings independent of the challenge bit. This makes the entire game independent of the challenge bit, proving that the adversary has no advantage.

The complete security proof can be found in the full version [21].

5 Other Variants of Selene

There are [30, 31] some challenges tied to the use of trackers in Selene. First, if the coercer is also a voter, there is a possibility that a coerced voter points to the coercer’s own tracker when employing the coercion evasion strategy. Second, publishing the trackers in the clear next to the ballots might affect the voters’ perceived privacy, and some might find this troublesome.

To address the first challenge, the authors of Selene have proposed a variant they call Selene II. Informally, the idea is to provide each voter with a set of alternative (or dummy) trackers, one for each possible candidate, in a way that the set of alternative trackers is unique to each voter. This way, it is not possible for a coerced voter to accidentally point to the coercer’s tracker. However, trackers are still published in the clear.

Both challenges are also addressed by Ryan et al. [30], who have proposed a voting system they call Hyperion. The idea is to only publish commitments next to the plaintext ballots, rather than plaintext trackers. Furthermore, to avoid the issue that voters might accidentally point to the coercer’s own tracker, each voter is given their unique view of the bulletin board.

For both Selene II [31] and Hyperion [30], we refer to the original papers for the full details of the constructions, but we briefly describe here how these systems fit into our framework. We first remark that in Selene II, it is necessary that the encryption system used to encrypt the ballots supports plaintext equivalence tests (PETs). As in the original description of Selene, we use ElGamal encryption to encrypt the ballots, so PETs are indeed supported (see e.g. [24]).

For Selene II, we need to change the $\textsf{TrackerGen}$ algorithm so that it outputs $c+1$ trackers for each voter, where c is the number of candidates, and c “dummy” ciphertexts, one ciphertext for each candidate. We let the last tracker be the one that is sent to the voter to be used for verification. By construction, for all voters there will be an extra encrypted ballot for each candidate. Thus, the $\textsf{DecryptResult}$ algorithm works similarly as for Selene, except that it needs to subtract $n_v$ votes for each candidate, where $n_v$ is the number of voters. The voting protocol must also be changed. Before notifying the voters of their tracking numbers, the EA must now perform a PET between each voter’s submitted ciphertext, and each of the “dummy” ciphertexts belonging to the voter, before removing the ciphertext (and the corresponding tracker) containing the same candidate as the voter voted for. This way, all voters receive a set of trackers, each pointing to a different candidate, which is unique to them. The opening to their real trackers is transmitted as usual, and thus the $\textsf{ExtractTracker}$ algorithm works as in Selene. The $\textsf{ClaimTracker}$ algorithm also works exactly as in Selene, except that voters now can choose a tracker from their personal set of dummy trackers, thus avoiding the risk of accidentally choosing the coercer’s tracker.

For Hyperion, the modification of the $\textsf{TrackerGen}$ algorithm is straight forward: we simply let it compute tracker commitments as described in [30], namely by (for each voter) sampling a random number $r_{i}$ and computing the commitment as $\textsf{vpk}_{i}^{r_{i}}$. At the same time, an opening is computed as $op_{i} \leftarrow g^{r_{i}}$. The $\textsf{Shuffle}$ algorithm still shuffles the list of encrypted ballots and tracker commitments in parallel, in the sense that they are subjected to the same permutation. However, the encrypted ballots are put through the same re-encryption shuffle as before, but the tracker commitments are put through an exponentiation mix, raising all commitments to a common secret power s. The $\textsf{DecryptResult}$ algorithm now performs additional exponentiation mixes to the commitments, one mix for each voter (by raising the commitment to a secret power $s_{i}$, unique to each voter), giving the voters their own unique view of the result. For each voter, it also computes the final opening to their commitments, as $op_{i} \leftarrow g^{r_i \cdot s \cdot s_i}$. Again, we need to change the voting protocol, this time so that each voter actually receives their own view of the bulletin board. The $\textsf{ExtractTracker}$ algorithm raises the opening $op_{i}$ to the voter’s secret key and loops through the bulletin board to find a matching commitment. The $\textsf{ClaimTracker}$ algorithm uses the voter’s secret key to compute an opening to a commitment pointing to the coercer’s desired ballot.