ディジタル映画のための鍵管理システム
【課題】ディジタル映画システムでコンテンツを保護する鍵を配布および管理する技術を提供する。
【解決手段】ディジタル映画システム１０００における鍵管理は、暗号化済みコンテンツに用いるフィーチャ鍵を、暗号化済みコンテンツを暗号化解除する役割を果たす暗号化解除モジュール６００１、６００２と交換された送信鍵４００１−４００４で暗号化することによって行われる。暗号化されたフィーチャ鍵５００１−５００４は、暗号化解除モジュールに送信されて、交換され保持している送信鍵で復号することによって、コンテンツの暗号化解除が可能になる。
【解決手段】ディジタル映画システム１０００における鍵管理は、暗号化済みコンテンツに用いるフィーチャ鍵を、暗号化済みコンテンツを暗号化解除する役割を果たす暗号化解除モジュール６００１、６００２と交換された送信鍵４００１−４００４で暗号化することによって行われる。暗号化されたフィーチャ鍵５００１−５００４は、暗号化解除モジュールに送信されて、交換され保持している送信鍵で復号することによって、コンテンツの暗号化解除が可能になる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はディジタル映画の技術に関し、より詳細には、ディジタル映画システムでコンテンツを保護する鍵を配布および管理する技術に関する。
【背景技術】
【０００２】
「ディジタル映画」という言葉は一般に、画像、サウンド・トラック、および字幕を含めたコンテンツが動画フィルム上にアナログ形式で存在する従来の映画とは対照的に、ディジタル形式の動画の作成および／または配信を指す。ディジタル映画投影システムが今や存在し、このディジタル映画投影システムは、すべてによって受け入れられる単一の標準化された解決法ではなく、様々な技術的解決法を利用する。限られた大規模なディジタル映画配備しか持たないコンテンツ所有者（例えば動画スタジオ）にとっては、コピーからの防護が主要な懸念であり続けている。コンテンツがディジタル形式で存在することは、労力をほとんどかけずに元のコンテンツの完全なコピーを作る機会を与える。この理由で、Ｄｉｇｉｔａｌ Ｃｉｎｅｍａ Ｉｎｉｔｉａｔｉｖｅ（ＤＣＩ）や全米映画テレビジョン技術者協会（ＳＭＰＴＥ）など様々な組織が、ディジタル映画コンテンツ配信のための仕様の制定に向けて多くの努力を捧げてきた。
【０００３】
ＤＣＩ仕様は、符号化、配信、セキュリティなど、多くの領域での好ましい解決法を定義している。ＳＭＰＴＥは、ＤＣＩ仕様を技術および実装の観点から改良しようとしたものである。セキュリティの領域内では、鍵管理が重要な役割を果たす。鍵管理とは、ディジタル・コンテンツの暗号化を達成するのに利用される鍵の管理を指す。全体を通して使用される用語「暗号化」は、暗号化とスクランブル化の何れかを意味する。同様に、用語「復号」は、暗号化解除とスクランブル化解除の何れかを意味する。現在、ＤＣＩおよびＳＭＰＴＥ仕様では、デバイス証明書および信用デバイス・リスト（「ＴＤＬ」、Ｔｒｕｓｔｅｄ Ｄｅｖｉｃｅ Ｌｉｓｔ）を使用した鍵管理が可能である。各セキュリティ・エンティティ（「ＳＥ」）、すなわちコンテンツに対するアクセスまたは操作が可能な各デバイスは、デバイスの製造業者から提供されたディジタル証明書を保持することになる。この証明書は、製造業者と独立エンティティの何れかによって管理することができる。ＴＤＬには、信用されるデバイス、例えばディジタル・プロジェクタなどのコンテンツ受信デバイスが記載されている。より具体的には、ＴＤＬには、信用されて特定のコンテンツの操作を許された各デバイスのそれぞれのディジタル証明書が記載されている。フィーチャ暗号化鍵（「ＫＦ」）が、コンテンツ所有者、または配給元などその代わりを務めるエージェントから、コンテンツ上映を許可された映画館に位置するセキュリティ・モジュール（「ＳＭ」）に送信される。ＳＭは、ＴＤＬ中で明示的に参照されるデバイスだけしかＫＦにアクセスしたりＫＦを知ったりしないようにすることを担う。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この方式にはいくつかの不都合がある。第１に、ＴＤＬの発行者と証明書の発行者との間には必ずしもリンクが存在するわけではなく、このことはセキュリティ上の脆弱性を招く。部外者が、証明されないデバイスに証明書を発行して、このような証明されないデバイスをうまくＴＤＬ中にリストさせる可能性があることが考えられる。第２に、セキュリティ・モジュール（「ＳＭ」）は、通常はコンテンツ権利所有者および公開者の制御外にあり、ＳＭは、フィーチャ鍵が信用デバイスのみに配布されるようにすることを担う唯一のエンティティとして働く。このような状況下では、ハッカーが、フィーチャ鍵をＴＤＬ外のデバイスに送信するのを許可するようにしてＳＭを操作する可能性がある。第３に、ＳＭは映画館でのＫＦ管理を担うが、ハッカーがＳＭを操作してＫＦへのアクセスを得る可能性がある。コンテンツはディジタル形式で存在するので、ＫＦへのアクセスにより、ハッカーは、ほぼ損失なくコンテンツにアクセスしてこれを再配信することができる。
【０００５】
従って、コンテンツの暗号化解除を実際に行うデバイスに対してフィーチャ鍵を秘密にしておく鍵管理プロセスが必要とされている。
【課題を解決するための手段】
【０００６】
簡潔に言えば本発明により、鍵管理、実際にはディジタル映画コンテンツのための鍵管理の技術が提供される。この方法は、暗号化済みコンテンツに関連するフィーチャ鍵を、暗号化解除モジュールと交換された送信鍵で暗号化することで開始する。通常、必須ではないが、暗号化解除モジュールは、暗号化済みコンテンツが後の上映のために鍵に従って暗号化解除される場所である映画館または同様の施設に存在する。暗号化されたフィーチャ鍵は、暗号化解除モジュールに送信されて、暗号化済みコンテンツの暗号化解除が可能になる。このようにして、暗号化解除モジュールは、このモジュール自体の鍵のみに基づいてコンテンツを暗号化解除する機能を有することになる。
【図面の簡単な説明】
【０００７】
【図１】本発明の原理の鍵管理技術を実施する、単一の公開施設に単一の暗号化解除モジュールがある場合のシステムの単純化されたブロック図である。
【図２】本発明の原理の鍵管理技術を実施する、単一の公開施設に複数の暗号化解除モジュールがある場合のシステムの単純化されたブロック図である。
【図３】本発明の原理の鍵管理技術を実施する、複数の公開施設に複数の暗号化解除モジュールがある場合のシステムの単純化されたブロック図である。
【発明を実施するための形態】
【０００８】
図１に、本原理の第１の実施例により鍵管理を提供するためのシステム１０のブロック概略図を示す。図１のブロック１５で表すように、鍵管理プロセスの最初に、映画スタジオなどのコンテンツ作成者がコンテンツ作成に携わる。作成されたコンテンツは、初めにディジタル・キャプチャ・デバイスを使用して作成した結果としてであろうと、初めにフィルム上でキャプチャした画像をディジタル変換した結果としてであろうと、ディジタル形式で存在する。コンテンツ作成者またはそのエージェントは、図１にフィーチャ鍵２０として示す鍵をコンテンツの暗号化解除に使用することを必要とするいくつかの周知の技術の何れか１つを使用して、ディジタル形式のコンテンツを暗号化することになる。
【０００９】
鍵マネージャ３０が、フィーチャ鍵２０を受け取る。鍵マネージャ３０はさらに、映画館やその他などの公開施設（図示せず）に位置するディジタル映画プロジェクタに通常は関連する暗号化解除モジュール６０と、送信鍵４０について合意する。鍵マネージャと暗号化解除モジュールの何れかが、送信鍵４０の交換を開始することになる。通常、鍵マネージャ３０は、あるタイプの鍵を別の鍵で暗号化および／または暗号化解除する機能を有するプログラム済みディジタル・コンピュータまたは専用ロジック回路の形式をとる。鍵マネージャ３０は、送信鍵４０でフィーチャ鍵２０を暗号化して、保護されたフィーチャ鍵５０を生み出す。保護されたフィーチャ鍵５０は、暗号化解除モジュール６０に送られる。暗号化解除モジュール６０は、合意済みの送信鍵４０を利用してフィーチャ鍵２０を取り出し、さらに暗号化済みコンテンツを暗号化解除して表示を可能にする。
【００１０】
前述のシステム１０によって実施される鍵管理技術は、セキュリティ増強の利点をもたらす。コンテンツ・フィーチャ鍵２０を暗号化解除モジュール６０からの送信鍵４０で暗号化するプロセスにより、フィーチャ鍵２０はより傍受されにくくなる。さらに、暗号化解除モジュール６０によって利用される保護されたフィーチャ鍵５０は、暗号化解除モジュールと一意に関連付けられたままであり、従って、保護されたフィーチャ鍵がたとえハッキングされたとしても、保護されたフィーチャ鍵によって別の暗号化解除モジュールが暗号化済みコンテンツを正しく暗号化解除できる可能性は大きく低減される。
【００１１】
図２に、本原理の第２の実施例により鍵管理を提供するためのシステム１００のブロック概略図を示す。図２のブロック１５０で表すように、鍵管理プロセスの最初に、映画スタジオなどのコンテンツ作成者がコンテンツ作成に携わる。作成されたコンテンツは、初めにディジタル・キャプチャ・デバイスを使用して作成した結果としてであろうと、初めにフィルム上でキャプチャした画像をディジタル変換した結果としてであろうと、ディジタル形式で存在する。コンテンツ作成者またはそのエージェントは、図２にフィーチャ鍵２００として示す鍵をコンテンツの暗号化解除に使用することを必要とするいくつかの周知の技術の何れか１つを使用して、ディジタル形式のコンテンツを暗号化することになる。
【００１２】
鍵マネージャ３００が、フィーチャ鍵２００をコンテンツ作成者から受け取る。図２の鍵マネージャ３００は、暗号化解除モジュール６０１および６０２のそれぞれと、送信鍵４０１および４０２を交換することになる。暗号化解除モジュール６０１と６０２は両方とも同じ公開施設に位置するが、各モジュールは異なるディジタル映画プロジェクタ（図示せず）に関連する。鍵マネージャと各暗号化解除モジュールの何れかが、交換を開始することになる。図１の鍵マネージャ３０と同様、鍵マネージャ３００は、あるタイプの鍵を別の鍵で暗号化する機能を有するプログラム済みディジタル・コンピュータまたは専用ロジック回路の形式をとる。図２の鍵マネージャ３００は、暗号化解除モジュール６０１および６０２からの各送信鍵４０１および４０２でそれぞれ別々にフィーチャ鍵２００を暗号化して、保護されたフィーチャ鍵５０１および５０２をそれぞれ生み出す。各暗号化解除モジュール６０１および６０２は、送信鍵４０１および４０２のうちの対応する一方をそれぞれ利用してフィーチャ鍵２００を入手し、さらに暗号化済みコンテンツを暗号化解除して表示を可能にする。
【００１３】
図１の鍵管理システム１０では、単一の暗号化解除モジュール６０に関連する送信鍵４０でフィーチャ鍵２０の暗号化を実施するが、この鍵管理システム１０と比較すると、図２の鍵マネージャ３００は、異なる暗号化解除モジュール６０１および６０２の送信鍵で別々にフィーチャ鍵２００を暗号化して、別々の保護されたフィーチャ鍵５０１および５０２をそれぞれ生み出す。別々の保護されたフィーチャ鍵５０１および５０２はそれぞれ、暗号化解除モジュール６０１および６０２のうちの対応する一方でのみ機能することになる。図２の鍵管理システム１００では、映画館のオペレータは、同じ保護されたフィーチャ鍵を複数の暗号化解除モジュールで使用して、確立されたセキュリティ・セーフガードを破ることはできない。
【００１４】
図２の鍵マネージャ３００はまた、各暗号化解除モジュール６０１および６０２と、異なるフィーチャ鍵（フィーチャ鍵２００など）を交換することもできる。このような場合は、鍵マネージャ３００は、送信鍵４０１を利用してフィーチャ鍵２０１（図示せず）を暗号化し、保護されたフィーチャ鍵５０１の代わりに保護されたフィーチャ鍵（図示せず）を生み出して暗号化解除モジュール６０１に送ることになる。暗号化解除モジュール６０１は、その送信鍵４０１を使用してこの保護されたフィーチャ鍵を暗号化解除し、フィーチャ鍵２０１を入手し、暗号化済みコンテンツを暗号化解除して表示を可能にすることになる。同様に、鍵マネージャ３００は、送信鍵４０２を使用して第２のフィーチャ鍵２０２（図示せず）を暗号化し、保護されたフィーチャ鍵５０２の代わりに保護されたフィーチャ鍵（図示せず）を生み出すことになる。鍵マネージャ３００は、この保護されたフィーチャ鍵を暗号化解除モジュール６０２に送り、暗号化解除モジュール６０２は、その送信鍵４０２を使用して保護されたフィーチャ鍵５０４を暗号化解除し、フィーチャ鍵２０２を入手し、暗号化済みコンテンツを暗号化解除して表示を可能にすることになる。
【００１５】
図３に、本原理の第３の実施例により鍵管理を提供するためのシステム１０００のブロック概略図を示す。図３のブロック１５００で表すように、鍵管理プロセスの最初に、映画スタジオなどのコンテンツ作成者がコンテンツ作成に携わる。作成されたコンテンツは、初めにディジタル・キャプチャ・デバイスを使用して作成した結果としてであろうと、初めにフィルム上でキャプチャした画像をディジタル変換した結果としてであろうと、ディジタル形式で存在する。コンテンツ作成者またはそのエージェントは、図３にフィーチャ鍵２０００として示す鍵をコンテンツの暗号化解除に使用することを必要とするいくつかの周知の技術の何れか１つを使用して、ディジタル形式のコンテンツを暗号化することになる。
【００１６】
鍵マネージャ３０００が、フィーチャ鍵２０００をコンテンツ製作者から受け取る。図３の鍵マネージャ３０００は、暗号化解除モジュール６００１〜６００４と、送信鍵４００１〜４００４をそれぞれ交換する。図３の例示的な実施例では、暗号化解除モジュール６００１および６００２は第１の公開施設（映画館Ａ）にあり、暗号化解除モジュール６００３および６００４は第２の公開施設（映画館Ｂ）にある。あるいは、暗号化解除モジュール６００１〜６００４それぞれが別々の公開施設にあってもよい。公開施設の数、およびこのような施設にある暗号化解除モジュールの数は、本原理の鍵管理技術に悪影響を及ぼすことなく変更することができる。鍵マネージャと暗号化解除モジュールの何れかが、交換を開始することになる。鍵マネージャが交換を開始する場合は、鍵マネージャ・システムは通常、少なくとも１つの予想される暗号化解除受信側の固有識別子を、各暗号化解除モジュールに送ることになる。
【００１７】
図２の鍵マネージャ３００と同様、図３の鍵マネージャ３０００は、あるタイプの鍵を別の鍵で暗号化する機能を有するプログラム済みディジタル・コンピュータまたは専用ロジック回路の形式をとる。図３の鍵マネージャ３０００は、暗号化解除モジュール６００１〜６００４からの各送信鍵４００１〜４００４でそれぞれ別々にフィーチャ鍵２０００を暗号化して、保護されたフィーチャ鍵５００１〜５００４をそれぞれ生み出す。各暗号化解除モジュール６００１〜６００４は、保護されたフィーチャ鍵５００１〜５００４のうちの対応する１つをそれぞれ利用して、暗号化済みコンテンツを暗号化解除して表示を可能にする。
【００１８】
図２の鍵マネージャ３００がフィーチャ鍵２００を送信鍵４０１および４０２で別々に暗号化して別々の保護されたフィーチャ鍵５０１および５０２をそれぞれ生み出すのと同様、図３の鍵マネージャ３０００も、フィーチャ鍵２０００を各送信鍵４００１〜４００４でそれぞれ別々に暗号化して、保護されたフィーチャ鍵５００１〜５０００４をそれぞれ生み出す。それぞれの場合に、各暗号化解除モジュールは、そのモジュールに固有の保護されたフィーチャ鍵を受け取る。従って、図２の鍵管理システム１００のように、図３の鍵管理システム１０００では、映画館のオペレータは、同じ保護されたフィーチャ鍵を複数の暗号化解除モジュールで使用して、確立されたセキュリティ・セーフガードを破ることはできない。
【００１９】
複数の暗号化解除モジュールが同じフィーチャの暗号化解除に使用される場合は、そのような暗号化解除モジュールがそれぞれ共通の送信鍵を鍵マネージャに提供するという条件で、図２の鍵マネージャ３００や図３の鍵マネージャ３０００などの鍵マネージャが、同じフィーチャ鍵を提供することができる。そうでない場合は、鍵マネージャは各暗号化解除モジュールに別々の保護されたフィーチャ鍵を提供することになる。
【００２０】
図１〜３の各鍵管理システム１０、１００、および１０００ではそれぞれ、鍵マネージャへのフィーチャ鍵の送信は安全な方式で行われる。論じたように、各鍵マネージャは、どんな予備またはバックアップ暗号化解除モジュールをも含めて、最終的にコンテンツを暗号化解除することになっている各暗号化解除モジュールに関連する送信鍵でフィーチャ鍵を暗号化することによって、個別の保護されたフィーチャ鍵を生み出す。
【００２１】
実際には、フィーチャ鍵２０、２００、２０００はそれぞれ、単一の対称鍵を含む。フィーチャ作成システムと鍵マネージャとの間のフィーチャ鍵の交換は、通常、共有秘密に基づく暗号対称アルゴリズムを使用して行われる。フィーチャ作成システムと鍵マネージャとの間のフィーチャ鍵の交換はまた、鍵マネージャの秘密／公開鍵の対に基づく非対称暗号アルゴリズムを使用して、あるいは安全な認証済みチャネルまたは専用モデム回線を使用して保護することもできる。
【００２２】
同様に、鍵マネージャと暗号化解除モジュールとの間のフィーチャ鍵の交換は、通常、鍵マネージャと暗号化解除モジュールとが暗号的な意味でお互いを相互認証できたという条件で、共有秘密に基づく暗号対称アルゴリズムを使用して行われる。鍵マネージャと暗号化解除モジュールとの間のフィーチャ鍵の交換は、鍵マネージャが暗号化解除モジュールを安全に認証できたという条件で、暗号化解除モジュールの秘密／公開鍵の対に基づく非対称暗号アルゴリズムを使用して保護することができる。
【００２３】
コンテンツを暗号化するには、ディジタル・エンベロープや非対称鍵の使用など、様々な代替方法がある。さらに、コンテンツ暗号化は、単一の鍵ではなく複数の鍵を使用して行うこともでき、各鍵は通常、必須ではないが、フィーチャの時間的セグメントに関連する。コンテンツをセグメント化して複数の鍵の使用を可能にするには、フィーチャをＮ個（ただし、Ｎは０（零）よりも大きい。）の連続的なセグメントにセグメント化することなど、様々な方法がある。複数のフィーチャ暗号化鍵を利用する場合、図１に述べたシステムを修正して、システム・レベルとフィーチャ暗号化解除レベルの両方で動作を最適化することができる。例えば、図１に示すように、鍵管理システム３０はまず、フィーチャ鍵をマスタ鍵で暗号化し、マスタ鍵を送信鍵４０で暗号化し（送信鍵は、暗号化解除モジュールの公開鍵、または鍵マネージャと暗号化解除モジュールとの間で交換される対称鍵とすることができる）、両方の結果を暗号化解除モジュール６０に送ることができる。コンテンツ暗号化はまた、非対称スクランブル化または暗号化アルゴリズムを使用して行うこともできる。さらに、コンテンツは、追加の鍵を使用して超スクランブル化または超暗号化をかけることもできる。例えば、フィーチャをまずフィーチャ鍵で暗号化し、次いで追加の鍵で暗号化する（またはこの逆）。コンテンツ暗号化はまた、フィーチャ鍵と他の情報とから得られる鍵を使用して行うこともできる。他の情報とは、鍵管理システムの識別、暗号化解除モジュール、時刻、日付、および／またはこれらの任意の組合せなどだが、これらに限定されない。
【００２４】
好ましい一実施例では、送信鍵は、非対称暗号鍵の対によって提供される、暗号化解除モジュールの公開鍵を含む。送信鍵は、定期的に、ランダムに、または要求があり次第、変更することができる。
【００２５】
各暗号化解除モジュールは、その公開鍵を鍵マネージャに送信する。このような送信は個別に行うことができる（すなわち、暗号化解除モジュールは鍵マネージャへの直接接続を有する）。あるいは、１組の暗号化解除モジュール、例えば単一の公開施設にあるすべての暗号化解除モジュールが、それぞれの公開鍵を単一メッセージ内で鍵管理システムに送ることもできる。通信リンクは、無線または有線チャネルを含むことができる。送信鍵に関する非対称アプローチの代替方法には、事前に合意した対称鍵の使用や、ＭＡＣベースの方法などを含めることができる。本原理の鍵管理技術は、フィーチャ暗号化鍵に暗号化解除モジュール・レベルでのみアクセス可能であり他のどんな中間モジュールからもアクセス不可能な方式で、フィーチャ暗号化鍵を保護する利点をもたらす。
【００２６】
各暗号化解除モジュール６０、６０１〜６０２、および６００１〜６００４は、公開施設にある物理デバイスとの関連を有する。物理デバイスとは例えば、セキュリティ・モジュール（図示せず）、プロジェクタ（図示せず）、コンテンツ処理デバイス（図示せず）などだが、これらに限定されない。暗号化解除モジュールの実際の位置は、本原理の鍵管理技術にまったく関係ない。必要であることは、各暗号化解除モジュールがその識別を鍵マネージャに知られており、両者が送信鍵を相互と交換する機能を有することである。別々に示したが、鍵管理システムは、映画館内の物理デバイス（上述）の一部として存在してもよく、あるいはコンテンツ作成システムの一部として存在してもよい。
【００２７】
暗号化解除モジュールは、鍵マネージャへの直接通信リンクを所有している必要はない。そのような場合は、中継エンティティ、例えばＤＣＩおよびＳＭＰＴＥ文書に記載されているシアター管理システム（Ｔｈｅａｔｅｒ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）やセキュリティ・モジュール（図示せず）が、鍵マネージャからのメッセージを取り込み、適切な暗号化解除モジュールに中継することができる。
【００２８】
以上、暗号化済みコンテンツの暗号化解除とともに鍵を管理する技術について述べた。
【技術分野】
【０００１】
本発明はディジタル映画の技術に関し、より詳細には、ディジタル映画システムでコンテンツを保護する鍵を配布および管理する技術に関する。
【背景技術】
【０００２】
「ディジタル映画」という言葉は一般に、画像、サウンド・トラック、および字幕を含めたコンテンツが動画フィルム上にアナログ形式で存在する従来の映画とは対照的に、ディジタル形式の動画の作成および／または配信を指す。ディジタル映画投影システムが今や存在し、このディジタル映画投影システムは、すべてによって受け入れられる単一の標準化された解決法ではなく、様々な技術的解決法を利用する。限られた大規模なディジタル映画配備しか持たないコンテンツ所有者（例えば動画スタジオ）にとっては、コピーからの防護が主要な懸念であり続けている。コンテンツがディジタル形式で存在することは、労力をほとんどかけずに元のコンテンツの完全なコピーを作る機会を与える。この理由で、Ｄｉｇｉｔａｌ Ｃｉｎｅｍａ Ｉｎｉｔｉａｔｉｖｅ（ＤＣＩ）や全米映画テレビジョン技術者協会（ＳＭＰＴＥ）など様々な組織が、ディジタル映画コンテンツ配信のための仕様の制定に向けて多くの努力を捧げてきた。
【０００３】
ＤＣＩ仕様は、符号化、配信、セキュリティなど、多くの領域での好ましい解決法を定義している。ＳＭＰＴＥは、ＤＣＩ仕様を技術および実装の観点から改良しようとしたものである。セキュリティの領域内では、鍵管理が重要な役割を果たす。鍵管理とは、ディジタル・コンテンツの暗号化を達成するのに利用される鍵の管理を指す。全体を通して使用される用語「暗号化」は、暗号化とスクランブル化の何れかを意味する。同様に、用語「復号」は、暗号化解除とスクランブル化解除の何れかを意味する。現在、ＤＣＩおよびＳＭＰＴＥ仕様では、デバイス証明書および信用デバイス・リスト（「ＴＤＬ」、Ｔｒｕｓｔｅｄ Ｄｅｖｉｃｅ Ｌｉｓｔ）を使用した鍵管理が可能である。各セキュリティ・エンティティ（「ＳＥ」）、すなわちコンテンツに対するアクセスまたは操作が可能な各デバイスは、デバイスの製造業者から提供されたディジタル証明書を保持することになる。この証明書は、製造業者と独立エンティティの何れかによって管理することができる。ＴＤＬには、信用されるデバイス、例えばディジタル・プロジェクタなどのコンテンツ受信デバイスが記載されている。より具体的には、ＴＤＬには、信用されて特定のコンテンツの操作を許された各デバイスのそれぞれのディジタル証明書が記載されている。フィーチャ暗号化鍵（「ＫＦ」）が、コンテンツ所有者、または配給元などその代わりを務めるエージェントから、コンテンツ上映を許可された映画館に位置するセキュリティ・モジュール（「ＳＭ」）に送信される。ＳＭは、ＴＤＬ中で明示的に参照されるデバイスだけしかＫＦにアクセスしたりＫＦを知ったりしないようにすることを担う。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この方式にはいくつかの不都合がある。第１に、ＴＤＬの発行者と証明書の発行者との間には必ずしもリンクが存在するわけではなく、このことはセキュリティ上の脆弱性を招く。部外者が、証明されないデバイスに証明書を発行して、このような証明されないデバイスをうまくＴＤＬ中にリストさせる可能性があることが考えられる。第２に、セキュリティ・モジュール（「ＳＭ」）は、通常はコンテンツ権利所有者および公開者の制御外にあり、ＳＭは、フィーチャ鍵が信用デバイスのみに配布されるようにすることを担う唯一のエンティティとして働く。このような状況下では、ハッカーが、フィーチャ鍵をＴＤＬ外のデバイスに送信するのを許可するようにしてＳＭを操作する可能性がある。第３に、ＳＭは映画館でのＫＦ管理を担うが、ハッカーがＳＭを操作してＫＦへのアクセスを得る可能性がある。コンテンツはディジタル形式で存在するので、ＫＦへのアクセスにより、ハッカーは、ほぼ損失なくコンテンツにアクセスしてこれを再配信することができる。
【０００５】
従って、コンテンツの暗号化解除を実際に行うデバイスに対してフィーチャ鍵を秘密にしておく鍵管理プロセスが必要とされている。
【課題を解決するための手段】
【０００６】
簡潔に言えば本発明により、鍵管理、実際にはディジタル映画コンテンツのための鍵管理の技術が提供される。この方法は、暗号化済みコンテンツに関連するフィーチャ鍵を、暗号化解除モジュールと交換された送信鍵で暗号化することで開始する。通常、必須ではないが、暗号化解除モジュールは、暗号化済みコンテンツが後の上映のために鍵に従って暗号化解除される場所である映画館または同様の施設に存在する。暗号化されたフィーチャ鍵は、暗号化解除モジュールに送信されて、暗号化済みコンテンツの暗号化解除が可能になる。このようにして、暗号化解除モジュールは、このモジュール自体の鍵のみに基づいてコンテンツを暗号化解除する機能を有することになる。
【図面の簡単な説明】
【０００７】
【図１】本発明の原理の鍵管理技術を実施する、単一の公開施設に単一の暗号化解除モジュールがある場合のシステムの単純化されたブロック図である。
【図２】本発明の原理の鍵管理技術を実施する、単一の公開施設に複数の暗号化解除モジュールがある場合のシステムの単純化されたブロック図である。
【図３】本発明の原理の鍵管理技術を実施する、複数の公開施設に複数の暗号化解除モジュールがある場合のシステムの単純化されたブロック図である。
【発明を実施するための形態】
【０００８】
図１に、本原理の第１の実施例により鍵管理を提供するためのシステム１０のブロック概略図を示す。図１のブロック１５で表すように、鍵管理プロセスの最初に、映画スタジオなどのコンテンツ作成者がコンテンツ作成に携わる。作成されたコンテンツは、初めにディジタル・キャプチャ・デバイスを使用して作成した結果としてであろうと、初めにフィルム上でキャプチャした画像をディジタル変換した結果としてであろうと、ディジタル形式で存在する。コンテンツ作成者またはそのエージェントは、図１にフィーチャ鍵２０として示す鍵をコンテンツの暗号化解除に使用することを必要とするいくつかの周知の技術の何れか１つを使用して、ディジタル形式のコンテンツを暗号化することになる。
【０００９】
鍵マネージャ３０が、フィーチャ鍵２０を受け取る。鍵マネージャ３０はさらに、映画館やその他などの公開施設（図示せず）に位置するディジタル映画プロジェクタに通常は関連する暗号化解除モジュール６０と、送信鍵４０について合意する。鍵マネージャと暗号化解除モジュールの何れかが、送信鍵４０の交換を開始することになる。通常、鍵マネージャ３０は、あるタイプの鍵を別の鍵で暗号化および／または暗号化解除する機能を有するプログラム済みディジタル・コンピュータまたは専用ロジック回路の形式をとる。鍵マネージャ３０は、送信鍵４０でフィーチャ鍵２０を暗号化して、保護されたフィーチャ鍵５０を生み出す。保護されたフィーチャ鍵５０は、暗号化解除モジュール６０に送られる。暗号化解除モジュール６０は、合意済みの送信鍵４０を利用してフィーチャ鍵２０を取り出し、さらに暗号化済みコンテンツを暗号化解除して表示を可能にする。
【００１０】
前述のシステム１０によって実施される鍵管理技術は、セキュリティ増強の利点をもたらす。コンテンツ・フィーチャ鍵２０を暗号化解除モジュール６０からの送信鍵４０で暗号化するプロセスにより、フィーチャ鍵２０はより傍受されにくくなる。さらに、暗号化解除モジュール６０によって利用される保護されたフィーチャ鍵５０は、暗号化解除モジュールと一意に関連付けられたままであり、従って、保護されたフィーチャ鍵がたとえハッキングされたとしても、保護されたフィーチャ鍵によって別の暗号化解除モジュールが暗号化済みコンテンツを正しく暗号化解除できる可能性は大きく低減される。
【００１１】
図２に、本原理の第２の実施例により鍵管理を提供するためのシステム１００のブロック概略図を示す。図２のブロック１５０で表すように、鍵管理プロセスの最初に、映画スタジオなどのコンテンツ作成者がコンテンツ作成に携わる。作成されたコンテンツは、初めにディジタル・キャプチャ・デバイスを使用して作成した結果としてであろうと、初めにフィルム上でキャプチャした画像をディジタル変換した結果としてであろうと、ディジタル形式で存在する。コンテンツ作成者またはそのエージェントは、図２にフィーチャ鍵２００として示す鍵をコンテンツの暗号化解除に使用することを必要とするいくつかの周知の技術の何れか１つを使用して、ディジタル形式のコンテンツを暗号化することになる。
【００１２】
鍵マネージャ３００が、フィーチャ鍵２００をコンテンツ作成者から受け取る。図２の鍵マネージャ３００は、暗号化解除モジュール６０１および６０２のそれぞれと、送信鍵４０１および４０２を交換することになる。暗号化解除モジュール６０１と６０２は両方とも同じ公開施設に位置するが、各モジュールは異なるディジタル映画プロジェクタ（図示せず）に関連する。鍵マネージャと各暗号化解除モジュールの何れかが、交換を開始することになる。図１の鍵マネージャ３０と同様、鍵マネージャ３００は、あるタイプの鍵を別の鍵で暗号化する機能を有するプログラム済みディジタル・コンピュータまたは専用ロジック回路の形式をとる。図２の鍵マネージャ３００は、暗号化解除モジュール６０１および６０２からの各送信鍵４０１および４０２でそれぞれ別々にフィーチャ鍵２００を暗号化して、保護されたフィーチャ鍵５０１および５０２をそれぞれ生み出す。各暗号化解除モジュール６０１および６０２は、送信鍵４０１および４０２のうちの対応する一方をそれぞれ利用してフィーチャ鍵２００を入手し、さらに暗号化済みコンテンツを暗号化解除して表示を可能にする。
【００１３】
図１の鍵管理システム１０では、単一の暗号化解除モジュール６０に関連する送信鍵４０でフィーチャ鍵２０の暗号化を実施するが、この鍵管理システム１０と比較すると、図２の鍵マネージャ３００は、異なる暗号化解除モジュール６０１および６０２の送信鍵で別々にフィーチャ鍵２００を暗号化して、別々の保護されたフィーチャ鍵５０１および５０２をそれぞれ生み出す。別々の保護されたフィーチャ鍵５０１および５０２はそれぞれ、暗号化解除モジュール６０１および６０２のうちの対応する一方でのみ機能することになる。図２の鍵管理システム１００では、映画館のオペレータは、同じ保護されたフィーチャ鍵を複数の暗号化解除モジュールで使用して、確立されたセキュリティ・セーフガードを破ることはできない。
【００１４】
図２の鍵マネージャ３００はまた、各暗号化解除モジュール６０１および６０２と、異なるフィーチャ鍵（フィーチャ鍵２００など）を交換することもできる。このような場合は、鍵マネージャ３００は、送信鍵４０１を利用してフィーチャ鍵２０１（図示せず）を暗号化し、保護されたフィーチャ鍵５０１の代わりに保護されたフィーチャ鍵（図示せず）を生み出して暗号化解除モジュール６０１に送ることになる。暗号化解除モジュール６０１は、その送信鍵４０１を使用してこの保護されたフィーチャ鍵を暗号化解除し、フィーチャ鍵２０１を入手し、暗号化済みコンテンツを暗号化解除して表示を可能にすることになる。同様に、鍵マネージャ３００は、送信鍵４０２を使用して第２のフィーチャ鍵２０２（図示せず）を暗号化し、保護されたフィーチャ鍵５０２の代わりに保護されたフィーチャ鍵（図示せず）を生み出すことになる。鍵マネージャ３００は、この保護されたフィーチャ鍵を暗号化解除モジュール６０２に送り、暗号化解除モジュール６０２は、その送信鍵４０２を使用して保護されたフィーチャ鍵５０４を暗号化解除し、フィーチャ鍵２０２を入手し、暗号化済みコンテンツを暗号化解除して表示を可能にすることになる。
【００１５】
図３に、本原理の第３の実施例により鍵管理を提供するためのシステム１０００のブロック概略図を示す。図３のブロック１５００で表すように、鍵管理プロセスの最初に、映画スタジオなどのコンテンツ作成者がコンテンツ作成に携わる。作成されたコンテンツは、初めにディジタル・キャプチャ・デバイスを使用して作成した結果としてであろうと、初めにフィルム上でキャプチャした画像をディジタル変換した結果としてであろうと、ディジタル形式で存在する。コンテンツ作成者またはそのエージェントは、図３にフィーチャ鍵２０００として示す鍵をコンテンツの暗号化解除に使用することを必要とするいくつかの周知の技術の何れか１つを使用して、ディジタル形式のコンテンツを暗号化することになる。
【００１６】
鍵マネージャ３０００が、フィーチャ鍵２０００をコンテンツ製作者から受け取る。図３の鍵マネージャ３０００は、暗号化解除モジュール６００１〜６００４と、送信鍵４００１〜４００４をそれぞれ交換する。図３の例示的な実施例では、暗号化解除モジュール６００１および６００２は第１の公開施設（映画館Ａ）にあり、暗号化解除モジュール６００３および６００４は第２の公開施設（映画館Ｂ）にある。あるいは、暗号化解除モジュール６００１〜６００４それぞれが別々の公開施設にあってもよい。公開施設の数、およびこのような施設にある暗号化解除モジュールの数は、本原理の鍵管理技術に悪影響を及ぼすことなく変更することができる。鍵マネージャと暗号化解除モジュールの何れかが、交換を開始することになる。鍵マネージャが交換を開始する場合は、鍵マネージャ・システムは通常、少なくとも１つの予想される暗号化解除受信側の固有識別子を、各暗号化解除モジュールに送ることになる。
【００１７】
図２の鍵マネージャ３００と同様、図３の鍵マネージャ３０００は、あるタイプの鍵を別の鍵で暗号化する機能を有するプログラム済みディジタル・コンピュータまたは専用ロジック回路の形式をとる。図３の鍵マネージャ３０００は、暗号化解除モジュール６００１〜６００４からの各送信鍵４００１〜４００４でそれぞれ別々にフィーチャ鍵２０００を暗号化して、保護されたフィーチャ鍵５００１〜５００４をそれぞれ生み出す。各暗号化解除モジュール６００１〜６００４は、保護されたフィーチャ鍵５００１〜５００４のうちの対応する１つをそれぞれ利用して、暗号化済みコンテンツを暗号化解除して表示を可能にする。
【００１８】
図２の鍵マネージャ３００がフィーチャ鍵２００を送信鍵４０１および４０２で別々に暗号化して別々の保護されたフィーチャ鍵５０１および５０２をそれぞれ生み出すのと同様、図３の鍵マネージャ３０００も、フィーチャ鍵２０００を各送信鍵４００１〜４００４でそれぞれ別々に暗号化して、保護されたフィーチャ鍵５００１〜５０００４をそれぞれ生み出す。それぞれの場合に、各暗号化解除モジュールは、そのモジュールに固有の保護されたフィーチャ鍵を受け取る。従って、図２の鍵管理システム１００のように、図３の鍵管理システム１０００では、映画館のオペレータは、同じ保護されたフィーチャ鍵を複数の暗号化解除モジュールで使用して、確立されたセキュリティ・セーフガードを破ることはできない。
【００１９】
複数の暗号化解除モジュールが同じフィーチャの暗号化解除に使用される場合は、そのような暗号化解除モジュールがそれぞれ共通の送信鍵を鍵マネージャに提供するという条件で、図２の鍵マネージャ３００や図３の鍵マネージャ３０００などの鍵マネージャが、同じフィーチャ鍵を提供することができる。そうでない場合は、鍵マネージャは各暗号化解除モジュールに別々の保護されたフィーチャ鍵を提供することになる。
【００２０】
図１〜３の各鍵管理システム１０、１００、および１０００ではそれぞれ、鍵マネージャへのフィーチャ鍵の送信は安全な方式で行われる。論じたように、各鍵マネージャは、どんな予備またはバックアップ暗号化解除モジュールをも含めて、最終的にコンテンツを暗号化解除することになっている各暗号化解除モジュールに関連する送信鍵でフィーチャ鍵を暗号化することによって、個別の保護されたフィーチャ鍵を生み出す。
【００２１】
実際には、フィーチャ鍵２０、２００、２０００はそれぞれ、単一の対称鍵を含む。フィーチャ作成システムと鍵マネージャとの間のフィーチャ鍵の交換は、通常、共有秘密に基づく暗号対称アルゴリズムを使用して行われる。フィーチャ作成システムと鍵マネージャとの間のフィーチャ鍵の交換はまた、鍵マネージャの秘密／公開鍵の対に基づく非対称暗号アルゴリズムを使用して、あるいは安全な認証済みチャネルまたは専用モデム回線を使用して保護することもできる。
【００２２】
同様に、鍵マネージャと暗号化解除モジュールとの間のフィーチャ鍵の交換は、通常、鍵マネージャと暗号化解除モジュールとが暗号的な意味でお互いを相互認証できたという条件で、共有秘密に基づく暗号対称アルゴリズムを使用して行われる。鍵マネージャと暗号化解除モジュールとの間のフィーチャ鍵の交換は、鍵マネージャが暗号化解除モジュールを安全に認証できたという条件で、暗号化解除モジュールの秘密／公開鍵の対に基づく非対称暗号アルゴリズムを使用して保護することができる。
【００２３】
コンテンツを暗号化するには、ディジタル・エンベロープや非対称鍵の使用など、様々な代替方法がある。さらに、コンテンツ暗号化は、単一の鍵ではなく複数の鍵を使用して行うこともでき、各鍵は通常、必須ではないが、フィーチャの時間的セグメントに関連する。コンテンツをセグメント化して複数の鍵の使用を可能にするには、フィーチャをＮ個（ただし、Ｎは０（零）よりも大きい。）の連続的なセグメントにセグメント化することなど、様々な方法がある。複数のフィーチャ暗号化鍵を利用する場合、図１に述べたシステムを修正して、システム・レベルとフィーチャ暗号化解除レベルの両方で動作を最適化することができる。例えば、図１に示すように、鍵管理システム３０はまず、フィーチャ鍵をマスタ鍵で暗号化し、マスタ鍵を送信鍵４０で暗号化し（送信鍵は、暗号化解除モジュールの公開鍵、または鍵マネージャと暗号化解除モジュールとの間で交換される対称鍵とすることができる）、両方の結果を暗号化解除モジュール６０に送ることができる。コンテンツ暗号化はまた、非対称スクランブル化または暗号化アルゴリズムを使用して行うこともできる。さらに、コンテンツは、追加の鍵を使用して超スクランブル化または超暗号化をかけることもできる。例えば、フィーチャをまずフィーチャ鍵で暗号化し、次いで追加の鍵で暗号化する（またはこの逆）。コンテンツ暗号化はまた、フィーチャ鍵と他の情報とから得られる鍵を使用して行うこともできる。他の情報とは、鍵管理システムの識別、暗号化解除モジュール、時刻、日付、および／またはこれらの任意の組合せなどだが、これらに限定されない。
【００２４】
好ましい一実施例では、送信鍵は、非対称暗号鍵の対によって提供される、暗号化解除モジュールの公開鍵を含む。送信鍵は、定期的に、ランダムに、または要求があり次第、変更することができる。
【００２５】
各暗号化解除モジュールは、その公開鍵を鍵マネージャに送信する。このような送信は個別に行うことができる（すなわち、暗号化解除モジュールは鍵マネージャへの直接接続を有する）。あるいは、１組の暗号化解除モジュール、例えば単一の公開施設にあるすべての暗号化解除モジュールが、それぞれの公開鍵を単一メッセージ内で鍵管理システムに送ることもできる。通信リンクは、無線または有線チャネルを含むことができる。送信鍵に関する非対称アプローチの代替方法には、事前に合意した対称鍵の使用や、ＭＡＣベースの方法などを含めることができる。本原理の鍵管理技術は、フィーチャ暗号化鍵に暗号化解除モジュール・レベルでのみアクセス可能であり他のどんな中間モジュールからもアクセス不可能な方式で、フィーチャ暗号化鍵を保護する利点をもたらす。
【００２６】
各暗号化解除モジュール６０、６０１〜６０２、および６００１〜６００４は、公開施設にある物理デバイスとの関連を有する。物理デバイスとは例えば、セキュリティ・モジュール（図示せず）、プロジェクタ（図示せず）、コンテンツ処理デバイス（図示せず）などだが、これらに限定されない。暗号化解除モジュールの実際の位置は、本原理の鍵管理技術にまったく関係ない。必要であることは、各暗号化解除モジュールがその識別を鍵マネージャに知られており、両者が送信鍵を相互と交換する機能を有することである。別々に示したが、鍵管理システムは、映画館内の物理デバイス（上述）の一部として存在してもよく、あるいはコンテンツ作成システムの一部として存在してもよい。
【００２７】
暗号化解除モジュールは、鍵マネージャへの直接通信リンクを所有している必要はない。そのような場合は、中継エンティティ、例えばＤＣＩおよびＳＭＰＴＥ文書に記載されているシアター管理システム（Ｔｈｅａｔｅｒ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）やセキュリティ・モジュール（図示せず）が、鍵マネージャからのメッセージを取り込み、適切な暗号化解除モジュールに中継することができる。
【００２８】
以上、暗号化済みコンテンツの暗号化解除とともに鍵を管理する技術について述べた。
【特許請求の範囲】
【請求項１】
少なくとも１つの暗号化解除モジュールに関連付けられた少なくとも１つの送信鍵で、暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して、少なくとも１つの保護されたフィーチャ鍵を生成するステップと、
前記保護されたフィーチャ鍵を前記少なくとも１つの暗号化解除モジュールに供給して、前記暗号化済みコンテンツの暗号化解除を可能にするステップと、
を含む鍵管理方法。
【請求項２】
前記暗号化するステップは、複数の暗号化解除モジュールの別々の１つに関連付けられた複数の送信鍵のそれぞれで、前記フィーチャ鍵を暗号化して、複数の別々の保護されたフィーチャ鍵をそれぞれ生成するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項３】
前記供給するステップは、前記保護されたフィーチャ鍵のそれぞれを前記複数の暗号化解除モジュールの別々の１つに提供するステップをさらに含む、請求項２に記載の鍵管理方法。
【請求項４】
前記暗号化するステップは、前記暗号化を実施する鍵マネージャにおいて前記暗号化解除モジュールから前記送信鍵を受け取るステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項５】
前記受け取るステップは、複数の送信鍵のそれぞれを別々の暗号化解除モジュールから別々に受け取るステップをさらに含む、請求項４に記載の鍵管理方法。
【請求項６】
前記受け取るステップは、複数の送信鍵それぞれを別々の暗号化解除モジュールから単一のメッセージ・グループとして受け取ることをさらに含む、請求項４に記載の鍵管理方法。
【請求項７】
前記供給するステップは、前記少なくとも１つの保護されたフィーチャ鍵を安全な送信チャネルを介して供給するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項８】
前記提供するステップは、前記少なくとも１つの保護されたフィーチャ鍵を安全な無線送信チャネルを介して供給するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項９】
前記供給するステップは、前記少なくとも１つの保護されたフィーチャ鍵を安全な有線送信チャネルを介して提供するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項１０】
前記暗号化するステップは、フィーチャ作成システムと鍵マネージャとの間で前記フィーチャ鍵を交換し、共有秘密に基づく暗号対称アルゴリズムを使用してそのような交換を保護するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項１１】
前記暗号化するステップは、フィーチャ作成システムと鍵マネージャとの間で前記フィーチャ鍵を交換し、前記鍵マネージャの秘密／公開鍵の対に基づく非対称暗号アルゴリズムを使用してそのような交換を保護するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項１２】
前記暗号化するステップは、前記フィーチャ作成システムと前記鍵マネージャとの間で前記フィーチャ鍵を交換し、保護された認証済みチャネルおよび専用モデム回線の一方を使用してそのような交換を保護するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項１３】
フィーチャ作成システムからフィーチャ鍵を受け取り、少なくとも１つの保護されたフィーチャ鍵を少なくとも１つの暗号化解除モジュールに配布するための鍵マネージャ・システムであって、
（１）前記フィーチャ作成システムからのフィーチャ鍵を前記少なくとも１つの暗号化解除モジュールからの送信鍵で暗号化して、保護されたフィーチャ鍵を生成し、
（２）前記保護されたフィーチャ鍵を前記少なくとも１つの暗号化解除モジュールに供給して、暗号化済みコンテンツの暗号化解除を可能にする鍵マネージャを備えるシステム。
【請求項１４】
前記フィーチャ作成システムおよび前記鍵マネージャは、単一のエンティティとして存在する、請求項１３に記載のシステム。
【請求項１５】
前記鍵マネージャおよび前記暗号化解除モジュールは単一のエンティティとして存在する、請求項１３に記載のシステム。
【請求項１６】
前記コンテンツは非対称または対称のスクランブル化アルゴリズムと暗号化アルゴリズムのうちの一方を使用して暗号化される、請求項１３に記載のシステム。
【請求項１７】
前記コンテンツは第１および第２の鍵で超暗号化される、請求項１３に記載のシステム。
【請求項１８】
前記コンテンツは前記フィーチャ鍵と他の情報とから得られる鍵を使用して暗号化される、請求項１３に記載のシステム。
【請求項１９】
前記コンテンツは複数のフィーチャ鍵で暗号化され、各鍵は前記フィーチャの時間的セグメントに関連する、請求項１３に記載のシステム。
【請求項２０】
前記鍵マネージャはすべてのフィーチャ鍵をマスタ鍵で暗号化して、前記マスタ鍵を前記送信鍵で暗号化し、前記マスタ鍵は当該鍵マネージャ・システムと前記１つまたは複数の暗号化解除モジュールとの間の共有秘密である、請求項１３に記載のシステム。
【請求項２１】
前記鍵マネージャ・システムはすべてのフィーチャ鍵をマスタ鍵で暗号化して、前記マスタ鍵を前記送信鍵で暗号化し、前記マスタ鍵は前記鍵マネージャ・システムの非対称暗号秘密／公開鍵の対を使用して保護される、請求項１３に記載のシステム。
【請求項２２】
前記鍵マネージャはすべてのフィーチャ鍵をマスタ鍵で暗号化して、前記マスタ鍵を前記送信鍵で暗号化し、前記マスタ鍵は前記暗号化解除モジュールの非対称暗号秘密／公開鍵の対を使用して保護される、請求項１３に記載のシステム。
【請求項２３】
前記鍵マネージャは、各暗号化解除モジュールごとに異なる送信鍵を使用して前記フィーチャ鍵を送る、請求項２２に記載のシステム。
【請求項２４】
前記鍵マネージャは、すべての暗号化解除モジュールに共通の送信鍵を使用して前記フィーチャ鍵を複数の暗号化解除モジュールに送る、請求項２２に記載のシステム。
【請求項２５】
前記鍵マネージャは、暗号化解除モジュールの所定の部分集合に対する定義された送信鍵を使用して前記フィーチャ鍵を送る、請求項２２に記載のシステム。
【請求項２６】
前記鍵マネージャが前記送信鍵の交換を開始する、請求項２２に記載のシステム。
【請求項２７】
前記暗号化解除モジュールが前記送信鍵の交換を開始する、請求項２２に記載のシステム。
【請求項２８】
当該鍵マネージャ・システムは、少なくとも１つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る、請求項１３に記載のシステム。
【請求項２９】
前記フィーチャ鍵は、前記送信鍵を利用する対称暗号化アルゴリズムとスクランブル化アルゴリズムのうちの一方を使用して保護される、請求項１３に記載のシステム。
【請求項３０】
前記フィーチャ鍵は、前記送信鍵から得られる鍵を利用する対称暗号化アルゴリズムを使用して保護される、請求項１３に記載のシステム。
【請求項３１】
前記フィーチャ鍵は、前記鍵マネージャと前記暗号化解除モジュールとの間で共有される鍵を利用する対称暗号化アルゴリズムまたはスクランブル化アルゴリズムを使用して保護される、請求項１３に記載のシステム。
【請求項３２】
前記フィーチャ鍵は、前記鍵マネージャの秘密／公開鍵に基づく非対称暗号化アルゴリズムを使用して保護される、請求項１３に記載のシステム。
【請求項３３】
前記フィーチャ鍵は、前記暗号化解除モジュールの秘密／公開鍵に基づく非対称暗号化アルゴリズムを使用して保護される、請求項１３に記載のシステム。
【請求項３４】
前記フィーチャ鍵は、前記送信鍵と他の情報とに基づいて生成される非対称暗号ベースの秘密／公開鍵の対を使用して保護される、請求項１３に記載のシステム。
【請求項３５】
前記保護されたフィーチャ鍵の配布は安全なチャネルを介して行われる、請求項１３に記載のシステム。
【請求項１】
少なくとも１つの暗号化解除モジュールに関連付けられた少なくとも１つの送信鍵で、暗号化済みコンテンツに関連付けられたフィーチャ鍵を暗号化して、少なくとも１つの保護されたフィーチャ鍵を生成するステップと、
前記保護されたフィーチャ鍵を前記少なくとも１つの暗号化解除モジュールに供給して、前記暗号化済みコンテンツの暗号化解除を可能にするステップと、
を含む鍵管理方法。
【請求項２】
前記暗号化するステップは、複数の暗号化解除モジュールの別々の１つに関連付けられた複数の送信鍵のそれぞれで、前記フィーチャ鍵を暗号化して、複数の別々の保護されたフィーチャ鍵をそれぞれ生成するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項３】
前記供給するステップは、前記保護されたフィーチャ鍵のそれぞれを前記複数の暗号化解除モジュールの別々の１つに提供するステップをさらに含む、請求項２に記載の鍵管理方法。
【請求項４】
前記暗号化するステップは、前記暗号化を実施する鍵マネージャにおいて前記暗号化解除モジュールから前記送信鍵を受け取るステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項５】
前記受け取るステップは、複数の送信鍵のそれぞれを別々の暗号化解除モジュールから別々に受け取るステップをさらに含む、請求項４に記載の鍵管理方法。
【請求項６】
前記受け取るステップは、複数の送信鍵それぞれを別々の暗号化解除モジュールから単一のメッセージ・グループとして受け取ることをさらに含む、請求項４に記載の鍵管理方法。
【請求項７】
前記供給するステップは、前記少なくとも１つの保護されたフィーチャ鍵を安全な送信チャネルを介して供給するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項８】
前記提供するステップは、前記少なくとも１つの保護されたフィーチャ鍵を安全な無線送信チャネルを介して供給するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項９】
前記供給するステップは、前記少なくとも１つの保護されたフィーチャ鍵を安全な有線送信チャネルを介して提供するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項１０】
前記暗号化するステップは、フィーチャ作成システムと鍵マネージャとの間で前記フィーチャ鍵を交換し、共有秘密に基づく暗号対称アルゴリズムを使用してそのような交換を保護するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項１１】
前記暗号化するステップは、フィーチャ作成システムと鍵マネージャとの間で前記フィーチャ鍵を交換し、前記鍵マネージャの秘密／公開鍵の対に基づく非対称暗号アルゴリズムを使用してそのような交換を保護するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項１２】
前記暗号化するステップは、前記フィーチャ作成システムと前記鍵マネージャとの間で前記フィーチャ鍵を交換し、保護された認証済みチャネルおよび専用モデム回線の一方を使用してそのような交換を保護するステップをさらに含む、請求項１に記載の鍵管理方法。
【請求項１３】
フィーチャ作成システムからフィーチャ鍵を受け取り、少なくとも１つの保護されたフィーチャ鍵を少なくとも１つの暗号化解除モジュールに配布するための鍵マネージャ・システムであって、
（１）前記フィーチャ作成システムからのフィーチャ鍵を前記少なくとも１つの暗号化解除モジュールからの送信鍵で暗号化して、保護されたフィーチャ鍵を生成し、
（２）前記保護されたフィーチャ鍵を前記少なくとも１つの暗号化解除モジュールに供給して、暗号化済みコンテンツの暗号化解除を可能にする鍵マネージャを備えるシステム。
【請求項１４】
前記フィーチャ作成システムおよび前記鍵マネージャは、単一のエンティティとして存在する、請求項１３に記載のシステム。
【請求項１５】
前記鍵マネージャおよび前記暗号化解除モジュールは単一のエンティティとして存在する、請求項１３に記載のシステム。
【請求項１６】
前記コンテンツは非対称または対称のスクランブル化アルゴリズムと暗号化アルゴリズムのうちの一方を使用して暗号化される、請求項１３に記載のシステム。
【請求項１７】
前記コンテンツは第１および第２の鍵で超暗号化される、請求項１３に記載のシステム。
【請求項１８】
前記コンテンツは前記フィーチャ鍵と他の情報とから得られる鍵を使用して暗号化される、請求項１３に記載のシステム。
【請求項１９】
前記コンテンツは複数のフィーチャ鍵で暗号化され、各鍵は前記フィーチャの時間的セグメントに関連する、請求項１３に記載のシステム。
【請求項２０】
前記鍵マネージャはすべてのフィーチャ鍵をマスタ鍵で暗号化して、前記マスタ鍵を前記送信鍵で暗号化し、前記マスタ鍵は当該鍵マネージャ・システムと前記１つまたは複数の暗号化解除モジュールとの間の共有秘密である、請求項１３に記載のシステム。
【請求項２１】
前記鍵マネージャ・システムはすべてのフィーチャ鍵をマスタ鍵で暗号化して、前記マスタ鍵を前記送信鍵で暗号化し、前記マスタ鍵は前記鍵マネージャ・システムの非対称暗号秘密／公開鍵の対を使用して保護される、請求項１３に記載のシステム。
【請求項２２】
前記鍵マネージャはすべてのフィーチャ鍵をマスタ鍵で暗号化して、前記マスタ鍵を前記送信鍵で暗号化し、前記マスタ鍵は前記暗号化解除モジュールの非対称暗号秘密／公開鍵の対を使用して保護される、請求項１３に記載のシステム。
【請求項２３】
前記鍵マネージャは、各暗号化解除モジュールごとに異なる送信鍵を使用して前記フィーチャ鍵を送る、請求項２２に記載のシステム。
【請求項２４】
前記鍵マネージャは、すべての暗号化解除モジュールに共通の送信鍵を使用して前記フィーチャ鍵を複数の暗号化解除モジュールに送る、請求項２２に記載のシステム。
【請求項２５】
前記鍵マネージャは、暗号化解除モジュールの所定の部分集合に対する定義された送信鍵を使用して前記フィーチャ鍵を送る、請求項２２に記載のシステム。
【請求項２６】
前記鍵マネージャが前記送信鍵の交換を開始する、請求項２２に記載のシステム。
【請求項２７】
前記暗号化解除モジュールが前記送信鍵の交換を開始する、請求項２２に記載のシステム。
【請求項２８】
当該鍵マネージャ・システムは、少なくとも１つの予想される暗号化解除受信側の固有識別子を前記暗号化解除モジュールに送る、請求項１３に記載のシステム。
【請求項２９】
前記フィーチャ鍵は、前記送信鍵を利用する対称暗号化アルゴリズムとスクランブル化アルゴリズムのうちの一方を使用して保護される、請求項１３に記載のシステム。
【請求項３０】
前記フィーチャ鍵は、前記送信鍵から得られる鍵を利用する対称暗号化アルゴリズムを使用して保護される、請求項１３に記載のシステム。
【請求項３１】
前記フィーチャ鍵は、前記鍵マネージャと前記暗号化解除モジュールとの間で共有される鍵を利用する対称暗号化アルゴリズムまたはスクランブル化アルゴリズムを使用して保護される、請求項１３に記載のシステム。
【請求項３２】
前記フィーチャ鍵は、前記鍵マネージャの秘密／公開鍵に基づく非対称暗号化アルゴリズムを使用して保護される、請求項１３に記載のシステム。
【請求項３３】
前記フィーチャ鍵は、前記暗号化解除モジュールの秘密／公開鍵に基づく非対称暗号化アルゴリズムを使用して保護される、請求項１３に記載のシステム。
【請求項３４】
前記フィーチャ鍵は、前記送信鍵と他の情報とに基づいて生成される非対称暗号ベースの秘密／公開鍵の対を使用して保護される、請求項１３に記載のシステム。
【請求項３５】
前記保護されたフィーチャ鍵の配布は安全なチャネルを介して行われる、請求項１３に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１３−６６１８７（Ｐ２０１３−６６１８７Ａ）
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−２３６３６５（Ｐ２０１２−２３６３６５）
【出願日】平成２４年１０月２６日（２０１２．１０．２６）
【分割の表示】特願２００７−５５５１０４（Ｐ２００７−５５５１０４）の分割
【原出願日】平成１８年１月１８日（２００６．１．１８）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願番号】特願２０１２−２３６３６５（Ｐ２０１２−２３６３６５）
【出願日】平成２４年１０月２６日（２０１２．１０．２６）
【分割の表示】特願２００７−５５５１０４（Ｐ２００７−５５５１０４）の分割
【原出願日】平成１８年１月１８日（２００６．１．１８）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]