JP5620999B2 - プライベートデジタルコンテンツにアクセスするためのシステムおよび方法 - Google Patents

Description

本発明は、プライベートデジタルコンテンツにアクセスするためのシステムおよび方法に関する。

ＰｅＣＭａｎは、ユーザによって提供されたタグ（情報）を用いて、ウェブオブジェクト（データ）のリストをＵＲＬ（参照）の形で維持するウェブアプリケーションである。これらのタグは、次いで、その情報の元の寄与者（主要なユーザ）がその参照およびデータを（再度）見出すことを可能にするため、またはその情報およびデータを他者（参加者ユーザ）と共有するために使用される。これらの参加者は、友人であってよく、家族であってよく、または、一般に、集団であってよい。ＰｅＣＭａｎの動作モデルは、ＰｅＣＭａｎは参照およびタグだけを維持し、参照されたオブジェクト自体がユーザのホスト上で実行しているアプリケーションによって取り出されることである。したがって、参加者ユーザのための手順は、ＰｅＣＭａｎに少数のタグを入力して、ＰｅＣＭａｎがそれらのタグをその情報とマッチさせて、参照をユーザに返し、その時点で、ユーザは参照されたデータの取得を試みることになるというものである。

ウェブから情報を取得するためのＰｅＣＭａｎ方法は、公的に利用可能なデータには効果があるが、プライベート共有データには機能しない。プライベート共有データは、背後に記憶されたオブジェクトの参照、例えば、パスワードで保護されたウェブサイトである。この場合、ユーザは、参照されたデータを提供しているウェブサービスにログインする必要がある。これは、参照されたデータの所有者がそのデータを探している同じユーザである場合、かなり簡単である。しかし、プライベートデータを参加者と共有することは難題であり、そのデータの主要な所有者がそのサービスに関する資格情報を参加者に提供できる場合だけ実現され得る。先行技術によれば、非共有コンテンツと共有コンテンツとをサポートするために、主要ＰｅＣＭａｎサーバは、一般に、指定されているＵＲＬと共にユーザ資格情報を記憶する。プライベートコンテンツがアドレス指定されている場合、参加者ＰｅＣＭａｎクライアントは、ＰｅＣＭａｎサーバに対する通信チャネルをセットアップし、ＰｅＣＭａｎサーバは、次いで、参加者ＰｅＣＭａｎクライアントに代わってストレージプロバイダに対する接続を確立する、すなわち、ＰｅＣＭａｎサーバは、参加者ＰｅＣＭａｎクライアントのプロキシの機能を果たす。ＰｅＣＭａｎにおけるこのデータ共有方法の欠点は、すべてのプライベートデータがＰｅＣＭａｎプロキシを通じて送信されることである。これは、ＰｅＣＭａｎがプライベートコンテンツにアクセスするためのボトルネックになる可能性があることを意味する。

欧州特許出願公開第０９ ３０５ ５００．２号明細書

Ｂｕｔｌｅｒ Ｌａｍｐｓｏｎ他、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｉｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ：Ｔｈｅｏｒｙ ａｎｄ Ｐｒａｃｔｉｃｅ」、ＡＣＭ Ｔｒａｎｓ．Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ １０、４、１９９２年１１月、２６５−３１０頁

本発明の実施形態によれば、コンテンツ管理サーバが遠隔コンテンツサーバに対するセキュアなトンネルを確立することを可能にして、特定の資格情報、一般的には、ユーザＩＤとパスワードとを提供することによって自らを許可し、そのトンネルに関して新しいセッション鍵を確立して、一般には、ユーザ装置内に存在するクライアントが、コンテンツ管理サーバであるかのように、そのクライアントがそのコンテンツサーバとの会話を継続することを可能にするために、新しく確立されたセッション鍵を用いて、そのクライアントに信号伝達するための改善された方法およびシステムが提供される。

本発明の一実施形態によれば、コンテンツサーバ上にインストールされたプライベートデジタルコンテンツに対するアクセスを提供するための方法が提供され、コンテンツマネージャサーバは、プライベートコンテンツに潜在的に関心を持ついくつかのクライアントを有する。本方法は、コンテンツ管理サーバで実行される：
− いくつかのクライアントの１つのクライアントとの第１の通信チャネルを確立するステップと、
− プライベートデジタルコンテンツに関する問合せをクライアントから受信して、適切な応答を送り、これが、一般に、クライアントがコンテンツサーバとの第２の通信チャネルを確立するためのトリガとなるステップと、
− 第１の通信チャネルと第２の通信チャネルとを介してコンテンツサーバとセキュアなセッションを確立するステップと、
− セキュアなセッションに関する新しいセッション鍵を確立して、前記新しいセッション鍵をクライアントＣ（ｂ）に送信するステップとを含む。一般に、新しいセッション鍵を確立する前に、第１の通信チャネルと第２の通信チャネルとを介して確立されたセキュアなセッションを通じてデータ要求がコンテンツサーバに送られることになり、例えば、セキュアなコンテンツサーバの場合、ログイン資格情報が提供される。

