L’inutilité des lampes à lave : ce que signifie réellement le hasard

 (loup-vaillant.fr)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • La promotion par Cloudflare de nombres aléatoires fondés sur des lampes à lave relève davantage du marketing et du théâtre de sécurité que d’une contribution concrète majeure au chiffrement de l’Internet
  • En cryptographie, l’important n’est pas tant la nature intrinsèquement aléatoire d’une valeur que ce qu’un attaquant sait de cette valeur ; c’est cet écart de connaissance qui détermine la sécurité
  • Le one-time pad masque l’information du message original si une clé suffisamment aléatoire n’est utilisée qu’une seule fois, mais il se brise si la même clé est réutilisée, car elle se combine alors avec les informations déjà observées
  • Les systèmes modernes utilisent des CSPRNG et des chiffrements par flot à la place des masques jetables ; ChaCha20 ou AES-256-CTR offrent une sécurité pratique avec une clé de 256 bits
  • Les vrais RNG physiques sont difficiles à débarrasser de leurs biais et n’apportent qu’un faible gain de sécurité ; une conception plus simple où le serveur génère lui-même sa graine et utilise le fast key erasure est plus sûre

Le hasard dépend davantage de la connaissance de l’observateur que de l’objet

  • Cloudflare affirme que les lampes à lave contribuent au chiffrement de l’Internet, mais cette approche relève surtout du marketing et du théâtre de sécurité plus que d’un apport majeur à la sécurité
  • Outre les lampes à lave, Cloudflare utilise aussi des dispositifs physiques d’imprévisibilité comme des double pendulums, le mouvement des vagues ou des mobiles
  • Une fonction à la XKCD qui ne fait que return 4 renvoie toujours 4 et n’est donc pas aléatoire en elle-même ; mais si l’appelant sait seulement qu’il s’agit d’une « constante choisie avec un dé honnête » et ne l’appelle qu’une fois, elle peut être traitée comme aléatoire du point de vue de la distribution de probabilité de l’observateur
  • En cryptographie, la vraie question n’est pas de savoir si le résultat est intrinsèquement aléatoire, mais ce qu’un attaquant sait de ce résultat
  • Une même valeur peut avoir un sens différent selon qui possède quelle information ; dans un système cryptographique, c’est cet écart de connaissance qui détermine la sécurité

Comment le one-time pad fonctionne… et échoue

  • Dans l’analogie avec la roulette russe, le complice connaît la position de la balle et n’annonce à l’extérieur que le résultat de l’addition entre cette position et la valeur d’un dé partagé à l’avance avec le joueur
  • Le joueur peut reconstituer la position de la balle en soustrayant la valeur du dé au nombre annoncé, mais l’adversaire, qui ignore cette valeur, ne peut pas déduire la position de la balle à partir du seul nombre entendu
  • Avec un dé honnête, la probabilité a priori P(Ci) que possède l’adversaire est égale à la probabilité a posteriori P(Ci|S3) après avoir entendu un nombre précis S3
  • Avec la formule de Bayes, on obtient P(Ci|S3) = P(Ci) × 1/6 ÷ 1/6 = P(Ci) ; autrement dit, l’adversaire n’apprend absolument rien en entendant la valeur annoncée
  • C’est le cœur du one-time pad : si une clé suffisamment aléatoire n’est combinée qu’une seule fois avec le message, le texte chiffré ne révèle rien sur le texte en clair
  • Si la même clé est réutilisée pour une seconde partie, les informations révélées lors de la première permettent à l’adversaire de réduire l’éventail des valeurs possibles du dé
  • Si l’on a déjà confirmé que les quatre premières chambres du revolver sont vides lors de la première partie, l’adversaire sait qu’il ne reste que les possibilités correspondant à 3 ou 4 pour le dé ; si, à la seconde partie, le complice annonce « Four », l’adversaire apprend en plus que la balle est soit dans la première chambre, soit dans la dernière
  • Le one-time pad n’est sûr qu’une seule fois, comme son nom l’indique ; dès qu’on réutilise la même clé, les textes chiffrés observés se combinent aux informations précédentes et la sécurité s’effondre

