JP6802772B2 - コンテンツを取得するクライアント装置 - Google Patents

Description

本発明は、コンテンツ名に基づきルーティングするネットワークからコンテンツを取得するクライアント装置に関する。

コンテンツを示す名前に基づきコンテンツをルーティングして配信を行うネットワークが提案されている。非特許文献１は、その様なネットワークの１つであるコンテンツ・セントリック・ネットワーク（ＣＣＮ：Ｃｏｎｔｅｎｔ Ｃｅｎｔｒｉｃ Ｎｅｔｗｏｒｋｉｎｇ）を開示している。

ＣＣＮにおいて、コンテンツを公開するサーバ装置は当該コンテンツを１つ以上のチャンクと呼ばれるオブジェクトに分割し、クライアント装置は、この分割されたオブジェクト単位でコンテンツを取得する。なお、コンテンツと区別するため、分割されたその部分をオブジェクトと呼ぶが、オブジェクトもまた１つのコンテンツである。また、ＣＣＮにおいて、オブジェクトの転送を行った通信装置（以下、転送装置と呼ぶ。）は、当該オブジェクトを保存（キャッシュ）できる。この転送装置は、自装置がキャッシュしているオブジェクトを要求するインタレスト・パケット（要求メッセージ）をクライアント装置から受信すると、当該インタレスト・パケットをサーバ装置に向けて転送することなく、自装置が保持するオブジェクトを、当該インタレスト・パケットの送信元のクライアント装置に向けて送信できる。

以下に、転送装置の動作の一例を説明する。転送装置は、ＣＳ（Ｃｏｎｔｅｎｔｓ Ｓｔｏｒｅ）と、ＦＩＢ（Ｆｏｒｗａｒｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）と、ＰＩＴ（ＰＩＴ：Ｐｅｎｄｉｎｇ Ｉｎｔｅｒｅｓｔ Ｔａｂｌｅ）を管理する。ＣＳは、自装置が保持しているオブジェクトを示す情報である。ＦＩＢは、インタレスト・パケットと、当該インタレスト・パケットを転送すべきインタフェースとの関係を示す情報である。ＰＩＴは、転送したインタレスト・パケットが要求するオブジェクトと、当該転送したインタレスト・パケットを受信したインタフェースとの関係を示す情報である。

転送装置は、インタレスト・パケットを受信すると、ＣＳを検索し、当該インタレスト・パケットが要求するオブジェクトを保持しているか否かを判定する。保持している場合には、自装置が保持しているオブジェクトを、当該インタレスト・パケットの送信元のクライアント装置に向けて送信する。一方、受信したインタレスト・パケットが要求するオブジェクトを保持していない場合には、ＰＩＴを検索して、当該インタレスト・パケットと同じオブジェクトを要求するインタレスト・パケットを既に転送し、当該オブジェクトの受信待ちの状態であるかを判定する。受信待ちの状態であると、受信したインタレスト・パケットを転送せず、当該インタレスト・パケットの受信インタフェースを、当該インタレスト・パケットが要求するオブジェクトに関連付ける様にしてＰＩＴを更新する。一方、受信したインタレスト・パケットが要求するオブジェクトの受信待ちでなければ、ＦＩＢに基づき判定したインタフェースから当該インタレスト・パケットを転送すると共にＰＩＴを更新する。また、転送装置は、オブジェクトを受信すると、当該オブジェクトの転送先インタフェースをＰＩＴに基づき判定し、当該オブジェクトに関する情報をＰＩＴから削除する。また、転送装置は、受信して転送したオブジェクトを保存するとＣＳを更新する。

ここで、公開するコンテンツを、特定のサービス会員等、所定のユーザに限定したい場合、各オブジェクトをそれぞれ、所定のユーザが有する暗号鍵で暗号化する必要がある。例えば、第１サービスのユーザは、第１アプリケーションを使用してコンテンツを取得し、第２サービスのユーザは、第２アプリケーションを使用してコンテンツを取得するものとする。なお、第１アプリケーションは暗号鍵Ａを使用し、第２アプリケーションは暗号鍵Ｂを使用しているものとする。この場合、同じオブジェクトであっても、第１アプリケーションに配信する場合には暗号鍵Ａで暗号化する必要があり、第２アプリケーションに配信する場合には暗号鍵Ｂで暗号化する必要がある。したがって、転送装置が、第１アプケーションに配信した暗号鍵Ａで暗号化されたオブジェクトをキャッシュしたとしても、当該キャッシュしているオブジェクトを、第２アプリケーションに向けて配信することはできない。

