JP6903786B2 - 管理装置、および管理方法 - Google Patents

Description

本発明の実施形態は、管理装置、および管理方法に関する。

複数の通信装置が受信するマルチキャスト通信の通信内容を保護するために、複数の通信装置で共有するグループ鍵を利用する方法がある。また、グループ鍵を管理する管理装置から複数の通信装置に対してグループ鍵を配布する技術が知られている。この技術では、例えばデバイス鍵を用いてグループ鍵を配布することで、管理装置から各通信装置に対して個別にグループ鍵を配布するよりも、少ない通信コストでグループ鍵を配布できる。

IEEE Std 802.21d-2015， 802.21d-2015-IEEE Standard for Local and metropolitan area networks--Part 21: Media Independent Handover Services Amendment 4: Multicast Group Management. RFC 6407， The Group Domain of Interpretation. ISO/IEC 11770-5:2011 Information technology--Security techniques--Key management--Part 5: Group key management.

システムの安全性を維持するためには、定期的にデバイス鍵を更新することが望ましい。しかしながら、例えば２者間による認証付鍵交換プロトコルを利用したデバイス鍵の再配布では、通信装置の数が多い場合、すべての通信装置のデバイス鍵を更新するまでに多くの時間を要する。このように従来技術では、すべての通信装置のデバイス鍵の更新が完了するまでグループ鍵を配布できず、システムの可用性が下がる場合があった。

実施形態の管理装置は、管理木記憶部と管理木更新部と選択部と送信部とを備える。管理木記憶部は、ノード鍵が割り当てられた複数のノードを含む二分木を記憶する。管理木更新部は、ノード鍵を更新する。選択部は、グループに含まれる通信装置に対応する二分木の葉ノードを含む部分木であって、割り当てられたノード鍵がすべて更新前である葉ノードのみを含む第１の部分木、および、割り当てられたノード鍵がすべて更新後である葉ノードのみを含む第２の部分木のうち少なくとも一方を選択する。送信部は、選択された部分木の根ノードのノード鍵で暗号化したグループ鍵を送信する。

第１の実施形態に係る通信システムのブロック図。 第１の実施形態に係る管理装置のブロック図。 ＣＳ（Complete Subtree）法のための管理木の一例を示す図。 第１の実施形態の管理木のノードに割り当てられる情報の一例を示す図。 第１の実施形態に係る通信装置のブロック図。 第１の実施形態におけるデバイス鍵更新処理のシーケンス図。 第１の実施形態のデバイス鍵更新処理のフローチャート。 第１の実施形態の管理木更新事前処理のフローチャート。 第１の実施形態の管理木更新処理のフローチャート。 第１の実施形態のグループ更新処理のフローチャート。 第１の実施形態のノード鍵選択処理のフローチャート。 第１の実施形態の通信装置のデバイス鍵更新処理のフローチャート。 第１の実施形態の通信装置のグループ更新処理のフローチャート。 変形例１の管理木更新処理のフローチャート。 変形例１のノード鍵選択処理のフローチャート。 変形例２のノード鍵選択処理のフローチャート。 変形例３の通信システムの構成例を示すブロック図。 第２の実施形態に係る管理装置のブロック図。 第２の実施形態の管理木のノードに割り当てられる情報の一例を示す図。 第２の実施形態の管理木更新事前処理のフローチャート。 第２の実施形態の管理木更新処理のフローチャート。 第２の実施形態のノード鍵選択処理のフローチャート。 変形例５の管理木更新事前処理のフローチャート。 変形例５の管理木更新処理のフローチャート。 実施形態にかかる装置のハードウェア構成例を示す説明図。

以下に添付図面を参照して、この発明にかかる管理装置の好適な実施形態を詳細に説明する。

デバイス鍵を用いてグループ鍵を配布する技術として、デバイス鍵の構成方法とその利用方法が異なる複数の技術が知られている。例えばＩＥＥＥ ８０２．２１ｄでは、次のようなグループ鍵配布プロトコルが規定されている。グループを管理する管理装置は、各通信装置との間で、デバイス鍵と呼ばれるグループ鍵配布用の共通鍵を共有する。管理装置は、デバイス鍵を用いてグループ鍵を暗号化して送付する。これによりマルチキャストグループに所属する通信装置に対してのみグループ鍵を安全に送付することができる。

デバイス鍵の共有は、２者間による認証付鍵交換プロトコルなどの公知技術を用いることで実現できる。安全性を維持するためにデバイス鍵を更新する場合、上記のように、すべてのデバイス鍵の更新が完了するまでグループ鍵を配布できず、システムの可用性が下がる場合があった。そこで、以下の各実施形態では、すべての通信装置のデバイス鍵の更新が完了する前であってもグループ鍵の配布を可能とする。

（第１の実施形態）
図１は、第１の実施形態に係る通信システム１０の構成例を示すブロック図である。図１に示すように、通信システム１０は、管理装置１００と、通信装置２００ａ〜２００ｅとを有する。通信装置２００ａ〜２００ｅは、同様の機能を備えるため、以下では区別する必要がない場合は単に通信装置２００という場合がある。通信装置２００の個数は５に限られるものではなく、任意の個数でよい。

管理装置１００は、複数の通信装置２００を制御する通信制御装置である。管理装置１００は、例えば、各通信装置２００との間で共有するデバイス鍵を用いてグループ鍵を配布する機能を有する。管理装置１００と通信装置２００はネットワークを介して接続される。ネットワークは、有線ネットワーク、無線ネットワーク、その他任意の形態のネットワークでよい。

管理装置１００と各通信装置２００との間では、相互認証と鍵共有を行う認証付鍵交換プロトコルが実施される。管理装置１００は、認証付鍵交換プロトコルの結果として確立された共有鍵を用いてデバイス鍵を暗号化し、暗号化したデバイス鍵を通信装置２００に送付することで、管理装置１００と各通信装置２００の間でデバイス鍵が共有される。管理装置１００は、暗号通信で使用するグループ鍵をデバイス鍵の一部を用いて暗号化して各通信装置２００に配布する。認証付鍵交換プロトコルの一例として、ＲＦＣ５１９１方式など様々な公知技術が知られている。

図２は、第１の実施形態に係る管理装置１００の機能構成例を示すブロック図である。図２に示すように、管理装置１００は、受信部１０１と、送信部１０２と、グループ情報記憶部１２１と、機器情報記憶部１２２と、証明書記憶部１２３と、管理木記憶部１２４と、鍵交換部１１１と、管理木更新部１１２と、選択部１１３と、グループ更新部１１４と、を有する。

受信部１０１は、他の管理装置および通信装置２００などの外部装置から各種情報を受信する。例えば受信部１０１は、外部装置からグループ更新要求を受信する。

送信部１０２は、他の管理装置および通信装置２００などの外部装置に各種情報を送信する。例えば送信部１０２は、暗号化したグループ鍵を、対応するグループに属する通信装置２００に送信する。

グループ情報記憶部１２１は、通信装置２００が属するグループを管理するグループ情報を記憶する。例えばグループ情報記憶部１２１は、グループを識別する識別情報（グループＩＤ）と、グループ鍵と、そのグループＩＤで識別されるグループに所属するメンバである通信装置２００を識別する識別情報（機器ＩＤ）との組であるグループ情報を記憶する。

機器情報記憶部１２２は、通信装置２００を管理する機器情報を記憶する。例えば機器情報記憶部１２２は、各通信装置２００の機器ＩＤと、その通信装置２００との間で共有したデバイス鍵との組である機器情報を記憶する。

証明書記憶部１２３は、認証付鍵交換に用いる証明書と、対応する秘密情報との組を記憶する。証明書は、公開鍵に対する証明書、および、事前共有鍵に対する証明書など、用いる相互認証方法に応じて選択すればよい。本実施形態では、管理装置１００は、正規の管理装置１００に対してのみ発行される証明書と対応する秘密情報を予め備えているとする。

管理木記憶部１２４は、デバイス鍵を管理するための管理木を記憶する。例えば管理木記憶部１２４は、ノード鍵が割り当てられた複数のノードを含む二分木である管理木を記憶する。以下に説明するように、複数のノード鍵の組がデバイス鍵に相当する。

