JP2017201832A

JP2017201832A - 通信制御装置及び通信装置

Info

Publication number: JP2017201832A
Application number: JP2017142926A
Authority: JP
Inventors: 大場　義洋; Yoshihiro Oba; 義洋大場; 嘉一花谷; Kiichi Hanatani
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2017-07-24
Filing date: 2017-07-24
Publication date: 2017-11-09

Abstract

【課題】処理負荷を削減する通信制御装置及び通信装置を提供する。
【解決手段】通信制御装置のコーディネータ２０は、生成部と、制御部とを有する。生成部は、ＧＫＢ（Group Key Block）を使用したシステムにおいて、自装置のデジタル署名を含む操作コマンドを用いて、２つの通信装置で構成される個別通信用グループに対応するグループ鍵を生成する。制御部は、生成されたグループ鍵による認証コードが付与されたグループ操作コマンド用メッセージを用いて、通信装置とのグループ操作を制御する。
【選択図】図３

Description

本発明の実施形態は、通信制御装置及び通信装置に関する。

ＩＥＥＥ８０２．２１ｄ／Ｄ０５では、グループマネージャ（GM：Group Manager）から送信されるグループ操作コマンド用メッセージにおいて、デジタル署名による送信元認証が行われている。

ＩＥＥＥ８０２．２１ｄ／Ｄ０５

ＩＥＥＥ８０２．２１ｄ／Ｄ０５において、グループ操作コマンド用メッセージは、複数のメンバーに送信されるため、グループ共通鍵によるメッセージ認証を送信元認証に使用することが困難である。すなわち、ＩＥＥＥ８０２．２１ｄ／Ｄ０５では、グループ操作のたびにデジタル署名の生成や検証が行なわれるため、処理負荷が増大する。

本発明が解決しようとする課題は、処理負荷を削減することができる通信制御装置及び通信装置を提供することである。

実施の形態の通信制御装置は、自装置のデジタル署名を含む第１操作コマンド用メッセージを用いて、２つの通信装置で構成される個別通信用グループに対応するグループ鍵を、通信装置に配布する配布部と、グループ鍵による認証コードが付与された第２操作コマンド用メッセージを用いて、通信装置とのグループ操作を制御する制御部とを有する。

第１の実施形態に係る通信システムの構成を示すブロック図。第１の実施形態に係るコントローラと機器との接続関係を示す図。第１の実施形態に係るノード種別の対応を示す図。第１の実施形態に係る各装置のハードウェア構成を示すブロック図。第１の実施形態に係るコーディネータの機能構成を示すブロック図。第１の実施形態に係るグループ管理木とＬｅａｆＩＤとを示す図。第１の実施形態に係るグループ割り当て規則を示す図。第１の実施形態に係る通信手順を示す全体シーケンス。第１の実施形態に係る認証シーケンス。第１の実施形態に係る鍵共有シーケンス。第１の実施形態に係るグループ通信セキュリティポリシーのデフォルト値を示す図。第１の実施形態に係る参加ノードをトリガとしてシーケンス番号の再同期を行なう図。第１の実施形態に係るコーディネータをトリガとしてシーケンス番号の再同期を行なう図。第１の実施形態に係るＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。第１の実施形態に係るＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。第１の実施形態に係るＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。第１の実施形態に係るＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。第１の実施形態に係るＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。第１の実施形態に係るＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。第１の実施形態に係るＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅｉｎｄｉｃａｔｉｏｎメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。第１の実施形態に係るＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。第１の実施形態に係るＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶを示す図。第１の実施形態に係る鍵共有フェーズ１Ａの詳細シーケンス。第１の実施形態に係る鍵共有フェーズ１Ｂの詳細シーケンス。第１の実施形態に係る鍵共有フェーズ２の詳細シーケンス。第１の実施形態に係る鍵共有フェーズ２の詳細シーケンス。第１の実施形態に係る暗号通信の詳細シーケンス。第１の実施形態に係る証明書リボークの詳細シーケンス。第１の実施形態に係るグループ鍵更新の詳細シーケンス。

（第１の実施形態）
［システムアーキテクチャ］
図１は、第１の実施形態に係る通信システムの構成例を示すブロック図である。本実施形態では、ＥＣＨＯＮＥＴＬｉｔｅノードのセキュリティ機能を例に挙げて説明する。ＥＣＨＯＮＥＴＬｉｔｅノードは、セキュリティ機能として、ＩＥＥＥ８０２．２１ｄ及びＲＦＣ５１９１で規定されるＰＡＮＡ（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）、及びＳｅｃｕｒｉｔｙＴＬＶが使用される。送信元認証の有効時には、ＳｉｇｎａｔｕｒｅＴＬＶが使用される。秘匿性と送信元認証とがともに有効である場合には、ＳＡＩＤＴＬＶ、ＳｅｃｕｒｉｔｙＴＬＶ、ＳｉｇｎａｔｕｒｅＴＬＶが使用される。以下に、ＩＥＥＥ８０２．２１ｄメッセージの保護に関するセキュリティポリシーと、ＡＥＳ−ＣＣＭで使用されるシーケンス番号の更新方法とを説明する。

