説明

セキュア・メディア・パスのシステム

【課題】望ましい程度のフレキシブルなセキュリティを提供しながら、レンダリング可能なコンテンツを処理する。
【解決手段】本発明は、レンダリング・デバイスに保護されないコンテンツが届いた後の不正アクセス又は複製を防止し、一般的なメディア・ソースに対し実質的にあらゆる種類のマルチメディア・コンテンツを適切に構成されたレンダリング・デバイスに送信可能なアーキテクチャを備える。コンテンツの保護及びレンダリングはローカル/ネットワーク上で実施可能である。これは、第三者がコンポーネントを作成し、安全かつ柔軟に処理連鎖に組み込みことを可能とする。コンポーネントの信頼性検証は、コンポーネントの連鎖を辿る1以上のオーセンティケータを生成して行う。多種多様のレンダリング環境、コンテンツ・タイプ、DRM手法にわたって、コンテンツ保護に活用できる標準プラットフォームを提供する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ビデオ・データ、オーディオ/ビデオ・データなどのレンダリング可能な(renderable)デジタル・データを処理するための方法とシステムに関するものである。特に、本発明はデジタルのデータを保護するための方法とシステムに関する。
【背景技術】
【0002】
マルチメディア・コンテンツなどのデジタル・コンテンツの所有権およびこのようなコンテンツについての正当な権限を有するユーザの使用権を保護することが、近年、非常に重要になってきている。このようなコンテンツの保護の重要性は、特にインターネットなどのコンピューティング・ネットワークの環境においてコンテンツの配布が容易になるにつれ、ますます高まることは避けられない。
【0003】
コンテンツ保護手法から利益を得る、成功することができるシナリオは多数ある。例えば、映画コンテンツ・プロバイダ(movie content providers)は、自社のコンテンツが保護されることが保証されれば、コンテンツを直接個人に販売することが容易になる。さらに、ユーザは、予約購読スタイルのサービス(subscription style services)(ケーブル・プロバイダ、ペイ・パー・ビュー方式デジタル衛星放送など)からコンテンツを受信することがより容易に、都合良く行える。さらに、ユーザはコンテンツを格納しておき、後日そのコンテンツを再生したり、自分専用にコピーを作成したりすることができ、しかもコンテンツ所有者の権利は必ず保持される。さらに、ユーザは独自のコンテンツを作成し、閲覧者を制限できることがわかる。例えば、ユーザはプライベートのホームビデオをWebサイトにポスト(post)して、家族だけに限定された期間、閲覧を許可することできる。
【0004】
コンテンツがデバイスに送られ、ユーザに対しそのコンテンツが再生される場合、通常、再生を整合させ、デジタル権利が保護され、維持されることを確実にするために、適切に定義されたアーキテクチャ(ソフトウェア・コンポーネントとハードウェア・コンポーネントの両方を含む)が必要である。多くの場合、保護されているコンテンツはビデオWebサーバなどのコンテンツ・ソースから、さらにはローカルのハードディスクからも、ユーザのデバイス(例えば、コンピューティング・デバイス、セットトップボックスなど)に転送される。そのコンテンツは、通常、コンテンツ・ソース側でエンコードまたは圧縮され暗号化されている。その後、ユーザのデバイスでコンテンツを復号し、展開し(圧縮解除し)、例えばモニタおよび/またはスピーカでユーザ対して、そのコンテンツを表示し、またはその他の方法でレンダリングする。
【0005】
コンテンツは、通常、今も発展と進化が続いているデジタル権利管理(digital rights management)(DRM)手法を使用して保護される。DRM手法では通常、Webなどのネットワーク上で有料コンテンツについて、セキュアな配信(secure distribution)を有効にし、またさらに重要なことと思われるが、その違法な配信を無効にする、ソフトウェアを使用する。現在のDRM開発作業は、オーディオ・コンテンツを守ること(securing audio content)に重点が置かれている。しかし、ネットワークの帯域幅が広がれば、ビデオを直接エンド・ユーザに配信する方法は、技術的に効率的で実現可能なものになるであろう。価値のあるデジタル・コンテンツも、デジタルTV、デジタル・ケーブルなどの他のソースから、あるいはデジタル・メディアを介してますます利用できるようになってきている。
【先行技術文献】
【非特許文献】
【0006】
【非特許文献1】"Systems and Methods For Securing Video Card Output", naming as inventors, Glenn Evans and Paul England, bearing Attorney Docket Number ms1-1115us, filed on June 24, 2002
【非特許文献2】"Methods and Systems Providing Per Pixel Functionality", naming as inventors, Glenn Evans and Paul England, bearing Attorney Docket Number ms1-1025us, filed on June 24, 2002
【発明の概要】
【発明が解決しようとする課題】
【0007】
将来的には、ユーザがデジタル・コンテンツを体験することを可能にするアーキテクチャは、ユーザおよび敵対的グループの両方からの迂回および不正アクセスを防止することに、存在していなければならないことになる。それと同時に、こうしたアーキテクチャは、信頼できるコンポーネントへの合法的アクセスを許す十分な柔軟性を備え、新しいアプリケーション、ソフトウェア・コンポーネントおよびハードウェア・デバイスが保護されたコンテンツに関して使用することを可能にし、さまざまな種類のメディアに対応し、ハンドヘルドPDAなどのリモート・ハードウェア・デバイス上でコンテンツの認証および再生を行う何らかのメカニズムを備え、リモート・デジタル・スピーカへの再生を行うといったものでなければならない。
【0008】
さらに、アーキテクチャは、下位インフラストラクチャ層のみが信頼できるものであればよく、信頼できないアプリケーションでもコンテンツが保護されていることを意識せずに保護されているコンテンツを再生できる十分な柔軟性と抽象性を持つ必要である。
【課題を解決するための手段】
【0009】
以上の理由から、本発明は、柔軟なセキュリティを十分に確保しながらレンダリング可能なデジタル・データを処理する改良された方法およびシステムを実現することと関連する課題から生まれた。
【0010】
レンダリング可能なコンテンツを処理するための方法、システム、およびアーキテクチャについて説明する。さまざまな実施形態で、保護されていないコンテンツ(つまり、復号化されたコンテンツ)、それがユーザのコンピュータなどのレンダリング・デバイスに届いた後に、そのコンテンツに対する不正アクセスまたはその複製を防止することができる。柔軟なフレームワークは、一般的なメディア・ソース(media sources)に対して、実質的にあらゆる種類のマルチメディア・コンテンツを適切に構成されたレンダリング・デバイスに送ることを可能とするアーキテクチャを備える。コンテンツの保護およびレンダリングは、ローカルでかつ/またはインターネットなどのネットワーク上で行うことができる。
【0011】
本発明のアーキテクチャを使用すると、第三者がコンポーネントを作成し、それらのコンポーネントを安全にかつ柔軟に処理連鎖(processing chain)に組み込むことができる。コンポーネントが信頼できるものであることを検証するため、コンポーネントの連鎖を辿るのに使用される1つまたは複数のオーセンティケータ(authenticator)を生成し、これによってコンポーネントを検証することができる。さまざまな実施形態が、多種多様のレンダリング環境、コンテンツ・タイプ、およびDRM手法にわたって、コンテンツを保護することに活用できる標準プラットフォームを提供することができる。
【図面の簡単な説明】
【0012】
【図1】本発明のさまざまな原理が使用されるシステムの高水準のブロック図である。
【図2】説明されている実施形態の原理が実装可能なコンピューティング環境の例のブロック図である。
【図3】1つまたは複数の実施形態を実装するために利用できるシステム例を示すブロック図である。
【図3a】一実施形態による方法のステップを説明する流れ図である。
【図4】1つまたは複数の実施形態を実装するために利用できるシステム例を示すブロック図である。
【図5】一実施形態による認証設計のさまざまな態様を示すブロック図である。
【図6】ネットワーク環境と関連する1つまたは複数の実施形態を実装するために利用できるシステム例を示すブロック図である。
【図7】ネットワーク環境と関連する1つまたは複数の実施形態を実装するために利用できるシステム例を示すブロック図である。
【発明を実施するための形態】
【0013】
概要
後述の方法、システム、およびアーキテクチャは、保護されているコンテンツのある種のソース(例えば、DRMサーバ、DVDサーバ(通常はDVDディスク・ドライブ)、HDTVサーバ(通常はTV局であり、ここからPC上のチューナ・カードに放送内容を送る)、または特定の種類のコンテンツ・サーバ)から、保護されたコンテンツを、ユーザに対してレンダリングまたはその他の方法により再生することができるデバイス(デバイスのソフトウェアおよびハードウェアを含む)への保護されているメディア・パスを提供することを目指している。
【0014】
例えば、図1を考察する。この図では、システム100は、いくつか例を挙げるとDVDサーバ102、コンテンツ・サーバ104(オーディオ・コンテンツ、オーディオ/ビデオ・コンテンツなどを供給できるサーバ)、HDTVサーバ106、およびローカルのハードディスク116など多数のさまざまな種類の保護されたコンテンツ・ソースまたはプロバイダを含む。コンテンツ・プロバイダは、ネットワーク108、110、112、118のようなネットワーク、バス(例えばPCIやAGPバス)、などを含むことができる各種のメディア上で彼らのコンテンツを供給するように構成されている。通常、コンテンツは、ユーザに対してコンテンツを表示することができるいくつかのタイプのデバイスに供給される。デバイス例として、限定しないが、パーソナル・コンピュータ114、ハンドヘルドPC 120、例えばセットトップボックス124を備えるテレビ122、などがある。
【0015】
後述の説明では、このようなコンテンツ用の対象ハードウェアは、一実施形態では、保護ビデオ・カードが装着されているローカルPCであり、また他の実施形態では、ハンドヘルド・コンピュータなどのリモート・ハンドヘルド・デバイスである。このような例は、本明細書で説明している本発明の原理が使用される環境例を説明することを目的としているが、ほんの少数の例に過ぎないことは明白であり理解されるであろう。したがって、請求されている主題の精神と範囲から逸脱することなく他の種類のデバイスを使用することができる。
【0016】
後述の方法、システム、およびアーキテクチャは、さまざまな種類のコンテンツ形式、その多くは、自分の権利の管理および暗号化を、多くの場合に含む特定のDRM(デジタル権利管理)特性を持つ、を処理することを目指している。このため、コンテンツを保護する際の柔軟性と堅牢性を大幅に高めることができる。したがって、柔軟なアーキテクチャを実現することで、すべてのコンテンツが必ず特定の1種類のDRM形式に結ばれていなければならないという状況を回避することができる。そこで、後述の1つまたは複数の実施形態のアーキテクチャの利点の1つは、第三者が、このアーキテクチャにインポートすることができるトランスレータ・モジュールで、これを使用してアーキテクチャ・コンポーネントが信頼でき検証済みであることを保証する共通権利管理および暗号化システムにマッピングできるトランスレータ・モジュールを作成して、提供できるという点である。
【0017】
さらに、後述の実施形態では、下記の特徴および/または利点の1つまたは複数を採用できる。オーセンティケータ(authenticator)メカニズムを実現し、これをデータの流れに従う再帰的アルゴリズムに一般化することができる。いくつかの実施形態では、初期オーセンティケータが用意され、これが保護されているデータを処理するコンポーネントの連鎖を認証することを開始する。追加オーセンティケータが、その連鎖に沿って作成され、通信することができるセキュア・チャネルを確立することができる。オーセンティケータは、最初に、認証作業を実行するためにそのデータ・グラフの構造を知っている必要はない。さまざまな実施形態で、危うい状態にある既知のコンポーネントの使用を防ぐ取り消しリストを使用できる。さらに、いくつかの実施形態では、ハードウェアとの直接認証とハードウェア・デバイスへの暗号化も可能である。さまざまな実施形態を、信頼できないアプリケーションを扱えるように構成することができる。この場合、信頼できないアプリケーションからデータを保護することができ、しかも、信頼でき、且つ検証されたコンポーネントによるコンポーネントの連鎖により処理することができる。信頼できるアプリケーションなど正当なアプリケーションに対してデータへのアクセス権を与えることができる。これは、データを視覚化するか、または修正を加えるなどの方法でアプリケーションからデータを操作できるようにするのに役立つ。
【0018】
認証および暗号化機能を完全にサポートしながら、さまざまなバス、ネットワークなどでデータをレンダリングできるリモート・デバイスに関してさまざまな実施形態を実装することができる。これにより、ホスト側に前処理およびインターフェース制御の大半を実行させ、リモート・デバイス(例えば、PDA)側ではデータを表示するだけにできる。さらに、さまざまな実施形態ではさまざまなソースからの保護されたコンテンツを処理することができる。つまり、保護されたコンテンツを、ローカル・デバイス(例えば、DVDドライブ、ビデオ・カメラ、TVチューナ、デジタル・ケーブル)およびリモート・ソース(Webまたはビデオ・サーバなど)により作成することができるということである。さらに、データの処理連鎖(data processing chains)を他のデータの処理連鎖内で再利用することもできる。例えば、ビデオ・クリップからオーディオ・トラックを保護するのに、セキュア・オーディオを再生するために使用されるコンポーネントのほとんどすべてを再利用することができる。
【0019】
これらの利点およびその他の利点は、以下の説明に照らせば明らかになることであろう。
【0020】
これらの実施形態では、どのようなデータストリームをも処理することができ、特にビデオまたはオーディオ・データのみに制限されるわけではない。そのため、他のデータ形式を保護するためにもこれらの実施形態を使用することができる。
【0021】
コンピューティング・システムの例
図2は、後述のシステムでおよび関連する方法を実装できる適当なコンピューティング環境200の一実施例を示している。
【0022】
コンピューティング環境200は、適当なコンピューティング環境の一例にすぎず、メディア処理システムの使用または機能の範囲に関する何らかの制限を示唆する意図はないことを理解されたい。またコンピューティング環境200はコンピューティング環境例200に示されているコンポーネントの1つまたは組み合わせに関係する依存性または要求条件があると解釈しないものとする。
【0023】
説明されているさまざまな実施形態は、さらに、他の多数の汎用または専用コンピューティング・システム環境または構成で動作する。メディア処理システムとともに使用するのに適していると思われるよく知られているコンピューティング・システム、環境、および/または構成の例として、パーソナル・コンピュータ、サーバ・コンピュータ、シン・クライアント(thin client)、シック・クライアント(thick client)、ハンドヘルドまたはラップトップ・デバイス、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベース・システム、セットトップボックス、プログラム可能家電製品、ネットワークPC、ミニ・コンピュータ、メインフレーム・コンピュータ、上記システムまたはデバイスのどれかを含む分散コンピューティング環境などがあるがこれに制限はされない。
【0024】
いくつかの実装では、本システムおよび関連する方法は、コンピュータによって実行されるプログラム・モジュールなどのコンピュータ実行可能命令の一般的文脈において説明できるであろう。一般に、プログラム・モジュールには、特定のタスクを実行する、あるいは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。これらの実施形態はさらに、通信ネットワークを介してリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することも可能である。分散コンピューティング環境では、プログラム・モジュールをメモリ記憶デバイスなどのローカルとリモートの両方のコンピュータ記憶メディアに配置できる。
【0025】
図2に示されている実施例によれば、コンピューティング・システム200は、1つまたは複数のプロセッサまたは処理装置202、システム・メモリ204、およびシステム・メモリ204などの各種システム・コンポーネントをプロセッサ202に結合するバス206を備えることが示されている。
【0026】
バス206は、メモリ・バスまたはメモリ・コントローラ、周辺機器バス、グラフィック専用高速バス、およびさまざまなバス・アーキテクチャを使用するプロセッサまたはローカルバスを含む1つおよび複数のさまざまなタイプのバス構造を表すことを意図している。例えば、このようなアーキテクチャとしては、業界標準アーキテクチャ(ISA)バス、マイクロ・チャネル・アーキテクチャ(MCA)バス、拡張ISA(EISA)バス、Video Electronics Standards Association(VESA)ローカルバス、およびMezzanineバスとも呼ばれるPeripheral Component Interconnect(PCI)バスがあるがこれに制限されない。
【0027】
コンピュータ200は通常、さまざまなコンピュータ読み取り可能メディアを含む。このようなメディアは、コンピュータ200からローカルでかつ/またはリモートからアクセス可能な有効なメディアであればよく、揮発性および不揮発性メディア、取り外し可能および取り外し不可能メディアの両方を含む。
【0028】
図2では、システム・メモリ204は、ランダム・アクセス・メモリ(RAM)210などの揮発性メモリおよび/または読み取り専用メモリ(ROM)208などの不揮発性メモリの形式のコンピュータ読み取り可能メディアを備える。起動時などにコンピュータ200内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム(BIOS)212は、ROM 208に格納される。通常、RAM 210には、処理装置202に直接アクセス可能な、かつ/または現在操作されているデータおよび/またはプログラム・モジュールを格納する。
【0029】
コンピュータ200はさらに、その他の取り外し可能/取り外し不可能な揮発性/不揮発性コンピュータ記憶メディアを備えることもできる。例えば、図2は、取り外し不可能な不揮発性磁気メディアの読み書きを行うハード・ディスク・ドライブ228(図には示されておらず、通常「ハードドライブ」と呼ばれる)、取り外し可能な不揮発性磁気ディスク232(例えば、「フロッピー(登録商標)ディスク」)の読み書きを行う磁気ディスク・ドライブ230、およびCD−ROM、DVD−ROM、またはその他の光メディアなどの取り外し可能な不揮発性光ディスク236の読み書きを行う光ディスク・ドライブ234を示している。ハード・ディスク・ドライブ228、磁気ディスク・ドライブ230、および光ディスク・ドライブ234はそれぞれ、1つまたは複数のインターフェース226によりバス206に接続されている。
【0030】
ドライブおよび関連コンピュータ読み取り可能メディアは、コンピュータ200用のコンピュータ読み取り可能命令、データ構造、プログラム・モジュール、およびその他のデータを格納する不揮発性ストレージを備える。本発明で説明している環境例ではハードディスク228、取り外し可能磁気ディスク232、および取り外し可能光ディスク236を採用しているが、当業者であれば、磁気カセット、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ランダム・アクセス・メモリ(RAM)、読み取り専用メモリ(ROM)などのコンピュータからアクセス可能なデータを格納できる他のタイプのコンピュータ読み取り可能メディアもオペレーティング環境例で使用できることも理解するであろう。
【0031】
ハードディスク228、磁気ディスク232、光ディスク236、ROM 208、またはRAM 210には、制限はされないが例としてオペレーティング・システム214、1つまたは複数のアプリケーション・プログラム216(例えば、マルチメディア・アプリケーション・プログラム224)、その他のプログラム・モジュール218、およびプログラム・データ220などの、多数のプログラム・モジュールを格納できる。ユーザはキーボード238およびポインティング・デバイス240(「マウス」など)などの入力デバイスを通じてコンピュータ200にコマンドおよび情報を入力することができる。他の入力デバイスとしては、オーディオ/ビデオ入力デバイス253、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、シリアル・ポート、スキャナなど(図には示されていない)がある。これらの入力デバイスやその他の入力デバイスは、バス206に結合されている入力インターフェース242を介して処理装置202に接続されるが、パラレル・ポート、ゲームポート、またはユニバーサル・シリアルバス(USB)などの他のインターフェースおよびバス構造により接続することもできる。
【0032】
モニタ256やその他の種類の表示デバイスも、ビデオ・アダプタまたはビデオ/グラフィックス・カード244などのインターフェースを介してバス206に接続される。モニタに加えて、パーソナル・コンピュータは通常、スピーカやプリンタなどの他の周辺出力デバイス(図に示されていない)を備え、これらは、出力周辺インターフェース246を介して接続することができる。
【0033】
コンピュータ200は、リモート・コンピュータ250などの1つまたは複数のリモート・コンピュータへの論理接続を使用してネットワーク環境で動作することができる。リモート・コンピュータ250は、コンピュータに関して本明細書で説明している要素および機能の多くまたはすべてを備えることができる。
【0034】
図2に示されているように、コンピューティング・システム200はローカル・エリア・ネットワーク(LAN)251および一般的なワイド・エリア・ネットワーク(WAN)252を通じてリモート・デバイス(例えば、リモートコンピュータ250)に結合され通信できるようになっている。このようなネットワーキング環境は、事務所、企業規模のコンピュータ・ネットワーク、イントラネットおよびインターネットではよくある。
【0035】
LANネットワーキング環境で使用する場合は、コンピュータ200は適当なネットワーク・インターフェースまたはアダプタ248を介してLAN 251に接続される。WANネットワーキング環境で使用する場合は、コンピュータ200は通常、モデム254またはWAN 252上で通信を確立するためのその他の手段を備える。モデム254は、内蔵でも外付けでもよいが、ユーザ入力インターフェース242またはその他の適切なメカニズムを介してシステム・バス206に接続できる。
【0036】
ネットワーク環境では、パーソナル・コンピュータ200またはその一部に関して述べたプログラム・モジュールは、リモート・メモリ・ストレージ・デバイスに格納できる。制限ではなく例として、図2は、リモート・アプリケーション・プログラム216がリモート・コンピュータ250のメモリ・デバイスに常駐しているものとして示している。図に示され説明されているネットワーク接続は例であり、コンピュータ間に通信リンクを確立するのにその他手段を使用できる
ことは理解されるであろう。
【0037】
実施形態の例
図3は、本明細書で説明しているさまざまな発明の原理を理解するうえで役立つコンポーネントの連鎖の例を示している。図3のシステムの総合的な目標の1つは、暗号化されたデータまたはコンテンツおよびDRMデータを何らかのソースから受信することが可能であること、それらのデータを共通システムにマッピングすることが可能であることにあり、このとき、そのデータまたはコンテンツは、保護されたメディア・パスが必要であることを指定するライセンスを有することが可能であることである。その後、システムは、メディア・パスを構成するシステムのコンポーネントが信頼できるものであることを検証することが可能となる。説明されている実施形態の一態様では、このアーキテクチャはさまざまな種類のデータ形式を扱うことができ、またこのアーキテクチャをさまざまな種類のコンポーネントのもとで採用することができる。つまり、このアーキテクチャは、保護されているコンテンツを効果的に処理しレンダリングするために特定のコンポーネントに強く結び付けられている必要はないということである。
【0038】
以下の説明は、一実施形態によるさまざまな発明の原理を実現するシステムについての、幾分かハイレベルの、機能的な概要を提供している。システムの一実施例のより詳細な態様については、以下の「実装例−ローカル・デバイスの実施形態」というセクションで説明している。
【0039】
図に示されているシステムは、さまざまな発明の原理を理解できるように、実実上、6段階に分割することができ、それぞれについて以下で詳述する。
・コンテンツ・ソース・コンポーネントと、ライセンス・サーバ(例えば、コンテンツ・ソース300)へのその接続。
・クライアント・コンポーネント、およびデータを復号化し、DRMコンテンツを含むコンテンツマニフェストを処理する関連するコンポーネント(例えば、クライアント304)。
・デマルチプレクサ、デコーダ、およびデータ再エンクリプタ(data re-encryptors)(例えば、デマルチプレクサ306、デコーダ308、およびエンクリプタ310)。
・データストリームを処理しミキシングするアプリケーション(例えば、アプリケーション312)。
・ハードウェアによる復号化をセットアップし、データの表示をスケジュールする1つまたは複数のレンダラ(renderers)(例えば、レンダラ314)。
・データを復号しレンダリングするハードウェア(例えば、レンダリング・ハードウェア316)。
【0040】
上記の段階に加えて、図のシステムではさらに、システムを構成するコンポーネントが信頼できるものであることを効果的に確認する検証プロセス期間に作成された複数の異なるオーセンティケータも使用する。これは、コンポーネント上で実現されている電子署名を検証することにより行うことができる。この例では、3つのオーセンティケータ−一次オーセンティケータ318と2つの二次オーセンティケータ320、322−がある。オーセンティケータ318および320はユーザ・モード・オーセンティケータであり、したがってユーザ・モード・コンポーネントを検証する場合に使用されることに留意されたい。他方、オーセンティケータ322はカーネル・モード・オーセンティケータであり、カーネル・モード・コンポーネントを検証する場合に使用される。
【0041】
さらに、このシステムではトランスレータ302などのトランスレータを採用することができる。トランスレータ302を使用して、DRM形式のコンテンツおよびライセンス・データをシステム側で認識できる形式に変換することができる。つまり、説明するシステムの利点の1つは、システムが本来認識しない、異なるいわゆる「外来の(foreign)」DRM形式に関して動作するように構成できるという点である。特に、トランスレータ・コンポーネントは、例えば、さまざまなDRM形式を共通アーキテクチャとともに使用できるように第三者側で作成できる。そのようにして、さまざまな、知られているまたはそれ以降開発されたDRM形式をも利用できるようシステムの自由度を高めることができる。
【0042】
コンテンツ・ソース
この特定の例では、コンテンツ・ソース300などのコンテンツ・ソース・コンポーネントは、ネイティブのDRMソース(つまり、コンポーネントが認識するソース)を読み込んだり、外部DRM形式をコンポーネントが認識するDRM形式に変換したりする役目を持つ。後者の作業は、コンテンツ・ソースの一部を含む場合も含まない場合もあるトランスレータ302の助けを借りて実行することができる。トランスレータ302を使用して、コンテンツおよびライセンスを認識可能なDRM形式に転写することができる。
【0043】
DRMコンテンツを提供するローカル・デバイス(DTV受信機など)が、暗号システムおよびライセンス制限を認識可能なDRM形式に変換する。そのようなデバイスに関連するドライバは、DRMコンテンツを作成できるようにする署名を発行できる。そのライセンスによりリモート・ライセンス・サーバへの依存性を指定し、取り消しリストを更新できる。取り消しリストは通常、危うい状態にあるコンポーネントをシステム側で突き止められるように用意される。例えば、ライセンスにより、ローカルでキャッシュできる週単位の取り消しリストを要求することができる。
クライアントとオーセンティケータ
クライアント304は通常、暗号化されたコンテンツと、クライアントが受け取るマニフェストの一部として含めることができるライセンスを受け取る。通常、マニフェストは、コンテンツのレンダリングに必要なレンダリング・パイプラインのコンポーネントを記述する。さらにライセンスには、コンテンツが必要とするセキュリティのレベルなどの補足情報を含めることもできる。これについては、以下で詳述する。
【0044】
マニフェストはさらに、レンダリング・パイプライン内のコンポーネントを検証するために使用する必要があるオーセンティケータの種類を指示すこともできる。それとは別に、マニフェストは、数種類のオーセンティケータを要求し、レンダラなどの他のパイプライン・コンポーネントに依存して、オーディオおよびビデオ・カーネル・オーセンティケータなどの対応するオーセンティケータを作成することもできる。
【0045】
ネットワーク接続またはキャプチャ・ソースをセットアップした後、コンテンツ・ソース側は、ライセンスに応じてバインドするようクライアント304に指示することもできる。また、コンテンツ・ソースは、バインド・プロセスを補助するためクライアントまたは他のコンポーネントが使用するソース関連情報をセットアップすることもできる。ライセンスがバインドされると、クライアントでは、オーセンティケータ318などの1つまたは複数のオーセンティケータ(例えば、ビデオおよびオーディオ・オーセンティケータ)を作成することができる。クライアントは、ライセンス要件をオーセンティケータに、それがインスタンス化されるときに渡すことができる。
【0046】
オーセンティケータは、パイプライン内の各コンポーネントを辿り(walk through the component)、暗号化されていないデータを処理するコンポーネントの署名を検証することができる。例えば、図のシステムで、クライアント304はセキュア・サーバによって認証されることが可能であり、認証された後、クライアントはオーセンティケータ318を作成できる。生成されると、オーセンティケータ318は、デマルチプレクサ306、デコーダ308、およびエンクリプタがすべて信頼できるものであることを検証することができる。
【0047】
さらに、この例では、バスまたは認証されていないコンポーネント間で(例えば、暗号化されたリンクを使って)、またはカーネル空間へデータが渡されたときに、データフロー・パイプラインの残り部分を検証するために、二次オーセンティケータが生成される。したがって、この例では、レンダラ314で二次オーセンティケータ320を作成し、このオーセンティケータによりレンダラが信頼できるものであることを検証する。その後、オーセンティケータ318、320が、それらの間の、認証され且つ暗号化されたチャネル319をセットアップすることができる。
【0048】
認証され暗号化されたチャネル319はさまざまな目的に使用することができる。例えば、チャネルでは隣接するオーセンティケータ間の通信を行うことができる。例えば、これにより、二次オーセンティケータは検証情報および妥当性確認またはその他の要求の報告を元のオーセンティケータに送り返すことができる。さらに、オーセンティケータは、危うい状態にあってもはや信頼できないと思われるコンポーネントを記述する取り消しリストをチェックできなければならない。さらに、認証され暗号化されているチャネルを使用して、信頼できるコンポーネントの間のビデオおよびオーディオ・データを暗号化する暗号化セッションをセットアップすることができる。
【0049】
ハードウェア復号化機能がサポートされているリモート・レンダリング・デバイスでは(詳しくは後述)、リモート・デバイスへの暗号化および認証のプロキシとなる二次オーセンティケータを作成できる。リモート・デバイス上では、小さなだけで、場合によっては信頼されていないプロキシ・コンポーネントを用意するだけでよい。それでも、その後一次オーセンティケータにより取り消せるようにリモートハードウェアで自己識別を行う必要がある。
【0050】
ビデオ・コンテンツについては、汎用オーディオ・ビデオ(AV)オーセンティケータが、ユーザ・モードのコンポーネントを検証し、レンダラがメディア特有のオーセンティケータを作成できる。
【0051】
デマルチプレクサ、デコーダ、および再エンクリプタ
デマルチプレクサ306は、通常、クライアント304から暗号化されていないデータを受け取り、そのデータをオーディオおよびビデオ・ストリームなどの異なるストリームに分割する。次に、デマルチプレクサ306は、通常、それらのストリームをデコーダ308などの1つまたは複数のデコーダに渡し、さらに処理を行う。オーディオ・デコーダ(エンクリプタ310などのエンクリプタとともに)はデータを再暗号化し、それをアプリケーション312に送って処理することができる。ビデオ・デコーダは、PCI/AGPバスでビデオ・カードのランダム・アクセス・メモリ(VRAM)に安全に転送できるようにデータを再暗号化する。ビデオ・デコーダは、通常、部分的に圧縮した(そして暗号化した)データをビデオ・カードに渡し、タイムスタンプの修正、データの再配列、およびヘッダの構文解析を実行できる。例えば、DVDの再生では、デコーダがベクトル・レベル・データと残余を抽出し、それらをビデオ・ハードウェアに渡して処理する。デコーダはさらに、修正を行って、逆方向再生または可変速度効果をシミュレートすることもできる。
【0052】
アプリケーションとミキシング
アプリケーション312は、ビデオ・ストリームとオーディオ・ストリームをレンダラによって供給される混合バッファ(mixing buffers)内に入れ混在させることができる。その後、ハードウェアに対して、混合命令のリストとともにデコーダから暗号化されたバッファを実際に渡す。ピクセル・シェーダ(pixel shaders)および任意多角形マッピング(polygon mappings)を使用するような、多数のイメージ処理オペレーションおよび非線形ビデオ効果、が可能である。アプリケーション側で暗号化されていないデータにアクセスする必要が生じた場合、切り離された信頼できるワーカー・プロセス(separated trusted worker process)を作成できる。次に、アプリケーションは実際に、もうひとつの認証されているデコーダになり、データの復号化、処理、および再暗号化を行って、ビデオ・ハードウェアまたは次の処理ユニットに出力する。
【0053】
レンダラおよびコンポジッタ(Compositors)
この例では、レンダラ314などのレンダラは、デコーダ308からディスプレイ・ドライバおよびオーディオ・ドライバ(たとえば、レンダリング・ハードウェア316)への暗号化セッションのプロキシになることができる。レンダラは、同期化処理およびハードウェアのセットアップの役目を担っている。レンダラは、関連するオペレーティング・システムおよびドライバAPIのような、さまざまなユーザ・モードAPIとコードを備えることができる。
【0054】
データがビデオ・カードのVRAMに転送されると、場合によっては、このデータは、復号化され、他のビデオソースとブレンドされて、ユーザ用ディスプレイに直接マッピングされているメモリの一部(「デスクトップ」または「プライマリ・サーフェス(primary surface)」と呼ばれる)にコピーされる。上述したおよび後述する保護されているメディア・パス・システムでは、一時ミキシング・バッファ(temporary mixing buffers)とデスクトップが不正アクセスから保護されることを確実にすることになる。
【0055】
デスクトップ上に配置された後のデータの完全性(integrity)を維持する方法として、信頼できるグラフィックス・ハードウェアを使用するやり方がある。このシステム例は、参照によりその開示が本明細書に組み込まれている文献(例えば、非特許文献1および非特許文献2参照)で説明されている。
【0056】
本質的に、参照している特許出願で説明されているシステムでは、出力データをディスプレイ上のウィンドウの原点に関して暗号化している。ウィンドウを物理的に移動した場合、原点が移動するか、またはデータが新しい原点に関して暗号化される。ディスプレイのハードウェアのDACのみ、データの復号化および表示を行うことができる。
【0057】
コンテンツは、デコーダによって直接デスクトップに暗号化するか、または最終的なイメージが組み立てられた後レンダラによって信頼できるハードウェアを使用して暗号化変換(transcrypt)することができる。
【0058】
レンダラがネットワーク上で「軽量」クライアントに対して実行される実施形態では、レンダラを、認証されたローカル・コンポーネントとリモート・コンポーネントに分割することができる。ネットワークを介して、圧縮された暗号化データおよび操作命令がリモート・レンダラに送信される。リモートハードウェアのサポートがない場合には、ホスト上でデータのブレンドを実行できる。
【0059】
レンダリング用のハードウェア
グラフィックス・カードはコンテンツ・ストリームの復号化、グラフィックス・プロセッサ・ユニット(GPU)を使用したデータの操作、および出力データの表示を受け持つ。上記の参照により取り込まれている特許出願では、保護されているコンテンツを処理するために使用できる1つの信頼できるハードウェア構成を説明している。
【0060】
つまり、これらの出願では、GPU内の復号化/暗号化エンジンと鍵(「暗号プロセッサ」と呼ばれる)を管理するコンポーネントとに分割できる暗号法サポート機能を説明している。グラフィックス・ハードウェアは、ピクセル毎の暗号化サポートを備え、VRAMを暗号化された形式で保持できる。次に、GPUによるそれぞれのグラフィックス・オペレーションで、着目しているピクセルを復号化し、それに対してある処理を実行し、その出力を再暗号化することができる。イメージは暗号鍵とともにタイル化され、各鍵領域がGPU内のキャッシュと効率よく整合することになる。ビデオDACの出力は、デジタル方式の保護またはアナログ方式の保護のいずれかを行うことができる。リモートのディスプレイでは、ディスプレイ・ハードウェアは、ネットワーク上で送信されるデータを復号化する何らかの形式の復号化サポートが知らされることになる。
【0061】
図3aは、一実施形態による方法のステップを説明する流れ図である。これらのステップは、適当なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせにより実装することができる。図の例では、これらのステップを上述および後述のようなソフトウェア・アーキテクチャに関して実行することができる。
【0062】
ステップ354で、DRMの変換(translation)が必要かどうかを決定する。必要であれば、ステップ356で、DRMを、コンテンツをレンダリングする処理システムにより認識される形式に変換できる。このステップは、いくつかの場合に、第三者ソフトウェア・ベンダが供給する別のトランスレータ・モジュールで実行できる。ステップ350では、レンダリング・プロセスの期間中に保護されるべき暗号化されたコンテンツを受け取る。このコンテンツは、DRM方式に従って保護されることになる。このコンテンツは任意の適当なソース、例えば、上述の例、から受信することができる。ステップ352で、コンテンツに関連付けられたマニフェストを受け取る。ステップ350および352は、クライアント304などの適当に構成されたクライアントにより実行できる(図3)。マニフェストには、コンテンツがそれによってレンダリングされるプロセスを制限する、保護されたメディア・パス要件が記述されている。このような要件はライセンスの形態を取ることができ、また通常はそうである。マニフェストは、暗号化されたコンテンツと同時に受け取る場合も、そうでない場合もある。
【0063】
さらに、ステップ358で、暗号化されたコンテンツを受け取るクライアント・コンポーネントが信頼できるものであるかどうかを検証する。このステップは、例えば、クライアントに関連付けられた電子署名を検証するセキュア・サーバにより実装できる。ステップ360で、一次オーセンティケータを作成する。このステップは、クライアント側で実行できる。ステップ362で、1つまたは複数のダウンストリームの処理システム・コンポーネントを一次オーセンティケータに明確に伝える(articulate)。このステップは、クライアントおよび/またはダウンストリームのコンポーネントに実装できる。一実施形態では、一次オーセンティケータは、データの渡し先であるコンポーネントに関してクライアントにクエリを実行し、さらに、それらのコンポーネントについてクエリを実行する、さらに同様な処理を繰り返す。ステップ364では、1つまたは複数のダウンストリームのコンポーネントを一次オーセンティケータで認証する。このステップは、例えば、セキュア・サーバを使用してさまざまなコンポーネントと関連する電子署名を検証することにより実装できる。
【0064】
ステップ366で、二次オーセンティケータが必要かどうかを決定する。二次オーセンティケータは、何らかの適当な理由から必要になる場合があり、この場合を後述する。二次オーセンティケータが必要ない場合、ステップ368では作成しない。他方、二次オーセンティケータが必要な場合は、ステップ370で、二次オーセンティケータを作成し、オーセンティケータ間の安全なチャネルを確立する。次に、ステップ372では、その二次オーセンティケータを使用して、1つまたは複数のダウンストリームのコンポーネントを認証する。その後、この方法はステップ366に戻り、追加二次オーセンティケータが必要かどうかを決定することができる。
実施例−ローカル・デバイスの実装形態
図4は、保護されているメディアを処理するように構成されている、一実施形態にしたがったシステム例を示している。システムは、いくつかの点で、図3に示され説明されているシステムと類似している。この特定の例では、システムはローカル・デバイス上のオーディオ/ビデオ・データを処理するように構成されている。適当なローカル・デバイスに、ローカルPC、セットトップボックス、または通常、オーディオ/ビデオ・データを処理する任意のデバイスを含むことができる。
【0065】
図4のシステムは、ビデオ経路とオーディオ経路を含む。ビデオ経路は、ユーザ・モードとカーネル・モード共に、ビデオ・カードのVRAMに送られるビデオを生成するコンポーネント(例えば、構文解析および変換コンポーネント)の連鎖で構成される。フレーム・バッファがデスクトップ上に表示され、それは、DACを通じて出力デバイスに送られる。またオーディオ・ストリームを処理するためのオーディオ経路も用意される。
【0066】
図4のシステムは、保護されているコンテンツを提供するコンテンツ・ソース400を備える。上述のようなコンテンツには、通常、多くの場合マニフェストに含まれるライセンスが付属するか、またはライセンスに関連付けられている。ライセンスは通常、コンテンツを使用できる人やその使い方などを記述することによりコンテンツの使用を制限する。ライセンスはさらに、コンテンツとともに使用されることになる取り消しリスト、このような取り消しリストの使用の頻度、および取り消しリストのソースとしてのセキュア・サーバなどを指定することもできる。また通常、マニフェストにより、セットアップされる保護されているメディア・パスの性質、そのメディア・パスによるコンポーネントの識別、および暗号化/復号化要求条件など、保護されているコンテンツとともに使用されるセキュリティのレベルを記述することもできる。さらに、通常トランスレータを使用して外部DRMコンテンツをストリームで認識できるDRMコンテンツに変換できることにも留意されたい。
【0067】
コンテンツはコンテンツ・ソースによりクライアント404に供給される。上述のように、クライアントが取得するライセンスは、そのデータが、オーセンティケータ418などの、保護されているメディア・パスのオーセンティケータを必要とすることを示す。この例では、単一のクライアント404が、コンテンツ・ソースから受信したデータを復号化する。オーセンティケータ418、420、および422などのオーセンティケータを使用して、暗号化されていないデータを受信するコンポーネントの連鎖を検証する。この作業は、コンポーネントに関連付けられた電子署名を検証する、およびまたはDLLアドレスのリストを通して検証する、などのさまざまな方法で実行できる。コンポーネントの処理連鎖がセットアップされた後、DRMサーバなどのサーバがクライアント404の認証を行う。次に、クライアント404は一次オーセンティケータ418を作成し、さらにこれにより、復号化されたデータを含むデータを処理するコンポーネントを見つけ出される。コンポーネントは、どのコンポーネントのそのコンポーネントがデータを渡すかについて、個々のコンポーネントにクエリを実行することにより、オーセンティケータ418によって見つけ出される。例えば、オーセンティケータ418は、クライアント404に対して、どのコンポーネントにクライアントがデータを供給するかについて、クエリを実行できる。クライアントは、データをデマルチプレクサ406に渡すことを示すことにより、オーセンティケータに応答する。このことは、デマルチプレクサ406を指示するポインタをオーセンティケータに渡すことにより、なされる。デマルチプレクサ406は暗号化されていないデータを処理するので、信頼される必要がある。デマルチプレクサ406は、クライアントにより暗号化されていないデータを受け取り、データをビデオ・ストリームとオーディオ・ストリームに多重化(多重化を解除)する。ビデオ・ストリームは、ビデオ・デコーダ408aおよび関連するダウンストリームのコンポーネント(つまり、エンクリプタ410a、ビデオ・レンダラ414a、ビデオ・ドライバおよびGPU(416aでまとめて示す))により処理されるが、オーディオ・ストリームはオーディオ・デコーダ408bおよびそのダウンストリーム・コンポーネント(つまり、エンクリプタ410b、オーディオ・レンダラ414b、オーディオ・ドライバおよびオーディオ・ハードウェア(416bでまとめて示す))により処理される。
【0068】
処理連鎖内の個々のコンポーネントは、オーセンティケータに対して、暗号化されていないデータの渡し先である他のコンポーネントのアドレスを送る。その後オーセンティケータは、コンポーネントのリスト内を巡り、例えば、コンポーネントの対応するDLLの署名を検証するなどして、コンポーネントの署名を検証する。これは、セキュア・サーバを使用して、なされる。そのように、例えば、オーセンティケータ418はデマルチプレクサ406の認証を行う。オーセンティケータ418は、次に、両方のデコーダ408a、408bを検証する。デコーダがデータを渡すコンポーネント(つまり、エンクリプタ410a、410b)を習得した後、オーセンティケータ418は、それらのエンクリプタを認証する。アプリケーション412は、信頼できるアプリケーションであってもなくてもよい。アプリケーションが暗号化されていないデータを処理する場合、オーセンティケータ418はアプリケーションが信頼できるアプリケーションかどうかを検証することができる。アプリケーションは信頼できるものでない場合、その場合は、アプリケーションは暗号化されているデータを、単に、処理することになる。
【0069】
最終的に、データはレンダラ414a、414bに渡される。レンダラは、自分専用のオーセンティケータ420を作成でき、これはオーセンティケータ418により検証される。オーセンティケータ418、420の間で認証され暗号化されたチャネルを確立することができる。検証が済むと、オーセンティケータ420はレンダラを認証することができる。
【0070】
この例では、カーネル・モードのオーセンティケータ422がレンダラによって作成され、他のオーセンティケータのうち1つまたは複数により認証される。オーセンティケータ422は、ユーザ・モードのオーセンティケータに安全にリンクすることができ、それにより、コンポーネント416a、416bなどのカーネル・コンポーネントを検証できる。
【0071】
さらに鍵マネージャ424も用意され、これはオーセンティケータ422により認証できる。鍵マネージャ424は、暗号化されたデータを渡す処理連鎖の中のさまざまなコンポーネントにより使用される暗号/復号鍵を管理する役割を持つ。鍵マネージャはさらに、暗号化プロセスで使用されるセッション鍵を管理することもできる。カスタム暗号法も、一部において、鍵マネージャ側によって、使用し、実装することができる。例えば、交換可能な暗号ライブラリを中間コンポーネントに提供することもできる。鍵はすべて、セッション・ベースの鍵として、各種コンポーネントに埋め込まれた複数の鍵を有することから避けなければならない。公開鍵暗号アルゴリズムを認証に使用し、ビデオ・ハードウェア上でデコーダと暗号プロセッサの間のセッション鍵をセットアップすることができる。認証に使用される暗号化されたチャネルは、セッション鍵のセットアップのために、認証されたコンポーネントによって再利用することができる。このことは、復号鍵は次のオーセンティケータにより検証されたエンティティにのみに渡されることを確実にする。コンポーネントが、暗号化されたデータとオーセンティケータのデータ・チャネルを同じ宛先に送らなければ、ダウンストリーム・エンティティでそのデータストリームを復号化することはできない。セッション鍵をセットアップするために使用されるアルゴリズムは、デコーダとレンダリング・コンポーネントに特有のものとすることができる。認証チャネルは、セッション鍵生成スレッドに対し個人化して、セッション鍵のセットアップのなりすまし(spoofing)を避けることができる。
【0072】
各コンポーネントは、再認証することができ、また定期的に再認証すべきであり、鍵は、外部コンポーネントによる挿入攻撃(insertion attacks)を最小限に抑えるために再ネゴシエーション(renegotiate)すべきである。セッション鍵の配列は、ソース側が所定の間隔で鍵を効率よく変更することを可能にすることができる。鍵のセットアップは、比較的低速で、コストのかかるプロセスなので、データストリームと非同期に実行されることがある。数バンク分の鍵を順繰りに使用することにより、データ鍵の同期化問題を回避することができる。例えば、新しい鍵ネゴシエーションが完了する前に4つの鍵で4つのフレーム遅延を起こすことができる。これについては、以下の「鍵ネゴシエーションと同期」という表題のセクションで詳しく説明する。
【0073】
鍵ネゴシエーションと同期
鍵バンクは通常、複数の鍵で構成される。ビデオの場合、ビデオ・レンダラでデータを処理するときに、通常、表示用の多数のフレームをキューに入れる。効率上の理由から、複数の鍵からなる鍵バンクを使用し、例えば1フレームにつき1つの鍵を同期させれば、フレーム毎に新しい鍵のネゴシエーションを行わなければならないことに関連付けられた問題を緩和することができる。つまり、鍵バンクを用意すれば、鍵のネゴシエーションが鍵毎に行われる必要はないという事実に基づき、鍵ネゴシエーション時間を短縮することができる。したがって、1バンク分の複数の鍵を使用すると、フレーム毎に1つの鍵を使用し、それらの鍵を順繰りに使用することができる。例えば、鍵1から4のネゴシエーションがされると、鍵1をフレーム1に、鍵2をフレーム2に、というように使用される。このように、個々の鍵のネゴシエーションを行う代わりに、複数の鍵に対するネゴシエーションを一度に実行し、その後、その鍵を順繰りに使用する。
【0074】
例えば、保護されているビデオ経路で、認証されたPKI暗号システムを使用して、セッション鍵の配列をデコーダとビデオ・ハードウェアの間で確立することができる。その後、その鍵をビデオ・カード内のアクセスし難いメモリとデコーダによって保護されたメモリ内に保持することができる。各鍵は、セッション・インデックスで参照することができる。ビデオ・ハードウェアでは、データはデータの暗号化にどのセッションが使用されたかを示すセッションのインデックスまたはIDと関連付けることができる。GPUが、このセッション・インデックスを使用して、GPU内の暗号エンジンをセットアップし、その後、暗号化されているデータを処理(つまり、復号化)することができる。オーセンティケータ連鎖は、辞書攻撃(dictionary attacks)を弱めさせ、挿入された外部コンポーネントの検出を試みるために、定期的に再ネゴシエーションがされ、認証されることが可能である。
【0075】
オーセンティケータ
上述のように、再生メカニズム(つまり、処理連鎖)をセットアップした後、クライアント・コンポーネントがデータを復号化し、そのデータをビデオおよびオーディオ・デマルチプレクサに渡す。認証プロセスの一部としてクライアントは、デマルチプレクサに適用されるオーセンティケータを作成する。その後、そのオーセンティケータを、認証のために、次のビデオおよびオーディオ処理コンポーネントに送る。それから、レンダラが、対応するビデオ/オーディオ特有のカーネル・オーセンティケータを作成することができる。オーセンティケータは、各アドレスが置かれているDLLに関連付けられたる電子署名を認証することができる。
【0076】
オーセンティケータは、コンポーネントの署名を検証するだけでなく、処理連鎖が、コンテンツのライセンス内の要件を満たすに十分なセキュリティがあることを検証することもできる。例えば、ライセンスは、処理連鎖について必要とされるセキュリティのレベルを指定することもできる。このセキュリティ・レベルをオーセンティケータに渡し、そこで、セキュリティ・レベルへの適合性を確認することができる。それとは別に、特定のレベルのオーセンティケータ、例えばレベル1のオーセンティケータまたはレベル2のオーセンティケータを要求することにより、暗黙のうちにセキュリティ・レベルをエンコードすることができ、その両方がそのレベルの一次オーセンティケータを呼び出すことができる。
【0077】
セキュリティ・レベルの例を以下に示す。
・ビット0−圧縮されたデータ(および署名されているビデオ・ドライバ)のソフトウェア不明化(software obfuscation)
・ビット1−圧縮されたデータの信頼できるソフトウェア保護
・ビット2−バス上の圧縮されたデータのハードウェア保護
・ビット3−ビデオ/オーディオ・デバイス内の圧縮されたデータのハードウェア保護
・ビット4−出力デバイスから出るデータのアナログ保護
・ビット5−出力デバイスから出るデータのデジタル保護
各コンポーネントはさらに、認証の第1パスとしてライセンスに制限を加える機能も備えることができる。これにより、コンポーネント(例えば、デコーダ)が、他のコンポーネントに互換性について問い合わせを行わなければならないようにできる。例えば、オーディオ・デコーダは、一定の条件を満たしたすアプリケーションで再生されることにライセンスされるだけとなる。
【0078】
システムのバージョンに関する追加要件もまた、ドライバ・サポートの必要なレベルを指定するのに役立つ。例えば、ライセンスに、適合性を保証するためオーセンティケータに渡されるデータのペア(最小限の保護された経路/ドライバ・レベル、最小限のハードウェア要件)を含めることができる。
【0079】
コンポーネント
オーセンティケータのさまざまな配列(arrangements)を使用して、上記の実施形態を実装することができる。例えば、図4に示され説明されているシステムでは、2つの別々の一次オーセンティケータ−ビデオ回路に1つとオーディオ回路に1つ、または図4に示されているように、オーディオおよびビデオ回路の両方と通信する単一の一次オーセンティケータが考えられる。さらに、ビデオ回路に1つおよびオーディオ回路に1つの、2つの別々のカーネル・モード・オーセンティケータが考えられる。このような場合、2つの別々の、認証され且つ暗号化されているチャネルが、オーディオ回路とビデオ回路のオーセンティケータ間にそれぞれ1つ、備えることができる。
【0080】
下の説明では、特定の認証設計について説明している。説明されている設計が1つの認証設計を示しているに過ぎないことは理解されるであろう。したがって、請求されている主題の精神と範囲から逸脱することなく他の認証設計を実現することができる。
【0081】
図5は、オーセンティケータが「An」と指定されている認証設計例を示しており、処理連鎖内のさまざまなコンポーネントによりサポートされているインターフェースは、認証可能なインターフェースに対しては「IA」、認証プロキシ・インターフェース(authentication proxy interface)に対しては「IAP」として示されている。プロキシ・インターフェース(proxy interface)は、別の認証可能なインターフェースへサービスを転送するインターフェースとして機能する。さまざまなコンポーネントの名前が、対応するコンポーネントの隣に示されている。例えば、オーディオ回路では、オーディオ・デコーダ、オーディオ・エンコーダ、アプリケーション、オーディオ・レンダラ、およびオーディオ・ドライバ/ハードウェアが示されている。同様に、ビデオ回路では、ビデオ・デコーダ、ビデオ・エンコーダ、アプリケーション、ビデオ・レンダラ、およびビデオ・ドライバ/ハードウェアが示されている。いくつかのコンポーネントでは、プロキシ・インターフェース(IAP)と認証可能インターフェース(IA)の両方、例えばレンダラのそれぞれ、をサポートすることに留意されたい。
【0082】
インターフェースは、コンポーネントの単なる論理的部分であり、他のコンポーネントから呼び出される、呼び出し可能な方法の集まりである。オーセンティケータ側で特定のコンポーネントとの通信を望んでいる場合、オーセンティケータはそのコンポーネントの適切なインターフェースを探し、そのインターフェースのメソッドを呼び出すことにより、そのコンポーネントに通信する。
【0083】
オーセンティケータは、コンポーネントを検証し、他のオーセンティケータへの暗号化されたチャンネルを確立する。さらに、暗号化されていないデータを処理するコンポーネント間に、暗号化されているチャネル・サービスを提供する。このチャネルは、メイン・データを暗号化するコンポーネント間で、セッション鍵の配列のネゴシエーションを実行することに使用される。IAインターフェースは、オーセンティケータに、検証対象のコンポーネントのリストと、検証を続けるためのダウンストリーム・コンポーネントのリストを提供する。IAPプロキシ・インターフェースは、非認証コンポーネントも合わせてリンクされているオーセンティケータ間で、認証情報を転送するためのパス・スルー・インターフェースである。
【0084】
それぞれのオーセンティケータ内で、Enは接続イニシエータ(connection initiator)の暗号/復号鍵ペアを表し、Dnは接続レシーバの暗号/復号鍵ペアを表す。
【0085】
第1のオーセンティケータA1は、2つの別々の出力回路(例えば、ビデオおよびオーディオ)を検証するために使用されるので、複数の二次オーセンティケータ(A2-5)をサポートすることができる。
【0086】
クライアントは、初期オーセンティケータA1を作成し、第1のコンポーネント(つまり、デマルチプレクサ)のIAインターフェースをオーセンティケータに対して指定する。この例では、IAインターフェースは以下の情報をオーセンティケータに返す。
・ダウンストリーム・コンポーネント(複数)のIAインターフェースのリスト
・(暗号化されたデータを見るだけの)ダウンストリーム・コンポーネント(複数)のIAプロキシ・インターフェースのリスト
・署名を検証すべき従属コンポーネントのリスト
・次のオーセンティケータのリンク・インデックスの記憶領域(同じオーセンティケータを複数のストリームに再利用することができる)
・認証の連鎖(authentication chain)の鍵セッション番号(Key session number)
オーセンティケータ(A1)では、クライアントを使用して、IAインターフェースのアドレス、次に従属コンポーネントを検証し、ダウンストリームIAインターフェースのそれぞれで繰り返す。次に、オーセンティケータがリストに含まれるIAPインターフェースのそれぞれを通じて暗号化され認証されているチャンネルをセットアップする。
【0087】
IAPインターフェースは、次のオーセンティケータと送信するための2つのメソッドを備える。
・ReadData (buffer, length)
・WriteData (buffer, length)
通常、レンダラはIAPおよびIAインターフェースをサポートする。レンダラのIAPインターフェースは、参照されると、次のオーセンティケータを作成して、そのオーセンティケータに対するIAP呼び出しのプロキシとなる。その後、それらのオーセンティケータは、認証され暗号化されている通信チャネルを確立する。オーセンティケータはレンダラのIAインターフェースを渡され、レンダラから始まる新しい認証連鎖を開始できる。
【0088】
オーセンティケータはさらに、IAインターフェースを持つコンポーネントがオーセンティケータ・チャネルで情報を渡すためのメソッドを備えることもできる。オーセンティケータでは、これは以下のものを含むことができる。
・EncryptAndSend(link ID,[in]data)−データを次のコンポーネントに送信する。
オーセンティケータに渡されたIAのインターフェースでは、以下のコール・バックが存在できる。
・DecryptAndReceive([out]data)−データを信号化して受け取り側コンポーネントに渡す場合に使用する。
・LinkIdentifier([out]link ID)−送信するIAインターフェースに渡される送信および受信メソッドが、コンポーネントによって使用され、メイン・データを暗号化するセッション鍵をセットアップすることができる。
【0089】
クライアントを簡素化するため、オーセンティケータはさらに、以下の単純な暗号機能をサポートできる。
・CreateSession(HANDLE[out],CLSID drmEncryptorID)−エンクリプタを作成して、セッション鍵を確立する。
・EncryptData(HANDLE[in],BYTE* pIn,BYTE* pOut)
・DecryptData(HANDLE[in],BYTE* pIn,BYTE* pOut)
その後、オーセンティケータは、コンポーネントに対して暗号化オブジェクトを持続させる。
【0090】
ネットワークの実施形態−ケースI
上述のアーキテクチャの一利点は、インターネットなどのネットワークと関連して使用でき、またインターネットなどのネットワークのもとで適用できるという点である。例えば、図4に関して示され説明されているシステムとさまざまな点で類似しているシステムを示す図6を考察する。図4の実施形態の同様の番号が適宜使用されている(ただし、図6での番号は「6XX」形式であるが、図4での番号は「4XX」形式である)。
【0091】
この例では、リモート・デバイス624を備えており、これは、リモート・デバイス上でコンテンツをレンダリングするのに使用可能なソフトウェアおよびハードウェア(617でまとめて示す)を実現している。リモート・デバイスとしては、例えば、ハンドヘルドPC、PDA、USBスピーカ、IEEE1394スピーカなどがある。クライアント604、鍵マネージャ624、デマルチプレクサ606、デコーダ608a、608b、エンクリプタ610a、610b、アプリケーション612、レンダラ614a、614b、および一次オーセンティケータなどの1つまたは複数のオーセンティケータ618および二次オーセンティケータ620などのコンポーネントを、ホストなどのネットワーク接続の一方の側に配置することができる。そこで、デバイス624は、ネットワーク接続を介してホストと通信し、信頼できるソースから保護されたコンテンツをユーザ向けにレンダリングすることができる。
【0092】
この例では、リモート・デバイス624は、上述においてカーネル・モードのオーセンティケータをセットアップし、構成したのと非常によく似た方法でセットアップし構成することができるオーセンティケータ622を含む。
【0093】
つまり、この例では、ネットワークの両側にあるオーセンティケータ(例えば、オーセンティケータ620と622)の間に論理接続があるということである。この論理接続は、上で述べたすべての理由により、認証され暗号化されている。ネットワーク・レンダラには、ネットワークを介して通信し、リモート・デバイス624に存在するコンポーネントを確認する役割がある。そこでレンダラは、リモート・デバイス624上でオーセンティケータを確立し、2つのオーセンティケータ620、622の間の通信チャンネルを確立する。このチャネルを使用して、エンクリプタ610aとレンダリング・ハードウェア(617)の間の鍵をセットアップすることができる。
【0094】
ネットワークの各側の処理連鎖内の各種コンポーネントの認証が済んだら、保護されているコンテンツを、レンダリングするためにリモート・デバイス624に送ることができる。
【0095】
ネットワークの実施形態−ケースII
図7は、図6に示され説明されているシステムとわずかに異なるシステムを示している。ここでは、リモート・デバイス724は、純粋にハードウェアだけからなるレンダリング・コンポーネント717を包含する。ソフトウェア・プロキシ715が実現されており、認証プロセスを補助するが、必ずしも信頼できるものである必要はない。例えば、ハードウェアでPKI認証サポートを行うことによりハードウェア自体で認証を実行できる。
【0096】
この例では、ネットワーク・レンダラが、ネットワークの左側の認証プロトコルをデバイス724のハードウェア認証プロトコルにマッピングすることができる。この場合、ソフトウェア・プロキシ715内に常駐する認証変換モジュールを使用できる。するとこの場合、ソフトウェア・プロキシ715は信頼できるものである必要があり、検証する必要があることになる。それとは別に、ハードウェアはネットワークの左側の認証プロトコルと本来互換性があってもよいし、またハードウェアにマッピング・オペレーション自体を実行する変換モジュールを組み込み、デバイス上のソフトウェアの信頼性を求めたり、それを検証したりする必要をなくすこともできる。
【0097】
この種の配置は、第三者が、第三者自身のリモート・デバイス上で使用する、第三者自身のトランスレータ・モジュールを作成できるようにするという観点からはメリットがある。そこでこれらのモジュールは認証プロトコルの変換を実行することができ、そのため、どの認証設計にも縛られない。さらに第三者は、例えば、ビデオ・レンダラで暗号化されていないデータを処理する必要がある場合にネットワークの左側にユーザ・モードのオーセンティケータをセットアップすることもできる。
【0098】
さらに、上のアーキテクチャは、取り消しリストをさまざまなコンポーネント上で送信できる、例えば、サーバから取り消しリストをクライアントに送信し、さらにそのリストは処理連鎖を下って、リモート・デバイスに送信することができるという点で都合がよい。したがって、取り消されたコンポーネントはもはや、保護されているデータを処理することができなくなる。例えば、保護されているコンテンツに伴うライセンスで、そのコンテンツにメディア・パス・オーセンティケータが必要であること、さらにデバイスで定期的にサーバにアクセスして取り消しリストを取得する必要があることを指定することができる。そしてユーザは、ユーザのリモート・デバイスを使って、一定期間コンテンツを再生し、その後、ユーザのデバイスでサーバにアクセスして取り消しリストを取得し、それで、ユーザのデバイスが、コンポーネントが取り消されてしまったユーザのリストを更新する必要がある。
【0099】
その他の拡張と利点
図6および7の実施形態を拡張し、ネットワーク・レンダラをブロードキャスト・レンダラ(broadcast renderer)として実装するようにできる。例えば、ブロードキャスト・サービス(broadcast service)またはサーバが、暗号鍵をセットアップして、さまざまなハードウェア・デバイスと共有することができる。次に、ブロードキャスト・レンダラは保護されているコンテンツをそれらのデバイスにブロードキャストし、そのコンテンツが依然として保護されていることを確認することができる。
【0100】
このアーキテクチャの他の利点として、ユーザ・モードとカーネル・モードの間でデータを必要なだけ何回もやり取りできるという点が挙げられる。これは、オーディオ・データのエコー・キャンセルなどに役立つと思われる。つまり、オーディオ・レンダラがカーネルに入り、ユーザ・モードのコンポーネントへ出てまたカーネルに入る別の処理連鎖を構成できる。
【0101】
結論
上述の方法およびシステムでは、レンダリング可能なデジタル・データを処理する改良された方法とシステムを実現できる。上述の実施形態の利点として、制限されないが、信頼できないユーザ・モード・コンポーネント(デコーダ、ビデオ操作)およびカーネル・モード・コンポーネントでの保護されたコンテンツへの不正アクセスを禁止できるという点が挙げられる。さらに、認可されたコンポーネントは、保護されたコンテンツへの不正アクセスに利用されないよう保護することもできる。処理連鎖でさまざまなサード・パーティ・コンポーネントを使用し、また保護されたコンテンツへのアクセスの前にそのようなコンポーネントが信頼できるものであることを確認するメカニズムを備えることができる。変換プロセスまたはトランスレータ・モジュールを使用することで、複数の異なるソースからのコンテンツ、さらに複数の異なる種類のコンテンツおよびDRM手法をシステムに簡単に組み込むことができる。さまざまな実施形態では、さらに、保護されたコンテンツをデバイスやネットワーク境界をまたいで使用することができ、その際には、境界をまたいで変換可能な認証プロセスを、使用する。さらに、取り消しメカニズム(つまり、取り消しリスト)を使用して、危ういコンポーネントが保護されているコンテンツにアクセスできないようブロックすることができる。またこのアーキテクチャを使用すると、デコーダとレンダリング機能(つまり、表示用ハードウェア)との間にセキュリティ・レベルの高い通信チャネルを確立することもできる。このアーキテクチャは、コンポーネントのトポロジに関する情報を事前に必要とせず、またデータのフローに従うので複雑な構造に適用することができる。
【0102】
本発明は構造的機能および/または方法論的ステップに固有の言語で説明されているが、請求項で定められている発明は、説明した特定の機能またはステップに必ずしも限られないことは理解されるであろう。むしろ、特定の機能およびステップは請求されている発明を実施する好ましい形態として開示されている。
【符号の説明】
【0103】
100 システム
102 DVDサーバ
104 コンテンツ・サーバ
106 HDTVサーバ
108、110、112、118 ネットワーク
114 パーソナル・コンピュータ
116 ローカルのハードディスク
120 ハンドヘルドPC
122 テレビ
124 セットトップボックス
200 コンピューティング環境
202 1つまたは複数のプロセッサまたは処理装置
204 システム・メモリ
206 バス
208 読み取り専用メモリ(ROM)
210 ランダム・アクセス・メモリ(RAM)
212 基本入出力システム(BIOS)
216 リモート・アプリケーション・プログラム
228 ハード・ディスク・ドライブ
230 磁気ディスク・ドライブ
232 取り外し可能な不揮発性磁気ディスク
234 光ディスク・ドライブ
236 取り外し可能な不揮発性光ディスク
238 キーボード
240 ポインティング・デバイス
242 入力インターフェース
244 ビデオ/グラフィックス・カード
246 出力周辺インターフェース
248 適当なネットワーク・インターフェースまたはアダプタ
250 リモート・コンピュータ
251 ローカル・エリア・ネットワーク(LAN)
252 ワイド・エリア・ネットワーク(WAN)
253 オーディオ/ビデオ入力デバイス
254 モデム
256 モニタ
300 コンテンツ・ソース
302 トランスレータ
304 クライアント
306 デマルチプレクサ
308 デコーダ
310 エンクリプタ
312 アプリケーション
314 レンダラ
316 レンダリング・ハードウェア
318 一次オーセンティケータ
320、322 二次オーセンティケータ
404 クライアント
406 デマルチプレクサ
408a ビデオ・デコーダ
408b オーディオ・デコーダ
410a エンクリプタ
410b エンクリプタ
414a ビデオ・レンダラ
414b オーディオ・レンダラ
416a ビデオ・ドライバおよびGPU
416b オーディオ・ハードウェア
418、420、および422 オーセンティケータ
424 鍵マネージャ
604 クライアント
606 デマルチプレクサ
608a、608b デコーダ
610a、610b エンクリプタ
612 アプリケーション
614a、614b レンダラ
617 レンダリング・ハードウェア
618 オーセンティケータ
620、622 オーセンティケータ
624 鍵マネージャ
624 リモート・デバイス
715 ソフトウェア・プロキシ
717 レンダリング・コンポーネント
724 リモート・デバイス

