調査と解説

IPsec の仕組み

通信者双方で共有するパラメータを SA (Security Association) といい，SA を管理するデータベースを SAD (Security Association Database) という． どのプロトコルでどの SAD を使うかを決めるのが，SP (Security Policy) であり，SP を管理するデータベースが SPD (Security Policy Database) である． エンコードされた IPsec ヘッダ (AH/ESP) には自身の所属する SA を示す 32 bit の ID 情報が付加されるが，これを SPI (Security Parameter Index) とよぶ．

IP パケットを送信するノードはその IP パケットにあった SP をさがし，その SP が示す SA の情報に基づいて暗号の処理を行う． 受信時は AH/ESP のヘッダに含まれる SPI から SA が検索されて復号/認証処理が行われ，その処理結果が SP で規定されるセキュリティ要求を満たしているかどうかが判定される．

認証ヘッダ (AH)

認証ヘッダ (Authentication Header, AH) は，認証，改竄防止機能を提供する IPv6 のヘッダである． データそのものは暗号化されないので，のぞき見防止には利用できない． IPSec は 2 回おおきな改訂をへているが，現在の版を記述している RFC 4302 においてはリプレイ防止機能 (Anti Replay Counter) のために AH において 64 bit のカウンタが使用されている． また，過去に送信されたパケットがコピーされリプレイされても多重受信しない機能がオプションとして利用できる． 前回の改訂版である RFC 2402 においては 32 bit のカウンタが使用されたが，最初の版である RFC 1826 形式の AH にはリプレイ防止機能がなかった．

隠蔽されたセキュリティ・ペイロード (ESP)

隠蔽されたセキュリティ・ペイロード (Encapsulated Security Payload, ESP) は暗号化されたペイロードのことをいう． 正確には，IP ヘッダ，経路ヘッダ，ホップバイホップ・オプション・ヘッダを除いた部分が暗号化される． 最初の版である RFC 1827 形式の ESP には認証機能がなかったが，RFC 2406 / RFC 4303 形式の ESP にはオプションとして 「認証トレイラー」 機能があり，AH を併用しなくても改竄防止機能を利用することが可能である (ただし保証されるのはデータ部分だけであり，IP ヘッダ部分の改竄を検出することはできない)． また後者には AH 同様にリプレイ防止機能も追加されている．

RFC 182x 形式の AH/ESP はそれ以降の形式とヘッダ長が異なるため互換性がない． RFC 430x 形式の 64 bit カウンタは ESN (Extended Sequence Number) とも呼ばれるが，実際にパケットに付加されるのは下位 32 bit だけであり，RFC 2402 形式のパケットと区別がつかない． ただし認証ベクタ (ICV) の算出には全 64 bit が使用されるため，RFC 240x 形式の IPsec と RFC 430x 形式の IPsec の間にも直接の互換性はない． このため，RFC 4302x 仕様の IPsec 実装で RFC 2402x 形式と通信するためには，32 bit の互換カウンタ使用を明示指定する必要がある．

インターネット鍵交換プロトコル (IKE)

インターネット鍵交換プロトコル (IKE) は SAD を構築するのに必要な鍵情報の交換を安全に行うプロトコルである． IKEv1 (RFC 2409) と IKEv2 (RFC 4306) が定義されている． また IKEv1 / v2 以外にも Photuris (RFC 2522), KINK (RFC 4430) などの鍵交換プロトコルが提案されている．

IKEv1

IKEv1 (Internet Key Exchange protocol version 1) は UDP ポート番号 500 上で通信される鍵交換プロトコルである． 1998 年に制定された RFC 2409 に記述されている． 開発時には ISAKMP/Oakley と呼ばれたが，これは ISAKMP (Internet Security Association and Key Management Protocol) プロトコルの上で Oakley 鍵交換手順を実装したことを意味している．

IKEv1 はフェーズ 1，フェーズ 2 と呼ばれる二段階の手順で鍵交換を行う． まずフェーズ 1 で IKE プロトコル同士の認証と暗号交換を行い (これを ISAKMP SA 交換とも呼ぶ)，フェーズ 2 で IPsec の適用条件と鍵情報の交換を行う (IPsec SA 交換とも呼ぶ)．

• フェーズ 1 には Main Mode, Aggressive Mode と呼ばれる 2 つの手順がある． 前者は ISAKMP 仕様における Identity Protection Exchange 手順の呼び名であり，後者は ISAKMP 仕様における Aggressive Exchange 手順の呼び名である． (用語定義の錯綜と難解さも IKE の理解を難しくしている理由の一つである)．
• フェーズ 2 の通信はフェーズ 1 において成立した共有鍵を用いて暗号化される． フェーズ 2 の手順は Quick Mode と呼ばれ，これは ISAKMP にはなく IKEv1 で新たに定義されたものである． IKEv1 の規格上では New Group Mode という手順も定義されているが，実際にはほとんど使われていない．