セキュリティポリシーには、個別通信のセキュリティポリシーと、グループ通信のセキュリティポリシーとが存在する。本実施形態において、個別通信とは、ＩＥＥＥ８０２．２１ｄのＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒにＭＩＨＦＩＤを使用した１対１の通信のことを指す。また、グループ通信とは、ＩＥＥＥ８０２．２１ｄのＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒにＭＩＨＦＧｒｏｕｐＩＤを使用した多対多の通信のことを指す。グループ通信の特殊ケースとして、グループメンバ数が２である通信を個別グループ通信と呼ぶ。個別通信と個別グループ通信とは、セキュリティポリシーの観点で区別される。

個別通信については、秘匿性は常に無効とし、送信元認証は所定のメッセージを除き常に有効とする。例えば、所定のメッセージは、ＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒｒｅｑｕｅｓｔである。グループ通信に関しては、グループ毎に、全体ポリシー、送信元別ポリシー、メッセージ別ポリシー等のセキュリティポリシーを定める。全体ポリシーは、対象グループ全体に適用されるセキュリティポリシーである。全体ポリシーには、「有効」又は「無効」の何れかのポリシーが設定される。送信元別ポリシーは、同一グループ内の送信元別に適用されるセキュリティポリシーである。送信元別ポリシーには、全体ポリシーに対する例外が適用される送信元を指定する。例えば、送信元別ポリシーは、全体ポリシーが「有効」であるときに例外＝「無効」となり、全体ポリシーが「無効」であるときに例外＝「有効」となる。送信元別ポリシーは、全体ポリシーの例外を適用する送信元識別子のリスト、ＢｌｏｏｍＦｉｌｔｅｒ、又は、ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅにより指定される。

メッセージ別ポリシーは、同一グループ内のメッセージ毎に適用されるポリシーである。メッセージ別ポリシーには、全体ポリシーに対する例外が適用されるメッセージを指定する。例えば、メッセージ別ポリシーは、全体ポリシーが「有効」であるときに例外＝「無効」となり、全体ポリシーが「無効」であるときに例外＝「有効」となる。メッセージ別ポリシーは、全体ポリシーの例外を適用するメッセージ識別子のリスト、ＢｌｏｏｍＦｉｌｔｅｒ、又は、ビットマップにより指定される。

図１１は、第１の実施形態に係るグループ通信セキュリティポリシーのデフォルト値の例を示す図である。図１１において、網掛けで表された箇所は、変更不可である。例えば、設定により変更可能なセキュリティポリシーは、個別通信用グループ以外の送信元認証に関する送信元別ポリシー及びメッセージ別ポリシーである。変更可能なセキュリティポリシーの設定は、事前に設定しておく、グループ識別子にポリシー情報を埋め込む、グループ操作コマンドで通知する、の何れかにより行なわれる。なお、グループ操作コマンドは、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅ又はＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅである。

ＩＥＥＥ８０２．２１ｄのＡＥＳ−ＣＣＭは、１３オクテットのＮｏｎｃｅを使用する。このＮｏｎｃｅは、ＴｒａｎｓａｃｔｉｏｎＩＤ（２オクテット）、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ（１０オクテット）、ＦｒａｇｍｅｎｔＮｕｍｂｅｒ（１オクテット）を連結したものである。これらのうち、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ以外は、パケットヘッダのフィールドである。

本実施形態においては、送信元毎にＡＥＳ−ＣＣＭのＳｅｑｕｅｎｅＮｕｍｂｅｒが管理され、グループ生成やグループ鍵更新によるＳｅｑｕｅｎｃｅＮｕｍｂｅｒのリセットは行なわれないものとする。つまり、本実施形態では、グループ存命中にＳｅｑｕｅｎｃｅＮｕｍｂｅｒが１周することはないと仮定する。なお、グループ存命中とは、対象となるグループに含まれるノード数が１以上であることを指す。

ＳｅｑｕｅｎｃｅＮｕｍｂｅｒは、単調増加する４オクテットの同期カウンタと、単調増加する６オクテットのパケットカウンタのサブフィールドを持つ。同期カウンタは、コーディネータ２０により割り当てられ、他のノードに通知される。パケットカウンタは、ＩＥＥＥ８０２．２１メッセージの送信毎に１ずつインクリメントされる。例えば、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒの値は、現在の同期カウンタの値を「ａ」、現在のパケットカウンタの値を「ｂ」とすると、（ａ，ｂ）で表される。

