Broken by Design

Debunkage de la vidéo sur les mots de passe de Fabien Olicard : mémorabilité, densité et entropie irréconciliables ?

Sun, 03 May 2026 11:40:00 +0200

Alors que les mots de passe deviennent toujours plus longs et complexes à retenir d’une part, et que les attaques informatiques augmentent en intensité d’autre part, nous voyons encore en 2026 des débats autour des méthodes sur la composition d’un mot de passe.

En avril 2026, Fabien Olicard, lancé dans le défi de publier une vidéo courte par jour pendant un an, a publié une vidéo intitulée “Votre Mot de Passe est Nul (mais j’ai la solution)”. Dans sa vidéo, il donne des conseils sur la composition d’un mot de passe, dont l’impact en sécurité informatique est très dommageable. Nous détaillerons pourquoi dans cet article (et qui sait, cela lui donnera peut-être un sujet pour une prochaine vidéo 😅).

Plus inquiétant/intéressant encore, dans la section commentaires, de nombreuses personnes mentionnaient des techniques de composition de mots de passe de leur cru. Une qui est ressortie particulièrement est d’utiliser une phrase complète telle que “J’ai mangé 3 croissants le jour de mon mariage”. L’argumentaire des personnes proférant ce conseil est qu’une longue phrase en toutes lettres rend les attaques par recherche exhaustive (c’est-à-dire d’essayer toutes les combinaisons de mots/caractères possibles) extrêmement longue.

Florilège :

Je suis désolé d’invalider ton propos mais je pense que, partant de ta phrase perso, le mieux est de la prendre telle quelle, donc “J ai mangé 3 croissant le jour de mon mariage”, avec ou sans les espaces, en y ajoutant un caractère spécial, afin de respecter cette exigence de la plupart des sites nécessitant un mot de passe.

Perso, je mets des phrases random généralement et en entier XD

oui, lune phrase longue est un meilleur mot de passe qu’un mdp court avec caractère spéciaux… le problème, c’est que tout les sites ne permettent pas de le faire

On peut aussi choisir une phrase d’un livre que l’on aime particulièrement, dans un chapitre précis , dans un passage de ce livre, passage que l’on aime particulièrement…

Tu m’es simple la phrase t’elle qu’elle sans les espaces.Tu à tout la majuscule le chiffre et c’est incracable

S’en est suivi un débat auquel j’ai participé et que je souhaiterais reprendre ici, loin de la censure de Youtube qui supprime assez arbitrairement des commentaires. Ma position est que toute structure dans un mot de passe nuit à sa qualité. Nous définirons et détaillerons cette affirmation dans le corps de l’article.

Recommandations institutionnelles

Les institutions françaises publient des recommandations concernant les mots de passe.

Ainsi, la CNIL publie des recommandations et un évaluateur de la sécurité des mots de passe. De manière intéressante, les recommandations de la CNIL ont évolué vers le mieux en 2022, celles publiées en 2017 présentant de vrais problèmes pour la sécurité des usagers.

De son côté, l’ANSSI publie un guide de recommandations relatives à l’authentification multifacteur et aux mots de passe. Par transparence, précisons que l’auteur du présent article a participé à son élaboration.

La recommandation de Fabien Olicard

Synthèse de la vidéo

Dans sa vidéo courte, Fabien nous propose d’utiliser les lettres initiales de chaque mot d’une phrase personnelle, avec quelques modifications additionnelles. Ainsi, la phrase “J’ai mangé 3 croissants le jour de mon mariage” est transformée en “Jam3cljdmm”. Ensuite, il propose de rajouter un caractère spécial à intervalle régulier, par exemple tous les 6 caractères. Il suggère ici le tiret, ce qui donne “Jam3cl-jdmm”. Enfin, il suffixe au mot de passe un “abrégé” du site pour lequel ce mot de passe est destiné. En guise d’exemple, il propose “Nfx” pour Netflix. Le suffixe ne contient jamais de caractères spéciaux rajoutés ; il est donc préfixé du caractère spécial. Ainsi, le mot de passe Netflix serait “Jam3cl-jdmm-Nfx”.

En points positifs, Fabien indique bien de préférer une phrase personnelle à une phrase bien connue, comme une citation. En effet, une citation connue, ou un extrait de livre auraient une forte probabilité d’être la source d’inspiration de nombreuses personnes, qui se retrouveraient alors avec un mot de passe quasi identique et “public”. Fabien suggère également qu’il est nécessaire d’utiliser des mots de passe distincts par site, ce qui est une bonne pratique de sécurité.

Analysons maintenant pourquoi la recommandation de Fabien est problématique.

Analyse critique

Pour comprendre les problèmes de la recommandation de Fabien, il faut d’abord comprendre comment sont généralement stockés les mots de passe par les sites web, et comment ils sont attaqués.

Pour s’authentifier, on envoie généralement son mot de passe au site web (il existe des manières de s’authentifier où ce n’est pas le cas).

sequenceDiagram
actor you as Vous
actor website as Site Web

you ->> website: Envoie du mot de passe
website ->> website: Dérive le mot de passe
website ->> website: Vérifie le dérivé avec celui stocké en base de données
alt Les dérivés correspondent
    website ->> you: Vous donne accès
else
    website ->> you: Rejette la connexion
end

Ce mot de passe n’est pas comparé directement avec le mot de passe que nous avons envoyé lors de notre inscription sur le site web. En effet, pour limiter les risques en cas de compromission du site web, ce dernier stocke les mots de passe fournis à l’inscription sous une forme dérivée. Cette dérivation se produit en utilisant des algorithmes spécialement conçus pour le stockage de mots de passe.

Pour vérifier le mot de passe qu’on envoie lorsqu’on veut se connecter à un site web, ce dernier va appliquer un algorithme de dérivation sur le mot de passe envoyé. Le résultat de cet algorithme, appelé dérivé, est ensuite comparé avec le dérivé stocké dans sa base de données, lors de l’inscription.

Si les deux dérivés sont identiques, alors bingo ! Nous avons prouvé notre connaissance du mot de passe, et donc notre identité au site web !

Si le site web venait à être compromis, l’attaquant·e n’obtiendrait que les dérivés des mots de passe stockés en base de données. Les algorithmes de dérivation de mots de passe sont conçus spécifiquement pour qu’il soit très difficile pour un·e attaquant·e de retrouver le mot de passe à partir du dérivé. L’attaquant·e ne peut qu’essayer de retrouver le mot de passe à partir du dérivé en générant des mots de passe, en les dérivant, et en comparant ces dérivés avec les dérivés récupérés lors du piratage. On appelle cela l’attaque par force brute, bruteforce, ou par recherche exhaustive.

Nous en savons maintenant assez pour comprendre quelques-uns des problèmes de la recommandation de Fabien.

Fabien propose d’utiliser un mot de passe “Jam3cl-jdmm” suffixé d’un abrégé désignant le site web sur lequel ce mot de passe est utilisé. Dans l’exemple “-Nfx”. Si l’utilisateur·rice utilise aussi Amazon Prime, le suffixe sera, par exemple, “-AmzP” et son mot de passe sera “Jam3cl-jdmm-AmzP”.

Ainsi, les suffixes “-Nfx” et “-AmzP” jouent le rôle de diversificateurs. L’essentiel du mot de passe reste cependant identique !

Imaginons maintenant que le site d’Amazon Prime contienne un bug, et qu’il n’utilise pas d’algorithmes de dérivation de mots de passe. À la place, il stocke directement le mot de passe de l’utilisateur·rice dans la base de données. Si celle-ci est piratée, ou qu’Amazon est malveillant, l’attaquant·e pourra voir que le mot de passe de Fabien sur Amazon Prime est “Jam3cl-jdmm-AmzP” ! L’effort mental pour imaginer que pour Netflix, le suffixe est “-Nfx” est minimal. L’attaquant·e ou Amazon pourront alors facilement deviner que le mot de passe pour Netflix est “Jam3cl-jdmm-Nfx” et pirater le compte Netflix de Fabien ! 😱

Ce constat est déjà très problématique en soi. Il revient à utiliser quasiment le même mot de passe partout, ce qui est décrié depuis des années par toutes les personnes vaguement compétentes pour parler du sujet.
Certaines personnes l’ont d’ailleurs présenti dans les commentaires :

Excellente l’idée de rajouter le sigle du site à la fin. Cela permet de réutiliser la phrase.
Mais en cas de soucis ou doute, il faudra changer touts les mots de passe…🙄

Les problèmes de la recommandation de Fabien vont cependant plus loin. Les mots de passe ainsi construits ont une structure. Le sujet de la structure est complexe, et nombre des commentateur·rices ne l’ont pas saisi ; c’est ce qui a motivé l’écriture du présent article.

Le problème de la structure des mots de passe

Commençons par acquérir une intuition du problème que représente la structure. Nous pourrons ensuite généraliser et formaliser le propos.

Biais statistique de la lettre initiale

En vulgarisant, on pourrait dire qu’en français, plus de mots commencent par un D que par un Z. Plus formellement, on dirait que les mots français ne sont pas uniformément distribués en 26 catégories correspondant à la lettre initiale de chaque mot.
En prenant le dictionnaire libre aspell, on peut calculer le graphique suivant, avec la commande :

for i in {a..z} ; do aspell -d /usr/lib64/aspell-0.60/francais-lrg.alias dump master | grep -c "^$i" ; done

xychart
    title "Répartition des mots dans le dictionnaire par leur lettre initiale"
    x-axis "Lettres initiales" [A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z]
    y-axis "Nombre de mots" 0 --> 70000
    bar [ 25187, 15642, 35126, 65442, 21728, 12855, 10470, 6147, 12059, 11801, 537, 69161, 53765, 59390, 5441, 27644, 55430, 37415, 36184, 53545, 1038, 7307, 190, 63, 94, 800 ]

Le mot de passe de Fabien “Jam3cl-jdmm” est composé des lettres initiales des mots présents dans la phrase personnelle “J’ai mangé 3 croissants le jour de mon mariage.” Certaines lettres ont donc statistiquement beaucoup plus de chances d’apparaitre que d’autres dans un mot de passe fabriqué en suivant la technique de Fabien.
Lorsque l’attaquant·e essaie de trouver le mot de passe d’une personne, il pourra donc mener sa recherche en essayant d’abord avec les lettres les plus fréquentes, afin d’accélérer sa recherche et trouver plus vite le mot de passe !

Il convient de noter que ce problème existe également si l’on compose ses mots de passe avec la méthode dite syllabique, où le mot de passe est élaboré à partir d’une phrase décomposée en phonèmes (par exemple, “J’ai” devient la lettre “G” par proximité phonologique). La méthode syllabique était conseillée, à tort, par la CNIL en 2017.

Biais statistiques liés à la structure de la phrase

La fréquence des initiales n’est pas le seul biais de ce type lié à la structure du mot de passe. En français, la plupart des phrases sont construites sous la forme SVO : sujet, verbe, objet. En généralisant, la plupart des langues possèdent une syntaxe propre ne permettant pas d’ordonner les mots de manière arbitraire.

💡 En contre-exemple, l’Esperanto utilise le suffixe -n pour marquer l’accusatif. Ainsi, “amikoj” désigne le sujet de la phrase et “amikojn” porte la marque de l’accusatif et est donc l’actant ou le complément d’objet direct, quelle que soit sa position dans la phrase. Ces trois phrases (“J’ai des amis.”) sont syntaxiquement identiques : “Mi havas amikojn. Amikojn mi havas. Mi amikojn havas.” Pour être complet, l’ordre des composants de la phrase pourra traduire une intention d’attirer spécifiquement l’attention sur l’une des informations de la phrase.

La syntaxe d’une langue permet de concevoir des chaines de Markov. Il s’agit d’un outil mathématique permettant, par exemple, de déterminer quels sont les mots les plus probables suivant un autre mot. Si cela vous évoque les grands modèles de langage (LLM), ce n’est pas un hasard.

Mais pour en revenir à nos moutons, intuitivement, on peut se dire qu’après l’article “la”, nous ne trouverons pas en français correct de mots commençant par une voyelle.

Lorsqu’un·e attaquant·e tentera de retrouver un mot de passe consistant en une phrase en langage naturel (comme le français), il pourra donc intégrer ces informations pour tester en premier les combinaisons probables, et donc accélérer sa recherche. En effet, les attaquant·es ne limitent pas leur recherche des mots de passe à la seule technique par recherche exhaustive bête et méchante : a, b, …, aa, bb, …, aaa, bbb, … Les outils modernes de “cassage de mots de passe” sont parfaitement capables d’utiliser des techniques variées, incluant la recherche de mots dans les dictionnaires, les chaines de Markov, des masques, et bien d’autres.

Ce biais affecte directement la méthode de Fabien pour fabriquer un mot de passe, puisque les lettres sont des initiales de mots. Pour chaque lettre du mot de passe, même sans connaitre le mot qui lui est associé, on peut prendre la liste des mots commençant par cette lettre. Ensuite, on peut calculer quels mots sont les plus probables après chacun de ces mots. Enfin, on calcule la lettre initiale la plus commune parmi ces derniers. Cela permet à l’attaquant·e d’optimiser sa recherche exhaustive !

Mais on peut généraliser ce biais et faire la déclaration que certain·es trouvent excessive : toute structure induit un biais réduisant l’entropie ou la densité.

Structure, entropie et densité

Définition de l’entropie et de la densité

L’entropie est un terme du technolecte informatique lié à la théorie de l’information de Shannon. Ce terme est souvent mécompris. Nous commencerons par en apporter une définition afin de faciliter la lecture du reste de l’article.

L’entropie désigne la quantité d’information dans une donnée. La quantité d’information désigne l’incertitude de ce que sera une information compte tenu des informations précédemment connues.

Intuitivement, la donnée représentant le mot de passe aaaaaa contient relativement peu d’informations, si ce mot de passe est construit exclusivement en répétant six fois la lettre a. Au mieux, on peut avoir deux informations : le nombre de lettres et la lettre répétée. Les mêmes deux informations auraient pu être communiquées de manière plus dense en écrivant 6a.

Il convient également de tordre le cou à une croyance bien ancrée, et qui se trouve être également très populaire chez les personnes œuvrant en informatique. Il n’est pas possible de déterminer l’entropie en observant une donnée !

Ainsi, 999999 pourrait tout à fait contenir plus d’entropie que hjf3U&àSD/r-. Pour comprendre cela, il faut comprendre comment est calculée l’entropie. Une définition formelle est disponible sur Wikipedia. Intuitivement, il faut comprendre que ce qui compte n’est pas tant l’aspect de la donnée que le degré d’incertitude de chaque élément composant la donnée.

Le mot de passe hjf3U&àSD/r- semble complexe, et il a probablement été généré en tirant 12 caractères aléatoirement, avec des minuscules, des majuscules, des chiffres et des caractères spéciaux. L’ensemble des minuscules (26 éléments), majuscules (26 éléments), chiffres (10 éléments) et caractères spéciaux (disons une quarantaine) signifie que chaque caractère a une chance sur 92 (26 + 26 + 10 + 40) d’être sélectionné comme le prochain caractère du mot de passe. Répété 12 fois, on obtient 92¹² combinaisons possibles (367666387654882241806336 ou environ 3,68 * 10²³ ). Cela correspond à log2(92¹² ) ≈ 78 bits d’entropie.

Comparativement, le mot de passe 999999 semble être un chiffre répété six fois. Cependant, il se pourrait aussi qu’il s’agisse du nombre tiré aléatoirement entre zéro et 2¹²⁸ . Ou même de 6 nombres concaténés et constitués de un chiffre chacun, tirés entre 0 et 2¹²⁸ ! Dans le premier cas, l’entropie serait de moins de 20 bits. Dans le second, l’entropie serait de 128 bits, soit nettement supérieure aux 78 bits de hjf3U&àSD/r-. Dans le dernier cas, l’entropie serait même de 768 bits ! 🤯

Il résulte de cet argumentaire que tout “calculateur d’entropie” où l’on saisit son mot de passe pour qu’il en fasse une analyse statistique d’uniformité est irrémédiablement incorrect, puisqu’il repose sur ce qui est observable dans le mot de passe et non sur l’analyse de sa méthode de fabrication ! Cette erreur est également présente sur des gestionnaires/générateurs de mots de passe, comme KeePassXC qui calcule l’entropie d’un mot de passe en fonction des caractères le composant plutôt qu’en fonction du nombre de caractères le composant ET de la taille de l’ensemble des caractères possibles pour chacun d’entre eux ! 😭

Les mots de passe fonction de l’aléa

Dans la section précédente de cet article, l’entropie a été mesurée en bits. Ce n’est pas un hasard ; cette unité est liée à la génération de secrets en cryptographie.

En cryptographie, un nombre aléatoire doit disposer de deux propriétés : dans sa représentation binaire, chaque bit (c’est-à-dire chaque 0 ou 1 qui le compose) doit être indépendant et la distribution doit être uniforme.

L’uniformité d’une représentation binaire signifie que chaque bit composant un nombre aléatoire avait autant de chance d’être un 0 qu’un 1. Intuitivement, c’est comme de faire un pile ou face avec une pièce non truquée.

L’indépendance signifie qu’aucun des bits ne doit être en mesure d’influencer la probabilité qu’un ou plusieurs bits suivants soient un 0 ou un 1. Intuitivement, c’est comme de dire que chaque lancer de pile ou face ne peut pas influencer le résultat des futurs lancers. Par exemple, 01010101 est parfaitement uniforme (il y a autant de zéros et de uns), mais il semblerait bien que ce soit une alternance de zéros et de uns. Si cette séquence est le pur fruit du hasard, alors parfait ! Si, par contre, lors de la génération, cette séquence alternée de zéros et de uns était délibérée, alors les bits ne sont pas indépendants ! On touche à nouveau du doigt les biais et l’intentionnalité dans l’algorithme de fabrication du mot de passe.

Pour éviter les biais, une méthode est de demander à une machine de nous générer un mot de passe. Pour cela, cette dernière utilise un générateur de bits aléatoires, afin de générer N bits d’entropie.

Une fois ces bits générés, ils sont consommés par une fonction, que nous appellerons T, afin de transformer cet aléa en mot de passe. La fonction T peut être tout et n’importe quoi, mais le principe général est de consommer une partie des bits encore non consommés pour choisir aléatoirement le prochain “composant” d’un mot de passe.

Par exemple, admettons que les bits aléatoires générés par la machine soient les suivants (regroupés en groupes de six bits pour des raisons qui deviendront évidentes dans quelques lignes) :

101010 101000 111000 101101

Admettons ensuite que le mot de passe que l’on cherche à générer est un mot de passe composé de caractères alphanumériques et de quelques caractères spéciaux. L’ensemble des caractères pouvant constituer un mot de passe sont au nombre de 64 et sont les suivants :

a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 - _

Chaque groupe de 6 bits représente un nombre entre 0 et 63 en base 2 (c’est-à-dire en binaire). Ainsi, 101010 représente le nombre 42. On prend donc le 43e caractère (42 + 1, le +1 étant parce qu’on commence à compter à partir de 0) parmi la liste de caractères précédemment listés.

En répétant cet algorithme, on obtient ainsi :

Bits aléatoires	Caractère du mot de passe
101010	Q
101000	O
111000	4
101101	T

Le mot de passe généré est donc QO4T et contient autant d’entropie que le nombre de bits générés précédemment : 4 groupes de 6 bits, soit 24 bits.

Dans cet exemple, la fonction T est donc de consommer les bits, six par six, pour tirer un caractère aléatoire dans une liste de 64 caractères distincts. On aurait pu imaginer une fonction T_bis où l’on consomme les bits quatre par quatre et où l’on répète alternativement la lettre A ou la lettre B un nombre de fois égal au nombre formé en base 2 par ces groupes de 4 bits ! Cela donnerait :

1010 1010 1000 1110 0010 1101

Bits aléatoires	Séries de A ou de B
1010	AAAAAAAAAA
1010	BBBBBBBBBB
1000	AAAAAAAA
1110	BBBBBBBBBBBBBB
0010	AA
1101	BBBBBBBBBBBBB

Le mot de passe serait alors AAAAAAAAAABBBBBBBBBBAAAAAAAABBBBBBBBBBBBBBAABBBBBBBBBBBBB. Bien qu’il soit nettement plus long (c’est-à-dire moins dense) que QO4T, il contient la même quantité d’entropie : 24 bits.

Un attaquant qui voudrait casser ce mot de passe aurait à deviner 25 bits d’entropie : 24 bits aléatoires et si c’est la fonction T ou la fonction T_bis qui a été utilisée. Il a une chance sur deux de tenter la fonction T et une chance sur deux de tenter la fonction T_bis , ce qui représente donc une incertitude de 1 bit.

On peut imaginer encore d’autres fonctions T :

choisir un mot aléatoirement dans un dictionnaire (si le dictionnaire contient 8192 mots, alors on consomme les bits treize par treize) comme le fait Bitwarden ;
choisir un smiley aléatoire dans une liste de smileys ;
choisir aléatoirement un phonème dans une langue (s’il y a 36 phonèmes dans une langue, alors on consomme les bits 6 par 6, car 2⁵ < 36 < 2⁶ ) comme le fait Apple ;
choisir aléatoire un livre dans sa bibliothèque, choisir aléatoirement une page, choisir aléatoirement un paragraphe dans la page, choisir aléatoirement un mot dans le paragraphe et recommencer jusqu’à avoir consommé tous les bits d’entropie ;
choisir un chemin de neurones pseudo-aléatoire déterministe pour fabriquer une phrase dans un langage naturel, comme peuvent le faire les LLM…

Contrairement à ce que l’on pourrait croire intuitivement, l’existence de nombreuses fonctions T n’est pas un frein majeur pour un attaquant. Si nous pouvons imaginer 1024 fonctions T distinctes, cela n’augmente l’entropie que de 10 bits (car log2(1024) = 10).

Et pire : il existe un nouveau biais dans ces 10 bits si la fonction T est choisie par un humain en fonction de ses préférences et sa capacité à se souvenir du résultat de la fonction T ! Gageons que AAAAAAAAAABBBBBBBBBBAAAAAAAABBBBBBBBBBBBBBAABBBBBBBBBBBBB est moins facilement mémorisable que QO4T et que peu de personnes préfèreront la fonction T_bis .

Pour maintenant généraliser et formaliser ces conclusions, les fonctions T sont des bijections entre :

un domaine de départ composé de nombres ou bits aléatoires ;
un domaine d’arrivée composé de symboles (caractères, mots, phonèmes, etc.) ayant pour but d’être plus aisément mémorisables par un humain.

S’agissant de bijections, la fonction T est inversible (T^-1 ), ce qui signifie qu’en connaissant le fonctionnement de la fonction T et en observant le résultat d’une fonction T, on peut retrouver les bits aléatoires ayant servis à fabriquer ce résultat.

On peut donc formaliser que l’objectif d’un·e attaquant·e est de retrouver les bits aléatoires ayant servis à fabriquer le mot de passe, quelle que soit sa représentation humainement mémorisable et quelle que soit la fonction T appliquée. Avec un mot de passe de 24 bits d’entropie et une fonction T connue, il faudra 2²⁴ (≈ 16 millions) tentatives à l’attaquant pour le trouver avec une probabilité de 1 (100%).

Le compromis entre entropie, densité et mémorabilité

Dans sa recommandation de 2022, la CNIL définit un seuil minimal d’entropie de 80 bits pour un mot de passe utilisé comme seul moyen d’identification. Cette recommandation est adressée sans spécifier de méthode de fabrication du mot de passe spécifique. Le choix de la fonction T est donc libre.

En reprenant les exemples précédents, on peut calculer la longueur des mots de passe comme suit dans ce tableau.

Taille de l’ensemble dans lequel sélectionner aléatoirement des éléments	Complexité du mot de passe	Entropie
un ensemble de 64 caractères (alphanumériques + caractères spéciaux )	14 caractères	≈ 84 bits
un dictionnaire de 7776	7 mots	≈ 83 bits
un ensemble de 36 phonèmes	16 phonèmes	≈ 83 bits

On peut observer que la densité est très variable, pour une même entropie.

Alors qu’utiliser des caractères aléatoires représente 14 caractères à taper au clavier lors de l’authentification, taper des mots du dictionnaire représente 55 caractères, les mots faisant en moyenne 7 caractères, avec un caractère séparant les 7 mots (7 * 7 + 6). Sachant que la frappe de ces 55 caractères se fait généralement à l’aveugle, la moindre faute de frappe coute un temps considérable ! D’un autre côté, se souvenir de 14 caractères aléatoires sans aucun sens peut représenter un défi insurmontable pour la plupart des utilisateur·rices !

Certain·es pourraient être alors tenté·es, comme suggéré par Fabien, d’utiliser des mots ou des phrases ayant un sens personnel particulier. Mais est-ce que 7 mots choisis par un humain contiennent bien 80 bits d’entropie ?!

La question n’est pas simple, car il n’est pas possible de connaitre la fonction T qui a été utilisée ; il faudrait faire une imagerie du cerveau de la personne pour comprendre, au moment de la création du mot de passe, par quel procédé elle a inventé ce mot de passe ! 🧑‍⚕️

Quand bien même, il est déjà possible de répondre à propos des phrases en langage naturel. En français, il existe presque 300 mots-outils, et leur occurrence dans un texte serait de l’ordre d’un tiers du texte ! Cela veut dire qu’un mot sur trois porte en lui au maximum 8 bits (log2(300) ≈ 8,23) contre presque 13 bits quand on choisit un mot dans le dictionnaire de 7776 mots évoqué plus haut (log2(7776) ≈ 12,92). Cela réduit donc drastiquement la densité : l’entropie de 2 mots du dictionnaire est supérieure à celle de 3 mots-outils. Il en résulte donc la nécessité de mots de passe plus longs que 55 caractères pour maintenir une même quantité d’entropie.

Outre les mots-outils, le français, comme toutes les langues, est structuré, comme expliqué plus haut dans cet article. Cela signifie que, dans une phrase syntaxiquement valide, le contexte détermine la nature des mots pouvant suivre ceux déjà sélectionnés, ce qui diminue encore la densité. Intuitivement “Je mange une pomme” est syntaxiquement correct et plus probable que “Mange je pomme une” qui est encore plus probable que “Rouge voiture conduit anticatastase”.

Ensuite, concernant la taille du vocabulaire actif d’un français adulte, les chiffres ne sont pas clairs, et beaucoup de faux chiffres semblent circuler. D’après une étude du département de psychologie expérimentale de Ghent, en Belgique, l’adulte moyen de 20 ans, natif des États-Unis d’Amérique, connait 42000 lemmes. Chaque lemme serait alors porteur d’environ 15 bits d’entropie (log2(42000) ≈ 15.36), en admettant qu’ils soient choisis de manière aléatoire. L’amélioration est marginale: 6 lemmes sont nécessaires pour atteindre 80 bits d’entropie, contre 7 avec le dictionnaire !

Reste à déterminer si un humain est capable de faire un choix réellement aléatoire (uniforme et indépendant) parmi ces 42000 lemmes. Comme le démontre très bien Fabien dans ses vidéos, l’humain est abominablement mauvais pour choisir quoi que ce soit aléatoirement. Les biais dans le choix “aléatoire” effectué par un humain viennent à nouveau réduire l’entropie, et incidemment réduire la densité si l’on veut garder le même niveau de sécurité. Il en résulte des mots de passe toujours plus longs 😱.

Conclusion

L’objectif d’un mot de passe est de fournir un moyen d’identification mémorisable par un humain. Dès lors que ce dernier ne peut plus être mémorisé, il doit être stocké dans un gestionnaire de secrets. Et dès qu’on utilise un gestionnaire de secrets, alors la longueur du mot de passe ou sa mémorabilité cessent d’être un sujet : la machine peut mémoriser des téraoctets de données sans broncher.

Simultanément, plus le mot de passe est facilement mémorisable, plus il est porteur de sémantique. Or, la structure du mot de passe et sa sémantique résultent en une sélection biaisée des constituants du mot de passe, et une diminution de la densité ou de l’entropie.

Il en résulte une tension insoluble :

un mot de passe à forte entropie peut être dense, mais il sera aussi peu mémorisable ;
un mot de passe mémorisable est soit peu dense, et donc peu utilisable en pratique, soit il n’est pas de bonne qualité, car ne comportant pas une entropie d’au moins 80 bits.

La méthode qui semble la plus propice à réduire cette tension est d’utiliser une série de mots indépendants et sélectionnés par la machine, et d’ensuite y donner du sens ou de les mémoriser tels quels par des méthodes comme celles promues par Fabien Olicard sur ses chaines Youtube (palais mental, etc.).

Le mot de passe est cependant appelé à disparaitre tôt ou tard, à mesure que la puissance de calcul des machines grandit et avec elle la capacité des attaquant·es à retrouver toujours plus vite les mots de passe. Des solutions existent (comme les passkeys) mais leur adoption par le grand public reste encore à améliorer.

Managing files over WebDAV with Terraform

Mon, 08 Dec 2025 00:00:00 +0000

A few weeks ago, I participated in a conversation on social media about the use of simple technologies like WebDAV instead of relying on modern and unreliable stuff like minio.

WebDAV is boring and it is not gonna change its license or become obsolete because some shareholders decided they want more, so everybody else is gonna have less. WebDAV is an Internet Standard implemented by Apache, nginx, Caddy and many others.

Unfortunately, modern DevOps tools prefer to play with modern tech. It is easy to publish a blob on a S3-like platform with infrastructure as code tools like Terraform, but you are out of luck if you want to push that same blob on a WebDAV server. Or at least, you WERE out of luck because I decided to follow through and develop a WebDAV Terraform provider on my free time! Hooray!

OpenTofu is not supported at the moment because I used features that are not yet in an OpenTofu stable version. As soon as v1.11 is out, I’ll seek compatibility.

Some of you may be wondering about these missing features. In short, OpenTofu < 1.11 misses ephemeral resources and write-only attributes. Those are very important features that enable secure-ish¹ secret handling in Terraform/OpenTofu. And because developing a Terraform provider with write-only attributes is a challenge, I decided to document the journey in this blog post.

But first, let’s talk about my use cases.

What Documents Could I Possibly Publish over WebDAV ?

WebDAV main current use case is CalDAV. Most people using an online calendar are probably synchronizing their events over WebDAV without ever knowing it.

In the infrastructure that I have developed, I like to use WebDAV because it relies on mTLS for authentication. Transferring files over SSH/SFTP is fine as long as you are able to authenticate the SSH server. Unfortunately, this is rarely done. Most Terraform providers I audited are silently skipping the host key verification, allowing free meddle-in-the-middle (MITM) attacks and making the connection as secure as using Telnet… This is why I developed the SSH2VSOCK Terraform provider, which leverages the implicit trust you have in the hypervisor to access a guest VM over SSH without needing to verify the SSH host key. Unfortunately, this provider only works when using a (compatible) hypervisor. When using a bare metal server or an incompatible hypervisor, SSH host key verification remains a challenge.

Meanwhile, secure TLS certificate deployment to authenticate servers (and clients) is trivial thanks to the ACME protocol. Once the certificates are provisioned, tools like Terraform can safely connect to a WebDAV server over HTTPS, authenticate using their client certificate, and manage file over a secure channel.

Using this secure channel, I can push configuration files like ignition configuration that are later served over HTTPS to Fedora CoreOS booting instances. I can also push shared secrets to several instances and avoid using centralized online secret managers, which carry their own risks. This is a topic I discussed at length in a podcast episode (in French, but the transcript is available if you want to use a translator on it).

Secret Handling in Terraform

Handling secret in Terraform used to be a very bad practice. Terraform is a state machine, and a state machine is based on… you guessed it: a state. And that state is stored in clear text². OpenTofu implemented client-side encryption, using a passphrase, but the idea is cursed because it means anybody knowing the password can learn all secrets stored in the state. If you want to fragment the knowledge, you have to fragment the workspace as well.

Hashicorp (employees and community members) came up with a really smart solution to this issue: the ephemeral resources and the write-only attributes.

Ephemeral resources have a different lifecycle from standard resources. They are created (opened) with every execution (plan or apply) and destroyed (closed) immediately after the execution. Thus, they are not persisted in the state. Write-only attributes can be assigned ephemeral values generated by the ephemeral resources. These attributes are NOT stored in state. Putting all of this together means you can generate a password with an ephemeral resource and assign it to a write-only attribute, without it ever getting stored in the state.

As such, Terraform can become a secret generator and distribution center without ever becoming a single point of failure.

Developing a Terraform resource with some write-only attributes

Write-only attributes are weird.

When developing a resource, one implements the usual CRUD operations: Create, Read, Update and Destroy. Which of these functions is called depends on the plan. The called function receives the planned values as arguments. It then proceeds in making the intended changes. It is pretty straight forward.

With write-only attributes, things change: the plan only contains null values for the write-only attributes. This is due to the fact that write-only attributes can receive ephemeral values. These values can be different with every invocation of Terraform. Building a plan containing values for these attributes would not make sense, since these values might be different during the apply phase.

To implement CRUD operations on resources containing write-only resources, you will need to get values both from the plan and from the configuration.

Now the problem is that your resources won’t have any changes during the planning phase if the only thing that changes is a value assigned to a write-only attribute. The reason for this is that your plan is computed by comparing the state and the planned changes. Except your planned changes will contain a null value for your write-only attributes, and so will the state these write-only attributes…. So since nothing has changed, there is nothing to do. Thank you very much.

Don’t even think about adding a standard plan modifier like RequireReplace(): the value did not change! It is still null, so there is nothing to replace!

Terraform documentation contains some “best practices” to implement write-only attributes. The main advice is to pair up your write-only attributes with some standard read-write attributes (like a version number or a keeper), or use some resource private state.

Keepers and version numbers are exposed to the practitioners, which effectively means that we transfer on them the burden of deciding when to replace the resource.

So I first attempted to rely exclusively on a private state and it somewhat worked until it did not.

Using a private state

First off, let’s clarify that the private state is not private in the sense that it is confidential. The private state is still part of the state that is sent in clear text to the state storage backend. Private only means that the content is not spilled in front of the practitioners’ eyes and they cannot modify it directly. As such, storing the content of a write-only attribute configuration value in the private state effectively negates the very thing that makes write-only attributes usable as a security feature. If you are a security auditor, you should check that the developers did not do that…

The private state can be used to store a value derived from the write-only value. For instance, a cryptographic digest of the value assigned to the write-only attribute. When a new value is assigned, you can implement a custom plan modification function that will hash the new value and compare it with the digest stored in the private state. If the digest changes, it means the resource was updated and the resource needs to be updated/replaced.

This may be acceptable, considering a cryptographic hash function is a one-way operation and learning the content of the private state is not supposed to yield information on the hashed data.

And if you thought I was making any sense: gotcha. Yes, a cryptographic hash function is a one-way operation, but it is a deterministic one. As such, if a value is assigned to two resource instances, one won’t be able to know the assigned value just by looking at the state, but one will be able to learn that it was the same value that was assigned to those two resource instances. That may be an undesired property. Also, if the assigned value is a low-to-medium entropy password, one could try and brute force the password value from the digest.

As a consequence there is no universal answer here: depending on the content that may be assigned to the write-only attribute, you may want to hash the value with a “simple” cryptographic hash function, like SHA-512, or with a function that was built to derive passwords, like Argon2ID.

In the case of the WebDAV provider I developed, I chose to expose to the practitioners a write-only attribute for the content of the managed files. Doing so helps prevent the state from being bloated with large file contents. It also helps prevent the storage of sensitive values in the state if the file contains stuff like passwords.

To detect changes, I stored a digest in the private state and implemented a custom plan modification function. The practitioners can inform the provider if the content of the file contains sensitive values by specifying a hash salt. If no salt is not specified, the stored digest is computed with SHA-512. If a salt is specified, a SHA-512 digest is computed over the file content; it is then hex-encoded and used as input for the Argon2ID hash function with the salt value. Using this “weird” combination of SHA-512 + Argon2ID is just a way to avoid having to pass the whole file content to the Argon2ID function. This should not affect security, even if you believe hash shucking gives you any advantage.

As such, practitioners using my WebDAV provider can write stuff like:

terraform {
  required_providers {
    random = {
       source = "hashicorp/random"
    }
    remotefs = {
      source = "X-Cli/remotefs"
    }
  }
}

variable "mysecret" {
  type = string
  ephemeral = true
}

provider "remotefs" {
  webdav = {
    base_url = "YOUR_WEBDAV_SERVER_URL"
  }
}

resource "random_pet" "my-id" {
  length = 4
}

# Creates a /my-id file containing the random petname that was generated above
resource "remotefs_file" "davsecret" {
  path = "/my-id"
  inline_content = random_pet.my-id.id
}

resource "random_bytes" "salt" {
  length = 16
}

# Creates a /secret.txt file containing the secret specified as an ephemeral variable
resource "remotefs_file" "davsecret" {
  path = "/secret.txt"
  inline_content = var.mysecret
  hash_salt = random_bytes.salt.hex 
}

This ought to work… as long as you provide the same ephemeral value during the plan and the apply phases.

But as soon as you try to do the following, the provider will explode in flight:

terraform {
  required_providers {
    random = {
       source = "hashicorp/random"
    }
    remotefs = {
      source = "X-Cli/remotefs"
    }
  }
}

provider "remotefs" {
  webdav = {
    base_url = "YOUR_WEBDAV_SERVER_URL"
  }
}

ephemeral "random_password" "mysecret" {
  length = 16
}

resource "remotefs_file" "mysecret" {
  path = "/mysecret"
  inline_content = ephemeral.random_password.mysecret.result
}

This is because the ephemeral random_password resource will generate a different value during the plan phase, the apply phase and the post-apply non-refresh plan phase that ensure that the apply phase went as expected. So the solution exposed in this section of the blog post only works for values that are not generated using an ephemeral resource. That may be OK for you but I would love to be able to generate random passwords like in the previous example. So we need another mechanism!

Using keepers

Keepers are a notion introduced by the hashicorp/random provider. They consist of a map of values that have no ties with the business logic of the managed resource. Instead, the keepers are in control of the lifecycle of the managed resource: if the keeper map values change, the resource must be replaced.

Using keeper values, one can ignore the digest difference between the private state and the assigned value and instead rely entirely on the keeper value changes.

To support both workflows, I modified my custom plan modification function to skip the digest computation and comparison operations if the keeper attribute is not null, and I added a keeper attribute that has a plan modifier requiring resource replacement if it is updated. During the resource replacement, whatever the value that will be yielded by the ephemeral random_password resource during the apply phase will be used.

Here is a working example:

terraform {
  required_providers {
    random = {
       source = "hashicorp/random"
    }
    remotefs = {
      source = "X-Cli/remotefs"
    }
  }
}

variable "secret_version" {
  description = "Increase this value when the secrets need to be renewed"
  type = number
  default = 0
}

provider "remotefs" {
  webdav = {
    base_url = "YOUR_WEBDAV_SERVER_URL"
  }
}

ephemeral "random_password" "mysecret" {
  length = 16
}

resource "remotefs_file" "mysecret" {
  keepers = {
    secret_version = var.secret_version
  }
  path = "/mysecret"
  inline_content = ephemeral.random_password.mysecret.result
}

Conclusion

Write-only attributes are weird to implement because they require extra logic and stuff you probably never used before in the Terraform plugin framework. Nevertheless they are an essential part of the ongoing revolution that is secret management as part of the Terraform configuration.

Old farts like me, who enjoy publishing content thanks to reliable Internet standard protocols, can now do so with Terraform.

In the following weeks, I expect to publish an update for that provider to support the SFTP protocol in case you already have the material to check the SSH host key (known_hosts file or SSHFP DNS records).

Go has no efficient and universal way of zeroizing freed memory. So you need to rely on the kernel to do it for you. ↩︎
Server-side state encryption is just sending your state in clear text to a service provider and hoping that they will encrypt the state as they said they would. Also, let’s hope there are no early TLS channel terminations, like Cloudflare does. ↩︎

Expérimentation de Fedora CoreOS sur Proxmox : création de la machine virtuelle d'installation

Mon, 03 Jun 2024 00:00:00 +0200

Ce billet est le deuxième d’une série traitant de la création d’une infrastructure virtualisée à l’aide de Proxmox¹ pour la partie hyperviseur et de Fedora CoreOS² pour le système d’exploitation des machines virtuelles invitées (guests). L’infrastructure codifiée (Infrastructure as Code) est réalisée avec OpenTofu³ (Hashicorp Terraform ayant rejoint le côté obscur de la Force).

Dans le premier billet⁴, nous avons évoqué les raisons qui ont mené au choix de créer une machine virtuelle d’installation. Dans ce billet, nous allons voir une solution technique preuve de concept satisfaisant ce besoin. Le code source est publié en licence ouverte, afin que la communauté puisse en bénéficier ⁵.

L’objectif est ici d’installer une machine virtuelle (sur Proxmox) qui permettra d’en installer d’autres. La distribution Fedora CoreOS est utilisée pour ses atouts de stabilité et de sécurité intrinsèques (et détaillés dans le premier billet).

Sur cette distribution, nous allons déployer un serveur DHCP qui permettra le démarrage par le réseau des futures machines de l’infrastructure. Ce serveur DHCP fournira un script iPXE⁶, une version moderne et en source ouverte de PXE (Preboot eXecution Environment), ainsi que des options DHCP distinctes en fonction de la machine à installer. Ces options permettront notamment de fournir une adresse réticulaire (URL) de type HTTP, afin de récupérer un fichier de configuration Ignition spécifique à chaque machine à installer. Ce fichier Ignition permettra la personnalisation de cette machine à partir de l’image Fedora Core OS générique.

Le serveur HTTP est le second service de cette machine virtuelle d’installation. Il permet la publication des configurations Ignition, mais aussi du script iPXE à exécuter, et de l’image de Fedora CoreOS à utiliser pour l’installation.

Le dernier service de cette machine d’installation est un serveur de fichiers sur lequel Opentofu (ou Terraform si vous y tenez vraiment) pourra déposer des extensions de configuration DHCP et des fichiers Ignition : un pour chaque machine virtuelle de l’infrastructure à installer. Dans cette preuve de concept, le serveur de fichiers est un serveur SFTP. Nous verrons dans la suite de cet article que c’est un choix par défaut, et qui n’est pas entièrement satisfaisant.

Déploiement de services sur Fedora CoreOS

Extensions par conteneurs

Fedora CoreOS est une distribution optimisée pour l’hébergement de conteneurs. Son socle (constitué par les namespaces⁷ par défaut) ne contient que très peu de programmes, et les interactions entre les différents logiciels le composant ainsi qu’avec les conteneurs sont fortement limitées par le durcissement mis en place, notamment avec SELinux.

Cette distribution permet bien d’installer des logiciels additionnels sur le socle, grâce à un système de surcouches (layering) de rpm-ostree⁸. Cette éventualité doit cependant être écartées dans le cas de cette machine virtuelle d’installation ; en effet, celle-ci démarre sur un LiveCD ISO et la propriété d’immuabilité de Fedora CoreOS “interdit” l’ajout de nouveaux programmes sur le système en cours d’exécution.

L’ensemble des services déployés doivent donc l’être grâce à des conteneurs. Ce n’est pas si différent de ce qui doit être fait dans un cluster Kubernetes, et il n’est pas étonnant que Red Hat CoreOS soit utilisée comme socle pour la plateforme OpenShift⁹.

De même, les volumes des conteneurs ne sont qu’assez rarement des bind-mount¹⁰ de répertoires arbitraires du socle, et plus généralement des volumes (anonymes ou nommés) du moteur de conteneurs. Cela est dû aux politiques SELinux¹¹ qui restreignent les interactions avec les fichiers dans les volumes, qui doivent avoir (principalement) les types container_file_t ou container_ro_file_t¹², ce qu’ont rarement les fichiers du socle.

Ainsi, le service DHCP et le service HTTP sont déployés sous la forme de conteneurs, et en conséquence, le serveur de fichiers doit l’être également, puisqu’il sert à ajouter du contenu aux volumes exposés aux deux premiers services.

Une autre conséquence est que si un conteneur doit disposer de fichiers pré-existants dans des volumes, il faut trouver un moyen de les y placer. La méthode la plus propre et la plus simple est d’utiliser des conteneurs d’initialisation¹³, à l’instar de ce qui est fait dans les déploiements Kubernetes. Podman dispose également de la commande podman kube qui permet d’émuler en partie les déploiements Kubernetes et notamment les objets ConfigMap¹⁴. Les ConfigMaps étant plus “limitées” que le dépôts de fichiers arbitraires, il a été choisi pour cette preuve de concept d’utiliser exclusivement des conteneurs d’initialisation.

Les Podman Quadlets

Fedora CoreOS dispose par défaut des moteurs Moby (Docker) et Podman.

S’il est bien sûr possible d’utiliser compose pour définir les conteneurs, les orchestrer et les lancer, il est également possible d’utiliser les Podman Quadlets¹⁵. Les Quadlets sont des fichiers de configuration ressemblant à des unités systemd (systemd units), avec des sections en plus. Il en existe de plusieurs types : conteneurs, pods, images, volumes, réseaux, et même une couche de compatibilité avec la syntaxe Kubernetes.

Voici par exemple le quadlet pour le volume stockant les baux DHCP de notre preuve de concept, stocké dans le fichier /etc/containers/systemd/dhcp_data.volume :

[Unit]
Description = DHCP Data Volume

[Volume]
VolumeName = dhcp_data
Device=/dev/disk/by-label/dhcp_data
Options=nodev,noexec,nosuid,rootcontext=system_u:object_r:container_file_t:s0
Type=ext4

Le quadlet du conteneur d’initialisation téléchargeant la dernière image de Fedora CoreOS est :

[Unit]
Description = Download Latest FCOS Image

[Container]
ContainerName = fcos_downloader
Image = image_downloader.image
Exec = download -s stable -f pxe
Volume = fcos_images.volume:/data:z
WorkingDir = /data

[Install]
WantedBy=multi-user.target

Ils sont consommés par un générateur de services systemd qui transforme ces quadlets, situés dans /etc/containers/systemd, en services, situés dans /run/systemd/generator.

L’un des intérêts des quadlets est leur intégration au sein de systemd, avec la possibilité de contrôler de manière assez fine les dépendances avec d’autres services.

En outre, leur syntaxe permet également de monter automatiquement des systèmes de fichiers sur des volumes. Couplé à la facilité de créer des partitions avec Ignition, il est ainsi trivial de créer une partition par volume. Il s’agit d’une bonne pratique de sécurité qui permet de limiter les risques de dénis de service ou de corruption entre conteneurs par saturation d’un système de fichiers commun à plusieurs volumes.

Difficultés rencontrées

Un projet ne serait pas une aventure, sans son lot d’ornières et d’imprévus. Quelle aventure se fut !

Problèmes avec le fournisseur Ignition d’Opentofu

Les fichiers de configuration Ignition sont des documents JSON.

Chaque document JSON décrit une machine complète : partitions, systèmes de fichiers, fichiers de configuration systemd, fichiers arbitaires, répertoires, utilisateurs et groupes, etc. Le contenu des fichiers à créer est sérialisé dans ce document JSON, soit verbatim, soit sous la forme d’une adresse de type data:¹⁶.

Il est possible qu’un fichier de configuration Ignition contienne des directives d’inclusion/fusion d’autres fichiers Ignition pouvant être récupérés notamment par le réseau. Il faut dans ce cas s’assurer de l’intégrité de ces fichiers distants, afin de prévenir la compromission totale du serveur.

Fedora CoreOS étant un système d’exploitation immuable, reposant sur des images systèmes administrées par rpm-ostree, l’image de base est la même pour toutes les machines d’une infrastructure virtualisée ; les machines se diversifient et se spécialisent via leur configuration Ignition. Cette approche est donc opposée à celles impliquant la pré-personnalisation des images avec des outils comme Packer¹⁷.

Le moment et la manière de générer la configuration Ignition peut varier en fonction des préférences individuelles. Le plus gros de la configuration peut être statique : tous les serveurs HTTP ont besoin des mêmes images de conteneurs, des mêmes scripts de démarrage, des mêmes partitions et volumes pour stocker certaines informations de manière persistante. Tout cela peut être stocké dans un fichier Ignition commun à toutes les instances et ultérieurement inclus, ou être mis dans le fichier Ignition de chaque instance. C’est au choix. Avec une approche cloud-init, ces fichiers feraient parties de l’image générée avec Packer.

En revanche, le contenu servi par ces serveurs HTTP ou l’adresse IP d’écoute sont des informations spécifiques à chaque instance. Avec l’approche cloud-init, ces informations seraient communiquées au système d’exploitation par le service de métadonnées interrogé par l’utilitaire cloud-init.

Dans le cas d’espèce, puisque nous n’avons pas encore d’infrastructure virtualisée, pas de serveur HTTP de confiance où stocker et distribuer la configuration commune à toutes les machines virtuelles d’installation, et que le fichier Ignition va être stocké dans un ISO personnalisé de Fedora CoreOS, nous n’allons générer qu’un seul fichier Ignition, contenant les informations communes à plusieurs instances éventuelles et les informations spécifiques à une instance spécifique.

Concernant la conception du document JSON au format Ignition, nous pourrions écrire cette configuration Ignition avec n’importe quel outil, y compris “manuellement”, mais ultérieurement, nous le ferons avec Opentofu, au moins pour les informations spécifiques. Par cohérence, Opentofu a donc également été utilisé pour cette machine.

Étant donné que les fichiers Ignition sont exprimés en JSON, il est possible de structurer ses données en HCL (HashiCorp Configuration Language), puis de faire appel à la fonction jsonencode. Pour autant, Hashicorp a initialement développé un fournisseur Terraform pour Ignition¹⁸, qui a ensuite été abandonné, puis repris par la communauté¹⁹. Ce fournisseur propose des sources de données (data sources) afin de structurer la configuration Terraform et la typer.

Ce fournisseur est assez basique puisqu’il se contente de codifier sous la forme d’un schéma de source de données les champs des différentes structures définies dans la spécification d’Ignition²⁰.

Avec le fournisseur, on écrit donc :

data "ignition_file" "dnsmasq_container" {
    path = "/etc/containers/systemd/dnsmasq.container"
    mode = 420
    content {
        content = file("${path.module}/files/dnsmasq.container")
    }
}

data "ignition_config" "example" {
    files = [
        data.ignition_file.dnsmasq_container.rendered,
    ]
}

locals {
    serialized_config = data.ignition_config.example.rendered
}

En HCL “pur”, pour comparaison, on écrit :

locals {
    dnsmasq_container_file = {
        path = "/etc/containers/systemd/dnsmasq.container"
        mode = 420
        contents = {
            source = format(
                "data:text/plain;base64,%s",
                base64encode(file("${path.module}/files/dnsmasq.container"))
            )
        }
    }

    serialized_config = jsonencode({
        ignition = {
            version = "3.4.0"
        }
        storage = {
            files = [
                local.dnsmasq_container_file,
            ]
        }
    })
}

La différence de verbosité entre les deux versions n’est pas flagrante ; mais surtout, le fournisseur comporte plusieurs problèmes : le document JSON généré n’est pas minimal, certaines générations sont incorrectes, et il manque des options pourtant spécifiées dans la version 3.4.0 du format Ignition.

La génération non-minimaliste est dû à l’usage par le fournisseur des types définis dans le code source de l’outil Ignition lui-même²¹. Par exemple la structure racine d’une configuration Ignition est définie ainsi :

type Ignition struct {
	Config   IgnitionConfig `json:"config,omitempty"`
	Proxy    Proxy          `json:"proxy,omitempty"`
	Security Security       `json:"security,omitempty"`
	Timeouts Timeouts       `json:"timeouts,omitempty"`
	Version  string         `json:"version"`
}

La plupart des champs sont définis avec l’annotation de sérialisation JSON omitempty. Quand cette annotation est utilisée de manière correcte, le champ n’apparait pas dans le document JSON généré avec la fonction json.Marshal si sa valeur est “fausse” ou “vide” selon le système de typage du langage Go. Or, les sous-structures ne sont pas définies comme des pointeurs. Ainsi, elles ne peuvent jamais être “vides”, et les champs sont toujours ajoutés au document JSON, même si elles ne contiennent aucune valeur.

Voici la configuration générée par le code ci-dessus utilisant le fournisseur :

{
  "ignition": {
    "config": {
      "replace": {
        "verification": {}
      }
    },
    "proxy": {},
    "security": {
      "tls": {}
    },
    "timeouts": {},
    "version": "3.4.0"
  },
  "kernelArguments": {},
  "passwd": {},
  "storage": {
    "files": [
      {
        "group": {},
        "overwrite": false,
        "path": "/etc/containers/systemd/dnsmasq.container",
        "user": {},
        "contents": {
          "source": "data:text/plain;charset=utf-8;base64,W1VuaXRdCkRlc2NyaXB0aW9uID0gREhDUCBDb250YWluZXIKCldhbnRzPWltYWdlX2Rvd25sb2FkZXIuc2VydmljZQpBZnRlcj1pbWFnZV9kb3dubG9hZGVyLnNlcnZpY2UKV2FudHM9bmV0d29yay1vbmxpbmUudGFyZ2V0CkFmdGVyPW5ldHdvcmstb25saW5lLnRhcmdldApXYW50cz1kaGNwX2NvbmZpZ19pbml0LnNlcnZpY2UKQWZ0ZXI9ZGhjcF9jb25maWdfaW5pdC5zZXJ2aWNlCgpbQ29udGFpbmVyXQpDb250YWluZXJOYW1lID0gZG5zbWFzcV9jb250YWluZXIKSW1hZ2UgPSBsb2NhbGhvc3QvZG5zbWFzcTpsYXRlc3QKVm9sdW1lID0gZGhjcF9jb25maWcudm9sdW1lOi9ldGMvZG5zbWFzcS5kOnoKVm9sdW1lID0gZGhjcF9kYXRhLnZvbHVtZTovZGF0YTpaClZvbHVtZSA9IC9kZXYvbG9nOi9kZXYvbG9nCk5ldHdvcmsgPSBob3N0CkFkZENhcGFiaWxpdHkgPSBDQVBfTkVUX0FETUlOLENBUF9ORVRfUkFXCgpbU2VydmljZV0KV29ya2luZ0RpcmVjdG9yeT0vdmFyL3Jvb3Rob21lL2RoY3AKRXhlY1N0YXJ0UHJlPS9iaW4vYmFzaCAvdmFyL3Jvb3Rob21lL2dlbmVyYXRlX2RoY3Bfb3B0aW9ucy5zaApFeGVjU3RhcnRQcmU9L3Vzci9iaW4vcG9kbWFuIGJ1aWxkIC10IGRuc21hc3E6bGF0ZXN0IC4KUmVzdGFydD1vbi1mYWlsdXJlCgpbSW5zdGFsbF0KV2FudGVkQnk9bXVsdGktdXNlci50YXJnZXQKCg==",
          "verification": {}
        },
        "mode": 420
      }
    ]
  },
  "systemd": {}
}

En comparaison, voici le document JSON généré en écrivant soi-même en HCL la configuration Ignition :

{
  "ignition": {
    "version": "3.4.0"
  },
  "storage": {
    "files": [
      {
        "contents": {
          "source": "data:text/plain;base64,W1VuaXRdCkRlc2NyaXB0aW9uID0gREhDUCBDb250YWluZXIKCldhbnRzPWltYWdlX2Rvd25sb2FkZXIuc2VydmljZQpBZnRlcj1pbWFnZV9kb3dubG9hZGVyLnNlcnZpY2UKV2FudHM9bmV0d29yay1vbmxpbmUudGFyZ2V0CkFmdGVyPW5ldHdvcmstb25saW5lLnRhcmdldApXYW50cz1kaGNwX2NvbmZpZ19pbml0LnNlcnZpY2UKQWZ0ZXI9ZGhjcF9jb25maWdfaW5pdC5zZXJ2aWNlCgpbQ29udGFpbmVyXQpDb250YWluZXJOYW1lID0gZG5zbWFzcV9jb250YWluZXIKSW1hZ2UgPSBsb2NhbGhvc3QvZG5zbWFzcTpsYXRlc3QKVm9sdW1lID0gZGhjcF9jb25maWcudm9sdW1lOi9ldGMvZG5zbWFzcS5kOnoKVm9sdW1lID0gZGhjcF9kYXRhLnZvbHVtZTovZGF0YTpaClZvbHVtZSA9IC9kZXYvbG9nOi9kZXYvbG9nCk5ldHdvcmsgPSBob3N0CkFkZENhcGFiaWxpdHkgPSBDQVBfTkVUX0FETUlOLENBUF9ORVRfUkFXCgpbU2VydmljZV0KV29ya2luZ0RpcmVjdG9yeT0vdmFyL3Jvb3Rob21lL2RoY3AKRXhlY1N0YXJ0UHJlPS9iaW4vYmFzaCAvdmFyL3Jvb3Rob21lL2dlbmVyYXRlX2RoY3Bfb3B0aW9ucy5zaApFeGVjU3RhcnRQcmU9L3Vzci9iaW4vcG9kbWFuIGJ1aWxkIC10IGRuc21hc3E6bGF0ZXN0IC4KUmVzdGFydD1vbi1mYWlsdXJlCgpbSW5zdGFsbF0KV2FudGVkQnk9bXVsdGktdXNlci50YXJnZXQKCg=="
        },
        "mode": 420,
        "path": "/etc/containers/systemd/dnsmasq.container"
      }
    ]
  }
}

Cette définition incorrecte des types dans le code source d’Ignition n’est pas trivial à corriger car ces types sont générés par un outil appelé schematyper²². Cet outil prend en entrée une description de données au format JSON Schema²³, et écrit en sortie des définitions de structures en Go.

Dans le cas d’espèce, cette verbosité excessive n’est pas forcément gênante car nous n’avons pas de contrainte de taille de fichiers. Certains services de metadonnées cloud en ont cependant une (généralement autour de 16ko) ; dans ces cas, la taille compte.

Également, bien que les champs soient bien définis par le code source d’Ignition, le fournisseur Terraform est incomplet et plusieurs définitions manquent, rendant impossible l’utilisation de certaines options. Ce n’est pas que c’est difficile à ajouter… mais leur absence cumulée au fait qu’exprimer en HCL une configuration Ignition fait qu’il devient immédiatement préférable de s’en passer.

Problèmes avec la prise en charge de SFTP par Opentofu

La solution proposée utilise SFTP afin de permettre l’extension de la configuration du serveur DHCP et la publication de fichiers Ignition pour les futures machines virtuelles qui composeront l’infrastructure.

SFTP est un service natif d’OpenSSH, un des démons les plus exposés et les plus sensibles puisque sa présence est quasi universelle et qu’il transporte notamment les flux d’administration. Son emploi est particulièrement intéressant pour le type de transfert de fichiers utilisé dans cette preuve de concept, grâce à son chiffrement de flux par défaut, son identification native par clé publique, et ses capacités d’isolation à l’aide de chroot²⁴.

De surcroit, la configuration est triviale :

Subsystem sftp internal-sftp
Match User terraform_ignition
ForceCommand internal-sftp
ChrootDirectory /my/chroot/path

Compte tenu des politiques de sécurité SELinux en place par défaut sur Fedora CoreOS, il n’est pas possible d’utiliser le processus OpenSSH Server du socle. En effet, lors de la réception des fichiers, ces derniers sont marqués avec le type SELinux user_home_t avec lequel les conteneurs ne peuvent interagir.

Pour cette raison, la preuve de concept dispose de deux serveurs SSH : un pour se connecter au socle et un autre, accessible uniquement en SFTP, permettant le téléversement de fichiers. Ainsi, les fichiers déposés en SFTP sont marqués avec le type container_file_t qui peut être lu par d’autres conteneurs.

Hélas, ce superbe service SFTP ne peut être utilisé nativement par Opentofu… En effet, l’espoir était que les configurations DHCP soient générées par Opentofu, écrites sur disque à l’aide d’une ressource local_file²⁵ ou même une null_resource²⁶, puis téléversées grâce au mécanisme d’approvisionnement (provisioner) “file”²⁷. Le code aurait ressemblé à :

resource "null_resource" "ignition_configuration" {
  provisioner "file" {
    content = local.encoded_config
    destination = "writable/${vm_id}.ign"  
    connection {
      type = "ssh"
      host = var.netboot_server_ip
      port = 2222
      user = "terraform_ignition"
      agent = true
      bastion_host = var.pve_host
      bastion_user = var.pve_pam_user
      bastion_port = 22
    }
  }
}

Il s’avère néanmoins que cela n’est pas possible, et une tentative renvoie le message d’erreur :

Upload failed: his service allows sftp connections only`

La documentation explique que :

Provisioners which execute commands on a remote system via a protocol such as SSH typically achieve that by uploading a script file to the remote system and then asking the default shell to execute it.

Ce mécanisme d’approvisionnement ayant pour but la copie de fichiers notamment par SSH n’est pas compatible avec le mécanisme standard de transfert de fichiers de SSH²⁸…

La preuve de concept actuelle repose donc sur plusieurs mécanismes d’approvisionnement, dont local-exec²⁹ afin d’exécuter la commande sftp via le shell. Comme cette solution est un bricolage peu satisfaisant, l’auteur de cet article envisage de développer, dans un futur plus ou moins proche, un fournisseur Opentofu pour la gestion de ressources de type fichiers au travers du protocole WebDav³⁰, afin de palier cette situation.

Problèmes avec le fournisseur Opentofu pour Proxmox

Le fournisseur Opentofu pour Proxmox bpg/proxmox³¹ est le fournisseur le plus avancé disponible sur les registres de Terraform.

Hélas, ce dernier ne dispose pas d’une ressource pour le téléversement de fichiers ISO. La ressource proxmox_virtual_environement_file permet certes le téléversement de fichiers arbitraires, mais comme l’indique la documentation, un transfert par SSH vers l’hyperviseur est impliqué, au lieu d’utiliser l’API de Proxmox. La surface d’attaque de cette ressource est donc bien plus importante que si l’API avait été utilisée. C’est d’autant plus regrettable que l’API fournit bien un moyen de téléverser des fichiers ISO.

En conséquence, dans cette preuve de concept, le mécanisme d’approvisionnement local-exec d’Opentofu a été utilisé afin de téléverser le fichier avec l’utilitaire curl par l’API de Proxmox :

    provisioner "local-exec" {
        command = <<EOT
curl \
  -F "content=iso" \
  -F "filename=@customized-${random_pet.config_name.id}.iso;type=application/vnd.efi.iso;filename=fcos-netboot-server-${random_pet.config_name.id}.iso" \
  -H "@${local_file.api_token.filename}" \
  "${var.pve_api_base_url}nodes/${var.pve_node_name}/storage/${var.pve_storage_id}/upload"
EOT      
    }

Une ressource de type local_file a également été utilisée pour stocker le jeton d’API, de manière à éviter d’exposer le jeton directement sur la ligne de commandes³².

Problèmes avec systemd.path et la détection de changements de fichiers dans un répertoire

Le serveur DHCP utilisé par cette preuve de concept repose sur dnsmasq. Celui-ci contient certainement moins de fonctionnalités que le serveur de l’ISC, mais il convient parfaitement pour le démarrage par le réseau.

Une fonctionnalité manquante sur ces deux logiciels est la capacité de recharger automatiquement la configuration lors de son changement ou de son extension. Or, cette preuve de concept repose sur l’extensibilité de la configuration par Opentofu : lorsqu’une nouvelle machine est ajoutée à l’infrastructure, des options DHCP sont définies dynamiquement pour permettre son installation. En particulier, une option DHCP indique où trouver le fichier de configuration Ignition spécifique à cette machine à installer et une autre indique le chemin du disque dur sur lequel effectuer l’installation.

dhcp-host=${mac_address},set:${hostname}tag,${host_ip},${hostname}
dhcp-option=tag:${hostname}tag,encap:128,2,"${vm_id}.ign"
dhcp-option=tag:${hostname}tag,encap:128,3,"/dev/disk/by-path/pci-0000:00:0a.0"

Le redémarrage du service pourrait être fait avec un mécanisme d’approvisionnement de type remote-exec³³, mais cette solution nécessite la capacité d’exécuter des commandes sur le socle depuis Opentofu.

Opentofu dispose déjà de la capacité d’exécuter des commandes arbitraires sur toutes les machines de l’infrastructure par injection de commandes et de fichiers dans les configurations Ignition. Cela demande néanmoins le redémarrage de la machine virtuelle pour appliquer la nouvelle configuration, ce qui n’est pas forcément très discret pour un attaquant qui souhaiterait ainsi compromettre des machines.

Une solution plus propre et ne nécessitant pas d’accès shell est de surveiller les fichiers de configuration avec inotify³⁴. Inotify est une fonctionnalité du noyau Linux qui permet d’émettre des événements lors d’opérations sur le système de fichiers. Les programmes intéréssés peuvent s’abonner à ces événements en vue d’y réagir.

Systemd peut être configuré pour surveiller le système de fichiers avec inotify, grâce aux unités de type path³⁵. La configuration ressemble à ceci :

[Unit]
Description = Path Monitor for DHCP Config

[Path]
PathChanged=/path/to/monitored/path
TriggerLimitIntervalSec=0

[Install]
WantedBy=multi-user.target

Cette unité d’exemple active un service du même nom que celui de l’unité de type path lorsque le chemin indiqué subit une modification. Ce chemin peut être un fichier ou un répertoire. Dans le cas d’un répertoire, les changements n’interviennent que lors de la suppression ou de l’ajout d’un fichier ; les opérations de modification des fichiers contenus dans un répertoire n’entrainent pas de modification du répertoire lui-même.

Hélas, bien qu’il existe une directive PathExistsGlob permettant l’usage de chaines de substitution (e.g. *.conf), il n’existe aucune directive de type PathChangedGlob qui permettrait la surveillance de tous les fichiers au sein d’un répertoire. Un ticket à ce sujet est ouvert depuis plusieurs années³⁶. Un bricolage pour s’accomoder de la situation est de supprimer les fichiers de configuration existants avant d’ajouter les nouveaux, de façon à provoquer un ou deux redémarrages du service³⁷ et la prise en compte de la nouvelle configuration.

Un autre défaut de cette solution est qu’elle exige que systemd “espionne” les fichiers déposés par SFTP dans un volume géré par Podman. Cela implique de faire une hypothèse sur les chemins utilisés par Podman ou de monter une deuxième fois le système de fichiers associé à ce volume à un chemin connu du socle. Si le montage peut sembler plus propre, il faut considérer que lorsqu’on monte un même système de fichiers à de multiples endroits, il faut que les options de montage soient identiques, y compris les informations relatives à SELinux (e.g. l’option rootcontext). Il faut alors à nouveau faire des hypothèses : les options utilisées par les Quadlets Podman lors du montage du système de fichiers sur le volume.

Dans le ticket précédemment évoqué, un moyen de contournement est évoqué : utiliser l’utilitaire inotifywatch³⁸. Ce programme permet la surveillance de plusieurs fichiers dans un répertoire, nommés suivant un motif spécifié. Hélas, ce dernier n’est pas disponible sur le socle de Fedora CoreOS, et comme expliqué précédemment, il n’est pas possible d’installer des logiciels additionnels dans notre cas d’usage. Il est cependant possible de l’utiliser dans un conteneur qui aurait également accès au volume des extensions de configuration DHCP. Une pierre, deux coups : on contournerait la limitation de systemd et on ne ferait plus d’hypothèse sur le chemin d’accès ! Hélas, il reste ensuite à trouver un moyen de redémarrer le service dnsmasq depuis le conteneur ayant détecté le changement…

Donner un accès SSH sur le socle depuis le conteneur de surveillance semble la voie royale. Hélas, cet accès est compliqué à donner, du fait des politiques SELinux, encore une fois, ou du plan d’adressage dynamique de la couche réseau de Podman.

L’hypothèse à faire sur le plan d’adressage de Podman est de connaitre l’adresse IP associée au socle. Elle doit être faite si on tente de se connecter en SSH au socle par le réseau. Une solution pour éviter de faire des hypothèses sur la couche réseau est d’établir la connexion SSH à travers une socket Unix bind-montée dans le conteneur de surveillance. Exposer un service SSH sur socket Unix à d’autres conteneurs ou utilisateurs est une astuce assez élégante notamment discutée par Timothée Ravier, développeur de CoreOS, sur son blog dans le cadre d’un remplacement de sudo par une connexion SSH locale³⁹. Hélas, dans le cas d’espèce, les politiques SELinux empêchent la connexion de socat, utilisé par le client SSH du conteneur, à la socket Unix exposée par le serveur SSHD du socle.

En conséquence, sur cette problématique, aucune solution satisfaisante n’a été trouvée. La solution retenue est, en attendant de trouver mieux, d’utiliser une unité systemd de type path en faisant l’hypothèse sur le chemin du volume Podman, et en supprimant puis en rajoutant le fichier de configuration, afin de déclencher le redémarrage du service.

Conclusion

Cet article a couvert une partie des problèmes rencontrés et des solutions proposées pour la création d’une preuve de concept d’un serveur d’installation pour une infrastructure basée sur Fedora CoreOS sur Proxmox. Le code est ouvert⁵ et les commentaires sont les bienvenues, afin d’améliorer cette dernière et permettre à la communauté d’en bénéficier.

Grâce à cette machine d’installation, il devient trivial de déployer de nouvelles machines faisant tourner Fedora CoreOS. Il suffit pour cela de téléverser le fichier Ignition de la machine à installer et un fichier d’extension de la configuration de dnsmasq, puis de configurer la nouvelle machine virtuelle pour démarrer par le réseau.

Ces téléversements peuvent s’effectuer lors de la déclaration de la nouvelle machine virtuelle dans la configuration d’Opentofu.

Dans le prochain billet de cette série, nous verrons comment déployer, grâce à cette machine d’installation, un serveur DNS⁴⁰, un serveur ACME⁴¹, et un cluster etcd⁴², en vue d’installer une instance d’Openbao⁴³, et ainsi pouvoir enfin créer des instances de Fedora CoreOS sans placer de secrets dans les fichiers Ignition.

https://www.proxmox.com/en/ ↩︎
https://fedoraproject.org/coreos/ ↩︎
https://opentofu.org/ ↩︎
https://www.broken-by-design.fr/posts/proxmox-fcos1/ ↩︎
https://git.broken-by-design.fr/fmaury/iac ↩︎ ↩︎
https://ipxe.org/ ↩︎
https://www.man7.org/linux/man-pages/man7/namespaces.7.html ↩︎
https://coreos.github.io/rpm-ostree/ ↩︎
https://www.redhat.com/fr/technologies/cloud-computing/openshift ↩︎
https://docs.docker.com/storage/bind-mounts/ ↩︎
https://github.com/containers/container-selinux/blob/main/container_selinux.8 ↩︎
https://github.com/containers/container-selinux/blob/main/container.te ↩︎
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/ ↩︎
https://kubernetes.io/docs/concepts/configuration/configmap/ ↩︎
https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html ↩︎
https://www.rfc-editor.org/rfc/rfc2397 ↩︎
https://www.packer.io/ ↩︎
https://github.com/hashicorp/terraform-provider-ignition ↩︎
https://github.com/community-terraform-providers/terraform-provider-ignition ↩︎
https://coreos.github.io/ignition/configuration-v3_4/ ↩︎
https://github.com/coreos/ignition/blob/v2.18.0/config/v3_4/types/schema.go ↩︎
https://github.com/idubinskiy/schematyper ↩︎
https://json-schema.org/ ↩︎
chroot(2) est un appel système qui permet de restreindre la capacité d’un processus à changer de répertoires ; bien utilisé, il permet de restreindre les accès à un sous-ensemble de la hiérarchie des fichiers d’un système de fichiers sous Linux. ↩︎
https://registry.terraform.io/providers/hashicorp/local/latest/docs/resources/file ↩︎
https://registry.terraform.io/providers/hashicorp/null/latest/docs/resources/resource ↩︎
https://developer.hashicorp.com/terraform/language/resources/provisioners/file ↩︎
Le protocole SCP est devenu obsolète à la suite d’une vulnérabilité protocolaire irréparable : https://lwn.net/Articles/835962/ ↩︎
https://developer.hashicorp.com/terraform/language/resources/provisioners/local-exec ↩︎
https://www.rfc-editor.org/rfc/rfc4918 ↩︎
https://registry.terraform.io/providers/bpg/proxmox/latest/docs ↩︎
https://cwe.mitre.org/data/definitions/214 ↩︎
https://developer.hashicorp.com/terraform/language/resources/provisioners/remote-exec ↩︎
https://www.man7.org/linux/man-pages/man7/inotify.7.html ↩︎
https://www.freedesktop.org/software/systemd/man/latest/systemd.path.html ↩︎
https://github.com/systemd/systemd/issues/14330 ↩︎
L’incertitude entre un ou deux redémarrage provient du fait qu’inotify ne garantit pas un événement distinct par opération recherchée. Si deux événements de même type se produisent avant qu’un observateur/abonné ne soit informé du premier, un unique événement lui est rapporté. ↩︎
https://www.man7.org/linux/man-pages/man1/inotifywatch.1.html ↩︎
https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/ ↩︎
https://www.knot-resolver.cz/ ↩︎
https://caddyserver.com/docs/caddyfile/directives/acme_server ↩︎
https://etcd.io/ ↩︎
https://openbao.org/ ↩︎

Expérimentation de Fedora CoreOS sur Proxmox

Wed, 29 May 2024 00:00:00 +0200

Ce billet est le premier d’une série de billets traitant de la création d’une infrastructure virtualisée à l’aide de Proxmox¹ pour la partie hyperviseur, de Fedora CoreOS² pour le système d’exploitation des machines virtuelles invitées (guests). L’infrastructure codifiée (Infrastructure as Code) est réalisée avec OpenTofu³ (Hashicorp Terraform ayant rejoint le côté obscur de la Force).

Présentation de Proxmox

Proxmox est un ensemble d’outils, voire une distribution Linux à part entière reposant sur Debian, permettant l’administration d’une infrastructure virtualisée en ligne de commande, via une interface web, ou grâce à une API. Proposant des options de stockage réparti, de réseau étendu à un groupe d’instances (cluster), de groupes de sécurité, de haute disponibilité, pour n’en citer que quelques-unes, il s’agit d’une solution qui peut remplacer aisément VMWare, au minimum sur les cas d’usage relativement simples.

Présentation de Fedora CoreOS

Fedora CoreOS est une distribution Linux orientée sur la stabilité et la sécurité. Son objectif principal est l’hébergement de conteneurs, et pour cette raison, elle est pourvue d’un socle minimaliste et durci, mis à jour automatiquement. Ces mises à jour automatiques sont aisément réversibles en cas de problème, grâce à son approche pseudo-immuable⁴, reposant sur rpm-ostree, et son système de mise à jour (Zincati) permet également d’orchestrer ces dernières de façon à maintenir un service hautement disponible.

Fedora CoreOS est également un système d’exploitation à part en cela qu’il est conçu pour ne pas avoir besoin d’interagir directement avec le système, que ce soit pour l’installation/configuration ou l’administration. L’idée est qu’un cas de changement de configuration, on réinstalle totalement le système. Au premier démarrage, lors de l’exécution de l’initramfs, le programme ignition⁵ exécute une recette qui configure le système : formatage et partitionnement des disques, ajout des utilisateurs, copies de fichiers et de services, etc..

Si cette approche peut sembler lourde de prime abord, elle présente en réalité l’avantage d’apporter la sérénité à ses administrateurs et administratrices ; en effet, il est dès lors possible de réaliser la recette de la nouvelle configuration à l’identique dans un environnement de préproduction, sans risque d’interférence avec l’existant (snowflake servers⁶).

Ignition et cloud-init⁷ sont des cousins éloignés. Les deux participent à la configuration et la personnalisation d’une image système. Le moment de l’exécution est cependant très différent et importe. En effet, Ignition intervient lors de l’initramfs, tandis que cloud-init intervient plus tard lors du démarrage du système d’exploitation. Ignition est donc en mesure de modifier les tables des partitions avant que le véritable système d’exploitation ne démarre, et préconfigure le système comme si cette configuration avait toujours existé ou avait été modifiée lors d’une exécution précédente.

Ignition possède néanmoins quelques limitations, assumées, notamment si on le compare à Ansible. En effet, Ansible possède de très nombreux greffons lui permettant d’effectuer des actions riches sur un système en cours d’exécution. Ignition permet essentiellement la copie de fichiers et de services, et les opérations complexes doivent être effectuées par des scripts shell (Fedora CoreOS n’installe pas Python, par exemple). Ce choix est raisonnable étant donné que relativement peu d’opérations d’administration sont attendues sur le socle faisant tourner Fedora CoreOS.

En outre, Ansible Vault permet le stockage et le déploiement sécurisé de secrets, y compris dans les outils de versionnement de code comme git. Ignition, pour sa part, ne permet pas la communication de secrets de manière sécurisée ; au mieux, il est possible de les stocker dans un fichier qui sera téléchargé puis fusionné avec le reste de la configuration par Ignition. Cette solution n’étant pas très satisfaisante, il est donc nécessaire d’utiliser un gestionnaire de secrets comme OpenBao (Hashicorp Vault ayant rejoint le côté obscur de la Force)⁸ avec l’emballage de réponses⁹, Bitwarden Send¹⁰ ou Bitwarden Secret Manager¹¹.

Défis d’un déploiement de Fedora CoreOS sur Proxmox

Proxmox dispose d’une couche de compatibilité native avec Cloud-init. Celle-ci n’est hélas pas générique, et ne permet pas de configurer toutes les options de Cloud-init. Avec OpenTofu et le fournisseur bpg/proxmox¹², il est possible de fabriquer à la volée un ISO disposant du label CIDATA, et ainsi d’exploiter le mode “nocloud” de cloud-init¹³. Tout ceci n’aide cependant pas au déploiement de Fedora CoreOS.

Il existe une multitude de moyens de fournir un fichier de configuration à Ignition : par HTTP après une indication par PXE ou sur la ligne de commande du noyau, directement dans le fichier ISO d’installation après une personnalisation de ce dernier, dans une variable du micrologiciel (firmware), etc. Hélas, l’utilisation d’un ISO séparé, à l’instar du mode “nocloud” de cloud-init, n’est pas une option. Nous allons néanmoins voir qu’aucune des autres options n’est native à Proxmox ou satisfaisante.

Fourniture de l’adresse du fichier Ignition par PXE

Proxmox dispose d’une couche réseau programmable/configurable (Software-defined Network (SDN)) assez développée. Cette dernière permet la définition de différentes zones réseau, avec un filtrage des flux par règles et par groupes de sécurité. En outre, elle fournit différents services, dont un serveur DHCP branché sur un IPAM (IP Address Management), avec possible synchronisation des adresses avec un serveur DNS.

Hélas, il n’est pas possible (par l’interface web ou l’API) de personnaliser la configuration DHCP pour y rajouter les options nécessaires à PXE, ni d’ajouter un service pour publier les fichiers de configuration Ignition par HTTP ou TFTP.

Il est bien sûr possible de se connecter en console, en root, pour modifier cette configuration, mais cela demande des privilèges élevés sur l’hyperviseur, et ce n’est pas officiellement supporté par Proxmox. Il est donc préférable de rechercher une voie alternative, supportée et ne nécessitant que peu de privilèges.

Fourniture du fichier de configuration par personnalisation du fichier ISO

La personnalisation du fichier ISO de Fedora CoreOS est assez aisée. En effet, ses développeurs fournissent, notamment sous la forme de conteneurs, des outils pour ajouter des fichiers et modifier la ligne de commande du noyau¹⁴.

Cette approche nécessite cependant d’avoir un fichier ISO distinct par poste à installer. Ce fichier doit à nouveau être téléversé en intégralité à chaque modification de la configuration Ignition, ce qui est consommateur de bande passante. Il peut surement être possible d’utiliser un LXC hébergé par Proxmox pour faire cette personnalisation directement sur l’hyperviseur, sans nécessiter le téléversement.

Au niveau stockage, il est possible de ne pas trop surconsommer du fait que Proxmox prend en charge nativement btrfs¹⁵ et ZFS, et que ces systèmes de fichiers permettent la déduplication des blocs. Cette approche relève cependant d’une certaine forme de bricolage, avec de potentielles pertes de performances dans le cas de ZFS ou d’espace disque dans le cas de btrfs si la déduplication n’est pas demandée assez souvent.

Fourniture du fichier de configuration par une variable du micrologiciel

La fourniture du fichier de configuration par une variable de micrologiciel s’effectue en ajoutant un argument à la commande qemu qui lance la machine virtuelle. Cet argument ressemble à la ligne suivante :

-fw_cfg name=opt/com.coreos/config,file=/local/path/to/config.ign

Cet argument peut être fourni en modifiant le fichier de configuration de la machine virtuelle sur l’hyperviseur dans le répertoire /etc/pve/qemu-server/<vm_id>.conf. Cette méthode nécessite néanmoins la connexion en utilisateur root (via le console ou en SSH), ce qui n’est pas forcément souhaitable, et la manipulation plus ou moins manuelle de fichiers système.

Il peut être également fourni lors des appels à l’API, et le greffon OpenTofu bpg/proxmox permet de le faire avec l’attribut kvm_paramters de la ressource proxmox_virtual_environment_vm. Cette méthode nécessite cependant qu’OpenTofu se connecte avec l’utilisateur root@pam, avec mot de passe et sans avoir défini de second facteur d’authentification. En effet, Proxmox ne permet pas l’utilisation de jetons d’API, même pour l’utilisateur root@pam, pour cette opération. Cette approche abaisse donc significativement le niveau de sécurité et n’est donc pas souhaitable.

En outre, l’option permettant la définition d’une variable dans le micrologiciel prend en argument le chemin vers le fichier de configuration Ignition. Ce chemin est local à l’hyperviseur. Hélas, il n’est pas possible de téléverser sur un serveur Proxmox un fichier arbitraire par l’API ou l’interface web, malgré l’existence d’une fonctionnalité de “snippets”¹⁶. Il est donc là encore nécessaire de se connecter en SSH/SFTP pour téléverser le fichier de configuration…

Convertir un fichier cloud-init

Geco IT¹⁷ a créé un script qui permet de convertir certaines options de cloud-init en fichier de configuration Ignition.

Leur méthode de création de VM ne passe pas par l’API Proxmox mais utilise un autre script shell qui lance des outils en ligne de commandes de la distribution Proxmox. Ces commandes sont exécutées en tant que root, et parmi celles-ci, la commande suivante :

qm set <vmid> -hookscript <snippet_storage>:snippets/hook-fcos.sh

L’attribut -hookscript peut être défini par l’API de Proxmox, et par le greffon bpg/proxmox d’OpenTofu. Cependant, à l’instar de l’attribut -args, celui-ci n’est accepté que si le compte d’API utilisé est root@pam, c’est-à-dire le compte root du serveur Proxmox, avec une authentification par mot de passe et sans second facteur d’authentification.

En conséquence, cette méthode n’apporte aucune sécurité additionnelle par rapport à la précédente discutée, tout en réduisant l’expressivité du fichier de configuration Ignition.

Une proposition de solution : une machine virtuelle d’installation

Comme nous avons pu le voir dans les sections précédentes, l’usage de l’API Proxmox pour les attributs -args et -hookscript est rédhibitoire puisque nécessitant non seulement d’utiliser le mot de passe du compte root dans la configuration OpenTofu, mais aussi de désactiver les seconds facteurs d’authentification.

La solution PXE est certainement la plus élégante, mais l’impossibilité de configurer le serveur DHCP de Proxmox (sans passer par le shell) pour permettre un tel démarrage nous en prive. Finalement, l’approche ISO personnalisé ne passerait pas à l’échelle d’un parc complet.

Nous disposons cependant ici de toutes les briques suffisantes pour construire une solution satisfaisante !

L’idée est la suivante : personnaliser un ISO de Fedora CoreOS afin d’y ajouter un fichier Ignition permettant d’installer un serveur DHCP (pour distribuer les IPs mais aussi la configuration PXE), un serveur HTTP pour servir les fichiers indiqués par PXE, et un serveur SFTP afin de déposer les fichiers de configuration Ignition servis par HTTP.

À l’origine, je souhaitais détailler ici la solution, mais son développement s’est avéré suffisamment complexe (et surprenant) pour constituer un billet de blog séparé. À suivre !

Identité et méthodes d'authentification

Mon, 26 Feb 2024 00:00:00 +0200

Définition des termes

Un acteur ou sujet (subject) est un membre actif d’un système d’information exerçant une action ou une activité sur les membres de ce système. Les acteurs peuvent être des personnes ou des processus.

Par opposition, un objet est un membre inactif du système d’information sur lequel peut porter une activité exercée par un acteur.

L’identité est la manière dont un acteur d’un système d’information se fait connaitre auprès des autres acteurs de ce système. On rattache à l’identité de nombreuses propriétés ou attributs. Par exemple, on peut citer l’adresse email, le numéro de téléphone, son nom et son prénom, un identifiant d’utilisateur ou d’utilisatrice (User Identifier (UID)), un identifiant de processus (Process Identifier PID), l’appartenance à des groupes, l’attribution de rôles, mais il peut s’agir plus largement de valeurs arbitraires propres à cet acteur.

L’authentification est le procédé par lequel un acteur prouve son identité aux autres acteurs du système. Il existe de nombreuses façons de prouver son identité : mots de passe, clés cryptographiques, biométrie, etc. Dans les textes juridiques, les authentifiants sont parfois appelés “moyens d’identification électroniques”.

L’autorisation encadre les activités que l’acteur peut entreprendre sur les objets du système d’information.

Identité

Portée

La portée d’une identité peut être vue comme son périmètre d’action, c’est-à-dire l’espace dans lequel cette identité a du sens (un peu comme une carte d’identité française n’a pas de valeur au Royaume-Uni). Nous allons en envisager plusieurs : locale, centrale, répartie et décentralisée.

De la portée locale

Une identité peut être locale à un système d’information, ou même à un sous-ensemble d’un système d’information. C’est le cas des comptes locaux gérés par nsswitch et le module PAM (Pluggable Authentication Modules)¹ pam_unix sur une machine Linux. Les identités locales présentent l’avantage d’être autonomes et toujours disponibles, sans être tributaires de la disponibilité de système tiers. La contrepartie est une difficulté notable à maintenir la cohérence des identités sur les différents systèmes, chacun ayant la même force de vérité dans leur périmètre.

---
title: Illustration des comptes locaux
---
flowchart LR
  laptop["Client"]
  subgraph srv1 ["Serveur 1"]
    direction LR
    proc1[/"Processus 1"/]
    db1[("Base locale 1")]
  end
  subgraph srv2 ["Serveur 2"]
    direction LR
    proc2[/"Processus 2"/]
    db2[("Base locale 2")]
  end
  subgraph srv3 ["Serveur 3"]
    direction LR
    proc3[/"Processus 3"/]
    db3[("Base locale 3")]
  end

  laptop --> srv1 & srv2 & srv3
  proc1 --> db1
  proc2 --> db2
  proc3 --> db3

Des référentiels d’identités centraux

La portée d’une identité peut être plus large et une identité peut être connue de plusieurs membres d’un système d’information ; on parle alors d’une identité centralisée.

Un référentiel d’identités central contient les identités d’un ensemble d’acteurs.

L’intérêt d’un tel référentiel devient évident à mesure qu’un système d’information s’agrandit ; gérer manuellement des identités locales sur de nombreux systèmes peut mener à des incohérences, et des oublis. En rassemblant les informations dans un référentiel central, il n’y alors qu’une seule source de vérité, faisant autorité pour l’ensemble du système d’information concerné. Il convient également de noter qu’il peut exister des copies de ces informations conservées en local sur les différents systèmes assujettis à ce référentiel d’identité. Ces copies ne font pas autorité, et il convient de surveiller leur cohérence avec la source de vérité et de les invalider ou les mettre à jour, le cas échéant.

Les copies sont souvent nécessaires à des fins de performance et de résilience. En effet, centraliser les identités présente des défis techniques notamment en matière de disponibilité ; une panne du référentiel central peut être de nature à stopper net l’ensemble des activités d’un système d’information.

Parmi les protocoles fréquemment utilisés pour la centralisation des identités, il est possible de citer LDAP².

---
title: Illustration d'un annuaire centralisé
---
flowchart LR
  laptop["Client"]
  subgraph srv1 ["Serveur 1"]
    direction TB
    proc1[/"Processus 1"/]
    dbs1[("Copie locale")]
  end
  subgraph srv2 ["Serveur 2"]
    direction TB
    proc2[/"Processus 2"/]
    dbs2[("Copie locale")]
  end
  subgraph srv3 ["Serveur 3"]
    direction TB
    proc3[/"Processus 3"/]
    dbs3[("Copie locale")]
  end

  subgraph ref ["Référentiel d'identité"]
    ldapsrv[/"Serveur LDAP"/]
    db[("Base d'identités")]
  end

  laptop --> srv1 & srv2 & srv3
  srv1 & srv2 & srv3 --"LDAP"--> ref
  proc1 --> dbs1
  proc2--> dbs2
  proc3 --> dbs3
  ldapsrv --> db

Des référentiels d’identités répartis

Un référentiel d’identités peut être amené à voir sa taille grandir, que ce soit de manière organique ou lors d’acquisitions de sociétés. Dans ce dernier cas, en particulier, il existe alors plusieurs référentiels d’identités concurrents, qu’il pourrait être intéressant de fusionner. Cette opération est sensible, et difficile.

Il existe des alternatives à la fusion ; l’établissement d’une forêt³ ou la mise en place d’un annuaire virtuel (Virtual Directory Service (VDS))⁴.

Une forêt est constituée d’un ensemble de référentiels d’identités indépendants entre lesquels il existe une relation de confiance. Ainsi, par transitivité de la confiance, les membres d’un référentiel d’identité accordent leur confiance aux identités gérées par un autre référentiel d’identité. Ce genre de schéma est très répandu dans les infrastructures Active Directory.

Les services d’annuaires virtuels jouent le rôle de serveurs mandataires pour l’accès à plusieurs référentiels d’identité. Ces derniers apparaissent alors comme “fusionnés” aux yeux des utilisateurs de service, alors qu’ils continuent d’être gérés individuellement.

---
title: Illustration d'annuaires répartis (forest)
---
flowchart LR
  laptop["Client"]
  subgraph srv1 ["Serveur 1"]
    direction TB
    proc1[/"Processus 1"/]
    dbs1[("Copie locale")]
  end
  subgraph srv2 ["Serveur 2"]
    direction TB
    proc2[/"Processus 2"/]
    dbs2[("Copie locale")]
  end

  subgraph refnet ["Référentiel d'identité #quot;example.net#quot;"]
    direction TB
    ldapsrv[/"Serveur LDAP"/]
    db[("Base d'identités")]
  end

  subgraph refcom ["Référentiel d'identité #quot;example.com#quot;"]
    direction TB
    ldapsrv2[/"Serveur LDAP"/]
    db2[("Base d'identités")]
  end

  laptop --> srv1 & srv2
  srv1 & srv2 --"LDAP"--> refcom
  proc1 --> dbs1
  proc2 --> dbs2
  ldapsrv --> db
  srv1 & srv2 --"LDAP"--> refnet
  ldapsrv2 --> db2

---
title: Illustration d'annuaires répartis (VDS)
---
flowchart LR
  laptop["Client"]
  subgraph srv1 ["Serveur 1"]
    proc1[/"Processus 1"/]
    dbs1[("Copie locale")]
  end
  subgraph srv2 ["Serveur 2"]
    proc2[/"Processus 2"/]
    dbs2[("Copie locale")]
  end
  subgraph srv3 ["Serveur 3"]
    proc3[/"Processus 3"/]
    dbs3[("Copie locale")]
  end

  subgraph vds ["Virtual Directory Service"]
    direction TB
    vdss[/"Serveur VDS"/]
    dbss[("Copie locale")]
  end

  subgraph refnet ["Référentiel d'identité #quot;example.net#quot;"]
    ldapsrv[/"Serveur LDAP"/]
    db[("Base d'identités")]
  end

  subgraph refcom ["Référentiel d'identité #quot;example.com#quot;"]
    ldapsrv2[/"Serveur LDAP"/]
    db2[("Base d'identités")]
  end

  laptop --> srv1 & srv2 & srv3
  proc1 --> dbs1
  proc2 --> dbs2
  proc3 --> dbs3
  srv1 & srv2 & srv3 --"LDAP"--> vds
  vds --"LDAP"--> refcom & refnet
  vdss --> dbss
  ldapsrv --> db
  ldapsrv2 --> db2

Des référentiels d’identités décentralisés

Les référentiels d’identités répartis ont du sens lorsque l’ensemble des référentiels d’identités sont sous le contrôle d’entités juridiques ayant un rapport de confiance ou ayant la volonté d’apparaitre sous une même bannière. La confiance et l’unification s’effectuent par les gestionnaires des référentiels d’identités ; le consommateur de ces référentiels n’a aucun pouvoir de décision.

Il existe cependant une alternative dans le cas où ce genre de centralisation ou de répartition n’est pas possible ou souhaitable : l’utilisation de référentiels d’identités décentralisés. On parle alors d’identités fédérées.

Avec des référentiels d’identités décentralisés, chaque référentiel est géré par ses gestionnaires selon des politiques qui leur sont propres. C’est, en revanche, les responsables des systèmes d’information ayant besoin de connaitre l’identité de leurs utilisateurs et utilisatrices qui choisissent à quels fournisseurs de référentiels d’identités décentralisés ils font confiance ! Si l’identité d’un utilisateur ou d’une utilisatrice n’est pas gérée par un fournisseur de référentiels d’identité accrédité par les responsables d’un système d’information, il ou elle ne pourra pas se faire connaitre de ce système d’information.

Concernant la disponibilité, la plupart des services consommant des identités fédérées maintiennent en local une base de données avec des attributs supplémentaires spécifiques à leurs besoins métier. En revanche, si un fournisseur de référentiel d’identités est indisponible, les utilisateurs et les utilisatrices de ce fournisseur ne pourront plus se connecter à aucun service.

Les référentiels d’identités décentralisés sont devenus très populaires sur Internet, et de nombreux sites proposent ainsi de s’enregistrer ou de s’identifier à l’aide d’une identité fédérée. Ironiquement, cependant, peu de référentiels d’identités sont accrédités par les sites web, et les identités décentralisées reconnues se limitent souvent à celles gérées par quelques acteurs clés : Google, Facebook, Twitter, ou spécifiquement en France, France Connect.

L’interrogation de ces référentiels se fait à l’aide de protocoles plus ou moins standards. Parmi les plus répandus, on peut notamment citer OpenID Connect⁵ et SAML⁶.

---
title: Illustration d'annuaires décentralisés
---
flowchart LR
  laptop["Client"]
  subgraph srv [Serveur]
    direction TB
    proc[/"Processus"/]
    dbs[("Base locale")]
  end

  subgraph refnet ["Référentiel d'identité #quot;example.net#quot;"]
    direction TB
    oidcsrv1[/"Serveur OpenID Connect"/]
    db1[("Base d'identités")]
  end

  subgraph refcom ["Référentiel d'identité #quot;example.com#quot;"]
    direction TB
    samlsrv1[/"Serveur SAML"/]
    db2[("Base d'identités")]
  end

  subgraph reforg ["Référentiel d'identité #quot;example.org#quot;"]
    direction TB
    oidcsrv2[/"Serveur OpenID Connect"/]
    db3[("Base d'identités")]
  end


  laptop --"Protocole OIDC/SAML"--> srv
  srv --"Accrédite"--> refnet
  srv --"Accrédite"--> refcom
  srv --"`N'accrédite *PAS*`"--> reforg;
  proc --> dbs
  laptop <-."Protocole OIDC".-> refnet
  laptop <-."Protocole SAML".-> refcom
  oidcsrv1 --> db1
  samlsrv1 --> db2
  oidcsrv2 --> db3
  linkStyle 1,2 color:red;

Sur la séparation des référentiels d’identité

Le référentiel SecNumCloud⁷⁸ prévoit que les comptes d’administration d’un prestataire de cloud qualifié soient gérés “à l’aide d’outils et d’annuaires distincts de ceux utilisés pour la gestion des comptes utilisateurs placés sous la responsabilité du commanditaire (c’est-à-dire de ses clients)”.

Exigée pour les prestataires de cloud qualifiés, cette séparation des référentiels d’identités afin d’en dédier un pour les comptes d’administration du système d’information semble une bonne pratique de sécurité à adopter en général. Elle permet, en effet, de limiter la surface d’attaque des services manipulant notamment les clés cryptographiques utilisées pour l’administration (clés TLS, clés de signature des “jetons d’accès”, etc.).

Authentification

L’authentification est un sujet complexe, que ce cours va aborder sous de nombreux angles :

les aspects juridiques et normatifs ;
les facteurs d’authentification ;
la force de l’authentification ;
les mécanismes de preuve mis en œuvre ;
les risques de la réutilisation de moyens de preuve d’identité ;
le stockage des éléments authentifiants.

Aspects juridiques de l’authentification

L’authentification est un sujet traité à la fois par les juridictions nationales et internationales. Un défaut de conformité à ces dispositions peut entrainer des sanctions parfois sévères.

La Commission Nationale Information et Libertés (CNIL) a à plusieurs reprises sanctionné des sociétés mettant en place des mécanismes d’authentification trop faibles⁹, des politiques de sécurité entourant les moyens d’authentifications insuffisantes¹⁰, ou des mécanismes de stockage des éléments authentifiants trop faibles, mal déployés ou mal composés¹¹.

Parmi les textes juridiques encadrant l’authentification, on peut notamment évoquer le règlement européen “Electronic Identification, Authentication and Trust Services” (eiDAS)¹² et la “directive révisée sur les services de paiement” (DSP2)¹³.

En France, la directive DSP2 a été transposée notamment dans les articles L133-4¹⁴ et L133-44¹⁵ du code monétaire et financier.

Pour le règlement eiDAS, des spécifications techniques viennent compléter les textes juridiques, notamment à des fins d’interopérabilité¹⁶. Des précisions techniques sont également apportées sur les contraintes pour satisfaire les différents niveaux de garantie définis par le règlement¹⁷. Une ordonnance¹⁸ donne le pouvoir à l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI)¹⁹ de certifier des moyens d’authentification permettant de satisfaire ces niveaux de garantie. De plus amples informations sur le règlement eiDAS peuvent être trouvées sur le site de l’ANSSI²⁰.

Nous reviendrons sur le contenu de ces textes au fur et à mesure que le cours abordera les notions qui y sont renseignées.

Outre les textes à valeurs juridiques, en France, l’ANSSI a publié divers référentiels et guides :

le Référentiel Général de Sécurité (RGS) 2.0, et en particulier son annexe B1 sur les mécanismes cryptographiques et son annexe B3 sur les mécanismes d’authentification²¹ ;
le guide “Recommandations relatives à l’authentification multifacteur et aux mots de passe”²².

Le respect des règles et “recommandations” listées dans ces documents est requis pour l’obtention d’un certain nombre de qualifications de l’ANSSI, notamment SecNumCloud⁷.

Les facteurs d’authentification

Le règlement d’exécution (UE) 2015/1502¹⁷ définit trois types de facteurs d’authentification.

a) “facteur d’authentification basé sur la possession”, un facteur d’authentification dont il revient au sujet de démontrer la possession;

b) “facteur d’authentification basé sur la connaissance”, un facteur d’authentification dont il revient au sujet de démontrer la connaissance;

c) “facteur d’authentification inhérent”, un facteur d’authentification qui est basé sur un attribut physique d’une personne physique, et dont il revient au sujet de démontrer qu’il possède cet attribut physique.

Cette définition est également présente dans le code monétaire et financier, ainsi que dans le RGS (à une subtilité prête ; voir le chapitre concernant la force de l’authentification).

Les facteurs d’authentification basés sur la possession

D’après le guide de l’ANSSI “Recommandations relatives à l’authentification multifacteur et aux mots de passe” :

Un facteur de possession est un moyen de stocker des secrets non mémorisables par un humain (et n’ayant pas vocation à être mémorisés par un humain). Il s’agit typiquement des clés cryptographiques qui permettent de réaliser des opérations de chiffrement, de signature ou d’authentification.

Le même guide spécifie également :

Un facteur de possession doit être un équipement attribué à un unique utilisateur. Afin de garantir la sécurité apportée par ce facteur, il est essentiel que des moyens de protection et de détection contre les tentatives de reproduction ou de falsification du facteur soient mis en place. Un facteur de possession peut être une carte à puce contenant une clé privée, une carte SIM d’un téléphone mobile comportant des données d’identification, ou un dispositif permettant de générer des codes à usage unique (OTP).

Les facteurs d’authentification basés sur la connaissance

Les facteurs d’authentification basés sur la connaissance reposent sur le fait que l’acteur connaisse un secret. En général, il s’agit d’un mot de passe, d’une phrase de passe, ou d’un code PIN (Personal Identification Number).

Les jetons d’authentification (authentication token ou bearer token) sont un cas intéressant lorsqu’on parle d’authentification multifacteurs. En effet, ces derniers sont soit des valeurs aléatoires assimilables à des clés cryptographiques symétriques, soit des informations structurées et signées et encodées sous la forme d’une chaine de caractères (par exemple en base64). La simple preuve de la connaissance d’un tel jeton est suffisante pour prouver son identité ; cela laisserait donc entendre qu’il s’agisse d’un facteur d’authentification basé sur la connaissance. Pourtant, il s’agit d’un secret non mémorisable par un humain, ce qui entrerait aussi dans certaines des définitions d’un facteur d’authentification basé sur la possession.

Les facteurs d’authentification inhérents

L’authentification par des facteurs inhérents est une question épineuse en France. En effet, l’ANSSI a longtemps été une pourfendeuse de la biométrie, indiquant que les facteurs inhérents sont au mieux un facteur d’identification et non d’authentification, ou dans le pire des cas une méthode de déverrouillage pour un autre facteur d’authentification. Cette position a dû être partiellement révisée par la contrainte européenne, au travers du règlement eiDAS et la directive DSP2.

Cette méfiance vis-à-vis de la biométrie n’est pourtant pas sans justification.

La vérification des facteurs inhérents s’effectue de manière probabiliste ; contrairement à la vérification des mots de passe ou des signatures cryptographiques, l’acquisition des données nécessaires à ce type de vérification n’est pas “parfaite”, et les algorithmes sont paramétrés avec des taux de faux positifs (validation d’une personne non autorisée) et de faux négatifs (refus d’une personne autorisée). Suivant le paramétrage, l’utilisateur fait alors face soit à un risque en confidentialité et en intégrité, soit à un risque en disponibilité. Ces paramétrages doivent d’ailleurs tenir compte qu’au cours du temps, certaines caractéristiques physiques changent ou s’estompent.

Ensuite, les facteurs inhérents ne sont pas renouvelables à l’infini ; si la révocation d’un moyen est possible, son remplacement ne l’est pas forcément.

Également, le risque de réutilisation d’une même caractéristique physique pour l’authentification auprès de plusieurs systèmes d’information peut comporter des risques de compromission croisée : un système d’information compromis pourrait permettre d’en compromettre un autre, à la manière d’une attaque dite de “credential stuffing”²³. Cette attaque ne se limite cependant pas aux exfiltrations de données biométriques depuis des bases de données compromises ; par le passé, des chercheurs en sécurité ont réussi à extraire des données biométriques à partir de simples photos²⁴.

Remarques concernant l’authentification des processus

La notion de facteurs d’authentification n’a réellement de sens que pour les utilisateurs. Par définition, un processus ne peut posséder un équipement ou mettre en œuvre un attribut physique.

Pourtant, l’exigence 9.6, alinéa f du référentiel SecNumCloud dispose que :

Le prestataire doit mettre en place un système d’authentification multifacteur fort pour l’accès :

aux interfaces d’administration utilisées par le prestataire ;

aux interfaces d’administration dédiées aux commanditaires.

Avec une lecture littérale, il semblerait donc impossible d’authentifier des processus autonomes (par exemple, les tâches planifiées ou les traitements de chaines d’intégration ou de déploiement continu (CI/CD)) pour l’administration d’un cloud qualifié SecNumCloud. Fort heureusement, les auditeurs SecNumCloud ne suivent pas à la lettre cette exigence mal écrite, et les prestataires de Cloud qualifiés proposent pour la plupart des interfaces d’administration programmables (API) sans avoir recours à une authentification multifacteur.

Il convient cependant de noter que strictement parlant, il pourrait être considéré qu’un processus puisse mettre en œuvre un facteur d’authentification basé sur la possession à l’aide d’équipements de sécurité particuliers : les Trusted Platform Module (TPM)²⁵, les Hardware Security Module (HSM)²⁶, et les Key Management Services (KMS)²⁷. Ces équipements permettent la manipulation ou l’exercice de secrets sans en permettre l’extraction, la copie ou la falsification.

La force de l’authentification

Le règlement eiDAS définit trois niveaux de garantie : faible, substantiel et élevé.

À chacun de ces niveaux de garantie sont associées des contraintes particulières. Parmi ces dernières, on peut notamment citer le nombre de facteurs d’authentification requis. Ainsi, le niveau faible ne requiert l’usage que d’un seul facteur, tandis que le niveau substantiel requiert au moins deux facteurs de nature différente.

La directive européenne DSP2 transposée dans le code monétaire et financier définit l’authentification forte comme étant :

[…] une authentification reposant sur l’utilisation de deux éléments ou plus appartenant aux catégories “connaissance” (quelque chose que seul l’utilisateur connait), “possession” (quelque chose que seul l’utilisateur possède) et “inhérence” (quelque chose que l’utilisateur est) et indépendants en ce sens que la compromission de l’un ne remet pas en question la fiabilité des autres, et qui est conçue de manière à protéger la confidentialité des données d’authentification ;

Cette définition de l’article L133-44 du code monétaire et financier vient en contradiction avec la définition de l’authentification forte que l’ANSSI emploie parfois. En effet, la définition de l’authentification forte dans le RGS est (presque) conforme à la définition du droit français:

Cette recommandation est en cohérence avec la notion traditionnelle « d’authentification forte », qui préconise de combiner deux mécanismes parmi ce que l’on sait, ce que l’on a, ce que l’on est ou ce que l’on sait faire.

On notera au passage que le RGS évoque “ce que l’on sait faire” qui est un facteur qui n’est ni reconnu par le règlement eiDAS, ni le code monétaire et financier.

En revanche, dans son guide “Recommandations relatives à l’authentification multifacteur et aux mots de passe” en version 2.0, le chapitre 2.5 distingue “authentification forte” et “authentification multifacteur”, en précisant :

En langue française, l’authentification multifacteur est souvent confondue avec l’appellation authentification forte (ou robuste), ce qui laisserait entendre qu’une authentification multifacteur est nécessairement plus robuste qu’une authentification avec un unique facteur.

[…]

Afin d’être considérée comme forte, une authentification doit reposer sur un protocole cryptographique permettant de résister à certaines attaques comme :

l’écoute clandestine (eavesdroppping en anglais), qui consiste pour un attaquant à passivement écouter le canal de communication entre le prouveur et le vérifieur ;

les attaques par rejeu, qui consistent pour un attaquant à récupérer des informations d’authentification (comme un mot de passe ou son empreinte) et à utiliser ces informations pour les rejouer afin d’usurper l’identité de la cible (l’attaque pass-the-hash [21] en est un exemple) ;

les attaques de l’homme-du-milieu, qui consistent pour un attaquant à intercepter et modifier les communications se déroulant entre le prouveur et le vérifieur lors de l’authentification sans être détecté ;

la non-forgeabilité : l’observation par un attaquant de plusieurs échanges d’authentification d’un prouveur ne doit pas lui permettre d’usurper son identité dans un nouvel échange d’authentification.

En outre, l’expression “authentification forte” est de plus en plus galvaudée par le marketing.

Il convient donc de toujours s’assurer de la définition de l’authentification forte qu’un interlocuteur ou une interlocutrice utilise.

Les mécanismes d’authentification

Cette section du cours n’a pas vocation à être exhaustive. La liste qui suit n’est même pas forcément représentative des mécanismes les plus fréquemment utilisés. Elle permet cependant de couvrir un large éventail de techniques afin d’apporter une culture générale sur le sujet.

Dans cette section, on utilisera le terme de prouveur pour désigner celui qui tente de prouver son identité ; c’est-à-dire de s’authentifier. Le terme vérificateur désigne celui qui vérifie les preuves d’identité. On peut penser de prime abord que seul l’utilisateur tente de prouver son identité auprès d’un serveur pour accéder à son compte. La réalité est que presque toujours, le serveur prouve également son identité auprès du logiciel mis en œuvre par l’utilisateur ou l’utilisatrice. En conséquence, il serait incorrect de considérer que prouveur et utilisateurs sont synonymes dans le chapitre qui suit.

La preuve par divulgation

La méthode la plus universelle pour prouver son identité est de divulguer un secret au vérificateur. Ce dernier peut alors comparer ce secret à celui attendu pour cet acteur. S’ils correspondent, alors la preuve est faite. C’est le cas typique de l’utilisateur qui envoie son mot de passe tel quel à un serveur. C’est également le cas pour les codes temporels (TOTP), les codes Transaction Authentification Number (TAN) (par exemple, des codes reçus par email ou par SMS et à reproduire auprès du vérificateur), les codes PIN, les jetons d’authentification, etc. C’est également le cas des “identifiants de session”, comme les “cookies de session”, qui ne sont ni plus ni moins que des jetons d’authentification présentés à chacune des requêtes.

Ce mécanisme d’authentification présente de nombreux défauts, et a pour seul avantage d’être extrêmement simple à implémenter, à tout le moins du côté du prouveur. Côté vérificateur, les choses sont plus complexe : il s’agit de stocker de manière sécurisée le matériel nécessaire à la vérification de l’identité. Ce stockage sécurisé est l’objet d’un chapitre ultérieur.

Outre la nécessité d’un stockage sécurisé, ce mécanisme d’authentification nécessite que le secret exige sur un canal de communication assurant la confidentialité des données. Sans cela, un attaquant ou une attaquante n’aurait qu’à écouter passivement le réseau pour apprendre le secret. En outre, tous les logiciels manipulant le secret en clair et dans sa forme originale, tel que connu du prouveur, devraient mettre en place des mesures de sécurité afin de limiter les risques de divulgation de ce secret en cas de compromission logicielle : nettoyer la mémoire, mettre en place des pages de garde (page guards), isoler les traitements des secrets dans des processus séparés. En pratique, cela n’est presque jamais fait. C’est ainsi que des vulnérabilités comme Heartbleed²⁸, qui avait permis de faire des lectures arbitraires dans la mémoire des processus utilisant OpenSSL pour sécuriser les communications, ont permis de récupérer les mots de passe non protégés directement en mémoire. Tous les secrets ainsi exfiltrés étaient directement utilisables pour se connecter aux comptes associés.

Finalement, ce mécanisme d’authentification ne présente aucune protection contre le rejeu. Ainsi, si le canal de communication est intercepté ou si l’utilisateur ou l’utilisatrice est victime d’une attaque par hameçonnage (phishing), et qu’il ou elle saisit son mot de passe sur le site frauduleux, alors l’attaquant ou l’attaquante apprendra le moyen de preuve et pourra le mettre en œuvre pour accéder au compte associé. Il conviendra néanmoins de nuancer l’impact de la vulnérabilité aux attaques par rejeu avec la durée de vie du secret divulgué : certains sont à usage unique ou ont une faible durée de validité (TOTP, TAN, etc.), tandis que d’autres ont des durées de vie beaucoup plus longues (par exemple, les mots de passe).

---
title: Authentification par divulgation d'un mot de passe
---
sequenceDiagram
  autonumber
  actor peggy as Peggy
  box
    actor victor as Victor
    participant db as Base de données
  end

  peggy ->> victor:"Je m'appelle Peggy. Mon mot de passe est #quot;Bonjour1!#quot;."

  victor ->> victor:Calcule la dérivée du mot de passe reçu

  victor ->> db:"Quel est la dérivée du mot de pase de Peggy ?"
  db ->> victor:"Voici la dérivée du mot de passe de Peggy"

  victor ->> victor:Compare les deux dérivées

  alt Mot de passe valide
    victor ->> peggy:"Bonjour Peggy"
  else Mot de passe invalide
    victor ->> peggy:"Je ne crois pas, non"
  end

La preuve par défi

Les mécanismes d’authentification reposant sur des défis sont des procédés interactifs : un dialogue se met en place entre le vérificateur et le prouveur. Ce dialogue permet de s’accorder sur une valeur aléatoire, parfois appelée nonce. Cet accord peut être unilatéral : le vérificateur décide arbitrairement de cette valeur. Ensuite le prouveur effectue une opération cryptographique sur cette valeur aléatoire et envoie le résultat au vérificateur. Ce dernier vérifie alors la preuve à l’aide d’un élément en sa possession et qui est associé à l’identité supposée du prouveur.

Il existe de nombreux protocoles reposant sur les défis ; certains ont de très bonnes propriétés de sécurité ; d’autres sont catastrophiquement mauvais, et même pires que la preuve par divulgation !

RFC 7616 : HTTP Digest

La RFC 7616²⁹ décrit le mécanisme d’authentification HTTP Digest.

Le vérificateur génère un nonce et l’envoie au prouveur. Ce dernier utilise alors une fonction de hachage cryptographique sur la concaténation de l’identité à prouver, le mot de passe associé à cette identité, le nonce, le verbe HTTP et l’URI demandée. Le résultat de la fonction de hachage est envoyé au vérificateur. Ce dernier exécute la fonction de hachage de son côté avec les mêmes entrées. Si le résultat de la fonction de hachage appelée par le vérificateur est identique à celui transmis par le prouveur, alors la preuve est faite.

L’intérêt supposé de ce mécanisme d’authentification est que le mot de passe n’est à aucun moment transmis dans la requête HTTP. Celui-ci est protégé par la résistance de la fonction de hachage cryptographique à la découverte d’une préimage³⁰.

Cet intérêt supposé est cependant assez peu pertinent étant donné que l’essentiel des communications HTTP est de nos jours transporté sur des canaux de communication chiffrés (par TLS ou HTTP/3 qui intègrent directement le chiffrement).

Un intérêt notable de ce mécanisme d’authentification est l’inclusion d’un nonce. Ce dernier permet de contrer les attaques par rejeu ; en effet, même en cas d’interception d’une preuve, il n’est pas possible de l’utiliser pour réaliser des tentatives d’authentification futures par simple rejeu.

En revanche, ce mécanisme d’authentification requiert que le vérificateur connaisse le mot de passe de l’utilisateur³¹ et qu’il le stocke tel quel, ou sous un format réversible. En conséquence, en cas de fuite de la base de données du vérificateur, un attaquant pourrait immédiatement utiliser les valeurs récupérées pour usurper l’identité de tous les acteurs auprès de ce vérificateur. Cet inconvénient majeur disqualifie totalement ce mécanisme d’authentification, qui ne doit jamais être employé.

Un autre problème de sécurité est que la divulgation de toute preuve à un attaquant ou une attaquante lui permet d’effectuer ensuite une recherche exhaustive hors-ligne sur le mot de passe qui a permis de générer cette preuve ; tous les autres éléments sont connus. La possibilité de recherche exhaustive hors-ligne sur des mots de passe est agravée par le fait que les fonctions de hachage spécifiées dans la RFC sont très insuffisantes ; ces considérations de sécurité sont identiques à celles discutées dans le chapitre sur le stockage des dérivées des mots de passe.

---
title: Authentification avec HTTP Digest (simplifiée)
---
sequenceDiagram
  autonumber
  actor peggy as Peggy
  box
    actor victor as Victor
    participant db as Base de données
  end

  peggy ->> victor:"Je voudrais faire X sur l'adresse Y."

  victor ->> peggy:"Heu, t'es qui ? Voici un nonce."

  peggy ->> peggy: Calcule le condensat, avec son nom, son mot de passe, X, Y et le nonce

  peggy ->> victor:"Je m'appelle Peggy. Je voudrais faire X sur l'adresse Y. Voici le nonce et mon condensat."

  victor ->> db: "C'est quoi le mot de passe de Peggy ?"

  db ->> victor: "Le mot de passe de Peggy est #quot;Bonjour1!#quot;..."

  victor ->> victor:Calcule le condensat, avec le nom #quot;Peggy#quot;, le mot de passe de Peggy, X, Y et le nonce

  alt Les condensats correspondent
    victor ->> peggy:"Bonjour Peggy. Voici le résultat de X sur Y."
  else Les condensats ne correspondent pas
    victor ->> peggy:"Je ne crois pas, non"
  end

La signature électronique

La signature électronique est une méthode d’authentification très courante. Elle est notamment employée par les protocoles SSH, TLS, et IPsec.

Le principe général est que le prouveur dispose d’une clé privée et le vérificateur dispose de la clé publique associée. Le prouveur effectue la signature électronique d’un nonce et le vérificateur n’a alors qu’à utiliser la clé publique pour en vérifier l’authenticité. Si elle est authentique, alors la preuve est faite.

Ce mécanisme d’authentification présente l’avantage de lever toute contrainte relative à la confidentialité du stockage par le vérificateur : seule une clé publique est stockée, dont la divulgation ne remet pas en cause la sécurité du mécanisme d’authentification. La contrainte d’intégrité du stockage de la clé publique peut elle-même être levée si la clé publique est inscrite dans un certificat, faisait partie d’une infrastructure de clés. Il faudra néanmoins assurer l’intégrité du certificat racine de l’infrastructure de clés.

Des précautions doivent cependant être prises, notamment pour éviter les attaques par rejeu. En effet, il est important que le prouveur s’assure que les nonces ne soient jamais réutilisés (en général ou au minimum par un même vérificateur). En effet, si un nonce était réutilisé, il ne serait plus nécessaire d’avoir accès à la clé privée permettant la signature ; il suffirait juste de rejouer la preuve correspondante qui aurait été générée la première fois que ce nonce avait été signé. Un attaquant ou une attaquante pourrait également hameçonner un prouveur dans le cadre d’une attaque par relais. Cette attaque consiste alors à présenter au prouveur le nonce choisi par le vérificateur, récupérer cette preuve et la jouer à son compte auprès du véritable vérificateur.

Pour contrer ces attaques par rejeu ou par relais, la plupart des implémentations font intervenir le prouveur dans le choix du nonce ; le prouveur est alors sûr qu’au moins sa propre contribution à l’établissement du nonce est réellement aléatoire et non rejouée.

Une autre contremesure aux attaques par relais est de s’assurer que le prouveur utilise une clé privée différente par vérificateur. Le prouveur peut utiliser, par exemple, le nom du site web consulté comme discriminant. Ainsi, en cas d’hameçonnage, le site web de l’attaquant ou de l’attaquante ne dispose pas de la même URL et, pour générer la signature, la clé privée utilisée est différente de la clé qui serait utilisée pour le vérificateur légitime. En conséquence, la preuve interceptée par l’attaquant ou l’attaquante n’est pas valide auprès du véritable vérificateur ! Cette parade peut être utilisée en plus de la précédente ; leur combinaison est utilisée par les protocoles WebAuthn, U2F et FIDO2, détaillés ultérieurement dans ce cours.

---
title: Authentification d'un serveur TLS avec confidentialité persistente (simplifiée)
---
sequenceDiagram
  autonumber
  actor peggy as Peggy (Serveur TLS)
  actor victor as Victor (Client TLS)

  victor ->> victor:Tire un nonce

  victor ->> victor:Tire une bi-clé temporaire (DHE)

  victor ->> peggy:"Je voudrais consulter https://broken-by-design.fr. Voici un nonce et une clé publique temporaire"

  peggy ->> peggy:Tire un nonce

  peggy ->> peggy:Tire une bi-clé temporaire (DHE)

  peggy ->> peggy:Prépare le message "Voici un autre nonce"

  peggy ->> peggy:Prépare le message "Voici un certificat pour broken-by-design.fr"

  peggy ->> peggy:Prépare le message "Voici une autre clé publique temporaire"

  peggy ->> peggy:Calcule un condensat cryptographique de l'ensemble des messages échangés et préparés

  peggy ->> peggy:Signe avec sa clé privée le condensat cryptographique

  peggy ->> victor:"Voici un autre nonce"

  peggy ->> victor:"Voici un certificat pour broken-by-design.fr"

  peggy ->> victor:"Voici une autre clé publique temporaire"

  peggy ->> victor:"Voici la signature des messages précédents"

  victor ->> victor:Vérifie l'authenticité du certificat

  victor ->> victor:Calcule le condensat cryptographique de l'ensemble des messages reçus (sauf la signature).

  victor ->> victor:Vérifie la signature cryptographique reçue avec la clé publique du certificat

  alt La signature est valide
    par Calcul des clés par Peggy
      peggy ->> victor:"Top ! À partir de maintenant, échangeons de manière sécurisée."
      peggy ->> peggy:Calcule le PMS et les autres clés
    and Calcul des clés par Victor
      victor ->> peggy:"Top ! À partir de maintenant, échangeons de manière sécurisée."
      victor ->> victor:Calcule le PMS et les autres clés
    end
    victor -> peggy:"#10216;illisible#10217; (vérification de l'intégrité des échanges précédents)"
    victor -> peggy:"#10216;illisible#10217; (échanges métier)"
  else La signature est invalide
    victor ->> peggy:"Je ne crois pas, non"
  end

La preuve par déchiffrement

La preuve par déchiffrement repose sur la capacité du prouveur à démontrer la connaissance d’un secret arbitraire qui lui a été transmis sous une forme chiffrée par le vérificateur.

Pour déchiffrer ce secret arbitraire, le prouveur doit disposer d’une clé symétrique ou d’une clé privée. La clé symétrique peut être issue d’un calcul, comme le résultat d’une fonction de dérivation de mot de passe (voir chapitre sur le stockage des éléments authentifiants pour en apprendre plus sur ces fonctions).

En déchiffrant le secret arbitraire envoyé par le vérificateur, le prouveur démontre qu’il connait la clé de déchiffrement et donc qu’il est celui qu’il prétend être. Cela est pourtant insuffisant pour convaincre le vérificateur, puisque ce dernier ne sait encore rien du résultat de ce déchiffrement. Une nouvelle opération cryptographique est donc nécessaire : le prouveur doit exercer ce secret arbitraire dans une opération cryptographique et envoyer le résultat de cette dernière au vérificateur. Le vérificateur pourra alors vérifier que l’opération cryptographique a bien mis en œuvre le secret qu’il avait envoyé au prouveur.

Les implémentations de cette preuve varient beaucoup. Elle est employée par le protocole Kerberos ou par certaines suites cryptographiques de TLS.

Avec les suites cryptographiques de TLS ne mettant pas en œuvre la confidentialité persistante (perfect forward secrecy (PFS)), le vérificateur (le client TLS) va envoyer au prouveur (le serveur TLS) un secret chiffré avec la clé publique contenue dans le certificat du serveur TLS. Si le serveur TLS est bien en possession de la clé privée associée à la clé publique contenue dans le certificat, il pourra déchiffrer ce secret. Ce secret, appelé “pre-master secret (PMS)” est utilisé ensuite par le vérificateur et le prouveur pour calculer les clés cryptographiques qui seront utilisées pour sécuriser l’ensemble de la communication TLS. Si le prouveur n’a pas été en mesure de déchiffrer le PMS, il ne sera pas en mesure de lire, ni de répondre aux messages chiffrés envoyés par le vérificateur. Si en revanche, il est en mesure de le faire, alors implicitement, il aura prouvé qu’il était en possession de la clé privée et la preuve d’identité sera faite.

---
title: Authentification TLS sans confidentialité persistente (simplifiée)
---
sequenceDiagram
  autonumber
  actor peggy as Peggy (Serveur TLS)
  actor victor as Victor (Client TLS)

  victor ->> victor:Tire un nonce

  victor ->> peggy:"Je voudrais consulter https://broken-by-design.fr. Voici un nonce."

  peggy ->> peggy:Tire un autre nonce

  peggy ->> victor:"Voici un autre nonce"

  peggy ->> victor:"Voici un certificat pour broken-by-design.fr"

  victor ->> victor:Vérifie l'authenticité du certificat reçu

  victor ->> victor:Tire le PMS

  victor ->> victor:Chiffre le PMS avec la clé publique du certificat

  victor ->> peggy:"Voici le PMS chiffré"

  par Peggy indique chiffrer ses communications
      peggy ->> victor:"Top ! À partir de maintenant, échangeons de manière sécurisée."
  and Victor indique chiffrer ses communications
      victor ->> peggy:"Top ! À partir de maintenant, échangeons de manière sécurisée."
  end

  alt Peggy ne connait pas la clé privée
    peggy --x victor:Peggy ne dispose pas des clés pour chiffrer un message pour Victor
  else Peggy connait la clé privée
    peggy ->> peggy:Déchiffre le PMS avec sa clé privée

    par Calcul des clés par Peggy
      peggy ->> peggy:Calcule les autres clés à partir du PMS
    and Calcul des clés par Victor
      victor ->> victor:Calcule les autres clés à partir du PMS
    end

    alt Peggy envoie en premier à Victor un message de vérification des échanges
      peggy ->> peggy:Calcule un condensat cryptographique de tous les messages échangés jusqu'ici
      peggy ->> peggy:Protège le condensat en intégrité et confidentialité avec les clés calculées
      peggy ->> victor:"[Chiffré] Voici le condensat de nos échanges"
      victor ->> victor:Calcule un condensat cryptographique de tous les messages échangés jusqu'ici sauf le dernier reçu
      victor ->> victor:Compare le condensat reçu à celui qu'il a calculé
      alt Les condensats ne correspondent pas
        victor ->> peggy: "Je ne crois pas, non."
      else Les condensats correspondent
        victor ->> victor:Calcule un condensat cryptographique de tous les messages échangés jusqu'ici
        victor ->> victor:Protège le condensat en intégrité et confidentialité avec les clés calculées
        victor ->> peggy:"[Chiffré] Voici le condensat de nos échanges"
        peggy ->> peggy:Calcule un condensat cryptographique de tous les messages échangés jusqu'ici sauf le dernier reçu
        peggy ->> peggy:Compare le condensat reçu à celui qu'il a calculé
        alt Les condensats correspondent
          peggy -> victor:"[Chiffré] Données métier"
        else Les condensats ne correspondent pas
          peggy ->> victor: "Je ne crois pas, non."
        end

      end
    else Victor envoie en premier à Peggy un message de vérification des échanges
      victor ->> victor:Calcule un condensat cryptographique de tous les messages échangés jusqu'ici
      victor ->> victor:Protège le condensat en intégrité et confidentialité avec les clés calculées
      victor ->> peggy:"[Chiffré] Voici le condensat de nos échanges"
      peggy ->> peggy:Calcule un condensat cryptographique de tous les messages échangés jusqu'ici sauf le dernier reçu
      peggy ->> peggy:Compare le condensat reçu à celui qu'il a calculé

      alt Les condensats ne correspondent pas
        peggy ->> victor: "Je ne crois pas, non."
      else Les condensats correspondent
        peggy ->> peggy:Calcule un condensat cryptographique de tous les messages échangés jusqu'ici
        peggy ->> peggy:Protège le condensat en intégrité et confidentialité avec les clés calculées
        peggy ->> victor:"[Chiffré] Voici le condensat de nos échanges"
        victor ->> victor:Calcule un condensat cryptographique de tous les messages échangés jusqu'ici sauf le dernier reçu
        victor ->> victor:Compare le condensat reçu à celui qu'il a calculé
        alt Les condensats correspondent
          victor -> peggy:"[Chiffré] Données métier"
        else Les condensats ne correspondent pas
          victor ->> peggy: "Je ne crois pas, non."
        end
      end
    end
  end

Avec Kerberos, le mot de passe du prouveur est utilisé pour déchiffrer une clé symétrique envoyée par le serveur d’authentification (authentication server (AS)). Cette clé est ensuite utilisée par le prouveur pour chiffrer un message à destination du serveur d’émission de tickets (ticket granting service (TGS)). Ce serveur s’attend à ce que le message soit chiffré avec une clé particulière : celle envoyée chiffrée au prouveur par le serveur d’authentification. Ce mécanisme d’authentification est un peu plus complexe qu’expliqué plus haut, car le rôle de vérificateur est, en fait, endossé par deux acteurs distincts : le serveur d’authentification d’une part, et le serveur d’émission de tickets d’autre part.

---
title: Authentification Kerberos (simplifiée)
---
sequenceDiagram
  autonumber
  actor peggy as Peggy (Client)
  box Serveur(s)
    actor trent as Trent (Serveur d'authentification)
    actor victor as Victor (Serveur d'émission de tickets)
    participant db as Base de données
  end

  peggy ->> trent:"Je suis Peggy.".
  trent ->> db:"C'est quoi la dérivée du mot de passe de Peggy ?"
  db ->> trent:"La dérivée du mot de passe de Peggy est..."
  trent ->> db:"C'est quoi la clé de Victor ?"
  db ->> trent:"La clé de Victor est..."
  trent ->> trent:Tire une clé A
  trent ->> peggy:"[Chiffré avec la dérivée du mot de passe de Peggy] Voici la clé A.
  trent ->> peggy:"[Chiffré avec la clé de Victor] Elle dit s'appeler Peggy. Ce message est valide M secondes/minutes/heures. Voici la clé A."
  peggy ->> peggy:Dérive son mot de passe
  peggy ->> peggy:Déchiffre la clé A avec la dérivée de son mot de passe
  peggy ->> victor:"Trent m'a donné ce message pour toi."
  victor ->> victor:Déchiffre le message de Trent avec sa propre clé
  victor ->> victor:Vérifie la période de validité de ces informations
  alt La période de validité est expirée
    victor ->> peggy:"Je ne crois pas, non."
  else La période de validité est en cours
    peggy ->> victor:"[Chiffré avec la clé A] "Je suis Peggy. Je veux accéder au serveur X."
    victor ->> victor:Déchiffre le message Peggy avec la clé A
    victor ->> victor:Vérifie que le nom Peggy figure bien dans les deux messages déchiffrés
    alt Peggy ne connait pas véritablement la clé A, car c'était le mauvais mot de passe. Son nom ne figure pas dans son message après déchiffrement.
      victor ->> peggy:"Je ne crois pas, non."
    else Peggy connait la clé A. Son nom figure bien dans le message qu'elle a chiffré.
      Note right of victor:Victor continue le protocole avec la partie "autorisation"
    end
  end

La preuve d’identité par déchiffrement est plus complexe à mettre en œuvre et ses assurances de sécurité sont plus faibles que d’autres types de preuves, notamment comme implémentée dans TLS 1.3. En conséquence, cette preuve est de moins en moins utilisée. Il s’agit d’un bel exemple du développement itératif et de l’amélioration continue des protocoles cryptographiques ; beaucoup de ceux conçus dans les années 90 sont désormais écartés au profit de constructions plus récentes et robustes.

La preuve avec divulgation nulle de connaissance

Les mécanismes reposant sur la preuve par divulgation nulle de connaissance (ou sans apport de connaissance) sont assez divers. Le principe commun de tous ces mécanismes est que l’élément secret utilisé par le prouveur n’est à aucun moment divulgué au vérificateur. Ce dernier reçoit la preuve de la connaissance de ce secret, sans obtenir d’information sur le secret !

La divulgation nulle de connaissance semble souvent “magique”. Jean-Jacques Quisquater et Louis Guillou ont publié en 1989 un article de vulgarisation intitulé “Comment expliquer à vos enfants les protocoles sans apport de connaissance”, dont le récit est rapporté et traduit dans un article Wikipedia, et dont la lecture peut se révéler éclairante.³².

Une caractéristique intéressante de la preuve à divulgation nulle de connaissance telle qu’implémentée dans le protocole de Schnorr³³, ou dans celui de Guillou-Quisquater³⁴, est que le vérificateur peut être raisonnablement certain de la preuve³⁵ qui lui est apportée par le prouveur, tout en étant parfaitement incapable de convaincre un tiers de la même chose, a posteriori. Cette propriété est particulièrement intéressante dans le cas d’applications préservant la vie privée et nécessitant d’authentifier un acteur tout en pouvant nier de manière plausible avoir des preuves que cette authentification ait eu lieu.

---
title: Illustration du protocole de Feige–Fiat–Shamir (simplifié)
---
sequenceDiagram
  autonumber
  actor p as Peggy
  box
    actor v as Victor
    participant db as Base de données
  end

  p ->> v:"Je suis Peggy."
  v ->> db:"C'est quoi la clé publique de Peggy ?"
  db ->> v:"La clé publique de Peggy est..."
  v ->> p:"Convaincs moi."
  p ->> p: Se munit de sa clé privée S
  loop Jusqu'à ce que Victor soit convaincu ou que Peggy ne calcule pas correctement
    p ->> p:Tire une valeur aléatoire x, et calcule une fonction D(x) = X
    p ->> v:"Voici X"
    v ->> v:Tire à pile ou face
    v --> p:"Voici le résultat du tirage à pile ou face"
    p ->> p:Calcule la fonction F(S, x, pile ou face) = Y
    p ->> v:"Voici le résultat du calcul"
    v ->> v:Vérifie le calcul avec la clé publique de Peggy avec une fonction G(X, Y, clé publique de Peggy)
    alt Le calcul est correct
      v ->> v:Est un peu plus convaincu
    else Le calcul est incorrect
      v ->> p: "Je ne te crois pas. Fin de conversation."
    end
  end

La preuve par calculs répartis

Par proximité avec les protocoles à divulgation nulle de connaissance, il peut être fait mention également de ceux utilisant des fonctions pseudo-aléatoires oublieuses (oblivious pseudo-random functions (OPRF) ; il n’existe pas de traduction faisant autorité).

Les OPRF sont des fonctions impliquant deux parties qui contribuent aux entrées d’une fonction générant un nombre aléatoire. L’une des parties apprend la valeur de sortie de la fonction, sans avoir appris la contribution de l’autre partie ; et l’autre partie n’apprend rien. La RFC 9497³⁶ décrit une fonction de cette nature. Cette construction est utilisée dans deux protocoles d’authentification très différents : Privacy Pass³⁷ et Opaque³⁸.

Privacy Pass est un protocole d’authentification permettant de prouver non pas une identité individuelle, mais l’appartenance à un groupe d’individus, sans pouvoir distinguer l’individu. Il s’agit bien d’une authentification : un acteur prouve une identité (de groupe) à un vérificateur, qui, en cas de succès, le reconnait bien comme ayant cette identité (d’appartenance à ce groupe). On pourrait, par exemple, imaginer un service de vidéos à la demande payant, qui authentifierait un acteur sans être capable de tracer ce qu’il visionne ; tout ce qu’il saurait, c’est que l’acteur accèdant à la vidéo est à jour de son abonnement. La cryptographie impliquée est un peu avancée pour ce cours, mais le lecteur intéressé pourra en apprendre plus en consultant les documents du groupe de travail “Privacy Pass” de l’Internet Engineering Task Force (IETF).

Opaque, quant à lui, est un protocole d’authentification de la catégorie des Strong Asymmetric Password-based Authenticated Key Exchange (SaPAKE), et utilise donc un mot de passe pour effectuer l’authentification. Il utilise cependant une OPRF afin de permettre de prouver une identité spécifique sans divulguer d’information sur le mot de passe auprès du vérificateur ! L’OPRF est, en effet, utilisée pour calculer une valeur dérivée du mot de passe qui permet le déverrouillage d’un coffre-fort numérique contenant une clé privée. Cette clé privée est ensuite utilisée pour générer la signature d’un défi, comme dans le cas classique des protocoles à signature de défis. L’intérêt d’avoir utilisé une OPRF est que le vérificateur est impliqué dans chaque tentative de déverrouillage du coffre-fort, ce qui lui permet d’empêcher les attaques par recherche exhaustive et de “verrouiller” le compte associé à cette identité si le nombre d’échecs est trop important ! Une fonctionnalité bien utile qui devrait être implémentée par tous les fournisseurs de gestionnaires de mots de passe en ligne synchronisés dans le cloud… De son côté, Whatsapp a mis en œuvre Opaque pour ses sauvegardes chiffrées de bout-en-bout³⁹.

---
title: Authentification avec le protocole Opaque (simplifiée)
---
sequenceDiagram
  autonumber
  actor p as Peggy
  box
    actor v as Victor
    participant db as Base de données
  end

  p ->> p:Tire une valeur aléatoire R
  p ->> p:Calcule 1/R
  p ->> p:Dérive son mot de passe
  p ->> v:"Je suis Peggy."
  p ->> v:"[Chiffré avec R]La dérivée de mon mot de passe est..."
  v ->> p:"Voici ton coffre-fort."
  v ->> v: Se munit de sa clé S
  v ->> p:"[Chiffré avec S][Chiffré avec R]La dérivée de mon mot de passe est..."
  v ->> v: Tire un nonce
  v ->> p:"Voici un nonce"
  p --> p:Déchiffre le message reçu avec 1/R, ce qui donne "[Chiffré avec S]La dérivée de mon mot de passe est..."
  alt Peggy ne connait pas son mot de passe
    Note right of p:Utiliser "[Chiffré avec S]La dérivée de mon mot de passe est..." comme clé ne permet pas de déchiffrer le coffre-fort. "Peggy" ne peut continuer le protocole.
  else
    p ->> p:Utilise "[Chiffré avec S]La dérivée de mon mot de passe est..." comme clé pour déchiffrer le coffre-fort
    p ->> p:Utilise la clé privée contenue dans le coffre pour signer le nonce
    p ->> v:"Voici le nonce signé"
    v ->> db:"C'est quoi la clé publique de Peggy ?"
    db ->> v:"La clé publique de Peggy est..."
    v ->> v:Vérifie la signature du nonce avec la clé publique de Peggy
    alt La signature est valide
      v ->> p:"Bonjour Peggy!"
    else La signature est invalide
      v ->> p:"Je ne crois pas, non."
    end
  end

Du stockage des éléments authentifiants

Pour effectuer l’authentification d’un acteur, le vérificateur a besoin d’avoir accès à une information permettant de vérifier la preuve d’identité. De la nature de la preuve dépend la nature de l’information à stocker côté vérificateur. Le cas le plus typique est celui du mot de passe, mais il en existe d’autres, comme les secrets permettant la génération des codes temporels (TOTP), des clés publiques ou des certificats.

Protocoles reposant sur de la cryptographie à clé publique

Dans le cas où la preuve consiste en une signature numérique vérifiable avec la cryptographie à clé publique, tous les éléments stockés par le vérificateur sont publics par nature ; la seule protection requise est en intégrité, afin de prévenir un attaquant de remplacer les éléments de vérification par les siens. La confidentialité peut néanmoins être un sujet, en particulier si les clés sont réutilisées auprès de plusieurs vérificateurs (voir la section de ce cours dédiée à la réutilisation des moyens de preuve).

Protocole reposant sur de la cryptographie à clé secrète

La cryptographie à clé secrète ou cryptographie symétrique effectue les opérations de vérification avec la même clé que celle qui a permis de créer la preuve. En conséquence, cette clé doit être stockée en clair, sous une forme réversible, ou dans un équipement de sécurité (par exemple, un TPM, un HSM, ou une carte à puce) permettant sa mise en œuvre sans risque d’extraction, copie ou falsification. Ce dernier cas est malheureusement trop rare.

Étant donné que la compromission en confidentialité du stockage du vérificateur permet ensuite l’usurpation de l’identité des acteurs, les protocoles utilisant de la cryptographie à clé secrète sont à éviter, en particulier s’il s’agit de l’unique facteur d’authentification.

C’est le cas notamment des protocoles utilisant les mécanismes de preuve de type challenge/response, comme le mode “digest” de HTTP, spécifié dans la RFC 7616²⁹. C’est également le cas du protocole TOTP, spécifié dans la RFC 6238⁴⁰.

Protocoles reposant sur les mots de passe

Le stockage des mots de passe par le vérificateur est sans doute la problématique liée à l’authentification la plus connue, du fait de la quasi-omniprésence des mots de passe comme méthode d’authentification, des méthodes de stockage qui ont largement évolué à mesure que les techniques d’attaque se sont sophistiquées, et des sanctions de la CNIL qui ont été mises en avant sur ces sujets.

Si le mot de passe de l’utilisateur est stocké en clair par le vérificateur, alors la problématique est la même que lorsqu’est utilisé un protocole reposant sur de la cryptographie à clé secrète.

Une meilleure méthode consiste à stocker non pas le mot de passe lui-même, mais le résultat d’une fonction dite de dérivation au mot de passe. Ce résultat de la dérivée est parfois appelé “empreinte”. Parfois, la fonction de dérivation est appelée “fonction de hachage”, de manière abusive, du fait que nombre de ces dérivations sont faites à l’aide de fonctions de hachage cryptographiques. Il existe de très nombreuses fonctions de dérivation, comme nous le verrons plus loin, avec des niveaux de sécurité assez variables.

Finalement, la meilleure méthode reste encore de ne pas transmettre du tout le mot de passe au vérificateur, mais plutôt d’utiliser le mot de passe pour générer une preuve vérifiable ; cette preuve est alors l’unique élément transmis au vérificateur qui ignore tout du mot de passe de l’acteur ! C’est le cas avec le protocole OPAQUE présenté précédemment dans ce cours.

Concernant la dérivation des mots de passe, les principales attaques sont :

la recherche exhaustive ou guidée (bruteforce) ;
le précalcul ;
le “bourrage” de mots de passe (credential stuffing)⁴¹ ;
“l’épluchage” de mots de passe (credential shucking)⁴².

Pour ce qui est de la recherche exhaustive ou guidée, si le mot de passe est trop faible, la méthode de dérivation utilisée n’aura pas d’incidence sur la difficulté à retrouver le mot de passe. Même avec la meilleure fonction théoriquement possible, le mot de passe “password” sera cassé presque instantanément. Le guide ANSSI “Recommandations relatives à l’authentification multifacteur et aux mots de passe” indique qu’un mot de passe doit avoir une entropie allant de 65 bits à plus de 100 bits en fonction du niveau de risque associé au compte protégé par ce mot de passe. L’entropie est calculée avec le log_2 du nombre de combinaisons possibles d’un jeu de caractères sur une longueur donnée. Par exemple, si un mot de passe est uniquement numérique, et composé de 10 chiffres, alors l’entropie est de 10 puissance 10, et l’entropie est donc log_2(10^10), soit 33 bits.

De même, si l’acteur utilise le même mot de passe auprès de plusieurs vérificateurs, alors la sécurité du stockage de ce mot de passe est équivalente à la sécurité de la méthode de stockage la plus faible employée par l’un de ces vérificateurs. Si cette méthode de stockage est trop faible, alors le mot de passe peut être recouvré puis utilisé auprès d’un vérificateur ayant pourtant une bonne méthode de stockage ; c’est ce qu’on appelle le “bourrage” de mots de passe. Dans ce cas, peu importe la fonction de dérivation employée : le mot de passe peut être cassé en une seule tentative, puisque le mot de passe est en fait déjà connu.

Pour freiner la recherche exhaustive, il convient d’utiliser une fonction de dérivation qui soit raisonnablement couteuse à calculer. Plus la fonction est couteuse, plus il faudra de temps pour retrouver le mot de passe à partir de sa dérivée. Il y a cependant un arbitrage à faire, car pour chaque tentative de vérification d’un mot de passe, le vérificateur devra utiliser cette fonction couteuse également. S’il y a peu d’utilisateurs, comme c’est le cas pour une authentification locale sur un poste de travail, cela ne présente pas un gros problème, mais sur un site web avec des millions d’utilisateurs et d’utilisatrices, le cout peut rapidement devenir prohibitif.

Le précalcul est une attaque qui vise à précalculer un grand nombre de dérivées de mots de passe, et d’indexer efficacement le résultat de ces calculs. Cet index permet d’optimiser le temps nécessaire pour casser les mots de passe dont les dérivées auraient fuité. Plus besoin d’exécuter la fonction de dérivation pour chaque mot de passe à attaquer ! Il suffit de regarder si la dérivée est présente dans l’index, et si oui de regarder quel mot de passe lui correspond. Ces index sont appelés des tables arc-en-ciel (rainbow tables).

Pour contrer le précalcul, une donnée aléatoire spécifique à chaque compte de chaque système d’information doit être ajoutée au mot de passe en entrée de la fonction de dérivation. Cette donnée est parfois appelée “sel” ou “diversificateur”. Plus cette donnée contient d’entropie, plus le cout du précalcul devient élevé. Le guide ANSSI “Recommandations relatives à l’authentification multifacteur et aux mots de passe” préconise une donnée d’au moins 128 bits d’entropie !

Finalement, l’attaque par épluchage des mots de passe consiste à exploiter le fait que la fonction de dérivation soit en fait une composition de plusieurs fonctions de dérivation unitairement moins fortes que leur assemblage. L’exploitation consiste alors à attaquer chacune de ces fonctions individuellement ; si certaines sont trop faibles, alors l’attaquant peut accélérer d’autant sa recherche exhaustive. C’est par exemple ce qui a été reproché par la CNIL à Doctissimo, qui avait utilisé un assemblage MD5+bcrypt.

La fonction de dérivation de mots de passe à l’état de l’art est argon2id. Cette fonction dérive les mots de passe de telle façon que les calculs ne puissent être faits sur des cartes graphiques. Cette propriété est importante, car les recherches exhaustives ont longtemps été faites sur des cartes graphiques, disposant de processeurs capables d’effectuer de très grandes quantités de certains types de calcul, bien supérieures aux processeurs généralistes. Ensuite, argon2id peut consommer de grandes quantités de mémoire lors de la dérivation des mots de passe, ce qui permet d’accroitre encore le cout d’une recherche exhaustive. Finalement, argon2id met en œuvre un certain nombre de précautions pour éviter des attaques par canaux auxiliaires rendus possibles à cause des techniques permettant de faire consommer plus de mémoire : une protection sur la protection, en somme !

Il existe d’autres fonctions, moins efficaces que argon2id, qui peuvent être mentionnées. Par ordre décroissant de protection, il peut être cité : scrypt, bcrypt, PBKDF2. Toutes ces fonctions, comme argon2id, intègrent toutes par conception un diversificateur pour contrer les précalculs.

De la réutilisation des moyens de prouver son identité

L’utilisation d’un même moyen permettant de prouver son identité n’est pas recommandée. Les conséquences sont cependant assez diverses en fonction du moyen.

La réutilisation d’un moyen dans le cadre d’un mécanisme d’authentification par divulgation a des conséquences catastrophiques si le canal de communication ou la sécurité logicielle du prouveur et du vérificateur sont insuffisamment protégés en confidentialité. En effet, l’attaquant ou l’attaquante pourra alors apprendre le secret et le réutiliser en l’état auprès d’un autre vérificateur.

La réutilisation de mots de passe pose également des difficultés relatives au stockage par le vérificateur. Le stockage du mot de passe lui-même, en clair ou sous un format réversible, signifie que l’attaquant ou l’attaquante ayant accès à ce stockage peut apprendre le mot de passe et le réutiliser tel quel auprès d’autres vérificateurs. Même si le stockage ne contient que des dérivées des mots de passe, le risque reste réel si l’entropie de ces mots de passe est trop faible. En effet, ils pourront être retrouvés par recherche exhaustive, avec les mêmes conséquences que s’ils avaient été stockés en clair.

Avec les mécanismes d’authentification utilisant la signature électronique, l’utilisation d’une même clé privée auprès de plusieurs vérificateurs présente également des risques.

D’une part, il arrive que des erreurs d’implémentation permettent à un vérificateur malveillant d’exploiter une vulnérabilité dans le code du prouveur, menant à la divulgation de la clé privée utilisée pour prouver son identité ⁴³⁴⁴.

D’autre part, un attaquant ou une attaquante ayant pu obtenir la liste des clés publiques associées à des identités auprès de divers vérificateurs pourrait relier les identités entre elles. Il ou elle lui serait alors possible de tracer et corréler les activités sur les systèmes d’information accessibles après authentification auprès de ces vérificateurs⁴⁵.

Considérations de sécurité relatives aux moyens de prouver son identité

Fort de toutes les connaissances évoquées dans ce chapitre, il peut sembler difficile de faire le bon choix. Quelles normes, référentiels ou lois s’appliquent ? Quelle force ? Quel protocole ? Faut-il utiliser plusieurs facteurs ? Si oui, lesquels ? Quelles assurances le stockage du vérificateur doit-il fournir ? Quelles assurances le protocole de transport réseau doit-il fournir ? Faut-il utiliser des facteurs physiques comme des cartes à puce ? Si oui, à quel cout ? Qu’utiliser quand on accède à une API ?

Pour ajouter à la complexité technique, il faut ajouter celles relatives aux humains. Quelle solution est la plus acceptable et réaliste ? Est-il réaliste de demander à un humain de mémoriser des mots de passe de plus de 12, voire 16 caractères, générés aléatoirement par une machine et sur 4 classes de caractères ? Que faire si un facteur est perdu ? Comment tenir compte des méthodes de hameçonnage et d’ingénierie sociale, et quel risque leur associer ?

En 2024, les capacités de calcul sont telles que la plupart des humains sont incapables de mémoriser un mot de passe ou une phrase de passe résistant à une attaque par recherche exhaustive, en particulier si la méthode de stockage des dérivées des mots de passe côté vérificateur est insuffisante. Les mauvaises pratiques du milieu⁴⁶ et la complexité d’analyse d’une adresse réticulaire (Uniform Resource Locator (URL)) sont telles que même les spécialistes peinent à distinguer un lien légitime d’un lien redirigeant vers un site d’hameçonnage ⁴⁷.

Ces conclusions ont mené les industries sensibles à déconsidérer les facteurs d’authentification basés sur la connaissance (mots de passe, codes PIN, jetons d’authentification), nécessitant un stockage assurant la confidentialité (HTTP digest, etc.) et ceux qui sont vulnérables aux attaques par rejeu ou par relais (mécanisme de preuve par divulgation (dont les TOTP), codes TAN, clés privées réutilisées auprès de plusieurs vérificateurs…). D’un autre côté, rares sont les organismes qui disposent du budget nécessaire pour fournir à tous leurs utilisateurs et utilisatrices des facteurs de possession tels que des cartes à puce, des clés USB implémentant U2F ou FIDO2, ou même des téléphones portables (Duo Push, Microsoft Authenticator). Ces moyens sont généralement réservés au public sensible, comme les équipes de sécurité et les équipes opérationnelles et d’administration.

Pour ces raisons, des mécanismes d’authentification reposant sur le standard W3C WebAuthn⁴⁸ et utilisant des stockages logiciels plutôt que physiques (soft tokens) ont émergé, avec l’avènement des passkeys en 2023, principalement sous l’impulsion de Google, Apple et Microsoft.

Les passkeys sont des clés utilisées dans le cadre du protocole WebAuthn. Ce protocole prévoit qu’une clé privée distincte soit utilisée par chaque vérificateur (relying party dans la norme). Pour cela, WebAuthn utilise un identifiant unique (Uniform Resource Identifier (URI)) pour distinguer les vérificateurs, le cas typique étant l’adresse réticulaire (URL) du site web demandant une authentification. Chacune de ces clés privées est stockée dans un coffre-fort auquel le prouveur pourra avoir accès sur demande. Pour éviter l’inconvénient de la perte, ce coffre-fort est généralement synchronisé dans le cloud ; c’est le cas, par exemple, pour les passkeys gérées par Apple (stockage dans iCloud) ou par Bitwarden (stockage dans le coffre-fort de mots de passe). L’utilisateur ou l’utilisatrice n’a alors qu’à s’authentifier auprès du service qui stocke ce coffre-fort pour récupérer l’ensemble de ses passkeys.

Contrairement aux mots de passe qui pourraient être stockés dans ces mêmes coffres-forts, les passkeys sont par conception :

un mécanisme d’authentification forte, employant des clés cryptographiques ;
un mécanisme d’authentification multifacteur, puisqu’un ou plusieurs facteurs d’authentification sont nécessaires pour déverrouiller le coffre-fort contenant les passkeys ;
unique à chaque vérificateur, sans réutilisation, ce qui les immunise aux attaques par relais⁴⁹ et aux hameçonnages.

Contrairement aux facteurs de possession physiques, les passkeys sont par conception :

immunisées à la perte ;
peu onéreuses.

Enfin, les passkeys étant uniques à chaque vérificateur, elles offrent des propriétés intéressantes pour la vie privée. En effet, il n’existe aucun lien entre deux clés privées distinctes. Cela empêche donc plusieurs vérificateurs de se liguer en vue de tracer et corréler les activités d’un même utilisateur ou d’une même utilisatrice sur leurs systèmes d’information respectifs.

---
title: Authentification avec WebAuthn (simplifiée)
---
sequenceDiagram
  autonumber
  box Client
    actor p as Peggy
    participant cf as Coffre-fort
    participant b as Navigateur
  end
  box Serveur
    participant v as Victor
    participant db as Base de données
  end

  p ->> b:"Je suis Peggy. Je veux accéder à https://broken-by-design.fr/"
  b --> v:"Je suis Peggy. Je veux accéder à https://broken-by-design.fr/"
  v ->> v:Tire un nonce
  v ->> b:"Prouve le. Voici un nonce."
  p ->> cf:Déverrouille son coffre-fort, par exemple avec un mot de passe
  b ->> cf:"Je visite https://broken-by-design.fr et voici le nonce"
  cf ->> cf:Vérifie que Peggy a déverrouillé le coffre-fort il y a peu (*user verification*)
  cf ->> cf:Récupère la clé associée à https://broken-by-design.fr/
  cf ->> cf:Signe le nonce et le site visité
  cf ->> b:"Voici la signature"
  b ->> v:"Voici la signature"
  v ->> db:"C'est quoi la clé publique de Peggy ?"
  db ->> v:"Voici la clé publique de Peggy"
  v ->> v: Vérifie la signature
  alt La signature est valide
    v ->> b:"Bonjour Peggy!"
    b ->> p:"Bonjour Peggy!"
  else La signature est invalide
    v ->> b: "Je ne pense pas, non."
    b ->> p: "Je ne pense pas, non."
  end

Autorisation

L’autorisation est le fait d’accorder ou non, à un sujet (c’est-à-dire un acteur, une organisation, ou un groupe), à l’issue d’un contrôle d’accès, les droits, permissions ou privilèges, lui permettant d’effectuer une activité sur un objet ou une vue.

Derrière cette définition assez générique se cachent des réalités simples et intuitives, mais aussi des modèles de sécurité permettant l’application de politiques plus ou moins abstraites (modèles de Bell-Lapadula, Biba, Clark-Wilson, Multilevel Security (MLS)…). Ce chapitre détaillera ces différents modèles.

Étiquetage explicite ou intrinsèque

Les sujets, actions et objets soumis à un système de contrôle d’accès ont besoin d’être identifiés de manière à pouvoir y faire référence lors de l’écriture de règles de contrôle d’accès.

Pour les sujets, nous avons déjà discuté assez largement de la manière de les identifier dans ce cours.

Pour ce qui est des objets, l’identification peut être effectuée de manière explicite, par l’ajout d’une étiquette (label). Cette étiquette peut décrire une identité individuelle pour cet objet. Néanmoins, la plupart du temps, il s’agit plutôt d’une identité d’appartenance à un groupe. Par exemple, il pourrait s’agir d’une étiquette “objets correspondant à des données bancaires” ou “objets contenant des données personnelles”.

L’étiquetage s’effectue généralement par l’ajout d’une métadonnée associée à l’objet. Sous Linux, cela s’effectue le plus souvent avec les attributs étendus⁵⁰.

L’étiquetage est le système le plus répandu d’identification des objets, mais il est également possible d’identifier un objet de manière intrinsèque, par exemple en fonction de son nom ou de sa localisation. Ce système est notamment utilisé par le Linux Security Module (LSM) AppArmor qui définit des politiques de sécurité sur des fichiers en fonction de leur chemin d’accès dans le système de fichiers. Un autre exemple est le contrôle d’accès sur un site web, en fonction de la section “chemin” d’une adresse réticulaire (URL Path).

Contrôle d’accès discrétionnaire (DAC)

La plupart des personnes manipulant un ordinateur sont familières avec le contrôle d’accès discrétionnaire (DAC), même si la désignation leur est inconnue.

Ce type de contrôle d’accès consiste à laisser la liberté au propriétaire d’un objet de déterminer les droits d’accès à ce dernier. C’est le modèle de contrôle d’accès par défaut sous Linux, avec les appels système chown(2) et chmod(2) qui permettent respectivement de changer le propriétaire d’un fichier et les droits (lecture, écriture, exécution) qui sont associés à l’utilisateur propriétaire, à un groupe d’utilisateurs, et aux autres utilisateurs.

Ce contrôle d’accès est parfaitement adapté pour la gestion du contrôle d’accès à des données personnelles. Néanmoins, dans une entreprise, le contrat de travail contient quasi systématiquement une clause de cession des droits patrimoniaux de l’ensemble des productions du personnel. Pour le dire plus vulgairement, l’entreprise est la propriétaire des documents produits. Comme il n’est pas raisonnable d’attendre du chef ou de la cheffe d’entreprise de prendre toutes les décisions d’attribution des droits, des politiques de sécurité sont établies, qui s’appliquent ensuite de manière verticale sur l’ensemble des objets produits par le personnel de l’entreprise. L’étiquetage entre alors en jeu.

Contrôle d’accès obligatoire (MAC)

Le contrôle d’accès obligatoire (Mandatory Access Control) a parfois été incorrectement appelé “contrôle d’accès mandataire” par les agents du gouvernement français, probablement pour des raisons de proximité phonétique avec “mandatory”…

Ce type de contrôle d’accès consiste en l’établissement d’une politique de sécurité qui s’applique de manière verticale à l’ensemble des sujets, des actions et des objets d’un système d’information.

Les politiques sont des descriptions abstraites des relations entre les sujets, les actions et les objets. Bien qu’elles puissent établir des règles à propos de sujets ou d’objets individuels spécifiques, elles portent plus généralement sur des étiquettes pouvant être associées à plusieurs sujets ou objets.

Les modèles théoriques

Les modèles de MAC classiques

La littérature contient de nombreuses variantes et approches au contrôle d’accès obligatoire. Certaines sont assez intuitives, par exemple en attribuant des rôles aux sujets (Role-based Access Control (RBAC)). D’autres approches utilisent des attributs arbitraires associés aux sujets, actions ou objets (Attribute-based Access Control (ABAC)), ou encore des informations contextuelles à propos du sujet (Context-based Access Control (CBAC)) : (heure d’accès, géolocalisation, capacités du terminal, force de l’authentification, etc…).

OrBAC

Certaines approches au contrôle d’accès obligatoires rajoutent des couches d’abstraction supplémentaires, en bâtissant sur ceux déjà cités. Par exemple, le modèle de contrôle d’accès fondé sur l’organisation (Organization-based Access Control (OrBAC)) repose sur les approches par rôles (RBAC), par actions (Task-based Access Control (TBAC)), par vues (View-based Access Control (VBAC)) et par équipes (Team-based Access Control (TBAC, à nouveau…)). Le modèle OrBAC abstrait le triplet “sujets, action, objets” en un nouveau triplet “rôles, activités, vues”.

Des règles de contrôle d’accès peuvent alors être écrites concernant ce nouveau triplet en faisant abstraction du contexte d’implémentation, c’est-à-dire de l’organisation (société, association, etc.) pour laquelle elles sont écrites. Cela permet ainsi de les écrire une fois pour toutes, pour un nombre arbitraire d’organisations qui y auront recours.

Une couche de “traduction” spécifique à chaque organisation doit alors être utilisée pour transposer ces règles abstraites en des règles pragmatiques concernant des acteurs, les actions et les objets de chaque organisation.

Sécurité multiniveau

L’approche par sécurité multiniveau (Multilevel Security (MLS)) est assez ancienne. Elle est particulièrement appréciée dans les domaines militaires et gouvernementaux, du fait de la verticalité intrinsèque de cette approche. Néanmoins, cette approche a également ses mérites en dehors du domaine exécutif. Elle est, par exemple, intéressante pour la centralisation des données de santé (monitoring) et de journalisation d’un système d’information.

Le principe général de la sécurité multiniveau est, en effet, d’établir une hiérarchie de niveaux d’autorisation. Les acteurs associés à un niveau sont alors autorisés à effectuer un jeu d’actions restreint avec les objets associés aux niveaux situés en dessous du niveau de l’acteur. Un autre jeu d’actions, généralement distinct et disjoint, est également autorisé pour cet acteur avec les objets associés aux niveaux situés au-dessus du niveau de l’acteur.

Parmi les modèles de sécurité reposant sur la sécurité multiniveau, on peut notamment citer le modèle de Bell-Lapadula⁵¹, le modèle Biba⁵², ou encore celui de Clark-Wilson⁵³.

Le modèle Bell-Lapadula

Le modèle Bell-Lapadula utilise la sécurité multiniveau à des fins de confidentialité. Le principe général est qu’un acteur situé à un certain niveau de sécurité ne peut qu’écrire aux niveaux supérieurs et ne peut que lire aux niveaux inférieurs. En anglais, on parle d’une approche “Write Up, Read Down (WURD)”. Avec cette approche, les acteurs de la hiérarchie peuvent concentrer les informations confidentielles, sans qu’aucune information notamment agrégée ne puisse redescendre.

Ce modèle est implémenté dans Linux à l’aide de SElinux (Security-Enhanced Linux), qui dispose d’une fonctionnalité multiniveau grâce aux étiquettes de niveaux de sensibilité.

Le modèle Biba

Le modèle Biba utilise la sécurité multiniveau à des fins d’intégrité. Le principe général est comparable à celui de Bell-Lapadula, bien qu’il soit en quelque sorte inversé. Avec le modèle Biba, il n’y pas d’écriture aux niveaux supérieurs, et pas de lecture aux niveaux inférieurs. Ainsi, les niveaux les plus privilégiés sont protégés de toute interférence ou corruption de la part des niveaux inférieurs. En anglais, on parle d’une approche “Read Up, Write Down (RUWD)”.

Ce modèle peut être adroitement utilisé conjointement avec le modèle de Bell-Lapadula afin d’agréger des données confidentielles au niveau du commandement, et permettre ensuite au commandement de faire redescendre des ordres qui sont fonction de ces données agrégées.

Le modèle de Clark-Wilson

Le modèle de Clark-Wilson s’intéresse également à l’intégrité. Son approche est plus dynamique et modélise le triplet “sujet,programme, objets”. Ce triplet signifie que les sujets ne peuvent manipuler les objets que par des programmes spécifiques. Ceci est plus restrictif que dans les autres modèles où le contrôle d’accès s’effectue en fonction de l’acteur, sans tenir compte de comment il y accède.

Ce modèle est notamment implémentable sous Linux grâce aux politiques de contrôles des types (type enforcement (TE)) de SElinux. Le type enforcement permet d’associer notamment à chaque utilisateur système ou rôle (ce qui est une autre notion de SElinux), à chaque programme exécutable, à chaque fichier, à chaque socket un type. Une politique TE régit ensuite les interactions entre les types (écriture, lecture, exécution, modification des métadonnées, etc.), ainsi que les transitions entre les types : tel utilisateur de type W peut exécuter un programme de type X, ce qui lui permet de lire les fichiers de type Y et d’écrire les fichiers de type Z.

Modèle de Brewer et Nash ou de la muraille de Chine

Le modèle de Brewer et Nash consiste à appliquer une politique de sécurité permettant de prévenir les conflits d’intérêts, notamment en matière commerciale. Dans ce modèle, le contrôle d’accès est dynamique ; par défaut l’acteur a virtuellement accès à toutes les données. Néanmoins, en fonction des données auxquelles il accède, il se voit au fur et à mesure restreindre l’accès à d’autres données. Par exemple, si les sociétés A et B sont concurrentes, accéder aux données de la société A fait que l’on perdra automatiquement les accès aux données de la société B.

Un exemple d’implémentation de ce modèle est l’outil StemJail⁵⁴ pour Linux, développé par Mickaël Salaün (ANSSI), avec Marion Daubignard (ANSSI) et sous la coulpe d’Hérvé Debar (SudParis Télécom), dans le cadre de la thèse de doctorat de Mickaël.

Des rôles et des groupes

Avec l’approche Role-based Access Control (RBAC), des rôles sont attribués à des sujets. Comme vu précédemment dans ce cours, le terme de sujet recouvre plusieurs réalités : des acteurs mais aussi des groupes d’acteurs. Or, dans certaines définitions de ce que sont les rôles, il est retenu que les rôles sont des groupes d’acteurs et de permissions, tandis que d’autres définitions retiennent que les rôles sont des collections de permissions⁵⁵. Ainsi, certaines implémentations considérant que les rôles sont des groupes d’acteurs et de permissions n’implémentent pas du tout la notion de groupes d’acteurs (sans permissions), considérant celle-ci redondante avec celle des rôles. Pour rajouter un peu de confusion, certaines implémentations ne nomment pas les rôles “rôles” mais “groupes” (e.g. Gitlab) ou “équipes” (e.g. Gitea/Forgejo).

D’une manière générale, il est fortement déconseillé d’attribuer des permissions à des acteurs de façon nominative, à moins qu’il ne soit possible de placer un commentaire explicite à côté de ces permissions accordées nominativement, afin de justifier leur attribution.

Prenons l’exemple d’un personnel d’entreprise, inspiré d’un cas réel : au cours de sa vie professionnelle au sein de cette entreprise, ce personnel intègre une équipe de développement et obtient les permissions nécessaires à l’accomplissement de son affectation. Plus tard, ce même personnel réoriente sa carrière et devient ingénieur avant-vente, et se voit attribuer en conséquence de nouvelles permissions pour l’accomplissement de sa nouvelle affectation. Finalement, ce personnel bascule totalement dans l’équipe commerciale, et obtient encore de nouvelles permissions. Comme prévu dans la politique de sécurité de la société, les permissions sont auditées annuellement, afin de s’assurer que personne ne détient des permissions indues. Lorsque la personne en charge de l’audit vérifiera les permissions de ce personnel, il lui sera très difficile de s’assurer de la légitimité de chaque permission unitaire sans investigation. Si les permissions avaient été accordées en fonction de l’appartenance ou non à un groupe d’acteurs, il suffirait de contrôler la pertinence de l’appartenance aux groupes des développeurs, des avant-ventes et des commerciaux.

En conséquence, même lorsque la notion de rôles est celle de groupes d’acteurs et de permissions, il est fortement conseillé de créer des rôles composés uniquement d’acteurs et de rôles composés exclusivement de permissions et de créer une hiérarchie entre ces rôles, de façon à ce que les rôles “groupes” héritent des permissions des rôles “permissions”.

OAuth2, OpenID Connect et assertions de sécurité

Les protocoles OAuth2 et OpenID Connect sont détaillés dans cette section en préparation du TP compagnon de ce cours. Il existe d’autres protocoles d’autorisation, comme Kerberos ou SAML, qui ne seront pas abordés dans ce cours, mais qui offrent des propriétés de sécurité intéressantes ou comparables.

OAuth2

OAuth2 est un protocole standard d’autorisation, extensible, principalement utilisé dans le contexte web. Une partie de sa spécification, ce qui est appelé le “cadriciel OAuth2” (framework), repose dans la RFC 6749⁵⁶. Cette RFC est également completée par les RFC 6750⁵⁷ et 8252⁵⁸. Le principe général d’OAuth2 repose sur un protocole impliquant quatre participants :

une personne propriétaire d’une ressource (en anglais “resource owner”);
un serveur de ressources (en anglais “resource server”);
une tierce partie souhaitant obtenir accès à cette ressource ; il s’agit généralement d’une application (en anglais “client” ou “relying party”);
un serveur d’autorisation (en anglais “authorization server).

---
title: Représentation simplifiée des interactions entre les parties du protocole OAuth2
---
sequenceDiagram
  autonumber
  actor p as Propriétaire
  actor a as Serveur d'autorisation
  actor r as Serveur de ressources
  actor c as Client

  c ->> r:"Je souhaite accéder à la ressource X."
  r ->> c:"Il faut un jeton d'accès. Va voir le serveur d'autorisation."
  c ->> a:"J'aurais besoin d'un jeton d'accès pour la ressource X. Je redirige le propriétaire vers toi."
  a ->> p:"T'es qui ?"
  p ->> a:"Je suis Peggy, et en voici la preuve."
  a ->> a:Vérifie la preuve.
  a ->> p:"OK, Peggy. J'ai ce Client qui voudrait accéder à X dont tu es propriétaire. T'en penses quoi ?"
  p ->> a:"OK pour donner accès à Client à la ressource X."
  a ->> c:"OK, voici un jeton d'accès pour X."
  c ->> r:"Je souhaite accéder à la ressource X. Voici le jeton d'accès."
  r ->> r:Vérifie le jeton d'accès.
  alt Le jeton d'accès est valide
    r ->> c:"Voici la ressource X."
  else Le jeton d'accès est invalide, forgé ou expiré
    r ->> c:"Accès refusé."
  end

Le serveur de ressources et le serveur d’autorisation ont établi une relation de confiance au préalable. Cette relation de confiance permet au serveur de ressources de reconnaitre et vérifier des jetons d’accès émis par le serveur d’autorisation.

De même, la personne propriétaire d’une ressource a préalablement établi une relation de confiance avec le serveur d’autorisation ; elle est notamment capable de lui prouver son identité, d’une part, et de le convaincre qu’elle est propriétaire d’une certaine donnée, d’autre part.

Finalement, la tierce partie et le serveur d’autorisation ont également préalablement établi une relation de confiance qui permet à la tierce partie de prouver son identité au serveur d’autorisation.

Ainsi, lorsque la tierce partie manifeste le besoin d’accéder à la ressource, elle sollicite le serveur d’autorisation pour obtenir un jeton d’accès et s’authentifie auprès de lui. Après avoir vérifié l’identité de la personne propriétaire de la ressource, le serveur d’autorisation lui demande l’accord pour délivrer un jeton d’accès à cette ressource pour cette tierce partie spécifique. En cas d’accord, un jeton est délivré. La tierce partie peut alors contacter le serveur de ressources et présenter le jeton d’accès. Le serveur de ressources vérifie le jeton d’accès, et s’il est valide, donne accès à la ressource.

Ce protocole permet de délivrer des autorisations d’accès à des ressources protégées, avec une granularité réglable, sans révéler à la tierce partie l’identité ou les moyens d’identification (les “authentifiants”) du propriétaire de la ressource. De surcroit, ce protocole permet de délivrer à la tierce partie des jetons d’accès à usage restreint : ils sont incessibles et potentiellement limités dans le temps.

Une critique récurrente qui peut être adressée contre le cadriciel d’OAuth2 est la multitude de ces modes opératoires, certains étant par essence d’une sécurité relativement douteuse. C’est notamment le cas du mode implicite, ou lorsque sont utilisés des clients “publics”. Ce cours ne rentrera pas plus avant dans ces considérations, mais de plus amples informations peuvent être trouvées dans la RFC de référence, à la section “Considérations de sécurité”.

Une utilisation “abusive” ou “détournée” du protocole d’OAuth2 est souvent constatée pour l’authentification décentralisée. Dans ce contexte d’usage, le serveur de ressources et le serveur d’autorisation sont la même entité. Lorsqu’une personne veut s’authentifier auprès d’une application tierce, elle demande à cette application de demander une autorisation d’accès au serveur d’autorisation. Le serveur d’autorisation demande à cette personne de s’authentifier, puis renvoie à la tierce partie un jeton d’accès pour une ressource quelconque contenant une information identifiant la personne qui s’est authentifiée. Si la tierce partie est en mesure d’obtenir cette ressource grâce au jeton d’accès, alors elle peut déduire que la personne a été capable de prouver son identité au serveur d’autorisation.

Cette utilisation abusive a été normalisée par une extension au protocole OAuth2 : OpenID Connect.

OpenID Connect

OpenID Connect (OIDC)⁵⁹ est une extension au protocole OAuth2. Elle rajoute notamment une couche d’identité, qui permet de normaliser la communication de l’identité d’une personne connue du serveur OIDC à la tierce partie (appelée en anglais relying party), et de fournir également des informations complémentaires à son sujet. Ces informations sont appelées des assertions (claims), qui peuvent être de nature arbitraire, tant qu’elles sont exprimables dans le format JWT (JSON Web Token)⁶⁰.

Le principe général d’OAuth 2 est appliqué avec OpenID Connect. La différence majeure est que le serveur d’autorisation est également le serveur de ressources, et que la ressource consultée est un document appelé “ID Token”, contenant des assertions relatives à la personne s’étant authentifiée au serveur d’autorisation.

Le document ID Token contient diverses assertions requises ou optionnelles. Les assertions requises sont :

iss : “issuer” : l’identifiant de l’émetteur de cet ID Token ;
sub : “subject” : l’identifiant de la personne cherchant à prouver son identité à la tierce partie ;
aud : “audience” : l’identifiant de la tierce partie ;
exp : “expiry date” : la date d’expiration de cet ID Token ;
iat : “issued at” : la date d’émission de cet ID Token.

Les assertions suivantes sont parfois requises, parfois optionnelles :

auth_time : “authentication time” : heure de la dernière authentification réussie de la personne cherchant à prouver son identité à la tierce partie auprès du serveur OpenID Connect. Cette assertion est requise si l’application tierce a explicitement exprimé le besoin d’en connaitre à propos cette information.
nonce : une valeur arbitraire ajoutée à l’ID Token à la demande de la tierce application, en vue de contrer des attaques par rejeu éventuelles.

Les serveurs OpenID Connect peuvent être généralement configurés pour ajouter des assertions additionnelles arbitraires. Certaines peuvent ainsi spécifier les groupes auxquels appartient le sujet de l’ID Token ou les rôles dont il disposerait.

User-managed Access

User-managed Access (UMA) est une autre extension au protocole OAuth2. Spécifiée par la Kantara Initiative⁶¹, elle permet au propriétaire d’une ressource d’établir à l’avance des règles régissant l’émission de jetons d’accès à cette ressource. L’application tierce sera alors autonome pour obtenir des jetons d’accès à cette ressource sous réserve de satisfaction des règles édictées par le propriétaire et sans interaction explicite avec ce dernier.

Cette extension permet notamment la création d’un référentiel central d’autorisation, seule source de vérité des autorisations d’accès sur l’ensemble des ressources d’un système d’information.

Hélas, s’il y a bon nombre de fournisseurs de service pour le protocole UMA, son adoption par les applications tierces est encore modeste.

Remerciements

Je tiens à remercier mes relecteurs et relectrices pour leurs contributions à ce cours. Un merci tout spécial à @karl@infosec.exchange et @bortzmeyer@mastodon.gougere.fr pour leurs suggestions d’amélioration nombreuses et détaillées.

Le contenu de ce cours ne saurait les engager.

Licence

Ce cours est publié sous licence CC-BY.

Vous êtes autorisé à :

Partager — copier, distribuer et communiquer le matériel par tous moyens et sous tous formats pour toute utilisation, y compris commerciale.
Adapter — remixer, transformer et créer à partir du matériel pour toute utilisation, y compris commerciale.

L’Offrant ne peut retirer les autorisations concédées par la licence tant que vous appliquez les termes de cette licence.

Selon les conditions suivantes :

Attribution — Vous devez créditer l’Œuvre, intégrer un lien vers la licence et indiquer si des modifications ont été effectuées à l’Œuvre. Vous devez indiquer ces informations par tous les moyens raisonnables, sans toutefois suggérer que l’Offrant vous soutient ou soutient la façon dont vous avez utilisé son Œuvre.
Pas de restrictions complémentaires — Vous n’êtes pas autorisé à appliquer des conditions légales ou des mesures techniques qui restreindraient légalement autrui à utiliser l’Œuvre dans les conditions décrites par la licence.

https://github.com/linux-pam/linux-pam ↩︎
https://www.rfc-editor.org/rfc/rfc4511.html ↩︎
https://learn.microsoft.com/fr-fr/windows-server/identity/ad-ds/plan/using-the-organizational-domain-forest-model ↩︎
https://en.wikipedia.org/wiki/Virtual_directory ↩︎
https://openid.net/developers/how-connect-works/ ↩︎
https://wiki.oasis-open.org/security/FrontPage ↩︎
https://cyber.gouv.fr/secnumcloud-pour-les-fournisseurs-de-services-cloud ↩︎ ↩︎
version 3.2, chapitre 9.6, alinéa a ↩︎
https://www.legifrance.gouv.fr/cnil/id/CNILTEXT000046693390 ↩︎
https://www.legifrance.gouv.fr/cnil/id/CNILTEXT000042203965/ ↩︎
https://www.legifrance.gouv.fr/cnil/id/CNILTEXT000047552103 ↩︎
https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32014R0910 ↩︎
https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=celex%3A32015L2366 ↩︎
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000035430451 ↩︎
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000035407334/ ↩︎
https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eIDAS+eID+Profile ↩︎
https://eur-lex.europa.eu/legal-content/FR/ALL/?uri=CELEX:32015R1502 ↩︎ ↩︎
https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000035720606 ↩︎
https://cyber.gouv.fr ↩︎
https://cyber.gouv.fr/lidentification-electronique ↩︎
https://cyber.gouv.fr/le-referentiel-general-de-securite-version-20-les-documents ↩︎
https://cyber.gouv.fr/publications/recommandations-relatives-lauthentification-multifacteur-et-aux-mots-de-passe ↩︎
https://www.cloudflare.com/fr-fr/learning/bots/what-is-credential-stuffing/ ↩︎
https://jankrissler.blogspot.com/2016/09/hacker-fakes-german-ministers.html ↩︎
https://en.wikipedia.org/wiki/Trusted_Platform_Module ↩︎
https://en.wikipedia.org/wiki/Hardware_security_module ↩︎
https://www.lemagit.fr/conseil/Key-Management-System-KMS-une-pierre-angulaire-du-chiffrement ↩︎
https://heartbleed.com/ ↩︎
https://www.rfc-editor.org/rfc/rfc7616.html ↩︎ ↩︎
Une des propriétés de sécurité attendues des fonctions de hachage cryptographiques est qu’il soit virtuellement impossible de déterminer, autrement que par la recherche exhaustive, une valeur qui, passée à la fonction de hachage en entrée, produirait un résultat connu. ↩︎
Le serveur peut également stocker une dérivée du mot de passe, mais pour ce protocole, cette dérivée de mot de passe a la même sensibilité que le mot de passe lui-même : le connaitre est suffisant pour s’authentifier. ↩︎
https://fr.wikipedia.org/wiki/Preuve_%C3%A0_divulgation_nulle_de_connaissance#La_grotte_d'Ali_Baba ↩︎
https://fr.wikipedia.org/wiki/Protocole_d%27authentification_de_Schnorr ↩︎
https://fr.wikipedia.org/wiki/Guillou-Quisquater ↩︎
Les protocoles à divulgation nulle de connaissance sont des protocoles probabilistes. Le vérificateur ne dispose jamais d’une preuve formelle de l’identité ; il acquiert juste une conviction reposant sur une probabilité écrasante que le prouveur connait ou possède le secret prouvant son identité. Le seuil de probabilité à partir duquel il est convaincu est paramétrable et à la discrétion du vérificateur. ↩︎
https://www.rfc-editor.org/rfc/rfc9497.html ↩︎
https://datatracker.ietf.org/wg/privacypass/documents/ ↩︎
https://eprint.iacr.org/2018/163.pdf ↩︎
https://www.whatsapp.com/security/WhatsApp_Security_Encrypted_Backups_Whitepaper.pdf ↩︎
https://www.rfc-editor.org/rfc/rfc6238.html ↩︎
https://www.cloudflare.com/fr-fr/learning/bots/what-is-credential-stuffing/ ↩︎
https://www.scottbrady91.com/authentication/beware-of-password-shucking ↩︎
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0777 ↩︎
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31497 ↩︎
https://words.filippo.io/dispatches/whoami-updated/ ↩︎
Il semble très difficile d’astreindre les départements marketing et communications à utiliser uniquement des noms de domaine bien identifiés, que les utilisateurs et utilisatrices finaux sont habitués à reconnaitre… ↩︎
https://github.com/orangetw/My-Presentation-Slides/blob/main/data/2019-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdfs ↩︎
https://www.w3.org/groups/wg/webauthn/publications/ ↩︎
Le standard WebAuthn requiert la vérification de l’identité du vérificateur. Cette vérification est généralement faite à l’aide de TLS et de l’infrastructure de gestion de clés “web”. Si un attaquant réussit à disposer de la clé privée associée à un certificat légitime pour un vérificateur donné, alors il sera en mesure d’effectuer tout de même des attaques relais. WebAuthn dispose d’une mécanique appelée “channel binding” ou “token binding” permettant de prévenir totalement les attaques par relais, mais cette fonctionnalité n’a jamais été implémentée à large échelle. ↩︎
https://man7.org/linux/man-pages/man7/xattr.7.html ↩︎
https://websites.umich.edu/~cja/LPS12b/refs/belllapadula1.pdf ↩︎
https://www.researchgate.net/publication/235043659_Integrity_Considerations_for_Secure_Computer_Systems ↩︎
https://groups.csail.mit.edu/ana/Publications/PubPDFs/A%20Comparison%20of%20Commercial%20and%20Military%20Computer%20Security%20Policies.pdf ↩︎
https://stemjail.github.io/ ↩︎
https://profsandhu.com/workshop/role-group.pdf ↩︎
https://www.rfc-editor.org/rfc/rfc6749.html ↩︎
https://www.rfc-editor.org/rfc/rfc6750.html ↩︎
https://www.rfc-editor.org/rfc/rfc8252.html ↩︎
https://openid.net/developers/specs/ ↩︎
https://www.rfc-editor.org/rfc/rfc7519.html ↩︎
https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html ↩︎

Identité et méthodes d'authentification : TP

Mon, 26 Feb 2024 00:00:00 +0200

TP

Ce TP consiste à mettre en place un référentiel d’identités et un service qui utilisera ce référentiel pour effectuer l’authentification décentralisée de ces utilisateurs et utilisatrices. Ce service sera la forge logicielle Forgejo et le référentiel d’identités sera Keycloak.

Le référentiel d’identités sera configuré pour permettre l’authentification sans mot de passe, à l’aide de WebAuthn et de passkeys.

Pour stocker et gérer les passkeys, nous aurons recours à Bitwarden et son extension navigateur d’une part et à un serveur Vaultwarden d’autre part. Vaultwarden est un serveur libre compatible avec l’API de Bitwarden. Il nous permet d’effectuer ce TP sans “polluer” les serveurs Bitwarden officiels avec des comptes créés pour ce TP.

L’authentification avec WebAuthn nécessite que les sites soient servis sur HTTPS. Pour cette raison, nous allons mettre en place un serveur HTTPS qui tiendra lieu de serveur mandataire inverse (reverse proxy).

Ajouter une adresse IP dédiée au TP

(Action) Ajouter une adresse IP locale dédiée pour le TP. Bloquer le cas échéant les connexions depuis le réseau externe.

Sur Linux, ajouter une interface de type dummy et configurer une adresse IP dédiée pour le TP. Par exemple, 10.108.0.1.

sudo ip l a dummy0 type dummy
sudo ip a a 10.108.0.1 dev dummy0
sudo ip l s dummy0 up

Sur Windows et Mac, trouver une manière de faire…

Installation du serveur mandataire inverse

Avant toute chose, il convient de configurer le serveur mandataire, et de configurer notre navigateur internet afin qu’il fasse confiance aux certificats émis par ce serveur mandataire. Pour ce faire, nous allons utiliser Caddy.

Caddy est un serveur qui peut à la fois jouer le rôle de serveur HTTP, mais aussi assurer la gestion d’une infrastructure de gestions de clés (IGC), et même délivrer des certificats à l’aide du protocole ACME¹.

Le conteneur Caddy a besoin d’exposer le port 443. Il stocke ses fichiers relatifs à l’IGC dans un volume qui doit être monté sur le chemin /data. Finalement, sa configuration est effectuée avec un fichier “Caddyfile”, situé au chemin /etc/caddy/Caddyfile.

La syntaxe des Caddyfile est documentée sur le site officiel de Caddy².

Pour le moment, nous allons simplement le déclarer et le démarrer pour obtenir le certificat racine de l’infrastructure de gestion de clés.

(Action) Créer un répertoire caddy dans votre répertoire de travail pour ce TP.

(Action) Écrire un fichier de configuration Caddyfile minimaliste et le stocker dans caddy/Caddyfile.

{
    http_port 80   # écoute sur le port 80
    https_port 443  # écoute sur le port 443
    admin off  # désactivation de l'API qui n'est pas utilisée dans ce TP
    log {
        output stdout  # journalisation sur stdout afin de le récupérer par le driver de log de l'engine
        format console  # journalisation au format console pour faciliter la lisibilité des logs (pas recommandé en production)
        level info  # journalisation de niveau info, pour avoir des informations, mais pas trop
    }
    local_certs  # tous les certificats sont émis par l'IGC interne, au lieu d'aller les chercher sur Internet
    skip_install_trust  # n'effectue pas une étape inutile quand on fait tourner Caddy dans un conteneur
}

(Action) Étendre l’image officielle de Caddy pour ajouter ce fichier de configuration. Pour cela, créer le fichier Containerfile (ou Dockerfile) suivant, et le stocker dans le répertoire caddy.

FROM docker.io/caddy:2.10.0-alpine
COPY Caddyfile /etc/caddy

(Action) Créer un fichier podman-compose.yml ou docker-compose.yml qui inclura les différentes définitions fournies ultérieurement

version: '3.7'

(Action) Déclarer dans le fichier compose un conteneur caddy

Le réseau caddy_frontend est le réseau public sur lequel seront exposés les ports 80 et 443. Le réseau caddy_backend est le réseau privé sur lequel seront connectés les différents services rendus disponibles par Caddy.

volumes:
  caddy_data:
    driver: local

networks:
  caddy_frontend:
    name: caddy_frontend
    internal: false
  caddy_backend:
    name: caddy_backend
    internal: true

services:
  caddy:
    build: caddy/
    container_name: caddy
    restart: always
    ports:
      - 8080:80
      - 8443:443
    volumes:
      - caddy_data:/data
    networks:
      - caddy_frontend
      - caddy_backend

(Action) Démarrer le conteneur

Depuis un shell, taper :

podman compose -f podman-compose.yml up -d

docker compose -f docker-compose.yml up -d

(Action) Récupérer le certificat racine

Depuis un shell, taper :

podman cp caddy:/data/caddy/pki/authorities/local/root.crt caddy.crt

docker cp caddy:/data/caddy/pki/authorities/local/root.crt caddy.crt

(Action) Insérer le certificat racine dans le magasin de certificat de son navigateur.

Avec Firefox, cela peut se faire de manière programmatique, avec l’utilitaire certtool. Cet utilitaire peut être installé avec le paquet “libnss3-tool” sur Debian/Ubuntu, et le paquet “nss-tools” sur Fedora.

Ensuite, exécuter la commande suivante dans un shell :

find $HOME -type f -name "cert9.db" | while read filename ; do certutil -A -n "CA TP" -t "TC" -i $PWD/caddy.crt -d "$(dirname "$filename")" ; done

Installation de Vaultwarden

Vaultwarden est un serveur compatible avec l’API Bitwarden. Il permet le stockage de mots de passe et de passkeys.

Il va être installé sous la forme d’un conteneur.

(Action) Ajouter le nom de domaine vault.tp-authn.broken-by-design.fr dans le fichier hosts, et le faire pointer vers 10.108.0.1

Sur Linux et Mac, éditer le fichier /etc/hosts. Sur Windows, éditer le fichier C:\Windows\system32\drivers\etc\hosts.

10.108.0.1 vault.tp-authn.broken-by-design.fr

(Action) Ajouter dans le fichier compose la déclaration des ressources pour un serveur Vaultwarden

Dans la section volumes, ajouter :

  vault_data:
    driver: local

Dans la section services, ajouter :

  vault:
    image: ghcr.io/dani-garcia/vaultwarden:1.33.2
    container_name: vault
    restart: always
    volumes:
      - vault_data:/data
    networks:
      - caddy_backend
    environment:
      SIGNUPS_ALLOWED: true
      SIGNUPS_DOMAINS_WHITELIST: tp-authn.broken-by-design.fr
      INVITATIONS_ALLOWED: false
      DOMAIN: https://vault.tp-authn.broken-by-design.fr:8443
      SHOW_PASSWORD_HINT: false
    depends_on:
      - caddy

(Action) Ajouter l’hôte virtuel pour Vaultwarden dans la configuration de Caddy

vault.tp-authn.broken-by-design.fr:80 {
  redir vault.tp-authn.broken-by-design.fr:8443{uri}
  log
}
vault.tp-authn.broken-by-design.fr:443 {
  reverse_proxy vault:80
  log
}

(Action) Détruire, reconstruire et recréer les conteneurs

podman compose -f podman-compose.yml down
podman compose -f podman-compose.yml build
podman compose -f podman-compose.yml up -d

docker compose -f docker-compose.yml down
docker compose -f docker-compose.yml build
docker compose -f docker-compose.yml up -d

(Action) Ouvrir dans son navigateur https://vault.tp-authn.broken-by-design.fr:8443/ et se créer un compte

(Action) Installer l’extension navigateur Bitwarden

(Action) Se connecter à son compte Vaultwarden dans l’extension Bitwarden. Penser à sélectionner “Connexion sur auto-hébergé” et renseigner l’URL du serveur “https://vault.tp-authn.broken-by-design.fr:8443/"

Installation de la forge logicielle

La forge logicielle est installée avec un conteneur. Ce conteneur dispose d’un volume /data pour le stockage de la configuration et des données des utilisateurs et utilisatrices.

Nous utiliserons une base de données sqlite3 pour stocker les données. En production, il est recommandé d’utiliser un gestionnaire de base de données plus robuste, comme Postgresql ou MariaDB.

Nous avons d’abord besoin de déclarer le nom de domaine qui sera utilisé pendant ce TP pour joindre la forge.

(Action) Ajouter le nom de domaine git.tp-authn.broken-by-design.fr dans le fichier hosts, et le faire pointer vers 10.108.0.1

Sur Linux et Mac, éditer le fichier /etc/hosts. Sur Windows, éditer le fichier C:\Windows\system32\drivers\etc\hosts.

10.108.0.1 git.tp-authn.broken-by-design.fr

Plus tard dans le TP, nous aurons besoin que Forgejo contacte le référentiel d’identités. Comme ce dernier sera rendu accessible par Caddy, il nous faut ajouter le certificat racine de Caddy à la liste des certificats de confiance du conteneur Forgejo. Il faut également que le conteneur forgejo ait accès à un réseau public.

(Action) Créer un répertoire forgejo à la racine du répertoire pour ce TP.

(Action) Copier dans le répertoire forgejo le certificat racine de Caddy.

(Action) Créer un fichier Containerfile ou Dockerfile qui étend l’image officielle de Forgejo pour y ajouter le certificat de Caddy

FROM codeberg.org/forgejo/forgejo:11
COPY caddy.crt /usr/local/share/ca-certificates/caddyca.crt
RUN update-ca-certificates

(Action) Déclarer la forge logicielle dans le fichier compose

Dans la section volumes du fichier compose, ajouter :

  forgejo_data:
    driver: local

Dans la section networks du fichier compose, ajouter :

  forgejo_public:
    name: forgejo_public
    internal: false

Dans la section services du fichier composer, ajouter :

  forgejo:
    build: forgejo/
    container_name: forgejo
    restart: always
    networks:
      - forgejo_public
      - caddy_backend
    volumes:
      forgejo_data:/data
    environment:
      USER_UID: 1000
      USER_GID: 1000
      FORGEJO__server__DOMAIN: git.tp-authn.broken-by-design.fr
      FORGEJO__server__ROOT_URL: 'https://%(DOMAIN)s:8443/'
      FORGEJO__server__DISABLE_SSH: true
      FORGEJO__database__DB_TYPE: sqlite3
      FORGEJO__admin__DEFAULT_EMAIL_NOTIFICATIONS: disabled
      # La ligne suivante est OK car nous utilisons un réseau "interne" et dédié
      FORGEJO__security__REVERSE_PROXY_TRUSTED_PROXIES: '*'
      FORGEJO__security__PASSWORD_HASH_ALGO: argon2
      FORGEJO__security__MIN_PASSWORD_LENGTH: 12
      FORGEJO__security__PASSWORD_COMPLEXITY: lower,upper,digit,spec
      FORGEJO__security__PASSWORD_CHECK_PWN: true
    depends_on:
      - caddy

(Action) Ajouter l’hôte virtuel pour forgejo dans Caddy à la fin du fichier caddy/Caddyfile

git.tp-authn.broken-by-design.fr:80 {
  redir https://git.tp-authn.broken-by-design.fr:8433{uri}
  log
}

git.tp-authn.broken-by-design.fr:443 {
  reverse_proxy forgejo:3000
  log
}

(Action) Détruire, reconstruire et recréer les conteneurs

podman compose -f podman-compose.yml down
podman compose -f podman-compose.yml build
podman compose -f podman-compose.yml up -d

docker compose -f docker-compose.yml down
docker compose -f docker-compose.yml build
docker compose -f docker-compose.yml up -d

(Action) Ouvrir https://git.tp-authn.broken-by-design.fr:8443/ dans son navigateur

(Action) Terminer la procédure d’installation de Forgejo en configurant un utilisateur administrateur et son mot de passe.

(Action) Ajouter une passkey pour le compte Administrateur du Forgejo

Pour ajouter la passkey, aller dans la “Configuration” du compte Administrateur de Forgejo, dans l’onglet “Sécurité”. Ensuite, dans la section “Clés de sécurité”, taper le nom “Bitwarden” et cliquer sur Ajouter une clé de sécurité. Dans la popup Bitwarden, sélectionner “Enregistrer la clé d’accès”.

(Action) Se déconnecter, et se reconnecter au compte administrateur, et utiliser la passkey comme second facteur d’authentification.

Installation d’un serveur Postgres pour le référentiel d’identités

Keycloak utilise une base de données pour stocker les identités entre autres informations.

Nous allons donc installer un serveur Postgres sous la forme d’un conteneur, et créer un réseau sur lequel Keycloak pourra le joindre.

(Action) Ajouter un serveur Postgres au fichier compose

Dans la section volumes, ajouter :

  psql_data:
    driver: local

Dans la section networks, ajouter :

  psql_backend:
    name: psql_backend
    internal: true

Dans la section services, ajouter :

  psql:
    image: docker.io/postgres:17.5-alpine
    container_name: psql
    restart: always
    volumes:
      - psql_data:/var/lib/postgresql/data
    networks:
      - psql_backend
    environment:
      PGDATA: /var/lib/postgresql/data/pgdata
      POSTGRES_DB: keycloak
      POSTGRES_USER: keycloak
      POSTGRES_PASSWORD: keycloak

(Action) Lancer le conteneur Postgres

podman compose -f podman-compose.yml up psql

docker compose -f docker-compose.yml up psql

Installation du référentiel d’identité

Le conteneur Keycloak est fourni sous la forme d’une image “non optimisée” et qui ne sait pas se servir de Postgresql comme base de données par défaut. Il est nécessaire “d’optimiser” l’image. En outre, Keycloak va avoir besoin de parler avec Forgejo ; il lui faut donc ajouter le certificat racine dans sa base de confiance. Contrairement à Forgejo, Keycloak n’utilise pas la base système et utilise à la place un keystore propre à Java.

(Action) Ajouter l’hôte idp.tp-authn.broken-by-design.fr dans le fichier hosts

10.108.0.1 idp.tp-authn.broken-by-design.fr

(Action) Ajouter l’hôte virtuel dans Caddy pour Keycloak

À la fin du fichier caddy/Caddyfile, ajouter :

idp.tp-authn.broken-by-design.fr:80 {
  redir https://idp.tp-authn.broken-by-design.fr:8433{uri}
  log
}

idp.tp-authn.broken-by-design.fr:443 {
  reverse_proxy keycloak:8080
  log
}

(Action) Créer un répertoire keycloak à la racine du répertoire du TP

(Action) Copier dans le répertoire keycloak le certificat de l’autorité de certification racine généré par Caddy

(Action) Créer un Containerfile (ou Dockerfile) dans le répertoire keycloak pour optimiser keycloak pour Postgresql

FROM quay.io/keycloak/keycloak:latest as builder
ENV KC_DB=postgres

COPY --chmod=0644 caddy.crt /opt/keycloak/conf/caddy.crt
RUN keytool -import -trustcacerts -keystore /opt/keycloak/conf/truststores/cacerts.jks -noprompt -storepass useless -file /opt/keycloak/conf/caddy.crt

WORKDIR /opt/keycloak
RUN /opt/keycloak/bin/kc.sh build

FROM quay.io/keycloak/keycloak:latest
COPY --from=builder /opt/keycloak/ /opt/keycloak/

(Action) Ajouter un conteneur keycloak dans le fichier compose

Dans la section networks, ajouter :

  keycloak_public:
    name: keycloak_public
    internal: false

Dans la section services, ajouter :

  keycloak:
    build: keycloak/
    container_name: keycloak
    restart: always
    networks:
      - keycloak_public
      - caddy_backend
      - psql_backend
    command: start
    environment:
      JAVA_OPTS: -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.err.encoding=UTF-8 -Dstdout.encoding=UTF-8 -Dstderr.encoding=UTF-8 -XX:+ExitOnOutOfMemoryError -Djava.security.egd=file:/dev/urandom -XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:FlightRecorderOptions=stackdepth=512 -Xms64m -Xmx512m -Djavax.net.ssl.trustStore=/opt/keycloak/conf/truststores/cacerts.jks -Djavax.net.ssl.trustStorePassword=useless
      KC_PROXY_HEADERS: xforwarded
      KC_HTTP_ENABLED: "true"
      KC_DB: postgres
      KC_DB_URL: jdbc:postgresql://psql/keycloak
      KC_DB_USER: keycloak
      KC_DB_PASSWORD: keycloak
      KC_HOSTNAME: https://idp.tp-authn.broken-by-design.fr:8443/
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: Bonjour1!tititoto
    depends_on:
      - caddy
      - psql

(Action) Détruire, reconstruire et relancer les conteneurs

podman compose -f podman-compose.yml down
podman compose -f podman-compose.yml build
podman compose -f podman-compose.yml up -d

docker compose -f docker-compose.yml down
docker compose -f docker-compose.yml build
docker compose -f docker-compose.yml up -d

Configuration du référentiel d’identités

Dans cette section, nous allons configurer Keycloak afin qu’il dispose d’un domaine ("realm”) dédié au réseau d’exploitation (par opposition au réseau et au domaine d’administration). Dans ce domaine, nous allons créer un utilisateur. Nous allons également déclarer un “client” OpenID Connect pour Forgejo. Cette configuration client permettra à Forgejo de demander des informations à Keycloak concernant les utilisateurs.

(Action) Se connecter sur https://idp.tp-authn.broken-by-design.fr:8443/

Utiliser le compte “admin” et le mot de passe “Bonjour1!tititoto”

(Action) Créer un nouveau domaine (realm) nommé “TP” pour les comptes utilisateurs et utilisatrices d’exploitation

(Action) Collecter les informations pour l’ajout d’un nouveau client dans Forgejo.

Pour cela, se connecter au compte administrateur, sélectionner “Administration du site”, puis dans “Identité et accès”, sélectionner “Sources d’authentification”. Ajouter une source d’authentification. Sélectionner le type “OAuth2” et le fournisseur OAuth2 appelé “OpenID Connect”. Après avoir saisir le nom de l’authentification “keycloak”, récupérer l’adresse conseillée pour l’URL de rappel/redirection (https://git.tp-authn.broken-by-design.fr:8443/user/oauth2/keycloak/callback).

(Action) Sur Keycloak, créer un nouveau client OpenID Connect forgejo dans le domaine &quote;TP&quote;.

Dans le domaine “TP”, aller dans le menu “Clients”, et cliquer sur “Create client”. Appeler le client forgejo. Cliquer sur “Next”, puis sélectionner uniquement le flux d’authentification standard. Activer également l’authentification du client, puis cliquer sur “Next”. Indiquer l’URL racine https://git.tp-authn.broken-by-design.fr:8443/, l’URL de rappel valide https://git.tp-authn.broken-by-design.fr:8443/user/oauth2/keycloak/callback. Finalement, cliquer sur “Save”.

(Action) Récupérer le secret pour le client Forgejo.

Se rendre dans l’onglet “Credentials” du client forgejo et copier le client secret.

(Action) Configurer Forgejo pour utiliser Keycloak

Une fois “ajouter une source d’authentification” sélectionné, choisir le type “OAuth2”, et le fournisseur “OpenID Connect”. Indiquer le nom de fournisseur keycloak, l’ID du client forgejo, et le secret du client copié depuis Keycloak. Indiquer également l’URL de découverte https://idp.tp-authn.broken-by-design.fr:8443/realms/TP/.well-known/openid-configuration. Ajouter la source d’authentification.

(Action) Ajouter un utilisateur administrateur forgejo admin dans le domaine TP

Dans “Users”, sélectionner “Create new user”. Nommer l’utilisateur admin et créer l’utilisateur. Dans l’onglet “Credentials”, sélectionner “Set Password” et définir un mot de passe pour l’utilisateur admin. Utiliser Bitwarden/Vaultwarden pour suggérer un bon mot de passe, et le sauvegarder.

(Action) Associer l’utilisateur administrateur de Forgejo à l’identité admin du realm TP de Keycloak.

Dans Forgejo, aller dans “Configuration” du profil utilisateur. Dans l’onglet “Sécurité”, dans la section “Gérer les comptes liés”, sélectionner “Lier un compte”, et sélectionner “keycloak” dans la liste déroulante qui est apparue. S’authentifier au compte admin du realm TP. Compléter les champs demandés.

(Action) Tester l’authentification avec Keycloak sur Forgejo.

Se déconnecter du compte administrateur de Forgejo. Se reconnecter, en cliquant sur “Se connecter avec Keycloak”.

Gérer les groupes et les rôles de façon centralisée

Dans cette partie du TP, nous allons créer des rôles et des groupes et les assigner à nos utilisateurs admin et un nouvel utilisateur jean.dupont. Ces droits seront ajoutés dans Keycloak et dans Forgejo. Ensuite nous configurerons Forgejo pour qu’il utilise les informations récupérées grâce OpenID Connect pour ajouter l’utilisateur jean.dupont dans les bons groupes gérés par Forgejo.

(Action) Créer dans Forgejo une organisation &quote;TP&quote;

Cliquer sur le “+” en haut à droite, puis sélectionner “Nouvelle Organisation”. Appeler l’organisation “TP” et cliquer sur “Créer une organisation”.

(Action) Créer dans l’organisation Forgejo &quote;TP&quote;, une équipe mainteneurs, avec des droits en écriture.

Une fois sur la page de l’organisation “TP”, sélectionner “Nouvelle équipe”. Nommer l’équipe mainteneurs, et sélectionner le niveau de privilège “Ecriture” pour l’ensemble des actions possibles.

(Action) Créer dans l’organisation Forgejo “TP”, une équipe contributeurs, avec des droits en lecture.

(Action) Ajouter au domaine TP de Keycloak des rôles mainteneur et contributeurs.

Dans le domaine TP, sélectionner le menu “Realm Roles”, puis “Create role”. Nommer les rôles et cliquer sur “Save”.

(Action) Ajouter au domaine TP de Keycloak des groupes Mainteneurs du TP et Contributeurs du TP.

Dans le domaine TP, aller dans le menu “Groups”, puis cliquer sur “Create Group”. Nommer le groupe, puis cliquer sur “Create”. Renouveller l’opération pour le second groupe.

(Action) Assigner le rôle mainteneur aux membres du groupe Mainteneurs du TP et le rôle contributeur aux membres du groupe Contributeurs du TP.

Pour cela, dans le domaine TP, dans le menu “Groups”, cliquer sur un groupe, puis aller dans l’onglet “Role Mapping”, et cliquer sur “Assign Role”. Sélectionner le rôle approprié, puis cliquer sur “Assign”. Renouveler l’opération pour le second groupe.

(Action) Dans Keycloak, ajouter un utilisateur jean.dupont et lui définir un mot de passe avec Vaultwarden.

(Action) Ajouter jean.dupont au groupe Mainteneurs du TP.

Pour cela, dans le domaine TP, dans le menu “Groups”, cliquer sur le groupe Mainteneurs du TP, puis aller dans l’onglet “Members”. Cliquer sur “Add Member”, cocher l’utilisateur jean.dupont, puis cliquer sur “Add”.

(Action) Configurer l’exposition des rôles au client forgejo, afin de ne divulguer que la possession des rôles mainteneur et contributeur à ce client, sous une entrée forgejo-roles.

Dans le menu “Clients”, cliquer sur le client forgejo. Ensuite, dans l’onglet “Client Scopes”, cliquer sur l’entrée forgejo-dedicated. Cliquer sur le bouton “Add predefined mappers”. Cocher “realm roles”, puis cliquer sur “Add”. Cliquer ensuite sur l’entrée “realm roles”, et remplacer la valeur dans “Token Claim Name” par forgejo-roles. Cocher également “Add to userinfo” et “Add to ID Token”, puis cliquer sur “Save”. Ensuite, revenir sur la fenêtre “forgejo-dedicated”, puis se rendre dans l’onglet “Scope”. Désactiver “Full scope allowed”, puis cliquer que “Assign Role”, cocher les deux rôles mainteneur et contributeur et cliquer sur “Assign”.

(Action) Configurer Forgejo pour tenir compte des rôles fournis par Keycloak.

Dans “Administration du site”, dans le menu “Identités et accès”, puis “Sources d’authentification”, cliquer sur “Editer” pour le fournisseur “keycloak”. Dans le champ “Associe les groupes réclamés avec les équipes de l’organisation. (Optionnel, nécessite un nom de réclamation)”, saisir le document JSON suivant :

{"mainteneur": {"TP": ["mainteneurs"]}, "contributeur": {"TP": ["contributeurs"]}}

Saisir également forgejo-roles dans le champ “Réclamer le nom fournissant les noms de groupe pour cette source. (facultatif)”, puis cliquer sur “Mettre à jour la source d’authentification”.

(Action) Configurer Forgejo pour qu’il retire les membres des équipes lors de la synchronisation avec Keycloak

Dans “Administration du site”, dans le menu “Identités et accès”, puis “Sources d’authentification”, cliquer sur “Editer” pour le fournisseur “keycloak”. Cocher la case “Supprimer les utilisateurs des équipes synchronisées si l’utilisateur n’appartient pas au groupe correspondant”, puis cliquer sur “Mettre à jour la source d’authentification”.

(Action) Constater qu’il n’y a aucun membre dans l’équipe mainteneurs sur Forgejo.

(Action) Se déconnecter de l’utilisateur admin du realm TP.

Se rendre à l’adresse https://idp.tp-authn.broken-by-design.fr:8443/realms/TP/account/ et se déconnecter.

(Action) Se connecter en tant que jean.dupont sur Forgejo, en se connectant avec Keycloak. Valider la création d’un nouveau compte. Constater que l’utilisateur appartient à l’équipe mainteneurs.

(Action, Optionnel) Dans Keycloak, retirer jean.dupont du groupe des utilisateurs “Mainteneurs du TP”.

(Action) Se déconnecter du compte jean.dupont sur Forgejo et sur Keycloak et se reconnecter. Constater que l’utilisateur n’est plus membre de l’équipe mainteneurs.

Configurer une authentification sans mot de passe

Dans cette partie du TP, nous allons améliorer la procédure d’authentification sur Keycloak en rendant l’usage du mot de passe optionnel, voire en l’éliminant totalement.

(Action) Créer une nouvelle procédure d’authentification à partir de celle préexistante &quote;Browser&quote;, ne permettant que l’authentification sans mot de passe avec une passkey, ou l’authentification avec mot de passe si l’attribut &quote;password-authn-allowed&quote; vaut &quote;true&quote;.

Dans le domaine TP, cliquer sur “Authentication”. Dans l’onglet “Flows”, sur le menu kebab au bout de la ligne “browser”, et sélectionner “Duplicate. Appeler ce flow “Browser TP”. Cliquer sur “Browser TP”, puis supprimer toutes les entrées en cliquant sur les icones poubelles.

Cliquer ensuite sur “Add execution”, sélectionner “Cookie” et cliquer sur “Add”. Dans la colonne “Requirement” de la ligne “Cookie”, sélectionner “Alternative”.

Cliquer ensuite sur “Add Subflow”, appeler ce flow “user active authentication”, et conserver le “flow type” à la valeur “Generic”. Dans la colonne “Requirement” de la ligne “user active authentication”, sélectionner “Alternative”.

Cliquer ensuite sur le “+” de la ligne “user active authentication”, puis sur “Add execution”. Sélectionner “Username Form”.

Cliquer ensuite sur le “+” de la ligne “user active authentication”, puis sur “Add sub-flow”. Le nommer “required placeholder”, laisser le “flow type” à la valeur “Generic”, puis cliquer sur “Add”. Dans la colonne “Requirement” de la ligne “required placeholder”, sélectionner “Required”.

Cliquer ensuite sur le “+” de la ligne “required placeholder”, puis sur “Add sub-flow”. Le nommer “passwordless flow”, laisser le “flow type” à la valeur “Generic”, puis cliquer sur “Add”. Dans la colonne “Requirement” de la ligne “passwordless flow”, sélectionner “Alternative”.

Cliquer ensuite sur le “+” de la ligne “required placeholder”, puis sur “Add sub-flow”. Le nommer “passwordful flow”, laisser le “flow type” à la valeur “Generic”, puis cliquer sur “Add”. Dans la colonne “Requirement” de la ligne “passwordful flow”, sélectionner “Alternative”.

Cliquer ensuite sur le “+” de la ligne “passwordless flow”, puis sur “Add condition”. Sélectionner “Condition - user configured”, puis cliquer sur Add. Dans la colonne “Requirement” de la ligne “Condition - user configured” que l’on vient d’ajouter, sélectionner “Required”.

Cliquer ensuite sur le “+” de la ligne “passwordless flow”, puis sur “Add step”. Sélectionner “Webauthn Passwordless Authenticator”, puis cliquer sur Add. Dans la colonne “Requirement” de la ligne “Webauthn Passwordless Authenticator”, sélectionner “Required”.

Cliquer ensuite sur le “+” de la ligne “passwordful flow”, puis sur “Add subflow”. Le nommer “Conditional Flow - password allowed”, puis cliquer sur Add. Dans la colonne “Requirement” de la ligne “Conditional Flow - password allowed”, sélectionner “Conditional”.

Cliquer ensuite sur le “+” de la ligne “Conditional Flow - password allowed”, puis cliquer sur “Add condition”. Sélectionner “Condition - user attribute”, puis cliquer sur Add. Dans la colonne “Requirement” de la ligne “Condition - user attribute” que l’on vient d’ajouter, sélectionner “Required”. Cliquer ensuite sur la roue crantée de la ligne “Condition - user attribute”. Saisir dans le champ “Alias” la valeur “Authentification par mot de passe autorisée”, dans le champ “Attribute name” la valeur “password-authn-allowed”, dans le champ “Expected attribute value” la valeur “true”. Cocher “Include group attributes”, puis cliquer sur “Save”.

Cliquer ensuite sur le “+” de la ligne “Conditional Flow - password allowed”, puis sur “Add step”. Sélectionner “Password Form”, puis cliquer sur “Add”. Dans la colonne “Requirement”, sur la ligne “Password Form”, sélectionner “Required”.

(Action) Assigner cette procédure au flux d’authentification &quote;Browser&quote;

Dans la procédure “Browser TP”, cliquer sur “Action”, puis “Bind flow”. Sélectionner “Browser flow”, puis “Save”.

(Action) Ajouter un groupe Password allowed dans le domaine TP

Cliquer sur le menu “Groups”, puis “Create Group”. Nommer le groupe, puis cliquer sur “Create”.

(Action) Ajouter jean.dupont et admin en tant que membres du groupe Password allowed.

Cliquer sur le groupe Password allowed. Dans l’onglet “Members”, cliquer sur “Add member”. Cocher les deux utilisateurs et cliquer sur “Add”.

(Action) Ajouter un attribut password-authn-allowed au groupe Password allowed, avec la valeur true.

Cliquer sur le groupe Password allowed. Dans l’onglet “Attributes”, cliquer sur “Add attributes”. Saisir password-authn-allowed dans le champ “key” et true dans le champ “Value”. Cliquer sur “Save”.

(Action) Configurer l’enregistrement obligatoire d’une passkey pour admin

Dans le menu “Users” du domaine TP, cliquer sur l’utilisateur admin. Dans “Required actions”, sélectionner “Webauthn Register Passwordless”. Cliquer sur “Save”.

(Action) S’authentifier au compte admin avec un mot de passe. Enregister une passkey.

(Action) Se déconnecter et se reconnecter à l’utilisateur admin. Utiliser la passkey.

(Action) Retirer admin du groupe Password allowed

Dans le menu “Groups” du domaine TP, cliquer sur le groupe Password allowed, puis cocher l’utilisateur admin et cliquer sur “Leave”.

(Action) Retirer la passkey du compte admin

Dans le menu “Users” du domaine TP, cliquer sur l’utilisateur admin. Dans l’onglet “Credentials”, cliquer sur le menu kebab de la ligne Webauthn-password less, et cliquer “Delete” et confirmer.

(Action) Essayer de se connecter au compte admin et constater une erreur.

Panique morale face à l'écriture inclusive en capacité de droit

Wed, 29 Nov 2023 00:00:00 +0000

Celles et ceux qui me suivent savent certainement que j’ai récemment entrepris de reprendre mes études, grâce au temps libéré en devenant freelance. Je me suis donc inscrit en faculté de droit à l’Université de Paris 1, en capacité, ayant raté la fenêtre pour les inscriptions en L1. J’effectue cette capacité au CNED, afin de pouvoir bosser à mon rythme et au rythme de mes clients.

Parmi les différents outils de communication, un groupe de discussion non officiel existe sur Whatsapp, où des étudiants et étudiantes de capacité peuvent échanger entre elles et eux, et également avec certaines personnes plus expérimentées.

Usant couramment de l’écriture inclusive, j’ai donc tout naturellement utilisé ce sociolecte sur ces groupes de discussion, avant de me faire agresser verbalement par un participant sur mon emploi de cette forme d’écriture : “ça ne veut rien dire”, “les correcteurs ne vont pas te rater”, “blablabla”. S’en est suivi le message suivant, retranscrit en toute légalité puisque posté sur un groupe de discussion public (mais non listé) :

Bonsoir tout le monde, ici votre serviteur ! J’espère que vous allez bien. Un simple rappel si vous utilisez l’écriture inclusive et/ou le point médian. Son usage à l’Université est vivement déconseillé (dans vos copies mais également vos échanges avec l’administration (sic) qui n’a pas le droit d’utiliser ce langage d’ailleurs). Pour information la jurisprudence administrative a censuré une délibération de l’Université de Grenoble qui utilisait ce langage ET une proposition de loi vient d’être adoptée pour que soit mis un terme à son usage dans l’administration (sic) (actuellement une circulaire) ainsi que dans tout document officiel (contrat de travail, panneau, etc.). Aussi, vraiment, n’utilisez pas ce langage dans vos copies, au risque de vous faire saquer par votre correcteur et contrairement à ce que diront certains, vous ne ferez pas les social justice warriors en contestant vos résultats, ça ne marche pas comme ça. En fac de droit on parle français et on ne fait pas une copie militante avec un langage sorti des théories fumantes des woke (sic) des USA. C’est un simple conseil, libre à vous de vous faire votre propre expérience.

Je propose de ne pas relever outre mesure la stupidité d’assigner l’écriture inclusive aux “wokes des USA”.

D’une part, discréditer une information ou une pratique sur la base de son origine est une partie intégrante de la cancel culture. Or, selon ses détracteurs et détractrices, la cancel culture est l’apanage des Wokes ; preuve est donc faite que la cancel culture est également utilisée pour cancel les Wokes..! La belle ironie.

D’autre part, attribuer l’écriture inclusive à des anglophones, dont la langue est essentiellement non genrée relève du contreexploit intellectuel. La seule variation récente de la langue sur ce sujet est la généralisation, notamment dans les papiers scientifiques, de l’emploi de “she” (elle) ou du “they” singulier (dont l’usage prédate les “Wokes” de plusieurs siècles) pour désigner les personnes de genre inconnu ou non pertinent.

Je passerai également sur la stupidité de déclarer “qu’en fac de droit on parle français et on ne fait pas une copie militaire avec un langage [autre]”, puisque le français ne se décrète pas. Il s’agit d’une langue (et non d’un langage) vivante, appartenant à la francophonie, qui ne se limite pas à la France. Et c’est en cela qu’il est totalement inepte que des pouvoirs politiques tentent d’en imposer un usage. Je parle français ; juste pas le français de la République française, et ce faisant, je lutte contre l’emploi des langues comme outils d’oppression.

Dans cet article, je vais apporter, après une description un peu plus formelle de ce qu’est l’écriture inclusive, un éclairage sur les contrevérités énoncées dans l’extrait précédent.

Définition de l’écriture inclusive

L’objet de l’écriture inclusive en français est de faire apparaitre dans la langue les femmes, les personnes sur le spectre du genre, ou agenrée. En effet, le français, tel que reconnu par la République française, utilise le masculin comme genre neutre. La communauté scientifique a cependant pu établir que cette règle créée des biais dans les jugements et les interprétations qui sont en défaveur des personnes dont le genre est ainsi invisibilisé.

L’écriture inclusive recouvre un ensemble de pratiques typographiques, syntaxiques et grammaticales visant à faire apparaitre ces genres invisibilisés, à commencer par le genre féminin.

L’écriture inclusive est souvent réduite à l’usage du point médian (comme dans “les premier.ères arrivé.es seront les mieux servi.es”), aux pronoms neutres nouveaux (comme “iel” et “iels”), aux flexions neutres (comme “-ae”), ou à l’accord de proximité. Ses détracteurs et détractrices reprochent à l’emploi du point médian de rendre plus difficiles la lecture, et l’oralisation de ces écrits. Malgré mon emploi du point médian dans mes écrits, je conviens de la validité de ces reproches. J’argüerais cependant que le français est une langue qui a été artificiellement complexifiée en vue de séparer “les gens de lettres des ignorants et des simples femmes”. Ainsi, si nous voulions aller vers une langue plus simple à apprendre, comprendre et lire, peut-être devrions nous en premier lieu la rendre transparente, à l’instar de l’Espéranto.

Concernant l’emploi des pronoms neutres nouveaux (il en existe de plus anciens, utilisés de tous et toutes, et auxquels on ne pense même plus sous cet angle, nonobstant les divagations de Brigitte Macron et de Jean-Michel Blanquer), ces derniers sont dans plusieurs dictionnaires actuels. Le lecteur ou la lectrice aura donc tôt fait d’en saisir le sens, tout comme il ou elle aura certainement cherché le mot “sociolecte” employé plus haut dans ce texte, et qui fait partie du technolecte des sociolinguistes.

L’écriture inclusive ne se limite cependant pas à ces pratiques. Ainsi, la féminisation des noms communs, l’énumération, l’emploi de termes épicènes, et l’évitement de certaines antonomases sont autant de techniques d’écriture, bien moins remarquables et satisfaisant pourtant à l’inclusivité.

L’énumération consiste à lister les noms, dans leurs différentes formes genrées. On peut citer comme exemples, le célèbre “Françaises, Français…” au début des discours présidentiels, ou la locution “le Premier ou la Première Ministre”.

Les termes épicènes sont ceux dont la forme ne varie pas suivant que l’on se réfère à un nom féminin ou masculin, comme c’est le cas, par exemple avec le mot “ministre”.

Finalement, les antonomases comme “Homme”, comme dans “la Déclaration des Droits de l’Homme et du Citoyen”, peuvent être simplement évitées, lorsque cela est possible (i.e. quand on ne fait pas référence à un texte l’employant déjà…).

Comme nous le verrons dans l’analyse juridique qui suit, certaines de ces formes sont rejetées par la loi de la République française, tandis que d’autres sont requises.

Analyse juridique

Le message cité en début d’article évoque plusieurs éléments :

une décision du tribunal de Grenoble concernant un acte administratif ayant été annulé ;
une proposition de loi, adoptée par le Sénat fin octobre 2023 ;
une circulaire portant sur l’emploi de l’écriture inclusive dans l’Administration.

Dans ce chapitre, nous verrons que les conclusions énoncées par l’auteur du message cité sont trompeuses, fausses et incomplètes.

Décision du tribunal de Grenoble

La décision n°2005367 du tribunal administratif de Grenoble concerne une affaire dans laquelle un plaignant sollicite (notamment) l’annulation d’une délibération de l’Université de Grenoble rédigée en utilisant certaines techniques d’écriture inclusive, et notamment le point médian.

Le tribunal a condamné l’Université de Grenoble et ainsi annulé la délibération en cause. Les raisons avancées sont cependant particulièrement importantes. En effet, ses dernières ont rapport avec la nécessité de clarté et d’intelligibilité de la norme. Cette nécessité a valeur constitutionnelle. Elle a été commentée par Louis le Foyer de Costil, spécialiste en droit public, dans Marianne.

D’une part, cette décision ne saurait faire jurisprudence quant à la recevabilité d’une copie étudiante, puisque (fort heureusement) les copies étudiantes ne sont pas la norme, et n’ont pas besoin de s’élever au niveau de la qualité de la loi. En outre, des décisions passées ont débouté les plaignants ou plaignantes souhaitant faire censurer des écrits inclusifs dans d’autres contextes qu’un acte administratif. Ce fut notamment le cas le 14 mars 2023, où le tribunal administratif de Paris a rejeté un recours sur l’usage du point médian sur une plaque en hommage aux anciens présidents du conseil de Paris.

D’autre part, comme le note une étude sénatoriale : “le principe de clarté de la loi renvoie à l’exercice par le législateur de sa compétence, qu’il tient de l’article 34 de la Constitution. Le Conseil constitutionnel a consacré ce principe, avant de l’abandonner […], compte tenu des ambigüités fréquemment relevées dans la doctrine”.

S’agissant d’un jugement en première instance, et étant le premier à juger ainsi négativement de la clarté d’un acte administratif utilisant le point médian, cette décision est relativement fragile et “il faudrait que ce jugement soit confirmé par la cour administrative d’appel, par le Conseil d’État”, commente Louis le Foyer de Costil.

Proposition de loi sur l’écriture inclusive

Les termes employés par l’auteur du message cité en début d’article concernant la proposition de loi sur l’écriture inclusive sont trompeurs. En effet, en choisissant de dire que la proposition de loi a été adoptée, il entend ainsi faire croire que c’est le Parlement qui a adopté le texte, à l’issue de la procédure législative. Or, ce n’est pas le cas. Le texte a simplement été adopté en première lecture par le Sénat, le 31 octobre 2023. Cette adoption n’a rien de surprenant étant donné que la couleur politique du Sénat est à droite depuis sa création sous la Ve République, et que les paniques morales sur la désacralisation de la langue sont un marronnier des mouvements politiques de l’extrême centre, de la droite et de l’extrême droite. Le texte n’a cependant pas terminé son parcours législatif et doit encore être étudié par l’Assemblée Nationale qui aura le loisir de voter divers amendements, y compris des amendements de suppression. La responsabilité du gouvernement ne pourra également pas être engagée sur ce texte, compte tenu qu’il s’agit d’un texte social et que le Gouvernement a déjà utilisé le 49.3 lors la session parlementaire en cours.

Circulaire sur l’écriture inclusive

La circulaire du 17 novembre 2017 est “relative aux règles de féminisation et de rédaction des textes publiés au Journal officiel de la République française”. Ici encore, l’auteur du message cité trompe délibérément son auditoire en laissant entendre que sa portée s’applique également aux écrits des étudiants et des étudiantes. Pourtant le nom de la circulaire indique bien qu’elle se limite au Journal officiel.

Cette circulaire est cependant référencée dans le bulletin officiel de l’éducation nationale, de la jeunesse et des sports, du 5 mai 2021. Ce bulletin, rédigé par Jean-Michel Blanquer, encadre l’emploi de l’écriture inclusive dans les actes et usages administratifs, et dans le cadre de l’enseignement. Il convient néanmoins de noter que ce bulletin, fortement chargé politiquement, use du sophisme de la généralisation abusive, en tentant de pourfendre l’écriture inclusive d’une main, tout en en promouvant (inconsciemment) son usage d’une autre, dans un exercice d’équilibrisme absurde, démontrant la parfaite stupidité de son auteur.

En effet, ce bulletin “proscrit le recours à l’écriture dite inclusive, qui utilise notamment le point médian pour faire apparaitre simultanément les formes féminines et masculines d’un mot employé au masculin lorsque celui-ci est utilisé dans un sens générique”. Simultanément, le bulletin prescrit “de recourir à des formulations telles que le candidat ou la candidate afin de ne pas marquer de préférence de genre, ou à des formules telles que les inspecteurs et les inspectrices de l’éducation nationale pour rappeler la place des femmes dans toutes les fonctions”. Or cette formulation est une pratique d’écriture inclusive, nommée énumération, et qui a été présentée plus haut dans ce document.

En conséquence, non seulement l’écriture inclusive n’est pas proscrite sous toutes ses formes dans les copies des étudiants et des étudiantes de l’Université, mais elle n’est pas non plus proscrite, mais au contraire prescrite par le ministère par l’entremise de cette circulaire et de ce bulletin.

Pour résumer, si vous souhaitez être certain ou certaines, évitez le point médian, mais vous pouvez utiliser sans problème les termes épicènes, l’énumération, et l’évitement des antonomases discriminantes. Si vous utilisez le point médian et que vous êtes pénalisés ou pénalisées lors de la notation, un recours sera possible, car il n’existe pas de jurisprudence à ce sujet.

Finalement, faites attention aux arguments d’autorité, en particulier quand ces derniers sont donnés mâtinés d’idéologie.

Refusez de donner les contacts de vos managers aux recruteurs !

Sun, 23 Apr 2023 00:00:00 +0000

Donner/Demander les contacts de précédents managers est immoral et injuste.

Voici pourquoi :

une des raisons du départ du salarié ou de la salariée peut être due à des tensions avec le ou la manager (pouvant aller jusqu’au harcèlement). Demander le contact du ou de la manager accroit l’influence de ce dernier ou cette dernière sur la vie du salarié ou de la salariée au delà de la relation de travail initiale, et peut étendre et prolonger le harcèlement de l’employé.e à toute sa future carrière professionnelle.
un.e employé.e peut avoir commis des actes par le passé qui sont de nature à pouvoir lui être reprochés. Néanmoins, ce dernier ou cette dernière bénéficie de plusieurs droits fondamentaux : le droit à l’oubli et le droit à se défendre. Au cours de sa vie, une personne change et évolue. Si en droit commun, les crimes peuvent être prescrits, les mauvaises aventures entre managers et employé.es devraient également pouvoir se prescrire, d’autant plus rapidement qu’elles ne relèvent pas du pénal. L’employé.e peut avoir changé, appris de son erreur, s’être construit autour de cette mauvaise aventure et être devenu.e un.e. meilleur.e employé.e. Pour autant, le/la manager de l’époque n’en saura possiblement rien, et pourra nuire à la carrière de l’employé.e malgré ses efforts. En outre, il est rarement offert au candidat ou à la candidate de donner sa version des faits lorsqu’un.e manager décide de donner un avis négatif. Là aussi, en droit commun, l’accusé.e dispose d’un droit à se défendre ; droit qu’ignorent les recruteurs et recruteuses, comme si la parole des managers étaient au dessus de celle des candidat.es, leur position hiérarchique dans l’entreprise en faisant des individu.e.s plus fiables de manière innée.

En tant que membres d’un secteur d’activité connaissant le plein emploi, nous, spécialistes en cybersécurité, ressources rares courtisées par les employeurs, avons le devoir moral de refuser fermement ces exigences de la part des recruteurs et recruteuses, par solidarité pour celles et ceux qui souffrent de ce type de situations. Faisons cesser ces abus ! Donnons le droit aux gens d’évoluer ! Rendons leur la liberté de s’être trompé.es sans entacher l’ensemble de leur carrière ! Faisons cesser ce classisme qui érige les managers en juges unilatéraux des bonnes conduites.

Protocole d'autorisation par "double anonymat" pour la vérification d'âge respectueuse de la vie privée

Thu, 23 Feb 2023 00:11:00 +0000

Cet article effectue une analyse comparative du protocole d’autorisation d’accès à des sites requérant une vérification d’âge proposé par le LINC (Laboratoire d’innovation numérique de la CNIL), dit en “double anonymat”, et de Privacy Pass, un protocole similaire développé par l’IETF (Internet Engineering Task Force), avec la contribution de Google, Apple, Cloudflare, Fastly, LIC, Brave Software, The Tor Project, et Mozilla.

Ces deux protocoles sont génériques et n’ont rien de spécifique avec la vérification d’âge. Leur objectif est de prouver à un tiers qu’un utilisateur remplit un certain critère, sans révéler à ce tiers qui est exactement cet utilisateur parmi un groupe d’individus. Ainsi, bien que le protocole proposé par le LINC soit actuellement popularisé dans le cadre du contrôle d’accès aux sites pornographiques, celui-ci ne se limite pas à ce cas d’usage, et d’autres sont possibles (âge, genre, classe de niveaux de revenu, statut de vaccination, etc.) et certains sont même déjà évoqués sur le site du LINC¹.

Par exemple, nous pouvons imaginer que cela fonctionne par grand palier selon la législation : 13 ans, 15 ans, 16 ans et 18 ans.

Dans cet article, nous verrons que le protocole proposé par le LINC comporte plusieurs risques pour la vie privée des utilisateurs. Parmi ces derniers, il est notamment question de fuite de données potentiellement caractérisables comme des données de santé, et de la capacité de l’État ou de son représentant à désanonymiser les utilisateurs en cas de collusion de plusieurs parties, de manière plus ou moins discrète.

Cet article est délibérément très technique et s’adresse à un public averti et formé à la cryptographie applicative et à la sécurité des protocoles réseau. La conclusion de l’article devrait être intelligible pour la plupart des lecteurs, mais elle n’aurait aucune valeur scientifique et technique sans le charabia qui la précède. Si vous êtes journaliste, faites-vous assister par un spécialiste de confiance pour vérifier mes dires avant de les reprendre.

Finalement, cet article ne couvre pas les nombreux moyens de contournement de la mesure technique souhaitée par le gouvernement français, au rang desquels les VPN. L’objectif est de discuter des mérites et des défauts des protocoles d’autorisation. Il est fait l’hypothèse (évidemment fantasque) que le monde entier a déployé cette méthode d’autorisation, ou qu’il n’est pas possible d’échapper à ce contrôle d’aucune manière que ce soit. Bienvenue en enfer.

Description informelle du protocole du LINC

Il n’existe à ce jour pas de papier scientifique ou whitepaper effectuant une description formelle du protocole proposé. Il existe cependant un article publié sur le site du LINC¹, et le code source d’un démonstrateur². Ces deux ressources sont assez anciennes, puisqu’elles ont été publiées en juin 2022, sans changement depuis lors. Si des évolutions ont eu lieu entre temps, ces dernières ne sont pas encore rendues publiques.

Description informelle des acteurs

Pour résumer ce qui est indiqué dans ces ressources, le protocole du LINC est composé de cinq acteurs ou types d’acteurs :

l’utilisateur et son navigateur (appelé Client dans le reste de cet article) ;
le site requérant une vérification de l’âge du Client (appelé Origin dans le reste de l’article, pour faciliter la comparaison avec Privacy Pass ;
des tiers certificateurs (appelés Issuers dans le reste de l’article) ;
l’Autorité qui maintient à jour une liste de tiers certificateurs de confiance ;
l’ouvreur (appelé Opener dans le reste de l’article) qui peut désanonymiser un tiers certificateur à partir d’une signature (nous reviendrons sur ce point).

Il convient de noter que l’Autorité et l’Opener sont des rôles pouvant être assumés par une unique entité ou des entités distinctes. Il est fait l’hypothèse que l’Autorité et l’Opener sont des entités étatiques ou mandatées par l’État français.

Si les termes Origin, Client, Issuer, Autorité et Opener semblent trop abstraits, il semble acceptable de les remplacer mentalement dans le reste de cet article de la façon suivante, tant qu’il reste clair à l’esprit de chacun qu’il ne s’agit que d’exemples :

Client : l’utilisateur ; vous, moi ;
Origin : un site pornographique, un débit de boisson, un site de jeu d’argent, un site de réservation pour un évènement (concerts, etc.) ;
Issuer : le site des Impôts ;
Autorité : l’État français ;
Opener : l’État français.

Description informelle des échanges

Pour consulter un site dont l’accès est restreint (noté Origin), celui-ci signale au Client, s’il n’est pas authentifié à l’aide d’un compte précédemment créé sur ce site, qu’une vérification du critère d’accès est requise. Pour cela, l’Origin fournit un “challenge”. Ce challenge consiste en des données permettant à l’Origin de vérifier, à l’issue des différents échanges, que l’autorisation d’accès délivrée a bien été émise pour cette Origin, et nul autre. Il contient également des métadonnées sur la nature du critère qui doit être contrôlé à propos du Client (p. ex. son âge supérieur à 18 ans).

Le Client télécharge ce challenge, puis se connecte auprès d’un Issuer et lui envoie le challenge. Cet Issuer vérifie si le Client remplit le critère. Par exemple, si c’est le site des Impôts, il vérifie à l’aide des informations d’état civil, si l’utilisateur est majeur. Dans le cas où le Client remplit le critère, l’Issuer effectue une opération cryptographique sur le challenge, et renvoie au Client le résultat de cette opération, que nous appellerons preuve.

Le Client télécharge cette preuve, puis il se connecte à nouveau à l’Origin et lui envoie la preuve délivrée par l’Issuer. L’Origin vérifie la validité de cette preuve grâce à des opérations cryptographiques, vérifie que cette preuve est bien fournie pour le challenge qu’il avait initialement fourni à l’utilisateur et vérifie que l’Issuer sélectionné par le Client a toujours la confiance de l’Autorité. Si ces conditions sont réunies, alors l’Origin accorde au Client l’accès à son service.

Description des propriétés de sécurité

Le protocole du LINC est affublé du qualificatif de “double anonymat”, car :

l’identité du Client, bien que connue et vérifiée par l’Issuer, reste inconnue de l’Origin. L’Origin n’a connaissance que du fait que l’utilisateur remplit ou non le critère d’admission.
l’identité de l’Issuer reste inconnue de l’Origin. En effet, les mécanismes cryptographiques mis en jeu par le protocole permettent à l’Origin de vérifier les preuves et de vérifier que l’Issuer a toujours la confiance de l’Autorité, sans jamais apprendre l’identité de l’Issuer.

Ce protocole vise donc à se défier des Origin, et à contrôler leur mécanisme d’autorisation d’accès en les privant de toute information d’identification.

En outre, ce protocole vise à ce que l’Issuer ne puisse discerner l’Origin que cherche à visiter le Client.

Protéger l’identité du Client semble une évidence, étant donné qu’avant la mise en place de ce type de contrôle d’accès, l’Origin ignorait tout de l’identité du Client.

Protéger l’identité de l’Issuer semble un peu plus surprenant. Cela permet néanmoins de limiter les risques que l’Origin apprenne des informations à propos de l’identité du Client. Par exemple, si le Client utilise le site des Impôts pour obtenir l’autorisation, alors l’Origin apprend que le Client est imposable (c’est-à-dire “potentiellement monétisable”) en plus de connaitre le critère de majorité.

Il convient de noter que la propriété d’anonymat de l’Issuer n’est pas limitée à l’Origin. En effet, avec les mécanismes cryptographiques mis en oeuvre par le protocole du LINC, il n’est possible pour personne d’autre que l’Opener de savoir qui est l’Issuer. Cela peut paraitre étonnant de prime abord, puisque l’utilisateur sait bien auprès de quel organisme il s’est authentifié pour obtenir la preuve de son admissibilité au critère. Il s’agit ici d’une subtilité du protocole : l’Issuer n’est en réalité pas un organisme unique, mais une clé cryptographique détenue par un organisme. Rien ne permet de garantir à qui que ce soit qu’un organisme ne possède qu’une et une seule clé cryptographique. Pour le dire plus simplement, un organisme peut incarner simultanément plusieurs Issuers à l’insu de tous·tes. Nous reviendrons sur ce point lors de l’analyse des défauts de ce protocole.

Description des mécanismes cryptographiques mis en oeuvre

Ces informations sont majoritairement tirées du démonstrateur publié sur Github².

L’Origin génère un challenge comprenant deux informations publiques et une privée. Les informations publiques sont un nonce, et un critère d’âge. L’information privée est la durée de validité du challenge.

Le Client transmet le challenge tel quel à l’Issuer sans aucune modification.

L’Issuer effectue une “signature” grâce à la bibliothèque PBC ³, et génère ainsi une preuve à divulgation nulle de connaissance de sa connaissance de sa clé privée. Il convient de noter que cette clé privée fait partie d’un schéma de signature de groupe⁴, dont le domaine de confiance est géré par l’Autorité. La seule connaissance de la clé publique du groupe est suffisante pour vérifier la preuve émise par cette clé privée. Une fois cette preuve créée, elle est envoyée au Client.

Le Client transmet tel quel à l’Origin la preuve, sans aucune modification.

L’Origin vérifie que la preuve porte bien sur le challenge/nonce qu’il a initialement délivré à ce Client. Il vérifie que le challenge n’a pas expiré. Il vérifie ensuite la validité de la preuve, grâce à la clé publique de l’Autorité. Il vérifie également dans une liste de révocation fournie par l’Autorité que la clé privée ayant créé la preuve n’a pas été révoquée du domaine de confiance.

Description de Privacy Pass

Privacy Pass est un protocole d’autorisation d’accès préservant la vie privée du Client développé par l’IETF. Ce protocole a été initialement proposé, en 2017, par Cloudflare dans un objectif de limitation du nombre de CAPTCHA présentés aux Clients naviguant sur des sites protégés par Cloudflare depuis le réseau d’anonymisation Tor. Il a depuis été spécifié sous la forme d’Internet Drafts dont certains sont en passe d’être adoptés en tant que RFC. Il convient donc de noter que les éléments évoqués ci-dessous sont contemporains aux versions en cours d’études par le groupe de travail Privacy Pass WG⁵.

Privacy Pass est un protocole générique de vérification de critères, bien qu’à l’origine, le critère vérifié par Cloudflare soit limité à “l’intelligence humaine”, ou plus spécifique à la capacité à résoudre un puzzle sensément insoluble par les intelligences artificielles actuelles.

Il convient de noter qu’il existe deux méthodes de génération des jetons d’autorisation d’accès avec Privacy Pass. L’un repose sur un VOPRF (Verifiable Oblivious Pseudo Random Function)⁶ et des vérifications avec une clé privée. L’autre utilise des signatures et des vérifications à clé publique. Dans le cadre de cet article, nous n’étudierons que la version avec des signatures et vérifications à clé publique, afin de rester dans un cadre relativement comparable au protocole proposé par le LINC.

Description des acteurs de Privacy Pass

Privacy Pass est composé de quatre rôles :

Client : l’utilisateur et son navigateur ;
Origin : le site web requérant la vérification du critère ;
Attester : une entité en charge de vérifier le remplissage du critère par le Client ;
Issuer : l’entité délivrant la preuve admissible par l’Origin que le Client remplit un certain critère, selon l’Attester.

Il existe de nombreuses variations dans l’architecture de Privacy Pass. Chaque rôle peut être incarné par des entités distinctes ou plusieurs rôles peuvent l’être par une seule entité. Ainsi les combinaisons de rôle suivantes sont spécifiées :

Origin + Attester + Issuer ;
Origin + Issuer ;
Attester + Issuer.

Description des échanges

Lorsqu’un Client tente d’accéder à une Origin requérant un critère spécifique, l’Origin renvoie un ou plusieurs challenges.

Chaque challenge est composé des informations suivantes :

un type de jeton d’autorisation acceptable (en vue de permettre l’agilité cryptographique) ;
le nom d’un issuer pouvant répondre à ce challenge ;
optionnellement, une information de contexte, sous la forme d’une valeur opaque de 32 octets, permettant de restreindre le contexte d’utilisation du jeton d’autorisation ;
optionnellement, le nom de l’Origin ayant produit ce challenge.

L’information de contexte permet notamment de limiter l’utilisation à une Origin particulière, sans pour autant divulguer le nom de cette Origin auprès de l’Issuer. Elle permet aussi d’encoder des restrictions comme l’adresse IP depuis laquelle sera autorisée la présentation du jeton d’autorisation d’accès, ou encore la durée de validité du challenge.

Le Client choisit l’un des challenges, et contacte un Attester qui est en relation avec l’Issuer spécifié dans le challenge sélectionné. L’Attester vérifie si le critère est vérifié par le Client. Si tel est le cas, l’Attester témoignera de cela auprès de l’Issuer. Si l’Attester n’est pas Issuer, alors il faudra qu’une mise en relation des deux rôles soit effectuée, soit par l’intermédiaire du Client qui contactera l’Issuer avec une attestation signée par l’Attester, soit l’Attester contactera directement l’Issuer.

Que ce soit le Client ou l’Attester qui contacte l’Issuer, dans tous les cas, le Client devra fournir des informations additionnelles à destination de l’Issuer :

le type de jeton d’autorisation acceptable par l’Origin et par lui-même ;
l’identifiant tronqué à un octet de la biclé que l’Issuer doit utiliser pour générer le jeton d’autorisation ;
une valeur opaque.

L’identifiant de la biclé que l’Issuer doit utiliser pour générer le jeton d’autorisation est le condensat SHA-256 de la clé publique de l’Issuer au format SubjectPublicKeyInfo encodée en DER.

La valeur opaque est le résultat d’une opération de masquage (blinding) du condensat du challenge et d’un nonce généré par le Client, et de diverses autres métadonnées protocolaires.

Le Client peut envoyer plusieurs requêtes à l’Issuer (éventuellement par l’entremise de l’Attester) pour une même attestation, afin de pouvoir obtenir plusieurs jetons pour une seule vérification du critère. Pour chaque requête, il sera nécessaire que le nonce du client soit distinct.

L’Issuer vérifie qu’une attestation a été fournie par l’Attester et effectue la signature cryptographique de la valeur opaque qu’il a reçue.

Le Client récupère la/les valeur(s) signée(s) et la/les démasque (unblind).

Le Client envoie ensuite à l’Origin le nonce, la signature démasquée, le condensat du challenge et diverses métadonnées.

L’Origin vérifie alors la signature démasquée contre les différentes données reçues, grâce à la clé publique associée à l’Issuer que le Client a choisi. Si la signature est bonne, alors l’accès est accordé.

Description des propriétés de sécurité

Privacy Pass offre une protection raisonnable (mais pas absolue) sur l’identité du Client.

L’Origin ne peut connaitre l’identité du Client, et ce même en cas de collusion avec l’Issuer. Cela est assuré par le mécanisme de masquage, dont seul le Client connait la clé de démasquage et qui rend virtuellement impossible toute connexion entre la requête du Client à l’Issuer et celle qu’il effectue auprès de l’Origin.

L’Origin apprend néanmoins quel Issuer a émis la signature, et il peut donc inférer certaines informations sur l’Attester, si tous les Attesters ne sont pas accrédités par tous les Issuers. Et en connaissant/suspectant quel Attester a été utilisé, l’Origin peut alors inférer une information sur le Client. Pour reprendre l’exemple donné pour le protocole du LINC, si l’Attester est le service des Impôts, et que l’Issuer n’a comme seul Attester ce dernier, alors en sachant que cet Issuer a reçu une attestation du service des Impôts, alors il sait que le Client est imposable.

Privacy Pass prévoit également que le Client puisse vérifier la signature grâce à la clé publique de l’Issuer. Cette vérification de signature doit être couplée à la vérification en ligne⁷ que la clé publique qu’il connait et utilise pour vérifier la signature est la même que celle à laquelle tous les autres Clients qui auraient recours à cet Issuer, auraient utilisée. Ces deux vérifications permettent de contrecarrer une attaque dite par partitionnement de l’ensemble anonyme (anonymity set partitionning). En effet, sans elles, le Client pourrait avoir reçu une signature effectuée avec une clé privée qui ne serait utilisée par l’Issuer que pour certains Clients. Ces Clients ne feraient alors plus partie de l’ensemble anonyme global, vérifié par la clé publique commune, mais d’un sous-ensemble, distinguable, vérifiable uniquement par une clé publique distincte.

Finalement, la révocation d’un Issuer ne s’effectue pas de manière centralisée ; chaque Origin doit individuellement retirer de sa liste de confiance les Issuers qui ne sont plus de confiance.

Il existe de nombreuses variantes et options dans Privacy Pass, et il ne s’agit ici que d’un portrait partiel, afin des fins de comparaison avec le protocole du LINC. S’il devait il y avoir de nouveaux points de comparaison, à l’aune d’une mise à jour des spécifications de l’un ou l’autre des protocoles, ou si un oubli c’était glissé dans cet article, ce dernier sera mis à jour dès que l’auteur en aura connaissance.

Description des mécanismes cryptographiques mis en oeuvre

Privacy Pass est conçu de manière à être agile vis-à-vis de ses mécanismes cryptographiques. Cette agilité est encodée grâce aux indicateurs de types de jetons qui ont été évoqués à plusieurs reprises dans la section précédente.

À l’heure où cet article est écrit, il n’existe que deux types de jetons :

0x0001 : VOPRF⁶ (P-384, SHA-384)
0x0002 : Blind RSA⁸ (2048 bit)

Considérations de sécurité et de vie privée

Après cette longue présentation des deux protocoles, il est proposé de procéder à l’analyse comparative de ces derniers.

Lien entre identité du Client et session sur le site de l’Origin

Adresse IP de l’utilisateur

Le protocole du LINC est un protocole interactif. Pour chaque demande d’accès devant être autorisée, le Client doit contacter un Issuer afin d’obtenir une preuve que le critère est rempli.

À l’inverse, Privacy Pass est un protocole qui peut être interactif ou non. Il est ainsi possible de demander à un Issuer implémentant Privacy Pass de multiples jetons d’autorisation pour un même challenge. Le Client n’est alors pas obligé de rentrer en contact avec l’Attester ou l’Issuer à chaque accès à l’Origin, puisqu’il peut être en mesure de disposer de certains jetons “d’avance”.

La nécessité d’interactivité du protocole dit en “double anonymat” fait que le Client se présentera probablement à l’Issuer et à l’Origin avec la même adresse IP. Si cette dernière n’est pas partagée avec une large portion de l’ensemble anonyme (anonymity set), alors il sera possible de déduire l’identité de l’utilisateur et ses habitudes de consommation en cas de collusion de l’Issuer et de l’Origin.

Avec Privacy Pass en mode interactif, le problème est identique. Néanmoins, en mode non interactif, le Client a l’opportunité de moduler son adresse IP, par exemple grâce à un VPN, pour l’unique moment où il collectera l’ensemble de ses jetons d’autorisation.

Challenge

Avec le protocole du LINC, le challenge fourni par l’Origin est transmis verbatim à l’Issuer. En conséquence, la collusion des deux entités permet d’associer aisément l’identité d’un Client à une activité sur une session sur l’Origin par simple journalisation puis comparaison des challenges émis et reçus.

En outre, même sans collusion, il est possible que l’Issuer puisse découvrir quelle Origin est visitée par le Client grâce à des motifs discernables dans le challenge. Par exemple, dans le démonstrateur développé par le LINC, le challenge est simplement la date du serveur. Il suffira alors de quelques requêtes par quelques Clients pour réussir à discerner l’heure exacte d’un serveur après gommage statistique des latences des requêtes. L’Issuer sera ensuite capable d’identifier de manière totalement passive quel site est consulté par quel Client sur la simple base de l’information volontairement transmise par le Client. Même si le challenge était un nombre aléatoire, il pourrait être possible d’identifier l’Origin si l’Origin n’utilise pas un générateur de nombres aléatoires cryptographiquement sûr. En effet, après un certain nombre de requêtes, il serait possible de retrouver l’état du générateur de nombres aléatoires, et d’ainsi distinguer plusieurs Origin de manière passive⁹.

Avec Privacy Pass, comme le challenge émis par l’Origin est intégré dans une requête dont le contenu est masqué avant d’être envoyée à l’Issuer, il n’est pas possible de faire ce lien, même en cas de collusion de l’Origin et de l’Issuer. Le Client participe activement au protocole et se défie de l’Origin et de l’Issuer.

Preuve

Avec le protocole du LINC, la preuve à divulgation nulle de connaissance émise par l’Issuer est transmise verbatim à l’Origin. Comme pour le challenge dans la section précédente, il est possible de relier l’identité du Client à une session sur l’Origin grâce à cette valeur commune.

Avec Privacy Pass, comme dans la section précédente, le démasquage de la réponse de l’Issuer permet de créer une rupture entre les données connues de l’Issuer et celles connues de l’Origin. En conséquence, il n’est pas possible de relier l’identité du Client à une session sur l’Origin par ce biais. Le client participe activement au protocole et se défie de l’Origin et de l’Issuer.

Partitionnement de l’ensemble anonyme

Le protocole du LINC prévoit que seul l’Opener puisse être en mesure de recouvrer quel Issuer a émis une preuve donnée. Cette propriété est délibérée et constitue l’un des deux “anonymats” de ce protocole dit à “double anonymat”. Elle est implémentée grâce à l’emploi d’un mécanisme de signature cryptographique de groupe⁴, et elle vise notamment à ce que l’Origin ne puisse distinguer l’Issuer.

Hélas, l’Origin n’est pas le seul acteur à ne pouvoir distinguer quel Issuer et plus précisément quelle clé privée d’Issuer a été utilisée pour générer une preuve. Les Clients ne le peuvent pas non plus.

Ainsi, dans le cas où l’Autorité et l’Issuer sont malveillants, il est possible qu’un sous-ensemble de l’ensemble anonyme (c.-à-d. certains Clients) voie ses preuves générées à l’aide de clés privées spécifiques. Ces preuves sont indistinguables de toutes les autres preuves, sauf pour l’Opener qui sera en mesure de singulariser les Clients ayant présenté à l’Origin ces preuves. Il ne semble pas improbable, dans le cas où l’Opener est l’État français qu’une perquisition des serveurs de l’Origin permet d’obtenir des journaux applicatifs contenant ces preuves et leur association à des sessions de navigation.

Privacy Pass, de son côté, peut également mettre en oeuvre des attaques par partitionnement de l’ensemble anonyme, notamment en incitant le Client à recourir à plusieurs Issuers tour à tour. Dans le cas où le Client se conforme à ces incitations, il est alors possible de partitionner l’ensemble anonyme en plaçant le Client à l’intersection des ensembles des Clients étant capables ou incapables d’obtenir des jetons d’autorisation de certains Issuers. Par exemple, un Client pourrait être identifié dans un sous-ensemble anonyme dont ses membres peuvent prouver leur âge grâce à leur banque, et à la sécurité sociale, et jamais via le service des Impôts. Ce sous-ensemble pourrait ainsi correspondre aux jeunes encore rattachés au foyer fiscal de leurs parents/tuteurs. Bien que Privacy Pass spécifie un moyen d’inciter les Clients à fournir des jetons d’autorisation provenant de tel ou tel Issuer plutôt que d’autres, le choix revient au logiciel mis en oeuvre par l’utilisateur de suivre cette incitation ou non. Il est donc possible que certains logiciels implémentant Privacy Pass ne soient pas concernés par cette attaque.

Futilité de l’interactivité comme méthode de prévention du marché noir

Le protocole du LINC doit et Privacy Pass peut fonctionner en mode interactif. Ce mode de fonctionnement oblige le Client à obtenir une preuve ou un jeton d’autorisation frais auprès d’un Issuer à chaque accès à une Origin. Cette obligation signifie que les Issuers seront en mesure de reconnaitre des habitudes de consommation. Dans le cas des sites pornographiques, ce mode est dangereux puisqu’une personne ayant développé une addiction à la pornographie pourra être identifiée comme telle par un Issuer qui lui remettrait des dizaines des preuves/jetons d’autorisation par jour. Or, les addictions sont des informations de santé¹⁰ ¹¹.

Un des risques perçus par le mode non interactif où le Client est autorisé à demander plusieurs preuves/jetons d’autorisation pour un unique challenge est la création d’un marché noir des preuves/jetons d’autorisation. En effet, un Client disposant de plusieurs jetons pourrait distribuer ou vendre ces derniers sans que l’Origin ne puisse distinguer si la preuve a bien été produite pour le Client qui la lui présente.

D’une part, il existe une contremesure assez simple, et qui est même recommandée dans la spécification de Privacy Pass : relier le challenge à un attribut de la connexion entre le Client et l’Origin : l’adresse IP du Client ou l’identifiant de la connexion TLS ¹² (Transport Layer Security).

Une telle contremesure permettrait de passer en mode non interactif, tout en contrecarrant l’essentiel des risques liés au marché noir.

Ensuite, en admettant que la preuve/le jeton d’autorisation soit bien présenté à l’Origin par le Client l’ayant demandé à l’Issuer, la première chose que fera l’Origin après vérification de l’authenticité de ce jeton sera de créer une session HTTP classique dans laquelle il sera noté que ce Client est autorisé à accéder au contenu du site. La plupart des sites n’appliquent pas de politique de sécurité associant fortement une session HTTP à une session TLS. Un utilisateur malveillant pourra alors revendre non pas son jeton d’autorisation, mais son identifiant de session HTTP. Cette technique de partage de sessions HTTP par la divulgation de l’identifiant de session est bien connu des auditeurs en sécurité, qui la connaisse sous le nom de Session Fixation¹³. Un tel partage pourrait même être aisément automatisé à grande échelle grâce à une extension navigateur.

L’usage du mode interactif pour le protocole proposé par le LINC dans le cadre de la demande de restriction d’accès aux sites pornographiques par le gouvernement français n’est donc pas pertinent, et constitue au mieux un choix mal informé.

Problème de la double dépense

Le problème de double dépense survient lorsqu’une même preuve ou un même jeton d’autorisation peut être utilisé sur plusieurs Origin, alors que le protocole souhaiterait voir la preuve/le jeton consommé et ne plus être réutilisable.

Il existe de nombreuses manières de résoudre ce problème de double dépense. L’une d’entre elles, la plus simple théoriquement et bien souvent la plus difficile à implémenter dans la pratique, est la conception d’un registre commun à l’ensemble des Origin. Ces dernières inscriraient au registre commun les jetons qu’elles auraient dépensés, après avoir consulté ce dernier pour s’assurer qu’une autre Origin ne l’aurait déjà fait. Hélas, cette méthode peut présenter des problèmes de vie privée, puisque ce registre devrait être largement consultable et contiendrait indirectement des statistiques de fréquentation des sites (une donnée métier sensible).

Une autre méthode tient dans la génération de challenges aléatoires, dont la probabilité de collision avec un autre challenge émis par une autre Origin serait négligeable. C’est la méthode recommandée par la spécification de Privacy Pass.

De manière étrange, dans le démonstrateur proposé par le LINC, le challenge n’est pas aléatoire, mais est la sortie d’une fonction monotonique : l’heure du serveur. L’heure ne peut constituer un bon moyen de prévention contre la double dépense, puisque le même challenge peut être alors émis par plusieurs Origin. Il s’agit surement d’une facilité utilisée par le développeur dans le cadre du démonstrateur. Dans une implémentation réelle, il serait néanmoins nécessaire de prévenir la double dépense à l’aide d’un challenge généré à l’aide d’un générateur de nombres aléatoires cryptographiquement sûr.

Conclusion

Dans cet article, nous avons étudié deux technologies pouvant être utilisées à des fins de contrôle d’accès en fonction de critères vérifiés par des tiers. Ces technologies prétendent pouvoir prouver à un tiers qu’un utilisateur remplit ces critères sans dévoiler d’informations personnelles. Les critères peuvent être variés, et sont extensibles : seuil d’âge, genre, niveaux de revenu, statut de santé, etc.

Privacy Pass, un protocole spécifié par un consortium informel sous l’égide de l’IETF, remplit cet objectif, sur le papier et dans certaines conditions d’implémentation.

De son côté, le protocole du LINC dit en “double anonymat” échoue maintes fois à protéger l’identité de l’individu, par erreur de conception ou sous la contrainte du cahier des charges du commanditaire. Cela est dû notamment à l’interactivité du protocole, et au rôle passif de l’utilisateur lors des échanges.

L’interactivité permet de relier nominativement l’utilisateur à une session sur le site qu’il souhaite consulter, et fuite ses fréquences de consultation, ce qui peut être une donnée de santé dans le cas d’une addiction (au jeu, à la pornographie, à l’alcool, etc.). Outre son aspect nocif pour la vie privée de l’utilisateur, cette interactivité se révèle totalement futile dans le combat contre l’émergence de marchés noirs de jetons d’autorisation permettant l’accès à des personnes ne remplissant pas les critères.

La passivité de l’utilisateur dans les échanges, quant à elle, permet de relier également l’identité de l’utilisateur à sa session sur le site visité, et donc potentiellement à ses préférences sexuelles. Elle permet également aux organismes attestant que l’utilisateur remplit un critère donné d’apprendre, dans certaines conditions, quel site est visité.

Finalement, il peut être intéressant de noter que le démonstrateur du LINC comporte une fragilité d’implémentation qui permet d’utiliser les jetons d’autorisations d’accès plusieurs fois, sur plusieurs sites distincts.

Secure Boot: this is not the protection we are looking for

Wed, 30 Nov 2022 00:00:00 +0000

Before being a technology, secure boot is an English expression. But, what does it mean to boot securely? What are we trying to achieve and to protect?

First, we want user data protection from a secure system. User data is really any piece of data a user might display or edit, including the obvious office documents but also configuration files, databases, downloaded files, log files, user commands, etc. These data must be protected in confidentiality. For this, the system must ensure that these data are protected at rest, when the system is shutdown. However, this is not enough, since access from unauthorized software could leak the data, for instance over the network or by copying it on an external removable drive. Hence, a secure system should only run authorized software.

Secure Boot, the technology

Secure Boot¹ helps running only authorized software on a machine. It does so by bootstrapping the security of the system at boot time, by verifying signatures on various software components, before giving way to other technologies to keep the system secure, later on. Secure boot works by authorizing only select executables to be run. Authorized executables are signed using public cryptography, and the keys used to verify those signatures are stored securely in UEFI “databases”.

UEFI is the successor of the now nearly defunct BIOS. It is an interface between the operating system and the manufacturer platform, a firmware, that runs very early on most modern systems. The platform is responsible of, among many other things, executing the bootloader (for instance, Grub or systemd-boot). Generally, the bootloader then starts an operating system. In the case of GNU/Systemd/Linux, the bootloader runs the Linux kernel, which shuts down all UEFI Boot Services, before dropping its privileges and then doing “Linux stuff” (like starting the userland part of the operating system). This privilege drop is very important because this is what ensures that no code past that point is able to tamper with the UEFI sensitive information, including UEFI variables, which contains sensitive data.

Secure Boot aims at securing “everything” that is executed prior to that privilege drop. Once the privileges are drop, Secure Boot is done and it is up to the operating system to extend that integrity/authenticity protection and ensure that only authorized software is run. Most Linux distros do not even try to do it, although there are notable exceptions (Chrome OS, Android, just to name a few). If we run one of the distros that do not leverage technologies such as dm-verity, fs-verity (with signatures) or Linux IMA (Integrity Management Architecture), then Secure Boot protected the boot integrity for basically nothing, because the security chain is broken by the operating system, and user data is at risk from possibly any tainted userland executable.

Nevertheless, ANSSI, the French Infosec Agency recommends in its GNU/Linux security guide² to enable Secure Boot (R3) for all systems requiring medium security level (level 2 out of 4, 1 being the minimal requirements and 4 being for highly secure systems). Meanwhile, using a Unified Kernel Image to bundle the Linux kernel with a initramfs into a single executable that can be verified by Secure Boot is only recommended³ for highly secure systems (security level 4 out of 4). No recommendation is ever done about using one of the aforementioned integrity features to ensure operating system integrity.

Interestingly, a poll on the fediverse⁴ revealed that 89% of the respondants thinks that Secure Boot is necessary for intermediate security level, and 45% even think that it should be a minimum requirement.

This article is a strong push-back against ANSSI “recommendation”, and it attempts to prove that it is not only useless but incoherent and misleading.

Signature verification and default public keys

Secure boot relies on a set of public keys to verify authorized software authenticity. By default, most vendors ship Microsoft public keys. These keys sign all Microsoft Windows version, of course, but to avoid a monopoly, other executables were signed. The list is ought to be short (and unfortunately, it is not) because with each signature and authorized software, the attack surface grows and the probability of a vulnerability raises. Several were already found in the recent past (e.g. CVE-2020-10713⁵, CVE-2022-34301⁶, CVE-2022-34302⁷, CVE-2022-34303⁸.

For this reason, many software still require that Secure Boot be deactivated, including firmware updates by some manufacturers, including Intel⁹ or Lenovo¹⁰.

Grub and the kernels are not directly authorized by Microsoft, as it would require for each and every single version to be signed individually by Microsoft. Instead, a binary called Shim¹¹ was developed. This rather small, auditable, innocuous-looking program is signed by Microsoft. Its role is basically that of a trojan horse (or a security pivot, depending on the way you look at it). Indeed, its only purpose is to cryptographically verify the authenticity of any executable. However, this time, the list of public keys used to verify these executables is not directly under the control of Microsoft. These public keys are either built in Shim itself or stored in a EFI variable serving as a database.

Additionally, shim public key list can be altered by any user able to prove “presence”. This is the case of any user using the local console or using a BMC for remote console access. Once a new public key enrolled, all executables verifiable by that key can run in the UEFI privileged mode, and for instance create a persistent backdoor in the bootstrapping code of the machine.

If this was not enough, users able to prove “presence” can also disable shim verification of authorized software. This means that shim can be used to have the system believe that Secure Boot was used to bootstrap security, while untrusted code was ultimately run within the UEFI privileged mode.

Hence, thanks to shim, just about any signed or unsigned, trusted or untrusted executable can be validated by proxy by Secure Boot using Microsoft keys.

And this conclusion signs (pun intended) the second incoherence in ANSSI recommendations. Indeed, they recommend replacing Microsoft keys by our own set of keys only for highly secure security level (R4). This means that all systems with intermediate (2/4) and enhanced (3/4) security levels will have the false sense of security of running Secure Boot while exposing themselves to attackers capable of proving “presence”.

For what it is worth, shim does provide a way secure all operations, including disabling verification or enrolling new keys by setting a password on shim’s MOK (Machine Owner Keys) Manager¹². However, the feature is mostly unused because no Linux distro enables it (it requires user interaction during the boot procedure) and system administrators often mistake the MOK Manager password, which secures the access to the MOK Manager as a whole, with the password that is asked when running mokutil commands (including --import and --disable-verification), which is just a password used to confirm the will of the user in the MOK Manager. The author of this article failed to find a single tutorial or article discussing the necessity of setting a MOK Manager for a Secure Boot. ANSSI also failed to recommend that. Most interestingly, setting a MOK Manager password is recommended even for Windows administrators that have no intention of ever running Linux, because MOK Manager is one of the executables signed by the Microsoft keys.

Using our own set of Secure Boot keys (PK and KEK)

Since replacing the Microsoft keys and signing only authorized binaries (i.e. our own Unified Kernel Image and specifically not shim) is an option, why not do that? It just requires that the system administrators replace the Secure Boot keys. The question of who controls the private key and the signature process is entirely up to whether the signed executable is altered or not by the system administrator. Distros could ship public keys and Unified Kernel Images instead of relying on Shim. If we run our own kernel, as recommended by ANSSI (R15 to R27), then we need to handle the private key and the signature process ourselves.

With a Unified Kernel Image signed and verified by Secure Boot, we are now sure that only our code is executed, and we can safely ask for the user passphrase to unlock the LUKS container. This way, user data is protected at rest, and accessed only by authorized software. Cool. Except it is not.

First, as mentioned earlier, the only thing that we verified is that the Unified Kernel Image is authentic. That kernel must then verify the operating system to ensure that only verified software is run. This requires cryptographic verification of every single executable (binaries, scripts and executable configuration files (because… yeah… that’s a thing)) in the operating system. This can be achieved if we, at minimum, do the following:

use a read-only filesystem for our partitions containing executable code, enforced using dm-verity, or fs-verity with file signature or Linux IMA, or something similar;
use the noexec mount option on data partitions;
modify command interpreters to ensure they do not execute scripts from mount points with noexec nor from STDIN;
prevent writable memory from ever getting executed, by patching the kernel;
ensure that no executable configuration file is writable.

Welcome in Wonderland, Alice.

Ok, but let’s assume we go down that rabbit hole… are we secure yet?

No. No, we are not.

Because there is no way of telling if our Secure Boot implementation is tainted by an attacker or not. Indeed, someone could have flashed our UEFI firmware before we enabled Secure Boot. Or they could have disabled it, flashed and reenabled it, if we did not have a UEFI administration password at some point. Or they could have abused shim when we were using the default keys to flash UEFI.

Nirvana Fallacy much?

So, if Secure Boot is not a good answer, especially against an attacker capable of physical access or remote access through a BMC, what is? Is there a better solution?

Well, to the best of the author knowledge, there is one: using a TPM. Using a TPM will not necessarily prevent an attacker from tainting the firmware. It will not necessarily prevent booting untrusted and unverified executables. What a TPM can give us is the ability to unseal a LUKS passphrase and get access to user data if and only if the cryptographically verified right version of UEFI firmware, Unified Kernel Image and operating system image have been booted. This is based on PCR policies, that ties the sealed passphrase to a particular signed set of executables measured by the TPM. This approach ensures user data confidentiality at rest and the authenticity of the executables that are on disk during boot. Of course, it does not prevent executing writable memory, nor user data flagged as executable, including scripts, and executable configuration files. And of course, having a signed set of policies means handling a private key and designing a signature procedure. There is no free lunch. Sorry.

However, using a TPM offers the same security level against attackers with physical access, attackers with remote access through a BMC, and a rogue system administrator, and that is something that Secure Boot cannot brag about.

Conclusion

So there you have it: recommending idly Secure Boot for all systems requiring intermediate security level accomplishes nothing, except maybe giving more work to system administrators that are recompiling their kernel, while offering exactly no measurable security against many threats if UEFI Administrative password and MOK Manager passwords are not set. This is especially true for laptop systems where physical access cannot be prevented for obvious reasons. For servers in colocation, the risk of physical access is not null. And finally for many servers, the risk of a rogue employee somewhere in the supply chain, or the maintenance chain cannot be easily ruled out.

UEFI Specifications ↩︎
no English version yet. French version ↩︎
“Protect command line parameters and initramfs with Secure Boot” ↩︎
Mastodon poll ↩︎
CVE-2020-10713 ↩︎
CVE-2022-34301 ↩︎
CVE-2022-34302 ↩︎
CVE-2022-34303 ↩︎
Intel UEFI Flash BIOS Update Instruction ↩︎
Lenovo flash BIOS with UEFI tool ↩︎
shim source code ↩︎
The command is mokutil --password. Please consider using it. ↩︎

Building a Debian rootfs from an unprivileged user with debootstrap

Thu, 08 Sep 2022 18:00:00 +0200

At Gatewatcher¹, we put efforts in making our building system reproducible and working offline, so that we can reduce the risk of supply chain attacks. Some efforts are also made so that our building system run with as few privileges as possible.

One of the few things we were still running as a privileged user recently was the build of our initial Debian root filesystem, for our base system and for our containers.

Indeed, the official Debian Docker container from Docker Hub was not generated in a way that we can consider secure for our need. It basically downloads a blob from a web server, does no verification whatsoever of that blob and ships it as the root filesystem². Even though the root filesystem they are using can be rebuilt in a reproducible way, downloading the result from Internet without verifying it against the expected hash is sort of missing the point of reproducible builds. Also, debuerreotype uses debootstrap, which is problematic in itself, as explained hereafter.

To create such root filesystem, multiple tools are provided by the Debian team, among which debootstrap, and multistrap.

Multistrap has not been updated in many years³, and suffers from some limitations that were show-stoppers for us, but it is capable to create root filesystems from an unprivileged user without hacks.

On the other hand, deboostrap is not really friendly with the idea of building a system from an unprivileged user.

First of, there is a check to ensure we are running it with UID 0⁴. This can be bypassed in several documented ways, including using fakeroot, which overloads some libc calls, using LD_PRELOAD. An other, less hacky, way is to run the program in a user namespace.

Unfortunately, this is not sufficient to run debootstrap, since it performs another check consisting of trying to create a “/dev/null” node⁵. This is more problematic since nodes cannot be created from a user namespace, as this would create a easy way of escaping the namespace.

As it seems, though, there is a way to build an unprivileged Debian root filesystem that is even built into deboostrap, using the installation variant “fakechroot”. Alternate code paths exist in deboostrap when this variant is selected that side-step some checks, and fake some calls. This variant also adds a check to ensure this variant is run only if the fakechroot utility is in use. Therefore, you are expected to run debootstap as followed, as documented in the fakechroot manpage:

# apt update && apt install -y debootstrap fakeroot fakechroot
$ fakechroot fakeroot debootstrap --variant=fakechroot bullseye $HOME/rootfs

fakechroot works by overloading some functions with LD_PRELOAD, and has some documented limitations regarding symlinks. As it happens, these limitations include rewrites of absolute symlinks, by prefixing them with the path of the faked chroot. As a result, within the chroot, you will find links that are broken when actually chrooting, such as when you would use that directory hierarchy as a root filesystem on a container or a virtual machine.

With fakechroot:

$ readlink /path/to/my/chroot/usr/sbin/telinit
/path/to/my/chroot/bin/systemctl

Without fakechroot (this is what you want to see, in a normal system):

$ readlink /path/to/my/chroot/usr/sbin/telinit
/bin/systemctl

After some verifications, we decided that it was safe to fake the use of fakechroot, while using the “fakechroot” installation variant. For this, we set the environment variable FAKECHROOT to true, which fakechroot is supposed to set and which is controlled by debootstrap to authorize the use of the “fakechroot” variant. And it worked.

So to build a working root filesystem from an unprivileged user, we are now doing the following:

$ podman unshare
# FAKECHROOT=true debootstrap --variant=fakechroot bullseye chroot/
# tar -C chroot/ --exclude=dev/* -czf ./chroot.tgz .
# exit
$ cat <<EOF > Containerfile
FROM scratch
ADD chroot.tgz .
CMD ["/bin/bash"]
EOF
$ podman build -f Containerfile

This series of commands builds a Debian container from an unprivileged user. More work needs to be done to achieve offline reproducible builds, of course, but none require hacks like this, thankfully.

On votes, and Indieweb forums

Thu, 16 Jun 2022 00:00:00 +0000

In reply to https://seirdy.one/notes/2022/06/14/better-vote-enabled-forums/

Context: https://lemmy.ml/post/307399

Reddit and Lemmy supports upvotes and downvotes. This system is meant to allow good content to bubble up and bad content to sink. The goal is for people to self administer a filter bubble instead of relying on an opaque AI to sort content for the users, based on their inferred preferences.

Lemmy offers alternative sorting algorithms, some of which are not based on votes. This allows people to be able to dig up links, threads and comments that do not score well.

Downvotes are often used as a cheap way to signify a disagreement. They can be frustrating because the author of a post might feel bad without having a clear explanation about the disagreement. Downvotes can also be misused, e.g. for harassment campaigns and brigading.

Upvotes can also be assimilated to “likes”, which may signify agreement. Likes are well-known to be addictive, and some people become dependant of them, to the point of “living for social validation” at the cost of their own well-being. The “Infernet” series by the French media “Blast, le souffle de l’info” documents several cases.

Overall, votes (both up and down) can have a negative impact, at least on some users.

My understanding of your suggestion is that votes shall only be casted as part of a comment meeting a set of criteria for minimal quality. Automated screening are often gamified and are generally not well accepted by users. Also, I would argue that upvotes marking agreement will have a difficult time meeting the minimal quality criteria: agreement needs less words/clauses to be expressed than disagreement that would need to be supported by arguments.

Thus, I think that a system where votes can only be casted with comments would almost only have downvotes in practice. It feels like votes would therefore be redundant and that this system would be better off relying on another criterion than votes to sort content displayed by the forum/link aggregator. Someone suggested other engagement criteria.

Regarding the overall quality of posts in the system you present, I would agree that following the IndieWeb/POSSE philosophy could reduce the amount of low quality content since the author’s reputation would be directly impacted by the fact that their low quality content would be hosted on their own site. However, I would argue that user tracing and linkability would be increased, which can be an severe issue, especially for people expressing dissident opinions.

Regarding the use of a chat room for content creation, I suppose this is a mostly a question of habits and preferences. I do not like chat rooms because I find it difficult to track threads and comments and I prefer using a git send-email workflow with a good MUA, much like we do for code reviews at $WORK.

Displaying Password Policy before Password Change

Thu, 26 May 2022 16:30:00 +0000

On a multi-user system, one may not trust users to choose strong passwords. Thus, one can setup up a password policy. On linux systems using PAM, this can be done with pam_cracklib.

While pam_cracklib does an excellent job, with many options, it does not have an option to display the current password policy to the user prior to a password change. Indeed, this could be tedious because of the localization.

Displaying the policy is crucial, especially for users with expired passwords that must change them upon logging, because they can’t have access to the system to learn the policy before changing their passwords. This often results in frustrated users trying to “discover” the policy by trials and errors.

Sadly, most sysadmins I met forget to display that policy, or just do not know how to do it.

One response is to use pam_echo. This module displays on screen the content of a file and it can do so in all four PAM phases (account, auth, password, and session). With pam_echo, system administrators can just write down in the natural language of their users what the password policy is, and display it using a well-positioned call to pam_echo.

For instance, on my debian system, I edited /etc/pam.d/common-password and I added just before the line about pam_unix:

password optional pam_echo.so file=/etc/password_policy

Why is it better to sign commits with SSH than OpenPGP?

Thu, 26 May 2022 11:00:00 +0000

The OpenPGP format was designed in the 90’s and never really changed since then. It was documented in RFC4880 in 2008. Unfortunately, in the 90’s, people had really no good understanding of crypto yet, and the choices made were poor. Envelope design is poor. Some crypto algorithms are clearly outdated. Some default options are plain wrong.

Have you ever noticed that so many crypto attacks target OpenPGP and GnuPG? That’s not a surprise: it’s a popular crypto solution and it’s a relatively easy target, comparatively to some other mainstream crypto implementations. The Go langage maintainers even deprecated the OpenPGP implementation in their crypto standard library because they think OpenPGP is dangerous.

OpenPGP is incompatible with Go Cryptography Principles, it’s complex, fragile, and unsafe, and using it exposes applications to a dangerous ecosystem.

Basically, I would say that the only thing that OpenPGP has for itself is the deployed infrastructure. Or has it? Web of trust is mostly dead, since keyservers are out-of-service. And OpenPGP adoption was never really that high to begin with.

SSH keys are much more widely deployed and used than OpenPGP keys. The format is dead simple, and the crypto implementation from OpenSSH is up-to-date.

I am very happy that git made SSH signing possible; it means I can delete my OpenPGP keys for good. I just hope linux distros will make the switch soon, to a more modern crypto approach: ssh signing or minisign.

Secure large file decryption using Linux, Go and Nacl

Tue, 11 Jan 2022 00:00:00 +0000

It is often said that you should not create your own cryptographic algorithm. That in cryptography, one should not be original; that security is in the beaten track, and in particular those which are beaten by cryptographers. What is often forgotten is that using cryptography is also perilous. In this article we will discuss how to handle large files when decrypting, and how to do it securely on a Linux system. This article will be illustrated with Go code.

What is a “large file” and how is it different from “small files”?

A small file is anything that is reasonable to store in RAM, in its entirety. RAM is a sanctuary where a program can store information. This sanctuary offers a relatively strong guarantee of isolation from interference from other tasks/processes.

Conversely, a large file is a file that cannot be stored in its entirety in the RAM of the system that will decrypt it. Therefore, interferences can occur. They are of several kinds.

Modifications of the encrypted data

The first problem is that the encrypted data can be modified by an external program. Indeed, as soon as a file is visible in a directory, any program running with the necessary privileges can open a file descriptor on this file. Thanks to this file descriptor, it is then possible to modify the file. This includes programs running with the same privileges as the program that is in charge of decryption.

This is not necessarily a problem. The state of the art in applied cryptography is to use authenticated encryption. This type of encryption verifies the cryptographic integrity of the encrypted content, while it decrypts it. Some algorithms and encryption modes, such as AES-GCM or AES-OCB, perform these operations in “one pass”. That is to say that the authenticity check is performed as the decryption proceeds and an authenticity verdict is given at the end of the decryption. Alas, not all encryption modes are one-pass; thus AES-CCM, for example, will first perform an integrity check (first pass) and then perform decryption (second pass) if the data was initially determined to be authentic. Unfortunately, an attacker is then able to alter the data between the first and second pass. The decrypted content is then declared authentic, even though it has been altered.

Consequently, when a one-pass decryption mode is not used, it is necessary to use a private copy of the data, either in RAM or by other system tricks that will be detailed later in this document.

Early use of data whose authenticity is not yet assured

When the decrypted data is too large to be stored in RAM, it is necessary to write it to disk. Unfortunately, security problems can occur during this passage on disk.

The list of these problems cannot be exhaustive, but it is possible to think of certain software that would use the data in an anticipated way. Indeed, some software monitors the contents of a folder with inotify(7) ; this is the case of most file explorers.

This early reading can result in incorrect interpretations of the file. This is not the most unfortunate consequence, however. In the case of one-pass encryption, or integrity checking after decryption (see the OpenPGP section of this document), it is possible that the file containing the decrypted file contains malicious code added by an attacker who corrupted the encrypted document. It is indeed very important to understand that encryption alone is not sufficient to guarantee the integrity of a data, and that it is necessary to use an integrity pattern, and to verify it, before using the decrypted file. If the decrypted data is used before the authenticity verdict is given, then it is possible to exploit a vulnerability with a non-authentic document.

Therefore, it is essential that the decrypted data remains private until the authenticity verdict is received. When it is stored in RAM, this is easy, but when it must be stored on disk, in the case of large files, then it is necessary to exploit some defensive strategies, discussed later in this document.

Size reduction by fragmentation

One possible strategy for encrypting/decrypting a large file may be to break it up into chunks that will fit in RAM.

It might be tempting to look at encryption modes used for encrypting large amounts of data, like XTS. In a nutshell, XTS performs encryption/decryption using a single key, but it uses an encryption process that is “tweaked” to each logical unit. XTS is often used for disk encryption, and in this case the logical unit is the disk “sector”. Under Linux, it is possible to use XTS with dm-crypt and its LUKS overlay.

XTS presents a rather interesting advantage for disk encryption. Indeed, the tweak for each logical unit is an intrinsic information about the disk: the position of the sector on the disk. This subtlety means that it is not necessary to store additional data (the tweak) for each sector. So there is no storage expense for encryption related data!

Unfortunately, XTS offers limited integrity protection. Of course, if you take an encrypted sector and move it to another sector on the disk, the tweek of the algorithm will be incorrect. Indeed, if a sector is to be decrypted as sector X, and we try to decrypt it as sector Y, then the tweak will be incorrect, and the decryption will be meaningless. However, XTS does not protect against replacing sector X with an earlier version of sector X, for example.

Moreover, by splitting the disk into encrypted sectors, each with a different tweak, there is no protection against truncation. If one takes a disk of size X and copies it to a disk of size Y, with Y < X, the cryptographic algorithm will not detect that data is missing.

From the errors or constraints of disk encryption modes, several lessons can be learned. If the data to be encrypted/decrypted is too large to be stored in RAM, and the solution is to split it into chunks, then care must be taken to ensure that the integrity of the chunks is strong.

This integrity must ensure that :

each section cannot be modified individually, even by replacement with a section of another encrypted message of comparable size;
the order of the sections cannot be modified;
it is not possible to add or remove sections without the entire large file being considered invalid.

Problem number 1 can be easily solved by using a separate encryption/decryption key per encrypted file, in combination with an algorithm and encryption mode that results in an authenticated encryption, such as AES-GCM.

Problem 2 can be easily solved by adding a counter to each encrypted data block. This represents a storage overhead that can be paid for when we are talking about file encryption and not disk encryption.

It might be possible to create a tweakable encryption mode that is also authenticated, for example by combining XTS and an HMAC. Alas, the consequence would be that the cryptographic operations would be in two passes (XTS then HMAC), which is a potentially unnecessary computational overhead if a better solution is available (and it is; see below :)).

Furthermore, XTS + HMAC would not protect against issue 3). Indeed, to counter 3), one method is to add the expected amount of chunks in the metadata of the encrypted file. This amount should be protected in integrity. This method is not original; it is used in the Merkle-Damgård cryptographic construction, and is used in particular by the SHA hash algorithms.

All these additions are as many ways to make mistakes when performing the encryption and decryption steps. However, as stated in the chapter of this article, going off the beaten track is often synonymous with vulnerability.

Therefore, it would be better not to reinvent the wheel, and to use well-known cryptographic mechanisms and libraries to solve our large file problem.

Cryptographic libraries

In Go, there are various high-level cryptographic libraries that are frequently used. Here I will talk about OpenPGP, which is problematic, and NACL, which is to be preferred.

OpenPGP

OpenPGP is a fairly old encryption standard. Its main implementation is GnuPG, and it continues to be the hobby of some misguided technicians. Yes, I’m thinking in particular of you Linux distributions.

These harsh words against this format are however deserved. OpenPGP is a museum of horrors, full of antiquated mechanisms, and cryptographic constructs from the infancy of authenticated encryption. Also, and not least, its implementers seem to have a passion for bad API ideas. In fact, the author of this article discovered problems in most OpenPGP implementations in 2015, and some, in 2022, are still vulnerable to these findings… including GnuPG.

In Go, unsurprisingly, the OpenPGP implementation also contains some bad ideas. The package has even been frozen and deprecated, with the comment that it is not desirable for Go developers to use OpenPGP, as this format is “complex, fragile, and unsafe, and using it exposes applications to a dangerous ecosystem”. To make the point, we will study one of its problems.

While it is true that it is fairly universal for data sources to implement io.Reader, it is possible to question the relevance of this choice for an encrypted data source whose integrity can only be verified after a complete pass.

One might expect the OpenPGP container openpgp.MessageDetails to perform this check on its own when instantiated with openpgp.ReadMessage. This would be quite consistent with the encoding/gzip API whose NewReader function returns an error if there are no “magic” bytes at the beginning of the read. Alas, as said before, OpenPGP is a museum of horrors, and it is not possible to check the integrity of the encrypted document; it is necessary to decrypt the entire encrypted document first, to finally recover an integrity tag. Indeed, with the OpenPGP standard, the integrity tab (a simple SHA-1 of the cleartext) is part of the encrypted data, and is suffixed to the cleartext. This approach is called MAC-then-encrypt and is decried by the cryptographic community.

Although the io.Reader of openpgp.MessageDetails is stored in the aptly named UnverifiedBody field, it is extremely tempting for a developer to plug it into another io.Reader, like a series of decorators, and forget or discover too late that the message was not genuine!

NACL

NACL is an excellent cryptographic library, whose well-designed API allows only the most stubborn of idiots to make mistakes in its use. There are some command line tools to exploit it or its fork libsodium. One of them is the excellent minisign utility, by Frank Denis. The author of this article highly recommends minisign as a replacement for OpenPGP for signing documents!

There are implementations of minisign in Go, such as go-minisign, which unfortunately suffers from the same problem of handling large files that we are dealing with in this article. Fortunately it is possible to use go-minisign even for large files by using the tricks presented in this article, below.

Coming back to NACL, the box.Seal and box.Open functions have the particularity of not reading from an io.Reader and not writing to an io.Writer. So they do not fall into the crude trap at the bottom of which we find OpenPGP. These functions use byte slices. This could look like a blocking point. This article aims precisely at proposing a solution to circumvent this particularity, while offering a correct level of security.

System tips and tricks to the rescue

Control the release of data

As seen at the beginning of this article, it is important to control when the decrypted data is released; until the data is complete and verified, the working copy of the data must remain private. Since we are dealing with large files, which do not fit in RAM, it is necessary to store the working copy on the file system, while ensuring that no other process or task can access it. To do this, it is possible to use anonymous files.

Anonymous files are files that are stored on the file system without any links to them. By link, here, it is necessary to understand link in the sense “entry in a directory”: a hardlink. These files are created by specifying the O_TMPFILE option to syscall open(2). Any byte written to such a file is actually stored on the file system, via the file descriptor returned by open(2) and known only to the program that created it (and to the processes that will be poking around in /proc… but they are looking for trouble ;)). It is therefore a private copy of the decrypted file. When the file is complete and its content verified, it is then possible to publish it through different ways.

One way to publish the file in a not very elegant way is simply to create a new file, without the O_TMPFILE option, and then to copy the contents of the decrypted file into this new file which is accessible by the other processes. The file descriptor can then be closed, and the anonymous file will be automatically freed. This method is expensive and has the drawback of doubling the disk size needed to store the decrypted file, at least temporarily, until the file descriptor of the anonymous file is closed.

A more elegant way, which takes advantage of a feature that is not always available, is to use FICLONE of the syscall ioctl(2). FICLONE uses the copy-on-write (COW) functionality of some file systems, such as btrfs. With this syscall, it is possible to open a file with a hardlink and then request that the named file be a snapshot of the anonymous file. The two files will then share the same blocks of data on the file system, until one of them changes a block. But in this case, there will be no subsequent writing to the anonymous file after this call to ioctl(2). So this is simply a trick to link to the contents of the anonymous file, and thus publish it. The only drawback of this approach is that you have to use a file system that is compatible with FICLONE, and this is not the case with ext4, which is usually the default file system of Linux distrubutions.

Finally, there is a third method, also elegant, which does not take advantage of a particular feature of some file systems. Unfortunately, it requires certain system privileges to do so: CAP_DAC_READ_SEARCH. CAP_DAC_READ_SEARCH bypasses this file system protection, which is unfortunate, because it is also the privilege required to call the linkat(2) syscall, with the AT_EMPTY_PATH option. This syscall together with this option allows the creation of a link from a file descriptor. It allows giving a name to our anonymous file, once it is complete. It may be acceptable to give CAP_DAC_READ_SEARCH to our process, if it is running in a chroot in which this permission does not allow the program to gain or keep undue access to system resources. This solution is therefore probably acceptable under certain conditions, which must however be well controlled.

Decrypting a large file in virtual memory

Not everything that is in virtual memory is necessarily physical memory. Thus, it is possible to obtain a Go slice containing the contents of a file, without it being copied into RAM. In the same way, it is possible to write in a slice, which is not stored in RAM, thanks to a syscall: mmap(2). So we can call box.Seal and box.Open on such slices, and the result will have been computed without the content of the files being stored in RAM!

Unfortunately, things are never that “simple”. There are some additional subtleties required when performing this write operation to a slice pointing to a file placed in virtual memory with mmap(2). Firstly, it is necessary that the destination file is the right size before calling mmap(2). To do this, a sparse file can be created, using the fallocate(2) syscall. Then, once the writing to the slice is done, it is necessary to call the msync(2) syscall in order to force the transfer of data from the virtual memory to the file, before making the call to munmap(2), to free the slice created by mmap(2).

Similarly, mmap(2) should used for the encrypted file, but there are some subtleties here as well. In particular, it is better to work on a private copy of the file, rather than one that can be altered by an external source. Indeed, the behavior is not specified if an external program truncates the file after it has been passed to mmap(2).

Finally, when passing the slice receiving the decrypted data to box.Open, one must pass this slice with [:0], in order to keep the capacity of the slice equal to the size of the file, but to force its length to 0. By doing this, box.Open will not proceed to reallocations of the array underlying the slice. It is indeed very important to use this trick, in order to continue working in the virtual memory returned by mmap(2) and not to end up working accidentally in RAM.

Bringing it all together in a coherent program

To summarize everything that has been discussed in this article:

when dealing with a large file, it is better to use Linux efficiently than to risk creating vulnerabilities by trying to truncate the file;
it is important to always work with private copies of the data, both the encrypted and decrypted content;
it is necessary to have control over the publication of the decrypted content, in particular to ensure that the content has integrity and is complete before making it available to third-party applications.

To accomplish these goals, it is possible to use the Linux syscalls mmap(2), fallocate(2), msync(2), and ioctl(2) or linkat(2).

This git repository contains a library using all these elements to encrypt and decrypt a large file in a secure way.

Déchiffrement sécurisé de gros fichiers en Go

Mon, 10 Jan 2022 00:00:00 +0000

L’on dit souvent qu’il ne faut pas créer son propre algorithme cryptographique. Qu’en cryptographie, il ne faut pas faire preuve d’originalité ; que la sécurité est dans les sentiers battus, et en particulier ceux qui le sont par les cryptographes. Ce qu’on oublie souvent de dire, c’est qu’utiliser la cryptographie est aussi périlleux. Dans cet article, nous allons discuter du traitement des gros fichiers lors du déchiffrement, et de comment le faire de manière sécurisée sur un système Linux. Cet article sera illustré par du code Go.

Qu’est ce qu’un “gros fichier” et en quoi cela est-il différent des “petits fichiers” ?

Un petit fichier est tout ce qu’il est raisonnable de stocker en RAM, en intégralité. La RAM est un espace sanctuarisé où un programme peut stocker de l’information. Cette sanctuarisation offre avec une garantie relativement forte d’isolation contre les interférences provenant d’autres tâches/processus.

À l’inverse, un gros fichier est un fichier qui ne peut être stocké dans son intégralité dans la RAM du système qui va le déchiffrer. Dès lors des interférences peuvent survenir. Elles sont de plusieurs ordres.

Les modifications de la donnée chiffrée

Le premier problème est que la donnée chiffrée peut être modifiée par un programme externe. En effet, dès lors qu’un fichier est présent dans un répertoire, tout programme tournant avec les privilèges nécessaires peut ouvrir un descripteur de fichiers (file descriptor) sur ce fichier. Grâce à ce descripteur de fichiers, il est alors possible de modifier le fichier. Cela inclut les programmes tournant avec le même niveau de privilèges que le programme qui est en charge du déchiffrement.

Ce n’est pas forcément un problème. L’état de l’art en matière de cryptographie appliquée est d’utiliser du chiffrement authentifié. Ce type de chiffrement vérifie l’intégrité cryptographique du contenu chiffré, en même temps qu’il le déchiffre. Certains algorithmes et modes de chiffrement, comme AES-GCM ou AES-OCB, effectuent ces opérations en “une passe”. C’est-à-dire que la vérification de l’authenticité est effectuée au fur et à mesure du déchiffrement et un verdict d’authenticité est donné à la fin du déchiffrement. Hélas, tous les modes de chiffrement ne sont pas en une passe ; ainsi AES-CCM, par exemple, va d’abord effectuer une vérification en intégrité, puis effectuer le déchiffrement si la donnée a initialement été déterminée comme authentique. Hélas, un attaquant est alors en mesure d’altérer la donnée entre la première et la deuxième passe. Le contenu déchiffré est alors déclaré authentique, alors que ce dernier a été modifié.

En conséquence, lorsqu’un mode de déchiffrement en une passe n’est pas employé, il est nécessaire d’utiliser une copie privée de la donnée, que ce soit en RAM ou par d’autres astuces systèmes qui seront détaillées ultérieurement dans ce document.

Utilisation anticipée d’une donnée dont l’authenticité n’est pas encore assurée

Lorsque les données déchiffrées sont trop grandes pour être contenues en RAM, il est nécessaire de les écrire sur disque. Hélas, des problèmes de sécurité peuvent survenir lors de ce passage sur disque.

La liste de ces problèmes ne saurait être exhaustive, mais il est possible de penser notamment à certains logiciels qui utiliseraient la donnée de manière anticipée. En effet, certains logiciels surveillent le contenu d’un dossier avec inotify(7) ; c’est le cas de la plupart des explorateurs de fichiers.

Cette lecture anticipée peut résulter en des interprétations incorrectes du fichier. Ce n’est cependant pas la conséquence la plus funeste. Dans le cas d’un chiffrement en une passe, ou d’une vérification d’intégrité effectuée après le déchiffrement (c.f. la section de ce document relative à OpenPGP), il est possible que le fichier contenant le déchiffré intègre du code malveillant ajouté par un attaquant ayant corrompu le document chiffré. Il est, en effet, capital de comprendre que le chiffrement seul n’est pas suffisant pour garantir l’intégrité d’une donnée, et qu’il est nécessaire d’utiliser un motif d’intégrité, et de le vérifier, avant de faire usage du déchiffré. S’il est fait usage de la donnée déchiffrée avant que le verdict d’authenticité ne soit rendu, alors il est possible d’exploiter une vulnérabilité avec un document non-authentique.

En conséquence, il est indispensable que le déchiffré reste privé, jusqu’à réception du verdict d’authenticité. Lorsqu’il est stocké en RAM, c’est chose aisée, mais lorsqu’il doit être stocké sur le disque, dans le cas des gros fichiers, alors il est nécessaire d’exploiter quelques stratégies défensives, discutées plus bas dans ce document.

Réduction de la taille par fragmentation

Une stratégie possible pour chiffrer/déchiffrer un gros fichier peut être de le découper en tronçons qui tiendront en RAM.

Il pourrait être tentant de regarder du côté des modes de chiffrement utilisés pour le chiffrement de vastes quantité de données, comme XTS. En quelques mots, XTS effectue un chiffrement/déchiffrement à l’aide d’une unique clé, mais d’un procédé de chiffrement qui est ajusté (“tweaked”) à chaque unité logique. XTS est souvent employé pour le chiffrement de disques, et dans ce cas, l’unité logique est le “secteur” du disque. Sous Linux, il est possible de faire usage de XTS notamment avec dm-crypt et sa surcouche LUKS.

XTS présente un avantage assez intéressant pour le chiffrement de disques. En effet, l’élément qui permet de paramétrer l’ajustement (tweak) pour chaque unité logique est une donnée extérieure et intrinsèque du disque : la position du secteur sur le disque. Cette subtilité fait qu’il n’est pas nécessaire de stocker une donnée supplémentaire (les paramètres d’ajustement) pour chaque secteur. Il n’y a donc pas de dépense de stockage pour des données liées au chiffrement !

Hélas, XTS offre une protection en intégrité limitée. Certes, si l’on prend un secteur chiffré et qu’on le déplace dans un autre secteur du disque, les paramètres d’ajustement de l’algorithme vont être incorrects. En effet, si un secteur doit être déchiffré en tant que secteur X, et qu’on tente de le déchiffrer en tant que secteur Y, alors les paramètres de l’algorithme seront incorrects, et le déchiffré n’aura aucun sens. Cependant XTS ne protège pas contre le remplacement du secteur X par une version antérieure du secteur X, par exemple.

En outre, en découpant le disque en secteurs chiffrés, chacun avec un paramètre différent, il n’existe pas de protection contre la troncature. Si l’on prend un disque de taille X et qu’on le copie sur un disque de taille Y, avec Y < X, l’algorithme cryptographique ne détectera pas qu’il manque de la donnée.

Des erreurs ou contraintes des modes de chiffrement de disques, plusieurs leçons peuvent être tirées. Si l’on dispose d’une donnée à chiffrer/déchiffrer qui est trop grande pour être stockée en RAM, et que la solution envisagée est de découper cette donnée en tronçon, alors il faut veiller à mettre en place une intégrité forte des tronçons.

Cette intégrité doit assurer que :

chaque tronçon ne peut être modifié individuellement, même par remplacement avec un tronçon d’un autre message chiffré de taille comparable ;
l’ordre des tronçons ne peut être modifié ;
il n’est pas possible d’ajouter ou de retirer des tronçons sans que l’ensemble du gros fichier ne soit considéré comme invalide.

La problématique numéro 1 peut être aisément résolue en utilisant une clé de chiffrement/déchiffrement distincte par fichier chiffré, en combinaison avec un algorithme et un mode de chiffrement qui permette d’obtenir un chiffré authentifié, comme AES-GCM.

La problématique 2 peut être aisément résolue en ajoutant un compteur à chaque bloc de données chiffré. Cela représente un surcoût de stockage qu’il est possible de payer quand on parle de chiffrement de fichiers et non de chiffrement de disques.

Il pourrait être envisageable de créer un mode de chiffrement ajustable qui soit également authentifié, par exemple en combinant XTS et un HMAC. Hélas, la conséquence serait que les opérations cryptographiques seraient en deux passes (XTS puis HMAC), ce qui représente un surcoût potentiellement inutile si une meilleure solution est disponible (et c’est le cas ; voir ci-dessous :)).

En outre, XTS + HMAC ne protègerait pas contre la problématique 3). En effet, pour protéger contre cette dernière, une méthode est d’ajouter la quantité de tronçons attendue en meta-données du fichier. Cette quantité devrait être protégée en intégrité. Cette méthode n’est pas originale ; elle est utilisée dans la construction cryptographique Merkle-Damgård, et est employée notamment par les algorithmes de hachage SHA.

Tous ces ajouts sont autant de manière de se tromper lorsqu’on réalise les étapes de chiffrement et de déchiffrement. Or, comme dit en chapô de cet article, sortir des sentiers battus est souvent synonyme de vulnérabilité.

Dès lors, il serait préférable de ne pas réinventer la roue, et d’employer des mécanismes et des bibliothèques cryptographiques bien connues pour résoudre notre problématique de gros fichiers.

Les bibliothèques cryptographiques

En Go, il existe diverses bibliothèques cryptographiques haut-niveau qui sont fréquemment employées. Je vais ici parler d’OpenPGP, qui est problématique, et de NACL, qu’il convient de préférer.

OpenPGP

OpenPGP est un standard de chiffrement assez ancien. Son implémentation principale est GnuPG, et il continue d’être la marotte de certains techniciens bien mal avisés. Oui, je pense notamment à vous, les distributions Linux.

Ces mots durs contre ce format sont cependant mérités. OpenPGP est un musée des horreurs, remplis de mécanismes vétustes, et de constructions cryptographiques datant des balbutiements du chiffrement authentifié. Également, et non des moindres, ses implémenteurs semblent avoir une passion pour les mauvaises idées en matière d’API. L’auteur de cet article a d’ailleurs découvert en 2015 des problèmes dans la plupart des implémentations d’OpenPGP, et certaines, en 2022, sont toujours vulnérables à ces découvertes… dont GnuPG.

En Go, sans surprise, l’implémentation d’OpenPGP contient elle aussi de mauvaises idées. Le package a même été gêlé et déprécié, avec le commentaire qu’il n’est pas souhaitable que les développeurs Go emploient OpenPGP, ce format étant “fragile, complexe, non sûr, et […] son usage expose les développeurs à un écosystème dangereux”. Pour enfoncer le clou, nous allons procéder à une étude de l’une de ses problématiques.

S’il est vrai qu’il est assez universel que des sources de données implémentent io.Reader, il est possible de s’interroger sur la pertinence de ce choix pour une source de données chiffrée dont l’intégrité ne peut être vérifiée qu’après une passe complète.

L’on pourrait alors s’attendre à ce que le containeur OpenPGP openpgp.MessageDetails effectue cette vérification de lui-même lors de son instanciation avec openpgp.ReadMessage. Cela serait assez cohérent avec l’API de encoding/gzip dont la fonction NewReader renvoie une erreur en l’absence d’octets “magiques” en début de lecture. Hélas, comme dit précemment, OpenPGP est un musée des horreurs, et il n’est pas possible de vérifier l’intégrité du chiffré ; il est nécessaire de déchiffrer l’intégralité du document chiffré, pour récupérer enfin un motif d’intégrité. En effet, avec le standard OpenPGP, le motif d’intégrité (un simple SHA-1 du clair) fait partie des données chiffrées, et est suffixé au clair. Cette approche est appelée MAC-then-encrypt et est décriée par la communauté cryptographique.

Bien que le io.Reader de openpgp.MessageDetails soit stocké dans le bien-nommé champ UnverifiedBody, il est extrêmement tentant pour un développeur de le “brancher” dans un autre io.Reader, à la manière d’une série de décorateurs, et d’oublier ou de découvrir trop tard que le message n’était pas intègre !

NACL

NACL est une excellente bibliothèque cryptographique, dont l’API, bien conçue, ne permet qu’aux plus entêtés des idiots de se tromper dans son emploi. Il existe quelques outils en ligne de commande pour l’exploiter, elle ou sa variante (fork) libsodium. On peut notamment citer l’excellent utilitaire minisign, par Frank Denis. L’auteur de cet article recommande vivement minisign comme remplacement à OpenPGP pour la signature de documents !

Il existe des implémentations de minisign en Go, dont go-minisign, qui hélas souffre du même problème de gestion des gros fichiers qui nous occupe dans cet article. Fort heureusement il est possible d’exploiter go-minisign y compris pour des gros fichiers en utilisant les astuces qui sont présentées dans le présent article, plus bas.

Pour en revenir à NACL, les fonctions box.Seal et box.Open ont pour particularité de ne pas recevoir d’io.Reader et d’écrire dans des io.Writer. Elles ne tombent donc pas dans le piège grossier au fond duquel on trouve OpenPGP. Ces fonctions utilisent des slices de bytes. Cela pourrait ressembler à un point bloquant. Cet article vise précisément à proposer une solution pour contourner cette particularité, tout en offrant un niveau de sécurité correct.

Astuces systèmes à la rescousse

Contrôler la mise à disposition des données

Comme vu en début d’article, il est important de maitriser le moment où les données déchiffrées sont publiées ; tant que ces dernières ne sont pas complètes ou pas vérifiées, la copie de travail de ces données doit rester privée. Vu que nous traitons des gros fichiers, qui ne tiennent pas en RAM, il est nécessaire de stocker la copie de travail sur le système de fichiers, tout en s’assurant que nul autre processus ou tâche ne puisse y avoir accès. Pour ce faire, il est possible d’utiliser les fichiers anonymes.

Les fichiers anonymes sont des fichiers qui sont stockés sur le système de fichiers, sans qu’aucun lien n’existe vers ces derniers. Par lien, ici, il faut comprendre lien dans le sens “entrée dans un répertoire” (hardlink). Ces fichiers sont créés en spécifiant l’option O_TMPFILE au syscall open(2). Tout octet écrit dans un tel fichier est effectivement stocké sur le système de fichiers, par l’intermédiaire du descripteur de fichier renvoyé par open(2) et connu uniquement du programme qui l’a créé (et des processus qui vont farfouiller dans /proc… mais ils cherchent les problèmes ;)). Il s’agit donc d’une copie privée du déchiffré. Lorsque le fichier est complet et son contenu vérifié, il est alors possible de le publier de différentes manières.

Une manière de publier le fichier d’une manière peu élégante est simplement de créer un nouveau fichier, sans l’option O_TMPFILE, puis de recopier le contenu du fichier déchiffré dans ce nouveau fichier qui est accessible par les autres processus. Le descripteur de fichiers peut alors être fermé, et le fichier anonyme sera automatiquement libéré. Cette méthode est couteuse et présente le défaut de doubler la taille disque nécessaire pour stocker le déchiffré, au moins temporairement, jusqu’à la fermeture du descripteur de fichier du fichier anonyme.

Une manière plus élégante, qui tire cependant partie d’une fonctionnalité qui n’est pas toujours disponible, est d’utiliser FICLONE du syscall ioctl(2). FICLONE utilise la fonctionnalité de copy-on-write (COW) de certains systèmes de fichiers, comme btrfs. Avec ce syscall, il est possible d’ouvrir un fichier ayant un lien (hardlink) puis de demander que le fichier nommé soit une copie instantanée du fichier anonyme. Les deux fichiers partageront alors les mêmes blocs de données sur le système de fichiers, jusqu’à ce que l’un d’entre eux modifie un bloc. Mais en l’espèce, il n’y aura pas d’écriture ultérieure dans le fichier anonyme, après cet appel à ioctl(2). Il s’agit donc simplement d’une astuce qui permet de créer un lien vers le contenu du fichier anonyme, et donc de le publier. Le seul défaut de cette approche est qu’il faut utiliser un système de fichier compatible avec FICLONE, et ce n’est notamment pas le cas de ext4, qui est généralement le système de fichiers par défaut des distrubutions Linux.

Finalement, il existe une troisième méthode, elle aussi élégante, qui ne tire par partie d’une fonctionnalité particulière de certains systèmes de fichiers. Hélas, il est nécessaire de disposer de certains privilèges système pour ce faire : CAP_DAC_READ_SEARCH. CAP_DAC_READ_SEARCH permet de contourner cette protection du système de fichiers, ce qui est regrettable, car il s’agit aussi du privilège requis pour appeler le syscall linkat(2), avec l’option AT_EMPTY_PATH. Ce syscall cumulé à cette option permet de créer un lien à partir d’un descripteur de fichiers. Il permet donc de donner un nom à notre fichier anonyme, une fois celui-ci complet. Il peut être acceptable de donner CAP_DAC_READ_SEARCH à notre processus, si ce dernier est exécuté dans un chroot dans lequel cette permission ne permet pas au programme de gagner ou conserver des accès indûs à des ressources du système. Cette solution est donc probablement acceptable dans certaines conditions, qui doivent cependant être bien maitrisées.

Travailler sur une copie inaltérable du chiffré

Dans le cas d’un procédé de déchiffrement en deux passes, une pour la vérification d’intégrité, et une pour le déchiffrement en lui-même, il est possible d’utiliser les mêmes mécanismes que détaillés dans la section précédente de cet article pour obtenir une copie privée : créer un fichier anonyme dont le contenu sera alimenté par recopie (avec un surcoût en espace disque) ou le syscall ioctl(2) avec FICLONE pour obtenir une copie instantanée et qui ne pourra être modifiée par des processus ou taches tiers.

Déchiffrer un gros fichier en mémoire virtuelle

Tout ce qui est dans la mémoire virtuelle n’est pas nécessairement de la mémoire physique. Ainsi, il est possible d’obtenir une slice Go comportant le contenu d’un fichier, sans que celui-ci ne soit lu et recopié en RAM. De même, il est possible d’écrire dans une slice, qui n’est pas stocké en RAM, grâce à un syscall : mmap(2). Il nous est donc possible d’appeler box.Seal et box.Open sur de telles slices, et le résultat aura été calculé sans que le contenu des fichiers ne soit stocké en intégralité en RAM !

Hélas, les choses ne sont jamais aussi “simples”. Il a quelques petites subtilités supplémentaires, requises lorsqu’on effectue cette opération d’écriture dans une slice pointant vers un fichier placé en mémoire virtuelle avec mmap(2). D’une part, il est nécessaire que le fichier de destination soit de la bonne taille avant l’appel à mmap(2). Pour cela, on peut créer un fichier creux (sparse file), à l’aide de l’appel système fallocate(2). Ensuite, une fois l’écriture dans la slice accomplie, il est nécessaire d’appeler le syscall msync(2) afin de forcer le transfert de données depuis la mémoire virtuelle vers le fichier, avant d’effectuer l’appel à munmap(2), pour “défaire” la slice créée par mmap(2).

De même, mmap(2) est utilisé pour le fichier chiffré, mais il y a là aussi quelques subtilités. Il est notamment préférable de travailler sur une copie privée du fichier, plutôt qu’un fichier altérable par une source externe. En effet, le comportement n’est pas spécifié si un programme externe tronquait le fichier après que ce dernier ait été passé à mmap(2).

Enfin, lorsqu’on passe la slice recevant les données déchiffrées à box.Open, il convient de passer cette slice découpée avec [:0], afin de garder la capacité de la slice égale à la taille du fichier, mais de forcer sa longueur à 0. Ce faisant, box.Open ne procèdera pas à des réallocations du tableau qui sous-tend la slice. Il est, en effet, capital d’user de cette astuce, afin de continuer de travailler dans la mémoire virtuelle retournée par mmap(2) et ne pas se retrouver à travailler accidentellement en RAM.

Rassembler tout en un programme cohérent

Pour résumer tout ce qui a été abordé dans cet article :

pour traiter un gros fichier, il est préférable d’utiliser efficacement Linux que de risquer de créer des vulnérabilités en essayant de tronçonner le fichier ;
il est important de toujours travailler avec des copies privées des données, que ce soit le contenu chiffré et le contenu déchiffré ;
il est nécessaire d’avoir un contrôle sur la publication du déchiffré, notamment pour s’assurer que le contenu est intègre, et complet avant de le rendre accessible à des applications tierces.

Pour accomplir ces objectifs, il est possible d’exploiter les syscall Linux mmap(2), fallocate(2), msync(2), et ioctl(2) ou linkat(2).

Ce dépôt git contient un exemple d’algorithme mettant tous ces éléments en oeuvre, pour déchiffrer un gros fichier, de manière sécurisée.

TousAntiCovid Verif : vulnérabilité et développement défensif

Thu, 05 Aug 2021 00:00:00 +0200

L’application TousAntiCovid Verif sur Android nous a récemment régalé d’une vulnérabilité permettant d’afficher comme valides des pass sanitaires au format 2D-DOC manifestement invalides. Le bug n’intervient pas dans la vérification cryptographique de l’authenticité du pass sanitaire. Il se situe dans le reste du code métier qui vérifie la validité du pass, ne se déclenche que si l’appareil faisant tourner TousAntiCovid Verif utilise la locale anglaise.

Une vidéo de démonstration a été publiée par l’auteur de cet article. La démonstration a été effectuée avec la version 1.6.1 de TousAntiCovid Verif. La version 1.6.2 publiée le 4 août n’a pas corrigé la vulnérabilité.

Cet article propose d’étudier le bug, ses causes, et comment se protéger de tels bugs lorsqu’on pratique le développement défensif.

La vulnérabilité

Comme le code source de TousAntiCovid Verif n’a été publié que très tardivement, et que la vulnérabilité était présente dès cette publication initiale, il n’est pas possible de déterminer la date d’introduction du bug. En outre, tous les commits étant fusionné sous un unique commit à l’intitulé laconique “initial commit”, il n’est pas possible de faire une revue de code des changements dans le détail et de déterminer si l’auteur de ce bug a également commis d’autres impairs dans le code source de l’application. Bref, nous avons affaire à une parodie de code en sources ouvertes.

Toujours est-il que l’excellent @Gilbsgilbs a détecté, puis identifié la vulnérabilité. Elle se situe à aux lignes suivantes :

(oui, parce que non contents de faire un bug, ils font des copier-coller du bug pour être sûrs de l’avoir dans plusieurs branches de code…)

Au niveau le plus basique de l’analyse, le hic se situe sur le fait que status, en anglais, ne vaut pas Not Valid mais Invalid.

Cette variable est assignée ici : https://gitlab.inria.fr/tousanticovid-verif/tousanticovid-verif-android/-/blob/master/app/src/main/java/com/ingroupe/verify/anticovid/ui/result/ResultScanPresenterImpl.kt#L590

La valeur assignée à cette variable est, elle-même, assignée ici : https://gitlab.inria.fr/tousanticovid-verif/tousanticovid-verif-android/-/blob/master/app/src/main/java/com/ingroupe/verify/anticovid/service/document/StaticDataService.kt#L68

On peut noter que la valeur est issue d’un fichier de traduction : en français ou en anglais.

Le niveau zéro de la correction de cette vulnérabilité serait donc de remplacer Not Valid par Invalid… Mais il y a bien plus d’enseignements à tirer de cette erreur criante. Le reste de cet article s’attache à expliquer les stratégies de développement défensif visant à prévenir de ce genre de bugs.

Tester

Le code de TousAntiCovid Verif ne semble manifestement pas faire l’objet de tests unitaires (à l’exception de trois fichiers). Plusieurs indices le laissent penser. D’une part, il n’y a aucune trace de ces tests dans le dépôt de code source. Pour autant, on trouve des fichiers qui sont peu pertinents comme les fichiers de proguard pour rendre le code compilé moins facilement lisible par rétro-ingénierie. Cela pourrait donc laisser à penser qu’ils ont commité tout ce qu’ils avaient (à l’exception des fichiers exclus par .gitignore, et qui ne font pas mention des tests unitaires).

Ensuite, on peut voir que le code fautif était déjà présent dans le commit initial tandis que le fichier de langue contenant la chaine de caractères a été introduit dans un commit ultérieur. Il est donc probable que le code a été poussé en production, sans même avoir de fichier de langue de test pour vérifier que le code soit fonctionnel.

La première stratégie de développement défensif, qui constitue une bonne pratique standard de l’industrie, est de tester son code.

Utiliser les bons types (booléens) et les bonnes variables

Le code fautif effectue des comparaisons de chaines de caractères pour déterminer le statut de validité de la vérification cryptographique. La comparaison de chaines de caractère est fragile, en cela qu’elle repose sur la comparaison de nombreux octets qui doivent être tous justes pour que le test réussisse. À l’inverse, la comparaison d’une valeur booléenne ou même numérique (nulle ou non nulle, par exemple), aurait permis de discriminer de manière bien moins ambiguë et surtout moins susceptible à des erreurs comme celle vu dans TousAntiCovid Verif.

Le plus navrant avec TousAntiCovid Verif, c’est qu’il y a dans la même structure que celle dont est extraite cette chaine de caractères, un attribut isValid de type booléen et qui aurait pu être avantageusement utilisé pour ce test. C’est à se demander s’il y a eu une revue de code !

Utiliser des symboles plutôt que des littéraux

Comme discuté dans le point précédent, les chaines de caractères sont souvent des ennemis du code rigoureux. En effet, leur usage est bien souvent la cause de bugs lorsqu’elles contiennent de manière aléatoire des coquilles. Il est donc généralement considéré que leur usage sous la forme de valeurs hardcodées est une mauvaise pratique de développement. Il est généralement préférable d’utiliser des symboles de langages, comme des constantes nommées ou des symboles. L’usage de symboles présente l’avantage qu’en cas de coquille dans le nom du symbole : une erreur sera levée au moment de la compilation ou de l’interprétation, suivant le langage, et la coquille ne se traduira pas par une erreur de logique métier. Même Javascript, qui est un langage très souple, a un mode strict pour forcer la déclaration des variables, ce qui permet de détecter des coquilles dans les noms des variables.

Utiliser l’approche liste autorisée (“blanche”), plutôt que liste interdite (“noire”)

L’approche utilisée par le code fautif de TousAntiCovid Verif est celle de la liste interdite. En effet, le test vérifie que le status de validité du pass est “Non valide”. Si ce test échoue, alors le statut du pass est réputé valide. Cette approche a montré ses limites en de multiples occasions lors du développement d’applications sécurisées, car il est en général bien plus difficile d’envisager l’infinité des valeurs susceptibles d’être invalides, alors que les valeurs valides sont bien souvent en quantité très limitée.

Une manière de programmer de manière défensive le test fautif aurait été d’inverser sa nature : plutôt que de tester si le statut du pass est “Non valide”, il aurait été préférable de tester s’il n’était pas “Valide”. Ainsi, en cas d’oubli, de coquille, ou de toute autre raison inattendue, le résultat de la validation aurait été un échec et non un succès.

Émuler le pattern matching complet

Une méthode employée par des langages très rigoureux pour prévenir ce genre de bugs est également de proposer des instructions de contrôles exhaustives.

Par exemple, en Caml ou en Rust (parmi tant d’autres ; je ne fais que citer ceux que j’ai pratiqués), il existe du pattern matching dont l’exhaustivité des cas est vérifiée à la compilation. Si vous ne connaissez pas ce mécanisme, imaginez une sorte d’instruction switch qui refuse de compiler si tous les case possibles n’ont pas été énumérés.

Typiquement, ici, il aurait pu être pertinent d’utiliser une telle instruction de contrôle pour énumérer de façon exhaustive les cas “Valide”, “Non valide”, “Valid” et “Invalid” à l’exclusion de tout autre, sauf à encourir une erreur de compilation.

Même quand le langage ne dispose pas de telles instructions de pattern matching (ou même de switch !), il est possible de l’émuler.

Par exemple, en Python :

  if status in ["Non valide", "Invalid"]:
    handle_invalid_case()
  else if status in ["Valide", "Valid"]:
    handle_valid_case()
  else:
    raise NotImplementedError()

Employer les design patterns lorsqu’ils sont pertinents

Finalement, on peut noter que les développeurs de TousAntiCovid Verif n’ont absolument pas respecté les patrons de conception (“design patterns”) pourtant standard dans l’industrie. Je pense notamment à Model View Controler (MVC), introduit dans les années 80. En effet, les développeurs de TousAntiCovid Verif ont initialisé l’attribut status de type string de la structure DocumentSignatureResult avec le résultat d’une interrogation du module d’internationalisation. Cette initialisation est faite dès l’acquisition du code-barre 2D-DOC. Il s’agit donc d’une violation du patron MVC qui réserve l’affichage (éventuellement internationalisé) à la View, alors que l’initialisation du résultat de l’acquisition du code barre est clairement du code métier, devant être développé dans le Model.

Il est de bon aloi pour tout développeur, débutant ou moins débutant de se familiariser avec les patrons de conception classiques. Il est notamment chaudement recommandé de lire “Design Patterns: Elements of Reusable Object-Oriented Software”.

Conclusion

L’application TousAntiCovid Verif présente de nombreux signes d’une application développée sans respect des bonnes pratiques et des standards de l’industrie. L’absence de tests unitaires, et le manque de vigilance lors des revues de code (s’il y en a eu), indiquent également une très faible qualité code. Il est également permis de douter qu’un tel code ait été validé par l’ANSSI ou ait même subi un audit externe indépendant.

Compte tenu de la criticité de cette application dans la stratégie gouvernementale de déploiement universalisé du pass sanitaire comme panacée contre la COVID-19, et son installation sur les téléphones de centaines de milliers de citoyens/contrôleurs, il est regrettable de constater la faible qualité de son développement et l’incompétence manifeste de ses développeurs.

7 gestes barrières contre le pass sanitaire et pour préserver sa vie privée

Thu, 29 Jul 2021 00:00:00 +0200

Cet article présente une série de gestes barrières visant à lutter activement contre le pass sanitaire, et à préserver la confidentialité de ses données personnelles et médicales contenues dans le pass sanitaire.

Avertissement : je ne suis pas juriste. Tous les points listés ci-dessous me semblent légaux, au meilleur de mes connaissances actuelles, mais vous prenez vos responsabilités personnelles en les appliquant. Ce document ne constitue pas un conseil juridique.

1. Stratégie d’évitement : boycotter les lieux qui exigent le pass sanitaire

Le premier geste barrière est d’adopter une stratégie d’évitemment de l’emploi du pass sanitaire. En boycottant les lieux qui l’exigent, on créé une pression que nos gouvernants, adeptes du néolibéralisme, comprennent. Boycott = pas de revenu. Alors évidemment, certains diront que la stratégie d’évitemment est la seule option des non-vaccinés. Ce n’est pas faux. Mais c’est aussi une stratégie qui peut, et à mon sens doit, être entreprise par les vaccinés, par solidarité, et pour rejeter cette société de controle permanent qui nous est proposée. Nous sommes des citoyens, et nous méritons la liberté de choix, en conscience, et l’égalité en droit.

2. Stratégie d’obstruction : maximiser le temps requis pour faire le contrôle du pass sanitaire, sans toutefois refuser

Le deuxième geste barrière est à appliquer lorsque la stratégie d’évitemment n’est pas possible ou n’est pas appropriée. L’objectif reste le même : maximiser les pertes de profit, seul argument compris par les néolibéraux. Ce geste consiste à maximiser le temps requis pour qu’un controleur vérifie le pass sanitaire.

Même 10 secondes, multipliées par le nombre de personnes qui ont à présenter le pass sanitaire, cela créé des retards significatifs et un impact sur l’activité économique.

N’hésitez pas à présenter des pass sanitaires de type tests (PCR ou antigéniques) périmés (“oh, je me suis trompé ; le voici”), à baisser la luminosité du téléphone pour gêner la lecture du code barre. Galérez à trouver le bouton pour l’augmenter. Présentez une photocopie chiffonnée.

Tout ce qui montre que vous êtes en train de vous plier au contrôle mais qui cause un délai est bon à appliquer. En revanche, ne soyez pas agressif, ou violent, et ne refusez pas de présenter le pass, à moins d’appliquer au final la stratégie d’évitemment. Les contrôleurs suivent les instructions du gouvernement et préfèreraient sûrement faire le vrai métier. Blamez les vrais coupables du pass sanitaire.

3. Ne jamais diffuser son pass sanitaire, même partiellement masqué à des personnes n’ayant pas le besoin d’en connaitre

Votre pass sanitaire contient de nombreuses données personnelles et de santé. Il contient notamment, vos noms, prénoms, date de naissance. En outre la nature des données médicales qu’il contient dépend du type de pass que vous détenez. Pour un pass de type vaccinal, il contient des informations générales comme le nombre de doses reçues, le nombre de doses requises pour être protégé et un indicateur de complétion de votre parcours vaccinal. En outre, il contient le nom, la marque, l’agent prophylactique et la date d’injection du dernier vaccin reçu.

Ces informations sont lisibles par n’importe qui qui peut visualiser votre code barre et qui dispose d’un logiciel dédié. Certains sont librement accessibles sur le net. Cette petite vidéo vous en convainvra.

En outre, les code barres 2D (datamatrix et qrcode) contiennent des codes correcteurs d’erreurs. Un code correcteur d’erreurs, c’est un outil mathématique qui vise à compenser la destruction partielle du code barre. Dans le cas des qrcodes, c’est le même code correcteur d’erreurs que celui qui est utilisé sur les CD, pour compenser les micro-rayures, par exemple. Dissimuler une partie de votre code barre peut ne pas être suffisant pour empecher la lecture complète du code, et des données qu’il contient.

Finalement, la diffusion de son pass sanitaire avec l’intention d’encourager son emploi par un tiers est puni selon le code pénal de 75 000 € d’amende et de 5 ans de prison.

Le troisième geste barrière est donc de ne pas diffuser son pass sanitaire.

4. Privilégier le papier

Ce quatrième geste barrière consiste à ne pas numériser son pass sanitaire afin de limiter les risques de sa diffusion. Utiliser le pass sanitaire au format papier limite sa diffusion aux moments où vous sortez le pass de votre poche.

Si votre poche n’est pas un endroit sûr (?), alors un téléphone avec un code d’accès fort peut éventuellement mieux le protéger. Notez bien que vous n’avez pas besoin d’installer TousAntiCovid sur votre téléphone pour numériser le pass sanitaire. TousAntiCovid ne présente aucun intérêt particulier pour la numérisation du pass sanitaire. Une simple photo suffit ! Attention cependant à ne pas la stocker dans un dossier synchronisé avec le cloud (e.g. Google Photos). Si vous êtes d’humeur très prudente, il existe des logiciels qui permettent de stocker les photos de manière chiffrée sur votre téléphone. Rien que s’envoyer à soi-même (pléonasme pour insister sur le fait de ne pas communiquer son pass à un tiers) la photo avec un logiciel de messagerie comme Signal peut faire l’affaire.

5. Vérifier le logiciel utilisé par le controleur

Comme détaillé plus haut, votre pass sanitaire contient de nombreuses données personnelles et médicales. Or, vous devez les présenter à des inconnus. Comment leur faire confiance pour qu’ils ne stockent pas ces données à des fins commerciales, marketing, ou statistiques. La loi les en défend, mais si personne ne vérifie, il y a fort à parier que cela sera fait. Contrôlez les controleurs !

Ce cinquième geste barrière consiste à exiger du controleur qu’il lance l’application de vérification (par exemple TousAntiCovid Verif) depuis l’app store, devant vos yeux. Si le controleur refuse, insistez (stratégie d’obstruction). Finalement, en cas de refus ferme, appliquez la stratégie d’évitemment : il en va de la sécurité de vos données personnelles et médicales.

6. Refuser la vérification d’identité par les personnes non habilitées

Le contrôle d’identité est un acte qui ne peut être effectué que par certains membres des forces de l’ordre. Aucun contrôleur de pass sanitaire employé par le secteur privé, ni même certains agents des forces de l’ordre ne sont habilités à contrôler votre identité.

En conséquence, ce sixième geste barrière consister à refuser de présenter sa carte d’identité ou tout autre justificatif d’identité à ces personnes. Appliquez la stratégie d’obstruction en cas de refus, et faites intervenir les forces de l’ordre.

Lors d’un contrôle d’identité par les forces de l’ordre, privilégiez la preuve d’identité par témoignage, si vous êtes dans un groupe d’amis, plutôt que de présenter vos papiers d’identité. C’est peu connu, mais des personnes attestant de votre identité sont suffisantes pour satisfaire un contrôle d’identité. Il n’y a pas besoin de présenter des titres émis par l’État.

7. Ne pas convertir son pass avec TousAntiCovid

EDIT du 4 août 2021 : ce geste barrière n’est plus nécessaire. La version 3.6.0 de TousAntiCovid introduit un mécanisme de protection des données pendant leur transfert, préservant leur confidentialité lors de leur passage via les serveurs américains.

L’application TousAntiCovid permet la conversion des pass sanitaires français, au format 2D-DOC (datamatrix) en pass européens, de type DCC (Digital Covid Certificate). Cette conversion s’effectue par l’envoi du pass sanitaire à un serveur central, via des serveurs américains, qui peuvent voir le contenu du pass sanitaire dans son intégralité.

Ce septième geste barrière consiste donc à ne pas utiliser TousAntiCovid pour effectuer cette conversion. À la place, rendez vous sur Ameli.fr pour télécharger votre pass au format européen, ou rendez vous dans un centre de vaccination ou une pharmacie.

Conclusion

Je doute qu’il y a ait un jour une chanson de Mc Fly et Carlito pour diffuser ces gestes barrières, mais je vous encourage à les faire connaitre. N’hésitez pas à redistribuer cet article. Vous pouvez le republier, le commenter, en faire des travaux dérivés. Sa licence est CC-0.

Si vous souhaitez me contacter, je suis disponible sur Twitter ou le Fédiverse.

Merci à toutse de m’avoir lu.

Vive la Nation !

BONUS : gestes barrières relatifs à TousAntiCovid Signal

Limiter la diffusion d’informations personnelles dans les carnets de rappel (TousAntiCovid Signal)

Lorsque l’on se rend dans certains lieux, il est requis de s’enregistrer soit avec l’application TousAntiCovid en scannant un QRCode de l’établissement, soit en ajoutant ses informations de contact dans un carnet de rappel papier.

Dans le carnet de rappel papier, il est demandé de renseigner son nom, prénom, et une information de contact (généralement le numéro de téléphone).

Ce geste barrière consiste à donner de faux noms et prénoms, car ils ne sont pas utiles pour la finalité du traitement, et une adresse email à la place du numéro de téléphone. Cette adresse email peut être une adresse email temporaire, comme celles proposées par le service Yopmail. Ainsi, vous restez contactables en cas de cluster, mais vous ne diffusez aucune information personnelle durable. Si la personne en charge de l’enregistrement dans le carnet de rappel refuse l’usage d’une adresse email, prétexter que vous n’avez pas de téléphone, ou que vous êtes sur un numéro temporaire car vous changez d’opérateur.

Utiliser ou non TousAntiCovid Signal avec prise de photo d’un QRCode est un sujet complexe en matière de respect de la vie privée ; il y a du pour et du contre. Il n’est donc pas possible de donner une recommandation universelle quant à son emploi ou non.

Régénérer très fréquemment les QRCodes TousAntiCovid Signal

Si vous êtes gestionnaire de lieux devant afficher des QRCode TousAntiCovidSignal, ce geste barrière consiste à renouveller le plus fréquemment possible le QRCode que votre clientèle peut scanner. Un bon rythme pourrait être une fois par jour, à intégrer dans les gestes du quotidien lors de l’ouverture de l’établissement.

Changer le code régulièrement aide vos clients à préserver leur vie privée lorsqu’ils se déclarent malades. Cela limite la possibilité de désanonymiser le malade, et de tracer ses lieux de fréquentation d’une manière disproportionnée par rapport à la finalité de détection de clusters.

Vacciné et contre le pass sanitaire

Mon, 19 Jul 2021 00:00:00 +0200

Un billet d’humeur contre l’extension du pass sanitaire, son principe en général et ses dérives autoritaires.

Je suis contre le pass sanitaire, et je suis pourtant vacciné.

Comme il semble importer à certains de comprendre qui parle pour ensuite savoir l’écouter, voici un court résumé sur ma personne. Les gens intéressés uniquement par le fond peuvent sauter la prochaine section de ce billet.

Qui suis-je ?

Je suis Florian Maury. J’ai 38 ans, et je suis en surpoids (IMC 29.5), sans autre comorbidité connue. Je ne suis ni rattaché, ni sympathisant d’aucun parti politique. Mon seul engagement politique significatif est l’antispécisme.

Pendant la pandémie, mon emploi a été maintenu et j’ai pu le continuer, en bénéficiant du télétravail à 100%. Ce jour encore, je suis en télétravail.

Ma compagne, elle, travaille avec des enfants et est donc exposée à un risque de contamination plus important que d’autres corps de métier.

J’ai fait le choix de me vacciner parce que j’ai considéré les risques de ne pas me vacciner, et ceux de me vacciner, et j’ai jugé que la balance bénéfices/risques, dans mon cas, penchait vers l’intérêt d’être vacciné. C’est un calcul personnel, effectué exclusivement sur des considérations égoïstes, et à aucun moment pour protéger les autres. À ma place, vous auriez pu faire un choix différent ; chacun son corps.

Pour protéger les autres, je respecte les gestes barrières depuis la première heure. J’ai porté un masque, conformément aux directives sanitaires, y compris en forêt, lorsque je croisais d’autres promeneurs (ce qui pourra paraître hygiéniste à certains). En fait, je portais même un masque dans les transports en commun et sur mon lieu de travail AVANT la pandémie de covid-19, lorsque j’étais malade. Par respect pour mes collègues de travail, et mes compagnons de voyage de la région parisienne.

Quels sont les problèmes du pass sanitaire ?

Le pass sanitaire présente de nombreux problèmes, sur le plan technique, sur le plan juridique et sur le plan éthique. Dans ce billet, il pourra être question du vaccin, puisque les deux sont quasiment indissociables depuis les annonces d’Emmanuel Macron, ce 12 juillet 2021.

Aspect technique

Depuis la parution du pass sanitaire, de nombreuses critiques sont formulées sur sa réalisation technique.

Dans cet article, Piotr Chmielnicki et moi-même avons analysé le contenu du pass sanitaire, et l’avons comparé aux annonces gouvernementales, aux déclarations sur les sites gouvernementaux, et à l’avis de la CNIL.

Nous avons révélé que le pass contenait de nombreuses informations sans rapport avec la finalité du pass, dont des informations médicales, et des informations affectant la vie privée, et pouvant causer des risques dans le cadre du vol d’identité. Ces affirmations ont été confirmées par de nombreuses études indépendantes et publiées à la même période. On pensera à celle de Mathis Hammel, celle de Christian Quest, aux excellentes analyses de TousAntiCovid Verif par Gilbsgilbs, ou à l’implémentation de preuves de concept comme sanipasse.fr et celle de Bastien Le Querrec, de la Quadrature du Net.

Il est intéressant de noter que dans son avis du 12 mai, la CNIL disait d’ailleurs à juste titre :

La Commission estime que l’accès à un lieu ne saurait, par principe, être conditionné à la divulgation d’informations relatives à l’état de santé des personnes, y compris s’agissant de lieux qui n’ont pas trait à la vie quotidienne. En effet, si la vérification de l’identité des personnes peut être exigée pour l’accès à certains lieux, l’exigence de divulgation d’autres informations relatives à la vie privée des personnes, a fortiori de données sensibles, ne saurait être admise qu’au regard de la nature du lieu ou de l’événement fréquenté et dans le cadre de la stricte application du principe de minimisation de la collecte de ces données. La possibilité d’accéder aux lieux de sociabilité sans avoir à prouver son état de santé fait partie des garanties apportées à l’exercice des libertés et participe à dessiner une frontière raisonnable entre ce qui relève de la responsabilité individuelle et du contrôle social.

En outre, principalement grâce à Gilbsgilbs, le peuple français a pu prendre conscience que TousAntiCovid Verif fuitait de manière systématique, à chaque scan d’un pass, le contenu de ce pass sanitaire (c’est-à-dire nos données privées et de santé) à un acteur américain (Akamai), puis à une société française : IN Groupe, l’imprimerie nationale. L’application TousAntiCovid Verif pouvait donc être transformée en une application de surveillance de masse, permettant de savoir qui se rendait où et quand. Cette fuite de données était, par ailleurs, parfaitement injustifiable d’un point de vue technique, d’après de nombreux spécialistes en cryptographie. D’ailleurs, Olaf et le créateur de sanipasse.fr l’ont prouvé en fournissant au public des vérificateurs de pass sanitaires hors-ligne, c’est-à-dire sans connexion à Internet nécessaire. En outre, TousAntiCovid Verif contenait des logiciels de tracking des utilisateurs provenant de Google.

De nombreux journaux ont relayé l’information, parmi lesquels NextInpact, Numerama, 01net, Mediapart, Contrepoints, Le Monde Informatique. Il y eut aussi d’autres formes de relais dont Developpez ou iGeneration. Finalement, le gouvernement a annoncé, lors d’une conférence de presse, l’élaboration dans l’urgence d’un mode “offline” (hors-ligne). Cette version avec un mode offline a été mise en ligne deux jours après. À ce jour, le code source de TousAntiCovid Verif n’a toujours pas été publié, contrairement aux annonces gouvernementales effectuées durant cette même conférence de presse.

Depuis, Olaf et Gilbsgilbs ont pu noter que la fonctionnalité de conversion des pass sanitaires français en pass sanitaires européens, par l’entremise de TousAntiCovid, avait recours à l’envoi du pass sanitaire dans son intégralité, toujours via les serveurs américains d’Akamai, puis via les serveurs d’IN Groupe.

Le gouvernement a annoncé une migration vers Orange, afin d’éviter la fuite des données en Amérique. À l’instar de la publication du code source de TousAntiCovid Verif, le cierge est allumé…

Aspect juridique

Le pass sanitaire présente de nombreuses faiblesses juridiques.

Pour commencer, le pass sanitaire a failli être retoqué par le Parlement puisqu’il a été nécessaire de faire deux votes, le premier ayant eu pour résultat son rejet. C’est au prix d’amendements, à l’initiative du Modem, visant à restreindre la durée du pass, que celui-ci a été finalement accepté par le Parlement.

Parmi les dysfonctionnements persistants, on note ainsi dans la loi n° 2021-689 du 31 mai 2021 relative à la gestion de la sortie de crise sanitaire :

La présentation, sur papier ou sous format numérique, des documents mentionnés au premier alinéa du présent B est réalisée sous une forme ne permettant pas aux personnes habilitées ou aux services autorisés à en assurer le contrôle de connaître la nature du document ni les données qu’il contient.

Or il se trouve que le pass sanitaire est librement lisible par tous, à l’aide d’un lecteur de code barre 2D, et qu’il contient les noms, prénoms, date de naissance, date de la dernière injection, agent prophylactique, état du cycle vaccinal, et nom et marque du vaccin, dans le cas d’un pass sanitaire de type vaccinal. Des informations différentes sont présentées dans le cas d’un pass sanitaire de type test. Le pass est donc contraire à cette loi en cela qu’il permet aux personnes habilitées ou aux services autorisés à en assurer le contrôle de connaître la nature du document et les données qu’il contient. Peu importe que l’application TousAntiCovid Verif dissimule certaines informations ; n’importe quel lecteur de code barres peut en révéler le contenu intégral.

En outre, il est attendu, pour qu’il soit efficace, que les personnes habilitées ou les services autorisés à en assurer le contrôle puissent vérifier l’identité du porteur du pass, notamment en comparant les noms, prénoms et date de naissance du pass avec ceux sur une pièce d’identité. Or, la vérification de l’identité d’une personne est encadrée par la loi. En l’occurrence, sur le site Services Publics.fr, on peut lire que le contrôle d’identité est limité aux personnes suivantes :

Les forces de l’ordre (police, gendarmerie) habilitées à faire un contrôle d’identité sont les suivantes :

Officier de police judiciaire (OPJ)

Agents de police judiciaire, sous la responsabilité de l’OPJ

Certains agents de police judiciaire adjoints, sous la responsabilité de l’OPJ Un douanier peut aussi faire un contrôle d’identité dans certains cas. A savoir : un agent de police municipale peut relever votre identité lorsqu’il constate une contravention. Par exemple, une contravention de stationnement. Toutefois, il n’est pas autorisé à contrôler votre identité.

Il convient donc de noter que ni les barmen, ni les restaurateurs, ni les agents de sécurité des boîtes de nuit, des centres commerciaux, des hôpitaux, des cinémas et théâtres, ou d’aucun lieu de loisirs ne sont habilités à demander aux citoyens français leurs papiers d’identité pour en faire le contrôle. Alexandre Horn informe également dans ce sens, dans les colonnes de Libération.

Par ailleurs, la Quadrature du Net a saisi le Conseil d’État, le 9 juin, à propos du pass sanitaire, via la procédure de référé-liberté. Bien que le Conseil d’État soit censé rendre un verdict en deux jours, dans ce cadre de procédure, il a fallu attendre près d’un mois pour obtenir un jugement. Il s’agit là d’un délai noté comme anormalement long par de nombreux juristes, même dans les circonstances exceptionnelles de cette pandémie.

Le verdict du Conseil d’État, rendu le 6 juillet a soigneusement évité d’adresser certains points cruciaux de la plainte, a énoncé des banalités sans rapport avec la plainte (avaient-ils perdu le dossier ?), et n’a finalement pas suspendu le pass sanitaire pour les raisons suivantes (liste non exhaustive) :

“Il résulte de l’instruction et il n’est d’ailleurs pas contesté que le traitement TousAntiCovid Vérif effectivement mis en oeuvre par le ministre de solidarités et de la santé repose sur un contrôle local des données contenues par les justificatifs (” mode off-line “), et que le Gouvernement a renoncé à tout échange de données avec le serveur central de la société prestataire lors de la vérification des justificatifs présentés sur le téléphone mobile de la personne entendant se prévaloir du passe sanitaire”. On notera que ce “renoncement” du gouvernement coïncide avec les révélations faites par le groupe de citoyens mentionnés dans la section “Aspects techniques” de ce billet.
“Son usage a été restreint aux déplacements avec l’étranger, la Corse et l’outre-mer, d’une part, et à l’accès à des lieux de loisirs, d’autre part, sans que soient concernées les activités quotidiennes ou l’exercice des libertés de culte, de réunion ou de manifestation”.

Or, avec l’extension du pass sanitaire annoncée par le Président de la République ce 12 juillet 2021, soit 6 jours après le verdict du Conseil d’État, il apparaît très clairement que le contexte sanitaire n’a pas changé du tout au tout en ces 6 jours, et que le pass concerne désormais les activités quotidiennes.

Sur le plan juridique, il y a également la question de la proportionnalité de l’atteinte à la liberté de circulation, et au principe d’égalité, au vu de l’objectif. Étant donné que la France est l’un des rares pays à avoir choisi de déployer un tel dispositif généralisé, il me semble raisonnable d’en douter. Hélas, comme l’explique Dominique Bompoint dans son article dans Le Figaro, il n’y a rien à attendre du Conseil Constitutionnel.

Le recours déposé par Piotr Chmielnicki auprès de la CNIL, avec en copie le Défenseur des droits, n’a pas abouti. Le Défenseur des droits s’est défaussé en pointant vers son article à ce sujet, publié en mai, à une date antérieure à la plainte, et qui ne répond à aucun des éléments techniques avancés dans la plainte. On peut notamment y lire “Le projet de loi a fait l’objet de modifications par le Sénat, maintenues par la commission mixte paritaire, dont certaines vont dans le sens des recommandations de la Défenseure des droits, en particulier l’intégration dans le texte de garanties complémentaires concernant le « pass sanitaire », en vue de protéger les droits et libertés, notamment les données de santé”. Or, il s’avère que même si la loi contient effectivement ces garanties, l’implémentation du pass sanitaire par le gouvernement français en fait fi. Le Défenseur des droits n’a donc visiblement pas jugé utile de vérifier. La CNIL n’a fait qu’accuser réception, plus d’un mois après le dépôt de plainte. Elle n’a pas statué sur le fond pour le moment, près de deux mois après la réception du recommandé avec accusé de réception.

Aspect éthique

Le pass sanitaire devient moralement un pass vaccinal. En effet, le déremboursement des tests sans prescription médicale revient à ce que les personnes ne souhaitant pas se faire vacciner, ou ne le pouvant pas pour raisons de santé, soient contraintes de se vacciner, ou à débourser plusieurs centaines d’euros par mois, pour vivre normalement. Il s’agit là d’une violence sociale, particulièrement grave, contre les personnes en situation de précarité, ou en situation de santé complexes. Criant est le manque d’humilité des instances dirigeantes sur leur capacité à capturer l’infinie complexité des situations individuelles et à asséner une solution universelle.

Le pass sanitaire va donc créer deux castes de citoyens : les vaccinés et les non-vaccinés. Le Président de la République soulignait d’ailleurs lors d’un entretien : “Vos droits ne peuvent pas être les mêmes parce qu’ils supposent des devoirs”. Dès lors, la notion d’égalité, énoncée par la Constitution française, vole en éclat. Cette division participe, d’ailleurs, à créer des tensions entre citoyens, et détourne l’ire de la foule de la caste des dirigeants vers celle des non-vaccinés. Cette diversion participe activement à dédouaner et déresponsabiliser la caste politique de la situation actuelle, alors qu’ils en sont les premiers fautifs.

Hélas, les pauvres hères de la caste des non-vaccinés (ou devrait-on les appeler “intouchables” ?) ne seront pas tous relégués ainsi par choix. Même en admettant que tous souhaitent se faire vacciner, il n’y a pas assez de doses pour vacciner toute la population âgée de 12 ans et plus. Avec 50 millions d’adultes âgés de 20 ans et plus, il faudrait au minimum 100 millions de doses pour tous les vacciner. C’est faire l’hypothèse qu’aucune dose n’a été perdue, et qu’il faut deux doses pour chaque personne. Or, depuis le début de la pandémie, la France n’a reçu que 71 millions de doses. Bien que nous soyons censés en recevoir 9.6 millions d’ici fin juillet, et 14 millions en août (source : JT de France 2 du 17 juillet), le chiffre de 100 millions ne sera pas atteint. Et c’est sans compter la vaccination des 12 à 20 ans. Le gouvernement a donc choisi délibérément, et en connaissance de ces chiffres publics, une stratégie qui plongera des millions de citoyens dans la difficulté, qu’ils soient pour ou contre le vaccin, et pour ou contre le pass sanitaire. Une stratégie antisociale, déshumanisante, déresponsabilisante, infantilisante.

Finalement, on peut s’interroger sur le caractère éthique d’un très haut taux de vaccination dans les pays développés, imposé par le gouvernement en France avec le pass désormais vaccinal, quand 87% de la population mondiale n’a pas reçu deux doses. Freinerait-on plus efficacement l’épidémie en diminuant la propagation du virus (et donc ses chances de mutation, qui affecteront également les vaccinés du premier monde) dans les pays du tiers monde ? Probablement.

Conclusion

Le pass sanitaire, maintenant devenu pass vaccinal, représente à lui seul la déchéance de tous les principes énoncés par notre devise nationale. Séparation des citoyens en castes ; privation de libertés pour les non-vaccinés volontaires et involontaires ; obligation vaccinale pour certains corps de métiers, sous peine d’être licenciés de plein droit ; tensions accrues entre les citoyens menant à des actes de violences et de vandalismes. La défaite est totale. L’individualisme est la règle, et dès lors que certains ont leur fameux sésame, ils se contrefichent, et pire, jugent, leurs compatriotes, au lieu de se montrer solidaires et de comprendre qu’ils seront peut-être les prochains exclus, au détour d’une nouvelle loi liberticide des gouvernants.

Un passeport n’a jamais été le symbole de la liberté. Un passeport est un passe-droit accordé à des personnes qui peuvent outrepasser une nouvelle règle restrictive, afin que leurs détenteurs puissent continuer de procéder comme avant. N’oublions jamais les laissés pour compte qui ne jouissent pas de ce passe-droit, et souvenons-nous que nous serons peut-être les prochains à être laissés sur le carreau.

Je souhaiterais terminer ce billet avec le cri du Général Kellermann lors de la bataille de Valmy, où les forces prussiennes ont été repoussées par l’armée des citoyens : “Vive la Nation !”. Faisons trembler la terre, et pourquoi pas l’Élysée !

Pass sanitaire et vie privée : quels sont les risques ?

Thu, 03 Jun 2021 18:00:00 +0200

Cet article est sous licence CC-BY-ND.

Auteurs :

Les auteurs de cet article peuvent être contactés :

par email : florian.maury-pass-sanitaire VOUS-SAVEZ-QUOI broken-by-design.fr
par chat, avec Matrix : #pass-sanitaire:matrix.piotr.paris

Mise à jour importante du 10 juin 2021 : l’application TousAntiCovid Verif, dans sa dernière version à la date d’écriture de cette ligne, ne fait plus appel à un serveur centralisé pour valider les pass sanitaires. Elle n’envoie plus de données à un prestataire américain. Elle ne contient plus de services Google Firebase. Hélas, le reste de l’article et de la vidéo continuent d’être pertinents pour l’heure. La Quadrature du Net effectue une action en justice en ce sens.

Il existe une vidéo compagnon, pour ceux qui préfèrent regarder que lire.

Sur Peertube :

En téléchargement : Haute qualité (1300MB) / Faible qualité (90MB)

Ce document porte sur le pass sanitaire, qui est en train d’être mis en place par le gouvernement français et qui entrera en vigueur le 9 juin 2021. Il vise à mettre au jour de fausses informations diffusées par certains membres du gouvernement, à expliquer et à illustrer pourquoi le pass sanitaire, tel qu’il est conçu, met en danger la vie privée, mais aussi des données médicales des citoyens. En outre, il accroit le risque de vol d’identité.

Le pass sanitaire est présenté sous la forme d’un code barre en deux dimensions, appelé datamatrix. Ce code barre, comme son nom l’indique, encode des informations. Il est en cela similaire aux codes barres des produits que vous achetez en grande surface, et que vous passez à la caisse. Il est juste en deux dimensions et contient plus d’information. Au lieu d’un numéro qui sert à indiquer à la caisse enregistreuse la nature du produit que vous achetez, ce qui lui sert à connaitre le prix à imputer, le code barre du pass sanitaire contient vos informations personnelles et des informations relatives à la vaccination. L’encodage de ces informations ne constitue pas une mesure de protection des données puisque n’importe qui équipé d’un dispositif de lecture de code-barres peut acquérir les données qui ont été encodées. Le pass sanitaire ne fait pas exception.

D’après le site Service Public.fr, le pass sanitaire contient les informations suivantes :

nom, prénom ;

date de naissance ;

type de certificat et résultat éventuel (test PCR ou antigénique ou vaccination première et seconde dose) ;

type de vaccin le cas échéant ;

date et heure du certificat.

Le site gouvernement.fr indique la même liste.

Nous avons analysé le contenu du pass sanitaire, à l’aide d’outils grands publics, trouvables sur n’importe quel Store d’applications, comme le Google Play Store ou l’Apple Store. Par exemple, Barcode Scanner de ZXing Team sur le Google Play Store.

Nous affirmons que la liste dressée par les sites gouvernmentaux est incomplète.

Le pass est composé de 3 types d’informations :

des informations techniques, qui permettent de vérifier l’authenticité du pass sanitaire ; on y retrouve des informations sur l’émetteur du pass sanitaire, ainsi que la date d’émission, et le sceau d’authenticité (une signature numérique) ;
des informations personnelles : nom, prénom et date de naissance ;
des informations de santé : le type de molécule injectée, le nom du vaccin reçu, le nombre de doses reçues, la date de vaccination et si ce nombre est suffisant pour être protégé de manière optimale pour la personne vaccinée.

Au-delà de ces informations de santé, il est également possible d’inférer des informations de santé encore plus privées sur certains citoyens : ont-il déjà été infectés par la COVID-19 (besoin que d’une seule dose) ? Sont-ils immunodéprimés (besoin de trois doses) ? Sont-ils parmis les citoyens prioritaires pour recevoir des injections tôt dans le calendrier vaccinal ?

Ces informations dépassent largement le cadre et la finalité du pass sanitaire.

Les sites gouvernementaux (comme gouvernement.fr et servic public.fr) se veulent cependant rassurants. Ils précisent :

Pour accéder à un lieu, un établissement ou un événement, seuls les ouvreurs engagés par les organisateurs pourront lire :

nom et prénom ;

date de naissance ;

accès autorisé ou accès refusé, en fonction des règles sanitaires imposées pour accéder au lieu (les ouvreurs ne pourront pas connaître le détail du type de certificat sanitaire présenté).

De même, M. Cédric O, secrétaire d’État, chargé de la transition numérique, indique dans son interview exclusive donnée au journal Le Parisien :

Comment les professionnels vérifieront-ils le pass sanitaire numérique ?

D’ici le 9 juin, nous aurons déployé l’application de lecture appelée TousAntiCovid Verif. Pour les compagnies aériennes, il y aura une version spécifique car elles ont obligation d’avoir accès au contenu détaillé, avec la date de vaccination, le type de vaccination etc. Elles pourront la télécharger sur les stores, avec un contrôle d’accès par identifiant. En revanche, les organisateurs d’évènements ou les lieux concernés par le pass sanitaire en France, ne connaîtront pas ces informations. Ils ne sauront que le nom, le prénom et la date de naissance de la personne concernée et ne verront apparaître que « vert » ou « rouge » pour valider ou non l’accès. Pour eux, l’application sera en accès libre sur les stores.

Comme nous l’avons démontré plus tôt dans ce document, il n’existe aucune protection contre l’obtention de l’ensemble des données contenues dans le pass sanitaire. Tout lecteur de code barre grand public est suffisant. Il n’est nul besoin d’être membre d’une compagnie aérienne pour obtenir une application aux pouvoirs supérieurs permettant d’acquérir des informations de santé sensibles sur une personne qui exposerait volontairement ou par mégarde son pass sanitaire, sur Internet, dans une file d’attente, ou à un personnel de sécurité à l’entrée d’un événement.

Il existe également d’autres parties qui pourraient être mises au courant du contenu de votre pass sanitaire. D’après un tweet du compte TousAntiCovid du 20 mai 2021:

#COVID19 | Les autorités compétentes peuvent lire vos certificats de tests avec l’application #TousAntiCovid Verif. Seule la signature du certificat est vérifiée par un serveur dédié d’@IN_Groupe respectant toutes les règles de sécurité des systèmes d’information.

Cette assertion est également corroborée par la demande de l’application TousAntiCovid Verif d’avoir un accès complet au réseau, lors de son installation. De même, on trouve dans les entrailles de l’application TousAntiCovid Verif, une URL (https://portail.tacv.myservices-ingroupe.com), et ainsi qu’un fichier comportant une fonction call2dDoc, qui fait une requête HTTP avec des paramètres 2ddoc, latitude et longitude. Enfin, lorsque l’on scanne un pass sanitaire en mode avion, TousAntiCovid Verif affiche un message d’erreur “Erreur de connexion” et n’affiche pas de résultat.

Il n’est pas aisé de déterminer clairement ce que fait cette fonction, car l’application TousAntiCovid Verif, contrairement à l’application TousAntiCovid, n’est pas en sources ouvertes. Néanmoins, gilbsgilbs a su faire de l’ingénierie inverse et il confirme nos craintes et observations.

Il convient de noter qu’une telle communication réseau génère des meta-données de communication avec le serveur ; il y a notamment l’adresse IP de l’équipement faisant tourner l’application TousAntiCovid Verif. Cette adresse IP permet la géolocalisation de l’équipement faisant tourner TousAntiCovid Verif, par l’entremise des opérateurs de télécommunication, comme Orange.

En croisant ces données, l’État serait donc en mesure de dresser un listing des citoyens et de leurs lieux de fréquentation, grâce au pass sanitaire.

Il convient de noter que l’envoi des données (complètes ou sous la forme d’empreintes cryptographiques) n’est nullement nécessaire pour la vérification de la signature numérique du pass sanitaire. Toutes les informations nécessaires à cette vérification sont publiques. La validation du pass sanitaire peut donc être accomplie sans problème directement par l’application de lecture du code barre. Si un lecteur de code barre est jugé par le gouvernement comme étant suffisamment de confiance pour lire les données médicales et afficher un verdict, il l’est aussi pour la vérification de la signature.

Nous ne sommes pas les seuls à dénoncer le pass sanitaire, et la quantité d’informations qu’il recèle. La CNIL, la Commission Nationale Informatique et Liberté, a été saisie et a rendu un avis le 12 mai 2021 :

La Commission considère qu’un dispositif visant à ne permettre la vérification que sur la base d’un résultat de conformité réduirait considérablement les données accessibles aux personnes habilitées à vérifier le statut des personnes concernées, et notamment de ne pas indiquer si elle a été vaccinée, a fait un test ou s’est rétablie d’une infection antérieure à la COVID-19, conformément au principe de minimisation des données

Un tel dispositif implique le téléchargement, du côté des vérificateurs, d’une application permettant de décoder les signaux, probablement sous forme de code-QR, qui contiendront l’information permettant de faire apparaître un résultat vert ou rouge et d’en vérifier l’authenticité. Dans l’hypothèse où ce code-QR correspondrait aux codes actuellement disponibles dans la fonctionnalité « TousAntiCovid Carnet », la Commission relève que celui-ci contient plus d’informations (nom, prénom, date de 8 naissance, date d’examen, type d’examen, résultat). Il est donc possible, dans ce cas, qu’un tel dispositif soit détourné de façon à ce que le lecteur (téléphone ou lecteur dédié) lisant le code-QR puisse accéder à davantage d’informations qu’un simple résultat de conformité (couleur verte ou rouge). Elle invite le Gouvernement à s’assurer de la mise en œuvre des mesures opérationnelles et à fournir, aux personnes gérant les lieux, événements et établissements toute documentation nécessaire (communication sur les lieux, établissements ou évènements soumis au dispositif, mise en place d’une signalétique visible sur place, etc.) permettant de se prémunir de ce risque.

Hélas, aucune “mesure opérationnelle” significative n’a été mise en place par le gouvernement. Il aurait, par exemple, été possible d’émettre plusieurs pass, contenant plus ou moins d’information, en fonction du type de lieu (e.g. salles de spectacle ou aéroports). Cela aurait été, de surcroit, conforme au principe de minimisation des données en regard de la finalité, comme indiqué par la CNIL ou par le Règlement Général de la Protection des Données (RGPD).

Nous affirmons donc, que la mise en oeuvre du pass sanitaire, en l’état, constitue un risque significatif pour la vie privée, pour les données personnelles (risque de vol d’identité accru) et pour les données médicales des citoyens.

Nous affirmons qu’il contient des informations sensibles sans aucun rapport avec la finalité énoncée.

Nous affirmons qu’il peut être détourné pour pister les citoyens.

Nous demandons le retrait du pass sanitaire dans sa forme actuelle.

Nous invitons les citoyens français à rejoindre cet appel et à déposer une plainte auprès de la CNIL et du défenseur des droits contre le pass sanitaire dans sa forme actuelle.

Nous invitons les citoyens européens et les responsables politiques à s’opposer au pass sanitaire européen qui est peu ou prou calqué sur le pass sanitaire français, avec les mêmes informations, les mêmes dérives et les mêmes risques.

Si un nouveau pass sanitaire français est créé, nous exigeons le retrait des informations qui sont sans rapport avec la finalité. Si certaines informations sensibles doivent figurer dans le pass sanitaire, plusieurs pass doivent être remis en fonction du besoin d’en connaitre des employés de sécurité filtrant l’accès à un lieu.

Finalement, nous exigeons que la vérification de l’authencité du pass sanitaire s’effectue localement par une application de vérification en source ouverte, sans avoir besoin de la permission d’accès au réseau.

M. Cédric O s’indigne, dans son interview au Parisien :

Il y a une forme d’aberration dans la crispation sur ces sujets-là. Comme si nous avions si peur de la solidité de notre démocratie et de notre état de droit, qu’on ne puisse pas se doter de ces outils.

Nous affirmons que la confiance ne s’exige pas, mais qu’elle s’acquiert. Nous affirmons que son acquisition passe par la vérité, la transparence, et des actes en accord avec les paroles et les engagements. Sur ce point, le pass sanitaire est un échec.

De surcroit, les risques de détournement ou de mésusage évoquées dans ce document devraient au minimum avoir été considérés avec circonspection par les responsables politiques. S’ils l’avaient été, le pass sanitaire dans sa forme actuelle aurait été rejeté selon le principe de prudence, au nom de la protection des citoyens.

Autres documents :

un excellent article de Christian Quest, sur ce même sujet, qui confirme nos observations ;
un fil de tweets de Mathis Hammel, qui faisait une analyse similaire à la nôtre, au même moment où nous tournions les rushs de notre vidéo ;
une application Android en preuve de concept, qui collecte et extrait les informations de pass sanitaires scannés, a été développée par Bastien Le Querrec ;
une version alternative de TousAntiCovid maintenue par Olaf, qui contient notamment un lecteur/vérificateur du pass sanitaire au format 2D-DOC, prouvant la faisabilité d’une lecture et d’une vérification en local, sans avoir besoin des serveurs d’IN Groupe ;
un fil de tweets de Pixel de Tracking, qui indique des trouvailles similaires à celles sur Android : le pass sanitaire est envoyé aux serveurs d’IN Groupe en totalité ;
une application web qui vérifie les pass sanitaires de manière autonome ;
l’article de presse de NextInpact
l’article de press de Numerama
l’article de Developpez
l’article d’igen
l’article de 01net
l’article de lemondeinformatique.fr
l’article de Mediapart
l’article de Contrepoints
l’article de NextInpact sur la réaction du gouvernement le 8 juin, en conférence de presse
la délibération de la CNIL du 7 juin (PDF)

Remerciements : Aurélien Hugues, Émilie Gill, Stéphane Bortzmeyer

Historique d’édition :

5 juin 2021 à 13h55 : ajout des références aux travaux de gilbsgilbs et de Christian Quest
5 juin 2021 à 14h35 : ajout du fil de tweets de Mathis Hammel
5 juin 2021 à 16h20 : ajout des remerciements
6 juin 2021 à 8h45 : ajout de l’application en preuve de concept
6 juin 2021 à 11h50 : ajout de la version alternative de TousAntiCovid par Olaf
7 juin 2021 à 12h40 : corrections de coquilles, précisions sur les auteurs, rajout d’une réference à NextInpact, reformulation de la contribution d’Olaf
7 juin 2021 à 13h30 : ajout du fil de tweets de Pixel de Tracking
8 juin 2021 à 8h50 : ajout des articles de Numerama, de Developpez, et du code source de sanipasse
8 juin à 19h15 : ajout des articles d’igen, de 01net et de lemondeinformatique.fr
9 juin à 13h35 : ajout des articles de Mediapart, de Contrepoints, de Nextinpact, et la délibération de la CNIL du 7 juin ; remerciements à Stéphane Bortzmeyer sans lequel la diffusion de cet article n’aurait pas été celle qu’elle a connue
10 juin à 8h25 : ajout du bandeau de mise à jour en tête d’article concernant TousAntiCovid Verif

Attestation COVID-19 en ligne : un outil de surveillance globale sur Internet ?

Wed, 25 Nov 2020 22:00:00 +0000

Cet article est sous licence CC-BY-NC-ND.

Les auteurs de cet article peuvent être contactés sur :

le numéro Signal : +33687414960 (Florian Maury)
le compte Twitter : Piotr Chmielnicki - Twitter
le compte Twitter : Florian Maury - Twitter

Synthèse non-technique

Le Ministère de l’Intérieur, par l’intermédiaire du site permettant la génération d’attestations de déplacement dérogatoire COVID-19, est en mesure d’assurer un pistage nominatif des citoyens, en usant de procédés comparables à ceux qu’emploient les régies publicitaires et d’autres spécifiques aux services de renseignement. Il est impossible de prouver qu’ils ne le font ou ne le feront pas. Les auteurs de cet article ne détiennent pas, à ce jour, de preuve non plus qu’ils le font ou l’on fait. Cet article expose un risque et propose des contremesures. Les observations de cet article restent valables même après le 15 décembre 2020, lorsque les attestations ne seront potentiellement plus obligatoires, à cause de la persistence infinie des données de pistage.

Il n’existe pas de contremesure technique à certaines des méthodes de pistage évoquées dans cet article. Selon le principe de précaution, il est recommandé aux citoyens d’éviter le risque en ne faisant pas usage de la fonctionnalité “Mon téléphone se souvient de moi”, ou en privilégiant les attestations au format papier. Si un citoyen a déjà utilisé la fonctionnalité “Mon téléphone se souvient de moi”, il est recommandé qu’il efface son historique de navigation, y compris les données mémorisées par le site web https://media.interieur.gouv.fr.

Il est recommandé au Ministère de l’Intérieur de modifier le site web de génération des attestations de déplacement COVID-19 afin :

de supprimer la fonctionnalité “Mon téléphone se souvient de moi” ;
d’automatiser l’effacement des données mémorisées précedemment ;
d’héberger l’application sur une autre adresse que https://media.interieur.gouv.fr ;
dans le cas d’un maintien de la fonctionnalité de mémorisation, de supprimer la couche de chiffrement qui ne sert à rien d’autre qu’à induire un faux sentiment de sécurité ;
de renforcer la sécurité de son site web (détail technique plus bas).

Une voie alternative pour le Ministère de l’Intérieur serait de fournir une application mobile en sources ouvertes dédiée à la génération d’attestations. TousAntiCovid ne répond pas à ce besoin, car elle effectue de nombreuses autres missions nécessitant des droits supplémentaires sur le téléphone.

Présentation succincte de l’application d’émission d’attestation

Pour le second confinement de 2020, le Ministère de l’Intérieur a publié une application en ligne pour l’émission d’attestation de déplacement dérogatoire COVID-19 à l’adresse : https://media.interieur.gouv.fr/deplacement-covid-19/

Cette application a subi notamment une mise à jour afin de permettre de mémoriser les informations saisies dans le formulaire, afin d’éviter d’avoir à retaper tous les renseignements à chaque nouvelle visite. Ce mécanisme est au coeur des risques évoqués dans cet article.

L’application fonctionne à l’aide d’un formulaire dans lequel les citoyens saississent leurs informations d’état civil, ainsi que le motif de sortie, et la date et heure. Lors du clic sur le bouton de génération, un fichier PDF est téléchargé. Ce fichier est un formulaire vierge. Il est completé par le navigateur (et le code téléchargé depuis le site du Ministère) grâce aux informations fournies dans le formulaire. Si la case “mon téléphone se souvient de moi” est cochée, alors les informations saisies dans le formulaire sont enregistrées dans le navigateur, grâce à la fonctionnalité localStorage. Elles ne sont pas transmises au Ministère lors de cette opération.

Lors du rechargement de la page, le localStorage est consulté afin d’auto-compléter le formulaire.

Les informations sont stockées sous une forme de document JSON chiffré à l’aide secure-ls. Secure-ls est un module Javascript permettant de chiffrer les données dans le localStorage afin d’en éviter le vol. Outre le fait que les algorithmes cryptographiques déployés par secure-ls sont pour la plupart obsolètes (MD5, SHA-1, 3DES, PBKDF2, RC4…), et que l’implémentation contienne des versions Javascript de ces algorithmes alors qu’il existe WebCrypto, le problème de l’implémentation du Ministère de l’Intérieur est le suivant : le secret permettant de chiffrer et de déchiffrer les informations dans le localStorage est hardcodé dans le code source de la page. Le voici :

s3cr3t$#@135^&*246

Autant dire que cette couche de chiffrement ne sert strictement à rien, et n’est là que pour donner une fausse impression de sécurité… ou pour cacher ce que contient le localStorage aux yeux des curieux.

Il se trouve que le localStorage ne contient rien de bien excitant : une entrée _secure__ls__metadata qui contient un document JSON listant les autres entrées “sécurisées” du localStorage et leurs clés de chiffrement :

{"keys":[{"k":"profile","s":"7bebe7af384395d2ec6d383ac5380c4f"}]}

La clé “profile” contient l’état civil et des informations étrangement redondantes :

{
  "firstname": "Camille",
  "lastname": "Dupont",
  "birthday": "01/01/1970",
  "placeofbirth": "Paris",
  "address": "999 avenue de France",
  "city": "Paris",
  "zipcode": "75001",
  "datesortie": "24/11/2020",
  "heuresortie": "18:00",
  "ox-travail": "travail",
  "ox-achats": "achats",
  "ox-sante": "sante",
  "ox-famille": "famille",
  "ox-handicap": "handicap",
  "ox-sport_animaux": "sport_animaux",
  "ox-convocation": "convocation",
  "ox-missions": "missions",
  "ox-enfants": "enfants"
}

À première vue, l’application semble légitime et conforme à sa mission, faire de son mieux pour que les données ne fuitent pas vers le Ministère de l’Intérieur, et même ce qui semble “caché” sous du chiffrement médiocre est en fait sans surprise ni risque.

Quel est donc le problème décrit par cet article ?

Isolation des sites web

Le web est un milieu dangereux ; s’y cotoient de nombreuses applications web (autrefois appelées sites, mais le terme de site web semble bien réducteur, compte tenu de la quantité de code que chaque site fait exécuter à un navigateur ; ce sont bien des applications à part entière), d’origines diverses et d’innocuité variable. Il est possible de consulter simultanément votre situation fiscale et Facebook, et il serait un scandale si Facebook pouvait décortiquer vos sources de revenus, ou si le site des Impôts pouvait analyser votre graph social.

Pour parrer à ce type de porosité, très tôt dans l’histoire du Web, une politique de sécurité appelée Same Origin Policy (SOP) a été introduite. Cette politique est automatiquement appliquée par tous les navigateurs web. Son principe est l’isolation des applications web en fonction du schéma/protocole (http ou https), du nom de domaine et du numéro de port depuis lequel elles ont été téléchargées. Ainsi http://example.com, http://exemple.net, http://broken-by-design.fr, https://broken-by-design.fr, https://www.broken-by-design.fr et https://www.broken-by-design.fr:8080 sont toutes des applications séparées.

Des applications web isolées par la SOP ne peuvent ni consulter ce qui est affiché par une autre application, ni consulter leurs localStorage respectifs.

Il est ainsi impossible pour Facebook de consulter l’état civil stocké par l’application de génération des attestations COVID-19, par exemple.

Techniques de pistage des utilisateurs

Les techniques de pistage des utilisateurs sont très nombreuses. Parmi ces dernières, les cookies sont un outil redoutable.

Visiter un site A, puis visiter un site B. Les deux sites utilisent les services d’un troisième site, C. Le site B peut alors afficher des publicités en rapport avec la visite du site A. Cela est rendu possible, car C a obtenu des informations sur la navigation de l’utilisateur lors de son passage sur le site A, et a utilisé des cookies pour en prendre note. Lors de la visite sur le site B, les cookies déposés lors de la visite du site A sont automatiquement envoyés à C, et C peut agit en conséquence en proposant de la publicité personnalisée.

Les cookies ne sont qu’un des nombreux moyens à la disposition des régies publicitaires. Ils sont les plus pratiques car les cookies usent d’une politique de sécurité moins forte que la Same Origin Policy discutée précedemment. Mais il est possible de faire virtuellement la même chose avec localStorage, l’outil de stockage également employé par le site de génération des attestations COVID-19 du Ministère de l’Intérieur. Le localStorage est légèrement plus sécurisé (c’est-à-dire moins pratique pour les régies), mais il a le mérite d’avoir une durée de vie potentiellement illimitée, et de passer un peu plus sous le radar juridique.

Pistage des citoyens

Les lecteurs les plus perspicaces auront déjà fait 1 + 1.

Le citoyen soucieux de ne pas être sanctionné en cas d’absence d’attestation de déplacements dérogatoires COVID-19 voudra générer ses attestations quotidiennes le plus facilement et rapidement possible. Il va donc utiliser l’application web du Ministère de l’Intérieur sur son téléphone portable, et mémoriser ses informations. Ce faisant, il aura stocké son état civil durablement dans le localStorage associé à https://media.interieur.gouv.fr/.

Ce même utilisateur pourra ensuite continuer de naviguer sur ses sites habituels. Tout site contenant une sous-page (iframe) téléchargée depuis https://media.interieur.gouv.fr, qu’elle soit visible ou non, permettra potentiellement au Ministère de l’Intérieur d’associer cette visite à un état civil. Il s’agit d’un pistage nominatif, et non plus d’un pistage sur la base de pseudonymes (comme des identifiants numériques arbitraires ou des adresses IP).

Mettons que l’on veuille préremplir un formulaire sur service-public.fr ; il suffit d’inclure une sous-page téléchargée depuis https://media.interieur.gouv.fr et boom : service-public.fr peut collaborer avec media.interieur.gouv.fr pour obtenir les informations d’état civil ! (Par exemple, avec une technique d’affaiblissement de la SOP nommée message passing, qui permet à des onglets de communiquer entre eux par messages.)

Mettons que l’on veuille identifier les bons citoyens qui se rendent régulièrement sur le site gouvernement.fr : boom, même technique.

Mettons qu’un service de renseignement peu scrupuleux des limites du droit français souhaite identifier les utilisateurs d’un site peu recommandable. Plusieurs options sont à sa disposition.

La première possibilité serait l’exploitation d’une vulnérabilité de XSS (Cross Site Scripting) qui serait présente sur ce site. Cette vulnérabilité permet d’ajouter du code illégitime dans une page d’un site web. Les XSS font partie des vulnérabilités les plus communes du web ; cela ne semble donc pas improbable. Grâce à cette faille, il est possible d’ajouter une sous-page de https://media.interieur.gouv.fr sur le site ciblé et boom : citoyen Camille Dupont a visité un site interdit !

Une seconde solution pour ce service de renseignement, si le site peu recommandable est servi en HTTP : pratiquer l’attaque de l’homme du milieu (MITM). Cette attaque permet également d’injecter du code dans une page du site web.

Finalement, il existe une technique pour associer un citoyen à une visite sur un site ciblé qui contourne toutes les contremesures (connues des auteurs de cet article) qui ont été déployées notamment à l’encontre des régies publicitaires, y compris First Party Isolation de Mozilla, et son équivalent dans le Tor Browser. Cette technique utilise la redirection HTTP et une page web qui pourrait être hébergée sur https://media.interieur.gouv.fr. Cette page web offrirait volontairement une vulnérabilité de type Open Redirect : en clair, dès que le Javascript de cette page est chargé, il enregistrerait les paramètres de la query string ainsi que l’état civil de l’utilisateur, puis effectuerait une redirection du navigateur (top level navigation) vers l’adresse du site web peu recommandable indiquée dans cette query string.

Délibérée ou accidentelle, cette fonctionnalité est dangereuse pour les libertés des citoyens français.

Pour les plus sceptiques, un ensemble de sites de démonstration ont été mis en place, qui simulent ce que le Ministère de l’Intérieur peut faire.

Comment s’en protéger ?

Une application mobile en sources ouvertes dédiée à la génération d’attestation est une voie intéressante : elle serait immunisée aux attaques web. La recommandation n’est cependant pas d’utiliser TousAntiCovid. Son modèle est voué à l’échec et présente des risques d’atteinte à la vie privée. De plus, TousAntiCovid accomplit de nombreuses autres missions qui nécessitent des privilèges supplémentaires, dont la connexion au réseau.

Pour se protéger des risques de dévoiement du site de génération de l’attestation COVID-19, il n’existe aucune panacée au meilleur de la connaissance des auteurs de cet article. Il est donc recommandé :

de ne pas enregistrer ses données en laissant décoché “Mon téléphone se souvient de moi” ou
d’éviter le risque en générant ses attestations autrement (sur papier ou avec des applications alternatives ne reposant par sur la sécurité des navigateurs web).

Enfin, si vous avez utilisé la fonction de mémorisation des données personnelles par le passé, il convient d’effacer toutes les données stockées par le site https://media.interieur.gouv.fr. Il est préférable de le faire en utilisant la fonctionnalité de nettoyage de l’historique du navigateur (en cochant bien la case d’effacement des données stockées par le site), plutôt que d’utiliser le bouton prévu à cet effet dans l’application web de génération des attestations (bien que celle-ci agisse correctement à l’heure de l’écriture de cet article).

Recommandations au Ministère de l’Intérieur

Les recommandations principales sont de retirer la fonctionnalité de mémorisation de l’état civil, et d’ajouter un nettoyage automatique de ces données si elles ont été mémorisées par le passé.

L’usage de l’origine https://media.interieur.gouv.fr est un choix médiocre pour plusieurs raisons :

de nombreuses ressources sont servies par cette origine ; la compromission d’une seule de ces ressources entraine la fuite des données personnelles (état civil) des citoyens français. L’isoler sur une origine dédié est une tâche prioritaire.
media.interieur.gouv.fr peut trop facilement co-héberger une application délibérément utilisée pour traquer les utilisateurs, tout en prétendant avoir un objectif légitime ; si un site web tiers héberge une sous-page servie par https://media.interieur.gouv.fr, il ne fera pas immédiatement le rapport avec le risque de pistage des citoyens. En utilisant une autre origine dédiée (https://attestation-covid.media.interieur.gouv.fr, par exemple), vous faîtes preuve de transparence et vous permettez à vos partenaires et vos citoyens de vérifier/douter d’une sous-page que vous voudriez qu’ils ajoutent à votre site web.

En outre, les entêtes de sécurité HTTP employés pour servir le site web de génération des attestations COVID-19 sont strictement insuffisants. Vous employez à la date d’écriture de cet article X-XSS-Protection qui est obsolète, HSTS (de manière adéquate, bravo), x-content-type-options. Les auteurs de cet article recommandent l’ajout des entêtes suivants :

Content-Security-Policy (dont frame-ancestors ’none’, script-src et default-src), afin de prévenir l’inclusion dans une sous-page et de charger du contenu malveillant en cas de XSS qui ne serait pas bloquée par X-XSS-protection qui est obsolète ;
X-Frame-Options: deny afin de prévenir l’inclusion dans des sous-pages ;
Cross-Origin-Opener-Policy: same-origin afin de prévenir la fuite d’information via l’ouverture de pop-ups par un attaquant (Spectre, etc.) ;
Cross-Origin-Resource-Policy: same-site afin de prévenir l’inclusion de ressources de votre site sur un site tiers ; cela évitera que le secret hardcodé dans votre code source soit volable de manière automatisée ;
Cross-Origin-Embedder-Policy: require-corp afin d’imposer l’usage de Cross-Origin-Resource-Policy

Enfin, si vous tenez absolument à maintenir la fonctionnalité de mémorisation, il est recommandable de retirer la couche de chiffrement ls-secure qui est parfaitement inutile et non conforme au Référentiel Général de Sécurité (RGS) - Annexe B1.

L’empoisonnement de cache DNS : toujours d’actualité ?

Wed, 01 Jul 2020 00:00:00 +0000

Le DNS est l’un des protocoles réseau centraux au bon fonctionnement de l’Internet moderne. Ce protocole permet la résolution de noms « symboliques » – les noms de domaine – en des ressources, notamment des adresses IP. Malgré son omniprésence dans notre quotidien, sa sécurisation a été incrémentale et laborieuse. Cet article traite d’une attaque aussi vieille que le DNS, l’empoisonnement de cache, contre laquelle les dernières avancées, comme DNS-over-HTTPS, pourraient permettre de se protéger enfin complètement. Ou le pourront-elles ?

1. Rappels sur le fonctionnement nominal du DNS

Le DNS désigne simultanément un protocole de transmission d’informations sur Internet, et une arborescence administrative et technique organisant les données qui sont transmises par ce protocole. Comprendre finement ces deux aspects est nécessaire pour approcher les attaques par empoisonnement de cache, également appelées attaques par pollution de cache.

Les données stockées dans le DNS sont d’ordres multiples : des adresses IP (types A, AAAA…), des informations utiles pour la livraison des courriers électroniques (types MX, TXT…), des politiques de sécurité (types TXT, TLSA…), des clés cryptographiques (types DNSKEY, TLSA…), ou encore des informations techniques nécessaires au bon fonctionnement et à la sécurisation du DNS lui-même (types NS, RRSIG, DS…). Ces données sont rangées sous la forme d’un arbre, dont chaque nœud, chaque intersection, forme un domaine, comme le montre la figure 1.

Fig. 1 : Illustration de l’arborescence DNS. Chaque intersection constitue un domaine, qui couvre l’ensemble des domaines situés en dessous de lui, et qui sont donc appelés sous-domaines.

Entre chaque domaine de cette arborescence peut se trouver une séparation, une frontière administrative ou technique, que l’on nomme délégation, représentée par un trait plein dans la figure 1. Cette frontière se manifeste techniquement par des données, stockées sous la forme d’enregistrements DNS de type NS, qui indiquent où trouver les serveurs qui seront responsables du domaine délégué.

L’extrait de console suivant fournit un exemple d’une réponse DNS comportant de tels enregistrements formant une délégation. Dans cet exemple, le domaine john.domaine-fictif.fr est délégué, et deux serveurs font autorité sur ce dernier : srv.autre-domaine.fr, et truc.john.domaine-fictif.fr. Ces informations de délégations sont fournies dans la section Authority de la réponse DNS. Nous verrons ultérieurement le rôle des sections dans les empoisonnements de cache. Comme le nom de domaine truc.john.domaine-fictif.fr est situé à l’intérieur du domaine délégué john.domaine-fictif.fr, une adresse doit être fournie pour ce dernier, dans la section Additional de la réponse DNS de délégation.

$ dig -t NS john.domaine-fictif.fr @ns1.domaine-fictif.fr
<snip>
;; QUESTION SECTION:
john.domaine-fictif.fr. IN NS
 
;; AUTHORITY SECTION:
john.domaine-fictif.fr. 172800 IN NS srv.autre-domaine.fr.
john.domaine-fictif.fr. 172800 IN NS truc.john.domaine-fictif.fr.
 
;; ADDITIONAL SECTION:
truc.john.domaine-fictif.fr. 172800 IN A 198.51.100.53

Pour comprendre le rapport entre ces sections et les attaques par empoisonnement de cache, il est également nécessaire d’étudier le fonctionnement d’une interrogation DNS. Une interrogation DNS fait intervenir au minimum trois types d’acteurs : le demandeur, le serveur récursif, et les serveurs faisant autorité sur des domaines.

Le demandeur est une application qui a besoin d’une donnée stockée dans le DNS. Ce peut être, par exemple, un navigateur ou un serveur de courriers électroniques, ou tout simplement la commande ping. Ces applications peuvent contenir du code servant à interroger le DNS, ou simplement utiliser les dispositifs mis à disposition par le système d’exploitation : un résolveur primitif (en anglais, stub resolver).

Le serveur récursif, quant à lui, reçoit la requête DNS du demandeur, et interroge, de manière itérative, les serveurs faisant autorité pour obtenir la réponse adéquate. Pour cela, le serveur récursif suit les délégations, comme celles de l’extrait de console précédent. Son fonctionnement est illustré dans la figure 2, où l’on observe avec les étapes 2, 3, et 4, le processus itératif. Comme l’interrogation itérative est relativement coûteuse, en temps, mémoire, et CPU, les serveurs récursifs sont dotés d’une mémoire persistante, dénommée cache, dans laquelle ils stockent les réponses temporairement, afin d’économiser des ressources en cas de réception d’une nouvelle requête DNS identique (étape 6).

Fig. 2 : Résolution DNS standard. Une requête est envoyée par un résolveur primitif à un serveur récursif ; celui-ci entreprend le processus de récursion, puis répond au résolveur primitif. Un second résolveur primitif interroge ensuite le même serveur DNS récursif.

Finalement, les serveurs faisant autorité contiennent les données recherchées. Ils répondent aux requêtes DNS ayant trait à des domaines sur lesquels ils ont reçu l’autorité par d’autres serveurs ayant eux-mêmes autorité sur des domaines « parents ». Seule la racine du DNS n’a pas de domaine parent, et la localisation de ses serveurs doit être spécifiée dans la configuration des serveurs DNS récursifs.

Souvent, l’interrogation du DNS n’est pas aussi triviale que le cas présenté dans la figure 2. En effet, toujours à des fins d’optimisations, parfois également pour des raisons de sécurité, un autre type d’acteurs du DNS peut être employé : les relais. Les relais sont des serveurs qui n’ont pour objectif que de faire suivre les requêtes et les réponses entre plusieurs autres acteurs du DNS (par exemple, entre des résolveurs primitifs et des serveurs récursifs). Généralement, ces serveurs ont également une mémoire persistante (cache), afin de décharger les serveurs récursifs ou d’économiser le transit sur le réseau des requêtes et réponses. Ces relais sont souvent utilisés par le système d’exploitation pour mettre en commun les réponses pour plusieurs applications, ou par les box Internet et autres routeurs SOHO pour mettre en commun les réponses pour plusieurs équipements d’un même réseau. La figure 3 illustre un exemple d’interrogation DNS employant des relais.

Fig. 3 : Résolution DNS avec un relais. Plusieurs applications sollicitent un relais installé directement sur le poste de travail. Ce dernier relaie les requêtes au serveur DNS récursif, qui procède comme dans la figure 2.

2. L’empoisonnement de cache

L’attaque par empoisonnement de cache vise à insérer dans une mémoire persistante (cache) une valeur frauduleuse, qui sera ensuite servie à de multiples demandeurs.

Les conséquences d’une réponse DNS frauduleuse peuvent être très variables : le détournement de connexions vers une adresse IP sous le contrôle de l’attaquant, le contournement de politiques de sécurité, ou encore la fuite d’informations sensibles, comme détaillée dans l’article « SMTP : la killer-app de DNSSEC », publié dans MISC n°97 ¹.

Il est intéressant de noter qu’un attaquant peut utiliser les mêmes techniques détaillées ultérieurement dans cet article pour empoisonner juste une réponse pour un demandeur spécifique. Cela est cependant rarement fait, puisqu’étant à la fois potentiellement plus difficile à effectuer, et ayant un impact moins grand, puisqu’une seule application en est victime.

L’empoisonnement de cache peut généralement être exécuté par quatre vecteurs, chacun objet d’une des sections suivantes.

2.1. Le cas d’école : l’attaque de l’homme du milieu

Le mode opératoire de l’empoisonnement de cache par l’homme du milieu est simple : l’attaquant se situe en coupure sur le réseau entre le serveur DNS victime et le serveur interrogé. Ce cas peut survenir lorsqu’un routeur est compromis, par exemple. Une variante de cette attaque consiste à manipuler le réseau ou le DNS pour détourner le trafic vers les serveurs de l’attaquant.

Dans ces deux cas, l’homme du milieu peut intercepter toutes les requêtes et réponses DNS. Ainsi, il peut observer les requêtes en transit sur le réseau et fournir des réponses DNS correspondantes contenant les informations frauduleuses de son choix, à la place du serveur interrogé.

Cette attaque est de loin la plus triviale à comprendre, mais sa complexité d’exécution est très variable en fonction du réseau sur lequel elle est mise en œuvre. En effet, sur un réseau local, il est souvent possible de faire des attaques de type ARP poisoning, afin de détourner le trafic local en se faisant passer pour la passerelle du réseau. Sur Internet, en revanche, les attaques ARP ne sont pas possibles. Détourner du trafic reste, bien entendu, possible, notamment grâce à des attaques sur les protocoles de routage dynamiques comme BGP. Ces attaques ont cependant le mauvais goût d’être peu discrètes. Cela n’empêche pas des attaquants de la pratiquer, comme en 2018, où le trafic vers les serveurs DNS d’Amazon a été détourné avec une attaque BGP afin de dérober des cryptomonnaies ². La NSA a également monté le programme QUANTUMDNS pour effectuer ce genre d’empoisonnement de cache ³.

Si l’on omet les autres attaques nécessaires pour se placer en homme du milieu, effectuer un empoisonnement de cache en étant l’homme du milieu est l’affaire d’une dizaine de lignes de Python : intercepter le trafic, inverser le bit de l’en-tête DNS indiquant que ce message DNS est une question ou une réponse, ajouter la réponse frauduleuse au message DNS, et renvoyer le paquet dans « l’autre sens ».

2.2. La compromission des serveurs faisant autorité ou de la chaîne d’approvisionnement

L’empoisonnement de cache consiste à faire persister une donnée frauduleuse qui sera redistribuée à des demandeurs qui seront les victimes réelles ; l’empoisonnement n’est pas une fin en soi, mais bien un moyen. En conséquence, un serveur DNS disposant d’une mémoire persistante peut parfaitement recevoir une donnée frauduleuse d’un serveur désigné comme légitime par l’arborescence DNS. Cela peut se produire si ce serveur légitime a été compromis, ou bien lorsque les attaquants mènent une attaque sur la chaîne d’approvisionnement du DNS.

Les attaques sur la chaîne d’approvisionnement du DNS sont très fréquentes. La chaîne d’approvisionnement du DNS est formée, au minimum, par le bureau d’enregistrement auprès duquel est acheté un domaine, et le registre. Les registres sont les organismes qui possèdent les domaines situés juste en dessous de la racine du DNS et qui accréditent les bureaux d’enregistrement pour vendre des noms de domaine. Par exemple, on peut citer l’AFNIC, registre en charge des noms de domaine français, dont le .fr, et OVH ou Gandi pour les bureaux d’enregistrement.

Parmi les attaques sur la chaîne d’approvisionnement, il peut notamment être cité le cas de la compromission des authentifiants permettant de se connecter auprès du bureau d’enregistrement. Une fois authentifié, l’attaquant peut modifier les informations de délégation d’un domaine, et désigner ses propres serveurs comme faisant autorité sur ce domaine. Ces serveurs peuvent alors servir des données frauduleuses qui resteront potentiellement dans la mémoire persistante des serveurs DNS qui les auront interrogés bien après que le propriétaire légitime de ce domaine ait repris le contrôle de son domaine. Un exemple d’une telle attaque sur la chaîne d’approvisionnement peut être le détournement de PayPal et d’eBay, en 2014, par l’intermédiaire d’une attaque du bureau d’enregistrement Mark Monitor ⁴.

En outre, la nature arborescente du DNS signifie qu’il est possible de servir des données frauduleuses pour un domaine en compromettant n’importe lequel de ses domaines parents. Ainsi, en 2017, Matthew Bryant, un chercheur en sécurité, a détourné une fraction des requêtes pour les domaines se terminant en .io, en identifiant une faiblesse dans la délégation de la racine du DNS vers les serveurs en charge du domaine io ⁵.

2.3. L’exploitation de bugs de logique logicielle

Il est bien entendu que si le serveur ou le logiciel rendant le service DNS sont compromis par un attaquant, ce dernier peut envoyer des réponses de son choix. Cette section de l’article ne s’intéresse cependant pas à ce cas de figure.

Il est ici question du niveau de confiance qu’un serveur DNS récursif a dans les informations reçues dans une réponse DNS. Par exemple, est-ce que le serveur responsable de example.com a le droit de fournir l’adresse IP de www.example.net, dans le cadre d’un « complément de réponse » à une requête qui lui serait envoyée ? Et quid de la réponse illustrée dans l’extrait ci-dessous ? Est-elle acceptable ? Doit-elle être ajoutée à la mémoire persistante (cache) ? Peut-elle remplacer une donnée contraire déjà en mémoire ?

$ dig -t A any1.abc.com
<snip>
;; QUESTION SECTION:
any1.abc.com.         IN    A
;; ANSWER SECTION:
any1.abc.com.        IN    A    1.2.3.4
;; AUTHORITY SECTION:
abc.com.    172800    IN    NS    www.abc.com.
;; ADDITIONAL SECTION:
www.abc.com.        172800    IN    A    6.6.6.6

La réponse n’est pas simple, car il y a de nombreux facteurs à considérer :

sur quel(s) domaines(s) le serveur produisant la réponse fait-il autorité ;
dans quelle section de la réponse DNS l’information a-t-elle été fournie : section réponse (Answer), autorité (Authority) ou complément d’information (Additional) ;
l’information reçue est-elle signée cryptographiquement, avec les extensions de sécurité du DNS : DNSSEC.

Pendant près de dix ans après la conception du DNS, aucune norme n’a documenté l’arbre de décision permettant de choisir si une donnée est suffisamment digne de confiance pour être stockée en mémoire persistante. C’est seulement avec la RFC 2181, en 1997, que des conseils ont enfin été donnés, après un processus itératif ayant compris essais et erreurs. À ce jour, le serveur DNS BIND implémente sept niveaux de confiance différents pour qualifier une donnée et décider si celle-ci peut être mémorisée, utilisée ou retournée dans le cadre d’une réponse. Les autres serveurs DNS ont implémenté leurs propres variantes. Les réponses DNS n’ont donc pas les mêmes effets en fonction du serveur récursif recevant la réponse.

Cela a notamment été documenté dans l’étude « The Hitchhiker’s Guide to DNS Cache Poisoning » ⁶, qui compare les implémentations de trois serveurs DNS récursifs (BIND9, Unbound, et MaraDNS), modélise leurs comportements, et utilise un modèle formel pour découvrir des réponses DNS provoquant des empoisonnements de cache. Par exemple, la réponse montrée dans l’extrait de console ci-dessus peut inciter BIND9 et Unbound à enregistrer un serveur DNS faisant autorité additionnel, à une adresse du choix de l’attaquant. Cette réponse ne permettra cependant pas d’écraser l’adresse IP de www.abc.com si celle-ci a déjà été mémorisée dans le cadre d’une réponse où elle figurait dans la section Answer.

Le processus de décision est désormais bien établi dans les implémentations principales. Il reste cependant parfois des bugs, comme la CVE-2009-4022, qui affectait BIND. En outre, les nouvelles implémentations peuvent se faire piéger comme des débutants, comme ce fut le cas pour systemd-resolved, en 2014 ⁷.

2.4. L’attaque à l’aveugle

L’attaque à l’aveugle est la plus terrifiante des attaques par empoisonnement de cache ; et pour cause, l’attaquant peut la mener depuis virtuellement n’importe où sur le réseau, y compris parfois Internet dans sa globalité ! Pour cette attaque, il n’est pas nécessaire d’intercepter le trafic DNS de la victime, d’où son nom d’attaque à l’aveugle. L’attaquant se « contente » d’envoyer une réponse (probablement plutôt des millions) à une requête dont il ignore tout, et joue les probabilités afin que sa réponse (l’une d’entre-elles, en tout cas) soit acceptée par le serveur DNS récursif victime comme étant la réponse légitime. Ce dernier met alors à jour sa mémoire persistante avec les informations frauduleuses.

Cette notion de probabilité de succès tient au fait que pour qu’une réponse soit acceptée par un serveur DNS récursif, plusieurs critères doivent être réunis :

l’identifiant de transaction DNS (QXID), un champ aléatoire présent dans l’en-tête des réponses DNS doit être identique à celui envoyé dans la requête ;
la réponse doit être reçue (c’est-à-dire qu’elle doit être envoyée à la bonne adresse IP et au bon port) ;
la réponse doit (sembler) provenir du serveur interrogé (c’est-à-dire que la réponse a été envoyée à partir de l’adresse IP et du numéro de port auxquels la requête a été envoyée).

À cela, il faut également ajouter les éventuelles informations spécifiques au protocole de transport employé : UDP, TCP, D-TLS ⁸, TLS ⁹ ou HTTP/2 ¹⁰. Le DNS peut les utiliser tous, même si UDP est actuellement généralement privilégié, pour des raisons de performance. En UDP, aucune information supplémentaire ne doit être devinée par un attaquant tentant de créer une réponse DNS frauduleuse. HTTP/2 repose (dans les faits) sur TLS, qui lui-même transite sur TCP. Chacun de ces protocoles ajoute des informations inconnues de l’attaquant, à commencer par le numéro de séquence TCP (32 bits pseudo-aléatoires). L’attaquant doit devenir ce dernier, car il usurpe l’adresse IP du serveur DNS interrogé et il ne reçoit donc pas le segment TCP SYN/ACK contenant le numéro de séquence du serveur.

D-TLS, quant à lui, introduit, entre autres, des éléments cryptographiques très difficiles à deviner par un attaquant.

En somme, si l’on considère le protocole de transport par défaut, UDP, le nombre de bits inconnus d’un attaquant essayant de fabriquer une réponse frauduleuse est :

QXID au maximum 16 bits ;
l’adresse IP du résolveur DNS : certaines infrastructures DNS utilisent plusieurs adresses IP émettrices de requêtes vers les serveurs faisant autorité, ce qui ajoute une incertitude de l’ordre de 0 à 3 ou 4 bits dans les cas extrêmes ;
l’adresse IP du serveur DNS interrogé : la plupart des domaines disposent d’au moins deux serveurs DNS faisant autorité, soit au moins 1 bit d’incertitude ;
le port sur lequel la réponse doit être envoyée : si ce dernier est choisi aléatoirement, selon les recommandations ¹¹ ¹², au maximum 16 bits.

Au total, l’attaquant qui tente de fabriquer une réponse DNS frauduleuse doit donc deviner, dans le cas le plus défavorable pour lui, $16 + 16 + 4 + 1 = 37$ bits. Une autre manière de considérer ce résultat est de dire qu’une réponse DNS frauduleuse d’un attaquant à l’aveugle a une probabilité d’au mieux $2^-37$ (environ une chance sur 137 milliards) d’être acceptée par un serveur DNS récursif.

L’attaquant n’est cependant pas contraint d’envoyer une unique réponse frauduleuse. En effet, le serveur DNS récursif est en attente d’une réponse valide. Il rejettera généralement silencieusement les tentatives infructueuses de l’attaquant, et attendra patiemment une réponse correcte. Cette attente dure le temps que le serveur réellement interrogé réponde. Pendant ce laps de temps, l’attaquant peut donc envoyer autant de tentatives de réponses frauduleuses que la victime est capable de recevoir et de traiter. Une réponse DNS de taille moyenne pouvant faire dans les 100 octets, l’attaquant peut envoyer 125000 réponses frauduleuses par seconde vers une victime capable de traiter 100 Mb/s. En admettant un délai raisonnable de réponse du serveur légitime autour des 100 millisecondes, l’attaquant a donc le temps d’envoyer 12500 réponses frauduleuses. En conséquence, une tentative d’empoisonnement de cache d’une victime capable de gérer 100 Mb/s de trafic, avec un serveur légitime mettant 100 millisecondes à répondre, a une probabilité de succès d’autour de $log(12500)/log(2) * 2^-37$, soit environ $2^-23$ ou approximativement une chance sur huit millions. Il existe, en outre, des techniques obscures pouvant permettre d’améliorer encore cette probabilité ¹³ ¹⁴ (note : le calcul ci-dessus est faux, mais constitue une approximation compréhensible acceptable).

Une chance sur 137 milliards peut paraître être un risque négligeable. C’est en particulier le cas si l’on considère qu’en cas d’échec, l’attaquant doit attendre que l’information envoyée par le serveur DNS légitime expire de la mémoire persistante du serveur récursif ciblé. Pendant cette période d’expiration, toutes les requêtes sont, en effet, répondues avec l’information mémorisée ; l’attaquant ne peut donc plus tenter sa chance, car le serveur DNS récursif n’émet plus de requête.

Le risque n’a cependant pas toujours été aussi faible. En 2008, le chercheur en sécurité Dan Kaminsky a publié une attaque permettant un empoisonnement de cache à l’aveugle pouvant s’effectuer en quelques minutes, voire quelques secondes suivant les « optimisations » appliquées. À l’époque, les serveurs DNS récursifs n’utilisaient pas systématiquement un port source aléatoire. La probabilité qu’une réponse frauduleuse puisse être acceptée pouvait donc être aussi basse que $2^-16$, soit une chance sur 65536. Le seul élément inconnu était l’identifiant de transaction (QXID) ! En outre, Kaminsky a abusé de la mécanique permettant aux serveurs DNS de juger de la confiance qu’ils peuvent porter dans les informations contenues dans une réponse DNS. Ainsi, son attaque consistait à faire des tentatives d’empoisonnement de cache, non pas sur des domaines existants, mais sur des domaines inexistants aux noms aléatoires. Son but n’était pas de compromettre ces domaines inexistants, mais de fournir des informations complémentaires écrasant d’autres données déjà présentes dans la mémoire persistante du serveur DNS récursif victime. De surcroît, le génie de cette attaque était d’utiliser des domaines inexistants, qui sont quasiment innombrables. Grâce à ces noms aléatoires, en cas de tentative infructueuse, au lieu d’attendre que le serveur DNS récursif vide sa mémoire persistante ou invalide la réponse légitime après un certain délai, une nouvelle tentative pouvait être immédiatement effectuée par l’attaquant, avec un nouveau nom aléatoire.

3. Défenses

Le DNS a été conçu à la fin des années 80. Ce vénérable protocole a connu de nombreux changements, et moult augmentations. Pendant longtemps, les seules améliorations de sa sécurité ont été des rustines visant à rendre de plus en plus difficiles les attaques à l’aveugle et compenser l’absence de lignes directrices pour les niveaux de confiance à porter dans les données reçues.

C’est ainsi que la RFC 5452, publiée en 2009, documente, après la débâcle causée par l’attaque de Dan Kaminksy, que le port source devrait être aléatoire pour plus de sécurité.

La technique connue sous le nom de 0x20 a également vu le jour. 0x20 est la distance, dans la table ASCII, entre une lettre majuscule et la lettre minuscule correspondant : A (65) et a (97) donnent $97 - 65 = 32 = 0x20$ en hexadécimal. Son principe est de changer aléatoirement la casse des lettres d’un nom de domaine dans une requête DNS, et d’escompter voir les mêmes variations de casse dans la réponse DNS. Si la réponse ne contient pas les bonnes majuscules, alors la réponse est rejetée, même si tous les autres paramètres sont bons. Un attaquant à l’aveugle ne peut connaître les lettres qui ont été mises en majuscule ; il doit donc les deviner, en plus de tout le reste.

Ces astuces ne protègent cependant pas contre les autres attaques par empoisonnement de cache évoquées dans la section précédente de cet article. Ainsi, au milieu des années 90, l’IETF, l’organisme qui conçoit les standards de fait de l’Internet, a donc commencé à concevoir des extensions DNS pour la sécurité : DNSSEC. Il a fallu à la communauté plus de dix ans pour arriver à une mouture convenable. Finalement, en 2010, son déploiement global fut rendu possible.

Le principe de DNSSEC a déjà été détaillé de nombreuses fois dans MISC, ainsi que dans un document publié par l’Afnic ¹⁵. Néanmoins, il convient ici d’en présenter les grandes lignes, étant donné qu’il s’agit de l’unique contre-mesure efficace contre l’empoisonnement de cache, à ce jour. DNSSEC permet de protéger l’intégrité des informations contenues dans le DNS, à l’aide de signatures cryptographiques. Ces signatures sont créées avec des clés asymétriques : une clé privée est utilisée pour créer les signatures, et la clé publique associée à la clé privée permet de vérifier ces signatures.

La personne ou le serveur en charge d’un domaine signe donc, avec une clé privée, les informations contenues dans ce domaine (plus spécifiquement, dans sa zone… mais la différence subtile de terminologie peut être ignorée ici). La « magie » mathématique de la cryptographie asymétrique permet à tout acteur DNS de valider l’intégrité cryptographique des données ayant trait à ce domaine. Pour cela, la clé publique est employée. Les signatures et les clés publiques nécessaires à leur vérification sont publiées dans l’arborescence DNS elle-même. À chaque délégation d’un sous-domaine, le domaine parent signe une information permettant de vérifier l’authenticité de la clé qui signe le sous-domaine. Il se crée ainsi une chaîne de clés-signatures, permettant de vérifier toutes les informations du DNS… pour peu que les domaines soient signés.

Les validateurs des signatures DNS sont généralement les acteurs de l’infrastructure DNS qui maintiennent une mémoire persistante : les serveurs DNS récursifs et les relais. Une fois les données vérifiées cryptographiquement, ces serveurs peuvent les stocker, en toute sécurité.

Lorsqu’un résolveur primitif interroge un serveur DNS récursif validant DNSSEC, ce dernier répondra en fournissant les informations depuis sa mémoire, et en mettant un bit à 1 (AD : Authentic Data) pour signaler qu’en ce qui le concerne, ces informations ont été déterminées comme authentiques.

Paradoxalement, et de façon parfaitement incompréhensible, les concepteurs de DNSSEC n’ont pas jugé utile de protéger en intégrité le bit AD… En conséquence, si un relais maintenant une mémoire persistante ne fait pas lui-même la validation DNSSEC, son cache peut être empoisonné par un attaquant, quand bien même le domaine est signé avec DNSSEC ! Il peut être jugé que sur un réseau local maîtrisé, comme dans un réseau d’entreprise, la probabilité d’une telle attaque soit faible. Cependant, il est difficile de tenir le même argument lorsque le serveur DNS récursif validant DNSSEC est celui de résolveurs publics, comme ceux de Google, Cloudflare ou OpenDNS ; en effet, les réponses de ces serveurs transitent sur l’Internet sans protection !

Plusieurs propositions ont été avancées pour combler cette absence.

Le protocole DNSCrypt ¹⁶ figure parmi les premières propositions viables. Hélas, malgré ses nombreux mérites et son support par OpenDNS dès 2011, son déploiement reste faible à ce jour.

De son côté, la communauté DNS a, des années après la publication de DNSCrypt, mis au monde DNS-over-TLS (DoT) en 2018. Ses atouts sur son prédécesseur sont au mieux douteux, et son adoption est également anecdotique à l’aube de la nouvelle décennie.

Finalement, toujours en 2018, ce qui aurait pu sembler être un trait d’humour il y a dix ans est devenu réalité : DNS-over-HTTPS a été spécifié. Encombré par HTTP/2, sans en tirer le moindre avantage, ce protocole plaque les messages DNS dans la pile protocolaire « DNS sur HTTP/1.1 sur HTTP/2 sur TLS sur TCP ». Ironiquement, contre toute attente et contrairement à la raison la plus primaire, c’est ce protocole, digne de l’œuvre du docteur Frankenstein, qui semble être destiné à être largement adopté. Ce dernier est, en effet, largement plébiscité par les navigateurs, déjà habitués à traiter avec cette pile protocolaire absurde, et dont les intérêts sont tout autre que la protection de l’intégrité du DNS et de la vie privée. Néanmoins, force est de constater que grâce aux navigateurs, le bit AD aura peut-être enfin une chance d’être protégé lors de son transit sur le réseau, grâce à TLS, et les attaques par empoisonnement de cache deviendront réellement impossibles grâce à DNSSEC.

4. Conclusion

Dans cet article, nous avons étudié les différents types d’attaques par empoisonnement de cache, au sens large. Nous avons ainsi pu observer, au travers d’exemples, que ces attaques sont toujours d’actualité, à l’aube de la nouvelle décennie, et plus de 30 ans après la conception du protocole DNS. Enfin, nous avons fait un point sur les techniques de défense disponibles, et celles en cours de déploiement.

Disposer d’une boîte à outils complète pour contrer ces attaques est un luxe dont nous pouvons/allons pouvoir enfin jouir. Hélas, le taux d’adoption de DNSSEC est encore très faible, notamment pour les noms de domaine en .fr. En 2017, l’ANSSI relevait que 10% des noms en .fr étaient signés, et que l’adoption volontaire était anecdotique (1% des domaines qui existaient déjà l’année précédente) ¹⁷.

En conséquence, étudier les empoisonnements de cache est encore à ce jour pertinent, et cela devrait, hélas, continuer de l’être pour encore de nombreuses années.

5. Remerciements

Je tiens à remercier Benjamin Cohen et Piotr Chmielnicki pour leurs suggestions d’amélioration de cet article. Les opinions exprimées dans cet article ne sauraient les engager.

6. Références

Publié par les Editions Diamond sous licence CC-BY-NC-ND.

SMTP la killer-app de DNSSEC : https://connect.ed-diamond.com/MISC/MISC-097/SMTP-la-killer-app-de-DNSSEC ↩︎
Article sur l’attaque BGP pour détourner les serveurs DNS d’Amazon : https://dyn.com/blog/bgp-hijack-of-amazon-dns-to-steal-crypto-currency/ ↩︎
Quantum DNS : https://arstechnica.com/information-technology/2015/01/nsa-secretly-hijacked-existing-malware-to-spy-on-n-korea-others/ ↩︎
Article sur l’attaque via Mark Monitor : https://mashable.com/2014/02/01/syrian-electronic-army-ebay/ ↩︎
Blog de Matthew Bryant : https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/ ↩︎
The Hitchhiker’s Guide to DNS Cache Poisoning : https://www.cs.cornell.edu/~shmat/shmat_securecomm10.pdf ↩︎
Systemd-resolved DNS cache poisoning https://seclists.org/oss-sec/2014/q4/592 ↩︎
DNS over Datagram Transport Layer Security (DTLS) : https://www.rfc-editor.org/rfc/rfc8094.txt ↩︎
Specification for DNS over Transport Layer Security (TLS) : https://www.rfc-editor.org/rfc/rfc7858.txt ↩︎
DNS Queries over HTTPS (DoH) : https://www.rfc-editor.org/rfc/rfc8484.txt ↩︎
DNS forgery : http://cr.yp.to/djbdns/forgery.html ↩︎
Measures for Making DNS More Resilient against Forged Answers : https://www.rfc-editor.org/rfc/rfc5452.txt ↩︎
Blocking DNS messages is Dangerous : https://www.ssi.gouv.fr/uploads/IMG/pdf/DNS-OARC-2013-Blocking_DNS_Messages_Is_Dangerous.pdf ↩︎
Fragments Considered Poisonous : https://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf ↩︎
Dossier DNSSEC de l’Afnic : https://www.afnic.fr/data/divers/public/afnic-dossier-dnssec-2010-09.pdf ↩︎
Site du projet DNSCrypt : https://dnscrypt.info/ ↩︎
Rapport de l’observatoire de la résilience de l’Internet français : https://ssi.gouv.fr/observatoire ↩︎

Sondes de détection : performances, évaluations et biais

Fri, 01 Nov 2019 00:00:00 +0000

En avril 2019, l’ANSSI a qualifié les premières sondes pour assurer la supervision de sécurité de réseaux. Les OIV, les OSE et, d’une manière générale, les organismes opérant des fonctions sensibles disposent ainsi de produits français de confiance : Cybels Sensor de Thales et Trackwatch Full Edition de Gatewatcher. La méthodologie d’évaluation des sondes n’est, hélas, pas publique. Les ingénieurs sécurité et réseau devant intégrer ces sondes ne disposent donc pas de guides pour effectuer la recette de leur efficacité en production.

Cet article propose un retour d’expérience sur l’évaluation des sondes, notamment sous l’angle de la performance. Cet aspect est, en effet, particulièrement significatif puisque le taux de détection d’une sonde diminue si elle est submergée, quand bien même elle serait équipée des meilleurs signatures et moteurs d’analyse.

De la notion de budget

Les différents moteurs d’analyse constituant une sonde consomment des ressources machine. Celles-ci sont en quantité finie et dépendante du matériel sur lequel sont installés les mécanismes de détection et d’analyse. Ces ressources comprennent notamment la capacité de calcul (CPU, FPGA, ASIC) et la mémoire (RAM, mémoire de travail des périphériques…).

Il est généralement possible d’effectuer certains compromis calcul/mémoire afin d’optimiser le traitement. Néanmoins, ces ressources confinent, in fine, au temps nécessaire pour traiter un paquet entrant. La variable non ajustable est, en effet, le débit entrant dans une sonde. Ce débit est exprimé en deux unités : le nombre de paquets par seconde, et le nombre d’octets par seconde.

Le nombre de paquets par seconde est significatif, car il définit le budget temporel disponible pour le traitement des paquets. Un million de paquets par seconde signifient que la sonde dispose d’un millionième de seconde pour le traitement de chaque paquet en moyenne. En outre, le nombre de paquets par seconde a une influence sur le nombre d’interruptions (matérielles ou logicielles) qu’un CPU doit traiter. De la même manière qu’un ingénieur est moins productif s’il est constamment interrompu, un CPU perd du temps à chaque interruption. En conséquence, à l’instar de nombreux équipements, il est aisé de noyer une sonde sous de nombreux paquets représentant un trafic extrêmement modéré en octets par seconde.

Le nombre d’octets par seconde reste cependant significatif. Ce dernier a, en effet, un impact sur les temps de transfert des paquets entre les différents composants de la sonde. Cet impact se matérialise notamment pendant les recopies des paquets, entre composants matériels ou logiciels.

Dès lors qu’une sonde épuise son budget pour le traitement d’un paquet, celui des paquets suivants peut en pâtir. S’il ne s’agit que d’un pic de trafic, il est généralement possible d’absorber celui-ci en lissant son coût sur les millisecondes/secondes suivantes. En effet, certains paquets sont traités plus rapidement que d’autres, comme ceux qui sont immédiatement écartés, car faisant partie d’un flux chiffré dont la sonde n’a pas la clé de déchiffrement. Si le pic d’activité se prolonge, la sonde n’a alors d’autre choix que de défausser du trafic. L’endroit et la manière dont le trafic est défaussé sont déterminés en fonction de la localisation du goulot d’étranglement.

Les goulots d’étranglement

Les paquets reçus peuvent être défaussés par de nombreux composants matériels ou logiciels, dès lors qu’une surconsommation budgétaire survient. Cela peut se produire dès la carte réseau recevant les paquets et ne pouvant pas les diffuser au noyau, ou bien plus tard, quelque part dans le noyau ou dans le logiciel de détection en lui-même.

Pertes par la carte réseau

Les cartes réseau disposent d’une mémoire interne relativement réduite ; il s’agit d’une file d’attente. Chaque paquet entrant dans la carte est inséré dans cette file. Celle-ci est ensuite consommée par un procédé qui transfère les paquets dans la mémoire centrale du serveur. Cela s’effectue par des écritures DMA ou des variantes, telles qu’IOAT/DMA).

Une carte réseau peut saturer sa file d’attente, si elle n’arrive pas à effectuer les écritures DMA aussi rapidement que les paquets arrivent depuis le réseau. Outre de possibles lenteurs matérielles sur les bus de communication en eux-mêmes, la cause principale de lenteur est le filtrage des accès mémoire par l’IOMMU ¹. Il s’agit d’un gestionnaire des écritures DMA, capable de limiter les plages mémoires sur lesquelles les périphériques d’un serveur sont en mesure d’écrire, à l’instar d’un pare-feu limitant les accès à un réseau. Sa fonction est cruciale pour la sécurité des serveurs, mais totalement contre-productive si elle résulte en l’incapacité de la sonde à remplir son rôle.

Pertes dans le noyau

Lors de son démarrage, le logiciel de détection fait appel au noyau pour configurer une méthode d’acquisition des paquets. Plusieurs existent, parmi lesquels les plus populaires sont certainement AF_Packet (natif dans Linux), PF_Ring, DPDK, ou encore Netmap.

Généralement, le logiciel de détection configure le noyau afin qu’une plage mémoire soit réservée pour la réception des paquets écrits par DMA.

Plus cette plage mémoire est grande, plus la quantité de paquets qui pourront être stockés en attendant leur traitement est importante. Si toutefois cette plage se remplit plus vite qu’elle n’est consommée par le logiciel de détection, alors des paquets sont défaussés.

La lenteur de la consommation des paquets entrants n’est pas systématiquement à imputer aux lenteurs du logiciel de détection. En effet, le noyau effectue des transformations ou ajoute des métadonnées, qui peuvent être plus ou moins coûteuses. Des pertes peuvent donc se produire avant même que le logiciel de détection ne soit prévenu de la réception de paquets ! Ce cas peut être notamment observé si l’on utilise des programmes XDP très gourmands, ou des algorithmes peu performants de répartition des paquets (load-balancing) entre les différents processeurs.

Une autre cause de pertes de paquets impliquant le noyau est l’extraction de fichiers. Les logiciels de détection peuvent, en effet, stocker les paquets reçus (fichiers PCAP) ou les fichiers suspects transitant sur le réseau (HTTP, SMB, SMTP…). Si les périphériques de stockage ne sont pas suffisamment rapides, les appels système d’opération sur les fichiers (write(2), sync(2)…) pourraient être plus lents à rendre la main au logiciel de détection, et donc dépasser le budget. En conséquence, une perte de paquets est possible dès lors qu’une grande quantité de fichiers doivent être extraits pour mise en quarantaine et analyses ultérieures.

Pertes dues au logiciel de détection

L’organisation des composants constituant le logiciel de détection et la complexité des règles d’analyse peuvent avoir un impact significatif sur les performances, et entraîner la perte de paquets.

Les moteurs d’analyse sont découpés, en interne, en plusieurs sous-tâches :

acquérir de nouveaux paquets à traiter ;
replacer les paquets dans leur contexte (e.g. « fait-il partie d’une session TCP ? », « est-ce un fragment d’un paquet déjà vu ? ») ;
effectuer des analyses de sécurité des paquets ou des flux, afin d’inférer des événements de sécurité ou d’extraire des fichiers suspects ;
produire des journaux enregistrant les événements générés.

Ces sous-tâches peuvent être gérées par un ou plusieurs processus. Utiliser plusieurs processus peut être avantageux pour paralléliser les traitements, et ne pas se retrouver avec une surcharge de travail qui pourrait saturer les capacités de traitement d’un unique processus. Hélas, utiliser plusieurs processus n’est pas non plus une panacée, car ces sous-tâches peuvent nécessiter des états partagés. Il est alors nécessaire d’organiser l’accès à ces états, par l’intermédiaire de serveurs mandataires (comme le fait Zeek/Bro) ou de verrous (futex/mutex, comme le fait Suricata).

Une analyse de performance assez poussée du logiciel de détection Suricata a été conduite ² ; elle montre que les verrous constituent un des freins principaux, pouvant causer la perte de paquets. Dans cette analyse, il est notamment stipulé que Suricata effectue beaucoup d’accès concurrents aux états des sessions TCP.

Ainsi, un trafic réseau comportant une grande quantité de sessions TCP simultanées ou de nombreuses nouvelles connexions par seconde peut avoir pour conséquence le ralentissement de Suricata. En effet, tous les processus ayant pour objectif de remplacer un paquet dans son contexte seront alors figés en l’attente de la libération des verrous pour accéder aux états partagés.

En outre, et sans même parler de verrous, une grande quantité de sessions TCP peut saturer les tables de hachage dans lesquelles sont stockés les états. Or, la complexité algorithmique d’accès aux éléments des tables de hachage passe d’O(1) (temps constant) à O(n) (temps linéaire, fonction de la quantité de collisions dans la table de hachage) lorsque celles-ci saturent. Il en résulte alors une surconsommation CPU, et donc une surconsommation du budget temporel pour le traitement d’un paquet.

L’architecture logicielle des moteurs d’analyse peut également influencer les performances en cas de mauvaise répartition des paquets reçus entre les différents processus en charge de leur traitement. La perte de paquets survient lorsqu’un CPU est saturé/noyé sous les traitements qu’un processus d’analyse doit entreprendre. Ce cas de figure se manifeste très facilement lorsque la répartition des paquets reçus n’est pas aléatoire, mais tend à concentrer sur le même processus d’analyse tous les paquets relatifs à un même flux (ex. : sessions TCP). Cette répartition par flux est la plus commune et privilégiée, car elle permet de limiter les accès aux ressources partagées et d’augmenter la localité des accès mémoire ³. Le problème est que cette méthodologie ne répartit pas correctement le trafic incluant des tunnels (IPsec, GRE, L2TP, TLS…). En effet, à moins que le programme en charge de la répartition ne fasse de l’inspection profonde (DPI) du trafic (qui n’est même pas toujours possible, par exemple en cas de paquets fragmentés), l’intégralité des paquets d’un tunnel sera analysée par un même processus d’analyse ! Si ce tunnel est très actif, le processus d’analyse sera facilement débordé, et des paquets commenceront à être perdus.

Finalement, les moteurs d’analyse (ex. : dissecteurs, analyseurs de contenu, greffons d’analyse) peuvent être des sources de problèmes de performance, résultant en la perte de paquets. Le pare-feu applicatif de Cloudflare a causé une indisponibilité de l’ensemble de leurs services en juillet 2019 ⁴, à cause d’une expression rationnelle gourmande en CPU. De même, une règle de détection mal conçue pourra freiner significativement l’analyse des paquets, et surconsommer le budget.

De l’expérience de l’auteur de cet article, le problème est encore pire avec des greffons écrits en Lua. Ce langage utilise, en effet, exclusivement des co-routines pour simuler le parallélisme. En conséquence, si une instruction Lua met en attente l’interpréteur Lua, sans rendre la main pour que ce dernier exécute une autre co-routine en attendant, l’ensemble des processus d’analyse de paquets ayant recours à un greffon Lua se retrouvent figés ⁵.

Biais introduits par les méthodologies d’évaluation

Les conditions évoquées dans la précédente section de cet article peuvent se manifester lors de la capture de trafic sur des réseaux de production. Néanmoins, étant donné que les sondes sont des composants généralement connectés à des réseaux sensibles, nombre d’opérateurs préfèrent évaluer ces équipements en émulant de tels réseaux, avant d’en sélectionner un et de le raccorder à leur production. De même, les constructeurs de sondes doivent évaluer leur produit afin de s’assurer de leur performance.

L’émulation d’un réseau n’est cependant pas chose aisée, et de nombreux biais peuvent être introduits, faussant positivement ou négativement la perception des performances réelles des sondes ! Cette section détaille quelques erreurs communes que l’auteur de cet article a pu observer ou commettre dans le cadre de son activité professionnelle.

Les outils pour l’émulation de réseaux

Outre les plateformes commerciales, dont l’efficacité et la pertinence des tests pourraient certainement faire l’objet d’études formelles, plusieurs outils libres existent. Parmi ces derniers, il est notamment judicieux de citer :

tcpdump, qui permet la capture de trafic, le filtrage et le stockage dans des fichiers PCAP ⁶ ;
tcpreplay, qui permet de rejouer des PCAP à plus ou moins grande vitesse, et même d’éditer les PCAP ⁷ ;
TRex, de Cisco, qui constitue une plateforme de rejeu de trafic complète [^TRex] ;
scapy, une bibliothèque Python dédiée à la manipulation de paquets réseau. Elle permet de capturer du trafic, de l’analyser, de le filtrer et de l’éditer, avant de l’enregistrer sous la forme de fichiers PCAP, ou de renvoyer les paquets sur le réseau ⁸ ;
tc qdisc, un ensemble d’outils sous Linux permettant notamment l’émulation de certaines conditions sur un réseau, comme la limitation de débit avec le module tbf, ou la création de latence ou d’instabilités (pertes de paquets, rejeux…) avec le module netem ⁹.

Tcpdump

tcpdump permet de capturer et d’enregistrer du trafic sur des réseaux modérément actifs. Lorsque les réseaux sont trop rapides, ce dernier ne parvient pas toujours à collecter tous les paquets reçus. Les flux réseau ainsi enregistrés s’en retrouvent alors corrompus. Quelle que soit la technologie employée pour le rejeu du trafic, il est crucial que les captures réseau employées soient représentatives de la situation que l’on cherche à émuler. En outre, il est normal de souhaiter que le trafic envoyé à la sonde contienne des pertes, des rejeux et des réordonnancements de paquets. Il convient cependant que ceux-ci soient désirés et émulés à dessein, plutôt que le résultat du hasard et d’une méthodologie de capture inadéquate.

Il convient également de noter que la capture de trafic d’un réseau réel peut générer des fichiers PCAP non représentatifs, malgré une source de données bien légitime. En effet, il est absolument capital de nettoyer ces captures, car celles-ci contiennent des demi-flux ¹⁰. Ces demi-flux sont des flux qui ont commencé avant le début de la capture ou qui se termineront après la fin de la capture.

Les demi-flux commencés avant le début de la capture sont problématiques si la sonde est configurée pour ignorer de tels flux. En rejouant ces demi-flux, l’évaluateur néophyte pourrait alors avoir l’impression d’envoyer une quantité importante de trafic à la sonde et que cette dernière se comporte parfaitement, sans perdre le moindre paquet. En réalité, la sonde n’effectuera aucune analyse des paquets reçus et les défaussera, sans lever la moindre alerte, même en présence d’un trafic malveillant.

Les demi-flux ne se terminant pas pendant la capture sont également problématiques si la capture est relativement courte, et rejouée en boucle, par exemple avec tcpreplay. En effet, ces flux ne se terminant jamais, ils vont créer à chaque itération de nouveaux états à maintenir dans la sonde, pouvant ainsi causer une explosion en coût mémoire, et une saturation de différentes tables de hachage internes. Or, si les logiciels de détection sont optimisés pour ne pas s’écrouler face à des DDoS de type SYN Flood, une explosion du nombre de flux tombe dans le spectre des attaques logiques. Les sondes n’ont alors d’autres choix, pour ne pas s’écrouler, que de défausser arbitrairement des flux, parmi lesquels des flux potentiellement malveillants. Pour ce faire, des délais de grâce (timeout) agressifs sont employés.

Tcpreplay

tcpreplay permet de rejouer des PCAP contenant des flux de toute nature et peut être un outil efficace pour évaluer une sonde. Des biais peuvent cependant être introduits dès lors que le PCAP est rejoué en boucle à l’aide de l’option --loop.

Le premier biais constaté par l’auteur de cet article survient si la périodicité des rejeux en boucle est inférieure à la valeur du délai de grâce (timeout) CLOSE_WAIT configuré dans la sonde. Dans l’absolu, CLOSE_WAIT est un état de la machine à états du protocole TCP, qui est indépendant des paquets reçus, et qui évolue seulement après un certain délai. Son objectif est d’empêcher qu’un serveur croie à l’établissement d’une nouvelle connexion TCP à cause de paquets réseau dupliqués trouvant leurs chemins après la fermeture de la session originale. Les sondes devant émuler les piles TCP des serveurs qu’elles protègent, elles doivent avoir un délai de grâce pour l’état CLOSE_WAIT représentatif de ces serveurs. Or, si tcpreplay rejoue en boucle « trop rapidement » (relativement au délai de grâce) le même PCAP, alors le trafic sera partiellement ignoré par la sonde, comme il l’aurait été par le serveur auquel s’adressait le trafic original, en vertu des spécifications du protocole TCP ! Il en résulte une sonde donnant l’impression de traiter énormément de paquets, alors qu’en pratique, elle les ignore.

Pour éviter le biais précédent, il est possible d’utiliser l’option --unique-ip de tcpreplay qui fait varier les adresses IP à chaque nouvelle itération d’un PCAP. Hélas, cette option conduit au second biais !

Ce second biais est une amusante et improbable coïncidence. Il existe, en effet, une interaction entre l’algorithme utilisé par --unique-ip et certaines méthodes de hachage des paquets en vue d’effectuer la répartition des paquets entre les processus d’analyse !

Les méthodes de hachage des paquets pour répartir les flux nécessitent une propriété assez inhabituelle. En effet, il est nécessaire de hacher vers le même processus d’analyse, tant les requêtes que les réponses d’un même flux. Il faut donc utiliser un algorithme dit symétrique, qui hachera les adresses IP de manière identique même si les adresses IP source et destination sont inversées. Or, certains mécanismes de répartition, comme celui de la méthode de capture des paquets PF_Ring, utilisent une simple addition modulaire des octets des adresses IP. Ainsi, un paquet allant de 192.168.0.1 à 192.168.0.2 donnera un haché égal à $192+168+1+192+168+2 = 723 modulo N$.

De son côté, l’implémentation de --unique-ip dans tcpreplay se contente de soustraire le nombre d’itérations du PCAP à une adresse IP, et d’ajouter le nombre d’itérations du PCAP à l’autre adresse IP. Or il s‘agit d’une opération mathématique à somme nulle qui conduira donc l’algorithme de répartition des paquets de la sonde à toujours envoyer les paquets vers les mêmes processus d’analyse. Si le PCAP est suffisamment court, alors la sonde se trouvera submergée artificiellement au niveau de certains processus, tandis que tous les autres ne recevront pratiquement aucun flux !

TRex

TRex est une plateforme développée par Cisco permettant le rejeu d’une gamme de PCAP. Chaque PCAP ne doit contenir qu’un seul flux. La configuration de cette plateforme permet ensuite de spécifier la fréquence relative de chaque PCAP par rapport aux autres. Il est alors possible d’envoyer plus ou moins de flux, en sachant que la quantité et la nature des flux envoyés sont maîtrisées.

TRex évite les biais introduits par tcpreplay, en faisant varier les adresses IP de manière aléatoire à chaque nouvel envoi d’un flux. En outre, pour l’expédition des flux, il envoie les paquets d’une adresse A vers une adresse B sur une interface réseau, et les paquets retour, de B vers A sur une autre interface réseau. Cela résulte en une méthode d’acquisition des flux par la sonde qui est plus réaliste, car plus proche de la méthode d’acquisition des flux sur une fibre optique.

La seule ombre au tableau de TRex est sa complexité ; il est, en effet, aisé d’envoyer à une sonde du trafic dépassant l’une de ses spécifications, soit en nombre de paquets par seconde, de nouveaux flux par seconde, de nombre de flux totaux, de fichiers à extraire, ou autre.

Scapy

Scapy est un outil probablement indispensable pour les évaluateurs de sonde. Il leur permet, en effet, de retravailler un fichier PCAP, notamment pour y nettoyer les demi-flux, altérer les flux pour dupliquer des paquets ou en supprimer, corrompre sciemment des sommes de contrôle. Son seul véritable défaut est sa relative lenteur, due principalement à son modèle d’abstraction des paquets, et au langage Python. Il est donc peu pratique d’opérer sur des PCAP de plusieurs gigaoctets.

Tc qdisc

tc qdisc (traffic control – queue discipline) est un cadriciel reposant sur le noyau Linux et des outils de l’espace utilisateur (userland) pour altérer l’écoulement des paquets sur des interfaces réseau spécifiques. Cet outil est notamment utile lorsqu’un évaluateur cherche à créer des PCAP pour TRex. En effet, il est possible de créer un environnement contrôlé, par exemple avec une paire d’interfaces virtuelles (veth). L’une des interfaces fait alors tourner le serveur et l’autre accueille le client. tc permet d’altérer cet environnement de tests pour y introduire des perturbations volontaires (ex. : délais, pertes, réduction de débit…).

Biais introduits par l’injection de flux non représentatifs

Le comportement d’une sonde peut varier significativement en fonction du trafic reçu. Leurs logiciels de détection doivent, en effet, être en mesure de s’adapter à tout type de trafic susceptible d’être reçu par les équipements qu’elles protègent. Or le traitement d’un grand nombre de petits paquets, ou à l’inverse le traitement de jumbo frames (des trames dont la taille excède les classiques 1514 octets) demande des allocations mémoire contradictoires, ne serait-ce que pour stocker les paquets en attendant leur traitement. De même, de nombreux flux distincts ne se gèrent pas de la même manière que quelques flux bien connus, mais massifs.

Or, une sonde, par défaut, doit savoir gérer toutes ces situations. Leur configuration doit donc être suffisamment générique pour accorder au logiciel la flexibilité nécessaire pour les encaisser. Il en résulte une allocation des ressources potentiellement inadéquates pour des cas extrêmes, comme le traitement d’un trafic réseau à très haut débit. Pire, ces configurations génériques ont tendance à « surbooker » les ressources à disposition. L’hypothèse optimiste est, en effet, que plusieurs situations extrêmes ne se présenteront pas simultanément. Les ressources de la machine étant en quantité finie, il peut alors en résulter des dénis de service du logiciel de détection (ex. : déclenchement de l’OOM Killer de Linux, qui tue les processus consommant beaucoup de mémoire).

Finalement, la nature des flux injectés peut également influencer le comportement de la sonde. Une grande quantité de flux chiffrés est, en général, facile à gérer pour une sonde. Cette dernière n’a, en effet, pas accès aux clés de déchiffrement ; le flux peut donc généralement être ignoré, pour privilégier l’analyse de paquets en clair. À l’inverse, une grande quantité de flux distincts (ex. : sessions TCP ou questions/réponses sur UDP…) peuvent faire exploser les états dans la sonde, comme cela a été détaillé plus haut dans cet article.

Conclusion

Au fil de cet article ont été présentés différents :

goulots d’étranglement d’une sonde ;
ressources critiques ;
sources de lenteur ;
biais pouvant être introduits involontairement lors de l’évaluation.

À moins d’avoir développé une expertise notable dans l’intégration de ce genre d’équipements, il est donc nécessaire de se référer à des guides de déploiement, et des méthodologies de tests éprouvées et génériques. Hélas, de tels documents n’existent pas encore, et les ingénieurs doivent réinventer la roue systématiquement, quitte à en produire des carrées, de temps à autre.

Dans le monde des systèmes industriels, souvent considéré par la communauté de la sécurité des systèmes d’information IT comme le vilain petit canard, ce problème a pourtant déjà été résolu ! La certification ANSI/ISA 62443 et le programme ISA-Secure ¹¹ spécifient une méthodologie d’évaluation très précise des systèmes industriels, et des équipements pouvant automatiser ces tests. Les exigences sont donc clairement établies, les méthodologies de tests documentées, et les produits d’évaluation certifiés. Ces tests incluent la conformité, la robustesse au trafic anormal, et la robustesse contre la montée en charge.

Ces éléments manquent cruellement dans le monde des sondes de détection, dont la réaction peut varier significativement, comme décrit dans cet article, en fonction du trafic reçu, de la nature de ses flux et de son intensité.

Remerciements

Je tiens à remercier mes relecteurs : Erwan Abgrall, Baptiste Bone, Piotr Chmielnicky, Sebastien Larinier, ainsi que ceux qui ont souhaité rester anonymes, et les employés de Gatewatcher. Les avis exprimés dans cet article ne sauraient les engager.

Références

Publié par les Editions Diamond sous licence CC-BY-NC-ND.

Neugebauer et alii., « Understanding PCIe performance for end host networking », août 2018 ↩︎
Étude sur l’incidence des verrous dans Suricata : https://xbu.me/article/performance-characterization-of-suricata-thread-models/ ↩︎
Document sur l’amélioration des performances d’acquisition de Suricata : https://github.com/pevma/SEPTun ↩︎
Rapport d’incident de Cloudflare impliquant leur pare-feu applicatif web : https://blog.cloudflare.com/cloudflare-outage/ ↩︎
Exemples cassant le modèle de threads collaboratifs de Lua : https://stackoverflow.com/a/18964444 ↩︎
Site de l’outil Tcpdump : https://www.tcpdump.org/ ↩︎
Site de l’outil Tcpreplay : https://tcpreplay.appneta.com/ ↩︎
Dépôt de l’outil Scapy : https://github.com/secdev/scapy ↩︎
Documentation sur l’émulation d’incidents réseau avec Traffic Control : https://wiki.linuxfoundation.org/networking/netem#packet_duplication ↩︎
Script permettant de nettoyer les demi-flux : https://frama.link/RfNczV0d ↩︎
Site de la certification ISA Secure : https://www.isasecure.org/en-US/ ↩︎

Python String Emptiness Test

Mon, 25 Mar 2019 00:00:00 +0000

Security specialists have this tendency to focus on the most mundane things, and overthink them to the point where they may actually find something interesting to say about them.

Is that a useful use of their time? That question is open to debate ;p

But I believe writing about them IS a useful use of my time on a gray Sunday morning!

Python String Emptiness Test

A while back, I entered a lengthy debate about condition expressions in Python with one of my colleagues during a merge conflict. We both wrote a utility function expressing the exact same condition, but we had written it in a different way.

He wrote this:

def should_i_do_smth():
    # ...
    return bool(some_string) and some_int == 0

I wrote that:

def should_i_do_smth():
    # ...
    return len(some_string) != 0 and some_int == 0

The only use case of that function was in an if condition:

if should_i_do_smth():

Whose code was merged is not really relevant, but I decided to create a Twitter poll to probe my followers on the topic of writing emptiness tests of Python strings.

The poll was:

According to you, which of the four following lines of #Python code (poll) is the most self-explanatory and the safest to express that the string variable “value” is not empty? All answers are valid Python.

if value:

if bool(value):

if len(value) != 0:

if value != '':

Regarding the poll itself

The wording of the poll is vague on purpose. Depending on the reader, some of the words have different meanings. That was a deliberate choice. It is very hard to express formal things in a natural language. So, even if you have clear instructions, and documentation, and code comments, in the end, what really matters is what was on the mind of the dev when they wrote that line of code.

People who answered the poll may have read differently:

Safest: did I mean that the code must be robust (i.e. not crash) or secure (i.e. act consistently and fail during static analysis)?
String variable: did I mean str or Optional[str], only Unicode string ('') or also bytestring (b'')? Was there a test to control the type? Or static typing analysis?
Not empty: did I mean that we should refuse the empty string only, or should we also refuse None?
Self-explanatory: did I mean that the code should be readable by Python developers abiding to PEP8 and the Zen, or should the code be readable by most people, including security auditors or junior developers that may not be knowledgeable of PEP8 best current practices. Is readable equivalent to explicit and unambiguous?

Of course, the poll results are heavily biased. Most of my followers are security specialists, not software engineers, and certainly not full-time Python developers.

At any rate, I find the results quite interesting, because a majority of people did NOT follow the PEP-8 recommendation when asked this question.

At the time of writing, with 54 voters, the poll results is:

if value: 38%
if bool(value): 4%
if len(value) != 0: 34%
if value != '': 24%

Answer analysis

Each of the poll answers is valid Python, but they all also have merits.

First Answer

if value: might be readable by most full-time Python developers because it is the Python way, recommended by PEP-8. It works because the empty string '' is evaluated to False in the context of a condition expression.

To some extent, it is comparable to the following C code :

char * value;
... instructions ...
if (value && *value) {

This code plays on the fact that a NULL pointer values 0, which is evaluated to False in C. It also plays on the fact that if the string is empty, the first character will be the NULL byte (\0), which is also evaluated to False. This type of syntax requires your reader to be knowledgeable about the language. Thus, if they are, it is very readable. If they are not, then the jury is out.

But the real issue of this syntax is that there is absolutely no type checking whatsoever. That’s not really a problem if you embrace Python’s duck typing and you are well prepared for the consequences of that choice. If you only consider the poll question as it is formulated, and the code is properly guarded so that you are certain that the value variable is a Unicode string, this approach bares no risks.

But what if I lied and the value variable is not a string? What if it is a bytestring? The None value? An integer? An arbitrary object? What if the code is not properly guarded?

I mean, this can happen easily when you refactor your code or when you meddle with some code you don’t fully understand. Sure, unit tests and static analysis are valid answers to refactoring problems… but let’s be honest here: correctly written unit tests are not frequent in the startup industry.

And mistakes happen. One of my followers told me a “war story”:

if i:

Yeah, that’s it ^_^ A colleague of them wrote this test to guard against the None value… but i was an integer. And some day, that integer equaled 0. If you don’t know, 0, in Python, is evaluated as False in a condition expression. Oops.

But let’s say that this integer war story is a corner case. What would happen if the value variable was in fact an instance of a type implementing __bool__ or __len__?

In Python, truth evaluation on arbitrary object is done by trying to call __bool__ that should return the truth value for this object. If __bool__ is not implemented, __len__ is tried. If __len__ returns 0, then the evaluation result is False, else True. Finally, if __len__ is not implemented, then it returns True for variable that are not None nor a scalar that evaluates to None.

class Test:
    def __bool__(self):
        print('>>Bool!')
        return True

value = Test()
if value():
    print('>>Hey!')

>>Bool!
>>Hey!

class Test:
    def __len__(self):
        print('>>Len!')
        return 1

value = Test()
if value:
    print('>>Hey!')

>>Len!
>>Hey!

class Test:
    def __len__(self):
        print('>>Len!')
        return 0

value = Test()
if value():
    print('>>Hey!')

>>Len!

class Test: pass

value = Test()
if value:
    print('>>Hey!')

>>Hey!

With such a high risk of confusion on the actual type of the object, I would personally bet that there is a very high probability of having some unstable code that will assume something about what the value variable is capable of, resulting in the infamous AttributeError: 'Foo' object has no attribute 'bar'. Or worse: no crash and a very stupid result.

You understood it, this all boils down to the discussion about typing, and the fact that the more checks (notably typing checks) are done statically, the more robust the code. And that is a fact that many languages have caught on. PHP, Python, Javascript, Perl, almost all interpreted languages (with the exception of Ruby 😂) have adopted a type hinting syntax to help static analyzers verify the code sanity. In Python, PEP-484 defines the syntax and you can use MyPy to do the checking.

So, if you hinted that the type of value was str before the if value: statement, then your code is probably safe and robust if you use a static analyzer.

def foo(value: str):

If you do not have a type hint and you don’t use a static analyzer, then your code is not readable because your intention about what is acceptable is not explicit. Thus, and your code is not robust/safe because you will probably end up crashing.

Second Answer

The second answer is nonsensical and I admittedly did a poor job at representing the opinion of my colleague when writing this poll. Let’s put it on the fact that I was forced to use their solution.

if bool(value): is stupid because we already are in the context of a boolean evaluation, so the bool casting is redundant. However, their opinion is not without ground in other contexts.

For instance, in the following code, what would you replace XXX with?

def foo() -> Tuple[str, int]:
    """some instructions"""
    # ...
 
def bar() -> XXX:
    s, i = foo()
    return s and i

If you answered bool, you are wrong. XXX must be replaced by Union[str, int].

error: Incompatible return value type (got "Union[str, int]", expected "bool")

That’s because Python logical operators do not return booleans! In the case of the and operator, it returns the first value that cannot be evaluated to True.

Thus, if you meant the bar function to return a boolean, you need to cast the whole expression as bool before returning it.

def bar() -> bool:
    s, i = foo()
    return bool(s and i)

You can also only cast elements that are not comparisons, because, at least, comparisons do return booleans:

def bar() -> bool:
    s, i = foo
    return bool(s) and i != 0

The fact that Python logical operators return arbitrary values is very surprising to people that come from some other languages, such as C or even PHP, where the logical operators return a truth value. For people coming from very strongly typed languages such as Ocaml or Rust, this is difficult to even consider, because logical operators are typed and would only accept booleans as operands in the first place.

$ echo '''#include <stdio.h>

int main(){
  printf("> %d\n", 2 && 3);
  return 0;
}''' | gcc -o /tmp/condition -x c -

$ /tmp/condition
>1

$ php -r 'echo 2 && 3;'
1

Once you consider that you need to explicitly cast to bool all of your values in a logical expression to output a boolean, the readability and robustness/safety arguments are identical to those of the first answer.

Third Answer

The third answer is the first that is not relying on the Python language specification to express a condition. It explicitly states which particular characteristic of the content of the value variable is studied and must not be equal to 0 and it returns an unambiguous result: a truth value: True or False.

Regarding code safety, the result is mixed. It is the only answer out of the four that will crash the program during runtime if value is the None value.

TypeError: object of type 'NoneType' has no len()

Depending on the purpose of the program, crashing early may or may not be desirable. A ex-colleague working on machine learning told me that they would prefer to have a program crash early because of a type bug like this, than to have the program run for hours only to crash later with a AttributeError: 'NoneType' object has no attribute 'foo'.

Of course, the best option is to test the program, and check the parameters against the API contract so that this situation never occurs. But what if the test is broken (for instance, because it was written with the syntax from the first answer) and it let through a value that was not intended?

Unfortunately, this answer is also susceptible to cause late crashes because of duck typing. The len() function is only a keyword that calls on the __len__ implementation of the receiver (that is the object provided as len()’s argument. This means that this test won’t guard against objects implementing __len__, just like str, but not being a string. The perfect builtin example would be the bytestring.

value = b'bonjour'
if len(value) != 0:
    l = a.split('o')

TypeError: a bytes-like object is required, not 'str'

All in all, this answer is relatively explicit in what is tested and what’s the intended result. But even if an early crash might be desirable, a crash is not certain because duck typing will let invalid objects go through.

Fourth Answer

The fourth answer is pretty straightforward. The meaning is crystal clear: it evaluates to True as long as value is not the empty Unicode string. Anybody gifted with eyes can read this expression and understand what is the intent of the author.

It won’t be abused by the empty bytestring. It won’t be abused by the None value. It won’t be abused by objects implementing __str__.

class Test:
    def __str__(self) -> str:
        return ""

value = Test()
if value != "":
    print("Foo")

Foo

Wait, what? It printed Foo?! Oh, yeah. Right. All objects of a different type than str, and even objects of type str if they are not the empty string will make this condition evaluate to True. They are not equal to the empty string. That is exactly what is expressed by the condition.

If what you really mean is that the value must be a string and not the empty string, then, you need to write an even more explicit version of this:

if isinstance(value, str) and value != "":

(note: using isinstance() is prefered to type(value) is str just in case someone got the extra-weird idea to subclass str; don’t do that. Unfortunately, type(value) is str would have been so much more readable)

A Word About Efficiency

To my very own surprise, there is a significant difference of performance between the four answers. The slowest take twice as much time as the fastest (2.19 times more, to be precise).

It is in the realm of micro-optimizations but since the difference is so large, I think the result is worth including in this post.

For 10 million iterations, run 100 times to clear out statistical noise, the average results are:

Answer	Time	Ratio
First	1.28s	1
Second	2.81s	2.19
Third	1.92s	1.5
Fourth	1.52s	1.19

Conclusion

As I stated in the poll itself, all four of the answers are totally valid Python code. However some answers will make full-time Python developers abiding by the PEP-8 recommendations cringe. Some even implemented tools that would whine specifically on one of the answers. That’s the case of the third answer that will make pylint, a Python code linter, complain about the use of len() to test if an sequence is empty (because a str is also an character sequence):

Do not use `len(SEQUENCE)` to determine if a sequence is empty (len-as-condition)

We also saw during the discussion about the advantages and drawbacks of the first answer that if one makes a proper use of type hinting and static code analysis (e.g. mypy), there may be little code safety problems with it; just a readability issue because the intent of the developers about which use cases are covered remains obscure.

Overall, my personal belief is that the fourth answer (especially when guarded with the isinstance() call) should be prefered because the developer’s intent is explicit and one gets exactly what they asked for, without any of the magic offered by the language.

Please post your comments as answers on Twitter or on the Fediverse!

About

Sun, 24 Mar 2019 23:22:48 +0100

My name is Florian Maury. I am a network and protocol security specialist.

My resume

My social media links:

Fediverse

My Contact Info:

florian.maury-website@broken-by-design.fr

A PKI Rant: the Free (as in free beer) Certificate Problem

Wed, 24 Oct 2018 00:00:00 +0000

Intro

Someone asked me what I had to object to this article about free certificates versus paying ones.

The competing interests problem

First of all, I agree that many CAs (Certificate Authorities) are overselling their certificates, granting them properties or responsibilities that are not factual or even accurate on the technical level. The examples provided in the article are excellent. Where my opinion starts to diverge is near the conclusion. Most people will say that the following is pure FUD, and they would not be absolutely wrong. I have nothing to prove my statements; these are hypotheses, and things to look out for. Truth is I don’t feel like I am not FUDing, or I would not speak up. I think I am just being extra precautious.

First, I find amusing that many people like to quote “if that is free, then you are the product”, but when it comes to Let’s Encrypt, they forget this statement and enjoy their certificates carelessly. So, you might ask: “How am I a product, when I am a client of Let’s Encrypt? They are not selling my information, and even if they were, all they have on me and my website are public data”. True. Your information is not a good for Let’s Encrypt, as far as I know. What you are, however, is a wallet, who is no longer opening to give money to any CAs. You see, operating a CA is not free, nor even cheap (especially when you consider that Let’s Encrypt staffing budget was a whooping $2.06M for 10 people in 2017 ). So if you get your certificates for free, someone is paying for them. Let’s see, “platinum sponsors” (over $300K annually):

EFF: OK.
OVH: they make a heavy usage of Let’s Encrypt for their shared hosting; OK.
Cisco and Akamai: hmm, OK.
Mozilla and Chrome? Uh-oh.

You see, if Let’s Encrypt is giving certificates for free, other CAs won’t sell any, because people know that there is no difference between a paying DV certificate and a Let’s encrypt DV certificate (or now, they know, thanks to the aforementioned article). Since browsers are increasingly lowering the value of EV certificates, people have less and less incentive to pay for them. (Did you notice there is no longer any green bar (or indicator for that matter) in Chrome?) Thus, people won’t buy DV or EV certificates from commercial CAs. What will happen to them? They will either shut down their business or become increasingly less secure, because of the lack of funding. Good riddance will say those that consider they have been swindled enough by these CAs. But what the sponsors of Let’s Encrypt are doing, really, is leading a war of attrition on commercial CAs by sponsoring an organization that is losing money with each emitted certificate. That’s called unfair competition and that is the road to monopolies, too-big-to-fail entities, and single point of failure. That is also the road to an entity whose main sponsors are consumers of the product, and who may have competing interests.

What do you think will happen if, say, Google requires drastic changes in CA policies at the CA/B Forum and the main CA is also dependent on Google’s funding to exist and operate properly?

The Certificate Transparency problem

Also, you may consider that free certificates are a bane because people act more carelessly with what is literally worthless, than if they had paid $1 for it. Did you ever come across people who are registering certificates during their boot-up procedures and throw them away during the shutdown procedure (docker containers, hello!)? Well, these certificates are ephemeral only if you consider the registrant.

You see, Let’s Encrypt is not all bad; they have implemented ACME, and they started registering all their certificates to Certificate Transparency (CT) logs long before April 2018, when it became required by some browsers. For those not familiar with CT, it is a collection of append-only logs where certificates emitted by (“public”) CAs are registered, for them to be publicly auditable. The important word in the previous sentence is “append-only”. That means that the so-called ephemeral certificates are logged forever in these CT logs. This causes massive scaling issues on the CT ecosystem, because log operation requires a lot of memory and the CT logs are literally spammed with free certificates. This, in turn, causes CT log sharding (certificates are logged into different CT logs based on some criteria), which increases the difficulty for website owners to monitor these logs and use them properly.

Conclusion

If DV certificate price was low but non-null, commercial CAs would still be able to exist, and Let’s Encrypt would be less dependent on their sponsor and less influenced by their agenda and pressures. So I dare say that free certificates are actively harming the web PKI.

This content was originally posted by myself on https://fediverse.blog/~/InfiniteTypingPlatypuses/a-pki-rant-the-free-as-in-beer-certificate-problem.

SMTP : la « killer app » de DNSSEC

Tue, 01 May 2018 00:00:00 +0000

Huit ans après le déploiement de DNSSEC par la racine du DNS, cette technologie peine encore à trouver son public et à prouver son utilité. Cet article démontre que la sécurité des échanges de courriers électroniques avec SMTP contre des attaquants actifs ne peut être atteinte en l’absence de DNSSEC, compte tenu des standards et implémentations actuels.

DNSSEC assure l’intégrité cryptographique des enregistrements DNS. Sa faible adoption peut s’expliquer par une complexité à l’implémentation et lors de sa maintenance, et par le fait que cette technologie est inutile, la plupart du temps. En effet, le DNS est principalement utilisé pour la résolution de noms de domaine en adresses IP, en vue d’accéder à un service tiers. Si ce service est authentifié et protégé en confidentialité et en intégrité, comme c’est le cas avec TLS, alors l’attaque active est contrée au moment de l’établissement de cette communication sécurisée. À l’inverse, protéger en intégrité le DNS alors que le service contacté n’est pas lui-même authentifié semble au mieux inutile : l’attaquant actif pourra généralement attaquer le service directement.

SMTP, le protocole d’échange de courriers électroniques se trouve, hélas, dans le second cas de figure, bien que la plupart des implémentations prennent en charge TLS. En effet, pour des raisons historiques et de déploiements progressifs transparents, les serveurs de courriers électroniques ne vérifient pas ou mal les certificats X.509 fournis dans le cadre de SMTP sur TLS. Ainsi, les communications entre serveurs de courriers électroniques ne bénéficient généralement que d’une protection contre les écoutes passives ; un attaquant actif pourra effectuer une interception aisément, sans même avoir à fournir un certificat frauduleux usurpant l’identité de la victime.

Les attaques actives ne se limitent cependant pas au protocole SMTP, mais s’étendent à son écosystème. En effet, les serveurs de courriers emploient de nombreuses techniques pour éviter l’usurpation d’identité de l’expéditeur d’un courrier électronique, dont des politiques de sécurité publiées dans le DNS.

Cet article expose l’impossibilité de sécuriser les échanges SMTP en l’absence d’intégrité cryptographique des enregistrements DNS, que ce soit pour récupérer les politiques de sécurité évoquées ci-dessus, ou pour effectuer une vérification de certificats efficace.

1. État des lieux

Cette section dresse un état des lieux du déploiement des technologies utilisées dans l’écosystème SMTP et qui peuvent être sécurisées grâce à DNSSEC. Des mesures actives ont été effectuées par l’auteur de cet article en vue de présenter au lecteur une image dénombrée. L’outil de mesures, la méthodologie, ainsi que les résultats bruts peuvent être consultés en ligne ¹.

1.1. TLS pour SMTP

Dans le précédent numéro de MISC, Arthur Provost et Olivier Levillain présentaient les résultats de mesures actives sur les serveurs SMTP afin d’évaluer la qualité des déploiements de TLS. Leur étude permet d’obtenir une estimation intéressante de la sensibilisation des administrateurs de serveurs de courriers électroniques aux bonnes pratiques de sécurité. Elle ne permet, cependant, pas d’évaluer la quantité de courriers électroniques ainsi protégés, car elle comptabilise les serveurs et non les messages envoyés entre ces serveurs. Or, le trafic des courriers électroniques est extrêmement concentré sur quelques plateformes d’hébergement mutualisé ².

Cette concentration implique que la sécurisation de quelques acteurs permet de protéger un grand pourcentage des communications. Ainsi, plusieurs initiatives nationales et internationales ont été lancées, afin d’encourager l’adoption de TLS pour sécuriser les échanges entre les grands fournisseurs de service de transport de courriers électroniques, au nombre desquelles celle de Google, de l’ANSSI ou encore du BSI, l’agence nationale de sécurité des systèmes d’information allemande.

À ce titre, Google publie des statistiques publiques sur l’utilisation de TLS entre ses serveurs SMTP et les serveurs SMTP des organismes avec lesquels ils échangent [“SaferEmail]. Il y est notamment possible d’observer le pourcentage de courriers envoyés sur un canal chiffré, par domaine expéditeur/destinataire.

L’ANSSI a également rédigé une charte ³, en collaboration avec plusieurs fournisseurs de service français, afin d’ériger des engagements de sécurité minimaux devant être mis en œuvre par les signataires (Orange, SFR/Numéricable, Bouygues Télécom, Free et La Poste).

Finalement, le BSI a publié un document ⁴ fournissant des recommandations de sécurité pour les fournisseurs de service de courriers électroniques allemand s’étant autosaisis de la problématique. Il est intéressant de noter que le BSI encourage l’emploi de DNSSEC dans son document.

1.2. DNSSEC

L’auteur de cet article décrivait dans ces mêmes colonnes, en 2012, trois mécanismes employant DNSSEC afin de venir au secours de la validation des certificats X.509 : DANE ⁵, CAA ⁶ et un mécanisme non standard d’épinglage des certificats par l’entremise de DNSSEC. Six ans plus tard, force est de constater que ces mécanismes sont peu implémentés ⁷ ⁸. Et pour cause : DNSSEC peine à se généraliser, avec un taux d’adoption autour de 12,5% des noms de domaine se terminant en « .fr. », dont la majorité sont signés automatiquement par les bureaux d’enregistrement dans le cadre de la création de nouveaux noms de domaine ².

Du côté des autorités de certification, la prise en charge de DNSSEC n’est pas obligatoire, même pour les autorités de certification émettant des certificats où seul le contrôle temporaire d’un nom de domaine est validé (certificats dits « DV », pour « Domain Validation »). En fait, la seule mention de DNSSEC dans les prérequis minimaux édictés par le CA/B Forum – une entité réunissant les autorités de certification et les principaux navigateurs web – a trait au comportement à adopter dans le cas d’un échec de vérification d’une signature DNSSEC dans le cadre de CAA ⁹.

Certaines autorités de certification, comme Let’s Encrypt, implémentent cependant la validation DNSSEC de leur propre chef pour l’émission de certificats DV ; un fait à porter à leur crédit.

1.3. SPF

SPF ¹⁰ est une politique de sécurité permettant à un émetteur de courriers électroniques de spécifier la liste des serveurs/adresses IP autorisés à envoyer des courriers provenant de son nom de domaine. Cette politique est publiée sous la forme d’un enregistrement DNS de type TXT à l’apex (c’est-à-dire « tout en haut ») de la zone DNS correspondant au domaine DNS expéditeur à protéger. Par exemple, pour l’expéditeur john@example.com, l’enregistrement SPF suivant sera consulté :

example.com. 86400 IN TXT “v=spf1 ip4:192.0.2.1 -all”

Cette donnée est directement consommée par un validateur SPF et aucun autre mécanisme de sécurité n’intervient ultérieurement pour la protéger, comme c’est le cas avec TLS pour les courriers électroniques. Les enregistrements SPF mériteraient donc d’être protégés en intégrité grâce à DNSSEC. La RFC7208 n’oblige cependant pas la signature ou la validation cryptographique de cet enregistrement DNS, permettant ainsi à un attaquant actif de modifier cet enregistrement à la volée et autoriser des adresses IP sous son contrôle à émettre des courriers.

Le déploiement de SPF pour les domaines délégués depuis le nom de domaine de premier niveau (en anglais, TLD) « .fr » est d’environ 37%. Cependant, seuls 7,4% des zones étudiées contiennent des enregistrements SPF signés avec DNSSEC.

1.4. DKIM

DKIM Signatures ¹¹ est une politique de sécurité permettant à un émetteur de courriers électroniques de signer cryptographiquement certains en-têtes et tout ou partie du contenu des courriers provenant de son domaine. Cette technologie vise ainsi à prévenir l’usurpation d’identité de l’expéditeur et permet la détection en cas d’altération des courriers pendant leur transit.

La signature DKIM est placée dans les en-têtes d’un courrier électronique. En voici un exemple :

DKIM-Signature: d=example.net; s=chaine_arbitraire; …

La clé publique utilisée pour effectuer la vérification de cette signature est publiée dans le DNS, dans un enregistrement TXT. Cet enregistrement est publié dans un nom de domaine composé du domaine spécifié dans la métadonnée d= de la signature, préfixée de la chaîne constante _domainkey, elle-même préfixée d’un sélecteur (une chaîne de caractères arbitraire, spécifiée dans la métadonnée s= de la signature). Ainsi pour la signature donnée en exemple ci-dessus, l’enregistrement DNS suivant est récupéré :

chaine_arbitraire._domainkey.example.net. 86400 IN TXT “v=DKIM1; k=rsa; p=base64clef”

Bien que la RFC6376 ne requière pas l’authentification cryptographique de la clé publique servant à vérifier la signature des courriers électroniques, DNSSEC permet de « certifier » cette clé, la protégeant ainsi d’attaquants actifs.

Le déploiement de DKIM ne peut être mesuré avec précision, les sélecteurs étant imprédictibles par l’outil de mesure. Il est cependant possible d’inférer l’absence d’enregistrements relatifs à DKIM grâce à la RFC8020 ¹². Celle-ci dicte que le DNS est une base de données arborescente, et donc qu’un domaine ne peut exister que si tous les domaines parents existent aussi. Ainsi, il est possible de déterminer un pourcentage de domaines n’utilisant pas DKIM, en comptant les domaines pour lesquels le sous-domaine _domainkey n’existe pas. Les autres domaines utilisent peut-être DKIM ou sont des faux positifs.

Pour les domaines délégués depuis le TLD « .fr », 81% des domaines n’emploient pas DKIM. Seul 1% des domaines étudiés sont susceptibles d’utiliser DKIM et sont signés avec DNSSEC. Ces 1% constituent la borne haute du nombre de noms de domaine utilisant DKIM avec une protection contre les attaquants actifs.

1.5. DMARC

DMARC ¹³ est une politique de sécurité publiée dans le DNS, permettant de spécifier des actions à prendre en cas de violation des politiques SPF et DKIM. Cette politique est publiée dans un enregistrement TXT localisé dans le sous-domaine _dmarc du domaine de l’expéditeur d’un courrier, dont voici un exemple :

_dmarc.example.net. 86400 IN TXT “v=DMARC1; p=none; pct=100; ruf=mailto:dmarc-feedback@example.com"

Des exemples d’actions à prendre en cas de violation de SPF et DKIM incluent de défausser les courriers jugés frauduleux, de les mettre en quarantaine, et éventuellement de rapporter cet échec auprès d’un serveur. De manière cruciale, ces rapports peuvent contenir des extraits de courriers électroniques. Pour un domaine n’étant pas protégé par DNSSEC, un attaquant est donc en mesure de modifier les enregistrements DKIM, de façon à faire passer un courrier électronique pour frauduleux, puis de retourner un faux enregistrement DMARC permettant l’exfiltration d’informations du courrier.

Le déploiement de DMARC est très faible, avec seulement 1,4% des noms de domaine délégués depuis le TLD « .fr » l’implémentant. Seuls les enregistrements de 1,5 domaine pour mille sont, en outre, protégés par DNSSEC. Finalement, comme noté dans la section 1.2, seuls 12,5% des domaines étudiés sont signés avec DNSSEC et sont donc à l’abri de toute attaque active impliquant DMARC en vue d’exfiltrer le contenu des courriers électroniques.

2. Modélisation d’un attaquant actif

Dans cette section, nous allons exposer une liste non exhaustive des possibilités d’un attaquant actif à l’encontre de SMTP sur TLS, en vue de casser la confidentialité des métadonnées ou des échanges en général.

2.1. Négociation TLS

Certains protocoles, comme IMAP ou POP disposent d’un mode d’usage de TLS dit « implicite ». Cela signifie que la version sécurisée de ces protocoles dispose d’un numéro de port TCP spécifique (IMAPS/993, POPS/995), et que lorsqu’un serveur est contacté sur ce port, TLS doit être employé dès les premiers segments échangés sur une nouvelle connexion TCP. La version TLS implicite de SMTP, appelée SMTPS et employant le port 465, a hélas été supprimée des registres de l’IANA, et le port 465 a été réalloué pour d’autres usages. SMTPS n’existe donc plus.

Certains protocoles disposant de TLS implicite existent également dans une version dite « explicite ». Dans ce cas, la connexion TCP est effectuée sur les ports « en clair » (IMAP/143, POP/110). C’est alors à la couche applicative (IMAP, POP), d’exprimer dans son dialecte qu’une amélioration de la sécurité de la communication est désirée. Cela s’exprime généralement par l’affichage d’une option STARTTLS par le serveur, et que le client est libre de solliciter en envoyant le message STARTTLS. Lorsque le client sollicite l’usage de TLS proposé par le serveur, les échanges en clair sont interrompus et la même connexion TCP est subitement employée pour échanger des messages TLS en vue de négocier des clés, puis de transférer du trafic chiffré. L’extrait de session SMTP ci-dessous illustre une négociation de STARTTLS. Les lignes préfixées par S: sont envoyées par le serveur, et celles par C: par le client.

S: 220 smtp.gmail.com ESMTP 186sm7907497wmm.32 - gsmtp
C: EHLO x-cli.eu
S: 250-smtp.gmail.com at your service, [2001:41d0:51:1::716]
S: 250-SIZE 35882577
S: 250-8BITMIME
S: 250-STARTTLS
S: 250-ENHANCEDSTATUSCODES
S: 250-PIPELINING
S: 250-CHUNKING
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 Ready to start TLS

L’avantage de l’emploi de TLS de façon implicite est que si la connexion TCP/TLS est ouverte avec succès, il n’y a aucun doute sur le fait que les messages transférés sont protégés. Avec TLS en mode explicite, la même assurance ne peut être fournie. Certains clients codés « un peu rapidement » poursuivent, en effet, l’envoi du courrier en clair, sans noter les erreurs renvoyées par les serveurs ne souhaitant pas recevoir en l’absence de TLS.

En outre, l’indication que le serveur prend en charge TLS et la sollicitation de chiffrement du client sont échangées en clair. Un attaquant actif est donc en mesure de corrompre le trafic afin de dissimuler/supprimer l’option/la sollicitation, afin que la négociation TLS ne soit pas effectuée. Cette attaque porte le nom de STARTTLS Stripping. Ce risque n’est pas théorique ; dans un excellent papier de Google, l’université du Michigan et l’université de l’Illinois ¹⁴, des chercheurs ont effectué une étude des connexions SMTP vers les serveurs de Gmail. Ils ont ainsi découvert qu’une grande quantité des connexions SMTP avec TLS explicite à destination de Gmail était altérée par des attaquants actifs. Dans certains pays, comme la Tunisie, jusqu’à 96% des connexions sont affectées par un attaquant, tandis que 9% des connexions sont affectées en France, et plus particulièrement à l’île de la Réunion.

Le mode opératoire de l’attaquant est de remplacer à la volée dans la connexion TCP l’option du serveur ou la sollicitation du client par une chaîne de même longueur que STARTTLS, non reconnue par l’autre partie, comme XXXXXXXX. En conséquence, le client ne verra pas l’option STARTTLS, mais une option XXXXXXXX qu’il ne sait pas utiliser, ou le serveur recevra une commande XXXXXXXX du client, à laquelle il répondra avec un message d’erreur indiquant qu’il s’agit d’une commande invalide.

Finalement, la validation des certificats TLS dans le cadre de SMTP est très en retard par rapport à celle de HTTPS. Par exemple, dans l’étude ¹⁴, environ 66% des certificats présentés par les serveurs SMTP sont invalides (mauvais sujet, principalement, mais aussi certificats périmés ou autosignés).

Le chiffrement est dit « opportuniste » lorsque les serveurs SMTP acceptent aveuglément tout certificat présenté. C’est le cas de la plupart des déploiements de SMTP sur l’Internet. De plus, au moment où ces lignes sont écrites, aucune implémentation de SMTP sur TLS connue de l’auteur n’est compatible avec Certificate Transparency. Comparativement, pour le web, tout certificat émis à partir d’avril 2018 et n’étant pas dans Certificate Transparency est jugé invalide par le navigateur Chrome.

Certificate Transparency est une technologie et un écosystème qui permettent au titulaire d’un nom de domaine de lister les certificats émis pour son nom de domaine, et d’ainsi vérifier qu’ils ont tous été émis avec son accord. Certificate Transparency a été présenté dans MISC Hors-Série n°13, article « Souriez ! Les autorités de certification sont filmées ! ».

2.2. Remplacement des enregistrements MX

Lorsqu’un serveur SMTP cherche à envoyer un courrier électronique à un tiers inconnu, la recherche du serveur SMTP à contacter s’effectue grâce au DNS. Pour cela, une recherche d’enregistrement de type MX (pour Mail eXchanger, ou relais de courriers, en français) est initiée. Ces enregistrements contiennent les noms des serveurs SMTP à contacter, noms qui doivent ensuite être résolus en adresse IP. Voici un exemple d’enregistrements MX :

example.com. 86400 IN MX 5 mail1.example.com.
example.com. 86400 IN MX 10 smtp.example.net.

Dans le même papier ¹⁴, les chercheurs ont également évalué la propension des attaquants à remplacer les enregistrements MX légitimes par des enregistrements MX contenant des noms de domaine sous son contrôle. Ce faisant, le serveur expéditeur enverra le courrier directement aux serveurs de l’attaquant, qui pourra prendre connaissance du contenu. L’attaquant peut, ensuite, éventuellement faire suivre le courrier aux vrais serveurs destinataires afin de rendre « transparente » l’attaque, en l’absence d’une politique SPF sur le domaine expéditeur. En présence de SPF, l’attaquant peut émuler un problème serveur, à la suite de la réception du contenu du courrier, par exemple, en renvoyant une erreur temporaire, indiquant un espace de stockage insuffisant (erreur 452). Le serveur expéditeur original réessaiera alors de transmettre ultérieurement le courrier, cette fois-ci au serveur destinataire légitime, qui saura valider la légitimité de l’expéditeur avec SPF.

Les auteurs de ¹⁴ ont interrogés les serveurs DNS récursifs et les relais DNS (forwarders) souffrant d’un défaut de contrôle d’accès (serveurs appelés résolveurs DNS ouverts) afin de collecter des réponses DNS depuis de nombreux points d’observation de l’Internet. Le résultat de ces mesures actives a révélé que 2% des serveurs DNS interrogés renvoyaient une réponse frauduleuse pouvant mener au détournement de courriers électroniques.

Il convient de noter que cette attaque ne saurait être prévenue même si l’expéditeur exigeait l’utilisation de TLS avec des certificats X.509 valides (sujet, dates, usage, etc.) de la part du destinataire. En effet, l’hébergement mutualisé de plusieurs domaines sur un seul serveur SMTP de réception n’emploie pas l’extension TLS appelée SNI. À la place, c’est le nom du serveur SMTP fourni dans l’enregistrement MX qui est généralement recherché à l’intérieur du certificat présenté par le serveur SMTP destinataire. Or, si l’enregistrement MX n’est pas signé avec DNSSEC, celui-ci peut être modifié à la volée par un attaquant pour y mettre tout nom sous son contrôle et pour lequel il est en mesure d’obtenir un certificat valide et légitime.

SNI permet de spécifier lors de l’initialisation de la connexion TLS, un nom de domaine spécifique parmi plusieurs domaines cohébergés sur la même machine ; c’est ainsi que l’on peut avoir plusieurs hôtes virtuels (Virtual Host) sur une même adresse IP servant du HTTPS.

L’emploi de SNI aurait permis à un expéditeur de préciser pendant la négociation TLS qu’il envoyait un courrier électronique à destination d’une adresse en @example.com. Le serveur de destination aurait alors pu fournir un certificat valide pour example.com.

Plusieurs explications existent pour justifier ce choix qui semble sous-optimal. En premier lieu, les serveurs SMTP réutilisent les connexions TCP/TLS ouvertes entre deux hôtes, afin de créer un pipeline. Cette réutilisation vise à éviter, lorsque c’est possible, le coûteux établissement d’une connexion TCP/TLS pour l’envoi d’un unique courrier. Il ne semblerait donc pas correct de réutiliser une connexion établie et authentifiée pour example.com pour l’envoi d’un courrier au nom de domaine cohébergé example.net. À la place, deux connexions indépendantes vers la même adresse IP devraient être employées ; un coût que tous les opérateurs ne souhaitent pas payer.

Ensuite, utiliser SNI présente le défaut de divulguer une partie des métadonnées (le nom du domaine du destinataire parmi les N domaines cohébergés) à un attaquant passif écoutant le réseau.

3. La contre-mesure : DNSSEC et DANE

Comme vu dans les précédentes sections de cet article, DNSSEC fournit une aide contre les attaquants actifs. Notamment, les signatures cryptographiques des enregistrements DNS permettent d’assurer l’intégrité et l’authentification de la source des données des technologies SPF, DKIM et DMARC. En outre, une vérification effective des informations contenues dans les certificats TLS pourrait être effectuée puisque DNSSEC confirme l’authenticité des noms présents dans les enregistrements MX.

Un aspect « chiffrement opportuniste » demeure néanmoins, lors du signalement de la prise en charge de TLS par le client et le serveur, avec STARTTLS, comme expliqué dans la section 2.1 de cet article. Il est, bien sûr, possible de refuser de communiquer avec toute personne n’offrant pas TLS. L’attaquant qui corrompt la négociation de TLS ne pratique alors qu’un déni de service, puisque les deux parties refuseront de communiquer en l’absence de canal chiffré. Ce choix peut être raisonnable pour certains types d’infrastructures, d’interconnexions ou d’organismes. Sur l’Internet, et en particulier dans un réseau comme SMTP où toute partie peut écrire à un autre, une telle intransigeance n’est cependant pas réaliste. En conséquence, il est nécessaire de disposer d’un mécanisme de signalement de la prise en charge de TLS qui soit lui-même résistant aux attaquants actifs, largement déployable, et ce de manière incrémentale.

DNS remplit le cahier des charges, avec son rôle d’annuaire protégé en intégrité par DNSSEC. Il est ainsi possible de publier un enregistrement DNS indiquant que le serveur SMTP contacté prend en charge TLS ; cet enregistrement pourra alors être récupéré par un client SMTP, au moment où il demande les enregistrements MX.

La technologie DANE ⁵ permet d’effectuer ce signalement de la prise en charge de TLS par la simple présence d’un enregistrement DNS de type TLSA. Il convient de noter que la spécification requiert que l’enregistrement TLSA soit signé et vérifiable par DNSSEC, ce qui apporte la protection contre l’attaquant actif.

Cet enregistrement est situé dans un sous-domaine des noms de domaine contenus dans les enregistrements MX. Plus précisément, le nom du MX est préfixé de la chaîne _25._tcp.. Ainsi, le serveur smtp.gmail.com pourrait disposer d’un enregistrement TLSA comme celui-ci :

_25._tcp.smtp.gmail.com. IN TLSA 3 1 1 Base64DuCertificatOuDeLaClefPublique

L’objectif de DANE dépasse celui du simple signalement de prise en charge de TLS, et permet notamment d’épingler le certificat ou la clé publique qui doivent être présentés par le serveur contacté. Pour cela, des outils comme ¹⁵ permettent de générer l’enregistrement TLSA à partir d’un certificat. Il suffit alors de le publier dans la zone DNS appropriée et de signer cette dernière avec DNSSEC.

Côté serveurs SMTP expéditeurs, la configuration pour la prise en compte de DANE est un peu moins aisée, puisqu’il faut valider les réponses DNSSEC d’une part, et configurer le serveur pour demander les enregistrements DANE d’autre part. La validation DNSSEC en elle-même devrait être effectuée par un résolveur validant local (Unbound ou Knot-Resolver sont de bons choix). Ensuite, avec Postfix, l’administrateur doit indiquer dans son fichier de configuration main.cf les lignes suivantes :

smtp_tls_security_level = dane
smtp_dns_support_level = dnssec

Ces lignes indiquent à Postfix de se comporter comme suit : en présence d’un enregistrement TLSA validé, le serveur contacté doit prendre en charge TLS ; si un attaquant actif corrompt l’échange et que l’option STARTTLS n’est pas négociée, Postfix ne transmet pas le courrier électronique. En cas d’erreur de validation de l’enregistrement TLSA, ou d’absence de réponse du serveur, le même comportement conservatoire doit être adopté. Dans les cas où la réponse DNS n’est pas signée, ou si elle ne contient pas d’enregistrement TLSA, alors le chiffrement opportuniste est employé avec le serveur contacté. En conséquence, le mode dane de Postfix permet un déploiement progressif, offrant une sécurité contre les attaquants actifs si DANE est employé, et conservant le chiffrement opportuniste dans le cas contraire.

4. Conclusion

Dans cet article, nous avons étudié différentes menaces pouvant affecter les échanges de courriers électroniques, en présence d’un attaquant actif. La figure 1 rappelle ces dernières de manière synthétique.

Fig. 1 : Synthèse des menaces étudiées dans cet article pouvant affecter les échanges de courriers électroniques. Les flux en rouge sont créés ou modifiés par l’attaquant.

Nous avons également observé l’effet positif que DNSSEC peut avoir pour améliorer la sécurité des échanges de courriers électroniques. Hélas, son faible taux de déploiement à ce jour, signifie que la plupart des courriers électroniques peuvent être et sont la proie d’attaques actives plus ou moins ciblées (comme le cas tunisien, évoqué en section 2.1 nous l’a montré).

Les utilisateurs souhaitant échanger de manière confidentielle sont encouragés à chiffrer le contenu de leurs courriers électroniques, en complément de la protection offerte, de manière opportuniste ou non, par TLS. Il existe pour cela plusieurs options, dont des moyens intégrés (comme S/MIME ou, dans une moindre mesure, OpenPGP), ou non (comme ceux listés dans le catalogue des produits certifiés par l’ANSSI). Dans le cas du chiffrement opportuniste, les métadonnées de ces échanges ne sont, cependant, protégées que contre les écoutes passives lors de leur transit sur le réseau. Les administrateurs de serveurs de courriers électroniques souhaitant offrir une sécurité adéquate à leurs utilisateurs contre les attaques actives devraient donc signer leurs zones DNS avec DNSSEC, publier des enregistrements TLSA, et configurer leurs serveurs pour utiliser DANE lorsqu’il est disponible.

Pour finir, publier des enregistrements SPF, DKIM et DMARC signés participe à lutter contre les usurpations d’identité. Il convient cependant d’exiger des signatures DNSSEC sur les enregistrements DMARC ou de désactiver l’envoi de rapports dans son validateur DMARC, lorsque la configuration logicielle le permet, afin d’éviter les exfiltrations de métadonnées sur les courriers électroniques.

5. Remerciements

Je tiens à remercier mes relecteurs, Baloo (@baloose), Olivier Levillain et Christophe Malinge, pour leurs remarques constructives qui ont significativement contribué à l’amélioration de cet article.

Merci également à Claudio Fiandrino pour son code TikZ pour topologies réseaux, publié en ¹⁶.

6. Références

Publié par les Editions Diamond sous licence CC-BY-NC-ND.

Outil de mesures DNS développé pour cet article : https://github.com/X-Cli/collectDNSSECEmailStats ↩︎
Observatoire de la résilience de l’Internet français : https://www.ssi.gouv.fr/observatoire ↩︎ ↩︎
Charte de l’ANSSI pour l’amélioration de la sécurité des échanges de courriers électroniques : https://www.ssi.gouv.fr/particulier/precautions-elementaires/charte-pour-la-securite-des-courriers-electroniques/ ↩︎
Document équivalent au lien précédent, rédigé par l’homologue de l’ANSSI en Allemagne : http://www.project-consult.de/files/BSI_TR03108-1_Sichere_EMail.pdf ↩︎
The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol : TLSA https://tools.ietf.org/html/rfc6698 ↩︎ ↩︎
DNS Certification Authority Authorization (CAA) Resource Record : https://tools.ietf.org/html/rfc6844 ↩︎
CAA Study : https://caastudy.github.io/ ↩︎
Measuring DANE TLSA Deployment : https://www.isi.edu/~liangzhu/presentation/dns-oarc/dane_tlsa_survey.pdf ↩︎
Baseline Requirements Documents : https://cabforum.org/baseline-requirements-documents/ ↩︎
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 : https://tools.ietf.org/html/rfc7208 ↩︎
DomainKeys Identified Mail (DKIM) Signatures : https://tools.ietf.org/html/rfc6376 ↩︎
NXDOMAIN : There Really Is Nothing Underneath : https://tools.ietf.org/html/rfc8020 ↩︎
Domain-based Message Authentication, Reporting, and Conformance (DMARC) : https://tools.ietf.org/html/rfc7489 ↩︎
Neither Snow Nor Rain Nor MITM… An Empirical Analysis of Email Delivery Security : https://static.googleusercontent.com/media/research.google.com/fr//pubs/archive/43962.pdf ↩︎ ↩︎ ↩︎ ↩︎
https://www.huque.com/bin/gen_tlsa ↩︎
Attribution 2.5 Generic : https://creativecommons.org/licenses/by/2.5/ ↩︎

Chiffrement de messagerie quasi instantanée : à quel protocole se vouer ?

Wed, 01 Mar 2017 00:00:00 +0000

Telegram, WhatsApp, Signal, OTR… et autant de protocoles de messagerie quasi instantanée, de modèles de sécurité et de protocoles cryptographiques : lesquels choisir ? Et si la solution idéale n’était pas dans la liste précédente ? Cet article évoque les limites de plusieurs de ces solutions, et présente le cœur cryptographique de Signal, WhatsApp et du protocole OMEMO. Il met finalement en exergue, par une analyse comparative, certaines limites de Signal et des qualités d’OMEMO.

Chiffrement des messages de bout en bout ou chiffrement du canal, qualité des algorithmes cryptographiques et de l’authentification des pairs, confidentialité persistante (PFS) ou non, fiabilité de l’équipement faisant tourner la solution, limitation de l’exposition des métadonnées, fuite du carnet d’adresses, localisation des serveurs, capacité à dénier l’envoi d’un message : des critères rarement considérés par les utilisateurs de messagerie. Leurs véritables critères de sélection sont souvent la taille du réseau social joignable, la facilité d’utilisation, l’accessibilité de la solution sur l’équipement de l’utilisateur ou encore la liste des services annexes. Un constat compréhensible, puisque la première liste est formée de critères abscons et rarement absolus, tandis que la seconde liste affecte l’usage quotidien.

Certains utilisateurs restent néanmoins soucieux de leur vie privée ou sont contraints par la nature de leurs activités en ligne à un niveau de sécurité plus élevé. Ils disposent alors d’une myriade d’options, dont Telegram, WhatsApp, Signal, ou Apple iMessage. Ils peuvent aussi se tourner vers des solutions de messagerie instantanées traditionnelles augmentées du protocole OTR ¹ ou encore des e-mails augmentés grâce à OpenPGP ².

Se pose alors la question de séparer le bon grain de l’ivraie ; une tâche qui est simplifiée par la forte concentration des applications autour des protocoles X3DH ³ et Double Ratchet ⁴. Ces deux protocoles, spécifiés récemment dans le domaine public par les auteurs de Signal, sont employés par plusieurs vendeurs, dont Signal et WhatsApp. En outre, la communauté de XMPP, un protocole de messagerie quasi instantanée, a également choisi X3DH+Double Ratchet, afin de remplacer leur usage d’OpenPGP et OTR.

La combinaison X3DH+Double Ratchet n’est cependant qu’une partie de la solution pour sécuriser les communications. Plus spécifiquement, ces protocoles permettent, respectivement, la négociation des clés et leur rafraîchissement. L’utilisation de ces clés, afin de créer des sessions cryptographiques entre les utilisateurs, est dévolue à d’autres composants : le protocole Signal, dans le cas de Signal et de WhatsApp, et le protocole OMEMO ⁵, dans le cas de XMPP.

X3DH+Double Ratchet, OMEMO et Signal sont étudiés dans la suite de cet article.

Pour le lecteur intéressé, la sécurité de Telegram a fait l’objet de discussions ⁶ et d’études ⁷ et l’université de Johns Hopkins a étudié celle d’Apple iMessage ⁸. WeChat ou encore Slack sont hors sujet, puisqu’ils ne proposent pas de chiffrement de bout en bout.

1. Les protocoles inadéquats pour la messagerie quasi instantanée

1.1. OpenPGP

OpenPGP est un format de stockage de messages et de clés cryptographiques, spécifié dans sa version la plus récente en 2007 ². Il est notamment employé pour sécuriser des messages électroniques. Ce format étant agnostique vis-à-vis de la nature des messages, il convient pour des réseaux de messagerie décentralisés ou lorsque le destinataire est hors-ligne (protocole non interactif). Il permet également d’assurer de la protection de bout en bout, puisque ce sont les messages qui sont chiffrés et non le canal de transport de ces derniers.

En outre, il est possible d’utiliser OpenPGP pour envoyer des messages à un groupe d’utilisateurs. Pour ce faire, la clé de chiffrement du message est chiffrée avec les clés publiques de chacun des destinataires. Les clés publiques ainsi utilisées doivent être préalablement créées, et stockées dans des certificats OpenPGP. Ces certificats permettent d’associer des identités — éventuellement des pseudonymes — à ces clés publiques. Ces certificats sont transmis ponctuellement aux autres utilisateurs grâce à des annuaires ou par une remise en main propre.

OpenPGP présente cependant des limites, en regard de solutions alternatives spécialisées pour le chiffrement de messagerie quasi instantanée. Ainsi, il n’offre pas, de manière inhérente, de confidentialité persistante du fait de la transmission ponctuelle des certificats : le rafraîchissement des clés est du ressort de l’utilisateur. En outre, pour la protection en intégrité des messages, l’utilisateur n’a le choix qu’entre des solutions imparfaites. L’une est sujette à des attaques par dégradation du niveau de sécurité (downgrade attack) ⁹ et l’autre use de signatures cryptographiques non répudiables, ce qui n’est pas toujours souhaitable.

1.2. Off-the-Record

Le protocole Off-the-Record a été spécifié, pour la première fois, en 2004 ; sa version la plus récente date de 2012. Ce mécanisme permet l’échange de clés et de messages sécurisés de bout en bout. L’établissement de la session protégée est effectué entre deux parties de manière interactive. Autrement dit, il est nécessaire que les participants soient en ligne simultanément pour l’établissement de cette session. Cette propriété exclut un usage asynchrone, et restreint donc ce protocole à la messagerie instantanée. Une variante, appelée mpOTR ¹⁰, permet d’échanger des messages au sein d’un groupe d’utilisateurs.

Avec OTR, les utilisateurs sont identifiés par des clés publiques à long terme. Les clés à long terme servent à signer/authentifier des échanges de clés Diffie-Hellman (DH) éphémères. Ces clés éphémères servent, à leur tour, à générer les clés protégeant les messages. Il convient de noter que les signatures émises par les clés à long terme affectent la vie privée ; elles constituent, en effet, une preuve non répudiable qu’une conversation a eu lieu entre deux parties, même si le contenu de la conversation reste inconnu d’un observateur.

Une fois la négociation de clés initiale accomplie, de nouvelles biclés DH sont introduites à chaque nouveau message. Cela permet ainsi de rafraîchir les secrets et d’apporter la confidentialité persistante. En effet, la compromission d’une clé privée DH n’affecte la confidentialité que d’un unique message ; de même, la compromission de la clé à long terme n’affecte que les futurs messages.

Le protocole Off-the-Record présente également une propriété de sécurité qui serait favorable à la vie privée. Ainsi, Off-the-Record permettrait à un expéditeur de dénier le contenu d’un message, tout en garantissant au destinataire la légitimité et l’intégrité du message reçu. Pour ce faire, les clés utilisées pour calculer des motifs d’intégrité de messages sont divulguées en clair après réception et vérification de ces messages. Conjuguée à un mode de chiffrement malléable et à un clair connu, cette méthode peut permettre à un observateur de forger un message chiffré et intègre arbitraire. Cet observateur serait cependant incapable de prouver à un tiers l’authenticité d’un message qu’il détient. L’efficacité de ce mécanisme fait néanmoins débat parmi les experts, car il n’a jamais été éprouvé dans le cadre d’un procès, afin de décrédibiliser une conversation enregistrée et utilisée comme preuve incriminante.

Malgré ses nombreux avantages, le protocole Off-the-Record, tel que spécifié dans sa version la plus récente (3.4), souffre d’un problème d’obsolescence cryptographique. En effet, l’absence d’un mécanisme de négociation des algorithmes fait d’Off-the-Record un musée des algorithmes cryptographiques des années 2000. Sont notamment employés l’algorithme de signature DSA, des empreintes cryptographiques avec SHA-1, ou encore des échanges DH sur corps entiers de 1536 bits avec un groupe fixé par la spécification. L’usage de cette cryptographie datée est contraire aux bonnes pratiques actuellement reconnues.

2. X3DH+Double Ratchet

Les protocoles X3DH et Double Ratchet ont été inventés par Trevor Perrin et Moxie Marlinspike. En 2013, il s’agissait, en fait, d’un seul et même protocole connu sous le nom d’Axolotl. Ce n’est qu’en 2016 qu’Axolotl fut divisé et que ses parties furent renommées afin de mettre fin à des confusions fréquentes entre Axolotl et le protocole Signal. Il faut dire que le protocole Signal, qui fait usage d’une variante d’Axolotl, n’a, à ce jour, jamais été spécifié ou documenté et que la frontière entre les deux protocoles était donc pour le moins floue. Les spécifications complètes de X3DH et Double Ratchet ont finalement été publiées en novembre 2016. Cette publication a également permis de mettre fin à de récurrentes menaces judiciaires que les auteurs de Signal ont pu proférer contre des vendeurs prétendant implémenter le protocole Signal, alors qu’ils utilisaient réellement Double Ratchet ¹¹.

X3DH est responsable de la négociation de clés cryptographiques. Celle-ci prend place lors d’une phase initiale. Les clés évoluent ensuite par dérivations, selon le protocole Double Ratchet. Ce dernier rafraîchit les clés à l’aide de cryptographie symétrique, ainsi que par l’apport régulier de nouveaux éléments secrets asymétriques.

Pour effectuer ces opérations sur les clés, les deux protocoles emploient de la cryptographie moderne : XEdDSA, une extension à EdDSA, sur les courbes elliptiques curve25519 ou curve448 ¹², SHA2 et HKDF ¹³.

2.1. X3DH

Chaque utilisateur du protocole X3DH doit générer et publier un ensemble de biclés cryptographiques. Ces clés doivent être compatibles avec les fonctions X25519 ou X448 de XEdDSA.

La première biclé est appelée clé à long terme. Elle sert dans le cadre d’échanges DH, mais elle est également employée pour signer d’autres biclés, appelées clés à moyen terme. Des biclés à usage supposément unique sont également générées en grande quantité ; Signal et Conversations en génèrent ainsi une centaine. Générer autant de clés à usage unique permet qu’un grand nombre de sessions puissent être établies avec la confidentialité persistante dès le premier message, et ce alors que le destinataire n’est pas en ligne.

La génération de ces trois types de biclés (à long et moyen termes et à usage unique) doit être répétée pour chacun des périphériques avec lesquels un utilisateur est susceptible d’accéder à ses messages. L’utilisateur disposant d’un PC, d’une tablette et d’un téléphone portable se retrouve ainsi rapidement avec plusieurs centaines de biclés associées à son identifiant. Seule la clé à long terme de chaque équipement nécessite cependant une vérification d’authenticité par les autres utilisateurs.

Ces biclés sont utilisées afin d’établir des sessions entre un expéditeur et l’ensemble des périphériques des destinataires. Ces périphériques peuvent être possédés par un même destinataire ou par plusieurs destinataires, dans le cadre d’une discussion de groupe. La liste des périphériques destinataires peut même contenir les équipements de l’expéditeur, afin de permettre la synchronisation des messages émis entre équipements.

Autant de sessions sont créées qu’il y a d’équipements destinataires. Cette étape n’a cependant besoin de se produire qu’une seule fois, lors de la première conversation entre deux périphériques. Ces sessions ont, en effet, une durée de vie illimitée.

Pour établir une session, la première étape consiste à récupérer les clés publiques des périphériques destinataires. La manière dont elles sont publiées et récupérées est laissée ici volontairement abstraite ; elle varie d’une implémentation à l’autre, comme le détaillera la section 3 de cet article.

Une fois les clés publiques des destinataires en possession de l’expéditeur, ce dernier effectue les mêmes étapes avec les clés de chaque périphérique pour lequel une session doit être établie. La première étape consiste à générer une nouvelle biclé DH éphémère. Trois à quatre échanges DH sont ensuite effectués, entre les clés de l’équipement expéditeur et celles de l’équipement destinataire. L’appariement des clés publiques DH est détaillé dans la figure 1.

Fig. 1 : Illustration des échanges de clés DH effectués dans le cadre de X3DH. Le trait en pointillé représente un échange optionnel, qui n’a lieu que si une clé à usage unique est disponible pour l’équipement destinataire.

La variabilité du nombre d’échanges DH résulte de la capacité à récupérer une des clés à usage unique pour l’équipement destinataire. Certains dépôts de clés tiennent, en effet, une comptabilité afin d’assurer qu’une clé à usage unique n’est bien distribuée qu’une seule fois. Si toutes les clés ont été distribuées, aucune n’est fournie à l’expéditeur et seuls trois échanges DH sont opérés. Ceci peut affecter la confidentialité persistante, car le destinataire ne fournit alors que des clés qui sont partagées entre plusieurs sessions. Dans la section 2.2 traitant de Double Ratchet, il sera détaillé comment cette faiblesse est cicatrisée dès la réception d’un message de la part de l’équipement destinataire.

L’ensemble des secrets résultant des échanges DH est ensuite concaténé et passé à travers la fonction HKDF pour former une valeur secrète, appelée secret racine de la session.

Cet échange de clés a la particularité de négocier un secret tout en préservant la capacité des deux parties de nier avoir tenu une conversation ensemble. Cette propriété est dérivée de l’hypothèse de difficulté calculatoire de DH (Computational DH Assumption). La signature XEdDSA des clés à moyen terme, qui elle est non répudiable, ne prévient pas cette propriété puisqu’elle est totalement décorrélée de l’échange de clés et n’intervient que pour « certifier » la clé à moyen terme.

2.2. Double Ratchet

Double Ratchet repose sur deux mécanismes de rafraîchissement des clés. Ces deux mécanismes confèrent son nom à cet algorithme, puisqu’ils utilisent tous deux, à l’instar d’une roue à rochet, des fonctions cryptographiques à sens unique pour faire « évoluer » des secrets.

Le premier, représenté sur fond jaune dans la figure 2, utilise exclusivement la cryptographie symétrique. Il permet de générer les clés secrètes protégeant les messages. Avec ce mécanisme, chaque message bénéficie d’une clé secrète à usage unique. Cette clé de protection d’un message est obtenue par dérivation d’une clé, tirée d’un ensemble appelé chaîne de clés. Cette chaîne est formée par des dérivations successives de secrets. Le secret initial de cette chaîne est le secret racine actuel. La notion d’actualité du secret racine provient du second mécanisme de rafraîchissement des clés.

Ce second mécanisme, représenté sur fond vert dans la figure 2, utilise de la cryptographie asymétrique. Il vise à faire évoluer la clé racine qui a été négociée initialement, par exemple avec X3DH. Avec ce mécanisme, une nouvelle biclé DH est tirée aléatoirement chaque fois qu’un périphérique s’apprête à envoyer un message consécutif à la réception d’un message par un autre périphérique. La clé publique de cette nouvelle biclé DH est jointe à l’ensemble des messages envoyés par ce périphérique jusqu’à la réception d’un message de la part d’un autre périphérique. Cette gymnastique est représentée dans la figure 3.

La nouvelle clé DH fraîchement tirée est utilisée dans un échange DH en conjonction avec les clés publiques les plus récentes reçues dans des messages émis par les autres périphériques. Le résultat de cet échange est ensuite « mélangé » avec le secret racine actuel à l’aide de la fonction HKDF. Le résultat de cette opération devient le nouveau secret racine actuel.

Fig. 2 : Illustration de l’algorithme Double Ratchet. Les clés composant la chaîne de clés sont représentées dans des diamants. Les clés de messages sont représentées dans des ellipses. Les algorithmes sont dessinés dans des boîtes roses aux bords arrondis. Les composants sur fond vert représentent la roue à rochet asymétrique. Les composants sur fond jaune représentent la roue à rochet symétrique.

Fig. 3 : Illustration d’un enchaînement de messages avec un protocole de messagerie employant Double Ratchet. De nouvelles clés asymétriques sont générées juste avant l’envoi d’un message faisant suite à une réponse. Cette clé asymétrique est répétée dans tous les messages suivants.

L’utilisation de ces deux mécanismes de rafraîchissement de clés permet de bénéficier de clés secrètes uniques pour chaque message envoyé, y compris lorsqu’un des participants se lance dans un monologue de plusieurs messages. La compromission d’une clé symétrique ne mène alors qu’à la compromission d’un seul message. La réception d’un message de la part de l’autre participant permet ensuite de rafraîchir le secret racine. Ceci permet ainsi de prévenir la compromission de plus d’un monologue en cas de compromission d’une clé asymétrique.

Outre ces propriétés, les protocoles de messageries sécurisées reposant sur Double Ratchet peuvent également se montrer tolérants vis-à-vis de la perte de messages ou de la livraison de messages dans le désordre. Il suffit à ces applications de conserver les différentes chaînes de clés, et de « sauter » les messages encore non reçus, en appliquant plusieurs fois de suite la fonction HMAC-SHA256 avec la « constante 2 » de la figure 2. Il convient néanmoins de noter que conserver ainsi les clés, au lieu de les supprimer dès que possible, peut mettre en péril la confidentialité persistante, en cas de compromission d’un équipement.

2.3. Intégration de X3DH+Double Ratchet dans OMEMO

La première version d’OMEMO a été spécifiée par Andreas Straub en 2015, avec l’aide de Daniel Gultsch, développeur principal du client XMPP Conversations. En décembre 2016, OMEMO a été officiellement acceptée comme extension expérimentale du protocole XMPP (XEP-0384).

Avec XMPP, chaque utilisateur est identifié par un JID. Il s’agit d’un identifiant qui ressemble fort à une adresse e-mail, mais il est suivi d’une barre oblique (slash) et du nom d’un équipement ou d’un logiciel. florian@im.x-cli.eu/phone est, par exemple, le JID de l’auteur de cet article lorsqu’il est connecté avec son téléphone. À l’instar des adresses e-mail, la partie précédant l’arobase désigne un utilisateur local, tandis que la partie suivant l’arobase et jusqu’à la barre oblique désigne le serveur sur lequel est hébergé cet utilisateur. XMPP est donc un système fédéré, où chaque utilisateur choisit son fournisseur de service.

Les messages à destination d’un utilisateur, désigné par son bare JID (c.-à-d. son JID sans le nom de l’équipement), sont délivrés au dernier périphérique actif de cet utilisateur. Ce fonctionnement peut être altéré grâce aux extensions Carbon Messages (XEP-0280) et Message Archive Management (XEP-0313) afin que tous les équipements d’un utilisateur aient accès à tous les messages reçus. En outre, si un utilisateur est hors-ligne, ses messages peuvent être stockés sur le serveur responsable du compte de l’utilisateur. Ces messages lui seront alors délivrés lors de sa prochaine connexion. Par ailleurs, des informations relatives à un utilisateur peuvent être stockées, en clair, sur le serveur responsable de son compte, grâce à l’extension XMPP XEP-0163, appelée Personal Eventing Protocol (PEP). Ce mécanisme, lui-même extensible, permet ainsi à un utilisateur connecté ou hors-ligne de mettre à la disposition d’autres utilisateurs diverses informations comme son avatar, son dernier message de statut, ou encore sa « carte de visite ».

OMEMO utilise ces différentes extensions XMPP pour offrir une méthode de chiffrement de bout en bout à l’ergonomie moderne. Chaque équipement, lorsqu’il active OMEMO, génère sa clé à long terme, sa clé à moyen terme et d’une vingtaine à une centaine de clés à usage « unique ». Les jeux de clés de chaque équipement sont stockés dans le profil PEP utilisateur. Lorsqu’un expéditeur souhaite établir une nouvelle session, il récupère toutes les clés auprès du serveur responsable du compte du destinataire. Ensuite, il effectue un échange de clés en suivant le protocole X3DH. Par équipement avec lequel une session doit être établie, il sélectionne aléatoirement une clé à « usage unique ». Cette sélection aléatoire permet de s’affranchir du risque qu’un serveur malveillant dégrade la confidentialité persistante en diffusant sciemment une clé à usage unique déjà employée par ailleurs. Le risque de dégradation de la confidentialité persistante n’est cependant pas totalement évité. Il est, en effet, possible que plusieurs sessions soient établies pendant qu’un périphérique est hors-ligne, et que la sélection aléatoire provoque une collision. Plus un périphérique tarde à remplacer les clés utilisées, et plus le risque de collision grandit. Cette collision a une portée limitée puisqu’elle n’a un impact que sur tout ou partie du premier monologue d’un utilisateur. Si l’équipement, dont l’une des clés à usage unique a été réutilisée, se connecte et détecte cette situation, il est alors en mesure de rétablir la confidentialité persistante. Il lui suffit d’envoyer un message « de service » dont le seul objet est de rafraîchir le secret racine. Cette situation semble, dans tous les cas, préférable à l’absence totale du quatrième échange DH.

3. Des divergences entre Signal et le protocole OMEMO

Signal et le protocole OMEMO sont par certains aspects très similaires. Certaines implémentations d’OMEMO utilisent, en effet, la bibliothèque cryptographique libsignal ¹⁴ d’Open Whisper Systems, la société éditrice de Signal. Ses usages sont cependant cantonnés aux échanges de clés X3DH et à la maintenance des secrets avec Double Ratchet. Les points de divergences entre Signal et les implémentations d’OMEMO se situent donc sur les points suivants : les identifiants et l’architecture réseau, l’infrastructure de gestions de clés, l’usage qui est fait de ces clés, l’existence de documentation de qualité et la capacité à auditer le protocole.

3.1. Les identifiants et l’infrastructure réseau

Alors qu’OMEMO utilise une infrastructure répartie, où chaque utilisateur choisit son fournisseur de services, grâce au réseau fédéré XMPP, Signal préfère une infrastructure centralisée. Les auteurs de Signal ont, en effet, exprimé une opinion très négative sur les notions de fédération et d’interopérabilité, les qualifiant de causes génératrices de l’ossification des protocoles ¹⁵. Au diable donc l’Internet ouvert, le succès de HTTP ou encore celui des courriers électroniques. Moxie Marlinspike a même demandé à des clones (fork) de Signal de ne pas employer les serveurs opérés par Open Whisper Systems, quand bien même le protocole employé était le même ¹⁶. Signal est donc un système clos ; la porte de la fédération a été fermée à clé, clé qui est maintenant au fond d’un lac.

Signal utilise les numéros de téléphone des utilisateurs comme identifiants. Cette pratique a certainement pour origine l’usage des SMS/MMS comme première méthode de transport des messages de Signal. En 2015, les développeurs ont cependant décidé arbitrairement d’arrêter de prendre en charge le transport par SMS/MMS, et d’utiliser, à la place, exclusivement les serveurs d’Open Whisper Systems, situés aux États-Unis. Cette décision a fait réagir une fraction de la communauté qui a créé un clone de l’application, désormais appelé Silence ¹⁷.

Le choix d’Open Whisper Systems d’arrêter la prise en charge des SMS/MMS n’a cependant pas causé l’arrêt de l’usage des numéros de téléphone comme identifiants. Il en résulte un problème de vie privée, dû au fait que les métadonnées relatives aux expéditeurs et destinataires ne sont pas chiffrées par le protocole Signal. En effet, ces identifiants pourraient permettre aux opérateurs d’Open Whisper Systems de tracer le graphe social des utilisateurs, ou encore de les géolocaliser, grâce au réseau SS7 ¹⁸.

Le choix des numéros de téléphone comme identifiant est également fortement discutable depuis la publication de Signal Desktop. Ce logiciel permet aux utilisateurs de converser depuis des PC avec les utilisateurs Signal ; il n’est cependant pas possible d’employer ce logiciel sans s’être enrôlé préalablement sur téléphone portable !

Pour finir, cette centralisation du service présente également des risques topologiques. En effet, la géolocalisation aux États-Unis de la société Open Whisper Systems et de ses serveurs signifie qu’elle est soumise à l’arsenal légal américain. Celui-ci a d’ailleurs déjà été mis en œuvre à l’encontre de Signal ¹⁹. En outre, la centralisation facilite la censure administrative du service, comme cela s’est déjà produit plusieurs fois au Brésil pour WhatsApp ²⁰, et en Égypte pour Signal ²¹. Une technique expérimentale ²², inspirée du module meek pour Tor et appelée Domain Fronting, a été déployée en réponse à ce dernier blocage. Son déploiement hâtif laisse cependant en suspens des questions de vie privée, de confidentialité et d’intégrité, eu égard à l’absence de protection de bout en bout de certaines (méta-)données transitant par Google AppEngine lors du Domain Fronting.

En comparaison, les JID de XMPP/OMEMO peuvent être des pseudonymes n’offrant aucune corrélation avec un utilisateur particulier. Les utilisateurs les plus prudents peuvent même se connecter à XMPP au travers de Tor, ou utiliser des hidden services XMPP sur Tor. En outre, les identifiants ne sont pas liés à un type d’équipements. Ils peuvent ainsi être utilisés sur PC ou téléphone exclusivement ou sur un mélange des deux. Finalement, pour la géolocalisation des serveurs, l’infrastructure répartie de XMPP permet de jongler à volonté avec la localisation administrative et juridique des serveurs.

3.2. L’infrastructure de gestion de clés

Les serveurs gérés par Open Whisper Systems sont responsables du stockage des clés publiques de tous les utilisateurs, et de distribuer ces clés aux nouveaux utilisateurs. Ainsi, lorsqu’un nouvel utilisateur installe Signal, le logiciel prélève les numéros de téléphone de l’intégralité du carnet d’adresses de l’utilisateur, et les envoie aux serveurs de Signal, qui retournent en échange les clés des utilisateurs connus ²³. Les utilisateurs figurant dans le carnet de contacts sont également notifiés qu’un de leurs contacts vient d’installer Signal.

En vue de protéger la vie privée des utilisateurs, les numéros de téléphone des contacts sont hachés avec une fonction cryptographique et le résultat est tronqué ; cette technique s’avère cependant insuffisante et une recherche exhaustive permet de recouvrer ces numéros de téléphone.

Pour chaque utilisateur du carnet d’adresses ayant Signal, les serveurs d’Open Whisper Systems retournent donc une clé à long terme, une clé à moyen terme et optionnellement une clé à usage unique. Cette méthode de distribution centralisée des clés exige de faire confiance aux serveurs. Ces derniers peuvent, en effet, dégrader sciemment la confidentialité persistante en ne retournant pas de clé à usage unique. Ils peuvent, en outre, tout simplement fournir de fausses clés, en vue d’effectuer une interception de messages. Cette éventualité peut être contrée si les utilisateurs effectuent une vérification des clés retournées et les valident. L’usage des clés préalable à cette vérification n’est cependant pas empêché, et nombre d’utilisateurs font donc probablement une confiance aveugle aux serveurs de Signal.

Les utilisateurs méfiants qui voudraient effectuer cette vérification ne sont malheureusement pas dotés d’outils adaptés. Ainsi, s’il était auparavant possible de vérifier la clé du destinataire d’un message, les développeurs de Signal ont dégradé cette possibilité en novembre 2016. Au nom d’études sur l’expérience utilisateur, ils ont ainsi remplacé la vérification d’empreintes cryptographiques des clés par la comparaison de « nombres de sûretés » (safety number) ²⁴, supposément plus faciles à comparer. Cette opération a ainsi réduit la sécurité de l’empreinte de 256 bits à 100 bits. Plus incompréhensible encore, l’empreinte a également été réduite dans le QRCode utilisé pour la comparaison des clés, alors qu’il ne peut y avoir d’impact sur l’expérience utilisateur, que l’on photographie un QRCode de 100 ou 256 bits de sécurité ! Pour finir, la vérification des empreintes est impossible lors d’une conversation de groupe ²⁵.

Pour enfoncer le dernier clou, Signal envisage de réviser à la baisse son mécanisme de sécurité concernant le signalement d’un changement de clés d’un pair ²⁴. Auparavant, lorsqu’un utilisateur changeait de clé à long terme (une opération rarissime), une notification était affichée et une confirmation manuelle était exigée. Avec la nouvelle option, dont il est envisagé qu’elle soit activée par défaut, seule une petite ligne sera affichée au milieu de la conversation.

En comparaison, les clés OMEMO sont récupérées auprès d’un serveur au choix du destinataire. Avec le logiciel Conversations, par défaut depuis la version 1.15 de novembre 2016, les clés peuvent être employées sans avoir été vérifiées ; un indicateur visuel différencie cependant les échanges avec les clés vérifiées et les échanges sans vérification ²⁶. De plus, dès qu’une première clé d’un utilisateur est vérifiée, seules ses clés vérifiées sont utilisables. Dans le cas où plusieurs périphériques seraient destinataires, chaque clé doit être individuellement validée au premier usage, à l’aide d’une empreinte cryptographique de 256 bits. Il existe un risque d’utiliser plusieurs fois une clé à usage unique, mais le protocole prévoit une contre-mesure pour raccourcir la durée de l’incident.

3.3. Usage des clés symétriques

Signal chiffre les messages à l’aide d’AES256 en mode CBC et ses motifs d’intégrité sont calculés avec HMAC-SHA256 dont le résultat est tronqué à 64 bits.

Ces choix peuvent faire débat. Ainsi, bien que Signal use d’une composition chiffrement/intégrité satisfaisante (Encrypt-then-Mac), l’implémentation incorrecte du mode CBC s’est révélée à l’origine de nombreuses vulnérabilités au fil des années. Cela a été notamment le cas dans TLS. En conséquence, l’existence de meilleures alternatives, tant en performances qu’en sécurité, a valu à ce mode d’être déconseillé par les auteurs du RFC de HTTP/2 ²⁷. La prochaine version de TLS ne la prend même tout simplement pas en charge ²⁸.

En outre, si l’algorithme HMAC-SHA256 est, à ce jour, irréprochable, la troncature du motif d’intégrité à 64 bits affaiblit son efficacité de manière significative. Ce choix tient peut-être sa justification dans l’usage des SMS comme méthode originelle de transport des messages. À l’heure actuelle, tous les messages de Signal sont notifiés à l’aide de Firebase Cloud Messaging (anciennement Google Cloud Messaging), et transportés sur le canal de données des téléphones portables. Les problèmes de bande passante utile ne peuvent donc plus constituer une justification. En fait, la grande bande passante désormais disponible joue même à l’encontre de cette troncature, rendant plus facile le bombardement de messages frauduleux jusqu’à réussir à forger un motif correct.

En comparaison, OMEMO emploie AES256 avec le mode de chiffrement authentifié GCM, considéré à l’état de l’art.

3.4. Documentation et audits

Signal est une cible mouvante. Jusqu’alors dénué de documentation, par une volonté affichée de ses développeurs, ce n’est que sur la pression croissante de la communauté que les algorithmes XEdDSA, X3DH et Double Ratchet ont été finalement spécifiés et publiés dans le domaine public. Si des études formelles vont désormais pouvoir être menées sur ces trois protocoles, effectuer ce même type d’études sur le protocole Signal reste encore un défi. Quelques-uns s’y sont néanmoins essayés, documentant leurs découvertes du protocole par « ingénierie inverse du code source », afin de dégager des propriétés de sécurité ²⁹ ³⁰. Aucune attaque réellement significative n’a été découverte, à ce jour.

En comparaison, le protocole OMEMO est documenté et standardisé dans une extension expérimentale du protocole XMPP. Il a récemment subi un audit, ayant révélé divers points d’attention ³¹, qui ont été rapidement pris en compte par le protocole et au moins certaines implémentations.

4. Conclusion

Cet article a détaillé les atouts et inconvénients de plusieurs protocoles permettant la sécurisation de messageries quasi instantanées. La figure 4 reprend les observations de manière synthétique.

Fig. 4 : Synthèse des points forts et faibles de plusieurs protocoles dans le cadre de la messagerie (quasi) instantanée. Les justifications ou références ont été apportées dans l’article.

Les utilisateurs souhaitant protéger leur messagerie quasi instantanée de bout en bout disposent d’options valables, comme Signal, WhatsApp, ou encore OMEMO. Ces outils ont en commun un cœur cryptographique formé des protocoles X3DH et Double Ratchet, dont il ressort de plusieurs études indépendantes qu’ils seraient fiables.

Malgré cela, ces différentes solutions offrent un niveau de protection de la vie privée et de la confidentialité des messages qui varie de manière significative. Ainsi, cet article a rappelé, à l’instar d’une conférence lors de la conférence 33c3 ³², que les numéros de téléphone sont à la fois des identifiants de compte pratiques, puisque déjà enregistrés dans le téléphone, mais aussi une donnée personnelle sensible. Outre leur usage éventuel pour géolocaliser des utilisateurs, ils sont nécessairement transmis en clair, en tant que métadonnées de tout message : une situation préoccupante lorsque les messages du réseau doivent passer par une infrastructure centralisée. Cette dernière est, en effet, en mesure d’observer le graphe social de ses utilisateurs et la fréquence de leurs échanges, quand bien même leurs concepteurs s’en défendent ¹⁹. Par ailleurs, comme cet article l’a présenté, les serveurs de Signal et WhatsApp sont en charge de la délivrance des clés publiques des contacts d’un utilisateur. Pour cela, un dérivé cryptographique des numéros de tous les contacts d’un utilisateur est envoyé aux serveurs, qui répondent avec des clés publiques associées. Cette dérivation cryptographique est hélas aisément réversible ²³, et il est possible de retrouver la liste des contacts d’un utilisateur de ces applications. En outre, il est à la charge des utilisateurs de vérifier l’authenticité des clés remises par les serveurs, une étape probablement rarement effectuée et dont les mécanismes de vérification ont été récemment dégradés dans Signal, parfois de façon inexplicable ²⁴. Pour WhatsApp, ce mécanisme de distribution de clés a même été à l’origine d’un tumulte, en janvier 2017, lorsque le journal Guardian a rapporté qu’une vulnérabilité publique depuis huit mois et non corrigée permet l’interception de messages en clair ³³.

Finalement, cet article a détaillé le protocole OMEMO, qui utilise le réseau XMPP pour la distribution des clés et des messages. Le réseau XMPP utilise des serveurs répartis et des identifiants indépendants de l’identité propre de l’utilisateur. Chaque utilisateur de XMPP est libre d’employer le serveur de son choix, dont la sécurité peut être catastrophique ou excellente. Une sécurité serveur excellente n’exempte cependant pas les utilisateurs de la nécessité de vérifier les clés cryptographiques.

Heureusement, grâce à la publication récente dans le domaine public des spécifications de X3DH et de Double Ratchet par les auteurs de Signal, de nombreuses applications peuvent s’équiper de ce cœur cryptographique robuste tout en faisant des choix d’infrastructures plus respectueux de la vie privée que ne le sont Signal ou WhatsApp.

Les arguments de l’éditeur de Signal concernant l’agilité d’un écosystème fermé, soumis aux décisions unilatérales des développeurs, sont certainement fondés. À l’instar du régime politique démocratique, les réseaux fédérés, comme XMPP, nécessitent des négociations, des ententes et des compromis. Le résultat peut cependant, au long cours, se montrer supérieur à la somme des idées exprimées par les différents intervenants de l’écosystème.

Ainsi, grâce la stabilité de sa spécification, sa licence ouverte, ses primitives cryptographiques à l’état de l’art et son architecture répartie, OMEMO offre aux utilisateurs de XMPP une méthode de communication protégée de bout en bout efficace, auditable, et potentiellement durable.

Pour le lecteur intéressé, l’application libre Conversations implémente OMEMO et des extensions permettant l’économie de la batterie du périphérique le faisant tourner ³⁴. Un compte est optionnellement fourni à tout utilisateur faisant l’acquisition de l’application au travers du Google Play Store. Les utilisateurs d’iOS peuvent utiliser ChatSecure ³⁵. Les utilisateurs PC peuvent, quant à eux, se tourner vers Gajim et son implémentation expérimentale d’OMEMO. Pour les utilisateurs souhaitant effectuer un auto-hébergement de leur serveur XMPP, Prosody ³⁶ implémente la partie serveur des optimisations permettant des économies de batterie. Enfin, la Quadrature du Net fournit un service XMPP ouvert à tous ³⁷.

5. Remerciements

Je tiens à remercier mes relecteurs : Piotr Chmielnicki, François Contat, Arnaud Ebalard, Sarah De Haro, Olivier Levillain, Mickaël Salaün, et Guillaume Valadon. Les idées exprimées dans cet article ne sauraient les engager.

6. Réferences

Publié par les Editions Diamond sous licence CC-BY-NC-ND.