(57)【要約】【課題】  ユーザ端末とサービス提供サーバとの間にＮＡＰＴルータが存在する環境において、ＵＤＰヘッダを追加したＩＰｓｅｃトンネルモード形式パケットによる暗号通信を行うことを可能にする。【解決手段】  サービス提供サーバ側の暗号通信モジュールは、サービス提供サーバ側のＮＡＰＴルータに割り当てられたグローバルＩＰアドレス、およびグローバル側で使用する外側ＵＤＰヘッダのポート番号を、認証・鍵交換サーバへ通知する。ユーザ端末側の暗号通信モジュールから暗号パケットを受信した際には、外側ＩＰヘッダの送信元・宛先ＩＰアドレスで内側ＩＰヘッダの送信元・宛先ＩＰアドレスを上書きする。また、内側ＴＣＰ・ＵＤＰヘッダの送信元ポート番号を、外側ＩＰヘッダの送信元ＩＰアドレスが同一の暗号通信の中で、通信セッション毎に一意な値に変更する。ユーザ端末側の暗号通信モジュールに向けてパケットを送信する際には逆のヘッダ変換を行う。【選択図】  図１３
2009111437.tif 000002
【特許請求の範囲】
【請求項１】
それぞれ通信インターフェースを備えた、第一のコンピュータ、第二のコンピュータ、第一のパケット中継装置が、ネットワークを介して接続されたネットワークシステムであって、
前記第一のコンピュータおよび前記第二のコンピュータの通信インターフェースには個別のネットワーク・アドレスが割り当てられており、
前記第一のコンピュータは該第一のコンピュータにおいて動作する第一のソフトウェアを、第二のコンピュータは該第二のコンピュータにおいて動作する第二のソフトウェアを備えており、
前記第一のソフトウェアと、前記第二のソフトウェアは、送信元コンピュータの通信インターフェースを表すネットワーク・アドレス、宛先コンピュータの通信インターフェースを表すネットワーク・アドレス、送信元ソフトウェアを表す識別子、宛先ソフトウェアを表す識別子を含む通信パケットを用いて通信を行い、
さらに、前記第一のコンピュータは第一の暗号化・復号化処理部を備えるか又は該第一の暗号化・復号化処理部と接続されており、前記第二のコンピュータは第二の暗号化・復号化処理部を備えるか又は該第二の暗号化・復号化処理部と接続されており、
前記第一の暗号化・復号化処理部は、前記第一のソフトウェアが前記第二のソフトウェアへ向けて送信した通信パケット全体を暗号化し、該通信パケットの送信元および宛先を表すネットワーク・アドレスおよび識別子を新たに付与し、該通信パケットを中継し、さらに前記第二のソフトウェアが前記第一のソフトウェアへ向けて送信した通信パケットから、送信元および宛先を表すネットワーク・アドレスおよび識別子を除去して残りの部分を復号化し、該通信パケットを中継し、
前記第二の暗号化・復号化処理部は、前記第二のソフトウェアが前記第一のソフトウェアへ向けて送信した通信パケット全体を暗号化し、該通信パケットの送信元および宛先を表すネットワーク・アドレスおよび識別子を新たに付与し、該通信パケットを中継し、さらに前記第一のソフトウェアが前記第二のソフトウェアへ向けて送信した通信パケットから、送信元および宛先を表すネットワーク・アドレスおよび識別子を除去して残りの部分を復号化し、該通信パケットを中継し、
さらに、前記第一のパケット中継装置が備える通信インターフェースにはネットワーク・アドレスが割り当てられており、
前記第一のパケット中継装置は、前記第一のソフトウェアが前記第二のソフトウェアへ向けて送信した通信パケットにおいて、前記第一の暗号化・復号化処理部が新たに付与した該通信パケットの送信元である前記第一のコンピュータの通信インターフェースを表すネットワーク・アドレスおよび前記第一のソフトウェアを表す識別子を、前記第一のパケット中継装置の通信インターフェースのネットワーク・アドレスおよび、前記第一のパケット中継装置が任意に割り当てた識別子に変換し、該通信パケットを中継し、さらに前記第二のソフトウェアが前記第一のパケット中継装置へ向けて送信した通信パケットに対し、前記第二の暗号化・復号化処理部が新たに付与した該通信パケットの宛先である前記第一のパケット中継装置の通信インターフェースのネットワーク・アドレス及び前記任意に割り当てられた識別子を前記第一のコンピュータの通信インターフェースを表すネットワーク・アドレスおよび前記第一のソフトウェアを表す識別子に変換し、該通信パケットを中継し、
さらに、前記第二の暗号化・復号化処理部は、前記第一のソフトウェアが前記第二のソフトウェアへ向けて送信した通信パケットに対し、前記第一の暗号化・復号化処理部で付与され前記第一のパケット中継装置で変換された送信元および宛先を表すネットワーク・アドレスおよび識別子を除去して残りの部分を復号化する際に、復号化後の該通信パケットに含まれる送信元のネットワーク・アドレスを、復号化前の通信パケットに前記第一の暗号化・復号化処理部で付加され前記第一のパケット中継装置で変換されていた送信元ネットワーク・アドレスによって置き換え、該送信元ネットワーク・アドレスが同一の他の通信とは異なる一意な値を新たな識別子として割り当て、復号化後の該通信パケットに含まれる送信元の識別子を前記の新たな識別子によって置き換え、
上記のネットワーク・アドレスおよび識別子の置き換え規則を記憶し、前記第二のソフトウェアが前記第一のソフトウェアに向けて送信する通信パケットの宛先ネットワーク・アドレス及び識別子に対し、前記置き換え規則を逆方向に適用することを特徴とするネットワークシステム。
【請求項２】
請求項１に記載のネットワークシステムであって、
前記第一のパケット中継装置と前記第二のコンピュータとの間に置かれた第二のパケット中継装置を備え、前記第二のパケット中継装置が備える通信インターフェースにはネットワーク・アドレスが割り当てられており、
前記第二のパケット中継装置は、前記第一のソフトウェアが前記第二のソフトウェアへ向けて送信した通信パケットにおいて、該通信パケットの宛先である前記第二のパケット中継装置の通信インターフェースのネットワーク・アドレスおよび、前記第二のパケット中継装置内に予め設定された識別子を、前記第二のコンピュータを表すネットワーク・アドレスおよび前記第二のソフトウェアを表す識別子に変換し、該通信パケットを中継し、前記第二のソフトウェアが前記第一のパケット中継装置へ向けて送信した通信パケットに対し、該通信パケットの送信元を前記第二のパケット中継装置の通信インターフェースのネットワーク・アドレスおよび前記の予め設定された識別子に変換し、該通信パケットを中継し、
さらに、前記第二の暗号化・復号化処理部は、前記第一のソフトウェアが前記第二のソフトウェアへ向けて送信した通信パケットに対し、前記第一の暗号化・復号化処理部で付与され前記第一のパケット中継装置及び前記第二のパケット中継装置で変換された送信元および宛先を表すネットワーク・アドレスおよび識別子を除去して残りの部分を復号化する際に、復号化後の該通信パケットに含まれる宛先のネットワーク・アドレスを、復号化前の通信パケットに前記第一の暗号化・復号化処理部で付加され前記第一のパケット中継装置及び前記第二のパケット中継装置で変換されていた宛先ネットワーク・アドレスによって置き換えることを特徴とするネットワークシステム。
【請求項３】
請求項２に記載のネットワークシステムであって、
さらに前記ネットワークに接続され、前記第一の暗号化・復号化処理部と前記第二の暗号化・復号化処理部が相互の認証および鍵情報の交換を行うために用いる、第三のコンピュータを備え、
前記第二の暗号化・復号化処理部は、前記第三のコンピュータを経由して、前記第一の暗号化・復号化処理部に対し、通信パケットの宛先ネットワーク・アドレスおよび宛先識別子として、前記第二のパケット中継装置の通信インターフェースのネットワーク・アドレスおよび前記の前記第二のパケット中継装置に予め設定された識別子を通知することを特徴とするネットワークシステム。
【請求項４】
請求項１乃至３のいずれかに記載のネットワークシステムであって、
前記第一のパケット中継装置及び第二のパケット中継装置及び第二の暗号化・復号化処理部は該通信パケットに含まれる送信元もしくは宛先のネットワーク・アドレスもしくは識別子を変換又は置き換えた後に、該通信パケットに含まれる、パケットデータの誤り検出コードを適切に再計算することを特徴とするネットワークシステム。
【請求項５】
請求項１乃至３のいずれかに記載のネットワークシステムであって、
前記ネットワーク・アドレスにＩＰ（Internet Protocol）アドレスを、前記識別子にＴＣＰ（Transmission Control Protocol）もしくはＵＤＰ（User Datagram Protocol）のポート番号を用いることを特徴とするネットワークシステム。
【請求項６】
請求項５に記載のネットワークシステムであって、
前記通信パケットの暗号化プロトコルに、ＵＤＰヘッダが付加されたＩＰｓｅｃ（IP Security Protocol）を用いることを特徴とするネットワークシステム。
【請求項７】
請求項５に記載のネットワークシステムであって、
前記第二の暗号化・復号化処理部と、前記第一の暗号化・復号化処理部との間の情報交換を行うためのプロトコルに、ＳＩＰ（Session Initiation Protocol）、もしくはＳＩＰをＴＬＳ（Transport Layer Security）によって暗号化したものを用いることを特徴とするネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントと第一のサーバが、両者から信頼されている第二のサーバを介して鍵情報を交換し、その鍵を用いて暗号化トンネリング通信を行うシステムにおいて、前記クライアントと前記第一のサーバとの間の通信経路上にネットワーク・アドレス変換装置が存在する場合においても通信を可能とする方法に関する。
【背景技術】
【０００２】
インターネットをはじめとするＩＰ（Internet Protocol）ネットワークでは、通信経路上における盗聴等のセキュリティ上の脅威から通信内容を保護し、ホスト間で安全な通信を行う方法として、通信の暗号化が日常的に行われている。暗号通信プロトコルには様々なものがあるが、代表的なものとして、ＯＳＩ（Open Systems Interconnection）参照モデルにおけるネットワーク層の暗号通信プロトコルであるＩＰｓｅｃ（IP Security Protocol）、トランスポート層の暗号通信プロトコルであるＴＬＳ（Transport Layer Security）等を挙げることができる。
【０００３】
一般的に暗号通信では、通信を開始する前に、（１）通信相手の認証、（２）通信データの暗号化および認証に用いる鍵情報を通信相手と共有、の２つのステップが必要である。例えば、ＴＬＳによる暗号通信であれば、（１）は、通信ホストの一方が他方の公開鍵証明書を受信し、自身が持つルート証明書によってその公開鍵証明書が信頼できる認証局によって発行されたことを確認することによって行われる。（２）は、通信ホストの一方が、自ら生成した共通鍵を、他方から受信した公開鍵証明書に含まれる公開鍵を用いて暗号化して送信することによって行われる。双方の通信ホストで共通鍵を共有できれば、これを用いて共通鍵暗号による暗号通信と、ＨＭＡＣ（Keyed-Hashing for Message Authentication Code）による通信データ認証が可能になる。
【０００４】
ＩＰｓｅｃによる暗号通信においては、ＩＫＥ（Internet Key Exchange）と呼ばれる鍵交換プロトコルを用いて（１）および（２）を行うのが一般的である。すなわち、ＩＳＡＫＭＰ（Internet Security Association Key Management Protocol）と呼ばれるプロトコルを用いて（２）を実行するための暗号化通信路の確立と（１）を行い、その暗号化通信路を用いて（２）を行う。
【０００５】
また、特許文献１には、ＩＰｓｅｃによる暗号通信において、双方の通信ホストの認証と鍵交換の仲介を行うサーバ（以降、認証・鍵交換サーバと称す）を用いて（１）および（２）を行う方法が示されている。特許文献１の方法では、ＳＩＰ（Session Initiation Protocol）のＵＡ（User Agent）として動作する双方の通信ホストが、ＴＬＳによって暗号化されたＳＩＰであるＳＩＰＳ（Secure SIP）を用いて、ＳＩＰサーバとして動作する認証・鍵交換サーバへ接続することで、（２）を実行するための暗号化通信路の確立と（１）を行う。（２）の鍵情報の共有は、この暗号化通信路を用いて、認証・鍵交換サーバ経由で行われる。
【０００６】
一方、ユーザが所有する内部ネットワーク（以降では、これをＬＡＮ（Local Area Network）とも称す）をインターネット等の外部ネットワーク（以降では、これをＷＡＮ（Wide Area Network）とも称す）に接続する際には、両者の間でＮＡＰＴ（Network Address Port Translation）と呼ばれる、ＩＰアドレスおよびＴＣＰ（Transmission Control Protocol）・ＵＤＰ（User Datagram Protocol）ポートの変換を行うことが多い。ＮＡＰＴを行うことにより、ＷＡＮ側の一つのＩＰアドレスを、ＬＡＮ側の複数のホストで共有することができる。このため、インターネットにおけるＩＰｖ４（IP Version 4）アドレスの割当数を抑えつつ、多数のユーザホストをインターネットに接続するための有効な手段として、ＮＡＰＴは広く利用されている。
【０００７】
ＮＡＰＴは一般的に、ＬＡＮとＷＡＮとの間の境界に置かれるルータやファイアウォール等の通信装置の一機能として実装されることが多い。以下、ＮＡＰＴ機能を実装した通信装置をまとめて、ＮＡＰＴルータと称する。通常、ＮＡＰＴルータのＷＡＮ側インターフェースには、インターネット全体で通信に利用できるグローバルＩＰアドレスが一つだけ、手動または自動で割り当てられる。ＮＡＰＴルータのＬＡＮ側には、ＬＡＮ内のみでの使用が認められているプライベートＩＰアドレスを使用するのが一般的である。
【０００８】
なお、ＮＡＰＴは、場合によってはＮＡＴ（Network Address Translation）とも呼ばれる。ＮＡＴには狭義の意味と広義の意味があり、狭義にはＴＣＰ・ＵＤＰポートの変換を行わず、ＩＰアドレスの変換のみを行うことを意味する。広義には、ＮＡＰＴおよび狭義のＮＡＴの両方を意味する呼称として用いられるが、ＮＡＰＴの方が狭義のＮＡＴよりも利用場面が多いため、広義のＮＡＴはＮＡＰＴとほぼ等しい意味で用いられている。本稿では、混乱を避けるために、基本的にＮＡＴではなくＮＡＰＴという呼称を用いる。
【０００９】
ＮＡＰＴルータを経由した通信経路においてＩＰｓｅｃによる暗号通信を行おうとした場合、通常のＩＰｓｅｃパケットそのままでは通信できないことが一般に知られている。これには幾つかの原因があるが、ＩＰｓｅｃパケットには暗号化されていないＴＣＰ・ＵＤＰヘッダが付加されていないことがその原因の一つである。すなわち、ＩＰｓｅｃパケットの形式にはトランスポートモード（暗号化する前のＩＰパケットのペイロード部分を暗号化する形式）と、トンネルモード（暗号化する前のＩＰパケット全体を暗号化して新たにＩＰヘッダを付与する形式）の２種類があるが、いずれの形式のパケットにおいてもＴＣＰ・ＵＤＰヘッダ（ＩＰパケットのペイロード部分に含まれる）が暗号化されるため、ＮＡＰＴルータにおけるポート変換が機能せず、結果としてＮＡＰＴルータを越えることができない。
【００１０】
特許文献２には、この問題の回避方法が示されている。特許文献２に示された通信方法では、通信経路上にＮＡＰＴルータが存在するか否かを調べ、存在する場合には、トランスポートモード形式のＩＰｓｅｃパケットを生成する際に、先頭のＩＰヘッダの直後に新たにＵＤＰヘッダを挿入する。トンネルモード形式のＩＰｓｅｃパケットの場合も、特許文献２に示されている方法と同様に、先頭に新たに付加したＩＰヘッダの直後に、新たなＵＤＰヘッダを追加挿入することにより、この問題を回避できる。
【００１１】
【特許文献１】特許第３８５９６６７号公報
【特許文献２】特許第３７９３０８３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
ＩＰｓｅｃによる暗号通信方法においては、ここまでに述べたとおり、通信相手の認証および鍵情報の共有には、ＩＫＥを用いる方法と、特許文献１に示されている認証・鍵交換サーバを用いる方法の２種類がある。ＩＰｓｅｃ暗号通信パケットの形式には、トランスポートモード形式とトンネルモード形式の２種類があり、それぞれにおいてＵＤＰヘッダを追加することが可能である。以降では、認証・鍵交換サーバを用いて通信相手の認証および鍵情報の共有を行い、ＩＰｓｅｃパケットの形式にはＵＤＰヘッダを追加したトンネルモード形式を用いる場合の例について説明する。
【００１３】
上記の前提の下では、ＮＡＰＴルータにおいてＩＰｓｅｃパケットに対するＮＡＰＴは機能するものの、これだけでＮＡＰＴルータを経由したＩＰｓｅｃ通信が可能になるわけではない。ＮＡＰＴルータの設置位置としては、通信の開始を要求する側であるアプリケーションクライアントが動作する通信ホスト（以降はこれをユーザ端末と称する）の側のＬＡＮとＷＡＮとの境界（図１のネットワーク構成におけるＮＡＰＴルータ１３０−Ｃ）、および、上記の通信開始要求を受ける側であるアプリケーションサーバが動作する通信ホスト（以降はこれをサービス提供サーバと称する）の側のＬＡＮとＷＡＮとの境界（図１のネットワーク構成におけるＮＡＰＴルータ１３０−Ｓ）の２箇所が考えられるが、それぞれの位置のＮＡＰＴルータによって以下の問題が生じるため、ＮＡＰＴルータを経由したＩＰｓｅｃ通信を正しく行うことができない。
【００１４】
ユーザ端末側にＮＡＰＴルータが存在する場合、これを経由したＩＰｓｅｃ通信において、次の２つの問題が生じる。
（ア）ユーザ端末は自身のＩＰアドレスをＬＡＮ内のプライベートＩＰアドレス（図１におけるＩＰアドレスＡ）で認識しているため、ＩＰｓｅｃトンネルモード形式パケットの内側ＩＰヘッダのユーザ端末側ＩＰアドレスフィールド（ユーザ端末が送信するパケットの場合、図２１の送信元ＩＰアドレス２１１１）にも、そのプライベートＩＰアドレスがセットされる。この内側ＩＰヘッダは、暗号化された状態でＮＡＰＴルータを通過するため、ＮＡＰＴによるＩＰアドレス変換が行われず、ユーザ端末のプライベートＩＰアドレスが格納されたままサービス提供サーバに届く。しかし、ユーザ端末のプライベートＩＰアドレスは、サービス提供サーバ側のＬＡＮと異なる管理下において割り当てられたＩＰアドレスであるため、サービス提供サーバはそのプライベートＩＰアドレスへの経路を正しく認識できない可能性がある。そればかりか、サービス提供サーバ側ＬＡＮや、他のユーザ端末側ＬＡＮ（パケット送信元のユーザ端末とは異なるＮＡＰＴルータの下に設けられたＬＡＮ）内に存在するホストと、ＩＰアドレスが重複する可能性もある。
（イ）上記（ア）の問題を解決する方法としては、サービス提供サーバにおいて、ＩＰｓｅｃトンネルモード形式パケットの内側ＩＰヘッダに含まれるユーザ端末側ＩＰアドレスを、ユーザ端末側のＮＡＰＴルータに割り当てられたグローバルＩＰアドレスに置き換えて解釈する、という方法が考えられる。この処置により、サービス提供サーバはユーザ端末側ＩＰアドレスへの経路を正しく認識できることに加え、サービス提供サーバ側ＬＡＮや、他のユーザ端末側ＬＡＮ内に存在するホストと、ＩＰアドレスが重複する可能性もなくなる。しかしその一方で、もし、同一のＮＡＰＴルータの下のＬＡＮ内に存在する２つのユーザ端末が、ＩＰｓｅｃトンネルモード形式パケットの内側ＴＣＰ・ＵＤＰヘッダのユーザ端末側ポート番号フィールド（ユーザ端末が送信するパケットの場合、図２１の送信元ポート番号２１２１）に同じポート番号を用いて同一のサービス提供サーバと通信を行った場合、サービス提供者サーバは受信したパケットがどちらのユーザ端末から届いたものか分からなくなってしまう。
【００１５】
また、サービス提供サーバ側にＮＡＰＴルータが存在する場合、これを経由したＩＰｓｅｃ通信において、次の２つの問題が生じる。
（ウ）サービス提供サーバは自身のＩＰアドレスをＬＡＮ内のプライベートＩＰアドレス（図１におけるＩＰアドレスＥ）で認識しているため、認証・鍵交換サーバへの自身のＩＰアドレスの登録や、ユーザ端末への自身のＩＰアドレスの通知の際に、サービス提供サーバ側ＮＡＰＴルータに割り当てられたグローバルＩＰアドレス（図１におけるＩＰアドレスＤ）ではなく、そのプライベートＩＰアドレスを通知してしまう。また、ＩＰｓｅｃトンネルモード形式パケットの外側ＵＤＰヘッダに用いるサービス提供サーバ側ポート番号についても、もし、サービス提供サーバ側ＮＡＰＴルータの変換規則においてＷＡＮ側の値とＬＡＮ側の値（図１におけるＵＤＰポート番号ｄ−ｕｄｐとｅ−ｕｄｐ）が異なる場合は、ＬＡＮ側の値をユーザ端末へ通知してしまう。その結果、ユーザ端末は、これらのプライベートＩＰアドレスやＬＡＮ側ＵＤＰポート番号を、ＩＰｓｅｃトンネルモード形式パケットの外側ヘッダの構築に使用するが、そのパケットはサービス提供サーバに届かない。また、ユーザ端末からサービス提供サーバへの通信開始要求プロトコルにＳＩＰを用いる場合は、通信開始要求メッセージの構築のために、ユーザ端末がサービス提供サーバに対応するＵＲＩ（Uniform Resource Identifier）を知る必要がある。しかし、認証・鍵交換サーバへのサービス提供サーバのＩＰアドレスの登録がプライベートＩＰアドレスで行われていると、特許文献１に示されているＡＯＲ（Address-of-Record）取得メッセージのような方法を用いて、ユーザ端末のアプリケーションが送信した宛先ＩＰアドレス（グローバルＩＰアドレス）を元にＵＲＩを認証・鍵交換サーバへ問い合わせても、望むＵＲＩを得ることはできない。
（エ）仮に（ウ）の問題を解決し、サービス提供サーバのＩＰアドレスおよび外側ＵＤＰヘッダのサービス提供サーバ側ポート番号として、グローバルＩＰアドレス（図１におけるＩＰアドレスＤ）およびＷＡＮ側ポート番号（図１におけるｄ−ｕｄｐ）が、ユーザ端末および認証・鍵交換サーバへ通知されるように変更したとする。この場合、ＩＰｓｅｃトンネルモード形式パケットの内側ＩＰヘッダのサービス提供サーバ側ＩＰアドレスフィールド（ユーザ端末が送信するパケットの場合、図２１の宛先ＩＰアドレス２１１２）にもそのグローバルＩＰアドレスが格納されることになる。しかし、この内側ＩＰヘッダは、暗号化された状態でＮＡＰＴルータを通過するため、ＮＡＰＴによるＩＰアドレス変換が行われず、サービス提供サーバのグローバルＩＰアドレスが格納されたままサービス提供サーバに届く。しかし、サービス提供サーバ自身は、このグローバルＩＰアドレスを自身に割り当てられたＩＰアドレスと認識していないため、サービス提供サーバのＩＰ処理はそのパケット正しく処理できない可能性がある。
【００１６】
本発明は、上記（ア）、（イ）、（ウ）、および（エ）の課題を解決することにより、ユーザ端末とサービス提供サーバとの間の通信経路上にＮＡＰＴルータが存在する環境において、両者ホストが認証・鍵交換サーバを用いた相互認証および鍵情報共有を行い、その鍵情報を用いて、ＵＤＰヘッダを追加したＩＰｓｅｃトンネルモード形式パケットによる暗号通信を両者ホスト間で行うことを可能にすることを目的とする。
【課題を解決するための手段】
【００１７】
本発明の通信方法では、上記（ア）、（イ）、（ウ）、および（エ）の課題を解決するために、以下の（ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）の処理を行う。
（ａ）上記（ウ）の課題を解決するために、サービス提供サーバ内の暗号通信処理には、サービス提供サーバ側ＮＡＰＴルータに割り当てられたグローバルＩＰアドレス、および外側ＵＤＰヘッダのＷＡＮ側ポート番号を、予め登録しておく。この登録は、サービス提供サーバの管理者が手動で行ってもよいし、ＮＡＰＴルータとの間で設定を自動的に同期してもよい。認証・鍵交換サーバやユーザ端末へ、自身のＩＰアドレスや外側ＵＤＰヘッダのポート番号を通知する際には、これらの予め登録されたＩＰアドレスおよびポート番号を用いる。
（ｂ）ユーザ端末からサービス提供サーバへＩＰｓｅｃトンネルモード形式パケットを送信する際の、上記（ア）および（エ）の課題を解決するために、サービス提供サーバ内の暗号通信処理内のカプセル除去処理では、パケットの暗号化された部分（図２２の暗号化パケットデータ２２４０）を復号した後、復号したデータに含まれる内側ＩＰヘッダの送信元ＩＰアドレスフィールド（図２１の送信元ＩＰアドレス２１１１）と宛先ＩＰアドレスフィールド（図２１の宛先ＩＰアドレス２１１２）を、外側ＩＰヘッダの送信元ＩＰアドレスフィールド（図２２の送信元ＩＰアドレス２２１１）と宛先ＩＰアドレスフィールド（図２２の宛先ＩＰアドレス２２１２）の値で上書きする。
（ｃ）ユーザ端末からサービス提供サーバへＩＰｓｅｃトンネルモード形式パケットを送信する際の、上記（イ）の課題を解決するために、サービス提供サーバ内の暗号通信処理内のカプセル除去処理では、パケットの暗号化された部分（図２２の暗号化パケットデータ２２４０）を復号した後、復号したデータに含まれる内側ＴＣＰ・ＵＤＰヘッダの送信元ポート番号フィールド（図２１の送信元ポート番号２１２１）の値を、外側ＩＰヘッダのユーザ端末側ＩＰアドレスが同じ全ての通信について、ＳＰＩ（Security Parameter Index）の値毎に一意となる値に変更する（もし一意な値がまだ割り当てられていなければ、新たに割り当てる）。
（ｄ）サービス提供サーバからユーザ端末へＩＰｓｅｃトンネルモード形式パケットを送信する際の、上記（ア）、（イ）、および（エ）の課題を解決するために、サービス提供サーバ内の暗号通信処理内のカプセル除去処理では、（ｃ）で決定したポート番号を表に記憶する。また、他の外側ヘッダ情報（送信元・宛先ＩＰアドレス、および送信元・宛先ＵＤＰポート番号）、および内側ヘッダ情報（送信元・宛先ＩＰアドレス、プロトコル番号、およびＴＣＰ・ＵＤＰの送信元・宛先ポート番号）についても、ユーザ端末から受信したＩＰｓｅｃトンネルモード形式パケット、もしくは認証・鍵交換サーバ経由でユーザ端末との間で送受信された通信開始要求メッセージから得た情報に基づき、表に記憶する。サービス提供サーバ内の暗号通信処理内のカプセル化処理では、サービス提供サーバ内のアプリケーションからユーザ端末へ送信する内側パケットを受け取ったら、その送信元・宛先ＩＰアドレスを、記憶しておいた表の外側ヘッダ情報の該当欄と、その送信元ポート番号を、記憶しておいた表の内側ヘッダ情報の該当欄と、その宛先ポート番号を、記憶しておいた表の（ｃ）で決定したポート番号の欄と比較する。そして、これらが全て一致したエントリの内側ヘッダ情報を元にパケットの内側ヘッダを書き換え、同エントリの外側ヘッダ情報を元にパケットの外側ヘッダを生成する。
（ｅ）上記（ｂ）、（ｃ）、および（ｄ）の処理を行った結果、パケットのＩＰヘッダおよびＴＣＰ・ＵＤＰヘッダが書き換わる場合は、そのパケットのＩＰヘッダチェックサム、およびＴＣＰ・ＵＤＰパケットチェックサムを適宜再計算し、そのパケットのヘッダ内の該当フィールドに計算結果の値を再設定する。
【発明の効果】
【００１８】
このように、本発明の通信方法を用いることにより、ユーザ端末とサービス提供サーバとの間の通信経路上にＮＡＰＴルータが存在する環境において、両者ホストが認証・鍵交換サーバを用いた相互認証および鍵情報共有を行い、その鍵情報を用いて、ＵＤＰヘッダを追加したＩＰｓｅｃトンネルモード形式パケットによる暗号通信を両者ホスト間で行うことが可能になる。この際、ＮＡＰＴルータはユーザ端末側のみに存在してもよいし、サービス提供サーバ側のみに存在してもよいし、両方に存在してもよい。
【００１９】
また、本発明の通信方法は、サービス提供サーバ側の暗号通信処理には適用する必要があるが、ユーザ端末側の暗号通信処理には適用してもしなくてもよい。このため、本発明を適用したユーザ端末と適用していないユーザ端末が混在する環境においても、いずれのユーザ端末も問題なくＮＡＰＴルータ経由の暗号通信を行うことができる。さらに、暗号通信処理以外の通信装置やソフトウェアには一切の変更が不要である。
【００２０】
加えて、本発明の通信方法は、サービス提供サーバが自身のグローバルＩＰアドレスおよび外側ＵＤＰヘッダのＷＡＮ側ポート番号をＮＡＰＴルータから動的に取得する場合を除き、通信経路上にＮＡＰＴルータが存在するか否かの判定を必要としない。このため、本発明の通信方法の追加による処理アルゴリズムの複雑化を最小限に抑えることができる。
【発明を実施するための最良の形態】
【００２１】
以下、図面を用いて本発明の実施例について説明する。
【実施例１】
【００２２】
図１は、実施例1における、本発明の通信方法を備えた暗号通信モジュールの適用対象となるシステムのネットワーク構成を表す図である。
【００２３】
ユーザ端末１２０−Ｃおよびサービス提供サーバ１２０−Ｓは、それぞれＮＡＰＴルータ１３０−Ｃ、１３０−Ｓを介して、インターネット等の外部ネットワーク１６０に接続される。ユーザ端末１２０−ＣとＮＡＰＴルータ１３０−Ｃとの間のネットワークはユーザ端末側ＬＡＮ、ＮＡＰＴルータ１３０−ＣとＮＡＰＴルータ１３０−Ｓとの間のネットワークはＷＡＮ、ＮＡＰＴルータ１３０−Ｓとサービス提供サーバ１２０−Ｓとの間のネットワークはサービス提供サーバ側ＬＡＮとなる。
【００２４】
ユーザ端末側ＬＡＮおよびサービス提供サーバ側ＬＡＮにおいてはプライベートＩＰアドレスが、ＷＡＮにおいてはグローバルＩＰアドレスが使用されるのが一般的で、本実施例においてもそのように仮定する。ただし、本発明を実施するにあたって、必ずしもそのようなアドレス割当になっていなくともよい。本実施例では、ユーザ端末１２０−ＣにはプライベートＩＰアドレスＡが、ユーザ端末側のＮＡＰＴルータ１３０−ＣのＷＡＮ側インターフェースにはグローバルＩＰアドレスＣが、サービス提供サーバ側のＮＡＰＴルータ１３０−ＳのＷＡＮ側インターフェースにはグローバルＩＰアドレスＤが、サービス提供サーバ１２０−ＳにはプライベートＩＰアドレスＥが割り当てられているものとする。
【００２５】
ユーザ端末側ＬＡＮの内部には、図に示すように、ユーザ端末１２０−Ｃ以外の他のホスト１５０−Ｃが1台以上存在してもよい。また、これらのホストをＬＡＮに接続するためのＨＵＢ  １４０−Ｃや、同様の通信装置（スイッチ、ルータ等）が設置されていてもよい。本発明の実施においては、ＬＡＮ内に設置されたユーザ端末１２０−Ｃが、自身に割り当てられたＩＰアドレスＡを用いて、ＮＡＰＴルータ経由で認証・鍵交換サーバ１７０およびサービス提供サーバ１２０−Ｓと通信できることが要件であり、これが満たされれば、ＬＡＮ内のホスト数やネットワーク構成は問わない。このことは、サービス提供サーバ側ＬＡＮにおいても同様である。
【００２６】
ＮＡＰＴルータ１３０−Ｃおよび１３０−Ｓは、その内部にそれぞれＮＡＰＴ変換表１３１−Ｃ、１３１−Ｓを持ち、これを用いて、ＬＡＮ側とＷＡＮ側との間で中継するＩＰパケットに含まれるＩＰアドレスおよびＴＣＰ・ＵＤＰポート番号を変換する。
【００２７】
外部ネットワーク１６０には、認証・鍵交換サーバ１７０が配置される。本実施例においては、認証・鍵交換サーバ１７０はＳＩＰＳサーバとして実現されるものとする。認証・鍵交換サーバ１７０の内部には、サービス提供サーバのサービスに対応付けられたＵＲＩと、そのＩＰアドレスやポート番号との対応付けを表す、ロケーションデータベース１７１が記憶されている。
【００２８】
サービス提供サーバ１２０−Ｓの内部では、アプリケーションサーバ１１０−Ｓおよび暗号通信モジュール１００−Ｓが動作する。同様に、ユーザ端末１２０−Ｃの内部では、アプリケーションクライアント１１０−Ｃおよび暗号通信モジュール１００−Ｃが動作する。以降では、アプリケーションサーバ１１０−Ｓとアプリケーションクライアント１１０−Ｃを、まとめてアプリケーションと称する。
【００２９】
アプリケーション１１０−Ｃおよび１１０−Ｓは、ユーザ端末１２０−Ｃがサービス提供サーバ１２０−Ｓと通信を行ってサービスを実現するという本来の目的のためのソフトウェアであり、通信相手のホスト（サービス提供サーバ１２０−Ｓに対するユーザ端末１２０−Ｃ、ユーザ端末１２０−Ｃに対するサービス提供サーバ１２０−Ｓ）との間の通信パケットを、暗号通信モジュール１００−Ｃもしくは１００−Ｓとの間で、平文のＩＰパケットのまま送受信する。
【００３０】
暗号通信モジュール１００−Ｃおよび１００−Ｓは、認証・鍵交換サーバ１７０を用いて通信相手のホストを認証し、認証・鍵交換サーバ１７０経由で通信相手のホストと通信開始要求およびその応答を交換し、通信相手のホストとの間で鍵情報を共有する。本実施例においては、暗号通信モジュール１００−ＳはＳＩＰＳクライアントとして動作し、ＴＬＳを用いて暗号化されたＳＩＰプロトコルを用いてこれらの処理を行う。本実施例において、上記の通信開始要求はＳＩＰメッセージの形式をとり、ユーザ端末１２０−Ｃの暗号通信モジュール１００−Ｃを送信元として、認証・鍵交換サーバ１７０経由でサービス提供サーバ１２０−Ｓの暗号通信モジュール１００−Ｓへ送信される。このため、ユーザ端末１２０−ＣをＳＩＰのＵＡＣ（User Agent Client）、サービス提供サーバ１２０−ＳをＳＩＰのＵＡＳ（User Agent Server）と見ることもできる。
【００３１】
また、暗号通信モジュール１００−Ｃおよび１００−Ｓは、上記の処理によって得られた鍵情報を用いて、通信相手のホストから受信したＩＰｓｅｃトンネルモード形式の暗号通信パケットを復号化し、平文のＩＰパケットとしてアプリケーション１１０−Ｃもしくは１１０−Ｓへ中継する。また、アプリケーションサーバ１１０−Ｃもしくは１１０−Ｓから受け取った平文のＩＰパケットを暗号化し、ＩＰｓｅｃトンネルモード形式の暗号通信パケットとして通信相手のホストへ送信する。
なお、ＮＡＰＴルータ１３０−Ｃおよび１３０−Ｓを経由してユーザ端末１２０−Ｃとの間で暗号通信を行うためには、サービス提供サーバ側の暗号通信モジュール１００−Ｓは、本発明の通信方法を備える必要がある。一方、ユーザ端末側の暗号通信モジュール１００−Ｃは、本発明の通信方法を備えても備えなくてもよい。
【００３２】
サービス提供サーバ１２０−Ｓ側の暗号通信モジュール１００−Ｓの内部には、ロケーション情報１０１−Ｓ、ポリシリスト１０２−Ｓ、ＳＰ（Security Policy）表１０３−Ｓ、受信ＳＡ（Security Association）表１０４−Ｓ、送信ＳＡ表１０５−Ｓが記憶される。同様に、ユーザ端末側の暗号通信モジュール１００−Ｃの内部には、ポリシリスト１０２−Ｃ、ＳＰ表１０３−Ｃ、受信ＳＡ表１０４−Ｃ、送信ＳＡ表１０５−Ｃが記憶される。
【００３３】
ロケーション情報１０１−Ｓは、これを保持するサービス提供サーバ１２０−Ｓが、認証・鍵交換サーバ１７０のロケーションデータベース１７１へ登録する情報である。
【００３４】
ポリシリスト１０２−Ｓおよび１０２−Ｃは、暗号通信モジュール１００−Ｓもしくは１００−Ｃが、ネットワークインターフェースやアプリケーションからＩＰパケットを受信した際に、そのパケットに対してカプセル化処理を行うのか、カプセル除去処理を行うのか、何も行わずに通過させるのか、破棄するのかを判断するために用いる表である。
【００３５】
ＳＰ表１０３−Ｓおよび１０３−Ｃは、ＩＰｓｅｃトンネルモード形式パケットに含まれるＳＰＩの値と、それに対応するＩＰｓｅｃトンネルモード形式パケットの外側ＩＰヘッダ、外側ＵＤＰヘッダ、内側ＩＰヘッダ、内側ＴＣＰ・ＵＤＰヘッダ、平文のＩＰパケットのＩＰヘッダ、ＴＣＰ・ＵＤＰヘッダに関する情報の対応付けを表す表である。
受信ＳＡ表１０４−Ｓおよび１０４−Ｃは、受信したＩＰｓｅｃトンネルモード形式パケットに含まれるＳＰＩの値と、それに対応する鍵情報を記憶する表である。
【００３６】
送信ＳＡ表１０５−Ｓおよび１０５−Ｃは、送信するＩＰｓｅｃトンネルモード形式パケットにセットするＳＰＩの値と、それに対応する鍵情報を記憶する表である。
【００３７】
図２は、実施例１における、本発明の通信方法を備えた暗号通信モジュールが動作する、ユーザ端末またはサービス提供サーバの内部処理アーキテクチャを示す図である。
【００３８】
ユーザ端末またはサービス提供サーバ１２０の内部ハードウェアは、ＣＰＵ  ２１０、主記憶装置２２０、ネットワークインターフェース２３０、それらを結合する内部バス２４０により構成される。もちろん、これら以外のハードウェアが含まれていてもよい。
【００３９】
主記憶装置２２０には、ソフトウェア２２１と、ソフトウェアからアクセスされるデータ２２２が格納される。ＣＰＵ  ２１０は、ソフトウェア２２１を読み取り実行する。ネットワークインターフェース２３０は、ユーザ端末またはサービス提供サーバ１２０が設置されたネットワーク（ユーザ端末側またはサービス提供サーバ側のＬＡＮ）に接続される。
【００４０】
ソフトウェア２２１には、アプリケーション１１０、暗号通信モジュール１００、ＯＳ  ３１０、ネットワークインターフェースドライバ３２０が含まれる。もちろん、これら以外のソフトウェアが含まれていてもよい。ＯＳ  ３１０には、ＩＰ・ＴＣＰ・ＵＤＰの送受信処理が含まれ、これら以外にも一般的にはプロセス管理、メモリ管理、入出力ドライバ管理等の処理が含まれる。ネットワークインターフェースドライバ３２０は、ネットワークインターフェース２３０を制御して通信パケットの入出力を行うとともに、通信パケットのレイヤ２処理を行う、一種の入出力ドライバである。なお、本実施例においては、ネットワークインターフェースドライバ３２０とＯＳ  ３１０を別個のソフトウェアとしたが、ネットワークインターフェースドライバ３２０の一部もしくは全ての機能がＯＳ  ３１０に含まれていても構わない。
【００４１】
データ２２２には、暗号通信モジュール１００が使用するデータである、ロケーション情報１０１、ポリシリスト１０２、ＳＰ表１０３、受信ＳＡ表１０４、送信ＳＡ表１０５が含まれる。ただし、ユーザ端末においては、ロケーション情報１０１は含まれなくてもよい。もちろん、これら以外のデータが含まれていてもよい。
【００４２】
図３は、実施例１における、本発明の通信方法を備えた暗号通信モジュールを含む、ユーザ端末またはサービス提供サーバのソフトウェア構成を示す図である。
【００４３】
ＯＳ  ３１０には、ＩＰ処理３１１、ＴＣＰ処理３１２、ＵＤＰ処理３１３、ＴＬＳ処理３１４が含まれる。なお、本実施例においては、これらの処理はＯＳ  ３１０に含まれるものとしたが、同様の機能を実現できるのであれば、ＯＳ  ３１０の外部（ライブラリ等）に置かれていても本発明を実施可能である。
【００４４】
ＩＰ処理３１１は、自ホストを送信元とするＩＰパケットの送信処理や、自ホストを宛先とするＩＰパケットの受信処理を行う。ＩＰパケット送信処理は、上位の処理（ＴＣＰ処理、ＵＤＰ処理、もしくはＩＰを直接用いるアプリケーション）から受け取ったＩＰペイロードに適切なＩＰヘッダを付加し、その宛先ＩＰアドレスに応じた適切なＩＰ通信インターフェース（ＩＰアドレスが割り当てられたネットワークインターフェース）のネットワークインターフェースドライバへＩＰパケットを送出する。ＩＰパケット受信処理は、ＩＰ通信インターフェースのネットワークインターフェースドライバから受信したＩＰパケットが、自ホストに宛てたＩＰパケットか否かを判別し、自ホスト宛であれば、そのパケットのＩＰヘッダに含まれるプロトコル番号に応じた上位の処理へ、そのパケットのＩＰペイロードを渡す。
【００４５】
なお、ＩＰ処理３１１におけるＩＰパケット受信処理では、受信したＩＰパケットのＩＰヘッダに含まれるＩＰヘッダチェックサムが正しい値か否かの判定も行われる（この値が正しくない場合、ＩＰパケットは破棄される）。ＩＰパケット送信処理では、正しいＩＰヘッダチェックサムの値が計算され、送信するＩＰパケットのＩＰヘッダにセットされる。
【００４６】
ＴＣＰ処理３１２は、ＴＣＰプロトコルの送受信終端処理を行う。すなわち、上位の処理（ＴＣＰを用いるアプリケーション）から指定された通信相手との間でＴＣＰコネクションの確立や切断を行う処理、上位の処理から与えられた送信データストリームをセグメントに分割し、ＴＣＰデータパケットを構築してＩＰ処理３１１経由で送出する処理、ＩＰ処理３１１経由で受信したＴＣＰデータパケットをシーケンス番号順に並べなおして受信データストリームを構築し、ＴＣＰヘッダに含まれる宛先ポート番号に対応する上位の処理に渡す処理、通信相手から受信確認パケットが届かないＴＣＰデータパケットを再送する処理等を行う。
【００４７】
なお、ＴＣＰ処理３１２におけるＴＣＰパケット受信処理では、受信したＴＣＰパケットのＴＣＰヘッダに含まれるＴＣＰパケットチェックサムが正しい値か否かの判定も行われる（この値が正しくない場合、ＴＣＰパケットは破棄される）。ＴＣＰパケット送信処理では、正しいＴＣＰパケットチェックサムの値が計算され、送信するＴＣＰパケットのＴＣＰヘッダにセットされる。
【００４８】
ＵＤＰ処理３１３は、ＵＤＰプロトコルの送受信処理を行う。すなわち、上位の処理（ＵＤＰを用いるアプリケーション）から与えられた送信ＵＤＰペイロードに適切なＵＤＰヘッダを付加して、ＩＰ処理３１１経由で送出する処理、ＩＰ処理３１１経由で受信したＵＤＰパケットを、そのＵＤＰヘッダに含まれる宛先ポート番号に対応する上位の処理に渡す処理を行う。
【００４９】
なお、ＵＤＰ処理３１３におけるＵＤＰパケット受信処理では、受信したＵＤＰパケットのＵＤＰヘッダに含まれるＵＤＰパケットチェックサムの値が０で無ければ、その値が正しい値か否かの判定も行われる（この値が正しくない場合、ＵＤＰパケットは破棄される）。ＵＤＰパケット送信処理では、０もしくは正しいＵＤＰパケットチェックサムの値のいずれかが、送信するＵＤＰパケットのＵＤＰヘッダにセットされる。
【００５０】
ＴＬＳ処理３１４は、ＴＬＳによる暗号通信に関する処理を行う。すなわち、上位の処理（ＴＬＳを用いるアプリケーション）から指定された通信相手との間でＴＬＳ暗号通信路の確立や切断を行う処理、上位の処理から与えられた送信平文データストリームを暗号化してＴＣＰ処理３１２経由で送出する処理、ＴＣＰ処理３１２経由で受信した暗号化データストリームを復号化して受信平文データストリームを構築し、適切な上位の処理に渡す処理等を行う。
【００５１】
暗号通信モジュール１００には、カプセル処理適用判定３０１、カプセル除去処理３０２、カプセル化処理３０３、シグナリング処理３０４が含まれる。
カプセル処理適用判定３０１は、ＩＰ処理３１１の、ネットワークインターフェース２３０に対応するＩＰ通信インターフェースと、ネットワークインターフェース２３０に対応するネットワークインターフェースドライバ３２０との間に入り、送受信されるＩＰパケットに対して、カプセル除去処理３０２もしくはカプセル化処理３０３を行うべきか、いずれの処理も行わずにそのままＩＰ処理３１１やネットワークインターフェースドライバ３２０に渡すべきか、どの処理にも渡さずに破棄すべきかを判断する。そして、その判断結果に応じた処理を実行する。
【００５２】
カプセル除去処理３０２は、ＩＰｓｅｃトンネルモード形式パケットの外側ＵＤＰヘッダに用いる自ホスト側ポート番号のＬＡＮ側の値（図１の場合、サービス提供サーバであればポート番号ｅ−ｕｄｐ、ユーザ端末であればポート番号ａ−ｕｄｐ）を宛先ポート番号とするＵＤＰパケットの受信を、ＵＤＰ処理３１３を用いて待ち受ける。そして、該当するＵＤＰパケットを受信したら、そのＵＤＰペイロードをＵＤＰ処理３１３から受け取り、そのパケットの認証値の確認や復号化を行い、取り出した内側の平文ＩＰパケットをＩＰ処理３１１に引き渡す。
【００５３】
カプセル化処理３０３は、カプセル処理適用判定３０１によって暗号化すべきと判断された平文ＩＰパケットをカプセル処理適用判定３０１から受け取り、そのパケットを暗号化して適切なヘッダ等を付加し、ＩＰｓｅｃトンネルモード形式パケットの外側ＵＤＰヘッダに用いる自ホスト側ポート番号のＬＡＮ側の値（図１の場合、サービス提供サーバであればポート番号ｅ−ｕｄｐ、ユーザ端末であればポート番号ａ−ｕｄｐ）を送信元ポート番号とするＵＤＰパケットとして、ＵＤＰ処理３１３経由で送信する。なお、この暗号化処理に必要な暗号通信路確立がまだ行われていない場合は、シグナリング処理３０４に暗号通信の開始を要求し、その結果として暗号通信路が確立された後に、パケットの暗号化および送出を行う。
【００５４】
シグナリング処理３０４は、通信相手のホストとの間でＩＰｓｅｃ暗号通信路の確立や解放を行うための通信（以降ではこの通信をシグナリングと称する）を行う。すなわち、認証・鍵交換サーバ１７０に対するロケーション情報の登録や通信相手を表すＵＲＩの問合せ、認証・鍵交換サーバ１７０を経由した通信相手のホストへの通信開始要求・応答といった、暗号通信路の確立やその前処理に関わる通信を行う。本実施例においては、これらの通信を、ＴＬＳ処理３１４により暗号化したＳＩＰメッセージを用いて行う。
【００５５】
アプリケーション１１０は、ＯＳ  ３１０が用意する標準的な方法により、ＩＰ処理３１１、ＴＣＰ処理３１２、ＵＤＰ処理３１３を介して、ＴＣＰやＵＤＰの通信を通信相手のホストと行う（図１の場合、このときの自ホスト側ポート番号は、サービス提供サーバではｅ、ユーザ端末ではａ）。また、アプリケーション１１０が、通信相手のＵＲＩを予め知っている場合は、これを用いて暗号通信モジュール１００内のシグナリング処理３０４に暗号通信の開始を要求してもよい。
【００５６】
図４は、実施例１におけるロケーション情報を表す図である。
【００５７】
ロケーション情報１０１には、サービスＵＲＩ  ４１０、プロトコル番号４２０、ＵＡＳ側のＩＰアドレス４３０、ＵＡＳ側のポート番号４４０の項目が含まれる。
【００５８】
本実施例においては、これらの項目は、サービス提供サーバの管理者によって手動で設定されることとする。ただし、ＵＡＳ側のＩＰアドレス４３０については、サービス提供サーバ側ＮＡＰＴルータ１３０−ＳからＵＰｎＰ（Universal Plug and Play）等の方法を用いて、自動的に取得してもよい。サービスＵＲＩ  ４１０、プロトコル番号４２０、およびＵＡＳ側のポート番号４４０の項目については、サービス提供サーバで動作するアプリケーションサーバが自動的に設定してもよい。
【００５９】
サービスＵＲＩ  ４１０は、サービス提供サーバが提供するアプリケーションサービスと対応付けられたＳＩＰＳ  ＵＲＩである。
【００６０】
プロトコル番号４２０には、サービス提供サーバが提供するアプリケーションサービスと通信する際に使用するプロトコルの番号が格納される。なお、ここで言うプロトコルとは、ＩＰレイヤのすぐ上位で使用されるプロトコルのことである。プロトコル番号とは、それらのプロトコルに対応付けて、ＩＡＮＡ（Internet Assigned Numbers Authority）のような組織によって割り当てられた番号であり、ＩＰヘッダのプロトコル番号フィールドに格納される。通常のアプリケーションにおいては、ＴＣＰもしくはＵＤＰがプロトコルとして用いられる。
【００６１】
ＵＡＳ側のＩＰアドレス４３０には、サービス提供サーバのＩＰアドレスが格納される。本実施例においては、サービス提供サーバ１２０−Ｓとユーザ端末１２０−Ｃはそれぞれ、外部ネットワーク１６０を挟んで、異なる管理下のプライベートＩＰアドレスが割り当てられたＬＡＮの中に存在するため、互いにプライベートＩＰアドレスを用いて通信することはできない。このため、ＵＡＳ側のＩＰアドレス４３０には、サービス提供サーバ側ＮＡＰＴルータ１３０−ＳのグローバルＩＰアドレス（図１における、ＩＰアドレスＤ）を登録する必要がある。
【００６２】
ＵＡＳ側のポート番号４４０には、サービス提供サーバが提供するアプリケーションサービスがユーザ端末からの通信を待ち受ける、ＴＣＰまたはＵＤＰのポート番号が格納される。
【００６３】
なお、プロトコル番号およびサービス提供サーバ側のアプリケーションポート番号の値によらず、サービス提供サーバ側のＩＰアドレスに対してＵＲＩが一意に決まる場合においては、プロトコル番号４２０およびＵＡＳ側のポート番号４４０の項目を省略しても構わない。
【００６４】
図５は、実施例１におけるポリシリストを表す図である。
【００６５】
ポリシリスト１０２には、プロトコル番号５１０、相手側ＩＰアドレス５２１、相手側ポート番号５２２、自側（グローバル）ポート番号５３２、自側（プライベート）ＩＰアドレス５４１、自側（プライベート）ポート番号５４２、ポリシ５５０の項目が含まれる。
【００６６】
本実施例においては、これらの項目は、該当ホスト（ユーザ端末もしくはサービス提供サーバ）の管理者によって手動で設定されることとする。ただし、後述の通り、プロトコル番号５１０、自側（グローバル）ポート番号５３２、自側（プライベート）ＩＰアドレス５４１、自側（プライベート）ポート番号５４２の項目の一部については、ＮＡＰＴルータと設定を自動的に同期する方法も考えられる。
【００６７】
プロトコル番号５１０には、該当エントリのポリシの適用対象となるＩＰパケットのプロトコル番号が格納される。
【００６８】
相手側ＩＰアドレス５２１には、該当エントリのポリシの適用対象となるＩＰパケットの相手側ＩＰアドレス（送信ＩＰパケットであれば宛先ＩＰアドレス、受信ＩＰパケットであれば送信元ＩＰアドレス）が格納される。
【００６９】
相手側ポート番号５２２には、該当エントリのポリシの適用対象となるＩＰパケットの相手側ＴＣＰ・ＵＤＰポート番号（送信ＩＰパケットであれば宛先ポート番号、受信ＩＰパケットであれば送信元ポート番号）が格納される。
【００７０】
自側（グローバル）ポート番号５３２には、該当エントリのポリシの適用対象となるＩＰパケットが自側のＬＡＮの外部を流れる際に用いる、自側ＴＣＰ・ＵＤＰポート番号（送信ＩＰパケットであれば送信元ポート番号、受信ＩＰパケットであれば宛先ポート番号）が格納される。
【００７１】
自側（プライベート）ＩＰアドレス５４１には、該当エントリのポリシの適用対象となるＩＰパケットが自側のＬＡＮの内部（自ホスト内を含む）を流れる際に用いる、自側ＩＰアドレス（送信ＩＰパケットであれば送信元ＩＰアドレス、受信ＩＰパケットであれば宛先ＩＰアドレス）が格納される。
【００７２】
自側（プライベート）ポート番号５４２には、該当エントリのポリシの適用対象となるＩＰパケットが自側のＬＡＮの内部（自ホスト内を含む）を流れる際に用いる、自側ＴＣＰ・ＵＤＰポート番号（送信ＩＰパケットであれば送信元ポート番号、受信ＩＰパケットであれば宛先ポート番号）が格納される。
【００７３】
ポリシ５５０には、該当エントリによって適用されるポリシが格納される、本実施例においては、ポリシの種別は、「カプセル内側」、「カプセル外側」、「非適用」、「破棄」の４種類である。
【００７４】
本実施例において本発明が機能するためには、ポリシリスト１０２のうち、サービス提供サーバとして機能し、かつ、ポリシが「カプセル外側」のエントリについては、自側（グローバル）ポート番号５３２に適切なポート番号が登録されている必要がある。一般的に、該当エントリのプロトコル番号５１０、自側（グローバル）ポート番号５３２、自側（プライベート）ＩＰアドレス５４１、自側（プライベート）ポート番号５４２は、サービス提供サーバ側ＮＡＰＴルータのＮＡＰＴ変換表１３１−Ｓに静的ＮＡＰＴエントリとして登録されている必要がある（さもなくば、ユーザ端末からサービス提供サーバへ送信されたパケットを、サービス提供サーバは受信することができない）。
【００７５】
このように、サービス提供サーバのポリシリスト１０２−Ｓの一部エントリと、サービス提供サーバ側ＮＡＰＴルータのＮＡＰＴ変換表１３１−Ｓの静的ＮＡＰＴエントリは、互いに設定が同期している必要がある。この同期は、両装置の管理者が手動で行ってもよいし、ＵＰｎＰ等の手段を用いてサービス提供サーバの暗号通信モジュール１００−Ｓがサービス提供サーバ側ＮＡＰＴルータ１３０−Ｓから静的ＮＡＰＴエントリを得ることによって行ってもよいし、サービス提供サーバの暗号通信モジュール１００−Ｓがサービス提供サーバ側ＮＡＰＴルータ１３０−Ｓに対して適切な静的ＮＡＰＴエントリを追加することによって行ってもよい。
【００７６】
なお、ポリシリスト１０２のうち、サービス提供サーバとして機能しないエントリ、および、ポリシが「カプセル内側」のエントリについては、自側（グローバル）ポート番号５３２は空欄でよい。また、ユーザ端末のポリシリスト１０２−Ｃにおいては、自側（グローバル）ポート番号５３２は全て空欄でよい。
【００７７】
図６は、実施例１におけるＳＰ表を表す図である。
【００７８】
ＳＰ表１０３には、外側ヘッダのパラメータ６１０、内側ヘッダのパラメータ６２０、仮想相手側ポート番号６３０、受信ＳＰＩ  ６４０、送信ＳＰＩ  ６５０の項目が含まれる。外側ヘッダのパラメータ６１０には、相手側ＩＰアドレス６１１、相手側ポート番号６１２、自側ＩＰアドレス６１３、自側ポート番号６１４の項目が含まれる。内側ヘッダのパラメータ６２０には、プロトコル番号６２１、相手側ＩＰアドレス６２２、相手側ポート番号６２３、自側ＩＰアドレス６２４、自側ポート番号６２５の項目が含まれる。
【００７９】
ＳＰ表１０３のエントリは、ロケーション情報１０１やポリシリスト１０２の内容、認証・鍵交換サーバ１７０を介して得られた情報、送受信するデータパケットのヘッダに含まれる情報等を元に、自動的に作成される。ＳＰ表１０３の各エントリは、ユーザ端末１２０−Ｃとサービス提供サーバ１２０−Ｓとの間に設けられた、一つ一つの双方向暗号化通信路に対応する。
【００８０】
外側ヘッダのパラメータ６１０の各項目には、ＩＰｓｅｃトンネルモード形式パケットの外側ＩＰヘッダおよび外側ＵＤＰヘッダに用いられる、相手側および自側のＩＰアドレスとポート番号が格納される。これらのＩＰアドレスおよびポート番号は、自ホスト内でＩＰｓｅｃトンネルモード形式パケットを取り扱う際に用いられるものである。すなわち、自側のＩＰアドレスおよびポート番号は、自側ＬＡＮ内で用いられるプライベートなＩＰアドレスおよびポート番号であり、相手側のＩＰアドレスおよびポート番号は、相手側ＬＡＮ外で用いられるグローバルなＩＰアドレスおよびポート番号である。
【００８１】
内側ヘッダのパラメータ６２０の各項目には、ＩＰｓｅｃトンネルモード形式パケットの内側ＩＰヘッダおよび内側ＴＣＰ・ＵＤＰヘッダに用いられる、相手側および自側のＩＰアドレスとポート番号、およびプロトコル番号が格納される。これらのＩＰアドレスおよびポート番号は、暗号化されたＩＰｓｅｃトンネルモード形式パケットの内側ヘッダにおいて用いられるものである。すなわち、ユーザ端末１２０−Ｃにおいては、自側のＩＰアドレスおよびポート番号は、自側ＬＡＮ内で用いられるプライベートなＩＰアドレスおよびポート番号であり、プロトコル番号、相手側のＩＰアドレスおよびポート番号は、ユーザ端末側のアプリケーション１１０−Ｃが認識している、サービス提供サーバ側のアプリケーション１１０−ＳのＩＰアドレスおよびポート番号である。サービス提供者サーバ１２０−Ｓにおいては、ユーザ端末１２０−ＣにおけるＩＰアドレスおよびポート番号の値を、自側と相手側で入れ替えたものとなる。
【００８２】
仮想相手側ポート番号６３０は、外側ヘッダの相手側ＩＰアドレス６１１の項目の値が同じである全エントリの中で一意な値となるように割り当てた、仮想的な相手側のポート番号である。
【００８３】
受信ＳＰＩ  ６４０は、受信パケットで使用されるＳＰＩの値である。ＩＰｓｅｃトンネルモード形式パケットを受信した際には、そのパケットに含まれるＳＰＩが、この受信ＳＰＩ  ６４０の項目の値と一致するエントリを使用して、パケットヘッダのＩＰアドレスやポート番号の書き換えを行う。
【００８４】
送信ＳＰＩ  ６５０は、送信パケットで使用されるＳＰＩの値である。この値については、受信ＳＰＩ  ６４０と異なる値を使用してもよいし、同じ値を使用してもよい。ＩＰｓｅｃトンネルモード形式パケットを送信する際には、この送信ＳＰＩ  ６５０の項目の値がパケットのＳＰＩフィールドにセットされる。
【００８５】
図７は、実施例１における受信ＳＡ表を表す図である。
【００８６】
受信ＳＡ表１０４には、受信ＳＰＩ  ７１０、復号化鍵７２０、認証値確認鍵７３０の項目が含まれる。
【００８７】
受信ＳＡ表１０４のエントリは、ＳＰ表において使用されている受信ＳＰＩの値それぞれについて、自動的に生成される。
【００８８】
受信ＳＰＩ  ７１０は、受信パケットで使用されるＳＰＩの値である。ＩＰｓｅｃトンネルモード形式パケットを受信した際には、そのパケットに含まれるＳＰＩが、この受信ＳＰＩ  ７１０の項目の値と一致するエントリを使用して、パケットの復号化や認証値の確認を行う。
【００８９】
復号化鍵７２０は、受信ＳＰＩに対応する復号化鍵である。
【００９０】
認証値確認鍵７３０は、受信ＳＰＩに対応する認証値確認鍵である。
【００９１】
図８は、実施例１における送信ＳＡ表を表す図である。
【００９２】
送信ＳＡ表１０５には、送信ＳＰＩ  ８１０、暗号化鍵８２０、認証値計算鍵８３０の項目が含まれる。
【００９３】
送信ＳＡ表１０５のエントリは、ＳＰ表において使用されている送信ＳＰＩの値それぞれについて、自動的に生成される。
【００９４】
送信ＳＰＩ  ８１０は、送信パケットで使用されるＳＰＩの値である。ＩＰｓｅｃトンネルモード形式パケットを送信する際には、そのパケットのＳＰＩフィールドにセットしたＳＰＩが、この送信ＳＰＩ  ８１０の項目の値と一致するエントリを使用して、パケットの暗号化や認証値の計算を行う。
【００９５】
暗号化鍵８２０は、送信ＳＰＩに対応する暗号化鍵である。
【００９６】
認証値計算鍵８３０は、送信ＳＰＩに対応する認証値計算鍵である。
【００９７】
なお、本実施例では、受信ＳＰＩと送信ＳＰＩとで別々の値を用いることを可能にするために、受信ＳＡ表１０４と送信ＳＡ表１０５を別々に用意しているが、受信ＳＰＩと送信ＳＰＩに同一の値を用いる場合は、両者の表をまとめて、一つのＳＡ表とすることができる。
【００９８】
さらに、本実施例では、パケットの受信時に用いる復号化鍵と認証値確認鍵、送信時に用いる暗号化鍵と認証値計算鍵をそれぞれ別の項目として用意しているが、受信ＳＰＩと送信ＳＰＩに同一の値を用い、かつ、暗号化に共通鍵暗号を用い、かつ、パケットの送信時と受信時で同じ鍵を用いる場合は、同一ＳＰＩの復号化鍵と暗号化鍵が同じ値となる。同様に、受信ＳＰＩと送信ＳＰＩに同一の値を用い、かつ、認証値の計算および確認にＨＭＡＣのような共通鍵を使用する認証アルゴリズムを用い、かつ、パケットの送信時と受信時で同じ鍵を用いる場合は、同一ＳＰＩの認証値確認鍵と認証値計算鍵が同じ値となる。さらに、暗号化と認証の両方に共通鍵を使用するアルゴリズムを用いる場合は、両者の鍵を同一にしてもよい
このように、ＳＰＩの割り当て、および暗号化や認証に用いる鍵の割り当てについては、使用する暗号化・認証アルゴリズムや、送信と受信でＳＰＩや鍵を使い分けるか否かによって様々な割り当て方法が考えられる。本発明は、ＳＰＩや鍵の割当方法、使用する暗号化・認証アルゴリズムの選択に依らず適用可能である。
【００９９】
図９は、実施例１におけるロケーションデータベースを表す図である。
【０１００】
ロケーションデータベース１７１には、ロケーション情報１０１と同様に、サービスＵＲＩ  ９１０、プロトコル番号９２０、ＵＡＳ側のＩＰアドレス９３０、ＵＡＳ側のポート番号９４０の項目が含まれる。これらの項目は、ロケーション情報１０１に基づいて、サービス提供サーバ１２０−Ｓから認証・鍵交換サーバ１７０に対して通知され、その通知に基づいて各エントリが設定される。
【０１０１】
図１０は、実施例１におけるＮＡＰＴ変換表を表す図である。
【０１０２】
ＮＡＰＴ変換表１３１には、プロトコル番号１０１０、ＬＡＮ側のＩＰアドレス１０２０、ＬＡＮ側のポート番号１０３０、ＷＡＮ側のポート番号１０４０、静的／動的１０５０の項目が含まれる。
【０１０３】
ＮＡＰＴ変換表１３１は、ＮＡＰＴルータにおける、パケット中継の際のＩＰアドレスおよびポート番号の変換規則を表す。すなわち、ＮＡＰＴルータがＷＡＮ側ネットワークから、ＷＡＮ側ネットワークインターフェースに割り当てられたＩＰアドレスを宛先とするＩＰパケットを受信した際には、そのパケットのＩＰヘッダに含まれるプロトコル番号、およびＴＣＰ・ＵＤＰヘッダに含まれる宛先ポート番号が、プロトコル番号１０１０およびＷＡＮ側のポート番号１０４０の値と一致するエントリをＮＡＰＴ変換表１３１から探す。そして、一致するエントリが見つかれば、そのエントリのＬＡＮ側のＩＰアドレス１０２０およびＬＡＮ側のポート番号１０３０の値で、パケットのＩＰヘッダの宛先ＩＰアドレス、およびＴＣＰ・ＵＤＰヘッダの宛先ポート番号の値を書き換え、パケットをＬＡＮ側ネットワークインターフェースへ中継する。一致するエントリが見つからなければ、そのパケットを破棄する。
【０１０４】
逆に、ＮＡＰＴルータがＬＡＮ側ネットワークから、ＷＡＮ側に存在するＩＰアドレスを宛先とするＩＰパケットを受信した際には、そのパケットのＩＰヘッダに含まれるプロトコル番号、送信元ＩＰアドレス、およびＴＣＰ・ＵＤＰヘッダに含まれる送信元ポート番号が、プロトコル番号１０１０、ＬＡＮ側のＩＰアドレス１０２０、およびＬＡＮ側のポート番号１０３０の値と一致するエントリをＮＡＰＴ変換表１３１から探す。そして、一致するエントリが見つかれば、そのエントリのＷＡＮ側のポート番号１０４０の値でパケットのＴＣＰ・ＵＤＰヘッダの送信元ポート番号の値を書き換え、ＷＡＮ側ネットワークインターフェースに割り当てられたＩＰアドレスでパケットのＩＰヘッダの送信元ＩＰアドレスの値を書き換え、パケットをＷＡＮ側ネットワークインターフェースへ中継する。一致するエントリが見つからなければ、他のエントリで使用されていない適当なＷＡＮ側ポート番号を新たに割り当て、これを用いてＮＡＰＴ変換表１３１に新たな動的エントリを生成し、そのエントリに基づいて同様のパケット中継を行う。
【０１０５】
ＮＡＰＴ変換表１３１のエントリには、動的なものと静的なものが存在する。動的なものは、先述の通り、ＬＡＮ側からＷＡＮ側へのパケット中継の際にＮＡＰＴ変換表１３１に該当するエントリが見つからなければ新たに生成される。そして、その通信が終了したとみなされる（ＴＣＰコネクションの終了シーケンスの検出、一定時間の該当パケットの非通過等により判断）と、そのエントリはＮＡＰＴ変換表１３１から削除される。一方、静的なものは、ＮＡＰＴルータの管理者による手動設定、ＵＰｎＰ等を用いた外部からの自動設定等の手段によって登録されるエントリである。一般的に静的なエントリは、改めて該当エントリの削除設定が行われない限り、ＮＡＰＴ変換表１３１から削除されない。本実施例のＮＡＰＴルータ１３０では、ＮＡＰＴ変換表１３１に含まれる静的／動的１０５０の項目を用いて、各エントリが動的エントリか静的エントリかを区別しているが、もちろんこの実現方法に依らずに、本発明は実施可能である。
【０１０６】
図１１は、実施例１において、ＵＡＣ側アプリケーションからのデータパケット送信を契機として、ＵＡＣとＵＡＳとの間に暗号化通信路を確立し、暗号化通信を開始する際の、送受信シーケンス図である。
【０１０７】
なお、本実施例に述べたように暗号通信モジュール１００と認証・鍵交換サーバ１７０との間の通信メッセージにＳＩＰを用いる場合は、図１１と図１２のシーケンス図に示したメッセージの他にも、処理途中であることを返信するメッセージや、応答を受信したことを確認するためのメッセージ等が送受信される。しかし、これらのメッセージは本発明の実施に本質的な影響を与えるものではないため、図１１と図１２のシーケンス図からは省略した。
【０１０８】
まず、サービス提供サーバ（ＵＡＳ）側の暗号通信モジュール１００−Ｓは、自らが持つロケーション情報１０１に基づき、認証・鍵交換サーバ１７０に対してロケーション登録要求メッセージを送信する（ステップ１１１１）。このメッセージはサービス提供サーバ側ＮＡＰＴルータ１３０−Ｓを経由して認証・鍵交換サーバ１７０に届く。認証・鍵交換サーバ１７０は自らのロケーションデータベース１７１に、メッセージに含まれるロケーション情報を登録する。そして、登録が完了したことを表すロケーション登録応答メッセージを、サービス提供サーバ側ＮＡＰＴルータ１３０−Ｓ経由で、サービス提供サーバ側の暗号通信モジュール１００−Ｓへ返信する（ステップ１１１２）。
【０１０９】
次に、ユーザ端末（ＵＡＣ）側のアプリケーション１１０−Ｃは、サービス提供サーバ側のアプリケーション１１０−Ｓに対して、最初のデータパケットの送信を行う（ステップ１１２１）。このときのパケットの宛先となるサービス提供サーバのＩＰアドレスは、ユーザ端末側のアプリケーション１１０−Ｃが予め知っているか、もしくは、サービス提供サーバのＦＱＤＮ（Full Qualified Domain Name）をユーザ端末側のアプリケーション１１０−Ｃが予め知っており、これを元にＤＮＳ（Domain Name System）等を用いてサービス提供サーバのＩＰアドレスを得るものとする。また、パケットのプロトコル番号および宛先ポート番号は、ユーザ端末側のアプリケーション１１０−Ｃが予め知っているものとする。
【０１１０】
なお、ここでデータパケットと称しているのは、ユーザ端末側のアプリケーション１１０−Ｃと、サービス提供サーバ側のアプリケーション１１０−Ｓとの間で行われる通信に関するパケット全般を表しており、アプリケーションが直接用いるデータがパケットに含まれるか否かとは無関係である。例えば、ユーザ端末側のアプリケーション１１０−Ｃとサービス提供サーバ側のアプリケーション１１０−Ｓとの間の通信にＴＣＰが用いられる場合は、そのＴＣＰコネクション確立の初期段階で行われるＴＣＰ  ＳＹＮパケットの送信が、最初のデータパケットの送信となる。
【０１１１】
最初のデータパケットの送信がアプリケーションから行われたことを検知した、ユーザ端末側の暗号通信モジュール１００−Ｃは、そのデータパケットの宛先ＩＰアドレス、プロトコル番号、および宛先ポート番号をもとに、認証・鍵交換サーバ１７０に対してＵＲＩ取得要求メッセージを送信する（ステップ１１３１）。このメッセージはユーザ端末側ＮＡＰＴルータ１３０−Ｃを経由して認証・鍵交換サーバ１７０に届く。認証・鍵交換サーバ１７０は自らのロケーションデータベース１７１を検索して対応するＵＲＩを調べ、そのＵＲＩを含むＵＲＩ取得応答メッセージを、ユーザ端末側ＮＡＰＴルータ１３０−Ｃ経由で、ユーザ端末側の暗号通信モジュール１００−Ｃへ返信する（ステップ１１３２）。
【０１１２】
続いて、ユーザ端末側の暗号通信モジュール１００−Ｃは、認証・鍵交換サーバ１７０に対して、取得したＵＲＩや鍵情報等を含む通信開始要求メッセージを送信する（ステップ１１４１）。このメッセージはユーザ端末側ＮＡＰＴルータ１３０−Ｃを経由して認証・鍵交換サーバ１７０に届く。認証・鍵交換サーバ１７０は、メッセージに含まれるＵＲＩに基づいてメッセージの転送先を決定し、そのメッセージをサービス提供サーバ側ＮＡＰＴルータ１３０−Ｓを経由してサービス提供サーバ側の暗号通信モジュール１００−Ｓへ転送する。このメッセージを受信したサービス提供サーバ側の暗号通信モジュール１００−Ｓは、対応する鍵情報等を含む通信開始応答メッセージを、サービス提供サーバ側ＮＡＰＴルータ１３０−Ｓを経由して認証・鍵交換サーバ１７０へ返信する。このメッセージを受信した認証・鍵交換サーバ１７０は、そのメッセージをユーザ端末側ＮＡＰＴルータ１３０−Ｃ経由で、ユーザ端末側の暗号通信モジュール１００−Ｃへ返信する（ステップ１１４２）。
【０１１３】
以上の処理により、ユーザ端末側の暗号通信モジュール１００−Ｃと、サービス提供サーバ側の暗号通信モジュール１００−Ｓとの間で、ＩＰｓｅｃによる暗号通信に必要な鍵情報等のパラメータを共有できたので、ユーザ端末側の暗号通信モジュール１００−Ｃは、ステップ１１２１においてユーザ端末側アプリケーション１１０−Ｃから受信した最初のデータパケットを暗号化し、ユーザ端末側ＮＡＰＴルータ１３０−Ｃおよびサービス提供サーバ側ＮＡＰＴルータ１３０−Ｓを経由して、サービス提供サーバ側の暗号通信モジュール１００−Ｓへ送信する。サービス提供サーバ側の暗号通信モジュール１００−Ｓは、これを複合化して平文のＩＰパケットに戻し、サービス提供サーバ側のアプリケーション１１０−Ｓへ引き渡す（ステップ１１５１）。
【０１１４】
以上の処理により、以降はユーザ端末側のアプリケーション１１０−Ｃと、サービス提供サーバ側のアプリケーション１１０−Ｓとの間で、ＩＰｓｅｃによる暗号通信が可能になる（ステップ１１６０）。
【０１１５】
図１２は、実施例１において、ＵＡＣ側アプリケーションから暗号通信モジュールへの通信開始要求を契機として、ＵＡＣとＵＡＳとの間に暗号化通信路を確立し、暗号化通信を開始する際の、送受信シーケンス図である。
【０１１６】
まず、サービス提供サーバ側の暗号通信モジュール１００−Ｓは、図１１のステップ１１１１と同様の手順で、ロケーション登録要求メッセージを認証・鍵交換サーバ１７０へ送信する（ステップ１２１１）。これを受信した認証・鍵交換サーバ１７０は、図１１の場合と同様の処理を行い、図１１のステップ１１１２と同様の手順で、ロケーション登録応答メッセージをサービス提供サーバ側の暗号通信モジュール１００−Ｓへ返信する（ステップ１２１２）。
【０１１７】
次に、ユーザ端末側のアプリケーション１１０−Ｃは、自らが持つサービス提供サーバが提供するサービスを表すＵＲＩを用いて、ユーザ端末側の暗号通信モジュール１００−Ｃに対して暗号通信の開始を要求する（ステップ１２２１）。これを受けたユーザ端末側の暗号通信モジュール１００−Ｃは、認証・鍵交換サーバ１７０に対して、ＵＲＩや鍵情報等を含む通信開始要求メッセージを送信する（ステップ１２２２）。このメッセージは図１１のステップ１１４１と同様の手順で、最終的にサービス提供サーバ側の暗号通信モジュール１００−Ｓに届く。これを受信したサービス提供サーバ側の暗号通信モジュール１００−Ｓは、対応する鍵情報等を含む通信開始応答メッセージを、認証・鍵交換サーバ１７０へ返信する（ステップ１２２３）。このメッセージは図１１のステップ１１４２と同様の手順で、ユーザ端末側の暗号通信モジュール１００−Ｃへ届く。これを受信したユーザ端末側の暗号通信モジュール１００−Ｃは、通信開始要求に対する応答を受信し、暗号化通信路の確立が完了したことを、ユーザ端末側のアプリケーション１１０−Ｃに通知する（ステップ１２２４）。
【０１１８】
続いて、ユーザ端末側のアプリケーション１１０−Ｃは、確立されたＩＰｓｅｃ暗号化通信路を用いて、サービス提供サーバ側のアプリケーション１１０−Ｓへ向けて最初のデータパケットの送信を行う（ステップ１２３１）。このデータパケット送信は、図１１のステップ１１２１およびステップ１１５１と同様の手順で行われ、最終的にデータパケットがサービス提供サーバ側のアプリケーション１１０−Ｓに届く。
【０１１９】
以上の処理により、以降はユーザ端末側のアプリケーション１１０−Ｃと、サービス提供サーバ側のアプリケーション１１０−Ｓとの間で、ＩＰｓｅｃによる暗号通信が可能になる（ステップ１２４０）。
【０１２０】
図１３は、実施例１において、ＵＡＣとＵＡＳとの間の暗号化通信路を確立した後に、その暗号化通信路を用いてＵＡＣ側アプリケーションからＵＡＳ側アプリケーションへデータパケットを送信する際の、送受信シーケンス図である。
【０１２１】
図１１の最初のデータパケット送信・中継（ステップ１１２１、１１５１）、図１２の最初のデータパケット送信（ステップ１２３１）、図１１および図１２のアプリケーションデータ通信（ステップ１１６０、１２４０）のうちでユーザ端末からサービス提供サーバへ向かうもののいずれもが、この図１３のシーケンス図に従って行われる。
【０１２２】
まず、ユーザ端末側のアプリケーション１１０−Ｃは、サービス提供サーバ側のアプリケーション１１０−Ｓに向けて、暗号化されていないＩＰパケットの形式でデータパケットを送信する（ステップ１３１１）。このときのパケットのＩＰヘッダの送信元ＩＰアドレスはユーザ端末１２０−Ｃに割り当てられたプライベートＩＰアドレス（ここでは図１のＩＰアドレスＡ）、宛先ＩＰアドレスはサービス提供サーバ側ＮＡＰＴルータに割り当てられたグローバルＩＰアドレス（ここでは図１のＩＰアドレスＤ）、プロトコル番号はアプリケーションプロトコルに従った値（ここではＴＣＰ）である。また、このときのパケットのＴＣＰ・ＵＤＰヘッダ（ここではＴＣＰヘッダ）の送信元ポート番号および宛先ポート番号は、いずれもユーザ端末側のアプリケーション１１０−Ｃが認識しているポート番号（ここではそれぞれ、図１のポート番号ａ、ｅ）である。
【０１２３】
次に、ユーザ端末側の暗号通信モジュール１００−Ｃは、この暗号化されていないＩＰパケットを受け取り、暗号化を施してＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットを構成し、ユーザ端末１２０−Ｃのネットワークインターフェースから送出する（ステップ１３１２）。このときのパケットの外側ＩＰヘッダの送信元ＩＰアドレスおよび宛先ＩＰアドレスは、元になった暗号化されていないＩＰパケットの送信元ＩＰアドレスおよび宛先ＩＰアドレスと同じである（ここではそれぞれＩＰアドレスＡ、Ｄ）。また、このときのパケットの外側ＵＤＰヘッダの送信元ポート番号は、ユーザ端末側の暗号通信モジュール１００−Ｃが自側のポート番号として認識している番号（ここでは図１のポート番号ａ−ｕｄｐ）、宛先ポート番号は、ユーザ端末側の暗号通信モジュール１００−Ｃがサービス提供サーバ側の暗号通信モジュール１００−Ｃから認証・鍵交換サーバ１７０経由で通知された、サービス提供サーバ側の暗号通信モジュール１００−Ｃのポート番号（ここではポート番号ｄ−ｕｄｐ）である。内側のＩＰパケットは、ＩＰヘッダおよびＴＣＰ・ＵＤＰヘッダも含め、ステップ１３１１のときの暗号化されていないＩＰパケットと全く同じものを暗号化しただけである。
【０１２４】
次に、ユーザ端末側のＮＡＰＴルータ１３０−Ｃは、この暗号化されたＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットをＬＡＮ側インターフェースから受信し、外側ＩＰヘッダの送信元ＩＰアドレスおよび外側ＵＤＰヘッダの送信元ポート番号を書き換え、ＷＡＮ側インターフェースから送信する（ステップ１３１３）。このとき、パケットの外側ＩＰヘッダの送信元ＩＰアドレスは、ユーザ端末側のＮＡＰＴルータ１３０−ＣのＷＡＮ側インターフェースに割り当てられたグローバルＩＰアドレス（ここでは図１のＩＰアドレスＣ）に、外側ＵＤＰヘッダの送信元ポート番号は、ユーザ端末側のＮＡＰＴルータ１３０−Ｃが適当に割り当てたポート番号（ここではポート番号ｘ−ｕｄｐ）に書き変わる。
【０１２５】
次に、サービス提供サーバ側のＮＡＰＴルータ１３０−Ｓは、この暗号化されたＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットをＷＡＮ側インターフェースから受信し、外側ＩＰヘッダの宛先ＩＰアドレスおよび外側ＵＤＰヘッダの宛先ポート番号を書き換え、ＬＡＮ側インターフェースから送信する（ステップ１３１４）。このとき、パケットの外側ＩＰヘッダの宛先ＩＰアドレスは、サービス提供サーバ１２０−Ｓに割り当てられたプライベートＩＰアドレス（ここでは図１のＩＰアドレスＥ）に、外側ＵＤＰヘッダの宛先ポート番号は、サービス提供サーバ側の暗号通信モジュール１００−Ｓが自側のポート番号として認識している番号（ここでは図１のポート番号ｅ−ｕｄｐ）に書き変わる。なお、この書き換えは、サービス提供サーバ側のＮＡＰＴルータ１３０−Ｓに予め設定された静的ＮＡＰＴ変換規則に基づいて行われる。
【０１２６】
最後に、サービス提供サーバ側の暗号通信モジュール１００−Ｓは、この暗号化されたＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットをサービス提供サーバ１２０−Ｓのネットワークインターフェースから受信し、内側のＩＰパケットを復号化して元の暗号化されていないＩＰパケットを取り出し、パケットのＩＰヘッダの送信元ＩＰアドレス、宛先ＩＰアドレス、およびＴＣＰ・ＵＤＰヘッダの送信元ポート番号を書き換え、サービス提供サーバ側アプリケーション１１０−Ｓに引き渡す（ステップ１３１５）。このとき、パケットのＩＰヘッダの送信元ＩＰアドレスおよび宛先ＩＰアドレスには、元のＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットの外側ＩＰヘッダの値を用いる。また、パケットのＴＣＰ・ＵＤＰヘッダの送信元ポート番号には、サービス提供サーバ側の暗号通信モジュール１００−Ｓが、ＳＰ表において外側ヘッダの相手側ＩＰアドレスが同一のエントリの中で一意な値になるように適当に割り当てたポート番号の値（ここではポート番号ｕｎｉｑ−ａ）を用いる。
【０１２７】
図１４は、実施例１において、ＵＡＣとＵＡＳとの間の暗号化通信路を確立した後に、その暗号化通信路を用いてＵＡＳ側アプリケーションからＵＡＣ側アプリケーションへデータパケットを送信する際の、送受信シーケンス図である。
【０１２８】
図１１および図１２のアプリケーションデータ通信（ステップ１１６０、１２４０）のうちでサービス提供サーバからユーザ端末へ向かうものが、この図１４のシーケンス図に従って行われる。
【０１２９】
まず、サービス提供サーバ側のアプリケーション１１０−Ｓは、ユーザ端末側のアプリケーション１１０−Ｃに向けて、暗号化されていないＩＰパケットの形式でデータパケットを送信する（ステップ１４１１）。このときのパケットのＩＰヘッダの送信元ＩＰアドレスはサービス提供サーバ１２０−Ｓに割り当てられたプライベートＩＰアドレス（ここでは図１のＩＰアドレスＥ）、宛先ＩＰアドレスはユーザ端末側ＮＡＰＴルータに割り当てられたグローバルＩＰアドレス（ここでは図１のＩＰアドレスＣ）、プロトコル番号はアプリケーションプロトコルに従った値（ここではＴＣＰ）である。また、このときのパケットのＴＣＰ・ＵＤＰヘッダ（ここではＴＣＰヘッダ）の送信元ポート番号は、サービス提供サーバ側のアプリケーション１１０−Ｓが認識しているポート番号（ここではポート番号ｅ）である。宛先ポート番号は、サービス提供サーバ側のアプリケーション１１０−Ｓが最初にユーザ端末側のアプリケーション１１０−Ｃから届いたデータパケットを受信した際（図１３のステップ１３１５）に知った、ユーザ端末側のアプリケーション１１０−Ｃのポート番号（ここではポート番号ｕｎｉｑ−ａ）である。
【０１３０】
次に、サービス提供サーバ側の暗号通信モジュール１００−Ｓは、この暗号化されていないＩＰパケットを受け取り、内側のＩＰパケットのＩＰヘッダおよびＴＣＰ・ＵＤＰヘッダを後述の通り書き換え、暗号化を施してＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットを構成し、サービス提供サーバ１２０−Ｓのネットワークインターフェースから送出する（ステップ１４１２）。このときのパケットの外側ＩＰヘッダの送信元ＩＰアドレスおよび宛先ＩＰアドレスは、元になった暗号化されていないＩＰパケットの送信元ＩＰアドレスおよび宛先ＩＰアドレスと同じである（ここではそれぞれＩＰアドレスＥ、Ｃ）。また、このときのパケットの外側ＵＤＰヘッダの送信元ポート番号は、サービス提供サーバ側の暗号通信モジュール１００−Ｓが自側のポート番号として認識している番号（ここでは図１のポート番号ｅ−ｕｄｐ）、宛先ポート番号は、サービス提供サーバ側の暗号通信モジュール１００−Ｓが最初にユーザ端末側の暗号通信モジュール１００−Ｃから届いたデータパケットを受信した際（図１３のステップ１３１４）に知った、ユーザ端末側の暗号通信モジュール１００−Ｃのポート番号（ここではポート番号ｘ−ｕｄｐ）である。また、内側のＩＰパケットのＩＰヘッダの送信元ＩＰアドレスと宛先ＩＰアドレス、およびＴＣＰ・ＵＤＰヘッダの宛先ポート番号には、サービス提供サーバ側の暗号通信モジュール１００−Ｓがユーザ端末側の暗号通信モジュール１００−Ｃから届いたデータパケットを受信した際（図１３のステップ１３１４）の、内側のＩＰパケットのＩＰヘッダの宛先ＩＰアドレスと送信元ＩＰアドレス、およびＴＣＰ・ＵＤＰヘッダの送信元ポート番号と同じ値（ここではそれぞれ、ＩＰアドレスＤ、ＩＰアドレスＡ、ポート番号ａ）がそれぞれセットされる。
【０１３１】
次に、サービス提供サーバ側のＮＡＰＴルータ１３０−Ｓは、この暗号化されたＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットをＬＡＮ側インターフェースから受信し、外側ＩＰヘッダの送信元ＩＰアドレスおよび外側ＵＤＰヘッダの送信元ポート番号を書き換え、ＷＡＮ側インターフェースから送信する（ステップ１４１３）。このとき、パケットの外側ＩＰヘッダの送信元ＩＰアドレスは、サービス提供サーバ側のＮＡＰＴルータ１３０−ＳのＷＡＮ側インターフェースに割り当てられたグローバルＩＰアドレス（ここでは図１のＩＰアドレスＤ）に、外側ＵＤＰヘッダの送信元ポート番号は、サービス提供サーバ側のＮＡＰＴルータ１３０−Ｓに予め設定された静的ＮＡＰＴ変換規則に基づいたポート番号（ここではポート番号ｄ−ｕｄｐ）に書き変わる。
【０１３２】
次に、ユーザ端末側のＮＡＰＴルータ１３０−Ｃは、この暗号化されたＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットをＷＡＮ側インターフェースから受信し、外側ＩＰヘッダの宛先ＩＰアドレスおよび外側ＵＤＰヘッダの宛先ポート番号を書き換え、ＬＡＮ側インターフェースから送信する（ステップ１４１４）。このとき、パケットの外側ＩＰヘッダの宛先ＩＰアドレスは、ユーザ端末１２０−Ｃに割り当てられたプライベートＩＰアドレス（ここでは図１のＩＰアドレスＡ）に、外側ＵＤＰヘッダの宛先ポート番号は、ユーザ端末側の暗号通信モジュール１００−Ｃが自側のポート番号として認識している番号（ここでは図１のポート番号ａ−ｕｄｐ）に書き変わる。なお、この書き換えは、ユーザ端末側のＮＡＰＴルータ１３０−Ｃがユーザ端末側の暗号通信モジュール１００−Ｃから届いたデータパケットを受信した際（図１３のステップ１３１２）に生成された、動的ＮＡＰＴ変換規則に基づいて行われる。
【０１３３】
最後に、ユーザ端末側の暗号通信モジュール１００−Ｃは、この暗号化されたＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットをユーザ端末１２０−Ｃのネットワークインターフェースから受信し、内側のＩＰパケットを復号化して元の暗号化されていないＩＰパケットを取り出し、ユーザ端末側アプリケーション１１０−Ｃに引き渡す（ステップ１４１５）。このとき、復号化した内側のＩＰパケットに対しては、ＩＰヘッダやＴＣＰ・ＵＤＰヘッダの書き換えを一切行わず、そのままの形でユーザ端末側アプリケーション１１０−Ｃに引き渡す。
【０１３４】
図１５は、実施例１におけるロケーション登録要求メッセージのデータ構造を表す図である。
【０１３５】
本実施例において、ロケーション登録要求メッセージは、ＴＬＳによる暗号化を行ったＳＩＰメッセージとして実現される。ただし、ＴＬＳやＳＩＰを用いなくても、同等の内容のデータを含むメッセージを暗号通信モジュール１００と認証・鍵交換サーバ１７０との間で送受信できれば、本発明を実施することは可能である。このことは、以降の図１６から図２０までにおいても同様である。
【０１３６】
ロケーション登録要求メッセージは、ＩＰヘッダ１５１０、ＴＣＰヘッダ１５２０、暗号化データ１５３０で構成される。ただし、この図では一つのメッセージが一つのＩＰパケットに収まる場合を想定したが、暗号化データ１５３０の部分が長い場合は複数のＩＰパケットに分割されることもある。これについては、ＴＬＳおよびＴＣＰの標準に従って処理されるものとする。このことは、以降の図１６から図２０までにおいても同様である。
【０１３７】
暗号化データ１５３０は、ロケーション登録要求メッセージ本体１５４０を、ＴＬＳによって暗号化することによって生成される。ロケーション登録要求メッセージ本体１５４０は、ＳＩＰプロトコルに従って構成される。ここでは、メッセージ本体に含まれる主な情報のみを示す。ＳＩＰプロトコルを用いたメッセージ本体のより具体的な実現方法については、特許文献１に示されている。このことは、以降の図１６から図２０までにおいても同様である。
【０１３８】
ロケーション登録要求メッセージ本体１５４０には、ロケーション登録要求を表すメッセージ種別、サービス提供サーバの待ち受けアプリケーションを表すＵＲＩ、アプリケーションのプロトコル番号、アプリケーションのサービス提供サーバ側待ち受けポート番号、サービス提供サーバのグローバルIPアドレスといった情報が含まれる。これらの情報は、ロケーション情報１０１の内容に従って構成される。
【０１３９】
図１６は、実施例１におけるロケーション登録応答メッセージのデータ構造を表す図である。
【０１４０】
ロケーション登録応答メッセージ本体１６４０には、ロケーション登録要求に対する応答結果を示す情報が含まれる。
【０１４１】
図１７は、実施例１におけるＵＲＩ取得要求メッセージのデータ構造を表す図である。
【０１４２】
ＵＲＩ取得要求メッセージ本体１７４０には、ＵＲＩ取得要求を表すメッセージ種別、ＵＲＩ取得対象のＩＰアドレス、ＵＲＩ取得対象のプロトコル番号、ＵＲＩ取得対象のポート番号といった情報が含まれる。これらの情報は、ユーザ端末側の暗号通信モジュール１００−Ｃがユーザ端末側のアプリケーション１１０−Ｃから受け取った最初のデータパケット（図１１におけるステップ１１２１）の、ＩＰヘッダおよびＴＣＰ・ＵＤＰヘッダの内容に従って構成される。
【０１４３】
図１８は、実施例１におけるＵＲＩ取得応答メッセージのデータ構造を表す図である。
【０１４４】
ＵＲＩ取得応答メッセージ本体１８４０には、ＵＲＩ取得要求に対する応答結果、取得したＵＲＩといった情報が含まれる。
【０１４５】
図１９は、実施例１における通信開始要求メッセージのデータ構造を表す図である。
【０１４６】
通信開始要求メッセージ本体１９４０には、通信開始要求を表すメッセージ種別、通信先のサービス提供サーバ側アプリケーションを表すＵＲＩ、データパケットの暗号化に用いられる暗号化鍵、データパケットに含まれる認証値が正しいか否かを確認するために用いられる認証値確認鍵、それらの鍵情報に対応するＳＰＩ、データパケットのユーザ端末側ＩＰアドレス、データパケットのユーザ端末側の内側ヘッダのポート番号といった情報が含まれる。これらの情報（ＵＲＩを除く）に基づき、ユーザ側、サービス提供サーバ側の双方において、ＳＰ表１０３、受信ＳＡ表１０４、送信ＳＡ表１０５のエントリが生成される。
【０１４７】
図２０は、実施例１における通信開始応答メッセージのデータ構造を表す図である。
【０１４８】
通信開始応答メッセージ本体２０４０には、通信開始要求に対する応答結果、データパケットの暗号化に用いられる暗号化鍵、データパケットに含まれる認証値が正しいか否かを確認するために用いられる認証値確認鍵、それらの鍵情報に対応するＳＰＩ、データパケットのサービス提供サーバ側ＩＰアドレス、データパケットのサービス提供サーバ側の内側ヘッダのポート番号、データパケットのサービス提供サーバ側の外側ＵＤＰヘッダのポート番号といった情報が含まれる。これらの情報に基づき、ユーザ側、サービス提供サーバ側の双方において、ＳＰ表１０３、受信ＳＡ表１０４、送信ＳＡ表１０５のエントリが生成される。
【０１４９】
図２１は、実施例１における、暗号化されていないＩＰパケットのデータ構造を表す図である。
【０１５０】
本発明のアプリケーションが通信に用いるＩＰパケットにおいては、ＩＰの上位層プロトコルとしてＴＣＰもしくはＵＤＰを用いることを前提とする。また、送信元ポート番号と宛先ポート番号を持ち、ＮＡＰＴを適用可能な他のトランスポート層プロトコルにおいても、ＴＣＰやＵＤＰと同様に、本発明を適用可能である。本稿では、ＴＣＰもしくはＵＤＰを用いる場合のみについて言及する。
【０１５１】
ＩＰパケットは、ＩＰヘッダ２１１０と、ＩＰペイロードにより構成される。ＩＰペイロードは、ＴＣＰ・ＵＤＰヘッダ２１２０と、ＴＣＰ・ＵＤＰペイロード２１３０により構成される。
【０１５２】
ＩＰヘッダ２１１０には、送信元ＩＰアドレス２１１１、宛先ＩＰアドレス２１１２、プロトコル番号２１１３、チェックサム２１１４の各フィールドが含まれる。もちろん、一般的にはこれら以外のフィールドも含まれる。
【０１５３】
送信元ＩＰアドレス２１１１にはＩＰパケットの送信元のＩＰアドレスが格納される。宛先ＩＰアドレス２１１２にはＩＰパケットの宛先のＩＰアドレスが格納される。プロトコル番号２１１３にはＩＰの上位層プロトコルのプロトコル番号が格納される。チェックサム２１１４には、ＩＰヘッダから計算したチェックサム値が格納される。一般的に、このチェックサム値が誤っているＩＰパケットを受信したＩＰ処理は、そのパケットを破棄する。このため、送信元ＩＰアドレス２１１１や宛先ＩＰアドレス２１１２といった、ＩＰヘッダに含まれる情報を書き換えた場合は、チェックサム２１１４を再計算する必要がある。
【０１５４】
ＴＣＰ・ＵＤＰヘッダ２１２０には、送信元ポート番号２１２１、宛先ポート番号２１２２、チェックサム２１２３の各フィールドが含まれる。もちろん、一般的にはこれら以外のフィールドも含まれる。
【０１５５】
送信元ポート番号２１２１にはＴＣＰ・ＵＤＰパケットの送信元のポート番号が格納される。宛先ポート番号２１２２にはＴＣＰ・ＵＤＰパケットの宛先のポート番号が格納される。チェックサム２１２３には、ＴＣＰ・ＵＤＰパケット全体（ヘッダとペイロードの両方）から計算したチェックサム値が格納される。一般的に、このチェックサム値が誤っているＴＣＰ・ＵＤＰパケットを受信したＴＣＰ・ＵＤＰ処理は、そのパケットを破棄する。このため、送信元ポート番号２１２１や宛先ポート番号２１２２といった、ＴＣＰ・ＵＤＰヘッダに含まれる情報を書き換えた場合は、チェックサム２１２３を再計算する必要がある。ただし、ＵＤＰの場合は、チェックサムフィールド２１２３に、チェックサム計算を省略したことを表す値の、０を格納することが許されている。
【０１５６】
ＴＣＰ・ＵＤＰペイロード２１３０には、ＴＣＰもしくはＵＤＰのデータ本体が格納される。
【０１５７】
図２２は、実施例１における、暗号化されたＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットのデータ構造を表す図である。
【０１５８】
ＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットは、外側ＩＰヘッダ２２１０、外側ＵＤＰヘッダ２２２０、ＥＳＰ（Encapsulating Security Payload）ヘッダ２２３０、暗号化パケットデータ２２４０、ＩＣＶ（Integrity Check Value）２２５０により構成される。
【０１５９】
外側ＩＰヘッダ２２１０、外側ＵＤＰヘッダ２２２０の構成は、図２１のＩＰヘッダ２１１０、ＵＤＰヘッダ２１２０と同様である。ＥＳＰヘッダ２２３０には、ＳＰＩ  ２２３１のフィールドが含まれる。ＩＣＶ  ２２５０には、認証値２２５１のフィールドが含まれる。例えば、パケットデータの認証アルゴリズムにＨＭＡＣを用いる場合、認証値２２５１のフィールドには、ＥＳＰヘッダ２２３０と暗号化パケットデータ２２４０を元に計算したＭＡＣ（Message Authentication Code）が格納される。
【０１６０】
暗号化パケットデータ２２４０は、暗号化前のＩＰパケットの末尾にＥＳＰトレイラ２２６０を付加して暗号化することにより生成される。暗号化前のＩＰパケットは、図２１にて示したＩＰパケットと全く同じデータ構造である。
【０１６１】
図２３は、実施例１において、本発明の通信方法を備えた暗号通信モジュールがネットワークインターフェースドライバから受信パケットを受け取った際に行う、カプセル処理適用判定のフローを表す図である。
【０１６２】
本アルゴリズムは、暗号通信モジュール１００内のカプセル処理適用判定３０１が、ネットワークインターフェースドライバ３２０から受信パケットを受け取ったときに実行される。
【０１６３】
ネットワークインターフェースドライバ３２０から受信パケットを受け取ったカプセル処理適用判定３０１は、その受信パケットの送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル番号、送信元ポート番号、宛先ポート番号と、ポリシリスト１０２の相手側ＩＰアドレス５２１、自側（プライベート）ＩＰアドレス５４１、プロトコル番号５１０、相手側ポート番号５２２、自側（プライベート）ポート番号５４２とをそれぞれ比較することにより、ポリシリスト１０２を検索する（ステップ２３１０）。
【０１６４】
その結果、一致するエントリが見つかり、そのエントリのポリシ５５０が破棄またはカプセル内側であった場合は（ステップ２３２１）、受信パケットを破棄し（ステップ２３２２）、処理を終了する。
【０１６５】
一致するエントリが見つかり、そのエントリのポリシ５５０が非適用またはカプセル外側であった場合は（ステップ２３３１）、受信パケットをＯＳのＩＰ処理３１１に渡し（ステップ２３３２）、処理を終了する。
【０１６６】
一致するエントリが見つからなかった場合は、デフォルトの処理をとして、破棄または非適用のいずれかと同じ処理を行い（ステップ２３４０）、処理を終了する。破棄と非適用のどちらをデフォルトの処理とすべきかは、システムをどのようなセキュリティポリシで運用するかによって異なる。
【０１６７】
図２４は、実施例１において、本発明の通信方法を備えた暗号通信モジュールがＯＳのＩＰ処理から送信パケットを受け取った際に行う、カプセル処理適用判定のフローを表す図である。
【０１６８】
本アルゴリズムは、暗号通信モジュール１００内のカプセル処理適用判定３０１が、ＯＳのＩＰ処理３１１から送信パケットを受け取ったときに実行される。
【０１６９】
ＯＳのＩＰ処理３１１から送信パケットを受け取ったカプセル処理適用判定３０１は、その受信パケットの送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル番号、送信元ポート番号、宛先ポート番号と、ポリシリスト１０２の自側（プライベート）ＩＰアドレス５４１、相手側ＩＰアドレス５２１、プロトコル番号５１０、自側（プライベート）ポート番号５４２、相手側ポート番号５２２とをそれぞれ比較することにより、ポリシリスト１０２を検索する（ステップ２４１０）。
【０１７０】
その結果、一致するエントリが見つかり、そのエントリのポリシ５５０が破棄であった場合は（ステップ２４２１）、送信パケットを破棄し（ステップ２４２２）、処理を終了する。
【０１７１】
一致するエントリが見つかり、そのエントリのポリシ５５０がカプセル内側であった場合は（ステップ２４３１）、送信パケットに対してカプセル化処理３０３を適用し（ステップ２４３２）、処理を終了する。
【０１７２】
一致するエントリが見つかり、そのエントリのポリシ５５０が非適用またはカプセル外側であった場合は（ステップ２４４１）、送信パケットをネットワークインターフェースドライバ３２０に渡し（ステップ２４４２）、処理を終了する。
【０１７３】
一致するエントリが見つからなかった場合は、デフォルトの処理をとして、破棄または非適用のいずれかと同じ処理を行い（ステップ２４５０）、処理を終了する。破棄と非適用のどちらをデフォルトの処理とすべきかは、システムをどのようなセキュリティポリシで運用するかによって異なる。
図２５は、実施例１において、本発明の通信方法を備えた暗号通信モジュールがＯＳのＵＤＰ処理から受信パケットを受け取った際に行う、カプセル除去処理のフローを表す図である。
【０１７４】
本アルゴリズムは、暗号通信モジュール１００内のカプセル除去処理３０２が、ＯＳのＵＤＰ処理３１３から受信パケットを受け取ったときに実行される。
【０１７５】
ＯＳのＵＤＰ処理３１３から受信パケットを受け取ったカプセル除去処理３０２は、受信パケットに含まれるＳＰＩ  ２２３１と、ＳＰ表１０３の受信ＳＰＩ  ６４０とを比較することにより、ＳＰ表１０３を検索する（ステップ２５１０）。その結果、一致エントリが見つからなければ（ステップ２５１１）、パケットを破棄して（ステップ２５９５）、処理を終了する。
【０１７６】
一致エントリが見つかった場合は、今度は受信パケットに含まれるＳＰＩ  ２２３１と、受信ＳＡ表１０４の受信ＳＰＩ  ７１０とを比較することにより、受信ＳＡ表１０４を検索し、ＳＰＩに対応する復号化鍵７２０と認証値確認鍵７３０を得る。そして、この認証値確認鍵７３０を用いて、受信パケットの認証値を計算し、受信パケットに含まれる認証値２２５１と一致するか否かを確認する（ステップ２５２０）。もし、これらの値が一致しなければ（ステップ２５２１）、パケットを破棄して（ステップ２５９５）、処理を終了する。
【０１７７】
認証値が一致した場合は、先ほど得た復号化鍵７２０を用いて、受信パケット内の暗号化パケットデータ２２４０を復号化し、平文の内側ＩＰパケットを得る（ステップ２５３０）。そして、この内側ＩＰパケットのＩＰヘッダ２１１０に含まれるプロトコル番号、送信元ＩＰアドレス、宛先ＩＰアドレス、およびＴＣＰ・ＵＤＰヘッダ２１２０に含まれる送信元ポート番号、宛先ポート番号と、先ほど検索して見つけたＳＰ表のエントリに含まれる内側ヘッダ（オリジナル）６２０のプロトコル番号６２１、相手側ＩＰアドレス６２２、自側ＩＰアドレス６２４、相手側ポート番号６２３、自側ポート番号６２５とそれぞれ比較し、全て一致するかどうかを確認する（ステップ２５４０）。もし一致しない項目があれば（ステップ２５４１）、パケットを破棄して（ステップ２５９５）、処理を終了する。
【０１７８】
これらの値が一致した場合は、受信パケットの外側ＩＰヘッダ２２１０の送信元ＩＰアドレス、および外側ＵＤＰヘッダ２２２０の送信元ポート番号の値を、先ほど検索して見つけたＳＰ表のエントリの、外側ヘッダ６１０の相手側ＩＰアドレス６１１および相手側ポート番号６１２の項目にそれぞれセットする（ステップ２５５０）。
【０１７９】
次に、先ほど検索して見つけたＳＰ表のエントリの、仮想相手側ポート番号６３０の項目が未登録か否かを調べ（ステップ２５６０）、未登録であれば（ステップ２５６１）、外側ヘッダ６１０の相手側ＩＰアドレス６１１が同じ他の全てのＳＰ表エントリと異なる値になるように、仮想相手側ポート番号６３０を新たに決定し、ＳＰ表の該当エントリに登録する（ステップ２５６２）。
【０１８０】
次に、受信パケットの内側ＩＰヘッダの送信元ＩＰアドレスと宛先ＩＰアドレス、内側ＴＣＰ・ＵＤＰヘッダの送信元ポート番号をそれぞれ、ＳＰ表の該当エントリの外側ヘッダ６１０列の相手側ＩＰアドレス６１１、自側ＩＰアドレス６１３、仮想相手側ポート番号６３０の値で書き換え（ステップ２５７０）、内側ＩＰヘッダのチェックサム２１１４と内側ＴＣＰ・ＵＤＰヘッダのチェックサム２１２３を、必要であれば再計算し、再計算した値で書き換える（ステップ２５７５）。
【０１８１】
そして、外側ＩＰヘッダ２２１０、外側ＵＤＰヘッダ２２２０、ＥＳＰヘッダ２２３０、ＥＳＰトレイラ２２６０、ＩＣＶ  ２２５０を全て受信パケットから取り除き（ステップ２５８０）、残った内側ＩＰパケットをＯＳのＩＰ処理３１１に渡し（ステップ２５８５）、処理を終了する。
【０１８２】
図２６は、実施例１において、本発明の通信方法を備えた暗号通信モジュールのカプセル処理適用判定から呼び出される、送信パケットのカプセル化処理のフローを表す図である。
【０１８３】
本アルゴリズムは、暗号通信モジュール１００内のカプセル処理適用判定３０１が、ＯＳのＩＰ処理３１１から受け取った送信パケットを「カプセル内側」と判定したときに実行される。
【０１８４】
カプセル処理適用判定３０１から送信パケットを受け取ったカプセル化処理３０３は、送信パケットのＩＰヘッダ２１１０の送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル番号、およびＴＣＰ・ＵＤＰヘッダ２１２０の送信元ポート番号、宛先ポート番号と、ＳＰ表１０３の外側ヘッダ６１０の自側ＩＰアドレス６１３、相手側ＩＰアドレス６１１、および内側ヘッダ（オリジナル）６２０のプロトコル番号６２１、自側ポート番号６２５、および仮想相手側ポート番号６３０の値とをそれぞれ比較することにより、ＳＰ表１０３を検索する（ステップ２６１０）。
【０１８５】
その結果、一致するエントリがない場合は（ステップ２６１１）、送信パケットのＩＰヘッダ２１１０のプロトコル番号、宛先ＩＰアドレス、ＴＣＰ・ＵＤＰヘッダ２１２０の宛先ポート番号に対応するＵＲＩの取得、および、該当ＵＲＩが表すサービス提供サーバ側アプリケーション１１０−Ｓとの暗号通信の開始を、シグナリング処理３０４に要求する（ステップ２６８０）。その結果、暗号通信の開始準備が失敗した場合は（ステップ２６８１）、パケットの送信が失敗したものとして、処理を終了する。成功した場合は、以下の処理を継続する。
【０１８６】
次に、送信パケットのＩＰヘッダ２１１０の送信元ＩＰアドレスと宛先ＩＰアドレス、ＴＣＰ・ＵＤＰヘッダ２１２０の宛先ポート番号をそれぞれ、ＳＰ表１０３の該当エントリ（ステップ２６１０で一致するエントリが見つかった場合はそのエントリ、見つからなかった場合はステップ２６８０で新たに生成されたエントリ）の内側ヘッダ（オリジナル）６２０の自側ＩＰアドレス６２４、相手側ＩＰアドレス６２２、相手側ポート番号６２３の値でそれぞれ書き換える（ステップ２６２０）。そして、ＩＰヘッダのチェックサム２１１４とＴＣＰ・ＵＤＰヘッダのチェックサム２１２３を、必要であれば再計算し、再計算した値で書き換える（ステップ２６２５）。
【０１８７】
次に、送信ＳＡ表１０５から、ＳＰ表１０３の該当エントリの送信ＳＰＩ  ６５０と、送信ＳＰＩ  ８１０の値が一致するエントリを探し、該当エントリの暗号化鍵８２０と認証値計算鍵８３０を得る。そして、この暗号化鍵８２０を用いて、ＥＳＰトレイラ２２６０を付加した送信パケットを暗号化し、生成された暗号化パケットデータ２２４０の先頭にＥＳＰヘッダ２２３０を付加し、そのＳＰＩフィールド２２３１に送信ＳＰＩ  ６５０の値をセットする（ステップ２６３０）。
【０１８８】
次に、先ほど得た認証値計算鍵８３０を用いて、ＥＳＰヘッダ２２３０が付加された暗号化パケットデータ２２４０の認証値を計算し、暗号化パケットデータ２２４０の末尾にＩＣＶ  ２２５０を付加し、その認証値フィールド２２５１へ計算した認証値をセットする（ステップ２６３５）。
【０１８９】
そして、ＳＰ表１０３の該当エントリの外側ヘッダ６１０の自側ＩＰアドレス６１３、相手側ＩＰアドレス６１１、自側ポート番号６１４、相手側ポート番号６１２を、それぞれ、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号として、生成した暗号化パケット（ＥＳＰヘッダ２２３０、暗号化パケットデータ２２４０、およびＩＣＶ  ２２５０により構成）を、ＯＳのＵＤＰ処理３１３経由で送信し（ステップ２６４０）、処理を終了する。
【実施例２】
【０１９０】
図２７は、実施例２における、本発明の通信方法を備えた暗号通信モジュールの適用対象となるシステムのネットワーク構成を表す図である。
【０１９１】
実施例２においては、暗号通信モジュール２７００−Ｃ、２７００−Ｓは、ユーザ端末２７２０−Ｃやサービス提供サーバ２７２０−Ｓではなく、暗号通信機能付ＮＡＰＴルータ２７３５−Ｃ、２７３５−Ｓの内部において動作する。暗号通信機能付ＮＡＰＴルータ２７３５−Ｃ、２７３５−Ｓの内部では、実施例１の暗号通信モジュール１００−Ｃ、１００−Ｓと同等の動作を行う暗号通信モジュール２７００−Ｃ、２７００−Ｓ、および、実施例１のＮＡＰＴルータ１３０−Ｃ、１３０−Ｓと同等の動作を行うＮＡＰＴルータモジュール２７３０−Ｃ、２７３０−Ｓが動作する。ユーザ端末２７２０−Ｃやサービス提供サーバ２７２０−Ｓの内部ではアプリケーション１１０−Ｃ、１１０−Ｓのみが動作する。
【０１９２】
本実施例においては、ユーザ端末２７２０−Ｃやサービス提供サーバ２７２０−Ｓと、暗号通信機能付ＮＡＰＴルータ２７３５−Ｃ、２７３５−Ｓとの間のＬＡＮにおいては、平文のままアプリケーションの通信が行われる。その一方で、一台の暗号通信機能付ＮＡＰＴルータ２７３５−Ｃのみで、同一のＮＡＰＴルータ下に置かれた、暗号通信機能のない複数のユーザ端末が、ＷＡＮにおいてアプリケーションの通信を暗号化することができる。サービス提供サーバについても同様である。
【０１９３】
なお、実施例１に示した、暗号通信モジュールをユーザ端末やサービス提供サーバの中に置く方法と、実施例２に示した、暗号通信モジュールをＮＡＰＴルータの中に置く方法とは、ＬＡＮ毎にいずれか一方の方法に統一されていれば、混在させることができる。すなわち、ユーザ端末側では暗号通信モジュールをＮＡＰＴルータの中に置く方法を用い、サービス提供サーバ側ではサービス提供サーバの中に暗号通信モジュールを置く方法を用いてもよい。
【０１９４】
図２８は、実施例２における、本発明の通信方法を備えた暗号通信モジュールが動作する、暗号通信機能付ＮＡＰＴルータの内部処理アーキテクチャを示す図である。
【０１９５】
暗号通信機能付ＮＡＰＴルータ２７３５は、ＷＡＮ側とＬＡＮ側のそれぞれにネットワークインターフェース２８３１，２８３２を持ち、それぞれに対応するネットワークインターフェースドライバ２９２１，２９２２が動作する。また、アプリケーションではなくＮＡＰＴルータの機能を持つため、アプリケーションのソフトウェアの代わりにＮＡＰＴルータモジュール２７３０が動作し、NAPT変換表131が存在する。他の構成は、実施例１のユーザ端末２７２０−Ｃやサービス提供サーバ２７２０−Ｓとほぼ同じである。
【０１９６】
図２９は、実施例２における、本発明の通信方法を備えた暗号通信モジュールを含む、暗号通信機能付ＮＡＰＴルータのソフトウェア構成を示す図である。
【０１９７】
暗号通信機能付ＮＡＰＴルータ２７３５はＩＰ層でのパケット中継を行える必要があるため、ＯＳのＩＰ終端・アドレス変換・中継処理２９１１は、エンドホストとしてのＩＰの送受信のみではなく、ルータとしてのＩＰパケット中継機能も備える。また、ＮＡＰＴルータモジュールからの設定に従い、中継パケットに対するＮＡＰＴ処理も行う。
【０１９８】
暗号通信モジュール２７００のカプセル処理適用判定２９０１は、ＩＰ終端・アドレス変換・中継処理２９１１の、ネットワークインターフェース（ＬＡＮ側）２８３１に対応するＩＰ通信インターフェースと、ネットワークインターフェース（ＬＡＮ側）２８３１に対応するネットワークインターフェースドライバ（ＬＡＮ側）２９２１との間に入り、中継されるＩＰパケットに対して、カプセル除去処理２９０２もしくはカプセル化処理２９０３を行うべきか、いずれの処理も行わずにそのままＩＰ終端・アドレス変換・中継処理２９１１やネットワークインターフェースドライバ（ＬＡＮ側）２９２１に渡すべきか、どの処理にも渡さずに破棄すべきかを判断する。そして、その判断結果に応じた処理を実行する。
【０１９９】
カプセル除去処理２９０２は、カプセル処理適用判定２９０１によって復号化すべきと判断されたＩＰｓｅｃトンネルモード形式パケットをカプセル処理適用判定２９０１から受け取り、そのパケットの認証値の確認や復号化を行い、取り出した内側の平文ＩＰパケットをネットワークインターフェースドライバ（ＬＡＮ側）２９２１に引き渡す。
【０２００】
カプセル化処理２９０３は、カプセル処理適用判定２９０１によって暗号化すべきと判断された平文ＩＰパケットをカプセル処理適用判定２９０１から受け取り、そのパケットを暗号化して適切なヘッダ等を付加し、ＩＰｓｅｃトンネルモード形式パケットを生成して、ＩＰ終端・アドレス変換・中継処理２９１１経由でＷＡＮ側へ中継する。なお、この暗号化処理に必要な暗号通信路確立がまだ行われていない場合は、シグナリング処理２９０４に暗号通信の開始を要求し、その結果として暗号通信路が確立された後に、パケットの暗号化および送出を行う。
【０２０１】
図３０は、実施例２において、本発明の通信方法を備えた暗号通信モジュールがＯＳのＩＰ終端・アドレス変換・中継処理から中継パケットを受け取った際に行う、カプセル処理適用判定のフローを表す図である。
【０２０２】
本アルゴリズムは、暗号通信モジュール２７００内のカプセル処理適用判定２９０１が、ＩＰ終端・アドレス変換・中継処理２９１１からＬＡＮへの中継パケットを受け取ったときに実行される。
【０２０３】
ＩＰ終端・アドレス変換・中継処理２９１１からＬＡＮへの中継パケットを受け取ったカプセル処理適用判定２９０１は、図２３のステップ２３１０と同様にして、ポリシリスト１０２を検索する（ステップ３０１０）。
【０２０４】
その結果、一致するエントリが見つかり、そのエントリのポリシ５５０が破棄またはカプセル内側であった場合は（ステップ３０２１）、中継パケットを破棄し（ステップ３０２２）、処理を終了する。
【０２０５】
一致するエントリが見つかり、そのエントリのポリシ５５０がカプセル外側であった場合は（ステップ３０３１）、中継パケットに対してカプセル除去処理２９０２を適用し（ステップ３０３２）、処理を終了する。
一致するエントリが見つかり、そのエントリのポリシ５５０が非適用であった場合は（ステップ３０４１）、中継パケットをネットワークインターフェースドライバ（ＬＡＮ側）２９２１に渡し（ステップ３０４２）、処理を終了する。
【０２０６】
一致するエントリが見つからなかった場合は、デフォルトの処理をとして、破棄または非適用のいずれかと同じ処理を行い（ステップ３０５０）、処理を終了する。破棄と非適用のどちらをデフォルトの処理とすべきかは、システムをどのようなセキュリティポリシで運用するかによって異なる。
【０２０７】
図３１は、実施例２において、本発明の通信方法を備えた暗号通信モジュールがネットワークインターフェースドライバ（ＬＡＮ側）から中継パケットを受け取った際に行う、カプセル処理適用判定のフローを表す図である。
【０２０８】
本アルゴリズムは、暗号通信モジュール２７００内のカプセル処理適用判定２９０１が、ネットワークインターフェースドライバ（ＬＡＮ側）２９２１からＷＡＮへの中継パケットを受け取ったときに実行される。
【０２０９】
ネットワークインターフェースドライバ（ＬＡＮ側）２９２１からＷＡＮへの中継パケットを受け取ったカプセル処理適用判定２９０１は、図２４のステップ２４１０と同様にして、ポリシリスト１０２を検索する（ステップ３１１０）。
【０２１０】
その結果、一致するエントリが見つかり、そのエントリのポリシ５５０が破棄またはカプセル外側であった場合は（ステップ３１２１）、中継パケットを破棄し（ステップ３１２２）、処理を終了する。
【０２１１】
一致するエントリが見つかり、そのエントリのポリシ５５０がカプセル内側であった場合は（ステップ３１３１）、中継パケットに対してカプセル化処理２９０３を適用し（ステップ３１３２）、処理を終了する。
【０２１２】
一致するエントリが見つかり、そのエントリのポリシ５５０が非適用であった場合は（ステップ３１４１）、中継パケットをＩＰ終端・アドレス変換・中継処理２９１１に渡し（ステップ３１４２）、処理を終了する。
【０２１３】
一致するエントリが見つからなかった場合は、デフォルトの処理をとして、破棄または非適用のいずれかと同じ処理を行い（ステップ３１５０）、処理を終了する。破棄と非適用のどちらをデフォルトの処理とすべきかは、システムをどのようなセキュリティポリシで運用するかによって異なる。
【０２１４】
図３２は、実施例２において、本発明の通信方法を備えた暗号通信モジュールのカプセル処理適用判定から呼び出される、中継パケットのカプセル除去処理のフローを表す図である。
【０２１５】
本フローの内容は、図２５に示した、実施例１におけるカプセル除去処理のフローとほぼ同じである。大きな違いは、処理対象の暗号化ＩＰｓｅｃパケットの受け取りがＵＤＰ処理の上ではなくＩＰ終端・アドレス変換・中継処理２９１１の下で行われるため、処理前の暗号化ＩＰｓｅｃパケットに外側ＩＰヘッダおよび外側ＵＤＰヘッダが付加されていることと、最終的に生成した平文ＩＰパケットの受け渡し先が、ネットワークインターフェースドライバ（ＬＡＮ側）２９２１となることのみである。
【０２１６】
図３３は、実施例２において、本発明の通信方法を備えた暗号通信モジュールのカプセル処理適用判定から呼び出される、中継パケットのカプセル化処理のフローを表す図である。
【０２１７】
本フローの内容は、図２６に示した、実施例１におけるカプセル化処理のフローとほぼ同じである。大きな違いは、処理後の暗号化ＩＰｓｅｃパケットの受け渡しがＵＤＰ処理に対してではなくＩＰ終端・アドレス変換・中継処理２９１１に対して行われるため、処理後の暗号化ＩＰｓｅｃパケットに外側ＩＰヘッダおよび外側ＵＤＰヘッダを付加する必要があることと、最終的に生成した暗号化ＩＰｓｅｃパケットの受け渡し先が、ＩＰ終端・アドレス変換・中継処理２９１１となることのみである。
【０２１８】
本実施例のように暗号通信モジュールをＮＡＰＴルータの中に置くことにより、ユーザ端末およびサービス提供サーバは、その内部に暗号通信モジュールがなくても、外部ネットワーク区間において暗号通信を行うことが可能になる。特に、１台のＮＡＰＴルータの下に複数のユーザ端末（もしくはサービス提供サーバ）が存在する場合、実施例１の構成では各ユーザ端末（もしくはサービス提供サーバ）に暗号通信モジュールを導入する必要があるが、本実施例の構成ではその必要がない。ただし、その代わりに、本実施例においてはユーザ端末（もしくはサービス提供サーバ）とＮＡＰＴルータとの間が平文通信となるため、この区間においては本発明とは別の手段を用いて通信の安全性を確保する必要がある。
【実施例３】
【０２１９】
図３４は、実施例３における、本発明の通信方法を備えた暗号通信モジュールの適用対象となるシステムのネットワーク構成を表す図である。
【０２２０】
本実施例のように、ＮＡＰＴがユーザ端末側のみに適用されており、サービス提供サーバに直接グローバルＩＰアドレスが割り当てられている場合においても、アプリケーションの暗号通信を問題なく実施可能である。また、本実施例においては、暗号通信モジュールをユーザ端末およびサービス提供サーバに内蔵させた場合を示したが、ユーザ端末側については、実施例２のように、ＮＡＰＴルータに内蔵しても問題なく実施可能である。
【０２２１】
図３５は、実施例３において、ＵＡＣとＵＡＳとの間の暗号化通信路を確立した後に、その暗号化通信路を用いてＵＡＣ側アプリケーションからＵＡＳ側アプリケーションへデータパケットを送信する際の、送受信シーケンス図である。
【０２２２】
本実施例においては、サービス提供サーバ側にＮＡＰＴルータが設置されていないので、いずれの装置およびソフトウェアにおいても、サービス提供サーバ側のＩＰアドレスおよび外側ＵＤＰポート番号は、同じグローバルＩＰアドレスとポート番号（図３４におけるＩＰアドレスＤ、ポート番号ｄ−ｕｄｐ）で認識される。その他については、実施例１の図１３に示したシーケンス図と同様である。
【０２２３】
図３６は、実施例３において、ＵＡＣとＵＡＳとの間の暗号化通信路を確立した後に、その暗号化通信路を用いてＵＡＳ側アプリケーションからＵＡＣ側アプリケーションへデータパケットを送信する際の、送受信シーケンス図である。
【０２２４】
本実施例においては、サービス提供サーバ側にＮＡＰＴルータが設置されていないので、いずれの装置およびソフトウェアにおいても、サービス提供サーバ側のＩＰアドレスおよび外側ＵＤＰポート番号は、同じグローバルＩＰアドレスとポート番号（図３４におけるＩＰアドレスＤ、ポート番号ｄ−ｕｄｐ）で認識される。その他については、実施例１の図１４に示したシーケンス図と同様である。
【実施例４】
【０２２５】
図３７は、実施例４における、本発明の通信方法を備えた暗号通信モジュールの適用対象となるシステムのネットワーク構成を表す図である。
【０２２６】
本実施例のように、ユーザ端末側にＮＡＰＴルータが二重に設置されている場合においても、アプリケーションの暗号通信を問題なく実施可能である。また、サービス提供サーバ側にＮＡＰＴルータが二重に設置されている場合においても、最も外部ネットワーク１６０に近い位置に置かれたＮＡＰＴルータに割り振られたグローバルＩＰアドレスと、両者のＮＡＰＴルータを通過した際に起こる静的ＮＡＰＴ変換の規則を予め把握し、サービス提供サーバ側の暗号通信モジュールにこれらの設定を正しく行えば、アプリケーションの暗号通信を問題なく実施可能である。
【図面の簡単な説明】
【０２２７】
【図１】実施例1における、本発明の通信方法を備えた暗号通信モジュールの適用対象となるシステムのネットワーク構成を表す図である。
【図２】実施例１における、本発明の通信方法を備えた暗号通信モジュールが動作する、ユーザ端末またはサービス提供サーバの内部処理アーキテクチャを示す図である。
【図３】実施例１における、本発明の通信方法を備えた暗号通信モジュールを含む、ユーザ端末またはサービス提供サーバのソフトウェア構成を示す図である。
【図４】実施例１におけるロケーション情報を表す図である。
【図５】実施例１におけるポリシリストを表す図である。
【図６】実施例１におけるＳＰ表を表す図である。
【図７】実施例１における受信ＳＡ表を表す図である。
【図８】実施例１における送信ＳＡ表を表す図である。
【図９】実施例１におけるロケーションデータベースを表す図である。
【図１０】実施例１におけるＮＡＰＴ変換表を表す図である。
【図１１】実施例１において、ＵＡＣ側アプリケーションからのデータパケット送信を契機として、ＵＡＣとＵＡＳとの間に暗号化通信路を確立し、暗号化通信を開始する際の、送受信シーケンス図である。
【図１２】実施例１において、ＵＡＣ側アプリケーションから暗号通信モジュールへの通信開始要求を契機として、ＵＡＣとＵＡＳとの間に暗号化通信路を確立し、暗号化通信を開始する際の、送受信シーケンス図である。
【図１３】実施例１において、ＵＡＣとＵＡＳとの間の暗号化通信路を確立した後に、その暗号化通信路を用いてＵＡＣ側アプリケーションからＵＡＳ側アプリケーションへデータパケットを送信する際の、送受信シーケンス図である。
【図１４】実施例１において、ＵＡＣとＵＡＳとの間の暗号化通信路を確立した後に、その暗号化通信路を用いてＵＡＳ側アプリケーションからＵＡＣ側アプリケーションへデータパケットを送信する際の、送受信シーケンス図である。
【図１５】実施例１におけるロケーション登録要求メッセージのデータ構造を表す図である。
【図１６】実施例１におけるロケーション登録応答メッセージのデータ構造を表す図である。
【図１７】実施例１におけるＵＲＩ取得要求メッセージのデータ構造を表す図である。
【図１８】実施例１におけるＵＲＩ取得応答メッセージのデータ構造を表す図である。
【図１９】実施例１における通信開始要求メッセージのデータ構造を表す図である。
【図２０】実施例１における通信開始応答メッセージのデータ構造を表す図である。
【図２１】実施例１における、暗号化されていないＩＰパケットのデータ構造を表す図である。
【図２２】実施例１における、暗号化されたＵＤＰヘッダ付ＩＰｓｅｃトンネルモード形式パケットのデータ構造を表す図である。
【図２３】実施例１において、本発明の通信方法を備えた暗号通信モジュールがネットワークインターフェースドライバから受信パケットを受け取った際に行う、カプセル処理適用判定のフローを表す図である。
【図２４】実施例１において、本発明の通信方法を備えた暗号通信モジュールがＯＳのＩＰ処理から送信パケットを受け取った際に行う、カプセル処理適用判定のフローを表す図である。
【図２５】実施例１において、本発明の通信方法を備えた暗号通信モジュールがＯＳのＵＤＰ処理から受信パケットを受け取った際に行う、カプセル除去処理のフローを表す図である。
【図２６】実施例１において、本発明の通信方法を備えた暗号通信モジュールのカプセル処理適用判定から呼び出される、送信パケットのカプセル化処理のフローを表す図である。
【図２７】実施例２における、本発明の通信方法を備えた暗号通信モジュールの適用対象となるシステムのネットワーク構成を表す図である。
【図２８】実施例２における、本発明の通信方法を備えた暗号通信モジュールが動作する、暗号通信機能付ＮＡＰＴルータの内部処理アーキテクチャを示す図である。
【図２９】実施例２における、本発明の通信方法を備えた暗号通信モジュールを含む、暗号通信機能付ＮＡＰＴルータのソフトウェア構成を示す図である。
【図３０】実施例２において、本発明の通信方法を備えた暗号通信モジュールがＯＳのＩＰ終端・アドレス変換・中継処理から中継パケットを受け取った際に行う、カプセル処理適用判定のフローを表す図である。
【図３１】実施例２において、本発明の通信方法を備えた暗号通信モジュールがネットワークインターフェースドライバ（ＬＡＮ側）から中継パケットを受け取った際に行う、カプセル処理適用判定のフローを表す図である。
【図３２】実施例２において、本発明の通信方法を備えた暗号通信モジュールのカプセル処理適用判定から呼び出される、中継パケットのカプセル除去処理のフローを表す図である。
【図３３】実施例２において、本発明の通信方法を備えた暗号通信モジュールのカプセル処理適用判定から呼び出される、中継パケットのカプセル化処理のフローを表す図である。
【図３４】実施例３における、本発明の通信方法を備えた暗号通信モジュールの適用対象となるシステムのネットワーク構成を表す図である。
【図３５】実施例３において、ＵＡＣとＵＡＳとの間の暗号化通信路を確立した後に、その暗号化通信路を用いてＵＡＣ側アプリケーションからＵＡＳ側アプリケーションへデータパケットを送信する際の、送受信シーケンス図である。
【図３６】実施例３において、ＵＡＣとＵＡＳとの間の暗号化通信路を確立した後に、その暗号化通信路を用いてＵＡＳ側アプリケーションからＵＡＣ側アプリケーションへデータパケットを送信する際の、送受信シーケンス図である。
【図３７】実施例４における、本発明の通信方法を備えた暗号通信モジュールの適用対象となるシステムのネットワーク構成を表す図である。
【符号の説明】
【０２２８】
１００  実施例１における暗号通信モジュール
１０１  ロケーション情報
１０２  ポリシリスト
１０３  ＳＰ表
１０４  受信ＳＡ表
１０５  送信ＳＡ表
１１０  アプリケーション
１２０  ユーザ端末（ＵＡＣ）またはサービス提供サーバ（ＵＡＳ）
１３０  ＮＡＰＴルータ
１３１  ＮＡＰＴ変換表
１４０  ＨＵＢ（レイヤ２スイッチ、リピータ等）
１５０  ＬＡＮ内の他のホスト
１６０  外部ネットワーク（インターネット等）
１７０  認証・鍵交換サーバ
１７１  ロケーションデータベース
２１０  ＣＰＵ
２２０  主記憶装置（メモリ）
２２１  ソフトウェア
２２２  データ
２３０  ネットワークインターフェース
２４０  内部バス
３０１  カプセル処理適用判定
３０２  カプセル除去処理
３０３  カプセル化処理
３０４  シグナリング処理
３１０  ＯＳ
３１１  ＩＰ処理
３１２  ＴＣＰ処理
３１３  ＵＤＰ処理
３１４  ＴＬＳ処理
３２０  ネットワークインターフェースドライバ
２７００  実施例２における暗号通信モジュール
２７２０  ユーザ端末またはサービス提供サーバ
２７３０  ＮＡＰＴルータモジュール
２７３５  暗号通信機能付ＮＡＰＴルータ
２８１０  ＣＰＵ
２８２０  主記憶装置（メモリ）
２８２１  ソフトウェア
２８２２  データ
２８３１  ネットワークインターフェース（ＬＡＮ側）
２８３２  ネットワークインターフェース（ＷＡＮ側）
２８４０  内部バス
２９０１  カプセル処理適用判定
２９０２  カプセル除去処理
２９０３  カプセル化処理
２９０４  シグナリング処理
２９１０  ＯＳ
２９１１  ＩＰ終端・アドレス変換・中継処理
２９１２  ＴＣＰ処理
２９１３  ＵＤＰ処理
２９１４  ＴＬＳ処理
２９２１  ネットワークインターフェースドライバ（ＬＡＮ側）
２９２２  ネットワークインターフェースドライバ（ＷＡＮ側）
３７３０  二重に設置されたＮＡＰＴルータ。
【図１】
2009111437.tif 000003
【図２】
2009111437.tif 000004
【図３】
2009111437.tif 000005
【図４】
2009111437.tif 000006
【図５】
2009111437.tif 000007
【図６】
2009111437.tif 000008
【図７】
2009111437.tif 000009
【図８】
2009111437.tif 000010
【図９】
2009111437.tif 000011
【図１０】
2009111437.tif 000012
【図１１】
2009111437.tif 000013
【図１２】
2009111437.tif 000014
【図１３】
2009111437.tif 000015
【図１４】
2009111437.tif 000016
【図１５】
2009111437.tif 000017
【図１６】
2009111437.tif 000018
【図１７】
2009111437.tif 000019
【図１８】
2009111437.tif 000020
【図１９】
2009111437.tif 000021
【図２０】
2009111437.tif 000022
【図２１】
2009111437.tif 000023
【図２２】
2009111437.tif 000024
【図２３】
2009111437.tif 000025
【図２４】
2009111437.tif 000026
【図２５】
2009111437.tif 000027
【図２６】
2009111437.tif 000028
【図２７】
2009111437.tif 000029
【図２８】
2009111437.tif 000030
【図２９】
2009111437.tif 000031
【図３０】
2009111437.tif 000032
【図３１】
2009111437.tif 000033
【図３２】
2009111437.tif 000034
【図３３】
2009111437.tif 000035
【図３４】
2009111437.tif 000036
【図３５】
2009111437.tif 000037
【図３６】
2009111437.tif 000038
【図３７】
2009111437.tif 000039