信頼される処理技術を使用したデジタル権利管理
【課題】本発明は、OMA DRMによって規定されるコンテンツ配布と関係するエンティティ、メッセージ、および処理の完全性を強化するいくつかの方法を開示する。
【解決手段】これらの方法は、TCG仕様と関係する技術を使用する。第1の実施形態は、DRM ROAP仕様およびDRMコンテンツフォーマット仕様の変更を伴う場合と、伴わない場合の両方で、TCG技術を使用して、プラットフォームおよびDRMソフトウェアの完全性または信頼性を検証する。第2の実施形態は、既存のROAPプロトコルを変更することなしに、TCG技術を使用して、ROAPメッセージ、ROAPメッセージを構成する情報、およびROAP処理の完全性を強化する。第3の実施形態は、既存のROAPプロトコルのいくつかの変更を伴って、TCG技術を使用して、ROAPメッセージ、ROAP情報、およびROAP処理の完全性を強化する。
【解決手段】これらの方法は、TCG仕様と関係する技術を使用する。第1の実施形態は、DRM ROAP仕様およびDRMコンテンツフォーマット仕様の変更を伴う場合と、伴わない場合の両方で、TCG技術を使用して、プラットフォームおよびDRMソフトウェアの完全性または信頼性を検証する。第2の実施形態は、既存のROAPプロトコルを変更することなしに、TCG技術を使用して、ROAPメッセージ、ROAPメッセージを構成する情報、およびROAP処理の完全性を強化する。第3の実施形態は、既存のROAPプロトコルのいくつかの変更を伴って、TCG技術を使用して、ROAPメッセージ、ROAP情報、およびROAP処理の完全性を強化する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般に、無線通信ネットワークにおけるDRM(デジタル権利管理)方法に関する。より詳細には、本発明は、OMA(Open Mobile Alliance)DRM仕様に準拠して動作するシステムにおいてセキュリティ、完全性、および信頼性を強化するための方法を提供する。
【背景技術】
【0002】
OMA DRMは、移動電話機および移動デバイスの製造業者、ならびにモバイルサービスプロバイダのコンソーシアムであるOMAによって指定されるDRMシステムである。このスキームは、多くの移動電話機上で実施され、モバイルコンテンツプロバイダによって、プロバイダの製品およびサービスにDRMを追加するのに使用されることが意図される。OMA DRMの2つのバージョン、すなわち、OMA DRM1.0およびOMA DRM2.0が、公開されている。
【0003】
OMA DRM1.0は、コンテンツオブジェクトに関するデジタル権利の基本的管理に関するスキームを扱う。このため、OMA DRM1.0は、コンテンツオブジェクトに関しても、権利オブジェクトに関しても強力な保護は提供しなかった。OMA DRM1.0は、3つの配信方法、すなわち、転送ロック(ユーザが、コンテンツを他のユーザ、または他のデバイスに転送するのを防止する)、組み合わされた配信(組み合わされた権利オブジェクトとメディアオブジェクト)、および分離した配信(分離した権利オブジェクトとメディアオブジェクト)を規定する。OMA DRM1.0は、電話機に関する呼び出し音または壁紙などの小さいサイズのメディアオブジェクトを扱うように設計された。
【0004】
OMA DRM2.0は、OMA DRM1.0配信機構を改良し、拡張する。OMA DRM2.0に準拠するデバイスは、DRM PKI(公開鍵インフラストラクチャ)に基づく個別の証明書を有し、すなわち、各デバイスは、公開鍵、対応する秘密鍵を有するとともに、この事実を検証する証明書を有する。各RO(権利オブジェクト)は、機密性(暗号化によって)と完全性(デジタル署名によって)の両方に関して保護される。PKI、暗号化、および完全性検査の使用が、OMA DRM1.0システムのセキュリティと比べて、OMA DRM2.0システムのセキュリティを強化する。
【0005】
また、OMA DRM2.0は、デバイスとRI(権利発行者)との間の相互認証および相互登録、ROを要求すること、ROの配信に対する応答、またはROを配信することの拒否、ならびにデバイスがドメインに参加すること、およびドメインを退去することと関係する様々なサブプロトコルを含むROAP(権利オブジェクト獲得プロトコル)とまとめて呼ばれるプロトコルのセットも規定する。
【0006】
以下は、OMA DRMにおいて定義される主なエンティティのいくつかである。すなわち、
【0007】
アクタ アクタは、使用事例を実行する外部エンティティである。
【0008】
バックアップ/リモートストレージ ROおよびCO(コンテンツオブジェクト)を、元のデバイスに送り返すことを意図して、別のロケーションに転送すること。
【0009】
組み合わされた配信 保護されたコンテンツおよびROを配信するためのOMA DRM1.0メソッド。ROおよび保護されたコンテンツは、DRMメッセージという単一のエンティティの中で一緒に配信される。
【0010】
機密性 情報が、許可のない個人、エンティティ、またはプロセスに提供されない、または開示されないという特性。
【0011】
合成オブジェクト 包含によって1つまたは複数のメディアオブジェクトを含むCO。
【0012】
接続されたデバイス 適切なワイドエリアトランスポート/ネットワーク層インタフェースを介して、適切なプロトコルを使用してRIに直接に接続することができるデバイス。
【0013】
コンテンツ 1つまたは複数のメディアオブジェクト
【0014】
CI(コンテンツ発行者) DRMエージェントにコンテンツを提供するエンティティ。
【0015】
コンテンツプロバイダ CIまたはRIであるエンティティ。
【0016】
デバイス DRMエージェントを有するユーザ機器。デバイスは、接続されたデバイスであることも、接続されていないデバイスであることも可能であるが、この区別は、接続されたデバイスが、RIに直接に接続する能力を失うと、接続されていないデバイスになる可能性があるので、コンテキスト依存であり、性質が不定である。
【0017】
デバイス取り消し 或るデバイスがROを獲得することが、もはや信頼されないことをRIが示すプロセス。
【0018】
デバイスRO 或る特定のデバイスに、そのデバイスの公開鍵によって専用とされるRO。
【0019】
ドメイン ドメインROを共有することができるデバイスのセット。ドメイン内のデバイスは、ドメイン鍵を共有する。ドメインは、RIによって定義され、管理される。
【0020】
ドメイン識別子 ドメイン鍵の一意ストリング識別子。
【0021】
ドメイン鍵 128ビットの対称暗号鍵
【0022】
DRMエージェント デバイス上のメディアオブジェクトに関する許可を管理するデバイス内のエンティティ。
【0023】
DRMコンテンツ ROの中の許可セットに従って消費されるメディアオブジェクト。
【0024】
DRM時間 セキュリティで保護された、ユーザが変更できない時間源。DRM時間は、UTC時間フォーマットになっている。
【0025】
完全性 データが、許可のない仕方で変更、または破壊されていないという特性。
【0026】
ドメインに参加する RIが、デバイスをドメインに含めるプロセス。
【0027】
ドメインを退去する(参加解消する)RIが、取り消されていないデバイスをドメインから除外するプロセス。
【0028】
メディアオブジェクト デジタル作品または合成オブジェクト。
【0029】
ネットワークサービスプロバイダ 移動デバイスにネットワーク接続を提供するエンティティ。
【0030】
許可 DRMコンテンツに対してRIによって許される実際の使用または活動。
【0031】
再生する リソースの一過性の知覚可能な表現を作成すること。
【0032】
保護されたコンテンツ ROの中の許可セットに従って消費されるメディアオブジェクト。
【0033】
復元する 保護されたコンテンツおよび/またはROを外部ロケーションから、保護されたコンテンツおよび/またはROのバックアップの源とされたデバイスに送り返すこと。
【0034】
取り消す デバイスまたはRI証明書を無効と宣言するプロセス。
【0035】
RI(権利発行者) OMA DRMに準拠するデバイスにROを発行するエンティティ。
【0036】
RIコンテキスト RI ID、RI証明書チェーン、バージョン、アルゴリズム、およびその他の情報などの、4パス登録プロトコル中に所与のRIを相手にネゴシエートされた情報。RIコンテキストは、デバイスが、登録プロトコルを除いて、ROAPスイートのすべてのプロトコルに参加することに成功するのに必要である。
【0037】
RO(権利オブジェクト) 保護されたコンテンツにリンクされた許可およびその他の属性の集合。
【0038】
ROAP(権利オブジェクト獲得プロトコル) デバイスが、RIからROを要求し、獲得することを可能にするプロトコル。
【0039】
ROAPトリガ デバイスによって受信されると、ROAPを開始するURLを含むXML(拡張マークアップ言語)ドキュメント。
【0040】
状態のない権利 デバイスが状態情報を保持しなくてもよいRO。
【0041】
状態のある権利 デバイスが、状態情報を明示的に保持して、ROの中で表現される制約および許可が、正しく実施されることが可能であるようにしなければならないRO。以下の制約または許可のいずれかを含むROが、状態のある権利である。すなわち、<interval>、<count>、<timed−count>、<datetime>、<accumulated>、または<export>である。
【0042】
スーパ配布 (1)セキュリティで保護されていない可能性があるチャネルを介して、ユーザが保護されたコンテンツを他のデバイスに配布することを許し、さらに、そのデバイスのユーザが、スーパ配布された保護されたコンテンツに関するROを獲得することを可能にする機構。
【0043】
接続されていないデバイス ローカル接続技術を介する適切なプロトコル、例えば、OBEX over IrDA(object exchange over infrared)、Bluetooth、またはUSB(ユニバーサルシリアルバス)を使用して、接続されたデバイス経由でRIに接続することができるデバイス。
【0044】
ユーザ デバイスの人間ユーザ。ユーザは、デバイスを必ずしも所有しない。
【0045】
図1は、既存のOMA DRM2.0機能アーキテクチャ100の概略図である。アーキテクチャ100は、DRMシステム102、コンテンツプロバイダ104、およびユーザ106から成る。DRMシステム102は、CI110、RI112、DRMエージェント114、ネットワークストア116、およびリムーバブルメディア118を含む。CI110は、保護されたコンテンツ122を配布し、RI112は、RO124を配布する。DRMエージェント114は、保護されたコンテンツ122を再配布する。
【0046】
CI110は、DRMコンテンツ122を配信するエンティティである。OMA DRMは、DRMエージェント114に配信されるべきDRMコンテンツ122のフォーマット、ならびにDRMコンテンツ122が、様々なトランスポート機構を使用してCI110からDRMエージェント114にトランスポートされることが可能な仕方を定義する。CI110は、DRMコンテンツ122の実際のパッケージ化を自ら行っても、他の何らかの源からあらかじめパッケージ化されたコンテンツを受信してもよい。
【0047】
RI112は、DRMコンテンツ122に許可および制約を割り当て、RO124を生成するエンティティである。RO124は、DRMコンテンツ122に関連する許可および制約を表現するXMLドキュメントである。RO124は、DRMコンテンツ122がどのように使用されることが可能であるかを支配し、つまり、DRMコンテンツ122は、関連付けられたRO124なしに使用されることが可能でなく、関連付けられたROによって指定されるとおりにしか使用されることが可能でない。DRMコンテンツは、例えば、ROが、時間有効期限(例えば、10日)を有し、この時間有効期限の後、このコンテンツにアクセスするのに新たなROが必要とされる場合、複数のROに関連付けられることも可能である。
【0048】
DRMエージェント114は、DRMコンテンツ122の消費時点の執行を管理することを担う論理的エンティティである。DRMエージェント114は、デバイスの信頼される構成要素を実体化し、デバイス上のDRMコンテンツ122に関する許可および制約を執行すること、デバイス上のDRMコンテンツ(DRMエージェントを介してしかアクセスすることができない)へのアクセスを制御することなどを担う。
【0049】
DRMコンテンツ122は、配信される前に、許可のないアクセスからコンテンツ122を保護するようにパッケージ化される。CI110が、DRMコンテンツ122を配信し、RI122が、RO124を生成する。CI110およびRI112は、システム102において、物理的エンティティではなく、論理的役割を実体化する。例えば、1つの展開において、コンテンツ所有者が、DRMコンテンツをあらかじめパッケージ化し、その後、このコンテンツが、CIとRIの両方の役割をするコンテンツ配給元によって配布される。
【0050】
RO124が、DRMコンテンツ122がどのように使用されることが可能であるかを支配する。DRMコンテンツ122は、関連付けられたRO124なしに使用されることが可能でなく、RO124の中で指定される許可および制約に従ってしか使用されることが可能でない。OMA DRMは、ROからのDRMコンテンツの論理的分離を行う。DRMコンテンツとROは、別々に要求されても、一緒に要求されてもよく、別々に配信されても、同時に配信されてもよい。DRMコンテンツとROは、同時に配信される場合、通常、ともに、CI110によって提供され、ROおよびコンテンツは、DCF(DRMコンテンツフォーマット)に埋め込まれる。
【0051】
RO124は、鍵のセットによって、或る特定のDRMエージェント114に暗号上、結び付けられて、その特定のDRMエージェント114だけが、RO124にアクセスすることができるようにされる。DRMコンテンツ122は、有効なRO124を使用してしかアクセスすることができず、したがって、コンテンツ122は、自由に配布される、またはスーパ配布されることが可能である。
【0052】
OMA DRM2.0は、1つのROが、DRMエージェントのグループに結び付けられることを許す。そのようなグループは、ドメインと呼ばれる。或るドメインに配布されたDRMコンテンツおよびROは、そのドメインに属するすべてのDRMエージェントによってオフラインで共有され、アクセスされることが可能である。例えば、ユーザは、ユーザの電話機とユーザのPDAの両方で使用するためにDRMコンテンツを購入することができる。
【0053】
OMA DRM仕様は、DRMコンテンツのためのフォーマットおよび保護機構(つまり、DCF)、ROのためのフォーマット(REL(権利表現言語))および保護機構、暗号鍵の管理のためのセキュリティモデルを定義する。また、OMA DRM仕様は、DRMコンテンツおよびROが、プル(HTTPプル、OMAダウンロード)、プッシュ(WAPプッシュ、MMS)、およびストリーミングを含む一連のトランスポート機構を使用して、どのようにデバイスにトランスポートされることが可能であるかも定義する。しかし、OMA DRM仕様は、ネットワークエンティティ間、例えば、CI110とRI112の間の対話を全く扱わない。
【0054】
以下は、OMA DRM2.0仕様が範囲に含む使用事例の網羅的ではないリストである。
【0055】
1.基本プルモデル
【0056】
ユーザは、Webサイトにブラウズして行くことによって、ダウンロードすべきコンテンツを選択し、購入の条件を確認する。CI110は、コンテンツ122を識別し、保護する、すなわち、コンテンツ122をパッケージ化する。コンテンツ122は、CEK(コンテンツ暗号化鍵)を使用して暗号化される。デバイス能力が、公示されたMIMEタイプサポートなどを使用して検出されることが可能である。RI112が、コンテンツ122およびターゲットDRMエージェント114に関するRO124を生成する。RO124は、コンテンツトランザクションに関する許可、およびCEKを含む。最期に、RO124は、暗号化(RO暗号化鍵、つまり、REKを使用する)およびデジタル署名によって暗号で保護され、ターゲットDRMエージェント114だけに結び付けられる。次に、DRMコンテンツ122および保護されたRO124が、DRMエージェント114に配信される。
【0057】
2.DRMコンテンツのプッシュ
【0058】
代替の配布モデルは、先行する発見プロセスなしに、MMS(マルチメディアメッセージングサービス)、WAPプッシュ、または類似した方法を使用して、デバイスにコンテンツを直接にプッシュすることである。この使用事例の2つの変種が存在する。
【0059】
2A.コンテンツプッシュ
【0060】
CI110および/またはRI112は、或るユーザ、および或る特定のDRMエージェント114のいくらかの事前の知識を有することが可能であり、したがって、コンテンツ122およびRO124は、配信のためにフォーマットされ、パッケージ化されることが可能である。
【0061】
2B.プッシュによって開始されるプル
【0062】
この場合、CI110および/またはRI112は、ユーザ、またはユーザのDRMエージェント114についての事前の知識を全く有さないことが可能であるが、それでも、例えば、ユーザが、コンテンツを購入するようにユーザの気を引くコンテンツ122をプレビューすることを可能にするように、コンテンツを配信することを望む可能性がある。DRMコンテンツ122をユーザに直接にプッシュする代わりに、このコンテンツへのリンク、またはこのコンテンツのプレビューへのリンクが、送信されることが可能である。このリンクをたどることにより、ユーザは、或る特定のロケーションに連れて行かれ、その後、手続きは、基本プルモデルにおけるとおりに進む。
【0063】
3.DRMコンテンツのストリーミング
【0064】
基本プル使用事例とプッシュ使用事例はともに、コンテンツの全体がパッケージ化され、配信されるものと想定する。代替として、コンテンツは、ストリームとしてパケット化されて、配信されてもよい。この場合、ストリーム自体が保護される(暗号化される)。暗号化の厳密なフォーマットは、OMA DRMの範囲外とされており、既存の暗号化標準から選択されることが可能である。これらのストリームは、可能なパケット損失などに対処するように、ダウンロードに関してOMAによって規定される暗号化スキームとは異なる暗号化スキームを使用して保護されてもよい。しかし、ストリームが暗号化された後、ストリームへのアクセスは、離散的コンテンツに関して前段で説明したのと同一の手続きを介して制御されることが可能である。ROが生成され、ストリーム暗号化鍵が、CEKと同様にROの中に入れられ、次に、このROが、DRMエージェントと暗号上、結び付けられる。
【0065】
4.ドメイン
【0066】
ドメインは、オプションのフィーチャであり、すべてのRIによってサポートされるわけではない可能性がある。ドメインは、ROとCEKが或る特定のDRMエージェント114に結び付けられるOMA DRM2.0の基本モデルを拡張し、RI112が、権利およびCEKを、単一のDRMエージェントだけにではなく、DRMエージェントのグループに結び付けることを許す。すると、ユーザは、同一のドメインに属するすべてのDRMエージェントの間で、DRMコンテンツ122をオフラインで共有することができる。RI112は、ドメイン概念を使用して、ユーザが所有するいくつかのデバイスから、ユーザがDRMコンテンツ122にアクセスすることができるようにすることなどの、新たなサービスを提供する、あるいはユーザが、1つのデバイス(例えば、PC)を介して、別のデバイス(例えば、ポータブルプレーヤ)上で後に使用するために、DRMコンテンツおよび権利を購入する場合、接続されていないデバイスのサポートを提供することができる。
【0067】
5.バックアップ
【0068】
DRMコンテンツ122は、リムーバブルメディア118上に、ネットワークストア116の中に、または他の何らかの形態のストレージの中に格納されることが可能である。DRMコンテンツ122は、暗号化された形態で格納され、関連付けられたRO124を使用する或る特定のターゲットDRMエージェント114によってしかアクセスされることが可能でない。RO124は、ROが、状態のない許可だけしか含まない場合、バックアップの目的で格納されることが可能である。セキュリティモデルが、RO124がオフデバイスで格納される場合でさえ、RO124が保護されて、意図されるDRMエージェント114によってしかアクセスされることが可能でないことを確実にする。一部の許可は、DRMエージェント114による状態、例えば、限られた回数の再生の保持を要求する。そのようなROは、オフデバイスで格納されることが、そうすることにより、状態情報が失われることになる可能性があるので、可能でない。
【0069】
6.スーパ配布
【0070】
DRMコンテンツ122は、コピーされて、他のDRMエージェント114に転送されること、例えば、ユーザが、DRMコンテンツ122を友人に送信することが可能である。友人は、コンテンツ122にアクセスするために、DRMコンテンツパッケージの中のリンクを介してRI112に連れて行かれて、RO124を獲得する。
【0071】
7.エクスポート(非OMA DRMシステムへの)
【0072】
DRMコンテンツ122は、OMA DRM準拠ではないが、他の何らかのDRM機構をサポートするデバイス上で使用されるように、他のDRMシステムにエクスポートされることが可能である。OMA DRMアーキテクチャは、RI112が、所望する場合、別の特定DRMシステムへの変換を、DRMエージェント114が、場合により、その別のDRMシステムによって指定されるとおり実行する、許可を表明することを許す。RI112は、特定の外部DRMシステムだけに、このエクスポートを制限することができる。
【0073】
8.接続されていないデバイスのサポート
【0074】
OMA DRMは、接続されていないデバイスがコンテンツ122およびRO124を購入して、ダウンロードするのを助ける仲介役の働きを、接続されたデバイスがすることを可能にする。ユーザが、例えば、ネットワーク接続を全く有さないOMA DRMに準拠するポータブルデバイス(接続されていないデバイス)と、ネットワーク接続を有するOMA DRMに準拠する移動デバイス(接続されたデバイス)とを有することが可能である。接続されたデバイスを使用して、DRMコンテンツ122をブラウズして、購入し、DRMコンテンツ122を、接続されたデバイスにダウンロードした後、ユーザは、次に、接続されていないデバイス上でDRMコンテンツ122を再生することを所望することが可能である。この場合、接続されたデバイス上のDRMエージェント114は、RI112からドメインRO124を要求して、ダウンロードする。
次に、接続されたデバイス上のDRMエージェント114は、DCFの中にドメインRO124を埋め込む。次に、このDCFが、ローカル接続技術を介する適切なプロトコル、例えば、BluetoothまたはUSBを使用して、接続されていないデバイスに転送されることが可能である。接続されたデバイスと接続されていないデバイスの両方が、OMA DRM準拠であって、この機能をサポートしなければならない。また、接続されていないデバイスは、接続されたデバイスと同一のドメインに属さなければならない。
【0075】
セキュリティおよび信頼
【0076】
以下は、OMA DRM2.0のセキュリティ方策および信頼方策の概要である。一般に、いずれのDRMソリューションも、以下の2つのセキュリティ要件を満たす必要がある。すなわち、(1)保護されたコンテンツは、適切に認証され、許可されたDRMエージェントによってだけアクセスされなければならず、さらに(2)保護されたコンテンツ上の許可は、すべてのDRMエージェントによって遵守されなければならない。DRMコンテンツに関連する許可および制約の執行は、任意のDRMスキームのセキュリティ方策および信頼方策の主要な関心事である。関連付けられたROによって規定されるものを超えたDRMコンテンツへの許可のないアクセス、不正なコピーの作成、およびDRMコンテンツの再配布が、いずれのDRMシステムにも主な脅威を成す。
【0077】
OMA DRMシステムは、OMA環境における保護されたコンテンツのセキュリティで保護された配布および管理のための手段を提供し、前段で規定された要件を満たす。OMA DRMは、ROの制約下におけるコンテンツの保護された使用を確実にするDRMエージェントを使用することによって、消費時点でコンテンツおよびROの使用および保護を執行する。
【0078】
DRMコンテンツを配布するための基本ステップは、以下のとおり要約されることが可能である。すなわち、
【0079】
1.コンテンツパッケージ化。コンテンツは、セキュリティで保護されたコンテンツコンテナ(DCF)の中にパッケージ化される。DRMコンテンツは、対称CEK(コンテンツ暗号化鍵)を使用して暗号化される。コンテンツは、あらかじめパッケージ化されることが可能であり、すなわち、コンテンツパッケージ化は、オンザフライで行われなくてもよい。同一のCEKが、コンテンツのすべてのインスタンスに関して使用されるわけではなく、ただし、このことは、OMA DRMにおける要件ではない。
【0080】
2.DRMエージェント認証。すべてのDRMエージェントが、一意の秘密鍵/公開鍵ペアと、証明書とを有する。証明書は、デバイス製造業者、デバイスタイプ、ソフトウェアバージョン、通し番号などのさらなる情報を含む。このことは、CIおよびRIが、DRMエージェントをセキュリティで保護された仕方で認証することを可能にする。
【0081】
3.RO生成。ROは、DRMコンテンツが、関連付けられたROなしに使用されることが可能でないことを確実にするCEKを含む。ROは、許可(例えば、再生、表示、および実行)および制約(例えば、1ヶ月間、再生する、10分間、表示する)から成る。また、ROは、コンテンツにアクセスが行われる際に、或るユーザが居合わせること(例えば、ユーザの身元によって判定される)を要求する制約を含むことも可能である。これらの許可および制約、ならびにROに実体化される他の情報(例えば、著作権情報)は、ユーザに提示されることが可能である。
【0082】
4.RO保護。ROを配信する前に、ROのセンシティブな部分(CEKなどの)が、REK(権利暗号化鍵)を使用して暗号化され、次に、このROが、ターゲットDRMエージェントに暗号上、結び付けられる。このことにより、ターゲットDRMエージェントだけが、RO、CEK、およびDRMコンテンツにアクセスすることができることが確実にされる。さらに、RIが、ROにデジタルで署名する。また、ROは、CEKを含めることによって、DRMへのアクセスを支配する。OMA DRM REL(権利表現言語)が、DRMコンテンツの使用を支配する許可および制約のシンタックス(XML)およびセセマンティックスを規定する。ROは、RO独自のMIMEコンテンツタイプを有する。
【0083】
5.配信。次に、ROおよびDCFは、ターゲットDRMエージェントに配信されることが可能である。両方のアイテムは、本来的にセキュリティで保護されているので、任意のトランスポート機構(例えば、HTTP/WSP、WAPプッシュ、MMS)を使用して配信されることが可能である。ROとDCFは、例えば、MIME複数パートメッセージの中で、一緒に配信されることも、別々に配信されることも可能である。
【0084】
ROに関するOMA DRM信頼モデルは、双方によって認識され、信頼される主役のグループ、検証者、および1つまたは複数の認証機関が存在する、PKI(公開鍵インフラストラクチャ)に基づく。単一のエンティティが、選択されたコンテキストおよびソリューションのニーズに応じて、主役の役割をすることも、検証者の役割をすることもできる。PKIは、検証者と主役が、開かれた、セキュリティで保護されていないネットワークを介して通信する際に、検証者が、主役の身元、およびその他の属性を認証することを可能にする。そのようなシステムにおいて、通常、検証者は、認証の目的で、検証者が対話する相手の主役についてのセンシティブな情報を全く保持する必要はない。さらに、CA(証明機関)は、主役と検証者の間のトランザクションに直接に関与していない。RIは、DRMエージェントの証明書が、RIによって検証可能であり、取り消されていない場合、DRMエージェントが正しく振る舞うことを信頼する。同様に、DRMエージェントは、RIの証明書が、DRMエージェントによって検証可能であり、取り消されていない場合、RIが正しく振る舞うことを信頼する。
【0085】
OMA DRMに適用されるPKIの主なエンティティは、CA、デバイス、およびRIである。OMA DRMの認証プロトコルおよび鍵転送プロトコルは、RIが、デバイスを認証することができ、デバイスが、RIを認証することができることを要求する。そのような相互認証は、ROAPによって達せられる。
【0086】
さらに、デバイスは、デバイス公開鍵およびデバイス秘密鍵、ならびに適切なCAによって署名された関連する証明書を備えさせられる(製造時に、または後に)ものと想定される。RIによって表明される証明書選好に基づき、デバイスは、適切な証明書を提供しなければならない。デバイスは、完全性および機密性の保護を有するローカルストレージの中に秘密鍵を格納することを要求される。
【0087】
また、RIも、公開鍵、秘密鍵、およびCAによって署名された証明書を与えられる。証明書チェーン(1つのCAによって署名された公開鍵所有者の証明書と、他のCAによって署名されたCAの0、または1つ以上のさらなる証明書とを含む複数の証明書のチェーン)は、信頼の証明書チェーンの検証のための認証プロトコルの時点で、デバイスに提示される。
【0088】
複数のCAが、DRMシステム内に存在することが可能であることに留意されたい。ROAPプロトコルは、RI証明書に署名するCAが、プロトコルの実行中に使用するために、OCSP(オンライン証明書ステータスプロトコル)レスポンダを実行することを要求する。また、CAは、発行された証明書の使用を支配する適切な証明書ポリシーを定義することも要求される。
【0089】
以下は、OMA DRMセキュリティの主な態様を説明する。
【0090】
1.データが、許可のないパーティによってアクセスされることが可能でないことを確実にする機密性。前述したとおり、保護されたコンテンツは、適切に認証され、許可されたDRMエージェントによってだけアクセス可能でなければならない。この目標を達するのに、保護されたコンテンツは、暗号化される。暗号化鍵は、各メディアオブジェクトに一意であり、ROが、意図される受信者によってしかアクセス可能でない鍵の中にラップされた暗号化鍵を担持する。
【0091】
2.或るパーティが、別のパーティに自らの身元を明かすプロセスである認証。OMA DRMにおいて、相互DRMエージェント−RI認証が、4パス登録プロトコル、2パスRO獲得プロトコル、および2パスドメイン参加プロトコルにおいて達せられる。使用されるプロトコル、および送信されるメッセージに依存して、認証は、ナンス上、またはタイムスタンプ上のデジタル署名を介して達せられる。1パスRO獲得プロトコルは、タイムスタンプ上のデジタル署名を介してRI認証を実現する。1パスRO獲得プロトコルは、RIに対してDRMエージェントを認証しないが、保護されたコンテンツが、受信者の公開鍵でラップされることにより、認証は、鍵結び付けを介して間接的に行われる。2パスドメイン退去プロトコルは、タイムスタンプ上のデジタル署名を介して、RIに対してDRMエージェントを認証する。2パスドメイン退去プロトコルは、DRMエージェントに対してRIを認証しない。RIは、ROの配信中にDRMエージェントに対して自らを認証することを要求される。このことにより、RIの真正性について或る程度の保証が提供される。
【0092】
3.データ完全性保護は、データの許可のない変更を検出する能力を確実にする。OMA DRMにおいて、データ完全性保護は、適宜、ROAPメッセージ上、およびRO上のデジタル署名を介して達せられる。
【0093】
4.鍵確認は、保護された鍵を含むメッセージの受信者に、メッセージ送信者が鍵値を知っていることを保証する。DRMコンテキストにおいて、この特性は、或るRIからのROを、別のRIが許可なく再発行することを防止する。OMA DRMシステムにおいて、鍵確認は、保護された鍵の諸部分をMAC鍵として使用することによる、保護された鍵、および送信するパーティの身元に対するMAC(メディアアクセス制御)を介して達せられる。
【0094】
DRMエージェントは、正しい振舞いと、セキュリティで保護された実施の両方の点で、RIによって信頼されなければならない。OMA DRMにおいて、各DRMエージェントは、そのDRMエージェントを識別し、そのエージェントと鍵ペアとの間の結び付きを証明する、一意の鍵ペア、および関連する証明書を備えさせられる。このことにより、RIは、標準のPKI手続きを使用してDRMエージェントをセキュリティで保護された仕方で認証することが可能になる。
【0095】
証明書の中の情報は、RIが、ビジネス規則、コンテンツの価値などに基づいて、ポリシーを適用することを可能にする。例えば、RIは、或る製造業者を信頼することが可能であり、あるいはRIによって定義されたいくつかの基準に従って信頼されるべき、または信頼されるべきでないことが知られているDRMエージェントの更新されたリストを保持することが可能である。
【0096】
DCF(DRMコンテンツフォーマット)は、独自のMIMEコンテンツタイプを有する、暗号化されたコンテンツに関するセキュリティで保護されたコンテンツパッケージである。暗号化されたコンテンツに加え、DCFは、コンテンツ記述(元のコンテンツタイプ、ベンダ、バージョンなど)、RI URI(ユニフォームリソース識別子)(ROが獲得されることが可能なロケーション)などのさらなる情報を含む。このさらなる情報は、暗号化されず、ROが取得される前にユーザに提示されることが可能である。DCF内のDRMコンテンツをアンロックするのに必要とされるCEKは、RO内に含まれる。このため、ROなしにDRMコンテンツにアクセスすることは可能でなく、DRMコンテンツは、ROの中で規定されたとりにしか使用されることが可能でない。OMA DRMは、DRMエージェントが、DCFの完全性を検証することを可能にして、許可のないエンティティによるコンテンツの変更を防止する機構を含む。
【0097】
OMA DRMシステムは、DRMエージェントの中にDRM時間が存在することを想定する。ユーザは、DRM時間を変更することができないので、DRM時間が、OCSPレスポンダによって保持される時間と同期されることが可能な機構が、定義される。いくつかの制約(例えば、絶対時間制約)、ならびにROに関する配信プロトコルのいくつかの態様は、セキュリティで保護された時間源を有するDRMエージェントに依拠する。OMA DRM仕様のコンテキストにおけるDRM時間は、正確な時間、ならびにユーザが変更することが可能でない時間値を意味する。OMA DRM仕様は、DRM時間が、必要な際、例えば、DRM時間が、長い停電の後に失われた場合、同期される機構を提供する。一部の限られた能力の接続されていないデバイスは、リアルタイムのクロックをサポートしないことが可能であり、このため、DRM時間をサポートしない可能性がある。しかし、接続されたデバイスは、DRM時間をサポートしなければならない。
【0098】
OMA DRMは、ROリプレー保護攻撃を防止する。ROリプレー攻撃の例は、中間者が、DRMエージェントへの配信中に、限られた回数の実行でROを傍受する場合である。DRMエージェント上で権利が失効した際、この傍受されたROが、中間者から再び配信される(リプレーされる)可能性がある。OMA DRMは、このこと、および類似した攻撃が行われることを防ぐ。
【0099】
OMA DRMシステムは、前段で列挙したセキュリティ機構の使用を介してアプリケーション層セキュリティを提供する。このため、OMA DRMシステムは、トランスポート層セキュリティに依拠しない、またはトランスポート層セキュリティを前提としない。
【0100】
ROAPは、OMA DRM2.0において、ROに関する情報のセキュリティで保護された認証ベースの交換を可能にすることに中心的な役割を果たす。ROAPは、RIと、デバイス内のDRMエージェントとの間のDRMセキュリティプロトコルスイートを表す一般的な名前である。このプロトコルスイートは、以下のいくつかのサブプロトコルを含む。すなわち、
【0101】
1.図2に示される、RIにデバイスを登録するための4パスプロトコル。
【0102】
2.図3に示される、ROの要求および配信を含む2パスRO獲得プロトコル。
【0103】
3.1パスRO獲得プロトコルは、図4に示されるとおり、RIからデバイスへのROの配信(例えば、メッセージング/プッシュ)と関係する。
【0104】
4.図5に示される、デバイスがドメインに参加する2パスドメイン参加プロトコル。
【0105】
5.図6に示される、デバイスがドメインを退去する2パスドメイン退去プロトコル。
【0106】
図2は、4パス登録プロトコル200の流れ図である。プロトコル200は、デバイス202、RI204、およびOCSPレスポンダ206を利用する。デバイス202は、デバイスID(RI204が、OCSPレスポンダ206に後に確認をとることができるデバイスの証明書のハッシュ)、およびその他の情報などの情報を含む、デバイスハローメッセージを送信すること(ステップ210)によって、RI204との連絡を開始する(場合により、ROAPトリガを受信した後)。テーブル1は、デバイスハローメッセージの主な構成要素を示す。デバイスハローメッセージの中の情報のいずれも、完全性保護されておらず、すなわち、このメッセージに関する署名は、存在しない。
【0107】
【表1】
【0108】
RI204は、デバイスハローメッセージに応答して(ステップ210)、RIの証明書資格情報(RI IDの形態の)、いくつかのセッション関連の(リプライ防止目的の)ナンスおよびセッション番号、ならびにRI204が認識するデバイスについての信頼チェーンに関する情報などの他のオプションの情報などの情報を含む、RIハローメッセージをデバイス202に送信する(ステップ212)。テーブル2は、RIハローメッセージのフォーマットを示す。RIハローメッセージの中の情報のいずれも、完全性保護されていないことに留意されたい。
【0109】
【表2】
【0110】
RIハローメッセージの中に含まれる情報の検証が成功すると、デバイス202は、要求時間、セッションID、および署名などの必須の情報と、証明書チェーン、信頼されるRI権限アンカ、拡張子などのオプションの情報とを含む登録要求メッセージを送信する(ステップ214)。テーブル3は、登録要求メッセージのフォーマットを示す。登録要求メッセージは、末尾において、登録要求メッセージの中の署名フィールドまでの、デバイス202とRI204の間で交換されるすべてのメッセージの、すなわち、デバイスハローメッセージ全体、RIハローメッセージ全体、および署名フィールドまでの(このフィールドを除く)登録要求メッセージのフィールドのデジタル署名を含む。このデジタル署名は、デバイスの秘密鍵を使用して作成される。このデジタル署名を含めることにより、関連するROAPメッセージのいくらかの完全性保護がもたらされる。
【0111】
【表3】
【0112】
デバイス202が、拡張子の中の情報を介して、OCSP検証が必要ない、またはサポートされないことを示すのでない限り、RI204は、デバイス202によってRI204に供給される情報の検証を要求するOCSP要求メッセージをOCSPレスポンダ206に送信する(ステップ216)。OCSPレスポンダ206は、要求メッセージの中でこの情報を探して、この情報を検証し、要求の結果を含むOCSP応答メッセージを戻そうと試みる(ステップ218)。
【0113】
RI204は、登録が成功したか、失敗したかという指示、ならびに他の情報を含む登録応答メッセージをデバイス202に送信する。テーブル4は、登録応答メッセージのフォーマットを示す。登録応答メッセージは、末尾に、登録要求メッセージおよび登録応答メッセージのSHA−1ハッシュ(署名フィールドまでの、署名フィールドを除く)を含む。このデジタル署名は、RIの秘密鍵を使用して行われる。デジタル署名を含めることにより、関連するROAPメッセージのいくらかの完全性保護がもたらされる。SHA−1ハッシュが、このデジタル署名に関して使用されるが、デジタル署名を適用するための任意の適切なアルゴリズムが使用されることが可能であることに留意されたい。
【0114】
【表4】
【0115】
図3は、2パスRO獲得プロトコル300の流れ図である。プロトコル300は、デバイス202およびRI204を利用し、4パス登録プロトコル200が完了して、デバイス202が、RI204についての有効な証明書チェーンを受信した後に機能する。プロトコル300は、デバイス202によって、RI204からROを要求するのに使用される。デバイス202は、RO要求メッセージをRI204に送信して、ROを要求する(ステップ310)。テーブル5は、RO要求メッセージのフォーマットを示す。RO要求メッセージは、メッセージのデジタル署名(署名フィールドを除く)を含む。
【0116】
【表5】
【0117】
RI204は、要求メッセージに応答して、デバイス202にRO応答メッセージを送信する(ステップ312)。RO応答メッセージは、ROを含む、またはROが送信されないという指示を含む。
【0118】
テーブル6は、RO応答メッセージのフォーマットを示す。RO応答メッセージは、成功した状態の場合、署名フィールドを除くRO要求メッセージおよびRO応答メッセージのSHA−1ハッシュであるデジタル署名を含む。
【0119】
【表6】
【0120】
図4は、1パスRO獲得プロトコル400の流れ図である。プロトコル400は、デバイス202およびRI204を利用する。プロトコル400において、RI204は、デバイス202による要求なしに、ROを含むRO応答メッセージをデバイス202に一方的に送信する(ステップ410)。プロトコル400は、例えば、プッシュ使用事例を適用する。テーブル7は、RO応答メッセージのフォーマットを示す。
【0121】
【表7】
【0122】
図5は、2パスドメイン参加プロトコル500の流れ図である。プロトコル500は、デバイス202およびRI204を利用する。デバイス202が、ドメインに参加することを望む場合、デバイス202は、RI204にドメイン参加要求メッセージを送信する(ステップ510)。RI204は、この要求を評価し、ドメイン参加応答メッセージをデバイス202に送信する(ステップ512)。テーブル8は、ドメイン参加要求メッセージのフォーマットを示し、テーブル9は、ドメイン参加応答メッセージのフォーマットを示す。
【0123】
【表8】
【0124】
【表9】
【0125】
図6は、2パスドメイン退去プロトコル600の流れ図である。プロトコル600は、デバイス202およびRI204を利用する。デバイス202が、ドメインを退去することを望む場合、デバイス202は、RI204にドメイン退去要求メッセージを送信する(ステップ610)。RI204は、この要求を評価して、デバイス202にドメイン退去応答メッセージを送信する(ステップ612)。テーブル10は、ドメイン退去要求メッセージのフォーマットを示し、テーブル11は、ドメイン退去応答メッセージのフォーマットを示す。
【0126】
【表10】
【0127】
【表11】
【0128】
1パスRO獲得プロトコルを除いて、ROAPスイートに含まれるプロトコルのすべては、ROAPトリガを使用して開始されることが可能である。また、デバイス202は、ユーザ対話の結果、一方的にプロトコルを開始することもできる。RI204は、ROAPトリガを生成して、デバイス202に送信して、ROAPプロトコル交換をトリガする。代替として、RI204は、必要な情報(RO識別子やドメイン識別子などの)を他のシステムに供給することによって、ROAPトリガ生成をこれらのシステムに委任してもよい。また、ROAPトリガ(RI204によって直接に生成されたか、間接的に生成されたかにかかわらず)は、他のシステム(例えば、CI)によってデバイス202に送信されることも可能である。
【0129】
デバイス202が、ROAPトリガを受信すると、デバイス202は、可能な限り早くROAPプロトコル交換を開始する。ROAPトリガを受信した結果、ROAPプロトコルを開始するのに先立って、適切なユーザ同意が、得られていなければならない。ROAPは、いくつかのプロトコルを含むので、ROAPトリガは、デバイス202によって開始されるべき実際のプロトコル(例えば、登録、RO獲得、ドメイン参加、またはドメイン退去)の指示を含む。
【0130】
ROAPメッセージ、およびこれらのメッセージが、プロトコルによって、どのように扱われるかは、RO,および関連する処理を提供するだけでなく、OMA DRM2.0におけるROを取り巻くセキュリティ機能も提供する。より具体的には、以下のセキュリティ態様および信頼態様が、ROAPプロトコルによって扱われる。すなわち、
【0131】
1.RIとデバイスの間の相互認証、
【0132】
2.様々なメッセージにおいてナンスを使用することによって、リプレー攻撃に対処すること、
【0133】
3.ROAPメッセージ、およびROAPメッセージの諸部分の完全性を保護すること、および
【0134】
4.ROAPメッセージ、またはROAPメッセージの諸部分におけるセキュリティで保護されたDRM時間の検証である。
【0135】
(信頼されるコンピューティング技術)
【0136】
最近、信頼されるコンピューティング技術が、おおむね、TCG(Trusted Computing Group)の技術的傘下において文献および製品に出現している。TCG技術は、コンピューティングエンティティが、信頼チェーンを使用することによって、エンティティ、および他のデバイスの信頼性を確立することができ、したがって、そのようなデバイス上の処理またはコンピューティングは、以下のとおりであることが可能である。すなわち、
【0137】
1.プラットフォーム、ならびに様々なHW(ハードウェア)構成要素およびSW(ソフトウェア)構成要素の信頼性に関して評価され、
【0138】
2.適切な信頼レベルが確立された場合にだけ、検証され、外部要求があると、エンティティまたはデバイス自らに対して、ならびに他のエンティティまたはデバイスに対して検証されることが可能であり、さらに
【0139】
3.外部パーティは、他のデバイスとの情報および処理の交換に関する評価および決定を実行することができ、そのようなターゲットデバイスの表明された信頼レベルに基づく。
【0140】
TCGは、以下のフィーチャを有する、TPM(信頼される処理モジュール)と呼ばれるコア処理モジュールを定義する。すなわち、
【0141】
1.モジュール、およびモジュールのインタフェースの物理的保護、
【0142】
2.保護された揮発性のストレージスペース、および保護された不揮発性のストレージスペース、
【0143】
3.暗号化、およびデジタル署名を実行することができるモジュール内部の保護された暗号化機能、
【0144】
4.ハッシュ拡張によるプラットフォーム、およびプラットフォームのSW構成要素の「状態」を連続的にキャプチャするPCR(プラットフォーム構成レジスタ)の使用、
【0145】
5.デバイスの認証のルートの役割をするが、ただし、直接的な仕方でそのような役割をするのではないPKIに基づく、デバイス特有のセキュリティで保護されたEK(承認鍵)の存在。EKは、決して外部に開示されないが、AIK(構成証明アイデンティティ鍵)と呼ばれるEKのエイリアスが、プラットフォームの完全性測定値に署名するのに使用され、さらに
【0146】
6.データの「密封」を、AIKによって署名されたPCR値と併せて、メモリ「BLOB」の中で使用して、プラットフォーム完全性またはSW完全性(TPMからの、または密封メモリBLOBからの合致するPCR値によって測定され、検証された)が検証された場合に限って、データがアクセスされる、または抽出されることが可能であるようにすること。
【0147】
信頼されるコンピューティング技術が、特に移動電話デバイスのコンテキストにおいて、そのような移動デバイス上のDRMアプリケーションをセキュリティで保護することへの可能な応用のために、検査される。TCG技術の使用によってDRMアプリケーションをセキュリティで保護するようにこれまでに提案された方法は、TPM密封の手続き、およびメモリBLOBを使用して、TCG鍵を使用するROAPプロトコル処理の後、TPM、および鍵保護を有するストレージエリアの中にDRM関連のデータをセキュリティで保護された仕方で格納することを含んでいた。
【0148】
しかし、既存の従来技術は、プラットフォーム、および/またはDRMソフトウェアに対してどのように「信頼」を確立し、使用すべきかを明示的に扱う、または秩序立った仕方で扱うことはしない。また、従来技術は、ROAPメッセージの中の完全性をセキュリティで保護して、OMA DRM2.0システムにおける完全性処理を強化することもしない。本発明は、そのような目的で新たな技術を含む。
【0149】
現在のOMA DRM2.0仕様は、CA、RI、およびデバイスが関与するPKIに基づく、強いセキュリティ方法を提供する。しかし、OMA DRM2.0仕様の範囲内でも、OMA DRM2.0準拠であるデバイスおよびRIの不特定の実施に関連しても、プラットフォーム、SW、エージェント、およびメッセージのセキュリティおよび完全性と関係する脆弱性が、存在する。
【0150】
OMA DRM仕様は、デバイスまたはRIが、OMA DRM2.0仕様を遵守している場合でも、いずれのデバイスまたはRIも直面する可能性がある様々な脅威および脆弱性を認識している。これらの脆弱性には、以下が含まれる。すなわち、
【0151】
1.攻撃者が、DRMシステムのエンティティを物理的に、またはそれ以外で侵害しようと試みることが可能な、エンティティ侵害。エンティティ侵害攻撃のタイプには、デバイス上のDRMエージェント、およびRIにおけるDRM SWを侵害することが含まれる。エンティティ侵害の結果には、秘密鍵、ドメイン鍵、RO暗号化鍵、コンテンツ暗号化鍵、および保護されたコンテンツの開示、ならびに、例えば、DRMエージェントのリプレーキャッシュの完全性保護が失われること、および/またはDRMエージェントの内部に格納された権利の保護が失われることが含まれる。さらに、DRM時間が失われることが、生じる可能性もある。侵害されたCAまたはOCSPレスポンダのPKIに対する影響は、例えば、非特許文献1において説明される。
【0152】
OMA DRMシステムは、侵害されたエンティティによって生じる損害を最小限に抑えるのに、証明書取り消しに依拠する。DRMエージェントおよびRIは、エンティティの証明書ステータスを調べることによって、DRMエージェントおよびRIが通信している相手のエンティティが、侵害されていないことを常に検証しなければならない。エンティティ侵害攻撃は、「順方向」でも、「逆方向」でも行われる可能性がある。順方向侵害攻撃は、DRMエンティティ(RI、DRMエージェント、CI、CA、またはOCSPレスポンダ)に対してであり、許可のない振舞いにつながる。逆方向侵害攻撃は、DRMエージェントのセキュリティ、完全性設定、および構成を無力化する、または脆弱にする。
【0153】
2.攻撃者が、DRMエージェントとRIの間で送信されるメッセージを削除することができ、通常、DoS(サービス拒否)攻撃をもたらすメッセージ削除。メッセージ削除攻撃には、登録プロトコル中、またはRO獲得プロトコル中のメッセージ削除、リプレーナンス削除、ROAPトリガの削除などが含まれることが可能である。
【0154】
3.攻撃者が、DRMエージェントとRIの間で送信される任意のメッセージを変更することができ、通常、DoS攻撃をもたらすメッセージ変更。メッセージ変更攻撃には、登録プロトコル中の変更、ドメイン参加プロトコル中の変更、およびドメイン退去プロトコル中の変更、ならびに様々なROAPトリガに対する変更が含まれることが可能である。
【0155】
4.攻撃者が、RIとDRMエージェントの間の任意のポイントで通信チャネルにメッセージを挿入することができるメッセージ挿入。また、攻撃者は、メッセージを記録して、これらのメッセージを後の時点でリプレーしようと試みることもできる。メッセージ挿入攻撃は、登録プロトコルの最中に挿入されたメッセージ、2パスRO獲得プロトコルの最中に挿入されたメッセージ、1パスRO獲得プロトコルの最中に挿入されたメッセージ、および様々なROAPトリガに挿入されたメッセージを含むことが可能である。
【0156】
5.一般的なDoS攻撃、トラフィック解析などの受動的攻撃、およびプライバシー開示などのその他の攻撃。
【0157】
現在のOMA DRM仕様およびOMA DRM実施形態の以下の問題が、特定される。OMA DRMスキームに適用された「完全性」の拡大された概念が、定義される。従来の意味で、OMA DRM仕様は、ROAPメッセージ完全性の小さい範囲だけしか扱わない。本発明において定義される完全性の拡大された概念において、以下において、どこで、どのような種類の完全性が考慮されることが可能であるか留意されたい。
【0158】
1.DRMプラットフォーム完全性。DRMプラットフォーム完全性は、プラットフォームエンティティにおける、またはプラットフォームエンティティ内の、すなわち、デバイス、RI、およびコンテンツ機能を含む物理的エンティティにおける完全性と関係する。異なるエンティティには、OS(オペレーティングシステム)、起動コード(例えば、PCの事例におけるBIOS)、メモリアクセスのためのHW/FW(ファームウェア)/SW、セキュリティ関連の機能(暗号法および鍵管理、ならびにポリシー、証明書などの秘密データの特権的格納)を処理する様々なHW/FW/SWエンティティ、ならびにネットワーク接続HW/FW/SWおよびローカル接続HW/FW/SWが含まれる。プラットフォーム完全性は、プラットフォームが、有効であり、真性であり、正当なプロセスによる他は、変更されておらず、意図されるとおりにしか動作しないかどうかを判定する。
【0159】
2.DRM SW完全性。DRM SWとは、OMA DRM仕様、およびOMA DRM仕様の手続きに特有の機能を実行するデバイス内、RI内、またはCI内に存在するソフトウェアエンティティおよびソフトウェア構成要素を指す。デバイスにおいて、DRMエージェントは、DRM SWから成る。RIおよびCIにおいて、DRM SWとは、ROパッケージ化、DCFフォーマット、コンテンツ暗号化、コンテンツ配信もしくはRO配信、検証、ROAP処理などのDRM特有の機能を実行するSWのセットをまとめて指す。DRM SW完全性は、DRM SWが、有効であり、真性であり、正当なプロセスによる他は、変更されておらず、意図されるとおりにしか動作しない場合に、維持される。
【0160】
3.ROAPメッセージおよびROAP情報の完全性。ROAPメッセージ、およびこれらのメッセージを構成する情報の完全性は、そのような情報が、有効であり、真性であり、正当なプロセスによる他は、変更されていない場合、維持される。OMA DRM2.0仕様において、ROAPメッセージのいくつかのサブセット、およびこれらのサブセットを構成する情報は、デジタル署名の使用によって完全性保護される。
【0161】
4.メディアオブジェクトおよびDRMコンテンツの完全性。メディアオブジェクトおよびDRMコンテンツも、完全性保護されなければならず、すなわち、メディアオブジェクトおよびDRMコンテンツが、デバイスにおいて格納されているか、RIにおいて格納されているか、CIにおいて格納されているか、あるいはいずれかの2つのパーティ間で伝送中または配信中であるかにかかわらず、変更される、削除される、または不正に挿入されることがあってはならない。特に関心を引くのが、DRMコンテンツが、基本的に開かれたチャネルを使用して配信される場合の、移動デバイスへのコンテンツの転送に適用可能な、コンテンツのOTA(無線)配信である。
【0162】
5.DRM関連の情報の完全性。エンティティID(デバイスID、RI IDなど)、暗号化鍵(CEK、REK)および署名鍵、RO自体、コンテキスト情報、証明書、およびその他の信頼チェーン関連の情報などのDRM関連の情報は、セキュリティで保護されなければならず、このことは、これらの情報が、機密性を保護されるだけでなく、完全性も保護されなければならないことを意味する。
【0163】
現在のOMA DRM2.0仕様も、既存の従来技術も、エンティティ侵害または完全性問題に対するソリューションを提供したように思われないことに留意されたい。ソリューションのこの欠如は、以下の問題をもたらす。すなわち、例えば、すべてのROAP手続きが、OMA DRM2.0仕様に準拠して正しく実施された場合でも、RIのプラットフォームが信頼できるかどうか、デバイスはどのようにして本当に知ることができるか。つまり、RIのプラットフォームが、ROAPプロトコルの一環としてデバイスが送信するデータを乱用しないかどうか、またはDRM処理自体を乱用しないかどうかを、デバイスは、どのようにして知ることができるか。例えば、デバイスは、RIのプラットフォームSWが、侵害されており、デバイスのさもなければ有効な使用権利を制限するため、RIが、デバイスの使用権利を恣意的に、誤って制限するかどうかを知らない。DRMソフトウェアの完全性の問題に関して、同様の問題が生じる。より具体的には、前述した完全性の拡大された概念から見た現在のOMA DRM2.0システムの問題のいくつかは、以下のとおりである。
【0164】
1.プラットフォームおよびDRM SWの完全性を検査して、報告する方法の欠如。前段で特定されたエンティティ侵害脅威と関係して、OMA DRM2.0仕様によって指定される、またはTCG1.2使用事例の一環としての、デバイスとRIとの間の明確な、構造化されたプラットフォーム完全性検証、およびSWエージェント完全性検証のための方法は、従来技術において、全く存在しない。このことは、DRMエージェントに関してだけでなく、プラットフォーム完全性検証に関して特に当てはまる。
【0165】
2.プラットフォーム(デバイスと関係して、PCもしくはPDA,あるいはRIに関して、サーバなどの)が、悪意のある仕方で侵害されることが可能であり、これにより、DRMエージェントおよびRIエージェントSWが、正しい、機密性保護され、完全性保護された情報を与えられても、正しく動作することが妨げられることになる可能性がある。例えば、さもなければよく保護されたDRMエージェントSWが、処理に先立って、処理中に、または処理後に、いくらかの情報を共有メモリの中に平文で格納する可能性がある。侵害されたプラットフォームは、そのような事例において、共有メモリにひどくアクセスして、情報を削除する、情報を変更する、または新たな偽の情報を挿入して、この情報が、そのような偽の情報を真性と認識する可能性があるDRMエージェントSWによって後に処理される得る可能性がある。このことは、DoS攻撃、プライベート情報の許可のない開示、またはDRM ROもしくはDRMコンテンツの許可のない配信、配布、または消費をもたらす可能性がある。
【0166】
3.DRM関連の情報を処理するSWの部分であるDRMエージェントSWおよびRI SWが、様々な理由で侵害される可能性がある。そのようなSWが、例えば、ウイルス、または他の悪意のあるSWエンティティによって変更されることが可能である。プラットフォームまたはDRM SWのそのような侵害の1つの結果は、OMA DRM2.0が考慮するメッセージおよび情報、特にROAPプロトコルメッセージの完全性が後に侵害されることである。1つには、ROAPメッセージのすべてではなく、一部だけが完全性保護されるため、ROAPメッセージは、理論上、侵害されたデバイスと、不正な、つまり、侵害されたRIとの間で同期された仕方で操作されることが可能である。メッセージは、デバイスとRIの両方において同期した仕方で変更されることが可能であり、メッセージは、同一の仕方で変更されたため、それでも、「完全性検証」されているように見える可能性がある。
【0167】
4.ROAPメッセージの不十分な完全性保護。メッセージ完全性と関係して、ROAPメッセージ、および様々なメッセージフィールドによって担持される情報は、OMA DRM2.0仕様によっては解決されない脆弱性を被る。例えば、OMA DRM2.0仕様の中で現在、指定されているROAPメッセージ完全性保護は、以下のような穴を残す。すなわち、
【0168】
4A.すべてのROAPメッセージが、完全性保護されるわけではない。すべてのメッセージの中にデジタル署名を含めるわけではないことにより、一部の場合において脆弱性がもたらされる可能性がある。
【0169】
4B.ROAPメッセージ、または情報の一部のフィールドが、デジタル署名によって完全性保護されている場合でさえ、一旦、そのような情報が解読され、完全性検査され、その後、平文で使用されると、悪意のあるエンティティが、この平文情報にアクセスして、それまでに完全性検査された情報を削除する、改変する、または再配布する可能性がある。このため、強化された完全性保護が、要求される。
【0170】
5.DRMコンテンツ、およびDRMコンテンツの配信の完全性に関する脆弱性。より具体的には、以下の問題が存在する。すなわち、
【0171】
5A.コンテンツ完全性検査機構が、不完全である。例えば、コンテンツが伝送されている、または配信されている(例えば、OTAダウンロード)最中のコンテンツの完全性が、規定されていない。例えば、DFCに関する署名は、ROAP手続きにおいて使用するためにだけ生成される。ROAP手続きが行われるまで、この手続きより前に、例えば、CIにおける格納中に、コンテンツ完全性を管理する完全性検査機構は、全く存在しない。
【0172】
5B.コンテンツ暗号化は、ROAPプロトコルにおいて使用するためにさえ、必須であるが、完全性検査は、単にオプションである。
【0173】
5C.特に、ストリーミングサービスに関するパケット化されたコンテンツに関して、PDCFフォーマットは、タイミング問題を有する。不正に変更されているパケットが、ダウンロードされる可能性があり、ストリーム全体の完全性が検査されることが可能である前に、消費される(すなわち、メディアプレーヤ上で再生される)可能性さえある。
【先行技術文献】
【非特許文献】
【0174】
【非特許文献1】IETF RFC3280
【発明の概要】
【発明が解決しようとする課題】
【0175】
中心的問題は、以下のとおりとなる。すなわち、様々なパーティ(デバイス、RI、およびCI)はどのようにして、プラットフォーム完全性、およびDRM SW完全性を確信することができるか。このため、DRMエージェントSWまたはRI SWが依拠するプラットフォーム(例えば、OS、BIOS,ドライバ、メディアプレーヤ、通信ソフトウェア、共有メモリなど)の完全性を強化し、検証する方法が、必要とされる。本発明は、従来技術の欠点に対処する。
【課題を解決するための手段】
【0176】
本発明は、OMA DRM仕様 v2.0と関係するエンティティ、メッセージ、および処理の完全性を強化するいくつかの方法を開示する。これらの方法は、業界フォーラム、TCG(Trusted Computing Group)によって規定される、信頼されるコンピューティング(Trusted Computing)技術として一般に知られる技術を使用する。本発明の第1の実施形態において、DRM ROAP仕様およびDCF仕様の変更を伴う場合と、伴わない場合の両方の、プラットフォームおよびDRM SWの完全性または信頼性を検証する技術が、開示される。第2の実施形態において、既存のROAPプロトコルを変更することなしに、OMA DRM ROAPメッセージ、ROAPメッセージを構成する情報、およびROAP処理の完全性を強化する技術が、開示される。第3の実施形態において、既存のROAPプロトコルのいくつかの変更を伴って、ROAPメッセージ、情報、および処理の完全性を強化する技術が、開示される。
【0177】
本発明のより詳細な理解は、例として与えられ、添付の図面と併せて理解されるべき、好ましい実施形態の以下の説明から得ることができる。
【図面の簡単な説明】
【0178】
【図1】既存のOMA DRM2.0機能アーキテクチャを示すブロック図である。
【図2】既存のOMA DRM2.0 ROAP 4パス登録プロトコルを示す流れ図である。
【図3】既存のOMA DRM2.0 ROAP 2パスRO獲得プロトコルを示す流れ図である。
【図4】既存のOMA DRM2.0 ROAP 1パスRO獲得プロトコルを示す流れ図である。
【図5】既存のOMA DRM2.0 ROAP 2パスドメイン参加プロトコルを示す流れ図である。
【図6】既存のOMA DRM2.0 ROAP 1パスドメイン退去プロトコルを示す流れ図である。
【図7】OMA DRM2.0エンティティ間のマルチパーティプラットフォーム完全性検査を示すブロック図である。
【図8】2つのエンティティが、デバイスとRI、またはデバイスとCIであることが可能である場合の2つのエンティティ間でプラットフォーム完全性検証を実行するための方法を示す流れ図である。
【図9】従来の信頼検査を使用してデバイスとRIの間で相互プラットフォーム完全性検査を実行するための4パスROAP登録プロトコルを示す流れ図である。
【図10】変更されたデバイスハローメッセージ、および変更されたRIハローメッセージを使用して、デバイスとRIの間で相互プラットフォーム完全性検査を実行するための4パスROAP登録プロトコルを示す流れ図である。
【図11】2つのエンティティが、デバイスとRI、またはデバイスとCIであることが可能である場合の2つのエンティティ間でDRMソフトウェア完全性検査を実行するための方法を示す流れ図である。
【図12】デバイスとRIの間で相互DRMソフトウェア完全性検査を実行するための2パスROAP RO獲得プロトコルを示す流れ図である。
【図13】密封結び付け、およびメモリBLOB生成を含むTCG技術を使用したROAPメッセージおよびROAP処理の完全性を向上させるための方法を示す流れ図である。
【発明を実施するための形態】
【0179】
以降、「無線送信/受信ユニット」(WTRU)という用語には、ユーザ機器、移動局、固定加入者ユニットもしくは移動加入者ユニット、ポケットベル、または有線環境または無線環境において動作することが可能な他の任意のタイプのデバイスが含まれるが、以上には限定されない。以降、言及される場合、「基地局」という用語には、ノードB、サイトコントローラ、アクセスポイント、または無線環境における他の任意のタイプのインタフェースデバイスが含まれるが、以上には限定されない。
【0180】
本発明は、DRMエンティティ(例えば、デバイス、RI、またはCI)の信頼状態または完全性に関する情報が、OMA DRM手続きの前提条件として、いずれの2つのDRMエンティティの間でも明示的に、相互に要求され、交換される方法を開示する。
【0181】
この方法の一般的なアーキテクチャ700が、図7に示される。このアーキテクチャは、4つのDRMエンティティ、すなわち、デバイス702、RI704、CI706、およびPCA(プライベート証明機関)708を含む。プラットフォーム完全性検査は、PCA708が、その他のDRMエンティティ(例えば、デバイス702、RI704、およびCI706)に関する信頼されるコンピューティング(例えば、TCG)資格証明のレコードを有し、それらのTCG資格証明の証明に関する信頼のルートを提供するものと想定する。
【0182】
互いの間で相互プラットフォーム完全性検査を望む任意のエンティティペア(例えば、デバイス702とRI704、デバイス702とCI706、またはRI704とCI706)が、信頼されるコンピューティング対応である(例えば、TCG TPM(信頼される処理モジュール)710を備えている)。このことは、信頼されるコンピューティング対応のDRMエンティティが、TPM710(または均等物)を有するだけでなく、AIK712、SML714、およびBLOBを使用する保護されたメモリ716などの、関連するTCGリソースも有することを暗示する。やはり存在するのが、OSまたはプラットフォームソフトウェア718およびDRMソフトウェア720である。
【0183】
以上の要件が満たされる場合、様々なDRMエンティティの任意のペアが、PCA708、および信頼されるコンピューティング能力を使用して、プラットフォーム完全性またはプラットフォーム信頼状態を互いに検査することができる。例として、デバイス702とRI704の間の相互完全性検査のための手続きは、以下のとおりである。
【0184】
デバイス702、RI704、およびCI706がすべて、OS構成要素、または他のプラットフォームソフトウェア構成要素の自己検査(ステップ730)、およびDRMソフトウェアの自己検査(ステップ732)を実行することができる。自己検査は、より大きい検証プロセス(後段でより詳細に説明される)の一環として要求されることも、スタンドアロンのプロセスであることも可能である。これらの自己検査のいずれかが不合格であった場合、そのことは、そのエンティティが、侵害されており、信頼されるべきでないことの表れである可能性がある。
【0185】
デバイス702は、デバイス702のプラットフォームTCG資格証明をRI704に送信する(ステップ740)。プラットフォームTCG資格証明の例には、署名されたTCGプラットフォーム証明書、または署名されたTPM証明書が含まれるが、以上には限定されない。資格証明の一部として、デバイス702は、自己証明された信頼状態フラグ、または自己証明されたプラットフォーム完全性検査済みフラグを補足的な情報として、RI704に送信することもできる。デバイス702が、RI704のプラットフォーム完全性を検証する場合、ステップ740で送信される資格証明情報は、RI704が、デバイス702のプラットフォーム完全性を検証する手続きを開始することをデバイス702が望むという、デバイス702による指示も含む。デバイス702は、RIのプラットフォーム完全性ステータスの検証がオプションのフィーチャである場合に限って、RI704のプラットフォーム完全性を検証すべきかどうかに関する決定を行うことができ、一実施形態では、RIのプラットフォーム完全性を検証することは、必須のフィーチャであることに留意されたい。
【0186】
デバイス702から資格証明情報を受信すると、RI704は、この資格証明情報をPCA708に中継し(ステップ742)、デバイス702についての資格証明、特に、デバイスの最新の信頼性を検証するよう、PCA708に要求も行う。すると、PCA708は、デバイス702に関する最新の信頼性情報(例えば、プラットフォーム信頼レベルなど)をRI704に送信する(ステップ744)。PCA708からデバイスプラットフォーム信頼性情報を受信し、オプションとして、デバイス702から補足的な情報も受信すると、RI704は、デバイス702の信頼レベルを評価する。RI704は、デバイスプラットフォームの完全性に十分な信頼を与えて、登録プロトコルまたはRO獲得プロトコルなどのDRM手続きをさらに進めるかどうかを決定する。
【0187】
デバイス702は、必須の手続きとして、またはオプションの手続きとして、ステップ740〜744の場合と同様な、相互の仕方でRI704のプラットフォーム完全性を評価することができる。より具体的には、RI704が、RI704のプラットフォームTCG資格証明についての情報を、デバイス702に送信する(ステップ750)。資格証明の一部として、RI704は、自己証明された信頼状態フラグ、または自己証明されたプラットフォーム完全性検査済みフラグを補足的情報として、デバイス702に送信することもできる。
【0188】
RI704からTCG関連の情報を受信すると、デバイス702は、この情報をPCAに中継し(ステップ752)、RI704についての資格証明、特に、RIの最新の信頼性を検証するよう、PCA708に要求も行う。すると、PCA708は、RI704に関する最新の信頼性情報をデバイス702に送信する(ステップ754)。RI704に関してPCA708からRIプラットフォーム信頼性情報を受信し、オプションとして、RI自体から補足的な情報も受信すると、デバイス702は、RI704の信頼レベルを評価する。デバイス702は、RIプラットフォームの完全性に十分な信頼を与えて、登録プロトコルまたはRO獲得プロトコルなどのDRM手続きをさらに進めるかどうかを決定する。
【0189】
デバイス702は、必須の手続きとして、またはオプションの手続きとして、CI706のプラットフォーム完全性を評価することができる。CI706が、CI706のプラットフォームTCG資格証明についての情報を、デバイス702に送信する(ステップ760)。資格証明の一部として、CI706は、自己証明された信頼状態フラグ、または自己証明されたプラットフォーム完全性検査済みフラグを補足的な情報として、デバイス702に送信することもできる。
【0190】
CI706からTCG関連の情報を受信すると、デバイス702は、この情報をPCAに中継し(ステップ706)、CI706についての資格証明、特に、CIの最新の信頼性を検証するよう、PCA708に要求も行う。すると、PCA708は、CI706に関する最新の信頼性情報をデバイス702に送信する(ステップ764)。CI706に関してPCA708からCIプラットフォーム信頼性情報を受信し、オプションとして、CI自体から補足的な情報も受信すると、デバイス702は、CI706の信頼レベルを評価する。デバイス702は、CIプラットフォームの完全性に十分な信頼を与えて、DRM手続きをさらに進めるかどうかを決定する。
【0191】
デバイス702のプラットフォーム完全性が、以下のとおり、CI706によって検証されることが可能である。デバイス702は、デバイス702のプラットフォームTCG資格証明についての情報をCI706に送信する(ステップ770)。資格証明の一環として、デバイス702は自己構成証明信頼状態検査フラグまたはプラットフォーム完全性検査フラグを補足情報としてCI706に送信することも可能である。デバイス702が、CI706のプラットフォーム完全性を検証する場合、ステップ770で送信される資格証明情報は、CI706が、デバイス702のプラットフォーム完全性を検証する手続きを開始することをデバイス702が望むという、デバイス702による指示も含む。デバイス702は、CIのプラットフォーム完全性ステータスの検証がオプションのフィーチャである場合に限って、CI706のプラットフォーム完全性を検証すべきかどうかに関する決定を行うことができ、一実施形態では、CIのプラットフォーム完全性を検証することは、必須のフィーチャであることに留意されたい。
【0192】
デバイス702から資格証明情報を受信すると、CI706は、この資格証明情報をPCA708に中継し(ステップ722)、デバイス702についての資格証明、特に、デバイスの最新の信頼性を検証するよう、PCA708に要求も行う。すると、PCA708は、デバイス702に関する最新の信頼性情報をCI706に送信する(ステップ774)。PCA708からデバイスプラットフォーム信頼性情報を受信し、オプションとして、デバイス702から補足的な情報も受信すると、CI706は、デバイス702の信頼レベルを評価する。CI706は、デバイスプラットフォームの完全性に十分な信頼を与えて、DRM手続きをさらに進めるかどうかを決定する。
【0193】
前述の例では、ステップ740〜744は、デバイス702が、RI704に対してデバイス702の完全性ステータスを検証するのに、本発明の必須のフィーチャであることに留意されたい。しかし、デバイス702に対してRI704のプラットフォーム完全性を検証すること(ステップ750〜754)、デバイス702に対してCI706のプラットフォーム完全性を検証すること(ステップ760〜764)、およびCI706に対してデバイスプラットフォーム完全性を検証すること(ステップ770〜774)は、DRMシステムにおける、オプションであるが、それでも強く推奨されるフィーチャである。
【0194】
これらの手続きは、検証される必要があるエンティティによる能動的な開始によって開始される必要はないことにも留意されたい。これらの完全性検証手続きは、その他のパーティの完全性を検証することを所望するエンティティによる要求で始まることが可能である。そのような場合において、ステップ740、750、760、または770のそれぞれには、その他のパーティのプラットフォーム完全性の検証を要望するエンティティが、関係のある信頼関連の情報を送信するよう、その他のパーティを呼び出す、またはその他のパーティに要求する別のステップが先行する。
【0195】
代替の実施形態では、実際的なOMA DRMシステム実施に関して、前述した、提案されるプラットフォーム完全性検証手続きに関する条件またはトリガ機構には、以下が含まれることが可能である。
【0196】
1.デバイスプラットフォーム完全性検証手続き(すなわち、ステップ740〜744)が、以下の1つまたは複数によって実行されることが可能である。
【0197】
1A.デバイスが、新たな4パスROAP登録プロトコルを開始することを要望する前。
【0198】
1B.各RIにつき1回、その特定のRIへの最初の登録が行われる前。この場合、RIは、最初の登録より前に1回、デバイスのTCG資格証明を受信し、次に、RIは、デバイスの資格証明情報をTPM鍵に結び付けることによって、RI自らのTPMの下で、この資格証明情報を保護する。RIは、後に、この格納されたTCG資格証明の結び付きを解除して、定期的に、またはいくつかのイベント時に、例えば、OCSP CAを調べることによって、RIが受信したデバイスのTCG資格証明が依然として有効であるかどうかを検証する。
【0199】
1C.定期的に、指定された時間、例えば、デバイスが、同一のRIに対して前回の登録プロトコルを完了して以来、TDEV-PLATFORM-LAST-REGが経過するたびに。
【0200】
1D.定期的に、指定された時間、例えば、デバイスが、同一のRIに対してデバイスの完全性ステータスを前回に検証して以来、TDEV-PLATFORM-LAST-REPORTが経過するたびに。
【0201】
2.RIプラットフォーム完全性検証手続き(すなわち、ステップ750〜754)が実施される場合、実施される際に、実施されるプラットフォーム完全性検証手続きは、以下の1つまたは複数によって実行されることが可能である。
【0202】
2A.各デバイスにつき1回、その特定のデバイスへの最初の登録が行われる前。この場合、デバイスは、最初の登録より前に1回、RIのTCG資格証明を受信し、次に、デバイスは、RIの資格証明情報をTPM鍵に結び付けることによって、デバイス自らのTPMの下で、この資格証明情報を保護する。デバイスは、後に、この格納されたTCG資格証明の結び付きを解除して、定期的に、またはいくつかのイベント時に、例えば、OCSP CAを調べることによって、デバイスが受信したRIのTCG資格証明が依然として有効であるかどうかを検証する。
【0203】
2B.RIがデバイスに対してRIの完全性ステータスを検証することをデバイスが望むというデバイスからの指示を、スタンドアロンのメッセージとして、または変更されたROAPプロトコルメッセージの一部として、RIが受信するといつでも。
【0204】
2C.定期的に、指定されたセキュリティで保護された時間、例えば、RIが、デバイスに対してRIの完全性ステータスを前回に検証して以来、TRI-PLATFORM-LAST-REPORTが経過するたびに。
【0205】
3.デバイスとCIの間のプラットフォーム完全性検証に関して、前述した機構と同様の機構が、完全性検証プロセスの定期的発生および/またはイベント駆動の発生に関して考慮されることが可能である。また、CIのプラットフォーム完全性のデバイスによる検証の場合、検証は、コンテンツが購入される、またはダウンロードされることが必要とされるのに先立って毎回、実行されることも可能であり、場合により、その逆(すなわち、デバイスのプラットフォーム完全性が、CIに対して検証されなければならない)も同様である。
【0206】
従来技術は、堅牢なDRMのアプリケーションに結合されたTCG技術を使用する「セキュリティで保護された起動」の使用を考慮してきた。そのようなスキームにおいて、プラットフォームのOS、および他の起動関連のコードは、デバイスが起動されるといつでも、完全性検査され、プラットフォーム完全性検査を暗黙に実行してからでないと、いずれのDRMアプリケーションも実行されることが可能でない。本発明は、起動時プラットフォーム完全性検査のより系統立った、明示的な使用とともに、所定の期間に基づく他の時点におけるプラットフォーム完全性検査、ならびにいくつかのイベントの発生時のプラットフォーム完全性検査を提供する。また、本発明は、プラットフォーム完全性検査をデバイスからRIおよびCIにまで一般化する。継続的なプラットフォーム完全性検査は、デバイスが、或る特定の有効なCOを正しく受信しただけで、RIまたはCIが、その時点から将来にわたって無期限に信頼できると見なされるべきことにはならないということのために、有益である。信頼性の定期的な、さらに/またはイベント駆動の継続的検証は、良好な保護機構を提供する。
【0207】
また、デバイスとCIの間の完全性検査の必要性に関して、コンテンツが、ROより前に着信した場合でも、コンテンツは、CIのプラットフォームまたはCIのDRM SWが侵害されると、侵害される可能性がある。例えば、ユーザが、或るファイルをダウンロードしたものと想定されたい。ROが、まだ獲得されていない場合でも、ユーザは、コンテンツを誤ってクリックする可能性があり、あるいはコンテンツに対して有効性検査を実行する可能性がある。コンテンツが、侵害されたている(例えば、コンテンツにウイルスが添付されている)場合、コンテンツは、ROなしでも、デバイスに損害を与える可能性がある。また、デバイスとCIの間のダウンロード前の対話において(例えば、発見段階中に)、侵害されたデバイスが、例えば、コンテンツに添付されたウイルスを、CIを宛先とするメッセージに追加することによって、CIに害を与える可能性がある。さらに、ビジネスの点から、CIは、侵害されたデバイスにコンテンツを送信することを望まず、つまり、例えば、侵害されたデバイスは、許可のない受信者にコンテンツを無料で再配布する可能性がある。このため、デバイスとCIの間の相互プラットフォーム(およびSW)完全性検証は、システム全体を保護することにメリットがある。
【0208】
また、前段のアーキテクチャの説明において概要を述べた中心的な考えを実現する、いくつかの異なる仕方が存在することが可能であることに留意されたい。2つのそのような例が、後段で説明されるが、これらは、前段で説明されるアーキテクチャに基づくより広い概念の説明的な例に過ぎないことに留意されたい。
【0209】
(プラットフォーム完全性検証)
【0210】
図8は、2つのエンティティ間のプラットフォーム完全性検証を実行するための方法800の流れ図である。この2つのエンティティは、デバイスとRI、デバイスとCI、またはRIとCIであることが可能である。方法800は、RE(要求するエンティティ)とTE(ターゲットエンティティ)とを利用し、つまり、ペアのいずれのエンティティ(デバイス、RI、またはCI)が、REであることも可能であることに留意されたい。方法800は、いずれのエンティティがREであり、いずれのエンティティがTEであるかにかかわらず、同一の仕方で動作する。
【0211】
方法800は、REが、TEのプラットフォーム完全性ステータスを報告するよう、TEに要求を送信することから始まる(ステップ802)。この要求に応答して、TEは、TEのTCG資格証明をREに送信する(ステップ804)。これらのTCG資格証明には、例えば、プラットフォーム資格証明、TPM資格証明、または準拠資格証明が含まれることが可能である。次に、REが、TEのTCG資格証明を、これらの資格証明の検証のためにOCSPレスポンダに送信する(ステップ806)。OCSPレスポンダは、TEのTCG資格証明を精査して、検証ステータスをREに報告する(ステップ808)。
【0212】
REが、TE自らのプラットフォーム完全性ステータスを報告するよう、TEに要求を送信する(ステップ810)。TEは、TEのプラットフォーム完全性ステータスを検査し(ステップ812)、プラットフォーム完全性ステータスフラグをREに送信し(ステップ814)、方法は、終了する(ステップ816)。
【0213】
方法800は、ROAPプロトコルの変更が行われなくても(図9に関連して後段で説明される)、ROAPプロトコルの変更が行われても(図10に関連して後段で説明される)、適用されることが可能である。
【0214】
(ROAPプロトコルの変更なしの完全性検証)
【0215】
図9は、ROAPプロトコルとは別個にTCG技術を使用して(すなわち、OCSPレスポンダ/PCA906を利用して)、デバイス902とRI904の間で完全性関連の情報を交換する方法900の流れ図である。方法900では、同一のエンティティ906が、DRM処理のためのPCAとしても、TCG処理のためのOCSPレスポンダとしても示されていることに留意されたい。方法900では、プラットフォーム完全性検証(破線の長方形で示される)は、ROAP4パス登録プロトコルに先立って実行される。登録プロトコルより前にプラットフォーム完全性検証を実行することは、登録プロトコルが、頻繁には実行されず、プラットフォーム完全性検証プロセスが、完了するのにいくらかの時間を要するため、有用であり、つまり、プラットフォーム完全性検証が、各メッセージで実行されたとした場合、システムの全体的な動作は、不必要に減速させられる可能性がある。当業者は、プラットフォーム完全性検証が実行された後、1つだけのデバイスハローメッセージが、信頼されるデバイスを示すので、RIによって受信されるものと想定することができる。複数のデバイスハローメッセージが、同一のデバイスからRIによって受信されたとした場合、このことは、DoS攻撃の表れである可能性がある。また、プラットフォーム完全性検証は、認証プロトコルおよびオブジェクト獲得プロトコルに関連して実行されることも可能である。
【0216】
デバイス902は、RI904を相手に4パス登録プロトコルを開始することに先立って、RI904を相手に、プラットフォーム完全性の相互検証を実行する別の手続きセットを開始する。デバイス902はまず、デバイス902自らのTCG資格証明(例えば、プラットフォーム資格証明、TPM資格証明、準拠資格証明など)、あるいはTCG資格証明を含む、またはTCG資格証明と関係する他の情報を、RI904に送信する(ステップ910)。オプションとして、デバイス902は、RI904自らのプラットフォーム完全性ステータスを検査して、デバイス902に報告するよう、RI904に要求を送信することも行い、この要求には、デバイス資格証明が含められる。
【0217】
RI904は、デバイスのTCG資格証明を検証するようPCA906に要求する(ステップ912)。PCA906は、RIの要求に応答して、デバイスのTCG資格証明に関する情報を送信する(ステップ914)。
【0218】
RI904は、デバイス902のプラットフォーム完全性ステータスフラグを報告するよう、デバイス902に要求する(ステップ916)。また、デバイス902が、ステップ910で、RI904が、RI904のプラットフォーム完全性ステータスを検証して、報告することを要求し、かつRI904が、この要求に応じることを望み、応じることができる場合、RI904は、RI904自らのTCG資格証明、あるいはTCG資格証明を含む、またはTCG資格証明と関係する他の情報を、ステップ916で、デバイス902に送信する。RI904が、この要求に応じることができない、または応じることを望まない場合、RI904は、「応じない」メッセージをデバイスに送信する。RI904は、リソースが限られたRI(すなわち、RIが、この要求に応答するのに利用可能なリソースを十分に有さない)、またはデバイス信頼性検査が不合格であることを含め、いくつかの理由で、この要求に応答しない可能性がある。デバイスは、デバイスがRIに対して有する信用レベルに依存して、このプロトコルを中止することができ、つまり、デバイスが、RIを信頼する場合、デバイスは、RIが、この要求に応答することを拒否した場合でも、このプロトコルを続ける可能性が高い。RI904から、プラットフォームステータスを検査する要求を受信すると、デバイス902は、デバイス902自らのプラットフォーム完全性ステータスを検査する(ステップ918)。
【0219】
デバイス902は、RIのTCG資格証明を検証するよう、PCA906に要求する(ステップ920)。PCA906は、デバイス902からこの要求を受信すると、RIのTCG資格証明に関する情報を戻す(ステップ922)。デバイス902は、デバイス902のプラットフォーム完全性ステータスフラグをRI904に送信する(ステップ924)。RI904が、RI904の完全性ステータスを検査するよう、デバイス902から要求を受信し、RI904が、この要求に応じることを望み、応じることができる場合、RI904は、RI904自らのプラットフォーム完全性を検査する(ステップ926)。次に、RIは、RIのプラットフォーム完全性ステータスフラグをデバイス902に戻す(ステップ928)。RI完全性検査に関するオプションのステップは、任意の順序で実行されることが可能であり、つまり、それらのステップは、図9に示されるとおりにデバイス完全性検査と絡み合わされなくてもよい。さらに、RIは、RI自らの完全性検査を開始することができる。また、RIが、可能な理由のいずれかで、RI自らのTCG資格証明情報で要求に完全には応答することを拒否する場合、RIは、例えば、ステップ922で、適切な仕方で、そのような事実をデバイスに示すことができる。
【0220】
方法900は、デバイス902およびRI904が、相互プラットフォーム完全性検証を実現することを可能にする。そのような検証後、デバイスは、ROAP登録プロトコルを開始することができる。図9に示される登録プロトコルのステップ(ステップ930〜940)は、前述した方法200のステップ210〜220と同一である。また、これらの手続きは、周期的な間隔でトリガされる、または繰り返されることが可能であることにも留意されたい。
【0221】
(ROAP登録プロトコルの変更を伴う完全性検証)
【0222】
図10は、別の例示的な実施形態において、デバイス1002とRI1004が、OCSPレスポンダ/PCA1006のサービスをやはり利用して、完全性関連の情報を交換する方法1000を示す。方法1000では、ROAP登録プロトコルの既存のデバイスハローメッセージおよびRIハローメッセージは、TCG資格証明と、プラットフォーム完全性検証を求める、相手への要求をともに伝えるように変更される。
【0223】
デバイス1002は、変更されたデバイスハローメッセージをRI1004に送信し(ステップ1010)、このメッセージは、デバイスTCG資格証明と、RI1004のプラットフォーム完全性を報告するようにという、RI1004へのオプションの要求とを含む。RI1004は、これらのデバイス資格証明を、検証ためにPCA1006に転送する(ステップ1012)。次に、PCA1006は、デバイスTCG資格証明をRI1004に戻す(ステップ1014)。RI1004は、変更されたRIハローメッセージでデバイス1002に応答し(ステップ1016)、このメッセージは、RIのTCG資格証明をオプションとして含む。
【0224】
次に、デバイス1002は、オプションとして、RIのTCG資格証明を検査するようPCA1006に要求を送信する(ステップ1018)。PCA1006はRIの資格証明を検査し、結果をデバイス1002に報告する(ステップ1020)。デバイス1002は、デバイス1002自らの完全性ステータスを検査し(ステップ1022)、完全性ステータスをRI1004に報告する(ステップ1024)。
【0225】
デバイス1002が、RI1004が、RI1004の完全性ステータスを報告することを要求した場合、RI1004は、プラットフォーム完全性検査を実行し(ステップ1026)、完全性ステータス、例えば、RI1004の信頼状態フラグを、デバイス1002に送り返す(ステップ1028)。ステップ1030〜1036は、ROAP登録プロトコルの図2に示されるステップ214〜220と同一である。
【0226】
(DRMソフトウェアの完全性を検査すること)
【0227】
図11は、DRMエンティティの任意のペアの間でDRM SW(例えば、デバイスに常駐するDRMユーザエージェントSW、あるいはRIまたはCIに常駐するDRM SW)の完全性を検査するための方法1100の流れ図である。RE(要求するエンティティ)が、DRM SW完全性検査を実行するよう、TE(ターゲットエンティティ)に要求を送信する(ステップ1102)。TEは、TEのDRM SW完全性を検査し(ステップ1104)、DRM SW完全性ステータスフラグをREに送信し(ステップ1106)、方法は、終了する(ステップ1108)。TEが、デバイスである場合、デバイスドライバおよびメディアプレーヤSWの完全性が、DRM SWの完全性とは別個に検査されることが、これら2つの構成要素が、デバイス上に別々に存在する場合、可能であることに留意されたい。
【0228】
方法1100は、REが、TEからDRM SW完全性検査を獲得することだけに関する。相互DRM SW完全性検査を実行するのに、方法1100は、REからTEに1回、次に、TEからREに1回(REとTEが役割を交替して)の、2回、実行される必要がある。相互DRM SW完全性検査中、これらの要求は、絡み合わされる(図12に示されるとおり)ことも、図11に示されるとおり、分離されることも可能である。この方法の動作は、相互DRM SW完全性検査が実行されている場合、変化しない。
【0229】
OMA DRM2.0仕様は、そのような想定が、どのようにして有効に実施されることが可能であるかを示唆することなしに、DRMユーザエージェントSW(または本発明において使用される用語では、デバイスDRM SW)、およびRI(またはRIのDRM SW)が、暗黙に信頼されることが可能であるものと想定する。このため、OMA DRM2.0仕様における認証プロトコルは、既に信用できると考えられるエンティティ間の実際の認証手続きだけしか規定しない。明白な理由で、この暗黙のSW信頼想定は、実際には、それらの想定を実施し、検証する実際のステップなしに、自動的に想定されることは可能でない。このセクションで説明される方法は、そのような具体的なステップにかかわる。
【0230】
図12は、ROAP RO獲得プロトコルに関連してDRM SW検査を適用するための方法1200の流れ図である。この方法1200は、デバイス1202、RI1204、およびOCSPレスポンダ/PCA1206を利用する。第1に、PCA1206は、デバイス1202およびRI1204と通信して、プラットフォーム完全性検査およびROAP登録プロトコルを実行する(ステップ1210)。デバイス1202とRI1204が、相互プラットフォーム完全性検査、単方向DRM SW完全性検査、または相互DRM SW完全性検査を実行する(ステップ1212)。
【0231】
RI1204が、デバイスのDRM UA(ユーザエージェント)SW完全性を検査して、報告するよう、デバイス1202に要求を送信する(ステップ1214)。デバイス1202が、デバイス1202の最新のDRM UA SW完全性を検査する(ステップ1216)。デバイス1202は、オプションとして、RIのDRM SW完全性を検査して、報告するよう、RI1204に要求を送信する(ステップ1218)。要求された場合、RI1204は、RI1204の最新のDRM SW完全性を検査する(ステップ1220)。デバイス1202が、デバイスDRM SW完全性ステータスフラグをRI1204に送信する(ステップ1222)。前に要求されている場合、RI1204が、RI DRM SW完全性ステータスフラグをデバイス1202に送信する(ステップ1224)。オプションのRI完全性検査のステップは、任意の順序で実行されることが可能であり、図12に示されるとおりにデバイス完全性検査と絡み合わされる必要はないことに留意されたい。
【0232】
方法1200は、例示されるデバイス/RI対話の代わりに、デバイスとCIの間の相互DRM SW完全性検証に関して一般化されることが可能であることに留意されたい。ステップ1210〜1224が完了すると、デバイス1202は、例えば、図3に関連して前述したステップ310および312と同一であるステップ1226および1228における2パスRO獲得プロトコルを開始することができる。方法1200は、RO獲得プロトコルに関連して図示されるものの、方法1200は、他の任意のROAPプロトコルに関連して使用されることが可能であり、ただし、方法1200に関連するオーバヘッドを最小限に抑えるのに、方法1200は、任意の所与の時点で、ROAPプロトコルの適切に選択されたサブセットだけしか伴わずに実行されることが可能であることにさらに留意されたい。実際的なOMA DRMシステム実施形態に関して、前述した、提案されるプラットフォーム完全性検証手続きおよび/またはDRM SW完全性検証手続きのための条件またはトリガ機構のいくつかには、以下が含まれることが可能である。すなわち、
【0233】
1.デバイスDRM SW完全性検証手続きは、以下の1つまたは複数によってトリガされることが可能である。
【0234】
1A.デバイスが、新たな2パスROAP登録プロトコル、2パスドメイン参加プロトコル、または2パスドメイン退去プロトコルを開始することを要望する前。
【0235】
1B.定期的に、指定された時間、例えば、デバイスが、同一のRIに対して2パスROAP登録プロトコル、2パスドメイン参加プロトコル、または2パスドメイン退去プロトコルを前回に完了して以来、TDEV-DRM-LAST-ROAPが経過するたびに。
【0236】
1C.定期的に、指定された時間、例えば、デバイスが、前回に、デバイスのDRM SW完全性ステータスを検証して、同一のRIに報告して以来、TDEV-DRM-LAST-REPORTが経過するたびに。
【0237】
1D.デバイスが、デバイスのDRM SWを更新するといつでも。
【0238】
1E.プラットフォームSWが、更新される、または変更されるといつでも。
【0239】
2.RI DRM完全性検証手続きは、以下の1つまたは複数によって実行されることが可能である。
【0240】
2A.RIがデバイスに対してRIのDRM SW完全性ステータスを検証することをデバイスが望むというデバイスからの指示を、スタンドアロンのメッセージとして、または変更されたROAPプロトコルメッセージの一部として、RIが受信するといつでも。
【0241】
2B.定期的に、指定された時間、例えば、RIが、前回に、RIのDRM SW完全性ステータスを検証して、デバイスに報告して以来、TRI-DRM-LAST-REPORTが経過するたびに。
【0242】
2C.RIが、RIのDRM SWを更新するといつでも。
【0243】
2D.ユーザが、ストリーミングコンテンツの場合のように、コンテンツを頻繁に獲得している場合において、デバイスがRO要求を送信するのに先立って毎回。
【0244】
デバイスとCIの間のプラットフォーム完全性検証に関して、前述した機構と同様の機構が、DRM SW完全性検証プロセスの定期的発生および/またはイベント駆動の発生に関して考慮されることが可能である。
【0245】
DRMプラットフォーム検証およびDRM SW検証のための提案される方法は、互いに無関係に実行されることが可能であるが、これらの検証手続きが、手続きのグループの一部として組み合わされることが可能であることも企図される。そのような実施形態では、DRMプラットフォーム検証ステップは、DRM SW検証ステップの前提条件と考えられる。例えば、デバイスとRIの間の完全性検証のために、デバイスとRIはまず、前述したとおり、DRMプラットフォーム検証手続きを実行することによって、互いのプラットフォーム全体に対する信頼を確立する。トリガ機構は、一般的なプラットフォーム検証トリガ条件を含む。次に、DRM SW検証トリガに関する条件が生じると、DRM SW検証手続きが、その後に続く。両方のタイプの検証手続きは、それぞれのトリガ条件が満たされると、実行されることに留意されたい。しかし、DRM SW検証ステップは、DRMプラットフォーム検証ステップが成功して完了することに追従させられ、すなわち、デバイスとRIの間でDRMプラットフォーム検証が不合格である場合、DRM SW検証におけるさらなる処理、ならびに実際のDRM ROAP処理および使用関連の処理は、失敗する。
【0246】
(密封署名および結び付け)
【0247】
ROAPプロトコルの完全性を保護するOMA DRM2.0仕様の既存の機構は、ROAPメッセージのいくつかに、ただし、すべてにではなく、デジタル署名(またはメッセージ完全性検査)を含めることに限られる。ROAPプロトコルが、セキュリティで保護されたDRM処理実施に中心的な重要性を有することから、ROAPプロトコルにおいて使用され、交換される情報の完全性を保護し、絶えず検証することが重要である。
【0248】
したがって、本発明の代替の実施形態では、DRMデバイスとRIの間の信頼できる認証および完全性検証に中心的な情報が、(1)TCG技術を使用して安全に格納され、さらに(2)他方の側に伝送されるのに先立って、または情報が格納される側において処理のために使用されるのに先立って、事前検証されることが可能である、ROAPプロトコルの完全性を強化する方法が、開示される。
【0249】
この方法には、密封署名(すなわち、ターゲット情報を対称的に暗号化し、次に、対称鍵に加え、プラットフォームまたは特定のSW構成要素のその時点で最新の完全性ステータスを示すPCR値のセットに非対称的に署名する)、および結び付け(秘密解読鍵がTPMなどの、保護されたモジュールの中に保持された鍵を使用して、ターゲット情報を非対称的に暗号化する)というTCG技術を使用する2つの基本的な手続きがかかわる。密封署名は、保護されたPCR値によって示される、デバイスDRMユーザエージェントSWの信頼状態に、非対称暗号化、デジタル署名、および結び付けによってもたらされる最高レベルの情報セキュリティを与える。結び付けは、解読鍵がTPM内部で保護される場合に、非対称暗号化を使用する高いレベルの保護を与える。
【0250】
以下の体系的な原理は、密封署名、および結び付けを使用して、ROAPメッセージの中で使用される情報の機密性と完全性をともに保護して、ROAPプロトコル自体の完全性の強度を間接的に高める。以下の説明において、デバイスとRI(またはこの特定のデバイスを扱うRIの部分)はともに、TPMを備えており、完全なTPM機能をサポートするものと想定される。
【0251】
デバイスとRIはそれぞれ、デバイスまたはRIが存在する信頼されるプラットフォームに、ROAP処理と関係する或る情報を暗号上、結び付け、セキュリティで保護された仕方で格納する2つのストレージ鍵のセットを取っておき、使用することができる。デバイスに関して、これらの鍵は、K_DEV_BIND_AおよびK_DEV_BIND_Bである。RIに関して、これらの鍵は、K_RI_BIND_AおよびK_RI_BIND_Bである。これらの鍵は、TPMによって保持される非対称鍵(すなわち、暗号化は、公開鍵を使用して行われ、解読は、TPM内で保護された秘密鍵を使用して行われる)である。
【0252】
デバイスとRIはそれぞれ、DRM処理のために単一のPCR、またはPCRのセットを使用する。また、デバイスとRIは、AIK(構成証明アイデンティティ鍵)を取っておき、信頼されるプラットフォーム、およびそのプラットフォームの特定のPCR値に、ROAP処理と関係する或る情報を密封署名するのに使用する。TCG AIK鍵は、PCR値に署名するためだけに使用されることに留意されたい。デバイスに関して、デバイスのAIKは、K_DEV_AIKであり、RIに関して、RIのAIKは、K_RI_AIKである。また、密封署名は、ターゲットデータの暗号化操作のための非対称ストレージ鍵を要求する。このため、デバイスとRIはそれぞれ、この目的でストレージ鍵を取っておき、使用する。デバイスに関するストレージ鍵は、K_DEV_STO_SEALであり、RIに関するストレージ鍵は、K_RI_STO_SEALである。
【0253】
この方法は、ROAP処理にかかわる様々な情報要素を格納することの強度を高めるように、密封署名および結び付けと、機密性および完全性を保護する追加の対策との組合せを使用する。例えば、図13は、TPM密封署名操作およびTPM結び付け操作を使用して、4パスROAP登録プロトコルを含む様々なメッセージの中の情報の機密性および完全性が保護される方法1300の流れ図である。方法1300では、デバイス1302とRI1304がそれぞれ、4パス登録プロトコルの過程においてそれぞれが送信する(他方の側に)または受信する(他方の側から)ストレージ鍵の2つのセットを使用して、ROAP関連の情報の選択的なセットに密封署名し、情報を結び付ける。
【0254】
デバイス1302がまず、暗号化鍵K_DEV_STO_SEALおよびデバイス特有のAIK、K_DEV_AIKを使用して、デバイスID情報要素(OMA DRMの場合、OMA DRM公開鍵のSHA−1ハッシュである)に密封署名する。この情報は、ストレージ鍵K_DEV_BIND_Aを使用して、デバイスハローメッセージ向けの他の情報に結び付けられる(非対称暗号化を使用して)(ステップ1310)。次に、このデバイスハローメッセージが、デバイス1302からRI1304に送信される(ステップ1312)。
【0255】
デバイスIDなどの情報に密封署名すること、およびデバイスハローメッセージを含む他の情報を結び付けることにより、デバイス1302は、デバイス1302が、デバイス1302の保護されたストレージから以前に密封署名され、結び付けられた情報を回復し(すなわち、密封署名解除して、結び付け解除し)、それらの情報を、DRM SWが使用している可能性があるような情報要素の現在の値と比較し、これらの現在の値の真正性および完全性を検証すると、その場合に限って、デバイスハローメッセージが伝送されるというポリシーを定めることもできる。このシナリオにおける、密封署名されるべき情報要素対結び付けられるべき情報要素の選択は、例として与えられているに過ぎないことに留意されたい。他の情報要素は、本発明の動作を実行することなしに、様々な組合せで密封署名され、結び付けられることが可能である。他の組合せは、システム時間、メッセージの中の任意の情報要素、アルゴリズム、およびナンスなどのアイテムから導き出されることが可能である。ナンスをセキュリティで保護する1つの理由は、一部の乱数発生器、特に有害な侵害を受けている可能性がある乱数発生器は、同一のパターンを繰り返して、同一の数を乱数発生器の出力として、容認できない短い周期で生成する可能性があるので、ナンスが本当にランダムであるかどうかを判定するためである。
【0256】
RI1304は、デバイスハローメッセージの受信後、RI1304の結び付け鍵、KI_RI_BIND_Aを使用して、デバイスハローメッセージの中に含まれる情報を結び付ける(ステップ1314)。このステップは、RI1304がデバイス1302から受信した鍵情報の、セキュリティで保護された、完全性保護された格納を可能にする。代替として、RI1304は、デバイスハローメッセージからデバイスID(または他の任意の情報要素)を抽出し、AIK、K_RI_AIK、および暗号化鍵K_RI_STO_SEALを別々に使用して、その情報要素に密封署名することもできる。
【0257】
RI1304が、暗号化鍵K_RI_STO_SEALおよびAIK、K_RI_AIKを使用して、RI IDおよびRI URL情報要素に密封署名する(ステップ1316)。また、RI1304は、ストレージ鍵K_RI_BIND_Aを使用して、RI1304のRIハローメッセージの中に含まれるその他の情報を結び付けることも行う(ステップ1316)。次に、RI1304は、RIハローメッセージをデバイス1302に送信する(ステップ1318)。
【0258】
RI1304は、RI1304がまず、保護されたストレージから以前に密封署名され、結び付けられた情報を回復し(すなわち、密封署名解除して、結び付け解除し)、それらの情報を、RI DRM SWが使用している可能性があるような情報要素の現在の値と比較し、これらの現在の値の真正性および完全性を検証すると、その場合に限って、デバイス1302にRIハローメッセージを送信する。
【0259】
デバイス1302は、RIハローメッセージを受信すると、第2の結び付け鍵、すなわち、K_DEV_BIND_Bを使用して、RIハローメッセージの中に含まれる情報を結び付ける(ステップ1320)。このステップは、デバイスがRI1304から受信した鍵情報のセキュリティで保護された、完全性保護された格納を可能にする。代替として、デバイス1302は、受信されたRIハローメッセージから、選択された情報要素(RI IDおよび/またはRI URLなどの)を抽出し、AIK、K_DEV_AIKおよび暗号鍵K_DEV_STO_SEALを使用して、これらの情報要素に密封署名する一方で、K_DEV_BIND_Bを使用して、RIハローメッセージの中で受信された残りの情報を単に結び付けることも可能である。
【0260】
デバイス1302が、K_DEV_AIKおよびK_DEV_STO_SEALを使用して、証明書チェーン、DCFハッシュ、および要求時間に密封署名する(ステップ1322)。次に、デバイス1302は、K_DEV_BIND_Aを使用して、登録要求メッセージ向けのその他の情報を結び付ける(ステップ1322)。次に、デバイス1302は、この登録要求メッセージをRI1304に送信する(ステップ1324)。デバイス1302は、デバイス1302が、以前に密封署名され、結び付けられた情報を回復し(すなわち、密封署名解除して、結び付け解除し)、回復された値を、DRM SWメモリの中で使用される現在の一時的な値と比較し、これらの現在の値の真正性および完全性を検証すると、その場合に限って、この登録要求メッセージを送信する。この登録要求メッセージを受信すると、RI1304は、結び付け鍵、K_RI_BIND_Bを使用して、登録要求メッセージからの情報を結び付ける(ステップ1326)。
【0261】
RI1304が、KI_RI_AIKおよびK_RI_STO_SEALを使用して、鍵、証明書チェーン、およびROに密封署名する(ステップ1328)。次に、RI1304は、密封署名された鍵、証明書チェーン、およびROを、結び付け鍵K_RI_BIND_Aを使用して、登録応答メッセージに含められるべき他の情報に結び付ける(ステップ1328)。次に、RI1304は、この登録応答メッセージをデバイス1302に送信する(ステップ1330)。RI1304は、RIが、以前に密封署名され、結び付けられた情報を回復し(すなわち、密封署名解除して、結び付け解除し)、これらの回復された値を、DRM SWメモリの中で使用される現在の一時的な値と比較し、これらの現在の値の真正性および完全性を検証した場合に限って、この登録応答メッセージを送信する。登録応答メッセージを受信すると、デバイス1302は、登録応答メッセージからのRIによって生成された情報を、結び付け鍵K_DEV_BIND_Bを使用して結び付ける(ステップ1332)。
【0262】
この密封署名および結び付けは、他の任意のROAPプロトコルで使用されることが可能であることに留意されたい。前述した方法1300は、例示的であり、方法1300の原理は、他の任意のROAPプロトコルにも等しく適用されることが可能である。
【0263】
OMA DRM ROAPメッセージ交換中に獲得されたデータは、このデータを密封した、またはこのデータに密封署名したエンティティが、そのエンティティのOSまたはDRM SWを更新した場合、密封解除され、新たな構成PCR値に再密封される必要がある。そのような事態が生じると、或る特定の状態(または、均等なこととして、或る特定のPCR値セット)に密封されていた、または密封署名されていたDRM ROAP関連のデータが、最初に、密封解除され、次に、更新されたプラットフォームOSの最新の状態に再密封されなければならない。この手続き要件に対処する既存の技術が、従来技術に存在し、そのような手続きは、本明細書で提案される密封または密封署名を使用して格納された任意のDRM ROAP関連のデータの適切な密封解除および再密封を確実にするように行われるものと想定される。
【0264】
1つのさらなる機能強化は、送信するデバイスのTCG能力を示すフィールドを、既存のROAPメッセージフォーマットに追加することである。このTCG能力フィールドは、受信するエンティティが、TCG関連の情報および手続きをサポートすることができるかどうかの早期判定を行うことによって、レガシーデバイスとの相互運用性を高めることに役立つことが可能である。
【0265】
(デバイスハローメッセージの変更、およびこの変更の導出)
【0266】
第1の変更は、デバイスのTPC能力の標識である、新たなDTCI(デバイスTPM能力指示)を、デバイスハローメッセージの既存の拡張子パラメータの新たな要素の中に追加すること、または代替として、好ましくは、このDCTIを、デバイスハローメッセージのヘッダの中の新たな第1のパラメータとして追加することである。DTCIは、1ビット(デバイスTPMの欠如、または存在を示す)、または数ビット(デバイスのTPM能力に関して、より細分性の高い情報を示す)であることが可能である。DTCIは、新たなパラメータとして挿入される場合、好ましくは、デバイスIDパラメータより前に、最初のパラメータとして挿入されて、他のパラメータに先立って、デバイスがいくつかのTPC能力を有することをRIが知り、DTCIを利用して、後のパラメータ(例えば、デバイスID)からの情報を処理することができるようにされなければならない。DTCI情報の利点は、この情報により、RIが、ROAPプロトコルの残りの部分におけるデバイスとのさらなる対話において、デバイスの信頼性を評価することが可能になることである。
【0267】
第2の変更は、デバイス特有のTCG EK資格証明またはTCG AIK資格証明を使用して、DRMデバイスIDをハッシングし、導き出すことである。この変更の利点は、EK資格証明および/またはAIK資格証明が、デバイス内のTPMによって強固に保護されており、このため、これらの資格証明のいずれかからDRMデバイスIDを導き出すことにより、DRMデバイスID情報の完全性が強化されることである。
【0268】
第3の変更は、署名までの、署名を除くデバイスハローメッセージに、RIによって検証されることが意図される、デバイスのAIK秘密鍵を使用して署名が行われる場合に、新たな署名パラメータを追加することである。この変更の利点は、デバイスとRIの間の最初の対話から、デバイスTPM能力の完全性を保護することである。TPMによって強固に保護される、デバイスのAIK秘密鍵の使用により、署名動作の完全性が強化される。
【0269】
テーブル12および13は、変更されたデバイスハローメッセージに関する可能な2つのフォーマットを示す。テーブル12は、最初のパラメータとしてDTCIビットを有するメッセージのフォーマットを示す。テーブル13は、DTCIが、既存の拡張子パラメータの新たな要素である、デバイスハローメッセージのフォーマットを示す。
【0270】
【表12】
【0271】
【表13】
【0272】
(RIハローメッセージの変更、およびこの変更の導出)
【0273】
第1の変更は、RIのTPM能力の標識である新たなRTCI(RI TPM能力指示)を、RIハローメッセージの既存の拡張子パラメータの新たな要素として追加すること、または代替として、好ましくは、このRTCIを、RIハローメッセージのヘッダの中の新たな第1のパラメータとして追加することである。この変更の利点は、この変更により、デバイスが、RTCI情報を使用して、RIの信頼性を評価し、さらに、ROAPプロトコル手続きの残りの部分におけるRIとのさらなる対話において、そのような情報を利用することが可能になることである。
【0274】
第2の変更は、RI TPMを使用して、セッションIDを表す擬似乱数を提供することである。この変更の利点は、TPMが、セキュリティで強固に保護されたハードウェアベースの擬似乱数発生器を提供することである。TPMを使用して、セッションIDとして使用される擬似乱数を生成することにより、プロトコルのセキュリティが強化される。
【0275】
第3の変更は、RI TCG EK資格証明、またはRIのTPMに属するTCG AIK資格証明を使用して、RI IDを導き出すことである。この変更の利点は、EK資格証明および/またはAIK資格証明が、デバイス内のTPMによって強固に保護され、これらの資格証明のいずれかからDRMデバイスIDを導き出すことにより、DRMデバイスID情報の完全性が強化されることである。
【0276】
第4の変更は、RI TPMを使用して、RIナンスを提供することである。この変更の利点は、TPMが、セキュリティで強固に保護されたハードウェアベースの擬似乱数発生器を提供することである。TPMを使用して、RIナンスを生成することにより、RIハローメッセージの中で使用されるナンスの完全性が強化される。
【0277】
第5の変更は、デバイスによって信頼されるRIアンカの中にデバイスTCG資格証明を含めることである。デバイスのTCG資格証明には、EK資格証明、AIK資格証明、プラットフォーム資格証明、ならびにRIが、信頼されるTCG CAから事前獲得した準拠資格証明が含まれる。この変更の利点は、デバイスがRIハローメッセージに対して有することが可能な信頼を強化することである。
【0278】
第6の変更は、RIのAIK公開鍵が、RIハローメッセージの一部としてデバイスにあらかじめ配布されている場合に、RIのAIK秘密鍵を使用して署名された、署名までの、署名を除くRIハローメッセージの署名を追加することである。この変更の利点は、RIとデバイスの間の最初の対話から、RTCIの完全性を保護することである。RIのTPMによって強固なセキュリティで保護されたRIのAIK秘密鍵を使用することにより、署名動作の完全性が強化される。
【0279】
テーブル14および15は、変更されたRIハローメッセージに関する可能な2つのフォーマットを示す。テーブル14は、最初のパラメータとしてRTCIビットを有するRIハローメッセージのフォーマットを示す。テーブル15は、RTCIが、既存の拡張子パラメータの新たな要素である場合の、RIハローメッセージのフォーマットを示す。
【0280】
【表14】
【0281】
【表15】
【0282】
(登録要求メッセージの変更、およびこの変更の導出)
【0283】
第1の変更は、デバイスTPMを使用して、デバイスナンスを提供することである。この変更の利点は、TPMが、ナンスに使用するのに適したセキュリティで保護された、信頼できる擬似乱数を提供することである。
【0284】
第2の変更は、デバイスTCG資格証明を証明書チェーンの中に含めることである。デバイスTCG資格証明を含めることは、既存のOMA DRM2.0デバイス資格証明の代わりであること、または既存のOMA DRM2.0デバイス資格証明に加えてであることが可能である。TCG資格証明(EK資格証明、AIK資格証明、プラットフォーム資格証明、または準拠資格証明)を含めることの利点は、デバイスの信頼性を高めることである。
【0285】
第3の変更は、RIによって信頼されるTCG CAのリストを、信頼RIアンカ要素の中に含めることである。RIによって信頼されるTCG CAを含めることは、既存のOMA DRM2.0 RI信頼アンカ要素リストの代わりであること、または既存のOMA DRM2.0 RI信頼アンカ要素リストに加えてであることが可能である。RIによって信頼されるTCG CAのリストを含めることの利点は、デバイスの信頼性を高めることである。
【0286】
第4の変更は、デバイスTPMについての情報を、拡張子パラメータのデバイス詳細要素の中に含めることである。この情報を含めることの利点は、RIに対するデバイスについての信頼性を高めることである。
【0287】
第5の変更は、変更されたデバイスハローメッセージに署名するのに使用されたデバイスAIKを使用して署名に署名することである。この変更の利点は、デバイスAIKの強固に保護された性質のため、デバイス、および登録要求メッセージの信頼性を高めることである。
【0288】
テーブル16は、変更された登録要求メッセージに関するフォーマットを示す。
【0289】
【表16】
【0290】
(登録応答メッセージの変更、およびこの変更の導出)
【0291】
第1の変更は、RI TPMを使用して、セッションIDを表す擬似乱数を提供することである。この変更の利点は、TPMが、セキュリティで強固に保護されたハードウェアベースの擬似乱数発生器を提供することである。TPMを使用して、セッションIDとして使用される擬似乱数を生成することにより、プロトコルのセキュリティが強化される。
【0292】
第2の変更は、RI TCG EK資格証明、またはRIのTPMに属するTCG AIK資格証明を使用して、RI IDを導き出すことである。この変更の利点は、EK資格証明および/またはAIK資格証明が、デバイス内のTPMによって強固に保護され、これらの資格証明のいずれかからDRMデバイスIDを導き出すことにより、DRMデバイスID情報の完全性が強化されることである。
【0293】
第3の変更は、RI TPMを使用して、RIナンスを提供することである。この変更の利点は、RI TPMが、ナンスとして使用するのに適したセキュリティで保護された、信頼できる擬似乱数を提供することである。
【0294】
第4の変更は、デバイスによって信頼されるTCG CAのリストを、信頼されるデバイスアンカ要素の中に含めることである。デバイスによって信頼されるTCG CAを含めることは、既存のOMA DRM2.0信頼デバイスアンカ要素リストの代わりであること、または既存のOMA DRM2.0信頼デバイスアンカ要素リストに加えてであることが可能である。デバイスによって信頼されるTCG CAのリストを含めることの利点は、RIの信頼性を高めることである。
【0295】
第5の変更は、変更されたRIハローメッセージに署名するのに使用されたRI AIKを使用して署名に署名することである。この変更の利点は、RI AIKの強固に保護された性質のため、RI、および登録応答メッセージの信頼性を高めることである。
【0296】
テーブル17は、変更された登録応答メッセージに関するフォーマットを示す。
【0297】
【表17】
【0298】
(RO要求メッセージの変更、およびこの変更の導出)
【0299】
第1の変更は、TPMを使用して、デバイスIDとして使用すべき、選択されたTCG資格証明(EK資格証明、AIK資格証明、プラットフォーム資格証明、または準拠資格証明)のSHA−1ハッシュを作成する。この変更の利点は、資格証明が、TPMによって強固に保護され、このため、これらの資格証明のいずれかからデバイスIDを導き出すことにより、デバイスID情報の完全性が強化されることである。
【0300】
第2の変更は、デバイスTPMを使用して、デバイスナンスを生成することである。この変更の利点は、TPMによって生成されるナンスが、TPMの保護された擬似乱数発生能力のために、セキュリティで保護されていることである。
【0301】
第3の変更は、TCG資格証明を証明書チェーンの中に含めることである。TCG資格証明を含めることは、既存のOMA DRM2.0デバイス資格証明の代わりであること、または既存のOMA DRM2.0デバイス資格証明に加えてであることが可能である。TCG資格証明を含めることの利点は、デバイスの信頼性を高めることである。
【0302】
第4の変更は、拡張子パラメータの中のデバイスAIKを使用して、オプションのDCFハッシュに署名することである。この変更の利点は、デバイスAIKが強固に保護されており、DCF署名が、より強固なセキュリティで保護されるようにすることである。
【0303】
第5の変更は、正常に応答があった最新の登録要求メッセージに署名するのに使用されたデバイスAIKを使用して、RO要求メッセージに署名することである。この変更の利点は、RI AIKの強固に保護された性質のため、RI、およびRO要求メッセージの信頼性を高めることである。
【0304】
テーブル18は、変更されたRO要求メッセージのフォーマットを示す。
【0305】
【表18】
【0306】
(RO応答メッセージの変更、およびこの変更の導出)
【0307】
1つの変更は、RIのTPMを使用して、成功した最新の登録応答メッセージに署名する際に使用されたのと同一のRI TPM AIKを使用して、RO応答メッセージに署名することである。この変更の利点は、RI AIKの強固に保護された性質のため、RI、およびRO応答メッセージの信頼性を高めることである。
【0308】
テーブル19は、変更されたRO要求メッセージのフォーマットを示す。
【0309】
【表19】
【0310】
本発明の特徴および要素は、特定の組合せで、好ましい実施形態において説明されるものの、各フィーチャ、または各要素は、単独で(好ましい実施形態のその他のフィーチャ、およびその他の要素なしに)、あるいは本発明の他のフィーチャ、および他の要素を伴って、または伴わずに様々な組合せで使用されることが可能である。
【0311】
(実施形態)
【0312】
1.RE(要求するエンティティ)と、TE(ターゲットエンティティ)との間でプラットフォーム完全性検査を実行するための方法であって、TEのTCG(Trusted Computing Group)資格証明を報告するようTEに要求する要求を、REからTEに送信するステップと、TEからREにTEのTCG資格証明を送信するステップと、TEのTCG資格証明を、検証のために、REからOCSP(オンライン証明書ステータスプロトコル)レスポンダに転送するステップと、TEのTCG資格証明の検証ステータスを、OCSPレスポンダからREに報告するステップと、TE自らのプラットフォーム完全性ステータスを報告するようTEに要求する要求を、REからTEに送信するステップと、TEのプラットフォーム完全性ステータスを検査するステップと、TEからREにプラットフォーム完全性ステータス標識を送信するステップとを含む方法。
【0313】
2.REは、RI(権利発行者)であり、TEは、デバイスである実施形態1による方法。
【0314】
3.デバイスが、方法を開始するトリガをRIに送信することによって、デバイスが、RIを相手にROAP(権利オブジェクト獲得プロトコル)登録プロトコルを開始するのに先立って実行される実施形態2による方法。
【0315】
4.デバイスが、RIに最も新しく登録してから経過した時間に基づいて、定期的に実行される実施形態2または3による方法。
【0316】
5.デバイスが、デバイスのプラットフォーム完全性ステータスをRIに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態2から4のいずれかによる方法。
【0317】
6.REは、デバイスであり、TEは、RI(権利発行者)である実施形態1による方法。
【0318】
7.RIが、RIのプラットフォーム完全性ステータスをデバイスに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態6による方法。
【0319】
8.REは、CI(コンテンツ発行者)であり、TEは、デバイスである実施形態1による方法。
【0320】
9.デバイスが、デバイスのプラットフォーム完全性ステータスをCIに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態8による方法。
【0321】
10.デバイスが、CIからコンテンツを購入すると、実行される実施形態8または9による方法。
【0322】
11.REは、デバイスであり、TEは、CI(コンテンツ発行者)である実施形態1による方法。
【0323】
12.CIが、CIのプラットフォーム完全性ステータスをデバイスに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態11による方法。
【0324】
13.デバイスが、CIからコンテンツを購入すると、実行される実施形態11または12による方法。
【0325】
14.ROAP(権利オブジェクト獲得プロトコル)プロセスの一環として実行される実施形態1による方法。
【0326】
15.ROAPプロセスに先立って実行される実施形態14による方法。
【0327】
16.ROAPプロセスは、ROAPプロセスの一環として方法を組み込むように変更される実施形態14または15による方法。
【0328】
17.RE(要求するエンティティ)と、TE(ターゲットエンティティ)との間でDRM(デジタル権利管理)ソフトウェア完全性検査を実行するための方法であって、TEがDRMソフトウェア完全性検査を実行することを要求する要求を、REからTEに送信するステップと、TEによってDRMソフトウェア完全性を検査するステップと、TEからREにDRMソフトウェア完全性ステータス標識を送信するステップとを含む方法。
【0329】
18.REは、RI(権利発行者)であり、TEは、デバイスである実施形態17による方法。
【0330】
19.デバイスは、デバイスが、ROAP(権利オブジェクト獲得プロトコル)プロセスを開始するのに先立って、方法を開始するトリガをRIに送信する実施形態18による方法。
【0331】
20.ROAPプロセスは、2パス登録、2パスドメイン参加、および2パスドメイン退去から成るグループから選択される実施形態19による方法。
【0332】
21.デバイスが、RIを相手にROAP(権利オブジェクト獲得プロトコル)プロセスを完了した後、定期的に実行される実施形態19または20による方法。
【0333】
22.ROAPプロセスは、2パス登録、2パスドメイン参加、および2パスドメイン退去から成るグループから選択される実施形態19から21のいずれかによる方法。
【0334】
23.デバイスが、デバイスのDRMソフトウェア完全性ステータスをRIに検証し、報告した後、定期的に実行される実施形態18から22のいずれかによる方法。
【0335】
24.デバイスが、デバイスのDRMソフトウェアを更新した後、実行される実施形態18から23のいずれかによる方法。
【0336】
25.RIは、デバイス上のメディアプレーヤに対してDRMソフトウェア完全性検査を実行するよう、デバイスに要求する実施形態18から24のいずれかによる方法。
【0337】
26.REは、デバイスであり、TEは、RI(権利発行者)である実施形態17による方法。
【0338】
27.デバイスによって開始されると、実行される実施形態26による方法。
【0339】
28.スタンドアロンのプロセスである実施形態26または27による方法。
【0340】
29.変更された権利オブジェクト獲得プロトコルプロセスの一環である実施形態26から28のいずれかによる方法。
【0341】
30.RIが、RIのDRMソフトウェア完全性ステータスをデバイスに検証し、報告した後、定期的に実行される実施形態26から29のいずれかによる方法。
【0342】
31.RIが、RIのDRMソフトウェアを更新した後、実行される実施形態26から30のいずれかによる方法。
【0343】
32.デバイスが、RIに権利オブジェクト要求を送信するのに先立って実行される実施形態26から31のいずれかによる方法。
【0344】
33.ストリーミングコンテンツを求めるデバイスからRIへの要求中に、定期的に実行される実施形態26から32のいずれかによる方法。
【0345】
34.REは、CI(コンテンツ発行者)であり、TEは、デバイスである実施形態17による方法。
【0346】
35.デバイスは、デバイスが、ROAP(権利オブジェクト獲得プロトコル)プロセスを開始するのに先立って、方法を開始するトリガをCIに送信する実施形態34による方法。
【0347】
36.デバイスが、CIを相手にROAP(権利オブジェクト獲得プロトコル)プロセスを完了した後、定期的に実行される実施形態34または35による方法。
【0348】
37.デバイスが、デバイスのDRMソフトウェア完全性ステータスをCIに検証し、報告した後、定期的に実行される実施形態34から36のいずれかによる方法。
【0349】
38.デバイスが、デバイスのDRMソフトウェアを更新した後、実行される実施形態34から37のいずれかによる方法。
【0350】
39.CIは、デバイス上のメディアプレーヤに対してDRMソフトウェア完全性検査を実行するよう、デバイスに要求する実施形態34から38のいずれかによる方法。
【0351】
40.REは、デバイスであり、TEは、CI(コンテンツ発行者)である実施形態17による方法。
【0352】
41.デバイスによって開始されると、実行される実施形態40による方法。
【0353】
42.スタンドアロンのプロセスである実施形態40または41による方法。
【0354】
43.変更された権利オブジェクト獲得プロトコルプロセスの一環である実施形態40から42のいずれかによる方法。
【0355】
44.CIが、CIのDRMソフトウェア完全性ステータスをデバイスに検証し、報告した後、定期的に実行される実施形態40から43のいずれかによる方法。
【0356】
45.CIが、CIのDRMソフトウェアを更新した後、実行される実施形態40から44のいずれかによる方法。
【0357】
46.デバイスが、権利オブジェクト要求をCIに送信するのに先立って実行される実施形態40から45のいずれかによる方法。
【0358】
47.ストリーミングコンテンツを求めるデバイスからCIへの要求中に、定期的に実行される実施形態40から46のいずれかによる方法。
【0359】
48.2つのエンティティ間で交換されるROAP(権利オブジェクト獲得プロトコル)メッセージの完全性を強化するための方法であって、信頼されるコンピューティング技術を使用して各エンティティにおいて、ROAPメッセージの中で使用されるべき情報を安全に格納するステップと、ROAPメッセージに関連して使用されるのに先立って、ROAPメッセージの中で使用されるべき情報を事前検証するステップとを含む方法。
【0360】
49.格納するステップは、情報に密封署名すること、および情報を結び付けることを含む実施形態48による方法。
【0361】
50.密封署名するステップは、対称暗号化鍵を使用して情報を対称的に暗号化すること、およびこの対称暗号化鍵、およびオブジェクトの現在の完全性ステータスを示す値のセットに非対称的に署名することを含む実施形態49による方法。
【0362】
51.署名するステップは、エンティティが動作するプラットフォームの完全性ステータスを使用することを含む実施形態50による方法。
【0363】
52.署名するステップは、エンティティのソフトウェア構成要素の完全性ステータスを使用することを含む実施形態50または51による方法。
【0364】
53.結び付けるステップは、秘密解読鍵がエンティティ内の保護されたモジュールの中に格納された鍵を使用して、情報を非対称的に暗号化することを含む実施形態49から52のいずれかによる方法。
【0365】
54.保護されたモジュールは、TPM(信頼される処理モジュール)である実施形態53による方法。
【0366】
55.TPMは、ROAPメッセージの中で使用すべきパラメータを導き出すのに使用される実施形態54による方法。
【0367】
56.情報は、デバイスID、権利発行者ID、証明書、証明書チェーン、デジタル権利管理関連の時間値、権利オブジェクト、アルゴリズム、およびナンスから成るグループから選択される実施形態48から55のいずれかによる方法。
【0368】
57.すべてのROAPメッセージに適用される実施形態48から56のいずれかによる方法。
【0369】
58.ROAPメッセージとは別個に適用される実施形態48から56のいずれかによる方法。
【0370】
59.ROAPメッセージの生成および伝送に組み込まれる実施形態48から56のいずれかによる方法。
【0371】
60.送信するエンティティの信頼されるコンピューティング能力を示すフィールドを、既存のROAPメッセージに追加するステップをさらに含む実施形態48から56のいずれかによる方法。
【0372】
61.実施形態1から60のいずれかによる方法を実行するように構成されたシステム。
【0373】
62.実施形態1から60のいずれかによる方法を実行するように構成された集積回路。
【技術分野】
【0001】
本発明は、一般に、無線通信ネットワークにおけるDRM(デジタル権利管理)方法に関する。より詳細には、本発明は、OMA(Open Mobile Alliance)DRM仕様に準拠して動作するシステムにおいてセキュリティ、完全性、および信頼性を強化するための方法を提供する。
【背景技術】
【0002】
OMA DRMは、移動電話機および移動デバイスの製造業者、ならびにモバイルサービスプロバイダのコンソーシアムであるOMAによって指定されるDRMシステムである。このスキームは、多くの移動電話機上で実施され、モバイルコンテンツプロバイダによって、プロバイダの製品およびサービスにDRMを追加するのに使用されることが意図される。OMA DRMの2つのバージョン、すなわち、OMA DRM1.0およびOMA DRM2.0が、公開されている。
【0003】
OMA DRM1.0は、コンテンツオブジェクトに関するデジタル権利の基本的管理に関するスキームを扱う。このため、OMA DRM1.0は、コンテンツオブジェクトに関しても、権利オブジェクトに関しても強力な保護は提供しなかった。OMA DRM1.0は、3つの配信方法、すなわち、転送ロック(ユーザが、コンテンツを他のユーザ、または他のデバイスに転送するのを防止する)、組み合わされた配信(組み合わされた権利オブジェクトとメディアオブジェクト)、および分離した配信(分離した権利オブジェクトとメディアオブジェクト)を規定する。OMA DRM1.0は、電話機に関する呼び出し音または壁紙などの小さいサイズのメディアオブジェクトを扱うように設計された。
【0004】
OMA DRM2.0は、OMA DRM1.0配信機構を改良し、拡張する。OMA DRM2.0に準拠するデバイスは、DRM PKI(公開鍵インフラストラクチャ)に基づく個別の証明書を有し、すなわち、各デバイスは、公開鍵、対応する秘密鍵を有するとともに、この事実を検証する証明書を有する。各RO(権利オブジェクト)は、機密性(暗号化によって)と完全性(デジタル署名によって)の両方に関して保護される。PKI、暗号化、および完全性検査の使用が、OMA DRM1.0システムのセキュリティと比べて、OMA DRM2.0システムのセキュリティを強化する。
【0005】
また、OMA DRM2.0は、デバイスとRI(権利発行者)との間の相互認証および相互登録、ROを要求すること、ROの配信に対する応答、またはROを配信することの拒否、ならびにデバイスがドメインに参加すること、およびドメインを退去することと関係する様々なサブプロトコルを含むROAP(権利オブジェクト獲得プロトコル)とまとめて呼ばれるプロトコルのセットも規定する。
【0006】
以下は、OMA DRMにおいて定義される主なエンティティのいくつかである。すなわち、
【0007】
アクタ アクタは、使用事例を実行する外部エンティティである。
【0008】
バックアップ/リモートストレージ ROおよびCO(コンテンツオブジェクト)を、元のデバイスに送り返すことを意図して、別のロケーションに転送すること。
【0009】
組み合わされた配信 保護されたコンテンツおよびROを配信するためのOMA DRM1.0メソッド。ROおよび保護されたコンテンツは、DRMメッセージという単一のエンティティの中で一緒に配信される。
【0010】
機密性 情報が、許可のない個人、エンティティ、またはプロセスに提供されない、または開示されないという特性。
【0011】
合成オブジェクト 包含によって1つまたは複数のメディアオブジェクトを含むCO。
【0012】
接続されたデバイス 適切なワイドエリアトランスポート/ネットワーク層インタフェースを介して、適切なプロトコルを使用してRIに直接に接続することができるデバイス。
【0013】
コンテンツ 1つまたは複数のメディアオブジェクト
【0014】
CI(コンテンツ発行者) DRMエージェントにコンテンツを提供するエンティティ。
【0015】
コンテンツプロバイダ CIまたはRIであるエンティティ。
【0016】
デバイス DRMエージェントを有するユーザ機器。デバイスは、接続されたデバイスであることも、接続されていないデバイスであることも可能であるが、この区別は、接続されたデバイスが、RIに直接に接続する能力を失うと、接続されていないデバイスになる可能性があるので、コンテキスト依存であり、性質が不定である。
【0017】
デバイス取り消し 或るデバイスがROを獲得することが、もはや信頼されないことをRIが示すプロセス。
【0018】
デバイスRO 或る特定のデバイスに、そのデバイスの公開鍵によって専用とされるRO。
【0019】
ドメイン ドメインROを共有することができるデバイスのセット。ドメイン内のデバイスは、ドメイン鍵を共有する。ドメインは、RIによって定義され、管理される。
【0020】
ドメイン識別子 ドメイン鍵の一意ストリング識別子。
【0021】
ドメイン鍵 128ビットの対称暗号鍵
【0022】
DRMエージェント デバイス上のメディアオブジェクトに関する許可を管理するデバイス内のエンティティ。
【0023】
DRMコンテンツ ROの中の許可セットに従って消費されるメディアオブジェクト。
【0024】
DRM時間 セキュリティで保護された、ユーザが変更できない時間源。DRM時間は、UTC時間フォーマットになっている。
【0025】
完全性 データが、許可のない仕方で変更、または破壊されていないという特性。
【0026】
ドメインに参加する RIが、デバイスをドメインに含めるプロセス。
【0027】
ドメインを退去する(参加解消する)RIが、取り消されていないデバイスをドメインから除外するプロセス。
【0028】
メディアオブジェクト デジタル作品または合成オブジェクト。
【0029】
ネットワークサービスプロバイダ 移動デバイスにネットワーク接続を提供するエンティティ。
【0030】
許可 DRMコンテンツに対してRIによって許される実際の使用または活動。
【0031】
再生する リソースの一過性の知覚可能な表現を作成すること。
【0032】
保護されたコンテンツ ROの中の許可セットに従って消費されるメディアオブジェクト。
【0033】
復元する 保護されたコンテンツおよび/またはROを外部ロケーションから、保護されたコンテンツおよび/またはROのバックアップの源とされたデバイスに送り返すこと。
【0034】
取り消す デバイスまたはRI証明書を無効と宣言するプロセス。
【0035】
RI(権利発行者) OMA DRMに準拠するデバイスにROを発行するエンティティ。
【0036】
RIコンテキスト RI ID、RI証明書チェーン、バージョン、アルゴリズム、およびその他の情報などの、4パス登録プロトコル中に所与のRIを相手にネゴシエートされた情報。RIコンテキストは、デバイスが、登録プロトコルを除いて、ROAPスイートのすべてのプロトコルに参加することに成功するのに必要である。
【0037】
RO(権利オブジェクト) 保護されたコンテンツにリンクされた許可およびその他の属性の集合。
【0038】
ROAP(権利オブジェクト獲得プロトコル) デバイスが、RIからROを要求し、獲得することを可能にするプロトコル。
【0039】
ROAPトリガ デバイスによって受信されると、ROAPを開始するURLを含むXML(拡張マークアップ言語)ドキュメント。
【0040】
状態のない権利 デバイスが状態情報を保持しなくてもよいRO。
【0041】
状態のある権利 デバイスが、状態情報を明示的に保持して、ROの中で表現される制約および許可が、正しく実施されることが可能であるようにしなければならないRO。以下の制約または許可のいずれかを含むROが、状態のある権利である。すなわち、<interval>、<count>、<timed−count>、<datetime>、<accumulated>、または<export>である。
【0042】
スーパ配布 (1)セキュリティで保護されていない可能性があるチャネルを介して、ユーザが保護されたコンテンツを他のデバイスに配布することを許し、さらに、そのデバイスのユーザが、スーパ配布された保護されたコンテンツに関するROを獲得することを可能にする機構。
【0043】
接続されていないデバイス ローカル接続技術を介する適切なプロトコル、例えば、OBEX over IrDA(object exchange over infrared)、Bluetooth、またはUSB(ユニバーサルシリアルバス)を使用して、接続されたデバイス経由でRIに接続することができるデバイス。
【0044】
ユーザ デバイスの人間ユーザ。ユーザは、デバイスを必ずしも所有しない。
【0045】
図1は、既存のOMA DRM2.0機能アーキテクチャ100の概略図である。アーキテクチャ100は、DRMシステム102、コンテンツプロバイダ104、およびユーザ106から成る。DRMシステム102は、CI110、RI112、DRMエージェント114、ネットワークストア116、およびリムーバブルメディア118を含む。CI110は、保護されたコンテンツ122を配布し、RI112は、RO124を配布する。DRMエージェント114は、保護されたコンテンツ122を再配布する。
【0046】
CI110は、DRMコンテンツ122を配信するエンティティである。OMA DRMは、DRMエージェント114に配信されるべきDRMコンテンツ122のフォーマット、ならびにDRMコンテンツ122が、様々なトランスポート機構を使用してCI110からDRMエージェント114にトランスポートされることが可能な仕方を定義する。CI110は、DRMコンテンツ122の実際のパッケージ化を自ら行っても、他の何らかの源からあらかじめパッケージ化されたコンテンツを受信してもよい。
【0047】
RI112は、DRMコンテンツ122に許可および制約を割り当て、RO124を生成するエンティティである。RO124は、DRMコンテンツ122に関連する許可および制約を表現するXMLドキュメントである。RO124は、DRMコンテンツ122がどのように使用されることが可能であるかを支配し、つまり、DRMコンテンツ122は、関連付けられたRO124なしに使用されることが可能でなく、関連付けられたROによって指定されるとおりにしか使用されることが可能でない。DRMコンテンツは、例えば、ROが、時間有効期限(例えば、10日)を有し、この時間有効期限の後、このコンテンツにアクセスするのに新たなROが必要とされる場合、複数のROに関連付けられることも可能である。
【0048】
DRMエージェント114は、DRMコンテンツ122の消費時点の執行を管理することを担う論理的エンティティである。DRMエージェント114は、デバイスの信頼される構成要素を実体化し、デバイス上のDRMコンテンツ122に関する許可および制約を執行すること、デバイス上のDRMコンテンツ(DRMエージェントを介してしかアクセスすることができない)へのアクセスを制御することなどを担う。
【0049】
DRMコンテンツ122は、配信される前に、許可のないアクセスからコンテンツ122を保護するようにパッケージ化される。CI110が、DRMコンテンツ122を配信し、RI122が、RO124を生成する。CI110およびRI112は、システム102において、物理的エンティティではなく、論理的役割を実体化する。例えば、1つの展開において、コンテンツ所有者が、DRMコンテンツをあらかじめパッケージ化し、その後、このコンテンツが、CIとRIの両方の役割をするコンテンツ配給元によって配布される。
【0050】
RO124が、DRMコンテンツ122がどのように使用されることが可能であるかを支配する。DRMコンテンツ122は、関連付けられたRO124なしに使用されることが可能でなく、RO124の中で指定される許可および制約に従ってしか使用されることが可能でない。OMA DRMは、ROからのDRMコンテンツの論理的分離を行う。DRMコンテンツとROは、別々に要求されても、一緒に要求されてもよく、別々に配信されても、同時に配信されてもよい。DRMコンテンツとROは、同時に配信される場合、通常、ともに、CI110によって提供され、ROおよびコンテンツは、DCF(DRMコンテンツフォーマット)に埋め込まれる。
【0051】
RO124は、鍵のセットによって、或る特定のDRMエージェント114に暗号上、結び付けられて、その特定のDRMエージェント114だけが、RO124にアクセスすることができるようにされる。DRMコンテンツ122は、有効なRO124を使用してしかアクセスすることができず、したがって、コンテンツ122は、自由に配布される、またはスーパ配布されることが可能である。
【0052】
OMA DRM2.0は、1つのROが、DRMエージェントのグループに結び付けられることを許す。そのようなグループは、ドメインと呼ばれる。或るドメインに配布されたDRMコンテンツおよびROは、そのドメインに属するすべてのDRMエージェントによってオフラインで共有され、アクセスされることが可能である。例えば、ユーザは、ユーザの電話機とユーザのPDAの両方で使用するためにDRMコンテンツを購入することができる。
【0053】
OMA DRM仕様は、DRMコンテンツのためのフォーマットおよび保護機構(つまり、DCF)、ROのためのフォーマット(REL(権利表現言語))および保護機構、暗号鍵の管理のためのセキュリティモデルを定義する。また、OMA DRM仕様は、DRMコンテンツおよびROが、プル(HTTPプル、OMAダウンロード)、プッシュ(WAPプッシュ、MMS)、およびストリーミングを含む一連のトランスポート機構を使用して、どのようにデバイスにトランスポートされることが可能であるかも定義する。しかし、OMA DRM仕様は、ネットワークエンティティ間、例えば、CI110とRI112の間の対話を全く扱わない。
【0054】
以下は、OMA DRM2.0仕様が範囲に含む使用事例の網羅的ではないリストである。
【0055】
1.基本プルモデル
【0056】
ユーザは、Webサイトにブラウズして行くことによって、ダウンロードすべきコンテンツを選択し、購入の条件を確認する。CI110は、コンテンツ122を識別し、保護する、すなわち、コンテンツ122をパッケージ化する。コンテンツ122は、CEK(コンテンツ暗号化鍵)を使用して暗号化される。デバイス能力が、公示されたMIMEタイプサポートなどを使用して検出されることが可能である。RI112が、コンテンツ122およびターゲットDRMエージェント114に関するRO124を生成する。RO124は、コンテンツトランザクションに関する許可、およびCEKを含む。最期に、RO124は、暗号化(RO暗号化鍵、つまり、REKを使用する)およびデジタル署名によって暗号で保護され、ターゲットDRMエージェント114だけに結び付けられる。次に、DRMコンテンツ122および保護されたRO124が、DRMエージェント114に配信される。
【0057】
2.DRMコンテンツのプッシュ
【0058】
代替の配布モデルは、先行する発見プロセスなしに、MMS(マルチメディアメッセージングサービス)、WAPプッシュ、または類似した方法を使用して、デバイスにコンテンツを直接にプッシュすることである。この使用事例の2つの変種が存在する。
【0059】
2A.コンテンツプッシュ
【0060】
CI110および/またはRI112は、或るユーザ、および或る特定のDRMエージェント114のいくらかの事前の知識を有することが可能であり、したがって、コンテンツ122およびRO124は、配信のためにフォーマットされ、パッケージ化されることが可能である。
【0061】
2B.プッシュによって開始されるプル
【0062】
この場合、CI110および/またはRI112は、ユーザ、またはユーザのDRMエージェント114についての事前の知識を全く有さないことが可能であるが、それでも、例えば、ユーザが、コンテンツを購入するようにユーザの気を引くコンテンツ122をプレビューすることを可能にするように、コンテンツを配信することを望む可能性がある。DRMコンテンツ122をユーザに直接にプッシュする代わりに、このコンテンツへのリンク、またはこのコンテンツのプレビューへのリンクが、送信されることが可能である。このリンクをたどることにより、ユーザは、或る特定のロケーションに連れて行かれ、その後、手続きは、基本プルモデルにおけるとおりに進む。
【0063】
3.DRMコンテンツのストリーミング
【0064】
基本プル使用事例とプッシュ使用事例はともに、コンテンツの全体がパッケージ化され、配信されるものと想定する。代替として、コンテンツは、ストリームとしてパケット化されて、配信されてもよい。この場合、ストリーム自体が保護される(暗号化される)。暗号化の厳密なフォーマットは、OMA DRMの範囲外とされており、既存の暗号化標準から選択されることが可能である。これらのストリームは、可能なパケット損失などに対処するように、ダウンロードに関してOMAによって規定される暗号化スキームとは異なる暗号化スキームを使用して保護されてもよい。しかし、ストリームが暗号化された後、ストリームへのアクセスは、離散的コンテンツに関して前段で説明したのと同一の手続きを介して制御されることが可能である。ROが生成され、ストリーム暗号化鍵が、CEKと同様にROの中に入れられ、次に、このROが、DRMエージェントと暗号上、結び付けられる。
【0065】
4.ドメイン
【0066】
ドメインは、オプションのフィーチャであり、すべてのRIによってサポートされるわけではない可能性がある。ドメインは、ROとCEKが或る特定のDRMエージェント114に結び付けられるOMA DRM2.0の基本モデルを拡張し、RI112が、権利およびCEKを、単一のDRMエージェントだけにではなく、DRMエージェントのグループに結び付けることを許す。すると、ユーザは、同一のドメインに属するすべてのDRMエージェントの間で、DRMコンテンツ122をオフラインで共有することができる。RI112は、ドメイン概念を使用して、ユーザが所有するいくつかのデバイスから、ユーザがDRMコンテンツ122にアクセスすることができるようにすることなどの、新たなサービスを提供する、あるいはユーザが、1つのデバイス(例えば、PC)を介して、別のデバイス(例えば、ポータブルプレーヤ)上で後に使用するために、DRMコンテンツおよび権利を購入する場合、接続されていないデバイスのサポートを提供することができる。
【0067】
5.バックアップ
【0068】
DRMコンテンツ122は、リムーバブルメディア118上に、ネットワークストア116の中に、または他の何らかの形態のストレージの中に格納されることが可能である。DRMコンテンツ122は、暗号化された形態で格納され、関連付けられたRO124を使用する或る特定のターゲットDRMエージェント114によってしかアクセスされることが可能でない。RO124は、ROが、状態のない許可だけしか含まない場合、バックアップの目的で格納されることが可能である。セキュリティモデルが、RO124がオフデバイスで格納される場合でさえ、RO124が保護されて、意図されるDRMエージェント114によってしかアクセスされることが可能でないことを確実にする。一部の許可は、DRMエージェント114による状態、例えば、限られた回数の再生の保持を要求する。そのようなROは、オフデバイスで格納されることが、そうすることにより、状態情報が失われることになる可能性があるので、可能でない。
【0069】
6.スーパ配布
【0070】
DRMコンテンツ122は、コピーされて、他のDRMエージェント114に転送されること、例えば、ユーザが、DRMコンテンツ122を友人に送信することが可能である。友人は、コンテンツ122にアクセスするために、DRMコンテンツパッケージの中のリンクを介してRI112に連れて行かれて、RO124を獲得する。
【0071】
7.エクスポート(非OMA DRMシステムへの)
【0072】
DRMコンテンツ122は、OMA DRM準拠ではないが、他の何らかのDRM機構をサポートするデバイス上で使用されるように、他のDRMシステムにエクスポートされることが可能である。OMA DRMアーキテクチャは、RI112が、所望する場合、別の特定DRMシステムへの変換を、DRMエージェント114が、場合により、その別のDRMシステムによって指定されるとおり実行する、許可を表明することを許す。RI112は、特定の外部DRMシステムだけに、このエクスポートを制限することができる。
【0073】
8.接続されていないデバイスのサポート
【0074】
OMA DRMは、接続されていないデバイスがコンテンツ122およびRO124を購入して、ダウンロードするのを助ける仲介役の働きを、接続されたデバイスがすることを可能にする。ユーザが、例えば、ネットワーク接続を全く有さないOMA DRMに準拠するポータブルデバイス(接続されていないデバイス)と、ネットワーク接続を有するOMA DRMに準拠する移動デバイス(接続されたデバイス)とを有することが可能である。接続されたデバイスを使用して、DRMコンテンツ122をブラウズして、購入し、DRMコンテンツ122を、接続されたデバイスにダウンロードした後、ユーザは、次に、接続されていないデバイス上でDRMコンテンツ122を再生することを所望することが可能である。この場合、接続されたデバイス上のDRMエージェント114は、RI112からドメインRO124を要求して、ダウンロードする。
次に、接続されたデバイス上のDRMエージェント114は、DCFの中にドメインRO124を埋め込む。次に、このDCFが、ローカル接続技術を介する適切なプロトコル、例えば、BluetoothまたはUSBを使用して、接続されていないデバイスに転送されることが可能である。接続されたデバイスと接続されていないデバイスの両方が、OMA DRM準拠であって、この機能をサポートしなければならない。また、接続されていないデバイスは、接続されたデバイスと同一のドメインに属さなければならない。
【0075】
セキュリティおよび信頼
【0076】
以下は、OMA DRM2.0のセキュリティ方策および信頼方策の概要である。一般に、いずれのDRMソリューションも、以下の2つのセキュリティ要件を満たす必要がある。すなわち、(1)保護されたコンテンツは、適切に認証され、許可されたDRMエージェントによってだけアクセスされなければならず、さらに(2)保護されたコンテンツ上の許可は、すべてのDRMエージェントによって遵守されなければならない。DRMコンテンツに関連する許可および制約の執行は、任意のDRMスキームのセキュリティ方策および信頼方策の主要な関心事である。関連付けられたROによって規定されるものを超えたDRMコンテンツへの許可のないアクセス、不正なコピーの作成、およびDRMコンテンツの再配布が、いずれのDRMシステムにも主な脅威を成す。
【0077】
OMA DRMシステムは、OMA環境における保護されたコンテンツのセキュリティで保護された配布および管理のための手段を提供し、前段で規定された要件を満たす。OMA DRMは、ROの制約下におけるコンテンツの保護された使用を確実にするDRMエージェントを使用することによって、消費時点でコンテンツおよびROの使用および保護を執行する。
【0078】
DRMコンテンツを配布するための基本ステップは、以下のとおり要約されることが可能である。すなわち、
【0079】
1.コンテンツパッケージ化。コンテンツは、セキュリティで保護されたコンテンツコンテナ(DCF)の中にパッケージ化される。DRMコンテンツは、対称CEK(コンテンツ暗号化鍵)を使用して暗号化される。コンテンツは、あらかじめパッケージ化されることが可能であり、すなわち、コンテンツパッケージ化は、オンザフライで行われなくてもよい。同一のCEKが、コンテンツのすべてのインスタンスに関して使用されるわけではなく、ただし、このことは、OMA DRMにおける要件ではない。
【0080】
2.DRMエージェント認証。すべてのDRMエージェントが、一意の秘密鍵/公開鍵ペアと、証明書とを有する。証明書は、デバイス製造業者、デバイスタイプ、ソフトウェアバージョン、通し番号などのさらなる情報を含む。このことは、CIおよびRIが、DRMエージェントをセキュリティで保護された仕方で認証することを可能にする。
【0081】
3.RO生成。ROは、DRMコンテンツが、関連付けられたROなしに使用されることが可能でないことを確実にするCEKを含む。ROは、許可(例えば、再生、表示、および実行)および制約(例えば、1ヶ月間、再生する、10分間、表示する)から成る。また、ROは、コンテンツにアクセスが行われる際に、或るユーザが居合わせること(例えば、ユーザの身元によって判定される)を要求する制約を含むことも可能である。これらの許可および制約、ならびにROに実体化される他の情報(例えば、著作権情報)は、ユーザに提示されることが可能である。
【0082】
4.RO保護。ROを配信する前に、ROのセンシティブな部分(CEKなどの)が、REK(権利暗号化鍵)を使用して暗号化され、次に、このROが、ターゲットDRMエージェントに暗号上、結び付けられる。このことにより、ターゲットDRMエージェントだけが、RO、CEK、およびDRMコンテンツにアクセスすることができることが確実にされる。さらに、RIが、ROにデジタルで署名する。また、ROは、CEKを含めることによって、DRMへのアクセスを支配する。OMA DRM REL(権利表現言語)が、DRMコンテンツの使用を支配する許可および制約のシンタックス(XML)およびセセマンティックスを規定する。ROは、RO独自のMIMEコンテンツタイプを有する。
【0083】
5.配信。次に、ROおよびDCFは、ターゲットDRMエージェントに配信されることが可能である。両方のアイテムは、本来的にセキュリティで保護されているので、任意のトランスポート機構(例えば、HTTP/WSP、WAPプッシュ、MMS)を使用して配信されることが可能である。ROとDCFは、例えば、MIME複数パートメッセージの中で、一緒に配信されることも、別々に配信されることも可能である。
【0084】
ROに関するOMA DRM信頼モデルは、双方によって認識され、信頼される主役のグループ、検証者、および1つまたは複数の認証機関が存在する、PKI(公開鍵インフラストラクチャ)に基づく。単一のエンティティが、選択されたコンテキストおよびソリューションのニーズに応じて、主役の役割をすることも、検証者の役割をすることもできる。PKIは、検証者と主役が、開かれた、セキュリティで保護されていないネットワークを介して通信する際に、検証者が、主役の身元、およびその他の属性を認証することを可能にする。そのようなシステムにおいて、通常、検証者は、認証の目的で、検証者が対話する相手の主役についてのセンシティブな情報を全く保持する必要はない。さらに、CA(証明機関)は、主役と検証者の間のトランザクションに直接に関与していない。RIは、DRMエージェントの証明書が、RIによって検証可能であり、取り消されていない場合、DRMエージェントが正しく振る舞うことを信頼する。同様に、DRMエージェントは、RIの証明書が、DRMエージェントによって検証可能であり、取り消されていない場合、RIが正しく振る舞うことを信頼する。
【0085】
OMA DRMに適用されるPKIの主なエンティティは、CA、デバイス、およびRIである。OMA DRMの認証プロトコルおよび鍵転送プロトコルは、RIが、デバイスを認証することができ、デバイスが、RIを認証することができることを要求する。そのような相互認証は、ROAPによって達せられる。
【0086】
さらに、デバイスは、デバイス公開鍵およびデバイス秘密鍵、ならびに適切なCAによって署名された関連する証明書を備えさせられる(製造時に、または後に)ものと想定される。RIによって表明される証明書選好に基づき、デバイスは、適切な証明書を提供しなければならない。デバイスは、完全性および機密性の保護を有するローカルストレージの中に秘密鍵を格納することを要求される。
【0087】
また、RIも、公開鍵、秘密鍵、およびCAによって署名された証明書を与えられる。証明書チェーン(1つのCAによって署名された公開鍵所有者の証明書と、他のCAによって署名されたCAの0、または1つ以上のさらなる証明書とを含む複数の証明書のチェーン)は、信頼の証明書チェーンの検証のための認証プロトコルの時点で、デバイスに提示される。
【0088】
複数のCAが、DRMシステム内に存在することが可能であることに留意されたい。ROAPプロトコルは、RI証明書に署名するCAが、プロトコルの実行中に使用するために、OCSP(オンライン証明書ステータスプロトコル)レスポンダを実行することを要求する。また、CAは、発行された証明書の使用を支配する適切な証明書ポリシーを定義することも要求される。
【0089】
以下は、OMA DRMセキュリティの主な態様を説明する。
【0090】
1.データが、許可のないパーティによってアクセスされることが可能でないことを確実にする機密性。前述したとおり、保護されたコンテンツは、適切に認証され、許可されたDRMエージェントによってだけアクセス可能でなければならない。この目標を達するのに、保護されたコンテンツは、暗号化される。暗号化鍵は、各メディアオブジェクトに一意であり、ROが、意図される受信者によってしかアクセス可能でない鍵の中にラップされた暗号化鍵を担持する。
【0091】
2.或るパーティが、別のパーティに自らの身元を明かすプロセスである認証。OMA DRMにおいて、相互DRMエージェント−RI認証が、4パス登録プロトコル、2パスRO獲得プロトコル、および2パスドメイン参加プロトコルにおいて達せられる。使用されるプロトコル、および送信されるメッセージに依存して、認証は、ナンス上、またはタイムスタンプ上のデジタル署名を介して達せられる。1パスRO獲得プロトコルは、タイムスタンプ上のデジタル署名を介してRI認証を実現する。1パスRO獲得プロトコルは、RIに対してDRMエージェントを認証しないが、保護されたコンテンツが、受信者の公開鍵でラップされることにより、認証は、鍵結び付けを介して間接的に行われる。2パスドメイン退去プロトコルは、タイムスタンプ上のデジタル署名を介して、RIに対してDRMエージェントを認証する。2パスドメイン退去プロトコルは、DRMエージェントに対してRIを認証しない。RIは、ROの配信中にDRMエージェントに対して自らを認証することを要求される。このことにより、RIの真正性について或る程度の保証が提供される。
【0092】
3.データ完全性保護は、データの許可のない変更を検出する能力を確実にする。OMA DRMにおいて、データ完全性保護は、適宜、ROAPメッセージ上、およびRO上のデジタル署名を介して達せられる。
【0093】
4.鍵確認は、保護された鍵を含むメッセージの受信者に、メッセージ送信者が鍵値を知っていることを保証する。DRMコンテキストにおいて、この特性は、或るRIからのROを、別のRIが許可なく再発行することを防止する。OMA DRMシステムにおいて、鍵確認は、保護された鍵の諸部分をMAC鍵として使用することによる、保護された鍵、および送信するパーティの身元に対するMAC(メディアアクセス制御)を介して達せられる。
【0094】
DRMエージェントは、正しい振舞いと、セキュリティで保護された実施の両方の点で、RIによって信頼されなければならない。OMA DRMにおいて、各DRMエージェントは、そのDRMエージェントを識別し、そのエージェントと鍵ペアとの間の結び付きを証明する、一意の鍵ペア、および関連する証明書を備えさせられる。このことにより、RIは、標準のPKI手続きを使用してDRMエージェントをセキュリティで保護された仕方で認証することが可能になる。
【0095】
証明書の中の情報は、RIが、ビジネス規則、コンテンツの価値などに基づいて、ポリシーを適用することを可能にする。例えば、RIは、或る製造業者を信頼することが可能であり、あるいはRIによって定義されたいくつかの基準に従って信頼されるべき、または信頼されるべきでないことが知られているDRMエージェントの更新されたリストを保持することが可能である。
【0096】
DCF(DRMコンテンツフォーマット)は、独自のMIMEコンテンツタイプを有する、暗号化されたコンテンツに関するセキュリティで保護されたコンテンツパッケージである。暗号化されたコンテンツに加え、DCFは、コンテンツ記述(元のコンテンツタイプ、ベンダ、バージョンなど)、RI URI(ユニフォームリソース識別子)(ROが獲得されることが可能なロケーション)などのさらなる情報を含む。このさらなる情報は、暗号化されず、ROが取得される前にユーザに提示されることが可能である。DCF内のDRMコンテンツをアンロックするのに必要とされるCEKは、RO内に含まれる。このため、ROなしにDRMコンテンツにアクセスすることは可能でなく、DRMコンテンツは、ROの中で規定されたとりにしか使用されることが可能でない。OMA DRMは、DRMエージェントが、DCFの完全性を検証することを可能にして、許可のないエンティティによるコンテンツの変更を防止する機構を含む。
【0097】
OMA DRMシステムは、DRMエージェントの中にDRM時間が存在することを想定する。ユーザは、DRM時間を変更することができないので、DRM時間が、OCSPレスポンダによって保持される時間と同期されることが可能な機構が、定義される。いくつかの制約(例えば、絶対時間制約)、ならびにROに関する配信プロトコルのいくつかの態様は、セキュリティで保護された時間源を有するDRMエージェントに依拠する。OMA DRM仕様のコンテキストにおけるDRM時間は、正確な時間、ならびにユーザが変更することが可能でない時間値を意味する。OMA DRM仕様は、DRM時間が、必要な際、例えば、DRM時間が、長い停電の後に失われた場合、同期される機構を提供する。一部の限られた能力の接続されていないデバイスは、リアルタイムのクロックをサポートしないことが可能であり、このため、DRM時間をサポートしない可能性がある。しかし、接続されたデバイスは、DRM時間をサポートしなければならない。
【0098】
OMA DRMは、ROリプレー保護攻撃を防止する。ROリプレー攻撃の例は、中間者が、DRMエージェントへの配信中に、限られた回数の実行でROを傍受する場合である。DRMエージェント上で権利が失効した際、この傍受されたROが、中間者から再び配信される(リプレーされる)可能性がある。OMA DRMは、このこと、および類似した攻撃が行われることを防ぐ。
【0099】
OMA DRMシステムは、前段で列挙したセキュリティ機構の使用を介してアプリケーション層セキュリティを提供する。このため、OMA DRMシステムは、トランスポート層セキュリティに依拠しない、またはトランスポート層セキュリティを前提としない。
【0100】
ROAPは、OMA DRM2.0において、ROに関する情報のセキュリティで保護された認証ベースの交換を可能にすることに中心的な役割を果たす。ROAPは、RIと、デバイス内のDRMエージェントとの間のDRMセキュリティプロトコルスイートを表す一般的な名前である。このプロトコルスイートは、以下のいくつかのサブプロトコルを含む。すなわち、
【0101】
1.図2に示される、RIにデバイスを登録するための4パスプロトコル。
【0102】
2.図3に示される、ROの要求および配信を含む2パスRO獲得プロトコル。
【0103】
3.1パスRO獲得プロトコルは、図4に示されるとおり、RIからデバイスへのROの配信(例えば、メッセージング/プッシュ)と関係する。
【0104】
4.図5に示される、デバイスがドメインに参加する2パスドメイン参加プロトコル。
【0105】
5.図6に示される、デバイスがドメインを退去する2パスドメイン退去プロトコル。
【0106】
図2は、4パス登録プロトコル200の流れ図である。プロトコル200は、デバイス202、RI204、およびOCSPレスポンダ206を利用する。デバイス202は、デバイスID(RI204が、OCSPレスポンダ206に後に確認をとることができるデバイスの証明書のハッシュ)、およびその他の情報などの情報を含む、デバイスハローメッセージを送信すること(ステップ210)によって、RI204との連絡を開始する(場合により、ROAPトリガを受信した後)。テーブル1は、デバイスハローメッセージの主な構成要素を示す。デバイスハローメッセージの中の情報のいずれも、完全性保護されておらず、すなわち、このメッセージに関する署名は、存在しない。
【0107】
【表1】
【0108】
RI204は、デバイスハローメッセージに応答して(ステップ210)、RIの証明書資格情報(RI IDの形態の)、いくつかのセッション関連の(リプライ防止目的の)ナンスおよびセッション番号、ならびにRI204が認識するデバイスについての信頼チェーンに関する情報などの他のオプションの情報などの情報を含む、RIハローメッセージをデバイス202に送信する(ステップ212)。テーブル2は、RIハローメッセージのフォーマットを示す。RIハローメッセージの中の情報のいずれも、完全性保護されていないことに留意されたい。
【0109】
【表2】
【0110】
RIハローメッセージの中に含まれる情報の検証が成功すると、デバイス202は、要求時間、セッションID、および署名などの必須の情報と、証明書チェーン、信頼されるRI権限アンカ、拡張子などのオプションの情報とを含む登録要求メッセージを送信する(ステップ214)。テーブル3は、登録要求メッセージのフォーマットを示す。登録要求メッセージは、末尾において、登録要求メッセージの中の署名フィールドまでの、デバイス202とRI204の間で交換されるすべてのメッセージの、すなわち、デバイスハローメッセージ全体、RIハローメッセージ全体、および署名フィールドまでの(このフィールドを除く)登録要求メッセージのフィールドのデジタル署名を含む。このデジタル署名は、デバイスの秘密鍵を使用して作成される。このデジタル署名を含めることにより、関連するROAPメッセージのいくらかの完全性保護がもたらされる。
【0111】
【表3】
【0112】
デバイス202が、拡張子の中の情報を介して、OCSP検証が必要ない、またはサポートされないことを示すのでない限り、RI204は、デバイス202によってRI204に供給される情報の検証を要求するOCSP要求メッセージをOCSPレスポンダ206に送信する(ステップ216)。OCSPレスポンダ206は、要求メッセージの中でこの情報を探して、この情報を検証し、要求の結果を含むOCSP応答メッセージを戻そうと試みる(ステップ218)。
【0113】
RI204は、登録が成功したか、失敗したかという指示、ならびに他の情報を含む登録応答メッセージをデバイス202に送信する。テーブル4は、登録応答メッセージのフォーマットを示す。登録応答メッセージは、末尾に、登録要求メッセージおよび登録応答メッセージのSHA−1ハッシュ(署名フィールドまでの、署名フィールドを除く)を含む。このデジタル署名は、RIの秘密鍵を使用して行われる。デジタル署名を含めることにより、関連するROAPメッセージのいくらかの完全性保護がもたらされる。SHA−1ハッシュが、このデジタル署名に関して使用されるが、デジタル署名を適用するための任意の適切なアルゴリズムが使用されることが可能であることに留意されたい。
【0114】
【表4】
【0115】
図3は、2パスRO獲得プロトコル300の流れ図である。プロトコル300は、デバイス202およびRI204を利用し、4パス登録プロトコル200が完了して、デバイス202が、RI204についての有効な証明書チェーンを受信した後に機能する。プロトコル300は、デバイス202によって、RI204からROを要求するのに使用される。デバイス202は、RO要求メッセージをRI204に送信して、ROを要求する(ステップ310)。テーブル5は、RO要求メッセージのフォーマットを示す。RO要求メッセージは、メッセージのデジタル署名(署名フィールドを除く)を含む。
【0116】
【表5】
【0117】
RI204は、要求メッセージに応答して、デバイス202にRO応答メッセージを送信する(ステップ312)。RO応答メッセージは、ROを含む、またはROが送信されないという指示を含む。
【0118】
テーブル6は、RO応答メッセージのフォーマットを示す。RO応答メッセージは、成功した状態の場合、署名フィールドを除くRO要求メッセージおよびRO応答メッセージのSHA−1ハッシュであるデジタル署名を含む。
【0119】
【表6】
【0120】
図4は、1パスRO獲得プロトコル400の流れ図である。プロトコル400は、デバイス202およびRI204を利用する。プロトコル400において、RI204は、デバイス202による要求なしに、ROを含むRO応答メッセージをデバイス202に一方的に送信する(ステップ410)。プロトコル400は、例えば、プッシュ使用事例を適用する。テーブル7は、RO応答メッセージのフォーマットを示す。
【0121】
【表7】
【0122】
図5は、2パスドメイン参加プロトコル500の流れ図である。プロトコル500は、デバイス202およびRI204を利用する。デバイス202が、ドメインに参加することを望む場合、デバイス202は、RI204にドメイン参加要求メッセージを送信する(ステップ510)。RI204は、この要求を評価し、ドメイン参加応答メッセージをデバイス202に送信する(ステップ512)。テーブル8は、ドメイン参加要求メッセージのフォーマットを示し、テーブル9は、ドメイン参加応答メッセージのフォーマットを示す。
【0123】
【表8】
【0124】
【表9】
【0125】
図6は、2パスドメイン退去プロトコル600の流れ図である。プロトコル600は、デバイス202およびRI204を利用する。デバイス202が、ドメインを退去することを望む場合、デバイス202は、RI204にドメイン退去要求メッセージを送信する(ステップ610)。RI204は、この要求を評価して、デバイス202にドメイン退去応答メッセージを送信する(ステップ612)。テーブル10は、ドメイン退去要求メッセージのフォーマットを示し、テーブル11は、ドメイン退去応答メッセージのフォーマットを示す。
【0126】
【表10】
【0127】
【表11】
【0128】
1パスRO獲得プロトコルを除いて、ROAPスイートに含まれるプロトコルのすべては、ROAPトリガを使用して開始されることが可能である。また、デバイス202は、ユーザ対話の結果、一方的にプロトコルを開始することもできる。RI204は、ROAPトリガを生成して、デバイス202に送信して、ROAPプロトコル交換をトリガする。代替として、RI204は、必要な情報(RO識別子やドメイン識別子などの)を他のシステムに供給することによって、ROAPトリガ生成をこれらのシステムに委任してもよい。また、ROAPトリガ(RI204によって直接に生成されたか、間接的に生成されたかにかかわらず)は、他のシステム(例えば、CI)によってデバイス202に送信されることも可能である。
【0129】
デバイス202が、ROAPトリガを受信すると、デバイス202は、可能な限り早くROAPプロトコル交換を開始する。ROAPトリガを受信した結果、ROAPプロトコルを開始するのに先立って、適切なユーザ同意が、得られていなければならない。ROAPは、いくつかのプロトコルを含むので、ROAPトリガは、デバイス202によって開始されるべき実際のプロトコル(例えば、登録、RO獲得、ドメイン参加、またはドメイン退去)の指示を含む。
【0130】
ROAPメッセージ、およびこれらのメッセージが、プロトコルによって、どのように扱われるかは、RO,および関連する処理を提供するだけでなく、OMA DRM2.0におけるROを取り巻くセキュリティ機能も提供する。より具体的には、以下のセキュリティ態様および信頼態様が、ROAPプロトコルによって扱われる。すなわち、
【0131】
1.RIとデバイスの間の相互認証、
【0132】
2.様々なメッセージにおいてナンスを使用することによって、リプレー攻撃に対処すること、
【0133】
3.ROAPメッセージ、およびROAPメッセージの諸部分の完全性を保護すること、および
【0134】
4.ROAPメッセージ、またはROAPメッセージの諸部分におけるセキュリティで保護されたDRM時間の検証である。
【0135】
(信頼されるコンピューティング技術)
【0136】
最近、信頼されるコンピューティング技術が、おおむね、TCG(Trusted Computing Group)の技術的傘下において文献および製品に出現している。TCG技術は、コンピューティングエンティティが、信頼チェーンを使用することによって、エンティティ、および他のデバイスの信頼性を確立することができ、したがって、そのようなデバイス上の処理またはコンピューティングは、以下のとおりであることが可能である。すなわち、
【0137】
1.プラットフォーム、ならびに様々なHW(ハードウェア)構成要素およびSW(ソフトウェア)構成要素の信頼性に関して評価され、
【0138】
2.適切な信頼レベルが確立された場合にだけ、検証され、外部要求があると、エンティティまたはデバイス自らに対して、ならびに他のエンティティまたはデバイスに対して検証されることが可能であり、さらに
【0139】
3.外部パーティは、他のデバイスとの情報および処理の交換に関する評価および決定を実行することができ、そのようなターゲットデバイスの表明された信頼レベルに基づく。
【0140】
TCGは、以下のフィーチャを有する、TPM(信頼される処理モジュール)と呼ばれるコア処理モジュールを定義する。すなわち、
【0141】
1.モジュール、およびモジュールのインタフェースの物理的保護、
【0142】
2.保護された揮発性のストレージスペース、および保護された不揮発性のストレージスペース、
【0143】
3.暗号化、およびデジタル署名を実行することができるモジュール内部の保護された暗号化機能、
【0144】
4.ハッシュ拡張によるプラットフォーム、およびプラットフォームのSW構成要素の「状態」を連続的にキャプチャするPCR(プラットフォーム構成レジスタ)の使用、
【0145】
5.デバイスの認証のルートの役割をするが、ただし、直接的な仕方でそのような役割をするのではないPKIに基づく、デバイス特有のセキュリティで保護されたEK(承認鍵)の存在。EKは、決して外部に開示されないが、AIK(構成証明アイデンティティ鍵)と呼ばれるEKのエイリアスが、プラットフォームの完全性測定値に署名するのに使用され、さらに
【0146】
6.データの「密封」を、AIKによって署名されたPCR値と併せて、メモリ「BLOB」の中で使用して、プラットフォーム完全性またはSW完全性(TPMからの、または密封メモリBLOBからの合致するPCR値によって測定され、検証された)が検証された場合に限って、データがアクセスされる、または抽出されることが可能であるようにすること。
【0147】
信頼されるコンピューティング技術が、特に移動電話デバイスのコンテキストにおいて、そのような移動デバイス上のDRMアプリケーションをセキュリティで保護することへの可能な応用のために、検査される。TCG技術の使用によってDRMアプリケーションをセキュリティで保護するようにこれまでに提案された方法は、TPM密封の手続き、およびメモリBLOBを使用して、TCG鍵を使用するROAPプロトコル処理の後、TPM、および鍵保護を有するストレージエリアの中にDRM関連のデータをセキュリティで保護された仕方で格納することを含んでいた。
【0148】
しかし、既存の従来技術は、プラットフォーム、および/またはDRMソフトウェアに対してどのように「信頼」を確立し、使用すべきかを明示的に扱う、または秩序立った仕方で扱うことはしない。また、従来技術は、ROAPメッセージの中の完全性をセキュリティで保護して、OMA DRM2.0システムにおける完全性処理を強化することもしない。本発明は、そのような目的で新たな技術を含む。
【0149】
現在のOMA DRM2.0仕様は、CA、RI、およびデバイスが関与するPKIに基づく、強いセキュリティ方法を提供する。しかし、OMA DRM2.0仕様の範囲内でも、OMA DRM2.0準拠であるデバイスおよびRIの不特定の実施に関連しても、プラットフォーム、SW、エージェント、およびメッセージのセキュリティおよび完全性と関係する脆弱性が、存在する。
【0150】
OMA DRM仕様は、デバイスまたはRIが、OMA DRM2.0仕様を遵守している場合でも、いずれのデバイスまたはRIも直面する可能性がある様々な脅威および脆弱性を認識している。これらの脆弱性には、以下が含まれる。すなわち、
【0151】
1.攻撃者が、DRMシステムのエンティティを物理的に、またはそれ以外で侵害しようと試みることが可能な、エンティティ侵害。エンティティ侵害攻撃のタイプには、デバイス上のDRMエージェント、およびRIにおけるDRM SWを侵害することが含まれる。エンティティ侵害の結果には、秘密鍵、ドメイン鍵、RO暗号化鍵、コンテンツ暗号化鍵、および保護されたコンテンツの開示、ならびに、例えば、DRMエージェントのリプレーキャッシュの完全性保護が失われること、および/またはDRMエージェントの内部に格納された権利の保護が失われることが含まれる。さらに、DRM時間が失われることが、生じる可能性もある。侵害されたCAまたはOCSPレスポンダのPKIに対する影響は、例えば、非特許文献1において説明される。
【0152】
OMA DRMシステムは、侵害されたエンティティによって生じる損害を最小限に抑えるのに、証明書取り消しに依拠する。DRMエージェントおよびRIは、エンティティの証明書ステータスを調べることによって、DRMエージェントおよびRIが通信している相手のエンティティが、侵害されていないことを常に検証しなければならない。エンティティ侵害攻撃は、「順方向」でも、「逆方向」でも行われる可能性がある。順方向侵害攻撃は、DRMエンティティ(RI、DRMエージェント、CI、CA、またはOCSPレスポンダ)に対してであり、許可のない振舞いにつながる。逆方向侵害攻撃は、DRMエージェントのセキュリティ、完全性設定、および構成を無力化する、または脆弱にする。
【0153】
2.攻撃者が、DRMエージェントとRIの間で送信されるメッセージを削除することができ、通常、DoS(サービス拒否)攻撃をもたらすメッセージ削除。メッセージ削除攻撃には、登録プロトコル中、またはRO獲得プロトコル中のメッセージ削除、リプレーナンス削除、ROAPトリガの削除などが含まれることが可能である。
【0154】
3.攻撃者が、DRMエージェントとRIの間で送信される任意のメッセージを変更することができ、通常、DoS攻撃をもたらすメッセージ変更。メッセージ変更攻撃には、登録プロトコル中の変更、ドメイン参加プロトコル中の変更、およびドメイン退去プロトコル中の変更、ならびに様々なROAPトリガに対する変更が含まれることが可能である。
【0155】
4.攻撃者が、RIとDRMエージェントの間の任意のポイントで通信チャネルにメッセージを挿入することができるメッセージ挿入。また、攻撃者は、メッセージを記録して、これらのメッセージを後の時点でリプレーしようと試みることもできる。メッセージ挿入攻撃は、登録プロトコルの最中に挿入されたメッセージ、2パスRO獲得プロトコルの最中に挿入されたメッセージ、1パスRO獲得プロトコルの最中に挿入されたメッセージ、および様々なROAPトリガに挿入されたメッセージを含むことが可能である。
【0156】
5.一般的なDoS攻撃、トラフィック解析などの受動的攻撃、およびプライバシー開示などのその他の攻撃。
【0157】
現在のOMA DRM仕様およびOMA DRM実施形態の以下の問題が、特定される。OMA DRMスキームに適用された「完全性」の拡大された概念が、定義される。従来の意味で、OMA DRM仕様は、ROAPメッセージ完全性の小さい範囲だけしか扱わない。本発明において定義される完全性の拡大された概念において、以下において、どこで、どのような種類の完全性が考慮されることが可能であるか留意されたい。
【0158】
1.DRMプラットフォーム完全性。DRMプラットフォーム完全性は、プラットフォームエンティティにおける、またはプラットフォームエンティティ内の、すなわち、デバイス、RI、およびコンテンツ機能を含む物理的エンティティにおける完全性と関係する。異なるエンティティには、OS(オペレーティングシステム)、起動コード(例えば、PCの事例におけるBIOS)、メモリアクセスのためのHW/FW(ファームウェア)/SW、セキュリティ関連の機能(暗号法および鍵管理、ならびにポリシー、証明書などの秘密データの特権的格納)を処理する様々なHW/FW/SWエンティティ、ならびにネットワーク接続HW/FW/SWおよびローカル接続HW/FW/SWが含まれる。プラットフォーム完全性は、プラットフォームが、有効であり、真性であり、正当なプロセスによる他は、変更されておらず、意図されるとおりにしか動作しないかどうかを判定する。
【0159】
2.DRM SW完全性。DRM SWとは、OMA DRM仕様、およびOMA DRM仕様の手続きに特有の機能を実行するデバイス内、RI内、またはCI内に存在するソフトウェアエンティティおよびソフトウェア構成要素を指す。デバイスにおいて、DRMエージェントは、DRM SWから成る。RIおよびCIにおいて、DRM SWとは、ROパッケージ化、DCFフォーマット、コンテンツ暗号化、コンテンツ配信もしくはRO配信、検証、ROAP処理などのDRM特有の機能を実行するSWのセットをまとめて指す。DRM SW完全性は、DRM SWが、有効であり、真性であり、正当なプロセスによる他は、変更されておらず、意図されるとおりにしか動作しない場合に、維持される。
【0160】
3.ROAPメッセージおよびROAP情報の完全性。ROAPメッセージ、およびこれらのメッセージを構成する情報の完全性は、そのような情報が、有効であり、真性であり、正当なプロセスによる他は、変更されていない場合、維持される。OMA DRM2.0仕様において、ROAPメッセージのいくつかのサブセット、およびこれらのサブセットを構成する情報は、デジタル署名の使用によって完全性保護される。
【0161】
4.メディアオブジェクトおよびDRMコンテンツの完全性。メディアオブジェクトおよびDRMコンテンツも、完全性保護されなければならず、すなわち、メディアオブジェクトおよびDRMコンテンツが、デバイスにおいて格納されているか、RIにおいて格納されているか、CIにおいて格納されているか、あるいはいずれかの2つのパーティ間で伝送中または配信中であるかにかかわらず、変更される、削除される、または不正に挿入されることがあってはならない。特に関心を引くのが、DRMコンテンツが、基本的に開かれたチャネルを使用して配信される場合の、移動デバイスへのコンテンツの転送に適用可能な、コンテンツのOTA(無線)配信である。
【0162】
5.DRM関連の情報の完全性。エンティティID(デバイスID、RI IDなど)、暗号化鍵(CEK、REK)および署名鍵、RO自体、コンテキスト情報、証明書、およびその他の信頼チェーン関連の情報などのDRM関連の情報は、セキュリティで保護されなければならず、このことは、これらの情報が、機密性を保護されるだけでなく、完全性も保護されなければならないことを意味する。
【0163】
現在のOMA DRM2.0仕様も、既存の従来技術も、エンティティ侵害または完全性問題に対するソリューションを提供したように思われないことに留意されたい。ソリューションのこの欠如は、以下の問題をもたらす。すなわち、例えば、すべてのROAP手続きが、OMA DRM2.0仕様に準拠して正しく実施された場合でも、RIのプラットフォームが信頼できるかどうか、デバイスはどのようにして本当に知ることができるか。つまり、RIのプラットフォームが、ROAPプロトコルの一環としてデバイスが送信するデータを乱用しないかどうか、またはDRM処理自体を乱用しないかどうかを、デバイスは、どのようにして知ることができるか。例えば、デバイスは、RIのプラットフォームSWが、侵害されており、デバイスのさもなければ有効な使用権利を制限するため、RIが、デバイスの使用権利を恣意的に、誤って制限するかどうかを知らない。DRMソフトウェアの完全性の問題に関して、同様の問題が生じる。より具体的には、前述した完全性の拡大された概念から見た現在のOMA DRM2.0システムの問題のいくつかは、以下のとおりである。
【0164】
1.プラットフォームおよびDRM SWの完全性を検査して、報告する方法の欠如。前段で特定されたエンティティ侵害脅威と関係して、OMA DRM2.0仕様によって指定される、またはTCG1.2使用事例の一環としての、デバイスとRIとの間の明確な、構造化されたプラットフォーム完全性検証、およびSWエージェント完全性検証のための方法は、従来技術において、全く存在しない。このことは、DRMエージェントに関してだけでなく、プラットフォーム完全性検証に関して特に当てはまる。
【0165】
2.プラットフォーム(デバイスと関係して、PCもしくはPDA,あるいはRIに関して、サーバなどの)が、悪意のある仕方で侵害されることが可能であり、これにより、DRMエージェントおよびRIエージェントSWが、正しい、機密性保護され、完全性保護された情報を与えられても、正しく動作することが妨げられることになる可能性がある。例えば、さもなければよく保護されたDRMエージェントSWが、処理に先立って、処理中に、または処理後に、いくらかの情報を共有メモリの中に平文で格納する可能性がある。侵害されたプラットフォームは、そのような事例において、共有メモリにひどくアクセスして、情報を削除する、情報を変更する、または新たな偽の情報を挿入して、この情報が、そのような偽の情報を真性と認識する可能性があるDRMエージェントSWによって後に処理される得る可能性がある。このことは、DoS攻撃、プライベート情報の許可のない開示、またはDRM ROもしくはDRMコンテンツの許可のない配信、配布、または消費をもたらす可能性がある。
【0166】
3.DRM関連の情報を処理するSWの部分であるDRMエージェントSWおよびRI SWが、様々な理由で侵害される可能性がある。そのようなSWが、例えば、ウイルス、または他の悪意のあるSWエンティティによって変更されることが可能である。プラットフォームまたはDRM SWのそのような侵害の1つの結果は、OMA DRM2.0が考慮するメッセージおよび情報、特にROAPプロトコルメッセージの完全性が後に侵害されることである。1つには、ROAPメッセージのすべてではなく、一部だけが完全性保護されるため、ROAPメッセージは、理論上、侵害されたデバイスと、不正な、つまり、侵害されたRIとの間で同期された仕方で操作されることが可能である。メッセージは、デバイスとRIの両方において同期した仕方で変更されることが可能であり、メッセージは、同一の仕方で変更されたため、それでも、「完全性検証」されているように見える可能性がある。
【0167】
4.ROAPメッセージの不十分な完全性保護。メッセージ完全性と関係して、ROAPメッセージ、および様々なメッセージフィールドによって担持される情報は、OMA DRM2.0仕様によっては解決されない脆弱性を被る。例えば、OMA DRM2.0仕様の中で現在、指定されているROAPメッセージ完全性保護は、以下のような穴を残す。すなわち、
【0168】
4A.すべてのROAPメッセージが、完全性保護されるわけではない。すべてのメッセージの中にデジタル署名を含めるわけではないことにより、一部の場合において脆弱性がもたらされる可能性がある。
【0169】
4B.ROAPメッセージ、または情報の一部のフィールドが、デジタル署名によって完全性保護されている場合でさえ、一旦、そのような情報が解読され、完全性検査され、その後、平文で使用されると、悪意のあるエンティティが、この平文情報にアクセスして、それまでに完全性検査された情報を削除する、改変する、または再配布する可能性がある。このため、強化された完全性保護が、要求される。
【0170】
5.DRMコンテンツ、およびDRMコンテンツの配信の完全性に関する脆弱性。より具体的には、以下の問題が存在する。すなわち、
【0171】
5A.コンテンツ完全性検査機構が、不完全である。例えば、コンテンツが伝送されている、または配信されている(例えば、OTAダウンロード)最中のコンテンツの完全性が、規定されていない。例えば、DFCに関する署名は、ROAP手続きにおいて使用するためにだけ生成される。ROAP手続きが行われるまで、この手続きより前に、例えば、CIにおける格納中に、コンテンツ完全性を管理する完全性検査機構は、全く存在しない。
【0172】
5B.コンテンツ暗号化は、ROAPプロトコルにおいて使用するためにさえ、必須であるが、完全性検査は、単にオプションである。
【0173】
5C.特に、ストリーミングサービスに関するパケット化されたコンテンツに関して、PDCFフォーマットは、タイミング問題を有する。不正に変更されているパケットが、ダウンロードされる可能性があり、ストリーム全体の完全性が検査されることが可能である前に、消費される(すなわち、メディアプレーヤ上で再生される)可能性さえある。
【先行技術文献】
【非特許文献】
【0174】
【非特許文献1】IETF RFC3280
【発明の概要】
【発明が解決しようとする課題】
【0175】
中心的問題は、以下のとおりとなる。すなわち、様々なパーティ(デバイス、RI、およびCI)はどのようにして、プラットフォーム完全性、およびDRM SW完全性を確信することができるか。このため、DRMエージェントSWまたはRI SWが依拠するプラットフォーム(例えば、OS、BIOS,ドライバ、メディアプレーヤ、通信ソフトウェア、共有メモリなど)の完全性を強化し、検証する方法が、必要とされる。本発明は、従来技術の欠点に対処する。
【課題を解決するための手段】
【0176】
本発明は、OMA DRM仕様 v2.0と関係するエンティティ、メッセージ、および処理の完全性を強化するいくつかの方法を開示する。これらの方法は、業界フォーラム、TCG(Trusted Computing Group)によって規定される、信頼されるコンピューティング(Trusted Computing)技術として一般に知られる技術を使用する。本発明の第1の実施形態において、DRM ROAP仕様およびDCF仕様の変更を伴う場合と、伴わない場合の両方の、プラットフォームおよびDRM SWの完全性または信頼性を検証する技術が、開示される。第2の実施形態において、既存のROAPプロトコルを変更することなしに、OMA DRM ROAPメッセージ、ROAPメッセージを構成する情報、およびROAP処理の完全性を強化する技術が、開示される。第3の実施形態において、既存のROAPプロトコルのいくつかの変更を伴って、ROAPメッセージ、情報、および処理の完全性を強化する技術が、開示される。
【0177】
本発明のより詳細な理解は、例として与えられ、添付の図面と併せて理解されるべき、好ましい実施形態の以下の説明から得ることができる。
【図面の簡単な説明】
【0178】
【図1】既存のOMA DRM2.0機能アーキテクチャを示すブロック図である。
【図2】既存のOMA DRM2.0 ROAP 4パス登録プロトコルを示す流れ図である。
【図3】既存のOMA DRM2.0 ROAP 2パスRO獲得プロトコルを示す流れ図である。
【図4】既存のOMA DRM2.0 ROAP 1パスRO獲得プロトコルを示す流れ図である。
【図5】既存のOMA DRM2.0 ROAP 2パスドメイン参加プロトコルを示す流れ図である。
【図6】既存のOMA DRM2.0 ROAP 1パスドメイン退去プロトコルを示す流れ図である。
【図7】OMA DRM2.0エンティティ間のマルチパーティプラットフォーム完全性検査を示すブロック図である。
【図8】2つのエンティティが、デバイスとRI、またはデバイスとCIであることが可能である場合の2つのエンティティ間でプラットフォーム完全性検証を実行するための方法を示す流れ図である。
【図9】従来の信頼検査を使用してデバイスとRIの間で相互プラットフォーム完全性検査を実行するための4パスROAP登録プロトコルを示す流れ図である。
【図10】変更されたデバイスハローメッセージ、および変更されたRIハローメッセージを使用して、デバイスとRIの間で相互プラットフォーム完全性検査を実行するための4パスROAP登録プロトコルを示す流れ図である。
【図11】2つのエンティティが、デバイスとRI、またはデバイスとCIであることが可能である場合の2つのエンティティ間でDRMソフトウェア完全性検査を実行するための方法を示す流れ図である。
【図12】デバイスとRIの間で相互DRMソフトウェア完全性検査を実行するための2パスROAP RO獲得プロトコルを示す流れ図である。
【図13】密封結び付け、およびメモリBLOB生成を含むTCG技術を使用したROAPメッセージおよびROAP処理の完全性を向上させるための方法を示す流れ図である。
【発明を実施するための形態】
【0179】
以降、「無線送信/受信ユニット」(WTRU)という用語には、ユーザ機器、移動局、固定加入者ユニットもしくは移動加入者ユニット、ポケットベル、または有線環境または無線環境において動作することが可能な他の任意のタイプのデバイスが含まれるが、以上には限定されない。以降、言及される場合、「基地局」という用語には、ノードB、サイトコントローラ、アクセスポイント、または無線環境における他の任意のタイプのインタフェースデバイスが含まれるが、以上には限定されない。
【0180】
本発明は、DRMエンティティ(例えば、デバイス、RI、またはCI)の信頼状態または完全性に関する情報が、OMA DRM手続きの前提条件として、いずれの2つのDRMエンティティの間でも明示的に、相互に要求され、交換される方法を開示する。
【0181】
この方法の一般的なアーキテクチャ700が、図7に示される。このアーキテクチャは、4つのDRMエンティティ、すなわち、デバイス702、RI704、CI706、およびPCA(プライベート証明機関)708を含む。プラットフォーム完全性検査は、PCA708が、その他のDRMエンティティ(例えば、デバイス702、RI704、およびCI706)に関する信頼されるコンピューティング(例えば、TCG)資格証明のレコードを有し、それらのTCG資格証明の証明に関する信頼のルートを提供するものと想定する。
【0182】
互いの間で相互プラットフォーム完全性検査を望む任意のエンティティペア(例えば、デバイス702とRI704、デバイス702とCI706、またはRI704とCI706)が、信頼されるコンピューティング対応である(例えば、TCG TPM(信頼される処理モジュール)710を備えている)。このことは、信頼されるコンピューティング対応のDRMエンティティが、TPM710(または均等物)を有するだけでなく、AIK712、SML714、およびBLOBを使用する保護されたメモリ716などの、関連するTCGリソースも有することを暗示する。やはり存在するのが、OSまたはプラットフォームソフトウェア718およびDRMソフトウェア720である。
【0183】
以上の要件が満たされる場合、様々なDRMエンティティの任意のペアが、PCA708、および信頼されるコンピューティング能力を使用して、プラットフォーム完全性またはプラットフォーム信頼状態を互いに検査することができる。例として、デバイス702とRI704の間の相互完全性検査のための手続きは、以下のとおりである。
【0184】
デバイス702、RI704、およびCI706がすべて、OS構成要素、または他のプラットフォームソフトウェア構成要素の自己検査(ステップ730)、およびDRMソフトウェアの自己検査(ステップ732)を実行することができる。自己検査は、より大きい検証プロセス(後段でより詳細に説明される)の一環として要求されることも、スタンドアロンのプロセスであることも可能である。これらの自己検査のいずれかが不合格であった場合、そのことは、そのエンティティが、侵害されており、信頼されるべきでないことの表れである可能性がある。
【0185】
デバイス702は、デバイス702のプラットフォームTCG資格証明をRI704に送信する(ステップ740)。プラットフォームTCG資格証明の例には、署名されたTCGプラットフォーム証明書、または署名されたTPM証明書が含まれるが、以上には限定されない。資格証明の一部として、デバイス702は、自己証明された信頼状態フラグ、または自己証明されたプラットフォーム完全性検査済みフラグを補足的な情報として、RI704に送信することもできる。デバイス702が、RI704のプラットフォーム完全性を検証する場合、ステップ740で送信される資格証明情報は、RI704が、デバイス702のプラットフォーム完全性を検証する手続きを開始することをデバイス702が望むという、デバイス702による指示も含む。デバイス702は、RIのプラットフォーム完全性ステータスの検証がオプションのフィーチャである場合に限って、RI704のプラットフォーム完全性を検証すべきかどうかに関する決定を行うことができ、一実施形態では、RIのプラットフォーム完全性を検証することは、必須のフィーチャであることに留意されたい。
【0186】
デバイス702から資格証明情報を受信すると、RI704は、この資格証明情報をPCA708に中継し(ステップ742)、デバイス702についての資格証明、特に、デバイスの最新の信頼性を検証するよう、PCA708に要求も行う。すると、PCA708は、デバイス702に関する最新の信頼性情報(例えば、プラットフォーム信頼レベルなど)をRI704に送信する(ステップ744)。PCA708からデバイスプラットフォーム信頼性情報を受信し、オプションとして、デバイス702から補足的な情報も受信すると、RI704は、デバイス702の信頼レベルを評価する。RI704は、デバイスプラットフォームの完全性に十分な信頼を与えて、登録プロトコルまたはRO獲得プロトコルなどのDRM手続きをさらに進めるかどうかを決定する。
【0187】
デバイス702は、必須の手続きとして、またはオプションの手続きとして、ステップ740〜744の場合と同様な、相互の仕方でRI704のプラットフォーム完全性を評価することができる。より具体的には、RI704が、RI704のプラットフォームTCG資格証明についての情報を、デバイス702に送信する(ステップ750)。資格証明の一部として、RI704は、自己証明された信頼状態フラグ、または自己証明されたプラットフォーム完全性検査済みフラグを補足的情報として、デバイス702に送信することもできる。
【0188】
RI704からTCG関連の情報を受信すると、デバイス702は、この情報をPCAに中継し(ステップ752)、RI704についての資格証明、特に、RIの最新の信頼性を検証するよう、PCA708に要求も行う。すると、PCA708は、RI704に関する最新の信頼性情報をデバイス702に送信する(ステップ754)。RI704に関してPCA708からRIプラットフォーム信頼性情報を受信し、オプションとして、RI自体から補足的な情報も受信すると、デバイス702は、RI704の信頼レベルを評価する。デバイス702は、RIプラットフォームの完全性に十分な信頼を与えて、登録プロトコルまたはRO獲得プロトコルなどのDRM手続きをさらに進めるかどうかを決定する。
【0189】
デバイス702は、必須の手続きとして、またはオプションの手続きとして、CI706のプラットフォーム完全性を評価することができる。CI706が、CI706のプラットフォームTCG資格証明についての情報を、デバイス702に送信する(ステップ760)。資格証明の一部として、CI706は、自己証明された信頼状態フラグ、または自己証明されたプラットフォーム完全性検査済みフラグを補足的な情報として、デバイス702に送信することもできる。
【0190】
CI706からTCG関連の情報を受信すると、デバイス702は、この情報をPCAに中継し(ステップ706)、CI706についての資格証明、特に、CIの最新の信頼性を検証するよう、PCA708に要求も行う。すると、PCA708は、CI706に関する最新の信頼性情報をデバイス702に送信する(ステップ764)。CI706に関してPCA708からCIプラットフォーム信頼性情報を受信し、オプションとして、CI自体から補足的な情報も受信すると、デバイス702は、CI706の信頼レベルを評価する。デバイス702は、CIプラットフォームの完全性に十分な信頼を与えて、DRM手続きをさらに進めるかどうかを決定する。
【0191】
デバイス702のプラットフォーム完全性が、以下のとおり、CI706によって検証されることが可能である。デバイス702は、デバイス702のプラットフォームTCG資格証明についての情報をCI706に送信する(ステップ770)。資格証明の一環として、デバイス702は自己構成証明信頼状態検査フラグまたはプラットフォーム完全性検査フラグを補足情報としてCI706に送信することも可能である。デバイス702が、CI706のプラットフォーム完全性を検証する場合、ステップ770で送信される資格証明情報は、CI706が、デバイス702のプラットフォーム完全性を検証する手続きを開始することをデバイス702が望むという、デバイス702による指示も含む。デバイス702は、CIのプラットフォーム完全性ステータスの検証がオプションのフィーチャである場合に限って、CI706のプラットフォーム完全性を検証すべきかどうかに関する決定を行うことができ、一実施形態では、CIのプラットフォーム完全性を検証することは、必須のフィーチャであることに留意されたい。
【0192】
デバイス702から資格証明情報を受信すると、CI706は、この資格証明情報をPCA708に中継し(ステップ722)、デバイス702についての資格証明、特に、デバイスの最新の信頼性を検証するよう、PCA708に要求も行う。すると、PCA708は、デバイス702に関する最新の信頼性情報をCI706に送信する(ステップ774)。PCA708からデバイスプラットフォーム信頼性情報を受信し、オプションとして、デバイス702から補足的な情報も受信すると、CI706は、デバイス702の信頼レベルを評価する。CI706は、デバイスプラットフォームの完全性に十分な信頼を与えて、DRM手続きをさらに進めるかどうかを決定する。
【0193】
前述の例では、ステップ740〜744は、デバイス702が、RI704に対してデバイス702の完全性ステータスを検証するのに、本発明の必須のフィーチャであることに留意されたい。しかし、デバイス702に対してRI704のプラットフォーム完全性を検証すること(ステップ750〜754)、デバイス702に対してCI706のプラットフォーム完全性を検証すること(ステップ760〜764)、およびCI706に対してデバイスプラットフォーム完全性を検証すること(ステップ770〜774)は、DRMシステムにおける、オプションであるが、それでも強く推奨されるフィーチャである。
【0194】
これらの手続きは、検証される必要があるエンティティによる能動的な開始によって開始される必要はないことにも留意されたい。これらの完全性検証手続きは、その他のパーティの完全性を検証することを所望するエンティティによる要求で始まることが可能である。そのような場合において、ステップ740、750、760、または770のそれぞれには、その他のパーティのプラットフォーム完全性の検証を要望するエンティティが、関係のある信頼関連の情報を送信するよう、その他のパーティを呼び出す、またはその他のパーティに要求する別のステップが先行する。
【0195】
代替の実施形態では、実際的なOMA DRMシステム実施に関して、前述した、提案されるプラットフォーム完全性検証手続きに関する条件またはトリガ機構には、以下が含まれることが可能である。
【0196】
1.デバイスプラットフォーム完全性検証手続き(すなわち、ステップ740〜744)が、以下の1つまたは複数によって実行されることが可能である。
【0197】
1A.デバイスが、新たな4パスROAP登録プロトコルを開始することを要望する前。
【0198】
1B.各RIにつき1回、その特定のRIへの最初の登録が行われる前。この場合、RIは、最初の登録より前に1回、デバイスのTCG資格証明を受信し、次に、RIは、デバイスの資格証明情報をTPM鍵に結び付けることによって、RI自らのTPMの下で、この資格証明情報を保護する。RIは、後に、この格納されたTCG資格証明の結び付きを解除して、定期的に、またはいくつかのイベント時に、例えば、OCSP CAを調べることによって、RIが受信したデバイスのTCG資格証明が依然として有効であるかどうかを検証する。
【0199】
1C.定期的に、指定された時間、例えば、デバイスが、同一のRIに対して前回の登録プロトコルを完了して以来、TDEV-PLATFORM-LAST-REGが経過するたびに。
【0200】
1D.定期的に、指定された時間、例えば、デバイスが、同一のRIに対してデバイスの完全性ステータスを前回に検証して以来、TDEV-PLATFORM-LAST-REPORTが経過するたびに。
【0201】
2.RIプラットフォーム完全性検証手続き(すなわち、ステップ750〜754)が実施される場合、実施される際に、実施されるプラットフォーム完全性検証手続きは、以下の1つまたは複数によって実行されることが可能である。
【0202】
2A.各デバイスにつき1回、その特定のデバイスへの最初の登録が行われる前。この場合、デバイスは、最初の登録より前に1回、RIのTCG資格証明を受信し、次に、デバイスは、RIの資格証明情報をTPM鍵に結び付けることによって、デバイス自らのTPMの下で、この資格証明情報を保護する。デバイスは、後に、この格納されたTCG資格証明の結び付きを解除して、定期的に、またはいくつかのイベント時に、例えば、OCSP CAを調べることによって、デバイスが受信したRIのTCG資格証明が依然として有効であるかどうかを検証する。
【0203】
2B.RIがデバイスに対してRIの完全性ステータスを検証することをデバイスが望むというデバイスからの指示を、スタンドアロンのメッセージとして、または変更されたROAPプロトコルメッセージの一部として、RIが受信するといつでも。
【0204】
2C.定期的に、指定されたセキュリティで保護された時間、例えば、RIが、デバイスに対してRIの完全性ステータスを前回に検証して以来、TRI-PLATFORM-LAST-REPORTが経過するたびに。
【0205】
3.デバイスとCIの間のプラットフォーム完全性検証に関して、前述した機構と同様の機構が、完全性検証プロセスの定期的発生および/またはイベント駆動の発生に関して考慮されることが可能である。また、CIのプラットフォーム完全性のデバイスによる検証の場合、検証は、コンテンツが購入される、またはダウンロードされることが必要とされるのに先立って毎回、実行されることも可能であり、場合により、その逆(すなわち、デバイスのプラットフォーム完全性が、CIに対して検証されなければならない)も同様である。
【0206】
従来技術は、堅牢なDRMのアプリケーションに結合されたTCG技術を使用する「セキュリティで保護された起動」の使用を考慮してきた。そのようなスキームにおいて、プラットフォームのOS、および他の起動関連のコードは、デバイスが起動されるといつでも、完全性検査され、プラットフォーム完全性検査を暗黙に実行してからでないと、いずれのDRMアプリケーションも実行されることが可能でない。本発明は、起動時プラットフォーム完全性検査のより系統立った、明示的な使用とともに、所定の期間に基づく他の時点におけるプラットフォーム完全性検査、ならびにいくつかのイベントの発生時のプラットフォーム完全性検査を提供する。また、本発明は、プラットフォーム完全性検査をデバイスからRIおよびCIにまで一般化する。継続的なプラットフォーム完全性検査は、デバイスが、或る特定の有効なCOを正しく受信しただけで、RIまたはCIが、その時点から将来にわたって無期限に信頼できると見なされるべきことにはならないということのために、有益である。信頼性の定期的な、さらに/またはイベント駆動の継続的検証は、良好な保護機構を提供する。
【0207】
また、デバイスとCIの間の完全性検査の必要性に関して、コンテンツが、ROより前に着信した場合でも、コンテンツは、CIのプラットフォームまたはCIのDRM SWが侵害されると、侵害される可能性がある。例えば、ユーザが、或るファイルをダウンロードしたものと想定されたい。ROが、まだ獲得されていない場合でも、ユーザは、コンテンツを誤ってクリックする可能性があり、あるいはコンテンツに対して有効性検査を実行する可能性がある。コンテンツが、侵害されたている(例えば、コンテンツにウイルスが添付されている)場合、コンテンツは、ROなしでも、デバイスに損害を与える可能性がある。また、デバイスとCIの間のダウンロード前の対話において(例えば、発見段階中に)、侵害されたデバイスが、例えば、コンテンツに添付されたウイルスを、CIを宛先とするメッセージに追加することによって、CIに害を与える可能性がある。さらに、ビジネスの点から、CIは、侵害されたデバイスにコンテンツを送信することを望まず、つまり、例えば、侵害されたデバイスは、許可のない受信者にコンテンツを無料で再配布する可能性がある。このため、デバイスとCIの間の相互プラットフォーム(およびSW)完全性検証は、システム全体を保護することにメリットがある。
【0208】
また、前段のアーキテクチャの説明において概要を述べた中心的な考えを実現する、いくつかの異なる仕方が存在することが可能であることに留意されたい。2つのそのような例が、後段で説明されるが、これらは、前段で説明されるアーキテクチャに基づくより広い概念の説明的な例に過ぎないことに留意されたい。
【0209】
(プラットフォーム完全性検証)
【0210】
図8は、2つのエンティティ間のプラットフォーム完全性検証を実行するための方法800の流れ図である。この2つのエンティティは、デバイスとRI、デバイスとCI、またはRIとCIであることが可能である。方法800は、RE(要求するエンティティ)とTE(ターゲットエンティティ)とを利用し、つまり、ペアのいずれのエンティティ(デバイス、RI、またはCI)が、REであることも可能であることに留意されたい。方法800は、いずれのエンティティがREであり、いずれのエンティティがTEであるかにかかわらず、同一の仕方で動作する。
【0211】
方法800は、REが、TEのプラットフォーム完全性ステータスを報告するよう、TEに要求を送信することから始まる(ステップ802)。この要求に応答して、TEは、TEのTCG資格証明をREに送信する(ステップ804)。これらのTCG資格証明には、例えば、プラットフォーム資格証明、TPM資格証明、または準拠資格証明が含まれることが可能である。次に、REが、TEのTCG資格証明を、これらの資格証明の検証のためにOCSPレスポンダに送信する(ステップ806)。OCSPレスポンダは、TEのTCG資格証明を精査して、検証ステータスをREに報告する(ステップ808)。
【0212】
REが、TE自らのプラットフォーム完全性ステータスを報告するよう、TEに要求を送信する(ステップ810)。TEは、TEのプラットフォーム完全性ステータスを検査し(ステップ812)、プラットフォーム完全性ステータスフラグをREに送信し(ステップ814)、方法は、終了する(ステップ816)。
【0213】
方法800は、ROAPプロトコルの変更が行われなくても(図9に関連して後段で説明される)、ROAPプロトコルの変更が行われても(図10に関連して後段で説明される)、適用されることが可能である。
【0214】
(ROAPプロトコルの変更なしの完全性検証)
【0215】
図9は、ROAPプロトコルとは別個にTCG技術を使用して(すなわち、OCSPレスポンダ/PCA906を利用して)、デバイス902とRI904の間で完全性関連の情報を交換する方法900の流れ図である。方法900では、同一のエンティティ906が、DRM処理のためのPCAとしても、TCG処理のためのOCSPレスポンダとしても示されていることに留意されたい。方法900では、プラットフォーム完全性検証(破線の長方形で示される)は、ROAP4パス登録プロトコルに先立って実行される。登録プロトコルより前にプラットフォーム完全性検証を実行することは、登録プロトコルが、頻繁には実行されず、プラットフォーム完全性検証プロセスが、完了するのにいくらかの時間を要するため、有用であり、つまり、プラットフォーム完全性検証が、各メッセージで実行されたとした場合、システムの全体的な動作は、不必要に減速させられる可能性がある。当業者は、プラットフォーム完全性検証が実行された後、1つだけのデバイスハローメッセージが、信頼されるデバイスを示すので、RIによって受信されるものと想定することができる。複数のデバイスハローメッセージが、同一のデバイスからRIによって受信されたとした場合、このことは、DoS攻撃の表れである可能性がある。また、プラットフォーム完全性検証は、認証プロトコルおよびオブジェクト獲得プロトコルに関連して実行されることも可能である。
【0216】
デバイス902は、RI904を相手に4パス登録プロトコルを開始することに先立って、RI904を相手に、プラットフォーム完全性の相互検証を実行する別の手続きセットを開始する。デバイス902はまず、デバイス902自らのTCG資格証明(例えば、プラットフォーム資格証明、TPM資格証明、準拠資格証明など)、あるいはTCG資格証明を含む、またはTCG資格証明と関係する他の情報を、RI904に送信する(ステップ910)。オプションとして、デバイス902は、RI904自らのプラットフォーム完全性ステータスを検査して、デバイス902に報告するよう、RI904に要求を送信することも行い、この要求には、デバイス資格証明が含められる。
【0217】
RI904は、デバイスのTCG資格証明を検証するようPCA906に要求する(ステップ912)。PCA906は、RIの要求に応答して、デバイスのTCG資格証明に関する情報を送信する(ステップ914)。
【0218】
RI904は、デバイス902のプラットフォーム完全性ステータスフラグを報告するよう、デバイス902に要求する(ステップ916)。また、デバイス902が、ステップ910で、RI904が、RI904のプラットフォーム完全性ステータスを検証して、報告することを要求し、かつRI904が、この要求に応じることを望み、応じることができる場合、RI904は、RI904自らのTCG資格証明、あるいはTCG資格証明を含む、またはTCG資格証明と関係する他の情報を、ステップ916で、デバイス902に送信する。RI904が、この要求に応じることができない、または応じることを望まない場合、RI904は、「応じない」メッセージをデバイスに送信する。RI904は、リソースが限られたRI(すなわち、RIが、この要求に応答するのに利用可能なリソースを十分に有さない)、またはデバイス信頼性検査が不合格であることを含め、いくつかの理由で、この要求に応答しない可能性がある。デバイスは、デバイスがRIに対して有する信用レベルに依存して、このプロトコルを中止することができ、つまり、デバイスが、RIを信頼する場合、デバイスは、RIが、この要求に応答することを拒否した場合でも、このプロトコルを続ける可能性が高い。RI904から、プラットフォームステータスを検査する要求を受信すると、デバイス902は、デバイス902自らのプラットフォーム完全性ステータスを検査する(ステップ918)。
【0219】
デバイス902は、RIのTCG資格証明を検証するよう、PCA906に要求する(ステップ920)。PCA906は、デバイス902からこの要求を受信すると、RIのTCG資格証明に関する情報を戻す(ステップ922)。デバイス902は、デバイス902のプラットフォーム完全性ステータスフラグをRI904に送信する(ステップ924)。RI904が、RI904の完全性ステータスを検査するよう、デバイス902から要求を受信し、RI904が、この要求に応じることを望み、応じることができる場合、RI904は、RI904自らのプラットフォーム完全性を検査する(ステップ926)。次に、RIは、RIのプラットフォーム完全性ステータスフラグをデバイス902に戻す(ステップ928)。RI完全性検査に関するオプションのステップは、任意の順序で実行されることが可能であり、つまり、それらのステップは、図9に示されるとおりにデバイス完全性検査と絡み合わされなくてもよい。さらに、RIは、RI自らの完全性検査を開始することができる。また、RIが、可能な理由のいずれかで、RI自らのTCG資格証明情報で要求に完全には応答することを拒否する場合、RIは、例えば、ステップ922で、適切な仕方で、そのような事実をデバイスに示すことができる。
【0220】
方法900は、デバイス902およびRI904が、相互プラットフォーム完全性検証を実現することを可能にする。そのような検証後、デバイスは、ROAP登録プロトコルを開始することができる。図9に示される登録プロトコルのステップ(ステップ930〜940)は、前述した方法200のステップ210〜220と同一である。また、これらの手続きは、周期的な間隔でトリガされる、または繰り返されることが可能であることにも留意されたい。
【0221】
(ROAP登録プロトコルの変更を伴う完全性検証)
【0222】
図10は、別の例示的な実施形態において、デバイス1002とRI1004が、OCSPレスポンダ/PCA1006のサービスをやはり利用して、完全性関連の情報を交換する方法1000を示す。方法1000では、ROAP登録プロトコルの既存のデバイスハローメッセージおよびRIハローメッセージは、TCG資格証明と、プラットフォーム完全性検証を求める、相手への要求をともに伝えるように変更される。
【0223】
デバイス1002は、変更されたデバイスハローメッセージをRI1004に送信し(ステップ1010)、このメッセージは、デバイスTCG資格証明と、RI1004のプラットフォーム完全性を報告するようにという、RI1004へのオプションの要求とを含む。RI1004は、これらのデバイス資格証明を、検証ためにPCA1006に転送する(ステップ1012)。次に、PCA1006は、デバイスTCG資格証明をRI1004に戻す(ステップ1014)。RI1004は、変更されたRIハローメッセージでデバイス1002に応答し(ステップ1016)、このメッセージは、RIのTCG資格証明をオプションとして含む。
【0224】
次に、デバイス1002は、オプションとして、RIのTCG資格証明を検査するようPCA1006に要求を送信する(ステップ1018)。PCA1006はRIの資格証明を検査し、結果をデバイス1002に報告する(ステップ1020)。デバイス1002は、デバイス1002自らの完全性ステータスを検査し(ステップ1022)、完全性ステータスをRI1004に報告する(ステップ1024)。
【0225】
デバイス1002が、RI1004が、RI1004の完全性ステータスを報告することを要求した場合、RI1004は、プラットフォーム完全性検査を実行し(ステップ1026)、完全性ステータス、例えば、RI1004の信頼状態フラグを、デバイス1002に送り返す(ステップ1028)。ステップ1030〜1036は、ROAP登録プロトコルの図2に示されるステップ214〜220と同一である。
【0226】
(DRMソフトウェアの完全性を検査すること)
【0227】
図11は、DRMエンティティの任意のペアの間でDRM SW(例えば、デバイスに常駐するDRMユーザエージェントSW、あるいはRIまたはCIに常駐するDRM SW)の完全性を検査するための方法1100の流れ図である。RE(要求するエンティティ)が、DRM SW完全性検査を実行するよう、TE(ターゲットエンティティ)に要求を送信する(ステップ1102)。TEは、TEのDRM SW完全性を検査し(ステップ1104)、DRM SW完全性ステータスフラグをREに送信し(ステップ1106)、方法は、終了する(ステップ1108)。TEが、デバイスである場合、デバイスドライバおよびメディアプレーヤSWの完全性が、DRM SWの完全性とは別個に検査されることが、これら2つの構成要素が、デバイス上に別々に存在する場合、可能であることに留意されたい。
【0228】
方法1100は、REが、TEからDRM SW完全性検査を獲得することだけに関する。相互DRM SW完全性検査を実行するのに、方法1100は、REからTEに1回、次に、TEからREに1回(REとTEが役割を交替して)の、2回、実行される必要がある。相互DRM SW完全性検査中、これらの要求は、絡み合わされる(図12に示されるとおり)ことも、図11に示されるとおり、分離されることも可能である。この方法の動作は、相互DRM SW完全性検査が実行されている場合、変化しない。
【0229】
OMA DRM2.0仕様は、そのような想定が、どのようにして有効に実施されることが可能であるかを示唆することなしに、DRMユーザエージェントSW(または本発明において使用される用語では、デバイスDRM SW)、およびRI(またはRIのDRM SW)が、暗黙に信頼されることが可能であるものと想定する。このため、OMA DRM2.0仕様における認証プロトコルは、既に信用できると考えられるエンティティ間の実際の認証手続きだけしか規定しない。明白な理由で、この暗黙のSW信頼想定は、実際には、それらの想定を実施し、検証する実際のステップなしに、自動的に想定されることは可能でない。このセクションで説明される方法は、そのような具体的なステップにかかわる。
【0230】
図12は、ROAP RO獲得プロトコルに関連してDRM SW検査を適用するための方法1200の流れ図である。この方法1200は、デバイス1202、RI1204、およびOCSPレスポンダ/PCA1206を利用する。第1に、PCA1206は、デバイス1202およびRI1204と通信して、プラットフォーム完全性検査およびROAP登録プロトコルを実行する(ステップ1210)。デバイス1202とRI1204が、相互プラットフォーム完全性検査、単方向DRM SW完全性検査、または相互DRM SW完全性検査を実行する(ステップ1212)。
【0231】
RI1204が、デバイスのDRM UA(ユーザエージェント)SW完全性を検査して、報告するよう、デバイス1202に要求を送信する(ステップ1214)。デバイス1202が、デバイス1202の最新のDRM UA SW完全性を検査する(ステップ1216)。デバイス1202は、オプションとして、RIのDRM SW完全性を検査して、報告するよう、RI1204に要求を送信する(ステップ1218)。要求された場合、RI1204は、RI1204の最新のDRM SW完全性を検査する(ステップ1220)。デバイス1202が、デバイスDRM SW完全性ステータスフラグをRI1204に送信する(ステップ1222)。前に要求されている場合、RI1204が、RI DRM SW完全性ステータスフラグをデバイス1202に送信する(ステップ1224)。オプションのRI完全性検査のステップは、任意の順序で実行されることが可能であり、図12に示されるとおりにデバイス完全性検査と絡み合わされる必要はないことに留意されたい。
【0232】
方法1200は、例示されるデバイス/RI対話の代わりに、デバイスとCIの間の相互DRM SW完全性検証に関して一般化されることが可能であることに留意されたい。ステップ1210〜1224が完了すると、デバイス1202は、例えば、図3に関連して前述したステップ310および312と同一であるステップ1226および1228における2パスRO獲得プロトコルを開始することができる。方法1200は、RO獲得プロトコルに関連して図示されるものの、方法1200は、他の任意のROAPプロトコルに関連して使用されることが可能であり、ただし、方法1200に関連するオーバヘッドを最小限に抑えるのに、方法1200は、任意の所与の時点で、ROAPプロトコルの適切に選択されたサブセットだけしか伴わずに実行されることが可能であることにさらに留意されたい。実際的なOMA DRMシステム実施形態に関して、前述した、提案されるプラットフォーム完全性検証手続きおよび/またはDRM SW完全性検証手続きのための条件またはトリガ機構のいくつかには、以下が含まれることが可能である。すなわち、
【0233】
1.デバイスDRM SW完全性検証手続きは、以下の1つまたは複数によってトリガされることが可能である。
【0234】
1A.デバイスが、新たな2パスROAP登録プロトコル、2パスドメイン参加プロトコル、または2パスドメイン退去プロトコルを開始することを要望する前。
【0235】
1B.定期的に、指定された時間、例えば、デバイスが、同一のRIに対して2パスROAP登録プロトコル、2パスドメイン参加プロトコル、または2パスドメイン退去プロトコルを前回に完了して以来、TDEV-DRM-LAST-ROAPが経過するたびに。
【0236】
1C.定期的に、指定された時間、例えば、デバイスが、前回に、デバイスのDRM SW完全性ステータスを検証して、同一のRIに報告して以来、TDEV-DRM-LAST-REPORTが経過するたびに。
【0237】
1D.デバイスが、デバイスのDRM SWを更新するといつでも。
【0238】
1E.プラットフォームSWが、更新される、または変更されるといつでも。
【0239】
2.RI DRM完全性検証手続きは、以下の1つまたは複数によって実行されることが可能である。
【0240】
2A.RIがデバイスに対してRIのDRM SW完全性ステータスを検証することをデバイスが望むというデバイスからの指示を、スタンドアロンのメッセージとして、または変更されたROAPプロトコルメッセージの一部として、RIが受信するといつでも。
【0241】
2B.定期的に、指定された時間、例えば、RIが、前回に、RIのDRM SW完全性ステータスを検証して、デバイスに報告して以来、TRI-DRM-LAST-REPORTが経過するたびに。
【0242】
2C.RIが、RIのDRM SWを更新するといつでも。
【0243】
2D.ユーザが、ストリーミングコンテンツの場合のように、コンテンツを頻繁に獲得している場合において、デバイスがRO要求を送信するのに先立って毎回。
【0244】
デバイスとCIの間のプラットフォーム完全性検証に関して、前述した機構と同様の機構が、DRM SW完全性検証プロセスの定期的発生および/またはイベント駆動の発生に関して考慮されることが可能である。
【0245】
DRMプラットフォーム検証およびDRM SW検証のための提案される方法は、互いに無関係に実行されることが可能であるが、これらの検証手続きが、手続きのグループの一部として組み合わされることが可能であることも企図される。そのような実施形態では、DRMプラットフォーム検証ステップは、DRM SW検証ステップの前提条件と考えられる。例えば、デバイスとRIの間の完全性検証のために、デバイスとRIはまず、前述したとおり、DRMプラットフォーム検証手続きを実行することによって、互いのプラットフォーム全体に対する信頼を確立する。トリガ機構は、一般的なプラットフォーム検証トリガ条件を含む。次に、DRM SW検証トリガに関する条件が生じると、DRM SW検証手続きが、その後に続く。両方のタイプの検証手続きは、それぞれのトリガ条件が満たされると、実行されることに留意されたい。しかし、DRM SW検証ステップは、DRMプラットフォーム検証ステップが成功して完了することに追従させられ、すなわち、デバイスとRIの間でDRMプラットフォーム検証が不合格である場合、DRM SW検証におけるさらなる処理、ならびに実際のDRM ROAP処理および使用関連の処理は、失敗する。
【0246】
(密封署名および結び付け)
【0247】
ROAPプロトコルの完全性を保護するOMA DRM2.0仕様の既存の機構は、ROAPメッセージのいくつかに、ただし、すべてにではなく、デジタル署名(またはメッセージ完全性検査)を含めることに限られる。ROAPプロトコルが、セキュリティで保護されたDRM処理実施に中心的な重要性を有することから、ROAPプロトコルにおいて使用され、交換される情報の完全性を保護し、絶えず検証することが重要である。
【0248】
したがって、本発明の代替の実施形態では、DRMデバイスとRIの間の信頼できる認証および完全性検証に中心的な情報が、(1)TCG技術を使用して安全に格納され、さらに(2)他方の側に伝送されるのに先立って、または情報が格納される側において処理のために使用されるのに先立って、事前検証されることが可能である、ROAPプロトコルの完全性を強化する方法が、開示される。
【0249】
この方法には、密封署名(すなわち、ターゲット情報を対称的に暗号化し、次に、対称鍵に加え、プラットフォームまたは特定のSW構成要素のその時点で最新の完全性ステータスを示すPCR値のセットに非対称的に署名する)、および結び付け(秘密解読鍵がTPMなどの、保護されたモジュールの中に保持された鍵を使用して、ターゲット情報を非対称的に暗号化する)というTCG技術を使用する2つの基本的な手続きがかかわる。密封署名は、保護されたPCR値によって示される、デバイスDRMユーザエージェントSWの信頼状態に、非対称暗号化、デジタル署名、および結び付けによってもたらされる最高レベルの情報セキュリティを与える。結び付けは、解読鍵がTPM内部で保護される場合に、非対称暗号化を使用する高いレベルの保護を与える。
【0250】
以下の体系的な原理は、密封署名、および結び付けを使用して、ROAPメッセージの中で使用される情報の機密性と完全性をともに保護して、ROAPプロトコル自体の完全性の強度を間接的に高める。以下の説明において、デバイスとRI(またはこの特定のデバイスを扱うRIの部分)はともに、TPMを備えており、完全なTPM機能をサポートするものと想定される。
【0251】
デバイスとRIはそれぞれ、デバイスまたはRIが存在する信頼されるプラットフォームに、ROAP処理と関係する或る情報を暗号上、結び付け、セキュリティで保護された仕方で格納する2つのストレージ鍵のセットを取っておき、使用することができる。デバイスに関して、これらの鍵は、K_DEV_BIND_AおよびK_DEV_BIND_Bである。RIに関して、これらの鍵は、K_RI_BIND_AおよびK_RI_BIND_Bである。これらの鍵は、TPMによって保持される非対称鍵(すなわち、暗号化は、公開鍵を使用して行われ、解読は、TPM内で保護された秘密鍵を使用して行われる)である。
【0252】
デバイスとRIはそれぞれ、DRM処理のために単一のPCR、またはPCRのセットを使用する。また、デバイスとRIは、AIK(構成証明アイデンティティ鍵)を取っておき、信頼されるプラットフォーム、およびそのプラットフォームの特定のPCR値に、ROAP処理と関係する或る情報を密封署名するのに使用する。TCG AIK鍵は、PCR値に署名するためだけに使用されることに留意されたい。デバイスに関して、デバイスのAIKは、K_DEV_AIKであり、RIに関して、RIのAIKは、K_RI_AIKである。また、密封署名は、ターゲットデータの暗号化操作のための非対称ストレージ鍵を要求する。このため、デバイスとRIはそれぞれ、この目的でストレージ鍵を取っておき、使用する。デバイスに関するストレージ鍵は、K_DEV_STO_SEALであり、RIに関するストレージ鍵は、K_RI_STO_SEALである。
【0253】
この方法は、ROAP処理にかかわる様々な情報要素を格納することの強度を高めるように、密封署名および結び付けと、機密性および完全性を保護する追加の対策との組合せを使用する。例えば、図13は、TPM密封署名操作およびTPM結び付け操作を使用して、4パスROAP登録プロトコルを含む様々なメッセージの中の情報の機密性および完全性が保護される方法1300の流れ図である。方法1300では、デバイス1302とRI1304がそれぞれ、4パス登録プロトコルの過程においてそれぞれが送信する(他方の側に)または受信する(他方の側から)ストレージ鍵の2つのセットを使用して、ROAP関連の情報の選択的なセットに密封署名し、情報を結び付ける。
【0254】
デバイス1302がまず、暗号化鍵K_DEV_STO_SEALおよびデバイス特有のAIK、K_DEV_AIKを使用して、デバイスID情報要素(OMA DRMの場合、OMA DRM公開鍵のSHA−1ハッシュである)に密封署名する。この情報は、ストレージ鍵K_DEV_BIND_Aを使用して、デバイスハローメッセージ向けの他の情報に結び付けられる(非対称暗号化を使用して)(ステップ1310)。次に、このデバイスハローメッセージが、デバイス1302からRI1304に送信される(ステップ1312)。
【0255】
デバイスIDなどの情報に密封署名すること、およびデバイスハローメッセージを含む他の情報を結び付けることにより、デバイス1302は、デバイス1302が、デバイス1302の保護されたストレージから以前に密封署名され、結び付けられた情報を回復し(すなわち、密封署名解除して、結び付け解除し)、それらの情報を、DRM SWが使用している可能性があるような情報要素の現在の値と比較し、これらの現在の値の真正性および完全性を検証すると、その場合に限って、デバイスハローメッセージが伝送されるというポリシーを定めることもできる。このシナリオにおける、密封署名されるべき情報要素対結び付けられるべき情報要素の選択は、例として与えられているに過ぎないことに留意されたい。他の情報要素は、本発明の動作を実行することなしに、様々な組合せで密封署名され、結び付けられることが可能である。他の組合せは、システム時間、メッセージの中の任意の情報要素、アルゴリズム、およびナンスなどのアイテムから導き出されることが可能である。ナンスをセキュリティで保護する1つの理由は、一部の乱数発生器、特に有害な侵害を受けている可能性がある乱数発生器は、同一のパターンを繰り返して、同一の数を乱数発生器の出力として、容認できない短い周期で生成する可能性があるので、ナンスが本当にランダムであるかどうかを判定するためである。
【0256】
RI1304は、デバイスハローメッセージの受信後、RI1304の結び付け鍵、KI_RI_BIND_Aを使用して、デバイスハローメッセージの中に含まれる情報を結び付ける(ステップ1314)。このステップは、RI1304がデバイス1302から受信した鍵情報の、セキュリティで保護された、完全性保護された格納を可能にする。代替として、RI1304は、デバイスハローメッセージからデバイスID(または他の任意の情報要素)を抽出し、AIK、K_RI_AIK、および暗号化鍵K_RI_STO_SEALを別々に使用して、その情報要素に密封署名することもできる。
【0257】
RI1304が、暗号化鍵K_RI_STO_SEALおよびAIK、K_RI_AIKを使用して、RI IDおよびRI URL情報要素に密封署名する(ステップ1316)。また、RI1304は、ストレージ鍵K_RI_BIND_Aを使用して、RI1304のRIハローメッセージの中に含まれるその他の情報を結び付けることも行う(ステップ1316)。次に、RI1304は、RIハローメッセージをデバイス1302に送信する(ステップ1318)。
【0258】
RI1304は、RI1304がまず、保護されたストレージから以前に密封署名され、結び付けられた情報を回復し(すなわち、密封署名解除して、結び付け解除し)、それらの情報を、RI DRM SWが使用している可能性があるような情報要素の現在の値と比較し、これらの現在の値の真正性および完全性を検証すると、その場合に限って、デバイス1302にRIハローメッセージを送信する。
【0259】
デバイス1302は、RIハローメッセージを受信すると、第2の結び付け鍵、すなわち、K_DEV_BIND_Bを使用して、RIハローメッセージの中に含まれる情報を結び付ける(ステップ1320)。このステップは、デバイスがRI1304から受信した鍵情報のセキュリティで保護された、完全性保護された格納を可能にする。代替として、デバイス1302は、受信されたRIハローメッセージから、選択された情報要素(RI IDおよび/またはRI URLなどの)を抽出し、AIK、K_DEV_AIKおよび暗号鍵K_DEV_STO_SEALを使用して、これらの情報要素に密封署名する一方で、K_DEV_BIND_Bを使用して、RIハローメッセージの中で受信された残りの情報を単に結び付けることも可能である。
【0260】
デバイス1302が、K_DEV_AIKおよびK_DEV_STO_SEALを使用して、証明書チェーン、DCFハッシュ、および要求時間に密封署名する(ステップ1322)。次に、デバイス1302は、K_DEV_BIND_Aを使用して、登録要求メッセージ向けのその他の情報を結び付ける(ステップ1322)。次に、デバイス1302は、この登録要求メッセージをRI1304に送信する(ステップ1324)。デバイス1302は、デバイス1302が、以前に密封署名され、結び付けられた情報を回復し(すなわち、密封署名解除して、結び付け解除し)、回復された値を、DRM SWメモリの中で使用される現在の一時的な値と比較し、これらの現在の値の真正性および完全性を検証すると、その場合に限って、この登録要求メッセージを送信する。この登録要求メッセージを受信すると、RI1304は、結び付け鍵、K_RI_BIND_Bを使用して、登録要求メッセージからの情報を結び付ける(ステップ1326)。
【0261】
RI1304が、KI_RI_AIKおよびK_RI_STO_SEALを使用して、鍵、証明書チェーン、およびROに密封署名する(ステップ1328)。次に、RI1304は、密封署名された鍵、証明書チェーン、およびROを、結び付け鍵K_RI_BIND_Aを使用して、登録応答メッセージに含められるべき他の情報に結び付ける(ステップ1328)。次に、RI1304は、この登録応答メッセージをデバイス1302に送信する(ステップ1330)。RI1304は、RIが、以前に密封署名され、結び付けられた情報を回復し(すなわち、密封署名解除して、結び付け解除し)、これらの回復された値を、DRM SWメモリの中で使用される現在の一時的な値と比較し、これらの現在の値の真正性および完全性を検証した場合に限って、この登録応答メッセージを送信する。登録応答メッセージを受信すると、デバイス1302は、登録応答メッセージからのRIによって生成された情報を、結び付け鍵K_DEV_BIND_Bを使用して結び付ける(ステップ1332)。
【0262】
この密封署名および結び付けは、他の任意のROAPプロトコルで使用されることが可能であることに留意されたい。前述した方法1300は、例示的であり、方法1300の原理は、他の任意のROAPプロトコルにも等しく適用されることが可能である。
【0263】
OMA DRM ROAPメッセージ交換中に獲得されたデータは、このデータを密封した、またはこのデータに密封署名したエンティティが、そのエンティティのOSまたはDRM SWを更新した場合、密封解除され、新たな構成PCR値に再密封される必要がある。そのような事態が生じると、或る特定の状態(または、均等なこととして、或る特定のPCR値セット)に密封されていた、または密封署名されていたDRM ROAP関連のデータが、最初に、密封解除され、次に、更新されたプラットフォームOSの最新の状態に再密封されなければならない。この手続き要件に対処する既存の技術が、従来技術に存在し、そのような手続きは、本明細書で提案される密封または密封署名を使用して格納された任意のDRM ROAP関連のデータの適切な密封解除および再密封を確実にするように行われるものと想定される。
【0264】
1つのさらなる機能強化は、送信するデバイスのTCG能力を示すフィールドを、既存のROAPメッセージフォーマットに追加することである。このTCG能力フィールドは、受信するエンティティが、TCG関連の情報および手続きをサポートすることができるかどうかの早期判定を行うことによって、レガシーデバイスとの相互運用性を高めることに役立つことが可能である。
【0265】
(デバイスハローメッセージの変更、およびこの変更の導出)
【0266】
第1の変更は、デバイスのTPC能力の標識である、新たなDTCI(デバイスTPM能力指示)を、デバイスハローメッセージの既存の拡張子パラメータの新たな要素の中に追加すること、または代替として、好ましくは、このDCTIを、デバイスハローメッセージのヘッダの中の新たな第1のパラメータとして追加することである。DTCIは、1ビット(デバイスTPMの欠如、または存在を示す)、または数ビット(デバイスのTPM能力に関して、より細分性の高い情報を示す)であることが可能である。DTCIは、新たなパラメータとして挿入される場合、好ましくは、デバイスIDパラメータより前に、最初のパラメータとして挿入されて、他のパラメータに先立って、デバイスがいくつかのTPC能力を有することをRIが知り、DTCIを利用して、後のパラメータ(例えば、デバイスID)からの情報を処理することができるようにされなければならない。DTCI情報の利点は、この情報により、RIが、ROAPプロトコルの残りの部分におけるデバイスとのさらなる対話において、デバイスの信頼性を評価することが可能になることである。
【0267】
第2の変更は、デバイス特有のTCG EK資格証明またはTCG AIK資格証明を使用して、DRMデバイスIDをハッシングし、導き出すことである。この変更の利点は、EK資格証明および/またはAIK資格証明が、デバイス内のTPMによって強固に保護されており、このため、これらの資格証明のいずれかからDRMデバイスIDを導き出すことにより、DRMデバイスID情報の完全性が強化されることである。
【0268】
第3の変更は、署名までの、署名を除くデバイスハローメッセージに、RIによって検証されることが意図される、デバイスのAIK秘密鍵を使用して署名が行われる場合に、新たな署名パラメータを追加することである。この変更の利点は、デバイスとRIの間の最初の対話から、デバイスTPM能力の完全性を保護することである。TPMによって強固に保護される、デバイスのAIK秘密鍵の使用により、署名動作の完全性が強化される。
【0269】
テーブル12および13は、変更されたデバイスハローメッセージに関する可能な2つのフォーマットを示す。テーブル12は、最初のパラメータとしてDTCIビットを有するメッセージのフォーマットを示す。テーブル13は、DTCIが、既存の拡張子パラメータの新たな要素である、デバイスハローメッセージのフォーマットを示す。
【0270】
【表12】
【0271】
【表13】
【0272】
(RIハローメッセージの変更、およびこの変更の導出)
【0273】
第1の変更は、RIのTPM能力の標識である新たなRTCI(RI TPM能力指示)を、RIハローメッセージの既存の拡張子パラメータの新たな要素として追加すること、または代替として、好ましくは、このRTCIを、RIハローメッセージのヘッダの中の新たな第1のパラメータとして追加することである。この変更の利点は、この変更により、デバイスが、RTCI情報を使用して、RIの信頼性を評価し、さらに、ROAPプロトコル手続きの残りの部分におけるRIとのさらなる対話において、そのような情報を利用することが可能になることである。
【0274】
第2の変更は、RI TPMを使用して、セッションIDを表す擬似乱数を提供することである。この変更の利点は、TPMが、セキュリティで強固に保護されたハードウェアベースの擬似乱数発生器を提供することである。TPMを使用して、セッションIDとして使用される擬似乱数を生成することにより、プロトコルのセキュリティが強化される。
【0275】
第3の変更は、RI TCG EK資格証明、またはRIのTPMに属するTCG AIK資格証明を使用して、RI IDを導き出すことである。この変更の利点は、EK資格証明および/またはAIK資格証明が、デバイス内のTPMによって強固に保護され、これらの資格証明のいずれかからDRMデバイスIDを導き出すことにより、DRMデバイスID情報の完全性が強化されることである。
【0276】
第4の変更は、RI TPMを使用して、RIナンスを提供することである。この変更の利点は、TPMが、セキュリティで強固に保護されたハードウェアベースの擬似乱数発生器を提供することである。TPMを使用して、RIナンスを生成することにより、RIハローメッセージの中で使用されるナンスの完全性が強化される。
【0277】
第5の変更は、デバイスによって信頼されるRIアンカの中にデバイスTCG資格証明を含めることである。デバイスのTCG資格証明には、EK資格証明、AIK資格証明、プラットフォーム資格証明、ならびにRIが、信頼されるTCG CAから事前獲得した準拠資格証明が含まれる。この変更の利点は、デバイスがRIハローメッセージに対して有することが可能な信頼を強化することである。
【0278】
第6の変更は、RIのAIK公開鍵が、RIハローメッセージの一部としてデバイスにあらかじめ配布されている場合に、RIのAIK秘密鍵を使用して署名された、署名までの、署名を除くRIハローメッセージの署名を追加することである。この変更の利点は、RIとデバイスの間の最初の対話から、RTCIの完全性を保護することである。RIのTPMによって強固なセキュリティで保護されたRIのAIK秘密鍵を使用することにより、署名動作の完全性が強化される。
【0279】
テーブル14および15は、変更されたRIハローメッセージに関する可能な2つのフォーマットを示す。テーブル14は、最初のパラメータとしてRTCIビットを有するRIハローメッセージのフォーマットを示す。テーブル15は、RTCIが、既存の拡張子パラメータの新たな要素である場合の、RIハローメッセージのフォーマットを示す。
【0280】
【表14】
【0281】
【表15】
【0282】
(登録要求メッセージの変更、およびこの変更の導出)
【0283】
第1の変更は、デバイスTPMを使用して、デバイスナンスを提供することである。この変更の利点は、TPMが、ナンスに使用するのに適したセキュリティで保護された、信頼できる擬似乱数を提供することである。
【0284】
第2の変更は、デバイスTCG資格証明を証明書チェーンの中に含めることである。デバイスTCG資格証明を含めることは、既存のOMA DRM2.0デバイス資格証明の代わりであること、または既存のOMA DRM2.0デバイス資格証明に加えてであることが可能である。TCG資格証明(EK資格証明、AIK資格証明、プラットフォーム資格証明、または準拠資格証明)を含めることの利点は、デバイスの信頼性を高めることである。
【0285】
第3の変更は、RIによって信頼されるTCG CAのリストを、信頼RIアンカ要素の中に含めることである。RIによって信頼されるTCG CAを含めることは、既存のOMA DRM2.0 RI信頼アンカ要素リストの代わりであること、または既存のOMA DRM2.0 RI信頼アンカ要素リストに加えてであることが可能である。RIによって信頼されるTCG CAのリストを含めることの利点は、デバイスの信頼性を高めることである。
【0286】
第4の変更は、デバイスTPMについての情報を、拡張子パラメータのデバイス詳細要素の中に含めることである。この情報を含めることの利点は、RIに対するデバイスについての信頼性を高めることである。
【0287】
第5の変更は、変更されたデバイスハローメッセージに署名するのに使用されたデバイスAIKを使用して署名に署名することである。この変更の利点は、デバイスAIKの強固に保護された性質のため、デバイス、および登録要求メッセージの信頼性を高めることである。
【0288】
テーブル16は、変更された登録要求メッセージに関するフォーマットを示す。
【0289】
【表16】
【0290】
(登録応答メッセージの変更、およびこの変更の導出)
【0291】
第1の変更は、RI TPMを使用して、セッションIDを表す擬似乱数を提供することである。この変更の利点は、TPMが、セキュリティで強固に保護されたハードウェアベースの擬似乱数発生器を提供することである。TPMを使用して、セッションIDとして使用される擬似乱数を生成することにより、プロトコルのセキュリティが強化される。
【0292】
第2の変更は、RI TCG EK資格証明、またはRIのTPMに属するTCG AIK資格証明を使用して、RI IDを導き出すことである。この変更の利点は、EK資格証明および/またはAIK資格証明が、デバイス内のTPMによって強固に保護され、これらの資格証明のいずれかからDRMデバイスIDを導き出すことにより、DRMデバイスID情報の完全性が強化されることである。
【0293】
第3の変更は、RI TPMを使用して、RIナンスを提供することである。この変更の利点は、RI TPMが、ナンスとして使用するのに適したセキュリティで保護された、信頼できる擬似乱数を提供することである。
【0294】
第4の変更は、デバイスによって信頼されるTCG CAのリストを、信頼されるデバイスアンカ要素の中に含めることである。デバイスによって信頼されるTCG CAを含めることは、既存のOMA DRM2.0信頼デバイスアンカ要素リストの代わりであること、または既存のOMA DRM2.0信頼デバイスアンカ要素リストに加えてであることが可能である。デバイスによって信頼されるTCG CAのリストを含めることの利点は、RIの信頼性を高めることである。
【0295】
第5の変更は、変更されたRIハローメッセージに署名するのに使用されたRI AIKを使用して署名に署名することである。この変更の利点は、RI AIKの強固に保護された性質のため、RI、および登録応答メッセージの信頼性を高めることである。
【0296】
テーブル17は、変更された登録応答メッセージに関するフォーマットを示す。
【0297】
【表17】
【0298】
(RO要求メッセージの変更、およびこの変更の導出)
【0299】
第1の変更は、TPMを使用して、デバイスIDとして使用すべき、選択されたTCG資格証明(EK資格証明、AIK資格証明、プラットフォーム資格証明、または準拠資格証明)のSHA−1ハッシュを作成する。この変更の利点は、資格証明が、TPMによって強固に保護され、このため、これらの資格証明のいずれかからデバイスIDを導き出すことにより、デバイスID情報の完全性が強化されることである。
【0300】
第2の変更は、デバイスTPMを使用して、デバイスナンスを生成することである。この変更の利点は、TPMによって生成されるナンスが、TPMの保護された擬似乱数発生能力のために、セキュリティで保護されていることである。
【0301】
第3の変更は、TCG資格証明を証明書チェーンの中に含めることである。TCG資格証明を含めることは、既存のOMA DRM2.0デバイス資格証明の代わりであること、または既存のOMA DRM2.0デバイス資格証明に加えてであることが可能である。TCG資格証明を含めることの利点は、デバイスの信頼性を高めることである。
【0302】
第4の変更は、拡張子パラメータの中のデバイスAIKを使用して、オプションのDCFハッシュに署名することである。この変更の利点は、デバイスAIKが強固に保護されており、DCF署名が、より強固なセキュリティで保護されるようにすることである。
【0303】
第5の変更は、正常に応答があった最新の登録要求メッセージに署名するのに使用されたデバイスAIKを使用して、RO要求メッセージに署名することである。この変更の利点は、RI AIKの強固に保護された性質のため、RI、およびRO要求メッセージの信頼性を高めることである。
【0304】
テーブル18は、変更されたRO要求メッセージのフォーマットを示す。
【0305】
【表18】
【0306】
(RO応答メッセージの変更、およびこの変更の導出)
【0307】
1つの変更は、RIのTPMを使用して、成功した最新の登録応答メッセージに署名する際に使用されたのと同一のRI TPM AIKを使用して、RO応答メッセージに署名することである。この変更の利点は、RI AIKの強固に保護された性質のため、RI、およびRO応答メッセージの信頼性を高めることである。
【0308】
テーブル19は、変更されたRO要求メッセージのフォーマットを示す。
【0309】
【表19】
【0310】
本発明の特徴および要素は、特定の組合せで、好ましい実施形態において説明されるものの、各フィーチャ、または各要素は、単独で(好ましい実施形態のその他のフィーチャ、およびその他の要素なしに)、あるいは本発明の他のフィーチャ、および他の要素を伴って、または伴わずに様々な組合せで使用されることが可能である。
【0311】
(実施形態)
【0312】
1.RE(要求するエンティティ)と、TE(ターゲットエンティティ)との間でプラットフォーム完全性検査を実行するための方法であって、TEのTCG(Trusted Computing Group)資格証明を報告するようTEに要求する要求を、REからTEに送信するステップと、TEからREにTEのTCG資格証明を送信するステップと、TEのTCG資格証明を、検証のために、REからOCSP(オンライン証明書ステータスプロトコル)レスポンダに転送するステップと、TEのTCG資格証明の検証ステータスを、OCSPレスポンダからREに報告するステップと、TE自らのプラットフォーム完全性ステータスを報告するようTEに要求する要求を、REからTEに送信するステップと、TEのプラットフォーム完全性ステータスを検査するステップと、TEからREにプラットフォーム完全性ステータス標識を送信するステップとを含む方法。
【0313】
2.REは、RI(権利発行者)であり、TEは、デバイスである実施形態1による方法。
【0314】
3.デバイスが、方法を開始するトリガをRIに送信することによって、デバイスが、RIを相手にROAP(権利オブジェクト獲得プロトコル)登録プロトコルを開始するのに先立って実行される実施形態2による方法。
【0315】
4.デバイスが、RIに最も新しく登録してから経過した時間に基づいて、定期的に実行される実施形態2または3による方法。
【0316】
5.デバイスが、デバイスのプラットフォーム完全性ステータスをRIに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態2から4のいずれかによる方法。
【0317】
6.REは、デバイスであり、TEは、RI(権利発行者)である実施形態1による方法。
【0318】
7.RIが、RIのプラットフォーム完全性ステータスをデバイスに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態6による方法。
【0319】
8.REは、CI(コンテンツ発行者)であり、TEは、デバイスである実施形態1による方法。
【0320】
9.デバイスが、デバイスのプラットフォーム完全性ステータスをCIに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態8による方法。
【0321】
10.デバイスが、CIからコンテンツを購入すると、実行される実施形態8または9による方法。
【0322】
11.REは、デバイスであり、TEは、CI(コンテンツ発行者)である実施形態1による方法。
【0323】
12.CIが、CIのプラットフォーム完全性ステータスをデバイスに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態11による方法。
【0324】
13.デバイスが、CIからコンテンツを購入すると、実行される実施形態11または12による方法。
【0325】
14.ROAP(権利オブジェクト獲得プロトコル)プロセスの一環として実行される実施形態1による方法。
【0326】
15.ROAPプロセスに先立って実行される実施形態14による方法。
【0327】
16.ROAPプロセスは、ROAPプロセスの一環として方法を組み込むように変更される実施形態14または15による方法。
【0328】
17.RE(要求するエンティティ)と、TE(ターゲットエンティティ)との間でDRM(デジタル権利管理)ソフトウェア完全性検査を実行するための方法であって、TEがDRMソフトウェア完全性検査を実行することを要求する要求を、REからTEに送信するステップと、TEによってDRMソフトウェア完全性を検査するステップと、TEからREにDRMソフトウェア完全性ステータス標識を送信するステップとを含む方法。
【0329】
18.REは、RI(権利発行者)であり、TEは、デバイスである実施形態17による方法。
【0330】
19.デバイスは、デバイスが、ROAP(権利オブジェクト獲得プロトコル)プロセスを開始するのに先立って、方法を開始するトリガをRIに送信する実施形態18による方法。
【0331】
20.ROAPプロセスは、2パス登録、2パスドメイン参加、および2パスドメイン退去から成るグループから選択される実施形態19による方法。
【0332】
21.デバイスが、RIを相手にROAP(権利オブジェクト獲得プロトコル)プロセスを完了した後、定期的に実行される実施形態19または20による方法。
【0333】
22.ROAPプロセスは、2パス登録、2パスドメイン参加、および2パスドメイン退去から成るグループから選択される実施形態19から21のいずれかによる方法。
【0334】
23.デバイスが、デバイスのDRMソフトウェア完全性ステータスをRIに検証し、報告した後、定期的に実行される実施形態18から22のいずれかによる方法。
【0335】
24.デバイスが、デバイスのDRMソフトウェアを更新した後、実行される実施形態18から23のいずれかによる方法。
【0336】
25.RIは、デバイス上のメディアプレーヤに対してDRMソフトウェア完全性検査を実行するよう、デバイスに要求する実施形態18から24のいずれかによる方法。
【0337】
26.REは、デバイスであり、TEは、RI(権利発行者)である実施形態17による方法。
【0338】
27.デバイスによって開始されると、実行される実施形態26による方法。
【0339】
28.スタンドアロンのプロセスである実施形態26または27による方法。
【0340】
29.変更された権利オブジェクト獲得プロトコルプロセスの一環である実施形態26から28のいずれかによる方法。
【0341】
30.RIが、RIのDRMソフトウェア完全性ステータスをデバイスに検証し、報告した後、定期的に実行される実施形態26から29のいずれかによる方法。
【0342】
31.RIが、RIのDRMソフトウェアを更新した後、実行される実施形態26から30のいずれかによる方法。
【0343】
32.デバイスが、RIに権利オブジェクト要求を送信するのに先立って実行される実施形態26から31のいずれかによる方法。
【0344】
33.ストリーミングコンテンツを求めるデバイスからRIへの要求中に、定期的に実行される実施形態26から32のいずれかによる方法。
【0345】
34.REは、CI(コンテンツ発行者)であり、TEは、デバイスである実施形態17による方法。
【0346】
35.デバイスは、デバイスが、ROAP(権利オブジェクト獲得プロトコル)プロセスを開始するのに先立って、方法を開始するトリガをCIに送信する実施形態34による方法。
【0347】
36.デバイスが、CIを相手にROAP(権利オブジェクト獲得プロトコル)プロセスを完了した後、定期的に実行される実施形態34または35による方法。
【0348】
37.デバイスが、デバイスのDRMソフトウェア完全性ステータスをCIに検証し、報告した後、定期的に実行される実施形態34から36のいずれかによる方法。
【0349】
38.デバイスが、デバイスのDRMソフトウェアを更新した後、実行される実施形態34から37のいずれかによる方法。
【0350】
39.CIは、デバイス上のメディアプレーヤに対してDRMソフトウェア完全性検査を実行するよう、デバイスに要求する実施形態34から38のいずれかによる方法。
【0351】
40.REは、デバイスであり、TEは、CI(コンテンツ発行者)である実施形態17による方法。
【0352】
41.デバイスによって開始されると、実行される実施形態40による方法。
【0353】
42.スタンドアロンのプロセスである実施形態40または41による方法。
【0354】
43.変更された権利オブジェクト獲得プロトコルプロセスの一環である実施形態40から42のいずれかによる方法。
【0355】
44.CIが、CIのDRMソフトウェア完全性ステータスをデバイスに検証し、報告した後、定期的に実行される実施形態40から43のいずれかによる方法。
【0356】
45.CIが、CIのDRMソフトウェアを更新した後、実行される実施形態40から44のいずれかによる方法。
【0357】
46.デバイスが、権利オブジェクト要求をCIに送信するのに先立って実行される実施形態40から45のいずれかによる方法。
【0358】
47.ストリーミングコンテンツを求めるデバイスからCIへの要求中に、定期的に実行される実施形態40から46のいずれかによる方法。
【0359】
48.2つのエンティティ間で交換されるROAP(権利オブジェクト獲得プロトコル)メッセージの完全性を強化するための方法であって、信頼されるコンピューティング技術を使用して各エンティティにおいて、ROAPメッセージの中で使用されるべき情報を安全に格納するステップと、ROAPメッセージに関連して使用されるのに先立って、ROAPメッセージの中で使用されるべき情報を事前検証するステップとを含む方法。
【0360】
49.格納するステップは、情報に密封署名すること、および情報を結び付けることを含む実施形態48による方法。
【0361】
50.密封署名するステップは、対称暗号化鍵を使用して情報を対称的に暗号化すること、およびこの対称暗号化鍵、およびオブジェクトの現在の完全性ステータスを示す値のセットに非対称的に署名することを含む実施形態49による方法。
【0362】
51.署名するステップは、エンティティが動作するプラットフォームの完全性ステータスを使用することを含む実施形態50による方法。
【0363】
52.署名するステップは、エンティティのソフトウェア構成要素の完全性ステータスを使用することを含む実施形態50または51による方法。
【0364】
53.結び付けるステップは、秘密解読鍵がエンティティ内の保護されたモジュールの中に格納された鍵を使用して、情報を非対称的に暗号化することを含む実施形態49から52のいずれかによる方法。
【0365】
54.保護されたモジュールは、TPM(信頼される処理モジュール)である実施形態53による方法。
【0366】
55.TPMは、ROAPメッセージの中で使用すべきパラメータを導き出すのに使用される実施形態54による方法。
【0367】
56.情報は、デバイスID、権利発行者ID、証明書、証明書チェーン、デジタル権利管理関連の時間値、権利オブジェクト、アルゴリズム、およびナンスから成るグループから選択される実施形態48から55のいずれかによる方法。
【0368】
57.すべてのROAPメッセージに適用される実施形態48から56のいずれかによる方法。
【0369】
58.ROAPメッセージとは別個に適用される実施形態48から56のいずれかによる方法。
【0370】
59.ROAPメッセージの生成および伝送に組み込まれる実施形態48から56のいずれかによる方法。
【0371】
60.送信するエンティティの信頼されるコンピューティング能力を示すフィールドを、既存のROAPメッセージに追加するステップをさらに含む実施形態48から56のいずれかによる方法。
【0372】
61.実施形態1から60のいずれかによる方法を実行するように構成されたシステム。
【0373】
62.実施形態1から60のいずれかによる方法を実行するように構成された集積回路。
【特許請求の範囲】
【請求項1】
要求するエンティティ(RE)装置と、ターゲットエンティティ(TE)装置との間でプラットフォーム完全性検査を実行するための方法であって、
前記TE装置に、そのTE装置の信頼される資格証明を報告することを求める要求を送信するステップと、
前記TE装置の信頼される資格証明を受信するステップと、
前記TE装置の信頼される資格証明を、完全性検証のために、レスポンダに転送するステップと、
前記レスポンダから前記TE装置の信頼される資格証明の完全性検証ステータスを受信するステップと、
前記TE装置に、そのTE装置自身のプラットフォーム完全性ステータスを報告することを求める要求を送信するステップと、
前記TE装置からプラットフォーム完全性ステータス標識を受信するステップと、
前記レスポンダからの前記TE装置の信頼される資格証明の完全性検証ステータスと前記TE装置からの前記プラットフォーム完全性ステータス標識とに基づいて、前記TE装置のプラットフォーム完全性ステータスに十分な信頼を与えて、権利オブジェクト獲得プロトコル(ROAP)登録プロトコルにおいて前記TE装置を進めるか、または、デバイスが権利発行者(RI)からの権利オブジェクト(RO)を獲得することを可能にする別のプロトコルにおいて前記TE装置を進めるのかを決定するステップと
を含み、
前記TE装置が、前記方法を開始するトリガを前記RE装置に送信することによって、前記方法が、前記TE装置が前記RE装置を相手に前記登録プロトコルを開始するのに先立って実行されることを特徴とする方法。
【請求項2】
前記RE装置は、前記RIであり、前記TE装置は、前記デバイスであることを特徴とする請求項1に記載の方法。
【請求項3】
前記デバイスが前記RI装置に最も新しく登録してから経過した時間に基づいて、前記方法が定期的に実行されることを特徴とする請求項2に記載の方法。
【請求項4】
前記デバイスが該デバイスのプラットフォーム完全性ステータスを前記RI装置に最も新しく検証してから経過した時間に基づいて、前記方法が定期的に実行されることを特徴とする請求項2に記載の方法。
【請求項5】
前記RE装置は、コンテンツ発行者(CI)であり、前記TE装置は、前記デバイスであることを特徴とする請求項1に記載の方法。
【請求項6】
前記デバイスが該デバイスのプラットフォーム完全性ステータスを前記CIに最も新しく検証してから経過した時間に基づいて、前記方法が定期的に実行されることを特徴とする請求項5に記載の方法。
【請求項7】
前記デバイスが、前記CIからコンテンツを購入すると、前記方法が実行されることを特徴とする請求項5に記載の方法。
【請求項8】
要求するエンティティ(RE)装置と、ターゲットエンティティ(TE)装置との間でデジタル権利管理(DRM)ソフトウェア完全性検査を実行するための方法であって、
前記TE装置がDRMソフトウェア完全性検査を実行するための要求を、前記RE装置から受信するステップと、
前記TE装置において前記DRMソフトウェア完全性検査を実行するステップと、
権利発行者(RI)にデバイスから権利オブジェクト要求メッセージが送信されることに先立って、前記RE装置にDRMソフトウェア完全性ステータス標識を送信するステップであって、前記DRMソフトウェア完全性ステータス標識は、前記TE装置の完全性ステータスに十分な信頼を与えて、権利オブジェクト獲得プロトコル(ROAP)登録プロトコルにおいて前記TE装置を進めるか、または、デバイスが前記RIからの権利オブジェクト(RO)を獲得することを可能にする別のプロトコルにおいて前記TE装置を進めるのかを示すように構成される、ステップと
を含み、
前記TE装置は、前記TE装置が前記ROAPプロセスを開始するのに先立って、前記方法を開始するトリガを前記RE装置に送信することを特徴とする方法。
【請求項9】
前記RE装置は、前記RIであり、前記TE装置は、前記デバイスであることを特徴とする請求項8に記載の方法。
【請求項10】
前記ROAPプロセスは、2パス登録、2パスドメイン参加、または2パスドメイン退去のうちの少なくとも1つから選択されることを特徴とする請求項8に記載の方法。
【請求項11】
前記デバイスが前記RIを相手に権利オブジェクト獲得プロトコル(ROAP)プロセスを完了した後、前記方法が定期的に実行されることを特徴とする請求項9に記載の方法。
【請求項12】
前記ROAPプロセスは、2パス登録、2パスドメイン参加、または2パスドメイン退去のうちの少なくとも1つから選択されることを特徴とする請求項11に記載の方法。
【請求項13】
前記デバイスが該デバイスのDRMソフトウェア完全性ステータスを前記RIに検証し、報告した後、前記方法が定期的に実行されることを特徴とする請求項9に記載の方法。
【請求項14】
前記デバイスが該デバイスのDRMソフトウェアを更新した後、前記方法が実行されることを特徴とする請求項9に記載の方法。
【請求項15】
前記RIは、前記デバイス上のメディアプレーヤに対して前記DRMソフトウェア完全性検査を実行するよう、前記デバイスに要求することを特徴とする請求項9に記載の方法。
【請求項16】
前記RE装置は、コンテンツ発行者(CI)であり、前記TE装置は、デバイスであることを特徴とする請求項8に記載の方法。
【請求項17】
前記デバイスは、前記デバイスが権利オブジェクト獲得プロトコル(ROAP)プロセスを開始するのに先立って、前記方法を開始するトリガを前記CIに送信することを特徴とする請求項16に記載の方法。
【請求項18】
前記デバイスが、前記CIを相手に権利オブジェクト獲得プロトコル(ROAP)プロセスを完了した後、前記方法が定期的に実行されることを特徴とする請求項16に記載の方法。
【請求項19】
前記デバイスが該デバイスのDRMソフトウェア完全性ステータスを前記CIに検証し、報告した後、前記方法が定期的に実行されることを特徴とする請求項16に記載の方法。
【請求項20】
前記デバイスが該デバイスのDRMソフトウェアを更新した後、前記方法が実行されることを特徴とする請求項16に記載の方法。
【請求項21】
前記CIは、前記デバイス上のメディアプレーヤに対してDRMソフトウェア完全性検査を実行するよう、前記デバイスに要求することを特徴とする請求項16に記載の方法。
【請求項1】
要求するエンティティ(RE)装置と、ターゲットエンティティ(TE)装置との間でプラットフォーム完全性検査を実行するための方法であって、
前記TE装置に、そのTE装置の信頼される資格証明を報告することを求める要求を送信するステップと、
前記TE装置の信頼される資格証明を受信するステップと、
前記TE装置の信頼される資格証明を、完全性検証のために、レスポンダに転送するステップと、
前記レスポンダから前記TE装置の信頼される資格証明の完全性検証ステータスを受信するステップと、
前記TE装置に、そのTE装置自身のプラットフォーム完全性ステータスを報告することを求める要求を送信するステップと、
前記TE装置からプラットフォーム完全性ステータス標識を受信するステップと、
前記レスポンダからの前記TE装置の信頼される資格証明の完全性検証ステータスと前記TE装置からの前記プラットフォーム完全性ステータス標識とに基づいて、前記TE装置のプラットフォーム完全性ステータスに十分な信頼を与えて、権利オブジェクト獲得プロトコル(ROAP)登録プロトコルにおいて前記TE装置を進めるか、または、デバイスが権利発行者(RI)からの権利オブジェクト(RO)を獲得することを可能にする別のプロトコルにおいて前記TE装置を進めるのかを決定するステップと
を含み、
前記TE装置が、前記方法を開始するトリガを前記RE装置に送信することによって、前記方法が、前記TE装置が前記RE装置を相手に前記登録プロトコルを開始するのに先立って実行されることを特徴とする方法。
【請求項2】
前記RE装置は、前記RIであり、前記TE装置は、前記デバイスであることを特徴とする請求項1に記載の方法。
【請求項3】
前記デバイスが前記RI装置に最も新しく登録してから経過した時間に基づいて、前記方法が定期的に実行されることを特徴とする請求項2に記載の方法。
【請求項4】
前記デバイスが該デバイスのプラットフォーム完全性ステータスを前記RI装置に最も新しく検証してから経過した時間に基づいて、前記方法が定期的に実行されることを特徴とする請求項2に記載の方法。
【請求項5】
前記RE装置は、コンテンツ発行者(CI)であり、前記TE装置は、前記デバイスであることを特徴とする請求項1に記載の方法。
【請求項6】
前記デバイスが該デバイスのプラットフォーム完全性ステータスを前記CIに最も新しく検証してから経過した時間に基づいて、前記方法が定期的に実行されることを特徴とする請求項5に記載の方法。
【請求項7】
前記デバイスが、前記CIからコンテンツを購入すると、前記方法が実行されることを特徴とする請求項5に記載の方法。
【請求項8】
要求するエンティティ(RE)装置と、ターゲットエンティティ(TE)装置との間でデジタル権利管理(DRM)ソフトウェア完全性検査を実行するための方法であって、
前記TE装置がDRMソフトウェア完全性検査を実行するための要求を、前記RE装置から受信するステップと、
前記TE装置において前記DRMソフトウェア完全性検査を実行するステップと、
権利発行者(RI)にデバイスから権利オブジェクト要求メッセージが送信されることに先立って、前記RE装置にDRMソフトウェア完全性ステータス標識を送信するステップであって、前記DRMソフトウェア完全性ステータス標識は、前記TE装置の完全性ステータスに十分な信頼を与えて、権利オブジェクト獲得プロトコル(ROAP)登録プロトコルにおいて前記TE装置を進めるか、または、デバイスが前記RIからの権利オブジェクト(RO)を獲得することを可能にする別のプロトコルにおいて前記TE装置を進めるのかを示すように構成される、ステップと
を含み、
前記TE装置は、前記TE装置が前記ROAPプロセスを開始するのに先立って、前記方法を開始するトリガを前記RE装置に送信することを特徴とする方法。
【請求項9】
前記RE装置は、前記RIであり、前記TE装置は、前記デバイスであることを特徴とする請求項8に記載の方法。
【請求項10】
前記ROAPプロセスは、2パス登録、2パスドメイン参加、または2パスドメイン退去のうちの少なくとも1つから選択されることを特徴とする請求項8に記載の方法。
【請求項11】
前記デバイスが前記RIを相手に権利オブジェクト獲得プロトコル(ROAP)プロセスを完了した後、前記方法が定期的に実行されることを特徴とする請求項9に記載の方法。
【請求項12】
前記ROAPプロセスは、2パス登録、2パスドメイン参加、または2パスドメイン退去のうちの少なくとも1つから選択されることを特徴とする請求項11に記載の方法。
【請求項13】
前記デバイスが該デバイスのDRMソフトウェア完全性ステータスを前記RIに検証し、報告した後、前記方法が定期的に実行されることを特徴とする請求項9に記載の方法。
【請求項14】
前記デバイスが該デバイスのDRMソフトウェアを更新した後、前記方法が実行されることを特徴とする請求項9に記載の方法。
【請求項15】
前記RIは、前記デバイス上のメディアプレーヤに対して前記DRMソフトウェア完全性検査を実行するよう、前記デバイスに要求することを特徴とする請求項9に記載の方法。
【請求項16】
前記RE装置は、コンテンツ発行者(CI)であり、前記TE装置は、デバイスであることを特徴とする請求項8に記載の方法。
【請求項17】
前記デバイスは、前記デバイスが権利オブジェクト獲得プロトコル(ROAP)プロセスを開始するのに先立って、前記方法を開始するトリガを前記CIに送信することを特徴とする請求項16に記載の方法。
【請求項18】
前記デバイスが、前記CIを相手に権利オブジェクト獲得プロトコル(ROAP)プロセスを完了した後、前記方法が定期的に実行されることを特徴とする請求項16に記載の方法。
【請求項19】
前記デバイスが該デバイスのDRMソフトウェア完全性ステータスを前記CIに検証し、報告した後、前記方法が定期的に実行されることを特徴とする請求項16に記載の方法。
【請求項20】
前記デバイスが該デバイスのDRMソフトウェアを更新した後、前記方法が実行されることを特徴とする請求項16に記載の方法。
【請求項21】
前記CIは、前記デバイス上のメディアプレーヤに対してDRMソフトウェア完全性検査を実行するよう、前記デバイスに要求することを特徴とする請求項16に記載の方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【公開番号】特開2012−257292(P2012−257292A)
【公開日】平成24年12月27日(2012.12.27)
【国際特許分類】
【出願番号】特願2012−168650(P2012−168650)
【出願日】平成24年7月30日(2012.7.30)
【分割の表示】特願2009−509765(P2009−509765)の分割
【原出願日】平成19年5月4日(2007.5.4)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.BLUETOOTH
【出願人】(596008622)インターデイジタル テクノロジー コーポレーション (871)
【Fターム(参考)】
【公開日】平成24年12月27日(2012.12.27)
【国際特許分類】
【出願日】平成24年7月30日(2012.7.30)
【分割の表示】特願2009−509765(P2009−509765)の分割
【原出願日】平成19年5月4日(2007.5.4)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.BLUETOOTH
【出願人】(596008622)インターデイジタル テクノロジー コーポレーション (871)
【Fターム(参考)】
[ Back to top ]