JP2005510184A - 機密保護インターネット・プロトコル権利管理アーキテクチャ用の鍵管理プロトコルおよび認証システム - Google Patents

Abstract

許可された使用者に機密保護状態でコンテンツを配信するためのデジタル権利管理アーキテクチャ。このアーキテクチャは、コンテンツ・プロバイダ（２０２）とコンテンツ・プロバイダからコンテンツを要求するための使用者システム（２１６）を含む。コンテンツ・プロバイダは、使用者が選択した購入オプションを有するセッション権利オブジェクト（２０２Ｂ）を生成する。その後で、ＫＤＣ（２０４）は、許可データを使用者システムに供給する。また、キャッシング・サーバ（２１５）が、購入オプションを許可データと比較するために設置されている。キャッシング・サーバ（２１５）は、購入オプションが許可データと一致する場合には、要求したコンテンツを使用者システム（２１６）に転送する。キャッシング・サーバ（２１５）は、暗号化したコンテンツを機密保護状態で転送するために、リアルタイム・ストリーミングを使用し、使用者システム（２１６）に転送するために要求したコンテンツが暗号化される。さらに、キャッシング・サーバ（２１５）および使用者システム（２１６）は、要求したコンテンツの転送をサポートするために、暗号化された（および認証された）制御メッセージを交換する。このようにして、構成要素間のすべてのインタフェースは、暗号化および認証により保護される。

Description

本発明は、概して、データ通信の分野に関し、特にネットワークの構成要素間でコンテンツを機密保護状態で通信するためのデジタル権利管理機能に関する。

インターネットのような通信ネットワークを介して送信されたコンテンツを保護するための従来のデジタル権利管理システムは周知されつつある。権利管理システムが必要になってきているが、それはコンテンツ・プロバイダが当面している基本的な問題が、デジタル・コンテンツの不正使用および配布を如何に防止するかという問題であるからである。コンテンツ・プロバイダは、自分のコンテンツの補償を得ること、およびそのコンテンツの正規のユーザを得ることに関心がある。

多くのデジタル権利管理スキームは、通常、デジタル・コンテンツの「暗号化／解読」により行われる。暗号化は、データを、例えば、無許可のクライアントが簡単に理解し得ない暗号文のような、理解できない形に変換することである。解読は、暗号化されたコンテンツを、理解できる元の形に変換するプロセスである。簡単な暗号としては、アルファベットでの文字の回転、数字の文字への置換、および側帯波周波数の倒置による音声信号の「スクランブリング」がある。もっと複雑な暗号は、デジタル情報コンテンツのデータ・ビットを再配置するという、高度のコンピュータ・アルゴリズムにより行われる。

暗号化された情報コンテンツを容易に回復するためには、正しい解読鍵が必要になる。この鍵は、暗号化および解読のアルゴリズム両方に対するパラメータであり、この場合、鍵の値が異なると、暗号化および解読プロセスの両方の際に予測し得ない異なる結果を生じる。鍵の長さが長ければ長いほど、鍵の値を正しく推測するのが困難になり、そのため鍵を知らない場合には通信を解読するのが困難になる。通常、暗号化／解読のシステムのために２つのタイプの鍵スキームが使用される。すなわち、（１）ＰＫＳ（公開鍵システム）、即ち一方は暗号化または署名をするためのものであり、他方は解読または確認のためのものである２つの異なる鍵を使用する非対称システムと、（２）対称であるとして周知の非公開鍵システム、即ち、通常、暗号鍵と解読鍵とが同じである秘密鍵システムである。公開鍵システムおよび秘密鍵システムの両方を使用して、鍵を配布し、鍵を受け取る相手の認証を正しく行うために鍵管理が使用される。

ＭＩＴが開発した１つの関連技術である鍵管理システムは、Ｋｅｒｂｅｒｏｓプロトコルと呼ばれる。Ｋｅｒｂｅｒｏｓは、当事者が、ＫＤＣ（鍵配布センター）およびチケットのコンセプトを用いて種々のネットワーク・サービスとの共有セッション鍵を確立することができる、鍵管理プロトコルである。チケットは、チケットを発行したクライアントの識別と一緒に、セッション鍵をサーバに安全に送るために使用される。チケットは不正開封防止機能付きなので、クライアントはこれを安全に保管することができ、サーバは１つの状態に拘束されないで自由に行動することができる（サーバは、クライアントがサーバにチケットを送る度に、セッション鍵を再度学習することができる）。それ故、チケットのコンセプトの導入により、サーバが維持できるクライアントの数の点で、サーバの拡張可能性が改善される。問題点は、Ｋｅｒｂｅｒｏｓは比較的複雑であり、特定のアプリケーションにいつでも適用できるとは限らない多くの異なるオプションを含む。さらに、このような複雑なシステムの修正は自由に行うことができない。何故なら、よく知らないシステムにこのような修正を行うと、他のエラーをさらに引き起こす恐れがあるからである。Ｋｅｒｂｅｒｏｓのもう１つの問題点は、チケットを入手した場合の、クライアント
とサーバとの間の鍵管理の実行の詳細を指定しないことである（供給されるのはいくつかの基本的な構成ブロックだけである）。

インターネット・プロトコル（ＩＰ）ネットワークによるマルチメディア・コンテンツのストリーミング配布に対する興味が増大してきているために、鍵管理システムに対するニーズも増大してきている。このようなストリーミング配布システムの１つが、カリフォルニア州サンディエゴ所在のＡｅｒｏｃａｓｔ，Ｉｎｃ．社が開発した、Ａｅｒｏｃａｓｔ Ｎｅｔｗｏｒｋ（商標）である。図１を参照しながら説明するように、既存の第一世代のＡｅｒｏｃａｓｔ Ｎｅｔｗｏｒｋでは、コンテンツの供給は容易であるが、ネットワークに対する安全性および鍵管理が不足している。

図１は、通信ネットワーク全体でのコンテンツのストリーミングを容易にするためのネットワーク１００（Ａｅｒｏｃａｓｔ社による）のブロック図である。他の構成要素も含んでいるが、ネットワーク１００は、使用者１１６向けのコンテンツを生成するためのコンテンツ・プロバイダ１０２、コンテンツがストリーミングされるインターネット１１４、およびコンテンツ・プロバイダ１０２がそのコンテンツを発行する中央サーバ１０４を含む。中央サーバ１０４は、コンテンツ情報を記憶するためのデータベース１０８、およびデータベース１０８を検索するための検索エンジン１１０を含む。ネットワーク１００は、さらに、提供センター１０６およびキャッシング・サーバ１１２、１１３および１１５を備える。

動作中、コンテンツ・プロバイダ１０２によりコンテンツにアクセスしたい使用者１１６は、最も近いキャッシング・サーバ、この場合は、キャッシング・サーバ１１５からコンテンツをストリーミングする。キャッシング・サーバを備えていない従来のシステムの場合には、このようなコンテンツ・ストリームを入手したい使用者１１６は、コンテンツ・プロバイダ１０２から直接コンテンツを入手する。この場合には、コンテンツの品質が劣化するばかりでなく、不適当な帯域幅による遅延が発生する恐れがある。キャッシング・サーバを使用することにより、ネットワーク１００は、コンテンツ・プロバイダ２０２からのデジタル・コンテンツの直接ストリーミングによる不都合を回避できる。キャッシング・サーバ１１２、１１３および１１５としては、例えば、ローカルＤＳＬ（デジタル加入者ライン）プロバイダを使用することができる。

ネットワーク１００は、更なる利点を有する。コンテンツを検索する場合、使用者１１６は、インターネット１１４上の任意のおよびすべてのデータベースを検索する必要はない。ネットワーク１００上のすべてのコンテンツ・プロバイダ（コンテンツ・プロバイダ１０２を含む）は、１つの中央データベース１０８にそのコンテンツの説明を発行する。例えば、ビデオ・コンテンツの場合には、このような説明は、映画のタイトル、俳優等を含み得る。このようにして、コンテンツが必要な場合には、使用者１１６は、データベース１０８を検索するために検索エンジン１１０を使用する。コンテンツを発見した場合には、データベース１０８は、その後で、所望のコンテンツを有しているコンテンツ・プロバイダ２０２にリンクする。次に、使用者１１６は、コンテンツ・プロバイダ１０２にアクセスし、より詳細な説明およびコンテンツに関連する他のメタデータを見る。

それにより使用者１１６がコンテンツ・プロバイダ１０２に、自分に最も近いキャッシング・サーバのリストを供給する機構が設置されている。使用者１１６の要求に応じて、コンテンツ・プロバイダ１０２は、コンテンツをストリーミングするために、使用者１１６に最も近い適当なキャッシング・サーバを選択する。しかし、現在のＡｅｒｏｃａｓｔネットワークのコンテンツは、ネットワーク１００によりクリア（ｃｌｅａｒ）でストリーミングされることに留意されたい。問題点は、コンテンツが保護されていないので、コンテンツが無許可の使用者により傍受され、コンテンツ・プロバイダおよび使用者がかな
りの損失を蒙る結果になる。

ネットワーク１００の他の欠点としては、認証が行われないこと、プライバシーが保護されないこと、メッセージが保全されないこと、および永続的保護に欠けていること等がある。

それ故、上記問題を解決する必要があり、本発明はこの要求に適合している。

本発明は、コンテンツを許可された使用者に機密保護状態で配信し、種々のネットワーク構成要素間でデータを機密保護状態で転送するためのデジタル権利管理アーキテクチャである。

本発明の第１の態様によれば、このアーキテクチャは、ＩＰ（インターネット・プロトコル）通信ネットワークを介してコンテンツ・プロバイダに接続している使用者システムを含む。アーキテクチャは、さらに、ＫＤＣ（鍵配布センター）および同様に通信ネットワークに結合しているキャッシング・サーバを含む。許可されたユーザは、コンテンツ・プロバイダからコンテンツにアクセスすることができる。ユーザは、例えば、コンテンツ・プロバイダのＵＲＬから所望のコンテンツを選択するために使用者システムを使用する。コンテンツ・プロバイダは、使用者システムに、必要なコンテンツにアクセスするためのセッション権利オブジェクトを供給する。セッション権利オブジェクトは、ユーザが選択した購入オプションを含むことができる。または、セッション権利オブジェクトは、コンテンツ・アクセス・ルールを含むことができる。購入オプションは、コンテンツ、すなわち、それが無料なのか、加入者だけなのか、ペイパービュウなのか等がある。コンテンツ・アクセス・ルールの一例は、指定の地理的位置の外部のエリアへのコンテンツ・アクセスではないことである。

セッション権利オブジェクトを受信した後で、ユーザはキャッシング・サーバに転送される。このキャッシング・サーバから、要求したコンテンツがユーザにストリーミングされる。ユーザは、ＫＤＣからキャッシング・サーバ・チケットを予め入手することができることに留意されたい。チケットは、認証トークン（ｔｏｋｅｎ 証拠）であり、クライアント、サーバ名、セッション鍵等を含むことができる。チケットは、さらに加入サービス、ユーザの支払い方法等を表示する許可データを含む。その後で、このチケットおよびセッション権利オブジェクトがキャッシング・サーバに提示され、キャッシング・サーバは、セッション権利オブジェクト内のユーザ選択および／またはコンテンツ・アクセス・ルールをチケットからの許可データと比較する。この情報が一致した場合には、コンテンツがユーザにストリーミングされる。このようにして、無許可のユーザへのアクセスを拒否しながら、許可されたユーザにコンテンツを機密保護状態で供給するアーキテクチャが供給される。

他の態様によれば、本発明は、許可された使用者にコンテンツを機密保護状態で配信するための権利管理アーキテクチャである。このアーキテクチャは、コンテンツ・プロバイダ、およびコンテンツ・プロバイダからコンテンツを要求するための使用者システムを含む。コンテンツ・プロバイダは、使用者が選択した購入オプションを有するセッション権利オブジェクトを生成する。その後で、ＫＤＣは、使用者システムに許可データを供給する。また、キャッシング・サーバは、購入オプションを許可データと比較するためのものである。購入オプションが許可データと一致した場合には、キャッシング・サーバは、要求されたコンテンツを使用者システムに転送する。キャッシング・サーバは、暗号化した
コンテンツを機密保護状態で転送するために、リアルタイム・ストリーミングを使用し、要求されたコンテンツは使用者システムに転送するために暗号化されることに留意されたい。さらに、キャッシング・サーバおよび使用者システムは、要求されたコンテンツの転送をサポートするために、暗号化された（および認証された）制御メッセージを交換する。このようにして、構成要素間のすべてのインタフェースは、暗号化および／または認証により保護される。

