JP2005229435A - リゾルバをアプリケーションとは別に備えた端末及びリゾルバプログラム - Google Patents

Abstract

【課題】 セキュアに名前解決を行い、２つの端末間でセキュアデータチャネルを容易に構築する。
【解決手段】 他の端末とデータ通信を行うアプリケーションと名前解決モジュールとを有する端末において、前記名前解決モジュールにより、ネットワークに接続されたセッション管理装置との間で暗号化通信チャネルを確立し、前記アプリケーションにより他の端末の名前の入力を受け、その名前を名前解決依頼として前記名前解決モジュールに渡し、前記名前解決モジュールにより、当該名前を含む第１のメッセージを前記暗号化通信チャネルを用いてセッション管理装置に送信し、前記名前解決モジュールにより、前記他の端末からセッション管理装置を介して前記名前に対応するアドレスを含む第２のメッセージを受信し、当該アドレスが前記アプリケーションに渡され、当該アプリケーションにより、当該アドレスを用いて前記他の端末とデータ通信を行う。
【選択図】 図８

Description

本発明は、ネットワーク上の２つの端末間でセキュアなデータチャネルを構築する技術における名前解決に関するものである。

従来技術において、ＩＰネットワーク上の２つの端末間でセキュアなデータチャネルを構築しいわゆるピア・ツー・ピアの通信を行うためには、ＤＮＳサーバへの名前登録から、セキュリティを確保するためのＦＷ等の設定・管理、証明書の取得等の作業が必要である。また、多数の端末同士の間で相互認証および暗号化されたピア・ツー・ピアの通信を行うためにはそれら全端末の証明書を取得するか、あるいは全端末のＩＤ、パスワードを管理することが必要である。このように、従来技術では、ＩＰネットワーク上の２つの端末間でセキュアなデータチャネルを構築するために煩雑な作業が必要である。

また、名前解決のために使用されるＤＮＳサーバは、一般的に誰からもアクセスを許容するオープンなものであり、そこに名前とＩＰアドレスが登録されるため、名前解決を許容すべきでない者に対しても名前解決を許容することとなり、端末が不正なアクセスを受ける恐れがあるという問題がある。

また、上記のＤＮＳに関する従来技術として、名前とＩＰアドレスとの対応表を動的に変更させることが可能なＤＤＮＳ（ダイナミックＤＮＳ）があるが、他人のドメインのＩＰアドレスを自分のものに書き換えることができてしまう等の問題がある。
特開２００２−２０８９２１号公報

本発明は、上記の点に鑑みてなされたものであり、セキュアに名前解決を行い、２つの端末間でセキュアデータチャネルを容易に構築する技術を提供することを目的とする。

上記の課題は、他の端末とデータ通信を行うアプリケーションと名前解決モジュールとを有する端末であって、前記名前解決モジュールにより、前記端末はネットワークに接続されたセッション管理装置との間で暗号化通信チャネルを確立し、前記アプリケーションにより他の端末の名前の入力を受け、その名前を名前解決依頼として前記名前解決モジュールに渡し、前記名前解決モジュールにより、前記端末は当該名前を含む第１のメッセージを前記暗号化通信チャネルを用いてセッション管理装置に送信し、前記名前解決モジュールにより、前記端末は前記他の端末からセッション管理装置を介して前記名前に対応するアドレスを含む第２のメッセージを受信し、当該アドレスが前記アプリケーションに渡され、当該アプリケーションにより、当該アドレスを用いて前記他の端末とデータ通信を行うことを特徴とする端末を用いることにより解決できる。

上記の構成において、他の端末とセッション管理装置間でもシグナリングのための暗号化通信チャネルが確立されており、また、他の端末の名前とＩＰアドレスがその暗号化通信チャネルを介してセッション管理装置に登録されている。そして、前記第１のメッセージを受信したセッション管理装置は、前記名前に対応するアドレスを取得し、当該アドレスを更に含む第１のメッセージを前記他の端末に送信する。このように、暗号化通信チャネルを介して登録及び名前解決を行うため、セキュアに名前解決を行うことができる。

また、前記第１のメッセージ及び前記第２のメッセージの各々に、前記端末と前記他の端末との間の暗号化通信チャネル確立のための鍵情報を含ませることにより、２つの端末間でセキュアデータチャネルを容易に構築でき、前記データ通信を当該暗号化通信チャネルを用いて行うことができる。

例えば、前記第１のメッセージはＳＩＰに基づくＩＮＶＩＴＥメッセージであり、前記第２のメッセージはその応答メッセージである。

また、本発明は、コンピュータを名前解決手段として機能させるプログラムとして構成でき、当該名前解決手段は、ネットワークに接続されたセッション管理装置との間で暗号化通信チャネルを確立する手段と、前記コンピュータ上のアプリケーションにより入力された他のコンピュータの名前を名前解決依頼として受信する手段と、当該名前を含む第１のメッセージを前記暗号化通信チャネルを用いてセッション管理装置に送信する手段と、前記他のコンピュータから、セッション管理装置を介して前記名前に対応するアドレスを含む第２のメッセージを受信する手段と、当該アドレスを前記アプリケーションに渡す手段とを有する。

本発明によれば、安全に名前解決を行うことができるとともに、端末間でセキュアデータチャネルを容易に構築できる。また、セキュアデータチャネル構築のためのシグナリング機能を有するリゾルバをアプリケーションとは別に設けているため、アプリケーションを改造することなく、上記の効果を得ることができる。

以下、本発明の実施の形態を図を参照して説明する。まず、セキュアに名前解決を行う技術の前提となるセキュアデータチャネル構築技術について説明し、その後に、名前解決について詳細に説明する。

（セキュアに名前解決を行う技術の前提となるセキュアデータチャネル構築技術）
図１は、本発明の実施の形態におけるセキュアデータチャネル構築技術の概要を説明するための図である。

図１に示すように、端末１と端末２との間にセッション管理サーバ３を設置し、端末１−セッション管理サーバ３−端末２間で、端末１−端末２間のデータチャネル構築のためのシグナリング（信号手順）を実行し、データチャネル構築後はセッション管理サーバ３を介さずに端末間のみでデータ通信を行うというものである。

シグナリングにおいては、まず、端末１−セッション管理サーバ３間、セッション管理サーバ３−端末２間の各々で、ＩＰｓｅｃ等の暗号化通信を行うためのセキュアシグナリングチャネル確立のために、暗号鍵情報の交換、相互認証が行われる。そして、端末１−セッション管理サーバ３間、セッション管理サーバ３−端末２間の各々で確立されたセキュアシグナリングチャネルを介してセッション管理サーバへの名前登録、端末１−端末２間のセキュアデータチャネル確立のためのシグナリングが実行される。

端末１−セッション管理サーバ３間、セッション管理サーバ３−端末２間でのセキュアシグナリングチャネル確立におけるシグナリングにより、セッション管理サーバ３と端末１との間、セッション管理サーバ３と端末２との間において相互認証に基づく信頼関係が確立されているため、端末１と端末２との間でも信頼関係が確立されている。すなわち、上記の相互認証により、セッション管理サーバ３を介した信頼のチェーンモデルが構築される。従って、端末１−端末２間のセキュアデータチャネル確立のためのシグナリングでは、簡易な鍵情報の交換手順を用いることができる。

次に、端末１−セッション管理サーバ３−端末２間の通信のシーケンスを図２を参照して説明する。

図２に示すシーケンスは、端末１、セッション管理サーバ３、端末２がインターネット等のＩＰネットワークに接続されたシステム構成を前提とするものである。

各端末は、セッション管理サーバ３との間でシグナリングを実行するシグナリング機能、セキュアデータチャネルを介してデータ通信を行うための機能、及びデータ通信を利用して所望のサービスを提供するアプリケーションを備えている。

また、セッション管理サーバは、シグナリングを各端末との間で実行するシグナリング機能、端末間の接続許可等を制御する接続ポリシー制御機能、各端末を認証するための認証機能、端末の名前からＩＰアドレスを取得する名前解決機能、及び、認証のために用いるＩＤ、パスワードを格納するデータベースや、名前とＩＰアドレスを対応付けて格納するデータベース等を備えている。また、名前解決機能として一般のＤＮＳと同等の機能を持たせることもできる。

図２に示すように、端末１−端末２間でのセキュアデータチャネル構築にあたり、まず、端末１−セッション管理サーバ３間、端末２−セッション管理サーバ３間の各々でセキュアシグナリングチャネルを構築して、名前の登録を行う。

すなわち、端末１−セッション管理サーバ３間でＩＰｓｅｃ等の暗号通信で用いる鍵情報（暗号鍵生成用の情報）の交換を行う（ステップ１）。その後、自分のＩＤ、パスワードを含む情報を暗号化して相手側に送信することにより、相互に認証を行う（ステップ２）。認証後は、セキュアシグナリングチャネルが確立された状態となり、そのチャネルを用いて、端末１は名前とＩＰアドレスの登録をセッション管理サーバ３に対して行う（ステップ３）。端末１の通信相手となる端末２とセッション管理サーバ３間でも同様のシーケンスが実行され、端末２の名前とＩＰアドレスがセッション管理サーバ３に登録される（ステップ４、５、６）。

その後、端末１から端末２への接続要求が、セキュアシグナリングチャネルを介して送信される（ステップ７）。接続要求には、端末２の名前と暗号通信用の鍵情報（暗号鍵生成用の情報）が含まれる。接続要求を受信したセッション管理サーバ３は、端末１からの接続要求に関して、端末１が嘘をついていないことをチェックし（発信者詐称チェック）、更に、接続ポリシー制御機能を用いて端末１と端末２の接続が許可されているかをチェックし（ステップ８）、許可されていれば、名前解決機能を用いてデータベースを参照することにより端末２の名前から端末２のＩＰアドレスを取得し（ステップ９）、セキュアシグナリングチャネルを介して端末２へ接続要求を転送する（ステップ１０）。このとき、端末１のＩＰアドレスも端末２に送信される。端末１と端末２の接続が許可されていなければ、端末１の接続要求は拒否される。このとき、端末２に関する情報は端末１には全く送信されない。

接続要求を受信した端末２は、接続要求に対する応答として、暗号通信用の鍵情報を含む応答メッセージをセキュアシグナリングチャネルを介してセッション管理サーバ３に送信し（ステップ１１）、セッション管理サーバ３がその応答メッセージを端末１に送る（ステップ１２）。このとき、端末２のＩＰアドレスも端末１に送信される。

この手順により、端末１と端末２との間での暗号化通信が可能となる。すなわち、セキュアデータチャネルが確立され、所望のデータ通信が行われる。

ステップ１、２及び４、５を経てセキュアシグナリングチャネルが確立されているということは、端末−セッション管理サーバ間で相互に認証が成功しており、信頼関係が成立しているということである。端末１−セッション管理サーバ３間、及び端末２−セッション管理サーバ３間の各々でこのような関係が成立しているので、端末１と端末２との間も相互に信頼できる関係となることから、ステップ７以降は、一般の暗号化通信で用いられる鍵交換手順より簡略化した手順を用いることが可能となっている。

上記のシーケンスを実現する手段として、ＳＩＰ（session initiation protocol）を拡張したプロトコルを用いることが可能である。すなわち、セッション管理サーバ３をＳＩＰプロキシサーバとして機能させ、ＳＩＰのメッセージに上記の手順でやり取りされる情報を含ませる。

この場合、セキュアシグナリングチャネルの確立及び名前登録のためにＲＥＧＩＳＴＥＲメッセージを用い、端末１−端末２間のセキュアデータチャネル確立のためにＩＮＶＩＴＥメッセージを用いることができる。

ＳＩＰを用いる場合のシーケンス例を図３に示す。

図３に示す例は、セキュアなチャネルで接続された複数のセッション管理サーバを経由してシグナリングを行う場合の例である。なお、セキュアなチャネルで接続された複数のセッション管理サーバをセッション管理装置と称する場合がある。図３に示すシーケンスの構成において、端末１のＩＰアドレスが２００１：１２３４：：１０、セッション管理サーバＡのＩＰアドレスが２００１：６７８９：：５０６０、セッション管理サーバＢのＩＰアドレスが２００１：ａｂｃｄ：：５０６０、端末２のＩＰアドレスが２００１：ｃｄｅｆ：：１０である。

各端末とセッション管理サーバ間では予め互いにＩＤ、パスワードを配布しておき、端末とセッション管理サーバの各々は、相手のＩＤ、パスワードを自分の記憶装置に格納する。また、セッション管理サーバＡとセッション管理サーバＢの間は、ＴＬＳ等のセキュアなチャネルを介して通信を行う。

まず、端末１、２は、ＲＥＧＩＳＴＥＲメッセージを用いて、セッション管理サーバとのセキュアチャネルの確立、及び、（ＳＩＰに準拠した）名前の登録をセッション管理サーバＡ、Ｂに対して行う（ステップ２１）（図２のステップ１〜６に相当する）。なお、この部分の手順については後により詳細に説明する。

続いて、端末１が、暗号通信用の鍵情報（図の例では秘密共有鍵生成用の情報）をＳＤＰパラメータとして記述したＩＮＶＩＴＥメッセージを、端末２への接続要求として、端末１とセッション管理サーバＡ間のセキュアシグナリングチャネルを介して送信する（ステップ２２）。セッション管理サーバＡは、そのＩＮＶＩＴＥメッセージをセッション管理サーバＡ、Ｂ間のセキュアなチャネルを介してセッション管理サーバＢに転送する（ステップ２３）。

なお、端末１からのＩＮＶＩＴＥメッセージにはRoute-Securityヘッダが含まれる。Route-Securityヘッダが付加されている場合、そのＩＮＶＩＴＥメッセージを受信した装置は、Route-Securityヘッダ：[アドレス]で示されているアドレスから当該装置までの経路がセキュアなものであるかとうか（例えばＩＰｓｅｃによる暗号化がなされているかどうか）をチェックし、セキュアなものであればそのRoute-Securityヘッダをそのまま残してメッセージを転送する。また、転送先で経路がセキュアなものであるかとうかチェックを要する場合には、Route-Securityヘッダ：[自分のアドレス]を付加したメッセージをその転送先に転送する。応答メッセージには、これまでに付されたRoute-Securityヘッダがそのまま付されており、これにより、メッセージがセキュアな経路を介して転送されたものであることがわかる。すわわち、Route-Securityヘッダにより、経路の安全性を担保する仕組みが提供される。

セッション管理サーバＢは端末２に、ＩＮＶＩＴＥメッセージを端末２とセッション管理サーバＢ間のセキュアシグナリングチャネルを介して送信する（ステップ２４）。なお、セッション管理サーバＡ及びセッション管理サーバＢにおいて端末２の名前解決がなされている。

ＩＮＶＩＴＥメッセージを受信した端末２は、暗号通信用の鍵情報をＳＤＰパラメータとして含む応答メッセージを端末１に向けて送信する（ステップ２５）。そして、その応答メッセージは、ＩＮＶＩＴＥメッセージと同じルート上を逆の方向に運ばれ、端末１に送信される（ステップ２６、２７）。

その後、受信確認（ＡＣＫ）メッセージが端末１から端末２に送信され（ステップ２８〜３０）、端末１と端末２との間の暗号化通信（例えばＩＰｓｅｃによる通信）が可能となる。

図３のステップ２１におけるＲＥＧＩＳＴＥＲメッセージのシーケンスは、例えば図４に示す通りである。

この場合、まず、暗号通信用（ＩＰｓｅｃ等）の鍵情報を含むＲＥＧＩＳＴＥＲメッセージを端末からセッション管理サーバに送信する（ステップ２１１）。セッション管理サーバはその応答として暗号通信用の鍵情報を含む応答メッセージを端末に返す（ステップ２１２）。続いて、端末は、セッション管理サーバが端末を認証するための認証用情報を含むＲＥＧＩＳＴＥＲメッセージをセッション管理サーバに送信する（ステップ２１３）。セッション管理サーバはその応答として、端末がセッション管理サーバを認証するために必要な認証用情報を含む応答メッセージを端末に送信する（ステップ２１４）。互いの認証が取れた後、セキュアシグナリングチャネルによる暗号化通信が可能となる。

その後は、パケットがセキュアシグナリングチャネルを介して暗号化して送受信されるため、通常のＲＥＧＩＳＴＥＲメッセージシーケンスにより名前の登録が行われる（ステップ２１５、２１６）。

なお、上記のシーケンスにおいて、ＩＰｓｅｃ等の暗号化通信に必要なその他の情報は適宜送受信されているものとする。なお、認証用情報は、ＩＤ、パスワード等を含む情報でもよいし、証明書（Ｘ．５０９証明書等）でもよい。また、暗号通信用の鍵情報の交換のために用いるメッセージに認証用情報（証明書）を含めてもよい。

次に、シグナリングプロトコルとしてＳＩＰを用いる場合の各装置の機能ブロックを図５を参照して説明する。

セッション管理サーバは、呼（メッセージ）の転送のための処理を行うＳＩＰプロキシ、ＳＩＰの名前登録を行うＳＩＰレジストラ、ＩＤ、パスワード、もしくは証明書等を用いて各端末の認証を行う認証モジュール、ＩＰｓｅｃ等の暗号化通信を行うための暗号化モジュールを有している。

また、各端末は、セキュアデータチャネル上での通信を行う機能部、ＩＮＶＩＴＥメッセージの送受信やＲＥＧＩＳＴＥＲメッセージの発行等を含むＳＩＰに基づくメッセージ通信を行うＳＩＰ機能部、ＩＤ、パスワード、もしくは証明書等を用いてセッション管理サーバの認証を行う認証モジュール、ＩＰｓｅｃ等の暗号化通信を行うための暗号化モジュールを有している。

上記のセッション管理サーバ、各端末の機能は、プログラムにより実現されるものであり、本発明におけるセッション管理装置、端末の各手段は、プログラムと、セッション管理装置、端末のハードウェアとで実現されているものである。また、端末は、ＣＰＵ、メモリ、ハードディスク等を含む一般的なＰＣ等のコンピュータ、モバイル機器等であり、当該コンピュータ等に上記プログラムをインストールすることにより本実施の形態の端末の機能を実現できる。なお、端末はディジタル家電等でもよい。また、セッション管理サーバは、サーバ等のコンピュータであり、当該サーバに上記プログラムをインストールすることにより本実施の形態のセッション管理サーバの機能を実現できる。

上記のようなセキュアデータチャネル構築技術を用いることにより、次のような効果を奏する。

まず、端末のアドレスが変更される度にＲＥＧＩＳＴＥＲメッセージによる名前とＩＰアドレスの登録を行うので、端末側はいわゆる動的ＩＰアドレス割り当てを用いることができる。また、セッション管理サーバが名前解決を行うことから、従来は必要であったオープンなＤＮＳへの名前登録が不要となる。また、各端末とセッション管理サーバ間でセキュアなチャネルを構築してシグナリングを行うので、端末側でのＦＷ管理が不要となる。また、セッション管理サーバが各端末のＩＤ、パスワードを管理するので、端末側で多数のＩＤ、パスワードを管理することが不要となる。また、セッション管理サーバ接続ポリシー制御機能により、接続を許可していない相手端末に対しては、名前解決さえ許可していないので、その端末の存在自体を知られることがなく、端末が不正なアクセスを受ける恐れがなくなる。更に、セキュアシグナリングチャネルを介したシグナリングにより、セキュアデータチャネルに必要なポート番号が伝えられるので、シグナリングが正常に完了しない場合には、外部にはポート番号を知られることがない。また、軽いシグナリングだけが中間サーバ（セッション管理サーバ）を経由し、実際のデータ通信は端末間でピア・ツー・ピアで行われるので、中間サーバの負荷が過大となることはない。

また、従来技術においては、多数の端末同士の間で相互認証および暗号化されたピア・ツー・ピアの通信を行うためにはそれら全端末の証明書を取得するか、あるいは全端末のＩＤ、パスワードを管理することが必要であったが、本発明によれば、メンバー同士であれば何の事前セキュリティ設定が不要となる。

また、従来技術において、データチャネルの暗号化が不要だったとしても、発番号の信憑性を確保する手段として、PKIを使う方法等しかなかったが、本発明によれば、サービス設定（SIPのID/パスワード設定）だけで発番号の詐称・改竄を防ぐことができる。

（セキュアな名前解決について）
次に、図２に示した構成において、端末２をＷｅｂサーバ（例えばホームサーバ）とし、端末１をＷｅｂアプリケーションが実行されるクライアント端末とした場合における例を用いて、名前解決の技術について説明する。以下の例では、端末１をクライアント端末１、端末２をＷｅｂサーバ２と呼ぶこととする。また、以下では、ＳＩＰを用いる例を示している。なお、本明細書において“名前解決”とは、名前からその名前に対応するアドレスを取得することである。

図６に示す動作概要図及び図７のシーケンスチャートを用いて動作概要を説明する。

図６に示すように、クライアント端末１は、Ｗｅｂアプリケーション１１と、名前解決を行うためのリゾルバ１２（名前解決手段ともいう）を有している。また、リゾルバ１２は、セキュアデータチャネル構築のためのメッセージの送受信を行うＳＩＰ機能部１３を有している。すなわち、ＳＩＰ機能部１３により、クライアント端末１は、図２等に示したシーケンスを実行することができる。リゾルバ１２に含まれるＳＩＰ機能部１３は、図５に示すＳＩＰ機能部に相当するものである。なお、図５に示す認証モジュールは、リゾルバ内に備えてもよいし、リゾルバの外に備えてもよい。

図７のシーケンスにおいて、クライアント端末１とセッション管理サーバ３間では、ＲＥＧＩＳＴＥＲメッセージによりセキュアシグナリングチャネルが既に構築されているものとする（図２のステップ１〜ステップ３）。なお、クライアント端末１とセッション管理サーバ３間では、例えば、クライアント端末１の起動時にセキュアシグナリングチャネルを構築する。

図７に示すように、セッション管理サーバ３とＷｅｂサーバ２間では、ＲＥＧＩＳＴＥＲメッセージによりセキュアシグナリングチャネルの構築、及び名前とＩＰアドレスのセッション管理サーバ３への登録が行われる（図２のステップ４〜ステップ６に相当）。このように図２に示したプラットフォームで名前の登録が行われるので、セッション管理サーバは、信頼できるＷｅｂサーバのみから登録を受けることができ、従来のＤＤＮＳで生じ得る不正な登録を防止できる。

次に、クライアント端末１において、Ｗｅｂアプリケーション１１を用いてアクセス先の名前（ＳＩＰ ＵＲＩ）が入力される（ステップ２１）。その名前は、Ｗｅｂアプリケーション１１からリゾルバ１２に名前解決依頼として渡される（ステップ２２）。そして、リゾルバ１２のＳＩＰ機能部１３が、クライアント端末１とセッション管理サーバ３間のセキュアシグナリングチャネルを利用して、アクセス先（Ｗｅｂサーバ２）の名前を含むＩＮＶＩＴＥメッセージをセッション管理サーバ３に送信する（ステップ２３、図２のステップ７に相当）。セッション管理サーバ３は、受信した名前からＷｅｂサーバ２のＩＰアドレスを取得し、その情報を含むＩＮＶＩＴＥメッセージをＷｅｂサーバ２に送信する（ステップ２４、図２のステップ１０に相当）。そして、Ｗｅｂサーバ２は、そのＩＰアドレスを含む応答メッセージ（２００ ＯＫ）をクライアント端末１に送信する（ステップ２５、２６、図２のステップ１１、１２）。クライアント端末１のＳＩＰ機能部１３は、Ｗｅｂサーバ２に対してＡＣＫを返し（ステップ２７）、Ｗｅｂサーバ２のＩＰアドレスを名前解決結果としてＷｅｂアプリケーション１１に渡す（ステップ２８）。

図２を用いて既に説明したように、この時点でクライアント端末１とＷｅｂサーバ２間ではセキュアデータチャネルが確立しており、このチャネルを用いて、Ｗｅｂアプリケーション１１によりクライアント端末１はＷｅｂサーバ２にアクセスし（ステップ２９）、所望のデータを取得できる。

なお、上記のステップ２３の後、セッション管理サーバ３は、クライアント端末１によるＷｅｂサーバ２へのアクセスが許可されているかどうかを判断し、許可されていればＩＮＶＩＴＥメッセージの送信を続行するが、許可されていない場合には、Ｗｅｂサーバ２に何も情報を送らず、接続不許可の旨のメッセージをクライアント端末１に送信するようなアクセスコントロールを行うこともできる。

また、ステップ２４の後、Ｗｅｂサーバ２はどのクライアント端末１からのアクセスであるかがわかるので、クライアント端末１によるアクセスの可否を、Ｗｅｂサーバ２が判断することによりアクセスコントロールを行うこともできる。

このように、図２に示した技術を適用することにより、名前解決と並行してセキュアデータチャネルの確立を行うことができる。また、クライアント端末１側では、ユーザが意識することなくＷｅｂアプリケーションを用いたＷｅｂサーバとのピアツーピアセキュア通信を実現できる。また、図７に示したシグナリングシーケンスはリゾルバ１２のＳＩＰ機能部１３により実行されるので、既存のＷｅｂアプリケーションを改造することなく、上記の機能を実現できる。なお、Ｗｅｂアプリケーションの他にも所望のアプリケーションをリゾルバ１２と組み合わせて使用することにより、上記のようにユーザが意識することなく、当該アプリケーションを使用したクライアント端末１と接続相手先装置とのピアツーピアセキュア通信を実現できる。

図８に、クライアント端末１の機能ブロック図を示す。

この図では、Ｗｅｂアプリケーション１１、リゾルバ１２の他、暗号化通信モジュール１３を示している。暗号化通信モジュール１３は、例えばＩＰｓｅｃに基づく暗号化通信を行うためのモジュールである。動作の概要は以下の通りである。

Ｗｅｂアプリケーション１１に名前が入力されると（ステップ３１）、リゾルバ１２へ名前解決を依頼する（ステップ３２）。リゾルバ１２は、これまでに説明したセキュアシグナリングチャネルによるネゴシエーションにより、名前に対応するＩＰアドレスを取得する（ステップ３３）。また、ＳＩＰ機能部１３が取得した鍵情報から、暗号化通信コネクション（例えばＩＰｓｅｃ−ＳＡ）が暗号化通信モジュール１４において作成される（ステップ３４）。リゾルバ１２は、名前解決結果をＷｅｂアプリケーションに通知する（ステップ３５）。これにより、Ｗｅｂアプリケーション１１は、セキュアデータチャネルにてデータ通信を開始することができる（ステップ３６）。上記の動作で、Ｗｅｂアプリケーション１１の動作は、セキュアデータチャネルの構築、使用を行なわない場合の動作と同様である。すなわち、Ｗｅｂアプリケーション１１が意識することなく、セキュアデータチャネルの構築が行われ、セキュアデータチャネルを用いた通信を行うことができる。

本発明は、上記の実施例に限定されることなく、特許請求の範囲内で種々変更・応用が可能である。

本発明の実施の形態の概要について説明するための図である。 端末１−セッション管理サーバ３−端末２間の通信のシーケンス図である。 シーケンスを詳細に示す図である。 ＲＥＧＩＳＴＥＲメッセージのシーケンスを示す図である。 シグナリングプロトコルとしてＳＩＰを用いる場合の各装置の機能ブロック図である。 リゾルバを備えたクライアント端末の動作を説明するための図である。 リゾルバを備えたクライアント端末、セッション管理サーバ、Ｗｅｂサーバの処理を示すシーケンスチャートである。 クライアント端末の機能ブロック図である。

符号の説明

１、２ 端末
３、Ａ、Ｂ セッション管理サーバ
１１ Ｗｅｂアプリケーション
１２ リゾルバ
１３ ＳＩＰ機能部
１４ 暗号化通信モジュール

Claims (8)

1. 他の端末とデータ通信を行うアプリケーションと名前解決モジュールとを有する端末であって、
   前記名前解決モジュールにより、前記端末はネットワークに接続されたセッション管理装置との間で暗号化通信チャネルを確立し、
   前記アプリケーションにより他の端末の名前の入力を受け、その名前を名前解決依頼として前記名前解決モジュールに渡し、
   前記名前解決モジュールにより、前記端末は当該名前を含む第１のメッセージを前記暗号化通信チャネルを用いてセッション管理装置に送信し、
   前記名前解決モジュールにより、前記端末は前記他の端末からセッション管理装置を介して前記名前に対応するアドレスを含む第２のメッセージを受信し、
   当該アドレスが前記アプリケーションに渡され、当該アプリケーションにより、当該アドレスを用いて前記他の端末とデータ通信を行うことを特徴とする端末。
2. 前記第１のメッセージを受信したセッション管理装置は、予め登録された、前記名前に対応するアドレスを取得し、当該アドレスを更に含む第１のメッセージを前記他の端末に送信する請求項１に記載の端末。
3. 前記第１のメッセージ及び前記第２のメッセージの各々は、前記端末と前記他の端末との間の暗号化通信チャネル確立のための鍵情報を含み、前記データ通信を当該暗号化通信チャネルを用いて行う請求項１に記載の端末。
4. 前記第１のメッセージはＳＩＰに基づくＩＮＶＩＴＥメッセージであり、前記第２のメッセージはその応答メッセージである請求項１ないし３のうちいずれか１項に記載の端末。
5. コンピュータを名前解決手段として機能させるプログラムであって、当該名前解決手段は、
   ネットワークに接続されたセッション管理装置との間で暗号化通信チャネルを確立する手段と、
   前記コンピュータ上のアプリケーションにより入力された他のコンピュータの名前を名前解決依頼として受信する手段と、
   当該名前を含む第１のメッセージを前記暗号化通信チャネルを用いてセッション管理装置に送信する手段と、
   前記他のコンピュータから、セッション管理装置を介して前記名前に対応するアドレスを含む第２のメッセージを受信する手段と、
   当該アドレスを前記アプリケーションに渡す手段と
   を有することを特徴とするプログラム。
6. 前記第１のメッセージを受信したセッション管理装置は、予め登録された、前記名前に対応するアドレスを取得し、当該アドレスを更に含む第１のメッセージを前記他のコンピュータに送信する請求項５に記載のプログラム。
7. 前記第１のメッセージ及び前記第２のメッセージの各々は、前記コンピュータと前記他のコンピュータとの間の暗号化通信チャネル確立のための鍵情報を含む請求項５に記載のプログラム。
8. 前記第１のメッセージはＳＩＰに基づくＩＮＶＩＴＥメッセージであり、前記第２のメッセージはその応答メッセージである請求項５ないし７のうちいずれか１項に記載のプログラム。

Images