本発明の本方法のこの実施形態は、そのクライアントがコンテンツ管理サーバであるかのように、そのクライアントが問い合わされたプライベートデジタルコンテンツをコンテンツサーバから取得することを可能にすることになる。

本発明の文脈で、コンテンツ管理サーバは、広い意味で、例えば、写真、ビデオなど、複数のユーザのパブリックデジタルコンテンツ、ならびに／またはプライベート共有デジタルコンテンツおよび／もしくはプライベート非共有デジタルコンテンツを管理できる任意のサーバを指すと解釈されるべきである。このコンテンツ自体は、局所的に記憶されることが可能であり、または遠隔位置に記憶されることも可能である。そのようなコンテンツ管理サーバの例は、Ｆｌｉｃｋｒ、ＹｏｕｔＴｕｂｅなどのコンテンツプロバイダによって使用されているような、単純なコンテンツ管理サーバ、ＰｅＣＭａｎ、ＳｅｃｏｎｄＢｒａｉｎ、ｉＧｏｏｇｌｅなど、任意のタイプのコンテンツアグリゲータ、任意のタイプの所有者のプロキシ、選択的なプロキシ機能を備えたプロキシなどである。

本発明の文脈で、コンテンツサーバは、一般に、セキュアなコンテンツサーバを指し、例えば、セキュアなウェブサーバであってよい。その他の例は、ファイル共有機能を備えたローカルディスク、コンピュータがコンテンツサーバとして機能するように、サーバプログラムをインストールしている任意のコンピュータなどである。

好ましい実施形態によれば、セキュアなセッションを確立するステップは、以下のセキュアなトンネル、すなわち、ＳＳＬトンネル／ＴＬＳトンネル、ＥＳＰトンネルのうちのいずれか１つを確立するステップにある。さらに、第１の通信チャネルおよび／または第２の通信チャネルを確立するステップは、好ましくは、第１のＴＣＰセッション／ＩＰセッションおよび／または第２のＴＣＰセッション／ＩＰセッションを確立するステップにある。

好ましい実施形態によれば、ウェブサーバは、ＳＳＬ／ＴＬＳに関して可能にされたクライアント認証機構を維持し、コンテンツサーバとセキュアなセッションを確立するステップは、クライアントノードを認証するステップを含む。

本発明の別の実施形態によれば、コンテンツ管理サーバのクライアントによってプライベートデジタルコンテンツを取得するための方法が提供され、そのプライベートコンテンツはコンテンツサーバ上にインストールされる。本方法は、クライアントによって実行される：
− コンテンツ管理サーバとの第１の通信チャネルを確立するステップと、
− プライベートデジタルコンテンツに関する問合せをコンテンツ管理サーバに送るステップと、
− コンテンツサーバとの第２の通信チャネルを確立するステップであって、前記問合せが、一般に、コンテンツ管理サーバに第１の通信チャネルと第２の通信チャネルとを介してコンテンツサーバとセキュアなセッションをセットアップさせて、前記セキュアなセッションを通じてデータ要求をコンテンツサーバに送らせる、確立するステップと、
− 第２のセキュアなセッションに関して確立された新しいセッション鍵を受信するステップと、
− 新しいセッション鍵を使用して、問い合わされたプライベートデジタルコンテンツをコンテンツサーバから取得するステップとを含む。

本方法は、そのクライアントがコンテンツ管理サーバであるかのように、クライアントがプライベートデジタルコンテンツを取得することを可能にする。

１つの可能な実施形態によれば、クライアントとコンテンツ管理サーバとの間に第１のセキュアなセッションが確立されて、前記第１のセキュアなセッションを通じて新しいセッション鍵が受信される。そのような実施形態では、第１の通信チャネルと第２の通信チャネルとを介したセキュアなセッションは、第１のセキュアなセッションを使用することが可能である。

さらに、本発明は、複数のクライアントのプライベートデジタルコンテンツを編成するためのコンテンツ管理サーバに関する。本発明の一実施形態によれば、コンテンツ管理サーバは、
プライベートデジタルコンテンツに関する問合せを前記クライアントから受信した後で、コンテンツサーバとクライアントの間の第１の通信チャネルと、前記クライアントとコンテンツ管理サーバとの間に確立された第２の通信チャネルとを含む、連結されたチャネルを介してコンテンツサーバとセキュアなセッションを確立して、
セキュアな接続を通じてデータ要求をコンテンツサーバに送り、
セキュアなセッションに関する新しいセッション鍵を確立して、前記新しいセッション鍵をクライアントＣ（ｂ）に送信するように構成される。

