JP6751894B2 - 認証方法およびコントローラ - Google Patents

Description

本開示は、ネットワークに接続されたコントローラと機器との間で相互認証を行い、グループ鍵を共有する技術に関する。

近年、ネットワーク接続機能を有する家電機器やＡＶ(Audio/Visual)機器、住宅設備機器などの機器類（以下、単に「機器」と呼ぶ。）からクラウド上のサーバに収集される各種履歴情報を用いたサービスが期待されている。

このようなサービスにおいて、家庭内に機器を制御するための機器（以下、「コントローラ」と呼ぶ。）を設置し、コントローラが、機器とクラウド上のサーバとの間の通信を中継することが考えられる。このとき、コントローラと機器との接続に関して、不正機器のなりすましや通信内容の傍受による情報漏えいなどを防止することが求められる。

不正機器のなりすましの対策として、例えば、公開鍵認証基盤（ＰＫＩ：Public Key Infrastructure）を用いたコントローラや機器の正当性の認証が行われる。また、情報漏えいの対策として、例えば、正当性が認証されたコントローラと機器とで暗号通信用の鍵を共有して暗号通信が行われる。

ここで、コントローラと接続する機器が複数存在する場合、コントローラと各機器とが同一の暗号通信用の鍵（以下、「グループ鍵」と呼ぶ。）を共有することで、コントローラが各機器に対して同一情報を一斉送信するマルチキャスト通信やブロードキャスト通信の暗号化が可能になる。

特許第４５７６９９７号公報

Federal Information Processing Standards Publication (FIPS PUB) 186-4: Digital Signature Standard (DSS), National Institute of Standards and Technology (NIST), July 2013 NIST Special Publication 800-56A Revision 2: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, National Institute of Standards and Technology (NIST), May 2013 IETF: RFC5191: Protocol for Carrying Authentication for Network Access (PANA), Internet Engineering Task Force (IETF), May 2008 IETF: RFC6347: Datagram Transport Layer Security Version 1.2, Internet Engineering Task Force (IETF), January 2008

本開示に係る認証方法は、ネットワーク上の１以上の機器と２以上のコントローラとが所属するグループにおける認証方法であって、前記グループ内の少なくとも１つのコントローラが、前記グループ内で共通で利用するグループ鍵を管理するコーディネータを、前記グループ内のコントローラの中から各コントローラの属性に応じて決定し、前記コーディネータが、グループ鍵を生成し、前記グループ内の機器およびコントローラと相互認証を実行し、認証に成功した機器およびコントローラと前記生成したグループ鍵を共有することを特徴とする。

本開示によれば、ネットワーク上のグループ内に複数のコントローラが存在する場合において、グループ内で共通で利用するグループ鍵を管理するコーディネータとして、適切なコントローラを選択することができる。

図１は、認証システムの一例を示す図である。 図２は、ＨＡＮ(Home Area Network)内のグループ構成の一例を示す図である。 図３は、統合後のグループ構成の一例を示す図である。 図４は、コントローラの機能構成の一例を示す図である。 図５Ａは、コントローラの保持する接続機器管理テーブルの一例を示す図である。 図５Ｂは、コントローラの保持するグループに関する情報の一例を示す図である。 図６は、公開鍵証明書の一例を示す図である。 図７は、ＣＲＬ(Certificate Revocation List)の一例を示す図である。 図８は、機器の機能構成の一例を示す図である。 図９Ａは、機器の保持する接続コントローラ管理テーブルの一例を示す図である。 図９Ｂは、機器の保持するグループに関する情報の一例を示す図である。 図１０は、機器登録時の認証システムの動作の一例を示すシーケンス図である。 図１１は、コントローラ参入時の認証システムの動作の一例を示すシーケンス図である。 図１２は、ネゴシエート処理の一例を示すシーケンス図である。 図１３は、ＳＣ（Security Coordinator）引継処理の一例を示すシーケンス図である。 図１４は、相互認証処理の一例を示すシーケンス図である。 図１５は、共通鍵を計算する処理の一例を示すシーケンス図である。 図１６は、グループ鍵配信・受信処理の一例を示すシーケンス図である。 図１７は、グループ鍵更新処理の一例を示すシーケンス図である。 図１８は、グループ鍵更新処理の一例を示すシーケンス図である。 図１９Ａは、グループ統合前のコントローラＡの保持する接続機器管理テーブルを示す図である。 図１９Ｂは、グループ統合前のコントローラＡの保持するグループに関する情報を示す図である。 図１９Ｃは、グループ統合前のコントローラＢの保持する接続機器管理テーブルを示す図である。 図１９Ｄは、グループ統合前のコントローラＢの保持するグループに関する情報を示す図である。 図２０Ａは、グループ統合前の機器Ａの保持する接続コントローラ管理テーブルを示す図である。 図２０Ｂは、グループ統合前の機器Ａの保持するグループに関する情報を示す図である。 図２０Ｃは、グループ統合前の機器Ｂの保持する接続コントローラ管理テーブルを示す図である。 図２０Ｄは、グループ統合前の機器Ｂの保持するグループに関する情報を示す図である。 図２１Ａは、グループ統合後のコントローラＡの保持する接続機器管理テーブルを示す図である。 図２１Ｂは、グループ統合後のコントローラＡの保持するグループに関する情報を示す図である。 図２１Ｃは、グループ統合後のコントローラＢの保持する接続機器管理テーブルを示す図である。 図２１Ｄは、グループ統合後のコントローラＢの保持するグループに関する情報を示す図である。 図２２Ａは、グループ統合後の機器Ａの保持する接続コントローラ管理テーブルを示す図である。 図２２Ｂは、グループ統合後の機器Ａの保持するグループに関する情報を示す図である。 図２２Ｃは、グループ統合後の機器Ｂの保持する接続コントローラ管理テーブルを示す図である。 図２２Ｄは、グループ統合後の機器Ｂの保持するグループに関する情報を示す図である。 図２３は、機器履歴情報の送信処理の一例を示すシーケンス図である。 図２４は、制御コマンドの送信処理の一例を示すシーケンス図である。 図２５は、ＳＣ引継処理の一例を示すシーケンス図である。 図２６は、ＳＣ選択画面の一例を示す図である。

（本開示に至る経緯）
ＨＡＮ(Home Area Network)などのネットワークにおいて、同一の機器を複数のコントローラが制御する状況が想定される。

このような状況では、各コントローラが個別にグループ鍵を生成して機器に配信し、機器はコントローラ毎に異なるグループ鍵を用いた暗号通信を行うことが想定される。しかしながら、機器によっては、複数のグループ鍵を用いた暗号通信のために必要なリソースを割り当てることができない可能性がある。例えば、機器の演算性能が低く、複数のグループ鍵を用いた暗号通信ができない可能性がある。また、機器の記憶容量が少ない場合には、すべてのコントローラとの暗号通信に必要な数のグループ鍵を記憶できない可能性がある。

そこで、ネットワーク上の一部または全部の機器及びコントローラがグループを構成し、グループ内のコントローラの中からグループ鍵を管理するコントローラを決めて、決定されたコントローラがグループ鍵を生成してグループ内の機器及び他のコントローラに配信する構成が考えられる。しかしながら、この構成では、どのコントローラがグループ鍵を管理するかが問題となる。例えば、コントローラによっては、電源断やネットワーク未接続状態が頻繁に起こり、機器や他のコントローラと常時通信できないものが存在する。グループ鍵を管理するコントローラをランダムに決めてしまうと、このようなコントローラが選ばれてしまう可能性がある。グループ鍵を管理するコントローラと通信できない状態では、新たな機器やコントローラがグループに参入しグループ鍵を共有することができない。また、セキュリティ上の観点からグループ鍵を定期的に更新することが望まれるが、グループ鍵を管理するコントローラと通信できない状態では、グループ鍵の更新ができない。従来の認証システムでは、グループ鍵に関して更なる改善が必要とされている。

本開示は、係る問題を鑑みてなされたものであり、ネットワーク上のグループ内に複数のコントローラが存在する場合において、グループ内で共通で利用するグループ鍵を管理するコントローラとして、適切なコントローラを決定する認証方法を提供するものである。

（実施の形態１）
以下、図面を参照しながら、本開示の実施の形態に係る認証システムについて説明する。なお、本実施の形態で示される数値、形状、材料、構成要素、構成要素の配置および接続形態、ステップ、ステップの順序などは一例であり、本開示を限定する主旨ではない。

＜概要＞
ここでは、本開示の一実施形態としての認証システム１００の概要について説明する。

図１は、認証システム１００の構成を示す図である。認証システム１００は、ＨＡＮ１３０上のコントローラ１１０（コントローラ１１０ａ及びコントローラ１１０ｂ）及び機器１２０（機器１２０ａ、１２０ｂ及び１２０ｃ）から構成される。また、コントローラ１１０は、ネットワーク１５０を介してサーバ１４０（サーバ１４０ａ及びサーバ１４０ｂ）と接続される。

機器１２０は、ネットワークに接続する機能を有する家電機器やＡＶ機器及び住宅設備機器であり、例えば、テレビ、レコーダ、エアコン、冷蔵庫、蓄電池などである。コントローラ１１０は、機器１２０を制御する機能を有する機器であり、例えばサーバ１４０からの依頼等に応じて制御コマンドを生成し、生成した制御コマンドを機器１２０に送信して実行させる。また、コントローラ１１０は、機器１２０に蓄積された情報をサーバ１４０に送信する機能も有する。なお、コントローラ１１０は、ペアリングを行って登録された機器１２０の制御を行い、機器１２０は、ペアリングを行って登録されたコントローラ１１０から送信された制御コマンドを実行する。

ＨＡＮ１３０は、家庭内に構築された有線又は無線のネットワークである。ＨＡＮ１３０は、具体的には、Ｅｔｈｅｒｎｅｔ（登録商標）、特定小電力無線、Ｗｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、電力線通信などで実現される。また、ネットワーク１５０は、家庭と企業との間等に構築された、所謂インターネット等のネットワークである。

認証システム１００では、ＨＡＮ１３０上の１以上のコントローラ１１０と、該１以上のコントローラ１１０とペアリングを行った１以上の機器１２０とで一つのグループ鍵を共有する１つのグループが形成される。グループ鍵は、コントローラ１１０が生成し、コントローラ１１０と機器１２０とが認証処理を行ったとき等に、コントローラ１１０から機器１２０へ配信される。

図２は、ＨＡＮ１３０上のコントローラ１１０及び機器１２０のグループ構成の一例を示す図である。図２は、コントローラＡと機器Ａとが所属するグループ２００及びコントローラＢと機器Ｂとが所属するグループ２１０を示している。グループ２００とグループ２１０とでは、異なるグループ鍵が共有される。これにより、グループ２００とグループ２１０が同じ通信方式を利用していたとしても、互いのグループ内で通信している内容がグループ外に漏洩することがなくなる。

認証システム１００では、異なるグループに所属する機器やコントローラの間でペアリングが発生すると、２つのグループの統合を行う。例えば、グループ構成が図２に示す状態で、機器ＡとコントローラＢとでペアリングが行われた場合、グループ構成が図３に示すように変更される。このとき、認証システム１００では、認証処理やグループ鍵の管理処理を行うコントローラを一つ決定し、決定されたコントローラがグループ鍵の生成及び配信を担う。本開示では、認証処理やグループ鍵の管理処理を行うコントローラのことをＳＣ(Security Coordinator)と呼ぶ。なお、ＳＣ以外の機器やコントローラのことをノードと呼ぶ場合がある。図３の例では、ＳＣとして、コントローラＡが決定されている。すなわち、グループ３００では、各機器との認証処理やグループ鍵の生成や配信はＳＣであるコントローラＡのみが行い、コントローラＢは行わない。そして、コントローラＢは、ＳＣであるコントローラＡが生成し配信したグループ鍵を用いて、ペアリングを行った機器Ａ及び機器Ｂの制御を行うことになる。

