JP4722478B2 - 関連するストリーミングプロトコル群に対するセキュリティパラメータの統合 - Google Patents

Description

本発明は概してデータ通信分野に関連し、更に特定するとネットワークにおける権利管理、および通信データの保護に関連する。

インターネットプロトコル（ＩＰ）ネットワーク上において、マルチメディアストリーミングコンテンツをストリーミング配信する関心が高まるにつれて、鍵管理システムに対する必要性も問われている。そのようなストリーミング配信システムの一つが、カリフォルニア州、サンディエゴ市にあるエアロキャスト株式会社（Ａｅｒｏｃａｓｔ、Ｉｎｃ．）によって開発されたエアロキャストネットワーク（Ａｅｒｏｃａｓｔ Ｎｅｔｗｏｒｋ）（商標）である。図１で説明しているように、既存層１のエアロキャストネットワークでは、コンテンツの配信を促進するが、ネットワークに対するセキュリティ、および鍵管理を欠いている。

図１は通信ネットワーク上でコンテンツのストリーミングを促進するための、ネットワーク１００（エアロキャストによる）のブロック図である。
数ある構成要素の中において、ネットワーク１００は顧客１１６向けのコンテンツを生成するコンテンツプロバイダ１０２、コンテンツがストリーミングされるインターネット１１４、およびコンテンツプロバイダ１０２がそのコンテンツを公開する中央サーバ１０４を含む。中央サーバ１０４はコンテンツ情報を保存するためのデータベース１０８、およびデータベース１０８を検索する検索エンジン１１０を含む。ネットワーク１００は更に、プロビジョニングセンター１０６、およびキャッシュサーバ１１２，１１３，および１１５を備える。

ネットワークの動作中において、顧客１１６はコンテンツプロバイダ１０２のコンテンツにアクセスしたい場合、顧客に最も近いキャッシュサーバ、この場合キャッシュサーバ１１５、がそのコンテンツをストリーミングする。キャッシュサーバのない従来のシステムでは、顧客が上記のようなコンテンツストリームを望む場合には、コンテンツプロバイダ１０２から直接コンテンツを得ることになる。この場合、コンテンツの質が落ちるだけでなく、不十分な帯域幅によるコンテンツの遅延も招く可能性がある。キャッシュサーバを使用することによって、ネットワーク１００はコンテンツプロバイダ２０２からデジタルコンテンツを直接ストリーミングすることに伴う弊害を避けることができる。キャッシュサーバ１１２，１１３，および１１５は例えば、ローカルのＤＳＬ（デジタル加入者回線）プロバイダであってもよい。

ネットワーク１００が提供する利益はこれだけではない。コンテンツを検索する際、顧客１１６はインターネット１１４上のあらゆるデータベースを検索する必要はない。ネットワーク１００上のコンテンツプロバイダ（コンテンツプロバイダ１０２を含む）は、コンテンツの解説を単一の中央データベース１０８に全て公開しているからである。例えばストリーミングビデオコンテンツの場合、その説明には映画の名前、俳優等が含まれるだろう。このようにして、コンテンツを要求する際、顧客１１６は検索エンジンを使用してデータベース１０８を検索する。そのコンテンツが見つかると、データベース１０８は目的のストリーミングコンテンツを有するコンテンツプロバイダ２０２へのリンクを提供する。顧客１１６はその後、コンテンツプロバイダ１０２にアクセスして、より詳細な情報を得る。前記詳細な情報には、価格情報等が含まれる。

顧客１１６が、最も近いキャッシュサーバのリストをコンテンツプロバイダ１０２に提供する機構を説明する。顧客１１６の要求に応答して、コンテンツプロバイダ１０２はコンテンツをストリーミングするために、顧客１１６に最も近い適切なキャッシュサーバを選択する。しかしながら今日のエアロキャストネットワークでは、ネットワーク１００はコンテンツを平文でストリーミングすることに注目すべきである。不都合なことにコンテンツは保護されていないため、許可されていない顧客に奪われ、コンテンツプロバイダ、および顧客の双方に結果として重大な損失を招く恐れがある。これらの不都合のうちいくつかは、本願と本願の出願により所有される同時出願の関連特許出願によって解決されたものもあり、前記関連特許出願はその出願全体を説明するように、本明細書において引用し援用される。

通常、ストリーミングコンテンツを配信、管理、および制御するために、いくつかの異なるプロトコルを用いる。例えば、リアルタイムデータをストリーミングするためのプロトコル群として、ＲＴＰ（リアルタイムプロトコル）、ＲＴＣＰ（リアルタイム制御プロトコル）、およびＲＴＳＰ（リアルタイムストリーミングプロトコル）を用いる。ＲＴＰはＲＦＣ（コメント要求）１８８９で明記されており、ＵＤＰ（ユーザデータグラムプロトコル）上で動作する。

様々な機能の中でＲＴＰは、ポイントツーポイント、またはマルチキャストサービス上の音声や映像等のコンテンツをリアルタイムに伝送するエンドツーエンドの転送機能を提供する。ＲＴＣＰ（リアルタイムプロトコル制御プロトコル）は、ＲＴＰと組み合わせて使用するプロトコルで、ＱｏＳ（通信サービス品質）を監視することと、メディアストリーミングセッションの通信状況を伝えることとを提供し、送信側がその送信のタイミングを調整するために使用される。加えて、少なくともポイントツーポイントの場合において、（おそらくはマルチキャストの場合においても）、ＲＴＰ、およびＲＴＣＰはＲＴＳＰ（リアルタイムセッションプロトコル）を伴い、前記ＲＴＳＰは特定のコンテンツの要求、コンテンツの解説の提供、ポイントツーポイント接続に対するメディアストリームの中断、および再スタート等に使用される。

ＲＴＰパケットに対する保護が提供されていながらも、従来のデジタル著作権管理システムは、ＲＴＳＰ、およびＲＴＣＰパケットに対する保護をほとんど、あるいは全く提供していない。そのようなシステムでは、不都合なことにＲＴＣＰおよびＲＴＳＰメッセージの完全性を欠いているために、更なるサービス妨害攻撃に対して無防備であり、ユーザのプライバシー（例えばユーザのコンテンツ鑑賞パターン）を提供することができないであろう。更に、メディアストリーミング（例えば、ＲＴＰ／ＲＴＣＰ／ＲＴＳＰ）に関連する各プロトコルに必要な鍵を全て提供する、各ストリーミングセッションに対する単一鍵のネゴシエーションもない。

従って、上述した一つ以上の問題を解決する必要があり、本発明はその必要性を満たすものである。

第一態様によると、本発明は関連プロトコル群に対するセキュリティパラメータセットを生成するための、単一鍵管理システムである。ＲＴＳＰ（リアルタイムストリーミングプロトコル）、ＲＴＰ（リアルタイムプロトコル）、およびＲＴＣＰ（リアルタイム制御プロトコル）メッセージ等のプロトコルの安全が確保される。これらのプロトコルはサーバからクライアントへのリアルタイムデータのストリーミングを許可するものであり、セキュリティパラメータによってその安全を確保されている。セキュリティパラメータはＭ
ＡＣ（メッセージ認証コード）、コンテンツ暗号化／復号化鍵等であり得る。