さらに、本発明は、プライベートデジタルコンテンツにアクセスするためのシステムであって、
− コンテンツ管理サーバと、
− デジタルプライベートコンテンツを備えたコンテンツサーバと、
− いくつかのクライアントであって、クライアントが、新しいセッション鍵を受信して、デジタルプライベートコンテンツをコンテンツサーバから取得するためにその新しいセッション鍵を使用するように構成された、いくつかのクライアントとを備えるシステムに関する。

最後に、本発明は、プログラムがコンピュータ上で実行されるとき、上で開示された方法のうちのいずれかを実行するためのコンピュータ実行可能命令を備えたコンピュータプログラム製品に関する。

添付の図面は、本発明の現在好ましい非限定的な例示的な実施形態を示すために使用される。添付の図面と共に読まれたとき、以下の詳細な説明から、本発明の上記のおよびその他の特徴の利点および目的はより明らかになり、本発明はより良好に理解されよう。

ＰｅＣＭａｎシステムを使用した、本発明によるシステムの一実施形態を例示する図である。 本発明の方法およびシステムの一実施形態において使用される通信システムの構造を例示する図である。 本発明の方法を実施するための一実施形態によるコールフローを例示する図である。

本発明の１つの例示的な実施形態は、コンテンツ管理サーバとして、パーソナルコンテンツマネージメント（ＰｅＣＭａｎ）サーバを参照して下で例示されるが、当業者は、本発明は、上で定義された（所有者のプロキシを含めて）任意のタイプのコンテンツ管理サーバに適用可能であることを理解されよう。ＰｅＣＭａｎは、文書、写真、ビデオなど、ユーザのデジタルコンテンツを編成するウェブツールである。図１は、本発明の一実施形態で使用されるＰｅＣＭａｎアーキテクチャの概略図を示す。ユーザは、それを経由して、ユーザが、例えば、文書を追加、除去、またはタグ付けできるクライアント３（例えば、ウェブクライアント、デスクトップクライアント、またはＰＤＡ上のクライアントなど）を使用して、ＰｅＣＭａｎサーバ１と対話する。クライアント３からの着信要求４は、システムによって処理されるためにＰｅＣＭａｎサーバ１によって受信される。このシステムは、文書から抽出されたメタデータ、またはタグの形でユーザが生成したメタデータを記憶するためのメタデータセクション（図示せず）をさらに備える。

ユーザは、例えば、ＰｅＣＭａｎ内にＵＲＬをアップロードして、フリーフォーマットタグ（ｆｒｅｅ−ｆｏｒｍａｔ ｔａｇｓ）を用いてその情報を意味的にタグ付けして、後で、同じタグを用いてＰｅＣＭａｎに問い合わせることによって、その情報を再び見出すことができる。同じタグを用いて複数のＵＲＬにタグ付することができるため、ＰｅＣＭａｎは、ユーザが、１つの論理位置アキン（ｌｏｇｉｃａｌ ｌｏｃａｔｉｏｎ ａｋｉｎ）「仮想ドライブ」を通じて、多数のストレージプロバイダ（例えば、ウェブサーバ、ホーム記憶装置、またはメールサーバ）上に維持されたすべてのオブジェクトを編成することを可能にする。

ＰｅＣＭａｎは、３種類の参照、すなわち、パブリックコンテンツと、プライベート非共有コンテンツと、プライベート共有コンテンツとを認識する。パブリックコンテンツは、公的に利用可能なウェブソースを指定するＵＲＬである。そのようなコンテンツにアクセスすることは、ユーザ資格情報を必要とせず、これは、そのコンテンツに関心を持つ誰とでもそのようなコンテンツを容易に共有できることを意味する。ユーザ同士の間で公的な情報が共有されるとき、ＰｅＣＭａｎは、要求されるＵＲＬを要求しているＰｅＣＭａｎクライアントまたは二次ＰｅＣＭａｎクライアントに単に直接的に送り、二次ＰｅＣＭａｎクライアントは、例えば、ＷｅｂＤａｖまたはＨＴＴＰを通じてそのコンテンツを取り出す。

