Signaler un abus

Tout d’abord merci pour vos réponses.

Voici quelques clarifications.

Tout d’abord, je ne suis pas du style à avoir ouvertement peur des nouvelles technologies. Je ne suis pas contre le nucléaires, je suis en la faveur des OGM (avec des réserves mais cela pourrait être le sujet d’un prochain article) et en général j’adopte rapidement toute nouvelle invention que je juge utile.

Autre remarque : Je ne suis pas dans l’opposition. Je suis de droite, tendence libérale.

Premiere remarque à laquelle je souhaite réagir : C’est la même chose à chaque nouvelle technologie. Je répondrai FAUX. Personne n’a intérêt à ce qu’une centrale nucléaire pête en France. Tout le monde va donc faire en sorte de l’éviter. De même pour les OGM : Si les gens crévent, Monsanto sera enmerdé et devra rendre des comptes. Les seules personnes qui peuvent y avoir intérêt sont des terroristes. Dans le cas du vote, tous les candidats peuvent potentiellement avoir un intérêt à la triche. Certains voudront avoir 5% pour rembourser leurs frais de campagnes. D’autres voudront gagner. Et c’est la le problème. Dans un cas, on veut construire un avion pour qu’il vole sans s’écraser, dans l’autre cas on veut construire un avion pour qu’il vole sans s’écraser même si on lui tire des missiles dessus.

Seconde remarque à laquelle je souhaite réagir : La démocratie directe. Vous êtes nombreux à l’avoir évoquée. Effectivement le fait de pouvoir voter plus souvent (et sur plus de sujets) peut être un argument en faveur du e-vote. On pourrait tout d’abord penser qu’il serait raisonable de conserver les scrutins importants (présidentielles, législatives) sous leur forme classique et faire des scrutins éléctroniques sur les choses secondaires. La difficulté c’est ou fixer la limite. Auriez vous été heureux que le référendum sur l’Europe soit conduit de façon éléctronique ? Quid d’un référendum sur la Davdsi ? Pour chacun d’entre nous, il y a une liste de sujets qui nous tienne à coeur. Et il ne revient pas à l’état de décider qui aura droit à un scrutin équitable et qui aura droit à un scrutin avec un fort risque de fraude.

Pour ne pas sombrer dans un exemple trop « caricatural » (pouvoir de l’argent) imaginons un référendum sur le droit à l’avortement. Ce sujet mobilisera sans nul doute toute la population que l’on soit pour ou contre. C’est un sujet qui ne laisse en général pas indifférent et génére des débats passionnés. Les constructeurs de la machine étant des hommes, il n’y couperont pas. Imaginons que le scrutin soit serré. Celui qui est pour l’avortement ne voudra pas que le pays retourne dans l’obscurantisme et sera tenté de faire une fraude pour la bonne cause. Celui qui est contre l’avortement voudra mettre fin aux « meurtres » et il sera tenté de frauder en se disant également que c’est pour la bonne cause. Le pire est que ces deux personnes auraient toutes deux l’impression d’avoir commis un acte juste. Il se dédouaneront même en se disant que de toute façon les gens auraient votés du bon coté.

Troisiéme remarque : Distribution de numéros à l’entrée des bureaux de votes. Bravo pour l’idée ! Sauf qu’il faut garantir qu’aucune machine à voter ne peut recevoir de l’extérieur une commande contenant les affectations. Imaginons que la machine vous authentifie par carte à puce. Alors il suffit d’avoir prévu une carte à puce spéciale contenant les affectations. Un élécteur va « voter » avec cette carte le matin du scrutin et le tour est joué. Cela peut aussi être une combinaison de touches sur la machine. Il y a deux boutons : Parfait, on va pouvoir faire encoder de l’information en binaire par l’électeur ! Un seul bouton ? Codons en morse ! Tout périphérique d’entrée du système permet potentiellement de l’instruire. Et donc votre argument n’est pas valable !

Quatriéme remarque : Accès aux sources et certifications ! Je suis un fervent défenseur du logiciel libre. Et pourtant je n’irai jamais dire que les source suffisent à prouver une application. On a trouvé des bugs dans tous les logiciels libres parfois des années aprés leur introduction. Et pourtant des chercheurs en sécurité passent leur temps à cela. Un bug ca peut passer inapperçu.

Vous confondez également certification et tests. Tester une application avec une batterie de test est effectivement nécéssaire. Mais cela n’est jamais suffisant. Microsoft posséde en interne un trés bon système de test. C’est également le cas de Dassault Systèmes. Tous les éditeurs consacrent plus de la moitié de leur budget développement aux tests de leurs produits. Pourtant ni Windows ni Catia ne sont sans bugs bien au contraire.

Enfin vous ignorez qu’en informatique, il n’y a qu’une différence ténue (d’ordre technique) entre du code et de l’information. Vous pouvez par exemple tout à fait cacher (cela s’appelle de la stéganographie) un petit morceau de code dans une image (le fond d’écran de la machine à voter). L’image apparaitra non modifiée à l’oeil. Ce code n’aura alors qu’à être recopié par exemple dans le segment de pile (en prenant pour partie qu’il y a des segments de données non exécutables sur la machine à voter et que le segment de pile le soit). Il pourra alors être lancé de façon trés discrete ! Sans être jamais appelé depuis le code original. Suffit d’y laisser un bug dit buffer overflow pour pouvoir modifier l’adresse de retour sur le segment de pile et le tour est joué. Vous allez me répondre que le segment de pile peut être rendu non exécutable. Je vous répondrez qu’aucune des protections de ce type n’ont empéchées l’exploitation de buffer overflows. Elles ont juste rendu l’exploitation de ce type de failles moins triviales. Et bien il y a de bonne chances que ce genre d’entourloupes passe au travers de toute revue de code, même effectuée par des ingénieurs trés qualifiés.

La encore ce n’est qu’un scénario donné pour l’exemple. Si vous cherchez bien il y a des tonnes de moyens de fournir une injection de code discrête. Une version originale peut d’ailleurs constituer en l’insertion du code magique dans le firmware d’une des cartes de la machine à voter. Le cas du Bios serait bien trop « obvious » (encore que). Suffit alors d’insérer dans le code du noyeau un morceau de code a priori anodin qui va lire ce firmware et un autre morceau de code bien plus loin qui en fait bon usage. Vu l’usage immodéré des pointeurs sur fonctions qui est fait dans le code du kernel, je vous laisse tout à fait le soin de trouver cela lors d’une revue de code. Et la vous avez une application, un compilo, un os certifié mais ... vous avez oublié le firmware de la carte vidéo.

Voila c’est fini. Merci encore à tous pour vos réponses. J’espére avoir convaincu le maximum d’entre vous.