本発明のもう１つの他の態様によれば、キャッシング・サーバのところにコンテンツを機密保護状態で予め位置決めするための権利管理方法を使用する。この方法は、コンテンツ・プロバイダ、キャッシング・サーバおよび鍵管理プロトコルを供給する工程を含む。このプロトコルは、コンテンツを機密保護状態で転送するために種々のメッセージを使用する。その中の１つのメッセージは、コンテンツ・プロバイダからキャッシング・サーバに送られる鍵要求メッセージである。このメッセージの目的は、鍵管理をスタートすることである。これに応じて、鍵応答メッセージが、キャッシング・サーバからコンテンツ・プロバイダに送られる。その後で、鍵要求／鍵応答メッセージが交換され、コンテンツ・プロバイダからキャッシング・サーバにコンテンツを機密保護状態で配信するための一組の鍵が確立する。

本発明のさらに他の態様によれば、通信ネットワークの構成要素間で機密保護状態でデータ転送を行うためのプロトコルが開示されている。このプロトコルは、データベースを有する中央サーバを供給する工程を含む。次に、コンテンツがコンテンツ・プロバイダから中央サーバに発行される。さらに、プロトコルは、課金センター・サーバを供給し、キャッシング・サーバから課金センター・サーバへ課金情報を報告する工程を含む。また、提供データベースが供給される。データベースは使用者情報により更新される。次に、プロトコルは中央サーバに発行したデータを保護するために鍵管理プロトコルを使用する。また、課金情報が報告され、提供データベースが更新された場合、データが保護される。

本発明の長所は、公開鍵技術と対称鍵手法を混合して、取得時間を短縮し、コードを最も簡単にしなければならないという拘束の下で、コンテンツの配布に対して「ソフトウェア」で実施した最善の安全性を達成する。さらに、このアーキテクチャを使用すれば、ネットワークとサービス・プロバイダを分離することができ、特定のネットワークと容易に統合することができる。

本明細書の残りの部分を読み、添付の図面を見れば、本発明の性質および利点をよりよく理解することができるだろう。本発明の「工程」の意味は、「工程プラス機能」手段に限定されると解釈すべきでないし、本発明を実施するための特定の順序を意味するものでもない。添付の図面を参照しながら、本発明の他の機能および利点、および本発明の種々の実施形態の構造および動作について、以下に詳細に説明する。図面中、同じ参照符号は、同じまたは機能的に類似の素子を示す。

図２は、本発明の例示としての実施形態による、図１のネットワーク１００に鍵管理およびセキュリティを適用するためのＥＳＢｒｏｋｅｒ（商標）プロトコルを内蔵するＩＰＲＭ（インターネット・プロトコル権利管理）システム２００のブロック図である。

他の構成要素も含んでいるが、ＩＰＲＭシステム２００は、コンテンツ・プロバイダ２０２、使用者２１６、インターネット２１４、提供センター２０６、データベース２０８と検索エンジン２１０の両方を含む中央サーバ２０５、そのすべての機能が図１の対応する構成要素の機能に類似しているキャッシング・サーバ２１２、２１３および２１５を備える。さらに、ＩＰＲＭシステム２００は、ＴＧＴ（チケット許可チケット）を使用者２
１６に発行するためのＡＳ（認証サーバ）２０７を含むＫＤＣ（鍵配布センター）２０４、特定のサーバにアクセスするためのサーバ・チケットを供給するためのＴＧＳ（チケット許可サーバ）２０９、提供サーバ２２０および課金センター２１１を備える。ＫＤＣ２０４、課金センター２１１、提供センター２０６および中央サーバ２０５は、ＩＰＲＭシステム２００内でのサービスの提供を容易にするために、すべて中央ユニット２１８内に位置する。

さらに、ＩＰＲＭシステム２００は、コンテンツ・プロバイダ２０２のために権利管理を管理するためのＩＰＲＭエージェント２０２Ａ、ユーザの選択およびコンテンツ・ルールを内蔵するためのセッション権利オブジェクト２０２Ｂ、キャッシング・サーバ２１２のための権利管理を管理するためのＩＰＲＭエージェント２１２Ａ、キャッシング・サーバ２１３のために権利管理を管理するためのＩＰＲＭエージェント２１３Ａ、キャッシング・サーバ２１５のために権利管理を管理するためのＩＰＲＭエージェント２１５Ａ、使用者２１６のために権利管理を管理するためのＩＰＲＭエージェント２１６Ａ、および所望のコンテンツを受信するための使用者２１６内のビューア（図示せず）を含む。図示していないが、上記構成要素は、その関連構成要素に内蔵させることができる。例えば、ＩＰＲＭエージェント２０２Ａは、図に示すように、外部ではなく、コンテンツ・プロバイダ２０２内に内蔵させることができる。

すでに説明したように、ＩＰＲＭシステム２００は、通常、キャッシング・サーバ２１２、２１３および２１５により、使用者２１６への機密保護状態でのコンテンツのストリーミングを容易にする働きをする。コンテンツ・プロバイダ２０２は、１回だけコンテンツを供給し、その後でコンテンツはキャッシング・サーバ間を移動することができる。キャッシング・サーバを使用するのは、コンテンツをＩＰＲＭシステム２００の縁部にもっと近づけるためである。そうすることにより、ストリーミング性能が改善され、もっと小規模なコンテンツ・プロバイダは、媒体ストリーミング用の高価なハードウェアを購入しなくても、そのコンテンツを販売することができる。また、キャッシング・サーバのところに、ＩＰマルチキャスト（ネットワーク上の１つの送信機と複数の受信機との間の通信）だけを導入することもできる。現在の技術を使用して、インターネットを通してＩＰマルチキャストを行うよりも、ローカル・アクセス・ネットワークに制限されているＩＰマルチキャストを行うほうが容易である。

第１の実施形態による本発明は、ＫＤＣ２０４、ＩＰＲＭエージェント２０２Ａ、２１２Ａ、２１３Ａ，２１５Ａおよび２１６Ａを介して、ＩＰＲＭシステム２００にセキュリティを提供する。ＫＤＣ２０４および提供センター２０６と一緒に、ＩＰＲＭエージェントは、ＩＰＲＭシステム２００のすべての態様に、認証、プライバシー、保全およびアクセス制御ツールを供給する。例えば、コンテンツをストリーミングするために使用者がシステムを使用するには、まず登録プロセスを行わなければならない。ＩＰＲＭシステム２００は使用者に機密保護登録を提供する。それ故、登録プロセスの間、誰も、使用者２１６とＫＤＣ２０４との間のメッセージを傍受して、使用者２１６の識別をコピーすることはできない。ＫＤＣ２０４は、委託エンティティであり、対称および非対称アルゴリズムの混合物により、ネットワーク構成要素に鍵を配布する。これらのアルゴリズムは、１つまたはそれ以上のソフトウェア命令により実施することができる。または、これらのアルゴリズムは、機密保護暗号ハードウェアに内蔵させることもできる。

セキュリティが提供されるシステムのもう１つの態様は、コンテンツがノード間で交換される場合の、キャッシング・サーバとコンテンツ・プロバイダ２０２との間のインタフェースである。セキュリティが提供される他の態様は、キャッシング・サーバが設置される場合であり、コンテンツ・プロバイダからキャッシング・サーバにコンテンツを配信する場合であり、キャッシング・サーバ間でコンテンツを移動する場合であり、使用データ
を報告する場合であり、課金する場合であり、使用者プロファイルを更新する場合であり、コンテンツを発行する場合であり、最初の使用者の購入契約の場合である。表示していないが、通常の当業者であれば、本発明の精神および範囲に含まれる他の態様にも、機密保護を提供することができることを理解することができるだろう。

ＫＤＣ２０４およびＩＰＲＭ構成要素は、使用者２１６の信頼が限定されている純粋なソフトウェア保護であってもよいし、高いセキュリティ・レベルを必要とする著作権者から高品質なコンテンツへの権利を入手するために絶対必要な場合があるハードウェア・セキュリティ・モジュールであってもよいし、ソフトウェアとハードウェア両方の組合せであってもよい。ＩＰＲＭは、何百万という使用者に対して高いスケーラビリティを有する認証した鍵管理プロトコルを使用する。鍵管理プロトコルは、ＥＳＢｒｏｋｅｒ（商標）（電子セキュリティ・ブローカー）と呼ばれ、これはカリフォルニア州サンディエゴ所在のモトローラ社（Ｍｏｔｏｒｏｌａ，Ｉｎｃ．）の製品であり、本明細書で随所に出てくる。

部分的にＫｅｒｂｅｒｏｓフレームワークをベースとしているＥＳＢｒｏｋｅｒ（商標）プロトコルは、中央鍵配布センター（ＫＤＣ２０４）と個々のアプリケーション・サーバとのクライアントの相互作用からなる。ＫＤＣクライアントは、ＫＤＣに要求を送ることができる任意のホストである。ＩＰＲＭシステムにおいては、ＫＤＣクライアントは、使用者、キャッシング・サーバおよび他のＩＰＲＭシステム構成要素を含む。アプリケーション・サーバは、クライアント（例えば、キャッシング・サーバ、課金センター等）がサービス・チケットを要求することができるＫＤＣに登録している任意のサーバである。

本明細書で使用する場合、チケットは、ＫＤＣがクライアントに与える認証トークンである。他の情報も含んでいるが、チケットは、クライアント名、特定のサーバ名、およびセッション鍵（対称暗号鍵）を含む。クライアント名およびセッション鍵は秘密にしておかなければならないし、サービス鍵と呼ばれるもう１つの鍵で暗号化される。サービス鍵は、ＫＤＣおよびチケット内で指名されたサーバだけが知っている秘密鍵である。また、クライアントはこのサービス鍵を有していないので、クライアントはチケットを解読することもできないし、そのコンテンツを変更することもできない。通常、クライアントは、また、セッション鍵を知っていなければならない。何故なら、クライアントは、チケットからセッション鍵を取り出すことができないからである。ＫＤＣは、このクライアントに同じセッション鍵の別のコピーを送る。

チケット（例えば、ＥＳＢｒｏｋｅｒ鍵要求メッセージ）を含むメッセージの認証を行うために、クライアントは、このメッセージ内に、チケットとチケット内のセッション鍵のチェックサム値の両方を内蔵させることができる。チケット内のセッション鍵は、サーバのサービス鍵で暗号化されていることに留意されたい。チケット内で指名されたサーバが、クライアントからこのメッセージを受信した場合には、そのサービス鍵でチケットを解読し、クライアント名を確認し、セッション鍵を入手することができる。次に、セッション鍵は、鍵によるチェックサムを確認するために、すなわち全メッセージの認証を行うために使用される。

このチケットをベースとする認証は、Ｋｅｒｂｅｒｏｓ ＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）規格（ＲＦＣ １５１０）の一部であり、また、ＥＳＢｒｏｋｅｒプロトコルで使用される。他の規格をベースとする他の認証技術も使用することができることを理解されたい。チケットは、有効期間（開始時期および満了時期）、種々のフラグ、クライアント許可データ等を含む他の情報も含むことができる。許可データ・フィールドは、加入サービス、地理的位置、ユーザの支払方法、およびユーザの許可に関連する他のデータを含むことができる。

同じホストが、同時にＫＤＣクライアントおよびアプリケーション・サーバになることができる。ＩＰＲＭシステム２００の場合には、プロトコルは、システムのクライアントとサーバ・インタフェースとの間で鍵管理を行うために一連のメッセージを使用することができる。この鍵管理プロトコルは、機密保護セッションを確立するために一般的に使用するためのものであり、ＩＰＲＭシステムに限定されない。下記のテーブル１のこれらのメッセージについては、ＩＰＲＭプロトコル・メッセージの節でさらに詳細に説明する。

