Warum überhaupt überhaupt. Müssen wir den zufälligen Seed zwischen Neustarts "bewahren"? Was würde passieren, wenn wir es nicht tun? Wird der Computer beim Booten eine Zufälligkeit von 0 haben?
Dies stellt sich als eine viel tiefere Frage heraus, als Sie vielleicht glauben. Ich werde versuchen, dem gerecht zu werden, ohne ein Lehrbuch zu schreiben.
Grundsätzlich:Computer saugen an Zufälligkeit; Wenn Sie etwas echte Zufälligkeit (auch bekannt als Entropie) haben, ist es eine gute Idee, daran festzuhalten.
Nehmen wir an, Ihr Computer hat keinen Hardware-Zufallszahlengenerator. (Moderne Intel-Chips haben den rdrand Anweisung, die einen Hardware-Rng anzapft, aber aus politischen Gründen vom Linux-Kernel nicht verwendet wird.)
Woher bekommt der Kernel beim Booten reine Zufälligkeit? Laut Wikipedia:
Der Linux-Kernel generiert Entropie aus Tastatur-Timings, Mausbewegungen und IDE-Timings und stellt die zufälligen Zeichendaten anderen Betriebssystemprozessen über die speziellen Dateien /dev/random und /dev/urandom zur Verfügung. Diese Funktion wurde in der Linux-Version 1.3.30 eingeführt.
Also Maus, Tastatur und Timing von Festplatten-IO-Ereignissen. Angenommen, Sie benötigen Entropie während des Betriebssystemstarts (zum Beispiel starten Sie sshd das beim ersten Start Schlüssel generieren muss), dass Sie die Maus- und Tastaturtreiber noch nicht geladen haben und dass Sie zu Beginn des Boot-Zyklus nicht sehr viele Disk-IO-Aufrufe getätigt haben - verdammt noch mal früh genug im Boot der Kernel läuft immer noch in einem RAM FS, und selbst danach befinden Sie sich möglicherweise auf einer SSD oder einem Flash-Laufwerk, das sehr vorhersehbare IO-Zeiten hat.
Also zurück zu deiner Frage:
Was würde passieren, wenn wir es nicht tun? Wird der Computer beim Booten eine Zufälligkeit von 0 haben?
Es ist möglich.
Auf kleinen eingebetteten Linux-Geräten wie Routern, die aus dem Flash-Speicher booten (sowohl die kleinen Heimgeräte als auch die großen Rechenzentrumsgeräte, die das Internet mit Strom versorgen), ist dies tatsächlich ein ernstes Problem.
Eine großartige Lektüre zu diesem Thema finden Sie in der Veröffentlichung von 2012 Mining Your Ps and Qs:Detection of Widespread Weak Keys in Network Devices die den schockierenden Befund hat, dass
0,75 % der TLS-Zertifikate [im Internet] teilen Schlüssel aufgrund unzureichender Entropie während der Schlüsselgenerierung.
Nur ein paar Zeilen unter dem Short-Description Sie zitierten, /etc/init.d/urandom stellt einige Annahmen über die Geheimhaltung fest:
## Assumption 1: We assume [/var/lib/urandom/random-seed] is a file (or a symlink
## to a file) that resides on a non-volatile medium that persists
## across reboots.
## Case 1a: Ideally, it is readable and writeable. Its is unshared,
## i.e. its contents are unique to this machine. It is protected so
## that its contents are not known to attackers.
## Case 1b: Less than ideally, it is read-only. Its contents are
## unique to this machine and not known to attackers.
Später in dieser Datei, wo der Seed auf die Festplatte geschrieben wird, gibt es einen Kommentar:
# see documentation in linux/drivers/char/random.c
was lesenswert ist, aber beinhaltet:
* When any operating system starts up, it will go through a sequence
* of actions that are fairly predictable by an adversary, especially
* if the start-up does not involve interaction with a human operator.
* This reduces the actual number of bits of unpredictability in the
* entropy pool below the value in entropy_count. In order to
* counteract this effect, it helps to carry information in the
* entropy pool across shut-downs and start-ups.
... Even with
* complete knowledge of the start-up activities, predicting the state
* of the entropy pool requires knowledge of the previous history of
* the system.
Das Speichern von Entropie zwischen Neustarts ist eine unvollkommene Lösung für Entropieknappheit beim Booten. Warum unvollkommen? Erstens, weil gespeicherte Entropie auffindbar ist, könnten potenzielle Angreifer, wenn sie an diesen gespeicherten Seed gelangen könnten, auch alle damit gesäten Zufallszahlengeneratoren kompromittieren. Zweitens, weil bei der Wiederherstellung des Systems aus Backups oder mehreren VM-Instanzen, die mit demselben gespeicherten Seed erstellt wurden, alle dieselbe gespeicherte Entropie wiederverwenden würden.
Dennoch sind solche Katastrophen immer noch vorzuziehen, wenn Ihrem System keine Entropie beim Booten zur Verfügung steht.
Denken Sie daran, dass Ihre Lösung nicht zertifizierbar ist, wenn Sie so konfigurieren, dass Entropie gespeichert wird, da FIPS und so ziemlich jeder andere krypto- und infosec-bezogene Standard diese Praxis verbietet.