通信路のセキュリティ・・・通信路の暗号化

 TCP/IPを使ったインターネットの通信でセキュリティを確保しようとする場合には、様々な手段が考えられます。例えば、アプリケーションを選択して、そのアプリケーションだけをセキュアなものにする方向です。SSH、SSL、S/MIME、などがこの方向です。この方向を取る限りは、1つ1つアプリケーション毎にセキュリティの方法を導入しなくてはなりません。もう一つの方向は、もっと大括りにして、特定のレベルの通信全部をセキュアにしようとするアプローチです。このアプローチを取るものとしてIPsecがあります。






1 IPsec

1.1 IPsecの概要

 IPsecはどんなアプリケーションの通信であろうとお構いなしで、ネットワーク層のレベルで一纏めにしてセキュリティを提供しようとするものです。IPsecはIP層のレベルでパケット単位に暗号化/認証を提供しますので、通信にIPパケットを利用するものなら、TCPだけでなく、UDPでも、ICMPでも、あるいはそれ以外の何か新しく作ったプロトコルでも何でも、利用することができます。しかも、上のプロトコルには何の変更も加える必要がありません。

 IPsecはIP層レベルでパケット単位で暗号化/認証を提供しますので、ローカルなネットワーク同士を接続して、インターネット経由で機密情報を送れるようにしようというVPNの発想にとってはうってつけの仕掛けです。また、IPsecはVPNを構築するだけでなく、従来通りのエンドシステム同士の通信のセキュリティも提供しています。

 IPsecを導入するためにはIPを入れ替える必要があります。IPはOSのカーネルの一部として組み込まれていますので、IPsecを利用するためには通常OSをそっくり入れ替えなくてはなりません。

1.1.1 プロトコルの構成

 IPsecは大きく分けるとESPとAH、IKEから構成されます。

 ESP(Encapsulating Security Payload)はパケット内容を暗号化するための拡張ヘッダについて規定しています。暗号化することによってデータの中身を第三者から隠すことができます。IPプロトコルの番号は50番を使います。

 AH(Authentication Header)は、認証のための拡張ヘッダの仕様です。AHはパケットが送信途中で改竄されていないこと、パケットのヘッダに書かれたIPアドレスから送信されてきたこと、つまり本人から送信されてきたことを保証します。IPプロトコル番号は51番を使います。

 AHはRFC1826、2402、4302で規定され、ESPはRFC1827、2406、4303で規定されています。RFC2402、RFC4302のAHでは再送防止機能(Anti Replay Counter)がついていますが、RFC2402、RFC4302ではカウンターのビット数が違います。RFC2406、RFC4303のESPには認証機能もついていますので、AHと併用しなくても改竄防止ができます。実際には、IPsecの実装ではほとんどESPが使われています。なお、2406と4303のESPには再送防止機能もついています。

 ESP暗号化とAH認証の各サービスを提供するためには、秘密鍵を必要とします。この秘密鍵を交換する方法を規定するのがIKE(Internet Key Exchange)です。



1.1.2 ピア間のコネクション確立

 IPsecに参加している互いに対向するデバイスはピア(同等)の関係になります。IPsecではこのIPsecピアの間にSA(Security Association、セキュリティアソシエーション)と呼ばれるコネクションを確立します。このコネクションは単方向のコネクションですので、ピア間に上りと下りの2つのSAを確立しなくてはなりません。

1.1.3 2種類のピア

 IPsecのピアはホストタイプと、セキュリティ・ゲートウェイのタイプに分類できます。ホストタイプは個人用のクライアント端末やサーバのようなIP通信の端末に相当する機器にインストールします。セキュリティ・ゲートウェイはルータのようなIP通信を中継する機器にインストールします。
 
 IPsecはピアがどちらのタイプかはまったく気にしません。ホストとホスト間にSAを確立することも、ルータとルータの間にSAを確立することも可能です。

1.1.4 データベースの管理

 IPsecの各ピアはSPD(Security Policy Database)、SAD(Security Association Database)という2つのデータベースを管理します。SPDはIPアドレス、プロトコル、ポートなどの情報に応じてIPsecを使って送信するのか、IPsecを使わずに送信するのか、それとも破棄するのかを決めるために使います(セキュリティポリシー)。これに対して、SADは各ピアとSAを確立する際に利用するパラメータのデータベースです。

1.1.5 プロトコルの流れ

 ピアAがピアBに向けてIPsecの通信をする場合には以下の3ステップを踏みます。

≪ステップ1:SAの確立≫
 ピアAは上位層から依頼されたパケットをIPsecで送るのか、そのまま送るのか、それとも破棄するのかを、SPDを参照して決定します。
 
 IPsecで保護して送信すると決定した場合は、ピアAはピアBとの間でSAを確立するために必要なデータがSADに入っているかを確認し、揃っていれば、それらをSADから読み込みます。

 SA確立のための必要なデータが揃っていない場合は、ピアBとの間でIKE(Internet Key Exchange)を実行します。IKEでメインとなるのがピアとの鍵共有です。

 SAに必要な情報を交換するプロトコルとしては、IKE以外にもKINK(Kerberized Internet Negotiation of Keys)やIPSECKEY DNS recordsなどがあります。

≪ステップ2:IPsec通信≫
 SAを確立したらピアAとピアBはAHか、ESPのいずれかのプロトコルを用いて通信を行います。AH、ESPで使用する共通鍵はSA確立の際に生成もしくは読み込んだものです。この鍵は、平文の暗号化とメッセージ認証の両方ができる共通鍵暗号化方式です。ESPではパケットの秘匿と改竄検知の両方ができますが、AHでは改竄検知しか行いません。

 通信はトランスポートモードかトンネルモードの何れかの動作モードで行います。トランスポートモードではパケットのデータ部のみの暗号処理を施します。これに対して、トンネルモードはヘッダを含めたパケット全体を丸ごと「データ」として暗号処理を施し、新たなIPヘッダを付加します。

 トランスポートモードは主として2つのホスト間の通信で使用され、トンネルモードは主としてルータとルータ間、あるいはホストとルータ間の通信で使用されます。

≪ステップ3:受信処理≫
 ピアBはパケットを受け取ったら、SADの記載に従って、パケットを破棄するか否かを決めます。パケットがIPsecのものであれば、(暗号化されている場合は)パケットを復号し、更に改竄検知を行い、パケットによって指定された上位レイアのプロトコルにパケットを渡します。パケットがIPsecのものでない場合は、復号処理などをしないで、そのまま上位レイアのプロトコルにパケットを渡します。



1.2 セキュリティポリシー

 IPsecを実装したノードでは、IPパケットの処理方法を記述したセキュリティポリシーが必要となります。セキュリティポリシーではIPパケットに対して、パケットを破棄するか、IPsecを適用せずに通常の処理を行うか、あるいはIPsecを適用するかの区別を記述します。
 
 IPsecで保護すると規定したパケットに対しては、適用するプロトコル(AHまたはESP)やカプセル化のモード(トランスポートモードあるいはトンネルモード)についても指定します。

1.2.1 セレクタ

 セキュリティポリシーにおいて処理対象となるパケットを指定するために利用する情報をセレクタと呼びます。セレクタには、パケットの始点のIPアドレス、終点IPアドレス、トランスポート層プロトコル、送信元ポート番号、宛先ポート番号などが使用されます。

1.2.2 SPD

 IPsecのセキュリティポリシーはSPD(Security Policy Database、セキュリティポリシーデータベース)に登録します。SPDには出力パケットに適用する出力用SPDと、入力パケットに適用する入力SPDがあります。セキュリティポリシーの適用対象となるパケットはセレクタによって特定します。

 次に出力用SPDの例を示します。

