[gull] le 13e bit frappe (vote electronique)

[Martial Guex]

> D'où l'importance de conserver les bulletins de votes électroniques,
> comme on conserve les bulletins de vote en papier, pour pouvoir
> les recompter.
> Une solution qui ne fait que compter les votes, en les oubliant
> après, ne peut pas être satisfaisante à mon avis
> (car susceptible à des attaques de type DoS)

L'idée que j'avais dans une analyse en cour et d'utiliser un identificateur de 
votant unique pour un vote. Cette id assure une tracabilité du vote pendant 
le processus et permettrai même sous le contrôle d'une autorité qq de faire 
sauté l'anonymat.

> Pour compter, on peut fortement augmenter la sécurité en faisant
> comme dans les avions modernes, contrôlés par ordinateurs:
> 2 ordinateurs différents, avec des architectures différentes
> et des systèmes d'exploitation différents, sur lesquels tournent
> des programmes différents, conçus par des équipes différentes,
> avec des langages (et compilateurs) différents...
> Et en cas de litige, un arbitrage est donné par un troisième
> ordinateur, différent bien sûr...

C'est ce que j'ai décrit dans ma première réponse en indiquant que l'on 
pouvait utilisé plusieurs chaînes de traitements différents pour la même 
information.

> Paranoia, oui. Mais qu'est-ce qui coute le plus cher ?
> Un nouveau programme sur un nouvel ordinateur, ou la
> crédibilité du système de vote ?

Pour la crédibilité j'avais pensé à inclure dans les protocoles de test 
d'utiliser des pseudo votation avec le même système ou le votant pourait 
contrôler si son vote était bien comptabilisé au bonne endroit en fin de 
chaîne. D'ailleur rien n'empêche d'offrir cette option dans le vote réel en 
diffusant une liste des id des votants ayant voté oui ou non pour tel chois 
ou tel personne si le votant le désire.

> Je serais plus prudent. La probabilité est surement ridicule
> quand on teste en quelques microsecondes, mais elle ne l'est
> peut-être plus autant quand un programme réside en mémoire
> plusieurs heures (10^10 fois plus).
> Tous les utilisateurs de CCD avec des très longs temps de poses
> (minutes ou heures) vous diront les problèmes causés par les
> rayons cosmiques. Et quand on dit "rayons cosmiques", cela
> inclut la radioactivité, artificielle ou naturelle. Y compris
> la radioactivité résiduelle des céramiques encapsulant les puces.

Cela doit pouvoir être quantifiable en attribuant des valeurs données dans une 
partie de la mémoire et de contrôler périodiquement afin de détecter un 
changement, bon avec de la ECC la probabilité que deux 2 bits changes entre 
deux accès à un byte et certainement négligeable.

> Cela dit, c'est toujours une explication trop facile des experts
> face à cette erreur de vote.

C'est des rigolos.

> Mais de toute façon, la sécurité du vote, comme la sécurité
> en général, est une chaine qui n'est pas plus forte que
> son maillon le plus faible.
> Et le maillon le plus faible sera toujours chez les citoyens:
> après la généralisation du vote électronique,
> combien de temps faudra-t-il pour voir apparaître un worm
> s'installant discrètement en mémoire et hookant les messages
> Windows pour transformer les oui en non ou l'inverse le jour J ?
> Faudra-t-il tester la configuration d'où le vote est émis
> pour le valider ? Ou s'accomoder d'un pourcentage de votes
> pollués par des virus ?

C'est pour cela que j'ai proposé qu'une confirmation du vote se fasse par 
téléphone. Par ailleur rien n'empêche de compliquer la vie des "worm" en 
utilisant des astuces comme l'utilisation de label de champs sous forme 
d'image, de nom de champs variables pour la même donnée. On peu même proposé 
un programme de contrôle spécifique permettant de sniffer le réseau et 
affichant le vote réellement envoyé au serveur web.

> Il me semble qu'on va vers des problèmes pas tristes...

C'est sur mais il doit être possible d'arriver à une solution permettant 
d'assurer une fiabilité permettant son exploitation. Le tout est de savoir si 
le coup et le mode d'utilisation ne serai pas dissuasif.

A+
Martial Guex