私は現在、IPsecに使用されるIKEv2プロトコルを理解しようとしており、認証プロセスが機能する理由/方法について疑問に思っています。
私の理解では、以前のIKE_SA_INIT交換では、イニシエーターとレスポンダーが暗号スイートについて合意し、お互いにDH値とナンスを送信します。
次のIKE_AUTH交換では、ピアのIDを相互に検証することになっています。プロトコルは、DH値とノンスを使用して計算された共有秘密SKEYSEEDから多くの鍵を導き出しました。
IKE_AUTH交換では、キーペアの1つを使用して、基本的にデータのブロックに署名します-以前のIKE_SA_INIT交換のコピー、ピアのノンスおよびprf(SK、ID)。
DH値とナンスがIKE_SA_INIT交換で認証されずに暗号化されずに送信されるため、攻撃者が反対の通信パートナーのIDを偽装してMitM攻撃を実行できないのはなぜですか?
プロトコルのどの時点で、このようなMitM攻撃が発生しますか。 DH値を置き換え、反対側で認識されますか?
事前にどうもありがとうございました!
DHのポイントは、2つの当事者だけが共有秘密(gxy)DH交換用。 SKEYSEED
は、DH交換の共有秘密ではありません。実際には、DH共有シークレットとナンスから派生しています。送信されたDHパラメータからではありません。 SKEYSEED
がネットワーク経由で送信されることはありません。
DH交換が完了し、暗号化/整合性キーが生成されると、AUTHメッセージを使用して各サイドのIDが証明されます。
イニシエーターはIDiペイロードを使用してIDをアサートし、IDiに対応する秘密の知識を証明し、整合性はAUTHペイロードを使用して最初のメッセージの内容を保護します( セクション2.15 を参照)。また、証明書をCERTペイロードで送信し、トラストアンカーのリストをCERTREQペイロードで送信する場合もあります。 CERTペイロードが含まれている場合、提供される最初の証明書には、AUTHフィールドの確認に使用される公開鍵が含まれている必要があります。
MitM攻撃が機能するためには、DH共有秘密を知る必要があります。 DHパラメータを単純に置き換えることはできません。交換される値はgバツ mod pおよびgy mod p。 x
またはy
を知っている必要があります。これらは 簡単に計算されない です。
交渉の一方を偽装することもできますが、それは実際にはMitMではありません。また、IKEv2は、この種の攻撃から保護するものではありません。それがファイアウォールルールの仕事です。