IPsec

出典: フリー百科事典『ウィキペディア(Wikipedia)』
IPSecから転送)
移動先: 案内検索

テンプレート:Infobox IPsec(Security Architecture for Internet Protocol、アイピーセック)は、暗号技術を用いて、IP パケット単位でデータの改竄防止や秘匿機能を提供するプロトコルである。これによって、暗号化をサポートしていないトランスポート層アプリケーションを用いても、通信路の途中で通信内容を覗き見られたり改竄されることを防止できる。

IPsec は、AH (Authentication Header) による認証機構とデータの完全性保証、ESP (Encapsulated Security Payload) によるデータ暗号化等のセキュリティプロトコルと、IKE (Internet Key Exchange protocol) などによる鍵交換から構成されている。

IETFの ipsec wg にて規格策定が行われていたが、現在その規格はほぼ固まっている。

IPv4, IPv6 両者で利用できる。IPv6 では専用の拡張ヘッダが定義されているが、IPv4 では IP ヘッダオプションを利用する。

IPsec の動作モードには、パケットデータ部のみを暗号化(ないしは認証)するトランスポートモードと、ヘッダを含めたパケット全体を丸ごと「データ」として暗号化(ないしは認証)し新たなIPヘッダを付加するトンネルモードがある。トンネルモードは主としてVPNで使用される。

IPsec の仕組み

IPsec は、ノード間通信のセキュリティ確保のために、認証(なりすまし防止)・データの完全性保証や暗号化を行うセキュリティプロトコル利用する通信方法である。殆どの場合、複数のセキュリティプロトコルを組み合わせて利用する。

IPsec は同一ノード間の通信でも、プロトコルやポート番号などによって複数の暗号化方式や暗号鍵、セキュリティプロトコルを使用することができる。このように双方で共有するパラメータを SA (Security Association) といい、SA を管理するデータベースを SAD という。どのプロトコルでどの SAD を使うかを決めるのが、SP (Security Policy) で、SP を管理するデータベースが SPD である。 エンコードされた IPsec ヘッダ (AH/ESP) には自身の所属する SA を示す32bit の ID 情報が付加され、これを SPI と呼ぶ。紛らわしいが SPI は Security Parameter Index の略であり、Security Policy と直接の関係はない。

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

AH

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

ESP

ESP (Encapsulated Security Payload) は 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 の互換カウンタ使用を明示指定する必要がある。

RFC182x 形式の IPsec を IPSECv1, RFC260x 形式を IPSECv2, RFC430x 形式を IPSECv3 と呼ぶこともあるが、これは非公式なものであり、IETF ではバージョン番号を与えていない。

IKE

IKE (Internet Key Exchange protocol) は 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上で通信される鍵交換プロトコルである。開発時には 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 をもって標準化の仕切り直しを図っている。

IPsec の特徴

暗号化する層

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を使いこなすには総じて高度な専門知識が要求される。

IPsec が使えるシステム

  • Windows - Windows2000 / XP は IPv4, IPv6 で利用可能であるが、IPv6はESP暗号化に対応していない。Windows VistaはIPv4、IPv6で利用可能である。
  • Mac OS X - KAME由来のIPsecが利用可能。OS標準のGUIで利用出来るのはL2TP / IPsecのみである。
  • BSD - FreeBSDNetBSDではKAMEで作られた実装が取り込まれており、OpenBSDでは独自に実装を行っている。
  • Linux - IPv4、IPv6で利用可能。IKEはKAME由来のipsec-toolsのracoonを利用する。他にFreeS/WANプロジェクトから派生したOpenswanstrongSwanがある。

関連する RFC

RFC 1826 (obsoleted by RFC 2402)
IP Authentication Header
RFC 1827 (obsoleted by RFC 2406)
IP Encapsulating Security Payload (ESP)
RFC 2367
PF_KEY Interface
RFC 2401 (obsoleted by RFC 4301)
Security Architecture for the Internet Protocol
RFC 2402 (obsoleted by RFC 4302 and RFC 4305)
Authentication Header
RFC 2403
The Use of HMAC-MD5-96 within ESP and AH
RFC 2404
The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2405
The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC 2406 (obsoleted by RFC 4303 and RFC 4305)
Encapsulating Security Payload
RFC 2407 (obsoleted by RFC 4306)
IPsec Domain of Interpretation for ISAKMP (IPsec DoI)
RFC 2408 (obsoleted by RFC 4306)
Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409 (obsoleted by RFC 4306)
Internet Key Exchange (IKE)
RFC 2410
The NULL Encryption Algorithm and Its Use With IPsec
RFC 2411
IP Security Document Roadmap
RFC 2412
The OAKLEY Key Determination Protocol
RFC 2451
The ESP CBC-Mode Cipher Algorithms
RFC 2857
The Use of HMAC-RIPEMD-160-96 within ESP and AH
RFC 3526
More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
RFC 3706
A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
RFC 3715
IPsec-Network Address Translation (NAT) Compatibility Requirements
RFC 3947
Negotiation of NAT-Traversal in the IKE
RFC 3948
UDP Encapsulation of IPsec ESP Packets
RFC 4106
The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
RFC 4301 (obsoletes RFC 2401)
Security Architecture for the Internet Protocol
RFC 4302 (obsoletes RFC 2402)
IP Authentication Header
RFC 4303 (obsoletes RFC 2406)
IP Encapsulating Security Payload (ESP)
RFC 4304
Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
RFC 4305 (obsoleted by RFC 4835)
Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 4306 (obsoletes RFC 2407, RFC 2408, and RFC 2409)
Internet Key Exchange (IKEv2) Protocol
RFC 4307
Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
RFC 4308
Cryptographic Suites for IPsec
RFC 4309
Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
RFC 4478
Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
RFC 4543
The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
RFC 4555
IKEv2 Mobility and Multihoming Protocol (MOBIKE)
RFC 4621
Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
RFC 4718
IKEv2 Clarifications and Implementation Guidelines
RFC 4806
Online Certificate Status Protocol (OCSP) Extensions to IKEv2
RFC 4809
Requirements for an IPsec Certificate Management Profile
RFC 4835 (obsoletes RFC 4305)
Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 4945
The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX

外部リンク

テンプレート:Asbox