IPsec

IPsecは、データストリームの各IPパケットを認証／暗号化することにより、ネットワーク層でIP通信を保護するためのプロトコル群である。 暗号技術を用いることで、IP パケット単位で改竄検知や秘匿機能を提供するプロトコルである。これによって、暗号化をサポートしていないトランスポート層やアプリケーションを用いても、通信路の途中で、通信内容を覗き見られたり改竄されることを防止できる。

IPsecは、IPv6では必須とされた時期があり、専用の拡張ヘッダが定義されている。一方、IPv4では、利用可能だが必須ではなく、IP ヘッダオプションを利用する。

1. バージョン
--------

IPsecの規格はIETFの ipsec wg にて策定し、RFCとして公開している。IETF ではIPsecにバージョン番号を与えていないが、非公式に下記のバージョンが与えられており、2016年現在のバージョンはIPsec-v3である：

IPsec-v1：RFC182x 形式のもの
IPsec-v2：RFC240x 形式のもの
IPsec-v3：RFC430x 形式のもの

2. プロトコル概要
----------

2.1. 構成
-------

IPsecは、2つのピアの間にSA という単方向コネクションを確立することで、ピア間にセキュアな通信を確立する。なお、SAは、単方向であるため、双方向通信を行う場合には、上りと下りの2つのSAを確立する必要がある。

ピアは、ホストとセキュリティ・ゲートウェイの二種類に分類できる。前者は、個人端末やサーバのようなIP通信の端点に相当する機器である。後者は、ルータのようなIP通信の中継を担う機器である。

IPsecは、原理的にはピアがどちらのタイプであるのかを問わない。したがって、ホストからホストまでの通信全体を直接1つのSAで保護することもできるし、2つの中継地点間毎に別々のSAを確立して通信を保護するリレー形態の運用も可能である。しかし後述するように、ピアがどちらのタイプであるかによって推奨される通信モードが存在する。

IPsecの各ピアは、SPD、SADという2つのデータベースを管理する。

SPDは、IPアドレス、プロトコル、TCPポートといった情報に応じて、パケットを破棄するのか、IPsecを使わずに送信するのか、IPsecを使って送信するのかを決めるセキュリティポリシーのデータベースである。

一方、SADは、各ピアとSAを確立する際に用いるパラメータのデータベースである。

2.2. プロトコルの流れ
-------------

ピアSがピアRに向けてIPsecで通信するには、以下の3ステップを踏む。

SからRへのSAを確立する。
SAを使ってパケットをSがRに暗号通信する。
Rがデータを受信し、復号などの必要処理を行う。第一ステップであるSAを確立する段階では、鍵共有プロトコルが実行される。このときに共有された鍵を用いて、第二ステップで通信を暗号化し、第三ステップで復号する。 以下では、この3つのステップの概略を述べる。

2.2.1. SAの確立
------------

ピアSは、自身のSPDを参照することで、上位レイヤのプロトコルがRに送ることを要求したパケットを廃棄するのか、そのまま送るのか、それともIPsecで保護して送るのかを決定する。

IPsecで保護して送ることに決定した場合、ピアSは、SAの確立に必要なデータがすでにSADに存在するかどうかを確認する。データが揃っていれば、それらのデータをSADから読み込む。

一方、SAの確立に必要なデータがSADにすべて揃っていない場合は、SAに必要な情報を確立するプロトコルであるIKEをピアRとともに実行する。2016年現在、IKEの最新版はIKEv2である。

IKEは、上述のように、SAに必要な情報を確立するプロトコルであるが、その中でメインとなるのはその名称が示す通り、ピアRとの鍵共有である。

なお、SAに必要な情報を確立するプロトコルとして、IKEの代わりにKerberized Internet Negotiation of Keys やIPSECKEY DNS recordsを使用することもできる。

2.2.2. 暗号通信
-----------

SAが確立された後、ピアSとRは、以下の2つのうちいずれかのプロトコル用いて、通信を行う：

AH  ：IPパケットにメッセージ認証子をつけるが暗号化は行わない。IPプロトコル番号 51。
ESP  ：IPパケットに認証暗号を施す。IPプロトコル番号 50。AHやESPの暗号処理に必要な共通鍵は、SAの確立の際に生成もしくは読み込んだものを用いる。

認証暗号は、平文の暗号化とメッセージ認証の両方を実行できる共通鍵暗号方式である。したがって、ESPを用いた場合、パケットの秘匿性と改竄検知の両方が担保される。一方、AHを用いた場合、改竄検知しか担保されない。

通信は、以下の2つのいずれかの動作モードに従って行う：

トランスポートモード：パケットデータ部のみを暗号処理を施す。
トンネルモード：ヘッダを含めたパケット全体を丸ごと「データ」として暗号処理を施し新たなIPヘッダを付加。トランスポートモードは、主に2つのホスト間の通信で使われ、トンネルモードは、主にセキュリティ・ゲートウェイとセキュリティ・ゲートウェイ、およびセキュリティ・ゲートウェイとホストの間の通信で使われる。

2.2.3. 受信時の処理
-------------