認証・鍵共有時及び鍵更新時には、プッシュ又はプルによる鍵配信により、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ＝（ａ，０）が各ノードに通知される。ＳｅｑｕｅｎｃｅＮｕｍｂｅｒの同期を、ノードの再起動等の何らかの事由により喪失した場合には、暗号通信が途絶するため、シーケンス番号の再同期が行なわれる。ここで、シーケンス番号の同期喪失の条件は、以下の場合である。例えば、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒを喪失した場合や、受信フレームのＳｅｑｕｅｎｃｅＮｕｍｂｅｒと自身が管理する受信ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ値の差が閾値を超えた場合、シーケンス番号の同期維持を確認してから一定時間が経過した場合である。かかるシーケンス番号の再同期は、参加ノードをトリガとして行なわれる場合と、コーディネータ２０をトリガとして行なわれる場合とが存在する。

図１２は、第１の実施形態に係る参加ノードをトリガとしてシーケンス番号の再同期を行なう例を説明する図である。なお、図１２では、参加ノードとして、参加ノード１と参加ノード２とが存在する場合を例に挙げる。図１２の（１）に示すように、参加ノード１は、同期カウンタ（例えば、ａとする）を保持していない場合に、コーディネータ２０に対して同期カウンタの取得要求を行なう。例えば、参加ノード１は、同期カウンタの取得要求として、セキュリティ保護されていない（暗号化されていない、及び、署名なし）ＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒｒｅｑｕｅｓｔメッセージをコーディネータ２０に対して送信する。同期カウンタを保持していない状況は、元々保持していない場合のほか、リブートや、スリープ状態からアクティブになったとき等の状態において起こり得る。また、参加ノード１によって同期カウンタが保持されている場合には、同期カウンタの取得要求は行なわれなくて良いため、図１２の（３）における処理が実行される。

図１２の（２）に示すように、同期カウンタの取得要求を受信したコーディネータ２０は、同期カウンタの取得要求に対する応答（同期カウンタ取得応答）を参加ノード１に対して送信する。例えば、コーディネータ２０は、同期カウンタの取得要求の応答として、個別通信用グループ鍵で暗号化されており、署名なしのＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒｒｅｓｐｏｎｓｅメッセージを参加ノード１に対して送信する。同期カウンタ取得応答を受信した参加ノード１は、自身の同期カウンタを、受信メッセージのＳｅｑｕｅｎｃｅＮｕｍｂｅｒに含まれる同期カウンタの値（例えば、ａとする）に設定する。

図１２の（３）に示すように、同期カウンタの取得応答を受信した参加ノード１は、コーディネータ２０に対して同期カウンタの更新要求を行なう。例えば、参加ノード１は、個別通信用グループ鍵で暗号化されており、署名なし、且つ、ＲｅｑｕｅｓｔＣｏｄｅ＝１であるＭＩＨ＿Ｒｅｇｉｓｔｒａｔｉｏｎｒｅｑｕｅｓｔメッセージをコーディネータ２０に対して送信する。ＭＩＨ＿ＲｅｇｉｓｔｒａｔｉｏｎｒｅｑｕｅｓｔメッセージのＳｅｑｕｅｎｃｅＮｕｍｂｅｒ値は、（ａ，ｂ＿ｍａｘ）とする。ｂ＿ｍａｘは、パケットカウンタの最大値である。

図１２の（４）に示すように、同期カウンタの更新要求を受信したコーディネータ２０は、同期カウンタの更新要求に対する応答（同期カウンタ更新応答）を参加ノード１に対して送信する。例えば、コーディネータ２０は、同期カウンタ更新要求の応答として、個別通信用グループ鍵で暗号化されており、署名なしのＭＩＨ＿Ｒｅｇｉｓｔｒａｔｉｏｎｒｅｓｐｏｎｓｅメッセージを参加ノード１に対して送信する。参加ノード１は、同期カウンタ更新応答の受信に成功した場合には次の処理を実行し、同期カウンタ更新応答の受信に失敗した場合には保持している同期カウンタを破棄し、同期カウンタの取得要求を行なう。

