通信装置及びプログラム
【課題】軽装化及び相手認証を実現する。
【解決手段】実施形態の通信装置は、上位装置を介して外部装置と通信し、主処理部と、鍵生成部と、を備える。主処理部は、上位装置から、被認証データ、第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を受信する。鍵生成部は、上位装置と外部装置との間で用いられる認証プロトコルが使用する鍵階層を保持し、鍵階層と第１鍵仕様とを用いて第１鍵を生成する。主処理部は、メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムと第１鍵とを用いて被認証データに対するメッセージ認証コードを生成し、当該メッセージ認証コードを含むデータ認証応答を上位装置に送信する。
【解決手段】実施形態の通信装置は、上位装置を介して外部装置と通信し、主処理部と、鍵生成部と、を備える。主処理部は、上位装置から、被認証データ、第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を受信する。鍵生成部は、上位装置と外部装置との間で用いられる認証プロトコルが使用する鍵階層を保持し、鍵階層と第１鍵仕様とを用いて第１鍵を生成する。主処理部は、メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムと第１鍵とを用いて被認証データに対するメッセージ認証コードを生成し、当該メッセージ認証コードを含むデータ認証応答を上位装置に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信装置及びプログラムに関する。
【背景技術】
【０００２】
従来から、電気メータなどの装置をＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）ゲートウェイを介してリモートサーバなどの外部装置と通信させる技術が知られている。
【０００３】
このような技術では、例えば、電気メータが、自身が測定した計量データを、レイヤ２フレームを用いてｎｏｎ−ＩＰパケットとしてＴＣＰ／ＩＰゲートウェイに送信し、ＴＣＰ／ＩＰゲートウェイが、電気メータから受信した計量データをＨＴＴＰ（HyperText Transfer Protocol） ｏｖｅｒ ＴＣＰ／ＩＰを用いてリモートサーバに送信する。
【０００４】
このようにすれば、電気メータとリモートサーバとの通信において、電気メータの軽装化が可能となる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許第６３６３０５７号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述したような従来技術では、正当でない装置が外部装置と通信できてしまうなどセキュリティ上の問題がある。本発明が解決しようとする課題は、軽装化及び相手認証を実現することができる通信装置及びプログラムを提供することである。
【課題を解決するための手段】
【０００７】
実施形態の通信装置は、上位装置を介して外部装置と通信し、主処理部と、鍵生成部と、を備える。主処理部は、上位装置から、被認証データ、第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を受信する。鍵生成部は、上位装置と外部装置との間で用いられる認証プロトコルが使用する鍵階層を保持し、鍵階層と第１鍵仕様とを用いて第１鍵を生成する。主処理部は、メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムと第１鍵とを用いて被認証データに対するメッセージ認証コードを生成し、当該メッセージ認証コードを含むデータ認証応答を上位装置に送信する。
【図面の簡単な説明】
【０００８】
【図１】本実施形態の通信システムの例を示す構成図。
【図２】本実施形態の通信システムの処理例を示すシーケンス図。
【図３】本実施形態の鍵階層の例を示す図。
【図４】本実施形態の共通メッセージフォーマットの例を示す図。
【図５】本実施形態の登録要求のペイロードのフォーマットの例を示す図。
【図６】本実施形態の登録応答のペイロードのフォーマットの例を示す図。
【図７】本実施形態のデータ認証要求のペイロードのフォーマットの例を示す図。
【図８】本実施形態の鍵仕様の例を示す図。
【図９】本実施形態の完全指定子の例を示す図である。
【図１０】本実施形態のデータ認証応答のペイロードのフォーマットの例を示す図。
【図１１】本実施形態の鍵要求のペイロードのフォーマットの例を示す図。
【図１２】本実施形態の鍵応答のペイロードのフォーマットの例を示す図。
【図１３】本実施形態のＳＫに対する完全指定子の例を示す図。
【図１４】本実施形態のＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹに対する完全指定子の例を示す図。
【図１５】本実施形態の子ノードの処理例を示すフローチャート。
【図１６】本実施形態の主処理の例を示すフローチャート。
【図１７】本実施形態の親ノードの処理例を示すフローチャート。
【図１８】本実施形態の親ノードメッセージ受信処理例を示すフローチャート。
【図１９】本実施形態の親ノードメッセージ送信処理例を示すフローチャート。
【図２０】本実施形態のメッセージ認証コード取得処理例を示すフローチャート。
【図２１】本実施形態の鍵取得処理例を示すフローチャート。
【発明を実施するための形態】
【０００９】
図１は、本実施形態の通信システム１の一例を示す構成図である。図１に示すように、通信システム１は、複数の子ノード１０−１〜１０−Ｎと、親ノード２０と、アプリケーションサーバ３０とを、備える。
【００１０】
複数の子ノード１０−１〜１０−Ｎと親ノード２０との通信は、例えば、有線ＬＡＮ（Local Area Network）や無線ＬＡＮなどのネットワークで実現してもよいし、ＢｌｕｅｔｏｏｔｈやＺｉｇＢｅｅなどの短距離無線通信で実現してもよい。親ノード２０とアプリケーションサーバ３０との通信は、例えば、有線ＬＡＮ（Local Area Network）や無線ＬＡＮなどのネットワークで実現できる。
【００１１】
子ノード１０−１〜１０−Ｎは、保持している鍵階層（詳細は後述）が互いに異なるが、用いられる用途、備えている構成要素、実行する動作は、いずれも同様である。このため、以下では、子ノード１０−１を主に説明し、子ノード１０−２〜１０−Ｎについては、その説明を省略する。
【００１２】
子ノード１０−１（通信装置、下位装置の一例）は、例えば、ガスメータ、電気メータ、家電機器、照明器具、センサー、アクチュエーター、又は電気自動車などに実装され、親ノード２０（通信装置、上位装置の一例）を介してアプリケーションサーバ３０（外部装置の一例）と通信する。
【００１３】
子ノード１０−１は、登録処理部１１と、主処理部１３と、鍵生成部１５とを、備える。登録処理部１１、主処理部１３、及び鍵生成部１５は、例えば、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、及びＲＯＭ（Read Only Memory）などを有する処理装置により実現してもよいし、ＩＣ（Integrated Circuit）により実現してもよいし、処理装置及びＩＣを併用して実現してもよい。
【００１４】
登録処理部１１は、後述の鍵生成部１５が保持している鍵階層を使用する認証プロトコルの識別子のリスト及び子ノード１０−１の認証識別子を含む登録要求を親ノード２０に送信し、親ノード２０から登録応答を受信する。なお登録処理部１１は、鍵生成部１５が保持している鍵階層を使用する認証プロトコルの識別子のリスト及び子ノード１０−１の認証識別子を予め保持している。
【００１５】
主処理部１３は、親ノード２０から、被認証データ、第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を受信する。そして主処理部１３は、メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムと後述の鍵生成部１５により第１鍵仕様から生成される第１鍵とを用いて、被認証データに対するメッセージ認証コードを生成し、当該メッセージ認証コードを含むデータ認証応答を親ノード２０に送信する。なお主処理部１３は、メッセージ認証アルゴリズムを予め保持しており、メッセージ認証アルゴリズム識別子で指定（識別）されるメッセージ認証アルゴリズムを用いて、メッセージ認証コードを生成する。
【００１６】
ここで、主処理部１３は、過去に受信したデータ認証要求に含まれる第１鍵仕様と当該第１鍵仕様から生成される第１鍵とを含む鍵キャッシュを保持し、新たに受信したデータ認証要求に含まれる第１鍵仕様と鍵キャッシュに含まれる第１鍵仕様とを比較するようにしてもよい。そして主処理部１３は、両者が一致する場合、鍵キャッシュに含まれる第１鍵と新たに受信したデータ認証要求に含まれるメッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムとを用いて、新たに受信したデータ認証要求に含まれる被認証データに対するメッセージ認証コードを生成するようにしてもよい。
【００１７】
また主処理部１３は、親ノード２０から第２鍵仕様を含む鍵要求を受信し、当該第２鍵仕様から後述の鍵生成部１５により生成される第２鍵を含む鍵応答を親ノード２０に送信する。
【００１８】
鍵生成部１５は、親ノード２０とアプリケーションサーバ３０との間で用いられる認証プロトコルが使用する鍵階層を保持する。そして鍵生成部１５は、主処理部１３によりデータ認証要求が受信されると、データ認証要求に含まれる第１鍵仕様と保持している鍵階層とを用いて第１鍵を生成し、鍵要求が受信されると、鍵要求に含まれる第２鍵仕様と保持している鍵階層とを用いて第２鍵を生成する。なお、生成された第１鍵、第２鍵は、鍵生成部１５が保持している鍵階層に属する。
【００１９】
親ノード２０は、例えば、電気メータ、ＨＥＭＳ（Home Energy Management System）サーバ、コンセントレータ、ルータ、無線ＬＡＮアクセスポイント、ＬＡＮスイッチ、又は電気自動車等などに実装され、複数の子ノード１０−１〜１０−Ｎとアプリケーションサーバ３０とを自身を介して通信させる。
【００２０】
親ノード２０は、登録処理部２１と、認証プロトコル処理部２３と、鍵仕様生成部２５とを、備える。登録処理部２１、認証プロトコル処理部２３、及び鍵仕様生成部２５は、例えば、ＣＰＵ、ＲＡＭ、及びＲＯＭなどを有する処理装置により実現してもよいし、ＩＣにより実現してもよいし、処理装置及びＩＣを併用して実現してもよい。
【００２１】
登録処理部２１は、複数の子ノード１０−１〜１０−Ｎのそれぞれから、当該子ノードが保持する鍵階層を使用する認証プロトコルの識別子のリスト及び当該子ノードの認証識別子を含む登録要求を受信する。そして登録処理部２１は、当該子ノードの登録期間の間、登録要求の内容と当該子ノードのアドレスとを対応付けて保持し、登録要求を受信した子ノードに登録応答を送信する。なお登録処理部２１は、複数の子ノード１０−１〜１０−Ｎそれぞれのアドレスを予め保持しており、このアドレスを登録要求の内容と対応付ける。また、登録要求に、登録期間の値が更に含まれていてもよい。
【００２２】
認証プロトコル処理部２３は、親ノード２０とアプリケーションサーバ３０との間で用いられる認証プロトコルの処理のうちメッセージ認証コード生成以外の処理を行う。本実施形態では、認証プロトコルは、ＰＡＮＡ（Protocol for carrying Authentication for Network Access）及びＥＡＰ（Extensible Authentication Protocol）認証メソッドを含むものとするが、これに限定されるものではない。
【００２３】
また認証プロトコル処理部２３は、被認証データ、後述の鍵仕様生成部２５により生成される第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を、複数の子ノード１０−１〜１０−Ｎのうち認証プロトコルが使用する鍵階層を有する子ノードに送信する。なお認証プロトコル処理部２３は、アプリケーションサーバ３０との間で送信又は受信されるメッセージから、被認証データ及びメッセージ認証アルゴリズム識別子を取得する。本実施形態では、被認証データは、アプリケーションサーバ３０と間で交換されるアプリケーションデータであるものとするが、これに限定されるものではない。認証プロトコル処理部２３は、データ認証要求を送信した子ノードから、被認証データに対するメッセージ認証コードを含むデータ認証応答を受信する。そして認証プロトコル処理部２３は、子ノードから受信したメッセージ認証コードを用いて、被認証データのメッセージ認証を行う。
【００２４】
また認証プロトコル処理部２３は、後述の鍵仕様生成部２５により生成される第２鍵仕様を含む鍵要求を、複数の子ノード１０−１〜１０−Ｎのうち認証プロトコルが使用する鍵階層を有する子ノードに送信し、当該子ノードから、当該第２鍵仕様から生成される第２鍵を含む鍵応答を受信する。そして認証プロトコル処理部２３は、当該第２鍵を用いて、被認証データの暗号化又は復号化を行う。本実施形態では、鍵応答に含まれる第２鍵は、アプリケーションサーバ３０と間で共有されるものとする。
【００２５】
鍵仕様生成部２５は、認証プロトコルが使用する鍵階層に属する第１鍵を、複数の子ノード１０−１〜１０−Ｎのうち当該鍵階層を有する子ノードに生成させるための第１鍵仕様を生成する。また鍵仕様生成部２５は、認証プロトコルが使用する鍵階層に属する第２鍵を、複数の子ノード１０−１〜１０−Ｎのうち当該鍵階層を有する子ノードに生成させるための第２鍵仕様を生成する。
【００２６】
鍵仕様は、鍵種別、親鍵の鍵長、鍵導出関数識別子、ハッシュ関数識別子、鍵導出関数出力長、鍵導出関数出力中の鍵系列開始位置、鍵導出関数出力中の鍵系列終了位置、及び鍵ラベルを含む完全指定要素の順序リストである完全指定子、又は当該完全指定子に対応する整数値である参照指定子により指定され、完全指定子による指定か参照指定子による指定かを識別する指定子種別を含む。参照指定子の値は、データ認証応答の送信元により割当てられ、データ認証応答により通知されるので、鍵仕様生成部２５は、参照指定子と完全指定子の対応関係を保持しておく。これにより、鍵仕様生成部２５は、完全指定子ではなく参照指定子による指定が可能となる。なお、鍵仕様は、完全指定子のみにより指定されるようにしてもよい。
【００２７】
なお、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０は、登録要求、登録応答、データ認証要求、データ認証応答、鍵要求、及び鍵応答を、データリンクレイヤ、ネットワークレイヤ、及びトランスポートレイヤのいずれのレイヤのプロトコルを用いて送受信してもよい。
【００２８】
また、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０は、登録要求、登録応答、データ認証要求、データ認証応答、鍵要求、及び鍵応答を、暗号化したりメッセージ認証を施したりして送受信してもよい。この場合、暗号化やメッセージ認証には、複数の子ノード１０−１〜１０−Ｎそれぞれと親ノード２０との間で共有される共通鍵が用いられる。この共通鍵は子ノード毎に異なることが望ましい。
【００２９】
図２は、本実施形態の通信システム１で実行される処理の一例を示すシーケンス図である。
【００３０】
図２に示す例では、通信システム１は、認証プロトコルＸ及び認証プロトコルＹの２種類の認証プロトコルを用いて認証を行う。具体的には、認証プロトコルＹのメッセージは、認証プロトコルＸのメッセージによりカプセル化され、認証プロトコルＸがメッセージ認証に用いる鍵は、認証プロトコルＹが使用する鍵階層から生成される。図２に示す例では、認証プロトコルＸは、ＰＡＮＡ（ＲＦＣ ５１９１）であり、認証プロトコルＹは、ＥＡＰ−ＧＰＳＫ（ＲＦＣ ５４３３）であるものとするが、これに限定されるものではない。
【００３１】
なお、図２に示す例では、複数の子ノード１０−１〜１０−Ｎと親ノード２０との通信については、子ノード１０−１と親ノード２０との通信についてのみ図示している。また、図２に示す例では、親ノード２０とアプリケーションサーバ３０との間で通信される認証プロトコルＸのメッセージ及び認証プロトコルＹのメッセージは、メッセージ認証コードが付加されるもののみを図示すものとする。このため、図２に示す例では、メッセージ認証アルゴリズムのネゴシエーションや認証識別子の通知に使用されるメッセージなどのメッセージ認証コードが付加されないメッセージについては、図示を省略している。
【００３２】
シーケンスの内容を説明する前に、図２に示す例において、子ノード１０−１が保持する鍵階層、及び子ノード１０−１と親ノード２０との間で通信されるメッセージのメッセージフォーマットについて説明する。
【００３３】
図３は、本実施形態の子ノード１０−１が保持する鍵階層の一例を示す図である。図３に示す例では、鍵階層は、親ノード２０とアプリケーションサーバ３０とがネットワークアクセス認証プロトコルとしてＰＡＮＡ（ＲＦＣ ５１９１）を使用し、ＰＡＮＡ上でＥＡＰ認証メソッドＥＡＰ−ＧＰＳＫ（ＲＦＣ ５４３３）を使用する場合に、これらの認証プロトコルが使用するものとなっている。
【００３４】
図３に示す例では、ＰＳＫ（Pre-Shared Key）１０１は、ＥＡＰ−ＧＰＳＫで使用される共通鍵認証の共通鍵、ＭＫ（Master Key）１０２は、ＰＳＫ１０１から導出されるマスター鍵、ＳＫ（Session Key）１０３は、ＥＡＰ−ＧＰＳＫのメッセージ認証コード生成に使用される鍵、ＰＫ１０４は、ＥＡＰ−ＧＰＳＫのペイロード暗号化に使用される鍵、ＭＳＫ（Master Session Key）１０５及びＥＭＳＫ（Extended MSK）１０６は、ＥＡＰが下位層にエキスポートする鍵、ＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹ１０７は、ＰＡＮＡのメッセージのメッセージ認証コード生成に使用される鍵となっている。なお、図３に示す例では、ＥＡＰ−ＧＰＳＫのペイロード暗号化に使用される鍵は、ＰＫ１０４となっているが、これに限定されず、ＥＭＳＫ１０６の下の鍵階層に属する鍵としてもよい。
【００３５】
図４は、本実施形態のメッセージが使用する共通メッセージフォーマットの一例を示す図である。図４に示す例では、共通メッセージフォーマットは、メッセージ種別、ペイロード平文長、初期化ベクトル、暗号化ペイロード、及びメッセージ認証コードを有する。
【００３６】
メッセージ種別は、子ノード１０−１と親ノード２０との間で通信されるメッセージの種別を示し、データ認証要求、データ認証応答、登録要求、登録応答、鍵要求、及び鍵応答を区別するための整数値が格納される。
【００３７】
ペイロード平文長には、メッセージ種別が示すメッセージのペイロードの平文のオクテット長が格納される。
【００３８】
初期化ベクトルには、ランダム値が格納される。このランダム値は、暗号化ペイロードへの暗号化及び暗号化ペイロードからの復号化に対するリプレイ攻撃の防止に用いられる。
【００３９】
暗号化ペイロードには、メッセージ種別が示すメッセージのペイロードが子ノード１０−１と親ノード２０との間で共有される暗号鍵（共通鍵）で暗号化されて格納される。但し、暗号化が必要ない場合には、暗号化ペイロードには、メッセージ種別が示すメッセージのペイロードが平文で格納される。
【００４０】
メッセージ認証コードには、メッセージ種別、ペイロード平文長、初期化ベクトル、及び暗号化ペイロードに対するメッセージ認証コードの値が格納される。このメッセージ認証コードの値は、子ノード１０−１と親ノード２０との間で共有されるメッセージ認証鍵（共通鍵）を用いて生成される。
【００４１】
図５は、本実施形態の登録要求のペイロードのフォーマットの一例を示す図である。図５に示す例では、登録要求のペイロードのフォーマットは、認証プロトコル識別子リスト、認証識別子、及び登録ライフタイム（登録期間の値）を有する。
【００４２】
図６は、本実施形態の登録応答のペイロードのフォーマットの一例を示す図である。図６に示す例では、登録応答のペイロードのフォーマットは、ステータスを有する。ステータスは、登録要求で登録が要求された子ノードの登録が成功したか失敗したかを示し、成功の場合は０、失敗の場合は失敗の理由を示す０以外の値が格納される。
【００４３】
図７は、本実施形態のデータ認証要求のペイロードのフォーマットの一例を示す図である。図７に示す例では、データ認証要求のペイロードのフォーマットは、鍵仕様、メッセージ認証アルゴリズム識別子、及び被認証データを有する。
【００４４】
図８は、本実施形態の鍵仕様の一例を示す図である。図８に示す例では、鍵仕様は、指定子種別、及び指定子を有する。指定子種別は、完全指定子及び参照指定子のいずれかを示す。指定子種別が完全指定子の場合、指定子には完全指定子が格納され、指定子種別が参照指定子の場合、指定子には整数値である参照指定子が格納される。なお、指定子に完全指定子のみを用いる場合（参照指定子をサポートしない場合）は、指定子種別を省略できる。
【００４５】
図９は、本実施形態の完全指定子の一例を示す図である。図９に示す例では、完全指定子は、完全指定子要素の順次リストとして定義されている。各完全指定子要素は、鍵種別、親鍵の鍵長、鍵導出関数識別子、ハッシュ関数識別子、鍵導出関数出力長、鍵導出関数出力中の鍵系列開始位置、鍵導出関数出力中の鍵系列終了位置、及び鍵ラベルのフィールドを有する。
【００４６】
鍵種別（以下、「Ｔ」と称する場合がある）は、導出される鍵の種別である。親鍵の鍵長（以下、「Ｐ」と称する場合がある）は、鍵の導出に使用する親鍵のオクテット長である。鍵導出関数識別子（以下、鍵導出関数を「Ｄ」と称する場合がある）は、任意の長さの鍵の導出に使用する鍵導出関数の識別子である。ハッシュ関数識別子（以下、ハッシュ関数を「Ｈ」と称する場合がある）は、鍵導出関数の中で使用されるハッシュアルゴリズムの識別子である。鍵導出関数出力中の鍵系列開始位置（以下、「ｓ」と称する場合がある）は、鍵導出関数の出力シーケンス中で導出される鍵の開始位置である。鍵導出関数出力中の鍵系列終了位置（以下、「ｅ」と称する場合がある）は、鍵導出関数の出力シーケンス中で導出される鍵の終了位置である。鍵ラベル（以下、「Ｌ」と称する場合がある）は、鍵導出関数の入力パラメータである。
【００４７】
親鍵をＫＰとすると、子ノード１０−１は、親ノード２０から図９示す完全指定子で指定された鍵仕様を用いて、数式（１）により鍵Ｋを生成する。
【００４８】
Ｋ＝ＫＤＦ＿Ｐ（ＫＰ，ｆ（Ｌ））［ｓ，ｅ］…（１）
【００４９】
ここで、Ｌ１、Ｌ２は、親ノード２０に対して未公開のラベルであり、鍵種別Ｔから定まる。ｆ（Ｌ）は、ラベルＬからあるオクテット列を生成する関数である。ｆ（Ｌ）の一例として、ｆ（Ｌ）＝Ｌ１｜｜Ｌ｜｜Ｌ２がある。ここで、Ｌ１、Ｌ２は、ＮＵＬＬであってもよい。ＫＤＦ＿Ｐ（ＫＰ，ｆ（Ｌ））は、オクテット長Ｐの鍵ＫＰとオクテット列ｆ（Ｌ）とから、ハッシュ関数Ｈを用いた鍵導出関数Ｄで生成された任意長のオクテット列である。以下、ＫＤＦ＿Ｐ（ＫＰ，ｆ（Ｌ））をＳと称する。Ｓ［ｓ，ｅ］は、オクテット列Ｓのｓオクテット目からｅオクテット目までの長さ（ｅ−ｓ＋１)のオクテット列を取り出す関数である。
【００５０】
なお、鍵導出関数は、例えば、ＲＦＣ ５４３３に記載されたＧＫＤＦ（Generalized Key Derivation Function)やＲＦＣ ５９９６に記載されたｐｒｆ＋などがある。また、鍵導出関数は、出力オクテット列の先頭Ｐオクテットが鍵ＫＰと同一であるようなものであってもよい。このようにすれば、例えば、最上位階層の鍵を用いてメッセージ認証コードを生成するなど親鍵を子供鍵として使用するケースにも対応できる。
【００５１】
図１０は、本実施形態のデータ認証応答のペイロードのフォーマットの一例を示す図である。図１０に示す例では、データ認証応答のペイロードのフォーマットは、被認証データのメッセージ認証コード、参照指定子、及びステータスを有する。データ認証応答に参照指定子を含めるか否かは任意である。データ認証応答に参照指定子を含める場合、参照指定子の値は、データ認証応答の送信元が割り当てる。ステータスは、メッセージ認証コード生成が成功したか失敗したかを示し、成功の場合は０、失敗の場合は失敗の理由を示す０以外の値が格納される。
【００５２】
図１１は、本実施形態の鍵要求のペイロードのフォーマットの一例を示す図である。図１１に示す例では、鍵要求のペイロードのフォーマットは、鍵仕様を有する。鍵仕様の詳細は、図８及び図９で説明したとおりである。
【００５３】
図１２は、本実施形態の鍵応答のペイロードのフォーマットの一例を示す図である。図１２に示す例では、鍵応答のペイロードのフォーマットは、鍵及びステータスを有する。ステータスは、鍵取得が成功したか失敗したかを示し、成功の場合は０、失敗の場合は失敗の理由を示す０以外の値が格納される。
【００５４】
なお、図５〜図７及び図１０〜図１２で説明した各メッセージのペイロードは、暗号化されて、図４で説明した共通メッセージフォーマットの暗号化ペイロードに格納される。但し、暗号化が必要ない場合、平文のまま格納される。
【００５５】
次に、シーケンスの内容について説明する。
【００５６】
まず、子ノード１０−１は、親ノード２０に登録要求（Ｌ，ＩＤ，Ｔ，ＣＲ１)を送信する（ステップＳ１０１）。ここで、Ｌは認証プロトコル識別子リスト、ＩＤは認証識別子、Ｔは登録ライフタイム（登録期間の値）であるものとする。
【００５７】
続いて、親ノード２０は、登録ライフタイムＴが示す期間、子ノード１０−１を登録し、子ノード１０−１に登録応答（ＳＲ１，ＣＲ２)を送信する（ステップＳ１０３）。ここで、ＳＲ１はステータスであるものとする。この後、親ノード２０は、認証プロトコルＸを起動する。そして、認証プロトコルＸ起動後（実行中）の所定タイミングで認証プロトコルＸから認証プロトコルＹが起動される。
【００５８】
続いて、認証プロトコルＹ起動後（実行中）に、メッセージＹ１の送信イベントが発生したとする。ここで、メッセージＹ１はＥＡＰ−ＧＰＳＫのメッセージＧＰＳＫ−２であるものとする。この場合、親ノード２０は、メッセージＹ１の送信に必要なメッセージ認証コードを取得するため、データ認証要求１（ＳＹ１，ＡＹ，ＤＹ１)を子ノード１０−１に送信する（ステップＳ１０５）。ここで、ＳＹ１はＳＫ１０３（図３参照）の鍵仕様、ＡＹはメッセージ認証アルゴリズム識別子、ＤＹ１はメッセージＹ１の被認証データであるものとする。
【００５９】
図１３は、本実施形態のＳＫ１０３に対する完全指定子の一例を示す図である。図１３に示す例では、完全指定子は、先頭から完全指定子要素１、完全指定子要素２の要素数２の順序リストとして定義されている。完全指定子要素１は、ＭＫ１０２（図３参照）に対応し、完全指定子要素２は、ＳＫ１０３（図３参照）に対応する。ＭＫ１０２、ＳＫ１０３ともに、親鍵のオクテット長が３２オクテットであり、鍵導出関数にＧＫＤＦ、ハッシュ関数にＨＭＡＣ＿ＳＨＡ２５６を使用する。
【００６０】
続いて、子ノード１０−１は、親ノード２０にデータ認証応答１（ＣＹ１，ＳＤ１)を送信する（ステップＳ１０７）。ここで、ＣＹ１は被認証データＤＹ１に対するメッセージ認証コード、ＳＤ１はステータスであるものとする。
【００６１】
続いて、親ノード２０は、アプリケーションサーバ３０にメッセージＹ１（ＤＹ１，ＣＹ１）を送信する（ステップＳ１０９）。
【００６２】
続いて、親ノード２０は、アプリケーションサーバ３０からメッセージＹ２（ＣＹ２，ＥＹ２）を受信する（ステップＳ１１１）。ここで、メッセージＹ２はＥＡＰ−ＧＰＳＫのメッセージＧＰＳＫ−３、ＣＹ２はメッセージＹ２のメッセージ認証コード、ＥＹ２はメッセージＹ２の暗号化データであるものとする。
【００６３】
続いて、親ノード２０は、子ノード１０−１に鍵要求（ＳＹ２）を送信する（ステップＳ１１３）。ここで、ＳＹ２は、ＰＫ１０４（図３参照）の鍵仕様であるものとする。
【００６４】
続いて、子ノード１０−１は、親ノード２０に鍵応答（Ｋ，ＳＫ)を送信する（ステップＳ１１５）。ここで、ＫはＰＫ１０４、ＳＫはステータスであるものとする。
【００６５】
続いて、親ノード２０は、Ｋを用いてＥＹ２を復号化し、ＤＹ２を取得する。ここで、ＤＹ２はメッセージＹ２の被認証データであるものとする。そして親ノード２０は、データ認証要求２（ＳＹ１，ＡＹ，ＤＹ２)を子ノード１０−１に送信する（ステップＳ１１７）。
【００６６】
続いて、子ノード１０−１は、親ノード２０にデータ認証応答２（ＣＹ２，ＳＤ２)を送信する（ステップＳ１１９）。ここで、ＣＹ２は被認証データＤＹ２に対するメッセージ認証コード、ＳＤ２はステータスであるものとする。そして親ノード２０は、メッセージＹ２のメッセージ認証コードとデータ認証応答２のメッセージ認証コードとがＣＹ２で一致することを確認する。
【００６７】
続いて、メッセージＹ３の送信イベントが発生したとする。ここで、メッセージＹ３はＥＡＰ−ＧＰＳＫのメッセージＧＰＳＫ−４であるものとする。この場合、親ノード２０は、メッセージＹ３の送信に必要なメッセージ認証コードを取得するため、データ認証要求３（ＳＹ１，ＡＹ，ＤＹ３)を子ノード１０−１に送信する（ステップＳ１２１）。ここで、ＤＹ３はメッセージＹ３の被認証データであるものとする。
【００６８】
続いて、子ノード１０−１は、親ノード２０にデータ認証応答３（ＣＹ３，ＳＤ３)を送信する（ステップＳ１２３）。ここで、ＣＹ３は被認証データＤＹ３に対するメッセージ認証コード、ＳＤ３はステータスであるものとする。
【００６９】
続いて、親ノード２０は、アプリケーションサーバ３０にメッセージＹ３（ＤＹ３，ＣＹ３）を送信する（ステップＳ１２５）。
【００７０】
以上で、認証プロトコルＹに関するメッセージ認証処理は完了となる。
【００７１】
続いて、親ノード２０は、アプリケーションサーバ３０から認証プロトコルＸのメッセージＸ１（ＤＸ１，ＣＸ１）を受信する（ステップＳ１２７）。ここで、メッセージＸ１は、ＰＡＮＡのＰＡＮＡ−Ａｕｔｈ−Ｒｅｑｕｅｓｔ（ＰＡＲ)メッセージでＣｂｉｔがオンになったものとする。また、ＤＸ１はメッセージＸ１の被認証データ、ＣＸ１は被認証データＤＸ１に対するメッセージ認証コードであるものとする。
【００７２】
続いて、親ノード２０は、データ認証要求４（ＳＸ，ＡＸ，ＤＸ１)を子ノード１０−１に送信する（ステップＳ１２９）。ここで、ＳＸはＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹ１０７（図３参照）の鍵仕様、ＡＸはメッセージ認証アルゴリズム識別子であるものとする。
【００７３】
図１４は、本実施形態のＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹ１０７に対する完全指定子の一例を示す図である。図１４に示す例では、完全指定子は、先頭から完全指定子要素１、完全指定子要素２、完全指定子要素３の要素数３の順序リストとして定義されている。完全指定子要素１は、ＭＫ１０２（図３参照）に対応し、完全指定子要素２は、ＭＳＫ１０５（図３参照）に対応し、完全指定子要素３は、ＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹ１０７（図３参照）に対応する。ＭＫ１０２は、親鍵のオクテット長が３２オクテットであり、鍵導出関数にＧＫＤＦ、ハッシュ関数にＨＭＡＣ＿ＳＨＡ２５６を使用する。ＭＳＫ１０５は、親鍵のオクテット長が３２オクテットであり、鍵導出関数にＧＫＤＦ、ハッシュ関数にＨＭＡＣ＿ＳＨＡ２５６を使用する。ＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹ１０７は、親鍵のオクテット長が６４オクテットであり、鍵導出関数にｐｒｆ＋、ハッシュ関数にＨＭＡＣ＿ＳＨＡ１を使用する。
【００７４】
続いて、子ノード１０−１は、親ノード２０にデータ認証応答４（ＣＸ１，ＳＤ４)を送信する（ステップＳ１３１）。ここで、ＳＤ４はステータスであるものとする。そして親ノード２０は、メッセージＸ１のメッセージ認証コードとデータ認証応答４のメッセージ認証コードとがＣＸ１で一致することを確認する。
【００７５】
続いて、メッセージＸ２の送信イベントが発生したとする。ここで、メッセージＸ２は、ＰＡＮＡのＰＡＮＡ−Ａｕｔｈ−Ａｎｓｗｅｒ（ＰＡＮ)メッセージでＣｂｉｔがオンになったものとする。この場合、親ノード２０は、メッセージＸ２の送信に必要なメッセージ認証コードを取得するため、データ認証要求５（ＳＸ，ＡＸ，ＤＸ２)を子ノード１０−１に送信する（ステップＳ１３３）。ここで、ＤＸ２はメッセージＸ２の被認証データであるものとする。
【００７６】
続いて、子ノード１０−１は、親ノード２０にデータ認証応答５（ＣＸ２，ＳＤ５)を送信する（ステップＳ１３５）。ここで、ＣＸ２は被認証データＤＸ２に対するメッセージ認証コード、ＳＤ５はステータスであるものとする。
【００７７】
続いて、親ノード２０は、アプリケーションサーバ３０にメッセージＸ２（ＤＸ２，ＣＸ２）を送信する（ステップＳ１３７）。
【００７８】
図１５は、本実施形態の子ノード１０−１で実行される処理の一例を示すフローチャートである。
【００７９】
まず、登録処理部１１は、親ノード２０に登録要求を送信する（ステップＳ２０１）。
【００８０】
続いて、登録処理部１１は、親ノード２０から登録応答を受信する（ステップＳ２０２）。
【００８１】
続いて、主処理部１３は、主処理を行う（ステップＳ２０３）。なお、主処理の詳細については、後述する。
【００８２】
続いて、登録処理部１１は、登録がタイムアウトし、親ノード２０に再登録が必要であるか否かを確認する（ステップＳ２０４）。そして、再登録が必要であれば（ステップＳ２０４でＹｅｓ）、ステップＳ２０１に戻り、再登録が必要でなければ（ステップＳ２０４でＮｏ）、処理は終了となる。
【００８３】
図１６は、本実施形態の主処理の一例を示すフローチャートである。
【００８４】
まず、主処理部１３は、親ノード２０からイベントを受信する（ステップＳ３０１）。
【００８５】
続いて、主処理部１３は、受信したイベントが登録タイムアウトを示すイベントであるか否か確認する（ステップＳ３０２）。登録タイムアウトを示すイベントである場合（ステップＳ３０２でＹｅｓ）、処理は終了となる。
【００８６】
登録タイムアウトを示すイベントでない場合（ステップＳ３０２でＮｏ）、主処理部１３は、受信したイベントがデータ認証要求か否か確認する（ステップＳ３０３）。
【００８７】
受信したイベントがデータ認証要求である場合（ステップＳ３０３でＹｅｓ）、主処理部１３は、データ認証要求から鍵仕様Ｓ、被認証データＤ、及びメッセージ認証アルゴリズム識別子を取得し、メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムＡを更に取得する（ステップＳ３０４）。
【００８８】
続いて、鍵生成部１５は、保持している鍵階層と鍵仕様Ｓとを用いて、鍵仕様Ｓに対応する鍵Ｋを生成する（ステップＳ３０５）。なお、主処理部１３は、鍵キャッシュ（Ｓ，Ｋ)を作成し、保持してもよい。なお、主処理部１３が鍵キャッシュ（Ｓ，Ｋ)を保持している場合、鍵生成部１５による鍵Ｋの生成を省略し、鍵キャッシュ（Ｓ，Ｋ)から鍵Ｋを取得してもよい。
【００８９】
続いて、主処理部１３は、鍵Ｋ及びメッセージ認証アルゴリズムＡを使用して、被認証データＤに対するメッセージ認証コードＣ’を生成する（ステップＳ３０６）。
【００９０】
続いて、主処理部１３は、メッセージ認証コードＣ’を含むデータ認証応答を親ノード２０に送信する（ステップＳ３０７）。そして、ステップ３０１へ戻る。
【００９１】
一方、受信したイベントがデータ認証要求でない場合（ステップＳ３０３でＮｏ）、主処理部１３は、受信したイベントが鍵要求か否か確認する（ステップＳ３０８）。鍵要求でなければ（ステップＳ３０８でＮｏ）、ステップ３０１へ戻る。
【００９２】
受信したイベントが鍵要求である場合（ステップＳ３０８でＹｅｓ）、主処理部１３は、鍵要求から鍵仕様Ｓを取得する（ステップＳ３０９）。
【００９３】
続いて、鍵生成部１５は、保持している鍵階層と鍵仕様Ｓとを用いて、鍵仕様Ｓに対応する鍵Ｋを生成する（ステップＳ３１０）。
【００９４】
続いて、主処理部１３は、鍵Ｋを含む鍵応答を親ノード２０に送信する（ステップＳ３１１）。そして、ステップＳ３０１へ戻る。
【００９５】
図１７は、本実施形態の親ノード２０で実行される処理の一例を示すフローチャートである。
【００９６】
まず、認証プロトコル処理部２３は、イベントを受信する（ステップＳ４０１）。
【００９７】
続いて、認証プロトコル処理部２３は、受信したイベントが登録要求か否か確認する（ステップＳ４０２）。
【００９８】
受信したイベントが登録要求である場合（ステップＳ４０２でＹｅｓ）、登録処理部２１は、登録要求を送信した子ノードを登録する（ステップＳ４０３）。そして、ステップＳ４０１へ戻る。
【００９９】
受信したイベントが登録要求でない場合（ステップＳ４０２でＮｏ）、登録処理部２１は、登録されている子ノードのうち登録がタイムアウトしている子ノードがあるか否かを確認する（ステップＳ４０４）。
【０１００】
登録がタイムアウトしている子ノードがある場合（ステップＳ４０４でＹｅｓ）、登録処理部２１は、当該子ノードの登録を抹消する（ステップＳ４０５）。そして、ステップＳ４０１へ戻る。
【０１０１】
登録がタイムアウトしている子ノードがない場合（ステップＳ４０４でＮｏ）、認証プロトコル処理部２３は、受信したイベントがアプリケーションサーバ３０からのメッセージ受信イベントであるか否か確認する（ステップＳ４０６）。
【０１０２】
受信したイベントがアプリケーションサーバ３０からのメッセージ受信イベントである場合（ステップＳ４０６でＹｅｓ）、認証プロトコル処理部２３は、親ノードメッセージ受信処理を行う（ステップＳ４０７）。なお、親ノードメッセージ受信処理の詳細については、後述する。そして、ステップＳ４０１へ戻る。
【０１０３】
受信したイベントがアプリケーションサーバ３０からのメッセージ受信イベントでない場合（ステップＳ４０６でＮｏ）、認証プロトコル処理部２３は、受信したイベントがアプリケーションサーバ３０へのメッセージ送信イベントであるか否か確認する（ステップＳ４０８）。
【０１０４】
受信したイベントがアプリケーションサーバ３０へのメッセージ送信イベントでない場合（ステップＳ４０８でＮｏ）、ステップＳ４０１へ戻る。
【０１０５】
受信したイベントがアプリケーションサーバ３０へのメッセージ送信イベントである場合（ステップＳ４０８でＹｅｓ）、認証プロトコル処理部２３は、親ノードメッセージ送信処理を行う（ステップＳ４０９）。なお、親ノードメッセージ送信処理の詳細については、後述する。そして、ステップＳ４０１へ戻る。
【０１０６】
図１８は、本実施形態の親ノードメッセージ受信処理の一例を示すフローチャートである。
【０１０７】
まず、認証プロトコル処理部２３は、アプリケーションサーバ３０からメッセージを受信すると、受信したメッセージの認証に用いる子ノードを決定し、プロトコル種別Ｔｐ、メッセージ種別Ｔｍ、被認証データＤ、メッセージ認証コードＣ、及びメッセージ認証アルゴリズム識別子を取得する（ステップＳ５０１）。
【０１０８】
続いて、認証プロトコル処理部２３は、メッセージ認証コード取得処理を行う（ステップＳ５０２）。なお、メッセージ認証コード取得処理の詳細については、後述する。
【０１０９】
続いて、認証プロトコル処理部２３は、ステップＳ５０２で取得したメッセージ認証コードＣ’がステップＳ５０１で取得したメッセージ認証コードＣと一致するか否か確認する（ステップＳ５０３）。
【０１１０】
両メッセージ認証コードが一致する場合（ステップＳ５０３でＹｅｓ）、認証プロトコル処理部２３は、受信したメッセージの復号化が必要か否か確認する（ステップＳ５０４）。受信したメッセージの復号化が必要でない場合（ステップＳ５０４でＮｏ）、ステップＳ５０７へ進む。
【０１１１】
受信したメッセージの復号化が必要な場合（ステップＳ５０４でＹｅｓ）、認証プロトコル処理部２３は、鍵取得処理を行う（ステップＳ５０５）。なお、鍵取得処理の詳細については、後述する。
【０１１２】
続いて、認証プロトコル処理部２３は、鍵取得処理で取得した鍵を用いて、受信したメッセージを復号化する（ステップＳ５０６）。
【０１１３】
続いて、認証プロトコル処理部２３は、その他のメッセージ受信処理を行い（ステップＳ５０７）、処理は終了となる。
【０１１４】
一方、ステップＳ５０３で両メッセージ認証コードが一致しない場合（ステップＳ５０３でＮｏ）、認証プロトコル処理部２３は、メッセージ認証失敗時のメッセージ受信処理を行い（ステップＳ５０８）、処理は終了となる。
【０１１５】
なお、図１８に示す例では、暗号化されたメッセージにメッセージ認証コードＣが含まれていないため、メッセージ認証を行った後にメッセージを復号化したが、暗号化されたメッセージにメッセージ認証コードＣが含まれている場合は、メッセージを復号化した後に、メッセージ認証を行うことになる。
【０１１６】
図１９は、本実施形態の親ノードメッセージ送信処理の一例を示すフローチャートである。
【０１１７】
まず、認証プロトコル処理部２３は、アプリケーションサーバ３０へのメッセージ送信イベントが発生すると、送信対象のメッセージの認証に用いる子ノードを決定し、プロトコル種別Ｔｐ、メッセージ種別Ｔｍ、被認証データＤ、及びメッセージ認証アルゴリズム識別子を取得する（ステップＳ６０１）。
【０１１８】
続いて、認証プロトコル処理部２３は、送信対象のメッセージの暗号化が必要か否か確認する（ステップＳ６０２）。送信対象のメッセージの暗号化が必要でない場合（ステップＳ６０２でＮｏ）、ステップＳ６０５へ進む。
【０１１９】
送信対象のメッセージの暗号化が必要な場合（ステップＳ６０２でＹｅｓ）、認証プロトコル処理部２３は、鍵取得処理を行う（ステップＳ６０３）。なお、鍵取得処理の詳細については、後述する。
【０１２０】
続いて、認証プロトコル処理部２３は、鍵取得処理で取得した鍵を用いて、受信したメッセージを暗号化する（ステップＳ６０４）。
【０１２１】
続いて、認証プロトコル処理部２３は、メッセージ認証コード取得処理を行う（ステップＳ６０５）。なお、メッセージ認証コード取得処理の詳細については、後述する。
【０１２２】
続いて、認証プロトコル処理部２３は、ステップＳ６０５で取得したメッセージ認証コードＣ’を暗号化したメッセージに付加してアプリケーションサーバ３０へ送信する（ステップＳ６０６）。
【０１２３】
図２０は、本実施形態のメッセージ認証コード取得処理の一例を示すフローチャートである。
【０１２４】
まず、認証プロトコル処理部２３は、メッセージの認証に用いる子ノードが登録されているか否か確認する（ステップＳ７０１）。メッセージの認証に用いる子ノードが登録されていなければ（ステップＳ７０１でＮｏ）、処理は終了となる。
【０１２５】
メッセージの認証に用いる子ノードが登録されている場合（ステップＳ７０１でＹｅｓ）、鍵仕様生成部２５は、プロトコル種別Ｔｐ及びメッセージ種別Ｔｍから鍵仕様Ｓを生成する（ステップＳ７０２）。
【０１２６】
続いて、認証プロトコル処理部２３は、鍵仕様Ｓ、被認証データＤ及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を、メッセージの認証に用いる子ノードに送信し（ステップＳ７０３）、当該子ノードからメッセージ認証コードＣ’を含むデータ認証応答を受信する（ステップＳ７０４）。
【０１２７】
続いて、認証プロトコル処理部２３は、データ認証応答からメッセージ認証コードＣ’を取得する（ステップＳ７０５）。
【０１２８】
図２１は、本実施形態の鍵取得処理の一例を示すフローチャートである。
【０１２９】
まず、鍵仕様生成部２５は、プロトコル種別Ｔｐ及びメッセージ種別Ｔｍから鍵仕様Ｓを生成する（ステップＳ８０１）。
【０１３０】
続いて、認証プロトコル処理部２３は、鍵仕様Ｓに対応する暗号鍵を保有しているか否か確認する（ステップＳ８０２）。
【０１３１】
鍵仕様Ｓに対応する暗号鍵を保有している場合（ステップＳ８０２でＹｅｓ）、認証プロトコル処理部２３は、保有している暗号鍵を有効化し（ステップＳ８０３）、処理は終了となる。
【０１３２】
鍵仕様Ｓに対応する暗号鍵を保有していない場合（ステップＳ８０２でＮｏ）、認証プロトコル処理部２３は、鍵仕様Ｓを含む鍵要求を、メッセージの認証に用いる子ノードに送信し（ステップＳ８０４）、当該子ノードから暗号鍵を含む鍵応答を受信する（ステップＳ８０５）。
【０１３３】
続いて、認証プロトコル処理部２３は、鍵応答から暗号鍵を取得する（ステップＳ８０６）。なお、認証プロトコル処理部２３は、取得した暗号鍵を鍵仕様Ｓと対応付けて保有してもよい。
【０１３４】
なお、上記実施形態の複数の子ノード１０−１〜１０−Ｎ及び親ノード２０は、例えば、ＣＰＵなどの制御装置と、ＲＯＭやＲＡＭなどの記憶装置と、ＨＤＤやＳＳＤなどの外部記憶装置と、通信Ｉ／Ｆなどの通信装置とを備えており、通常のコンピュータを利用したハードウェア構成で実現できる。
【０１３５】
この場合、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０で実行されるプログラムは、ＲＯＭ等に予め組み込んで提供される。
【０１３６】
また、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０で実行されるプログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、ＣＤ−Ｒ、メモリカード、ＤＶＤ、フレキシブルディスク（ＦＤ）等のコンピュータで読み取り可能な記憶媒体に記憶されて提供するようにしてもよい。
【０１３７】
また、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するようにしてもよい。また、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０で実行されるプログラムを、インターネット等のネットワーク経由で提供または配布するようにしてもよい。
【０１３８】
複数の子ノード１０−１〜１０−Ｎ及び親ノード２０で実行されるプログラムは、上述した各部をコンピュータ上で実現させるためのモジュール構成となっている。実際のハードウェアとしては、例えば、ＣＰＵがＨＤＤからプログラムをＲＡＭ上に読み出して実行することにより、上記各部がコンピュータ上で実現されるようになっている。
【０１３９】
以上のように本実施形態の通信システムによれば、いずれの子ノードも認証プロトコルのステートを管理する必要がなく、少なくとも鍵仕様に基づく鍵の生成及び生成された鍵を用いたメッセージ認証コードの生成を行えばよいため、セキュリティを損なうことなく実装の軽装化が可能となる。
【０１４０】
また本実施形態の子ノードは、鍵階層のルート鍵を保持していればよく、その他の鍵はルート鍵と鍵仕様から必要な時に生成すればよいため、子ノードのメモリサイズを抑えることもできる。
【０１４１】
以上より、子ノードの数が増えるほど、通信システム全体として子ノードの軽装化によりハードウェアコストを抑えることができる。
【０１４２】
また本実施形態では、子ノードに対する相手認証のメッセージ認証以外のプロトコル処理を親ノードが代理で行うため、子ノードを軽装化してもＥＡＰやＰＡＮＡを用いた相手認証が可能となる。このため、不正な装置が親ノードを介してアプリケーションサーバと通信することを防止できる。
【０１４３】
また本実施形態では、親ノードは鍵階層を保持しないため、攻撃者により親ノードが乗っ取られた場合でも、鍵階層を守ることができる。
【０１４４】
また本実施形態では、被認証データの暗号鍵を子ノードが保持する鍵階層から生成するため、仮に攻撃者により親ノードが乗っ取られたとしても、被認証データの秘匿性及び完全性を維持でき、子ノード及びアプリケーションサーバへの影響を最小限に抑えることができる。
【０１４５】
また本実施形態の親ノードは、認証プロトコル固有の情報を子ノードに送信する必要がないため、子ノードとの間でやりとりするメッセージサイズ及びメッセージ数を削減することができる。
【０１４６】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせても良い。
【０１４７】
以上のように本実施形態によれば、軽装化及び相手認証を実現することができる。
【符号の説明】
【０１４８】
１ 通信システム
１０−１〜１０−Ｎ 子ノード
１１ 登録処理部
１３ 主処理部
１５ 鍵生成部
２０ 親ノード
２１ 登録処理部
２３ 認証プロトコル処理部
２５ 鍵仕様生成部
３０ アプリケーションサーバ
【技術分野】
【０００１】
本発明の実施形態は、通信装置及びプログラムに関する。
【背景技術】
【０００２】
従来から、電気メータなどの装置をＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）ゲートウェイを介してリモートサーバなどの外部装置と通信させる技術が知られている。
【０００３】
このような技術では、例えば、電気メータが、自身が測定した計量データを、レイヤ２フレームを用いてｎｏｎ−ＩＰパケットとしてＴＣＰ／ＩＰゲートウェイに送信し、ＴＣＰ／ＩＰゲートウェイが、電気メータから受信した計量データをＨＴＴＰ（HyperText Transfer Protocol） ｏｖｅｒ ＴＣＰ／ＩＰを用いてリモートサーバに送信する。
【０００４】
このようにすれば、電気メータとリモートサーバとの通信において、電気メータの軽装化が可能となる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許第６３６３０５７号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述したような従来技術では、正当でない装置が外部装置と通信できてしまうなどセキュリティ上の問題がある。本発明が解決しようとする課題は、軽装化及び相手認証を実現することができる通信装置及びプログラムを提供することである。
【課題を解決するための手段】
【０００７】
実施形態の通信装置は、上位装置を介して外部装置と通信し、主処理部と、鍵生成部と、を備える。主処理部は、上位装置から、被認証データ、第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を受信する。鍵生成部は、上位装置と外部装置との間で用いられる認証プロトコルが使用する鍵階層を保持し、鍵階層と第１鍵仕様とを用いて第１鍵を生成する。主処理部は、メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムと第１鍵とを用いて被認証データに対するメッセージ認証コードを生成し、当該メッセージ認証コードを含むデータ認証応答を上位装置に送信する。
【図面の簡単な説明】
【０００８】
【図１】本実施形態の通信システムの例を示す構成図。
【図２】本実施形態の通信システムの処理例を示すシーケンス図。
【図３】本実施形態の鍵階層の例を示す図。
【図４】本実施形態の共通メッセージフォーマットの例を示す図。
【図５】本実施形態の登録要求のペイロードのフォーマットの例を示す図。
【図６】本実施形態の登録応答のペイロードのフォーマットの例を示す図。
【図７】本実施形態のデータ認証要求のペイロードのフォーマットの例を示す図。
【図８】本実施形態の鍵仕様の例を示す図。
【図９】本実施形態の完全指定子の例を示す図である。
【図１０】本実施形態のデータ認証応答のペイロードのフォーマットの例を示す図。
【図１１】本実施形態の鍵要求のペイロードのフォーマットの例を示す図。
【図１２】本実施形態の鍵応答のペイロードのフォーマットの例を示す図。
【図１３】本実施形態のＳＫに対する完全指定子の例を示す図。
【図１４】本実施形態のＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹに対する完全指定子の例を示す図。
【図１５】本実施形態の子ノードの処理例を示すフローチャート。
【図１６】本実施形態の主処理の例を示すフローチャート。
【図１７】本実施形態の親ノードの処理例を示すフローチャート。
【図１８】本実施形態の親ノードメッセージ受信処理例を示すフローチャート。
【図１９】本実施形態の親ノードメッセージ送信処理例を示すフローチャート。
【図２０】本実施形態のメッセージ認証コード取得処理例を示すフローチャート。
【図２１】本実施形態の鍵取得処理例を示すフローチャート。
【発明を実施するための形態】
【０００９】
図１は、本実施形態の通信システム１の一例を示す構成図である。図１に示すように、通信システム１は、複数の子ノード１０−１〜１０−Ｎと、親ノード２０と、アプリケーションサーバ３０とを、備える。
【００１０】
複数の子ノード１０−１〜１０−Ｎと親ノード２０との通信は、例えば、有線ＬＡＮ（Local Area Network）や無線ＬＡＮなどのネットワークで実現してもよいし、ＢｌｕｅｔｏｏｔｈやＺｉｇＢｅｅなどの短距離無線通信で実現してもよい。親ノード２０とアプリケーションサーバ３０との通信は、例えば、有線ＬＡＮ（Local Area Network）や無線ＬＡＮなどのネットワークで実現できる。
【００１１】
子ノード１０−１〜１０−Ｎは、保持している鍵階層（詳細は後述）が互いに異なるが、用いられる用途、備えている構成要素、実行する動作は、いずれも同様である。このため、以下では、子ノード１０−１を主に説明し、子ノード１０−２〜１０−Ｎについては、その説明を省略する。
【００１２】
子ノード１０−１（通信装置、下位装置の一例）は、例えば、ガスメータ、電気メータ、家電機器、照明器具、センサー、アクチュエーター、又は電気自動車などに実装され、親ノード２０（通信装置、上位装置の一例）を介してアプリケーションサーバ３０（外部装置の一例）と通信する。
【００１３】
子ノード１０−１は、登録処理部１１と、主処理部１３と、鍵生成部１５とを、備える。登録処理部１１、主処理部１３、及び鍵生成部１５は、例えば、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、及びＲＯＭ（Read Only Memory）などを有する処理装置により実現してもよいし、ＩＣ（Integrated Circuit）により実現してもよいし、処理装置及びＩＣを併用して実現してもよい。
【００１４】
登録処理部１１は、後述の鍵生成部１５が保持している鍵階層を使用する認証プロトコルの識別子のリスト及び子ノード１０−１の認証識別子を含む登録要求を親ノード２０に送信し、親ノード２０から登録応答を受信する。なお登録処理部１１は、鍵生成部１５が保持している鍵階層を使用する認証プロトコルの識別子のリスト及び子ノード１０−１の認証識別子を予め保持している。
【００１５】
主処理部１３は、親ノード２０から、被認証データ、第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を受信する。そして主処理部１３は、メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムと後述の鍵生成部１５により第１鍵仕様から生成される第１鍵とを用いて、被認証データに対するメッセージ認証コードを生成し、当該メッセージ認証コードを含むデータ認証応答を親ノード２０に送信する。なお主処理部１３は、メッセージ認証アルゴリズムを予め保持しており、メッセージ認証アルゴリズム識別子で指定（識別）されるメッセージ認証アルゴリズムを用いて、メッセージ認証コードを生成する。
【００１６】
ここで、主処理部１３は、過去に受信したデータ認証要求に含まれる第１鍵仕様と当該第１鍵仕様から生成される第１鍵とを含む鍵キャッシュを保持し、新たに受信したデータ認証要求に含まれる第１鍵仕様と鍵キャッシュに含まれる第１鍵仕様とを比較するようにしてもよい。そして主処理部１３は、両者が一致する場合、鍵キャッシュに含まれる第１鍵と新たに受信したデータ認証要求に含まれるメッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムとを用いて、新たに受信したデータ認証要求に含まれる被認証データに対するメッセージ認証コードを生成するようにしてもよい。
【００１７】
また主処理部１３は、親ノード２０から第２鍵仕様を含む鍵要求を受信し、当該第２鍵仕様から後述の鍵生成部１５により生成される第２鍵を含む鍵応答を親ノード２０に送信する。
【００１８】
鍵生成部１５は、親ノード２０とアプリケーションサーバ３０との間で用いられる認証プロトコルが使用する鍵階層を保持する。そして鍵生成部１５は、主処理部１３によりデータ認証要求が受信されると、データ認証要求に含まれる第１鍵仕様と保持している鍵階層とを用いて第１鍵を生成し、鍵要求が受信されると、鍵要求に含まれる第２鍵仕様と保持している鍵階層とを用いて第２鍵を生成する。なお、生成された第１鍵、第２鍵は、鍵生成部１５が保持している鍵階層に属する。
【００１９】
親ノード２０は、例えば、電気メータ、ＨＥＭＳ（Home Energy Management System）サーバ、コンセントレータ、ルータ、無線ＬＡＮアクセスポイント、ＬＡＮスイッチ、又は電気自動車等などに実装され、複数の子ノード１０−１〜１０−Ｎとアプリケーションサーバ３０とを自身を介して通信させる。
【００２０】
親ノード２０は、登録処理部２１と、認証プロトコル処理部２３と、鍵仕様生成部２５とを、備える。登録処理部２１、認証プロトコル処理部２３、及び鍵仕様生成部２５は、例えば、ＣＰＵ、ＲＡＭ、及びＲＯＭなどを有する処理装置により実現してもよいし、ＩＣにより実現してもよいし、処理装置及びＩＣを併用して実現してもよい。
【００２１】
登録処理部２１は、複数の子ノード１０−１〜１０−Ｎのそれぞれから、当該子ノードが保持する鍵階層を使用する認証プロトコルの識別子のリスト及び当該子ノードの認証識別子を含む登録要求を受信する。そして登録処理部２１は、当該子ノードの登録期間の間、登録要求の内容と当該子ノードのアドレスとを対応付けて保持し、登録要求を受信した子ノードに登録応答を送信する。なお登録処理部２１は、複数の子ノード１０−１〜１０−Ｎそれぞれのアドレスを予め保持しており、このアドレスを登録要求の内容と対応付ける。また、登録要求に、登録期間の値が更に含まれていてもよい。
【００２２】
認証プロトコル処理部２３は、親ノード２０とアプリケーションサーバ３０との間で用いられる認証プロトコルの処理のうちメッセージ認証コード生成以外の処理を行う。本実施形態では、認証プロトコルは、ＰＡＮＡ（Protocol for carrying Authentication for Network Access）及びＥＡＰ（Extensible Authentication Protocol）認証メソッドを含むものとするが、これに限定されるものではない。
【００２３】
また認証プロトコル処理部２３は、被認証データ、後述の鍵仕様生成部２５により生成される第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を、複数の子ノード１０−１〜１０−Ｎのうち認証プロトコルが使用する鍵階層を有する子ノードに送信する。なお認証プロトコル処理部２３は、アプリケーションサーバ３０との間で送信又は受信されるメッセージから、被認証データ及びメッセージ認証アルゴリズム識別子を取得する。本実施形態では、被認証データは、アプリケーションサーバ３０と間で交換されるアプリケーションデータであるものとするが、これに限定されるものではない。認証プロトコル処理部２３は、データ認証要求を送信した子ノードから、被認証データに対するメッセージ認証コードを含むデータ認証応答を受信する。そして認証プロトコル処理部２３は、子ノードから受信したメッセージ認証コードを用いて、被認証データのメッセージ認証を行う。
【００２４】
また認証プロトコル処理部２３は、後述の鍵仕様生成部２５により生成される第２鍵仕様を含む鍵要求を、複数の子ノード１０−１〜１０−Ｎのうち認証プロトコルが使用する鍵階層を有する子ノードに送信し、当該子ノードから、当該第２鍵仕様から生成される第２鍵を含む鍵応答を受信する。そして認証プロトコル処理部２３は、当該第２鍵を用いて、被認証データの暗号化又は復号化を行う。本実施形態では、鍵応答に含まれる第２鍵は、アプリケーションサーバ３０と間で共有されるものとする。
【００２５】
鍵仕様生成部２５は、認証プロトコルが使用する鍵階層に属する第１鍵を、複数の子ノード１０−１〜１０−Ｎのうち当該鍵階層を有する子ノードに生成させるための第１鍵仕様を生成する。また鍵仕様生成部２５は、認証プロトコルが使用する鍵階層に属する第２鍵を、複数の子ノード１０−１〜１０−Ｎのうち当該鍵階層を有する子ノードに生成させるための第２鍵仕様を生成する。
【００２６】
鍵仕様は、鍵種別、親鍵の鍵長、鍵導出関数識別子、ハッシュ関数識別子、鍵導出関数出力長、鍵導出関数出力中の鍵系列開始位置、鍵導出関数出力中の鍵系列終了位置、及び鍵ラベルを含む完全指定要素の順序リストである完全指定子、又は当該完全指定子に対応する整数値である参照指定子により指定され、完全指定子による指定か参照指定子による指定かを識別する指定子種別を含む。参照指定子の値は、データ認証応答の送信元により割当てられ、データ認証応答により通知されるので、鍵仕様生成部２５は、参照指定子と完全指定子の対応関係を保持しておく。これにより、鍵仕様生成部２５は、完全指定子ではなく参照指定子による指定が可能となる。なお、鍵仕様は、完全指定子のみにより指定されるようにしてもよい。
【００２７】
なお、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０は、登録要求、登録応答、データ認証要求、データ認証応答、鍵要求、及び鍵応答を、データリンクレイヤ、ネットワークレイヤ、及びトランスポートレイヤのいずれのレイヤのプロトコルを用いて送受信してもよい。
【００２８】
また、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０は、登録要求、登録応答、データ認証要求、データ認証応答、鍵要求、及び鍵応答を、暗号化したりメッセージ認証を施したりして送受信してもよい。この場合、暗号化やメッセージ認証には、複数の子ノード１０−１〜１０−Ｎそれぞれと親ノード２０との間で共有される共通鍵が用いられる。この共通鍵は子ノード毎に異なることが望ましい。
【００２９】
図２は、本実施形態の通信システム１で実行される処理の一例を示すシーケンス図である。
【００３０】
図２に示す例では、通信システム１は、認証プロトコルＸ及び認証プロトコルＹの２種類の認証プロトコルを用いて認証を行う。具体的には、認証プロトコルＹのメッセージは、認証プロトコルＸのメッセージによりカプセル化され、認証プロトコルＸがメッセージ認証に用いる鍵は、認証プロトコルＹが使用する鍵階層から生成される。図２に示す例では、認証プロトコルＸは、ＰＡＮＡ（ＲＦＣ ５１９１）であり、認証プロトコルＹは、ＥＡＰ−ＧＰＳＫ（ＲＦＣ ５４３３）であるものとするが、これに限定されるものではない。
【００３１】
なお、図２に示す例では、複数の子ノード１０−１〜１０−Ｎと親ノード２０との通信については、子ノード１０−１と親ノード２０との通信についてのみ図示している。また、図２に示す例では、親ノード２０とアプリケーションサーバ３０との間で通信される認証プロトコルＸのメッセージ及び認証プロトコルＹのメッセージは、メッセージ認証コードが付加されるもののみを図示すものとする。このため、図２に示す例では、メッセージ認証アルゴリズムのネゴシエーションや認証識別子の通知に使用されるメッセージなどのメッセージ認証コードが付加されないメッセージについては、図示を省略している。
【００３２】
シーケンスの内容を説明する前に、図２に示す例において、子ノード１０−１が保持する鍵階層、及び子ノード１０−１と親ノード２０との間で通信されるメッセージのメッセージフォーマットについて説明する。
【００３３】
図３は、本実施形態の子ノード１０−１が保持する鍵階層の一例を示す図である。図３に示す例では、鍵階層は、親ノード２０とアプリケーションサーバ３０とがネットワークアクセス認証プロトコルとしてＰＡＮＡ（ＲＦＣ ５１９１）を使用し、ＰＡＮＡ上でＥＡＰ認証メソッドＥＡＰ−ＧＰＳＫ（ＲＦＣ ５４３３）を使用する場合に、これらの認証プロトコルが使用するものとなっている。
【００３４】
図３に示す例では、ＰＳＫ（Pre-Shared Key）１０１は、ＥＡＰ−ＧＰＳＫで使用される共通鍵認証の共通鍵、ＭＫ（Master Key）１０２は、ＰＳＫ１０１から導出されるマスター鍵、ＳＫ（Session Key）１０３は、ＥＡＰ−ＧＰＳＫのメッセージ認証コード生成に使用される鍵、ＰＫ１０４は、ＥＡＰ−ＧＰＳＫのペイロード暗号化に使用される鍵、ＭＳＫ（Master Session Key）１０５及びＥＭＳＫ（Extended MSK）１０６は、ＥＡＰが下位層にエキスポートする鍵、ＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹ１０７は、ＰＡＮＡのメッセージのメッセージ認証コード生成に使用される鍵となっている。なお、図３に示す例では、ＥＡＰ−ＧＰＳＫのペイロード暗号化に使用される鍵は、ＰＫ１０４となっているが、これに限定されず、ＥＭＳＫ１０６の下の鍵階層に属する鍵としてもよい。
【００３５】
図４は、本実施形態のメッセージが使用する共通メッセージフォーマットの一例を示す図である。図４に示す例では、共通メッセージフォーマットは、メッセージ種別、ペイロード平文長、初期化ベクトル、暗号化ペイロード、及びメッセージ認証コードを有する。
【００３６】
メッセージ種別は、子ノード１０−１と親ノード２０との間で通信されるメッセージの種別を示し、データ認証要求、データ認証応答、登録要求、登録応答、鍵要求、及び鍵応答を区別するための整数値が格納される。
【００３７】
ペイロード平文長には、メッセージ種別が示すメッセージのペイロードの平文のオクテット長が格納される。
【００３８】
初期化ベクトルには、ランダム値が格納される。このランダム値は、暗号化ペイロードへの暗号化及び暗号化ペイロードからの復号化に対するリプレイ攻撃の防止に用いられる。
【００３９】
暗号化ペイロードには、メッセージ種別が示すメッセージのペイロードが子ノード１０−１と親ノード２０との間で共有される暗号鍵（共通鍵）で暗号化されて格納される。但し、暗号化が必要ない場合には、暗号化ペイロードには、メッセージ種別が示すメッセージのペイロードが平文で格納される。
【００４０】
メッセージ認証コードには、メッセージ種別、ペイロード平文長、初期化ベクトル、及び暗号化ペイロードに対するメッセージ認証コードの値が格納される。このメッセージ認証コードの値は、子ノード１０−１と親ノード２０との間で共有されるメッセージ認証鍵（共通鍵）を用いて生成される。
【００４１】
図５は、本実施形態の登録要求のペイロードのフォーマットの一例を示す図である。図５に示す例では、登録要求のペイロードのフォーマットは、認証プロトコル識別子リスト、認証識別子、及び登録ライフタイム（登録期間の値）を有する。
【００４２】
図６は、本実施形態の登録応答のペイロードのフォーマットの一例を示す図である。図６に示す例では、登録応答のペイロードのフォーマットは、ステータスを有する。ステータスは、登録要求で登録が要求された子ノードの登録が成功したか失敗したかを示し、成功の場合は０、失敗の場合は失敗の理由を示す０以外の値が格納される。
【００４３】
図７は、本実施形態のデータ認証要求のペイロードのフォーマットの一例を示す図である。図７に示す例では、データ認証要求のペイロードのフォーマットは、鍵仕様、メッセージ認証アルゴリズム識別子、及び被認証データを有する。
【００４４】
図８は、本実施形態の鍵仕様の一例を示す図である。図８に示す例では、鍵仕様は、指定子種別、及び指定子を有する。指定子種別は、完全指定子及び参照指定子のいずれかを示す。指定子種別が完全指定子の場合、指定子には完全指定子が格納され、指定子種別が参照指定子の場合、指定子には整数値である参照指定子が格納される。なお、指定子に完全指定子のみを用いる場合（参照指定子をサポートしない場合）は、指定子種別を省略できる。
【００４５】
図９は、本実施形態の完全指定子の一例を示す図である。図９に示す例では、完全指定子は、完全指定子要素の順次リストとして定義されている。各完全指定子要素は、鍵種別、親鍵の鍵長、鍵導出関数識別子、ハッシュ関数識別子、鍵導出関数出力長、鍵導出関数出力中の鍵系列開始位置、鍵導出関数出力中の鍵系列終了位置、及び鍵ラベルのフィールドを有する。
【００４６】
鍵種別（以下、「Ｔ」と称する場合がある）は、導出される鍵の種別である。親鍵の鍵長（以下、「Ｐ」と称する場合がある）は、鍵の導出に使用する親鍵のオクテット長である。鍵導出関数識別子（以下、鍵導出関数を「Ｄ」と称する場合がある）は、任意の長さの鍵の導出に使用する鍵導出関数の識別子である。ハッシュ関数識別子（以下、ハッシュ関数を「Ｈ」と称する場合がある）は、鍵導出関数の中で使用されるハッシュアルゴリズムの識別子である。鍵導出関数出力中の鍵系列開始位置（以下、「ｓ」と称する場合がある）は、鍵導出関数の出力シーケンス中で導出される鍵の開始位置である。鍵導出関数出力中の鍵系列終了位置（以下、「ｅ」と称する場合がある）は、鍵導出関数の出力シーケンス中で導出される鍵の終了位置である。鍵ラベル（以下、「Ｌ」と称する場合がある）は、鍵導出関数の入力パラメータである。
【００４７】
親鍵をＫＰとすると、子ノード１０−１は、親ノード２０から図９示す完全指定子で指定された鍵仕様を用いて、数式（１）により鍵Ｋを生成する。
【００４８】
Ｋ＝ＫＤＦ＿Ｐ（ＫＰ，ｆ（Ｌ））［ｓ，ｅ］…（１）
【００４９】
ここで、Ｌ１、Ｌ２は、親ノード２０に対して未公開のラベルであり、鍵種別Ｔから定まる。ｆ（Ｌ）は、ラベルＬからあるオクテット列を生成する関数である。ｆ（Ｌ）の一例として、ｆ（Ｌ）＝Ｌ１｜｜Ｌ｜｜Ｌ２がある。ここで、Ｌ１、Ｌ２は、ＮＵＬＬであってもよい。ＫＤＦ＿Ｐ（ＫＰ，ｆ（Ｌ））は、オクテット長Ｐの鍵ＫＰとオクテット列ｆ（Ｌ）とから、ハッシュ関数Ｈを用いた鍵導出関数Ｄで生成された任意長のオクテット列である。以下、ＫＤＦ＿Ｐ（ＫＰ，ｆ（Ｌ））をＳと称する。Ｓ［ｓ，ｅ］は、オクテット列Ｓのｓオクテット目からｅオクテット目までの長さ（ｅ−ｓ＋１)のオクテット列を取り出す関数である。
【００５０】
なお、鍵導出関数は、例えば、ＲＦＣ ５４３３に記載されたＧＫＤＦ（Generalized Key Derivation Function)やＲＦＣ ５９９６に記載されたｐｒｆ＋などがある。また、鍵導出関数は、出力オクテット列の先頭Ｐオクテットが鍵ＫＰと同一であるようなものであってもよい。このようにすれば、例えば、最上位階層の鍵を用いてメッセージ認証コードを生成するなど親鍵を子供鍵として使用するケースにも対応できる。
【００５１】
図１０は、本実施形態のデータ認証応答のペイロードのフォーマットの一例を示す図である。図１０に示す例では、データ認証応答のペイロードのフォーマットは、被認証データのメッセージ認証コード、参照指定子、及びステータスを有する。データ認証応答に参照指定子を含めるか否かは任意である。データ認証応答に参照指定子を含める場合、参照指定子の値は、データ認証応答の送信元が割り当てる。ステータスは、メッセージ認証コード生成が成功したか失敗したかを示し、成功の場合は０、失敗の場合は失敗の理由を示す０以外の値が格納される。
【００５２】
図１１は、本実施形態の鍵要求のペイロードのフォーマットの一例を示す図である。図１１に示す例では、鍵要求のペイロードのフォーマットは、鍵仕様を有する。鍵仕様の詳細は、図８及び図９で説明したとおりである。
【００５３】
図１２は、本実施形態の鍵応答のペイロードのフォーマットの一例を示す図である。図１２に示す例では、鍵応答のペイロードのフォーマットは、鍵及びステータスを有する。ステータスは、鍵取得が成功したか失敗したかを示し、成功の場合は０、失敗の場合は失敗の理由を示す０以外の値が格納される。
【００５４】
なお、図５〜図７及び図１０〜図１２で説明した各メッセージのペイロードは、暗号化されて、図４で説明した共通メッセージフォーマットの暗号化ペイロードに格納される。但し、暗号化が必要ない場合、平文のまま格納される。
【００５５】
次に、シーケンスの内容について説明する。
【００５６】
まず、子ノード１０−１は、親ノード２０に登録要求（Ｌ，ＩＤ，Ｔ，ＣＲ１)を送信する（ステップＳ１０１）。ここで、Ｌは認証プロトコル識別子リスト、ＩＤは認証識別子、Ｔは登録ライフタイム（登録期間の値）であるものとする。
【００５７】
続いて、親ノード２０は、登録ライフタイムＴが示す期間、子ノード１０−１を登録し、子ノード１０−１に登録応答（ＳＲ１，ＣＲ２)を送信する（ステップＳ１０３）。ここで、ＳＲ１はステータスであるものとする。この後、親ノード２０は、認証プロトコルＸを起動する。そして、認証プロトコルＸ起動後（実行中）の所定タイミングで認証プロトコルＸから認証プロトコルＹが起動される。
【００５８】
続いて、認証プロトコルＹ起動後（実行中）に、メッセージＹ１の送信イベントが発生したとする。ここで、メッセージＹ１はＥＡＰ−ＧＰＳＫのメッセージＧＰＳＫ−２であるものとする。この場合、親ノード２０は、メッセージＹ１の送信に必要なメッセージ認証コードを取得するため、データ認証要求１（ＳＹ１，ＡＹ，ＤＹ１)を子ノード１０−１に送信する（ステップＳ１０５）。ここで、ＳＹ１はＳＫ１０３（図３参照）の鍵仕様、ＡＹはメッセージ認証アルゴリズム識別子、ＤＹ１はメッセージＹ１の被認証データであるものとする。
【００５９】
図１３は、本実施形態のＳＫ１０３に対する完全指定子の一例を示す図である。図１３に示す例では、完全指定子は、先頭から完全指定子要素１、完全指定子要素２の要素数２の順序リストとして定義されている。完全指定子要素１は、ＭＫ１０２（図３参照）に対応し、完全指定子要素２は、ＳＫ１０３（図３参照）に対応する。ＭＫ１０２、ＳＫ１０３ともに、親鍵のオクテット長が３２オクテットであり、鍵導出関数にＧＫＤＦ、ハッシュ関数にＨＭＡＣ＿ＳＨＡ２５６を使用する。
【００６０】
続いて、子ノード１０−１は、親ノード２０にデータ認証応答１（ＣＹ１，ＳＤ１)を送信する（ステップＳ１０７）。ここで、ＣＹ１は被認証データＤＹ１に対するメッセージ認証コード、ＳＤ１はステータスであるものとする。
【００６１】
続いて、親ノード２０は、アプリケーションサーバ３０にメッセージＹ１（ＤＹ１，ＣＹ１）を送信する（ステップＳ１０９）。
【００６２】
続いて、親ノード２０は、アプリケーションサーバ３０からメッセージＹ２（ＣＹ２，ＥＹ２）を受信する（ステップＳ１１１）。ここで、メッセージＹ２はＥＡＰ−ＧＰＳＫのメッセージＧＰＳＫ−３、ＣＹ２はメッセージＹ２のメッセージ認証コード、ＥＹ２はメッセージＹ２の暗号化データであるものとする。
【００６３】
続いて、親ノード２０は、子ノード１０−１に鍵要求（ＳＹ２）を送信する（ステップＳ１１３）。ここで、ＳＹ２は、ＰＫ１０４（図３参照）の鍵仕様であるものとする。
【００６４】
続いて、子ノード１０−１は、親ノード２０に鍵応答（Ｋ，ＳＫ)を送信する（ステップＳ１１５）。ここで、ＫはＰＫ１０４、ＳＫはステータスであるものとする。
【００６５】
続いて、親ノード２０は、Ｋを用いてＥＹ２を復号化し、ＤＹ２を取得する。ここで、ＤＹ２はメッセージＹ２の被認証データであるものとする。そして親ノード２０は、データ認証要求２（ＳＹ１，ＡＹ，ＤＹ２)を子ノード１０−１に送信する（ステップＳ１１７）。
【００６６】
続いて、子ノード１０−１は、親ノード２０にデータ認証応答２（ＣＹ２，ＳＤ２)を送信する（ステップＳ１１９）。ここで、ＣＹ２は被認証データＤＹ２に対するメッセージ認証コード、ＳＤ２はステータスであるものとする。そして親ノード２０は、メッセージＹ２のメッセージ認証コードとデータ認証応答２のメッセージ認証コードとがＣＹ２で一致することを確認する。
【００６７】
続いて、メッセージＹ３の送信イベントが発生したとする。ここで、メッセージＹ３はＥＡＰ−ＧＰＳＫのメッセージＧＰＳＫ−４であるものとする。この場合、親ノード２０は、メッセージＹ３の送信に必要なメッセージ認証コードを取得するため、データ認証要求３（ＳＹ１，ＡＹ，ＤＹ３)を子ノード１０−１に送信する（ステップＳ１２１）。ここで、ＤＹ３はメッセージＹ３の被認証データであるものとする。
【００６８】
続いて、子ノード１０−１は、親ノード２０にデータ認証応答３（ＣＹ３，ＳＤ３)を送信する（ステップＳ１２３）。ここで、ＣＹ３は被認証データＤＹ３に対するメッセージ認証コード、ＳＤ３はステータスであるものとする。
【００６９】
続いて、親ノード２０は、アプリケーションサーバ３０にメッセージＹ３（ＤＹ３，ＣＹ３）を送信する（ステップＳ１２５）。
【００７０】
以上で、認証プロトコルＹに関するメッセージ認証処理は完了となる。
【００７１】
続いて、親ノード２０は、アプリケーションサーバ３０から認証プロトコルＸのメッセージＸ１（ＤＸ１，ＣＸ１）を受信する（ステップＳ１２７）。ここで、メッセージＸ１は、ＰＡＮＡのＰＡＮＡ−Ａｕｔｈ−Ｒｅｑｕｅｓｔ（ＰＡＲ)メッセージでＣｂｉｔがオンになったものとする。また、ＤＸ１はメッセージＸ１の被認証データ、ＣＸ１は被認証データＤＸ１に対するメッセージ認証コードであるものとする。
【００７２】
続いて、親ノード２０は、データ認証要求４（ＳＸ，ＡＸ，ＤＸ１)を子ノード１０−１に送信する（ステップＳ１２９）。ここで、ＳＸはＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹ１０７（図３参照）の鍵仕様、ＡＸはメッセージ認証アルゴリズム識別子であるものとする。
【００７３】
図１４は、本実施形態のＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹ１０７に対する完全指定子の一例を示す図である。図１４に示す例では、完全指定子は、先頭から完全指定子要素１、完全指定子要素２、完全指定子要素３の要素数３の順序リストとして定義されている。完全指定子要素１は、ＭＫ１０２（図３参照）に対応し、完全指定子要素２は、ＭＳＫ１０５（図３参照）に対応し、完全指定子要素３は、ＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹ１０７（図３参照）に対応する。ＭＫ１０２は、親鍵のオクテット長が３２オクテットであり、鍵導出関数にＧＫＤＦ、ハッシュ関数にＨＭＡＣ＿ＳＨＡ２５６を使用する。ＭＳＫ１０５は、親鍵のオクテット長が３２オクテットであり、鍵導出関数にＧＫＤＦ、ハッシュ関数にＨＭＡＣ＿ＳＨＡ２５６を使用する。ＰＡＮＡ＿ＡＵＴＨ＿ＫＥＹ１０７は、親鍵のオクテット長が６４オクテットであり、鍵導出関数にｐｒｆ＋、ハッシュ関数にＨＭＡＣ＿ＳＨＡ１を使用する。
【００７４】
続いて、子ノード１０−１は、親ノード２０にデータ認証応答４（ＣＸ１，ＳＤ４)を送信する（ステップＳ１３１）。ここで、ＳＤ４はステータスであるものとする。そして親ノード２０は、メッセージＸ１のメッセージ認証コードとデータ認証応答４のメッセージ認証コードとがＣＸ１で一致することを確認する。
【００７５】
続いて、メッセージＸ２の送信イベントが発生したとする。ここで、メッセージＸ２は、ＰＡＮＡのＰＡＮＡ−Ａｕｔｈ−Ａｎｓｗｅｒ（ＰＡＮ)メッセージでＣｂｉｔがオンになったものとする。この場合、親ノード２０は、メッセージＸ２の送信に必要なメッセージ認証コードを取得するため、データ認証要求５（ＳＸ，ＡＸ，ＤＸ２)を子ノード１０−１に送信する（ステップＳ１３３）。ここで、ＤＸ２はメッセージＸ２の被認証データであるものとする。
【００７６】
続いて、子ノード１０−１は、親ノード２０にデータ認証応答５（ＣＸ２，ＳＤ５)を送信する（ステップＳ１３５）。ここで、ＣＸ２は被認証データＤＸ２に対するメッセージ認証コード、ＳＤ５はステータスであるものとする。
【００７７】
続いて、親ノード２０は、アプリケーションサーバ３０にメッセージＸ２（ＤＸ２，ＣＸ２）を送信する（ステップＳ１３７）。
【００７８】
図１５は、本実施形態の子ノード１０−１で実行される処理の一例を示すフローチャートである。
【００７９】
まず、登録処理部１１は、親ノード２０に登録要求を送信する（ステップＳ２０１）。
【００８０】
続いて、登録処理部１１は、親ノード２０から登録応答を受信する（ステップＳ２０２）。
【００８１】
続いて、主処理部１３は、主処理を行う（ステップＳ２０３）。なお、主処理の詳細については、後述する。
【００８２】
続いて、登録処理部１１は、登録がタイムアウトし、親ノード２０に再登録が必要であるか否かを確認する（ステップＳ２０４）。そして、再登録が必要であれば（ステップＳ２０４でＹｅｓ）、ステップＳ２０１に戻り、再登録が必要でなければ（ステップＳ２０４でＮｏ）、処理は終了となる。
【００８３】
図１６は、本実施形態の主処理の一例を示すフローチャートである。
【００８４】
まず、主処理部１３は、親ノード２０からイベントを受信する（ステップＳ３０１）。
【００８５】
続いて、主処理部１３は、受信したイベントが登録タイムアウトを示すイベントであるか否か確認する（ステップＳ３０２）。登録タイムアウトを示すイベントである場合（ステップＳ３０２でＹｅｓ）、処理は終了となる。
【００８６】
登録タイムアウトを示すイベントでない場合（ステップＳ３０２でＮｏ）、主処理部１３は、受信したイベントがデータ認証要求か否か確認する（ステップＳ３０３）。
【００８７】
受信したイベントがデータ認証要求である場合（ステップＳ３０３でＹｅｓ）、主処理部１３は、データ認証要求から鍵仕様Ｓ、被認証データＤ、及びメッセージ認証アルゴリズム識別子を取得し、メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムＡを更に取得する（ステップＳ３０４）。
【００８８】
続いて、鍵生成部１５は、保持している鍵階層と鍵仕様Ｓとを用いて、鍵仕様Ｓに対応する鍵Ｋを生成する（ステップＳ３０５）。なお、主処理部１３は、鍵キャッシュ（Ｓ，Ｋ)を作成し、保持してもよい。なお、主処理部１３が鍵キャッシュ（Ｓ，Ｋ)を保持している場合、鍵生成部１５による鍵Ｋの生成を省略し、鍵キャッシュ（Ｓ，Ｋ)から鍵Ｋを取得してもよい。
【００８９】
続いて、主処理部１３は、鍵Ｋ及びメッセージ認証アルゴリズムＡを使用して、被認証データＤに対するメッセージ認証コードＣ’を生成する（ステップＳ３０６）。
【００９０】
続いて、主処理部１３は、メッセージ認証コードＣ’を含むデータ認証応答を親ノード２０に送信する（ステップＳ３０７）。そして、ステップ３０１へ戻る。
【００９１】
一方、受信したイベントがデータ認証要求でない場合（ステップＳ３０３でＮｏ）、主処理部１３は、受信したイベントが鍵要求か否か確認する（ステップＳ３０８）。鍵要求でなければ（ステップＳ３０８でＮｏ）、ステップ３０１へ戻る。
【００９２】
受信したイベントが鍵要求である場合（ステップＳ３０８でＹｅｓ）、主処理部１３は、鍵要求から鍵仕様Ｓを取得する（ステップＳ３０９）。
【００９３】
続いて、鍵生成部１５は、保持している鍵階層と鍵仕様Ｓとを用いて、鍵仕様Ｓに対応する鍵Ｋを生成する（ステップＳ３１０）。
【００９４】
続いて、主処理部１３は、鍵Ｋを含む鍵応答を親ノード２０に送信する（ステップＳ３１１）。そして、ステップＳ３０１へ戻る。
【００９５】
図１７は、本実施形態の親ノード２０で実行される処理の一例を示すフローチャートである。
【００９６】
まず、認証プロトコル処理部２３は、イベントを受信する（ステップＳ４０１）。
【００９７】
続いて、認証プロトコル処理部２３は、受信したイベントが登録要求か否か確認する（ステップＳ４０２）。
【００９８】
受信したイベントが登録要求である場合（ステップＳ４０２でＹｅｓ）、登録処理部２１は、登録要求を送信した子ノードを登録する（ステップＳ４０３）。そして、ステップＳ４０１へ戻る。
【００９９】
受信したイベントが登録要求でない場合（ステップＳ４０２でＮｏ）、登録処理部２１は、登録されている子ノードのうち登録がタイムアウトしている子ノードがあるか否かを確認する（ステップＳ４０４）。
【０１００】
登録がタイムアウトしている子ノードがある場合（ステップＳ４０４でＹｅｓ）、登録処理部２１は、当該子ノードの登録を抹消する（ステップＳ４０５）。そして、ステップＳ４０１へ戻る。
【０１０１】
登録がタイムアウトしている子ノードがない場合（ステップＳ４０４でＮｏ）、認証プロトコル処理部２３は、受信したイベントがアプリケーションサーバ３０からのメッセージ受信イベントであるか否か確認する（ステップＳ４０６）。
【０１０２】
受信したイベントがアプリケーションサーバ３０からのメッセージ受信イベントである場合（ステップＳ４０６でＹｅｓ）、認証プロトコル処理部２３は、親ノードメッセージ受信処理を行う（ステップＳ４０７）。なお、親ノードメッセージ受信処理の詳細については、後述する。そして、ステップＳ４０１へ戻る。
【０１０３】
受信したイベントがアプリケーションサーバ３０からのメッセージ受信イベントでない場合（ステップＳ４０６でＮｏ）、認証プロトコル処理部２３は、受信したイベントがアプリケーションサーバ３０へのメッセージ送信イベントであるか否か確認する（ステップＳ４０８）。
【０１０４】
受信したイベントがアプリケーションサーバ３０へのメッセージ送信イベントでない場合（ステップＳ４０８でＮｏ）、ステップＳ４０１へ戻る。
【０１０５】
受信したイベントがアプリケーションサーバ３０へのメッセージ送信イベントである場合（ステップＳ４０８でＹｅｓ）、認証プロトコル処理部２３は、親ノードメッセージ送信処理を行う（ステップＳ４０９）。なお、親ノードメッセージ送信処理の詳細については、後述する。そして、ステップＳ４０１へ戻る。
【０１０６】
図１８は、本実施形態の親ノードメッセージ受信処理の一例を示すフローチャートである。
【０１０７】
まず、認証プロトコル処理部２３は、アプリケーションサーバ３０からメッセージを受信すると、受信したメッセージの認証に用いる子ノードを決定し、プロトコル種別Ｔｐ、メッセージ種別Ｔｍ、被認証データＤ、メッセージ認証コードＣ、及びメッセージ認証アルゴリズム識別子を取得する（ステップＳ５０１）。
【０１０８】
続いて、認証プロトコル処理部２３は、メッセージ認証コード取得処理を行う（ステップＳ５０２）。なお、メッセージ認証コード取得処理の詳細については、後述する。
【０１０９】
続いて、認証プロトコル処理部２３は、ステップＳ５０２で取得したメッセージ認証コードＣ’がステップＳ５０１で取得したメッセージ認証コードＣと一致するか否か確認する（ステップＳ５０３）。
【０１１０】
両メッセージ認証コードが一致する場合（ステップＳ５０３でＹｅｓ）、認証プロトコル処理部２３は、受信したメッセージの復号化が必要か否か確認する（ステップＳ５０４）。受信したメッセージの復号化が必要でない場合（ステップＳ５０４でＮｏ）、ステップＳ５０７へ進む。
【０１１１】
受信したメッセージの復号化が必要な場合（ステップＳ５０４でＹｅｓ）、認証プロトコル処理部２３は、鍵取得処理を行う（ステップＳ５０５）。なお、鍵取得処理の詳細については、後述する。
【０１１２】
続いて、認証プロトコル処理部２３は、鍵取得処理で取得した鍵を用いて、受信したメッセージを復号化する（ステップＳ５０６）。
【０１１３】
続いて、認証プロトコル処理部２３は、その他のメッセージ受信処理を行い（ステップＳ５０７）、処理は終了となる。
【０１１４】
一方、ステップＳ５０３で両メッセージ認証コードが一致しない場合（ステップＳ５０３でＮｏ）、認証プロトコル処理部２３は、メッセージ認証失敗時のメッセージ受信処理を行い（ステップＳ５０８）、処理は終了となる。
【０１１５】
なお、図１８に示す例では、暗号化されたメッセージにメッセージ認証コードＣが含まれていないため、メッセージ認証を行った後にメッセージを復号化したが、暗号化されたメッセージにメッセージ認証コードＣが含まれている場合は、メッセージを復号化した後に、メッセージ認証を行うことになる。
【０１１６】
図１９は、本実施形態の親ノードメッセージ送信処理の一例を示すフローチャートである。
【０１１７】
まず、認証プロトコル処理部２３は、アプリケーションサーバ３０へのメッセージ送信イベントが発生すると、送信対象のメッセージの認証に用いる子ノードを決定し、プロトコル種別Ｔｐ、メッセージ種別Ｔｍ、被認証データＤ、及びメッセージ認証アルゴリズム識別子を取得する（ステップＳ６０１）。
【０１１８】
続いて、認証プロトコル処理部２３は、送信対象のメッセージの暗号化が必要か否か確認する（ステップＳ６０２）。送信対象のメッセージの暗号化が必要でない場合（ステップＳ６０２でＮｏ）、ステップＳ６０５へ進む。
【０１１９】
送信対象のメッセージの暗号化が必要な場合（ステップＳ６０２でＹｅｓ）、認証プロトコル処理部２３は、鍵取得処理を行う（ステップＳ６０３）。なお、鍵取得処理の詳細については、後述する。
【０１２０】
続いて、認証プロトコル処理部２３は、鍵取得処理で取得した鍵を用いて、受信したメッセージを暗号化する（ステップＳ６０４）。
【０１２１】
続いて、認証プロトコル処理部２３は、メッセージ認証コード取得処理を行う（ステップＳ６０５）。なお、メッセージ認証コード取得処理の詳細については、後述する。
【０１２２】
続いて、認証プロトコル処理部２３は、ステップＳ６０５で取得したメッセージ認証コードＣ’を暗号化したメッセージに付加してアプリケーションサーバ３０へ送信する（ステップＳ６０６）。
【０１２３】
図２０は、本実施形態のメッセージ認証コード取得処理の一例を示すフローチャートである。
【０１２４】
まず、認証プロトコル処理部２３は、メッセージの認証に用いる子ノードが登録されているか否か確認する（ステップＳ７０１）。メッセージの認証に用いる子ノードが登録されていなければ（ステップＳ７０１でＮｏ）、処理は終了となる。
【０１２５】
メッセージの認証に用いる子ノードが登録されている場合（ステップＳ７０１でＹｅｓ）、鍵仕様生成部２５は、プロトコル種別Ｔｐ及びメッセージ種別Ｔｍから鍵仕様Ｓを生成する（ステップＳ７０２）。
【０１２６】
続いて、認証プロトコル処理部２３は、鍵仕様Ｓ、被認証データＤ及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を、メッセージの認証に用いる子ノードに送信し（ステップＳ７０３）、当該子ノードからメッセージ認証コードＣ’を含むデータ認証応答を受信する（ステップＳ７０４）。
【０１２７】
続いて、認証プロトコル処理部２３は、データ認証応答からメッセージ認証コードＣ’を取得する（ステップＳ７０５）。
【０１２８】
図２１は、本実施形態の鍵取得処理の一例を示すフローチャートである。
【０１２９】
まず、鍵仕様生成部２５は、プロトコル種別Ｔｐ及びメッセージ種別Ｔｍから鍵仕様Ｓを生成する（ステップＳ８０１）。
【０１３０】
続いて、認証プロトコル処理部２３は、鍵仕様Ｓに対応する暗号鍵を保有しているか否か確認する（ステップＳ８０２）。
【０１３１】
鍵仕様Ｓに対応する暗号鍵を保有している場合（ステップＳ８０２でＹｅｓ）、認証プロトコル処理部２３は、保有している暗号鍵を有効化し（ステップＳ８０３）、処理は終了となる。
【０１３２】
鍵仕様Ｓに対応する暗号鍵を保有していない場合（ステップＳ８０２でＮｏ）、認証プロトコル処理部２３は、鍵仕様Ｓを含む鍵要求を、メッセージの認証に用いる子ノードに送信し（ステップＳ８０４）、当該子ノードから暗号鍵を含む鍵応答を受信する（ステップＳ８０５）。
【０１３３】
続いて、認証プロトコル処理部２３は、鍵応答から暗号鍵を取得する（ステップＳ８０６）。なお、認証プロトコル処理部２３は、取得した暗号鍵を鍵仕様Ｓと対応付けて保有してもよい。
【０１３４】
なお、上記実施形態の複数の子ノード１０−１〜１０−Ｎ及び親ノード２０は、例えば、ＣＰＵなどの制御装置と、ＲＯＭやＲＡＭなどの記憶装置と、ＨＤＤやＳＳＤなどの外部記憶装置と、通信Ｉ／Ｆなどの通信装置とを備えており、通常のコンピュータを利用したハードウェア構成で実現できる。
【０１３５】
この場合、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０で実行されるプログラムは、ＲＯＭ等に予め組み込んで提供される。
【０１３６】
また、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０で実行されるプログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、ＣＤ−Ｒ、メモリカード、ＤＶＤ、フレキシブルディスク（ＦＤ）等のコンピュータで読み取り可能な記憶媒体に記憶されて提供するようにしてもよい。
【０１３７】
また、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するようにしてもよい。また、複数の子ノード１０−１〜１０−Ｎ及び親ノード２０で実行されるプログラムを、インターネット等のネットワーク経由で提供または配布するようにしてもよい。
【０１３８】
複数の子ノード１０−１〜１０−Ｎ及び親ノード２０で実行されるプログラムは、上述した各部をコンピュータ上で実現させるためのモジュール構成となっている。実際のハードウェアとしては、例えば、ＣＰＵがＨＤＤからプログラムをＲＡＭ上に読み出して実行することにより、上記各部がコンピュータ上で実現されるようになっている。
【０１３９】
以上のように本実施形態の通信システムによれば、いずれの子ノードも認証プロトコルのステートを管理する必要がなく、少なくとも鍵仕様に基づく鍵の生成及び生成された鍵を用いたメッセージ認証コードの生成を行えばよいため、セキュリティを損なうことなく実装の軽装化が可能となる。
【０１４０】
また本実施形態の子ノードは、鍵階層のルート鍵を保持していればよく、その他の鍵はルート鍵と鍵仕様から必要な時に生成すればよいため、子ノードのメモリサイズを抑えることもできる。
【０１４１】
以上より、子ノードの数が増えるほど、通信システム全体として子ノードの軽装化によりハードウェアコストを抑えることができる。
【０１４２】
また本実施形態では、子ノードに対する相手認証のメッセージ認証以外のプロトコル処理を親ノードが代理で行うため、子ノードを軽装化してもＥＡＰやＰＡＮＡを用いた相手認証が可能となる。このため、不正な装置が親ノードを介してアプリケーションサーバと通信することを防止できる。
【０１４３】
また本実施形態では、親ノードは鍵階層を保持しないため、攻撃者により親ノードが乗っ取られた場合でも、鍵階層を守ることができる。
【０１４４】
また本実施形態では、被認証データの暗号鍵を子ノードが保持する鍵階層から生成するため、仮に攻撃者により親ノードが乗っ取られたとしても、被認証データの秘匿性及び完全性を維持でき、子ノード及びアプリケーションサーバへの影響を最小限に抑えることができる。
【０１４５】
また本実施形態の親ノードは、認証プロトコル固有の情報を子ノードに送信する必要がないため、子ノードとの間でやりとりするメッセージサイズ及びメッセージ数を削減することができる。
【０１４６】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせても良い。
【０１４７】
以上のように本実施形態によれば、軽装化及び相手認証を実現することができる。
【符号の説明】
【０１４８】
１ 通信システム
１０−１〜１０−Ｎ 子ノード
１１ 登録処理部
１３ 主処理部
１５ 鍵生成部
２０ 親ノード
２１ 登録処理部
２３ 認証プロトコル処理部
２５ 鍵仕様生成部
３０ アプリケーションサーバ
【特許請求の範囲】
【請求項１】
上位装置を介して外部装置と通信する通信装置であって、
前記上位装置から、被認証データ、第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を受信する主処理部と、
前記上位装置と前記外部装置との間で用いられる認証プロトコルが使用する鍵階層を保持し、当該鍵階層と前記第１鍵仕様とを用いて第１鍵を生成する鍵生成部と、
を備え、
前記主処理部は、前記メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムと前記第１鍵とを用いて前記被認証データに対するメッセージ認証コードを生成し、当該メッセージ認証コードを含むデータ認証応答を前記上位装置に送信することを特徴とする通信装置。
【請求項２】
前記主処理部は、過去に受信したデータ認証要求に含まれる第１鍵仕様と当該第１鍵仕様から生成される第１鍵とを含む鍵キャッシュを保持し、新たに受信したデータ認証要求に含まれる第１鍵仕様が前記鍵キャッシュに含まれる前記第１鍵仕様と一致する場合、前記鍵キャッシュに含まれる前記第１鍵と前記新たに受信したデータ認証要求に含まれるメッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムとを用いて、前記新たに受信したデータ認証要求に含まれる被認証データに対するメッセージ認証コードを生成することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記主処理部は、更に、前記上位装置から第２鍵仕様を含む鍵要求を受信し、
前記鍵生成部は、更に、前記鍵階層と前記第２鍵仕様とを用いて第２鍵を生成し、
前記主処理部は、更に、前記第２鍵を含む鍵応答を前記上位装置に送信することを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記鍵階層を使用する前記認証プロトコルの識別子のリスト及び自身の認証識別子を含む登録要求を前記上位装置に送信する登録処理部を更に備えることを特徴とする請求項１〜３のいずれか１つに記載の通信装置。
【請求項５】
下位装置と外部装置とを自身を介して通信させる通信装置であって、
自身と前記外部装置との間で用いられる認証プロトコルの処理のうちメッセージ認証コード生成以外の処理を行う認証プロトコル処理部と、
前記認証プロトコルが使用する鍵階層に属する第１鍵を前記下位装置に生成させるための第１鍵仕様を生成する鍵仕様生成部と、を備え、
前記認証プロトコル処理部は、被認証データ、前記第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を前記下位装置に送信し、前記被認証データに対するメッセージ認証コードを含むデータ認証応答を前記下位装置から受信することを特徴とする通信装置。
【請求項６】
前記鍵仕様生成部は、更に、前記鍵階層に属する第２鍵を前記下位装置に生成させるための第２鍵仕様を生成し、
前記認証プロトコル処理部は、更に、前記第２鍵仕様を含む鍵要求を前記下位装置に送信し、当該第２鍵仕様から生成される前記第２鍵を含む鍵応答を前記下位装置から受信することを特徴とする請求項５に記載の通信装置。
【請求項７】
前記鍵階層を使用する前記認証プロトコルの識別子のリスト及び前記下位装置の認証識別子を含む登録要求を前記下位装置から受信し、当該下位装置の登録期間の間、前記登録要求の内容と前記下位装置のアドレスとを対応付けて保持する登録処理部を更に備えることを特徴とする請求項５又は６に記載の通信装置。
【請求項８】
前記登録要求は、前記登録期間の値を更に含むことを特徴とする請求項７に記載の通信装置。
【請求項９】
前記外部装置は、アプリケーションサーバであり、
前記被認証データは、前記アプリケーションサーバとの間で交換されるアプリケーションデータであり、
前記第２鍵は、前記アプリケーションサーバとの間で共有され、
前記認証プロトコル処理部は、前記第２鍵を用いて、前記アプリケーションデータの暗号化又は復号化を行うことを特徴とする請求項６に記載の通信装置。
【請求項１０】
前記外部装置は、アプリケーションサーバであり、
前記被認証データは、前記アプリケーションサーバとの間で交換されるアプリケーションデータであり、
前記認証プロトコル処理部は、前記メッセージ認証コードを用いて、前記アプリケーションデータのメッセージ認証を行うことを特徴とする請求項５〜９のいずれか１つに記載の通信装置。
【請求項１１】
前記第１鍵仕様は、鍵種別、親鍵の鍵長、鍵導出関数識別子、ハッシュ関数識別子、鍵導出関数出力長、鍵導出関数出力中の鍵系列開始位置、鍵導出関数出力中の鍵系列終了位置、及び鍵ラベルを含む完全指定要素の順序リストである完全指定子により指定されることを特徴とする請求項１〜１０のいずれか１つに記載の通信装置。
【請求項１２】
前記第１鍵仕様は、鍵種別、親鍵の鍵長、鍵導出関数識別子、ハッシュ関数識別子、鍵導出関数出力長、鍵導出関数出力中の鍵系列開始位置、鍵導出関数出力中の鍵系列終了位置、及び鍵ラベルを含む完全指定要素の順序リストである完全指定子、又は当該完全指定子に対応する整数値である参照指定子により指定され、前記完全指定子による指定か前記参照指定子による指定かを識別する指定子種別を含むことを特徴とする請求項１〜１０のいずれか１つに記載の通信装置。
【請求項１３】
前記参照指定子の値は、前記データ認証応答の送信元により割当てられ、前記データ認証応答により通知されることを特徴とする請求項１２に記載の通信装置。
【請求項１４】
前記認証プロトコルは、ＰＡＮＡ（Protocol for carrying Authentication for Network Access）及びＥＡＰ（Extensible Authentication Protocol）認証メソッドを含むことを特徴とする請求項１〜１３のいずれか１つに記載の通信装置。
【請求項１５】
前記データ認証要求又は前記データ認証応答は、暗号化又はメッセージ認証が施されることを特徴とする請求項１〜１４のいずれか１つに記載の通信装置。
【請求項１６】
上位装置を介して外部装置と通信する通信装置で実行されるプログラムであって、
前記上位装置から、被認証データ、鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を受信する受信ステップと、
前記上位装置と前記外部装置との間で用いられる認証プロトコルが使用する鍵階層と前記鍵仕様とを用いて鍵を生成する鍵生成ステップと、
前記メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムと前記鍵とを用いて前記被認証データに対するメッセージ認証コードを生成し、当該メッセージ認証コードを含むデータ認証応答を前記上位装置に送信する送信ステップと、
を含むことを特徴とするプログラム。
【請求項１７】
下位装置と外部装置とを自身を介して通信させる通信装置で実行されるプログラムであって、
前記通信装置と前記外部装置との間で用いられる認証プロトコルの処理のうちメッセージ認証コード生成以外の処理を行う認証プロトコル処理ステップと、
前記認証プロトコルが使用する鍵階層に属する鍵を前記下位装置に生成させるための鍵仕様を生成する鍵仕様生成ステップと、
被認証データ、前記鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を前記下位装置に送信し、前記被認証データに対するメッセージ認証コードを含むデータ認証応答を前記下位装置から受信するメッセージ認証コード受信ステップと、
を含むことを特徴とするプログラム。
【請求項１】
上位装置を介して外部装置と通信する通信装置であって、
前記上位装置から、被認証データ、第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を受信する主処理部と、
前記上位装置と前記外部装置との間で用いられる認証プロトコルが使用する鍵階層を保持し、当該鍵階層と前記第１鍵仕様とを用いて第１鍵を生成する鍵生成部と、
を備え、
前記主処理部は、前記メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムと前記第１鍵とを用いて前記被認証データに対するメッセージ認証コードを生成し、当該メッセージ認証コードを含むデータ認証応答を前記上位装置に送信することを特徴とする通信装置。
【請求項２】
前記主処理部は、過去に受信したデータ認証要求に含まれる第１鍵仕様と当該第１鍵仕様から生成される第１鍵とを含む鍵キャッシュを保持し、新たに受信したデータ認証要求に含まれる第１鍵仕様が前記鍵キャッシュに含まれる前記第１鍵仕様と一致する場合、前記鍵キャッシュに含まれる前記第１鍵と前記新たに受信したデータ認証要求に含まれるメッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムとを用いて、前記新たに受信したデータ認証要求に含まれる被認証データに対するメッセージ認証コードを生成することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記主処理部は、更に、前記上位装置から第２鍵仕様を含む鍵要求を受信し、
前記鍵生成部は、更に、前記鍵階層と前記第２鍵仕様とを用いて第２鍵を生成し、
前記主処理部は、更に、前記第２鍵を含む鍵応答を前記上位装置に送信することを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記鍵階層を使用する前記認証プロトコルの識別子のリスト及び自身の認証識別子を含む登録要求を前記上位装置に送信する登録処理部を更に備えることを特徴とする請求項１〜３のいずれか１つに記載の通信装置。
【請求項５】
下位装置と外部装置とを自身を介して通信させる通信装置であって、
自身と前記外部装置との間で用いられる認証プロトコルの処理のうちメッセージ認証コード生成以外の処理を行う認証プロトコル処理部と、
前記認証プロトコルが使用する鍵階層に属する第１鍵を前記下位装置に生成させるための第１鍵仕様を生成する鍵仕様生成部と、を備え、
前記認証プロトコル処理部は、被認証データ、前記第１鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を前記下位装置に送信し、前記被認証データに対するメッセージ認証コードを含むデータ認証応答を前記下位装置から受信することを特徴とする通信装置。
【請求項６】
前記鍵仕様生成部は、更に、前記鍵階層に属する第２鍵を前記下位装置に生成させるための第２鍵仕様を生成し、
前記認証プロトコル処理部は、更に、前記第２鍵仕様を含む鍵要求を前記下位装置に送信し、当該第２鍵仕様から生成される前記第２鍵を含む鍵応答を前記下位装置から受信することを特徴とする請求項５に記載の通信装置。
【請求項７】
前記鍵階層を使用する前記認証プロトコルの識別子のリスト及び前記下位装置の認証識別子を含む登録要求を前記下位装置から受信し、当該下位装置の登録期間の間、前記登録要求の内容と前記下位装置のアドレスとを対応付けて保持する登録処理部を更に備えることを特徴とする請求項５又は６に記載の通信装置。
【請求項８】
前記登録要求は、前記登録期間の値を更に含むことを特徴とする請求項７に記載の通信装置。
【請求項９】
前記外部装置は、アプリケーションサーバであり、
前記被認証データは、前記アプリケーションサーバとの間で交換されるアプリケーションデータであり、
前記第２鍵は、前記アプリケーションサーバとの間で共有され、
前記認証プロトコル処理部は、前記第２鍵を用いて、前記アプリケーションデータの暗号化又は復号化を行うことを特徴とする請求項６に記載の通信装置。
【請求項１０】
前記外部装置は、アプリケーションサーバであり、
前記被認証データは、前記アプリケーションサーバとの間で交換されるアプリケーションデータであり、
前記認証プロトコル処理部は、前記メッセージ認証コードを用いて、前記アプリケーションデータのメッセージ認証を行うことを特徴とする請求項５〜９のいずれか１つに記載の通信装置。
【請求項１１】
前記第１鍵仕様は、鍵種別、親鍵の鍵長、鍵導出関数識別子、ハッシュ関数識別子、鍵導出関数出力長、鍵導出関数出力中の鍵系列開始位置、鍵導出関数出力中の鍵系列終了位置、及び鍵ラベルを含む完全指定要素の順序リストである完全指定子により指定されることを特徴とする請求項１〜１０のいずれか１つに記載の通信装置。
【請求項１２】
前記第１鍵仕様は、鍵種別、親鍵の鍵長、鍵導出関数識別子、ハッシュ関数識別子、鍵導出関数出力長、鍵導出関数出力中の鍵系列開始位置、鍵導出関数出力中の鍵系列終了位置、及び鍵ラベルを含む完全指定要素の順序リストである完全指定子、又は当該完全指定子に対応する整数値である参照指定子により指定され、前記完全指定子による指定か前記参照指定子による指定かを識別する指定子種別を含むことを特徴とする請求項１〜１０のいずれか１つに記載の通信装置。
【請求項１３】
前記参照指定子の値は、前記データ認証応答の送信元により割当てられ、前記データ認証応答により通知されることを特徴とする請求項１２に記載の通信装置。
【請求項１４】
前記認証プロトコルは、ＰＡＮＡ（Protocol for carrying Authentication for Network Access）及びＥＡＰ（Extensible Authentication Protocol）認証メソッドを含むことを特徴とする請求項１〜１３のいずれか１つに記載の通信装置。
【請求項１５】
前記データ認証要求又は前記データ認証応答は、暗号化又はメッセージ認証が施されることを特徴とする請求項１〜１４のいずれか１つに記載の通信装置。
【請求項１６】
上位装置を介して外部装置と通信する通信装置で実行されるプログラムであって、
前記上位装置から、被認証データ、鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を受信する受信ステップと、
前記上位装置と前記外部装置との間で用いられる認証プロトコルが使用する鍵階層と前記鍵仕様とを用いて鍵を生成する鍵生成ステップと、
前記メッセージ認証アルゴリズム識別子で識別されるメッセージ認証アルゴリズムと前記鍵とを用いて前記被認証データに対するメッセージ認証コードを生成し、当該メッセージ認証コードを含むデータ認証応答を前記上位装置に送信する送信ステップと、
を含むことを特徴とするプログラム。
【請求項１７】
下位装置と外部装置とを自身を介して通信させる通信装置で実行されるプログラムであって、
前記通信装置と前記外部装置との間で用いられる認証プロトコルの処理のうちメッセージ認証コード生成以外の処理を行う認証プロトコル処理ステップと、
前記認証プロトコルが使用する鍵階層に属する鍵を前記下位装置に生成させるための鍵仕様を生成する鍵仕様生成ステップと、
被認証データ、前記鍵仕様、及びメッセージ認証アルゴリズム識別子を含むデータ認証要求を前記下位装置に送信し、前記被認証データに対するメッセージ認証コードを含むデータ認証応答を前記下位装置から受信するメッセージ認証コード受信ステップと、
を含むことを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１３−６２７６４（Ｐ２０１３−６２７６４Ａ）
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願番号】特願２０１１−２０１６０２（Ｐ２０１１−２０１６０２）
【出願日】平成２３年９月１５日（２０１１．９．１５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
２．ＺＩＧＢＥＥ
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願日】平成２３年９月１５日（２０１１．９．１５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
２．ＺＩＧＢＥＥ
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]