JP4674044B2 - クライアントが許可を検証できるキー管理プロトコルを設けるためのシステムおよび方法 - Google Patents

Description

本発明は、一般的に、ネットワークのセキュリティに関し、更に特定すれば、アプリケーション・サーバからのコンテンツを要求するときに、クライアントのプライバシを保護する方法およびシステムに関する。

インターネットは安全性が低いネットワークである。ネットワーク上で用いられているプロトコルの多くは、セキュリティを全く設けていない。暗号化またはその他の何らかの形式のセキュリティ方式を用いずにインターネット上で送信されるデータは、「平文」で送信すると言われる。平文でインターネット上で送信される、パスワード、クレジット・カード番号、顧客の身元および氏名等のようなデータを、ハッカーが「かぎつける」ことができるようにするツールは、容易に入手することができる。したがって、暗号化しないデータをインターネット上で送信するアプリケーションは、被害を受ける虞れが非常に高い。

ケルベロス（Ｋｅｒｂｅｒｏｓ）は、秘密キー暗号法を用いることによって、クライアント／サーバ・アプリケーションの認証を行うように設計された、公知のネットワーク認証プロトコルの一例である。ケルベロス（Ｋｅｒｂｅｒｏｓ）プロトコルは、マサチューセッツ工科大学から入手可能であり、暗号法を用いて、クライアントがその身元をサーバに（またはその逆）、安全性の低いネットワーク接続を通じて立証することができると言われている。クライアントおよびサーバがケルベロス（Ｋｅｒｂｅｒｏｓ）を用いてそれぞれの身元を証明した後、その通信全てを暗号化することもでき、彼らがその業務を遂行する際に、プライバシおよびデータ保全性を保証すると言われている。

本発明は、ネットワーク・セキュリティの分野に関するこれらおよびその他の背景情報要因に関連してなされた。

本発明は、クライアントに、当該クライアントがアクセスし利用することができる許可データのコピーを供給する方法を提供する。本方法は、クライアントから認証サーバ要求（ＡＳ＿ＲＥＱ）メッセージを受信するステップと、認証サーバ回答（ＡＳ＿ＲＥＰ）メッセージを生成するステップと、ＡＳ＿ＲＥＰをクライアントに送信するステップと、クライアントからチケット付与サーバ要求（ＴＧＳ＿ＲＥＱ）メッセージを受信するステップと、許可データの２つのコピーを有するチケット付与サーバ回答（ＴＧＳ＿ＲＥＰ）メッセージを生成するステップと、ＴＧＳ＿ＲＥＰを許可データの２つのコピーと共にクライアントに送信するステップとを含む。

別の実施形態では、本発明は、許可データの第１コピーを含むサービス・チケットを生成するステップと、サービス・チケットを含むチケット付与サーバ回答を生成するステップと、チケット付与サーバ回答および許可データの第２コピーをクライアントに送信するステップとを含む。一実施形態では、許可データの第２コピーを送信するステップは、クライアントが許可データの第２コピーを解読して利用できるように、クライアント・セッションキーを用いて許可データの少なくとも第２コピーを暗号化することを含み、サービス・チケットを生成するステップは、サーバキーを用いて、少なくとも第１許可データを暗号化することを含む。

別の実施形態では、本発明は、アプリケーション・サーバからのコンテンツを要求するときに、クライアントのプライバシ保護を確保するシステムであることを特徴とすることができる。このシステムは、許可データの少なくとも２つのコピーを含むチケット付与サーバ回答を生成するように構成されたキー配布局を含み、キー配布局は、チケット付与サーバ回答を受信し、許可データの一方のコピーを利用して許可を検証するように構成されているクライアントと結合されており、クライアントはコンテンツをクライアントに供給するように構成されたアプリケーションサーバに結合されている。クライアントは、更に、許可データの一方のコピーを用いて、コンテンツの正規使用を検証するように構成されている。

別の実施形態では、本発明は、クライアントにコンテンツおよびサービスの少なくともいずれかへのアクセスを与えるシステムであることを特徴とする。このシステムは、許可データの第１コピーを含むサービス・チケットを生成する手段と、サービス・チケットと、許可データの第２コピーとを含むチケット付与サーバ回答を生成する手段と、チケット付与サーバ回答をクライアントに送信する手段とを含む。チケット付与サーバ回答を生成する手段は、クライアント・セッションキーを用いて、許可データの少なくとも第２コピーを暗号化する手段を含むことができる。少なくとも第２許可データを暗号化する手段は、クライアントが許可データの第２コピーを解読し利用できるように、許可データの少なくとも第２コピーを暗号化する手段を含むことができる。サービス・チケットを生成する手段は、サーバキーを用いて、許可データの少なくとも第１コピーを暗号化する手段を含むことができる。許可データの第２コピーは、クライアントが、アプリケーション・サーバからのサービスに対する要求を検証できるように、構成することができる。許可データの第２コピーは、クライアントが、受信したコンテンツの正規使用を判断できるように構成することができる。

本発明の特徴および利点は、以下の発明の説明、および本発明の原理を利用した例示的実施形態を明記する添付図面を参照することによって、一層深く理解されよう。
本発明の前述のおよびその他の態様、特徴ならびに利点は、以下の図面に関連付けて示した、以下の更に特定的な発明の説明から更に明らかとなろう。

対応する参照符号は、図面における種々の図全てを通じて対応する構成要素を示すこととする。

ケルベロス（Ｋｅｒｂｅｒｏｓ）は、クライアントまたはサーバのようなネットワークのエンティティは、アプリケーション・サーバが供給するサービスおよび／またはコンテンツにアクセスするために、アプリケーション・サーバに提出した許可データを検証することができないという不都合を有している。部分的に、許可データは、クライアントに供給されるであろうサービスおよび／またはコンテンツの範囲を規定する。多くの場合、許可データは、アプリケーション・サーバ１０６ならびに当該アプリケーション・サーバ１０６が提供するコンテンツおよび／またはサービスに特定的である。クライアントは許可を検証することができないので、クライアントはコンテンツに対する要求をチェックして、許可されていないオプションが選択されていないことを確認することができない。加えて、クライアントは許可データを検証することができないので、クライアントは、当該クライアントに配信されるコンテンツをコピーすることがクライアントに許可されているか否か判断するためには、余分な通信および情報が必要となる。この結果、エラーが生じ、ネットワーク・トラフィックが過剰となり、ネットワーク資源および処理が無駄に使われることになる。更にまた、クライアントは許可データを検証することができないので、ク
ライアントは、余分な通信および情報を受信せずには、例えば、コンテンツを１回よりも多く再生することがクライアントに許可されているか否か判断することができない。

本発明は、許可データのコピーをクライアントに配信することによって、上記およびその他の欠点を克服する方法およびシステムを提供する。クライアントは、前記許可データのコピーにアクセスして利用し、ネットワーク効率を高め、ネットワーク・トラフィックを削減し、コンテンツおよび／またはサービスのアクセスや使用を合理化することを可能にする。許可データのクライアント・コピーをクライアントに供給することによって、クライアントは要求を検証し、コンテンツ要求の中に違法なオプションが含まれることを回避することができ、配信されたコンテンツおよび／またはサービスにおけるクライアントが正規使用を判断し、例えば、配信されたコンテンツのコピーを保存することができるか、およびコンテンツを１回よりも多く再生することができるかについて判断することができる。
本発明は、チケットの概念を利用するキー管理プロトコルに非常に適している。チケットとは、対称キーで暗号化した認証トークンであり、対称キーによってクライアントは特定のサーバに認証することができる。本発明の一実施形態によれば、キー配布局（ＫＤＣ）がサービス・チケットをクライアント、サーバ、またはネットワークのその他のエンティティに転送するとき、サービス・チケット内に２つの許可データのコピーを含む。許可のコピーの一方、すなわち、クライアント・コピーは、クライアントによる使用を目的として、クライアント（サーバまたはその他のエンティティ）が許可データにアクセスすることができる。許可データのコピーのもう一方、すなわち、サーバ・データは、クライアントからのコンテンツ選択および／またはキー要求と共に、アプリケーション・サーバに供給される。本発明は、アプリケーション・サーバによって提供されるコンテンツおよび／またはサービスに対するアクセスを得ようとするクライアントまたはサーバによって、アクセスされ使用される許可データのコピーを供給することによって、標準的なケルベロス（Ｋｅｒｂｅｒｏｓ）およびその他の以前のプロトコルの不都合を解消する。

