Security Gateway and IPsec release 3
| 作成日 | 1999/Jul/23 |
| 最終変更日 | 2018/Nov/06 |
| 文書サイズ | 27KB |
近年、IPsecというセキュリティアーキテクチャが注目を集めている。 IPsecはIPレイヤにおけるセキュリティサービスを提供する枠組みである。 IPsecの仕様は、1995年に一度はRFCとなったものの、 幾つかの理由により再びインターネットドラフトの段階に差し戻された。 再び活発な議論が行われ、問題点が克服された結果、 1998年11月に再度RFCが提案されるに至った。 本資料は、この新しいRFCに基づいて、IPsecの概要を説明するものである。
IPsecの主要な目的は、 IPレイヤでのセキュリティサービスを提供することである。 より細かく言えば、相互接続性のある、高品質な、 暗号に基づくセキュリティサービスを提供することである。
IPsecで与えられたセキュリティサービスが、 IPレイヤの上位レイヤについても透過的に働くことが大きな特徴である。 もちろん、上位レイヤで別のセキュリティサービスを利用することができるが、 利用しない場合でも最低限のセキュリティ保護を受けることができる。 また、上位レイヤのセキュリティサービスと併用することによって、 より頑強なセキュリティ保護が提供される。
アクセスコントロールは、 存外のアクセスが発生しないようアクセスを監視・制御するものであり、 完全性は、第三者が情報を書き換えたときに、それを検出できるような特性である。 認証は、第三者のなりすましを検出するものであり、リプレイ攻撃は、 過去に発生した通信シーケンスをそっくりに真似して、 認証チェックを潜り抜ける手法である。 機密性は、通信の内容が第三者には分からないという特性であり、 秘匿性は、通信の存在が第三者に分からないという特性である。
暗号や認証を用いるには、それぞれのアルゴリズムが必要であるが、 IPsecは、特定のアルゴリズムに依存せずに機能する。 すなわち、IPsecの枠組みを用いて、様々のアルゴリズムが利用できる。 この理由は、おそらく、どんなアルゴリズムでも、採用した途端に欠陥が指摘され、 利用できなくなるという歴史があるからである。
なお、最低限の相互接続性を保証するために、 幾つかの基本的なアルゴリズムが用意されている。 例えば、暗号アルゴリズムのDES-CBCや、認証アルゴリズムのHMAC-MD5などである。
IPsecは、以下の3つのプロトコルによって、セキュリティサービスを提供する。
認証ヘッダ(AH : Authentication Header)は、 IPパケットの一部または全部を認証するためのプロトコルである。 AHにはトンネルモードとトランスポートモードという2つの認証の方式がある。 認証には、認証用のアルゴリズム(認証アルゴリズム)が用いられる。 認証アルゴリズムには特に決まったものが存在するわけではなく、 色々なアルゴリズムを利用することができる。
暗号ペイロード(ESP : Encapsulating Security Payload)は、 IPパケットの一部または全部を暗号化するプロトコルである。 ESPにもトンネルモードとトランスポートモードという2つの暗号化の方式がある。 暗号化には、暗号アルゴリズムが用いられる。 AHと同様に、特に決まったアルゴリズムはなく、 色々なアルゴリズムを利用することができる。
IPsecでは、認証や暗号化に必要な鍵を用意するプロトコルが必要である。 このようなプロトコルは、鍵管理プロトコルと呼ばれる。 鍵管理プロトコルには、手動のものと自動のものがあり、 それぞれ、手動鍵管理プロトコル、自動鍵管理プロトコルと呼ばれる。 自動鍵管理プロトコルには、Kerberos、SKIP、Photuris、IKEなどがある。
これらの中でも特に、IKEがIPsecの標準的なプロトコルとして採用されている。 しかし、もちろん他の鍵管理プロトコルを利用することもできる。 ちなみに、IKEはInternet Key Exchangeの略であり、「あい・けー・いー」 と発音する。
1999年1月現在のRFCを以下に示す。
RFC2401は、IPsecを勉強する人が最初に読まなければならないドキュメントである。 残りのRFCはこれを補足するために存在している。
AHは認証ヘッダ、ESPは暗号ペイロードのことである。 AHはIPパケットに認証情報を付加するプロトコルで、 ESPはIPパケットを暗号化するプロトコルである。 なお、ESPのEがEncryptionの頭文字でないことに注意を要する。 実のところESPは常にIPヘッダを暗号化するわけではない。 しかし、とりあえず"ESP = 暗号化"と認識しておけば良いと思う。
繰り返しになるが、IPsecは認証・暗号アルゴリズムに依存しない枠組みである。 ここに挙げたアルゴリズムは、 最低限の相互接続性を保証するために用いられる基本的なアルゴリズムである。
RFC2403とRFC2404は認証アルゴリズムを扱っているが、 タイトルにESPの文字が見えることに注意する必要がある。 ESPの主要な機能はIPパケットの暗号化であるが、 オプションとして認証を扱うことができる。
これらは全てIKEに関するRFCである。 「ISAKMP」や「OAKLEY」は、IKEの基になったプロトコルの名前である。 昔、IKEは「ISAKMP/Oakley」と呼ばれており、今でもその名残が存在する。 「ISAKMP/Oakley」は、「いざくんぷ・おーくりー」もしくは、 「あいさかんぷ・おーくりー」と発音する。
RFC2393は、IPパケットの圧縮方式をまとめたドキュメントであり、 IPsecとの直接的な関係はないが、 IPsec環境での利用を想定しているのでここに挙げる。 このプロトコルを用いると、 ESPで暗号化する前のIPパケットに圧縮をかけることができ、 低速回線における通信負荷を軽減することができる。
IPsecの実装は、ホスト、もしくはセキュリティゲートウェイで機能する。 セキュリティゲートウェイとは、IPsecが実装されていて、 ホストとホストの間に位置するシステムを指す。 例えば、 IPsecを実装したルータやファイアウォールはセキュリティゲートウェイである。 以下、セキュリティゲートウェイをSGWと書く。
IPsecシステムは、AHとESPをセキュリティ保護のための武装として用いる。 AHやESPのないIPパケットは「生」であり、 セキュリティ保護はないものと考えられる。
IPsecシステムは、一種の関所としてIPパケットを監視する。 関所の片側はセキュリティ保護を必要としないような安全な世界である。 もう一方はセキュリティ保護の必要な危険な世界である。 IPsecシステムがセキュリティゲートウェイの場合、典型的には、 前者がLANであり、後者がWANである。 ここでは前者を「内側」、後者を「外側」と呼ぶ。
まず、内側から外側へ出るパケットについて考える。これらのパケットは 「生」のまま通してしまうと、外側で攻撃にさらされる可能性がある。 そこでIPsecシステムは、 このパケットにAHやESPを付けてセキュリティ保護を与える。 もちろん何も付けずに送り出すという選択肢もある。 どうでも良いパケットならば何もせずに通しても良い。
次に、外側から内側へ入るパケットについて考える。 もし、AHやESPが付加されているならば、それはどこかのIPsecシステムが、 セキュリティ保護を与えたことを意味する。 IPsecシステムは、とりあえずAHやESPを外そうと試みる。 もちろん、外すためには、 これを付加したシステムとの間で友好関係を結んでいなければならない。 友好関係の契札はSAと呼ばれる。SAについては後述するが、 SAがあれば、AHやESPを外すことができる。外れたら、それを内側へ取り込み、 外れなければ、それを破棄する。
AHやESPを付加するときには、適用すべきアルゴリズムや鍵の長さなど、 多くの選択肢があるため、バリエーションに富んだセキュリティサービスが 提供される。特に選択するアルゴリズムや鍵の長さによっては、 セキュリティ保護の強さが異なる点に留意する必要がある。
また、トラヒックによっては、 求められるセキュリティ保護の強さに違いがあると思われる。 例えば、TELNETのセッションを強力な暗号で保護したいという要求がある一方で、 経路制御に関する情報は全く保護を必要としないかもしれない。
以上の2点を考えると、明らかに、 トラヒックに対して適切なアルゴリズムや鍵長が選ばれるべきである。 そこで、トラヒックとセキュリティサービスを対応づけるために、 セキュリティアソシエーション(以下SAと略す)という概念が定義される。
SAには、
などの情報が格納されていて、 IPsecシステムが自由に参照できるように設計されている。 そして、IPパケットがIPsecシステムを通過するときには、 IPパケットに対応するSAを探し、 そのSAが示すアルゴリズムや鍵の長さを用いる。 明らかに、 同じSAで処理されたIPパケットには、 同じセキュリティサービスが提供される。
この文書ではSAについての詳細を扱わず、以下に主要な特徴を挙げるに留める。
以下に典型的な実装例を示す。
認証ヘッダはAuthentication Headerの和訳であり、AHと略すことが多い。 AHにはIPパケットの認証情報が含まれている。 AHによって提供されるセキュリティサービスには、 完全性、認証、リプレイ攻撃に対する防御、アクセスコントロールがある。
AHの書式を以下に示す。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SPIは、SAを識別するための識別子である。 SPIの役割は、AHを受け取ったセキュリティ・ゲートウェイに対して、 どのSAによってパケットを処理したらよいか、通知することである。 Sequence Numberは、リプレイ攻撃を防ぐために設けられたフィールドであり、 複製されたパケットを繰り返し処理しないために用いられる。
IPパケットに対してAHを付加するときには、2つの方法を選択することができる。 1つはトンネルモード(tunnel mode)、 もう1つはトランスポートモード(transport mode)と呼ばれる。
トンネルモードでAHを付加すると、以下のようになる。
元のパケット
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AHが付加されたパケット
------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
|← authenticated except for mutable fields -→|
| in the new IP hdr |
元のパケットの内容は変更を受けることなく、新しいIPヘッダとAHが付加される。
AHには、新しいパケット全体の認証情報が含まれる。
トランスポートモードでAHを付加すると、以下のようになる。
元のパケット
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AHが付加されたパケット
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
|←------ authenticated ------→|
except for mutable fields
元のパケットのIPヘッダの直後にAHが挿入される。AHには、
新しく構成されたパケット全体の認証情報が含まれる。
AHで標準的に使われる認証アルゴリズムには、HMAC-MD5とHMAC-SHA-1がある。 読みはそれぞれ「えっちまっく・えむでぃーふぁいぶ」 「えっちまっく・しゃーわん」である。 両者はそれぞれ、 MD5とSHA-1というハッシュ関数を認証用にアレンジしたものであり、 RFC2403、 RFC2404で定義されている。
暗号ペイロードはEncapsulating Security Payloadの和訳であり、 ESPと略すことが多い。 繰り返しになるが、EncapsulatingがEncryptingでないことに注意を要する。 ESPは暗号アルゴリズムと組み合わせ、 IPパケットの中身を暗号化するために用いられるが、 暗号化をしないようにESPを適用することもできる。 このためには、 RFC2410で定義されるアルゴリズムを用いる。
ESPはIPパケットを暗号化するが、オプションで認証情報を付加することもできる。 ただし、AHはIPヘッダも含めてIPパケットの全体を認証できるのに対して、 ESPの認証情報では、IPヘッダを認証することができない。
ESPによって提供されるセキュリティサービスには、 機密性、秘匿性、完全性、認証、リプレイ攻撃に対する防御、 アクセスコントロールがある。ただし、秘匿性の保護は限定的である。 ESPを用いると、通信相手を示す部分は暗号化されて見えなくなり、 一応の秘匿性は保護されるが、完全に通信の事実を隠すことは難しい。 一般に、インターネットではトラヒック解析が容易であり、 秘匿性を保護するのは難しいと考えられている。
以下にESPの構造を示す。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Auth. | Sequence Number | |Coverage +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----- | Payload Data* (variable) | | ^ ~ ~ | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid. | | Padding (0-255 bytes) | |Coverage* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------- | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SPIとSequence Numberについては、AHと同じであるため、説明を省略する。 暗号化された情報は、ESPの構造の一部となる。 ESPの最後の部分にはオプションで認証情報を付加することができる。 この認証情報は、AHの場合と異なり、 暗号化された情報のみに対する認証情報となる。 ESPについても、 AHと同様に、トンネルモードとトランスポートモードが定義されている。
トンネルモードでESPを付加すると、以下のようになる。
元のパケット
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
ESPが付加されたパケット
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
-----------------------------------------------------------
|←-------- encrypted ---------→|
|←---------- authenticated ---------→|
元のパケットが全て暗号化されてESPの構造の一部になる。また、先頭には、
新しいIPヘッダが付け加えられる。
トランスポートモードでESPを付加すると、以下のようになる。
元のパケット
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
ESPが付加されたパケット
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------
|←---- encrypted ---→|
|←----- authenticated ----→|
元のパケットのIPヘッダより後ろの部分が暗号化されてESPの構造の一部になる。
標準的に用いられるアルゴリズムには、DES-CBCがあり、 「です・しーびーしー」と発音する。 DES(Data Encryption Standard)は1970年代に米国で開発されたブロック暗号であり、 CBCは元のデータをシャッフルするときのモード(方法)を表す。 CBCの他には、ECB、CFB、OFBというモードがあるが、 IPsecではCBCが用いられる。また、鍵の長さは56bitである。 DESに関しては、解読技術が向上し、 今ではとても安価で高速な解読器(DES Cracker)を作ることができる。 例えば、DES Challenge III(99年1月)の勝利者は、22時間で解読に成功している。
なお、DESを異なる鍵で3回適用する3DES-CBCというアルゴリズムを用いる こともできる。これはDESに比べて256倍の強さを持つ。 3DESには、暗号化と復号化を交互に3回行うE-D-E型と、暗号化を3回行う E-E-E型があり、 鍵の数についても、2つの鍵を使うものと3つの鍵を使うものがあるが、 IPsecでは、3つの鍵によるE-D-E型が用いられる。
IKE(Internet Key Exchange)は、 IPsecで標準として用いられる自動鍵管理プロトコルである。 細かいことだが、「鍵管理プロトコル」と言うよりは、 原語に忠実に「鍵交換プロトコル」と言うべきかも知れない。 IKEは鍵管理よりも主に鍵交換の枠組みを規定している。
IKE(Internet Key Exchange)は、昔はISAKMP/Oakleyと呼ばれていた。 今でもIPsec関係の文書にはISAKMP/Oakleyという文字を多く見ることができる。 もちろん名称の問題であり、両者の間に本質的な違いはない。
IKEはDiffie-Hellmanの公開鍵配布の手法を基にしている。 オリジナルのDiffie-Hellmanの手法では、 中間者攻撃やサービス妨害攻撃に弱いという問題点があるが、 IKEではそれを阻止するための工夫が加えられている。
Diffie-Hellmanの手法は、 鍵を公開された通信路で配布するための手法である。 この手法の一例を以下に示す。
アリスとボブは、事前にpとqの2つの値を決めておく。
アリス : さいころを振って出た目をxとする。 ボブにp^x (mod q)を送る。アリスとボブが最後に求めた値は同じ値になる。したがって、 これを鍵として利用することができる。pとqの値にもよるが、 通信路に流れた情報は解析不可能な値である。 実際、qとして768bitや1024bitなどの大数が使われる。 xやyが十分に大きければ、xやyを逆算するのは難しい。
IKEを利用することの利点は、鍵を動的に生成し得ることである。 一般に秘密の情報を長い間、保持するのは難しいことであり、 必要なときに生成する方が、セキュリティの点では望ましいと言える。
一方、IKEを利用することの欠点は、 鍵を計算するために、かなりの計算量を取られることである。 十分に安全に鍵を交換するためには、桁数の大きな数についての演算が要求される。
IKEの主要な動作は鍵を生成することであるが、 鍵を生成するためにも別な鍵を利用する。 そこで最初に簡単な手法で鍵を生成し、その鍵を使って本物の鍵を生成する。 前者はフェーズ1と呼ばれ、後者はフェーズ2と呼ばれる。
フェーズ1には、 メインモードとアグレッシブモードの2つのモードが選択的に使われる。 アグレッシブモードはメインモードに比べて、 1つのメッセージあたりの情報量が多く、 少ないメッセージの交換で鍵を生成することができる。 フェーズ2ではクイックモードが使われる。