図３は、８台の通信装置２００のデバイス鍵を管理するＣＳ（Complete Subtree）法のための管理木の一例を示す図である。図３に示すように、管理木は、葉ノードを８つ持つ二分木となっており、ａ１からａ１５の１５個のノードで構成される。親ノードを持たないノードａ１を根ノードと呼び、子ノードを持たないノードａ８からａ１５を葉ノードと呼ぶ。各葉ノードには、１台の通信装置が割り当てられる。ＣＳ法の管理木では、各ノードは、ノードを一意に識別する識別情報（ノードＩＤ）と、ノードごとに割り当てられる暗号鍵であるノード鍵を保持する。

各通信装置２００は、根ノードから自身が割り当てられた葉ノードまでの経路上のノードに割り当てられたノードＩＤと、ノード鍵との組を、管理装置１００よりデバイス鍵として与えられる。例えば、図３の通信装置２００ａは、ノードａ１、ａ２、ａ４、ａ８に割り当てられた４組のノードＩＤとノード鍵との組であるデバイス鍵を保持する。

グループ鍵を配布するとき、管理装置１００は、グループ鍵の配布対象となる通信装置２００に割り当てられた葉ノードのみを持つ部分木を求め、その部分木の根ノードに割り当てられたノード鍵を用いてグループ鍵を暗号化し、送付する。送付される暗号化したグループ鍵の組をグループ鍵データと呼ぶ。

例えば、通信装置２００ａ、２００ｂ、２００ｃ、２００ｄ、２００ｅ、２００ｆ、２００ｇ、２００ｈにグループ鍵を送付する場合、管理装置１００は、各通信装置２００に割り当てられた葉ノードａ８、ａ９、ａ１０、ａ１１、ａ１２、ａ１３、ａ１４、ａ１５のみを葉ノードに持つ部分木の根ノードａ１に割り当てられたノード鍵を用いてグループ鍵を暗号化した暗号文ｃを送付する。各通信装置２００は、ａ１に割り当てられたノード鍵をデバイス鍵の成分として保持しているため、暗号文ｃを復号することでグループ鍵を得ることができる。

また、通信装置２００ａ、２００ｅ、２００ｆ、２００ｇ、２００ｈにのみグループ鍵を送付する場合、管理装置１００は、ａ８のみを葉ノードに持つ部分木の根ノードａ８に割り当てられたノード鍵でグループ鍵を暗号化した暗号文ｃ１と、ａ１２、ａ１３、ａ１４、ａ１５のみを葉ノードにもつ部分木の根ノードａ３に割り当てられたノード鍵を用いてグループ鍵を暗号化した暗号文ｃ２と、を送付する。通信装置２００ａ、２００ｅ、２００ｆ、２００ｇ、２００ｈは、ａ８またはａ３に割り当てられたノード鍵をデバイス鍵の成分として保持しているため、ｃ１またはｃ２を復号することでグループ鍵を得ることができる。一方、他の通信装置２００ｂ、２００ｃ、２００ｄは、ａ８またはａ３に割り当てられたノード鍵を保持していないため、ｃ１とｃ２からグループ鍵を得ることができない。

このように、第１の実施形態では、ＣＳ法を応用して、所望の通信装置２００にのみグループ鍵を配布する。ＣＳ法では、管理装置１００は管理木を保持しており、通信装置２００はデバイス鍵を保持している。グループ鍵は、所望の通信装置２００に応じて選択されたデバイス鍵で暗号化される。ＣＳ法の詳細は、非特許文献１などに記載されている。

ＣＳ法は、ある通信装置２００に割り当てられたデバイス鍵が漏えいした場合、そのデバイス鍵を無効化する機能も備える。例えば、管理木の各ノードは、初期値０の無効化フラグを各々保持する。デバイス鍵が漏えいした場合、管理装置１００は、そのデバイス鍵に含まれるノードＩＤに対応するノードの無効化フラグを１に変更する。そして管理装置１００は、以降のグループ鍵配布では、無効化フラグが１のノードは利用しないようにする。これにより、デバイス鍵が無効化された通信装置２００は、以降、グループ鍵の配布を受けることはできないが、漏えいしたデバイス鍵を保持する攻撃者に対してもグループ鍵を秘匿できる。

これまでは、ＣＳ法の機能を説明するための最低限の処理のみを記述している。管理装置１００はこれ以外の処理を備えてもよい。例えば、上記の処理に加え、無効化済みのノードを利用しなければ、指定されたグループメンバにグループ鍵を配布できない場合は、指定されたメンバに無効化済みの通信装置２００が含まれる旨の警告を返すように管理装置１００を構成してもよい。

図４は、ノードに割り当てられる情報の一例を示す図である。図４に示すように、各ノードは、ノードＩＤおよびノード鍵に加えて、有効フラグおよび更新済フラグが割り当てられる。有効フラグおよび更新済フラグは、後述するように、デバイス鍵の更新状況の管理、および、デバイス鍵更新中におけるグループ鍵配布に用いられる情報である。

例えば有効フラグは、割り当てられたノード鍵が暗号化に使用できるか否かを判定するための判定情報として用いられる。有効フラグは、例えば割り当てられたノード鍵が暗号化に使用できる場合に１が設定され、使用できない場合に０が設定される。更新済フラグは、ノードに対応するノード鍵が更新されたか否かを示す情報である。更新済フラグは、例えばノード鍵が更新された場合に１が設定され、更新されていない場合に０が設定される。本実施形態では、有効フラグおよび更新済フラグは、管理木に含まれるすべてのノード（第１のノード）に対して割り当てられる。

図２に戻り、鍵交換部１１１は、認証付鍵交換プロトコルを実行する。例えば鍵交換部１１１は、証明書記憶部１２３に記憶された証明書を用いて、通信装置２００と相互認証を行い、管理装置１００と通信装置２００の２者間の共有鍵を確立する。鍵交換部１１１は、相互認証の相手となる通信装置２００の証明書が、正規の通信装置２００に対してのみ発行される証明書であるか、および、無効化済みの機器ではないかを検査することで、更新したデバイス鍵を割り当ててもよい機器であるか否かを検査する。

管理木更新部１１２は、各通信装置２００との間で共有したデバイス鍵の更新処理を行う。上記のように複数のノード鍵の組がデバイス鍵に相当するため、各ノードのノード鍵を更新することが、デバイス鍵を更新することに相当する。

選択部１１３は、グループ鍵の配布対象となる通信装置２００に割り当てられた葉ノードのみを持つ部分木を、管理木の部分木から選択する。選択部１１３は、例えば、グループに含まれる通信装置２００に対応する葉ノードを含む部分木であって、割り当てられたノード鍵がすべて更新前である葉ノードのみを含む部分木（第１の部分木）、および、割り当てられたノード鍵がすべて更新後である葉ノードのみを含む部分木（第２の部分木）のうち少なくとも一方を選択する。

例えば選択部１１３は、まず、ＣＳ法に基づいてグループに含まれる通信装置２００に対応する管理木の葉ノードを含む部分木を選択する。選択部１１３は、ＣＳ法により選択した部分木から、判定情報を参照してノード鍵が暗号化に使用できると判定されたノードを含む部分木を選択する。すなわち選択部１１３は、判定情報として有効フラグを参照して、ノード鍵が暗号化に使用できることを示す有効フラグ（有効フラグ＝１）が割り当てられたノードを含む部分木を選択する。

グループ更新部１１４は、グループ更新処理を実行する。例えばグループ更新部１１４は、管理木記憶部１２４が記憶する管理木と、機器情報記憶部１２２が記憶する機器情報と、グループ情報記憶部１２１が記憶するグループ情報と、グループに属すべき通信装置２００の情報と、を参照して、グループに属すべき通信装置２００にのみグループ鍵を配布するための情報（グループ鍵データ）を生成する。グループ鍵データは、例えば送信部１０２により、対応するグループに属する通信装置２００に送信される。

上記各部（受信部１０１、送信部１０２、鍵交換部１１１、管理木更新部１１２、選択部１１３、グループ更新部１１４）は、例えば、１または複数のプロセッサにより実現される。例えば上記各部は、ＣＰＵ（Central Processing Unit）などのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。上記各部は、専用のＩＣ（Integrated Circuit）などのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち１つを実現してもよいし、各部のうち２以上を実現してもよい。