評価
順序
セレクタ 適用するポリシー
始点
IPアドレス
終点
IPアドレス
プロトコル 宛先
ポート番号
1 10.1.1.0/24 10.2.1.0/24 Any Any IPsecの適用
ESPトンネルモード
トンネルの始点:10.1.1.1
トンネルの終点:10.2.1.1
暗号化アルゴリズム:
DES-CBC
認証アルゴリズム:
HMAC-SHA-1
2 Any Any Any Any 通常のパケット送信




1.3 SA

 IPsecはSAという概念を使います。SA(Security Association、セキュリティアソシエーション)は1つのピアから対向側のピアに対するセキュアな論理接続を提供します。SAのセキュリティを実現するのがAHやESPです。

 SAはAHやESPによって安全性を保障された一方向のトンネルです。SAに入ったトラフィックは、そのままの形で対向側のピアにまで届けられます。双方向の通信を安全に行おうとするなら、双方向のSAが必要となります。

 SAはSPI(Security Parameters Index)、終点IPアドレス、セキュリティプロトコル識別子(AH、ESPの何れか)の3つのパラメータで識別されます。終点IPアドレス、セキュリティプロトコルが異なると別のSAが使用されます。終点アドレス、セキュリティプロトコルが同じでも、別のSAを使うことができます。SPIを使うとこれらも識別できます。

 SAではカプセル化モードのうちトランスポートモードを使うのか、トンネルモードを使うのか、使用するプロトコルはAHか、ESPか、AHやESPが使用する認証アルゴリズムや、暗号化アルゴリズム、これらのアルゴリズムが使用する様々なパラメータ(鍵など)が決められています。

 SAは手動で設定することもできますが、IKEによって自動的にネゴシエーションすることもできます。

 SAはセキュリティポリシーに従って生成されます。あるパケットを処理しなくてはならない場合、最初にSPDが参照されます。ここに「IPsecの適用」と書かれていれば、次にSAが格納されているSADから、該当するSAを検索します。該当するSAが見つかればそれを使います。該当するSAがなかった場合は、IKEなどを使ってSAを生成します。


1.3.1 SAのパラメータ

 SAのパラメータを次に示します。

パラメータの種別 SAパラメータ
ユーザ設定
パラメータ
外側ヘッダの終点IPアドレス
IPsecプロトコルの種別
SPI値
カプセル化モード
認証アルゴリズム
認証鍵
暗号化アルゴリズム
暗号化鍵
ECNトンネル
シーケンス番号カウンタ
オーバフローフラグ
SAの有効期間
システム
パラメータ
シーケンス番号カウンタ
リプレイ攻撃防御ウィンドウ
パケット総転送数
経路MTU値
暗号化アルゴリズムで使用するIV

● ECNトンネル
 ECNトンネルは、IPsecでECN(明示的輻輳通知)(IPパケットのToSフィールドにRFC3168で追加した機能)機能を有効にするかどうかを記述します。有効にする場合は、「Allowed」と記述し、無効にする場合は「Forbidden」と記述します。このパラメータはオプションです。

● シーケンス番号カウンタオーバーフローフラグ
 シーケンス番号カウンターオーバフローフラグはIPsecの出力側で使用されます。IPsecでは、パケットごとにSAで管理されるシーケンス番号を付加されますが、このシーケンス番号が32ビットで表現できる数を超えた場合に、そのSAを破棄して、新しいSAを折衝するかどうかを予め決めておきます。"1"にセットすると、オーバした場合には新たに生成します。"0"の場合は、そのまま使い続けます。ただし、受信側でリプレイ攻撃防御機能が無効とされていることが予め分かっている場合(例えば、SAが手動で設定されている場合など)は、オーバーフローした場合でも引き続きSAを使い続けることができます。

● SAの有効期間
 SAの有効期間にはソフト有効期間とハード有効期間があります。ソフト有効期間は新しいSAの折衝を開始する時期を定めるもです。しかし、今まで使っていたSAは、新しいSAの折衝が開始してもそのまま使い続けることができます。ハード有効期間が過ぎると従来のSAを使うことができません。従って、ソフト有効期間が終わってから、ハード有効期間が終わるまでの間に新しいSAを更新しなくてはなりません。有効期間は、時間での指定(秒単位)と、送信するデータ量(キロバイト)での指定が可能です。

● シーケンス番号
 リプレイ攻撃から防御するための32ビット値です。SADではシーケンス番号のカウンタが用意され、パケットを送信するごとにカウンタを1つずつ増加させています。

● 経路MTU
 SAの始点から終点までの経路上でフラグメント化を発生せずにIPsecを適用して運ぶことができる最大のIPパケットサイズが入ります。



1.3.2 SAD

 SAを確立する際に利用するパラメータを管理しているのが、SADです。SADは手動で管理することもできますが、IKEを使う場合は自動で管理されます。

 SADには出力パケットの処理の際に参照される出力用のSADと入力パケットの処理の際に参照される入力用のSADがあります。

 SADはシーケンス番号カウンタ、シーケンス番号の超過範囲、リプレイ攻撃防止ウィンドウ、AH情報、ESP情報、SAの有効期限、IPsecプロトコルモード、経路MTUなどを管理しています。

 SADの例を次に示します。

キーとなるSAパラメータ その他のSAパラメータ
終点IPアドレス IPsecプロトコル SPI
192.168.1.1 ESP 1000 カプセル化モード:トンネルモード
暗号化アルゴリズム:BLOWFISH-CBC
暗号化鍵:1345bngmj...34598hjiky
IV:r27234a1234f45gh9
認証アルゴリズム:HMAC-SHA-1-96
認証鍵:1234ghrnm...9876werngh
シーケンス番号:884
192.168.20.2 ESP 1022 カプセル化モード:トンネルモード
暗号化アルゴリズム:3DES-CBC
暗号化鍵:q12340898...34hntmj
IV:3456789nhjumij
認証アルゴリズム:HMAC-SHA-1-96
認証鍵:234fnghu...456hnrgsb
シーケンス番号:567


1.4 IPsecの通信モード

 IPsec(AHとESP)には、IPsecパケット全体を保護する方法と、IPパケットのペイロードを構成する上位層のプロトコルを保護する方法の2つの方法があります。IPパケットのペイロードを保護する方法は、トランスポートモード(transport mode)といいます。トランスポートモードは2つのホスト間の関係です。これに対して、トンネルモード(tunnel mode)は、2つのルータ同士、あるいはホストとルータの間の関係です。トンネルモードでは、IPパケット全体をペイロードにする形でIPsecヘッダでカプセル化し、更にその前に新しいIPヘッダを付加します。

※ペイロードは、直訳的には対価(運賃、pay)が発生する荷物(load)という意味です。陸上運輸や海上運輸ではあまり使われませんが、民間航空分野では、旅客や貨物のことを指します。軍事分野、宇宙航空などでも使用する言葉です。この言葉が情報通信の分野でも使われるようになり、情報の分野では、データ伝送における正味のデータ部分を指します。例えば、TCPセグメントから見ると、上位層のアプリケーションから送信依頼をされたメッセージがペイロードで、それにセグメントヘッダを付けて、全体がセグメントになります。TCPからセグメントを託されたIPの立場から見ると、セグメント全体がペイロードで、それにIPヘッダを付けて、データグラム(あるいはパケット)が出来上がるということになります。

