Comme vous le savez, /dev/random, un générateur de nombres pseudo-aléatoires cryptographiquement sécurisés (CSPRNG), présente un problème désagréable : les blocages. Cet article explique comment résoudre ce problème.
Au cours des derniers mois, les moyens de génération de nombres aléatoires dans le noyau ont été légèrement retravaillés, mais les problèmes dans ce sous-système ont été résolus sur de plus larges . Les plus ont été apportées pour éviter le blocage prolongé de l'appel système getrandom() au démarrage du système, mais la cause sous-jacente était le comportement du pool aléatoire bloquant. Le récent correctif aurait supprimé ce pool, et l'on s'attendait à ce qu'il soit intégré au noyau principal.
Andy Lutomirski a publié la troisième version du patch à la fin décembre. Il apporte « deux changements sémantiques majeurs dans les API aléatoires de Linux ». Le correctif ajoute un nouveau drapeau GRND_INSECURE à l'appel système getrandom() (bien que Lutomirski s'y réfère sous le nom de getentropy(), qui est implémenté dans glibc avec getrandom() avec des drapeaux fixes) ; ce drapeau force l'appel à toujours retourner la quantité de données demandée, mais sans garantie que ces données soient aléatoires. Le noyau fera simplement de son mieux pour fournir les meilleures données aléatoires disponibles à ce moment-là. « Il est probablement préférable de l'appeler 'INSECURE' (insecure), pour décourager l'utilisation de cette API pour des choses nécessitant de la sécurité. »
Les correctifs suppriment également le pool bloquant. Actuellement, le noyau gère deux pools de données aléatoires, l'un correspondant à /dev/random et l'autre à /dev/urandom, comme décrit dans cet article de 2015. Le pool bloquant est celui de /dev/random ; la lecture de ce dispositif sera bloquée (comme l'indique son nom) jusqu'à ce qu'une « quantité suffisante » d'entropie soit collectée dans le système pour satisfaire la demande. D'autres lectures de ce fichier sont également bloquées s'il n'y a pas suffisamment d'entropie dans le pool.
La suppression du pool de blocage signifie que la lecture à partir de /dev/random se comporte comme getrandom() avec une valeur de flags égale à zéro (et transforme le flag GRND_RANDOM en noop). Après l'initialisation du générateur de nombres aléatoires cryptographiques (CRNG), lire à partir de /dev/random et appeler getrandom(…,0) ne provoquera pas de blocage et renverra la quantité demandée de données aléatoires.
Loutomirski dit : « Je pense que le pool de blocage de Linux est dépassé. Le CRNG de Linux génère des sorties qui sont suffisamment bonnes pour être utilisées même pour la génération de clés. Le pool de blocage n'est plus plus sécurisé de manière significative et nécessite beaucoup d'infrastructure de valeur douteuse pour fonctionner. »
Des modifications ont été apportées dans le but que les programmes existants ne souffrent pas réellement, et en effet, les problèmes d'attente prolongée pour des choses comme la génération de clés GnuPG devraient diminuer.
« Ces séries ne devraient pas interrompre les programmes existants. /dev/urandom reste inchangé. /dev/random est toujours bloqué juste après le démarrage, mais il est moins souvent bloqué qu'auparavant. getentropy() avec les flags existants renverra un résultat qui sera tout aussi adéquat à des fins pratiques qu'auparavant. »
Loutomirski a noté qu'il reste encore à déterminer si le noyau doit fournir ce qu'on appelle des « nombres aléatoires véritables », ce que le noyau de blocage était censé faire dans une certaine mesure. Il ne voit qu'une seule raison à cela : « le respect des normes gouvernementales ». Loutomirski a suggéré que si le noyau doit le garantir, cela devrait être fait via une interface complètement différente ou devrait être déplacé dans l'espace utilisateur, lui permettant d'extraire des échantillons bruts d'événements qui peuvent être utilisés pour créer un tel pool de blocage.
Stephan Müller a suggéré que son ensemble Pour le générateur de nombres aléatoires Linux (LRNG) (actuellement en version 26), cela pourrait être un moyen de fournir de véritables nombres aléatoires aux applications qui en ont besoin. LRNG « respecte pleinement les recommandations sur les sources d'entropie utilisées pour la génération de bits aléatoires » SP800-90B, ce qui en fait une solution aux problèmes de normes gouvernementales.
Matthew Garrett s'est opposé au terme « données aléatoires vraies », notant que les dispositifs choisis peuvent essentiellement être suffisamment modélisés pour les rendre prévisibles : « nous ne sélectionnons pas ici des événements quantiques ».
Müller a répondu que ce terme provient de la norme allemande AIS 31 pour décrire un générateur de nombres aléatoires qui ne produit un résultat « qu'à la vitesse à laquelle la source de bruit de base génère de l'entropie ».
Au-delà des divergences terminologiques, la présence d'un pool de verrouillage, comme proposé par les patches LRNG, entraînera simplement divers problèmes, au moins s'il est accessible sans privilèges.
Comme l'a dit Lotomirski : « Cela ne résout pas le problème. Si deux utilisateurs différents lancent des programmes idiots, comme gnupg, ils s'épuisent simplement mutuellement. Je vois qu'il existe actuellement deux problèmes majeurs avec /dev/random : il est sujet à des attaques par déni de service (c'est-à-dire l'épuisement des ressources, l'influence malveillante ou quelque chose de semblable), et, comme aucune privilège n'est requis pour son utilisation, il est également sujet à des abus. Gnupg se trompe, c'est un effondrement total. Si nous ajoutons une nouvelle interface non privilégiée que gnupg et des programmes similaires utiliseront, nous perdrons encore une fois. »
Müller a noté que l'ajout de getrandom() permettra maintenant à GnuPG d'utiliser cette interface, car elle garantira que le pool a été initialisé. D'après des discussions avec le développeur de GnuPG Werner Koch, Müller estime que cette garantie est la seule raison pour laquelle GnuPG lit actuellement directement à partir de /dev/random. Mais s'il existe une interface non privilégiée sujette à des déni de service (comme aujourd'hui /dev/random), alors selon Lotomirski, elle sera mal utilisée par certaines applications.
Théodore Tsao (Theodore Yue Tak Ts’o), développeur du sous-système de nombres aléatoires de Linux, semble avoir changé d'avis sur la nécessité d'un pool bloquant. Il a déclaré que la suppression de ce pool permettrait d'éliminer efficacement l'idée que Linux dispose d'un véritable générateur de nombres aléatoires (TRNG): « Ce n'est pas une absurdité, car c'est précisément ce que *BSD a toujours fait. »
Il est également préoccupé par le fait que la fourniture d'un mécanisme TRNG servira simplement d'appât pour les développeurs d'applications et estime qu'il est en réalité impossible de garantir un TRNG dans le noyau, compte tenu des différents types de matériel pris en charge par Linux. Même la possibilité d'interagir avec le matériel uniquement sur la base de privilèges root ne résoudra pas le problème: « Les développeurs d'applications précisent que pour des raisons de sécurité, leur application doit être installée en tant que root, car c'est le seul moyen d'accéder à des nombres aléatoires « vraiment bons ». »
Müller a demandé si Tsao avait abandonné la mise en œuvre du pool bloquant qu'il avait lui-même proposé il y a longtemps. Tsao a répondu qu'il prévoyait d'appliquer les correctifs de Lutomirski et s'oppose fermement à l'ajout d'une interface bloquante dans le noyau.
« Le noyau ne peut donner aucune garantie quant à savoir si la source de bruit a été correctement caractérisée. La seule chose que le développeur de GPG ou OpenSSL peut obtenir, c'est une vague impression que TRUERANDOM est « meilleur », et comme ils souhaitent une plus grande sécurité, ils tenteront sans aucun doute de l'utiliser. À un moment donné, cela sera bloqué, et lorsque d'autres utilisateurs intelligents (peut-être un spécialiste de la distribution) l'incluront dans le script init, les systèmes cesseront de fonctionner, laissant aux utilisateurs le seul recours de se plaindre directement à Linus Torvalds. »
Tsao plaide également pour fournir aux cryptographes et à ceux qui ont réellement besoin d'un TRNG un moyen de rassembler leur propre entropie dans l'espace utilisateur, afin de l'utiliser à leur convenance. Il affirme que la collecte d'entropie n'est pas un processus que le noyau peut réaliser sur tout le matériel qu'il prend en charge ; de plus, le noyau ne peut pas évaluer la quantité d'entropie fournie par les différentes sources.
«Le noyau ne doit pas mélanger différentes sources de bruit, et il ne doit certainement pas prétendre savoir combien de bits d'entropie il reçoit lorsqu'il essaie de jouer à un « jeu d'entropie désordonné » sur une architecture CPU d'une simplicité désarmante pour les cas d'utilisation IOT/Embedded, lorsque tout est désynchronisé avec un seul générateur maître, lorsqu'il n'y a aucune instruction CPU pour réorganiser ou renommer le registre, etc.».
«On peut parler de fournir des outils qui tentent de faire ces calculs, mais de telles choses doivent se faire sur le matériel de chaque utilisateur, ce qui est simplement impratique pour la plupart des utilisateurs de la distribution. Si cela est destiné uniquement aux cryptographes, qu'ils le fassent dans leur espace utilisateur. Et ne simplifions pas GPG, OpenSSL, etc., pour que tout le monde dise : « nous voulons de la « véritable aléa » et nous ne sommes pas prêts à accepter moins ». On peut aborder comment nous fournissons des interfaces aux cryptographes pour qu'ils puissent obtenir les informations nécessaires grâce à l'accès à des sources de bruit primaires, séparées et nommées, et peut-être que d'une manière ou d'une autre, la source de bruit pourra s'authentifier dans la bibliothèque ou l'application de l'espace utilisateur».
Il y a eu une petite discussion sur la manière dont cette interface pourrait ressembler, car, par exemple, certains événements peuvent avoir des implications en matière de sécurité. Cao a noté que les codes de balayage du clavier (c'est-à-dire les frappes de touches) sont mélangés dans un pool dans le cadre de la collecte d'entropie : « Transférer cela dans l'espace utilisateur, même par un appel système privilégié, serait au moins imprudent ». Il est tout à fait possible que d'autres chronométrages d'événements puissent créer une sorte de fuite d'informations par canaux latéraux.
Ainsi, il semble que le vieux problème de la sous-système de nombres aléatoires de Linux soit en passe d'être résolu. Les changements récents apportés à ce sous-système n'ont en réalité entraîné que des problèmes de DoS lors de son utilisation. Cependant, des méthodes efficaces ont maintenant été mises en place pour obtenir les meilleurs nombres aléatoires que le noyau peut fournir. Si le TRNG est toujours souhaitable pour Linux, cette lacune devra être corrigée à l'avenir, mais il est probable que cela ne se fera pas au sein même du noyau.
Un peu de publicité 🙂
Merci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu intéressant ? Soutenez-nous en passants une commande ou en nous recommandant à des amis, , un équivalent unique des serveurs d'entrée de gamme, conçu pour vous : (options disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go DDR4).
Dell R730xd deux fois moins cher dans le data center Equinix Tier IV à Amsterdam ? Uniquement chez nous aux Pays-Bas ! Dell R420 — 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To — à partir de 99 $ ! Lisez sur
Source : habr.com