なお、各記憶部（グループ情報記憶部１２１、機器情報記憶部１２２、証明書記憶部１２３、管理木記憶部１２４）は、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。

図５は、第１の実施形態に係る通信装置２００の機能構成例を示すブロック図である。図５に示すように、通信装置２００は、受信部２０１と、送信部２０２と、グループ情報記憶部２２１と、デバイス鍵記憶部２２２と、証明書記憶部２２３と、鍵交換部２１１と、デバイス鍵更新部２１２と、グループ更新部２１３と、を有する。

受信部２０１は、管理装置１００などの外部装置から各種情報を受信する。例えば受信部２０１は、管理装置１００からデバイス鍵の更新要求、更新するデバイス鍵、および、グループ鍵データなどを受信する。送信部２０２は、管理装置１００などの外部装置に各種情報を送信する。

グループ情報記憶部２２１は、通信装置２００が属するグループを管理するグループ情報を記憶する。例えばグループ情報記憶部２２１は、メンバとして属するグループのグループＩＤとグループ鍵との組であるグループ情報を記憶する。デバイス鍵記憶部２２２は、管理装置１００から割り当てられたデバイス鍵を記憶する。

証明書記憶部２２３は、認証付鍵交換に用いる証明書と、対応する秘密情報との組を記憶する。証明書は、公開鍵に対する証明書、および、事前共有鍵に対する証明書など、用いる相互認証方法に応じて選択すればよい。本実施形態では、通信装置２００は、管理装置１００に対してのみ発行される証明書と対応する秘密情報を予め備えているとする。

鍵交換部２１１は、認証付鍵交換プロトコルを実行する。例えば鍵交換部２１１は、証明書記憶部２２３に記憶された証明書を用いて、管理装置１００と相互認証を行い、管理装置１００と通信装置２００の２者間の共有鍵を確立する。鍵交換部２１１は、相互認証の相手となる通信装置２００の証明書が、正規の管理装置１００に対してのみ発行される証明書であるか否かを検査することで、デバイス鍵を更新する資格がある管理装置１００であるか否かを検査する。

デバイス鍵更新部２１２は、デバイス鍵の更新処理を実行する。グループ更新部２１３は、グループ鍵の更新処理を実行する。

上記各部（受信部２０１、送信部２０２、鍵交換部２１１、デバイス鍵更新部２１２、グループ更新部２１３）は、例えば、１または複数のプロセッサにより実現される。例えば上記各部は、ＣＰＵなどのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。上記各部は、専用のＩＣなどのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち１つを実現してもよいし、各部のうち２以上を実現してもよい。

なお、各記憶部（グループ情報記憶部２２１、デバイス鍵記憶部２２２、証明書記憶部２２３）は、ＨＤＤ、光ディスク、メモリカード、ＲＡＭなどの一般的に利用されているあらゆる記憶媒体により構成することができる。

次に、このように構成された第１の実施形態にかかる通信システム１０によるデバイス鍵更新処理の概要について図６を用いて説明する。図６は、第１の実施形態におけるデバイス鍵更新処理の一例を示すシーケンス図である。管理装置１００は、無効化されていないすべての通信装置２００との間で、図６に示すデバイス鍵更新処理を実行する。

管理装置１００は、通信装置２００に対してデバイス鍵更新要求を送信し（ステップＳ１１）、認証付鍵交換処理を行う（ステップＳ１２）。認証付鍵交換処理が成功したら、管理装置１００と通信装置２００との間で、共有鍵Ｋが確立される。本実施形態では、共有鍵Ｋの確立に失敗したら、以降の手順は行われないものとする。失敗した場合は一定回数まではデバイス鍵更新要求を再送し、処理をやり直すように構成してもよい。

管理装置１００は、通信装置２００に対して新たに割り当てる更新後デバイス鍵を算出し、共有鍵Ｋで更新後デバイス鍵を暗号化した暗号化デバイス鍵を送信する（ステップＳ１３）。

通信装置２００は、共有鍵Ｋを用いて、暗号化デバイス鍵を正常に復号し、デバイス鍵を取得できたら、受領通知を管理装置１００に送信する（ステップＳ１４）。本実施形態では、デバイス鍵の取得に失敗したら、以降の手順は行われないものとする。失敗した場合は一定回数まで失敗通知を送信し、認証付鍵交換処理等の前の処理をやり直すように構成してもよい。

以下、デバイス鍵更新処理の詳細についてさらに説明する。図７は、管理装置１００内でのデバイス鍵更新処理の一例を示すフローチャートである。

受信部１０１は、デバイス鍵更新要求を受信する（ステップＳ１０１）。デバイス鍵更新要求は、例えば、定期的に実行、および、システム危殆化時に実行など、別途定められたポリシーに基づき発行される。デバイス鍵更新要求は、管理装置１００内で発行されてもよいし、他の管理装置などで発行されてもよい。

デバイス鍵更新要求が受信された場合、管理装置１００の管理木更新部１１２は、デバイス鍵更新処理を開始する。管理木更新部１１２は、現時点で無効化されていないすべての通信装置２００の機器ＩＤを含むリストＬを作成する（ステップＳ１０２）。

管理木更新部１１２は、管理木更新事前処理を実行する（ステップＳ１０３）。管理木更新事前処理の詳細は後述する。

管理木更新部１１２は、リストＬより通信装置２００の機器ＩＤを１つ選択する（ステップＳ１０４）。選択した機器ＩＤに対応する通信装置２００を以下では通信装置ｘともいう。

鍵交換部１１１は、通信装置ｘとの間で認証付鍵交換を実行して共有鍵Ｋを確立する（ステップＳ１０５）。管理木更新部１１２は、認証付鍵交換に成功したか否かを判定する（ステップＳ１０６）。成功した場合（ステップＳ１０６：Ｙｅｓ）、管理木更新部１１２は、デバイス鍵とデバイス鍵の管理木を更新する管理木更新処理を実行する（ステップＳ１０７）。管理木更新処理の詳細は後述する。なお以下では更新後デバイス鍵のリストをＬ＿ｎｄｋと記載する。

管理木更新部１１２は、共有鍵Ｋを用いてリストＬ＿ｎｄｋに含まれる各更新後デバイス鍵を暗号化した暗号化デバイス鍵を生成する（ステップＳ１０８）。送信部１０２は、暗号化デバイス鍵を通信装置２００に送信する（ステップＳ１０９）。

認証付鍵交換に失敗した場合（ステップＳ１０６：Ｎｏ）、および、暗号化デバイス鍵を送信後、管理木更新部１１２は、リストＬから通信装置ｘの機器ＩＤを取り除く（ステップＳ１１０）。

受信部１０１は、グループの更新要求を受信したか否かを判定する（ステップＳ１１１）。グループ更新要求を受信した場合（ステップＳ１１１：Ｙｅｓ）、グループ更新部１１４は、グループ更新処理を実行する（ステップＳ１１２）。グループ更新処理の詳細は後述する。

グループ更新要求を受信していない場合（ステップＳ１１１：Ｎｏ）、および、グループ更新処理の実行後、管理木更新部１１２は、リストＬが空であるか否かを判定する（ステップＳ１１３）。リストＬが空でない場合（ステップＳ１１３：Ｎｏ）、ステップＳ１０４に戻り処理が繰り返される。リストＬが空の場合（ステップＳ１１３：Ｙｅｓ）、デバイス鍵更新処理が終了する。

以上の処理により、機器情報記憶部１２２に記憶されたデバイス鍵と管理木記憶部１２４に記憶された管理木が更新され、各通信装置２００に更新後のデバイス鍵が送信される。

本実施形態では、デバイス鍵更新処理の中で、グループの更新要求が受信されたかが判定され、受信された場合にグループ更新処理が実行される（ステップＳ１１１、ステップＳ１１２）。グループ更新処理では、更新前のデバイス鍵と更新後のデバイス鍵を使い分けてグループ鍵が配布される。これにより、すべての通信装置２００のデバイス鍵の更新が完了する前であってもグループ鍵を配布可能となる。