また、同期カウンタ更新応答を送信したコーディネータ２０は、同期カウンタを１だけインクリメントする。例えば、コーディネータ２０は、更新後の同期カウンタ値を「ａ＿ｎｅｗ」とすると、ａ＿ｎｅｗ＝ａ＋１に更新する。そして、図１２の（５）に示すように、同期カウンタを更新したコーディネータ２０は、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ（ａ＿ｎｅｗ，０）を持つ同期カウンタ更新通知を、ＨＡＮグループ宛てのマルチキャストにより参加ノード１や参加ノード２に通知する。例えば、同期カウンタ更新通知は、ＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａがＮｕｌｌのドメイングループ鍵で暗号化されており、署名付きのＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅｉｎｄｉｃａｔｉｏｎメッセージである。

これらにより、同期カウンタ更新通知を受信した各参加ノードは、同期カウンタの値を更新するとともに、自身が管理する全ての送信用ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ及び受信用ＳｅｑｕｅｎｃｅＮｕｍｂｅｒを（ａ＿ｎｅｗ，０）に設定する。なお、受信用ＳｅｑｕｅｎｃｅＮｕｍｂｅｒの再同期に失敗した参加ノードは、全てのグループに関するステートを削除し、上述した鍵共有シーケンスを実行する。なお、個別通信用グループ鍵によるメッセージ認証コードは、グループ操作コマンド用メッセージだけではなく、他のメッセージに対しても付与されても良い。例えば、図１０に示した（８）や（１１）等の機器証明書やコントローラ証明書の配布時に使用されても良い。なお、同期カウンタの更新は、個別通信グループ操作コマンド用のメッセージを含まない場合に用いても良いし、個別通信用グループに対応するグループ鍵を使わない場合に用いても良い。

図１３は、第１の実施形態に係るコーディネータ２０をトリガとしてシーケンス番号の再同期を行なう例を説明する図である。なお、図１３では、参加ノードとして、参加ノード１と参加ノード２とが存在する場合を例に挙げる。図１３に示すように、コーディネータ２０は、リブート後に、同期カウンタを１だけインクリメントする。上述したように、コーディネータ２０は、更新後の同期カウンタ値をａ＿ｎｅｗ＝ａ＋１に更新する。そして、コーディネータ２０は、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ（ａ＿ｎｅｗ，０）を持つ同期カウンタ更新通知を、ＨＡＮグループ宛てのマルチキャストにより参加ノード１や参加ノード２に通知する。上述したように、同期カウンタ更新通知は、ＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａがＮｕｌｌのドメイングループ鍵で暗号化されており、署名付きのＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅｉｎｄｉｃａｔｉｏｎメッセージである。これらにより、同期カウンタ更新通知を受信した各参加ノードは、同期カウンタの値を更新するとともに、自身が管理する全ての送信用ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ及び受信用ＳｅｑｕｅｎｃｅＮｕｍｂｅｒを（ａ＿ｎｅｗ，０）に設定する。

［ＩＥＥＥ８０２．２１ｄメッセージＴＬＶ］
本実施形態で使用されるＩＥＥＥ８０２．２１ｄメッセージに含まれるセキュリティポリシー非依存ＴＬＶを説明する。セキュリティポリシー非依存ＴＬＶは、ＩＥＥＥ８０２．２１ｄＴＬＶのうち、ＳＡＩＤＴＬＶ、ＳｅｃｕｒｉｔｙＴＬＶ及びＳｉｇｎａｔｕｒｅＴＬＶ以外のＴＬＶである。

図１４は、第１の実施形態に係るＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１４に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０の識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、ユニキャストの場合、参加ノードの識別子、又は、コーディネータ２０と参加ノードとの間の個別通信用グループの識別子である。また、ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、マルチキャストの場合、ＨＡＮグループの識別子である。ＴａｒｇｅｔＩｄｅｎｔｉｆｉｅｒは、グループ識別子であり、個別通信用グループ又はアプリケーションシステムグループの場合はＬｅａｆＩＤを使用する。

ＲｅｓｐｏｎｓｅＦｌａｇは、応答要求フラグであり、値「１」を指定する。ＧｒｏｕｐＫｅｙＤａｔａは、暗号化されたグループ鍵であり、空のＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅが指定される場合、ＧｒｏｕｐＫｅｙＤａｔａ及びＳＡＩＤＮｏｔｉｆｉｃａｔｉｏｎは不要である。ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅは、ＧｒｏｕｐＫｅｙＤａｔａの復号に使用されるＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅデータである。ＳｅｑｕｅｎｃｅＮｕｍｂｅｒは、暗号通信時の送信パケットのＡＥＳ−ＣＣＭＮｏｎｃｅフィールドのＳｅｑｕｅｎｃｅＮｕｍｂｅｒ部の初期値である。ＴａｒｇｅｔＡｄｄｒｅｓｓは、個別通信用グループの場合にメッセージに含まれ、参加ノードに対する通信ピアノードのＩＰアドレスを指定する。ＳＡＩＤＮｏｔｉｆｉｃａｔｉｏｎは、ＧｒｏｕｐＫｅｙＤａｔａに対応するＳＡＩＤを指定する。

