JP2009239839A - グループ暗号通信における鍵管理方法、及び、鍵管理プログラム - Google Patents

Abstract

【課題】ユーザが複数のグループに所属する場合にも、当該ユーザのクライアントで複数のグループ鍵を管理できるようにすること。
【解決手段】 識別情報入力部２２にメンバーの識別情報が入力されると、並べ替え処理部２３が所定の順序で並べ替え、要求送信部２４を介して鍵管理サーバ１０に送信する。ハッシュ処理部２５は、並べ替えられた識別情報を入力として第１種チェックサム値ＣＳ１を算出し、切り出し部２６が第１種チェックサム値の前半部分を切り出して第２種チェックサム値ＣＳ２を生成する。鍵管理サーバ１０からグループ鍵Ｒ１を受信すると、第２種チェックサム値により標準テーブル２１ａを検索し、該当するレコードがあれば移行キーフィールドにフラグを立て、新たなグループ鍵を第１種チェックサム値と共に拡張テーブル２１ｂに格納する。該当するレコードがないとグループ鍵を第２種チェックサム値と共に標準テーブルに格納する。
【選択図】図１

Description

本発明は、複数のユーザにより構成されるグループ毎に鍵管理サーバにより生成されたグループ鍵を各ユーザのクライアントのデータベースで管理するグループ暗号通信における鍵管理方法、及び、この方法を実現するために各クライアントにより実行されるプログラムに関する。

ローカルエリアネットワーク等のネットワーク内の特定のユーザ間で秘密にしたい情報をやりとりする場合、これらの特定のユーザによりグループを形成し、グループの構成メンバーのみが知り得るグループ鍵を用いて情報を暗号化してやりとりするグループ暗号通信が利用される。

特許文献１には、ＩＣカード内に格納されたマスター鍵と通信宛先情報とを入力データとしてハッシュ関数による計算でグループ鍵を生成して暗号化、復号を行うシステムが開示されている。

特開平５−３４７６１６号公報

しかしながら、上記の特許文献１に開示されるシステムは、それぞれの端末で保存しているグループ鍵が１つであるため、通信相手先が変更される毎にグループ鍵を新たに作成しなければならず、例えば特定のユーザが複数のグループに所属し、それぞれのグループ内で暗号通信を行う場合には、鍵の生成処理に時間がかかる。

本発明は、上記の問題点に鑑みてなされたものであり、その課題は、ユーザが複数のグループに所属する場合にも、当該ユーザのクライアントで複数のグループ鍵を管理することが可能な鍵管理方法及び鍵管理プログラムを提供することにある。

上述した課題を解決するために、本発明に係るグループ暗号通信における鍵管理方法は、複数のユーザにより構成されるグループ毎に鍵管理サーバにより生成されたグループ鍵を各ユーザのクライアントのデータベースで管理するシステムを前提として、鍵管理サーバに、グループを構成する複数のユーザの識別情報に基づいて生成される第１種グループ識別情報に基づいてグループ鍵を生成させて当該グループを構成する各ユーザのクライアントに送信させ、各クライアントのデータベースに、第１種グループ識別情報の所定の一部を切り出して構成される第２種グループ識別情報と当該識別情報に対応するグループ鍵とを格納する標準テーブルと、第１種グループ識別情報と当該識別情報に対応するグループ鍵とを格納する拡張テーブルとを用意し、各クライアントに、鍵管理サーバから送信されるグループ鍵を第２種グループ識別情報と対応させて標準テーブルに格納させて管理させると共に、当該標準テーブル内で異なるグループ鍵の第２種グループ識別情報が一致した場合のみ、当該一致したグループ鍵の一方を第１種グループ識別情報と対応させて拡張テーブルに格納させて管理させることを特徴とする。

なお、鍵管理サーバは、複数のユーザの識別情報を所定の順序で並び替えてから第１種グループ識別情報を生成することが望ましい。