なお、図７の例では、１つの通信装置２００に対応するデバイス鍵を更新するごとに、グループの更新要求が受信されたか判定した。更新要求の判定処理およびグループ更新処理のタイミングはこれに限られず、デバイス鍵の更新中にグループ更新処理が実行できれば任意のタイミングでよい。例えば、複数の通信装置２００のデバイス鍵が更新されたタイミングでもよい。１つの通信装置２００のデバイス鍵の更新処理のループの中で複数回、更新要求の判定処理およびグループ更新処理が実行されてもよい。更新要求の判定処理およびグループ更新処理を、デバイス鍵更新処理のフローの中で実行せず、デバイス鍵更新処理とは独立に任意のタイミングで実行するように構成してもよい。

図８は、管理木更新事前処理の一例を示すフローチャートである。管理木更新部１１２は、管理木記憶部１２４に記憶されている管理木のすべてのノードの更新済フラグを０に設定し（ステップＳ２０１）、有効フラグを１に設定する（ステップＳ２０２）。

図９は、管理木更新処理の一例を示すフローチャートである。管理木更新部１１２は、管理木記憶部１２４から管理木を読み出す（ステップＳ３０１）。管理木更新部１１２は、更新後デバイス鍵を記録するリストＬ＿ｎｄｋに空集合を代入して初期化する（ステップＳ３０２）。管理木更新部１１２は、通信装置ｘに割り当てられたデバイス鍵に含まれるすべてのノードＩＤをリストＬ＿ｄｋに記録する（ステップＳ３０３）。

説明のため、通信装置ｘに割り当てられたデバイス鍵に含まれるすべてのノードＩＤをｎＩＤ＿０，・・・，ｎＩＤ＿ｎと表す。例えば図３の通信装置２００ａが通信装置ｘである場合、ノードａ１、ａ２、ａ４、ａ８に対応する４つのノードＩＤ（ｎＩＤ＿０、ｎＩＤ＿１、ｎＩＤ＿２、ｎＩＤ＿３）がリストＬ＿ｄｋに記録される。

管理木更新部１１２は、リストＬ＿ｄｋに含まれるノードＩＤのうち、管理木中で最も深いノードのノードＩＤを読み出す（ステップＳ３０４）。ここでは、読み出したノードＩＤをｎＩＤ＿ｉと表す。例えば図３の通信装置２００ａが通信装置ｘである場合、最初の処理では、最も深い位置のノードａ８のノードＩＤが読み出される。

管理木更新部１１２は、ｎＩＤ＿ｉに対応する更新済フラグが０であるか否かを判定する（ステップＳ３０５）。ｎＩＤ＿ｉに対応する更新済フラグが０である場合（ステップＳ３０５：Ｙｅｓ）、管理木更新部１１２は、ノード鍵ｎｋ＿ＩＤ＿ｉを新たに生成し、ｎＩＤ＿ｉに対応するノード鍵を、生成したノード鍵ｎｋ＿ＩＤ＿ｉに更新する（ステップＳ３０６）。管理木更新部１１２は、ｎＩＤ＿ｉに対応する更新済フラグを１に設定する（ステップＳ３０７）。

更新済フラグが０でない、すなわち、１である場合（ステップＳ３０５：Ｎｏ）、または、ステップＳ３０７で更新済フラグを１に設定した後、管理木更新部１１２は、ｎＩＤ＿ｉが葉ノードであるか否かを判定する（ステップＳ３０８）。ｎＩＤ＿ｉが葉ノードでない場合（ステップＳ３０８：Ｎｏ）、管理木更新部１１２は、ｎＩＤ＿ｉの２つの子ノードの有効フラグが共に１であるか否かを判定する（ステップＳ３０９）。

ｎＩＤ＿ｉが葉ノードである場合（ステップＳ３０８：Ｙｅｓ）、または、ｎＩＤ＿ｉの２つの子ノードの更新済フラグが共に１である場合（ステップＳ３０９：Ｙｅｓ）、管理木更新部１１２は、ｎＩＤ＿ｉの有効フラグを１に設定する（ステップＳ３１１）。ｎＩＤ＿ｉの２つの子ノードの更新済フラグの少なくともいずれか１つが０の場合（ステップＳ３０９：Ｎｏ）、管理木更新部１１２は、ｎＩＤ＿ｉの有効フラグを０に設定する（ステップＳ３１０）。

図９の例では、ノードが葉ノードであるか、または、２つの子ノードに割り当てられたノード鍵が共に更新済みであるか、または、２つの子ノードに割り当てられたノード鍵が共に更新前である場合に、有効フラグが１に設定される。このように設定された有効フラグを用いれば、ノード鍵を更新していないノードとノード鍵を更新したノードとを子ノードとして含むノードに対応するノード鍵を、グループ鍵の暗号化に使用しないように制御可能となる。

管理木更新部１１２は、リストＬ＿ｎｄｋに、ｎＩＤ＿ｉとノード鍵ｎｋ＿ＩＤ＿ｉとを追加する（ステップＳ３１２）。管理木更新部１１２は、リストＬ＿ｄｋから、ｎＩＤ＿ｉを削除する（ステップＳ３１３）。

管理木更新部１１２は、リストＬ＿ｄｋが空であるか否かを判定する（ステップＳ３１４）。リストＬ＿ｄｋが空でない場合（ステップＳ３１４：Ｎｏ）、ステップＳ３０４に戻り処理が繰り返される。リストＬ＿ｄｋが空である場合（ステップＳ３１４：Ｙｅｓ）、管理木更新処理を終了する。

このようにして設定された有効フラグは、後述するグループ更新処理の中で、ノード鍵が使用できるか判定するときに参照される。管理木更新処理の中で有効フラグを設定しておくことにより、グループ更新処理の中でノード鍵が使用できるか判定する処理の負荷を軽減可能となる。

図１０は、グループ更新処理の一例を示すフローチャートである。グループ更新部１１４は、更新後のグループに所属させるすべての通信装置２００の機器ＩＤを記録したリストＬ＿ｍを生成する（ステップＳ４０１）。選択部１１３は、ノード鍵選択処理を行い、ノードＩＤのリストＬ＿ｃｓを生成する（ステップＳ４０２）。リストＬ＿ｃｓには、割り当てられたノード鍵がすべて更新前である葉ノードのみを含む部分木（第１の部分木）の根ノードのノードＩＤ、および、割り当てられたノード鍵がすべて更新後である葉ノードのみを含む部分木（第２の部分木）の根ノードのノードＩＤの少なくとも一方が登録される。ノード鍵選択処理の詳細は後述する。

グループ更新部１１４は、更新後のグループで利用するグループ鍵を生成する（ステップＳ４０３）。グループ更新部１１４は、生成したグループ鍵を、リストＬ＿ｃｓに記録された１以上のノードＩＤに対応する１以上のノード鍵でそれぞれ暗号化してグループ鍵データを生成する（ステップＳ４０４）。送信部１０２は、グループ鍵データと更新対象のグループを識別するグループＩＤとを含む情報（グループ更新情報）を、例えば、更新対象の通信装置２００を含むマルチキャストグループに対して配布する（ステップＳ４０５）。

図１１は、ノード鍵選択処理の一例を示すフローチャートである。選択部１１３は、リストＬ＿ｃｓに空集合を代入して初期化する（ステップＳ５０１）。選択部１１３は、リストＬ＿ｍ、および、管理木を読み出す（ステップＳ５０２）。選択部１１３は、リストＬ＿ｍと管理木から、ＣＳ法によりノードＩＤのリストＬ＿ｔｃｓを算出する（ステップＳ５０３）。

上記のように、ＣＳ法では、グループ鍵の配布対象となる通信装置２００（リストＬ＿ｍに機器ＩＤが記録された通信装置２００）に割り当てられた葉ノードのみを持つ部分木が求められる。リストＬ＿ｔｃｓには、このようにして求められた部分木の根ノードのノードＩＤが記録される。

選択部１１３は、リストＬ＿ｔｃｓからノードＩＤを１つ読み出す（ステップＳ５０４）。読み出されたノードＩＤをｎＩＤと記載する。選択部１１３は、ｎＩＤに対応する有効フラグが１であるか否かを判定する（ステップＳ５０５）。ｎＩＤに対応する有効フラグが１である場合（ステップＳ５０５：Ｙｅｓ）、選択部１１３は、ｎＩＤをリストＬ＿ｃｓに追加する（ステップＳ５０６）。ｎＩＤに対応する有効フラグが０である場合（ステップＳ５０５：Ｎｏ）、選択部１１３は、ｎＩＤの２つの子ノードのノードＩＤ（ｃｎＩＤ１、ｃｎＩＤ２）をリストＬ＿ｔｃｓに追加する（ステップＳ５０７）。選択部１１３は、ｎＩＤをリストＬ＿ｔｃｓから削除する（ステップＳ５０８）。

選択部１１３は、リストＬ＿ｔｃｓが空であるか否かを判定する（ステップＳ５０９）。リストＬ＿ｔｃｓが空でない場合（ステップＳ５０９：Ｎｏ）、ステップＳ５０４に戻り処理が繰り返される。リストＬ＿ｔｃｓが空である場合（ステップＳ５０９：Ｙｅｓ）、ノード鍵選択処理を終了する。

次に、通信装置２００内でのデバイス鍵更新処理について説明する。図１２は、通信装置２００のデバイス鍵更新処理の一例を示すフローチャートである。

受信部２０１は、デバイス鍵更新要求を受信する（ステップＳ６０１）。デバイス鍵更新要求は、例えば、管理装置１００から発行される。デバイス鍵更新要求は、定期的に実行、システム危殆化時に実行など、別途定められたポリシーに基づき発行されてもよい。

デバイス鍵更新要求が受信されると、鍵交換部２１１は、管理装置１００との間で認証付鍵交換を実行して共有鍵Ｋを確立する（ステップＳ６０２）。デバイス鍵更新部２１２は、認証付鍵交換が成功したか否かを判定する（ステップＳ６０３）。

認証付鍵交換に成功した場合（ステップＳ６０３：Ｙｅｓ）、受信部２０１は、管理装置１００から暗号化デバイス鍵を受信する（ステップＳ６０４）。デバイス鍵更新部２１２は、受信された暗号化デバイス鍵を、共有鍵Ｋを用いて復号する（ステップＳ６０５）。

デバイス鍵更新部２１２は、復号が成功したか否かを判定する（ステップＳ６０６）。復号に成功した場合（ステップＳ６０６：Ｙｅｓ）、デバイス鍵更新部２１２は、デバイス鍵記憶部２２２に記憶されているデバイス鍵を、復号により得られたデバイス鍵で更新し（ステップＳ６０７）、デバイス鍵更新処理を終了する。デバイス鍵更新部２１２は、更新に成功したことを管理装置１００などに通知してからデバイス鍵更新処理を終了してもよい。

認証付鍵交換に失敗した場合（ステップＳ６０３：Ｎｏ）、または、復号に失敗した場合（ステップＳ６０６：Ｎｏ）、以降の処理を行わずにデバイス鍵更新処理を終了する。デバイス鍵更新部２１２は、更新に失敗したことを管理装置１００などに通知してからデバイス鍵更新処理を終了してもよい。

次に、通信装置２００内でのグループ更新処理について説明する。図１３は、通信装置２００のグループ更新処理の一例を示すフローチャートである。

受信部２０１は、更新対象のグループを識別するグループＩＤとグループ鍵データとを含むグループ更新情報を受信する（ステップＳ７０１）。グループ更新部２１３は、デバイス鍵記憶部２２２に記憶されているデバイス鍵を用いてグループ鍵データの復号処理を行う（ステップＳ７０２）。

グループ更新部２１３は、復号に成功したか否かを判定する（ステップＳ７０３）。復号に成功した場合（ステップＳ７０３：Ｙｅｓ）、グループ更新部２１３は、グループＩＤと復号処理により得られたグループ鍵とをグループ情報記憶部２２１に記憶する処理、すなわち、グループに参加する処理を行う（ステップＳ７０４）。既にグループＩＤで指定されるグループに参加済みの場合は、グループ情報記憶部２２１にグループＩＤと対で記憶されているグループ鍵を、復号処理により得られたグループ鍵で更新する。

復号に失敗した場合（ステップＳ７０３：Ｎｏ）、グループ更新部２１３は、グループ情報記憶部２２１に記憶されているグループＩＤとグループ鍵とを削除する処理、すなわち、グループから離脱する処理を行う（ステップＳ７０５）。グループ情報記憶部２２１に対応するグループＩＤが記憶されていない場合は、この処理はスキップされる。

グループ更新処理を終了するときに、例えば送信部２０２が、グループに参加しているか、参加していないかを管理装置１００に通知するように構成してもよい。

（変形例１）
第１の実施形態では、管理木中のすべてのノードが更新済フラグと有効フラグを保持し、有効フラグを判定情報として用いた。判定情報はこれに限られるものではない。変形例１では、各ノードが更新済フラグのみを保持し、この更新済フラグが判定情報として用いられる。

図１４は、変形例１の管理木更新処理の一例を示すフローチャートである。変形例１の管理木更新処理は、ステップＳ３０８〜ステップＳ３１１、すなわち、有効フラグを設定するための処理が実行されない以外は、第１の実施形態の管理木更新処理を示す図９と同様であるため説明を省略する。

図１５は、変形例１のノード鍵選択処理の一例を示すフローチャートである。変形例１のノード鍵選択処理では、ステップＳ５０５〜ステップＳ５０７に代わり、ステップＳ９０５〜ステップＳ９０８が実行される。その他の処理は第１の実施形態のノード鍵選択処理を示す図１１と同様であるため説明を省略する。

以下、ステップＳ９０５〜ステップＳ９０８について説明する。選択部１１３は、ｎＩＤのノードを根ノードとする部分木のすべての葉ノードの更新済フラグが１であるか否かを判定する（ステップＳ９０５）。すべての葉ノードの更新済フラグが１でない場合（ステップＳ９０５：Ｎｏ）、選択部１１３は、ｎＩＤのノードを根ノードとする部分木のすべての葉ノードの更新済フラグが０であるか否かを判定する（ステップＳ９０６）。

すべての葉ノードの更新済フラグが１である場合（ステップＳ９０５：Ｙｅｓ）、または、すべての葉ノードの更新済フラグが０である場合（ステップＳ９０６：Ｙｅｓ）、選択部１１３は、ｎＩＤをリストＬ＿ｃｓに追加する（ステップＳ９０８）。すべての葉ノードの更新済フラグが０でない場合（ステップＳ９０６：Ｎｏ）、選択部１１３は、ｎＩＤの２つの子ノードのノードＩＤ（ｃｎＩＤ１、ｃｎＩＤ２）をリストＬ＿ｔｃｓに追加する（ステップＳ９０７）。

上記はあくまでも一例であり、別の等価な条件を用いて判定してもよい。例えば、ｎＩＤを根ノードとする部分木のすべての葉ノードの更新済フラグが等しいか否かを判定し、等しい場合はステップＳ９０８を実行し、等しくない場合はステップＳ９０７を実行するように構成してもよい。

このように構成することで、有効フラグを用いることなく、第１の実施形態と同様の結果を得ることができる。また、有効フラグを記憶する必要がないため、管理すべきデータ量を削減することが可能となる。

（変形例２）
第１の実施形態では、管理木とグループに属する通信装置２００の機器ＩＤのリストＬ＿ｍとを用いたＣＳ法を適用してリストＬ＿ｔｃｓを求め、リストＬ＿ｔｃｓと有効フラグとを用いてリストＬ＿ｃｓを作成した。リストＬ＿ｃｓの作成方法はこれに限られない。変形例２では、まず、グループに属するメンバであって対応する葉ノードの更新済フラグが１の通信装置２００の機器ＩＤからなるリストＬ＿ｍ１と、グループに属するメンバであって対応する葉ノードの更新済フラグが０の通信装置２００の機器ＩＤからなるリストＬ＿ｍ０とが作成される。リストＬ＿ｍ１と管理木とからＣＳ法によりノードＩＤのリストＬ＿ｔｃｓ１が生成され、リストＬ＿ｍ０と管理木とからＣＳ法によりノードＩＤのリストＬ＿ｔｃｓ０が生成される。リストＬ＿ｔｃｓ１とリストＬ＿ｔｃｓ０とをマージすることにより、リストＬ＿ｃｓが作成される。