プライベートコンテンツは、一般に、セキュアな位置、一般に、セキュアなウェブサイト（すなわち、ストレージプロバイダ）を通じてだけアクセスされ得るコンテンツである。セキュアなストレージプロバイダ２にアクセスするために、ウェブクライアント３は、まず、例えば、ＳＳＬ／ＴＬＳを通じて、セキュアな接続６を確立し、次いで、ユーザを認証するために、ユーザ資格情報（一般に、ユーザＩＤおよびパスワード）を提供する。ユーザが認証された後で、ウェブクライアント３は、ウェブ問合せ７を経由して、プライベートに記憶されたコンテンツにアクセスすることが可能である。一般に、アドレス指定されたウェブサーバ２内に、通信チャネルに関連する状態が割り当てられる。この状態は、要求しているウェブクライアント３が自らを認証したことをウェブサーバ２に示す。

先行技術によれば、プライベート非共有コンテンツおよびプライベート共有コンテンツをサポートするために、ＰｅＣＭａｎは、一般に、指定されているＵＲＬと共にユーザ資格情報を記憶する。プライベートコンテンツがアドレス指定されている場合、二次ＰｅＣＭａｎクライアント３は、ＰｅＣＭａｎ１に対する通信チャネルをセットアップし、ＰｅＣＭａｎ１は、次いで、二次ＰｅＣＭａｎクライアントに代わってストレージプロバイダ２に対する接続を確立し、すなわち、ＰｅＣＭａｎサーバ４は、二次ＰｅＣＭａｎクライアント３に関するプロキシの機能を果たす。このプロキシは、ウェブサーバ２に対するセキュアな接続を維持し、ストレージプロバイダ２にユーザ資格情報を提供するプロキシでもある。ＰｅＣＭａｎは、共有プライベートコンテンツ参照と非共有プライベートコンテンツ参照の両方に関してこれを行う。

ＰｅＣＭａｎにおけるプライベートコンテンツに関するデータ共有の本方法の欠点は、指定されたオブジェクトに関連するすべてのデータがＰｅＣＭａｎプロキシを通じて送信されることである。これは、ＰｅＣＭａｎがプライベートコンテンツにアクセスするためのボトルネックになる可能性があり、料金がＰｅＣＭａｎを通じたデータ転送に関連する場合、ＰｅＣＭａｎオペレータは、プライベートコンテンツを提供するために多額の料金を負う可能性があることを意味する。さらに、ウェブクライアントの領域においてプロキシを実行することは、ユーザのユーザ資格情報が二次ＰｅＣＭａｎクライアントと共有される必要があることを意味することになるため、これは、一般に、選択肢ではない。

プライベート共有コンテンツにアクセスするための代替の手法は、出願人の名義で欧州特許出願第０９ ３０５ ５００．２号で開示されている。

その特許と本特許の間の差異は、前者はすべての参加者がＯＡＵＴＨをサポートし、一方、本特許開示は、この新しい標準を使用せずに、デリゲートされたトンネル（ｄｅｌｅｇａｔｅｄ ｔｕｎｎｅｌ）の確立を可能にすることに依拠する点である。すなわち、ＳＳＬ／ＴＬＳのデリゲーションは、新しいＯＡＵＴＨ標準を使用しないウェブサーバ上で使用され得る。

以下の議論において、ＰｅＣＭａｎサーバ１は、多くの場合、Ｃ（ａ）と呼ばれ、ユーザ装置（電話、パーソナルコンピュータなど）内で動作しているＰｅＣＭａｎクライアントは、多くの場合、Ｃ（ｂ）と呼ばれる。本発明の一実施形態によれば、ＰｅＣＭａｎサーバ１は、ユーザ資格情報を維持し続けて、ウェブサーバ２とＳＳＬセッション／ＴＬＳセッションを確立し、ＰｅＣＭａｎサーバがウェブサーバ２内でログインされると、ＰｅＣＭａｎサーバ１は、ＳＳＬトンネル／ＴＬＳトンネルをＣ（ｂ）にデリゲートする。これがどのように実施されることになるかは、図２および３を参照してさらに説明される。

図３は、本発明の方法を実施する一実施形態を例示する。図３は、ＰｅＣＭａｎサーバＣ（ａ）と、ＰｅＣＭａｎクライアントＣ（ｂ）と、ウェブサーバＣ（ｓ）との間のＳＳＬセッション／ＴＬＳセッションを確立してデリゲートするための７つの段階が区別され得る１つの例示的なシグナリングフローを示す。

第１段階で、ＰｅＣＭａｎクライアントサーバ通信チャネルがセットアップされる。図３のステップ３０１−３０３を参照されたい。この第１段階は、一般に、ＰｅＣＭａｎクライアントＣ（ｂ）が開始されて、ＰｅＣＭａｎサーバＣ（ａ）との第１の通信を確立するときに実行する。まず、ＰｅＣＭａｎクライアントＣ（ｂ）とＰｅＣＭａｎサーバＣ（ａ）との間に通信チャネル２０が確立される。図２を参照されたい。一般に、ＴＣＰ終点は、それぞれの対応ノードの遠隔ＩＰアドレスを記録して、その接続のそれぞれの端部上にプロトコル状態変数を維持する。ＴＣＰセッションは対応ノード同士の間で容易に再配置できず、Ｃ（ｓ）とＣ（ｂ）との間に最終的な通信チャネルが必要とされることを考慮すると、さらなるＴＣＰセッション２１は、一般に、Ｃ（ｂ）とＣ（ｓ）との間に確立されることになる。さらに下記（第３段階）を参照されたい。この図は２つのエンティティ同士の間のＴＣＰセッションの確立を示すが、当業者は、他の通信チャネルがここで適用可能である点を理解されよう。