非特許文献２は、転送装置の一部に、再暗号化機能を設ける構成を開示している。再暗号化機能を有する転送装置は、暗号化されたオブジェクトをキャッシュしている場合において、当該暗号化されたオブジェクトを要求するインタレスト・パケットをクライアント装置から受信すると、当該クライアント装置が使用している暗号鍵で復号できる様に、キャッシュしているオブジェクトの再暗号化を行って、当該クライアント装置に送信する。

Ｖ．Ｊａｃｏｂｓｏｎ，ｅｔ ａｌ．，"Ｎｅｔｗｏｒｋｉｎｇ Ｎａｍｅｄ Ｃｏｎｔｅｎｔ"，ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＡＣＭ ＣｏＮＥＸＴ ２００９，２００９年１２月 Ｎ. Ｆｏｔｉｏｕ，ｅｔ ａｌ．，"Ｓｅｃｕｒｉｔｙ Ｃｏｎｔｅｎｔ Ｓｈａｒｉｎｇ ｏｖｅｒ ＩＣＮ"，ＡＣＭ ＩＣＮ'１６、京都、２０１６年９月

しかしながら、非特許文献２の構成では、再暗号化機能を設けた転送装置以外の転送装置でキャッシュされている暗号化されたオブジェクトは、当該暗号化に使用された暗号鍵を使用しないアプリケーションに向けて配信することはできない。

本発明は、転送装置がキャッシュしているオブジェクトの暗号化に使用されている暗号鍵に拘らず、転送装置がキャッシュしているオブジェクトを取得することができるクライアント装置を提供するものである。

本発明の一側面によると、コンテンツ名に基づきルーティングするネットワークからコンテンツを取得するクライアント装置は、コンテンツを取得する１つ以上のアプリケーションを動作させるアプリケーション手段であって、前記１つ以上のアプリケーションは対応する暗号鍵を有し、コンテンツを取得する前に前記ネットワークに、当該コンテンツの再暗号化鍵を要求する第１要求パケットを送信し、コンテンツを取得する際には、当該コンテンツを要求する第２要求パケットを前記ネットワークに送信する、前記アプリケーション手段と、前記第１要求パケットの応答としてコンテンツの再暗号化鍵を受信すると、前記第１要求パケットを送信したアプリケーションと、受信した前記コンテンツの再暗号化鍵との関係を管理情報に追加し、かつ、受信した前記コンテンツの再暗号化鍵を保存し、前記第２要求パケットの応答としてコンテンツを受信すると、前記第２要求パケットを送信したアプリケーションと、受信した前記コンテンツと、前記管理情報と、に基づき、保存している再暗号化鍵から受信した前記コンテンツを再暗号化するための再暗号化鍵を選択し、選択した再暗号化鍵に基づき受信した前記コンテンツを再暗号化して前記第２要求パケットを送信したアプリケーションに送信する処理手段と、を備えていることを特徴とする。

本発明によると、転送装置がキャッシュしているオブジェクトの暗号化に使用されている暗号鍵に拘らず、転送装置がキャッシュしているオブジェクトを取得することができる。

一実施形態によるクライアント装置の構成図。 一実施形態による再暗号化鍵取得処理のシーケンス図。 一実施形態によるＰＩＴを示す図。 一実施形態による名前変換テーブル及び管理テーブルを示す図。 一実施形態によるコンテンツ取得処理のシーケンス図。 一実施形態によるＰＩＴを示す図。

以下、本発明の例示的な実施形態について図面を参照して説明する。なお、以下の実施形態は例示であり、本発明を実施形態の内容に限定するものではない。また、以下の各図においては、実施形態の説明に必要ではない構成要素については図から省略する。