図１５は、第１の実施形態に係るＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１５に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、参加ノードの識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０の識別子、又は、コーディネータ２０と参加ノードとの間の個別通信用グループ識別子である。ＴａｒｇｅｔＩｄｅｎｔｉｆｉｅｒは、グループ識別子であり、個別通信用グループ又はアプリケーションシステムグループの場合はＬｅａｆＩＤを使用する。ＧｒｏｕｐＳｔａｔｕｓは、グループ操作結果であり、Ｊｏｉｎｏｐｅｒａｔｉｏｎｓｕｃｃｅｓｓｆｕｌ（値「０」）を指定する。

図１６は、第１の実施形態に係るＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１６に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、参加ノードの識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０と参加ノードとの間の個別通信用グループ識別子、又は、コーディネータ２０の個別ノード識別子である。ＴａｒｇｅｔＩｄｅｎｔｉｆｉｅｒは、グループ識別子であり、個別通信用グループの場合はＬｅａｆＩＤ以外の識別子を指定する。ＧｒｏｕｐＡｃｔｉｏｎは、グループ操作種別であり、Ｊｏｉｎｔｈｅｇｒｏｕｐ（値「０」）を指定する。

図１７は、第１の実施形態に係るＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１７に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０の識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０と参加ノードとの間の個別通信用グループ識別子、又は、参加ノードの個別ノード識別子である。ＴａｒｇｅｔＩｄｅｎｔｉｆｉｅｒは、グループ識別子であり、個別通信用グループ又はアプリケーションシステムグループの場合はＬｅａｆＩＤを使用する。ＧｒｏｕｐＫｅｙＤａｔａは、暗号化されたグループ鍵である。ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅは、ＧｒｏｕｐＫｅｙＤａｔａの復号に使用されるＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅデータである。ＳｅｑｕｅｎｃｅＮｕｍｂｅｒは、暗号通信時の送信パケットのＡＥＳ−ＣＣＭＮｏｎｃｅフィールドのＳｅｑｕｅｎｃｅＮｕｍｂｅｒ部の初期値である。ＳＡＩＤＮｏｔｉｆｉｃａｔｉｏｎは、ＧｒｏｕｐＫｅｙＤａｔａに対応するＳＡＩＤを指定する。

図１８は、第１の実施形態に係るＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１８に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、参加ノードの識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、ユニキャストの場合、コーディネータ２０と参加ノードとの間の個別通信用グループの識別子である。また、ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、マルチキャストの場合、ＨＡＮグループの識別子である。Ｃｅｒｔｉｆｉｃａｔｅは、参加ノードと暗号通信を行なう通信ピアノードのＸ．５０９証明書である。

図１９は、第１の実施形態に係るＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図１９に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０の識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０と参加ノードとの間の個別通信用グループの識別子である。ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒは、ＨＩＭ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージにより配布されたＸ．５０９証明書のシリアル番号である。ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓは、配布された証明書のステータスであり、証明書が有効である場合にはＣｅｒｔｉｆｉｃａｔｅＶａｌｉｄ（値「０」）が入る。

図２０は、第１の実施形態に係るＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅｉｎｄｉｃａｔｉｏｎメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図２０に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、送信元ノードの識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、宛先識別子であり、ユニキャスト暗号通信の場合には個別通信用グループの識別子が使用される。ここで、個別通信用グループの識別子は、ＩＤｘ＋‘＠’＋ＩＤｙ（Ｌ）、又は、ＩＤｙ＋‘＠’＋ＩＤｘ（Ｌ）である。また、ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、マルチキャスト暗号通信の場合、アプリケーションシステムグループ使用時にはアプリケーションシステムグループの識別子（‘＠’＋ＩＤｃｔｌ（Ｌ））が使用され、それ以外のグループ使用時にはＨＡＮグループの識別子（“”）が使用される。ＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａには、コーディネータ２０からの同期カウンタ更新通知に使用される場合Ｎｕｌｌとなり、それ以外はアプリケーション種別（ＵＤＰポート番号など）、及び、アプリケーションメッセージ（ＥＣＨＯＮＥＴ−Ｌｉｔｅ電文など）が含まれる。

図２１は、第１の実施形態に係るＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図２１に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０の識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、ユニキャストの場合、コーディネータ２０と参加ノードとの間の個別通信用グループの識別子である。また、ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、マルチキャストの場合、ＨＡＮグループの識別子である。ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒは、リボークされる証明書のシリアル番号である。ＣｅｒｔｉｆｉｃａｔｅＲｅｖｏｃａｔｉｏｎは、リボークされる証明書の発行元のデジタル署名である。