第２段階で、通信チャネル、詳細には、第１段階で確立されたＴＣＰセッションを使用して、ＰｅＣＭａｎクライアントＣ（ｂ）とＰｅＣＭａｎサーバＣ（ａ）との間にセキュアな通信チャネルが確立される。セキュアな通信チャネルの確立の詳細は、図面において省略されているが、これらのステップは、例えば、下で詳細に説明される第５段階のステップに類似し得る。１つの可能な実施形態によれば、セキュアソケットレイヤ（ＳＳＬ）プロトコルまたはトランスポートレイヤセキュリティ（ＴＬＳ）プロトコル（ＲＦＣ５２４６を参照されたい）など、ネットワークを介した通信に関するセキュリティを提供する暗号化プロトコルが使用される。一般に、クライアントおよびサーバ認証と共に、ＳＳＬセッション／ＴＬＳセッションが使用される。しかし、当業者は、ＲＦＣ４３０３で定義されるカプセル化セキュリティペイロード（ＥＳＰ）トンネルなど、代替のセキュアなトンネル機構も同様に良好に機能することを理解されよう。ＥＳＰは、データストリームのそれぞれのインターネットプロトコル（ＩＰ）パケットを認証して、暗号化することによって、ＩＰ通信をセキュアにするためのインターネットプロトコルセキュリティ（ＩＰｓｅｃ）スイートにおいて使用されるプロトコルである。ＥＳＰは、発信元の真正性と、完全性と、パケットの機密性保護とを提供する。

第３段階（ステップ３０５）において、ＰｅＣＭａｎクライアントＣ（ｂ）は、コンテンツに関してＰｅＣＭａｎサーバＣ（ａ）に問い合わせる。ＰｅＣＭａｎサーバは、その問合せをそのデータベースとマッチさせて、その問合せにマッチするＵＲＬのセットをＰｅＣＭａｎクライアントに返す。ＰｅＣＭａｎクライアントＣ（ｂ）は、次いで、取り出すために１つまたは複数のＵＲＬを選択することになる。この例では、ＵＲＬのうちの少なくとも１つがウェブサーバＣ（ｓ）上のプライベート共有コンテンツを指定し、ＰｅＣＭａｎサーバＣ（ａ）がそのウェブサーバに関するユーザ資格情報を維持し、そのコンテンツを維持しているウェブサーバに対する通信がＳＳＬセッション／ＴＬＳセッションによってセキュアにされることが仮定される。１つの好ましい実施形態によれば、問合せおよび応答要求３０５は、第２段階でセットアップされたセキュアなチャネルを介して送信されることが可能であるか、または別個の通信チャネル（図示せず）を介して平文で送信されることも可能である。

第４段階で、ＰｅＣＭａｎクライアントＣ（ｂ）と遠隔ウェブサーバＣ（ｓ）との間に通信チャネルが確立される。ステップ３０６−３０８を参照されたい。１つの可能な実施形態によれば、この通信チャネルは、単純なＴＣＰ通信チャネルに基づく。

第５段階（図３のステップ３０９−３１２）において、第４段階で確立されたＣ（ｓ）とＣ（ｂ）との間のＴＣＰ通信チャネルと第１の段階でＣ（ｂ）とＣ（ａ）との間に確立されたＴＣＰ通信チャネルとを通じて、ウェブサーバＣ（ｓ）とＰｅＣＭａｎサーバＣ（ａ）との間にＳＳＬセッション／ＴＬＳセッション２２（図２を参照されたい）が確立される。交換されるメッセージに関する詳細は、ＲＦＣ５２４６に見出すことができる。矢印３１０、３１１、および３１２は、１つの単一のメッセージを送ることを表さず、ＲＦＣ５２４６で詳述される、いくつかのメッセージの交換を表す。すなわち、鍵交換は、Ｃ（ｂ）のＴＣＰ終点を通じて、２つの連結されたＴＣＰセッションを使用して、セキュアな終端間チャネルを介してＣ（ｓ）とＣ（ａ）との間で発生し、Ｃ（ｂ）がウェブサーバの資格情報を捕捉することが不可能にされる。これは、Ｃ（ａ）がそのトンネルに関して確立された新しいセッション鍵を使用しているかのように、ＰｅＣＭａｎクライアントＣ（ｂ）がＣ（ｓ）との会話を継続することを可能にすることになる、本発明のこの実施形態の主要な段階である。