図１は、本実施形態によるクライアント装置の構成図である。クライアント装置は、スマートフォン、タブレット等の携帯型端末や、パーソナルコンピュータ等の通信端末であり、ＣＣＮの様なコンテンツ名に基づきルーティングを行うネットワークを介してコンテンツを取得する。なお、以下では、ネットワークがＣＣＮであるものとして本実施形態の説明を行うが、コンテンツ名に基づきルーティングを行うネットワークからコンテンツを取得する任意のクライアント装置に本発明を適用することができる。アプリケーション部３０は、複数のアプリケーションを実行する。図１によると、アプリケーション１と、アプリケーション２が実行されている。ここで、アプリケーション１は、暗号鍵（以下、単に、鍵と表記する。）Ａで暗号化されたコンテンツを復号することができる。また、アプリケーション２は、鍵Ｂで暗号化されたコンテンツを復号することができる。

転送処理部１０は、ＣＣＮの転送装置と同様の処理を行う。具体的には、転送処理部１０は、ＰＩＴ、ＦＩＢ、ＣＳを管理し、インタレスト・パケット及びデータ・パケットの転送処理を行う。なお、本実施形態において、転送処理部１０が管理するＦＩＢは、コンテンツ名フィールドが"ＡＣ"で始まるパケットをプロキシ部２０に転送し、それ以外のパケットをネットワークに転送することを示している。

プロキシ部２０は、管理テーブルと名前変換テーブルを管理し、転送処理部１０から受信するパケットを処理して転送処理部１０に送信する。プロキシ部２０における処理の詳細については後述する。

アプリケーション１及びアプリケーション２は、コンテンツを取得するに当たり、まず、再暗号化鍵を取得する。以下では、アプリケーション１及びアプリケーション２がそれぞれ、"ＣＮ１"をコンテンツ名（オブジェクト名）とするコンテンツ（以下、コンテンツＣＮ１と表記。）を取得するための再暗号化鍵を取得する処理について図２を用いて説明する。なお、転送処理部１０のＣＳは、コンテンツをキャッシュしていないものとする。また、コンテンツＣＮ１は、鍵Ｃで暗号化されて配信されているものとする。つまり、コンテンツＣＮ１を公開しているサーバ装置や、ネットワーク内の転送装置は、コンテンツＣＮ１については、鍵Ｃで暗号化されたコンテンツ・データを保持又はキャッシュしている。さらに、本実施形態において、再暗号化鍵は、ネットワーク内の転送装置においてキャッシュすることが禁止されているものとする。つまり、再暗号化鍵を要求するインタレスト・パケットは、常に、サーバ装置に送信されるものとする。

Ｓ１で、アプリケーション１は、コンテンツ名フィールドに"／ＡＣ／Ａｐｐ１／ＣＮ１／ＫＲ／Ｎ１／"を設定したインタレスト・パケットを転送処理部１０に送信する。なお、"ＡＣ"に続く"Ａｐｐ１"は、アプリケーション１を示している。また、コンテンツ名"ＣＮ１"に続く"ＫＲ"は、再暗号化鍵の要求であることを示している。さらに、"ＫＲ"に続く"Ｎ１"は、ナンス値である。なお、ナンス値としては、ランダム値を使用することができるが、アプリケーション１に固有の値とすることや、ランダム値とアプリケーション１に固有の値との組み合わせを使用することができる。また、アプリーション１が送信するインタレスト・パケットには、アプリケーション１が使用する鍵Ａと、クライアント装置のユーザの認証情報、例えば、ユーザ識別子及びパスワードが含まれている。上述した様に、コンテンツ名フィールドが"ＡＣ"で始まるため、転送処理部１０は、Ｓ１で受信するインタレスト・パケットをプロキシ部２０に転送する。したがって、転送処理部１０のＰＩＴには、図３（Ａ）に示す様に、受信したインタレスト・パケットのコンテンツ名フィールドに設定された"／ＡＣ／Ａｐｐ１／ＣＮ１／ＫＲ／Ｎ１／"の応答として受信するデータ・パケットの送信先がアプリケーション１であることを示すエントリが追加される。

プロキシ部２０は、コンテンツ名フィールドが"ＡＣ"で始まるインタレスト・パケットを受信すると、その宛先からプレフィクス"／ＡＣ／Ａｐｐ１"を削除し、コンテンツ名フィールドに"／ＣＮ１／ＫＲ／Ｎ１／"が設定されたインタレスト・パケットをＳ２で転送処理部１０に送信する。また、図４（Ａ）の番号＃１のエントリに示す様に、Ｓ２で送信したコンテンツ名フィールドが"／ＣＮ１／ＫＲ／Ｎ１／"であるインタレスト・パケットが、アプリケーション１（Ａｐｐ１）から受信したことを示すエントリを名前変換テーブルに追加する。

