(57)【要約】【課題】処理負荷を削減することを課題とする。【解決手段】通信制御装置は、生成部と、制御部とを有する。生成部は、ＧＫＢ（Group  Key  Block）を使用したシステムにおいて、自装置のデジタル署名を含む操作コマンドを用いて、２つの通信装置で構成される個別通信用グループに対応するグループ鍵を生成する。制御部は、生成されたグループ鍵による認証コードが付与されたグループ操作コマンド用メッセージを用いて、通信装置とのグループ操作を制御する。【選択図】図１
2016063233.tif 000002
【特許請求の範囲】
【請求項１】
ＧＫＢ（Group  Key  Block）を使用したシステムにおいて、
自装置のデジタル署名を含む操作コマンドを用いて、２つの通信装置で構成される個別通信用グループに対応するグループ鍵を生成する生成部と、
生成された前記グループ鍵による認証コードが付与されたグループ操作コマンド用メッセージを用いて、前記通信装置とのグループ操作を制御する制御部と
を有する通信制御装置。
【請求項２】
前記個別通信用グループであるか否かを判定する判定部をさらに有し、
前記生成部は、前記個別通信用グループであると判定された場合に、前記グループ鍵を生成する請求項１に記載の通信制御装置。
【請求項３】
前記判定部は、前記ＧＫＢにおいて、それぞれを識別するインデックスが割り当てられた前記通信装置を管理するためのＣＳ（Complete  Subtree）を２つ含み、且つ、該２つの前記ＣＳが管理木の葉ノードを表す場合に、前記個別通信用グループであると判定する請求項２に記載の通信制御装置。
【請求項４】
前記判定部は、各グループを識別するグループ識別子が前記個別通信用グループを表す場合に、前記個別通信用グループであると判定する請求項２又は３に記載の通信制御装置。
【請求項５】
前記制御部は、前記グループ操作コマンド用メッセージとは異なる所定メッセージを用いる場合に、前記グループ鍵による認証コードを付与する請求項１に記載の通信制御装置。
【請求項６】
単調増加する同期カウンタの同期カウンタ値を更新する更新部をさらに有し、
前記制御部は、前記同期カウンタ値を含む前記グループ操作コマンド用メッセージを用いて、前記グループ操作を制御する請求項１〜５の何れか一つに記載の通信制御装置。
【請求項７】
前記更新部は、前記通信装置からの同期カウンタ更新要求を受け付けた場合、又は、自装置において同期カウンタを喪失した場合に、前記同期カウンタ値を更新する請求項６に記載の通信制御装置。
【請求項８】
自装置のデジタル署名を含む同期カウンタ更新通知を用いて、単調増加する同期カウンタをグループメンバに通知するための通信部と、
前記同期カウンタの同期カウンタ値を更新する更新部と
を有する通信制御装置。
【請求項９】
前記通信部は、少なくとも前記同期カウンタとメッセージ送信毎に１つずつインクリメントされるパケットカウンタをシーケンス番号に含むグループ宛てメッセージの送受信を行なう請求項８に記載の通信制御装置。
【請求項１０】
２つの通信装置で構成される個別通信用グループに対応するグループ鍵を生成する生成部と、
生成された前記グループ鍵による認証コードと、更新された前記同期カウンタ値とを含むグループ操作コマンド用メッセージを用いて、前記通信装置とのグループ操作を制御する制御部と
をさらに有する請求項８又は９に記載の通信制御装置。
【請求項１１】
前記更新部は、前記通信装置からの同期カウンタ更新要求を受け付けた場合、又は、自装置において同期カウンタを喪失した場合に、前記同期カウンタ値を更新する請求項８〜１０の何れか一つに記載の通信制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信制御装置に関する。
【背景技術】
【０００２】
ＩＥＥＥ８０２．２１ｄ／Ｄ０５では、グループマネージャ（GM：Group  Manager）から送信されるグループ操作コマンド用メッセージにおいて、デジタル署名による送信元認証が行われている。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】ＩＥＥＥ８０２．２１ｄ／Ｄ０５
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ＩＥＥＥ８０２．２１ｄ／Ｄ０５において、グループ操作コマンド用メッセージは、複数のメンバーに送信されるため、グループ共通鍵によるメッセージ認証を送信元認証に使用することが困難である。すなわち、ＩＥＥＥ８０２．２１ｄ／Ｄ０５では、グループ操作のたびにデジタル署名の生成や検証が行なわれるため、処理負荷が増大する。
【０００５】
本発明が解決しようとする課題は、処理負荷を削減することができる通信制御装置を提供することである。
【課題を解決するための手段】
【０００６】
実施の形態の通信制御装置は、ＧＫＢ（Group  Key  Block）を使用したシステムにおいて、自装置のデジタル署名を含む操作コマンドを用いて、２つの通信装置で構成される個別通信用グループに対応するグループ鍵を生成する生成部と、生成された前記グループ鍵による認証コードが付与されたグループ操作コマンド用メッセージを用いて、前記通信装置とのグループ操作を制御する制御部とを有する。
【図面の簡単な説明】
【０００７】
【図１】第１の実施形態に係る通信システムの構成を示すブロック図。
【図２】第１の実施形態に係るコントローラと機器との接続関係を示す図。
【図３】第１の実施形態に係るノード種別の対応を示す図。
【図４】第１の実施形態に係る各装置のハードウェア構成を示すブロック図。
【図５】第１の実施形態に係るコーディネータの機能構成を示すブロック図。
【図６】第１の実施形態に係るグループ管理木とＬｅａｆＩＤとを示す図。
【図７】第１の実施形態に係るグループ割り当て規則を示す図。
【図８】第１の実施形態に係る通信手順を示す全体シーケンス。
【図９】第１の実施形態に係る認証シーケンス。
【図１０】第１の実施形態に係る鍵共有シーケンス。
【図１１】第１の実施形態に係るグループ通信セキュリティポリシーのデフォルト値を示す図。
【図１２】第１の実施形態に係る参加ノードをトリガとしてシーケンス番号の再同期を行なう図。
【図１３】第１の実施形態に係るコーディネータをトリガとしてシーケンス番号の再同期を行なう図。
【図１４】第１の実施形態に係るＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。
【図１５】第１の実施形態に係るＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。
【図１６】第１の実施形態に係るＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。
【図１７】第１の実施形態に係るＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。
【図１８】第１の実施形態に係るＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。
【図１９】第１の実施形態に係るＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。
【図２０】第１の実施形態に係るＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅ  ｉｎｄｉｃａｔｉｏｎメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。
【図２１】第１の実施形態に係るＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。
【図２２】第１の実施形態に係るＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。
【図２３】第１の実施形態に係る鍵共有フェーズ１Ａの詳細シーケンス。
【図２４】第１の実施形態に係る鍵共有フェーズ１Ｂの詳細シーケンス。
【図２５】第１の実施形態に係る鍵共有フェーズ２の詳細シーケンス。
【図２６】第１の実施形態に係る鍵共有フェーズ２の詳細シーケンス。
【図２７】第１の実施形態に係る暗号通信の詳細シーケンス。
【図２８】第１の実施形態に係る証明書リボークの詳細シーケンス。
【図２９】第１の実施形態に係るグループ鍵更新の詳細シーケンス。
【発明を実施するための形態】
【０００８】
（第１の実施形態）
［システムアーキテクチャ］
図１は、第１の実施形態に係る通信システムの構成例を示すブロック図である。本実施形態では、ＥＣＨＯＮＥＴ  Ｌｉｔｅノードのセキュリティ機能を例に挙げて説明する。ＥＣＨＯＮＥＴ  Ｌｉｔｅノードは、セキュリティ機能として、ＩＥＥＥ８０２．２１ｄ及びＲＦＣ５１９１で規定されるＰＡＮＡ（Protocol  for  carrying  Authentication  for  Network  Access）をサポートする。
【０００９】
図１に示すように、通信システム１０は、コーディネータ２０と、コントローラ３０と、機器４０とを有する。これらのうち、コーディネータ２０は、通信装置の一例であるコントローラ３０や機器４０の制御を行なう通信制御装置であり、１つのＥＣＨＯＮＥＴ  Ｌｉｔｅドメイン（以下、単に「ドメイン」と呼ぶ場合がある）内に１つ存在する。例えば、ドメインは、１つのＨＡＮ（Home  Area  Network）である。コントローラ３０は、１つのドメイン内に少なくとも１つ存在する。すなわち、コントローラ３０はＭ個（Ｍ≧１）存在する。機器４０は、１つのドメイン内に少なくとも１つ存在する。すなわち、機器４０はＮ個（Ｎ≧１）存在する。図２は、第１の実施形態に係るコントローラ３０と機器４０との接続関係の例を示す図である。図２に示すように、コントローラ３０と機器４０とは、１つのドメイン内に少なくとも１つ存在する。また、機器４０は、コントローラ３０によって形成されるグループ（アプリケーションシステムグループ）に属する。ここで、機器４０は、複数のアプリケーションシステムグループに属する場合も有り得る。
【００１０】
コーディネータ２０と各コントローラ３０との間では、「相互認証」及び「鍵共有」の手順が実施される。同様に、コーディネータ２０と各機器４０との間では、「相互認証」及び「鍵共有」の手順が実施される。また、コントローラ３０と機器４０との間では、「暗号通信」が行なわれる。暗号通信で使用される暗号鍵は、鍵共有の手順において、コーディネータ２０から各コントローラ３０及び各機器４０に配布される。なお、暗号通信は、コントローラ３０間や機器４０間で行われても良い。相互認証、鍵共有及び暗号通信の詳細な手順については後述する。
【００１１】
図３は、第１の実施形態に係るノード種別の対応例を示す図である。図３では、ＥＣＨＯＮＥＴ  Ｌｉｔｅノード種別と、ＰＡＮＡノード種別と、ＩＥＥＥ８０２．２１ｄノード種別との対応付けを例に挙げている。コーディネータ２０は、グループ管理及びセキュリティ管理の主体となるノードであり、ＥＣＨＯＮＥＴ  Ｌｉｔｅの管理や操作関連機器グループの新規クラスとして定義される。コントローラ３０及び機器４０は、ＥＣＨＯＮＥＴ  Ｌｉｔｅの管理や操作関連機器グループの既存クラスである。コーディネータ２０は、ＰＡＮＡのＰＡＡ（PANA  Authentication  Agent）及びＩＥＥＥ８０２．２１ｄのＰｏＳ（Point  of  Service）  ｗｉｔｈ  ＧＭ（Group  Manager）の機能を有する。コントローラ３０及び機器４０は、ＰＡＮＡのＰａＣ（PANA  Client）及びＩＥＥＥ８０２．２１ｄのＰｏＳの機能を有する。なお、コーディネータ２０は、ＥＣＨＯＮＥＴ  Ｌｉｔｅノード機器でない場合もある。このとき、本実施形態に係る通信システムは、ＥＣＨＯＮＥＴ  Ｌｉｔｅ以外のシステムにも適用可能である。
【００１２】
図４は、第１の実施形態に係る各装置のハードウェア構成例を示すブロック図である。ここでは、コーディネータ２０を例に挙げて説明する。図４に示すように、コーディネータ２０は、ＣＰＵ（Central  Processing  Unit）２２と、ＲＡＭ（Random  Access  Memory）２３と、ＲＯＭ（Read  Only  Memory）２４と、通信Ｉ／Ｆ２５とを有する。上記各ハードウェアは、バス２１によって接続されている。ＣＰＵ２２は、コーディネータ２０の動作を統括的に制御する。ＣＰＵ２２は、ＲＡＭ２３をワークエリア（作業領域）として、ＲＯＭ２４等に格納されたプログラムを実行することで、コーディネータ２０全体の動作を制御する。通信Ｉ／Ｆ２５は、外部装置（例えば、コントローラ３０や機器４０等）と通信するためのインタフェースである。
【００１３】
図５は、第１の実施形態に係るコーディネータ２０の機能構成例を示すブロック図である。図５に示すように、コーディネータ２０は、通信部２１０と、判定部２２０と、生成部２３０と、更新部２４０と、制御部２５０とを有する。通信部２１０は、コントローラ３０や機器４０との各種通信を制御する。また、通信部２１０は、更新された同期カウンタを更新通知として通知する。判定部２２０は、個別通信用グループであるか否かを判定する。生成部２３０は、個別通信用グループであると判定された場合に、コーディネータ２０のデジタル署名を含む操作コマンドを用いて、個別通信用グループに対応するグループ鍵を生成する。更新部２４０は、同期カウンタの同期カウンタ値を更新する。制御部２５０は、生成されたグループ鍵による認証コードと、更新された同期カウンタ値とを含むグループ操作コマンド用メッセージを用いて、コントローラ３０や機器４０とのグループ操作を制御する。なお、上記各部は、これらの一部又は全てがソフトウェア（プログラム）で実現されても良いし、ハードウェア回路で実現されても良い。また、上記各部により、後述する各種処理が実行される。
【００１４】
［グループ管理］
ＥＣＨＯＮＥＴ  Ｌｉｔｅセキュリティでは、ＨＡＮグループ、個別通信用グループ、アプリケーションシステムグループ、及びコントローラグループの４種類のグループを扱うことができる。これらのうち、ＨＡＮグループ（グループ数＝１）は、ドメイン内の全てのＥＣＨＯＮＥＴ  Ｌｉｔｅノード間の暗号通信に使用可能である。また、ＨＡＮグループでは、１つのグループ暗号鍵「Ｋ１」がドメイン内の全てのＥＣＨＯＮＥＴ  Ｌｉｔｅノードで共有される。
【００１５】
個別通信用グループは、ある特定の２つのＥＣＨＯＮＥＴ  Ｌｉｔｅノード間での暗号通信に使用可能である。ある特定の２つのＥＣＨＯＮＥＴ  Ｌｉｔｅノードの識別子をｘ，ｙとすると、グループ暗号鍵Ｋ＿ｘｙ又はグループ暗号鍵Ｋ＿ｙｘ（本実施形態では、Ｋ＿ｘｙ＝Ｋ＿ｙｘとする）が、ノードｘ、ノードｙ間で共有される。
【００１６】
アプリケーションシステムグループ（グループ数＝Ｍ）は、ある特定のコントローラ３０に接続するＥＣＨＯＮＥＴ  Ｌｉｔｅノード（コントローラ３０を含む）間での暗号通信に使用可能である。コントローラ３０の識別子をｃｔｌとすると、グループ暗号鍵Ｋ＿ｃｔｌが、コントローラｃｔｌに接続するＥＣＨＯＮＥＴ  Ｌｉｔｅノードで共有される。
【００１７】
コントローラグループ（グループ数＝１）は、ドメイン内の全てのコントローラ３０間の暗号通信に使用可能である。また、コントローラグループでは、１つのグループ暗号鍵Ｋ２がドメイン内の全てのコントローラ３０で共有される。
【００１８】
上記４種類全てのグループによるグループ通信において、ＩＥＥＥ８０２．２１ｄによる暗号通信を行なうものとする。以下、‘＋’は文字列の連結を表す演算子、ＴｙｐｅはＬｅａｆＩＤ、ＥＵＩ６４アドレス又はショートアドレスの何れのタイプかを識別する文字、‘Ｌ’（ＬｅａｆＩＤ）、‘Ｅ’（ＥＵＩ６４アドレス）、‘Ｓ’（ＩＥＥＥ８０２．１５．４ショートアドレス）の何れかである。ＩＤｘ、ＩＤｙは個別通信用グループに属する２つのＥＣＨＯＮＥＴ  Ｌｉｔｅノードの識別子（ＬｅａｆＩＤ、ＥＵＩ６４アドレス、ＩＥＥＥ８０２．１５．４ショートアドレスの何れか）、ＩＤｃｔｌはアプリケーションシステムにおけるコントローラ３０の識別子（ＬｅａｆＩＤ、ＥＵＩ６４アドレス、ＩＥＥＥ８０２．１５．４ショートアドレスの何れか）である。
【００１９】
このとき、パケットに付与されるＩＥＥＥ８０２．２１ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒとして、ＬｅａｆＩＤ、ＥＵＩ６４アドレス又はＩＥＥＥ８０２．１５．４ショートアドレスが使用されるかもしれない。例えば、パケットに付与されるＩＥＥＥ８０２．２１ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、“Ｌ１０”、“Ｅ００１１２２３３ＡＡＢＢＣＣＤＤ”、“Ｓ００１１”等である。ＬｅａｆＩＤは、ＩＥＥＥ８０２．２１ｄのグループ管理木における葉ノードの識別子であり、ＩＥＥＥ８０２．２１ｄノードの識別子として使用可能である。なお、グループ管理木における葉ノードの識別子は、インデックスの一例である。例えば、インデックスは、ＭＡＣアドレス等の識別子を表す。
【００２０】
ＬｅａｆＩＤ長は、グループ管理木サイズに依存する。葉ノード数が２５６であるグループ管理木の場合、ＢＡＳＥ１６エンコーディング時のＬｅａｆＩＤ長は２バイトとなる。また、ＢＡＳＥ１６エンコーディング時のＥＵＩ６４アドレス長は１６バイト、ＢＡＳＥ１６エンコーディング時のＩＥＥＥ８０２．１５．４ショートアドレス長は４バイトとなる。以下、ＬｅａｆＩＤ、ＥＵＩ６４アドレス、ＩＥＥＥ８０２．１５．４ショートアドレスの符号化には、ＢＡＳＥ１６エンコーディングを使用するものとする。
【００２１】
図６は、第１の実施形態に係るグループ管理木とＬｅａｆＩＤとの例を示す図である。図６において、ＬｅａｆＩＤは、２進数表現で表されている。グループ管理木において、葉ノードと各通信ノードとは、１対１に対応している。また、グループ管理木の各ノードには、固有の１２８ビットの暗号鍵が対応している。ここで、ある通信ノードについて、根ノードから葉ノードに至るパス上に存在する各ノードに対応する暗号鍵のリストを、該当の通信ノードに対するデバイス鍵と呼ぶ。例えば、根ノードから葉ノードに至るパス上に存在する各ノードについて、Ｎ０に対しては、ノード０、ノード００、ノード０００、ノード００００となる。ある通信ノードのデバイス鍵は、該通信ノードとＧＭとの間で共有される。例えば、通信ノードＮ０、Ｎ１、Ｎ２、Ｎ３をグループメンバとすると、鍵暗号化に使用されるノード鍵は、ノード００のノード鍵となる。また、通信ノードＮ１、Ｎ２、Ｎ３、Ｎ４、Ｎ６、Ｎ７をグループメンバとすると、鍵暗号化に使用されるノード鍵は、ノード００、ノード０１００、ノード０１１のノード鍵となる。
【００２２】
グループ通信において、パケットに付与されるＩＥＥＥ８０２．２１ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒとして、ＩＥＥＥ８０２．２１ｄで規定されるＭＩＨＦ  ＧｒｏｕｐＩＤを使用する。ＭＩＨＦ  ＧｒｏｕｐＩＤの値は、グループによって異なる。図７は、第１の実施形態に係るグループ割り当て規則の例を示す図である。ＨＡＮグループに対しては、ＭＩＨＦ  ＧｒｏｕｐＩＤとしてＭＩＨＦ  ＢｒｏａｄｃａｓｔＩＤ（＝“”）を使用する。個別通信用グループに対しては、ＭＩＨＦ  ＧｒｏｕｐＩＤとして、Ｔｙｐｅ＋ＩＤｘ＋‘＠’＋ＩＤｙを使用する。例えば、個別通信用グループのＭＩＨＦ  ＧｒｏｕｐＩＤは、“Ｌ１０＠２０”、“Ｅ００１１２２３３ＡＡＢＢＣＣＤＤ＠００１１２２３３ＢＢＣＣＤＤＥＥＦＦ”、“Ｓ００１１＠ＡＡＢＢ”等となる。
【００２３】
アプリケーションシステムグループに対しては、ＭＩＨＦ  ＧｒｏｕｐＩＤとして、Ｔｙｐｅ＋‘＠’＋ＩＤｃｔｌを使用する。例えば、アプリケーションシステムグループのＭＩＨＦ  ＧｒｏｕｐＩＤは、“Ｌ＠２０”、“Ｅ＠００１１２２３３ＢＢＣＣＤＤＥＥＦＦ”、“Ｓ＠ＡＡＢＢ”等となる。コントローラグループに対しては、ＭＩＨＦ  ＧｒｏｕｐＩＤとして、“Ｃｏｎｔｒｏｌｌｅｒｓ”を使用する。以下では、ＭＩＨＦ  ＩＤ及びＭＩＨＦ  Ｂｒｏａｄｃａｓｔ以外のＭＩＨＦ  ＧｒｏｕｐＩＤを、“ＩＤ（Ｔｙｐｅ）”と表記する場合がある。例えば、ＭＩＨＦ  ＧｒｏｕｐＩＤ“Ｌ１０＠２０”については、１０＠２０（Ｌ）と表記する。
【００２４】
［通信手順］
図８は、第１の実施形態に係る通信手順の例を示す全体シーケンスである。図８に示すように、コーディネータ２０とコントローラ３０との間で、「１．機器登録」、「２．認証・鍵共有」が実施され、コントローラ３０と機器４０との間で「３．暗号通信」が実施される。同様に、コーディネータ２０と機器４０との間で、「１．機器登録」、「２．認証・鍵共有」が実施され、コントローラ３０と機器４０との間で「３．暗号通信」が実施される。なお、「１．機器登録」と「２．認証・鍵共有」において、コントローラ３０と機器４０とは、任意の順序で起動可能である。以下では、コントローラ３０と機器４０とを、「参加ノード」と呼ぶ場合がある。
【００２５】
まず、参加ノードとコーディネータ２０との間で機器登録が行なわれる。参加ノードは、ＵＰｎＰ又はＥＣＨＯＮＥＴ  Ｌｉｔｅ（何れもセキュリティなし）等を使用してコーディネータ２０を発見する。コーディネータ２０は、ＵＰｎＰ又はＥＣＨＯＮＥＴ  Ｌｉｔｅ等のブロードキャストを受信した場合に、送信元を登録する。なお、登録内容の確定は、後述する認証・鍵共有の成功時に行なわれても良い。このとき、認証・鍵共有に失敗した場合には、登録内容を破棄する。
【００２６】
次に、参加ノードとコーディネータ２０との間で認証及び鍵共有を行なう。参加ノードとコーディネータ２０との間の認証時には、相互認証のために証明書の交換が行なわれる。認証に成功した場合、コーディネータ２０は、鍵共有に使用される８０２．２１ｄデバイス鍵を暗号化して参加ノードに配布する。なお、リブート時の処理負荷を軽減するために、参加ノードは、認証及び鍵共有時に、コーディネータ２０から配布された情報を不揮発性メモリに保持するものとする。
【００２７】
参加ノードとコーディネータ２０との間の鍵共有は、コーディネータ２０から参加ノードに対してグループ鍵を配布することにより行なわれる。グループ鍵は、参加ノードの要求なしで配布される場合（プッシュ）と、参加ノードからの要求により配布される場合（プル）とがある。また、コーディネータ２０は、参加ノードに対し、別の参加ノードに関する証明書を配布するかもしれない。
【００２８】
その後、参加ノードの間で暗号通信が行なわれる。コントローラ３０と機器４０との間の暗号通信に加えて、コントローラ３０間、機器４０間においても暗号通信が行なわれても良い。暗号通信に使用されるメッセージには、暗号化されたＥＣＨＯＮＥＴ  Ｌｉｔｅ電文が含まれ、送信元ノードによるデジタル署名を付与することができる。本実施形態では、例えば、メッセージ送信にマルチキャストが使用される場合、ドメインの範囲があるＩＰリンクの範囲と一致する場合には、マルチキャストアドレスとして、Ａｌｌ  Ｎｏｄｅｓリンクローカルアドレス（ＦＦ０２：０：０：０：０：０：０：１）を使用する。
【００２９】
図９は、第１の実施形態に係る認証シーケンスの例である。認証時には、ＰＡＮＡの上で証明書を使用したＲＦＣ５２１６で規定されるＥＡＰ−ＴＬＳによる相互認証を実施するものとする。このとき、Ｘ．５０９証明書の交換と、ＥＣＤＨ（楕円Diffie‐Hellman）鍵交換とが行なわれ、相互認証とセッション鍵とが確立される。コーディネータ２０から参加ノードには、認証局（CA：Certificate  Authority）のＸ．５０９証明書も配布されるかもしれない。認証に成功すると、コーディネータ２０から参加ノードに、少なくとも参加ノードの８０２．２１ｄデバイス鍵、コーディネータ２０の８０２．２１ｄＬｅａｆＩＤ、及び、参加ノードの８０２．２１ｄＬｅａｆＩＤが配布される。参加ノードの８０２．２１ｄデバイス鍵は、暗号化して配布する必要がある。このときの暗号化は、ＲＦＣ６７８６で規定される暗号化機能が使用される。なお、確立されたＰＡＮＡセッションは、直ちに削除しても良い。
【００３０】
図１０は、第１の実施形態に係る鍵共有シーケンスの例である。鍵共有は、参加ノードとコーディネータ２０との間の認証完了後に行なうフェーズ（フェーズ１）と、参加ノードが暗号通信を行なう通信ピアを発見したときに行なうフェーズ（フェーズ２）とに分けられる。フェーズ１は、コーディネータ２０とコントローラ３０との間の鍵共有であるフェーズ１Ａと、コーディネータ２０と機器４０との間の鍵共有であるフェーズ１Ｂとに分かれる。なお、フェーズ１Ａとフェーズ１Ｂとは、何れが先に行なわれても良い。また、フェーズ２は、コーディネータ２０とコントローラ３０との間の鍵共有であるフェーズ２Ａと、コーディネータ２０と機器４０との間の鍵共有であるフェーズ２Ｂとに分かれる。なお、フェーズ２Ａとフェーズ２Ｂとは、何れが先に行なわれても良い。フェーズ１Ａ、フェーズ１Ｂ、フェーズ２Ａ及びフェーズ２Ｂの各フェーズでは、ＩＥＥＥ８０２．２１ｄを使用して鍵共有を行なう。以下に、各フェーズについて説明する。
【００３１】
フェーズ１Ａにおいて、コーディネータ２０は、コントローラ３０に対し、コーディネータ２０とコントローラ３０との間の個別通信用グループ鍵をプッシュにより配布する（図１０の（１）参照）。そして、コーディネータ２０は、コントローラ３０に対し、ＨＡＮグループ鍵をプッシュにより配布する（図１０の（２）参照）。続いて、コーディネータ２０は、コントローラ３０に対し、コントローラグループ鍵をプッシュにより配布する（図１０の（３）参照）。その後、コーディネータ２０は、コントローラ３０に対し、アプリケーションシステムグループ鍵をプッシュにより配布する（図１０の（４）参照）。
【００３２】
フェーズ１Ｂにおいて、コーディネータ２０は、機器４０に対し、コーディネータ２０と機器４０との間の個別通信用グループ鍵をプッシュにより配布する（図１０の（５）参照）。そして、コーディネータ２０は、機器４０に対し、ＨＡＮグループ鍵をプッシュにより配布する（図１０の（６）参照）。
【００３３】
フェーズ２Ａにおいて、コーディネータ２０は、コントローラ３０に対し、コントローラ３０と機器４０との間の個別通信用グループ鍵を、プル又はプッシュにより配布する（図１０の（７）参照）。ここで、フェーズ２Ａがフェーズ２Ｂよりも先に行なわれる場合にはプル、フェーズ２Ｂがフェーズ２Ａよりも先に行なわれる場合にはプッシュとなる。そして、コーディネータ２０は、コントローラ３０に対し、機器４０のＸ．５０９証明書をプッシュにより配布する（図１０の（８）参照）。
【００３４】
フェーズ２Ｂにおいて、コーディネータ２０は、機器４０に対し、コントローラ３０と機器４０との間の個別通信用グループ鍵を、プル又はプッシュにより配布する（図１０の（９）参照）。ここで、フェーズ２Ａがフェーズ２Ｂよりも先に行なわれる場合にはプル、フェーズ２Ｂがフェーズ２Ａよりも先に行なわれる場合にはプッシュとなる。そして、コーディネータ２０は、機器４０に対し、アプリケーションシステムグループ鍵をプッシュにより配布する（図１０の（１０）参照）。続いて、コーディネータ２０は、機器４０に対し、コントローラ３０のＸ．５０９証明書をプッシュにより配布する（図１０の（１１）参照）。
【００３５】
図１０に示した鍵共有シーケンスにおいて、（３）は、コントローラグループ鍵を使用しない場合には不要である。また、（４）及び（１０）は、アプリケーションシステムグループ鍵を使用しない場合には不要である。また、（８）は、暗号通信において機器４０の送信元署名を付与しない場合には不要である。また、プッシュによるグループ鍵配布は、プルによるグループ鍵配布に置き換えることも可能である。
【００３６】
（１）及び（５）以外の各ステップでコーディネータ２０と参加ノードとの間で交換されるＩＥＥＥ８０２．２１ｄメッセージは、コーディネータ２０と参加ノードとの間の個別通信用グループ宛てに送信される。また、（１）及び（５）で交換されるＩＥＥＥ８０２．２１ｄメッセージは、個別ノード宛てに送信される。図１０に示した（１）〜（１１）の各ステップは、「プッシュによるグループ鍵配布」、「プルによるグループ鍵配布」、「プッシュによる証明書配布」の３種類の基本手順に分類できる。以下では、これらの３種類の手順について説明する。
【００３７】
プッシュによるグループ鍵配信時に、コーディネータ２０は、参加ノードに対し、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信した参加ノードは、コーディネータ２０に対し、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。
【００３８】
プルによるグループ鍵配信時に、参加ノードは、コーディネータ２０に対し、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したコーディネータ２０は、参加ノードに対し、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。
【００３９】
プッシュによる証明書配布時に、コーディネータ２０は、参加ノードに対し、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを受信した参加ノードは、コーディネータ２０に対し、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。
【００４０】
暗号通信では、ユニキャスト暗号通信とマルチキャスト暗号通信とをサポートする。ユニキャスト暗号通信と、マルチキャスト暗号通信とでは、暗号化されたＥＣＨＯＮＥＴ  Ｌｉｔｅメッセージを含むＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅ  ｉｎｄｉｃａｔｉｏｎメッセージが使用される。ユニキャスト暗号通信のＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅ  ｉｎｄｉｃａｔｉｏｎメッセージは、個別通信用グループ宛てに送信される。マルチキャスト暗号通信のＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅ  ｉｎｄｉｃａｔｉｏｎメッセージは、個別通信用グループ以外のグループ宛てに送信される。
【００４１】
証明書リボーク時に、コーディネータ２０は、ＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージをマルチキャスト又はユニキャストで送信する。マルチキャストで送信する場合、ドメインの範囲内においてＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したノード（コントローラ３０又は機器４０）は、ＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージをユニキャストでコーディネータ２０に送信する。
【００４２】
証明書リボーク時のユニキャストＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージは、コーディネータ２０と参加ノードとの間の個別通信用グループ宛てに送信される。マルチキャストＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージは、ＨＡＮグループ宛てに送信される。ＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージは、コーディネータ２０と参加ノードとの間の個別通信用グループ宛てに送信される。ユニキャストによる証明書リボークは、マルチキャストによる証明書リボークと併用することが可能である。
【００４３】
鍵更新時に、コーディネータ２０は、プッシュによるグループ鍵配信を起動する。このとき、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージをマルチキャストで一斉同報する、又は、ユニキャストで個別ノード宛てに送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信した参加ノード（コントローラ３０又は機器４０）は、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを、ユニキャストでコーディネータ２０に送信する。
【００４４】
鍵更新時のユニキャストＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージは、コーディネータ２０と参加ノードとの間の個別通信用グループ宛てに送信される。マルチキャストＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージは、ＨＡＮグループ宛てに送信される。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージは、コーディネータ２０と参加ノードとの間の個別通信用グループ宛てに送信される。ユニキャストによる鍵更新は、マルチキャストによるグループ鍵更新と併用することが可能である。
【００４５】
あるグループに対する鍵更新は、グループからメンバーが離脱した場合や、グループを削除する場合に起動される。また、鍵更新による通信瞬断を避けることが好ましく、パケット送信とパケット受信とにおいて、以下の実装が推奨される。パケット送信では、新鍵をコーディネータ２０から受信してから一定期間（Ｔ）、旧鍵を使用し、以降は新鍵を使用する。パケット受信では、新鍵をコーディネータ２０から受信してから一定期間（２Ｔ）、旧鍵及び新鍵のどちらでも使用可能とする。ここで、「Ｔ」は、鍵更新時間の最大値であり、例えばデフォルト値は１８０秒である。
【００４６】
鍵更新時に新鍵の受信に失敗したことで新鍵を保有していない参加ノードは、新鍵で暗号化された、自ノードが属するグループ宛てのメッセージを受信した場合に、プルによるグループ鍵配信を起動すれば良い。鍵更新の結果、一定期間２Ｔの間、コーディネータ２０がＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージをグループに所属するノードの何れからも受信しなかった場合には、鍵更新失敗となる。鍵更新に失敗したコーディネータ２０は、鍵更新のリトライを試みても良く、これにより、鍵更新のリトライのたびに新しい鍵が生成されるかもしれない。
【００４７】
あるグループを削除する場合には、削除対象のグループに対し、空のＣｏｍｐｌｅｔｅ  Ｓｕｂｔｒｅｅを指定した鍵更新を実施する。又は、Ｃｏｍｐｌｅｔｅ  Ｓｕｂｔｒｅｅにグループ管理木の未使用の葉ノードを１つだけ含む鍵更新を実行する。
【００４８】
［セキュリティ］
本実施形態で使用されるＩＥＥＥ８０２．２１ｄの全てのメッセージに適用されるセキュリティ共通処理のうち、ＩＥＥＥ８０２．２１ｄで詳細が規定されていない部分を規定する。ＩＥＥＥ８０２．２１ｄメッセージの保護のためのセキュリティは、秘匿性、送信元認証の２種類である。これらのうち、秘匿性は、ＡＥＳ−ＣＣＭにより実現される。また、送信元認証は、鍵長２５６ビットのＥＣＤＳＡにより実現される。秘匿性の有効時には、ＳＡＩＤ（Security  Association  Identifier）  ＴＬＶ（Type  Length  Value）、及びＳｅｃｕｒｉｔｙ  ＴＬＶが使用される。送信元認証の有効時には、Ｓｉｇｎａｔｕｒｅ  ＴＬＶが使用される。秘匿性と送信元認証とがともに有効である場合には、ＳＡＩＤ  ＴＬＶ、Ｓｅｃｕｒｉｔｙ  ＴＬＶ、Ｓｉｇｎａｔｕｒｅ  ＴＬＶが使用される。以下に、ＩＥＥＥ８０２．２１ｄメッセージの保護に関するセキュリティポリシーと、ＡＥＳ−ＣＣＭで使用されるシーケンス番号の更新方法とを説明する。
【００４９】
セキュリティポリシーには、個別通信のセキュリティポリシーと、グループ通信のセキュリティポリシーとが存在する。本実施形態において、個別通信とは、ＩＥＥＥ８０２．２１ｄのＤｅｓｔｉｎａｔｉｏｎ  ＩｄｅｎｔｉｆｉｅｒにＭＩＨＦ  ＩＤを使用した１対１の通信のことを指す。また、グループ通信とは、ＩＥＥＥ８０２．２１ｄのＤｅｓｔｉｎａｔｉｏｎ  ＩｄｅｎｔｉｆｉｅｒにＭＩＨＦ  ＧｒｏｕｐＩＤを使用した多対多の通信のことを指す。グループ通信の特殊ケースとして、グループメンバ数が２である通信を個別グループ通信と呼ぶ。個別通信と個別グループ通信とは、セキュリティポリシーの観点で区別される。
【００５０】
個別通信については、秘匿性は常に無効とし、送信元認証は所定のメッセージを除き常に有効とする。例えば、所定のメッセージは、ＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒ  ｒｅｑｕｅｓｔである。グループ通信に関しては、グループ毎に、全体ポリシー、送信元別ポリシー、メッセージ別ポリシー等のセキュリティポリシーを定める。全体ポリシーは、対象グループ全体に適用されるセキュリティポリシーである。全体ポリシーには、「有効」又は「無効」の何れかのポリシーが設定される。送信元別ポリシーは、同一グループ内の送信元別に適用されるセキュリティポリシーである。送信元別ポリシーには、全体ポリシーに対する例外が適用される送信元を指定する。例えば、送信元別ポリシーは、全体ポリシーが「有効」であるときに例外＝「無効」となり、全体ポリシーが「無効」であるときに例外＝「有効」となる。送信元別ポリシーは、全体ポリシーの例外を適用する送信元識別子のリスト、Ｂｌｏｏｍ  Ｆｉｌｔｅｒ、又は、Ｃｏｍｐｌｅｔｅ  Ｓｕｂｔｒｅｅにより指定される。
【００５１】
メッセージ別ポリシーは、同一グループ内のメッセージ毎に適用されるポリシーである。メッセージ別ポリシーには、全体ポリシーに対する例外が適用されるメッセージを指定する。例えば、メッセージ別ポリシーは、全体ポリシーが「有効」であるときに例外＝「無効」となり、全体ポリシーが「無効」であるときに例外＝「有効」となる。メッセージ別ポリシーは、全体ポリシーの例外を適用するメッセージ識別子のリスト、Ｂｌｏｏｍ  Ｆｉｌｔｅｒ、又は、ビットマップにより指定される。
【００５２】
図１１は、第１の実施形態に係るグループ通信セキュリティポリシーのデフォルト値の例を示す図である。図１１において、網掛けで表された箇所は、変更不可である。例えば、設定により変更可能なセキュリティポリシーは、個別通信用グループ以外の送信元認証に関する送信元別ポリシー及びメッセージ別ポリシーである。変更可能なセキュリティポリシーの設定は、事前に設定しておく、グループ識別子にポリシー情報を埋め込む、グループ操作コマンドで通知する、の何れかにより行なわれる。なお、グループ操作コマンドは、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ又はＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅである。
【００５３】
ＩＥＥＥ８０２．２１ｄのＡＥＳ−ＣＣＭは、１３オクテットのＮｏｎｃｅを使用する。このＮｏｎｃｅは、ＴｒａｎｓａｃｔｉｏｎＩＤ（２オクテット）、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ（１０オクテット）、ＦｒａｇｍｅｎｔＮｕｍｂｅｒ（１オクテット）を連結したものである。これらのうち、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ以外は、パケットヘッダのフィールドである。
【００５４】
本実施形態においては、送信元毎にＡＥＳ−ＣＣＭのＳｅｑｕｅｎｅ  Ｎｕｍｂｅｒが管理され、グループ生成やグループ鍵更新によるＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒのリセットは行なわれないものとする。つまり、本実施形態では、グループ存命中にＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒが１周することはないと仮定する。なお、グループ存命中とは、対象となるグループに含まれるノード数が１以上であることを指す。
【００５５】
Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒは、単調増加する４オクテットの同期カウンタと、単調増加する６オクテットのパケットカウンタのサブフィールドを持つ。同期カウンタは、コーディネータ２０により割り当てられ、他のノードに通知される。パケットカウンタは、ＩＥＥＥ８０２．２１メッセージの送信毎に１ずつインクリメントされる。例えば、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの値は、現在の同期カウンタの値を「ａ」、現在のパケットカウンタの値を「ｂ」とすると、（ａ，ｂ）で表される。
【００５６】
認証・鍵共有時及び鍵更新時には、プッシュ又はプルによる鍵配信により、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ＝（ａ，０）が各ノードに通知される。Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの同期を、ノードの再起動等の何らかの事由により喪失した場合には、暗号通信が途絶するため、シーケンス番号の再同期が行なわれる。ここで、シーケンス番号の同期喪失の条件は、以下の場合である。例えば、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを喪失した場合や、受信フレームのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒと自身が管理する受信Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ値の差が閾値を超えた場合、シーケンス番号の同期維持を確認してから一定時間が経過した場合である。かかるシーケンス番号の再同期は、参加ノードをトリガとして行なわれる場合と、コーディネータ２０をトリガとして行なわれる場合とが存在する。
【００５７】
図１２は、第１の実施形態に係る参加ノードをトリガとしてシーケンス番号の再同期を行なう例を説明する図である。なお、図１２では、参加ノードとして、参加ノード１と参加ノード２とが存在する場合を例に挙げる。図１２の（１）に示すように、参加ノード１は、同期カウンタ（例えば、ａとする）を保持していない場合に、コーディネータ２０に対して同期カウンタの取得要求を行なう。例えば、参加ノード１は、同期カウンタの取得要求として、セキュリティ保護されていない（暗号化されていない、及び、署名なし）ＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒ  ｒｅｑｕｅｓｔメッセージをコーディネータ２０に対して送信する。同期カウンタを保持していない状況は、元々保持していない場合のほか、リブートや、スリープ状態からアクティブになったとき等の状態において起こり得る。また、参加ノード１によって同期カウンタが保持されている場合には、同期カウンタの取得要求は行なわれなくて良いため、図１２の（３）における処理が実行される。
【００５８】
図１２の（２）に示すように、同期カウンタの取得要求を受信したコーディネータ２０は、同期カウンタの取得要求に対する応答（同期カウンタ取得応答）を参加ノード１に対して送信する。例えば、コーディネータ２０は、同期カウンタの取得要求の応答として、個別通信用グループ鍵で暗号化されており、署名なしのＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒ  ｒｅｓｐｏｎｓｅメッセージを参加ノード１に対して送信する。同期カウンタ取得応答を受信した参加ノード１は、自身の同期カウンタを、受信メッセージのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒに含まれる同期カウンタの値（例えば、ａとする）に設定する。
【００５９】
図１２の（３）に示すように、同期カウンタの取得応答を受信した参加ノード１は、コーディネータ２０に対して同期カウンタの更新要求を行なう。例えば、参加ノード１は、個別通信用グループ鍵で暗号化されており、署名なし、且つ、Ｒｅｑｕｅｓｔ  Ｃｏｄｅ＝１であるＭＩＨ＿Ｒｅｇｉｓｔｒａｔｉｏｎ  ｒｅｑｕｅｓｔメッセージをコーディネータ２０に対して送信する。ＭＩＨ＿Ｒｅｇｉｓｔｒａｔｉｏｎ  ｒｅｑｕｅｓｔメッセージのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ値は、（ａ，ｂ＿ｍａｘ）とする。ｂ＿ｍａｘは、パケットカウンタの最大値である。
【００６０】
図１２の（４）に示すように、同期カウンタの更新要求を受信したコーディネータ２０は、同期カウンタの更新要求に対する応答（同期カウンタ更新応答）を参加ノード１に対して送信する。例えば、コーディネータ２０は、同期カウンタ更新要求の応答として、個別通信用グループ鍵で暗号化されており、署名なしのＭＩＨ＿Ｒｅｇｉｓｔｒａｔｉｏｎ  ｒｅｓｐｏｎｓｅメッセージを参加ノード１に対して送信する。参加ノード１は、同期カウンタ更新応答の受信に成功した場合には次の処理を実行し、同期カウンタ更新応答の受信に失敗した場合には保持している同期カウンタを破棄し、同期カウンタの取得要求を行なう。
【００６１】
また、同期カウンタ更新応答を送信したコーディネータ２０は、同期カウンタを１だけインクリメントする。例えば、コーディネータ２０は、更新後の同期カウンタ値を「ａ＿ｎｅｗ」とすると、ａ＿ｎｅｗ＝ａ＋１に更新する。そして、図１２の（５）に示すように、同期カウンタを更新したコーディネータ２０は、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ（ａ＿ｎｅｗ，０）を持つ同期カウンタ更新通知を、ＨＡＮグループ宛てのマルチキャストにより参加ノード１や参加ノード２に通知する。例えば、同期カウンタ更新通知は、ＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａがＮｕｌｌのドメイングループ鍵で暗号化されており、署名付きのＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅ  ｉｎｄｉｃａｔｉｏｎメッセージである。
【００６２】
これらにより、同期カウンタ更新通知を受信した各参加ノードは、同期カウンタの値を更新するとともに、自身が管理する全ての送信用Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ及び受信用Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを（ａ＿ｎｅｗ，０）に設定する。なお、受信用Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの再同期に失敗した参加ノードは、全てのグループに関するステートを削除し、上述した鍵共有シーケンスを実行する。なお、個別通信用グループ鍵によるメッセージ認証コードは、グループ操作コマンド用メッセージだけではなく、他のメッセージに対しても付与されても良い。例えば、図１０に示した（８）や（１１）等の機器証明書やコントローラ証明書の配布時に使用されても良い。なお、同期カウンタの更新は、個別通信グループ操作コマンド用のメッセージを含まない場合に用いても良いし、個別通信用グループに対応するグループ鍵を使わない場合に用いても良い。
【００６３】
図１３は、第１の実施形態に係るコーディネータ２０をトリガとしてシーケンス番号の再同期を行なう例を説明する図である。なお、図１３では、参加ノードとして、参加ノード１と参加ノード２とが存在する場合を例に挙げる。図１３に示すように、コーディネータ２０は、リブート後に、同期カウンタを１だけインクリメントする。上述したように、コーディネータ２０は、更新後の同期カウンタ値をａ＿ｎｅｗ＝ａ＋１に更新する。そして、コーディネータ２０は、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ（ａ＿ｎｅｗ，０）を持つ同期カウンタ更新通知を、ＨＡＮグループ宛てのマルチキャストにより参加ノード１や参加ノード２に通知する。上述したように、同期カウンタ更新通知は、ＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａがＮｕｌｌのドメイングループ鍵で暗号化されており、署名付きのＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅ  ｉｎｄｉｃａｔｉｏｎメッセージである。これらにより、同期カウンタ更新通知を受信した各参加ノードは、同期カウンタの値を更新するとともに、自身が管理する全ての送信用Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ及び受信用Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを（ａ＿ｎｅｗ，０）に設定する。
【００６４】
［ＩＥＥＥ８０２．２１ｄメッセージＴＬＶ］
本実施形態で使用されるＩＥＥＥ８０２．２１ｄメッセージに含まれるセキュリティポリシー非依存ＴＬＶを説明する。セキュリティポリシー非依存ＴＬＶは、ＩＥＥＥ８０２．２１ｄ  ＴＬＶのうち、ＳＡＩＤ  ＴＬＶ、Ｓｅｃｕｒｉｔｙ  ＴＬＶ及びＳｉｇｎａｔｕｒｅ  ＴＬＶ以外のＴＬＶである。
【００６５】
図１４は、第１の実施形態に係るＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１４に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０の識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、ユニキャストの場合、参加ノードの識別子、又は、コーディネータ２０と参加ノードとの間の個別通信用グループの識別子である。また、ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、マルチキャストの場合、ＨＡＮグループの識別子である。ＴａｒｇｅｔＩｄｅｎｔｉｆｉｅｒは、グループ識別子であり、個別通信用グループ又はアプリケーションシステムグループの場合はＬｅａｆＩＤを使用する。
【００６６】
ＲｅｓｐｏｎｓｅＦｌａｇは、応答要求フラグであり、値「１」を指定する。ＧｒｏｕｐＫｅｙＤａｔａは、暗号化されたグループ鍵であり、空のＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅが指定される場合、ＧｒｏｕｐＫｅｙＤａｔａ及びＳＡＩＤＮｏｔｉｆｉｃａｔｉｏｎは不要である。ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅは、ＧｒｏｕｐＫｅｙＤａｔａの復号に使用されるＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅデータである。ＳｅｑｕｅｎｃｅＮｕｍｂｅｒは、暗号通信時の送信パケットのＡＥＳ−ＣＣＭ  ＮｏｎｃｅフィールドのＳｅｑｕｅｎｃｅＮｕｍｂｅｒ部の初期値である。ＴａｒｇｅｔＡｄｄｒｅｓｓは、個別通信用グループの場合にメッセージに含まれ、参加ノードに対する通信ピアノードのＩＰアドレスを指定する。ＳＡＩＤ  Ｎｏｔｉｆｉｃａｔｉｏｎは、ＧｒｏｕｐＫｅｙＤａｔａに対応するＳＡＩＤを指定する。
【００６７】
図１５は、第１の実施形態に係るＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１５に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、参加ノードの識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０の識別子、又は、コーディネータ２０と参加ノードとの間の個別通信用グループ識別子である。ＴａｒｇｅｔＩｄｅｎｔｉｆｉｅｒは、グループ識別子であり、個別通信用グループ又はアプリケーションシステムグループの場合はＬｅａｆＩＤを使用する。ＧｒｏｕｐＳｔａｔｕｓは、グループ操作結果であり、Ｊｏｉｎ  ｏｐｅｒａｔｉｏｎ  ｓｕｃｃｅｓｓｆｕｌ（値「０」）を指定する。
【００６８】
図１６は、第１の実施形態に係るＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１６に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、参加ノードの識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０と参加ノードとの間の個別通信用グループ識別子、又は、コーディネータ２０の個別ノード識別子である。ＴａｒｇｅｔＩｄｅｎｔｉｆｉｅｒは、グループ識別子であり、個別通信用グループの場合はＬｅａｆＩＤ以外の識別子を指定する。ＧｒｏｕｐＡｃｔｉｏｎは、グループ操作種別であり、Ｊｏｉｎ  ｔｈｅ  ｇｒｏｕｐ（値「０」）を指定する。
【００６９】
図１７は、第１の実施形態に係るＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１７に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０の識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０と参加ノードとの間の個別通信用グループ識別子、又は、参加ノードの個別ノード識別子である。ＴａｒｇｅｔＩｄｅｎｔｉｆｉｅｒは、グループ識別子であり、個別通信用グループ又はアプリケーションシステムグループの場合はＬｅａｆＩＤを使用する。ＧｒｏｕｐＫｅｙＤａｔａは、暗号化されたグループ鍵である。ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅは、ＧｒｏｕｐＫｅｙＤａｔａの復号に使用されるＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅデータである。ＳｅｑｕｅｎｃｅＮｕｍｂｅｒは、暗号通信時の送信パケットのＡＥＳ−ＣＣＭ  ＮｏｎｃｅフィールドのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ部の初期値である。ＳＡＩＤ  Ｎｏｔｉｆｉｃａｔｉｏｎは、ＧｒｏｕｐＫｅｙＤａｔａに対応するＳＡＩＤを指定する。
【００７０】
図１８は、第１の実施形態に係るＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１８に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、参加ノードの識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、ユニキャストの場合、コーディネータ２０と参加ノードとの間の個別通信用グループの識別子である。また、ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、マルチキャストの場合、ＨＡＮグループの識別子である。Ｃｅｒｔｉｆｉｃａｔｅは、参加ノードと暗号通信を行なう通信ピアノードのＸ．５０９証明書である。
【００７１】
図１９は、第１の実施形態に係るＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１９に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０の識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０と参加ノードとの間の個別通信用グループの識別子である。ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒは、ＨＩＭ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージにより配布されたＸ．５０９証明書のシリアル番号である。ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓは、配布された証明書のステータスであり、証明書が有効である場合にはＣｅｒｔｉｆｉｃａｔｅ  Ｖａｌｉｄ（値「０」）が入る。
【００７２】
図２０は、第１の実施形態に係るＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅ  ｉｎｄｉｃａｔｉｏｎメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図２０に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、送信元ノードの識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、宛先識別子であり、ユニキャスト暗号通信の場合には個別通信用グループの識別子が使用される。ここで、個別通信用グループの識別子は、ＩＤｘ＋‘＠’＋ＩＤｙ（Ｌ）、又は、ＩＤｙ＋‘＠’＋ＩＤｘ（Ｌ）である。また、ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、マルチキャスト暗号通信の場合、アプリケーションシステムグループ使用時にはアプリケーションシステムグループの識別子（‘＠’＋ＩＤｃｔｌ（Ｌ））が使用され、それ以外のグループ使用時にはＨＡＮグループの識別子（“”）が使用される。ＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａには、コーディネータ２０からの同期カウンタ更新通知に使用される場合Ｎｕｌｌとなり、それ以外はアプリケーション種別（ＵＤＰポート番号など）、及び、アプリケーションメッセージ（ＥＣＨＯＮＥＴ−Ｌｉｔｅ電文など）が含まれる。
【００７３】
図２１は、第１の実施形態に係るＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図２１に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０の識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、ユニキャストの場合、コーディネータ２０と参加ノードとの間の個別通信用グループの識別子である。また、ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、マルチキャストの場合、ＨＡＮグループの識別子である。ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒは、リボークされる証明書のシリアル番号である。ＣｅｒｔｉｆｉｃａｔｅＲｅｖｏｃａｔｉｏｎは、リボークされる証明書の発行元のデジタル署名である。
【００７４】
図２２は、第１の実施形態に係るＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図２２に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、参加ノードの識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０と参加ノードとの間の個別通信用グループの識別子である。ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒは、リボークされる証明書のシリアル番号である。ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓは、リボークされる証明書のステータスであり、リボーク成功の場合にはＣｅｒｔｉｆｉｃａｔｅ  Ｖａｌｉｄ（値「１」）を設定する。
【００７５】
次に、本実施形態に係る鍵共有、暗号通信、証明書リボーク、鍵更新についての詳細シーケンスを説明する。
【００７６】
［鍵共有フェーズ１の詳細シーケンス］
図２３は、第１の実施形態に係る鍵共有フェーズ１Ａの詳細シーケンスの例である。図２３では、ＩＤｃｔｌはコントローラ３０の識別子、ＩＤｃｄｎはコーディネータ２０の識別子、ＩＤｄｅｖは機器４０の識別子を表す。また、図２３に示す（１）〜（４）は、図１０に示した（１）〜（４）に相当する。
【００７７】
図２３の（１）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｄｎ，ｃｔｌ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳｅｑｕｅｎｃｅＮｕｍ，ＳＡＩＤＮｏｔｉｆ，Ｓｉｇｎａｔｕｒｅ」が含まれる。また、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｃｄｎ（Ｌ），ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ，Ｓｉｇｎａｔｕｒｅ」が含まれる。
【００７８】
図２３の（２）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ１），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝“”，ＳｅｑｕｅｎｃｅＮｕｍ，ＳＡＩＤＮｏｔｉｆ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝“”，ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。
【００７９】
図２３の（３）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ２），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝“Ｃｏｎｔｒｏｌｌｅｒｓ”，ＳｅｑｕｅｎｃｅＮｕｍ，ＳＡＩＤＮｏｔｉｆ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝“Ｃｏｎｔｒｏｌｌｅｒｓ”，ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。
【００８０】
図２３の（４）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ），ＣｏｍｐｕｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。
【００８１】
なお、鍵共有フェーズ１Ａにおいては、図２３の（１）に先立ち、コントローラ３０からコーディネータ２０に対し、ＩＥＥＥ８０２．２１‐２００８で規定されるＭＩＨ  Ｒｅｇｉｓｔｒａｔｉｏｎが行なわれるかもしれない。
【００８２】
図２４は、第１の実施形態に係る鍵共有フェーズ１Ｂの詳細シーケンスの例である。図２４では、ＩＤｃｔｌはコントローラ３０の識別子、ＩＤｃｄｎはコーディネータ２０の識別子、ＩＤｄｅｖは機器４０の識別子を表す。また、図２４に示す（５）及び（６）は、図１０に示した（５）及び（６）に相当する。
【００８３】
図２４の（５）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ（Ｌ），ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｄｎ，ｄｅｖ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳｅｑｕｅｎｃｅＮｕｍ，ＳＡＩＤＮｏｔｉｆ，Ｓｉｇｎａｔｕｒｅ」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｃｄｎ（Ｌ），ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ，Ｓｉｇｎａｔｕｒｅ」が含まれる。
【００８４】
図２４の（６）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ１），ＣｏｍｐｌｅｔｅＳｕｂｔｕｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝“”，ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝“”，ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。
【００８５】
なお、鍵共有フェーズ１Ｂにおいては、図２４の（５）に先立ち、機器４０からコーディネータ２０に対し、ＩＥＥＥ８０２．２１‐２００８で規定されるＭＩＨ  Ｒｅｇｉｓｔｒａｔｉｏｎが行なわれるかもしれない。
【００８６】
［鍵共有フェーズ２の詳細シーケンス］
図２５は、第１の実施形態に係る鍵共有フェーズ２の詳細シーケンスの例である。図２５では、フェーズ２Ａがフェーズ２Ｂよりも先行する場合を例に挙げる。図２５では、ＩＤｃｔｌはコントローラ３０の識別子、ＩＤｃｄｎはコーディネータ２０の識別子、ＩＤｄｅｖは機器４０の識別子を表す。また、図２５に示す（７）〜（１１）は、図１０に示した（７）〜（１１）に相当する。
【００８７】
図２５の（７）に示すように、コントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｅ  ｏｒ  Ｓ），ＧｒｏｕｐＡｃｔｉｏｎ＝ｊｏｉｎ｝」が含まれる。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したコーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ，ｄｅｖ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ，ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。
【００８８】
図２５の（８）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛Ｃｅｒｔｉｆｉｃａｔｅ（ＣＥＲＴｄｅｖ）｝」が含まれる。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒ，ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ｝」が含まれる。
【００８９】
図２５の（９）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ，ｄｅｖ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＡｄｄｒ＝ＩＰｃｔｌ，ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。
【００９０】
図２５の（１０）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。
【００９１】
図２５の（１１）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛Ｃｅｒｔｉｆｉｃａｔｅ（ＣＥＲＴｃｔｌ）｝」が含まれる。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒ，ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ｝」が含まれる。
【００９２】
なお、鍵共有フェーズ２Ｂをコントローラ３０間通信の鍵共有に使用する場合、鍵共有フェーズ２Ｂの機器４０（ＩＤｄｅｖ）は、鍵共有フェーズ２Ａのコントローラ３０（ＩＤｃｔｌ）の通信相手のコントローラ３０（ＩＤｃｔｌ’）に置き換えられ、（７）が省略される。また、鍵共有フェーズ２Ａを機器４０間通信の鍵共有に使用する場合、鍵共有フェーズ２Ａのコントローラ３０（ＩＤｃｔｌ）は、鍵共有フェーズ２Ｂの機器４０（ＩＤｄｅｖ）の通信相手の機器４０（ＩＤｄｅｖ’）に置き換えられ、（７）が省略される。
【００９３】
図２６は、第１の実施形態に係る鍵共有フェーズ２の詳細シーケンスの例である。図２６では、フェーズ２Ｂがフェーズ２Ａよりも先行する場合を例に挙げる。図２６では、ＩＤｃｔｌはコントローラ３０の識別子、ＩＤｃｄｎはコーディネータ２０の識別子、ＩＤｄｅｖは機器４０の識別子を表す。また、図２６に示す（７）〜（１１）は、図１０に示した（７）〜（１１）に相当する。
【００９４】
図２６の（９）に示すように、機器４０は、コーディネータ２０に対して、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｅ  ｏｒ  Ｓ），ＧｒｏｕｐＡｃｔｉｏｎ＝ｊｏｉｎ｝」が含まれる。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したコーディネータ２０は、機器４０に対して、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ，ｄｅｖ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ，ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。
【００９５】
図２６の（１０）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。
【００９６】
図２６の（１１）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛Ｃｅｒｔｉｆｉｃａｔｅ（ＣＥＲＴｃｔｌ）｝」が含まれる。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒ，ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ｝」が含まれる。
【００９７】
図２６の（７）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ，ｄｅｖ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＡｄｄｒ＝ＩＰｄｅｖ，ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。
【００９８】
図２６の（８）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛Ｃｅｒｔｉｆｉｃａｔｅ（ＣＥＲＴｄｅｖ）｝」が含まれる。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒ，ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ｝」が含まれる。
【００９９】
［暗号通信の詳細シーケンス］
図２７は、第１の実施形態に係る暗号通信の詳細シーケンスの例である。図２７において、ｇｉｄはグループ識別子であり、アプリケーションシステムグループの場合「ｇｉｄ＝＠ＩＤｃｔｌ（Ｌ）」、アプリケーションシステムグループ以外の場合「ｇｉｄ＝“”」である。図２７に示すように、コントローラ３０又は機器４０は、ユニキャスト暗号通信とマルチキャスト暗号通信において、コントローラ３０又は機器４０に対して、ＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅ  ｉｎｄｉｃａｔｉｏｎメッセージを送受信する。ＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅ  ｉｎｄｉｃａｔｉｏｎメッセージの送受信は、コントローラ３０又は機器４０（ＩＤｘ）と、コントローラ３０又は機器４０（ＩＤｙ）とにより行なわれる。
【０１００】
［証明書リボークの詳細シーケンス］
図２８は、第１の実施形態に係る証明書リボークの詳細シーケンスの例である。図２８に示すように、コーディネータ２０は、コントローラ３０又は機器４０に対して、マルチキャスト又はユニキャストにより、ＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。これにより、コントローラ３０又は機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。
【０１０１】
［グループ鍵更新の詳細シーケンス］
図２９は、第１の実施形態に係るグループ鍵更新の詳細シーケンスの例である。図２９に示すように、コーディネータ２０は、コントローラ３０又は機器４０に対して、マルチキャスト又はユニキャストにより、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｑｕｅｓｔメッセージを送信する。これにより、コントローラ３０又は機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ  ｒｅｓｐｏｎｓｅメッセージを送信する。
【０１０２】
本実施形態によれば、グループ識別子の構造に、グループのセマンティックを表し、且つ、グループの存命中は値が不変である可変値のフィールドを含むパケットをグループで送受するので、セマンティックの自由度を向上させるとともに、通信を簡素化することができる。
【０１０３】
また、本実施形態によれば、個別通信用グループに対応するグループ鍵による認証コードが付与された、署名なしのグループ操作コマンド用メッセージを用いて、グループ操作を制御するので、処理負荷を軽減することができる。
【０１０４】
また、上記文書中や図面中等で示した処理手順、制御手順、具体的名称、各種のデータやパラメータ等を含む情報は、特記する場合を除いて任意に変更することができる。また、図示した制御装置の各構成要素は、機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散又は統合の具体的形態は、図示のものに限られず、その全部又は一部を各種の負担や使用状況等に応じて、任意の単位で機能的又は物理的に分散又は統合することができる。
【０１０５】
また、上記実施形態に係る通信システム１０に含まれるコーディネータ２０やコントローラ３０、機器４０は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることで実現することが可能である。実行されるプログラムは、上述してきた各機能を含むモジュール構成となっている。プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録されて提供しても、ＲＯＭ等に予め組み込んで提供しても良い。
【０１０６】
また、上述してきた実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。また、各実施形態は、内容を矛盾させない範囲で適宜組み合わせることが可能である。また、各実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１０７】
１０  通信システム
２０  コーディネータ
３０  コントローラ
４０  機器
２１０  通信部
２２０  判定部
２３０  生成部
２４０  更新部
２５０  制御部
【図１】
2016063233.tif 000003
【図２】
2016063233.tif 000004
【図３】
2016063233.tif 000005
【図４】
2016063233.tif 000006
【図５】
2016063233.tif 000007
【図６】
2016063233.tif 000008
【図７】
2016063233.tif 000009
【図８】
2016063233.tif 000010
【図９】
2016063233.tif 000011
【図１０】
2016063233.tif 000012
【図１１】
2016063233.tif 000013
【図１２】
2016063233.tif 000014
【図１３】
2016063233.tif 000015
【図１４】
2016063233.tif 000016
【図１５】
2016063233.tif 000017
【図１６】
2016063233.tif 000018
【図１７】
2016063233.tif 000019
【図１８】
2016063233.tif 000020
【図１９】
2016063233.tif 000021
【図２０】
2016063233.tif 000022
【図２１】
2016063233.tif 000023
【図２２】
2016063233.tif 000024
【図２３】
2016063233.tif 000025
【図２４】
2016063233.tif 000026
【図２５】
2016063233.tif 000027
【図２６】
2016063233.tif 000028
【図２７】
2016063233.tif 000029
【図２８】
2016063233.tif 000030
【図２９】
2016063233.tif 000031