【FAQ】IPsecのあるある疑問をパパっと解消

そもそもIPsecって何？

IPsecとは？

IPsec (IP Security) は、インターネット上でデータを安全にやり取りするための仕組みです。
普段のインターネット通信は、基本的に暗号化されていないため、悪意のある第三者にデータを盗み見られたり、改ざんされたりするリスクがあります。

IPsecは、こうしたリスクからデータを守るために、以下のようなセキュリティ機能を提供します：

1. 暗号化 (Encryption) → データを暗号化して、盗み見を防ぐ
2. 完全性 (Integrity) → データが改ざんされていないかチェック
3. 認証 (Authentication) → データの送信者・受信者が本物か確認

つまり、IPsecを使うと、安全な通信トンネルを作れるということです！

VPNとは？

VPN (Virtual Private Network) は、インターネット上に仮想的な専用線を作る技術です。

たとえば、会社のネットワークに外出先からアクセスしたい場合、そのままインターネット経由でつなぐと、セキュリティが不安ですよね。VPNを使うと、暗号化されたトンネルを作り、まるで直接会社のネットワークにつながっているかのように安全に通信できます。

VPNにはいくつかの方式がありますが、IPsec VPNは特に強力なセキュリティを持つため、企業の拠点間通信やリモートアクセスによく使われます。

IPsecとVPNの関係

VPNは、あくまで「インターネット上に仮想的な専用線を作る仕組み」ですが、実際にデータを暗号化したり保護する役割は、IPsecなどのプロトコルが担います。

つまり、VPNを作るためのセキュリティ技術の1つがIPsecというイメージです！
特に、IPsec VPNは安全性が高く、以下の2つのモードで通信を保護します：

• トランスポートモード → データ部分だけ暗号化 (主にサーバ同士の直接通信で使う)
• トンネルモード → IPパケット全体を暗号化 (拠点間VPNやリモートアクセスで使う)

具体的なイメージ

たとえば、以下のような状況を考えましょう：

• 東京本社と大阪支社をインターネットでつなぎたい
• 通信内容は、部外者に見られたり改ざんされたくない

ここでIPsec VPNを使うと、次のように通信できます！

1. VPNゲートウェイ (ルータなど) がIPsecを使って暗号化通信トンネルを作る
2. インターネットを通るデータは暗号化されていて、盗み見されても中身はわからない
3. 改ざんチェックもあるので、途中でデータをすり替えられても検知できる
4. お互いに認証し合うので、通信相手が本当に正しい拠点かも確認できる

結果、インターネットを使いながら、まるで専用回線のように安全な通信ができるんです！

まとめ

• IPsec → データを暗号化・認証して、安全な通信を実現する技術
• VPN → インターネット上に仮想的な専用線を作る技術
• IPsec VPN → IPsecを使って、暗号化された安全な通信トンネルを作る仕組み

企業ネットワークやリモートワーク、拠点間通信など、セキュリティが重要なシーンでよく使われます！

もし、「実際のパケットの流れ」や「IPsecの具体的な設定例」など、もっと詳しく知りたいところがあれば、ぜひ教えてくださいね！✨ 🚀

IPsecとESPの関係は？また、IPsecとIKEの関係は？

IPsecとESPの関係

まず、基本的な構成を確認しましょう。

• IPsec → インターネット上で安全な通信を行うためのフレームワーク（枠組み・プロトコルセット）
  • 実際にデータを暗号化・認証する役割を担うのがESP (Encapsulating Security Payload) です。
  • ESPはIPsecのデータ保護部分を担当しているプロトコルと考えればOK！

つまり：

• IPsecがセキュリティ全体の仕組み
• ESPがデータを暗号化・保護するプロトコル

同じように、IPsecの鍵交換を担当するのがIKE (Internet Key Exchange) です！

IKEv2とは？

IKEv2 (Internet Key Exchange version 2) は、IPsecで安全に通信するための鍵交換プロトコルです。

IPsecで暗号化通信をするとき、お互いの端末が同じ暗号鍵を持っていないといけません。でも、ネットワーク上で鍵を直接やりとりすると盗まれるリスクがあります。そこで、安全に鍵を交換する仕組みとしてIKEv2が使われます。

IKEv2がやることは大きく3つ：

1. セキュリティパラメータのネゴシエーション → 使う暗号アルゴリズムや認証方式をお互いに決める
2. 鍵の交換 → 鍵交換アルゴリズム (Diffie-Hellman など) を使って、安全に暗号鍵を共有
3. SA (Security Association) の管理 → IPsecセッションの暗号化ルールや鍵のライフタイムを管理