また、各クライアントは、ユーザがデータベースに格納された特定のグループ鍵を必要とする場合には、当該グループを構成する複数のユーザの識別情報に基づいて第１種グループ識別情報及び第２種グループ識別情報を生成し、生成された第２種グループ識別情報に基づいて標準テーブルを検索して対応するグループ鍵を抽出し、標準テーブルのみではグループ鍵を特定できない場合には、第１種グループ識別情報に基づいて拡張テーブルを検索し、両テーブルの検索結果に基づいて対応するグループ鍵を抽出することができる。この場合、各クライアントは、複数のユーザの識別情報を所定の順序で並び替えてから第１種グループ識別情報を生成することが望ましい。

一方、本発明に係るグループ暗号通信における鍵管理プログラムは、複数のユーザにより構成されるグループ毎に鍵管理サーバにより生成されたグループ鍵を各ユーザのクライアントのデータベースで管理するためものであり、各クライアントに、鍵管理サーバから、グループを構成する複数のユーザの識別情報に基づいて生成された第１種グループ識別情報に基づいて生成されたグループ鍵を受信する手順、第１種グループ識別情報を生成する手順、その所定の一部を切り出して第２種グループ識別情報を生成する手順、データベースの標準テーブルに第２種グループ識別情報と当該識別情報に対応するグループ鍵とを格納する手順、当該標準テーブル内で異なるグループ鍵の第２種グループ識別情報が一致した場合のみ、データベースの拡張テーブルに当該一致したグループ鍵の一方を第１種グループ識別情報と対応させて格納する手順を実行させることを特徴とする。

また、各クライアントに、ユーザがデータベースに格納された特定のグループ鍵を必要とする場合には、当該グループを構成する複数のユーザの識別情報に基づいて第１種グループ識別情報及び第２種グループ識別情報を生成し、生成された第２種グループ識別情報に基づいて標準テーブルを検索して対応するグループ鍵を抽出する手順、標準テーブルのみではグループ鍵を特定できない場合には、第１種グループ識別情報に基づいて拡張テーブルを検索し、両テーブルの検索結果に基づいて対応するグループ鍵を抽出する手順をさらに実行させることができる。この場合、各クライアントに、複数のユーザの識別情報を所定の順序で並び替えてから第１種グループ識別情報を生成する手順を実行させることが望ましい。

ユーザが複数のグループに所属する場合には、上記のように各ユーザのクライアントにデータベースを備えてグループ毎にグループ鍵を格納しておけば、鍵の生成にかかる時間や鍵管理サーバとの通信が節約できる。ただし、グループを識別するための情報の情報量が増えると、データベースの容量も大きくなり、メモリに収納できなくなったり、不必要に大きなメモリ容量が要求されたりする。一方、鍵管理サーバでグループ鍵を生成する際に異なるグループに対して同一のグルーブ鍵が生成されるのを防ぐためには、グループを識別するための情報としてある程度の情報量が必要とされる。

そこで、本発明では、上記のように、グループを識別する情報として、異なるグループに対して同一のグループ鍵が生成されるのを防ぐのに十分な情報量を持つ第１種グループ識別情報と、その一部(例えば前半、あるいは後半等)を切り出して構成される第２種グループ識別情報とを用い、鍵管理サーバでのグループ鍵の生成には第１種グループ識別情報を用い、クライアントのデータベースへの登録には基本的には第２種グループ識別情報を用いる。そして、クライアントのデータベースへの登録に際して異なるグループに対して第２種グループ識別情報が一致した場合にのみ第１種グループ識別情報を用いて登録するようにしている。これにより、異なるグループに対するグループ鍵の一致を避けながら、クライアントのデータベースの容量を抑え、必要とされるメモリ容量が膨大となるのを防ぐことができる。

また、鍵管理サーバ又はクライアントが第１種グループ識別情報を生成する際には、ユーザの識別情報を所定の順序で並べ替えてから生成することにより、同一の構成メンバーに対して異なるグループ鍵が生成されるのを防ぐことができ、グループ鍵の増大により管理の負荷が増加するのを防ぐことができる。第１種グループ識別情報は、構成メンバーの識別情報を入力として、例えばハッシュ関数を用いて計算により求められるが、入力される際に識別情報の順序が異なると、同じ構成メンバーに対して異なるチェックサム値(ハッシュ値)が生成され、これに基づいて生成されるグループ鍵の数が膨大となる。上記のように識別情報を並べ替えてからチェックサム値を求めることにより、同一の構成メンバーに対しては単一のチェックサム値のみが得られることになり、グルーブ鍵の数の増加を防ぐことができる。

以下、本発明にかかるグループ暗号通信における鍵管理方法及び鍵管理プログラムの実施形態を図面に基づいて説明する。図１は、実施形態の鍵管理方法を実現するためのネットワークシステムの一部を簡略化して示したブロック図である。このシステムは、ローカルエリアネットワーク内で互いに接続された鍵管理サーバ１０とユーザクライアント２０とから構成されている。

鍵管理サーバ１０は、汎用コンピュータであり、所定のプログラムを実行することにより、各クライアントからの要求に応じて複数のユーザにより構成されるグループ間の暗号通信を行うためのグループ鍵を生成して送信する機能を実現している。また、ユーザクライアント２０は、パーソナルコンピュータであり、鍵管理プログラムを実行することにより、鍵管理サーバ１０から送信されたグループ鍵を管理する。図１では、これらの機能に着目して本発明に関連する構成のみを示している。

鍵管理サーバ１０は、ユーザクライアント２０からのグループ鍵生成の要求を受け付ける要求受信部１１と、この要求に含まれるユーザ識別情報を所定の順序で並び替える並べ替え処理部１２と、並べ替えられた識別情報を入力としてハッシュ関数により固定長の第１種チェックサム値(ハッシュ値)ＣＳ１を生成するハッシュ処理部１３と、この第１種チェックサム値ＣＳ１と鍵管理サーバ１０に登録されたマスター鍵ＫＭとに基づいて疑似乱数を用いてグルーブ鍵Ｒ１を生成する鍵生成処理部１４と、生成されたグループ鍵Ｒ１を暗号化する暗号化部１５と、暗号化されたグループ鍵を要求のあったユーザクライアントに送信する鍵送信部１６とを備えている。

ユーザクライアント２０は、鍵管理サーバ１０により生成されたグループ鍵を格納するデータベース２１と、グループを構成するユーザの識別情報を入力する識別情報入力部２２と、入力されたユーザ識別情報を所定の順序で並び替える並べ替え処理部２３と、並べ替えられた識別情報を鍵管理サーバ１０に送信する要求送信部２４と、同じく並べ替えられた識別情報を入力としてハッシュ関数により固定長の第１種チェックサム値(ハッシュ値)ＣＳ１を生成するハッシュ処理部２５と、第１種チェックサム値ＣＳ１の所定の一部を切り出して第２種チェックサム値ＣＳ２を生成する切り出し部２６と、鍵管理サーバ１０から送信される暗号化されたグループ鍵を受信する鍵受信部２７と、暗号化されたグループ鍵を復号する復号部２８と、データベース２１から必要なグループ鍵を抽出するグループ鍵抽出部２９とを備えている。また、並び替え処理部２３と要求送信部２４との間には、第１スイッチＳＷ１が設けられており、鍵受信部２７と復号部２８との間には、第２スイッチＳＷ２が設けられている。

ハッシュ処理部１３及び２５は、複数の識別情報を一連に羅列した文字列を入力としてハッシュ関数に入力し、同一の入力に対しては常に同一のチェックサム値を出力する。このため、グループの構成メンバーが同一であっても、識別情報の並び順が異なると、異な
るチェックサム値が出力される。そこで、上記のように並び替え処理部１２及び２３を設けることにより、同一の構成メンバーに対しては単一のチェックサム値のみが得られることになり、グルーブ鍵の数の増加を防ぐことができる。

