(57)【要約】      （修正有）【課題】コンテンツ指向ネットワークメッセージ内のビットグループを選択的に暗号化するシステムを提供する。【解決手段】システムは、コンテンツ要求デバイスまたはコンテンツ生成デバイスによって、各々がタイプ、長さ、および値セットに対応する複数のビットグループを含むメッセージを決定し、１つまたは複数のビットグループを暗号化のためにマークする。メッセージは、最も一般的なレベルから最も特定的なレベルへと順序付けされた連続する名前構成要素を含む階層構造可変長識別子である名前を指示する。次いで、認証済み暗号化プロトコルに基づいて、メッセージのための複数の暗号ブロックを計算する。次に、１つまたは複数の対称鍵に基づいて暗号化のためにマークされているビットグループを暗号化する。マークされているビットグループは、１つまたは複数の名前構成要素を含む。その後、暗号化ビットグループを暗号化されたものとして指示する。【選択図】図２
2017076964.tif 000002
【特許請求の範囲】
【請求項１】
パケットの転送を促進するためのコンピュータシステムであって、前記システムは、
プロセッサと、
前記プロセッサによって実行されると、前記プロセッサに方法を実施させる命令を記憶している記憶デバイスと
を備え、前記方法は、
コンテンツ要求デバイスまたはコンテンツ生成デバイスによって、各々がタイプ、長さ、および値セットに対応する複数のビットグループを含むメッセージを決定するステップであって、１つまたは複数のビットグループが暗号化のためにマークされ、前記メッセージは、最も一般的なレベルから最も特定的なレベルへと順序付けされた連続する名前構成要素を含む階層構造可変長識別子である名前を指示する、決定するステップと、
認証済み暗号化プロトコルに基づいて、前記メッセージのための複数の暗号ブロックを計算するステップと、
１つまたは複数の対称鍵に基づいて前記暗号化のためにマークされている１つまたは複数のビットグループを暗号化するステップであって、前記マークされているビットグループは、１つまたは複数の名前構成要素を含む、暗号化するステップと、
前記暗号化ビットグループを暗号化されているものとして指示するステップであって、それによって、前記メッセージのビットグループの選択的暗号化が促進される、指示するステップと
を含む、コンピュータシステム。
【請求項２】
前記メッセージは、インタレストパケットまたはコンテンツオブジェクトパケットである、請求項１に記載のコンピュータシステム。
【請求項３】
前記方法は、前記選択的に暗号化されたメッセージをコンテンツ生成デバイスまたはコンテンツ要求デバイスに送信するステップ
をさらに含む、請求項１に記載のコンピュータシステム。
【請求項４】
前記暗号ブロックの計算は、前記メッセージの０バイト目での開始にさらに基づく、請求項１に記載のコンピュータシステム。
【請求項５】
前記暗号ブロックの計算は、１２８ビットの長さを有する鍵を使用する高度暗号化標準にさらに基づく、請求項１に記載のコンピュータシステム。
【請求項６】
パケットを転送するためのコンピュータ実施方法であって、前記方法は、
コンテンツ要求デバイスまたはコンテンツ生成デバイスによって、各々がタイプ、長さ、および値セットに対応する複数のビットグループを含むメッセージを決定するステップであって、１つまたは複数のビットグループが暗号化のためにマークされ、前記メッセージは、最も一般的なレベルから最も特定的なレベルへと順序付けされた連続する名前構成要素を含む階層構造可変長識別子である名前を指示する、決定するステップと、
認証済み暗号化プロトコルに基づいて、前記メッセージのための複数の暗号ブロックを計算するステップと、
１つまたは複数の対称鍵に基づいて前記暗号化のためにマークされている１つまたは複数のビットグループを暗号化するステップであって、前記マークされているビットグループは、１つまたは複数の名前構成要素を含む、暗号化するステップと、
前記暗号化ビットグループを暗号化されているものとして指示するステップであって、それによって、前記メッセージのビットグループの選択的暗号化が促進される、指示するステップと
を含む、コンピュータ実施方法。
【請求項７】
前記メッセージは、インタレストパケットまたはコンテンツオブジェクトパケットである、請求項６に記載の方法。
【請求項８】
前記選択的に暗号化されたメッセージをコンテンツ生成デバイスまたはコンテンツ要求デバイスに送信するステップ
をさらに含む、請求項６に記載の方法。
【請求項９】
前記暗号ブロックの計算は、前記メッセージの０バイト目での開始にさらに基づく、請求項６に記載の方法。
【請求項１０】
前記暗号ブロックの計算は、１２８ビットの長さを有する鍵を使用する高度暗号化標準にさらに基づく、請求項６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は概してデジタルコンテンツの配信に関する。より詳細には、本開示は、コンテンツ指向ネットワークメッセージ内の複数の対称鍵に基づいてビットグループ（名前構成要素など）を選択的に暗号化するためのシステムおよび方法に関する。
【背景技術】
【０００２】
インターネットおよび電子商取引の広がりによって、膨大な量のデジタルコンテンツが生成され続けている。そのようなデジタルコンテンツへのアクセスおよびその処理を容易にするために、コンテンツ指向ネットワーク（ＣＣＮ）アーキテクチャが設計されている。ＣＣＮは、様々なコンテンツアイテムのインターネットパケットを送信し、引き換えにコンテンツオブジェクトパケットを受信することによって互いに通信するネットワーククライアント、転送器（たとえば、ルータ）、コンテンツ生成器のようなエンティティまたはノードを含む。ＣＣＮインタレストおよびコンテンツオブジェクトは、一般的には階層構造可変長識別子（ＨＳＶＬＩ）であるそれらの固有の名前によって識別される。ＨＳＶＬＩは、最も一般的なレベルから最も特定的なレベルへと順序付けされた連続する複数の名前構成要素を含むことができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
ＣＣＮ名の一部分はルーティング目的に使用することができ、名前の一部分は、慎重に扱うべきデータを含む可能性がある。たとえば、いくつかの名前構成要素は、中間ノードによって、転送およびキャッシングを実施するために使用され得、一方で、他の名前構成要素は、私的なユーザ情報またはアプリケーション特有のデータを含み得る。以前のＣＣＮパケットフォーマットが、暗号化機能を含み得るが、パケット全体に対する認証を可能にしながらペイロードのみを暗号化するように設計されている一方で、現行のＣＣＮパケットフォーマットは、主目的として認証を含み得る。これらのパケットフォーマットは２つのエンティティ間のセッションベースでペアワイズの暗号化を可能にせず、ＣＣＮパケットまたはメッセージの部分を選択的に暗号化する方法も提供しない。
【課題を解決するための手段】
【０００４】
一実施形態は、メッセージのビットグループの選択的暗号化を促進するシステムを提供する。動作中、システムは、コンテンツ要求デバイスまたはコンテンツ生成デバイスによって、各々がタイプ、長さ、および値セットに対応する複数のビットグループを含むメッセージを決定し、１つまたは複数のビットグループが暗号化のためにマークされ、メッセージは、最も一般的なレベルから最も特定的なレベルへと順序付けされた連続する名前構成要素を含む階層構造可変長識別子である名前を指示する。システムは、認証済み暗号化プロトコルに基づく、メッセージのための複数の暗号ブロックを計算する。システムは、１つまたは複数の対称鍵に基づいて暗号化のためにマークされている１つまたは複数のビットグループを暗号化し、マークされているビットグループは、１つまたは複数の名前構成要素を含む。その後、システムは、暗号化ビットグループを暗号化されたものとして指示する。
【０００５】
いくつかの実施形態において、メッセージは、インタレストパケットまたはコンテンツオブジェクトパケットである。
【０００６】
いくつかの実施形態において、システムは、選択的に暗号化されたメッセージをコンテンツ生成デバイスまたはコンテンツ要求デバイスに送信する。
【０００７】
いくつかの実施形態において、暗号ブロックの計算は、メッセージの０バイト目での開始にさらに基づく。
【０００８】
いくつかの実施形態において、暗号ブロックの計算は、１２８ビットの長さを有する鍵を使用する高度暗号化標準にさらに基づく。
【０００９】
いくつかの実施形態において、ビットグループの暗号化は、排他的論理和演算にさらに基づく。
【００１０】
いくつかの実施形態において、暗号化ビットグループを暗号化されたものとして指示することは、メッセージ内のビットグループと関連付けられるフィールドを設定すること、および、メッセージ内のビットグループと関連付けられる予備ビットを設定することのうちの１つまたは複数を含む。
【００１１】
いくつかの実施形態において、システムは、メッセージに対する検証区画内に、ノンス、および、対称鍵の各々の鍵識別子を含める。
【００１２】
いくつかの実施形態において、システムは、以下の特徴、すなわち、対称鍵が公開鍵操作を介して交換されること、対称鍵がメッセージ内に含まれる公開鍵に基づいて暗号化されること、検証区画が暗号化を用いる対称鍵暗号システムに基づくこと、コンテンツ生成デバイスの公開鍵識別子がメッセージ内に含まれること、および、コンテンツ要求デバイスとコンテンツ生成デバイスとの間で後続のメッセージにおいて使用するためにショート対称鍵識別子が指定されることのうちの１つまたは複数をさらに含む。
【００１３】
いくつかの実施形態において、システムは、以下の特徴、すなわち、公開鍵操作がＲＳＡ−ＳＨＡ２５６である暗号システムに基づくこと、および、ショート対称鍵識別子が、対称鍵から導出されない乱数であることのうちの１つまたは複数をさらに含む。
【００１４】
いくつかの実施形態において、システムは、選択的に暗号化されたメッセージを受信する。メッセージと関連付けられる認証情報の検証に応答して、システムは、暗号化されたものとして指示されている各ビットグループについて、対応する対称鍵に基づいて暗号化ビットグループを解読し、ノンス、および、対称鍵の各々の鍵識別子がメッセージの検証区画内に含まれている。システムは、解読されたビットグループを解読されたものとして指示する。
【００１５】
いくつかの実施形態において、メッセージと関連付けられる認証情報を検証することは、記憶装置内で、メッセージと関連付けられる鍵識別子を検索すること、および、鍵識別子に基づいて署名またはメッセージ認証コードを検証することをさらに含む。
【図面の簡単な説明】
【００１６】
【図１】図１は、本発明の一実施形態による、ＣＣＮメッセージのビットグループの選択的暗号化を促進する例示的なネットワークを示す図である。
【図２】図２は、本発明の一実施形態による、コンテンツ要求デバイスまたはコンテンツ生成デバイスによって、ＣＣＮメッセージを選択的に暗号化するための方法を示す流れ図である。
【図３】図３は、本発明の一実施形態による、コンテンツ要求デバイスまたはコンテンツ生成デバイスによって、選択的に暗号化されたＣＣＮメッセージを検証および解読するための方法を示す流れ図である。
【図４Ａ】図４Ａは、本発明の一実施形態による、選択的に暗号化されたＣＣＮメッセージの例示的なフォーマットを示す図である。
【図４Ｂ】図４Ｂは、本発明の一実施形態による、選択的に暗号化されたＣＣＮメッセージの例示的なフォーマットを示す図である。
【図４Ｃ】図４Ｃは、本発明の一実施形態による、入れ子式暗号化による選択的に暗号化されたＣＣＮメッセージの例示的なフォーマットを示す図である。
【図４Ｄ】図４Ｄは、本発明の一実施形態による、図４Ｃのメッセージの例示的なフォーマットに対応する、後順走査による符号化グラフの例示的なフォーマットを示す図である。
【図４Ｅ】図４Ｅは、本発明の一実施形態による、図４Ｃのメッセージの例示的なフォーマットに対応する、逆後順走査による符号化グラフの例示的なフォーマットを示す図である。
【図５】図５は、本発明の一実施形態による、選択的に暗号化されたＣＣＮメッセージの検証区画の例示的なフォーマットを示す図である。
【図６】図６は、本発明の一実施形態による、ＣＣＮメッセージのビットグループの選択的暗号化を促進する例示的な装置を示す図である。
【図７】図７は、本発明の一実施形態による、ＣＣＮメッセージのビットグループの選択的暗号化を促進する例示的なコンピュータシステムを示す図である。
【発明を実施するための形態】
【００１７】
図面において、同様の参照符号は同じ図面要素を指す。
【００１８】
以下の説明は、任意の当業者が、本実施形態を作成および使用することを可能にするために提示され、特定の用途およびその要件の文脈において提供されている。開示される実施形態の様々な改変が当業者には容易に諒解され、本明細書において定義されている一般原理は、本発明の精神および範囲から逸脱することなく、他の実施形態および用途に適用することができる。したがって、本発明は、示されている実施形態には限定されず、本明細書において開示されている原理および特徴と一致する最も広い範囲を与えられるべきである。
【００１９】
概説
本発明の実施形態は、２者の通信エンティティが、ＣＣＮメッセージの選択される部分を暗号化するために、複数の異なる、相互に知られている鍵を使用することを促進することによって、パケットの認証と暗号化とを効率的に組み合わせるという課題を解決するシステムを提供する。消費者および生産者のような２者のエンティティが、既知の鍵交換プロトコルに基づいて複数の秘密鍵を共有すると仮定する。消費者は、パケットの部分または「ビットグループ」が暗号化を必要とする場合があるインタレストパケットを送信することを所望し得る。たとえば、インタレスト名の名前構成要素は、ルーティング可能な情報と、慎重に扱うべきアプリケーション特有の情報の両方を含む可能性がある。消費者は、名前構成要素の周囲にコンテナを配置し、特定の鍵に基づいて名前構成要素を暗号化されたものとし、パケットの検証区画において特定の鍵を指示することによって、様々な名前構成要素を選択的に暗号化することができる。暗号化コンテナを有する例示的なパケットフォーマットは、図４Ａ〜図４Ｃに関係して下記に説明されている。生産者は、選択的に暗号化されたインタレストを受信し、指示されている特定の鍵に基づいて検証区画内の認証情報を検証し、その後、指示されている鍵に基づいて各暗号化名前構成要素（またはビットグループ）を解読することができる。生産者は、応答コンテンツオブジェクトを生成し、それぞれのコンテンツオブジェクトに、入来しているインタレストと同じ選択的に暗号化された名前を割り当てることができる。消費者によって使用される、インタレストを選択的に暗号化する同じ方法に基づいて、生産者はまた、他の相互に知られている鍵に基づいて応答コンテンツオブジェクトの追加の部分を暗号化することもできる。
【００２０】
具体的には、システムは、封入されているデータのプライバシーと信頼性／完全性の両方を同時に保護する認証付き暗号化（ＡＥＡＤ）方式を使用する。ＴＬＶフォーマット化パケット（たとえば、各ビットグループがタイプ、長さ、および値セットに対応するビットグループから構成されるパケット）を所与として、消費者は、ＡＥＡＤ方式を使用して、パケットの選択的なビットグループ（名前構成要素など）を暗号化することができる。修正ＴＬＶフォーマット化ＣＣＮパケットとともに使用されるものとしての「暗号化後認証」パラダイムに従うＡＥＡＤ方式の一例が、「暗号化コンテナを介した例示的な認証付き暗号化プロトコル」と題する節において下記で説明される。
【００２１】
以下の用語は、ＣＣＮアーキテクチャの要素を説明する。
【００２２】
コンテンツオブジェクト（Ｃｏｎｔｅｎｔ  Ｏｂｊｅｃｔ）または「コンテンツオブジェクト」（“ｃｏｎｔｅｎｔ  ｏｂｊｅｃｔ”）：固有の名前に結びつけられる単一の名前付きデータ片。コンテンツオブジェクトは「持続性」であり、これは、コンテンツオブジェクトがコンピューティングデバイス内を、または、複数の異なるコンピューティングデバイスにわたって移動することができるが、変化はしないことを意味する。コンテンツオブジェクトの任意の構成要素が変化する場合、変更を行ったエンティティが、更新されたコンテンツを含む新たなコンテンツオブジェクトを生成し、新たなコンテンツオブジェクトを新たな固有の名前に結びつける。
【００２３】
固有名：ＣＣＮにおける名前は一般的に位置独立であり、コンテンツオブジェクトを一意に識別する。データ転送デバイスは、この名前または名前プレフィックスを使用して、コンテンツオブジェクトのネットワークアドレスまたは物理的位置にかかわりなく、コンテンツオブジェクトを生成または記憶するネットワークノードに向けてパケットを転送することができる。いくつかの実施形態において、名前は、階層構造可変長識別子（ＨＳＶＬＩ）であってもよい。ＨＳＶＬＩは、様々な方法で構造化することができるいくつかの階層構成要素に分割することができる。たとえば、個々の名前構成要素ｐａｒｃ、ｈｏｍｅ、ｃｃｎ、およびｔｅｓｔ．ｔｘｔは、左にいくほど上位プレフィックスとなるように構造化して、名前「／ｐａｒｃ／ｈｏｍｅ／ｃｃｎ／ｔｅｓｔ．ｔｘｔ」を形成することができる。したがって、名前「／ｐａｒｃ／ｈｏｍｅ／ｃｃｎ」は、「／ｐａｒｃ／ｈｏｍｅ／ｃｃｎ／ｔｅｓｔ．ｔｘｔ」の「親」または「プレフィックス」とすることができる。追加の構成要素を使用して、協同文書のようなコンテンツアイテムの複数の異なる文書間で区別を行うことができる。
【００２４】
いくつかの実施形態において、名前は、コンテンツオブジェクトのデータ（たとえば、チェックサム値）および／またはコンテンツオブジェクトの名前の要素から導き出されるハッシュ値のような非階層識別子を含むことができる。ハッシュベースの名前の説明は、米国特許出願第１３／８４７，８１４号明細書に記載されている。名前は、フラットなラベルとすることもできる。以降、「名前」は、階層型の名前または名前プレフィックス、フラットな名前、固定長の名前、任意長の名前、またはラベル（たとえば、マルチプロトコルラベルスイッチング（ＭＰＬＳ）ラベル）のような、名前データネットワーク内のデータ片の任意の名前を指すのに使用される。
【００２５】
インタレスト（Ｉｎｔｅｒｅｓｔ）または「インタレスト」（“ｉｎｔｅｒｅｓｔ”）：データ片を求める要求を指示し、そのデータ片の名前（または名前プレフィックス）を含むパケット。データ消費者は、情報指向ネットワークにわたって要求またはインタレストを広めることができ、この要求またはインタレストは、ＣＣＮルータが要求またはインタレストを満たすために、記憶デバイス（たとえば、キャッシュサーバ）、または、要求されているデータを提供することができるデータ生成者に向けて伝搬することができる。
【００２６】
本明細書に開示する方法は、ＣＣＮネットワークには限定されず、他のアーキテクチャにも同様に適用可能である。ＣＣＮアーキテクチャの説明は、米国特許出願第１２／３３８，１７５号明細書に記載されている。
【００２７】
例示的なネットワークおよび通信
図１は、本発明の一実施形態による、ＣＣＮメッセージのビットグループの選択的暗号化を促進する例示的なネットワークを示す。ネットワーク１００はコンテンツ指向ネットワーク（ＣＣＮ）とすることができ、クライアントデバイス１１６、コンテンツ生成デバイス１１８、ならびに、ノード１０２、１０４、１０６、１０８、１１０、１１２、および１１４にあるルータまたは他の転送デバイスを含むことができる。ＣＣＮルータは、ＩＰルータに加えて存在するＣＣＮ転送デバイスとすることができる。言い換えれば、ＣＣＮは、ＩＰに加えてのオーバーレイとして実装することができる。他のＣＣＮオーバーレイアーキテクチャも可能である。ノードは、コンピュータシステム、ユーザを表すエンドポイント、および／または、インタレストを生成しまたはコンテンツを発信することができるデバイスとすることができる。
【００２８】
要求エンティティまたはコンテンツ消費者（デバイス１１６など）は、「／ａ／ｂ／ｃ／ｄ／ｅ」の元々の名前を有するインタレスト１３０を生成または決定することができる。消費者１１６は、暗号化１４０機能を介してインタレスト１３０を選択的に暗号化することができ、この結果として、「／ａ／ｂ／ＥＫ２｛ｃ｝／ＥＫ３｛／ｄ／ｅ｝」の選択的に暗号化された名前を有するインタレスト１３２がもたらされる。インタレスト１３２は、２つの選択的に暗号化された名前構成要素（たとえば、「ｃｏｎｔａｉｎｅｒｓ」または「ｂｉｔ  ｇｒｏｕｐｓ」）を有する：１）名前構成要素「ｃ」は、対称鍵Ｋ２を使用して暗号化され、２）名前構成要素／ｄ／ｅ」は、対称鍵Ｋ３を使用して暗号化される。鍵Ｋ２およびＫ３は、消費者１１６および生産者１１８に相互に知られている。可能性のある鍵交換プロトコルは、「対称鍵を交換するための可能な方法」と題する節において下記に説明されている。名前構成要素を暗号化するために使用される各対称鍵について、暗号化１４０機能は、認証付き暗号化（ＡＥＡＤ）プロトコルにさらに基づくことができる。下記に説明されているようにＡＥＡＤ方式は、それぞれの暗号化コンテナの認証子タグを生成することができ、消費者１１６は、認証子タグを、メッセージの対応する検証区画内に含めることができる。消費者１１６は、ネットワークを通じて選択的に暗号化されたインタレスト１３２を送信することができる。インタレスト１３２は、コンテンツ生成デバイスまたはコンテンツ生産者１１８に達するまで、中間ノード１０２および１１４によって受信および転送される。
【００２９】
生産者１１８は、認証情報（たとえば、メッセージの検証区画内に含まれる認証子タグ）を検証する。認証情報が適切に検証されると、生産者１１８は、検証区画内の情報に基づいて、解読１４２機能を介してインタレスト１３２の各暗号化名前構成要素を解読する。検証区画は、図５に関係して下記に説明されているように、いずれの対称鍵を各暗号化名前構成要素（またはビットグループ）に対して使用すべきかを特定するための情報を含む。解読１４２機能は、結果として、元々の名前「／ａ／ｂ／ｃ／ｄ／ｅ」を有するインタレスト１３０をもたらす。生産者１１８はその後、インタレスト１３０に対応するコンテンツオブジェクト１３１を生成または生産する。生産者１１８は、暗号化１４４機能を介してインタレスト１３２の名前に一致するようにコンテンツオブジェクト１３１（たとえば、コンテンツオブジェクト１３１の名前構成要素）を選択的に暗号化することができ、結果として、コンテンツオブジェクト１３３がもたらされる。生産者１１８はまた、消費者１１６によって以前に使用された同じ暗号化鍵（たとえば、Ｋ２およびＫ３）を使用してコンテンツオブジェクト１３３の他のビットグループを暗号化することもできる。生産者１１８は、パーティ間で共有されるまた別の対称鍵（たとえば、Ｋ４、図示せず）を使用してコンテンツオブジェクト１３３の他のビットグループをさらに暗号化することができる。いくつかの実施形態において、生産者１１８はまた、「ラッピング方法」と題する節において下記に説明されているように、外側コンテナでコンテンツオブジェクト１３３をラッピングすることもできる。生産者１１８は、ネットワークを通じてコンテンツオブジェクト１３３を送信することができる。コンテンツオブジェクト１３３は、消費者１１６に達するまで、インタレスト１３２とは逆の経路上、たとえば、中間ノード１１４および１０２を通じて戻って進行する。
【００３０】
コンテンツオブジェクト１３３が受信されると、消費者１１６は、生産者１１８が選択的に暗号化されたインタレスト１３２を検証および解読するために実施するものと同様のステップを実施して、選択的に暗号化されたコンテンツオブジェクト１３３を検証および解読する。たとえば、消費者１１６は、コンテンツオブジェクト１３３内の認証情報を検証し、認証情報が検証されると、消費者１１６は、検証区画内の情報に基づいて、解読１４６機能を介してコンテンツオブジェクト１３３の暗号化ビットグループまたは名前構成要素の解読を開始する。解読１４６機能は、結果として、元々の名前「／ａ／ｂ／ｃ／ｄ／ｅ」を有するコンテンツオブジェクト１３１をもたらす。消費者１１６はその後、インタレスト１３２および／またはインタレスト１３０について、検索を実施し、そのペンディングインタレストテーブル（ＰＩＴ）内の対応するエンティティを消去する。
【００３１】
ＣＣＮメッセージの選択的暗号化
図２は、本発明の一実施形態による、コンテンツ要求デバイスまたはコンテンツ生成デバイスによって、ＣＣＮメッセージを選択的に暗号化するための方法を示す流れ図２００を提示する。動作中、システムは、コンテンツ生成デバイスまたはコンテンツ要求デバイスによって、複数のビットグループを含むメッセージを決定し、各ビットグループは、タイプ、長さ、および値セットに対応し、１つまたは複数のビットが暗号化のためにマークされる（動作２０２）。メッセージはまた、最も一般的なレベルから最も特定的なレベルへと順序付けされた連続する複数の名前構成要素を含む階層構造可変長識別子である名前をも指示する。メッセージは、インタレストパケットまたはコンテンツオブジェクトパケットとすることができる。システムはその後、認証済み暗号化プロトコルに基づいて、メッセージのための複数の暗号ブロックを計算する（動作２０４）。認証付き暗号化プロトコルは、当該プロトコルが暗号化するよりも多くのデータを同時に暗号化および認証する「暗号化後認証」方式とすることができる。そのような認証付き暗号化（ＡＥＡＤ）方式の一例が、下記に説明されているような、ガロアカウンタモード高度暗号化標準（ＡＥＳ−ＧＣＭ）である。システムは、１つまたは複数の対称鍵に基づいて暗号化のためにマークされている１つまたは複数のビットグループを暗号化し、マークされているビットグループは、１つまたは複数の名前構成要素を含む（動作２０６）。ビットグループはまた、ペイロード、および、任意の他のビットグループ、または、暗号器が暗号化することを所望し得るＴＬＶフォーマット化グループをも含むことができる。加えて、暗号器は、図４Ｃに関係して下記に説明されているように、ビットグループの入れ子式暗号化を実施することができる。
【００３２】
システムは、メッセージに対する検証区画内に、ビットグループを暗号化するために使用される、ノンス、および、対称鍵の各々の鍵識別子（ＫｅｙＩｄ）を含める（動作２０８）。可能性のある対称鍵交換プロトコルは、「対称鍵を交換するための可能な方法」と題する節において下記に論じられている。その後、システムは、選択的に暗号化されたメッセージを別のエンティティに送信する（動作２１０）。たとえば、ＣＣＮメッセージは、選択的に暗号化され、コンテンツ要求デバイスからコンテンツ生成デバイスへと送信されるインタレストパケットとすることができる。コンテンツ生成デバイスはその後、コンテンツ要求デバイスに、同じ選択的に暗号化された名前を有する応答コンテンツオブジェクトを返すことができる。応答コンテンツオブジェクトは、さらに選択的に暗号化することができる。
【００３３】
暗号化コンテナを介した例示的な認証付き暗号化プロトコル
ブロック暗号動作モードは、封入されているデータのプライバシーと信頼性または完全性の両方を同時に保護することができる。そのような認証付き暗号化（ＡＥ）方式はまた、それらが暗号化するよりも多くのデータを認証することもでき、認証付き暗号化（ＡＥＡＤ）方式と称される。ＡＥＡＤ方式の一例が、１２８ビットのブロックサイズを有するブロック暗号とともに使用される、ガロアカウンタモード高度暗号化標準（ＡＥＳ−ＧＣＭ）である。ＡＥＳ−ＧＣＭは、「暗号化後認証」パラダイムを使用する。この方式は、秘密鍵Ｋ、ノンス（たとえば、初期化ベクトルすなわちＩＶ）、およびノンスごとのカウンタに基づく。選択的に暗号化されたパケットは、ＫｅｙＩｄおよびノンスを搬送する。その開示全体が本明細書に組み込まれるＩＥＴＦ  ＲＦＣ  ４１０６「Ｔｈｅ  Ｕｓｅ  ｏｆ  Ｇａｌｏｉｓ／Ｃｏｕｎｔｅｒ  Ｍｏｄｅ  （ＧＣＭ）  ｉｎ  ＩＰｓｅｃ  Ｅｎｃａｐｓｕｌａｔｉｎｇ  Ｓｅｃｕｒｉｔｙ  Ｐａｙｌｏａｄ  （ＥＳＰ）」（２００５年６月）（以下「ＲＦＣ  ４１０６」）に記載されているように、ＫｅｙＩｄは、関連付け設定の間に作成される（ｋｅｙ，ｓａｌｔ）対を識別する。ノンスは、１〜８バイトサイズであり、図５に関係して下記に説明されているように、パケットの検証区画内で搬送される。ノンスは、０を８バイトまで左詰めされ、ｓａｌｔに付加されて、ＧＣＭ−ＡＥＳ  ＩＶが形成される。パケット内のノンスはまた、カウンタでもあり得ることに留意されたい。
【００３４】
ＧＣＭ−ＡＥＳ方式を使用してパケットを暗号化するために、暗号器は、以下の入力、すなわち、秘密鍵Ｋ、個別の初期化ベクトルＩＶ（一般的には９６ビット）、プレーンテキストＰ（最大２３９−２５６ビット）、および、関連データＡ（最大２６４ビット）を使用する。これらの入力を使用して、暗号器は以下の出力、すなわち、暗号文Ｃ（Ｐに等しい長さを有する）、および認証タグＴ（０〜１２８ビット）を作成する。認証タグＴは、データブロックをＧＨＡＳＨ関数に供給し、結果を暗号化することによって構築される。たとえば、ＧＨＡＳＨ関数はＧＨＡＳＨ（Ｈ，Ａ，Ｃ）によって定義することができ、Ｈはハッシュキー、ブロック暗号を使用して暗号化されている１２８個のゼロビットの列であり、Ａは認証のみされ暗号化はされない関連データであり、Ｃは暗号文である。したがって、ＧＣＭ−ＡＥＳの関数ＧＨＡＳＨは、各暗号化コンテナのＣおよびＡのすべてにわたって実施される。
【００３５】
解読器は、出力Ａ（プレーンテキストヘッダ、テール、または他のメタ情報を含むことができる）とともにＣおよびＴを受信し、以前の鍵交換プロトコルに基づいてＫおよびＩＶを決定することができる。したがって、解読器は、入力Ｋ、ＩＶ、Ｃ、Ａ、およびＴを使用して、プレーンテキストＰまたは「ＦＡＩＬ（失敗）」結果のいずれかである出力を決定する。
【００３６】
ＣＣＮメッセージの各暗号化ビットグループは、ＧＣＭ−ＡＥＳ方式の独立した鍵／ノンスの実行である。暗号器は、暗号化コンテナの「ｖａｌｕｅ」に対して排他的論理和（たとえば、ＸＯＲ）演算を実施することができる。したがって、暗号文Ｃは、いくつかのＸＯＲ演算されたバイトといくつかのプレーンテキストバイトとの混合を含む。関連データＡは、すべての先行する検証区画および現在の検証区画を含む。検証区画の例示的なフォーマットは、図５に関係して下記に説明されている。
【００３７】
バイトカウンタは、暗号文ＣがＣＣＮｘメッセージ全体であることを明確にするために、メッセージのバイト０からメッセージの終わりまで作動することができる。暗号器は、ＸＯＲ範囲の外側にあるメッセージ区画のＡＥＳブロック（Ｋ，Ｙｉ）を計算する必要はない。いくつかの実施形態において、暗号器は、特定の暗号化コンテナの「ｖａｌｕｅ」バイトのみを使用することができ、コンパクトになった範囲にわたって暗号化を実施することができる。これによって既存のＧＣＭ−ＡＥＳ実施態様とのより高い互換性をもたらすことができるが、暗号器は、関連データＡのすべてのカバーされていないバイト部分を作成する必要があり得、これは、長さを適切に符号化するために追加のオーバヘッドを必要とする場合がある。
【００３８】
対称鍵を共有するための可能な方法
通信エンティティは対称鍵を交換する必要がある。１つの方法において、エンティティは、公開鍵操作を介して対称鍵を交換する。公開鍵操作は、たとえば、ＲＳＡ−ＳＨＡ２５６である暗号システムに基づくことができる。ラッピングされた鍵を、この鍵を使用してメッセージ内に含めることができる、すなわち、メッセージは、公開鍵操作の下でそれ自体の解読鍵を埋め込む。別の方法において、２つの通信エンティティは、ラッピングされた鍵を有する別個のメッセージを交換し、その後、識別子への一致をもってそれを参照する。別の方法において、２つの通信エンティティは、あるバージョンのディフィー・ヘルマン鍵交換のような、オンライン鍵交換メカニズムを使用する。
【００３９】
通信エンティティは、メッセージの部分を暗号化するために使用される対称鍵（複数可）を識別する必要がある。本発明の実施形態において、暗号器は、所与のＴＬＶタイプ値によって識別される１つまたは複数の暗号化コンテキストを確立することができる。メッセージの終わりに、ＶａｌｉｄａｔｉｏｎＡｌｇｏｒｉｔｈｍ（検証アルゴリズム）区画において、暗号器は、暗号化コンテキストを、対称鍵のＫｅｙＩｄと関連付けることができる。対称鍵のＫｅｙＩｄは、パーティによって合意される小さい整数値であってもよい。ＫｅｙＩｄ値は、メッセージ交換において使用される名前プレフィックスに対するものであり得、これによって、異なる名前プレフィックスを用いる複数の通信において、同じＫｅｙＩｄが不明確さなしに使用されることが可能である。
【００４０】
選択的に暗号化されたＣＣＮメッセージの検証および解読
図３は、本発明の一実施形態による、コンテンツ要求デバイスまたはコンテンツ生成デバイスによって、選択的に暗号化されたＣＣＮメッセージを検証および解読するための方法を示す流れ図３００を提示する。動作中、システムは、コンテンツ生成デバイスまたはコンテンツ要求デバイスによって、各々がタイプ、長さ、および値セットに対応する複数のビットグループを含むメッセージを受信し、１つまたは複数のビットグループが暗号化されているものとして指示される（動作３０２）。メッセージはまた、最も一般的なレベルから最も特定的なレベルへと順序付けされた連続する複数の名前構成要素を含む階層構造可変長識別子である名前をも指示する。システムは、認証情報が検証されるか否かを判定する（判断３０４）。たとえば、システムは、鍵ストレージ内で鍵識別子を検索することができる。鍵識別子が見つかった場合、システムはその後、検証区画内に含まれる認証子タグ（複数可）（たとえば、ＣＷＣ−ＭＡＣ署名）を検証することができる。認証情報が検証されない場合、システムはメッセージをドロップまたは廃棄し（３０６）、動作は戻る。認証情報が検証された場合、システムは、対応する対称鍵に基づいて暗号化されているものとして指示されている各ビットグループを解読する（３０８）。
【００４１】
選択的に暗号化されたＣＣＮメッセージのための例示的なフォーマット
図４Ａは、本発明の一実施形態による、選択的に暗号化されたＣＣＮメッセージ４００の例示的なフォーマットを示す。メッセージ４００は、固定ヘッダ４０２と、任意選択のヘッダ４０４と、メッセージタイプ４０６と、メッセージ長４０８と、フィールド４１０および４１２を含むメッセージ値と、行４１４、４２６、４３６、４４２、４５２、４５８、および４６２内に示されているフィールドとを含むことができる。フィールド４１０は、「Ｔ＿ＮＡＭＥ」の値を有するタイプフィールドとすることができ、フィールド４１２は、「Ｎａｍｅ  Ｌｅｎｇｔｈ（名前長）」に等しい値を有する長さフィールドとすることができる。行４１４は、以下のような、名前の第１の名前構成要素および第２の名前構成要素のＴＬＶ値を含むことができる：「Ｔ０」、「Ｌ０」、および「Ｖ０」、ならびに「Ｔ１」、「Ｌ１」、および「Ｖ１」。行４２６は、後続の値またはビットグループ（たとえば、第３の名前構成要素）が、特定の対称鍵に基づく暗号化値であるという指示子を含むことができる。たとえば、行４２６は、「ＴＥ２」の値を有するタイプフィールド、「ＬＥ２＝Ｌ２＋４」の値を有する長さフィールド（たとえば、第３の名前構成要素の長さ＋それぞれ「Ｔ２」および「Ｌ２」の値を有する対応するタイプフィールドおよび長さフィールドの４バイト）、および、柄のある背景で指示されているような、第３の名前構成要素のビットグループの暗号化バージョン（たとえば、「Ｔ２」、「Ｌ２」、および「Ｖ２」）を含む値フィールドを含むことができる。ＴＥ値は、各ＴＥの対応する検証区画にリンクする、様々な値から選択されてもよい。各ＴＥの認証範囲は、ＣＣＮメッセージ全体にわたる。さらに、各ＴＥは、基礎となるＡＥＡＤ方式、たとえば、ＧＣＭ−ＡＥＳの独立した鍵／ノンスの実行である値を指示する。ＴＥ２の検証区画は、下記に説明されているように、行４６８においてメッセージ内に含まれている。
【００４２】
行４３６は、以下のような、名前の第４の名前構成要素のＴＬＶ値を含むことができる：「Ｔ３」、「Ｌ３」、および「Ｖ３」。行４４２は、後続の値またはビットグループ（たとえば、第５の名前構成要素）が暗号化値であるという指示子を含むことができる。たとえば、行４４２は、「ＴＥ４」の値を有するタイプフィールド、「ＬＥ４＝Ｌ４＋４」の値を有する長さフィールド（たとえば、第５の名前構成要素の長さ＋それぞれ「Ｔ４」および「Ｌ４」の値を有する対応するタイプフィールドおよび長さフィールドの４バイト）、および、柄のある背景で指示されているような、第５の名前構成要素のビットグループの暗号化バージョン（たとえば、「Ｔ４」、「Ｌ４」、および「Ｖ４」）を含む値フィールドを含むことができる。ＴＥ４の検証区画は、行４７０においてメッセージ内に含まれている。
【００４３】
行４５２は、「Ｔ＿ＥＸＰＩＲＹ」のタイプおよび対応する長さおよび値を有する別のＴＬＶビットグループを含む。行４５８は、後続の値またはビットグループ（たとえば、メッセージのペイロード）が暗号化値であるという指示子を含むことができる。たとえば、行４５８は、「ＴＥ５」の値を有するタイプフィールド、「ＬＥ５＝Ｌ５＋４」の値を有する長さフィールド（たとえば、ペイロード構成要素の長さ＋それぞれ「Ｔ＿ＰＡＹＬＯＡＤ」および「Ｌ５」の値を有する対応するタイプフィールドおよび長さフィールドの４バイト）、および、柄のある背景で指示されているような、ペイロードのビットグループの暗号化バージョン（たとえば、「Ｔ＿ＰＡＹＬＯＡＤ」、「Ｌ５」、および「Ｖａｌｕｅ」）を含む値フィールドを含むことができる。
【００４４】
メッセージ４００は、メッセージ４００内で使用される各暗号化方式に対応する検証区画も含むことができる。検証区画は、直線的に、または、入れ子式暗号化の事例においては、後順走査に基づいて含まれ得る。メッセージ４００は、行４２６における「ＴＥ２」によってマークされている暗号化に対応する検証アルゴリズムおよび検証ペイロードを指示する行４６８を含むことができる。メッセージ４００はまた、それぞれ行４４２における「ＴＥ４」および行４５８における「ＴＥ５」によってマークされている暗号化に対応する検証アルゴリズムおよび検証ペイロードを指示する行４７０および４７２をも含むことができる。検証区画の例示的なフォーマットは、図５に関係して下記に説明されている。
【００４５】
インタレストの「／ａ／ｂ／ｃ／ｄ／ｅ」のような元々の名前を所与とすると、メッセージ４００に基づく名前の選択的に暗号化されたバージョンは「／ａ／ｂ／ＥＫ２｛ｃ｝／ｄ／ＥＫ４｛ｅ｝」とすることができ、Ｋ２は第３の名前構成要素「ｃ」を暗号化するために使用される対称鍵として指示され、Ｋ４は、第５の名前構成要素「ｅ」を暗号化するために使用される対称鍵として指示される。
【００４６】
図４Ｂは、本発明の一実施形態による、選択的に暗号化されたＣＣＮメッセージ４８０の例示的なフォーマットを示す。メッセージ４８０は、固定ヘッダ４０２と、任意選択のヘッダ４０４と、メッセージタイプ４０６と、メッセージ長４０８と、フィールド４１０および４１２を含むメッセージ値と、行４１４、４２６、４７４、４５２、４５８、および４６２内に示されているフィールドを含む、図４Ａのメッセージ４００と同様のフィールドを含むことができる（異なるフィールドは、対応するラベルの周囲の点線の円でマークされている）。行４１４および４２６は、第１の名前構成要素、第２の名前構成要素、および第３の名前構成要素について図４Ａと同様の情報を含む。行４７４は、後続の値またはビットグループ（たとえば、第４の名前構成要素および第５の名前構成要素）が暗号化値であるという指示子を含むことができる。たとえば、行４７４は、「ＴＥ３」の値を有するタイプフィールド、「ＬＥ３＝Ｌ３＋Ｌ４＋８」の値を有する長さフィールド（たとえば、第４の名前構成要素の長さ＋第５の名前構成要素の長さ＋それぞれ「Ｔ３」、「Ｌ３」、「Ｔ４」、および「Ｌ４」の値を有する、それぞれの対応するタイプフィールドおよび長さフィールドの８バイト）、および、柄のある背景で指示されているような、第４の名前構成要素および第５の名前構成要素のビットグループの暗号化バージョン（たとえば、「Ｔ３」、「Ｌ３」、および「Ｖ３」、ならびに「Ｔ４」、「Ｌ４」、および「Ｖ４」）を含む値フィールドを含むことができる。メッセージ４８０の行４５２、４５８、４６２、４６８、および４７２は、図４Ａのメッセージ４００に関係して説明されているものと同様の情報を含む。メッセージ４８０は、メッセージ４８０内で行４７４における「ＴＥ３」によってマークされている暗号化に対応する検証アルゴリズムおよび検証ペイロードを指示する行４７６を含む。
【００４７】
インタレストの「／ａ／ｂ／ｃ／ｄ／ｅ」のような元々の名前を所与とすると、メッセージ４８０に基づく名前の選択的に暗号化されたバージョンは「／ａ／ｂ／ＥＫ２｛ｃ｝／ＥＫ３｛／ｄ／ｅ｝」とすることができ、Ｋ２は第３の名前構成要素「ｃ」を暗号化するために使用される対称鍵として指示され、Ｋ３は、第４の名前構成要素および第５の名前構成要素「／ｄ／ｅ」を暗号化するために使用される対称鍵として指示される。
【００４８】
図４Ｃは、本発明の一実施形態による、入れ子式暗号化による選択的に暗号化されたＣＣＮメッセージ４９０の例示的なフォーマットを示す図である。メッセージ４９０は、固定ヘッダ４０２と、任意選択のヘッダ４０４と、メッセージタイプ４０６と、メッセージ長４０８と、フィールド４１０および４１２を含むメッセージ値と、行４１４、４８２、４９２、４５２、４５８、および４６２内に示されているフィールドを含む、図４Ａのメッセージ４００と同様のフィールドを含むことができる。行４１４は、第１の名前構成要素および第２の名前構成要素について図４Ａと同様の情報を含む。
【００４９】
行４８２は、後続の値またはビットグループ（たとえば、第３の名前構成要素、ならびに、その後入れ子式暗号化において、第４の名前構成要素および第５の名前構成要素）が暗号化値であるという指示子を含むことができる。たとえば、行４８２は、「ＴＥ２」の値を有するタイプフィールド、および、「ＬＥ２＝Ｌ２＋４＋Ｌ３＋Ｌ４＋１２」の値を有する長さフィールドを含むことができる。「ＬＥ２」は、第３の名前構成要素の長さ＋（「Ｔ２」および「Ｌ２」の値を有する）対応するタイプフィールドおよび長さフィールドの４バイト＋第４の名前構成要素および第５の名前構成要素の長さ＋（それぞれ「ＴＥ３」、「ＬＥ３」、「Ｔ３」、「Ｌ３」、「Ｔ４」、および「Ｌ４」の値を有する）それぞれの対応するタイプフィールドおよび長さフィールドの１２バイトに基づいて計算される。行４８２は、柄のある背景で指示されているような、第３の名前構成要素のビットグループの暗号化バージョン（たとえば、「Ｔ２」、「Ｌ２」、および「Ｖ２」）と、行４９２に図示されている入れ子式暗号化の両方を含む値フィールドを含むことができる。行４９２は、行４８２のＴＥ２コンテナ内に含まれている入れ子式暗号化を指示する。行４９２は、「ＴＥ３」の値を有するタイプフィールド、および、「ＬＥ３＝Ｌ３＋Ｌ４＋８」の値を有する長さフィールドを含むことができる。「ＬＥ３」は、第４の名前構成要素および第５の名前構成要素の長さ＋（それぞれ「Ｔ３」、「Ｌ３」、「Ｔ４」および「Ｌ４」の値を有する）対応するタイプフィールドおよび長さフィールドの８バイトに基づいて計算される。行４９２はまた、柄のある背景で指示されているような、第４の名前構成要素および第５の名前構成要素の暗号化バージョン（たとえば、「Ｔ３」、「Ｌ３」、「Ｖ３」、「Ｔ４」、「Ｌ４」、および「Ｖ４」）を含む値フィールドをも含むことができる。
【００５０】
メッセージ４９０の行４５２、４５８、４６２、および４７２は、図４Ａのメッセージ４００に関係して説明されているものと同様の情報を含む。メッセージ４９０内に含まれている検証区画は、ＴＥ２暗号化コンテナ内のＴＥ３値（第４の名前構成要素および第５の名前構成要素）の入れ子式暗号化に基づいてわずかに異なる。一般的に、暗号器は、各暗号化コンテキストまたはコンテナの検証区画を含む。入れ子式暗号化について、入れ子式暗号化に対応する検証区画もまた、同じ親コンテナの下で暗号化されなければならない。たとえば、ＴＥ３はＴＥ２の下での入れ子式暗号化であり、そのため、ＴＥ３に対応する検証区画も、ＴＥ２の下で暗号化される。メッセージ４９０は、このシナリオを示す行４９４を含む。行４９４は、後続の値（たとえば、ＴＥ３検証区画）が暗号化値であるという指示子を含む。行４９４は、「ＴＥ２」の値を有するタイプフィールドと、ＴＥ３の検証区画の長さに対応する「Ｌ」の値の長さフィールドとを含むことができる。行４９６は、「ＴＥ２」によってマークされている暗号化に対応する検証アルゴリズムおよび検証ペイロードを指示し、行４７２は、「ＴＥ５」によってマークされている暗号化に対応する検証アルゴリズムおよび検証ペイロードを指示する。
【００５１】
インタレストの「／ａ／ｂ／ｃ／ｄ／ｅ」のような元々の名前を所与とすると、メッセージ４９０に基づく名前の選択的に暗号化されたバージョンは「／ａ／ｂ／ＥＫ２｛ｃ，ＥＫ３｛／ｄ／ｅ｝｝」とすることができ、Ｋ２は第３の名前構成要素「ｃ」ならびに第４の名前構成要素および第５の名前構成要素の（入れ子式）暗号化バージョンを暗号化するために使用される対称鍵として指示され、Ｋ３は、第４の名前構成要素および第５の名前構成要素「／ｄ／ｅ」を暗号化するために使用される対称鍵として指示される。
【００５２】
図４Ｄは、本発明の一実施形態による、図４Ｃのメッセージ４９０の例示的なフォーマットに対応する、後順走査による符号化グラフ４９８の例示的なフォーマットを示す。グラフ４９８は、左ノードとしてのビットグループの収容、および、右ノードとしてのビットグループの順次的順序付けを示す。関数４９８．１、４９８．２、および４９８．３は、ビットグループをそれらのそれぞれのコンテナにおいて暗号化するための深さ優先探索後順に対応する。たとえば、関数４９８．１は、実施される最初の関数であり、Ｔ３およびＴ４名前構成要素を暗号化するための内側のＴＥ３コンテナ（円内の「１」によってマークされている）に対応する。後順走査に基づいて、次の関数は関数４９８．２であり、これは、Ｔ２ビットグループおよび暗号化Ｔ３コンテナを暗号化するためのＴＥ２コンテナ（円内の「２」によってマークされている）に対応する。最後に、第３の関数は関数４９８．３であり、これは、ペイロードを暗号化するためのＴＥ５コンテナ（円内の「３」によってマークされている）に対応する。いくつかの実施形態において、入れ子式暗号化がなければ、走査は直線的に実施することができ、または、昇順のＴＥ値に基づくことができる。
【００５３】
図４Ｅは、本発明の一実施形態による、図４Ｃのメッセージ４９０の例示的なフォーマットに対応する、後順走査による符号化グラフ４９９の例示的なフォーマットを示す。グラフ４９８と同様に、グラフ４９９は、左ノードとしてのビットグループの収容、および、右ノードとしてのビットグループの順次的順序付けを示す。関数４９９．１、４９９．２、および４９９．３は、ビットグループをそれらのそれぞれのコンテナにおいて解読するための深さ優先探索逆後順に対応する。たとえば、最初の関数は関数４９９．１であり、これは、ペイロードを解読するためのＴＥ５コンテナ（円内の「１」によってマークされている）に対応する。後順走査に基づいて、次の関数は関数４９９．２であり、これは、Ｔ２ビットグループおよび暗号化Ｔ３コンテナを解読するためのＴＥ２コンテナ（円内の「２」によってマークされている）に対応する。最後に、関数４９９．３が第３の関数であり、Ｔ３およびＴ４名前構成要素を解読するための内側のＴＥ３コンテナ（円内の「３」によってマークされている）に対応する。解読は、パケット内にリストされている検証区画の逆順に実施されることに留意されたい。したがって、関数４９９．１〜４９９．３は、図４Ｃ内にリストされている検証区画の逆順に対応する逆後順で実施される。
【００５４】
選択的に暗号化されたＣＣＮメッセージの検証区画のための例示的なフォーマット
図５は、本発明の一実施形態による、選択的に暗号化されたＣＣＮメッセージの検証区画５００の例示的なフォーマットを示す図である。検証区画５００は、検証アルゴリズム（行５０２、５０６、５１２、および５１８）および検証ペイロード（行５２４および５２８）を含むことができる。検証アルゴリズム区画は、ビットグループを暗号化するために使用される、ノンス、および、各対称鍵のＫｅｙＩｄを含むことができる。たとえば、行５０２は、「Ｔ＿ＶＡＬＡＬＧ」の値を有するタイプフィールドと、その値が行５０６、５１２、および５１８に示すフィールドの長さを含む長さフィールドとを含むことができる。行５０６は、ＫｅｙＩｄのＴＬＶビットグループであり、「Ｔ＿ＫＥＹＩＤ」の値を有するタイプフィールドと、長さフィールドと、「ＫｅｙＩＤ」の値フィールドとを含む。行５１２は、ノンスのＴＬＶビットグループであり、「Ｔ＿ＮＯＮＣＥ」の値を有するタイプフィールドと、１〜８バイトの値を有する長さフィールドと、「Ｎｏｎｃｅ（ＩＶ）」の値フィールドとを含む。上述したように、ＫｅｙＩｄは、関連付け設定の間に生成される（ｋｅｙ，ｓａｌｔ）対を識別し、一方で、ノンスは、１〜８バイトサイズであり、０を８バイトまで左詰めされ、ｓａｌｔに付加されて、ＧＣＭ−ＡＥＳ  ＩＶが形成される。
【００５５】
行５１８は、コンテナのＴＬＶビットグループであり、これは、鍵のコンテナへのマッチングを可能にする一定範囲の暗号化コンテナ値である。たとえば、行５１８は、「Ｔ＿ＣＯＮＴＡＩＮＥＲ」の値を有するタイプフィールドと、「２」の値を有する長さフィールドと、「ＴＥ  Ｖａｌｕｅ」である値フィールド（たとえば、図４Ａのメッセージ４００のＴＥ２）とを含むことができる。
【００５６】
行５２４は、「Ｔ＿ＰＡＹＬＯＡＤ」の値を有するタイプフィールドと、（ＲＦＣ  ４１０６に記載されているように）８、１２、または１６バイトを有する長さフィールドとを含み、行５２８は、基礎となるＡＥＡＤ方式に基づいて作成される認証子タグを含む値フィールドを含む。たとえば、上述したようにＡＥＳ−ＧＣＭを使用して、認証子タグは、各暗号化コンテナの暗号化データおよび非暗号化データのすべてにわたって実施されるＧＨＡＳＨ関数に基づいて作成される。
【００５７】
ラッピングソリューション／方法
本明細書に記載されているＣＣＮメッセージの選択的暗号化に加えて、ＣＣＮはまた、ラッピング方法に基づいて暗号化されてもよい。この方法は、ルーティング可能なカプセル化名および様々な「ラッパ（ｗｒａｐｐｅｒ）」ヘッダを用いてインタレストパケットまたはコンテンツオブジェクトパケットをカプセル化することを含む。元々のインタレストの「ラッパ」インタレストを作成するために、エンティティは、Ｔ＿ＥＮＣＡＰパケットを作成し、カプセル化または「ラッパ」名をラッパインタレストに割り当て、元々のインタレストを暗号化コンテナ内で名前の後に配置する。エンティティは、検証区画（たとえば、ＶａｌｉｄａｔｉｏｎＡｌｇおよびＶａｌｉｄａｔｉｏｎＰａｙｌｏａｄ）を付加し、ＶａｌｉｄａｔｉｏｎＡｌｇは、この特定の方式が使用されていることを示し、０バイトの値である。
【００５８】
元々のコンテンツオブジェクトの「ラッパ」コンテンツオブジェクトを作成するために、エンティティは、Ｔ＿ＥＮＣＡＰパケットを作成し、同じラッパインタレスト名をラッパコンテンツオブジェクトに割り当て、元々のコンテンツオブジェクトを暗号化コンテナ内に配置する。元々のコンテンツオブジェクトの暗号化コンテナは一般的に、暗号化またはラッピングされたインタレストとは異なるＴＥ数または暗号化コンテナ指示子を有する。たとえば、消費者が対称鍵Ｋ１に基づいてコンテナ内に元々のインタレストをラッピングする場合、応答する生産者は、異なる対称鍵Ｋ２に基づいて応答するコンテンツオブジェクトをコンテナ内にラッピングする可能性がある。消費者と生産者は両方共、鍵交換プロトコルを介して秘密対称鍵Ｋ１およびＫ２を保持することに留意されたい。元々のインタレストのラッピングと同様に、元々のコンテンツオブジェクトをラッピングするエンティティは、暗号化コンテナによって使用される（ＫｅｙＩＤ，Ｎｏｎｃｅ）対を有するＶａｌｉｄａｔｉｏｎＡｌｇを含み、認証子タグを有するＶａｌｉｄａｔｉｏｎＰａｙｌｏａｄをさらに含む検証区画を付加する。暗号化コンテナが１つしかない（たとえば、ＴＥまたは暗号化コンテナが１つしかない）場合、暗号器は、検証区画内にＴＥ数を含む必要はない。プレーンテキストキャッシュ制御指令（または他のＴＬＶ）は、暗号化インタレストまたはコンテンツオブジェクトパケットの外部でＴ＿ＥＮＣＡＰパケット内に含まれてもよい。
【００５９】
例示的な装置およびコンピュータシステム
図６は、本発明の一実施形態による、ＣＣＮメッセージのビットグループの選択的暗号化を促進する例示的な装置６００を示す。装置６００は、有線または無線通信チャネルを介して互いと通信することができる複数のモジュールを備えることができる。装置６００は、１つまたは複数の集積回路を使用して実現することができ、図６に示すよりも少ないまたは多いモジュールを含んでもよい。さらに、装置６００は、コンピュータシステム内に統合されてもよく、または、他のコンピュータシステムおよび／またはデバイスと通信することが可能である別個のデバイスとして実現されてもよい。具体的には、装置６００は、通信モジュール６０２と、ブロック計算モジュール６０４と、ビットグループ暗号化モジュール６０６と、ビットグループ解読モジュール６０８と、セキュリティモジュール６１０とを備えることができる。
【００６０】
いくつかの実施形態において、通信モジュール６０２は、コンテンツ指向ネットワークのようなコンピュータネットワークにわたって他のネットワークノードへ／からデータパケットを送信および／または受信することができ、データパケットは、各々がタイプ、長さ、値セットに対応する複数のビットグループを含むインタレストまたはコンテンツオブジェクトメッセージに対応することができ、１つまたは複数のビットグループは暗号化のためにマークされる。ブロック計算モジュール６０４は、認証済み暗号化プロトコルに基づいて、メッセージのための複数の暗号ブロックを計算することができる。ビットグループ暗号化モジュール６０６は、１つまたは複数の対称鍵に基づいて暗号化のためにマークされている１つまたは複数のビットグループを暗号化することができ、マークされているビットグループは、１つまたは複数の名前構成要素を含む。ビットグループ暗号化モジュール６０６はまた、暗号化ビットグループを暗号化されているものとして指示することもできる。
【００６１】
通信モジュール６０２は、選択的に暗号化されたメッセージをコンテンツ生成デバイスまたはコンテンツ要求デバイスに送信することができる。ビットグループ暗号化モジュール６０６は、メッセージ内のビットグループと関連付けられるフィールドを設定することによって、または、メッセージ内のビットグループと関連付けられる予備ビットを設定することによって、暗号化ビットグループを暗号化されたものとして指示することができる。
【００６２】
セキュリティモジュール６１０は、メッセージに対する検証区画内に、ノンス、および、対称鍵の各々の鍵識別子を含めることができる。セキュリティモジュール６１０はまた、以下の特徴、すなわち、対称鍵が公開鍵操作を介して交換されること、対称鍵がメッセージ内に含まれる公開鍵に基づいて暗号化されること、検証区画が暗号化を用いる対称鍵暗号システムに基づくこと、コンテンツ生成デバイスの公開鍵識別子がメッセージ内に含まれること、および、コンテンツ要求デバイスとコンテンツ生成デバイスとの間で後続のメッセージにおいて使用するためにショート対称鍵識別子が指定されることのうちの１つをも含むことができる。セキュリティモジュール６１０は、記憶装置内で、メッセージと関連付けられる鍵識別子を検索すること、および、鍵識別子に基づいて署名またはメッセージ認証コードを検証することによって、メッセージと関連付けられる認証情報を検証することができる。
【００６３】
通信モジュール６０２は、選択的に暗号化されたメッセージを受信することができる。メッセージと関連付けられる認証情報の検証（セキュリティモジュール６１０）に応答して、ビットグループ解読モジュール６０８は、暗号化されたものとして指示されている各ビットグループについて、対応する対称鍵に基づいて暗号化ビットグループを解読することができ、ノンス、および、対称鍵の各々の鍵識別子がメッセージの検証区画内に含まれている。ビットグループ解読モジュール６０８は、解読されたビットグループを解読されているものとして指示することができる。
【００６４】
図７は、本発明の一実施形態による、ＣＣＮメッセージのビットグループの選択的暗号化を促進する例示的なコンピュータシステム７０２を示す。コンピュータシステム７０２は、プロセッサ７０４と、メモリ７０６と、記憶デバイス７０８とを含む。メモリ７０６は、管理メモリとしての役割を果たす揮発性メモリ（たとえば、ＲＡＭ）を含むことができ、１つまたは複数のメモリプールを記憶するのに使用することができる。さらに、コンピュータシステム７０２は、表示デバイス７１０、キーボード７１２、およびポインティングデバイス７１４に結合することができる。記憶デバイス７０８は、オペレーティングシステム７１６、コンテンツ処理システム７１８、およびデータ７３０を記憶することができる。
【００６５】
コンテンツ処理システム７１８は、コンピュータシステム７０２によって実行されると、コンピュータシステム７０２に、本開示に記載されている方法および／またはプロセスを実施させることができる命令を含むことができる。具体的には、コンテンツ処理システム７１８が、コンテンツ指向ネットワークのようなコンピュータネットワークにわたって他のネットワークノードへ／からデータパケットを送信および／または受信するための命令を含むことができ、データパケットは、各々がタイプ、長さ、値セットに対応する複数のビットグループを含むインタレストまたはコンテンツオブジェクトメッセージに対応することができ、１つまたは複数のビットグループは暗号化のためにマークされる。コンテンツ処理システム７１８は、認証済み暗号化プロトコルに基づいて、メッセージのための複数の暗号ブロックを計算するための命令を含むことができる（ブロック計算モジュール７２２）。コンテンツ処理システム７１８はまた、１つまたは複数の対称鍵に基づいて暗号化のためにマークされている１つまたは複数のビットグループを暗号化するための命令と、暗号化ビットグループを暗号化されているものとして指示するための命令とをも含むことができる（ビットグループ暗号化モジュール７２４）。
【００６６】
コンテンツ処理システム７１８は、選択的に暗号化されたメッセージを、コンテンツ生成デバイスまたはコンテンツ要求デバイスに送信するための命令をさらに含むことができる（通信モジュール７２０）。コンテンツ処理システム７１８は、メッセージ内のビットグループと関連付けられるフィールドを設定することによって、または、メッセージ内のビットグループと関連付けられる予備ビットを設定することによって、暗号化ビットグループを暗号化されたものとして指示するための命令を含むことができる（ビットグループ暗号化モジュール７２４）。
【００６７】
コンテンツ処理システム７１８は、加えて、メッセージの検証区画内に、ノンス、および、対称鍵の各々の鍵識別子を含めるための命令を含むことができる（セキュリティモジュール７２８）。コンテンツ処理システム７１８は、以下の特徴、すなわち、対称鍵が公開鍵操作を介して交換されること、対称鍵がメッセージ内に含まれる公開鍵に基づいて暗号化されること、検証区画が暗号化を用いる対称鍵暗号システムに基づくこと、コンテンツ生成デバイスの公開鍵識別子がメッセージ内に含まれること、および、コンテンツ要求デバイスとコンテンツ生成デバイスとの間で後続のメッセージにおいて使用するためにショート対称鍵識別子が指定されることのうちの１つまたは複数を含むための命令を含むことができる（セキュリティモジュール７２８）。コンテンツ処理システム７１８はまた、記憶装置内で、メッセージと関連付けられる鍵識別子を検索すること、および、鍵識別子に基づいて署名またはメッセージ認証コードを検証することによって、メッセージと関連付けられる認証情報を検証するための命令をも含むことができる（セキュリティモジュール７２８）。
【００６８】
コンテンツ処理システム７１８はまた、選択的に暗号化されたメッセージを受信する（通信モジュール７２０）ための命令をも含むことができる。コンテンツ処理システム７１８は、メッセージと関連付けられる認証情報の検証（セキュリティモジュール７２８）に応答して、暗号化されたものとして指示されている各ビットグループについて、対応する対称鍵に基づいて暗号化ビットグループを解読するための命令を含むことができ、ノンス、および、対称鍵の各々の鍵識別子がメッセージの検証区画内に含まれている（ビットグループ解読モジュール７２６）。コンテンツ処理システム７１８は、解読されたビットグループを解読されているものとして指示するための命令を含むことができる（ビットグループ解読モジュール７２６）。
【００６９】
データ７３０は、本開示に記載されている方法および／またはプロセスによって、入力として要求されるか、または、出力として生成される任意のデータを含むことができる。具体的には、データ７３０は少なくとも、インタレストまたはコンテンツオブジェクトに対応するパケットまたはメッセージ、タイプ、長さ、および値セットに対応するビットグループ、最も一般的なレベルから最も特定的なレベルへと順序付けされた連続する複数の名前構成要素を含む階層構造可変長識別子（ＨＳＶＬＩ）である名前、複数のビットグループを含むメッセージであって、１つまたは複数のビットグループは暗号化のためにマークされており、メッセージは、ＨＳＶＬＩである名前を指示する、メッセージ、複数の暗号ブロック、認証済み暗号化プロトコルの指示子、１つまたは複数の対称鍵、鍵識別子すなわちＫｅｙＩｄ、ノンス、鍵とｓａｌｔとの対、初期化ベクトル、プレーンテキスト、暗号文、関連データ、認証タグまたは認証子、ＧＨＡＳＨ関数、暗号化ビットグループまたは解読されたビットグループの指示子、ビットグループと関連付けられるフィールドまたは予備ビット、公開鍵操作の指示子、公開鍵、暗号化を用いる対称鍵暗号システムの指示子、公開鍵識別子すなわち公開ＫｅｙＩｄ、ショート対称鍵識別子、鍵ストレージ、ならびに、署名またはメッセージ認証コードを格納することができる。
【００７０】
この詳細な説明に記載されているデータ構造およびコードは一般的に、コンピュータシステムによって使用するためにコードおよび／またはデータを記憶することができる任意のデバイスまたは媒体であってもよいコンピュータ可読記憶媒体上に記憶される。コンピュータ可読記憶媒体は、限定ではないが、揮発性メモリ、不揮発性メモリ、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル多用途ディスクまたはデジタルビデオディスク）のような磁気および光学記憶デバイス、または、現在既知であるかまたは後に開発されるコンピュータ可読媒体を記憶することが可能な他の媒体を含む。
【００７１】
詳細な説明の節に記載されている方法およびプロセスは、上述したようにコンピュータ可読記憶媒体内に記憶することができるコードおよび／またはデータとして具現化することができる。コンピュータシステムが、コンピュータ可読記憶媒体上に記憶されているコードおよび／またはデータを読み出し実行すると、コンピュータシステムは、データ構造およびコードとして具現化されており、コンピュータ可読記憶媒体内に記憶されている方法およびプロセスを実施する。
【００７２】
さらに、上述した方法およびプロセスは、ハードウェアモジュールに含めることができる。たとえば、ハードウェアモジュールは、限定ではないが、特定用途向け集積回路（ＡＳＩＣ）チップ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、および、現在既知であるかまたは後に開発される他のプログラム可能論理デバイスを含むことができる。ハードウェアモジュールが起動されると、ハードウェアモジュールは、ハードウェアモジュール内に含まれている方法およびプロセスを実施する。
【図１】
2017076964.tif 000003
【図２】
2017076964.tif 000004
【図３】
2017076964.tif 000005
【図４Ａ】
2017076964.tif 000006
【図４Ｂ】
2017076964.tif 000007
【図４Ｃ】
2017076964.tif 000008
【図４Ｄ】
2017076964.tif 000009
【図４Ｅ】
2017076964.tif 000010
【図５】
2017076964.tif 000011
【図６】
2017076964.tif 000012
【図７】
2017076964.tif 000013