$Id: report-ipsec-cnlan9808.html,v 1.2 1999/12/31 08:26:58 sakane Exp $
ここにある文章は「コンピュータ&ネットワークLAN 1998/8月号」に掲載された記事です。
オーム社編集部の許可を得て公開しています。
WEBで公開するため若干手を加えているので、表現や言葉使いに相違があります。
1999/03/03 IPヘッダの認証とIPデータグラムの認証を区別。
%Hd: "IPsec セミナールーム第1回" コンピュータ&ネットワークLAN 1998年8月号
ネットワーク層でセキュリティを提供する技術である
Security Architecture for the Internet Protocol (以降 IPsec と略す)が
RFC として世に送り出されてから、3年になろうとしています。
また、IPsec 準拠を唱ったファイアウォールや、OSも数多く出てきています。
そこで IPsec を知らない方を対象に、その概要と構造、
そして今後の展望について書いていきたいと思います。
第1回 IPsec って何?
インターネットの裏側
普段何気なく手紙に書いている情報は、簡単に他人に盗み見られてしまいます。
別に疑うわけでは無いのですが、郵便配達員ならば間違いなく読む事は可能でしょう。
また、悪意を持った者であれば、鍵付きポストを壊したり、封書を破って読むことを
何とも思わないでしょう。
インターネットで使われる電子メールは、これに例える事が出来ます。
他にもインターネットには、サーバからメールを取得したり telnet などで
ホストにログインする時に必要なパスワードは、大抵盗聴可能な形で流れます。
さらにインターネット・ショッピングモールに行って買物をした後に
何気なく入力する個人情報なども同様です。
つまり、悪意のある者がターゲットの情報が流れる経路にさえ侵入出来てしまえば、
情報は取り放題になるわけです。
最近、あるパケットをサーバに送り続けて負荷を上げてサービスを不能にしてしまう
悪戯(Denial of service attack)が流行っています。
また、リセット・フラグの立っているTCPパケットを投げつけて
強制的にコネクションを切ってしまう悪戯もあります。
このようなことも実は現状のTCP/IPネットワーク上では簡単に出来てしまいます。
この手の悪戯は昔からあったのですが、WWWを利用して情報が簡単に入手出来るように
なったのが原因で広まっているのだと思います。
アプリケーションによるセキュリティ
ネットスケープナビゲータの左下にある2つに割れた鍵が継っているのを
見た事があるでしょうか?
これはナビゲータとサーバ間でのみ共有する暗号鍵を使って、この間を流れる情報を
暗号化して通信が行われている状態を示すものです。
これは SSL (Secure Socket Layer, ※1) と呼ばれています。
プロバイダのオンラインサインアップの時などは大抵SSLの元で通信が行われます。
遠隔地の計算機でコマンドを実行したりログインする時には SSH(Secure Shell, ※2)
と言うアプリケーションがあります。
これは通信を行うユーザを認証して、さらに流れる情報を暗号化するものです。
ある程度設定は必要ですが、非常に便利なアプリケーションです。
IPsec の登場
これらのサービスはアプリケーションにより実現されているので、予め通信する
2つのホスト上に、このアプリケーションをインストールしなければいけません。
通信する相手が少なければ良いですが、多くなるとそれだけ設定の手間がかかります。
しかし、このようなセキュリティを提供する機能がOSやルータに実装されていれば、
ユーザは意識せずに比較的かなり安全な通信が可能になります。
IETFの IPsec WG (※3)では現在、これらのセキュリティをOSI参照モデル(図1)の
ネットワーク層で提供することについて議論しています。
+----------------------------------------+
| Application 層 |
+----------------------------------------+
| Presentation 層 |
+----------------------------------------+
| Session 層 |
+----------------------------------------+
| Transport 層 |
+----------------------------------------+
| Network 層 |
+----------------------------------------+
| Datalink 層 |
+----------------------------------------+
| Physical 層 |
+----------------------------------------+
図1. OSI 参照モデル
この WG は1992年に Al Hoover, Paul Lambert らを議長として、
IPSEC Protocol Working Group という名で発足しました。
その後、次世代インターネットプロトコルを模索していた IPNG WG (※4)内の
セキュリティについて議論をしている部門が、検討内容が類似していたことと
メンバーがかなり重複していることを理由とし、1995年に統合され現在に至っています。
1995年8月に『IPセキュリティアーキテクチャ』という RFCを Standards Trackとして
提出し、それとほぼ同時期にセキュリティプロトコル等のRFCも提出しました。
しかし、それ以降も議論が重ねられ、曖昧な点や安全性に疑問が残る点等を改良し、
前出のRFCを置き換えるためのドラフトは最終段階に来ています。
IPsec の概要
IPsec は、もともと米国政府が必要としていた1つのネットワーク上で異なる
機密レベルの通信を行うためのものでした。
しかし、インターネットにおけるユーザの爆発的な増加により、
誰でも利用できる安全性のある通信を提供することがその主たる目的になっています。
それゆえ IPsec には、柔軟性があり、ユーザにとって透過的(※5)なセキュリティを
提供できることが求められています。
IPsec の特徴として以下の3つがあげられます。
- 多様なセキュリティポリシに対応可能
- 暗号技術の使用
- 透過的なセキュリティの実現
企業によっては、AというネットワークからBというネットワークの通信は安全に、
CからBへはさらに高い安全性を持った通信を行いたいと思うかもしれません。
また、ある外部のPというユーザからの要求は暗号化されていることが条件で
社内のネットワークに受け入れることを望むかも知れません。
さらには、あるサーバのあるサービス、例えば人事データベースを利用するユーザの
通信は、他の社員に盗聴されたくないと思うかもしれません。
IPsec ではTCP/IPパケットやソケットから得られる情報を元に、
それぞれに適したセキュリティプロトコルや暗号処理を決定することによって、
様々なポリシに対応します。
IPsec では、例えば、DES や CAST 等の共通鍵暗号を用いてデータの暗号化を行ったり、
場合によっては RSA 等の公開鍵暗号を用いて送信元の認証を行います。
これらの暗号方式は、取り換えや組み合わせがある程度自由に出来るように
設計されていて、OSがサポートしさえすれば、ユーザやアプリケーションは
これらの暗号を自由に選択できます。
そして、これらの暗号の特性等を利用して以下のサービスを提供しています。
- コネクションレスな完全性 (Connectionless integrity)
- IPヘッダの認証
- IPデータグラムの認証
- 再送攻撃に対する耐性 (Anti-replay)
- 暗号化による秘匿性
- 限定されたトラフィックフローの秘匿性
- アクセスコントロール
コネクションレスな完全性とは、
たかだか一つのパケットの改纂が分かることが可能なサービスであり、
一連のパケットの順序やパケットの損失を見つけることは出来ません。
IPヘッダの認証は、いくつかのヘッダオプションも対象になります。
再送攻撃に対する耐性とは、パケットの再送を意図的に行う悪戯に耐性があることです。
限定されたトラフィックフローの秘匿性とは、ゲートウェイ間でパケットを暗号化する
ことにより実際に通信している2点間の通信の秘匿性をサービスするものです。
これはトラフィック分析に対して弱い耐性があるとも言えます。
IPsec はIPv4,IPv6で共通の技術となるように設計されています。
しかし、IPv4では追加機能として定義されているため、
使うためには既存のものを置き換えなければなりません。
IPv6は現在開発中のプロトコルであり、しかもIPsecは実装必須になっているため、
導入した時点でセキュリティ機能を使えるようになります。
IPsec の安全性
IPsec の安全性は、以下の項目に完全に依存しています。
これらのうち一つでも欠けると、その保証は出来なくなってしまいます。
- 実装されている暗号アルゴリズムの強度
- 暗号アルゴリズムの実装の正確さ
- 使用されている鍵の強度
- 鍵管理プロトコルとその実装の安全性
- 関係している全システムのセキュリティプロトコルとIPの実装の正確さ
- 実装されている OS の安全性
実装されている OS の安全性とは、
対称鍵や非対称鍵暗号における秘密鍵を安全に隠蔽することができるかどうかです。
同一システム上の異なるユーザ同士が互いに信用できない可能性がある時に、
ユーザまたはセッション単位で個々に秘密の鍵を持つことができなければ、
そのシステムは安全とは言えないのです。
また IPsec では、トラフィック分析に対する強い耐性がありません。
前述したように、ある程度は可能なのですが、例えばゲートウェイの手前では
どこが通信しているか識別はできてしまいます。
また、E-Mail アドレスを偽造して相手に嘘の情報を送り付けることや、
ディスクに書き込まれた情報等のアプリケーション固有の情報の保護もできません。
このように、インターネットにおける全てのセキュリティの問題を解決していない
と言う事も重要な IPsec の特徴と言えます。
IPsec の構成要素
IPsec の構成要素は大別すると以下の4つに分けられます。
- セキュリティ・アソシエーション (以降 SA と略す)
- 鍵管理
- セキュリティプロトコル
- トランスフォーム
SA とは、安全な通信を提供するための論理的なコネクションのことで、
SA が確立すると、そこを流れるトラフィックは IPsec が提供するセキュリティの
範囲で安全であると言えます。
この SA を構成するパラメータを管理する部分のことを、鍵管理と呼びます。
これにはコマンドによる設定方法や、デーモンによる方法があります。
セキュリティプロトコルは、パケットに直接関係する部分で、
以下の2つが定義され実装必須になっています。
- IP Encapsulating Security Payload (ESP) (※6)
- IP Authentication Header (AH) (※7)
セキュリティプロトコルのなかでは、様々な認証アルゴリズムや暗号アルゴリズムが
用いられますが、これらアルゴリズムをパケットに適用する規則をトランスフォームと
読んでいます。
認証アルゴリズムのためのトランスフォームには、HMAC-MD5-96 (※8),
暗号アルゴリズムのためのトランスフォームには、DES-CBC (※9) 等があります。
このように、いろいろと分離されている理由は、新しくより強力なセキュリティ機能が
開発された時に、他の機能に影響を与えずに容易に交換できるように考慮したためです。
次回は IPsec の構成要素について、さらに詳しく書きたいと思います。
捕捉
- ※1:
http://home.netscape.com/eng/ssl3/ssl-toc.html
- ※2:
http://www.cs.hut.fi/ssh/
- ※3:
http://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html
- ※4:
http://www.ietf.cnri.reston.va.us/html.charters/ipngwg-charter.html
- ※5: transparent, "意識する事無く"の意。ネットワーク用語としてよく使われる。
- ※6:
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-esp-v2-05.txt
- ※7:
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-auth-header-06.txt
- ※8:
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-auth-hmac-md5-96-03.txt
- ※9:
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-ciph-des-expiv-02.txt
第2回/
第3回