そもそも、なぜそんなことをするのか。再起動の間にランダムシードを「保存」する必要がありますか?そうしないとどうなりますか？起動時のコンピュータのランダム性は 0 になりますか?
これは、あなたが思っているよりもずっと深い問題であることがわかりました。私は教科書を書かずにそれを正当化しようとします.
基本的に、コンピューターはランダム性を嫌います。真のランダム性 (別名エントロピー) がある場合は、それを維持することをお勧めします。
お使いのコンピューターにハードウェア乱数ジェネレーターがないと仮定しましょう。 (最新の Intel チップには rdrand ハードウェア rng を利用する命令ですが、政治的な理由から、Linux カーネルはそれを使用しません。)
起動時に、カーネルはどこから純粋なランダム性を取得しますか?ウィキペディアによると:
<ブロック引用>Linux カーネルは、キーボードのタイミング、マウスの動き、および IDE のタイミングからエントロピーを生成し、特別なファイル /dev/random および /dev/urandom を通じて、他のオペレーティング システム プロセスがランダムな文字データを利用できるようにします。この機能は、Linux バージョン 1.3.30 で導入されました。
つまり、マウス、キーボード、およびハードドライブ IO イベントのタイミングです。 OS の起動中にエントロピーが必要だとしましょう (たとえば、sshd を開始します) 最初の起動時にキーを生成する必要があります)、マウスとキーボードのドライバーをまだロードしていないため、起動サイクルの早い段階でディスク IO 呼び出しをあまり行っていません。カーネルはまだ RAM FS で実行されており、その後も IO 時間が非常に予測可能な SSD またはフラッシュ ドライブを使用している可能性があります。
質問に戻ります:
<ブロック引用>そうしないとどうなりますか？起動時のコンピュータのランダム性は 0 になりますか?
可能です。
フラッシュ メモリから起動するルーターのような小さな組み込み Linux デバイス (家庭用の小さなデバイスと、インターネットに電力を供給する大規模なデータ センターのデバイスの両方) では、これは実際には深刻な問題です。
このトピックに関するすばらしい読み物については、2012 年の論文 Mining Your Ps and Qs:Detection of Widespread Weak Keys in Network Devices を参照してください。 という衝撃的な発見があります
<ブロック引用>[インターネット上の] TLS 証明書の 0.75% は、キー生成時のエントロピーが不十分なため、キーを共有しています。
Short-Description の数行下 あなたが引用した /etc/init.d/urandom 機密性に関するいくつかの仮定に注意してください:
## 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.
シードがディスクに書き込まれるそのファイルの後半に、コメントがあります:
# see documentation in linux/drivers/char/random.c
これは読む価値がありますが、以下が含まれます:
* 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.
再起動の間にエントロピーを保存することは、起動時のエントロピー不足に対する完全な解決策ではありません。なぜ不完全なのですか？まず、保存されたエントロピーは発見可能であるため、潜在的な攻撃者がその保存されたシードを手に入れることができれば、シードされたすべての乱数ジェネレーターも侵害される可能性があります。 2 つ目は、システムがバックアップから復元された場合、または複数の VM インスタンスが保存された同じシードで生成された場合、それらはすべて同じ保存されたエントロピーを再利用するためです。
それでも、システムで起動時のエントロピーを利用できないよりは、このような災害の方が望ましいです。
エントロピーを保存するように構成すると、FIPS やその他のほとんどすべての暗号化および情報セキュリティ関連の標準がこの慣行を禁止しているため、ソリューションは認定されないことに注意してください。