動作中、クライアントとサーバとの間の鍵管理プロセスは、２つの段階、すなわち、（
１）クライアントが、サーバにアクセスする目的でサーバ・チケットを入手するために、ＫＤＣ２０４と連絡する一般的な段階、（２）クライアントが、サーバへのＫＥＹ＿ＲＥＱ（鍵要求）メッセージを作成するために、サーバ・チケットを使用する一般的でない段階に分類される。一般的でない段階においては、ＤＯＩ（解釈の領域）オブジェクトが、一般的なＥＳＢｒｏｋｅｒ鍵管理プロトコル（例えば、ＩＰＲＭシステム特有の）の特殊な用途に特有な情報を含む。例えば、使用者２１６（クライアント）とキャッシング・サーバ２１５（サーバ）との間の鍵管理プロセスの場合、一般的な段階は、使用者２１６によるキャッシング・サーバ２１５にアクセスするためＫＤＣ２０４からサーバ・チケットを入手するステップを含む。一般的でないプロセスは、キャッシング・サーバ２１５にアクセスする目的で、ＫＥＹ＿ＲＥＱメッセージを生成するためにサーバ・チケットを使用するステップを含む。この場合、ＫＥＹ＿ＲＥＱは、ユーザ選択およびオプションとしてのコンテンツ・ルールを含むセッション権利を含むＤＯＩオブジェクトを含む。通常、コンテンツ・ルールは、例えば、ある地理的領域への制限であってもよい。コンテンツ・ルールは、通常、すべてのユーザに適用することができることに留意されたい。さらに、プロトコルでどのメッセージを使用するかは、鍵管理がクライアントが始動したのか、サーバが始動したのかにより異なる。サーバが始動した場合には、図４にもっとはっきり示すように、他のメッセージの他に、ＴＫＴ＿ＣＨＡＬＬＥＮＧＥ（チケット・チャレンジ）メッセージを使用することができる。

図３は、本発明の例示としての実施形態による、使用者２１６（クライアント）がキャッシング・サーバ２１５（サーバ）に対して鍵管理をスタートした場合の、セキュリティおよび鍵管理プロトコルのハイ・レベルの流れ図である。

この図に示すように、機密が保護されている状態でキャッシング・サーバ２１５からコンテンツをストリーミングしたい使用者２１６は、鍵管理プロセスをスタートする。このスタートは、ＴＧＳサーバ２０９に対するＴＧＴ（チケット許可チケット）を入手するために、ＫＤＣ２０４にＡＳ＿ＲＥＱメッセージを送信することにより行われる。ＡＳ＿ＲＥＱメッセージは、使用者２１６の識別、ＫＤＣ２０４の識別、より詳細に説明すると、ＫＤＣ領域または管理領域、および応答にそれを結合する当面の目的を含む。ＡＳ＿ＲＥＱメッセージは、また、使用者２１６がサポートしている対称暗号化アルゴリズムのリストを含むことができる。もちろん、使用者２１６およびキャッシング・サーバ２１５の両方は、委任認証装置としての働きをするＫＤＣ２０４によりすでに登録されていて、両方のノードの識別を確認することができるものと仮定する。

この図に示すように、ＡＳ＿ＲＥＱメッセージへの応答の際に、ＫＤＣ２０４は、ＴＧＴ要求を確認し、使用者２１６を確認するために提供サーバ２２０によりチェックを行い、その後でＴＧＴを含むＡＳ＿ＲＥＰメッセージで応答する。ＴＧＴの非公開部分は、ＫＤＣ２０４だけが知っているＫＤＣ２０４のサービス鍵により暗号化されることに留意されたい。同じＫＤＣ２０４サービス鍵は、また鍵によるハッシュによりＴＧＴの認証を行うためにも使用される。使用者２１６は、ＫＤＣ２０４のサービス鍵を知らないので、使用者はサービス鍵を修正することもできないし、チケットの非公開部分を読むこともできない。使用者２１６は、依然として、ＫＤＣ２０４への以降の認証のためにセッション鍵を知る必要があるので、鍵一致アルゴリズム（例えば、楕円曲線Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）により、セッション鍵のもう１つのコピーが使用者２１６に配信される。

ＴＧＴを受信し、記憶した後で、使用者２１６は、このネットワーク上でコンテンツのストリーミングの要求をスタートすることができる。ＴＧＴを含んでいるＴＧＳ＿ＲＥＱメッセージは、キャッシング・サーバ２１５に対してチケットを要求しているＫＤＣ２０４（ＴＧＳサーバ２０９）に送られる。使用者２１６は、特定のコンテンツ・プロバイダへの加入のような追加の供給行為を行うことができることに留意されたい。また、使用者
２１６は、好適なキャッシング・サーバのリストを生成することもできる。

ＴＧＳ＿ＲＥＱメッセージに応じて、キャッシング・サーバ・チケットを有するＴＧＳ＿ＲＥＰメッセージが、ＫＤＣ２０４から使用者２１６に送信される。追加の好適なキャッシング・サーバがある場合には、使用者２１６は、ＴＧＴにより好適なキャッシング・サーバに対するキャッシング・サーバ・チケットを入手するために、ＫＤＣ２０４に連絡することができる。次に、これらのキャッシング・サーバ・チケットは、後で使用するためにキャッシュ内に記憶することができる。そうでない場合には、適当なキャッシング・サーバからコンテンツを要求した時点で、キャッシング・サーバ・チケットが入手される。

ある種の使用者の場合には、ＫＤＣ２０４は、最初に、キャッシング・サーバ・チケットを発行する前に、加入者許可データのために、提供サーバ２２０に問合わせを行わなければならない。この問合わせは、ＫＤＣ２０４と提供サーバ２２０との間のＡＵＴＨ＿ＤＡＴＡ＿ＲＥＱ／ＡＵＴＨ＿ＤＡＴＡ＿ＲＥＰ交換により行われる。ユーザ許可データは、チケット内に挿入することができる。キャッシング・サーバ・チケットは、ＴＧＴと同じフォーマットを有する（キャッシング・サーバ・チケットは、キャッシング・サーバ２１５への認証のために使用したセッション鍵を含む）。チケットの非公開部分は、キャッシング・サーバ２１５およびＫＤＣ２０４だけが知っているキャッシング・サーバ２１５のサービス鍵により暗号化される。チケットの認証は、また、同じサービス鍵で鍵をかけられているハッシュにより認証される。ＴＧＴの場合のように、使用者２１６は、このチケットを修正することができない。使用者２１６は、このサーバに対して自らの認証を行うためには、キャッシング・サーバ・チケットからのセッション鍵を必要とする。このセッション鍵のコピーは、ＴＧＴセッション鍵により暗号化され、使用者２１６に配信される。

ＴＧＳ＿ＲＥＰメッセージへのＡＳ＿ＲＥＱメッセージでスタートするこのプロセスは、サーバにアクセスする目的でサーバ・チケットを入手するために、クライアントがＫＤＣ２０４に連絡する上記一般的な段階に対応する。このプロセスは一般的なプロセスなので、コンテンツ・プロバイダからキャッシング・サーバにコンテンツを配信するために、使用を報告するために、および課金するため等のために、他のインタフェースを保護するために同じプロセスが使用される。さらに、そうすることにより、不必要なまたは複雑なオプションを使用しなくても、もっと安全なＩＰＲＭシステムができる。さらに、簡単になるので、速くて能率的な方法で種々の問題が識別され、修正される。

キャッシング・サーバ・チケットを含む、ＴＧＳ＿ＲＥＰメッセージを受信した場合には、チケットを含むＫＥＹ＿ＲＥＱメッセージが、キャッシング・サーバ２１５に送信される。ＫＥＹ＿ＲＥＱメッセージは、キャッシング・サーバ・チケットの他に、メッセージのＭＡＣ（メッセージ認証コード）、ＤＯＩ（解釈領域）オブジェクト、タイムスタンプを含む。ＤＯＩオブジェクトは、この機密保護セッションに関連するアプリケーション特有の情報を運ぶためのものである。この実施形態の場合には、ＤＯＩオブジェクトは、使用者２１６のためのセッション権利情報を含む。セッション権利は、コンテンツ・プロバイダ２０２により供給される。セッション権利をこのＤＯＩオブジェクト内に収容するのは、セッション権利は、この特定のコンテンツ配信アーキテクチャ（キャッシング・サーバを含む）特有のものであるからである。一方、ＥＳＢｒｏｋｅｒプロトコルは、一般的な鍵管理サービスを提供する。ＥＳＢｒｏｋｅｒは、そのアプリケーション指向情報もＤＯＩオブジェクト内に収容した状態で、他のタイプのセキュア・セッションに適用することができる。

キャッシング・サーバ２１５が、一般的なＫＥＹ＿ＲＥＱメッセージを受信した場合に
は、キャッシング・サーバは一般的でないＤＯＩオブジェクトを抽出する。次に、キャッシング・サーバ２１５は、例えば、ストリーミングのためにアプリケーション指向コードをチェックし、ＤＯＩオブジェクトおよび許可情報を確認する。セッション権利がチケット内の許可データと一致する場合には、セッション鍵を含むＫＥＹ＿ＲＥＰメッセージが使用者２１６に転送される。許可データはチケットからのもので、セッション権利オブジェクトが、ユーザの選択および／またはコンテンツ・ルールを含んでいることに留意されたい。ユーザの選択は、許可データおよびコンテンツ・ルールと比較される。コンテンツ・ルールがセッション権利オブジェクト内に含まれていない場合には、キャッシング・サーバは、コンテンツ・ルールを他の何らかの方法でコンテンツ・プロバイダから入手しなければならない。さらに、例えば、ケーブル・プロバイダのような他のソースからのある種のコンテンツ・ルールが存在する場合もある。

セッション権利が許可データと一致する場合には、この時点から、両方の当事者は、プロトコル鍵を有し、コンテンツのストリーミングのようなその最終的メッセージの暗号化をスタートすることができる。許可に失敗した場合には、エラー・メッセージが使用者に転送される。場合によっては、ＫＥＹ＿ＲＥＰメッセージが、一般的なＤＯＩオブジェクトを含んでいることに留意されたい。この場合、キャッシング・サーバ２１５は、あるアプリケーション指向情報を使用者２１６に返送しなければならない。例えば、ＩＰＲＭシステムの場合、キャッシング・サーバが、機密保護セッションを要求するために、Ｔｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅをコンテンツ・プロバイダに送信した場合には、後でキャッシング・サーバにより、ＫＥＹ＿ＲＥＰメッセージのＤＯＩオブジェクト内にセッションＩＤが供給される。Ｔｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅメッセージの認証は行われず、そのためＤＯＩオブジェクトを含んでいない。

この段階（ＫＥＹ＿ＲＥＱ／ＫＥＹ＿ＲＥＰ）は、サーバへの鍵要求を生成するために、クライアントがサーバ・チケットを使用する、一般的でない段階に対応する。この段階が一般的でない段階であるのは、ＤＯＩオブジェクトが保護中のインタフェースにより変化するからである。例えば、コンテンツ・プロバイダからキャッシング・サーバへのコンテンツの配信に関連するＤＯＩオブジェクトは、キャッシング・サーバから加入者に同じコンテンツを配信するのに使用するＤＯＩオブジェクトとは異なるものである。

図４は、本発明の例示としての実施形態による、キャッシング・サーバ２１５（サーバ）からコンテンツ・プロバイダ２０２（クライアント）に対して、鍵管理がスタートした場合の、セキュリティおよび可能な鍵管理プロトコルのハイ・レベルの流れ図である。キャッシング・サーバは、また図３に示すように、Ｋｅｙ Ｒｅｑｕｅｓｔメッセージにより、コンテンツ・プロバイダと一緒に鍵管理をスタートすることができることに留意されたい。図４の方法は、サーバがスタートした鍵管理を最適化し、サーバは潜在的に多数のクライアント・チケットを入手し、次にキャッシュに記憶する必要がなくなる。

コンテンツに対する要求を受信したが、キャッシング・サーバ２１５が要求されたコンテンツを有していない場合には、キャッシング・サーバ２１５が鍵管理をスタートする。図に示すように、キャッシング・サーバ２１５からコンテンツ・プロバイダ２０２に、ＴＫＴ＿ＣＨＡＬＬＥＮＧＥ（チケット・チャレンジ）メッセージを送信することにより鍵管理をスタートすることができる。ＴＫＴ＿ＣＨＡＬＬＥＮＧＥは、クライアントに鍵管理をスタートさせるためにサーバが使用するものである。

決定ブロック２２４において、コンテンツ・プロバイダ２０２が、すでに入手したキャッシング・サーバ・チケットを有している場合には、コンテンツ・プロバイダは、そのチケットを含むＫＥＹ＿ＲＥＱメッセージをキャッシング・サーバ２１５に転送する。これに応じて、キャッシング・サーバ２１５は、すでに説明したように、ＫＥＹ＿ＲＥＰメッ
セージを送信する。一方、決定ブロック２２４に戻って、コンテンツ・プロバイダ２０２が、キャッシング・サーバ・チケットもＴＧＴも有していない場合には、コンテンツ・プロバイダは、ＫＤＣ２０４にＡＳ＿ＲＥＱメッセージを送信し、ＫＤＣ２０４は、ＡＳ＿ＲＥＰメッセージで応答する。コンテンツ・プロバイダがそのＴＧＴを有している場合には、ＡＳ＿ＲＥＱ／ＲＥＰはスキップされる。

その後で、コンテンツ・プロバイダ２０２は、ＫＤＣ２０４にＴＧＳ＿ＲＥＱメッセージを送信し、キャッシング・サーバ・チケットを含むＴＧＳ＿ＲＥＰメッセージを受信する。キャッシング・チケットを入手した場合、コンテンツ・プロバイダ２０２は、この場合には、ＤＯＩオブジェクトを含んでいないＫＥＹ＿ＲＥＱメッセージを送信する。セッションＩＤは、応答であっても、要求であっても、または両方であってもよい。セッション権利は適用されない。何故なら、コンテンツ・プロバイダ２０２もキャッシング・サーバ２１５も使用者ではないからである。共有鍵が確立されると、ＳＥＣ＿ＥＳＴＡＢＬＩＳＨＥＤメッセージ（図示せず）が、コンテンツ・プロバイダ２０２によりキャッシング・サーバ２１５に送信される。サーバが鍵管理をスタートしたので、ＳＥＣ＿ＥＳＴＡＢＬＩＳＨＥＤメッセージは、サーバにセキュリティが確立されたことを通知する。

都合のよいことに、同じメッセージ、すなわち、ＴＫＴ＿ＣＨＡＬＬＥＮＧＥ、ＡＳ＿ＲＥＱ／ＡＳ＿ＲＥＰ、ＴＧＳ＿ＲＥＱ／ＴＧＳ＿ＲＥＰ、ＫＥＹ＿ＲＥＱ／ＫＥＹ＿ＲＥＰ、ＳＥＣＵＲＩＴＹ＿ＥＳＴＡＢＬＩＳＨＥＤを、クライアントまたはサーバのどちらが鍵管理をスタートしたかにより、複数のプロトコルおよびシナリオで使用されることに留意されたい。サーバが鍵管理を要求した場合には、ＴＫＴ＿ＣＨＡＬＬＥＮＧＥメッセージを含めて、すべてのメッセージを使用することができる。逆に、クライアントが鍵管理をスタートした場合には、ＴＫＴ＿ＣＨＡＬＬＥＮＧＥ以外のすべてのメッセージが使用される。クライアントが鍵管理をスタートした場合には、セキュリティ確立メッセージも通常スキップされることに留意されたい。都合のよいことに、１つの鍵管理プロトコルは、すべてのインタフェース上で使用されるので、システムが安全であるかどうかを簡単に分析することができる。さらに、システムは、ＤＯＩオブジェクト・フィールドを変更するだけで、同じ鍵管理による課金データを含むストリーミング・コンテンツおよび非ストリーミング・コンテンツ両方を保護する。

図５は、本発明の例示としての実施形態による、使用者２１６によるコンテンツの最初の登録および受信を示すブロック図である。
キャッシング・サーバ２１５からコンテンツを受信したい新しい使用者２１６は、最初に中央ユニット２１８で購入契約を行うことができる。

ブロック５０２において、ウェブ・ブラウザを使用する使用者２１６は、中央ユニット２１８が供給するウェブサイト（図示せず）にアクセスする。使用者２１６は、最初の購入契約およびソフトウェア・ダウンロード・ページのところにきて、任意のＩＰＲＭ構成要素を含むビューア・アプリケーションをダウンロードし、インストールする。別の方法としては、ビューア・アプリケーションおよびＩＰＲＭ構成要素を、ＣＤ−ＲＯＭのような取り外すことができる媒体を備えている使用者に配布することもできる。

ブロック５０４において、使用者２１６は、提供サーバ２２０により、ＳＳＬ（固定ソケット層）セッションをスタートするためにビューアを始動する。このセッションは、中央ユニット２１８の証明書（図示せず）によりスタートする。証明書は、使用者２１６が事前に入手した中央ユニット２１８の署名入りの公開鍵である。ＳＳＬセッションがスタートした後で、使用者２１６は、ユーザＩＤ用のフォームを含む最初の購入契約フォームに記入する。または、ユーザＩＤを、中央ユニットにより自動的に割り当てることができる。次に、使用者２１６は、ローカル・ホスト識別子を決定し、それを他の情報と一緒に
供給セッション２２０に送信する（この送信はビューアにより透明に行われる）。

ブロック５０６において、提供サーバ２２０は、ユーザＩＤを抽出し、このユーザＩＤをＥＳＢｒｏｋｅｒ（商標）の本人名に変換する。本人名は、一意に名付けられた使用者またはＩＰＲＭシステム２００に参加するサーバ例である。この場合、ビューア本人名は、ビューアに割り当てられている加入者ｉｄと同じものである。ユーザＩＤがＥＳＢｒｏｋｅｒ（商標）本人名に変換された後で、提供サーバ２２０は、ＫＤＣ２０４データベース（図示せず）内に新しいＥＳＢｒｏｋｅｒ（商標）本人を生成するために、ＫＤＣ２０４にコマンドを送信する。このコマンドも、使用者ホスト識別子を含む。

ブロック５０８において、ＫＤＣ２０４は、使用者２１６のための提供鍵（セッション鍵）を含む提供チケットを生成する。提供鍵は、本発明のある実施形態で使用する対称鍵であってもよい。提供鍵は、自分自身と使用者２１６との間のメッセージの認証のためにＫＤＣ２０４が使用する。その後で、提供チケットは、ＳＫＳ（セッション鍵シード）と一緒に提供サーバ２２０に返送される。使用者２１６は、（ＫＤＣ２０４鍵により暗号化されている）提供鍵にアクセスできないので、ＳＫＳは、提供チケット内に位置する提供鍵を再構成するために使用者２１６が使用する。

ブロック５１０において、提供チケットの他に、ユーザＩＤ、チケット期限切れ時間（チケットの暗号化されていない部分にすでに含まれている）、ＫＤＣ２０４名および／またはアドレス等を含む構成パラメータ、およびＥＳＢｒｏｋｅｒ（商標）デーモンを含むソフトウェア構成要素（オプションとしての）が、使用者２１６によりダウンロードされる。ソフトウェア構成要素は、（Ａｅｒｏｃａｓｔネットワークの場合のように）この登録手順の前にダウンロードしておくことができることに留意されたい。その後で、ＳＳＬ接続は終了する。

ブロック５１２において、ＥＳＢｒｏｋｅｒ（商標）デーモンは、ダウンロードした構成パラメータにより初期化される。
ブロック５１４において、使用者２１６とＫＤＣ２０４との間のＡＳ＿ＲＥＱメッセージの認証を行うための公開鍵／秘密鍵のペアが生成される。公開鍵は使用者２１６からＫＤＣ２０４に転送される。この転送は、ＣＬＩＥＮＴ＿ＥＮＲＯＬＬ＿ＲＥＱメッセージにより行われる。このメッセージは、使用者２１６がＳＫＳから導出した提供鍵により、（対称的に）署名された公開鍵を含む。提供チケット内の提供鍵にはアクセスできないので、使用者２１６は、一方向機能によりＳＫＳから提供鍵を導出する。ソフトウェア・クライアントにチケットを配布し、鍵を提供する際の問題は、ソフトウェア・クライアントが、無許可のソフトウェア・クライアントに転送するために、チケットおよび鍵をコピーすることができることである。この問題を解決するために、使用者２１６は、実際の提供鍵の代わりにＳＫＳを受信する。一方向機能によりＳＫＳを一意のホスト識別子と結合することにより提供鍵が生成される。ＳＫＳは特定のホスト指向のもので、他では使用できない。この実施形態の場合には、使用者２１６は、提供鍵をコピーするために下記の機能を実行する。

提供鍵＝ＳＫＧｅｎ^−１（ホストＩＤ、ＳＫＳ）
ＳＫＧｅｎ^−１（）は、一方向機能である。ＳＫＧｅｎ^−１（）は、妥当な時間の間（例えば、チケットの使用可能期間内）に計算することはできない。

ブロック５１６において、ＣＬＩＥＮＴ＿ＥＮＲＯＬＬ＿ＲＥＱメッセージを受信した場合には、ＫＤＣ２０４は、要求を確認するために、そのローカル・データベース内で使用者２１６を発見する。要求が有効である場合には、ＫＤＣ２０４は、ＫＤＣ上に局部的に位置させることができるクライアント・データベース内か、または機密保護アクセスを
有する他の遠隔地に公開鍵を記憶する。別の方法としては、ＫＤＣ２０４は、使用者２１６に転送するために、公開鍵により証明書を生成することができる。鍵の受信を通知するメッセージＣＬＩＥＮＴ＿ＥＮＲＯＬＬ＿ＲＥＰは記憶済みで（または別の方法としては、クライアント証明書を含んでいるが）、次に使用者２１６に転送される。

ブロック５１８において、使用者２１６は登録され、コンテンツ・プロバイダ２０２を含む種々のプロバイダからのコンテンツのリストを有するデータベース２０８を備えるウェブサイト（図示せず）と連絡することができる。所望のコンテンツを発見した場合には、使用者２１６は、コンテンツ・プロバイダ２０２の方に転送する。

次に、ブロック５２０において、使用者２１６は、自分が転送したコンテンツ・プロバイダ２０２と連絡し、キャッシング・サーバに、その好適なリスト、加入したサービスのリスト、コンテンツに対するその支払い能力等を送る。

ブロック５２２において、コンテンツ・プロバイダ２０２は、特定の使用者およびサービスのコンテキストに依存する購入オプションの最適化したサブセットを提供する。例えば、このサービスにすでに加入している使用者のために、価格選択スクリーンをバイパスすることができる。

ブロック５２４において、コンテンツ・プロバイダ２０２は、使用者２１６が選択した購入オプションを収容しているセッション権利オブジェクト、コンテンツ・アクセス・ルール（例えば、停電地域）のオプションとしてのセット、および選択したコンテンツへの参照を生成する。例えば、使用者がコンテンツ・プロバイダからこれらのセッション権利を要求した場合、使用者２１６が生成した乱数であるセッションＩＤ、セッション権利オブジェクトは、それ以降はこれらのセッション権利はもはや有効でなくなる有効期限終了時間、プロバイダＩＤ等を含むことができる。そうしたい場合には、セッション権利オブジェクトは、コンテンツ・ルールであってもよい。別の方法としては、これらのルールを、ある種の帯域外方法によりキャッシング・サーバに送ることができる。

ブロック５２６において、コンテンツ・プロバイダ２０２は、使用者２１６を適当なキャッシング・サーバに転送する。この場合、コンテンツを使用者２１６に最も近いキャッシング・サーバ２１５からストリーミングすることができる。使用者２１６が、購入契約を結んだ場合で、すでにキャッシング・サーバ２１５のためのキャッシング・サーバ・チケットをキャッシュに記憶している場合には、使用者はこのチケットを検索する。使用者が、キャッシュにチケットを記憶していない場合には、使用者は、正しいキャッシング・サーバ・チケットを入手するために、ＴＧＴによりＫＤＣ２０４と連絡する。

ブロック５２８において、使用者２１６は、キャッシング・サーバ・チケットにより、キャッシング・サーバ２１５に対して自分自身の認証を行い、同時に（同じＫＥＹ＿ＲＥＱメッセージで）キャッシング・サーバ２１５に、コンテンツ・プロバイダ２０２から入手したセッション権利オブジェクトを転送する。使用者２１６とキャッシング・サーバ２１５との間の通信は、上記ＫＥＹ＿ＲＥＱ／ＫＥＹ＿ＲＥＰメッセージにより行われる。

ブロック５３０において、キャッシング・サーバ２１５は、セッション権利オブジェクトから、チケットが内蔵している使用者２１６のエンタイトルメントに対するアクセス・ルール、およびセッション権利オブジェクト内のユーザの選択（使用者が選択した購入オプション）に対するアクセス・ルールをチェックする。エンタイトルメントは、基本的には、コンテンツにアクセスできるようにする使用者２１６特有の許可データである。この一組のコンテンツ・アクセス・ルールは、オプションとしてのものである。何故なら、コンテンツと一緒にキャッシング・サーバ２１５に直接送ることができるからである。さら
に、キャッシング・サーバ２１５は、そうしたい場合には、複数のソースから追加のコンテンツ・アクセス・ルールを収集することができる。例えば、アクセス・ネットワーク・プロバイダ（例えば、ケーブル・システム・オペレータ）は、そのネットワークを通しての配信にある程度の制限を行うことができる。

ブロック５３２において、アクセスが承認された場合には、使用者２１６およびキャッシング・サーバ２１５は、コンテンツの配信についてコンテンツ暗号鍵（ＣＥＫ）と交渉する。

ブロック５３４において、使用者２１６は、コンテンツ（ＲＴＳＰ ＵＲＬ）の説明を入手し、次に、コンテンツの再生を要求するために、キャッシング・サーバ２１５への暗号化したＲＴＳＰコマンドの発行をスタートする。

ブロック５３６において、キャッシング・サーバ２１５は、ＲＴＳＰコマンドを受信し、これらコマンドを復号し、暗号化したＲＴＳＰ応答を返送する。ＲＴＳＰコマンドが特定のＵＲＬの再生を要求している場合には、キャッシング・サーバ２１５は、指定ＵＲＬが、このセキュア・セッション（セッションＩＤにより識別した）に対して、セッション権利オブジェクト内で指定されたものであることを確認する。

ブロック５３８において、ＲＴＳＰ ＵＲＬの再生の要求を受信した後で、キャッシング・サーバ２１５は、暗号化したＲＴＰパケットの送信をスタートし、キャッシング・サーバ２１５および使用者２１６の両方は、周期的に暗号化したＲＴＣＰ報告パケットを送信する。同じＲＴＳＰ ＵＲＬに関連するすべてのＲＴＰおよびＲＴＣＰパケットは、同じセッションＩＤにより暗号化され、このセッションＩＤは、キャッシング・サーバ２１５が使用者２１６から暗号化したＲＴＳＰメッセージの受信をスタートした際に記録したものである。

ブロック５４０において、使用者２１６は、コンテンツを解読し、再生する。同時に使用者２１６は、同じセッションＩＤを使用して、依然として暗号化されている追加のＲＴＳＰコマンド（例えば、コンテンツの再生を一時停止したり、再開するための）を発行することができる。キャッシング・サーバ２１５は、コンテンツを見た人、コンテンツを見た時間、およびどんな機構によりコンテンツを購入したかを追跡する。次に、この情報は、使用者２１６に対して要求するのか、広告主に対して要求するのか、課金目的のために使用される。都合のよいことに、このシステムを使用すれば、種々のプロバイダからの多数のコンテンツを通して、また１回だけ入力したクレジット番号のような課金情報により簡単に遷移することができる。コンテンツを要求した場合には、使用者に関する情報は、コンテンツ・プロバイダに透明に送信される。使用者はそれほど努力しなくてもすむ。何故なら、複数のアクセス・コードを覚える必要がないからである。
コンテンツの発行
コンテンツ・プロバイダ２０２が中央サーバ２０５にコンテンツを発行したい場合には、上記と同じプロトコル・ステップを使用することができる。例えば、中央サーバ２０５は、ＫＥＹ＿ＲＥＱメッセージを送信し、その後で上記のようにＫＥＹ＿ＲＥＰメッセージを送信することにより、コンテンツ・プロバイダ２０２とのセキュリティ関連を確立することができる。
キャッシング・サーバ間でのコンテンツの配信
コンテンツを要求しているキャッシング・サーバは、ソース・キャッシング・サーバ・チケットを供給することにより、認証および鍵配信プロセスをスタートする。キャッシング・サーバが、このチケットをまだ有していない場合には、キャッシング・サーバは、このチケットをＴＧＴによりＫＤＣ２０４から要求する。
課金データの報告
ＫＤＣ２０４が、使用者２１６にキャッシング・サーバ、すなわち、キャッシング・サーバ２１５のためのサービス・チケットを発行した場合には、ＫＤＣ２０４は、そのチケットに、例えば加入データおよび許可することができる購入オプションのような使用者許可データを追加する。使用者２１６の許可データおよびコンテンツ・プロバイダ２０２が生成し、使用者２１６が転送した機密保護オブジェクトに基づいて、キャッシング・サーバ２１５は、使用者２１６にコンテンツへのアクセスを許可し、使用および購入情報を記録する。周期的に、キャッシング・サーバは、課金情報を報告するために課金センター２１１と連絡する。キャッシング・サーバは、課金センター・チケットにより、課金センター２１１へ自分自身の認証を行う。認証が終了すると、キャッシング・サーバは、機密保護状態で、課金センター２１１に記録した課金情報を転送する。課金センター２１１は、提供センターが維持している使用者データベースから使用者データ（課金アドレス、クレジット・カード等）を検索することができる。中央ユニット２１８は、同じ場所の課金システムを通して課金を行うことができ、またはローカル・ネットワーク・オペレータまたはコンテンツ・プロバイダの設置場所に常駐している課金システムとのインタフェースを通して課金することができる。
キャッシング・サーバの最初の設置
通常、キャッシング・サーバ２１５は、そのサービス鍵を最初に入手し、その後で更新するために、ＳＥＲＶＩＣＥ＿ＫＥＹ＿ＲＥＱ／ＳＥＲＶＩＣＥ＿ＫＥＹ＿ＲＥＱを除いて、上記類似の機構により設置される。そうすることにより、サービス鍵を自動的にスケジュールに基づいて更新することができ、それにより、特定のサービス鍵が危険にさらされる機会を低減することができる。
ストリーミングおよび非ストリーミング・コンテンツ
保護されているコンテンツの基本的な分類は２つある。すなわち、ストリーミング・コンテンツと非ストリーミング・コンテンツである。下記のプロトコルは、実際のストリーミング・コンテンツまたはコンテンツに関連する情報を配信するために使用される。ストリーミング・コンテンツ：ＲＴＰ（リアルタイム・プロトコル）／ＲＴＣＰ（リアルタイム制御プロトコル）、ＲＴＳＰ（リアルタイム・ストリーミング・プロトコル）。サーバ間のコンテンツの非ストリーミング転送：ストリーミング記述：ＳＤＰ（セッション記述プロトコル）を含むＲＴＳＰ。他の非ストリーミング・コンテンツ：ＨＴＴＰ（提供、ディレクトリへのコンテンツ発行）；ＴＣＰ（トランスポート制御プロトコル）またはＵＤＰ（ユーザ・データグラム・プロトコル）（コンテンツ使用報告）を通してのカスタム・プロトコル。ストリーミング・コンテンツ。規格をベースとするシステムにおいては、ストリーミング・コンテンツは、通常、ＲＴＰにより配信される。このＩＰＲＭシステムにより保護することもできるＲｅａｌおよびＭｉｃｒｏｓｏｆｔのＷｉｎｄｏｗｓ Ｍｅｄｉａのような追加の専用のストリーミング・プロトコルもある。
ＲＴＰセキュリティ・サービス
無許可の当事者が支払い済みのコンテンツを決して見ることができないようにするために、認証、暗号化およびメッセージの保全が実施される。
ＲＴＰ暗号化機構
各媒体ＲＴＰパケットは、プライバシーを保護するために暗号化される。２つの終点は、システム構成により定義され、サーバにより制御される特定の暗号化アルゴリズムについて交渉することができる。暗号化は、パケットのペイロードに対して適用される。ＲＴＰヘッダは、ＲＦＣ−１８８９フォーマットを有する。最初の１２のオクテットは、各ＲＴＰパケット内に位置していて、一方、ＣＳＲＣ識別子のリストは、ミキサが挿入した場合だけ存在する。
ＲＴＰパケット・コード化
各パケットは、下記の手順によりコード化することができる。送信側はこのパケットのセッションＩＤを参照する。参照は、ＳＳＲＣ（ＲＴＰ同期ソース）または宛先ＩＰアドレスおよびＵＤＰポートに基づいて行うことができる。（二地点間配信の場合には、セッションＩＤは、接続の両方の終点において一意の乱数である。）このセッションＩＤが、
今度はこのパケットを暗号化するための一組のセキュリティ・パラメータを識別する。これらのパラメータは、（１）ＥＫ−ＲＴＰ暗号鍵である。この暗号鍵は、一方向の（例えば、いつでもキャッシング・サーバからその使用者２１６へ）トラヒックを暗号化するためだけに使用される。ＩＰＲＭシステムにおいては、二方向ＲＴＰセッションが使用され、そのためＲＴＰ暗号鍵は１つのセッションに対して１つしかない。（２）１６バイト初期化ベクトル（ＩＶ）。第１の態様によれば、ＲＴＰヘッダを含んでいないパケット本体は、ＣＢＣモードで選択したブロック暗号により暗号化される。ある実施形態の場合には、ＡＥＳ（高度暗号化規格）暗号が使用される。ＡＥＳは、１２８ビット・ブロック上で動作する。最後のブロックがそれより短い場合には、それを暗号化するために、ＲＢＴ（残留ブロック終了）という特殊な処理を使用することができる。
ＲＴＰパケット復号
各パケットは下記の手順により復号される。受信側はこのパケットのセッションＩＤを参照する。参照は、ＳＳＲＣ（ＲＴＰ同期ソース）またはソースＩＰアドレスおよびＵＤＰポートに基づいて行うことができる。（二地点間配信の場合には、セッションＩＤは、接続の両方の終点において一意の乱数である。）このセッションＩＤが、今度は、このパケットを解読するための一組のセキュリティ・パラメータを識別する。これらのパラメータは、ＥＫ−ＲＴＰ暗号鍵、一方向機能によりＲＴＰパケット・ヘッダから導出される初期化ベクトル（ＩＶ）である。各ＲＴＰパケット・ヘッダは、異なる一連番号またはタイムスタンプを含んでいるので、各ＲＴＰパケット・ヘッダは、各パケット毎に一意のＩＶになることに留意されたい。
ＲＴＣＰパケット・コード化
暗号化されたＲＴＣＰパケットは、元の暗号化したＲＴＣＰパケットと下記のいくつかの追加フィールドを含む。

・機密保護セッション識別子
・パケット一連番号
・選択した暗号化アルゴリズムがＣＢＣ（暗号ブロック・チェーニング）モードのブロック暗号である場合だけ必要なＩＶ（初期化ベクトル）
・ＭＡＣ − メッセージの保全を提供するためのメッセージ認証コード
各パケットは、下記の手順によりコード化される。ソースＩＰアドレスおよびＵＤＰポートは、このパケットのセッションＩＤを参照するために使用される。（二地点間配信の場合には、セッションＩＤは、接続の両方の終点に対して一意の乱数である。）このセッションＩＤが、今度は、このパケットを暗号化するための一組のセキュリティ・パラメータを識別する。これらのパラメータは、ＥＫ（媒体ストリーム暗号鍵（ＲＴＰ用のものと同じ）Ｋ_ＭＡＣ）メッセージ認証鍵である。

