JP2014238877A - 信頼される処理技術を使用したデジタル権利管理 - Google Patents

Abstract

【課題】本発明は、ＯＭＡ ＤＲＭによって規定されるコンテンツ配布と関係するエンティティ、メッセージ、および処理の完全性を強化するいくつかの方法を開示する。【解決手段】これらの方法は、ＴＣＧ仕様と関係する技術を使用する。第１の実施形態は、ＤＲＭ ＲＯＡＰ仕様およびＤＲＭコンテンツフォーマット仕様の変更を伴う場合と、伴わない場合の両方で、ＴＣＧ技術を使用して、プラットフォームおよびＤＲＭソフトウェアの完全性または信頼性を検証する。第２の実施形態は、既存のＲＯＡＰプロトコルを変更することなしに、ＴＣＧ技術を使用して、ＲＯＡＰメッセージ、ＲＯＡＰメッセージを構成する情報、およびＲＯＡＰ処理の完全性を強化する。第３の実施形態は、既存のＲＯＡＰプロトコルのいくつかの変更を伴って、ＴＣＧ技術を使用して、ＲＯＡＰメッセージ、ＲＯＡＰ情報、およびＲＯＡＰ処理の完全性を強化する。【選択図】図７

Description

本発明は、一般に、無線通信ネットワークにおけるＤＲＭ（デジタル著作権管理）方法に関する。より詳細には、本発明は、ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）ＤＲＭ仕様に準拠して動作するシステムにおいてセキュリティ、完全性、および信頼性を強化するための方法を提供する。

ＯＭＡ ＤＲＭは、移動電話機および移動デバイスの製造業者、ならびにモバイルサービスプロバイダのコンソーシアムであるＯＭＡによって指定されるＤＲＭシステムである。このスキームは、多くの移動電話機上で実施され、モバイルコンテンツプロバイダによって、プロバイダの製品およびサービスにＤＲＭを追加するのに使用されることが意図される。ＯＭＡ ＤＲＭの２つのバージョン、すなわち、ＯＭＡ ＤＲＭ１．０およびＯＭＡ ＤＲＭ２．０が、公開されている。

ＯＭＡ ＤＲＭ１．０は、コンテンツオブジェクトに関するデジタル権利の基本的管理に関するスキームを扱う。このため、ＯＭＡ ＤＲＭ１．０は、コンテンツオブジェクトに関しても、権利オブジェクトに関しても強力な保護は提供しなかった。ＯＭＡ ＤＲＭ１．０は、３つの配信方法、すなわち、転送ロック（ユーザが、コンテンツを他のユーザ、または他のデバイスに転送するのを防止する）、組み合わされた配信（組み合わされた権利オブジェクトとメディアオブジェクト）、および分離した配信（分離した権利オブジェクトとメディアオブジェクト）を規定する。ＯＭＡ ＤＲＭ１．０は、電話機に関する呼び出し音または壁紙などの小さいサイズのメディアオブジェクトを扱うように設計された。

ＯＭＡ ＤＲＭ２．０は、ＯＭＡ ＤＲＭ１．０配信機構を改良し、拡張する。ＯＭＡ ＤＲＭ２．０に準拠するデバイスは、ＤＲＭ ＰＫＩ（公開鍵インフラストラクチャ）に基づく個別の証明書を有し、すなわち、各デバイスは、公開鍵、対応する秘密鍵を有するとともに、この事実を検証する証明書を有する。各ＲＯ（権利オブジェクト）は、機密性（暗号化によって）と完全性（デジタル署名によって）の両方に関して保護される。ＰＫＩ、暗号化、および完全性検査の使用が、ＯＭＡ ＤＲＭ１．０システムのセキュリティと比べて、ＯＭＡ ＤＲＭ２．０システムのセキュリティを強化する。

また、ＯＭＡ ＤＲＭ２．０は、デバイスとＲＩ（権利発行者）との間の相互認証および相互登録、ＲＯを要求すること、ＲＯの配信に対する応答、またはＲＯを配信することの拒否、ならびにデバイスがドメインに参加すること、およびドメインを退去することと関係する様々なサブプロトコルを含むＲＯＡＰ（権利オブジェクト獲得プロトコル）とまとめて呼ばれるプロトコルのセットも規定する。

以下は、ＯＭＡ ＤＲＭにおいて定義される主なエンティティのいくつかである。すなわち、

アクタ アクタは、使用事例を実行する外部エンティティである。

バックアップ／リモートストレージ ＲＯおよびＣＯ（コンテンツオブジェクト）を、元のデバイスに送り返すことを意図して、別のロケーションに転送すること。

組み合わされた配信 保護されたコンテンツおよびＲＯを配信するためのＯＭＡ ＤＲＭ１．０メソッド。ＲＯおよび保護されたコンテンツは、ＤＲＭメッセージという単一のエンティティの中で一緒に配信される。

機密性 情報が、許可のない個人、エンティティ、またはプロセスに提供されない、または開示されないという特性。

合成オブジェクト 包含によって１つまたは複数のメディアオブジェクトを含むＣＯ。

接続されたデバイス 適切なワイドエリアトランスポート／ネットワーク層インタフェースを介して、適切なプロトコルを使用してＲＩに直接に接続することができるデバイス。

コンテンツ １つまたは複数のメディアオブジェクト

ＣＩ（コンテンツ発行者） ＤＲＭエージェントにコンテンツを提供するエンティティ。

コンテンツプロバイダ ＣＩまたはＲＩであるエンティティ。

デバイス ＤＲＭエージェントを有するユーザ機器。デバイスは、接続されたデバイスであることも、接続されていないデバイスであることも可能であるが、この区別は、接続されたデバイスが、ＲＩに直接に接続する能力を失うと、接続されていないデバイスになる可能性があるので、コンテキスト依存であり、性質が不定である。

デバイス取り消し 或るデバイスがＲＯを獲得することが、もはや信頼されないことをＲＩが示すプロセス。

デバイスＲＯ 或る特定のデバイスに、そのデバイスの公開鍵によって専用とされるＲＯ。

ドメイン ドメインＲＯを共有することができるデバイスのセット。ドメイン内のデバイスは、ドメイン鍵を共有する。ドメインは、ＲＩによって定義され、管理される。

ドメイン識別子 ドメイン鍵の一意ストリング識別子。

ドメイン鍵 １２８ビットの対称暗号鍵

ＤＲＭエージェント デバイス上のメディアオブジェクトに関する許可を管理するデバイス内のエンティティ。

ＤＲＭコンテンツ ＲＯの中の許可セットに従って消費されるメディアオブジェクト。

ＤＲＭ時間 セキュリティで保護された、ユーザが変更できない時間源。ＤＲＭ時間は、ＵＴＣ時間フォーマットになっている。

完全性 データが、許可のない仕方で変更、または破壊されていないという特性。

ドメインに参加する ＲＩが、デバイスをドメインに含めるプロセス。

ドメインを退去する（参加解消する）ＲＩが、取り消されていないデバイスをドメインから除外するプロセス。

メディアオブジェクト デジタル作品または合成オブジェクト。

ネットワークサービスプロバイダ 移動デバイスにネットワーク接続を提供するエンティティ。

許可 ＤＲＭコンテンツに対してＲＩによって許される実際の使用または活動。

再生する リソースの一過性の知覚可能な表現を作成すること。

保護されたコンテンツ ＲＯの中の許可セットに従って消費されるメディアオブジェクト。

復元する 保護されたコンテンツおよび／またはＲＯを外部ロケーションから、保護されたコンテンツおよび／またはＲＯのバックアップの源とされたデバイスに送り返すこと。

取り消す デバイスまたはＲＩ証明書を無効と宣言するプロセス。

ＲＩ（権利発行者） ＯＭＡ ＤＲＭに準拠するデバイスにＲＯを発行するエンティティ。

ＲＩコンテキスト ＲＩ ＩＤ、ＲＩ証明書チェーン、バージョン、アルゴリズム、およびその他の情報などの、４パス登録プロトコル中に所与のＲＩを相手にネゴシエートされた情報。ＲＩコンテキストは、デバイスが、登録プロトコルを除いて、ＲＯＡＰスイートのすべてのプロトコルに参加することに成功するのに必要である。

ＲＯ（権利オブジェクト） 保護されたコンテンツにリンクされた許可およびその他の属性の集合。

ＲＯＡＰ（権利オブジェクト獲得プロトコル） デバイスが、ＲＩからＲＯを要求し、獲得することを可能にするプロトコル。

ＲＯＡＰトリガ デバイスによって受信されると、ＲＯＡＰを開始するＵＲＬを含むＸＭＬ（拡張マークアップ言語）ドキュメント。

状態のない権利 デバイスが状態情報を保持しなくてもよいＲＯ。

状態のある権利 デバイスが、状態情報を明示的に保持して、ＲＯの中で表現される制約および許可が、正しく実施されることが可能であるようにしなければならないＲＯ。以下の制約または許可のいずれかを含むＲＯが、状態のある権利である。すなわち、＜ｉｎｔｅｒｖａｌ＞、＜ｃｏｕｎｔ＞、＜ｔｉｍｅｄ−ｃｏｕｎｔ＞、＜ｄａｔｅｔｉｍｅ＞、＜ａｃｃｕｍｕｌａｔｅｄ＞、または＜ｅｘｐｏｒｔ＞である。

スーパ配布 （１）セキュリティで保護されていない可能性があるチャネルを介して、ユーザが保護されたコンテンツを他のデバイスに配布することを許し、さらに、そのデバイスのユーザが、スーパ配布された保護されたコンテンツに関するＲＯを獲得することを可能にする機構。

接続されていないデバイス ローカル接続技術を介する適切なプロトコル、例えば、ＯＢＥＸ ｏｖｅｒ ＩｒＤＡ（ｏｂｊｅｃｔ ｅｘｃｈａｎｇｅ ｏｖｅｒ ｉｎｆｒａｒｅｄ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、またはＵＳＢ（ユニバーサルシリアルバス）を使用して、接続されたデバイス経由でＲＩに接続することができるデバイス。

ユーザ デバイスの人間ユーザ。ユーザは、デバイスを必ずしも所有しない。

図１は、既存のＯＭＡ ＤＲＭ２．０機能アーキテクチャ１００の概略図である。アーキテクチャ１００は、ＤＲＭシステム１０２、コンテンツプロバイダ１０４、およびユーザ１０６から成る。ＤＲＭシステム１０２は、ＣＩ１１０、ＲＩ１１２、ＤＲＭエージェント１１４、ネットワークストア１１６、およびリムーバブルメディア１１８を含む。ＣＩ１１０は、保護されたコンテンツ１２２を配布し、ＲＩ１１２は、ＲＯ１２４を配布する。ＤＲＭエージェント１１４は、保護されたコンテンツ１２２を再配布する。

ＣＩ１１０は、ＤＲＭコンテンツ１２２を配信するエンティティである。ＯＭＡ ＤＲＭは、ＤＲＭエージェント１１４に配信されるべきＤＲＭコンテンツ１２２のフォーマット、ならびにＤＲＭコンテンツ１２２が、様々なトランスポート機構を使用してＣＩ１１０からＤＲＭエージェント１１４にトランスポートされることが可能な仕方を定義する。ＣＩ１１０は、ＤＲＭコンテンツ１２２の実際のパッケージ化を自ら行っても、他の何らかの源からあらかじめパッケージ化されたコンテンツを受信してもよい。

ＲＩ１１２は、ＤＲＭコンテンツ１２２に許可および制約を割り当て、ＲＯ１２４を生成するエンティティである。ＲＯ１２４は、ＤＲＭコンテンツ１２２に関連する許可および制約を表現するＸＭＬドキュメントである。ＲＯ１２４は、ＤＲＭコンテンツ１２２がどのように使用されることが可能であるかを支配し、つまり、ＤＲＭコンテンツ１２２は、関連付けられたＲＯ１２４なしに使用されることが可能でなく、関連付けられたＲＯによって指定されるとおりにしか使用されることが可能でない。ＤＲＭコンテンツは、例えば、ＲＯが、時間有効期限（例えば、１０日）を有し、この時間有効期限の後、このコンテンツにアクセスするのに新たなＲＯが必要とされる場合、複数のＲＯに関連付けられることも可能である。

ＤＲＭエージェント１１４は、ＤＲＭコンテンツ１２２の消費時点の執行を管理することを担う論理的エンティティである。ＤＲＭエージェント１１４は、デバイスの信頼される構成要素を実体化し、デバイス上のＤＲＭコンテンツ１２２に関する許可および制約を執行すること、デバイス上のＤＲＭコンテンツ（ＤＲＭエージェントを介してしかアクセスすることができない）へのアクセスを制御することなどを担う。

ＤＲＭコンテンツ１２２は、配信される前に、許可のないアクセスからコンテンツ１２２を保護するようにパッケージ化される。ＣＩ１１０が、ＤＲＭコンテンツ１２２を配信し、ＲＩ１２２が、ＲＯ１２４を生成する。ＣＩ１１０およびＲＩ１１２は、システム１０２において、物理的エンティティではなく、論理的役割を実体化する。例えば、１つの展開において、コンテンツ所有者が、ＤＲＭコンテンツをあらかじめパッケージ化し、その後、このコンテンツが、ＣＩとＲＩの両方の役割をするコンテンツ配給元によって配布される。

ＲＯ１２４が、ＤＲＭコンテンツ１２２がどのように使用されることが可能であるかを支配する。ＤＲＭコンテンツ１２２は、関連付けられたＲＯ１２４なしに使用されることが可能でなく、ＲＯ１２４の中で指定される許可および制約に従ってしか使用されることが可能でない。ＯＭＡ ＤＲＭは、ＲＯからのＤＲＭコンテンツの論理的分離を行う。ＤＲＭコンテンツとＲＯは、別々に要求されても、一緒に要求されてもよく、別々に配信されても、同時に配信されてもよい。ＤＲＭコンテンツとＲＯは、同時に配信される場合、通常、ともに、ＣＩ１１０によって提供され、ＲＯおよびコンテンツは、ＤＣＦ（ＤＲＭコンテンツフォーマット）に埋め込まれる。

ＲＯ１２４は、鍵のセットによって、或る特定のＤＲＭエージェント１１４に暗号上、結び付けられて、その特定のＤＲＭエージェント１１４だけが、ＲＯ１２４にアクセスすることができるようにされる。ＤＲＭコンテンツ１２２は、有効なＲＯ１２４を使用してしかアクセスすることができず、したがって、コンテンツ１２２は、自由に配布される、またはスーパ配布されることが可能である。

ＯＭＡ ＤＲＭ２．０は、１つのＲＯが、ＤＲＭエージェントのグループに結び付けられることを許す。そのようなグループは、ドメインと呼ばれる。或るドメインに配布されたＤＲＭコンテンツおよびＲＯは、そのドメインに属するすべてのＤＲＭエージェントによってオフラインで共有され、アクセスされることが可能である。例えば、ユーザは、ユーザの電話機とユーザのＰＤＡの両方で使用するためにＤＲＭコンテンツを購入することができる。

ＯＭＡ ＤＲＭ仕様は、ＤＲＭコンテンツのためのフォーマットおよび保護機構（つまり、ＤＣＦ）、ＲＯのためのフォーマット（ＲＥＬ（権利表現言語））および保護機構、暗号鍵の管理のためのセキュリティモデルを定義する。また、ＯＭＡ ＤＲＭ仕様は、ＤＲＭコンテンツおよびＲＯが、プル（ＨＴＴＰプル、ＯＭＡダウンロード）、プッシュ（ＷＡＰプッシュ、ＭＭＳ）、およびストリーミングを含む一連のトランスポート機構を使用して、どのようにデバイスにトランスポートされることが可能であるかも定義する。しかし、ＯＭＡ ＤＲＭ仕様は、ネットワークエンティティ間、例えば、ＣＩ１１０とＲＩ１１２の間の対話を全く扱わない。

以下は、ＯＭＡ ＤＲＭ２．０仕様が範囲に含む使用事例の網羅的ではないリストである。

１．基本プルモデル

ユーザは、Ｗｅｂサイトにブラウズして行くことによって、ダウンロードすべきコンテンツを選択し、購入の条件を確認する。ＣＩ１１０は、コンテンツ１２２を識別し、保護する、すなわち、コンテンツ１２２をパッケージ化する。コンテンツ１２２は、ＣＥＫ（コンテンツ暗号化鍵）を使用して暗号化される。デバイス能力が、公示されたＭＩＭＥタイプサポートなどを使用して検出されることが可能である。ＲＩ１１２が、コンテンツ１２２およびターゲットＤＲＭエージェント１１４に関するＲＯ１２４を生成する。ＲＯ１２４は、コンテンツトランザクションに関する許可、およびＣＥＫを含む。最期に、ＲＯ１２４は、暗号化（ＲＯ暗号化鍵、つまり、ＲＥＫを使用する）およびデジタル署名によって暗号で保護され、ターゲットＤＲＭエージェント１１４だけに結び付けられる。次に、ＤＲＭコンテンツ１２２および保護されたＲＯ１２４が、ＤＲＭエージェント１１４に配信される。

２．ＤＲＭコンテンツのプッシュ

代替の配布モデルは、先行する発見プロセスなしに、ＭＭＳ（マルチメディアメッセージングサービス）、ＷＡＰプッシュ、または類似した方法を使用して、デバイスにコンテンツを直接にプッシュすることである。この使用事例の２つの変種が存在する。

２Ａ．コンテンツプッシュ

ＣＩ１１０および／またはＲＩ１１２は、或るユーザ、および或る特定のＤＲＭエージェント１１４のいくらかの事前の知識を有することが可能であり、したがって、コンテンツ１２２およびＲＯ１２４は、配信のためにフォーマットされ、パッケージ化されることが可能である。

２Ｂ．プッシュによって開始されるプル

この場合、ＣＩ１１０および／またはＲＩ１１２は、ユーザ、またはユーザのＤＲＭエージェント１１４についての事前の知識を全く有さないことが可能であるが、それでも、例えば、ユーザが、コンテンツを購入するようにユーザの気を引くコンテンツ１２２をプレビューすることを可能にするように、コンテンツを配信することを望む可能性がある。ＤＲＭコンテンツ１２２をユーザに直接にプッシュする代わりに、このコンテンツへのリンク、またはこのコンテンツのプレビューへのリンクが、送信されることが可能である。このリンクをたどることにより、ユーザは、或る特定のロケーションに連れて行かれ、その後、手続きは、基本プルモデルにおけるとおりに進む。