図１を参照すると、本発明の一実施形態にしたがって構成した、安全な通信を行うシステム１００の簡略ブロック図が示されている。本発明の可能な一実施態様の一例を含むシステム１００は、インターネット、イントラネットまたはその他のネットワークのような、ネットワーク上でセキュリティおよびプライバシを確保する認証キー管理プロトコルを用いる。これは、百万人単位のユーザに拡大することができる。概略的に、システム１００は、公開キーアルゴリズムおよび対称キーアルゴリズムの双方を用いて、１つ以上の中央キー配布局（ＫＤＣ）１０４と対話し、かつ対称キーアルゴリズムを用いて、アプリケーション・サーバ１０６（および第三者サーバ１４０、図２参照）のような、個々のアプリケーション・サーバと対話する少なくとも１つのクライアント１０２を含む。プロトコルは汎用的であり、分散環境において認証を要求する異なるアプリケーションに容易に改造することができる。更に、集中管理ユーザ・データベースとインターフェースされ得る。

クライアント１０２は、ユーザに代わってネットワーク・サービスを利用するプロセス、アプリケーション、またはデバイスを含み得る。一例として、クライアント１０２は、任意の種類のコンピュータからなってもよいし、あるいはクライアント１０２は、ワイヤレス電話機、ページャ（小型無線呼出機）、携帯端末（ＰＤＡ）、ローエンドのマイクロプロセッサを有する家電製品、または処理能力が低いかまたは限られているその他の実質的に任意の装置からなってもよい。尚、場合によっては、サーバ自身がある他のサーバのクライアントにもなり得る（例えば、プリント・サーバはファイル・サーバのクライアントである場合もある）ことを注記しておく。

アプリケーション・サーバ１０６は、ネットワーク・クライアントに資源を提供する。
例示する実施形態では、ＫＤＣ１０４は、第１ステージ１０８および第２ステージ１１０を含む。一実施形態では、第１ステージは認証サーバ（ＡＳサーバ）１０８であり、第２ステージはチケット付与サーバ（ＴＧＳサーバ）１１０である。ＡＳサーバ１０８は、クライアント１０２の信用証明書(credential)を検証した後に、チケット付与チケット（ＴＧＴチケット）をクライアント１０２に発行する。ＴＧＳサーバ１１０は、アプリケーション・サーバ・サービス・チケット（ＳＴチケット）をクライアント１０２に供給する。ＳＴチケットは、クライアント１０２がサービスを要求するときに、クライアントがアプリケーション・サーバ１０６に提示する最終サービス・チケットである。アプリケーション・サーバ１０６は、クライアント１０２がＳＴチケットを用いて自身を認証したときに、種々のサービスをクライアント１０２に提供する。

システム１００が用いる基本的なメッセージ・タイプは以下の通りである。
（Ａ）認証サーバ要求メッセージ（ＡＳ＿ＲＥＱ）：ＡＳサーバ１０８からのＴＧＴチケットを要求するためのクライアント１０２からのメッセージ。

（Ｂ）認証サーバ回答メッセージ（ＡＳ＿ＲＥＰ）：ＴＧＴチケットを備える、ＡＳサーバ１０８からクライアント１０２への回答メッセージ。
（Ｃ）チケット付与サーバ要求メッセージ（ＴＧＳ＿ＲＥＱ）：ＴＧＳサーバ１１０からのＳＴチケットを要求するためのクライアント１０２からのメッセージ。

（Ｄ）チケット付与サーバ回答メッセージ（ＴＧＳ＿ＲＥＰ）：ＳＴチケットを備える、ＴＧＳサーバ１１０からクライアント１０２への回答メッセージ。
（Ｅ）キー要求メッセージ（ＫＥＹ＿ＲＥＱ）：セキュリティ（キー管理）パラメータを要求するためのクライアント１０２からアプリケーション・サーバ１０６へのメッセージ。

（Ｆ）キー回答メッセージ（ＫＥＹ＿ＲＥＰ）：サブキーおよびアプリケーション特定データを備える、アプリケーション・サーバ１０６からクライアント１０２への回答メッセージ。

（Ｈ）コンテンツおよび／またはサービス・メッセージの要求（ＣＯＮ＿ＲＥＱ）：所望のコンテンツおよび／またはサービスを要求するためにクライアント１０２からアプリケーション・サーバ１０６に送られるメッセージ。

（Ｉ）コンテンツ（ＣＯＮ＿ＲＥＰ）：所望のコンテンツおよび／またはサービスをクライアントに供給する、アプリケーション・サーバ１０６からクライアント１０２へ送られるメッセージ。コンテンツは、クライアントに送られる前に暗号化されるのが通常である。

これらのメッセージの各々は、一般に、ヘッダ、およびこれに続くメッセージ本体を含み、ヘッダはメッセージに共通である。一例として、ヘッダは、メッセージ・タイプ・フィールド、プロトコル・バージョン番号フィールド、およびチェックサムを含むことができる。メッセージ・タイプ・フィールドは、ＡＳ＿ＲＥＱ、ＡＳ＿ＲＥＰ等のようなメッセージ・タイプを示す。メッセージ・ヘッダに続いて、メッセージ本体があり、好ましくは、タイプ−長さ−値（ＴＬＶ）フォーマットで属性のリストを有する。

クライアント１０２が、同様にＫＤＣ１０４の一部であるＴＧＳサーバ１１０のチケットであるＴＧＴチケットを取得したいとき、クライアントは、ＡＳ＿ＲＥＱメッセージを生成して、クライアント１０２とＡＳサーバ１０８（ＫＤＣ１０４の一部）との間で認証サービス交換を開始する。言い換えると、ＡＳ＿ＲＥＱメッセージは、ＴＧＴチケットを
取得するために、クライアント１０２からＡＳサーバ１０８に送られ、クライアントはＴＧＴチケットを用いて、アプリケーション・サーバ１０６のような、特定のアプリケーション・サーバのためのＳＴチケットを要求する。一例として、ＡＳ＿ＲＥＱメッセージは、クライアントの身元（例えば、名称）、ＴＧＳサーバ１１０の身元、およびこれを応答に結び付けるノンス(nonce) を含むことができる。また、ＡＳ＿ＲＥＱメッセージは、クライアント１０２がサポートする対称暗号アルゴリズムのリストも含むことができる。回答に対してチェックするために、このメッセージは、タイムスタンプ、およびメッセージ完全性のための署名も含むことができる。署名は、キー付きチェックサム(keyed checksum)またはディジタル署名とすることができる。