一態様として、例えばセキュリティパラメータはアウトバウンドメッセージを暗号化する暗号化鍵、およびアウトバウンドメッセージを認証する認証鍵を含む。セキュリティパラメータはインバウンドメッセージに対する復号、および認証鍵を含んでもよい。都合の良いことにストリーミングセッションに必要とされるセキュリティパラメータは、一度に全て生成される。更に全ての関連プロトコルをまとめるために、識別子が利用される。

本発明における別の態様に従って、リアルタイムデータストリームを安全に転送する方法を教示する。本方法は、ストリーミングセッションの安全を確保する、二つ以上のセキュリティパラメータを確立する工程を含む。その後、前記セキュリティパラメータに関連するセッション識別子を確立する。このような方法により、ストリーミングセッションに関連するパラメータは全て、容易に識別することができる。

リアルタイムデータはＲＳＴＰ、ＲＴＰ、およびＲＴＣＰを任意の順に交換することで安全に転送される。例えば、クライアントは、リアルタイムデータストリーミングを要求するＲＳＴＰメッセージを、サーバに送信する。サーバはその応答として、リアルタイムデータストリームをストリーミングするための、ＲＴＰ、およびＲＴＣＰポートのリストを含むＲＴＳＰメッセージを送信する。これらのメッセージはセキュリティパラメータによって、その安全を確保されている。注意すべきは、前記セキュリティパラメータは、セッション識別子を使用して識別可能なことである。

本発明における別の態様に従って、ＭＡＣ鍵、および暗号化鍵によるリアルタイムデータストリームの安全を確保する方法を開示する。該方法は、多数の工程を含む。第一に、ＭＡＣ鍵で認証されたＲＴＳＰメッセージが、クライアントとサーバとの間で交換される。更に、サーバはリアルタイムデータをストリーミングするために、クライアントにＲＴＰメッセージを送信する。ＲＴＰメッセージは同様に暗号化鍵で暗号化され、ＭＡＣ鍵で認証される。更に安全なリアルタイムデータのストリーミングを容易にするために、ＲＴＣＰメッセージが交換される。これらのＲＴＣＰメッセージは暗号化鍵で暗号化され、ＭＡＣ鍵で認証される。このような方法で、リアルタイムデータはサーバからクライアントへ安全にストリーミングされる。注意すべきは、メッセージは暗号化、認証、またはそれらの双方が可能なことである。

本発明の利点として、便利であることと、これらのプロトコルを単一セッションに関連付ける、共通のセッション識別子を伴う単一のセキュリティパラメータセットを有することで、複雑であるリアルタイムデータの安全なストリーミングを単純化が可能なことである。

本明細書、および添付の図面を参照することによって、本願における本発明の本質、および利点が更に理解されよう。本発明において言及する単語は、「工程、および機能」の意味として解釈されるべきではなく、かつ本発明を実施するための特定の順序に言及するものでもない。本発明の更なる形状、および効能は、本発明における様々な実施形態の構造、および操作と同様に、添付の図面と共に以下において詳細に説明されるものである。図面において、同一の参照符号は同様の、または機能的に同様の要素を示すものとする。

第一態様に従って簡単に説明すると、本発明はセキュリティパラメータセットを生成するための、単一の鍵管理システムである。この単一セキュリティパラメータセットは、関連するプロトコル群の安全を確保するために使用される。ＲＴＳＰ（リアルタイムストリーミングプロトコル）、ＲＴＰ（リアルタイムプロトコル）、およびＲＴＣＰ（リアルタ
イム制御プロトコル）メッセージ等のプロトコルは、サーバからクライアントにリアルタイムデータをストリーミングする間に、その安全が確保されている。

クライアントは、リアルタイムデータを有するサーバとの通信を開始する。最初に、ストリーミングセッションの安全を確保するためのセキュリティパラメータが導出される。その後、前記セキュリティパラメータに関連するセッション識別子が確立される。続いて、クライアントはＲＴＳＰメッセージを使用して、サーバにリアルタイムデータストリームを要求する。サーバはＲＴＳＰメッセージを受信すると、リアルタイムデータパケットを含むＲＴＰメッセージをストリーミングするためのストリーミングセッションを確立する。前記ＲＴＰメッセージはセキュリティパラメータによって安全を確保されている。前記ＲＴＳＰメッセージも同様に安全を確保されている。一つ以上のＲＴＣＰ、ＲＴＰ、およびＲＴＳＰメッセージが任意の順に交換され、各メッセージはセキュリティパラメータで安全を確保されており、前記セキュリティパラメータはセッション識別子によって識別可能である。このようにして、これらのプロトコルはサーバからクライアントへ安全にデータをストリーミングするために、暗号化、および認証によって安全を確保されている。

本発明はＲＴＰ、ＴＣＰ、およびＲＴＳＰに関連して説明されているが、当業者は本発明の精神において他のタイプのプロトコルにも適用可能であることを理解するであろう。例えば、本発明はリアルネットワークのプロトコルに適用可能であろう。

図２は本発明の典型的な実施形態における、図１のネットワーク１００に鍵管理、およびセキュリティを適用するためのＥＳＢｒｏｋｅｒ（商標）プロトコルを組み合わせたＩＰＲＭ（インターネットプロトコル権利管理）システム２００のブロック図である。

システムを構成する様々な要素のうち、ＩＰＲＭシステム２００はコンテンツプロバイダ２０２、顧客２１６、インターネット２１４、プロビジョニングセンター２０６、コンテンツを解説するデータベース２０８、および検索エンジン２１０の両方を含む中央サーバ２０５、キャッシュサーバ２１２，２１３，および２１５を含み、上記構成要素は全て、図１に示す構成要素と同様の方法によって機能する。ＩＰＲＭシステム２００は上記に加えて、顧客２１６にＴＧＴ（チケット交付チケット）を発行するＡＳ（認証サーバ）２０７、特定のサーバにアクセスするためにサーバにチケットを提供するＴＧＳ（チケット交付サーバ）２０９を含むＫＤＣ（鍵配布センター）２０４、プロビジョニングサーバ２２０、および請求センター２１１を備える。ＫＤＣ２０４、請求センター２１１、プロビジョニングセンター２２０、中央サーバ２０５は、ＩＰＲＭシステム２００内においてサービスプロビジョニングを実現するために、全て中央ユニット２１８内に配置されている。

ＩＰＲＭシステム２００は更に、コンテンツプロバイダ２０２に対する権利管理を行うＩＰＲＭエージェント２０２Ａ、ストリーミングされるコンテンツに対するユーザの選択、およびそのコンテンツにアクセスする規則を定義するセッション権オブジェクト２０２Ｂ、キャッシュサーバ２１２に対する権利管理を行うＩＰＲＭエージェント２１２Ａ、キャッシュサーバ２１３に対する権利管理を行うＩＰＲＭエージェント２１３Ａ、キャッシュサーバ２１５に対する権利管理を行うＩＰＲＭエージェント２１５Ａ、顧客２１６に対する権利管理を行うＩＰＲＭエージェント２１６Ａ、および目的のコンテンツを受信するために顧客２１６内にいる、視聴者（図示せず）をそれぞれ含む。図面には表されていないが、上述の構成要素はそれぞれ、関連する構成要素の内部に配置することも可能である。例えば、ＩＰＲＭエージェント２０２Ａは図面では外部に表されているが、コンテンツプロバイダ２０２内に配置することも可能である。

説明したように、ＩＰＲＭシステム２００は通常、キャッシュサーバ２１２，２１３，
および２１５を使用して、安全な方法による顧客へのコンテンツのストリーミングを容易にするために機能している。コンテンツプロバイダ２０２は、コンテンツを一度だけ提供し、その後そのコンテンツはキャッシュサーバ間で移動され得る。キャッシュサーバ間でコンテンツを移動させる理由は、そのコンテンツをできるだけＩＲＰＭシステム２００の端の近くに移動させるためである。これによってストリーミングの性能が改善し、より小さなコンテンツプロバイダはメディアストリームのために高価なハードウェアを購入する必要がなく、そのコンテンツを販売することが可能になる。また、キャッシュサーバのみが、ＩＰマルチキャスト（ネットワーク上における一人の送信者と複数の受信者との間の通信）を導入すればよいことになる。現在の技術において、インターネット上でＩＰマルチキャストを有するよりも、ローカルアクセスネットワークに限定したＩＰマルチキャストを備える方がより簡単である。

第一の実施形態における本発明は、ＫＤＣ２０４，ＩＰＲＭエージェント２０２Ａ，２１２Ａ，２１３Ａ，２１５Ａ，および２１６Ａを経由してＩＰＲＭシステム２００にセキュリティを提供する。ＩＰＲＭエージェントはＫＤＣ２０４およびプロビジョニングセンター２０６と併せて、ＩＰＲＭシステム２００の全ての態様に認証、プライバシー、完全性、アクセス制御、および否認防止ツールを提供する。例えば、顧客はコンテンツのストリーミングが利用できる前に、登録手続きを要求される。この顧客の登録は、ＩＰＲＭシステム２００によって安全に提供されている。従って、登録手続き中は、誰も、顧客２１６とＫＤＣ２０４との間のメッセージを傍受することによって、顧客２１６の身元を複製することはできない。ＫＤＣ２０４は信頼のおける構成要素であり、対称／非対称アルゴリズムを組み合わせて使用することでネットワーク構成要素に鍵配布を提供する。

ＫＤＣ２０４およびＩＰＲＭの構成要素は、顧客２１６に与えられる有限の信頼性を有する、純粋にソフトウェアのみによる保護であるか、またはハードウェアセキュリティモジュールによる保護であるが、その場合には、高レベルのセキュリティを要求する著作権所有者から高品質コンテンツに対する権利を取得しなければならないかもしれない。或いはソフトウェア、およびハードウェアの両方による保護の可能性もある。ＩＰＲＭは、何百万もの顧客に対応する高い拡張性を有する認証鍵管理プロトコルを使用する。前記鍵管理プロトコルは電子セキュリティブローカー（ＥＳＢｒｏｋｅｒ（商標））と呼ばれ、カリフォルニア州サンディエゴ市にあるモトローラ社の製品であり、本明細書を通して引用されるだろう。

ＥＳＢｒｏｋｅｒ（商標）プロトコルは部分的にケルベロスの構造に基づいており、クライアントが個々のアプリケーションサーバとやりとりするのと同様に、クライアントによる集中鍵配布センター（ＫＤＣ２０４）との相互作用、並びに個々のアプリケーションサーバとの相互作用から構成される。ＫＤＣクライアントはＫＤＣに要求を送信することができる、任意のホストである。ＩＰＲＭシステム内において、ＫＤＣクライアントは顧客、キャッシュサーバ、および他のＩＰＲＭシステム構成要素を含む。アプリケーションサーバはＫＤＣに登録された任意のサーバであり、クライアントはそのアプリケーションサーバに対するサービスチケットを要求することがある（例えば、キャッシュサーバ、請求センター等）。同一のホストが同時にＫＤＣクライアント、およびアプリケーションサーバの両方になる場合もある。ＩＰＲＭシステム２００では、プロトコルは一連のメッセージを使用して、システムのクライアントサーバ間におけるインターフェースの鍵管理を実現する。この鍵管理プロトコルは、安全なセッションを確立すつために通常使用されるものであり、ＩＰＲＭシステムに限定されたプロトコルではない。以下の表１に掲載されてあるこれらのメッセージは、ＩＰＲＭプロトコルメッセージと題するセクションにおいて説明されている。

動作中において、クライアントサーバ間の鍵管理プロセスは二段階に分類される：（１）クライアントはＫＤＣ２０４と通信してサーバにアクセスするためのチケットを要求する一般段階、および（２）クライアントがサーバチケットを使用して、サーバへのＫＥＹ−ＲＥＱ（鍵要求）メッセージを作成する特殊段階である。特殊段階において、ＤＯＩ（
解釈ドメイン）オブジェクトは、通常のＥＳＢｒｏｋｅｒ（商標）鍵管理プロトコルのある特定のアプリケーションに特化した（例えばＩＰＲＭシステムに特化した）情報を含む。例えば、顧客２１６（クライアント）とキャッシュサーバ２１５（サーバ）との間の鍵管理プロセスにおいて、一般段階では顧客２１６がＫＤＣ２０４からキャッシュサーバ２１５にアクセスするためのサーバチケットの取得を生じる。特殊段階のプロセスにおいては、前記サーバチケットを使用して、キャッシュサーバ２１５にアクセスするためのＫＥＹ＿ＲＥＱメッセージの生成を生じ、ＫＥＹ＿ＲＥＱにはセッション権を含むＤＯＩオブジェクトが含まれている。更に、プロトコルに使用されるメッセージは、鍵管理をクライアントが開始した場合、またはサーバが開始した場合によって変わってくる。サーバが鍵管理を開始した場合、図３を参照することでより明確に示されているように、他のメッセージに加えてＴＫＴ＿ＣＨＡＬＬＥＮＧＥ（チケットチャレンジ）メッセージが使用される。

図３は本発明の典型的な実施形態に基づく、顧客２１６（クライアント）による鍵管理開始時におけるキャッシュサーバ２１５（サーバ）へのセキュリティ、および鍵管理プロトコルの高レベル流れ図を示す。言うまでもなく、顧客２１６、キャッシュサーバ２１５は両方ともＫＤＣ２０４に登録されていると仮定しており、ＫＤＣ２０４は信頼のおける認証サーバとして動作し、両ノードの身元を確認する。

図に示すように、安全な方法によってキャッシュサーバからコンテンツのストリーミングを望む顧客２１６は、鍵管理プロセスを開始する。鍵管理プロセスはＡＳ＿ＲＥＱメッセージをＫＤＣ２０４に送信し、ＴＧＳサーバ２０９のためのＴＧＴ（チケット交付チケット）を取得することによって行われる。ＡＳ＿ＲＥＱメッセージには顧客２１６の身元情報、ＫＤＣ２０４の身元情報を含み、より詳しく言うとＫＤＣのレルム、または管理ドメイン、およびＡＳ＿ＲＥＱメッセージを応答に結び付けるノンスを含む。また、顧客２１６にサポートされている対称暗号化アルゴリズムのリストを含むこともある。

図に示すように、ＫＤＣ２０４はＡＳ＿ＲＥＱメッセージに応答して、ＴＧＴ要求を認証する。ＫＤＣ２０４は、ローカルのデータベースを調査して顧客２１６の身元を確認後、ＴＧＴを含むＡＳ＿ＲＥＰメッセージとして応答する。注目すべきは、ＴＧＴの秘密部分は、ＫＤＣのみに知られているＫＤＣのサービス鍵によって暗号化されている。同一のＫＤＣのサービス鍵は、鍵付ハッシュによってＴＧＴを認証するためにも使用される。顧客２１６はＫＤＣ２０４のサービス鍵を知らないために、チケットを変更したり、チケットの秘密部分を読み込んだりすることはできない。しかしながら顧客２１６は、後にＫＤＣ２０４に対して認証されるためのセッション鍵が必要なことから、鍵共有アルゴリズム（例えば、楕円曲線暗号「Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ」）を使用してセッション鍵の別のコピーが顧客２１６に送られる。

ＴＧＴを受信し、保存すると、顧客２１６はそのネットワーク上のコンテンツのストリーミングを要求する用意が整う。顧客２１６はＴＧＴを含み、キャッシュサーバ２１５へのチケットを要求するＴＧＳ＿ＲＥＱメッセージをＫＤＣ２０４（ＴＧＳサーバ２０９）に送信する。注目すべきは、顧客２１６は上記の動作に加えて、例えば特定のコンテンツプロバイダを定期的にアクセスするような、プロビジョニング動作を実行することもある。また、顧客２１６は好みキャッシュサーバのリストを作成することもできる。

前記ＴＧＳ＿ＲＥＱメッセージの応答として、キャッシュサーバのチケットを有するＴＧＳ＿ＲＥＰメッセージが、ＫＤＣ２０４から顧客へ送信される。他に好みのキャッシュサーバを追加したい場合には、顧客２１６はＴＧＴを使用してＫＤＣ２０４と通信し、好みのキャッシュサーバに対するキャッシュサーバのチケットを取得する。これらのキャッシュサーバのチケットは、後で使用するためにキャッシュされ得る。キャッシュサーバの
チケットをキャッシュしない場合、適当なキャッシュサーバからコンテンツを要求する際にチケットを取得する。

ＫＤＣ２０４は最初に、ある顧客に対してキャッシュサーバチケットを発行する前に、プロビジョニングサーバ２２０にある加入者認証データに問い合せる必要がある。これは、ＫＤＣ２０４、プロビジョニングサーバ２２０間におけるＡＵＴＨ＿ＤＡＴＡ＿ＲＥＱ／ＡＵＴＨ＿ＤＡＴＡ＿ＲＥＰの交換によって実現される。ユーザの認証データはチケットに挿入することができる。キャッシュサーバチケットはＴＧＴと同一のフォーマットであり、キャッシュサーバ２１５に対しての認証に使用するセッション鍵を含む。チケットの秘密部分は、キャッシュサーバのサービス鍵によって暗号化されており、前記サービス鍵はキャッシュサーバ、およびＫＤＣ２０４にのみ知られている。チケットはまたハッシュによって認証され、ハッシュもまた同一のサービス鍵で暗号化されている。顧客２１６はＴＧＴと同様に、本チケットも変更することはできない。顧客２１６はキャッシュサーバに対して自分自身を認証するために、前記キャッシュサーバチケットからセッション鍵を必要とする。

ＡＳ＿ＲＥＱメッセージから始まり、ＴＧＳ＿ＲＥＰメッセージへと続くプロセスは上記において説明した一般段階に一致し、その一般段階において、クライアントはＫＤＣ２０４と通信してサーバにアクセスするためのサーバチケットを取得している。上記プロセスは通常のプロセスであるため、コンテンツプロバイダからキャッシュサーバへコンテンツを配信したり、使用状況を報告したり、請求書を送信したりする等の、他の同様インターフェースに対しても同様のプロセスを使用することができる。更にその結果として、ＩＰＲＭシステムは余計な、または複雑なオプションを必要としない、より安全なシステムになる。また、複雑性を減らすことで、迅速な方法で問題を特定し修正することができる。

顧客２１６はキャッシュサーバチケットを含むＴＧＳ＿ＲＥＰメッセージを受信すると、そのチケットを含むＫＥＹ＿ＲＥＱメッセージをキャッシュサーバ２１５に送信する。ＫＥＹ＿ＲＥＱメッセージはキャッシュサーバチケットに加えて、メッセージのＭＡＣ（メッセージ認証コード）、ＤＯＩ（解釈ドメイン）オブジェクト、およびタイムスタンプを含む。ＤＯＩオブジェクトはこの安全なセッションに関連するアプリケーションに特化した情報を保持するものである。本実施形態におけるＤＯＩオブジェクトは、顧客２１６に対するセッション権の情報を含む。前記セッション権をこのＤＯＩオブジェクトにカプセル化するのは、ＥＳＢｒｏｋｅｒ（商標）プロトコルが通常の鍵管理サービスを提供するのに対して、本セッション権は（キャッシュサーバを伴う）この特定のコンテンツ配信アーキテクチャに特化したものだからである。ＥＳＢｒｏｋｅｒ（商標）は、同様にアプリケーションに特化した情報がＤＯＩオブジェクトにカプセル化された他の安全なセッションタイプにも適用可能である。

キャッシュサーバ２１５が通常のＫＥＹ＿ＲＥＱメッセージを受信すると、キャッシュサーバは特殊ＤＯＩオブジェクトを取り除く。キャッシュサーバ２１５はその後、ストリーミングに対するアプリケーションに特化したコードを調べ、例えば、ＤＯＩオブジェクト、および認証情報を確認する。セッション権がチケット内の認証データと一致した場合、サブセッション鍵を含むＫＥＹ＿ＲＥＰメッセージが顧客２１６へ転送される。サブセッション鍵はチケット内にあるセッション鍵とは違うことに注目されたい。サブセッション鍵は、セキュリティパラメータを得るために使用される。この時点において、顧客２１６、キャッシュサーバ２１５の両ノードはプロトコル鍵を所有し、例えばストリーミングコンテンツである両ノードの最終メッセージの暗号化を開始することができる。認証が失敗した場合には、エラーメッセージが顧客に転送される。注目すべきは、ＫＥＹ＿ＲＥＰメッセージが通常のＤＯＩオブジェクトを含むいくつかの例において、キャッシュサーバ
２１５は顧客２１６に、あるアプリケーションに特化した情報を返す必要があることである。例えばＩＰＲＭシステムにおいて、キャッシュサーバが安全なセッションを要求するために、コンテンツプロバイダにチケットチャレンジを送信すると、その後キャッシュサーバによってＫＥＹ＿ＲＥＰメッセージ内のＤＯＩオブジェクト内にセッションＩＤが提供される。チケットチャレンジは認証されておらず、従ってＤＯＩオブジェクトを含まない。

この段階（ＫＥＹ＿ＲＥＱ／ＫＥＹ＿ＲＥＰ）は、クライアントがサーバチケットを使用してサーバに鍵を要求する、特殊段階に一致する。ＤＯＩオブジェクトは安全を確保するインターフェースによって変化するため、この様相は非一般的である。例えば、コンテンツプロバイダからキャッシュサーバへのコンテンツの配信に関するＤＯＩオブジェクトは、同一のコンテンツをキャッシュサーバから顧客へ配信するために用いられるＤＯＩオブジェクトとは異なる。

図４は本発明の典型的な実施形態に基づく、鍵管理開始時におけるキャッシュサーバ２１５（サーバ）からコンテンツプロバイダ２０２（クライアント）へのセキュリティおよび鍵管理の高レベル流れ図である。

鍵管理は、キャッシュサーバ２１５がコンテンツの要求を受信し、かつキャッシュサーバ２１５が要求されたコンテンツを所有していない場合に開始される。図に示すように、鍵管理はキャッシュサーバ２１５からコンテンツプロバイダ２０２にＴＫＴ＿ＣＨＡＬＬＥＮＧＥ（チケットチャレンジ）メッセージを送信することによって開始される。サーバはＴＫＴ＿ＣＨＡＬＬＥＮＧＥを使用して、クライアントが鍵管理を開始するように導く。

判定ブロック２２４において、コンテンツプロバイダ２０２が以前にキャッシュサーバチケットを取得している場合、コンテンツプロバイダ２０２はそのチケットを含むＫＥＹ＿ＲＥＱメッセージをキャッシュサーバ２１５に転送する。キャッシュサーバ２１５はその応答として、以前に上記において説明したようにＫＥＹ＿ＲＥＰメッセージを送信する。一方、判定ブロック２２４に戻ってコンテンツプロバイダ２０２がキャッシュサーバチケット、およびＴＧＴを所有していない場合、コンテンツプロバイダ２０２はＫＤＣ２０４にＡＳ＿ＲＥＱメッセージを送信し、ＫＤＣ２０４はその返答にＡＳ＿ＲＥＰメッセージを返す。コンテンツプロバイダがそのＴＧＴを所有している場合には、ＡＳ＿ＲＥＱ／ＲＥＰメッセージは省略される。

その後、コンテンツプロバイダ２０２はＫＤＣ２０４にＴＧＳ＿ＲＥＱメッセージを送信し、キャッシュサーバチケットを含むＴＧＳ＿ＲＥＰメッセージを受信する。キャッシュサーバチケットを取得すると、コンテンツプロバイダ２０２はＫＥＹ＿ＥＲＱメッセージを送信するが、この場合、メッセージ内にＤＯＩオブジェクトを含まない。セッションＩＤは、応答メッセージ、要求メッセージ、またはその両方に含まれていてもよい。コンテンツプロバイダ２０２もキャッシュサーバ２１５もどちらも顧客でないため、セッション権は適用されない。一度共有鍵が確立されると、コンテンツプロバイダ２０２によってＳＥＣ＿ＥＳＴＡＢＬＩＳＨＥＤメッセージ（図示せず）がキャッシュサーバ２１５に送信される。キャッシュサーバが鍵管理を開始したことから、ＳＥＣ＿ＥＳＴＡＢＬＩＳＨＥＤメッセージはサーバにセキュリティが確立されたことを知らせる。上記１３行目を参照されたい。ただし、ＳＥＣ＿ＥＳＴＡＢＬＩＳＨＥＤメッセージは図４に加えられている。

有利なことに、クライアントまたはサーバのどちらかが鍵管理を開始することに依存しながらも、同一のメッセージ、即ちＴＫＴ＿ＣＨＡＬＬＥＮＧＥ, ＡＳ＿ＲＥＱ／ＡＳ＿
ＲＥＰ，ＴＧＳ＿ＲＥＱ／ＴＧＳ＿ＲＥＰ，ＫＥＹ＿ＲＥＱ／ＫＥＹ＿ＲＥＰ，ＳＥＣＵＲＩＴＹ＿ＥＳＴＡＢＬＩＳＨＥＤが、様々なプロトコルおよび場合で使用されていることが分かるに違いない。サーバが鍵管理を要求する場合、ＴＫＴ＿ＣＨＡＬＬＥＮＧＥメッセージを含むメッセージを全て使用する。それに対して、クライアントが鍵管理を開始する場合、ＴＫＴ＿ＣＨＡＬＬＥＮＧＥメッセージ以外のメッセージ全てを使用する。注意すべきは、セキュリティ確立メッセージも同様に、通常クライアントが鍵管理を開始する場合には省略されることである。利点として挙げられることは、全てのインターフェースにおいて単一の鍵管理プロトコルを利用していることから、システムが安全であるかを解析するのが、より容易なことである。加えて、ＤＯＩオブジェクトフィールドのみ変更することで、同一の鍵管理によってストリーミングコンテンツ、および非ストリーミングコンテンツの両方の安全を確保することが可能である。

図５は本発明の典型的な実施形態に基づく、顧客２１６による初期登録、およびコンテンツの受信を表すブロック図である。
キャッシュサーバ２１５からコンテンツの受信を希望する新たな顧客２１６は、最初に中央ユニット２１８で登録することができる。

ブロック５０２において、ウェブブラウザを使用する顧客は、中央ユニット２１８によって提供されるウェブサイト（図示せず）にアクセスする。顧客２１６は初期登録、およびソフトウェアのダウンロードページに行き、ＩＰＲＭ構成要素をいくつか含むビューアアプリケーションをダウンロードし、インストールする。或いは、ビューアアプリケーション、およびＩＰＲＭ構成要素はＣＤ−ＲＯＭのような取外し可能なメディアによって顧客に配布することも可能である。

ブロック５０４において、顧客２１６は前記ビューアアプリケーションを起動して、プロビジョニングサーバ２２０とのＳＳＬ（セキュアソケットレイヤ）セッションを開始する。前記セッションは中央ユニット２１８の証明書（図示せず）を使用して開始される。前記証明書は中央ユニットにより署名された公開鍵であり、顧客２１６が以前に取得しているものである。ＳＳＬセッションを開始すると、顧客２１６は初期登録フォームを記入し、その登録フォームにはユーザＩＤの記入を含む。或いは、中央ユニットが自動的にユーザＩＤを割り当てることもできる。顧客２１６は次に、ローカルホスト識別子を決定し、その他の情報と共にプロビジョニングサーバ２２０に送信する。（上記手続きはビューアアプリケーションによって透過的に行われる）。

ブロック５０６においてプロビジョニングサーバ２２０はユーザＩＤを抽出して、ＥＳＢｒｏｋｅｒ（商標）プリンシパル名に変換する。プリンシパル名とはＩＰＲＭシステム２００に参加する顧客、またはサーバインスタンスを一意に識別するために名付けられた名前である。この場合、視聴者のプリンシパル名はその視聴者に割り当てられた加入者ＩＤと同一である。ユーザＩＤがＥＳＢｒｏｋｅｒ（商標）プリンシパル名に変換された後、プロビジョニングサーバ２２０はＫＤＣ２０４にコマンドを送信してＫＤＣ２０４のデータベース（図示せず）に新しいＥＳＢｒｏｋｅｒ（商標）プリンシパルを生成する。また、このコマンドは顧客２１６のホスト識別子を含んでいる。

ブロック５０８において、ＫＤＣ２０４は顧客２１６のためのプロビジョニング鍵（セッション鍵）を含むプロビジョニングチケットを生成する。前記プロビジョニング鍵は、本発明の一実施形態において対称鍵であり得る。ＫＤＣ２０４はプロビジョニング鍵を、ＫＤＣ２０４自身と顧客２１６との間のメッセージの認証に使用する。その後、プロビジョニングチケットはＳＫＳ（セッション鍵シード）と共にプロビジョニングサーバ２０２に返される。顧客２１６はプロビジョニング鍵（ＫＤＣ２０４の鍵で暗号化されている）にアクセスすることができないため、顧客２１６はＳＫＳを使用してプロビジョニングチ
ケット内にあるプロビジョニング鍵を再現する。

