Paper 2018/1052

Verifiability Analysis of CHVote

David Bernhard, Véronique Cortier, Pierrick Gaudry, Mathieu Turuani, and Bogdan Warinschi

Abstract

This document details analyses of verifiability properties of the CH-Vote v1.3 electronic voting protocol, as defined by the preprint publication [12]. Informally, these properties are: • Individual verifiability: a voter is convinced that a ballot confirmed as coming from the voter contains his intended vote • Ballot verifiability: all ballots that are confirmed contain correct votes • Eligibility uniqueness: there are no two distinct entries in the list of confirmed ballots which correspond to the same voter • Confirmed as intended: if a confirmed ballot is on the bulletin board for some voter, then that ballot records that voter’s voting intention • Universal verifiability: any party can verify that the votes on this board were tallied correctly The analyses employ the currently well-established approach used within the scientific community. Specifically, they rely on mathematical abstractions for the adversary and for the system under analysis, as well as mathematical formulations of the properties to be established. Mathematical proofs are then used to establish that (under certain assumptions) the security properties hold. We provide two types of analysis (which differ in the level of abstraction at which they operate). Part I contains a pen-and-paper computational/cryptographic analysis. Part II describes an automated symbolic analysis. Broadly speaking, both the symbolic and the computational analyses conclude that CH-Vote satisfy the desired security properties under several assumptions. The assumptions include, for example, computational assumptions (which mathematical problems are assumed to be hard), trust assumptions (which parties, if any, are assumed to behave honestly and what are parties assume to know before they interact with the system). Besides the concrete mathematical statements the analyses led to a number of recommendations which aim to improve the security. Part III concludes with a number of recommendations which reflect assumptions made in the analyses and weaknesses that were identified. The recommendations also sum up the results of a (light) code review of the code available via GitHub 1 – commit 9b0e7c9fcd409, from April 2017.