Wie bekannt ist, hat /dev/random, ein kryptographisch sicherer Pseudozufallszahlengenerator (CSPRNG), ein unangenehmes Problem â Blockierungen. In diesem Artikel wird erlĂ€utert, wie man dieses Problem lösen kann.
In den letzten Monaten wurden die Mittel zur Generierung von Zufallszahlen im Kernel etwas ĂŒberarbeitet, aber Probleme in diesem Untersystem wurden ĂŒber einen lĂ€ngeren Zeitraum angegangen. waren die letzten. wurden vorgenommen, um zu verhindern, dass der Systemaufruf getrandom() beim Systemstart lange blockiert wird, aber die zugrunde liegende Ursache war das Verhalten des blockierenden Zufalls-Pools. Ein kĂŒrzlicher Patch wĂŒrde diesen Pool entfernen, und man konnte erwarten, dass er in den Hauptkernel einflieĂt.
Andy Lutomirski veröffentlichte Ende Dezember die dritte Version des Patches. Er fĂŒhrt ein. âzwei wesentliche semantische Ănderungen in den Zufalls-APIs von Linuxâ. Der Patch fĂŒgt dem Systemaufruf getrandom() ein neues Flag GRND_INSECURE hinzu (obwohl Lutomirski sich darauf als getentropy() bezieht, das in glibc mit getrandom() und festen Flags implementiert ist); dieses Flag sorgt dafĂŒr, dass der Aufruf immer die angeforderte Datenmenge zurĂŒckgibt, jedoch ohne Garantie, dass diese Daten zufĂ€llig sind. Der Kernel wird einfach sein Bestes tun, um die besten Zufallsdaten zu liefern, die ihm zu diesem Zeitpunkt zur VerfĂŒgung stehen. âWahrscheinlich ist es am besten, es âINSECUREâ zu nennen, um die Verwendung dieser API fĂŒr Dinge, die Sicherheit benötigen, zu verhindern.â
Die Patches entfernen auch den blockierenden Pool. Derzeit unterstĂŒtzt der Kernel zwei Zufallsdaten-Pools, von denen einer /dev/random und der andere /dev/urandom entspricht, wie in diesem Bericht von 2015 beschrieben. Der blockierende Pool ist der Pool fĂŒr /dev/random; das Lesen von diesem GerĂ€t wird blockiert (es wird auf seinen Namen verwiesen), bis im System genug âzufĂ€lligeâ Entropie gesammelt wurde, um die Anfrage zu erfĂŒllen. Weitere LesevorgĂ€nge aus dieser Datei werden ebenfalls blockiert, wenn im Pool nicht genug Entropie vorhanden ist.
Die Entfernung des Blockierungspools bedeutet, dass das Lesen aus /dev/random sich wie getrandom() mit einem Wert von flags gleich null verhĂ€lt (und das Flag GRND_RANDOM in noop umwandelt). Nach der Initialisierung des kryptografischen Zufallszahlengenerators (CRNG) fĂŒhrt das Lesen aus /dev/random und die Aufrufe von getrandom(âŠ,0) nicht zu einer Blockierung und geben die angeforderte Menge an Zufallsdaten zurĂŒck.
Lutomirski sagt: âIch glaube, dass der Blockierungspool von Linux ĂŒberholt ist. CRNG Linux erzeugt Ausgaben, die gut genug sind, um sie sogar zur Generierung von SchlĂŒsseln zu verwenden. Der Blockierungspool ist in keiner materiellen Hinsicht stĂ€rker, und fĂŒr seine Aufrechterhaltung ist viel Infrastruktur von fraglichem Wert erforderlich.â
Die Ănderungen wurden vorgenommen, um sicherzustellen, dass bestehende Programme tatsĂ€chlich nicht betroffen sind, und tatsĂ€chlich wird es weniger Probleme mit langen Wartezeiten bei so etwas wie der Generierung von GnuPG-SchlĂŒsseln geben.
âDiese Serien sollten keine bestehenden Programme stören. /dev/urandom bleibt unverĂ€ndert. /dev/random wird weiterhin sofort nach dem Booten blockiert, blockiert aber weniger als vorher. getentropy() mit den bestehenden Flags gibt ein Ergebnis zurĂŒck, das fĂŒr praktische Zwecke genauso geeignet sein wird wie zuvor.â
Lutomirski stellte fest, dass die Frage offen bleibt, ob der Kernel sogenannte âwahre Zufallszahlenâ bereitstellen sollte, was das blockierende Kernel in gewissem MaĂe tun sollte. Er sieht dafĂŒr nur einen Grund: âEinhaltung staatlicher Standardsâ. Lutomirski schlug vor, dass, wenn der Kernel dies bereitstellen soll, es ĂŒber ein völlig anderes Interface geschehen sollte oder es in den Benutzerspeicher ĂŒbertragen werden sollte, um ihm die Möglichkeit zu geben, rohe Ereignismuster abzurufen, die zur Erstellung eines solchen Blockierungspools verwendet werden können.
Stephan MĂŒller schlug vor, dass sein Satz Der Linux-Zufallszahlengenerator (LRNG) (derzeit in Version 26 veröffentlicht) könnte eine Möglichkeit sein, echte Zufallszahlen fĂŒr Anwendungen bereitzustellen, die diese benötigen. LRNG entspricht vollstĂ€ndig den Anforderungen der "Empfehlungen zu Entropiequellen fĂŒr die Generierung von Zufallsbits" SP800-90B, was es zu einer Lösung fĂŒr die Probleme staatlicher Standards macht.
Matthew Garrett sprach sich gegen den Begriff "echte Zufallsdaten" aus und bemerkte, dass die gewÀhlten GerÀte grundsÀtzlich so genau modelliert werden könnten, dass sie vorhersagbar wÀren: "Wir erfassen hier keine quantenmechanischen Ereignisse."
MĂŒller antwortete, dass dieser Begriff aus dem deutschen Standard AIS 31 stammt, der einen Zufallszahlengenerator beschreibt, der nur Ergebnisse "in der gleichen Geschwindigkeit wie die Entropie des Basisrauschs ausgibt".
Abgesehen von terminologischen Unterschieden wird die EinfĂŒhrung eines Blocking-Pools, wie sie durch die Patches von LRNG vorgeschlagen wird, einfach zu verschiedenen Problemen fĂŒhren â zumindest, wenn er ohne Berechtigungen verfĂŒgbar ist.
Wie Lutomirski sagte: âDas löst das Problem nicht. Wenn zwei verschiedene Benutzer dumme Programme wie gnupg ausfĂŒhren, werden sie sich einfach gegenseitig erschöpfen. Ich sehe aktuell zwei Hauptprobleme mit /dev/random: Es ist anfĂ€llig fĂŒr DoS (d.h. Ressourcenausbeutung, schĂ€dliche Beeinflussung oder etwas Ăhnliches), und da keine Berechtigungen fĂŒr seine Nutzung erforderlich sind, ist es auch anfĂ€llig fĂŒr Missbrauch. Gnupg ist falsch, es ist ein völliger Zusammenbruch. Wenn wir eine neue nicht privilegierte Schnittstelle hinzufĂŒgen, die von gnupg und Ă€hnlichen Programmen verwendet wird, werden wir wieder verlieren.â
MĂŒller stellte fest, dass die HinzufĂŒgung von getrandom() GnuPG nun die Nutzung dieser Schnittstelle ermöglichen wird, da sie die notwendige Garantie bietet, dass der Pool initialisiert wurde. Basierend auf Diskussionen mit dem GnuPG-Entwickler Werner Koch glaubt MĂŒller, dass diese Garantie der einzige Grund ist, warum GnuPG derzeit direkt aus /dev/random liest. Wenn jedoch eine nicht privilegierte Schnittstelle vorhanden ist, die anfĂ€llig fĂŒr Denial-of-Service ist (wie heute /dev/random), wird laut Lutomirski sie von einigen Anwendungen missbrĂ€uchlich verwendet werden.
Theodor Tsao (Theodore Yue Tak Tsâo), Entwickler des Linux-Zufallszahlensystems, hat anscheinend seine Meinung ĂŒber die Notwendigkeit eines blockierenden Pools geĂ€ndert. Er sagte, dass die Entfernung dieses Pools effektiv die Vorstellung beseitigen wĂŒrde, dass Linux einen echten Zufallszahlengenerator (TRNG) hat: "Es ist keine Dummheit, denn genau das haben *BSD immer gemacht."
Er ist auch besorgt, dass die Bereitstellung eines TRNG-Mechanismus lediglich als Köder fĂŒr Anwendungsentwickler dienen wird und hĂ€lt es fĂŒr unmöglich, TRNG im Kern zu garantieren, wenn man die verschiedenen Arten von Hardware berĂŒcksichtigt, die von Linux unterstĂŒtzt werden. Selbst die Möglichkeit, nur mit Root-Rechten auf Hardware zuzugreifen, wird das Problem nicht lösen: "Anwendungsentwickler stellen fest, dass ihre Anwendung aus SicherheitsgrĂŒnden als Root installiert werden sollte, denn nur so hat man Zugang zu 'wirklich guten' Zufallszahlen."
MĂŒller fragte, ob Tsao die Implementierung des blockierenden Pools, die er selbst vor langer Zeit vorgeschlagen hatte, aufgegeben hat. Tsao antwortete, dass er plant, die Patches von Lutomirski zu ĂŒbernehmen und aktiv gegen das HinzufĂŒgen einer blockierenden Schnittstelle zurĂŒck in den Kern ist.
"Der Kernel kann keine Garantien dafĂŒr geben, dass die Rauschenquelle ordnungsgemÀà charakterisiert wurde. Das Einzige, was der Entwickler von GPG oder OpenSSL erhalten kann, ist ein schwammiges GefĂŒhl, dass TRUERANDOM 'besser' ist, und da sie mehr Sicherheit wollen, werden sie es sicherlich verwenden wollen. Irgendwann wird es blockiert, und wenn ein anderer kluger Benutzer (möglicherweise ein Distribution-Release-Spezialist) es in das Init-Skript einfĂŒgt, werden die Systeme ausfallen, und den Benutzern bleibt nur, Linus Torvalds selbst zu beschweren."
Tsao spricht sich auch dafĂŒr aus, Kryptographen und denen, die wirklich TRNG benötigen, zu ermöglichen, ihre eigene Entropie im Benutzerspeicher zu sammeln, um sie nach eigenem Ermessen zu verwenden. Er sagt, dass das Sammeln von Entropie kein Prozess ist, der vom Kernel auf allen unterstĂŒtzten Hardware-GerĂ€ten durchgefĂŒhrt werden kann, auĂerdem kann der Kernel selbst nicht einschĂ€tzen, wie viel Entropie von verschiedenen Quellen bereitgestellt wird.
âDer Kernel sollte unterschiedliche GerĂ€uschquellen nicht zusammenmischen, und er sollte natĂŒrlich nicht versuchen zu behaupten, zu wissen, wie viele Bits Entropie er erhĂ€lt, wenn er versucht, ein gewisses âzerrĂŒttetes Entropiespielâ auf einer erschreckend einfachen CPU-Architektur fĂŒr BenutzerfĂ€lle im IOT/Embedded zu spielen, wenn alles mit einem einzigen Mastergenerator unsynchronisiert ist, wenn es keinen Befehl der CPU zum Umordnen oder Umbenennen von Registern gibt usw.â
âMan kann ĂŒber die Bereitstellung von Werkzeugen sprechen, die versuchen, diese Berechnungen anzustellen, aber solche Dinge sollten auf der Hardware jedes Benutzers stattfinden, was fĂŒr die meisten Benutzer des Distributionspakets einfach unpraktisch ist. Wenn dies jedoch nur fĂŒr Kryptographen gedacht ist, dann lassen Sie es in ihrem Benutzerraum geschehen. Und lassen Sie uns GPG, OpenSSL usw. nicht vereinfachen, damit alle sagen: âWir wollen âechte ZufĂ€lligkeitâ und akzeptieren nichts weniger.â Man kann darĂŒber sprechen, wie wir Schnittstellen fĂŒr Kryptographen bereitstellen, damit sie die benötigten Informationen durch den Zugang zu primĂ€ren GerĂ€uschquellen, die getrennt und benannt sind, erhalten können, und vielleicht kann sich die GerĂ€uschquelle irgendwie in der Bibliothek oder Anwendung des Benutzerraums authentifizieren.â
Es gab eine kleine Diskussion darĂŒber, wie eine solche Schnittstelle aussehen könnte, denn beispielsweise können einige Ereignisse Sicherheitsfolgen haben. Cao bemerkte, dass die Codes zum Scannen von Tastaturen (d.h. Tastendrucke) in einen Pool gemischt werden als Teil der Entropiesammlung: âDas in den Benutzerraum zu verlagern, selbst ĂŒber einen privilegierten Systemaufruf, wĂ€re zumindest unklug.â Es ist durchaus möglich, dass andere Zeitereignisse irgendwie Informationsleckagen ĂŒber SeitenkanĂ€le verursachen könnten.
So entsteht das GefĂŒhl, dass das seit langem bestehende Problem des Linux-Zufallszahlensubsystems auf dem Weg zur Lösung ist. Die Ănderungen, die das Zufallszahlensystem in letzter Zeit durchlaufen hat, fĂŒhrten tatsĂ€chlich nur zu DoS-Problemen wĂ€hrend seiner Nutzung. Jetzt gibt es jedoch effektive Wege, um die besten Zufallszahlen zu erhalten, die der Kernel bieten kann. Wenn TRNG weiterhin fĂŒr Linux wĂŒnschenswert ist, muss dieses Manko in Zukunft behoben werden, aber wahrscheinlich wird dies nicht im Kern selbst geschehen.
Ein wenig Werbung đ
Danke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? Möchten Sie mehr interessante Inhalte sehen? UnterstĂŒtzen Sie uns, indem Sie eine Bestellung aufgeben oder uns Freunden empfehlen, , ein einzigartiges Ăquivalent zu Einsteigerservern, das wir fĂŒr Sie entwickelt haben: (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verfĂŒgbar).
Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so gĂŒnstig? Nur bei uns in den Niederlanden! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â ab $99! Lesen Sie, wie
Quelle: habr.com