Ｃ（ｂ）とＣ（ａ）との間の通信は、第２段階で確立されたＳＳＬトンネル／ＴＬＳトンネルを介して送信されることが可能であるか、またはセキュアでない通信（図示せず）を介して送信されることも可能である。１つの可能な実施形態によれば、クライアントベースの認証が可能にされ得る。そのような場合、Ｃ（ｂ）の証明書が使用されることが可能であり、その場合、Ｃ（ｂ）は、ＳＳＬプロトコル／ＴＬＳプロトコルの最後のメッセージに署名する必要がある（ステップ３０９−３１５）。代替案によれば、Ｃ（ｂ）を証明する新しく導出された証明書は、Ｃ（ａ）によって使用されることが可能である。これは下でさらに説明されることになる。

第５段階の間、一般に、通信チャネルの両端は、正規のＳＳＬ認証機構／ＴＬＳ認証機構を通じて互いを認証する。このために、ウェブサーバＣ（ｓ）は、ＲＦＣ４２１０に定義されているＸ．５０９証明書など、ＰＫＩ内に保持される証明書を維持する。上で説明されたように、（デフォルト設定ではなく）ＳＳＬ／ＴＬＳに関してクライアント認証が可能にされた場合、ウェブサーバは、対応するノード、現在の事例ではＣ（ｂ）を認証する。しかし、ＳＳＬセッション／ＴＬＳセッションがＣ（ｓ）とＣ（ａ）との間でまず確立されるため、Ｃ（ａ）はＣ（ｂ）の証明書を必要とする。Ｃ（ｂ）の証明書は、Ｃ（ｂ）にとってプライベートであり、上で説明されたように、Ｃ（ｂ）のプライベート署名鍵をＣ（ａ）と共有することは望ましくなく、３つのオプションが存在する：
− 正規のＳＳＬ／ＴＬＳの確立手順がとられるが、Ｃ（ｓ）がそれを要求するとき、Ｃ（ａ）はＣ（ｂ）の証明書を再使用する。１つの考えられる実施形態によれば、Ｃ（ａ）は、Ｃ（ａ）がメッセージをＣ（ｓ）に送信する前に、ステップ３１１の最終的なＳＳＬ／ＴＬＳのプロトコルメッセージに署名することをＣ（ｂ）に要求する。代替の実施形態によれば、この手順が開始する前に、Ｃ（ｂ）の証明書はＣ（ａ）に複写される。この複写は、例えば、図３の手順が開始するかなり前に、帯域外で実行され得る点に留意されたい。または、
− Ｃ（ｂ）を証明する新しい証明書が使用されて、Ｃ（ａ）によって保持される。そのような技法は、例えば、Ｂｕｔｌｅｒ Ｌａｍｐｓｏｎ他、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｉｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ：Ｔｈｅｏｒｙ ａｎｄ Ｐｒａｃｔｉｃｅ」、ＡＣＭ Ｔｒａｎｓ．Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ １０、４、１９９２年１１月、２６５−３１０頁で開示されている。この新しい証明書は、Ｃ（ｂ）によって作成されて、署名され、ＳＳＬ／ＴＬＳがクライアント側の認証手順を実行するときに使用される。ウェブサーバＣ（ｓ）は、次いで、Ｃ（ａ）によって保持された、導出された証明書から始めて、鍵階層を横断することによって、その新しい証明書の真正性を検証することが可能である。また、一般に、この手順が開始する前に、新しい証明書はＣ（ａ）に複写される。
− 例えば、証明書の連鎖が可能にされない場合、Ｃ（ａ）は、Ｃ（ｂ）の秘密鍵を用いて証明書に署名することをＣ（ｂ）に要求することが可能である。後者の場合、Ｃ（ｓ）は、Ｃ（ｂ）の公開鍵を通じてＣ（ａ）の証明書を検証することができる。