転送処理部１０は、Ｓ２で、コンテンツ名フィールドに"／ＣＮ１／ＫＲ／Ｎ１／"が設定されたインタレスト・パケットを受信するが、上述した様に、コンテンツ名フィールドが"ＡＣ"で始まらないため、転送処理部１０は、Ｓ２で受信したインタレスト・パケットをＦＩＢに従いネットワークに転送する。したがって、転送処理部１０のＰＩＴには、図３（Ｂ）の番号＃２のエントリとして示す様に、コンテンツ名フィールドに"／ＣＮ１／ＫＲ／Ｎ１／"が設定されたデータ・パケットの送信先がプロキシ部２０（プロキシ）であることを示すエントリが追加される。

Ｓ３で、アプリケーション２は、コンテンツ名フィールドに"／ＡＣ／Ａｐｐ２／ＣＮ１／ＫＲ／Ｎ２／"を設定したインタレスト・パケットを転送処理部１０に送信する。コンテンツ名フィールドの"ＡＣ"に続く"Ａｐｐ２"は、アプリケーション２を示している。また、"ＫＲ"に続く"Ｎ２"は、ナンス値である。また、当該インタレスト・パケットには、アプリケーション２が使用する鍵Ｂと認証情報が含まれている。Ｓ１の処理と同様に、転送処理部１０は、Ｓ３で受信したインタレスト・パケットをプロキシ部２０に転送する。したがって、転送処理部１０のＰＩＴには、図３（Ｃ）の番号＃３のエントリが追加される。Ｓ２の処理と同様に、プロキシ部２０は、Ｓ３で受信したインタレスト・パケットのコンテンツ名フィールドに設定された値からプレフィクス"／ＡＣ／Ａｐｐ２"を削除し、コンテンツ名フィールドに"／ＣＮ１／ＫＲ／Ｎ２／"が設定されたインタレスト・パケットをＳ４で転送処理部１０に送信する。インタレスト・パケットのコンテンツ名フィールドを変換したため、プロキシ部２０は、図４（Ａ）の番号＃２のエントリに示す様に、Ｓ４で送信したコンテンツ名フィールドが"／ＣＮ１／ＫＲ／Ｎ２／"であるインタレスト・パケットが、アプリケーション２（Ａｐｐ２）から受信したことを示すエントリを名前変換テーブルに追加する。Ｓ２での処理と同様に、転送処理部１０は、Ｓ４で受信したコンテンツ名フィールドが"／ＣＮ１／ＫＲ／Ｎ２／"であるインタレスト・パケットをネットワークに転送し、図３（Ｄ）の番号＃４のエントリをＰＩＴに追加する。

Ｓ４の処理の終了時点において、クライアント装置は、コンテンツ名フィールドが"／ＣＮ１／ＫＲ／Ｎ１／"であるインタレスト・パケットと、コンテンツ名フィールドが"／ＣＮ１／ＫＲ／Ｎ２／"であるインタレスト・パケットの２つのインタレスト・パケットをネットワークに送信している。上述した様に、本実施形態において、再暗号化鍵はネットワーク内の転送装置においてキャッシュすることが禁止されており、よって、２つのインタレスト・パケットは、コンテンツＣＮ１に関する再暗号化鍵を管理しているサーバ装置に送信される。当該サーバ装置は、受信するインタレスト・パケットに含まれる認証情報に基づき認証を行い、認証が成功すると、コンテンツＣＮ１の暗号化に使用している鍵Ｃで暗号化された暗号化データを、インタレスト・パケットに含まれる鍵で暗号化された暗号化データに再暗号化するための再暗号化鍵を生成する。つまり、コンテンツ名フィールドが"／ＣＮ１／ＫＲ／Ｎ１／"であるインタレスト・パケットに対しては、鍵Ｃで暗号化された暗号化データを、鍵Ａで暗号化された暗号化データに変換するための再暗号化鍵ＣＡを生成し、コンテンツ名フィールドが"／ＣＮ１／ＫＲ／Ｎ２／"であるインタレスト・パケットに対しては、鍵Ｃで暗号化された暗号化データを、鍵Ｂで暗号化された暗号化データに変換するための再暗号化鍵ＣＢを生成する。そして、サーバ装置は、生成した再暗号化鍵を含むデータ・パケットをネットワークに送信する。このデータ・パケットには、それぞれ、データ・パケットの送信のトリガとなった、インタレスト・パケットのコンテンツ名フィールドの値が、そのコンテンツ名フィールドに設定される。

