Proč to vůbec dělat, v první řadě. Potřebujeme „zachovat“ náhodné semeno mezi restarty? Co by se stalo, kdybychom to neudělali? Bude mít počítač při startu náhodnost 0?
To se ukazuje jako mnohem hlubší otázka, než si možná uvědomujete. Pokusím se to napravit bez psaní učebnice.
V podstatě:počítače vysávají náhodnost; když máte nějakou skutečnou náhodnost (aka entropii), je dobré se jí držet.
Předpokládejme, že váš počítač nemá hardwarový generátor náhodných čísel. (Moderní čipy Intel mají označení rdrand instrukce, která se napojí na hardwarový rng, ale z politických důvodů ji linuxové jádro nepoužívá.)
Odkud při bootu jádro získává čistou náhodnost? Podle Wikipedie:
Linuxové jádro generuje entropii z časování klávesnice, pohybů myši a časování IDE a zpřístupňuje data náhodných znaků dalším procesům operačního systému prostřednictvím speciálních souborů /dev/random a /dev/urandom. Tato schopnost byla zavedena v Linuxu verze 1.3.30.
Tedy myš, klávesnice a časování IO událostí pevného disku. Řekněme, že potřebujete entropii během bootování OS (například spustíte sshd který potřebuje vygenerovat klíče při prvním spuštění), ještě jste nenahráli ovladače myši a klávesnice a že na začátku spouštěcího cyklu neprovedete příliš mnoho IO volání na disk -- sakra, dost brzy při zavádění jádro stále běží v RAM FS a i poté můžete být na SSD nebo flash disku, který má velmi předvídatelné IO časy.
Takže zpět k vaší otázce:
Co by se stalo, kdybychom to neudělali? Bude mít počítač při startu náhodnost 0?
Je to možné.
Na malých vestavěných linuxových zařízeních, jako jsou routery, které se spouštějí z flash paměti (jak malé domácí, tak velká datacentra, která napájejí internet), je to ve skutečnosti vážný problém.
Úžasné čtení na toto téma najdete v dokumentu z roku 2012 Těžba Ps and Qs:Detection of Widespread Weak Keys in Network Devices která má šokující zjištění, že
0,75 % certifikátů TLS [na internetu] sdílí klíče kvůli nedostatečné entropii během generování klíčů.
Jen pár řádků pod Short-Description jak jste citovali, /etc/init.d/urandom bere na vědomí některé předpoklady o utajení:
## 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.
Později v tomto souboru, kde je seed zapsán na disk, je komentář:
# see documentation in linux/drivers/char/random.c
který stojí za přečtení, ale obsahuje:
* 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.
Úspora entropie mezi restarty je nedokonalým řešením nedostatku entropie při spouštění. Proč nedokonalé? Za prvé, protože uložená entropie je zjistitelná, pokud by potenciální útočník mohl získat toto uložené semeno, mohl by také kompromitovat všechny generátory náhodných čísel, které jsou jím nasazeny. Za druhé, protože když je systém obnoven ze záloh nebo více instancí virtuálních počítačů vytvořených se stejným uloženým seedem, všechny by znovu použily stejnou uloženou entropii.
Přesto jsou takové katastrofy stále lepší, než když váš systém nemá k dispozici žádnou entropii při spouštění.
Mějte na paměti, že pokud nakonfigurujete ukládání entropie, vaše řešení nebude certifikovatelné, protože FIPS a v podstatě jakýkoli jiný standard související s krypto a infosec tuto praxi zakazuje.