図１６は、変形例２のノード鍵選択処理の一例を示すフローチャートである。選択部１１３は、リストＬ＿ｃｓ、リストＬ＿ｍ０、および、リストＬ＿ｍ１を空集合で初期化する（ステップＳ１００１）。選択部１１３は、リストＬ＿ｍ、および、管理木を読み出す（ステップＳ１００２）。

選択部１１３は、リストＬ＿ｍから更新済フラグが１の葉ノードを割り当てられた通信装置２００の機器ＩＤをすべて読み出し、読み出した機器ＩＤをリストＬ＿ｍ１に記録する（ステップＳ１００３）。選択部１１３は、リストＬ＿ｍ１と管理木から、ＣＳ法によりノードＩＤのリストＬ＿ｔｃｓ１を算出する（ステップＳ１００４）。

次に選択部１１３は、リストＬ＿ｍから更新済フラグが０の葉ノードを割り当てられた通信装置２００の機器ＩＤをすべて読み出し、読み出した機器ＩＤをリストＬ＿ｍ０に記録する（ステップＳ１００５）。選択部１１３は、リストＬ＿ｍ０と管理木から、ＣＳ法によりノードＩＤのリストＬ＿ｔｃｓ０を算出する（ステップＳ１００６）。選択部１１３は、リストＬ＿ｔｃｓ１とリストＬ＿ｔｃｓ０とをマージしたリストＬ＿ｃｓを生成する（ステップＳ１００７）。

ノード鍵選択処理を本変形例のように構成しても、第１の実施形態と同様に、リストＬ＿ｍに含まれる通信装置２００が保持するデバイス鍵のみで復号できるグループ鍵データを算出するために必要な、ノードＩＤのリストＬ＿ｃｓを導出できる。

（変形例３）
管理装置１００は、常時ネットワークに接続されていてもよいが、デバイス鍵の更新やグループ鍵の更新が必要になったときにのみ、通信装置２００が接続しているネットワークに接続するように構成してもよい。

また、デバイス鍵の更新時にはすべての通信装置２００と同時に接続されている必要はない。接続が必要となったときに、更新の対象となる通信装置２００と管理装置１００とを、例えばＵＳＢ（Universal Serial Bus）またはシリアル通信を用いて直接接続するように構成してもよい。このとき、管理装置１００は、第１の実施形態の機能をすべて同一の機器内で実現する必要はなく、グループ鍵更新機能を備えた機器と、デバイス鍵更新機能を備えた機器に分けて実現してもよい。

図１７は、変形例３の通信システムの構成例を示すブロック図である。図１７の破線は、常時接続ではなく、必要に応じて接続される通信路であることを示している。図１７では、グループ鍵更新機能を備えたグループ鍵更新装置４００と、デバイス鍵更新機能を備えたデバイス鍵更新装置３００と、により管理装置１００が実現される例が示されている。

（変形例４）
第１の実施形態では、判定情報として１ビットの更新済フラグを用いていたが、代わりにデバイス鍵の世代情報（バージョン情報など）を判定情報として用いてもよい。この場合、他のノードよりも新しい世代情報を持つノードは更新済フラグ＝１に相当すると解釈し、他のノードよりも古い世代情報を持つノードは更新済フラグ＝０であると解釈すればよい。

このように、第１の実施形態では、判定情報（有効フラグ、更新済フラグなど）を用いて、グループ鍵の暗号化に使用できるノード鍵（デバイス鍵）を判定する。これにより、すべての通信装置２００のデバイス鍵の更新が完了する前であってもグループ鍵を配布することが可能となる。

（第２の実施形態）
第２の実施形態では、デバイス鍵の更新を行う際に、更新後の管理木において、更新前とは別の葉ノードを通信装置に割り当てる。通信装置を割り当てる葉ノードの位置は、同一のグループに属する頻度の高い通信装置同士ができるだけ近い祖先ノードを持つように、例えば、これまでのグループメンバの構成、および、グループ鍵配布に要した通信コストなどの情報をもとに決定される。このようにデバイス鍵を更新することで、デバイス鍵の更新後、グループ鍵の配布に要する通信コストを削減することが可能となる。

上記の割り当て位置の決定法はあくまでも一例である。通信履歴、更新前のシステム構成、および、更新後のシステム構成などから、更新後のシステムで行われるグループ鍵配布に要するグループ鍵データのサイズを削減できるように、各通信装置に割り当てる葉ノードの位置を決定すればよい。

第２の実施形態の通信システムの構成は、図１と同様であるため説明を省略する。第２の実施形態では、管理装置の機能が第１の実施形態と異なっている。通信装置は第１の実施形態と同様であるため同一の符号を付し説明を省略する。

図１８は、第２の実施形態に係る管理装置１００−２の機能構成例を示すブロック図である。図１８に示すように、管理装置１００−２は、受信部１０１と、送信部１０２と、グループ情報記憶部１２１と、機器情報記憶部１２２と、証明書記憶部１２３と、管理木記憶部１２４−２と、鍵交換部１１１と、管理木更新部１１２−２と、選択部１１３−２と、グループ更新部１１４と、を有する。

第２の実施形態では、管理木記憶部１２４−２、管理木更新部１１２−２、および、選択部１１３−２が第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態にかかる管理装置１００のブロック図である図２と同様であるので、同一符号を付し、ここでの説明は省略する。

管理木記憶部１２４−２は、デバイス鍵を管理するための管理木を記憶する。本実施形態では、管理木の各ノードが保持する情報が、第１の実施形態と異なる。図１９は、第２の実施形態の管理木のノードに割り当てられる情報の一例を示す図である。図１９に示すように、各ノードは、ノードＩＤと、ノード鍵と、有効フラグとが割り当てられる。

また、本実施形態では、デバイス鍵を更新する前の管理木（更新前管理木）と、デバイス鍵を更新した後の管理木（更新後管理木）とが、管理木記憶部１２４−２に記憶される。すなわち、管理木記憶部１２４−２は、更新前のノード鍵が割り当てられた複数のノードを含む更新前管理木（第１の二分木）と、更新後のノード鍵が割り当てられた複数のノードを含む更新後管理木（第２の二分木）とを記憶する。

管理木更新部１１２−２は、各通信装置２００との間で共有したデバイス鍵の更新処理を行う。例えば管理木更新部１１２−２は、同じグループに属する複数の通信装置２００に対応する複数の葉ノードの祖先ノードが、更新前管理木よりも葉ノードに近くなるように更新後管理木を生成して管理木記憶部１２４−２に記憶させる。

選択部１１３−２は、グループ鍵の配布対象となる通信装置２００に割り当てられた葉ノードのみを持つ部分木を、管理木の部分木から選択する。選択部１１３−２は、例えば、グループに含まれる通信装置２００に対応する葉ノードを含む更新前管理木の部分木（第１の部分木）、および、グループに含まれる通信装置２００に対応する葉ノードを含む更新後管理木の部分木（第２の部分木）のうち少なくとも一方を選択する。

次に、このように構成された第２の実施形態にかかる通信システムによるデバイス鍵更新処理について説明する。第２の実施形態のデバイス鍵更新処理の全体の流れは、第１の実施形態の図６および図７と同様であるため説明を省略する。

第２の実施形態では、管理木更新事前処理（図７のステップＳ１０３）、管理木更新処理（図７のステップＳ１０７）、および、グループ更新処理（図７のステップＳ１１２）が、第１の実施形態と異なる。他の処理は第１の実施形態と同じであるため、説明を省略する。