例えば、並べ替えをせずにチェックサム値を生成してグループ鍵を生成する場合には、構成員の増加に対して生成可能なグループ鍵の数が幾何級数的に増加し、チェックサム値の長さが２４ビットの場合には構成メンバー数１５以上でグループ鍵の数がチェックサム値の空間(2²⁴)を越え、チェックサム値の長さが４８ビットの場合には構成メンバー数２０以上でグループ鍵の数がチェックサム値の空間(2⁴⁸)を越え、全てのグループ鍵に対してユニークなチェックサム値を用意することができず、チェックサム値が確実に衝突することになる。これに対し、上記のように識別情報を並べ替えてからチェックサム値を生成する場合には、構成員数の増加に対して生成可能なグルーブ鍵の数は比例して増加するのみであるため、少ないビット数のチェックサム値であっても衝突を避けることができ、必要とされるメモリの容量を小さくすることができる。

なお、ユーザの識別情報は、通常はユーザクライアント２０内の並べ替え処理部２３で並べ替えられてから鍵管理サーバ１０に送信されるため、鍵管理サーバ１０では並べ替えの必要はない。ただし、何らかの理由でクライアント側の並べ替え処理部が機能しなかった場合や、並べ替え処理部を持たないクライアントからの入力をも想定して、鍵管理サーバ１０にも並べ替え処理部１３を設けている。

第１種チェックサム値ＣＳ１は、第１種グループ識別情報であり、ユーザ数に対して衝突の確率が無視できる程度の長さ、この例では４８ビットの長さを持ち、第２種チェックサム値ＣＳ２は、第２種グループ識別情報であり、この例では第１種チェックサム値ＣＳ１の上位２４ビットを切り出して利用される。データベース２１には、第２種チェックサム値ＣＳ２とグループ鍵Ｒ１との組み合わせをレコードとして格納する標準テーブル２１ａと、第１種チェックサム値ＣＳ１とグループ鍵Ｒ１との組み合わせをレコードとして格納する拡張テーブル２１ｂとが含まれている。なお、標準テーブル２１ａの各レコードには、上記の第２種チェックサム値ＣＳ２とグループ鍵Ｒ１とを格納するフィールドの他に、第２種チェックサム値が衝突した場合にフラグが立てられる移行キーフィールドが含まれている。また、拡張テーブル２１ｂは、標準テーブル２１ａに登録される第2種チェックサム値ＣＳ２ではグループの識別ができない場合(衝突する場合)に限って利用されるものであり、第2種チェックサム値ＣＳ２で全てのグループが識別できる場合には、利用されない。

このような２つのテーブルを使い分けるのは、データベース２１の容量が過大になるのを防ぎつつ、グループ鍵を確実に識別できるようにするためである。鍵管理サーバ１０は、第１種チェックサム値ＣＳ１に基づいてグループ鍵を生成するため、鍵の値はユニークになる。ただし、ユーザクライアント２０の標準テーブル２１ａ上では、容量を小さくするために短い第２種チェックサム値を使用していることから、異なるグループ鍵に対して第２種チェックサム値が一致し、識別不能になる可能性がある。そこで、このような場合には、標準テーブルの衝突したレコードの移行キーフィールドにフラグを立て、このレコードに既に登録されているグループ鍵はそのまま維持し、拡張テーブルに新たに登録しようとするグループ鍵と第１種チェックサム値とを格納するようにしている。

例えば、標準テーブルに第１のグループの第2種チェックサム値とグループ鍵とが登録されている状態で、第2のグループのグループ鍵を登録しようとしたとき、第2のグループの第2種チェックサム値が第1のグループの第2種チェックサム値と一致した場合には、標準テーブル２１ａの第１のグループのグループ鍵が格納されたレコードの移行キーフィールドにフラグを立て、拡張テーブル２１ｂに新規レコードを追加し、そこに第２グループ
のグループ鍵と第１種チェックサム値とを登録する。グループ鍵を抽出する際には、第2種チェックサム値により標準テーブル２１ａを検索し、抽出されたレコードの移行キーフィールドにフラグが立ててなければ、標準テーブルに格納されたグループ鍵を用いる。フラグが立ててある場合には、第１種チェックサム値により拡張テーブル２１ｂを検索し、一致するレコードがあれば拡張テーブル２１ｂに格納されたグループ鍵を用い、一致するレコードがなければ標準テーブル２１ａに格納されたグループ鍵を用いることになる。

これにより、通常は各レコードの容量が小さい標準テーブル２１ａを利用することによりデータベース２１の容量を小さく抑えつつ、標準テーブル２１ａのみからでは区別できない場合には、各レコードの容量が大きな拡張テーブル２１ｂをも利用することにより、グループ鍵を確実に識別することができる。

例えば、グループ数を5000000と仮定し、24ビットの第２種チェックサム値を用いた場合の予測衝突数を1000と仮定すると、上記のように標準テーブルと拡張テーブルとの組み合わせを利用した場合のデータベースの容量は、以下の通り約4.8Mbyteになる。
(第2種チェックサム値の長長さ(24bit) × 衝突しないグループの数)
＋ (第1種チェックサム値の長さ(48bit) × 衝突するグループの数)
= (3byte × (5000000 − 1000)) ＋ (6byte × 1000)
= 5003000byte (約4.8Mbyte)

これに対して、全てのグループに対して第１種チェックサム値を用いて拡張テーブルに登録した場合のデータベースの容量は、以下の通り約28.6Mbyteとなり、約６倍の容量が必要となる。
第１種チェックサム値の長さ(48bit) × グループの数
= 6byte × 5000000
= 30000000byte (約28.6Mbyte)

次に、上記のような構成を備えたシステムにおいて実現される本実施形態の鍵管理方法の流れについて、図２〜図４に示すフローチャートに基づいて説明する。図２は、グループ鍵を登録する際のユーザクライアント２０内での処理を示し、図３は、グループ鍵を生成する際の鍵管理サーバ１０内での処理を示し、図４は、既に登録されているグループ鍵を抽出する際のユーザクライアント２０内での処理を示す。なお、図２のグループ鍵登録の処理と、図４のグループ鍵抽出の処理とは、識別情報入力部２２に識別情報を入力する際にユーザがいずれかを選択するように設定されている。

ユーザクライアント２０を利用するあるユーザが、当該ユーザを含む複数のメンバーにより構成されるグループ内でグループ暗号通信を行う場合、暗号化及び復号のためのグループ鍵を取得する必要がある。グループ鍵の生成には、鍵管理サーバ１０のみが所有するマスター鍵が必要であるため、鍵管理サーバ１０のみがグループ鍵を生成することができる。ただし、グループ暗号通信の都度サーバにグループ鍵の生成を依頼するのでは手間も時間もかかるため、一度作成したグループ鍵はユーザクライアント２０のデータベース２１に登録し、必要に応じてデータベースから抽出して利用するようにしている。

ユーザがグループ鍵を登録するために識別情報入力部２２にグループを構成するメンバーの識別情報を入力すると、図２に示すように、ユーザクライアント２０はこれを受け付ける(S001)。識別情報が入力されると、並べ替え処理部２３が入力された識別情報を所定の順序で並べ替える(S002)。例えば、英数字であればアルファベット昇順に並べ替える。この時点では第１スイッチＳＷ１及び第２スイッチＳＷ２は共にＯＦＦ状態に設定されている。

次に、ユーザクライアント２０は第１スイッチＳＷ１をＯＮにして識別情報を要求送信部２４に伝え、要求送信部２４はこの情報を鍵管理サーバ１０に送信する(S003)。そして、ユーザクライアント２０は、第２スイッチＳＷ２をＯＮにし、鍵受信部２７は、鍵管理サーバ１０からのグループ鍵の受信を待って待機する(S004)。

一方、ユーザクライアント２０のハッシュ処理部２５は、並べ替えられた識別情報を入力としてハッシュ関数による演算により第１種チェックサム値ＣＳ１を算出する(S005)。そして、切り出し部２６が第１種チェックサム値ＣＳ１の前半部分を切り出して第２種チェックサム値ＣＳ２を生成する(S006)。

鍵管理サーバ１０は、図３に示すように、要求受信部１１がグループメンバーの識別情報を受信し(S101)、並べ替え部１２が受信した識別情報を所定の順序で並べ替える(S102)。そして、ハッシュ処理部１３が並べ替えられた識別情報を入力としてハッシュ関数を用いた演算により第１種チェックサム値ＣＳ１を生成し(S103)、鍵生成部１４が第１種チェックサム値ＣＳ１とマスター鍵ＫＭとを入力として疑似乱数処理を行うことにより、グループ鍵Ｒ１を生成する(S104)。暗号化部１５は、生成されたグループ鍵Ｒ１を暗号化して鍵送信部１６に送り(S105)、鍵送信部１６は暗号化されたグループ鍵を要求元のユーザクライアント２０に送信する(S106)。

ユーザクライアント２０は、鍵受信部２７が鍵管理サーバ１０から暗号化されたグループ鍵を受信すると(S007, Yes)、これを復号部２８が復号してグルーブ鍵Ｒ１を得る(S008)。そして、このグループ鍵をデータベース２１に登録するため、ステップS006で生成した第２種チェックサム値ＣＳ２により標準テーブル２１ａを検索する(S009)。

該当するレコードがあった場合(S010, Yes)には、既に同一の第２種チェックサム値で他のグループに対応するグループ鍵が登録されていることを意味するため、第２種チェックサム値では登録しようとするグループ鍵が既に登録されているグループ鍵と区別ができないこととなる。そこで、該当したレコードの移行キーフィールドにフラグを立て(S011)、今回登録しようとするグループ鍵と第１種チェックサム値ＣＳ１との組み合わせを拡張テーブル２１ｂに格納する(S012)。

該当するレコードがなかった場合(S010, No)には、鍵管理サーバ１０により生成されたグループ鍵Ｒ１を切り出し部２６から出力される第２種チェックサム値ＣＳ２と共に標準テーブル２１ａに格納する(S013)。

次に、ユーザがグループ暗号通信をするに当たり、既に登録されているグループ鍵をデータベース２１から抽出する場合には、図４に示すように、識別情報入力部２２にグループを構成するメンバーの識別情報を入力し、ユーザクライアント２０がこれを受け付ける(S201)。識別情報が入力されると、並べ替え処理部２３が入力された識別情報を所定の順序で並べ替える(S202)。ユーザクライアント２０のハッシュ処理部２５は、並べ替えられた識別情報を入力としてハッシュ関数による演算により第１種チェックサム値ＣＳ１を算出する(S203)。そして、切り出し部２６が第１種チェックサム値ＣＳ１の前半部分を切り出して第２種チェックサム値ＣＳ２を生成する(S204)。

そして、グループ鍵抽出部２９は、ステップS204で生成した第２種チェックサム値ＣＳ２により標準テーブル２１ａからレコードを抽出し(S205)、このレコードの移行キーフィールドにフラグが立てられているか否かをチェックする(S206)。フラグが立てられていた場合(S206, Yes)には、ステップS203で生成された第1種チェックサム値ＳＣ１に基づいて拡張テーブル２１ｂを検索する(S207)。そして、拡張テーブル２１ｂに一致するレコードがあるか否かを判断する(S208)。一致するレコードが存在すれば、ステップS205で抽出し
たレコードに代えて拡張テーブルからレコードを抽出する(S209)。拡張テープルに一致するレコードがなければ、ステップS205で抽出したレコードをそのまま用いる。そして、抽出されたレコードに登録されているグループ鍵を出力する(S210)。ユーザは、このグループ鍵を用いて情報を暗号化して送信し、あるいは、暗号化されて送信されてきた情報を復号することができる。

なお、図２のステップS004はグループ鍵を受信する手順、ステップS005は第１種チェックサム値を生成する手順、ステップS006は第２種チェックサム値を生成する手順、ステップS012は拡張テーブルにグループ鍵を第１種グループ識別情報と対応させて格納する手順、ステップS013は標準テーブルに第２種グループ識別情報とグループ鍵とを格納する手順に該当する。また、図４のステップS203〜S205は、標準テーブルを検索して対応するグループ鍵を抽出する手順、ステップS206〜S209は標準テーブルのみではグループ鍵を特定できない場合に第１種グループ識別情報に基づいて拡張テーブルを検索して両テーブルの検索結果に基づいて対応するグループ鍵を抽出する手順、ステップS202及びS203は識別情報を所定の順序で並び替えてから第１種グループ識別情報を生成する手順に相当する。

次に、ユーザクライアント２０のデータベース２１に含まれる標準テーブル２１ａ及び拡張テーブル２１ｂの登録内容の具体例について説明する。以下の表１は、ある状況でのユーザAの利用するユーザクライアント内の標準テーブル２１ａの内容を示す。移行キーフィールドには、初期状態では０が設定されており、フラグを立てると１が設定される。なお、以下で使用するチェックサム値とグループ鍵の具体的な値は簡易的に連続した値とするが、実際は無作為な値となる。

上記の前提で、グループAE用の通信が発生し、AEの第１種チェックサム値と第２種チェックサム値を作成したところ、第１種チェックサム値は”0x80001000000”であり、第２種チェックサム値はその上位24bitである”0x100002”となった。ここで第２種チェックサム値”0x100002”は、グループAC用の第２種チェックサム値と衝突する。そこで、標準テーブルの第２種チェックサム値”0x100002”のレコードには表２に示すように、移行キーフィールドにフラグが立てられ、グループAEに関するグループ鍵は表３に示すように拡張テーブル２１ｂに移行される。なお、グループ鍵自体は第１種チェックサム値ＣＳ１に基づいて生成されているため、ユニークであり、そのまま拡張テープルに移行させて利用できる。

次に、上記とは異なるユーザＣが利用するユーザクライアントのデータベースに格納された標準テーブルの内容を表４に示す。

ここで、グループAC間の通信が発生したとする。グループACの第１種チェックサム値は上記のように”0x80001000000”、第２種チェックサム値は”0x100002”である。ただし、ユーザＣの標準テーブル２１ａ上では、第２種チェックサム値”0x100002”は他のレコードと衝突していないため、グループACについて拡張テーブルを使用する必要がなく、以下の表５に示すように標準テーブルのみで識別可能である。

上記のように２つのテーブルを使い分ける場合には、同じメンバーにより構成されるグループについて、一方のユーザは拡張テーブルを使用し、他のユーザは標準テーブルを使用する状況となることもあり得るが、グループ鍵の値は同一であり、このグループ鍵を用いて暗号通信が可能である。

本発明の実施形態に係る鍵管理方法を実現するためのシステムの構成を模式的に示すブロック図である。 実施形態の鍵管理方法によるグループ鍵登録時のユーザクライアントの処理を示すフローチャートである。 実施形態の鍵管理方法によるグループ鍵生成時の鍵管理サーバの処理を示すフローチャートである。 実施形態の鍵管理方法によるグループ鍵抽出時のユーザクライアントの処理を示すフローチャートである。

符号の説明

１０ 鍵管理サーバ
１１ 要求受信部
１２ 並び替え処理部
１３ ハッシュ処理部
１４ 鍵生成部
１５ 暗号化部
１６ 鍵送信部
２０ ユーザクライアント
２１ データベース
２１ａ 標準テーブル
２１ｂ 拡張テーブル
２２ 識別情報入力部
２３ 並び替え処理部
２４ 要求送信部
２５ ハッシュ処理部
２６ 切り出し部
２７ 鍵受信部
２８ 復号部
２９ グループ鍵抽出部

Claims (7)