図２２は、第１の実施形態に係るＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージに含まれるセキュリティポリシー非依存ＴＬＶの例を示す図である。図２２に示すように、ＳｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒは、参加ノードの識別子である。ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｆｉｅｒは、コーディネータ２０と参加ノードとの間の個別通信用グループの識別子である。ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒは、リボークされる証明書のシリアル番号である。ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓは、リボークされる証明書のステータスであり、リボーク成功の場合にはＣｅｒｔｉｆｉｃａｔｅＶａｌｉｄ（値「１」）を設定する。

次に、本実施形態に係る鍵共有、暗号通信、証明書リボーク、鍵更新についての詳細シーケンスを説明する。

［鍵共有フェーズ１の詳細シーケンス］
図２３は、第１の実施形態に係る鍵共有フェーズ１Ａの詳細シーケンスの例である。図２３では、ＩＤｃｔｌはコントローラ３０の識別子、ＩＤｃｄｎはコーディネータ２０の識別子、ＩＤｄｅｖは機器４０の識別子を表す。また、図２３に示す（１）〜（４）は、図１０に示した（１）〜（４）に相当する。

図２３の（１）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｄｎ，ｃｔｌ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳｅｑｕｅｎｃｅＮｕｍ，ＳＡＩＤＮｏｔｉｆ，Ｓｉｇｎａｔｕｒｅ」が含まれる。また、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｃｄｎ（Ｌ），ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ，Ｓｉｇｎａｔｕｒｅ」が含まれる。

図２３の（２）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ１），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝“”，ＳｅｑｕｅｎｃｅＮｕｍ，ＳＡＩＤＮｏｔｉｆ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝“”，ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。

図２３の（３）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ２），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝“Ｃｏｎｔｒｏｌｌｅｒｓ”，ＳｅｑｕｅｎｃｅＮｕｍ，ＳＡＩＤＮｏｔｉｆ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝“Ｃｏｎｔｒｏｌｌｅｒｓ”，ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。

図２３の（４）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ），ＣｏｍｐｕｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。

なお、鍵共有フェーズ１Ａにおいては、図２３の（１）に先立ち、コントローラ３０からコーディネータ２０に対し、ＩＥＥＥ８０２．２１‐２００８で規定されるＭＩＨＲｅｇｉｓｔｒａｔｉｏｎが行なわれるかもしれない。

図２４は、第１の実施形態に係る鍵共有フェーズ１Ｂの詳細シーケンスの例である。図２４では、ＩＤｃｔｌはコントローラ３０の識別子、ＩＤｃｄｎはコーディネータ２０の識別子、ＩＤｄｅｖは機器４０の識別子を表す。また、図２４に示す（５）及び（６）は、図１０に示した（５）及び（６）に相当する。

図２４の（５）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ（Ｌ），ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｄｎ，ｄｅｖ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳｅｑｕｅｎｃｅＮｕｍ，ＳＡＩＤＮｏｔｉｆ，Ｓｉｇｎａｔｕｒｅ」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｃｄｎ（Ｌ），ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ，Ｓｉｇｎａｔｕｒｅ」が含まれる。

図２４の（６）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ１），ＣｏｍｐｌｅｔｅＳｕｂｔｕｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝“”，ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝“”，ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。

なお、鍵共有フェーズ１Ｂにおいては、図２４の（５）に先立ち、機器４０からコーディネータ２０に対し、ＩＥＥＥ８０２．２１‐２００８で規定されるＭＩＨＲｅｇｉｓｔｒａｔｉｏｎが行なわれるかもしれない。

［鍵共有フェーズ２の詳細シーケンス］
図２５は、第１の実施形態に係る鍵共有フェーズ２の詳細シーケンスの例である。図２５では、フェーズ２Ａがフェーズ２Ｂよりも先行する場合を例に挙げる。図２５では、ＩＤｃｔｌはコントローラ３０の識別子、ＩＤｃｄｎはコーディネータ２０の識別子、ＩＤｄｅｖは機器４０の識別子を表す。また、図２５に示す（７）〜（１１）は、図１０に示した（７）〜（１１）に相当する。

図２５の（７）に示すように、コントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（ＥｏｒＳ），ＧｒｏｕｐＡｃｔｉｏｎ＝ｊｏｉｎ｝」が含まれる。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信したコーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ，ｄｅｖ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ，ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。

図２５の（８）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛Ｃｅｒｔｉｆｉｃａｔｅ（ＣＥＲＴｄｅｖ）｝」が含まれる。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒ，ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ｝」が含まれる。

