Blockchain et vote électronique

Il faut se méfier des cadres présents qui nous feraient penser qu’une nouvelle technologie ne marcherait jamais pour une application donnée [1]. Le passé nous as en effet souvent donné tort. A contrario, les limites de ces nouvelles technologies ne sont pas imaginaires et les nier, comme le feraient certains, est une attitude de croyant aux antipodes d’une démarche scientifique prudente qui pourrait nous protéger des dérives potentielles que toute technique sans cadre peux entraîner.

La blockchain est une technologie informatique conçue pour garantir l’inscription de données de façon immuables, sans intermédiaires, accessibles à tous, en offrant une garantie d’authenticité. C’est donc le support idéal pour les crypto-monnaies telles que le Bitcoin ou Ethereum. Les limites de cette technologie existent cependant : impact environnemental, anonymat non garanti, résilience incertaine au déchiffrage… La révolution de la blockchain est incontestable, mais lui attribuer toutes les vertus serait aussi absurde que de nier l’impact disruptif de cette technologie.

Je vois beaucoup de blockchain-idolâtres clamer partout que cette technologie va permettre de faire du vote électronique dématérialisé, anonyme, et vérifiable (donc sécurisé). L’affirmer aujourd’hui revient hélas à nier le principe de réalité.

  • D’abord l’anonymat n’existe pas dans la blockchain. Il est obtenu en utilisant un pseudonyme. Ce n’est pas – à mon sens – précisément la technique de la blockchain qui permet de garantir l’anonymat. Pour être plus précis, les organisateurs du vote doivent créer un système qui lie les identités de chacun aux adresses bitcoin ou autre. C’est donc là qu’est la faiblesse. Nous ne sommes donc pas dans une anonymisation mais dans une pseudonymisation.
  • Les travaux de recherche ont démontré que tout vote dématérialisé anonyme est intrinsèquement invérifiable. La blockchain ne peut échapper à cette réalité scientifique qui n’a jamais été infirmée. Les travaux de Chevalier-Mames et al. ont en effet abouti à démontrer pourquoi il y a incompatibilité formelle entre la vérifiabilité des votes dématérialisés et l’anonymat [2].
  • Comme tout système de vote par procuration, la blockchain, n’a pas de moyens de convaincre un électeur de la sincérité des opérations. Cela introduit un doute dans le résultat de l’élection qui sape l’autorité des personnes élues.
  • Même parée de toutes les vertus, la blockchain ne constitue qu’une partie de la chaîne de traitement. Si l’on considérait son usage comme fiable et vérifiable, cela ne protégerait quand même pas les autres maillons du processus (comme le poste client en vote par internet qui peut être attaqué par des chevaux de Troie de type man-in-the-browser tel Zeus qui peuvent même modifier l’interface utilisateur à la volée).
  • Enfin, et c’est le plus problématique, la blochain porte intrinsèquement le danger majeur de révélation du contenu intégral des votes le jour où l’un de ses protocoles de chiffrement est cassé, car elle est conçue pour rester publique à long terme. Or, les experts en sécurité informatiques savent que toute implémentation de protocole sera très certainement cassé un jour. La vraie question est : quand l’implémentation sera-t-elle cassée ? Or, comme il n’y a pas de possibilité de revenir en arrière une fois la blockchain écrite, les données sont donc à la merci d’une future faille. Avez-vous vraiment envie de prendre le risque que vos votes soient révélés un jour ? Même dans 10 ans ?

[1] Les oracles malchanceux sont nombreux. En voici quelques exemples savoureux:

  • « Internet ? On s’en fout, ça ne marchera jamais ! ! » Pascal Nègre, PDG d’Universal – 2001
  • « Il n’y a aucune chance pour que l’Iphone obtienne des parts de marché significatives. Aucune chance. » – Steeve Balmer, PDG de Microsoft – 2007
  • « Théoriquement, la télévision est possible, mais je la considère comme une impossibilité – une percée à laquelle nous ne devrions pas perdre de temps à rêver. » – Lee de Forest, inventeur du tube cathodique, 1926
  • « Je crois qu’il y a un marché mondial pour peut-être cinq ordinateurs. »  – Thomas J. Watson, président du conseil d’administration d’IBM, 1943
  • « Nous ne fabriquerons jamais un système d’exploitation à 32 bits. » – Bill Gates, fondateur de Microsoft, 1983
  • « Je prédis qu’Internet… sera une supernova et qu’en 1996, il s’effondrera de façon catastrophique. » – Bob Metcalfe, fondateur de 3Com, 1995
  • « Les tablettes informatiques sont inutiles car sont ni des vrais smartphones, ni des vrais ordinateurs. Elles disparaîtront d’ici 3 ans. » Hervé Suaudeau, dans son salon, 2010.

[2] Benoît Chevallier-Mames, Pierre-Alain Fouque, David Pointcheval, Julien Stern et Jacques Traoré. On some incompatible properties of voting schemes. Towards Trustworthy Elections, 6000 :191–199, 2010.

  • Bien que la démonstration de leur théorème soit difficile d’accès pour un non spécialiste, la conclusion de l’article scientifique est sans appel (traduction personnelle) : « En conclusion, nous avons montré que les systèmes de vote ayant les caractéristiques habituelles ne peuvent pas vérifier les notions de sécurité fortes toutes en même temps : nous ne
    pouvons pas parvenir simultanément à la vérifiabilité universelle (vérifier même le calcul du décompte par les autorités) du décompte des voix et à la confidentialité inconditionnelle des votes ou à la ‘receipt-freeness’ » (l’absence de preuve de son vote protège l’électeur contre la coercition).

