Je vais être méchant, mais l’article n’est que du technobabeul completement a cote de la plaque. Les problèmes de securite que l’on rencontre avec les machines a vote sont des problèmes humain (comment s’assurer que la machine n’a pas ete trafique) et non pas des problèmes informatique (y a t’il un bug dans le programme).

Je pourrais tout autant être méchant et vous demandez si vous savez lire ... A votre question à savoir comment s’assurer que la machine n’a pas été trafiquée, la réponse est : c’est impossible que ce soit de façon formelle ou non ! Un cheval de Troie (ensemble dont les canaux cachés font partie), pour votre gouverne, n’est aucunement un bug mais un programme introduit intentionnellement dans l’intention de nuire.

Parler de CIA, c’est gentil, mais quel est l’interet ? Une machine a vote, c’est juste une pauvre suite de compteurs. Ajouter un systeme de droit d’acces est le meilleur moyen de complexifier le système et donc d’y inserer des bugs. KISS (Keep It Simple Stupid) est une des règles d’or de la securite.

Vous avez une vision très restrainte des machines conçues sur les bases des technologies électroniques (heu !!! comment sont manipulés vos compteurs ; l’opération du saint esprit  ?) ! Ce sont des données manipulées selon un processus technique bien défini. Passage obligatoire par des registres, gestion par pile aussi bien du système que du processus en fonctionnement, chargement en mémoire aussi bien des programmes que des données, stockage, interruptions, ... Vous connaissez vraiment comment fonctionne un ordinateur ou une machine quelconque conçue sur ce qui s’appelle l’électronique. Un exemple simple : comment votre machine à voter sait-elle qu’un citoyen a appuyé sur le bouton de son choix ? Donc qu’elle doit traiter la demande de prise en charge d’un vote. Comment sait-elle que la personne qui vote a le droit de le faire ? Comment limite-t-elle le nombre de votes à un par personne ?

Idem pour les preuves formelles. La majorite des failles sont du soit a une erreur d’implementation, soit a une erreur de configuration ou soit a de mauvaises hypothèses. Hors les preuves formelles ne peuvent rien contre ceci. Au mieux, les preuves prouvent qu’il n’y a pas d’erreur dans les theoremes. Mais si les hypotheses sont fausses, et bin, prouver que le theoreme est juste, ca ne sert pas a grand chose.

Les preuves formelles permettent d’empêcher les erreurs d’implémentaition ; sauf si vous êtes capable de me démontrer que vous pouvez faire travailler un ordinateur sur autre chose que des fonctions mathématiques.

Mais, la ou j’ai envie de donner des claques, c’est quand je lit : « L’élément principal étant que la confiance que les utilisateurs ont en la sécurité du système informatique qu’ils utilisent doit être sans faille. »

Je vous renvoie aux textes de base de la sécurité des systèmes du Département de la Défense américaine (DOD) et les critères d’évaluation européen dont les références sont associés au texte. La recherche de confiance consiste à mettre aussi bien des contrôles techniques que non techniques ; il me semble que c’est ce qui est exprimé.

Il est hors de question de creer des systemes de securite fiable a 100% tout au long de la chaine pour une question de couts. La securite n’est qu’une question d’equilibre. Faire croire que l’on fournit un systeme sure a 100% est une preuve d’incompétence.

Le but de ces normes consiste à insister sur le fait que tout ne pouvant être traité techniquement, il faut mettre des contrôles administratifs, du personnel, ... pour tenter de conforter une certaine confiance qui ne peut en aucun être totale.

Il est super-important de savoir comment le systeme peut deconner pour mettre en place des contre-mesures. Un des gros probleme de la securite est que l’utilisateur est trop confiant. Alors rajouter une couche pour le rendre encore plus confiant, c’est n’importe quoi.

Ce n’est pas du tout ce qui est écrit non plus. Savoir comment un système peut déconner ne limite pas les risques ; les contre mesures sont généralement inefficaces ; cela consiste à mettre en œuvre un système de trace qui, en fonction d’une suite d’opérations atomiques d’un même sujet, le système détectera une agression. Ce système est facilement contournable par l’éclatement d’un processus dont chaque partie (sujets différents) prend en charge une action atomique.

Je conseil a l’auteur, de relire ses livres d’introduction a la securite informatique et en particulier Secret and Lies de Bruce Schneier et Security Engeeniring de Ross Anderson.

Si je puis me permettre, je vous conseillerai plutôt la lecture de Fondements Théoriques de la Sécurité Informatique. CERT, Rapport final, 3/3407.00/DERI, 1991 de P. Bieber, F. Cuppens et G.Eizenberg.

Bizzarement, ces deux livres prennent les systemes de votes comme cas d’ecole ou l’un des systemes est un exemple de securite et ou l’autre est le parfait example de ce qu’il ne faut pas faire. Bien sure, dans leur discussion, ils ne parlent jamais de probleme informatique (Je rappelle que le probleme avec les machines a vote n’est pas d’ordre informatique mais avant tous d’ordre humain).

Bien sûr, il est préférable d’éviter de parler des problèmes informatiques en posant l’hypothèse que le système de vote qui est considéré comme un cas d’école n’est fait d’aucun composant électronique. Il n’existe aucun cas d’école en matière de sécurité informatique dû principalement aux problèmes liés à la sécurité matériel ; c’est la nature des travaux de Gasser : d’autres problèmes se posent pour des utilisateurs connaissant les fonctionnements internes d’un ordinateur. Pour traiter ce type de problème, il faut tenir compte des mécanismes de sécurité matériels (exposés dans Building a Secure Computer System : Computers Acces Control and System Design. Van Nostrand Reinhold, 1988.)

Je me permets donc de douter de l’un des systemes est un exemple de securite ; ce qui, au niveau de la recherche est irréaliste sauf à poser des hypothèses irréalistes.