【特許請求の範囲】
【請求項1】
システムであって、
ユーザ向けにレンダリングされる保護されているコンテンツを処理するコンポーネントの処理連鎖内で使用されるように構成されているコンポーネントで、認証可能なインターフェースおよび認証プロキシ・インターフェースの1つまたは複数をサポートする1つまたは複数のコンポーネント
を備え、
前記認証可能なインターフェースは、オーセンティケータにより呼び出し可能であって、前記オーセンティケータに対して、
ダウンストリーム・コンポーネントの認証インターフェースのリスト、
ダウンストリーム・コンポーネントの認証プロキシ・インターフェースのリスト、および
署名を検証する従属コンポーネントのリスト
を返し、
前記認証プロキシ・インターフェースは、前記オーセンティケータとの間でデータを読み書きする方法を提供することを特徴とするシステム。
【請求項2】
前記認証可能なインターフェースは、オーセンティケータの前記連鎖に、鍵セッション番号を返すことを特徴とする請求項1に記載のシステム。
【請求項3】
少なくとも1つのコンポーネントは、レンダラを備えることを特徴とする請求項2に記載のシステム。
【請求項4】
少なくとも1つのコンポーネントは、前記両方のインターフェースをサポートするレンダラを備えることを特徴とする請求項1に記載のシステム。
【請求項5】
少なくとも1つのコンポーネントは、デマルチプレクサを備えることを特徴とする請求項1に記載のシステム。
【請求項6】
少なくとも1つのコンポーネントは、デコーダを備えることを特徴とする請求項1に記載のシステム。
【請求項7】
少なくとも1つのコンポーネントは、ビデオ・デコーダを備えることを特徴とする請求項1に記載のシステム。
【請求項8】
少なくとも1つのコンポーネントは、オーディオ・デコーダを備えることを特徴とする請求項1に記載のシステム。
【請求項9】
少なくとも1つのコンポーネントは、エンクリプタを備えることを特徴とする請求項1に記載のシステム。
【請求項10】
少なくとも1つのコンポーネントは、オーディオ・エンクリプタを備えることを特徴とする請求項1に記載のシステム。
【請求項11】
少なくとも1つのコンポーネントは、ビデオ・エンクリプタを備えることを特徴とする請求項1に記載のシステム。
【請求項12】
少なくとも1つのコンポーネントは、ネットワーク・レンダラを備えることを特徴とする請求項1に記載のシステム。
【請求項13】
システムであって、
少なくとも1つがホスト・コンピューティング・デバイスを備え、少なくとも1つがリモート・コンピューティング・デバイスを備えた、複数のコンピューティング・デバイスであって、前記複数のコンピューティング・デバイスのそれぞれは、
ユーザ向けにレンダリングされる保護されているコンテンツを処理するコンポーネントの処理連鎖で使用するように構成されているコンポーネントで、認証可能なインターフェースおよび認証プロキシ・インターフェースの1つまたは複数をそれぞれがサポートする1つまたは複数のコンポーネントを備え、
前記認証可能なインターフェースは、オーセンティケータにより呼び出し可能であって、前記オーセンティケータに対して、
ダウンストリーム・コンポーネントの認証インターフェースのリスト、
ダウンストリーム・コンポーネントの認証プロキシ・インターフェースのリスト、および
署名を検証する依存コンポーネントのリスト
のうちの1つまたは複数を返し、
前記認証プロキシ・インターフェースは、前記オーセンティケータとの間でデータを読み書きする方法を提供することを特徴とするシステム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図3a】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate


【公開番号】特開2013−15862(P2013−15862A)
【公開日】平成25年1月24日(2013.1.24)
【国際特許分類】
【出願番号】特願2012−214390(P2012−214390)
【出願日】平成24年9月27日(2012.9.27)
【分割の表示】特願2009−288223(P2009−288223)の分割
【原出願日】平成15年6月24日(2003.6.24)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】