Skip to content

MS_IPsec

Jump to bottom
nishi_74322014 edited this page Aug 3, 2026 · 1 revision

IPsec

概要

  • IPsec（Security Architecture for Internet Protocol、アイピーセック）
  • 共有鍵暗号方式を用いることで、IP パケット単位で改ざん検知や秘匿機能を提供するプロトコル
    • 暗号化をサポートしていないトランスポート層やアプリケーション層のプロトコルをネットワーク層で暗号化可能。
    • 共有鍵暗号方式を用いるので鍵交換が必要。「完全性の確保」と「認証」も含まれる。
  • 暗号化アルゴリズムなどをあえて特定せず、あらゆる暗号を利用できるような柔軟な枠組みを提供している。
  • もともとインターネットの標準化団体であるIETFが VPN の標準プロトコルとして規定した。

機能

アクセス制御

送信元の認証

  • MACによる送信元の認証
  • プロトコル：ESP / AH の何れかで可能

メッセージ認証

  • MACによるメッセージ認証（改ざん検知）
  • プロトコル：ESP / AH の何れかで可能

受信データ重複検知

  • リプレイアタックの防止
  • プロトコル：ESP / AH の何れかで可能

通信データの暗号化

移行メモ（正誤）: 元 Wiki では、上記の各機能から ESP / AH へ張られたアンカーが AH と ESP で入れ替わっていた（ESP と表示されるリンクが AH の見出しへ、 AH と表示されるリンクが ESP の見出しへ飛ぶ状態）。移行にあたり正しい対応に修正した。

構成

ピア

  • ピアは、ホストとセキュリティ・ゲートウェイの二種類に分類できる。
  • IPsecは、原理的にはピアがどちらのタイプであるのかを問わない。
  • が、ピアがどちらのタイプであるかによって推奨される通信モードが存在する。
  • IPsecの各ピアは、2つのデータベースを管理する。

SPD（Security Policy Database）

セキュリティポリシーのデータベース

  • 判定ポリシー
    • IPアドレス
    • プロトコル（TCP/UDP/ICMP等）
    • TCPポート
  • アクション・ポリシー
    • パケットを破棄（discard）
    • IPsecを使わずに送信（bypass IPsec）
    • IPsecを使って送信（apply IPsec）

SAD（Security Association Database）

各ピアと SA を確立する際に用いるパラメタのデータベース

コネクション

SA（Security Association）

  • 一連のネゴシエーションの結果として、お互いの間で得られた暗号化アルゴリズムや暗号鍵に関する合意。
  • SAには、ISAKMP SA（制御用）とIPsec SA（通信用）がある。
    • ISAKMP SA（制御用）
    • IPsec SA（通信用）
      • 単方向であるため、双方向通信を行う場合には、上りと下りの2つのSAを確立する必要がある。
      • 2つの単方向コネクションを確立することで、ピア間にセキュアな通信を確立する。

移行メモ（誤記）: 原文の「ISAKEMP SA」は「ISAKMP SA」の誤記と解して整えた。

SPI（Security Parameter Index）

  • SA の確定と同時に、SA と関連付けされた32ビットの整数値
  • SPIは暗号化通信で各パケット中に挿入され、暗号化・復号（化）をガイドする。
    • 暗号化アルゴリズム
    • 暗号鍵
  • SPIを検索キーのように使って、パケット内の必要な情報を引き出す。
    • 暗号化アルゴリズムや暗号鍵が推測できないように、暗号化通信の開始時に任意のものが割り当てられる。
    • 値の意味がネゴシエーションを行った当事者同士以外には分からないように工夫されている。

移行メモ（正誤）: 原文は SPI を「Security Pointer Index」としていたが、 正しくは Security Parameter Index（RFC 4301）。

プロトコル

フロー

ピアSがピアRに向けてIPsecで通信する場合。

  1. SからRへの SA を確立する。
    鍵共有プロトコルが実行される。
  2. SA を使ってパケットをSがRに暗号通信する。
    共有された鍵を用いて、通信を暗号化する。
  3. Rがデータを受信し、復号などの必要処理を行う。
    共有された鍵を用いて、通信を復号（化）する。

中核

中核をなす以下の3つのプロトコルがある。

鍵共有プロトコル

IKE（Internet Key Exchange）という鍵交換プロトコルを使用する。

  • ISAKMP/Oakley を元にして作られた。
  • 「Diffie-Hellman」方式（暗号化アルゴリズム）が利用される。
  • それ自体で暗号化通信をサポートしている。
  • UDPポート番号500上で通信される。
  • IKEv1 と IKEv2 があるが互換性はない。