＜構成＞
次に、認証システム１００の主要な構成要素であるコントローラ１１０及び機器１２０の構成について説明する。

＜コントローラの構成＞
まず、図４−７を参照して、コントローラ１１０の構成を説明する。

図４は、コントローラ１１０の機能構成を示す図である。コントローラ１１０は、機器管理部４１０、機器情報保持部４２０、認証処理部４３０、認証情報保持部４４０、ネゴシエート部４５０、操作部４６０、通信部４７０を含んで構成される。

機器管理部４１０は、自機（コントローラ１１０）に接続される機器１２０や他のコントローラ１１０を管理する。機器管理部４１０は、通信部４７０を介した機器１２０や他のコントローラ１１０からのペアリング要求や相互認証要求、機器情報保持部４２０からのグループ鍵更新要求などを受け付け、認証処理部４３０などに、要求に応じた処理を依頼し、依頼結果に応じて機器情報保持部４２０で保持する接続機器管理テーブル５００やグループに関する情報５１０を更新する機能を有する。

図５Ａは、機器情報保持部４２０が保持する接続機器管理テーブル５００の一例を示す図である。図５Ｂは、機器情報保持部４２０が保持するグループに関する情報５１０の一例を示す図である。

接続機器管理テーブル５００には、自機（コントローラ１１０）と接続する機器１２０（又は他のコントローラ１１０）毎に、機器ＩＤ５０１、証明書ＩＤ５０２、共有鍵５０３、グループ鍵５０４、グループ鍵有効時間５０５、グループ鍵更新フラグ５０６が記録される。機器ＩＤ５０１は、機器１２０を一意に識別するための情報である。証明書ＩＤ５０２は、機器１２０が持つ公開鍵証明書の証明書ＩＤである。共有鍵５０３は、機器１２０との間で共有される共有鍵のデータである。グループ鍵５０４は、機器１２０に設定されているグループ鍵のデータである。グループ鍵有効時間５０５は、機器１２０に設定されているグループ鍵の有効期間の残余時間である。グループ鍵更新フラグ５０６は、機器１２０のグループ鍵が最新のものに更新されているか否かを示すフラグ情報である。

グループに関する情報５１０には、制御機器５１１、ＳＣ５１２、傘下の機器５１３が記録される。制御機器５１１は、ペアリングを行った機器１２０の機器ＩＤである。ＳＣ５１２は、所属しているグループのＳＣの機器ＩＤである。なお、コントローラ１１０のＳＣ５１２は、コントローラ１１０の出荷時には、自機の機器ＩＤを示す値が設定されているものとする。傘下の機器５１３は、自らがＳＣの場合におけるグループに所属している機器１２０及び他のコントローラ１１０の機器ＩＤである。

機器情報保持部４２０は、時間の経過と共にグループ鍵有効時間５０５の値をカウントダウンさせ、グループ鍵有効時間５０５の値が所定値以下となった場合に機器管理部４１０に、グループ鍵更新要求を行う機能を有する。所定値とは、例えば、最初に設定された値の１０％の値や、グループ鍵の更新に必要な時間の２倍の値などである。

図４に戻り、コントローラ１１０の構成について説明を続ける。

認証処理部４３０は、機器管理部４１０からの依頼に応じて、機器１２０や他のコントローラ１１０との認証処理を行う機能を有する。認証処理部４３０の行う認証処理の詳細は後述する。

認証情報保持部４４０は、自機（コントローラ１１０）の秘密鍵と公開鍵証明書を保持している。また、認証情報保持部４４０は、相手機器の公開鍵証明書が失効していないことを確認するために使用するＣＲＬ（Certificate Revocation List）や、認証局の公開鍵が含まれるデジタル証明書を保持している。なお、秘密鍵と公開鍵証明書との鍵ペアやＣＲＬやデジタル証明書はコントローラ１１０の出荷時に埋め込まれるものとする。

図６は、認証情報保持部４４０の保持する公開鍵証明書６００のデータ構成の一例を示す図である。公開鍵証明書６００は、例えば、バージョン６１０、証明書ＩＤ６２０、署名６３０、発行者６４０、有効期間の開始６５０、有効期間の終了６６０、公開鍵６７０、属性６８０のデータで構成される。

図７は、認証情報保持部４４０の保持するＣＲＬ７００のデータ構成の一例を示している。ＣＲＬ７００は、例えば、バージョン７１０、署名７２０、発行者７３０、発行日時７４０、次回発行日７５０、失効した証明書ＩＤのデータで構成される。

図４に戻り、コントローラ１１０の構成について説明を続ける。

ネゴシエート部４５０は、１つのグループ内に複数のコントローラ１１０が存在する場合、例えば、異なるグループに属する機器間でペアリングが発生したとき等に、他のコントローラ１１０と通信をし合い、どのコントローラがＳＣになるかを決定するネゴシエート処理を行う。ネゴシエート部４５０の行うネゴシエート処理の詳細については後述する。

機器管理部４１０、機器情報保持部４２０、認証処理部４３０、認証情報保持部４４０ネゴシエート部４５０の各機能部は、典型的には、メモリに保持されているプログラムをプロセッサが実行することにより実現される。

操作部４６０は、ペアリング用のボタンと、当該ボタンの押下に応じて割り込み信号を生成してプロセッサに伝えるための制御回路とで構成される。

通信部４７０は、通信機能を有する通信用ＬＳＩ（Large Scale Integration）によって実現される。通信部４７０は、ＨＡＮ１３０とネットワーク１５０とに接続され、ＨＡＮ１３０を介してＨＡＮ１３０に接続される機器１２０や他のコントローラ１１０と通信する機能と、ネットワーク１５０を介してサーバ１４０と通信する機能とを有する。なお、コントローラ１１０とネットワーク１５０との接続は、図示しないゲートウェイ機器を介して行われてもよい。

通信部４７０は、機器１２０や他のコントローラ１１０との通信には、認証処理部４３０から受信したグループ鍵などを用いて適宜暗号化通信を行う。また、通信部４７０は、サーバ１４０との通信には、ＳＳＬ（Secure Socket Layer）通信を行う。なお、ＳＳＬ通信に必要な証明書等は、通信部４７０が記憶している。

＜機器の構成＞
次に、図８−９を参照して、機器１２０の構成を説明する。

図８は、機器１２０の機能構成を示す図である。機器１２０は、機器管理部８１０、機器情報保持部８２０、認証処理部８３０、認証情報保持部８４０、機器履歴保持部８５０、操作部８６０、通信部８７０を含んで構成される。

機器管理部８１０は、自ら（機器１２０）に接続されるコントローラ１１０を管理する。機器管理部８１０は、操作部８６０からの割り込み信号をトリガとして登録モードを起動してコントローラ１１０へペアリング要求を送信する機能や認証処理部８３０などの処理結果に応じて機器情報保持部８２０で保持する接続コントローラ管理テーブル９００やグループに関する情報９１０を更新する機能を有する。また、機器管理部８１０は、機器履歴保持部８５０で記録している機器履歴情報をグループ鍵で暗号化して、定期的または非定期にコントローラ１１０経由でサーバ１４０へ送信する機能を有する。

図９Ａは、機器情報保持部８２０が保持する接続コントローラ管理テーブル９００の一例を示す図である。図９Ｂは、機器情報保持部８２０が保持するグループに関する情報９１０の一例を示す図である。

接続コントローラ管理テーブル９００には、自機（機器１２０）と接続するコントローラ１１０毎に、コントローラＩＤ９０１、証明書ＩＤ９０２、共有鍵９０３、グループ鍵９０４が記録される。コントローラＩＤ９０１は、コントローラ１１０を一意に識別するための情報である。証明書ＩＤ９０２は、コントローラ１１０が持つ公開鍵証明書の証明書ＩＤである。共有鍵９０３は、コントローラ１１０との間で共有される共有鍵のデータである。グループ鍵９０４は、コントローラ１１０から受信したグループ鍵のデータである。なお、共有鍵は、ＳＣとのみ共有を行うものであり、すべてのコントローラと共有するわけではない。

グループに関する情報９１０には、制御コントローラ９１１、ＳＣ９１２が記録される。制御コントローラ９１１は、ペアリングを行ったコントローラ１１０の機器ＩＤである。ＳＣ９１２は、所属しているグループのＳＣの機器ＩＤである。なお、機器１２０のＳＣ９１２は、機器１２０の出荷時には、ＳＣが登録されていないことを示す値が設定されているものとする。

図８に戻り、機器１２０の構成について説明を続ける。

認証処理部８３０は、コントローラ１１０との認証処理を行う機能を有する。認証処理部８３０の行う認証処理の詳細は後述する。

認証情報保持部８４０は、自機（機器１２０）の秘密鍵と公開鍵証明書を保持している。また、認証情報保持部８４０は、ＣＲＬ（Certificate Revocation List）や、認証局の公開鍵が含まれるデジタル証明書を保持している。公開鍵証明書やＣＲＬはコントローラ１１０が持つ公開鍵証明書やＣＲＬと同じ構成であるのでここでの説明は省略する。なお、秘密鍵と公開鍵証明書の鍵ペアやＣＲＬやデジタル証明書は機器１２０の出荷時に埋め込まれるものとする。

機器履歴保持部８５０は、自機（機器１２０）の動作履歴を示す機器履歴情報を保持している。

機器管理部８１０、機器情報保持部８２０、認証処理部８３０、認証情報保持部８４０、機器履歴保持部８５０の各機能部は、典型的には、メモリに保持されているプログラムをプロセッサが実行することにより実現される。

操作部８６０は、ペアリング用のボタンと、当該ボタンの押下に応じて割り込み信号を生成してプロセッサに伝えるための制御回路とで構成される。

通信部８７０は、通信機能を有する通信用ＬＳＩ（Large Scale Integration）によって実現される。通信部８７０は、ＨＡＮ１３０に接続され、ＨＡＮ１３０を介してＨＡＮ１３０に接続されるコントローラ１１０と通信する機能を有する。

通信部８７０は、コントローラ１１０との通信には、認証処理部８３０から受信したグループ鍵などを用いて適宜暗号化通信を行う。

＜動作＞
以下、認証システム１００で行う、機器登録処理、ネゴシエート処理、ＳＣ引継処理、相互認証処理、共有鍵計算処理、グループ鍵配信・受信処理、グループ鍵更新処理、機器履歴情報送信処理、制御コマンド送信処理について、順に説明する。

＜機器登録処理＞
機器登録処理は、コントローラと機器とがペアリングする際の処理である。以下、機器登録処理について、図１０を参照して説明する。なお、以下の説明において、機器ＡとコントローラＢが機器登録処理を行うものとする。

（Ｓ１０００）ユーザが、機器ＡとコントローラＢとが備えるペアリング用のボタンを押下する。これにより、機器ＡとコントローラＢとはそれぞれ登録モードを起動する。

（Ｓ１００５）機器ＡからコントローラＢに対し、接続要求を送信する。この時、機器Ａは、自機に設定されているＳＣの機器ＩＤも併せて送信する。なお、機器ＡにＳＣが設定されていない場合にはその旨を示す情報が送信される。

