Gravatar couramment utilisé Blog perso de Paul Da Silva

Le vote par Internet, c’est pire au second tour !

Posted on | juin 10, 2012 | 19 Comments

Aujourd’hui se tient le premier tour des législatives en France métropolitaine. Pour les Français établis à l’étranger cependant on en est déjà à la tenue du second tour sur Internet. L’occasion pour Laurent Grégoire de continuer à mettre à l’épreuve le vote par Internet… Et ce qu’il a trouvé est pire encore que lors du premier tour.

Toujours en se servant d’une injection de code il a cette fois essayé de prouver que l’on pouvait influer sur le contenu de son propre vote pour voir si le système était suffisamment bien conçu (spoiler : il ne l’est pas) pour tenir compte du cas de figure « je suis un méchant et je veux truquer le vote ».

Voter pour un candidat fantôme

Le candidat du Parti Pirate n’ayant pas recueilli suffisamment de votes pour se maintenir au second tour il n’était pas présent dans les choix proposés cette fois-ci. Les propositions restantes étaient l’UMP, le PS ou le vote blanc.

Qu’à celà ne tienne, ajouter un candidat n’est pas bien compliqué, il suffit d’un put :

———[com.scytl.pnyx.client.communication.application.MessagesProtocol]———

public VoteReceipt doCastVote(ClientData clientData) throws ApplicationProtocolException, PnyxProtocolException
{
Map<String, QuestionAnswer> vote = clientData.getTrustedBallot().getBallotAnswers();
for (Map.Entry<String, QuestionAnswer> kv : vote.entrySet()) {
ValuedMultipleChoiceQuestionAnswer qa = (ValuedMultipleChoiceQuestionAnswer)kv.getValue();
Map<String, String> answers = qa.getAnswerIdValues();
for (Map.Entry<String, String> kv2 : answers.entrySet()) {
kv2.setValue(null); // AUCUN VOTE
}
answers.put(« ff808081375acd2201375adad63d037a », « 1 »); // CANDIDAT PIRATE INEXISTANT
}
ClientDataManager clientDataMgr = new ClientDataManager(clientData);
String response = this._transport.sendMessage(this._secureMessageMessage.createMessage(clientDataMgr),
this._destinations.getPnyxCastVoteAction());
JOptionPane.showMessageDialog(JFrame.getFrames()[0], response); // AFFICHAGE DE LA REPONSE XML
return this._secureMessageMessage.parseResponse(response, clientDataMgr);
}

On pourrait penser que le machin ait la bête idée de vérifier que le vote que l’on vient d’envoyer est bien parmi les propositions valides… Ce serait sans compter sur la compétence de Scytl !

Non seulement le vote est accepté mais le tout fournit un beau reçu de vote valide à la fin de la procédure… Le total des votes sera donc supérieur d’au moins une voix au cumule des votes exprimés pour les candidats réellement en lice : UMP + PS + Blanc = total -1…

Le vote nul est-il prévu par le système de décompte ? On verra ça au dépouillement avec le reçu de vote… Et justement puisqu’on en parle !

L’identifiant de bulletin

Dans le système utilisé chaque vote a un identifiant donné généré de façon pseudo-aléatoire sur 24 octets. Laurent a eu la bonne idée de tester de modifier la génération de ce chiffre pseudo-aléatoire pour que la fonction qui le créé renvoie toujours 0x00 (zéro en hexadécimal).

Bien entendu l’applet n’y voit que du feu et laisse le vote se dérouler de façon classique. Et ce jusqu’à la fin, à la génération du reçu de vote qui étrangement se retrouve à avoir un identifiant qui vaut AAAAAAAAA. Il y a donc fort à parier que ce reçu est calculé en fonction de l’identifiant précédemment altéré. En poussant le vice on peut aussi supposer que la somme de contrôle en dessous (qui sert à vérifier son vote à postériori) est générée de la même façon.

Mais plus grave, cet identifiant de vote (qui sert à générer l’identifiant de reçu) étant tiré de façon pseudo-aléatoire dans un pool de 26^10 possibilités peut présenter des risques de collision (probabilité de collision de 1 – e^(-(n^2/(2 x 26^10)))) : deux votants pourraient avoir le même identifiant. Pour être précis, avec nos 700.000 inscrits le risque est de 0.17% sur le scrutin actuel, plus élevé si l’on envisage un scrutin à plus grande échelle… Comment réagirait le système dans ce cas ? Bah vérifiez vous même en vous attribuant l’identifiant 0x00 :