Longueur de clé et sécurité pratique du chiffrement moderne

  • Sur Internet, on envoie des bits et des octets plutôt que des positions de balle ; un message binaire « yes/no » peut être masqué par un seul lancer de pièce
  • Si c’est face, on laisse le message tel quel ; si c’est pile, on inverse « yes » et « no », ce qui masque le texte en clair pour un observateur qui ignore le résultat du lancer
  • Mais si l’on chiffre deux bits avec le même lancer de pièce, le texte chiffré réduit les quatre textes en clair possibles à deux
    • « Yes yes » signifie que le texte en clair était soit « yes yes », soit « no no »
    • « No no » signifie que le texte en clair était soit « no no », soit « yes yes »
    • « Yes no » signifie que le texte en clair était soit « yes no », soit « no yes »
    • « No yes » signifie que le texte en clair était soit « no yes », soit « yes no »
  • De manière générale, si l’on chiffre n bits avec un seul lancer de pièce, l’espace des messages possibles est réduit de 2^n à 2 possibilités
  • Pour chiffrer correctement n bits au sens informationnel strict, il faut une clé de n bits ; pour un message plus long, une partie peut être déchiffrée, et si l’observateur connaît déjà plus de n bits d’information, l’ensemble peut généralement être reconstitué
  • Appliquer un one-time pad à tout le trafic traité par Cloudflare exigerait une quantité astronomique de nombres aléatoires, mais les systèmes modernes n’utilisent pas de one-time pad
  • Avec un chiffrement authentifié et des chiffrements par flot correctement employés, une clé de 256 bits permet de chiffrer de grandes quantités de données de manière pratiquement sûre
  • Avec des chiffrements par flot adaptés comme ChaCha20 ou AES-256-CTR, un observateur passif doit essayer environ 2^255 combinaisons pour retrouver le texte en clair
  • Pour quelqu’un qui connaît la clé, le flot est entièrement prévisible ; mais pour un observateur à l’échelle de la civilisation terrestre qui ne connaît pas la clé, il se comporte comme une « entropie » totalement imprévisible
  • Le nom officiel de cette approche est Cryptographically Secure Pseudo-Random Number Generator, abrégé en CSPRNG

Génération réelle de nombres aléatoires et fast key erasure

  • Pour dériver tous les nombres aléatoires nécessaires à partir d’une clé maître de 256 bits, on peut stocker cette clé maître dans un serveur maître ou un module matériel de sécurité, générer un flot de clés local et le distribuer de manière sûre à toute l’entreprise
  • Chaque serveur ou cœur CPU peut générer autant d’octets aléatoires que nécessaire à partir d’une clé locale de 256 bits et d’un compteur
  • Le problème central est que la distribution sécurisée est extrêmement difficile
  • Si une clé locale fuit, tous les messages passés chiffrés par cette machine ainsi que ceux qu’elle chiffrera à l’avenir sont menacés ; si la clé maître fuit, les conséquences sont bien plus graves
  • Le fast key erasure est une procédure conçue pour réduire à la fois la probabilité de fuite de clé et l’impact d’une telle fuite
    • On place une graine aléatoire de 32 octets au début d’un tampon de 512 octets
    • On génère 512 octets à partir de cette graine pour écraser le tampon
    • On produit ensuite, à la demande, tout ce qui suit les 32 premiers octets avant de l’effacer
    • Quand le tampon est épuisé, on revient à l’étape de génération
  • Le terme « erasure » vient du fait que l’étape de génération efface la clé précédente
  • Si le tampon fuit, les messages futurs peuvent être compromis, mais les valeurs passées déjà produites puis effacées restent protégées
  • Plus important encore : il ne faut pas dupliquer le tampon
    • Il ne faut pas créer deux flots à partir de la même graine
    • Lors d’un fork de processus, il faut séparer correctement le flot en deux
  • Si plusieurs instances du même flot existent, les mêmes octets aléatoires seront répétés, ce qui peut être catastrophique
  • C’est pourquoi les RNG en espace utilisateur sont déconseillés ; les RNG du noyau ne sont pas simples non plus, mais il y a moins d’éléments à auditer