（Ｓ１０１０）コントローラＢは、自機に設定されているＳＣの機器ＩＤと、機器Ａから通知されたＳＣの機器ＩＤとからネゴシエート処理が必要か否かを判断する。認証システム１００では、機器ＡとコントローラＢとで互いに異なるコントローラがＳＣとして設定されていた場合に、ネゴシエート処理が必要となる。逆に、機器ＡにＳＣが設定されていない場合や、機器ＡとコントローラＢとで共通のコントローラがＳＣとして設定されている場合には、ネゴシエート処理を行う必要はない。

（Ｓ１０１５）ステップＳ１０１０において、ネゴシエート処理が必要と判断された場合、機器ＡにＳＣとして設定されているコントローラとコントローラＢにＳＣとして設定されているコントローラとの間でネゴシエート処理が行われる。

コントローラＢは、自機がネゴシエート処理を行う場合、ネゴシエート処理を行う相手のコントローラにネゴシエート依頼を送信し、ネゴシエート処理を開始する。コントローラＢは、自機がネゴシエート処理を行わない場合、ネゴシエート処理を行う２つのコントローラにネゴシエート依頼を送信する。ネゴシエート処理の詳細は後述する。

（Ｓ１０２０）コントローラＢは、機器Ａに対してＳＣの機器ＩＤを送信する。ステップＳ１０１０において、ネゴシエート処理が必要ないと判断した場合、コントローラＢは、自機に設定されているＳＣの機器ＩＤを通知する。ステップＳ１０１０において、ネゴシエート処理が必要と判断した場合、コントローラＢは、ネゴシエート処理の結果新たにＳＣとして決定されたコントローラの機器ＩＤを取得し、機器Ａに送信する。

（Ｓ１０２５）機器ＡおよびコントローラＢは、ＳＣとの間で認証が必要であるか否かを判断する。機器Ａは、ステップＳ１０２０でコントローラＢから通知された機器ＩＤと、機器Ａに現在ＳＣとして設定されているコントローラの機器ＩＤとが異なる場合、コントローラＢから通知されたＳＣの生成したグループ鍵を共有していない場合等に、認証が必要であると判断する。コントローラＢは、ステップＳ１０２０で機器Ａに送信した機器ＩＤと、コントローラＢに現在ＳＣとして登録されているコントローラの機器ＩＤとが異なる場合、機器Ａに通知したＳＣの生成したグループ鍵を共有していない場合等に、認証が必要であると判断する。

（Ｓ１０３０、Ｓ１０３５）ステップＳ１０２５で認証が必要と判断された場合、機器Ａ又はコントローラＢは、新たなＳＣとの間で後述する相互認証処理及びグループ鍵配信・受信処理を行う。

（Ｓ１０４０）相互認証処理及びグループ鍵配信・受信処理が正常に終了した場合、機器Ａ又はコントローラＢは、新たなＳＣの傘下に参入する処理を行う。機器Ａは、新たなＳＣの機器ＩＤを、機器情報保持部８２０の保持するグループに関する情報９１０のＳＣ９１２に設定する。又は、コントローラＢは、新たなＳＣの機器ＩＤを、機器情報保持部４２０の保持するグループに関する情報５１０のＳＣ５１２に設定する。そして、機器Ａ又はコントローラＢは、新たなＳＣに自機の機器ＩＤを送信し、ＳＣは、受信した機器ＩＤを機器情報保持部４２０の保持するグループに関する情報５１０の傘下の機器５１３に設定する。

（Ｓ１０４５）機器Ａ又はコントローラＢにおける相互認証処理及びグループ鍵配信・受信処理を正常に終了した場合、機器Ａは、コントローラＢに対して、ペアリング要求を送信する。このとき、機器Ａは、自機の機器ＩＤを併せて送信する。

（Ｓ１０５０）コントローラＢは、機器Ａからペアリング要求を受信すると、機器Ａのペアリングを行う。すなわち、コントローラＢは、機器Ａからペアリング要求と共に受信した機器ＩＤを、機器情報保持部４２０の保持するグループに関する情報５１０の制御機器５１１に設定する。

（Ｓ１０５５）コントローラＢは、機器Ａのペアリングを行うと、機器Ａに対して、ペアリング要求を送信する。このとき、コントローラＢは、自機の機器ＩＤを併せて送信する。

（Ｓ１０６０）機器Ａは、コントローラＢからペアリング要求を受信すると、コントローラＢのペアリングを行う。すなわち、機器Ａは、コントローラＢからペアリング要求と共に受信した機器ＩＤを、機器情報保持部８２０の保持するグループに関する情報９１０の制御コントローラ９１１に設定する。

（Ｓ１０６５）機器Ａ及びコントローラＢは、互いのペアリングが正常に終了すると、登録モードを終了し、機器ＡとコントローラＢとでペアリングが行われたことを、同じグループに所属する他の機器やコントローラに通知する。当該通知は、ステップＳ１０３５で共有したグループ鍵を用いて暗号化して、ブロードキャスト等で送信される。

以上が、機器ＡとコントローラＢとの間で行われる機器登録処理となる。

なお、コントローラＡとコントローラＢとの間で機器登録処理が行われる場合の処理を図１１に示す。コントローラＡとコントローラＢとの間で機器登録処理は、ステップＳ１０４５、Ｓ１０５０、Ｓ１０５５、Ｓ１０６０の処理を行わないことを除いて、機器ＡとコントローラＢとの機器登録処理と同じであり、説明を省略する。

＜ネゴシエート処理＞
ネゴシエート処理は、異なるグループに所属する機器やコントローラの間でペアリングが発生した場合に行われる、２つのグループを統合した後にいずれのコントローラがＳＣになるかを決定する処理である。以下、ネゴシエート処理について、図１２を参照して説明する。なお、以下では、コントローラＡとコントローラＢとがネゴシエート処理を行うものとする。

（Ｓ１２００）コントローラＡは、コントローラＢにネゴシエート要求を送信する。

（Ｓ１２０５）コントローラＡ及びコントローラＢは、後述する相互認証処理を行う。

（Ｓ１２１０）相互認証処理が正常に終了した場合、コントローラＡは、コントローラＡの公開鍵証明書と、相互認証処理で取得したコントローラＢの公開鍵証明書とから、コントローラの属性を取得する。

（Ｓ１２１５）コントローラＡは、コントローラＡの属性が「専用機器」であるか否かを判断する。コントローラＡの属性が「専用機器」である場合はステップＳ１２３５に進み、そうでない場合はステップＳ１２２０に進む。

（Ｓ１２２０）コントローラＡは、コントローラＢの属性が「専用機器」であるか否かを判断する。コントローラＢの属性が「専用機器」である場合はステップＳ１２４０に進み、そうでない場合はステップＳ１２２５に進む。

（Ｓ１２２５）コントローラＡは、コントローラＡの属性が「汎用機器」であるか否かを判断する。コントローラＡの属性が「汎用機器」である場合はステップＳ１２３５に進み、そうでない場合はステップＳ１２３０に進む。

（Ｓ１２３０）コントローラＡは、コントローラＢの属性が「汎用機器」であるか否かを判断する。コントローラＢの属性が「汎用機器」である場合はステップＳ１２４０に進み、そうでない場合はステップＳ１２３５に進む。

（Ｓ１２３５）コントローラＡは、コントローラＡをＳＣとして決定する。

（Ｓ１２４０）コントローラＡは、コントローラＢをＳＣとして決定する。

（Ｓ１２４５）コントローラＡは、ＳＣの選定結果をコントローラＢに通知する。

（Ｓ１２５０）コントローラＡ及びコントローラＢは、後述するＳＣ引継処理を行う。

以上が、ネゴシエート処理となる。

ネゴシート処理では、公開鍵証明書の項目内の属性のデータを参照して、コントローラが他の機器をコントロールする機能しか持たない「専用機器」であるか、他の機能も持つ「汎用機器」であるか、ＰＣやスマートフォン上で動作する「アプリ」であるかによって、ＳＣになる優先度を変えている。コントローラの属性「専用機器」であれば、どんなときでも迅速に処理が行えるように常に待機する機能を持っていることが考えられる。コントローラの属性が「汎用機器」であれば、家の中に誰もいなくなったときや、就寝中には電源が切られる可能性が考えられる。コントローラの属性が「アプリ」であれば、いつ電源が切られたり、ネットワークから外れたりするか分からない。このため、「専用機器」、「汎用機器」、「アプリ」の順番で、ＳＣになりやすいように優先度を付けている。また、ここでは、両者の属性が同じであった場合は、ネゴシエート処理を依頼した側のコントローラが優先的にＳＣになる場合を示しているが、ネゴシエート処理の依頼を受けた側のコントローラＢが優先的にＳＣになってもよい。

＜ＳＣ引継処理＞
ＳＣ引継処理は、ネゴシエート処理によって新たなＳＣが決定された後、今までＳＣであったコントローラが保持していた情報を、新たなＳＣへと譲渡する処理である。以下、ＳＣ引継処理について、図１３を参照して、説明する。なお、以下では、新たなにＳＣとなったコントローラＡ（新ＳＣ）と、今までＳＣであったコントローラＢ（旧ＳＣ）とがＳＣ引継処理を行うものとする。

（Ｓ１３００）新ＳＣおよび旧ＳＣは、後述するグループ鍵配信・受信処理を行う。ここでは、旧ＳＣの管理していたグループ鍵を、新ＳＣへ配信する。

（Ｓ１３０５）旧ＳＣは、傘下の機器の情報を新ＳＣへ送信する。具体的には、旧ＳＣのグループに関する情報５１０の傘下の機器５１３の機器それぞれについて、接続機器管理テーブル５００の機器ＩＤ５０１、証明書ＩＤ５０２、グループ鍵５０４、グループ鍵有効時間５０５のデータを送信する。このとき、旧ＳＣは、傘下の機器の公開鍵証明書も併せて送信する。なお、旧ＳＣは、新ＳＣにグループ鍵を送信する場合は、新ＳＣとの間で共有した共有鍵を用いて暗号化して送信する。

（Ｓ１３１０）旧ＳＣは、傘下の機器へ、ＳＣがコントローラＢからコントローラＡへと変更した旨を通知する。このとき、コントローラＡの機器ＩＤや公開鍵証明書も併せて送信する。

（Ｓ１３１５）旧ＳＣ傘下の機器は、旧ＳＣからＳＣの変更通知と機器ＩＤと公開鍵証明書を受信すると、コントローラＡをＳＣとして登録する。具体的には、旧ＳＣ傘下の機器は、受信したコントローラＡの機器ＩＤを、機器情報保持部８２０の保持するグループに関する情報９１０のＳＣ９１２に登録する。さらに、旧ＳＣ傘下の機器は、接続コントローラ管理テーブル９００に、受信したコントローラＡの機器ＩＤのレコードを追加する。

（Ｓ１３２０）新ＳＣは、ステップＳ１３００のグループ鍵配信・受信処理で受信したグループ鍵、ステップＳ１３０５で受信した機器の情報を用いて、機器情報保持部４２０で保持する接続機器管理テーブル５００及びグループに関する情報５１０を更新する。

（Ｓ１３２５）旧ＳＣは、新ＳＣであるコントローラＡをＳＣとして登録する。具体的には、旧ＳＣは、コントローラＡの機器ＩＤを、機器情報保持部４２０の保持するグループに関する情報５１０のＳＣ５１２に設定する。