ブロック５１０ではプロビジョニングチケットに加えて、ユーザＩＤ、チケット有効期限（既にチケットの暗号化されていない部分に含まれている）、ＫＤＣ２０４の名前かつ／またはアドレス等、および（オプションとして）ＥＳＢｒｏｋｅｒ（商標）ソフトウェアを含む、ソフトウェア構成要素を備える設定パラメータが、顧客２１６によってダウンロードされる。エアロキャストネットワークの場合にあるように、前記ソフトウェア構成要素は本登録手続きの前にダウンロードされる場合もあることに注意されたい。その後、ＳＳＬ接続が終了する。

ブロック５１２において、ダウンロードした前記設定パラメータを使用してＥＳＢｒｏｋｅｒ（商標）ソフトウェアが起動する。
ブロック５１４において、顧客２１６とＫＤＣ２０４との間のＡＳ＿ＲＥＱメッセージを認証するために、公開鍵／秘密鍵の対が生成される。公開鍵は顧客２１６からＫＤＣ２０４に転送される。これは、ＣＬＩＥＮＴ＿ＥＮＲＯＬＬ＿ＲＥＱメッセージを使用して実現される。前記メッセージは、プロビジョニング鍵によって（対称的に）署名された公開鍵を含み、前記プロビジョニング鍵は顧客２１６によってＳＫＳから導出されたものである。顧客２１６はプロビジョニングチケット内のプロビジョニング鍵にアクセスできないことから、一方向関数を使用してＳＫＳからプロビジョニング鍵を導出する。チケット、およびプロビジョニング鍵を、ソフトウェアクライアントに配信する上で問題となるのは、ソフトウェアクライアントがチケット、およびプロビジョニング鍵をコピーして、許可されていないソフトウェアクライアントに転送する可能性があることである。この問題に対処するために、顧客２１６は実際にプロビジョニング鍵を受信する代わりに、ＳＫＳを受信するのである。一方向関数を使用してＳＫＳを一意であるホスト識別子と組み合わせることで、プロビジョニング鍵が生成される。ＳＫＳは特定のホストに特化しており、その他のホストでは使用することはできない。本発明の実施形態において、顧客２１６はプロビジョニング鍵を再作成するために以下の関数を使用する。

Ｐｒｏｖｉｓｉｏｎｉｎｇ ｋｅｙ ＝ ＳＫＧｅｎ（Ｈｏｓｔ ＩＤ、ＳＫＳ）
上式において、ＳＫＧｅｎ（）は一方向関数であり、ＳＫＧｅｎ^−１（）は妥当な時間内（例えば、チケットの有効期間より短い時間）において計算不可能である。

ブロック５１６において、ＫＤＣ２０４はＣＬＩＥＮＴ＿ＥＮＲＯＬＬ＿ＲＥＱメッセージを受信すると、顧客２１６をローカルデータベース内に発見し、その要求を確認する。その要求が有効であれば、ＫＤＣ２０４は、自身に配置することも可能なクライアントデータベース内か、安全なアクセスのあるその他の遠隔地のどちらかに公開鍵を保存する。或いは、ＫＤＣ２０４は顧客２１６に公開鍵を転送するために、公開鍵証明書を生成してもよい。その後、その鍵を保存している（或いはクライアント証明書を含んでいる）ことを承認するＣＬＩＥＮＴ＿ＥＮＲＯＬＬ＿ＲＥＰメッセージが顧客２１６に転送される。

ブロック５１８において、顧客２１６はこの時点で登録され、コンテンツプロバイダ２０２を含む、様々なプロバイダによるコンテンツのリストを有するデータベース２０８のあるウェブサイト（図示せず）にアクセスすることができる。顧客２１６は目的のコンテンツを特定すると、コンテンツプロバイダ２０２へと導かれる。

ブロック５２０では、顧客２１６は導かれたコンテンツプロバイダ２０２にアクセスし、好みのキャッシュサーバのリスト、加入したサービスのリスト、コンテンツに対する支払い能力等を伝える。

ブロック５２２では、コンテンツプロバイダ２０２は、特定の顧客やサービス事情に依存する購入オプションから、最適なセットを提供する。例えば、価格選択の画面において既にこのサービスに加入した顧客の場合には、その画面を省略することができる。

ブロック５２４において、コンテンツプロバイダ２０２は、顧客２１６によって選択された購入オプションをカプセル化するセッション権オブジェクト、コンテンツにアクセスする規則に関するオプションセット（例えば、停電地域）、および選択したコンテンツを参照する資料を生成する。例えば、顧客２１６がコンテンツプロバイダにこれらのセッション権を要求した際に、顧客２１６によって生成された乱数であるセッションＩＤ、これらのセッション権が後に有効でなくなる終了時刻、プロバイダＩＤ、顧客２１６によって選択された購入オプション等がある。

ブロック５２６において、コンテンツプロバイダ２０２は顧客２１６を導いて、適切なキャッシュサーバに案内する。この場合、コンテンツは顧客２１６に最も近いキャッシュサーバ２１５からストリーミングされる。顧客２１６が登録時において、以前にキャッシュサーバ２１５のキャッシュサーバチケットをキャッシュしていた場合には、そのチケットを抽出する。チケットをキャッシュしていない場合には、ＴＧＴを使用してＫＤＣ２０４にアクセスし、適正なキャッシュサーバチケットを取得する。

ブロック５２８において顧客２１６は、キャッシュサーバチケットを使用して、キャッシュサーバ２１５に対して自分自身を認証すると同時に、（同一のＫＥＹ＿ＲＥＱメッセージにある）コンテンツプロバイダ２０２から取得したセッション権オブジェクトをキャッシュサーバ２１５に転送する。顧客２１６とキャッシュサーバ２１５との間の通信は上記のＫＥＹ＿ＲＥＱ／ＫＥＹ＿ＲＥＰメッセージを使用して実現される。

ブロック５３０において、キャッシュサーバ２１５はチケットに含まれている顧客２１６の資格に対するアクセス規則を、セッション権オブジェクトから調べる。同様にセッション権オブジェクトにあるユーザ選択（顧客によって選択された購入オプション）に対するアクセス規則も調べる。前記資格は基本的に顧客２１６に特化した認証データであり、顧客がコンテンツにアクセスすることを許可するものである。コンテンツアクセス規則のセットは、コンテンツと共にキャッシュサーバ２１５に直接配信された可能性もあるため、任意のものである。更にキャッシュサーバ２１５は様々な情報源から、追加したコンテンツアクセス規則を任意に集めることができる。例えば、アクセスネットワークプロバイダ（例えば、ケーブルシステムオペレータ）が、そのネットワーク上の配信においてある制限を加えること等である。

ブロック５３２においてアクセスが承認された場合、顧客２１６、およびキャッシュサーバ２１５は、コンテンツを配信するためのコンテンツ暗号化鍵（ＣＥＫ）を交換する。
ブロック５３４において、ストリーミングセッションにおける通信の安全を確保するセキュリティパラメータが設定される。様々なパラメータの内、セキュリティパラメータはＭＡＣ（メッセージ認証コード）、およびコンテンツ暗号化鍵を含み、前記コンテンツ暗号化鍵の導出については以下に続く「鍵の導出」において説明する。前記セキュリティパラメータに関連するセッション識別子も同様に設定される。顧客２１６が、キャッシュサーバ２１５にＲＴＳＰコマンドの発行を開始して、コンテンツの解説（ＲＴＳＰ ＵＲＬ）を取得し、さらにコンテンツの再生を要求する際には、そのＲＴＳＰメッセージはセキュリティパラメータによって安全を確保される。