署名を検証する公開キーは、ユーザのデータベースに保持しておくことが好ましい。任意にＡＳ＿ＲＥＱメッセージにディジタル証明書を含ませることができ、このディジタル証明書は格納されている公開キーの代わりに、ディジタル署名を検証するために用いられ得る。クライアント１０２のキー付きチェックサムを検証するためのクライアント１０２の永久対称キーは、同じユーザ・データベースに保持しておくことが好ましい。また、ＡＳ＿ＲＥＱメッセージは、キー同意（例えば、楕円曲線ディッフィ−ヘルマン(Elliptic Curve Diffie-Hellman) パラメータ）に必要な公開キー情報も含むことができる。一例として、楕円曲線(Elliptic Curve)は、その処理速度のために、公開キー暗号化に用いることができる。楕円曲線の使用は、ＲＳＡのような他の暗号化よりも、通常、１桁または２桁ほど高速である。キーの長さが１２８ビットのラインダール(Rijndael)暗号規格を用いてもよい。

ＡＳサーバ１０８は、ＡＳ＿ＲＥＱメッセージを検証するために、そのＡＳ＿ＲＥＱメッセージを処理する。ＡＳ＿ＲＥＱ処理でエラーが発生しない場合、ＡＳサーバ１０８は、ＡＳ＿ＲＥＱメッセージに応答してＡＳ＿ＲＥＰメッセージを生成する。通常、ＡＳサーバ１０８はデータベースにおいてＴＧＳサーバ１１０およびクライアント１０２のキーを調べ、後続のＫＤＣ１０４との認証のために、ランダムなクライアント・セッションキーを生成する。ＡＳサーバ１０８はＴＧＴチケットを生成する。ＴＧＴチケットは、通常、平文部および暗号化部分の双方を含む。ＴＧＳサーバ１１０の身元およびチケット有効期間は、発行されたＴＧＴチケットの平文側に提供され得る。チケットの暗号化部分は、クライアント１０２の名称、クライアントのセッションキー、および秘密に保持すべきその他のあらゆるデータを含むことができる。また、ＴＧＴチケットは、ＫＤＣ１０４が対応する暗号タイプおよびチェックサム・タイプのリストも提供することができる。チケットの暗号化部分は、ＫＤＣ１０４の秘密キーを用いて暗号化されていてよい。

一実施形態では、ＡＳ＿ＲＥＰメッセージは、クライアント１０２がＡＳ＿ＲＥＱメッセージのための署名を生成するために用いたアルゴリズムと同一のものを用いて、ＫＤＣ１０４によって署名される。この署名は、ディジタル署名またはクライアント１０２の秘密キーを用いたキー付きチェックサムのいずれかとすることができる。公開キー情報は、ＫＤＣ１０４のキー同意パラメータの公開部であり、クライアント１０２が選択したのと同じキー同意アルゴリズムを示していなければならない。リプレイを防止するために、ＡＳ＿ＲＥＰメッセージは、クライアントがＡＳ＿ＲＥＱメッセージにおいて生成したノンスのコピーであるノンスも含むことが好ましい。

一実施形態では、ＡＳ＿ＲＥＰメッセージの暗号化部分は、クライアント１０２に、自身の許可データへのアクセスを提供する。クライアント１０２が自身の許可データを知っている場合には、アプリケーション・サーバは、チケット内部に暗号化されているクライアント情報のコピーしか信頼しないため、クライアントはアプリケーション・サーバによってあっさり拒絶されるであろう動作を行おうとはしないので、許可データのクライアント・コピーをクライアントに供給することによって、クライアント（およびユーザ）には
便利になる。また、クライアントにハードウェア・セキュリティが備えられており、ユーザがハッキングして自身の許可データを変更するのを防止する場合にも、この機構はセキュリティ上の利点となり得る。これは、読み取り可能な許可データは、ローカル・ディスク上のコンテンツ（例えば、ムービー）を保存し再生する権利というような、何らかの局在的な行為をクライアントに許可する場合もあるためである。ＡＳ＿ＲＥＰメッセージ内において受信した許可データのクライアント・コピーは、通常、一般的なクライアント許可を規定するのであり、サーバに特定的ではない。許可データのクライアント・コピーの使用については、以下で更に説明する。ＡＳ＿ＲＥＰメッセージの暗号化部分も、クライアント１０２の身元を含み、この回答が元々ＫＤＣ１０４によってこの特定のクライアント１０２のために作成されたことを検証することができる。データは、キー同意アルゴリズムから得られる対称キーを用いて暗号化することが好ましい。

クライアント１０２は、ＡＳ＿ＲＥＰメッセージを処理してその認証性を検証し、メッセージにおける秘密チケット部を解読し、ＴＧＴチケットを取得する。ＡＳ＿ＲＥＰメッセージの認証性を検証することができない場合、クライアント１０２は、エラー・メッセージをＡＳサーバ１０８に返送しないことが好ましい。場合によっては、クライアントは別のＡＳ＿ＲＥＱメッセージで再試行することもできる。

本発明は、任意で、ＡＳ＿ＲＥＱメッセージおよびＡＳ＿ＲＥＱメッセージの双方においてディジタル証明書の受け渡しを可能にし、更にクライアント１０２およびＫＤＣ１０４がディジタル証明書によって互いに認証し合うことを可能にする。証明書がない場合には、クライアント１０２には既にＫＤＣ公開キーが渡されており、ＫＤＣ１０４は既にクライアント１０２の公開キーをそのデータベース内に有していると予測される。ＡＳ＿ＲＥＱ上のディジタル署名は、ＫＤＣ１０４のデータベース内で参照したクライアントの公開キーを用いてＫＤＣ１０４によって検証される。クライアント１０２は、ＡＳ＿ＲＥＰ上のディジタル署名を、予め渡されているＫＤＣ公開キーを用いて検証する。

クライアントがＡＳサーバ１０８の交換によってＴＧＴチケットを取得した後、クライアント１０２は、アプリケーション・サーバ１０６のような、所与のまたは特定のアプリケーション・サーバに対する認証の信用証明書を取得したいときに、クライアント１０２は、当該クライアント１０２とＫＤＣ１０４のＴＧＳサーバ１１０との間でＴＧＳ＿ＲＥＱメッセージ交換を開始する。ＴＧＳ＿ＲＥＱメッセージは、クライアント１０２によって生成され、ＴＧＳサーバ１１０に送られて、アプリケーション・サーバ・サービス・チケット（ＳＴチケット）が取得され、このＳＴチケットはＫＥＹ＿ＲＥＱメッセージ（以下で更に説明する）において用いられる。クライアント１０２は、ＡＳ＿ＲＥＰメッセージから取得したＴＧＴチケットを、ＴＧＳ＿ＲＥＱメッセージの一部として提示する。ＴＧＳ＿ＲＥＱメッセージは、アプリケーション・サーバ１０６の身元を特定するだけでなく、通常ＴＧＴチケット内にあるクライアント１０２の身元も特定し、クライアントは通常ノンスを含む。一実施形態では、クライアント１０２の身元は保護されている。何故なら、ＴＧＴチケットの暗号化部分内にあり、メッセージの平文部分には含まれていないからである。ＴＧＴチケットからのクライアント・セッションキーは、ＴＧＳ＿ＲＥＱ交換における暗号化および解読に用いることができる。このため、詮索者(snooper) は、クライアント（例えば、ユーザ）がどのサービスを要求しているかを検出することができない。

好ましくは、クライアント１０２は、後でＫＤＣ１０４からの一致するＴＧＳ＿ＲＥＰメッセージの有効性を判断するために、ノンス値を保存する。好ましくは、クライアント１０２は、設定変更可能なタイム・アウト値が満了するまで、ノンス値を保持しておくとよい。タイム・アウトの後では、クライアント１０２はもはや対応するＴＧＳ＿ＲＥＰを処理することができず、再試行しなければならない。