Choix du chiffrement par flot et marge de sécurité

  • La taille de bloc interne du chiffrement par flot sous-jacent est également importante
  • Le bloc de 512 bits de ChaCha20 est suffisamment grand pour ne pas poser de souci, et le bloc de 128 bits d’AES est lui aussi assez grand
  • Il existe contre AES des attaques réalistes bien plus efficaces qu’une simple recherche exhaustive ; on peut considérer qu’AES-128 peut être cassé, alors qu’AES-256 est considéré comme sûr
  • Une taille de bloc plus petite doit être considérée comme cassée pour cet usage
  • Les choix recommandés sont ChaCha20 ou AES-256, avec une préférence pour ChaCha20
  • Les chiffrements par flot modernes sont très sûrs et, au vu de la littérature académique ainsi que des usages de plusieurs gouvernements, notamment celui des États-Unis, il paraît très peu probable qu’ils soient cassés dans un futur proche
  • Comme le CSPRNG et le chiffrement dépendent tous deux de la cryptographie, si l’un des deux est cassé, l’ensemble du système l’est aussi
  • Si l’on suppose qu’il existe une probabilité non négligeable qu’AES-256 ou ChaCha20 soient cassés dans un avenir proche, il existe des moyens d’augmenter la marge de sécurité
    • Utiliser le même chiffrement à la fois pour le CSPRNG et pour le chiffrement évite de laisser à l’attaquant le choix de casser AES ou ChaCha ; il doit alors casser un algorithme précis
    • Augmenter le nombre de rounds aide non seulement contre la recherche exhaustive, mais aussi contre les attaques meilleures qu’une simple recherche exhaustive
    • AES-256 utilise 14 rounds, ChaCha20 en utilise 20
    • Il existe contre ChaCha7 des attaques meilleures qu’une recherche exhaustive, mais pas actuellement contre ChaCha8
    • ChaCha20 utilise 20 rounds afin de garder une marge suffisante même si une attaque à 12 rounds était soudainement découverte
  • Les approches qui combinent plusieurs systèmes en parallèle augmentent fortement la complexité globale, et cette complexité a davantage de chances d’introduire une faille fatale qu’une attaque mathématique contre l’un des composants

Vrais RNG physiques et graine initiale

  • Il faut se méfier de l’idée selon laquelle un vrai RNG physique serait automatiquement plus sûr qu’un CSPRNG, simplement parce que ce dernier pourrait théoriquement être cassé
  • Pour des raisons de sécurité, la sortie aléatoire doit souvent être exempte de biais détectables, c’est-à-dire suivre une distribution suffisamment uniforme pour qu’aucun biais ne soit détectable même après l’analyse de 2^64 échantillons
  • Il est difficile d’ajuster un processus physique à ce niveau de précision ; en pratique, il faut donc souvent faire passer la sortie d’une source de bruit dans une fonction de hachage cryptographique
  • Comparé à un chiffrement par flot utilisant le fast key erasure, le gain de sécurité est faible, tandis que le coût en performance peut être important selon les besoins
  • Pour produire une quantité arbitraire de nombres aléatoires, il faut une graine initiale de quelques octets
  • On peut enregistrer numériquement une source imprévisible pendant assez longtemps pour obtenir plus de 256 bits d’entropie, puis hacher cet enregistrement avec un hachage 256 bits comme SHA-256 ou BLAKE2s afin de produire la graine maître
  • Les sources possibles de hasard sont notamment les hardware random number generators, le jitter CPU, une photo aléatoire d’arbre, un beam splitter, les frappes clavier ou événements souris, des dés, etc.
  • La distribution de nombres aléatoires entre sites n’est pas pratique ; elle ajoute de la complexité et peut elle-même devenir une cause de compromission
  • Les nombres aléatoires ne sont pas nécessaires une seule fois, mais chaque fois qu’une compromission est suspectée ou qu’une mise à jour de sécurité importante est déployée
  • Pour réduire les contraintes et les risques, il vaut généralement mieux que chaque machine génère elle-même la graine aléatoire qu’elle utilisera, plutôt que de l’importer depuis l’extérieur
  • Un serveur standard dispose de jitter CPU, d’interactions avec les périphériques et d’événements réseau, ce qui suffit généralement pour des usages ordinaires
  • Si l’on veut une sécurité supplémentaire, on peut ajouter quelques dongles matériels RNG par baie de serveurs, mais des mécanismes plus complexes constituent une complexité inutile