転送処理部１０は、Ｓ５で、サーバ装置が送信した再暗号化鍵ＣＡを含むデータ・パケットを受信する。このデータ・パケットには、"／ＣＮ１／ＫＲ／Ｎ１／"が含まれているため、転送処理部１０は、図３（Ｄ）の番号＃２に示すエントリに基づき、このデータ・パケットをプロキシ部２０に転送する。なお、転送後、番号＃２のエントリはＰＩＴから削除される。プロキシ部２０は、Ｓ５で受信したデータ・パケットに含まれる"／ＣＮ１／ＫＲ／Ｎ１／"と名前変換テーブルに基づき、当該データ・パケットのトリガとなったインタレスト・パケットを送信したアプリケーションを判定する。図４（Ａ）の番号＃１で示すエントリに基づき、ここでは、アプリケーション１が判定される。プロキシ部２０は、アプリケーション１を判定すると、図４（Ｂ）の番号＃１のエントリを管理テーブルに追加する。図４（Ｂ）の番号＃１のエントリは、アプリケーション１がコンテンツＣＮ１を取得する際に再暗号化鍵ＣＡを使用することを示している。また、プロキシ部２０は、再暗号化鍵ＣＡを保存する。さらに、プロキシ部２０は、名前変換テーブルに基づき、Ｓ５で受信したデータ・パケットに含まれる"／ＣＮ１／ＫＲ／Ｎ１／"を、"／ＡＣ／Ａｐｐ１／ＣＮ１／ＫＲ／Ｎ１／"に変換してＳ６で転送処理部１０に送信する。なお、変換後、プロキシ部２０は、図４（Ａ）の番号＃１のエントリを削除する。転送処理部１０は、図３（Ｄ）の番号＃１に示すエントリに基づき、このデータ・パケットをアプリーション１に転送する。転送後、番号＃１のエントリはＰＩＴから削除される。なお、再暗号化鍵は、プロキシ部２０が使用し、アプリケーションでは使用しないため、Ｓ６で送信するデータ・パケットには再暗号化鍵を含めない構成とすることもできる。Ｓ６で、データ・パケットをアプリケーション１に送信するのは、再暗号化鍵の取得が完了したことを、アプリケーション１に通知するためである。

Ｓ７及びＳ８の処理は、Ｓ５及びＳ６の処理と同様であり再度の説明は省略する。図２の処理が完了することで、プロキシ部２０が管理する管理テーブルは図４（Ｂ）に示す様になる。

続いて、アプリケーション１及びアプリケーション２が、コンテンツＣＮ１を取得する処理について図５を用いて説明する。Ｓ１１で、アプリケーション１は、コンテンツ名フィールドに"／ＡＣ／Ａｐｐ１／ＣＮ１／"を設定したインタレスト・パケットを転送処理部１０に送信する。コンテンツ名フィールドが"ＡＣ"で始まるため、転送処理部１０は、受信するインタレスト・パケットをプロキシ部２０に転送する。したがって、転送処理部１０のＰＩＴには、図６（Ａ）に示すエントリが追加される。

プロキシ部２０は、コンテンツ名フィールドが"ＡＣ"で始まるインタレスト・パケットを受信すると、プレフィクス"／ＡＣ／Ａｐｐ１"を削除し、コンテンツ名フィールドに"／ＣＮ１／"が設定されたインタレスト・パケットをＳ１２で転送処理部１０に送信する。また、プロキシ部２０は、図４（Ｃ）の番号＃１のエントリに示す様に、Ｓ１２で送信した、コンテンツ名フィールドが"ＣＮ１"であるインタレスト・パケットをアプリケーション１（Ａｐｐ１）から受信したことを示すエントリを名前変換テーブルに追加する。

転送処理部１０は、Ｓ１２で、コンテンツ名フィールドが"／ＣＮ１／"であるインタレスト・パケットを受信するが、上述した様に、コンテンツ名フィールドが"ＡＣ"で始まらないため、転送処理部１０は、Ｓ１２で受信したインタレスト・パケットをＦＩＢに従いネットワークに転送する。したがって、転送処理部１０のＰＩＴには、図６（Ｂ）の番号＃２のエントリが追加される。