ＴＧＳサーバ１１０は、ＴＧＳ＿ＲＥＱメッセージを検証し、ＴＧＴチケットを処理する。ＴＧＳサーバ１１０は、次いで、ＴＧＳ＿ＲＥＱメッセージに応答して、ＴＧＳ＿ＲＥＰメッセージを生成する。ＴＧＳ＿ＲＥＰメッセージは、ＫＤＣ１０４が発行したＳＴチケット（最終サービス・チケット）を含み、クライアント１０２がコンテンツおよび／またはサービスを要求しようとするときに、これをクライアントがアプリケーション・サーバ１０６に提示する。アプリケーション・サーバ１０６の身元およびチケット有効期間は、発行されたＳＴチケットの平文側に提供されている。ＳＴチケットの暗号化部分は、クライアント１０２の名称、ならびにアプリケーション・サーバ１０６およびＫＤＣ１０４が共有するサーバキーによって暗号化されているサーバ・セッションキーを含む。ＳＴチケットの暗号化部分は、更に、許可データの第１コピー（例えば、サーバ・コピー）も含み、これは、部分的に、クライアントに供給されるサービスおよび／またはコンテンツの範囲を規定する。許可データは、アプリケーション・サーバ１０６ならびにアプリケーション・サーバ１０６が提供するコンテンツおよび／またはサービスに特定的である。一実施形態では、許可データは、サービスおよび／またはコンテンツに特定のオブジェクト、およびこれらのオブジェクトに対する権利を含む。秘密にする必要がある付加的なクライアント・データは、いずれもＳＴチケットの暗号化部分の一部として含ませることができる。

一実施形態では、ＴＧＳ＿ＲＥＰは、許可データの第２コピー（例えば、クライアント・コピー）も更に含む。許可データの第２コピーは、ＡＳ＿ＲＥＰメッセージにおいてＡＳサーバ１０８が生成したＴＧＴチケットからのクライアント・セッションキーを用いて暗号化されている。前述のように、セッションキーは、ＴＧＳサーバ１１０およびクライアント１０２にはわかっている。許可データの第２コピー（クライアント・コピー）は、ＴＧＴチケットからのセッションキーを用いて暗号化されているので、検証の目的またはその他の目的のために、クライアント１０２は、許可データを解読し、その許可データを利用することができる。これについては、以下で更に説明する。ＴＧＳ＿ＲＥＰメッセージにおいて受信された許可データの第２コピーは、ＡＳ＿ＲＥＰメッセージにおいて受信される許可データの第２コピーよりも、よりサーバに特定的な許可を含む、更に特定的な許可を与えることができる。ＡＳ＿ＲＥＰメッセージにおいて受信する許可データは、更に一般的であり、サーバに特定的でないクライアント許可、例えば、クライアントがコンテンツを格納することを許可されているか否かを規定する。

ＴＧＳ＿ＲＥＰメッセージは、ＫＤＣ１０４によって、ＴＧＴチケット・セッションキーを用いて、キー付きチェックサムで署名される。ＴＧＳ＿ＲＥＰメッセージは、更に、リプレイを防止するために、ＴＧＳ＿ＲＥＱメッセージからコピーされたノンスも含む。

一例として、ＴＧＳサーバ１１０は、以下の手順を用いてＴＧＳ＿ＲＥＰメッセージを生成することができる。まず、ＴＧＳ＿ＲＥＱメッセージからのノンスをＴＧＳ＿ＲＥＰメッセージに含ませて、これを要求に結び付ける。次に、ＫＤＣ１０４はランダムＳＴチケット・セッションキーのタイプを割り当てる。１つよりも多い暗号化アルゴリズムが使用可能な場合、ＫＤＣ１０４は最も強力なものを選択することが好ましい。次いで、ＫＤＣ１０４は、許可データの第１コピー、すなわちサーバ・コピーを含むＳＴチケットを生成する。アプリケーション・サーバ１０６の秘密キーは、ＳＴチケットの暗号化部分を暗号化し、更に、ＳＴチケット全体に対するキー付きチェックサムを生成するために用いられる。ＳＴチケットの終了時刻は、ＫＤＣ１０４によって決定することが好ましい。クライアント１０２は、所望により、より短い有効期間を指定することもできる。ＳＴチケットの暗号化部分は、クライアント１０２の身元、許可データの第１コピー、セッションキー、およびその他の秘密データを含む。ＴＧＳ＿ＲＥＰメッセージは、更に、暗号化データ部を含み、ＴＧＴチケット・セッションキーは、暗号化データ部を生成するために用い
られる。暗号化データ部は、許可データの第２コピーを含み、ＴＧＴセッションキーを用いて生成されたキー付きチェックサムは、ＴＧＳ＿ＲＥＰメッセージ上に追加され得る。この場合も、これは、ＴＧＳサーバ１１０が、許可データの２つのコピーを含むＴＧＳ＿ＲＥＰメッセージを生成するために用いることができる手順の一例に過ぎない。

ＴＧＳ＿ＲＥＰメッセージは、一方はＳＴチケットの暗号化部分に含まれ、もう一方はＴＧＴチケットからのセッションキーによって暗号化されている２つの許可データのコピーを含むので、アプリケーション・サーバ１０６およびクライアント１０２は、許可データにアクセスし、これを用いることができる。このように、クライアントは、余分な通信や余分なデータを必要とせずに、チェックおよび検証を行うことができる。本発明は、ケルベロス（Ｋｅｒｂｅｒｏｓ）とは異なる。ケルベロス（Ｋｅｒｂｅｒｏｓ）では、特定のアプリケーション・サーバに対するクライアントからのチケット要求に対するＫＤＣ回答は、許可データの単一コピーを含むのみであり、このデータは、ＳＴチケットの解読時に、アプリケーション・サーバにしかアクセスすることができない。クライアントは、許可データにアクセスできず、データを利用することができない。これに代わって、本発明におけるＫＤＣは、一方はＳＴチケット内に暗号化されており、もう一方はＴＧＴチケットからのセッションキーによって暗号化されている許可データの２つのコピーを含ませることによって、特定のアプリケーション・サーバに対するクライアントからのチケット要求への回答を生成し、それにより、クライアント１０２が、許可データの第２コピーを解読して、許可データを利用することが可能になる。

一実施形態では、クライアント１０２は許可モジュール１２２を含む。許可モジュールは、許可データの第２コピーを受信し、許可データを分析して、アプリケーション・サーバ１０６が提供するコンテンツおよび／サービスの内どれを、どのようにクライアントが利用することを許可されているのか判定するように構成されている。許可モジュール１２２は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせによって実現することができる。一実施形態では、許可モジュール１２２は、ハードウェア・モジュールであり、許可データから抽出した許可をデコードし、クライアント１０２のコンテンツおよび／またはサービスに対する許可を検証し、クライアントが許可を超えていない場合にのみ、要求したコンテンツの解読および／またはサービスの提供に移行する。ハードウェア・モジュール外部からのソフトウェアによる詮索攻撃に対抗するために、許可データのキー付きチェックサムを検証するために用いられる秘密キーは、ハードウェア・モジュールの外側のクライアントには露出されていない。これを実施するために、一実施形態では、同じハードウェア・モジュール１２２内に、総合キー管理プロトコルが実装され、ハードウェア・モジュールの外側のクライアント内では、秘密キー即ちプライベートキーを平文では露出させない。

一例として、クライアント１０２は、以下の手順を用いて、ＴＧＳ＿ＲＥＰメッセージを処理することができる。この例では、「クライアント」とはクライアント１０２自身または許可モジュール１２２（クライアント内部にある場合）のいずれかを意味する。当業者であれば、許可モジュール１２２を備えたクライアントは、許可モジュールの外側では暗号化処理を行わせないことが認識されるであろう。まず、クライアント１０２はＴＧＳ＿ＲＥＰメッセージ・ヘッダを解析する。ヘッダの解析ができなかった場合、クライアント１０２は、ＴＧＳ＿ＲＥＰが受信されなかったかのように振る舞う。クライアント１０２は、エラー・メッセージをＴＧＳサーバ１１０に返送しない方が好ましい。場合によっては、クライアント１０２は別のＴＧＳ＿ＲＥＱメッセージを用いて再試行する。未処理のＴＧＳ＿ＲＥＱメッセージがある場合、クライアント１０２は、タイム・アウトまで回答を待ち続け、次いで再試行することができる。次いで、クライアント１０２は、ヘッダ内にあるプロトコル・バージョン番号を検証する。このプロトコル・バージョンに対応していない場合、クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージが受信されなかったか
のように振る舞う。それ以外の場合、クライアント１０２は次にメッセージの残り部分を解析する。メッセージ・フォーマットが違法であることがわかった場合、クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージが受信されなかったかのように振る舞う。

次に、クライアント１０２は、同じノンスを有する未処理のＴＧＳ＿ＲＥＱメッセージを探す。一致がない場合、クライアントは、メッセージが受信されなかったかのように続行する。チェックサムが検証されない場合、このメッセージを欠落させ、クライアント１０２は、メッセージが受信されなかったかのように続行する。

次に、クライアントは、ＴＧＴチケット・セッションキーを用いて、ＴＧＳ＿ＲＥＰメッセージにおける秘密チケット部分を解読する。ＴＧＴチケット・セッションキーのタイプおよび暗号化データのタイプが一致しないために秘密チケット部分が解読できない場合、致命的なエラーがユーザに報告され、クライアント１０２は再試行しない。得られた平文テキストがフォーマット・エラーを含む場合、またはこのクライアント１０２がサポートしていないタイプのセッションキーを含む場合、または要求と一致しないクライアントの身元を含む場合も、致命的エラーがユーザに報告され、クライアント１０２は再試行しない。セッションキータイプがサポートされており、クライアントがＴＧＳ＿ＲＥＰメッセージの秘密チケット部分を解読できる場合、クライアントは許可データの第２コピーを抽出し、これを検証し、後の使用のためにこれを保持する。

次に、クライアント１０２はＳＴチケットを処理する。ＳＴチケット内にエラーがある場合、これをユーザに致命的エラーとして報告し、クライアント１０２は他のＴＧＳ＿ＲＥＱメッセージで再試行しない。ＴＧＳ＿ＲＥＰメッセージ内にエラーが検出されない場合、クライアント１０２はＳＴチケット、および許可データの第１コピーを含む平文秘密チケット部分全体を、そのチケット・キャッシュ内の新たなエントリに保存する。許可モジュール１２２がクライアント１０２内にある実施形態では、クライアントは、変更バージョンのチケットに対するチェックサムを生成するためにサーバキーを入手しないため、ＳＴチケットは、クライアント１０２内部で、かつ許可モジュール１２２の外側に格納され得る。許可データは、許可モジュール１２２内部に格納されるか、あるいはキー付きチェックサムまたはディジタル署名によって認証され、次いでクライアント１０２内部でモジュールの外部に格納され得る。許可データを許可モジュール１２２の外部に格納する場合（モジュールの必要記憶量を極力抑えるため）、ハッカーの許可データを変更しようとする試みは、許可モジュール１２２によって検出される。これは、許可データのためにキー付きチェックサムまたはディジタル署名を生成する際に用いられるキーは、許可モジュール１２２の外部では読むことができないからである。

ＫＥＹ＿ＲＥＱおよびＫＥＹ＿ＲＥＰメッセージは、クライアント１０２とアプリケーション・サーバ１０６との間におけるキー管理および認証のために用いられる。ＫＥＹ＿ＲＥＱメッセージは、クライアント１０２によってアプリケーション・サーバ１０６に送られ、新たな１組のセキュリティ・パラメータを確立する。また、ＫＥＹ＿ＲＥＱメッセージは、クライアント１０２が定期的にアプリケーション・サーバ１０６との新たなキーを確立するためにも用いることができる。クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージにおいて前に取得されている有効なＳＴメッセージによって開始する。アプリケーション・サーバ１０６は、そのサービスキーで開始し、これを用いてチケットを解読し有効性を判断することができる。クライアントは、ＳＴチケット、およびクライアント１０２を認証するために必要なキー付きチェックサムを含むＫＥＹ＿ＲＥＱメッセージを生成する。ＫＥＹ＿ＲＥＱメッセージは、反射攻撃(replay attack) を防止するために、これを応答ＫＥＹ＿ＲＥＰメッセージおよびクライアント・タイムスタンプに結び付けるノンスも含むことが好ましい。

クライアント１０２がＫＥＹ＿ＲＥＱメッセージを生成するとき、許可データの第１コピー、および一実施形態では、クライアント１０２の身元は、ＳＴチケットの暗号化部分に存在する。クライアント１０２がＫＥＹ＿ＲＥＱメッセージを送り出した後、アプリケーション・サーバ１０６からの一致するＫＥＹ＿ＲＥＰメッセージの有効性を後に判断するために、クライアントのノンス値を保存する。クライアント１０２は、設定可能なタイム・アウト値が終了するまで、クライアントのノンス値を保持する。タイム・アウトの後では、クライアント１０２はもはや対応するＫＥＹ＿ＲＥＰメッセージを処理することができない。クライアント１０２は、このタイム・アウトの後に再試行することができる。

ＫＥＹ＿ＲＥＰメッセージは、ＫＥＹ＿ＲＥＱメッセージに応答して、アプリケーション・サーバ１０６によって送られる。一例として、ＫＥＹ＿ＲＥＱメッセージは、クライアント１０２およびアプリケーション・サーバ１０６間で共有するセッションキーで暗号化されている、１つ以上のランダムに生成されたサブキーを含むことができる。ＫＥＹ＿ＲＥＰメッセージは、セキュリティ・パラメータを確立するために必要な追加情報も含むことができる。

クライアント１０２は、ＫＥＹ＿ＲＥＰメッセージを受信し、ＫＥＹ＿ＲＥＰメッセージを処理する。クライアントは、メッセージ・ヘッダを解析し、プロトコル・バージョン番号を検証し、メッセージの残り部分を解析し、ＫＥＹ＿ＲＥＰ内のノンスを既存のクライアントＫＥＹ＿ＲＥＱノンスと照合し、クライアント１０２およびアプリケーション・サーバ１０６間で共有されるセッションキーを用いてチェックサムを検証する。更に、クライアントは、前記共有セッションキーを用いてＫＥＹ＿ＲＥＰのサブキーを解読し、選択したサイファースイート(ciphersuite) が受け入れ可能であることを検証し、暗号化されたＤＯＩオブジェクト（認証）を解析し、コンテンツ解読キーおよび認証キーをサブキーから生成し、これらを後の使用のために保存する。

