(57)【特許請求の範囲】
【請求項１】
通信装置との間で第１ネットワークアクセス認証処理を行うネットワークアクセス認証処理部と、
前記第１ネットワークアクセス認証処理の結果に応じて、前記通信装置と共有する第１マスター鍵を生成するマスター鍵生成部と、
前記第１マスター鍵に基づき、前記通信装置と共有する第１アプリケーション用暗号鍵を生成するアプリケーション用暗号鍵生成部と、
前記第１マスター鍵の識別子を決定するマスター鍵識別子決定部と、
前記第１マスター鍵の識別子に応じて、前記第１アプリケーション用暗号鍵の識別子を決定するアプリケーション用暗号鍵識別子決定部と、
を備えた認証装置。
【請求項２】
前記ネットワークアクセス認証処理部は、前記通信装置との間で第２ネットワークアクセス認証処理を行い、
前記マスター鍵生成部は、前記第２ネットワークアクセス認証処理の結果に応じて、前記通信装置と共有する第２マスター鍵を生成し、
前記アプリケーション用暗号鍵生成部は、前記第２マスター鍵に基づき、前記通信装置と共有する第２アプリケーション用暗号鍵を生成し、
前記マスター鍵識別子決定部は、前記第２マスター鍵の識別子を、前記第１マスター鍵の識別子と異なる値に決定し、
前記アプリケーション用暗号鍵識別子決定部は、前記第２マスター鍵の識別子に応じて、前記第２アプリケーション用暗号鍵の識別子を、前記第１アプリケーション用暗号鍵の識別子と異なる値に決定する
請求項１に記載の認証装置。
【請求項３】
前記マスター鍵識別子決定部は、前記第２アプリケーション用暗号鍵の識別子が前記第１アプリケーション用暗号鍵の識別子と異なる値に算出されるように、前記第２マスター鍵の識別子を決定する
請求項２に記載の認証装置。
【請求項４】
前記アプリケーション用暗号鍵識別子決定部は、マスター鍵の識別子と同じ長さの値を入力とし、アプリケーション用暗号鍵の識別子と同じ長さの値を出力とする関数を用いて、前記第１マスター鍵の識別子から前記第１アプリケーション用暗号鍵の識別子を算出し、前記第２マスター鍵の識別子から前記第２アプリケーション用暗号鍵の識別子を算出する
請求項３に記載の認証装置。
【請求項５】
前記ネットワークアクセス認証処理部は、前記第１マスター鍵の識別子および前記第２マスター鍵の識別子を前記通信装置に通知する、
請求項２ないし４のいずれか一項に記載の認証装置。
【請求項６】
アプリケーション用暗号鍵の識別子のビット長は、マスター鍵の識別子のビット長よりも小さく、
前記アプリケーション用暗号鍵識別子決定部は、前記第１マスター鍵の識別子のビット列の下位の所定範囲のビットを前記第１アプリケーション用暗号鍵の識別子とし、前記第２マスター鍵の識別子のビット列の下位の前記所定範囲のビットを前記第２アプリケーション用暗号鍵の識別子として決定する
請求項２に記載の認証装置。
【請求項７】
前記マスター鍵識別子決定部は、前記所定範囲のビット数により表現可能な最大値よりも小さい所定の値を前記第１マスター鍵の識別子に加算することによって、前記第２マスター鍵の識別子を得る
請求項６に記載の認証装置。
【請求項８】
通信装置との間で第１ネットワークアクセス認証処理を行うネットワークアクセス認証処理ステップと、
前記第１ネットワークアクセス認証処理の結果に応じて、前記通信装置と共有する第１マスター鍵を生成するマスター鍵生成ステップと、
前記第１マスター鍵に基づき、前記通信装置と共有する第１アプリケーション用暗号鍵を生成するアプリケーション用暗号鍵生成ステップと、
前記第１マスター鍵の識別子を決定するマスター鍵識別子決定ステップと、
前記第１マスター鍵の識別子に応じて、前記第１アプリケーション用暗号鍵の識別子を決定するアプリケーション用暗号鍵識別子決定ステップと、
を備えた認証方法。
【請求項９】
前記ネットワークアクセス認証処理ステップは、前記通信装置との間で第２ネットワークアクセス認証処理を行い、
前記マスター鍵生成ステップは、前記第２ネットワークアクセス認証処理の結果に応じて、前記通信装置と共有する第２マスター鍵を生成し、
前記アプリケーション用暗号鍵生成ステップは、前記第２マスター鍵に基づき、前記通信装置と共有する第２アプリケーション用暗号鍵を生成し、
前記マスター鍵識別子決定ステップは、前記第２マスター鍵の識別子を、前記第１マスター鍵の識別子と異なる値に決定し、
前記アプリケーション用暗号鍵識別子決定ステップは、前記第２マスター鍵の識別子に応じて、前記第２アプリケーション用暗号鍵の識別子を前記第１アプリケーション用暗号鍵の識別子と異なる値に決定する
請求項８に記載の認証方法。
【請求項１０】
通信装置との間で第１ネットワークアクセス認証処理を行うネットワークアクセス認証処理ステップと、
前記第１ネットワークアクセス認証処理の結果に応じて、前記通信装置と共有する第１マスター鍵を生成するマスター鍵生成ステップと、
前記第１マスター鍵に基づき、前記通信装置と共有する第１アプリケーション用暗号鍵を生成するアプリケーション用暗号鍵生成ステップと、
前記第１マスター鍵の識別子を決定するマスター鍵識別子決定ステップと、
前記第１マスター鍵の識別子に応じて、前記第１アプリケーション用暗号鍵の識別子を決定するアプリケーション用暗号鍵識別子決定ステップと、
をコンピュータに実行させるための認証プログラム。
【請求項１１】
前記ネットワークアクセス認証処理ステップは、前記通信装置との間で第２ネットワークアクセス認証処理を行い、
前記マスター鍵生成ステップは、前記第２ネットワークアクセス認証処理の結果に応じて、前記通信装置と共有する第２マスター鍵を生成し、
前記アプリケーション用暗号鍵生成ステップは、前記第２マスター鍵に基づき、前記通信装置と共有する第２アプリケーション用暗号鍵を生成し、
前記マスター鍵識別子決定ステップは、前記第２マスター鍵の識別子を、前記第１マスター鍵の識別子と異なる値に決定し、
前記アプリケーション用暗号鍵識別子決定ステップは、前記第２マスター鍵の識別子に応じて、前記第２アプリケーション用暗号鍵の識別子を前記第１アプリケーション用暗号鍵の識別子と異なる値に決定する
請求項１０に記載の認証プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ネットワークアクセス認証処理を行う認証装置、認証方法および認証プログラムに関する。
【背景技術】
【０００２】
マスター鍵からアプリケーション用暗号鍵を生成する方法がある。しかしながら、この方法では、アプリケーション用暗号鍵を識別することに触れておらず、アプリケーション用暗号鍵が同時に複数存在した場合に、それぞれのアプリケーション用暗号鍵を識別できなくなる問題がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開第2011／064868号
【非特許文献】
【０００４】
【非特許文献１】RFC 5191  Protocol for Carrying Authentication for Network Access (PANA)  http://tools.ietf.org/html/rfc5191
【非特許文献２】RFC 5247  Extensible Authentication Protocol (EAP) Key Management Framework  http://tools.ietf.org/html/rfc5247
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の一側面は、複数のアプリケーション用暗号鍵を区別できるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
本発明の実施形態としての認証装置は、ネットワークアクセス認証処理部と、マスター鍵生成部と、アプリケーション用暗号鍵生成部と、マスター鍵識別子決定部と、アプリケーション用暗号鍵識別子決定部とを備える。
【０００７】
前記ネットワークアクセス認証処理部は、通信装置との間で第1ネットワークアクセス認証処理を行う。
【０００８】
前記マスター鍵生成部は、前記第1ネットワークアクセス認証処理の結果に応じて、前記通信装置と共有する第1マスター鍵を生成する。
【０００９】
前記アプリケーション用暗号鍵生成部は、前記第1マスター鍵に基づき、前記通信装置と共有する第1アプリケーション用暗号鍵を生成する。
【００１０】
前記マスター鍵識別子決定部は、前記第1マスター鍵の識別子を決定する。
【００１１】
前記アプリケーション用暗号鍵識別子決定部は、前記第1マスター鍵の識別子に応じて、前記第1アプリケーション用暗号鍵の識別子を決定する。
【図面の簡単な説明】
【００１２】
【図１】一実施形態にかかるサーバを備えたネットワーク構成を示す図。
【図２】サーバの認証処理の流れを示すフローチャート。
【図３】鍵識別子決定処理の一例の流れを示すフローチャート。
【図４】一実施形態にかかるサーバの構成図。
【図５】鍵識別子決定処理の他の例の流れを示すフローチャート。
【発明を実施するための形態】
【００１３】
以下、図面を参照しながら、本発明の実施形態を説明する。
【００１４】
[実施形態1] 
図1に、本発明の実施形態1にかかるサーバ（認証装置）101を備えたネットワークシステムを示す。
【００１５】
このネットワークシステムは、サーバ101とクライアント（通信装置）102とネットワーク103とを備えている。
【００１６】
クライアント102が、ネットワーク103に接続する際には、サーバ101とクライアント102の間でネットワークアクセス認証が行われる。サーバ101は、クライアント102との事前共有鍵、またはパスワード、電子証明書等に基づき、事前に定めた認証方式で、認証を行う。本実施形態では、ネットワークアクセス認証プロトコルとしてRFC5191(PANA)を使うことを想定しているが、使用プロトコルはこの限りではない。
【００１７】
サーバ101によりクライアント102が認証許可されると、認証方式の仕様に従って、サーバ101とクライアント102の双方で、同一のマスター鍵が生成される。たとえば、認証結果の値と、事前に共有するマスター鍵生成関数に基づき、双方で同一のマスター鍵が生成される。さらに当該マスター鍵から、双方において事前に共有するアプリケーション用暗号鍵生成関数に基づき、同一のアプリケーション用暗号鍵が生成される。
【００１８】
クライアント102およびサーバ101は、当該アプリケーション用暗号鍵を用いて、該当するアプリケーション用の通信を行う。なお、認証許可された後、サーバ101からネットワーク103上の図示しない別の装置にアプリケーション用暗号鍵をセキュアに送り、当該別の装置とクライアント102間で、アプリケーション用暗号鍵を用いた暗号化通信を行うことも可能である。なお、本実施例において、マスター鍵は、アプリケーション用暗号鍵の生成のために用いられ、実際の通信用の暗号鍵として用いられないが、これに限定されるものではない。
【００１９】
サーバ101およびクライアント102間の認証は定期的に行われ、再認証の都度、マスター鍵およびアプリケーション用暗号鍵の生成が行われる。再認証は、前回の認証の有効期限が切れる前に行われる。このため、前回の認証に基づくマスター鍵およびアプリケーション用暗号鍵と、今回の認証に基づくマスター鍵およびアプリケーション用暗号鍵とが同時に存在する期間がある。したがって、この併存期間において、マスター鍵識別子およびアプリケーション用暗号鍵を区別できる必要性がある。また、再認証以外にも、サーバ101およびクライアント102間で2つ以上の認証が並行して行われる可能性もあり、このような場合にも、当該2つ以上の認証間で、マスター鍵およびアプリケーション用暗号鍵が区別される必要がある。
【００２０】
従来、マスター鍵については、サーバ101でマスター鍵識別子を重複しないように決定し、クライアント102に通知していた。このため、マスター鍵は、前回のものと今回のものと、当該マスター鍵識別子により区別可能であった。しかしながら、アプリケーション用暗号鍵については、区別する方法がなかった。本実施形態では、この問題を解決し、複数のアプリケーション用暗号鍵を識別可能にするサーバおよび方法を開示する。
【００２１】
図2は、サーバ101により行われる認証処理の流れを概略的に示すフローチャートである。
【００２２】
サーバ101は、クライアント102から認証開始メッセージを受信すると（S201）、クライアント102との間で、ネットワークアクセス認証処理を実施する（S202）。認証は、はじめてクライアント102が接続してきた場合、再認証の場合、及び既に1つ以上の認証が既に存在し、追加の認証を行う場合等がある。なお、クライアント102からの認証開始メッセージを受信しないで、ネットワークアクセス認証処理（S202）を実施する場合もあるが、ここでは省略する。
【００２３】
事前共有鍵の不一致またはパスワードの不一致等により、認証処理が失敗した場合（S203のNO）、認証完了メッセージをクライアント102に送信し、失敗した旨を通知する（S207）。
【００２４】
認証が成功した場合（S203のYES）、認証処理の結果として得られる値に基づきマスター鍵を生成し（S204）、さらに当該マスター鍵からアプリケーション用暗号鍵を生成する（S205）。
【００２５】
マスター鍵からアプリケーション用暗号鍵を生成する方法は任意でよく、様々な方法を用いることができる。認証処理の結果として得られる値は、サーバ101とクライアント102双方で共有されており、クライアント102においても当該値からサーバ101と同一のマスター鍵が生成される。またアプリケーション用暗号鍵の生成アルゴリズムも双方で共有されており、クライアント102においても、同一のマスター鍵からサーバ101と同一のアプリケーション用暗号鍵が生成される。
【００２６】
なお、本願のマスター鍵は、認証結果に基づき作成される鍵であれば特定のものに制限されない。マスター鍵は、例えばマスターセッション鍵（MSK）、拡張マスターセッション鍵（EMSK）のどちらに該当してもよい。
【００２７】
またアプリケーション用暗号鍵も、マスター鍵から生成される限り、マスター鍵から直接的に（親子関係で）生成されるのでも、間接的に（親孫関係で）生成されるものでもよい。例えば、マスター鍵がEMSKに該当するとき、アプリケーション用暗号鍵は、EMSKから直接生成されるユースケース毎のルート鍵（USRK (Usage-Specific Root Key）for use case A, USRK for use case B)等でもよいし、当該USRKからさらに生成される鍵でもよい。たとえばUSRKがSMMK(USRK for Smart Meter)であるとき、アプリケーション用暗号鍵はSMMKでもよいし、当該SMMKから生成されるSMK-HH（Smart Meter Key for hop by hop protection）でも、SMK-EE(Smart Meter Key for End-to-End protection)でもよい。
【００２８】
次に、サーバ101はマスター鍵識別子およびアプリケーション用暗号鍵識別子を決定する（S206）。マスター鍵識別子およびアプリケーション用暗号鍵識別子は、現在使用中のものと重複しないように決定する。アプリケーション用暗号鍵識別子は、マスター鍵識別子の値に応じて決定される。サーバ101は、決定したマスター鍵識別子およびアプリケーション用暗号鍵識別子を、それぞれ今回生成したマスター鍵およびアプリケーション用暗号鍵に対応づけて記憶管理する。
【００２９】
サーバ101は、決定したマスター鍵識別子を含む認証完了メッセージをクライアント102に送信し、認証に成功した旨を通知する。マスター鍵識別子は、当該認証完了メッセージとは別のメッセージとして、通知してもよい。
【００３０】
アプリケーション用暗号鍵識別子は、認証完了メッセージに含めなくてよい。つまり、アプリケーション用暗号鍵識別子をクライアント102に通知しなくてよい。この場合、クライアント102とサーバ101でアプリケーション用暗号鍵識別子生成関数を事前に共有しておき、クライアント102では、サーバ101から通知されたマスター鍵識別子から、当該関数にしたがって、サーバ101と同一のアプリケーション用暗号鍵識別子を生成する。したがって、クライアント102およびサーバ101間で送受信するメッセージシーケンスまたはメッセージ内容に、従来から変更を加える必要はない。よって、実施が容易である。
【００３１】
クライアント102は、上記マスター鍵識別子およびアプリケーション用暗号鍵識別子を、それぞれ、今回生成したマスター鍵およびアプリケーション用暗号鍵に関連づけて記憶管理する。
【００３２】
図3に、図2のステップS206における鍵識別子決定処理の一例の流れを詳細に示す。
【００３３】
はじめに、サーバ101とクライアント102間で現在使用しているマスター鍵識別子（現マスター鍵識別子）と異なる値を選択し、それを仮マスター鍵識別子とする（S301）。なお、マスター鍵識別子は、異なるクライアント間では、同一の値を許す場合と、許さない場合が考えられるが、本フローの例ではどちらの場合でも対応可能である。
【００３４】
次に、仮マスター鍵識別子と同じ長さの値を入力とし、アプリケーション暗号鍵識別子と同じ長さの値を出力とするアプリケーション用暗号鍵識別子生成関数を使い、当該仮マスター鍵識別子から、仮アプリケーション暗号鍵識別子を生成する（S302）。たとえば、マスター鍵識別子が32ビットで、アプリケーション暗号鍵識別子が8ビットの場合、アプリケーション用暗号鍵識別子生成関数は、入力（仮マスター鍵識別子）の下位8ビットを出力する関数が考えられる。
【００３５】
そして、算出した仮アプリケーション暗号鍵識別子と同じ値を持つアプリケーション用暗号鍵識別子が存在しないか確認する（S303）。なお、アプリケーション暗号鍵識別子は、異なるクライアント間では、同一の値を許す場合と、許さない場合が考えられるが、本フローの例では、どちらの場合でも対応可能である。少なくとも同一クライアントでは重複しないことが必要である。
【００３６】
存在する場合（NO）、ステップS301に戻って、仮マスター鍵識別子を再生成する。
【００３７】
存在しない場合（YES）、仮マスター鍵識別子をマスター鍵識別子として決定する（S304）。また、仮アプリケーション用暗号鍵識別子をアプリケーション用暗号鍵識別子として決定する（S305）。
【００３８】
上記で述べたアプリケーション用暗号鍵識別子生成関数はあくまで例であり、これ以外の関数であってもよい。
【００３９】
また、マスター鍵識別子やアプリケーション用暗号鍵識別子の有効範囲（スコープ）によって、ステップS301やS303で比較すべき鍵識別子が異なる。つまり、これらの鍵識別子がサーバ101とクライアント102間だけでユニークであればよいのか、それともネットワーク103に接続しているすべてのノードの中でユニークでなければならないのかによって、ステップS301やステップS303で比較すべき鍵識別子が異なる。
【００４０】
図4にサーバ101の構成図を示す。
【００４１】
サーバ101は、ネットワークアクセス認証処理部401、マスター鍵生成部402、アプリケーション用暗号鍵生成部403、マスター鍵識別子決定部404、アプリケーション用暗号鍵識別子決定部405、ネットワークアクセス認証セッション情報データベース（記憶部）406を備える。
【００４２】
ネットワークアクセス認証処理部401は、事前に設定された認証メソッドとPANAを使用し、サーバ101とクライアント102の間のネットワークアクセス認証処理を行う。クライアントへのマスター鍵識別子の通知、必要に応じてアプリケーション用暗号鍵識別子の通知もこれに含まれる。具体的に、図2のフローのステップS201、S202、S203、S206、S207の処理を行う。ステップS206では、特に図3のフローのステップS303、S304、S305の処理を行う。
【００４３】
マスター鍵生成部402は、ネットワークアクセス認証処理の結果に応じてマスター鍵を生成する。つまり、マスター鍵生成部402は、ネットワークアクセス認証処理が許可されると、認証方式の仕様に従って、マスター鍵を生成する。たとえば図2のフローのステップS204の処理を行う。
【００４４】
アプリケーション用暗号鍵生成部403は、事前に設定されたアプリケーション用暗号鍵関数を用いて、マスター鍵から、アプリケーション用暗号鍵を生成する。たとえば図2のフローのステップS205の処理を行う。
【００４５】
マスター鍵識別子決定部404は、図3に示した処理により、マスター鍵識別子を決定し、アプリケーション用暗号鍵識別子決定部405は、アプリケーション用暗号鍵識別子を生成する。たとえば、図2のフローのステップS206の処理、特に、図3のフローのステップS301、S302の処理を行う。
【００４６】
上記した実施形態では、1つのマスター鍵から1つのアプリケーション用暗号鍵を生成し、1つのマスター鍵識別子から、1つのアプリケーション用暗号鍵識別子を生成する例を示したが、1つのマスター鍵から複数のアプリケーション用暗号鍵を作る場合もあり得る。この場合、各アプリケーション用暗号鍵にそれぞれ識別子を決定する必要がある。この場合も、基本的に、上記の処理と同様の考えで、当該1つのマスター鍵識別子から、複数のアプリケーション用暗号鍵識別子を作ればよい。
【００４７】
たとえば、1のマスター鍵から2つのアプリケーション用暗号鍵を生成する場合は、それぞれのアプリケーション用暗号鍵について図3の ステップS302 や S303 と S305 を実施することになる。具体的にはステップS301で仮マスター鍵識別子を決めたのち、ステップS302で、アプリケーション用暗号鍵A の仮アプリケーション用鍵識別子a とアプリケーション用暗号鍵B の仮アプリケーション用鍵識別子b を決める。この a と b についてステップS303の判定を行い、問題がなければ、仮マスター鍵識別子と仮アプリケーション用鍵識別子a、b を、真のマスター鍵識別子およびアプリケーション用鍵識別子として決定する（S304、S305）。
【００４８】
なお、上記実施形態では、認証装置はサーバ101としてネットワーク103上に独立して存在したが、認証装置はクライアント102とネットワーク103間に存在し得る、ゲートウェイ（アクセスサーバ）に組み込まれてもよい。アクセスサーバは、認証装置による認証が許可される前は、クライアントに対しサーバとの間で認証のための限られた通信のみ許可し、認証が許可された後は、ネットワーク103への自由なアクセスを許可する役割を有する。
【００４９】
以上、本実施形態により、アプリケーション用暗号鍵に識別子を付与することができ、よって、複数のアプリケーション用暗号鍵を区別することが可能となる。
【００５０】
また、マスター鍵識別子に応じてアプリケーション用暗号鍵識別子を決定するため、クライアントへのアプリケーション用暗号鍵識別子の通知を不要にできる。すなわち、前述のアプリケーション用暗号鍵識別子生成関数をクライアントと共有しておくことで、クライアントに従来通りマスター鍵識別子を通知しさえずれば、クライアントは、後は自身でアプリケーション用暗号鍵識別子を決定できる。したがって、クライアントへのアプリケーション用暗号鍵識別子の通知を省略でき、従来のメッセージシーケンスまたはメッセージ内容に変更を加える必要はない。
【００５１】
[実施形態2]
本実施形態2は、図2のステップS206で行う鍵識別子決定処理が実施形態1と異なる。
【００５２】
図5に、実施形態2における鍵識別子決定処理の流れを示す。本実施形態では、マスター鍵識別子のビット空間は32ビット、アプリケーション用暗号鍵識別子のビット空間は8ビットを前提としている。また、異なるクライアント間では、マスター鍵識別子はユニークであるとする。
【００５３】
まず、サーバ101とクライアント102間で現在使用しているマスター鍵の識別子（現マスター鍵識別子）を特定する（S501）。
【００５４】
次に、現マスター鍵識別子の下位8ビット（現マスター鍵識別子のビット列における下位の所定範囲のビット）が、0xFF（“11111111”）であるか否かを判断する（S502）。下位8ビットが0xFFでないときは、ステップS503に進み、0xFFであるときは、ステップS504に進む。また、クライアント102が初めてサーバに接続してきた状態で、まだ現マスター鍵識別子が存在しないときも、ステップS504に進む。
【００５５】
ステップS503では、上記所定範囲のビット数により表現可能な最大値より小さい所定の値、ここでは1を、現マスター鍵識別子に加算した値を、サーバ101とクライアント102間で新たに共有するマスター鍵（図2のS204で生成されたマスター鍵）の鍵識別子として決定する（S503）。ここで決定した鍵識別子を、新マスター鍵識別子と呼ぶ。また、新マスター鍵識別子の下位8ビットを、アプリケーション用暗号鍵識別子として決定する。クライアント102でも、サーバ101から通知されるマスター鍵識別子（新マスター鍵識別子）の下位8ビットを、アプリケーション用暗号鍵識別子として決定する。
【００５６】
一方、下位8ビットが0xFF（“11111111”）であるときは、他のクライアントとの間で共有しているマスター鍵のマスター鍵識別子の中で、最も大きい値のマスター鍵識別子を特定する（S504）。具体的には上位24ビットを比較して、上位24ビット部分の値が最も大きいマスター鍵識別子を特定する。ここで特定したマスター鍵識別子を、“最大鍵識別子”と呼ぶ。
【００５７】
最大鍵識別子の上位24ビットを「1」で、下位8ビットを「0」でマスクし、256を加算した値を、新たなマスター鍵の識別子（新マスター鍵識別子）とする。つまり、最大鍵識別子の上位24ビットに1を加算し、下位8ビットをすべて0にした値を、新マスター鍵識別子とする。また、新マスター鍵識別子の下位8ビットを、アプリケーション用暗号鍵識別子として決定する。クライアント102でも、サーバ101から通知されるマスター鍵識別子（新マスター鍵識別子）の下位8ビットを、アプリケーション用暗号鍵識別子として決定する。
【００５８】
以上、本実施形態によれば、現在のマスター鍵識別子に1を加算することで、新マスター鍵識別子を決定し、新マスター鍵識別子の下位8ビットをアプリケーション用暗号鍵識別子とするため、重複しないアプリケーション用暗号鍵識別子を簡単に決定できる。
【００５９】
なお、以上に説明した実施形態におけるサーバは、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、サーバの各ブロックの処理は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、サーバは、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。
【図１】
0005643741.tif 000002
【図２】
0005643741.tif 000003
【図３】
0005643741.tif 000004
【図４】
0005643741.tif 000005
【図５】
0005643741.tif 000006