Oakley 鍵交換手順は公開鍵暗号を用いた鍵交換手順のアルゴリズムとパラメータのセットをいくつか定めたもので，アルゴリズムは大きく分けて Diffie-Hellman 鍵共有 (DH-MODP) と楕円曲線暗号 (EC2N) の 2 種がある． 鍵長は DH-MODP で 768, 1024, 1536, 2048, 3072, 4096, 6144, 8192 bit，EC2N で 155, 188, 163, 283, 409, 571 bit が定義されている．

IKE の通信を行うノードを IKE ピアと呼び，IKE 要求を発行する側をイニシエータ，受信した側をレスポンダと呼ぶ． Oakley のパラメータや IPsec SA の詳細はイニシエータ側が使用可能な組み合わせを提示し (これをプロポーザルと呼ぶ)，レスポンダ側が最も適切と判断したものを選択して合意を取るという手順を踏む． 何をもって 「適切」 とみなすかは実装と設定に依存し，これを 「ポリシー」 と呼ぶ場合もあるが，狭義の意味における IPsec Security Policy とは必ずしも同じニュアンスではない． 用語の混同を避けるため，RFC 4301 においてはこれら 「鍵交換時の挙動を定めるパラメータの一覧」 を Peer Authorization Database (PAD) と呼んでいる．

Aggressive Mode はフェーズ 1 におけるプロポーザル手順の一部を削減し，パラメータの一部を決め打ちとすることで Main Mode にくらべてパケット交換回数を 3 往復 6 パケットから 1.5 往復 3 パケットに減らし，通信効率を向上している． ただし Main Mode では最後に交換される ID パケットが暗号化されるのに対し，Agressive Mode では ID 情報が暗号化されないまま送信されるので，盗聴によるセキュリティ・ホールを生じかねないというリスクもある． フェーズ 1 にどちらのモードを用いるかはイニシエータに依存し，やはりそのネットワークにおけるポリシー (PAD) によって決定される．

IKEv1 においては鍵交換と同時に相手ピアの認証を行う． 認証アルゴリズムもフェーズ 1 において提示-合意のプロセスを踏んで実行され，認証方式としてはつぎの方式がある．

• 事前鍵共有方式 (Pre Shared Key, PSK)
• デジタル署名方式 (Digital Signatures)
• 公開鍵暗号方式 (Public Key Encryption)

フェーズ 2 で生成される IPsec SA の鍵情報は，原則としてフェーズ 1 で生成された共有鍵情報から生成される． しかし複数個の IPsec SA をまとめて生成するような使用法の場合，全ての IPsec SA 情報が 1 つの秘密情報に依存することは好ましくない場合がある． このような場合，IKEv1 では Perfect Forward Secrecy (PFS) と呼ばれるオプション機能の利用が (通信ピア双方に実装されていれば) 可能である． PFS は個々のフェーズ 2 交換時に新たな Oakley 鍵交換を行い，個々に異なった共有鍵を生成して IPsec SA の秘密鍵生成時に適用するものである． PFS は一般に通信秘匿性を向上させるがピアの処理負荷も向上させるため，これを適用すべきか否かもポリシー (あるいは PAD) に応じて決定すべきだとされている．

なお 1 回のフェーズ 1 交換に付随するフェーズ 2 の回数を 1 回かぎりに制限することによって，結果的に全てのフェーズ 2 生成鍵を異なったものにすることで PFS と同等の秘匿性を得る実装もあり，これを Master PFS と呼ぶこともある． この場合，上記の 「狭義の PFS」 は Session PFS と呼ばれて区別される．

このように IKEv1 には数多くのモードとパラメータとオプションの組み合わせがあり，さらに多くの拡張仕様が存在する． また IKEv1 仕様には難解でまぎらわしい用語が錯綜しているため，実装系において独自の名前を与えている場合もある (たとえば Microsoft Windows では IPsec におけるセレクタをフィルタと呼び，ポリシーをアクションと呼んでいる)． このため IETF 標準であるはずの IKEv1 の実装どうしでも異機種間接続のためにはプロトコルおよび製品実装の深遠な理解が必要になってしまった． そのため，IPsec でネットワークを組む場合は同じメーカーの同じ機器を使用することが最も確実だといわれるようにになってしまった．

IETF は混沌としてしまった IKEv1 の整理を諦め，IKEv2 をもって標準化の仕切り直しをはかっている．

IKEv2