次に、一連番号が決定される。この一連番号は、現在のセキュリティ・パラメータと一緒に送信された第１のＲＴＣＰメッセージの場合には０であり、その後で１つずつ増大する。次に、暗号ブロック・サイズと同じ大きさのランダム初期化ベクトル（ＩＶ）が生成される。次に、ＣＢＣモードで選択したブロック暗号によりＲＴＣＰメッセージが暗号化される。この時点で、ＡＥＳ暗号を使用することができる。ＡＥＳは、１２８ビット・ブロック上で動作する。最後のブロックがＡＥＳより短い場合には、ＡＥＳを暗号化するために、ＲＢＴ（残留ブロック終了）という特殊な処理を使用することができる。その後で、コード化されたＲＴＣＰメッセージがＭＡＣの例外と結合され、ＲＴＣＰメッセージ上のＭＡＣが計算され、計算したものが同じメッセージに追加される。
ＲＴＣＰパケット復号
各パケットは、下記の手順により復号される。ヘッダ内のセッションＩＤは、このパケットを解読するための一組のセキュリティ・パラメータを参照するために使用される。これらのパラメータは、ＥＫ（媒体ストリーム暗号鍵（ＲＴＰ用のものと同じ）Ｋ_ＭＡＣ）メッセージ認証鍵である。ＭＡＣフィールド自身を含んでいないコード化されたメッセー
ジ上でＭＡＣの計算が行われる。計算したＭＡＣが、コード化メッセージ内の値と一致するかどうかの確認が行われる。一致しない場合には、それ以上の復号を打ち切り、エラーを報告する。下記の小節内に指定する一連番号を確認する。確認に失敗した場合には、メッセージの再生は拒否される。ＣＢＣモードで選択したブロック暗号により、暗号化したＲＴＣＰメッセージが解読される。このメッセージのためのＩＶは、コード化したメッセージ内に含まれている。
一連番号の確認
一連番号の確認には２つの場合がある。ＵＤＰを通してメッセージを受信した場合と、ＴＣＰを通してメッセージを受信した場合である。ＲＴＣＰメッセージは、いつでもＵＤＰを通して送信されるが、同じメッセージ復号ルールが、ＲＴＣＰ以外のプロトコルにも適用される。
ＴＣＰを通して送信されたアプリケーション・メッセージのための一連番号の確認
受信したメッセージの一連番号は、前に受信したメッセージの一連番号より大きい。受信側は、一連番号が前のメッセージより２つ以上大きい場合に、メッセージを受け入れる。（受信側の内部バッファがオーバフローしたか、処理前にいくつかの外からのメッセージを喪失した場合に、このシナリオが適用される。）
ＵＤＰを通して送信されたアプリケーション・メッセージのための一連番号の確認
一連番号は、スライディング・ウィンドウ・プロトコルにより確認される。スライディング・ウィンドウＷのサイズは、ＵＤＰトランスポートの信頼性により異なり、各終点で局地的に構成される。パラメータＷは、３２または６４である。スライディング・ウィンドウは、ビット・マスク動作およびビット・シフト動作により最も効率的に実施される。受信側が機密保護セッションからのＵＤＰストリーム内の第１のパケットを処理する前に、スライディング・ウィンドウ内の第１の一連番号が０に初期化され、最後のものはＷ−１である。ウィンドウ内のすべての一連番号は、１回目は受け入れられるが以降は拒否される。ウィンドウの「左」端のものよりも小さいすべての一連番号は拒否される。ウィンドウの「右」端のものよりも大きい一連番号を有する認証したパケットを受信した場合には、一連番号は受け入れられ、ウィンドウの「右」端のものはこの一連番号により置き換えられる。同じウィンドウ・サイズを維持するために、ウィンドウの「左」端のものは更新される。あるウィンドウ（Ｓ_{ＲＩＧＨＴ}−Ｗ＋１、Ｓ_{ＲＩＧＨＴ}）に対して一連番号Ｓ_ＮＥＷを受信した場合で、Ｓ_ＮＥＷ＞Ｓ_{ＲＩＧＨＴ}の場合には、ウィンドウは新しくなる。

（Ｓ_ＮＥＷ−Ｗ_ＲＴＣＰ＋，Ｓ_ＮＥＷ）
ＲＴＳＰコード化
コード化したＲＴＳＰメッセージを、これらメッセージを直ちに復号するプロキシが直接受信した場合には、これらメッセージを２進法でコード化することができる。しかし、ＲＴＳＰメッセージがある種の中間ＨＴＴＰ中継エージェントにより転送された場合には、これらメッセージをＡＳＣＩＩコード化して印刷することができる。ＲＴＳＰメッセージの２進コード化は、ＲＴＣＰメッセージのコード化のそれと同じである。印刷できるＡＳＣＩＩコード化が必要な場合には、ＲＴＳＰ２進コード化は、Ｂａｓｅ６４コード化である。ＲＴＳＰパケットは下記のようにコード化される。ＲＴＣＰパケット用の手順と同じ手順により２進コード化を行う。印刷できるＡＳＣＩＩが必要な場合には、Ｂａｓｅ６４が、２進コード化をコード化する。＜ＣＲ＞＜ＬＦ＞文字をＢａｓｅ６４コード化の各８０文字の後に挿入する。最後の行が８０文字未満の場合には、＜ＣＲ＞＜ＬＦ＞をもう１つ終わりに追加する。
ＲＴＳＰメッセージ復号
コード化された各ＲＴＳＰメッセージは、下記のように復号される。ＲＴＳＰメッセージが、Ｂａｓｅ６４によりコード化されている場合には、最初に＜ＣＲ＞＜ＬＦ＞文字を削除し、次にＡＳＣＩＩメッセージをＢａｓｅ６４により復号して２進コード化する。上記ＲＴＣＰパケットの場合と全く同じ方法で２進コード化を復号する。場合によっては、
クライアント（例えば、ビューア）は、第三者（元のサーバ）からこのコンテンツを受信するために、セッション権利を入手しなければならない。これらの場合、クライアントは、Ｋｅｙ ＲｅｑｕｅｓｔメッセージのＤＯＩオブジェクト内に、コンテンツに対するそのセッション権利を送る。二地点間配信の場合には、ＲＴＳＰプロトコル自身は、通常、ＲＴＳＰ ＵＲＬにより識別された特定のコンテンツのストリーミングを要求するために使用される。ＲＴＳＰクライアント・ソフトウェアは、機密保護ＲＴＳＰメッセージにより要求されたＲＴＳＰ ＵＲＬが、実際にその機密保護セッション（セッションＩＤにより識別された）に関連するセッション権利内のＲＴＳＰ ＵＲＬに対応することを確認しなければならない。
ＩＰＲＭプロトコル・メッセージ
テーブル１に記載するプロトコル・メッセージについて以下にさらに詳細に説明する。ＡＳ＿ＲＥＱメッセージ
ＡＳ＿ＲＥＱメッセージは、ＫＤＣクライアントが、サーバからチケットを要求する際に使用するチケット許可チケットを入手するために、ＥＳＢｒｏｋｅｒ（商標）認証サーバ（ＫＤＣ２０４）に送信される。このメッセージは、クライアントの識別、サーバの識別、およびこのクライアントがサポートしている対称暗号化アルゴリズムのリストを含む。再生をチェックするために、このメッセージはまたタイムスタンプも含む。メッセージが完全なものであることを示すために署名がしてある。署名は、鍵によるチェックサム（例えば、ＨＭＡＣ）であってもよいし、デジタル署名であってもよい。そうしたい場合には、デジタル証明書をこのメッセージに内蔵させ、将来デジタル署名を確認するために、記憶している公開鍵の代わりに使用することができる。鍵によるチェックサムを確認するためのクライアントの永久対称鍵を、同じユーザ・データベース内に保持することができる。このメッセージは、また、鍵一致（例えば、楕円曲線Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎパラメータ）のために必要な公開鍵情報も含む。
ＡＳ＿ＲＥＰメッセージ
ＡＳ＿ＲＥＰメッセージは、ＫＤＣ２０４によりＡＳ＿ＲＥＱに応じて生成される。ＫＤＣ２０４は、データベース内のサーバ鍵およびクライアント鍵を参照して、ＫＤＣ２０４による以降の認証のためにセッション鍵を生成する。ＫＤＣ２０４は、平文および暗号化部分の両方を有するチケット許可チケットを生成する。ＴＧＴ内のサーバの識別は、いつでも「ＫＤＣ」（引用符を含まない）でなければならないし、ＫＤＣ領域は、ＡＳ＿ＲＥＱメッセージのサーバ領域（Ｓｒｅａｌｍ）フィールド内に別に列挙される。サーバの識別およびチケットの有効期間は、発行したチケット内の平文に含まれる。チケットの暗号化した部分は、クライアント名、セッション鍵および秘密にしなければならない任意の他のデータを含む。チケットは、また、ＫＤＣ２０４がサポートしている暗号タイプおよびチェックサム・タイプのリストを供給する。チケットの暗号化された部分は、ＫＤＣ２０４の秘密鍵により暗号化される。メッセージには、ＫＤＣ２０４が、クライアントがＡＳ＿ＲＥＱ内に指定した公開鍵に対応する秘密鍵により、またＡＳ＿ＲＥＱで指定した署名アルゴリズムにより署名する。公開鍵情報は、鍵一致パラメータのＫＤＣ２０４の公開部分であり、クライアントが選択したものと同じ鍵一致アルゴリズムを示す。ＫＤＣ２０４のデジタル署名を確認するための公開鍵は、供給中に、そのクライアントにより入手することができる。
ＡＳ＿ＲＥＰの暗号化部分
メッセージの暗号化部分は、チケット内のものと同じ情報を含んでいるので、クライアントは、自分自身の許可データにアクセスする。上記暗号化部分は、また、この応答が、この特定のクライアントのために、ＫＤＣ２０４が元々構成したものであることを確認するために、クライアントの識別を含む。このデータは、鍵一致アルゴリズムから導出した対称鍵により暗号化される。しかし、ＡＳ＿ＲＥＰの暗号化部分内の鍵は、チケット内のセッション鍵と同じものではない。上記鍵は、実際のセッション鍵を生成するために、クライアントが、そのホストＩＤと一緒に使用するＳＫＳ（セッション鍵シード）である。ＴＧＳ＿ＲＥＱメッセージ
クライアントは、所与のサーバに対する認証証明書を入手したい場合、クライアントとチケット許可サーバとの間のＴＧＳ交換をスタートする。ある場合には、クライアントは、ＡＳ交換により、チケット許可サービス用のチケットをすでに入手している。ＴＧＳ交換のためのメッセージ・フォーマットは、ＡＳ交換のためのメッセージ・フォーマットに類似している。大きな違いは、ＴＧＳ交換の際の暗号化および解読が、鍵一致アルゴリズムにより行われないことである。代わりに、チケット許可チケットからのセッション鍵が使用される。このメッセージは、キャッシング・サーバ・チケット（ＫＥＹ＿ＲＥＱで使用することができる）を入手するために、クライアントによりチケット許可サーバに送られる。クライアントは、ＡＳ＿ＲＥＰから入手したＴＧＴをメッセージの一部として提示する。メッセージは、サーバの識別およびクライアントの識別（ＴＧＴに内蔵されている）を指定する。クライアントの識別がＴＧＴ内で暗号化されるので、クライアントのプライバシーは保護される（ＩＰＲＭシステムにおいては、この機能は使用者２１６にとって有用である）。スヌーパはユーザが要求しているサービスを検出することができない。サーバは、再生を検出するためにクライアントのタイムスタンプを使用する。ＴＧＴ内のセッション鍵は、メッセージ上のチェックサムを計算するために使用される。
ＴＧＳ＿ＲＥＰメッセージ
ＴＧＳ＿ＲＥＰメッセージは、ＴＧＳ＿ＲＥＱメッセージに応じてＫＤＣ２０４により生成される。このメッセージは、サービスを要求しなければならない場合、クライアントがサーバに提示するエンド・サービス・チケット（ＫＤＣ２０４が発行した）を含む。サーバの識別およびチケットの有効期間は、発行したチケット内の平文に内蔵されている。チケットの暗号化された部分は、クライアント領域、クライアント名、およびサーバおよびＫＤＣ２０４が共有する鍵により暗号化されたセッション鍵を含む。秘密にしておかなければならない任意の他のクライアント・データは、チケットの暗号化された部分の一部として内蔵される。メッセージの暗号化された部分は、指定アプリケーション・サーバに対して認証を行うために使用することができる実際のセッション鍵を生成するために、クライアント（ホストＩＤと一緒に）が使用することができるＳＫＳ（セッション鍵フィールド内の）を含む。メッセージの暗号化された部分は、また、サーバに提示されるクライアント許可データを含むことができる。メッセージには、ＫＤＣ２０４がＴＧＳセッション鍵により、鍵によるチェックサムで署名する。ＩＰＲＭシステム２０００は、現在、使用者２１６に発行したチケット内の許可データを使用する。
Ｔｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅメッセージ
サーバは、鍵管理をスタートしたい場合には、いつでもＴｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅメッセージを使用する。このメッセージは認証されないが、そのヘッダ（）内にＳＴＩＤを含む。本明細書で使用する場合には、ＳＴＩＤ（ソース・トランザクション識別子）は、鍵管理メッセージのイニシエータが選択した一意のランダムな値である。