図２０は、第２の実施形態の管理木更新事前処理の一例を示すフローチャートである。管理木更新部１１２−２は、最新の管理木を更新前管理木として管理木記憶部１２４−２に記憶する（ステップＳ１１０１）。管理木更新部１１２−２は、更新前管理木を複製して更新後管理木を生成する（ステップＳ１１０２）。管理木更新部１１２−２は、更新後管理木の各ノードに割り当てられたノード鍵を新たに生成した鍵で更新する（ステップＳ１１０３）。鍵を生成する方法は、ランダムに鍵を生成する方法などの任意の方法を適用できる。管理木更新部１１２−２は、更新後管理木の各ノードが保持する有効フラグを０に設定してすべてのノードを無効化する（ステップＳ１１０４）。管理木更新部１１２−２は、更新後管理木を例えば管理木記憶部１２４−２に記憶して管理木更新事前処理を終了する。

図２１は、第２の実施形態の管理木更新処理の一例を示すフローチャートである。管理木更新部１１２−２は、管理木記憶部１２４−２から、更新前管理木を読み出す（ステップＳ１２０１）。管理木更新部１１２−２は、更新前の通信装置ｘのデバイス鍵（更新前デバイス鍵）に割り当てられたノードを記憶するリストＬ＿ｄｋと、更新後デバイス鍵を記憶するリストＬ＿ｎｄｋと、を空集合で初期化する（ステップＳ１２０２）。管理木更新部１１２−２は、通信装置ｘに割り当てられた更新前デバイス鍵に含まれるノードＩＤをリストＬ＿ｄｋに記録する（ステップＳ１２０３）。

管理木更新部１１２−２は、更新後管理木の葉ノードのうち、有効フラグが０の葉ノードｌｅａｆを１つ選択し、通信装置ｘを割り当てる葉ノードとする（ステップＳ１２０４）。上記のように、選択する葉ノードの位置は、履歴情報や選択法のポリシーに基づいて適切に選択される。

管理木更新部１１２−２は、更新後管理木の根ノードからｌｅａｆまでの経路上のノードに割り当てられたノードＩＤとノード鍵との組を、リストＬ＿ｎｄｋに記録する（ステップＳ１２０５）。

管理木更新部１１２−２は、更新後管理木のノードであってリストＬ＿ｎｄｋに記録されているノードＩＤで特定されるノードの有効フラグを１に設定する（ステップＳ１２０６）。また管理木更新部１１２−２は、更新前管理木のノードであって、リストＬ＿ｄｋに記録されているノードＩＤで特定されるノードの有効フラグを０に設定する（ステップＳ１２０７）。

次に、第２の実施形態のグループ更新処理について説明する。管理装置１００−２は、図７のステップＳ１１２のグループ更新処理で、図１０に示す第１の実施形態と同様のグループ更新処理を行う。第２の実施形態では、図１０のステップＳ４０２のノード鍵選択処理が第１の実施形態と異なる。以下では、第２の実施形態のノード鍵選択処理を説明し、他の処理の説明は省略する。

図２２は、第２の実施形態のノード鍵選択処理の一例を示すフローチャートである。選択部１１３−２は、リストＬ＿ｃｓ、リストＬ＿ｍ０、リストＬ＿ｍ１を空集合で初期化する（ステップＳ１３０１）。本実施形態では、リストＬ＿ｍ０は、グループに属するメンバであって対応する更新前管理木の葉ノードの有効フラグが１の通信装置２００の機器ＩＤを記録するリストである。また、リストＬ＿ｍ１は、グループに属するメンバであって対応する更新後管理木の葉ノードの有効フラグが１の通信装置２００の機器ＩＤを記録するリストである。

選択部１１３−２は、グループに所属させる通信装置の機器ＩＤのリストＬ＿ｍ、更新前管理木、および、更新後管理木を読み出す（ステップＳ１３０２）。選択部１１３−２は、更新前管理木の葉ノードのうち、有効フラグが１の葉ノードが割り当てられた通信装置２００を特定し、特定した通信装置２００のうちリストＬ＿ｍに含まれる通信装置２００をリストＬ＿ｍ０に記録する（ステップＳ１３０３）。選択部１１３−２は、リストＬ＿ｍ０と更新前管理木から、ＣＳ法によりノードＩＤのリストＬ＿ｔｃｓ０を導出する（ステップＳ１３０４）。

次に選択部１１３−２は、更新後管理木の葉ノードのうち、有効フラグが１の葉ノードが割り当てられた通信装置２００を特定し、特定した通信装置２００のうちリストＬ＿ｍに含まれる通信装置２００をリストＬ＿ｍ１に記録する（ステップＳ１３０５）。選択部１１３−２は、リストＬ＿ｍ１と更新後管理木から、ＣＳ法によりノードＩＤのリストＬ＿ｔｃｓ１を導出する（ステップＳ１３０６）。

選択部１１３−２は、リストＬ＿ｔｃｓ０とリストＬ＿ｔｃｓ１をマージしてリストＬ＿ｃｓを生成する（ステップＳ１３０７）。選択部１１３−２は、更新前管理木を管理木記憶部１２４−２から削除し、更新後管理木を新たな管理木とする。選択部１１３−２は、更新前管理木を削除せず、バックアップデータとして保存してもよい。

このようにして選択されたノード鍵を用いてグループ鍵が暗号化され（図１０のステップＳ４０４）、更新対象の通信装置２００に送信される（図１０のステップＳ４０５）。また、第２の実施形態では、更新後管理木の根ノードから葉ノードまでに割り当てられたノード鍵の集合が更新後デバイス鍵として通信装置２００に送信される（図６のステップＳ１３）。

（変形例５）
第２の実施形態では、管理木更新事前処理（図２０）において更新後管理木のすべてのノード鍵を作成し、管理木更新処理（図２１）においてデバイス鍵の再割り当てを行っていた。本変形例では、管理木更新事前処理では完全な更新後管理木を作成せず、管理木更新処理で更新対象のデバイス鍵が必要とするノード鍵を逐次生成することにより、更新後管理木を生成する。このように構成することで、更新中に保持すべき情報量を削減可能となる。

図２３は、変形例５の管理木更新事前処理の一例を示すフローチャートである。管理木更新部１１２−２は、最新の管理木を更新前管理木として管理木記憶部１２４−２に記憶する（ステップＳ１４０１）。管理木更新部１１２−２は、更新前管理木と同じ数の葉ノードを持ち、各ノードにノードＩＤを割り振った二分木を、更新後管理木として生成する（ステップＳ１４０２）。管理木更新部１１２−２は、更新後管理木の各ノードが保持する有効フラグを０に設定してすべてのノードを無効化する（ステップＳ１４０３）。管理木更新部１１２−２は、更新後管理木を例えば管理木記憶部１２４−２に記憶して管理木更新事前処理を終了する。

図２４は、変形例５の管理木更新処理の一例を示すフローチャートである。ステップＳ１５０１からステップＳ１５０４までは、第２の実施形態の管理木更新処理（図２１）のステップＳ１２０１からステップＳ１２０４までと同様の処理なので、その説明を省略する。

管理木更新部１１２−２は、更新後管理木の根ノードからｌｅａｆまでの経路上のノードに割り当てられたノードＩＤを特定する。管理木更新部１１２−２は、特定したノードＩＤに対応するノード鍵が記録されているノードに対しては、そのノードＩＤとノード鍵との組をリストＬ＿ｎｄｋに記録する。管理木更新部１１２−２は、ノードＩＤに対応するノード鍵が空のノードに対しては、そのノードＩＤと新たに生成したノード鍵との組をリストＬ＿ｎｄｋに記録する（ステップＳ１５０５）。ノード鍵を生成する方法は、ランダムに鍵を生成する方法などの任意の方法を適用できる。

ステップＳ１５０６およびステップＳ１５０７は、第２の実施形態の管理木更新処理（図２１）のステップＳ１２０６およびステップＳ１２０７と同様の処理なので、その説明を省略する。

管理木更新部１１２−２は、更新後管理木の空のノード鍵を持つノードであって、リストＬ＿ｎｄｋにノードＩＤが記録されているノードに対して、空のノード鍵をリストＬ＿ｎｄｋに記録されたノード鍵に置き換えて更新後管理木を更新する（ステップＳ１５０８）。管理木更新部１１２−２は、更新前管理木のノードであって、リストＬ＿ｄｋに記録されているノードＩＤで特定されるノードのノード鍵を空のノード鍵に置き換えて削除する（ステップＳ１５０９）。