Passer son site en HTTPS

Auteur Sean MacEntee (CC-BY-2.0)

Avoir un site en HTTPS est un gage de confidentialité et de meilleure indexation. Peu de choses semblent justifier aujourd’hui de ne pas mettre en place votre site web en https (et désactiver le http).

Je profite donc d’avoir terminé la migration en HTTPS des 13 noms de domaines que j’auto-héberge pour écrire ce petit mémo.

Les exemples utilisés dans cet article seront adaptés à un serveur Debian avec Apache.

Installation d’un certificat HTTPS avec Let’s encrypt

Droits nécessaires: droits root sur le serveur d’hébergement

Let’s encypt est une autorité de certification mise en place par projet porté par l’Electronic Frontier Foundation, Mozilla et d’autres partenaire privés qui veulent généraliser l’usage de connexions sécurisées sur l’internet.  Elle permet d’avoir gratuitement un certificat HTTPS.

Pour ce lancer dans cette étape il faut avoir déjà un site fonctionnel en HTTP.

Ensuite on peut utiliser l’outil très puissant de l’EFF, Certbot. Voici comment l’installer et le lancer pour un serveur apache :

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto
mv certbot-auto /mon_dossier/mes_scripts/
sudo /mon_dossier/mes_scripts/certbot-auto --apache

Durant l’installation, indiquer les options par défaut et autoriser certbot à modifier votre configuration apache et de rediriger le trafic http vers https.

On termine en configurant la tache de renouvellement automatique:

sudo crontab -e
0 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && /mon_dossier/mes_scripts/certbot-auto renew

Migrez tout vos liens en HTTPS

Droits nécessaires: webmaster

Sur votre site, remplacez tous les liens http que vous avez en https.

Sur WordPress il faut intervenir à plusieurs endroits:

  • Modifier l’adresse de votre site dans la page de réglages généraux (menu Réglages→Généraux)
  • Mettre à jour tous les liens de vos anciens articles (notamment les images). Vous pouvez utiliser un plugin Search Regex pour automatiser tout cela.
  • Éventuellement vous devrez intervenir en rééditant vos widget, corriger des liens dans vos menus, et (plus rare) dans le code de votre thème si vous avez rajouté des liens manuellement.

Vous devez avoir un cadenas vert en affichant votre site, ce qui signifie que tout vos éléments sont passés en https:

Si vous n’avez pas ce cadenas vert:

vous pouvez rechercher les éléments manquants en vous aidant par exemple avec le site WhyNoPadlock.

Accélérez le HTTPS

Droits nécessaires: droits root sur le serveur d’hébergement

L’agrafage OCSP permet d’éviter aux navigateurs de faire une requête supplémentaire vers l’autorité de certification. Voici comment le mettre en place:
echo 'SSLStaplingCache shmcb:/tmp/stapling_cache(2097152)' >> /etc/apache2/conf-available/ssl.conf
a2enconf ssl

et ajouter la ligne suivante dans le fichier /etc/letsencrypt/options-ssl-apache.conf :
SSLUseStapling on

Testez et améliorez la sécurité de votre certificat

Le site de Qualys SSL Labs SslTest est excellent pour tester la sécurité de vos certificats.

N’utiliser que des protocoles fiables

Droits nécessaires: droits root sur le serveur d’hébergement ou par défaut droit d’écriture sur le vhost d’apache

Pour améliorer la note au SslTest, il faut modifier les lignes suivantes du fichier /etc/letsencrypt/options-ssl-apache.conf :

SSLProtocol all -SSLv2 -SSLv3 -TLSv1
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:!DSS

Publier votre autorité de certification

Droits nécessaires: droits de configuration du DNS de votre nom de domaine

Il faut aussi graver dans le marbre de votre DNS le fait que ce soit Let’s Encrypt qui vous procure le certificat. Voici l’entrée DNS à rajouter dans votre interface de configuration de votre registraire de nom de domaine :

example.org. CAA 128 issue "letsencrypt.org"

Le 128 (valeur maximale possible) signifie que le certificat est impératif.

Activer HSTS

Droits nécessaires: droits root sur le serveur d’hébergement ou droit d’écriture sur le vhost d’apache

Enfin il vous faut configurer les headers http en rajoutant ces lignes dans votre fichier de configuration virtual host d’apache:
#Activer HSTS pour le site et les sous-domaines pendant 1 an (pour HTTPS)
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

Puis il faudra soumettre votre site sur https://hstspreload.org/ afin d’empêcher totalement l’accès non https.

Pourquoi ce blog?

J’ai crée ce blog afin de le distinguer de mes autres blogs afin que mes engagements politiques ne perturbent pas les causeries techniques de ce nouveau blog.

Certes, la politique est toujours présente, car je ne me priverais pas de remettre en cause certaines technologies et leurs conséquences sur notre société, et le faire est profondément un acte politique, mais il fallait distinguer les engagements partisans de mes connaissances techniques afin de ne pas risque de parasiter l’argumentation.