ブロック５３６において、キャッシュサーバ２１５はＲＴＳＰコマンドを受信し、それらのコマンドを複合化し、応答メッセージを暗号化して返す。ＲＴＳＰコマンドが特定のＵＲＬのストリーミングを要求すると、キャッシュサーバ２１５は、その特定のＵＲＬが
今回の安全なセッションに対するセッション権オブジェクトに特定されていたものであること、およびセッション識別子によって識別されたものであることを確認する。

ブロック５３８において、ＲＴＳＰ ＵＲＬのストリーミング要求を受信した後、キャッシュサーバ２１５はストリーミングセッションを確立し、ＲＴＰパケットの送信を開始する。キャッシュサーバ２１５も顧客２１６も両方とも、定期的にＲＴＣＰ報告パケットを送信する。ＲＴＰ、およびＲＴＣＰパケットは全てセキュリティパラメータによって暗号化されている。更に同一のＲＴＳＰ ＵＲＬに関連するＲＴＰ、およびＲＴＣＰパケットは、同一のセッションＩＤによって識別されたセキュリティアソシエーションを使用して暗号化され、前記セッションＩＤは、キャッシュサーバ２１５が顧客２１６から暗号化されたＲＴＳＰメッセージを受信し始めた際に記録したものである。前記ＲＴＳＰ、ＲＴＰ、およびＲＴＣＰメッセージは任意の順において交換可能であり、各メッセージはセキュリティパラメータによって安全を確保されており、セキュリティパラメータはセッション識別子によって識別可能であることに注意されたい。

ブロック５４０において、顧客２１６はコンテンツを複合化し、再生する。同時に顧客２１６は追加のＲＴＳＰコマンド（例えば、コンテンツの一時停止または再スタート）を発行することも可能であり、更に同一のセッションＩＤを使用して暗号化される。キャッシュサーバ２１５は誰がコンテンツを視聴しているか、どの位コンテンツが視聴されているか、どのような方法でコンテンツが購入されたか等の情報を記録する。
（ストリーミング、および非ストリーミングコンテンツ）
保護されているコンテンツは基本的に二つの種類に分類される。ストリーミングコンテンツ、および非ストリーミングコンテンツである。以下のプロトコルは実際のストリーミングコンテンツ、またはそのコンテンツに関連する情報のどちらかを配信するために使用される。ストリーミングコンテンツの場合、ＲＴＰ（リアルタイムプロトコル）／ＲＴＣＰ（リアルタイム制御プロトコル）、ＲＴＳＰ（リアルタイムストリーミングプロトコル）がある。サーバ間における非ストリーミングによるコンテンツの配信には、配送エージェントプロトコル（改良ＲＴＳＰ）がある。ストリーミングの内容を説明するにはＳＤＰ（セッション記述プロトコル）を伴うＲＴＳＰがある。他の非ストリーミングコンテンツとしては、ＨＴＴＰ（プロビジョニング、ディレクトリにコンテンツを公開）、ＴＣＰ（転送制御プロトコル）かＵＤＰ（ユーザデータグラムプロトコル）のどちらかで動作するカスタムプロトコル（コンテンツの使用状況を報告する）がある。標準ベースのシステムにおいて、ストリーミングコンテンツは通常ＲＴＰを使用して配信される。更に独自に開発されたプロトコルもある。例えばリアル、およびマイクロソフトのウィンドウズメディア（登録商標）等が用いられる。これらのプロトコルは典型的な例であり、他のプロトコルも使用し得ることに注意されたい。
（鍵の導出）
本願における鍵の導出処理はＩＰＲＭ ＤＯＩ＿ＩＤ値に特化したものであり、同一のＤＯＩ＿ＩＤに該当する他のターゲットプロトコルと同様に、メディアストリームにも適用可能である。鍵管理によってターゲットアプリケーションの秘密（ＴＡＳ）（ＥＳＢｒｏｋｅｒ（商標）セッション鍵とその副鍵を連結する）が確立されると、ターゲットアプリケーションを使用して、以下に続く鍵のセットを特定の順で導出する。（ＥＳＢｒｏｋｅｒ（商標）のＫＥＹ＿ＲＥＱメッセージを生成した）クライアントは、以下の鍵のセットを導出する。

アウトバウンドＥＫ、アウトバウンドメッセージに対するコンテンツ暗号化鍵。その長さは暗号文による。
アウトバウンドＫ_ＭＡＣ、アウトバウンドメッセージを認証するためのＭＡＣ（メッセージ認証コード）の生成に使用するＭＡＣ鍵。鍵の長さは選択したメッセージ認証アルゴリズムによる。

インバウンドＥＫ、インバウンドメッセージに対するコンテンツ暗号化鍵。
インバウンドＫ_ＭＡＣ、インバウンドメッセージの認証に使用されるＭＡＣ鍵。
（ＥＳＢｒｏｋｅｒ（商標）の鍵応答メッセージを生成する）アプリケーションサーバは以下の暗号化鍵を導出する。

インバウンドＥＫ
インバウンドＫ_ＭＡＣ
アウトバウンドＥＫ
アウトバウンドＫ_ＭＡＣ
注意すべきは、クライアントとサーバにおいてインバウンド鍵、およびアウトバウンド鍵が導出される順は、逆になっていることである。これは一方におけるアウトバウンドトラフィックの暗号化と、他方におけるインバウンドトラフィックの複合化に同一の鍵を使用しているためである。同様に、一方においてアウトバウンドメッセージのためのＭＡＣの生成に使用されているＭＡＣ鍵と、他方においてインバウンドメッセージ上のＭＡＣ値の確認に使用されるＭＡＣ鍵とは同一である。

それぞれのプロトコルに全ての鍵が使用されるわけではないことに注意されたい。例えば、ＲＴＰではＥＫ（暗号化鍵）のみ使用し、一方向のみのトラフィックに使用される。これはＩＰＲＭにおいて双方向のＲＴＰセッションがないためである（クライアントはストリーミングサーバにＲＴＰパケットを返信しない）。

上記において、本発明の特定の典型的な実施形態を全て説明したが、他の実施形態を補足することも可能である。従って、上記の説明は本発明の範囲を限定するものと解釈すべきではなく、他の類するもの全てを含む、添付の特許請求の範囲によって定義されるものとする。

通信ネットワーク上におけるコンテンツのストリーミングを実現するネットワークブロック図。 本発明の典型的な実施形態における、図１のネットワークに鍵管理、およびセキュリティを適用するためのＥＳＢｒｏｋｅｒ（商標）プロトコルを組み合わせたＩＰＲＭ（インターネットプロトコル権利管理）システムブロック図。 本発明の典型的な実施形態に基づく、顧客による鍵管理開始時におけるキャッシュサーバ（サーバ）へのセキュリティおよび鍵管理プロトコルの高レベル流れ図。 本発明の典型的な実施形態に基づく、鍵管理開始時におけるキャッシュサーバ（サーバ）からコンテンツプロバイダ（クライアント）へのセキュリティおよび鍵管理の高レベル流れ図。 本発明の典型的な実施形態に基づく、顧客による初期登録、およびコンテンツの受信を表すブロック図。

Claims (9)

