Wie Sie wissen, hat / dev / random, ein kryptografisch starker Pseudozufallszahlengenerator (CSPRNG), ein unangenehmes Problem - das Blockieren. Dieser Artikel beschreibt, wie man es löst.
In den letzten Monaten wurden die Mittel zur Erzeugung von Zufallszahlen im Kernel leicht überarbeitet, die Probleme in diesem Subsystem wurden jedoch über einen längeren
Zeitraum hinweg gelöst. Die
letzten Änderungen wurden vorgenommen, um zu verhindern, dass der Systemaufruf getrandom () während des Systemstarts für längere Zeit blockiert wird. Der Grund dafür war jedoch das Verhalten des blockierenden zufälligen Pools. Ein neuer Patch würde diesen Pool entfernen und sollte voraussichtlich zum Hauptkern gehen.
Andy Lutomirski veröffentlichte Ende Dezember die dritte Version des Patches. Es nimmt
"zwei grundlegende semantische Änderungen an den zufälligen Linux-APIs vor". Der Patch fügt dem Systemaufruf getrandom () das neue Flag GRND_INSECURE hinzu (obwohl Lutomirsky es als getentropy () bezeichnet, das in glibc mithilfe von getrandom () mit festen Flags implementiert wird). Dieses Flag erzwingt, 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 liefern, die er zu einem bestimmten Zeitpunkt hat.
"Wahrscheinlich ist das Beste, was Sie tun können, es" INSECURE " (unsicher) zu nennen, um zu verhindern, dass es für Dinge verwendet wird, die Sicherheit benötigen."
Patches entfernen auch den blockierenden Pool. Derzeit unterstützt der Kernel zwei Pools von Zufallsdaten, von denen einer / dev / random und der andere / dev / urandom entspricht, wie in diesem
Artikel von 2015
beschrieben . Ein Blocking Pool ist ein Pool für / dev / random; Der Lesevorgang für dieses Gerät wird blockiert (dh sein Name), bis vom System eine ausreichende Entropie erfasst wurde, um die Anforderung zu erfüllen. Weitere Lesevorgänge aus dieser Datei werden ebenfalls blockiert, wenn nicht genügend Entropie im Pool vorhanden ist.
Das Entfernen des Sperrpools bedeutet, dass sich das Lesen von / dev / random wie getrandom () verhält, wobei der Flags-Wert auf Null gesetzt ist (und das Flag GRND_RANDOM in noop verwandelt). Nach der Initialisierung des kryptografischen Zufallszahlengenerators (CRNG) wird beim Lesen von / dev / random und Aufrufen von getrandom (..., 0) die angeforderte Menge an Zufallsdaten nicht blockiert und zurückgegeben.
Lutomirsky sagt:
„Ich glaube, der Linux-Blocking-Pool ist veraltet. CRNG Linux generiert eine Ausgabe, die selbst für die Schlüsselgenerierung gut genug ist. Der Sperrpool ist in keiner Weise stärker und erfordert viel Infrastruktur von zweifelhaftem Wert, um ihn zu erhalten. “Die Änderungen wurden mit dem Ziel vorgenommen, sicherzustellen, dass vorhandene Programme nicht wirklich darunter leiden. Tatsächlich werden Probleme mit dem langen Warten auf Dinge wie das Generieren von GnuPG-Schlüsseln kleiner.
„Diese Serien sollten keine bestehenden Programme verletzen. / dev / urandom bleibt unverändert. / dev / random blockiert immer noch direkt nach dem Laden, aber es blockiert weniger als zuvor. getentropy () mit vorhandenen Flags gibt ein Ergebnis zurück, das für den Zweck genauso praktisch ist wie zuvor. "Lutomirsky merkte an, dass die Frage offen bleibt, ob der Kern die sogenannten „wahren Zufallszahlen“ liefern sollte, was zum Teil vom blockierenden Kern hätte getan werden müssen. Er sieht dafür nur einen Grund: "Einhaltung staatlicher Standards." Lutomirsky schlug vor, dass der Kernel dies über eine völlig andere Schnittstelle bereitstellen oder in den Benutzerbereich übertragen sollte, damit er nicht verarbeitete Ereignismuster abrufen kann, die zum Erstellen eines solchen Sperrpools verwendet werden können.
Stephan Müller schlug vor, mit seinem
Patch- Set für den Linux-Zufallszahlengenerator (LRNG) (Version 26 ist derzeit verfügbar) echte Zufallszahlen für Anwendungen bereitzustellen, die diese benötigen. LRNG "entspricht in vollem Umfang den Anforderungen der" Empfehlungen zu den Entropiequellen für die Erzeugung von Zufallsbits "SP800-90B" und ist damit eine Lösung für das Problem der staatlichen Standards.
Matthew Garrett lehnte den Begriff "echte Zufallsdaten" ab und stellte fest, dass auswählbare Geräte im Prinzip so genau modelliert werden können, dass sie vorhersehbar sind: "Wir nehmen hier keine Quantenereignisse auf."
Müller antwortete, dass der Begriff aus dem deutschen Standard AIS 31 stammt, um einen Zufallszahlengenerator zu beschreiben, der nur das Ergebnis "mit der gleichen Geschwindigkeit erzeugt, mit der die zugrunde liegende Rauschquelle Entropie erzeugt".
Zusätzlich zu den Missverständnissen der Terminologie führt das Vorhandensein eines Sperrpools, wie von den LRNG-Patches vorgeschlagen, einfach zu verschiedenen Problemen, zumindest wenn er ohne Berechtigungen verfügbar ist.
Wie Lutomirsky sagte:
„Dies löst das Problem nicht. Wenn zwei verschiedene Benutzer dumme Programme wie gnupg ausführen, erschöpfen sie sich gegenseitig. Ich sehe, dass es derzeit zwei Hauptprobleme mit / dev / random gibt: Es ist anfällig für DoS (d. H. Ressourcenverbrauch, schädliche Einflüsse oder ähnliches), und da es keine Berechtigungen erfordert, um es zu verwenden, ist es auch Missbrauch unterworfen. Gnupg ist falsch, es ist ein völliger Zusammenbruch. Wenn wir eine neue nichtprivilegierte Schnittstelle hinzufügen, die Gnupg und ähnliche Programme verwenden, werden wir wieder verlieren. “Müller stellte fest, dass das Hinzufügen von getrandom () GnuPG nun die Verwendung dieser Schnittstelle ermöglicht, da dies die notwendige Garantie dafür bietet, dass der Pool initialisiert wurde. Aufgrund von Gesprächen mit dem GnuPG-Entwickler Werner Koch ist Müller der Ansicht, dass die Garantie der einzige Grund ist, warum GnuPG derzeit direkt aus / dev / random liest. Wenn es jedoch eine nichtprivilegierte Schnittstelle gibt, die einem Denial-of-Service (ab heute / dev / random) unterliegt, wird sie laut Lutomirsky von einigen Anwendungen missbraucht.
Theodore Yue Tak Ts'o, der Entwickler des Linux-Subsystems für Zufallszahlen, scheint seine Meinung über die Notwendigkeit eines Sperrpools geändert zu haben. Er sagte, dass das Löschen dieses Pools die Idee, dass Linux einen echten Zufallszahlengenerator (TRNG) hat, effektiv loswerden würde:
"Dies ist kein Unsinn, da dies genau das ist, was * BSD immer getan hat."Er ist auch besorgt darüber, dass die Bereitstellung des TRNG-Mechanismus lediglich als Lockmittel für Anwendungsentwickler dienen wird und glaubt, dass es angesichts der verschiedenen von Linux unterstützten Hardwaretypen in der Realität nicht möglich ist, TRNG im Kernel zu garantieren. Selbst die Möglichkeit, mit Geräten zu arbeiten, die auf Root-Rechten basieren, wird das Problem nicht lösen:
"Anwendungsentwickler geben aus Sicherheitsgründen an, dass ihre Anwendung als Root installiert wird, da nur so auf" wirklich gute "Zufallszahlen zugegriffen werden kann."Müller fragte, ob Cao sich geweigert habe, den von ihm selbst seit langem vorgeschlagenen Sperrpool umzusetzen. Cao erwiderte, dass er die Lutomirsky-Patches nehmen wolle und lehnte es aktiv ab, dem Kernel eine blockierende Schnittstelle hinzuzufügen.
„Der Kernel kann keine Garantie dafür geben, ob die Geräuschquelle ordnungsgemäß charakterisiert wurde. Das einzige, was ein GPG- oder OpenSSL-Entwickler bekommen kann, ist das vage Gefühl, dass TRUERANDOM "besser" ist, und da sie mehr Sicherheit wollen, werden sie zweifellos versuchen, es zu verwenden. Irgendwann wird es blockiert, und wenn ein anderer intelligenter Benutzer (vielleicht ein Distributionsspezialist) es in das Init-Skript einfügt und die Systeme nicht mehr funktionieren, müssen sich die Benutzer nur bei Linus Torvalds beschweren. “Cao befürwortet auch, Kryptographen und solchen, die TRNG wirklich benötigen, die Möglichkeit zu geben, ihre eigene Entropie im Benutzerbereich zu sammeln, damit sie sie nach Belieben verwenden können. Er sagt, dass die Entropieerfassung kein Prozess ist, der vom Kernel auf allen Arten von Hardware durchgeführt werden kann, die von ihm unterstützt werden. Außerdem kann der Kernel selbst den Entropiebetrag, der von verschiedenen Quellen bereitgestellt wird, nicht schätzen.
„Der Kernel sollte nicht verschiedene Rauschquellen miteinander mischen und natürlich nicht behaupten, er wisse, wie viele Entropiebits er erhält, wenn er versucht, ein für den hässlichen Benutzer einfaches„ ruckeliges Entropiespiel “auf einer CPU-Architektur zu spielen "IOT / Embedded-Fälle, in denen alles nicht mit einem einzelnen Master-Generator synchronisiert ist, wenn es keine CPU-Anweisung zum Umordnen oder Umbenennen des Registers usw. gibt."
„Wir können über die Bereitstellung von Tools sprechen, die versuchen, diese Berechnungen durchzuführen, aber solche Dinge sollten an der Ausrüstung jedes Benutzers durchgeführt werden, was für die meisten Benutzer des Distributionskits einfach unpraktisch ist. Wenn dies nur für Kryptografen gedacht ist, lassen Sie es in ihrem Benutzerbereich geschehen. Und lassen Sie uns GPG, OpenSSL usw. nicht vereinfachen, damit alle sagen: "Wir wollen" echte Zufälligkeit "und sind uns über nichts weniger einig." Wir können darüber sprechen, wie wir Kryptographen Schnittstellen bereitstellen, damit diese die erforderlichen Informationen über den Zugriff auf primäre, getrennte und benannte Rauschquellen erhalten und sich möglicherweise die Rauschquelle in einer Bibliothek oder einer Anwendung im Benutzerbereich authentifizieren kann. “Es wurde ein wenig darüber diskutiert, wie eine solche Schnittstelle aussehen könnte, da beispielsweise für einige Ereignisse Sicherheitsrisiken bestehen. Cao stellte fest, dass Tastatur-Scan-Codes (dh Tastatureingaben) im Rahmen der Entropiesammlung in den Pool gemischt werden: "Die Übertragung in den Benutzerraum, selbst durch einen privilegierten Systemaufruf, wäre zumindest unvernünftig." Es ist möglich, dass andere Ereignis-Timings eine Art Informationsleck über Seitenkanäle verursachen können.
Daher besteht das Gefühl, dass das langjährige Problem des Linux-Zufallszahlen-Subsystems auf dem Weg zu einer Lösung ist. Die Änderungen, die das Zufallszahlensubsystem in letzter Zeit vorgenommen hat, führten tatsächlich nur zu DoS-Problemen bei seiner Verwendung. Jetzt gibt es effektive Möglichkeiten, die besten Zufallszahlen zu ermitteln, die der Kernel bereitstellen kann. Wenn TRNG für Linux immer noch wünschenswert ist, muss dieses Manko in Zukunft behoben werden, aber höchstwahrscheinlich nicht im Kernel selbst.
Ein bisschen Werbung :)
Vielen Dank für Ihren Aufenthalt bei uns. Mögen Sie unsere Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden
Cloud-basiertes VPS für Entwickler ab 4,99 US-Dollar empfehlen, ein
einzigartiges Analogon zu Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit / s ab 19 Dollar oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).
Dell R730xd 2-mal billiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur wir haben
2 x Intel TetraDeca-Core Xeon 2 x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV ab 199 US-Dollar in den Niederlanden! Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie mehr über
das Erstellen von Infrastruktur-Bldg. Klasse mit Dell R730xd E5-2650 v4 Servern für 9.000 Euro für einen Cent?