(57)【要約】クライアント（１０２）に、当該クライアントがアクセスし使用できる許可データのコピーを供給する方法およびシステムを提供する。本方法は、チケットの概念を利用するキー管理プロトコルに非常に適している。許可データの２つのコピー、即ち、クライアント・コピーおよびサーバ・コピーが内部含まれ、クライアントに転送される。そのクライアントは特定のアプリケーション・サーバ（１０６）にチケットを要求している。クライアントは、許可データのクライアント・コピーにアクセスすることができ、クライアントは要求を検証し、要求したコンテンツおよび／またはサービスに対する使用の許可を判断することができるようにしている。
2005517347.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーション・サーバからのコンテンツおよびサービスの少なくともいずれかを要求するときに、クライアント許可を検証する方法であって、
許可データの第１コピーを含むサービス・チケットを生成するステップと、
前記許可データの第２コピーをクライアントに送信するステップと、
前記サービス・チケットを前記クライアントに送信するステップと、
を含む方法。
【請求項２】
請求項１記載の方法であって、
前記サービス・チケットと、前記許可データの第２コピーとを含むＡＳ＿ＲＥＰを生成するステップと、
前記ＡＳ＿ＲＥＰを前記クライアントに送信するステップと、
を更に含む、方法。
【請求項３】
請求項１記載の方法であって、
前記サービス・チケットを含むチケット付与サーバ回答（ＴＧＳ＿ＲＥＰ）を更に生成するステップと、
前記チケット付与サーバ回答を前記クライアントに送信するステップと、
更にを含む、方法。
【請求項４】
請求項３記載の方法であって、
クライアントから認証サーバ要求（ＡＳ＿ＲＥＱ）メッセージを受信するステップと、
認証サーバ回答（ＡＳ＿ＲＥＰ）メッセージを生成するステップと、
前記ＡＳ＿ＲＥＰを前記クライアントに送信するステップと、
前記クライアントからチケット付与サーバ要求（ＴＧＲ＿ＲＥＱ）メッセージを受信するステップとを更に含み、
前記ＲＧＲ＿ＲＥＰを生成するステップは、前記許可データの第２コピーを含む許可データの２つ以上のコピーを有するＴＧＳ＿ＲＥＰを生成することを含む、方法。
【請求項５】
請求項３記載の方法であって、
前記許可データの第２コピーを含む認証サーバ回答（ＡＳ＿ＲＥＰ）メッセージを生成するステップと、
ＡＳ＿ＲＥＰを前記クライアントに送信するステップであって、前記許可データの第２コピーを前記クライアントに送信するステップを含むステップとを更に含む、方法。
【請求項６】
請求項３記載の方法であって、
前記許可データの第２コピーが前記クライアントによって用いられるように、前記許可データの第２コピーを構成するステップを更に含む、方法。
【請求項７】
請求項６記載の方法であって、
クライアント・セッションキーを用いて、前記許可データの第２コピーを暗号化するステップを更に含む、方法。
【請求項８】
請求項７記載の方法であって、
サーバ・サービスキーを用いて、前記サービス・チケットを暗号化するステップを更に含む、方法。
【請求項９】
請求項７記載の方法において、前記クライアント・セッションキーを用いて暗号化するステップは、ＡＳ＿ＲＥＰにおけるチケット付与チケットからの前記セッションキーを用
いることを含む、方法。
【請求項１０】
請求項６記載の方法であって、
前記クライアントが所望のコンテンツを決定するステップと、
前記クライアントが、前記許可データの第２コピーによって、前記所望のコンテンツを検証するステップと、
前記クライアントがコンテンツに対する要求を生成するステップと、
前記クライアントが前記コンテンツに対する要求を第三者サーバに送信するステップと、
前記アプリケーション・サーバが前記要求されたコンテンツに対するクライアントの許可を判定する際に後に用いる第三者情報を、前記第三者サーバが前記クライアントに送信するステップと、
を更に含む、方法。
【請求項１１】
請求項６記載の方法において、
前記クライアントからキー要求（ＫＥＹ＿ＲＥＱ）を受信するステップと、
キー回答（ＫＥＹ＿ＲＥＰ）を生成するステップと、
前記ＫＥＹ＿ＲＥＰを前記クライアントに転送するステップと、
前記クライアントがコンテンツに対する要求を生成するステップと、
前記クライアントが、前記許可データの第２コピーによって、前記コンテンツに対する要求を検証するステップと、
前記クライアントが、前記コンテンツに対する要求に誤りがないことを検証した場合、前記クライアントが前記コンテンツに対する要求をアプリケーション・サーバに送信するステップと、
を更に含む、方法。
【請求項１２】
請求項６記載の方法であって、
コンテンツに対する要求を受信するステップと、
前記要求されたコンテンツの少なくとも一部を前記クライアントに送信するステップとを更に含み、
前記許可データの第２コピーを構成するステップは、前記クライアントが前記許可の第２コピーを用いて、前記要求したコンテンツの少なくとも許可された使用を判断することができるように、前記許可データの第２コピーを構成することを含む、方法。
【請求項１３】
請求項１２記載の方法であって、
前記クライアントが、前記許可の第２コピーを用いて、当該クライアントが前記要求したコンテンツを格納することを許可されているかを判定できるように、前記許可データの第２コピーを構成するステップを更に含む、方法。
【請求項１４】
請求項１３記載の方法であって、
前記クライアントが、前記許可の第２コピーを用いて、当該クライアントが前記要求したコンテンツを再生することを許可されているかを判定できるように、前記許可データの第２コピーを構成するステップを更に含む、方法。
【請求項１５】
システムを通じて安全な通信を提供するシステムであって、
チケット付与チケット（ＴＧＴ）をクライアントに発行するように構成されているキー配布局（ＫＤＣ）の第１ステージと、
前記クライアントから受信したＴＧＴに応答して、許可データの少なくとも２つのコピーを含むチケット付与サーバ回答を生成するように構成されているＫＤＣの第２ステージと、
を備えているシステム。
【請求項１６】
請求項１５記載のシステムにおいて、
前記クライアントは、前記チケット付与サーバ回答を受信し、前記許可データの一方のコピーを利用して許可を検証するように構成されている、システム。
【請求項１７】
請求項１５記載のシステムにおいて、
前記クライアントはアプリケーション・サーバと結合されており、該アプリケーション・サーバは、前記クライアントにコンテンツを供給するように構成されており、
前記クライアントは、更に、前記許可データの一方のコピーを用いて、前記コンテンツの許可された使用を検証するように構成されている、
システム。
【請求項１８】
コンテンツおよびサービスの少なくともいずれかへのアクセスをクライアントに提供するシステムであって、
許可データの第１コピーを含むサービス・チケットを生成する手段と、
前記サービス・チケットと、前記許可データの第２コピーとを含むチケット付与サーバ回答を生成する手段と、
前記チケット付与サーバ回答をクライアントに送信する手段と、
を備えている、システム。
【請求項１９】
請求項１８記載のシステムにおいて、前記チケット付与サーバ回答を生成する手段は、前記許可データの少なくとも前記第２コピーを、クライアント・セッションキーを用いて暗号化する手段を含む、システム。
【請求項２０】
請求項１９記載のシステムにおいて、前記少なくとも第２許可データを暗号化する手段は、前記クライアントが、前記許可データの第２コピーを解読して利用できるように、前記許可データの少なくとも前記第２コピーを暗号化する手段を含む、システム。
【請求項２１】
請求項２０記載のシステムにおいて、前記サービス・チケットを生成する手段は、前記許可データの少なくとも前記第１コピーを、サーバキーを用いて、暗号化する手段を含む、システム。
【請求項２２】
請求項１８記載のシステムにおいて、前記許可データの第２コピーは、前記クライアントが、アプリケーション・サーバからのサービスに対する要求を検証できるように構成されている、システム。
【請求項２３】
請求項１８記載のシステムにおいて、前記許可データの第２コピーは、前記クライアントが、受信したコンテンツに許可されている使用を判断できるように構成されている、システム。
【請求項２４】
システムを通じて安全な通信を提供するシステムであって、
チケット付与チケット（ＴＧＴ）と、許可データの少なくともクライアント・コピーとを、クライアントに発行するように構成されているキー配布局（ＫＤＣ）の第１ステージであって、前記クライアントがクライアントの許可を判断できるように、前記許可データのクライアント・コピーを構成する、ＫＤＣ第１ステージと、
チケット付与サーバ回答を生成するように構成されているＫＤＣ第２ステージと、
を備えている、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、ネットワークのセキュリティに関し、更に特定すれば、アプリケーション・サーバからのコンテンツを要求するときに、クライアントのプライバシを保護する方法およびシステムに関する。
【背景技術】
【０００２】
インターネットは安全性が低いネットワークである。ネットワーク上で用いられているプロトコルの多くは、セキュリティを全く設けていない。暗号化またはその他の何らかの形式のセキュリティ方式を用いずにインターネット上で送信されるデータは、「平文」で送信すると言われる。平文でインターネット上で送信される、パスワード、クレジット・カード番号、顧客の身元および氏名等のようなデータを、ハッカーが「かぎつける」ことができるようにするツールは、容易に入手することができる。したがって、暗号化しないデータをインターネット上で送信するアプリケーションは、被害を受ける虞れが非常に高い。
【０００３】
ケルベロス（Ｋｅｒｂｅｒｏｓ）は、秘密キー暗号法を用いることによって、クライアント／サーバ・アプリケーションの認証を行うように設計された、公知のネットワーク認証プロトコルの一例である。ケルベロス（Ｋｅｒｂｅｒｏｓ）プロトコルは、マサチューセッツ工科大学から入手可能であり、暗号法を用いて、クライアントがその身元をサーバに（またはその逆）、安全性の低いネットワーク接続を通じて立証することができると言われている。クライアントおよびサーバがケルベロス（Ｋｅｒｂｅｒｏｓ）を用いてそれぞれの身元を証明した後、その通信全てを暗号化することもでき、彼らがその業務を遂行する際に、プライバシおよびデータ保全性を保証すると言われている。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明は、ネットワーク・セキュリティの分野に関するこれらおよびその他の背景情報要因に関連してなされた。
【課題を解決するための手段】
【０００５】
本発明は、クライアントに、当該クライアントがアクセスし利用することができる許可データのコピーを供給する方法を提供する。本方法は、クライアントから認証サーバ要求（ＡＳ＿ＲＥＱ）メッセージを受信するステップと、認証サーバ回答（ＡＳ＿ＲＥＰ）メッセージを生成するステップと、ＡＳ＿ＲＥＰをクライアントに送信するステップと、クライアントからチケット付与サーバ要求（ＴＧＳ＿ＲＥＱ）メッセージを受信するステップと、許可データの２つのコピーを有するチケット付与サーバ回答（ＴＧＳ＿ＲＥＰ）メッセージを生成するステップと、ＴＧＳ＿ＲＥＰを許可データの２つのコピーと共にクライアントに送信するステップとを含む。
【０００６】
別の実施形態では、本発明は、許可データの第１コピーを含むサーバ・チケットを生成するステップと、サーバ・チケットを含むチケット付与サーバ回答を生成するステップと、チケット付与サーバ回答および許可データの第２コピーをクライアントに送信するステップとを含む。一実施形態では、許可データの第２コピーを送信するステップは、クライアントが許可データの第２コピーを解読して利用できるように、クライアント・セッションキーを用いて許可データの少なくとも第２コピーを暗号化することを含み、サービス・チケットを生成するステップは、サーバキーを用いて、少なくとも第１許可データを暗号
化することを含む。
【０００７】
別の実施形態では、本発明は、アプリケーション・サーバからのコンテンツを要求するときに、クライアントのプライバシ保護を確保するシステムであることを特徴とすることができる。このシステムは、許可データの少なくとも２つのコピーを含むチケット付与サーバ回答を生成するように構成されたキー配布局を含み、キー配布局は、チケット付与サーバ回答を受信し、許可データの一方のコピーを利用して許可を検証するように構成されているクライアントと結合されており、クライアントはコンテンツをクライアントに供給するように構成されたアプリケーションサーバに結合されている。クライアントは、更に、許可データの一方のコピーを用いて、コンテンツの許可された使用を検証するように構成されている。
【０００８】
別の実施形態では、本発明は、クライアントにコンテンツおよびサービスの少なくともいずれかへのアクセスを与えるシステムであることを特徴とする。このシステムは、許可データの第１コピーを含むサービス・チケットを生成する手段と、サービス・チケットと、許可データの第２コピーとを含むチケット付与サーバ回答を生成する手段と、チケット付与サーバ回答をクライアントに送信する手段とを含む。チケット付与サーバ回答を生成する手段は、クライアント・セッションキーを用いて、許可データの少なくとも第２コピーを暗号化する手段を含むことができる。少なくとも第２許可データを暗号化する手段は、クライアントが許可データの第２コピーを解読し利用できるように、許可データの少なくとも第２コピーを暗号化する手段を含むことができる。サービス・チケットを生成する手段は、サーバキーを用いて、許可データの少なくとも第１コピーを暗号化する手段を含むことができる。許可データの第２コピーは、クライアントが、アプリケーション・サーバからのサービスに対する要求を検証できるように、構成することができる。許可データの第２コピーは、クライアントが、受信したコンテンツの許可されている使用を判断できるように構成することができる。
【０００９】
本発明の特徴および利点は、以下の発明の説明、および本発明の原理を利用した例示的実施形態を明記する添付図面を参照することによって、一層深く理解されよう。
本発明の前述のおよびその他の態様、特徴ならびに利点は、以下の図面に関連付けて示した、以下の更に特定的な発明の説明から更に明らかとなろう。
【００１０】
対応する参照符号は、図面における種々の図全てを通じて対応する構成要素を示すこととする。
【発明を実施するための最良の形態】
【００１１】
ケルベロス（Ｋｅｒｂｅｒｏｓ）は、クライアントまたはサーバのようなネットワークのエンティティは、アプリケーション・サーバが供給するサービスおよび／またはコンテンツにアクセスするために、アプリケーション・サーバに提出した許可データを検証することができないという不都合を有している。部分的に、許可データは、クライアントに供給されるであろうサービスおよび／またはコンテンツの範囲を規定する。多くの場合、許可データは、アプリケーション・サーバ１０６ならびに当該アプリケーション・サーバ１０６が提供するコンテンツおよび／またはサービスに特定的である。クライアントは許可を検証することができないので、クライアントはコンテンツに対する要求をチェックして、許可されていないオプションが選択されていないことを確認することができない。加えて、クライアントは許可データを検証することができないので、クライアントは、当該クライアントに配信されるコンテンツをコピーすることがクライアントに許可されているか否か判断するためには、余分な通信および情報が必要となる。この結果、エラーが生じ、ネットワーク・トラフィックが過剰となり、ネットワーク資源および処理が無駄に使われることになる。更にまた、クライアントは許可データを検証することができないので、ク
ライアントは、余分な通信および情報を受信せずには、例えば、コンテンツを１回よりも多く再生することがクライアントに許可されているか否か判断することができない。
【００１２】
本発明は、許可データのコピーをクライアントに配信することによって、上記およびその他の欠点を克服する方法およびシステムを提供する。クライアントは、前記許可データのコピーにアクセスして利用し、ネットワーク効率を高め、ネットワーク・トラフィックを削減し、コンテンツおよび／またはサービスのアクセスや使用を合理化することを可能にする。許可データのクライアント・コピーをクライアントに供給することによって、クライアントは要求を検証し、コンテンツ要求の中に違法なオプションが含まれることを回避することができ、配信されたコンテンツおよび／またはサービスにおけるクライアントが許可された使用を判断し、例えば、配信されたコンテンツのコピーを保存することができるか、およびコンテンツを１回よりも多く再生することができるかについて判断することができる、
本発明は、チケットの概念を利用するキー管理プロトコルに非常に適している。チケットとは、対称キーで暗号化した認証トークンであり、対称キーによってクライアントは特定のサーバに認証することができる。本発明の一実施形態によれば、キー配布局（ＫＤＣ）がサービス・チケットをクライアント、サーバ、またはネットワークのその他のエンティティに転送するとき、サービス・チケット内に２つの許可データのコピーを含む。許可のコピーの一方、すなわち、クライアント・コピーは、クライアントによる使用を目的として、クライアント（サーバまたはその他のエンティティ）が許可データにアクセスすることができる。許可データのコピーのもう一方、すなわち、サーバ・データは、クライアントからのコンテンツ選択および／またはキー要求と共に、アプリケーション・サーバに供給される。本発明は、アプリケーション・サーバによって提供されるコンテンツおよび／またはサービスに対するアクセスを得ようとするクライアントまたはサーバによって、アクセスされ使用される許可データのコピーを供給することによって、標準的なケルベロス（Ｋｅｒｂｅｒｏｓ）およびその他の以前のプロトコルの不都合を解消する。
【００１３】
図１を参照すると、本発明の一実施形態にしたがって構成した、安全な通信を行うシステム１００の簡略ブロック図が示されている。本発明の可能な一実施態様の一例を含むシステム１００は、インターネット、イントラネットまたはその他のネットワークのような、ネットワーク上でセキュリティおよびプライバシを確保する認証キー管理プロトコルを用いる。これは、百万人単位のユーザに拡大することができる。概略的に、システム１００は、公開キーアルドリズムおよび対称キーアルゴリズムの双方を用いて、１つ以上の中央キー配布局（ＫＤＣ）１０４と対話し、かつ対称キーアルゴリズムを用いて、アプリケーション・サーバ１０６（および第三者サーバ１４０、図２参照）のような、個々のアプリケーション・サーバと対話する少なくとも１つのクライアント１０２を含む。プロトコルは汎用的であり、分散環境において認証を要求する異なるアプリケーションに容易に改造することができる。更に、集中管理ユーザ・データベースとインターフェースされ得る。
【００１４】
クライアント１０２は、ユーザに代わってネットワーク・サービスを利用するプロセス、アプリケーション、またはデバイスを含み得る。一例として、クライアント１０２は、任意の種類のコンピュータからなってもよいし、あるいはクライアント１０２は、ワイヤレス電話機、ページャ（小型無線呼出機）、携帯端末（ＰＤＡ）、ローエンドのマイクロプロセッサを有する家電製品、または処理能力が低いかまたは限られているその他の実質的に任意の装置からなってもよい。尚、場合によっては、サーバ自身がある他のサーバのクライアントにもなり得る（例えば、プリント・サーバはファイル・サーバのクライアントである場合もある）ことを注記しておく。
【００１５】
アプリケーション・サーバ１０６は、ネットワーク・クライアントに資源を提供する。
例示する実施形態では、ＫＤＣ１０４は、第１ステージ１０８および第２ステージ１１０を含む。一実施形態では、第１ステージは認証サーバ（ＡＳサーバ）１０８であり、第２ステージはチケット付与サーバ（ＴＧＳサーバ）１１０である。ＡＳサーバ１０８は、クライアント１０２の信用証明書(credential)を検証した後に、チケット付与チケット（ＴＧＴチケット）をクライアント１０２に発行する。ＴＧＳサーバ１１０は、アプリケーション・サーバ・サービス・チケット（ＳＴチケット）をクライアント１０２に供給する。ＳＴチケットは、クライアント１０２がサービスを要求するときに、クライアントがアプリケーション・サーバ１０６に提示する最終サービス・チケットである。アプリケーション・サーバ１０６は、クライアント１０２がＳＴチケットを用いて自身を認証したときに、種々のサービスをクライアント１０２に提供する。
【００１６】
システム１００が用いる基本的なメッセージ・タイプは以下の通りである。
（Ａ）認証サーバ要求メッセージ（ＡＳ＿ＲＥＱ）：ＡＳサーバ１０８からのＴＧＴチケットを要求するためのクライアント１０２からのメッセージ。
【００１７】
（Ｂ）認証サーバ回答メッセージ（ＡＳ＿ＲＥＰ）：ＴＧＴチケットを備える、ＡＳサーバ１０８からクライアント１０２への回答メッセージ。
（Ｃ）チケット付与サーバ要求メッセージ（ＴＧＳ＿ＲＥＱ）：ＴＧＳサーバ１１０からのＳＴチケットを要求するためのクライアント１０２からのメッセージ。
【００１８】
（Ｄ）チケット付与サーバ回答メッセージ（ＴＧＳ＿ＲＥＰ）：ＳＴチケットを備える、ＴＧＳサーバ１１０からクライアント１０２への回答メッセージ。
（Ｅ）キー要求メッセージ（ＫＥＹ＿ＲＥＱ）：セキュリティ（キー管理）パラメータを要求するためのクライアント１０２からアプリケーション・サーバ１０６へのメッセージ。
【００１９】
（Ｆ）キー回答メッセージ（ＫＥＹ＿ＲＥＰ）：サブキーおよびアプリケーション特定データを備える、アプリケーション・サーバ１０６からクライアント１０２への回答メッセージ。
【００２０】
（Ｈ）コンテンツおよび／またはサービス・メッセージの要求（ＣＯＮ＿ＲＥＷ）：所望のコンテンツおよび／またはサービスを要求するためにクライアント１０２からアプリケーション・サーバ１０６に送られるメッセージ。
【００２１】
（Ｉ）コンテンツ（ＣＯＮ＿ＲＥＰ）：所望のコンテンツおよび／またはサービスをクライアントに供給する、アプリケーション・サーバ１０６からクライアント１０２へ送られるメッセージ。コンテンツは、クライアントに送られる前に暗号化されるのが通常である。
【００２２】
これらのメッセージの各々は、一般に、ヘッダ、およびこれに続くメッセージ本体を含み、ヘッダはメッセージに共通である。一例として、ヘッダは、メッセージ・タイプ・フィールド、プロトコル・バージョン番号フィールド、およびチェックサムを含むことができる。メッセージ・タイプ・フィールドは、ＡＳ＿ＲＥＱ、ＡＳ＿ＲＥＰ等のようなメッセージ・タイプを示す。メッセージ・ヘッダに続いて、メッセージ本体があり、好ましくは、タイプ−長さ−値（ＴＬＶ）フォーマットで属性のリストを有する。
【００２３】
クライアント１０２が、同様にＫＤＣ１０４の一部であるＴＧＳサーバ１１０のチケットであるＴＧＴチケットを取得したいとき、クライアントは、ＡＳ＿ＲＥＱメッセージを生成して、クライアント１２０とＡＳサーバ１０８（ＫＤＣ１０４の一部）との間で認証サービス交換を開始する。言い換えると、ＡＳ＿ＲＥＱメッセージは、ＴＧＴチケットを
取得するために、クライアント１０２からＡＳサーバ１０８に送られ、クライアントはＴＧＴチケットを用いて、アプリケーション・サーバ１０６のような、特定のアプリケーション・サーバにＳＴチケットを要求する。一例として、ＡＳ＿ＲＥＱメッセージは、クライアントの身元（例えば、名称）、ＴＧＳサーバ１１０の身元、およびこれを応答に結び付けるノンス(nonce) を含むことができる。また、ＡＳ＿ＲＥＱメッセージは、クライアント１０２がサポートする対称暗号アルゴリズムのリストも含むことができる。回答に対してチェックするために、このメッセージは、タイムスタンプ、およびメッセージ完全性のための署名も含むことができる。署名は、キー付きチェックサム(keyed checksum)またはディジタル署名とすることができる。
【００２４】
署名を検証する公開キーは、ユーザのデータベースに保持しておくことが好ましい。任意にＡＳ＿ＲＥＱメッセージにディジタル証明書を含ませることができ、このディジタル証明書は格納されている公開キーの代わりに、ディジタル署名を検証するために用いられ得る。クライアント１０２のキー付きチェックサムを検証するためのクライアント１０２の永久対称キーは、同じユーザ・データベースに保持しておくことが好ましい。また、ＡＳ＿ＲＥＱメッセージは、キー同意（例えば、楕円曲線ディッフィ−ヘルマン(Elliptic Curve Diffie-Hellman) パラメータ）に必要な公開キー情報も含むことができる。一例として、楕円曲線(Elliptic Curve)は、その処理速度のために、公開キー暗号化に用いることができる。楕円曲線の使用は、ＲＳＡのような他の暗号化よりも、通常、１桁または２桁ほど高速である。キーの長さが１２８ビットのラインダール(Rijndael)暗号規格を用いてもよい。
【００２５】
ＡＳサーバ１０８は、ＡＳ＿ＲＥＳメッセージを検証するために、そのＡＳ＿ＲＥＳメッセージをを処理する。ＡＳ＿ＲＥＱ処理でエラーが発生しない場合、ＡＳサーバ１０８は、ＡＳ＿ＲＥＱメッセージに応答してＡＳ＿ＲＥＰメッセージを生成する。通常、ＡＳサーバ１０８はデータベースにおいてＴＧＳサーバ１１０およびクライアント１０２のキーを調べ、後続のＫＤＣ１０４との認証のために、ランダムなクライアント・セッションキーを生成する。ＡＳサーバ１０８はＴＧＴチケットを生成する。ＴＧＴチケットは、通常、平文部および暗号化部分の双方を含む。ＴＧＳサーバ１００の身元およびチケット有効期間は、発行されたＴＧＴチケットの平文側に提供され得る。チケットの暗号化部分は、クライアント１０２の名称、クライアントのセッションキー、および秘密に保持すべきその他のあらゆるデータを含むことができる。また、ＴＧＴチケットは、ＫＤＣ１０４が対応する暗号タイプおよびチェックサム・タイプのリストも提供することができる。チケットの暗号化部分は、ＫＤＣ１０４の秘密キーを用いて暗号化されていてよい。
【００２６】
一実施形態では、ＡＳ＿ＲＥＰメッセージは、クライアント１０２がＡＳ＿ＲＥＱメッセージのための署名を生成するために用いたアルゴリズムと同一のものを用いて、ＫＤＣ１０４によって署名される。この署名は、ディジタル署名またはクライアント１０２の秘密キーを用いたキー付きチェックサムのいずれかとすることができる。公開キー情報は、ＫＤＣ１０４のキー同意パラメータの公開部であり、クライアント１０２が選択したのと同じキー同意アルゴリズムを示していなければならない。リプレイを防止するために、ＡＳ＿ＲＥＰメッセージは、クライアントがＡＳ＿ＲＥＱメッセージにおいて生成したノンスのコピーであるノンスも含むことが好ましい。
【００２７】
一実施形態では、ＡＳ＿ＲＥＰメッセージの暗号化部分は、クライアント１０２に、自身の許可データへのアクセスを提供する。クライアント１０２が自身の許可データを知っている場合には、アプリケーション・サーバは、チケット内部に暗号化されているクライアント情報のコピーしか信頼しないため、クライアントはアプリケーション・サーバによってあっさり拒絶されるであろう動作を行おうとはしないので、許可データのクライアント・コピーをクライアントに供給することによって、クライアント（およびユーザ）には
便利になる。また、クライアントにハードウェア・セキュリティが備えられており、ユーザがハッキングして自身の許可データを変更するのを防止する場合にも、この機構はセキュリティ上の利点となり得る。これは、読み取り可能な許可データは、ローカル・ディスク上のコンテンツ（例えば、ムービー）を保存し再生する権利というような、何らかの局在的な行為をクライアントに許可する場合もあるためである。ＡＳ＿ＲＥＰメッセージ内において受信した許可データのクライアント・コピーは、通常、一般的なクライアント許可を規定するのであり、サーバに特定的ではない。許可データのクライアント・コピーの使用については、以下で更に説明する。ＡＳ＿ＲＥＰメッセージの暗号化部分も、クライアント１０２の身元を含み、この回答が元々ＫＤＣ１０４によってこの特定のクライアント１０２のために作成されたことを検証することができる。データは、キー同意アルゴリズムから得られる対称キーを用いて暗号化することが好ましい。
【００２８】
クライアント１０２は、ＡＳ＿ＲＥＰメッセージを処理してその認証性を検証し、メッセージにおける秘密チケット部を解読し、ＴＧＴチケットを取得する。ＡＳ＿ＲＥＰメッセージの認証性を検証することができない場合、クライアント１０２は、エラー・メッセージをＡＳサーバ１０２に返送しないことが好ましい。場合によっては、クライアントは別のＡＳ＿ＲＥＱメッセージで再試行することもできる。
【００２９】
本発明は、任意で、ＡＳ＿ＲＥＱメッセージおよびＡＳ＿ＲＥＱメッセージの双方においてディジタル証明書の受け渡しを可能にし、更にクライアント１０２およびＫＤＣ１０４がディジタル証明書によって互いに認証し合うことを可能にする。証明書がない場合には、クライアント１０２には既にＫＤＣ公開キーが渡されており、ＫＤＣ１０４は既にクライアント１０２の公開キーをそのデータベース内に有していると予測される。ＡＳ＿ＲＥＱ上のディジタル署名は、ＫＤＣ１０４のデータベース内で参照したクライアントの公開キーを用いてＫＤＣ１０４によって検証される。クライアント１０２は、ＡＳ＿ＲＥＰ上のディジタル署名を、予め渡されているＫＤＣ公開キーを用いて検証する。
【００３０】
クライアントがＡＳサーバ１０８の交換によってＴＧＴチケットを取得した後、クライアント１０２は、アプリケーション・サーバ１０６のような、所与のまたは特定のアプリケーション・サーバに対する認証の信用証明書を取得したいときに、クライアント１０２は、当該クライアント１０２とＫＤＣ１０４のＴＧＳサーバ１１０との間でＴＧＳ＿ＲＥＱメッセージ交換を開始する。ＴＧＳ＿ＲＥＱメッセージは、クライアント１０２によって生成され、ＴＧＳサーバ１１０に送られて、アプリケーション・サーバ・サービス・チケット（ＳＴチケット）が取得され、このＳＴチケットはＫＥＹ＿ＲＥＱメッセージ（以下で更に説明する）において用いられる。クライアント１０２は、ＡＳ＿ＲＥＰメッセージから取得したＴＧＴチケットを、ＴＧＳ＿ＲＥＱメッセージの一部として提示する。ＴＧＳ＿ＲＥＱメッセージは、アプリケーション・サーバ１０６の身元を特定するだけでなく、通常ＴＧＴチケット内にあるクライアント１０２の身元も特定し、クライアントは通常ノンスを含む。一実施形態では、クライアント１０２の身元は保護されている。何故なら、ＴＧＴチケットの暗号化部分内にあり、メッセージの平文部分には含まれていないからである。ＴＧＴチケットからのクライアント・セッションキーは、ＴＧＳ＿ＲＥＱ交換における暗号化および解読に用いることができる。このため、詮索者(snooper) は、クライアント（例えば、ユーザ）がどのサービスを要求しているかを検出することができない。
【００３１】
好ましくは、クライアント１０２は、後でＫＤＣ１０４からの一致するＴＧＳ＿ＲＥＰメッセージの有効性を判断するために、ノンス値を保存する。好ましくは、クライアント１０２は、設定変更可能なタイム・アウト値が満了するまで、ノンス値を保持しておくとよい。タイム・アウトの後では、クライアント１０２はもはや対応するＴＧＳ＿ＲＥＰを処理することができず、再試行しなければならない。
【００３２】
ＴＧＳサーバ１１０は、ＴＧＳ＿ＲＥＱメッセージを検証し、ＴＧＴチケットを処理する。ＴＧＳサーバ１１０は、次いで、ＴＧＳ＿ＲＥＱメッセージに応答して、ＴＧＳ＿ＲＥＰメッセージを生成する。ＴＧＳ＿ＲＥＰメッセージは、ＫＤＣ１０４が発行したＳＴチケット（最終サービス・チケット）を含み、クライアント１０２がコンテンツおよび／またはサービスを要求しようとするときに、これをクライアントがアプリケーション・サーバ１０６に提示する。アプリケーション・サーバ１０６の身元およびチケット有効期間は、発行されたＳＴチケットの平文側に提供されている。ＳＴチケットの暗号化部分は、クライアント１０２の名称、ならびにアプリケーション・サーバ１０６およびＫＤＣ１０４が共有するサーバキーによって暗号化されているサーバ・セッションキーを含む。ＳＴチケットの暗号化部分は、更に、許可データの第１コピー（例えば、サーバ・コピー）も含み、これは、部分的に、クライアントに供給されるサービスおよび／またはコンテンツの範囲を規定する。許可データは、アプリケーション・サーバ１０６ならびにアプリケーション・サーバ１０６が提供するコンテンツおよび／またはサービスに特定的である。一実施形態では、許可データは、サービスおよび／またはコンテンツに特定のオブジェクト、およびこれらのオブジェクトに対する権利を含む。秘密にする必要がある付加的なクライアント・データは、いずれもＳＴチケットの暗号化部分の一部として含ませることができる。
【００３３】
一実施形態では、ＴＧＳ＿ＲＥＰは、許可データの第２コピー（例えば、クライアント・コピー）も更に含む。許可データの第２コピーは、ＡＳ＿ＲＥＰメッセージにおいてＡＳサーバ１０８が生成したＴＧＴチケットからのクライアント・セッションキーを用いて暗号化されている。前述のように、セッションキーは、ＴＧＳサーバ１１０およびクライアント１０２にはわかっている。許可データの第２コピー（クライアント・コピー）は、ＴＧＴチケットからのセッションキーを用いて暗号化されているので、検証の目的またはその他の目的のために、クライアント１０２は、許可データを解読し、その許可データを利用することができる。これについては、以下で更に説明する。ＴＧＳ＿ＲＥＰメッセージにおいて受信された許可データの第２コピーは、ＡＳ＿ＲＥＰメッセージにおいて受信される許可データの第２コピーよりも、よりサーバに特定的な許可を含む、更に特定的な許可を与えることができる。ＡＳ＿ＲＥＰメッセージにおいて受信する許可データは、更に一般的であり、サーバに特定的でないクライアント許可、例えば、クライアントがコンテンツを格納することを許可されているか否かを規定する。
【００３４】
ＴＧＳ＿ＲＥＰメッセージは、ＫＤＣ１０４によって、ＴＧＴチケット・セッションキーを用いて、キー付きチェックサムで署名される。ＴＧＳ＿ＲＥＰメッセージは、更に、リプレイを防止するために、ＴＧＳ＿ＲＥＱメッセージからコピーされたノンスも含む。
【００３５】
一例として、ＴＧＳサーバ１１０は、以下の手順を用いてＴＧＳ＿ＲＥＰメッセージを生成することができる。まず、ＴＧＳ＿ＲＥＱメッセージからのノンスをＴＧＳ＿ＲＥＰメッセージに含ませて、これを要求に結び付ける。次に、ＫＤＣ１０４はランダムＳＴチケット・セッションキーのタイプを割り当てる。１つよりも多い暗号化アルゴリズムが使用可能な場合、ＫＤＣ１０４は最も強力なものを選択することが好ましい。次いで、ＫＤＣ１０４は、許可データの第１コピー、すなわちサーバ・コピーを含むＳＴチケットを生成する。アプリケーション・サーバ１０６の秘密キーは、ＳＴチケットの暗号化部分を暗号化し、更に、ＳＴチケット全体に対するキー付きチェックサムを生成するために用いられる。ＳＴチケットの終了時刻は、ＫＤＣ１０４によって決定することが好ましい。クライアント１０２は、所望により、より短い有効期間を指定することもできる。ＳＴチケットの暗号化部分は、クライアント１０２の身元、許可データの第１コピー、セッションキー、およびその他の秘密データを含む。ＴＧＳ＿ＲＥＰメッセージは、更に、暗号化データ部を含み、ＴＧＴチケット・セッションキーは、暗号化データ部を生成するために用い
られる。暗号化データ部は、許可データの第２コピーを含み、ＴＧＴセッションキーを用いて生成されたキー付きチェックサムは、ＴＧＳ＿ＲＥＰメッセージ上に追加され得る。この場合も、これは、ＴＧＳサーバ１１０が、許可データの２つのコピーを含むＴＧＳ＿ＲＥＰメッセージを生成するために用いることができる手順の一例に過ぎない。
【００３６】
ＴＧＳ＿ＲＥＰメッセージは、一方はＴＳチケットの暗号化部分に含まれ、もう一方はＴＧＴチケットからのセッションキーによって暗号化されている２つの許可データのコピーを含むので、アプリケーション・サーバ１０６およびクライアント１０２は、許可データにアクセスし、これを用いることができる。このように、クライアントは、余分な通信や余分なデータを必要とせずに、チェックおよび検証を行うことができる。本発明は、ケルベロス（Ｋｅｒｂｅｒｏｓ）とは異なる。ケルベロス（Ｋｅｒｂｅｒｏｓ）では、特定のアプリケーション・サーバに対するクライアントからのチケット要求に対するＫＤＣ回答は、許可データの単一コピーを含むのみであり、このデータは、ＳＴチケットの解読時に、アプリケーション・サーバにしかアクセスすることができない。クライアントは、許可データにアクセスできず、データを利用することができない。これに代わって、本発明におけるＫＤＣは、、一方はＴＳチケット内に暗号化されており、もう一方はＴＧＴチケットからのセッションキーによって暗号化されている許可データの２つのコピーを含ませることによって、特定のアプリケーション・サーバに対するクライアントからのチケット要求への回答を生成し、それにより、クライアント１０２が、許可データの第２コピーを解読して、許可データを利用することが可能になる。
【００３７】
一実施形態では、クライアント１０２は許可モジュール１２２を含む。許可モジュールは、許可データの第２コピーを受信し、許可データを分析して、アプリケーション・サーバ１０６が提供するコンテンツおよび／サービスの内どれを、どのようにクライアントが利用することを許可されているのか判定するように構成されている。許可モジュール１２２は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせによって実現することができる。一実施形態では、許可モジュール１２２は、ハードウェア・モジュールであり、許可データから抽出した許可をデコードし、クライアント１０２のコンテンツおよび／またはサービスに対する許可を検証し、クライアントが許可を超えていない場合にのみ、要求したコンテンツの解読および／またはサービスの提供に移行する。ハードウェア・モジュール外部からのソフトウェアによる詮索攻撃に対抗するために、許可データのキー付きチェックサムを検証するために用いられる秘密キーは、ハードウェア・モジュールの外側のクライアントには露出されていない。これを実施するために、一実施形態では、同じハードウェア・モジュール１２２内に、総合キー管理プロトコルが実装され、ハードウェア・モジュールの外側のクライアント内では、秘密キー即ちプライベートキーを平文では露出させない。
【００３８】
一例として、クライアント１０２は、以下の手順を用いて、ＴＧＳ＿ＲＥＰメッセージを処理することができる。この例では、「クライアント」とはクライアント１０２自身または許可モジュール１２２（クライアント内部にある場合）のいずれかを意味する。当業者であれば、許可モジュール１２２を備えたクライアントは、許可モジュールの外側では暗号化処理を行わせないことが認識されるであろう。まず、クライアント１０２はＴＧＳ＿ＲＥＰメッセージ・ヘッダを解析する。ヘッダの解析ができなかった場合、クライアント１０２は、ＴＧＳ＿ＲＥＰが受信されなかったかのように振る舞う。クライアント１０２は、エラー・メッセージをＴＧＳサーバ１１０に返送しない方が好ましい。場合によっては、クライアント１０２は別のＴＧＳ＿ＲＥＱメッセージを用いて再試行する。未処理のＴＧＳ＿ＲＥＱメッセージがある場合、クライアント１０２は、タイム・アウトまで回答を待ち続け、次いで再試行することができる。次いで、クライアント１０２は、ヘッダ内にあるプロトコル・バージョン番号を検証する。このプロトコル・バージョンに対応していない場合、クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージが受信されなかったか
のように振る舞う。それ以外の場合、クライアント１０２は次にメッセージの残り部分を解析する。メッセージ・フォーマットが違法であることがわかった場合、クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージが受信されなかったかのように振る舞う。
【００３９】
次に、クライアント１０２は、同じノンスを有する未処理のＴＧＳ＿ＲＥＱメッセージを探す。一致がない場合、クライアントは、メッセージが受信されなかったかのように続行する。チェックサムが検証されない場合、このメッセージを欠落させ、クライアント１０２は、メッセージが受信されなかったかのように続行する。
【００４０】
次に、クライアントは、ＴＧＴチケット・セッションキーを用いて、ＴＧＳ＿ＲＥＰメッセージにおける秘密チケット部分を解読する。ＴＧＴチケット・セッションキーのタイプおよび暗号化データのタイプが一致しないために秘密チケット部分が解読できない場合、致命的なエラーがユーザに報告され、クライアント１０２は再試行しない。得られた平文テキストがフォーマット・エラーを含む場合、またはこのクライアント１０２がサポートしていないタイプのセッションキーを含む場合、または要求と一致しないクライアントの身元を含む場合も、致命的エラーがユーザに報告され、クライアント１０２は再試行しない。セッションキータイプがサポートされており、クライアントがＴＧＳ＿ＲＥＰメッセージの秘密チケット部分を解読できる場合、クライアントは許可データの第２コピーを抽出し、これを検証し、後の使用のためにこれを保持する。
【００４１】
次に、クライアント１０２はＳＴチケットを処理する。ＳＴチケット内にエラーがある場合、これをユーザに致命的エラーとして報告し、クライアント１０２は他のＴＧＳ＿ＲＥＱメッセージで再試行しない。ＴＧＳ＿ＲＥＰメッセージ内にエラーが検出されない場合、クライアント１０２はＳＴチケット、および許可データの第１コピーを含む平文秘密チケット部分全体を、そのチケット・キャッシュ内の新たなエントリに保存する。許可モジュール１２２がクライアント１０２内にある実施形態では、クライアントは、変更バージョンのチケットに対するチェックサムを生成するためにサーバキーを入手しないため、ＳＴチケットは、クライアント１０２内部で、かつ許可モジュール１２２の外側に格納され得る。許可データは、許可モジュール１２２内部に格納されるか、あるいはキー付きチェックサムまたはディジタル署名によって認証され、次いでクライアント１０２内部でモジュールの外部に格納され得る。許可データを許可モジュール１２２の外部に格納する場合（モジュールの必要記憶量を極力抑えるため）、ハッカーの許可データを変更しようとする試みは、許可モジュール１２２によって検出される。これは、許可データのためにキー付きチェックサムまたはディジタル署名を生成する際に用いられるキーは、許可モジュール１２２の外部では読むことができないからである。
【００４２】
ＫＥＹ＿ＲＥＱおよびＫＥＹ＿ＲＥＰメッセージは、クライアント１０２とアプリケーション・サーバ１０６との間におけるキー管理および認証のために用いられる。ＫＥＹ＿ＲＥＱメッセージは、クライアント１０２によってアプリケーション・サーバ１０６に送られ、新たな１組のセキュリティ・パラメータを確立する。また、ＫＥＹ＿ＲＥＱメッセージは、クライアント１０２が定期的にアプリケーション・サーバ１０６との新たなキーを確立するためにも用いることができる。クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージにおいて前に取得されている有効なＳＴメッセージによって開始する。アプリケーション・サーバ１０６は、そのサービスキーで開始し、これを用いてチケットを解読し有効性を判断することができる。クライアントは、ＳＴチケット、およびクライアント１０２を認証するために必要なキー付きチェックサムを含むＫＥＹ＿ＲＥＱメッセージを生成する。ＫＥＹ＿ＲＥＱメッセージは、反射攻撃(replay attack) を防止するために、これを応答ＫＥＹ＿ＲＥＰメッセージおよびクライアント・タイムスタンプに結び付けるノンスも含むことが好ましい。
【００４３】
クライアント１０２がＫＥＹ＿ＲＥＱメッセージを生成するとき、許可データの第１コピー、および一実施形態では、クライアント１０２の身元は、ＳＴチケットの暗号化部分に存在する。クライアント１０２がＫＥＹ＿ＲＥＱメッセージを送り出した後、アプリケーション・サーバ１０６からの一致するＫＥＹ＿ＲＥＰメッセージの有効性を後に判断するために、クライアントのノンス値を保存する。クライアント１０２は、設定可能なタイム・アウト値が終了するまで、クライアントのノンス値を保持する。タイム・アウトの後では、クライアント１０２はもはや対応するＫＥＹ＿ＲＥＰメッセージを処理することができない。クライアント１０２は、このタイム・アウトの後に再試行することができる。
【００４４】
ＫＥＹ＿ＲＥＰメッセージは、ＫＥＹ＿ＲＥＱメッセージに応答して、アプリケーション・サーバ１０６によって送られる。一例として、ＫＥＹ＿ＲＥＱメッセージは、クライアント１０２およびアプリケーション・サーバ１０６間で共有するセッションキーで暗号化されている、１つ以上のランダムに生成されたサブキーを含むことができる。ＫＥＹ＿ＲＥＰメッセージは、セキュリティ・パラメータを確立するために必要な追加情報も含むことができる。
【００４５】
クライアント１０２は、ＫＥＹ＿ＲＥＰメッセージを受信し、ＫＥＹ＿ＲＥＰメッセージを処理する。クライアントは、メッセージ・ヘッダを解析し、プロトコル・バージョン番号を検証し、メッセージの残り部分を解析し、ＫＥＹ＿ＲＥＰ内のノンスを既存のクライアントＫＥＹ＿ＲＥＱノンスと照合し、クライアント１０２およびアプリケーション・サーバ１０６間で共有されるセッションキーを用いてチェックサムを検証する。更に、クライアントは、前記共有セッションキーを用いてＫＥＹ＿ＲＥＰのサブキーを解読し、選択したサイファースイート(ciphersuite) が受け入れ可能であることを検証し、暗号化されたＤＯＩオブジェクト（認証）を解析し、コンテンツ解読キーおよび認証キーをサブキーから生成し、これらを後の使用のために保存する。
【００４６】
一実施形態では、クライアント１０２が、一旦、ＫＥＹ＿ＲＥＰを受信し検証すると、クライアントによってＣＯＮ＿ＲＥＱメッセージがアプリケーション・サーバ１０６に送られる。ＣＯＮ＿ＲＥＱメッセージを生成する際、クライアントは、同クライアントがＡＳ＿ＲＥＰメッセージおよび／またはＳＴチケットを有するＴＧＳ＿ＲＥＰメッセージから受信して解読した、許可データの解読第２コピーにアクセスし、許可データを確認して、ＣＯＮ＿ＲＥＱメッセージが違法または不正なオプションを含んでいないことを確認する。したがって、クライアントのユーザ・インターフェースは改善され、ユーザは、ＣＯＮ＿ＲＥＱメッセージをサーバに提出し応答を待つ必要なく、最初から無許可のオプションを選択することを防止することができる。一実施形態では、クライアント１０２がなおも何らかの方法で無許可のＣＯＮ＿ＲＥＱメッセージを生成した場合、許可モジュール１２２は、ＣＯＮ＿ＲＥＱメッセージのキー付きチェックサムを生成するために必要な対称キーを保持し、許可データの第２コピーが規定するクライアントの許可に違反するかまたはそれを超過するＣＯＮ＿ＲＥＱメッセージに対して、このキー付きチェックサムを生成することを拒絶する。したがって、無許可のＣＯＮ＿ＲＥＱメッセージはクライアント側で拒絶されるが、かかる無許可のメッセージが侵入してきた場合、ＣＯＮ＿ＲＥＱは、正しいキー付きチェックサムを有しておらず、サーバ１０６にクライアント許可をチェックすることを要求することなく拒絶されるので、アプリケーション・サーバ１０６は、通常、そのような無許可のＣＯＮ＿ＲＥＱメッセージを発見することはない。
【００４７】
許可データの確認によって、アプリケーション・サーバ１０６において無許可のメッセージの処理を回避するため、システムが最適化され、クライアントとユーザとの対話が改善され、ユーザはアプリケーション・サーバ１０６の応答を待つことなく、その場で許可を評価することが可能となる。一実施形態では、ＣＯＮ＿ＲＥＱメッセージは、クライアント１０２およびアプリケーション・サーバ１０６が供給するセッションキーによって暗
号化される。
【００４８】
ＣＯＮ＿ＲＥＱメッセージを受信すると、アプリケーション・サーバ１０６はＣＯＮ＿ＲＥＱメッセージを処理し、暗号化ＳＴチケットの一部として受信した許可データの第１コピーによって、要求の有効性を判断する。エラーがなく、コンテンツに対する要求が許可データの許可に違反していない場合、アプリケーション・サーバ１０６はＣＯＮ＿ＲＥＰメッセージを生成し、クライアントが要求したコンテンツおよび／またはサービスの配信を開始する。通常、配信されるコンテンツは、クライアント１０２およびサーバ１０６が供給するセッションキーを用いて、アプリケーション・サーバ１０６によって暗号化されている。
【００４９】
クライアント１０２は、コンテンツを受信し、コンテンツを解読し、コンテンツを処理し利用し始める。一実施形態では、クライアント１０２は許可データのコピーを有しているので、クライアントは、受信したコンテンツおよび／またはサービスに許可された使用を判断することができる。例えば、クライアント１０２は、許可データをチェックすることにより、クライアントはコンテンツのコピーを格納または保存することを許可されているか否か判断することができる。許可モジュール１２２は、許可データをチェックし、クライアントの許可を判断することができる。クライアントが許可されている場合、クライアントは、受信し解読したコンテンツを保存することができる。加えて、クライアントは許可データのコピーを有しているので、クライアント１０２は、一実施形態では許可モジュール１２２によって、更にクライアントは１回よりも多くコンテンツを再生または再使用できるか否かの許可を、チェックによって判断することができる。許可モジュール１２２は、通常、コンテンツ解読キーを格納しており、適正な許可がなければ、コンテンツを解読することを拒絶する。クライアントの許可を判断する能力を得るには、クライアント１０２がＴＧＳ＿ＲＥＰメッセージにおいて受信しその内部で使用するために格納してある、許可データの第２コピーを利用する。これによって、クライアントの動作が改善し、ネットワークを通じた通信を抑制する。
【００５０】
一実施形態では、システム１００では、クライアントがＳＴチケットおよび許可データのクライアント・コピーを取得するためには、ＴＧＳ＿ＲＥＱおよびＧＳ＿ＲＥＰの交換を行う必要がない。クライアント１０２は、特定のサーバ、例えば、アプリケーション・サーバ１０６に、サービス・チケットのためにＡＳ＿ＲＥＱを提出する。ＫＤＣ１０４はＡＳ＿ＲＥＱを処理し、許可データの第１コピーを含む最初のアプリケーション・サーバにＳＴチケットを返す。更に、ＫＤＣは、許可データの第２コピーをクライアントに送る。前記許可データの第２コピーは、クライアント１０２がアクセスし利用するようにフォーマットされている。通常、ＫＤＣ１０４が返送するＡＳ＿ＲＥＰは、許可データの第１コピーを有するＳＴチケット、および許可データのクライアント・コピーを含む。したがって、クライアントは、ＴＧＳ＿ＲＥＱを提出しなくても、ＳＴチケットと共に、許可データのクライアント・コピーを取得し続ける。
【００５１】
図２は、本発明の一実施形態の一実施態様によるシステム１０１の簡略ブロック図を示す。一実施形態では、クライアント１０２は第三者サーバ１４０にアクセスして所望のコンテンツおよび／またはサービスを選択し、次いでアプリケーション・サーバ１０６にアクセスして、選択したコンテンツおよび／またはサービスを実際に受信する。コンテンツおよび／サービスを選択する際、クライアント１０２は許可データのクライアント・コピーを利用する。コンテンツおよび／またはサービスの選択を第３者のサーバ１４０に提出する前に、クライアントは、所望のコンテンツおよび／またはサービスを決めておき、次いで許可データのクライアント・コピーをチェックして、クライアントの許可を超過する選択を行うことを回避する。次いで、クライアント１０２は、コンテンツおよび／またはサービス選択を第三者サーバ１４０に送る。すると、第三者サーバ１４０は、コンテンツ
および／またはサービス選択を検証し、コンテンツおよび／サービス選択回答メッセージをクライアント１０２に送る。コンテンツおよび／サービス選択回答メッセージには、アプリケーション・サーバ１０６がクライアントに許可し、クライアントに選択したコンテンツおよび／またはサービスに対するアクセスを行わせるための情報が含まれている。このように、アプリケーション・サーバが第三者サーバの情報に基づいてクライアントの許可を決定しようとする場合に、クライアント１０２は、許可データを参照し、アプリケーション・サーバによって後であっさり拒絶される第三者サーバ１０４からのコンテンツおよび／サービスの許可を要求することを避ける。
【００５２】
一実施形態では、第三者アプリケーション・サーバ１４０は、更に、第三者情報の認証も含む。この認証は、付加的に、クライアント１０２によって、通常ＫＥＹ＿ＲＥＱメッセージ内でアプリケーション・サーバ１０６に転送される。アプリケーション・サーバ１０６は、この認証を利用して、クライアント１０２によってアプリケーション・サーバに供給された第三者サーバ情報を認証し、クライアントを許可するために使用する情報が、実際に第三者サーバ１０４からクライアントに供給されたのであり、他の何らかのネットワーク・エンティティから供給されたものではなく、あるいはクライアントによって生成された何らかの偽造情報ではないことを確認する。
【００５３】
ＫＥＹ＿ＲＥＱメッセージをアプリケーション・サーバ１０６に提出する際、クライアント１０２は、第三者サーバ情報と、クライアントに供給された場合には、認証を含ませる。アプリケーション・サーバ１０６は、ＫＥＹ＿ＲＥＱメッセージを処理し、第三者サーバ情報を認証し、この情報を利用してクライアントの許可を検証する。一旦、認証し検証したなら、アプリケーション・サーバ１０６は前述のようにＫＥＹ＿ＲＥＰを生成する。
【００５４】
図３を参照すると、アプリケーション・サーバからのコンテンツおよび／またはサーバを要求し使用するときに、クライアントが用いる、許可データの第２コピーをクライアントに供給する方法２００のフロー・チャートが示されている。一例として、方法２００は、システム１００および前述の適切なメッセージ・タイプによって実現することができる。ステップ２０２において、クライアント１０２のようなクライアントから、ＴＧＴチケットの要求を受信する。ステップ２０４において、ＴＧＴチケットを生成する。ステップ２０４は、例えば、ＡＳサーバ１０８によって実行することができる。ステップ２０６において、ＴＧＴチケットをクライアントに送る。このステップも、ＡＳサーバ１０８によって実行することができる。一実施形態では、クライアントは、許可データのクライアント・コピーがＡＳ＿ＲＥＰに含まれている場合、許可データのクライアント・コピーを抽出する。ステップ２０８において、特定のアプリケーションに向けたＳＴチケットの要求をクライアントから受信する。ＳＴチケットの要求は、ＴＧＴチケットを含み、通常では、クライアントの身元を平文では表示しない。ステップ２１０において、ＴＧＳ＿ＲＥＰメッセージを生成する。このメッセージは、ＳＴチケット内で暗号化された許可データの第１コピーと、ＴＧＴチケットからのセッションキーを用いて暗号化した許可データの第２コピーとを含む。一実施形態では、ＴＧＳ＿ＲＥＰの生成は、ＴＧＳサーバ１１０によって行われる。ステップ２１２において、ＴＧＳ＿ＲＥＰメッセージを、許可データの両コピーと共に、クライアントに送る。このステップもＴＧＳサーバ１１０によって実行することができる。ステップ２１４において、クライアントはＴＧＳ＿ＲＥＰを受信する。ステップ２１６において、クライアントはＴＧＳ＿ＲＥＰから、少なくとも許可データの第２コピーを抽出する。ステップ２２０において、クライアントは、ＳＴチケットを含むＫＥＹ＿ＲＥＱメッセージを生成し送る。これは、更に、許可データの第１コピーも含む。ステップ２２２において、アプリケーション・サーバはＫＥＹ＿ＲＥＱを受信し処理する。アプリケーション・サーバは、ＳＴチケットを抽出し、ＳＴチケットを解読し、許可データの第１コピーの有効性を判断する。ステップ２２６において、クライアントはＫＥ
Ｙ＿ＲＥＰメッセージを検証し、これをＫＥＹ＿ＲＥＱメッセージと照合する。
【００５５】
図４は、図３に示したプロセス２００と同様の、プロセス２４０の一実施態様の簡略フロー図を示す。ステップ２４２において、クライアントはＴＧＴチケット要求を送る。ステップ２４４において、ＫＤＣ１０４はＴＧＴチケットを生成する。ステップ４４６において、ＫＤＣ１０４は、クライアント許可データのクライアント・コピーと共にＴＧＴチケットを送る。ステップ２４８において、クライアントはＴＧＴチケットを受信し、許可データのクライアント・コピー全体を抽出する。ステップ２５０において、クライアント１０２は、ＳＴチケットを要求するＴＧＳ＿ＲＥＱを送る。ステップ２５２において、ＫＤＣはＴＧＳ＿ＲＥＰを返送する。ステップ２５４において、クライアントはＴＧＳ＿ＲＥＰを受信し、ＳＴチケットおよび許可データのサーバ特定の第２コピーを抽出する。ステップ２５６において、クライアントは、所望のコンテンツおよび／またはサービスを決定し、許可データのクライアント・コピーにアクセスし、所望のコンテンツおよび／またはサービスを検証して、許可を超過したコンテンツおよび／またはサービスを要求するのを回避する。ステップ２５６において、クライアント１０２は、コンテンツおよびサービス選択を第三者サーバ１４０に提出する。ステップ２６０において、第三者サーバは、クライアントを許可するために用いられる第三者情報、およびこの情報の認証（例えば、キー付きチェックサム）を含む、コンテンツおよび／またはサービス選択回答を送る。第三者情報は、クライアントの認証を検証するために用いることができる情報、例えば、クライアントによって選択されたコンテンツの識別、「クレジット・カードへの課金」、「ユーザにこのコンテンツを保存させる」というような、コンテンツに付随する種々の購入オプション、およびその他のかかる情報を含む。また、第三者情報は、ブラックアウト領域（例えば、国、州、郵便番号に基づくブラックアウト領域）およびその他のかかる制約のリストのような、コンテンツに付随する制約も含むことができる。ステップ２６２において、クライアント１０２は、許可データを超過しないＫＥＹ＿ＲＥＱメッセージをアプリケーション・サーバ１０６に送る。ＫＥＹ＿ＲＥＱメッセージは、第三者情報をその認証およびＳＴチケットと共に含み、ＳＴチケットは更に許可データの第１コピーも含む。ステップ２６４において、アプリケーション・サーバ１０６は、情報を認証し、第三者情報および許可データの第１コピーを用いてコンテンツおよび／またはサービスに対するクライアントの許可を検証する。ステップ２６６において、アプリケーション・サーバ１０６はＫＥＹ＿ＲＥＰをクライアント１０２に送る。
【００５６】
図５は、クライアントがアプリケーション・サーバからのコンテンツおよび／またはサービスを要求し受信するためのプロセス３１０の一実施態様の簡略フロー図を示す。一実施形態では、プロセス３１０は、図３に示すプロセス２００のステップ２２６を踏襲して、許可データの第２コピーをクライアントに供給する。ステップ３１２において、クライアント１０２のようなクライアントは、所望のコンテンツおよび／サービスを決定する。例えば、クライアントは、ユーザまたは他のネットワーク・エンティティから、コンテンツに対する要求を受信する。ステップ３１４において、クライアントは、コンテンツおよび／またはサービスの要求を検証して、コンテンツに対する要求をチェックし、以前に取得し格納されている許可データの第２コピーと比較することによって、要求が許可されており、許可されている使用を超過しないことを確認する。一旦クライアントが要求を検証したなら、クライアントはＣＯＮ＿ＲＥＱメッセージを生成する。ステップ３１６において、クライアントは、ＣＯＮ＿ＲＥＱメッセージを、暗号化し、キー付きチェックサムで認証し、アプリケーション・サーバ１０６（または第三者サーバ１４０）のようなアプリケーション・サーバに送る。ステップ３２０において、アプリケーション・サーバはＣＯＮ＿ＲＥＱメッセージを解読し、キー付きチェックサム、およびＳＴチケット内にある許可データの第１コピーにおいて規定されているクライアントの許可アクセスに基づいて、要求の有効性を判断する。ステップ３２２において、アプリケーション・サーバは、ＳＴチケットおよび許可データの有効性が判断された場合、要求されたコンテンツ、および／
またはサービスを暗号化して送る。一実施形態では、アプリケーション・サーバは、要求コンテンツを複数の異なるパケットに入れて送り、所望のコンテンツ全体が単一のパケットには含まれず、数個のパケットに含まれるようにする。ステップ３２４において、クライアントは、要求したコンテンツを受信し、データを処理する。ステップ３３０において、クライアントは、格納してある許可データの第２コピーにアクセスし、クライアントが当該コンテンツおよび／またはサービスのコピーを格納できるか否か判定を行う。ステップ３３２において、クライアントがコンテンツおよび／またはサービスを格納することを許可されている場合には、クライアントはコンテンツおよび／またはサービスを格納する。許可されていない場合には、クライアントは、コンテンツが初めて受信されたとき、コンテンツにアクセスすることを許可され、次いでプロセスはステップ３４０に進み、追加のコンテンツを探す。それ以外の場合、ステップ３３４に進み、クライアントは、コンテンツを１回よりも多く再生することが可能であるかを判定する。可能である場合、ステップ３３６に進み、クライアントは、１回以上コンテンツにアクセスし再生することができる。ステップ３４０において、プロセスは、受信するコンテンツおよび／またはサービスが未だあるか否か判定を行う。ある場合には、プロセス３１０はステップ３２４に戻り、追加のコンテンツおよび／またはサービスを受信する。ステップ３３６において、それ以上データおよび／またはコンテンツがないと判断した場合、プロセス３１０は終了する。
【００５７】
本発明は、クライアントが、許可データの自身のコピーを格納しアクセスすることを可能にする方法、システム、装置、プログラム、およびコンピュータ・プログラム生産物を提供する。これによって、ユーザ・インターフェースが改良され、エラーが減少し、コンテンツおよび／またはサービス配信の効率が向上し最適化する。更に、クライアントに許可データの自身のコピーにアクセスさせることによって、クライアントは、配信されるコンテンツおよび／またはサービスの処理および利用に関して判断を下すことが可能となる。更にまた、必要な通信量が減少し、全体的なネットワーク・トラフィックが減少する。一実施形態では、本発明は、モトローラ社（Ｍｏｔｏｒｏｌａ，Ｉｎｃ）が開発した電子セキュリティ・ブローカ（ＥＳＢｒｏｋｅｒ）プロトコル、および同様にモトローラ社が開発したＩＰ権利管理システムの一部として実装される。
【００５８】
以上、ここに開示した発明は、具体的な実施形態およびそお応用を通じて説明したが、特許請求の範囲に明記されている本発明の範囲から逸脱することなく、多数の変更や変更も当業者には可能である。
【図面の簡単な説明】
【００５９】
【図１】本発明の一実施形態にしたがって構成したシステムの簡略ブロック図。
【図２】本発明の一実施形態の一実施態様によるシステムの簡略ブロック図。
【図３】クライアントが用いるために、許可データの第２コピーをクライアントに供給する方法のフロー図。
【図４】図３に示したプロセスと同様のプロセスの一実施形態の簡略フロー図。
【図５】クライアントがコンテンツおよび／またはサービスを要求し、アプリケーション・サーバから受信するプロセスの一実施形態の簡略フロー図。
【図１】
2005517347.tif 000003
【図２】
2005517347.tif 000004
【図３】
2005517347.tif 000005
【図４】
2005517347.tif 000006
【図５】
2005517347.tif 000007
【国際調査報告】
2005517347.tif 000008
2005517347.tif 000009