(57)【要約】  本発明は、最上位鍵と、任意選択で検証タグとを確立することを含む。最上位鍵は、ブロードキャスト・メディアを暗号化するＭＤＰ鍵として使われる。暗号化された最上位鍵を含む鍵メッセージの一部のみが、たとえば、署名またはメッセージ・アクセス・コード（ＭＡＣ）を使って認証される。ある階層の鍵の作成に基づく、公知のどのグループ鍵配布プロトコルも用いることができる。このような方法の例が、ＬＫＨおよびＳＤ法である。従来はＭＤＰ鍵として用いられていた、グループ鍵配布プロトコルの出力鍵Ｈまたはその派生物が、最上位ＭＤＰ鍵を暗号化するのに使われる。本発明は、更に、指定されたユーザグループまたはサブグループに関して、不必要なメッセージ構成要素を排除することによるグループ鍵メッセージの最適化を含む。最適化は、ユーザプロファイル、ネットワーク状況、またはオペレータポリシーなどのコンテキストデータに応じて行うことができる。
2007537656.tif 000002
【特許請求の範囲】
【請求項１】
識別可能なメッセージ要素を有するグループ鍵管理メッセージが、メディア復号鍵を決定するため受信者グループにブロードキャストされる階層グループ鍵配布プロトコルを改善する方法であって、
メディア保護のための最上位鍵を確立する工程と、
前記グループ鍵配布プロトコルの出力鍵の下で、前記最上位鍵を暗号化する工程と、
少なくとも前記暗号化された最上位鍵に対して、認証署名を適用する工程と、
前記暗号化された最上位鍵および前記認証署名を追加することによって、前記グループ鍵管理メッセージを変更する工程と、
前記変更されたグループ鍵管理メッセージを、ユーザグループのメンバにブロードキャストする工程とを有することを特徴とする方法。
【請求項２】
前記暗号化された最上位鍵および前記認証署名が、前記変更されたグループ鍵管理メッセージ中の同じメッセージ要素に含まれることを特徴とする請求項１に記載の方法。
【請求項３】
前記暗号化された最上位鍵および前記認証署名が、前記変更されたグループ鍵管理メッセージ中の異なるメッセージ要素に含まれることを特徴とする請求項１に記載の方法。
【請求項４】
前記最上位鍵の正当性の検証を可能にするための検証タグを生成する工程と、
前記グループ鍵管理メッセージに前記検証タグを更に追加する工程とを更に有することを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記暗号化する工程では、前記グループ鍵配布プロトコルの出力鍵から派生する暗号化鍵を用いることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記派生が一方向関数に基づくことを特徴とする請求項５に記載の方法。
【請求項７】
前記検証タグが、チェックサムを備え、
前記グループ鍵管理メッセージに前記検証タグを追加する前記工程は、前記暗号化された最上位鍵に前記チェックサムを連結する工程を含むことを特徴とする請求項４に記載の方法。
【請求項８】
前記検証タグが、前記暗号化された最上位鍵を介して計算されるＭＡＣコードを備え、
前記グループ鍵管理メッセージに前記検証タグを追加する前記工程では、前記暗号化された最上位鍵に前記ＭＡＣコードを連結する工程を含むことを特徴とする請求項４に記載の方法。
【請求項９】
前記ＭＡＣコードが、前記グループ鍵配布プロトコルの出力鍵から派生した鍵を使って計算されることを特徴とする請求項８に記載の方法。
【請求項１０】
前記グループ鍵配布プロトコルが、論理鍵階層プロトコル（ＬＫＨ: logical key hierarchy protocol）、部分集合差プロトコル（ＳＤ: subset difference protocol）、または階層部分集合差プロトコル（ＬＳＤ: layered subset difference protocol）であることを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記ブロードキャストする工程に先立って、メッセージの最適化が施行され、
前記メッセージの最適化では、
メディア鍵を決定する所与の受信者サブグループによって必要とされる、前記グループ鍵管理メッセージ中の要素を識別する工程と、
前記所与の受信者サブグループによって必要とされない要素を除外することによって、変更されたグループ鍵管理メッセージを作成する工程と、
前記変更されたグループ鍵管理メッセージをブロードキャストする工程とを更に含むことを特徴とする請求項１に記載の方法。
【請求項１２】
前記ブロードキャストする工程が、セルラー無線システムにおける指定されたエリア内で行われ、前記識別する工程が、前記指定されたエリア内で受信者サブグループに関して行われることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記受信者サブグループが、前記メディアを予め指定された品質で受け取ることができる受信者に更に制限されることを特徴とする請求項１１または１２に記載の方法。
【請求項１４】
前記品質が、少なくとも１つの伝送リンクの品質に関することを特徴とする請求項１３に記載の方法。
【請求項１５】
識別可能なメッセージ要素を有するグループ鍵管理メッセージが、いくつかのグループメンバにブロードキャストされる階層グループ鍵配布プロトコルを改善する装置であって、
メディア保護のための最上位鍵を確立する手段と、
前記グループ鍵配布プロトコルの出力鍵の下で、前記最上位鍵を暗号化する手段と、
少なくとも前記暗号化された最上位鍵に対して、認証署名を適用する手段と、
前記認証署名を有する前記暗号化された最上位鍵を追加することによって、前記グループ鍵管理メッセージを変更する手段と、
前記変更されたグループ鍵管理メッセージをブロードキャストする手段とを有することを特徴とする装置。
【請求項１６】
前記最上位鍵の正当性の検証を可能にするための検証タグを生成する手段と、
前記グループ鍵管理メッセージに前記検証タグを追加する手段とを更に有する特徴とする請求項１５に記載の機器。
【請求項１７】
前記暗号化する手段が、前記グループ鍵配布プロトコルの出力鍵から派生する暗号化鍵に基づいて動作することを特徴とする請求項１５又は１６に記載の装置。
【請求項１８】
メディア鍵を決定するために前記グループメンバの所与のサブグループによって必要とされる、前記グループ鍵管理メッセージ中の要素を識別する手段と、
前記所与のサブグループによって必要とされない要素を除外することによって、最適化されたグループ鍵管理メッセージを作成する手段と、
前記最適化されたグループ鍵管理メッセージをブロードキャストする手段とを更に有することを特徴とする請求項１５に記載の装置。
【請求項１９】
前記装置が、鍵サーバ内に実装されることを特徴とする請求項１５又は１６に記載の装置。
【請求項２０】
前記装置が、ネットワークノード中に実装されることを特徴とする請求項１５又は１６に記載の装置。
【請求項２１】
識別可能なメッセージ要素を有するグループ鍵管理メッセージを最適化する装置であって、
グループ鍵管理メッセージＭを受け取る手段（２１０）と、
いくつかの前記メッセージ要素をフィルタリングして取り除くための所与の最適化規則に従って、前記グループ鍵管理メッセージを変更する手段（２３０）と、
前記変更されたグループ鍵管理メッセージＭ’の出力用の手段（２５０）とを有することを特徴とする装置。
【請求項２２】
前記グループ鍵管理メッセージが、元来、通信ネットワーク内の受信者グループに関連し、
前記グループ鍵管理メッセージを変更する手段が、
グループ鍵を決定する前記受信者の所与のサブグループによって必要とされる、前記グループ鍵管理メッセージ中の要素を識別する手段と、
前記所与のサブグループによって必要とされない要素を除外することによって、前記変更されたグループ鍵管理メッセージを作成する手段とを有することを特徴とする請求項２１に記載の装置。
【請求項２３】
所与のサブグループによって必要とされる前記グループ鍵管理メッセージ中の要素を識別する手段が、グループ鍵配布プロトコルの論理構造を含みどのグループ鍵配布プロトコルが用いられるかについての情報、ならびに現時点で前記所与のサブグループ中にある受信者リストに基づいて、動作することを特徴とする請求項２２に記載の装置。
【請求項２４】
前記グループ鍵配布プロトコルの情報および前記受信者リストが、通信ネットワーク内の少なくとも１つのネットワーク要素から取得されることを特徴とする請求項２３に記載の装置。
【請求項２５】
ブロードキャストが、セルラー無線システム内の指定されたエリア内で行われ、前記所与の受信者サブグループが、現時点で、前記指定されたエリア内部にいる受信者として定義されることを特徴とする請求項２２又は２３に記載の装置。
【請求項２６】
前記メッセージが、元来、ユーザグループＮに向けられており、
前記グループ鍵管理メッセージが、
Ｍ＝｛Ｕij，Ｅ(ＨUij，^ＨUij）…Ｕkl，Ｅ(ＨUkl，^ＨUkl), …}, という形を有し、上式で、Ｕijが、用いられている階層グループ鍵配布プロトコルに依存する複合インデックス識別子であり、ＨUijが、暗号化関数Ｅにおいて使われる暗号化鍵であり、^ＨUijが、前記グループ鍵配布プロトコルに依存し、前記階層プロトコル内のレベルに対応する最終出力鍵又は次の暗号化鍵の暗号化であり、
前記最適化が、ユーザサブグループＲ⊂Ｎに無関係な要素Ｅ(ＨUij，^ＨUij）の消去を含むことを特徴とする請求項２１に記載の装置。
【請求項２７】
前記機器が、無線ネットワーク・コントローラ（ＲＮＣ: Radio Network Controller）、無線基地局（ＲＢＳ: Radio Base Station）、サービスＧＰＲＳサポートノード（ＳＧＳＮ: Serving GPRS Support Node）、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ: Gateway GPRS Support Node）、ボーダーゲートウェイ(Boder Gateway)、又は個人プロキシに配置されることを特徴とする請求項２１に記載の装置。
【請求項２８】
識別可能なメッセージ要素を有するグループ鍵管理メッセージを最適化する方法であって、
グループ鍵管理メッセージＭを受け取る工程と、
いくつかの前記メッセージ要素をフィルタリングして取り除くための所与の最適化規則に従って、前記グループ鍵管理メッセージを変更する工程と、
前記変更されたグループ鍵管理メッセージＭ’を出力する工程とを有することを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、安全なブロードキャストを復号して認証するメディア鍵を派生させるための鍵メッセージの配布に関し、詳細には、このようなメッセージの認証および最適化に関する。
【背景技術】
【０００２】
ブロードキャストおよびマルチキャストは、図１に概略的に示すように、無線アプリケーションおよび標準データ通信の両方のために、大きな受信者グループへのコンテンツの効率的な配布を可能にする。以下では、ブロードキャストという用語は、ブロードキャストおよびマルチキャストの両方を指すのに使われる。最近の取組みは無線ネットワークを介するブロードキャストに焦点を当てており、重要なテーマは、たとえばメディアアクセスのための時間を削減するのに、無線リンクをできるだけ効率的に用いることである。非常に関心がもたれている別のテーマは、安全なブロードキャストを提供することである。したがって、コンテンツの暗号化は、商用ブロードキャストサービスを実現する重要な要因である。ユーザの観点から見ると、認証は重要なテーマである。ユーザが、意図された当事者から発せられたコンテンツおよび暗号化鍵を検証できることが望ましい。
【０００３】
ブロードキャスト保護システムは、普通、いくつかの区別されたステップで動作する。通常、ユーザがサービスプロバイダへの同意をするサービス登録ステップが必要とされる。このステップで、ユーザは、個人用の一意の秘密鍵を与えられる。鍵配布ステップで、ブロードキャストコンテンツの復号用に、登録済みのユーザにメディア鍵が配布される。サービスプロバイダは、メディア配信保護ステップで、コンテンツを暗号化する。たとえば、新規ユーザが登録されるとき、ユーザが登録解除するとき、またはメディア鍵が危険にさらされるときには、コンテンツ鍵を更新するために、鍵変更ステップが必要とされる。定期的な鍵変更は、システムの安全性を向上させるのにも用いることができる。サービス登録は、通常、ユーザとコンテンツプロバイダの間の二点間であり、通信用の安全で認証されたどんな手段も用いることができる。鍵配布およびメディア配信保護（ＭＤＰ: media delivery protection）は、一対多の形で実行される。
【０００４】
鍵配布に伴う主な問題は、新規メンバがグループに参加するとき、または脱退するときに、大きなグループに拡張可能なやり方でＭＤＰ鍵を更新することである。各メンバ用に個別に暗号化された、更新されたＭＤＰ鍵を送る単純な手法は、うまく拡張できない。拡張性を向上させるために、たとえば、論理鍵階層（ＬＫＨ: Logical Key Hierarchy）、部分集合差（ＳＤ: Subset Difference）および階層化部分集合差（ＬＳＤ: Layered Subset Difference）という、グループ鍵配布プロトコルと呼ばれる方式が提案されている。これらは、階層化グループ鍵配布プロトコルの例である。
【０００５】
各階層化グループ鍵配布プロトコルには、関連付けられた暗号化鍵の集合がある。こうした鍵の配置および鍵の間の関係を示すために、抽象的な階層ツリーを使うことができる。図２は、メンバの集合、すなわちＭ１〜Ｍ８を最下部に示す階層ツリーを示す。階層の最上部には、この特定の階層プロトコルの出力鍵Ｋmがある。完全なメンバグループのサブグループが、階層ツリーのサブツリーを決定し、そのサブツリーが今度は識別可能なメッセージ要素の集合を有するグループ鍵管理メッセージを決定する。最下位と最上位のレベルとの間にある、ツリーモデル中のノードは、グループ鍵管理メッセージの要素の復号に必要とされる暗号化鍵に関連付けられる。各ユーザは、開始段階で、これらの鍵、たとえば特定のメンバＭiとＫmの間のパス上の全鍵の部分集合、を導くための情報を受け取る。階層化グループ鍵配布プロトコルは、線形の初期鍵設定性能(linear initial keying performance)および改良型の対数鍵変更性能(improved logarithmic re-key performance)を提供する。こうした方法は、その非線形的性能により、最も拡張しやすく、効率的なものである。
【０００６】
図２は、都合の良いことに、ＬＫＨ法を論じるのに用いることができる。ＬＫＨ法は、拡張可能なグループ鍵配布プロトコルであり、ツリー中のすべてのノード(i)を、鍵Ｋiに関連付ける手法に基づくものである。ここで、(i)は、１つまたはいくつかの次元のインデックスである。ルート鍵、すなわちＫmは、ツリーの最上位レベルに関連付けられた鍵であり、ＭＤＰ鍵として使われる。ユーザグループ中のすべてのメンバには、たとえば登録段階で個別の鍵が与えられ、こうした鍵は、ツリーの最下部の所のリーフＫ(rst)に関連付けられる。すべてのメンバは、そのリーフからルートまでのパス上にある鍵もすべて受け取る。
【０００７】
典型的なメッセージが、三重項(triplets)｛ｉ＞ｊ，［Ｋi]Ｋj｝から作られる。ここで、ｉ＞ｊは、ノードｉがノードｊに対する上位要素であることを示す。ｊが、ルートまでのパス上にある場合、メンバは、メッセージ部を復号することができる。すなわち、ノードｊに関連付けられた鍵Ｋjを使用することによって、Ｋiを取り出すことができる。したがって、Ｋiの集合は、ルート鍵Ｋmの階層暗号化を有する。ここで、ｉ＜ｍである。
【０００８】
メンバの参加または脱退を理由としてＭＤＰ鍵を更新する際、必要とされるメッセージの数はほんの少数であり、メッセージサイズもまた同様である。大きな欠点は、システムが状態所有型(state-full)または状態依存型(state-depedent)であること、すなわち、そのアルゴリズムでは、生成された新たなグループ鍵を暗号化するのに以前のグループ鍵が使用されることである。したがって、この方式には、状態の依存が必要とされる。ある状態に対するグループ鍵が失われている場合には、参加者は、あらゆる手段を尽くしても、セッションを捕捉し直すことが不可能である。
【０００９】
別の欠点は、バッチの鍵変更、すなわち鍵のバッチ更新のために与えられている方法が、特に参加者の変更が大きく瞬時に行われる際には、あまり効率的でないことである。
【００１０】
部分集合カバーアルゴリズム(Subset Cover algorithm)は、一般的クラスのグループ鍵配布プロトコルであり、グループメンバがメンバの部分集合に関連付けられ、部分集合が特定の鍵に関連付けられることを特徴とする。図３に示す部分集合差（ＳＤ）プロトコルは、こうしたプロトコルの一例である。図３を参照すると、ノードにはインデックスｊで番号をつけてある。図３には、例示的にノード２、３、５、１２を示してある。部分集合Ｓi,jの集合体は完全なグループをカバーし、全メンバからなる集合を明確に決定する。Ｓi,jは、ノードｉの下位ではあるがノードｊの下位ではないリーフの集合を示す。図３に、部分集合Ｓ2,5およびＳ3,12を示す。ＭＤＰ鍵を更新する際に、メンバグループは、こうした部分集合で正確にカバーされ、更新された鍵は、部分集合鍵それぞれの下で暗号化される。ＳＤ（部分集合差）方式は、状態をもたないグループ鍵配布プロトコルである。ＳＤ方式は、可能なメンバ(possible members)と同じだけ多くのリーフを有する２分木を生成する。すべての可能なメンバは、具体的なリーフに関連付けられる。すなわち、この瞬間にメンバではないユーザもリーフに関連付けられる。鍵サーバ（ＫS）は、エンティティＳi,jからなる集合Ｓを生成する。すべてのＳi,jは、部分集合Ｓi,jのすべてのメンバが計算できるが他のグループメンバは計算できない鍵Ｌijにも一意に関連付けられる。ＭＤＰ鍵は、Ｌijを使って暗号化することによって、特定の集合Ｓi,jに対し更新することができる。この更新は、Ｓに属するすべてのＳi,jに対して行われなければならないことに留意されたい。Ｌijは階層的に作成されており、そこではノードｉに関連付けられた乱数種が一方向関数を繰り返し用いて複数ノードｊ＞ｉに拡張される。
【００１１】
ＬＳＤ（階層部分集合差）方式はＳＤ方式であるが、すべての可能なメンバが元の方式におけるよりも少ない鍵を格納する必要があるような、特殊な階層を有している。全てのこうしたシステムにおいて、全ユーザにブロードキャストされるグループ鍵管理メッセージはかなり大きいものであり、認証される必要がある。ユニキャストでは、認証を与えるのに共有の秘密鍵であるメッセージ認証コード（ＭＡＣ: message authentication code）が使われる。ブロードキャストでは、グループ鍵（ＭＤＰ）が共有の秘密鍵を提供するが、この鍵を用いたメッセージ認証の実施は、送信者がグループのメンバであることを検証するだけであり、意図されたソースであることは必ずしも検証しない。この単純な手法は、当然ながら、メッセージをメッセージ認証コードまたは署名を使っているものとして認証するものであろう。このブロードキャストメッセージの全体を認証する単純な手法では、グループ鍵管理メッセージの一部のビットエラーやパケット紛失が、必ず認証の失敗を引き起こしてしまう。
【００１２】
この単純な手法は、資源も消費し、計算コストおよび帯域幅消費の両方を増大させてしまう。
【００１３】
別の手法は、暗号化された各鍵を認証することであろう。この手法も、資源を消費する（計算および帯域幅の両方を消費する）ことがわかっている。事実、ＳＤでの暗号化されるＭＤＰ鍵の数は、最大でもｍｉｎ(2r-1, n/2, n-r)である。ここで、ｎはメンバの総数であり、ｒは取り消されたメンバの数である。
【００１４】
特許文献１は、ユーザグループの部分集合のカバーに基づく、状態をもたない階層方法を開示している。
【００１５】
鍵管理メッセージのサイズは、大きいグループでは非常に大きくなる傾向にある。したがって、鍵管理メッセージのブロードキャストをできるだけ効率的にするために、様々な試みが行われてきた。
【００１６】
非特許文献１は、ユーザが危険にさらされる確率に応じてユーザを配置し、そうすることによって、鍵管理システムの効率の改善を可能にする方法を開示している。
【００１７】
非特許文献２は、ＭＤＰ鍵の認証を開示している。しかし、この解決方法の拡張可能性は、本発明によって得られるものよりも好ましくない。更に、非特許文献２による解決方法は、ユーザが、署名を検証するために鍵管理メッセージ全体を取得する必要があるので、効果的な最適化を可能としない。
【００１８】
非特許文献３は、認証を導入するために、ＬＫＨ法に適用される方式を開示している。開示されている方式は、ハッシュチェーンがツリー中で各鍵を生成するという原理に基づく。グループメンバが新たな鍵を受け取ると、新たな鍵を上書きするハッシュの計算、および古い鍵とのハッシュの比較によって、その正当性を検証することができる。この方法は、小さいオーバーヘッドしか生じないが、実際に使用することは現実的でない。というのは、ＬＫＨに基づく鍵変更およびその認証は、その後、ハッシュチェーンの長さに等しい限られた回数だけしか適用できないからである。更に、鍵サーバは、必要とされたとしても、鍵を自力で生成することが不可能である。
【００１９】
上述したように、グループ鍵管理メッセージは、ユーザグループが増加すると非常に大きくなる。このようなメッセージを、セルラーネットワークを介して頻繁にマルチキャストし、またはブロードキャストすると、資源を非常に消費することになる。どの当事者が、メッセージを伝送するのに必要とされる高価な無線リンク資源に資金を供給するのか、疑問もある。
【００２０】
特許文献２及び非特許文献４は、各エンティティが完全なグループのサブグループを管理する、エンティティからなる分散型システムを助言している。各サブグループは、更に、別個のグループ鍵に関連付けられる。こうしたシステムは、拡張しやすさをもたらすが、複雑かつ高価になる。
【００２１】
引用した方法に伴う別の問題は、別のエンティティへのセキュリティ機能の分散に関連し、このような別のエンティティは、セキュリティ機能を安全に扱い、ユーザの認証および承認を扱えるようにも信頼されなければならない。これにより、このようなシステムはより危険にさらされる。その結果、このようなシステムは、鍵または他の秘密情報を任せることができないエンティティにより行われる、最適化を管理しない。
【００２２】
したがって、従来技術によるシステムの欠点を克服する、ブロードキャストシステムおよびマルチキャストシステムにおける、グループ鍵配布のための効率的な信頼できる方法が必要である。具体的には、ＭＤＰ鍵の認証を与え、同時にメッセージの最適化を可能にする方法が必要である。好ましくは、最適化は、使われるいずれの鍵についても知る必要なしに、可能でなければならない。
【特許文献１】国際特許出願ＷＯ−２００２６０１１６（ＬＯＴＳＰＩＥＣＨ  Ｊ  Ｂ；ＮＡＯＲ  Ｄ；ＮＡＯＲ  Ｓ）
【非特許文献１】Ｐｒｏｂａｂｉｌｉｓｔｉｃ  Ｏｐｔｉｍｉｚａｔｉｏｎ  ｏｆ  ＬＫＨ−ｂａｓｅｄ  Ｍｕｌｔｉｃａｓｔ  Ｋｅｙ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｓｃｈｅｍｅｓ、Ａ．Ｓｅｌｃｕｋら、Ｉｎｔｅｒｎｅｔ  ｄｒａｆｔ  Ｊａｎｕａｒｙ  ２０００、ｈｔｔｐ：／／ｗｗｗ．ｓｅｃｕｒｅｍｕｌｔｉｃａｓｔ．ｏｒｇ／ｄｒａｆｔ−ｓｅｌｃｕｋ−ｐｒｏｂａｂｉｌｉｓｔｉｃ−ｌｋｈ−００．ｔｘｔ
【非特許文献２】Ｓｅｃｕｒｅ  Ｇｒｏｕｐ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｕｓｉｎｇ  Ｋｅｙ  Ｇｒａｐｈｓ、Ｃ．Ｋ．Ｗｏｎｇら  ｈｔｔｐ：／／ｗｗｗ．ｃｓ．ｕｔｅｘａｓ．ｅｄｕ／ｕｓｅｒｓ／ｌａｍ／Ｖｉｔａ／ＡＣＭ／ＷＧＬ９８．ｐｄｆ
【非特許文献３】Ａ  Ｒｅｌｉａｂｌｅ  Ｋｅｙ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｓｃｈｅｍｅ  ｆｏｒ  Ｓｅｃｕｒｅ  Ｍｕｌｔｉｃａｓｔ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、Ｒ．Ｄｉ  Ｐｉｅｔｒｏら、ｈｔｔｐ：／／ｃｅｓａｒｅ．ｄｓｉ．ｕｎｉｒｏｍａｌ．ｉｔ／Ｓｉｃｕｒｅｚｚａ／ｄｏｃ／ｓｒｄｓ２００３．ｐｄｆ
【特許文献２】米国特許第５７４８７３６号
【非特許文献４】Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  ｆｏｒ  Ｓｅｃｕｒｅ  Ｍｕｌｔｉｃａｓｔ  Ｇｒｏｕｐ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｉｎ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋｓ、Ｔ．Ｋｏｓｔａｓら、ｈｔｔｐ：／／ｎｅｖｅｌｅｘ．ｃｏｍ／ｄｏｗｎｌｏａｄｓ／ｄｉｓｃｅｘ．ｐｄｆ
【発明の開示】
【発明が解決しようとする課題】
【００２３】
本発明は、従来技術による機器の上記欠点および他の欠点を克服する。
【００２４】
本発明の全体的な目的は、ブロードキャスト保護システムにおけるグループ鍵配布のための効率的な方法を提供することである。
【００２５】
本発明の他の目的は、堅牢性および拡張しやすさを犠牲にすることなく、ブロードキャスト保護システムにおいて認証を与えることである。
【００２６】
更に他の目的は、安全性を損なうことなく、グループ鍵管理メッセージのサイズを大幅に削減することである。
【００２７】
本発明の更に他の目的は、認証を、パケット紛失およびビットエラーに耐えるようにすることである。
【００２８】
更に他の目的は、安全なグループ鍵配布システムにおいて必要とされる暗号計算に関連した計算オーバーヘッドを削減することである。
【００２９】
本発明の更に他の目的は、ブロードキャストグループの各メンバまたはメンバの部分集合に、ＭＤＰ鍵を計算する完全な鍵メッセージの必要な一部のみを含むグループ鍵管理メッセージを提供することである。
【課題を解決するための手段】
【００３０】
こうした目的および他の目的は、添付の特許請求の範囲によって定義される本発明によって満たされる。
【００３１】
簡潔には、本発明は、メディア保護のための最上位鍵を確立すること、および使われるグループ鍵配布プロトコルの出力鍵の下で、最上位鍵を暗号化することを伴う。次に、認証署名が、少なくとも暗号化された最上位鍵に対して適用される。暗号化された最上位鍵および認証署名を追加すると、グループ鍵管理メッセージが変更される。変更されたグループ鍵管理メッセージは、次いで、ユーザグループのメンバにブロードキャストされる。
【００３２】
この場合、暗号化された最上位鍵のみの認証が開始され、そうすることによって、メッセージサイズの過度の増大を回避し、高い障害耐性を保証する。更に、新たな最上位鍵の導入は、暗号化された複数のメディア鍵を作成する特定のプロトコルに反して、暗号化されたただ１つのメディア保護鍵が存在するのを保証するために用いることができる。
【００３３】
暗号化された最上位鍵および認証署名は、設計選択の問題として、変更されたグループ鍵管理メッセージ中の同じメッセージ要素にも異なるメッセージ要素にも含めることができる。
【００３４】
所望されあるいは適切な場合には、暗号化された最上位鍵の正当性の検証を可能にするため、グループ鍵管理メッセージに検証タグを追加してもよい。
【００３５】
本発明は概して、たとえば論理鍵階層プロトコル（ＬＫＨ）、部分集合差プロトコル（ＳＤ）、および階層部分集合差プロトコル（ＬＳＤ）などのプロトコルに適用可能である。
【００３６】
本発明の別の態様は、識別可能なメッセージ要素を備えるグループ鍵管理メッセージの最適化に関する。本発明のこの最適化の態様は、いくつかの前記メッセージ要素をフィルタリングして取り去り、変更されたグループ鍵管理メッセージＭ’を出力するための、所与の最適化規則によるグループ鍵管理メッセージＭの変更に基づく。
【００３７】
たとえば、グループ鍵管理メッセージは、元来、受信者グループに関連し得る。それに次いで、受信者の所与のサブグループを検討する好ましい実現形態では、グループ鍵管理メッセージの変更または最適化は、好ましくは、グループまたはメディア鍵を決定するサブグループによって必要とされるグループ鍵管理メッセージ中の要素の識別を伴う。サブグループによって必要とされない要素を除外すると、最終的に、変更されたグループ鍵管理メッセージが作成される。
【発明の効果】
【００３８】
本発明は、以下の利点をもたらす。
・パケット紛失およびビットエラーに耐えるグループ鍵管理メッセージ認証。
・グループ鍵管理メッセージの最適化と共に用いることができる認証方法。
・グループメンバは、グループ鍵管理メッセージの各部を暗黙的に認証することができる。
・安全性を損なうことのない、メッセージサイズの劇的な削減。
・メッセージサイズの削減による、端末に対するより少ない計算負荷。
【００３９】
本発明の実施形態の以下の説明を読むと、本発明によってもたらされる他の利点が理解されよう。
【発明を実施するための最良の形態】
【００４０】
本発明は、上記以外の目的および利点と共に、以下の説明を添付の図面と合わせて参照することによって最もよく理解されよう。図面を通して、同じ参照符号は、対応するまたは同様の要素に対して使われる。
【００４１】
図４に概略的に示すように、本発明の第１の態様は、一般にＭＤＰ鍵として使われる最上位鍵を有する新たな抽象階層の導入に関する。新たな抽象階層を、例示的な基本プロトコルＬＫＨおよびＳＤそれぞれの上位に示す。
【００４２】
図５は、本発明の本態様の好ましい基本的な実施形態の概略フローチャートである。
【００４３】
ステップＳ１で、（たとえば、メディア保護のための）新たな最上位鍵が確立される。ステップＳ２で、最上位鍵は、好ましくは、用いられる特定のグループ鍵配布プロトコルの出力鍵の下で暗号化される。次に、ステップＳ３で、少なくとも暗号化された最上位鍵に、認証署名が適用される。ステップＳ４で、グループ鍵管理メッセージは、たとえば変更されたグループ鍵管理メッセージ中の同じメッセージ要素中または異なるメッセージ要素中にある、暗号化された最上位鍵および認証署名を追加することによって変更される。次いで、ステップＳ５で、変更されたグループ鍵管理メッセージは、ユーザグループのメンバにブロードキャストされる。
【００４４】
暗号化された最上位鍵のみが認証されると、メッセージサイズの過度の増大が回避され、高い障害耐性が保証される。更に、新たな最上位鍵の導入は、暗号化された複数のメディア鍵を作成する、従来技術によるいくつかのプロトコルとは明らかに対照的に、暗号化されたただ１つのメディア保護鍵が存在することを保証するためにも用いることができる。
【００４５】
後で詳しく説明するように、グループ鍵管理メッセージに追加される検証タグを生成して、暗号化された最上位鍵の正当性の検証を可能にすることが有益であり得る。
【００４６】
次に、本発明の第１の態様を、本発明の例示的ないくつかの実施形態を参照して、より詳しく説明する。
【００４７】
本発明の例示的な第１の実施形態は、最上位鍵と任意選択で検証タグとを確立することを伴う。最上位鍵は、ブロードキャストメディアを暗号化するＭＤＰ鍵として使われる。暗号化された最上位鍵を含む鍵メッセージＭの一部のみが、たとえば署名やメッセージ・アクセス・コード（ＭＡＣ: Message Access Code）を使って認証される。次いで、鍵の階層の作成に基づく公知のどのグループ鍵配布プロトコルＰも用いられる。このような方法の例が、ＬＫＨおよびＳＤ法である。プロトコルＰは、従来はＭＤＰ鍵として使われている出力鍵Ｈを有する。しかし、本発明によると、前記鍵Ｈまたはその派生物は、今度は、最上位ＭＤＰ鍵を暗号化するのに使われる。
【００４８】
最上位鍵の正当性の検証が所望される場合は、検証タグが使われる。所望されない場合は、検証タグは省略してよい。
【００４９】
グループ鍵管理メッセージを受け取るメンバは、メッセージ全体を正しく受け取る必要はなく、新たな鍵を計算するのに必要とされる一部のみを受け取ればよい。最上位鍵ＫSと、ＫSおよび可能性としては出力鍵Ｈに依存する特殊な検証タグＶＴとを導入することによって、暗黙の階層を用いる認証機構が開示される。したがって、検証タグは、概してＶＴ（Ｈ，ＫS）と示される。最上位鍵ＫSおよび検証タグＶＴは、例示的にデジタル署名を使って認証される。更に、最適化方法が鍵配布方法と合わせて適用され、安全性を損なうことなく、鍵メッセージのサイズを更に削減することを可能にする。
【００５０】
ブロードキャストまたはマルチキャストのための全グループ鍵配布プロトコルは、グループ鍵管理メッセージ全体が全グループメンバに送られることを特徴とする。正確なメッセージは、用いられるプロトコルＰに依存する。以下では、プロトコルＰは、Ｕijがインデックス識別子である鍵ＨUijの論理階層によって特徴付けられる階層プロトコルと仮定される。例示的に、図２を参照すると、ｉは、一定の階層レベルに関連付けられた複合インデックス（０，１）でよく、ｊ＝０または１である。したがって、Ｕij＝（０，１；０）または（０，１；１）は、前記一定のレベルのすぐ下位の階層レベルと結び付く。複合インデックス識別子Ｕijの正確な意味は、プロトコルＰに依存する。
【００５１】
本発明をよりよく理解するために、グループ鍵管理メッセージの一般化された構造を、以下のように定義することができる。
【００５２】
【数１】
2007537656.tif 000003
【００５３】
この式で、ＨUijは、暗号化関数Ｅ中で使われる暗号化鍵であり、用いられるプロトコルＰに依存する^ＨUijは、最終出力鍵Ｈ、または階層プロトコル中のレベルに対応する次の暗号化鍵を暗号化したものである。一部のプロトコル、たとえば部分集合カバープロトコルでは、暗号化された鍵^ＨUijはＵijに依存せず、したがって、全^ＨUijが同じでありＨに等しい。ＬＫＨなど、他のプロトコルは、たとえば、リンクされたチェーンを形成するために、要素Ｅ（ＨUij, ^ＨUij）の間の依存を導入する。概して、各ユーザには、Ｈ鍵の復号を可能にするいくつかの暗号化鍵ＨUijが与えられる。特定のプロトコルＰに応じて、復号用に使うための鍵を決定する方法は、当該分野において公知であるように変わる。インデックスＵ＝Ｕmnによって識別される、メッセージの少なくとも１つの暗号化部は、プロトコル出力鍵Ｈ＝ＨUmnを含む。
【００５４】
図４に関連して前述したように、本発明は、新たな抽象階層およびＭＤＰ鍵として使われる最上位鍵ＫSを導入する。図４で、新たな抽象階層を、例示的な基本プロトコルＬＫＨおよびＳＤそれぞれの上位に示す。したがって、図４で、ＬＫＨのルート鍵Ｋrootはプロトコル出力鍵Ｈであり、ＳＤのケースではＨ＝ＫMである。最上位鍵ＫSは、メッセージ集合Ｍに追加され、特定のプロトコルＰ用のプロトコル出力鍵Ｈの下で暗号化される。したがって、Ｈは、ＫS：Ｅ（Ｈ，ＫS）を暗号化する。ＫSの導入は、暗号化された複数のＭＤＰ鍵を作成するいくつかのプロトコルに反して、暗号化されたただ１つのＭＤＰ鍵が存在することを保証する。好ましくは、暗号化された鍵ＫSのみが直接認証され、そうすることによって、メッセージサイズの過度の増大を回避し、同時に、高い障害耐性を保証する。認証はＰＦ（Ｈ，ＫS）で示され、ＰＦは、たとえば、署名サーバによって秘密鍵を使って作られた署名を伴う、何らかの保護関数を示す。関数ＰＦの正確な性質は、後に続く実施形態例においてより明らかになるように、用いられるプロトコルＰに依存する。グループメンバは、たとえば初期登録段階の一部として、適切などの通信を介しても、対応する公開鍵を受け取ることができる。要素Ｅ（ＨUij, ^ＨUij）のリンクされたチェーンを有するプロトコルのケースでは、ＫSはＭの中の鍵チェーン中の最後の鍵であり、ＫSの認証は次いで、鍵チェーン全体の信頼性を保証する。上で導入された鍵メッセージの一般化された構造によると、本発明による鍵メッセージは、以下のように見える。
【００５５】
【数２】
2007537656.tif 000004
【００５６】
異なる部分Ｅ（ＨUij, ^ＨUij）の間の連鎖依存のケースでは、メッセージＭ＝｛Ｕij，Ｅ(ＨUij，^ＨUij）…Ｕkl，Ｅ(ＨUkl，^ＨUkl), Ｕ，ＰＦ(Ｈ，ＫS)｝中の暗号化されたＫSは、正しいものであることを検証することができない。どの一部｛Ｕkl, Ｅ(ＨUkl, ^ＨUkl)}の中のエラーも、依然として鍵の派生を可能にするが、この鍵は鍵ＫSに関連せず、その正当性を検証することができない。上述したように、暗号化されたＫSの正当性を検証するために、検証タグを導入することもできる。
【００５７】
例示的な第１の実現形態において、検証タグは、暗号化された鍵ＫSの関数ｆを備える。たとえば、関数ＰＦは、ＰＦ＝｛Ｅ（Ｈ，ＫS＋ｆ（ＫS）），Sign［Ｅ（Ｈ，ＫS＋ｆ（ＫS））］｝という形をもつ。演算（＋）は、一般に、２つのオペランドの連結を示す。関数ｆは公開されており、たとえば上述した初期登録段階で、メンバ端末と共有される。例示的には、関数ｆはその引数のチェックサムである。
【００５８】
本実施形態による最終メッセージは次いで、以下のように見える。
【００５９】
【数３】
2007537656.tif 000005
【００６０】
図６は、メッセージＭを生成するプロセスを示すフローチャートである。
【００６１】
Ｓ１１で、最上位鍵が最初に作成される、または予め計算された鍵の集合から選択される。Ｓ１２で、検証タグが、選択された最上位鍵と連結される。Ｓ１３で、ステップＳ１２の結果が、選択された鍵配布プロトコルの出力鍵を使って暗号化される。Ｓ１４で、認証署名が、少なくともステップＳ１３の結果に適用される。ステップＳ１５で、ステップＳ１３およびＳ１４の結果が、グループ鍵管理メッセージに追加される。生成されたグループ鍵管理メッセージは、最終的に、ステップＳ１６でブロードキャストされる。
【００６２】
図７は、本発明の好ましい実施形態による、グループ鍵管理メッセージの作成のための鍵サーバノードの例示的な機器を示す。
【００６３】
鍵サーバノード１００は、基本的に、選択された階層グループ鍵配布プロトコルを実装するユニット１０、最上位鍵エンジン２０、暗号化ユニット３０、認証タグユニット４０、任意選択の検証タグユニット５０、グループ鍵メッセージ生成部／変更部６０、およびユーザデータベース７０を備える。
【００６４】
最上位鍵エンジン２０は、最上位鍵を生成する。この鍵は、好ましくは、検証タグを生成して連結する任意選択の検証タグユニット５０に転送される。検証タグユニット５０からの出力は、暗号化ユニット３０に与えられる。暗号化ユニット３０において使われる暗号化鍵は、ユニット１０に実装された従来技術による階層グループ鍵配布プロトコルの使用によって受け取られる出力鍵である。暗号化ユニット３０からの出力は、認証タグの生成のために、グループ鍵メッセージ生成部／変更部６０および認証タグユニット４０に与えられる。認証タグユニット４０は、例示的に、鍵ペアを生成し、秘密鍵を使って暗号化ユニット３０から受け取った出力に署名する。認証タグユニット４０から出力された認証タグも、グループ鍵メッセージ生成部６０に入力される。グループ鍵メッセージ生成部６０は、階層グループ鍵配布プロトコル１０から取得された元のメッセージに基づいて、好ましくは、少なくとも１つのユーザグループ中の受取りユーザの組織についてのデータベース７０にある情報を用いることによって、変更されたグループ鍵メッセージを生成する。グループ鍵メッセージは、その後、メッセージをブロードキャストする少なくとも１つの装置に送られる。
【００６５】
例示的な第２の実現形態において、検証タグは、メッセージ・アクセス・コード（ＭＡＣ）の計算に基づく。ＰＦ（Ｈ，ＫS）を計算する詳細な方法は、以下のステップを含む。
【００６６】
１．  一方向関数、たとえば擬似乱数関数Ｆと、１つの暗号化鍵ＫEと、Ｈ＝ＨUmnからの１つの認証鍵ＫAとを使って、プロトコルＰに対する出力鍵を作成する。
【００６７】
２．  ＫEを使ってＫSを暗号化する。すなわち、Ａ＝Ｅ(ＫE，ＫS）
３．  ２の結果にＭＡＣを適用することによって、検証タグを生成する。すなわち、Ｂ＝ＭＡＣ(ＫA，Ａ）
４．  ＡおよびＢに対して署名を適用する。すなわち、Sign(Ａ＋Ｂ）
５．  最終結果は、したがって、ＰＦ（Ｈ，ＫS）＝｛Ｅ(ＫE，ＫS), ＭＡＣ(ＫA，Ｅ(ＫE，ＫS))，Sign(Ｅ(ＫE，ＫS）＋ＭＡＣ(ＫA，Ｅ(ＫE，ＫS)))｝となる。
【００６８】
繰り返しになるが、演算（＋）は一般に連結を示す。ここでは、たとえば、復号されたプロトコル出力鍵Ｈから鍵ＫEおよびＫAをユーザが派生することを可能にする初期登録段階で、関数Ｆが複数のユーザと共有されると仮定される。グループメンバの端末は、一般的な形（Ｅｑ１）のメッセージを受け取ると、端末に向けられた情報を収集し、与えられた鍵ＨUijの集合を使って、端末の中で鍵を復号する。このプロセスの間、ＰＦ（Ｈ，ＫS）部に達すると、ＭＤＰ鍵ＫSが復号され、その正当性および信頼性が、メッセージの付加されている検証および認証部を調べることによって検証される。
【００６９】
より完全な理解のために、所与の例示的な実現形態のより詳細なステップの例を、以下で説明する。
【００７０】
再度、本発明の例示的な第１の実現形態を検討すると、詳細なステップは、たとえば以下のように定義することができる。
【００７１】
１．  メンバ端末が、メンバに向けられた要素のみを含むＭの部分集合Ｍ’＝｛Ｕij，Ｅ(ＨUij，^ＨUij）…Ｕkl，Ｅ(ＨUkl，^ＨUkl), Ｕ，ＰＦ(Ｈ，ＫS)｝を識別する。すなわち、Ｍ’中の各｛Ｕij, Ｅ(ＨUij, ^ＨUij)}が、メンバに向けられる。
【００７２】
２．  一般的な階層方法によると、メンバ端末は、集合Ｍ’中の１つの構成要素｛Ｕij, Ｅ(ＨUij, ^ＨUij)}を突き止める。この集合に対して、メンバ端末は、Ｅを復号して^ＨUijを見つける鍵ＨUijを有する。
【００７３】
３．  構成要素｛Ｕij, Ｅ(ＨUij, ^ＨUij)}が集合Ｍ’から取り除かれ、ステップ２が、現在の鍵ＨUijとして^ＨUijを使って繰り返される。
【００７４】
４．  Ｍ’が｛Ｕ，ＰＦ（Ｈ，ＫS）｝のみを含むとき、ループ式プロセスを終了する。
【００７５】
５．  ここで、Ｍ’＝｛Ｕ，ＰＦ（Ｈ，ＫS）｝および復号された最後の鍵^ＨUijはここでは、Ｈになる。ＰＦ(Ｈ，ＫS）＝｛Ｅ(Ｈ，ＫS＋ｆ(ＫS)), Sign［Ｅ(Ｈ，ＫS＋ｆ(ＫS))］｝とすると、メンバ端末は次いでＫS＋ｆ(ＫS）を復号し、関数ｆを使って検証タグｆ(ＫS）を検証することができる。
【００７６】
６． ステップ５が成功した場合、メンバ端末は、次に、サーバ公開鍵を使ってソースを認証するために、署名Signを検証する。
【００７７】
ステップ２での各復号が正しく行われ、すなわち暗号化チェーン中の各鍵が正しく取得されるとすると、ＫS＋ｆ(ＫS）が正しく取り出され、検証タグは、全鍵が正しく取り出されているという暗黙の検証を与えることに気づかれたい。どの鍵も正しく復号されていないと、検証タグは失敗となる。
【００７８】
発明の例示的な第２の実現形態における対応する詳細なステップは、たとえば以下のように定義することができる。
【００７９】
１．  第１の実施形態の第１の態様のステップ１〜４は、メンバ端末がその復号鍵Ｈをもっている｛Ｕ，ＰＦ(Ｈ，ＫS）｝を取得するために同じやり方で実行される。
【００８０】
２．  鍵ＫEおよびＫAは、関数Ｆを使ってＨから派生される。
【００８１】
３．  メディア鍵ＫSは、派生される鍵ＫEを使って、Ｅ(ＫE，ＫS）を復号することによって、メッセージ要素ＰＦ(Ｈ，ＫS）＝｛Ｅ(ＫE，ＫS), ＭＡＣ(ＫA，Ｅ(ＫE，ＫS)), Sign(Ｅ(ＫE，ＫS）＋ＭＡＣ(ＫA，Ｅ(ＫE，ＫS)))｝から派生される。
【００８２】
４．  正当性および信頼性の検査は、鍵ＫAおよびＭＡＣを使って行われ、署名、すなわちSignは、サーバ公開鍵を使って、ソースを認証するために検証される。
【００８３】
本発明の別の態様では、それ以上の、全般的に適用可能なメッセージの最適化が、上の認証方式の堅牢性を損なうことなく実現される。上で与えられたメッセージの一般的な形
【００８４】
【数４】
2007537656.tif 000006
【００８５】
、または、より具体的には、
【００８６】
【数５】
2007537656.tif 000007
【００８７】
を、再度検討する。
【００８８】
メッセージＭおよび受取りメンバＮの部分集合Ｒ⊂Ｎが与えられると、最適化方法は概して、以下のように実行される。
１  新規メッセージＭ’＝Φを作成する。
２  メンバｐn∈Ｒに向けられては、各｛Ｕij, Ｅ(ＨUij, ^ＨUij)}∈Ｍごとに、Ｍ’に｛Ｕij, Ｅ(ＨUij, ^ＨUij)}を追加し、そうでなく
【００８９】
【数６】
2007537656.tif 000008
【００９０】
の場合は破棄する（最適化規則）。
３  ＭをＭ’で置き換える。
【００９１】
事実上、このことは、部分集合またはサブグループＲによって必要とされないメッセージ要素は、グループ鍵管理メッセージから効果的にフィルタリングで取り去られ、または除外されることを意味する。
【００９２】
この方法は、受取りグループＮの部分集合Ｒ⊂Ｎに関して、最適化を行う。本方法は、たとえば、グループメンバと鍵サーバ、すなわちＫSの間のパス中のどこに配置された最適化プロキシサーバＯｐｓ内でも実装することができる。
【００９３】
図１１は、例示的なＯｐｓサーバ、およびＷＣＤＭＡモバイル通信システム用に一般的なネットワーク・ノードＲＮＣ、ＳＧＳＮまたはＧＧＳＮ内での、サーバの可能な場所を示す。
【００９４】
適切な他のネットワークノードは、ＲＢＳノード、ボーダー・ゲートウェイおよび個人プロキシ・ユニットを含み得る。しかし、本発明は無線アプリケーションに限定されず、たとえばインターネット・サービス・アプリケーションに適用可能であることが理解されるべきである。一般的な方法のステップ２で、Ｏｐｓサーバは、階層プロトコルの構造を知り、したがって、メッセージ要素が、受取りグループのメンバに向けられているかどうか判定することができる。判定のための正確な手順は、後で更に論じるように、用いられるプロトコルに依存する。ただし、本方法は、プロトコルにおける秘密鍵についてのいかなる情報も、他の秘密情報も要求することなく、Ｏｐｓが適用可能であることに気づかれたい。ステップ２での、情報を破棄するという決定は、鍵管理メッセージ、すなわちＵijの暗号化されていない一部に対してのみ行うことができる。サーバＯｐｓは、個人プロキシ・サーバ内に配置してもよい。メッセージＭがＯｐｓサーバに入力され、Ｏｐｓ出力の所で縮小されたメッセージＭ’として現れるように最適化される。
【００９５】
前述した認証方法が用いられると、この方法を適用した後、メンバｐn⊂Ｒは依然として、信頼性を検証できることが留意されるべきである。これは、最適化方法が、Ｒのメンバに向けられていないメッセージのみを破棄し、メンバは依然として、ＫSを取り出すことができるおかげである。しかし、本発明のこの最適化態様は、新たな最上位鍵の有無に関わらず、適用可能であることが留意されるべきである。
【００９６】
本発明の最適化態様の例示的な第１の実施形態によると、プロトコルＰは、ＬＫＨプロトコルである。Ｈは、ＬＫＨに基づくプロトコルのルート鍵であると仮定される。最適化は好ましくは、以下のように行われる。
【００９７】
１．  グループ鍵管理メッセージＭ＝｛Ｕij，Ｅ(ＨUij，^ＨUij）…Ｕkl，Ｅ(ＨUkl，^ＨUkl), Ｕ，ＰＦ(Ｈ，ＫS)｝を取り出す。上式で、Ｕijは、暗号化関数Ｅで使われる暗号化鍵（Ｈij）に対する識別子を示し、（^Ｈij)は、暗号化された鍵である。
【００９８】
２．  新たなＭ’＝Φを作成する。
【００９９】
３．  ｐn∈Ｒに向けられる各｛Ｕij, Ｅ(ＨUij, ^ＨUij)}∈Ｍに対して、すなわち、ノードＵijが、メンバとルートの間のパス上にある場合、｛Ｕij, Ｅ(ＨUij, ^ＨUij)}をＭ’に追加する。
【０１００】
４．  Ｍ’に｛Ｕ，ＰＦ(Ｈ，ＫS)｝を追加する
５．  Ｍ＝Ｍ’とセットする。Ｍはこの時点では、メッセージが最適化される対象であるメンバに対して意図されたメッセージ部のみを含む。
【０１０１】
本発明の最適化態様の例示的な第２の実施形態によると、プロトコルＰは、部分集合カバープロトコルであり、出力鍵は、Ｈ＝ＫMによって示される。最適化は好ましくは、以下のように行われる。
【０１０２】
１．  グループ鍵管理メッセージＭ＝｛Ｕij，Ｅ(ＨUij，ＫM）…Ｕkl，Ｅ(ＨUkl，ＫM), Ｕ，ＰＦ(Ｈ，ＫS)｝を取り出す。ここで、Ｕxyは、対応するＥ(ＨＵxy，ＫM）を復号することができるユーザの具体的な部分集合を定義する。
【０１０３】
２．  新たなＭ’＝Φを作成する。
【０１０４】
３．  ｐn∈Ｒに向けられている各｛Ｕij，Ｅ(ＨUij，ＫM)｝∈Ｍに対して（すなわち、ｐn∈Ｕijである場合）、Ｍ’に｛Ｕij，Ｅ(ＨUij，ＫM)｝を追加する。
【０１０５】
４．  Ｍ’に｛Ｕ，ＰＦ(ＫM，ＫS)｝を追加する
５．  Ｍ＝Ｍ’とセットする。Ｍはこの時点では、メッセージが最適化される対象であるメンバに対して指定されたメッセージ部のみを含む。
【０１０６】
再度図１１を参照すると、最適化プロキシは、不必要な部分からグループ鍵管理メッセージをフィルタする最適化方法を実装する。プロキシは、ネットワーク・トポロジおよび必要とされる最適化に応じて、システムの異なる部分に配置することができる。セルラ・インタフェースまたはグループメンバの近くに配置される程、メッセージをより削減することができる。好ましくは、プロキシは、ＧＧＳＮあるいはプロキシ、ファイアウォール、またはホームエージェントなど、ユーザが知っている他のネットワークノードと統合される。フィルタリングは、サービスの安全性および利用可能性を乱さずに実施される。システムの異なる部分に、複数のフィルタリング・プロキシが存在し得る。プロキシの基本機能は、冗長で無関係な情報、すなわちサブグループがＭＤＰ鍵を計算するのに必要とされないメッセージ部を排除することによって、グループメンバからなる各サブグループ向けのグループ鍵管理メッセージのサイズを削減することである。
【０１０７】
図９は、フィルタリングプロセスの例を示す図である。図９には、メンバ（ＵＥ）からなる２つのサブグループを示してある。
【０１０８】
鍵サーバ（ＫS）が、オリジナル・グループ鍵管理メッセージ（Ｍ）を生成し、メッセージ（Ｍ）はメッセージ構成要素ｍ1, ｍ2, ｍ3を排除する第１のフィルタリング・プロキシ（ＯｐＳ1）に入力される。ＯｐＳ1は、たとえば、ＲＮＣノードの所に配置してよく、ＲＮＣノードによって制御されるセルエリア内に配置されていないメンバをフィルタリングすることができる。変更されたメッセージＭ１はその後、プロキシサーバＯｐＳ2, ＯｐＳ3に転送される。こうしたサーバは、たとえば、それぞれ、無線セルにサービスを行う無線基地局の所に配置してよい。したがって、ＯｐＳ2は、制御されるセルエリア内に配置されていないメンバをフィルタリングすることができる。例示的に、図９では、メッセージ構成要素ｍ4およびメッセージブロックｍｂ1, ｍｂ2が排除され、最終的にはサブグループのメンバにブロードキャストされる、変更されたメッセージＭ２を生じる。
【０１０９】
フィルタリングは、上述したもの以外の基準を用いてもよい。たとえば、ＯｐＳサーバは、ブロードキャストされるコンテンツを処理するという、ユーザ端末の能力を認識することができる。この能力は、たとえば、エンドユーザ装置の容量の計算、すなわち具体的なデコーダの、エンドユーザ装置での利用可能性に関する。他の因子は、ユーザの好み、ユーザの優先順位、およびユーザの居場所に関する。更に、ＯｐＳサーバは、使用可能な帯域幅、エラーレート、遅延および無線リンクの質に関連した他の要因など、無線リンク属性を認識することができる。したがって、ＯｐＳサーバは、容認できない品質の受信を回避するというユーザの観点から、または帯域幅を節約するというネットワークの観点から、特定のユーザをブロードキャストから排除することができる。このような排除の土台として、ＯｐＳサーバは、リアルタイム転送制御プロトコル（ＲＴＣＰ: Real-time Transport Control Protocol）を介して集められるメディアサーバ統計や、状態所有パケット検査ノード、メディア・ゲートウェイ、およびファイアウォールのような他のネットワーク監視ノードなど、様々なソースから必要な情報を取りまとめる。
【０１１０】
したがって、ＯｐＳサーバは概して、図８に示すようにいくつかのネットワーク・エンティティと対話する。保護されたデータをユーザに送るメディアサーバ（ＭＳ）は、ブロードキャストされるメディアの特性に関連した情報を提供する。場所レジスタ（ＬＲ）は、ユーザの場所データを提供する。ユーザデータベース（ＵＤＢ）は、ユーザの好みおよびユーザプロファイルについての情報を提供する。ＵＤＢは、ユーザと識別子Ｕijの間のマッピングを登録することもできる。ただし、このような各ソースと直接対話するのではなく、対話は、好ましくは、様々なソースから情報を収集するポリシー決定点（ＰＤＰ: polocy decision point）を介して間接的に行われることになる。集められた情報に基づいて、所与の瞬間に現在のどのポリシーをＯｐＳが適用するべきか、決定が行われる。ポリシー決定点（ＰＤＰ）は、グループ鍵配布に関する動的および静的ポリシーと、たとえば、トラフィック成形およびトラフィックの一時的な遮断に関するメディアデータとを与える。ポリシーは、ユーザごとにセットすることもできる。
【０１１１】
図１０は、本発明による例示的な信号図を示す図である。
【０１１２】
鍵サーバ（ＫS）は、（１）でグループ鍵管理メッセージを伝送し、該メッセージは処理のためにＯｐＳサーバによって傍受される。グループ鍵管理メッセージが、ＯｐＳに知られていないグループ鍵配布サービスに属す場合、ＯｐＳは、（２）で、鍵サーバ（ＫS）とコンタクトをとって、メンバのグループ、その論理構造を含むグループ鍵配布プロトコルのタイプについての情報を取り出す。グループ鍵配布サービスが知られている場合、メッセージ（２）は省いてよい。場所レジスタ（ＬＲ）は、（３）で、交信を受け、具体的なＯｐＳが扱っているユーザを識別するための要求を与えられる。ＯｐＳが受け取るユーザのリストは、要求が、扱うことができる全ユーザに対するものであるケースでは、グループ中の特定のメンバより多くのユーザを含み得ることに留意されたい。グループの中にないどのユーザも無視される。場所レジスタ（ＬＲ）との交信は、システム内を動き回るユーザおよび新規ユーザを追加することも、特定のＯｐＳから取り除くこともできるよう保証するために、定期的に行われる。（４）で、ＯｐＳは、ＵＤＢと交信をして、グループ中のユーザおよびユーザの間のマッピングと、グループ鍵管理メッセージ中で使われる識別子Ｕijとについての情報を得る。
【０１１３】
（５）で、特殊なポリシーが、ＰＤＰから取り出される。こうしたポリシーは、通常、絶えず更新される動的ポリシーである。動的ポリシーは、状況に依存し、時間と共に変化し得る。たとえば、時間ｘとｙの間で、ユーザ数がｙであるとすると、無線リンクＡは、ｚＫＢより大きいメッセージを受け取るべきでない。静的ポリシーは、ＯｐＳ内で「ハードコード化された」何かであり、たとえば、ノードＺのみからのグループ鍵配布サービスの受容を指示する。（６）で、メッセージは、たとえば上述したような、ユーザが知っている最適化方法を用いて最適化される。特殊なポリシーを強制してもよい。（７）で、最適化されたグループ鍵管理メッセージが、ユーザ（ＵＥ）に向けて伝送される。
【０１１４】
（８）で、メディアサーバ（ＭＳ）は、保護されたメディアを送り、ＯｐＳサーバは、メディア・トラフィック用のポリシー強制点として作用して、したがって、たとえば、（９）で、ユーザ（ＵＥ）へのメディアの転送に先立って、トラフィックを成形し、または遮断し得る。それ以外のネットワーク・エンティティを、図１０による信号通信に含めて、たとえば、ネットワーク構成パラメータに応じて部分集合Ｒを作ることができる。例示的には、部分集合Ｒは、モバイルネットワークの一定の位置エリア内に配置されたメンバに制限してよい。この場合、図１１を参照すると、Ｏｐｓサーバは好ましくは、ＲＮＣノード内に配置される。あるいは、部分集合Ｒは、端末および／または無線チャネル機能に応じて作られ、部分集合Ｒは、一定のメディア形式を処理する能力を有するメンバ端末、または指定された容量または質の無線アクセス権を有するメンバ端末に制限してよい。
【０１１５】
好ましいＯｐＳサーバの例示的な構造を、図１２に示す。
【０１１６】
入力メッセージ・バッファ・ユニット（ＩＭＢＵ: input message buffer unit）が、鍵サーバ（ＫS）から鍵メッセージ（Ｍ）を受け取る。メッセージは、最適化およびポリシー強制ユニット（ＯＰＥＵ: optimization and policy enforcement unit）に転送される。ＯＰＥＵユニットは、ネットワーク信号通信インタフェース（ＮＷＳＩ: neiwork-signaling interface）を介して様々なネットワークユニットから受け取った情報に応じて、最適化を実施する。変更されたメッセージ（Ｍ’）は、ユーザに更にブロードキャストするために、出力メッセージ・バッファ・ユニット（ＯＭＢＵ: output message buffer unit）に格納される。
【０１１７】
制御ユニット（ＣＬＵ: control unit）が、最適化サーバ内部でのプロセスを制御する。別の信号通信インタフェース（ＯＰＳＳ）が、異なる最適化サーバの間の信号通信を扱う。これは、たとえば、ユーザが、第１の最適化サーバによって制御されるあるセルから、第２の最適化サーバによって制御される別のセルに移動するときに有用であり得る。例示的には、図９を参照すると、ユーザＵＥ１は、ＯｐＳ2によって制御されるセルから、ＯｐＳ3によって制御されるセルに移動し得る。最適化サーバＯｐＳ2は、次いで、それに応じてメッセージＭ2を変更してＯｐＳ3に信号を送り、メッセージＭ3を変更することができる。
【０１１８】
本発明は、その全態様において、概してブロードキャストおよびマルチキャスト、ワイヤレス、ワイヤーラインの両方、およびたとえば無線に基づくブロードキャストだけでなくインターネット・サービス・アプリケーションも含む組合せに適用可能である。
【０１１９】
上述した実施形態は、例として与えられるだけであり、本発明は、それに限定されないことを理解されたい。本明細書において開示され権利請求される基本的な基底原理を保持するさらなる修正、変更および改良は、本発明の範囲内である。
【図面の簡単な説明】
【０１２０】
【図１】グループ鍵管理メッセージの配布のための例示的なネットワークの概観を示す図である。
【図２】グループ鍵管理メッセージをある特定のユーザグループに適合するための、従来技術による階層システムを表す論理ツリーを示す図である。
【図３】従来技術による部分集合差方法を表す論理ツリーを示す図である。
【図４】本発明による新たな抽象階層を示す図である。
【図５】本発明の好ましい基本的な実施形態によるフローチャートを示す図である。
【図６】本発明の別の好ましい実施形態によるフローチャートを示す図である。
【図７】本発明の一実施形態によるグループ鍵管理メッセージの作成のための例示的な機器を示すブロック図である。
【図８】本発明の一実施形態による１つまたは複数の最適化サーバを使用することができる例示的なシステム構成を示す全体図である。
【図９】本発明の一実施形態による１つまたは複数の最適化サーバの動作を示す図である。
【図１０】本発明の一実施形態による最適化サーバと他のネットワークエンティティとの間の例示的な信号通信を示す信号図である。
【図１１】本発明による最適化サーバのネットワーク内での例示的な場所を示す図である。
【図１２】本発明の好ましい実施形態による例示的な最適化サーバを示すブロック図である。
【図１】
2007537656.tif 000009
【図２】
2007537656.tif 000010
【図３】
2007537656.tif 000011
【図４】
2007537656.tif 000012
【図５】
2007537656.tif 000013
【図６】
2007537656.tif 000014
【図７】
2007537656.tif 000015
【図８】
2007537656.tif 000016
【図９】
2007537656.tif 000017
【図１０】
2007537656.tif 000018
【図１１】
2007537656.tif 000019
【図１２】
2007537656.tif 000020
【国際調査報告】
2007537656.tif 000021
2007537656.tif 000022