1.4.1 トランスポートモード

 トランスポートモードでは、第3層のペイロード(例:TCPセグメント、UDP、ICMPデータグラム)にIPsecヘッダを付けて、更にその前にIPヘッダを追加します。これを図示すると次のようになります。

IPヘッダ IPsecヘッダ TCPセグメント

 トランスポートモードでは、2つのIPsecホスト間のトラフィックを保護しますが、IPヘッダはむき出し状態ですので、IPパケットがどこからどこまで流れているかが表示されています。従って、分析ツールを使用すれば、どのホストとサーバの間の通信であるか直ぐに分かります。

 トランスポートモードはエンドシステム同士を接続しますので、IPsecの処理はエンドホストが行わなくてはなりません。ホストの負担は増大しますが、エンドツーエンドの通信を保護できます。

 エンドツーエンドの通信を保護しますので、エンドホストが異なるサブネットに存在している場合だけでなく、同じサブネットに所属している場合にも適用できます。


※図ではIPパケットが流れる方向の先頭にIPヘッダを付けています。これは流れる方向にパケットヘッダがある方が、視覚的に分かり易いと思ったためです。しかし、ヘッダフォーマットの記述方法としては左側が先頭になるように規則で決まっています。従って、ヘッダのフォーマットは左側が先頭になるように画いています。

 ルータとルータ、ルータとホスト間の通信にはトランスポートモードは使えません。ルータはネットワーク層の情報を元にして経路制御を行う機器ですので、ルータにIPヘッダよりも内側の情報を操作させるべきではありません。

1.4.2 トンネルモード

 トンネルモードSAは、2つのルータ間、あるいはルータとホスト間のアソシエーションです。トンネルモードでは、IPパケット全体が、IPsecヘッダでカプセル化され、IPsecパケットに新しいIPヘッダが追加されます。これを図示すると次のようになります。

新IPヘッダ IPsecヘッダ IPパケット

 トンネルモードでも、TCPに限らず、UDP、ICMPデータグラムも保護の対象となります。

 IPsecを実装したルータとルータの間の仮想トンネルを通っていく間、パケットの転送に関わる途中のルータは、IPsecヘッダでカプセル化された中身のパケットを見ることができません。そして、IPsecヘッダの先に付けられた新しいIPヘッダは、本来のものとは全く異なったものになります。新しく追加されたIPヘッダに含まれる終点アドレスと、始点アドレスはトンネルモードSAのペアであるルータあるいはホストのIPアドレスとなり、セキュリティが高まります。

※新しいIPヘッダの送信元と宛先は、IPsecヘッダでカプセル化されたIPパケットの送信元と宛先とは違いますので、NATシステムとの整合性は最悪です。NATシステムはIPsecよりも内側に付けなくてはなりませんが、最悪の場合はうまくいきません。

 トンネルモードを使用すると、ルータとルータ間(あるいはルータ、ホスト間)を専用線で結んだ専用線接続に近い効果が得られることが期待されます。ただし、トンネルモードで保護されるのはあくまでルータとルータ(あるいはルータとホスト)を結んだ通信路です。ネットワーク単位の保護ですので、SAはそれほど多くはなりません。交換される鍵の数も少なくて済みますので、鍵交換の作業もそれほどの負担にはならないでしょう。また、暗号化/認証処理を担当するのがルータですので、ネットワーク内部のホストは処理の負担から解放されます。


 トンネルモードのIPsecを動かすルータは、ファイアウォールの機能をもったものかもしれません。

 ルータとルータの間でのトンネルモードは、ルータ間にVPNを構築する場合などの有力な候補となります。



1.5 IPパケットの処理手順

 IPsec機器での、IPパケットの処理を、出力処理、入力処理に分けて説明します。

1.5.1 IPsec機器での出力処理

≪ステップ1:SPDからポリシーを検索≫
 対象となるIPパケットの始点IPアドレス、終点IPアドレス、プロトコル、宛先ポート番号などをセレクタとして、出力用SPDからセキュリティポリシーを検索します。

≪ステップ2:ポリシーの適用≫
 検索されたセキュリティポリシーが「破棄(discard)」である場合は、そのIPパケットを破棄します。「IPsecを適用しない(bypass IPsec)」の場合は、IPsecを適用しないで、通常の処理をします。「IPsecを適用(apply IPsec)」の場合は、IPsecの処理に進みます。

(IPsecの処理へ進む)
≪ステップ3:SAの検索≫
 ステップ2がIPsec処理の場合は、IPsecの処理に入ります。出力用のSADから該当するSAの情報を検索します。

≪ステップ4:SAの生成・確定≫
 該当するSAがなければ、新しいSAを生成します。該当するSAの情報が存在する場合は、そのSAに関する情報を取り出します。

≪ステップ5:パケットの送信≫
 IPsec処理を施したパケットを送信します。

1.5.2 IPsec機器での入力処理

 IPsec機器がIPパケットを受信した場合、そのIPパケットにIPsec処理を適用すべきかどうかを判断します。受信側のIPsec機器はパケットを受け取ったら、入力用のSPDから、セレクタの情報を基準にして、セキュリティポリシーを検索して、IPsec処理を施すのか、IPsec処理を施さないで普通のIPパケットの処理をするのかを判断します。
 
 IPsec処理を施す場合、入力用のSADから該当するSAに関する情報を取り出して、IPsec処理を施し、上位層のプロトコルにデータを渡します。



1.6 IKE

 IPsec通信ではSAという論理的なトンネルを構築しなくてはなりません。SAを構築するためにはさまざまな点での合意が必要です。この合意に関しては予め手動で設定しておくことも可能です。しかし、この手動による合意は大変です。合意事項が多く、一度で合意できない場合の選択肢なども予め決めておかなくてはなりません。通信相手が多かったり、遠隔地であることも少なくありません。また、安全上の理由から、SA構築に使う共通鍵を定期的に交換しなくてはなりません。こう考えると、SAの手動構築は事実上無理です。そこで、IPsecでは自動的にSAの合意ができるようにIKE(Internet Key Exchange)という鍵交換のプロトコルを規定しています。

 鍵交換プロトコルとしてはいろいろの候補がありますが、IPsecが採用したのが、「ISAKMP/Oakley」という鍵交換プロトコルを元にして作られたIKEです。IKEを使うと、ネットワーク上で鍵を安全、かつ自動的に交換することができます。

※ISAKMP/OakleyはISAKMPプロトコル上でOakley鍵交換手順を実装したものです。IKEで使うDiffei-Hellman鍵交換アルゴリズムはOakleyコンポーネントの1つです。

 IKEはUDPポート500番を使って通信されます。Versionが2つあり、IKE ver1はRFC2490、IKE ver2はRFC4306で規定されています。

 SAの合意では様々なパラメータに関する合意をしなくてはなりませんが、この通信が漏れてしまっては、後のIPsec通信が台無しになってしまいます。従って、このIKE通信も秘密にしなくてはならないのですが、まだIPsec通信は確立していませんので、IPsecを使うことは当然できません。そこで、IKE通信自体を暗号化しなくてはなりません。そのために、IKEは2つのフェーズに分けられます。

 第1フェーズはIKEで使用するSAを確立するためのフェーズです。第1フェーズのSA(ISAKMP SA)を確立したら、第2フェーズは、このSAを使ってIPsecで使用するためのSAを確立します。

1.6.1 ISAKMPメッセージのフォーマット


IPパケット
ヘッダ
UDP
ヘッダ
ISAKMP
ヘッダ
ISAKMP
ペイロード


 送信元と宛先のポートは共にUDP500番を使用しています。ISAKMPヘッダには、Cookieやモードが含まれます。ペイロードには、IPsecのSAのパラメータ、鍵計算のパラメータ、自身のID等が含まれます。


