Wie bekannt ist, hat /dev/random, der kryptographisch sichere 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 Erzeugung von Zufallszahlen im Kernel leicht überarbeitet, jedoch wurden Probleme in diesem Teilsystem über einen längeren Zeitraum hinweg behandelt. . Die neuesten wurden vorgenommen, um die lange Blockierung des Systemaufrufs getrandom() beim Systemstart zu verhindern, wobei die Ursache dafür das Verhalten des blockierenden Zufalls-Pools war. Ein kürzlicher Patch hat diesen Pool entfernt, und es wird erwartet, dass er ins Haupt-Branch übergeht.
Andy Lutomirski hat Ende Dezember die dritte Version des Patches veröffentlicht. Er bringt „zwei grundlegende semantische Änderungen an den Zufalls-APIs von Linux“.. Der Patch fügt einen neuen Flag GRND_INSECURE zum Systemaufruf getrandom() hinzu (obwohl Lutomirski ihn als getentropy() bezeichnet, das in glibc mit festgelegten Flags durch getrandom() 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 verfügbaren zufälligen Daten zu liefern, die er zu diesem Zeitpunkt hat. „Wahrscheinlich ist es am besten, es als 'INSECURE' zu bezeichnen, (unsicher), um die Verwendung dieser API für Dinge zu verhindern, die Sicherheit erfordern.“
Die Patches entfernen auch den blockierenden Pool. Der Kernel unterstützt derzeit zwei Pools zufälliger Daten, von denen einer /dev/random und der andere /dev/urandom entspricht, wie in diesem 2015 beschrieben. Der blockierende Pool ist ein Pool für /dev/random; das Lesen von diesem Gerät wird blockiert (was mit seinem Namen gemeint ist), bis im System genügend „Entropie“ gesammelt wurde, um die Anfrage zu erfüllen. Weitere Lesevorgänge aus dieser Datei werden ebenfalls blockiert, wenn im Pool nicht genügend Entropie vorhanden ist.
Das Entfernen des Blocking-Pools bedeutet, dass das Lesen aus /dev/random sich wie getrandom() verhält, wobei der Wert der Flags Null ist (und das FLAG GRND_RANDOM zu noop wird). Nach der Initialisierung des kryptographischen 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.
Lutomirsky sagt: „Ich glaube, dass der blockierende Pool in Linux überholt ist. Der CRNG in Linux erzeugt Ausgaben, die gut genug sind, um sie sogar für die Generierung von Schlüsseln zu verwenden. Der blockierende Pool ist in keiner materiellen Hinsicht stärker, und für seine Aufrechterhaltung wird viel Infrastruktur von fraglichem Wert benötigt.“
Die Änderungen wurden mit dem Ziel vorgenommen, dass bestehende Programme tatsächlich nicht betroffen sind, und tatsächlich wird es weniger Probleme mit langen Wartezeiten bei Dingen wie der Generierung von GnuPG-Schlüsseln geben.
«Diese Serien dürfen keine bestehenden Programme stören. /dev/urandom bleibt unverändert. /dev/random blockiert weiterhin sofort nach dem Booten, aber weniger als zuvor. getentropy() mit den bestehenden Flags wird ein Ergebnis zurückgeben, das für praktische Zwecke ebenso geeignet ist wie zuvor».
Lutomirski betonte, dass die Frage, ob der Kernel sogenannte „echte Zufallszahlen“ bereitstellen sollte, weiterhin offen bleibt, was in gewissem Maße von dem blockierenden Kernel erwartet wurde. Er sieht dafür nur einen Grund: „Einhaltung staatlicher Standards“. Lutomirski schlug vor, dass, wenn der Kernel dies bereitstellen muss, es über eine ganz andere Schnittstelle erfolgen oder in den Benutzerspeicher verlagert werden sollte, um ihm die Möglichkeit zu geben, rohe Ereignisproben zu extrahieren, die zur Erstellung eines solchen Blockierungspools verwendet werden können.
Stephan Müller schlug vor, dass sein Set Der Linux-Zufallszahlengenerator (LRNG) (derzeit in Version 26 verfügbar) kann 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 Erzeugung von Zufallsbits" SP800-90B, wodurch es eine Lösung für staatliche Standards darstellt.
Matthew Garrett hat den Begriff "echte Zufallsdaten" in Frage gestellt und darauf hingewiesen, dass die ausgewählten Geräte grundsätzlich so genau modelliert werden können, dass sie vorhersehbar sind: "Hier selektieren wir keine quantenmechanischen Ereignisse."
Müller antwortete, dass dieser Begriff aus dem deutschen Standard AIS 31 stammt, der einen Zufallszahlengenerator beschreibt, der nur Ergebnisse mit der gleichen Geschwindigkeit ausgibt, mit der die Basisrauschquelle Entropie produziert.
Abgesehen von terminologischen Missverständnissen wird die Existenz eines Lockpools, wie sie in den LRNG-Patches vorgeschlagen wird, einfach zu verschiedenen Problemen führen, zumindest wenn er ohne Berechtigungen zugänglich ist.
Wie Lutomirski sagte: «Это не решает проблему. Если два разных пользователя запускают глупые программы, такие как gnupg, они просто истощат друг друга. Я вижу, что в настоящее время существуют две основные проблемы с /dev/random: он склонен к DoS (т. е. истощению ресурсов, вредоносному влиянию или чему-то подобному), и, поскольку никаких привилегий для его использования не требуется, он также склонен к злоупотреблениям. Gnupg — это неправильно, это полный коллапс. Если мы добавим новый непривилегированный интерфейс, который будут использовать gnupg и аналогичные программы, мы снова проиграем».
Müller erklärte, dass die Hinzufügung von getrandom() GnuPG nun ermöglichen wird, diese Schnittstelle zu nutzen, da sie die notwendige Gewährleistung bietet, dass der Pool initialisiert wurde. Basierend auf Diskussionen mit dem GnuPG-Entwickler Werner Koch hält Müller die Gewährleistung für den einzigen Grund, warum GnuPG derzeit direkt aus /dev/random liest. Wenn jedoch eine nicht privilegierte Schnittstelle existiert, die anfällig für DoS-Angriffe ist (wie heute /dev/random), könnte sie laut Lutomirski von einigen Anwendungen falsch verwendet werden.
Theodore Yue Tak Ts’o, Entwickler des Linux-Zufallsunterystems, scheint seine Meinung zur Notwendigkeit eines blockierenden Pools geändert zu haben. Er sagte, dass die Entfernung dieses Pools die Idee, dass Linux einen echten Zufallszahlengenerator (TRNG) hat, effektiv beseitigen würde. „Es ist kein Unsinn, denn genau das haben die *BSD-Varianten immer gemacht."
Er ist auch besorgt, dass die Bereitstellung eines TRNG-Mechanismus nur als Köder für Anwendungsentwickler dienen wird, und er glaubt, dass es angesichts der verschiedenen Arten von Hardware, die von Linux unterstützt werden, unmöglich ist, TRNG im Kernel zu garantieren. Das Problem wird nicht einmal durch die Möglichkeit gelöst, ausschließlich mit Root-Rechten auf die Hardware zuzugreifen. „Anwendungsentwickler geben an, dass ihre Anwendung aus Sicherheitsgründen als Root installiert werden sollte, denn nur so können Sie auf 'wirklich gute' Zufallszahlen zugreifen.“
Müller fragte, ob Cao von der Umsetzung des von ihm selbst lange vorgeschlagenen blockierenden Pools Abstand genommen habe. Cao antwortete, dass er plant, die Patches von Lutomirskyi zu übernehmen und sich aktiv gegen die Wiedereinführung einer blockierenden Schnittstelle in den Kernel auszusprechen.
«Der Kernel kann keine Garantien dafür geben, ob die Noise-Source ordnungsgemäß charakterisiert wurde. Das Einzige, was der Entwickler von GPG oder OpenSSL erhalten kann, ist ein vages Gefühl, dass TRUERANDOM „besser“ ist, und da sie mehr Sicherheit wollen, werden sie mit Sicherheit versuchen, es zu verwenden. Irgendwann wird es blockiert, und wenn ein anderer kluger Nutzer (möglicherweise ein Distribution Release Spezialist) es in ein Init-Skript einfügt und die Systeme nicht mehr funktionieren, bleibt den Nutzern nur, sich direkt an Linus Torvalds zu wenden.«
Cao plädiert auch dafür, Kryptographen und denjenigen, die wirklich TRNG benötigen, eine Möglichkeit zu geben, ihre eigene Entropie im Benutzerspeicher zu sammeln, um diese nach Belieben zu verwenden. Er sagt, dass die Entropiesammlung kein Prozess ist, der vom Kernel auf sämtlichen unterstützten Hardware-Plattformen durchgeführt werden kann, zudem kann der Kernel selbst nicht einschätzen, wie viel Entropie von den verschiedenen Quellen bereitgestellt wird.
„Der Kern sollte verschiedene Rauschquellen nicht vermischen und kann natürlich nicht behaupten, zu wissen, wie viel Bit Entropie er erhält, wenn er versucht, ein 'zickiges Entropiespiel' auf einer schrecklich einfachen CPU-Architektur für Benutzeranwendungen im IOT/Embedded-Bereich zu spielen, wenn alles mit einem einzigen Master-Generator unsynchronisiert ist und es keine CPU-Anweisungen zum Neuanordnen oder Umbenennen von Registern gibt und so weiter.“
„Man kann über die Bereitstellung von Werkzeugen sprechen, die versuchen, diese Berechnungen durchzuführen, aber solche Dinge sollten auf der Hardware jedes Benutzers stattfinden, was für die meisten Benutzer des Verteilers einfach unpraktisch ist. Wenn dies jedoch nur für Kryptographen gedacht ist, dann soll es in ihrem Benutzerraum erfolgen. Lassen Sie uns GPG, OpenSSL usw. nicht vereinfachen, damit alle sagen können: „Wir wollen „wahre 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 Zugriff auf primäre Geräuschquellen erhalten, die getrennt und benannt sind, und vielleicht wird diese Geräuschquelle sich irgendwie in der Bibliothek oder Anwendung des Benutzerraums authentifizieren können.“
Es gab eine kurze Diskussion darüber, wie eine solche Benutzeroberfläche aussehen könnte, da beispielsweise einige Ereignisse sicherheitsrelevante Konsequenzen haben können. Cao merkte an, dass die Codes für Tastatureingaben (also die Tastendrucker) in einen Pool zur Entropieerzeugung gemischt werden: „Es wäre zumindest unklug, dies in den Benutzermodus zu übertragen, selbst über einen privilegierten Systemaufruf“. Es ist durchaus möglich, dass auch andere Zeitereignisse Informationslecks über Nebenkanäle erzeugen können.
Damit entsteht der Eindruck, dass das langjährige Problem der Zufallszahlensubsysteme in Linux auf dem Weg zur Lösung ist. Die Änderungen, die das Zufallszahlensubsystem kürzlich durchlaufen hat, führten in der Vergangenheit tatsächlich nur zu DoS-Problemen bei der Nutzung. Jetzt gibt es jedoch effektive Methoden, um die besten Zufallszahlen zu erhalten, die der Kernel bieten kann. Sollte ein TRNG für Linux weiterhin wünschenswert sein, muss dieses Manko in Zukunft behoben werden; wahrscheinlich wird es jedoch nicht innerhalb des Kernels 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 Ihren Freunden empfehlen. , eine einzigartige Alternative zu Einsteiger-Servern, die wir für Sie entwickelt haben: (Verfügbar sind Optionen mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40GB DDR4).
Dell R730xd im Equinix Tier IV Rechenzentrum in Amsterdam zum halben Preis? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab 99 $! Lesen Sie darüber
Quelle: habr.com