３．ＤＲＭコンテンツのストリーミング

基本プル使用事例とプッシュ使用事例はともに、コンテンツの全体がパッケージ化され、配信されるものと想定する。代替として、コンテンツは、ストリームとしてパケット化されて、配信されてもよい。この場合、ストリーム自体が保護される（暗号化される）。暗号化の厳密なフォーマットは、ＯＭＡ ＤＲＭの範囲外とされており、既存の暗号化標準から選択されることが可能である。これらのストリームは、可能なパケット損失などに対処するように、ダウンロードに関してＯＭＡによって規定される暗号化スキームとは異なる暗号化スキームを使用して保護されてもよい。しかし、ストリームが暗号化された後、ストリームへのアクセスは、離散的コンテンツに関して前段で説明したのと同一の手続きを介して制御されることが可能である。ＲＯが生成され、ストリーム暗号化鍵が、ＣＥＫと同様にＲＯの中に入れられ、次に、このＲＯが、ＤＲＭエージェントと暗号上、結び付けられる。

４．ドメイン

ドメインは、オプションのフィーチャであり、すべてのＲＩによってサポートされるわけではない可能性がある。ドメインは、ＲＯとＣＥＫが或る特定のＤＲＭエージェント１１４に結び付けられるＯＭＡ ＤＲＭ２．０の基本モデルを拡張し、ＲＩ１１２が、権利およびＣＥＫを、単一のＤＲＭエージェントだけにではなく、ＤＲＭエージェントのグループに結び付けることを許す。すると、ユーザは、同一のドメインに属するすべてのＤＲＭエージェントの間で、ＤＲＭコンテンツ１２２をオフラインで共有することができる。ＲＩ１１２は、ドメイン概念を使用して、ユーザが所有するいくつかのデバイスから、ユーザがＤＲＭコンテンツ１２２にアクセスすることができるようにすることなどの、新たなサービスを提供する、あるいはユーザが、１つのデバイス（例えば、ＰＣ）を介して、別のデバイス（例えば、ポータブルプレーヤ）上で後に使用するために、ＤＲＭコンテンツおよび権利を購入する場合、接続されていないデバイスのサポートを提供することができる。

５．バックアップ

ＤＲＭコンテンツ１２２は、リムーバブルメディア１１８上に、ネットワークストア１１６の中に、または他の何らかの形態のストレージの中に格納されることが可能である。ＤＲＭコンテンツ１２２は、暗号化された形態で格納され、関連付けられたＲＯ１２４を使用する或る特定のターゲットＤＲＭエージェント１１４によってしかアクセスされることが可能でない。ＲＯ１２４は、ＲＯが、状態のない許可だけしか含まない場合、バックアップの目的で格納されることが可能である。セキュリティモデルが、ＲＯ１２４がオフデバイスで格納される場合でさえ、ＲＯ１２４が保護されて、意図されるＤＲＭエージェント１１４によってしかアクセスされることが可能でないことを確実にする。一部の許可は、ＤＲＭエージェント１１４による状態、例えば、限られた回数の再生の保持を要求する。そのようなＲＯは、オフデバイスで格納されることが、そうすることにより、状態情報が失われることになる可能性があるので、可能でない。

６．スーパ配布

ＤＲＭコンテンツ１２２は、コピーされて、他のＤＲＭエージェント１１４に転送されること、例えば、ユーザが、ＤＲＭコンテンツ１２２を友人に送信することが可能である。友人は、コンテンツ１２２にアクセスするために、ＤＲＭコンテンツパッケージの中のリンクを介してＲＩ１１２に連れて行かれて、ＲＯ１２４を獲得する。

７．エクスポート（非ＯＭＡ ＤＲＭシステムへの）

ＤＲＭコンテンツ１２２は、ＯＭＡ ＤＲＭ準拠ではないが、他の何らかのＤＲＭ機構をサポートするデバイス上で使用されるように、他のＤＲＭシステムにエクスポートされることが可能である。ＯＭＡ ＤＲＭアーキテクチャは、ＲＩ１１２が、所望する場合、別の特定ＤＲＭシステムへの変換を、ＤＲＭエージェント１１４が、場合により、その別のＤＲＭシステムによって指定されるとおり実行する、許可を表明することを許す。ＲＩ１１２は、特定の外部ＤＲＭシステムだけに、このエクスポートを制限することができる。

８．接続されていないデバイスのサポート

ＯＭＡ ＤＲＭは、接続されていないデバイスがコンテンツ１２２およびＲＯ１２４を購入して、ダウンロードするのを助ける仲介役の働きを、接続されたデバイスがすることを可能にする。ユーザが、例えば、ネットワーク接続を全く有さないＯＭＡ ＤＲＭに準拠するポータブルデバイス（接続されていないデバイス）と、ネットワーク接続を有するＯＭＡ ＤＲＭに準拠する移動デバイス（接続されたデバイス）とを有することが可能である。接続されたデバイスを使用して、ＤＲＭコンテンツ１２２をブラウズして、購入し、ＤＲＭコンテンツ１２２を、接続されたデバイスにダウンロードした後、ユーザは、次に、接続されていないデバイス上でＤＲＭコンテンツ１２２を再生することを所望することが可能である。この場合、接続されたデバイス上のＤＲＭエージェント１１４は、ＲＩ１１２からドメインＲＯ１２４を要求して、ダウンロードする。
次に、接続されたデバイス上のＤＲＭエージェント１１４は、ＤＣＦの中にドメインＲＯ１２４を埋め込む。次に、このＤＣＦが、ローカル接続技術を介する適切なプロトコル、例えば、ＢｌｕｅｔｏｏｔｈまたはＵＳＢを使用して、接続されていないデバイスに転送されることが可能である。接続されたデバイスと接続されていないデバイスの両方が、ＯＭＡ ＤＲＭ準拠であって、この機能をサポートしなければならない。また、接続されていないデバイスは、接続されたデバイスと同一のドメインに属さなければならない。

セキュリティおよび信頼

以下は、ＯＭＡ ＤＲＭ２．０のセキュリティ方策および信頼方策の概要である。一般に、いずれのＤＲＭソリューションも、以下の２つのセキュリティ要件を満たす必要がある。すなわち、（１）保護されたコンテンツは、適切に認証され、許可されたＤＲＭエージェントによってだけアクセスされなければならず、さらに（２）保護されたコンテンツ上の許可は、すべてのＤＲＭエージェントによって遵守されなければならない。ＤＲＭコンテンツに関連する許可および制約の執行は、任意のＤＲＭスキームのセキュリティ方策および信頼方策の主要な関心事である。関連付けられたＲＯによって規定されるものを超えたＤＲＭコンテンツへの許可のないアクセス、不正なコピーの作成、およびＤＲＭコンテンツの再配布が、いずれのＤＲＭシステムにも主な脅威を成す。

ＯＭＡ ＤＲＭシステムは、ＯＭＡ環境における保護されたコンテンツのセキュリティで保護された配布および管理のための手段を提供し、前段で規定された要件を満たす。ＯＭＡ ＤＲＭは、ＲＯの制約下におけるコンテンツの保護された使用を確実にするＤＲＭエージェントを使用することによって、消費時点でコンテンツおよびＲＯの使用および保護を執行する。

ＤＲＭコンテンツを配布するための基本ステップは、以下のとおり要約されることが可能である。すなわち、

１．コンテンツパッケージ化。コンテンツは、セキュリティで保護されたコンテンツコンテナ（ＤＣＦ）の中にパッケージ化される。ＤＲＭコンテンツは、対称ＣＥＫ（コンテンツ暗号化鍵）を使用して暗号化される。コンテンツは、あらかじめパッケージ化されることが可能であり、すなわち、コンテンツパッケージ化は、オンザフライで行われなくてもよい。同一のＣＥＫが、コンテンツのすべてのインスタンスに関して使用されるわけではなく、ただし、このことは、ＯＭＡ ＤＲＭにおける要件ではない。

２．ＤＲＭエージェント認証。すべてのＤＲＭエージェントが、一意の秘密鍵／公開鍵ペアと、証明書とを有する。証明書は、デバイス製造業者、デバイスタイプ、ソフトウェアバージョン、通し番号などのさらなる情報を含む。このことは、ＣＩおよびＲＩが、ＤＲＭエージェントをセキュリティで保護された仕方で認証することを可能にする。

３．ＲＯ生成。ＲＯは、ＤＲＭコンテンツが、関連付けられたＲＯなしに使用されることが可能でないことを確実にするＣＥＫを含む。ＲＯは、許可（例えば、再生、表示、および実行）および制約（例えば、１ヶ月間、再生する、１０分間、表示する）から成る。また、ＲＯは、コンテンツにアクセスが行われる際に、或るユーザが居合わせること（例えば、ユーザの身元によって判定される）を要求する制約を含むことも可能である。これらの許可および制約、ならびにＲＯに実体化される他の情報（例えば、著作権情報）は、ユーザに提示されることが可能である。

４．ＲＯ保護。ＲＯを配信する前に、ＲＯのセンシティブな部分（ＣＥＫなどの）が、ＲＥＫ（権利暗号化鍵）を使用して暗号化され、次に、このＲＯが、ターゲットＤＲＭエージェントに暗号上、結び付けられる。このことにより、ターゲットＤＲＭエージェントだけが、ＲＯ、ＣＥＫ、およびＤＲＭコンテンツにアクセスすることができることが確実にされる。さらに、ＲＩが、ＲＯにデジタルで署名する。また、ＲＯは、ＣＥＫを含めることによって、ＤＲＭへのアクセスを支配する。ＯＭＡ ＤＲＭ ＲＥＬ（権利表現言語）が、ＤＲＭコンテンツの使用を支配する許可および制約のシンタックス（ＸＭＬ）およびセセマンティックスを規定する。ＲＯは、ＲＯ独自のＭＩＭＥコンテンツタイプを有する。

５．配信。次に、ＲＯおよびＤＣＦは、ターゲットＤＲＭエージェントに配信されることが可能である。両方のアイテムは、本来的にセキュリティで保護されているので、任意のトランスポート機構（例えば、ＨＴＴＰ／ＷＳＰ、ＷＡＰプッシュ、ＭＭＳ）を使用して配信されることが可能である。ＲＯとＤＣＦは、例えば、ＭＩＭＥ複数パートメッセージの中で、一緒に配信されることも、別々に配信されることも可能である。

ＲＯに関するＯＭＡ ＤＲＭ信頼モデルは、双方によって認識され、信頼される主役のグループ、検証者、および１つまたは複数の認証機関が存在する、ＰＫＩ（公開鍵インフラストラクチャ）に基づく。単一のエンティティが、選択されたコンテキストおよびソリューションのニーズに応じて、主役の役割をすることも、検証者の役割をすることもできる。ＰＫＩは、検証者と主役が、開かれた、セキュリティで保護されていないネットワークを介して通信する際に、検証者が、主役の身元、およびその他の属性を認証することを可能にする。そのようなシステムにおいて、通常、検証者は、認証の目的で、検証者が対話する相手の主役についてのセンシティブな情報を全く保持する必要はない。さらに、ＣＡ（証明機関）は、主役と検証者の間のトランザクションに直接に関与していない。ＲＩは、ＤＲＭエージェントの証明書が、ＲＩによって検証可能であり、取り消されていない場合、ＤＲＭエージェントが正しく振る舞うことを信頼する。同様に、ＤＲＭエージェントは、ＲＩの証明書が、ＤＲＭエージェントによって検証可能であり、取り消されていない場合、ＲＩが正しく振る舞うことを信頼する。

ＯＭＡ ＤＲＭに適用されるＰＫＩの主なエンティティは、ＣＡ、デバイス、およびＲＩである。ＯＭＡ ＤＲＭの認証プロトコルおよび鍵転送プロトコルは、ＲＩが、デバイスを認証することができ、デバイスが、ＲＩを認証することができることを要求する。そのような相互認証は、ＲＯＡＰによって達せられる。

さらに、デバイスは、デバイス公開鍵およびデバイス秘密鍵、ならびに適切なＣＡによって署名された関連する証明書を備えさせられる（製造時に、または後に）ものと想定される。ＲＩによって表明される証明書選好に基づき、デバイスは、適切な証明書を提供しなければならない。デバイスは、完全性および機密性の保護を有するローカルストレージの中に秘密鍵を格納することを要求される。

また、ＲＩも、公開鍵、秘密鍵、およびＣＡによって署名された証明書を与えられる。証明書チェーン（１つのＣＡによって署名された公開鍵所有者の証明書と、他のＣＡによって署名されたＣＡの０、または１つ以上のさらなる証明書とを含む複数の証明書のチェーン）は、信頼の証明書チェーンの検証のための認証プロトコルの時点で、デバイスに提示される。

複数のＣＡが、ＤＲＭシステム内に存在することが可能であることに留意されたい。ＲＯＡＰプロトコルは、ＲＩ証明書に署名するＣＡが、プロトコルの実行中に使用するために、ＯＣＳＰ（オンライン証明書ステータスプロトコル）レスポンダを実行することを要求する。また、ＣＡは、発行された証明書の使用を支配する適切な証明書ポリシーを定義することも要求される。

以下は、ＯＭＡ ＤＲＭセキュリティの主な態様を説明する。

１．データが、許可のないパーティによってアクセスされることが可能でないことを確実にする機密性。前述したとおり、保護されたコンテンツは、適切に認証され、許可されたＤＲＭエージェントによってだけアクセス可能でなければならない。この目標を達するのに、保護されたコンテンツは、暗号化される。暗号化鍵は、各メディアオブジェクトに一意であり、ＲＯが、意図される受信者によってしかアクセス可能でない鍵の中にラップされた暗号化鍵を担持する。

２．或るパーティが、別のパーティに自らの身元を明かすプロセスである認証。ＯＭＡ ＤＲＭにおいて、相互ＤＲＭエージェント−ＲＩ認証が、４パス登録プロトコル、２パスＲＯ獲得プロトコル、および２パスドメイン参加プロトコルにおいて達せられる。使用されるプロトコル、および送信されるメッセージに依存して、認証は、ナンス上、またはタイムスタンプ上のデジタル署名を介して達せられる。１パスＲＯ獲得プロトコルは、タイムスタンプ上のデジタル署名を介してＲＩ認証を実現する。１パスＲＯ獲得プロトコルは、ＲＩに対してＤＲＭエージェントを認証しないが、保護されたコンテンツが、受信者の公開鍵でラップされることにより、認証は、鍵結び付けを介して間接的に行われる。２パスドメイン退去プロトコルは、タイムスタンプ上のデジタル署名を介して、ＲＩに対してＤＲＭエージェントを認証する。２パスドメイン退去プロトコルは、ＤＲＭエージェントに対してＲＩを認証しない。ＲＩは、ＲＯの配信中にＤＲＭエージェントに対して自らを認証することを要求される。このことにより、ＲＩの真正性について或る程度の保証が提供される。

３．データ完全性保護は、データの許可のない変更を検出する能力を確実にする。ＯＭＡ ＤＲＭにおいて、データ完全性保護は、適宜、ＲＯＡＰメッセージ上、およびＲＯ上のデジタル署名を介して達せられる。

４．鍵確認は、保護された鍵を含むメッセージの受信者に、メッセージ送信者が鍵値を知っていることを保証する。ＤＲＭコンテキストにおいて、この特性は、或るＲＩからのＲＯを、別のＲＩが許可なく再発行することを防止する。ＯＭＡ ＤＲＭシステムにおいて、鍵確認は、保護された鍵の諸部分をＭＡＣ鍵として使用することによる、保護された鍵、および送信するパーティの身元に対するＭＡＣ（メディアアクセス制御）を介して達せられる。

ＤＲＭエージェントは、正しい振舞いと、セキュリティで保護された実施の両方の点で、ＲＩによって信頼されなければならない。ＯＭＡ ＤＲＭにおいて、各ＤＲＭエージェントは、そのＤＲＭエージェントを識別し、そのエージェントと鍵ペアとの間の結び付きを証明する、一意の鍵ペア、および関連する証明書を備えさせられる。このことにより、ＲＩは、標準のＰＫＩ手続きを使用してＤＲＭエージェントをセキュリティで保護された仕方で認証することが可能になる。

証明書の中の情報は、ＲＩが、ビジネス規則、コンテンツの価値などに基づいて、ポリシーを適用することを可能にする。例えば、ＲＩは、或る製造業者を信頼することが可能であり、あるいはＲＩによって定義されたいくつかの基準に従って信頼されるべき、または信頼されるべきでないことが知られているＤＲＭエージェントの更新されたリストを保持することが可能である。

ＤＣＦ（ＤＲＭコンテンツフォーマット）は、独自のＭＩＭＥコンテンツタイプを有する、暗号化されたコンテンツに関するセキュリティで保護されたコンテンツパッケージである。暗号化されたコンテンツに加え、ＤＣＦは、コンテンツ記述（元のコンテンツタイプ、ベンダ、バージョンなど）、ＲＩ ＵＲＩ（ユニフォームリソース識別子）（ＲＯが獲得されることが可能なロケーション）などのさらなる情報を含む。このさらなる情報は、暗号化されず、ＲＯが取得される前にユーザに提示されることが可能である。ＤＣＦ内のＤＲＭコンテンツをアンロックするのに必要とされるＣＥＫは、ＲＯ内に含まれる。このため、ＲＯなしにＤＲＭコンテンツにアクセスすることは可能でなく、ＤＲＭコンテンツは、ＲＯの中で規定されたとりにしか使用されることが可能でない。ＯＭＡ ＤＲＭは、ＤＲＭエージェントが、ＤＣＦの完全性を検証することを可能にして、許可のないエンティティによるコンテンツの変更を防止する機構を含む。