1.6.2 ISAKMPヘッダ


開始側Cookie
応答側Cookie
次ペイロード Mj Ver Mn Ver Exchange Type フラグ
メッセージ ID
長さ

● 開始側Cookie:ISAKMP SAの折衝の開始側が生成するCookie値
● 応答側Cookie:ISAKMP SAの折衝の応答側が生成するCookie値
● 次ペイロード:ISAKMPヘッダの次に来るISAKMPペイロードのタイプを示すフィールド

Next Payload Type
None(ペイロードなし) 0
Security Association (SA) 1
Proposal (P) 2
Transform (T) 3
Key Exchange (KE) 4
Identification (ID) 5
Certificate (CERT) 6
Certificate Request (CR) 7
Hash (HASH) 8
Signature (SIG) 9
Nonce (NONCE) 10
Notification (N) 11
Delete (D) 12
Vender ID (VID) 13
RESERVED 14-19
NAT-discovery  20 
NAT-OA (NAT Original Address) 21 
RESERVED  22-127 
Private USE 128-255


● Mj Ver:ISAKMPのメジャーバージョン番号を示すフィールド
● Mn Ver:ISAKMPのマイナーバージョン番号を示すフィールド
● Exchange Type(交換タイプ):使われている交換の種類を示します。これは、ISAKMP交換内でのメッセージとペイロードの順序を指示するものです。

Exchange Type
NONE 0
Base 1
Identity Protection 2
Authentication Only 3
Aggressive 4
Information 5
将来のために確保 6-31
DOI特別使用 32-239
 プライベート使用 240-255


● フラグ:上位5ビットは0。下位3ビットは最下位から順にA(Authentication only Bit)ビット、C(Commit Bit)ビット、E(Encryption Bit)ビットと呼ばれ、メッセージが暗号化されている場合はEビットがセットされています。

ビット 説明
E Eビットがセットされている場合、ヘッダに続くすべてのペイロードはISAKMP SAで特定される暗号アルゴリズムによって暗号化されています。
C Cビットは鍵交換の同期を知らせるために使用されます。SAが確立される前に、暗号化された情報が送られることのないようにします。
A Aビットは通知ペイロードが入ったInformational交換と共に使用されることを目的とし、統合性チェックのための暗号化されていない(例、緊急モード)情報の送信を許します。


● メッセージID:IKEフェーズ2で交換されるメッセージを識別するためのメッセージID
● 長さ:ISAKMPメッセージの長さを示します。


1.6.3 ISAKMPペイロード

 ISAKMPペイロードはタイプがいくつかあります。ISAKMPヘッダの「次ペイロード」フィールドが次に来るISAKMPペイロードのタイプを指定しています。

■ 共通ペイロード
 最初に来るのがペイロードの共通部分です。次に示す共通ペイロードは全てのタイプのペイロードに必ずついています。

次ペイロード    予約        ペイロード長    

・ 次ペイロード:そのメッセージの中の次のペイロードのタイプを示すIDを記述します。それがメッセージの最後のペイロードの場合は"0"となります。このフィールドは、ペイロードをいくつかつなぐ機能を果たすことができます。
 
 ペイロードのタイプとしては、SAペイロード、Proposalペイロード、Transformペイロード、鍵交換ペイロード、IDペイロード、証明書ペイロード、証明書要求ペイロード、ハッシュペイロード、署名ペイロード、Nonceペイロード、通知ペイロード、削除ペイロード、ベンダIDペイロード、などがあります。

■ SAペイロード

次ペイロード    予約        ペイロード長    
DOI

Situation

※DOI=Domain Of Interpretation

■ 鍵交換ペイロード
 鍵交換ペイロードはOakley、Diffie-Hellman等の様々な鍵交換技法をサポートしています。鍵交換ペイロードは次の通りです。

次ペイロード    予約        ペイロード長    

鍵交換データ

■ ペイロードタイプの組み合わせ
 ISAKMPペイロードは、モード(Main、Aggressive、Quickなど)によってペイロードの組み合わせが異なります。例えば、ISAKMPメッセージのMainモードの第1メッセージは以下のペイロードタイプが組み合わされます。

ISAKMP
ヘッダ
SA Proposal Transform Transform

1.6.4 IKEフェーズ1

 第1フェーズでは第1フェーズで使う暗号化鍵を生成するとともに、第2フェーズで使う暗号化のアルゴリズムを決めます。

 第1フェーズのネゴシエーションで決定するパラメータは、ISAKMPメッセージの暗号化に使うアルゴリズム(DES、3DES、AESの何れか)、ISAKMPメッセージの認証、鍵計算に使用するハッシュアルゴリズム(MD5、あるいはSHA-1)、ISAKMPのライフタイプとライフタイム、認証方式(Pre-Shaed-1、デジタル署名、公開鍵暗号、改良型公開鍵暗号)、DHグループです。DHグループは、鍵計算のためのパラメータです。鍵計算には「Diffie-Hellman」鍵交換アルゴリズムを使います。Diffie-Hellmanの方式では通信をするアリスとボブがお互いに公開鍵と秘密鍵のペアを作成し、公開鍵を相手に送ります。アリスとボブは自分の公開鍵と、相手の公開鍵を取り出して、積を計算し、これを共通鍵とする手法です。この方法では、共通鍵をインターネット上に流すことなく、お互いが共通鍵を持つことができます。Diffie-Hellman鍵交換アルゴリズムは離散対数問題という解くのが難しいとされる数学上の性質を利用しています。

 mainモードとaggressiveモードという2つの接続モードがあります。

 mainモードはIPsecゲートウェイとIPsecゲートウェイの間にIPsecトンネルを確立するときによく使われるモードです。主としてIPアドレスが固定されている装置同士でIPsecをするときに使用します。

 mainモードでは、6つのISAKMPメッセージの送受信でフェーズ1を完成させます。第1、第2メッセージでISAKMP SAのパラメータを決定します。第1メッセージでは、開始側(イニシエータ)から、暗号化アルゴリズム、ハッシュアルゴリズム、ライフタイム、認証方式が提案され、応答側(レスポンダ)が各パラメータについて1つ選択し、それを第2メッセージで回答します。

 第3、第4メッセージでは、DHによる鍵交換を行います。開始側から応答側にDH公開鍵とNonce(一時的に生成した乱数)が提示され、応答側から開示側にも同様にDH公開鍵とNonceが提示されます。

 第5、第6のメッセージで、それぞれ開始側からIDの提示、応答側からIDの提示で、それぞれ相手のIPsec機器を認証します。

 これで、ISAKMP SAが生成され、これ以降はIKEのやり取りは暗号化されます。

 aggressiveモードは、IPsec端末とIPsecゲートウェイの間でIPsecトンネルを確立するときによく使われるモードです。主としてIPアドレスが動的に変わる端末(ノートPCやスマホなど)と、IPアドレスが固定されているゲートウェイ同士でIPsecをするときに使用します。ネゴシエーションの際にID情報を隠ぺいせずに生で送信するので、mainモードよりもややセキュリティレベルが低いモードです。自宅パソコン(あるいは主張先のホテル)から自社のVPNサーバにアクセスする場合などにはaggressiveモードを使うことになると思います。

