特許第6802772号(P6802772)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ KDDI株式会社の特許一覧
<>
  • 特許6802772-コンテンツを取得するクライアント装置 図000002
  • 特許6802772-コンテンツを取得するクライアント装置 図000003
  • 特許6802772-コンテンツを取得するクライアント装置 図000004
  • 特許6802772-コンテンツを取得するクライアント装置 図000005
  • 特許6802772-コンテンツを取得するクライアント装置 図000006
  • 特許6802772-コンテンツを取得するクライアント装置 図000007
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6802772
(24)【登録日】2020年12月1日
(45)【発行日】2020年12月23日
(54)【発明の名称】コンテンツを取得するクライアント装置
(51)【国際特許分類】
   H04L 9/08 20060101AFI20201214BHJP
   H04L 9/14 20060101ALI20201214BHJP
【FI】
   H04L9/00 601B
   H04L9/00 641
【請求項の数】5
【全頁数】11
(21)【出願番号】特願2017-198726(P2017-198726)
(22)【出願日】2017年10月12日
(65)【公開番号】特開2019-75619(P2019-75619A)
(43)【公開日】2019年5月16日
【審査請求日】2019年11月28日
【国等の委託研究の成果に係る記載事項】(出願人による申告)平成28年度 国立開発研究法人情報通信研究機構「欧州との連携による情報指向ネットワーキングに関する実証的研究開発」副題「革新的なアプリケーションとグローバルな実証によるICNの深化」委託研究、産業技術力強化法第19条の適用を受ける特許出願
(73)【特許権者】
【識別番号】000208891
【氏名又は名称】KDDI株式会社
(74)【代理人】
【識別番号】100076428
【弁理士】
【氏名又は名称】大塚 康徳
(74)【代理人】
【識別番号】100115071
【弁理士】
【氏名又は名称】大塚 康弘
(74)【代理人】
【識別番号】100112508
【弁理士】
【氏名又は名称】高柳 司郎
(74)【代理人】
【識別番号】100116894
【弁理士】
【氏名又は名称】木村 秀二
(74)【代理人】
【識別番号】100130409
【弁理士】
【氏名又は名称】下山 治
(74)【代理人】
【識別番号】100134175
【弁理士】
【氏名又は名称】永川 行光
(74)【代理人】
【識別番号】100131886
【弁理士】
【氏名又は名称】坂本 隆志
(74)【代理人】
【識別番号】100170667
【弁理士】
【氏名又は名称】前田 浩次
(72)【発明者】
【氏名】スクソブーン カリカ
(72)【発明者】
【氏名】田上 敦士
(72)【発明者】
【氏名】オニバン バス
(72)【発明者】
【氏名】栗原 淳
【審査官】 児玉 崇晶
(56)【参考文献】
【文献】 特開2016−059022(JP,A)
【文献】 特開2008−020954(JP,A)
【文献】 特開2017−098949(JP,A)
【文献】 特開2010−182296(JP,A)
【文献】 米国特許出願公開第2015/0270957(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/08
H04L 9/14
(57)【特許請求の範囲】
【請求項1】
コンテンツ名に基づきルーティングするネットワークからコンテンツを取得するクライアント装置であって、
コンテンツを取得する1つ以上のアプリケーションを動作させるアプリケーション手段であって、前記1つ以上のアプリケーションは対応する暗号鍵を有し、コンテンツを取得する前に前記ネットワークに、当該コンテンツの再暗号化鍵を要求する第1要求パケットを送信し、コンテンツを取得する際には、当該コンテンツを要求する第2要求パケットを前記ネットワークに送信する、前記アプリケーション手段と、
アプリケーションと、コンテンツの再暗号化鍵との関係を管理する管理情報を保持する保持手段と、
前記第1要求パケットの応答としてコンテンツの再暗号化鍵を受信すると、前記第1要求パケットを送信したアプリケーションと、受信したコンテンツの再暗号化鍵との関係を前記管理情報に追加し、かつ、受信したコンテンツの再暗号化鍵を保存し、前記第2要求パケットの応答としてコンテンツを受信すると、前記第2要求パケットを送信したアプリケーションと受信したコンテンツに対応する再暗号化鍵を前記管理情報に基づき判定し、判定した再暗号化鍵に基づき受信したコンテンツを再暗号化して前記第2要求パケットを送信したアプリケーションに送信する処理手段と、
を備えていることを特徴とするクライアント装置。
【請求項2】
前記第1要求パケットは、前記第1要求パケットを送信したアプリケーションに対応する暗号鍵を含み、
前記第1要求パケットの応答として受信する前記コンテンツの再暗号化鍵は、コンテンツ鍵で暗号化されている前記コンテンツのデータを、前記第1要求パケットを送信したアプリケーションに対応する暗号鍵で暗号化されたデータに再暗号化するために使用されることを特徴とする請求項1に記載のクライアント装置。
【請求項3】
コンテンツの再暗号化鍵を要求する前記第1要求パケットの宛先は、前記コンテンツの名前と、前記第1要求パケットを送信したアプリケーションに関連付けられた名前と、を含むことを特徴とする請求項1又は2に記載のクライアント装置。
【請求項4】
コンテンツの再暗号化鍵を要求する前記第1要求パケットの宛先は、前記コンテンツの名前と、ナンス値と、を含むことを特徴とする請求項1又は2に記載のクライアント装置。
【請求項5】
請求項1から4のいずれか1項に記載のクライアント装置としてコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンテンツ名に基づきルーティングするネットワークからコンテンツを取得するクライアント装置に関する。
【背景技術】
【0002】
コンテンツを示す名前に基づきコンテンツをルーティングして配信を行うネットワークが提案されている。非特許文献1は、その様なネットワークの1つであるコンテンツ・セントリック・ネットワーク(CCN:Content Centric Networking)を開示している。
【0003】
CCNにおいて、コンテンツを公開するサーバ装置は当該コンテンツを1つ以上のチャンクと呼ばれるオブジェクトに分割し、クライアント装置は、この分割されたオブジェクト単位でコンテンツを取得する。なお、コンテンツと区別するため、分割されたその部分をオブジェクトと呼ぶが、オブジェクトもまた1つのコンテンツである。また、CCNにおいて、オブジェクトの転送を行った通信装置(以下、転送装置と呼ぶ。)は、当該オブジェクトを保存(キャッシュ)できる。この転送装置は、自装置がキャッシュしているオブジェクトを要求するインタレスト・パケット(要求メッセージ)をクライアント装置から受信すると、当該インタレスト・パケットをサーバ装置に向けて転送することなく、自装置が保持するオブジェクトを、当該インタレスト・パケットの送信元のクライアント装置に向けて送信できる。
【0004】
以下に、転送装置の動作の一例を説明する。転送装置は、CS(Contents Store)と、FIB(Forward Information Base)と、PIT(PIT:Pending Interest Table)を管理する。CSは、自装置が保持しているオブジェクトを示す情報である。FIBは、インタレスト・パケットと、当該インタレスト・パケットを転送すべきインタフェースとの関係を示す情報である。PITは、転送したインタレスト・パケットが要求するオブジェクトと、当該転送したインタレスト・パケットを受信したインタフェースとの関係を示す情報である。
【0005】
転送装置は、インタレスト・パケットを受信すると、CSを検索し、当該インタレスト・パケットが要求するオブジェクトを保持しているか否かを判定する。保持している場合には、自装置が保持しているオブジェクトを、当該インタレスト・パケットの送信元のクライアント装置に向けて送信する。一方、受信したインタレスト・パケットが要求するオブジェクトを保持していない場合には、PITを検索して、当該インタレスト・パケットと同じオブジェクトを要求するインタレスト・パケットを既に転送し、当該オブジェクトの受信待ちの状態であるかを判定する。受信待ちの状態であると、受信したインタレスト・パケットを転送せず、当該インタレスト・パケットの受信インタフェースを、当該インタレスト・パケットが要求するオブジェクトに関連付ける様にしてPITを更新する。一方、受信したインタレスト・パケットが要求するオブジェクトの受信待ちでなければ、FIBに基づき判定したインタフェースから当該インタレスト・パケットを転送すると共にPITを更新する。また、転送装置は、オブジェクトを受信すると、当該オブジェクトの転送先インタフェースをPITに基づき判定し、当該オブジェクトに関する情報をPITから削除する。また、転送装置は、受信して転送したオブジェクトを保存するとCSを更新する。
【0006】
ここで、公開するコンテンツを、特定のサービス会員等、所定のユーザに限定したい場合、各オブジェクトをそれぞれ、所定のユーザが有する暗号鍵で暗号化する必要がある。例えば、第1サービスのユーザは、第1アプリケーションを使用してコンテンツを取得し、第2サービスのユーザは、第2アプリケーションを使用してコンテンツを取得するものとする。なお、第1アプリケーションは暗号鍵Aを使用し、第2アプリケーションは暗号鍵Bを使用しているものとする。この場合、同じオブジェクトであっても、第1アプリケーションに配信する場合には暗号鍵Aで暗号化する必要があり、第2アプリケーションに配信する場合には暗号鍵Bで暗号化する必要がある。したがって、転送装置が、第1アプケーションに配信した暗号鍵Aで暗号化されたオブジェクトをキャッシュしたとしても、当該キャッシュしているオブジェクトを、第2アプリケーションに向けて配信することはできない。
【0007】
非特許文献2は、転送装置の一部に、再暗号化機能を設ける構成を開示している。再暗号化機能を有する転送装置は、暗号化されたオブジェクトをキャッシュしている場合において、当該暗号化されたオブジェクトを要求するインタレスト・パケットをクライアント装置から受信すると、当該クライアント装置が使用している暗号鍵で復号できる様に、キャッシュしているオブジェクトの再暗号化を行って、当該クライアント装置に送信する。
【先行技術文献】
【非特許文献】
【0008】
【非特許文献1】V.Jacobson,et al.,"Networking Named Content",in Proceedings of ACM CoNEXT 2009,2009年12月
【非特許文献2】N. Fotiou,et al.,"Security Content Sharing over ICN",ACM ICN'16、京都、2016年9月
【発明の概要】
【発明が解決しようとする課題】
【0009】
しかしながら、非特許文献2の構成では、再暗号化機能を設けた転送装置以外の転送装置でキャッシュされている暗号化されたオブジェクトは、当該暗号化に使用された暗号鍵を使用しないアプリケーションに向けて配信することはできない。
【0010】
本発明は、転送装置がキャッシュしているオブジェクトの暗号化に使用されている暗号鍵に拘らず、転送装置がキャッシュしているオブジェクトを取得することができるクライアント装置を提供するものである。
【課題を解決するための手段】
【0011】
本発明の一側面によると、コンテンツ名に基づきルーティングするネットワークからコンテンツを取得するクライアント装置は、コンテンツを取得する1つ以上のアプリケーションを動作させるアプリケーション手段であって、前記1つ以上のアプリケーションは対応する暗号鍵を有し、コンテンツを取得する前に前記ネットワークに、当該コンテンツの再暗号化鍵を要求する第1要求パケットを送信し、コンテンツを取得する際には、当該コンテンツを要求する第2要求パケットを前記ネットワークに送信する、前記アプリケーション手段と、前記第1要求パケットの応答としてコンテンツの再暗号化鍵を受信すると、前記第1要求パケットを送信したアプリケーションと、受信した前記コンテンツの再暗号化鍵との関係を管理情報に追加し、かつ、受信した前記コンテンツの再暗号化鍵を保存し、前記第2要求パケットの応答としてコンテンツを受信すると、前記第2要求パケットを送信したアプリケーションと、受信した前記コンテンツと、前記管理情報と、に基づき、保存している再暗号化鍵から受信した前記コンテンツを再暗号化するための再暗号化鍵を選択し、選択した再暗号化鍵に基づき受信した前記コンテンツを再暗号化して前記第2要求パケットを送信したアプリケーションに送信する処理手段と、を備えていることを特徴とする。
【発明の効果】
【0012】
本発明によると、転送装置がキャッシュしているオブジェクトの暗号化に使用されている暗号鍵に拘らず、転送装置がキャッシュしているオブジェクトを取得することができる。
【図面の簡単な説明】
【0013】
図1】一実施形態によるクライアント装置の構成図。
図2】一実施形態による再暗号化鍵取得処理のシーケンス図。
図3】一実施形態によるPITを示す図。
図4】一実施形態による名前変換テーブル及び管理テーブルを示す図。
図5】一実施形態によるコンテンツ取得処理のシーケンス図。
図6】一実施形態によるPITを示す図。
【発明を実施するための形態】
【0014】
以下、本発明の例示的な実施形態について図面を参照して説明する。なお、以下の実施形態は例示であり、本発明を実施形態の内容に限定するものではない。また、以下の各図においては、実施形態の説明に必要ではない構成要素については図から省略する。
【0015】
図1は、本実施形態によるクライアント装置の構成図である。クライアント装置は、スマートフォン、タブレット等の携帯型端末や、パーソナルコンピュータ等の通信端末であり、CCNの様なコンテンツ名に基づきルーティングを行うネットワークを介してコンテンツを取得する。なお、以下では、ネットワークがCCNであるものとして本実施形態の説明を行うが、コンテンツ名に基づきルーティングを行うネットワークからコンテンツを取得する任意のクライアント装置に本発明を適用することができる。アプリケーション部30は、複数のアプリケーションを実行する。図1によると、アプリケーション1と、アプリケーション2が実行されている。ここで、アプリケーション1は、暗号鍵(以下、単に、鍵と表記する。)Aで暗号化されたコンテンツを復号することができる。また、アプリケーション2は、鍵Bで暗号化されたコンテンツを復号することができる。
【0016】
転送処理部10は、CCNの転送装置と同様の処理を行う。具体的には、転送処理部10は、PIT、FIB、CSを管理し、インタレスト・パケット及びデータ・パケットの転送処理を行う。なお、本実施形態において、転送処理部10が管理するFIBは、コンテンツ名フィールドが"AC"で始まるパケットをプロキシ部20に転送し、それ以外のパケットをネットワークに転送することを示している。
【0017】
プロキシ部20は、管理テーブルと名前変換テーブルを管理し、転送処理部10から受信するパケットを処理して転送処理部10に送信する。プロキシ部20における処理の詳細については後述する。
【0018】
アプリケーション1及びアプリケーション2は、コンテンツを取得するに当たり、まず、再暗号化鍵を取得する。以下では、アプリケーション1及びアプリケーション2がそれぞれ、"CN1"をコンテンツ名(オブジェクト名)とするコンテンツ(以下、コンテンツCN1と表記。)を取得するための再暗号化鍵を取得する処理について図2を用いて説明する。なお、転送処理部10のCSは、コンテンツをキャッシュしていないものとする。また、コンテンツCN1は、鍵Cで暗号化されて配信されているものとする。つまり、コンテンツCN1を公開しているサーバ装置や、ネットワーク内の転送装置は、コンテンツCN1については、鍵Cで暗号化されたコンテンツ・データを保持又はキャッシュしている。さらに、本実施形態において、再暗号化鍵は、ネットワーク内の転送装置においてキャッシュすることが禁止されているものとする。つまり、再暗号化鍵を要求するインタレスト・パケットは、常に、サーバ装置に送信されるものとする。
【0019】
S1で、アプリケーション1は、コンテンツ名フィールドに"/AC/App1/CN1/KR/N1/"を設定したインタレスト・パケットを転送処理部10に送信する。なお、"AC"に続く"App1"は、アプリケーション1を示している。また、コンテンツ名"CN1"に続く"KR"は、再暗号化鍵の要求であることを示している。さらに、"KR"に続く"N1"は、ナンス値である。なお、ナンス値としては、ランダム値を使用することができるが、アプリケーション1に固有の値とすることや、ランダム値とアプリケーション1に固有の値との組み合わせを使用することができる。また、アプリーション1が送信するインタレスト・パケットには、アプリケーション1が使用する鍵Aと、クライアント装置のユーザの認証情報、例えば、ユーザ識別子及びパスワードが含まれている。上述した様に、コンテンツ名フィールドが"AC"で始まるため、転送処理部10は、S1で受信するインタレスト・パケットをプロキシ部20に転送する。したがって、転送処理部10のPITには、図3(A)に示す様に、受信したインタレスト・パケットのコンテンツ名フィールドに設定された"/AC/App1/CN1/KR/N1/"の応答として受信するデータ・パケットの送信先がアプリケーション1であることを示すエントリが追加される。
【0020】
プロキシ部20は、コンテンツ名フィールドが"AC"で始まるインタレスト・パケットを受信すると、その宛先からプレフィクス"/AC/App1"を削除し、コンテンツ名フィールドに"/CN1/KR/N1/"が設定されたインタレスト・パケットをS2で転送処理部10に送信する。また、図4(A)の番号#1のエントリに示す様に、S2で送信したコンテンツ名フィールドが"/CN1/KR/N1/"であるインタレスト・パケットが、アプリケーション1(App1)から受信したことを示すエントリを名前変換テーブルに追加する。
【0021】
転送処理部10は、S2で、コンテンツ名フィールドに"/CN1/KR/N1/"が設定されたインタレスト・パケットを受信するが、上述した様に、コンテンツ名フィールドが"AC"で始まらないため、転送処理部10は、S2で受信したインタレスト・パケットをFIBに従いネットワークに転送する。したがって、転送処理部10のPITには、図3(B)の番号#2のエントリとして示す様に、コンテンツ名フィールドに"/CN1/KR/N1/"が設定されたデータ・パケットの送信先がプロキシ部20(プロキシ)であることを示すエントリが追加される。
【0022】
S3で、アプリケーション2は、コンテンツ名フィールドに"/AC/App2/CN1/KR/N2/"を設定したインタレスト・パケットを転送処理部10に送信する。コンテンツ名フィールドの"AC"に続く"App2"は、アプリケーション2を示している。また、"KR"に続く"N2"は、ナンス値である。また、当該インタレスト・パケットには、アプリケーション2が使用する鍵Bと認証情報が含まれている。S1の処理と同様に、転送処理部10は、S3で受信したインタレスト・パケットをプロキシ部20に転送する。したがって、転送処理部10のPITには、図3(C)の番号#3のエントリが追加される。S2の処理と同様に、プロキシ部20は、S3で受信したインタレスト・パケットのコンテンツ名フィールドに設定された値からプレフィクス"/AC/App2"を削除し、コンテンツ名フィールドに"/CN1/KR/N2/"が設定されたインタレスト・パケットをS4で転送処理部10に送信する。インタレスト・パケットのコンテンツ名フィールドを変換したため、プロキシ部20は、図4(A)の番号#2のエントリに示す様に、S4で送信したコンテンツ名フィールドが"/CN1/KR/N2/"であるインタレスト・パケットが、アプリケーション2(App2)から受信したことを示すエントリを名前変換テーブルに追加する。S2での処理と同様に、転送処理部10は、S4で受信したコンテンツ名フィールドが"/CN1/KR/N2/"であるインタレスト・パケットをネットワークに転送し、図3(D)の番号#4のエントリをPITに追加する。
【0023】
S4の処理の終了時点において、クライアント装置は、コンテンツ名フィールドが"/CN1/KR/N1/"であるインタレスト・パケットと、コンテンツ名フィールドが"/CN1/KR/N2/"であるインタレスト・パケットの2つのインタレスト・パケットをネットワークに送信している。上述した様に、本実施形態において、再暗号化鍵はネットワーク内の転送装置においてキャッシュすることが禁止されており、よって、2つのインタレスト・パケットは、コンテンツCN1に関する再暗号化鍵を管理しているサーバ装置に送信される。当該サーバ装置は、受信するインタレスト・パケットに含まれる認証情報に基づき認証を行い、認証が成功すると、コンテンツCN1の暗号化に使用している鍵Cで暗号化された暗号化データを、インタレスト・パケットに含まれる鍵で暗号化された暗号化データに再暗号化するための再暗号化鍵を生成する。つまり、コンテンツ名フィールドが"/CN1/KR/N1/"であるインタレスト・パケットに対しては、鍵Cで暗号化された暗号化データを、鍵Aで暗号化された暗号化データに変換するための再暗号化鍵CAを生成し、コンテンツ名フィールドが"/CN1/KR/N2/"であるインタレスト・パケットに対しては、鍵Cで暗号化された暗号化データを、鍵Bで暗号化された暗号化データに変換するための再暗号化鍵CBを生成する。そして、サーバ装置は、生成した再暗号化鍵を含むデータ・パケットをネットワークに送信する。このデータ・パケットには、それぞれ、データ・パケットの送信のトリガとなった、インタレスト・パケットのコンテンツ名フィールドの値が、そのコンテンツ名フィールドに設定される。
【0024】
転送処理部10は、S5で、サーバ装置が送信した再暗号化鍵CAを含むデータ・パケットを受信する。このデータ・パケットには、"/CN1/KR/N1/"が含まれているため、転送処理部10は、図3(D)の番号#2に示すエントリに基づき、このデータ・パケットをプロキシ部20に転送する。なお、転送後、番号#2のエントリはPITから削除される。プロキシ部20は、S5で受信したデータ・パケットに含まれる"/CN1/KR/N1/"と名前変換テーブルに基づき、当該データ・パケットのトリガとなったインタレスト・パケットを送信したアプリケーションを判定する。図4(A)の番号#1で示すエントリに基づき、ここでは、アプリケーション1が判定される。プロキシ部20は、アプリケーション1を判定すると、図4(B)の番号#1のエントリを管理テーブルに追加する。図4(B)の番号#1のエントリは、アプリケーション1がコンテンツCN1を取得する際に再暗号化鍵CAを使用することを示している。また、プロキシ部20は、再暗号化鍵CAを保存する。さらに、プロキシ部20は、名前変換テーブルに基づき、S5で受信したデータ・パケットに含まれる"/CN1/KR/N1/"を、"/AC/App1/CN1/KR/N1/"に変換してS6で転送処理部10に送信する。なお、変換後、プロキシ部20は、図4(A)の番号#1のエントリを削除する。転送処理部10は、図3(D)の番号#1に示すエントリに基づき、このデータ・パケットをアプリーション1に転送する。転送後、番号#1のエントリはPITから削除される。なお、再暗号化鍵は、プロキシ部20が使用し、アプリケーションでは使用しないため、S6で送信するデータ・パケットには再暗号化鍵を含めない構成とすることもできる。S6で、データ・パケットをアプリケーション1に送信するのは、再暗号化鍵の取得が完了したことを、アプリケーション1に通知するためである。
【0025】
S7及びS8の処理は、S5及びS6の処理と同様であり再度の説明は省略する。図2の処理が完了することで、プロキシ部20が管理する管理テーブルは図4(B)に示す様になる。
【0026】
続いて、アプリケーション1及びアプリケーション2が、コンテンツCN1を取得する処理について図5を用いて説明する。S11で、アプリケーション1は、コンテンツ名フィールドに"/AC/App1/CN1/"を設定したインタレスト・パケットを転送処理部10に送信する。コンテンツ名フィールドが"AC"で始まるため、転送処理部10は、受信するインタレスト・パケットをプロキシ部20に転送する。したがって、転送処理部10のPITには、図6(A)に示すエントリが追加される。
【0027】
プロキシ部20は、コンテンツ名フィールドが"AC"で始まるインタレスト・パケットを受信すると、プレフィクス"/AC/App1"を削除し、コンテンツ名フィールドに"/CN1/"が設定されたインタレスト・パケットをS12で転送処理部10に送信する。また、プロキシ部20は、図4(C)の番号#1のエントリに示す様に、S12で送信した、コンテンツ名フィールドが"CN1"であるインタレスト・パケットをアプリケーション1(App1)から受信したことを示すエントリを名前変換テーブルに追加する。
【0028】
転送処理部10は、S12で、コンテンツ名フィールドが"/CN1/"であるインタレスト・パケットを受信するが、上述した様に、コンテンツ名フィールドが"AC"で始まらないため、転送処理部10は、S12で受信したインタレスト・パケットをFIBに従いネットワークに転送する。したがって、転送処理部10のPITには、図6(B)の番号#2のエントリが追加される。
【0029】
S13で、アプリケーション2は、コンテンツ名フィールドに"/AC/App2/CN1/"を設定したインタレスト・パケットを転送処理部10に送信する。S11の処理と同様に、転送処理部10は、S13で受信したインタレスト・パケットをプロキシ部20に転送する。したがって、転送処理部10のPITには、図6(C)の番号#3のエントリが追加される。S12の処理と同様に、プロキシ部20は、S13で受信したインタレスト・パケットのコンテンツ名フィールドの値からプレフィクス"/AC/App2"を削除し、コンテンツ名フィールドが"/CN1/"であるインタレスト・パケットをS14で転送処理部10に送信する。変換後のインタレスト・パケットのコンテンツ名フィールドの値は"/CN1/"であり、この宛先は、図4(C)に示す様に、既に名前変換テーブルのエントリとして存在するため、プロキシ部20は、図4(D)に示す様に、送信したコンテンツ名フィールドが"/CN1/"であるインタレスト・パケットをアプリケーション2(App1)からも受信したことを示す様に名前変換テーブルの番号#1のエントリを更新する。
【0030】
転送処理部10は、S14で、コンテンツ名フィールドが"/CN1/"であるインタレスト・パケットを受信するが、PITには、図6(C)に示す様に、コンテンツ名フィールドが"/CN1/"であるインタレスト・パケットを転送したことを示すエントリ(番号#3)が存在する。なお、番号#3のエントリのインタフェース欄にはプロキシ部20が示されており、S14で受信したインタレスト・パケットの送信元と同じであるため、転送処理部10は、S14で受信したインタレスト・パケットを単に廃棄する。
【0031】
したがって、アプリケーション1及びアプリケーション2がそれぞれ、コンテンツCN1を要求するインタレスト・パケットを送信したが、ネットワークに送信されるインタレスト・パケットは1つとなる。このインタレスト・パケットの応答として、転送処理部10は、S15で、鍵Cで暗号化されたコンテンツCN1を含むデータ・パケットを受信する。なお、このデータ・パケットの送信元は、サーバ装置又はネットワーク内においてコンテンツCN1をキャッシュしていた転送装置である。転送処理部10は、この受信したデータ・パケットを、図6(C)に示すPITの番号#3のエントリに従い、プロキシ部20に転送する。
【0032】
プロキシ部20は、S15でコンテンツ名フィールドが"/CN1/"であるデータ・パケットを受信すると、名前変換テーブルに基づき、どのアプリケーションがコンテンツCN1を取得しようとしているのかを判定する。図4(D)に示す名前変換テーブルに基づき、アプリケーション1及びアプリケーション2であることが判定される。この場合、プロキシ部20は、図4(B)に示す管理テーブルに基づき、鍵Cで暗号からされたコンテンツCN1の再暗号化を行う。具体的には、管理テーブルの番号#1のエントリに従い、プロキシ部20は、S16で、アプリケーション1のために、再暗号化鍵CAを使用して再暗号化を行う。これにより、鍵Aで暗号化されたコンテンツCN1が生成される。同様に、管理テーブルの番号#2のエントリに従い、プロキシ部20は、S17で、アプリケーション2のために、再暗号化鍵CBを使用して再暗号化を行う。これにより、鍵Bで暗号化されたコンテンツCN1が生成される。プロキシ部20は、S18で、名前変換テーブルに従って生成したコンテンツ名フィールドが"/AC/App1/CN1/"であるデータ・パケットを転送処理部10に送信する。なお、このデータ・パケットには、鍵Aで暗号化されたコンテンツCN1が含められる。転送処理部10は、図6(C)の番号#1のエントリに従い、このデータ・パケットをアプリケーション1に転送する。同様に、プロキシ部20は、S19で、名前変換テーブルに従って生成したコンテンツ名フィールドが"/AC/App2/CN1/"であるデータ・パケットを転送処理部10に送信する。なお、このデータ・パケットには、鍵Bで暗号化されたコンテンツCN1が含められる。転送処理部10は、図6(C)の番号#3のエントリに従い、このデータ・パケットをアプリケーション2に転送する。
【0033】
以上、本実施形態によると、コンテンツを取得する際、アプリケーションは、それぞれが使用している暗号鍵で暗号化されたデータに変換するための再暗号化鍵をサーバに要求する。サーバは、要求(インタレスト・パケット)に含まれる認証情報により、ユーザの正当性を検証すると、再暗号化鍵をクライアント装置に送信する。この構成により、ネットワーク側の構成を変更することなく、総ての転送装置でキャッシュされている暗号化されたコンテンツを、アプリケーションに拘らず配信することができる。
【0034】
また、本実施形態においてプロキシ部20は、アプリケーションより先にコンテンツを含むデータ・パケットを受信し、プロキシ部20にて再暗号化を行う。例えば、インストールされたアプリケーションに悪意のあるアプリケーションが含まれている場合、管理テーブルの当該悪意のあるアプリケーションに関するエントリを使用不可に設定することで、該悪意のあるアプリケーションがコンテンツを取得することを防ぐことができる。
【0035】
なお、本発明によるクライアント装置は、コンピュータを上記クライアント装置として動作させるプログラムにより実現することができる。これらコンピュータプログラムは、コンピュータが読み取り可能な記憶媒体に記憶されて、又は、ネットワーク経由で配布が可能なものである。
【符号の説明】
【0036】
10:転送処理部、20:プロキシ部、30:アプリケーション部
図1
図2
図3
図4
図5
図6