DHは、MITMを介して傍受されることなく、暗号化されていない接続を介して2者に既知の秘密を提供するにはどうすればよいですか？
秘密鍵と公開鍵のペアを使用しないと、Diffie-Hellmanが、盗聴される可能性のあるものを通過させることなく、インターネット上の2つの当事者間で秘密鍵を生成する方法がわかりません。これには、敵対的な領域を介してメッセージを送信する将軍に由来する用語があります。私はDHの背後にある数学や論理を理解しておらず、それがどのように可能であるかを理解できません。いつか私はもう一週間か二週間数学を勉強するでしょう、しかし私が確かめることができるまで、私は信頼することができません。さらに、公開秘密鍵のペアを使用して、はるかに少ないリスクで共有セッション鍵を確立できるのに、なぜそれを使用するのでしょうか。
一方、教育を受けていない大衆は、歴史的に熊手を進歩させてきました。私が5歳のように説明してください。DHは、MITMを介して傍受されることなく、暗号化されていない接続を介して2者に既知の秘密を提供するにはどうすればよいですか？
タイトルを次のように変更しました：「官民のキーペアがすでに配置されているのに、なぜDiffie-Hellmanが使用されるのですか？」
これが学生のためのDiffie-Hellmanです-5歳は対数を理解していません;-)
DHは2つのアイデアを使用しています。
- べき乗は高速ですが（2の3乗は8に等しい）、逆のプロセス（正確な対数）は非常に時間がかかります。実際には大きな数を取りますが、説明のためにここでは小さな数を取ります。
- べき乗は可換です。つまり、2の3乗の4乗は、2の4乗の3乗と同じです。
伝えたいと言ってください。一定の累乗する基数Aに同意します。そして、それはプライベートである必要はありません。お互いにAを送るだけです。
ここで、Bに大きな乱数を選択します。個別に、独自の大きな乱数を選択します。これをBと呼びます。そして、この合意された数をその大きな累乗に引き上げます。ここで、その中間結果を相互に送信します。そして今、私はあなたの中間結果を取り、それを私の大きな力に上げます。あなたは私の中間結果を取り、それをあなたの大きな力に上げます。私たちは両方とも同じ答えになってしまいます。
MITMは、Aと両方の中間結果が通過するのを確認しますが、妥当な時間内に逆のプロセスを実行することはできません。
彼は私たちが作り上げた私たちの力が何であったかを理解することはできません。したがって、乱数を選択し、それらを使用してその累乗に共通の値を上げ、それらの結果を交換し、再度実行することができます。両方ともまったく同じ値になり、それをキーとして使用できます。
実際には、Aには、大きいこと以外にいくつかの要件があります（たとえば、プライムである必要があります）。
クレジット： Security Nowエピソード34 のトランスクリプトに基づいて回答
Diffie-Hellmanは鍵交換アルゴリズムです。 goodの質問は、キーの交換です。はい、でも誰と交換しますか？
ネットワークの観点から、あなたは彼らがあなたに送るパケットを通してのみ他の人々を「見る」。そして、誰もが同じ種類のPCを購入できるので、誰もが同じパケットを送信できます--except一部の人/システムは、他の人が知らない値を知っている可能性があります。暗号化では、知識は力であり、あなたがあなたが知っていることを意味します。アリスとデータを交換し始めると、ボブではなくアリスと話していることがわかります。アリスは、特定の値を知っている誰かによってのみ計算された可能性のあるメッセージを送信できるためです。どういうわけか =その価値を知っている「アリス」と呼ばれる人と知らない「ボブ」と呼ばれる人がいることを知ってください。
モデルで、明確な知識を持つ可能性のある対話者が複数存在することを少なくとも定義していない場合、そのモデルの他のすべての人々がいるため、「中間者」の概念は意味がありません。 、同一です。 man-in-the-middle攻撃とその回避方法について話したい場合は、最初に誰と話したいかを定義する必要があります。これには、攻撃者が知らない、そのシステム/人が知っていることを指定する必要があります。
簡単に言うと、MitMは、攻撃者が他の誰かの身元を推測する、なりすまし（二重のなりすましでも）の特殊なケースです。したがって、MitM攻撃について説明する前に、「アイデンティティ」の概念が必要です。
ここで、アイデンティティの概念を定義したとします。例えば。あなたはWebブラウザであり、URL https://www.example.com/foobar.htmlに到達しようとしています。その場合、IDの概念は、「 [〜＃〜] dns [〜＃〜] "に登録されているwww.example.comサーバーを制御する人です。
Diffie-Hellman は鍵交換アルゴリズムです。これは、それ自体にはいかなる種類の認証も含まれていないことを意味します。これは、DHが役に立たないという意味ではありません。 単独取得しようとしているセキュリティ機能全体を提供する可能性が低いということだけです。実際には、いくつかの暗号化アルゴリズムは、 SSL/TLS などのプロトコルに組み込まれています。
例に戻ると、Diffie-HellmanはSSL/TLSで実際に広く使用されており、「DHE」暗号スイートが使用されています。暗号化の塔全体は次のようになります。
- サーバーには、signatures（RSA、DSA、ECDSA ...）に適した公開鍵と秘密鍵のペアがあります。
- サーバーはDH鍵交換の半分を生成し、次に署名（署名秘密鍵を使用）して、それをクライアントに送信します。
- サーバーは、一部のCAによって発行された証明書として、署名公開鍵もクライアントに送信します。
- クライアントは証明書を検証し（クライアントはすでにCAを認識して信頼しているため）、サーバーの公開鍵を学習します。
- クライアントは、サーバーの証明書に予期されたサーバー名（ここでは
www.example.com）が含まれていることを確認します。 - クライアントは、サーバーの公開鍵を使用して、サーバーから送信されたハーフDHの署名を検証します。
- クライアントは独自のハーフDHを計算し、それをサーバーに送信します。
- クライアントとサーバーはDH計算を完了し、共有シークレットを取得します。共有シークレットは、すべてのデータを暗号化するための対称キーに展開されます。
IDの概念クライアントが使用するのは、サーバーの所有者は、関連するドメインを効果的に制御しない限り、信頼できるCAから有効な証明書を取得できないということです。したがって、クライアントの観点から見ると、「本物のwww.example.comサーバー」とは、「信頼できるCAからの証明書の公開鍵に対応し、www.example.com名を含む秘密鍵を知っている人」です。 。秘密鍵の知識は、サーバーを「正しいもの」にするものです。 CAは、そのキー（具体的には公開キー）をDNS名にリンクします。
ここでMitMから保護するのは、中間者が秘密鍵を知らないことです（彼は自分の秘密鍵を生成できますが、証明書の公開鍵とは一致しません）。 signatureは、この保護が実施されるメカニズムです。それは、その保護を提供するDiffie-Hellmanではありません。一方、署名は共有シークレットにはなりません。それがDHの仕事です。
概要：特定のサーバーとの共有シークレットを取得して、そのサーバーに送信するギガバイトのデータを暗号化できるようにします。これは2つの部分からなるジョブです。必要なのは共有シークレットですが、特定のサーバーを使用するである必要もあります。 DHは「共有秘密」の部分を実行します。他の部分には何か他のものが必要です。いくつかの署名アルゴリズム。これはSSLまたはSSHで起こることです。
Diffie-Hellman自体は、認証を提供しません。
確かに、2つのパーティがDHとキーについて合意した場合、トラフィックをスニッフィングしているだけのサードパーティは、交換された秘密キーを見つけることができません。
ただし、DHは、同じ公開パラメータで2つの鍵交換を作成するアクティブなMITMによって攻撃される可能性があります。 1つはクライアントからMITMに、もう1つはMITMからサーバーに送信されます。この場合、MITMはクライアントとサーバーの両方をだまして、お互いに話していると思い込ませます。
サーバーがDHまたはその楕円曲線バリアントを使用する場合、認証がRSA /（EC）DSAおよび秘密鍵インフラストラクチャによって提供されている間、サーバーはDHまたはその楕円曲線バリアントを一時的に使用する傾向があります。 （通常はX509証明書）ここでのエフェメラル（EC）DHの理由は、転送秘密を提供するためです。つまり、サーバーの秘密鍵が将来のある時点で盗まれた場合、過去に発生したセッション（およびスニッフィングパーティによってログに記録されたもの）は、遡及的に復号化することはできません。
編集：私は固定DHの使用について言及するのを忘れました。この場合、公開パラメーターとサーバーの秘密DHキーから派生したキーが証明書に含まれています。この場合、サーバーの秘密DHキーは、公開パラメーターからも公開キーからも取得できず、証明書によって認証が提供されます。 （秘密鍵を知っているのはサーバーだけです）。
そうは言っても、私は実際に固定されたDH証明書を見たことがありません。ほとんどの場合、上記のようにForwardSecrecyのために一時的に使用されます。