/dev/random, un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG), est connu pour avoir un problème ennuyeux : le blocage. Cet article explique comment vous pouvez le résoudre.
Au cours des derniers mois, les fonctionnalités de génération de nombres aléatoires du noyau ont été légèrement retravaillées, mais les problèmes de ce sous-système ont été résolus au cours de la mise à jour plus large. . La plupart ont été conçus pour empêcher l'appel système getrandom() de se bloquer pendant une longue période au démarrage du système, mais la raison sous-jacente en était le comportement de blocage du pool aléatoire. Un patch récent aurait supprimé ce pool et il aurait été prévu qu'il se dirige vers le noyau principal.
Andy Lutomirski a publié la troisième version du patch fin décembre. Il contribue "deux changements sémantiques majeurs apportés aux API Linux aléatoires". Le correctif ajoute un 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) ; cet indicateur fait que l'appel renvoie toujours la quantité de données demandée, mais sans garantir que les données sont aléatoires. Le noyau fera simplement de son mieux pour produire les meilleures données aléatoires dont il dispose à un moment donné. "La meilleure chose à faire est probablement de l'appeler "INSECURE" (non sécurisé) pour empêcher que cette API soit utilisée pour des choses qui nécessitent de la sécurité.
Les correctifs suppriment également le pool de blocage. Le noyau gère actuellement deux pools de données aléatoires, l'un correspondant à /dev/random et l'autre à /dev/urandom, comme décrit dans ce document. 2015. Le pool de blocage est le pool pour /dev/random ; les lectures pour cet appareil seront bloquées (c'est-à-dire son nom) jusqu'à ce que "suffisamment" d'entropie ait été collectée auprès du système pour satisfaire la demande. Les lectures ultérieures de ce fichier sont également bloquées s'il n'y a pas suffisamment d'entropie dans le pool.
La suppression du pool de verrouillage signifie que la lecture depuis /dev/random se comporte comme getrandom() avec des indicateurs définis sur zéro (et transforme l'indicateur GRND_RANDOM en noop). Une fois le générateur de nombres aléatoires cryptographiques (CRNG) initialisé, la lecture depuis /dev/random et les appels à getrandom(...,0) ne bloqueront pas et renverront la quantité demandée de données aléatoires.
Lutomirski dit : « Je pense que le pool de blocage Linux est devenu obsolète. CRNG Linux génère une sortie suffisamment bonne pour même être utilisée pour la génération de clés. Le pool de blocage n’est pas plus solide d’un point de vue matériel et nécessite de nombreuses infrastructures de valeur douteuse pour le soutenir.
Les changements ont été apportés dans le but de garantir que les programmes existants ne seraient pas vraiment affectés et qu'en fait, il y aurait moins de problèmes avec de longues attentes pour des choses comme la génération de clés GnuPG.
« Ces épisodes ne doivent perturber aucun programme existant. /dev/urandom reste inchangé. /dev/random bloque toujours immédiatement au démarrage, mais il bloque moins qu'avant. getentropy() avec les indicateurs existants renverra un résultat tout aussi adapté à des fins pratiques qu'auparavant."
Lutomirsky a noté que la question reste ouverte de savoir si le noyau doit fournir ce que l'on appelle de « vrais nombres aléatoires », ce que le noyau bloquant était censé faire dans une certaine mesure. Il n’y voit qu’une seule raison : « le respect des normes gouvernementales ». Lutomirsky a suggéré que si le noyau devait fournir cela, cela devrait être fait via une interface complètement différente, ou cela devrait être déplacé dans l'espace utilisateur, permettant à l'utilisateur de récupérer des échantillons d'événements bruts qui pourraient être utilisés pour créer un tel pool de verrouillage.
Stephan Müller a proposé que son set pour Linux Random Number Generator (LRNG) (actuellement version 26 publiée) pourrait être un moyen de fournir de véritables nombres aléatoires pour les applications qui en ont besoin. LRNG est « entièrement conforme aux directives SP800-90B sur les sources d'entropie utilisées pour générer des bits aléatoires », ce qui en fait une solution au problème des normes gouvernementales.
Matthew Garrett s'est opposé au terme « véritables données aléatoires », soulignant que les dispositifs échantillonnés pourraient en principe être modélisés avec suffisamment de précision pour les rendre prévisibles : « nous n'échantillonnons pas ici les événements quantiques ».
Müller 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 ne produit un résultat « qu'au même rythme que la source de bruit sous-jacente produit de l'entropie ».
Mis à part les différences terminologiques, disposer d'un pool de verrouillage comme le suggèrent les correctifs LRNG entraînera simplement divers problèmes, du moins s'il est accessible 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 comme gnupg, ils se videront mutuellement. Je vois qu'il y a actuellement deux problèmes principaux avec /dev/random : il est sujet au DoS (c'est-à-dire l'épuisement des ressources, une influence malveillante ou quelque chose de similaire), et comme aucun privilège n'est requis pour l'utiliser, il est également sujet aux 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 encore. »
Mueller a noté que l'ajout de getrandom() permettra désormais à GnuPG d'utiliser cette interface, car elle fournira la garantie nécessaire que le pool a été initialisé. Sur la base de discussions avec le développeur de GnuPG, Werner Koch, Mueller estime 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 susceptible de faire l'objet d'un déni de service (comme /dev/random l'est aujourd'hui), Lutomirsky affirme qu'elle sera utilisée à mauvais escient par certaines applications.
Theodore Yue Tak Ts'o, développeur du sous-système de nombres aléatoires de Linux, semble avoir changé d'avis quant à la nécessité d'un pool de blocage. Il a déclaré que la suppression de ce pool éliminerait effectivement l'idée selon laquelle Linux dispose d'un véritable générateur de nombres aléatoires (TRNG) : "ce n'est pas absurde, puisque c'est exactement ce que *BSD a toujours fait."
Il craint également que la fourniture d'un mécanisme TRNG ne serve simplement d'appât aux développeurs d'applications et estime qu'en fait, étant donné les différents types de matériel pris en charge par Linux, il est impossible de garantir le TRNG dans le noyau. Même la possibilité de travailler avec des équipements uniquement avec les privilèges root ne résoudra pas le problème : "Les développeurs d'applications précisent que leur application doit être installée en tant que root pour des raisons de sécurité, afin que ce soit le seul moyen d'accéder aux "très bons" nombres aléatoires."
Mueller a demandé si Cao avait abandonné la mise en œuvre du pool de blocage qu'il proposait lui-même depuis longtemps. Cao a répondu qu'il prévoyait de prendre les correctifs de Lutomirsky et s'opposait activement à l'ajout d'une interface de blocage au noyau.
« Le noyau ne peut garantir que la source de bruit a été correctement caractérisée. La seule chose qu'un développeur GPG ou OpenSSL peut ressentir est un vague sentiment que TRUERANDOM est "meilleur", et comme il veut plus de sécurité, il essaiera 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 d'initialisation et que les systèmes cesseront de fonctionner, les utilisateurs n'auront qu'à se plaindre auprès de Linus Torvalds lui-même.
Cao préconise également de donner aux cryptographes et à ceux qui ont réellement besoin de TRNG un moyen de récolter leur propre entropie dans l'espace utilisateur et de 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 différents matériels qu'il prend en charge, et que le noyau lui-même ne peut pas non plus estimer la quantité d'entropie fournie par différentes sources.
"Le noyau ne devrait pas mélanger différentes sources de bruit, et il ne devrait certainement pas essayer de prétendre savoir combien de bits d'entropie il obtient lorsqu'il essaie de jouer à une sorte de "jeu d'entropie nerveux" sur un processeur outrageusement simple. " Architecture pour les utilisateurs grand public. Cas IOT/Embedded où tout est désynchronisé avec un seul oscillateur maître, où il n'y a pas d'instruction CPU pour réorganiser ou renommer un registre, etc. "
« On peut parler de fournir des outils qui tentent d'effectuer ces calculs, mais ces choses doivent être faites sur le matériel de chaque utilisateur, ce qui n'est tout simplement pas pratique pour la plupart des utilisateurs de distribution. Si cela n’est destiné qu’aux cryptographes, alors laissez-le se faire dans leur espace utilisateur. Et ne simplifions pas GPG, OpenSSL, etc. pour que tout le monde dise « nous voulons du « vrai hasard » et ne nous contenterons pas de moins ». Nous pouvons parler de la façon dont nous fournissons des interfaces aux cryptographes afin qu'ils puissent obtenir les informations dont ils ont besoin en accédant aux principales sources de bruit, séparées et nommées, et peut-être que d'une manière ou d'une autre, la source de bruit peut s'authentifier auprès d'une bibliothèque ou d'une application de l'espace utilisateur.
Des discussions ont eu lieu sur ce à quoi pourrait ressembler une telle interface, car par exemple, certains événements pourraient avoir des implications en matière de sécurité. Cao a noté que les codes de balayage du clavier (c'est-à-dire les frappes au clavier) sont mélangés dans un pool dans le cadre de la collecte d'entropie : « Introduire cela dans l'espace utilisateur, même via un appel système privilégié, serait pour le moins imprudent. » Il est tout à fait possible que d’autres timings d’événements créent une sorte de fuite d’informations via des canaux secondaires.
Il semble donc qu'un problème de longue date avec le sous-système de nombres aléatoires de Linux soit en passe d'être résolu. Les changements récemment subis par le sous-système de nombres aléatoires n’ont en réalité entraîné que des problèmes de DoS lors de son utilisation. Il existe désormais des moyens efficaces d'obtenir les meilleurs nombres aléatoires que le noyau peut fournir. Si le TRNG est toujours souhaitable sous Linux, alors cette faille devra être corrigée à l'avenir, mais cela ne sera probablement pas fait au sein du noyau lui-même.
Quelques publicités 🙂
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com