（Ｓ１３３０）旧ＳＣ傘下の機器と新ＳＣは、後述の共有鍵計算処理を行う。なお、共有鍵計算処理のタイミングは、旧ＳＣ傘下の機器が新ＳＣをＳＣとして登録した直後に行ってもよいが、新ＳＣがグループ鍵を更新する前であればいつでもよい。

以上が、ＳＣ引継処理となる。

＜相互認証処理＞
次に、機器又はコントローラとコントローラとの間の相互認証処理について、図１４を参照して説明する。なお、以下では、機器とコントローラとの間の相互認証処理について、説明するが、コントローラとコントローラとの間の相互認証処理でも同様の処理を行う。

（Ｓ１４００）機器からコントローラへ、認証要求を送信する。このとき、機器は、自機の機器ＩＤ及び公開鍵証明書も併せて送信する。

（Ｓ１４０５）コントローラは、機器の公開鍵証明書の証明書ＩＤが、認証情報保持部４４０で保持するＣＲＬに記載されていないことを検証する。検証に失敗した場合、コントローラは、機器にエラーを通知して処理を終了する。

（Ｓ１４１０）コントローラは、証明書ＩＤがＣＲＬに記載されていないことを確認すると、機器の公開鍵証明書の署名を認証局の公開鍵を用いて検証する。検証に失敗した場合、コントローラは、機器にエラーを通知して処理を終了する。署名には、ＥＣＤＳＡ（Elliptic Curve Digital Signature Algorithm）ＲＳＡ、ＤＳＡ（Digital Signature Algorithm）等の一般的に用いられている方式を利用することが可能である。また、コントローラは、機器の公開鍵証明書の署名の検証に成功すると、接続機器管理テーブル５００に、新たなレコードを作成し、相互認証処理の相手となる機器の機器ＩＤ及び証明書ＩＤを登録する。

（Ｓ１４１５）コントローラは、機器の公開鍵証明書の署名の検証に成功すると、自機の機器ＩＤ及び公開鍵証明書を機器に送信する。

（Ｓ１４２０）機器は、コントローラの公開鍵証明書の証明書ＩＤが、認証情報保持部８４０で保持するＣＲＬに記載されていないことを検証する。検証に失敗した場合、機器は、コントローラにエラーを通知して処理を終了する。

（Ｓ１４２５）機器は、証明書ＩＤがＣＲＬに記載されていないことを確認すると、コントローラの公開鍵証明書の署名を認証局の公開鍵を用いて検証する。検証に失敗した場合、機器は、コントローラにエラーを通知して処理を終了する。また、機器は、コントローラの公開鍵証明書の署名の検証に成功すると、接続コントローラ管理テーブル９００に、新たなレコードを作成し、相互認証処理の相手となるコントローラの機器ＩＤ及び証明書ＩＤを登録する。

（Ｓ１４３０）機器及びコントローラは、後述する共有鍵計算処理を行う。

以上が、相互認証処理となる。

＜共有鍵計算処理＞
次に、機器又はコントローラとコントローラとの間の共有鍵計算処理について、図１５を参照して説明する。なお、以下では、機器とコントローラとの間の共有鍵計算処理について、説明するが、コントローラとコントローラとの間の共有鍵計算処理でも同様の処理を行う。

（Ｓ１５００）機器及びコントローラは、鍵交換を行う。鍵交換の方式は、ＥＣＤＨ（Elliptic Curve Diffie-Hellman key exchange）等の一般的な方式を用いることが可能である。ＥＣＤＨにはＳｔａｔｉｃ方式と、Ｅｐｈｅｍｅｒａｌ方式があるが、本実施の形態では、Ｓｔａｔｉｃ方式を用いるものとする。なお、当然ではあるが、Ｅｐｈｅｍｅｒａｌ方式を用いるとしてもよい。

（Ｓ１５０５）機器及びコントローラは、共有鍵を算出する。具体的には、機器及びコントローラは、ステップＳ１５００の鍵交換で共有した値に対し、ハッシュ値を計算し、計算したハッシュ値の上位１２８ビットを共有鍵とする。なお、認証システム１００では、共有鍵を用いた暗号方式として鍵長１２８ビットのＡＥＳ（Advanced Encryption Standard）を用いるものとするが、これに限らず、他の暗号方式を用いてもよい。機器は、算出した共有鍵を、接続コントローラ管理テーブル９００の対応するコントローラのレコードの共有鍵９０３に登録する。コントローラは、算出した共有鍵を、接続機器管理テーブル５００の対応する機器のレコードの共有鍵５０３に登録する。ここで、対応するコントローラ及び対応する機器とは、共有鍵計算処理の相手となる機器及びコントローラのことである。

（Ｓ１５１０、Ｓ１５１５）コントローラは、乱数Ａを生成し、機器に送信する。

（Ｓ１５２０）機器は、コントローラから受信した乱数Ａを、ステップＳ１５０５で算出した共有鍵を用いて暗号化し、暗号化乱数Ａ'を生成する。

（Ｓ１５２５、Ｓ１５３０）機器は、乱数Ｂを生成し、暗号化乱数Ａ'と乱数Ｂをコントローラに送信する。

（Ｓ１５３５）コントローラは、機器から受信した暗号化乱数Ａ'をステップＳ１５０５で算出した共有鍵を用いて復号し、ステップＳ１５１０で生成した乱数Ａと一致するか否かの検証を行う。検証に失敗した場合、コントローラは、機器にエラーを通知して処理を終了する。

（Ｓ１５４０、Ｓ１５４５）コントローラは、機器から受信した乱数ＢをステップＳ１５０５で算出した共有鍵を用いて暗号化し、暗号化乱数Ｂ'を生成し、機器に送信する。

（Ｓ１５５０）機器は、コントローラから受信した暗号化乱数Ｂ'をステップＳ１５０５で算出した共有鍵を用いて復号し、ステップＳ１５２５で生成した乱数Ｂと一致するか否かの検証を行う。検証に失敗した場合、機器は、コントローラにエラーを通知して処理を終了する。

（Ｓ１５５５）検証が成功した場合、機器はコントローラに検証成功の結果を通知する。

以上が、共有鍵計算処理となる。

＜グループ鍵配信・受信処理＞
次に、機器又はＳＣでないコントローラとＳＣのコントローラとの間のグループ鍵配信・受信処理について、図１６を参照して説明する。なお、以下では、機器とＳＣのコントローラとの間のグループ鍵配信・受信処理について、説明するが、ＳＣでないコントローラとＳＣのコントローラとの間で実施してもよい。その場合は、機器をＳＣでないコントローラに置き換えればよい。

（Ｓ１６００）コントローラは、グループ鍵を既に生成済みであるか否かを判断する。なお、コントローラは、グループ鍵を既に生成済みである場合、接続機器管理テーブル５００の対応する機器のレコードに生成済みのグループ鍵及びグループ鍵の有効時間を登録する。ここで、対応する機器とは、グループ鍵配信・受信処理の相手となる機器のことである。

（Ｓ１６０５、Ｓ１６１０）グループ鍵を既に生成済みでない場合、コントローラは、グループ鍵を生成すると共に、生成したグループ鍵の有効時間を決定する。なお、認証システム１００では、グループ鍵を用いた暗号方式として鍵長１２８ビットのＡＥＳを用いるものとするが、これに限らず、他の暗号方式を用いてもよい。コントローラは、接続機器管理テーブル５００の対応する機器のレコードに生成したグループ鍵及びグループ鍵の有効時間を登録する。

（Ｓ１６１５、Ｓ１６２０）コントローラは、生成した又は生成済のグループ鍵を、接続機器管理テーブル５００の対応する機器のレコードの共有鍵を用いて暗号化し、暗号化グループ鍵を生成し、機器に送信する。

（Ｓ１６２５）機器は、コントローラから受信した暗号化グループ鍵を、接続コントローラ管理テーブル９００の対応するコントローラのレコードの共有鍵を用いて復号する。

（Ｓ１６３０）機器は、ステップＳ１６２５で復号したグループ鍵を、接続コントローラ管理テーブル９００の対応するコントローラのレコードに登録する。

（Ｓ１６３５）機器は、グループ鍵の登録を完了したことをコントローラに通知する。

（Ｓ１６４０）コントローラは、接続機器管理テーブル５００の対応する機器のレコードのグループ鍵更新フラグ５０６に、グループ鍵が更新済みである旨を示す値を登録する。

以上が、グループ鍵配信・受信処理である。

なお、コントローラ間でグループ鍵を共有する場合には、ステップＳ１６１５、Ｓ１６２０で、グループ鍵を暗号化して送信するときに、グループ鍵の有効時間も暗号化して送信してもよい。また、暗号化されたグループ鍵の有効時間を受信したコントローラは、接続機器管理テーブル５００に受信したグループ鍵の有効時間を登録してもよい。

＜グループ鍵更新処理＞
次に、ＳＣのコントローラとＳＣ傘下の機器やコントローラとの間のグループ鍵更新処理について、図１７を参照して説明する。

（Ｓ１７００）ＳＣとなったコントローラは、接続機器管理テーブル５００のいずれか一つのレコードのグループ鍵有効時間５０５が、所定値以下になっているか否かを判断する。グループ鍵の有効時間が所定値以下になるまで、以降の処理は実施しない。

（Ｓ１７０５）ＳＣは、接続機器管理テーブル５００のいずれか一つレコードのグループ鍵有効時間５０５が、所定値以下になると、新しいグループ鍵を生成する。

（Ｓ１７１０）ＳＣは、ステップＳ１７０５で生成したグループ鍵の有効時間を決定する。有効時間は、例えば、２４時間、７２時間といった値に決定する。

（Ｓ１７１５）ＳＣは、接続機器管理テーブル５００のすべてのレコードのグループ鍵更新フラグ５０６に、グループ鍵が更新されていない旨を示す値を登録する。

（Ｓ１７２０）ＳＣは、傘下の機器及びコントローラの中からグループ鍵を更新する機器（又はコントローラ）を一つ決定する。

（Ｓ１７２５）ＳＣは、ステップＳ１７０５で生成したグループ鍵を、接続機器管理テーブル５００のステップＳ１７２０で決定した機器（又はコントローラ）のレコードの共有鍵で暗号化して暗号化グループ鍵を生成する。

（Ｓ１７３０）ＳＣは、ステップＳ１７２０で決定した機器に、ステップＳ１７２５で生成した暗号化グループ鍵を送信し、ステップＳ１７２０で決定した機器（又はコントローラ）のグループ鍵を更新する。ステップＳ１７３０の処理の詳細は後述する。

（Ｓ１７３５）ＳＣは、傘下の機器及びコントローラの全てのグループ鍵の更新を行ったか否かを判断する。グループ鍵の更新を行っていない機器又はコントローラが存在する場合はステップＳ１７２０に戻り、傘下の機器及びコントローラの全てのグループ鍵の更新を行った場合はステップＳ１７４０に進む。

（Ｓ１７４０）ＳＣは、ステップＳ１７０５で生成したグループ鍵を、接続機器管理テーブル５００のすべてのレコードのグループ鍵５０４に登録する。ＳＣは、決定したグループ鍵の有効時間を、接続機器管理テーブル５００のすべてのレコードのグループ鍵有効時間５０５に登録する。

次に、ステップＳ１７３０の処理の詳細について、図１８を参照して説明する。なお、以下では、ステップＳ１７２０で決定された機器とＳＣのコントローラとの間の処理について、説明するが、ステップＳ１７２０で決定されたコントローラとＳＣのコントローラとの間で実施してもよい。その場合は、機器をＳＣでないコントローラに置き換えればよい。