ＯＭＡ ＤＲＭシステムは、ＤＲＭエージェントの中にＤＲＭ時間が存在することを想定する。ユーザは、ＤＲＭ時間を変更することができないので、ＤＲＭ時間が、ＯＣＳＰレスポンダによって保持される時間と同期されることが可能な機構が、定義される。いくつかの制約（例えば、絶対時間制約）、ならびにＲＯに関する配信プロトコルのいくつかの態様は、セキュリティで保護された時間源を有するＤＲＭエージェントに依拠する。ＯＭＡ ＤＲＭ仕様のコンテキストにおけるＤＲＭ時間は、正確な時間、ならびにユーザが変更することが可能でない時間値を意味する。ＯＭＡ ＤＲＭ仕様は、ＤＲＭ時間が、必要な際、例えば、ＤＲＭ時間が、長い停電の後に失われた場合、同期される機構を提供する。一部の限られた能力の接続されていないデバイスは、リアルタイムのクロックをサポートしないことが可能であり、このため、ＤＲＭ時間をサポートしない可能性がある。しかし、接続されたデバイスは、ＤＲＭ時間をサポートしなければならない。

ＯＭＡ ＤＲＭは、ＲＯリプレー保護攻撃を防止する。ＲＯリプレー攻撃の例は、中間者が、ＤＲＭエージェントへの配信中に、限られた回数の実行でＲＯを傍受する場合である。ＤＲＭエージェント上で権利が失効した際、この傍受されたＲＯが、中間者から再び配信される（リプレーされる）可能性がある。ＯＭＡ ＤＲＭは、このこと、および類似した攻撃が行われることを防ぐ。

ＯＭＡ ＤＲＭシステムは、前段で列挙したセキュリティ機構の使用を介してアプリケーション層セキュリティを提供する。このため、ＯＭＡ ＤＲＭシステムは、トランスポート層セキュリティに依拠しない、またはトランスポート層セキュリティを前提としない。

ＲＯＡＰは、ＯＭＡ ＤＲＭ２．０において、ＲＯに関する情報のセキュリティで保護された認証ベースの交換を可能にすることに中心的な役割を果たす。ＲＯＡＰは、ＲＩと、デバイス内のＤＲＭエージェントとの間のＤＲＭセキュリティプロトコルスイートを表す一般的な名前である。このプロトコルスイートは、以下のいくつかのサブプロトコルを含む。すなわち、

１．図２に示される、ＲＩにデバイスを登録するための４パスプロトコル。

２．図３に示される、ＲＯの要求および配信を含む２パスＲＯ獲得プロトコル。

３．１パスＲＯ獲得プロトコルは、図４に示されるとおり、ＲＩからデバイスへのＲＯの配信（例えば、メッセージング／プッシュ）と関係する。

４．図５に示される、デバイスがドメインに参加する２パスドメイン参加プロトコル。

５．図６に示される、デバイスがドメインを退去する２パスドメイン退去プロトコル。

図２は、４パス登録プロトコル２００の流れ図である。プロトコル２００は、デバイス２０２、ＲＩ２０４、およびＯＣＳＰレスポンダ２０６を利用する。デバイス２０２は、デバイスＩＤ（ＲＩ２０４が、ＯＣＳＰレスポンダ２０６に後に確認をとることができるデバイスの証明書のハッシュ）、およびその他の情報などの情報を含む、デバイスハローメッセージを送信すること（ステップ２１０）によって、ＲＩ２０４との連絡を開始する（場合により、ＲＯＡＰトリガを受信した後）。テーブル１は、デバイスハローメッセージの主な構成要素を示す。デバイスハローメッセージの中の情報のいずれも、完全性保護されておらず、すなわち、このメッセージに関する署名は、存在しない。

ＲＩ２０４は、デバイスハローメッセージに応答して（ステップ２１０）、ＲＩの証明書資格情報（ＲＩ ＩＤの形態の）、いくつかのセッション関連の（リプライ防止目的の）ナンスおよびセッション番号、ならびにＲＩ２０４が認識するデバイスについての信頼チェーンに関する情報などの他のオプションの情報などの情報を含む、ＲＩハローメッセージをデバイス２０２に送信する（ステップ２１２）。テーブル２は、ＲＩハローメッセージのフォーマットを示す。ＲＩハローメッセージの中の情報のいずれも、完全性保護されていないことに留意されたい。

ＲＩハローメッセージの中に含まれる情報の検証が成功すると、デバイス２０２は、要求時間、セッションＩＤ、および署名などの必須の情報と、証明書チェーン、信頼されるＲＩ権限アンカ、拡張子などのオプションの情報とを含む登録要求メッセージを送信する（ステップ２１４）。テーブル３は、登録要求メッセージのフォーマットを示す。登録要求メッセージは、末尾において、登録要求メッセージの中の署名フィールドまでの、デバイス２０２とＲＩ２０４の間で交換されるすべてのメッセージの、すなわち、デバイスハローメッセージ全体、ＲＩハローメッセージ全体、および署名フィールドまでの（このフィールドを除く）登録要求メッセージのフィールドのデジタル署名を含む。このデジタル署名は、デバイスの秘密鍵を使用して作成される。このデジタル署名を含めることにより、関連するＲＯＡＰメッセージのいくらかの完全性保護がもたらされる。

デバイス２０２が、拡張子の中の情報を介して、ＯＣＳＰ検証が必要ない、またはサポートされないことを示すのでない限り、ＲＩ２０４は、デバイス２０２によってＲＩ２０４に供給される情報の検証を要求するＯＣＳＰ要求メッセージをＯＣＳＰレスポンダ２０６に送信する（ステップ２１６）。ＯＣＳＰレスポンダ２０６は、要求メッセージの中でこの情報を探して、この情報を検証し、要求の結果を含むＯＣＳＰ応答メッセージを戻そうと試みる（ステップ２１８）。

ＲＩ２０４は、登録が成功したか、失敗したかという指示、ならびに他の情報を含む登録応答メッセージをデバイス２０２に送信する。テーブル４は、登録応答メッセージのフォーマットを示す。登録応答メッセージは、末尾に、登録要求メッセージおよび登録応答メッセージのＳＨＡ−１ハッシュ（署名フィールドまでの、署名フィールドを除く）を含む。このデジタル署名は、ＲＩの秘密鍵を使用して行われる。デジタル署名を含めることにより、関連するＲＯＡＰメッセージのいくらかの完全性保護がもたらされる。ＳＨＡ−１ハッシュが、このデジタル署名に関して使用されるが、デジタル署名を適用するための任意の適切なアルゴリズムが使用されることが可能であることに留意されたい。

図３は、２パスＲＯ獲得プロトコル３００の流れ図である。プロトコル３００は、デバイス２０２およびＲＩ２０４を利用し、４パス登録プロトコル２００が完了して、デバイス２０２が、ＲＩ２０４についての有効な証明書チェーンを受信した後に機能する。プロトコル３００は、デバイス２０２によって、ＲＩ２０４からＲＯを要求するのに使用される。デバイス２０２は、ＲＯ要求メッセージをＲＩ２０４に送信して、ＲＯを要求する（ステップ３１０）。テーブル５は、ＲＯ要求メッセージのフォーマットを示す。ＲＯ要求メッセージは、メッセージのデジタル署名（署名フィールドを除く）を含む。

ＲＩ２０４は、要求メッセージに応答して、デバイス２０２にＲＯ応答メッセージを送信する（ステップ３１２）。ＲＯ応答メッセージは、ＲＯを含む、またはＲＯが送信されないという指示を含む。

テーブル６は、ＲＯ応答メッセージのフォーマットを示す。ＲＯ応答メッセージは、成功した状態の場合、署名フィールドを除くＲＯ要求メッセージおよびＲＯ応答メッセージのＳＨＡ−１ハッシュであるデジタル署名を含む。

図４は、１パスＲＯ獲得プロトコル４００の流れ図である。プロトコル４００は、デバイス２０２およびＲＩ２０４を利用する。プロトコル４００において、ＲＩ２０４は、デバイス２０２による要求なしに、ＲＯを含むＲＯ応答メッセージをデバイス２０２に一方的に送信する（ステップ４１０）。プロトコル４００は、例えば、プッシュ使用事例を適用する。テーブル７は、ＲＯ応答メッセージのフォーマットを示す。

図５は、２パスドメイン参加プロトコル５００の流れ図である。プロトコル５００は、デバイス２０２およびＲＩ２０４を利用する。デバイス２０２が、ドメインに参加することを望む場合、デバイス２０２は、ＲＩ２０４にドメイン参加要求メッセージを送信する（ステップ５１０）。ＲＩ２０４は、この要求を評価し、ドメイン参加応答メッセージをデバイス２０２に送信する（ステップ５１２）。テーブル８は、ドメイン参加要求メッセージのフォーマットを示し、テーブル９は、ドメイン参加応答メッセージのフォーマットを示す。

図６は、２パスドメイン退去プロトコル６００の流れ図である。プロトコル６００は、デバイス２０２およびＲＩ２０４を利用する。デバイス２０２が、ドメインを退去することを望む場合、デバイス２０２は、ＲＩ２０４にドメイン退去要求メッセージを送信する（ステップ６１０）。ＲＩ２０４は、この要求を評価して、デバイス２０２にドメイン退去応答メッセージを送信する（ステップ６１２）。テーブル１０は、ドメイン退去要求メッセージのフォーマットを示し、テーブル１１は、ドメイン退去応答メッセージのフォーマットを示す。

１パスＲＯ獲得プロトコルを除いて、ＲＯＡＰスイートに含まれるプロトコルのすべては、ＲＯＡＰトリガを使用して開始されることが可能である。また、デバイス２０２は、ユーザ対話の結果、一方的にプロトコルを開始することもできる。ＲＩ２０４は、ＲＯＡＰトリガを生成して、デバイス２０２に送信して、ＲＯＡＰプロトコル交換をトリガする。代替として、ＲＩ２０４は、必要な情報（ＲＯ識別子やドメイン識別子などの）を他のシステムに供給することによって、ＲＯＡＰトリガ生成をこれらのシステムに委任してもよい。また、ＲＯＡＰトリガ（ＲＩ２０４によって直接に生成されたか、間接的に生成されたかにかかわらず）は、他のシステム（例えば、ＣＩ）によってデバイス２０２に送信されることも可能である。

デバイス２０２が、ＲＯＡＰトリガを受信すると、デバイス２０２は、可能な限り早くＲＯＡＰプロトコル交換を開始する。ＲＯＡＰトリガを受信した結果、ＲＯＡＰプロトコルを開始するのに先立って、適切なユーザ同意が、得られていなければならない。ＲＯＡＰは、いくつかのプロトコルを含むので、ＲＯＡＰトリガは、デバイス２０２によって開始されるべき実際のプロトコル（例えば、登録、ＲＯ獲得、ドメイン参加、またはドメイン退去）の指示を含む。

ＲＯＡＰメッセージ、およびこれらのメッセージが、プロトコルによって、どのように扱われるかは、ＲＯ，および関連する処理を提供するだけでなく、ＯＭＡ ＤＲＭ２．０におけるＲＯを取り巻くセキュリティ機能も提供する。より具体的には、以下のセキュリティ態様および信頼態様が、ＲＯＡＰプロトコルによって扱われる。すなわち、

１．ＲＩとデバイスの間の相互認証、

２．様々なメッセージにおいてナンスを使用することによって、リプレー攻撃に対処すること、

３．ＲＯＡＰメッセージ、およびＲＯＡＰメッセージの諸部分の完全性を保護すること、および

４．ＲＯＡＰメッセージ、またはＲＯＡＰメッセージの諸部分におけるセキュリティで保護されたＤＲＭ時間の検証である。

（信頼されるコンピューティング技術）

最近、信頼されるコンピューティング技術が、おおむね、ＴＣＧ（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ）の技術的傘下において文献および製品に出現している。ＴＣＧ技術は、コンピューティングエンティティが、信頼チェーンを使用することによって、エンティティ、および他のデバイスの信頼性を確立することができ、したがって、そのようなデバイス上の処理またはコンピューティングは、以下のとおりであることが可能である。すなわち、

１．プラットフォーム、ならびに様々なＨＷ（ハードウェア）構成要素およびＳＷ（ソフトウェア）構成要素の信頼性に関して評価され、

２．適切な信頼レベルが確立された場合にだけ、検証され、外部要求があると、エンティティまたはデバイス自らに対して、ならびに他のエンティティまたはデバイスに対して検証されることが可能であり、さらに

３．外部パーティは、他のデバイスとの情報および処理の交換に関する評価および決定を実行することができ、そのようなターゲットデバイスの表明された信頼レベルに基づく。

ＴＣＧは、以下のフィーチャを有する、ＴＰＭ（信頼される処理モジュール）と呼ばれるコア処理モジュールを定義する。すなわち、

１．モジュール、およびモジュールのインタフェースの物理的保護、

２．保護された揮発性のストレージスペース、および保護された不揮発性のストレージスペース、

３．暗号化、およびデジタル署名を実行することができるモジュール内部の保護された暗号化機能、

４．ハッシュ拡張によるプラットフォーム、およびプラットフォームのＳＷ構成要素の「状態」を連続的にキャプチャするＰＣＲ（プラットフォーム構成レジスタ）の使用、

５．デバイスの認証のルートの役割をするが、ただし、直接的な仕方でそのような役割をするのではないＰＫＩに基づく、デバイス特有のセキュリティで保護されたＥＫ（承認鍵）の存在。ＥＫは、決して外部に開示されないが、ＡＩＫ（構成証明アイデンティティ鍵）と呼ばれるＥＫのエイリアスが、プラットフォームの完全性測定値に署名するのに使用され、さらに

６．データの「密封」を、ＡＩＫによって署名されたＰＣＲ値と併せて、メモリ「ＢＬＯＢ」の中で使用して、プラットフォーム完全性またはＳＷ完全性（ＴＰＭからの、または密封メモリＢＬＯＢからの合致するＰＣＲ値によって測定され、検証された）が検証された場合に限って、データがアクセスされる、または抽出されることが可能であるようにすること。

信頼されるコンピューティング技術が、特に移動電話デバイスのコンテキストにおいて、そのような移動デバイス上のＤＲＭアプリケーションをセキュリティで保護することへの可能な応用のために、検査される。ＴＣＧ技術の使用によってＤＲＭアプリケーションをセキュリティで保護するようにこれまでに提案された方法は、ＴＰＭ密封の手続き、およびメモリＢＬＯＢを使用して、ＴＣＧ鍵を使用するＲＯＡＰプロトコル処理の後、ＴＰＭ、および鍵保護を有するストレージエリアの中にＤＲＭ関連のデータをセキュリティで保護された仕方で格納することを含んでいた。

しかし、既存の従来技術は、プラットフォーム、および／またはＤＲＭソフトウェアに対してどのように「信頼」を確立し、使用すべきかを明示的に扱う、または秩序立った仕方で扱うことはしない。また、従来技術は、ＲＯＡＰメッセージの中の完全性をセキュリティで保護して、ＯＭＡ ＤＲＭ２．０システムにおける完全性処理を強化することもしない。本発明は、そのような目的で新たな技術を含む。

現在のＯＭＡ ＤＲＭ２．０仕様は、ＣＡ、ＲＩ、およびデバイスが関与するＰＫＩに基づく、強いセキュリティ方法を提供する。しかし、ＯＭＡ ＤＲＭ２．０仕様の範囲内でも、ＯＭＡ ＤＲＭ２．０準拠であるデバイスおよびＲＩの不特定の実施に関連しても、プラットフォーム、ＳＷ、エージェント、およびメッセージのセキュリティおよび完全性と関係する脆弱性が、存在する。

ＯＭＡ ＤＲＭ仕様は、デバイスまたはＲＩが、ＯＭＡ ＤＲＭ２．０仕様を遵守している場合でも、いずれのデバイスまたはＲＩも直面する可能性がある様々な脅威および脆弱性を認識している。これらの脆弱性には、以下が含まれる。すなわち、

１．攻撃者が、ＤＲＭシステムのエンティティを物理的に、またはそれ以外で侵害しようと試みることが可能な、エンティティ侵害。エンティティ侵害攻撃のタイプには、デバイス上のＤＲＭエージェント、およびＲＩにおけるＤＲＭ ＳＷを侵害することが含まれる。エンティティ侵害の結果には、秘密鍵、ドメイン鍵、ＲＯ暗号化鍵、コンテンツ暗号化鍵、および保護されたコンテンツの開示、ならびに、例えば、ＤＲＭエージェントのリプレーキャッシュの完全性保護が失われること、および／またはＤＲＭエージェントの内部に格納された権利の保護が失われることが含まれる。さらに、ＤＲＭ時間が失われることが、生じる可能性もある。侵害されたＣＡまたはＯＣＳＰレスポンダのＰＫＩに対する影響は、例えば、非特許文献１において説明される。

ＯＭＡ ＤＲＭシステムは、侵害されたエンティティによって生じる損害を最小限に抑えるのに、証明書取り消しに依拠する。ＤＲＭエージェントおよびＲＩは、エンティティの証明書ステータスを調べることによって、ＤＲＭエージェントおよびＲＩが通信している相手のエンティティが、侵害されていないことを常に検証しなければならない。エンティティ侵害攻撃は、「順方向」でも、「逆方向」でも行われる可能性がある。順方向侵害攻撃は、ＤＲＭエンティティ（ＲＩ、ＤＲＭエージェント、ＣＩ、ＣＡ、またはＯＣＳＰレスポンダ）に対してであり、許可のない振舞いにつながる。逆方向侵害攻撃は、ＤＲＭエージェントのセキュリティ、完全性設定、および構成を無力化する、または脆弱にする。

２．攻撃者が、ＤＲＭエージェントとＲＩの間で送信されるメッセージを削除することができ、通常、ＤｏＳ（サービス拒否）攻撃をもたらすメッセージ削除。メッセージ削除攻撃には、登録プロトコル中、またはＲＯ獲得プロトコル中のメッセージ削除、リプレーナンス削除、ＲＯＡＰトリガの削除などが含まれることが可能である。

３．攻撃者が、ＤＲＭエージェントとＲＩの間で送信される任意のメッセージを変更することができ、通常、ＤｏＳ攻撃をもたらすメッセージ変更。メッセージ変更攻撃には、登録プロトコル中の変更、ドメイン参加プロトコル中の変更、およびドメイン退去プロトコル中の変更、ならびに様々なＲＯＡＰトリガに対する変更が含まれることが可能である。

