(57)【要約】【課題】移動端末装置が移動中に、設置されている複数のサーバと順々接続するときに、認証から暗号化通信の開始までを高速に行う暗号化通信システムを提供すること。【解決手段】暗号化通信システムは、使用条件が限定された認証用の限定鍵を移動端末装置である携帯端末１０毎に生成する認証サーバ１２と、この認証サーバ１２により生成された限定鍵を特定のサーバに配付する鍵管理サーバ１３と、この鍵管理サーバ１３から受信した限定鍵を用いて、携帯端末１０と暗号化通信を行うサーバ１１、２１、３１と、限定鍵を用いてこのサーバ１１、２１、３１と暗号化通信を行う携帯端末１０とを有し、携帯端末１０がサーバ１１との認証を行った後に、鍵管理サーバ１３がサーバ２１、３１に限定鍵を配付することにより、サーバ２１とサーバ３１との認証を高速に行うことが可能となる。【選択図】  図１
2004320308.tif 000002
【特許請求の範囲】
【請求項１】
移動端末装置からの認証要求と、第一の識別情報とを受信したり、移動端末装置と暗号化データを送受信したりする通信部と、
使用条件が限定された認証用の限定鍵と第一の識別情報とを関連づけて蓄積する限定鍵記憶部と、
第一の識別情報に対応する限定鍵が、前記限定鍵記憶部に存在するか否かを判定する限定認証部と、
限定鍵によりデータの暗号・復号化を行う暗号・復号化部とを有し、
前記限定認証部は第一の識別情報に対応した限定鍵が前記限定鍵記憶部に存在すると判定した場合、前記暗号・復号化部が前記限定鍵を用いて前記通信部を介して暗号化通信を行うサーバ。
【請求項２】
移動端末装置から認証要求と、認証のための認証用情報と、第一の識別情報とを受信したり、移動端末装置とデータを送受信したりする通信部と、
使用条件が限定された認証用の限定鍵と第一の識別情報とを関連づけて蓄積する限定鍵記憶部と、
第一の識別情報に対応する限定鍵が、前記限定鍵記憶部に存在するか否かを判定する限定認証部とを有し、
前記限定認証部は第一の識別情報に対応した限定鍵が前記限定鍵記憶部に存在すると判定した場合、前記認証用情報と前記限定鍵を用いて認証処理を行うサーバ。
【請求項３】
第一の識別情報は端末識別情報と限定鍵識別情報との少なくともいずれか一方である請求項１または請求項２に記載のサーバ。
【請求項４】
前記認証処理は、
前記通信部が認証要求を行う移動端末装置から、第一の識別情報と認証用情報とを受信し、前記限定認証部が前記第一の識別情報に対応した限定鍵が前記限定鍵記憶部に存在すると判定した場合、
前記限定認証部が決定する第二の認証用情報と、前記限定鍵と前記受信した認証用情報と前記第二の認証用情報とから生成される第三の認証用情報と、を前記移動端末装置へ送信する請求項２に記載のサーバ。
【請求項５】
前記限定認証部が、認証要求した移動端末装置に対応した限定鍵が前記限定鍵記憶部に存在しないと判定した場合、前記移動端末装置より受信した認証用情報と第一の識別情報とを移動端末装置の認証を行う認証装置へ送信する請求項１または請求項２に記載のサーバ。
【請求項６】
前記限定認証部が前記限定鍵記憶部に記憶された限定鍵が使用条件を満足するか否かを判定し、使用条件を満たさない場合は、前記限定鍵の削除あるいは更新を前記限定鍵の有効無効を管理する鍵管理装置に要求する請求項５に記載のサーバ。
【請求項７】
前記限定認証部が前記限定鍵記憶部に記憶された限定鍵が使用条件を満足するか否かを判定し、使用条件を満たさない場合は、前記限定鍵の削除と、新たな限定鍵の配付とを前記限定鍵の有効無効を管理する鍵管理装置に要求する請求項５に記載のサーバ。
【請求項８】
前記限定認証部が前記鍵管理装置から限定鍵の削除の指示を受信し、前記限定鍵記憶部にある前記限定鍵を削除する請求項６または請求項７に記載のサーバ。
【請求項９】
前記限定認証部が前記限定鍵記憶部に記憶された限定鍵が使用条件を満足するか否かを判定し、使用条件を満たさない場合は、前記限定鍵記憶部内の前記限定鍵を削除する請求項１乃至請求項５のいずれかに記載のサーバ。
【請求項１０】
使用条件が限定された認証用の限定鍵によりデータの暗号・復号化を行う端末用暗号・復号化部と、
限定鍵を識別する限定鍵識別情報と限定鍵を関連づけて蓄積する認証用情報記憶部と、
認証要求と第一の識別情報を送信したり、限定鍵識別情報を受信したり、暗号化されたデータを送受信したりする通信部と、
限定鍵識別情報により指定された限定鍵が前記認証用情報記憶部に存在するか否かを判定する判定部とを有し、
前記判定部が前記指定された限定鍵が前記認証用情報記憶部に存在すると判定した場合は前記端末用暗号・復号化部が前記指定された限定鍵を用いて前記通信部を介して暗号化通信を行う移動端末装置。
【請求項１１】
使用条件が限定された認証用の限定鍵と、前記限定鍵を識別する限定鍵識別情報とを関連づけて蓄積する認証用情報記憶部と、
認証要求と第一の識別情報を送信したり、限定鍵識別情報を受信したり、データを送受信したりする通信部と、
限定鍵識別情報により指定された限定鍵が前記認証用情報記憶部に存在するか否かを判定する判定部と、
前記判定部が前記指定された限定鍵が前記認証用情報記憶部に存在すると判定した場合は前記指定された限定鍵を用い、前記通信部を介して認証処理を行う認証部と
を有する移動端末装置。
【請求項１２】
第一の識別情報は端末識別情報と限定鍵識別情報との少なくともいずれか一方である請求項１０あるいは請求項１１に記載の移動端末装置。
【請求項１３】
前記認証処理は、
前記通信部がサーバから、限定鍵識別情報と第二の認証用情報と第三の認証用情報とを受信し、前記限定鍵識別情報に対応した限定鍵が前記認証用情報記憶部に存在すると判定した場合、
当該移動端末装置が前記サーバへ送出した認証用情報と、前記限定鍵と前記受信した第二の認証用情報とから生成される情報を前記サーバへ送信する請求項１１あるいは請求項１２に記載の移動端末装置。
【請求項１４】
移動端末装置から受信した認証用情報とあらかじめ保有する前記移動端末装置を認証するための認証情報とから前記移動端末装置を認証する認証部と、
使用条件が限定された認証用の限定鍵を生成する限定鍵生成部と、
前記限定鍵を特定のサーバにのみ配付する限定鍵管理部と
を有する鍵管理装置。
【請求項１５】
前記限定鍵管理部が限定鍵に使用条件を付加して配付する請求項１４に記載の鍵管理装置。
【請求項１６】
前記使用条件が使用可能期間、使用可能回数、使用可能地域、及び受信可能データ量の少なくとも一つを含む請求項１５に記載の鍵管理装置。
【請求項１７】
前記使用条件を満たさない場合に、サーバに限定鍵を削除、あるいは新たな限定鍵の配付を要求する指示を前記限定鍵管理部が限定鍵に付加する請求項１５に記載の鍵管理装置。
【請求項１８】
任意の移動端末装置から任意のサーバへの通信履歴に関する情報を記憶する通信履歴記憶部をさらに有し、
前記認証部が認証した移動端末装置に現在接続されているサーバを特定する情報と、前記通信履歴記憶部に記憶された前記現在接続されているサーバを含む通信履歴と、により前記限定鍵管理部が前記特定のサーバを決定する請求項１４乃至請求項１７のいずれかに記載の鍵管理装置。
【請求項１９】
前記特定のサーバの決定は、前記接続しているサーバを含む通信履歴の内、前記認証した移動端末装置からの通信履歴に関する情報のみにより決定される請求項１８に記載の鍵管理装置。
【請求項２０】
移動端末装置を識別する端末識別情報と、前記移動端末装置が属するグループを識別するグループ識別情報とを関連づけて記憶するグループＩＤ記憶部と、
任意の移動端末装置から任意のサーバへの通信履歴に関する情報を前記グループ毎に記憶する通信履歴記憶部とをさらに有し、
前記限定鍵管理部が前記グループＩＤ記憶部の端末識別情報とグループ識別情報とから、前記認証部により認証された移動端末装置の属するグループを求め、前記移動端末装置の現在接続しているサーバを特定する情報と、前記通信履歴記憶部内の前記接続しているサーバを含む、前記移動端末装置が属するグループの通信履歴と、により前記特定のサーバを決定する請求項１４乃至請求項１７のいずれかに記載の鍵管理装置。
【請求項２１】
任意の移動端末装置から任意のサーバへの通信履歴に関する情報をグループ毎に記憶する通信履歴記憶部を有し、
移動端末装置から受信したグループ識別情報と、前記移動端末装置の現在接続しているサーバを特定する情報と、前記通信履歴記憶部内の前記接続しているサーバを含む、前記移動端末装置が属するグループの通信履歴と、により前記特定のサーバを決定する請求項１４乃至請求項１７のいずれかに記載の鍵管理装置。
【請求項２２】
サーバを識別するサーバ識別情報と、前記サーバが属するグループを識別するサーバグループ識別情報とを関連づけて記憶するサーバグループＩＤ記憶部をさらに有し、
前記限定鍵生成部が前記サーバグループＩＤ記憶部内の情報に基づいて、前記限定鍵管理部の特定したサーバのサーバグループ毎に異なる限定鍵を生成し、
前記限定鍵管理部が前記異なる限定鍵を前記特定したサーバに配付する請求項１４乃至請求項１７のいずれかに記載の鍵管理装置。
【請求項２３】
前記特定のサーバの決定は現在接続しているサーバからの接続頻度の高い順から所定数のサーバ、あるいは所定の接続頻度以上のサーバを選択することにより行う請求項１８乃至請求項２１のいずれかに記載の鍵管理装置。
【請求項２４】
前記特定のサーバの決定は、任意のサーバからの要求により更新される請求項１４乃至請求項２３のいずれかに記載の鍵管理装置。
【請求項２５】
前記限定鍵管理部が前記特定のサーバに前記限定鍵の削除を指示する請求項１４乃至請求項２４のいずれかに記載の鍵管理装置。
【請求項２６】
前記限定鍵管理部が限定鍵を配付した特定のサーバと、前記限定鍵を特定する限定鍵識別情報とを関連づけて記憶する配付先記憶部をさらに有し、
前記限定鍵管理部が、受信した限定鍵の削除の要求と限定鍵識別情報とに従い、前記配付先記憶部から前記限定鍵を配付した特定のサーバを抽出する請求項２５に記載の鍵管理装置。
【請求項２７】
前記特定のサーバは前記認証部により認証された移動端末装置と現在接続しているサーバから所定の距離内にあるサーバである請求項１４に記載の鍵管理装置。
【請求項２８】
前記特定のサーバは前記認証部により認証された移動端末装置と現在接続しているサーバが存在する地域にあるサーバ、あるいは前記サーバと関連のあるサーバである請求項１４に記載の鍵管理装置。
【請求項２９】
使用条件が限定された認証用の限定鍵を移動端末装置毎に生成する限定鍵生成装置と、
前記限定鍵生成装置により生成された限定鍵を特定のサーバに配付する鍵管理装置と、
前記鍵管理装置から受信した前記限定鍵を用いて、移動端末装置と暗号化通信を行うサーバと、
前記限定鍵を用いて、前記サーバと暗号化通信を行う移動端末装置とを有する暗号化通信システム。
【請求項３０】
使用条件が限定された認証用の限定鍵を移動端末装置毎に生成する限定鍵生成装置と、
前記限定鍵生成装置により生成された限定鍵を特定のサーバに配付する鍵管理装置と、
前記鍵管理装置から受信した前記限定鍵と移動端末装置から受信した認証用情報とを用いて前記移動端末装置を認証した後に、前記限定鍵を用いて前記移動端末装置との暗号化通信を行うサーバと、
限定鍵と、サーバから受信した第二の認証用情報とを用いて前記サーバを認証した後に、前記限定鍵を用いて前記サーバとの暗号化通信を行う移動端末装置と
を有する暗号化通信システム。
【請求項３１】
請求項１に記載のサーバと、
請求項１０に記載の移動端末装置と、
請求項１４に記載の鍵管理装置と
を有する暗号化通信システム。
【請求項３２】
使用条件が限定された認証用の限定鍵を所有する移動端末装置から、認証用情報と、前記移動端末装置を識別するための識別情報とをサーバに送信して認証要求するステップと、
前記サーバが前記認証要求を受信して、前記移動端末装置の所有する前記限定鍵と同一の限定鍵を所有している場合、前記限定鍵を用いて前記移動端末装置と暗号化通信を行い、前記限定鍵と同一の限定鍵を所有していない場合、限定鍵生成装置に前記認証用情報と前記識別情報とを送信して前記移動端末装置用の限定鍵の生成を要求するステップと、
前記限定鍵生成装置が受信した前記認証用情報とあらかじめ保有する認証情報とから前記移動端末装置を認証し、前記認証用情報の少なくとも一部と前記認証情報とから前記移動端末装置が所有する前記限定鍵と同一の限定鍵を生成するステップと、
前記限定鍵の有効無効を管理する鍵管理装置が前記限定鍵生成装置の生成した前記限定鍵を特定のサーバに配付するステップと、
限定鍵の生成を要求した前記サーバが配付された前記限定鍵を受信したのちに、前記認証要求した移動端末装置と前記限定鍵を用いて暗号化通信をするステップと
を有する暗号化通信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、無線通信可能な移動端末装置と、情報を配信するサーバとが認証や暗号化通信を行う際に必要な鍵の配付や、削除等を行う暗号化通信システムおよび暗号化通信方法に関する。
【０００２】
【従来の技術】
近年、無線ＬＡＮやＢｌｕｅｔｏｏｔｈといった無線通信機器の普及がすすみ、ホットスポットをはじめとする無線によるインターネット接続や、モバイルＥＣなどの情報提供サービスなどを街中や建物の中などで利用できる機会が広まっている。
【０００３】
今後、無線通信技術の進歩と機器の普及によりそのようなサービスを利用できる場所や機会はますます増えて行くと思われる。
【０００４】
このようなサービスを実施する上で十分考慮すべき問題としてなりすましの問題が挙げられる。悪意のある者が設置した正規のサーバになりすました不正なサーバに、利用者がアクセスし個人情報を送信してしまうと、その個人情報が悪意のある者に漏洩してしまう。また、悪意のある者が他の正規の利用者になりすまして、サーバにアクセスできてしまうと、他の利用者の個人情報が漏洩したり、勝手にサービスを利用されたりしてしまう。
【０００５】
一般に利用者がサーバからサービスの提供を受ける場合に、これらのなりすましを防ぐため、サーバと利用者の持つ携帯端末間で相互認証を行う。また、通信が無線で行われることから、サービス提供時の通信内容を盗聴から保護するために、通信内容を暗号化することも必要である。そのため、相互認証が完了後、サーバと携帯端末は、そのセッションでの暗号化通信に用いるセッション鍵を生成し共有する。この相互認証、セッション鍵の共有は、サーバと携帯端末とが通信を開始するたびに行う必要がある。
【０００６】
相互認証の方式として、共通鍵暗号を使う方式と、公開鍵暗号を使う方式が挙げられる。共通鍵暗号方式では、二者間で事前に交換しておいた二者間以外には秘密の鍵を所持していることを確認することで認証を行う。公開鍵暗号方式では、相手のものと信頼できる公開鍵を入手し、相手しか保持していない秘密鍵による署名を検証して、秘密鍵を確かに所持していることを確認することで認証する。相手の公開鍵の信頼性は認証するたびに確認する必要がある。
【０００７】
このように、サーバは認証するために他に漏洩させてはならない秘密の鍵を保持することになるが、街頭などに設置されるサーバに対しては、ネットワーク経由での攻撃のほかに、物理的な盗難なども考えられ、長期に利用可能な鍵を所持させるのは危険である。
【０００８】
また、共通鍵暗号方式の場合、サーバ、利用者の対ごとに鍵が必要なため、多量の鍵の追加、削除、更新等の管理には大変な手間がかかる。特に携帯端末の鍵を管理することは困難である。公開鍵暗号方式の場合、信頼できる、あるいは無効化され信頼できない公開鍵のリストが各サーバ、携帯端末に必要となり、公開鍵の信頼性の確認に手間がかかる。
【０００９】
従来より、このような問題への対策として、長期に渡って利用可能な鍵は認証サーバと呼ばれる別の安全なサーバに置いておき、認証は認証サーバが行う方法がある。ダイアルアップサーバのＲＡＤＩＵＳ（Ｒｅｍｏｔｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｄｉａｌ−Ｉｎ  Ｕｓｅｒ  Ｓｅｒｖｉｃｅ）などはこの構成になっている。このシステムにおいては、認証サーバを置くことにより、サーバには暗号化通信に用いるセッション鍵だけが置かれることになる。したがって、セッション鍵がもれてもそのセッションが終了すると無効になるので、重大な問題にはならない。
【００１０】
また、無線の基地局がいたるところに存在し、認証サーバを有する構成である暗号化通信システムとして、非特許文献１に記載されているようなものがある。
【００１１】
このシステムでは、無線ＬＡＮを搭載した移動端末装置を持つ利用者が街中を歩き、基地局と無線による通信を開始した時点で、無線インターネットサービスを利用するための相互認証を行い、移動端末装置と基地局との間の暗号化通信に用いるセッション鍵の共有を行う。
【００１２】
図２０は、非特許文献１に記載された従来の暗号化通信システムの構成を示すブロック図である。
【００１３】
図２０において、暗号化通信システムは、利用者が持ち歩く移動端末装置である携帯端末１０、携帯端末１０からの認証要求や、サービス要求を受け、認証要求の転送、サービスの提供を行うサーバ１１、および転送された認証要求に対して認証を行う認証サーバ１２からなる。
【００１４】
携帯端末１０の通信部２０１は、サーバ１１の通信部３０１との通信を行う。認証要求部２０２は、認証用情報記憶部２０３の情報から認証要求を生成し、通信部３０１を介して、サーバ１１に送信する。認証用情報記憶部２０３は、認証に必要な情報を保持する。
【００１５】
サーバ１１の通信部３０１は、携帯端末１０の通信部２０１との通信を行う。鍵記憶部２００２はセッション鍵を携帯端末１０の識別子と対応させて保持する。鍵操作部３０４は鍵配付部２００３からセッション鍵を受け取り、鍵記憶部２００２に保存したり、セッション終了後に削除したりする。認証転送部２００１は、携帯端末１０からの認証要求を認証部４０１に転送する。
【００１６】
認証サーバ１２の、認証部４０１は認証転送部２００１から転送された携帯端末１０の認証要求に対する認証を認証情報記憶部４０２の情報を用いて行い、セッション鍵を生成して鍵配付部２００３に渡す。認証情報記憶部４０２は、認証に必要な情報を保持する。鍵配付部２００３は、認証部４０１から渡されたセッション鍵を鍵操作部３０４に送信する。
【００１７】
この構成における認証の流れを図２１で説明する。
【００１８】
まず、サーバ１１が、携帯端末１０からの認証要求を受ける（ステップＳ２１０１）。
【００１９】
次に、サーバ１１は認証サーバ１２に認証処理を依頼する（ステップＳ２１０２）。
【００２０】
次に、認証サーバ１２は、認証処理を行う。成功した場合には、携帯端末１０の認証要求からセッション鍵を生成し、サーバ１１に送信する（ステップＳ２１０３）。
【００２１】
次に、サーバ１１は、携帯端末１０に認証の成功を通知する（ステップＳ２１０４）。成功を通知された携帯端末１０は、サーバの認証を行い、成功した場合、サーバ１１に送った自身の認証要求からセッション鍵を生成する。こうして、サーバと携帯端末は相互認証とセッション鍵の共有を行うことができ、このセッション鍵を用いて、以降の暗号化通信を行う。
【００２２】
さらに、従来より、この暗号化通信システムとしては、特許文献１に記載されているようなものがあった。
【００２３】
図２２は、特許文献１に記載された従来の暗号化通信システムを示すものである。
【００２４】
図２２において、応用システム２２００はサービスを提供し、基地局管理装置２２０２は複数の基地局装置２２１０を管理し、通信網２２０１、２２０８はこれらをつないでいる。また、移動局装置２２１７は基地局装置２２１０が作る通信ゾーン内においては、基地局２２１０にアクセスし基地局管理装置２２０２に認証を受ける。その後、移動局装置２２１７が移動しても、同じ基地局管理装置２２０２の管理下にある別の基地局装置２２１１と通信する間は認証の簡略化を行うものである。
【００２５】
【特許文献１】
特開２００２−１１２３３７号公報（第４−５頁、第１図）
【非特許文献１】
「無線インターネットに必要なセキュリティを提供する高速認証システム」情報処理学会研究報告  ２００２−ＤＰＳ−１０７
【００２６】
【発明が解決しようとする課題】
しかし、非特許文献１に示した従来の暗号化通信システムでは、携帯端末１０が移動し、新たなサーバと通信を開始する場合、携帯端末１０は新たなサーバと認証をする都度、認証サーバと通信しなくてはならない。この通信はインターネットを経由して行うことも考えられ、認証にかかる時間がネットワークの状態に左右されるため、場合によっては大きな遅延が生じるいう課題があった。
【００２７】
また、認証サーバが認証を一手に引き受けるために、認証に要する負荷が高くなり、認証に時間がかかる恐れがあった。このことは、ＲＡＤＩＵＳにおいても、見られている。
【００２８】
これに対し認証サーバを複数台用意するなどの対策はとれるが、複数台用意することによりコストがかかる上、認証サーバに認証を依頼するかぎり、その認証にかかる時間はなくならないという問題が残っていた。
【００２９】
また、特許文献１に示した別の従来の暗号化通信システムでは、移動局装置が異なる基地局管理装置の管理下の基地局装置にアクセスする場合、認証用のＩＤが伝わっていないため、新たに正規の認証処理を行う必要があった。
【００３０】
本発明は上記従来の課題を解決するもので、利用者が携帯端末を持ちながら移動し街中に設置されている複数のサーバと順々に接続を行う場合において、認証から、暗号化通信の開始までを高速に行う暗号化通信システムを提供することを目的とする。
【００３１】
【課題を解決するための手段】
上記従来の課題を解決する本発明に係る暗号化通信システムは、使用条件が限定された認証用の限定鍵を移動端末装置毎に生成する限定鍵生成装置と、この限定鍵生成装置により生成された限定鍵を特定のサーバに配付する鍵管理装置と、この鍵管理装置から受信した限定鍵を用いて、移動端末装置と暗号化通信を行うサーバと、限定鍵を用いて、このサーバと暗号化通信を行う移動端末装置とを有している。
【００３２】
また、本発明に係るサーバは、移動端末装置からの認証要求と、第一の識別情報とを受信したり、移動端末装置と暗号化データを送受信したりする通信部と、使用条件が限定された認証用の限定鍵と第一の識別情報とを関連づけて蓄積する限定鍵記憶部と、第一の識別情報に対応する限定鍵が、限定鍵記憶部に存在するか否かを判定する限定認証部と、限定鍵によりデータの暗号・復号化を行う暗号・復号化部とを有し、限定認証部は第一の識別情報に対応した限定鍵が前記限定鍵記憶部に存在すると判定した場合、暗号・復号化部が限定鍵を用いて通信部を介して暗号化通信を行う。
【００３３】
これにより、初回アクセス時などのように移動端末装置とサーバとの間で限定鍵が共有されていない場合は認証サーバとの通信が発生するが、それ以後移動端末装置とサーバとの間で限定鍵が共有されている場合には、認証サーバとの通信が不要となるため、認証サーバへの認証依頼頻度を減らすことができる。また、限定鍵を用いて暗号化通信を行うこともでき、高速に安全な通信を開始することができる。
【００３４】
本発明に係る移動端末装置は、使用条件が限定された認証用の限定鍵によりデータの暗号・復号化を行う端末用暗号・復号化部２０６と、限定鍵を識別する限定鍵識別情報と限定鍵を関連づけて蓄積する認証用情報記憶部と、認証要求と第一の識別情報を送信したり、限定鍵識別情報を受信したり、暗号化されたデータを送受信したりする通信部と、限定鍵識別情報により指定された限定鍵が認証用情報記憶部に存在するか否かを判定する判定部２０７とを有し、この判定部２０７が指定された限定鍵が認証用情報記憶部に存在すると判定した場合は端末用暗号・復号化部２０６が指定された限定鍵を用いて通信部を介して暗号化通信を行う。
【００３５】
これにより、限定鍵をすでに保有している場合、限定鍵の受信を待つ必要がないので、これを用いてすばやく暗号化通信を開始することができる。
【００３６】
本発明に係る鍵管理装置は、移動端末装置から受信した認証用情報とあらかじめ保有する移動端末装置を認証するための認証情報とから移動端末装置を認証する認証部と、使用条件が限定された認証用の限定鍵を生成する限定鍵生成部と、限定鍵を特定のサーバにのみ配付する限定鍵管理部とを有している。
【００３７】
これにより、限定鍵の配付先を制限できるので、鍵管理装置の負荷を低減することができる。
【００３８】
【発明の実施の形態】
以下本発明の実施の形態について、図面を参照しながら説明する。
【００３９】
（第一の実施の形態）
本発明の第一の実施の形態における暗号化通信システムの構成について説明する。
【００４０】
図１に示すように、本実施の形態における暗号化通信システムは、利用者が持つ携帯端末１０と、携帯端末１０から認証を要求されるサーバ１１と、認証して限定鍵の作成を行う認証サーバ１２と、限定鍵の管理先を選択し、限定鍵のサーバへの配付および削除の通知を行う鍵管理サーバ１３とを備えている。そして、サーバ１１、認証サーバ１２、及び鍵管理サーバ１３はインターネットなどの電気通信回線１５で接続されており、これらの間の通信は暗号化されている。なお、電気通信回線は有線でも無線でも構わない。
【００４１】
また、上記の限定鍵とは、本実施の形態の暗号化通信システムにおいて、携帯端末１０が所定の条件の下に認証およびデータの暗号化に使用する鍵であり、この限定鍵の有効条件や、削除条件といった付帯情報も含んでいる。有効条件を満たさない限定鍵は認証に用いることができない。有効期間を過ぎたなど、有効条件が一時的ではなく、永久に満たせなくなった場合、あるいは削除条件を満たした場合にはその限定鍵は削除する。さらに、付帯情報の指示によっては、他のサーバの同じ限定鍵を削除してもらうよう鍵管理サーバを通じて通知する。
【００４２】
図１において、利用者は商店街の中を地点Ａから地点Ｂ、地点Ｃ、地点Ｄ、地点Ｅに順次移動している。そして、利用者の持っている携帯端末１０はサーバとの通信ゾーン１６、１７、１８内に入る度にサーバ１１、サーバ２１、サーバ３１に順次アクセスを行い、認証を受けた後にサービスの提供を受ける。このサービスの内容は、あらかじめ登録しておいた個人の好みといった個人情報をもとに、店舗が商品の紹介情報を提供するものである。なお、携帯端末１０は地点Ｂ及び地点Ｄで通信ゾーンの切り換えを行う。本実施の形態では商店街に情報サーバが多数配置され、利用者が近づき情報を得る例について説明しているが、商店街のような地域に限らず、美術館や、デパートといった出入りの限られた閉じた空間であってもよい。
【００４３】
次に、本発明の第一の実施の形態における暗号化通信システムの各構成物間のデータの流れについて、図１０乃至図１２を用いて説明する
図１０において初期状態として、利用者が地点Ａに侵入した状態にあり、携帯端末１０は認証サーバ１２と秘密鍵である共通鍵Ｋを共有しているが、サーバ１１との認証に用いる限定鍵を所有していない。
【００４４】
まず、携帯端末１０が入口にある限定鍵を共有していないサーバ１１へ近づくと、携帯端末１０は自己を特定するための端末識別情報と認証を受けるための認証用情報とをサーバ１１に送信して認証を要求する（ステップＳ１００１）。
【００４５】
サーバ１１は受けた端末識別情報をもとに限定鍵を保有していないか検索するが、この時点では携帯端末１０と共有する限定鍵をまだ持っていない。このため、サーバ１１は携帯端末１０の認証要求と、サーバ１１自身の認証のための認証用情報を認証サーバ１２に送信する（ステップＳ１００２）。
【００４６】
次に、認証サーバ１２は、サーバ１１から受け取った認証要求に対して、受信した認証用情報とあらかじめ保有している共通鍵Ｋとを用いて認証処理を行う。認証が失敗した場合は、その旨をサーバ１１に伝える。認証が成功した場合は、サーバ１１の認証要求に携帯端末１０への保証をする署名をして、サーバ１１に送信する（ステップＳ１００３）。
【００４７】
サーバ１１は、携帯端末１０に、認証が成功したことを通知し、サーバ１１の認証要求を送信する（ステップＳ１００４）。携帯端末１０は認証サーバ１２の署名によりサーバ１１を認証する。この時点でサーバ１１と携帯端末１０は相互認証されたことになる。
【００４８】
このステップＳ１００３において、認証サーバ１２は携帯端末１０の認証要求に含まれる認証用情報と共通鍵Ｋとから限定鍵を計算する。
【００４９】
次に、認証サーバ１２は限定鍵を携帯端末１０の端末識別情報などと共に鍵管理サーバ１３に伝える（ステップＳ１００５）。
【００５０】
鍵管理サーバ１３は認証サーバ１２から受け取った限定鍵と端末識別情報とから、限定鍵の配付先を選択し、選択された配付先に限定鍵と携帯端末１０に関する情報を配付する（ステップＳ１００６）。この例では、商店街中のサーバが配付先として選択される。選択されたサーバ２１，３１は携帯端末１０と受け取った限定鍵とを対応付けた情報を、記憶する。サーバ１１は携帯端末１０宛の付帯情報があったら、それを携帯端末１０に送信する。この時点で、携帯端末１０とサーバ１１との相互認証と、限定鍵の共有が完了し、サービスの暗号化通信が開始できる。
【００５１】
図１１は携帯端末１０がすでに認証サーバ１２に認証済みであり、認証に用いる限定鍵を共有している商店街のサーバにアクセスする場合の動作を示している。
【００５２】
利用者の携帯端末１０は、限定鍵の配付時に選択されて、既に限定鍵を共有しているサーバ２１に近づく。このとき、携帯端末１０は認証用情報を用いて認証をサーバ２１に要求する（ステップＳ１１０１）。
【００５３】
サーバ２１は受けた認証要求をもとに限定鍵を検索し、既に配付され登録されている限定鍵を抽出する。有効な限定鍵が複数ある場合は、適当な手段を用いて一つ選ぶ。例えば、商店街専用の鍵、後から配付された鍵、残っている有効期限の長い鍵、残使用回数の多い鍵、を選ぶ。
【００５４】
次に、サーバ２１は認証に用いる限定鍵そのものは送らずに、例えば、限定鍵を一方向関数に入力して計算される値や、限定鍵の生成に用いられた値を携帯端末１０に通知する（ステップＳ１１０２）。
【００５５】
次に、携帯端末１０は通知された限定鍵が識別できる情報から限定鍵を特定し、この限定鍵とサーバ２１から送信されたサーバの認証に用いる認証用情報を用いて新たな認証用情報を生成する。携帯端末１０はこれをサーバ２１に送信する（ステップＳ１１０３）。サーバ２１はこれを、限定鍵を用いて解読し、携帯端末１０の認証を行う。
【００５６】
図１２は利用者が商店街をでる場合、商店街の中で有効だった限定鍵を削除する動作を示している。
【００５７】
携帯端末１０は、サーバ３１に近づき、限定鍵を持っている場合と同様に認証を行う（ステップＳ１２０１）。
【００５８】
サーバ３１は認証後、限定鍵から通信終了後に限定鍵を削除する、という付帯情報を検出した場合、携帯端末１０との通信を終了する際、携帯端末１０に現行の限定鍵を削除することを通知する（ステップＳ１２０２）。そして、通知を受けた携帯端末１０は現行の限定鍵を削除する。
【００５９】
また、サーバ３１は鍵管理サーバ１３に、削除するべき限定鍵を持っているサーバの鍵を削除させるよう鍵管理サーバ１３に依頼する（ステップＳ１２０３）。
【００６０】
鍵管理サーバ１３はこの限定鍵を配付したサーバのネットワークアドレスを読み出し、削除要求するサーバを選択する。そして、鍵管理サーバ１３は選択されたサーバに、該当する限定鍵を削除するように通知する（ステップＳ１２０４）。そして、通知を受け取ったサーバは該当する限定鍵を削除する。
【００６１】
次に、本発明である暗号化通信システムの各構成物の構成と動作について、以下に説明する。
【００６２】
図２は、本発明の第一の実施の形態における携帯端末１０の構成を示すブロック図である。
【００６３】
図２において、携帯端末１０は、サーバ１１とのローカル通信を行う通信部２０１と、認証を要求する認証要求部２０２と、認証に必要な情報を保持する認証用情報記憶部２０３と、限定鍵生成部２０５と、サーバの認証を行う端末用認証部２０４と、データを暗号化したり復号化したりする端末用暗号・復号化部２０６と、認証用情報記憶部２０３内について指定の限定鍵の有無を判定する判定部２０７とを備えている。
【００６４】
この携帯端末１０は移動端末装置に相当し、その例として、携帯電話、ＰＤＡ、ノートパソコンなどが挙げられる。
【００６５】
なお、認証用情報記憶部２０３には、認証用情報の他に、限定鍵を識別する限定鍵識別情報を限定鍵と関連づけて、限定鍵と共に記憶している。この認証用情報の例としては、携帯端末１０を識別する端末識別情報（ＩＤ）や、認証サーバ１２との間であらかじめ共有する認証に用いる認証情報である共通鍵やパスワード、公開鍵暗号における秘密鍵などが挙げられる。
【００６６】
また、限定鍵生成部２０５は、サーバ１１へ送信する認証用情報と、共通鍵とから限定鍵を生成する。
【００６７】
以上のように構成された携帯端末１０について、図６を用いて以下にその動作を説明する。
【００６８】
まず、認証要求部２０２がサーバ１１に認証要求を通信部２０１を介して出力する（ステップＳ６０１）。
【００６９】
次に、認証要求部２０２は通信部２０１がサーバからの応答を受信したか否かをチェックし、所定時間内に受信しないとステップＳ６０１へ戻る（ステップＳ６０２）。
【００７０】
サーバ１１からの応答を受信した場合、認証要求部２０２は認証用情報記憶部２０３から認証用情報である端末識別情報（ＩＤ）と共通鍵（Ｋ）を取り出し、自らが保持している単調に増加する値である時間引数（ｔ）と乱数（ｒｎ）と共通鍵（Ｋ）とから署名された関数値ＨＭＡＣ（ｔ，ｒｎ）を算出する（ステップＳ６０３）。この関数値ＨＭＡＣ（ｔ，ｒｎ）は時間引数ｔと、乱数ｒｎの共通鍵Ｋによる署名ということができる。一般に、送信する情報と秘密の情報である共通鍵Ｋとを組み合わせた情報のハッシュ値をＨＭＡＣ値（（Ｋｅｙｅｄ）  Ｈａｓｈｉｎｇ  ｆｏｒ  Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）と呼ぶ。本文中の関数ＨＭＡＣはこのＨＭＡＣ値を計算する。ＨＭＡＣ値は共通鍵Ｋを知らないと正しい値が計算できないため、送ってきた相手が共通鍵Ｋを持っていることが確認できる。ハッシュ関数には例えば、ＭＤ５やＳＨＡ−１などが使用される。このハッシュ関数を使用することは、あらかじめ本発明の暗号化通信システムにおいて決められている。
【００７１】
次に、認証要求部２０２は関数値ＨＭＡＣ（ｔ，ｒｎ）、識別子ＩＤ、時間引数ｔ、及び乱数ｒｎ  を通信部２０１を介してサーバへ送信する（ステップＳ６０４）。
【００７２】
次に、通信部２０１はサーバ１１から応答を受信したか否かをチェックし、受信するまで待機する（ステップＳ６０５）。
【００７３】
次に、通信部２０１は応答と共に、限定鍵を特定する限定鍵識別情報（ＫＩＤ）を受信しなかった場合、その他に受信したサーバ１１が指定した第二の識別情報と、認証サーバ１２で生成された第三の識別情報とを、認証要求部２０２に通知する。この第二の識別情報はサーバ１１にて選択された任意の乱数ｒｎ２であり、第三の識別情報は時間引数ｔと乱数ｒｎとｒｎ２との共通鍵Ｋにより署名した関数値ＨＭＡＣ（ｔ，ｒｎ，ｒｎ２）である。認証要求部２０２は受信した乱数ｒｎ２と関数値ＨＭＡＣ（ｔ，ｒｎ，ｒｎ２）、共通鍵Ｋ、及びサーバ１１へ送信した時間引数ｔと乱数ｒｎとを端末用認証部２０４へ通知し、サーバ１１の認証を要求する（ステップＳ６０６）。
【００７４】
端末用認証部２０４は時間引数ｔ、乱数ｒｎ、ｒｎ２を共通鍵Ｋで署名した関数値が受信した関数値と同一か否かをチェックし、サーバの認証の可否を判断する。そして、その結果を認証要求部２０２へ返信する（ステップＳ６０７）。
【００７５】
認証要求部２０２はサーバ１１が認証されなかった場合は、この処理を終了し、認証された場合は認証用情報である乱数（ｒｎ）と共通鍵（Ｋ）とを限定鍵生成部２０５に通知し、それを用いて限定鍵の生成を指示する（ステップＳ６０８）。
【００７６】
次に、限定鍵生成部２０５は通知された乱数（ｒｎ）を共通鍵（Ｋ）で署名して限定鍵ＨＭＡＣ（ｒｎ）を作成する（ステップＳ６０９）。これは後述する鍵管理サーバ１３にて生成される限定鍵と同一のものである。限定鍵生成部２０５はこの限定鍵を認証要求部２０２へ引き渡し、認証要求部２０２はこの限定鍵とこの鍵から一方向関数により限定鍵識別情報（ＫＩＤ）を算出し、それに関連づけて限定鍵を認証用情報記憶部２０３に記憶する。そして、認証要求部２０２は端末用暗号・復号化部２０６に暗号化通信の開始を指示する。
【００７７】
次に、端末用暗号・復号化部２０６はこの限定鍵を用いて暗号化したデータを、通信部２０１を介してサーバに送信したり、あるいは通信部２０１を介して取得した暗号化データを復号化する（ステップＳ６１０）。この暗号化通信は携帯端末１０が移動してサーバ１１との通信可能域をはずれるまで続けられる。
【００７８】
一方、ステップＳ６０６において限定鍵を特定する限定鍵識別情報（ＫＩＤ）を受信した場合、これを判定部２０７に通知するとともに、特定された限定鍵が認証用情報記憶部２０３にあるか否かの判定を指示する。
【００７９】
判定部２０７はこれを受けて限定鍵の所有状況をチェックし、限定鍵がない場合は処理を終了する。限定鍵がある場合はその限定鍵を抽出して、限定鍵を認証要求部２０２へ返す（ステップＳ６１１）。
【００８０】
次に、認証要求部２０２はこの限定鍵と、時間引数ｔと、乱数ｒｎ、ｒｎ２と、限定鍵と共に受信した関数値ＨＭＡＣ’（ｔ，ｒｎ，ｒｎ２）とを端末用認証部２０４へ通知し、サーバ１１の認証の可否の判定を要求する。端末用認証部２０４はこれを受けて、時間引数ｔと乱数ｒｎ、ｒｎ２とを限定鍵Ｋ’で署名する。端末用認証部２０４はその署名結果がサーバから受信した関数値ＨＭＡＣ’（ｔ，ｒｎ，ｒｎ２）と同一になるか否かをチェックし、サーバの認証の可否を判断する（ステップＳ６１２）。そして、その結果を認証要求部２０２へ返信する。
【００８１】
次に、認証要求部２０２は認証がされなかった場合、処理を終了し、認証がされた場合、端末用暗号・復号化部２０６にこの限定鍵を引き渡す（ステップＳ６１３）。
【００８２】
次に、端末用認証部２０４は時間引数ｔと乱数ｒｎ２を限定鍵Ｋ’で署名して関数値ＨＭＡＣ’（ｔ、ｒｎ２）を求め、これを認証要求部２０２へ通知する。認証要求部２０２はこの関数値ＨＭＡＣ’（ｔ、ｒｎ２）をサーバ認証用情報として、通信部２０１を介してサーバ１１へ送信する（ステップＳ６１４）。その後、ステップＳ６１０へ移行する。
【００８３】
以上のように、本実施の形態での携帯端末１０は、限定鍵をすでに保有している場合、限定鍵の受信を待つ必要がないので、これを用いて高速に認証を行い、暗号化通信を開始することができる。
【００８４】
なお、本実施の形態では、携帯端末１０は限定鍵を１つのみ所有してサーバとの認証を行っているが、これに限らず、使用目的や使用条件により、複数の限定鍵を保有することができる。この場合、サーバから限定鍵を指定されるばかりでなく、携帯端末がサーバへ認証を要求する際に、限定鍵識別情報を送信し、限定鍵を特定した認証を要求することも可能である。
【００８５】
図３は本発明の第一の実施の形態におけるサーバ１１の構成を示すブロック図である。
【００８６】
サーバ１１は、携帯端末１０とのローカル通信を行う通信部３０１と、携帯端末１０の限定鍵による認証の可否を判断し、認証が不可の場合には認証を認証サーバ１２に要求する限定認証部３０２と、限定鍵を追加、削除、更新、あるいは検索が可能な形式で保持する鍵データベースである限定鍵記憶部３０３と、鍵管理サーバ１３からの鍵管理通知を受け取り、限定鍵記憶部３０３内のデータを変更する鍵操作部３０４と、データを暗号化したり復号化したりする暗号・復号化部３０５とを備えている。限定鍵記憶部３０３はサーバ１１が受け取った限定鍵をどの携帯端末のものか識別できるように、携帯端末の識別情報と対応させて保持する。識別情報としては、端末識別情報、限定鍵識別情報、またはそれらの組み合わせがある。携帯端末１０は使用目的や使用条件により、複数の限定鍵を保有しているため、１つの端末識別情報に対してサーバ１１が保持すべき限定鍵は一つとは限らない。なお、図１に示すように、このようなサーバは一般に複数存在している（サーバ２１、サーバ３１）。以上のように構成されたサーバ１１について、図７を用いて以下にその動作を説明する。
【００８７】
まず、通信部３０１は携帯端末１０からの認証要求を受信したか否かをチェックし、受信するまで待機する（ステップＳ７０１）。
【００８８】
次に、通信部３０１が認証要求を受信すると携帯端末１０に応答を送信する（ステップＳ７０２）。
【００８９】
次に、限定認証部３０２は通信部３０１を介して認証用情報として端末識別情報ＩＤ、時間引数ｔ、乱数ｒｎ、及び関数値ＨＭＡＣ（ｔ，ｒｎ）を受信する（ステップＳ７０３）。
【００９０】
次に、限定認証部３０２はこの通知を受けて、限定鍵記憶部３０３から受信した端末識別情報ＩＤに対応する限定鍵を検索する（ステップＳ７０４）。
【００９１】
限定鍵がみつからない場合、限定認証部３０２は携帯端末１０から受け取ったこれら認証用情報に加え、第二の認証用情報である、自らが指定する任意の乱数ｒｎ２を認証サーバ１２に送信し、認証を要求する（ステップＳ７０５）。
【００９２】
次に、限定認証部３０２が認証サーバ１２から認証結果と関数値ＨＭＡＣ（ｔ，  ｒｎ，  ｒｎ２）とを受信する。携帯端末１０が認証されると（ステップＳ７０６）、鍵操作部３０４が鍵管理サーバ１３から限定鍵Ｋ’と、端末識別情報ＩＤとを受信する。この限定鍵Ｋ’から一方向関数により限定鍵識別情報ＫＩＤを計算し、限定鍵Ｋ’と限定鍵識別情報ＫＩＤとを端末識別情報ＩＤに関連付けて、図１９（ａ）、（ｂ）、あるいは（ｃ）に示すデータ構造で限定鍵記憶部３０３に保存する（ステップＳ７０７）。
【００９３】
次に、限定認証部３０２は携帯端末１０へ、乱数ｒｎ２と関数値ＨＭＡＣ（ｔ，  ｒｎ，ｒｎ２）とを送信し、認証を要求する（ステップＳ７０８）。このとき、サーバ１１は自分のＩＤなどの情報も送信してもよい。
【００９４】
次に、限定認証部３０２は暗号・復号化部３０５に限定鍵Ｋ’を引き渡し、暗号化通信の開始を指示する。暗号・復号化部３０５はこの限定鍵Ｋ’を用いて暗号化したデータを、通信部３０１を介して携帯端末１０に送信したり、あるいは通信部３０１を介して取得した暗号化データを復号化する（ステップＳ７０９）。この暗号化通信は携帯端末１０へのサービスの提供期間中行われ、その後終了する。
【００９５】
ステップＳ７０６において、携帯端末１０が認証されなかった場合、限定認証部３０２は携帯端末へその旨を通知する（ステップＳ７１０）。
【００９６】
一方、ステップＳ７０４において、限定鍵が見つかった場合、限定認証部３０２は任意に選択した乱数ｒｎ２と、限定鍵識別情報ＫＩＤと、携帯端末から受信した時間引数ｔ、乱数ｒｎ、および自ら選択した乱数ｒｎ２を限定鍵Ｋ’で署名した関数値ＨＭＡＣ’（ｔ，ｒｎ，ｒｎ２）とを携帯端末１０に送信し、認証を要求する（ステップＳ７１１）。
【００９７】
次に、限定認証部３０２は携帯端末１０から認証の応答として時間引数ｔと乱数ｒｎ２を限定鍵Ｋ’で署名した関数値ＨＭＡＣ’（ｔ，ｒｎ２）を通信部３０１を介して受信する（ステップＳ７１２）。
【００９８】
次に、限定認証部３０２は自ら時間引数ｔと乱数ｒｎ２を限定鍵Ｋ’で署名した関数値を算出し、受信した関数値ＨＭＡＣ’（ｔ，ｒｎ２）と同一か否かをチェックする（ステップＳ７１３）。同一でなかった場合、携帯端末の認証をせず処理を終了する。同一であった場合、限定認証部３０２は携帯端末を認証し、限定鍵に附属の付帯情報に記載されている、有効期限が切れる状態であるか否かをチェックする（ステップＳ７１４）。有効期限が切れていないと判定した場合、ステップＳ７０９へ移行し、切れると判定した場合、限定認証部３０２は鍵管理サーバ１３にこの限定鍵の削除を要求する（ステップＳ７１５）。その後、ステップＳ７０９へ移行する。なお、この付帯情報としては、有効期限の他に、選択したサーバの中で、地域の境界や、通りの端に位置するもの、あるいは最も遠い距離のサーバに、携帯端末へのサービスの提供後に限定鍵の削除を指示するものであったり、全配付先のサーバに限定鍵を削除する時刻を通知するものであったり、サービスの提供する許容回数であったり、あるいは、サービスの許容データ量であったりする。
【００９９】
以上のように、本実施の形態でのサーバ１１は、携帯端末とサーバとの間で限定鍵が共有されていない場合は認証サーバとの通信が発生するが、それ以後、携帯端末とサーバとの間で限定鍵が共有されている場合には、認証サーバとの通信が不要となるため、認証サーバへの認証依頼頻度を減らすことができる。また、限定鍵を用いて暗号化通信を行うこともでき、高速に安全な通信を開始することができる。また、限定鍵に附属の付帯情報を活用することにより、限定鍵を適時に消滅することもでき、限定鍵が氾濫することを防止できる。
【０１００】
図４は本発明の第一の実施の形態における認証サーバ１２の構成を示すブロック図である。
【０１０１】
認証サーバ１２は、携帯端末１０の認証処理を行う認証部４０１と、認証に必要な情報を保持する認証情報記憶部４０２と限定鍵の生成を行う限定鍵生成部４０３とを備えている。そして、この認証サーバ１２は限定鍵生成装置に相当する。
【０１０２】
以上のように構成された認証サーバ１２について、図８を用いて以下にその動作を説明する。
【０１０３】
まず、認証部４０１はサーバ１１から携帯端末１０の認証要求と共に、端末識別情報ＩＤと，時間引数ｔと、乱数ｒｎ、ｒｎ２とこれら時間引数ｔと、乱数ｒｎとを共通鍵Ｋで署名された関数値ＨＭＡＣ（ｔ，ｒｎ）を受信する（ステップＳ８０１）。
【０１０４】
次に、認証部４０１はこの受信した端末識別情報ＩＤに対応した共通鍵Ｋを認証情報記憶部４０２から抽出し、時間引数ｔと乱数ｒｎとを共通鍵Ｋで署名した関数値ＨＭＡＣ（ｔ，ｒｎ）を算出する（ステップＳ８０２）。
【０１０５】
次に、認証部４０１はこの算出結果と、サーバから受信した関数値ＨＭＡＣ（ｔ，ｒｎ）とが一致するか否かをチェックし（ステップＳ８０３）、一致しなかった場合は、サーバ１１に認証不可を通知する（ステップＳ８０４）。
【０１０６】
一致した場合、認証部４０１はこの共通鍵Ｋと乱数ｒｎとを限定鍵生成部４０３へ引き渡す。限定鍵生成部４０３はこれを受けて、乱数ｒｎを共通鍵Ｋで署名した関数値ＨＭＡＣ（  ｒｎ）を算出し、限定鍵Ｋ’を生成する。また、認証部４０１は時間引数ｔと乱数ｒｎ、ｒｎ２とを共通鍵Ｋで署名した関数値ＨＭＡＣ（ｔ，  ｒｎ，  ｒｎ２）を算出する。これら限定鍵Ｋ’と、関数値ＨＭＡＣ（ｔ，  ｒｎ，  ｒｎ２）と、端末識別情報ＩＤとをサーバ１１に送信する（ステップＳ８０５）。
【０１０７】
次に、限定鍵Ｋ’と端末識別情報ＩＤとを鍵管理サーバ１３に送信する。（ステップＳ８０６）。
【０１０８】
以上のように、本実施の形態での認証サーバ１２は、限定鍵を持っていないサーバから転送された認証要求に対して認証を行い、限定鍵を生成し、鍵管理サーバに限定鍵の配付を依頼することにより、他のサーバと端末との間であらかじめ限定鍵を共有しておけるため、認証サーバへの認証依頼頻度を減らし、利用者が移動していても、認証を高速に行い、暗号化通信を開始することが可能となる。
【０１０９】
図５は本発明の第一の実施の形態における鍵管理サーバ１３の構成を示すブロック図である。鍵管理サーバ１３は、限定鍵の配付先のサーバを管理する限定鍵管理部５０１と、限定鍵の配付先を決定する配付先選択部５０２と、その配付先の決定に用いる配付先選択情報記憶部５０３とを備えている。
【０１１０】
配付先選択情報記憶部５０３はサーバ１１の所在位置と各サーバ間の距離、あるいは道路と設置されているサーバとが関連付けられたデータベースとして記録されている。
【０１１１】
以上のように構成された鍵管理サーバ１３について、図９（ａ）と（ｂ）を用いて以下にその動作を説明する。
【０１１２】
図９（ａ）において、まず、限定鍵管理部５０１は認証サーバ１２から限定鍵Ｋ’とその限定鍵Ｋ’の要求元である携帯端末を特定する端末識別情報と共に、その限定鍵の配付の要求を受信する（ステップＳ９０１）。
【０１１３】
次に、限定鍵管理部５０１は配付先選択部５０２に認証サーバ１２から受け取った限定鍵Ｋ’と端末識別情報ＩＤとを伝える。配付先選択部５０２はこれを受けて、配付先選択情報記憶部５０３から受け取った端末識別情報ＩＤと同一の通りにあるサーバを選択したり、あるいは端末識別情報ＩＤから所定の距離に位置するサーバを選択したりし、そのサーバのネットワークアドレスを抽出し、配付先記憶部５０４に記憶する（ステップＳ９０２）。この配付先の選択はこの他に、ある時間内に到達できるサーバを選ぶ、などのようにあらかじめ適しているサーバのリストを登録しておいて静的に決定することもできるし、利用履歴、天気情報などを利用して雨の日に、アーケードの本屋をよく利用するからそこに配付する、のように動的に決定することも可能である。さらに、利用者に利用者の嗜好や行動の目的を入力・選択させ、その情報を推測に利用することも可能である。音楽が好きである、とわかればＣＤショップによく立ち寄ることが推測されるし、食事が目的とわかれば飲食店に行くことが推測される。また、携帯端末１０は利用者が携帯端末１０に保存しているスケジュール情報をサーバ１０に認証後送信し、それを鍵管理サーバ１３にサーバ１１が通知することにより、鍵管理サーバ１３が限定鍵の配付先選択に利用することもできる。
【０１１４】
次に、配付先選択部５０２は鍵管理部５０１へ選択したこれらのサーバのネットワークアドレスを通知する。このとき、配付先選択部５０２は、限定鍵に付帯情報を付加して通知する。
【０１１５】
次に、鍵管理部５０１は選択された配付先のサーバに限定鍵と端末識別情報とを配付する（ステップＳ９０３）。
【０１１６】
以上のように、本実施の形態での鍵管理サーバ１３は、限定鍵の配付先を効率よく選択でき、サーバと携帯端末との間で前もって限定鍵を共有しておくことができるため、認証サーバへの認証を依頼する頻度を減らし、利用者が移動していても、認証を高速に行い、暗号化通信を開始することが可能となる。
【０１１７】
図９（ｂ）は、鍵管理サーバ１３が行うもう一つの動作である、限定鍵の削除処理を示すフローチャートである。
【０１１８】
まず、限定鍵管理部５０１がサーバ１１から限定鍵の削除の要求を受信するまで待機する（ステップＳ９１０）。
【０１１９】
次に、限定鍵管理部５０１はこの要求を受けて、受信した限定鍵識別情報ＫＩＤを配付先選択部５０２に通知し、この限定鍵を配付したサーバのネットワークアドレスのリストを要求する。配付先選択部５０２は配付先記憶部５０４に記憶してある配付先のサーバのネットワークアドレスを読み出し、その結果を限定鍵管理部５０１に通知する（ステップＳ９１１）。
【０１２０】
次に、限定鍵管理部５０１は通知されたサーバに限定鍵識別情報と共に、この限定鍵の削除を指示する（ステップＳ９１２）。
【０１２１】
これらにより、有効期限の切れた限定鍵を漏らすことなく消滅させることができる。この限定鍵の削除の要求は、上記したサーバが付帯情報をチェックすることにより発生したが、付帯情報としては、以下に説明するようなものがある。
【０１２２】
付帯情報には、利用可能な時間、回数、対象サーバ、その限定鍵で通信できる情報の内容、その限定鍵で暗号化できる情報のバイト数など、さまざまな条件が設定されており、有効であるための条件を満たしていない限定鍵は無効な鍵として扱われる。無効な限定鍵は、サーバとの相互認証や暗号化通信に用いることができない。このため、限定鍵には有効状態の鍵と、無効状態の鍵とが存在する。
【０１２３】
そして、削除される条件を満たすか、有効であるための条件を満たせなくなった限定鍵は削除される。削除される条件は、このサーバと通信した場合、終了時に限定鍵を削除するなどである。有効であるための条件を満たせなくなる場合は、有効期間が過ぎてしまった場合や、使用回数が超えてしまった場合などである。
【０１２４】
また、限定鍵の削除は、本実施の形態では鍵管理サーバが各サーバに限定鍵削除通知を行い、各サーバが鍵管理サーバからの通知内容に従い、自分の保持する限定鍵を削除するものであったが、これに限らず、サーバが自分の保持する限定鍵のみを削除することも可能である。
【０１２５】
以上のように、付帯情報を付加することにより、柔軟に限定鍵の制御を行うことができる。
【０１２６】
なお、本発明の形態では、認証サーバ１２や鍵管理サーバ１３はそれぞれ一台であったが、複数台設置し、負荷分散を行うなどしてもかまわない。また、認証サーバ１２と鍵管理サーバ１３は個別に存在していても、あるいはひとつに機能をまとめてもかまわない。この一つにまとめたものが、鍵管理装置に相当する。
【０１２７】
次に、図１３（ａ）と（ｂ）を用いて、本実施の形態の暗号化通信システムにおける、構成物間での限定鍵の共有、および認証処理の詳細な具体例を説明する。図１３（ａ）は本発明の第一の実施の形態の限定鍵がない場合の手順を示すシーケンス図である。
【０１２８】
まず、携帯端末１０がサーバ１１を検出すると、携帯端末１０は端末識別情報（ＩＤ）と自らが保持している単調に増加する値である時間引数（ｔ）、乱数（ｒｎ）、さらにｔとｒｎを共通鍵Ｋで署名した関数値ＨＭＡＣ（ｔ，ｒｎ）をサーバ１１へ送信する（ステップＳ１３０１）。
【０１２９】
次に、サーバ１１は限定鍵記憶部３０３を検索して受け取ったＩＤに対応する限定鍵を持っていないことを確認する。そして、サーバ１１は携帯端末１０から受け取った情報に加え、自らが指定する乱数ｒｎ２を認証サーバ１２に送信する（ステップＳ１３０２）。
【０１３０】
次に、認証サーバ１２は受け取った端末識別情報ＩＤからこの携帯端末１０に対応した共通鍵Ｋを検索し、時間引数ｔと乱数ｒｎを、共通鍵Ｋで署名した関数値ＨＭＡＣ（ｔ，ｒｎ）を計算し、受信したものとの一致を確認する。一致しなかった場合、認証サーバ１２はサーバ１１に認証失敗と通知する。一致した場合は、関数値ＨＭＡＣ（ｒｎ）を計算して、これを限定鍵Ｋ’とし、端末識別情報ＩＤ，限定鍵Ｋ’，共通鍵Ｋで署名した関数値ＨＭＡＣ（ｔ，  ｒｎ，  ｒｎ２）をサーバ１１に送信する（ステップＳ１３０３）。
【０１３１】
次に、サーバ１１は限定鍵Ｋ’から一方向関数により限定鍵識別情報ＫＩＤを計算し、限定鍵Ｋ’と限定鍵識別情報ＫＩＤとを端末識別情報ＩＤと関連付けて限定鍵記憶部３０３に保存する。サーバ１１は乱数ｒｎ２と、共通鍵Ｋで署名した関数値ＨＭＡＣ（ｔ，  ｒｎ，  ｒｎ２）とを携帯端末１０に送信する（ステップＳ１３０４）。このとき、サーバ１１は自分のＩＤを伝えるなど追加の情報を提供することもできる。
【０１３２】
携帯端末１０は時間引数ｔと乱数ｒｎ、ｒｎ２とから共通鍵Ｋで署名した関数値ＨＭＡＣ（ｔ，  ｒｎ，  ｒｎ２）を計算し、サーバ１１から送られてきたものと一致していることを確かめる。一致してなければ、サーバ１１は信頼できないものと判断して通信を中断する。
【０１３３】
一致していれば、携帯端末１０はサーバ１１を認証する。
【０１３４】
次に、携帯端末１０は限定鍵Ｋ’（＝ＨＭＡＣ（ｒｎ））を計算し、限定鍵Ｋ’から限定鍵識別情報ＫＩＤを計算し、限定鍵Ｋ’を限定鍵識別情報ＫＩＤと対応付けて認証用情報記憶部２０３に保存する。この時点で、携帯端末１０とサーバ１１は限定鍵Ｋ’を共有し、かつ、相互認証が済んだことになる。その後、携帯端末１０とサーバ１１は限定鍵Ｋ’による暗号化通信を開始する（ステップＳ１３０５）。
【０１３５】
次に、図１３（ｂ）は本発明の第一の実施の形態の携帯端末１０とサーバ１１とで限定鍵Ｋ’を共有している場合の手順を示すシーケンス図である。
【０１３６】
まず、携帯端末１０がサーバ１１と出会い、通信を開始すると、携帯端末１０は端末識別情報（ＩＤ）と時間引数（ｔ）、乱数（ｒｎ）、さらに時間引数ｔと乱数ｒｎを、共通鍵Ｋで署名した関数値ＨＭＡＣ（ｔ，ｒｎ）を計算して送信する（ステップＳ１３０１）。この部分は図１３（ａ）に示した限定鍵を共有していない場合と同じであり、最初の携帯端末１０の動作は常に同じである。
【０１３７】
次に、サーバ１１は限定鍵記憶部３０３に受け取った端末識別情報ＩＤの限定鍵Ｋ’を持っていることを確認する。付帯情報により、その限定鍵が有効であるか、削除すべきであるかを確認する。削除すべき限定鍵がある場合は、削除すべき限定鍵を限定鍵記憶部３０３から削除する。有効な限定鍵が一つもない場合は、図１３（ａ）に示した限定鍵を共有してない場合と同様の動作を行う。有効な限定鍵を複数持っている場合は、付帯情報にある限定鍵の新しさなどの情報を用いて、利用する限定鍵Ｋ’を決定する。
【０１３８】
次に、サーバ１１は限定鍵Ｋ’を選んだ後、乱数ｒｎ２、限定鍵Ｋ’の限定鍵識別情報ＫＩＤ、時間引数ｔと乱数ｒｎ、ｒｎ２を、限定鍵Ｋ’で署名した関数値ＨＭＡＣ’（ｔ，  ｒｎ，  ｒｎ２）を携帯端末１０に送信する（ステップＳ１３１０）。このとき、サーバ１１は自分のＩＤを伝えるなど追加の情報を提供することもできる。
【０１３９】
次に、携帯端末１０は受け取った限定鍵識別情報ＫＩＤから対応する限定鍵Ｋ’を取得し、時間引数ｔと乱数ｒｎ、ｒｎ２を限定鍵Ｋ’で署名した関数値ＨＭＡＣ’（ｔ，  ｒｎ，  ｒｎ２）を計算する。送られてきた値と一致していなければ、携帯端末１０はサーバ１１を信頼できないものとして通信を中断する。一致していた場合は、時間引数ｔと乱数ｒｎ２とを限定鍵Ｋ’で署名した関数値ＨＭＡＣ’（ｔ，  ｒｎ２）を計算し、サーバ１１に送信する（ステップＳ１３１１）。
【０１４０】
次に、サーバ１１は時間引数ｔと乱数ｒｎ２を限定鍵Ｋ’で署名した関数値ＨＭＡＣ’（ｔ，  ｒｎ２）を計算する。送られてきた値と一致していなければ、サーバ１１は携帯端末１０を信頼できないものとして通信を中断する。一致していれば、携帯端末１０とサーバ１１は限定鍵Ｋ’を共有し、かつ、相互認証が済んでいるので、限定鍵Ｋ’による暗号化通信を開始する（ステップＳ１３１２）。
【０１４１】
なお、本実施の形態においては、ステップＳ１３０４で時間引数ｔと乱数ｒｎ、ｒｎ２とから共通鍵Ｋで署名した関数値ＨＭＡＣ（ｔ，  ｒｎ，  ｒｎ２）を携帯端末１０が受信した後に限定鍵を算出しているが、これに限らず、携帯端末１０は最初の乱数ｒｎをサーバ１１に送信後、すぐに限定鍵Ｋ’を計算し、認証用情報記憶部２０３に有効化待ちの限定鍵Ｋ’として保存しておくこともできる。この有効化待ちの限定鍵は携帯端末１０が信頼できるサーバ１１から、限定鍵を有効にするという通知を受けるか、あるいは認証に使う限定鍵として指定されない限り、有効にならない。これにより、最初にステップＳ１３０１で認証用情報を送信した後に、通信不能となって別のサーバ２１と通信することになっても、認証サーバ１２で認証に成功すれば、限定鍵の配付はこのサーバ２１に行われるため、いつまでも限定鍵Ｋ’を共有できないという状態が避けられる。
【０１４２】
また、携帯端末１０は限定鍵の付帯情報に従って、所定のタイミングで有効化待ちの状態にある限定鍵を削除する。この削除する限定鍵を指定する付帯情報は次のようなものがある。
１）作成してから有効にならないまま一定時間が経過した鍵
２）有効化待ちの鍵の個数がある閾値を超えた場合、一番古い鍵
これにより、使われない有効化待ちの限定鍵が多数保存されてしまうことを防ぐことができる。
【０１４３】
なお、これら有効化待ちの限定鍵の削除を行うことにより、サーバ１１から認証に利用する限定鍵として指定された限定鍵識別情報ＫＩＤに対応する限定鍵が携帯端末１０側に存在しない場合は、例えば、別の有効な限定鍵がないか問い合わせ、一つもなければ限定鍵なしの場合に切り替える。ただし、この有効化待ちの限定鍵を使う方法は限定鍵として関数値ＨＭＡＣ（ｒｎ）を使う場合に限られる。
【０１４４】
以上のように本実施の形態では、サーバ１１と携帯端末１０との間で前もって限定鍵を共有しておくことができるため、認証サーバ１２への認証を依頼する頻度を減らすことができ、また、利用者が移動していても、認証を高速に行い、暗号化通信を開始することが可能となる。
【０１４５】
さらに、限定鍵を共有していない場合には、携帯端末１０の認証が終わらないうちにサーバ１１との通信が切れてしまったときにおいても、携帯端末１０の認証要求が認証サーバ１２に渡り、認証が成功すれば、限定鍵が、その後携帯端末１０が接続するサーバにも配付される。そのため、携帯端末１０が次に別のサーバにアクセスしたときにも、限定鍵を共有した状態とすることができので、何度も認証が間に合わずにサービスが受けられないということが避けられる。
【０１４６】
なお、本実施の形態では認証サーバは一つしかないことになっているが、複数用意してもかまわない。その場合には、最初にサーバが、自分が属している認証サーバのＩＤを携帯端末に送信する必要がある。
【０１４７】
なお、ステップＳ１３０１の時点で、携帯端末１０が自ら保持する限定鍵の全部または一部のそれぞれ毎に認証要求を生成し、使用した限定鍵識別情報と組にしてサーバ１１に送信しても良い。この場合、サーバ１１は携帯端末１０から送られた限定鍵の中で、保持していて、かつ、有効であることが確認された限定鍵で相互認証を行う。さらに、先に、限定鍵による認証要求を送信することでやりとりの回数を減らすことができる。ただし、この場合、限定鍵識別情報から限定鍵を抽出できるように、限定鍵記憶部３０３に図１９（ｂ）または（ｃ）の形式で保存されている必要がある。図１９（ｂ）のように限定鍵識別情報とのみ対応させる場合は、限定鍵記憶部３０３から端末識別情報が得られないため、広告を配るサーバである場合など、端末識別情報があまり重要でない場合に有効である。
【０１４８】
また、本実施の形態では、限定鍵は、関数値ＨＭＡＣ（ｒｎ）としたが、これに限らず、サーバの乱数を使って関数値ＨＭＡＣ（ｒｎ２）としても良い。あるいは、認証サーバが独自の乱数ｒｎ３を発生させて関数値ＨＭＡＣ（ｒｎ３）としてもよいし、関数値ＨＭＡＣ（ｒｎ，ｒｎ２）、関数値ＨＭＡＣ（ｒｎ，ｒｎ２，ｒｎ３）などと組み合わせてもよい。
【０１４９】
関数値ＨＭＡＣ（ｒｎ）を使う利点は、携帯端末が自ら他に情報を得ずに限定鍵を生成できる点である。認証サーバの指定した乱数ｒｎ３を用いた場合には携帯端末にそれらの値を送信する必要がある。乱数ｒｎ３の送信は暗号化されてなくてもよい。乱数ｒｎ，ｒｎ２，ｒｎ３を組み合わせる利点は、複数の乱数を用いることにより鍵をより予測しにくくすることである。
【０１５０】
さらに、限定鍵は最終的に共有できればよく、携帯端末や認証サーバが生成した鍵そのものを暗号化して相手に渡してもかまわない。
【０１５１】
また、限定鍵を共有していない状態での認証方法は認証サーバを用意しなくても良く、例えばサーバに秘密鍵を置くことを許容するならば、直接サーバと公開鍵を使った認証を行ってもよい。認証後に共有される限定鍵を配付し、この限定鍵を認証に使うことによって、以降の認証を高速に行えるからである。
【０１５２】
なお、鍵管理サーバ１３は、配付先のサーバが複数のグループを形成しているような場合、そのサーバグループ毎に異なる限定鍵を配付しても良い。これにより、例えば、組織の違うサーバグループ毎で同じ限定鍵を所持することを回避できるので、セキュリティを向上することが可能となる。このとき、携帯端末はサーバグループ毎の限定鍵を所持する。通信用の鍵をサーバグループ毎に別々に所有することにより、他のサーバグループのサーバの管理者が限定鍵を用いて盗聴することを防ぐことができる。あるいは、限定鍵による認証終了後、その限定鍵で暗号化通信を行わずに、新たな鍵の交換を行い、暗号化はその鍵で行うことにしてもよい。
【０１５３】
（第二の実施の形態）
図１５は、本発明の第二の実施の形態の移動端末装置である携帯端末１０の構成を示すブロック図である。図１５において、第一の実施の形態の構成に加えて携帯端末１０は通信履歴記憶部１５０１を備える。この通信履歴記憶部１５０１は、過去数回分のアクセスしたサーバの識別子とアクセスした時刻とを記憶している。認証要求部２０２はこの通信履歴を鍵管理サーバ１３へ新しくサーバにアクセスする度に、その接続したサーバを介して送信する。
【０１５４】
また、本発明の第二の実施の形態の鍵管理サーバ１３は、その通信履歴を受信すると配付先選択情報記憶部５０３に蓄積する。配付先選択部５０２は鍵配付先選択情報として、携帯端末１０により送信されるこの通信履歴の情報を利用して利用者がアクセスする確率をサーバ個々について推定する。
【０１５５】
以下に、配付先選択部５０２が配付先選択情報記憶部５０３に蓄積された、不特定多数の携帯端末から寄せられた通信履歴の情報から次に携帯端末１０がアクセスする確率をサーバ個々について推定する方法について図１４を用いて説明する。
【０１５６】
利用者が、サーバｍ（１４０１）にいるときに、次に利用者がアクセスしたことのあるサーバとして、サーバｑ（１４０２）、サーバｒ（１４０３）があるとする。このとき、次に利用者が到達するサーバがサーバｑ（１４０２）、サーバｒ（１４０３）である確率を推定する。
【０１５７】
以下に確率を推定する原理を説明する。配付先選択情報記憶部５０３には、過去にサーバｍ（１４０１）に到達した１０回のうち、次に到達したサーバがサーバｑ（１４０２）であった回数が８回、サーバｒ１であった回数が２回だったという頻度情報が保持されている。配付先選択部５０２は、この頻度情報から、今サーバｍ（１４０１）にいる利用者が次にサーバｑ（１４０２）に到達する確率は８／１０＝０．８であり、サーバｒ（１４０３）に到達する確率は２／１０＝０．２であると推定する。配付先として選択するかどうかを決める閾値Ｔとして０．３を選んでいたとすると、配付先選択部５０２はサーバｑ（１４０２）を鍵の配付先として選択する。
【０１５８】
このままでは、隣接するサーバしか選択されないので、その先のサーバに到達する確率の推定も行う。選択されたサーバ各々について同様の計算を繰り返し、各々のサーバに到達する確率をさらに乗算する。例えば、サーバｑ（１４０２）の次に到達するサーバとして、サーバｓ（１４０４）、サーバｔ（１４０５）があり、８回のうち、それぞれ６回、２回到達していたとする。このとき、サーバｓ（１４０４）に到達する確率は０．８×６／（６＋２）＝０．６、サーバｔ（１４０５）に到達する確率は０．８×２／（６＋２）＝０．２と計算される。さらに閾値Ｔと比較して、サーバｓ（１４０４）を選択し、到達する確率が閾値Ｔ以上のサーバがなくなるまで繰り返す。あるサーバに到達するのに複数のパスが存在しうるが、それらは独立して扱っても良いし、例えば和をとっても良い。和をとる場合には、あるサーバが選択されたのに途中のパスにあるサーバが選択されないことが起きうるので注意が必要である。
【０１５９】
そして、さらに一つ前のサーバがどのサーバであったかも考慮に入れて頻度を計数し、確率を推定する。
【０１６０】
これにより、ある方向からサーバｍ（１４０１）に来た場合と、その逆方向から来た場合とが同等に扱われ、歩いている方向と逆方向のサーバへ向かう確率も高い確率と推定され、選択されてしまうことを防止できる。
【０１６１】
なお、配付先選択情報記憶部５０３の更新は、携帯端末１０がサーバ１１と通信を開始する際に行われる。具体的には、通信履歴としては、新たなサーバ１１との通信の直前とその一つ前に接続していたサーバの識別子ＩＤと、アクセスした時刻とのリストである。携帯端末１０からこのリストを受け取ったサーバ１１はリストを、配付先選択部５０２に伝える。リストを受け取った配付先選択部５０２は配付先選択情報記憶部５０３の情報の更新を行う。
【０１６２】
なお、この情報が更新されるタイミングは携帯端末１０がサーバと通信するたびに更新が行われる以外にも、携帯端末１０がサーバに一定回数アクセスした時点や、１日に１回といった一定時間経過後に始めてサーバにアクセスした時点などがある。あるいは、サーバが携帯端末１０からアクセスしてきた際に限定鍵を有していた場合も、限定認証部３０２が、鍵管理サーバ１３の配付先選択部５０２に携帯端末１０の通信履歴などの配付先選択情報を伝えて、配付先選択情報記憶部５０３の更新をすることもできる。この通信は携帯端末１０との通信とは無関係に行われるので、遅延を生じさせる恐れはない。また、鍵管理サーバ１３の負荷等を考慮に入れ、例えば、サーバが携帯端末からの通信履歴をある程度蓄積し、それらをまとめてから鍵管理サーバ１３に送信しても良い。なお、この頻度の精度は要求されない。また、サーバｍ（１４０１）からサーバｒ（１４０３）に移ったことがない場合にはサーバｒ（１４０３）には配付されないため、頻度の初期設定を適切に行っておくことも必要である。
【０１６３】
なお、閾値Ｔは低い値にするほど多く配付されるが、あまりに低いと配付先が多くなり、鍵管理サーバの負荷が高くなってしまう。そこで鍵管理サーバ１３の負荷などを考慮して、配付先が所定数を越える場合は、閾値Ｔを少し高くするなど動的に変化させることもできる。
【０１６４】
さらにまた、他の選択方法として、現在アクセスしているサーバに近いところから確率の高いサーバを、所定の配付先数の上限まで選択するものも可能である。
【０１６５】
また、決定した配付先に配付するときに、近いところから配付することは、次に通信を開始するまでに限定鍵の配付が間にあわないといった可能性が減るため好ましい。
【０１６６】
さらに、頻度の数え方は利用者や時間帯、グループ毎で別々にしてもよい。
【０１６７】
図１６（ａ）は、グループ毎に通信履歴を分けて鍵管理サーバ１３が蓄積する場合の鍵管理サーバ１３の構成を示すブロック図である。
【０１６８】
図１６（ａ）において、携帯端末がどのグループに属しているかを示すグループ識別情報ＩＤを保有しておくグループＩＤ記憶部１６０１を有している点がそれまでのものと異なり、携帯端末の端末識別情報とグループ識別情報ＩＤとを関連づけて蓄積している。
【０１６９】
配付先選択部５０２は限定鍵管理部５０１を介して得られた携帯端末の通信履歴を、その携帯端末が属するグループの識別子が何かをグループＩＤ記憶部１６０１の情報から求め、配付先選択情報記憶部５０３にグループＩＤ毎に蓄積する。
そして、配付先選択部５０２が限定鍵管理部５０１から配付先の選択を指示された場合、その限定鍵の要求元の携帯端末が属するグループの通信履歴を用いて配付先を選択する。
【０１７０】
なお、グループＩＤ記憶部に、有効なグループ識別情報ＩＤだけ保存しておき、携帯端末にグループ識別情報ＩＤを送信させ、鍵管理サーバは有効であるかどうか確認し、有効であれば、そのグループに属しているものと扱うようにしても良い。無効である場合には、どのグループでもないデフォルトのグループにするか、グループ別ではなく全体の履歴情報を用いるようにすれば良い。
【０１７１】
なお、通信履歴を携帯端末が送信せずに、サーバが携帯端末からのアクセスがあった時刻と、その端末の端末識別情報を集め、鍵管理サーバに送信し、鍵管理サーバが集計することによりアクセス頻度情報を得ることも可能だが、推測を行うためにアクセスした順番が重要であるため、サーバ同士で時計を合わせなくてはならない。
【０１７２】
以上のように本実施の形態では、携帯端末が備える通信履歴記憶部から、次にアクセスするサーバの推定確率を計算することができ、利用者の行動傾向の推定に基づいた効率の良い配付先の選択が可能になる。
【０１７３】
すなわち、街中に多くのサーバが置いてある状況で、多数の利用者が移動しているとする。利用者は各々の意思で移動しているが、道路の形状、店の配置などにより、ある程度決まった通り道が存在している。このため、本発明の方法で限定鍵を配付すると、利用者が通りそうな道筋に沿って配付することができ、配付に無駄がなくなる。
【０１７４】
（第三の実施の形態）
図１６（ｂ）は本発明の第三の実施の形態の鍵管理サーバ１３の構成を示すブロック図である。図１６（ｂ）において、鍵管理サーバ１３が限定鍵蓄積部１６０２を有している点が第一の実施の形態と異なる。
【０１７５】
限定鍵蓄積部１６０２は認証サーバ１２から受信した限定鍵を限定鍵識別情報と関連づけて記憶している。
【０１７６】
この鍵管理サーバ１３を含む暗号化通信システムでの限定鍵の再配付の動作について図１７を用いて以下に説明する。
【０１７７】
まず、携帯端末１０は、サーバ１１に認証要求を行う（ステップＳ１７０１）。
【０１７８】
次に、サーバ１１はこの携帯端末１０に適応する限定鍵を所有していないため、認証サーバ１３に認証を要求する（ステップＳ１７０２）。
【０１７９】
次に、認証サーバ１２は限定鍵を生成し、鍵管理サーバ１３にその限定鍵の配付を依頼する（ステップＳ１７０３）。
【０１８０】
次に、鍵管理サーバ１３はその限定鍵を配付先選択情報に基づいてサーバ１１、２１に配付する（ステップＳ１７０４）。このとき、サーバ３１には配付されていない。また、携帯端末１０はサーバ１１から認証に成功したという通知を受ける（ステップＳ１７０５）。
【０１８１】
次に、携帯端末１０がサーバ２１に認証の要求を行う（ステップＳ１７０６）。サーバ２１はあらかじめ限定鍵を受信しているため、この限定鍵を用いて携帯端末１０を認証する。
【０１８２】
以上のステップＳ１７０１乃至ステップ１７０６は、第一の実施の形態における認証処理と同一である。
【０１８３】
図７に示した第一の実施の形態のサーバの動作において、ステップＳ７１４でサーバは限定鍵の付帯情報から有効期限切れか否かを判定し、有効期限切れの場合、鍵管理サーバ１３に限定鍵の削除を要求した（ステップＳ７１５）。しかし、本実施の形態では、サーバ２１はこの携帯端末１０を受信済みの限定鍵で認証する際に、付帯情報を用いて、限定鍵の再配付を鍵管理サーバに要求すべきか否かの判定を行う。この判定としては、例えば自己のサーバが配付されたサーバの中で終端に位置しているという情報があるか否かを判定するものであったり、あるいは限定鍵の有効期限が所定期間内であるか否かを判定するものである。また、サーバ２１は現行の限定鍵を配付するか、新規の限定鍵を配付するかも決定する。例えば、有効期限切れまで、５分以上ある場合は現行の限定鍵を使用し、５分以下の場合は新規の限定鍵の配付を要求するといった判定を行う。この条件の設定には、セキュリティ上の問題を考慮することが望ましい。サーバ２１が現行の限定鍵を配付すると決定した場合、鍵管理サーバに鍵の追加配付を依頼する（ステップＳ１７０７）。
【０１８４】
次に、鍵管理サーバ１３は要求元のサーバ２１を起点として、再度限定鍵の配付先を選択する。そして、新たな配付先の内、この限定鍵を未配付のサーバにのみ限定鍵を配付する（ステップＳ１７０８）。
【０１８５】
この鍵管理サーバ１３の処理を図１８に示したフローチャートを用いて説明する。
【０１８６】
まず、限定鍵管理部５０１はサーバ２１から限定鍵の再配付の要求を受信すると、要求元のサーバの識別子と、限定鍵識別情報とともに、配付先選択部５０２に再配付先の選択を要求する（ステップＳ１８０１）。
【０１８７】
次に、配付先選択部５０２は要求元のサーバの識別子で特定されたサーバを起点とし、配付先選択情報に基づいて配付先を選択する（ステップＳ１８０２）。この選択方法は第一の実施の形態と同一である。
【０１８８】
次に、配付先選択部５０２は配付先記憶部５０４からこの限定鍵識別情報に対応する限定鍵の配付先を読み出す（ステップＳ１８０３）。この配付先と、先の新たに選択した配付先とで重複していない配付先のサーバを抽出する（ステップＳ１８０４）。
【０１８９】
配付先選択部５０２はこの抽出されたサーバを限定鍵管理部５０１へ通知する。限定鍵管理部５０１は限定鍵記憶部５０５から限定鍵識別情報に対応した限定鍵を読み出し、配付先選択部５０２から通知されたサーバにそれを配付する（ステップＳ１８０５）。
【０１９０】
以上により、鍵管理サーバ１３は指定された既存の限定鍵を重複することなしに、携帯端末がさらにアクセスすると予測されるサーバに限定鍵を配付することができる。
【０１９１】
これにより、携帯端末は移動を続けても、既存の限定鍵を使用し続けることが可能になり、新たなサーバに高速に認証されサービスの提供をすばやく受けられる。また、有効期限を確認して、使用可能ならば現行の限定鍵を配付することにしているため、限定鍵の不要な増加を防止することができる。さらに、認証サーバと認証を行ったときに、限定鍵を配付されなかったサーバに対しても、必要に応じて無駄なく追加配付されるため、認証サーバへの認証を依頼する頻度をさらにおさえることができる。
【０１９２】
なお、サーバ２１が新規の鍵を配付すると決定した場合は、新しい限定鍵の生成のために認証サーバに、携帯端末１０から受信した認証用情報を送信する。認証サーバ１２は第一の実施の形態と同様にして、新たな限定鍵を生成し、鍵管理サーバ１３に配付を要求する。鍵管理サーバ１３もこれを受けて新限定鍵を配付する。すなわち、有効な限定鍵を共有している場合は認証済みであるとすることができるため、鍵の配付依頼を行っても、サーバと携帯端末との通信において、その応答を待つ必要はない。
【０１９３】
これにより、携帯端末１０は期限切れなどの理由で新規の限定鍵を必要とする場合も、限定鍵の期限が切れるまえに、新たな限定鍵を既存の限定鍵でサービスを受けている最中に取得できるので、その後は、この新たな限定鍵で配付済みのサーバに高速に認証されることになる。
【０１９４】
【発明の効果】
本発明により、サーバと移動端末装置との間で前もって限定鍵を共有しておくことができるので、認証サーバへの認証依頼頻度が減少し、利用者が移動しても、サーバと移動端末装置の相互認証を高速に行い、暗号化通信を開始することが可能となる。
【図面の簡単な説明】
【図１】本発明の第一の実施の形態における暗号化通信システムの構成を示すブロック図
【図２】本発明の第一の実施の形態における携帯端末の構成を示すブロック図
【図３】本発明の第一の実施の形態におけるサーバの構成を示すブロック図
【図４】本発明の第一の実施の形態における認証サーバの構成を示すブロック図
【図５】本発明の第一の実施の形態における鍵管理サーバの構成を示すブロック図
【図６】本発明の第一の実施の形態における携帯端末の動作を示すフローチャート
【図７】本発明の第一の実施の形態におけるサーバの動作を示すフローチャート
【図８】本発明の第一の実施の形態における認証サーバの動作を示すフローチャート
【図９】（ａ）本発明の第一の実施の形態における鍵管理サーバの動作を示すフローチャート
（ｂ）本発明の第一の実施の形態における鍵管理サーバの動作を示すフローチャート
【図１０】本発明の第一の実施の形態における限定鍵がない場合の動作を説明する図
【図１１】本発明の第一の実施の形態における限定鍵がある場合の動作を説明する図
【図１２】本発明の第一の実施の形態における限定鍵の削除をする動作を説明する図
【図１３】（ａ）本発明の第一の実施の形態の限定鍵がない場合の手順を示すシーケンス図
（ｂ）本発明の第一の実施の形態の限定鍵がある場合の手順を示すシーケンス図
【図１４】本発明の第二の実施の形態における限定鍵の配付先選択を説明する図
【図１５】本発明の第二の実施の形態における携帯端末の構成を示すブロック図
【図１６】（ａ）本発明の第二の実施の形態における鍵管理サーバの構成を示すブロック図
（ｂ）本発明の第三の実施の形態における鍵管理サーバの構成を示すブロック図
【図１７】本発明の第三の実施の形態の限定鍵の追加配付を行った場合の動作を説明する図
【図１８】本発明の第三の実施の形態における鍵管理サーバの動作を示すフローチャート
【図１９】（ａ）本発明の第一の実施の形態における限定鍵記憶部に保存するデータ構造を示す図
（ｂ）本発明の第一の実施の形態における限定鍵記憶部に保存するデータ構造を示す図
（ｃ）本発明の第一の実施の形態における限定鍵記憶部に保存するデータ構造を示す図
【図２０】従来例の暗号化通信システムの構成を示すブロック図
【図２１】従来例の暗号化通信システムの動作を説明する図
【図２２】従来例の暗号化通信システムの構成を示すブロック図
【符号の説明】
１０  携帯端末
１１、２１、３１  サーバ
１２  認証サーバ
１３  鍵管理サーバ
１５  電気通信回線
１６、１７、１８  通信ゾーン
２０１  通信部
２０２  認証要求部
２０３  認証用情報記憶部
２０４  端末用認証部
２０５  限定鍵生成部
２０６  端末用暗号・復号化部
２０７  判定部
３０１  通信部
３０２  限定認証部
３０３  限定鍵記憶部
３０４  鍵操作部
３０５  暗号・復号化部
４０１  認証部
４０２  認証情報記憶部
４０３  限定鍵生成部
５０１  限定鍵管理部
５０２  配付先選択部
５０３  配付先選択情報記憶部
５０４  配付先記憶部
１５０１  通信履歴記憶部
１６０１  グループＩＤ記憶部
１６０２  限定鍵蓄積部
２００１  認証転送部
２００２  鍵記憶部
２００３  鍵配付部
２２００  応用システム
２２０１、２２０８  通信網
２２０２  基地局管理装置
２２１０、２２１１  基地局装置
２２１７  移動局装置
【図１】
2004320308.tif 000003
【図２】
2004320308.tif 000004
【図３】
2004320308.tif 000005
【図４】
2004320308.tif 000006
【図５】
2004320308.tif 000007
【図６】
2004320308.tif 000008
【図７】
2004320308.tif 000009
【図８】
2004320308.tif 000010
【図９】
2004320308.tif 000011
【図１０】
2004320308.tif 000012
【図１１】
2004320308.tif 000013
【図１２】
2004320308.tif 000014
【図１３】
2004320308.tif 000015
【図１４】
2004320308.tif 000016
【図１５】
2004320308.tif 000017
【図１６】
2004320308.tif 000018
【図１７】
2004320308.tif 000019
【図１８】
2004320308.tif 000020
【図１９】
2004320308.tif 000021
【図２０】
2004320308.tif 000022
【図２１】
2004320308.tif 000023
【図２２】
2004320308.tif 000024