Laboratory Council Election✯

French version here

For software editor online instructions you can refer to the Belenios website.

Instructions for the voter✯

Before the election starts, the voter receives an email that contains their private credential and the url of the election. The election page displays the opening time when it is not yet open.

During the election, a voter can visit the election page and vote as follows:

• they enter their private credential. This step is done automatically if the url of the election received by the voter has been personalized with the credential of the voter (e.g. when the credentials are sent by the server).
• they can then see the questions and select their candidates
• their computer encrypts their choices (with a Javascript program) and prints a smart ballot tracker which is a fingerprint of the ballot. This smart ballot tracker is also sent by email to the voter when they have completed the voting procedure.
• once the voter has reviewed their choices, they have to authenticate themself. To do so, they then receive a one-time password by email, that should be entered into the voting interface. Other authentication means may be used (for example, a password may be sent before the start of the election).
• note: a voter may vote again. Only the last vote will count.

The Belenios system is verifiable.

• a voter may check that their ballot is indeed taken into account, by looking for their smart ballot tracker on the ballot box, visiting the link See accepted ballots on the main page of the election. They must complain if this is not the case. For even more security, the voter can perform this check with another device, possibly from a different location. If a voter votes several times, only the last smart ballot tracker appears on the ballot box.

• The voter must also vehemently protest if they receive a confirmation email that contains a smart ballot tracker that is different from the one that was printed on the screen during the voting phase. Somebody probably managed to add a ballot in their name. This can for instance be a hint of an attack by a system administrator who has access to the mailbox of the voter, in the case where both the credential and the one-time password are sent to the same address.

A voter can also verify the whole voting process. Instead of checking only the presence of their ballot in the ballot box, they can verify the validity of all the ballots, they can monitor the ballot box to check that no ballot disappears (except in case of revote), and finally check that the claimed result corresponds to the ballots in the ballot box. For all of this, the voter can follow the auditor instructions below.

Instructions for the committee in charge of the election✯

At the very least, the election committee visits the page of the election once it is open and checks that:

• the number of voters corresponds to the voter list;

• the value voter list fingerprint published corresponds to the one that is given (by the system or by the administrator of the election). This fingerprint can be computed using one of the commands suggested here;

• the voter list voters.txt corresponds to the legitimate voters, with the right weight in case of a weighted vote;

• the list of questions and possible answers correspond to what is expected. These questions and answers are also in the $UUID.bel file that can be obtained by clicking on public data in the footer of the election page.

Ideally, the election committee also performs the tasks of an auditor or commissions someone for doing it (a sysadmin of the organization, for instance).

Instructions for the auditor✯

Anyone who knows the url of the election can be an auditor. The url of an election is of the form PREFIX/elections/UUID/, where, for instance, PREFIX=https://vote.belenios.org and UUID=8GVH85AoSyweXG.

An auditor will ensure in particular that:

• the election data (public keys, public credentials, etc) are consistent and do not change over time;

• the ballot box, that contains the encrypted votes, evolves consistently: no ballot is removed unless it is replaced by a ballot with the same credential (this corresponds to a revote);

• the ballot box only contains well-formed ballots (with valid zero-knowledge proofs, and valid credentials);

• the integrity of active files (HTML, Javascript, etc.) used by the voters, the trustees and the credential authority is preserved;

• the result of the election corresponds to the encrypted ballots, thanks to the zero-knowledge proofs of correct decryption produced by the decryption trustees.

The security of Belenios relies on the fact that the verifications described below are performed by at least one honest person.

Note: these verifications are also run automatically by our servers for the elections that are setup with a maximum security level (external credential authority and at least two external trustees).

Setup. In order to do these tests, the auditor must use some software. We describe here how to run the verifications using belenios-tool, the sources of which are available from Gitlab Inria and that can be installed under Linux Debian/Ubuntu using sudo apt install belenios-tool. Then the auditor must create a directory workdir where the election audit information will be stored as they are downloaded, in the form of a git repository.

In order to check that the HTML/Javascript codes used by voters, decryption trustees, and credential authorities are not modified by a corrupted server, the auditor needs to find out the “right” code for each of these programs. They will then make sure the server delivers these files uncorrupted. First, a template must be prepared: we just copy it from the Belenios sources:

