(57)【要約】【課題】複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の第１の鍵管理装置のうち一部を効率的に無効にできるデータ処理方法を提供する。【解決手段】メインサーバ２がサブサーバ３＿ｐをリボークする場合に、Ｐ個のサブサーバ３＿ｐのうち、リボークするサブサーバ３＿ｐを除く他のサブサーバ３＿ｐとの間の上記暗号化通信に用いる新たな鍵暗号鍵データＫＥＫを後述するＲＬＫＨ方式を基に取得する。そして、メインサーバ２がリボークしないサブサーバ３＿ｐに予め設定されリボークするサブサーバ３＿ｐに設定されていない鍵データおよびラベルデータのうち、上記新たな鍵暗号鍵データＫＥＫを取得するために用いるデータをリボークしないサブサーバ３＿ｐに指定する。【選択図】  図１
2004328233.tif 000002
【特許請求の範囲】
【請求項１】
複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の第１の鍵管理装置と、当該複数の第１の鍵管理装置を管理する第２の鍵管理装置とを用いて行うデータ処理方法であって、
前記複数の第１の鍵管理装置のうち無効にする前記第１の鍵管理装置を除く他の前記第１の鍵管理装置との間の前記暗号化通信に用いる新たな前記鍵データを前記第２の鍵管理装置が取得する第１の工程と、
前記他の第１の鍵管理装置が予め保持し前記無効にする第１の鍵管理装置が保持しないデータのうち、前記第１の工程で取得した前記新たな鍵データを当該他の第１の鍵管理装置が取得するために用いるデータを前記第２の鍵管理装置が当該他の第１の鍵管理装置に指定する第２の工程と
を有するデータ処理方法。
【請求項２】
前記第２の工程で前記第２の鍵管理装置から指定されたデータを用いて、前記新たな鍵データを前記第１の鍵管理装置が取得する第３の工程
をさらに有する請求項１に記載のデータ処理方法。
【請求項３】
前記複数の第１の鍵管理装置のうち暗号化通信先として無効にする前記受信装置の鍵管理を行う前記第１の鍵管理装置に対して、前記無効にする受信装置を前記第２の鍵管理装置が指定する第４の工程と、
前記第４の工程で前記指定を受けた前記第１の鍵管理装置が、当該第１の鍵管理装置に割り当てられた前記複数の受信装置のうち、前記指定された前記受信装置を除く他の前記受信装置との間の暗号化通信に用いる新たな前記鍵データを取得する第５の工程と
を有する請求項１に記載のデータ処理方法。
【請求項４】
前記第２の鍵管理装置が、第１の鍵データで暗号化したデータを前記複数の第１の鍵管理装置に送信する第６の工程と、
前記複数の第１の鍵管理装置が、前記第６の工程で前記第２の鍵管理装置から受信した前記データを前記第１の鍵データを基に復号し、当該復号したデータを、前記第５の工程で取得した前記新たな鍵データである第２の鍵データを基に暗号化して、当該第１の鍵管理装置に割り当てられた前記受信装置に送信する第７の工程と
をさらに有する請求項１に記載のデータ処理方法。
【請求項５】
前記第１の工程において、前記第２の鍵管理装置が、予め決められた複数の鍵取得方法のうち、前記第１の鍵管理装置を無効にするために生じる当該第２の鍵管理装置と無効にしない前記他の第１の鍵管理装置との間の通信量が最少となる前記鍵取得方法を選択し、当該選択した前記鍵取得方法を基に、前記新たな前記鍵データを取得する
請求項１に記載のデータ処理方法。
【請求項６】
前記第１の工程において、前記第２の鍵管理装置が、当該第２の鍵管理装置が対応付けられたルートから分岐した最終端のノードであるリーフに前記複数の第１の鍵管理装置の各々が対応付けられ、前記ルートと前記リーフとの間に複数のレイヤが規定されたツリーと、前記複数のレイヤのうち少なくとも２つの前記レイヤに対して相互に異なるアルゴリズムを適用した前記鍵取得方法とを基に、前記無効にする前記第１の鍵管理装置が対応付けられた前記リーフに応じて、前記ツリー内の前記ノードに割り当てられたデータのうち前記新たな鍵データを取得するために用いるデータを特定する
請求項１に記載のデータ処理方法。
【請求項７】
前記異なるアルゴリズムとして、
処理対象の前記レイヤ内のサブツリーのうち当該サブツリー内あるいはその分岐先に無効にする前記第１の鍵管理装置が対応付けられているサブツリーについて、当該サブツリー内の最終端のノードのうち、当該最終端のノードあるいはその分岐先に無効にする前記第１の鍵管理装置が対応付けられていないノードのみを要素とする集合に割り当てられた第１のデータを基に、前記新たな鍵データを取得する第１の方法と、
処理対象のレイヤのノードのなかで、分岐先に前記無効にする第１の鍵管理装置に対応付けられたリーフがないノードで、かつ最も前記ルートに近いノードに割り当てられた第２のデータを、前記新たな鍵データとする第２の方法と
を用いる請求項６に記載のデータ処理方法。
【請求項８】
前記複数の鍵取得方法は、
前記ツリーの前記最終端のノードを含む第１のレイヤに対して前記第１の方法を採用し、前記ルートを含む第２のレイヤに対して前記第２の方法を採用する第１の鍵取得方法と、
前記ツリーの前記最終端のノードを含む第３のレイヤに対して前記第１の方法を採用し、前記第３のレイヤに対して前記ルート側に規定された第４のレイヤに対して前記第１の方法を採用し、前記ルートを含む第５のレイヤに対して前記第２の方法を採用する第２の鍵取得方法と
を少なくとも有する請求項７に記載のデータ処理方法。
【請求項９】
前記第２の鍵管理装置が、前記第１の工程で前記選択した前記鍵取得方法と、当該選択した鍵取得方法に用いるデータとを指定した指定データを、無効にしない前記第１の鍵管理装置に送信する第７の工程
をさらに有する請求項５に記載のデータ処理方法。
【請求項１０】
前記第２の鍵管理装置が、第１の鍵データを基に暗号化したデータを前記複数の第１の鍵管理装置にマルチキャストあるいは放送する第８の工程と、
前記第１の鍵管理装置が、前記第８の工程で前記第２の鍵管理装置から受信したデータを、前記第１の鍵データを基に復号し、当該復号したデータを第２の鍵データを基に暗号化する第９の工程と、
前記第１の鍵管理装置が、前記第９の工程で暗号化したデータを、当該第１の鍵管理装置が管理する複数の前記受信装置にマルチキャストあるいは放送する第１０の工程と、
前記受信装置が、前記第１０の工程で前記第１の鍵管理装置から受信したデータを、前記第２の鍵データを基に復号する第１１の工程と
をさらに有する請求項１に記載のデータ処理方法。
【請求項１１】
複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の鍵管理装置を管理するデータ処理装置によって実行されるプログラムであって、
前記複数の鍵管理装置のうち無効にする前記鍵管理装置を除く他の前記鍵管理装置との間の前記暗号化通信に用いる新たな前記鍵データを取得する第１の手順と、
前記他の鍵管理装置が予め保持し前記無効にする鍵管理装置が保持しないデータのうち、前記第１の手順で取得した前記新たな鍵データを当該他の鍵管理装置が取得するために用いるデータを当該他の第１の鍵管理装置に指定する第２の手順と
を有するプログラム。
【請求項１２】
複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の鍵管理装置を管理するデータ処理装置であって、
前記複数の鍵管理装置のうち無効にする前記鍵管理装置を除く他の前記鍵管理装置との間の前記暗号化通信に用いる新たな前記鍵データを取得する第１の手段と、
前記他の鍵管理装置が予め保持し前記無効にする鍵管理装置が保持しないデータのうち、前記第１の工程で取得した前記新たな鍵データを当該他の鍵管理装置が取得するために用いるデータを当該他の鍵管理装置に指定する第２の手段と
を有するデータ処理装置。
【請求項１３】
複数の受信装置との間の暗号化通信に用いる鍵データを管理するデータ処理装置が実行するプログラムであって、
鍵データを取得するために用いるデータの指定を鍵管理装置から受ける第１の手順と、
前記第１の手順で前記鍵管理装置から受けた前記指定に応じたデータを予め保持しているデータのなかから特定し、当該特定したデータを基に、前記鍵管理装置との暗号化通信に用いる新たな鍵データを取得する第２の手順と
を有するプログラム。
【請求項１４】
複数の受信装置との間の暗号化通信に用いる鍵データを管理するデータ処理装置であって、
複数の鍵データを生成するために用いるデータを記憶する記憶手段と、
鍵データを取得するために用いるデータの指定を鍵管理装置から受ける通信手段と、
前記通信手段が受けた前記指定に応じたデータを記憶手段から読み出し、当該読み出したデータを基に、前記鍵管理装置との暗号化通信に用いる新たな鍵データを取得する処理手段と
を有するデータ処理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、セキュア通信を行うデータ処理方法、そのプログラムとその装置に関する。
【０００２】
【従来の技術】
例えば、メインサーバが、予め登録した複数の受信装置にマルチキャストなどで暗号化データを送信する通信システムがある。
このような通信システムでは、既に登録済みの受信装置を無効に（リボーク）する場合に、例えば、下記非特許文献１や下記非特許文献２などに開示されているリボケーション処理を行う。当該リボケーション処理は、リボークしない受信装置に新たな鍵データを効率的に取得させる処理である。
上述した通信システムでは、例えば、メインサーバが登録された複数の受信装置を複数のサブグループに割り当て、複数のサブグループの各々における鍵管理を各サブグループに割り当てたサブサーバで実現している。
当該通信システムは、各サブサーバが、自らに割り当てられたサブグループ内の受信装置をリボークする処理（リボケーション処理）を個別に行うため、当該リボケーション処理が他のサブグループに影響しないという利点がある。
【０００３】
【非特許文献１】
Ｄ．Ｈａｌｅｖｙ  ａｎｄ  Ａ  Ｓｈａｍｉｒ，  ”Ｔｈｅ  ＬＣＤ  ｂｒｏａｄｃａｓｔ  ｅｎｃｒｙｐｔｉｏｎ  ｓｃｈｅｍｅ”，  ＣＲＹＰＴＯ  ２００２，  Ｌｅｃｔｕｒｅ  Ｎｏｔｅｓ  ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｓｃｉｅｎｃｅ，ｖｏｌ．２４４２．  ｐｐ．４７−６０，２００２
【非特許文献２】
Ｄ．Ｎａｏｒ，Ｍ．Ｎａｏｒ  ａｎｄ  Ｊ．Ｌｏｔｓｐｉｅｃｈ，”Ｒｅｖｏｃａｔｉｏｎ  ａｎｄ  ｔｒａｃｉｎｇ  ｓｃｈｅｍｅｓ  ｆｏｒ  ｓｔａｔｅｌｅｓｓ  ｒｅｃｅｉｖｅｒｓ”，  ＣＲＹＰＴＯ  ２００１．Ｌｅｃｔｕｒｅ  Ｎｏｔｅｓ  ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｓｃｉｅｎｃｅ．ｖｏｌ  ２１３９．ｐｐ．４１−６２，２００１．
【０００４】
【発明が解決しようとする課題】
ところで、上述した従来の通信システムでは、メインサーバと複数のサブサーバとの間の暗号化通信に、全てのサブサーバに共通の鍵データが用いられている。
そのため、複数のサブサーバのうち少なくとも一つのサブサーバをリボークする場合には、他のリボークしないサブグループのみが共用する新たな鍵データを、メインサーバとリボークされないサブサーバとが取得する必要がある。
しかしながら、上述した従来の通信システムでは、サブサーバが上記新たな鍵データを独自に取得するためのデータを予め保持していないため、リボークされないサブサーバは、上記新たな鍵データを独自に生成できないという問題がある。また、メインサーバが、新たな鍵データを古い鍵データを基に暗号化して送信すると、その内容を、リボークされるサブサーバが取得できてしまい、セキュリティ上問題がある。
そのため、通信システム全体を再構築する必要があり、その負担が大きいという問題がある。
【０００５】
本発明はかかる事情に鑑みてなされたものであり、第１の発明は、複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の第１の鍵管理装置と、当該複数の第１の鍵管理装置を管理する第２の鍵管理装置とを用いて通信を行う場合に、一部の前記第１の鍵管理装置を効率的に無効にできるデータ処理方法を提供することを目的とする。
また、第２および第３の発明は、複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の鍵管理装置のうち、一部の鍵管理装置を効率的に無効にできるプログラムおよびデータ処理装置を提供することを目的とする。
また、第４および第５の発明は、第２および第３の発明における上記鍵管理装置に対応したプログラムおよびデータ処理装置を提供することを目的とする。
【０００６】
【課題を解決するための手段】
上述した目的を達成するために、第１の発明のデータ処理方法は、複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の第１の鍵管理装置と、当該複数の第１の鍵管理装置を管理する第２の鍵管理装置とを用いて行うデータ処理方法であって、前記複数の第１の鍵管理装置のうち無効にする前記第１の鍵管理装置を除く他の前記第１の鍵管理装置との間の前記暗号化通信に用いる新たな前記鍵データを前記第２の鍵管理装置が取得する第１の工程と、前記他の第１の鍵管理装置が予め保持し前記無効にする第１の鍵管理装置が保持しないデータのうち、前記第１の工程で取得した前記新たな鍵データを当該他の第１の鍵管理装置が取得するために用いるデータを前記第２の鍵管理装置が当該他の第１の鍵管理装置に指定する第２の工程とを有する。
【０００７】
第１の発明のデータ処理方法の作用は以下のようになる。
先ず、第１の工程において、前記複数の第１の鍵管理装置のうち無効にする前記第１の鍵管理装置を除く他の前記第１の鍵管理装置との間の前記暗号化通信に用いる新たな前記鍵データを前記第２の鍵管理装置が取得する。
次に、第２の工程において、前記他の第１の鍵管理装置が予め保持し前記無効にする第１の鍵管理装置が保持しないデータのうち、前記第１の工程で取得した前記新たな鍵データを当該他の第１の鍵管理装置が取得するために用いるデータを前記第２の鍵管理装置が当該他の第１の鍵管理装置に指定する。
【０００８】
第２の発明のプログラムは、複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の鍵管理装置を管理するデータ処理装置によって実行されるプログラムであって、前記複数の鍵管理装置のうち無効にする前記鍵管理装置を除く他の前記鍵管理装置との間の前記暗号化通信に用いる新たな前記鍵データを取得する第１の手順と、前記他の鍵管理装置が予め保持し前記無効にする鍵管理装置が保持しないデータのうち、前記第１の手順で取得した前記新たな鍵データを当該他の鍵管理装置が取得するために用いるデータを当該他の第１の鍵管理装置に指定する第２の手順とを有する。
【０００９】
第３の発明のデータ処理装置は、複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の鍵管理装置を管理するデータ処理装置であって、前記複数の鍵管理装置のうち無効にする前記鍵管理装置を除く他の前記鍵管理装置との間の前記暗号化通信に用いる新たな前記鍵データを取得する第１の手段と、前記他の鍵管理装置が予め保持し前記無効にする鍵管理装置が保持しないデータのうち、前記第１の工程で取得した前記新たな鍵データを当該他の鍵管理装置が取得するために用いるデータを当該他の鍵管理装置に指定する第２の手段とを有する。
【００１０】
第３の発明のデータ処理装置の作用は以下のようになる。
先ず、第１の手段が、前記複数の鍵管理装置のうち無効にする前記鍵管理装置を除く他の前記鍵管理装置との間の前記暗号化通信に用いる新たな前記鍵データを取得する。
次に、第２の手段が、前記他の鍵管理装置が予め保持し前記無効にする鍵管理装置が保持しないデータのうち、前記第１の工程で取得した前記新たな鍵データを当該他の鍵管理装置が取得するために用いるデータを当該他の鍵管理装置に指定する。
【００１１】
第４の発明のプログラムは、複数の受信装置との間の暗号化通信に用いる鍵データを管理するデータ処理装置が実行するプログラムであって、鍵データを取得するために用いるデータの指定を鍵管理装置から受ける第１の手順と、前記第１の手順で前記鍵管理装置から受けた前記指定に応じたデータを予め保持しているデータのなかから特定し、当該特定したデータを基に、前記鍵管理装置との暗号化通信に用いる新たな鍵データを取得する第２の手順とを有する。
【００１２】
第５の発明のデータ処理装置は、複数の受信装置との間の暗号化通信に用いる鍵データを管理するデータ処理装置であって、複数の鍵データを生成するために用いるデータを記憶する記憶手段と、鍵データを取得するために用いるデータの指定を鍵管理装置から受ける通信手段と、前記通信手段が受けた前記指定に応じたデータを記憶手段から読み出し、当該読み出したデータを基に、前記鍵管理装置との暗号化通信に用いる新たな鍵データを取得する処理手段とを有する。
【００１３】
第５の発明のデータ処理装置の作用は以下のようになる。
先ず、通信手段が、鍵データを取得するために用いるデータの指定を鍵管理装置から受ける。
次に、処理手段が、前記通信手段が受けた前記指定に応じたデータを記憶手段から読み出し、当該読み出したデータを基に、前記鍵管理装置との暗号化通信に用いる新たな鍵データを取得する。
【００１４】
【発明の実施の形態】
以下、本発明の実施形態に係わる通信システムについて説明する。
図１は本発明の実施形態に係わる通信システム１の全体構成図、図２は図１に示すサブグループに属する受信装置を説明するための図である。
図１および図２に示すように、通信システム１は、例えば、メインサーバ２、複数（Ｐ個）のサブサーバ３＿ｐ（ｐは１〜Ｐの整数）と、Ｐ個のサブグループＳＵＢＧ＿ｐの各々に属するＮｐ個の受信装置４＿ｐ（ｎ）（ｎは１〜Ｎｐの整数）とを有する。
Ｎｐは、サブグループＳＵＢＧ＿ｐに属する受信装置の数を示す。
ここで、メインサーバ２が、第１の発明の第２の鍵管理装置、第２および第３の発明のデータ処理装置、並びに第４および第５の発明の鍵管理装置に対応している。
また、サブサーバ３＿ｐが、第１の発明の第１の鍵管理装置、第２および第３の発明の鍵管理装置、並びに第４および第５の発明のデータ処理装置に対応している。
また、受信装置４＿ｐ（ｎ）が本発明の受信装置に対応している。
【００１５】
メインサーバ２は、サブサーバ３＿ｐを予め登録して管理する。
メインサーバ２およびサブサーバ３＿ｐは、互いに暗号化通信を行うための鍵データＫ＿ＯＲＧ１とラベルデータＬＡＢＥＬ１とを保持している。
また、サブサーバ３＿ｐおよび受信装置４＿ｐ（ｎ）は、互いに暗号化通信を行うための鍵データＫ＿ＯＲＧ２とラベルデータＬＡＢＥＬ２とを保持している。
【００１６】
以下、図１および図２に示す通信システム１の概要を説明する。
通信システム１は、暗号化したペイロードデータを、サブサーバ３＿ｐを介して、受信装置４＿ｐ（ｎ）にマルチキャスト（暗号化通信）する。
メインサーバ２は、サブサーバ３＿ｐとの間の暗号化通信に用いるセッション鍵データＳＥＫ、並びに当該セッション鍵データＳＥＫを暗号化するために用いる鍵暗号鍵データＫＥＫ（本発明の新たな鍵データ）などを管理する。
また、サブサーバ３＿ｐは、受信装置４＿ｐ（ｎ）との間の暗号化通信に用いるセッション鍵データＳＥＫ、並びに当該セッション鍵データＳＥＫを暗号化するために用いる鍵暗号鍵データＫＥＫなどを管理する。
【００１７】
通信システム１では、メインサーバ２がサブサーバ３＿ｐをリボーク（無効に）する場合に、Ｐ個のサブサーバ３＿ｐのうち、リボークするサブサーバ３＿ｐを除く他のサブサーバ３＿ｐとの間の上記暗号化通信に用いる新たな鍵暗号鍵データＫＥＫを後述するＲＬＫＨ方式（Ｒｅｃｏｎｆｉｇｕｒａｂｌｅ  Ｌｏｇｉｃａｌ  Ｋｅｙ  Ｈｉｅｒａｒｃｈｙ）を基に取得する。
そして、メインサーバ２が、リボークしないサブサーバ３＿ｐに予め設定されリボークするサブサーバ３＿ｐに設定されていない鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬのうち、上記新たな鍵暗号鍵データＫＥＫを取得するために用いるデータを、リボークしないサブサーバ３＿ｐに指定する。
これにより、リボークしないサブサーバ３＿ｐは、メインサーバ２から指定されたデータを用いて、鍵取得方法ＲＬＫＨを基に上記鍵暗号鍵データＫＥＫを取得する。
そして、メインサーバ２が、リボークしないサブサーバ３＿ｐに、上記取得した鍵暗号鍵データＫＥＫで暗号化した新たなセッション鍵データＳＥＫを提供する。
リボークしないサブサーバ３＿ｐは、上記取得した鍵暗号鍵データＫＥＫを基に、メインサーバ２から受けた新たなセッション鍵データＳＥＫを復号する。
以後、メインサーバ２とリボークされていないサブサーバ３＿ｐとの間の暗号化通信に、上記新たなセッション鍵データＳＥＫを用いる。
なお、サブサーバ３＿ｐは、メインサーバ２からの指示に応じて、鍵取得方法ＲＬＫＨを基に、自らが管理する受信装置４＿ｐ（ｎ）のリボケーション処理を行う。
【００１８】
先ず、メインサーバ２、サブサーバ３＿１〜３＿Ｐおよび受信装置４＿ｐ（ｎ）のハードウェア構成について説明する。
〔メインサーバ２〕
図３は、図１に示すメインサーバ２のハードウェア構成図である。
図３に示すように、メインサーバ２は、例えば、通信部１１、メモリ１２および処理部１３を有する。
通信部１１は、サブサーバ３＿ｐに所定の暗号データを送信する。
メモリ１２は、処理部１３によって実行されるプログラムＰＲＧ１と、プログラムＰＲＧ１の実行に用いられる種々データを記憶する。
メモリ１２は、後述するサブサーバ３＿ｐのリボケーション処理に必要な鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬ１を記憶する。
なお、メモリ１２は、鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬ１の一部または全てを記憶せず、これらを基にリボケーション処理により最終的に取得される鍵暗号鍵データＫＥＫを記憶してもよい。
処理部１３は、メモリ１２に記憶されたプログラムＰＲＧ１を実行し、その実行に応じてメインサーバ２の処理を統括して制御する。本実施形態において、後述するメインサーバ２の処理は、処理部１３が実行するプログラムＰＲＧ１によって規定される。
【００１９】
〔サブサーバ３＿ｐ〕
図４は、図１に示すサブサーバ３＿ｐのハードウェア構成図である。
図４に示すように、サブサーバ３＿ｐは、例えば、通信部２１、メモリ２２および処理部２３を有する。
ここで、通信部２１が第５の発明の通信手段に対応し、メモリ２２が第５の発明の記憶手段に対応し、処理部２３が第５の発明の処理手段に対応している。
通信部２１は、メインサーバ２から所定の暗号データを受信する。
通信部２１は、受信装置４＿ｐ（ｎ）に所定の暗号データを送信する。
メモリ２２は、処理部２３によって実行されるプログラムＰＲＧ２と、プログラムＰＲＧ２の実行に用いられる種々データを記憶する。
メモリ２２は、後述するメインサーバ２によるリボケーション処理に必要な鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬ１を記憶する。
なお、メモリ２２は、鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬ１の一部または全てを記憶せず、これらを基にリボケーション処理により最終的に取得される鍵暗号鍵データＫＥＫを記憶してもよい。
また、メモリ２２は、後述する受信装置４＿ｐ（ｎ）のリボケーション処理に必要な鍵データＫ＿ＯＲＧ２およびラベルデータＬＡＢＥＬ２を記憶する。
なお、メモリ２２は、鍵データＫ＿ＯＲＧ２およびラベルデータＬＡＢＥＬ２の一部または全てを記憶せず、これらを基にリボケーション処理により最終的に取得される鍵暗号鍵データＫＥＫを記憶してもよい。
処理部２３は、メモリ２２に記憶されたプログラムＰＲＧ２を実行し、その実行に応じてサブサーバ３＿ｐの処理を統括して制御する。本実施形態において、後述するサブサーバ３＿ｐの処理は、処理部２３が実行するプログラムＰＲＧ２によって規定される。
【００２０】
〔受信装置４＿ｐ（ｎ）〕
図５は、図２に示す受信装置４＿ｐ（ｎ）のハードウェア構成図である。
図５に示すように、受信装置４＿ｐ（ｎ）は、例えば、通信部３１、メモリ３２および処理部３３を有する。
通信部３１は、サブサーバ３＿ｐから所定の暗号データを受信する。
メモリ３２は、処理部３３によって実行されるプログラムＰＲＧ３と、プログラムＰＲＧ３の実行に用いられる種々データを記憶する。
メモリ３２は、後述するサブサーバ３＿ｐによるリボケーション処理に必要な鍵データＫ＿ＯＲＧ２およびラベルデータＬＡＢＥＬ２を記憶する。
なお、メモリ３２は、鍵データＫ＿ＯＲＧ２およびラベルデータＬＡＢＥＬ２の一部または全てを記憶せず、これらを基にリボケーション処理により最終的に取得される鍵暗号鍵データＫＥＫを記憶してもよい。
処理部３３は、メモリ３２に記憶されたプログラムＰＲＧ３を実行し、その実行に応じて受信装置４＿ｐ（ｎ）の処理を統括して制御する。本実施形態において、後述する受信装置４＿ｐ（ｎ）の処理は、処理部３３が実行するプログラムＰＲＧ３によって規定される。
【００２１】
以下、通信システム１で行われる各種の処理を説明する。
〔メインサーバ２によるサブサーバ３＿ｐのリボケーション処理〕
図６は、メインサーバ２によるサブサーバ３＿ｐのリボケーション処理を説明するためのフローチャートである。
図６において、ステップＳＴ２が第１の発明の第１の工程および第２の発明の第１の手順に対応し、ステップＳＴ３が第１の発明の第２の工程および第２の発明の第２の手順に対応している。
また、第３の発明の第１の手段はメインサーバ２の処理部１３がステップＳＴ２を実行して実現され、第３の発明の第２の手段は処理部１３がステップＳＴ３を実行して実現される。
また、ステップＳＴ４が第１の発明の３の工程、並びに第４の発明の第２の手順に対応している。
【００２２】
ステップＳＴ１：
メインサーバ２は、リボークするサブサーバ３＿ｐを特定する。
ステップＳＴ２：
メインサーバ２は、ステップＳＴ１で特定したサブサーバ３＿ｐ、並びに後述する鍵取得方法ＲＬＫＨを基に、リボークしないサブサーバ３＿ｐとの間で用いる鍵暗号鍵データＫＥＫを取得（特定）する。
【００２３】
ステップＳＴ３：
メインサーバ２は、ステップＳＴ２で取得した鍵暗号鍵データＫＥＫを、リボークしないサブサーバ３＿ｐに取得させるために用いるデータ（鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬ）を指定した指定データを生成する。
また、メインサーバ２は、新たなセッション鍵データＳＥＫを、上記新たな鍵暗号鍵データＫＥＫで暗号化する。
そして、メインサーバ２は、上記指定データと、上記暗号化したセッション鍵データＳＥＫとを、リボークしないサブサーバ３＿ｐに送信する。
ステップＳＴ４：
リボークされないサブサーバ３＿ｐは、ステップＳＴ３で受信した上記指定データと上記鍵取得方法ＲＬＫＨとを基に、新たな鍵暗号鍵データＫＥＫを取得する。
そして、当該サブサーバ３＿ｐは、上記取得した新たな鍵暗号鍵データＫＥＫを用いて、メインサーバ２から受信した新たなセッション鍵データＳＥＫを復号する。当該サブサーバ３＿ｐは、以後、当該新たなセッション鍵データＳＥＫを基にメインサーバ２と暗号化通信を行う。
一方、リボークされるサブサーバ３＿ｐは、有効な上記指定データを得られないため、上記新たなセッション鍵データＳＥＫを得られない。
【００２４】
なお、メインサーバ２は、新たなサブサーバ３＿ｐを加入させる場合に、当該新たなサブサーバ３＿ｐに受信装置４＿ｐ（ｎ）を割り当てると共に、メインサーバ２との間の暗号化通知に用いる鍵データを当該サブサーバ３＿ｐに設定する。
【００２５】
〔サブサーバ３＿ｐによる受信装置４＿ｐ（ｎ）のリボケーション処理〕
受信装置４＿ｐ（ｎ）からの加入解除要求に応じて、メインサーバ２からの指示によってサブサーバ３＿ｐが受信装置４＿ｐ（ｎ）のリボケーション処理を行う。
図７および図８は、サブサーバ３＿ｐによる受信装置４＿ｐ（ｎ）のリボケーション処理を説明するためのフローチャートである。
ステップＳＴ１１：
ユーザによる受信装置４＿ｐ（ｎ）の操作に応じて、受信装置４＿ｐ（ｎ）がメインサーバ２に加入解除要求を送信する。
ステップＳＴ１２：
ステップＳＴ１１の加入解除要求に応じて、メインサーバ２と当該受信装置４＿ｐ（ｎ）とが相互認証を行い、互いの正当性を確認すると、ステップＳＴ１３に進む。
【００２６】
ステップＳＴ１３：
メインサーバ２が、加入解除要求元の受信装置４＿ｐ（ｎ）に、加入解除内容の選択要求を送信する。
ステップＳＴ１４：
受信装置４＿ｐ（ｎ）は、ステップＳＴ１３で受信した選択要求に応じて、加入解除内容を選択する。
ステップＳＴ１５：
メインサーバ２は、ステップＳＴ１４で選択された加入解除内容に応じて、当該受信装置４＿ｐ（ｎ）との間の加入契約を停止あるいは終了する。
ステップＳＴ１６：
メインサーバ２は、ステップＳＴ１５で契約を停止あるいは終了した受信装置４＿ｐ（ｎ）を管理するサブサーバ３＿ｐに対して、当該受信装置４＿ｐ（ｎ）を指定した加入解除指示を送信する。
ステップＳＴ１７：
サブサーバ３＿ｐは、ステップＳＴ１６で受信した加入解除指示に応じて、当該加入解除指示が指定する受信装置４＿ｐ（ｎ）のリボークを行う。
すなわち、サブサーバ３＿ｐは、後述する鍵取得方法ＲＬＫＨを基に、リボークしない受信装置４＿ｐ（ｎ）との間で用いる鍵暗号鍵データＫＥＫを取得（特定）する。
【００２７】
ステップＳＴ１８：
サブサーバ３＿ｐは、ステップＳＴ１７で取得した鍵暗号鍵データＫＥＫを、サブグループＳＵＢＧ＿ｐ内のリボークしない受信装置４＿ｐ（ｎ）に取得させるために用いるデータ（鍵データＫ＿ＯＲＧ２およびラベルデータＬＡＢＥＬ）を指定した指定データを生成する。
また、サブサーバ３＿ｐは、新たなセッション鍵データＳＥＫを、上記新たな鍵暗号鍵データＫＥＫで暗号化する。
そして、サブサーバ３＿ｐは、上記指定データと、上記暗号化したセッション鍵データＳＥＫとを、リボークしない受信装置４＿ｐ（ｎ）に送信する。
ステップＳＴ１９：
リボークされない受信装置４＿ｐ（ｎ）は、ステップＳＴ１８で受信した上記指定データと鍵取得方法ＲＬＫＨとを基に、新たな鍵暗号鍵データＫＥＫを取得する。
そして、当該受信装置４＿ｐ（ｎ）は、上記取得した新たな鍵暗号鍵データＫＥＫを用いて、サブサーバ３＿ｐから受信した新たなセッション鍵データＳＥＫを復号する。当該受信装置４＿ｐ（ｎ）は、以後、当該新たなセッション鍵データＳＥＫを基にサブサーバ３＿ｐと暗号化通信を行う。
一方、リボークされる受信装置４＿ｐ（ｎ）は、有効な上記指定データを得られないため、上記新たなセッション鍵データＳＥＫを得られない。
【００２８】
なお、上述した図７および図８に示す場合では、受信装置４＿ｐ（ｎ）からの要求に応じてサブサーバ３＿ｐが加入解除処理を行う場合を例示したが、サブサーバ３＿ｐが不適切なユーザの受信装置４＿ｐ（ｎ）を強制的に加入解除してもよい。この場合には、サブサーバ３＿ｐは、受信装置４＿ｐ（ｎ）からの加入解除要求を受けなくても、図７に示すステップＳＴ１５以降の処理、並びに図８に示す各ステップの処理を行う。
【００２９】
〔メインサーバ２による受信装置４＿ｐ（ｎ）の加入処理〕
図９および図１０は、メインサーバ２による受信装置４＿ｐ（ｎ）の加入処理を説明するためフローチャートである。
ステップＳＴ３１：
ユーザによる受信装置４＿ｐ（ｎ）の操作に応じて、受信装置４＿ｐ（ｎ）がメインサーバ２に加入要求を送信する。
ステップＳＴ３２：
ステップＳＴ３１の加入要求に応じて、メインサーバ２と当該受信装置４＿ｐ（ｎ）とが相互認証を行い、互いの正当性を確認すると、ステップＳＴ３３に進む。
【００３０】
ステップＳＴ３３：
メインサーバ２が、加入解除要求元の受信装置４＿ｐ（ｎ）に、加入契約内容の選択要求を送信する。
ステップＳＴ３４：
受信装置４＿ｐ（ｎ）は、ステップＳＴ３３で受信した選択要求に応じて、加入契約内容を選択する。
ステップＳＴ３５：
メインサーバ２は、ステップＳＴ３４で選択された加入契約内容に応じて、当該受信装置４＿ｐ（ｎ）との間の加入契約を行う。
【００３１】
ステップＳＴ３６：
メインサーバ２は、当該受信装置４＿ｐ（ｎ）を何れのサブサーバ３＿ｐの管理に割り当てるかを決定する。
ステップＳＴ３７：
メインサーバ２は、受信装置４＿ｐ（ｎ）の割り当て先のサブサーバ３＿ｐの指定と、メインサーバ２の証明内容とを含む証明書データを生成し、これを当該受信装置４＿ｐ（ｎ）に送信する。
ステップＳＴ３８：
メインサーバ２は、新規に加入する受信装置４＿ｐ（ｎ）を指定した加入処理要求を、ステップＳＴ３６で決定した割り当て先のサブサーバ３＿ｐに送信する。
【００３２】
ステップＳＴ３９：
サブサーバ３＿ｐは、ステップＳＴ３８で受信した加入処理要求に応じて、サブグループＳＵＢＧ＿ｐに既に属している受信装置４＿ｐ（ｎ）と、新たに加入する受信装置４＿ｐ（ｎ）とを含む新たなサブグループＳＵＢＧ＿    ｐについて、鍵取得方法ＲＬＫＨに用いる鍵データＫ＿ＯＲＧ２とラベルデータＬＡＢＥＬ２とを特定する。
スップＳＴ４０：
サブサーバ３＿ｐは、ステップＳＴ３９で特定した全ての鍵データＫ＿ＯＲＧ２とラベルデータＬＡＢＥＬ２とを、新規に加入する受信装置４＿ｐ（ｎ）に設定する。
また、サブサーバ３＿ｐは、ステップＳＴ３９で特定した鍵データＫ＿ＯＲＧ２およびラベルデータＬＡＢＥＬ２のうち、既に加入している受信装置４＿ｐ（ｎ）が保持していないものを、当該受信装置４＿ｐ（ｎ）に設定する。
【００３３】
〔メインサーバ２から受信装置４＿ｐ（ｎ）へのマルチキャスト〕
図１１は、メインサーバ２から受信装置４＿ｐ（ｎ）へのマルチキャスト処理を説明するためのフローチャートである。
ステップＳＴ５１：
メインサーバ２は、サブサーバ３＿ｐとの間で規定したセッション鍵データＳＥＫ１を用いて、ペイロードデータを暗号化する。
ステップＳＴ５２：
メインサーバ２は、ステップＳＴ５１で暗号化したペイロードデータを、サブサーバ３＿ｐにマルチキャストする。
ステップＳＴ５３：
サブサーバ３＿ｐは、ステップＳＴ５２で受信したペイロードデータを、上記サブサーバ３＿ｐとの間で規定したセッション鍵データＳＥＫ１を用いて復号する。
【００３４】
ステップＳＴ５４：
サブサーバ３＿ｐは、受信装置４＿ｐ（ｎ）との間で規定したセッション鍵データＳＥＫ２を用いて、ステップＳＴ５３で復号したペイロードデータを暗号化する。
ステップＳＴ５５：
サブサーバ３＿ｐは、ステップＳＴ５４で暗号化したペイロードデータを、受信装置４＿ｐ（ｎ）にマルチキャストする。
ステップＳＴ５６：
受信装置４＿ｐ（ｎ）は、ステップＳＴ５５で受信したペイロードデータを、上記サブサーバ３＿ｐとの間で規定したセッション鍵データＳＥＫ２（セッション鍵データＳＥＫ１とは異なる）を用いて復号する。
【００３５】
なお、上述した処理のうち、図７に示すＳＴ１１〜ＳＴ１４，図９に示すＳＴ３１〜ＳＴ３４，ＳＴ３７，図１０に示すＳＴ４０などのデータ授受は、例えば、ピア・ツー・ピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）方式で行われる。
【００３６】
以下、上述した本実施形態の鍵取得方法ＲＬＫＨについて説明する。
本実施形態では、上述したように、メインサーバ２によるサブサーバ３＿ｐのリボケーション処理、並びにサブサーバ３＿ｐによる受信装置４＿ｐ（ｎ）のリボケーション処理は、鍵取得方法ＲＬＫＨを基に行われる。
メインサーバ２がサブサーバ３＿ｐをリボークする場合には、図６を用いて前述したように、メインサーバ２とリボークしないサブサーバ３＿ｐとが鍵取得方法ＲＬＫＨにより新たな鍵暗号鍵データＫＥＫを取得し、メインサーバ２からリボークしないサブサーバ３＿ｐに新たなセッション鍵データＳＥＫを上記新たな鍵暗号鍵データＫＥＫで暗号化して送信する。
また、サブサーバ３＿ｐが受信装置４＿ｐ（ｎ）をリボークする場合には、図８を用いて前述したように、サブサーバ３＿ｐとリボークしない受信装置４＿ｐ（ｎ）とが鍵取得方法ＲＬＫＨにより新たな鍵暗号鍵データＫＥＫを取得し、サブサーバ３＿ｐからリボークしない受信装置４＿ｐ（ｎ）に新たなセッション鍵データＳＥＫを上記新たな鍵暗号鍵データＫＥＫで暗号化して送信する。
【００３７】
以下、メインサーバ２によるサブサーバ３＿ｐのリボケーション処理について説明する。
なお、サブサーバ３＿ｐによる受信装置４＿ｐ（ｎ）のリボケーション処理は、以下に示すメインサーバ２の処理をサブサーバ３＿ｐが行い、以下に示すサブサーバ３＿ｐの処理を受信装置４＿ｐ（ｎ）が行うことで実現される。この場合に、以下に示す鍵データＫ＿ＯＲＧ１の代わりに鍵データＫ＿ＯＲＧ２が用いられ、ラベルデータＬＡＢＥＬ１の代わりにラベルデータＬＡＢＥＬ２が用いられる。
【００３８】
図３に示すメインサーバ２の処理部１３は、プログラムＰＲＧ１の実行に応じて、サブサーバ３＿ｐへの鍵データＫ＿ＯＲＧ１やラベルデータＬＡＢＥＬ１の配信などの前処理、並びに、セッション鍵データの更新処理などのリボケーション処理などのセキュリティ処理を行う。
【００３９】
処理部１３は、上記リボケーション処理に先立って、例えば、サブサーバ３＿ｐの登録時などに、上記前処理を行う。
処理部１３は、上記前処理において、上記リボケーション処理を行うに当たって採用される鍵取得方法ＳＫＴ−Ａ，ＳＫＴ−Ｂ（ｕｎｄｅｒｌｙｉｎｇ  ｓｔｒｕｃｔｕｒｅ）  、並びに当該鍵取得方法ＳＫＴ−Ａ，ＳＫＴ−Ｂで使用する鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬ１をサブサーバ３＿ｐに設定する。
【００４０】
処理部１３は、サブサーバ３＿ｐのうち何れかをリボーク（無効に）する場合に、上記リボケーション処理を行う。
処理部１３は、リボケーション処理において、サブサーバ３＿ｐの何れをリボークするかに応じて、リボークしないサブサーバ３＿ｐに対してセッション鍵データＳＥＫを送信するための鍵暗号鍵データＫＥＫを選択する。
そして、処理部１３は、リボークしないサブサーバ３＿ｐが、鍵暗号鍵データＫＥＫを生成するための指定データを、リボークしないサブサーバ３＿ｐに送信する。
【００４１】
上記鍵取得方法ＳＫＴ−Ａ，ＳＫＴ−Ｂは、本実施形態では、以下に示すように、前述した非特許文献１に開示されているＬＳＤ方式や非特許文献２に開示されているＣＳＴ方式などのリボケーション方式を基に規定され、例えば、複数の２分ツリーを左右対称に組み合わせたツリーを構成するサブツリーであるセクション毎に個別にリボケーション方式を規定したものであるＳＫＴ（Ｓｅｃｔｉｏｎｅｄ  Ｋｅｙ  Ｔｒｅｅｓ）  の一例である。
処理部１３が採用する鍵取得方法ＳＫＴ−Ａ，ＳＫＴ−Ｂに関する情報、並びに当該鍵取得方法で用いられる鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬ１は、上記前処理によってサブサーバ３＿ｐに提供される。
【００４２】
通信システム１では、メインサーバ２が、予め決められた複数の鍵取得方法（例えば、後述する鍵取得方法ＳＫＴ−Ａ，ＳＫＴ−Ｂなど）のうち、所定のサブサーバ３＿ｐをリボーク（無効に）するために生じる、リボークにしないサブサーバ３＿ｐとの間の通信量が最少となる鍵取得方法を選択する。そして、メインサーバ２が当該選択した鍵取得方法を基に新たな鍵暗号鍵データＫＥＫを取得する。
【００４３】
以下、本実施形態の鍵取得方法ＳＫＴについて説明する。
上記ツリーでは、複数の水平レイヤが規定され、各水平レイヤが複数のセクションに分割されている。
また、各セクションは、そのルート（ＲＯＯＴ，ノード）が上位の水平レイヤのリーフ（ノード）となるサブツリーを有している。
また、例えば、同じ水平レイヤに属するセクションは、同じ数のノードを有する。すなわち、同じレイヤに属するセクションは、同じサブツリーを有している。
一般的な例としては、上記ツリーが、Ｋ個の水平レイヤに分割され、各水平レイヤｌ（ｌは０〜Ｌ−１の整数）の高さがＨ〔ｌ〕であるとすると、２Ｈ［ｌ−１］個のリーフを有している。また、水平レイヤｌは、下記式（１）で示される数のセクションを有し、そのサブツリーは、２Ｈ［ｌ−１］個のリーフ（ＬＥＡＦ）を有している。
【００４４】
【数１】
2004328233.tif 000003
【００４５】
Ｋ＝３、Ｈ〔０〕＝２、Ｈ〔１〕＝１、Ｈ〔３〕＝２の場合のツリー５０の構造を図１２に示す。
【００４６】
以下、上記ツリーを基に規定された本実施形態の鍵取得方法について説明する。
なお、メインサーバ２がサブサーバ３＿ｐをリボークする場合には、図１２に示すツリー５０のルート（ＲＯＯＴ）にメインサーバ２が仮想的に対応付けられ、各リーフ（ＬＥＡＦ）にサブサーバ３＿ｐが仮想的に対応付けられる。
一方、サブサーバ３＿ｐが受信装置４＿ｐ（ｎ）をリボークする場合には、図１２に示すツリー５０のルート（ＲＯＯＴ）にサブサーバ３＿ｐが仮想的に対応付けられ、各リーフ（ＬＥＡＦ）に当該サブサーバ３＿ｐに割り当てられた受信装置４＿ｐ（ｎ）が仮想的に対応付けられる。
【００４７】
図１３は、本実施形態の鍵取得方法を説明するためのフローチャートである。
以下、図１３に示す各ステップについて説明する。
ステップＳＴ６１：
処理部１３は、上記ツリー５０の水平レイヤ０（最下層のレイヤ）に属する全てのセクションの各々に対して、当該セクションが含むサブツリーのリーフのうち、リボークするリーフ（例えば、サブサーバ３＿ｐ）を特定する。
また、処理部１３は、ｌに初期値「０」を代入する。
【００４８】
ステップＳＴ６２：
処理部１３は、上記ツリーの水平レイヤ０に属する全てのセクションの各々に対して、当該セクションが含むサブツリーに対して採用されたリボケーション方式で、ステップＳＴ６１で特定したリーフをリボークする処理を行う。
すなわち、処理部１３は、上記採用されたリボケーション（ＲＶ）方式を基にリボケーション処理を行い、当該サブツリーに属するリーフのうちリボークされないリーフとの通信に使用する鍵暗号鍵データＫＥＫを決定するために用いられるデータ、例えば、リボークするリーフの位置などを示すデータを生成する。
【００４９】
ステップＳＴ６３：
処理部１３は、ｌをインクリメントする。すなわち、ｌ＝ｌ＋１を演算する。
【００５０】
ステップＳＴ６４：
処理部１３は、上記ツリーの水平レイヤｌに属する全てのセクションの各々に対して、当該セクションが含むサブツリーの最終端のノード（水平レイヤｌ−１のルート）のうち、その下層にリボークされるリーフがあるノード、すなわちリボークにより影響を受けるノードを特定する。
【００５１】
ステップＳＴ６５：
処理部１３は、上記ツリーの水平レイヤｌに属する全てのセクションの各々に対して、当該セクションが含むサブツリーに対して採用されたリボケーション方式で、ステップＳ６４で特定した最終端のノードをリボークする処理を行う。
すなわち、処理部１３は、上記採用されたリボケーション（ＲＶ）方式を基にリボケーション処理を行い、当該サブツリーに属する最終端のノードのうちリボークの影響を受けないノードの下層にあるリーフとの通信に使用する鍵暗号鍵データＫＥＫを決定するために用いられるデータ、例えば、リボークするノードの位置などを示すデータを生成する。
【００５２】
ステップＳＴ６６：
処理部１３は、ｌ＝Ｌであるか否かを判断し、ｌ＝Ｌであると判断した場合に処理を終了し、そうでない場合にステップＳＴ６３の処理に戻る。
【００５３】
ステップＳＴ６７：
処理部１３は、ステップＳＴ６１〜ＳＴ６６によって、全ての水平レイヤに属する全てのセクションについて行われたＲＶ処理の結果を基に、リボークしないリーフとの間の通信に用いる鍵暗号鍵データＫＥＫｍを生成する。
ここで、ｍは１〜Ｍの整数であり、Ｍはリボークしない全てのリーフとの通信に用いる鍵暗号鍵データＫＥＫの数を示している。
この場合に、リボークするリーフの上記ツリー上の位置に応じて、複数のリボークしないリーフに共通の鍵暗号鍵データＫＥＫｍを使用する場合がある。
なお、本実施形態では、鍵暗号鍵データＫＥＫｍを単に鍵暗号鍵データＫＥＫとも記すことがある。
【００５４】
次に、本実施形態においてリボケーション処理に用いる採用する鍵取得方法ＳＫＴである鍵取得方法ＳＫＴ−ＡおよびＳＫＴ−Ｂについて説明する。
鍵取得方法ＳＫＴ−Ａ，ＳＫＴ−Ｂは、前述した非特許文献１に開示されているＬＳＤ方式に比べて、リーフに割り当てられた装置が記憶するラベルデータＬＡＢＥＬ１および鍵データＫ＿ＯＲＧ１のデータ量が少なく、非特許文献２に開示されているＣＳＴ方式に比べてリボケーション処理に伴うルートに割り当てられた装置と、リボークしないリーフに割り当てられた装置との間の通信量が小さいという特徴を有している。
【００５５】
先ず、鍵取得方法ＳＫＴ−Ａについて説明する。
図１４は、鍵取得方法ＳＫＴ−Ａを説明するための図である。
図１４に示すように、鍵取得方法ＳＫＴ−Ａでは、例えば、ツリー５０を２つの水平レイヤＡ０，Ａ１に分割する。
ここで、水平レイヤＡ０が本発明の第１のレイヤに対応し、水平レイヤＡ１が本発明の第２のレイヤに対応している。
最下層の水平レイヤＡ０の高さをＨＡ〔０〕とし、水平レイヤＡ１の高さを（ｌｏｇ２Ｎ−ＨＡ〔０〕）とする。ここで、Ｎはリーフの総数を示す。
そして、水平レイヤＡ０に属する各セクション３１〔０〕のリボケーション方式として上記非特許文献１に開示されているＬＳＤ方式を採用する。
また、水平レイヤＡ１に属する各セクション３１〔１〕のリボケーション方式として上記非特許文献２に開示されているＣＳＴ方式を採用する。
【００５６】
ここで、鍵取得方法ＳＫＴ−Ａにおいて、Ｒ個のリーフのリボークが、上記ツリーを構成するＲ０Ａ個のセクションに影響を与えるとする。
この場合に、リボークに伴うルートに割り当てられた装置と、リボークされないリーフに割り当てられた装置との間の通信量のディメンションは、鍵取得方法ＳＫＴ−Ａの場合には下記式（２）に示すＯ（ＣＯＡ）となる。
【００５７】
【数２】
Ｏ（ＣＯＡ）＝Ｏ（Ｒ＋Ｒ０Ａ（ｌｏｇ２Ｎ−Ｈ０Ａ）−Ｒ０Ａｌｏｇ２Ｒ０Ａ）…（２）
【００５８】
次に、鍵取得方法ＳＫＴ−Ｂについて説明する。
図１５は、鍵取得方法ＳＫＴ−Ｂを説明するための図である。
図１５に示すように、鍵取得方法ＳＫＴ−Ｂでは、ツリー５０を３つの水平レイヤＢ０，Ｂ１，Ｂ２に分割する。
ここで、水平レイヤＢ０が本発明の第３のレイヤに対応し、水平レイヤＢ１が本発明の第４のレイヤに対応し，水平レイヤＢ２が本発明の第５のレイヤに対応している。
【００５９】
最下層の水平レイヤＢ０の高さをＨＢ〔０〕とし、水平レイヤＢ１の高さをＨＢ〔１〕とし、水平レイヤＢ２の高さを（ｌｏｇ２Ｎ−ＨＢ〔０〕−ＨＢ〔１〕）とする。
そして、水平レイヤＢ０に属する各セクション３１〔０〕のリボケーション方式として上記非特許文献１に開示されているＬＳＤ方式を採用する。
また、水平レイヤＢ１に属する各セクション３１〔１〕のリボケーション方式として上記非特許文献１に開示されているＬＳＤ方式を採用する。
さらに、水平レイヤＢ２に属する各セクション３１〔２〕のリボケーション方式として上記非特許文献２に開示されているＣＳＴ方式を採用する。
【００６０】
ここで、上述した鍵取得方法ＳＫＴ−Ｂにおいて、Ｒ個のリーフのリボークが、上記ツリーを構成する水平レイヤＢ１のＲ０Ｂ個のセクションに影響を与え、さらに水平レイヤＢ２のＲ１Ｂ個のセクションに影響を与えるとする。
この場合に、リボークに伴うルートに割り当てられた装置とリボークされないリーフに割り当てられた装置との間の通信量のディメンションは、鍵取得方法ＳＫＴ−Ｂの場合には下記式（３）に示すＯ（ＣＯＢ）となる。
【００６１】
【数３】
Ｏ（ＣＯＢ）＝（Ｒ＋Ｒ０Ｂ＋Ｒ１Ｂ（（ｌｏｇ２Ｎ）−ＨＢ〔１〕−ＨＢ〔０〕）−Ｒ１Ｂｌｏｇ２Ｒ１Ｂ）…（３）
【００６２】
以下、ＣＳＴ方式について説明する。
図１６〜図１８は、ＣＳＴ方式を説明するための図である。
以下の説明では、図１６に示すように、１６個のリーフｕ１〜ｕ１６に対してＣＳＴ方式でリボケーション処理を行う場合を例示する。
ＣＳＴ方式では、２分ツリーの各ノードを用いて、「そのノードを頂点とする２分ツリーのリーフに割り当てられたリーフからなる集合」を規定する。
図１６に示す例では、ノードｉは、リーフｕ５とｕ６を要素とする集合を示す。そして、各ノードにノードキー（ＳＫＴ−Ａでは鍵データＫ＿ＯＲＧ１に対応）が定義される。
【００６３】
各リーフには、それが割り当てられているリーフから、ルートに至るパス上のノードに割り当てられたノードキーが与えられ、リーフはこれらのノードキーを安全なメモリに保持する。
図１７に示すように、リーフｕ４には、ノード１，２，４，９，１９に割り当てられた５個のノードキーが与えられる。
すなわち、全リーフ数をＮとした場合には、各リーフはｌｏｇＮ＋１個のノードキーを保持する。
【００６４】
図１８は、秘密情報（たとえば、暗号化されたコンテンツを復号するためのコンテンツキー）をどのようにリボークされないリーフに送信するかを説明するための図である。
ここで、リーフｕ２，ｕ１１，ｕ１２がリボークするリーフとする。
この場合に、リボークするリーフｕ２，ｕ１１，ｕ１２が割り当てられているリーフからツリーのルートに至るパス上のノードに割り当てられたノードキーは使用することができない。これは、これらのノードキーを使用するとリボークするリーフが秘密情報を入手できてしまうためである。
そして、これらのノードおよびパスをツリーから除外すると、１つ以上のサブツリー（部分ツリー）が残る。
それぞれのサブツリーの頂点に最も近いノード（図１８ではノード５，７，９，１２，１６）に割り当てられたノードキーを用いて秘密情報を暗号化して送信することで、効率的で安全な秘密情報の送信を行う。
リーフは、伝送された暗号文のうち、自分が復号できるもの、すなわち、自身が割り当てられたリーフからルートに至るまでのパス上のノードに対応するノードキーを用いて暗号化されたものを復号して秘密情報を得る。
上記の例では、例えば、リーフｕ４はノード９のノードキーを保持しているので、これを用いて暗号化された暗号文を復号する。
ＣＳＴ方式では、リボークしないリーフが復号できる暗号文は必ずひとつ存在する。
【００６５】
次に、ＬＳＤ方式の前提となったＳＤ（Ｓｕｂｓｅｔ  Ｄｉｆｆｅｒｅｎｃｅ）  方式について説明する。
図１９〜図２２は、ＳＤ方式を説明するための図である。
上述したように、ＣＳＴ方式においては、ツリーの各ノードを用いて、「そのノードを頂点とするサブツリーのリーフに割り当てられたリーフからなる集合」を表している。
これに対し、ＳＤ方式では、ツリーの２つのノードｉ，ｊ（ただしｉはｊの先祖であるノード）を用いて、「（ノードｉを頂点とするサブツリーのリーフからなる集合）から（ノードｉを頂点とするサブツリーのリーフからなる集合）を引いた集合」を定義する。
例えば、図１９に示すノードｉ，ｊで定義される集合Ｓ（ｉ，ｊ）は、リーフｕ１〜ｕ８の集合からリーフｕ５，ｕ６を除いたものであり、すなわち、Ｓ（ｉ，ｊ）＝｛ｕ１，ｕ２，ｕ３，ｕ４，ｕ５，ｕ６，ｕ７，ｕ８，ｕ９｝−｛ｕ５，ｕ６｝である。
ノードｉがノードｊの先祖である（すなわち、ノードｊはノードｉと同一ではなく、ノードｊからルートへのパス上にノードｉが存在する）全てのノードの組についてこのような集合を定義する。
そして、各集合に、ラベルデータＬＡＢＥＬを割り当てる。また、ラベルデータＬＡＢＥＬ１を基に所定の演算（例えば、当該ラベルデータＬＡＢＥＬをキーとして疑似乱数を生成して）を行ってサブセットキーを得る。
当該サブセットキーは、当該集合の要素であるリーフとルートとの間の通信において、鍵暗号鍵データＫＥＫとして用いられる。
ＳＤ方式では、一つのリーフが所属する集合の個数はＯ（Ｎ）となるため、それぞれの集合（サブセット）に鍵データＳＫ（サブセットキー）を独立に割り当てたのでは、各リーフがＯ（Ｎ）個のサブセットキーに対応するラベルデータＬＡＢＥＬ１を安全に保持する必要があるが、これはＮが大きいときには現実的に困難である。
【００６６】
そのため、ＳＤ方式では以下に述べる手法により、各リーフが保持するラベルデータＬＡＢＥＬの数を削減している。
例えば、図２０（Ａ）に示すように、内部ノード（すなわち、リーフでないノード）ｉに注目し、そのノードのラベルデータＬＡＢＥＬ（ｉ）としてＣビットの値Ｓをランダムに選択する。
次に、図２１に示すように、Ｃビット入力、３Ｃビット出力の擬似乱数生成器Ｇに、ＬＡＢＥＬ（ｉ）の値Ｓ入力する。
そして、擬似乱数生成器Ｇからの３Ｃビットの出力を左から（最上位ビット側から）Ｃビットずつに区切り、それぞれＧＬ（Ｓ），ＧＭ（Ｓ），ＧＲ（Ｓ）とする。
【００６７】
そして、ＧＬ（Ｓ）を、ノードｉの左側（一方）の子ノードのラベルデータＬＡＢＥＬとし、ＧＲ（Ｓ）をノードｉの右側（他方）の子ノードのラベルデータＬＡＢＥＬとする。
この処理により、図２０においてノードｉの左側の子であるノードｋについて、ノードｉを始点にした場合のノードｋのラベルデータＬＡＢＥＬ（ｉ，ｋ）は、ＬＡＢＥＬ（ｉ，ｋ）＝ＧＬ（Ｓ）となる。そして、これをＴとする。
次に、Ｔを上記の擬似乱数生成器Ｇに入力し、その出力を左からＣビットずつに区切って、ＧＬ（Ｔ），ＧＭ（Ｔ），ＧＲ（Ｔ）を得る。
そして、ＧＬ（Ｔ），ＧＭ（Ｔ），ＧＲ（Ｔ）を、それぞれノードｉを始点にした場合のノードｋの左側の子ノードＬのラベルデータＬＡＢＥＬ（ｉ，ｋＬ）、ノードｉを始点にした場合のノードｋのラベルデータＬＡＢＥＬ（ｉ，ｋ）、ノードｉを始点にした場合のノードｋの右側の子ノードｋＲのラベルデータＬＡＢＥＬ（ｉ，ｋＲ）とする。
この処理を繰り返すことにより、ノードｉを始点とした場合の、その子孫となるすべてのノードに対応するラベルを作り出す。
【００６８】
なお、上記の定義によれば集合Ｓ（ｉ，ｉ）は空集合であり、ノードｉを始点とした場合に、ノードｉの鍵というものは不要であるため、ＬＡＢＥＬ（ｉ）を擬似乱数生成器Ｇに入力した出力の中央部分であるＧＭ（Ｓ）は使われない。
図２０（Ａ）に示すように、始点であるノードｉのラベルデータＬＡＢＥＬ（ｉ）の値Ｓが定められ、ＧＲ（Ｓ）がノードｉを始点とした場合のノードｉの右の子ノードのラベルデータＬＡＢＥＬとなり、さらにそれを擬似乱数生成器Ｇに入力して得られたＧＬ（Ｓ）が、ノードｉを始点とした場合のノードｊのラベルデータＬＡＢＥＬとなる。
この処理を、すべての内部ノードｉに対して行う。
【００６９】
これらの処理はシステムのセットアップ時にルートに割り当てられた装置によって行われるが、擬似乱数生成器（あるいは擬似乱数生成関数）Ｇはルートに割り当てられた装置によって定められ公開されており、これを用いることによって、ＬＡＢＥＬ（ｉ，ｊ）を与えられたリーフは、ノードｉを始点とした場合の、ノードｊの子孫となるすべてのノードｎのラベルＬＡＢＥＬ（ｉ，ｎ）を計算でき、ノードｉを始点とした場合の、ノードｊおよびその子孫ノードｎのサブセットキーＳＫ（ｉ，ｎ）を計算できる。
このようにしておけば、図２０（Ｂ）に示すように、あるリーフｕは、それが割り当てられたリーフからツリーの頂点へのパス上のそれぞれの内部ノードｉについて、ノードｉを始点として、このリーフからｉへのパスから直接枝分かれしているノードのラベルデータＬＡＢＥＬのみを保持しておけば、そのノードおよびそれ以降の（その子孫となる）ノードの、ノードｉを始点としたサブセットキーを作り出すことが可能となる。図２０（Ｂ）では、ノードｉに注目したときに、ｕからｉへのパスから直接枝分かれしているノードは３つであり、リーフｕは、これら３つのラベルデータＬＡＢＥＬをシステムのセットアップ時にルートに割り当てられた装置から受け取る。
【００７０】
以下、図２２に示す例において、リーフｕ４について考える。
リーフｕ４については、それが割り当てられたリーフであるノード１９から、ルート１へのパス上の内部ノード１，２，４，９が始点（ノードｉ）となる。ノード１を始点とすると、ノード１９からノード１へのパスから直接枝分かれしているノードはノード３，５，８，１８の４つであるため、ＬＡＢＥＬ（１，３），（１，５），（１，８），（１，１８）をリーフｕ４は保持する。
同様に、ノード２を始点とした場合にＬＡＢＥＬ（２，５），（２，８），（２，１８）３つのラベルデータＬＡＢＥＬを、ノード４を始点とした場合にはＬＡＢＥＬ（４，８），（４，１８）の２つのラベルデータＬＡＢＥＬを、ノード９を始点とした場合にはＬＡＢＥＬ（９，１８）を保持する。
また、リボークするリーフがないという特別な場合に使用する、全リーフを含む集合（これをＳ１，φと表すことにする）に対応するラベルデータＬＡＢＥＬ（１）をひとつ保持する。
ただし、Ｓ（１），φに対応するラベルデータＬＡＢＥＬとしているが、ラベルデータＬＡＢＥＬではなくＳ１，φに対応するサブセットキーを直接保持してもよい。
上記のように、各リーフは、リーフからルートへのパス上の各内部ノードについて、その内部ノードの高さ分だけのラベルデータＬＡＢＥＬを保持する必要がある。
これらのラベルデータＬＡＢＥＬは、公開されているＧを用いることによりサブセットキーを作り出せるものであるため、リーフがこれらを安全に保持する。
【００７１】
以下、上述したＳＤ方式を基礎としたＬＳＤ（  Ｂａｓｉｃ  Ｌａｙｅｒｅｄ  Ｓｕｂｓｅｔ  Ｄｉｆｆｅｒｅｎｃｅ）方式を説明する。
ＬＳＤ方式には、Ｂａｓｉｃ（基本）方式と、その拡張であるＧｅｎｅｒａｌ（一般化）方式がある。ここではＢａｓｉｃ方式について説明する。
ＬＳＤ方式はＳＤ方式の拡張であり、レイヤという新たな概念を取り入れたものである。ＳＤ方式における木構造の中で、特定の高さを特別レベル（Ｓｐｅｃｉａｌ  Ｌｅｖｅｌ）として定義する。
Ｂａｓｉｃ＿ＬＳＤ方式においては特別ラベルは１種類だけであるが、Ｇｅｎｅｒａｌ＿ＬＳＤ方式においては重要度の異なる複数の複数の特別レベルを用いる。
ここで、簡単のため、ｌｏｇ１／２Ｎを整数であるとする。
Ｂａｓｉｃ＿ＬＳＤ方式では、図２３に示すように、ツリーのルートからリーフに至るまでのそれぞれのレベル（階）のうち、ルートとリーフのレベルを含む、ｌｏｇ１／２Ｎごとのレベルを特別レイヤとする。
そして、隣り合う２つの特別レイヤに挟まれた階層（両方の特別レベルを含む）を、レイヤと呼ぶ。
図２３の例では、ルートのレベル、ノードｋを含むレベル、リーフのレベルが特別レベルであり、ルートのレベルとノードｉを含むレベルとノードｋを含むレベルが１つのレイヤを構成する。またノードｋを含むレベルとノードｊを含むレベルとリーフを含むレベルが別のレイヤを構成する。
【００７２】
Ｂａｓｉｃ＿ＬＳＤ方式においては、ＳＤ方式において定義されたサブセットＳ（ｉ，ｊ）のうち、ノードｉとノードｊが同一レイヤにあるか、もしくはノードｉが特別レベルにあるものだけを定義する。
このようにすると、ＳＤ方式において用いられたサブセットのうちのいくつかはＢａｓｉｃ＿ＬＳＤ方式では定義されなくなるが、このサブセットはＢａｓｉｃ＿ＬＳＤ方式で定義されたサブセットの高々２つの和集合で表すことができる。
例えば、図２３の例では、サブセットＳ（ｉ，ｊ）はＢａｓｉｃ＿ＬＳＤ方式では定義されないが、ノードｉからノードｊへのパス上の、ノードｉに最も近い特別レベル上のノード（ノードｋ）を用いて、Ｓ（ｉ，ｊ）＝Ｓ（ｉ，ｋ）∪Ｓ（ｋ，ｊ）と表すことができる。
つまり、ＳＤ方式においてはサブセットＳ（ｉ，ｊ）に対応するサブセットキーＳｋ（ｉ，ｊ）を用いて暗号化した１つの暗号文の代わりに、Ｂａｓｉｃ＿ＬＳＤ方式においてはサブセットＳ（ｉ，ｋ）とＳ（ｋ，ｊ）に対応するサブセットキーＳｋ（ｉ，ｋ），ＳＫ（ｋ，ｊ）を用いて暗号化した２つの暗号文を送信する。
これにより、送信される暗号文の数はＳＤ方式の高々２倍に増加するが、各受信機が保持するラベルの数を減らすことができる。
【００７３】
図２４に、図２２のＳＤ方式で想定したのと同じ場合にＢａｓｉｃ＿ＬＳＤ方式を適用した場合を説明する。
図２４に示すリーフｕ４は、ｉ，ｊが同一レイヤにあるか、ｉが特別レベルにあるラベルデータＬＡＢＥＬ（ｉ，ｊ）のみ保持すればよい。
すなわち、リーフｕ４が保持するラベルデータＬＡＢＥＬは、ラベルデータＬＡＢＥＬ（１，３），（１，５），（１，８），（１，１８），（２，５），（４，８），（４，１８），（９，１８）となる。
さらに、ＳＤ方式と同様に、リボークする受信機がない場合に用いる特別なラベルも保持する必要がある。
【００７４】
以下、サブサーバ３＿ｐをリボークする場合の図２に示すメインサーバ２の動作例を説明する。
メインサーバ２の動作は、前述したように、プログラムＰＲＧ１を基にした処理部１３の処理により実現される。
〔前処理の動作例〕
図２５は、メインサーバ２が上述した前処理を行う場合の動作例を説明するためのフローチャートである。
前述したように、メインサーバ２の処理部１３は、リボケーション処理に先立って、例えば、サブサーバ３＿ｐの登録時などに、以下に示す前処理を行う。
【００７５】
ステップＳＴ７１：
メインサーバ２は、上述した鍵取得方法ＳＫＴのうち、鍵取得方法ＳＫＴ−ＡおよびＳＫＴ−Ｂを、サブサーバ３＿ｐのリボケーション処理に使用する鍵取得方法として規定する。
ステップＳＴ７２：
メインサーバ２は、鍵取得方法ＳＫＴ−ＡおよびＳＫＴ−ＡＴ、並びに鍵取得方法ＳＫＴ−ＡおよびＳＫＴ−Ｂで使用する鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬ１をサブサーバ３＿ｐに設定する。
具体的には、メインサーバ２は、サブサーバ３＿ｐの各々に、図１４に示す鍵取得方法ＳＫＴ−Ａにおける水平レイヤＡ０内の当該サブサーバ３＿ｐが属するサブツリー内の他の何れのサブサーバ３＿ｐが無効にされる場合でも、当該サブツリー内の無効にされないサブサーバ３＿ｐのみを要素とする集合が存在するように規定された複数の集合にそれぞれ割り当てられた複数のラベルデータＬＡＢＥＬを取得するためのラベルデータＬＡＢＥＬ１を設定する。
また、メインサーバ２は、サブサーバ３＿ｐの各々に、図１４に示す水平レイヤＡ１内の当該サブサーバ３＿ｐに対応する最終端のノードと前記ルートとの間のパス上に位置する全てのノードにそれぞれ割り当てられた複数の鍵データＫ＿ＯＲＧ１を設定する。
【００７６】
また、メインサーバ２は、サブサーバ３＿ｐの各々に、図１５に示す鍵取得方法ＳＫＴ−Ｂにおける水平レイヤＢ０内の当該サブサーバ３＿ｐが属するサブツリー内の他の何れのサブサーバ３＿ｐが無効にされる場合でも、当該サブツリー内の無効にされないサブサーバ３＿ｐのみを要素とする集合が存在するように規定された複数の集合にそれぞれ割り当てられた複数のラベルデータＬＡＢＥＬを取得するためのラベルデータＬＡＢＥＬ１を設定する。
また、メインサーバ２は、サブサーバ３＿ｐの各々に、図１５に示す水平レイヤＢ１内の何れのサブツリー内がその分岐先に無効にされるサブサーバ３＿ｐを含む場合でも、当該サブツリー内の無効にされないサブサーバ３＿ｐのみを分岐先に含む最終端のノードのみを要素とする集合が存在するように規定された複数の集合にそれぞれ割り当てられた複数のラベルデータＬＡＢＥＬを取得するためのラベルデータＬＡＢＥＬ１を設定する。
また、メインサーバ２は、サブサーバ３＿ｐの各々に、図１５に示す水平レイヤＢ２内の当該サブサーバ３＿ｐに対応する最終端のノードと前記ルートとの間のパス上に位置する全てのノードにそれぞれ割り当てられた複数の鍵データＫ＿ＯＲＧ１を設定する。
メインサーバ２は、例えば、サブサーバ３＿ｐの発行あるいは登録時に、サブサーバ３＿ｐに対して個別に上記設定をセキュアな状態で行う。
【００７７】
〔リボケーション処理の動作例〕
図２６および図２７は、メインサーバ２が上述したサブサーバ３＿ｐのリボケーション処理を行う場合の動作例を説明するためのフローチャートである。
メインサーバ２の処理部１３は、サブサーバ３＿ｐのうち何れかをリボークする場合に、当該リボケーション処理を行う。
図２６および図２７において、ステップＳＴ８１が図６に示すステップＳＴ１に対応し、ステップＳＴ８２〜ＳＴ８５が図６に示すステップＳＴ２に対応し、ステップＳＴ８６〜ＳＴ９０が図６に示すステップＳＴ３に対応している。
【００７８】
ステップＳＴ８１：
メインサーバ２は、サブサーバ３＿ｐのうちリボークするサブサーバ３＿ｐを示すリボケーションリストＲＬを生成する。
ステップＳＴ８２：
メインサーバ２は、リボケーションリストＲＬを基に、上述した鍵取得方法ＳＫＴ−ＡおよびＳＫＴ−Ｂの各々について、当該鍵取得方法を採用した場合に、メインサーバ２とリボークしないサブサーバ３＿ｐとの間に生じる通信量を特定する。
ステップＳＴ８３：
メインサーバ２は、ステップＳＴ８２で特定した鍵取得方法ＳＫＴ−Ａを採用した場合の通信量が、鍵取得方法ＳＫＴ−Ｂを採用した場合の通信量以下であるか否かを判断する。
メインサーバ２は、ステップＳＴ８２で特定した鍵取得方法ＳＫＴ−Ａを採用した場合の通信量が鍵取得方法ＳＫＴ−Ｂを採用した場合の通信量以下であると判断すると鍵取得方法ＳＫＴ−Ａを選択してステップＳＴ８４に進み、そうでない場合には鍵取得方法ＳＫＴ−Ｂを選択してステップＳＴ８５に進む。
【００７９】
ステップＳＴ８４：
メインサーバ２は、ステップＳＴ８１で生成したリボケーションリストＲＬを基に、リボークしないサブサーバ３＿ｐとの間の通信に用いる鍵暗号鍵データＫＥＫｍを、鍵取得方法ＳＫＴ−Ａに従って特定する。
当該処理については、後に詳細に説明する。
ステップＳＴ８５：
メインサーバ２は、ステップＳＴ８１で生成したリボケーションリストＲＬを基に、リボークしないサブサーバ３＿ｐとの間の通信に用いる鍵暗号鍵データＫＥＫｍを、鍵取得方法ＳＫＴ−Ｂに従って特定する。
当該処理については、後に詳細に説明する。
【００８０】
ステップＳＴ８６：
メインサーバ２は、図２８に示すように、ステップＳＴ８４あるいはＳＴ８５で特定した鍵暗号鍵データＫＥＫｍの生成に用いる鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬを指定した鍵指定データＫＩＤｍと、ステップＳＴ８３で選択した鍵取得方法を指定する鍵取得方法指定データＫＯＩＤｍとを含む指定データＩｍ（本発明の指定データ）を生成する。
なお、鍵指定データＫＩＤｍにおける鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬの指定は、鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬに割り当てられたインデックスなどの識別データを基に行い、鍵データＫ＿ＯＲＧ１およびラベルデータＬＡＢＥＬ自体は含めない。
【００８１】
ステップＳＴ８７：
メインサーバ２は、新たな（更新後の）セッション鍵データＮＥＷ＿ＳＥＫを、ステップＳＴ８４あるいはＳＴ８５で生成した鍵暗号鍵データＫＥＫｍで暗号化してデータＥＫＥＫｍ（ＮＥＷ＿ＳＥＫ）を生成する。
ステップＳＴ８８：
メインサーバ２は、サブサーバ３＿ｐに提供する秘密情報であるペイロードデータＰＡＹＬを、新たなセッション鍵データＮＥＷ＿ＳＥＫを用いて暗号化してデータＥＮＥＷ＿ＳＥＫ（ＰＡＹＬ）を生成する。
ステップＳＴ８９：
メインサーバ２は、ステップＳＴ８６で生成した指定データＩｍ（Ｉ１〜ＩＭ）と、ステップＳＴ８７で生成したデータＥＫＥＫｍ（ＮＥＷ＿ＳＥＫ）と、ステップＳＴ８８で生成したＥＮＥＷ＿ＳＥＫ（ＰＡＹＬ）とを格納したデータである図２９に示すカプセルデータＣＡＰを生成する。
ステップＳＴ９０：
メインサーバ２は、ステップＳＴ８９で生成したカプセルデータＣＡＰを、図２に示す通信部１１を介して、例えば、放送（送信）する。
当該放送は、いわゆるＰＵＳＨ配信である。
なお、本実施形態における通信量は、ステップＳＴ９０における送信による通信に応じて決まり、前述したように、鍵取得方法ＳＫＴ−ＡとＳＫＴ−Ｂのうちより通信量が少ない方が採用される。
【００８２】
以下、図２６に示すステップＳＴ８４、すなわち、鍵取得方法ＳＫＴ−Ａを採用した場合の鍵暗号鍵データＫＥＫｍの生成方法について詳細に説明する。
図３０は、図２６に示すステップＳＴ８４、すなわち鍵取得方法ＳＫＴ−Ａを基にした鍵暗号鍵データＫＥＫの生成方法を説明するための図である。
【００８３】
ステップＳＴ１０１：
メインサーバ２は、図１４に示す水平レイヤＡ０に属するサブツリー（ＳＵＢＴ）のうちリボークするサブサーバ３＿ｐを含む全てのサブツリーの各々に対して、当該サブツリーに属するサブサーバ３＿ｐを各々が要素とする予め規定された複数の集合のなかから、当該サブツリー内のリボークしないサブサーバ３＿ｐのみを要素とする集合を特定する。
【００８４】
ステップＳＴ１０２：
メインサーバ２は、図１４に示す水平レイヤＡ１内の最終端のノードのうち、当該ノードの分岐先にリボークするサブサーバ３＿ｐが存在しないノードを特定する。
【００８５】
ステップＳＴ１０３：
メインサーバ２は、ステップＳＴ１０２で特定した全てのノードに対して、当該ノードとルートとの間のパス上に位置するノードのなかで、当該ノードから分岐した前記サブサーバ３＿ｐにリボークする前記サブサーバ３＿ｐが無く、かつルートに最も近いノードを特定する。
【００８６】
ステップＳＴ１０４：
メインサーバ２は、ステップＳＴ１０１で特定した集合（あるいはそのラベルデータＬＡＢＥＬ）に対応付けられた鍵暗号鍵データＫＥＫｍを、当該集合の要素であるサブサーバ３＿ｐとの間の通信に使用することを決定する。
メインサーバ２は、例えば、図１４に示す水平レイヤＡ０内の全てのサブセットの上記集合と鍵暗号鍵データＫＥＫｍとを対応付けて保持し、ステップＳＴ１０１で特定した集合に対応する鍵暗号鍵データＫＥＫを特定する。
また、メインサーバ２は、例えば、図１４に示す水平レイヤＡ０内の上述した集合であるサブセットＳ（ｉ，ｊ）のうち、ノードｉとノードｊが同一レイヤにあるか、もしくはノードｉが特別レベルにあるものに対応するラベルデータＬＡＢＥＬ１（ｉ，ｊ）を保持し、これを基に、図１９〜図２４を用いて説明した方法でラベルデータＬＡＢＥＬを生成し、このラベルデータＬＡＢＥＬを基にそのサブセットキーである鍵暗号鍵データＫＥＫｍを生成してもよい。
そして、メインサーバ２は、上記特定（生成）した鍵暗号鍵データＫＥＫｍを、上記特定した集合の要素であるサブサーバ３＿ｐが生成するために用いるラベルデータＬＡＢＥＬを指定する鍵・ラベル指定データＫＩＤｍを含む指定データＩｍを生成する。
なお、鍵・ラベル指定データＫＩＤｍが指定するラベルデータＬＡＢＥＬは、サブサーバ３＿ｐが保持するラベルデータＬＡＢＥＬ１の他に、例えば、上述したＳＤ方式およびＬＳＤ方式により、当該ラベルデータＬＡＢＥＬ１を基にサブサーバ３＿ｐが生成するラベルデータＬＡＢＥＬである。
【００８７】
ステップＳＴ１０５：
メインサーバ２は、ステップＳＴ１０３で特定したノードに対応する鍵データＫ＿ＯＲＧ１（ノードキー）を鍵暗号鍵データＫＥＫｍとして、当該ノードの分岐先のサブサーバ３＿ｐとの通信に使うことを決定する。
そして、メインサーバ２は、上記決定した鍵暗号鍵データＫＥＫｍである鍵データＫ＿ＯＲＧ１を指定する鍵指定データＫＩＤｍを含む指定データＩｍを生成する。
【００８８】
以下、図２６に示すステップＳＴ８５、すなわち、鍵取得方法ＳＫＴ−Ｂを採用した場合の鍵暗号鍵データＫＥＫｍの生成方法について詳細に説明する。
図３１は、図２６に示すステップＳＴ８５、すなわち鍵取得方法ＳＫＴ−Ｂを基にした鍵暗号鍵データＫＥＫの生成方法を説明するための図である。
【００８９】
ステップＳＴ１１１：
メインサーバ２は、図１５に示す水平レイヤＢ０に属するサブツリー（ＳＵＢＴ）のうちリボークするサブサーバ３＿ｐを含む全てのサブツリーの各々に対して、当該サブツリーに属するサブサーバ３＿ｐを各々が要素とする予め規定された複数の集合のなかから、当該サブツリー内のリボークしないサブサーバ３＿ｐのみを要素とする集合を特定する。
【００９０】
ステップＳＴ１１２：
メインサーバ２は、図１５に示す水平レイヤＢ１に属するサブツリー（ＳＵＢＴ）に対して、当該サブツリー内の最終端のノードのうち分岐先にリボークしないサブサーバ３＿ｐのみを含むノードのみを要素とする集合を特定する。
ステップＳＴ１１３：
メインサーバ２は、図１５に示す水平レイヤＢ２内の最終端のノードのうち、当該ノードの分岐先に無効にするサブサーバ３＿ｐが存在しないノードを特定する。
【００９１】
ステップＳＴ１１４：
メインサーバ２は、ステップＳＴ１１３で特定した全てのノードに対して、当該ノードとルートとの間のパス上に位置するノードのなかで、当該ノードから分岐した前記サブサーバ３＿ｐにリボークする前記サブサーバ３＿ｐが無く、かつルートに最も近いノードを特定する。
【００９２】
ステップＳＴ１１５：
メインサーバ２は、ステップＳＴ１１１で特定した集合（あるいはそのラベルデータＬＡＢＥＬ）に対応付けられた鍵暗号鍵データＫＥＫｍを、当該集合の要素であるサブサーバ３＿ｐとの間の通信に使用することを決定する。
メインサーバ２は、例えば、図１５に示す水平レイヤＢ０内の全てのサブセットの上記集合と鍵暗号鍵データＫＥＫｍとを対応付けて保持し、ステップＳＴ１１１で特定した集合に対応する鍵暗号鍵データＫＥＫを特定する。
また、メインサーバ２は、例えば、図１５に示す水平レイヤＢ０内の上述した集合であるサブセットＳ（ｉ，ｊ）のうち、ノードｉとノードｊが同一レイヤにあるか、もしくはノードｉが特別レベルにあるものに対応するラベルデータＬＡＢＥＬ１（ｉ，ｊ）を保持し、これを基に、図１９〜図２４を用いて説明した方法でラベルデータＬＡＢＥＬを生成し、このラベルデータＬＡＢＥＬを基にそのサブセットキーである鍵暗号鍵データＫＥＫｍを生成してもよい。
そして、メインサーバ２は、上記特定（生成）した鍵暗号鍵データＫＥＫｍを上記特定した集合の要素であるサブサーバ３＿ｐが生成するために用いるラベルデータＬＡＢＥＬを指定する鍵・ラベル指定データＫＩＤｍを含む指定データＩｍを生成する。
【００９３】
ステップＳＴ１１６：
メインサーバ２は、ステップＳＴ１１２で特定した集合（あるいはそのラベルデータＬＡＢＥＬ）に対応付けられた鍵暗号鍵データＫＥＫｍを、当該集合の要素であるサブサーバ３＿ｐとの間の通信に使用することを決定する。
当該鍵暗号鍵データＫＥＫの決定（生成）方法は、ステップＳＴ１１５と同様である。
そして、メインサーバ２は、上記特定（生成）した鍵暗号鍵データＫＥＫｍを上記特定した集合の要素であるサブサーバ３＿ｐが生成するために用いるラベルデータＬＡＢＥＬを指定する鍵・ラベル指定データＫＩＤｍを含む指定データＩｍを生成する。
ステップＳＴ１１７：
メインサーバ２は、ステップＳＴ１１４で特定したノードに対応する鍵データＫ＿ＯＲＧ１（ノードキー）を鍵暗号鍵データＫＥＫｍとして、当該ノードの分岐先のサブサーバ３＿ｐ１０４＿１〜１０４＿Ｎとの通信に使うことを決定する。
そして、メインサーバ２は、上記決定した鍵暗号鍵データＫＥＫｍである鍵データＫ＿ＯＲＧ１を指定する鍵・ラベル指定データＫＩＤｍを含む指定データＩｍを生成する。
【００９４】
以下、サブサーバ３＿ｐについて説明する。
図４に示すメモリ２２は、前述したように、処理部４３によって実行されるプログラムＰＲＧ２と、プログラムＰＲＧ２の実行に用いられる種々データを記憶する。
プログラムＰＲＧ２は、前述した鍵取得方法ＳＫＴ−ＡおよびＳＫＴ−Ｂの処理手順を含んでいる。
メモリ２２は、メインサーバ２による前述した前処理によって、サブサーバ３＿ｐの各々に割り当てられた鍵データＫ＿ＯＲＧ１，Ｋ＿ＯＲＧ２およびラベルデータＬＡＢＥＬ１，ＬＡＢＥＬ２を記憶する。
具体的には、メモリ２２は、図１４に示す鍵取得方法ＳＫＴ−Ａの水平レイヤＡ０内の当該サブサーバ３＿ｐが属するサブツリー内の他の何れのサブサーバ３＿ｐがリボークされる場合でも、当該サブツリー内のリボークされない前記サブサーバ３＿ｐのみを要素とする集合が存在するように規定された複数の集合にそれぞれ割り当てられた複数のラベルデータＬＡＢＥＬを取得するためのラベルデータＬＡＢＥＬ１を記憶する。
また、メモリ２２は、図１４に示す鍵取得方法ＳＫＴ−Ａの水平レイヤＡ１内の当該サブサーバ３＿ｐに対応する最終端のノードと前記ルートとの間のパス上に位置する全てのノードにそれぞれ割り当てられた複数の鍵データＫ＿ＯＲＧ１を記憶する。
【００９５】
また、メモリ２２は、図１５に示す鍵取得方法ＳＫＴ−Ｂの水平レイヤＢ０内の当該サブサーバ３＿ｐが属するサブツリー内の他の何れのサブサーバ３＿ｐがリボークされる場合でも、当該サブツリー内のリボークされないサブサーバ３＿ｐのみを要素とする集合が存在するように規定された複数の集合にそれぞれ割り当てられた複数のラベルデータＬＡＢＥＬを取得するためのラベルデータＬＡＢＥＬ２を記憶する。
また、メモリ２２は、図１５に示す水平レイヤＢ１内の何れのサブツリー内がその分岐先にリボークされるサブサーバ３＿ｐを含む場合でも、当該サブツリー内のリボークされないサブサーバ３＿ｐのみを分岐先に含む最終端のノードのみを要素とする集合が存在するように規定された複数の集合にそれぞれ割り当てられた複数のラベルデータＬＡＢＥＬを取得するためのラベルデータＬＡＢＥＬ２を記憶する。
また、メモリ２２は、図１５に示す水平レイヤＢ２内の当該サブサーバ３＿ｐに対応する最終端のノードと前記ルートとの間のパス上に位置する全てのノードにそれぞれ割り当てられた複数の鍵データＫ＿ＯＲＧ２を記憶する。
【００９６】
ここで、メモリ２２が記憶する鍵データＫ＿ＯＲＧ１，Ｋ＿ＯＲＧ２およびラベルデータＬＡＢＥＬ１，ＬＡＢＥＬ２のデータ量はオーダＯ（ＳＴ）は、下記式（４）で示される。
【００９７】
【数４】
Ｏ（ＳＴ）＝Ｏ（ｍａｘ｛（（ＨＡ〔０〕）１．５−ＨＡ〔０〕＋ｌｏｇ２Ｎ），（（ＨＢ〔０〕）１．５＋（ＨＢ〔１〕）１．５−ＨＢ〔０〕−ＨＢ〔１〕＋ｌｏｇ２Ｎ）｝…（４）
【００９８】
処理部４３は、メモリ２２に記憶されたプログラムＰＲＧ２を実行し、その実行に応じてサブサーバ３＿ｐの処理を統括して制御する。本実施形態において、サブサーバ３＿ｐの処理は、処理部４３が実行するプログラムＰＲＧ２によって規定される。
プログラムＰＲＧ２によって規定される処理部４３の機能は、サブサーバ３＿ｐもユーザからは制御できないように構成されている。また、サブサーバ３＿ｐのユーザは、これらの機能を全く意識せずにサブサーバ３＿ｐを使用する。
【００９９】
以下、メインサーバ２によって所定のサブサーバ３＿ｐがリボークされる場合に、サブサーバ３＿ｐが行う動作例を説明する。
図３２は、サブサーバ３＿ｐの動作例を説明するためのフローチャートである。
なお、サブサーバ３＿ｐの動作は、前述したように、処理部２３がプログラムＰＲＧ２を実行することで規定される。
図３２に示す処理は、図６に示すステップＳＴ４の処理に対応している。
【０１００】
ステップＳＴ１２１：
サブサーバ３＿ｐの通信部４１が、図２７に示すステップＳＴ９０においてメインサーバ２が放送したカプセルデータＣＡＰを受信する。
ステップＳＴ１２２：
サブサーバ３＿ｐの処理部２３が、ステップＳＴ１２１で受信したカプセルデータＣＡＰ内に、自らに対応する図２８に示す鍵・ラベル指定データＩｍが含まれているか否かを判断し、含まれていると判断した場合（リボークされないサブサーバ３＿ｐの場合）にはステップＳＴ１２３の処理に進み、そうでない場合（リボークされるサブサーバ３＿ｐの場合）には処理を終了する。
【０１０１】
ステップＳＴ１２３：
処理部２３は、カプセルデータＣＡＰ内に、自らに対応する指定データＩｍを取得する。
ステップＳＴ１２４：
処理部２３は、メモリ２２が記憶する鍵データＫ＿ＯＲＧ１のなかからステップＳＴ１２２で取得した指定データＩｍ内の鍵・ラベル指定データＫＩＤｍが指定する鍵データＫ＿ＯＲＧ１またはラベルデータＬＡＢＥＬを特定する。
【０１０２】
ステップＳＴ１２５：
処理部２３は、ステップＳＴ１２３で取得した指定データＩｍ内の鍵取得方法指定データＫＯＩＤｍが鍵取得方法ＳＫＴ−ＡとＳＫＴ−Ｂのうち何れを指定しているかを特定する。
ステップＳＴ１２６：
処理部２３は、ステップＳＴ１２４で特定した鍵データＫ＿ＯＲＧ１あるいはラベルデータＬＡＢＥＬを基に、ステップＳＴ１２５で特定した鍵取得方法ＳＫＴ−ＡあるいはＳＫＴ−Ｂを基に鍵暗号鍵データＫＥＫｍを取得（生成）する。
当該ステップＳＴ１２６の処理については、後に詳細に説明する。
【０１０３】
ステップＳＴ１２７：
処理部２３は、ステップＳＴ１２６で取得（生成）した鍵暗号鍵データＫＥＫｍを用いて、カプセルデータＣＡＰ内のデータＥＫＥＫｍ（ＮＥＷ＿ＳＥＫ）を復号して新たなセッション鍵データＮＥＷ＿ＳＥＫを取得する。
ステップＳＴ１２８：
処理部２３は、カプセルデータＣＡＰ内のデータＥＮＥＷ＿ＳＥＫ（ＰＡＹＬ）を、ステップＳＴ１２７で取得した新たなセッション鍵データＮＥＷ＿ＳＥＫを用いて復号してパイロードデータＰＡＹＬを取得する。
【０１０４】
サブサーバ３＿ｐは、以後、次にリボケーション処理を行うまで、メインサーバ２から受信したデータを復号するために、ステップＳＴ１２７で取得したセッション鍵データＮＥＷ＿ＳＥＫを使用する。
【０１０５】
以下、図３２に示すステップＳＴ１２６の処理を説明する。
図３３は、図３２に示すステップＳＴ１２６の処理を説明するためのフローチャートである。
ステップＳＴ１３１：
処理部２３は、図３２に示す前述したステップＳＴ１２４でラベルデータＬＡＢＥＬを特定したか否かを判断し、ラベルデータＬＡＢＥＬを特定したと判断するとステップＳＴ１３２に進み、鍵データＫ＿ＯＲＧ１を特定したと判断するとステップＳＴ１３６に進む。
【０１０６】
ステップＳＴ１３２：
処理部２３は、ステップＳＴ１２４で特定したラベルデータＬＡＢＥＬの生成に必要なラベルデータＬＡＢＥＬ１を、メモリ２２が記憶（保持）しているか否かを判断し、メモリ２２が記憶していると判断するとステップＳＴ１３５に進み、そうでない場合にはステップＳＴ１３３に進む。
ステップＳＴ１３３：
処理部２３は、メモリ２２が記憶しているラベルデータＬＡＢＥＬ１のなかから、鍵指定データＩｍが指定するラベルデータＬＡＢＥＬに対応する集合を和集合とする２つの集合に対応するラベルデータＬＡＢＥＬを特定する。
ステップＳＴ１３４：
処理部２３は、ステップＳＴ１３３で特定した２つのラベルデータＬＡＢＥＬを、必要に応じてメモリ２２に記憶されたラベルデータＬＡＢＥＬ１を基にそれぞれ生成する。
そして、処理部２３は、当該２つのラベルデータＬＡＢＥＬを、それぞれキーとして疑似乱数発生器Ｇを基に疑似乱数を発生させて、２つのサブセットキーＳＫを生成する。当該処理は、図１９〜図２４を基に前述したＬＳＤ方式の処理と同様である。
そして、処理部２３は、当該２つのサブセットキーＳＫを基に鍵暗号鍵データＫＥＫｍを生成する。
【０１０７】
ステップＳＴ１３５：
処理部２３は、ステップＳＴ１２４で特定したラベルデータＬＡＢＥＬを、必要に応じてメモリ２２に記憶されたラベルデータＬＡＢＥＬ１を基に生成する。
そして、処理部２３は、当該生成したラベルデータＬＡＢＥＬを、キーとして疑似乱数発生器Ｇを基に疑似乱数を発生させて、サブセットキーＳＫを生成する。
そして、処理部２３は、当該サブセットキーＳＫを鍵暗号鍵データＫＥＫｍとする。
【０１０８】
ステップＳＴ１３６：
処理部２３は、ステップＳＴ１２４で特定した鍵データＫ＿ＯＲＧ１ｍを、鍵暗号鍵データＫＥＫｍとする。
【０１０９】
以上説明したように、通信システム１では、上述したように、メインサーバ２によるサブサーバ３＿ｐのリボケーション処理を、前述した鍵取得方法ＲＬＫＨを基に行うため、システム全体を再構築することなく、指定したサブサーバ３＿ｐを効率的にリボークできる。
すなわち、通信システム１では、メインサーバ２が、リボークしないサブサーバ３＿ｐに予め設定されたリボークするサブサーバ３＿ｐが保持しないデータのうち、鍵取得方法ＲＬＫＨを基に取得した鍵暗号鍵データＫＥＫを生成するために用いる鍵データＫ＿ＯＲＧ１またはラベルデータＬＡＢＥＬを、リボークしないサブサーバ３＿ｐに指定データＩｍによって指定する。そのため、すなわち、通信システム１の再構築を行うことなく、リボークしないサブサーバ３＿ｐが新たな鍵暗号鍵データＫＥＫを取得できる。
【０１１０】
また、通信システム１では、上述したように、メインサーバ２が、予め決められた複数の鍵取得方法（例えば、前述した鍵取得方法ＳＫＴ−Ａ，ＳＫＴ−Ｂなど）のうち、所定のサブサーバ３＿ｐをリボーク（無効に）するために生じる、リボークにしないサブサーバ３＿ｐとの間の通信量が最少となる鍵取得方法を選択する。そして、メインサーバ２が当該選択した鍵取得方法を基に新たな鍵暗号鍵データＫＥＫを取得する。
そのため、通信システム１によれば、リボケーション処理に伴うメインサーバ２とリボークしないサブサーバ３＿ｐとの間の通信量を、前述したＣＳＴ方式に比べて少なくできる。
具体的には、当該通信量は、通信システム１の場合には、前述した式（２）に示すＯ（ＣＯＡ）と式（３）に示すＯ（ＣＯＢ）とのうち少ない方になり、ＬＳＤ方式およびＳＤ方式の場合（Ｏ（Ｒ））よりは多いが、ＣＳＴ方式の場合（Ｏ（Ｒｌｏｇ２Ｎ／Ｒ））より少なくできる。
【０１１１】
また、通信システム１によれば、サブサーバ３＿ｐに記憶される鍵データおよびラベルデータＬＡＢＥＬのデータ量（上記式（４）に示すＯ（ＳＴ））は、ＣＳＴ方式の場合（Ｏ（ｌｏｇ２Ｒ））よりは大きいが、ＳＤ方式およびＬＳＤ方式の場合（Ｏ（（ｌｏｇ２Ｎ）２），Ｏ（（ｌｏｇ２Ｎ）１＋ａ），ａ＞１）より少なくできる。
これにより、通信システム１によれば、リボケーション処理に伴うメインサーバ２とサブサーバ３＿ｐとの間の通信量と、サブサーバ３＿ｐが保持する鍵データのデータ量とを適切なトレードオフにより規定できる。
【０１１２】
また、通信システム１では、サブサーバ３＿ｐによる受信装置４＿ｐ（ｎ）のリボケーション処理についても、上述した鍵取得方法ＲＬＫＨを基に効率的に行うことができる。
また、通信システム１では、サブサーバ３＿ｐは、自らに対応するサブグループＳＵＢＧ＿ｐ内でのみ受信装置４＿ｐ（ｎ）のリボケーション処理を行うため、当該リボケーション処理により他のサブグループＳＵＢＧ＿ｐに影響を与えることはない。
【０１１３】
本発明は上述した実施形態には限定されない。
また、上述した実施形態では、本発明の複数の鍵取得方法として、２つの鍵取得方法ＳＫＴ−Ａ，ＳＫＴ−Ｂを例示したが、鍵取得方法の種類に特に限定されず、また、鍵取得方法の数も複数であれば特に限定されない。
例えば、本発明は、複数のサブサーバ３＿ｐが割り当てられたサブサーバ３＿ｐを含む第１の水平レイヤに対してＬＳＤあるいはＳＤ方式を適用し、鍵管理装置が割り当てられたルートを含む第２の水平レイヤに対してＣＳＴ方式を採用していれば、上記第１の水平レイヤと上記第２の水平レイヤとの間に、水平レイヤがなくても、単数または複数のレイヤがあってもよく、これらの水平レイヤに適用される鍵取得方法は任意である。
また、本発明では、例えば、図１に示す少なくとも一つのサブサーバ３＿ｐが、複数のサブ−サブサーバを管理し、各サブ−サブサーバが自らに割り当てられたサブ−サブグループ内の受信装置を管理してもよい。
【０１１４】
【発明の効果】
以上説明したように、第１の発明は、複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の第１の鍵管理装置と、当該複数の第１の鍵管理装置を管理する第２の鍵管理装置とを用いて通信を行う場合に、一部の前記第１の鍵管理装置を効率的に無効にできる第１の発明のデータ処理方法を提供することができる。
また、第２および第３の発明は、複数の受信装置のうち予め割り当てられた前記受信装置との間の暗号化通信に用いる鍵データをそれぞれ管理する複数の鍵管理装置のうち、一部の鍵管理装置を効率的に無効にできるプログラムおよびデータ処理装置を提供することができる。
また、第４および第５の発明は、第２および第３の発明における上記鍵管理装置に対応したプログラムおよびデータ処理装置を提供することができる。
【図面の簡単な説明】
【図１】図１は、本発明の実施形態に係わる通信システムの全体構成図である。
【図２】図２は、図１に示すサブグループの構成を説明するための図である。
【図３】図３は、図１に示すメインサーバのハードウェア構成図である。
【図４】図４は、図１に示すサブサーバのハードウェア構成図である。
【図５】図５は、図２に示す受信装置のハードウェア構成図である。
【図６】図６は、図１に示すメインサーバによるサブサーバのリボケーション処理を説明するための図である。
【図７】図７は、図１に示すサブサーバによる受信装置の加入解除処理を説明するための図である。
【図８】図８は、図１に示すサブサーバによる受信装置の加入解除処理を説明するための図７の続きの図である。
【図９】図９は、図１に示すメインサーバによる受信装置の加入処理を説明するための図である。
【図１０】図１０は、図１に示すメインサーバによる受信装置の加入処理を説明するための図９の続きの図である。
【図１１】図１１は、メインサーバによるペイロードデータのマルチキャスト処理を説明するための図である。
【図１２】図１２は、本発明の実施形態で採用される鍵取得方法の基礎となるツリー構造を説明するための図である。
【図１３】図１３は、本発明の実施形態で採用される鍵取得方法の処理を説明するためのフローチャートである。
【図１４】図１４は、本発明の実施形態で採用される鍵取得方法ＳＫＴ−Ａを説明するための図である。
【図１５】図１５は、本発明の実施形態で採用される鍵取得方法ＳＫＴ−Ｂを説明するための図である。
【図１６】図１６は、ＣＳＴ方式を説明するための図である。
【図１７】図１７は、ＣＳＴ方式を説明するための図である。
【図１８】図１８は、ＣＳＴ方式を説明するための図である。
【図１９】図１９は、ＳＤ方式を説明するための図である。
【図２０】図２０は、ＳＤ方式を説明するための図である。
【図２１】図２１は、ＳＤ方式を説明するための図である。
【図２２】図２２は、ＳＤ方式を説明するための図である。
【図２３】図２３は、ＬＳＤ方式を説明するための図である。
【図２４】図２４は、ＬＳＤ方式を説明するための図である。
【図２５】図２５は、図１に示す鍵管理装置が行う前処理を説明するためのフローチャートである。
【図２６】図２６は、図１に示す鍵管理装置が行うリボケーション処理を説明するためのフローチャートである。
【図２７】図２７は、図１に示す鍵管理装置が行うリボケーション処理を説明するための図２６の続きのフローチャートである。
【図２８】図２８は、本発明の実施形態の指定データを説明するための図である。
【図２９】図２９は、図１に示す鍵管理装置がリボークしないサブサーバ３＿ｐに送信するカプセルデータＣＡＰを説明するための図である。
【図３０】図３０は、図２６に示すステップＳＴ８４を説明するためのフローチャートである。
【図３１】図３１は、図２６に示すステップＳＴ８５を説明するためのフローチャートである。
【図３２】図３２は、図１に示すサブサーバ３＿ｐの動作例を説明するためのフローチャートである。
【図３３】図３３は、図３２に示すステップＳＴ１２６を説明するためのフローチャートである。
【符号の説明】
１…通信システム、２…メインサーバ、３＿ｐ…サブサーバ、４＿ｐ（ｎ）…受信装置、１０，２０，３０…バス、１１，２１，３１…通信部、１２，２２，３２…メモリ、１３，２３，３３…処理部
【図１】
2004328233.tif 000004
【図２】
2004328233.tif 000005
【図３】
2004328233.tif 000006
【図４】
2004328233.tif 000007
【図５】
2004328233.tif 000008
【図６】
2004328233.tif 000009
【図７】
2004328233.tif 000010
【図８】
2004328233.tif 000011
【図９】
2004328233.tif 000012
【図１０】
2004328233.tif 000013
【図１１】
2004328233.tif 000014
【図１２】
2004328233.tif 000015
【図１３】
2004328233.tif 000016
【図１４】
2004328233.tif 000017
【図１５】
2004328233.tif 000018
【図１６】
2004328233.tif 000019
【図１７】
2004328233.tif 000020
【図１８】
2004328233.tif 000021
【図１９】
2004328233.tif 000022
【図２０】
2004328233.tif 000023
【図２１】
2004328233.tif 000024
【図２２】
2004328233.tif 000025
【図２３】
2004328233.tif 000026
【図２４】
2004328233.tif 000027
【図２５】
2004328233.tif 000028
【図２６】
2004328233.tif 000029
【図２７】
2004328233.tif 000030
【図２８】
2004328233.tif 000031
【図２９】
2004328233.tif 000032
【図３０】
2004328233.tif 000033
【図３１】
2004328233.tif 000034
【図３２】
2004328233.tif 000035
【図３３】
2004328233.tif 000036