Ｓ１３で、アプリケーション２は、コンテンツ名フィールドに"／ＡＣ／Ａｐｐ２／ＣＮ１／"を設定したインタレスト・パケットを転送処理部１０に送信する。Ｓ１１の処理と同様に、転送処理部１０は、Ｓ１３で受信したインタレスト・パケットをプロキシ部２０に転送する。したがって、転送処理部１０のＰＩＴには、図６（Ｃ）の番号＃３のエントリが追加される。Ｓ１２の処理と同様に、プロキシ部２０は、Ｓ１３で受信したインタレスト・パケットのコンテンツ名フィールドの値からプレフィクス"／ＡＣ／Ａｐｐ２"を削除し、コンテンツ名フィールドが"／ＣＮ１／"であるインタレスト・パケットをＳ１４で転送処理部１０に送信する。変換後のインタレスト・パケットのコンテンツ名フィールドの値は"／ＣＮ１／"であり、この宛先は、図４（Ｃ）に示す様に、既に名前変換テーブルのエントリとして存在するため、プロキシ部２０は、図４（Ｄ）に示す様に、送信したコンテンツ名フィールドが"／ＣＮ１／"であるインタレスト・パケットをアプリケーション２（Ａｐｐ１）からも受信したことを示す様に名前変換テーブルの番号＃１のエントリを更新する。

転送処理部１０は、Ｓ１４で、コンテンツ名フィールドが"／ＣＮ１／"であるインタレスト・パケットを受信するが、ＰＩＴには、図６（Ｃ）に示す様に、コンテンツ名フィールドが"／ＣＮ１／"であるインタレスト・パケットを転送したことを示すエントリ（番号＃３）が存在する。なお、番号＃３のエントリのインタフェース欄にはプロキシ部２０が示されており、Ｓ１４で受信したインタレスト・パケットの送信元と同じであるため、転送処理部１０は、Ｓ１４で受信したインタレスト・パケットを単に廃棄する。

したがって、アプリケーション１及びアプリケーション２がそれぞれ、コンテンツＣＮ１を要求するインタレスト・パケットを送信したが、ネットワークに送信されるインタレスト・パケットは１つとなる。このインタレスト・パケットの応答として、転送処理部１０は、Ｓ１５で、鍵Ｃで暗号化されたコンテンツＣＮ１を含むデータ・パケットを受信する。なお、このデータ・パケットの送信元は、サーバ装置又はネットワーク内においてコンテンツＣＮ１をキャッシュしていた転送装置である。転送処理部１０は、この受信したデータ・パケットを、図６（Ｃ）に示すＰＩＴの番号＃３のエントリに従い、プロキシ部２０に転送する。

プロキシ部２０は、Ｓ１５でコンテンツ名フィールドが"／ＣＮ１／"であるデータ・パケットを受信すると、名前変換テーブルに基づき、どのアプリケーションがコンテンツＣＮ１を取得しようとしているのかを判定する。図４（Ｄ）に示す名前変換テーブルに基づき、アプリケーション１及びアプリケーション２であることが判定される。この場合、プロキシ部２０は、図４（Ｂ）に示す管理テーブルに基づき、鍵Ｃで暗号からされたコンテンツＣＮ１の再暗号化を行う。具体的には、管理テーブルの番号＃１のエントリに従い、プロキシ部２０は、Ｓ１６で、アプリケーション１のために、再暗号化鍵ＣＡを使用して再暗号化を行う。これにより、鍵Ａで暗号化されたコンテンツＣＮ１が生成される。同様に、管理テーブルの番号＃２のエントリに従い、プロキシ部２０は、Ｓ１７で、アプリケーション２のために、再暗号化鍵ＣＢを使用して再暗号化を行う。これにより、鍵Ｂで暗号化されたコンテンツＣＮ１が生成される。プロキシ部２０は、Ｓ１８で、名前変換テーブルに従って生成したコンテンツ名フィールドが"／ＡＣ／Ａｐｐ１／ＣＮ１／"であるデータ・パケットを転送処理部１０に送信する。なお、このデータ・パケットには、鍵Ａで暗号化されたコンテンツＣＮ１が含められる。転送処理部１０は、図６（Ｃ）の番号＃１のエントリに従い、このデータ・パケットをアプリケーション１に転送する。同様に、プロキシ部２０は、Ｓ１９で、名前変換テーブルに従って生成したコンテンツ名フィールドが"／ＡＣ／Ａｐｐ２／ＣＮ１／"であるデータ・パケットを転送処理部１０に送信する。なお、このデータ・パケットには、鍵Ｂで暗号化されたコンテンツＣＮ１が含められる。転送処理部１０は、図６（Ｃ）の番号＃３のエントリに従い、このデータ・パケットをアプリケーション２に転送する。

