Stellen Sie sich vor: Sie haben gerade ein dringend benötigtes Kernel-Update auf Ihrem Linux-System durchgeführt, starten neu und bemerken dann etwas Beunruhigendes. Der Wert für die „available entropy” – die Menge an verbleibender Zufälligkeit, die Ihr System zur Verfügung hat – ist drastisch gesunken, vielleicht sogar auf alarmierend niedrige Werte wie 60 oder 100 Bit. Panik macht sich breit! Ist Ihr System jetzt unsicher? Sind Ihre kryptografischen Schlüssel plötzlich schwach? Ist dies eine Sicherheitslücke?
Bevor Sie in puren Aktionismus verfallen und versuchen, manuell Entropy zu generieren, lassen Sie uns tief in das Thema eintauchen. Was auf den ersten Blick wie ein kritisches Sicherheitsproblem aussieht, ist in vielen modernen Linux-Installationen nach einem Kernel-Update (insbesondere ab Version 5.6) ein völlig normales und sogar gewolltes Verhalten, das im Gegenteil die **Sicherheit** und Stabilität Ihres Systems verbessert hat. Es ist an der Zeit, ein weit verbreitetes Missverständnis aufzuklären.
Was ist Entropy und warum ist sie so wichtig?
Im Kontext der Informatik ist Entropy (Entropie) ein Maß für die Unvorhersehbarkeit oder Zufälligkeit. Für kryptografische Zwecke benötigen Computersysteme echte Zufallszahlen. Diese sind entscheidend für eine Vielzahl von Sicherheitsfunktionen:
- Die Generierung von kryptografischen Schlüsseln (z. B. für SSH, TLS/SSL, VPNs).
- Die Erstellung von Sitzungs-IDs in Webanwendungen.
- Die Erzeugung von Initialisierungsvektoren (IVs) für Verschlüsselungsalgorithmen.
- Die Sicherstellung der Einmaligkeit von Nonces und Salzen.
- Schutz vor Replay-Angriffen und Brute-Force-Attacken.
Ohne ausreichende, hochqualitative Zufälligkeit wären diese Schutzmechanismen kompromittierbar. Ein Angreifer könnte potenziell die nächsten „zufälligen” Zahlen vorhersagen und somit Sicherheitsschlüssel oder andere kritische Werte erraten. Man spricht hier von einem Angriff auf den Zufallszahlengenerator (RNG), der verheerende Folgen haben kann.
Wie Linux Entropy sammelt und verwaltet
Linux-Systeme sammeln Entropy aus verschiedenen Quellen. Dies geschieht typischerweise durch Hardware-Ereignisse, die inhärent unvorhersehbar sind. Dazu gehören:
- Mausbewegungen und Tastatureingaben.
- Festplatten-I/O-Operationen.
- Netzwerkaktivitäten (Pakete, Interrupts).
- Prozess-Scheduling-Informationen.
- Die genauen Zeitpunkte von Hardware-Interrupts.
Diese gesammelten Daten werden in einem sogenannten „Entropy Pool” gesammelt. Der Kernel schätzt die Qualität dieser Zufälligkeit und speichert sie in einem Zähler ab, der über `/proc/sys/kernel/random/entropy_avail` ausgelesen werden kann. Dies ist der Wert, der nach Ihrem Kernel-Update möglicherweise stark gesunken ist.
Historisch gesehen gab es unter Linux zwei Hauptschnittstellen, um Zufallszahlen abzurufen:
- `/dev/random`: Diese Schnittstelle liefert „echte” Zufallszahlen aus dem Entropy Pool. Wenn der Pool leer ist, blockiert `/dev/random` den aufrufenden Prozess, bis ausreichend neue Entropy gesammelt wurde. Dies ist ideal für sehr sensitive Anwendungen, kann aber bei Systemen mit wenig Hardware-Aktivität (z. B. Headless-Server, VMs) zu langen Wartezeiten führen.
- `/dev/urandom`: Diese Schnittstelle liefert pseudozufällige Zahlen. Sie wird aus dem Entropy Pool initialisiert, blockiert aber niemals. Wenn der Pool leer ist, verwendet `/dev/urandom` einen kryptografisch sicheren Pseudozufallszahlengenerator (CSPRNG oder **CRNG**), der aus dem zuletzt gesammelten Entropy-Material weiterarbeitet. Die Qualität der Zahlen ist nach der Initialisierung des CRNG als „gut genug” für die meisten kryptografischen Zwecke anzusehen.
Das Dilemma lag oft darin, dass `/dev/random` bei blockierendem Verhalten die Systemleistung beeinträchtigte, während die unkritische Nutzung von `/dev/urandom` zu Bedenken führte, ob die anfängliche Seeding-Phase ausreichend sicher war, besonders auf frisch gebooteten Systemen ohne viel Interaktion.
Der „Kernel Update” und die drastisch gesunkene Entropy: Was hat sich geändert?
Hier kommen wir zum Kern des Problems, oder besser gesagt, zur Lösung. Ab Linux Kernel Version 5.6 (wobei die Vorarbeit bereits in früheren 5.x-Versionen geleistet wurde) gab es eine signifikante Änderung in der Art und Weise, wie der Linux-Kernel mit der Zufallszahlengenerierung umgeht. Das Hauptziel war, die **Zuverlässigkeit und die frühzeitige Verfügbarkeit** von kryptografisch starken Zufallszahlen zu verbessern und gleichzeitig das Problem des Blockierens bei mangelnder Entropy zu minimieren.
Die entscheidende Neuerung ist die Umstellung auf eine Architektur, bei der der interne **CRNG** des Kernels viel früher im Bootprozess initialisiert wird. Anstatt darauf zu warten, dass der traditionelle Entropy Pool vollständig gefüllt ist, bevor sichere Zufallszahlen ausgegeben werden können, verwendet der Kernel nun:
- Frühe Quellen: Der Kernel sammelt sehr früh im Bootprozess Entropy aus verschiedenen Quellen, darunter RDRAND (falls vorhanden, ein Hardware-Zufallszahlengenerator in modernen Intel- und AMD-CPUs), Zeitgeber, Interrupt-Timing und CPU-Variationen.
- `getrandom()` Systemaufruf: Der moderne und bevorzugte Weg, um Zufallszahlen unter Linux anzufordern, ist der Systemaufruf `getrandom()`. Dieser Aufruf wurde eingeführt, um die Komplexität und die Fallstricke von `/dev/random` und `/dev/urandom` zu umgehen. Standardmäßig verhält sich `getrandom()` wie `/dev/urandom` (blockiert nicht), kann aber optional so konfiguriert werden, dass es wie `/dev/random` blockiert.
- CRNG-Initialisierung: Sobald der Kernel genügend frühe Entropy gesammelt hat, um seinen internen **CRNG** sicher zu initialisieren, wird dies im Kernel-Log (dmesg) mit der Meldung
random: crng_init donevermerkt. Dieser Zeitpunkt ist entscheidend.
Nachdem die Meldung random: crng_init done erschienen ist, ist der interne CRNG vollständig initialisiert und liefert kryptografisch sichere Zufallszahlen über `getrandom()` und `/dev/urandom`. An diesem Punkt wird die Notwendigkeit, den traditionellen „Entropy Pool” auf einem hohen Wert zu halten, für die meisten Anwendungen obsolet.
Warum sinkt dann `entropy_avail`? Der Zähler `/proc/sys/kernel/random/entropy_avail` ist primär ein Indikator für die im *klassischen* Entropy Pool gesammelte Zufälligkeit, die für `/dev/random` relevant ist. Da der Kernel nun jedoch den internen **CRNG** als primäre Quelle für sichere Zufallszahlen (via `getrandom()` und `/dev/urandom`) verwendet und dieser CRNG nach seiner Initialisierung unabhängig vom Füllstand des klassischen Pools hochwertige Zufälligkeit generiert, wird der Zähler für `entropy_avail` einfach nicht mehr so aggressiv „aufgefüllt” oder hochgehalten, wie es früher der Fall war. Er spiegelt nicht mehr direkt die *Sicherheit* der insgesamt verfügbaren Zufälligkeit Ihres Systems wider, sondern eher die Menge an *zusätzlicher, nicht-deterministischer* Hardware-Entropy, die noch nicht in den Pool gemischt wurde.
Kurz gesagt: Der Kernel ändert sein Verhalten, weil er **nicht mehr unbedingt auf diesen speziellen Pool angewiesen ist**, um sichere Zufallszahlen zu liefern, sobald der CRNG einmal sauber initialisiert ist.
Ist mein System jetzt unsicher? Die Entwarnung!
Die kurze Antwort lautet: **Höchstwahrscheinlich nicht!** Im Gegenteil, Ihr System ist nach einem modernen Kernel-Update oft sicherer, weil es:
- Früher und zuverlässiger sichere Zufallszahlen bereitstellt, selbst auf Systemen mit wenig Hardware-Interaktion.
- Die Gefahr des Blockierens von Anwendungen durch einen leeren Entropy Pool minimiert.
- Eine konsistent hohe Qualität der Zufallszahlen über den internen, kryptografisch starken Generator sicherstellt.
Wenn Sie die Meldung random: crng_init done in Ihrem Kernel-Log (dmesg) sehen, können Sie beruhigt sein. Der **CRNG** wurde erfolgreich initialisiert, und Ihr System ist in der Lage, sichere Zufallszahlen zu generieren. Der niedrige Wert in `entropy_avail` ist dann lediglich ein Relikt einer älteren Arbeitsweise und kein Indikator für eine fehlende kryptografische Stärke.
Es ist ein Paradigmenwechsel: Statt den Füllstand des Entropy Pools zu überwachen, konzentriert sich die moderne Linux-Kernel-Architektur auf die erfolgreiche Initialisierung und den Betrieb des CRNG.
Was tun, wenn die Entropy wirklich fehlt oder man sich unsicher ist?
Obwohl in den meisten Fällen Entwarnung gegeben werden kann, gibt es Situationen, in denen das Fehlen von Entropy tatsächlich ein Problem darstellen könnte, oder in denen Sie einfach sicherstellen möchten, dass Ihr System optimal ausgestattet ist:
- Überprüfen Sie den CRNG-Status: Der wichtigste Schritt ist immer, im Kernel-Log nach der Meldung
random: crng_init donezu suchen. Sie können dies mitdmesg | grep 'crng_init done'tun. Wenn diese Meldung vorhanden ist, können Sie entspannt sein. - Installieren Sie Hardware-Zufallszahlengeneratoren (HRNGs): Moderne CPUs (Intel seit Ivy Bridge, AMD seit Zen) verfügen über Hardware-Instruktionen wie RDRAND und RDSEED, die eine hochwertige Zufälligkeit direkt von der CPU liefern. Der Kernel nutzt diese automatisch. Wenn Ihr System dies unterstützt, ist das ein großer Gewinn für die Entropy-Generierung. Für ältere Hardware oder zusätzliche Sicherheit können Sie Tools wie `rng-tools` (mit dem Daemon `rngd`) installieren. `rngd` liest aus verschiedenen Quellen (z.B. RDRAND, dedizierte Hardware-RNGs wie TPMs oder externe USB-Geräte) und führt diese in den Entropy Pool des Kernels ein.
- Virtuelle Maschinen (VMs): VMs haben oft das größte Problem mit Entropy-Mangel, da sie keinen direkten Zugriff auf „echte” Hardware-Interaktionen haben.
- Stellen Sie sicher, dass Ihr Hypervisor (z. B. KVM/QEMU, VMware, Hyper-V) einen paravirtualisierten Zufallszahlengenerator für die VM bereitstellt (z. B. `virtio-rng` für KVM/QEMU).
- Der Guest-Kernel sollte die entsprechende Treiberunterstützung (z. B. `virtio_rng`) geladen haben.
- In der VM kann ebenfalls `rngd` installiert werden, um die vom Hypervisor bereitgestellte Entropy effektiv zu nutzen.
- Anwendungen anpassen: Wenn Sie selbst Software entwickeln, stellen Sie sicher, dass Sie den `getrandom()` Systemaufruf verwenden oder `/dev/urandom` anstelle von `/dev/random`, es sei denn, Sie haben spezifische und gut begründete Anforderungen für das blockierende Verhalten von `/dev/random`. Viele moderne Bibliotheken und Programmiersprachen nutzen `getrandom()` bereits intern.
- KEINE ad-hoc-Lösungen ohne Verständnis: Vermeiden Sie es, ohne tiefes Verständnis Tricks wie `dd if=/dev/urandom of=/dev/random` anzuwenden. Dies füllt den Entropy Pool nur mit pseudozufälligen Daten und verbessert die Qualität nicht, wenn die ursprüngliche Quelle nicht ausreichend war. Solche Aktionen können die Situation im schlimmsten Fall sogar verschlimmern, indem sie einen falschen Sinn von Sicherheit vermitteln.
Fazit: Verstehen statt Panik
Die drastisch gesunkene Anzeige der „available entropy” nach einem Kernel Update ist in den meisten Fällen kein Grund zur Sorge, sondern ein Zeichen für eine verbesserte und modernisierte Architektur der Zufallszahlengenerierung in Linux. Der Schlüssel liegt im Verständnis des Paradigmenwechsels vom klassischen Entropy Pool hin zur **CRNG-Initialisierung** und dem `getrandom()` Systemaufruf.
Ihr System ist dadurch nicht unsicher geworden, sondern bietet im Gegenteil eine robustere und zuverlässigere Quelle für kryptografisch sichere **Zufallszahlen**. Solange die Meldung `random: crng_init done` in Ihrem Kernel-Log erscheint, können Sie davon ausgehen, dass Ihr System seine kryptografischen Aufgaben sicher erfüllen kann. Konzentrieren Sie sich auf die Überwachung dieses Status und die Bereitstellung von Hardware-Quellen, wo dies sinnvoll ist, statt sich von einem scheinbar niedrigen Zählerwert beunruhigen zu lassen.
Die Welt der IT-Sicherheit ist ständig in Bewegung. Was gestern als Best Practice galt, kann heute durch neue Erkenntnisse und technische Fortschritte überholt sein. Bleiben Sie informiert, verstehen Sie die Hintergründe und lassen Sie sich nicht von scheinbar alarmierenden Zahlen in die Irre führen!