（Ｓ１８００、Ｓ１８０５）ＳＣは、乱数Ａを生成し、グループ鍵更新要求と共に乱数Ａを機器に送信する。

（Ｓ１８１０）機器は、ＳＣからグループ鍵更新要求及び乱数Ａを受信すると、接続コントローラ管理テーブル９００のＳＣのレコードの共有鍵を用いて乱数Ａを暗号化して暗号化乱数Ａ'を生成する。

（Ｓ１８１５、Ｓ１８２０）機器は、乱数Ｂを生成し、暗号化乱数Ａ'と乱数ＢをＳＣに送信する。

（Ｓ１８２５）ＳＣは、機器から受信した暗号化乱数Ａ'を接続機器管理テーブル５００の対応する機器のレコードの共有鍵を用いて復号し、ステップＳ１８００で生成した乱数Ａと一致するか否かを検証する。検証に失敗した場合、ＳＣは、機器にエラーを通知して処理を終了する。

（Ｓ１８３０、Ｓ１８３５）ＳＣは、接続機器管理テーブル５００の対応する機器のレコードの共有鍵を用いて、機器から受信した乱数Ｂを暗号化して暗号化乱数Ｂ'を生成し、機器に送信する。

（Ｓ１８４０）機器は、ＳＣから受信した暗号化乱数Ｂ'を接続コントローラ管理テーブル９００のＳＣのレコードの共有鍵を用いて復号し、ステップＳ１８１５で生成した乱数Ｂと一致するか否かを検証する。検証に失敗した場合、機器は、ＳＣにエラーを通知して処理を終了する。

（Ｓ１８４５）検証が成功した場合、機器はＳＣに検証成功の結果を通知する。

（Ｓ１８５０）ＳＣは、機器から検証成功の結果を受信すると、ステップＳ１７２５で生成した暗号化グループ鍵を機器に送信する。

（Ｓ１８５５）機器は、ＳＣから受信した暗号化グループ鍵を、接続コントローラ管理テーブル９００のＳＣのレコードの共有鍵を用いて復号する。

（Ｓ１８６０）機器は、復号したグループ鍵を、接続コントローラ管理テーブル９００のすべてのレコードのグループ鍵９０４に登録する。

（Ｓ１８６５）機器は、グループ鍵の更新完了通知をＳＣに送信する。

（Ｓ１８７０）ＳＣは、機器からグループ鍵の更新完了通知を受信すると、接続機器管理テーブル５００の対応する機器のレコードのグループ鍵更新フラグ５０６に、グループ鍵が更新済みである旨を示す値を登録する。

以上がグループ鍵更新処理である。

＜機器履歴情報送信処理＞
次に、ペアリングを行った機器からコントローラへ機器履歴情報を送信する処理について図２３を参照して説明する。なお、この機器履歴情報送信処理は、定期的あるいは不定期に行われる。

（Ｓ２３００）機器は、機器履歴保持部８５０で保持している機器履歴情報を、接続コントローラ管理テーブル９００のグループ鍵で暗号化して、暗号化履歴情報を生成する。

（Ｓ２３０５）機器は、グループに関する情報９１０の制御コントローラ９１１に登録されているコントローラに対して、ステップＳ２３００で生成した暗号化履歴情報をコントローラに送信する。

（Ｓ２３１０）コントローラは、ペアリングした機器から暗号化機器履歴情報を受信すると、接続機器管理テーブル５００の対応する機器のレコードのグループ鍵を用いて復号する。

以上が機器履歴情報送信処理となる。なお、コントローラは、復号した機器履歴情報を、外部のサーバなどに送信してもよい。

＜制御コマンド送信処理＞
次に、ペアリングを行ったコントローラから機器へ制御コマンドを送信する処理について図２４を参照して説明する。なお、この制御コマンド送信処理は、定期的あるいは不定期に行われる。

（Ｓ２４００）コントローラは、外部のサーバからの制御依頼などに基づいて、ペアリングした各機器向けの制御コマンドを生成する。

（Ｓ２４０５）コントローラは、生成した各制御コマンドを、接続機器管理テーブル５００の対応する機器のレコードのグループ鍵を用いて暗号化して暗号化制御コマンドを生成する。

（Ｓ２４１０）コントローラは、生成した暗号化制御コマンドを、ペアリングした各機器に送信する。コントローラは、複数の機器に対して同一グループ鍵で暗号化された同一の制御コマンドを送信する場合は、一斉同報通信（ブロードキャスト通信）で送信する。

（Ｓ２４１５）機器は、ペアリングしたコントローラから暗号化制御コマンドを受信すると、接続コントローラ管理テーブル９００のグループ鍵を用いて復号する。

（Ｓ２４２０）機器は、復号した制御コマンドを実行する。

以上が制御コマンド送信処理となる。

＜接続機器管理テーブル及びグループに関する情報の更新について＞
以上に示した機器登録処理、ネゴシエート処理、ＳＣ引継処理、相互認証処理、共有鍵計算処理、グループ鍵配信・受信処理を適宜行うことより、認証システム１００のグループ構成は、図２に示す状態から図３に示す状態のようにグループ統合を行いながら動作する。

ここで、ＨＡＮ内のグループ構成が図２の状態で、コントローラＡとコントローラＢとが機器登録処理を行い、グループ統合により、図３に示すようなグループ構成になったとする。このときの各コントローラの接続機器管理テーブル５００及びグループに関する情報５１０、並びに、各機器の接続コントローラ管理テーブル９００及びグループに関する情報９１０の更新について、図１９−２２を参照して説明する。

図１９Ａは、ＨＡＮ内のグループ構成が図２の状態のときのコントローラＡの保持する接続機器管理テーブル５００を示す図である。

図１９Ｂは、ＨＡＮ内のグループ構成が図２の状態のときのコントローラＡの保持するグループに関する情報５１０を示す図である。

図１９Ｃは、ＨＡＮ内のグループ構成が図２の状態のときのコントローラＢの保持する接続機器管理テーブル５００を示す図である。

図１９Ｄは、ＨＡＮ内のグループ構成が図２の状態のときのコントローラＢの保持するグループに関する情報５１０を示す図である。

図２０Ａは、ＨＡＮ内のグループ構成が図２の状態のときの機器Ａの保持する接続コントローラ管理テーブル９００を示す図である。

図２０Ｂは、ＨＡＮ内のグループ構成が図２の状態のときの機器Ａの保持するグループに関する情報９１０を示す図である。

図２０Ｃは、ＨＡＮ内のグループ構成が図２の状態のときの機器Ｂの保持する接続コントローラ管理テーブル９００を示す図である。

図２０Ｄは、ＨＡＮ内のグループ構成が図２の状態のときの機器Ｂの保持するグループに関する情報９１０を示す図である。

図２１Ａは、ＳＣ引継処理後のコントローラＡの保持する接続機器管理テーブル５００を示す図である。

図２１Ｂは、ＳＣ引継処理後のコントローラＡの保持するグループに関する情報５１０を示す図である。

図２１Ｃは、ＳＣ引継処理後のコントローラＢの保持する接続機器管理テーブル５００を示す図である。

図２１Ｄは、ＳＣ引継処理後のコントローラＢの保持するグループに関する情報５１０を示す図である。

図２２Ａは、ＳＣ引継処理後の機器Ａの保持する接続コントローラ管理テーブル９００を示す図である。

図２２Ｂは、ＳＣ引継処理後の機器Ａの保持するグループに関する情報９１０を示す図である。

図２２Ｃは、ＳＣ引継処理後の機器Ｂの保持する接続コントローラ管理テーブル９００を示す図である。

図２２Ｄは、ＳＣ引継処理後の機器Ｂの保持するグループに関する情報９１０を示す図である。

図１９Ａと図２１Ａを比較すると、コントローラＡの接続機器管理テーブル５００には、新たに傘下となったコントローラＢのレコード（機器ＩＤが「００４」のレコード）と機器Ｂのレコード（機器ＩＤが「００２」のレコード）が追加されている。コントローラＢのレコードは、コントローラＡとコントローラＢのネゴシエート処理において、コントローラＡとコントローラＢとが相互認証を行ったときに、追加されたレコードである（図１２：ステップＳ１２０５及び図１４：ステップＳ１４１０、Ｓ１４２５参照）。機器Ｂのレコードは、コントローラＢ（旧ＳＣ）からコントローラＡ（新ＳＣ）のＳＣ引継処理において、旧ＳＣから通知された機器の情報を登録したときに追加されたレコードである（図１３：ステップＳ１３２０、ステップＳ１３３０参照）。

図１９Ｂと図２１Ｂを比較すると、コントローラＡのグループに関する情報５１０の傘下の機器５１３には、新たに傘下になったコントローラＢと機器Ｂの機器ＩＤが追加されている。この追加は、コントローラＢ（旧ＳＣ）からコントローラＡ（新ＳＣ）のＳＣ引継処理において、旧ＳＣから通知された機器及び旧ＳＣを傘下の機器として登録したときになされたものである（図１３：ステップＳ１３２０参照）。

図１９Ｃと図２１Ｃを比較すると、コントローラＢの接続機器管理テーブル５００には、新たにＳＣとなったコントローラＡのレコード（機器ＩＤが「００３」のレコード）が追加されている。コントローラＡのレコードは、コントローラＡとコントローラＢのネゴシエート処理において、コントローラＡとコントローラＢとが相互認証を行ったときに、追加されたレコードである（図１２：ステップＳ１２０５及び図１４：ステップＳ１４１０、Ｓ１４２５参照）。なお、図２１Ｃにおいて、コントローラＢの接続機器管理テーブル５００のグループ鍵有効時間５０５及びグループ鍵更新フラグ５０６の値が「−」となっているのは、コントローラＢがＳＣではなくなり、管理する必要のない情報であることを示している。

図１９Ｄと図２１Ｄを比較すると、コントローラＢのグループに関する情報５１０のＳＣ５１２が、コントローラＢの機器ＩＤからコントローラＡの機器ＩＤに変更している。この変更は、コントローラＢ（旧ＳＣ）からコントローラＡ（新ＳＣ）のＳＣ引継処理において、新ＳＣを登録したときになされたものである（図１３：ステップＳ１３２５参照）。なお、図２１Ｄにおいて、コントローラＢのグループに関する情報５１０の傘下の機器５１３の値が「−」となっているのは、コントローラＢがＳＣではなくなり、管理する必要のない情報であることを示している。

図２０Ａ、図２０Ｂと図２２Ａ、図２２Ｂを比較すると、機器Ａの接続コントローラ管理テーブル９００及びグループに関する情報９１０に変更はない。これは、今回のグループ統合によっては、機器ＡのＳＣがされなかったことを意味している。

図２０Ｃ、図２０Ｄと図２２Ｃ、図２２Ｄを比較すると、機器Ｂの接続コントローラ管理テーブル９００に、新たにＳＣとなったコントローラＡの機器ＩＤのレコードが追加され、グループに関する情報９１０のＳＣ９１２が旧ＳＣであるコントローラＢの機器ＩＤから新ＳＣであるコントローラの機器ＩＤに変更されている。この変更は、コントローラＢ（旧ＳＣ）からコントローラＡ（新ＳＣ）のＳＣ引継処理において、旧ＳＣの傘下であった機器Ｂが旧ＳＣからＳＣの変更通知を受信した後に、コントローラＡを新ＳＣとして登録したときになされたものである（図１３：ステップＳ１３１５、Ｓ１３３０参照）。