IPsecとIKEv2の関係はこう考える！

• IPsec → データを安全に送る仕組み
• ESP → データそのものを暗号化・認証するプロトコル
• IKEv2 → IPsecで使う暗号鍵やルールを決めて管理するプロトコル

つまり、IKEv2が暗号鍵を交換し、ESPがその鍵を使ってデータを暗号化・保護するという流れになります！

鍵交換のフェーズで中間者攻撃される危険性もあるよね？

IKEv2 鍵交換の前のやり取りは本当に危険？

確かに、最初の IKE_SA_INIT メッセージは暗号化されていないので、攻撃者はパケットを盗聴したり改ざんすることが技術的には可能です。例えば、以下のようなことが考えられます：

• アルゴリズムダウングレード攻撃 → 攻撃者が強力な暗号アルゴリズムを弱いものに書き換える
• 公開鍵のすり替え → 攻撃者が自分の Diffie-Hellman 鍵を送りつけ、通信を解読できるようにする

でも、実際にはこれらの攻撃は、IKEv2 の設計上成功しない ようになっています。その理由を詳しく解説します！

IKEv2 が中間者攻撃を防ぐ仕組み

① Diffie-Hellman (DH) 鍵交換

最初の IKE_SA_INIT で行われる鍵交換は、Diffie-Hellman (DH) アルゴリズム を使います。この仕組み自体が強力な耐性を持っています。

• 公開鍵 はやり取りしますが、そこから実際の共有鍵を計算するには、離散対数問題という非常に難しい数学問題を解かなければなりません。現在の計算能力では、これを解読するのは事実上不可能です。
• たとえ攻撃者が通信を傍受していたとしても、共有鍵自体は絶対に復元できません。

つまり、攻撃者が公開鍵を盗んでも、共通鍵 (セッションキー) を知ることはできないんです！

② Nonce (ノンス) とハッシュの検証

お互いが Nonce (一度きりのランダム値) を交換することで、ハッシュ検証 を行います。これは通信の完全性を守るための仕組みです。

• IKE_AUTH のとき、お互いの ID と、先ほど生成した共有鍵、そして Nonce を組み合わせたハッシュ値を計算します。
• このハッシュは HMAC (ハッシュベースのメッセージ認証コード) を使って計算されるので、攻撃者が途中でデータを改ざんすると、ハッシュ検証に失敗して接続が即座に拒否されます。

これで、データ改ざんは検出できるので、攻撃者がパラメータを書き換えることはできません。

③ デジタル署名 & 証明書 (ID 認証)

IKE_AUTH フェーズでは、お互いに デジタル署名 や 証明書 を交換します。これによって、なりすまし を防ぎます。

例えば：

• 双方が PKI (公開鍵基盤) を使った証明書を交換する場合、相手の ID に対する署名をチェックします。
• 攻撃者が偽の公開鍵を送りつけても、正しい署名を生成できないので、すぐに検出されます。

これで、「攻撃者が鍵をすり替える」攻撃も無力化されます！

④ 暗号アルゴリズムのネゴシエーションの保護

IKEv2 では、最初にお互いの使える暗号アルゴリズムを提案し合いますが、これが攻撃者に書き換えられると危険ですよね。これについても、安全策があります。

• IKE_AUTH で、提案したアルゴリズムのリスト自体もハッシュに含めて検証します。
• 攻撃者がアルゴリズムをすり替えても、ハッシュチェックで不一致が起きて即座に失敗します。

これにより、アルゴリズムダウングレード攻撃も防がれます。

まとめ：IKEv2 が中間者攻撃に強い理由

IKEv2 は、最初の通信が暗号化されていなくても、以下の仕組みで中間者攻撃を防ぎます：

1. Diffie-Hellman 鍵交換 → 盗聴されても共有鍵は解読不可能
2. Nonce & ハッシュ検証 → データの改ざんを即座に検出
3. デジタル署名 & 証明書 → なりすまし攻撃を防止
4. アルゴリズムネゴシエーションの保護 → 暗号強度の弱体化を防ぐ

これらが連携することで、攻撃者は鍵交換前にいくらパケットを盗み見たり改ざんしようとしても、最終的な認証やハッシュチェックに失敗して、IKE SA の確立自体が不可能になるんです！

