/ dev/randomおよび/dev/ urandomは、環境ノイズを使用してランダム性を生成します。
仮想化サーバーでは、1つのハードウェア構成にオペレーティングシステムの複数のインスタンスが存在する可能性があります。これらのオペレーティングシステムはすべて、同じ環境ノイズからランダム性を調達します。
これは、すべてのOSインスタンスが同じ入力の計算に基づいているため、グループとして乱数ジェネレーターの強度が低下することを意味しますか？または、共有が発生しないように環境ノイズが分割されていますか？
後者が当てはまる場合、/ dev / urandomの有効性が低下することがわかります。これは、内部プールを再利用し、環境入力が少なく、エントロピーが低下するためです。
/ dev / randomは、十分なノイズが取得されるまでブロックされるため、問題ないはずです...もちろん、OSインスタンスがすべて入力を共有している場合を除きます。
それで、質問：仮想化が暗号的に強力な乱数ジェネレーター、特に環境ノイズを使用するジェネレーターに与える影響は何ですか？
参照をすぐに見つけることはできませんでしたが、エントロピーは実際のデバイス自体ではなく、デバイスのカーネル データ構造から派生しているように思えます。これらは仮想化に関係なく独立しているため、答えはあまりないと思います。
[編集] カーネル ソース (実際にはパッチの履歴) を覗いてみると、少なくとも Linux は、キーボード プレス、マウス アクティビティ、割り込みタイミング (すべての割り込みではありません)、およびブロック デバイス リクエストの終了時間からエントロピーを収集しているように見えます。仮想化されたシステムでは、マウス/キーボード イベントはかなり少ないため、収集されるエントロピーには寄与しないのではないかと思います。おそらく、これは追加のネットワーク I/O 割り込みアクティビティによって相殺されるでしょうが、明確ではありません。この点では、非 VM サーバーと大差ないと思います。
ありがとう。
私が理解していることから、エントロピーをネットワーク I/O に依存するシステムは中間者攻撃の影響を受けやすいと言えます。エントロピーの適切なソースについて説明している次の記事を見つけました。彼らの提案は、Linux カーネルが影響を受けやすいため、ネットワーク I/O を Linux カーネルから削除することです。
つまり、仮想化環境で共通のハードウェアを活用できる可能性があるということです。ネットワーク I/O を使用すると、この可能性が高くなります。それ以外の場合は、最も安全なアプリケーション以外では問題にならないほど低い値です。そのような場合は、とにかく独自のアプリケーションをホストする方がおそらく安全です。
定義上、暗号的に強力な PRNG のランダム性は、仮想化の影響を受けるべきではありません。あなたが言及したように、/dev/random と /dev/urandom [参照: http://en.wikipedia.org/wiki/Urandom/]の違いは、システムが必要な量のランダム データを生成するには不十分なエントロピーが収集されました。/dev/random に書き込んで、独自のデータをエントロピー プールに混在させることもできます。