IKEv2 鍵交換の動作：SA 確立フェーズとリキー

IKEv2 が解く問題

IPsec は AH/ESP でパケットを暗号化・認証しますが、その前提となる「どの鍵で、どのアルゴリズムで守るか」を両端で安全に合意する仕組みが必要です。その合意を担うのが鍵交換プロトコル IKEv2（RFC 7296）です。IKEv1 が主モード/アグレッシブモードや複数フェーズで複雑だったのに対し、IKEv2 は 2往復（4メッセージ） で制御チャネルと最初のデータ用 SA をまとめて立ち上げる、簡潔で堅牢な設計に作り替えられました。VPN 全体像は /network/vpn/ を参照してください。

ここでいう SA（Security Association） とは、片方向の暗号パラメータ一式（アルゴリズム・鍵・寿命・対象トラフィック）をまとめた状態です。IKEv2 では2種類の SA を区別します。

第1往復：IKE_SA_INIT で鍵の土台を作る

最初の交換 IKE_SA_INIT は平文で行われ、ここでアルゴリズムの合意と Diffie-Hellman 鍵共有を済ませます。--> がイニシエータ送信、<-- がレスポンダ送信です。

-->  HDR, SAi1, KEi, Ni
       SAi1 : 提案する暗号スイート群（暗号/PRF/整合性/DHグループ）
       KEi  : イニシエータの DH 公開値
       Ni   : イニシエータのノンス
<--  HDR, SAr1, KEr, Nr
       SAr1 : レスポンダが選んだ1組のスイート
       KEr  : レスポンダの DH 公開値
       Nr   : レスポンダのノンス

DH 鍵共有の原理は ECDHE と同じで、両者は秘密値 a,b と公開値だけを交換し、共有秘密 g^ab を各自で計算します（詳細は /network/tls13-handshake-internals/ の鍵共有節と共通）。この共有秘密とノンスから、すべての鍵の種となる SKEYSEED を導きます。

SKEYSEED = prf( Ni | Nr , g^ab )

ここで prf は合意した疑似乱数関数（HMAC-SHA256 など）です。ノンスを混ぜるのは、過去のセッションと鍵が衝突しないようにする鮮度確保のためです。

SKEYSEED から鍵を派生する

SKEYSEED 単体では鍵に使わず、prf+（出力を繰り返し連結して任意長を作る拡張）で 7本の鍵 を一括導出します。順序は仕様で固定されています。

{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
  = prf+( SKEYSEED , Ni | Nr | SPIi | SPIr )

各鍵の用途は次の通りです。SK_d だけは Child SA の鍵材料の元になり、残りは IKE SA 自身の保護に使います。

第2往復：IKE_AUTH で認証し Child SA を作る

第1往復では鍵を作りましたが、相手が本物かはまだ確認していません（DH 単体は中間者攻撃に弱い）。IKE_AUTH で相互認証を行い、同時に最初の Child SA を確立します。メッセージ本体は SK_e/SK_a で保護されます。

-->  HDR, SK{ IDi, [CERT,] AUTH, SAi2, TSi, TSr }
<--  HDR, SK{ IDr, [CERT,] AUTH, SAr2, TSi, TSr }
       IDi/IDr : 各自の識別子
       AUTH    : 相手を認証する署名 or PSK ベースの値
       SAi2/SAr2 : Child SA 用の提案/選択
       TSi/TSr : Traffic Selector（どの IP/ポート範囲を守るか）

認証の核心は AUTH ペイロード です。各端は「自分が送った IKE_SA_INIT メッセージ全体＋相手のノンス＋prf(SK_p, ID)」を1つの文字列にまとめ、それに対して署名（証明書認証）または PSK ベースの MAC を計算します。

AUTH = sig_or_prf( 自分の最初のIKEメッセージ | 相手のNonce | prf(SK_p, IDx) )

相手はこの AUTH を検証することで、(1) 通信相手が秘密鍵/PSK を持つ正当な相手であり、(2) IKE_SA_INIT が改ざんされていない（ダウングレードされていない）ことを同時に確認します。鍵共有と完全性検証が最初の交換に束ねられている点が、TLS 1.3 と共通する堅牢性の根拠です。

Child SA の実際の暗号鍵は、ここでも SKEYSEED ではなく SK_d から派生します。

KEYMAT = prf+( SK_d , Ni | Nr )

IKE_AUTH 内で作るこの最初の Child SA は KE ペイロードを持たないため、上の式どおり SK_d とノンスだけで KEYMAT を導きます。ただし SK_d は IKE_SA_INIT の DH 共有秘密に由来するため、この Child SA も IKE SA 確立時の前方秘匿性を引き継いでいます。後から CREATE_CHILD_SA で 新たな DH 交換 を加えれば、KEYMAT = prf+(SK_d, g^ir_new | Ni | Nr) のように Child SA ごとに新鮮な共有秘密を混ぜられ（PFS）、IKE SA の鍵が将来漏れてもその Child SA の過去トラフィックは復号されません。

デッドピア検出（DPD）

確立後、相手が突然落ちても TCP のような明示的な切断は飛んできません。IKEv2 は DPD を、専用メッセージではなく INFORMATIONAL 交換の空リクエスト＋応答（liveness check） で実現します。

-->  HDR, SK{ }          ← 中身は空。これだけで「生きてる?」の問い
<--  HDR, SK{ }          ← 応答が返れば相手は生存

応答が一定回数返らなければピアは死んだとみなし、SA を破棄します。重要なのは DPD はオンデマンドで送るのが定石 という点で、常時ポーリングするのではなく「送るデータがあるのに ESP の応答が来ない」状況で初めて liveness を確認すると、無駄なトラフィックを避けられます。

リキー：無停止で鍵を入れ替える

SA には 寿命（ライフタイム） があり、時間または転送バイト量で上限に達する前に鍵を更新します。これが リキー（rekey） で、CREATE_CHILD_SA 交換で行います。鍵交換用と実データ用の両方が対象です。

-->  HDR, SK{ SA, Ni, [KEi,] [TSi, TSr] }
<--  HDR, SK{ SA, Nr, [KEr,] [TSi, TSr] }
       KEi/KEr を含めれば新規 DH 交換 = PFS つきリキー
       含めなければ既存の SK_d から派生（軽量だが PFS なし）

新しい SA が立ち上がってから旧 SA を Delete ペイロード で破棄するため、データプレーンは一瞬も止まりません。バイト量ベースの寿命を併用するのは、長時間でも大量転送で同じ鍵を使い続けると暗号解析のリスクが上がるためで、時間とデータ量のどちらか早い方で更新するのが安全です。

まとめ：4メッセージに凝縮された設計

IKEv2 は、IKE_SA_INIT で「鍵の土台（DH＋SKEYSEED）」を、IKE_AUTH で「相互認証＋最初の Child SA」を作り、わずか2往復で制御チャネルとデータチャネルを同時に立ち上げます。確立後は DPD で生存を確認し、CREATE_CHILD_SA で前方秘匿性を保ちながら無停止に鍵を更新し続けます。UDP の上で動く理由やトランスポート選択の背景は /network/tcp-udp/ を、暗号化通信の基礎概念は /network/tls/ を併読すると、IPsec が「いつ・どの鍵で・何を守るか」を一貫した状態機械として把握できます。