以上、本実施形態によると、コンテンツを取得する際、アプリケーションは、それぞれが使用している暗号鍵で暗号化されたデータに変換するための再暗号化鍵をサーバに要求する。サーバは、要求（インタレスト・パケット）に含まれる認証情報により、ユーザの正当性を検証すると、再暗号化鍵をクライアント装置に送信する。この構成により、ネットワーク側の構成を変更することなく、総ての転送装置でキャッシュされている暗号化されたコンテンツを、アプリケーションに拘らず配信することができる。

また、本実施形態においてプロキシ部２０は、アプリケーションより先にコンテンツを含むデータ・パケットを受信し、プロキシ部２０にて再暗号化を行う。例えば、インストールされたアプリケーションに悪意のあるアプリケーションが含まれている場合、管理テーブルの当該悪意のあるアプリケーションに関するエントリを使用不可に設定することで、該悪意のあるアプリケーションがコンテンツを取得することを防ぐことができる。

なお、本発明によるクライアント装置は、コンピュータを上記クライアント装置として動作させるプログラムにより実現することができる。これらコンピュータプログラムは、コンピュータが読み取り可能な記憶媒体に記憶されて、又は、ネットワーク経由で配布が可能なものである。

１０：転送処理部、２０：プロキシ部、３０：アプリケーション部

Claims (5)

1. コンテンツ名に基づきルーティングするネットワークからコンテンツを取得するクライアント装置であって、
   コンテンツを取得する１つ以上のアプリケーションを動作させるアプリケーション手段であって、前記１つ以上のアプリケーションは対応する暗号鍵を有し、コンテンツを取得する前に前記ネットワークに、当該コンテンツの再暗号化鍵を要求する第１要求パケットを送信し、コンテンツを取得する際には、当該コンテンツを要求する第２要求パケットを前記ネットワークに送信する、前記アプリケーション手段と、
   アプリケーションと、コンテンツの再暗号化鍵との関係を管理する管理情報を保持する保持手段と、
   前記第１要求パケットの応答としてコンテンツの再暗号化鍵を受信すると、前記第１要求パケットを送信したアプリケーションと、受信したコンテンツの再暗号化鍵との関係を前記管理情報に追加し、かつ、受信したコンテンツの再暗号化鍵を保存し、前記第２要求パケットの応答としてコンテンツを受信すると、前記第２要求パケットを送信したアプリケーションと受信したコンテンツに対応する再暗号化鍵を前記管理情報に基づき判定し、判定した再暗号化鍵に基づき受信したコンテンツを再暗号化して前記第２要求パケットを送信したアプリケーションに送信する処理手段と、
   を備えていることを特徴とするクライアント装置。
2. 前記第１要求パケットは、前記第１要求パケットを送信したアプリケーションに対応する暗号鍵を含み、
   前記第１要求パケットの応答として受信する前記コンテンツの再暗号化鍵は、コンテンツ鍵で暗号化されている前記コンテンツのデータを、前記第１要求パケットを送信したアプリケーションに対応する暗号鍵で暗号化されたデータに再暗号化するために使用されることを特徴とする請求項１に記載のクライアント装置。
3. コンテンツの再暗号化鍵を要求する前記第１要求パケットの宛先は、前記コンテンツの名前と、前記第１要求パケットを送信したアプリケーションに関連付けられた名前と、を含むことを特徴とする請求項１又は２に記載のクライアント装置。
4. コンテンツの再暗号化鍵を要求する前記第１要求パケットの宛先は、前記コンテンツの名前と、ナンス値と、を含むことを特徴とする請求項１又は２に記載のクライアント装置。
5. 請求項１から４のいずれか１項に記載のクライアント装置としてコンピュータを機能させることを特徴とするプログラム。

Images