ピアRは、パケットを受け取り、SADの記載に従って、パケットを破棄するか否かを決める。そして、パケットがIPsecのものであれば、パケットを復号し、さらにメッセージ認証の検証を行った上で、上位レイヤーのプロトコルにパケットを渡す。パケットがIPsecではなく通常のIPのものである場合、復号などの処理を施さず、直接上位レイヤーのプロトコルにパケットを渡す。

3. 利用する暗号方式
-----------

特に断りがない限り本節の記述は7321}} 2.3-2.4節で要求レベルがSHOULD以上のものに基づいた。

AHのMACとしてAES-GMACがSHOULD+、AES-XCBC-MAC の出力を96ビットに切り詰めたものがSHOULDである。NULLもMAYである。

ESPの認証暗号としてAES-GCMがSHOULD+である。Encryption-then-Mac 型の認証暗号としては、暗号部分はNULL とAES-CBCがMUSTであり、MAC部分はHMAC-SHA1の出力を96ビットに切り詰めたものがMUST、鍵長128ビットのAES-GMACがSHOULD+、AES-XCBC-MAC の出力を96ビットに切り詰めたものがSHOULDである。

ただし以上の要求レベルは過去の経緯にも基づいており、安全性や効率の観点から見た場合はAHにはAES-GMAC、ESPにはAES-GCMを推奨している。

4. 各プロトコルの詳細
------------

4.1. AH
-------

AH  は、認証および改竄防止機能を提供する。データそのものは暗号化されないので、盗聴防止には利用できない。1826}} 形式の AH には再送防止機能  が無いが、2402}} では 32 bit の、4302}} では 64 bit のカウンタが付けられており、過去に送信されたパケットがコピー再送されても多重受信しない機能がオプションとして利用できる。



4.2. ESP
--------

ESP  は ペイロード部を暗号化する。正確には、IP ヘッダ、経路ヘッダ、ホップバイホップオプションヘッダを除いた部分が暗号化される。1827}} 形式の ESP には認証機能が無いが、2406}} / 4303}} 形式の ESP にはオプションとして「認証トレイラー」機能があり、AH を併用せずとも改竄防止機能を利用することが可能となっている 。また後者には AH 同様に再送防止機能も追加されている。

1826}} / 1827}} 形式の AH/ESP はそれ以降の RFC とヘッダ長が異なるため互換性がない。4302}} / 4303}} 形式の 64 bit カウンタは ESN  とも呼ばれるが、実際にパケットに付加されるのは下位 32 bit だけで、見た目は 2402}} 形式のパケットと区別が付かない。ただし認証ベクタ  の算出には全 64 bit が使用されるため、2402}} / 2406}} 形式の IPsec と 4302}} / 4303}} 形式の IPsec の間にも直接の互換性はない。4302}} / 4303}} 仕様の IPsec 実装で 2402}} / 2406}} 形式と通信するためには、32 bit の互換カウンタ使用を明示指定する必要がある。



4.3. IKE
--------

IKE  は SAを構築するのに必要な情報の交換を安全に行うプロトコル。IKEv1  と IKEv2  が定義されており、2016年現在の最新版は後者である。

また IKEv1/v2 以外にも Photuris , KINK  などの鍵交換プロトコルが提案されている。

4.3.1. IKEv2
------------

4.3.2. IKEv1
------------

IKEv1は Internet Key Exchange protocol version 1 の意味であり、UDPポート番号500上で通信される鍵交換プロトコルである。開発時には ISAKMP/Oakley と呼ばれた過去があり、これはISAKMPプロトコルの上で Oakley 鍵交換手順を実装したものという意味である。すなわち、IKEv1 は ISAKMP と必ずしも同じものではない。

IKEv1 はフェーズ1、フェーズ2と呼ばれる二段階の手順で鍵交換を行う。まずフェーズ1で IKE プロトコル同士の認証と暗号交換を行い、フェーズ2で IPsec の適用条件と鍵情報の交換を行う。 フェーズ1には Main Mode,Aggressive Mode と呼ばれる2つの手順がある。前者は ISAKMP 仕様における Identity Protection Exchange 手順の呼び名であり、後者は ISAKMP 仕様における Aggressive Exchange 手順の呼び名である。。 フェーズ2の通信はフェーズ1において成立した共有鍵を用いて暗号化される。フェーズ2の手順は Quick Mode と呼ばれ、これは ISAKMP にはなく IKEv1 で新たに定義されたものである。IKEv1 の規格上では New Group Mode という手順も定義されているが、実際には殆ど使われていない。

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

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

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

IKEv1 では鍵交換と同時に相手ピアの認証を行う。認証アルゴリズムもフェーズ1において提示-合意のプロセスを踏んで実行され、認証方式には事前鍵共有方式 、デジタル署名方式 、公開鍵暗号方式  などがある。

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

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

このように IKEv1 には数多くのモードとパラメータとオプションの組み合わせがあり、さらに多くの拡張仕様が存在する。その中には標準案として提案されたもののドラフトを通過できず、正式な RFC として記載されずに終わったものも少なくない。また IKEv1 仕様には難解で紛らわしい用語が錯綜しているため、実装系において独自の名前を与えている場合もある