（変形例６）
第１の実施形態の変形例３と同様に、管理装置１００−２は、デバイス鍵の更新やグループ鍵の更新が必要になったときにのみ、通信装置２００が接続しているネットワークに接続するように構成してもよい。

また、デバイス鍵の更新時にはすべての通信装置２００と同時に接続されている必要はない。接続が必要となったときに、更新の対象となる通信装置２００と管理装置１００−２とを、例えばＵＳＢまたはシリアル通信を用いて直接接続するように構成してもよい。このとき、管理装置１００−２は、第２の実施形態の機能をすべて同一の機器内で実現する必要はなく、グループ鍵更新機能を備えた機器と、デバイス鍵更新機能を備えた機器に分けて実現してもよい。この場合の構成例は変形例３の図１７と同様である。

（変形例７）
第２の実施形態では、デバイス鍵更新処理が行われている間、更新前管理木と更新後管理木を用いるが、これらを管理木の世代情報によって管理してもよい。この場合、更新後管理木の生成時に、既存の管理木よりもより新しい世代情報を付すことで、更新前管理木と更新後管理木を区別する。

このように、第２の実施形態では、更新前後の管理木を分けて管理し、各管理木から、グループ鍵の暗号化に使用できるノード鍵（デバイス鍵）を判定する。これにより、すべての通信装置のデバイス鍵の更新が完了する前であってもグループ鍵を配布することが可能となる。また、第２の実施形態では、グループの構成などを参照して、同一のグループに属する頻度の高い通信装置同士ができるだけ近い祖先ノードを持つように更新後の管理木を決定する。これにより、グループ鍵の配布に要する通信コストを削減することが可能となる。

以上説明したとおり、第１から第２の実施形態によれば、すべての通信装置のデバイス鍵の更新が完了する前であってもグループ鍵を配布することが可能となる。

次に、上記各実施形態にかかる装置（管理装置、通信装置）のハードウェア構成について図２５を用いて説明する。図２５は、実施形態にかかる装置のハードウェア構成例を示す説明図である。

実施形態にかかる装置は、ＣＰＵ５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、各部を接続するバス６１を備えている。

実施形態にかかる装置で実行されるプログラムは、ＲＯＭ５２等に予め組み込まれて提供される。

実施形態にかかる装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。

さらに、実施形態にかかる装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、実施形態にかかる装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

実施形態にかかる装置で実行されるプログラムは、コンピュータを上記した装置の各部として機能させうる。このコンピュータは、ＣＰＵ５１がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１００ 管理装置
１０１ 受信部
１０２ 送信部
１１１ 鍵交換部
１１２ 管理木更新部
１１３ 選択部
１１４ グループ更新部
１２１ グループ情報記憶部
１２２ 機器情報記憶部
１２３ 証明書記憶部
１２４ 管理木記憶部
２００ 通信装置
２０１ 受信部
２０２ 送信部
２１１ 鍵交換部
２１２ デバイス鍵更新部
２１３ グループ更新部
２２１ グループ情報記憶部
２２２ デバイス鍵記憶部
２２３ 証明書記憶部
３００ デバイス鍵更新装置
４００ グループ鍵更新装置

Claims (12)

1. ノード鍵が割り当てられた複数のノードを含む二分木を記憶する管理木記憶部と、
   前記ノード鍵を更新する管理木更新部と、
   前記二分木の部分木から、割り当てられた前記ノード鍵がすべて更新前である葉ノードのみを含む第１の部分木、および、割り当てられた前記ノード鍵がすべて更新後である葉ノードのみを含む第２の部分木のうち少なくとも一方であって、グループに含まれる通信装置に対応する前記二分木の葉ノードのみを含む部分木を選択し、選択した部分木の根ノードのうち他の部分木の子ノードとならない根ノードを選択する選択部と、
   選択された前記根ノードのノード鍵で暗号化したグループ鍵を送信する送信部と、
   を備える管理装置。
2. 前記二分木は、割り当てられた前記ノード鍵が暗号化に使用できるか否かを判定するための判定情報がさらに割り当てられた複数の第１のノードを含み、
   前記選択部は、前記判定情報に基づいて、前記ノード鍵が暗号化に使用できると判定されたノードを含む前記第１の部分木および前記第２の部分木の少なくとも一方を選択する、
   請求項１に記載の管理装置。
3. 前記判定情報は、前記第１のノードが葉ノードであるか、または、前記第１のノードおよび前記第１のノードの２つの子ノードに割り当てられた前記ノード鍵が共に更新済みであるか、または、前記第１のノードおよび前記第１のノードの２つの子ノードに割り当てられた前記ノード鍵が共に更新前である場合に、前記第１のノードに割り当てられた前記ノード鍵が暗号化に使用できることを示し、
   前記選択部は、前記ノード鍵が暗号化に使用できることを示す前記判定情報が割り当てられたノードを含む前記第１の部分木および前記第２の部分木の少なくとも一方を選択する、
   請求項２に記載の管理装置。
4. 前記判定情報は、葉ノードである前記第１のノードに割り当てられた前記ノード鍵が更新済みであるか否かを示し、
   前記選択部は、前記ノード鍵が更新済みでないことを示す前記判定情報が割り当てられた葉ノードのみを含む第１の部分木、および、前記ノード鍵が更新済みであることを示す前記判定情報が割り当てられた葉ノードのみを含む第２の部分木のうち少なくとも一方を選択する、
   請求項２に記載の管理装置。
5. 前記選択部は、ＣＳ（Complete Subtree）法に基づいてグループに含まれる通信装置に対応する前記二分木の葉ノードを含む部分木を選択し、選択した部分木から前記第１の部分木、および、前記第２の部分木のうち少なくとも一方を選択する、
   請求項１に記載の管理装置。
6. 前記送信部は、さらに、更新された前記ノード鍵を、更新された前記ノード鍵が割り当てられた葉ノードに対応する通信装置に送信する、
   請求項１に記載の管理装置。
7. 前記管理木記憶部は、更新前のノード鍵が割り当てられた複数のノードを含む第１の二分木と、更新後のノード鍵が割り当てられた複数のノードを含む第２の二分木と、を記憶し、
   前記選択部は、前記第１の二分木の部分木である前記第１の部分木、および、前記第２の二分木の部分木である前記第２の部分木のうち少なくとも一方を選択する、
   請求項１に記載の管理装置。
8. 前記管理木更新部は、同じグループに属する複数の通信装置に対応する複数の葉ノードの祖先ノードが、前記第１の二分木よりも葉ノードに近くなるように前記第２の二分木を生成して前記管理木記憶部に記憶させる、
   請求項７に記載の管理装置。
9. 前記送信部は、さらに、更新後の前記ノード鍵を、更新後の前記ノード鍵が割り当てられた葉ノードに対応する通信装置に送信する、
   請求項８に記載の管理装置。
10. 前記送信部は、前記第２の二分木の根ノードから第１の葉ノードまでに割り当てられたノード鍵の集合を、前記第１の葉ノードに対応する通信装置に送信する、
    請求項９に記載の管理装置。
11. 前記選択部は、ＣＳ（Complete Subtree）法に基づいてグループに含まれる通信装置に対応する前記第１の二分木の葉ノードを含む部分木を選択し、選択した部分木から前記第１の部分木を選択し、ＣＳ法に基づいてグループに含まれる通信装置に対応する前記第２の二分木の葉ノードを含む部分木を選択し、選択した部分木から前記第２の部分木を選択する、
    請求項７に記載の管理装置。
12. ノード鍵が割り当てられた複数のノードを含む二分木の前記ノード鍵を更新する管理木更新ステップと、
    前記二分木の部分木から、割り当てられた前記ノード鍵がすべて更新前である葉ノードのみを含む第１の部分木、および、割り当てられた前記ノード鍵がすべて更新後である葉ノードのみを含む第２の部分木のうち少なくとも一方であって、グループに含まれる通信装置に対応する前記二分木の葉ノードのみを含む部分木を選択し、選択した部分木の根ノードのうち他の部分木の子ノードとならない根ノードを選択する選択ステップと、
    選択された前記根ノードのノード鍵で暗号化したグループ鍵を送信する送信ステップと、
    を含む管理方法。

Images