Pourquoi le mur de lampes à lave est inutile

  • Le mur de lampes à lave de Cloudflare n’est pas nécessaire, et le relier aux serveurs via le réseau local ne fait qu’augmenter la complexité et la surface d’attaque
  • Même si le risque peut être très faible quand c’est correctement implémenté, il reste supérieur au bénéfice obtenu
  • Si Cloudflare prend la sécurité au sérieux, l’entreprise devrait cesser d’utiliser des lampes à lave pour cela et les réserver à la décoration et au marketing
  • Il est plus simple et plus sûr que les serveurs génèrent eux-mêmes leurs nombres aléatoires
  • Il est aussi possible que Cloudflare fonctionne déjà ainsi

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Commentaires sur Lobste.rs

  • Cet article semble mal informé et un peu rabat-joie. La génération moderne de nombres aléatoires utilise plusieurs sources d’entropie indépendantes, que l’ordinateur continue de mélanger dans un pool d’entropie via des fonctions de hachage pendant son fonctionnement.
    Il n’y a pas une unique « graine aléatoire » dans l’ordinateur ; au lieu de cela, pendant l’exécution, il est continuellement réensemencé à partir de multiples sources d’entropie, selon un schéma du type seed = hash(seed, new_data). Ajouter les données d’une caméra filmant des lampes à lave ne réduit absolument pas la sécurité du système. Les données ajoutées au pool d’entropie sont déjà hachées avec les autres données présentes. Le système est conçu pour rester sûr dès lors qu’il existe ne serait-ce qu’un tout petit peu d’information inconnue de l’attaquant ; mélanger beaucoup de données à l’aléa variable ne dégrade donc pas la sécurité.
    Les lampes à lave ne nuisent pas à la sécurité du système et, personnellement, j’y vois une œuvre d’art joyeuse et fonctionnelle qui fait partie du système. Elles améliorent aussi, de façon extrêmement marginale, la qualité de l’aléa et rendent visuelles les notions d’aléatoire et d’entropie.

    • Oui, mais les générateurs aléatoires du noyau utilisent déjà depuis plus de 30 ans diverses formes d’aléa matériel, et il vaut mieux ne pas exagérer à quel point ils sont réensemencés « en continu » ou « sans cesse ».
      L’aléa est collecté en permanence depuis le matériel, mais le générateur aléatoire de Linux est réensemencé périodiquement. Pendant la première minute après le démarrage, cela se produit toutes les quelques secondes, puis le rythme ralentit à environ une fois par minute.

      https://zx2c4.com/projects/linux-rng-5.17-5.18/…

    • Je ne sais pas d’où vient l’impression qu’on aurait dit ou laissé entendre que les systèmes existants ne fonctionnaient pas déjà ainsi. Ici, en dehors de la partie sur les lampes à lave, il ne s’agissait pas d’expliquer les systèmes existants, mais de souligner à quel point nous avons en réalité besoin de peu, à savoir 256 bits.
      Quand tu dis qu’ajouter les données d’une caméra filmant des lampes à lave ne réduit pas la sécurité, cela me fait penser à la surface d’attaque. On ajoute un ordinateur embarqué ainsi qu’une communication réseau entre cet ordinateur et le serveur. À mes yeux, ce faible risque supplémentaire est bien plus grand que le risque absurdement faible qui ferait qu’on aurait réellement besoin de lampes à lave.

  • Une autre façon d’exprimer la distinction philosophique est la suivante : combien y a-t-il de résultats possibles, et à quel point le résultat est-il prévisible ?
    Pour les usages cryptographiques, nous avons fixé la prévisibilité à un niveau de 2^-256, mais il existe, de manière intéressante, des processus courants dont le nombre de résultats possibles est bien plus grand, et il peut arriver qu’on veuille pouvoir produire n’importe quel résultat possible, même s’il est extrêmement improbable. Dans ce genre de situation, l’aléa cryptographique peut ne pas suffire.
    Un jeu standard de cartes a 52! mélanges possibles, soit environ 2^226 ; une graine cryptographiquement aléatoire permet donc de produire tous les mélanges. Mais si l’on joue à Uno ou que l’on mélange plusieurs jeux ensemble, un générateur aléatoire à 256 bits n’a pas assez d’état pour produire tous les mélanges possibles. Si toute l’aléa en espace utilisateur du système provient du noyau, et que le noyau fait passer toute l’aléa matérielle dans un CSPRNG de 256 bits, alors cela ne sera peut-être pas suffisant pour mélanger des cartes à Las Vegas :-)
    Ce qui manque dans l’article, c’est le réensemencement ; c’est un sujet intéressant, notamment pour montrer comment il interagit avec l’effacement rapide des clés et la difficulté d’obtenir la graine initiale. L’article laisse entendre que Linux n’utilise que le jitter CPU, mais c’est une simplification excessive. Linux utilise de nombreuses sources d’aléa, et la danse du jitter n’est qu’un dernier recours.

    • Non. En pratique, on ne fait absolument jamais les choses ainsi.
      Dans le monde réel, on ne peut même pas obtenir 2^128 échantillons. En réalité, c’est bien moins que cela, et c’est pour cette raison qu’AES-128 reste largement assez sûr pour de nombreux usages. Quand le nombre de résultats possibles dépasse 2^256, « exécuter tous les résultats possibles » est tout simplement impossible. Il vaut mieux oublier cette idée. Cela n’existe pas.
      Même au blackjack, quand on utilise 6 jeux au lieu d’un seul, on ne cherche pas en réalité un processus de mélange qui répartisse uniformément la probabilité sur tous les mélanges possibles. Il suffit d’avoir une distribution suffisamment bonne pour qu’on ne puisse pas faire la différence, même en échantillonnant autant que possible. Même si le nombre de mélanges est limité à 2^256, voire 2^128, on ne verrait pas la différence.
      Si j’ai laissé de côté le réensemencement dans l’article, c’était volontaire. Il n’est nécessaire qu’à certains moments précis, comme après une compromission suspectée et pour certaines mises à jour de sécurité. Cela peut aussi s’appliquer au redémarrage, si c’est plus simple ou plus sûr que de conserver l’état du générateur dans une mémoire non volatile. C’est pourquoi je préfère le voir non pas comme un « réensemencement », mais comme un redémarrage à partir d’une nouvelle graine initiale.
      En fonctionnement normal, le réensemencement n’est absolument pas nécessaire. L’implémenter ne ferait qu’ajouter de la complexité.
      J’aurais dû vérifier cette implication selon laquelle Linux n’utiliserait que le jitter CPU. D’après ce que j’avais compris, au moment du démarrage, c’était la seule source. En particulier avant les entrées utilisateur et réseau, je pensais que c’était le cas. Tu connais d’autres sources ? Le support des générateurs matériels d’aléa doit sans doute déjà exister.
    • Cette distinction entre possibilité et prévisibilité me fait penser à l’article de Shamir, Rivest et Adleman. Ils y démontrent qu’il est mathématiquement impossible pour deux personnes de jouer au poker sécurisé par téléphone avec un jeu de cartes virtuel.
      On ne peut pas. Mais en laissant cela de côté, voici comment le faire en toute sécurité…
    • Intéressant. Si je me souviens bien, lire depuis une vraie source aléatoire est une opération bloquante, donc si le noyau n’a pas assez d’octets aléatoires disponibles, cela peut prendre un certain temps avant d’obtenir suffisamment d’aléa.
      J’imagine que les cartes matérielles de génération d’aléa existaient sans doute pour fournir des sources parallèles d’aléa, mesurées non seulement en densité de bits, mais aussi en nombre de bits par unité de temps.

  • Je ne suis pas fortement en désaccord avec beaucoup d’affirmations prises individuellement, mais l’argument global m’a semblé flou. L’article se construit autour de l’idée que « la cryptographie moderne a besoin de beaucoup moins de véritable aléa que les gens ne le pensent », puis atterrit sur « donc les lampes à lave sont pires parce qu’elles élargissent la surface d’attaque ».
    Les deux affirmations peuvent être vraies, mais l’enchaînement vers la conclusion semble brutal.

    • Honnêtement, la structure narrative ne me satisfait pas vraiment non plus. Cela dit, la moitié de la conclusion était déjà dans le titre.

  • LavaRand faisait déjà ce genre de chose il y a plus de 20 ans. À l’époque, c’était mignon, mais les capteurs photo étaient bien plus petits et, à cause de caractéristiques prévisibles comme les lentilles, ce n’était pas une très bonne source d’entropie.
    J’aime les lampes à lave, mais la consommation électrique d’un mur qui en contient des centaines me paraît assez élevée pour un dispositif aussi gadget.

  • Cela ressemble à de l’auto-promotion. La personne partage rarement des liens, et quand elle le fait, elle publie ses propres liens. Ses 5 publications les plus récentes renvoient toutes à son propre contenu.

    • Tout dépend de la manière dont on interprète « stories and comments ».
      « C’est bien que les auteurs participent à la communauté, mais ils ne doivent pas en abuser comme d’un outil à sens unique pour annoncer un produit ou attirer du trafic vers leur propre travail. En règle générale, l’auto-promotion doit représenter moins d’un quart de leurs stories et comments. »
      Avec 15 publications et 1399 commentaires, cette personne participe clairement à la communauté. Enfin, sauf si elle poste plus de 90 commentaires sur chacun de ses propres sujets.

  • Cloudflare a contribué avec l’entropie issue des lampes à lave, l’University of Chile avec des données sismiques, et si je me souviens bien EPFL avec des mesures de désintégration radioactive ; divers autres participants ont aussi fourni différentes données à la cérémonie de génération de clé initiale du réseau drand.
    Aurait-on pu utiliser un CSPRNG ? Bien sûr. Mais où serait le plaisir ?

    • Le plaisir, c’est très bien. Les lampes à lave sont belles, et leur mur de vagues est vraiment magnifique. La limite est franchie quand on fait semblant que cela améliore réellement la sécurité.