ISAKMP/Oakley

  • IPsecで利用される SA 確立のためのプロトコル
  • 今日では IKE (Internet Key Exchange) に統合化されている。
  • ISAKMP
  • Oakley
    • Diffie-Hellman 技術をベースとして、
    • ピア間での安全なセッションを構成可能にする。

IKEv1

Internet Key Exchange protocol version 1

ISAKMP

  • Internet Security Association Key Management Protocol
  • イニシエータとレスポンダのセッション確立のためのネゴシエーションを行う。
  • ヘッダ
0 ------------------------------------------------------------- 31
イニシエータ・クッキー（64bit）
レスポンダ・クッキー（64bit）
次ペイロード / Major-Version / Minor-Version / 交換タイプ / フラグ
メッセージID
全メッセージ長
  • 交換タイプ
    • Mainモード
    • Aggressiveモード
    • Quickモード
  • パケット
IPヘッダ UDPヘッダ ISAKMPヘッダ ISAKMPペイロード ...
  • ISAKMPペイロードの種類
番号 種類
1 SA ペイロード
2 Proposal ペイロード
3 変換ペイロード
4 鍵交換ペイロード
5 ID ペイロード
6 証明書ペイロード
7 証明書要求ペイロード
8 ハッシュ・ペイロード
9 署名ペイロード
10 乱数（nonce）ペイロード
11 通知ペイロード
12 削除ペイロード
13 ベンダ ID ペイロード
14 データ属性ペイロード

フェーズ

ISAKMP SAパラメタのネゴシエーション

  • イニシエータがパラメタを提案
    • 暗号化アルゴリズム
    • ハッシュ・アルゴリズム
    • 認証方式
    • , etc.
  • レスポンダが受諾可能なパラメタを選択・回答

メッセージの交換手順

ISAKMP SAを確立するまでの、

ISAKMPメッセージの交換手順

として２つの交換タイプがある。

  • Mainモード（３往復のパケット交換）
    • ISAKMP SAパラメタのネゴシエーション
    • 「Diffie-Hellman」方式で秘密対称鍵の生成・交換。次の４つの秘密対称鍵を生成する。
      • SKEYID：他のカギを生成する元（事前共有鍵認証の場合、事前共有鍵から生成）
      • SKEYID_d：IPsec SAの秘密対称鍵を生成する元（SKEYIDやDH秘密鍵から生成）
      • SKEYID_a：ISAKMPメッセージ認証用（SKEYID、SKEYID_d、DH秘密鍵から生成）
      • SKEYID_e：IPsec SAの暗号化用（SKEYID、SKEYID_a、DH秘密鍵から生成）
    • デバイスの認証方式
  • Aggressiveモード（1.5往復のパケット交換）
    • イニシエータは、以下を同時に行う。
      • ISAKMP SAパラメタのネゴシエーション
      • 「Diffie-Hellman」方式で秘密対称鍵の生成・交換
    • レスポンダは、
      • 受諾可能なパラメタを選択・回答、
      • 同時に（、イニシエータ、レスポンダは）、秘密対称鍵が生成可能。
    • イニシエータは、
      • デバイスの認証を行う（レスポンスは受けない）。
      • IDにFQDNを使用することで、動的なIPアドレスでも対応できる。

※ Aggressive モードは事前共有鍵のハッシュが平文で流れるためオフライン辞書攻撃に弱く、 現在は非推奨。IKEv2 の使用が推奨される。

デバイスの認証方式

通信相手（IPsec機器）との認証を行う認証方式

# 認証方式 説明
1 事前共有鍵認証（pre-shared key 認証） 事前に鍵交換する（もっとも簡便で広く利用されている）
2 ディジタル署名認証 証明書を使用して相互認証
3 公開鍵暗号認証 ...
4 改良型公開鍵暗号認証 ...

これにより、ISAKMP SAが確立する。

※ 仕組み（シーケンスやペイロードなど）が不明。

IPsec SAパラメタのネゴシエーション

  • IPsec SAを確立するISAKMPメッセージの交換手順
    • 秘密対称鍵は、SKEYID_dによって生成される。
    • 通信は、SKEYID_eによって暗号化される。
  • Quickモード（1.5往復のパケット交換を行う）
    • イニシエータは、以下を同時に行う。
      • IPsec SAパラメタのネゴシエーション
      • 認証情報の送信（認証用乱数、認証用ハッシュ）
    • レスポンダは、
      • 受諾可能なパラメタを選択・回答、
      • 認証情報の送信（認証用乱数、認証用ハッシュ）
    • イニシエータは、
      • デバイスの認証を行う（レスポンスは受けない）。
      • IPsec SAを確立し、以降IPsec通信が可能になる。
      • SAは定期的に更新され、両ホスト間で再認証と鍵の更新が行われる。