一実施形態では、クライアント１０２が、一旦、ＫＥＹ＿ＲＥＰを受信し検証すると、クライアントによってＣＯＮ＿ＲＥＱメッセージがアプリケーション・サーバ１０６に送られる。ＣＯＮ＿ＲＥＱメッセージを生成する際、クライアントは、同クライアントがＡＳ＿ＲＥＰメッセージおよび／またはＳＴチケットを有するＴＧＳ＿ＲＥＰメッセージから受信して解読した、許可データの解読第２コピーにアクセスし、許可データを確認して、ＣＯＮ＿ＲＥＱメッセージが違法または不正なオプションを含んでいないことを確認する。したがって、クライアントのユーザ・インターフェースは改善され、ユーザは、ＣＯＮ＿ＲＥＱメッセージをサーバに提出し応答を待つ必要なく、最初から無許可のオプションを選択することを防止することができる。一実施形態では、クライアント１０２がなおも何らかの方法で無許可のＣＯＮ＿ＲＥＱメッセージを生成した場合、許可モジュール１２２は、ＣＯＮ＿ＲＥＱメッセージのキー付きチェックサムを生成するために必要な対称キーを保持し、許可データの第２コピーが規定するクライアントの許可に違反するかまたはそれを超過するＣＯＮ＿ＲＥＱメッセージに対して、このキー付きチェックサムを生成することを拒絶する。したがって、無許可のＣＯＮ＿ＲＥＱメッセージはクライアント側で拒絶されるが、かかる無許可のメッセージが侵入してきた場合、ＣＯＮ＿ＲＥＱは、正しいキー付きチェックサムを有しておらず、サーバ１０６にクライアント許可をチェックすることを要求することなく拒絶されるので、アプリケーション・サーバ１０６は、通常、そのような無許可のＣＯＮ＿ＲＥＱメッセージを発見することはない。

許可データの確認によって、アプリケーション・サーバ１０６において無許可のメッセージの処理を回避するため、システムが最適化され、クライアントとユーザとの対話が改善され、ユーザはアプリケーション・サーバ１０６の応答を待つことなく、その場で許可を評価することが可能となる。一実施形態では、ＣＯＮ＿ＲＥＱメッセージは、クライアント１０２およびアプリケーション・サーバ１０６が供給するセッションキーによって暗
号化される。

ＣＯＮ＿ＲＥＱメッセージを受信すると、アプリケーション・サーバ１０６はＣＯＮ＿ＲＥＱメッセージを処理し、暗号化ＳＴチケットの一部として受信した許可データの第１コピーによって、要求の有効性を判断する。エラーがなく、コンテンツに対する要求が許可データの許可に違反していない場合、アプリケーション・サーバ１０６はＣＯＮ＿ＲＥＰメッセージを生成し、クライアントが要求したコンテンツおよび／またはサービスの配信を開始する。通常、配信されるコンテンツは、クライアント１０２およびサーバ１０６が供給するセッションキーを用いて、アプリケーション・サーバ１０６によって暗号化されている。

クライアント１０２は、コンテンツを受信し、コンテンツを解読し、コンテンツを処理し利用し始める。一実施形態では、クライアント１０２は許可データのコピーを有しているので、クライアントは、受信したコンテンツおよび／またはサービスの正規使用を判断することができる。例えば、クライアント１０２は、許可データをチェックすることにより、クライアントはコンテンツのコピーを格納または保存することを許可されているか否か判断することができる。許可モジュール１２２は、許可データをチェックし、クライアントの許可を判断することができる。クライアントが許可されている場合、クライアントは、受信し解読したコンテンツを保存することができる。加えて、クライアントは許可データのコピーを有しているので、クライアント１０２は、一実施形態では許可モジュール１２２によって、更にクライアントは１回よりも多くコンテンツを再生または再使用できるか否かの許可を、チェックによって判断することができる。許可モジュール１２２は、通常、コンテンツ解読キーを格納しており、適正な許可がなければ、コンテンツを解読することを拒絶する。クライアントの許可を判断する能力を得るには、クライアント１０２がＴＧＳ＿ＲＥＰメッセージにおいて受信しその内部で使用するために格納してある、許可データの第２コピーを利用する。これによって、クライアントの動作が改善し、ネットワークを通じた通信を抑制する。

一実施形態では、システム１００では、クライアントがＳＴチケットおよび許可データのクライアント・コピーを取得するためには、ＴＧＳ＿ＲＥＱおよびＴＧＳ＿ＲＥＰの交換を行う必要がない。クライアント１０２は、特定のサーバ、例えば、ＡＳサーバ１０８に、サービス・チケットのためにＡＳ＿ＲＥＱを提出する。ＫＤＣ１０４はＡＳ＿ＲＥＱを処理し、最初のアプリケーション・サーバのための許可データの第１コピーを含むＳＴチケットを返す。更に、ＫＤＣは、許可データの第２コピーをクライアントに送る。前記許可データの第２コピーは、クライアント１０２がアクセスし利用するようにフォーマットされている。通常、ＫＤＣ１０４が返送するＡＳ＿ＲＥＰは、許可データの第１コピーを有するＳＴチケット、および許可データのクライアント・コピーを含む。したがって、クライアントは、ＴＧＳ＿ＲＥＱを提出しなくても、ＳＴチケットと共に、許可データのクライアント・コピーを取得し続ける。

図２は、本発明の一実施形態の一実施態様によるシステム１０１の簡略ブロック図を示す。一実施形態では、クライアント１０２は第三者サーバ１４０にアクセスして所望のコンテンツおよび／またはサービスを選択し、次いでアプリケーション・サーバ１０６にアクセスして、選択したコンテンツおよび／またはサービスを実際に受信する。コンテンツおよび／サービスを選択する際、クライアント１０２は許可データのクライアント・コピーを利用する。コンテンツおよび／またはサービスの選択を第三者サーバ１４０に提出する前に、クライアントは、所望のコンテンツおよび／またはサービスを決めておき、次いで許可データのクライアント・コピーをチェックして、クライアントの許可を超過する選択を行うことを回避する。次いで、クライアント１０２は、コンテンツおよび／またはサービス選択を第三者サーバ１４０に送る。すると、第三者サーバ１４０は、コンテンツ
および／またはサービス選択を検証し、コンテンツおよび／サービス選択回答メッセージをクライアント１０２に送る。コンテンツおよび／サービス選択回答メッセージには、アプリケーション・サーバ１０６がクライアントに許可し、クライアントに選択したコンテンツおよび／またはサービスに対するアクセスを行わせるための情報が含まれている。このように、アプリケーション・サーバが第三者サーバの情報に基づいてクライアントの許可を決定しようとする場合に、クライアント１０２は、許可データを参照し、アプリケーション・サーバによって後であっさり拒絶される第三者サーバ１０４からのコンテンツおよび／またはサービスの許可を要求することを避ける。

一実施形態では、第三者サーバ１４０は、更に、第三者情報の認証も含む。この認証は、付加的に、クライアント１０２によって、通常ＫＥＹ＿ＲＥＱメッセージ内でアプリケーション・サーバ１０６に転送される。アプリケーション・サーバ１０６は、この認証を利用して、クライアント１０２によってアプリケーション・サーバに供給された第三者サーバ情報を認証し、クライアントを許可するために使用する情報が、実際に第三者サーバ１０４からクライアントに供給されたのであり、他の何らかのネットワーク・エンティティから供給されたものではなく、あるいはクライアントによって生成された何らかの偽造情報ではないことを確認する。

ＫＥＹ＿ＲＥＱメッセージをアプリケーション・サーバ１０６に提出する際、クライアント１０２は、第三者サーバ情報と、クライアントに供給された場合には、認証を含ませる。アプリケーション・サーバ１０６は、ＫＥＹ＿ＲＥＱメッセージを処理し、第三者サーバ情報を認証し、この情報を利用してクライアントの許可を検証する。一旦、認証し検証したなら、アプリケーション・サーバ１０６は前述のようにＫＥＹ＿ＲＥＰを生成する。