1.6.5 IKEフェーズ2

 Diffie-Hellmanで暗号鍵を共有した後は、第2フェーズに入ります。第2フェーズではIKE通信を暗号化して、IPsec SAによる暗号化通信で必要なパラメータを折衝します。

 フェーズ2で交渉されるパラメータはIPsecで使用するセキュリティプロトコル(AHかESPか)、IPsecで使用する暗号化アルゴリズム(DES、3DES、あるいはAES)、IPsecで使用する認証アルゴリズム(HMAC-MD5、あるいはHMAC-SHA1)、ライフタイム、カプセル化モードです。

 IKEフェーズ2では、フェーズ1で確立したISAKMP SA上でやり取りするので暗号化されています。フェーズ2の交換手順はQuickモードのみが規定されています。Quickモードでは第1、第2、第3のメッセージのやり取りでIPsec SAを確立します。

 第1メッセージで、開始側からセキュリティプロトコル、暗号化アルゴリズム、認証アルゴリズム、ライフタイム、カプセル化モードなどを提示し、応答側が各パラメータについてそれぞれ1つ選択し、第2メッセージで回答します。開始側は、第2メッセージを受信して、それを検証後、第3メッセージでハッシュペイロードを送信し、応答側は受信したハッシュペイロードの認証確認をします。

 IPsec SAが生成されると、これ以降はIPsecによる通信が可能となります。







1.7 AH

 AH(Authentication Header、認証ヘッダ)はパケットが途中で改竄されたり、他者によって偽造されることを防ぐためのプロトコルです。

 AHではMACを使って認証を行います。MACについてはこちらをご覧ください。MACの計算に使う共通鍵はピアとの間で予め交換します。送信側では、メッセージ等からMACを計算し、メッセージと一緒に送ります。受信側では、共通鍵を使ってメッセージ等からMACを計算し、受信したMACと比較して、同じならば通信途中での改ざんはないものと判断します。メッセージからMAC計算をする場合はメッセージそのものに改ざんが加えられていないことを保証します。ヘッダにも変更が加えられていないことを保証したい場合は、ヘッダフィールドの値も計算対象に加えなくてはなりません。


 MAC計算では、通信経路上で変更される可能性があるヘッダフィールドの値は、"0"にセットして計算します。計算対象になるのは、経路上で値が変わらないフィールド、あるいは終点(IPsecの終点)に到達した段階で変化が予測可能なフィールドです。MAC計算から外されたフィールドはたとえ改ざんされても分かりませんが、MAC計算の対象となるフィールドは改ざんされても、それを見破ることができます。

 AHのヘッダフォーマットは次の通りです。

0      7 8      15 16      23 24       31
次ヘッダ ペイロード長 予約
SPI
シーケンス番号
認証情報(ICV)

● 次ヘッダ:次に来るヘッダの種類を表します。
● 認証情報:そのパケットのICV(Integrity Check Value:完全性確認値、MACアルゴリズムによって生成されたコードを短縮したもの)もしくはMACを含む可変長フィールドです。

 MACは通信内容と共通鍵を合わせたものをハッシュ関数で演算した結果です。IPsecではハッシュ関数としてMD(メッセージダイジェスト)が使われます。代表的なものとしてMD5があります。

 トランスポートモードではAHヘッダは次のように追加されます。前にIPsecヘッダの追加のところで説明した通りで、IPsecヘッダの部分がAHヘッダとなるだけです。

IPヘッダ AHヘッダ TCPセグメント

 トンネルモードでは次のようにAHヘッダと新しいIPヘッダが追加されます。

新IPヘッダ AHヘッダ IPパケット

 AHには暗号化の機能はありませんので、盗聴防止には利用できません。RFC1826形式のAHには再送防止機能がありませんが、RFC2402には32ビットの、RFC4302には64ビットの再送防止のためのカウンタがついています(オプション)

1.8 ESP

 ESP(Encapsulated Security Payload)はパケットのデータ部分を暗号化し、経路途中での盗聴から保護するためのプロトコルです。ESPはオプションとして認証サービスを提供することができますので、実際にはIPsecでVPNを構築するにはESPだけが利用されます。

 ESPヘッダフォーマットは次の通りです。

0     7 8     15 16     23 24     31
SPI
シーケンス番号
ペイロード情報
パディング
パッド長 次ヘッダ

ICV
・・・

●ペイロード情報:次ヘッダフィールドで定義されるデータを含む可変長フィールドです。
●パディング:ペイロードデータの長さをアルゴリズムが要求するサイズに調整するためのフィールドです。
●バッド長:パディングの長さを表します。
●次ヘッダ:ESPの後に続くプロトコルのタイプ(TCP、UDP、IP等)を示すフィールドです。

 トランスポートモードでは、ESPヘッダは次のようになります。

IP
ヘッダ
ESP
ヘッダ
TCP
セグメント
ESP
トレーラ
ESP
認証

 IPのペイロード(次の例はTCPセグメント)をESPヘッダとESPトレーラで挟みます。TCPセグメントとESPトレーラが暗号化の対象となります。ESPヘッダは暗号化されません。ESPヘッダを暗号化してしまうと、復号の手掛かりがなくなってしまいますので、暗号化することはできません。

 RFC2406/4303では、選択すれば、認証機能を使うこともできます。認証を選択した場合は、ESPトレーラの次にESP認証情報フィールドが追加されます。認証の対象となるのはESPヘッダからESPトレーラまでです。また、RFC2406/4303にはAHと同様に再送防止の機能がついています。

※AHとESPを併用するとスループットが低下するので好まれません。しかし、認証は必要です。そこで、RFC2403と4303では認証トレーラという簡易認証のオプションを追加しました。日本におけるIPsec-VPNの実装はそのほとんどがAHを使用しない認証付きESPです。


 トンネルモードでのESPヘッダは次のようになります。

新IP
ヘッダ
ESP
ヘッダ
IP
パケット
ESP
トレーラ
ESP
認証


■ RFC1826/1827、RFC2402/2406、RFC4302/4303の互換性
 RFC1826/1827形式のAH/ESPはそれ以降のRFCとヘッダ長が異なるため互換性がありません。

 RFC2402/2406形式は再送防止のために32ビットのカウンタを使用します。これに対して、RFC4302/4303は64ビットのカウンタを使いますが、実際にパケットに追加されるのは、下位の32ビットだけで、見た目はRFC2402/2406形式のパケットと同じです。ただし、認証ベクタ(ICV)の計算には全64ビットが使用されるため、RFC2402/2406形式のIPsecと、RFC4302/4303形式のIPsecには直接的な互換性はありません。RFC4302/4303仕様のIPsec実装で、RFC4302/4303形式のIPsecと通信をするためには、32ビット互換カウンタの仕様を明示で指定しなくてはなりません。





2 SSL/TLS

 Web通信では通常データは暗号化されていませんので、盗聴の危険があります。また、データが通信途中で改竄される心配もあります。更に、Webサーバが思っていた通りのサーバではないかもしれません。サーバとデータのやり取りをしていたら、実は思っていたのとは別のサーバだったということがあるかも知れません。

 盗聴を防ぐには暗号化が必要です。また、データの改ざんを防止するためにはメッセージ認証が必要です。なりすましを防ぐためにも認証が必要となります。Web通信でこれらを実現する方法がSSL(Secure Sockets Layer)です。

※SSLはNetscape Communication社によって開発されましたが、後にIETFによって標準化されTLS(Transport Layer Security)と呼ばれています。SSLとTLSは非常に似ていて、多くの実装が両方をサポートしています。

 通常のWeb通信の場合は、ブラウザのアドレスバーにhttp://URLのように指定しますが、Web通信を暗号化する場合は、https://URLのように指定します。Webサイト上で個人情報やクレジットカード番号を送信する場合に、よく利用されています。

 SSLではクライアントとサーバ間で、公開鍵暗号方式を使って、共通鍵を交換し、この共通鍵を使って、データの暗号化を実現していますので、いわゆるハイブリッド型の暗号方式ということになります。