以上図１９−２２で示したように、各コントローラの接続機器管理テーブル５００及びグループに関する情報５１０、並びに、各機器の接続コントローラ管理テーブル９００及びグループに関する情報９１０が更新される。

＜新規コントローラ参入の流れ＞
ここでは、ＨＡＮ内の全ての機器及びコントローラがペアリングされていない状態から、上記機器登録処理、ネゴシエート処理、ＳＣ引継処理、相互認証処理、共有鍵計算処理、グループ鍵配信・受信処理、グループ鍵更新処理を行うことにより、グループが構築され、さらに、新規コントローラがグループに参入したときの流れについて説明する。

まず、ＨＡＮ内に、いずれの機器及びコントローラともペアリングされていないコントローラＡ、機器Ａが存在するとする。この状態において、コントローラＡのＳＣはコントローラＡが設定しており、機器Ａには、ＳＣが設定されていない状態である。

ユーザによるコントローラＡと機器Ａとのペアリング操作により、コントローラＡと機器Ｂとの間で上述の図１０に示す機器登録処理が行われる。

この機器登録処理では、機器ＡにはＳＣが設定されていないことから、ネゴシエート処理を行わずに、コントローラＡのＳＣとして設定されているコントローラＡが新たなＳＣとして、機器Ａに通知される（ステップＳ１０１０、Ｓ１０２０参照）。

機器Ａでは、ＳＣが新たに登録されることによって、ＳＣとの認証が必要になり、ＳＣであるコントローラＡとの相互認証処理を行う（ステップＳ１０２５、Ｓ１０３０参照）。この機器ＡとコントローラＡとの相互認証処理を第１の相互認証と呼ぶ。

第１の相互認証の後、機器ＡとコントローラＡとが、グループ鍵配信・受信処理を行って機器ＡとコントローラＡとの間でグループ鍵が共有される（ステップＳ１０３５参照）。このときに共有されるグループ鍵を第１のグループ鍵と呼ぶ。

そして、機器ＡがコントローラＡの傘下に参入し、機器ＡとコントローラＡとからなるグループが形成される（ステップＳ１０４０参照）。この後、第１のグループ鍵の有効時間が所定値以下になる度に、コントローラＡは、図１７，１８に示すグループ鍵更新処理を行い、グループ内で共有されているグループ鍵である第１のグループ鍵を更新する。

この状態で、新たにいずれの機器ともペアリングされていないコントローラＢがＨＡＮに接続されたとする。この時、コントローラＢのＳＣとしてはコントローラＢが設定されている。

ユーザによるコントローラＡとコントローラＢとのペアリング操作により、コントローラＡとコントローラＢとの間で図１１に示す機器登録処理が行われる。

この機器登録処理では、コントローラＡに設定されているＳＣと、コントローラＢに設定されているＳＣが異なることから、コントローラＡのＳＣとコントローラＢのＳＣとの間でネゴシエート処理が発生する（ステップＳ１１１０、Ｓ１１１５参照）。この場合、コントローラＡとコントローラＢがネゴシエート処理を行う。

ネゴシエート処理では、コントローラＡとコントローラＢとの間で相互認証処理が行われる（図１２：ステップＳ１２０５参照）。このコントローラＡとコントローラＢとの間で行われる相互認証処理を、第２の相互認証と呼ぶ。

第２の相互認証のあと、コントローラＡとコントローラＢのうちどちらがＳＣとなるかが決定される。

コントローラＢがＳＣとなると、コントローラＡからコントローラＢへのＳＣ引継処理が行われる。ＳＣ引継処理では、旧ＳＣであるコントローラＡが生成した第１のグループ鍵を、旧ＳＣであるコントローラＡと新ＳＣであるコントローラＢとが共有するグループ鍵配信・受信処理が行われる（図１３：ステップＳ１３００参照）。

この時、コントローラＡとコントローラＢと機器Ａとでは、コントローラＡが生成したグループ鍵である第１のグループ鍵が共有されており、新ＳＣによるグループ鍵更新処理が行われるまでは、コントローラＡとコントローラＢと機器Ａとは、第１のグループ鍵を用いた暗号通信を行うことが可能である。

第１のグループ鍵の有効時間が所定値以下になると、図１７、１８に示すグループ鍵更新処理が行われる。グループ鍵更新処理では、ＳＣであるコントローラＢがグループ鍵を生成する。このグループ鍵を第２のグループ鍵と呼ぶ（図１７：ステップＳ１７０５参照）。そして、コントローラＢは、傘下の機器であるコントローラＡと機器Ａそれぞれに対して、共有鍵と乱数を用いた相互認証を行う（図１８：ステップＳ１８００−Ｓ１８４５参照）。この共有鍵と乱数を用いた相互認証を第３の相互認証と呼ぶ。

コントローラＢは、第３の相互認証に成功したコントローラＡと機器Ａと第２のグループ鍵を共有する。

以上のように、グループに新たに参入したコントローラにＳＣが引き継がれ、新ＳＣによりグループ鍵が更新される場合には、第１の相互認証、第２の相互認証、第３の相互認証が行われることになる。

＜実施の形態１の効果＞
実施の形態１では、コントローラと機器でグループを形成し、１つのグループの中に複数のコントローラが含まれる状態になるときに、複数のコントローラ間でネゴシエート処理を行う。各コントローラは、公開鍵証明書に記載されたコントローラの属性を用いて、ネゴシエートすることで、電源断やネットワーク未接続の状態が発生しにくいコントローラを優先的にＳＣとして決定することができる。これにより、新しい機器やコントローラがグループに参入するときにも、グループ鍵を更新する必要が生じたときにも、グループ内で迅速にグループ鍵を共有できる。

また、実施の形態１では、コントローラ間でＳＣを変更した際に、旧ＳＣから新ＳＣへのＳＣ引継処理を行って、旧ＳＣが傘下の機器と行った認証結果を新ＳＣが引き継いでいる。これにより、新ＳＣと旧ＳＣの傘下の機器との間における公開鍵証明書を用いた認証を省略することができる。その結果、機器やコントローラの処理負担を少なくすることができる。

さらに、実施の形態１では、コントローラ間でＳＣを変更した際に、旧ＳＣから新ＳＣに、旧ＳＣの生成したグループ鍵を送信している。これにより、新ＳＣは、新ＳＣの生成したグループ鍵を配信する前であっても、旧ＳＣの生成したグループ鍵を用いて、旧ＳＣの傘下の機器に対する一斉同報通信を暗号化して行うことができる。

（変形例）
以上、本開示に係る認証方法を用いた認証システムについて、実施の形態に基づき説明したが、以下のように変形することも可能であり、本開示は上述した実施の形態で示した通りの認証システムに限られない。

＜１＞実施の形態１で示したＳＣ引継処理は、以下に示すように変形してもよい。

図２５は、ＳＣ引継処理の変形例を示す図である。

ステップＳ２５００、Ｓ２５０５、Ｓ２５１０、Ｓ２５２０、Ｓ２５２５、Ｓ２５３５の処理は、実施の形態１のＳＣ引継処理におけるステップＳ１３００、Ｓ１３０５、Ｓ１３１０、Ｓ１３２０、Ｓ１３２５、Ｓ１３３０の処理と同様であり説明を省略する。

（Ｓ２５１５）旧ＳＣであるコントローラＢは、傘下の機器及び新ＳＣであるコントローラＡに、登録モードの起動指示を送信する。

（Ｓ２５３０）コントローラＡと旧ＳＣの傘下の機器は、コントローラＢから登録モードの起動指示を受信すると、登録モードを起動する。

（Ｓ２５３５）コントローラＡは、旧ＳＣの傘下の各機器と順次、機器登録処理を行う。機器登録処理は、図１０のステップＳ１００５〜Ｓ１０６５と同様の処理であり、ここでの説明は省略する。

図２５に示すＳＣ引継処理は、ＳＣが変更された場合に、旧ＳＣから傘下の機器及び新ＳＣへ登録モードの起動指示を送信し、新ＳＣと旧ＳＣ傘下の機器が登録モードを起動する。これにより、ユーザが手動で登録モードを起動せずとも、旧ＳＣ傘下の機器と新ＳＣとで機器登録処理を行うことができ、ユーザの利便性が向上する。

＜２＞実施の形態１のＳＣ引継処理において、旧ＳＣは、傘下の機器の情報を新ＳＣに通知する際に、傘下の機器それぞれの公開鍵証明書も新ＳＣに送信するものとした。しかしながら、本開示はこれに限らず、旧ＳＣが傘下の機器それぞれの公開鍵証明書を新ＳＣに送信するのではなく、旧ＳＣからＳＣの変更通知を受けた傘下の機器それぞれが、自機が保持する公開鍵証明書を、新ＳＣに送信するものとしてもよい。この場合、旧ＳＣの傘下の機器それぞれは、旧ＳＣが生成したグループ鍵を用いて、公開鍵証明書を暗号化して、新ＳＣに送信してもよい。

＜３＞実施の形態１のネゴシエート処理は、公開鍵証明書に記載の機器の属性として、コントローラの機能による分類が記載され、その分類項目（「専用機器」、「汎用機器」、「アプリ」）によって、ＳＣになるコントローラを決定すると説明した。しかしながら、本開示のネゴシエート処理は、これに限定されるものではない。例えば、公開鍵証明書に記載の機器の属性として、通信方式や認証方式などのバージョン情報が記載され、ネゴシエート処理を行うコントローラのなかで、通信方式や認証方式などのバージョン情報として最新のバージョン番号が記載された公開鍵証明書を持つコントローラをＳＣとして決定してもよい。また、対応機器や対応機能が多いことを示すバージョン情報を持つコントローラをＳＣとして決定してもよい。これにより、最新の機能を持ったコントローラや対応機器や対応機能が多いコントローラをＳＣとして決定することができる。

また、公開鍵証明書に記載の機器の属性として、コントローラとペアリング可能な機器の最大数が記載され、ネゴシエート処理を行うコントローラの中でその最大数が一番大きいコントローラをＳＣとして決定してもよい。これにより、より多くの機器とペアリング可能なコントローラをＳＣとして決定することができる。

また、公開鍵証明書に記載の機器の属性として、コントローラが対応している通信機能の種類（有線、専用無線、汎用無線、近距離無線）が記載され、その種類によってＳＣとなるコントローラを決定してもよい。この時、例えば「有線」、「専用無線」、「汎用無線」、「近距離無線」の順番で、ＳＣになりやすいように優先度を設定してもよい。この順番は、ＨＡＮに接続している可能性が高い（ＨＡＮに接続していない状態となる頻度が低い）通信に対応しているコントローラが、ＳＣになりやすい順番である。これにより、ＳＣが必要とされるときに、ＨＡＮに接続している可能性が高いコントローラをＳＣとして決定することができる。

また、公開鍵証明書に記載の機器の属性として、電源の種類（常時通電、定期通電、短期通電）が記載され、その種類によってＳＣとなるコントローラを決定してもよい。この時、「常時通電」、「定期通電」、「短期通電」の順番で、ＳＣになりやすい優先度を設定してもよい。この順番は、動作している可能性が高い（電源ＯＦＦとなる頻度が低い）コントローラが、ＳＣになりやすい順番である。これにより、ＳＣが必要とされているときに動作している可能性が高いコントローラをＳＣとして決定することができる。ここで、「常時通電」の機器とは、機器制御用の専用コントローラやログ収集装置、分電盤、ブレーカー、冷蔵庫、エアコン、太陽光発電装置、蓄電池（バッテリー）、電話機、ブロードバンドルータ、終端装置等の常時通電している必要のある機器である。「定期通電」の機器とは、ＴＶや録画装置、オーディオ機器、天井灯等の機器である。「短期通電」の機器とは、電子レンジ、オーブン、洗濯機、掃除機、炊飯器等の機器である。

