JP2005505991A

JP2005505991A - 公衆サーバからコンテンツを要求した場合にクライアントのプライバシーを提供するための方法およびシステム

Info

Publication number: JP2005505991A
Application number: JP2003535412A
Authority: JP
Inventors: メドビンスキー、アレクサンダー
Original assignee: General Instrument Corp
Current assignee: Arris Technology Inc
Priority date: 2001-10-05
Filing date: 2002-09-24
Publication date: 2005-02-24
Also published as: CA2463034A1; EP1436944A2; US20030070068A1; WO2003032575A2; WO2003032575A3; KR100990320B1; CA2463034C; MXPA04003226A; CN1611031A; US6993652B2; KR20040045486A

Abstract

クライアント（１０２）が公衆アプリケーション・サーバ（１０６）からコンテンツを要求した場合に、インターネット上のクライアントのプライバシーを保護するために動作する方法およびシステム。この方法は、チケットのコンセプトを使用するキー管理プロトコルに適している。クライアント（１０２）の名前またはＩＤは、クライアントが、特定のアプリケーション・サーバ（１０６）に対してチケットを要求しているすべてのキー管理メッセージ（ＴＧＳ＿ＲＥＱ）内で暗号化される。キー管理メッセージは、クライアントとキー配布センター（ＫＤＣ）（１０４）との間およびクライアント（１０２）と特定のアプリケーション・サーバ（１０６）との間で交換される。ＫＤＣ（１０４）は、このようなメッセージでは平文でクライアント（１０２）の名前またはＩＤを提供しない。それにより、クライアントのＩＤが、特定のアプリケーション・サーバ（１０６）が提供するコンテンツとリンクされることが防止される。これにより、ユーザのプライバシーの保護が改善される。

Description