2.1 SSLの仕組み

 WebクライアントがWebサーバに接続要求すると、Webサーバから証明書が返されますが、証明書を作成する過程は次の通りです。

 認証局は認証局の秘密鍵を使って、Webサーバの公開鍵を暗号化し、これを電子署名として、証明書に添付します。


 証明書の正しさは認証局が保証してくれます。その証が、認証局の電子署名です。


 電子署名はサーバの公開鍵を認証局の秘密鍵で暗号化したものです。従って、認証局の公開鍵で復号できます。認証局の公開鍵は予めクライアントPCにインストールされているはずです。

 認証局の公開鍵で復号できたということは、認証局の秘密鍵で暗号化したということになります。認証局の秘密鍵を使って暗号化できるのは、認証局しかありませんので、この電子署名は認証局が生成したものだということになります。つまり、この電子署名がついている証明書は、認証局がお墨付きを与えてくれた証明書だということになります。

 証明書には電子署名以外に、Webサイトを運営している組織の情報(ドメイン名、IPアドレス、組織名、所在地等)、Webサイトに対してお墨付きを与えている認証局の情報などが書かれています。クライアントは、自分のリスクエスト先の組織と、証明書によって示された組織名が同一であることを確認することができます。これでなりすましがないことを確認できます。

 電子署名を認証局の公開鍵を使って復号し、中から出てきた鍵が、Webサーバの公開鍵です。


 Webクライアントは、共通鍵を用意して、Webサーバの公開鍵で暗号化し、Webサーバに送ります。WebサーバはWebサーバの秘密鍵で復号して、中から共通鍵を取り出します。

 これで、WebクライアントとWebサーバが共通鍵を入手できましたので、以降はこの共通鍵を使って、暗号化通信を行います。


 データが改ざんされていないことは次のようにして確認します。送信者はデータと共有鍵をハッシュ関数に入力して、MAC(ハッシュ値)をメッセージと共に相手に送信します。受信側は、受信データと共通鍵からMAC(ハッシュ値)を計算し、これと相手側から送られてきたMACを比較して、一致したら通信途中で改竄が行われていないものと考えます。


 データを改ざんした上でMACも計算し直すことができるでしょうか?MACを計算するにはデータと共通鍵が必要なので、正しい共通鍵を持つ人にしか正しくMACを計算することはできません。従って、共通鍵を持っていない攻撃者には、正しくMACの計算をすることはできません。

2.2 Webサーバ証明書

 SSLサーバ証明書は信頼のおける認証局(第三者機関)が発行する証明書です。証明書には2つの機能があります。1つは「Webサイト」の所有者の確認機能です。もう一つはデータの暗号化機能です。

 証明書を見るとどんな認証局が発行しているか、認証局が認証しているWebサーバがどんなサーバなのかが分かります。証明書に書かれているWebサーバ名と、自分が今通信しているWebサーバが一致しているかどうかが分かりますので、一応安心できます。

 証明書からはサーバの公開鍵を取り出すことができ、これを使って共通鍵を暗号化して、サーバに送信することが可能です。

2.2.1 ドメイン認証・企業認証

 SSLサーバ証明書は大きく分けてドメイン認証型と企業認証型の2つがあります。

 ドメイン認証型のサーバ証明書はSSL/TLS暗号化に特化したSSLサーバ証明書です。サーバ証明書の発行手続きは簡単で、ドメイン名の所有者名義を確認するだけです。個人でも取得でき、手間もかからず、低価格・短期間で発行できます。ドメイン名さえ持っていれば誰でも発行してもらえますので、Webサイトの運営組織が本当に存在しているかどうか分かりません。パスワードやクレジットカードを詐取しようとする攻撃者が取得する場合もありますので、注意が必要です。

 企業型のSSLサーバ証明書は、Webサイトの運営主体が本当に存在しているかをよく確認して発行されるものです。確認作業は登記事項証明書や、第三者のデータベース等に基づいて電話確認等で行われます。また、企業型証明書は、個人や個人事業主には取得することができません。ドメイン認証型の証明書に比較して格段に信頼性が高くなります。

 企業型証明書よりも更に信頼性が高いのがEV SSL証明書です。EV SSLではWeb運営主体が本当に存在しているかを確認した上で発行されるものです。EV SSLでは、署名権限確認者の在籍確認と、「申請責任者確認書」による確認が別途必要となります。EV SSL証明書は、Webブラウザのアドレスバーが緑色になり、Webサイト運用組織名が表示されます。

2.2.2 証明書の用途

 ドメイン認証型の証明書は、内部Webサイト(イントラネットのサーバ)などに向いています。企業が外部向けのWebサイトを運用する場合には企業型の証明書が向いています。企業のトップページやクレジットカード、ID、パスワードなどを入力するサーバにはEV SSL証明書が最適です。

2.2.3 証明書の有効期間

 認証局が発行するサーバ証明書は、1年~3年といった有効期間が設定されています。有効期限が切れる前に認証局の運営主体から連絡があると思いますので、忘れずに更新してください。サーバ証明書の所有者が秘密鍵を漏えいしてしまったような場合は、有効期限前でも証明書を無効にしなくてはなりません。