また、公開鍵証明書に記載の機器の属性として、使用形態（据え置き（固定）、据え置き（移動可）、持ち運び、身につける）が記載され、その形態によってＳＣになるコントローラを決定してもよい。この時、例えば「据え置き（固定）」、「据え置き（移動可）」、「持ち運び」、「身につける」の順番で、ＳＣになりやすいように優先度を設定してもよい。この順番は、移動させやすいコントローラほどＳＣになりにくい順番である。移動しない機器であれば、通信環境が変化することも少なく、通信が途中で切れる可能性が低いと考えられる。また、移動しない機器は、電源の確保も容易である。従って、通信が途中で途切れにくく、電源の確保が容易なコントローラをＳＣとして決定することができる。

さらに、公開鍵証明書に記載の機器の属性によりＳＣを決めるのではなく、その時の機器の状況によりＳＣを決定してもよい。例えば、ネゴシエート処理をするときに、そのコントローラとペアリングしている機器の数が一番多いコントローラがＳＣになるとしてもよい。これにより、ＳＣが変わることにより再認証の必要が生じる機器の台数を減らすことができる。また、稼働時間が一番短いコントローラがＳＣになるとしてもよいし、製造年月日が一番新しいコントローラがＳＣになるとしてもよい。これにより、ＳＣの故障により認証処理ができなくなる可能性を減らすことが可能となる。

また、上記の基準を組み合わせて、セキュリティコーディネータを決めてもよい。

＜４＞実施の形態１におけるネゴシエート処理は、コントローラにより自動で実施するものとして説明した。しかしながら、本開示のネゴシエート処理は、コントローラがユーザへＳＣの候補となるコントローラを提示し、ユーザが提示された候補の中からＳＣとなるコントローラを選択するとしてもよい。この時、ＳＣになれるコントローラ全てを候補として提示してもよいし、実施の形態１や変形例＜３＞に示す基準で選択したコントローラが複数になったときに、それらを候補として提示してもよい。

図２６は、本変形例におけるコントローラの表示部での表示例である。図２６においては、ＳＣの候補となるコントローラが２つあり、それぞれに異なる家電が登録されている様子を示している。また、２つのコントローラそれぞれの公開鍵証明書に記載された機器の属性（コントローラの機能による分類、通信方式や認証方式などのバージョン情報、製造年月日、稼働時間）が表示されている。ユーザは、提示された情報に応じてＳＣとなるコントローラを決定する。ここで、ユーザの決定は、例えば、決定したコントローラの画面内の絵をタッチする、それぞれのコントローラに付けられた番号（１や２）を入力装置から入力する、又は、コントローラの識別記号（ＡやＢ）を入力装置から入力する、といった方法により入力される。入力装置は、ユーザからの意思をコントローラへ伝えることができる装置であればよく、物理的なキー入力装置、タッチパネル上に提示されるアイコン、音声により指示を与える装置、ジェスチャーにより指示を与える装置、視線によって指示を与える装置であってもよい。

＜５＞実施の形態１では、ステップＳ１５１０〜Ｓ１５５５で乱数を暗号化して共有鍵を検証するチャレンジレスポンス認証を行っているが、これに限定するわけではなく、ＲＦＣ５１９１に記載されている認証方式を用いて、認証を行うとしてもよい。ＲＦＣ５１９１は非特許文献３に記載されているためここでは述べない。このとき、ＲＦＣ５１９１においてＥＡＰ−ＰＳＫを用いるとしてもよい。また、グループ鍵はＥＡＰ−ＰＳＫのネゴシエーションの結果導出されるＥＭＳＫを用いて導出するとしてもよい。さらに、鍵導出関数はＨＭＡＣ＿ＳＨＡ２＿２５６を用いてもよい。

＜６＞実施の形態１では、Ｓ１５１０〜Ｓ１５５５で乱数を暗号化して共有鍵を検証するチャレンジレスポンス認証を行っているが、これに限定するわけではなく、ＲＦＣ６３４７に記載されている認証方式を用いて、認証を行うとしてもよい。ＲＦＣ６３４７は非特許文献４に記載されているためここでは述べない。

＜７＞上記実施の形態では、グループへのコントローラの新規参入時に、新規参入するコントローラとグループ内の既存のコントローラとが登録モードを起動して、機器登録処理を行っているが、本開示はこれに限定されるものではない。例えば、以下であってもよい。コントローラの新規参入時に、新規参入するコントローラとグループ内の機器とが登録モードを起動する。このとき、機器は接続コントローラ管理テーブルを参照して、機器のＳＣとして設定されているコントローラの情報を新規参入するコントローラへ送信する。新規参入するコントローラはＳＣの情報を受信し、ＳＣと認証することにより参入が可能となる。これにより、グループのＳＣが家庭内で離れた場所にあったとしても、ＳＣ傘下の機器の登録モードを起動することで、ＳＣと新規参入するコントローラとが認証することが可能となる。

＜８＞コントローラは、接続する機器の消費電力量や蓄電池の電力量、太陽光発電の発電量を表示するとしてもよい。

＜９＞コントローラは、家庭に設置される分電盤であってもよい。

＜１０＞実施の形態１では、グループ鍵更新処理において、ＳＣとなったコントローラがグループ鍵の有効時間を管理し、各機器へグループ鍵更新通知を送信しているが、ＳＣとなったコントローラから各機器にグループ鍵の有効時間を通知し、各機器がグループ鍵の有効時間を管理し、各機器からＳＣとなったコントローラへグループ鍵更新通知を送信してもよい。

＜１１＞実施の形態１では、グループ鍵の有効時間を残り時間で管理しているが、これに限定するものではなく、グループ鍵の生成時刻やグループ鍵の有効期間の終了時刻で管理するとしてもよい。グループ鍵の生成時刻で管理する場合、グループ鍵の有効期間の長さを別途記憶し、現在の時刻と、グループ鍵の生成時刻にグループ鍵の有効期間を追加した時刻とを比較し、グループ鍵を更新するか否かを判断する。また、グループ鍵の有効期間の終了時刻で管理する場合、現在の時刻とグループ鍵の有効時間の終了時刻とを比較し、グループ鍵を更新するかを判断する。

＜１２＞実施の形態１では、グループ鍵更新処理においてグループ鍵未更新の機器が存在した場合、グループ鍵更新通知を送信し、グループ鍵の更新を行っているが、当該機器の電源が入っていない場合には、定期的にグループ鍵更新通知を送信するとしてもよい。

＜１３＞実施の形態１では、グループ鍵更新処理においてグループ鍵未更新の機器が存在した場合、グループ鍵更新通知を送信し、グループ鍵の更新を行っているが、当該機器がペアリングされたコントローラによる制御を受けている場合は、当該機器からグループ鍵の延期時間を通知して、当該延期時間の経過後にグループ鍵更新処理を行うとしてもよい。

＜１４＞実施の形態１では、ＳＣ引継処理時、ＳＣの変更通知の後に、新ＳＣと旧ＳＣ傘下の機器とで共有鍵を計算（Ｓ１３３０）しているが、グループ鍵有効時間が切れてグループ鍵更新処理が行われる前であればどのタイミングで行ってもよい。たとえば、機器の動作が行われていない時にするとしてもよいし、グループ鍵更新処理の直前に行うとしてもよい。これにより、機器の動作に負担をかけずにコントローラと機器間で共有鍵の計算ができる。

＜１５＞実施の形態１では、ネゴシエート処理時にコントローラＡがＳＣの判断（ステップＳ１２１０−Ｓ１２４０）をしているが、これに限定するわけではなく、コントローラＡとコントローラＢのそれぞれがＳＣの判断を行ってもよい。

＜１６＞上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。

＜１７＞上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されてもよい。

また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用しても良い。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

＜１８＞上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。

＜１９＞本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。

また、本発明は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。

また、本発明は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。

また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。

また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

＜２０＞上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。

（補足）
以下、さらに、本開示の構成と効果について補足説明する。

＜Ａ＞本開示の一態様の認証方法は、ネットワーク上の１以上の機器と２以上のコントローラとが所属するグループにおける認証方法であって、前記グループ内の少なくとも１つのコントローラが、前記グループ内で共通で利用するグループ鍵を管理するコーディネータを、前記グループ内のコントローラの中から各コントローラの属性に応じて決定し、前記コーディネータが、グループ鍵を生成し、前記グループ内の機器およびコントローラと相互認証を実行し、認証に成功した機器およびコントローラと前記生成したグループ鍵を共有することを特徴とする。

この構成によると、ネットワーク上のグループ内に複数のコントローラが存在する場合において、グループ内で共通で利用するグループ鍵を管理するＳＣとして、適切なコントローラを選択することができる。

＜Ｂ＞本開示の一態様の認証方法は、ネットワーク上の１以上の機器と第１のコントローラとが所属するグループにおける認証方法であって、前記第１のコントローラが、第１のグループ鍵を生成し、前記グループ内の機器と第１の相互認証を実行し、認証に成功した機器と前記第１のグループ鍵を共有し、前記グループに新たに第２のコントローラが参入した場合、前記グループ内の少なくとも１つのコントローラが、前記グループ内で共通で利用するグループ鍵を管理するコーディネータを、前記グループ内のコントローラの中から各コントローラの属性に応じて決定し、前記第１のコントローラが、前記コーディネータと第２の相互認証を実行し、認証に成功した場合に前記第１のグループ鍵を共有し、前記コーディネータが、前記第１のグループ鍵を用いて、前記グループ内で暗号通信を行い、前記コーディネータが、第２のグループ鍵を生成し、前記グループ内の機器およびコントローラと第３の相互認証を実行し、認証に成功した機器およびコントローラのグループ鍵を前記第２のグループ鍵に更新させることを特徴とする。

この構成によると、ネットワーク上のグループ内に複数のコントローラが存在する場合において、グループ内で共通で利用するグループ鍵を管理するＳＣとして、適切なコントローラを選択することができる。さらに、ＳＣが変更した場合に、新たにＳＣになったコントローラは、旧ＳＣだったコントローラから受信したグループ鍵を用いて、グループ内の複数の機器と一斉同報通信を暗号化して行うことができる。

＜Ｃ＞本開示の一態様の認証方法は、上記態様＜Ｂ＞の認証方法において、前記第１のコントローラが、前記ネットワーク内の機器の認証情報を、前記コーディネータに送信し、前記コーディネータが、前記第１のコントローラから受信した認証情報を用いて前記第３の相互認証を実行することを特徴とする。

この構成によると、新ＳＣと旧ＳＣの傘下の機器との間における認証を簡略化することができる。その結果、機器やコントローラの処理負担を少なくすることができる。

＜Ｄ＞本開示の一態様の認証方法は、上記態様＜Ｂ＞の認証方法において、前記グループ内の機器およびコントローラは、相互認証を実行して当該認証に成功した相手を登録する登録モードを備え、前記第１のコントローラは、前記第２の相互認証が成功した場合、前記コーディネータと前記グループ内の機器へ、登録モードの起動指示を送信し、前記グループ内の機器は、前記第１のコントローラから登録モードの起動指示を受信して登録モードを起動し、前記コーディネータは、前記第１のコントローラから登録モードの起動指示を受信して登録モードを起動し、登録モードを起動した機器と前記第３の相互認証を実行することを特徴とする。

