web-dev-qa-db-ja.com

SSLインターセプトの動的証明書は、エントロピーが弱いためにセキュリティリスクをもたらしますか?

ファイアウォールでの典型的なSSLインターセプトについて考えると、TLS接続の数に応じて、非常にタイムクリティカルな環境で大量の証明書が「オンザフライ」で偽造されます。

OpenVPNに基づくVPNサービスの実行に関する私の経験では、「適切な」新しい証明書を作成するために常に十分なエントロピーがあることを確認するために、常に十分に高いエントロピーが必要になります。

では、生成された大量の証明書を考慮すると、一般的なファイアウォールはどのようにして十分なエントロピーを確保するのでしょうか。彼らもそうしますか?そうでない場合、これは単なる理論上のセキュリティリスクですか、それとも弱いエントロピーに基づく攻撃が知られていますか?

1
architekt

はい、ここにはリスクがありますが、その範囲はそのようなプロキシ/ファイアウォールデバイスのネットワーク/ユーザーにほぼ完全に限定されています。低エントロピーは、 TLSハンドシェイクのクライアントナンス プロキシ/ファイアウォールデバイスからのアウトバウンド接続に非常に小さな影響を与える可能性もあります。

エントロピーが低いということは、推測可能な素数を意味する可能性があります。これは、推測可能な秘密鍵を意味し、実行可能なMITM攻撃につながる可能性があります。そのようなシステムに低エントロピーの問題があり、CAキーが最初に生成される場合は、 実際の問​​題がある可能性があります

(共有またはベンダー提供のキー/ CAを使用している場合、そのようなシステムには明らかな beartrap がありますが、それはまったく別の問題です。)

一般に、適切なチェーンと失効の検証の問題、および安全でないレガシーSSLまたは暗号の使用につながる不十分な構成に大きなリスクが割り当てられます。USCERTを参照してください TA17-075A HTTPS Interception Weakens TLS Security (これに秘密鍵の保護が不十分で、少なくとも1つの商用製品がHSMをサポートしていますが、オンデマンド証明書ではなく内部CAでのみ機能すると思われます)。

ここでの潜在的な問題は、エントロピーが低い場合、素数が予測可能である可能性があることです。ただし、これだけでは、モジュラスの因数分解(秘密鍵の決定)が容易になるわけではありません。 doesブルートフォース攻撃を実行可能にします。この場合、ブルートフォーシングPRNG input( attacker knows PRNG))使用中のプライム(したがってキー)。キーと証明書を収集できるプロキシにアクセスできる邪悪な管理者である場合は、 デッキが有利にスタックされています 他の誰かのプロキシを攻撃する場合。邪悪なユーザーとして、衝突を見つけるのに十分なトラフィックを生成できる可能性がありますが、これはあまり面白くありません。

実際には(確かにOpenSSLの場合)、a PRNGはキーソースマテリアルを生成するために使用されます( 素数を検索 )ので、「実際の」エントロピーはほとんどありません。プロキシは一般に、タイミングイベントとハードウェアイベント(多くのランダム接続がある、ネットワークとディスクがビジーである可能性がある)からエントロピーを収集するのに適した候補です。

およそ90-100kiBのPRNG出力は一般に2048ビットのキー生成(ナイーブな生成/テスト/破棄アルゴリズムを使用した2x 1024ビット素数)に必要であり、シードへの「実際の」エントロピーの非PRNGバイトのほんの一握り(観察によると32バイト)。キー生成の遅延は実際には 一次テスト です。

低エントロピーキーの意味については、(わかりやすいタイトルの)論文を読むことができます PsとQのマイニング:ネットワークデバイスでの広範囲にわたる弱いキーの検出 (PDF)。

このようなプロキシの使用に関するセキュリティの問題について説明している2つの有用な論文があります。

これらは他の多くのセキュリティ上の懸念を引き起こしますが、ランダム性/エントロピーは2番目のもので簡単に言及されています:

生成中のエントロピー。インストール時に生成された証明書で新しい公開鍵と秘密鍵のペアの生成中に使用されるエントロピーが不十分である可能性があります。実際には、分析したほとんどの製品はOpenSSLを使用してRSAキーでルート証明書を生成するため、生成プロセスでは、Rand_seed()、Rand_event()、RSA_generate_key_ex()などの特定の既知の関数を呼び出すことが期待されます。多くの場合、最後の関数の呼び出しが見つかりました。ただし、CCAのキー生成アルゴリズムについてはこれ以上調査しませんでした。

参照:

1
mr.spuratic