IKEv2

Internet Key Exchange protocol version 2

  • 混沌とした IKEv1 の標準化の仕切り直しを図っている。
  • IKEv1 と同じUDPポート500だが互換性はない。
  • 動的IPアドレスに標準対応している。
  • ユーザ認証にEAP (Extensible Authentication Protocol)を標準実装している。

SA

  • IKE_SA
    • ISAKMP SAに相当する。
    • 上りと下りで２つ造られる。
  • CHILD_SA
    • IPsec SAに相当する。
    • AHとESPの通信に用いられる。

Exchange

イニシエータとレスポンダの通信

  • IKE_SA_INIT
    • IKEv1のフェーズ1に相当（デバイス認証を含まない）
  • IKE_AUTH
    • IKEv1のフェーズ1に相当（デバイス認証とユーザ認証）
  • CREATE_CHILD_SA（IKEv1のフェーズ2に相当）
    • 別のCHILD_SAの生成
    • 既存のCHILD_SAの定期更新
  • INFORMATIONAL
    SAの削除やエラー情報の通知など

移行メモ（誤記）: 原文の「IKE_SA_INT」「INFORMATIONNAL」は、 RFC 7296 の正式名称に合わせて「IKE_SA_INIT」「INFORMATIONAL」に整えた。

暗号通信プロトコル

動作モード

トランスポート・モード

  • ペイロード、TCPヘッダを暗号化（署名）

  • パケットデータ部のみに、

    • ESP 暗号化
    • AH メッセージ認証

    処理を施す。

  • 主に2つのホスト間の通信で使われる。

トンネル・モード

  • ペイロード、TCPヘッダ、IPヘッダを暗号化（署名）

  • ヘッダを含めたパケット全体に

    • ESP 暗号化
    • AH メッセージ認証

    処理を施し、新たなIPヘッダを付加する（カプセル化）。

  • 主に以下の通信で使われる。

    • セキュリティ・ゲートウェイとセキュリティ・ゲートウェイ
    • セキュリティ・ゲートウェイとホストの間

暗号化、メッセージ認証

SA が確立された後、ピアSとRは、

  • 以下の2つのうちいずれか、若しくは両方のプロトコルを用いて、暗号化（メッセージ認証）通信を行う。
    • 平文の暗号化とメッセージ認証の両方を実行できる共通鍵暗号方式
    • 暗号処理に必要な共通鍵は、SA の確立の際に生成もしくは読み込んだものを用いる。

AH (Authentication Header)

  • IPプロトコル番号 51。
  • 「完全性の保証」と「認証」のための仕組み。
  • IPパケットにメッセージ認証子(MAC)をつけ暗号化は行わないので改ざん検知しか担保されない。
  • MAC（SPI、シーケンス番号、認証データ）をパックしてIPヘッダの直後に加える。
  • ヘッダのレイアウト
0 ----------------------------------------- 31
次ヘッダ / ペイロード長 / 予約
セキュリティ・パラメタ・インデックス（SPI）
シーケンス番号
認証データ（可変長）：ICV（Integrity Check Value）
  • パケット構成
    • 通常時：IPヘッダ | TCPヘッダ | データ
    • トランスポート・モード（AHヘッダを挿入）
      IPヘッダ | **AHヘッダ** | TCPヘッダ | データ
      ← 認証の範囲：全体
    • トンネル・モード（AHヘッダとIPヘッダでカプセル化）
      新IPヘッダ | **AHヘッダ** | IPヘッダ | TCPヘッダ | データ
      ← 認証の範囲：全体

ESP (Encapsulating Security Payload)

  • IPプロトコル番号 50。

  • IPパケットに認証暗号を施すため、パケットの秘匿性と改ざん検知の両方が担保される。

  • 以下の3つの情報が

    • 暗号化された通信内容
    • SPIとシーケンス番号フィールド
    • そして認証データ

    付け加えられた構造になる。

  • 動作モードによって暗号化の範囲が異なる。

  • パケットのレイアウト

0 ----------------------------------------- 31
セキュリティ・パラメタ・インデックス（SPI）
シーケンス番号
データ
パディング
ESPトレーラ（パディング長、次ヘッダ）
認証データ（可変長）：ICV（Integrity Check Value）
  • 構成
    • 通常時：IPヘッダ | TCPヘッダ | データ
    • トランスポート・モード（ESPヘッダを挿入）
      IPヘッダ | **ESPヘッダ** | TCPヘッダ | データ | **ESPトレーラ** | **ESP認証データ**
      • 認証の範囲：ESPヘッダ 〜 ESPトレーラ
      • 暗号化の範囲：TCPヘッダ 〜 ESPトレーラ
    • トンネル・モード（ESPヘッダとIPヘッダでカプセル化）
      新IPヘッダ | **ESPヘッダ** | IPヘッダ | TCPヘッダ | データ | **ESPトレーラ** | **ESP認証データ**
      • 認証の範囲：ESPヘッダ 〜 ESPトレーラ
      • 暗号化の範囲：IPヘッダ 〜 ESPトレーラ

※ ESP認証データは、認証＆暗号化対象外。

移行メモ（誤記）: 原文の見出しは「ESP (Encapsulated Security Payload)」だったが、 正式名称は Encapsulating Security Payload（RFC 4303）。

復号化、メッセージ認証の検証

フィルタリング

  • ピアRは、パケットを受け取り、
  • SAD の記載に従って、パケットを破棄するか否かを決める。

復号（化）

  • パケットがIPsecのものであれば、
    • パケットを復号し（暗号化されている場合）
    • メッセージ認証の検証を行った上で、上位レイヤーのプロトコルにパケットを渡す。
  • パケットがIPsecではなく通常のIPのものである場合、
    • 復号などの処理を施さず、
    • 直接上位レイヤーのプロトコルにパケットを渡す。

留意点と対策

端末の不正使用

  • リモートアクセス環境では、
    • デバイス認証だけでなく
    • ユーザ認証が必要になる。
  • XAUTH
    • ISAKMP SAが確立する中でデバイスの認証が行われる。
    • ユーザ認証
      • デバイス認証後に、ユーザ認証が行われる。
      • IPsec SAパラメタのネゴシエーションが暗号化されるようにユーザ認証も暗号化される。
      • 認証はユーザIDとパスワードによる（方式はチャレンジ＆レスポンスやワンタイムパスワードを選択可）

IPアドレスの動的割当

  • Point-to-Site VPN (P2S)（VPN Gateway）などでポイントとなる端末にIPアドレスの動的割当を行う必要がある。
  • これには、ISAKMP Configuration Methodが使用され、以下の2つの方式がある。
    • イニシエータが要求した情報をレスポンダから受け取る。
    • イニシエータから情報をレスポンダに送り、了解を得る。

NAT / NAPT 利用時の留意点

NAT / NAPT

NAT

IPの変換なので、IPヘッダにだけ影響する。

プロトコル 動作モード 問題
IKE 動作モードを問わない 特に問題は生じない。
AH 動作モードを問わない IPヘッダ含めて認証データであるICV（Integrity Check Value）が
生成されているので、IPアドレス変更によってICVが不一致になる。
ESP トランスポート・モード IPアドレスの変更に伴い、TCPヘッダのチェックサムを変更する必要があるが、TCPヘッダ自体が暗号化されているため出来ない。
〃 トンネル・モード トンネルモードでは、新IPヘッダが変更されるだけなので問題ない。

※ IKE + ESPで処理可能。

NAPT

IPとポート番号の変換なので、IPヘッダとTCPヘッダに影響する。

プロトコル 動作モード 問題
IKE 動作モードを問わない IKEパケットのポート番号は変換しないようにする。
AH 動作モードを問わない NATと同じ問題が発生する。
ESP 動作モードを問わない ポート番号は暗号化されているので変換できない。

※ 処理不可能なので UDP encapsulation of IPsec ESP packets を使用する。

UDP encapsulation of IPsec ESP packets

  • 新IPヘッダとESPヘッダの間にヘッダを追加する。
  • UDPヘッダ（UDPでカプセル化するため）
  • non-IKEヘッダ（IKEパケットとの区別のため）

※ 一般に NAT-T（NAT Traversal、RFC 3947 / 3948） と呼ばれ、UDP 4500番ポートを使用する。

参考

  • IPsecとは
  • 技術解説：IT管理者のためのIPSec講座 - ＠IT
  • IPsec - Wikipedia
    • 以下の理由から、現状は専門の技術者が管理するGateway間でVPNとして利用されることが多い。
      • 通信する二点間で全ての設定が一致していなければ通信が成立しない。
      • 手動設定の場合は同じ鍵情報を長期間使い続けることになるため、セキュリティ強度の観点からも好ましくない。

Tags: IT国際標準, インフラストラクチャ, セキュリティ, 暗号化, 通信技術

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally