JP2009038416A - マルチキャスト通信システム、並びにグループ鍵管理サーバ - Google Patents

Abstract

【課題】グループからメンバを削除する際にメンバの親ノードの鍵を更新せずにグループ鍵のみを更新して鍵の計算量を削減し、メンバを追加する際にメンバの削除時に更新しなかった親ノードの鍵を更新することによりマルチキャスト通信の通信量を削減する。
【解決手段】グループ鍵管理サーバは、二分木構造の各ノードについて、メッセージ鍵と親鍵種とを記憶する鍵情報記憶部と、メンバ追加時に、二分木構造の根ノードのメッセージ鍵であるグループ鍵を生成する鍵管理部とを有し、端末装置のそれぞれは、自己のメッセージ鍵と、自己の兄弟ノードの親鍵種と、二分木構造の経路上ノードのメッセージ鍵と親鍵種と、経路上ノードの兄弟ノードの親鍵種とを記憶する端末側鍵情報記憶部と、端末側鍵情報記憶部に記憶された親鍵種から、二分木構造の根ノードのメッセージ鍵であるグループ鍵を生成する端末側鍵管理部とを有する。
【選択図】図１

Description

本発明は、マルチキャスト通信システム、並びにグループ鍵管理サーバに関し、より詳しくは、マルチキャスト通信の秘匿化の際にグループ鍵の配信を行うマルチキャスト通信システム、並びにグループ鍵管理サーバに関する。

近年、インターネット回線が高速化し、動画配信など大容量のデータを送れるようになってきた。このため、動画配信などの特定多数のユーザへの配信手法の一つとして、ネットワーク内で複数の相手を指定して同じデータを送信する技術であるマルチキャスト通信が注目されている。

一方、通信の秘匿化を行う手法として鍵を用いる方法がある。すなわち、平文と鍵という暗号アルゴリズムの種を用いることにより暗号文を生成し、送信することにより、送信側、受信側で対応した鍵を持たない限りは平文を復号できないという性質を利用して、通信を秘匿化する。この鍵暗号方式には送信側と受信側で同じ鍵を使って暗号化／復号する共通鍵暗号方式、送信側と受信側で異なる鍵を使って暗号化／復号する公開鍵暗号方式の２種類ある。一般的に、公開鍵暗号方式より共通鍵暗号方式のほうが暗号化／復号にかかる計算量が小さいため、マルチキャスト通信の秘匿化においては、グループ鍵と呼ばれる共通鍵を用いて暗号化／復号が行われる。

ところで、マルチキャストの一般的なセキュリティ要件として次の２点が挙げられる。
(1) グループに追加されたメンバは追加される以前の情報を復号できない
(2) グループから削除されたメンバは削除された以後の情報を復号できない
これらの要件を満たすために、現在使用しているグループ鍵を、メンバ追加或いはメンバ削除時に追加されるメンバ、削除されるメンバには取得することができないグループ鍵に変更することが行われ、これによりセキュリティ要件を満たす。

上記グループ鍵の変更方法として、以下の方法が提案されている。
[従来技術１] ユニキャストによるグループ鍵の送信
最も単純なグループ鍵の送信手法は各メンバにユニキャストによってグループ鍵を送信する手法である。

[従来技術２] ＣＳ法(Complete Subset Method)
ＣＳ法は木構造によってグループ鍵を管理する手法である。木構造の各ノードに鍵を割り当てる。メンバは木構造の各葉に割り当てられ、葉に割り当てられたメンバは葉から根に向かう経路のノードの鍵すべてを持つ。つまり、完全二分木にＮ人のメンバが割り当たっていれば、各メンバは［ｌｏｇＮ］個の鍵を持つ。すべてのメンバは木構造の根の鍵を共通に持つことになるので、この根の鍵をグループ鍵として利用する。

このＣＳ法ではメンバ削除時に、削除されるメンバが持っている鍵を、グループ鍵を含めて使用不可にする。グループ鍵が使用できなくなると通信の秘匿化が行なくなるので、サーバは新しいグループ鍵を更新し、更新したグループ鍵をマルチキャストする。その際、削除されるメンバに更新したグループ鍵を得ることができなくするため、更新したグループ鍵を暗号化する。その暗号化では、削除されるメンバが持っていない鍵で、且つ、木構造の根に近い鍵を使って暗号化することにより、削除されるメンバは更新したグループ鍵を得ることができず、通信量を小さくすることができる。

[従来技術３] ＯＦＴ(One-way Function Method)
ＯＦＴは木構造によってグループ鍵を管理する手法である。木構造の各ノードに鍵を割り当てる。メンバは木構造の各葉に割り当てられ、葉に割り当てられたメンバは葉から根に向かう経路のノードの兄弟の鍵すべてを持つ。すべてのメンバは木構造の根の鍵を共通に計算可能になるので、この根の鍵をグループ鍵として利用する（例えば、特許文献１）。

各メンバは葉から根に向かう経路のノードの鍵をその子ノードの鍵から計算する。葉から根に向かってボトムアップに鍵を逐次的に計算することにより、各メンバの鍵(葉の鍵)をどれか一つを変えることのみによりグループ鍵の更新を行うことができ、鍵更新のための通信量が小さくなる。
米国特許公開公報US 7,095,850 B1

従来技術１では、しかし、この手法ではグループ鍵の更新時に、メンバ数をＮとしたとき、Ｎ回のユニキャストが必要になり、通信量が多くなってしまう点において問題がある。

従来技術２では、メンバ追加について考慮されておらず、その点から動的なマルチキャストグループでの通信に応用することができない。また、メンバが削除されると、削除されたメンバの鍵が使えなくなることにより、使えなくなる鍵が削除されたメンバ数に比例して多くなるため、最終的に従来技術１のようなユニキャストによりグループ鍵を送信する手法と同じ程度の通信量が必要になるという問題点がある。

従来技術３ではＯＦＴでは葉ノードから根ノードに向かって逐次的に鍵を計算していくため、鍵更新の際にメンバ数をＮとしたときにO(ｌｏｇＮ)の計算量が必要になり、グループ鍵更新の際に、メンバ追加／削除が発生したメンバの葉から根までの経路の鍵すべてを更新するため、信頼性の低いマルチキャスト通信で鍵の更新情報が正確に送信できなかった際に、そのメンバはそれ以後の鍵更新を行うことができなくなるという問題点がある。

上記課題を解決するための手段として、本発明は以下の特徴を有する。
本発明の第１の態様は、ネットワークに接続され、二分木構造の根ノードに相当するグループ鍵管理サーバと、ネットワークに接続され、二分木構造の葉ノードに相当する複数の端末装置とを有するマルチキャスト通信システムとして提案される。

このマルチキャスト通信システムにおいて、グループ鍵管理サーバは、二分木構造の各ノードについて、メッセージ鍵と親鍵種とを記憶する鍵情報記憶部と、メンバ追加時に、二分木構造の根ノードのメッセージ鍵であるグループ鍵を生成する鍵管理部とを有する。
また、このマルチキャスト通信システムにおいて、端末装置のそれぞれは、自己のメッセージ鍵と、自己の兄弟ノードの親鍵種と、二分木構造の経路上ノードのメッセージ鍵と親鍵種と、経路上ノードの兄弟ノードの親鍵種とを記憶する端末側鍵情報記憶部と、端末側鍵情報記憶部に記憶された親鍵種から、二分木構造の根ノードのメッセージ鍵であるグループ鍵を生成する端末側鍵管理部とを有することを特徴としている。

本発明の第２の態様は、二分木構造の葉ノードに相当する複数の端末装置が接続されたネットワークに接続され、二分木構造の根ノードに相当するグループ鍵管理サーバとして提案される。

このグループ鍵管理サーバは、根ノードと葉ノードを有する二分木構造を示す木構造情報と、木構造に含まれる各ノードについて、暗号化に使用できないメッセージ鍵である使用不可鍵の数を示す使用不可鍵数とを記憶する鍵情報記憶部と、メンバ追加時には、鍵情報記憶部に記憶された使用不可鍵数を用いて、二分木構造におけるメンバの追加位置を決定する鍵管理部とを有することを特徴としている。

本発明によれば、グループからメンバを削除する際に、メンバの親ノードの鍵を更新せずにグループ鍵のみを更新することにより、鍵の計算量を削減し、メンバを追加する際にメンバの削除時に更新しなかった親ノードの鍵を更新することによりマルチキャスト通信の通信量を削減することができる。

以下、図面を参照しながら本発明の実施の形態を説明する。
本実施の形態では次の２つのアクター、グループ鍵管理サーバ及びメンバが定義される。
（１）グループ鍵管理サーバ
グループ鍵管理サーバは、グループ鍵を管理する役割を有する装置である。グループ鍵管理サーバは、グループ鍵の生成／更新、グループ鍵の配信、メンバ情報の管理などの責務を持つ。

（２）メンバ
メンバは、グループ鍵を利用する役割を有する。メンバは、グループ鍵の更新、グループ鍵を用いた暗号化通信を行うなどの責務を持つ。なお、メンバがグループ鍵を利用してマルチキャスト通信を含む通信を行うための装置を端末装置と呼ぶものとする。

図１は、本実施の形態にかかるマルチキャスト通信システムの構成例を示すブロック図である。
マルチキャスト通信システム１は、グループ鍵管理サーバ１０と、ネットワーク２０を介してグループ鍵管理サーバ１０及び他の端末装置と通信可能な端末装置３０とを有している。図１に示した例では、８人のメンバＡ〜Ｈのそれぞれに対応する８台の端末装置３０によって、一つのグループを構成しているものとする。なお、端末装置３０は、一人のメンバに専有される装置であってもよいし、複数のメンバに共有される装置であっても構わない。

［１．グループ鍵管理サーバ］
グループ鍵管理サーバ１０は、演算処理装置（ＣＰＵ）、主メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、入出力装置（Ｉ／Ｏ）、必要な場合にはハードディスク装置等の外部記憶装置を具備している装置であって、例えばコンピュータ、ワークステーションなどの装置である。前記ＲＯＭ、若しくはハードディスク装置などにプログラムが記憶されており、このプログラムを主メモリ上に載せ、ＣＰＵがこれを実行することによりグループ鍵管理サーバ１０が実現される。また、上記プログラムは必ずしも情報処理装置内の記憶装置に記憶されていなくともよく、外部の装置（例えば、ＡＳＰ（アプリケーション・サービス・プロバイダのサーバなど））から提供され、これを主メモリに乗せる構成であってもよい。さらに、このグループ鍵管理サーバ１０は単体の装置で構成されていてもよいし、複数の装置をネットワークにより結合して構成されるものでもよい。

図２は、グループ鍵管理サーバ１０の構成例を示す機能ブロック図である。グループ鍵管理サーバ１０は、通信制御部１１と、通信制御部１１に接続された管理部１２と、管理部１２に接続された鍵管理部１３及び暗号処理部１４と、鍵管理部１３及び暗号処理部１４に接続された鍵情報記憶部１５とを有している。

通信制御部１１は、ネットワーク２０と接続され、端末装置３０とデータを送受信するために、所定のプロトコルに従ってパケットを生成してこれをマルチキャスト或いはユニキャストにより送信し、端末装置３０から送信されたパケットを受信する。通信制御部１１は、前記暗号化処理部によって暗号化されたグループ鍵を各端末装置にマルチキャストにより送信する。通信制御部１１は、例えば、ネットワークボード、ネットワークカードなどである。

管理部１２は、鍵管理部１３、暗号処理部１４、通信制御部１５と接続され、各部の動作制御、データの受け渡しの管理を行う。
鍵管理部１３は、鍵情報記憶部１５の記憶内容を利用し、グループ鍵、後述するメッセージ鍵（秘密鍵ともいう）、親鍵種（迷彩鍵ともいう）の計算やメンバ追加／削除の際にどのようにメンバの追加／削除を行うかを決定する機能を有する。
暗号処理部１４は、鍵情報記憶部１５の記憶内容を利用し、端末装置３０に必要な送信すべき鍵情報などを暗号化し、これを通信制御部１５を介して端末装置３０に送信させる機能を有する。

鍵情報記憶部１５は、以下の情報を記憶する。
（１）鍵の木構造
（２）各ノードの情報
（３）各ノードの親鍵種
（４）各ノードのメッセージ鍵
（５）使用不可鍵リスト
鍵の木構造は鍵の木構造をリストや表などなんらかの表現手法で保存する。各ノードには親鍵種とメッセージ鍵といった従来技術での必要な情報に加えて、使用不可鍵数を登録する。これは、そのノードより下位のノードに含まれる使用不可鍵の総和である。すなわち、使用不可でないノードの鍵の使用不可鍵数は次式で求める。
(使用不可でないノードの使用不可鍵数)=
(右子ノードの使用不可鍵数)+(左子ノードの使用不可鍵数)
使用不可のノードの使用不可鍵数は(使用不可でないノードの使用不可鍵数)+1により求めることとする。

鍵情報記憶部１５は、鍵の木構造に加えて使用不可鍵リストを保存する。これは、通信を暗号化する際に使用不可鍵リストに登録されているかを確認し、使用不可でない鍵により暗号化することにより、メンバから削除されたなどの理由により情報の閲覧を許可されないメンバによる暗号化情報の復号を避けるためである。

次に、端末装置３０について説明する。端末装置３０は、グループに属するメンバがグループ鍵を用いて情報を暗号化／復号することによって、情報を秘匿しながら他のメンバと通信することを可能とする情報処理装置である。端末装置３０は、グループ鍵管理サーバ１０から送られてきた鍵情報の復号や、復号して得られた情報から各種鍵の計算を行い、暗号化通信を行う責務がある。

端末装置３０は、演算処理装置（ＣＰＵ）、主メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、入出力装置（Ｉ／Ｏ）、必要な場合にはハードディスク装置等の外部記憶装置を具備している装置であって、例えばネットワーク通信機能を有するコンピュータ、ＰＤＡ（Personal Data Assistant）、携帯電話機、携帯ゲーム機などの装置である。端末装置３０の前記ＲＯＭ、若しくはハードディスク装置などにプログラムが記憶されており、このプログラムを主メモリ上に載せ、ＣＰＵがこれを実行することにより端末装置３０が実現される。また、上記プログラムは必ずしも情報処理装置内の記憶装置に記憶されていなくともよく、外部の装置（例えば、ＡＳＰ（アプリケーション・サービス・プロバイダのサーバなど））から提供され、これを主メモリに乗せる構成であってもよい。

図３に、端末装置３０の構成例を示す機能ブロック図を掲げる。端末装置３０は、端末側通信制御部３１と、端末側通信制御部３１に接続された端末側管理部３２と、端末側管理部３２に接続された端末側鍵管理部３３及び端末側暗号処理部３４と、端末側鍵管理部３３及び暗号処理部３４に接続された端末側鍵情報記憶部３５とを有している。

端末側通信制御部１１は、ネットワーク２０と接続され、グループ鍵管理サーバ１０及び他の端末装置３０とデータを送受信するために、所定のプロトコルに従ってパケットを生成してこれをマルチキャスト或いはユニキャストにより送信し、またグループ鍵管理サーバ１０及び他の端末装置３０から送信されたパケットを受信して元のデータを再構築して取得する。端末側通信制御部３１は、例えば、ネットワークボード、ネットワークカードなどである。

端末側管理部３２は、端末側鍵管理部３３、端末側暗号処理部３４、端末側通信制御部３５と接続され、各部の動作制御、データの受け渡しの管理を行う。端末側管理部３２は主にＣＰＵ、ＲＯＭ、ＲＡＭによって実現される構成要素である。

端末側鍵管理部３３は、端末側鍵情報記憶部３５の記憶内容を利用し、グループ鍵、後述するメッセージ鍵（秘密鍵ともいう）、親鍵種（迷彩鍵ともいう）の計算やメンバ追加／削除による端末側鍵情報記憶部３５内の木構造情報の更新を行う機能を有する。端末側鍵管理部３３は主にＣＰＵ、ＲＯＭ、ＲＡＭによって実現される構成要素である。

端末側暗号処理部３４は、端末側鍵情報記憶部３５の記憶内容を利用し、グループ鍵管理サーバ１０から送信された鍵情報を復号する機能を有する。端末側暗号処理部３４は主にＣＰＵ、ＲＯＭ、ＲＡＭによって実現される構成要素である。

端末側鍵情報記憶部３５は、以下の情報を記憶する。
（１）鍵の木構造
（２）その端末装置に相当する葉ノードから根ノードに向かう経路上に存する中間ノード（経路上ノードと呼ぶ）の情報
（３）各経路上ノードの兄弟ノード（同一の中間ノード又は根ノードを親に持つ中間ノード）の親鍵種
（４）各経路上ノードの親鍵種
（５）グループ鍵管理サーバとの暗号化通信に使用する共通鍵
（６）使用不可鍵リスト
上記の鍵の木構造は鍵の木構造をリストや表などなんらかの表現手法で保存する。端末装置３０が保持する鍵は、グループ鍵管理サーバ１０との共通鍵と、経路上ノードの親鍵種と、経路上ノードの兄弟ノードそれぞれの親鍵種である。端末側鍵管理部３３は、これらの鍵情報から親ノードのメッセージ鍵、親鍵種を復元（生成）する。
なお、使用不可鍵リストは、グループ鍵管理サーバ１０から送られてきた鍵を復号する際にどの鍵を使って復号するかを決めるものである。
以上で、本実施の形態にかかるマルチキャスト通信システム１の構成の説明を終了する。

［２．マルチキャスト通信システムの動作］
本実施の形態にかかるマルチキャスト通信システム１は、主要な機能若しくは動作として、グループ鍵管理、メンバ追加、メンバ削除の３つの機能を有する。
［２．１．グループ鍵管理］
まず、マルチキャスト通信システム１が実行するグループ鍵管理について述べる。

グループ鍵管理は木構造を示す木構造情報を用いて行う。グループ鍵管理サーバ１０は、メンバ追加、メンバ削除などのメンバ変更に伴う木構造の変更或いは更新が起こった場合は、更新された木構造を示す木構造情報を各端末装置３０に送信する。更新された木構造情報は、グループ鍵管理サーバ１０の鍵情報記憶部１５及び各端末装置３０の端末側鍵情報記憶部３５において保持される。

グループ鍵管理サーバ１０の鍵情報記憶部１５及び各端末装置３０の端末側鍵情報記憶部３５において保持される二分木による木構造の例を図４に示す。マルチキャスト通信システム１を構成するグループ鍵管理サーバ１０及び端末装置３０のすべてが、同じ木構造情報を共有する。

さて、グループ鍵管理に使用する木構造４０は、根ノード４１と、各メンバに対応する各葉ノード４２および根ノード４１と葉ノード４２の間に置かれる中間ノード４３によって構成される。この木構造４０は二分木であり、各ノード４１、４３はその下位のノードとして２つの子ノードを有する。ただし、葉ノード４２は子ノードを有しない。

なお、図４中、根ノード４１及び中間ノード４３は円形の枠で図示し、葉ノードは四角形の枠で示している。また、各枠内の数字はノードを区別するためのノード番号である。以下、各ノードを区別する場合には、ノード番号を用いて表記するものとし、例えば根ノード４１をノード［１］と表記し、例えば左端の葉ノード４２をノード［８］のように表記することがある。

図４に示した例では、８個の葉ノード４２、すなわち葉ノード［８］〜［１５］があり、これは８つのメンバ、すなわち８台の端末装置３０を意味している。また、根ノード４１はグループ鍵管理サーバ１０に相当する。

木構造４０のすべてのノード４１、４２、４３のそれぞれには親鍵種とメッセージ鍵の２つの情報が付与される。親鍵種はメッセージ鍵に一方向関数を使うことにより求めることができる。メッセージ鍵はそのノードの２つの子ノードの親鍵種を排他的論理和などの混合関数を使うことにより求めることができる。ただし、葉ノード４２のメッセージ鍵はグループ鍵管理サーバ１０によって生成される。

木構造４０の葉ノード４２に相当する端末装置３０は、葉ノード４２から根ノード４１に向かう経路上の中間ノード４３（経路上ノードと呼ぶ）それぞれの親鍵種と、その葉ノード４２および経路上ノードの兄弟ノード（同一の親ノードを有する中間ノード４３）の親鍵種と、グループ鍵管理サーバ１０と共有するその端末装置３０自身のメッセージ鍵を端末鍵情報記憶部３５に保持する。一例を挙げると、ノード［９］に対応する端末装置３０は、経路上ノードであるノード［４］の親鍵種及びノード［２］の親鍵種と、兄弟ノードであるノード［８］の親種鍵、ノード［５］の親種鍵、ノード［３］の親種鍵、及び自身のメッセージ鍵であるノード［９］のメッセージ鍵とをその端末側鍵情報３５に保持することとなる。

各端末装置３０は、グループへのメンバ追加の際に、グループ鍵管理サーバ１０の鍵管理部３３により与えられた親種鍵とメッセージ鍵から論理的ノードの鍵を計算する。図４の例において、ノード［９］に相当する端末装置３０が新たにグループに追加されたものとする。ノード［９］に相当する端末装置３０は、まず、ノード［９］のメッセージ鍵に一方向関数を使い、ノード［９］の親鍵種を求める。次に、この端末装置３０は、ノード［８］の親鍵種とノード［９］の親鍵種から経路上ノードであるノード［４］のメッセージ鍵を求める。そして、この端末装置３０は、ノード［４］のメッセージ鍵に一方向関数を使い、ノード［４］の親鍵種を求める。次に、この端末装置３０は、ノード［４］の親鍵種とノード［５］の親鍵種から所定の混合関数を用いて経路上ノード［２］のメッセージ鍵を求める。最後に、ノード［２］のメッセージ鍵に一方向関数を使い、ノード［２］の親鍵種を求めた後、ノード［２］の親鍵種とノード［３］の親鍵種から所定の混合関数を用いてノード［１］のメッセージ鍵、すなわちグループ鍵を求める。このように、すべての端末装置３０は、木構造４０の葉ノード４２から根ノード４１に向かって逐次的に親鍵種、メッセージ鍵を求めることができ、最終的にグループ鍵を求めることができる。

すべての端末装置３０は根ノード４１であるノード［１］のメッセージ鍵を求めることが可能なので、このノード［１］のメッセージ鍵を、グループ内の暗号化鍵であるグループ鍵として用いる。

［２．２．メンバ追加］
次に、グループに新たなメンバを追加する場合のマルチキャスト通信システム１の動作について説明する。
グループに追加されたメンバが追加される以前の情報を復元できなくするため、マルチキャスト通信システム１は、メンバ追加時にグループ鍵を更新する。このシーケンスを図５に示す。

グループ鍵管理サーバ１０は、オペレータの操作などにより、グループに新たなメンバを追加する（Ｓ１０１）。メンバの追加は、鍵情報記憶部１５に記憶されている木構造４０への新たな葉ノード４２の追加として行われる。

メンバの追加は、新たな葉ノード４２を木構造のどの位置に追加するかを決定することにより行われる。新たな葉ノード４２の追加は、まず、図６のフローチャートに示した手順を鍵管理部１３が実行してメンバの追加位置を求めることにより行われる。すなわち、グループ鍵管理サーバ１０、より詳しくは鍵管理部１３は、最上位のノード、すなわち根ノード４１から順に以下の判定を行う。

まず、鍵管理部１３は、対象となるノードについてその左子ノードの有する使用不可鍵数とその右子ノードの有する使用不可鍵数とを比較する（Ｓ６０１）。左子ノードの有する使用不可鍵数がより多い場合（Ｓ６０１、Ｙｅｓ）、鍵管理部１３は左子ノードを選択し（Ｓ６０２）、それ以外の場合（Ｓ６０１、Ｎｏ）は右子ノードを選択する（Ｓ６０３）。

次に、鍵管理部１３は、選択した左子ノード或いは右子ノードが葉ノード４２であるか否かを判定し（Ｓ６０４）、葉ノード４２である場合（Ｓ６０４、Ｙｅｓ）は、その葉ノードを中間ノード４３に置き換えるとともに、その中間ノード４３の子ノードとして選択された既存の葉ノード４２と追加する新たな葉ノード４２とを追加し（Ｓ６０５）、メンバ追加位置決定処理を終了する。

一方、選択した左子ノード或いは右子ノードが葉ノード４２でない場合（Ｓ６０４、Ｎｏ）は、グループ鍵管理サーバ１０、より詳しくは鍵管理部１３は、Ｓ６０２又はＳ６０３で選択した左子ノード或いは右子ノードを次の判定対象とする（Ｓ６０６）。
グループ鍵管理サーバ１０、より詳しくは鍵管理部１３は、次の判定対象としたそれらの子ノードの使用不可鍵数を比較し（Ｓ６０１）、以下選択した左子ノード或いは右子ノードが葉ノード４２となるまで同様の処理（Ｓ６０２〜６０５）を繰り返す。

すなわち、上記のメンバ追加位置決定処理によって、メンバ追加位置は使用不可鍵数の多いノードになる。このようにすることで、メンバ追加時には使用不可の鍵を更新するため、使用不可鍵の再利用効率を高めることができる。また、図６のアルゴリズムは根ノード４１から葉ノード４２へと実行されるためメンバ数をＮとしたとき、Ｏ（ｌｏｇＮ）の計算量でメンバ追加位置を求めることができる。

葉ノード４２にメンバを追加する際、その追加位置の葉ノード４２のメンバと新しいメンバの２つを葉とする部分木を追加位置に挿入する。例えば、図４の例で新たなノード［１６］を追加する場合、ノード［９］をメンバ追加位置と決定した場合は、ノード［９］とノード［１６］の共通の親のノード［１７］を生成し、ノード［１７］をノード［９］の位置に挿入することにより追加が行われる。図７に、図４の木構造４０に、ノード［９］をメンバ追加位置と決定してノード［１６］を追加した新たな木構造４０’の例を示す。

次に、グループ鍵管理サーバ１０は、追加メンバに相当する端末装置３０との間で、新しいメッセージ鍵の確立を行う（Ｓ１０２）。グループ鍵管理サーバ１０が追加メンバである端末装置との間で、公開鍵確立手法(DH)などの手段を用いて、共有鍵を確立する。また、追加位置の葉ノードに対応するメンバとの間にも同様に共通鍵を確立する（図略）。例えば、図４の例でノード［９］を追加位置とした場合にノード［１６］を追加する場合はノード［９］とノード［１６］に新しいメッセージ鍵を確立する。

次に、グループ鍵管理サーバ１０は、追加メンバと追加位置の葉ノード４２に相当するメンバから根ノード４１に向かう経路上ノードそれぞれのメッセージ鍵、親鍵種を鍵管理部１３で逐次的に計算する処理である追加メンバの親ノードのメッセージ鍵、親鍵種を再計算を行う（Ｓ１０３）。例えば、図４のノード［９］にノード［１６］を追加する例では、グループ鍵管理サーバ１０は、ノード［１７］のメッセージ鍵、親鍵種を計算し、ノード［４］のメッセージ鍵、親鍵種、及びノード［２］のメッセージ鍵、親鍵種、ノード［１］のメッセージ鍵と逐次的に計算し、計算したこれらメッセージ鍵、親鍵種を鍵情報記憶部１５に記憶させる。

なお、逐次的に計算していく際に、計算で求めた新たな鍵は鍵情報記憶部１５の使用不可鍵リストから取り除き、また、そのノードについての使用不可鍵数から１引く。これにより、使用不可鍵の再利用ができるようになる。

次に、グループ鍵管理サーバ１０は、すべてのメンバが共通のグループ鍵を再計算できるようにするために、先のステップＳ１０３で更新した論理的ノードの親種鍵を、その親鍵種を必要とするメンバに知らせるように親鍵種を暗号化（Ｓ１０４）する。この暗号化に使用するメッセージ鍵は、その親鍵種が付与される論理的ノードの兄弟ノード以下の論理的ノードのメッセージ鍵であって、使用不可鍵リストに登録されていないものを用いて行う。この場合に使用されるメッセージ鍵は必ずしもひとつではない。その親鍵種を必要とするメンバすべてに親鍵種が送信できるという条件を満たしつつ、使用するメッセージ鍵の数が最小となるように、親鍵種を暗号化するメッセージ鍵が選択される。

次に、グループ鍵管理サーバ１０は、暗号化された親鍵種を各端末装置３０にマルチキャスト送信する（Ｓ１０５）。
その際に、親鍵種の暗号化は暗号処理部１４で行われ、通信を暗号化するメッセージ鍵は鍵情報記憶部１５に記憶された使用不可鍵リストに登録されていないもので暗号化する。 図７の例では、ノード［２］の親鍵種は、葉ノード［１２］［１３］［１４］［１５］に送信される。この場合、ノード［３］のメッセージ鍵が使用不可鍵リストに登録されているので、グループ鍵管理サーバ１０は、葉ノード［１２］［１３］のためにノード［６］のメッセージ鍵によりノード［２］の親鍵種を暗号化してこれをマルチキャスト送信し、且つ葉ノード［１４］［１５］のためにノード［７］のメッセージ鍵によりノード［２］の親鍵種を暗号化してこれをマルチキャスト送信する。

暗号化された親鍵種を受信した各端末装置３０（追加メンバに相当する端末装置３０を除く）は、暗号化された親鍵種を端末側暗号処理部３４で復号する（Ｓ１０６）。その際に、端末側暗号処理部３４は、端末側鍵情報記憶部３５内の使用不可鍵リストの中にないメッセージ鍵を用いて復号を行う。このメッセージ鍵は保持している親鍵種、兄弟ノードの親鍵種から計算によって求めることができる。端末装置３０は、受信した親鍵種をこのメッセージ鍵により復号して端末側鍵情報記憶部３５内の兄弟ノードの親鍵種として保存する。

次に、各端末装置３０（追加メンバに相当する端末装置３０を除く）は、復号して得た新たな親鍵種、及びすでに記憶している親鍵種から、その端末装置３０に対応する葉ノード４２から根ノード４１に向かう経路ノードの親鍵種、メッセージ鍵を端末側鍵管理部３３で逐次的に計算する（Ｓ１０７）。計算手法はグループ鍵管理サーバ１０と同じであるが、送信された親鍵種に対応した鍵のみ更新を行う。つまり、端末装置３０は端末側鍵情報記憶部３５に保存されているノードの親鍵種と、兄弟ノードの親鍵種として保存されている送信された親鍵種から、親ノードの新しいメッセージ鍵を求める。

次に、グループ鍵管理サーバ１０は、追加メンバがグループ鍵を求めることができるようにするため、木構造４０において追加メンバに相当する葉ノード４２から根ノード４１に向かう経路上ノードの兄弟ノードそれぞれの親鍵種を、追加メンバに相当する端末装置３０のメッセージ鍵（Ｓ１０２）にて暗号化する（Ｓ１０８）。
グループ鍵管理サーバ１０は、ステップＳ１０８にて暗号化した親鍵種を、追加メンバに相当する端末装置３０にユニキャストにより送信する（Ｓ１０９）。

追加メンバに相当する端末装置３０は、グループ鍵管理サーバ１０から送信された親鍵種を自身のメッセージ鍵を用いて復号する（Ｓ１１０）。そして、復号した親鍵種を端末側鍵情報記憶部３５に保存する。

追加メンバに相当する端末装置３０は、端末側鍵情報記憶部３５に格納されている、その端末装置３０に相当する葉ノード４２の経路上ノードの兄弟ノードの親鍵種とメッセージ鍵とから、経路上ノードのメッセージ鍵及び親鍵種を逐次的に計算し、最終的に根ノードのメッセージ鍵に相当するグループ鍵を計算により生成する（Ｓ１１１）。逐次的に計算して得られた、グループ鍵、メッセージ鍵及び親鍵種は端末側鍵情報記憶部３５に保存される。
上記手順により、追加メンバに相当する端末装置３０を含めたすべてのメンバに相当する端末装置３０が共通のグループ鍵を得ることができる。

［２．３．メンバ削除］
グループからメンバが削除される場合、マルチキャスト通信システム1は、グループから削除されるメンバが、グループ内で送信される情報を復元して閲覧することを防ぐため、メンバ削除時にグループ鍵を更新する、すなわち従来のグループ鍵を新たなグループ鍵に置き換える。このグループ鍵更新の処理の一例を図８に示す。図８は、マルチキャスト通信システム１におけるグループ鍵更新の処理例を示すシーケンス図である。

あるメンバを削除する旨の入力がグループ鍵管理サーバ１０になされると、グループ鍵管理サーバ１０の鍵管理部１３は、木構造情報４０の更新を行う（Ｓ２０１）。すなわち、鍵管理部１３は、削除するメンバに相当する葉ノード４２及びその親ノードである中間ノード４３を木構造から削除するとともに、削除するメンバに相当する葉ノード４２の兄弟ノードである別の葉ノード４２を、削除した中間ノード４３に代えて親ノードに昇格させる。

図４に示した木構造の状態においてノード［９］に相当するメンバを削除する場合の、木構造の例を図９に示す。図９（ａ）は、ノード［９］に相当するメンバを削除する前の状態を示し、図９（ｂ）は、ノード［９］に相当するメンバを削除した後の状態を示している。なお、図９（ａ）（ｂ）ともに木構造の左半分のみを示し、変更のない右半分は図示を省略している。

ノード［９］が削除される場合には、その親ノードであるノード［４］も削除され、削除されたノード［４］の位置に、ノード［９］の兄弟ノードであるノード［８］が昇格して従前のノード［４］の位置に移動することにより図９（ｂ）の状態となる。これにより、木構造に含まれるすべてのノードが２つの子ノードを持つことになる（葉ノード４２は除く）。

ノード［９］の削除によって木構造中の位置が変更された兄弟ノード［８］について、そのメッセージ鍵、親鍵種は以下のように扱われる。すなわち、ノード［８］のメッセージ鍵は、従前のメッセージ鍵のままとし、一方、ノード［８］は、元の親ノードであるノード［４］の親鍵種をノード［８］の新たな親鍵種とする。これは、ノード［４］の親鍵種を変更すると、ノード［４］の親鍵種を記憶している他のノード、すなわちノード［４］の兄弟ノードであるノード［５］およびその子ノードであるノード［１０］とノード［１１］に新たな親鍵種を送信する必要が生ずるからである。よって、この段階では、ノード［８］ではメッセージ鍵に一方向関数を使ったものが親鍵種という原則は成り立たなくなり、親鍵種を別途保持する必要がある。この保持した親鍵種はメンバ追加の際に親ノードのメッセージ鍵を求める鍵として利用される。

また、グループ鍵管理サーバ１０の鍵管理部１３は、メンバ削除の際に、削除されるメンバが保持していたメッセージ鍵を使用不可鍵リストに登録する（Ｓ２０１）。使用不可鍵リストは、メンバ追加／削除の際の鍵情報の送受信に利用する。また、木構造の各ノードの使用不可鍵数に１加えることで、メンバ追加の際に、鍵の再利用効率を高めることができる。

次に、グループ鍵管理サーバ１０の鍵管理部１３は、グループ鍵を更新するため、乱数生成などにより新たなグループ鍵を生成する（Ｓ２０２）。鍵情報記憶部１５に記憶されている従前のグループ鍵は、新たなグループ鍵に置換される。
グループ鍵管理サーバ１０の暗号処理部１４は、新たなグループ鍵を鍵情報記憶部１５内の、使用不可鍵リストに登録されていないメッセージ鍵で暗号化する（Ｓ２０３）。

図１０は、図９（ｂ）の場合のメッセージ鍵を暗号化する場合の例を示す図である。
図９（ｂ）の場合は、使用不可鍵リストには、削除されるノード［９］が有していたメッセージ鍵であるノード［４］、ノード［２］のメッセージ鍵が登録されるが、ノード［４］が木構造から削除されるためノード［４］のメッセージ鍵も使用不可鍵リストから削除される。結局、使用不可鍵リストには、ノード［２］のメッセージ鍵のみが登録されることとなる。

さて、グループ鍵管理サーバ１０の暗号処理部１４は、使用不可鍵リストに登録されていないメッセージ鍵を用いつつ、最も少ないメッセージ鍵数で全端末装置３０に新しいグループ鍵の送信ができるように、新しいグループ鍵を暗号化するメッセージ鍵を選択する。
前記新たなグループ鍵の暗号化を行う。

図１０に示す例では、グループ鍵管理サーバ１０の暗号処理部１４は、葉ノード［８］のために、ノード［８］のメッセージ鍵ＭＫ８を用いた新たなグループ鍵の暗号化を行い、葉ノード［１０］及び葉ノード［１１］のために、ノード［５］のメッセージ鍵ＭＫ５を用いた新たなグループ鍵の暗号化を行い、ノード［１２］からノード［１５］のために、ノード［３］のメッセージ鍵ＭＫ３を用いた新たなグループ鍵の暗号化を行う。すなわち、グループ鍵管理サーバ１０の暗号処理部１４は、新たなグループ鍵をメッセージ鍵ＭＫ８、メッセージ鍵ＭＫ５、メッセージ鍵ＭＫ３のそれぞれで暗号化した、三種類の暗号化された新たなグループ鍵を生成する。

次に、グループ鍵管理サーバ１０の管理部１２及び通信制御部１１は、暗号化したグループ鍵をマルチキャストにより全端末装置３０に送信する（Ｓ２０４）。例えば、図１０に示した例では、三種類の暗号化された新たなグループ鍵をそれぞれマルチキャストにより全端末装置３０に送信する。使用不可鍵リストが多ければ多いほど、暗号化に用いるメッセージ鍵の数が増えるため、より多くの暗号化の処理が必要になり通信量、計算量が大きくなる。
暗号化された新たなグループ鍵を受信した各端末装置３０は、端末側暗号処理部３４により暗号化された新たなグループ鍵を復号し、記憶する（Ｓ２０５）。

その際に、端末側暗号処理部３４は端末側鍵情報記憶部３５に記憶されている使用不可鍵リストに登録されていないメッセージ鍵で復号し、復号に成功したものを新たなグループ鍵として端末側鍵情報記憶部３５に記憶させる。例えば、図１０に示した例では、ノード［８］に対応する端末装置３０は、メッセージ鍵ＭＫ８により暗号化されたグループ鍵の復号に成功し、これを新たなグループ鍵として端末側鍵情報記憶部３５に記憶させる。また、ノード［１０］、ノード［１１］に対応する各端末装置３０は、メッセージ鍵ＭＫ５により暗号化されたグループ鍵の復号に成功し、これを新たなグループ鍵として端末側鍵情報記憶部３５に記憶させる。また、ノード［１２］からノード［１５］に対応する各端末装置３０は、メッセージ鍵ＭＫ３により暗号化されたグループ鍵の復号に成功し、これを新たなグループ鍵として端末側鍵情報記憶部３５に記憶させる。
上記手順により、本マルチキャスト通信システム１は、メンバ削除時に新しいグループ鍵を生成し、配布することができる。

[３．従来技術との比較]
本発明により、メンバ削除時には、新たなグループ鍵をグループ鍵管理サーバ１０で生成し、この新たなグループ鍵を暗号化して各メンバに送信し、メンバはそれを復号するのみであるため、計算量を小さくすることができる。また、メンバ追加時には、葉ノード４１から根ノード４３まで向かう経路上ノードのメッセージ鍵を更新するため、従来技術のＣＳ法で見られたメンバ削除による木構造の断片化を防ぐことができる。

図１１及び図１２に、本発明で要する計算量と、従来技術で要する計算量のシミュレーションを行った結果を示している。図１１はシミュレーションの対象となるグループの木構造を示す図であり、図１２は、従来技術のＣＳ法及びＯＦＴと本発明による方式のシミュレーション結果を示す一覧表である。

このシミュレーションでは、従来技術のＣＳ法及びＯＦＴと本発明による方式について、図１１に示したグループにおいてメンバＡ削除、メンバＣ削除、メンバＪ追加、メンバＥ削除、メンバＩ追加、メンバＫ追加、メンバＨ削除、メンバＬ追加がそれぞれ行われた場合の暗号化／復号に要する計算量、鍵計算に要する計算量、及びその鍵送信に要する通信量を算出した。ただし、ＣＳ法ではメンバ追加は定義されていないので、メンバ削除のみによって両者を比較する。

このシミュレーション結果によれば、本発明ではＣＳ法に比べ、通信量が少ないことがわかる。これは、本発明は木構造の使用不可鍵を再利用することで、通信効率が高まったためである。また、ＯＦＴと比べると、通信量という観点では本発明が増えてしまっているものの、計算量の観点ではＯＦＴに比べ優れていることがわかる。これは、ＯＦＴではメンバ削除時に葉ノード４２から根ノード４１までの各ノードの鍵を再計算する必要があるためである。

［４．本発明の利点］
本発明は、以下の利点を有する。
１．グループからメンバを削除する際に、メンバの親ノードの鍵を更新せずにグループ鍵のみを更新することにより、鍵の計算量を削減し、メンバを追加する際にメンバの削除時に更新しなかった親ノードの鍵を更新することによりマルチキャスト通信の通信量を削減することができる。本発明により、メンバ削除時には計算量のリソースが少なく、メンバ追加時に計算量のリソースが多いときに効率的なグループ鍵管理を行うことができる。

２．木構造の各ノードに使用不可鍵数を登録しておくことにより、メンバ追加位置を木構造の根ノードから逐次的に求めることができる。また、グループ鍵管理サーバは、使用不可鍵リストを保持することにより、グループ鍵送信のための暗号化するためのメッセージ鍵を見つけることができる。

３．各ノードの使用不可鍵数を根ノードから葉ノードに向かって逐次的に計算し、記憶させておくことにより、メンバ数をＮとした完全二分木の場合の計算量Ｏ(ｌｏｇＮ)で、メンバの追加位置を求めることができ、メンバ数が増えても小さい計算量で追加位置を求めることができる。

本実施の形態にかかるマルチキャスト通信システムの構成例を示すブロック図 グループ鍵管理サーバの構成例を示す機能ブロック図 端末装置の構成例を示す機能ブロック図 グループ鍵管理サーバの鍵情報記憶部、及び各端末装置の端末側鍵情報記憶部において保持される二分木による木構造の例を示す図 メンバ追加時にグループ鍵を更新する場合の動作例を示すシーケンス図 メンバ追加位置決定処理の例を示すフローチャート 図４の木構造に、ノード［９］をメンバ追加位置と決定してノード［１６］を追加した新たな木構造４の例を示す図 マルチキャスト通信システムにおけるグループ鍵更新の処理例を示すシーケンス図 （ａ）はノード［９］に相当するメンバを削除する前の木構造を示す図、（ｂ）はノード［９］に相当するメンバを削除した後の木構造を示す図 図９（ｂ）の場合のメッセージ鍵を暗号化する場合の例を示す図 シミュレーションの対象となるグループの木構造を示す図 従来技術のＣＳ法及びＯＦＴと本発明による方式のシミュレーション結果を示す一覧表

符号の説明

１ … マルチキャスト通信システム
１０ … グループ鍵管理サーバ
１３ … 鍵管理部
１５ … 鍵情報記憶部
２０ … ネットワーク
３０ … 端末装置
３３ … 端末側鍵管理部
３５ … 端末側鍵情報記憶部

Claims (3)

1. ネットワークに接続され、二分木構造の根ノードに相当するグループ鍵管理サーバと、前記ネットワークに接続され、前記二分木構造の葉ノードに相当する複数の端末装置とを有するマルチキャスト通信システムであって、
   前記グループ鍵管理サーバは、前記二分木構造の各ノードについて、メッセージ鍵と親鍵種とを記憶する鍵情報記憶部と、メンバ追加時に、前記二分木構造の根ノードのメッセージ鍵であるグループ鍵を生成する鍵管理部とを有し、
   前記端末装置のそれぞれは、自己のメッセージ鍵と、自己の兄弟ノードの親鍵種と、前記二分木構造の経路上ノードのメッセージ鍵と親鍵種と、前記経路上ノードの兄弟ノードの親鍵種とを記憶する端末側鍵情報記憶部と、前記端末側鍵情報記憶部に記憶された親鍵種から、前記二分木構造の根ノードのメッセージ鍵であるグループ鍵を生成する端末側鍵管理部とを有する
   ことを特徴とするマルチキャスト通信システム。
2. 二分木構造の葉ノードに相当する複数の端末装置が接続されたネットワークに接続され、二分木構造の根ノードに相当するグループ鍵管理サーバであって、
   前記根ノードと前記葉ノードを有する二分木構造を示す木構造情報と、前記木構造に含まれる各ノードについて、暗号化に使用できないメッセージ鍵である使用不可鍵の数を示す使用不可鍵数とを記憶する鍵情報記憶部と
   メンバ追加時には、前記鍵情報記憶部に記憶された使用不可鍵数を用いて、前記二分木構造におけるメンバの追加位置を決定する鍵管理部と
   を有することを特徴とするグループ鍵管理サーバ。
3. 前記鍵情報記憶部は、暗号化に使用できないメッセージ鍵のリストである使用不可鍵リストをさらに記憶し、
   メンバ削除時に、前記使用不可鍵リストに含まれないメッセージ鍵を用いて新たなグループ鍵を暗号化する暗号処理部と、
   前記暗号化処理部によって暗号化されたグループ鍵を各端末装置にマルチキャストにより送信する通信制御部と
   をさらに有することを特徴とする請求項２に記載のグループ鍵管理サーバ。

Images