第６段階で、ＳＳＬ／ＴＬＳの開始手順が完了すると、Ｃ（ｂ）のＴＣＰセッションを通じてデータ要求がウェブサーバＣ（ｓ）とＰｅＣＭａｎサーバＣ（ａ）との間で往復して送られることが可能である。好ましい実施形態によれば、ウェブサーバは、典型的なセキュアなウェブサーバであり、ＰｅＣＭａｎサーバＣ（ａ）は、第５段階でセットアップされたＳＳＬセッション／ＴＬＳセッションを通じてウェブサーバと相互作用することによって、遠隔ウェブサーバＣ（ｓ）に関するユーザ資格情報を提供する。すべての通信がＰｅＣＭａｎクライアントＣ（ｂ）を通過しても、このクライアントはＳＳＬトンネル／ＴＬＳトンネルに関して使用されたセッション鍵の知識を有さないため、このクライアントはメッセージを解読することができない。ウェブサーバは、ウェブページを送り、ユーザがウェブサーバにログインするためにその資格情報を提供することを可能にすることになる。ステップ３１４を参照されたい。この場合、ＰｅＣＭａｎサーバＣ（ａ）は、ユーザＩＤとパスワードとをウェブサーバに提供して、Ｃ（ｂ）のＴＣＰセッションによって一部維持された、セキュアなＳＳＬトンネル／ＴＬＳトンネルを介して、この情報をＣ（ｓ）に送る。ステップ３１５を参照されたい。Ｃ（ｂ）はＳＳＬトンネル／ＴＬＳトンネルに関するセッション鍵を知らないため、Ｃ（ｂ）は、媒介としての機能だけを果たして、終点間のデータバーベイタム（ｄａｔａ ｖｅｒｂａｔｉｍ）を複写することが可能である。ＰｅＣＭａｎサーバＣ（ａ）は、一般に、ログイン手順全体を完了するために、ＳＳＬトンネル／ＴＬＳトンネル上でアクティブな状態に留まる。

第７段階は、Ｃ（ａ）からＣ（ｂ）にＳＳＬトンネル／ＴＬＳトンネルをデリゲートすることにある。第１のＰｅＣＭａｎＣ（ａ）およびウェブサーバＣ（ｓ）は、新しいセッション鍵（図３に図示せず）を確立し、次いで、ＰｅＣＭａｎサーバＣ（ａ）は、ＰｅＣＭａｎクライアントＣ（ｂ）がセキュアなトンネルを維持するために必要とされるすべてのパラメータを送信し、その新しく確立されたセッション鍵は、一般に、重要なパラメータである。ウェブサーバの資格情報がＣ（ｂ）に漏れることを回避するために、新しい鍵を計算することが重要な点に留意されたい。ＰｅＣＭａｎクライアントＣ（ｂ）がセキュアなトンネルを維持するために必要とされるパラメータは、ＳＳＬセッション／ＴＬＳセッションを暗号化／解読するためのパラメータを含む。データはクライアントがデータを要求するときだけ期待されるため、ウェブサーバはこのデリゲーションの間、ＳＳＬセッション／ＴＬＳセッション上でデータを送信しないことが仮定される。送信された暗号化材料は、一般に、平文で送信されてはならないため、デリゲーションに関して必要とされる通信チャネルは、上記の第２段階で確立されたセキュアな通信チャネルである。ＰｅＣＭａｎクライアントが解読材料を有すると、要求がＰｅＣＭａｎサーバＣ（ａ）から送信されたかのように、ＰｅＣＭａｎクライアントは、プライベート共有データをウェブサーバＣ（ｓ）から直接的に取得することが可能である。

本発明の原理は、上で、特定の実施形態に関して記載されているが、この記述は、添付の特許請求の範囲によって決定される保護の範囲の限定としてではなく、単に例示として行われている点を明瞭に理解されたい。

Claims (15)

1. コンテンツサーバＣ（ｓ）上にインストールされたプライベートデジタルコンテンツに対するアクセスを提供するための方法であって、コンテンツ管理サーバＣ（ａ）がプライベートデジタルコンテンツに潜在的に関心を持ついくつかのクライアントを有し、方法が、コンテンツ管理サーバＣ（ａ）で実行される、
   − いくつかのクライアントの１つのクライアントＣ（ｂ）との第１の通信チャネルを確立するステップと、
   − プライベートデジタルコンテンツに関する問合せをクライアントＣ（ｂ）から受信して、適切な応答を送り、クライアントにコンテンツサーバとの第２の通信チャネルを確立させるステップと、
   − 第１の通信チャネルと第２の通信チャネルとを介してコンテンツサーバＣ（ｓ）とセキュアなセッションを確立して、コンテンツサーバＣ（ｓ）にログインするステップと、
   − クライアントがコンテンツ管理サーバであるかのように、クライアントが問い合わされたプライベートデジタルコンテンツをコンテンツサーバから取得することができるように、セキュアなセッションに関する新しいセッション鍵を確立して、前記新しいセッション鍵をクライアントＣ（ｂ）に送信するステップとを含む、方法。
