AWSでキーを安全に生成するにはどうすればよいですか？
私たちのアプリケーションは、opensslを使用してAWSで長期ストレージ用の安全なキーを生成する必要があります。しかし、AWSマシンでエントロピーが危険なほど低くなる例をいくつか見ましたが、これは100％安全ではないようです。人々はいくつかの状況で 低エントロピー を報告しています。
AWSで強力なキーを生成していることを確認する最も簡単な方法は何ですか？
たとえば、次の方法があります。
- フェイルセーフとして十分なエントロピーが得られるまで実行をブロックする
- より多く/より高品質のエントロピーを備えたシードマシン
- ランダム性の優れたソースを提供するために、AWSを他のハードウェアで補完する
私は random.org を見てきましたが、外部のWebサービスを使用することは、実稼働環境に適していないか、十分に高速ではないようです。
この「低エントロピー」のマントラはおかしいです。詳細は this answer を参照してください。エグゼクティブサマリーは次のとおりです。一部のソフトウェア、特に/dev/randomは、「低いエントロピー」を報告し、実用的でない理由でブロックする場合があります。エントロピーが「使い果たされる」という考えは、現実とのつながりが希薄な数学的モデルに由来し、「理論的に安全な」アルゴリズムにランダム性が使用された場合にのみ（理論的には）セキュリティーが向上する可能性があります。 RSAやAESなどの通常のアルゴリズムは、これらのクラスのものではありません。
したがって、次のことを行う必要があります。
- OpenSSLは通常、
/dev/urandomを使用して問題を回避する必要があります。問題が発生した場合、それは「ブロッキング」動作として現れます（CPUを使用せずに、キーの生成に異常な時間がかかります）。 - 問題が発生した場合は、
/dev/randomを新鮮な疑似乱数で「リフィル」してくださいこれで十分です。次のようなもの：dd if=/dev/urandom of=/dev/random bs=1024 count=64
ただし、別の問題があり、対処が容易ではありません。クラウドシステムは仮想マシンであり、同じハードウェア上で他の仮想マシンと同時に実行できます。 2つの実行スレッドが同じCPUの2つのコアで実行される場合、それらが個別の仮想マシンに関連している場合でも、レベル1キャッシュを共有し、互いにスパイする可能性があります。この手法では、ターゲットコードと同じキャッシュラインを使用する配列でメモリアクセスを実行し、一部の配列要素がキャッシュから削除されたときに通知することでターゲットシークレットを再構築します。
実用的なプロトタイプは、実験室の条件で実証されています。それらが実際の設定で適用できるかどうかは、多くのパラメーターに依存し、現在不明です。しかし、それはもっともらしいです。結論は、キーで何か深刻なを実行する場合は、独自のハードウェアで実行するように努力するか、少なくとも仮想マシンがクラウドプロバイダーから保証を受けることです。他の顧客の仮想マシンと同じハードウェアサーバーを共有しないでください。
古いスレッドですが、良い質問と、ここでのいくつかの回答は、AWSマシンまたはCloud VMに必ずしも固有であるとは限りません。質問で述べたように、 キツネザル チーム、より幅広いシナリオに適用：「キツネザルが引き出す優れたエントロピーを確保するために費やしたい労力は、特定のリスク許容度とキツネザルの状態次第ですシステムにさらにエントロピーを生成したい場合は、次のリソースをご覧になることをお勧めします： "そして、推奨 haveged に進みます。
低エントロピーの問題の詳細を読むことに興味がある人は、次の論文 OpenSSLの乱数ジェネレーターの分析 と参考文献を読む価値があります。
高いエントロピー乱数を生成する機能は、暗号化操作のセキュリティが依存する秘密鍵、初期化ベクトル、およびその他の値の生成に不可欠です。
この記事では、 Ubuntu 14.04 LTSクラウドインスタンスでのランダムシードの改善 で、クラウドでのエントロピーの改善に向けたUbuntuの取り組みについて、問題と可能な解決策について説明します（ pollen ）より詳細に：
Q：私のOSは最初の起動時に初期シードを生成しますか？ A：はい。ただし、コンピューター、特にVMは予測可能です。コンピュータは本質的に決定論的であり、したがって、ランダム性を生成するのは得意ではありません実際のハードウェアは品質のエントロピーを提供できますが、仮想マシンは基本的には互いにクローンです
Ubuntuソリューションは「サービスとしてのエントロピー」ソリューションであるため、OPの要件をまだ満たしていない可能性がありますが、（開発者によると）「高速で効率的でスケーラブル」です。
理論から実践に移るには、PRNGがどの程度優れているかを評価することに興味がある場合は、 Prangster を確認してください。
ここでの目的は、疑似ランダム出力の特定のサンプルを生成したシードを特定することです。そうすることで、安全でないPRNGの使用を確実に終了し、それを使用するアプリケーションを攻撃する準備をします。これはPrangsterツールの主要な機能であり、必要なのは出力と正しいPRNGとアルファベットだけです。
。
/dev/randomまたは/dev/urandomについては、多くの誤解や神話があります。 /dev/urandomの使用が常に十分であり、/dev/randomが偏執狂的であることのみが一般的であるとは限りません。
ここで重要なのは、数値の生成を開始する前の、インスタンスの存続期間中に収集されたエントロピーの総量です。それが最も重要です。インスタンスの生成後（AMIから）、ランダムジェネレーターは、推測できない数の生成を開始するのに十分なエントロピーを蓄積する必要があります。
十分なエントロピーが得られると、/dev/urandomから暗号に強い、ほぼすべての量のデータを生成できます。ただし、収集されたエントロピーが十分でない場合は、最初にそれを取得する以外に解決策はありません。
/dev/randomがエントロピーのカウンターを減らすことは少し偏執狂的です。 以前に生成された数値を公開しても、次の生成された数値を推測することはできません。これを達成するために、ジェネレーターは、暗号化アルゴリズム（AES、SHAなど）で見つけたのと同じ構造を使用します。したがって、rndジェネレーターを信じない場合は、暗号化自体を信じることはできません。