————–com.scytl.crypto.CryptographicAlgorithms————-

private byte[] encryption(int paramInt, byte[] paramArrayOfByte,
Key paramKey, String paramString) {
try {
Cipher cipher = Cipher.getInstance(paramString);
paramString = null;
byte[] buf = null;
if (cipher.getBlockSize() > 0) {
         buf = new byte[cipher.getBlockSize()];
         this._secureRandom.nextBytes(buf);

cipher.init(1, paramKey, new IvParameterSpec(buf));

buf = packSymetricMsg(buf,
cipher.doFinal(paramArrayOfByte));
} else {
cipher.init(1, paramKey);
buf = cipher.doFinal(paramArrayOfByte);
}
return buf;
} catch (GeneralSecurityException e) {
throw new RuntimeException(e);
}
}

public final byte[] generateRandom(int length) {
byte[] randomBytes = new byte[length];
   //this._secureRandom.nextBytes(randomBytes);
   for (int i = 0; i < length; i++)
      randomBytes[i] = 0x00;
return randomBytes;
}

Conclusion

Voici donc un vote qui s’est déroulé impéccablement alors même que l’identifiant du vote a été changé et que le candidat pour lequel le vote a été exprimé n’est pas présent dans les choix. C’est à se demander s’il ne serait pas possible de voter pour un candidat d’une autre circonscription en utilisant tous le même identifiant de bulletin…

La suite au dépouillement pour voir comment le système va avoir géré les bugs et comment le ministère va justifier l’injustifiable cette fois-ci…

Commentaires

