説明

クライアントサーバシステム

【課題】署名付与や暗号化等をサポートしていない網の場合でも、IPアドレスが固定でないクライアントに対して、安全にデータまたはコマンドを送付可能なクライアントサーバシステムを提供することである。
【解決手段】サーバとクライアントとが通信を行うサーバクライアントシステムにおいて、前記サーバから前記クライアントに対して通信開始する際に、通信内容に応じた識別子を記載した電子メールを前記サーバから前記クライアントに対して送信し、該電子メールを受信した前記クライアントは該サーバに対して該受信電子メールに記載の識別子に対応する前記通信内容の問い合わせを行い、該問い合わせを受けた前記サーバは該クライアントとの間に暗号化通信路を確立し、該暗号化通信路上で前記サーバから前記クライアントに対して前記通信内容を送信することを特徴とする。

【発明の詳細な説明】
【技術分野】
【0001】
本発明はクライアントサーバシステムに関する。
【背景技術】
【0002】
クライアントサーバシステムにおいては、通信の際に互いを特定するためにIPアドレスが用いられる。しかしながら、携帯電話機や無線LAN等のクライアントにおいては、通信の都度にIPアドレスが割り当てられる構成であるため、サーバではクライアントのIPアドレスがわからず、サーバからクライアントに対して通信を開始することができなかった。このような状況において、最近では、携帯電話や無線LAN等の普及は目覚ましく、クライアントサーバシステムにおいて、IPアドレスが固定でないクライアントとの通信の必要性が増加している。
【0003】
さらに説明すると、上述の携帯電話機や無線LAN等のクライアントは移動機であり、通信キャリアの無線網に接続している場合、固定IPアドレスを用いることができず、接続ごとに異なるIPアドレスが割り当てられる。このため、従来はサーバからの契機でクライアントへ通信を行うことができなかった。
【0004】
この対策としては、Push配信サービスを利用することが考えられる。多くの通信キャリアは電子メールを移動機へPush配信するサービスを提供しているため、それを利用して電子メールを用いてクライアントへデータまたはコマンドを送付することができる。また、電子メールPush配信のサービスが利用できない場合は、クライアントがメールサーバからのメール受信をポーリングすることで同等の機能を実現することができる。
【0005】
特許文献1には、電子メールの送受信において、暗号通信が可能な相手先のみを選択するリストを提示し、暗号通信を行うことができない相手先に対して誤って暗号化した電子メールを送信することがないようにした通信装置について開示されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2006−60388号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
ところが、上述のように、上記の代替手段を用いる場合、電子メールは公衆網を使用するため、電子メールの傍受及び偽装が脅威として考えられる。具体的な例の1つとしては、サーバからクライアントへ電子メールで送付する内容がデータである場合、第三者による電子メールの傍受により、機密情報が漏洩するリスクがある。また、別の例としては、サーバからクライアントへ電子メールで送付する内容が処理を依頼するコマンドである場合、第三者が偽のコマンドを電子メールで送付した場合に、クライアントが不正な処理を実行するリスクがある。
【0008】
電子メールへの署名付与および暗号化により上記のリスクは軽減できるが、署名を付与したとしても、電子メール自体をキャプチャされて再送されると、署名が有効であるためコマンドが実行されてしまう。
【0009】
そこで、特許文献1に記載のように、電子メールを暗号化することが考えられるが、電子メールへの署名付与や暗号化は通信キャリアの無線網でサポートされていない場合があるという問題があった。
【0010】
本発明は上記の点にかんがみてなされたもので、署名付与や暗号化等をサポートしていない網の場合でも、IPアドレスが固定でないクライアントに対して、安全にデータまたはコマンドを送付可能なクライアントサーバシステムを提供することを目的とする。
【課題を解決するための手段】
【0011】
上記課題を解決するにあたり、本発明では、サーバからクライアントへ送付する電子メール自体にはデータまたはコマンドの識別子のみを記載し、クライアントが電子メールを受信後にクライアントからサーバへ接続を行い、識別子に対応する内容を問い合わせる。この問い合わせに応じてサーバは、識別子に対応するデータまたはコマンドをクライアントへ返送し、クライアントはデータの受信、およびコマンドの実行を行う。電子メール受信後のクライアント−サーバ間の接続は、セキュリティを確保するため、SSL等の暗号化通信とする。
【0012】
すなわち本発明は、サーバからクライアントへの通信において、電子メールを利用してPush通知を行い、電子メールには識別子のみ記載し、Push受信後にクライアントからサーバへ暗号化通信路を確立し、暗号化通信路上でサーバからクライアントへの通信内容を確認する。
【0013】
本発明では、公衆網を使用する電子メールには秘密情報を記載しないため、傍受されても問題ない。秘密情報は、クライアントからサーバへの暗号化通信で送受信する。
【0014】
また、電子メールを傍受して第三者がコマンドを再送する攻撃に対しては、クライアントからサーバへの問い合わせ時に、電子メールに記載されていた識別子が、サーバから発行されておらず有効でないことが判別できるため、不正なコマンドが実行されることもない。
【0015】
本発明は、サーバとクライアントとが通信を行うサーバクライアントシステムにおいて、前記サーバから前記クライアントに対して通信開始する際に、通信内容に応じた識別子を記載した電子メールを前記サーバから前記クライアントに対して送信し、該電子メールを受信した前記クライアントは該サーバに対して該受信電子メールに記載の識別子に対応する前記通信内容の問い合わせを行い、該問い合わせを受けた前記サーバは該クライアントとの間に暗号化通信路を確立し、該暗号化通信路上で前記サーバから前記クライアントに対して前記通信内容を送信することを特徴とする。
【0016】
また本発明は、前記サーバと前記クライアントとがインターネットプロトコルによって通信することを特徴とする。
【0017】
また本発明は、前記クライアントが固定IPアドレスを有さないことを特徴とする。
【0018】
また本発明は、前記クライアントが移動機であることを特徴とする。
【発明の効果】
【0019】
本発明によれば、以下のような効果を奏する。
【0020】
第1の効果は、IPアドレスが固定でないクライアントに対して、安全にデータまたはコマンドを送付可能な点である。
【0021】
第2の効果は、上記の実施のために既存のネットワーク設備の拡張を必要とせず、既存のネットワークの機能で実現可能な点である。
【図面の簡単な説明】
【0022】
【図1】本発明によるサーバクライアントシステムの一実施形態の構成を示すブロック図である。
【図2】図1に示したサーバクライアントシステムにおけるサーバとクライアントとの動作の流れを示すシーケンス図である。
【図3】図1に示したサーバクライアントシステムにおけるクライアントの処理流れを示すフローチャートである。
【図4】図1に示したサーバクライアントシステムにおけるクライアントの処理流れを示すフローチャートである。
【図5】図1に示したサーバクライアントシステムにおけるサーバの処理流れを示すフローチャートである。
【図6】本発明によるサーバクライアントシステムの、図1とは別の実施形態の構成を示すブロック図である。
【発明を実施するための形態】
【0023】
以下、本発明の実施の形態について図面を参照して詳細に説明する。
【0024】
図1は、本発明によるサーバクライアントシステムの一実施形態の構成を示すブロック図である。
【0025】
本実施形態のサーバクライアントシステムは、クライアント端末10と、ネットワーク30と、暗号化通信路40と、サーバ50とを有して構成される。
【0026】
クライアント端末10には、情報処理装置20が含まれる。
【0027】
情報処理装置20は、アプリケーション201と、Pushコマンド受信手段202と、受信メール解析手段203と、メール受信手段204と、通信手段205とを有して構成される。
【0028】
アプリケーション201は、サーバ50からのデータまたはコマンドを受信するアプリケーションである。
【0029】
Pushコマンド受信手段202は、サーバ50からの電子メール受信を受けて受信メール解析手段203から識別子を受け取り、通信手段205を用いてサーバへ識別子に対応するデータまたはコマンドを問い合わせる。
【0030】
受信メール解析手段203は、クライアント端末10が受信した電子メールを解析し、サーバ50からのデータまたはコマンドの通知であるかどうかを判定し、該当した場合はPushコマンド受信手段202へ電子メールに含まれる識別子を送付する。
【0031】
メール受信手段204は、クライアント端末10宛ての電子メールを受信する。受信の契機としては、通信キャリアのサービスとしてPush配信される他に、メール受信手段204がメールサーバ(図示せず)に対して受信確認をポーリングする方法も考えられる。受信したすべてのメールは、受信メール解析手段203へ送付される。
【0032】
通信手段205は、サーバ50の通信手段602との間に暗号化通信路40を確立し、この暗号化通信路40によってクライアント端末10とサーバ50との間の安全な通信を提供する。暗号化通信の方式としては、SSL等の既知のいかなる方式を用いてもよい。
【0033】
ネットワーク30は、公衆網および通信キャリアの通信網を含む。
【0034】
暗号化通信路40は、クライアント端末10とサーバ50との間で確立する仮想的な通信路である。クライアント端末10側の通信手段205と、サーバ50側の通信手段602とにより作成される。
【0035】
サーバ50は、情報処理装置60と、記憶装置70とを有して構成される。
【0036】
情報処理装置60は、メール送信手段601と、通信手段602と、Pushコマンド管理手段603と、アプリケーション604とを有して構成される。
【0037】
メール送信手段601は、Pushコマンド管理手段603から指定された内容のメールを、クライアントへ送付する。
【0038】
通信手段602は、クライアントの通信手段205との間に暗号化通信路40を確立し、クライアント端末10とサーバ50との間の安全な通信を提供する。暗号化通信の方式としては、SSL等の既知のいかなる方式を用いてもよい。
【0039】
Pushコマンド管理手段603は、アプリケーション604で発生したクライアントへ送付が必要なデータまたはコマンドをアプリケーション604から受け取り、該当データまたはコマンドに対応する識別子を生成し、記憶装置70内のコマンド・識別子対応表701に、そのデータまたはコマンドと識別子との組を保存する。その後、メール送信手段601を用いて、クライアント端末10へ識別子を電子メールで送付する。また、クライアント端末10からの問い合わせを通信手段602経由で受け取り、この問い合わせに含まれる識別子に対応するデータまたはコマンドを、コマンド・識別子対応表701から検索し、該当するデータまたはコマンドを通信手段602を用いてクライアントへ返送する。
【0040】
アプリケーション604は、サーバ50側のユーザの操作または何らかのイベントにより、クライアント端末10への送付が必要になったデータまたはコマンドをPushコマンド管理手段603へ渡し、クライアント端末10への送付を依頼する。
【0041】
記憶装置70はサーバ50内でデータを保存する装置である。コマンド・識別子対応表701を保存する。コマンド・識別子対応表701には、クライアント端末10へ送付するデータまたはコマンドと識別子の対応表が格納される。また、記憶装置70には、クライアント端末10のほか、接続される複数のクライアントの電子メールアドレスをあらかじめ記憶してあり、この電子メールアドレスを用いて、各クライアントへの識別子の電子メール送付が行われる。
【0042】
次に、図面を参照しながら本実施形態の動作を説明する。
【0043】
図2は、図1に示したサーバクライアントシステムにおけるサーバとクライアントとの動作の流れを示すシーケンス図である。
【0044】
図3は、図1に示したサーバクライアントシステムにおけるクライアントの処理流れを示すフローチャートである。
【0045】
図4は、図1に示したサーバクライアントシステムにおけるクライアントの処理流れを示すフローチャートである。
【0046】
図5は、図1に示したサーバクライアントシステムにおけるサーバの処理流れを示すフローチャートである。
【0047】
図2のシーケンス図は、サーバ50側でクライアント端末10へ送付するデータまたはコマンドが発生してからクライアント端末10がデータまたはコマンドを受信して、コマンドを実行するまでの動作の説明である。
【0048】
まず、ステップ(S01)では、サーバ50側のアプリケーション604で、ユーザの操作または何らかのイベントにより、クライアント端末10へ通知する必要があるデータまたはコマンドが発生し、Pushコマンド管理手段603へ該当のデータまたはコマンドを送付する。
【0049】
ステップ(S02)では、Pushコマンド管理手段603は、アプリケーション604で発生したクライアント端末10へ送付が必要なデータまたはコマンドを受け取り、該当データまたはコマンドに対応する識別子を生成し、記憶装置70内のコマンド・識別子対応表701にデータまたはコマンドと識別子の組を保存する。ここでいう識別子とは、各データまたはコマンドを識別可能なように、データまたはコマンドごとに設けられたものであり、文字、数字、記号等のいかなる組み合わせであってもよい。データまたはコマンドと識別子との対応付けは、データまたはコマンドが発生するたびに異なる対応付けをしてもよいし、同じ対応付けをしてもよい。
【0050】
ステップ(S03)では、Pushコマンド管理手段603は、メール送信手段601を用いて、クライアント端末10へ、今回の識別子を、規定フォーマットの電子メールで送付する。
【0051】
ステップ(S04)では、クライアント端末10のメール受信手段204は、サーバ50からの電子メールを受信する。受信の契機としては、通信キャリアのサービスとしてPush配信される他に、メール受信手段204がメールサーバに対して受信確認をポーリングする方法でもよい。受信したすべてのメールは、受信メール解析手段203へ送付される。
【0052】
ステップ(S05)では、受信メール解析手段203は、受け取った電子メールを解析し、サーバ50からのデータまたはコマンドの通知であるかどうかを判定し、該当した場合はPushコマンド受信手段202へ電子メールに含まれている識別子を送付する。
【0053】
ステップ(S07)では、Pushコマンド受信手段202は通信手段205を用いてサーバ50との暗号化通信路40を確立する。サーバ50側でも通信手段602は、クライアント端末10の通信手段205からの要求を受け、暗号化通信路40の確立を行う(ステップ(S08))。
【0054】
ステップ(S09)では、前のステップまでで確立した暗号化通信路40を使用して、Pushコマンド受信手段202が、通信手段205を用いて、ステップ(S05)で受け取った識別子に対応するデータまたはコマンドをサーバ50へ問い合わせる。
【0055】
ステップ(S10)では、サーバ50の通信手段602は、ステップ(S09)でクライアント端末10が出した問い合わせを受信し、その問い合わせをPushコマンド管理手段603へ送付する。
【0056】
ステップ(S11)では、Pushコマンド管理手段603は、ステップ(S10)で受け取ったクライアント端末10からの問い合わせに含まれる識別子に対応するデータまたはコマンドをコマンド・識別子対応表701から検索する。
【0057】
ステップ(S12)では、Pushコマンド管理手段603は、ステップ(S11)で検索したデータまたはコマンドを、通信手段602を用いて、クライアント端末10へ返送する。
【0058】
ステップ(S13)では、Pushコマンド管理手段603は、ステップ(S11)で検索した識別子とデータまたはコマンドとの組をコマンド・識別子対応表701から削除する。
【0059】
ステップ(S14)では、クライアント端末10のPushコマンド受信手段202は、通信手段205経由で、ステップ(S12)のサーバ50からのデータまたはコマンドを受信し、アプリケーション201へ通知する。
【0060】
ステップ(S15)では、アプリケーション201は受け取ったコマンドを実行する。
【0061】
図3のフローチャートは、クライアント端末10がサーバ50からの電子メールを受け取ってからコマンドを実行するまでの動作の説明である。
【0062】
ステップ(A01)では、クライアント端末10のメール受信手段204は、電子メールを受信する。受信したすべてのメールは、受信メール解析手段203へ送付される。
【0063】
ステップ(A02)では、受信メール解析手段203は、受け取った電子メールを解析し、サーバ50からのデータまたはコマンドの通知であるかどうかを判定する。
【0064】
ステップ(A03)では、ステップ(A02)の判定で該当した場合はPushコマンド受信手段202へ電子メールに含まれる識別子を送付してステップ(A04)に進む。ステップ(A02)の判定で該当しない場合は、本フローチャートは終了し、通常のメール受信時の動作を行う。
【0065】
ステップ(A04)では、Pushコマンド受信手段202は通信手段205を用いてサーバ50との暗号化通信路40を確立する。サーバ50は移動機ではなく、固定IPアドレスなどの固定アドレスを有するものであり、クライアント端末10は、図示しない記憶手段に、このサーバ50の固定IPアドレスなどの固定アドレスを記憶しており、クライアント端末10側からこの固定アドレス宛に通信を開始することによって暗号化通信路40を確立することができる。
【0066】
ステップ(A05)では、ステップ(A04)の暗号化通信路40の確立が成功した場合、ステップ(A06)に進む。暗号化通信路40の確立が失敗した場合、本フローチャートは終了する。
【0067】
ステップ(A06)で、前のステップまでで確立した暗号化通信路40を使用して、Pushコマンド受信手段202が、通信手段205を用いて、識別子に対応するデータまたはコマンドをサーバ50へ問い合わせる。
【0068】
ステップ(A07)では、クライアント端末10のPushコマンド受信手段202は、暗号化通信路40を使用して、通信手段205経由で、サーバ50からの問い合わせ結果のデータまたはコマンドを受信する。
【0069】
ステップ(A08)では、ステップ(A07)で受信した問い合わせ結果にコマンドが含まれていた場合は、ステップ(A09)に進む。コマンドが含まれていなかった場合は、本フローチャートは終了する。
【0070】
ステップ(A09)で、アプリケーション201は受け取ったコマンドを実行する。
【0071】
図4のフローチャートは、サーバ50側でクライアント端末10へ送付するデータまたはコマンドが発生してから、クライアント端末10へ電子メールを送付するまでのクライアントの動作の説明である。
【0072】
まず、ステップ(B01)では、サーバ側のアプリケーション604で、ユーザの操作または何らかのイベントにより、クライアントへ通知する必要があるデータまたはコマンドが発生し、Pushコマンド管理手段603へ該当のデータまたはコマンドを送付する。
【0073】
ステップ(B02)では、Pushコマンド管理手段603は、アプリケーション604で発生したクライアントへ送付が必要なデータまたはコマンドを受け取り、該当データまたはコマンドに対応する識別子を生成し、記憶装置70内のコマンド・識別子対応表701に、データまたはコマンドと識別子との組を保存する。
【0074】
ステップ(B03)では、Pushコマンド管理手段603は、メール送信手段601を用いて、クライアント端末10へ識別子を規定フォーマットの電子メールで送付する。
【0075】
図5のフローチャートは、サーバ50側でクライアント端末10からの識別子内容の問い合わせを待ち受け、問い合わせを受信してからクライアント端末10へ結果を返送するまでのサーバ50の動作の説明である。
【0076】
ステップ(C01)では、サーバ50の通信手段602は、クライアント端末10からの暗号化通信開始要求を待受けている。
【0077】
暗号化通信開始要求がクライアント端末10から来ると、ステップ(C02)で暗号化通信路40を確立する。
【0078】
ステップ(C03)では、ステップ(C02)で暗号化通信路40の確立が成功した場合はステップ(C04)に進む。失敗した場合は、本フローチャートは終了する。
【0079】
ステップ(C04)では、サーバ50の通信手段602は、クライアント端末10からの識別子問い合わせを待受ける。
【0080】
ステップ(C05)では、識別子の内容問い合わせを受信すると、Pushコマンド管理手段603へ送付する。
【0081】
ステップ(C06)では、Pushコマンド管理手段603は、ステップ(C05)で受け取ったクライアント端末10の問い合わせに含まれる識別子に対応するデータまたはコマンドをコマンド・識別子対応表701から検索する。
【0082】
ステップ(C07)では、ステップ(C06)の検索で該当のデータまたはコマンドが存在する場合、ステップ(C10)へ進む。該当のコマンドが存在しない場合、ステップ(S09)へ進む。
【0083】
ステップ(C09)では、クライアント端末10に対し、コマンドなしを返却する。
【0084】
ステップ(C10)では、クライアント端末10に対し、ステップ(S06)で検索したデータまたはコマンドを返却する。
【0085】
ステップ(C11)で、Pushコマンド管理手段603は、ステップ(C06)で検索した識別子とデータまたはコマンドとの組をコマンド・識別子対応表701から削除する。
【0086】
以上説明した本発明によれば、IPアドレスが固定でないクライアントに対して、安全にデータまたはコマンドを送付可能であるという効果を奏する。
【0087】
また、本発明は、既存のネットワーク設備の拡張を必要とせず、既存のネットワークの機能で実現可能である。
【0088】
次に、本発明の別の実施形態について説明する。
【0089】
図6は、本発明によるサーバクライアントシステムの、図1とは別の実施形態の構成を示すブロック図である。
【0090】
この実施形態のサーバクライアントシステムは、サーバ50が識別子生成器605を有し、クライアント端末10が識別子生成器206を有する点で、図1の実施形態と異なる。図1と同様の構成については、同じ参照番号を付して詳しい説明を省略する。
【0091】
図1に示した実施形態では、クライアント端末10のPushコマンド受信手段202は、電子メールで受け取った識別子すべてに対してサーバ50への問い合わせを実施していた。
【0092】
一方、この図6の実施形態では、サーバ50のPushコマンド管理手段603は識別子生成器206で生成した識別子を用いることとし、クライアント端末10は、サーバ50の識別子生成器206で生成した識別子と同じ識別子を生成可能な識別子生成器206を備え、クライアント端末10のPushコマンド受信手段202は、電子メールで受け取った識別子と自身で生成した識別子とが一致した場合にのみ、サーバ50へ問い合わせを実施する。
【0093】
このように構成することによって、第3者からのメール再送攻撃を受けた場合など、実際にはないコマンド等に対するサーバ50への問い合わせを行わずに済み、余計なトラフィックを発生させないという効果を奏する。
【産業上の利用可能性】
【0094】
本発明は、クライアントが移動機である場合に限られず、接続の都度にIPアドレスが割り当てられるあらゆるクライアントに対して、サーバ側から通信を開始したい場合すべてに適用可能である。また、インターネット網に限られず、異なるプロトコルのものにも適用可能である。
【符号の説明】
【0095】
10 クライアント端末
20 情報処理装置
201 アプリケーション
202 Pushコマンド受信手段
203 受信メール解析手段
204 メール受信手段
205 通信手段
30 ネットワーク
40 暗号化通信路
50 サーバ
60 情報処理装置
601 メール送信手段
602 通信手段
603 Pushコマンド送信手段
604 アプリケーション
70 記憶装置
701 コマンド・識別子対応表


【特許請求の範囲】
【請求項1】
サーバとクライアントとが通信を行うサーバクライアントシステムにおいて、
前記サーバから前記クライアントに対して通信開始する際に、通信内容に応じた識別子を記載した電子メールを前記サーバから前記クライアントに対して送信し、該電子メールを受信した前記クライアントは該サーバに対して該受信電子メールに記載の識別子に対応する前記通信内容の問い合わせを行い、該問い合わせを受けた前記サーバは該クライアントとの間に暗号化通信路を確立し、該暗号化通信路上で前記サーバから前記クライアントに対して前記通信内容を送信する、
ことを特徴とするサーバクライアントシステム。
【請求項2】
前記サーバと前記クライアントとがインターネットプロトコルによって通信することを特徴とする請求項1に記載のサーバクライアントシステム。
【請求項3】
前記クライアントが固定IPアドレスを有さないことを特徴とする請求項2に記載のサーバクライアントシステム。
【請求項4】
前記クライアントが移動機であることを特徴とする請求項3に記載のサーバクライアントシステム。
【請求項5】
請求項1に記載のサーバ。
【請求項6】
請求項1に記載のクライアント。


【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate


【公開番号】特開2010−183390(P2010−183390A)
【公開日】平成22年8月19日(2010.8.19)
【国際特許分類】
【出願番号】特願2009−25583(P2009−25583)
【出願日】平成21年2月6日(2009.2.6)
【出願人】(000004237)日本電気株式会社 (19,353)
【Fターム(参考)】