| TCP/IP群 |
|---|
| アプリケーション層 |
|
| トランスポート層 |
| カテゴリ |
| インターネット層 |
| カテゴリ |
| リンク層 |
| カテゴリ |
| インターネットセキュリティ プロトコル |
|---|
| キーマネジメント |
| アプリケーション層 |
| DNS |
| インターネット層 |
IPsec（Security Architecture for Internet Protocol又はInternet Protocol Security、アイピーセック）は、データストリームの各IPパケットを認証／暗号化することにより、ネットワーク層でIP通信を保護するためのプロトコル群である[1]。暗号技術を用いることで、IPパケット単位で改竄検知や秘匿機能を提供するプロトコルである。これによって、暗号化をサポートしていないトランスポート層やアプリケーションを用いても、通信路の途中で、通信内容を覗き見られたり改竄されることを防止できる。
IPsecは、IPv6では必須とされた時期[2]があり、専用の拡張ヘッダが定義されている。一方、IPv4では、利用可能だが必須ではなく、IPヘッダオプションを利用する。
IPsecの規格はIETFの ipsec wg にて策定し、RFCとして公開している。IETF ではIPsecにバージョン番号を与えていないが、非公式に下記のバージョンが与えられて[3]おり、2016年現在のバージョンはIPsec-v3である：
IPsecは、2つのピアの間にSA (Security Association)という単方向コネクションを確立することで、ピア間にセキュアな通信を確立する（詳細後述）。なお、SAは、単方向であるため、双方向通信を行う場合には、上りと下りの2つのSAを確立する必要がある。
ピアは、ホストとセキュリティ・ゲートウェイの二種類に分類できる。前者は、個人端末やサーバのようなIP通信の端点に相当する機器である。後者は、ルータのようなIP通信の中継を担う機器である。
IPsecは、原理的にはピアがどちらのタイプであるのかを問わない。したがって、ホストからホストまでの通信全体を直接1つのSAで保護することもできるし、2つの中継地点間毎に別々のSAを確立して通信を保護するリレー形態の運用も可能である。しかし後述するように、ピアがどちらのタイプであるかによって推奨される通信モードが存在する。
IPsecの各ピアは、SPD（security policy database）、SAD（security association database）という2つのデータベースを管理する。
SPDは、IPアドレス、プロトコル(TCP/UDP/ICMP等)、TCPポートといった情報に応じて、パケットを破棄（discard）するのか、IPsecを使わずに送信（bypass IPsec）するのか、IPsecを使って送信（apply IPsec）するのかを決めるセキュリティポリシーのデータベースである。
一方、SADは、各ピアとSAを確立する際に用いるパラメータのデータベースである。
ピアSがピアRに向けてIPsecで通信するには、以下の3ステップを踏む。
第一ステップであるSAを確立する段階では、鍵共有プロトコルが実行される。このときに共有された鍵を用いて、第二ステップで通信を暗号化し、第三ステップで復号する。以下では、この3つのステップの概略を述べる。
ピアSは、自身のSPDを参照することで、上位レイヤのプロトコルがRに送ることを要求したパケットを廃棄するのか、そのまま送るのか、それともIPsecで保護して送るのかを決定する。
IPsecで保護して送ることに決定した場合、ピアSは、SAの確立に必要なデータがすでにSADに存在するかどうかを確認する。データが揃っていれば、それらのデータをSADから読み込む。
一方、SAの確立に必要なデータがSADにすべて揃っていない場合は、SAに必要な情報を確立するプロトコルであるIKE（Internet Key Exchange）をピアRとともに実行する。2016年現在、IKEの最新版はIKEv2である。
IKEは、上述のように、SAに必要な情報を確立するプロトコルであるが、その中でメインとなるのはその名称が示す通り、ピアRとの鍵共有である。
なお、SAに必要な情報を確立するプロトコルとして、IKEの代わりにKerberized Internet Negotiation of Keys（英語版） (KINK)やIPSECKEY DNS recordsを使用することもできる[4][5][6][7]。
SAが確立された後、ピアSとRは、以下の2つのうちいずれかのプロトコル用いて、通信を行う（原理的には、両方のプロトコルを適用することも可能である）：
AHやESPの暗号処理に必要な共通鍵は、SAの確立の際に生成もしくは読み込んだものを用いる。
認証暗号は、平文の暗号化とメッセージ認証の両方を実行できる共通鍵暗号方式である。したがって、ESPを用いた場合、パケットの秘匿性と改竄検知の両方が担保される。一方、AHを用いた場合、改竄検知しか担保されない。
通信は、以下の2つのいずれかの動作モードに従って行う：
トランスポートモードは、主に2つのホスト間の通信で使われ、トンネルモードは、主にセキュリティ・ゲートウェイとセキュリティ・ゲートウェイ、およびセキュリティ・ゲートウェイとホストの間の通信で使われる。
ピアRは、パケットを受け取り、SADの記載に従って、パケットを破棄するか否かを決める。そして、パケットがIPsecのものであれば、パケットを復号し（暗号化されている場合）、さらにメッセージ認証の検証を行った上で、上位レイヤーのプロトコルにパケットを渡す。パケットがIPsecではなく通常のIPのものである場合、復号などの処理を施さず、直接上位レイヤーのプロトコルにパケットを渡す。
特に断りがない限り本節の記述はRFC 7321 2.3-2.4節で要求レベルがSHOULD以上のものに基づいた。
AHのMACとしてAES-GMACがSHOULD+、AES-XCBC-MAC の出力を96ビットに切り詰めたもの（AES-XCBC-MAC-96）がSHOULDである。NULL（＝MAC無し）もMAYである。
ESPの認証暗号としてAES-GCMがSHOULD+である。Encryption-then-Mac (EtM)型の認証暗号としては、暗号部分はNULL （＝暗号化しない）とAES-CBCがMUSTであり、MAC部分はHMAC-SHA1の出力を96ビットに切り詰めたもの(HMAC-SHA1-96)がMUST、鍵長128ビットのAES-GMACがSHOULD+、AES-XCBC-MAC の出力を96ビットに切り詰めたもの（AES-XCBC-MAC-96）がSHOULDである。
ただし以上の要求レベルは過去の経緯にも基づいており、安全性や効率の観点から見た場合はAHにはAES-GMAC、ESPにはAES-GCMを推奨している(RFC 7321 4.1節、4.3節)。
AH (Authentication Header) は、認証および改竄防止機能を提供する。データそのものは暗号化されないので、盗聴防止には利用できない。RFC 1826 形式の AH には再送防止機能 (Anti Replay Counter) が無いが、RFC 2402 では 32 bit の、RFC 4302 では 64 bit のカウンタが付けられており、過去に送信されたパケットがコピー再送されても多重受信しない機能がオプションとして利用できる。
| Offsets | Octet16 | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet16 | Bit10 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Next Header | ペイロード長 | 予約済み | |||||||||||||||||||||||||||||
| 4 | 32 | Security Parameters Index (SPI) | |||||||||||||||||||||||||||||||
| 8 | 64 | 順序番号 | |||||||||||||||||||||||||||||||
| C | 96 | Integrity Check Value (ICV) … | |||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
ESP (Encapsulated Security Payload) はペイロード部を暗号化する。正確には、IP ヘッダ、経路ヘッダ、ホップバイホップオプションヘッダを除いた部分が暗号化される。RFC 1827 形式の ESP には認証機能が無いが、RFC 2406 /RFC 4303 形式の ESP にはオプションとして「認証トレイラー」機能があり、AH を併用せずとも改竄防止機能を利用することが可能となっている (ただし保証されるのはデータ部分だけで、IP ヘッダ部分の改竄を検出することはできない)。また後者には AH 同様に再送防止機能も追加されている。
RFC 1826 /RFC 1827 形式の AH/ESP はそれ以降の RFC とヘッダ長が異なるため互換性がない。RFC 4302 /RFC 4303 形式の 64 bit カウンタは ESN (Extended Sequence Number) とも呼ばれるが、実際にパケットに付加されるのは下位 32 bit だけで、見た目はRFC 2402 形式のパケットと区別が付かない。ただし認証ベクタ (ICV) の算出には全 64 bit が使用されるため、RFC 2402 /RFC 2406 形式の IPsec とRFC 4302 /RFC 4303 形式の IPsec の間にも直接の互換性はない。RFC 4302 /RFC 4303 仕様の IPsec 実装でRFC 2402 /RFC 2406 形式と通信するためには、32 bit の互換カウンタ使用を明示指定する必要がある。
| Offsets | Octet16 | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet16 | Bit10 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Security Parameters Index (SPI) | |||||||||||||||||||||||||||||||
| 4 | 32 | 順序番号 | |||||||||||||||||||||||||||||||
| 8 | 64 | ペイロード | |||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
| … | … | Padding (0-255 octets) | |||||||||||||||||||||||||||||||
| … | … | Pad Length | Next Header | ||||||||||||||||||||||||||||||
| … | … | Integrity Check Value (ICV) … | |||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
 | 「IKE」はこの項目へ転送されています。SPYAIRの元メンバー（ボーカル）については「SPYAIR#メンバー」をご覧ください。 |
