/dev/random, ein kryptografisch sicherer Pseudozufallszahlengenerator (CSPRNG), hat bekanntermaßen ein lästiges Problem: das Blockieren. In diesem Artikel wird erläutert, wie Sie das Problem lösen können.
In den letzten Monaten wurden die Funktionen zur Generierung von Zufallszahlen im Kernel leicht überarbeitet, im weiteren Verlauf wurden jedoch Probleme in diesem Subsystem behoben . Am meisten wurden erstellt, um zu verhindern, dass der Systemaufruf getrandom() beim Systemstart längere Zeit blockiert. Der eigentliche Grund dafür war jedoch das Blockierungsverhalten des Zufallspools. Ein aktueller Patch hätte diesen Pool entfernt und man hätte erwartet, dass er sich in Richtung des Hauptkerns bewegt.
Andy Lutomirski veröffentlichte Ende Dezember die dritte Version des Patches. Er trägt dazu bei „zwei große semantische Änderungen an zufälligen Linux-APIs“. Der Patch fügt dem Systemaufruf getrandom() ein neues Flag GRND_INSECURE hinzu (obwohl Lutomirsky es als getentropy() bezeichnet, was in Glibc mithilfe von getrandom() mit festen Flags implementiert wird); Dieses Flag bewirkt, dass der Aufruf immer die angeforderte Datenmenge zurückgibt, ohne jedoch zu garantieren, dass die Daten zufällig sind. Der Kernel wird einfach sein Bestes tun, um die besten Zufallsdaten zu erzeugen, die ihm zum gegebenen Zeitpunkt zur Verfügung stehen. „Wahrscheinlich ist es am besten, es ‚UNSICHER‘ zu nennen. (unsicher), um zu verhindern, dass diese API für Dinge verwendet wird, die Sicherheit erfordern.“
Die Patches entfernen auch den Blocking-Pool. Der Kernel unterhält derzeit zwei Zufallsdatenpools, einer entspricht /dev/random und der andere /dev/urandom, wie hier beschrieben 2015. Der Blockierungspool ist der Pool für /dev/random; Lesevorgänge für dieses Gerät werden blockiert (also seinen Namen), bis „genug“ Entropie vom System gesammelt wurde, um die Anforderung zu erfüllen. Weitere Lesevorgänge aus dieser Datei werden ebenfalls blockiert, wenn im Pool nicht genügend Entropie vorhanden ist.
Das Entfernen des Sperrpools bedeutet, dass sich das Lesen von /dev/random wie getrandom() verhält, wobei die Flags auf Null gesetzt sind (und das GRND_RANDOM-Flag in einen Noop verwandelt). Sobald der kryptografische Zufallszahlengenerator (CRNG) initialisiert ist, werden das Lesen von /dev/random und Aufrufe von getrandom(...,0) nicht blockiert und die angeforderte Menge an Zufallsdaten wird zurückgegeben.
Lutomirsky sagt: „Ich glaube, dass der Linux-Blocking-Pool veraltet ist. CRNG Linux generiert eine Ausgabe, die gut genug ist, um sogar für die Schlüsselgenerierung verwendet zu werden. Der Blocking-Pool ist in keiner materiellen Hinsicht stärker und erfordert eine Menge Infrastruktur von zweifelhaftem Wert, um ihn zu unterstützen.“
Die Änderungen wurden mit dem Ziel vorgenommen, sicherzustellen, dass bestehende Programme nicht wirklich beeinträchtigt werden und es tatsächlich weniger Probleme mit langen Wartezeiten für Dinge wie die Generierung von GnuPG-Schlüsseln gibt.
„Diese Episoden dürfen keine bestehenden Programme stören. /dev/urandom bleibt unverändert. /dev/random blockiert immer noch sofort beim Booten, aber es blockiert weniger als zuvor. getentropy() mit den vorhandenen Flags wird ein Ergebnis zurückgeben, das für praktische Zwecke genauso geeignet ist wie zuvor.“
Lutomirsky bemerkte, dass es immer noch eine offene Frage sei, ob der Kernel sogenannte „echte Zufallszahlen“ bereitstellen sollte, was der blockierende Kernel in gewissem Umfang tun sollte. Er sieht dafür nur einen Grund: „Einhaltung staatlicher Standards.“ Lutomirsky schlug vor, dass, wenn der Kernel dies bereitstellen würde, dies über eine völlig andere Schnittstelle erfolgen oder in den Benutzerbereich verschoben werden sollte, damit der Benutzer rohe Ereignisbeispiele abrufen kann, die zum Erstellen eines solchen Sperrpools verwendet werden könnten.
Stephan Müller schlug sein Set vor für Linux Random Number Generator (LRNG) (derzeit Version 26 veröffentlicht) könnte eine Möglichkeit sein, echte Zufallszahlen für Anwendungen bereitzustellen, die diese benötigen. LRNG ist „vollständig konform mit den SP800-90B-Richtlinien für Entropiequellen zur Generierung von Zufallsbits“ und stellt damit eine Lösung für das Problem der Regierungsstandards dar.
Matthew Garrett lehnte den Begriff „echte Zufallsdaten“ ab und stellte fest, dass die untersuchten Geräte im Prinzip präzise genug modelliert werden könnten, um sie vorhersehbar zu machen: „Wir erfassen hier keine Quantenereignisse.“
Müller entgegnete, der Begriff stamme aus dem deutschen Standard AIS 31 und beschreibe einen Zufallszahlengenerator, der nur „in der gleichen Geschwindigkeit ein Ergebnis liefert, wie die zugrunde liegende Rauschquelle Entropie produziert“.
Abgesehen von den terminologischen Unterschieden führt ein Lock-Pool, wie er in den LRNG-Patches vorgeschlagen wird, einfach zu verschiedenen Problemen, zumindest wenn darauf ohne Privilegien zugegriffen wird.
Wie Lutomirsky sagte: „Das löst das Problem nicht. Wenn zwei verschiedene Benutzer dumme Programme wie gnupg ausführen, belasten sie sich gegenseitig. Ich sehe, dass es derzeit zwei Hauptprobleme mit /dev/random gibt: Es ist anfällig für DoS (d. h. Ressourcenverschwendung, böswilliger Einfluss oder ähnliches) und da für die Verwendung keine Berechtigungen erforderlich sind, ist es auch anfällig für Missbrauch. Gnupg ist falsch, es ist ein völliger Zusammenbruch. Wenn wir eine neue unprivilegierte Schnittstelle hinzufügen, die von gnupg und ähnlichen Programmen verwendet wird, werden wir erneut verlieren.“
Müller wies darauf hin, dass die Hinzufügung von getrandom() es GnuPG nun ermöglichen wird, diese Schnittstelle zu verwenden, da sie die notwendige Garantie dafür bietet, dass der Pool initialisiert wurde. Basierend auf Gesprächen mit dem GnuPG-Entwickler Werner Koch glaubt Mueller, dass die Garantie der einzige Grund ist, warum GnuPG derzeit direkt von /dev/random liest. Aber wenn es eine unprivilegierte Schnittstelle gibt, die anfällig für Denial-of-Service ist (wie es heute bei /dev/random der Fall ist), argumentiert Lutomirsky, dass sie von einigen Anwendungen missbraucht wird.
Theodore Yue Tak Ts'o, Entwickler des Linux-Zufallszahlen-Subsystems, scheint seine Meinung über die Notwendigkeit eines Blockierungspools geändert zu haben. Er sagte, dass durch das Entfernen dieses Pools die Vorstellung, dass Linux über einen echten Zufallszahlengenerator (TRNG) verfügt, effektiv beseitigt würde: „Das ist kein Unsinn, denn genau das hat *BSD immer getan.“
Er befürchtet auch, dass die Bereitstellung eines TRNG-Mechanismus lediglich als Köder für Anwendungsentwickler dienen wird, und glaubt, dass es angesichts der verschiedenen von Linux unterstützten Hardwaretypen tatsächlich unmöglich ist, TRNG im Kernel zu garantieren. Selbst die Möglichkeit, mit Geräten nur mit Root-Rechten zu arbeiten, wird das Problem nicht lösen: „Anwendungsentwickler legen aus Sicherheitsgründen fest, dass ihre Anwendung als Root installiert wird, damit nur so auf die ‚wirklich guten‘ Zufallszahlen zugegriffen werden kann.“
Mueller fragte, ob Cao die von ihm selbst seit langem vorgeschlagene Einführung eines Blocking-Pools aufgegeben habe. Cao antwortete, dass er vorhabe, Lutomirskys Patches zu übernehmen und sich aktiv gegen das Hinzufügen einer blockierenden Schnittstelle zum Kernel ausspreche.
„Der Kernel kann keine Garantien dafür geben, ob die Rauschquelle ordnungsgemäß charakterisiert wurde. Das Einzige, was ein GPG- oder OpenSSL-Entwickler bekommen kann, ist ein vages Gefühl, dass TRUERANDOM „besser“ ist, und da er mehr Sicherheit möchte, wird er zweifellos versuchen, es zu verwenden. Irgendwann wird es blockiert, und wenn ein anderer kluger Benutzer (vielleicht ein Distributionsspezialist) es in das Init-Skript einfügt und die Systeme nicht mehr funktionieren, müssen sich Benutzer nur noch bei Linus Torvalds selbst beschweren.“
Cao plädiert außerdem dafür, Kryptografen und denjenigen, die TRNG tatsächlich benötigen, eine Möglichkeit zu geben, ihre eigene Entropie im Benutzerraum zu sammeln und sie nach eigenem Ermessen zu nutzen. Er sagt, dass das Sammeln von Entropie kein Prozess ist, der vom Kernel auf der gesamten unterstützten Hardware durchgeführt werden kann, und dass der Kernel selbst auch nicht die Menge an Entropie schätzen kann, die von verschiedenen Quellen bereitgestellt wird.
„Der Kernel sollte nicht verschiedene Rauschquellen miteinander vermischen, und er sollte auf keinen Fall behaupten zu wissen, wie viele Entropiebits er erhält, wenn er versucht, eine Art „zuckendes Entropiespiel“ auf einer unglaublich einfachen CPU zu spielen Architektur für Verbraucheranwender. IOT/Embedded-Fälle, in denen alles nicht synchron mit einem einzelnen Master-Oszillator ist, in denen es keinen CPU-Befehl zum Neuordnen oder Umbenennen eines Registers usw. gibt.“
„Man kann über die Bereitstellung von Tools sprechen, die versuchen, diese Berechnungen durchzuführen, aber solche Dinge müssen auf der Hardware jedes Benutzers durchgeführt werden, was für die meisten Distributionsbenutzer einfach nicht praktikabel ist. Wenn dies nur für Kryptographen gedacht ist, dann lassen Sie es in ihrem Benutzerbereich geschehen. Und vereinfachen wir GPG, OpenSSL usw. nicht so, dass jeder sagt: „Wir wollen „echte Zufälligkeit“ und geben uns nicht mit weniger zufrieden.“ Wir können darüber sprechen, wie wir Kryptographen Schnittstellen bereitstellen, damit sie die Informationen erhalten, die sie benötigen, indem sie auf die primären Rauschquellen zugreifen, getrennt und benannt, und vielleicht kann sich die Rauschquelle irgendwie gegenüber einer Bibliothek oder einer User-Space-Anwendung authentifizieren.“
Es gab einige Diskussionen darüber, wie eine solche Schnittstelle aussehen könnte, da sie beispielsweise Auswirkungen auf die Sicherheit einiger Ereignisse haben könnte. Cao bemerkte, dass Tastatur-Scan-Codes (d. h. Tastenanschläge) als Teil der Entropiesammlung in einen Pool gemischt werden: „Es wäre gelinde gesagt unklug, dies in den Benutzerbereich zu bringen, selbst über einen privilegierten Systemaufruf.“ Es ist durchaus möglich, dass andere Ereigniszeitpunkte zu Informationslecks über Nebenkanäle führen.
Es sieht also so aus, als ob ein seit langem bestehendes Problem mit dem Zufallszahlen-Subsystem von Linux auf dem Weg zur Lösung ist. Die kürzlich vorgenommenen Änderungen am Zufallszahlen-Subsystem haben eigentlich nur zu DoS-Problemen bei der Nutzung geführt. Jetzt gibt es effiziente Möglichkeiten, die besten Zufallszahlen zu erhalten, die der Kernel bereitstellen kann. Wenn TRNG unter Linux immer noch wünschenswert ist, muss dieser Fehler in Zukunft behoben werden, aber höchstwahrscheinlich wird dies nicht im Kernel selbst geschehen.
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com