NSAは、何兆もの暗号化されたWebおよびVPN接続を破壊できる方法
Diffie-Hellmanの鍵交換の交渉に基づいて、少数の素数のみが一般的に使用されていることが判明するのはなぜですか？何が誰が素数を決めるのですか？
安全なプライムを使用する方が安全ではないでしょうか？ （例：p = 2q + 1）
*質問はこの記事に基づいています：
編集＃2（11/09/15）-いくつかの記事と論文を読みました。その他のコメントについては、下をご覧ください。
私は記事を読みましたが、以下についての直接的なデータはありません。
ここで起こっている要因の組み合わせがあります。
- DH交換の性質。
- 事前にプロビジョニングされたキー。
- キーの変更不可。
- DHアルゴリズムに対する既知の攻撃。
DH交換
交換では、2つの当事者がベースプライムを持っている必要があります。それはセーフプライム（またはソフィージェルマンプライム）であるべきです。クライアントが持っていない場合は、サーバーが送信します。両当事者は、指数を作成するために安全な乱数ジェネレータを使用する必要があります。計算は、成功と失敗が同じ量の実時間をとるように構成する必要があります。
事前にプロビジョニングされたキー
大きな素数を生成することは難しくありませんが、初心者向けです。あなたのためにそれを行うソフトウェアを用意するのが最善です。そのソフトウェアは、安全な乱数ジェネレータを使用する必要があります。ほとんどの人は、習慣、無知、怠惰から事前にプロビジョニングされたキー（素数）を使用するだけです。
変更不可能なキー（プライム）
問題のソフトウェアの多くが素数の変更を許可するように設計されていなかった可能性が高いです。ソフトウェアを作成するエンジニアは、ユーザーと同じように適切なセキュリティ方法を知らないことがよくあります。私はそれをつまらないと言っているのではありません。 「知識不足」のように無知。
既知のDH攻撃
どこから始めれば！
短い鍵（768）は、数十人の大学院生が部分離散ログマトリックスを計算し、数十年前にSunのネットワークパスワード認証方式を攻撃する能力の範囲内でした。この回答の最後にあるリファレンスを参照してください。 NSA（またはだれでも）が今日、既知の1024ビットキーのパーシャルを計算する機能を持っているとしても、私は驚かないでしょう。
プロトコルは、クライアントへの転送中にプライムを置き換えることによって攻撃される可能性がありますifクライアントはプライムを持っていず、サーバーにそれを要求します。
さらに良いことに、DHは中間者攻撃を受けやすく、特にクライアントがサーバーからPrimeを要求する場合はそうですが、そうでない場合でもです。 DHアルゴリズムは、計算される安全な指数に依存しています。ただし、他のデータに依存することはありません。サーバーとクライアントが安全なセッションを確立するためにお互いを証明する必要はありません。何らかの理由でクライアントのパスワード（またはそのハッシュ）がDHキーネゴシエーションに混入し、情報の漏えいや完全な転送の秘密が保持されなかった場合、クライアントはサーバーが正当であると確信できます。 SPEKEおよびDHEKEアルゴリズムを調べて、これから始めてください。いずれにせよ、NSA MITMは2つのDHセッションを作成し、1つはクライアントともう1つはサーバーで作成し、2つの間をパイプしながらすべてのデータを記録します。簡単です。
この記事では、NSAは、よく知られた素数に依存してセッションを攻撃していると述べています。離散対数部分行列の計算について述べた論文を参照します。現在、可能であればハードウェアアドバンス、1024ビットでキーは、オブザーバー攻撃からの秘密を提供しません。
DHアルゴリズムを実行しているマシンが他の方法で侵害されていないのは誰ですか？おそらく、彼らは正しい方法で照会されたときに重要なデータを漏らしたり、あきらめたりしましたか？どのようにNSAがすべての計算ハードウェアを危険にさらすことができるかについて、非常に多くの情報が公開されています。おそらく、必要な場合を除いてアルゴリズムを破壊することはせず、代わりにマシンに侵入してセッション暗号化キーを直接取得しました。 ？
編集
その他のDH攻撃：
- Safeではない素数を導入します（Q＆Pが素数であるP = 2Q + 1のソフィージェルマンプライム基準に準拠していません）。安全でないPrime P（QはPrimeではない）はDH関数の範囲を制限し、それによって、オブザーバー攻撃（離散ログ計算）を単純化することがあります。アルゴリズムのコンテキストでは、
g^(A*B)%PはPのフィールドに1：1または2：1でマップする必要があります。悪いPは、数値の大きなスワスを計算的に実行可能な小さなセットにマッピングできます。 - 小さな指数を許可する（または強制する）不十分にコーディングされたDHアルゴリズムに依存し、セッションへの攻撃を容易にします。
- コーディングが不十分な安全な乱数ジェネレーターやシードが不十分なRNG（現在の時刻またはプロセスIDを使用したもの）に依存します。
- オブザーバーが結果を計算するために参加者がどれほどハードに（時間内に測定）作業するかを監視し、キーの作業プロパティに基づいて推測するタイミング攻撃（その情報を使用してキーを破壊する）。これは一般的な攻撃であり、Diffie-Hellmanに固有のものではありません。
＃2を編集
私は article にリンクし、12人の著者 paper を投稿しました。
上記で疑われたように、ここにその要点があります。最後に、もう1つの脆弱性を示すために、TLS + DH + RSA暗号スイートについてもう少し追加します。
まず、NSAが、Diffie-Hellman鍵交換に使用される一般的に使用されるDHグループ（Safe Prime P + Generator g）の多くを壊した可能性があります。上で示したように、少なくとも10年ほど前に、この攻撃は、ネットワークパスワード認証に使用されるSunの768 DHキーを使った2人の大学院生（まだ参照していません）によって完了しました。この攻撃は、オブザーバー攻撃であるため、 -middleが必要です。特定のグループを解除するために必要な作業は非常に大きいですが、一度解除すると、それを使用するすべての交換が危険にさらされる可能性があります。
理論的には、DH鍵交換はPerfect Forward Secrecyを提供します（提供しないRSAに対して）。 DHグループが解除されると、そのグループを使用するすべての交換は将来的に危険にさらされ、逆方向にも危険にさらされるため（つまり、記録された交換が遮断される可能性がある）、そのグループの完全な転送秘密はなくなります。また、専用の攻撃者が珍しいDHキーを破ることができることも意味します。これは1024ビットのキーで可能であると想定されているため、DHの場合はキーの長さを2048に増やします。 RSAには、すでにより長いキーを使用しているはずです。
次に、研究者たちはいくつかの注目すべき点を指摘します。この論文はLogjamをカバーしていますが、これはMITM、暗号スイートダウングレード攻撃であると言う以外は詳しく説明しません。巧妙ですが、アルゴリズム的に複雑ではありません。
興味のある方はぜひ読んでいただきたい。すごいね。要約の2番目の段落です。
次に、768ビットおよび1024ビットのグループを持つDiffie-Hellmanについて検討します。 1024ビットの場合でも、計算は国民国家のリソースを考えればもっともらしいと推定します。少数の固定または標準化されたグループが数百万のサーバーで使用されています。単一の1024ビットグループに対して事前計算を実行すると、人気のあるHTTPSサイトの18％でパッシブ盗聴が可能になり、2番目のグループでは、IPsec VPNの66％とSSHサーバーの26％へのトラフィックの復号化が可能になります。公表されたNSAのリークを詳しく読むと、VPNに対する機関の攻撃がそのような破綻を達成したことと一致していることがわかります。より強力な鍵交換方法への移行がインターネットコミュニティの優先事項であると結論付けます。
それはほとんどすべてを語っています。 NSAで区切られた固定キーは、多くの安全なネットワークプロトコルのオブザーバー（パッシブ）ブレークを許可します。そのため、事前プロビジョニングされたキーまたは一般的なキー（可能な場合）を使用しないでください。キーの長さ。
TLS + DH + RSA暗号スイートについては、これはより長いキー長で安全ですか？
私はそれがオブザーバー攻撃から安全であることを危険にさらすでしょう、しかしそれはまだ中間者攻撃を受けやすいので、ここにその方法があります。
このモードでは、サーバーはRS鍵（Sign((g^B)%P,RSA_Key_Server)）を使用してDHエフェメラルに署名します。つまり、DH交換のサーバー部分が認証されます。署名がクライアントに到達したときに有効であり、サーバー証明書が取り消されていない場合、サーバーのみが署名を完了できることを知っていれば、クライアントはDH交換を安全に進めることができます。
では、MITMはどのようにして可能ですか？ 2つの方法、一方が他方よりも可能性が高い。どちらも、クライアントが適切な署名チェックを実行できないことに依存しています。
第1に、クライアントのキーストアにルート認証局が多すぎます（多くのブラウザには100を超える数があります）。これらのルートCAの一部は信頼できません。 MITMは問題のリモートサイトのサーバー証明書を取得し、中間に位置し、独自の証明書（Sign((g^B2)%P,RSA_Key_Middle_Server)）で署名します。クライアントは署名を検証し、サーバーが本物であると想定し、サーバーとのDH交換を完了します。一方、中間サーバーは、実サーバーとの交換の独自のクライアント側を実行し、その間のすべてのデータを監視できます。
第二に、これは可能性が低いと思います。クライアントは失効した証明書のチェックに失敗し、MITMには失効した秘密鍵があるため、元の実サーバーであるかのように署名できます。失効を確認しなかったため、クライアントにはわかりません。中間サーバーは、リモートの実サーバーと別のDH交換を再度実行し、中間に位置します。
物語の教訓は、クライアントの構成を監視し、キーの長さを増やすことです。
編集＃3：数十年前のDH攻撃への言及が見つかりました：
B.A. LaMacchiaとA.M.オドリズコ。素体における離散対数の計算。 Designs、Codes、and Cryptography、1：46-62、1991。
それらを壊す1つの方法は、それを回避する方法を見つけることです。ほとんどの場合、すべてのタイプのセキュリティを回避する方法があります。 「人間がそれを構築できれば、人間はそれを破壊することができる」の考え方に同意します。
Installbackdoors などの一般的なソフトウェアでAdobe Flash、PDF、そしてもちろん、Javaの中です。忘れないようにWindows services。次に、バックドアを備えた プレインストールされたハードウェア のようなものがあります。
あなたがしなければならないすべては implementsomethingthat allows あなた to runarbitrary code 正しく実行された場合。多くのプラットフォームで、そしてほとんどすべてのプログラミング言語でこれを行うには多くの方法があります。
セキュリティの欠陥をわざと実装することは、特定の機関が実際に行うのが好きなことの1つです。
そうすれば、暗号化も必要ありません。クワッドレイヤーのDr. Dalek暗号化VPN接続に多くの異なる方法がある場合、誰がそれを気にしますか？