４．攻撃者が、ＲＩとＤＲＭエージェントの間の任意のポイントで通信チャネルにメッセージを挿入することができるメッセージ挿入。また、攻撃者は、メッセージを記録して、これらのメッセージを後の時点でリプレーしようと試みることもできる。メッセージ挿入攻撃は、登録プロトコルの最中に挿入されたメッセージ、２パスＲＯ獲得プロトコルの最中に挿入されたメッセージ、１パスＲＯ獲得プロトコルの最中に挿入されたメッセージ、および様々なＲＯＡＰトリガに挿入されたメッセージを含むことが可能である。

５．一般的なＤｏＳ攻撃、トラフィック解析などの受動的攻撃、およびプライバシー開示などのその他の攻撃。

現在のＯＭＡ ＤＲＭ仕様およびＯＭＡ ＤＲＭ実施形態の以下の問題が、特定される。ＯＭＡ ＤＲＭスキームに適用された「完全性」の拡大された概念が、定義される。従来の意味で、ＯＭＡ ＤＲＭ仕様は、ＲＯＡＰメッセージ完全性の小さい範囲だけしか扱わない。本発明において定義される完全性の拡大された概念において、以下において、どこで、どのような種類の完全性が考慮されることが可能であるか留意されたい。

１．ＤＲＭプラットフォーム完全性。ＤＲＭプラットフォーム完全性は、プラットフォームエンティティにおける、またはプラットフォームエンティティ内の、すなわち、デバイス、ＲＩ、およびコンテンツ機能を含む物理的エンティティにおける完全性と関係する。異なるエンティティには、ＯＳ（オペレーティングシステム）、起動コード（例えば、ＰＣの事例におけるＢＩＯＳ）、メモリアクセスのためのＨＷ／ＦＷ（ファームウェア）／ＳＷ、セキュリティ関連の機能（暗号法および鍵管理、ならびにポリシー、証明書などの秘密データの特権的格納）を処理する様々なＨＷ／ＦＷ／ＳＷエンティティ、ならびにネットワーク接続ＨＷ／ＦＷ／ＳＷおよびローカル接続ＨＷ／ＦＷ／ＳＷが含まれる。プラットフォーム完全性は、プラットフォームが、有効であり、真性であり、正当なプロセスによる他は、変更されておらず、意図されるとおりにしか動作しないかどうかを判定する。

２．ＤＲＭ ＳＷ完全性。ＤＲＭ ＳＷとは、ＯＭＡ ＤＲＭ仕様、およびＯＭＡ ＤＲＭ仕様の手続きに特有の機能を実行するデバイス内、ＲＩ内、またはＣＩ内に存在するソフトウェアエンティティおよびソフトウェア構成要素を指す。デバイスにおいて、ＤＲＭエージェントは、ＤＲＭ ＳＷから成る。ＲＩおよびＣＩにおいて、ＤＲＭ ＳＷとは、ＲＯパッケージ化、ＤＣＦフォーマット、コンテンツ暗号化、コンテンツ配信もしくはＲＯ配信、検証、ＲＯＡＰ処理などのＤＲＭ特有の機能を実行するＳＷのセットをまとめて指す。ＤＲＭ ＳＷ完全性は、ＤＲＭ ＳＷが、有効であり、真性であり、正当なプロセスによる他は、変更されておらず、意図されるとおりにしか動作しない場合に、維持される。

３．ＲＯＡＰメッセージおよびＲＯＡＰ情報の完全性。ＲＯＡＰメッセージ、およびこれらのメッセージを構成する情報の完全性は、そのような情報が、有効であり、真性であり、正当なプロセスによる他は、変更されていない場合、維持される。ＯＭＡ ＤＲＭ２．０仕様において、ＲＯＡＰメッセージのいくつかのサブセット、およびこれらのサブセットを構成する情報は、デジタル署名の使用によって完全性保護される。

４．メディアオブジェクトおよびＤＲＭコンテンツの完全性。メディアオブジェクトおよびＤＲＭコンテンツも、完全性保護されなければならず、すなわち、メディアオブジェクトおよびＤＲＭコンテンツが、デバイスにおいて格納されているか、ＲＩにおいて格納されているか、ＣＩにおいて格納されているか、あるいはいずれかの２つのパーティ間で伝送中または配信中であるかにかかわらず、変更される、削除される、または不正に挿入されることがあってはならない。特に関心を引くのが、ＤＲＭコンテンツが、基本的に開かれたチャネルを使用して配信される場合の、移動デバイスへのコンテンツの転送に適用可能な、コンテンツのＯＴＡ（無線）配信である。

５．ＤＲＭ関連の情報の完全性。エンティティＩＤ（デバイスＩＤ、ＲＩ ＩＤなど）、暗号化鍵（ＣＥＫ、ＲＥＫ）および署名鍵、ＲＯ自体、コンテキスト情報、証明書、およびその他の信頼チェーン関連の情報などのＤＲＭ関連の情報は、セキュリティで保護されなければならず、このことは、これらの情報が、機密性を保護されるだけでなく、完全性も保護されなければならないことを意味する。

現在のＯＭＡ ＤＲＭ２．０仕様も、既存の従来技術も、エンティティ侵害または完全性問題に対するソリューションを提供したように思われないことに留意されたい。ソリューションのこの欠如は、以下の問題をもたらす。すなわち、例えば、すべてのＲＯＡＰ手続きが、ＯＭＡ ＤＲＭ２．０仕様に準拠して正しく実施された場合でも、ＲＩのプラットフォームが信頼できるかどうか、デバイスはどのようにして本当に知ることができるか。つまり、ＲＩのプラットフォームが、ＲＯＡＰプロトコルの一環としてデバイスが送信するデータを乱用しないかどうか、またはＤＲＭ処理自体を乱用しないかどうかを、デバイスは、どのようにして知ることができるか。例えば、デバイスは、ＲＩのプラットフォームＳＷが、侵害されており、デバイスのさもなければ有効な使用権利を制限するため、ＲＩが、デバイスの使用権利を恣意的に、誤って制限するかどうかを知らない。ＤＲＭソフトウェアの完全性の問題に関して、同様の問題が生じる。より具体的には、前述した完全性の拡大された概念から見た現在のＯＭＡ ＤＲＭ２．０システムの問題のいくつかは、以下のとおりである。

１．プラットフォームおよびＤＲＭ ＳＷの完全性を検査して、報告する方法の欠如。前段で特定されたエンティティ侵害脅威と関係して、ＯＭＡ ＤＲＭ２．０仕様によって指定される、またはＴＣＧ１．２使用事例の一環としての、デバイスとＲＩとの間の明確な、構造化されたプラットフォーム完全性検証、およびＳＷエージェント完全性検証のための方法は、従来技術において、全く存在しない。このことは、ＤＲＭエージェントに関してだけでなく、プラットフォーム完全性検証に関して特に当てはまる。

２．プラットフォーム（デバイスと関係して、ＰＣもしくはＰＤＡ，あるいはＲＩに関して、サーバなどの）が、悪意のある仕方で侵害されることが可能であり、これにより、ＤＲＭエージェントおよびＲＩエージェントＳＷが、正しい、機密性保護され、完全性保護された情報を与えられても、正しく動作することが妨げられることになる可能性がある。例えば、さもなければよく保護されたＤＲＭエージェントＳＷが、処理に先立って、処理中に、または処理後に、いくらかの情報を共有メモリの中に平文で格納する可能性がある。侵害されたプラットフォームは、そのような事例において、共有メモリにひどくアクセスして、情報を削除する、情報を変更する、または新たな偽の情報を挿入して、この情報が、そのような偽の情報を真性と認識する可能性があるＤＲＭエージェントＳＷによって後に処理される得る可能性がある。このことは、ＤｏＳ攻撃、プライベート情報の許可のない開示、またはＤＲＭ ＲＯもしくはＤＲＭコンテンツの許可のない配信、配布、または消費をもたらす可能性がある。

３．ＤＲＭ関連の情報を処理するＳＷの部分であるＤＲＭエージェントＳＷおよびＲＩ ＳＷが、様々な理由で侵害される可能性がある。そのようなＳＷが、例えば、ウイルス、または他の悪意のあるＳＷエンティティによって変更されることが可能である。プラットフォームまたはＤＲＭ ＳＷのそのような侵害の１つの結果は、ＯＭＡ ＤＲＭ２．０が考慮するメッセージおよび情報、特にＲＯＡＰプロトコルメッセージの完全性が後に侵害されることである。１つには、ＲＯＡＰメッセージのすべてではなく、一部だけが完全性保護されるため、ＲＯＡＰメッセージは、理論上、侵害されたデバイスと、不正な、つまり、侵害されたＲＩとの間で同期された仕方で操作されることが可能である。メッセージは、デバイスとＲＩの両方において同期した仕方で変更されることが可能であり、メッセージは、同一の仕方で変更されたため、それでも、「完全性検証」されているように見える可能性がある。

４．ＲＯＡＰメッセージの不十分な完全性保護。メッセージ完全性と関係して、ＲＯＡＰメッセージ、および様々なメッセージフィールドによって担持される情報は、ＯＭＡ ＤＲＭ２．０仕様によっては解決されない脆弱性を被る。例えば、ＯＭＡ ＤＲＭ２．０仕様の中で現在、指定されているＲＯＡＰメッセージ完全性保護は、以下のような穴を残す。すなわち、

４Ａ．すべてのＲＯＡＰメッセージが、完全性保護されるわけではない。すべてのメッセージの中にデジタル署名を含めるわけではないことにより、一部の場合において脆弱性がもたらされる可能性がある。

４Ｂ．ＲＯＡＰメッセージ、または情報の一部のフィールドが、デジタル署名によって完全性保護されている場合でさえ、一旦、そのような情報が解読され、完全性検査され、その後、平文で使用されると、悪意のあるエンティティが、この平文情報にアクセスして、それまでに完全性検査された情報を削除する、改変する、または再配布する可能性がある。このため、強化された完全性保護が、要求される。

５．ＤＲＭコンテンツ、およびＤＲＭコンテンツの配信の完全性に関する脆弱性。より具体的には、以下の問題が存在する。すなわち、

５Ａ．コンテンツ完全性検査機構が、不完全である。例えば、コンテンツが伝送されている、または配信されている（例えば、ＯＴＡダウンロード）最中のコンテンツの完全性が、規定されていない。例えば、ＤＦＣに関する署名は、ＲＯＡＰ手続きにおいて使用するためにだけ生成される。ＲＯＡＰ手続きが行われるまで、この手続きより前に、例えば、ＣＩにおける格納中に、コンテンツ完全性を管理する完全性検査機構は、全く存在しない。

５Ｂ．コンテンツ暗号化は、ＲＯＡＰプロトコルにおいて使用するためにさえ、必須であるが、完全性検査は、単にオプションである。

５Ｃ．特に、ストリーミングサービスに関するパケット化されたコンテンツに関して、ＰＤＣＦフォーマットは、タイミング問題を有する。不正に変更されているパケットが、ダウンロードされる可能性があり、ストリーム全体の完全性が検査されることが可能である前に、消費される（すなわち、メディアプレーヤ上で再生される）可能性さえある。

ＩＥＴＦ ＲＦＣ３２８０

中心的問題は、以下のとおりとなる。すなわち、様々なパーティ（デバイス、ＲＩ、およびＣＩ）はどのようにして、プラットフォーム完全性、およびＤＲＭ ＳＷ完全性を確信することができるか。このため、ＤＲＭエージェントＳＷまたはＲＩ ＳＷが依拠するプラットフォーム（例えば、ＯＳ、ＢＩＯＳ，ドライバ、メディアプレーヤ、通信ソフトウェア、共有メモリなど）の完全性を強化し、検証する方法が、必要とされる。本発明は、従来技術の欠点に対処する。

本発明は、ＯＭＡ ＤＲＭ仕様 ｖ２．０と関係するエンティティ、メッセージ、および処理の完全性を強化するいくつかの方法を開示する。これらの方法は、業界フォーラム、ＴＣＧ（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ）によって規定される、信頼されるコンピューティング（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ）技術として一般に知られる技術を使用する。本発明の第１の実施形態において、ＤＲＭ ＲＯＡＰ仕様およびＤＣＦ仕様の変更を伴う場合と、伴わない場合の両方の、プラットフォームおよびＤＲＭ ＳＷの完全性または信頼性を検証する技術が、開示される。第２の実施形態において、既存のＲＯＡＰプロトコルを変更することなしに、ＯＭＡ ＤＲＭ ＲＯＡＰメッセージ、ＲＯＡＰメッセージを構成する情報、およびＲＯＡＰ処理の完全性を強化する技術が、開示される。第３の実施形態において、既存のＲＯＡＰプロトコルのいくつかの変更を伴って、ＲＯＡＰメッセージ、情報、および処理の完全性を強化する技術が、開示される。

本発明のより詳細な理解は、例として与えられ、添付の図面と併せて理解されるべき、好ましい実施形態の以下の説明から得ることができる。

既存のＯＭＡ ＤＲＭ２．０機能アーキテクチャを示すブロック図である。 既存のＯＭＡ ＤＲＭ２．０ ＲＯＡＰ ４パス登録プロトコルを示す流れ図である。 既存のＯＭＡ ＤＲＭ２．０ ＲＯＡＰ ２パスＲＯ獲得プロトコルを示す流れ図である。 既存のＯＭＡ ＤＲＭ２．０ ＲＯＡＰ １パスＲＯ獲得プロトコルを示す流れ図である。 既存のＯＭＡ ＤＲＭ２．０ ＲＯＡＰ ２パスドメイン参加プロトコルを示す流れ図である。 既存のＯＭＡ ＤＲＭ２．０ ＲＯＡＰ １パスドメイン退去プロトコルを示す流れ図である。 ＯＭＡ ＤＲＭ２．０エンティティ間のマルチパーティプラットフォーム完全性検査を示すブロック図である。 ２つのエンティティが、デバイスとＲＩ、またはデバイスとＣＩであることが可能である場合の２つのエンティティ間でプラットフォーム完全性検証を実行するための方法を示す流れ図である。 従来の信頼検査を使用してデバイスとＲＩの間で相互プラットフォーム完全性検査を実行するための４パスＲＯＡＰ登録プロトコルを示す流れ図である。 変更されたデバイスハローメッセージ、および変更されたＲＩハローメッセージを使用して、デバイスとＲＩの間で相互プラットフォーム完全性検査を実行するための４パスＲＯＡＰ登録プロトコルを示す流れ図である。 ２つのエンティティが、デバイスとＲＩ、またはデバイスとＣＩであることが可能である場合の２つのエンティティ間でＤＲＭソフトウェア完全性検査を実行するための方法を示す流れ図である。 デバイスとＲＩの間で相互ＤＲＭソフトウェア完全性検査を実行するための２パスＲＯＡＰ ＲＯ獲得プロトコルを示す流れ図である。 密封結び付け、およびメモリＢＬＯＢ生成を含むＴＣＧ技術を使用したＲＯＡＰメッセージおよびＲＯＡＰ処理の完全性を向上させるための方法を示す流れ図である。

以降、「無線送信／受信ユニット」（ＷＴＲＵ）という用語には、ユーザ機器、移動局、固定加入者ユニットもしくは移動加入者ユニット、ポケットベル、または有線環境または無線環境において動作することが可能な他の任意のタイプのデバイスが含まれるが、以上には限定されない。以降、言及される場合、「基地局」という用語には、ノードＢ、サイトコントローラ、アクセスポイント、または無線環境における他の任意のタイプのインタフェースデバイスが含まれるが、以上には限定されない。

本発明は、ＤＲＭエンティティ（例えば、デバイス、ＲＩ、またはＣＩ）の信頼状態または完全性に関する情報が、ＯＭＡ ＤＲＭ手続きの前提条件として、いずれの２つのＤＲＭエンティティの間でも明示的に、相互に要求され、交換される方法を開示する。

この方法の一般的なアーキテクチャ７００が、図７に示される。このアーキテクチャは、４つのＤＲＭエンティティ、すなわち、デバイス７０２、ＲＩ７０４、ＣＩ７０６、およびＰＣＡ（プライベート証明機関）７０８を含む。プラットフォーム完全性検査は、ＰＣＡ７０８が、その他のＤＲＭエンティティ（例えば、デバイス７０２、ＲＩ７０４、およびＣＩ７０６）に関する信頼されるコンピューティング（例えば、ＴＣＧ）資格証明のレコードを有し、それらのＴＣＧ資格証明の証明に関する信頼のルートを提供するものと想定する。

互いの間で相互プラットフォーム完全性検査を望む任意のエンティティペア（例えば、デバイス７０２とＲＩ７０４、デバイス７０２とＣＩ７０６、またはＲＩ７０４とＣＩ７０６）が、信頼されるコンピューティング対応である（例えば、ＴＣＧ ＴＰＭ（信頼される処理モジュール）７１０を備えている）。このことは、信頼されるコンピューティング対応のＤＲＭエンティティが、ＴＰＭ７１０（または均等物）を有するだけでなく、ＡＩＫ７１２、ＳＭＬ７１４、およびＢＬＯＢを使用する保護されたメモリ７１６などの、関連するＴＣＧリソースも有することを暗示する。やはり存在するのが、ＯＳまたはプラットフォームソフトウェア７１８およびＤＲＭソフトウェア７２０である。

以上の要件が満たされる場合、様々なＤＲＭエンティティの任意のペアが、ＰＣＡ７０８、および信頼されるコンピューティング能力を使用して、プラットフォーム完全性またはプラットフォーム信頼状態を互いに検査することができる。例として、デバイス７０２とＲＩ７０４の間の相互完全性検査のための手続きは、以下のとおりである。

デバイス７０２、ＲＩ７０４、およびＣＩ７０６がすべて、ＯＳ構成要素、または他のプラットフォームソフトウェア構成要素の自己検査（ステップ７３０）、およびＤＲＭソフトウェアの自己検査（ステップ７３２）を実行することができる。自己検査は、より大きい検証プロセス（後段でより詳細に説明される）の一環として要求されることも、スタンドアロンのプロセスであることも可能である。これらの自己検査のいずれかが不合格であった場合、そのことは、そのエンティティが、侵害されており、信頼されるべきでないことの表れである可能性がある。

デバイス７０２は、デバイス７０２のプラットフォームＴＣＧ資格証明をＲＩ７０４に送信する（ステップ７４０）。プラットフォームＴＣＧ資格証明の例には、署名されたＴＣＧプラットフォーム証明書、または署名されたＴＰＭ証明書が含まれるが、以上には限定されない。資格証明の一部として、デバイス７０２は、自己証明された信頼状態フラグ、または自己証明されたプラットフォーム完全性検査済みフラグを補足的な情報として、ＲＩ７０４に送信することもできる。デバイス７０２が、ＲＩ７０４のプラットフォーム完全性を検証する場合、ステップ７４０で送信される資格証明情報は、ＲＩ７０４が、デバイス７０２のプラットフォーム完全性を検証する手続きを開始することをデバイス７０２が望むという、デバイス７０２による指示も含む。デバイス７０２は、ＲＩのプラットフォーム完全性ステータスの検証がオプションのフィーチャである場合に限って、ＲＩ７０４のプラットフォーム完全性を検証すべきかどうかに関する決定を行うことができ、一実施形態では、ＲＩのプラットフォーム完全性を検証することは、必須のフィーチャであることに留意されたい。

デバイス７０２から資格証明情報を受信すると、ＲＩ７０４は、この資格証明情報をＰＣＡ７０８に中継し（ステップ７４２）、デバイス７０２についての資格証明、特に、デバイスの最新の信頼性を検証するよう、ＰＣＡ７０８に要求も行う。すると、ＰＣＡ７０８は、デバイス７０２に関する最新の信頼性情報（例えば、プラットフォーム信頼レベルなど）をＲＩ７０４に送信する（ステップ７４４）。ＰＣＡ７０８からデバイスプラットフォーム信頼性情報を受信し、オプションとして、デバイス７０２から補足的な情報も受信すると、ＲＩ７０４は、デバイス７０２の信頼レベルを評価する。ＲＩ７０４は、デバイスプラットフォームの完全性に十分な信頼を与えて、登録プロトコルまたはＲＯ獲得プロトコルなどのＤＲＭ手続きをさらに進めるかどうかを決定する。

デバイス７０２は、必須の手続きとして、またはオプションの手続きとして、ステップ７４０〜７４４の場合と同様な、相互の仕方でＲＩ７０４のプラットフォーム完全性を評価することができる。より具体的には、ＲＩ７０４が、ＲＩ７０４のプラットフォームＴＣＧ資格証明についての情報を、デバイス７０２に送信する（ステップ７５０）。資格証明の一部として、ＲＩ７０４は、自己証明された信頼状態フラグ、または自己証明されたプラットフォーム完全性検査済みフラグを補足的情報として、デバイス７０２に送信することもできる。

ＲＩ７０４からＴＣＧ関連の情報を受信すると、デバイス７０２は、この情報をＰＣＡに中継し（ステップ７５２）、ＲＩ７０４についての資格証明、特に、ＲＩの最新の信頼性を検証するよう、ＰＣＡ７０８に要求も行う。すると、ＰＣＡ７０８は、ＲＩ７０４に関する最新の信頼性情報をデバイス７０２に送信する（ステップ７５４）。ＲＩ７０４に関してＰＣＡ７０８からＲＩプラットフォーム信頼性情報を受信し、オプションとして、ＲＩ自体から補足的な情報も受信すると、デバイス７０２は、ＲＩ７０４の信頼レベルを評価する。デバイス７０２は、ＲＩプラットフォームの完全性に十分な信頼を与えて、登録プロトコルまたはＲＯ獲得プロトコルなどのＤＲＭ手続きをさらに進めるかどうかを決定する。

デバイス７０２は、必須の手続きとして、またはオプションの手続きとして、ＣＩ７０６のプラットフォーム完全性を評価することができる。ＣＩ７０６が、ＣＩ７０６のプラットフォームＴＣＧ資格証明についての情報を、デバイス７０２に送信する（ステップ７６０）。資格証明の一部として、ＣＩ７０６は、自己証明された信頼状態フラグ、または自己証明されたプラットフォーム完全性検査済みフラグを補足的な情報として、デバイス７０２に送信することもできる。

ＣＩ７０６からＴＣＧ関連の情報を受信すると、デバイス７０２は、この情報をＰＣＡに中継し（ステップ７０６）、ＣＩ７０６についての資格証明、特に、ＣＩの最新の信頼性を検証するよう、ＰＣＡ７０８に要求も行う。すると、ＰＣＡ７０８は、ＣＩ７０６に関する最新の信頼性情報をデバイス７０２に送信する（ステップ７６４）。ＣＩ７０６に関してＰＣＡ７０８からＣＩプラットフォーム信頼性情報を受信し、オプションとして、ＣＩ自体から補足的な情報も受信すると、デバイス７０２は、ＣＩ７０６の信頼レベルを評価する。デバイス７０２は、ＣＩプラットフォームの完全性に十分な信頼を与えて、ＤＲＭ手続きをさらに進めるかどうかを決定する。

デバイス７０２のプラットフォーム完全性が、以下のとおり、ＣＩ７０６によって検証されることが可能である。デバイス７０２は、デバイス７０２のプラットフォームＴＣＧ資格証明についての情報をＣＩ７０６に送信する（ステップ７７０）。資格証明の一環として、デバイス７０２は自己構成証明信頼状態検査フラグまたはプラットフォーム完全性検査フラグを補足情報としてＣＩ７０６に送信することも可能である。デバイス７０２が、ＣＩ７０６のプラットフォーム完全性を検証する場合、ステップ７７０で送信される資格証明情報は、ＣＩ７０６が、デバイス７０２のプラットフォーム完全性を検証する手続きを開始することをデバイス７０２が望むという、デバイス７０２による指示も含む。デバイス７０２は、ＣＩのプラットフォーム完全性ステータスの検証がオプションのフィーチャである場合に限って、ＣＩ７０６のプラットフォーム完全性を検証すべきかどうかに関する決定を行うことができ、一実施形態では、ＣＩのプラットフォーム完全性を検証することは、必須のフィーチャであることに留意されたい。

デバイス７０２から資格証明情報を受信すると、ＣＩ７０６は、この資格証明情報をＰＣＡ７０８に中継し（ステップ７２２）、デバイス７０２についての資格証明、特に、デバイスの最新の信頼性を検証するよう、ＰＣＡ７０８に要求も行う。すると、ＰＣＡ７０８は、デバイス７０２に関する最新の信頼性情報をＣＩ７０６に送信する（ステップ７７４）。ＰＣＡ７０８からデバイスプラットフォーム信頼性情報を受信し、オプションとして、デバイス７０２から補足的な情報も受信すると、ＣＩ７０６は、デバイス７０２の信頼レベルを評価する。ＣＩ７０６は、デバイスプラットフォームの完全性に十分な信頼を与えて、ＤＲＭ手続きをさらに進めるかどうかを決定する。

前述の例では、ステップ７４０〜７４４は、デバイス７０２が、ＲＩ７０４に対してデバイス７０２の完全性ステータスを検証するのに、本発明の必須のフィーチャであることに留意されたい。しかし、デバイス７０２に対してＲＩ７０４のプラットフォーム完全性を検証すること（ステップ７５０〜７５４）、デバイス７０２に対してＣＩ７０６のプラットフォーム完全性を検証すること（ステップ７６０〜７６４）、およびＣＩ７０６に対してデバイスプラットフォーム完全性を検証すること（ステップ７７０〜７７４）は、ＤＲＭシステムにおける、オプションであるが、それでも強く推奨されるフィーチャである。

これらの手続きは、検証される必要があるエンティティによる能動的な開始によって開始される必要はないことにも留意されたい。これらの完全性検証手続きは、その他のパーティの完全性を検証することを所望するエンティティによる要求で始まることが可能である。そのような場合において、ステップ７４０、７５０、７６０、または７７０のそれぞれには、その他のパーティのプラットフォーム完全性の検証を要望するエンティティが、関係のある信頼関連の情報を送信するよう、その他のパーティを呼び出す、またはその他のパーティに要求する別のステップが先行する。

代替の実施形態では、実際的なＯＭＡ ＤＲＭシステム実施に関して、前述した、提案されるプラットフォーム完全性検証手続きに関する条件またはトリガ機構には、以下が含まれることが可能である。

１．デバイスプラットフォーム完全性検証手続き（すなわち、ステップ７４０〜７４４）が、以下の１つまたは複数によって実行されることが可能である。

１Ａ．デバイスが、新たな４パスＲＯＡＰ登録プロトコルを開始することを要望する前。

１Ｂ．各ＲＩにつき１回、その特定のＲＩへの最初の登録が行われる前。この場合、ＲＩは、最初の登録より前に１回、デバイスのＴＣＧ資格証明を受信し、次に、ＲＩは、デバイスの資格証明情報をＴＰＭ鍵に結び付けることによって、ＲＩ自らのＴＰＭの下で、この資格証明情報を保護する。ＲＩは、後に、この格納されたＴＣＧ資格証明の結び付きを解除して、定期的に、またはいくつかのイベント時に、例えば、ＯＣＳＰ ＣＡを調べることによって、ＲＩが受信したデバイスのＴＣＧ資格証明が依然として有効であるかどうかを検証する。

１Ｃ．定期的に、指定された時間、例えば、デバイスが、同一のＲＩに対して前回の登録プロトコルを完了して以来、Ｔ_{DEV-PLATFORM-LAST-REG}が経過するたびに。

１Ｄ．定期的に、指定された時間、例えば、デバイスが、同一のＲＩに対してデバイスの完全性ステータスを前回に検証して以来、Ｔ_{DEV-PLATFORM-LAST-REPORT}が経過するたびに。

２．ＲＩプラットフォーム完全性検証手続き（すなわち、ステップ７５０〜７５４）が実施される場合、実施される際に、実施されるプラットフォーム完全性検証手続きは、以下の１つまたは複数によって実行されることが可能である。

２Ａ．各デバイスにつき１回、その特定のデバイスへの最初の登録が行われる前。この場合、デバイスは、最初の登録より前に１回、ＲＩのＴＣＧ資格証明を受信し、次に、デバイスは、ＲＩの資格証明情報をＴＰＭ鍵に結び付けることによって、デバイス自らのＴＰＭの下で、この資格証明情報を保護する。デバイスは、後に、この格納されたＴＣＧ資格証明の結び付きを解除して、定期的に、またはいくつかのイベント時に、例えば、ＯＣＳＰ ＣＡを調べることによって、デバイスが受信したＲＩのＴＣＧ資格証明が依然として有効であるかどうかを検証する。

２Ｂ．ＲＩがデバイスに対してＲＩの完全性ステータスを検証することをデバイスが望むというデバイスからの指示を、スタンドアロンのメッセージとして、または変更されたＲＯＡＰプロトコルメッセージの一部として、ＲＩが受信するといつでも。

２Ｃ．定期的に、指定されたセキュリティで保護された時間、例えば、ＲＩが、デバイスに対してＲＩの完全性ステータスを前回に検証して以来、Ｔ_{RI-PLATFORM-LAST-REPORT}が経過するたびに。

３．デバイスとＣＩの間のプラットフォーム完全性検証に関して、前述した機構と同様の機構が、完全性検証プロセスの定期的発生および／またはイベント駆動の発生に関して考慮されることが可能である。また、ＣＩのプラットフォーム完全性のデバイスによる検証の場合、検証は、コンテンツが購入される、またはダウンロードされることが必要とされるのに先立って毎回、実行されることも可能であり、場合により、その逆（すなわち、デバイスのプラットフォーム完全性が、ＣＩに対して検証されなければならない）も同様である。

従来技術は、堅牢なＤＲＭのアプリケーションに結合されたＴＣＧ技術を使用する「セキュリティで保護された起動」の使用を考慮してきた。そのようなスキームにおいて、プラットフォームのＯＳ、および他の起動関連のコードは、デバイスが起動されるといつでも、完全性検査され、プラットフォーム完全性検査を暗黙に実行してからでないと、いずれのＤＲＭアプリケーションも実行されることが可能でない。本発明は、起動時プラットフォーム完全性検査のより系統立った、明示的な使用とともに、所定の期間に基づく他の時点におけるプラットフォーム完全性検査、ならびにいくつかのイベントの発生時のプラットフォーム完全性検査を提供する。また、本発明は、プラットフォーム完全性検査をデバイスからＲＩおよびＣＩにまで一般化する。継続的なプラットフォーム完全性検査は、デバイスが、或る特定の有効なＣＯを正しく受信しただけで、ＲＩまたはＣＩが、その時点から将来にわたって無期限に信頼できると見なされるべきことにはならないということのために、有益である。信頼性の定期的な、さらに／またはイベント駆動の継続的検証は、良好な保護機構を提供する。

また、デバイスとＣＩの間の完全性検査の必要性に関して、コンテンツが、ＲＯより前に着信した場合でも、コンテンツは、ＣＩのプラットフォームまたはＣＩのＤＲＭ ＳＷが侵害されると、侵害される可能性がある。例えば、ユーザが、或るファイルをダウンロードしたものと想定されたい。ＲＯが、まだ獲得されていない場合でも、ユーザは、コンテンツを誤ってクリックする可能性があり、あるいはコンテンツに対して有効性検査を実行する可能性がある。コンテンツが、侵害されたている（例えば、コンテンツにウイルスが添付されている）場合、コンテンツは、ＲＯなしでも、デバイスに損害を与える可能性がある。また、デバイスとＣＩの間のダウンロード前の対話において（例えば、発見段階中に）、侵害されたデバイスが、例えば、コンテンツに添付されたウイルスを、ＣＩを宛先とするメッセージに追加することによって、ＣＩに害を与える可能性がある。さらに、ビジネスの点から、ＣＩは、侵害されたデバイスにコンテンツを送信することを望まず、つまり、例えば、侵害されたデバイスは、許可のない受信者にコンテンツを無料で再配布する可能性がある。このため、デバイスとＣＩの間の相互プラットフォーム（およびＳＷ）完全性検証は、システム全体を保護することにメリットがある。

また、前段のアーキテクチャの説明において概要を述べた中心的な考えを実現する、いくつかの異なる仕方が存在することが可能であることに留意されたい。２つのそのような例が、後段で説明されるが、これらは、前段で説明されるアーキテクチャに基づくより広い概念の説明的な例に過ぎないことに留意されたい。

（プラットフォーム完全性検証）

図８は、２つのエンティティ間のプラットフォーム完全性検証を実行するための方法８００の流れ図である。この２つのエンティティは、デバイスとＲＩ、デバイスとＣＩ、またはＲＩとＣＩであることが可能である。方法８００は、ＲＥ（要求するエンティティ）とＴＥ（ターゲットエンティティ）とを利用し、つまり、ペアのいずれのエンティティ（デバイス、ＲＩ、またはＣＩ）が、ＲＥであることも可能であることに留意されたい。方法８００は、いずれのエンティティがＲＥであり、いずれのエンティティがＴＥであるかにかかわらず、同一の仕方で動作する。

方法８００は、ＲＥが、ＴＥのプラットフォーム完全性ステータスを報告するよう、ＴＥに要求を送信することから始まる（ステップ８０２）。この要求に応答して、ＴＥは、ＴＥのＴＣＧ資格証明をＲＥに送信する（ステップ８０４）。これらのＴＣＧ資格証明には、例えば、プラットフォーム資格証明、ＴＰＭ資格証明、または準拠資格証明が含まれることが可能である。次に、ＲＥが、ＴＥのＴＣＧ資格証明を、これらの資格証明の検証のためにＯＣＳＰレスポンダに送信する（ステップ８０６）。ＯＣＳＰレスポンダは、ＴＥのＴＣＧ資格証明を精査して、検証ステータスをＲＥに報告する（ステップ８０８）。

ＲＥが、ＴＥ自らのプラットフォーム完全性ステータスを報告するよう、ＴＥに要求を送信する（ステップ８１０）。ＴＥは、ＴＥのプラットフォーム完全性ステータスを検査し（ステップ８１２）、プラットフォーム完全性ステータスフラグをＲＥに送信し（ステップ８１４）、方法は、終了する（ステップ８１６）。

方法８００は、ＲＯＡＰプロトコルの変更が行われなくても（図９に関連して後段で説明される）、ＲＯＡＰプロトコルの変更が行われても（図１０に関連して後段で説明される）、適用されることが可能である。

（ＲＯＡＰプロトコルの変更なしの完全性検証）

図９は、ＲＯＡＰプロトコルとは別個にＴＣＧ技術を使用して（すなわち、ＯＣＳＰレスポンダ／ＰＣＡ９０６を利用して）、デバイス９０２とＲＩ９０４の間で完全性関連の情報を交換する方法９００の流れ図である。方法９００では、同一のエンティティ９０６が、ＤＲＭ処理のためのＰＣＡとしても、ＴＣＧ処理のためのＯＣＳＰレスポンダとしても示されていることに留意されたい。方法９００では、プラットフォーム完全性検証（破線の長方形で示される）は、ＲＯＡＰ４パス登録プロトコルに先立って実行される。登録プロトコルより前にプラットフォーム完全性検証を実行することは、登録プロトコルが、頻繁には実行されず、プラットフォーム完全性検証プロセスが、完了するのにいくらかの時間を要するため、有用であり、つまり、プラットフォーム完全性検証が、各メッセージで実行されたとした場合、システムの全体的な動作は、不必要に減速させられる可能性がある。当業者は、プラットフォーム完全性検証が実行された後、１つだけのデバイスハローメッセージが、信頼されるデバイスを示すので、ＲＩによって受信されるものと想定することができる。複数のデバイスハローメッセージが、同一のデバイスからＲＩによって受信されたとした場合、このことは、ＤｏＳ攻撃の表れである可能性がある。また、プラットフォーム完全性検証は、認証プロトコルおよびオブジェクト獲得プロトコルに関連して実行されることも可能である。

デバイス９０２は、ＲＩ９０４を相手に４パス登録プロトコルを開始することに先立って、ＲＩ９０４を相手に、プラットフォーム完全性の相互検証を実行する別の手続きセットを開始する。デバイス９０２はまず、デバイス９０２自らのＴＣＧ資格証明（例えば、プラットフォーム資格証明、ＴＰＭ資格証明、準拠資格証明など）、あるいはＴＣＧ資格証明を含む、またはＴＣＧ資格証明と関係する他の情報を、ＲＩ９０４に送信する（ステップ９１０）。オプションとして、デバイス９０２は、ＲＩ９０４自らのプラットフォーム完全性ステータスを検査して、デバイス９０２に報告するよう、ＲＩ９０４に要求を送信することも行い、この要求には、デバイス資格証明が含められる。