IKEv2 は 2005 年に制定された RFC 4306 に記述されている． ただし，他にも重要な関連 RFC がある． インターネット・プロトコルのセキュリティ・アーキテクチャを記述した RFC 4301 から EPP のための DNS セキュリティ拡張マッピングを記述した RFC 4310 までのドキュメントと，その後に追加されたあたらしいセキュリティ機能やプロトコルに関するドキュメントがある．

あたらしい IKE プロトコルの必要と意図は RFC 4306 の付録 A に記述されているが，そのおもな内容はつぎのとおりである．

より少数の RFC

IKE の使用は最低でも 3 つの RFC に分散されているが，NAT トラバーサルや他のよくつかわれる拡張を考慮にいれるならば，さらにおおくの RFC をみなければならない． IKEv2 においてはこれらをたばねてひとつの RFC にし，さらに NAT トラバーサルやファイアウォール・トラバーサルのサポートを改良している．

標準モビリティ・サポート

モビリティとそのためのマルチ・ホーミングおよび IPsec トンネルのサポートのための MOBIKE と名づけられた IKEv2 の標準拡張がある． モバイルおよびマルチ・ホームのユーザはこれらの IKEv2と IPsec の拡張を使用することができる．

SCTP サポート

IKEv2 においては，これまでの TCP や UDP にくわえて SCTP を IP 電話の VoIP (Voice over IP) などにおいて使用することができる．

より単純なメッセージ交換

IKE は，それぞれが多少の利点と欠点をもつ 8 種のことなる初期交換機構をもっている． これに対して IKEv2 は唯一の 4 つのメッセージを交換する機構だけをもつ．

よりすくない暗号化機構

IKEv2 は IPsec の ESP とよく似た機構によってそのパケットの暗号化をおこなう． これによって，より単純な実装と，各暗号化実装が独立に検証できる，たぶんより容易な証明 (certification) とがえられる．

信頼性と状態管理

IKEv2 はシーケンス番号と確認 (acknowledgments) を使用して信頼性をえるとともに，エラー処理の論理と共有された状態管理を必須のものとした． IKE はそういう信頼性尺度がないために，両方の当事者がいつまでもおこらない相手の動作をまちつづける停止状態におちいってしまうことがおこりえた． IKE においては，この特別な条件のために，死んだピアの検出 (Dead-Peer-Detection) を次善の策として実装したが，他の実装と常に互換ではない手段によって解決すべき他の条件もあった．

DoS 攻撃からの回復

IKEv2 は要求者が実在することが確認できるまで，おおくの処理をおこなわないようにする． それによって IKE をなやませている，にせの場所からの (たかくつく) 多数の暗号処理要求にだまされる DoS (Denial of Service) 問題を処置できるはずである．

IPsec の利点・欠点

IPsec はネットワーク層のプロトコルを保護するので，暗号化がサポートされていない上位層やアプリケーションでもセキュリティの確保が可能になる． 一方で，暗号通信はネットワーク・スタック以下で行われるので，SSL (Secure Socket Layer) や TLS (Transport Layer Security) を使用しているときの Web ブラウザの鍵マークのように，ユーザがどのプロトコルで暗号化されているかを容易に知ることができない． そのため，専門の管理者が容易に管理しやすい Gateway での設定が行えるような，VPN での利用が現在の主な用途になっていることが多い． IPsec を VPN で利用する場合は IP アドレスを二重に付加するトンネル・モードが利用できるが，IP 以外のパケットも伝達するため L2TP (レイヤ 2 トンネリング・プロトコル) などの拡張プロトコルが用いられる場合もある．

IPsec は AH の認証機能，ESP の暗号機能を組み合わせて使うことができ，AH / ESP それぞれに様々なアルゴリズムを指定することができる． この柔軟さが IPsec の利点ではあるが，設定可能な組み合わせは膨大となり，通信する二点間で全ての設定が一致していなければ通信が成立しない． このため IPsec VPN (Virtual Private Network) のような特定 2 点間ならともかく，多台数間の IPsec 通信を手動設定で行うのは実用上ほぼ不可能である (手動設定の場合は同じ鍵情報を長期間使い続けることになるため，セキュリティ強度の観点からも好ましくない)． この手間を軽減するためネットワークで自動鍵交換を行うプロトコルも提案されているが，KINK, Photuris, IKEv1, IKEv2 など互換性のない複数の規格が並立してしまっている． 最も普及している IKEv1 でも動作モード，認証パラメータ，認証方式，鍵交換アルゴリズム，暗号アルゴリズム，認証アルゴリズムなど設定項目の組み合わせが多い． 総じて IPsec を使うためには高度な専門知識が要求され，普及をさまたげる原因となっている．

参考文献

この項目の記述にあたっては Wikipedia (日本語版) の IPsec の項目と Wikipedia (英語版) の Internet key exchange および IKEv2 の項目を参照した．