19 Responses to “Le vote par Internet, c’est pire au second tour !”

  1. Laurent
    juin 10th, 2012 @ 12 h 27 min

    Si vous votez à l’étranger et que vous êtes intéressé pour faire cette expérience, n’hésitez pas à me contacter! Au chapitre des expériences qui reste à effectuer:
    1) Voir si on peut voter pour deux candidats en même temps, voire deux candidats et blanc.
    2) Que se passe-t-il si l’ID du bulletin est 0? (collision). Est-ce que le vote sera accepté? Quel est l’ID du reçu?
    3) Idem avec 1. Si l’ID du reçu est AAAAAAAAAA, cela confirmera le problème de collisions.

  2. JA
    juin 10th, 2012 @ 16 h 54 min

    @Laurent je peux tester si tu veux @ja25000

  3. Alban G
    juin 10th, 2012 @ 17 h 04 min

    Le fait de pouvoir voter pour un candidat non présent est possible dans les élections traditionnelles. Je pense que le bulletin sera compté comme nul.
    @laurent :le fait de vouloir voter 2 fois n’est pas punissable par la loi? Qu’en ai t-il dans le monde réel?

  4. Oumph
    juin 10th, 2012 @ 17 h 18 min

    L’avantage c’est que ça sera facile à vérifier après dépouillement grâce au serveur de vérification des reçus. Cf http://oumph.free.fr/textes/vote_internet_legislatives_2012_recus.html

  5. sam280
    juin 10th, 2012 @ 20 h 36 min

    Il y aurait beaucoup à dire sur l’aspect technique
    de cet article, mais je vais simplement reprendre
    vos deux points:

    > Le vote nul est-il prévu par le système de décompte ?
    > On verra ça au dépouillement avec le reçu de vote

    En effet on verra, donc pour l’instant vous n’avez rien
    démontré. D’ailleurs si je vais mettre dans l’urne
    un bulletin papier sur lequel j’ai écrit votre nom,
    mon vote sera bien enregistré.

    > Comment réagirait le système dans ce cas ? Bah vérifiez
    > vous même en vous attribuant l’identifiant 0×00

    Le code de contrôle sera différent car il est calculé
    à partir de beaucoup d’autres paramètres spécifiques
    au votant. Donc les votes de tous ceux qui auront forcé
    le nombre pseudo-aléatoire à zéro seront toujours bien
    distincts.

    En résumé, aujourd’hui vous n’avez montré aucun problème
    dans le système.

    Vous auriez pu attendre le dépouillement pour vérifier
    vos théories, et éventuellement exposer les problèmes
    du vote en ligne.

    Mais c’est vrai que le parti pirate n’a jamais hésité
    à déformer la vérité pour s’attirer un peu d’attention
    médiatique.

  6. Fenn
    juin 11th, 2012 @ 11 h 38 min

    @sam280:

    N’est-ce pas quelque part le devoir de tout citoyen qui en a la possibilité de pointer du doigt les soucis potentiels d’un système impliqué dans le processus démocratique ?

    Aucun problème ? Pour moi en terme de sécurité informatique, le fait même de pouvoir envoyer des inputs imprévus sans que le système se plaigne est un problème. « Never trust user input », règle de base.

    Je ne vois là aucune déformation de vérité, juste une exposition de faits et de conjectures. Et pourquoi devoir attendre pour alerter ? Ne vaut-il pas mieux chercher à prévenir un problème potentiel plutôt que de devoir se mordre les doigts plus tard devant un problème avéré et exploité ?

  7. Laurent
    juin 11th, 2012 @ 12 h 20 min

    @Alban G: Certainement, ça tombe bien, ce n’est pas ce que l’on a voulu faire et/ou démontrer ici. L’objectif de ces tests est de voir comment réagit le serveur de vote en modifiant certaines valeurs émises par le client, pas de voter à plusieurs reprise (mais le test serait intéressant à faire, soit dit en passant… on ne sait jamais!)

    @sam280:

    > En effet on verra, donc pour l’instant vous n’avez rien
    > démontré.

    Effectivement, nous n’avons rien « démontré », la seule vrai démonstration c’est quand on obtiendra 99,99% pour un parti :) C’est juste un faisceau de coincidences qui commencent à peser un peu lourd. Libre à chacun d’interpréter les résultats de ces expériences comme il l’entend. Si vous voulez avoir une confiance aveugle dans ces systèmes de vote, libre à vous.

    > D’ailleurs si je vais mettre dans l’urne
    > un bulletin papier sur lequel j’ai écrit votre nom,
    > mon vote sera bien enregistré.

    Ce n’est pas tout à fait la même chose ici. Ce qui à été démontré, c’est qu’il y a bien une validation fonctionnelle si la modification est effectuée *avant* l’étape de validation, mais cette étape de validation n’est pas présente *après*. Ce qui signifie que le serveur accepte gentiment comme valide un vote qui ne l’est pas. On peut toujours considérer que si « bug » il y a, il devra résulter en un vote blanc, mais cela ne dédouane pas le système de la présence du bug.

    Le fait de ne pas avoir prévu cette étape de validation fonctionnelle sur le contenu du vote au niveau du serveur est du point de vue d’un informaticien une faute *grave*.

    Ce qui est étrange ici, c’est que cette validation est prévue à un certain point du processus, mais pas aux autres: en gros on a barricadé la porte d’entrée en laissant celle de la cuisine ouverte, car on considère que laisser la maison ouverte ce n’est pas « si grave que ça ». Pourquoi alors avoir fermé la porte d’entrée?

    D’autre part, l’analogie avec un vote papier serait de vous laisser voter sans avoir inséré d’enveloppe dans l’urne, ou avec une enveloppe non reglémentaire ou déchirée: pas de cohérence fonctionnelle sur la procédure de vote. On peut toujours arguer que cela n’a pas d’importance (la personne aura voté blanc au final), j’imagine que l’on ne vous laissera pas le faire avec le vote papier.

    > Le code de contrôle sera différent car il est calculé
    > à partir de beaucoup d’autres paramètres spécifiques
    > au votant. Donc les votes de tous ceux qui auront forcé
    > le nombre pseudo-aléatoire à zéro seront toujours bien
    > distincts.

    Qu’en savez-vous? Avez-vous consulté le code source du programme de vote sur le serveur?

    Ce que vous dites est d’ailleurs techniquement erroné:
    1) Si le code généré (AAAAAAAAAA) provient d’une somme de contrôle de l’identifiant de bulletin (0) et d’autre valeurs, alors on n’obtiendrais pas ce AAAAAAAAAA (je ne crois pas aux coincidences dans un espace de taille 26^10)
    2) Un mécanisme de prévention des collisions peut-être effectué sur le serveur, mais cette procédure ne peut pas se limiter à l’ajout d’entropie dans la fonction de transformation, car quelque-soit la quantité ajoutée on ne préviendra pas les collisions, dont la probabilité ne dépend que de la taille de l’ensemble d’arrivée (ID généré), pas de celle de l’ensemble de départ. Donc si il y a mécanisme de prévention des collisions, cela se fait sans aucun doute par un mécanisme identique à celui d’une table de hachage (http://en.wikipedia.org/wiki/Hash_table#Collision_resolution) — procédure d’ailleurs beaucoup plus simple que l’ajout d’entropie dans les données de départ.

    > Vous auriez pu attendre le dépouillement pour vérifier
    > vos théories, et éventuellement exposer les problèmes
    > du vote en ligne.

    Non, dans ce cas il vaut mieux publier les résultats dès que possible, car il est encore temps de procéder à des tests complémentaires tant que le vote par internet est encore ouvert. Si on attend la publication des résultats il sera trop tard pour procéder à d’autres vérifications.

    > Mais c’est vrai que le parti pirate n’a jamais hésité
    > à déformer la vérité pour s’attirer un peu d’attention
    > médiatique.

    L’article expose simplement une expérimentation technique. Et je ne suis pas certain que ce soit le parti pirate qui déforme le plus la réalité dans cette histoire… Eux ont au moins l’honnêteté intellectuelle de publier leurs expériences avec la procédure utilisé et les résultats obtenus, contrairement à d’autres dont je ne citerais pas le nom, qui s’abritent derrière le « secret industriel » et la « compétence » de gens aux titres pompeux pour rassurer tout le monde.

    Libre à chacun de juger.

  8. Paul
    juin 11th, 2012 @ 13 h 46 min

    @sam280 : Parti Pirate ? Où ça le Parti Pirate ?

    Ici on parle de doutes sérieux en constatant qu’en face rien n’est fait pour nous rassurer. Comme le dit Laurent, si tu préfères regarder ailleurs grand bien t’en fasse, je préfère gueuler trop fort que me taire s’il y a une couille dans le paté…

  9. sam280
    juin 11th, 2012 @ 20 h 22 min

    @Fenn:

    > N’est-ce pas quelque part le devoir de tout citoyen qui en
    > a la possibilité de pointer du doigt les soucis potentiels
    > d’un système impliqué dans le processus démocratique ?

    Vous semblez accorder beaucoup d’importance à un prétendu devoir
    moral et bien peu à la Loi. Nous verrons ce que l’Etat pense
    de quelqu’un qui fait des test aléatoires sur un système de
    vote lors d’une élection nationale.

    > Aucun problème ? Pour moi en terme de sécurité informatique,
    > le fait même de pouvoir envoyer des inputs imprévus sans
    > que le système se plaigne est un problème.

    Comment savez-vous que le serveur ne s’est pas « plaint » à un
    administrateur du système ?

    > Je ne vois là aucune déformation de vérité, juste une exposition
    > de faits et de conjectures.

    Laurent semble d’accord avec moi que son expérience n’a encore
    rien démontré, or l’article titre « c’est pire au second tour » et
    conclue sur « …comment le ministère va justifier l’injustifiable »
    .
    J’ai vu mieux comme exposé objectif de faits.

    @Laurent:
    > Si vous voulez avoir une confiance aveugle dans ces systèmes
    > de vote, libre à vous.

    Intéressant. Donc soit on est entièrement d’accord avec vous,
    soit on a une confiance aveugle dans le système, c’est ça ?

    > Ce qui à été démontré, c’est qu’il y a bien une validation
    > fonctionnelle si la modification est effectuée *avant*
    > l’étape de validation, mais cette étape de validation
    > n’est pas présente *après*.

    Obtenir un reçu pour un vote nul ne prouve en aucun cas que
    vous avez eu un impact sur le comptage, qui est au final la
    seule chose qui importe.

    > Qu’en savez-vous? Avez-vous consulté le code source
    > du programme de vote sur le serveur?

    Justement, un état plus courageux que la France a forcé
    Scytl a publié le code source
    de leur serveur de vote.
    Une simple recherche google vous aurait évité beaucoup
    de suppositions.

    > Ce que vous dites est d’ailleurs techniquement erroné:

    Vous n’avez pas compris, je parle du code de contrôle et pas
    de l’identifiant du reçu. Lisez le code servant à créer
    le reçu et vous verrez de quoi je parle.

    > Non, dans ce cas il vaut mieux publier les résultats
    > dès que possible, car il est encore temps de procéder
    > à des tests complémentaires tant que le vote par internet

    En l’occurrrence vous n’avez aucun résultat, uniquement des
    suppositions. En publiant maintenant vous avez donné
    l’opportunité aux administrateurs du système de dissimuler
    leurs erreurs avant le dépouillement.

  10. Laurent
    juin 12th, 2012 @ 15 h 36 min

    @sam280:

    > Vous semblez accorder beaucoup d’importance à un prétendu devoir
    > moral et bien peu à la Loi. Nous verrons ce que l’Etat pense
    > de quelqu’un qui fait des test aléatoires sur un système de
    > vote lors d’une élection nationale.

    La morale peut très bien se situer au dessus de la « Loi »… Vaste débat, mais on s’éloigne du sujet.

    En tout cas je veux bien que vous me citiez une loi qui m’empêche de générer mon propre identifiant de bulletin. Le code qui génère celui-ci fonctionne sur mon ordinateur, il utilise en standard le générateur de nombre aléatoire basé sur une source d’évèvenements physiques qui provient de mon système d’exploitation. Or je fait fonctionner le système d’exploitation que je souhaite sur mon ordinateur, donc modifier /dev/random pour ne retourner que des zéros est « légal » il me semble. Il n’y a pas (encore) de loi qui m’interdise cela.

    > Comment savez-vous que le serveur ne s’est pas « plaint » à un
    > administrateur du système ?

    Soyons sérieux. En gros on aurait laissé une faille ouverte pour le plaisir de lire des messages d’alertes dans les logs?

    D’autant plus que le système est « sous scellé », donc la seule chose que l’administrateur puisse faire, c’est regarder les dégâts :)

    > Donc soit on est entièrement d’accord avec vous,
    > soit on a une confiance aveugle dans le système, c’est ça ?

    Non, ce n’est pas ce que je dit. Ce que j’affirme, c’est que soit on se donne les moyens de vérifier le système, soit on base sa confiance sur un audit de quelques personnes fait en quelques jours. Pour moi c’est une confiance aveugle.

    > Justement, un état plus courageux que la France a forcé
    > Scytl a publié le code source de leur serveur de vote.
    > Une simple recherche google vous aurait évité beaucoup
    > de suppositions.

    Vous parlez du serveur CVS public « norvégien »? Paul Da Silva en parlait dans un post d’il y a quelques semaines. J’avais téléchargé le code source en février. Le problème c’est que ce code est assez vieux et n’est probablement pas le même que celui utilisé pour ces élections, et que l’environnement de vote n’est pas le même (ils utilisent des ordinateurs de votes a-priori sécurisés avec un système d’identification de l’électeur basé sur une smart-card, et les électeurs sont des élus et peu nombreux). Ce qui semble d’ailleurs un peu plus sérieux que le système français.

    Mais si vous souhaitez faire un audit basé sur ce code pour rassurer tout le monde, n’hésitez pas.

    > En l’occurrrence vous n’avez aucun résultat, uniquement des
    > suppositions. En publiant maintenant vous avez donné
    > l’opportunité aux administrateurs du système de dissimuler
    > leurs erreurs avant le dépouillement.

    Impossible, le système est sous scellé. Si les administrateurs font cela, c’est un aveu d’échec: comment peut-on garantir le vote si pendant le dépouillement un technicien fait quelques « update » en base pour arriver à un compte rond? C’est de la démocratie « SQL » :)

  11. sam280
    juin 12th, 2012 @ 22 h 44 min

    @Laurent:
    > donc modifier /dev/random pour ne retourner que des zéros
    > est « légal » il me semble. Il n’y a pas (encore) de loi
    > qui m’interdise cela.

    En l’occurrence vous n’avez pas modifié du code de votre OS
    mais bien de l’application de vote. Mais c’est un détail,
    et le problème porte sur le vote que vous avez effectué
    pour ce candidat imaginaire. Je ne suis pas avocat, mais
    ça pourrait éventuellement tomber dans le cadre de l’article
    L.116 du Code électoral: http://is.gd/kcvVrR

    > Soyons sérieux. En gros on aurait laissé une faille ouverte
    > pour le plaisir de lire des messages d’alertes dans les logs?

    Encore une fois, il n’y a de faille que si vous avez influencé
    le résultat du vote, ce que nous ne saurons qu’au dépouillement.

    > Le problème c’est que ce code est assez vieux et n’est

    Le code publié a été utilisé pour une élection en Norvège en 2011,
    ça n’est pas vieux pour un système de ce genre.

    > probablement pas le même que celui utilisé pour ces élections,

    Pourquoi « probablement » ? La première partie du code de contrôle
    est une valeur binaire en base64 de 256 bits qui correspond
    justement à la taille d’un hash SHA-256, comme dans le code publié.

    Mais pour le prouver définitivement il vous suffirait de publier

    le reçu de quelqu’un qui a injecté le même code que vous.
    Est-ce que personne n’a reproduit votre expérience ?

    > Mais si vous souhaitez faire un audit basé sur ce code pour
    > rassurer tout le monde, n’hésitez pas.

    C’est là notre différence. Je ne cherche à rassurer personne,
    j’essaie simplement de rester objectif. Et objectivement, il
    faut encore attendre pour savoir si vous avez raison.

    Au contraire, Paul et vous avez affolé tout le monde sans
    connaitre le résultat de votre expérience.

    > Impossible, le système est sous scellé.

    Tiens, vous avez « une confiance aveugle » dans cette partie
    du système ? :)

  12. Erwann
    juin 18th, 2012 @ 14 h 47 min

    PC Inpact rapport un bug de décompte avec une différence de 1 voie :
    http://www.pcinpact.com/news/71719-vote-electronique-bug-benelux.htm
    S’agit-il de la même circonscription ?

  13. Wmd
    juin 18th, 2012 @ 15 h 05 min

    Héhé, suspense XD …

  14. Paul
    juin 18th, 2012 @ 15 h 52 min

    Oui c’est bien là et oui je pense que ça vient de là… On attend que le système de reçu de votes pour le second tour soit mis en ligne pour vérifier :)

  15. Laurent
    juin 18th, 2012 @ 17 h 36 min

    Tiens tiens… une différence de 1 vous dites? Comme c’est étrange…

  16. ..Où l’on reparle du vote par internet… « Ligue des droits de l'homme
    juin 19th, 2012 @ 6 h 51 min

    [...] l’a accepté sans rechigner”, poursuit-il. Cette démarche avait été expliquée en détails par le blogueur Paul Da Silva dès le premier [...]

  17. sam280
    juin 19th, 2012 @ 23 h 12 min

    @Laurent:
    Au vu des informations récentes, j’en conclus que:
    – vous aviez raison sur le premier point : le back office de Scytl ne supporte pas les votes nuls au second tour, ce qui est clairement un bug. C’est d’autant plus triste que la possibilité de manipuler cet identifiant leur avait apparemment déja été rapportée en 2008 (cf http://www.eecs.berkeley.edu/~daw/papers/scytl-odbp.pdf paragraphe 4.2.1.2).

    – la collision des identifiants de reçus et leur impact éventuel sur le vote n’ont pu être vérifiés faute de second test. Si ce second test avait été mené, je suis convaincu qu’on aurait bien vu une collision des identifiants mais pas du code de contrôle (comme décrit non seulement dans le code publié mais aussi dans tous les documents techniques et les patents de Scytl). Néanmoins il aurait été intéressant de voir le comportement du back office dans cette éventualité.

    Rendez-vous dans 5 ans :)

  18. Laurent
    juin 20th, 2012 @ 14 h 04 min

    @sam280

    > vous aviez raison sur le premier point : le back
    > office de Scytl ne supporte pas les votes nuls
    > au second tour, ce qui est clairement un bug.

    C’est d’autant plus grave que lors du décompte le serveur de production et le serveur de backup n’ont pas retourné le même résultat à cause de ce bug, et que les deux résultats sont erronés. Je ne comprend pas pourquoi ce test de validité fonctionnel n’a pas été mis en place, il est pourtant très simple a implémenter.

    > C’est d’autant plus triste que la possibilité
    > de manipuler cet identifiant leur avait
    > apparemment déja été rapportée en 2008 (cf
    > http://www.eecs.berkeley.edu/~daw/papers/scytl-odbp.pdf
    > paragraphe 4.2.1.2).

    Très intéressant. Effectivement, et la réponse officielle de Scytl selon le document est la suivante:

    « 4.3.4.3 Finding: The voting client will accept bogus election identifiers
    We acknowledge this finding, but the potential vulnerabilities associated to it are prevented by other security measures, such as using VPNs that prevent Voting Laptops to connect to any fake Voting Server. »

    Dans le contexte de cette élection la réponse de Scytl est un hors-sujet (pas de VPN, ordinateur électeur non sécurisé). Il serait intéressant de consulter le rapport de l’audit de sécurité pour savoir si cette faille avait été (re-)détectée.

    > Si ce second test avait été mené, je suis convaincu
    > qu’on aurait bien vu une collision des identifiants
    > mais pas du code de contrôle

    On aurait même pu avoir pire: écrasement de bulletin si l’identifiant de reçu est utilisé comme clé en base. C’est effectivement dommage que ce second test n’a pas été effectué. J’ai personnellement la même conviction.

    > Rendez-vous dans 5 ans :)

    Étant donné le fiasco à tous points de vue de cette « expérimentation », je n’espère pas. Souhaitons que dans le futur un vrai débat émerge enfin, et que l’on ne nous impose pas à nouveau cela. Les conséquences pourrait être bien pire.

  19. Laurent
    juin 20th, 2012 @ 14 h 38 min

    @sam280: Ce papier est une mine d’or.

    Un exemple parmi d’autre: la possibilité de modifier le code au niveau du client avait été pointé du doigt:

    « 4.1.2.1 Finding: The Voting Client relies on software that is downloaded across the network at run-time, and only stored in volatile memory.
    As described in finding 4.2.2.3, the voting kiosk downloads a Java application from the Voting Server at the start of the election, and it is this software that is then executed to implement the voting functionality on the voting kiosk. As this software is only stored in volatile memory on the voting kiosk, **it is difficult to determine what software was actually used during an election**. For instance, it is difficult to verify whether the software that was executed matches the version that was certified by the State of Florida, and there may be no way to check whether malicious code was introduced. The ability to perform such an audit is a desireable property for an election system, and the current software architecture does not easily enable such an audit to be performed. »
    [...]
    « Action: Include the Java Application on the Live CD and use that static version to run the election, **rather than relying on code downloaded over the network.** »

    (Emphasis are mine)

    Leur préconisation est bien sûr difficile à réaliser dans le cadre de ces élections (même si l’envoi d’un CD auto-amorçable contenant un système complet et le code client du vote aurait été envisageable), mais cet audit de 2008 confirme bien ce qui à été dit. Et c’est autrement plus sérieux que celui effectué par l’administration: il a duré 3 mois, piloté par 6 véritables experts indépendants (universitaires, etc…). Pourtant, même avec cette durée, ils estiment que leur audit ne saurait être complet et ne représente qu’une « petite partie » d’un audit complet:

    « Thus, our review was not chartered, and is not intended, to provide comprehensive analysis; rather, it focuses on security issues from a software perspective as part of the overall certification process. »