図２５の（９）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ，ｄｅｖ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＡｄｄｒ＝ＩＰｃｔｌ，ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。

図２５の（１０）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。

図２５の（１１）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛Ｃｅｒｔｉｆｉｃａｔｅ（ＣＥＲＴｃｔｌ）｝」が含まれる。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒ，ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ｝」が含まれる。

なお、鍵共有フェーズ２Ｂをコントローラ３０間通信の鍵共有に使用する場合、鍵共有フェーズ２Ｂの機器４０（ＩＤｄｅｖ）は、鍵共有フェーズ２Ａのコントローラ３０（ＩＤｃｔｌ）の通信相手のコントローラ３０（ＩＤｃｔｌ’）に置き換えられ、（７）が省略される。また、鍵共有フェーズ２Ａを機器４０間通信の鍵共有に使用する場合、鍵共有フェーズ２Ａのコントローラ３０（ＩＤｃｔｌ）は、鍵共有フェーズ２Ｂの機器４０（ＩＤｄｅｖ）の通信相手の機器４０（ＩＤｄｅｖ’）に置き換えられ、（７）が省略される。

図２６は、第１の実施形態に係る鍵共有フェーズ２の詳細シーケンスの例である。図２６では、フェーズ２Ｂがフェーズ２Ａよりも先行する場合を例に挙げる。図２６では、ＩＤｃｔｌはコントローラ３０の識別子、ＩＤｃｄｎはコーディネータ２０の識別子、ＩＤｄｅｖは機器４０の識別子を表す。また、図２６に示す（７）〜（１１）は、図１０に示した（７）〜（１１）に相当する。

図２６の（９）に示すように、機器４０は、コーディネータ２０に対して、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（ＥｏｒＳ），ＧｒｏｕｐＡｃｔｉｏｎ＝ｊｏｉｎ｝」が含まれる。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信したコーディネータ２０は、機器４０に対して、ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿ＭＮ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ，ｄｅｖ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ，ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。

図２６の（１０）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。

図２６の（１１）に示すように、コーディネータ２０は、機器４０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｄｅｖ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛Ｃｅｒｔｉｆｉｃａｔｅ（ＣＥＲＴｃｔｌ）｝」が含まれる。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージを受信した機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｄｅｖ（Ｌ），ｄｓｔ＝ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒ，ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ｝」が含まれる。

図２６の（７）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＧｒｏｕｐＫｅｙＤａｔａ（Ｋ＿ｃｔｌ，ｄｅｖ），ＣｏｍｐｌｅｔｅＳｕｂｔｒｅｅ，ＲｅｓｐｏｎｓｅＦｌａｇ＝１，ＴａｒｇｅｔＡｄｄｒ＝ＩＰｄｅｖ，ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＳＡＩＤＮｏｔｉｆ，ＳｅｑｕｅｎｃｅＮｕｍ｝」が含まれる。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ＠ｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＴａｒｇｅｔＩＤ＝ＩＤｄｅｖ＠ＩＤｃｔｌ（Ｌ），ＧｒｏｕｐＳｔａｔｕｓ｝」が含まれる。

図２６の（８）に示すように、コーディネータ２０は、コントローラ３０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージには、「ｓｒｃ＝ＩＤｃｄｎ（Ｌ），ｄｓｔ＝ＩＤｃｔｌ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛Ｃｅｒｔｉｆｉｃａｔｅ（ＣＥＲＴｄｅｖ）｝」が含まれる。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージを受信したコントローラ３０は、コーディネータ２０に対して、ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。ＭＩＨ＿Ｐｕｓｈ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージには、「ｓｒｃ＝ＩＤｃｔｌ（Ｌ），ｄｓｔ＝ＩＤｃｄｎ（Ｌ），ＳＡＩＤ，Ｓｅｃｕｒｉｔｙ｛ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒ，ＣｅｒｔｉｆｉｃａｔｅＳｔａｔｕｓ｝」が含まれる。

［暗号通信の詳細シーケンス］
図２７は、第１の実施形態に係る暗号通信の詳細シーケンスの例である。図２７において、ｇｉｄはグループ識別子であり、アプリケーションシステムグループの場合「ｇｉｄ＝＠ＩＤｃｔｌ（Ｌ）」、アプリケーションシステムグループ以外の場合「ｇｉｄ＝“”」である。図２７に示すように、コントローラ３０又は機器４０は、ユニキャスト暗号通信とマルチキャスト暗号通信において、コントローラ３０又は機器４０に対して、ＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅｉｎｄｉｃａｔｉｏｎメッセージを送受信する。ＭＩＨ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｕｐｄａｔｅｉｎｄｉｃａｔｉｏｎメッセージの送受信は、コントローラ３０又は機器４０（ＩＤｘ）と、コントローラ３０又は機器４０（ＩＤｙ）とにより行なわれる。