3 S/MIME

 電子メールは現在の社会経済活動になくてはならないシステムです。しかし、電子メールにはリスクがあります。電子メールのリスクとは、盗聴、成りすまし、改竄の3つのリスクです。

 電子メールのリスクを回避するためにはどうしたらいいでしょうか。盗聴を防止するためには暗号化が適切です。成りすましを防止する方法は認証です。認証を実現する方法には電子署名という方法がとられます。改ざんのリスクを防止するためには、メッセージ認証という方法が採用されます。これらを全部組み合わせて使う方法がS/MIME(Secure / Multipurpose Internet Mail Extensions)です。S/MIMEは、共通鍵暗号方式、公開鍵暗号方式、メッセージダイジェスト関数と呼ばれる3つの方法を組み合わせたものです。

 共通鍵にはRC2、DES、3DES、公開鍵暗号方式ではRSA、DSA、ECDSAが使われます。

 S/MIMEの概略を次に示します。SSL/TLSとほとんど同じです。次に示すのは、アリスとボブの間の通信を暗号化する場合の例です。

 
 公開鍵暗号方式は難解な数学理論を使っていますので暗号化、復号の処理に時間がかかります。そこで、通常の暗号化には共通鍵暗号方式が使われます。しかし、共通鍵暗号方式では共通鍵を安全に相手に渡す方法がありませんので、公開鍵暗号方式を使って共通鍵を相手に安全に渡します。


 認証は次の通りです。


 メッセージをそのままアリスの秘密鍵で暗号化してもいいのですが、それでは少し長すぎるので、ハッシュ関数を使って一定長のハッシュ値を使います。ハッシュ値をアリスの秘密鍵で暗号化して、これを電子署名として、メッセージに添付します。これで、電子署名付きのメッセージとなります。ボブは電子署名付きのメッセージからメッセージを取り出して、自分でハッシュ計算をして、ハッシュ値を取り出します。また、電子署名をアリスの公開鍵で復号してハッシュ値を取り出します。この2つの値が同じなら、通信途中で改竄は行われていないと判断できます。また、アリスの公開鍵で復号できたということは、もともとアリスの秘密鍵で鍵を掛けたということが分かります。アリスとの秘密鍵を持っているのはアリス以外にはいませんので、鍵を掛けてものはアリス以外には考えられません。ということはメッセージの作成者もアリスだと考えて間違いないはずです。これで、成りすましと、改竄防止ができることになります。

 ここまで述べたことはアリスの公開鍵が本当にアリスのものだという前提です。何らかの理由で、これがイブの公開鍵であるということになると、前提が崩れてしまいます。従って、アリスの公開鍵は絶対にアリスのものであるということが確かでなくてはなりません。これを保証してくれるのが認証局の仕組みです(PKI)。公開鍵の信頼性については、SSL/TLSと同様にPKIを利用しています。

 次に示すのは以上の暗号化、成りすまし防止、改竄防止の仕組みを組み合わせたものです。



 アリスはボブに送るメッセージを共通鍵暗号方式で暗号化します。アリスは、ボブの公開鍵を取り出し、共通鍵を暗号化して、暗号化したメッセージと一緒に送信します。

 ボブは暗号化された共通鍵を、自分の秘密鍵で解錠して取り出し、この共通鍵を使って、メッセージを解錠します。公開鍵暗号方式、メッセージ認証の方式を組み合わせたために、メッセージの暗号化、成りすましの防止、改竄防止を実現しています。

 S/MIMEに対応したメールソフトとして、Outlook Express、Shuriken、Mozilla Thunderbird、秀丸メール、Becky!、Mac Mail、Windowsメール、Windows Liveメールなどがあります。

 これらのメールソフトを使って電子署名や暗号を利用するためには認証機関から公開鍵証明書を入手します。

 商用の認証サービスを提供している会社、あるいは自社内で認証局を運営している場合なら、認証局サービスを提供しているサーバにアクセスして、Webブラウザの中で秘密鍵、公開鍵を作成することができます。作成した秘密鍵はハードディスクに保管しておき、公開鍵は名前とメールアドレスなどと一緒に認証局に送ります。認証局では、規定に沿って本人確認をし、本人確認が済めば、証明書を発行します。

 認証局によっては、電子メールでの証明書発行サービスを行っていますので、このようなサービスを受ける場合は、作成した公開鍵を名前やメールアドレスと一緒にメールに添付して、認証局の送ってください。
 
 認証局に送るデータは次のような形式です。

フォーマットのバージョン
名前や電子メールアドレス
公開鍵情報 公開鍵暗号方式のアルゴリズムの識別子
公開鍵
属性情報 Challenge passwordなど
電子署名アルゴリズムの識別子
属性情報までをあなたの秘密鍵で電子署名したデータ

 申請をうけた認証局は、予め定められた方針に従って本人確認を行い、問題がなければ証明書を発行します。

※上の表の中の「Challenge password」は証明書を破棄するときに必要となるパスワードです。

 証明書はX.509という仕様で決まっています。現在、一般に使われているのはX.509 ver3です。

 他人の証明書を入手する最も簡単な方法は、暗号化メールを送りたい相手に、電子署名したメールを送ってもらうことです。オプションの指定にもよりますが、通常は電子署名には署名者の証明書が添付されています。あなたのメールソフトは証明書を自動的に保管してくれ、あなたが必要な時に使うことができます。

※あなたの方から相手に電子署名付きメールを送信しておいてもいいでしょう。電子署名の中で相手が暗号化する際に使ってほしい証明書と、使ってほしい共通鍵暗号のアルゴリズムを指定しておいてください。

 商用の認証サービスを提供している会社では、同時にディレクトリサービスも提供していますので、そこから探してくることが可能です。探し出したものはアドレス帳などに保存して利用することができます。また、認証局を構築するためのソフトウェアでも、ディレクトリサービスを提供するソフトウェアとセットになっていることも多いようです。

 メールソフトでも、インターネット上のディレクトリから探してきて、アドレス帳に保存できるようになっているものがあります。

 設定が済むとメールソフトのメニューバーから「電子署名」や「暗号化」を選択できるようになります。アイコンができている場合もあると思います。


4 SSH

 Berkeley"r"コマンドと呼ばれるrsh、rloginは、ネットワークに信頼がおける限り、非常に便利なシステムです。Berkeley"r"コマンドはネットワークが信頼に足るものであるという前提で、開発されたものです。しかし、現在はその前提が崩れているといっていいでしょう。

 Berkeley"r"コマンドの場合は、システムが条件としている信頼関係があれば、パスワード無しにネットワーク上の他のシステムにログインできてしまいます。これでは、"r"コマンドは認証が非常に弱いと言わざるを得ません。更に、"r"コマンドでは、データがそのまま通信路を流れてしまいます。Telnetにも同様の問題があります。Telnetではログインパスワードが平文のまま流れてしまいます。

 SSHはTelnet、FTP、rsh、rloginなどの代用として開発されたものです。SSH(Secure Shell)は暗号や認証の技術を使って、安全にリモートのシステムにログインするプロトコルです。


 SSHは、RSAやDSAなどの公開鍵暗号方式を使って共通鍵を暗号化して、鍵交換し、この共通鍵を使って、高速に暗号化通信を行うものです。また、成りすましを防止するための認証の仕組みも充実していて、パスワード認証、公開鍵認証、ワンタイムパスワードなどが利用できます。

 Version1とVersion2が共存していますが(Version1とVersion2は互換性なし)、Version1は脆弱性が発見されていますので、利用は控えた方がいいでしょう。

 OpenSSHはオープンソースで開発されているシステムで、Version1とVersion2の両方をサポートしていますが、デフォルトではVersion2を使います。現在、単にSSHという場合は、通常、OpenSSHのことを指します。


5 VPN

 VPNとは、Vertual Private Networkという意味です。Private Networkとは、自社だけで使用する私的なネットワークという意味で、専門的な用語としては専用線ということになります。Vertualはこの場合は、「のようなもの」というような意味になるでしょうか。つまり、専用線のようなものです。

 「のようなもの」なんて言わないで、専用線が使いたいなら、専用線を使ったらいいじゃないかと思う人もいるかもしれませんね。しかし、専用線は自分だけしか使わないので、コストが非常に高くつきます。その代わり、自分しか使わないので、セキュリティは高くなります。

 企業間のコスト競争が激しい現代では、コストカットできるところはできるだけカットしなくてはなりません。ネットワーク代も例外ではありません。専用線のような高価なものを使っていれば、それが製品価格や、サービス価格に跳ね返って、結局競争力の低下に結びつきます。

 専用線に代わるものとして開発されたのが「専用線のようなもの」で、これがVPNです。専用線のようなものですから、専用線のように安全確実なものでなくてはなりません。しかも、コストを抑えなくてはなりません。

 企業内のネットワークや大学内のネットワークは通常LANと呼ばれます。これは物理的なネットワークとしてはイーサネットを構築し、その上にTCP/IPというインターネットの技術を使って構築したものです。

 TCP/IPに準拠したネットワーク製品は世の中にたくさん、しかも安く出回っています。従って、これらの製品を使って、企業内、大学内のネットワークを構築すると非常に低コストで、しかも使い勝手のいいネットワークを構築することができます。

 企業内、大学内ネットワークはイントラネットとも呼ばれます。内部ネットワークに構築されたインターネットというような意味だと思います。

 企業内ネットワーク、大学内ネットワークがインターネットの技術を使って構築されているなら、それを結びつける技術もインターネットの技術の方が多分親和性がいいでしょうし、コストも抑えられます。ということで、イントラネットと、イントラネットを結びつける技術も、インターネット技術で行おうということになりました。つまり、VPNはインターネットの技術で構築するということになります。

 イントラネット同士を結び付けることはLAN間接続VPNとも言います。ではVPNはLAN間接続のことなのかというと、もう少し広い概念です。VPNにはリモートアクセスVPNという面もあります。リモートアクセスVPNとは外部ネットワークから企業内ネットワークに接続することです。例えば、外出先から、あるいは自宅から企業内ネットワークに接続をするようなことを可能にします。

 VPNを実現する技術には大きく分けるとインターネットVPNとIP-VPNという方法があります。インターネットVPNはインターネットを使ってイントラネットを接続する方法です。IP-VPNは通信事業者が自前で構築しているIP網を使ってイントラネットを接続する技術です。


