私はASA 8.0でIPsec VPNを行っていましたが、それについて少し理解しています。イニシエーターはISAKMPポリシーをレスポンダに送信することから始め、レスポンダは一致したポリシーを返信します。その後、Diffie-Hellman鍵が交換され、両方が事前共有鍵を相手に送信して認証を行います。
これで2つのキーができました。
- 1つはAES暗号化によって生成されます
- 1つはDiffie-Hellmanグループによって生成されます
事前共有キーの暗号化にはどのキーが使用されますか？
私はASA 8.0でIPsec VPNを行っていましたが、それについて少し理解しています。イニシエーターはISAKMPポリシーをレスポンダに送信することから始め、レスポンダは一致したポリシーを返信します。その後、Diffie-Hellman鍵が交換され、両方が事前共有鍵を相手に送信して認証を行います。
これで2つのキーができました。
事前共有キーの暗号化にはどのキーが使用されますか？
回答:
あなたは素晴らしい質問をしました。質問は非常に単純に見えますが、実際には答えはやや複雑です。簡潔に回答できるように頑張ります。また、あなたはISAKMPについて言及したので、あなたはIKEv1に興味があると思います。物事はIKEv2で少し変更されます（まあ、多くの）、しかし私はIKEv1にのみ相関する以下の答えに言及したいと思いました。
フェーズ1は、メインモードとアグレッシブモードの2つの異なるmodで実行できます。どちらのモードでも、最初のメッセージはイニシエーターによって送信され、2番目のメッセージはレスポンダによって送信されます。これらのメッセージには、暗号化の世界でナンスと呼ばれるものが含まれています。Nonceは、キーの生成に使用するランダムに生成された数値です。 （Nonceという用語は_N_umber used _Once_に由来します）。したがって、メッセージ1とメッセージ2の後、両側はお互いのナンスを知っています。
Nonceと事前共有キーを組み合わせて、秘密キーを生成するためのシード値を作成します。IKE RFCの相対的な部分はここにあります：
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYIDは、後で追加の秘密鍵を生成するために使用されるシード値です。事前共有キーと両方のノンス値（Ni_bはイニシエーターのノンス、Nr_Bはレスポンダーのノンスです）は、PRFまたは疑似ランダム関数を使用して結合されます。PRFはハッシュアルゴリズムに似ていますが、結果が必要なビット数になる場合がある点が異なります。
ここで、最初にメインモードを実行していた場合、メッセージ3と4は、イニシエーターとレスポンダーの（それぞれ）Diffie-Hellman公開鍵を共有します。どちらもこれらの値を使用して、Diffie-Hellman 共有秘密を生成します。アグレッシブモードを実行していた場合、これらのDHパブリック値もメッセージ1とメッセージ2に含まれます（ナンスとともに）。
次に、シード値をDH共有シークレット（および他のいくつかの値）と組み合わせて、3つのセッションキー（派生キー、認証キー、および暗号化キー）を作成します。RFCは次のように述べています。
メインモードまたはアグレッシブモードの結果は、認証されたキー情報の3つのグループになります。
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d、_a、および_eは、上記の3つのセッションキーです。 SKEYIDシード値です。 g^xyDH共有秘密です。CKY-IそしてCKI-Rイニシエータとレスポンダクッキーあり、これらは、この特定のISAKMP交換及びセキュリティアソシエーションを識別するために後で使用されるだけで、追加のランダムに生成された値です。 0 1 20、1、2のリテラル番号|です。パイプ記号は連結を表します。
いずれの場合も、これらの値はすべて、3つのセッションキーを作成するPRFを使用して結合されます。
認証キーと暗号化キーは、その後のフェーズ2ネゴシエーションを保護/暗号化するために使用されます。メインモードでは、フェーズ1のメッセージ5と6もこれらのキーによって保護されます。さらに、将来のISAKMP情報交換（DPD、Rekeyイベント、Deleteメッセージなど）も、これら2つのキーによって保護されます。
派生キーはIPsecに渡され、IPsecはこのキーから独自のキー生成情報を生成します。思い出してください。IPsecには元々キー交換メカニズムが含まれていないため、IPsecが秘密キーを取得する唯一の方法は、手動で設定するか（これは古く、実際には行われません）、または外部サービスに依存することです。 ISAKMPのようなキー情報を提供します。
RFCは次のように述べています。
SKEYID_eは、ISAKMP SAがメッセージの機密性を保護するために使用するキー情報です。
SKEYID_aは、ISAKMP SAがメッセージを認証するために使用するキー情報です。
SKEYID_dは、ISAKMP以外のセキュリティアソシエーションのキーを取得するために使用されるキー情報です。
以上のことから、質問をもう一度参照できます。事前共有キーを保護するためにどのキーが使用されていますか？
メインモードでは、事前共有キー（PSK）はメッセージ5および6で確認されます。メッセージ5および6は、前述のISAKMPが生成するセッションキーによって保護されます。
アグレッシブモードでは、ネゴシエーションのメッセージは暗号化されません。そして、PSKは、メッセージ2と3の通知で検証されて、私はPSKがされて両方のケースで述べて検証し、そして私はPSKがされたことはありません交換します。明らかに、アグレッシブモードで何も暗号化されておらず、暗号化されていない状態で事前共有キーをネットワーク経由で送信しただけの場合、大きなセキュリティ上の脆弱性が存在します。
幸運なことに、ISAKMPの作者はすでにそのことを考えていました。その結果、彼らは実際にネットワーク上でそれを共有することなく、各当事者が正しいPSKを持っていることを確認するための特別な方法を作成しました。：彼らの両方が同じPSK持っていることを各ピアに検証するために使用されている二つの項目がありますアイデンティティ方法とアイデンティティハッシュ。
VPNピアは、さまざまな方法で自身を識別することを選択できます。最も一般的には、ピアはソースIPアドレスを使用するだけです。ただし、FQDNまたはホスト名を使用するオプションがあります。これらのそれぞれが、選択されたメソッドの相関値とともに、Identityメソッドを構成します。したがって、たとえば、IP 5.5.5.5があり、自分のIPアドレスを使用して自分自身を識別したい場合、IDメソッドは[IPアドレス、5.5.5.5]になります。 （注：両方の値がIDメソッド全体を構成します）
次に、IDメソッドを（PRFを使用して）前に説明したシード値（SKEYID）および他のいくつかの値と組み合わせて、アイデンティティハッシュを作成します。最初にSKEYIDを作成したのは事前共有キーだったことを思い出してください。
次に、IDメソッドとIDハッシュがネットワーク経由で送信され、相手は同じ式を使用してIDハッシュを再作成しようとします。受信者が同じIDハッシュを再作成できる場合は、送信者が正しい事前共有キーを持っている必要があることを受信者に証明します。
これは、ここのRFCで説明されています。
どちらかの交換を認証するために、プロトコルのイニシエーターはHASH_Iを生成し、レスポンダーはHASH_Rを生成します。
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
IDiiとIDirはIDメソッドです。また、HASH_IとHASH_Rは、イニシエーターとレスポンダーのハッシュです。これらは両方ともフェーズ1で共有されます。RFCから：
事前共有キー認証を行う場合、メインモードは次のように定義されます。
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R事前共有キーを使用したアグレッシブモードは次のとおりです。
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
そして今、私たちはようやくあなたの質問に完全に答えることができます：
Pre-Shared-KeyはPRFとNoncesを使用して結合され、交渉で他の誰にも知られている他の値の束です。結果は、両方の当事者が同じ値（別名、同じ事前共有鍵）で開始した場合にのみ、2つの当事者が相互に達成できる値です。結果として得られる値は、ネットワーク上で共有されるものであり、事前共有キー自体に関する情報を実際に公開することなく、2つのパーティが一致する事前共有キーを持っていることを確認できます。
メインモードは、上記の「結果の値」の交換も暗号化することにより、より安全な一歩を踏み出し、事前共有キーが何であったかに関する有用な情報を抽出することをさらに困難にします。
（私はこれを簡潔に答えることに無惨に失敗したようです）
あなたの答えはあなたの質問にあります：Diffie-Hellman交換は、共通鍵を安全に交換するために共通鍵を生成するために使用されます（つまり、事前共有）。
これを参照してください：https : //security.stackexchange.com/questions/67953/understanding-diffie-hellman-key-exchange