つまり、IKEv2 は最初の平文通信さえも慎重に守っていて、攻撃者が入り込もうとしても失敗する設計になっています。

フェーズ1 (IKE-SA) で Diffie-Hellman で鍵を共有できるなら、それだけで直接 IPsec のパラメータ交換して、そのまま通信開始すればよくない？

ざっくり言えば「フェーズ1 で鍵交換したなら、もうそれで通信始めればいいんじゃ？」って考えは理屈としては理解できます。でも、IKEv2 がわざわざ IKE-SA と Child-SA を分けてるのにはちゃんと理由があります！

これをしっかり理解すると、「なぜフェーズを分けるのか」がクリアになります！一緒に見ていきましょう！

まず前提整理：フェーズ1 とフェーズ2 の役割

• IKE-SA (フェーズ1) → IKE セッション自体を暗号化 & 認証
  • Diffie-Hellman (DH) を使って 共有秘密鍵 (SK_d, SK_ai, SK_ar) を作る
  • この鍵で IKE メッセージ自体を暗号化する
  • ここは「鍵交換するための安全なトンネルを作る」役割
• Child-SA (フェーズ2) → 実際の IPsec トンネルのパラメータ交換 & 鍵生成
  • 暗号化アルゴリズム (AES, ChaCha20 など)
  • 認証アルゴリズム (HMAC, SHA-256 など)
  • IPsec セッション用の鍵 を生成

なぜ IKE-SA だけじゃダメなのか？

1. IKE-SA の鍵は IKE 用、データ通信には向かない

IKE-SA で作った鍵 (SK_d) をそのまま IPsec 通信で使ってしまうと、もし将来この鍵が漏れたときに、過去の IKE 交渉内容も IPsec データも全部解読されるリスクがあります。

→ そこで、フェーズ2 で新しい鍵を作ることで、IKE の鍵と IPsec の鍵を完全に分離します。
これが Perfect Forward Secrecy (PFS) の考え方です！

2. 複数の Child-SA を作れる柔軟性

Child-SA を分けることで、複数の IPsec セッションを独立して管理できるんです。例えば：

• 1つ目の Child-SA → 本社 ↔ 支社 の通常通信 (AES-256, SHA-256)
• 2つ目の Child-SA → 支社 ↔ データセンター の通信 (AES-GCM, SHA-512)

もし 1つの IPsec セッションが何かしらの理由で壊れたり、鍵が古くなったりしても、他のセッションには影響が出ません。これもセキュリティと耐障害性を高める重要なポイントです。

3. 鍵の再生成・ローテーションがスムーズ

もし IPsec の鍵を一定期間ごとに 再生成 するとき、フェーズ2 (Child-SA) を独立しておけば：

• Child-SA だけを再ネゴシエーションして、新しい鍵を作成
• IKE-SA は維持したまま、鍵のローテーションができる

つまり、鍵交換のオーバーヘッドを最小限にしつつ、定期的な鍵更新でセキュリティを強化できます。

4. フェーズ1 だけだと IPsec の細かい制御が難しい

Child-SA では、IPsec の細かいパラメータ (プロトコル, ポート, サブネット) を決めます。
例えば：

• 10.0.0.0/24 → 192.168.1.0/24 の通信だけ IPsec
• ポート 443 (HTTPS) だけ暗号化する

フェーズ1 だけで終わらせてしまうと、こうした柔軟なポリシー制御が難しくなります。Child-SA を分けることで、複数の通信ルールを個別に管理できるわけです！

まとめ：フェーズを分ける意味

ざっくりまとめると：

もしフェーズ1だけで済ませると？

仮にフェーズ2 を省略してフェーズ1だけでやると：

• 鍵漏洩時のリスク爆増 → 1つ漏れたら IKE も IPsec も全部解読される
• 鍵更新が重すぎる → 定期的に IKE をやり直す必要あり
• ポリシー柔軟性が低下 → 1つのトンネルで全部まとめるしかない

これだと、セキュリティも運用効率も悪くなっちゃいます。

結論：フェーズを分けることでセキュリティと運用性を両立

結局のところ、IKE-SA と Child-SA を分けることで：

• PFS (完全前方秘匿性) を実現しつつ、
• 複数セッションを独立管理できて、
• 鍵更新も軽くて素早くできる

という、セキュリティ・柔軟性・パフォーマンスのバランスが取れているんです！

フェーズ１の鍵が漏洩したら、元も子もないんじゃない？