［証明書リボークの詳細シーケンス］
図２８は、第１の実施形態に係る証明書リボークの詳細シーケンスの例である。図２８に示すように、コーディネータ２０は、コントローラ３０又は機器４０に対して、マルチキャスト又はユニキャストにより、ＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｑｕｅｓｔメッセージを送信する。これにより、コントローラ３０又は機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｒｅｖｏｋｅ＿Ｃｅｒｔｉｆｉｃａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。

［グループ鍵更新の詳細シーケンス］
図２９は、第１の実施形態に係るグループ鍵更新の詳細シーケンスの例である。図２９に示すように、コーディネータ２０は、コントローラ３０又は機器４０に対して、マルチキャスト又はユニキャストにより、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｑｕｅｓｔメッセージを送信する。これにより、コントローラ３０又は機器４０は、コーディネータ２０に対して、ＭＩＨ＿Ｎｅｔ＿Ｇｒｏｕｐ＿Ｍａｎｉｐｕｌａｔｅｒｅｓｐｏｎｓｅメッセージを送信する。

本実施形態によれば、グループ識別子の構造に、グループのセマンティックを表し、且つ、グループの存命中は値が不変である可変値のフィールドを含むパケットをグループで送受するので、セマンティックの自由度を向上させるとともに、通信を簡素化することができる。

また、本実施形態によれば、個別通信用グループに対応するグループ鍵による認証コードが付与された、署名なしのグループ操作コマンド用メッセージを用いて、グループ操作を制御するので、処理負荷を軽減することができる。

また、上記文書中や図面中等で示した処理手順、制御手順、具体的名称、各種のデータやパラメータ等を含む情報は、特記する場合を除いて任意に変更することができる。また、図示した制御装置の各構成要素は、機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散又は統合の具体的形態は、図示のものに限られず、その全部又は一部を各種の負担や使用状況等に応じて、任意の単位で機能的又は物理的に分散又は統合することができる。

また、上記実施形態に係る通信システム１０に含まれるコーディネータ２０やコントローラ３０、機器４０は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることで実現することが可能である。実行されるプログラムは、上述してきた各機能を含むモジュール構成となっている。プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録されて提供しても、ＲＯＭ等に予め組み込んで提供しても良い。

また、上述してきた実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。また、各実施形態は、内容を矛盾させない範囲で適宜組み合わせることが可能である。また、各実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０通信システム
２０コーディネータ
３０コントローラ
４０機器
２１０通信部
２２０判定部
２３０生成部
２４０更新部
２５０制御部

Claims

自装置のデジタル署名を含む第１操作コマンド用メッセージを用いて、２つの通信装置で構成される個別通信用グループに対応するグループ鍵を、前記通信装置に配布する配布部と、
前記グループ鍵による認証コードが付与された第２操作コマンド用メッセージを用いて、前記通信装置とのグループ操作を制御する制御部と
を有する通信制御装置。
前記個別通信用グループは、前記個別通信用グループ以外のグループとは異なる形式のグループ識別子により識別される請求項１に記載の通信制御装置。
前記個別通信用グループのグループ識別子は、前記個別通信用グループに属する２つの通信装置それぞれを識別する識別子を含む形式である請求項１に記載の通信制御装置。
前記制御部は、前記第２操作コマンド用メッセージとは異なる所定メッセージを用いる場合に、前記グループ鍵による認証コードを付与する請求項１に記載の通信制御装置。
単調増加する同期カウンタと、単調増加するパケットカウンタとを含むシーケンス番号を更新する更新部をさらに有し、
前記制御部は、前記同期カウンタを含む前記第２操作コマンド用メッセージを用いて、前記グループ操作を制御する請求項１〜４の何れか一つに記載の通信制御装置。
前記更新部は、前記同期カウンタを更新し、前記パケットカウンタを初期化することにより、前記シーケンス番号を更新する請求項５に記載の通信制御装置。
前記制御部は、前記デジタル署名を含まない前記第２操作コマンド用メッセージを用いて、前記通信装置とのグループ操作を制御する請求項１に記載の通信制御装置。
通信装置であって、
前記通信装置と他の通信装置とで構成される個別通信用グループに対応するグループ鍵を配布するための、通信制御装置のデジタル署名を含む第１操作コマンド用メッセージを前記通信制御装置から受信する第１受信部と、
前記通信装置が属するグループのグループ操作を制御するための、前記グループ鍵による認証コードが付与された第２操作コマンド用メッセージを前記通信制御装置から受信する第２受信部と
を有する通信装置。