図３を参照すると、アプリケーション・サーバからのコンテンツおよび／またはサーバを要求し使用するときに、クライアントが用いる、許可データの第２コピーをクライアントに供給する方法２００のフロー・チャートが示されている。一例として、方法２００は、システム１００および前述の適切なメッセージ・タイプによって実現することができる。ステップ２０２において、クライアント１０２のようなクライアントから、ＴＧＴチケットの要求を受信する。ステップ２０４において、ＴＧＴチケットを生成する。ステップ２０４は、例えば、ＡＳサーバ１０８によって実行することができる。ステップ２０６において、ＴＧＴチケットをクライアントに送る。このステップも、ＡＳサーバ１０８によって実行することができる。一実施形態では、クライアントは、許可データのクライアント・コピーがＡＳ＿ＲＥＰに含まれている場合、許可データのクライアント・コピーを抽出する。ステップ２０８において、特定のアプリケーションに向けたＳＴチケットの要求をクライアントから受信する。ＳＴチケットの要求は、ＴＧＴチケットを含み、通常では、クライアントの身元を平文では表示しない。ステップ２１０において、ＴＧＳ＿ＲＥＰメッセージを生成する。このメッセージは、ＳＴチケット内で暗号化された許可データの第１コピーと、ＴＧＴチケットからのセッションキーを用いて暗号化した許可データの第２コピーとを含む。一実施形態では、ＴＧＳ＿ＲＥＰの生成は、ＴＧＳサーバ１１０によって行われる。ステップ２１２において、ＴＧＳ＿ＲＥＰメッセージを、許可データの両コピーと共に、クライアントに送る。このステップもＴＧＳサーバ１１０によって実行することができる。ステップ２１４において、クライアントはＴＧＳ＿ＲＥＰを受信する。ステップ２１６において、クライアントはＴＧＳ＿ＲＥＰから、少なくとも許可データの第２コピーを抽出する。ステップ２２０において、クライアントは、ＳＴチケットを含むＫＥＹ＿ＲＥＱメッセージを生成し送る。これは、更に、許可データの第１コピーも含む。ステップ２２２において、アプリケーション・サーバはＫＥＹ＿ＲＥＱを受信し処理する。アプリケーション・サーバは、ＳＴチケットを抽出し、ＳＴチケットを解読し、許可データの第１コピーの有効性を判断する。ステップ２２４において、アプリケーション・サーバは、ＫＥＹ＿ＲＥＰを生成し、ＫＥＹ＿ＲＥＰをクライアントに送信する。ステップ２２６において、クライアントはＫＥＹ＿ＲＥＰメッセージを検証し、これをＫＥＹ＿ＲＥＱメッセージと照合する。

図４は、図３に示したプロセス２００と同様の、プロセス２４０の一実施態様の簡略フロー図を示す。ステップ２４２において、クライアントはＴＧＴチケット要求を送る。ステップ２４４において、ＫＤＣ１０４はＴＧＴチケットを生成する。ステップ２４６において、ＫＤＣ１０４は、クライアント許可データのクライアント・コピーと共にＴＧＴチケットを送る。ステップ２４８において、クライアントはＴＧＴチケットを受信し、許可データのクライアント・コピー全体を抽出する。ステップ２５０において、クライアント１０２は、ＳＴチケットを要求するＴＧＳ＿ＲＥＱを送る。ステップ２５２において、ＫＤＣはＴＧＳ＿ＲＥＰを返送する。ステップ２５４において、クライアントはＴＧＳ＿ＲＥＰを受信し、ＳＴチケットおよび許可データのサーバ特定の第２コピーを抽出する。ステップ２５６において、クライアントは、所望のコンテンツおよび／またはサービスを決定し、許可データのクライアント・コピーにアクセスし、所望のコンテンツおよび／またはサービスを検証して、許可を超過したコンテンツおよび／またはサービスを要求するのを回避する。ステップ２５８において、クライアント１０２は、コンテンツおよびサービス選択を第三者サーバ１４０に提出する。ステップ２６０において、第三者サーバは、クライアントを許可するために用いられる第三者情報、およびこの情報の認証（例えば、キー付きチェックサム）を含む、コンテンツおよび／またはサービス選択回答を送る。第三者情報は、クライアントの認証を検証するために用いることができる情報、例えば、クライアントによって選択されたコンテンツの識別、「クレジット・カードへの課金」、「ユーザにこのコンテンツを保存させる」というような、コンテンツに付随する種々の購入オプション、およびその他のかかる情報を含む。また、第三者情報は、ブラックアウト領域（例えば、国、州、郵便番号に基づくブラックアウト領域）およびその他のかかる制約のリストのような、コンテンツに付随する制約も含むことができる。ステップ２６２において、クライアント１０２は、許可データを超過しないＫＥＹ＿ＲＥＱメッセージをアプリケーション・サーバ１０６に送る。ＫＥＹ＿ＲＥＱメッセージは、第三者情報をその認証およびＳＴチケットと共に含み、ＳＴチケットは更に許可データの第１コピーも含む。ステップ２６４において、アプリケーション・サーバ１０６は、情報を認証し、第三者情報および許可データの第１コピーを用いてコンテンツおよび／またはサービスに対するクライアントの許可を検証する。ステップ２６６において、アプリケーション・サーバ１０６はＫＥＹ＿ＲＥＰをクライアント１０２に送る。

図５は、クライアントがアプリケーション・サーバからのコンテンツおよび／またはサービスを要求し受信するためのプロセス３１０の一実施態様の簡略フロー図を示す。一実施形態では、プロセス３１０は、図３に示すプロセス２００のステップ２２６を踏襲して、許可データの第２コピーをクライアントに供給する。ステップ３１２において、クライアント１０２のようなクライアントは、所望のコンテンツおよび／サービスを決定する。例えば、クライアントは、ユーザまたは他のネットワーク・エンティティから、コンテンツに対する要求を受信する。ステップ３１４において、クライアントは、コンテンツおよび／またはサービスの要求を検証して、コンテンツに対する要求をチェックし、以前に取得し格納されている許可データの第２コピーと比較することによって、要求が許可されており、正規使用を超過しないことを確認する。一旦クライアントが要求を検証したなら、クライアントはＣＯＮ＿ＲＥＱメッセージを生成する。ステップ３１６において、クライアントは、ＣＯＮ＿ＲＥＱメッセージを、暗号化し、キー付きチェックサムで認証し、アプリケーション・サーバ１０６（または第三者サーバ１４０）のようなアプリケーション・サーバに送る。ステップ３２０において、アプリケーション・サーバはＣＯＮ＿ＲＥＱメッセージを解読し、キー付きチェックサム、およびＳＴチケット内にある許可データの第１コピーにおいて規定されているクライアントの許可アクセスに基づいて、要求の有効性を判断する。ステップ３２２において、アプリケーション・サーバは、ＳＴチケットおよび許可データの有効性が判断された場合、要求されたコンテンツ、および／
またはサービスを暗号化して送る。一実施形態では、アプリケーション・サーバは、要求コンテンツを複数の異なるパケットに入れて送り、所望のコンテンツ全体が単一のパケットには含まれず、数個のパケットに含まれるようにする。ステップ３２４において、クライアントは、要求したコンテンツを受信し、データを処理する。ステップ３３０において、クライアントは、格納してある許可データの第２コピーにアクセスし、クライアントが当該コンテンツおよび／またはサービスのコピーを格納できるか否か判定を行う。ステップ３３２において、クライアントがコンテンツおよび／またはサービスを格納することを許可されている場合には、クライアントはコンテンツおよび／またはサービスを格納する。許可されていない場合には、クライアントは、コンテンツが初めて受信されたとき、コンテンツにアクセスすることを許可され、次いでプロセスはステップ３４０に進み、追加のコンテンツを探す。それ以外の場合、ステップ３３４に進み、クライアントは、コンテンツを１回よりも多く再生することが可能であるかを判定する。可能である場合、ステップ３３６に進み、クライアントは、１回以上コンテンツにアクセスし再生することができる。ステップ３４０において、プロセスは、受信するコンテンツおよび／またはサービスが未だあるか否か判定を行う。ある場合には、プロセス３１０はステップ３２４に戻り、追加のコンテンツおよび／またはサービスを受信する。ステップ３３６において、それ以上データおよび／またはコンテンツがないと判断した場合、プロセス３１０は終了する。