2. 第１の通信チャネルと第２の通信チャネルとを介して確立されたセキュアなセッションを通じてデータ要求をコンテンツサーバに送るステップをさらに含む、請求項１に記載の方法。
3. セキュアなセッションを確立するステップが、以下のセキュアなトンネル、すなわち、ＳＳＬトンネル／ＴＬＳトンネル、ＥＳＰトンネルのうちのいずれか１つを確立するステップにある、請求項１または２に記載の方法。
4. 第１の通信チャネルおよび／または第２の通信チャネルを確立するステップが、第１のＴＣＰセッション／ＩＰセッションおよび／または第２のＴＣＰセッション／ＩＰセッションを確立するステップにある、請求項１から３のいずれかに記載の方法。
5. ウェブサーバＣ（ｓ）がＳＳＬ／ＴＬＳに関して可能にされたクライアント認証機構を維持し、コンテンツサーバＣ（ｓ）とセキュアなセッションを確立するステップが、クライアントノードＣ（ｂ）を認証するステップを含む、請求項１から４のいずれかに記載の方法。
6. クライアントノードＣ（ｂ）を認証するステップが、最終的なＳＳＬ／ＴＬＳのプロトコルメッセージに前記メッセージをコンテンツサーバに送信する前に署名することをクライアントに要求することによって、コンテンツサーバによって要求されたときにクライアントの証明書を再使用することによって可能にされる、請求項５に記載の方法。
7. コンテンツサーバＣ（ｓ）が新しい証明書の真正性を検証することができるように、クライアントノードＣ（ｂ）を認証するステップが、クライアントＣ（ｂ）によって署名されコンテンツ管理サーバＣ（ａ）によって保持される新しい証明書を使用することによって可能にされる、請求項５に記載の方法。
8. コンテンツ管理サーバＣ（ａ）のクライアントＣ（ｂ）によってプライベートデジタルコンテンツを取得するための方法であって、そのプライベートデジタルコンテンツがコンテンツサーバ上にインストールされ、方法が、クライアントによって実行される、
   − コンテンツ管理サーバＣ（ａ）との第１の通信チャネルを確立するステップと、
   − プライベートデジタルコンテンツに関する問合せをコンテンツ管理サーバに送るステップと、
   − コンテンツサーバＣ（ｓ）との第２の通信チャネルを確立するステップであって、前記問合せがコンテンツ管理サーバに第１の通信チャネルと第２の通信チャネルとを介してコンテンツサーバとセキュアなセッションをセットアップさせて、コンテンツサーバＣ（ｓ）にログインさせる、確立するステップと、
   − 第２のセキュアなセッションに関して確立された新しいセッション鍵を受信するステップと、
   − クライアントがコンテンツ管理サーバであるかのように、新しいセッション鍵を使用して、問い合わされたプライベートデジタルコンテンツをコンテンツサーバから取得するステップとを含む、方法。
9. 前記問合せが、さらに、コンテンツ管理サーバに前記セキュアなセッションを通じてデータ要求をコンテンツサーバへ送らせる、請求項８に記載の方法。
10. クライアントＣ（ｂ）とコンテンツ管理サーバＣ（ａ）との間に第１のセキュアなセッションが確立され前記第１のセキュアなセッションを通じて新しいセッション鍵が受信される、請求項８または９に記載の方法。
11. 第１の通信チャネルと第２の通信チャネルとを介したセキュアなセッションが、第１のセキュアなセッションを使用する、請求項８から１０のいずれかに記載の方法。
12. 複数のクライアントのプライベートデジタルコンテンツを編成するためのコンテンツ管理サーバであって、
    プライベートデジタルコンテンツに関する問合せをクライアントから受信した後で、コンテンツサーバとセキュアなセッションを確立して、コンテンツサーバにログインし、
    クライアントがコンテンツ管理サーバであるかのように、クライアントが問い合わされたプライベートデジタルコンテンツをコンテンツサーバから取得することができるように、セキュアなセッションに関する新しいセッション鍵を確立して、前記新しいセッション鍵をクライアントＣ（ｂ）に送信するように構成された、コンテンツ管理サーバ。
13. コンテンツ管理サーバが、ＰｅＣＭａｎサーバなどのコンテンツアグリゲータである、請求項１２のコンテンツ管理サーバ。
14. プライベートデジタルコンテンツにアクセスするためのシステムであって
    − 請求項１２または１３に記載のコンテンツ管理サーバと、
    − プライベートデジタルコンテンツを備えたコンテンツサーバと、
    − いくつかのクライアントとを備え、
    クライアントが、前記新しいセッション鍵を受信して、プライベートデジタルコンテンツをコンテンツサーバから取得するために前記新しいセッション鍵を使用するように構成された、システム。
15. プログラムがコンピュータ上で実行されるとき、請求項１から１１のいずれかに記載の方法を実行するためのコンピュータ実行可能命令を備えたコンピュータプログラム。

Images