Leave a Reply





Edito

Ancien journaliste, ancien entrepreneur, ancien (ir)responsable Pirate, actuel citoyen qui s'intéresse à la politique et à son évolution.

Read moar !.

Retrouvez moi sur :

Suivez moi sur twitter sur facebook sur wikipedia Ajouter ce blog a votre lecteur RSS

Bitcoin

bitcoin logo Paul da Silva Bitcoin
1AyR34kffA5tMGBKgHDsmhSQUFVvMmx38C

Piratons la démocratie

piratons la democratie

One more thing !

0100 0011 0110 1000 0110 0001 0110 1110 0110 0111 0110 0101 0111 0010 0010 0000 0110 1100 0110 0101 0010 0000 0110 1101 0110 1111 0110 1110 0110 0100 0110 0101 0010 0000 0110 0101 0110 1110 0010 0000 0111 0011 0010 0111 0110 0001 0110 1101 0111 0101 0111 0011 0110 0001 0110 1110 0111 0100 0010 0000 0010 1101 0010 0000 0110 1111 0110 1110 0010 0000 0111 0110 0110 0001 0010 0000 0110 0010 0110 1111 0110 1001 0111 0010 0110 0101 0010 0000 0111 0101 0110 1110 0010 0000 0110 0011 0110 1111 0111 0101 0111 0000 0010 0000 0011 1111

Tm9uIGNlbGVsIGzgIGVzdCBqdXN0ZSBwb3VyIHRlIGZhaXJlIHBlcmRyZSA1bW4gOyk=

Sentimancho