クライアントの応答は、応答のＤＴＩＤヘッダ・フィールド内のこのＳＴＩＤの値を含む。認証を行わない場合でも、この値により、敵対者が不必要な鍵管理交換をトリガできるサービス・アッタクの否認を防止する。このメッセージは、またそのサーバに対する正しいチケットを発見または入手するために、クライアントが使用するサーバ領域および本人名を含む。ＩＰＲＭシステム２０００内においては、アプリケーション・サーバは、コンテンツ・プロバイダ（クライアント）とキャッシング・サーバ（アプリケーション・サーバ）との間のインタフェース上でＴｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅにより鍵管理をスタートする。Ｔｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅメッセージは、また下記のフィールドを含む。

・鍵が確立中のターゲット・プロトコルに対する識別子
・アプリケーション役割 − 鍵が確立中の特定のアプリケーションを識別することである。鍵マネージャ・プロセスが、鍵を確立するために他のホストから要求を受信した場合には、鍵マネージャ・プロセスは、確立した鍵をハンドオフし、ＤＯＩオブジェクトの
コンテンツを確認するローカル・アプリケーションを発見するために、アプリケーション役割を使用する。

・アプリケーション・サーバ名および領域
Ｋｅｙ Ｒｅｑｕｅｓｔメッセージ
Ｋｅｙ Ｒｅｑｕｅｓｔは、新しい一組のセキュリティ・パラメータを確立するために、クライアントにより送信される。クライアントがＴｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅメッセージを受信した場合はいつでも、クライアントはＫｅｙ Ｒｅｑｕｅｓｔで応答することができる。クライアントは、またサーバとの新しい鍵を周期的に確立するために、このメッセージを使用することができる。クライアントは、ＴＧＳ Ｒｅｐｌｙ内で前に入手した有効なチケットでスタートする。サーバは、サーバがチケットを解読し、確認するために使用することができるそのＳｅｒｖｉｃｅ Ｋｅｙによりスタートする。Ｋｅｙ Ｒｅｑｕｅｓｔは、クライアント・チケットおよびクライアントの認証のために必要な鍵によるチェックサムを含む。このメッセージは、また（再生アタックを防止するために）タイムスタンプを含む。このメッセージは下記のフィールドを含む。

・鍵が確立中のターゲット・プロトコルに対する識別子
・アプリケーション役割 − 鍵が確立中の特定のアプリケーションを識別することである。

・クライアントのホストの現在の時刻
・クライアントを識別するために使用するＴＧＳ＿ＲＥＰから入手したサービス・チケット
・クライアントによりサポートされている暗号アルゴリズム（ｃｉｐｈｅｒｓｕｉｔｅｓ）のリスト
・プロトコル指向であり、アプリケーション指向であり、暗号化することができるＤＯＩデータ
・この認証装置が第三者（例えば、コンテンツ・プロバイダ）により生成された、ＤＯＩデータのコンテンツを確認する認証装置
・メッセージの保全を提供するためにクライアントが生成したＭＡＣ
ＫＥＹ Ｒｅｐｌｙ
ＫＥＹ Ｒｅｐｌｙメッセージは、Ｋｅｙ Ｒｅｑｕｅｓｔメッセージに応じてサーバにより送信される。ＫＥＹ Ｒｅｐｌｙは、クライアントおよびサーバ間で共有しているセッション鍵で暗号化されたランダムに生成した副鍵を含むことができる。副鍵の長さは、ＤＯＩ指向である。ＫＥＹ Ｒｅｐｌｙは、セキュリティ・パラメータを確立するために必要ないくつかの追加情報を含む。ＫＥＹ Ｒｅｐｌｙメッセージは下記のフィールドを含む。

・鍵が確立中のターゲット・プロトコルに対する識別子
・アプリケーション役割 − 鍵が確立中の特定のアプリケーションを識別することである。

・ターゲット・プロトコルまたはオブジェクトを保護するための鍵を導出するために使用する暗号化した副鍵
・ターゲット・プロトコルまたはオブジェクトを保護するために使用しなければならない暗号化および認証アルゴリズム
・いくつかのアプリケーション指向またはプロトコル指向パラメータを含むことができる暗号化されたＤＯＩオブジェクト
・副鍵の有効期間
・古い副鍵が無効になる前に自動的に、新しい副鍵を交渉しなければならないかどうか
を示すフラグ
・このメッセージの受信側が、セキュリティ確立メッセージでフォローアップしなければならないかどうかを示すフラグ
・メッセージの保全を行うためのＭＡＣ
セキュリティ確立
セキュリティ確立メッセージは、クライアントがＫＥＹ Ｒｅｐｌｙを受信し、新しいセキュリティ・パラメータのセットアップに成功したことを肯定応答するために、クライアントによりサーバに対して送信される。このメッセージは、ＡＣＫ＿ＲＥＱフラグが、ＫＥＹ Ｒｅｐｌｙ内にセットされた場合だけ送信することができる。サーバが、Ｔｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅにより鍵管理をスタートした場合、サーバはこの肯定応答をチェックしたいと考え、そのためＫＥＹ Ｒｅｐｌｙ内にＡＣＫ要求フラグをセットすることにより、肯定応答を要求することができる。このメッセージは下記のフィールドを含む。

・鍵が確立中のターゲット・プロトコルに対する識別子
・アプリケーション役割 − 鍵が確立中の特定のアプリケーションを識別することである。

・このメッセージおよび先行するＫＥＹ ＲｅｐｌｙメッセージをカバーするＭＡＣ
ＣＬＩＥＮＴ＿ＥＮＲＯＬＬ＿ＲＥＱメッセージ
ＣＬＩＥＮＴ＿ＥＮＲＯＬＬ＿ＲＥＱメッセージは、その公開鍵を更新したいと考えている、またはＫＤＣ２０４データベース内にまだ存在していないで、対応するデジタル証明書を有していない新しい公開鍵を指定したいと考えているクライアントによりＫＤＣ２０４に送信される。このメッセージは、提供チケットおよび提供鍵（提供チケット内のセッション鍵）で鍵をかけられているチェックサムにより認証することができる。提供サーバは、ＩＮＩＴ＿ＰＲＩＮＣＩＰＡＬ＿ＲＥＱメッセージにより、あるＥＳＢｒｏｋｅｒ（商標）本人のために、提供チケットを入手することができる。提供サーバは、次に、クライアントに、提供チケットおよび対応する提供鍵を転送するための帯域外方法を使用する。クライアントは、また、（ＡＳ＿ＲＥＰメッセージで）クライアントが受け入れるＫＤＣ２０４証明書のタイプを指定することができる。対応する属性（ＫＤＣ２０４証明書のタイプ）が存在しない場合には、このクライアントは、どのタイプのＫＤＣ２０４証明書もサポートしない。このメッセージを受信した場合には、ＫＤＣ２０４は、その方針に基づいて、公開鍵を記憶すべきか、クライアントに証明書を発行すべきかまたはこれら両方を行うべきかを決定する。ＫＤＣ２０４は、また、発行する証明書のタイプも決定する。どんなタイプのＫＤＣ２０４証明書が発行されるのかは、クライアントにとって無関係である。何故なら、クライアントは自分自身の証明書を分析する必要がないからである。クライアントに証明書が発行された場合には、クライアントは、それを半透明なブロブとして処理しなければならない。クライアントは、それ自身の証明書を記憶すること、およびＡＳ＿ＲＥＱメッセージ内にそれを含めることに対してだけ責任を有する。
ＣＬＩＥＮＴ＿ＥＮＲＯＬＬ＿ＲＥＰメッセージ
このメッセージは、ＣＬＩＥＮＴ＿ＥＮＲＯＬＬ＿ＲＥＱへの応答メッセージである。このメッセージは、クライアントの公開鍵が更新されたことを肯定応答するか、公開鍵に対する新しいクライアントの証明書を指定するか、またはこれら両方を行う。このメッセージを送信する前にＫＤＣ２０４がとった行動は、その構成方針に基づいて行われたものである。このメッセージの認証は、要求の認証のために使用した同じ提供鍵を使用して、鍵によるチェックサムにより行う。図示していないが、通常の当業者であれば、本発明の精神および範囲に入る種々の他のメッセージも使用できることを理解することができるだろう。
媒体ストリーム・鍵管理
媒体ストリーム・鍵管理は、Ｔｉｃｋｅｔ Ｃｈａｌｌｅｎｇｅ、ＫＥＹ＿ＲＥＱ、Ｋ
ＥＹ＿ＲＥＰおよびセキュリティ確立メッセージで使用したＤＯＩ＿ＩＤ属性により識別されるＩＰＲＭ特有のプロトコルである。

そうしたい場合には、これらのメッセージは、ＤＯＩオブジェクトに対応する第三者認証符号を運ぶことができる。この認証符号は、ＤＯＩオブジェクトのオリジネータが鍵管理メッセージの送信側でなく、ある種の他の第三者である場合に役に立つ。媒体ストリーム・セキュリティの場合には、このような認証符号が必要になり、一方、他の場合には必要ではない。

ＩＰＲＭ ＤＯＩオブジェクトは、セッション権利オブジェクトまたはセッションＩＤ（二地点間の機密保護セッションを一意に識別する乱数）を含む。セッションＩＤを生成するには、強力な乱数発生器は必要ではない（任意のソフトウェアをベースとする疑似乱数発生器で十分である）。終点の中の１つが、セッションＩＤを生成した場合には、そのセッションＩＤは必ずそのホストに対して一意なものである。セッションＩＤの衝突が検出された場合には、衝突が発生した終点は、アプリケーション・エラー・コードを返送することができ、このセッションＩＤを生成した終点は、他の乱数を発生し、もう一度試みる。通常、ＤＯＩオブジェクトは、ＫＥＹ＿ＲＥＱまたはＫＥＹ＿ＲＥＰメッセージ内で暗号化されることに留意されたい。
媒体ストリームＤＯＩオブジェクト
媒体ストリーム・鍵管理で使用することができるいくつかのタイプのＩＰＲＭ ＤＯＩオブジェクトがある。

・セッション権利
・セッションＩＤ
セッション権利ＤＯＩオブジェクト
セッション権利は、通常、使用者２１６が、プログラムを見るために、キャッシング・サーバから機密保護セッションを要求したいと考えた場合に、ＫＥＹ＿ＲＥＱメッセージにより送信される。セッション権利は、コンテンツ・プロバイダ２０２から使用者２１６により入手される。使用者２１６（ビューア・ソフトウェア）は、次に、ＫＥＹ＿ＲＥＱメッセージ内にこのＤＯＩオブジェクトを内蔵させる。上記ＫＥＹ＿ＲＥＱメッセージは、後で適当なキャッシング・サーバにより確認される。セッション権利は、キャッシング・サーバが、セッション権利およびこの認証符号の両方を生成したコンテンツ・プロバイダ２０２であることを確認することができるように、第三者認証符号により行われる。

セッション権利は、特定のコンテンツ・ストリーミングまたは配布セッションおよびこれらのセッション権利の期限切れ時間を識別するセッションＩＤを含む。セッション権利は、また、例えば、下記のものを含むユーザの選択を含む。

・使用者２１６が選択した購入オプション。例えば、購入オプションは、コンテンツが無料であること、加入ベースで選択したこと、ペイパービュウをベースとして選択したこと、またはペイバイタイムをベースとして選択したことを表示することができる（価格は、見たコンテンツの長さにより異なる）。