本発明は、クライアントが、許可データの自身のコピーを格納しアクセスすることを可能にする方法、システム、装置、プログラム、およびコンピュータ・プログラム生産物を提供する。これによって、ユーザ・インターフェースが改良され、エラーが減少し、コンテンツおよび／またはサービス配信の効率が向上し最適化する。更に、クライアントに許可データの自身のコピーにアクセスさせることによって、クライアントは、配信されるコンテンツおよび／またはサービスの処理および利用に関して判断を下すことが可能となる。更にまた、必要な通信量が減少し、全体的なネットワーク・トラフィックが減少する。一実施形態では、本発明は、モトローラ社（Ｍｏｔｏｒｏｌａ，Ｉｎｃ）が開発した電子セキュリティ・ブローカ（ＥＳＢｒｏｋｅｒ）プロトコル、および同様にモトローラ社が開発したＩＰ権利管理システムの一部として実装される。

以上、ここに開示した発明は、具体的な実施形態およびそお応用を通じて説明したが、特許請求の範囲に明記されている本発明の範囲から逸脱することなく、多数の変更や変更も当業者には可能である。

本発明の一実施形態にしたがって構成したシステムの簡略ブロック図。 本発明の一実施形態の一実施態様によるシステムの簡略ブロック図。 クライアントが用いるために、許可データの第２コピーをクライアントに供給する方法のフロー図。 図３に示したプロセスと同様のプロセスの一実施形態の簡略フロー図。 クライアントがコンテンツおよび／またはサービスを要求し、アプリケーション・サーバから受信するプロセスの一実施形態の簡略フロー図。

Claims (10)

1. クライアント（１０２）がアプリケーションサーバ（１０６）からのコンテンツとサービスのうちの少なくとも一方を要求する場合に、前記クライアント（１０２）による前記コンテンツの正規使用または前記クライアント（１０２）による前記サービスの正規使用を前記クライアント（１０２）が検証する検証方法であって、前記クライアント（１０２）にはキー配布局（１０４）から予めチケット付与チケットが提供され、前記検証方法は、
   前記チケット付与チケットを含むサービスチケット要求を、前記キー配布局（１０４）が前記クライアント（１０２）から受信するステップと；
   前記サービスチケット要求を受信した前記キー配布局（１０４）が、許可データの第１コピーを含むサービスチケットを生成するサービスチケット生成ステップであって、前記許可データの第２コピーは前記サービスチケットには含まれず、前記クライアント（１０２）による前記コンテンツの正規使用又は前記クライアント（１０２）による前記サービスの正規使用を前記クライアントが前記第２コピーを用いることによって検証できるように前記第２コピーは構成されていることと；
   前記第２コピーを前記キー配布局（１０４）が暗号化する第２コピー暗号化ステップと；
   前記サービスチケットと暗号化済みの前記第２コピーとを、前記キー配布局（１０４）が前記クライアント（１０２）に送信するサービスチケット送信ステップと
   を備えることを特徴とする、検証方法。
2. 前記サービスチケット生成ステップでは、前記サービスチケットと前記第２コピーとを含むチケット付与サーバ回答メッセージ（ＴＧＳ＿ＲＥＰメッセージ）が、前記キー配布局（１０４）によって生成される、
   請求項１記載の検証方法。
3. 前記サービスチケット送信ステップでは、前記チケット付与サーバ回答メッセージ（ＴＧＳ＿ＲＥＰメッセージ）が、前記キー配布局（１０４）から前記クライアントに送信される、
   請求項２記載の検証方法。
4. 前記第２コピー暗号化ステップでは、前記キー配布局（１０４）がクライアントセッションキーを用いて前記第２コピーを暗号化する、
   請求項１記載の検証方法。
5. 前記クライアントセッションキーは、前記チケット付与チケットから得られる、
   請求項４記載の検証方法。
6. 前記検証方法は更に、前記キー配布局（１０４）がサーバキーを用いて前記サービスチケットを暗号化するステップを備える、
   請求項１記載の検証方法。
7. 前記検証方法は更に、前記クライアント（１０２）によって：
   前記アプリケーションサーバに前記クライアント（１０２）が要求する所望コンテンツを決定するステップと；
   前記クライアント（１０２）による正規使用を前記所望コンテンツが超過していないことを、前記第２コピーを用いて検証するステップと；
   前記所望コンテンツが前記正規使用を超過していないことが検証された場合に、前記所望コンテンツに対する要求であるコンテンツ要求を生成するステップと；
   前記コンテンツ要求を第三者サーバに送信するステップと
   を備え、
   前記検証方法はその後に更に、
   前記正規使用を前記所望コンテンツが超過していないことを前記アプリケーションサーバ（１０６）が判定するために前記アプリケーションサーバ（１０６）によって使用される第三者情報を、前記第三者サーバ（１４０）が前記クライアント（１０２）に送信するステップを備える、
   請求項１記載の検証方法。
8. 前記検証方法は更に、前記アプリケーションサーバ（１０６）によって：
   前記サービスチケット送信ステップ後の前記クライアント（１０２）からキー要求メッセージを受信するステップと；
   キー回答メッセージを生成するステップと；
   前記キー回答メッセージを前記クライアント（１０２）に転送するステップと
   を備え、
   前記検証方法は更に、前記前記キー回答メッセージを受信した前記クライアント（１０２）によって：
   前記コンテンツに対する要求を生成するステップと；
   前記第２コピーを用いて、前記コンテンツに対する前記要求を検証するステップと；
   前記コンテンツに対する前記要求に誤りがないことを検証した場合、前記コンテンツに対する前記要求を前記アプリケーションサーバ（１０６）に送信するステップと
   を備える、
   請求項１記載の検証方法。
9. クライアント（１０２）とキー配布局（１０４）を有する通信提供システムであって、前記クライアント（１０２）がアプリケーションサーバ（１０６）からのコンテンツとサービスのうちの少なくとも一方を要求する場合に、前記クライアント（１０２）による前記コンテンツの正規使用と前記クライアント（１０２）による前記サービスの正規使用を前記クライアント（１０２）が検証するように前記通信提供システムは構成され、前記クライアント（１０２）には前記キー配布局（１０４）から予めチケット付与チケットが提供され、
   前記キー配布局（１０４）は、前記チケット付与チケットを含むサービスチケット要求を、前記クライアント（１０２）から受信し；許可データの第１コピーを含むサービスチケットを生成し；前記サービスチケットには含まれない前記許可データの第２コピーを暗号化し；前記サービスチケットと暗号化済みの前記第２コピーとを、前記クライアント（１０２）に送信するように構成され、
   前記クライアント（１０２）による前記コンテンツの正規使用または前記クライアント（１０２）による前記サービスの正規使用を、前記クライアントが前記第２コピーを用いて検証できるように前記第２コピーは構成されていることを特徴とする、通信提供システム。
10. 前記クライアント（１０２）は、前記サービスチケットと前記第２コピーとを含むチケット付与サーバ回答を前記キー配布局（１０４）から受信するように構成される、
    請求項９記載の通信提供システム。

Images