ＲＩ９０４は、デバイスのＴＣＧ資格証明を検証するようＰＣＡ９０６に要求する（ステップ９１２）。ＰＣＡ９０６は、ＲＩの要求に応答して、デバイスのＴＣＧ資格証明に関する情報を送信する（ステップ９１４）。

ＲＩ９０４は、デバイス９０２のプラットフォーム完全性ステータスフラグを報告するよう、デバイス９０２に要求する（ステップ９１６）。また、デバイス９０２が、ステップ９１０で、ＲＩ９０４が、ＲＩ９０４のプラットフォーム完全性ステータスを検証して、報告することを要求し、かつＲＩ９０４が、この要求に応じることを望み、応じることができる場合、ＲＩ９０４は、ＲＩ９０４自らのＴＣＧ資格証明、あるいはＴＣＧ資格証明を含む、またはＴＣＧ資格証明と関係する他の情報を、ステップ９１６で、デバイス９０２に送信する。ＲＩ９０４が、この要求に応じることができない、または応じることを望まない場合、ＲＩ９０４は、「応じない」メッセージをデバイスに送信する。ＲＩ９０４は、リソースが限られたＲＩ（すなわち、ＲＩが、この要求に応答するのに利用可能なリソースを十分に有さない）、またはデバイス信頼性検査が不合格であることを含め、いくつかの理由で、この要求に応答しない可能性がある。デバイスは、デバイスがＲＩに対して有する信用レベルに依存して、このプロトコルを中止することができ、つまり、デバイスが、ＲＩを信頼する場合、デバイスは、ＲＩが、この要求に応答することを拒否した場合でも、このプロトコルを続ける可能性が高い。ＲＩ９０４から、プラットフォームステータスを検査する要求を受信すると、デバイス９０２は、デバイス９０２自らのプラットフォーム完全性ステータスを検査する（ステップ９１８）。

デバイス９０２は、ＲＩのＴＣＧ資格証明を検証するよう、ＰＣＡ９０６に要求する（ステップ９２０）。ＰＣＡ９０６は、デバイス９０２からこの要求を受信すると、ＲＩのＴＣＧ資格証明に関する情報を戻す（ステップ９２２）。デバイス９０２は、デバイス９０２のプラットフォーム完全性ステータスフラグをＲＩ９０４に送信する（ステップ９２４）。ＲＩ９０４が、ＲＩ９０４の完全性ステータスを検査するよう、デバイス９０２から要求を受信し、ＲＩ９０４が、この要求に応じることを望み、応じることができる場合、ＲＩ９０４は、ＲＩ９０４自らのプラットフォーム完全性を検査する（ステップ９２６）。次に、ＲＩは、ＲＩのプラットフォーム完全性ステータスフラグをデバイス９０２に戻す（ステップ９２８）。ＲＩ完全性検査に関するオプションのステップは、任意の順序で実行されることが可能であり、つまり、それらのステップは、図９に示されるとおりにデバイス完全性検査と絡み合わされなくてもよい。さらに、ＲＩは、ＲＩ自らの完全性検査を開始することができる。また、ＲＩが、可能な理由のいずれかで、ＲＩ自らのＴＣＧ資格証明情報で要求に完全には応答することを拒否する場合、ＲＩは、例えば、ステップ９２２で、適切な仕方で、そのような事実をデバイスに示すことができる。

方法９００は、デバイス９０２およびＲＩ９０４が、相互プラットフォーム完全性検証を実現することを可能にする。そのような検証後、デバイスは、ＲＯＡＰ登録プロトコルを開始することができる。図９に示される登録プロトコルのステップ（ステップ９３０〜９４０）は、前述した方法２００のステップ２１０〜２２０と同一である。また、これらの手続きは、周期的な間隔でトリガされる、または繰り返されることが可能であることにも留意されたい。

（ＲＯＡＰ登録プロトコルの変更を伴う完全性検証）

図１０は、別の例示的な実施形態において、デバイス１００２とＲＩ１００４が、ＯＣＳＰレスポンダ／ＰＣＡ１００６のサービスをやはり利用して、完全性関連の情報を交換する方法１０００を示す。方法１０００では、ＲＯＡＰ登録プロトコルの既存のデバイスハローメッセージおよびＲＩハローメッセージは、ＴＣＧ資格証明と、プラットフォーム完全性検証を求める、相手への要求をともに伝えるように変更される。

デバイス１００２は、変更されたデバイスハローメッセージをＲＩ１００４に送信し（ステップ１０１０）、このメッセージは、デバイスＴＣＧ資格証明と、ＲＩ１００４のプラットフォーム完全性を報告するようにという、ＲＩ１００４へのオプションの要求とを含む。ＲＩ１００４は、これらのデバイス資格証明を、検証ためにＰＣＡ１００６に転送する（ステップ１０１２）。次に、ＰＣＡ１００６は、デバイスＴＣＧ資格証明をＲＩ１００４に戻す（ステップ１０１４）。ＲＩ１００４は、変更されたＲＩハローメッセージでデバイス１００２に応答し（ステップ１０１６）、このメッセージは、ＲＩのＴＣＧ資格証明をオプションとして含む。

次に、デバイス１００２は、オプションとして、ＲＩのＴＣＧ資格証明を検査するようＰＣＡ１００６に要求を送信する（ステップ１０１８）。ＰＣＡ１００６はＲＩの資格証明を検査し、結果をデバイス１００２に報告する（ステップ１０２０）。デバイス１００２は、デバイス１００２自らの完全性ステータスを検査し（ステップ１０２２）、完全性ステータスをＲＩ１００４に報告する（ステップ１０２４）。

デバイス１００２が、ＲＩ１００４が、ＲＩ１００４の完全性ステータスを報告することを要求した場合、ＲＩ１００４は、プラットフォーム完全性検査を実行し（ステップ１０２６）、完全性ステータス、例えば、ＲＩ１００４の信頼状態フラグを、デバイス１００２に送り返す（ステップ１０２８）。ステップ１０３０〜１０３６は、ＲＯＡＰ登録プロトコルの図２に示されるステップ２１４〜２２０と同一である。

（ＤＲＭソフトウェアの完全性を検査すること）

図１１は、ＤＲＭエンティティの任意のペアの間でＤＲＭ ＳＷ（例えば、デバイスに常駐するＤＲＭユーザエージェントＳＷ、あるいはＲＩまたはＣＩに常駐するＤＲＭ ＳＷ）の完全性を検査するための方法１１００の流れ図である。ＲＥ（要求するエンティティ）が、ＤＲＭ ＳＷ完全性検査を実行するよう、ＴＥ（ターゲットエンティティ）に要求を送信する（ステップ１１０２）。ＴＥは、ＴＥのＤＲＭ ＳＷ完全性を検査し（ステップ１１０４）、ＤＲＭ ＳＷ完全性ステータスフラグをＲＥに送信し（ステップ１１０６）、方法は、終了する（ステップ１１０８）。ＴＥが、デバイスである場合、デバイスドライバおよびメディアプレーヤＳＷの完全性が、ＤＲＭ ＳＷの完全性とは別個に検査されることが、これら２つの構成要素が、デバイス上に別々に存在する場合、可能であることに留意されたい。

方法１１００は、ＲＥが、ＴＥからＤＲＭ ＳＷ完全性検査を獲得することだけに関する。相互ＤＲＭ ＳＷ完全性検査を実行するのに、方法１１００は、ＲＥからＴＥに１回、次に、ＴＥからＲＥに１回（ＲＥとＴＥが役割を交替して）の、２回、実行される必要がある。相互ＤＲＭ ＳＷ完全性検査中、これらの要求は、絡み合わされる（図１２に示されるとおり）ことも、図１１に示されるとおり、分離されることも可能である。この方法の動作は、相互ＤＲＭ ＳＷ完全性検査が実行されている場合、変化しない。

ＯＭＡ ＤＲＭ２．０仕様は、そのような想定が、どのようにして有効に実施されることが可能であるかを示唆することなしに、ＤＲＭユーザエージェントＳＷ（または本発明において使用される用語では、デバイスＤＲＭ ＳＷ）、およびＲＩ（またはＲＩのＤＲＭ ＳＷ）が、暗黙に信頼されることが可能であるものと想定する。このため、ＯＭＡ ＤＲＭ２．０仕様における認証プロトコルは、既に信用できると考えられるエンティティ間の実際の認証手続きだけしか規定しない。明白な理由で、この暗黙のＳＷ信頼想定は、実際には、それらの想定を実施し、検証する実際のステップなしに、自動的に想定されることは可能でない。このセクションで説明される方法は、そのような具体的なステップにかかわる。

図１２は、ＲＯＡＰ ＲＯ獲得プロトコルに関連してＤＲＭ ＳＷ検査を適用するための方法１２００の流れ図である。この方法１２００は、デバイス１２０２、ＲＩ１２０４、およびＯＣＳＰレスポンダ／ＰＣＡ１２０６を利用する。第１に、ＰＣＡ１２０６は、デバイス１２０２およびＲＩ１２０４と通信して、プラットフォーム完全性検査およびＲＯＡＰ登録プロトコルを実行する（ステップ１２１０）。デバイス１２０２とＲＩ１２０４が、相互プラットフォーム完全性検査、単方向ＤＲＭ ＳＷ完全性検査、または相互ＤＲＭ ＳＷ完全性検査を実行する（ステップ１２１２）。

ＲＩ１２０４が、デバイスのＤＲＭ ＵＡ（ユーザエージェント）ＳＷ完全性を検査して、報告するよう、デバイス１２０２に要求を送信する（ステップ１２１４）。デバイス１２０２が、デバイス１２０２の最新のＤＲＭ ＵＡ ＳＷ完全性を検査する（ステップ１２１６）。デバイス１２０２は、オプションとして、ＲＩのＤＲＭ ＳＷ完全性を検査して、報告するよう、ＲＩ１２０４に要求を送信する（ステップ１２１８）。要求された場合、ＲＩ１２０４は、ＲＩ１２０４の最新のＤＲＭ ＳＷ完全性を検査する（ステップ１２２０）。デバイス１２０２が、デバイスＤＲＭ ＳＷ完全性ステータスフラグをＲＩ１２０４に送信する（ステップ１２２２）。前に要求されている場合、ＲＩ１２０４が、ＲＩ ＤＲＭ ＳＷ完全性ステータスフラグをデバイス１２０２に送信する（ステップ１２２４）。オプションのＲＩ完全性検査のステップは、任意の順序で実行されることが可能であり、図１２に示されるとおりにデバイス完全性検査と絡み合わされる必要はないことに留意されたい。

方法１２００は、例示されるデバイス／ＲＩ対話の代わりに、デバイスとＣＩの間の相互ＤＲＭ ＳＷ完全性検証に関して一般化されることが可能であることに留意されたい。ステップ１２１０〜１２２４が完了すると、デバイス１２０２は、例えば、図３に関連して前述したステップ３１０および３１２と同一であるステップ１２２６および１２２８における２パスＲＯ獲得プロトコルを開始することができる。方法１２００は、ＲＯ獲得プロトコルに関連して図示されるものの、方法１２００は、他の任意のＲＯＡＰプロトコルに関連して使用されることが可能であり、ただし、方法１２００に関連するオーバヘッドを最小限に抑えるのに、方法１２００は、任意の所与の時点で、ＲＯＡＰプロトコルの適切に選択されたサブセットだけしか伴わずに実行されることが可能であることにさらに留意されたい。実際的なＯＭＡ ＤＲＭシステム実施形態に関して、前述した、提案されるプラットフォーム完全性検証手続きおよび／またはＤＲＭ ＳＷ完全性検証手続きのための条件またはトリガ機構のいくつかには、以下が含まれることが可能である。すなわち、

１．デバイスＤＲＭ ＳＷ完全性検証手続きは、以下の１つまたは複数によってトリガされることが可能である。

１Ａ．デバイスが、新たな２パスＲＯＡＰ登録プロトコル、２パスドメイン参加プロトコル、または２パスドメイン退去プロトコルを開始することを要望する前。

１Ｂ．定期的に、指定された時間、例えば、デバイスが、同一のＲＩに対して２パスＲＯＡＰ登録プロトコル、２パスドメイン参加プロトコル、または２パスドメイン退去プロトコルを前回に完了して以来、Ｔ_{DEV-DRM-LAST-ROAP}が経過するたびに。

１Ｃ．定期的に、指定された時間、例えば、デバイスが、前回に、デバイスのＤＲＭ ＳＷ完全性ステータスを検証して、同一のＲＩに報告して以来、Ｔ_{DEV-DRM-LAST-REPORT}が経過するたびに。

１Ｄ．デバイスが、デバイスのＤＲＭ ＳＷを更新するといつでも。

１Ｅ．プラットフォームＳＷが、更新される、または変更されるといつでも。

２．ＲＩ ＤＲＭ完全性検証手続きは、以下の１つまたは複数によって実行されることが可能である。

２Ａ．ＲＩがデバイスに対してＲＩのＤＲＭ ＳＷ完全性ステータスを検証することをデバイスが望むというデバイスからの指示を、スタンドアロンのメッセージとして、または変更されたＲＯＡＰプロトコルメッセージの一部として、ＲＩが受信するといつでも。

２Ｂ．定期的に、指定された時間、例えば、ＲＩが、前回に、ＲＩのＤＲＭ ＳＷ完全性ステータスを検証して、デバイスに報告して以来、Ｔ_{RI-DRM-LAST-REPORT}が経過するたびに。

２Ｃ．ＲＩが、ＲＩのＤＲＭ ＳＷを更新するといつでも。

２Ｄ．ユーザが、ストリーミングコンテンツの場合のように、コンテンツを頻繁に獲得している場合において、デバイスがＲＯ要求を送信するのに先立って毎回。

デバイスとＣＩの間のプラットフォーム完全性検証に関して、前述した機構と同様の機構が、ＤＲＭ ＳＷ完全性検証プロセスの定期的発生および／またはイベント駆動の発生に関して考慮されることが可能である。

ＤＲＭプラットフォーム検証およびＤＲＭ ＳＷ検証のための提案される方法は、互いに無関係に実行されることが可能であるが、これらの検証手続きが、手続きのグループの一部として組み合わされることが可能であることも企図される。そのような実施形態では、ＤＲＭプラットフォーム検証ステップは、ＤＲＭ ＳＷ検証ステップの前提条件と考えられる。例えば、デバイスとＲＩの間の完全性検証のために、デバイスとＲＩはまず、前述したとおり、ＤＲＭプラットフォーム検証手続きを実行することによって、互いのプラットフォーム全体に対する信頼を確立する。トリガ機構は、一般的なプラットフォーム検証トリガ条件を含む。次に、ＤＲＭ ＳＷ検証トリガに関する条件が生じると、ＤＲＭ ＳＷ検証手続きが、その後に続く。両方のタイプの検証手続きは、それぞれのトリガ条件が満たされると、実行されることに留意されたい。しかし、ＤＲＭ ＳＷ検証ステップは、ＤＲＭプラットフォーム検証ステップが成功して完了することに追従させられ、すなわち、デバイスとＲＩの間でＤＲＭプラットフォーム検証が不合格である場合、ＤＲＭ ＳＷ検証におけるさらなる処理、ならびに実際のＤＲＭ ＲＯＡＰ処理および使用関連の処理は、失敗する。

（密封署名および結び付け）

ＲＯＡＰプロトコルの完全性を保護するＯＭＡ ＤＲＭ２．０仕様の既存の機構は、ＲＯＡＰメッセージのいくつかに、ただし、すべてにではなく、デジタル署名（またはメッセージ完全性検査）を含めることに限られる。ＲＯＡＰプロトコルが、セキュリティで保護されたＤＲＭ処理実施に中心的な重要性を有することから、ＲＯＡＰプロトコルにおいて使用され、交換される情報の完全性を保護し、絶えず検証することが重要である。

したがって、本発明の代替の実施形態では、ＤＲＭデバイスとＲＩの間の信頼できる認証および完全性検証に中心的な情報が、（１）ＴＣＧ技術を使用して安全に格納され、さらに（２）他方の側に伝送されるのに先立って、または情報が格納される側において処理のために使用されるのに先立って、事前検証されることが可能である、ＲＯＡＰプロトコルの完全性を強化する方法が、開示される。

この方法には、密封署名（すなわち、ターゲット情報を対称的に暗号化し、次に、対称鍵に加え、プラットフォームまたは特定のＳＷ構成要素のその時点で最新の完全性ステータスを示すＰＣＲ値のセットに非対称的に署名する）、および結び付け（秘密解読鍵がＴＰＭなどの、保護されたモジュールの中に保持された鍵を使用して、ターゲット情報を非対称的に暗号化する）というＴＣＧ技術を使用する２つの基本的な手続きがかかわる。密封署名は、保護されたＰＣＲ値によって示される、デバイスＤＲＭユーザエージェントＳＷの信頼状態に、非対称暗号化、デジタル署名、および結び付けによってもたらされる最高レベルの情報セキュリティを与える。結び付けは、解読鍵がＴＰＭ内部で保護される場合に、非対称暗号化を使用する高いレベルの保護を与える。

以下の体系的な原理は、密封署名、および結び付けを使用して、ＲＯＡＰメッセージの中で使用される情報の機密性と完全性をともに保護して、ＲＯＡＰプロトコル自体の完全性の強度を間接的に高める。以下の説明において、デバイスとＲＩ（またはこの特定のデバイスを扱うＲＩの部分）はともに、ＴＰＭを備えており、完全なＴＰＭ機能をサポートするものと想定される。

デバイスとＲＩはそれぞれ、デバイスまたはＲＩが存在する信頼されるプラットフォームに、ＲＯＡＰ処理と関係する或る情報を暗号上、結び付け、セキュリティで保護された仕方で格納する２つのストレージ鍵のセットを取っておき、使用することができる。デバイスに関して、これらの鍵は、Ｋ＿ＤＥＶ＿ＢＩＮＤ＿ＡおよびＫ＿ＤＥＶ＿ＢＩＮＤ＿Ｂである。ＲＩに関して、これらの鍵は、Ｋ＿ＲＩ＿ＢＩＮＤ＿ＡおよびＫ＿ＲＩ＿ＢＩＮＤ＿Ｂである。これらの鍵は、ＴＰＭによって保持される非対称鍵（すなわち、暗号化は、公開鍵を使用して行われ、解読は、ＴＰＭ内で保護された秘密鍵を使用して行われる）である。