・コンテンツの購入価格
同じセッション権利は、また下記のようなコンテンツ・ルールを含むことができる。
・特定の国に対するこのコンテンツの配布の制限
・特定の地理的エリアに対するこのコンテンツの配布の制限
・このコンテンツが加入のために提供されるサービスＩＤのリスト
一般的に、これらのルールおよび選択は、自由裁量による複雑なものであってもよいし、ＴＬＶ（タイプ−長さ−値）コード化、ＸＭＬ等を含むいくつかの形式で表現すること
ができる。
セッションＩＤ ＤＯＩオブジェクト
セッションＩＤ ＤＯＩオブジェクトは、ＫＥＹ＿ＲＥＱおよびＫＥＹ＿ＲＥＰメッセージの両方で使用される。キャッシング・サーバが、もう１つのキャッシング・サーバからコンテンツを要求した場合には、セッションＩＤ ＤＯＩオブジェクトは、要求しているキャッシング・サーバから送信されたＫＥＹ＿ＲＥＱメッセージに内蔵される。セッションＩＤ ＤＯＩオブジェクトは、キャッシング・サーバが、コンテンツ・プロバイダ２０２からコンテンツを要求した場合に、ＫＥＹ＿ＲＥＰメッセージの一部として送信される。この場合、キャッシング・サーバは、ＴＫＴ＿ＣＨＡＬＬＥＮＧＥメッセージとの鍵管理交換をスタートし、キャッシング・サーバがＫＥＹ＿ＲＥＰメッセージを送信するまで、セッションＩＤを指定することはできない。このタイプのＤＯＩオブジェクトは、第三者により生成されないので、追加の第三者認証符号を必要としない。
鍵の導出
この鍵導出手順は、ＩＰＲＭ ＤＯＩ＿ＩＤ値に特有なもので、媒体ストリームおよび同じＤＯＩ＿ＩＤに分類される他のターゲット・プロトコルに適用することができる。ターゲット・アプリケーション・シークレット（ＴＡＳ）（セッション鍵と副鍵との連鎖）が鍵管理により確立した後で、ＴＡＳは指定順序で鍵の下記の組を導出するために使用される。クライアントは下記のものを導出する。

出力ＥＫ、出力メッセージのためのコンテンツ暗号鍵。長さは選択した暗号により異なる。
出力Ｋ_ＭＡＣ、出力メッセージの認証のためにＭＡＣの生成中に使用するＭＡＣ（メッセージ認証コード）鍵。鍵の長さは、選択したメッセージ認証アルゴリズムにより異なる。

入力ＥＫ、入力メッセージのためのコンテンツ暗号鍵
入力Ｋ_ＭＡＣ、入力メッセージの認証のために使用するＭＡＣ鍵
アプリケーション・サーバは、下記のものを導出する。

入力ＥＫ
入力Ｋ_ＭＡＣ
出力ＥＫ
出力Ｋ_ＭＡＣ
クライアントおよびサーバのところでの入力および出力鍵の導出順序が逆であることに留意されたい。何故なら、一方の側で出力トラヒックを暗号化するために使用した同じ鍵が、他方の側で入力トラヒックを解読するために使用されるからである。同様に、一方の側で出力メッセージ用のＭＡＣを生成するために使用したＭＡＣ鍵が、他方の側で入力メッセージ上のＭＡＣ値を確認するために使用される。

また、各プロトコルに対して、すべての鍵が使用されるわけではないことに留意されたい。例えば、ＲＴＰは、ＥＫ、暗号鍵だけをトラヒックの一方向だけで使用する。何故なら、ＩＰＲＭ内においては、二方向ＲＴＰセッションは存在しないからである（クライアントは、ストリーミング・サーバにＲＴＰパケットを返送しない）。この鍵導出機能は一方向機能である。導出した鍵が１つである場合には、ＴＡＳ（ターゲット・アプリケーション・シークレット）の値を決定することはできない。

今まで、本発明の例示としての特定の実施形態を詳細に説明してきたが、本発明は他の方法でも実施することができる。それ故、上記説明は、等価物のその完全な範囲と一緒に添付の特許請求の範囲に記載してある本発明の範囲を制限するものではない。

通信ネットワークを通るコンテンツのストリーミングを容易にするためのネットワークのブロック図。 本発明のある例示としての実施形態による、図１のネットワークに鍵管理およびセキュリティを適用するためのＥＳＢｒｏｋｅｒ（商標）プロトコルを内蔵しているＩＰＲＭ（インターネット・プロトコル権利管理）システムのブロック図。 本発明の例示としての実施形態による、鍵管理が使用者（クライアント）によりキャッシング・サーバ（サーバ）に対してスタートした場合の、セキュリティおよび鍵管理プロトコルのハイ・レベルの流れ図。 本発明の例示としての実施形態による、鍵管理がキャッシング・サーバ（サーバ）からコンテンツ・プロバイダ（クライアント）に対してスタートした場合の、セキュリティおよび鍵管理プロトコルのハイ・レベルの流れ図。 本発明の例示としての実施形態による、使用者によるコンテンツの最初の登録および受信を示すブロック図。

Claims (23)

1. コンテンツを、許可された使用者に機密保護状態で配信するための権利管理アーキテクチャであって、
   コンテンツ・プロバイダと；
   同コンテンツ・プロバイダからコンテンツを要求するための使用者システムと；
   を備え、
   同コンテンツ・プロバイダが、前記コンテンツにアクセスするためのセッション権利オブジェクトを生成し；
   前記使用者システムに、前記コンテンツにアクセスするための許可データを提供するためのＫＤＣ（鍵配布センター）と；
   前記セッション権利オブジェクト内の情報を前記許可データと比較するためのキャッシング・サーバと；
   を備え、
   前記情報が前記許可データと一致した場合、前記キャッシング・サーバが、使用者システムに要求したコンテンツを転送する、アーキテクチャ。
2. 前記使用者システムが、要求したコンテンツを受信するために前記キャッシング・サーバに転送される請求項１に記載のアーキテクチャ。
3. 前記キャッシング・サーバおよび前記コンテンツ・プロバイダが、識別された１つのシステムに結合される請求項１に記載のアーキテクチャ。
4. 前記キャッシング・サーバが、暗号化したコンテンツを機密保護状態で転送するために、リアルタイム・ストリーミングを使用する請求項１に記載のアーキテクチャ。
5. 前記要求したコンテンツが、前記使用者システムに転送するために暗号化される請求項１に記載のアーキテクチャ。
6. 前記キャッシング・サーバおよび前記使用者システムが、前記要求したコンテンツの転送をサポートするために制御メッセージを交換する請求項４に記載のアーキテクチャ。
7. 前記制御メッセージが暗号化され、認証される請求項６に記載のアーキテクチャ。
8. 前記キャッシング・サーバが、暗号化されたコンテンツを記憶するための１つまたはそれ以上のキャッシュ・ディスクを備える請求項５に記載のアーキテクチャ。
9. 前記ＫＤＣが暗号鍵を配布し、該ＫＤＣが暗号鍵を配布するために、対称アルゴリズムと公開アルゴリズムの混合物を使用する請求項５に記載のアーキテクチャ。
10. さらに、前記キャッシング・サーバと前記使用者システムとの間の鍵を確立するための鍵管理プロトコルを備える請求項５に記載のアーキテクチャ。
11. 前記鍵管理プロトコルが、
    前記キャッシング・サーバからセッション鍵を要求するための鍵要求メッセージと、
    それに応じて、前記使用者システムに該セッション鍵を提供するための鍵応答メッセージとを備える請求項１０に記載のアーキテクチャ。
12. 前記セッション権利オブジェクトおよび前記許可データが前記鍵要求メッセージに内蔵されていて、
    前記キャッシング・サーバが、前記セッション権利オブジェクト内の情報を前記許可データと比較し、
    前記情報が前記許可データと一致する場合には、前記セッション鍵が前記使用者システムに提供される請求項１１に記載のアーキテクチャ。
13. 前記コンテンツ・プロバイダが、前記コンテンツに対するユーザのアクセス特権を指定する前記セッション権利オブジェクトを生成する請求項１２に記載のアーキテクチャ。
14. キャッシング・サーバから要求があった場合に、機密保護状態でコンテンツを配信するための権利管理方法であって、
    前記キャッシング・サーバに通信できるように結合されているコンテンツ・プロバイダを供給する工程と、
    鍵管理プロトコルを供給するステップと、を含み、
    同鍵管理プロトコルを供給する工程が、
    前記キャッシング・サーバから前記コンテンツ・プロバイダに鍵管理をスタートするためのチケット・チャレンジ・メッセージを転送する工程と、
    それに応じて、前記コンテンツ・プロバイダから前記キャッシング・サーバに鍵要求メッセージを送信する工程と、
    それに応じて、前記キャッシング・サーバから前記コンテンツ・プロバイダに鍵応答メッセージを送信する工程と、
    それに応じて、前記コンテンツ・プロバイダから前記キャッシング・サーバへ、セキュリティ確立メッセージを送信する工程と、
    それに応じて、前記コンテンツ・プロバイダから前記キャッシング・サーバへ、セキュリティ確立メッセージを送信する工程と、
    前記コンテンツ・プロバイダから前記キャッシング・サーバに、機密保護状態でコンテンツを配信するための一組の鍵を確立する工程と、を含む方法。
15. さらに、
    前記キャッシング・サーバからコンテンツをストリーミングするための使用者システムを供給する工程を含む請求項１４に記載の方法。
16. さらに、前記キャッシング・サーバと前記コンテンツ・プロバイダとの間に信託を確立するための鍵配布センターを供給する工程を含む請求項１４に記載の方法。
17. キャッシング・サーバのところで、機密保護状態でコンテンツを予め位置させるための権利管理方法であって、
    前記キャッシング・サーバに通信できるように結合されているコンテンツ・プロバイダを供給する工程と、
    鍵管理プロトコルを供給するステップと、を含み、同鍵管理プロトコルを供給する工程が、
    前記コンテンツ・プロバイダから前記キャッシング・サーバに、鍵管理をスタートするための鍵要求メッセージを転送する工程と、
    それに応じて、前記キャッシング・サーバから前記コンテンツ・プロバイダに、鍵応答メッセージを送信する工程と、
    前記コンテンツ・プロバイダから前記キャッシング・サーバに機密保護状態でコンテンツを配信するための一組の鍵を確立する工程と、を含む方法。
18. さらに、前記キャッシング・サーバからコンテンツをストリーミングするための使用者システムを供給するステップを含む請求項１７に記載の方法。
19. さらに、前記キャッシング・サーバと前記コンテンツ・プロバイダとの間に信託を確立するための鍵配布センターを供給するステップを含む請求項１７に記載の方法。
20. 許可されたユーザが計算ネットワーク内のキャッシング・サーバからコンテンツをストリーミングし得る認証システムであって、
    ユーザがアクセスするための前記キャッシング・サーバに前記コンテンツを供給するためのコンテンツ・プロバイダと、
    前記コンテンツ・プロバイダから前記キャッシング・サーバへのアクセスの第１の要求を受信し、認証が行われている場合には、前記コンテンツ・プロバイダが、前記キャッシング・サーバに前記コンテンツを配信する鍵配布センターと、を備え、
    同鍵配布センターが、ユーザから、前記キャッシング・サーバへのアクセスの第２の要求を受信し、認証が行われている場合には、ユーザが前記キャッシング・サーバから前記コンテンツをストリーミングすることができる認証システム。
21. 前記第２の要求が、前記キャッシング・サーバにアクセスするためのキャッシング・サーバ・チケットに対するものである請求項２０に記載の認証システム。
22. 通信ネットワークの構成要素間でデータの転送を機密保護状態で行うためのプロトコルであって、
    ａ）データベースを有する中央サーバを供給する工程と、
    ｂ）コンテンツ・プロバイダから前記中央サーバにコンテンツメタデータを発行する工程と、
    ｃ）前記中央サーバに通信できるように結合されている課金中央サーバを供給する工程と、
    ｄ）キャッシング・サーバから前記課金中央サーバに課金情報を報告する工程と、
    ｅ）前記中央サーバに結合している提供データベースを供給する工程と、
    ｆ）前記提供データベースを使用者情報により更新する工程と、
    ｇ）工程ｂ）、工程ｄ）および工程ｆ）の任意の１つまたはそれ以上の工程中に、データを機密保護状態で転送するために、鍵管理プロトコルを使用する工程と、
    を含むプロトコル。
23. 前記鍵管理プロトコルが、
    セッション鍵を要求するための鍵要求メッセージを転送する工程と、
    セッション鍵を供給するための鍵応答メッセージを受信する工程と、を含む請求項２２に記載のプロトコル。

Images