Rapport explicatif

En ce qui concerne la présente exigence, il faut supposer que l’attaquant a accès aux données d’authentification client de certains électeurs.

Ch. 2.6 : un vote n’est considéré comme ayant été émis conformément à la procédure prévue par le système que si les données d’authentification client utilisées correspondent à des données d’authentification serveur ayant été définies et « attribuées » à un électeur pendant la phase de préparation du scrutin. La preuve doit donc inclure la confirmation qu’aucunes données d’authentification non attribuées n’ont été créées pour l’émission de suffrages. À cette fin, les composants de contrôle ou les vérificateurs doivent avoir reçu lors de la préparation du scrutin des données correspondantes destinées à servir de moyen de comparaison. Les vérificateurs doivent établir que le nombre des données d’authentification correspond au nombre (officiel) des électeurs autorisés à voter. Dans ce cas, on peut considérer que les données d’authentification ont été « attribuées » à un électeur. Il est vrai que cela ne garantit pas que des données d’authentification client d’électeurs fiables n’ont pas été utilisées abusivement pour émettre un suffrage conformément à la procédure prévue par le système. Toutefois, selon le ch. 2.5, les électeurs doivent être en mesure de le déterminer.

Ch. 2.7.3 : on peut supposer que la manipulation du logiciel du serveur est sans effet sur la fiabilité de la plate-forme utilisateur pendant la vérification.

Les possibilités de protéger les plates-formes utilisateur contre les risques d’abus sont beaucoup plus faibles que pour les composants dans un environnement protégé. C’est cependant délibérément, dans un souci de convivialité, qu’on n’a pas voulu utiliser le protocole cryptographique pour garantir le secret du vote et l’absence de résultats partiels anticipés. Le protocole doit toutefois offrir une protection là où les suffrages sont conservés de manière centralisée. Qualifier la plate-forme utilisateur de « fiable » indique qu’il n’y a pas lieu de prendre en compte d’attaque contre la plate-forme utilisateur lors du développement et de l’analyse du protocole cryptographique (voir le commentaire introductif du ch. 2).

Ch. 2.9.3 : l’une des conséquences est que la clef nécessaire au déchiffrement des suffrages doit être répartie entre quatre composants de contrôle différents. Au moins un de ces composants de contrôle doit être exploité par le canton (comme cela est dit expressément au ch. 3.1).

Une proportion importante des électeurs doit être considérée comme non fiable afin que le système NF puisse apprendre en collaboration avec un électeur non fiable le contenu d’un suffrage émis. À cette fin, il faut s’assurer que cet électeur ne puisse faire passer pour sien un suffrage chiffré émis, même après adaptation externe, dans le but d’apprendre le contenu du suffrage au moyen de la preuve obtenue dans le cadre de la vérification de la preuve prévue au ch. 2.5.

Un attaquant pourrait essayer avant le dépouillement de marquer des suffrages avec l’aide des participants non fiables du système pour ensuite compromettre le secret du vote au moyen des suffrages décryptés. Après le dépouillement, les vérificateurs pourraient constater que les suffrages n’ont pas été traités conformément à leur saisie, mais sous une forme marquée. À ce stade, cependant, le secret du vote aurait déjà été compromis. Il s’agit de prévenir une telle situation au moyen de composants fiables garantissant avant le dépouillement qu’aucun suffrage marqué ne sera traité. Au regard de cet objectif, un dispositif technique des vérificateurs peut lui aussi être considéré comme fiable.

En ce qui concerne le qualificatif « fiable » appliqué à la plate-forme utilisateur, voir le commentaire du ch. 2.7 (deuxième paragraphe).

Ch. 2.11.1 : l’une des conséquences de cette disposition est qu’une preuve doit pouvoir prendre au moins 1000 valeurs différentes (pour un code numérique, par ex., toutes les valeurs entre 000 et 999). Ainsi, la probabilité pour l’attaquant de deviner correctement une preuve serait exactement de 0,1%. En recueillant des informations sur les participants du système et les canaux de communication non fiables, il pourrait se procurer un avantage qui lui permettrait de ne plus avoir à deviner le code entièrement au hasard, ce qui augmenterait d’autant la probabilité précitée. Eu égard à ces éventualités, un code doit pouvoir prendre a priori des valeurs en nombre suffisant pour que la probabilité ne dépasse pas 0,1%.

Ch. 2.11.3 : Admettons à titre d’hypothèse que ladite probabilité est de 1 %. En ce cas, il y aurait lieu de répéter les décomptes jusqu’à ramener cette probabilité à moins de 1 %. Une répétition de ces décomptes doit ainsi permettre de réduire cette probabilité autant que nécessaire.