1. 複数のユーザにより構成されるグループ毎に鍵管理サーバにより生成されたグループ鍵を前記各ユーザのクライアントのデータベースで管理する鍵管理方法において、
   前記鍵管理サーバは、グループを構成する複数のユーザの識別情報に基づいて生成される第１種グループ識別情報に基づいてグループ鍵を生成して当該グループを構成する各ユーザのクライアントに送信し、
   前記各クライアントのデータベースには、前記第１種グループ識別情報の所定の一部を切り出して構成される第２種グループ識別情報と当該識別情報に対応するグループ鍵とを格納する標準テーブルと、前記第１種グループ識別情報と当該識別情報に対応するグループ鍵とを格納する拡張テーブルとが用意され、
   前記各クライアントは、前記鍵管理サーバから送信されるグループ鍵を前記第２種グループ識別情報と対応させて前記標準テーブルに格納して管理すると共に、当該標準テーブル内で異なるグループ鍵の第２種グループ識別情報が一致した場合のみ、当該一致したグループ鍵の一方を第１種グループ識別情報と対応させて前記拡張テーブルに格納して管理することを特徴とするグループ暗号通信における鍵管理方法。
2. 前記鍵管理サーバは、前記複数のユーザの識別情報を所定の順序で並び替えてから前記第１種グループ識別情報を生成することを特徴とする請求項１に記載のグループ暗号通信における鍵管理方法。
3. 前記各クライアントは、ユーザが前記データベースに格納された特定のグループ鍵を必要とする場合には、当該グループを構成する複数のユーザの識別情報に基づいて前記第１種グループ識別情報及び前記第２種グループ識別情報を生成し、生成された第２種グループ識別情報に基づいて前記標準テーブルを検索して対応するグループ鍵を抽出し、前記標準テーブルのみではグループ鍵を特定できない場合には、前記第１種グループ識別情報に基づいて前記拡張テーブルを検索し、両テーブルの検索結果に基づいて対応するグループ鍵を抽出することを特徴とする請求項１または２に記載のグループ暗号通信における鍵管理方法。
4. 前記各クライアントは、前記複数のユーザの識別情報を所定の順序で並び替えてから前記第１種グループ識別情報を生成することを特徴とする請求項３に記載のグループ暗号通信における鍵管理方法。
5. 複数のユーザにより構成されるグループ毎に鍵管理サーバにより生成されたグループ鍵を前記各ユーザのクライアントのデータベースで管理するための鍵管理プログラムにおいて、
   前記各クライアントに、
   前記鍵管理サーバから、グループを構成する複数のユーザの識別情報に基づいて生成された第１種グループ識別情報に基づいて生成されたグループ鍵を受信する手順、
   前記第１種グループ識別情報を生成する手順、
   前記第１種グループ識別情報の所定の一部を切り出して第２種グループ識別情報を生成する手順、
   前記データベースの標準テーブルに前記第２種グループ識別情報と当該識別情報に対応するグループ鍵とを格納する手順、
   当該標準テーブル内で異なるグループ鍵の第２種グループ識別情報が一致した場合のみ、前記データベースの拡張テーブルに当該一致したグループ鍵の一方を第１種グループ識別情報と対応させて格納する手順を実行させることを特徴とするグループ暗号通信における鍵管理プログラム。
6. 前記各クライアントに、
   ユーザが前記データベースに格納された特定のグループ鍵を必要とする場合には、当該グループを構成する複数のユーザの識別情報に基づいて前記第１種グループ識別情報及び前記第２種グループ識別情報を生成し、生成された第２種グループ識別情報に基づいて前記標準テーブルを検索して対応するグループ鍵を抽出する手順、
   前記標準テーブルのみではグループ鍵を特定できない場合には、前記第１種グループ識別情報に基づいて前記拡張テーブルを検索し、両テーブルの検索結果に基づいて対応するグループ鍵を抽出する手順をさらに実行させることを特徴とする請求項５に記載のグループ暗号通信における鍵管理プログラム。
7. 前記各クライアントに、前記複数のユーザの識別情報を所定の順序で並び替えてから前記第１種グループ識別情報を生成する手順を実行させることを特徴とする請求項６に記載のグループ暗号通信における鍵管理プログラム。

Images