【技術分野】
【０００１】
本発明は、概して、ネットワークの機密保護に関し、より詳細にはアプリケーション・サーバからコンテンツを要求した場合に、クライアントのプライバシーを提供するための方法およびシステムに関する。
【背景技術】
【０００２】
インターネットは機密保護が行われていないネットワークである。インターネット上で使用される多くのプロトコルは全く機密保護を行わない。暗号化または任意の他のタイプのセキュリティ・スキームを使用しないでインターネットを通して送られるデータは、「（暗号ではなく）平文で」送信されることになる。ハッカーが、インターネットを通して平文で送信されるパスワード、クレジット・カード番号、クライアントのＩＤおよび名前等のようなデータを「嗅ぎつける（ｓｎｉｆｆ）」ことができるツールは容易に入手することができる。それ故、インターネットを通して暗号化していないデータを送信するアプリケーションは、非常に無防備なものである。
【０００３】
ケルベロス（Ｋｅｒｂｅｒｏｓ）は、秘密キー暗号を使用することにより、クライアント／サーバ・アプリケーションに対して認証を行うように設計されている周知のネットワーク認証プロトコルの一例である。マサチューセッツ工科大学（ＭａｓｓａｃｈｕｓｅｔｔｓＩｎｓｔｉｔｕｔｅｏｆＴｅｃｈｎｏｌｏｇｙ）から入手可能であるケルベロス・プロトコルは、その称するところによれば、暗号を使用しているので、クライアントは機密保護が行われていないネットワーク接続を通してそのＩＤをサーバに証明する（およびその逆を行う）ことができる。クライアントおよびサーバがそれらのＩＤを証明するためにケルベロスを使用した後、彼らが自分のビジネスを行う際に、プライバシーおよびデータの保全性を確保するために、そのすべての通信を暗号化することができると言われている。
【０００４】
本発明は、ネットワーク・セキュリティの分野に関するこれらおよび他の背景情報要因に関する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、アプリケーション・サーバからコンテンツを要求した場合に、クライアントのプライバシーを提供するための方法を提供する。
【課題を解決するための手段】
【０００６】
上記方法は、クライアントからチケット交付チケット（ＴＧＴチケット）に対する要求を受信するステップと、内部に暗号化されたクライアントのＩＤを含むＴＧＴチケットを生成するステップと、クライアントにＴＧＴチケットを送信するステップと、ＴＧＴチケットを含み、かつ平文でクライアントのＩＤを提供しない、クライアントからアプリケーション・サーバへのサービス・チケット（ＳＴチケット）に対する要求を受信するステップと、内部に暗号化されたクライアントのＩＤを含むＳＴチケットを生成するステップと、平文でクライアントのＩＤを提供することなく、クライアントにＳＴチケットを送信するステップとを含む。
【０００７】
他の実施形態の場合には、本発明の特徴は、アプリケーション・サーバからコンテンツを要求した場合に、クライアントのプライバシーを提供するためのシステムであることを特徴とする。このシステムは、クライアントからＴＧＴチケットに対する要求を受信し、内部に暗号化されたクライアントのＩＤを含むＴＧＴチケットを生成し、クライアントにＴＧＴチケットを送信するように構成されている認証サーバを含む。チケット交付サーバは、ＴＧＴチケットを含み、平文でクライアントのＩＤを提供しない、クライアントからアプリケーション・サーバへのＳＴチケットに対する要求を受信し、内部に暗号化されたクライアントのＩＤを含むＳＴチケットを生成し、平文でクライアントのＩＤを提供することなくクライアントにＳＴチケットを送信するように構成されている。
【０００８】
本発明の以下の詳細な説明を読み、本発明の原理を使用している例示としての実施形態を示す添付の図面を見れば、本発明の特徴および利点をよりよく理解することができるだろう。
【発明を実施するための最良の形態】
【０００９】
ケルベロスは、特定のアプリケーション・サーバへのクライアントからのチケット要求に対するキー配布センター（ＫＤＣ）応答が平文のクライアント名を含んでいるという不都合を有する。ケルベロスは、このような応答の中で、特定のアプリケーション・サーバのＩＤを平文で提供するように指定しているので、クライアントのＩＤを容易にコンテンツにリンクすることができる。これは、クライアントがコンテンツを要求している特定のサーバを第三者が容易に識別できるため、クライアントの（すなわち、ユーザの）プライバシーが非常に危険に晒されることを意味する。公衆サーバからコンテンツを要求しているネットワークのユーザは、自分が要求するコンテンツとの関連を知られたくない場合がある。本発明は、上記および他の欠点を克服し、公衆サーバのようなサーバからコンテンツを要求している場合にユーザのプライバシーを改善するための方法およびシステムを提供する。
【００１０】
本発明は、クライアントが特定のサーバに対して認証を行うことができる対称キーで暗号化された認証トークンであるチケットのコンセプトを使用するキー管理プロトコルに適している。本発明のある実施形態によれば、クライアントが特定のアプリケーション・サーバ（例えば、コンテンツ・プロバイダ）に対してチケットを要求しているか、またはコンテンツ・プロバイダと直接通信している場合に、すべてのキー管理メッセージ内でクライアント名またはＩＤが暗号化される。ユーザ（クライアント）名は、アプリケーション・サーバに直接宛先を指定されているか、または平文でサーバ名を含むすべてのキー管理メッセージ内で暗号化される。これらのキー管理メッセージは、クライアントとＫＤＣとの間およびクライアントとアプリケーション・サーバとの間で送受信される。本発明は、標準ケルベロスチケットはクライアント名を暗号化して送るが、特定のサーバへのチケット要求に対するＫＤＣ応答が、平文でクライアント名を含んでいるという標準ケルベロスの不都合を克服する。
【００１１】
図１を参照すると、本発明のある実施形態により構成したシステム１００のモデルが示されている。本発明の１つの可能な実施例を含むシステム１００は、インターネットのようなネットワーク上でセキュリティ及びプライバシーを提供し、数百万のユーザ用に拡張することができる認証キー管理プロトコルを使用する。一般的に、システム１００は、公開キーおよび対称キーアルゴリズムの双方を使用して、中央キー配布センター（ＫＤＣ）１０４と相互作用を行い、かつ対称キーアルゴリズムのみを使用してアプリケーション・サーバ１０６のような個々のアプリケーション・サーバと相互作用を行っているクライアント１０２を含む。プロトコルは、一般的なものであり、分散環境で認証を要求する異なるアプリケーションに容易に適合することができる。さらに、プロトコルは、集中管理されたユーザ・データベースによりインタフェースされ得る。
【００１２】
クライアント１０２は、ユーザのためにネットワーク・サービスを利用するプロセスまたはデバイスを備えることができる。例を挙げて説明すると、クライアント１０２は、任意のタイプのコンピュータを備えてもよく、あるいはクライアント１０２は無線電話またはロー・エンド・マイクロプロセッサを有する家庭電化製品のような「シンクライアント」を含んでもよい。場合によっては、サーバ自身が、他のサーバのクライアントになることもできる（例えば、プリント・サーバがファイル・サーバのクライアントになることができる）ことに留意されたい。アプリケーション・サーバ１０６は、ネットワーク・クライアントにリソースを提供する。例示した実施形態の場合には、ＫＤＣ１０４は、認証サーバ（ＡＳサーバ）１０８およびチケット交付サーバ（ＴＧＳサーバ）１１０を含む。ＡＳサーバ１０８は、その信用証明書を確認した後、クライアント１０２にチケット交付チケット（ＴＧＴチケット）を発行する。ＴＧＳサーバ１１０は、クライアント１０２にアプリケーション・サーバ・サービス・チケット（ＳＴチケット）を提供する。ＳＴチケットは、クライアント１０２がサービスを要求した場合に、クライアント１０２がアプリケーション・サーバ１０６に提示するエンド・サービス・チケットである。アプリケーション・サーバ１０６は、クライアント１０２がＳＴチケットにより自身の認証を行った場合に、クライアント１０２に種々のサービスを提供する。
【００１３】
システム１００が使用する基本的なメッセージのタイプを以下に示す。
（Ａ）認証サーバ要求メッセージ（ＡＳ＿ＲＥＱ）：ＡＳサーバ１０８からＴＧＴチケットを要求するためのクライアント１０２からのメッセージ；
（Ｂ）認証サーバ応答メッセージ（ＡＳ＿ＲＥＰ）：ＴＧＴチケットを含むＡＳサーバ１０８からクライアント１０２への応答メッセージ；
（Ｃ）チケット交付サーバ要求メッセージ（ＴＧＳ＿ＲＥＱ）：ＴＧＳサーバ１１０からＳＴチケットを要求するためのクライアント１０２からのメッセージ；
（Ｄ）チケット交付サーバ応答メッセージ（ＴＧＳ＿ＲＥＰ）：ＳＴチケットを含むＴＧＳサーバ１１０からクライアント１０２への応答メッセージ；
（Ｅ）チケット申込み（Ｃｈａｌｌｅｎｇｅ）メッセージ（ＴＫＴ＿ＣＨＡＬＬＥＮＧＥ）：キー管理を開始するために、アプリケーション・サーバ１０６からクライアント１０２に送信するメッセージ；
（Ｆ）キー要求メッセージ（ＫＥＹ＿ＲＥＱ）：セキュリティ（キー管理）パラメータを要求するためにクライアント１０２からアプリケーション・サーバ１０６へ送信するメッセージ；
（Ｇ）キー応答メッセージ（ＫＥＹ＿ＲＥＰ）：サブキーおよびアプリケーション特定データを含むアプリケーション・サーバ１０６からクライアント１０２への応答メッセージ；
（Ｈ）セキュリティ確立済みメッセージ（ＳＥＣ＿ＥＳＴＡＢＬＩＳＨＥＤ）：セキュリティが確立したことを示すクライアント１０２からアプリケーション・サーバ１０６へのメッセージ。
【００１４】
各メッセージは、通常、ヘッダとその後に続くメッセージ本体を含む。この場合、ヘッダはすべてのメッセージに対して共通である。例を挙げて説明すると、ヘッダは、メッセージ・タイプ・フィールド、プロトコル・バージョン番号フィールド、およびチェックサムを含むことができる。メッセージ・タイプ・フィールドは、ＡＳ＿ＲＥＱ、ＡＳ＿ＲＥＰ等のようなメッセージ・タイプを示す。メッセージ・ヘッダの直後には、好適には、タイプ長値フォーマットの形である属性のリストを有するメッセージ本体が続く。
【００１５】
クライアント１０２は、ＫＤＣ１０４の一部でもあるＴＧＳサーバ１１０に対するチケットであるＴＧＴチケットを入手したい場合、ＡＳ＿ＲＥＱメッセージを生成して、クライアント１０２とＡＳサーバ１０８（ＫＤＣ１０４の一部）との間で認証サービスの交換を開始する。すなわち、クライアント１０２は、アプリケーション・サーバ１０６のような特定のアプリケーション・サーバに対するＳＴチケットを要求する目的で、クライアントが使用するＴＧＴチケットを入手するために、ＡＳサーバ１０８にＡＳ＿ＲＥＱメッセージを送信する。例を挙げて説明すると、ＡＳ＿ＲＥＱメッセージは、クライアントのＩＤ（例えば、名前）、ＴＧＳサーバ１１０のＩＤ、およびそれを応答に結びつけるためのノンス（ｎｏｎｃｅ）を含むことができる。ＡＳ＿ＲＥＱメッセージは、また、クライアント１０２がサポートしている対称暗号化アルゴリズムのリストを含むことができる。また、このメッセージは、再試行に対する確認を行なうために、タイムスタンプおよびメッセージの保全性のための署名を含むことができる。署名は、キーによるチェックサムまたはデジタル署名であってもよい。
【００１６】
署名を確認するための公開キーは、好適には、ユーザのデータベース内に保持することが好ましい。任意で、ＡＳ＿ＲＥＱメッセージ内にデジタル証明書を備え、デジタル署名を確認するために記憶している公開キーの代わりにそのデジタル証明書を使用してもよい。キーによるチェックサムを確認するためのクライアント１０２の永久対称キーは、好適には、同じユーザ・データベース内に保持することが好ましい。ＡＳ＿ＲＥＱメッセージは、また、キーの一致のために必要な公開キー情報（例えば、楕円曲線ディフィー・ヘルマン・パラメータ（ＥｌｌｉｐｔｉｃＣｕｒｖｅＤｉｆｆｉｅ−Ｈｅｌｌｍａｎｐａｒａｍｅｔｅｒｓ））も含むことができる。例を挙げて説明すると、楕円曲線法は、その処理速度が速いので、公開キーの暗号化に使用することができる。楕円曲線法は、ＲＳＡと比較すると１桁または２桁速い。ラインダール（Ｒｉｊｎｄａｅｌ）暗号化規格は、１２８ビットのキーの長さと一緒に使用することができる。
【００１７】
ＡＳサーバ１０８は、ＡＳ＿ＲＥＱメッセージを確認するためにＡＳ＿ＲＥＱメッセージを処理する。ＡＳ＿ＲＥＱを処理してもエラーが全く発生しない場合には、ＡＳサーバ１０８はＡＳ＿ＲＥＱメッセージに応じてＡＳ＿ＲＥＰメッセージを生成する。より詳細に説明すると、ＡＳサーバ１０８は、データベース内でＴＧＳサーバ１１０およびクライアント１０２のキーを探し、ＫＤＣ１０４による後続の認証のためにランダム・セッションキーを生成する。ＡＳサーバ１０８は、平文部分および暗号化部分の双方を含むＴＧＴチケットを生成する。ＴＧＳサーバ１１０のＩＤおよびチケット有効期間は、発行したＴＧＴチケット内に平文で提供され得る。チケットの暗号化部分は、クライアント１０２の名前、セッションキーおよび機密が保持されるべき任意の他のデータを含む。チケットは、また、ＫＤＣ１０４がサポートしている暗号化のタイプとチェックサムのタイプのリストを提供することが好ましい。チケットの暗号化部分は、ＫＤＣ１０４の秘密キーを用いて暗号化され得る。
【００１８】
好適には、ＡＳ＿ＲＥＰメッセージは、ＫＤＣ１０４によって、ＡＳ＿ＲＥＱメッセージに対する署名を生成するためにクライアント１０２が使用したのと同じアルゴリズムを用いて署名されることが好ましい。この署名は、デジタル署名であってもよいし、クライアント１０２の秘密キーを使用するキーによるチェックサムであってもよい。公開キー情報は、キー一致パラメータのＫＤＣ１０４の公開部分であり、クライアント１０２が選択したものと同じキー一致アルゴリズムを示さなければならない。最後に、ＡＳ＿ＲＥＰメッセージは、繰り返しを防止するために、ＡＳ＿ＲＥＱメッセージからコピーされたノンスを含んでいることが好ましい。
【００１９】
ＡＳ＿ＲＥＰメッセージの暗号化部分は、好適には、クライアント１０２がそれ自身の許可データに読出し専用アクセスを行うことができるように、ＴＧＴチケットと同じ情報を含んでいることが好ましい。しかし、このことは本発明の要件ではない。この任意選択的な機能は、アプリケーション・サーバは、チケット内の暗号化されているクライアント情報のコピーのみを信用するために、クライアント１０２がそれ自身の許可データを知っている場合には、クライアントは後でアプリケーション・サーバにより何らかの方法で拒否される動作を試行しないため、ユーザにとって便利である。また、ユーザが自身の許可データをハッキングしたり変更したりするのを防止するハードウェア・セキュリティを有するクライアントに対しては、読出し可能な許可データは、例えば、ローカル・ディスク上で映画を保存したり、再生する権利のようなある種のローカル動作をクライアントに許可することもできるため、この任意選択的な機能はセキュリティ上の有利であり得る。ＡＳ＿ＲＥＰメッセージの暗号化部分は、同様に、この応答が元々はこの特定のクライアント１０２のためにＫＤＣ１０４が作成したものであることを確認するために、クライアント１０２のＩＤを含んでいることが好ましい。このデータは、好適には、キー一致アルゴリズムから入手した対称キーにより暗号化されることが好ましい。
【００２０】
クライアント１０２は、ＡＳ＿ＲＥＰメッセージを処理して、その信頼性を確認し、メッセージ内の秘密のチケット部分を解読してＴＧＴチケットを入手する。ＡＳ＿ＲＥＰメッセージの信頼性が確認できない場合には、クライアント１０２は、ＡＳサーバ１０８にエラー・メッセージを返送しないことが好ましい。場合によっては、クライアントは、他のＡＳ＿ＲＥＱメッセージで再試行することができる。
【００２１】
本発明は、クライアント１０２およびＫＤＣ１０４が、デジタル証明書により相互に認証を行うことができるように、任意でＡＳ＿ＲＥＱおよびＡＳ＿ＲＥＰメッセージの双方でデジタル証明書を送ることができる。証明書がない場合には、クライアント１０２がすでにＫＤＣの公開キーを提供されており、ＫＤＣ１０４がすでにそのデータベース内にクライアント１０２の公開キーを有していることが考えられる。ＡＳ＿ＲＥＱ上のデジタル署名は、そのデータベース内で探すクライアントの公開キーで、ＫＤＣ１０４により確認される。クライアント１０２は、予め提供されているＫＤＣの公開キーでＡＳ＿ＲＥＰ上のデジタル署名を確認する。
【００２２】
クライアント１０２が、ＡＳサーバ１０８との交換によりＴＧＴチケットを入手した後、クライアント１０２は、クライアント１０２がアプリケーション・サーバ１０６のような所与のまたは特定のアプリケーション・サーバに対する認証信用証明書を入手したい場合には、クライアント１０２とＴＧＳサーバ１１０との間でＴＧＳ＿ＲＥＱメッセージの交換を開始する。ＴＧＳ＿ＲＥＱメッセージは、（ＫＥＹ＿ＲＥＱメッセージで使用することができる）アプリケーション・サーバ・サービス・チケット（ＳＴチケット）を入手するために、クライアント１０２により生成され、ＴＧＳサーバ１１０に送られる。クライアント１０２は、ＴＧＳ＿ＲＥＱメッセージの一部として、ＡＳ＿ＲＥＰメッセージから入手したＴＧＴチケットを提示する。ＴＧＳ＿ＲＥＱメッセージは、アプリケーション・サーバ１０６のＩＤおよびクライアント１０２のＩＤ（ＴＧＴチケット内の）を指定する。クライアント１０２のＩＤはＴＧＴチケットの暗号化された部分内に存在し、メッセージの平文には含まれていないため、このＩＤは保護されている。ＴＧＴチケットからのセッションキーは、ＴＧＳ＿ＲＥＱ交換の際の暗号化および解読に使用することができる。したがって、スヌーパー（ｓｎｏｏｐｅｒ）は、クライアント（すなわち、ユーザ）がどのサービスを要求しているのかを検出することができない。
【００２３】
クライアント１０２がＴＧＳ＿ＲＥＱメッセージを送信した後、クライアントは、好適には、ＫＤＣ１０４から一致するＴＧＳ＿ＲＥＰメッセージを後で確認するためにノンスを保存する。クライアント１０２は、構成可能なタイムアウト値が時間切れになるまで、ノンスを保持することが好ましい。タイムアウトの後では、クライアント１０２は、もはや対応するＴＧＳ＿ＲＥＰを処理することはできないので、再試行を行わなければならない。
【００２４】
ＴＧＳサーバ１１０は、ＴＧＳ＿ＲＥＱメッセージを確認し、ＴＧＴチケットを処理する。ＴＧＳサーバ１１０は、次に、ＴＧＳ＿ＲＥＱメッセージに応じてＴＧＳ＿ＲＥＰメッセージを生成する。ＴＧＳ＿ＲＥＰメッセージは、ＫＤＣ１０４によって発行された（エンド・サービス・チケットである）ＳＴチケットを含む。クライアント１０２は、サービスを要求する必要がある場合に、このＳＴチケットをアプリケーション・サーバ１０６に提示する。アプリケーション・サーバ１０６のＩＤおよびチケット有効期間は、発行されたＳＴチケット内に平文で提供され得る。ＳＴチケットの暗号化部分は、クライアント１０２の名前およびアプリケーション・サーバ１０６とＫＤＣ１０４とが共有するキーで暗号化されたセッションキーを含む。秘密にしておく必要がある任意の付加的なクライアント・データを、ＳＴチケットの暗号化部分として内蔵させることができる。ＫＤＣ１０４は、ＴＧＴチケットのセッションキーを使用して、キーによるチェックサムでＴＧＳ＿ＲＥＰメッセージに署名する。最後に、ＴＧＳ＿ＲＥＰメッセージは、繰り返しを防止するために、ＴＧＳ＿ＲＥＱメッセージからコピーしたノンスを含む。
【００２５】
例を挙げて説明すると、ＴＧＳサーバ１１０は、下記手順によりＴＧＳ＿ＲＥＰメッセージを生成することができる。まず、ＴＧＳ＿ＲＥＱメッセージからのノンスをＴＧＳ＿ＲＥＰメッセージに含めて、それを要求に結びつける。次に、ＫＤＣ１０４が、ランダム（サービス・チケット）セッションキーのタイプを割り当てる。２つ以上の暗号化アルゴリズムを使用できる場合には、ＫＤＣ１０４は、好適には、最も強力なアルゴリズムを選択することが好ましい。次に、ＫＤＣ１０４は、ＳＴチケットを生成する。アプリケーション・サーバ１０６の秘密キーを用いて、暗号化されたチケット部分を暗号化し、また全ＳＴチケット上のキーによるチェックサムを生成する。ＳＴチケットの終了時間は、好適には、ＫＤＣ１０４によって決定されることが好ましい。クライアント１０２は、所望により、より短い有効期間を指定することができる。ＳＴチケットの暗号化された部分は、クライアント１０２のＩＤ、セッションキーおよび他の秘密データを含む。ＴＧＴチケットのセッションキーは、ＴＧＳ＿ＲＥＰメッセージの暗号化されたデータ部分を生成するために使用され、キーによるチェックサム（ＴＧＴセッションキーを使用する）は、ＴＧＳ＿ＲＥＰメッセージ上に追加される。この場合も、これは、ＴＧＳサーバ１１０が、ＴＧＳ＿ＲＥＰメッセージを生成するために使用することができる手順の一例にすぎない。
【００２６】
クライアント１０２の名前は、ＴＧＳ＿ＲＥＰメッセージ内のＳＴチケットの暗号化部分に含まれており、平文では送信されないので、クライアントのＩＤは隠されており、このクライアントのＩＤをクライアント１０２がアプリケーション・サーバ１０６から要求するコンテンツとリンクさせることができない。この方法では、スヌーパーは、クライアント１０２が、どのアプリケーション・サーバと通信したいのかを判定することができない。本発明は、特定のアプリケーション・サーバに対するクライアントからのチケット要求へのＫＤＣの応答が、チケット内で暗号化されているクライアント名の他に、平文でのクライアント名を含んでいるケルベロスとは異なる。実際には、本発明を使用した場合、クライアント１０２の名前が平文で提供される唯一のメッセージはＡＳ＿ＲＥＱメッセージである。この場合、セキュリティはまだ確立しておらず、クライアント１０２は、まだ特定のアプリケーション・サーバを要求または識別していないため、問題にはならない。
【００２７】
例を挙げて説明すると、クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージを処理するために、下記の手順を使用することができる。最初に、クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージのヘッダをパーズする（ｐａｒｓｅ）。ヘッダのパージング（ｐａｒｓｉｎｇ）が失敗した場合には、クライアント１０２は、ＴＧＳ＿ＲＥＰを受信しなかったかのように動作する。クライアント１０２は、ＴＧＳサーバ１１０にエラー・メッセージを返送しないことが好ましい。場合によっては、クライアント１０２は、別のＴＧＳ＿ＲＥＱメッセージにより再試行を行う。未処理のＴＧＳ＿ＲＥＱメッセージが存在する場合には、クライアント１０２はタイムアウトになり再試行が行われるまで、応答を待ち続ける。次に、クライアント１０２は、ヘッダ内のプロトコル・バージョン番号を確認する。このプロトコル・バージョンがサポートされていない場合には、クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージを受信しなかったかのように動作する。クライアント１０２は、次にメッセージの残りの部分をパーズする。メッセージ・フォーマットが不当なものであることが分かった場合には、クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージを受信しなかったかのように動作する。
【００２８】
次に、クライアント１０２は、同じノンスを含む未処理のＴＧＳ＿ＲＥＱメッセージを探す。そのようなメッセージがない場合には、クライアントは、メッセージを受信しなかったかのように処理を進める。そのようなメッセージがあった場合には、クライアント１０２は（ＴＧＳチケット・セッションキーを使用して）チェックサムを確認する。チェックサムが確認されない場合には、このメッセージは廃棄され、クライアント１０２はメッセージを受信しなかったかのように処理を進める。
【００２９】
次に、クライアントは、ＴＧＴチケット・セッションキーを使用して、ＴＧＳ＿ＲＥＰメッセージ内の秘密チケット部分を解読する。ＴＧＴチケット・セッションキーのタイプと暗号化されたデータのタイプが一致しないために、秘密チケット部分を解読できない場合には、ユーザに致命的なエラーが報告され、クライアント１０２は再試行を行わない。結果として得られる平文が、フォーマット・エラーを含んでいる場合、このクライアント１０２がサポートしていないタイプのセッションキーを含んでいる場合、または要求と一致しないクライアントＩＤを含んでいる場合には、同様に、ユーザに致命的なエラーが報告され、クライアント１０２は再試行を行わない。
【００３０】
クライアント１０２は、次に、ＳＴチケットを処理する。ＳＴチケットがエラーを含んでいる場合には、ユーザに致命的なエラーとして報告され、クライアント１０２は、他のＴＧＳ＿ＲＥＱメッセージによる再試行を行わない。ＴＧＳ＿ＲＥＰメッセージでエラーが検出されなかった場合には、クライアント１０２は、そのチケットのキャッシュ内の新しいエントリ内に全ＳＴチケットおよび平文の秘密チケット部分を保存する。
【００３１】
アプリケーション・サーバ１０６は、キー管理を開始したい場合に、ＴＫＴ＿ＣＨＡＬＬＥＮＧＥメッセージを使用する。サービス攻撃の否認を防止するために、このメッセージは、アプリケーション・サーバ１０６によって生成されたランダムな値であるサーバ・ノンス・フィールドを含む。クライアント１０２は、後続のＫＥＹ＿ＲＥＱメッセージ内にこのサーバノンスの正確な値を含むことが好ましい。また、このＴＫＴ＿ＣＨＡＬＬＥＮＧＥメッセージは、好適には、そのアプリケーション・サーバに対する正確なチケットを発見または入手するためにクライアント１０２によって使用されるアプリケーション・サーバ１０６の領域および主な名称も含む。
【００３２】
ＫＥＹ＿ＲＥＱおよびＫＥＹ＿ＲＥＰメッセージは、クライアント１０２とアプリケーション・サーバ１０６との間において、キー管理および認証のために使用される。ＫＥＹ＿ＲＥＱメッセージは、新しい一組のセキュリティ・パラメータを確立するために、クライアント１０２によりアプリケーション・サーバ１０６に送られる。好適には、クライアント１０２が、ＴＫＴ＿ＣＨＡＬＬＥＮＧＥメッセージを受信した場合には何時でも、クライアント１０２はＫＥＹ＿ＲＥＱメッセージによって応答することが好ましい。また、クライアント１０２は、アプリケーション・サーバ１０６との新しいキーを周期的に確立するために、ＫＥＹ＿ＲＥＱメッセージを使用することができる。クライアント１０２は、ＴＧＳ＿ＲＥＰメッセージで予め入手した有効なＳＴチケットにより開始する。アプリケーション・サーバ１０６は、自身がチケットを解読し、確認するために使用することができるそのサービスキーにより開始する。ＫＥＹ＿ＲＥＱメッセージは、ＳＴチケットおよびクライアント１０２の認証のために必要なキーによるチェックサムを含む。また、ＫＥＹ＿ＲＥＱメッセージは、好適には、（それを応答ＫＥＹ＿ＲＥＰメッセージに結びつけるための）ノンスおよび（繰り返し攻撃を防止するための）クライアントのタイムスタンプを含むことが好ましい。
【００３３】
クライアント１０２がＫＥＹ＿ＲＥＱメッセージを生成した場合、クライアント１０２のＩＤは、ＳＴチケットの暗号化された部分に含まれているので、メッセージの平文部分には含まれていない。クライアント１０２がＫＥＹ＿ＲＥＱメッセージを送信した後で、クライアント１０２は、アプリケーション・サーバ１０６からの一致するＫＥＹ＿ＲＥＰメッセージを後で確認するために、クライアントのノンス値を保存する。クライアント１０２は、構成可能なタイムアウト値が時間切れになるまで、クライアントのノンス値を保持する。タイムアウトの後で、クライアント１０２は、もはや対応するＫＥＹ＿ＲＥＰメッセージを処理することはできない。クライアント１０２が要求していないのに、ＫＥＹ＿ＲＥＱメッセージが送信された場合には、クライアント１０２はこのタイムアウトの後で再試行を行い得る。
【００３４】
アプリケーション・サーバ１０６は、ＫＥＹ＿ＲＥＱメッセージに応答して、ＫＥＹ＿ＲＥＰメッセージを送信する。例を挙げて説明すると、ＫＥＹ＿ＲＥＰメッセージは、クライアント１０２とアプリケーション・サーバ１０６とが共有するセッションキーにより暗号化された、ランダムに生成したサブキーを含むことができる。ＫＥＹ＿ＲＥＰメッセージは、また、セキュリティ・パラメータを確立するのに必要な付加的な情報を含むことができる。
【００３５】
最後に、クライアント１０２は、クライアント１０２がＫＥＹ＿ＲＥＰメッセージを受信し、新しいセキュリティ・パラメータの設定に成功したことを肯定応答するために、ＳＥＣ＿ＥＳＴＡＢＬＩＳＨＥＤメッセージをアプリケーション・サーバ１０６に送信する。
【００３６】
図２を参照すると、この図は、アプリケーション・サーバからコンテンツを要求した場合に、クライアントのプライバシーを提供するための方法２００を示す。例を挙げて説明すると、この方法２００は、ＫＤＣ１０４および上記の適当なメッセージ・タイプにより実施することができる。ステップ２０２において、ＴＧＴチケットに対する要求が、クライアント１０２のようなクライアントから受信される。ステップ２０４において、内部に暗号化されたクライアントのＩＤを含むＴＧＴチケットが生成される。ステップ２０４は、例えば、ＡＳサーバ１０８により実行することができる。ステップ２０６において、ＴＧＴチケットがクライアントに送信される。このステップは、またＡＳサーバ１０８により実行される。ステップ２０８において、特定のアプリケーション・サーバへのＳＴチケットに対する要求がクライアントから受信される。ＳＴチケットに対する要求は、ＴＧＴチケットを含み、平文にクライアントのＩＤを含んでいない。ステップ２１０において、例えば、ＴＧＳサーバ１１０により実行することができる、内部に暗号化されたクライアントのＩＤを含むＳＴチケットが生成される。ステップ２１２において、平文でクライアントのＩＤを提供しないで、ＳＴチケットがクライアントに送信される。この送信もＴＧＳサーバ１１０により行うことができる。
【００３７】
本発明は、公衆サーバのようなサーバからコンテンツを要求した場合に、改善されたユーザのプライバシーを提供するための方法およびシステムを提供する。クライアントが、特定のアプリケーション・サーバ（例えば、コンテンツ・プロバイダ）に対してチケットを要求するすべてのキー管理メッセージ内でクライアント名またはＩＤが暗号化されるため、プライバシーが改善される。これにより、標準ケルベロスの不都合が克服される。
【００３８】
今まで、その特定の実施形態および用途により本発明を説明してきたが、当業者であれば、特許請求の範囲に記載する本発明の範囲から逸脱することなく、本発明に対して種々の修正および変更を行うことができる。
【図面の簡単な説明】
【００３９】
【図１】本発明のある実施形態により構成したシステムのブロック図。
【図２】本発明のある実施形態によるアプリケーション・サーバからコンテンツを要求した場合、クライアントのプライバシーを提供するための方法を示すフローチャート。

