• No results found

Remote E-Voting

4.4 EV-1: SCWS-PAV

retrieved by the VA and subsequently deleted from the SCWS after it is cast. The vote is also kept on the SIM for future reference, encrypted with P U BV. This encryption is not strictly necessary, but is included to provide an additional security measure in case space restrictions mean the vote is stored in non-tamper-resistant memory or on the phone. A flag is set to indicate that the IDV has been used to vote. Once the vote is encrypted, the SCWS administration agent will either trigger a connection with the RAS, or the RAS can automatically retrieve the vote on a specific day/time. In both cases the two entities initiate an HTTPs connection and the vote is collected via the FAP. The RAS passes the signed vote (unchanged) to the VA, tagged with a temporary ID so that the vote receiving process at the VA does not find out the mobile number, as this could be used to link the voter to a particular vote. Once the vote is received by the VA, the voter receives a notification that their vote was cast via a second channel e.g. an SMS message, IVR or an email. Steps 12 to 15a/b in Figure 4.1 show the vote storage and sending process. Using the SCWS model keeps all sensitive vote information private in a tamper resistant environment, so that no one can determine how a voter voted.

4.3.6 SCWS e-Voting Generic Model: Summary

The SCWS e-Voting generic model presented here inherits many desirable security properties from its use of a) the tamper-resistant environment of the SIM for vote storage and processing, and b) the standardised and tightly controlled management procedures associated with the SCWS. A security analysis is shown later in this chapter, in Section 4.6.

The next section describes the first e-voting use-case, EV-1: SCWS-PAV which demonstrates how the generic SCWS model can be used with the Prˆet `a Voter e-voting system.

4.4 EV-1: SCWS-PAV

4.4.1 Prˆet `a Voter - Background Information

Prˆet `a Voter (PAV) [81, 244, 245, 246] is a paper-based e-voting system designed for the supervised environment of an election polling-station. The paper ballot form is used as input to a cryptographic system. The electoral process can be audited by voters and third parties, to give end-to-end verifiability. Voters can verify the system in two ways: by performing dummy votes not included in the final tally, which are intended to check that the cryptography used in the ballot form is correct; and by checking that

4.4. EV-1: SCWS-PAV 4. Remote E-Voting

their vote appears on a secure Web Bulletin Board (WBB) once it has been cast.

Voters are given a paper ballot form, and they mark their choice with an X. Every ballot form is different, as candidates are listed in a (different) random order on each one. There is a code (called an “onion”) which contains details of the candidate order in encrypted form. When the vote is cast, the left hand side of the form (containing the candidate names) is detached and destroyed, leaving the voter with a voting slip showing the position of their vote on the form, but not who the chosen candidate was.

The vote is input to the PAV system and the voter is given the slip as a receipt which can be checked against a web bulletin board at a later stage. The actual vote recorded in the system is the numerical position of the voter’s choice and the onion i.e. (index, onion).

The PAV scheme was extended in [246] by including confirmation codes for each candidate, printed on the ballot form. These codes are calculated by the VA prior to the election. Once a voter has cast their vote, the confirmation codes are recalculated by the VA and relayed back to the voter at the poll-site. The voter can check this received value against a confirmation code hidden on the ballot form under a scratch-off strip, which only they should see. The voter’s receipt contains the position (index) of their chosen candidate, the associated confirmation code and the onion. Figure 4.2 shows a paper ballot form with confirmation codes, before and after voting, with the onion in the bottom right corner.

In the PAV scheme, ballot forms can be printed on demand by the voting booth, as described in [245]. Briefly, two related onions are calculated for each ballot form, the

“booth onion”(left onion) encrypted with the public key of the voting booth, and the

“registrar onion” (right onion) encrypted in the normal PAV way. These “proto-ballot”

forms can be distributed and stored securely prior to the election. Alternatively, the left onion could be encrypted with P U BV (rather than a booth key) without losing any security, by using ElGamal for distributed blinding as described in [247]. On Election Day, when a voter takes a ballot form into the voting booth, the booth reads the left onion, uses its previously stored secret key to decrypt the onion, reconstructs the candidate list and prints the ballot form. The vote is cast using the right onion, i.e.

(index, right onion).

4.4.2 Using the SCWS with Prˆet `a Voter

It is the ability to print ballot forms on demand, along with the use of confirmation codes that make PAV a suitable example e-voting system to use with the SCWS model.

The advantage of using PAV with confirmation codes is that most of the cryptography (i.e. generating the onions) is done by the VA before the election starts, so this

min-4.4. EV-1: SCWS-PAV 4. Remote E-Voting

Figure 4.2: Prˆet `a Voter Ballot Forms Before and After Voting

SCWS Admin Agent

imises the amount of cryptographic processing necessary in the restricted environment of the SIM. With suitable modifications to the generic model, the SCWS voting appli-cation can play the part of the PAV voting booth, to decrypt the candidate ordering and hence display ballot forms. The SCWS can also store confirmation codes securely so that when the voter receives a code from the VA (in an SMS) the two values can be compared. Figure 4.3 shows an overview of the design.

4.4. EV-1: SCWS-PAV 4. Remote E-Voting

Installation of Keys and Application onto SCWS

In Message 2 of the protocol shown in Figure 4.1, PAV candidate lists and proto-ballots (including confirmation codes) are sent to the SCWS along with the voting application and other credentials. The left onion must be encrypted with P U BV, using the ElGamal blinding technique mentioned earlier. It is suggested that several proto-ballots are sent, as this allows the voter to cast dummy votes to audit the system if they so desire.

Authentication

The authentication stage remains the same as the generic SCWS approach, but when the ballot form is to be displayed (Message 7 in Figure 4.1), the PAV method of constructing the candidate order must be followed. This involves decrypting the left onion using ElGamal and P KV, and then reconstructing the candidate order using a predetermined PAV procedure [244, 245]. The ballot form can then be displayed (minus confirmation codes).

Choosing a Candidate/Vote Storage

Choosing the candidate and voting is the same as in the generic SCWS approach. The confirmation code for the selected candidate is displayed along with Message 11. Once the candidate has been chosen, the vote needs to be signed with the voter’s signing key before it is retrieved by the RAS. A copy of the vote with its associated confirmation code is encrypted with P U BV and stored on the SCWS. Storing the confirmation code on the SCWS ensures that at a later stage, only the voter can see this code (as specified in PAV). Finally, a flag will be set on the SCWS to indicate that the voter has voted.

Vote Sending

The RAS passes the signed vote (unchanged) to the VA, as in the generic model. Once the VA has received the vote, checked its validity, and posted it to the bulletin board, it will recalculate the confirmation code for the chosen candidate, and send it and the temporary ID to the RAS. The confirmation code can then be returned to the voter via a second channel (SMS/IVR/email), for checking against the one previously displayed on the phone browser and stored on the SCWS. This provides assurance that the vote was counted as cast because the correct confirmation code can only be generated at the VA once it has been successfully decrypted and matched to a valid entry in the bulletin board.