Pourquoi faire ça du tout, en premier lieu. Avons-nous besoin de "préserver" la graine aléatoire entre les redémarrages ? Que se passerait-il si nous ne le faisions pas ? L'ordinateur aura-t-il 0 aléatoire au démarrage ?
Cela s'avère être une question beaucoup plus profonde que vous ne le pensez. Je vais essayer de lui rendre justice sans écrire de manuel.
Fondamentalement :les ordinateurs aspirent au hasard; lorsque vous avez un vrai hasard (c'est-à-dire de l'entropie), c'est une bonne idée de s'y accrocher.
Supposons que votre ordinateur ne dispose pas d'un générateur de nombres aléatoires matériel. (Les puces Intel modernes ont le rdrand instruction qui puise dans un rng matériel, mais pour des raisons politiques, le noyau Linux ne l'utilise pas.)
Au démarrage, d'où le noyau tire-t-il le pur hasard ? D'après Wikipédia :
Le noyau Linux génère de l'entropie à partir des synchronisations du clavier, des mouvements de la souris et des synchronisations de l'IDE et rend les données de caractères aléatoires disponibles pour les autres processus du système d'exploitation via les fichiers spéciaux /dev/random et /dev/urandom. Cette fonctionnalité a été introduite dans la version 1.3.30 de Linux.
Donc, souris, clavier et synchronisation des événements d'E/S du disque dur. Disons que vous avez besoin d'entropie lors du démarrage du système d'exploitation (par exemple, vous démarrez sshd qui doit générer des clés lors de son premier démarrage), vous n'avez pas encore chargé les pilotes de la souris et du clavier, et qu'au début du cycle de démarrage, vous n'aurez pas fait beaucoup d'appels d'E/S de disque -- diable, assez tôt dans le démarrage le noyau est toujours en cours d'exécution dans un FS RAM, et même après cela, vous pouvez être sur un SSD ou un lecteur flash qui a des temps d'E/S très prévisibles.
Revenons donc à votre question :
Que se passerait-il si nous ne le faisions pas ? L'ordinateur aura-t-il 0 aléatoire au démarrage ?
C'est possible.
Sur les petits appareils Linux embarqués comme les routeurs qui démarrent à partir de la mémoire flash (à la fois les petits appareils domestiques et les grands centres de données qui alimentent Internet), c'est en fait un problème sérieux.
Pour une lecture impressionnante sur ce sujet, consultez l'article de 2012 Mining Your Ps and Qs :Detection of Widespread Weak Keys in Network Devices qui a la découverte choquante que
0,75 % des certificats TLS [sur Internet] partagent des clés en raison d'une entropie insuffisante lors de la génération de clés.
Juste quelques lignes sous le Short-Description vous avez cité, /etc/init.d/urandom note quelques hypothèses sur le secret :
## 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.
Plus loin dans ce fichier, là où la graine est écrite sur le disque, il y a un commentaire :
# see documentation in linux/drivers/char/random.c
qui vaut la peine d'être lu mais comprend :
* 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.
La sauvegarde de l'entropie entre les redémarrages est une solution imparfaite aux pénuries d'entropie au démarrage. Pourquoi imparfait ? Premièrement, parce que l'entropie sauvegardée est détectable, si un attaquant potentiel pouvait mettre la main sur cette graine sauvegardée, il pourrait également compromettre tous les générateurs de nombres aléatoires semés avec. Deuxièmement, parce que lorsque le système est restauré à partir de sauvegardes ou de plusieurs instances de VM générées avec la même graine sauvegardée, elles réutiliseront toutes la même entropie sauvegardée.
Pourtant, de tels désastres sont toujours préférables à l'absence d'entropie au démarrage disponible sur votre système.
Gardez à l'esprit que si vous configurez pour économiser l'entropie, votre solution ne sera pas certifiable, car FIPS et à peu près toutes les autres normes liées à la cryptographie et à la sécurité informatique interdisent cette pratique.