Claims

アプリケーション・サーバからコンテンツを要求した場合に、クライアントのプライバシーを提供するための方法であって、
クライアントからチケット交付チケット（ＴＧＴチケット）に対する要求を受信するステップと、
内部に暗号化されたクライアントのＩＤを有するＴＧＴチケットを生成するステップと、
クライアントにＴＧＴチケットを送信するステップと、
ＴＧＴチケットを含み、かつ平文でクライアントのＩＤを提供しない、クライアントからアプリケーション・サーバへのサービス・チケット（ＳＴチケット）に対する要求を受信するステップと、
内部に暗号化されたクライアントのＩＤを含むＳＴチケットを生成するステップと、
平文でクライアントのＩＤを提供することなく、クライアントにＳＴチケットを送信するステップとを含む方法。
ＴＧＴチケットに対する要求を受信するステップが、認証サーバによりＴＧＴチケットに対する要求を受信するステップを含む、請求項１に記載の方法。
ＴＧＴチケットを生成するステップが、認証サーバによりＴＧＴチケットを生成するステップを含む、請求項１に記載の方法。
クライアントにＴＧＴチケットを送信するステップが、認証サーバ応答メッセージの一部として、クライアントにＴＧＴチケットを送信するステップを含む、請求項１に記載の方法。
アプリケーション・サーバに対するＳＴチケットの要求を受信するステップが、チケット交付サーバによりアプリケーション・サーバへのＳＴチケットに対する要求を受信するステップを含む、請求項１に記載の方法。
アプリケーション・サーバに対するＳＴチケットに対する要求が、アプリケーション・サーバのＩＤを指定する、請求項１に記載の方法。
ＳＴチケットを生成するステップが、チケット交付サーバによりＳＴチケットを生成するステップを含む、請求項１に記載の方法。
クライアントにＳＴチケットを送信するステップが、チケット交付サーバ応答メッセージの一部としてＳＴチケットをクライアントに送信するステップを含む、請求項１に記載の方法。
クライアントにＴＧＴチケットを送信するステップが、平文でクライアントのＩＤを提供することなく、クライアントにＴＧＴチケットを送信するステップを含む、請求項１に記載の方法。
クライアントにＴＧＴチケットを送信するステップが、読出し専用の形態でクライアント自身の認可データのコピーと一緒に、クライアントにＴＧＴチケットを送信するステップを含む、請求項１に記載の方法。
アプリケーション・サーバからコンテンツを要求した場合に、クライアントのプライバシーを提供するためのシステムであって、
クライアントからチケット交付チケット（ＴＧＴチケット）に対する要求を受信し、内部に暗号化されたクライアントのＩＤを含むＴＧＴチケットを生成し、そのＴＧＴチケットをクライアントに送信するように構成されている認証サーバと、
ＴＧＴチケットを含み、平文でクライアントのＩＤを提供しないクライアントからアプリケーション・サーバに対するサービス・チケット（ＳＴチケット）の要求を受信し、内部に暗号化されたクライアントのＩＤを含むＳＴチケットを生成し、平文でクライアントにＩＤを提供することなく、クライアントにＳＴチケットを送信するように構成されているチケット交付サーバとを備えるシステム。
認証サーバおよびチケット交付サーバが、キー配布センター（ＫＤＣ）の少なくとも一部を形成する、請求項１１に記載のシステム。
認証サーバが、さらに、認証サーバ応答メッセージの一部として、クライアントにＴＧＴチケットを送信するように構成されている、請求項１１に記載のシステム。
認証サーバが、さらに、平文でクライアントのＩＤを提供することなく、クライアントにＴＧＴチケットを送信するように構成されている、請求項１１に記載のシステム。
チケット交付サーバが、さらに、チケット交付サーバ応答メッセージの一部として、クライアントにＳＴチケットを送信するように構成されている、請求項１１に記載のシステム。