「フェーズ1の鍵（IKE-SAの鍵）が漏れたら、フェーズ2（Child-SA）の内容もバレるんじゃない？」って思いますよね。これ、本当にそのとおりで、フェーズ1の鍵が漏れたら Child-SA のやり取りも解読されてしまいます。

でも、ここにいくつか重要なポイントがあります。なぜフェーズを分けているのか、鍵漏えいリスクとどう向き合っているのか、一つずつ解説しますね！

前提確認：フェーズ1とフェーズ2の関係

• フェーズ1 (IKE-SA)
  • IKE メッセージ自体を暗号化するための鍵を作成
  • Diffie-Hellman (DH) 交換で共有秘密を作成
  • 認証情報を交換して相手を確認 (証明書や事前共有鍵)
• フェーズ2 (Child-SA)
  • IPsec 通信用の暗号鍵や暗号アルゴリズム、パラメータを交換
  • 実際のデータ通信用の鍵をフェーズ1で作った鍵から派生して作成

つまり、フェーズ2のやり取り自体がフェーズ1の鍵で暗号化されています。なので、フェーズ1の鍵が漏れると、フェーズ2の鍵やパラメータも解読可能です。

鍵漏えい時のリスクと設計思想

1. Diffie-Hellman の鍵交換自体は超強力

まず、フェーズ1の鍵は Diffie-Hellman (DH) を使って交換しています。DH 自体は、中間者攻撃が防げて、過去の通信データだけでは鍵を逆算できない設計です。なので、攻撃者が盗聴していても、リアルタイムで鍵を解読するのは事実上不可能です。

→ 鍵漏えいのリスクは、実際にはデバイスの侵害や脆弱性の悪用の方が現実的です。

2. Perfect Forward Secrecy (PFS) の意味

フェーズ2で新しく鍵を作るのは、仮に1つのセッション鍵が漏れても、他のセッションには影響を与えないようにするためです。

• Child-SA の鍵が漏れる → そのセッションだけ解読される
• フェーズ1の鍵が漏れる → そのフェーズで作られた Child-SA は漏れるが、次回の IKE-SA では新しい鍵が生成される

つまり、フェーズ1の鍵が漏れても、その瞬間のやり取りは危険でも、次回のセッションには影響しないわけです。

3. フェーズ1鍵の漏えいは超クリティカルだけど短命

フェーズ1で作る IKE-SA の鍵は、一定時間ごとに自動で再生成します。例えば：

• 30分ごとに IKE-SA を再ネゴシエーションする
• 新しい DH 鍵交換で新しい鍵を作る

これで、仮にフェーズ1の鍵が漏えいしても、攻撃者が解読できるのは短時間だけになります。次の鍵交換ではまったく新しい鍵が使われるので、漏れた鍵はすぐに無効化されます。

4. 鍵漏えいの現実的な経路

実際にフェーズ1の鍵が漏れるとしたら、以下のケースが考えられます：

• エンドポイントの侵害 → PC やルーターにマルウェアが仕込まれて鍵が盗まれる
• 脆弱性の悪用 → 古い暗号アルゴリズム (例: DH Group 1) の脆弱性を突く
• 物理的攻撃 → デバイスを盗まれる、証明書が物理的に抜き取られる

でも、この場合はそもそも IKE-SA の鍵だけでなく、他のセッション鍵や認証情報も抜かれる可能性が高いです。だからこそ、フェーズを分けて鍵更新を短期間で行うことでリスクを局所化しているんですね。

フェーズ1鍵漏えい時の対策

1. 短い SA ライフタイム設定

• IKE-SA の有効期間を短くする (例: 30分)
• 短時間で鍵を再生成して被害を最小化

2. 強力な DH グループの使用

• DH Group 14 (2048bit) や Group 19 (ECC) を使う
• 計算量を爆増させて、鍵解読を現実的に不可能にする

3. 証明書認証の併用

• 事前共有鍵 (PSK) だけでなく、X.509 証明書で認証
• 攻撃者が鍵を盗んでも証明書がなければセッションを張れない

4. 不正アクセスの検知・ブロック

• IKE-SA ネゴシエーションの失敗ログを監視
• 特定 IP から何度も鍵交換失敗したら IP アドレスをブロック

結論：フェーズ1の鍵漏えいは致命的、でも設計上の防御策は万全