cp path/to/sources/belenios/contrib/reference_template.json workdir/hashref

Then, there are several solutions to ensure that the files served by the server are valid, while monitoring the election identified by UUID:

• either the auditor simply trusts the files downloaded the first time and checks that they do not vary over time (TOFU principle). Then the monitoring command is as follows:

    ./monitor_elections.py --url PREFIX --wdir workdir --checkhash yes --hashref workdir/hashref --outputref workdir/hashref --uuid UUID
  

  Each time the files change (including at the first run), this will print a warning message.

• or the auditor fetches the sources, recompile the code, start a local server, uses the previous command to fill-in the workdir/hashref file with trusted values, and copy it to use it as a reference for monitoring the real election that is run on an external server. The command is then the same as above.

• or the auditor trusts a well-identified person who published a gpg-signed version of the reference file. In that case additional arguments must be passed to the monitoring tool: the url of this signed version and a gpg keyring containing the public key of the person, as a trusted one. In the case of our voting platform, such a file is provided by the main developer of Belenios, Stéphane Glondu. We give the corresponding command-line, to be adapted for another server or another trusted person:

    ./monitor_elections.py --url https://vote.belenios.org/ --wdir workdir --checkhash yes --hashref workdir/hashref --outputref workdir/hashref --sighashref https://vote.belenios.org/monitoring-reference/reference.json.gpg --keyring workdir/trustdb.gpg --uuid UUID
  

In all cases, the auditor will regularly execute a monitoring command that we call monitor_elections. It is possible to redirect the messages with the --logfile option. Then only abnormal behaviours are reported on stdout/stderr, which makes it possible to run the command from a crontab and to be warned in case of problem.

Voting phase. During the election, it is expected that the auditor:

• in case the auditor has access to the voter list voters.txt (requested to the committee in charge of the election), verifies that the number of voters displayed on the main page of the election corresponds to the voter list, as well as the total weight of the election in case of a weighted vote, and that the fingerprint of the voter list corresponds to the fingerprint saved before, for instance using one of the commands suggested here;

• if the auditor has not access to the voter list, verifies that the number of voters and total weight of the election displayed on the main page of the election correspond to the official data;

• frequently runs monitor_elections. Ideally, this should be done at non guessable points of time, from various IP adresses that reflect the diversity of voters and trustees. The goal is that a corrupted server cannot guess when the request comes from an auditor or a genuine voter / trustee. Here are a few guidelines for a motivated auditor in order to look like a genuine user:

  • as already said, the requests to the server should be done frequently but not at a regular, predictable rate;
  • not only various IP adresses should be used but also with various device configuration information (browser type and version, operating system, active plugins, time zone, language, screen resolution, etc) from a large pool of typical device configurations used in reality by humans;
  • IP adresses should reflect the various locations and service providers of the population of voters;
  • the order in which the files are requested to the server should follow the order of typical visits of voters and trustees, with plausible (non predictible) delays between each request of files.

  Note that the script provided in belenios-tool does not offer support for this.

After the tally. After the election, it is expected that the auditor:

• runs again monitor_elections. The election page now contains a result.json file and this command will check the cryptographic proofs associated to the result of the election;
• verifies that the result mentioned in the result.json file corresponds to the result published on the page of the election. This verification must be done manually.

Note: If the belenios-tool command-line tool is used, the trust in the audit verifications partly relies on the trust in this tool. It is possible to write independent verification software following Belenios specification available here.

How to compute the fingerprint of a file?✯

To compute the fingerprint of a file, you need to use the same hash algorithm as the one used in Belenios. We provide here possible solutions with command lines. We use the file voters.txt as example but of course you may replace it by any other file.

sha256sum voters.txt | xxd -p -r | base64 | tr -d "="

(or shasum -a256 instead of sha256sum for example on MacOS)

cat voters.txt | python3 -c "import hashlib,base64,sys;m=hashlib.sha256();m.update(sys.stdin.read().encode());print(base64.b64encode(m.digest()).decode().strip('='))"

You may also use the online tool supported by Belenios.