Comme vous le savez, / dev / random, un générateur de nombres pseudo aléatoires (CSPRNG) cryptographiquement puissant, a un problème désagréable - le blocage. Cet article décrit comment le résoudre.
Au cours des derniers mois, les moyens de générer des nombres aléatoires dans le noyau ont été légèrement retravaillés, mais les problèmes de ce sous-système ont été résolus sur une
période plus large. Les
modifications les plus
récentes ont été apportées pour empêcher l'appel système getrandom () d'être bloqué pendant une longue période lors du démarrage du système, mais la raison derrière cela était le comportement du pool aléatoire de blocage. Un correctif récent supprimerait ce pool, et il était à prévoir qu'il irait au noyau principal.
Andy Lutomirski a publié la troisième version du patch fin décembre. Il apporte
"deux modifications sémantiques de base aux API Linux aléatoires" . Le correctif ajoute le nouvel indicateur GRND_INSECURE à l'appel système getrandom () (bien que Lutomirsky l'appelle getentropy (), qui est implémenté dans la glibc en utilisant getrandom () avec des indicateurs fixes); ce drapeau oblige l'appel à toujours renvoyer la quantité de données demandées, mais sans garantir que les données sont aléatoires. Le noyau fera simplement de son mieux pour fournir les meilleures données aléatoires qu'il possède à un moment donné.
"Probablement la meilleure chose que vous puissiez faire est de l'appeler" INSECURE " (dangereux) pour l'empêcher d'être utilisé pour des choses qui ont besoin de sécurité."
Les correctifs suppriment également le pool de blocage. Actuellement, le noyau prend en charge deux pools de données aléatoires, dont l'un correspond à / dev / random et l'autre à / dev / urandom, comme décrit dans cet
article de 2015. Un pool de blocage est un pool pour / dev / random; la lecture de cet appareil sera bloquée (c'est-à-dire son nom) jusqu'à ce que l'entropie «suffisante» soit collectée du système pour satisfaire la demande. Les lectures ultérieures de ce fichier sont également bloquées s'il n'y a pas assez d'entropie dans le pool.
La suppression du pool de verrous signifie que la lecture à partir de / dev / random se comporte comme getrandom () avec la valeur des indicateurs définie sur zéro (et transforme l'indicateur GRND_RANDOM en noop). Après avoir initialisé le générateur de nombres aléatoires cryptographiques (CRNG), la lecture à partir de / dev / random et l'appel à getrandom (..., 0) ne bloqueront pas et retourneront la quantité demandée de données aléatoires.
Lutomirsky déclare:
«Je pense que le pool de blocage Linux est devenu obsolète. CRNG Linux génère une sortie suffisamment bonne pour être utilisée même pour la génération de clés. Le pool de blocage n'est pas plus solide dans un sens matériel, et il nécessite beaucoup d'infrastructure de valeur douteuse pour le maintenir. "Les modifications ont été apportées dans le but de garantir que les programmes existants ne souffrent pas vraiment, et en fait, les problèmes avec la longue attente pour des choses telles que la génération de clés GnuPG deviendront plus petits.
«Ces séries ne doivent violer aucun programme existant. / dev / urandom reste inchangé. / dev / random bloque toujours immédiatement après le chargement, mais il bloque moins qu'auparavant. getentropy () avec les drapeaux existants retournera un résultat qui sera tout aussi pratique pour le but qu'auparavant. »Lutomirsky a noté que la question reste ouverte de savoir si le noyau devrait fournir les soi-disant «vrais nombres aléatoires», ce qui aurait dû dans une certaine mesure être effectué par le noyau bloquant. Il ne voit qu'une seule raison à cela: «le respect des normes étatiques». Lutomirsky a suggéré que si le noyau devait fournir cela, alors cela devrait être fait via une interface complètement différente ou transféré vers l'espace utilisateur, lui permettant de récupérer des modèles d'événements non traités qui pourraient être utilisés pour créer un tel pool de verrous.
Stephan Müller a suggéré que son ensemble de
correctifs pour le générateur de nombres aléatoires Linux (LRNG) (la version 26 est actuellement publiée) pourrait être un moyen de fournir de vrais nombres aléatoires pour les applications qui en ont besoin. LRNG "répond pleinement aux exigences des" Recommandations sur les sources d'entropie utilisées pour générer des bits aléatoires "SP800-90B", ce qui en fait une solution au problème des normes étatiques.
Matthew Garrett s'est opposé à l'expression «vraies données aléatoires», notant que les dispositifs sélectionnables peuvent, en principe, être modélisés avec suffisamment de précision pour les rendre prévisibles: «nous ne prenons pas ici d'événements quantiques».
Muller a répondu que le terme vient de la norme allemande AIS 31 pour décrire un générateur de nombres aléatoires qui produit uniquement le résultat "à la même vitesse que la source de bruit sous-jacente produit l'entropie".
Outre les malentendus de la terminologie, la présence d'un pool de verrous, comme le suggèrent les correctifs LRNG, entraînera simplement divers problèmes, du moins s'il est disponible sans privilèges.
Comme l'a dit Lutomirsky:
«Cela ne résout pas le problème. Si deux utilisateurs différents exécutent des programmes stupides tels que gnupg, ils s'épuisent simplement l'un l'autre. Je vois qu'il y a actuellement deux problèmes principaux avec / dev / random: il est sensible au DoS (c'est-à-dire l'épuisement des ressources, les influences nuisibles ou quelque chose de similaire), et comme il ne nécessite aucun privilège pour l'utiliser, il a également soumis à des abus. Gnupg a tort, c'est un effondrement complet. Si nous ajoutons une nouvelle interface non privilégiée que gnupg et des programmes similaires utiliseront, nous perdrons à nouveau. »Muller a noté que l'ajout de getrandom () permettra désormais à GnuPG d'utiliser cette interface, car cela fournira la garantie nécessaire que le pool a été initialisé. D'après des discussions avec le développeur de GnuPG Werner Koch, Muller pense que la garantie est la seule raison pour laquelle GnuPG lit actuellement directement depuis / dev / random. Mais s'il existe une interface non privilégiée qui fait l'objet d'un déni de service (à partir d'aujourd'hui / dev / random), alors selon Lutomirsky, elle sera mal utilisée par certaines applications.
Theodore Yue Tak Ts'o, le développeur du sous-système de nombres aléatoires Linux, semble avoir changé d'avis quant à la nécessité d'un pool de blocage. Il a dit que la suppression de ce pool se débarrasserait effectivement de l'idée que Linux a un véritable générateur de nombres aléatoires (TRNG):
"ce n'est pas un non-sens, car c'est exactement ce que * BSD a toujours fait."Il craint également que la fourniture du mécanisme TRNG serve simplement de leurre aux développeurs d'applications et estime qu'en réalité, compte tenu des différents types de matériel pris en charge par Linux, il n'est pas possible de garantir TRNG dans le noyau. Même la possibilité de travailler avec un équipement basé sur les privilèges root ne résoudra pas le problème:
"Les développeurs d'applications spécifient que leur application doit être installée en tant que root pour des raisons de sécurité, car c'est la seule façon d'accéder à de" très bons "nombres aléatoires."Muller a demandé si Cao avait refusé de mettre en œuvre le pool de blocage, qu'il avait lui-même proposé depuis longtemps. Cao a répondu qu'il prévoyait de prendre les correctifs Lutomirsky et s'est activement opposé à l'ajout d'une interface de blocage au noyau.
«Le noyau ne peut donner aucune garantie quant à la bonne caractérisation de la source de bruit. La seule chose qu'un développeur GPG ou OpenSSL peut obtenir est le vague sentiment que TRUERANDOM est «meilleur» et comme ils veulent plus de sécurité, ils essaieront sans aucun doute de l'utiliser. À un moment donné, il sera bloqué, et lorsqu'un autre utilisateur intelligent (peut-être un spécialiste de la distribution) l'insérera dans le script init et que les systèmes cesseront de fonctionner, les utilisateurs n'auront qu'à se plaindre de Linus Torvalds lui-même. »Cao préconise également de fournir aux cryptographes et à ceux qui ont vraiment besoin de TRNG un moyen de collecter leur propre entropie dans l'espace utilisateur afin qu'ils puissent l'utiliser comme bon leur semble. Il dit que la collecte d'entropie n'est pas un processus qui peut être effectué par le noyau sur tous les types de matériel pris en charge par lui, en outre, le noyau lui-même ne peut pas estimer la quantité d'entropie fournie par diverses sources.
"Le noyau ne doit pas mélanger différentes sources de bruit ensemble, et bien sûr, il ne doit pas essayer de prétendre qu'il sait combien de bits d'entropie il reçoit quand il essaie de jouer une sorte de" jeu saccadé d'entropie "sur une architecture CPU simple pour l'utilisateur laid "Cas IOT / Embedded, lorsque tout n'est pas synchronisé avec un seul générateur maître, quand il n'y a aucune instruction CPU pour réorganiser ou renommer le registre, etc."
«Nous pouvons parler de fournir des outils qui essaient de faire ces calculs, mais de telles choses devraient être effectuées sur l'équipement de chaque utilisateur, ce qui pour la plupart des utilisateurs du kit de distribution est tout simplement impossible. Si cela n'est destiné qu'aux cryptographes, laissez-le se faire dans leur espace utilisateur. Et ne simplifions pas GPG, OpenSSL, etc., pour que tout le monde dise: "nous voulons un" vrai hasard "et nous ne sommes pas d'accord sur quoi que ce soit de moins." Nous pouvons parler de la façon dont nous fournissons des interfaces aux cryptographes afin qu'ils puissent obtenir les informations nécessaires en accédant aux sources de bruit primaires, séparées et nommées, et, éventuellement, d'une manière ou d'une autre, la source de bruit peut s'authentifier dans une bibliothèque ou une application d'espace utilisateur. »Il y a eu une petite discussion sur l'apparence d'une telle interface, car, par exemple, pour certains événements, il peut y avoir des implications pour la sécurité. Cao a noté que les codes de numérisation du clavier (c'est-à-dire les frappes de touches) sont mélangés dans le pool dans le cadre de la collecte d'entropie: "Transférer cela dans l'espace utilisateur, même via un appel système privilégié, serait au moins déraisonnable." Il est possible que d'autres temporisations d'événement puissent créer une sorte de fuite d'informations via des canaux latéraux.
Ainsi, on a le sentiment qu'un problème de sous-système de nombre aléatoire Linux de longue date est en passe de trouver une solution. Les changements que le sous-système de nombres aléatoires a subis récemment, en fait, n'ont conduit qu'à des problèmes de DoS dans le processus de son utilisation. Il existe maintenant des moyens efficaces d'obtenir les meilleurs nombres aléatoires que le noyau peut fournir. Si TRNG est toujours souhaitable pour Linux, alors cette lacune devra être corrigée à l'avenir, mais très probablement elle ne sera pas effectuée à l'intérieur du noyau lui-même.
Un peu de publicité :)
Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis
des VPS basés sur le cloud pour les développeurs à partir de 4,99 $ , un
analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur les VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! Pour en savoir plus sur la
création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?