IKE (Internet Key Exchange protocol) は SAを構築するのに必要な情報の交換を安全に行うプロトコル。IKEv1 (RFC 2409) と IKEv2 (RFC 4306) が定義されており、2016年現在の最新版は後者である。
また IKEv1/v2 以外にも Photuris (RFC 2522), KINK (RFC 4430) などの鍵交換プロトコルが提案されている。
IKEv1は Internet Key Exchange protocol version 1 の意味であり、UDPポート番号500上で通信される鍵交換プロトコルである。開発時には ISAKMP/Oakley と呼ばれた過去があり、これはISAKMP(Internet Security Association and Key Management Protocol)プロトコルの上で Oakley 鍵交換手順を実装したものという意味である。すなわち、IKEv1 は ISAKMP と必ずしも同じものではない。
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,8192bit、EC2N で155,188,163,283,409,571bit が定義されている。
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において提示-合意のプロセスを踏んで実行され、認証方式には事前鍵共有方式 (PSK:Pre Shared Key)、デジタル署名方式 (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 には数多くのモードとパラメータとオプションの組み合わせがあり、さらに多くの拡張仕様が存在する。その中には標準案として提案されたもののドラフトを通過できず、正式なRFC として記載されずに終わったものも少なくない。また IKEv1 仕様には難解で紛らわしい用語が錯綜しているため、実装系において独自の名前を与えている場合もある（例えば Microsoft Windows では IPsec におけるセレクタをフィルタと呼び、ポリシーをアクションと呼んでいる)。このため「IETF標準」であるはずの IKEv1 同士でも、異機種間接続のためにはプロトコルおよび製品実装の深遠な理解が必要になってしまい、「IPsec でネットワークを組む場合は同じメーカーの同じ機器を使用することが最も確実」という慣習を生むことになってしまった。
IETF は混沌としてしまった IKEv1 の整理を諦め、IKEv2 をもって標準化の仕切り直しを図っている。
IKEv2プロトコルは、2005年のRFC 4306の付録Aで記述された[8]。以下のIKEv1の問題が対処された。
Aを持ち、HostBがSPIBを持つと仮定すると、シナリオは次のようになる。HostA -------------------------------------------------- HostB |HDR(A,0),sai1,kei,Ni--------------------------> | | <----------------------------HDR(A,0),N(cookie)| |HDR(A,0),N(cookie),sai1,kei,Ni----------------> | | <--------------------------HDR(A,B),SAr1,ker,Nr|
COOKIEタイプの通知メッセージを含む暗号化されていないIKE_SA_INIT応答メッセージをHostA（イニシエータ）に送信し、HostAがそのクッキー値を通知ペイロードに含めてIKE_SA_INITリクエストをHostBに送信することを期待する。これは、イニシエータが実際にレスポンダからのIKE応答を処理できることを保証するためである。IETFのipsecmeワーキンググループは、IKEv2プロトコルを近代化し、大量のトラフィックを扱う本番環境により良く適応させることを目的として、多くの拡張機能を標準化した。これらの拡張機能には以下が含まれる。
多くのネットワーク機器ベンダーは、独自のIKEデーモン（およびIPsec実装）を作成するか、相互にスタックをライセンス供与している。IKEv2の実装は数多くあり、IPsecの認証や相互運用性試験を扱う企業の中には、IKEv2試験に対応するためのワークショップや更新された認証要件の策定を開始しているところもある。
以下のIKEv2のオープンソース実装が利用可能である。
2014年にデア・シュピーゲルによって公開された、リークされたNSAのプレゼンテーションは、IKEがISAKMPと同様に、IPsecトラフィックを復号するために未知の方法で悪用されていることを示している。[11]Logjam攻撃を発見した研究者らは、1024ビットのDiffie-Hellmanグループを破ることで、VPNサーバーの66%、トップ100万のHTTPSドメインの18%、SSHサーバーの26%が破られると述べており、これはリーク情報と一致すると主張している。[12] この主張は、2015年にEyal Ronenとアディ・シャミアの両名によって彼らの論文「Critical Review of Imperfect Forward Secrecy」で反論され[13]、またLibreswanのPaul Woutersによって2015年の記事「66% of VPN's〔ママ〕 are not in fact broken」で反論された。[14]
複数の設定のネゴシエーションを許可するIPsec VPN設定は、IKEv1とIKEv2の両方で、提供される設定間で中間者攻撃ベースのダウングレード攻撃を受ける可能性がある。[15] これは、クライアントシステムをより厳格な設定を持つ複数のサービスアクセスポイントに慎重に分離することで回避できる。
IKE標準の両方のバージョンは、低エントロピーのパスワードが使用された場合にオフラインの辞書攻撃に対して脆弱である。IKEv1については、これはメインモードとアグレッシブモードの両方で当てはまる。[16][17][18]
IPsecはネットワーク層でセキュリティを実現するプロトコルであるため、アプリケーションなどの上位層が暗号化をサポートしていない場合でも通信全体としてのセキュリティを担保することが出来る。なおセキュリティをネットワーク層で実現しているため、アプリケーション層でセキュリティを実現しているTLSのように暗号化がどのプロトコルで行われているかをユーザーが容易に知ることはできない(TLSではwebブラウザに鍵マークが表示されるなど一見してそれが分かる表示がされる場合がある)。PCやスマートフォンなどのコンシューマ端末でもIPsecを利用することは可能であるが、現状は専門の技術者が管理するGateway間でVPNとして利用されることが多い。IPsecをVPNで利用する場合はIPアドレスを二重に付加するトンネルモードが利用できるが、IP以外のパケットも伝達するためL2TPなどのプロトコルと併用される場合もある。
IPsecはAHの認証機能、ESPの暗号機能を組み合わせて使うことができ、AH/ESPそれぞれに様々なアルゴリズムを指定することができる。この柔軟さが IPsec の利点ではあるが、設定可能な組み合わせは膨大となり、通信する二点間で全ての設定が一致していなければ通信が成立しない。多台数間のIPsec情報を手動で設定することは非常に手間がかかる上に、手動設定の場合は同じ鍵情報を長期間使い続けることになるため、セキュリティ強度の観点からも好ましくない。IPsecが上述したVPNで利用されることが多いのはこのためである。この手間を軽減するためネットワークで自動鍵交換を行うIKEv1,IKEv2,KINK,Photurisなどのプロトコルも提案されているが、各プロトコルには互換性が無い。最も普及しているIKEv1でも動作モード、認証パラメータ、認証方式、鍵交換アルゴリズム、暗号アルゴリズム及び認証アルゴリズムなど設定項目の組み合わせは多岐に渡り、IPsecを使いこなすには総じて高度な専門知識が要求される。
1993年12月、ソフトウェアIP暗号化プロトコルen:swIPe (protocol)はコロンビア大学とAT&Tベル研究所でジョン・ヨアニディス他によって研究されていた。
クリントン政権がwhitehouse.govの電子メールをトラスディド・インフォメーション・システムズにホスティングした資金によって(1993年6月1日から1995年1月20日)、ウェイ・シューは1994年7月、IPセキュリティの研究に着手、IPプロトコルの機能を拡張し、BSDIプラットフォーム上にIPSecを開発、すぐにSunOS、HP-UX、その他UNIXシステムにも移植した。その成功にもとづいてウェイはDESとトリプルDESの計算速度改善にも取り組んだ。アセンブリ言語によるソフトウェア暗号化はIntel 80386アーキテクチャではT1の通信速度にさえ対応できなかった。ドイツからCryptoカードを輸出、ウェイはさらに今日プラグアンドプレイと呼ばれる、自動化されたデバイスドライバも開発し、ハードウェアのCryptoと統合した。T1を超えるスループットを実現した後、ウェイ・シューはついに実用に耐える商品を作成、著名なGauntletファイアーウォールの一部としてリリースした。1994年12月、米国の東海岸、西海岸にある遠隔拠点を結ぶ通信を暗号化するために初めて本番導入された。
一方、IPカプセル化セキュリティ・ペイロード (ESP)[19]はDARPAの資金による研究プロジェクトの一部としてアメリカ海軍調査研究所で研究され、1993年12月、IETFのSIPP作業部会によってSIPPに対するセキュリティ拡張としてドラフトが公開された[20]。このESPはもともとISOのネットワーク層セキュリティプロトコル（NLSP）ではなく、アメリカ国防総省のSP3Dプロトコルから派生したものだった。SP3Dプロトコルの仕様はNISTにより公開されたが、アメリカ国防総省のセキュアデータ・ネットワークシステム・プロジェクトにより設計されたものだった。セキュリティ認証ヘッダ（AH）の一部は、以前のSimple Network Management Protocol(SNMP)バージョン2の認証のためのIETF標準策定作業から派生したものである。
1995年、IETFのIPsec作業部会はオープンかつ自由に利用できるバージョンのプロトコル作成を開始、セキュアデータ・ネットワークシステム(SDNS)プロジェクトに関するアメリカ国家安全保障局の契約の下で開発された。SDNSプロジェクトが定義したセキュリティプロトコル・レイヤー3(SP3)はNISTによって公開され、ISOのネットワーク層セキュリティ・プロトコル(NLSP)[21]の基礎にもなった。SP3の鍵管理は鍵管理プロトコル(KMP)によって提供され、これらに続くIPsec委員会の作業のベースラインを提供した。
IPsecは公式にはインターネット・エンジニアリング・タスクフォース(IETF)のRequest for Comments(RFC)の一連の文書として標準化され、さまざまなコンポーネントや拡張に対応している。その文書でプロトコルの名称はIPsecと表記すると定められている。[22]
| 国立図書館 | |
|---|---|
| その他 | |
 | この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |
