IT管理者のためのIPSec講座技術解説(3/3 ページ)

» 2000年11月27日 00時00分 公開
[河邊 拓,]
前のページへ 1|2|3       

 IPSecの具体的な仕組みを見ていこう。実のところIPSecというのは、暗号化通信を実現する複数のプロトコルの総称である。本稿では、中核をなす以下の3つのプロトコルについて説明する。

  • IKE(Internet Key Exchange)
  • ESP(Encapsulating Security Payload)
  • AH(Authentication Header)

 では、それぞれを順に見ていこう。

鍵交換に使われるプロトコル「IKE」

 IPSecによる暗号化通信は、まず鍵交換を含めたSAの合意をとることから始まる。この合意は、あらかじめ手動で設定しておくことも可能だ。しかし、SAの合意を手動で設定するのは面倒な作業であるだけではなく、通信相手となるコンピュータが遠隔地に設置されていたり、数が多かったりした場合は、手動で設定するのは事実上不可能である。また、暗号化通信の安全性を向上させるため、使用する暗号鍵を定期的に交換することも必要なので、なるべく管理が容易になるように、自動的にSAを交換できるほうが望ましい。そこで、IPSecでは自動でSAの合意をとることが可能な鍵交換プロトコルとして、「IKE(Internet Key Exchange)」を規定している。IKEを使うことで、SAの合意を自動的に行うことが可能になる。

 鍵交換プロトコルとしてはほかにもいくつか存在するが、IPSecでは「ISAKMP/Oakley」という鍵交換プロトコルをもとにして作られた、IKEが標準となっている。前述のとおり、この鍵交換の段階で内容が第三者に漏れるようなことがあっては、以後のIPSecによる暗号化通信は何ら意味をなさなくなる。またIPSecによる暗号化は、鍵交換が終了して初めて有効になるので、IKE自体にIPSecを使うわけにはいかない。そこでIKEはそれ自体で暗号化通信をサポートしている。IKE自体の暗号化通信のためにさらにIKE用の鍵交換手順が定められており、このためIKEは全体で2つの段階から構成されている。まず前半の段階では、後半の段階で利用する暗号化アルゴリズムを決定するとともに、暗号鍵を生成する。このときの鍵生成には「Diffie-Hellman」という方式が利用される。このDiffie-Hellmanという方法は、通信相手同士がお互いに乱数を送り合うと、結果として双方が同じ暗号鍵を生成・共有でき、なおかつ通信経路の盗聴者には、この乱数が分かっても暗号鍵が生成不能という、面白い仕組みを持ったものだ。原理は数学的なものになるので、ここでは説明しない。興味のある方は、暗号に関する専門書に必ず説明されているので、そちらを参照していただきたい。

 Diffie-Hellmanによって暗号鍵が共有できた後は、これを使って後半のフェイズに進み、IKE限定の暗号化通信が可能になる。この段階までくれば、第三者に通信内容を盗聴されても、内容を解読される心配はない。続いて、IPSecによる暗号化通信のためのネゴシエーションを始めることができる。順次、暗号化アルゴリズムの決定、暗号鍵の交換などIPSecによる通信に必要な各種情報がやり取りされ、いよいよデータの暗号化通信が行えるようになる。

データの転送に利用するプロトコル「ESP」

 ネゴシエーションが終了した後、当事者同士で暗号化されたパケットによる通信が開始される。この段階では前述のSPIの値も定まり、あとはSPIをお互いの「合言葉」として暗号化通信が行われる。IPSecではパケットごとに暗号化がなされ、「ESP(Encapsulating Security Payload)」と呼ばれる入れ物にパックされ送信される。ESPは、暗号化された通信内容にSPIとシーケンス番号フィールド、そして認証データという3つの付加情報が付け加えられた構造をとる。

ESPの構造

ESPの中には、暗号化されたデータだけでなく、SPIやシーケンス番号、認証データなどが同梱される。これにより、使用している暗号アルゴリズムや、「完全性の確保」や「認証」などを行う。


 このESPに通常のIPへッダが付け加えられて通信相手に送信される。IPSecでは、暗号化する対象部分によって、「トランスポート・モード」と「トンネル・モード」という2つの方法が提供されている。トランスポート・モードでは、IPパケットで運ぶデータ部分のみを暗号化し、これにあて先などを指定したIPへッダを付けて送信をする。一方、トンネル・モードでは、ほかのホストからいったん受信したIPへッダとデータ部分を合わせたものをまとめて暗号化したうえで、新たにIPへッダを再度つけ直して送信を行う。

トランスポート・モードとトンネル・モード

トンラスポート・モードでは、データを暗号化し、それにIPヘッダを付加して、受信相手に送る。これに対し、トンネル・モードでは、ゲートウェイでIPヘッダを含めて暗号化を行い、それを受信先のゲートウェイが復号化し、IPヘッダをチェックし、本当の受信先に転送する。真の受信先のIPヘッダまでもが暗号化されるため、受信先も隠すことができる。


 では、ESP内の個々の要素についてもう少し詳しく見ていくことにしよう。まずSPIであるが、これは前述のとおりだ。ESPを受信した側ではこの値を見て、復号化のための暗号化アルゴリズムと暗号鍵を選び出す。次のSequence Numberは、文字どおりパケットに付ける通し番号である。これは、悪意を持った第三者が通信内容を傍受して得たパケットを、当事者のふりをして送りつけることで、通信を横取りする「リプレイ攻撃(再送攻撃)」に対抗するためのものだ。送信側はパケットを送信するたびに、このSequence Numberをカウントアップしてゆき、受信側でもこの番号の順序を確認することで、不正なパケットを排除する。

■認証データの役割

 そして最後の認証データは、「完全性の確保」と「認証」の機能を担うものである。この中身は、「MAC(Message Authentication Code)」といわれるデータが入れられる。MACは、通信内容とパスワードを合わせたものに対して、ハッシュ関数と呼ばれる計算方法による演算を施した計算結果である。ハッシュ関数により、任意の大きさのデータから、数十ビットから数百ビットの固定長データが生成される。特にIPSecでは、ハッシュ関数として「メッセージ・ダイジェスト」と呼ばれるものが使われる。メッセージ・ダイジェストは、計算結果から元データを推測できない、どのような元データに対してもそれぞれ違うものであれば同一の計算結果を生じる確率が極めて小さい、という特徴を持っている。メッセージ・ダイジェストの代表的なアルゴリズムとしては、MD5が挙げられる。

 このメッセージ・ダイジェストによるMACで、なぜ「完全性の確保」と「認証」が実現できるかを説明しよう。まず、あるパスワードを通信相手同士でお互いに共有しておく。送信側では送るデータとパスワードを合わせたものをメッセージ・ダイジェストにより処理したのち、結果をESPの中の認証データとしてパケットに付け加える。データが無事に受信側に届いたら、こちらではデータと自分の側でとっておいたパスワードを合わせたものを送信時と同じメッセージ・ダイジェストによって計算をする。得られた結果と受信データを比較して、この2つの間で相違がなければ、データが途中で改ざんされることなく届いていることになる。

メッセージ・ダイジェストによる認証

まず送信側は、あらかじめ交換したパスワードと通信内容から計算されたメッセージ・ダイジェストを送信データに添付して送る。次に 受信側では、受け取った通信内容と交換済みのパスワードとでメッセージ・ダイジェストを計算し、送信データに添付されていたものと比較する。ここで値が同じであらば、通信内容の改ざんはなく、正しい送信者からのデータであったことが確認できる。


 仮に通信の途中経路で第三者がパケットを不正に取得して、中身を書き換えたとしよう。当然この第三者はパスワードを知らない。結果として第三者はデータのみから元の認証データを作ることができない。認証データをそのままにしておいても、自分が改ざんしたデータから作っても、受信側での計算結果とは異なるものになるのだ。このようにして認証データにより、データが元のままであるかどうかといった、「完全性の保証」ができる。また、同時に同じパスワードを共有していない限り、結果として同じ認証データが作れないため、意図した相手からデータが送られたことが確認できるので、「認証」が行える。

 ちなみにIPSecでは、暗号化アルゴリズム同様、使用するメッセージ・ダイジェストのアルゴリズムに関しても、特定のものを強制することなく、ユーザーが自由に選択可能となっている。これもまた鍵交換の段階で相互の交渉によって決定され、SAとして合意したうえでSPIを共有する。

完全性と認証のためのプロトコル「AH」

 「AH(Authentication Header)」は、「完全性の保証」と「認証」のための仕組みである。AHではデータの暗号化は行わず、SPI、シーケンス番号、そして認証データのみをパックして通常のIPパケットの中に加えるようになっている。場所はIPへッダの直後である。SPI、シーケンス番号、認証データの役割はESPの場合とまったく同じである。とするとESPだけでもよいのではないか? という疑問が当然生まれると思うが、これは暗号化通信が使えない(例えば、フランスのように市民の暗号化通信が許可されていないといった場合)というケースのために、最低限「完全性の保証」と「認証」を行うために提供されている。

IPSecの現状

 現在のIPSecの主な用途は、インターネットを使った「VPN(Virtual Private Network)」である。これは従来、専用線により実現されていた企業での本支店間の接続、あるいはLAN間接続といったものをインターネット経由で行おうというものだ。当然、不特定多数に通信内容がさらされることになるため、送信するデータを守る仕組みが必要になる。そこで、ここにIPSecを使用する。すると、利用料金は専用線と比較してはるかに安価でありながら、専用線と同じような通信の秘匿性を実現することができる。現時点で主たるIPSec採用製品もこうしたVPNを対象とするものが多い。製品の形態としては専用の暗号化装置、ルータやファイアウォール製品の付加機能といったものである。こうした製品を各拠点でのインターネットのアクセス回線の入口に設置し、前述のトンネル・モードのIPSecを利用することで、拠点間のすべての通信を暗号化することが可能になる。

 また、最近ではWindows 2000が標準でIPSecをサポートしたこともあり、SOHO同士や家庭とオフィス間での暗号化通信も利用可能になりつつある。今後、インターネットが社会インフラとして定着するにつれ、セキュリティは個人や企業といったユーザーとしての立場を問わず大きな関心事になっていくのは間違いない。IPSecの普及が大いに期待されるところである。

前のページへ 1|2|3       

Copyright© Digital Advantage Corp. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。