この構成によると、ユーザが手動で登録モードを起動せずとも、旧ＳＣ傘下の機器と新ＳＣとでペアリングを行うことができ、ユーザの利便性が向上する。

＜Ｅ＞本開示の一態様の認証方法は、上記態様＜Ａ＞又は＜Ｂ＞の認証方法において、前記グループ内のコントローラそれぞれは、自機器の１以上の属性が記載された公開鍵証明書を保持し、前記グループ内のコントローラは、それぞれが保持する公開鍵証明書に記載された属性を用いて、前記決定を行うことを特徴とする。

この構成によると、公開鍵証明書に記載されたコントローラの属性を参照して、ＳＣとして適切なコントローラを選択することができる。

＜Ｆ＞本開示の一態様の認証方法は、上記態様＜Ｅ＞の認証方法において、前記公開鍵証明書に記載される属性は、専用、汎用およびアプリの３つのうちのいずれかであり、属性が専用とは、コントローラが特定の目的のために専用の機能のみを提供することを示し、属性が汎用とは、コントローラが複数の目的に対してそれぞれの機能を提供することを示し、属性がアプリとは、コントローラが複数の目的に対してそれぞれの機能を提供する機器上で動作するソフトウェアであることを示し、属性が専用であるコントローラは、属性が汎用およびアプリであるコントローラよりも優先的にコーディネータになり、属性が汎用であるコントローラは、属性がアプリであるコントローラよりも優先的にコーディネータになることを特徴とする。

この構成により、電源断やネットワーク未接続状態が少ないコントローラ（公開鍵証明書に記載の属性が「専用機器」のコントローラ）がＳＣとして選択されやすくなる。また、電源断やネットワーク未接続状態が多いコントローラ（公開鍵証明書に記載の属性が「アプリ」のコントローラ）がＳＣとして選択されにくくなる。

＜Ｇ＞本開示の一態様の認証方法は、上記態様＜Ｅ＞の認証方法において、前記公開鍵証明書に記載された属性とは、バージョン情報であり、前記グループ内のコントローラは、それぞれが保持する公開鍵証明書に記載されたバージョン情報の示すバージョン番号の新しさに応じて、前記決定を行うことを特徴とする。

この構成により、最新の機能を持ったコントローラをＳＣとして決定することができる。

＜Ｈ＞本開示の一態様の認証方法は、上記態様＜Ｅ＞の認証方法において、前記公開鍵証明書に記載された属性とは、バージョン情報であり、前記グループ内のコントローラは、それぞれが保持する公開鍵証明書に記載されたバージョン情報の示す対応機器の数に応じて、前記決定を行うことを特徴とする。

この構成により、対応機器の多いコントローラをＳＣとして決定することができる。

＜Ｉ＞本開示の一態様の認証方法は、上記態様＜Ａ＞又は＜Ｂ＞の認証方法において、前記コントローラの属性は、前記コントローラの累積稼働時間であることを特徴とする。

この構成により、ＳＣの故障により認証処理ができなくなる可能性を減らすことが可能となる。

＜Ｊ＞本開示の一態様の認証方法は、上記態様＜Ａ＞又は＜Ｂ＞の認証方法において、前記コントローラの属性は、前記コントローラの製造時からの経過時間であることを特徴とする。

この構成により、ＳＣの故障により認証処理ができなくなる可能性を減らすことが可能となる。

＜Ｋ＞本開示の一態様の認証方法は、上記態様＜Ａ＞又は＜Ｂ＞の認証方法において、前記コントローラの属性は、前記コントローラとペアリングしている機器の数であることを特徴とする。

この構成により、ＳＣが変わることにより再認証の必要が生じる機器の台数を減らすことができる。

＜Ｌ＞本開示の一態様の認証方法は、上記態様＜Ａ＞又は＜Ｂ＞の認証方法において、前記グループ内のコントローラは、ディスプレイと操作部とを備えており、前記決定は、前記グループ内のコントローラが、前記グループ内の各コントローラの属性を示す情報を前記ディスプレイに表示し、前記表示に対して前記グループ内のコントローラから一コントローラを選択するユーザ入力を前記操作部で受け付け、選択されたコントローラを前記コーディネータとする処理であることを特徴とする。

この構成によると、ネットワーク上のグループ内に複数のコントローラが存在する場合において、ＳＣとして適切なコントローラを選択することができる。

本開示は、ＨＡＮ等のネットワーク内に構成されたグループ内に複数のコントローラが存在するシステムにおいて、グループ鍵の配布・更新を行うコントローラを適切に決定することができ、様々な機器と複数のコントローラが接続し、互いに通信しながら動作するシステムにおける認証システム等として有用である。

１００ 認証システム
１１０ コントローラ
１２０ 機器
１３０ ＨＡＮ
１４０ サーバ
１５０ ネットワーク
４１０ 機器管理部
４２０ 機器情報保持部
４３０ 認証処理部
４４０ 認証情報保持部
４５０ ネゴシエート部
４６０ 操作部
４７０ 通信部
８１０ 機器管理部
８２０ 機器情報保持部
８３０ 認証処理部
８４０ 認証情報保持部
８５０ 機器履歴保持部
８６０ 操作部
８７０ 通信部

Claims (13)

1. ネットワーク上の１以上の機器と第１のコントローラとが所属するグループにおける認証方法であって、
   前記第１のコントローラが、第１のグループ鍵を生成し、前記グループ内の機器と第１の相互認証を実行し、認証に成功した機器と前記第１のグループ鍵を共有し、
   前記グループに新たに第２のコントローラが参入した場合、前記グループ内の少なくとも１つのコントローラが、前記グループ内で共通で利用するグループ鍵を管理するコーディネータを、前記グループ内のコントローラの中から決定し、
   前記第１のコントローラが、前記コーディネータと第２の相互認証を実行し、認証に成功した場合に前記第１のグループ鍵を共有し、
   前記コーディネータが、前記第１のグループ鍵を用いて、前記グループ内で暗号通信を行い、
   前記コーディネータが、前記第１のグループ鍵の有効時間が所定の値よりも小さくなったときに、第２のグループ鍵を生成し、前記グループ内の機器およびコントローラと第３の相互認証を実行し、認証に成功した機器およびコントローラのグループ鍵を前記第２のグループ鍵に更新させる
   認証方法。
2. 前記第１のコントローラが、前記ネットワーク内の機器の認証情報を、前記コーディネータに送信し、
   前記コーディネータが、前記第１のコントローラから受信した認証情報を用いて前記第３の相互認証を実行する
   請求項１の認証方法。
3. 前記グループ内の機器およびコントローラは、相互認証を実行して当該認証に成功した相手を登録する登録モードを備え、
   前記第１のコントローラは、前記第２の相互認証が成功した場合、前記コーディネータと前記グループ内の機器へ、登録モードの起動指示を送信し、
   前記グループ内の機器は、前記第１のコントローラから登録モードの起動指示を受信して登録モードを起動し、
   前記コーディネータは、前記第１のコントローラから登録モードの起動指示を受信して登録モードを起動し、登録モードを起動した機器と前記第３の相互認証を実行する
   請求項１の認証方法。
4. 前記グループ内のコントローラそれぞれは、自機器の１以上の属性が記載された公開鍵証明書を保持し、
   前記グループ内のコントローラは、それぞれが保持する公開鍵証明書に記載された属性を用いて、前記決定を行う
   請求項１の認証方法。
5. 前記公開鍵証明書に記載される属性は、専用、汎用およびアプリの３つのうちのいずれかであり、
   属性が専用とは、コントローラが特定の目的のために専用の機能のみを提供することを示し、
   属性が汎用とは、コントローラが複数の目的に対してそれぞれの機能を提供することを示し、
   属性がアプリとは、コントローラが複数の目的に対してそれぞれの機能を提供する機器上で動作するソフトウェアであることを示し、
   属性が専用であるコントローラは、属性が汎用およびアプリであるコントローラよりも優先的にコーディネータになり、
   属性が汎用であるコントローラは、属性がアプリであるコントローラよりも優先的にコーディネータになる
   請求項４の認証方法。
6. 前記公開鍵証明書に記載された属性とは、バージョン情報であり、
   前記グループ内のコントローラは、それぞれが保持する公開鍵証明書に記載されたバージョン情報の示すバージョン番号の新しさに応じて、前記決定を行う
   請求項４の認証方法。
7. 前記公開鍵証明書に記載された属性とは、バージョン情報であり、
   前記グループ内のコントローラは、それぞれが保持する公開鍵証明書に記載されたバージョン情報の示す対応機器の数に応じて、前記決定を行う
   請求項４の認証方法。
8. 前記コントローラの属性は、前記コントローラの累積稼働時間である
   請求項１の認証方法。
9. 前記コントローラの属性は、前記コントローラの製造時からの経過時間である
   請求項１の認証方法。
10. 前記コントローラの属性は、前記コントローラとペアリングしている機器の数である
    請求項１の認証方法。
11. 前記グループ内のコントローラは、ディスプレイと操作部とを備えており、
    前記決定は、前記グループ内のコントローラが、前記グループ内の各コントローラの属性を示す情報を前記ディスプレイに表示し、前記表示に対して前記グループ内のコントローラから一コントローラを選択するユーザ入力を前記操作部で受け付け、選択されたコントローラを前記コーディネータとする処理である
    請求項１に記載の認証方法。
12. 接続部とネゴシエータと認証処理部を備えるコントローラであって、
    前記接続部は、ネットワーク上の１以上の機器と１以上の他コントローラとが所属するグループであって、前記他コントローラの中のーコントローラが、第１のグループ鍵を生成し、前記グループ内の機器と第１の相互認証を実行し、認証に成功した機器と前記第１のグループ鍵を共有しているグループに接続し、
    前記ネゴシエータは、前記グループ内で共通で利用するグループ鍵を管理するコーディネータを、前記グループ内のコントローラの中から決定し、
    前記認証処理部は、
    前記一コントローラと第２の相互認証を実行し、認証に成功した場合に前記第１のグループ鍵を受信し、前記第１のグループ鍵を用いて、前記グループ内で暗号通信を行い、
    さらに、自機器がコーディネータと決定された場合、前記第１のグループ鍵の有効時聞が所定の値よりも小さくなったときに、第２のグループ鍵を生成し、前記一コントローラから前記グループ内の機器の認証情報を受信し、受信した認証情報を用いて前記グループ内の機器およびコントローラと第３の相互認証を実行し、認証に成功した機器およびコントローラのグループ鍵を前記第２のグループ鍵に更新させる
    コントローラ。
13. 認証処理部とネゴシエータとを備え、ネットワーク上の１以上の機器と１以上のコントローラとが所属するグループ内のコントローラであって、
    前記認証処理部は、第１のグループ鍵を生成し、前記グループ内の機器と第１の相互認証を実行し、認証に成功した機器と前記第１のグループ鍵を共有し、
    他コントローラが前記グループに新たに参入した場合において、前記ネゴシエータは、前記グループ内で共通で利用するグループ鍵を管理するコーディネータを、前記グループ内のコントローラの中から決定し、
    前記認証処理部は、
    前記コーディネータと第２の相互認証を実行し、認証に成功した場合に前記第１のグループ鍵を共有し、
    前記コーディネータに、前記グループ内の機器の認証情報を送信し、
    前記コーディネータと第３の相互認証を行い、認証に成功した場合に、前記第１のグループ鍵の有効時聞が所定の値以下となったときに前記コーディネータが生成した第２のグループ鍵を受信し、保持するグループ鍵を受信した第２のグループ鍵に更新する
    コントローラ。

Images