5.1 インターネットVPN

 インターネットを使ってVPNを構築する方法は、コスト低く抑えることができます。インターネット経由でLAN間接続VPNを構築するには仮想化トンネルを構築します。リモートアクセスVPNではあたかも自宅のPCや出張先で使うノートPCを企業内、大学内のネットワークに直接接続しているように、使うことができます。

 インターネットを使って専用線と同じような、といってもレベル差は当然あるのですが、とにかく専用線と似たような通信状況を作り出す必要があります。専用線はポンントツーポイント(Point-To-Point)ですから、何とかして1対1でつながるようなものを作る必要があります。そのために利用するのがトンネルという考え方です。通信者相互間にトンネルを構築します。もちろん、インターネットは誰でも使えるようなオープンネットワークですから、通常ではこんなことはできません。そこで、「のようなもの」を使います。ここで使うのが、カプセリングという考え方です。IPパケットにあるヘッダを付けて、ある特定の通信者間でしかやり取りできないようにすることです。送信者が誰で、受信者が誰というように認証の機能を付けます。IPパケットはIPアドレスでしか認識できませんが、ここに送信者と受信者を区別する認証機能を追加します。

 このような機能を持つプロトコルは実は既に存在しています。電話回線等を経由して、ISPに接続し、インターネットを使えるようにする技術で、PPP(Point to Point Protocol、通称はピーピーピー))と呼ばれます。PPPは通信相手を認証する機能を持っていますが、送信者と受信者が1対1(Point-To-Point)でつながるような回線でしか使えません。そこで、PPPをIPでカプセリングして、インターネットを介したPPP接続を実現する方法が開発されました。これがPPTP(Point to Point Tunneling Protocol)です。PPTPはPPPの認証機能をIPネットワークでも利用できるように機能拡張したものです。

※PPPは上位層からの各種データグラム(IPパケットなど)をカプセル化して相手に届けることを目的としたプロトコルです。このようなプロトコルとしては当初SLIP(Serial Line IP)と呼ばれるものがありましたが、これは極めて単純なプロトコルで、リンク層レベルでの誤り検出処理ができない、各種上位プロトコルを識別することができない、リンクの制御ができない、ネットワークの制御ができないなどの問題を抱えていました。そこで、これらの問題を解決するプロトコルとして開発されたのがPPPです。

※PPPは現在PAP(Password Authentication Protocol)とCHAP(Challenge Handshake Authentication Protocol)という2種類のユーザ認証プロトコルをサポートしています(RFC 1334)。

※PPPは標準的な通信プロトコルの1つで、2台の機器の間で仮想的な専用の伝送路を確立して、データの送受信ができるようにしたものです。電話回線で発呼や着信ができるようにした方式を「ダイヤル式PPP」と呼び、1990年代に家庭からISP接続する手段として利用されました。また、ADSLや光ファイバーによるデータ通信専用回線による接続ではイーサネットなどの上位層で2地点間接続を確立する技術としても使われ、PPPoE(PPP over Ethernet)などと呼ばれています。

 インターネット上で専用線「のようなもの」を作るためのもう一つのポイントは暗号化です。専用線はポイントツーポイントなので、他の利用者に通信内容を盗み見られる心配はありませんが、インターネット上でこれと同様な状況を作る必要があります。そのための手法が暗号化ということになります。

 PPTPはPPPの機能によって通信のネゴシエイトを行います(通信速度や制御方式等を事前に折衝)が、暗号機能がありません。PPTPでパケットの暗号化を実現しようとすると、MPPE(Microsoft Point to Point Encryption)という暗号化技術と併用しなくてはなりません。

 ここで、暗号化についてはIPsecを使おうという考え方が出てきます。これがL2TP(Layer 2 Tunneling Protocol)という考え方です。L2TPはPPTPを元に開発されたものですが、PPTPと同様にPPPの通信機能を使いますが、パケットの暗号化については「IPsec」を使うというものです。現在、インターネットVPNでは、このIPsecを利用したVPNが最も普及しています。

※Microsoft社が推進していたPPTPとCisco Systems社のL2Fを統合して、IETFが標準化したのがL2TFで、RFC2661で規定されています。

 IPsecを使うためにはクライアントに専用のソフトウェアが必要です。また、クライアントのセキュリティチェック機能がなく、ユーザに応じたアクセス制御も難しいなどの問題点が指摘されています。更に現在一般的に利用されているESPではもともとのIPヘッダを暗号化してしまいますので、NATとの相性が良くありません。

 そこで新しく登場したのがSSL-VPNです。SSL-VPNではサーバ側には機器や新しいソフトが必要ですが、クライアント側はSSLに対応していれば、他に何も必要ありません。SSLに対応したブラウザとメーラがあればそれで十分です。このため簡単に導入できるというメリットがあります。

 ただ、SSL-VPNはあくまでHTTPベースのWebシステムなので、それ以外の通信をするためには、各種のデータや通信を変換しなくてはなりません。

5.2 IP-VPN

 IP-VPNは通信事業者が自前で構築したIP網を使ってVPNを実現する手法です。通信事業者との間でVPNの契約をした人だけが利用できます。誰でも利用できるわけではありませんので、インターネットよりも安全だと期待されています。しかし、暗号化は行われていません。

 現在は一般的にMPLS(Multi Protocol Label Switching)と呼ばれる技術が使われています。MPLSはIP網の中にMPLS網を作り、MPLS網の入り口と出口にラベルの貼り付けと取り外しを行い、MPLS網の中ではラベル情報だけでスイッチングを行うという通信方法です。特定の通信者間では特定のラベルが利用され、他の通信者とは論理的に別な経路が利用されるので、ある程度のセキュリティが用意されると期待されます。また、契約したものしか利用できないので、盗聴者などは排除できると期待されています。

 インターネットVPNと比較して、高速大容量の通信が期待できます。通常のIPルータは、パケットのヘッダ情報によって最短経路を選択するという作業を行う必要がありますが、MPLSルータはそのような必要はありません。パケットヘッダに書かれたラベル情報によって転送処理をするだけす。ルーティングテーブルを検索するのも、MPLSのラベル情報テーブルを確認するのも同じではないかと考える人がいるかもしれませんが、ルーティングテーブルには何十万ものルートのエントリが記述されていますが、MPLSラベルは契約者の数だけですので、検索は素早く終わります。また、ある程度のセキュリティも確保できます。しかし、通信事業者の閉鎖網を使わせてもらうわけですので、コストが高くなるのはやむを得ないところです。また、IP以外のプロトコルは使えませんので、どうしても使おうということになると、カプセル化が必要となります。

 本社と支社間のように頻繁に、しかも大量の通信量がある場合はIP-VPNが向いているかも知れませんが、本社と営業所間、営業所と営業所間、会社(本社、支社、営業所)と社員の自宅などの間はインターネットVPNで十分だと思います。






更新履歴

2016/08/29     作成






























































































ページの先頭