1. ＲＴＰ（リアルタイム制御プロトコル）、ＲＴＣＰ（リアルタイム制御プロトコル）、およびＲＴＳＰ（リアルタイムストリーミングプロトコル）を含む、複数のプロトコルを用いて、サーバからクライアントへリアルタイムデータを安全にストリーミングする方法であって、
   クライアントが、リアルタイムデータの安全を確保するために前記複数のプロトコルに対する複数のセキュリティパラメータを一度に確立する工程と、
   クライアントが、前記セキュリティパラメータに関連するセッション識別子を確立する工程と、前記セキュリティパラメータはセッション識別子を使用して識別可能であり、前記複数のプロトコルは共通のセッション識別子に関連付けられていることと、
   クライアントおよびサーバが、リアルタイムデータをストリーミングするための二つ以上のプロトコルメッセージを交換することによって、サーバからクライアントへリアルタイムデータを安全に転送する工程とを備え、各プロトコルメッセージは前記セキュリティパラメータによって安全を確保されている方法。
2. 請求項１記載の方法において、クライアントおよびサーバが二つ以上のプロトコルメッセージを交換することは、
   クライアントがサーバへＲＴＳＰメッセージを送信することと、前記ＲＴＳＰメッセージはリアルタイムデータストリームを要求するメッセージであることと、
   前記要求に応答して、サーバが前記リアルタイムデータをストリーミングするためのＲＴＰポートおよびＲＴＣＰポートのリストを含むＲＴＳＰメッセージを送信することとを含む方法。
3. ＲＴＰ（リアルタイム制御プロトコル）、ＲＴＣＰ（リアルタイム制御プロトコル）、およびＲＴＳＰ（リアルタイムストリーミングプロトコル）を含む、複数のプロトコルを用いて、サーバからクライアントへリアルタイムデータストリームを安全に転送する方法であって、
   クライアントが、前記データストリームの安全を確保するために前記複数のプロトコルに対する複数のセキュリティパラメータを一度に確立する工程と、
   クライアントが、前記セキュリティパラメータに関連するセッション識別子を確立する工程と、前記セキュリティパラメータはセッション識別子を使用して識別可能であり、前記複数のプロトコルは共通のセッション識別子に関連付けられていることと、
   クライアントがサーバへＲＴＳＰメッセージを送信する工程と、前記ＲＴＳＰメッセージはリアルタイムデータストリームを要求するメッセージであることと、前記ＲＴＳＰメッセージは前記セキュリティパラメータによって安全を確保されていることと、
   サーバがクライアントへ前記リアルタイムデータを含むＲＴＰメッセージを送信する工程と、前記ＲＴＰメッセージは前記セキュリティパラメータによって安全を確保されていることと、
   クライアントおよびサーバが、ＲＴＳＰメッセージ、ＲＴＰメッセージ、およびＲＴＣＰメッセージのうちから選択された二つ以上のプロトコルメッセージを任意の順で交換する工程と、を備え、各メッセージは前記セキュリティパラメータによって安全を確保されている方法。
4. 請求項３記載の方法において、前記セキュリティパラメータは、
   アウトバウンドメッセージを暗号化するための第一の鍵と、
   アウトバウンドメッセージを認証するための第二の鍵と、
   インバウンドメッセージを暗号化するための第三の鍵と、
   インバウンドメッセージを認証するための第四の鍵とを備えるセキュリティパラメータである方法。
5. ＲＴＰ（リアルタイム制御プロトコル）、ＲＴＣＰ（リアルタイム制御プロトコル）、およびＲＴＳＰ（リアルタイムストリーミングプロトコル）を含む、複数のプロトコルを用いて、サーバからクライアントへリアルタイムデータストリームを安全に転送するシステムにおいて、
   クライアントおよびサーバがＲＴＳＰメッセージを交換するための手段であって、前記ＲＴＳＰメッセージはＭＡＣ（メッセージ認証コード）鍵によって認証されている手段と、
   サーバからクライアントへリアルタイムデータをストリーミングするために、サーバがクライアントへＲＴＰメッセージを送信するための手段であって、前記ＲＴＰメッセージは暗号化鍵で暗号化され、前記ＭＡＣ鍵で認証されている手段と、
   クライアントおよびサーバがＲＴＣＰメッセージを交換するための手段であって、前記ＲＴＣＰメッセージは、前記リアルタイムデータがクライアントからサーバへ安全にストリーミングされるように、前記暗号化鍵で暗号化され、前記ＭＡＣ鍵で認証されている手段と、
   クライアントおよびサーバが前記ＲＴＳＰメッセージ、ＲＴＰメッセージ、およびＲＴＣＰメッセージに一つ以上の操作を実行するための手段であって、前記操作は暗号化と、認証と、暗号化および認証とのうちから選択される手段と、
   クライアントが前記複数のプロトコルに対する前記ＭＡＣ鍵および暗号化鍵を一度に確立するための手段と、
   クライアントが前記ＭＡＣ鍵と暗号化鍵とに関連するセッション識別子を確立するための手段と、を備え、
   前記ＭＡＣ鍵および暗号化鍵はセッション識別子を使用して識別可能であり、前記複数のプロトコルは共通のセッション識別子に関連付けられている、システム。
6. 請求項５記載のシステムにおいて、
   一つ以上のＲＴＳＰメッセージを交換する前に、クライアントが前記ＭＡＣ鍵および暗号化鍵をセッション識別子と関連付けるための手段を備えるシステム。
7. クライアントサーバシステムにおいて、ＲＴＰ（リアルタイム制御プロトコル）、ＲＴＣＰ（リアルタイム制御プロトコル）、およびＲＴＳＰ（リアルタイムストリーミングプロトコル）を含む、複数のプロトコルを用いて、リアルタイムデータを安全に通信する方法であって、
   クライアントが、前記リアルタイムデータを安全に転送するために前記複数のプロトコルに対する複数のセキュリティパラメータを一度に確立する工程と、
   クライアントが、前記セキュリティパラメータに関連するセッション識別子を確立する工程と、前記セキュリティパラメータはセッション識別子を使用して識別可能であり、前記複数のプロトコルは共通のセッション識別子に関連付けられていることと、
   クライアントがサーバへ、前記リアルタイムデータを要求するための第一プロトコルメッセージを送信する工程と、前記第一プロトコルメッセージは前記セキュリティパラメータによって安全を確保されていることと、
   サーバが、前記リアルタイムデータを含む第二プロトコルメッセージをストリーミングするためのストリーミングセッションを確立する工程と、前記第二プロトコルメッセージは前記セキュリティパラメータによって安全を確保されていることと、
   クライアントおよびサーバが、追加のプロトコルメッセージを任意の順で交換する工程と、各メッセージは前記セキュリティパラメータによって安全を確保されていることと、前記セキュリティパラメータはセッション識別子によって識別可能であることとを備える方法。
8. 請求項７記載の方法において、前記セキュリティパラメータは、
   アウトバウンドメッセージを暗号化するための第一の鍵と、
   アウトバウンドメッセージを認証するための第二の鍵と、
   インバウンドメッセージを暗号化するための第三の鍵と、
   インバウンドメッセージを認証するための第四の鍵とを備えるセキュリティパラメータである方法。
9. 請求項１記載の方法において、前記プロトコルメッセージはＲＴＳＰメッセージ、ＲＴＰメッセージ、およびＲＴＣＰメッセージのうちから選択される方法。

Images