デバイスとＲＩはそれぞれ、ＤＲＭ処理のために単一のＰＣＲ、またはＰＣＲのセットを使用する。また、デバイスとＲＩは、ＡＩＫ（構成証明アイデンティティ鍵）を取っておき、信頼されるプラットフォーム、およびそのプラットフォームの特定のＰＣＲ値に、ＲＯＡＰ処理と関係する或る情報を密封署名するのに使用する。ＴＣＧ ＡＩＫ鍵は、ＰＣＲ値に署名するためだけに使用されることに留意されたい。デバイスに関して、デバイスのＡＩＫは、Ｋ＿ＤＥＶ＿ＡＩＫであり、ＲＩに関して、ＲＩのＡＩＫは、Ｋ＿ＲＩ＿ＡＩＫである。また、密封署名は、ターゲットデータの暗号化操作のための非対称ストレージ鍵を要求する。このため、デバイスとＲＩはそれぞれ、この目的でストレージ鍵を取っておき、使用する。デバイスに関するストレージ鍵は、Ｋ＿ＤＥＶ＿ＳＴＯ＿ＳＥＡＬであり、ＲＩに関するストレージ鍵は、Ｋ＿ＲＩ＿ＳＴＯ＿ＳＥＡＬである。

この方法は、ＲＯＡＰ処理にかかわる様々な情報要素を格納することの強度を高めるように、密封署名および結び付けと、機密性および完全性を保護する追加の対策との組合せを使用する。例えば、図１３は、ＴＰＭ密封署名操作およびＴＰＭ結び付け操作を使用して、４パスＲＯＡＰ登録プロトコルを含む様々なメッセージの中の情報の機密性および完全性が保護される方法１３００の流れ図である。方法１３００では、デバイス１３０２とＲＩ１３０４がそれぞれ、４パス登録プロトコルの過程においてそれぞれが送信する（他方の側に）または受信する（他方の側から）ストレージ鍵の２つのセットを使用して、ＲＯＡＰ関連の情報の選択的なセットに密封署名し、情報を結び付ける。

デバイス１３０２がまず、暗号化鍵Ｋ＿ＤＥＶ＿ＳＴＯ＿ＳＥＡＬおよびデバイス特有のＡＩＫ、Ｋ＿ＤＥＶ＿ＡＩＫを使用して、デバイスＩＤ情報要素（ＯＭＡ ＤＲＭの場合、ＯＭＡ ＤＲＭ公開鍵のＳＨＡ−１ハッシュである）に密封署名する。この情報は、ストレージ鍵Ｋ＿ＤＥＶ＿ＢＩＮＤ＿Ａを使用して、デバイスハローメッセージ向けの他の情報に結び付けられる（非対称暗号化を使用して）（ステップ１３１０）。次に、このデバイスハローメッセージが、デバイス１３０２からＲＩ１３０４に送信される（ステップ１３１２）。

デバイスＩＤなどの情報に密封署名すること、およびデバイスハローメッセージを含む他の情報を結び付けることにより、デバイス１３０２は、デバイス１３０２が、デバイス１３０２の保護されたストレージから以前に密封署名され、結び付けられた情報を回復し（すなわち、密封署名解除して、結び付け解除し）、それらの情報を、ＤＲＭ ＳＷが使用している可能性があるような情報要素の現在の値と比較し、これらの現在の値の真正性および完全性を検証すると、その場合に限って、デバイスハローメッセージが伝送されるというポリシーを定めることもできる。このシナリオにおける、密封署名されるべき情報要素対結び付けられるべき情報要素の選択は、例として与えられているに過ぎないことに留意されたい。他の情報要素は、本発明の動作を実行することなしに、様々な組合せで密封署名され、結び付けられることが可能である。他の組合せは、システム時間、メッセージの中の任意の情報要素、アルゴリズム、およびナンスなどのアイテムから導き出されることが可能である。ナンスをセキュリティで保護する１つの理由は、一部の乱数発生器、特に有害な侵害を受けている可能性がある乱数発生器は、同一のパターンを繰り返して、同一の数を乱数発生器の出力として、容認できない短い周期で生成する可能性があるので、ナンスが本当にランダムであるかどうかを判定するためである。

ＲＩ１３０４は、デバイスハローメッセージの受信後、ＲＩ１３０４の結び付け鍵、ＫＩ＿ＲＩ＿ＢＩＮＤ＿Ａを使用して、デバイスハローメッセージの中に含まれる情報を結び付ける（ステップ１３１４）。このステップは、ＲＩ１３０４がデバイス１３０２から受信した鍵情報の、セキュリティで保護された、完全性保護された格納を可能にする。代替として、ＲＩ１３０４は、デバイスハローメッセージからデバイスＩＤ（または他の任意の情報要素）を抽出し、ＡＩＫ、Ｋ＿ＲＩ＿ＡＩＫ、および暗号化鍵Ｋ＿ＲＩ＿ＳＴＯ＿ＳＥＡＬを別々に使用して、その情報要素に密封署名することもできる。

ＲＩ１３０４が、暗号化鍵Ｋ＿ＲＩ＿ＳＴＯ＿ＳＥＡＬおよびＡＩＫ、Ｋ＿ＲＩ＿ＡＩＫを使用して、ＲＩ ＩＤおよびＲＩ ＵＲＬ情報要素に密封署名する（ステップ１３１６）。また、ＲＩ１３０４は、ストレージ鍵Ｋ＿ＲＩ＿ＢＩＮＤ＿Ａを使用して、ＲＩ１３０４のＲＩハローメッセージの中に含まれるその他の情報を結び付けることも行う（ステップ１３１６）。次に、ＲＩ１３０４は、ＲＩハローメッセージをデバイス１３０２に送信する（ステップ１３１８）。

ＲＩ１３０４は、ＲＩ１３０４がまず、保護されたストレージから以前に密封署名され、結び付けられた情報を回復し（すなわち、密封署名解除して、結び付け解除し）、それらの情報を、ＲＩ ＤＲＭ ＳＷが使用している可能性があるような情報要素の現在の値と比較し、これらの現在の値の真正性および完全性を検証すると、その場合に限って、デバイス１３０２にＲＩハローメッセージを送信する。

デバイス１３０２は、ＲＩハローメッセージを受信すると、第２の結び付け鍵、すなわち、Ｋ＿ＤＥＶ＿ＢＩＮＤ＿Ｂを使用して、ＲＩハローメッセージの中に含まれる情報を結び付ける（ステップ１３２０）。このステップは、デバイスがＲＩ１３０４から受信した鍵情報のセキュリティで保護された、完全性保護された格納を可能にする。代替として、デバイス１３０２は、受信されたＲＩハローメッセージから、選択された情報要素（ＲＩ ＩＤおよび／またはＲＩ ＵＲＬなどの）を抽出し、ＡＩＫ、Ｋ＿ＤＥＶ＿ＡＩＫおよび暗号鍵Ｋ＿ＤＥＶ＿ＳＴＯ＿ＳＥＡＬを使用して、これらの情報要素に密封署名する一方で、Ｋ＿ＤＥＶ＿ＢＩＮＤ＿Ｂを使用して、ＲＩハローメッセージの中で受信された残りの情報を単に結び付けることも可能である。

デバイス１３０２が、Ｋ＿ＤＥＶ＿ＡＩＫおよびＫ＿ＤＥＶ＿ＳＴＯ＿ＳＥＡＬを使用して、証明書チェーン、ＤＣＦハッシュ、および要求時間に密封署名する（ステップ１３２２）。次に、デバイス１３０２は、Ｋ＿ＤＥＶ＿ＢＩＮＤ＿Ａを使用して、登録要求メッセージ向けのその他の情報を結び付ける（ステップ１３２２）。次に、デバイス１３０２は、この登録要求メッセージをＲＩ１３０４に送信する（ステップ１３２４）。デバイス１３０２は、デバイス１３０２が、以前に密封署名され、結び付けられた情報を回復し（すなわち、密封署名解除して、結び付け解除し）、回復された値を、ＤＲＭ ＳＷメモリの中で使用される現在の一時的な値と比較し、これらの現在の値の真正性および完全性を検証すると、その場合に限って、この登録要求メッセージを送信する。この登録要求メッセージを受信すると、ＲＩ１３０４は、結び付け鍵、Ｋ＿ＲＩ＿ＢＩＮＤ＿Ｂを使用して、登録要求メッセージからの情報を結び付ける（ステップ１３２６）。

ＲＩ１３０４が、ＫＩ＿ＲＩ＿ＡＩＫおよびＫ＿ＲＩ＿ＳＴＯ＿ＳＥＡＬを使用して、鍵、証明書チェーン、およびＲＯに密封署名する（ステップ１３２８）。次に、ＲＩ１３０４は、密封署名された鍵、証明書チェーン、およびＲＯを、結び付け鍵Ｋ＿ＲＩ＿ＢＩＮＤ＿Ａを使用して、登録応答メッセージに含められるべき他の情報に結び付ける（ステップ１３２８）。次に、ＲＩ１３０４は、この登録応答メッセージをデバイス１３０２に送信する（ステップ１３３０）。ＲＩ１３０４は、ＲＩが、以前に密封署名され、結び付けられた情報を回復し（すなわち、密封署名解除して、結び付け解除し）、これらの回復された値を、ＤＲＭ ＳＷメモリの中で使用される現在の一時的な値と比較し、これらの現在の値の真正性および完全性を検証した場合に限って、この登録応答メッセージを送信する。登録応答メッセージを受信すると、デバイス１３０２は、登録応答メッセージからのＲＩによって生成された情報を、結び付け鍵Ｋ＿ＤＥＶ＿ＢＩＮＤ＿Ｂを使用して結び付ける（ステップ１３３２）。

この密封署名および結び付けは、他の任意のＲＯＡＰプロトコルで使用されることが可能であることに留意されたい。前述した方法１３００は、例示的であり、方法１３００の原理は、他の任意のＲＯＡＰプロトコルにも等しく適用されることが可能である。

ＯＭＡ ＤＲＭ ＲＯＡＰメッセージ交換中に獲得されたデータは、このデータを密封した、またはこのデータに密封署名したエンティティが、そのエンティティのＯＳまたはＤＲＭ ＳＷを更新した場合、密封解除され、新たな構成ＰＣＲ値に再密封される必要がある。そのような事態が生じると、或る特定の状態（または、均等なこととして、或る特定のＰＣＲ値セット）に密封されていた、または密封署名されていたＤＲＭ ＲＯＡＰ関連のデータが、最初に、密封解除され、次に、更新されたプラットフォームＯＳの最新の状態に再密封されなければならない。この手続き要件に対処する既存の技術が、従来技術に存在し、そのような手続きは、本明細書で提案される密封または密封署名を使用して格納された任意のＤＲＭ ＲＯＡＰ関連のデータの適切な密封解除および再密封を確実にするように行われるものと想定される。

１つのさらなる機能強化は、送信するデバイスのＴＣＧ能力を示すフィールドを、既存のＲＯＡＰメッセージフォーマットに追加することである。このＴＣＧ能力フィールドは、受信するエンティティが、ＴＣＧ関連の情報および手続きをサポートすることができるかどうかの早期判定を行うことによって、レガシーデバイスとの相互運用性を高めることに役立つことが可能である。

（デバイスハローメッセージの変更、およびこの変更の導出）

第１の変更は、デバイスのＴＰＣ能力の標識である、新たなＤＴＣＩ（デバイスＴＰＭ能力指示）を、デバイスハローメッセージの既存の拡張子パラメータの新たな要素の中に追加すること、または代替として、好ましくは、このＤＣＴＩを、デバイスハローメッセージのヘッダの中の新たな第１のパラメータとして追加することである。ＤＴＣＩは、１ビット（デバイスＴＰＭの欠如、または存在を示す）、または数ビット（デバイスのＴＰＭ能力に関して、より細分性の高い情報を示す）であることが可能である。ＤＴＣＩは、新たなパラメータとして挿入される場合、好ましくは、デバイスＩＤパラメータより前に、最初のパラメータとして挿入されて、他のパラメータに先立って、デバイスがいくつかのＴＰＣ能力を有することをＲＩが知り、ＤＴＣＩを利用して、後のパラメータ（例えば、デバイスＩＤ）からの情報を処理することができるようにされなければならない。ＤＴＣＩ情報の利点は、この情報により、ＲＩが、ＲＯＡＰプロトコルの残りの部分におけるデバイスとのさらなる対話において、デバイスの信頼性を評価することが可能になることである。

第２の変更は、デバイス特有のＴＣＧ ＥＫ資格証明またはＴＣＧ ＡＩＫ資格証明を使用して、ＤＲＭデバイスＩＤをハッシングし、導き出すことである。この変更の利点は、ＥＫ資格証明および／またはＡＩＫ資格証明が、デバイス内のＴＰＭによって強固に保護されており、このため、これらの資格証明のいずれかからＤＲＭデバイスＩＤを導き出すことにより、ＤＲＭデバイスＩＤ情報の完全性が強化されることである。

第３の変更は、署名までの、署名を除くデバイスハローメッセージに、ＲＩによって検証されることが意図される、デバイスのＡＩＫ秘密鍵を使用して署名が行われる場合に、新たな署名パラメータを追加することである。この変更の利点は、デバイスとＲＩの間の最初の対話から、デバイスＴＰＭ能力の完全性を保護することである。ＴＰＭによって強固に保護される、デバイスのＡＩＫ秘密鍵の使用により、署名動作の完全性が強化される。

テーブル１２および１３は、変更されたデバイスハローメッセージに関する可能な２つのフォーマットを示す。テーブル１２は、最初のパラメータとしてＤＴＣＩビットを有するメッセージのフォーマットを示す。テーブル１３は、ＤＴＣＩが、既存の拡張子パラメータの新たな要素である、デバイスハローメッセージのフォーマットを示す。

（ＲＩハローメッセージの変更、およびこの変更の導出）

第１の変更は、ＲＩのＴＰＭ能力の標識である新たなＲＴＣＩ（ＲＩ ＴＰＭ能力指示）を、ＲＩハローメッセージの既存の拡張子パラメータの新たな要素として追加すること、または代替として、好ましくは、このＲＴＣＩを、ＲＩハローメッセージのヘッダの中の新たな第１のパラメータとして追加することである。この変更の利点は、この変更により、デバイスが、ＲＴＣＩ情報を使用して、ＲＩの信頼性を評価し、さらに、ＲＯＡＰプロトコル手続きの残りの部分におけるＲＩとのさらなる対話において、そのような情報を利用することが可能になることである。

第２の変更は、ＲＩ ＴＰＭを使用して、セッションＩＤを表す擬似乱数を提供することである。この変更の利点は、ＴＰＭが、セキュリティで強固に保護されたハードウェアベースの擬似乱数発生器を提供することである。ＴＰＭを使用して、セッションＩＤとして使用される擬似乱数を生成することにより、プロトコルのセキュリティが強化される。

第３の変更は、ＲＩ ＴＣＧ ＥＫ資格証明、またはＲＩのＴＰＭに属するＴＣＧ ＡＩＫ資格証明を使用して、ＲＩ ＩＤを導き出すことである。この変更の利点は、ＥＫ資格証明および／またはＡＩＫ資格証明が、デバイス内のＴＰＭによって強固に保護され、これらの資格証明のいずれかからＤＲＭデバイスＩＤを導き出すことにより、ＤＲＭデバイスＩＤ情報の完全性が強化されることである。

第４の変更は、ＲＩ ＴＰＭを使用して、ＲＩナンスを提供することである。この変更の利点は、ＴＰＭが、セキュリティで強固に保護されたハードウェアベースの擬似乱数発生器を提供することである。ＴＰＭを使用して、ＲＩナンスを生成することにより、ＲＩハローメッセージの中で使用されるナンスの完全性が強化される。

第５の変更は、デバイスによって信頼されるＲＩアンカの中にデバイスＴＣＧ資格証明を含めることである。デバイスのＴＣＧ資格証明には、ＥＫ資格証明、ＡＩＫ資格証明、プラットフォーム資格証明、ならびにＲＩが、信頼されるＴＣＧ ＣＡから事前獲得した準拠資格証明が含まれる。この変更の利点は、デバイスがＲＩハローメッセージに対して有することが可能な信頼を強化することである。

第６の変更は、ＲＩのＡＩＫ公開鍵が、ＲＩハローメッセージの一部としてデバイスにあらかじめ配布されている場合に、ＲＩのＡＩＫ秘密鍵を使用して署名された、署名までの、署名を除くＲＩハローメッセージの署名を追加することである。この変更の利点は、ＲＩとデバイスの間の最初の対話から、ＲＴＣＩの完全性を保護することである。ＲＩのＴＰＭによって強固なセキュリティで保護されたＲＩのＡＩＫ秘密鍵を使用することにより、署名動作の完全性が強化される。

テーブル１４および１５は、変更されたＲＩハローメッセージに関する可能な２つのフォーマットを示す。テーブル１４は、最初のパラメータとしてＲＴＣＩビットを有するＲＩハローメッセージのフォーマットを示す。テーブル１５は、ＲＴＣＩが、既存の拡張子パラメータの新たな要素である場合の、ＲＩハローメッセージのフォーマットを示す。

（登録要求メッセージの変更、およびこの変更の導出）

第１の変更は、デバイスＴＰＭを使用して、デバイスナンスを提供することである。この変更の利点は、ＴＰＭが、ナンスに使用するのに適したセキュリティで保護された、信頼できる擬似乱数を提供することである。

第２の変更は、デバイスＴＣＧ資格証明を証明書チェーンの中に含めることである。デバイスＴＣＧ資格証明を含めることは、既存のＯＭＡ ＤＲＭ２．０デバイス資格証明の代わりであること、または既存のＯＭＡ ＤＲＭ２．０デバイス資格証明に加えてであることが可能である。ＴＣＧ資格証明（ＥＫ資格証明、ＡＩＫ資格証明、プラットフォーム資格証明、または準拠資格証明）を含めることの利点は、デバイスの信頼性を高めることである。