• フェーズ1の鍵が漏れたら、その IKE セッションの全通信は解読される → これは事実
• でも IKE-SA は定期的に鍵を再生成し、Child-SA も完全に独立
• Diffie-Hellman の強力な暗号性 + PFS の組み合わせで、1回漏れても次回以降の通信は守られる
• セッション時間の短縮 & 鍵更新の頻度増加で漏えいリスクの影響範囲を極小化

つまり、フェーズ1とフェーズ2を分けることで、鍵漏えいリスクは完全には消せないけど、攻撃者のコストを爆発的に増加させ、実際の被害範囲を極小化しているんですね。

フェーズ1 (IKE-SA) が短期間で終わるなら、フェーズ2 (Child-SA) の鍵ローテーションって意味あるの？

確かに一見すると、「そもそも IKE-SA を頻繁に再作成するなら、フェーズ2の鍵だけ回してもしょうがなくない？」って思えますよね。

でも実は、フェーズ1とフェーズ2を分けている理由は「頻度」と「計算コスト」にあります。順番にわかりやすく解説しますね！

フェーズ1とフェーズ2の役割をもう一度整理

• フェーズ1 (IKE-SA)
  • VPNゲートウェイ同士の通信路を作るための基盤を作成
  • DH鍵交換＋認証 (証明書や PSK) で安全な暗号セッションを確立
  • フェーズ2の鍵交換メッセージ自体を暗号化
• フェーズ2 (Child-SA)
  • 実際に IPsec 通信に使う暗号鍵とアルゴリズムを決定
  • ESP/AH で暗号化・認証するための鍵を作成

なぜフェーズ1が短期間でもフェーズ2の鍵ローテーションが必要なのか？

1. IKE-SA は「メタ通信路」、Child-SA は「実データ通信」

フェーズ1は、VPNのトンネルそのものを作るための 制御チャネル です。フェーズ1の鍵が変わる＝トンネルそのものを作り直すイメージ。

でも、データ通信の暗号鍵 (Child-SA) を細かく回すことで、通信ごとの暗号鍵漏洩リスクを抑えられるんです。

➡️ フェーズ1は30分ごと、Child-SAは5分ごと みたいにしておけば、たとえChild-SAが漏れてもすぐに無効化されます。

2. フェーズ1の再ネゴシエーションは重い

フェーズ1の IKE-SA を再作成するときには、Diffie-Hellman 鍵交換や認証処理が必要です。これには結構な計算コストがかかります。

一方、フェーズ2の鍵ローテーションは、フェーズ1で作った共有秘密をベースに 軽量な鍵派生関数 (PRF) で新しい鍵を作るので、フェーズ1の再ネゴシエーションより圧倒的に軽いんです。

➡️ フェーズ1は30分に1回、フェーズ2の鍵は5分に1回みたいにすれば、性能を落とさずセキュリティ強度を上げられます。

3. セッション継続性の確保

もし フェーズ1が切れた瞬間に VPN トンネルごと強制切断されたら、ユーザー体験が最悪ですよね？でも、フェーズ1が維持されている間は、フェーズ2の鍵だけをローテーションすることで、通信を途切れさせずに安全性を保てます。

➡️ トンネルは維持したまま、データ通信の鍵だけ細かく回す ことで、安定性とセキュリティのバランスを取っているんです。

4. 攻撃者のコストを爆増させる

フェーズ1が30分ごと、フェーズ2が5分ごとに鍵を回すとします。攻撃者が鍵を解読しても、たった5分分の通信データしか読めない。そして、5分後には新しい鍵に切り替わります。

➡️ 攻撃者が常に鍵を割ろうとするなら、5分以内に鍵を解読し続けなきゃいけないので、現実的に不可能になります。

まとめ：フェーズ1短期終了と鍵ローテーションのバランス

• フェーズ1 (IKE-SA) を短期間で終了させるのは、万が一漏えいしたときのリスク軽減
• フェーズ2 (Child-SA) の鍵ローテーションは、実データ通信の暗号鍵を頻繁に更新してセキュリティ強度を上げる
• フェーズ1の再作成は重いので、フェーズ2の鍵だけを軽く頻繁に回してパフォーマンスとセキュリティを両立
• フェーズ1を30分、フェーズ2を5分みたいにすると、攻撃者が鍵を解読しても被害範囲を極小化

要するに、フェーズ1はトンネル作成用の「基盤」で、フェーズ2は実データ通信の「暗号鍵」なんです。だから、フェーズ1が短期間でも、フェーズ2でこまめに鍵を回すのがベストバランスなんですね！