Wer schon einmal auf einem Embedded-System wie Router oder einer VM versucht hat einen geheimen Schlüssel unter Linux zu erzeugen wird das kennen: Es dauert ewig. Schuld daran ist nicht nur die meist spartanische Leistung des Prozessors, sondern auch die Art, mit welcher Linux seine Zufallsdaten erzeugt.
Wie Zufällig darf es denn sein?
Holen wir mal etwas aus: Viele Verschlüsselungen benötigen – beispielsweise zur Erstellung von Schlüsseln – Zufallswerte. Leider ist ein PC mit seinen An-Aus recht vorhersagbar und das genaue Gegenteil von Zufall. Um trotzdem verschlüsseln zu können kommen Pseudozufallsgeneratoren zum Einsatz. Diese verwenden meist schlecht vorhersagbare Quellen um eine hohe Qualität der Zufallszahlen zu erreichen – also eine Zahl, deren Herleitung man möglichst später nicht mehr nachvollziehen kann. Quelle kann Beispielsweise das Rauschen eines Gerätes, vergleichbar mit einem zu laut eingestellten Eingangs einer Soundkarte, sein.
Von vollen und von leeren Pools
Unter Linux kümmert sich der Kernel selbst um die Sammlung dieses Zufalls, diesen verwaltet er im Entropiepool. Üblicherweise werden maximal 4096 Bit vorgehalten, den aktuellen Füllstand kann man unter /proc/sys/kernel/random/entropy_avail einsehen. Um Zufallszahlen zu erhalten gibt es nun zwei Geräte mit den selben Aufgaben, aber wichtigen Unterschieden:
/dev/random stellt die Daten aus dem Pool zur Verfügung und dabei sicher, dass die Daten eine gewisse Qualität haben. Das bedeutet allerdings auch, dass – wenn die 4096bit aufgebraucht sind – das Lesen so lange pausiert wird, bis neue Zufallswerte vorliegen. Das ist Ideal für Verschlüsselungen und andere kritische Bereiche in denen sensible Daten behandelt werden sollen. Gleichzeitig heißt es auch, dass Systeme mit geringer Nutzung entsprechend lange zum Lesen benötigen. Häufig wird empfohlen für Fesplatten- oder Netzlast zu sorgen oder Maus und Tastatur intensiv zu nutzen um zusätzlichen Zufall zu generieren, ob dies tatsächlich auch für den Linux RNG hilft oder nur einen Placeboeffekt darstellt ist mir nicht bekannt.
/dev/urandom stellt die selben Daten bereit, blockiert allerdings nicht. Hierbei macht man sich eine Eigenheit eines Zufalls zu Nutze: Die Zufallswerte sind nicht wie ein Treibstoff, der durch Nutzung verbrannt wird, sondern eher das geschriebene Wort eines Füllers. Ist die Quelle des Zufalls langsam erschöpft, also die Tinte fast leer, sieht das Geschriebene nicht mehr schön aus, ist aber immer noch deutlich besser als Nichts. Je länger man jedoch mit leerer Patrone schreibt, desto schlechter wird das Ergenis. Aber zurück: Ist der Pool also leer werden die übrigen Daten nochmal in die Mangel genommen und neu gemischt um zumindest irgendwas zu haben. Ganz nach dem Motto: Egal wie, es kommt etwas raus. Die Qualität der herauspurzelnden Werte ist – wie oben schon angerissen – nicht garantiert, vor allem bei leerem Pool und wenig Aktivität steigt die Gefahr, dass die Werte nachvollziehbar werden. Für wichtige Crypto sollte man urandom entsprechend nicht benutzen, reicht aber „etwas Zufall“ aus – beispielsweise um Werte für ein Spiel oder das testen einer Festplatte zu erhalten – ist man hier richtig und kann viel Zeit sparen. Auch kann es als „letzter Ausweg“ genutzt werden, wenn Zeit wichtiger ist als Sicherheit – oder soll der Kunde des Onlineshops mehrere Minuten beim Laden warten, weil grade der Pool leer ist?
Programmdiktatur
Während man als Programmierer die Wahl zwischen den Qualitäten hat ist man als Nutzer meist den Entscheidungen des Programmierers ausgeliefert. Dies macht auch meist Sinn, beispielsweise wenn das Cryptoprotokoll auf dem blockierenden /dev/random beharrt. Arbeitet man jedoch beispielsweise auf einem Testsystem und muss hunderte Schlüssel erzeugen, die ohnehin nur unwichtige Testdaten verarbeiten, wäre ein umschalten auf /dev/urandom hilfreich. Sicher, man könnte den Symlink verbiegen, aber wirklich schön ist das nicht.
Mittelweg Füllhilfen
Eine Lösung kann ein zusätzlicher Zufallsgenerator sein, welcher als weitere Quelle die Füllung des Entropiepools beschleunigen kann. Eine Möglichkeit ist es – wenn vorhanden – die Hardware zu bemühen. Viele aktuelle Rechner haben einen Zusallsgenerator eingebaut, beispielsweise unterstützen Intel-CPUs mit DRNG entsprechende funktionen oder auch das vielfach verbaute TPM-Modul kann hierzu verwendet werden. Nutzer von QEmu können mit virtio_rng auch virtuelle Rechner versorgen. Nutzbar machen lässt sich dies über den rngd, welcher als Dienst gestartet die Vermittlung übernimmt und meist in einem Paket namens rng-tools o.Ä. zu finden ist. Die Gefahr, dass die Hardwareimplementierung eine Lücke hat besteht natürlich immer, denn diese Quellen sind meist fest verdrahtet und Lücken im Algorithmus können nicht „weggepatched“ werden. Auch liegen die Details der Implementierung häufig nicht offen, sodass die Qualität der Zahlen nicht prüfbar ist. Um hier zumindest ein grundsätzliches Fallnetz zu ziehen wird rngd in der Standardeinstellung nur anteilmäßig zur Generierung der Zahlen genutzt.
Steht keine Hardware zur Verfügung, beispielsweise in vielen VM-Umgebungen, ist es auch in Software möglich. Der bekannteste Vertreter ist hierbei haveged. Hierbei wird sich zu nutze gemacht, dass der Prozessor intern einige Operationen durchführt, welche nicht vorhersagbar erscheinen. Der Vorteil: Diese Quelle ist auf jedem Rechner verfügbar – vom normalen PC bis hin zum kleinsten Router. Problem: Nicht jeder Prozessor ist „gleich zufällig“, ob die Qualität also hoch ist lässt sich nur schwer bestimmen.
Pest oder Cholera?
Welchen Weg man wählt, dass muss man für sich selbst entscheiden. Lange Wartezeiten ergeben zwar meist eine höhere Sicherheit, aber in der heutigen Zeit zählen all zu oft andere Werte. Viele Nutzer sind nicht bereit ihen Komfort für Sicherheit zu opfern. Ein Hardware-RNG kann – wenn vorhanden und man der Quelle genug vertraut – eine große Hilfe sein. Auch Software ist als Ausweg eine Option. Am Ende lässt sich Zufall jedoch nie testen, die Qualität der einzelnene Lösungen ist also nur schwer zu bewerten. Am Ende ist es meist eine gute Idee mehrere Quellen zu nutzen und so den Zufall des Zufalls nicht ganz dem Zufall zu überlassen.