第３の変更は、ＲＩによって信頼されるＴＣＧ ＣＡのリストを、信頼ＲＩアンカ要素の中に含めることである。ＲＩによって信頼されるＴＣＧ ＣＡを含めることは、既存のＯＭＡ ＤＲＭ２．０ ＲＩ信頼アンカ要素リストの代わりであること、または既存のＯＭＡ ＤＲＭ２．０ ＲＩ信頼アンカ要素リストに加えてであることが可能である。ＲＩによって信頼されるＴＣＧ ＣＡのリストを含めることの利点は、デバイスの信頼性を高めることである。

第４の変更は、デバイスＴＰＭについての情報を、拡張子パラメータのデバイス詳細要素の中に含めることである。この情報を含めることの利点は、ＲＩに対するデバイスについての信頼性を高めることである。

第５の変更は、変更されたデバイスハローメッセージに署名するのに使用されたデバイスＡＩＫを使用して署名に署名することである。この変更の利点は、デバイスＡＩＫの強固に保護された性質のため、デバイス、および登録要求メッセージの信頼性を高めることである。

テーブル１６は、変更された登録要求メッセージに関するフォーマットを示す。

（登録応答メッセージの変更、およびこの変更の導出）

第１の変更は、ＲＩ ＴＰＭを使用して、セッションＩＤを表す擬似乱数を提供することである。この変更の利点は、ＴＰＭが、セキュリティで強固に保護されたハードウェアベースの擬似乱数発生器を提供することである。ＴＰＭを使用して、セッションＩＤとして使用される擬似乱数を生成することにより、プロトコルのセキュリティが強化される。

第２の変更は、ＲＩ ＴＣＧ ＥＫ資格証明、またはＲＩのＴＰＭに属するＴＣＧ ＡＩＫ資格証明を使用して、ＲＩ ＩＤを導き出すことである。この変更の利点は、ＥＫ資格証明および／またはＡＩＫ資格証明が、デバイス内のＴＰＭによって強固に保護され、これらの資格証明のいずれかからＤＲＭデバイスＩＤを導き出すことにより、ＤＲＭデバイスＩＤ情報の完全性が強化されることである。

第３の変更は、ＲＩ ＴＰＭを使用して、ＲＩナンスを提供することである。この変更の利点は、ＲＩ ＴＰＭが、ナンスとして使用するのに適したセキュリティで保護された、信頼できる擬似乱数を提供することである。

第４の変更は、デバイスによって信頼されるＴＣＧ ＣＡのリストを、信頼されるデバイスアンカ要素の中に含めることである。デバイスによって信頼されるＴＣＧ ＣＡを含めることは、既存のＯＭＡ ＤＲＭ２．０信頼デバイスアンカ要素リストの代わりであること、または既存のＯＭＡ ＤＲＭ２．０信頼デバイスアンカ要素リストに加えてであることが可能である。デバイスによって信頼されるＴＣＧ ＣＡのリストを含めることの利点は、ＲＩの信頼性を高めることである。

第５の変更は、変更されたＲＩハローメッセージに署名するのに使用されたＲＩ ＡＩＫを使用して署名に署名することである。この変更の利点は、ＲＩ ＡＩＫの強固に保護された性質のため、ＲＩ、および登録応答メッセージの信頼性を高めることである。

テーブル１７は、変更された登録応答メッセージに関するフォーマットを示す。

（ＲＯ要求メッセージの変更、およびこの変更の導出）

第１の変更は、ＴＰＭを使用して、デバイスＩＤとして使用すべき、選択されたＴＣＧ資格証明（ＥＫ資格証明、ＡＩＫ資格証明、プラットフォーム資格証明、または準拠資格証明）のＳＨＡ−１ハッシュを作成する。この変更の利点は、資格証明が、ＴＰＭによって強固に保護され、このため、これらの資格証明のいずれかからデバイスＩＤを導き出すことにより、デバイスＩＤ情報の完全性が強化されることである。

第２の変更は、デバイスＴＰＭを使用して、デバイスナンスを生成することである。この変更の利点は、ＴＰＭによって生成されるナンスが、ＴＰＭの保護された擬似乱数発生能力のために、セキュリティで保護されていることである。

第３の変更は、ＴＣＧ資格証明を証明書チェーンの中に含めることである。ＴＣＧ資格証明を含めることは、既存のＯＭＡ ＤＲＭ２．０デバイス資格証明の代わりであること、または既存のＯＭＡ ＤＲＭ２．０デバイス資格証明に加えてであることが可能である。ＴＣＧ資格証明を含めることの利点は、デバイスの信頼性を高めることである。

第４の変更は、拡張子パラメータの中のデバイスＡＩＫを使用して、オプションのＤＣＦハッシュに署名することである。この変更の利点は、デバイスＡＩＫが強固に保護されており、ＤＣＦ署名が、より強固なセキュリティで保護されるようにすることである。

第５の変更は、正常に応答があった最新の登録要求メッセージに署名するのに使用されたデバイスＡＩＫを使用して、ＲＯ要求メッセージに署名することである。この変更の利点は、ＲＩ ＡＩＫの強固に保護された性質のため、ＲＩ、およびＲＯ要求メッセージの信頼性を高めることである。

テーブル１８は、変更されたＲＯ要求メッセージのフォーマットを示す。

（ＲＯ応答メッセージの変更、およびこの変更の導出）

１つの変更は、ＲＩのＴＰＭを使用して、成功した最新の登録応答メッセージに署名する際に使用されたのと同一のＲＩ ＴＰＭ ＡＩＫを使用して、ＲＯ応答メッセージに署名することである。この変更の利点は、ＲＩ ＡＩＫの強固に保護された性質のため、ＲＩ、およびＲＯ応答メッセージの信頼性を高めることである。

テーブル１９は、変更されたＲＯ要求メッセージのフォーマットを示す。

本発明の特徴および要素は、特定の組合せで、好ましい実施形態において説明されるものの、各フィーチャ、または各要素は、単独で（好ましい実施形態のその他のフィーチャ、およびその他の要素なしに）、あるいは本発明の他のフィーチャ、および他の要素を伴って、または伴わずに様々な組合せで使用されることが可能である。

（実施形態）

１．ＲＥ（要求するエンティティ）と、ＴＥ（ターゲットエンティティ）との間でプラットフォーム完全性検査を実行するための方法であって、ＴＥのＴＣＧ（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ）資格証明を報告するようＴＥに要求する要求を、ＲＥからＴＥに送信するステップと、ＴＥからＲＥにＴＥのＴＣＧ資格証明を送信するステップと、ＴＥのＴＣＧ資格証明を、検証のために、ＲＥからＯＣＳＰ（オンライン証明書ステータスプロトコル）レスポンダに転送するステップと、ＴＥのＴＣＧ資格証明の検証ステータスを、ＯＣＳＰレスポンダからＲＥに報告するステップと、ＴＥ自らのプラットフォーム完全性ステータスを報告するようＴＥに要求する要求を、ＲＥからＴＥに送信するステップと、ＴＥのプラットフォーム完全性ステータスを検査するステップと、ＴＥからＲＥにプラットフォーム完全性ステータス標識を送信するステップとを含む方法。

２．ＲＥは、ＲＩ（権利発行者）であり、ＴＥは、デバイスである実施形態１による方法。

３．デバイスが、方法を開始するトリガをＲＩに送信することによって、デバイスが、ＲＩを相手にＲＯＡＰ（権利オブジェクト獲得プロトコル）登録プロトコルを開始するのに先立って実行される実施形態２による方法。

４．デバイスが、ＲＩに最も新しく登録してから経過した時間に基づいて、定期的に実行される実施形態２または３による方法。

５．デバイスが、デバイスのプラットフォーム完全性ステータスをＲＩに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態２から４のいずれかによる方法。

６．ＲＥは、デバイスであり、ＴＥは、ＲＩ（権利発行者）である実施形態１による方法。

７．ＲＩが、ＲＩのプラットフォーム完全性ステータスをデバイスに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態６による方法。

８．ＲＥは、ＣＩ（コンテンツ発行者）であり、ＴＥは、デバイスである実施形態１による方法。

９．デバイスが、デバイスのプラットフォーム完全性ステータスをＣＩに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態８による方法。

１０．デバイスが、ＣＩからコンテンツを購入すると、実行される実施形態８または９による方法。

１１．ＲＥは、デバイスであり、ＴＥは、ＣＩ（コンテンツ発行者）である実施形態１による方法。

１２．ＣＩが、ＣＩのプラットフォーム完全性ステータスをデバイスに最も新しく検証してから経過した時間に基づいて、定期的に実行される実施形態１１による方法。

１３．デバイスが、ＣＩからコンテンツを購入すると、実行される実施形態１１または１２による方法。

１４．ＲＯＡＰ（権利オブジェクト獲得プロトコル）プロセスの一環として実行される実施形態１による方法。

１５．ＲＯＡＰプロセスに先立って実行される実施形態１４による方法。

１６．ＲＯＡＰプロセスは、ＲＯＡＰプロセスの一環として方法を組み込むように変更される実施形態１４または１５による方法。

１７．ＲＥ（要求するエンティティ）と、ＴＥ（ターゲットエンティティ）との間でＤＲＭ（デジタル著作権管理）ソフトウェア完全性検査を実行するための方法であって、ＴＥがＤＲＭソフトウェア完全性検査を実行することを要求する要求を、ＲＥからＴＥに送信するステップと、ＴＥによってＤＲＭソフトウェア完全性を検査するステップと、ＴＥからＲＥにＤＲＭソフトウェア完全性ステータス標識を送信するステップとを含む方法。

１８．ＲＥは、ＲＩ（権利発行者）であり、ＴＥは、デバイスである実施形態１７による方法。

１９．デバイスは、デバイスが、ＲＯＡＰ（権利オブジェクト獲得プロトコル）プロセスを開始するのに先立って、方法を開始するトリガをＲＩに送信する実施形態１８による方法。

２０．ＲＯＡＰプロセスは、２パス登録、２パスドメイン参加、および２パスドメイン退去から成るグループから選択される実施形態１９による方法。

２１．デバイスが、ＲＩを相手にＲＯＡＰ（権利オブジェクト獲得プロトコル）プロセスを完了した後、定期的に実行される実施形態１９または２０による方法。

２２．ＲＯＡＰプロセスは、２パス登録、２パスドメイン参加、および２パスドメイン退去から成るグループから選択される実施形態１９から２１のいずれかによる方法。

２３．デバイスが、デバイスのＤＲＭソフトウェア完全性ステータスをＲＩに検証し、報告した後、定期的に実行される実施形態１８から２２のいずれかによる方法。

２４．デバイスが、デバイスのＤＲＭソフトウェアを更新した後、実行される実施形態１８から２３のいずれかによる方法。

２５．ＲＩは、デバイス上のメディアプレーヤに対してＤＲＭソフトウェア完全性検査を実行するよう、デバイスに要求する実施形態１８から２４のいずれかによる方法。

２６．ＲＥは、デバイスであり、ＴＥは、ＲＩ（権利発行者）である実施形態１７による方法。

２７．デバイスによって開始されると、実行される実施形態２６による方法。

２８．スタンドアロンのプロセスである実施形態２６または２７による方法。

２９．変更された権利オブジェクト獲得プロトコルプロセスの一環である実施形態２６から２８のいずれかによる方法。

３０．ＲＩが、ＲＩのＤＲＭソフトウェア完全性ステータスをデバイスに検証し、報告した後、定期的に実行される実施形態２６から２９のいずれかによる方法。

３１．ＲＩが、ＲＩのＤＲＭソフトウェアを更新した後、実行される実施形態２６から３０のいずれかによる方法。

３２．デバイスが、ＲＩに権利オブジェクト要求を送信するのに先立って実行される実施形態２６から３１のいずれかによる方法。

３３．ストリーミングコンテンツを求めるデバイスからＲＩへの要求中に、定期的に実行される実施形態２６から３２のいずれかによる方法。

３４．ＲＥは、ＣＩ（コンテンツ発行者）であり、ＴＥは、デバイスである実施形態１７による方法。

３５．デバイスは、デバイスが、ＲＯＡＰ（権利オブジェクト獲得プロトコル）プロセスを開始するのに先立って、方法を開始するトリガをＣＩに送信する実施形態３４による方法。

３６．デバイスが、ＣＩを相手にＲＯＡＰ（権利オブジェクト獲得プロトコル）プロセスを完了した後、定期的に実行される実施形態３４または３５による方法。

３７．デバイスが、デバイスのＤＲＭソフトウェア完全性ステータスをＣＩに検証し、報告した後、定期的に実行される実施形態３４から３６のいずれかによる方法。

３８．デバイスが、デバイスのＤＲＭソフトウェアを更新した後、実行される実施形態３４から３７のいずれかによる方法。

３９．ＣＩは、デバイス上のメディアプレーヤに対してＤＲＭソフトウェア完全性検査を実行するよう、デバイスに要求する実施形態３４から３８のいずれかによる方法。

４０．ＲＥは、デバイスであり、ＴＥは、ＣＩ（コンテンツ発行者）である実施形態１７による方法。

４１．デバイスによって開始されると、実行される実施形態４０による方法。

４２．スタンドアロンのプロセスである実施形態４０または４１による方法。

４３．変更された権利オブジェクト獲得プロトコルプロセスの一環である実施形態４０から４２のいずれかによる方法。

４４．ＣＩが、ＣＩのＤＲＭソフトウェア完全性ステータスをデバイスに検証し、報告した後、定期的に実行される実施形態４０から４３のいずれかによる方法。

４５．ＣＩが、ＣＩのＤＲＭソフトウェアを更新した後、実行される実施形態４０から４４のいずれかによる方法。

４６．デバイスが、権利オブジェクト要求をＣＩに送信するのに先立って実行される実施形態４０から４５のいずれかによる方法。

４７．ストリーミングコンテンツを求めるデバイスからＣＩへの要求中に、定期的に実行される実施形態４０から４６のいずれかによる方法。

４８．２つのエンティティ間で交換されるＲＯＡＰ（権利オブジェクト獲得プロトコル）メッセージの完全性を強化するための方法であって、信頼されるコンピューティング技術を使用して各エンティティにおいて、ＲＯＡＰメッセージの中で使用されるべき情報を安全に格納するステップと、ＲＯＡＰメッセージに関連して使用されるのに先立って、ＲＯＡＰメッセージの中で使用されるべき情報を事前検証するステップとを含む方法。

４９．格納するステップは、情報に密封署名すること、および情報を結び付けることを含む実施形態４８による方法。

５０．密封署名するステップは、対称暗号化鍵を使用して情報を対称的に暗号化すること、およびこの対称暗号化鍵、およびオブジェクトの現在の完全性ステータスを示す値のセットに非対称的に署名することを含む実施形態４９による方法。

５１．署名するステップは、エンティティが動作するプラットフォームの完全性ステータスを使用することを含む実施形態５０による方法。

５２．署名するステップは、エンティティのソフトウェア構成要素の完全性ステータスを使用することを含む実施形態５０または５１による方法。

５３．結び付けるステップは、秘密解読鍵がエンティティ内の保護されたモジュールの中に格納された鍵を使用して、情報を非対称的に暗号化することを含む実施形態４９から５２のいずれかによる方法。

５４．保護されたモジュールは、ＴＰＭ（信頼される処理モジュール）である実施形態５３による方法。

５５．ＴＰＭは、ＲＯＡＰメッセージの中で使用すべきパラメータを導き出すのに使用される実施形態５４による方法。

５６．情報は、デバイスＩＤ、権利発行者ＩＤ、証明書、証明書チェーン、デジタル権利管理関連の時間値、権利オブジェクト、アルゴリズム、およびナンスから成るグループから選択される実施形態４８から５５のいずれかによる方法。

５７．すべてのＲＯＡＰメッセージに適用される実施形態４８から５６のいずれかによる方法。

５８．ＲＯＡＰメッセージとは別個に適用される実施形態４８から５６のいずれかによる方法。

５９．ＲＯＡＰメッセージの生成および伝送に組み込まれる実施形態４８から５６のいずれかによる方法。

６０．送信するエンティティの信頼されるコンピューティング能力を示すフィールドを、既存のＲＯＡＰメッセージに追加するステップをさらに含む実施形態４８から５６のいずれかによる方法。

６１．実施形態１から６０のいずれかによる方法を実行するように構成されたシステム。

６２．実施形態１から６０のいずれかによる方法を実行するように構成された集積回路。

Claims (3)

1. 要求するエンティティ（ＲＥ）と、ターゲットエンティティ（ＴＥ）との間でデジタル著作権管理（ＤＲＭ）を実行するための方法であって、
   前記ＲＥによって実行される以下のステップ、
   （ａ）前記ＴＥに、前記ＴＥの信頼されている証明書を報告するよう要求するステップと、
   （ｂ）前記ＴＥの信頼されている証明書を受信するステップと、
   （ｃ）レスポンダに、前記ＴＥの信頼されている証明書を、完全性検証のために転送するステップと、
   （ｄ）前記レスポンダから、前記ＴＥの信頼されている証明書の前記完全性検証の結果のインジケーションを受信するステップと、
   （ｅ）前記ＴＥの自己証明された自身のプラットフォーム完全性ステータスを報告するよう要求するステップと、
   （ｆ）前記ＴＥの自己証明されたプラットフォーム完全性ステータスについての情報を受信するステップと、
   （ｇ）前記受信したインジケーションと、前記ＴＥの自己証明されたプラットフォーム完全性ステータスについての前記情報とに基づいて、前記ＴＥにおいて十分な信頼を与えて、Ｒｉｇｈｔｓ Ｏｂｊｅｃｔ Ａｃｑｕｉｓｉｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＲＯＡＰ）において前記ＴＥを進めるか、または、権利オブジェクトをデバイスが獲得することを可能にする別のプロトコルにおいて前記ＴＥを進めるかを判定するステップであって、前記判定するステップは、前記レスポンダに、前記ＴＥの自己証明されたプラットフォーム完全性ステータスを、検証のために予め転送することなく実行される、ステップと
   を備えることを特徴とする方法。
2. 前記ＲＥは、権利発行者（ＲＩ）であり、および、前記ＴＥは、前記デバイスであることを特徴とする請求項１に記載の方法。
3. 前記方法は、前記デバイスが前記ＲＩとの前記登録プロトコルを開始する前に、前記方法を開始するトリガを前記デバイスが前記ＲＩに送信することによって実行されることを特徴とする請求項２に記載の方法。