Problèmes de sécurité des systèmes de vote électroniques

Cette page est une liste de notes sur les problèmes de sécurité possibles des systèmes de vote électroniques/vote en ligne. Il s’agit aussi de lister les solutions potentielles lorsqu’elles existent.

Ces solutions ne sont PAS toutes implémentées dans PyVotons! surtout dans sa version alpha actuelle.

Contraintes

Un électeur peut voter une et une seule fois.

Seul l’électeur peut voter en son nom.

Le contenu du vote est secret pour tous les tiers (personne ne peut savoir pour qui l’électeur a voté)

On peut vérifier que son vote a été compté (registre de vote)

Aspects sociaux/humains

– quelqu’un d’autre utilise votre identité (par exemple à l’intérieur d’une même famille)
– vol ou perte des identifiants
– quelqu’un regarde par-dessus l’épaule ce que choisit l’électeur : isoloir, vote dans un lieu contrôlé (pression pour voter dans un sens ou un autre, corruption…)
– administration du serveur : quel logiciel, quel code s’exécute, quelle est la réalité des résultats…Plusieurs personnes devraient avoir la possibilité de contrôler (idéalement, chacun devrait avoir un accès en lecture au serveur (sauf les identifiants, mots de passe et les votes en cours de scrutin.
– Des humains doivent répondre aux problèmes signalés par les électeurs (détection des problèmes rapide et correction réactive).

Technical aspects

– Chiffrement des communications client-serveur sur internet : gestion des clefs et signatures HTTPS. La librairie OpenSSL utilisée par le serveur Python n’est PAS parfaitement fiable, comme le bug Heartbleed récent l’a démontré…
– stockage des mots de passe (hash, salt, pepper, bcrypt ou PBKDF2), une bonne explication, 3ème facteur d’authentification (envoi d’un code par SMS ?)
– attaques par mesure de durée (le succès ou l’échec de l’identification que ce soit à cause de l’identifiant ou du mot de passe doit prendre le même temps)
-signer les votes ? GnuPG
– filtrer et contrôler toutes données reçues du client and traiter toute donnée d’entrée comme potentiellement néfaste (en particulier liens et scripts dans les textes proposés, par exemple JS, PHP, SQL…).
– SQL : preparer toutes les requêtes (pas de concaténation de chaînes)
– failles de mémoire : utiliser un langage avec contrôle de la mémoire (Python, Java…), ou utiliser des pointeurs à compteur de référence/malloc sécurisé/valgrind…
– Attaques de déni de service distribuées (Filtrage par IP ? Détection de flood dans le système ?)
– Un vote et un seul par électeur
– Impossibilité de lier électeur et contenu du vote.
– l’analyse des heures ne doit pas permettre de connaître le contenu d’un vote (pas de résultats en temps réel car si on sait quand X a voté, on peut savoir ce qu’il a voté)
– il faut valider côté serveur toutes les données provenant du client
– mise à jour de sécurité : les serveurs doivent être à jour.
– minimiser la surface exposée à l’extérieur (firewall, droits d’utilisateurs du serveur web, de la base de données aussi faibles que possible)… Séparer le logiciel serveur en plusieurs processus (un pour l’identification, un pour le serveur web : compromettre l’un ne doit pas compromettre la totalité.
– écrire des tests pour vérifier les réactions à des données malveillantes envoyées par le client.
– pas de fuite de données entre les utilisateurs identifiés : un processus par utilisateur authentifié ?
– qu’est ce qui est stocké dans les logs côté serveur ? Qu’est-ce qui est nécessaire pour détecter des attaques ou des anomalies par rapport à la confidentialité des votes ?