以下本発明の実施の形態について説明する。本発明はソフトウェア的な処理で実現される部分が多く、以下の実施の形態の説明では基本的な部分についての説明を行うが、それぞれの実施の形態で説明した機能を組み合わせることもできる。
(実施の形態1)
図1を参照して、本発明のアクセス制限の手法を用いた通信形態の概略を説明する。なお、図中の番号は括弧をつけて表す。公衆回線(500)は図17の公衆回線と同じものである。公衆回線は、不特定多数の人がアクセスすることができる。公衆回線には、エリア毎の通信を束ねる通信局があり、公衆回線と接続するには、これらの通信局を介して接続する。図では省略した。
PCCクライアント(以後「PCCC」とも言う。)は、ユーザ側にあって、本発明を実現する装置である。PCCクライアントは、直接若しくは図示しない通信局を介して公衆回線と接続する。ユーザはこのPCCクライアントを介して公衆回線と接続をはかる。PCCクライアントはユーザ端末1台につき1台が用意される。すなわち、PCCクライアントは端末に接続される端末接続装置である。
PCCサーバー(以後「PCCS」とも記す。)はサーバー側にあって、本発明を実現する装置である。PCCSは公衆回線と接続する。サーバー(以後「S」とも記す。)は、各種のサービスを実現するためのデータやアプリケーションが搭載されている。サービスを提供するサーバーは複数台存在してもよい。図では5台のサーバー(S1乃至S5)がある場合を例示している。各サーバーは、PCCSを介して公衆回線と接続する。PCCSはサーバー1台につき1台である必要はなく、1つのPCCSに複数のサーバーが接続されていてもよい。
PCCサーバーは、サーバーへの無制限な接続を制限し、サーバーに蓄えられた情報を必要以上に開示させない役割を負う。すなわち、PCCサーバーは、サーバー接続制限装置である。
サーバーが提供するサービスとは、電子メールやWWW、遠隔ログイン、ネット管理などのよく知られたアプリケーションの提供だけでなく、個人情報管理、経理管理、各種データアクセスなど特別に作成されたアプリケーションの提供を含める事ができる。これらのアプリケーションはいずれも各サーバーのポート番号(以後「P」とも記す。)で弁別することができる。
例えば、サーバーS1のポート35には、経理管理アプリケーションが割り当てられているといった具合である。なお、本明細書では、サービスとアプリケーションはほぼ同意に使っている。また、本明細書では、サービスを指定するのに、サーバーとポートを並べて記載する場合がある。その際は、サーバーとポートをコロンを挟んで並べて記載する。例えばサーバー1のポート1の場合は、S1:P1のごとくである。または、サーバーのアドレスとポート番号をコロンを介して記載する。例えばアドレスM1のサーバーのポート番号1の場合は、M1:P1のごとくである。
図1では、ユーザAとユーザBがサービスを利用できる構成を示す。ユーザAは端末装置(以後「端末」とも記す。)であるTa(10)を操作する。Ta(10)はPCCクライアントであるPCCCa(12)に接続されている。またユーザBは端末であるTb(14)を操作し、Tb(14)はPCCCb(16)に接続されている。PCCクライアントaおよびbは公衆回線(500)に接続されている。
なお、端末(10)、端末(14)、PCCクライアントa(12)、PCCクライアントb(16)の各IPアドレスは、それぞれUa、Ub、Aa、Abである。図では「IP、Ua」などと表示している。以後同様である。
また、端末(10)、端末(14)、PCCクライアントa(12)、PCCクライアントb(16)は、図中Ta、Tb、PCCCa、PCCCbと記載した。なお、PCCCaとはユーザAのPCCクライアントの意味である。
PCCサーバーは、PCCサーバーであるPCCS1(20)およびPCCS2(22)が公衆回線(500)に接続されている。それぞれのIPアドレスは、G1およびG2である。
サーバーはサーバー1乃至5(30乃至38)があり、サーバー1乃至3はPCCS1(20)に接続されている。サーバー4および5はPCCS2に接続されている。サーバー1乃至5のIPアドレスはそれぞれM1乃至M5である。
また、図中、PCCサーバー1(20)、PCCサーバー2(22)、サーバー1乃至5は、PCCS1(20)、PCCS2(22)、S1(30)、S2(32)、S3(34)、S4(36)、S5(38)と記した。
なお、IPアドレスとは、例えば、255.255.255.255などのように8ビットの数字が4組で表される数字の組を言うが、これに限定するものではない。
(全体の動作)
次に本発明の全体的な動作についての概略を説明する。本発明では、サーバーのサービスを受けようとするユーザは、PCCクライアントとPCCサーバーを介してサーバーと接続を図る。その際に、ユーザは自分が許可されたサービスだけをサーバーから受けることができる。
図1を参照して、ユーザAが、サーバーの利用を受ける場合を説明する。ユーザAは、サーバーであるS1からS5の中で、S1のポート25とS4のポート110の利用を許可されていたとする。ユーザAがこれらのサービスの使用を許可されていたという情報は予めPCCCa(12)にもPCCS1(20)にも登録されている。
ユーザAがサーバーへの接続を試みると、ユーザAは、S1のポート25とS4のポート110にだけ接続することができる。すなわち、PCCS1(20)は、ユーザAにS1(30)の接続を許可するものの、ポート25以外のポートの接続を許可しない。言い換えるとユーザAは、S1(30)への接続ではポート25で提供されるサービス以外のサービスを受ける事ができない。
同様にPCCS2(22)は、ユーザAがS4(36)に接続することを許可するものの、ポート110以外のポートへの接続を許可しない。もちろんユーザAは許可されていない他のサーバーへの接続はできない。
このように本発明は、サーバーに接続するユーザ毎に利用できるサービスすなわち特定サーバーの特定ポートへの接続を厳格に管理する。
(より詳細な動作)
図2を用いて、より具体的な動作について説明する。図2は図1のユーザAが利用できるサービスの説明をするために、図1から関連する部分を抜き出したものである。従って、図1と同じ要素は同じ番号を付してある。
ユーザAは、サーバーの提供するサービスのうち、アプリケーション1乃至3の利用を許可されているとする。上記の(全体の動作)での説明より受けられるサービスの数を1つ増やした場合を説明する。
図では「アプリ1」乃至「アプリ3」で表した。ユーザAはこれらのアプリケーションを端末であるTa(10)上で利用する。これらのアプリケーションはS1(30)およびS4(36)に用意されているものとする。そして、アプリケーション1および2はS1(30)に、そしてアプリケーション3はS4(36)に用意されているものとする。
PCCCa(12)には、予めユーザAが利用できるサービスの情報(40)が記録されている。具体的には、サービスが提供されるサーバーのアドレス、サービスが提供されているポートの番号、そして、サーバーに接続される前に接続すべきPCCサーバーのアドレスなどである。すなわち、サービスの情報(40)は、利用可能サービスリストといえる。暗号方法および暗号鍵に関しては後の「アプリケーション毎の暗号化」で説明する。
PCCCa(12)は、これらのサービス提供のために、ユーザAに対してサービス毎のポート(50、51、52)を開く。このポートは、個々のサービスを特定するものであるので、「M1:P1」のようにサーバーアドレスとポート番号をコロンで結んで図に示した。サービス毎のポートは、具体的な実現方法はソフトウェアによるもので、具体的なハードウェアとしては、接続ラインとPCCCa(12)のCPUとメモリである。すなわち、これらのサービス毎のポートを開設するのは、ソフトウェア的な処理による。
PCCサーバーの方では、管理すべきアプリケーションの情報を把握している。具体的にはアプリケーション1を提供するS1(30)のアドレスとポート番号および利用を許可されているユーザ名およびそのアドレスなどである。具体的には、PCCS1(20)には、アプリケーション1に関する情報(42)を有しており、そこには接続すべきS1のアドレスM1とポート番号P1、そしてアプリケーション1の利用を許可されたユーザ名と、暗号方式および暗号鍵が記載されている。アプリケーションに関する情報(42)は、許可端末リストである。
このアプリケーションの情報(42)は、PCCサーバーが管轄するサーバーが用意している全てのアプリケーションについて用意されている。具体的には、図2では、アプリケーション1乃至3についてそれぞれアプリケーションの情報が存在している。図ではアプリケーション1の情報(42)だけを示した。
通信パケットの説明を随時加えていくが、通信パケットに関しては図3に例示した。点線と点線の間は公衆回線上を示す。公衆回線の左側はPCCC側、右側はPCCS側でのパケットの様子を示す。なお、これは説明のための例示であって、これに限定されるものではない。
ユーザAは、アプリケーション1を利用しようとすると、まず、アプリケーション1へ送る通信パケットを作成する。そして、PCCCa(12)が用意したサービスのポート(50)に送信する。このときユーザAの作成するパケット(60)は、先頭に接続を希望するサーバーS1(30)のアドレスであるM1と提供を希望するサービスのポート番号P1を記し、次に自分のアドレスUaを記載し、その後ろに接続要求のコマンドを記載したパケットをつけて構成する。つまり、M1:P1は、アドレスであるとともにサービス自体をも特定する。図3に示したこのパケット(60)をPCCクライアント(12)の用意したポート(50)へ送る。すなわち、図2中でのPCCクライアントのM1:P1というポート(50)である。
なお、ここでは、接続要求のコマンドを記載したパケットの送信を例示したが、他のコマンドや要求、命令、応答、データなど必要な情報であってもよい。ポート番号を含む送り先アドレスや自分のアドレス以外の部分をペイロードと呼ぶ。また、ポート番号はパケットの先頭に記載するとしたが、パケットの別の場所に記載してもよい。
PCCCa(12)は、ユーザAから要求されたサービスがS1(IPアドレスはM1)のポート番号P1であることをユーザAの情報テーブル(40)から知り、アクセス先のPCCサーバーはPCCS1(IPアドレスはG1)であることを同時に知る。そこで、ユーザAから受け取ったパケットの先頭に、PCCS1のアドレス「G1」と自分のアドレス「Aa」をつけたパケット(61)を作成し、公衆回線に送り出す。これはいわば、ユーザAのパケットをカプセル化したことに他ならない。これらの処理も主としてソフトウェア的に行われるが、いわばカプセル通信パケットを作成する処理である。
PCCS1(20)は、自分宛のパケットとしてこのパケット(61)を受け取る。PCCS1の受取口は通信回線を常にモニタしており、いわば受信部である。
そして、自分のアドレスとPCCクライアントのアドレスの後ろにあるパケット(60)を取り出す。これはカプセルからパケットを取り出すことである。このような通信パケット取出しについてもソフトウェア的な処理で行われる。
取り出したパケット(60)のアドレスから、アドレスUa(ユーザA)、がアドレスM1(サーバーS1)のポート番号P1(アプリケーション1)への接続要求を行ってきたことがわかる。すなわち、端末識別を行う。
PCCS1(20)は、アプリケーション1の情報(42)を参照し、そこにユーザAがいれば、S1のポートP1へ、このパケット(60)を送り出す。すなわち、アドレスUa(ユーザA)は、アプリケーション1を利用できるか否かを判断し、サービスに対応するポートP1へ接続する。
S1(30)は、送られてきたパケット(60)の要求に従って処理をし、ペイロードの部分に結果を載せ、今度は逆の順序でパケットを送り出す。PCCS1(20)、PCCCa(12)も全く逆の動作をすることによって、ユーザAはS1(30)からの結果を受け取ることができる。
なお、アプリケーションの情報(42)には、ユーザAに関する情報として、ユーザ名以外にアドレスであるUaやPCCクライアントのアドレスであるAaが予め記録されている、若しくは動的に記録されることはいうまでもない。
本発明では、PCCサーバーが接続を希望するユーザを確認するため、許可を得ていない者がサーバーへ接続することはできない。また、サーバーへの接続を許可された者も、許されたアプリケーション以外の利用はできない。すなわち、情報の漏洩の少ない接続制御が可能である。
また本発明では、PCCCa(12)は、ユーザAが利用可能なアプリケーションに対応するポートをユーザAに開く。図2では、ポート(50)乃至ポート(52)である。そのため、ユーザAからは、あたかもすぐそこにサーバーやポート、若しくは提供されるアプリケーションそのものがあるように見える。すなわち、PCCクライアントは目的のアプリケーションを有したサーバーになりすましているともいえる。従って、本発明を利用するユーザーにとっては、本発明の接続制限を受けているのかいないのかわからない。許可された接続先の異なる端末を同時に比較して、一方で繋がるサービスが他方では繋がらないという方法でなら、本発明の接続制限を受けているか否かを判断できる。
(アプリケーション毎の暗号化)
上記の説明では、カプセル化に際し、暗号化を行わず、パケット(60)の部分がそのままの形で公衆回線(500)に送られる態様の説明を行ったが、公衆回線上での盗聴を困難にするために、暗号化することもできる。
本発明では、ユーザは自分が受けることのできるサービス毎にPCCクライアントに接続の口を有する。従って、サービス毎に暗号化の方法若しくは暗号の鍵を変更することができる。
図2を再度参照して、PCCCa(12)には、ユーザAの情報として、サーバーのIPアドレス、サーバーのポート番号、転送先PCCサーバーのIPアドレスの情報(40)を持たせているが、これに暗号方法および暗号鍵の情報を持たせる。PCCCa(12)は、ユーザAの要求するサービス毎に、決められた暗号方法および暗号鍵で、アドレス以外の情報を暗号化する。図3では「接続要求」すなわち、ペイロードの部分に相当する情報である。
図3を参照して、ペイロードの部分を暗号化したパケットは(62)の様になる。これをカプセル化してパケット(63)の状態で公衆回線上へ送信する。ペイロードの部分を暗号化したパケットはサービス毎に異なる暗号鍵で暗号化することができ、これをサービス暗号化と呼ぶ。これはPCCCa(12)のCPUとメモリによるソフトウェア処理によって実現される。
なお、図3中、暗号化された部分は四角で囲んで示した。以後、暗号化されたパケットおよびパケットの部分は四角で囲むことで表す。
このパケットを受け取ったPCCS1(20)は、カプセルから上記で説明したパケット(62)の内容を取り出して、該当するアプリケーション(ポート番号)へ送る前に、暗号化された部分を復号してパケット(60)を得たのちサーバーに送る。
ここで、PCCサーバーのアプリケーションの情報にあるユーザのリストに、PCCクライアントにある情報に相当する暗号化の方法と暗号鍵の情報が、記憶されている。そして、上記の復号はこの情報に基づいて復号される。図2では、PCCCa(12)の持つユーザAの情報(40)にある暗号方式と鍵に対応する情報はPCCS1(20)のアプリ1の情報(42)にもある。図2では、暗号方式(E1)、鍵(Key10)がこれに相当する。これは上述したPCCCa(12)のサービス暗号化とは逆の処理であるのでサービス暗号復号化と呼ぶ。
このようにして、アプリケーション毎に通信できるユーザが制限される上に、アプリケーションを利用するユーザ毎に暗号方式と暗号の鍵を設定することができる。これは、盗聴に対するセキュリティーをより強固なものにする。
(カプセル化の暗号化)
上記で説明したように、PCCクライアントとPCCサーバーの間ではパケットがカプセル化されている。そこで、従来のVPNで行われていたようにカプセルの暗号化は本発明でも用いることができる。
再度図2を参照して、PCCCa(12)は、PCCS1(20)およびPCCS2(22)と接続する必要がある。従って、PCCS1(20)およびPCCS2(22)との間で、鍵のやり取りを行う必要がある。この間の暗号の方式は特に限定されるものではなく、共通鍵方式、公開鍵方式のいずれも使うことができる。
図2中でPCCCa(12)の(53)、(54)は擬似的な出力ポートである。これらの出力ポートは公衆回線への接続ポートであり、ソフトウェア的に処理されることで開設される。なお、この点はすでに説明した(より詳細な動作)や(アプリケーション毎の暗号化)でも適用される。
またPCCS1(20)およびPCCS2(22)の(55)、(56)はPCCCa(12)用の擬似的な入力ポートである。PCCサーバーは、接続してくる相手がPCCCa(12)だけではない。そこで、他のPCCクライアントに対してはそれぞれ別々の擬似的な入力ポートを構築する。これは上述した受信部の一環としてソフトウェア的に開設される。
PCCクライアントとPCCサーバーはそれぞれ複数の相手と接続する可能性があるため、PCCクライアントは擬似的な出力ポートの数だけ、またPCCサーバーは擬似的な入力ポートの数だけ暗号方式と暗号鍵を管理するテーブルが必要である。図2では(44)と(46)で示した。これらの間の暗号方式と暗号鍵作り方はすでに知られた公知の方法を用いることができる。
PCCクライアント側の管理テーブル(44)には、接続するPCCサーバー毎のアドレスと暗号方式、および暗号鍵が記載してある。図2ではPCCCaが公衆回線(500)を介して接続するための接続ポート(53)と(54)のために有する管理テーブル(44)を例示してある。PCCCa(12)は、PCCS1(20)とPCCS2(22)に接続することができるので、それぞれのIPアドレスであるG1とG2が記載してある。またPCCS1(20)とPCCS2(22)との通信には暗号方式をE3を使い、それぞれの暗号鍵がKey40とKey41であることを記載してある。
一方PCCサーバー側でも対応する管理テーブル(46)がある。図2では、PCCS1(20)の場合を例示した。PCCS1(20)は図1で示すように、PCCCa(12)およびPCCCb(16)と接続するので、それぞれのアドレスであるAaおよびAbとそれに対応する暗号方式および暗号鍵の情報が記載される。PCCS2(22)の管理テーブルについては省略した。
なお、PCCサーバーが使用するカプセル化の際に併用する暗号方式および暗号鍵については、接続要求のある全PCCクライアントに対して重複して使ってもかまわない。すなわち、PCCサーバーは接続する全ての相手に対するカプセル化に1つの暗号方式と暗号鍵を用いても構わない。
ポート(53)およびポート(54)はそれぞれポート(55)およびポート(56)との間で暗号の方式と鍵を決めてある。つまり、擬似的な出力ポート(53)から送信されたパケットは、カプセル化されていると共に、自分のアドレスより後ろ側を決められた方法と鍵で暗号化する。図3では、パケット(64)がその状態を示す。これにPCCサーバーのアドレスG1と自分のアドレスAaを付してカプセル化したパケット(66)を公衆回線に送信する。なお、この暗号化はPCCCa(12)のCPUとメモリによってソフトウェア的に処理されることで実現される。カプセル化してなおかつ暗号化するのはいわゆるトンネリングの技術であるので、この処理は、いわばトンネリング暗号化である。よって、管理テーブル(44)、(46)はトンネリング暗号管理テーブルと呼ぶ。
PCCサーバーの入力ポート(55)で受信されたパケットは、カプセル化されたアドレスの部分を取り外し、パケット(64)を得る。さらに暗号化された部分を復号しパケット(62)を得る。これも同様にPCCS1のCPUによるソフトウェア処理であり、上述したトンネリング暗号化に対応するトンネリング暗号復号化である。
同様に、PCCS1(20)およびPCCS2(22)のポート(57、58、59)も擬似的な出力ポートで、ペイロードの部分をアプリケーションの情報(42)に記載してある暗号方式および暗号鍵に従って復号してからそれぞれ所定のサーバーに送信する。すなわち、最終的にパケット(62)からパケット(60)を得て、所定サーバーの所定ポートに送信する。
(フローの説明)
図4には、PCCクライアントとPCCサーバーの動作のフローを上記(カプセル化の暗号)を例にとって示す。PCCクライアント(12)はユーザAからのサービス要求を待っている(1002)。サービス要求があったら、ユーザAの情報(40)を参照して要求されたサービスは許可されたサービスかどうかを判断する(1004)。このとき、PCCクライアント(12)はパケット(60)を受信することになる。
もし要求されたサービスが、ユーザAの情報(40)に無かったら、そのまま公衆回線に送信してもよいし、破棄してもよい(1021)。望ましくは、相手先サーバーがユーザの情報(40)に掲載されていない場合は破棄するのが望ましい。不特定の相手に、ユーザが接続を希望した接続先に関する情報を提供することになりかねないからである。
情報(40)に掲載されたサービスである場合は、情報(40)の暗号方式(E1)および暗号鍵(Key10)に従って、ペイロードの部分を暗号化する(1006)。このときにはパケット(62)が作られる。
その後、送信するPCCサーバー(20)との間の暗号方式(E3)と共通鍵(Key40)で暗号化する(1008)。この時のパケットはパケット(64)のごとくである。そして、カプセル化を行い公衆回線へ送信する(1010)。最終的にはパケット(66)になる。
PCCサーバー側では、自分宛のパケットの取得のルーチンは別途他の処理と並列して走っている。そこで、自分宛のパケットを受け取ったものとする(1020)。PCCサーバーでは、まずカプセル化を解除する(1022)。カプセル化解除によってパケット(64)を得る。
次にカプセルの中身を復号化する(1024)。ここでは、送信元がPCCクライアント(12)であることがアドレス(Aa)からわかっているので、カプセル化の暗号方式および暗号鍵を情報(46)から取得して復号化する。この復号化によってパケット(62)を得る。なお、カプセルの中身を復号化するのは図2のPCCサーバーの擬似的な入力ポート(55もしくは56)としているが、この入力ポートを介したパケットの処理という意味であって、実際はPCCサーバーが行う処理である。
パケット(62)が得られると、接続要求されたサーバーS1(アドレスはM1)とポートP1がわかるので、PCCサーバー(20)が管轄するサーバーか否かを判断する(1026)。例えば、PCCS1はS4やS5は管理していないので、管轄していない。管轄するサーバーでない場合は、破棄するかまたは接続対称でない旨の回答を行ってもよい(1036)。
また、サーバーとポート番号がわかるので、対応するアプリケーション(アプリ1)を決めることができ、アプリケーション情報(42)を参照して、接続要求をしたユーザは許可されたものか否かを確認する(1028)。許可されていないユーザであった場合は、破棄するか、もしくは接続は許可されない旨の回答をおこなってもよい(1038)。
許可されたユーザであった場合は、アプリケーションの情報(42)を参照して、ペイロードの部分を復号化する。この複合化によってパケット(60)を得ることができる。この処理は、擬似的な出力ポートに関わる部分(図2では57、58、59)で行われるように図示したが、この出力ポートを介するパケットの処理という意味であって、実際はPCCサーバーが行う処理である点は、入力ポート(55もしくは56)の場合と同じである。最後に所定のサーバーの所定ポートへ送信する(1032)。
なお、アプリケーション毎の暗号化とカプセル化の暗号は、いずれか一方だけを行ってもよいし、両方行ってもよい。
本実施の形態では、ユーザAからサーバーS1への接続は、カプセル化したパケットでやり取りを行っている。これは公衆回線上にあたかもプライベートな専用回線を作っているようなものであるため、VPNと似ている。しかし、VPNがLAN間の接続するために多くの利用者が通れるトンネルを作っているのに対して、本発明では、個々のユーザが自分が許可されたアプリケーションだけに接続するための細いトンネルを数多く作っている点で違いがある。
(実施の形態2)
実施の形態1では、アプリケーション毎の暗号方式と暗号鍵についてはすでにPCCクライアントとPCCサーバーに予め用意されているとした。しかし、ユーザの数が増えるとPCCクライアント側の暗号に関する情報を更新するのは大変な作業となる。そこで、PCCクライアントが公衆回線を使って接続要求した際にそれぞれのアプリケーション毎に暗号方式と暗号鍵を決める方法を説明する。
図5にはPCCクライアントであるPCCCa(12)が公衆回線500を介してPCCサーバーであるPCCS1(20)に接続する前の状況を示す。PCCCa(12)側とPCCS1(20)側が有するトンネリングのための暗号方式と鍵の情報であるトンネリング暗号管理テーブル(44)と(46)には何も記録されていない。
端末であるTa(10)とPCCCa(12)の間にはすでにアプリケーション1乃至3に関わる接続関係はできている。これは、PCCCa(12)がTa(10)に接続された時点で確立される。もちろん、PCCCa(12)が実際にPCCサーバーとの接続を確立してから、Ta(10)にアプリケーションを表示させるようにしてもよい。
図6には、PCCCa(12)とPCCS1(20)との間で行われる、やり取りのパケットや、利用可能サービスリストである情報(40)やトンネリング暗号管理テーブルである情報(46)などの状態を例示する。また図7には通信開始時のフローを示す。右側はPCCS1(20)を左側はPCCCa(12)のフローを示す。
図6および図7を参照して、PCCCa(12)がPCCS1(20)へ、自分に接続しているユーザ名とIPアドレスを送信する(1050)。図6の場合ユーザ名はユーザAでIPアドレスはUaである。PCCS1に送られるパケットは図6のパケット(68)のようなパケットになる。
PCCS1(20)では、PCCCa(12)からのパケットを受信し(1070)、ユーザA(アドレスUa)は、アプリケーションの情報のいずれかにあるか否かを調べる(1072)。アプリケーションの情報とは許可端末リスト(42等)である。PCCS1(20)が管轄しているサービスは複数あり、そのサービスに対応するアプリケーション情報の中のいずれかのアプリケーション情報にユーザAが登録されていれば、登録されているものと判断する。
一方、いずれのアプリケーションに関する情報にもユーザAがいなければ接続を許可できない相手からの接続希望であるので、破棄するかまたは接続できない旨の回答を行う(1086)。
アプリケーション情報にユーザAがあれば、トンネリングに用いる暗号を決める。ここではDH変換による共通鍵を求めることにした(1054および1074)。しかし、予め公開鍵方式の秘密鍵と公開鍵があれば、公開鍵を持っているほうが、共通鍵を決めて相手に送信してもよい。ここではDH変換によって得た鍵を用いた暗号方式をE3とする。図6では、「DH変換」で表した。
トンネリングに用いる共通鍵が決まったら、PCCCa(12)およびPCCS1(20)間の暗号鍵としてトンネリング暗号管理テーブル(44)および(46)に記録する。図6では、トンネリング暗号管理テーブル(44)に相手のアドレスG1と暗号方法を示すE3と暗号の鍵がKey1である点が記録されたことを示す。また、PCCS1(20)側ではトンネリング暗号管理テーブル(46)として、相手アドレスであるAaと、同じく暗号方法を示すE3と暗号の鍵がKey1である点が記録されたことを示す。
PCCS1(20)は、共通鍵を用いて要求するサービス内容を提示するようにPCCCa(12)に求める(1076)。この時のパケットは図6のパケット(70)である。
通信を受け取ったPCCCa(12)は復号し内容を解読する(1056)。そして、PCCS1(20)に対して要求するサービスを共通鍵で暗号化し送信する(1058)。この時のパケットは図6のパケット(72)である。要求するサービスとは、ユーザAが利用を許可されたサービスのうち、PCCS1(20)が提供する予定のサービスである。PCCCa(12)はユーザAの利用可能サービスリスト(40)からそれを知る。図6では、PCCS1(20)へ連絡すべきサービスとして、M1:P1とM1:P2があり、それを通知しているところを示す。
PCCS1(20)は、これを受け取り復号化し解読する(1078)。そして受け取ったサービスは確かに許可されたものかどうかそれぞれのアプリケーションの情報、すなわち許可端末リストに従って確認する(1080)。もし許可されていないサービスがあれば、その旨通知する(1088)。
PCCS1(20)は、許可されていることを確認できたら、サービス毎に暗号方式と暗号鍵を決め、PCCCa(12)に送信する(1082)。このときのパケットは、図6のパケット(74)になる。
このパケットを受信したPCCCa(12)は復号化し、内容を解読してユーザAの利用可能サービスリスト(40)にあるそれぞれのサービスの情報に暗号方式と暗号鍵を記録する(1064)。また、PCCS1(20)はアプリケーションの情報である許可端末リスト(42)にもこれを記録する。
同じ手続きをPCCS4とも行うことで、ユーザAの情報とトンネリングに使う暗号情報(44)および(46)とアプリケーションの情報(42)が図2のごとく完成する。本実施の形態のように、アプリケーション毎の暗号方式と暗号鍵を通信のたびに変えることができるようにすることで、より一層セキュリティが高くなる。
(実施の形態3)
図8に第3の実施の形態について説明する。本発明の基本的な構成は実施の形態1で示した。本実施の形態では、公衆回線を用いたときの「なりすまし」を防止するために、認証手続きを行う場合について説明する。よって、図8では図1に認証局(9)が追加される。
図9を参照し、PCCクライアントであるPCCCa(11)と認証局(9)とのやり取りについて説明する。PCCCa(11)と認証局(9)の間の通信で用いる暗号は、特に限定するものではないが、ここでは公開鍵方式による暗号を用いた場合を説明する。PCCCa(11)は、認証局(9)のアドレスTを持っており、認証局(9)は、ユーザ名、アドレス、ユーザの公開鍵、ユーザ毎の利用可能なサービスに関する情報を有している。サービスに関する情報とは、サーバー、ポート番号、PCCサーバーのアドレスなどを含む利用可能サービスリストである。
PCCCa(11)は、電源が投入されると、ユーザ名(81)、自分のアドレス(82)、最初の共通鍵(図ではKeyCと記載)などを自己の秘密鍵で暗号化し、暗号化していないユーザ名(83)をつけて認証局(9)に送る。公開鍵暗号方式なので、この暗号化された内容はPCCCa(11)の公開鍵でなければ開かない。具体的にはパケット(80)のような構成が例として挙げられる。
認証局(9)では、ユーザ名(83)を見て、予め用意されているユーザリスト(これを「認証許可リスト」と呼ぶ)からユーザの公開鍵(84)を選択し、暗号を解く。解いた内容に書かれたユーザ名(81)と暗号化されていなかったユーザ名(83)が一致したら、正しいユーザからの送信であると認定する。なぜなら、登録されたユーザの公開鍵で復号できたということは、秘密鍵の持ち主が暗号化したものとみなせるからである。すなわち、このパケットを送ってきたのは、確かに送り元の端末であることを確認する。また、認証許可リストにない者からの認証要求には応えない。
認証局(9)は、ユーザ名、アドレス、最初の共通鍵を認証局の秘密鍵で暗号化する。これは認証局の公開鍵でないと開かない。認証局は特殊なサイトであり、その公開鍵はサーバーを管理する特定の者にしか通知されないようにしておく。つまり、一般のユーザにとっては、暗号を解くことができない情報になる。すなわち、これは認証書(86)となる。なお、認証書(86)に含める内容はユーザ名、アドレスなどを例示したが、これに限定されるものではない。
認証局(9)はさらに、そのユーザが利用を許可されているサービスのリスト(利用可能サービスリスト)と共に、これらの情報をさらにユーザの公開鍵で暗号化する。従って、この情報は秘密鍵を有するユーザだけが解くことができる情報となる。認証書と利用可能サービスリストを含めて暗号化したものを認証パックと呼ぶ。そして、これをPCCCa(11)宛に送信する。具体的にはパケット(88)である。
PCCCa(11)では、受け取った情報を自分の秘密鍵で解く。そして、PCCCa(11)は、認証書と利用可能なサービスリストを得る。このようにすれば、PCCCa(11)は、予め許可されたサービスリストを持っている必要はなくなるし、また許可されたサービスの更新も、認証局(9)を通じて容易にできる。この認証書等の取得はPCCCa(11)のCPUによってソフトウェア処理によって行われる。
次にPCCCa(11)は、サービスリストを見て、接続可能なPCCサーバー宛に、認証書を送る。すなわち認証の要求を通知する。図10を参照して、PCCサーバーであるPCCS1(19)に接続を試みる場合を説明する。PCCCa(11)がPCCS1(19)へ送信するパケットは、例えばパケット(90)に示す形となる。すなわち、PCCS1(19)のアドレスであるG1と自分のアドレスであるAaとペイロードにあたる部分である。ここには、ユーザ名であるユーザAと認証書(86)が記載されている。
PCCS1(19)は受け取った認証書(86)を認証局の公開鍵で解く。正しく解ければ、送信者は、認証局が認証したユーザと認定できる。また、パケット(90)に記載してあるユーザ名と復号された認証書に書かれたユーザ名が同じであれば、送信者は確かに認証局に認証を受けたユーザであるとみなせる。
また、認証書(86)には最初の共通鍵もついているので、この共通鍵に基づいて、PCCS1(19)からの伝達事項をPCCCa(11)に安全に送信することができる。具体的な要求としては、ユーザが許可されているサービスのリストの送付や、暗号方式の通知や暗号鍵の更新などが上げられる。
PCCS1(19)は、PCCCa(11)が送付したサービスリストと自らが保持しているユーザに関する情報を比較対照してさらに確認作業をすることができる。また、サービスごとに使用する共通鍵を変えてもよい。
以上のようにPCCクライアントとPCCサーバーの間で認証作業が終了したら、共通鍵を用いて実施の形態1や2と同じように、通信が可能になる。
本実施の形態では、ユーザが使用できるサービスのリストは認証局からユーザに認証書作成の際に送付される。従って、予めPCCS1がユーザAの使用が許可されたサービスを知っていなくても認証書にサービスリストが入っていれば、PCCS1はそれを信じてアプリケーションに関する情報40のリストを更新することができる。
また、本実施の形態では、最初の共通鍵を認証書に含めるようにしたが、図10のPCCCa(11)とPCCS1(19)との通信をDH交換から始めれば、最初の共通鍵は不要となる。また、最初の共通鍵は認証局が与えるようにしてもよい。
(実施の形態4)
本実施の形態では、サーバー側のネットワークが多重化されている場合について説明を行う。図11は、本実施の形態の構成を示す。図11は図1の構成で示したPCCサーバーによって管轄されるネットワークが多重化されている状況を示す。
サーバーB1(106)には、サーバーB2(108)とサーバーBs2(112)が接続されている。サーバーB2(112)はさらにサーバーBs1(110)が接続されている。サーバーBs1(110)には、S1(30)とS2(32)の2つのサーバーが接続されている。また、サーバーBs2(112)にはサーバーS3(34)が接続されている。
すなわち公衆回線(500)側から見ると、B1(106)を経由して通信することができる外側ネットワークセグメント(100)があり、その内側にB2(108)を経由して通信することができる内側ネットワークセグメント(102)が存在する。これらのネットワークセグメントは通常はファイアウォール等により管理されており、VPNはB1と同じ位置に設置される。
PCCサーバーが管理するネットワークの多重化は、より多くのサーバーの接続の要求という局面で必要になる。しかし、実施の形態1および2に開示した発明だけでは、ユーザーからのパケットは、内側ネットワークセグメントを管轄するサーバー(図11の場合はB2)を、突破して所定のサーバーに到達することができない。本実施の形態の目的は、このような場合でも所望のサーバーにパケットを到達させるための発明を開示することである。
なお、ユーザと接続されているサーバをバンドルクライアント(Bc)、サーバと接続されるサーバをバンドルサーバー(Bs)、BcとBs間で通信を中継するサーバーをバンドル(Bd)と呼ぶ。また、外側ネットワークセグメントを管轄するバンドルをBdo、内側ネットワークセグメントを管轄するバンドルをBdiとする。図11では、B1(106)はBdo、B2(108)はBdiである。
本実施の形態では、実施の形態1および2で示したPCCサーバーの有するアプリケーション毎の情報とは別にサーバー側のネットワーク内での通信経路制御を行うためのデータベースを別に用意する。この情報によってサーバー側のネットワーク内での通信経路を通過させる。経路制御のためのデータベースはDBに番号を随時付加して表す。
図11において、簡単のために、サーバーであるS1(30)は2つ、S2(32)とS3(34)はそれぞれ1つのサービスを提供しているとする。それぞれを識別するポートをP1およびP2とする。すなわち、B1(106)は自身のネットワークの中に、M1:P1、M1:P2、M2:P1、M3:P1という4つのサービスを有する。
(全体的な動作の流れ)
図11を参照して、データベースDB1(114)は、B1の有するデータベースである。ここには、B1(106)が管轄する4つのサービスに対して要求があったとき、その要求を転送すべき相手先が記録してある。
また、DB2(116)は、B2の有するデータベースである。ここには、B2の管轄する2つのサービスに対して要求があったときに、その要求の転送先が記録されている。
例えば、B1(106)に対して、M1:P2のサービスの要求があったとすると、B1はDB1(114)を参照して、このパケットをB2(アドレスは「Gb2」)へ転送する。このようにすると、B1はB2のネットワークの内部構成を知る必要がない。B2もネットワーク内の通信情報のデータベースであるDB2(116)を参照する。図11では、B2(108)は受け取ったパケットのサービスを特定する情報であるM1:P2を見て、Bs1(アドレスは「G1」)へパケットを転送する。DB1やDB2をサービス対応リストと呼ぶ。
さらにこのパケットを受け取ったBs1(110)は、自身の有するアプリケーション情報(図2の42すなわち許可端末リストに相当)に照らし合わせ、許可されたユーザーからの要求であることを確認し、所定の暗号方式と鍵で復号化した後、所定のサーバーのポートへ送信する。
Bcは実施の形態1乃至3で示したPCCクライアントと同じものである。また、Bs1、Bs2は後に明確になるように、パケット化の暗号を解かない点を除けば、実施の形態1乃至3のPCCサーバーと同じである。
(より詳細な説明)
図12には、本実施の形態で使われるパケットを示した。図11と12を参照してより詳細な説明を行う。
ユーザAがS1のポートP1のサービスを受けようとした場合について説明を進める。ユーザAがTa(10)からサービスを特定するM1:P1へサービス提供のコマンドを送る。ペイロードの内容は「com.」と示した。パケット(120)がこれにあたる。Bc(104)は、実施の形態1乃至3のPCCクライアントと同じ機能を有しており、指定されたアドレスへユーザAは接続を許可されているか否かを自身の有するユーザの情報(図2の40すなわち利用可能サービスリストに相当)を参照して確認する。
実施の形態1乃至3では、ユーザの情報には転送先のPCCサーバーのアドレスが記載してあったが、ここではバンドルのアドレスが記載されたものになる。また、サービスを許可されているということと、所定ポートへ接続できるということはここでは同意である。
Bcは上記の確認ができたら、ペイロードの部分をアプリケーション毎の暗号方式と暗号鍵によって暗号しパケット(122)を得る。さらにトンネリングのための暗号をパケット(122)に行いパケット(124)を得る。これに自身のアドレスであるAaと送信先のバンドルであるB1のアドレスGb1をつけてパケット(126)を得る。これを公衆回線に送信する。
B1(106)はこれを自身宛のパケットとして受け取る。そして、トンネリングのための暗号を復号し、パケット(128)を得る。パケット(128)からは、要求されているサービスがM1:P1であることがわかる。すなわちサービスを識別する。B1(106)はDB1(114)を参照して、転送アドレスGb2を得る。そこで、先頭アドレスをGb2に書き換えたパケット(130)をB2に送信する。これをセクションアドレスの書き換えと呼び、B2への送信をセクション内送信と呼ぶ。
B2は、パケット(130)を受け取り、DB2(116)を参照し、サービスM1:P1はアドレスG1のBs1に送信することを知る。B2の受信は、公衆回線からの直接受信ではない。そこでこれをセクション内通信受信という。そして先頭アドレスをG1に書き換えたパケット(132)をBs1に送信する。ここでのアドレス書き換えと送信もセクションアドレスの書換えおよびセクション内送信である。
Bs1は実施の形態1乃至3で説明したPCCサーバーと同じである。ただし送られてくるカプセル化されたパケットは、パケット化の暗号はすでに復号済みのものが送られている。Bs1はパケット(132)のカプセル化を解除し、アプリケーション毎の暗号鍵を用いてペイロード部を復号化する。このようにして得たパケット(134)をS1へ送信する。
以上のようにすることで、多重化されたネットワークでもサービス毎の専用回線を確立することができる。
(フローチャートの説明)
図13には、本実施の形態のバンドルであるBdの動作のフローを示す。これはBdoの動作を示すフローである。
自分宛のパケットを取得したら(1040)、カプセル化を解除する(1042)。これはパケット(126)から自分のアドレスGb1と、送信元のアドレスAaを削除することである。次に共通鍵を用いて残りの部分を復号化する(1044)。これはトンネリング暗号の復号化である。B1(106)とBc(104)の間は実施の形態1乃至3で説明したPCCクライアントとPCCサーバーと同様に、共通鍵によるセキュアー通信路が確立されている。この処理によって送られてきたパケットはどのアプリケーションを要求したものかが分かる。
次にDBを参照して、要求されたアプリケーションはどこに転送すればよいかを判断する。もし、要求されたアプリケーションがなければ、破棄もしくは対応できない旨を通知する(1046乃至1048)。転送先がわかれば、転送先アドレスに送信元アドレスであるAaを付加し、カプセル化したパケット(130)を作って、そこに転送する(1050)。
バンドルはこのようにしてパケットを後方のサーバーに転送する。これによって、バンドルは後方のネットワークの構成を知る必要はなくなり、管理は容易になる。
なお、内部ネットワークセグメントであるB2(108)では、図13の(1042)および(1044)の処理はスキップする。トンネリングの暗号は、すでにB1(106)が復号しているからである。
また、Bs1(110)やBs2(112)は実施の形態1乃至3で説明したPCCSと同じフローで動作するが、トンネリングの復号は不要なので、その部分は不要である。具体的には図4の(1026)以下の処理を行えば足りる。
(実施の形態5)
実施の形態4では、サービスを提供するサーバS1、S2、S3のIPアドレスであるM1、M2、M3などとポート番号を指定することでサービスを特定していた。そうすると、利用者の端末Ta(10)などからそのIPアドレスが盗まれたり、流出したりする事故があったときにサーバのIPアドレスが知れてしまうことになる。特に利用者の端末の数が多くなればなるほど、サーバのIPアドレスが流出する可能性は高くなる。
そこで、サービスの特定の仕方としてサーバーのアドレスとポート番号の代わりにサービスIDといういわばサービスを表すシンボルを使う。このサービスIDを用いると直接サーバのIPアドレスやポート番号が漏れる心配がなくなる。
本実施の形態では、図11においてM1:P1などで表していたサービスをhtt1といったサービスIDで表す。具体的には、サーバS1のサービスであるM1:P1をhttp11、M1:P2をhttp12、サーバS2のサービスであるM2:P2をhttp22、サーバS3のサービスであるM3:P1をhttp31というサービスIDで置き換えた。
図14に本実施の形態の構成を示す。DB1とDB2以外は実施の形態4で示した図11と同じである。
DB1(140)やDB2(142)はサービスを特定するために新たに導入されたサービスIDも情報として含まれる。これによってユーザは、M1:P1といった指定方法によって特定されるサービスを、http11といったサービスIDで指定することができる。
ユーザからの要求がhttp11で表されるサービスM1:P1であったとして説明する。B1(106)は、ユーザから送られてきたパケットのサービスIDを取り出し、DB1(140)を参照して、次の転送先であるB2のアドレスGb2を得る。B2(108)は、送られてきたパケットのサービスIDがhttp11であることを知り、DB2(142)を参照して、次の転送先であるBa1のアドレスG1と、http11のサービス番号はM1:P1であることを知る。Ba1は、DB2を参照した時点で、サービスIDからサービス番号に変換を行う。いわば、サービスを表すシンボルをアドレスへ書き換える。
図15には、これをパケットの動きで説明する。ユーザが使用するのは、サービスIDなので、ユーザが作成するパケット(150)のヘッダにはサービスIDである「http11」が記載される。PCCCはコマンド部分を暗号化し(152)、さらに全体を暗号化し(154)、自分のアドレス(Aa)と送り先のPCCSのアドレス(Gb1)をつけて公衆回線上に送り出す。
PCCS側では、受け取ったパケットを復号化し、サービスIDを確認する(158)。そこでサービスIDであるhttp11をDB1(140)で参照し、自分のアドレスであるGb1を次の転送先B2のアドレスGb2に書き換えて送り出す(160)。
B2(108)は、DB2(142)を参照してサービスの特定をシンボルであるhttp11からアドレスとポート番号であるM1:P1に書き換える。さらに、自分のアドレスであるGb2を、次の転送先Bs1のアドレスG1に書き換えて、送り出す(162)。以下Bs1(110)が、不要なヘッダを削除し、サーバS1(アドレスはM1)のポート1番にパケット(164)を送るのは実施の形態4の場合と同じである。
図16には、同じくフローでの説明を行う。パケットを取得し(1060)、復号化(1064)し、データベースを参照(1066)し、サービスがDBにあるか否か(1068)の判断までは図13と同じである。但し、サービスがDBにあるか否かの判断はサービスID、若しくはサーバのアドレスとポート番号で判断する。
サービスがDBにあった場合は、さらに具体的なアドレスの記述がDBにあるか否かを判断する(1070)。もし具体的なアドレスの記載があれば、サービスIDを具体的なアドレスに書き換える(1072)。例えば、上述したようにhttp11というサービスIDをM1:P1というアドレスとポート番号に書き換える。そして次の転送先へ転送する(1072)。もし、具体的なアドレスがDBに記載されてなかったら(1070でNの分岐)、そのまま次の転送アドレス先に転送する。
なお、内部ネットワークセグメントであるB2(108)では、図16の(1062)および(1064)の処理はスキップする。トンネリングの暗号は、すでにB1(106)が復号しているからである。
また、Bs1(110)やBs2(112)は実施の形態1乃至3で説明したPCCSと同じフローで動作するが、トンネリングの復号は不要なので、その部分は不要である。具体的には図4の(1026)以下の処理を行えば足りる。
このようにサービスを特定するのにサービスIDという代表文字もしくは数字、記号といったシンボルを用いることで、サービスを提供するサーバのIPアドレスが、流出することをより強固に防ぐことができる。
(実施の形態6)
本実施の形態では、PCCクライアントのIPアドレスが自動取得となる場合について説明する。本発明ではユーザは自分の端末およびPCCクライアントを移動端末として持ち歩き、移動中もサービスが受けられる。特に、接続を切断することなく、継続的な接続を要求するサービスでは、接続が切断された場合の処理を、PCCクライアントとPCCサーバーが吸収してしまう。従って、ユーザーとサーバーは実際に通信が切断されたことを意識せずに、サービスの利用と提供を行うことができる。
図17に本実施の形態の構成を示す。ユーザーの端末であるTa(10)にはPCCクライアントであるPCCCa(11)が接続されており、これが公衆回線500に接続されている。公衆回線500を通じてPCCサーバーであるPCCS1との間でサービス毎の専用回線が形成され、実際にサービスを行うサーバーであるS1(30)と接続されているのは、実施の形態1乃至3で説明した場合と同じである。なお、本実施の形態においても、認証局を利用するが、認証局については、図示を省略した。
図17(a)を参照して、PCCCa(11)は、自身のIPアドレスの取得に際して、近郊のホットスポット1(170)に通信をし、アドレスを取得する。これはPCCCa(11)のCPUとメモリで行われるソフトウェア処理で実現する。ホットスポット1(170)は通信管理サーバー(172)が接続されていて、IPアドレスの使用状況を監視し、アドレスの重複がないように常時管理している。
アドレスを取得したPCCCa(11)は、実施の形態2で示した認証を行い、公衆回線を使ってPCCS1(19)とサービス毎の専用回線を確立する。ユーザーはホットスポット1(170)と通信可能な間は割り当てられたIPアドレスを用いて公衆回線と接続することができる。例えばここでは、ユーザAは、サーバS1と通信を行う。すなわち、PCCCa(11)は端末Ta(10)に対してM1:PXで表されるサービスのポートを開いている。同様にサーバS1からはPCCS1がUaというアドレスのユーザと接続を行っているように見える。
図17(b)を参照して、ユーザが今移動中で、ホットスポット1(170)との通信が困難になった場合は、PCCCa(11)と、ホットスポット1(170)との通信は切断される。
この場合、PCCCa(11)とPCCS1(19)との間の通信は切断される。しかし、ユーザの端末(10)はPCCCa(11)と通信しており、S1(30)はPCCS1(19)と通信を行っている。従って、端末(10)とS1(30)は、お互いの間の通信が切断されたことを検知しない。相手側からの返信に時間がかかっているだけと認識できるだけである。すなわち、永続的な接続を要求するサービスであっても、継続して受けることができる。
図17(c)を参照して、PCCCa(11)は、別のホットスポット2(174)と通信を行い、アドレスを取得しこちらへ切り替える。すなわち、PCCCa(11)が使うアドレスは変わることとなる。図17では、PCCCaのIPアドレスはAaからAxに変わった。
ホットスポット2(174)と通信を行い新たなアドレスを割り当てられたPCCCa(11)は、再度認証の手続きを行い、PCCS1(19)とサービス毎の専用回線を確立する。
この間、ユーザの端末Ta(10)はPCCCa(11)と常にM1というポートで繋がっており、またサーバS1はUaというユーザと接続を行っているように見える。以上のようにホットスポットの切り替えが行われても、ユーザの端末Ta(10)とサーバS1(30)は本発明のPCC方式の通信環境下で、高いセキュリティーの通信を継続して行える。
(フローの説明)
図18は、PCCクライアント側の動作を表すフローである。図17の場合では、PCCCaの動作に相当する。PCCCa(11)は、使用可能なアクセスポイントを探す(1080)。これは、電界強度が強く、使用を許可されたスポットである。電界強度が強く、良好な受信状態を得たとしても使用を許可されていないスポットは使えない。ここではホットスポット(170)が使用を許可されたスポットであるとする。そして、ホットスポット1(170)を解して通信局(172)からアドレスを取得する(1082)。
図17には図示していないが、認証局との間で実施の形態2で説明した認証作業を行い認証書を得る(1084)。この認証に失敗した場合は再度アクセス可能なホットスポットを探しにいく(1084のN分岐)。認証をもらえたら、この認証書を持って、PCCS1へ接続を図る(1086)。
通信が開始できたら、通信処理を始める(1090)。通信処理には、サービス毎の鍵の設定を受けたり、所定のパケットの送信や受信が含まれる。この動作中ホットスポットとの間での電界強度Eが所定の値(Th)より小さいか否かをモニタする(1072)。これが所定の値以上であれば、通信を続ける(1088)。
もし、電界強度Eが所定の値(Th)以下であれば、現在与えられているアドレスでの通信をあきらめて、一旦公衆回線との接続を切る(1094)。そして、また接続可能なホットスポットを探索しにいく(1080)。図17では、ホットスポット2との接続を示す。
そして再度アドレスの取得を行う(1082)。図17では、最初のホットスポット1(170)への接続で取得したアドレスはAaであった。次に接続したホットスポット2(174)では、Axというアドレスに変わっている。
次にまた認証局に対して認証を行うが(1084)、ここでは、先に接続していた際のアドレスであるAaと現在取得したアドレスであるAxの両方を認証書に書き込んでおくのが好ましい。次にPCCS1へ接続した際に、PCCS1がどのユーザーとの接続を変更したのかが、わかるためである。
この処理では、通信を終了するか否かをモニタしておき(1088)、通信を終了する場合は、終了処理を行い(1096)、終了する。
図19には、PCCS1での動作のフローを表す。PCCS1は自分宛のパケットを受け取り(1110)、認証局の公開鍵で復号化する(1112)。通信相手の認証を確認できたら(1114)、ユーザ毎のPCCCのアドレスを記録する(1116)。具体的には図2に示したアプリケーション毎の情報である許可端末リスト(42)と、トンネリング暗号管理テーブル(46)部分にPCCCのアドレスを記録する。認証が確認されなければ、そのパケットは破棄される(1118)。通信を許可された相手ではないからである。
サービス毎の暗号方式および鍵の設定を行い(1120)、通信を開始する(1124)。通信が終了の場合は(1126)、終了処理を行って(1128)終了する。
PCCS1は、PCCCaがホットスポットとの接続を切断したことを知ることができないので、PCCS1は常に通信内容が認証要求か否かをモニタする(1122)。そして、送られてきたパケットが認証要求である場合は、再び認証局の公開鍵で復号化し、認証を確認する(1112、1114)。すなわち、PCCS1は通信パケットが認証要求であるか否かを判断する。
ここで、認証書に前のアドレスと新しいアドレスが記載されている場合には、ユーザ毎のPCCCのIPアドレスを書き換える。すなわち、アドレスを更新する。図17の場合では、PCCCaのIPアドレスは、最初の接続ではAaであったが、新たな認証書には前のアドレスであるAaと新しいアドレスであるAxが記載されているので、図2のアプリケーション毎の情報(42)と、カプセル化のための情報(46)に記載されたPCCCaのIPアドレスを書き換える。
なお、ここでは認証書に新旧のアドレスが記載されていた例を説明したが、ステップ1116でユーザ毎のPCCCのアドレスを記録しているのでこれを利用してもよい。すなわち、アプリケーション毎の情報(42)やカプセル化のための情報(46)には、ユーザ名だけでなく端末のアドレスも記載されている。従って、認証を求めてきた相手がすでにこれらのテーブルに記載されていたら、現在通信を行っている端末に接続されたPCCCのアドレスが変更になったと判断する。これはいわば、通信記録を確認することになる。
その後、再度サービス毎の暗号方式と暗号鍵の設定(1120)は行ってもよいし、前の設定をそのまま用いてもよい。
上記の説明で、送られてきたパケットが認証要求であるかどうかをPCCSの動作フローの(1122)として説明したが、この処理は別途の専用処理ルーチンで処理をし、認証要求であれば、割り込みをかけて処理(1112)から始まるようにしてもよい。
以上のようなPCCクライアントと、PCCサーバーによって、利用者はローミング機能を有した本発明を利用することができ、移動しながらでもセキュリティーの高いサービスを受けることができる。