(57)【要約】  共通ドメイン鍵を共有する複数の装置を有するドメインにおいて、前記ドメインのメンバではないエンティティが、前記共通ドメイン鍵を用いて認証及び／又は復号化されることができるオブジェクトを生成することを可能とする方法であって、前記方法は、前記オブジェクトに関連する認証データを生成するための及び／又は前記オブジェクトを暗号化するための、少なくとも前記共通ドメイン鍵から一方向関数を用いて導出される多様化鍵を、前記ドメインのメンバではないエンティティに供給するステップを有し、前記ドメイン中の装置は、前記多様化鍵を用いて前記オブジェクトを認証及び／又は復号化するように構成される方法。
2009535958.tif 000002
【特許請求の範囲】
【請求項１】
共通ドメイン鍵を共有する複数の装置を有するドメインにおいて、前記ドメインのメンバではないエンティティが、前記共通ドメイン鍵を用いて認証及び／又は復号化されることができるオブジェクトを生成することを可能とする方法であって、
前記オブジェクトに関連する認証データを生成するための及び／又は前記オブジェクトの少なくとも一部を暗号化するための、少なくとも前記共通ドメイン鍵から一方向関数を用いて導出される多様化鍵を、前記ドメインのメンバではないエンティティに供給するステップと、
前記多様化鍵を用いて前記オブジェクトを認証及び／又は復号化するステップと、
を有する方法。
【請求項２】
前記一方向関数は、符号化された暗号ハッシュ関数を有する、請求項１に記載の方法。
【請求項３】
前記符号化された暗号ハッシュ関数において利用される入力は、前記ドメインのメンバではないエンティティの識別子の表現を有し、利用される鍵は前記共通ドメイン鍵である、請求項２に記載の方法。
【請求項４】
前記多様化鍵は、前記一方向関数の出力を所定の数のビットにまで切り捨てることにより導出される、請求項１に記載の方法。
【請求項５】
前記ドメインのメンバではないエンティティの識別子の表現を有するディジタル的に署名された確認トークンを生成するステップを更に有する、請求項１に記載の方法。
【請求項６】
前記共通ドメイン鍵を用いて、前記ドメインのメンバではないエンティティにより供給されるオブジェクトについてのメッセージ認証コードを生成するステップを更に有する、請求項１に記載の方法。
【請求項７】
前記オブジェクトは、コンテンツにアクセスするためのディジタル権利を有する、請求項１に記載の方法。
【請求項８】
前記共通ドメイン鍵から及び前記ドメインのメンバではないエンティティの識別子の表現から、前記一方向関数を用いて前記多様化鍵を導出するステップを有する、請求項１に記載の方法。
【請求項９】
複数の装置を有するドメインを有するシステムであって、前記ドメイン中の装置は共通ドメイン鍵を共有し、前記システムは、前記オブジェクトに関連する認証データを生成するための及び／又は前記オブジェクトを暗号化するための、少なくとも前記共通ドメイン鍵から一方向関数を用いて導出される多様化鍵を、前記ドメインのメンバではないエンティティに供給するステップを有することにより、前記ドメインのメンバではないエンティティが、前記共通ドメイン鍵を用いて認証及び／又は復号化されることができるオブジェクトを生成することを可能とするように構成され、前記ドメイン中の装置は、前記多様化鍵を用いて前記オブジェクトを認証及び／又は復号化するように構成されたシステム。
【請求項１０】
ドメインに含まれる装置であって、前記ドメイン中の装置は共通ドメイン鍵を共有し、前記装置は、前記ドメインのメンバではないエンティティからオブジェクトを受信し、少なくとも前記共通ドメイン鍵から一方向関数を用いて多様化鍵を導出し、前記多様化鍵を用いてオブジェクトを認証及び／又は復号化するように構成された装置。
【請求項１１】
前記共通ドメイン鍵を用いて前記オブジェクトについてのメッセージ認証コードを計算し、前記計算されたメッセージ認証コードと共に前記オブジェクトを前記ドメイン中の他の装置へと配布するように構成された、請求項１０に記載の装置。
【請求項１２】
新たな共通ドメイン鍵を受信し、前記新たな共通ドメイン鍵を用いて前記オブジェクトについての新たなメッセージ認証コードを計算し、前記計算されたメッセージ認証コードと共に前記オブジェクトを前記ドメイン中の他の装置へと配布するように構成された、請求項１１に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、改善されたドメインへのアクセスに関する。
【背景技術】
【０００２】
近年、利用可能なコンテンツ保護システムの数は、急速に増加している。これらシステムの幾つかは、認可されていないコピーに対してのみコンテンツを保護し、他のものはコンテンツにアクセスする又はコンテンツを利用するユーザの能力を制限する。これらのシステムはしばしば、ディジタル権利管理（Digital Rights Management、ＤＲＭ）システムと呼ばれる。
【０００３】
消費者は、困難なく、可能な限り少ない制約で、コンテンツを楽しみたいと欲する。消費者は、全てのタイプの種々のアプリケーションをイネーブルにし、いずれのタイプのコンテンツにも容易にアクセスするように、自身の装置をネットワーク接続したいと欲する。消費者はまた、自身の家庭の環境において、制約なくコンテンツを共有／転送することが可能であることを欲する。
【０００４】
認可されたドメイン（Authorized Domains、ＡＤ）の概念は、コンテンツ所有者（自身の著作権の保護を望む）及びコンテンツ消費者（コンテンツの制約されない利用を望む）の双方の利益に資するための解決方法を見出そうとするものである。基本原理は、コンテンツが認可されたドメインの境界を越えない限り、該コンテンツが比較的に自由に利用されることができる、制御されたネットワーク環境を持つことである。一般に、認可されたドメインは、家庭用ネットワークとも呼ばれる、家庭の環境を中心とする。
【０００５】
勿論、他の状況もあり得る。ユーザは例えば、限られたコンテンツの容量を持つオーディオ及び／又はビデオ用の携帯型装置を旅行に持って行き、家庭内にある該ユーザの個人的なオーディオ及び／又はビデオシステムに保存された更なるコンテンツにアクセスし該コンテンツをダウンロードするために、該ユーザのホテルの部屋で該装置を利用し得る。該携帯型装置が家庭用ネットワークの外部にあっても、該携帯型装置はユーザの認可されたドメインの一部である。このように、認可されたドメイン（ＡＤ）は、該ドメイン内の装置によるコンテンツへのアクセスを許可し、他の装置によるアクセスは許可しないシステムである。
【０００６】
認可されたドメインは、認可されたドメインの識別、装置のチェックイン、装置のチェックアウト、権利のチェックイン、権利のチェックアウト、コンテンツのチェックイン、コンテンツのチェックアウト、及びドメイン管理のような問題に対処する必要がある。認可されたドメインの使用に対するより広範な紹介については、S. A. F. A. van den Heuvel、W. Jonker、F. L. A. J. Kamperman及びP. J. Lenoirによる「Secure Content Management in Authorized Domains」（Philips Research、オランダ、IBC 2002 conference publication、467-474頁、2002年9月12-16日）を参照されたい。
【０００７】
認可されたドメインのための特定のアーキテクチャにおいては、当該ドメイン中のエンティティ（例えば装置）が、数あるなかでも、当該ドメインにおいて利用可能なコンテンツ又はライセンス（権利オブジェクト）のようなオブジェクトを生成、アクセス及び／又は認証するために利用される、対称ドメイン鍵を共有する。一例は、Open Mobile AllianceのＤＲＭアーキテクチャの第２のバージョンである、Approved Version 2.0（OMA-AD-DRM-V2_0-20060303-A、2006年3月3日）である（以下、略してＯＭＡ ＤＲＭ ｖ２と呼ばれる）。該文献は、member.openmobilealliance.org/ftp/public_documents/bac/DLDRM/Permanent_documents/においてインターネット上で利用可能であり、参照により本明細書に組み込まれたものとする。他の例は、国際特許出願公開WO2005/088896（整理番号PHNL040288）である。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
斯かるアーキテクチャにおいては、ドメイン鍵は、メンバでないエンティティには利用可能とされない。なぜなら該鍵が、メンバでないエンティティが、該ドメインのメンバではないにもかかわらず、保護されたオブジェクトにアクセスすることを可能にしてしまうことになるからである。しかし、メンバでない特定のエンティティが、該ドメインにおけるエンティティによる使用のためのオブジェクトを生成することを可能とされることが望ましい。これらメンバでないエンティティに異なる鍵を発行することも勿論可能であるが、このことは各ドメインにおける各装置が、これらの鍵の全てのコピーを保持することを要求する。
【０００９】
本発明の目的は、認可されたドメインのメンバではないエンティティにドメイン鍵を供給することなく、該エンティティが、該認可されたドメインのメンバにより利用可能なオブジェクトを生成することを可能とすることにある。
【課題を解決するための手段】
【００１０】
本目的は、請求項１に記載の方法により達成される。ドメインのメンバではない装置又はその他のエンティティに、一方向関数を用いて共通ドメイン鍵から導出された多様化鍵（diversified key）を供給することにより、当該装置が、該多様化鍵を用いてこれらオブジェクトに関連する認証データを生成すること及び／又はこれらオブジェクトを暗号化することが可能となる。該ドメイン中の装置は、必要とされるときに、これら装置に利用可能なドメイン鍵から一方向関数を用いて多様化鍵を生成することができる。これら装置は次いで、メンバではないエンティティから受信されたオブジェクトを認証及び／又は復号化するために、該多様化鍵を利用することができる。
【００１１】
本発明によれば、メンバでないエンティティはドメイン鍵にアクセスすることはできないが、該ドメイン中の装置により認証及び／又は復号化されることができるオブジェクトを生成することが可能である。このことは、ＯＭＡ ＤＲＭ権利オブジェクトのような斯かるオブジェクトを、どのエンティティが該ドメインに発行することができるかについての、優れた制御を提供する。
【００１２】
好適には、該多様化鍵は、共通ドメイン鍵から、及び該ドメインのメンバではないエンティティの識別子の表現から、一方向関数を利用して導出される。このことは、異なるエンティティが、異なる多様化鍵を受信するという利点を持つ。
【００１３】
好適な実施例においては、前記一方向関数は、符号化された暗号ハッシュ関数を有する。該関数における入力として、当該ドメインのメンバではないエンティティの識別子の表現（当該装置に関連する公開鍵のような）を利用しても良い。認証又は暗号化アルゴリズムが、鍵が特定の長さであることを要求する場合には、該一方向関数の出力を、必要とされる数のビットへと切り捨てても良い。例えば、１２８ビットの鍵を用いるＡＥＳ暗号化アルゴリズムによる多様化鍵を利用する場合には、ＳＨＡ−１一方向ハッシュ関数を用いて生成された鍵は、１６０ビットから１２８ビットへと切り捨てられるべきである。
【００１４】
好適な実施例においては、メンバでないエンティティは、コンテンツアイテムに関連付けられたディジタル権利を発行するように構成された権利発行器である。本実施例においては、ディジタル権利を有するコンテンツは、前記多様化鍵を利用して暗号化される。
【００１５】
一実施例においては、本方法は更に、前記ドメインのメンバではないエンティティの識別子の表現を有するディジタル的に署名された確認トークンを生成するステップを有する。
【００１６】
更なる実施例においては、本方法は、当該ドメインのメンバではないエンティティにより供給されたオブジェクトについて、共通ドメイン鍵を利用して、メッセージ認証コードを生成するステップを有する。他の装置から斯かるオブジェクトを受信する装置はここではまた、正当なメッセージ認証コードの存在を必要とする。このことは、メンバではないエンティティが、特定のドメインについての正当なオブジェクトを生成し、これらオブジェクトを異なるチャネルを通して利用可能とすることを防止する。
【００１７】
本発明は更に、本方法を実行するためのシステム及び装置を提供する。
【００１８】
他の有利な実施例は、従属請求項において記載される。
【００１９】
本発明のこれらの及び他の態様は、図面において示された例示的な実施例を参照しながら説明され、明らかとなるであろう。
【００２０】
図面を通して、同一の参照番号は類似する又は対応する特徴を示す。図面において示される特徴の幾つかは、典型的にはソフトウェアで実装され、それ自体がソフトウェアモジュール又はオブジェクトのようなソフトウェアエンティティを表す。
【発明を実施するための最良の形態】
【００２１】
図１は、ネットワーク１１０を介して相互接続された装置１０１乃至１０５を有するシステム１００を模式的に示す。典型的なディジタル家庭ネットワークは、例えば無線受信器、チューナ／デコーダ、ＣＤプレイヤ、一対のスピーカ、テレビジョン、ＶＣＲ、ディジタルレコーダ、モバイル電話、テープデッキ、パーソナルコンピュータ、パーソナルディジタルアシスタント、携帯型ディスプレイユニット、車載娯楽システム等のような、幾つかの装置を含む。これら装置は通常、或る装置（例えばテレビジョン）が別の装置（例えばＶＣＲ）を制御することを可能とするように、相互接続されている。幾つかの実施例においては、例えばチューナ／デコーダ又はセットトップボックス（ＳＴＢ）のような或る装置が、中央装置として動作し、他の装置に対する中央制御を提供する。
【００２２】
コンテンツ（典型的には音楽、曲、映画、アニメーション、音声、音楽用ビデオクリップ、ＴＶ番組、画像、ゲーム、着信音、音声書籍等のようなものを有するが、インタラクティブなサービスをも含んでも良い）は、広帯域幅ケーブルネットワーク、インターネット接続、衛星ダウンリンク、モバイル電話網、ディスク又は携帯型装置のような記憶媒体といった、種々のソースを介して受信される。コンテンツは次いで、ネットワーク１１０を通して、レンダリングのためのシンクへと転送されても良い。シンクは例えば、テレビジョンディスプレイ１０２、携帯型表示装置１０３、モバイル電話１０４及び／又はオーディオ再生装置１０５であっても良い。
【００２３】
コンテンツアイテムがレンダリングされる厳密な方法は、装置のタイプ及びコンテンツのタイプに依存する。例えば、無線受信器においては、レンダリングは、オーディオ信号を生成して該信号をラウドスピーカに供給することを有する。テレビジョン受信器については、レンダリングは一般に、オーディオ及びビデオ信号を生成し、これら信号を表示画面及びラウドスピーカに供給することを有する。他のタイプのコンテンツについては、同様の適切な動作がとられる必要がある。レンダリングはまた、受信された信号を復号化又はスクランブル解除すること、並びにオーディオ及びビデオ信号を同期させること等のような動作を含んでも良い。
【００２４】
システム１００におけるセットトップボックス１０１又は他のいずれかの装置は、受信されたコンテンツの記録及び後の再生を可能とする、適切に容量の大きなハードディスクのような記憶媒体Ｓ１を有しても良い。記憶媒体Ｓ１は、セットトップボックス１０１が接続された、例えばＤＶＤ＋ＲＷレコーダのような、或る種の個人向けディジタルレコーダ（ＰＤＲ）であっても良い。コンテンツは、コンパクトディスク（ＣＤ）又はディジタルバーサタイルディスク（ＤＶＤ）のような担体１２０に保存されて、システム１００に入力されても良い。
【００２５】
携帯型表示装置１０３及びモバイル電話１０４は、例えばBluetooth（登録商標）又はIEEE802.11bを利用して、基地局１１１を用いてネットワーク１１０に無線で接続されている。他の装置は、従来の有線の接続を利用して接続されている。装置１０１乃至１０５がインタラクトすることを可能とするため、異なる装置がメッセージ及び情報を交換し互いを制御することを可能とする、幾つかの相互運用性規格が利用可能である。良く知られた規格のひとつは、ユニバーサルプラグアンドプレイ（Universal Plug and Play）規格である（http://www.upnp.org）。
【００２６】
システム１００は、好ましくはＯＭＡ ＤＲＭ ｖ２規格又はその後継規格に従って、認可されたドメイン（ＡＤ）として動作することにより、コンテンツへのアクセスを管理するように構成される。図２は、ＯＭＡ ＤＲＭ ｖ２規格に従う模式的なアーキテクチャの図を示す。
【００２７】
図２において、コンテンツ発行器（ＣＩ）２０１は、該ＡＤにおける装置（ここでは装置１０１）に対して、コンテンツ２１０を保護された形態で利用可能とする（ＯＭＡの用語で「ＤＲＭコンテンツ」）。コンテンツ２１０にアクセスするため、装置１０１は、権利発行器（ＲＩ）２０２により供給される権利オブジェクト（ＲＯ）２１２を必要とする。ＲＯ２１２の供給は、ＤＲＭコンテンツ２１０の供給と同時に実行されても良いが、このことは必須ではない。例えば、或る時点にコンテンツを取得し、後に当該コンテンツにアクセスするためＲＯを購入しても良い。代替として、ＲＯを取得して、該ＲＯが適用されるコンテンツを後に取得しても良い。
【００２８】
ＯＭＡ ＤＲＭにおいては、ＲＯは、ＤＲＭコンテンツに関連付けられた許可及び制約を規定するＸＭＬ文書である。ＤＲＭコンテンツは関連するＲＯなしでは利用されることができず、ＲＯに規定された許可及び制約に従ってのみ利用され得る。ＲＯは、実際のコンテンツをレンダリングするために必要とされる権利表現及び鍵を含む。ＲＯの取得、装置の登録及びドメイン管理は、ＲＯＡＰと呼ばれるプロトコルのセットによって規定される。
【００２９】
装置１０１乃至１０５のそれぞれは、通常問題となる装置上で実行されるソフトウェアコンポーネントとして実施化される、ＤＲＭエージェントを持つ。ＤＲＭエージェントは、ＲＯにおいて規定されている許可及び制約に準拠していることを保証する。権利オブジェクトは、特定のＤＲＭエージェントに暗号的に結び付けられ、従って当該ＤＲＭエージェントのみが該権利オブジェクトを利用できる。
【００３０】
ＤＲＭコンテンツ２１０は、装置１０１乃至１０５の間で自由に配布されても良く、また例えば記憶媒体Ｓ１に保存されても良く、又は他の団体へと配布されても良い。しかしながら、正当なＲＯがなければ、ＤＲＭコンテンツ２１０はアクセスされることができない。例えば装置１０５がＤＲＭコンテンツ２１０のコピーを取得するものとすると、装置１０５は該装置のＤＲＭエージェントに結び付けられたＲＯをも取得する必要があることなる。ＲＯ２１２は、装置１０１のＤＲＭエージェントによってのみ利用可能である。
【００３１】
コンテンツに対するドメインベースのアクセスを生成するため、ＯＭＡ ＤＲＭはまた、単一のエージェントではなくＤＲＭエージェントの群に結び付けられた権利オブジェクトの生成及び配布を許容する。斯かる群はドメインと呼ばれ、ドメインに結び付けられた権利オブジェクトはドメイン権利オブジェクトと呼ばれる。ドメインに参加するためには、装置１０１は最初に、ドメインに参加することが許可されるか否かを権利発行器２０２に尋ねる必要がある。装置１０１が参加を許可された場合、ＲＩ２０２は、装置１０１にドメインコンテキスト（ＤＣ）を供給する。ＤＣは、ドメイン権利オブジェクトを復号化するために利用されることができるドメイン鍵を含む。詳細については、ＯＭＡ ＤＲＭ ｖ２規格の６．４節を参照されたい。
【００３２】
ＯＭＡ ＤＲＭ規格は更に、ＤＲＭコンテンツのためのフォーマット及び保護メカニズム、権利オブジェクトのためのフォーマット（表現言語）及び保護メカニズム、並びに暗号化鍵の管理のためのセキュリティモデルを定義している。ＯＭＡ ＤＲＭ規格はまた、プル型配信（ＨＴＴＰプル、ＯＭＡダウンロード）、プッシュ型配信（ＷＡＰプッシュ、ＭＭＳ）及びストリーミングを含む、様々な伝送メカニズムを利用して、ＤＲＭコンテンツ及び権利オブジェクトがどのように装置に伝送され得るかを定義している。ＲＯ伝送は、ＲＩとＤＲＭユーザエージェントとの間で実行される、権利オブジェクト取得プロトコル（ＲＯＡＰ）と呼ばれる、１パス又は２パスのプロトコルを利用する。代替として、ＲＯ伝送は、２つのＤＲＭユーザエージェント間で又はＲＩとＤＲＭユーザエージェントとの間でＲＯＡＰを実行することなく実行されても良い。
【００３３】
コンテンツ発行器２０１及び権利発行器２０２は、同一のエンティティであっても良いことは、留意されたい。ＯＭＡの用語では、該エンティティはこの場合、コンテンツ配布器と呼ばれる。
【００３４】
本発明の発明者は、ＯＭＡの方法において、権利発行とドメイン管理との機能的な分離の必要性があることを認識した。上述したアーキテクチャの大きな欠点は、異なるＲＩ間で、ドメインが容易に共有又は利用されることができない点である。
【００３５】
本発明によれば、別途のドメイン発行器（ＤＩ）が導入される。ドメインに参加したいと欲する装置はここでは、ＲＩではなくＤＩに連絡する。ここでは結果として、同一のドメインにドメインＲＯを供給するために、複数のＲＩが利用され得る。このことは、図３に模式的に示される。２つのＲＩ２０２ａ及び２０２ｂが備えられ、共に装置１０１に対してドメインＲＯ２１２ａ及び２１２ｂを発行する。加えて、ドメイン発行器（ＤＩ）３０１が、どの装置が該ドメインに参加し及び該ドメインから離れるかを管理する。
【００３６】
ドメイン鍵（以下ＫＤと略される）はここで、ＲＩ２０２ではなくＤＩ３０１によって、装置１０１乃至１０５へと供給される。ＲＩ２０２ａ及び２０２ｂはもはや、ドメイン鍵にアクセスすることはできない。このことは、ＲＩ２０２ａ及び２０２ｂがもはや、装置１０１乃至１０５に対してドメイン権利オブジェクトを発行し得ないことを意味し得る。なぜなら、ＯＭＡ ＤＲＭ ｖ２によれば、ドメイン権利オブジェクトは、ドメイン鍵によって保護される必要があるからである。
【００３７】
本発明によれば、各ＲＩは自身の多様化鍵を発行される。多様化鍵は以下ＫＤｉと略され、ｉは多様化鍵ＫＤｉが発行されたＲＩの識別子である。多様化鍵は、好適には問題となる権利発行器の識別子と合わせて、ドメイン鍵から導出される。
【００３８】
好適な実施例においては、多様化鍵は、ドメイン鍵を秘密鍵として用いて、権利発行器の識別子の表現（好適には公開鍵）の、符号化された（keyed）ハッシュメッセージ認証コード（ＨＭＡＣ）を計算することにより生成される。好適にはＳＨＡ１暗号ハッシュ関数が利用されるが、他の多くのハッシュ関数もまた利用されることができる。計算された符号化されたハッシュは好適には、先頭の１２８ビットのみを保持するように切り捨てられ、該１２８ビットが次いで多様化鍵として働く。
【００３９】
代替として、暗号ハッシュ関数は、ドメイン鍵のハッシュを計算するために利用され、該ハッシュが次いで多様化鍵として働いても良い。ここでもまた、該ハッシュは、必要であれば切り捨てられても良い。好適には、暗号ハッシュ関数の入力は、ドメイン鍵のみならず、権利発行器の識別子の表現（好適には公開鍵）も含む。該好適な実施例は、異なるＲＩに異なる鍵を提供する。例えば、ドメイン鍵と公開鍵との連結をハッシュしても良い。
【００４０】
他の実施例においては、鍵ＫＤｉは、ドメイン鍵ＤＫを暗号化鍵として利用して、ＲＩの識別子の表現の暗号化として得られる。ＲＩの識別子の表現は、ＤＲＭシステム実装内で、どのタイプの名称、シリアル番号等が利用されるかに依存して、種々の方法で生成されることができる。例えば、ＤＭは、当該ドメインと通信し得る各ＲＩに対して、正確に１２８ビット（１６バイト）の長さである一意な識別ラベルＬｂｉを割り当てても良い。該ラベルは認証シリアル番号であり得る。該ラベルが１６バイトよりも短い場合には、ＤＭは各ラベルの前方を１６バイトとなるまで０ビットで埋めてＬｂｉを形成するべきである。
【００４１】
ここで多様化鍵を生成するための１つの選択肢は、ドメイン鍵ＤＫを暗号化鍵として利用した、該ラベルＬｂｉのＡＥＳ暗号化である。この利点は、単純である点と、結果の鍵が一意であることが保証される点である。
【００４２】
各ＲＩが任意に選択された一意な名称を持つ場合には、当該名称は、正しい長さの文字列を形成するように埋められる。パディングのための標準的な技術が利用可能であり、例えばISO/IEC規格9797を参照されたい。１つの好適な選択肢は、以下のとおりである。最初に、１２８ビットの長さであり、且つ該名称の（埋められていない）長さのビットによるバイナリ表現であるブロックによって、該名称の前方を埋める。次いで、その結果の後方を、メッセージ全体が１２８ビットの倍数の長さに到達するまで、値「０」のビットによって埋める。その結果が、暗号化鍵としてドメイン鍵ＤＫを用いるＡＥＳを利用して暗号化されても良い。このことは、任意に選択された名称が、ＲＩによって利用され得るという利点を持つ。
【００４３】
多くの代替の選択肢が想像され得る。幾つかの例が、ここで与えられる。殆どの状況において、符号化されたＭＡＣ関数が、ドメイン鍵ＤＫを鍵として利用する暗号化の代わりに利用されることができる。
【００４４】
好適な実施例における権利発行器は、該権利発行器の多様化鍵ＫＤｉを得るために、ドメイン発行器に対して要求を発行する。権利発行器が、問題となっているドメインにおける装置に対してＲＯを発行することが許可される場合には、ドメイン発行器は、関連するコンテキストを有する応答を発行する。該コンテキストは、権利発行器のための多様化鍵を有し、好ましくは更に、ドメイン発行器についての識別子、ドメイン自体、有効期限（時刻又は現時点からの経過時間として表現される）、及び好適にはＲＩ確認トークン（以下に詳述する）を有する。有効期限及び確認トークンは、ドメイン発行器についての秘密鍵を用いて生成された権利発行器についての公開鍵のX.509v3証明書の形をとっても良い。
【００４５】
権利発行器はここで、権利オブジェクトを生成し、これらＲＯを暗号化するために多様化鍵を用いても良い。このことは、ここではドメイン鍵の代わりに多様化鍵が用いられることを除いて、ＯＭＡ ＤＲＭ ｖ２規格と同様である。
【００４６】
当該ドメイン中の装置が権利発行器からドメインＲＯを取得すると、該装置は、該権利発行器についての多様化鍵を構築し、当該多様化鍵を該ドメインＲＯを復号化するために利用する。この目的のため、該装置は、ドメイン発行器について以上に概説した処理を繰り返す。
【００４７】
一実施例においては、ドメイン発行器は、ＲＩが、問題となっているドメインにおける装置についてドメインＲＯを発行することが許可されていることを証明することを可能とする、ＲＩ確認トークンを生成する。該確認トークンは、権利発行器の識別子（例えば公開鍵）を有し、好適には更に、該トークンがどれだけの期間正当のままとなるかの示唆（例えば有効期限を示すことによる）を有する。確認トークンは、該トークンの信頼性が確認できるように、ＤＩによりディジタル的に署名されるべきである。
【００４８】
本実施例においては、該装置は、権利発行器の識別子（即ち公開鍵）を取得するために、ＲＩ確認トークンを利用することができる。勿論、該装置は、ディジタル署名が正常に確認できない場合、又は該トークンがもはや正当ではない場合（例えば現在の時刻が示唆された有効期限を過ぎている場合）には、ＲＩ確認トークンを利用すべきではない。
【００４９】
ＯＭＡ ＤＲＭ ｖ２によると、権利発行器及び装置は、該装置が権利発行器からＲＯを受理する前に、ＲＩ登録プロトコルを実行すべきである。本発明の利点は、このことがもはや必要条件とはならない点である。ドメイン中の装置はまた、該ドメイン中の別の装置からドメインＲＯを取得し得、この場合には、元々当該ドメインＲＯを生成したＲＩに自身を登録する必要はない。
【００５０】
特定の間隔で、ドメイン鍵は新たなドメイン鍵により置換されても良い。このとき、ドメイン発行器はまた、以前のドメイン鍵から導出された多様化鍵を発行された全ての権利発行器について、新たな多様化鍵を生成すべきである。ドメイン発行器は次いで好適には、これらの新たな多様化鍵を、自動的にこれら権利発行器に供給すべきである。代替として、これら多様化鍵は要求に応じて供給されても良い。
【００５１】
多様化鍵を用いてＲＯを暗号化する代わりに、多様化鍵は、権利オブジェクトに関連する認証データを生成及び確認するために利用されても良い。例えば、権利オブジェクトに適用されるべき符号化されたハッシュ関数又はメッセージ認証コード関数のための鍵として、多様化鍵を利用しても良い。該関数の出力は次いで、権利オブジェクトを認証するために働く。
【００５２】
ＲＩが、特定のドメインについての正当なドメインＲＯを、該ドメインのメンバである装置と共にＲＯ取得プロトコル（ＲＯＡＰ）に従事することなく生成することを防止することが望ましい。これを達成するために、好適な実施例においては、該ドメイン中の装置が、ＲＯＡＰの間にＲＯを受信した後に、マスタドメイン鍵を利用して装置ＭＡＣを計算し、かかるドメインＲＯをＲＩから受信したときに該装置ＭＡＣをドメインＲＯに付加する。該装置ＭＡＣはかくして、ドメインＲＯが認可されたＲＩから取得されたことの証明として働く。当該手法は、多様化鍵ではなくドメイン鍵を用いて生成されたＲＯについても同様に動作することに留意されたい。当該手法は従って、多様化鍵を用いて暗号化されたＲＯに制限されるものではない。
【００５３】
装置ＭＡＣは、ドメイン鍵ＫＤを鍵として利用して、ＲＯのＭＡＣとして計算されても良い。このことは、該ドメイン中のいずれの装置もが、該装置ＭＡＣの信頼性を確立することを可能とする。装置ＭＡＣは、好適にはドメインＲＯ中の新たなＸＭＬ要素として該装置ＭＡＣを追加することにより、ＲＯに付随するべきである。
【００５４】
本実施例においては、装置ＭＡＣは、後続する行先装置における装置間のＲＯ交換及びインストールのために必要とされる。装置がドメインＲＯを受信するときはいつでも、当該装置は、当該装置において該ドメインＲＯを受け取り及び／又はインストールする前に、最初に装置ＭＡＣを確認する必要がある。
【００５５】
ドメイン鍵ＫＤが変更されると、装置ＭＡＣは新たなドメイン鍵を用いては確認され得ない点に留意されたい。また、正当な付随する装置ＭＡＣのないドメインＲＯは、好適には、該ドメイン中の装置により拒絶されるべきである。一方、正当な装置ＭＡＣを用いてドメインＲＯを受け取りインストールした装置は、新たなドメイン鍵を用いて装置ＭＡＣを再計算しても良い。
【００５６】
以上に提案された方法のセキュリティは、ドメイン鍵ＫＤが、当該ドメインのメンバである装置及びドメイン発行器にのみ知られているという前提に基づく。しかしながら、ドメイン鍵ＫＤが何らかの形で認可されていない第三者に利用可能となった場合には、ＲＩが、ドメインＲＯの発行を、その認可が期限切れしてしまっている場合であっても、行うことが可能となる。
【００５７】
この問題を解決するため、装置ＭＡＣを生成する装置は、当該装置ＭＡＣについて該装置の秘密鍵を用いてディジタル署名を生成するべきである。該署名ＤｅｖｉｃｅＳｉｇｎは、ドメインＲＯ及び装置ＭＡＣと共に配布されることとなる。ＤｅｖｉｃｅＳｉｇｎは、該ドメイン中の他の装置が、ＲＩからドメインＲＯを受信した装置を識別することを可能とする。
【００５８】
続いて、ドメイン鍵ＫＤが改竄され認可されていないＲＯが発行された場合には、これらＲＯを受信したドメイン装置が識別されることができる。該装置はこのとき、認可されていないＲＩと共謀して動作する見込みが高い。次いで、問題となる装置は、例えば該装置の装置識別子を該ドメイン中の全ての装置に配布される装置無効化リスト（ＤＲＬ）に追加することによって、無効化されても良い。準拠する装置のみが、ＤＲＬに含まれていない装置によって生成された適切なＤｅｖｉｃｅＳｉｇｎを含むドメインＲＯを受信しインストールする。
【００５９】
以上のことをサポートするため、好適な実施例におけるドメイン発行器は、当該ドメイン中の全ての装置に対して、特定の装置（以下装置ｘ）がＤｅｖｉｃｅＳｉｇｎ署名を生成することを許可されたことを通知する、署名されたオブジェクトを生成する。トークンは装置ｘの公開鍵を含み、ＤＩにより署名され、それにより該トークンは該ドメイン中のいずれのメンバ装置によっても確認されることができる。好適には、該トークンは装置ｘに利用可能とされ、それにより該装置が該トークンを他の装置へと配布することができる。
【００６０】
本実施例においては、装置がドメインＲＯを受信するときはいつでも、該装置は、既に議論された他のステップに加えて、装置ｘについてのＤｅｖｉｃｅＳｉｇｎ及びトークンの確認を実行する必要がある。
【００６１】
本実施例においては更に、ドメイン中の全ての装置が、該ドメイン中の装置についての装置無効化リストＤＲＬにアクセスすることができる。該ＤＲＬは、これら装置に保存されても良いし、又は例えばネットワークを介してアクセス可能であっても良い。該ＤＲＬは好適には、ＤｅｖｉｃｅＳｉｇｎが受諾されるべきではない装置を列記することによる、ブラックリストとして実現される。代替として、ＤＲＬは、ＤｅｖｉｃｅＳｉｇｎが受諾されるべきである装置のみを列記したホワイトリストとして実現されても良い。
【００６２】
本発明は、権利オブジェクト以外のオブジェクトを保護及び／又は認証するために利用されることもできる。例えば、コンテンツが多様化鍵を用いて暗号化されても良い。
【００６３】
本発明は、ＯＭＡ ＤＲＭに従うドメインに適用可能であるだけではない。認可されたドメインの概念をある程度実装する、種々の提案が存在する。所謂装置ベースのＡＤにおいては、ハードウェア装置又はソフトウェアアプリケーション（以下集合的にクライアントと呼ばれる）とコンテンツとの特定のセットにより、ドメインが形成される。ドメインマネージャ（１以上のクライアントであっても良い）、スマートカード又はその他の装置が、どのクライアントが該ドメインに参加しても良いかを制御する。該ドメイン中のクライアントの特定のセット（メンバ）のみが、当該ドメインのコンテンツの利用（例えば該コンテンツを開く、コピーする、再生する又はエクスポートする）を許可される。斯かる装置ベースのＡＤの例は、本出願人による国際特許出願公開WO03/098931（整理番号PHNL020455）、国際特許出願公開WO05/088896（整理番号PHNL040288）及び国際特許出願公開WO04/027588（整理番号PHNL030283）において与えられ、これらは全てここで参照により本明細書に組み込まれたものとする。
【００６４】
或るタイプの装置ベースのＡＤは、ドメインに結び付けられたクライアントのセットが、当該ドメインに結び付けられたコンテンツにアクセスすることを可能とする。該二重の結び付けは、全てのメンバがコンテンツにアクセスできることを確実にする。該構造はしばしば、共有秘密鍵を通して該結び付けを実装することにより確立される。該鍵はドメインマネージャにより選択され、全てのメンバに配布される。コンテンツがドメインに結び付けられると、共有鍵を用いた暗号化により、当該ドメインにライセンスが暗号的にリンクされる。代替として、コンテンツが或るクライアントに直接に結び付けられ、該クライアントがＡＤに結び付けられていても良い。
【００６５】
他のタイプのＡＤは所謂人物ベースのＡＤであり、ここではドメインが装置ではなく人物に基づく。斯かるシステムの例は、本出願人による国際特許出願公開WO04/038568（整理番号PHNL021063）に記載され（参照により本明細書に組み込まれたものとする）、ここではコンテンツが人物に結合され、次いで人物がドメインへとグループ化される。
【００６６】
所謂ハイブリッド型の認可されたドメインベースのＤＲＭシステムは、装置及び人物を含み得るグループにコンテンツを結び付ける。該グループは典型的に家庭内に制限され、以下のようなものである：
１．コンテンツは、該家庭に属するいずれのメンバ（例えばリビングのＴＶ、寝室のＴＶ、ＰＣ）においても視聴されることができる。
２．コンテンツは、いずれかのクライアント（例えばホテルの部屋におけるテレビ）においてユーザが自身を認証した後には、該家庭に属するいずれのユーザによっても視聴されることができる。斯かる認証は通常、スマートカードのようなユーザ認証装置を伴う。
【００６７】
ハイブリッド型のＡＤシステムの例は、国際特許出願公開WO2005/010879（整理番号PHNL030926）及び国際特許出願公開WO2005/093544（整理番号PHNL040315）において見出され、ここで共に参照により本明細書に組み込まれたものとする。
【００６８】
国際特許出願シリアル番号PCT/IB2005/053531（整理番号PHNL041254）は、認可されたドメインへのアクセスを可能とする方法であって、該認可されたドメインはドメインマネージャにより管理され、該方法は、外部の装置にリンクされたユーザ認証装置が、該ドメインマネージャに対して、該ユーザ認証装置と該外部の装置との間の局所的なリンクが距離的に制限されている旨をアサートするステップと、該アサートが正確なものであると受諾された場合には、該ドメインマネージャが、該外部の装置が該認可されたドメインのメンバとして動作することを可能とするステップと、を有する方法を記載している。
【００６９】
国際特許出願シリアル番号PCT/IB2005/053687（整理番号PHNL041329）は、少なくとも１つの取得装置を含む複数の装置を有する認可されたドメインシステムであって、該取得装置が、当該ドメインに含まれる２以上の装置についての無効化状態情報を取得し、該取得装置が連絡をとっている１以上の装置に対して該取得された無効化状態情報を配布するように構成されたシステムを記載している。
【００７０】
国際特許出願公開WO2004/077790（整理番号PHFR030018）は、マルチメディアコンテンツをクライアント装置に放送するための通信システムを記載している。該システムは、該マルチメディアコンテンツを、エンコードされたデータストリームへとエンコードするためのエンコーダを有する。該エンコードされたデータストリームは、第１のネットワーク接続を介して、サーバへと送信される。該サーバは、受信された該エンコードされたデータストリームに含まれるメディアデータからメタデータを生成し、該メディアデータとメタデータとがインタリーブされたプログレッシブなファイルを生成することが可能である。該プログレッシブなファイルは、第２のネットワーク接続を介して、クライアント装置にダウンロードされ、該クライアント装置は、該インタリーブされたメタデータ及びメディアデータを用いて、該ダウンロードの終了の前に、受信された前記マルチメディアコンテンツを再生することを開始することが可能である。
【００７１】
上述の実施例は本発明を限定するものではなく説明するものであって、当業者は添付する請求項の範囲から逸脱することなく多くの代替実施例を設計することが可能であろうことは留意されるべきである。
【００７２】
請求項において、括弧に挟まれたいずれの参照記号も、請求の範囲を限定するものとして解釈されるべきではない。「有する（comprising）」なる語は、請求項に列記されたもの以外の要素又はステップの存在を除外するものではない。要素に先行する「１つの（a又はan）」なる語は、複数の斯かる要素の存在を除外するものではない。本発明は、幾つかの別個の要素を有するハードウェアによって、及び適切にプログラムされたコンピュータによって実装されても良い。
【００７３】
幾つかの手段を列記した装置請求項において、これら手段の幾つかは同一のハードウェアのアイテムによって実施化されても良い。特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これら手段の組み合わせが有利に利用されることができないことを示すものではない。
【図面の簡単な説明】
【００７４】
【図１】ネットワークを介して相互接続された装置を有するシステムを模式的に示す。
【図２】ＯＭＡ ＤＲＭ ｖ２規格に従う模式的なアーキテクチャの図を示す。
【図３】別個のドメイン発行器及び複数の権利発行器を有する、本発明による模式的なアーキテクチャの図を示す。
【図１】
2009535958.tif 000003
【図２】
2009535958.tif 000004
【図３】
2009535958.tif 000005
【国際調査報告】
2009535958.tif 000006
2009535958.tif 000007
2009535958.tif 000008
2009535958.tif 000009