JP2015511050A - プロセス作業セット隔離のための方法およびシステム - Google Patents

Abstract

本明細書に開示されるシステムおよび方法の実施形態は、オリジナルプロセスが終了した後でも、作業セットのデータが、他のプロセスにアクセス不可能であるように、プロセスの作業セットを隔離してもよい。より具体的には、特定の実施形態では、実行中のプロセスの作業セットは、キャッシュ内に記憶されてもよく、セキュアモードにある間、書き込まれるそれらのキャッシュラインのいずれかに対して、それらのキャッシュラインは、現在実行中のプロセスのためのセキュア記述子と関連付けられてもよい。セキュア記述子は、それらのキャッシュラインへのアクセスがそのプロセスのみに制限され得るように、実行中のセキュアプロセスに属するようなそれらのキャッシュラインを一意的に規定してもよい。

Description

（関連出願）
本願は、米国特許法第１１９条のもと、米国仮特許出願第６１／６１３，２９０号（Ｗｉｌｌｉａｍ Ｖ． Ｏｘｆｏｒｄにより２０１２年３月２０日出願、名称「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｐｒｏｃｅｓｓ Ｗｏｒｋｉｎｇ Ｓｅｔ Ｉｓｏｌａｔｉｏｎ」）に基づく優先権の利益を主張し、それによって、その全体が、参照によって本明細書に援用される。

（技術分野）
本開示は、概して、コンピュータシステムにおけるセキュリティに関する。より具体的には、本開示は、コンピューティングシステムのプロセスと関連付けられたデータ（命令を含む）のセキュア化に関する。さらにより具体的には、本開示は、再帰的セキュリティプロトコルの実装と併せて実行されるコンピューティングシステムのプロセスと関連付けられたデータのセキュア化に関する。

（背景）
コンピュータウイルスおよび他の悪質なソフトウェアは、情報技術業界にとって大きな問題となっている。汎用コンピュータは、定義によれば、任意のコードを作動可能であるので、所与の汎用コンピュータプラットフォーム上において、部分的または全体的のいずれかで、どのソフトウェアの作動が許容されるかの正確な制御を維持することが非常に困難である。この理由から、マルウェアまたは他の種類の望ましくないソフトウェアの実行を防止することが困難であり得る。現在、このレベルの制御が試みられているいくつかの方法が存在するが、攻撃からプロセッサを隔離するための大部分の努力は、２つの基礎的な問題、すなわち、プロセッサプラットフォームにおける汎用性の損失または性能の損失に悩まされている。これらの損失は、セキュアに保たれなければならないデータを自由に公開され得るデータからどのように隔離するかと、承認使用モードと未承認の使用モードとをどのように迅速かつ明確に区別するかとの基礎的な問題から生じる。

第２の、しかし、関連する問題は、著作権管理の問題である。今日作成されている文書、音声、および視覚的芸術作品の大部分は、元々デジタルフォーマットであるか、または最終的にデジタルフォーマットとなる。デジタルデータの特徴の１つは、容易に、実質的に正確に複製可能なことである。この特性は、多種多様な安価な配信メカニズムを促進し、その大部分は容易に制御されるものではない。デジタルコンテンツの配信特有の制限不能性は、過去数十年にわたって著作権法の分野に広範囲に及ぶ影響をもたらした。特定のシステムおよび方法が、そのような複製されたデータのコピーならびに配信を制御するために開発されたが、これらのシステムおよび方法が有する問題の１つは、これらのシステムおよび方法と併用した特定の種類のソフトウェア（例えば、システムおよび方法を修正するか、あるいは未承認または意図されない様式において、そのようなシステムおよび方法によって利用されるデータを取得するコード）の実行を介して、回避され得ることである。

特に、特定の技法が、コンピュータ上で実行されるそのようなセキュリティシステムによってアクセスされる（例えば、読み取られるまたは書き込まれる）データを取得するために利用されてもよい。このデータは、次いで、そのようなセキュリティシステムを回避し、したがって、デジタルデータのコピーおよび配信の制御を回避する試みにおいて利用されてもよい。

故に、そのようなセキュリティシステムのデータが、同様に、セキュア化され得、そのようなデータをセキュア化することによって、そのようなセキュリティシステムの有効性が向上され得るシステムおよび方法を見つける必要性がある。

（概要）
セキュアモードで実行中のプロセスの作業セットの隔離のためのシステムおよび方法の実施形態が、開示される。これらのシステムおよび方法の実施形態が利用されると、妨害されることのない普遍性だけではなく、多くの他のセキュリティシステムに勝る、攻撃に対する一定レベルの保護が取得され得る。

特に、一実施形態では、特定の算出において使用されるデータへの直接アクセスを防止する一方、それでもなお、依然として、そのデータの使用を可能にするためのシステムおよび方法が、提示される。別の実施形態では、あるソフトウェアプロセスによって使用されるデータへのアクセスは、任意の他のソフトウェアプロセスには拒否され得る。データアクセス制御のためのこれらのシステムおよび方法の実施形態は、デジタルセキュリティ、著作権管理、条件付きアクセス、望ましくないコンピュータウイルスに対する保護等を包含し得るが、それらに限定されない、セキュリティの分野を含む、多数の潜在的用途分野において使用されることができる。具体的には、実施形態は、再帰的セキュリティプロトコルと併用して利用され、そのようなセキュリティプロトコルを強化し得る。

加えて、コンピュータシステム、ハードウェア、およびソフトウェアにおいてこれらの種類の方法論を具現化するシステムの実施形態が提示される。全く同一のハードウェア実装は、潜在的に、ソフトウェアの要件に応じて、解決策の全範囲のうちの任意の１つまたはその組み合わせを実装するために使用され得ることに留意されたい。

さらに、実施形態は、一意の協働フレームワーク内でともに作用する３つの交差する技術構成要素から成る、単純および容易に理解されるセキュリティプロトコルを提示する。個々の構成要素の単純性、完全なアーキテクチャ上の独立性、およびその低実装オーバーヘッドは、このシステムを種々のアーキテクチャおよび展開シナリオにとって好適なものにする。実施形態は、したがって、任意の既存のソフトウェアに最小限の変更を伴って、単純な低電力システムだけではなく、高度で複雑な高処理量設計においても展開されることができる。

実施形態に説明されるように実装される場合、そのようなアプローチの実施形態は、「ゼロ知識」側面を保有するものと示され得、したがって、適応的選択暗号文攻撃等の公知の攻撃戦略に直面する際、明白にセキュアであることができる。システムの秘密キーを（直接および間接的の両方において）アーキテクチャ上不可視にすることによって、および、任意のセキュアプロセスの作業セットを任意の他のプロセスから効率的かつ確実に隔離するその能力によって、正しく実装された再帰的セキュリティシステムは、反射攻撃に影響されず、かつ競合解決策が匹敵することができないリターン指向プログラミングエクスプロイトに対する耐性をもたらすことが示され得る。

再帰的セキュリティプロトコルの実施形態はまた、あらゆる種類のマルウェアに対する戦いにおいて有用であり得る。より従来の「Ｐｅｒｍｉｓｓｉｏｎ ｔｏ Ｅｘｅｃｕｔｅ Ｄｅｎｉｅｄ（実行許可拒否）」方法（実行許可要求）」アプローチ（一般に、「ホワイトリスト」対「ブラックリスト」方式として知られる）とは対照的である、その「Ｐｅｒｍｉｓｓｉｏｎ Ｒｅｑｕｉｒｅｄ ｔｏ Ｅｘｅｃｕｔｅにより、再帰的セキュリティプロトコルは、未承認および／または修正されたソフトウェア実行ファイルが、任意のアーキテクチャのシステム上で作動することを防止するために使用されることができる。

一実施形態では、プロセスは、セキュアモードにおいて、プロセッサ上で実行し、データは、キャッシュのライン内に記憶され得、データは、セキュアモードにおいて、プロセッサ上で実行されたプロセスによって記憶されたものである。そのようなキャッシュのラインへのアクセスは、そのプロセスのみがキャッシュのラインにアクセスすることができるように、プロセスと関連付けられたセキュア記述子を使用して、制御され得、セキュア記述子は、プロセッサおよびキャッシュを含むシステムのハードウェア内に記憶された秘密キーに基づく。いくつかの実施形態によると、次いで、アクセスは、プロセスが終了した後でも、制御され得る。

いくつかの実施形態では、セキュア記述子に基づいてセキュアモードに入り、プロセスの作業セット全体が、キャッシュ内に記憶され、キャッシュ以外のメモリ位置への書込は、セキュアモードでは、無効にされる。さらに、キャッシュのラインは、プロセッサと関連付けられたセキュア記述子と関連付けられてもよく、または、プロセスがデータを書き込むとき、キャッシュのラインと関連付けられたセキュリティフラグが、設定されてもよい。

別の実施形態では、キャッシュのラインへのアクセスを制御することは、キャッシュのラインが現在実行中のプロセスによってアクセスされていることを決定することと、現在実行中のプロセスが、セキュアモードで実行中であるかどうかを決定することと、現在実行中のプロセスと関連付けられたセキュア記述子を決定することと、ラインと関連付けられたセキュア記述子とセキュア記述子とを比較することと、現在実行中のプロセスがセキュアモードで実行中であり、かつ、セキュア記述子が整合する場合のみ、アクセスを可能にすることとを含んでもよい。

本発明のこれらおよび他の側面は、以下の説明および付随の図面と併せて検討されることによって、さらに認識および理解される。しかしながら、以下の説明は、本開示の種々の実施形態およびその多数の具体的詳細を示すが、限定ではなく、例証として与えられることを理解されたい。多くの代用、修正、追加、および／または再配列が、その精神から逸脱することなく、本発明の範囲内で行われてもよく、本発明は、全てのそのような代用、修正、追加、および／または再配列を含む。

本明細書に付随し、その一部を形成する図面は、本発明の特定の側面を図示するために含まれる。本発明ならびに本発明を提供されるシステムの構成要素および動作のより明確な概念は、例示的であり、したがって、図面に例示される限定ではない実施形態を参照することによって、より容易に明白となり、図面において、同一の参照番号は、同一の構成要素を示す。本発明は、本明細書に提示される説明と組み合わせて、これらの図面のうちの１つ以上を参照することによって、さらに理解され得る。図面に例示される特徴は、必ずしも、正確な縮尺で図示されていないことに留意されたい。

図１は、コンテンツ配信のためのアーキテクチャの一実施形態を図示する。 図２は、標的デバイスの一実施形態を描写する。 図３は、セキュア実行コントローラの一実施形態を描写する。 図４Ａおよび図４Ｂは、プロセス作業セット隔離のために使用されるキャッシュの実施形態を描写する。 図５は、セキュア化コードブロック実行の実施形態を描写する。 図６は、セキュア化コードブロック実行の実施形態を描写する。 図７は、セキュア化コードブロック実行の実施形態を描写する。 図８〜図１４は、プロセス作業セット隔離の実施形態を描写する。 図８〜図１４は、プロセス作業セット隔離の実施形態を描写する。 図８〜図１４は、プロセス作業セット隔離の実施形態を描写する。 図８〜図１４は、プロセス作業セット隔離の実施形態を描写する。 図８〜図１４は、プロセス作業セット隔離の実施形態を描写する。 図８〜図１４は、プロセス作業セット隔離の実施形態を描写する。 図８〜図１４は、プロセス作業セット隔離の実施形態を描写する。 図１５は、複合キー生成の実施形態を描写する。 図１６は、複合キー生成の実施形態を描写する。 図１７は、複合キー生成の実施形態を描写する。 図１８は、復号化キーデータ構造の実施形態の表現である。 図１９は、セキュリティプロトコルの暗号化および配信プロセスの実施形態のための図である。 図２０は、セキュリティプロトコルの実施形態のための復号化およびローディングプロセスの図である。 図２１は、セキュリティプロトコルの暗号化／復号化プロセスの一実施形態の図である。 図２２は、キーリストデータ構造の実施形態の表現である。 図２３は、一時キー所有権譲渡手順の実施形態の図である。 図２３は、一時キー所有権譲渡手順の実施形態の図である。 図２４は、複合キーの作成の一実施形態を図示する。 図２５Ａおよび図２５Ｂは、デジタル署名またはその同様のものの作成の実施形態を図示する。 図２５Ａおよび図２５Ｂは、デジタル署名またはその同様のものの作成の実施形態を図示する。 図２６Ａおよび図２６Ｂは、複合キー構造とセキュア化コードブロックの使用の実施形態を図示する。 図２６Ａおよび図２６Ｂは、複合キー構造とセキュア化コードブロックの使用の実施形態を図示する。 図２７は、複合メッセージダイジェストの使用の一実施形態を図示する。 図２８Ａ、図２８Ｂ、および図２８Ｃは、セキュア化コードブロックメッセージの実施形態を図示する。 図２８Ａ、図２８Ｂ、および図２８Ｃは、セキュア化コードブロックメッセージの実施形態を図示する。 図２８Ａ、図２８Ｂ、および図２８Ｃは、セキュア化コードブロックメッセージの実施形態を図示する。 図２９は、復号化動作の一実施形態を図示する。 図３０は、複合キーの使用の一実施形態を図示する。 図３１は、候補コードブロックの承認における複合キーの使用の一実施形態を図示する。 図３２は、復号化動作の一実施形態を図示する。 図３３は、コードブロックの照合の一実施形態を図示する。 図３４は、再帰的セキュリティプロトコルを使用して行われる復号化動作の一実施形態を図示する。 図３５は、コード照合の動作の一実施形態を図示する。 図３６は、デジタル署名機能ブロックの一実施形態を図示する。

（詳細な説明）
本発明ならびにその種々の特徴および有利な詳細は、付随の図面に図示されて以下の説明に詳述される非限定的実施形態を参照して、より完全に説明される。公知の開始材料、処理技法、構成要素、および機器の説明は、本発明を詳細において不必要に曖昧にしないように、省略される。しかしながら、詳細な説明および特定の例は、本発明の好ましい実施形態を示すが、限定ではなく、単なる例証として与えられることを理解されたい。基礎をなす発明の概念の精神および／または範囲内の種々の代用、修正、追加、および／または並べ替えは、本開示から当業者に明白となる。本明細書で論じられる実施形態は、コンピュータ読み取り可能な媒体（例えば、ハードディスク（ＨＤ））、ハードウェア回路または同様のもの、あるいは任意の組み合わせ上に存在し得る好適なコンピュータ実行可能な命令に実装されることができる。

本明細書で使用される場合、用語「ｃｏｍｐｒｉｓｅｓ（備える）」、「ｃｏｍｐｒｉｓｉｎｇ（備えている）」、「ｉｎｃｌｕｄｅｓ（含む）」、「ｉｎｃｌｕｄｉｎｇ（含んでいる）」、「ｈａｓ（有する）」、「ｈａｖｉｎｇ（有している）」、またはそれらの任意の他の変形例は、非排他的包含を網羅することが意図される。例えば、要素の列挙を含むプロセス、物品、または装置は、必ずしも、それらの要素のみに限定されず、明示的に列挙されない要素、あるいはそのようなプロセス、物品、または装置に固有ではない他の要素を含んでもよい。さらに、そうではない旨が明示的に記述されない限り、「ｏｒ（または）」とは、包含的「ｏｒ」を指し、排他的「ｏｒ」を指すわけではない。例えば、条件ＡまたはＢは、以下のうちの任意の１つによって充足される。Ａは真（または、存在する）であり、Ｂは偽である（または、存在しない）、Ａは偽であり（または、存在しない）、Ｂは真である（または、存在する）、ならびにＡおよびＢの両方が、真である（または、存在する）。

加えて、本明細書において与えられる任意の例または例示は、それらが利用される任意の用語（単数または複数）の定義に関する制限、限定、あるいはそれらの表明として、いかようにも見なされるものではない。代わりに、これらの例または例示は、１つの特定の実施形態に関して、例示のみとして説明されるものと見なされるべきである。例えば、本明細書に説明されるような実施形態は、再帰的セキュリティシステムの文脈において、その実装と併せて説明されるが、他の実施形態も、他の文脈において、セキュアプロセス作業セットに有用に適用され得ることに留意されたい。

当業者は、これらの例または例示が利用される任意の用語（単数または複数）が、それらとともにまたは明細書内の別の箇所に与えられ得るか、あるいは与えられこともある、他の実施形態を包含し、あらゆるそのような実施形態は、その用語（単数または複数）の範囲内に含まれることが意図されることを理解する。そのような非限定的例および例示を指す言葉として、「ｆｏｒ ｅｘａｍｐｌｅ（例えば）」、「ｆｏｒ ｉｎｓｔａｎｃｅ（例えば）」、「ｅ．ｇ．（例えば）」、「ｉｎ ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ（一実施形態では）」を含むが、それららに限定されない。

本発明の実施形態は、ネットワーク（例えば、インターネット、イントラネット、インターネット、ＷＡＮ、ＬＡＮ、ＳＡＮ等）に通信可能に結合されたコンピュータ、別のコンピュータまたは独立型コンピュータ内に実装されることができる。当業者に公知のように、コンピュータは、中央処理ユニット（「ＣＰＵ」）またはプロセッサ、少なくとも１つの読取専用メモリ（「ＲＯＭ」）、少なくとも１つのランダムアクセスメモリ（「ＲＡＭ」）、少なくとも１つのハードドライブ（「ＨＤ」）、および１つ以上の入力／出力（「Ｉ／Ｏ」）デバイスを含み得る。Ｉ／Ｏデバイスは、キーボード、モニタ、プリンタ、電子ポインティングデバイス（例えば、マウス、トラックボール、スタイレット等）、または同様のものが挙げられ得る。実施形態では、コンピュータは、ネットワーク上の少なくとも１つのデータベースへのアクセスを有する。

ＲＯＭ、ＲＡＭ、およびＨＤは、ＣＰＵによって実行可能あるいはＣＰＵによって実行可能であるようにコンパイルまたは解釈されることが可能なコンピュータ実行可能な命令を記憶するためのコンピュータメモリである。本開示では、用語「コンピュータ読み取り可能な媒体」は、ＲＯＭ、ＲＡＭ、およびＨＤに限定されず、プロセッサによって読み取ることができる任意のタイプのデータ記憶媒体を含むことができる。例えば、コンピュータ読み取り可能な媒体は、データカートリッジ、データバックアップ磁気テープ、フロッピー（登録商標）ディスケット、フラッシュメモリドライブ、光学データ記憶ドライブ、ＣＤ−ＲＯＭ、ＲＯＭ、ＲＡＭ、ＨＤ、または同様のものを指し得る。本明細書に説明されるプロセスは、コンピュータ読み取り可能な媒体（例えば、ディスク、ＣＤ−ＲＯＭ、メモリ等）上に存在し得る、好適なコンピュータ実行可能な命令に実装されてもよい。代替として、コンピュータ実行可能な命令は、ソフトウェアコード構成要素として、ＤＡＳＤアレイ、磁気テープ、フロッピー（登録商標）ディスケット、光学記憶デバイス、あるいは他の適切なコンピュータ読み取り可能な媒体または記憶デバイス上に記憶されてもよい。

本発明の一例示的実施形態では、コンピュータ実行可能な命令は、Ｃ＋＋、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）、あるいは任意の他のプログラミングまたはスプリプティングコードのラインであってもよい。特定の実施形態では、ＨＴＭＬは、ＪａｖａＳｃｒｉｐｔ（登録商標）を利用して、コーディングを通した自動化および計算の手段を提供してもよい。他のソフトウェア／ハードウェア／ネットワークアーキテクチャも、使用されてもよい。例えば、本発明の機能は、１つのコンピュータ上に実装されてもよく、または２つ以上のコンピュータ間で共有されてもよい。一実施形態では、本発明の機能は、ネットワーク内に分散されてもよい。本発明の実施形態を実装するコンピュータ間の通信は、公知のネットワークプロトコルに準拠して、任意の電子信号、光学信号、無線周波数信号、または他の好適な通信の方法およびツールを使用して、達成されることが可能である。別の実施形態では、システム間のこの通信は、印刷媒体を使用することによってもたらされてもよく、ユーザは、それを手動で入力することによって、通信されるデータを標的「終点」システムに提供することができる。

加えて、開示される実施形態の機能は、１つのコンピュータ上に実装されてもよいか、あるいはネットワーク内またはネットワークを横断して、２つ以上のコンピュータ間に共有／分散されてもよい。実施形態を実装するコンピュータ間の通信は、公知のネットワークプロトコルに準拠して、任意の電子信号、光学信号、無線周波数信号、または他の好適な通信の方法およびツールを使用して、達成されることができる。本開示の目的のために、モジュールは、１つ以上の機能を行なうように構成された、１つ以上のコンピュータプロセス、コンピューティングデバイス、またはその両方であることを理解されたい。モジュールは、これらの機能にアクセスするために利用され得る、１つ以上のインターフェースを提示してもよい。そのようなインターフェースとして、ＡＰＩ、ウェブサービスのために提示されるウェブサービスインターフェース、遠隔手続呼び出し、遠隔メソッド呼び出し等が挙げられる。

前述のように、デジタル配信は、混合的結果を伴って、メディア業界に完全かつ取消不可能な変化をもたらした。任意の技術的進歩同様に、デジタル形式への移行は、創造的技術のための豊富な新しい機会を可能にした。しかしながら、その過程において、この変革は、芸術的資産を配信して収益化する最善の方法に対する長きにわたる課題を呈することになった。

特定の問題の１つは、デジタルデータをコピーすることの容易性に対処する必要があることである。偽造は、元の技術が存在する限り、問題となるが、納得のいくコピーの作成には、歴史的には、有能な技能者（すなわち、専門的偽造者）を必要としていた。デジタル革命は、２つの注目に値する側面において、そのルールを変化させた。第１に、デジタル作品のコピーは、正確な複製物であり得る、すなわち、「元のもの」と判別不可能であり得る。したがって、デジタル作品の「本物」と「違法」コピーとを区別する実践的方法は存在し得ない。第２の変化は、正確な複製コピーは、無視できるほど低コストで、事実上、誰でも、自由自在に作成することができることである。

これらの２つの側面は、デジタル作品の本物ならびに不正コピーを配信するための、これまでにない機会を生成する。歴史的には、作品の価値は、切り離せたとしても、物理的物体と密接に結び付けられていた。しかしながら、デジタル世界では、コピーあたり無視できるほどのコストで作品をグローバルに送達する能力は、著作権所有者および作品の未承認配信から利益を受ける人物の両方のための原動力を変化させている。

デジタル著作権管理（ＤＲＭ）の開始。ＤＲＭシステム成功の目標の１つは、「無許可」様式におけるデジタル作品のコピーの普及を防止することである。この戦略は、物理的物体と作品との間の歴史的つながりを整合させる。デジタル時代では、この戦略は、多くの理由から欠点があるが、この「コピー制御」アプローチは、ＤＲＭシステムの大部分が構築される前提を維持している。

デジタルデータ配信の場合、「制御された」データをコピーすることは、配信されるときに生じる。配信点に起因するデータは、その意図された再生デバイス（単数または複数）に終着する前に、相当数の中間体を通過し得る。各中間デバイスは、データストリーム全体が通過すると、潜在的に、データストリーム全体の正確な複製コピーを作成し得る。したがって、グローバルに配信されるデジタルデータを「コピーすること」を制限する試みは、本質的に、意味がない場合がある。多くの場合、配信されるデジタルデータは、常時、コピーされ得る。

しかしながら、デジタルデータの暗号化されたバージョンは、典型的には、元のものとはあまり似ていない。データを復号化する能力は、実施形態によると、秘密のままである、単一の（通常、グローバル）キーによって媒介され得る。

事実上、グローバルキーの保有は、著作権付き作品を保有することと同等である。したがって、暗号化プロセスが正しく行なわれる場合、理論上、任意の所与の著作権付き作品の暗号化されたバージョンの任意の数のコピーの自由な配信を妨害するものは何もない。実際、関連問題は、コピー防止ではなく、復号化プロセス自体（およびグローバル暗号化キー）の制御となる。

このように、デジタル配信の問題を、（典型的には、はるかに大きな）暗号化されたデータセットの制御ではなく、秘密キーの制御の問題に変換することができる。所与のデータセットのサイズが大きくなるにつれて、隠蔽または少なくとも制御を維持することがより困難になることに留意されたい。当然ながら、秘密キーのサイズが小さくなるにつれて、そのキーの値を推測することがより容易になる。したがって、セキュリティシステムの成功のための的確なトレードオフは、秘密キーのサイズが可能な限り小さいが、容易に推測されるほど小さくはないように、秘密キーのサイズを最適化することである。

別の懸念は、配信されるデータセットをグローバルに暗号化すべきかどうか（前述のように、これは、次いで、自由に共有されることができる）、またはこの同一のデータセットの複数の個々の暗号化されたコピーを配信し、指定された承認受信者のそれぞれが、個々に暗号化されたコピーを与えられるべきかどうかである。そのような方式の明白な非効率性に加えて、これは、ほとんどの場合、実際には、単一の「グローバル」暗号化（関連付けられた「グローバル」暗号化キーを伴う）を行い、単独で（および、グローバルに）暗号化されたデータセットを単に配信することよりもセキュアではない戦略である。これは、暗号化されたデータセットが全て、暗号化プロセスにおいて使用される秘密キーの値に関する大量の付加的情報を提供するために分析され得る共通統計を伴う共通プレーンテキストソースを有するという事実のためである。したがって、的確な戦略は、ほとんどの場合は、単一の暗号化（単一のグローバル秘密キーを伴う）を行い、グローバルに暗号化されたデータセットのみを配信することである。

一時的に、グローバル秘密キーの「承認」コピーを正当な顧客に正常かつセキュアに伝送するために管理されていたと仮定する。その場合、問題は、その顧客が、この同一のグローバルキーを他の潜在的に未承認のエンティティと共有しないようにどのように防ぐかということになる。したがって、これらのキーの合法所有者による保有後も、承認されたグローバル復号化キーを管理する何らかの方法を定義することが所望され得る。さらに、いったんグローバルキーが、暗号化されたデータセットの正当なコピーを復号化するために使用されると、また、復号化されたデータセットの承認所有者が、未承認様式において、復号化されたデータセットを他者に再配信しないように防ぐ方法の問題が検討され得る。

したがって、セキュリティ「エンベロープ」は、単なる復号化プロセスを超えて、制御メカニズムの境界を拡張させることが望ましい。１つの点では正しく復号化されているが、その他の点では「制御されていない」デジタルコピーが、作成される場合、その制御されていないコピーは、制限なく、デジタル的に複製されることができる。いったん「デジタルの魔人」が解き放たれると、決してランプの中に戻すことはできない。したがって、（著作権付きまたは別の）データを真に制御するために、暗号化されたデータを正しく復号化したエンティティが、復号化されたバージョンを再配信しないように防がれるべきである。したがって、デジタルデータ（例えば、著作権付きデータ）の効果的制御の目標を達成するために、復号化および任意の潜在的再配信の両方を制御することが望ましい。とりわけ、データセットの復号化およびその同一のデータセットの表示が、同一のデバイスで生じない場合、伝送が、事実上、再配信プロセスに相当するため、復号化デバイスとディスプレイデバイスとの間の伝送リンクを保護する必要があり得る。それから、この場合、伝送リンクは、外部傍受者および干渉に対して、配信の一次手段と同一のロバスト性を呈するべきである。そうでなければ、見込まれる攻撃者は、単純に、より脆弱なリンクを標的にし得る。

２００７年４月１０日発行の米国特許第７，２０３，８４４号「Ｒｅｃｕｒｓｉｖｅ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｄｉｇｉｔａｌ Ｃｏｐｙｒｉｇｈｔ Ｃｏｎｔｒｏｌ」、２００８年１１月２５日発行の米国特許第７，４５７，９６８号「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ ａ Ｒｅｃｕｒｓｉｖｅ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｄｉｇｉｔａｌ Ｃｏｐｙｒｉｇｈｔ Ｃｏｎｔｒｏｌ」、２０１０年６月２９日発行の米国特許第７，７４７，８７６号「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ ａ Ｒｅｃｕｒｓｉｖｅ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｄｉｇｉｔａｌ Ｃｏｐｙｒｉｇｈｔ Ｃｏｎｔｒｏｌ」、２００９年１１月１０日出願の米国特許出願第１２／６１５，８４３号「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｎｔｒｏｌ ｏｆ Ｃｏｄｅ Ｅｘｅｃｕｔｉｏｎｏｎ ａ Ｇｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｃｏｍｐｕｔｉｎｇ Ｄｅｖｉｃｅ ａｎｄ Ｃｏｎｔｒｏｌ ｏｆ Ｃｏｄｅ Ｅｘｅｃｕｔｉｏｎ ｉｎ ａｎ Ｒｅｃｕｒｓｉｖｅ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ」、２０１０年５月２７日出願の米国特許出願第１２／７８８，５１６号「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ ａ Ｒｅｃｕｒｓｉｖｅ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｄｉｇｉｔａｌ Ｃｏｐｙｒｉｇｈｔ Ｃｏｎｔｒｏｌ」、および２０１３年１月１８日出願の米国特許出願第１３／７４５，２３６号「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ ａ Ｒｅｃｕｒｓｉｖｅ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｄｉｇｉｔａｌ Ｃｏｐｙｒｉｇｈｔ Ｃｏｎｔｒｏｌ」を含む、データの制御を効果的に維持するための特定の非常に効果的な技法が、開発されており、その主題は、本願の図１８〜図３６に関して説明される。これらの技法は、例えば、ＤＲＭ、著作権保護、または他のタイプの制御と併せて、事実上、任意のタイプのデータの制御を維持するために効果的に使用され得る。

前述の出願および特許の検討から、そのような技法の実施形態は、複合暗号化を利用して、デジタルデータをエンコードし得ることが認識され得る。複合暗号化の一実施形態では、単一キー（例えば、グローバルキー）は、それだけでは、エンコードされたデータセットを正しくデコードすることができない。各キーは、複合キーを構築するために、少なくとも１つの他のキーと組み合わせられなければならない。便宜上、複合キーが含まれる元の個々のキーは、前駆体キーと呼ばれる。任意の複合キーは、少なくとも２つの前駆体キーを組み合わせることによって構築され得るが、最少２つから成る複合キーを仮定すると、単一複合キーは、実際、任意の数の前駆体キーに基づき得ることが分かる。これがどのように達成され得るかは、以下に論じられる。

一実施形態では、このチェーン全体における前駆体キーのうちの少なくとも１つが、「秘密」として見なされる場合、他の前駆体キーのいずれも、潜在的に、公開データであってもよく、したがって、全体的セキュリティシステムの必要性およびアーキテクチャに応じて、公開または非公開のいずれであってもよいことに留意されたい。少なくとも１つの秘密前駆体キーが所与の複合キーの構築チェーン内に存在する限り、複合キーベースのシステムのセキュリティ全体は、本質的に、その単一秘密前駆体キーのセキュリティが条件とされ得ることが示され得る。

複合キーを作成するための複数の方法が存在するが、２つのそのようなメカニズムが、一例として、与えられる。すなわち、一方向方式および可逆方式である。第１の方法の例は、図１５に示される。一方向方式では、複合キーは、セキュアな一方向ハッシュ関数によって生成され得る。本例では、複合キーは、少なくとも２つの前駆体キーを連結し、得られた連結されたデータセットを一方向ハッシュ関数に通すことによって生成されることができる。ハッシュ関数の一方向特性は、この種類の変換を不可逆的にする。これは、結果として生じる複合キーから前駆体キーのうちの任意のものの値を再作成する実践的方法は存在しないことを意味する。一方向ハッシュ関数の第２の属性は、組込データ圧縮機能を含み得ることである。したがって、入力データセットの長さにかかわらず（例えば、前駆体キーは、いずれかの任意の長さであり得る）、結果として生じる出力（複合キー）は、固定長を有する。

複合キーが、３つ以上の前駆体を有し得るという前述の議論に戻ると、このように、単一複合キーは、任意の大きさの集合の前駆体キー入力データを用いて生成されることができることが示され得る。これは、「カスケード化」または「チェーン化」プロセスによって達成されることができ、第１の複合キーが、構築され、次いで、この第１の複合キーは、第２の複合キーへの前駆体キーのうちの１つとして使用される。

そのような一方向複合キー生成プロセスの出力は、固定長であり得るため、この特性は、いくつかの点において有利であり得る。第１に、一方向複合キー手順は、前駆体キー入力のいずれも固定長である必要がないように一般化されることができる。しかしながら、前駆体キー（例えば、秘密前駆体キー）のうちの１つが、固定長であると仮定される場合、（システムのセキュリティ全体が依存する）秘密キー値を保持するためにその固定長前駆体キーをさらに割り当てることができる。

したがって、実施形態によると、例えば、単純なワンタイムプログラマブルレジスタ構造によって実装され得る単一の比較的に小さい固定長レジスタを単純かつ効率的に使用して、任意の大きさの集合の入力データ（例えば、前駆体）から成るシステムのセキュリティ全体を保証することができる。前述のように、これは、最小サイズが容易に推測されることを防止するために十分な大きさである限り、必要な秘密知識を最小サイズまで圧縮するというセキュリティシステム成功の目標に効果的である。

秘密前駆体キーが、例えば、比較的に小さい（かつ容易に実装される）１２８ビット、２５６ビット、５１２ビット等の値に固定される場合でも、平均して、そのような秘密キーを正しく推測するためにかかる時間は、それでもなお、依然として、非常に長くなることに留意されたい。

しかしながら、ある場合には、前駆体キー値を再生成するために、複合キーを「反転」することが可能であることが望ましい。そのような状況では、「可逆複合キー」を作成するために、若干、異なるメカニズムを使用することができる。そのような可逆複合キーを構築し得る方法の一例は、図１６に示される。当然ながら、これが達成され得るいくつかの方法が存在し、図１６に示される例は、単に、そのような例の１つであることを認識されたい。しかしながら、そのような構造の共通特徴は、少なくとも２つの「前駆体」入力が存在することであり得る。ここでは、これらは、プレーンテキスト１６１０およびキー１６２０として示され、前述の一方向複合キー構造の２つの前駆体（例えば、秘密キー前駆体および公開キー前駆体）に対応する。したがって、一方向複合キー同様に、可逆複合キーも、少なくとも２つの前駆体を使用して作成され得る。また、論じられるように、構築は、「カスケード化」または「チェーン化」複合キー構造に一般化されることができ、最終複合構造は、任意の数の前駆体入力に依存する。そのような「カスケード化」可逆複合キーを作成する方法の一例もまた、図１６に示される。

また、前述のように、キー前駆体が、秘密に保たれる場合、非秘密前駆体（例えば、図１６に示される例では、プレーンテキスト１６１０）入力が、既知である場合でも、前駆体の元の値を得られた出力から推測する実践的方法も、暗号化された出力の値を正しく予測する実践的手段もない。したがって、再び、セキュリティ全体は、秘密キー値のみを制御下に保つためのシステムの能力が条件とされる。

可逆方法を使用して、複合キーを作成することによって、第１の前駆体の元の値は、再び、対称暗号化関数に通すことによって、再構築されることができる。この可逆プロセスは、暗号化関数が、第２の複合キーを最初に作成するために使用される同一の前駆体にアクセスし得る限りのみ、可能であることに留意されたい。

複合暗号化の興味深い側面は、任意の数値が、前駆体となり得ることである。この融通性は、再帰的セキュリティシステムが、単純かつ著しく効率的な様式において、非常に複雑な論理構造（したがって、任意の多数の多様な構成要素に依存する）に対応する単一複合キー値を生成することを可能にする。しかしながら、いかなる場合でも、所与の暗号構造におけるいかなるキーの値も、（下層の暗号関数の取り扱いにくさを仮定して）結果として生じる複合キー単独からの発見に対して明白にセキュアである。

論じられるような対称暗号化に加え、非対称暗号化メカニズムを使用して、可逆複合キーを構築することもできる。その場合、可逆複合キーは、次いで、秘密前駆体キーおよび公開−プライベートキー集合のうちの１つを用いたハッシュ関数の「シード処理」から生じるデジタル署名として使用されてもよい。そのような構築は、次いで、所与のプラットフォーム上でセキュア様式において、デジタル文書に署名するために使用され得る。言い換えれば、特定のコンピュータプラットフォームを使用している間、または特定の地理的場所に居る間、またはデジタル形態において表され得る任意の入力パラメータのいくつかの組み合わせにおいてのみ、正しく認証可能なデジタル署名を生成することができる。

故に、再帰的セキュリティを実装するハードウェアデバイス（例えば、標的デバイス）の実施形態では、そのシステム上で実行される任意の複合キー動作のための前駆体のうちの少なくとも１つは、実際のデバイス上にセキュアに記憶されるべきである。したがって、いくつかの実施形態によると、複合キー動作のための１つの前駆体は、標的デバイスのハードウェア内に記憶された秘密キーであってもよい。そのようなハードウェア秘密キーは、多くの場合、そのような再帰的セキュリティシステムの「Ｃｈａｉｎ ｏｆ Ｔｒｕｓｔ（信頼の連鎖）」の基点の一部としての役割を果たし得る。他の実施形態では、システムの他の側面もまた、このハードウェア「Ｃｈａｉｎ ｏｆ Ｔｒｕｓｔ（信頼の連鎖）」内の一部であり得る。そのような側面は、セキュアな一方向ハッシュ関数、ワンタイムプログラマブルシリアル番号レジスタ（アーキテクチャ上可視であり得る）、あるいは、シリコンダイ自体の何らかのパラメータ特性（例えば、閾値電圧対温度曲線）、または、例えば、当該チップが走査／試験モードに置かれるときのみ観察可能な何らかの値さえ、含み得る。このメカニズムを使用して、特定のチップは、別の機能的に同じデバイスと明確かつ個々に区別され得る。

前述の参照特許および出願に説明されるように、また、本明細書に説明されるように、そのような秘密キーは、標的デバイスのプロセッサが、セキュア実行モード（また、セキュア化モードとも呼ばれる）で動作中であるときのみ、アクセス可能であってもよい。したがって、そのような標的デバイス上においてセキュアモードで実行中のプロセスは、秘密キーへのアクセスを有してもよく、この秘密キーに基づいて、データを生成してもよい。

そのようなシステムでは、特定の実施形態では、潜在的に、秘密キーの値が不特定の計算において使用され得る場合でも、非意図的でさえも、その値が暴露されることができないように、秘密キーをさらに隔離することが望ましくあり得る。この目標を達成するそのような手段の１つは、前述の不特定の計算において直接秘密キー値を使用する代わりに、秘密キーに関する一方向セキュアハッシュ関数の出力およびいくつかの他のデータを使用することである。一方向関数が、正しく選択される場合、不特定の計算の出力は、完全に決定論的であるが、それでもなお、秘密キーの値の以前の知識を伴わずには、実践的に予測可能ではない。したがって、システムは、秘密キーを利用するが、それでもなお、秘密キーの値を計算処理上暴露することが不可能であるように構築され得る。

しかしながら、いくつかの計算では、計算の動作が完了に先立って停止される場合、またはそのような計算のある中間結果が外部の観察者に暴露される場合のいずれかでは、潜在的に、何らかの他の秘密を暴露させ得る計算において、秘密キー（または、その何らかの派生物）を使用することが望ましくあり得る。したがって、セキュリティを維持するために、そのような標的デバイスにおけるコードの実行を制御することに加え、標的デバイスにおいてセキュアモードで実行される任意のプロセスの作業セット（例えば、キャッシュ、メインメモリ、レジスタ等のメモリから読み取られ、またはそこに書き込まれるデータ）を隔離することも望ましくあり得る。より具体的には、例えば、そのようなセキュリティシステムが、標的デバイス自体および復号化プロセス中に観察可能な中間結果から分離可能である場合、そのようなセキュリティシステムは、主に、中間攻撃および差分暗号解析の被害を受けやすくあり得る。これは、その他の点では無効な動作の部分的結果が、その他の点では不透明な「ブラックボックス」ベースのシステムであるものへの窓口を提供し得るという事実によるものである。言い換えれば、プロセスの作業セットからの逆行作業によって、セキュアプロセスによって使用されている秘密キーの派生値を発見し、したがって、セキュリティシステムのＣｈａｉｎ ｏｆ Ｔｒｕｓｔ（信頼の連鎖）を危殆化する可能性があり得る。

したがって、標的デバイス上のプロセスの作業セットへのアクセスを制御し得る方法およびシステム、特に、セキュアモードで実行しているプロセスの動作中に読み取られまたは書き込まれるデータが、コードセグメントが作動の過程にある間、または元のコードセグメントが終了した後のいずれでも、任意の他のコードセグメントによって読取不能のままである方法およびシステムの必要性がある。特に、プロセスの１つのインスタンスに属するデータを任意の他のプロセスから明確に隔離することが所望され得る。

そのために、ここで、プロセス作業セット隔離のためのシステムおよび方法の実施形態に注意が向けられる。概して、そのようなシステムおよび方法の実施形態は、オリジナルプロセスが終了した後でも、データが任意の他のプロセスにアクセス不可能であるように、セキュアモードで実行しているプロセスの作業セットを隔離し得る。より具体的には、一実施形態では、現在実行中のプロセスの作業セット全体が、キャッシュ（例えば、オンチップキャッシュ）内に記憶され、そのキャッシュのオフチップ書込およびライトスルーは、セキュア化モードでの実行中、禁止されてもよい。加えて、セキュアモードにある間、書き込まれたそれらのキャッシュライン（例えば、「ダーティ」キャッシュライン）のいずれに対しても、それらのキャッシュラインは、現在実行中のプロセスのためのセキュア記述子と関連付けられてもよい。セキュア記述子は、それらのキャッシュラインへのアクセスがそのプロセスのみに制限され得るように、実行中のセキュアプロセスに属する、それらの関連付けられた「ダーティ」キャッシュラインを一意的に規定してもよい。

一実施形態では、セキュア記述子が、異なるプロセス（異なる時に呼び出される同一のコードセグメントの異なるインスタンス化を含む）間を区別するだけのために十分に一意であることを保証するために、セキュア記述子は、複合キーであってもよい。複合キーは、標的デバイスの秘密キーを使用して、セキュアプロセス記述子として使用するために生み出されてもよい。前述のように、複合キーは、標的デバイスの秘密キーを含まずに、生み出されてもよい。特定の実施形態では、専用ハッシュ関数ブロックが、標的デバイスに提供され、そのようなハッシュブロック（または、ハッシュブロックを備えるセキュアな実行コントローラ）の出力は、標的デバイスの秘密キーを使用して、これらのセキュアプロセス記述子を作成するために使用されてもよい。

さらに、特定の実施形態では、このハッシュ関数の出力は、生成されたセキュアプロセス記述子の実際の値を外部攻撃者に暴露せずに値間に整合があるかどうかを決定するために、そのような生成されたセキュアプロセス記述子（自動的に生成されてもよい）と、アーキテクチャ上可視であるセキュアプロセス記述子とを比較するために使用されてもよい。

また、付加的値もまた、このセキュア記述子を生成するために、一方向ハッシュ関数の評価において、標的デバイスの秘密キーと併用されてもよい。そのような付加的値は、秘密キーの値を危殆化せずに、プロセッサに可視であってもよく、またはそうでなくてもよい。これらの付加的値のいくつかの例は、タイムスタンプ、プロセスＩＤ、以前に計算されたハッシュ関数の結果、またはデジタル形態で表され得る任意の他の属性を含み得る。

加えて、特定の実施形態では、これらの付加的値のサイズは、完全に任意であり得る。一方向ハッシュ関数が組込圧縮属性を有するシステムでは、ハッシュ関数の結果として生じる出力は、固定長であり、したがって、どれだけ多くのハッシュ関数反復が採用されても、ハッシュ関数を通した任意の多数の反復の結果のサイズが固定のままであることを可能にするであろう。このように、セキュアプロセス記述子は、セキュアプロセスの実行の時間ならびに当該セキュアプロセスの呼び出しチェーン全体に関する情報を含んでもよい。したがって、任意の１つのセキュアプロセスは、２つのプロセスが全く同一であるが、単に、例えば、異なる時間において、または異なる「親」プロセスによって呼び出される場合でも、効率的かつ効果的に、任意の他のセキュアプロセスから隔離され得る。

特定の実施形態では、セキュアプロセスのための作業セットが、オンチップキャッシュからオーバーフローし、セキュアプロセス記述子と関連付けられたダーティラインを含むそのキャッシュの一部が、メインメモリに書き込まれる必要がある場合（例えば、ページスワップまたはページアウト動作）、プロセッサとバス（例えば、外部メモリバス）との間の外部データトランザクションは、暗号化されてもよい。そのような暗号化のためのキーは、セキュア記述子自体またはその何らかの派生値、例えば、セキュアプロセス記述子および秘密キーを伴うハッシュ関数の出力であってもよい。

そのような暗号化キーの別の可能性は、セキュアプロセス記述子の暗号化されたバージョンであり得る。この後者の場合において使用される暗号化キーは、現在のセキュアプロセス記述子および他の何らかの値と連結された秘密キーのハッシュ関数の出力であってもよい。この後者の値は、次いで、公開され得る（例えば、平文でメモリに書き出される）。その場合、暗号化され、続いて、最初にメモリに書き出されたデータを実際に生成したセキュアプロセスのみ、正しい復号化キーを再生成し、したがって、メモリからデータキャッシュに読み戻される場合に、元のデータを復元し得る。これは、セキュアプロセスが中断され（かつ、その作業セットがデータキャッシュからスワップされ）、次いで、セキュア様式において、後に再開されることが可能であり得る１つの手段である。

この同一の方式の派生物は、２つのプロセスが異なるセキュアプロセス記述子を有する場合でも、１つのセキュアプロセスから別のプロセスにデータをセキュアに送るするために使用されてもよい。その場合、少なくとも２つの選択肢がある。すなわち、受信者セキュアプロセスによる共有データへの読取専用アクセス、または、共有データへの読取−書込アクセスである。いずれの場合も、２つのプロセスは、一方と他方との間で共有秘密復号化キーを通信するはずである。共有秘密復号化キーが、可逆複合キープロセスによって生成される場合、共有データは、共有データの受信者であるセキュアプロセスによって書込可能であってもよい。共有キーが、一方向複合キーメカニズムに基づく場合、共有データは、受信者のための読取専用アクセスに限定されてもよい。

性能を向上させるために、セキュアプロセスが大量の作業セットを有し得るか、または頻繁に中断される（例えば、多くのページスワップを伴う）特定の場合には、「セキュア」と見なされるプロセス作業セットのサブセットが、作成され（例えば、プロセスのためのダーティキャッシュラインのサブセットのみがセキュア記述子と関連付けられてもよい）、外部メモリに書き出されるとき、それらのキャッシュラインまたはそれらのラインを含むキャッシュの一部のみを暗号化してもよい。

加えて、性能を向上させるために、オフチップ記憶メカニズム（例えば、ページスワップモジュール）が、中断プロセスと並行して、非同期的に作動されることができ（例えば、統合されたＡＥＳ暗号化ハードウェアアクセラレーションを伴うＤＭＡユニットを使用して）、したがって、プロセッサ性能に最小限の影響を及ぼすように設計され得る。別の実施形態では、別個のセキュア「作業セットカプセル化」モジュールが、使用され、作業セットデータがメモリに書き出されることを可能にする前に、暗号化を行なってもよい。

本明細書に提示される実施形態を使用して、次いで、（直接または間接的にのいずれか）システムの秘密キーをアーキテクチャ上非可視にすることによって、かつセキュアプロセスの作業セットを任意の他のプロセスから効率的かつ明確に隔離する能力によって、再帰的セキュリティデバイスは、実質的に、反射攻撃に影響されず、かつ競合する解決策が匹敵することができないリターン指向プログラミングまたは他のプログラミングエクスプロイトに対する耐性をもたらすことが示され得る。したがって、これらの再帰的セキュリティシステムは、難読化を単独で使用するセキュリティの実装と比較して、いくつかの利点を提供し得る。

実施形態をより詳細に論じる前に、本発明の実施形態が効果的に利用され得るアーキテクチャの一般的概要を与えることが、有用となる。図１は、そのようなトポロジの一実施形態を図示する。ここでは、コンテンツ配信システム１０１は、プロトコルエンジンを備える１つ以上の標的ユニット１００（本明細書では、標的または終点デバイスとも呼ばれる）にデジタルコンテンツ（例えば、音声または映像データ、ソフトウェアアプリケーション等を含むビットストリームであってもよい）を配信するように動作し得る。これらの標的ユニットは、例えば、有線または無線ネットワーク、あるいはネットワークで結ばれていないコンピュータデバイス上のコンピューティングデバイスの一部であってもよく、そのようなコンピューティングデバイスとして、例えば、ネットワークを介して、または、コンピュータ読み取り可能な記憶媒体上で、例えば、メール等を介して送達され得る、ビットストリームとして送達されるコンテンツを再生し得るパーソナルコンピュータ、携帯電話、パーソナルデータアシスタント、メディアプレーヤを含む。このデジタルコンテンツは、デジタルコンテンツの実行の制御が、デジタルコンテンツに関して制御されてセキュアに実装され得るように、構成または配信されてもよい。

特定の実施形態では、デジタルコンテンツの制御は、使用許諾権限１０３と併せて遂行されてもよい。この使用許諾権限１０３（中央使用許諾権限と呼ばれ得るが、そのような使用許諾権限は、中央化される必要はなく、その機能は、分散されてもよく、またはその機能は、コンテンツ配信システム１０１、メモリスティック等のハードウェアデバイスへのデータの手動配信等によって達成されてもよいことが理解される）は、キーまたは承認コードを提供してもよい。このキーは、標的デバイスに配信されかつ各標的デバイス（ＴＤｎ）に結び付けられるデジタルコンテンツに暗号学的に依存する複合キー（ＤＳ）であってもよい。一例では、標的デバイスは、アプリケーションをセキュアモードで実行することを試みてもよい。このセキュアアプリケーション（候補コードまたは候補コードブロック（例えば、ＣＣ）と呼ばれ得る）は、特定のデジタルコンテンツにアクセスするために使用されてもよい。

故に、候補コードブロックが、候補コードブロックが配信される特定の標的デバイス１００のプロセッサ上において、セキュアモードで作動することを可能にするために、使用許諾権限１０３は、複合キーの正しい値（その一例は、認証コードと呼ばれ得る）を、候補コードブロックがセキュアモードで実行することを試みている標的デバイスに供給しなければならない（例えば、ＤＳ１をＴＤ１に供給する）。他の標的デバイス（例えば、ＴＤｎ≠ＴＤ１である、ＴＤｎ）は、複合キー（例えば、ＤＳ１）を用いて候補コードブロックを正しく作動することができず、他の複合キー（ＤＳｎ≠ＤＳ１であると仮定されるＤＳｎ）は、その標的デバイス１００（例えば、ＴＤ１）上のその候補コードブロックを用いて、正しく機能しない。

本明細書において後により詳細に説明されるように、標的デバイス１００（例えば、ＴＤ１）が、候補コードブロック（例えば、ＣＣ１）をその命令キャッシュにロードすると（かつ、例えば、ＣＣ１が、セキュアモードで作動させられることが意図されるコードとして識別される場合）、標的デバイス１００（例えば、ＴＤ１）は、その候補コードブロック（例えば、ＣＣ１）のメッセージダイジェスト（例えば、ＭＤ１）を作成するハッシュ関数（ハードウェアベースであり得る）を行なう。このハッシュ関数のためのシード値は、標的デバイス１００のための秘密キー（例えば、ＴＤ１の秘密キー（例えば、ＳＫ１））である。

実際、そのようなメッセージダイジェスト（例えば、ＭＤ１）は、ハッシュ関数結果が、ハッシュのシード値である標的デバイス１００の秘密キー（例えば、ＳＫ１）に依存するため、メッセージ認証コード（ＭＡＣ）ならびに複合キーであってもよい。したがって、メッセージダイジェスト（例えば、ＭＤ１）の結果として生じる値は、標的デバイス１００の秘密キーおよび候補コードブロックの両方に暗号学的に結び付けられる。使用許諾権限が配信した複合キー（例えば、ＤＳ１）が、メッセージダイジェスト（例えば、ＭＤ１）の値と整合する場合、候補コードブロック（例えば、ＣＣ１）が不変でありかつ標的デバイス１００（例えば、ＴＤ１）上においてセキュアモードで作動するために承認されることが保証され得る。標的デバイス１００は、次いで、候補コードブロックをセキュアモードで作動させることができる。

理解され得るように、次いで、一実施形態では、標的デバイス１００のためのセキュアモード実行が行なわれると、標的デバイス１００は、その元の形態から不変であるとして認証され、かつ、コードが実行中の標的デバイス１００に暗号学的に「結び付けられる」コードを実行してもよい。標的デバイスのセキュアモード実行を保証するこの方法は、プロセッサが、ハードウェアリセットに応じて、セキュアモードに入り、次いで、Ｒｏｏｔ−ｏｆ−Ｔｒｕｓｔ（信頼の基点）を確立するために、ハイパーバイザモードまたは同様のもので実行し得る他のシステムと対照的であり得る。

故に、開示されるような実施形態を使用して、使用許諾権限からの複合キー、メッセージダイジェスト、候補コードブロック等（例えば、ＤＳ１、ＭＤ１、ＣＣ１）等のこれらのデータの一部または全部は、標的デバイス１００の秘密キー（例えば、ＳＫ１）が暴露されない限り、完全に公開されてもよい。したがって、標的デバイスの秘密キーの値は、直接または間接のいずれにおいても、決して暴露されないことが所望される。故に、前述のように、本明細書に提示されるシステムおよび方法の実施形態は、秘密キーを直接暴露から保護することに加え、標的デバイス１００上においてセキュアモードで実行されるプロセスの作業セットをセキュア化することによって、標的デバイス１００上の秘密キーの間接暴露に対しても保護し得る。

ここで、デジタルコンテンツの実行を制御すること、または、受信されたデジタルコンテンツと併せて、セキュリティプロトコルを実装することが可能な標的デバイスの一実施形態のアーキテクチャである図２に移る。標的ユニットの要素は、プロセスがセキュア化モードで実行しているときプロセスの作業セットが隔離され得るように、プロセスが標的デバイス上においてセキュア化モードで実行することを可能にする一式のブロックを含んでもよい。これらのブロックは、本実施形態では、ハードウェアとして説明されるが、ソフトウェアが、同等の有効性を伴う類似機能性を達成するために利用されてもよいことに留意されたい。また、特定の実施形態は、本明細書に説明される全ブロックを含み得るが、他の実施形態では、より少ないブロックまたは付加的ブロックを利用してもよいことに留意されたい。

標的デバイス１００は、実行ユニットおよび命令パイプラインを有するプロセッサコアであり得るＣＰＵ実行ユニット１２０を備えてもよい。クロックまたは日付／時間レジスタ１０２は、中央サーバとのセキュアな相互作用によって設定またはリセットされることが可能な自走タイマであってもよい。時間は、セキュアな時間標準についてクエリを行うことによって確立され得るため、この機能をオンチップで有することは便利であり得る。そのような日付／時間レジスタの別の例は、その値が必ずしも単調様式でインクリメントされず、その値が非常に頻繁に繰り返されないレジスタであり得る。そのようなレジスタは、一意のタイムスタンプ値が、特定の理由から要求され得るが、そのタイムスタンプ値が、必ずしも、前もって予測されることができない場合、有用であり得る。したがって、疑似乱数発生器は、そのようなレジスタを実装するための好適なメカニズムであり得る。そのような機能を実装するための別の選択肢は、ハードウェアハッシュ関数１６０の出力を使用して、このレジスタの現在の値を生成することである。そのようなハッシュ関数の出力が、ハッシュ関数の入力のためのシード値またはソルト値として使用される場合、結果として生じる出力シリーズは、統計的に乱数列に類似し得るが、値は、それでもなお、決定論的であり、したがって、潜在的に予測可能であり得る。標的ユニット１００はまた、真性乱数発生器１８２を含んでもよく、これは、十分にランダムな数列を生成するように構成されてもよく、または、次いで、疑似乱数発生システムのためのシード値を供給するために使用されることができる。この疑似乱数発生器はまた、潜在的に、ハードウェア、ソフトウェア、または「セキュアな」ソフトウェアの中に実装されることができる。

一方向ハッシュ関数ブロック１６０は、ハッシュ関数を実質的にハードウェア内に実装するために動作可能であってもよい。一方向ハッシュ関数ブロック１６０は、本明細書において後により詳細に説明されるように、標的デバイス１００をセキュアモードに置くことを制御するために使用され得るかまたは（例えば、標的デバイス１００が、セキュア化モードで実行しているときに）メモリアクセスを制御するために使用され得るセキュア実行コントローラ１６２の一部であってもよい。

一実施形態では、機能ブロック１６０を有する方法の１つは、所与のプロセスがセキュアであるかどうかを評価するために使用される全く同一のＣＰＵ上で作動するセキュアプロセスによって、仮想方式で実装されてもよい。特定の実施形態では、２つの条件が、順守され、そのようなシステムが正しく解析し得ることを保証してもよい。第１に、セキュアモード「評価」動作（例えば、ハッシュ関数）は、評価中のセキュアプロセスの実行から独立して進められる。第２に、ネスト化評価のチェーンが、決定的終点（「Ｃｈａｉｎ ｏｆ Ｔｒｕｓｔ（信頼の連鎖）」の基点または単に「Ｒｏｏｔ−ｏｆ−Ｔｒｕｓｔ（信頼の基点）」と呼ばれ得る）を有し得る。そのような実施形態では、この「Ｒｏｏｔ−ｏｆ−Ｔｒｕｓｔ（信頼の基点）」は、何らかの変更不可能方式において（例えば、ハードウェア内に）実装されるべきシステムの最小部分であってもよい。この最小特徴は、「ハードウェアＲｏｏｔ−ｏｆ−Ｔｒｕｓｔ（信頼の基点）」と呼ばれ得る。例えば、そのような実施形態では、そのようなハードウェアＲｏｏｔ−ｏｆ−Ｔｒｕｓｔ（信頼の基点）の１つは、ファームウェア内（例えば、変更不可能ソフトウェア内）で実現される、一方向ハッシュ関数であり得る。

標的ユニット１００の別の部分は、前述のように、標的ユニット１００の秘密キー（単数または複数）または公開／プライベートキー（以降で説明）またはその派生物のいずれかを使用し得る、ハードウェア支援暗号化／復号化ブロック１７０（暗号化システムまたはブロック、復号化システムまたはブロック、あるいは暗号化／復号化ブロックと交換可能に呼ばれ得る）であってもよい。この暗号化／復号化ブロック１７０は、いくつかの方法で実装されることができる。また、一方向ハッシュ関数と後続の暗号化／復号化システムとのそのような組み合わせは、任意のデジタルデータが暗号化形式またはプレーンテキスト形式で配信されているかどうか、そのデータの照合のために使用可能なデジタル署名発生器を備えてもよいことに留意されたい。プロトコル全体の速度およびセキュリティは、このブロックの構造に応じて変動してもよく、したがって、セキュリティシステムのアップデートに対応するために十分に順応性があるだけでなく、システムに、タイムクリティカルなメッセージのリアルタイム復号化を行わせるために十分に高速であるように構成され得る。

正確にどの暗号化アルゴリズムが、このハードウェアブロック１７０に対して使用されるかは、実施形態にとって重要ではない。最大の融通性を増進するために、実際のハードウェアは、非アルゴリズム的に特有の様式で使用されることに十分に汎用性であることが想定されるが、このメカニズムを実装可能な多くの異なる手段が存在する。この点において、用語「暗号化」および「復号化」とは、暗号化／復号化を行うためのエンジン（アルゴリズム、ハードウェア、ソフトウェア等）を指す場合、本明細書では交換可能に利用されることに留意されたい。理解されるように、対称暗号化が特定の実施形態で使用される場合、同一または類似の暗号化あるいは復号化エンジンが、暗号化と復号化の両方のために使用されてもよい。非対称メカニズムの場合、暗号化および復号化関数は、キーが異なり得る場合でも、実質的に類似してもよく、またはそうでなくてもよい。

標的デバイス１００はまた、データキャッシュ１８０と、実行されるべきコードが記憶され得る命令キャッシュ１１０と、メインメモリ１９０とを備えてもよい。データキャッシュ１８０は、Ｌ１キャッシュまたはＬ２キャッシュ等、所望されるほぼあらゆるタイプのキャッシュであってもよい。一実施形態では、データキャッシュ１８０は、セキュアプロセス記述子をキャッシュの１つ以上のページと関連付けるように構成されてもよく、データキャッシュ１８０のライン（その全部またはいくつかのサブセット）と関連付けられた１つ以上のセキュリティフラグを有してもよい。例えば、セキュアプロセス記述子は、データキャッシュ１８０のページと関連付けられてもよい。

概して、標的デバイス１００の実施形態は、オリジナルプロセスが終了した後でも、データが任意の他のプロセスにアクセス不可能であるように、データキャッシュ１８０内に記憶された、セキュアモードで実行するプロセスの作業セットを隔離してもよい。より具体的には、一実施形態では、現在実行中の作業セット全体が、データキャッシュ１８０内に記憶され、メインメモリ１９０への書込および（例えば、メインメモリ１９０への）そのキャッシュのライトスルーは、セキュア化モードにおいて実行しているとき、（例えば、セキュア化実行コントローラ１６２によって）無効化されてもよい。

加えて、セキュアモードで実行中に書き込まれたデータキャッシュ１８０のそれらのライン（例えば、「ダーティ」キャッシュライン）のいずれに対しても、それらのキャッシュライン（または、それらのキャッシュラインを含むページ）は、現在実行中のプロセスのためのセキュアプロセス記述子と関連付けられてもよい。セキュアプロセス記述子は、それらのキャッシュラインへのアクセスが、（例えば、セキュア化実行コントローラ１６２によって）そのプロセスのみに制限され得るように、それらの関連付けられた「ダーティ」キャッシュラインを実行中のセキュアプロセスに属するとして一意的に規定してもよい。

特定の実施形態では、セキュアプロセスのための作業セットがデータキャッシュ１８０からオーバーフローし、現在実行中のプロセスのセキュリティ記述子と関連付けられたそれらのダーティラインを含む、データキャッシュ１８０の部分が、メインメモリに書き込まれる必要がある場合（例えば、ページスワップまたはページアウト動作）、プロセッサとバス（例えば、外部メモリバス）との間の外部データトランザクションは、（例えば、セキュアモードで実行中の暗号化ブロック１７０または暗号化ソフトウェアを使用して）暗号化されてもよい。メインメモリに書き込まれるデータの暗号化（および、復号化）は、セキュア実行コントローラ１６２によって制御されてもよい。

そのような暗号化のためのキーは、セキュアプロセス記述子自体またはそのある派生物であってもよく、そのセキュア記述子自体が、（例えば、標的デバイスの１００秘密キー１０４またはそのある派生物を使用して）暗号化され、メインメモリに書き込まれるデータの一部として、暗号化された形態で、メインメモリ１９０内に記憶されてもよい。

命令キャッシュ１１０は、典型的には、Ｉ−キャッシュとして知られている。いくつかの実施形態では、このＩ−キャッシュ１１０の一部の特性は、特定のブロック内に含まれるデータが、ＣＰＵ実行ユニット１２０によってのみ読み取り可能であることである。言い換えれば、Ｉ−キャッシュ１３０のこの特定のブロックは、任意の実行ソフトウェアによる実行専用であり、任意の実行ソフトウェアによって読み取られることも書込まれることもなくてもよい。また、Ｉ−キャッシュ１３０のこのブロックは、本明細書では、「セキュア化Ｉ−キャッシュ」１３０と呼ばれるであろう。実行されるコードが、このセキュア化Ｉ−キャッシュブロック１３０内に記憶される様式は、別のブロック（描写されされていてもよく、または描写されていなくてもよい）を経由してもよい。当技術分野において知られるように、通常のＩ−キャッシュ１５０を利用して通常実行されるコードを記憶してもよい。

加えて、いくつかの実施形態では、特定のブロックを使用して、セキュアなコードブロックの動作を加速してもよい。故に、ＣＰＵレジスタ１４０の集合は、ＣＰＵ１２０がセキュアなコードを実行中にのみアクセス可能であるように規定され得るか、またはセキュアなコードブロック（セキュアモードで実行するセキュア化Ｉ−キャッシュブロック１３０内の命令）の実行の完了に応じて、あるいは、何らかの理由から、セキュア化Ｉ−キャッシュ１３０内に記憶されるコードの実行中に、非セキュアまたは「通常」のＩ−キャッシュ１５０もしくは他のエリア内に位置するコードの任意のセクションへのジャンプが生じる場合、消去されるように規定されてもよい。

一実施形態において、ＣＰＵ実行ユニット１２０は、どのレジスタ１４０が、セキュア化Ｉ−キャッシュブロック１３０内に記憶されたコードを実行中に、読み取られるか、または書き込まれるかを追跡し、次いで、「セキュア化実行」モードの終了に応じてこれらのレジスタを自動的に消去するかまたはアクセスできなくするように構成されてもよい。これは、２つの種類のコードブロック間で共有が許可されているデータのみが保全されるように、セキュア化コード自体に迅速に「後始末」を行わせる。別の可能性は、セキュア化コードブロック１３０内で実行されるコードの著者が、どのレジスタ１４０が消去または無効化されるべきかを明示的に識別可能であることである。セキュアコードブロックが中断され、次いで、再開される場合、これらの無効化されたレジスタは、潜在的に、再開されているセキュアコードが一時停止された時間の間改竄されていないことが決定され得る場合、再有効化されてもよい。

一実施形態では、セキュアなコードセグメントと非セキュアなコードセグメントとの間のレジスタ１４０内に記憶されたデータの「漏洩」に対処するために、ＣＰＵ１２０がセキュア化コードを実行しているときのみ使用されるレジスタ１４０の集合が、識別され得る。一実施形態では、これは、多くの最新ＣＰＵ設計において実践されるレジスタリネーミングおよびスコアボーディングメカニズムの一種を利用して達成されてもよい。いくつかの実施形態では、セキュア化モードでのコードブロックの実行は、アトミックアクション（すなわち、割込み不可能である）として処理され、それは、このリネーミングおよびスコアボーディングの実装をより容易にし得る。

ＣＰＵ１２０が、「セキュア化」コード（セキュア化Ｉ−キャッシュブロック１３０からのコード）と「非セキュア化コード」（通常のＩ−キャッシュ１５０等の別の位置またはメモリ内の別の位置におけるコード）との混合を実行する可能性はほとんどないように思われ得るが、そのような状況は、割込みルーチン内にジャンプする場合のようなコンテキストを切り替えるプロセスにおいて、または、ＣＰＵ１２０のコンテキストが記憶される場所に応じて、生じ得る（大部分のＣＰＵは、メインメモリ内にコンテキストを記憶し、そこでは、潜在的に、非セキュア化コードブロックによる発見および操作を被る）。

この不測の事態に対する保護を支援するために、一実施形態では、実行中に割り込まれたセキュア化コードブロックの実行の際に得られた結果が、システム内の他の実行スレッドに曝露されることを防止するために利用され得る別の方法は、標的デバイス１００がセキュア化実行モードで動作中、スタックプッシュを無効にすることである。このスタックプッシュの無効化は、セキュア化コードブロックがその通常完了の前に割り込まれる場合、再開不可能であり、したがって、最初から再開されなければならないという点において、セキュア化コードブロックが、このように、割込み不可能であることを意味する。特定の実施形態では、「セキュア化実行」モードが、プロセッサ割込みの際に無効化される場合、セキュア化コードブロックも、潜在的に、呼出チェーン全体が再開されない限り、再開不可能であり得ることに留意されたい。

また、各標的ユニット１００は、１つ以上の秘密キー定数１０４（そのうちのいずれの値も、ソフトウェア読取り不可能である）を有してもよい。一実施形態では、これらのキー（一次秘密キー）の第１のものは、秘密キー集合として体系化されてもよく、そのうちの１つだけが、任意の特定の時間に読み取り可能である。ユニットの「所有権」が変更される（例えば、プロトコルエンジンを含む機器が販売されるか、またはその所有権が、別様に譲渡される）場合、現在アクティブな一次秘密キーは「消去される」か、または異なる値によって上書きされてもよい。この値は、セキュアな様式でユニットに転送されることが可能であるか、またはこの第１のキーが消去されるときにのみ使用されるような様式でユニットに既に記憶され得る。事実上、これは、その所有権が変更されるとき、またはそのような変更のある他の理由が存在する場合（危殆化キー等）、その特定のユニットに対して新しい一次秘密キーを発行することに相当する。二次秘密キーは、標的ユニット１００自体と併用されてもよい。標的ユニット１００のＣＰＵ１２０が、一次秘密キーまたは二次秘密キーのいずれかの値に決してアクセスすることができないため、ある意味、標的ユニット１００は、その独自の秘密キー１０４を「把握」さえしていないことになる。これらのキーは、説明されるように、標的ユニット１００のセキュリティ実行コントローラ１６２内に記憶され、その中で使用されるだけである。

別の実施形態では、２つのキーは、「対の」キーのリストとして構築されてもよく、そのようなキーの一方は、ワンタイムプログラマブルレジスタとして実装され、対の他方のキーは、書き換え可能レジスタを使用して実装される。本実施形態では、書き換え可能レジスタは、既知の値（例えば、ゼロ）に初期化されてもよく、システムが、その状態において、セキュアモードで実行するために利用可能であり得る唯一の選択肢は、レジスタの書き換え可能部分に値を書き込むことであってもよい。いったん、この書き換え可能レジスタ内の値が、ある値（例えば、使用許諾権限によって唯一把握され得るもの）で初期されると、システムは、次いで、セキュアモードにある間、より汎用のコードを実行可能になるだけであり得る。この書き換え可能値がいくつかの理由から再初期化されるべき場合、このレジスタに書き込まれるたびに新しい値を使用することは、潜在的反射攻撃に直面する際、増大したセキュリティを提供し得る。

さらに別のキー集合が、一時的公開／個人キーシステム（非対称キーシステムまたはＰＫＩシステムとしても知られる）の一部として動作してもよい。この対のキーは、実行中に生成され、中央サーバの介入なく、類似ユニット間のセキュアな通信リンクを確立するために使用されてもよい。そのようなシステムのセキュリティは、典型的には、同等のキー長の対称キー暗号化システムより低いため、これらのキーは、前述の秘密キー集合よりサイズが大きくなり得る。これらのキーは、特に、「反射攻撃」に対して防護するために、オンチップタイマブロック内に存在する値と併用されてもよい。これらのキーは、実行中に生成されるので、それらが生成される様式は、全体的システムセキュリティを増大させるために、乱数発生システム１８０に依存し得る。

一実施形態では、特定の標的ユニットの「所有権」の変更に影響を及ぼすために使用可能な方法の１つは、タイムスタンプまたはタイムスタンプ値と呼ばれる別のキー１０７と併せて、一次秘密キーを複合キーとして常に使用することである（このキーの値は、変更され得（言い換えると、異なる時間で異なる値を有し得る）、必ずしも、現在の日時を反映しないことがある）。このタイムスタンプ値自体は、構造上可視であってもよく、またはそうでなくてもよい（例えば、必ずしも秘密キーでなくてもよい）が、それでもなお、標的ユニット１００がセキュア化実行モードで動作していない限り、修正することができない。そのような場合、一次秘密が使用される場合は常に、複合キーの構成要素として、タイムスタンプ値を一貫して使用することは、本質的に、一次秘密キーが別個の値に切り替えられた場合と同一の効果をもたらすことが可能であり、したがって、一次秘密キー自体を修正する必要なく、効果的に、特定の標的終点ユニットの「所有権の変更」を可能にする。

理解され得るように、次いで、標的デバイスは、オリジナルプロセスが終了した後でも、データが任意の他のプロセスにアクセス不可能であるように、セキュア実行コントローラ１６２およびデータキャッシュ１８０を使用して、セキュアモードで実行中のプロセスの作業セットを隔離してもよい。この作業セット隔離は、特定の実施形態では、セキュア化モードで実行しているとき、オフチップ書込およびデータキャッシュのライトスルーを無効化し、実行中のプロセスによって書き込まれたデータキャッシュのラインをセキュア記述子（実行中のプロセスと一意的に関連付けられ得る）と関連付け、セキュアプロセス記述子を使用して、そのプロセスのみにそれらのキャッシュラインへのアクセスを制限することによって、達成されてもよい。そのようなセキュアプロセス記述子は、承認コードまたはその何らかの派生値等の複合キーであってもよい。

プロセスによって、データキャッシュ内のデータにアクセスすることが所望されると、現在実行中のプロセスと関連付けられたセキュア記述子は、要求されたデータキャッシュのラインと関連付けられたセキュア記述子と比較されてもよい。セキュア記述子が整合する場合、そのキャッシュラインのデータは、実行中のプロセスに提供されてもよい一方、セキュア記述子がデータと整合しない場合、提供されなくてもよく、別の措置が、講じられてもよい。

さらに、特定の実施形態では、セキュアプロセスのための作業セットが、オンチップキャッシュからオーバーフローし、セキュアプロセス記述子と関連付けられたそれらのダーティラインを含むキャッシュの部分が、メインメモリに書き込まれる必要がある場合（例えば、ページスワップまたはページアウト動作）、プロセッサとバス（例えば、外部メモリバス）との間の外部データトランザクションが、暗号化されてもよい。そのような暗号化のためのキーは、セキュアプロセス記述子自体またはその何らかの派生物であってもよく、そのセキュアプロセス記述子は、メインメモリに書き出される前に、（例えば、標的デバイスの秘密キーまたはその何らかの派生物を使用して）暗号化されてもよい。再び、この暗号化プロセスは、実質的に、標的デバイスのハッシュブロックを使用して、またはプロセッサ自体またはいくつかの他のオンチップ処理リソース上においてセキュアモードで作動するソフトウェア暗号化プロセスの使用によって、またはハードウェア内に実装される暗号化機能の使用によって、達成されてもよい。

性能を向上させるために、セキュアプロセスが大量の作業セットを有し得るかまたは頻繁に中断される（例えば、多くのページスワップを伴う）特定の場合には、「セキュア」と見なされるプロセス作業セットのサブセットが、作成され（例えば、プロセスのためのダーティキャッシュラインのサブセットのみが、セキュア記述子と関連付けられてもよい）、それが外部メモリに書き出されるとき、それらのキャッシュライン、または、それらのラインを含むキャッシュの部分のみを暗号化してもよい。

加えて、性能を向上させるために、オフチップ記憶メカニズム（例えば、ページスワップモジュール）が、中断プロセスと並行して、（例えば、統合されたＡＥＳ暗号化ハードウェアアクセラレーションを伴うＤＭＡユニットを使用して）非同期的に作動させられることができ、したがって、メインプロセッサ性能に最小限の影響を及ぼすように設計され得る。別の実施形態では、別個のセキュア「作業セットカプセル化」ソフトウェアモジュールが、使用され、作業セットデータがメモリに書き出されることを可能にする前に、暗号化を行なってもよい。

議論のこの時点で、より具体的な例を論じる前に、一般的観点において、一方向複合キーが、どのように構築され得るかの例を示すことが有用となり得る。次に、第１の一方向ハッシュ関数１５１０、その関連付けられた入力データセット１５２０、およびその得られた出力１５２３から成る一般構造である、図１５を参照する。本例では、入力データセット１５２０はさらに、３つの構成要素、すなわち、秘密キー１５２１、前駆体キー１５２２、およびペイロードデータ１ １５２３に分割されることができる。

これらの入力データ要素１５２１、１５２２、および１５２３ならびに得られた出力１５３２（複合キー１と呼ばれる）の名称および形式は、本例では、参照の便宜として、簡単に規定されることに留意されたい。実際、これらの入力データセット要素のいずれかのための形式は、固定されなくてもよい。一方向ハッシュ関数１５１０は、その入力データセット１５２０の構造の知識を有していなくてもよく、入力データ１５２０セットがどれだけ大量でも構わない。

ほとんどの場合、第１の一方向ハッシュ関数１５１０の得られた出力１５３２のサイズは、典型的には、入力データ１５２０セットがどれだけ大量であっても、サイズが一定である。この特徴は、典型的には、任意の一方向ハッシュ関数の組込「データ圧縮」機能性と呼ばれる。組込データ圧縮特性は、以下の例で利用され得るが、本明細書に描写されるシステムの実施形態の全体的構造は、このデータ圧縮機能に依存しない。

依然として、図１５を見ると、一方向ハッシュ関数１５１０の第１のアプリケーションの得られた出力１５３２はまた、次いで、以前に使用された秘密キー１５２１および対応するペイロードデータ２ １５３３と併用され、一方向ハッシュ関数１５４０の第２のアプリケーションのための入力データセット１５３０を形成することができる。実装の容易性のために、第１の一方向ハッシュ関数１５１０および第２の一方向ハッシュ関数１５４０は、実際、動作が同じであってもよいが、異なってもよいことに留意されたい。また、本例では、同一の秘密キー１５２１が第１の一方向ハッシュ関数１５１０および第２の一方向ハッシュ関数１５４０の両方への入力データセットの一部として使用されるが、これらのキーは、異なってもよい。第２の一方向ハッシュ関数１５４０の結果として生じる出力１５５０は、したがって、複合キー２と呼ばれる。

この構造は、第２の一方向ハッシュ関数１５４０の出力１５５０の値をとり、それを第１の一方向ハッシュ関数１５１０の入力データ構造１５２０の前駆体キー位置１５２２に挿入することによって、容易に、無限に拡張され得ることが分かる。同様に、第１の一方向ハッシュ関数１５１０の入力データセット１５２０のペイロードデータ１部分１５２３はまた、異なるペイロードデータセットで置換されてもよい。したがって、この連結された構造は、「キーチェーン化」メカニズムを生成し、それによって、最終結果は、任意の大きさの従属セットを有する単一の固定長の複合キーであり得る。言い換えれば、複合暗号化メカニズムは、チェーン化され、単純な集約を使用して、任意の数の任意の大きさの前駆体に暗号学的に依存する単一の複合キー値の生成を可能にし得る。

さらに、ハッシュ関数の一方向性質により、得られた出力１５３２が与えられた場合、ハッシュ関数を反転すること、すなわち、入力データセット１５２０の値を算出することは、計算上、実行できないことに留意されたい。一方向ハッシュ関数の第２の有用特性は、他の入力データ要素の値および得られた出力値１５３２が全て既知である場合でも、個々の入力データ要素（例えば、１５２１、１５２２または１５２３）のうちの任意の１つを算出することも、計算上、実行できないことである。

前述の「チェーン化」または「カスケード化」一方向複合キー構造と原則的に同様に、論理上の均等な構造が、一方向ハッシュ関数の代わりに、暗号化関数を使用して構築され得ることが分かる。この暗号化関数は、動作原理に影響を及ぼさない対称暗号化関数または非対称暗号化関数であり得る。本例の目的のために、対称暗号化メカニズムに基づく構造を示す。

前述の一方向複合キー例とは対照的に、暗号化チェーンは、特定の中間キー値を再作成するために、順方向入力／出力順序または逆方向入力／出力順序のいずれかで実行されてもよい。この理由から、図１６に示される構造は、「可逆」複合キー構成と呼ばれる。一方向複合キーメカニズム同様に、順方向プロセスまたは逆方向プロセスにおける段階のいずれかで行なわれる特定の暗号化関数は、同一であってもよく、またはそうでなくてもよい。同様に、種々の暗号化段階を通した反復回数も、「チェーン化」可逆複合キーメカニズムの全体的機能性に影響を及ぼさず、無期限に累積することができる。可逆複合キーメカニズムにおける段階のそれぞれがソフトウェア内に実装される場合、「チェーン化」複合キー構造の全体的セキュリティは、中間キーを「チェーン」の一部ではない他のプロセスから秘密（例えば、隔離状態）に保つためのシステムの能力に依存し得ることに留意されたい。実際、そのプロセスが「チェーン」の一部であるかどうかにかかわらず、これらの中間値の少なくともいくつかを任意の他のプロセスから隔離して保つことが望ましくあり得る。そのような隔離メカニズムを可能にする実施形態は、以下に論じられる。

また、一方向キー要素および可逆複合キー要素の両方を含む「ハイブリッド」複合キーメカニズムが構築され得ることに留意されたい。そのような構造の例は、図１７に示される。この種類のメカニズムは、セキュアプロセスのチェーンならびにそれらのセキュアプロセスに供給される入力データのセキュリティを保証するために、有用であり得る。

ここで、図１５に示される複合キー生成の実施形態が、どのようにセキュア化実行コントローラおよびデータキャッシュの実施形態のアーキテクチャにおいて利用され得るかの特定の例について論じることが有用となり得る。図３を参照すると、セキュア実行コントローラのアーキテクチャの一実施形態が、描写される。本実施形態では、セキュア実行コントローラ３６２は、システムのＣＰＵと関連付けられ、システムにおいて、セキュア実行コントローラ３６２は、メインＣＰＵ上においてセキュアモードでの候補コードブロックの作動をサポートするために含まれ、そのように意図される。したがって、セキュア実行コントローラ３６２は、ＣＰＵに可視ではない秘密ハードウェアキー３１０、セキュアモード制御レジスタ３５０、承認コードレジスタ３６０、セキュアモードステータスレジスタ３５２、ハッシュシードレジスタ３１２、およびハードウェア生成複合キーレジスタ３１４を含むレジスタのうちの１つ以上を備えてもよい。これらのレジスタのうち、秘密ハードウェアキー３１０を除いて全て、システムの全体的セキュリティに影響を及ぼさず、ＣＰＵによって読み取られ得るが、これらの他のレジスタのいずれも、可視であってもよく、またはそうでなくてもよい。

セキュアモード制御レジスタ３５０は、標的デバイスをセキュアモードに置くことを試みるために書き込まれ得るレジスタであってもよい。セキュアモード制御レジスタ３５０は、候補コードブロック（例えば、セキュア化モードで実行されるべきコードブロック）の開始アドレスに対応するメモリ位置（例えば、Ｉ−キャッシュまたはメインメモリ内）が書き込まれ得るレジスタと、そのような候補コードブロックの長さが書き込まれ得る別個のレジスタとを有してもよい。承認コードレジスタ３６０は、承認コードあるいは別のタイプのキーまたはデータが書き込まれ得る位置であってもよい。セキュアモードステータスレジスタ３５２は、ハードウェア比較ブロック３４０によってのみ設定され得、かつ標的デバイス１００がセキュアモードで動作しているかどうかを示し得る１つ以上のビットを含むメモリマップされた位置であってもよい。

ハードウェアハッシュ関数ブロック３２０は、ハッシュ関数を実質的にハードウェア内に実装し、複合キー３１４を生成するために動作可能であってもよい。ハードウェアハッシュ関数ブロック３２０は、例えば、ＳＨＡ２５６またはいくつかの類似一方向ハッシュ関数を実装してもよい。しかしながら、このハッシュ関数はまた、前述の仮想ハードウェアハッシュ関数方法論を使用して、システムのＣＰＵと別個のプロセッサ、またはさらにＣＰＵ上においてセキュアモードで作動させられるプロセスのいずれかの上で作動するソフトウェアまたはファームウェア内に実装されてもよい。

ハードウェアハッシュ関数ブロック３２０は、ハッシュシードレジスタ３１２、秘密ハードウェアキー３１０、または別の位置からのデータ内に記憶された値のうちの１つ以上を入力としてとり、これらの入力を連結し（例えば、ある入力を別の入力にプリペンドまたはアペンドする）、結果として生じるデータセットをハッシュし、一方向複合キーとして前述で参照されたメッセージ認証コードを生成してもよい。

特定の実施形態では、ほぼあらゆる数値が、ハードウェアハッシュ関数ブロック３２０のための入力（前駆体）として提供されることができる。簡単に図６を参照すると、例えば、ハードウェアハッシュ関数５１０のための入力データは、秘密ハードウェアキー５１４、ハッシュシード前駆体キー５１６、およびセキュアコードブロック候補５３２の連結によって構築されてもよい。入力データ５１４、５１６、および５３２が何を表すものであっても、またはこれらのデータセットのいずれかがどのような大きさであっても、ハッシュ関数５１０の動作に基本的差異は存在しない。また、ここでは、セキュアモードコントローラ状態機械５８０から生じるように示されるハードウェアハッシュ関数５１０への他の入力は、ハッシュ関数への入力データとは対照的に、制御入力を表すことに留意されたい。

ここで、図７を簡単に参照すると、図６に示されたものと同一の構造が、描写されるが、この場合、ハッシュ関数の結果として生じる出力５２４が、ここでは示される。この値５２４は、典型的には、現代の暗号法の文献では、メッセージ認証コード（または、ＭＡＣ）と呼ばれ、この結果５２４はまた、本明細書では、複合キー（例えば、ハードウェア生成）とも呼ばれている。（ほぼ全ての）セキュア一方向ハッシュメカニズムの固有の圧縮機能により、結果として生じる複合キー５２４は、使用された入力データセットの大きさにかかわらず、またはハッシュ関数５１０を通してデータが反復された回数にかかわらず、サイズが一定となる。

ここで、図３に戻ると、ハードウェア生成複合キーレジスタ３１４は、ハードウェアハッシュ関数ブロック３２０の出力を記憶するように構成される。ハードウェア比較ブロック３４０は、ハードウェア生成複合キーレジスタ３１４内のデータを承認コードレジスタ３６０内のデータと比較するように構成されてもよい。２つの値が同じ場合、ハードウェア比較ブロック３４０は、標的デバイスをセキュアモードに置く１つ以上のビットをセキュアモードステータスレジスタ３５２内に設定するように構成される。

セキュアモードコントローラ状態機械３７０は、セキュアモード制御レジスタ３５０またはセキュアモードステータスレジスタ３５２のビットの状態に基づいて動作し得る、論理（例えば、ハードウェア、ソフトウェア、またはいくつかの組み合わせ）であってもよい。セキュアモードコントローラ状態機械３７０は、前駆体が正しい様式で利用されてハードウェアハッシュ関数ブロック３２０の所望の出力３１４を生成し得るように、ハードウェアハッシュ関数ブロック３２０への入力を制御するために構成される。例えば、セキュアモードコントローラ状態機械３７０は、適切な時間に、結果として生じる出力をハードウェア生成複合キーレジスタ３１４にロードさせるように構成されてもよい。加えて、セキュアモードコントローラ状態機械３７０は、正しいデータをセキュアモードステータスレジスタ３５２に書き込ませるように構成されてもよい。

セキュアモードコントローラ状態機械３７０はまた、標的デバイスがセキュアモードで実行しているとき、メモリアクセスを制御するために構成されてもよい。一実施形態では、セキュアモードステータスレジスタ３５２内のビットが、標的デバイスが現在セキュアモードで動作していることを示すと、セキュアモードコントローラ状態機械３７０は、データキャッシュのどのページがそのプロセスに割り当てられているかを決定し、そのプロセスのためのセキュア記述子をデータキャッシュのページのうちの１つ以上と関連するデータキャッシュ内に記憶するように構成されてもよい。したがって、これらのセキュアプロセス記述子は、データキャッシュ内に記憶されている特定のセットのデータと、セキュア化モードで実行している特定のプロセスとを関連付けるために使用されてもよい。そのようなセキュアプロセス記述子は、例えば、承認コードレジスタ３６０またはハードウェア生成複合キーレジスタ３１４内に位置するデータに基づく値であってもよい。

加えて、標的デバイスをセキュアモードに置くセキュアモードステータスレジスタ３５２内のビットが設定されると、セキュアモードコントローラ状態機械３７０は、セキュアモードで実行しているプロセスによるメモリアクセスを受信することができ、メモリアクセスが、読取アクセスであるか書込アクセスであるかを決定することができてもよい。

データアクセスが、書込動作から成る場合、セキュアモードコントローラ状態機械３７０は、データが書き込まれるべきアドレスに対応するデータキャッシュのキャッシュラインを決定し、次いで、そのキャッシュライン内に含まれるデータがセキュアであることを示すために、そのキャッシュラインと関連付けられたセキュアフラグを設定するように構成されてもよい。特定の実施形態では、セキュアモードコントローラ状態機械３７０はまた、例えば、標的デバイスのデータキャッシュまたはメモリコントローラのライトスルー、ライトバック、または他の動作を無効化することによって、データキャッシュ内にない任意のメモリ位置へのいかなる書込も防止するように構成される。

アクセスが、読取アクセスである場合、セキュアモードコントローラ状態機械３７０は、キャッシュミスが生じたかどうかと、要求されたアドレスがデータキャッシュ内に以前に記憶されていなかったかどうかを決定するように構成されてもよい。セキュアモードコントローラ状態機械３７０は、要求されるデータがメインメモリから読み取られて、プロセスと関連付けられたページのデータキャッシュ内に置かれることを可能にするように構成されてもよい。キャッシュヒットが生じる場合、セキュアモードコントローラ状態機械３７０は、メモリアクセスのアドレスに対応するキャッシュラインを決定し、そのキャッシュラインと関連付けられたセキュリティフラグをチェックすることにより、それが設定されているかどうかを決定するように構成されてもよい。セキュリティフラグが設定されていない場合、メモリアクセスは、続行することを可能にされてもよい（例えば、データがキャッシュラインから読み取られる）。

代替として、データが読み取られるべきアドレスに対応するデータキャッシュ内のキャッシュラインと関連付けられたセキュアフラグが設定される場合、セキュアモードコントローラ状態機械３７０は、そのキャッシュラインを含むデータキャッシュ内のページと関連付けられたセキュアプロセス記述子を取得し、それを現在実行中のものと関連付けらたセキュアプロセス記述子と比較するように構成されてもよい。セキュアプロセス記述子が整合する場合、メモリアクセスは、続行することを可能にされてもよい。セキュア記述子が整合しない場合、メモリアクセスに応答して、不要データまたはプリセット値を返すこと、または代替として、ＣＰＵへのそのアドレスメッセージにおいて「無効データ」を返すことのいずれかのような別の措置が、講じられてもよく、それに応じて、ＣＰＵメモリ管理ユニットは、次いで、置換キャッシュラインにシステムメモリから読み取ることを要求してもよい。

一実施形態では、データキャッシュのみが、セキュアモードで実行しているプロセスの作業セット全体を記憶するために使用され、プロセスによるデータキャッシュ以外のメモリへのいかなる書込も、無効化されてもよい。加えて、セキュアモードにある間に書き込まれるデータキャッシュ（例えば、いわゆる「ダーティ」キャッシュライン）のいかなるラインも、どのプロセスがどの「ダーティ」キャッシュラインに属するかを一意的かつ正確に規定し得るセキュアプロセス記述子と関連付けられる。これらのキャッシュラインへのアクセスは、オリジナルプロセスが終了した後でも、セキュアプロセスの動作の間に修正されたいかなるキャッシュラインも任意の他のプロセスによって読取不可能であるように、特定の「ダーティ」キャッシュラインの所有者のみに許可されてもよい。したがって、プロセスのあるインスタンスに属するデータは、任意の他のプロセスから明確に隔離される。

ここで、図４Ａおよび図４Ｂに移ると、本明細書に提示されるような特定の実施形態による、プロセスの作業セットの隔離をもたらすために利用され得るデータキャッシュのアーキテクチャの一実施形態が、描写される。最初に、図４Ａを参照すると、データキャッシュ４００は、所望されるほぼあらゆる管理または書込ポリシーと併せて実装され得る、Ｌ１キャッシュ、Ｌ２キャッシュ、ダイレクトマップキャッシュ、２ウェイセットアソシアティブキャッシュ、４ウェイセットアソシアティブ、２ウェイスキュードアソシアティブキャッシュ等を含む、ほぼあらゆるタイプのキャッシュであってもよい。キャッシュ４００は、一式のページ４１０を備えてもよい。本明細書のキャッシュを参照して使用されるとき、ページは、キャッシュブロックまたはキャッシュセットを意味すると理解され得る。データキャッシュ４００は、キャッシュの１つ以上のページ４１０と関連付けられたセキュア記述子を記憶するように構成される。

図４Ｂは、キャッシュ４００のページ４１０ａの一実施形態の図を描写する。ここでは、キャッシュは、論理４１２を備え、論理４１２は、ページ４１０ａと関連してセキュアプロセス記述子を記憶し、ページ４１０ａのためのセキュアプロセス記述子の要求に応答して、またはページ４１０ａのキャッシュライン４０２への読取と併せて、セキュアプロセス記述子を提供するように設計される。ページ４１０ａの各キャッシュライン４０２は、データ、アドレスタグ、およびフラグ４２０のためのビットを含む。フラグ４２０は、有効ビットまたはダーティビット等のビットを含んでもよい。加えて、フラグ４２０は、セキュアビット４２２を含んでもよい。キャッシュ４００は、キャッシュライン４０２のためのセキュアビット４２２が設定され得るように構成されてもよい（例えば、セキュアモードで実行しているプロセスが、そのキャッシュライン４０２に書き込むとき）。

ここで、そのような標的デバイスの実施形態が、どのようにセキュア化モードに置かれ得るかを説明することが有用である。再び、特定の実施形態のさらなる理解は、２００９年１１月１０日出願の米国特許出願第１２／６１５，８４３号「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｎｔｒｏｌ ｏｆ Ｃｏｄｅ ｅｘｅｃｕｔｉｏｎ ｏｎ ａ Ｇｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｃｏｍｐｕｔｉｎｇ Ｄｅｖｉｃｅ ａｎｄ Ｃｏｎｔｒｏｌ ｏｆ Ｃｏｄｅ Ｅｘｅｃｕｔｉｏｎ ｉｎ ａｎ Ｒｅｃｕｒｓｉｖｅ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ」の検討から得られ得、その主題は、本願の図１８〜図３６に関して説明される。

一実施形態では、コードの任意の一般的（または、別様の）ブロック（「セキュアワーク関数」と呼ばれる）が本明細書に説明されるもの等のシステムの実施形態上においてセキュアモードで実行され得る手順は、セキュアワーク関数の両側に１つずつ（例えば、前または後）、一対の余剰関数を実行することであることに留意されたい。セキュアワーク関数の直前で実行される関数（または、関数のセット）は、「プロローグ」と呼ばれ、セキュアワーク関数の直後に実行される関数（または、関数のセット）は、「エピローグと呼ばれる」。

したがって、一実施形態では、ＣＰＵ上でセキュアワーク関数を実行するために、次いで、そのセキュアワーク関数は、プロローグによって先行され、その後、エピローグが続くはずである。特定の実施形態では、プロローグの目的は、少なくとも３部から成る。第１に、プロローグは、セキュアワーク関数による使用のために、セキュアワーク関数に送られる入力引数を準備するはずである。この準備は、例えば、平文ではセキュアワーク関数に送られなくてもよいそれらの入力引数のために要求され得る復号化プロセスを伴ってもよい。プロローグの第２の機能は、複合キーを構築することであり得、その復号キーの値は、いくつかのデータ要素に依存する。そのようなデータ要素は、標的デバイスのハードウェア秘密キー、親（例えば、呼出）関数の承認コード、セキュアワーク関数への１つ以上の入力引数のリスト（暗号化された形態または非暗号化された形態のいずれかにおける）、セキュアワーク関数自体の実行可能イメージ、またはセキュアワーク関数が標的デバイス上においてセキュアモードで実行されることが可能であるかどうかを決定する際に使用され得るいくつかの他の情報を含んでもよい。プロローグの第３の機能は、ＣＰＵが、セキュアワーク関数をセキュアモードで実行することを開始する要求を始動することであり得る。

エピローグの目的は、セキュアワーク関数の実行が完了した後の「クリーンアップ」であり得る。エピローグの機能の１つは、セキュアであるかどうかにかかわらず、後続コードブロック（例えば、セキュアワーク関数後に実行されるべき）によって使用するための任意の指定された出力パラメータを準備することであり得る。例えば、この準備は、そのような出力引数の意図された受信者（ハードウェアベースまたはソフトウェアベースのいずれかの観察者を含む）以外の任意の観察プロセスがそのデータを事実上傍受することを阻止され得るように、セキュアワーク関数からの指定される出力（または、返されたデータ）の暗号化を伴ってもよい。そのような場合、使用され得る暗号化キーは、その呼出引数の１つとして、セキュアルーチンに送られる可逆複合キーであってもよい。

エピローグの第２の機能は、プログラム的または自動的のいずれかにおいて、セキュアワーク関数が実行中に（例えば、セキュアワーク関数によって）書き込まれたデータキャッシュのそれらの部分を無効にし得ることである。したがって、セキュアワーク関数が、その動作を一時停止させられ、次いで、再開させられ得る場合、プロセスが一時停止される前に、データキャッシュのセキュア部分に書き込まれたデータ値は、例えば、これらのセキュアなデータ位置からメモリにページングする必要なく、再開されたセキュアプロセスに利用可能となり得る（介入暗号化プロセスを伴ってもよい）。次いで、いったん、セキュア機能が再開されると、セキュアプロセス記述子が、現在実行中の承認コードまたはその何らかの派生物（または、セキュアプロセス記述子として使用される別の値）と整合するため、これらの同一のデータキャッシュ位置は、次いで、セキュア機能に利用可能になり得る。

しかしながら、いったん、セキュアプロセスが終了すると（例えば、エピローグ関数を使用して）、これらの同一のセキュアデータキャッシュ位置は、エピローグ関数の間に無効としてマークされてもよい。この無効化プロセスは、依然として、データキャッシュのセキュア部分内に存在し得るデータのいかなる意図されない潜在的「漏出」も、セキュアワーク関数が適切に終了した後にアクセスされないように防止する。

このように、セキュアワーク関数が繰り返される場合でも、連続して２回、同一のセキュアプロセス記述子が与えられる場合、このセキュアワーク関数の第２の反復は、両反復に対して同一のセキュアプロセス記述子を有し得るという事実にもかかわらず、それでもなお、その同一のセキュアワーク関数の第１の反復から作業セットデータにアクセス不可能となる。プロローグおよびエピローグの説明は、一例として提供されるものであって、より多いまたはより少ない機能が、プロローグまたはエピローグによって達成されてもよく、加えて、これらの機能（または、付加的またはより少ない機能）は、説明されるような実施形態の範囲から逸脱することなく、別の様式で達成されてもよいことに留意されたい。

図５〜図７は、標的デバイスをセキュアモードに置くためのフローの一実施形態のブロック図を描写する。最初に、図５を参照すると、最初、コードブロック５３１は、セキュア化モードで実行するように構成されてもよい。そのようなコードブロックは、例えば、コンテンツ配信システムから受信されるか、またはコンピュータ読み取り可能な媒体等からロードされてもよい。加えて、承認コードが、例えば、使用許諾権限から受信され、コンピュータ読み取り可能な媒体から読み取られ、ユーザ等によって入力されてもよい。コードブロック（セキュアモードで実行する「候補」であるため、本明細書のいくつかの場所では、候補コードブロックと呼ばれる）および承認コード５２０は両方とも、標的デバイスのメインメモリ５３０内に記憶されてもよい。

本実施形態では、候補コードブロックは、プロローグ関数、セキュアワーク関数、およびエピローグ関数を、その順番で含むことに留意されたい。そのような実施形態では、次いで、セキュアワーク関数と関連付けられるであろう、承認コードは、候補コードブロックの全３つの関数セクションへの依存性を含んでもよい。しかしながら、いくつかの実施形態では、プロローグ関数およびエピローグ関数は、実質的に、固定様式で（言い換えれば、ハードウェアまたはファームウェア内に）実装されてもよい。その場合、候補コードブロックのための承認コードは、プロローグ関数およびエピローグ関数へのより限定された依存性を有し得ることが可能である。

故に、候補コードブロック５１０が、Ｉ−キャッシュ５４０にロードされ、ＣＰＵ実行ユニット５５０によって実行され始めると、ＣＰＵ実行ユニット５５０は、セキュア実行コントローラ５７０のセキュアモード制御レジスタ５６０にアクセスし、セキュアモード制御レジスタ５６０のビットを設定することにより、標的デバイスをセキュアモードに置くことを開始してもよい。加えて、候補コードブロック５３１のメモリ位置（例えば、コードブロック５３１が転送されるＩ−キャッシュ位置またはメインメモリ５３０内の位置）は、候補コードブロック５３１の長さとともに、セキュアモード制御レジスタ５６０に書き込まれてもよい。セキュアモード制御レジスタ５６０内のビットの設定に基づいて、セキュアモードコントローラ状態機械５８０は、１つ以上の機能を行なってもよい。

図６に移ると、セキュアモードコントローラ状態機械５８０は、次いで、候補コードブロック５３１が、セキュア実行コントローラ５７０のハードウェアハッシュブロック５１０に提供されるように、標的デバイスを構成してもよい。この構成は、例えば、セキュアモード制御レジスタ５６０に書き込まれる候補コードブロックのメモリ内の位置に基づいて、行なわれてもよい。

一実施形態では、セキュアモードコントローラ状態機械５８０は、候補コードブロックをＩ−キャッシュ５４０に明示的にロードするために、メインメモリ５３０に進み、候補コードブロック５３１をフェッチしてもよい。別の実施形態では、セキュアモードコントローラ状態機械５８０は、標的デバイスのいくつかの他の部分が、候補コードブロック５３１をメインメモリ５３０からＩ−キャッシュ５４０にロードする場合に、データバストランザクションを観察し、候補コードブロック５１０が全体としてＩ−キャッシュ５４０にロードされたことを確認してもよい。

別の実施形態では、セキュアモードコントローラ状態機械５８０は、標的デバイスの別の部分に、このメインメモリ５３０からＩ−キャッシュ５４０への転送を行わせてもよい。さらに別の実施形態では、セキュアモードコントローラ状態機械５８０は、メインメモリ５３０から転送されるデータを観察し、Ｉ−キャッシュ５４０に転送される場合に、データを追跡してもよい。

一実施形態では、候補コードブロック５３１を含むビットは、メインメモリ５３０からＩ−キャッシュ５４０へバスを横断して転送される場合に、ハードウェアハッシュ関数ブロック５１０に提供されてもよい。受信された候補コードブロック５３１を使用して、ハードウェアハッシュブロック５１２は、候補コードブロック５３１、秘密ハードウェアキー５１４、および、必要に応じて、ハッシュシードレジスタ５１６内に記憶された１つ以上の他の前駆体値から、複合キーを作成してもよい。

図７を参照すると、ある時点で、候補コードブロックのセキュア実行を開始するために、ＣＰＵ実行ユニットは、候補コードブロック５３１と関連付けられた承認コード５２０をセキュア実行コントローラ５７０の承認コードレジスタ５２２に書き込んでもよい。複合キーが、ハードウェアハッシュブロック５１２によって生成されると、ハードウェア生成複合キーレジスタ５２４に書き込まれる。セキュアモードコントローラ状態機械５８０は、次いで、ハードウェア生成複合キーレジスタ５２４内の値と承認コードレジスタ５２２内の値との間の比較を開始するように構成される。これらの値が整合する場合、ハードウェア比較ブロック５３２は、標的デバイスをセキュアモードに置くビットをセキュアモードステータスレジスタ５３４に書き込んでもよい。コードブロック５１０は、次いで、ＣＰＵ実行ユニット５５０によって、セキュア化モードで実行されることができる。値が整合しない場合、標的デバイスは、セキュアモードに置かれないが、しかしながら、コードブロック５１０は、依然として、（セキュア化モードではないが）実行することが可能にされてもよい（または、そうでなくてもよい）。

理解され得るように、次いで、セキュア化モードでのコードの実行は、提供される承認コードの使用を通して制御されることができる。この承認コードは、標的デバイスに配信され、かつ（例えば、その標的デバイスの秘密キーを使用して）各標的デバイスと結び付けられる候補コードブロックに暗号学的に依存する複合キー（ＤＳ）であってもよい。

故に、候補コードブロックを特定の標的デバイス上においてセキュアモードで作動可能にするために、正しい承認コード（例えば、候補コードブロックおよび標的デバイスの秘密キーの両方を使用して構築される）が、提供されなければならない。他の標的デバイスは、その承認コードを用いて、候補コードブロックを正しく作動することができず、他の複合キーは、その標的デバイス上において、その候補コードブロックと作用しない。

その結果、標的デバイスの秘密キーは、標的デバイスがセキュアモードで実行しているときに（または、例えば、標的デバイスがセキュア化モードに置かれるべきかどうかを決定するときのような特定の他の事例において）のみ、アクセスされることができるため、循環依存に類似する依存性が、もたらされる。最初にデバイスの秘密キーを保有するあるエンティティ（例えば、使用許諾権限）のみが、複合キーを生成し、特定のコードブロックがその標的デバイス上においてセキュアモードで作動することを可能にすることができる。したがって、エンティティは、そのキーにアクセスするためのコード片を承認し得る前に、デバイスの秘密キーの先験的知識を必要としてもよい。エンティティが、秘密キーの正しい値へのアクセスを有していない場合、そのコードがセキュアモードで実行することを承認するための有効な複合キーを生成することができない。

さらに、使用許諾権限によって提供される複合キーが元のコードブロックおよび秘密キーを使用して作成されたため、標的デバイス上の候補コードブロックは、デバイスをセキュアモードに置く前に修正または改竄されていないことを保証されることができ、候補コードブロックが何らかの方法で修正された場合、標的デバイスにおいて生成された複合キーが（例えば、使用許諾権限から）受信された複合キーと整合せず、したがって、標的デバイスは、セキュア化モードに置かれない。

この態様で、次いで、標的デバイス上でのハッシュ関数の使用は、候補コードブロックが改竄されていないことを立証し、（例えば、前述の複合キー「チェーン化」方法の使用によって）プロセスの実行の順序を保証し、かつ候補コードブロックが、標的デバイス上においてセキュアモードで作動することが承認されることを認証する。システムの全体的動作セキュリティを維持するために、次いで、一実施形態では、セキュアモードでコードブロックをプロセスとして実行するとき、呼出引数が（不当または別様に）修正されていないこと、プロセスが（例えば、中断を伴って、または伴わずに）完了するまで実行されること、および、プロセスの作業セットが外部観察から隔離されたままであることを保証することがさらに所望される。

一実施形態では、これらの３つの所望の第１のもの（呼出引数が修正されていないことを保証すること）は、呼出引数（または、その適切なサブセット）が、ハッシュ関数によってセキュア化されるべき候補コードブロックの残りとともに含まれる場合、達成可能である。この概念は、候補コードブロックのコンテンツの実施形態に関して前述されている。

残りの２つの所望（それぞれ、完了までの実行および作業セット隔離と呼ばれる）もまた、特定の実施形態では、本明細書に説明される複合キーまたは再帰的実行構成要素を使用して、対処されることができる。前述のように、完了までの実行を保証する実施形態は、２００９年１１月１０日出願の米国特許出願第１２／６１５，８４３号「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｎｔｒｏｌ ｏｆ Ｃｏｄｅ ｅｘｅｃｕｔｉｏｎ ｏｎ ａ Ｇｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｃｏｍｐｕｔｉｎｇ Ｄｅｖｉｃｅ ａｎｄ Ｃｏｎｔｒｏｌ ｏｆ Ｃｏｄｅ Ｅｘｅｃｕｔｉｏｎ ｉｎ ａｎ Ｒｅｃｕｒｓｉｖｅ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ」に開示および議論されており、その主題は、本願の図１８〜図３６に関して説明される。

次いで、作業セット隔離に目を向けると、セキュアモードでのプロセスの実行中に修正または生成された任意のデータ（可能性として返された引数以外）が、オリジナルプロセスが終了した後でも、任意の他のプロセスによって、読取不可能のままであることが所望され得る。別の閉鎖されているセキュリティシステムを攻撃するためのいくつかの周知のサイドチャネルまたは間接方法が存在するため（そのうち、タイミング攻撃および差分電力解析（ＤＰＡ）は、そのような広く実践されているより強力な方式のうちのいくつかである）、作業セット隔離は、プロセスをセキュアモードで実行しているときに使用されるシステムメモリ（例えば、データキャッシュまたはメインメモリ）のいずれも外部観察から隔離されることを単に保証することよりも複雑であり得る。

作業セット隔離を保証するために、次いで、特定の実施形態では、標的デバイスが、セキュア化モードで実行しているとき（例えば、標的デバイスをセキュアモードに置くために使用されるセキュアモードステータスレジスタのビットが設定されるとき）、プロセッサのデータキャッシュは、現在実行中のセキュアコードセグメントの作業セット全体を記憶するために使用されてもよく、プロセスによるメモリの任意の他の部分への書込は、許可されなくてもよく、データキャッシュのラインのライトスルーまたはライトバック（または、データキャッシュとメインメモリとの間の任意の他のタイプのメモリ同期）もまた、許可されなくてもよい。加えて、セキュアモードにある間、セキュアプロセスによって書き込まれるデータキャッシュの任意のラインは、そのデータキャッシュラインが属するプロセスを一意的かつ正確に規定する一意のセキュアプロセス記述子とタグ付けされてもよい。それらのデータキャッシュライン（または、ページ）へのアクセスは、次いで、そのセキュア記述子と関連付けられたプロセスのみに制限されてもよい。

故に、特定の実施形態では、セキュアプロセス記述子は、異なるコードブロックからの異なるプロセス間を区別するだけではなく、異なる時間に同一のコードブロックを実行することから生じる異なるプロセス間を区別することも可能であるように十分に一意的である。故に、セキュア記述子は、複合キーであり得る。本明細書で論じられる前述の例と同様に、複合キーメカニズムは、標的デバイスの秘密キーを危殆化せずに、このセキュア記述子を生成するために利用されることができる。そのような場合、付加的利点は、前述の既存のハードウェアベースのハッシュブロックおよびハードウェア比較ブロックが、外部攻撃者にいかなる中間データも暴露せずに、これらのセキュアプロセス記述子を作成または比較するために使用されることができることである。

実際、一実施形態では、利用され得る単純かつ効果的なセキュアプロセス記述子は、セキュア化モードで実行されているコードブロックと関連付けられ、かつそれを認証するために使用される承認コードである。セキュアプロセス記述子の他の例を作成するために利用され得る例示的前駆体は、例えば、標的デバイスの秘密キー、セキュアモードで実行しているコードブロックのメッセージダイジェスト（例えば、承認コード）、親プロセス（例えば、現在実行中のプロセスの呼出関数）のセキュアプロセス記述子、または現在実行中のプロセスの呼出引数である。

当然ながら、多くの他の可能性として考えられる組み合わせが、この複合キーベースのセキュアプロセス記述子のための前駆体値として使用され得、それは、地理的位置または時刻等の変数を含む。そのような一式の変数に基づいて、セキュアプロセスのアクセス可能性をその独自の作業セットにさえ動的に制限する能力は、システム全体の全体的動作に著しい影響を及ぼし得る。この種類の外部データ依存性を伴う、コードのセキュアブロックに関する機能的含意は、計り知れず、この能力は、単純かつ高度に効率的なメカニズムにおいて、セキュア化モードで実行する任意のコードブロックに追加されることができる。単なる例として、セキュアコードブロックは、それを実行中である標的デバイスが、２０１４年３月１９日の２：００ＰＭから２：２５ＰＭ（ＥＳＴ）までの間で、Ｍａｎｈａｔｔａｎのミッドタウン内の特定の３ブロックエリア内に位置するときのみ、正しい結果を生成するように作成され得る。

また、特定の実施形態では、セキュアコードブロックが完了の前に中断される場合、その作業セットは、いかなる他のセキュアコードブロック（潜在的に、それ自体を呼び出す場合でも）によってもアクセスされることができないことに留意されたい。セキュアコードセグメントの結果（および、結果のみ）をその親に返す能力に関して、セキュアコードブロックから返される値（単数または複数）は、前述のように、同様に制限されたアクセスを有し得る。この場合、子ルーチンのリターン引数のためのセキュアプロセス記述子キャッシュタグは、親ルーチンのセキュアプロセス記述子（それ自体が、同様に「セキュア化」様式において「子」ルーチンに送られる引数であり得る）に基づく。一方向複合キー構成または可逆複合キー構成のいずれかを使用することによって、親プロセスおよび子プロセスの間で送られる特定の引数が、「読取専用」データタイプとして定義されるかまたは「読取／書込」データタイプとして定義されるかの選択が行われることができる。いったん、子プロセスのセキュアワーク関数が終了すると、「ダーティ」キャッシュライン（例えば、子プロセスのセキュアワーク関数によってそれらに書き込まれたデータを含むもの）は、エピローグ関数によって無効化され、したがって、セキュアまたは別様の任意のプロセスアクセスされることが不可能となってもよい。実際、いったん、セキュアな子プロセスが終了すると、通常、適切に構築されたエピローグ関数によって、これらのデータは、論理的に「蒸発」する。なぜなら、これらのデータは、いかなるプロセスによっても（最初にそれらに書き込まれた同一のプロセスでも）、もはや読み取られることができないからである。影響を受けたキャッシュラインは、明示的に消去される必要はなく、単に、もはやアクセス可能ではなくなり、すなわち、このデータへのアクセスを拒否するための高度に効果的かつ効率的な手段であることに留意されたい。

また、いったん、セキュアプロセスが、終了すると、その最終作用は、潜在的に、暗号化された形態において、特定の返された結果を親ルーチンに戻すことである。この場合、使用される暗号化キーは、呼出（親）ルーチンのセキュアプロセス記述子に基づく。セキュアな子プロセスが、この最終作用の前に終了される場合、返される値は、親ルーチンによってアクセスされることが不可能である。この特定のメカニズムは、部分的結果が、セキュアまたは別様の任意の他のプロセスによってアクセスされることさえ防止する。この作業セット隔離メカニズムは、例えば、「セキュア」なメモリバンクおよび「非セキュア」なメモリバンクへの単純アドレス空間分岐よりはるかにセキュアでありかつはるかに粒度の細かいことが容易に分かる。また、この機能性は、最小限のオーバーヘッドを伴って実装されることができる。

したがって、複合暗号化および限定的認証メカニズムに基づいて、セキュアコードセグメントの作業セットからの「漏出」を防止する方法だけではなく、効率的かつセキュアに、親コードセグメントとその「子」との間で結果をやりとりするための方法も、説明される。当然ながら、このメカニズムは、種々の方法で実装されることができるが、この特定の実装は、最小限のシリコンエリア影響を伴って、アーキテクチャ上の依存性が完全になく、かつ事実上、全体的性能に全く損失を伴わずに、任意の既存のＣＰＵアーキテクチャに非常に容易に統合される。

ここで、セキュア化モードで実行するプロセスの作業セットをセキュア化する一実施形態のフローを図示することが有用となるであろう。本実施形態を図示するために、注意が、図８〜図１４に向けられる。最初に、図８を参照すると、前述の議論から、コードブロックが認証されると、コードブロックのための承認コードが、セキュア実行コントローラ８２０の承認コードレジスタ８１２内に置かれ、かつコードブロックが認証されると、標的デバイスをセキュアモードに置くセキュアモードステータスレジスタ８１０内のビットが、設定され、コードブロック８５２が、ＣＰＵ実行ユニット８５０上においてセキュア化モードで実行されることを思い出されたい。このコードブロック８５２の実行中、次いで、アドレスへのメモリアクセスが、行われてもよい。そのようなメモリアクセスは、セキュアモードコントローラ状態機械８８０によって受信されてもよい。メモリアクセスは、いくつかの方法で、例えば、標的デバイスのメモリコントローラから、システムバスの「スヌープ」から、変換索引バッファまたは他のキャッシュ管理デバイスから、または種々の他の様式において、受信されてもよいことに留意されたい。

セキュアモードコントローラ状態機械８８０が、そのようなメモリアクセスを受信すると、メモリアクセスが読取アクセスであるか書込アクセスであるかを決定してもよく（ステップ８０３）、メモリアクセスが読取アクセスであると決定される場合、メモリアクセスに対応するアドレスがデータキャッシュ８４０内に以前に記憶されたかどうかが決定され得る（ステップ８０５）。この決定は、例えば、キャッシュヒットが生じたかまたはキャッシュミスが生じたかに基づいて行われてもよい。再び、このデータは、いくつかの方法（例えば、メモリコントローラから、変換索引バッファから、または他のアドレス分解メカニズム等）において、取得されてもよい。

図９に移ると、メモリアクセスが、データキャッシュ８４０内に以前に置かれていないアドレス（例えば、キャッシュミス）に対するものである場合、読取が、可能にされてもよい（ステップ８０７）。所望のアドレスにおけるデータは、次いで、メインメモリ８９０から読み取られ、現在実行中のプロセスによって使用されるページ８４２のデータキャッシュ８４０内のライン８４６に置かれることができる。描写される例に図示されるように、要求されたアドレスと関連付けられたデータは、メインメモリ８９０から読み取られ、ページ８４２ａのキャッシュライン８４６ａ内に置かれる。

図１０を参照すると、メモリアクセスが書き込まれる場合（ステップ８０３）、書込が、データキャッシュ８４０内に位置するアドレスに対するものであるかどうかを決定されることができる（ステップ８１３）。アドレスが、データキャッシュ８４０内にない場合、書込は、許可されなくてもよく（ステップ８１５）、または、書込が許可され得るが、データキャッシュのみへの書込である（例えば、いかなるデータキャッシュライトスルー選択肢も、無効化され得る）。ここで、図１１を参照すると、書込が、データキャッシュ８４０内に位置するアドレスに対するものである場合（ステップ８１３）、書込は、そのキャッシュライン８４６を含むページ８４２内の適切なキャッシュライン８４６に対して許可されてもよい。本例の目的のために、メモリアクセスは、ページ８４２ａのキャッシュライン８４６ａ内のデータへの書込であると仮定する。セキュアモードコントローラ状態機械８８０はまた、書き込まれたキャッシュライン８４６のセキュリティビットを設定してもよい（ステップ８１７）（図示される例では、ページ８４２ａのキャッシュライン８４６ａのセキュリティビット８４８ａが設定されている）。

図１２に移ると、書込が、データキャッシュ８４０内に位置するアドレスに対するものである場合（ステップ８１３）、実行中のプロセスと関連付けられたセキュアプロセス記述子が生成され（ステップ８１９）、書込が行われたキャッシュライン８４６を含むページ８４２と関連して、データキャッシュ８４０内に記憶され得る（ステップ８２１）場合が決定されることができる。これらのステップは、そのようなセキュアプロセス記述子が、ページと以前に関連付けられていない場合のみ生じ得ることに留意されたい（ステップ８２３）。

一実施形態では、実行中のプロセスのためのセキュア記述子は、現在のプロセスによって実行されているコードブロックを認証するために使用される承認コードであってもよい。この承認コードは、セキュア実行コントローラ８２０の承認コードレジスタ８１２内に存在してもよい。したがって、承認コードレジスタ８１２内の承認コードは、書込が行われたキャッシュライン８４６を含むページ８４２と関連付けられたデータキャッシュ８４０のセキュア記述子エリア８４４内に記憶されてもよい。図示される例では、承認コードレジスタ８１２内の承認コードは、キャッシュライン８４６ａを含むページ８４２ａと関連付けられたセキュア記述子エリア８４４ａ内に記憶される。

図１３を参照すると、セキュアモードコントローラ状態機械によって受信されるメモリアクセスが、読取（ステップ８０３）であり、データキャッシュ８４０内に以前に記憶されたデータの読取である場合（ステップ８０５）（例えば、キャッシュヒット）、アクセスされているキャッシュライン８４６と関連付けられたセキュアにビット８４８が設定されているかどうかを決定されることができる（ステップ８２３）。セキュアにビットが設定されていない場合（ステップ８２３）、データキャッシュ８４０からの読取が、許可されてもよい（ステップ８２５）。

図１４に移ると、アクセスされているキャッシュライン８４６と関連付けられたセキュアにビット８４８が設定されている場合（ステップ８２３）、アクセスされているキャッシュライン８４６のページ８４２と関連付けられたセキュアプロセス記述子が、アクセスされたキャッシュライン８４６を含むページ８４２と関連付けられたセキュアプロセス記述子エリア８４４から取得されてもよい（ステップ８２５）。プロセスと関連付けられたセキュアプロセス記述子が、次いで、取得されることができ（ステップ８２７）、次いで、これらのセキュア記述子が同一であるかどうかを決定されることができる（ステップ８２９）。

論じられるように、実行中のプロセスのためのセキュアプロセス記述子は、セキュア実行コントローラ８２０の承認コードレジスタ８１２内に存在する承認コードまたはその何らかの派生値のいずれかであってもよい。したがって、アクセスされたキャッシュライン８４６を含むページ８４２と関連付けられたセキュアプロセス記述子エリア８４４から取得されるセキュアプロセス記述子は、セキュア実行コントローラ８２０のハードウェア比較ブロック８１４に提供されてもよく、そこで、承認コードレジスタ８１２内に存在する承認コードまたはその何らかの派生値のいずれかと比較される。図示される例では、キャッシュライン８４６ａを含むページ８４２ａと関連付けられたセキュアプロセス記述子エリア８４４ａ内のセキュアプロセス記述子は、ハードウェア比較ブロック８１４に提供され、そこで、承認コードレジスタ８１２内に存在する承認コードまたはその何らかの派生値のいずれかと比較される。セキュアプロセス記述子が整合する場合、読取は、許可されてもよく（ステップ８３１）、そうでなければ、許可されず（ステップ８３３）、別の措置が講じられてもよい。そのような他の措置の例は、キャッシュミス等を示す不要データまたは固定値を提供してもよい。

実施形態は、前述のように、セキュアモードで実行するプロセスのためのセキュアプロセス記述子として、承認コードの使用と併せて図示されたが、（例えば、標的の秘密キーを使用して）ほぼあらゆる所望の前駆体から生成されるほぼあらゆるタイプの複合キーが、使用されてもよい。そのような場合、例えば、セキュア実行コントローラ８２０のハードウェアハッシュブロックを含む、セキュア実行コントローラの他のブロックは、そのようなセキュアプロセス記述子の生成または比較に関与してもよい。

特定の場合には、データキャッシュ外の書込が無効化され得る間、セキュアプロセスの作業セットは、データキャッシュからオーバーフローし得る。一実施形態では、ＣＰＵ実行ユニットと外部メモリバスとの間の任意の外部データトランザクションは、セキュアプロセス（例えば、ページアウト動作または同様のものを含む）の実行中、暗号化されてもよい。そのような暗号化プロセスのために、セキュアプロセス記述子自体またはその何らかの派生値が、キーとして使用されてもよく、そのセキュアプロセス記述子または派生値は、それ自体が、（例えば、標的デバイスの秘密キーの派生値を使用して）暗号化され、データセットの一部として、メインメモリ内に記憶されてもよい。利点として、このメカニズムを実装するために要求される有意なアーキテクチャ上の変更は、実質的になくてもよい。最も重要な含意は、セキュアプロセスが大量の作業セットを有し、頻繁に中断される場合の性能に関するものである。そのような実施形態では、「セキュア」と見なされるプロセスの作業セットのサブセットが、作成され、その「セキュア」な作業セットに対応するキャッシュのその部分のみが、メインメモリに書き出されるときに暗号化されてもよい。

しかしながら、セキュリティが最重要懸念であり、セキュアコードブロックの作業セットが大量であり得るシステムでは、作業セット全体が、メモリバス上に置かれる時点の前に、暗号化されてもよい。そのような場合、メインメモリへの記憶は、別のプロセス（例えば、統合されたハードウェアアクセラレーション暗号化を伴うＤＭＡユニット）と並行して、非同期的に作動されてもよく、したがって、性能に最小限の影響を及ぼすように設計され得る。いくつかの実施形態では、別個の「作業セットカプセル化」ルーチン（それ自体が、セキュアモードで実行されるように設計されたセキュアコードブロックであってもよい）が、作業セットデータがメインメモリに書き出されることを可能にする前に、暗号化を行うために使用されてもよい。再び、該当する場合、最小限のアーキテクチャ変更が、このメカニズムをほとんどのあらゆる既存のＣＰＵに統合するために要求され得る。

いくつかの実施形態では、メインメモリに記憶されている、ページまたはキャッシュラインの暗号化を行うために使用されるキーは、承認コードの派生物であってもよい。具体的には、一実施形態では、セキュアモードで実行しているプロセス（そのページがメインメモリ内に記憶されている）のための承認コードは、デバイスおよび別の前駆体の秘密キーを使用するハードウェアハッシュブロックを使用して、複合キー（例えば、メッセージ認証コード）を生成するために使用されてもよい。結果として生じる複合キーは、それ自体が、承認コードを暗号化することにより、一過性のキーを生成するために使用されてもよい。この一過性のキーは、メインメモリ内に記憶されるべきデータキャッシュのページを暗号化するために使用されてもよく、それは、次いで、複合キーを生成するために使用される承認コードおよび前駆体を用いて、メインメモリ内に記憶される。

ほぼあらゆる対称暗号化メカニズムが、メインメモリに記憶されているページを暗号化するために、利用されてもよい。例えば、ハードウェア暗号化ブロック（例えば、ＡＥＳハードウェアブロック）が、利用されてもよい。加えて、この暗号化は、セキュアモードで作動している暗号化コードによって達成されてもよい。そのような場合、この暗号化コードは、セキュア化モードで実行された別のプロセスと関連付けられたデータキャッシュのキャッシュラインまたはページ（例えば、暗号化されるべきキャッシュ内のデータ）にアクセスする必要があり得る。それらのキャッシュラインの暗号化をもたらすために、そのような暗号化プロセスによるこのアクセスを可能にするため、一実施形態では、暗号化プロセスは、その暗号化キーとして呼出引数の派生物を使用してもよい。そのような派生物は、例えば、前述のように、親ルーチンまたは子ルーチンのセキュアプロセス記述子等の秘密キーおよびいくつかの他のデータとともに、呼出引数を使用することによって生成され得たハードウェアハッシュの出力（例えば、メッセージ認証コード）であってもよい。したがって、暗号化プロセスによってデータを暗号化または復号化するために使用される実際のキーは、キー内に送られた派生物であるが、単一のセキュアプロセスによってのみ正しく生成される得るものであってもよい。暗号化されたページは、次いで、入力／出力引数トランザクションに直接関与するものを除き、セキュアプロセスの入力引数または出力引数のいずれも任意の他の（セキュアまたは別様の）プロセスに暴露することなく、メインメモリに記憶されてもよい。

ここで、デジタルセキュリティの特定の側面を論じることが有用であり得る。デジタルセキュリティアルゴリズムにおける公開技術の現状は、オンライン情報の閲読を通して、またはこの主題を検討する種々の刊行物および特許を介して、容易に得られ得、その最近のもののいくつかとして、米国特許第６，３２７，６５２号、米国特許第６，１９３０，６７０号、米国特許第６，４１２，０７０号、米国特許第公報第２００２００１３７７２号、米国特許第６，２２６，７４２号、米国特許第６，１０１，６０５号、および、Ｄａｖｉｄ Ｌｉｅらによる「Ａｒｃｈｉｔｅｃｔｕｒａｌ Ｓｕｐｐｏｒｔ ｆｏｒ Ｃｏｐｙ ａｎｄ Ｔａｍｐｅｒ−Ｒｅｓｉｓｔａｎｔ Ｓｏｆｔｗａｒｅ」（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ９ｔｈ Ａｎｎｕａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ａｒｃｈｉｔｅｃｔｕｒａｌ Ｓｕｐｐｏｒｔ ｆｏｒ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅｓ ａｎｄ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ ａｋａ ＡＳＰＬＯＳ−ＩＸ， Ｃａｍｂｒｉｄｇｅ， ＭＡ． ２０００）が挙げられ、その全てが、参照することによって、本明細書に完全に組み込まれる。

先行技術システムは、デジタルデータ暗号化および復号化技術のいくつかの基本的動作カテゴリを利用する。これらのカテゴリは、セキュリティアルゴリズム自体の使用に基づいており、実際のデータを暗号化または復号化するための実際のメカニズムから独立する。これらの公知の技術および広く説明される分類および技術は、以下の通りである。
一方向ハッシュメカニズムおよび／またはメッセージダイジェスト。
メッセージ認証システム。
デジタル署名。
秘密キー暗号化システム。
公開キー暗号化システム。

これらの技術が所与のセキュリティシステムにおいて使用される手段は、セキュリティプロトコルとして知られている。セキュリティプロトコルは、種々の機能がどのように実装されるかの実際の基礎メカニズムから独立することに留意されたい。したがって、完璧にセキュアな暗号化アルゴリズムでも、潜在的に、暗号化技術自体のセキュアな側面を打破するような方法において、全体的セキュリティを危殆化するセキュリティプロトコルの内側で使用され得る。その結果、任意の所与のセキュリティシステムの全体的セキュリティは、基礎セキュリティ技術の相対的強度だけではなく、これらのセキュリティ技術が使用される方法にも依存する。セキュリティシステムを実装する際の以前の試みは、保護されるべき種々のタイプのビットストリーム間で（人工的）区別を行っていた。基礎レベルでは、全てのバイナリデジタルデータは、１および０のストリーム（ビットストリーム）に変形されることができ、これは、意図された目的またはそのビットストリームの解釈から完全に独立する様式において、記憶され、読み出されることができる。任意の特定のビットストリーム内に含まれるデータが、１つのテキストまたは写真、あるいは、１つの実行可能なオブジェクトコードまでもを伝送するために使用されるという事実は、ビットストリームが記憶される様式またはその位置に関連しない。

したがって、デジタルデータタイプ間の任意の区別に依存しないセキュリティプロトコルの必要性が存在する。産業標準的なセキュリティ技術および他のタイプのセキュリティ規格を利用することにより、より良好かつより効率的にデジタルコンテンツを保護し得るこれらのプロトコルは、それ自体が、デジタルビットストリームの観点で表されてもよい。したがって、そのようなプロトコルは、それ自体を同等にセキュア化可能である。この自己参照挙動は、「再帰」特性として知られ、そのようなセキュリティプロトコルは、「再帰的セキュリティプロトコル」と呼ばれ得る。

ここで、デジタルコンテンツを保護することを目的とする、セキュリティプロトコル用のシステムおよび方法に注意を向ける。これらのセキュリティプロトコルは、任意のデジタルコンテンツに使用可能であり、また、実際のデジタルコンテンツが改変されることを必要とせずに従来の透かし方式に通常は関連付けられる、同一性追跡の概念を支援することもできる。これらのプロトコルは、全てのデジタルビットストリームが平等であるという前提に基づくため、プロトコル自体の更新へのアクセスを制御するために、再帰的様式で使用することさえできる。言い換えれば、データが保護されるメディアストリームであろうと、それらのストリームを再生する必要がある実行可能コードであろうと、それらのストリームを再生する必要がある暗号化された実行可能コードであろうと、それらのストリームを再生する必要がある暗号化されたコードを復号化する必要がある、実行可能コードであろうと、暗号復号化コードとともに使用されるキー等であろうと、プロトコルは、デジタルデータの種類を区別しない。これらのデータのデジタル性質のみが、プロトコルにとって重要なものである。したがって、デジタルデータの性質および／または使用は、セキュリティプロトコルには関係ないため、プロトコルは、自らを保護することが可能である。

この能力は、実行中でさえも、それが作動しているハードウェアの変更を必要とせずに、（例えば、最近発見されたセキュリティホールを修繕するように）セキュリティプロトコルを更新できることを意味する。「古いほうの」セキュリティシステムは、新しいほうのセキュリティシステムの一部として「包含される」（すなわち、システム全体の新しく、潜在的により安全なレベルの保護を追加するために、古い保護「包装物」を決して剥がさなくてもよい）。したがって、システム全体は、最新で最も安全な暗号化および／またはアクセス制御システムにカプセル化される。新しいキーが追加されてもよいだけではなく、既存のシステムの最上部にも同様に、完全に新しいセキュリティおよび／または暗号化アルゴリズムを追加することができる。

この融通性は、プロトコルが、時間限定レンタル、ペイパービュー、多重バージョニング、機械依存性ライセンス取消、あるユーザから別のユーザへの所有権の永久譲渡を含む、多数のビジネスモデルを支援できるようにする。

著作権のあるソフトウェアアプリケーションが例示的実施形態で利用されるものの、ビデオ、音声データ、ソース、およびオブジェクトコードを含む、あらゆるビットストリームにセキュリティを提供するために、同じ方法およびシステムを使用できることが、当業者によって理解される。

セキュリティプロトコルの実施形態が提供するように設計される基本機能は、以下を含む（しかし、それらに限定されない）。
公正使用（「タイムシフト」、「スペースシフト」、およびアーカイブバックアップ）
増分アップグレード
所有権の一時譲渡
所有権の永久譲渡
時間限定アクセス
使用限定アクセス（使用される回数）
デバイス特有のライセンス取消
データまたはストリーム特有のライセンス取消。

多くのセキュリティシステムに対して、著作権のある作品に含まれる知的財産の保護のための一次メカニズムのうちの１つは、単純なアクセス制御である。しかしながら、そのようなメカニズムが回避された場合、最も精巧なアクセス制御メカニズムによって与えられる保護さえ、少ししか価値がない。これは、アクセス制御が役に立たないメカニズムであると言うことではなく、それ自体では全セキュリティシステムではないと言うことである。多数の著作権のあるメディアストリームがインターネット上で公共消費に自由に利用可能であるという事実は、そのようなセキュリティシステムをほとんど常に回避できるという事実の証拠である。この種類のアクセス制御はまた、原本が破壊される危険がある場合に必要な、合法的に購入された著作権のある作品のバックアップコピーを作製するメカニズムを確立することをより困難にする。したがって、本明細書で説明されるセキュリティプロトコルは、有用にするために、いかなる種類のアクセス制御システムも必要としない。

説明されるセキュリティプロトコルは、作品自体を構成するデジタルデータではなく、著作権のある作品の表現を制御することに専念する。そのようなものとして、プロトコルは、著作権のある作品、またはその作品がどのように解釈されるかを説明するために使用される他のデジタルデータをカプセル化するために使用される、デジタルデータを区別しない。結果として、プロトコルは、他のセキュリティプロトコルをカプセル化するためにさえ使用することができる。

（基本的動作説明：）
セキュリティプロトコルの実施形態は、それらのコードが、そのアルゴリズムをコピーあるいは不正流用しようとする者による分解から保護されるという高い信頼度を、１つのソフトウェアの作者が有することを可能にするように設計される。それらはまた、その機能性を改変しようと試みる者による修正からこのコードを保護するようにも設計される。他の汎用コンピューティングシステムにおいてこれらの主要な特性を実装することができる方法のうちの１つを、以下の項で論議する。これら２つの主要機能の副産物として発生する、付加的財産は、ソフトウェアを作動させることができる条件（すなわち、いつ、どのように、およびどの１つまたは複数の機械上で、コードが実行されることが可能となるか）を制御する能力である。これらの機能のうちの第１は、システムに改ざん防止タイマ要素を追加することによって達成されてもよい。他は、問題のブロックコードを実行するために満たされなければならない、所望の条件を示すために使用される、安全なデータ構造を実装する手段によって達成される。このデータ構造はハードウェア特有ではないため、種々の方法で使用することができ、それを解釈するために使用されるソフトウェアを更新することによって修正されることが可能である。より効率的にプロトコルを実装するために利用される、ハードウェア特有の特徴を論議し、プロトコルを支援するために、これらの特徴をどのように使用できるかという例を挙げる。最後に、著作権のある作品を保護するためにプロトコルをどのように使用できるかを示す。

セキュリティプロトコルの実施形態は、その意図された受信者によって復号化されることのみを可能にするような方法で、デジタルビットストリームを暗号化する能力に依存する。これは、よく理解された問題であり、多数の業界標準暗号化アルゴリズムの基礎である。しかしながら、プロトコルのコアが典型的なオンチップ命令キャッシュ（Ｉ−キャッシュ）の（比較的）小さい範囲内に適合できれば役立つという事実、および半自律的方式で作動することが可能であるという事実といった、セキュリティプロトコルの実施形態とともに使用するために考慮されるべき２つの付加的な要因がある。言い換えれば、プロトコルが小さく、通常の日常動作に中央セキュリティサーバの使用を必要としなければ、有用である。

（ハードウェア：）
このセキュリティプロトコルを実行することが可能なデバイスの一例の全体的なブロック図を上述の図２に示す。

（動作詳細：）
セキュリティプロトコルの実施形態が動作する方式は、システム初期化、安全なコード生成および大量配布、安全なコードローディングおよび実行、キーリストデータ構造の構成、一時ライセンス譲渡、永久ライセンス譲渡、システム所有権譲渡、ライセンス取消、およびセキュリティシステム更新といった、いくつかの異なる工程に分類することができる。これらのそれぞれを順に論議する。しかしながら、下記の例は、論議を簡素にする目的で選択され、必ずしもこのプロトコルを実装することができる最も効率的な方式ではない（または唯一の方式でもない）ことに留意されたい。

（システム初期化）
これは、標的ユニットの秘密キー１０４が何らかの初期値に設定されるステップである。この手順は、２つの秘密キーのうちのいずれかに対するいくつかの場所のうちの１つで達成することができるが、ロジスティックな理由によって、シリアル番号または秘密キーのいずれかが変更される可能性があり得るのは、組立工程の最後のステップとなるべきである。ユニット１００のシリアル番号がオフチップで記憶される場合、この手順は、最終組立の時点で行われる可能性が最も高い。ユニットのシリアル番号１０６がオンチップに記憶される場合、チップ製造工程の最後の時点で（すなわち、チップが包装された後）この手順を実行することが最も実用的となるため、生産後またはバーンイン副産物には、機能しない部分を選別する機会がある。こうして、安全に保たれなければならないデータの量が最小化される。プロトコル全体のセキュリティは、ユニットの秘密キー１０４のセキュリティに基づいてもよいため、初期化手順は、物理的セキュリティが可能な時点で着手されるべきである。

一次秘密キーは、二次秘密キーを供給するために使用されるものとは異なる手順で初期化される（またはデバイスに「焼き付けられる」）べきである。実践では、この二次キーは何らかの時点で知られるが（製造工程の何らかの時点でユニットにプログラムされるため）、一旦、それが標的デバイス１００上に記憶されると、それが関連付けられるユニットはどこにも記録されるべきではない。監査目的で、（配布の無作為性を試験するため、または何らかの他の理由で）どの部分がどのキーを保持するのかを知っていることとは無関係に、全１組の二次秘密キー値が検査されることが潜在的に望ましてくもよい。しかしながら、システムの安全な性質を維持するために、この二次秘密キーをユニットにプログラムするデバイスは、二次秘密キーを第１の秘密キーまたは標的デバイスのシリアル番号１０６のいずれかに関連付ける手段を決して持たないことが望ましい。また、これらの秘密キーの両方は、以降で説明する理由により、改ざん防止方式で実装されるべきである。これらの２つの秘密キーがどの順番で初期化されるかは重要ではない。例示的な実施形態で説明される初期化手順後、標的デバイスのシリアル番号１０６およびそれらの関連一次秘密キーが共同して位置する唯一の場所（実際のチップ上以外）は、使用許諾権限における安全なサーバ上にあるべきである。

（安全なコード生成および大量配布）
図２１を簡単に参照すると、一例のシナリオにおいて、合理的に分解の心配がなく、特定のデバイス上でのみ実行することができる、このプロトコルの下で作動するようにアプリケーションを生産することを開発者２１２０が希望すると仮定する。各登録された開発者２１２０は、使用許諾権限のサーバと通信するために、および開発者によって発行されたあらゆる公開されたコードブロックまたは他のビットストリームを認証するために使用することができる署名されたメッセージ認証コードまたはＭＡＣ（典型的には、デジタル署名と呼ばれる）を作成するために使用する、あらゆるメッセージを認証するために使用される公開キー／プライベートキーペアを有する。

アプリケーションは、デバッグされた後、本来の開発者のみに知られているアプリケーション特有の暗号化アルゴリズムおよびキーを使用して符号化される。このアプリケーション特有のアルゴリズムおよびキーは、非対称（秘密）キーシステムまたは非対称（ＰＫＩ）キーを用いたシステムのいずれかとなり得る。暗号化されたコードのブロックの端には、それらの発行された公開キー／プライベートキーペアのプライベートキー（したがって、暗号化されたコードブロックに対する一義的デジタル署名を形成する）を使用して、開発者２１２０によって署名されるＭＡＣが添付される。デジタル署名または本来のＭＡＣのいずれかおよび対応するコード特有のＩＤ番号は、使用許諾権限に供給されてもよい。アプリケーション開発者２１２０はまた、同様に適切な復号キーを供給することを選択してもよい（この決定のトレードオフを本書の以降の項で論議する）。

アプリケーション特有のアルゴリズムは、非対称暗号化システムである場合、署名されたメッセージ認証コード（デジタル署名）を生成するために使用される同じ発行されたＰＫＩキーペアを使用して、必ずしも暗号化される必要がないことに留意されたい。しかしながら、コードブロックの端において記憶されるＭＡＣは、既知のハッシングアルゴリズムを使用して生成されるべきであり、また、開発者の発行された公開キーのうちの１つを使用して署名されなければならない（したがって、デジタル署名を形成する）。これにより、標的が既知のハッシング関数および既知の公開キーを使用してＭＡＣの真正性を検証できるようにする。

次に、図１８に移ると、全てのアプリケーション特有の暗号化キーデータ構造１８１０は、（暗号復号化キー自体１８２０に加えて）多数の余分なフィールドを含んでもよい。これらのフィールドのうちの１つは、タイムスタンプ１８３０と、関連マスク値１８４０とを備え得る。第２は、「カウントダウン値」１８５０を含み得る。マスク値１８４０は、キーが有効である時を決定するために、他の２つのフィールド１８３０、１８５０と併用される。また、正確にいくつのビットがフィールドのそれぞれに割り付けられるかはプロトコルに関連しないことにも留意されたい。

タイムスタンプ値１８３０は、タイムスタンプマスク１８４０フィールドに記憶されるビットパターンに応じて、いくつかの方法で使用できることに留意されたい。タイムスタンプマスク１８４０値は、標的ユニット１００の現在の時間との比較を行う時に無視される、一部のタイムスタンプ数字を開発者２１２０が選択できるようにする。しかしながら、一例として、タイムスタンプフィールド１８３０によって支援される最小分解能が１秒であると想定する場合、タイムスタンプデータ１８３０の下位５ビットをマスクすることによって、タイムスタンプフィールド１８３０に記憶される時間から始まる、約３２秒の経過にわたって使用される時のみに有効な、特定のキーデータ構造１８１０を生成することができる。セキュリティプロトコルの全体的な機能性は、タイムスタンプフィールド１８３０の最下位ビットの実際の分解能に依存していない。

マスクフィールド１８４０に関連付けられる他のビットがあってもよく、そのいくつかは、タイムスタンプ１８３０で特定された値の前後でキーが有効かどうかを示すために使用することができる。タイムスタンプ１８３０および「カウントダウン」値１８５０がどのように関連付けられるかを示すために、さらに別のマスクフィールド１８４０ビットを使用することができる。例えば、これは、アプリケーション開発者２１２０の意向が、ある日付および時間窓に単純に関係するよりもむしろ、ある日付の前または後のいずれかに、ソフトウェアの使用をある反復回数に限定することであった場合に有用となる。当然ながら、これらの条件の任意の組み合わせを構築することができるため、プロトコルは、この点で極めて融通性がある。加えて、いくつのキーの合法コピーが本来の標的ユニット１００から他者へ同時に配布されてもよいか等、他の特性を示すように、さらなるフラグをこのデータ構造に含むことができる。これは、例えば、デジタルライブラリで見られるような、多重コピーライセンスが所望とされた場合に有用となる。

暗号化工程の一実施形態を表すフロー図を、図１９で見ることができる。デジタルメディアストリームまたはソフトウェアアプリケーション（そのメディアストリームを解釈するために使用される暗号復号化命令等）を配布するために使用される工程に実質的な差異がないことに留意されたい。いずれにしても、オンラインサーバを介するか、または直列化されたディスク（標準ＤＶＤ等）上のいずれかで、暗号化されたコードブロック１９１０、１９２０を配布するためのいくつかの異なるオプションがある。後者の場合、開発者２１２０は、使用許諾権限２１１０により、大量生産されたディスクの個別シリアル番号を事前登録する（またはしない）ことを選択することができる。そうする場合、シリアル番号は、バーストカッティングエリア（ＤＶＤの場合）に焼き付けることによるか、または標準ＣＤの場合はインクジェットインプリンティングによるかのいずれかによって、ディスクに永久的に取り付けられ得る。同じシリアル番号が大量生産されたディスクの全てにおいて複製されるため、開発者２１２０は、ＣＤまたはＤＶＤのデータエリアにこれらのシリアル番号を埋め込むことができないことに留意されたい。ある種の混成形式が使用された場合で、ディスクの一部が大量生産され、別の部分が一度書き込まれ得る場合、これは、個別シリアル番号を伴うディスクを配布する別の潜在的方法となる。どのような場合でも、登録工程中にエラーしにくいため、機械読み取り可能なシリアル番号が確かに好ましい。

開発者２１２０が使用許諾権限によりメディアシリアル番号の使用を登録しないことを選択する場合、適正な暗号化キーをアプリケーションまたはメディアストリームファイルに関連付けることができる、何らかの他の方式があってもよい。したがって、アプリケーション開発者２１２０は、コード特有のＩＤまたは関連メディアシリアル番号のいずれかを登録してもよい。前者の場合、アプリケーションを自由に配布することができる（すなわち、特定の公表フォーマットおよびメディアに関係しない）。

個別シリアル番号メカニズムの場合、使用許諾権限２１１０には、どのアプリケーション（またはメディアストリーム）がどのシリアル番号に関連付けられるかを知る必要（および、潜在的に、その指示）がないために、エンドユーザのプライバシーが維持される。開発者２１２０が、その関連キーとともにアプリケーションＩＤ（またはメディアストリームＩＤ）を登録する場合、使用許諾権限２１１０が、どのアプリケーションまたはメディアストリームが特定のエンドユーザによって「所有」されているかを知ることが可能である。一方で、このプライバシーの潜在的な欠如は、開発者２１２０が物理的メディアを製造して配布することを必要としないという、付加的な利便性および費用節約によって相殺される。「物理的メディア」という用語は、必ずしもディスクを意味しないことに留意されたい。この機能は、個別シリアル番号ステッカーが貼り付けられた、印刷されたマニュアル（または単純な登録フォームさえ）を使用することによって、同様に達成され得る。必要とされるのは、開発者２１２０がエンドユーザに供給される、一意のシリアル番号を有する何らかの対象を生産しなければならないことだけである。このシリアル番号の目的は、ビットストリーム登録番号の役割を果たすことである。このシリアル番号がプロトコルにおいてどのように使用されるかを以下の項で論議する。

図１９に示された例について、暗号化されたソフトウェアアプリケーション（またはメディアストリーム）１９１０および機械依存性の暗号復号化ソフトウェア１９３０の両方は、同じメカニズムを使用して配布される。これが事実となるべきということはプロトコルの要件ではなく、暗号化されたコードブロック１９１０、１９３０のいずれかまたは両方は、オンラインで、またはディスクをプレスすることによって配布することができる。しかしながら、デジタルメディアストリームの場合、メディアストリーム自体が２つのブロック１９１０、１９３０の桁違いに大きい方である可能性が高い。したがって、その場合、大量生産されたディスク形式で、少なくともこのブロックの配布を達成することが最も道理にかなう。多くの場合、随伴の暗号化されたコードブロック（第１のブロックをどのように復号するかという命令を含むもの）ならびに一次の暗号化されたコードブロックに適合するように、そのようなディスク上に十分な余地があってもよい。また、２つのデータセットのいずれもが、発行後に変更を受ける可能性がないため、オンラインで配布されなければならないという基本要件がないことにも留意されたい。そのようなものとして、それらは両方とも、大量生産されたディスクを用いた配布メカニズムによく適している。両方を同じディスク上に有することにより、一義的な様式で一方を他方に関連付けることがより容易となる。

（安全なコードローディングおよび実行）
配布メカニズムが実際のディスクを介して達成される場合、消費者は、従来のソフトウェア購入と正確に同じ方式で、アプリケーションを含むディスクを購入することができる。当然ながら、エンドユーザは、「標的」ユニットのプロセッサ上で修正されていない暗号化されたコードブロックを作動させることができない。ユーザが機械上でアプリケーションを作動させようとすると、ＣＰＵ１２０が、暗号化されたソフトウェアブロックをロードし、問題のコードブロックが真性であることを検証するために、ソフトウェア開発者の公開キーとともにコードブロックの端において保存されたデジタル署名（「署名された」ＭＡＣ）を使用する。これは、他の汎用ＣＰＵ１２０への第１のハードウェア修正が作用し始めてもよい場合である。そのような保護されたコードのブロックをロードして復号化するための工程を図２０に示す。

ハッシング関数が正しく計算されること（および、さらには、生成されたメッセージダイジェストと「本物の」メッセージダイジェストとの間の比較が有効であること）を確認するために、ＣＰＵ１２０は、安全な方式でこのハッシング関数を実行しなければならない。したがって、ハッシング関数は、デコーダのハードウェアによって直接生成されてもよいか、またはハッシング関数自体は、「安全な」コードのブロックを使用して計算されなければならないかのいずれかであり、その動作は、他の「安全ではない」プログラムによって改ざんすることができない。

ソフトウェアを用いたハッシュの場合、この安全なコードのブロックは、ユニット１００のセキュリティシステムの一部と見なされるべきであり、そのようなものとして、ユニット１００と使用許諾権限２１１０との間の安全なトランザクションを介してプレーヤにダウンロードすることしか可能でなくてもよいことに留意されたい。大変興味深いことには、「安全な」ハッシング関数の確立は、本明細書で説明される同じ保護プロトコルを介して達成することができる。セキュリティシステムの前側面に対するこの再帰的挙動は、このプロトコルのソフトウェアを用いたバージョンが、その暗号化／暗号復号化アーキテクチャにおいて極度に融通性（したがって、更新可能）となることを可能にするものである。

メッセージダイジェスト計算がハードウェアに固定される場合、ある程度のセキュリティを潜在的に獲得することができるが、これは融通性を犠牲にして成り立つ。ハッシュ値を生成するために専用ハードウェアブロックが使用される場合、チップが製造された後のある時点でハッシングアルゴリズムの多少の脆弱性が発見され（またはその実装に何らかのバグがある場合に）、そのとき事後に問題に対処する機会がない。これは、処理を加速するために、ソフトウェアを用いたハッシング関数のある種のハードウェアアクセラレーション（プログラム可能なＳ−Ｂｏｘ構造等）を使用できないと言うものではない。しかしながら、その場合、ハードウェアは、理想的には、多種多様の一方向ハッシング関数を支援するように十分に汎用性となるべきである。

しかしながら、このプロトコルのセキュリティは、最終的には、この安全なコードローディング手順の一部として提供される、最下位機能に依存している。下位機能（ハッシング関数で使用される、秘密キーまたは原始的操作等）は、署名されたメッセージダイジェスト等の上位機能性を産生するように、異なる方法で共に組み合わせられる。順に、これらの上位機能ブロックは、同一性確認等の、上位ユーティリティを提供するために使用される。より多くの原始層の最上部に上位機能を構築するこの工程は、「信用の連鎖」を構築するステップとして知られている。システムの融通性は、セキュリティ関連機能をこの階層内でできる限り低く修正することができる点を設置することにある。しかしながら、ある点で、このチェーンが基づく基本原始的操作は、性質がアトミックでなければならない（すなわち、これは、ハードウェアに実装されなければならない最小水準の機能性である）。ハードウェアのデータ塊（ｇｒａｎｕｌａｒｉｔｙ）のこの点の正確な選択は、大部分が実装詳細であり、このプロトコルの全体的動作は、上記の条件を考慮すると、この側面に依存していない。

一旦暗号化されたコードブロック１９１０が標的のメモリ空間１１０にロードされ、メッセージダイジェストが計算されると、結果は、そのとき開発者の公開キーによって、暗号化されたコード１９１０とともに記憶されたデジタル署名１９４０を復号化することによって計算されるメッセージダイジェストと比較される。２つが一致する場合、標的ユニット１００は、暗号化されたコードブロック１９１０が真性である（または、少なくとも、公開キーがデジタル署名を復号化するために使用された開発者２１２０によってコードが配布された）と確信することができる。

この時点で、標的１００は、最近検証された、暗号化されたコードブロックと協調して使用される、暗号復号化キーのコピーを要求する使用許諾権限２１１０への安全なメッセージを送信する。使用許諾権限との安全な接続を設定するステップの一部として、標的ユニット１００は、一時公開／プライベートキーペア（その公開部分は使用許諾権限２１１０サーバに供給される）を生成する。キー交換手順の詳細は、周知であり、これが達成される正確なメカニズムを本論議で詳細に述べる必要はない。どのような場合でも、標的ユニット１００と使用許諾権限２１１０における中央サーバとの間の全体的なネットワークトラフィックは、いくつかのキー転送、コード特有のＩＤ、およびそれとともに記憶されたＭＡＣから成るため、適度に小さなデータセットに限定されることに留意されたい。

コード特有のＩＤ２６０は使用許諾権限２１１０が認識するものであると想定すると、アプリケーションの作者がすでに使用許諾権限２１１０に要求された暗号復号化キーの「暗号化されていない」コピーを提供しているか否かに応じて、２つの可能な行動方針があってもよい。開発者２１２０が使用許諾権限２１１０にそのような情報を提供していない場合、中央サーバは、アプリケーション開発者のサーバに標的デバイスの一時公開キーのコピー（ならびに、問題のコード特有のＩＤ２６０）を伝送する。その時点で、開発者のサーバは、要求暗号復号化キー（標的の一時公開キーで暗号化される）を含むメッセージ、および適正に復号化されたコードから生成されるメッセージダイジェストで、使用許諾権限２１１０サーバに応答する。こうして、標的デバイス１００のみがメッセージを復号化してアプリケーション特有の暗号復号化キーを得ることができ、使用許諾権限２１１０は、暗号化されていない形の暗号復号化キーにアクセスできない。

メッセージダイジェストは、事前計算し、使用許諾権限のサーバ上に記憶することができるが、それがトランザクション中に開発者２１２０によって提供されてもよいという事実は、万一ハッシング関数（メッセージダイジェストを生成するために使用される）が変化する場合に潜在的に役立つ。万一このことが起こった場合、開発者２１２０は、標的デバイス１００との実際のトランザクションの前または後のいずれかにおいて、復号化されたコードのメッセージダイジェストの更新されたバージョンを使用許諾権限２１１０に提供する必要がある。使用許諾権限２１１０は、本来の（復号化された）コードに決してアクセスするべきではないため、開発者２１２０は、この情報を提供しなければならない。前述のように、使用許諾権限のサーバと開発者のサーバとの間のネットワークトラフィックの量は、依然として極めて少ない。次いで、開発者２１２０から受信された暗号化されたキーは、使用許諾権限２１１０から標的への伝送の前に、標的デバイスの一次秘密キーでさらにもう一度暗号化される。この第２の暗号化は、他のトランザクションの一部として、開発者の側で実際に実行され得るが、その場合、開発者は、潜在的に、（両方のキーが何らかの方法で組み合わせられない限り）標的ユニットの一次キーへのアクセスを有し、それは、エンドユーザの潜在的なプライバシーの欠如の問題を提示する。

アプリケーション開発者２１２０が使用許諾権限２１１０と標的デバイス１００との間のトランザクションのために「ループ外」でいることを希望する場合、単純に、暗号化されていない（非暗号化）形の関連暗号復号化キーのコピー、および復号化されたコードブロックに対する関連ＭＡＣ（その値はハッシングアルゴリズムが変更される度に更新されなければならない）を使用許諾権限２１１０に提供することができる。したがって、使用許諾権限２１１０における中央サーバは、自律的に作用することが可能となり、標的ユニット１００からのキー要求を遂行するために、開発者のサーバへの通信リンクを確立する必要はない。しかしながら、これは、使用許諾権限によって意図的または非意図的のいずれかで万一「暗号化されていないキー」情報が損なわれた場合、開発者にとって潜在的なセキュリティの危険を提示する。

全体のキー暗号化／復号化プロセスのフロー図が、図２１に概説される。この場合、暗号化されていないキーは、標的デバイスの一時公開キーによる（上記のような）伝送、および再度、標的の一次秘密キーによる伝送の両方の前に、依然として暗号化される。この時点で、標的デバイス１００は、二重に暗号化された形式における適正な暗号復号化キーを有する。使用許諾権限２１１０が暗号化されていないアプリケーション特有のキー２１５０情報にアクセスしない場合、各ユニット１００に対する秘密キーは、使用許諾権限２１１０のみに知られるべきであり、伝送のためのプライベートキーは、標的１００のみによって知られるため、意図された標的デバイス１００以外の誰もが、暗号化されていない形でこのキーデータを複製できることが可能となるべきでない。

しかしながら、この時点で、標的１００がアプリケーション開発者２１２０から受信する符号化された暗号復号化キーは、まだ、標的１００において誰にでも見られる状態で安全に記憶する（例えば、フラッシュＲＯＭに記憶する、またはハードドライブ上にバックアップする）ことができない。問題は、標的デバイス１００が、使用許諾権限２１１０から伝送された、符号化された暗号復号化キーとともに、一時プライベートキーのコピーも記憶しなければならないことである。使用許諾権限２１１０における誰かが、何らかの手段によってこれら２つのデータへのアクセスを獲得した場合には、（標的デバイス１００の一次秘密キーへのアクセスも同様に有する場合があると考えれば）復号化されたアプリケーション特有のキー２１５０を再構築することが潜在的に可能となる。

これは、標的デバイスの二次秘密キーが使用され始める時点である。二次秘密キーは、標的ユニットの復号化ユニット以外の誰にでも知られていないことを思い出されたい。したがって、使用許諾権限から標的１００に供給されたキーを復号化するために、いったん一時プライベートキーが使用されると、その使用（および／または保管）前にアプリケーション特有のキーを再暗号化するために、二次秘密キーが使用される。

次いで、標的は、コードブロック（またはメディアストリーム）を復号化するために、アプリケーション特有の（暗号化されていない）キー２１５０を使用することができる。したがって、アプリケーションコードが暗号化されていない形で存在する、２つだけの場所は、元の開発者２１２０自身、および標的デバイスのＩ−キャッシュ１１０の「保護された」部分の内側にある（そこでは実行することしかできず、暗号化されていない形でメモリに再び書き出すことは決してできない）。これは、ユーザと使用許諾権限２１１０との間のプライバシーを可能にする。言い換えれば、使用許諾権限２１１０は、ユーザがライセンスを有するものが何なのか（大きなプライバシーの問題点）を知らなくてもよいが、ユニット１００が損傷される、または盗まれる、あるいは動作不能にされる場合に、ユーザのキーリストに対する保存場所（またはバックアップ）の役割を果たすことが依然として可能である。

暗号復号化工程が正しく行われたことを検証するチェックとして、適正に復号化されたコードのメッセージダイジェストは、元の開発者２１２０から使用許諾権限２１１０を通して標的ユニット１００へと転送された、デジタル署名を復号化することによって生成されるメッセージダイジェストと比較される。前述のように、このデジタル署名は、アプリケーション開発者のプライベートキーで、暗号化されていないコードブロックのメッセージダイジェストを暗号化することによって作成される。代替として、このデジタル署名はまた、接続が確立された時に使用許諾権限２１１０に供給された、別の一時公開キー２１３０を使用して、再度、開発者２１２０によって暗号化することもできる。どのような場合でも、正しいメッセージダイジェストは、開発者の公開キーでデジタル署名を復号化することによって、標的デバイス１００によって復号することができる。このメッセージダイジェスト復号化されたコードブロックのＭＡＣに一致する場合、コードは真性であると見なされ、標的１００上で作動することが可能になる。次いで、このメッセージダイジェストは、再暗号化されたアプリケーション特有のキー２１５０とともに保管するために、標的ユニットの二次キー２１４０で再暗号化されてもよい。

この手順の最終ステップは、アプリケーション特有のキー２１６０の（標的デバイスの二次キー２１４０で）新しく暗号化されたバージョンが、保管目的で使用許諾権限２１１０サーバに再伝送されることである。この再伝送は、いくつかの目的を果たす。第１に、標的デバイス１００がコードブロックを適正に復号化できたという確認である。第２に、エンドユーザがある種の壊滅的なデータ不具合を被り、アクセスキーの自らのバックアップコピーを作製することを怠っていた場合に対処するために、使用許諾権限２１１０が、この暗号化されたキー２１６０のコピーを有する必要がある。次いで、使用許諾権限２１１０は、任意の特定のユーザに対するバックアップ記憶設備としての役割を果たすことができる。この手段のさらに別の理由は、特定の標的デバイス１００の所有権が１人のユーザから別のユーザへ変化する場合、または標的デバイス１００をアップグレードすることを希望する場合に対処するためである。この種類の所有権の永久譲渡は、そのユニット１００に対する許諾されたアプリケーションキーの全ての移譲を伴うことができる（その場合、新しい所有者の名前の下でユニットを登録する以外に、何も行われる必要はない）。しかしながら、ユーザが第１のデバイスから第２のデバイスへキーデータの永久所有権を譲渡することを希望する場合、これは、使用許諾権限２１１０と標的デバイスの両方との間の安全なトランザクションを用いて達成されてもよい。

標的デバイス１００が使用許諾権限２１１０サーバに返送する他の情報は、標的デバイスの新しく更新されたキーリストデータ構造２２１０（図２２に描写される）のメッセージダイジェストである。これは、新しく更新されたキーリストデータ２２１０構造の確認であるとともに、使用許諾権限２１１０サーバ上および標的デバイス１００上の特定の標的デバイス１００に関連付けられるキーリストデータ構造２２１０の等価性を検証するためにも使用される。このデータ構造の正確な構成を、以下の項に説明する。また、特定のキーまたは１組のキーの所有権の永久譲渡が達成される方法を以降の項で論議する。

この時点で、上記で概説される工程は、開発者２１２０から標的デバイス１００にアプリケーション特有のキー２１５０を譲渡するためにプロトコルを使用することができる、唯一の方式ではないことに留意されたい。例えば、実際のキー譲渡トランザクションは、標的１００とアプリケーション開発者２１２０との間でのみ、直接接続を伴うことができる。しかしながら、その場合、接続は、トランザクションにデバイス特有の暗号化情報を寄与するために、開発者のサーバと使用許諾権限のサーバとの間で確立されなければならない。安全な態様でこのプロトコルを動作させることができる多数のメカニズムがあり、上記で議論される例は、これらのうちの１つにすぎない。しかしながら、共通することは、標的１００に譲渡されるキーデータが、その標的デバイス１００のみに使用可能であることを確実にするために、３つ全ての関係者が協働しなければならないことである。

キーの構造は、ハードウェア特有の部分ならびにアプリケーション特有の部分といった、２つの断片を有するように設定できることに留意されたい。これら２つの断片が完全に分離不可能であることは要件ではない。分離不可能であるならば、先に議論されたとおりの特性を得る。しかしながら、キー断片を独立して動作可能にする方法がある場合、包括的な１組のコピーを有効にし、実際のコードまたは実際の標的デバイス１００とは無関係となり得る制限を使用することができる。言い換えれば、いずれの開発者２１２０も、配布の制限がないが、読み取ることができず、実行することしかできない、アプリケーションまたはメディアストリームを発行することができる。これは、使用許諾権限２１１０が、製造業者とは無関係に、全てのデバイス上で作動するセキュリティシステム更新を送信したい場合に、有用となり得る。これの別の例は、そのストリームの著作権の制御を依然として維持しながら、公的に利用可能なメディアストリームを放送することである。同様に、発行者は、誰もが読み取る、および／またはコピーすることができるが、１つの特定の標的デバイス１００または１組のデバイス上のみで実行するアプリケーションを配布することができる。これは、例えば、「この特定の部類のデバイスを更新する」というメッセージを送信するために有用となり得る。別の可能なアプリケーションは、どこにおいても作動し、配布に制限がないアプリケーションを送信することである。これは、特定のアプリケーションに対するソースコード（すなわち、オープンソース配布形態）を発行するステップと性質が同様である。分離可能なＨ／Ｗ特有およびＳ／Ｗ特有のキー構造によって有効にされる、セキュリティの異なる部類を表１に図示する。

（キーリストデータ構造の構成）
次に、図２２を見ると、特定の標的デバイス１００に許諾されているアプリケーションまたはメディア特有のキーのリストを含む、データ構造２２１０は、貴重な物品であり、所有者によってバックアップされることが可能となるべきである。個別キーは、（上記のような）標的の二次秘密キーで暗号化されるため、リストは、キーが許諾されるユニットにとって有益であるのみである。しかしながら、このデータ構造２２１０が改ざん、破損、および／または完全な損失の恐れがないことを確認できる必要がある。損失したキーリストデータ構造の場合、前述のように、使用許諾権限２１１０から、その特定の標的デバイス１００に対するキーリストの新しいコピーを要求することによって、データ構造２２１０全体を回復することができる。キーリストデータ構造に一時的変更が行われた場合（そのようなシナリオの理由をこの後の項で論議する）、プロトコルは、一時的であるような変更を識別するための手段に適応してもよい。最終的に、キーリストデータ構造２２１０の真正性、適時性、および有効性を立証するための何らかの改竄耐性のあるメカニズムを含む。

これらの要件を念頭に置いて、図２２に示されるもののような方式で、これらの品質の全てを示す、安全なキーリストデータ構造２２１０を構築することができる。例のごとく、示される例は、そのようなデータ構造に所望の特性の全てを含むことができる唯一の方法ではない。それでもなお、図２２に図示された特定のデータ構造は、実際に、プロトコルの基本要件の全てを満たす。

上記の図では、留意すべきいくつかの基本的規則がある。第１は、キーリストデータ構造２２１０の最上位暗号化が、標的デバイスの一次秘密キーで行われなければならないことである。この特定のキーを使用することのいくつかの理由があるが、主要な問題点は、このデータ構造のローカルコピーを修復しなければならない場合に、使用許諾権限２１１０が、標的デバイス１００とは無関係に、このデータ構造の暗号化された形態を再生できなければならないことである。このデータ構造を暗号化するために、任意の他のキー（例えば、標的の二次秘密キー等）が使用される場合、標的がデータ構造の変更を行う必要がある時（キーがリストに追加される時のように）、リスト全体は、バックアップ目的で使用許諾権限２１１０に転送されなければならない。これは、使用許諾権限２１１０に返送されなければならないネットワークトラフィックの量を大きく増加させる可能性があり、必ずしもチャネル帯域幅の最も効率的な使用ではない。

また、このキーリストデータ構造２２１０は、標準アプリケーションまたはメディアストリーム特有のライセンスキーの記憶に使用されることに加えて、セキュリティシステム関連キーの記憶に使用されることが望ましい。このデータ構造は、使用許諾権限２１１０によって再生されることができるため、標的デバイス１００上で作動するセキュリティソフトウェアを更新することが望ましい場合、両方の機能に同じキーリストデータ構造２２１０が使用され得るならば、より安全で、より効率的であることの両方となる（標的デバイス１００に対するコード記憶の要件の観点から）。

第２の問題点は、キーリストデータ構造２２１０の暗号化されたバージョンが本来のキーリストデータ構造２２１０のメッセージダイジェストを含むことである。個別キーのそれぞれが暗号化されるものの、リスト自体の他の部分は、メッセージダイジェストが計算される時点で別々に暗号化されないことに留意されたい。メッセージダイジェスト計算の後、キーリストデータ構造２２１０の全体（メッセージダイジェストを含む）は、最上位（またはマスター）キーによって識別される、キー値およびアルゴリズムで暗号化される。これは、悪意のある第３者がリストを改ざんし、新しいメッセージダイジェストを計算し、次いで修正されたリストを真性のリストに代用することを防止するために行われる。キーリストデータ構造２２１０が標的ユニット１００のメモリスペースに読み込まれると、任意の他の安全な暗号化されたコードブロックにＭＡＣが使用される方法と同じ方式で、キーリスト自体の真正性および有効性を検証するために、この（復号化された）メッセージダイジェストが使用される。個別キー以外の要素の全てが、マスターキーで暗号化されるのみであるという事実は、最上位キー以外の任意のキーにアクセスする必要なく、リストを詳しく検討できる（およびリストを維持できる）ことを意味する。また、暗号復号化ブロックを通る単一パスのみで、キーリスト目録を編纂することができる。

関心の第３の原則は、個別アプリケーションコードまたはメディアストリーム特有のキーを、各標的デバイス１００に対する個別キーに適応するように十分大きくできることである。コードまたはメディアストリームが大量生産されたディスクを介して配布される場合、これは、アプリケーション開発者２１２０が、個別暗号復号化キーとともに、新しいコード特有のＩＤを発行する必要があることを意味する。使用許諾工程に関与する関係者の全ての間で転送されなければならないデータの量を最小化しようとする観点より、これはあまり効率的ではないかもしれないが、損なわれた暗号復号化キーを追跡する能力を含む（しかし、それに限定されない）機能性をプロトコルに追加する。これはまた、キー取消を扱う以降の項でも論議する。

注目すべき次の問題点は、キーリストデータ構造２２１０のヘッダが、リストの残りの部分を構成するアプリケーション特有のキーと同じ１組の特性を共有することである。実際、ヘッダは、キーリストデータ構造２２１０自体の残りの部分に対するマスターキー２２２０と考えることができる。したがって、リストの残りの部分の管理を決定するために、このキーをどのように使用できるかに関する限りは、動作の同じ原則を適用することができる。これは、標的デバイス１００のセキュリティシステムの時間依存性管理を含む。したがって、標的ユニット１００は、所定の間隔でそのセキュリティシステムを更新せざるを得なくなり、それだけで極度に強力な概念である。

キーリストが多数のセクションを含むことができ、それぞれが独自のマスターキー２２２０（リストヘッダ）を有し、したがって、独自の独立暗号化メカニズムを有するという可能性も存在する。任意の他のキーと同様に、リストヘッダは、キーリストデータ構造２２１０を解釈するために使用される、暗号化されたコードブロックを指し示すことができる、コード特有のＩＤフィールド２６０を含む。次いで、リスト全体は、独自のマスターキー（それは、さらに別のリストヘッダ）を含む、さらに別のマスターリスト内に含まれ得る。したがって、キーリストデータ構造２２１０全体を再帰的に定義することができる。前述のように、この再帰的特性は、新しいキーリストデータ構造を作成して同じデータ構造の以前のバージョンの欠点に対処することによって、セキュリティシステムを更新するために使用することができる。リスト全体のセキュリティが「最外の」（または最新の）セキュリティ層内に含まれるため、キーリストデータ構造２２１０全体のセキュリティは、常にセキュリティソフトウェアの最新の反復に基づく。

したがって、キーリストデータ構造２２１０の再帰的特性は、強力な特徴である。前の項で論議された、データ構造の正確な実装が最重要ではないということも理由である。上記で提供した説明は、単に、プロトコルの再帰的性質を機能させるために必要とされる最小限の一部の機能性である特徴を含んだ、一例であった。

それがどのように構造化されるかとは無関係に、キーリスト２２１０は、いくつかの一般的な状況下で維持および／または更新されてもよい。これらの状況は、リストに含まれるキーのうちの１つ以上の状態が修正される場合を含む（しかし、それに限定されない）。１つのユニットから別のユニットへ特定のキー１８１０の所有権を譲渡することができるいくつかの基本的メカニズムがあり、これらを以降の項で論議する。しかしながら、どのような場合でも、改訂されたキーリストが維持されるメカニズムは、使用許諾権限２１１０の干渉を必要とするもの、および独立して実行することができるものといった、２つの部類に分けることができる。

このプロトコルが基づく主要な動作概念のうちの１つは、使用許諾権限２１１０の中央サーバと個別標的ユニットとの間の必要なネットワークトラフィックの量を最小に削減するというものである。したがって、キーリストデータ構造２２１０の任意の一時的変更（その理由は以下に説明する）は、標的ユニット１００によって独立して維持されることができるべきである。このことの主要な理由は、これらの変更が、表向きは、デバイスのセキュリティシステムの永久的変更（常に、標的デバイス１００と使用許諾権限との間の相互作用によってのみ達成されるべきである）よりも頻繁に発生するということである。

どのような場合でも、標的デバイス１００が、一義的な方式でマスターキーリストデータ構造の現在の状態を追跡することができる、何らかのメカニズムが存在しなければならない。このことは、２つの「マスター」リストを有することによって達成することができる。これら２つのリストのうちの第１（永久キーリストと呼ぶ）は、使用許諾権限２１１０によって維持される。このリストは、問題の標的ユニット１００に関連付けられる、アプリケーション特有のキーの「永久」所有権に関係している。第２のリストは、等しく重要であるが、「永久」キーリストデータ構造の一時的修正に関係しているものである。これらの修正は、リストへの追加となり得るか、または、リストからの削除となり得るかのいずれかであることに留意されたい。２つのリスト自体のデータ構造の実装には必要な差異はなく、主要な差異は、それらがどのように維持されるかによって発生する。これらのリストのうちの一方または他方のいずれかが、損失したイベントから標的ユニット１００を回復するために、何らかの方法が存在すべきことが望ましい。この損失は、何らかの壊滅的な不具合によるもの、またはリストのうちの１つの中に含まれた情報がどういうわけか破損した（悪意がなく、または悪意を持ってのいずれかで）場合によるものとなり得る。そのような「キーリスト破損」イベントの含意を以降の項で論議する。使用許諾権限との接続によって、永久リストを修復できることが必要であるものの、使用許諾権限２１１０が特定の標的デバイスの一時キーリストを回復できることは必要ではない（望ましくさえない）。この見解には多くの理由があるが、主要な理由は、一時キーリストが、永久キーリストよりもはるかに頻繁に更新される可能性が高いことであり、中央使用許諾権限２１１０と標的ユニットとの間の必要なネットワークトラフィックの量を絶対最小値に保つことが望ましい。それでもなお、いくつかの理由で（そのいくつかを以降で論議する）、使用許諾権限２１１０が特定の標的の一時キーリストに修正を行うことができることが潜在的に望ましくあり得る。この場合、標的デバイスの一次秘密キー（使用許諾権限２１１０に知られている）を使用して、このリストを暗号化させることが望ましくなる。

前述のように、キーリストデータ構造の両方の完全性は、リスト自体とともに保存される、署名されたメッセージダイジェスト（デジタル署名）を使用することによって検証することができる。このメッセージダイジェストを生成するために使用される安全なコードメカニズムの実装は、以前の項において説明し、手順を再び繰り返す必要はない。また、損失および／または破損の場合に永久キーリストデータ構造２２１０を回復するための手順もすでに説明した。対処しなければならない唯一の残っている問題点は、一時キーリストデータ構造の時間依存性部分をどのように解釈するか、および一時キーリストがどういうわけか使用不能になった場合にどのように対処するかである。

（一時ライセンス譲渡）
これは、タイムスタンプフィールド１８３０の使用が最も重要である、セキュリティプロトコルのセクションのうちの１つである。前述のように、一時キーリストデータ構造は、標的デバイスの永久キーリストと正確に同じ方式で構築される。しかしながら、２つの間にはいくつかの差異がある。第１の差異は、標的ユニットの秘密キー１０４のうちのいずれか１つによって、一時キーリストを潜在的に暗号化できることである。通常の条件下で、使用許諾権限２１１０が、このデータ構造を再構築できることは必要ではないため、それを暗号化するために標的ユニットのキーのうちのどれが使用されるかは、表向きは関連性がない。しかしながら、このリストがまた、標的ユニットの一次秘密キーを使用して暗号化された場合、それは潜在的に使用許諾権限２１１０の役に立つであろう。このことの理由は、ライセンス取消と関係があり、その状況を以降の項で論議する。

一時および永久キーリストの第２の（かつ最も重要な）区別は、最も新しい一時キーリストデータ構造に関連するタイムスタンプ値１８３０のコピーもまた、標的デバイス１００の内部に記憶されることである（つまり、オンチップ）。このレジスタは、ソフトウェア読み取り可能なではなく、セキュリティブロックの一部であるため、安全なコードによって上書きされることができるのみである。このレジスタにおける値は、一時キーリストデータ構造がどういうわけか損失および／または破損した場合にどうするかを決定するために使用される。その手順をこの項の以降で論議する。

一時キーリストと永久キーリストとのさらに別の区別は、標的ユニット１００が、その永久リストからユニット１００の一時リストへ特定のキーの所有権を（一時的に）譲渡できることであるが、いずれの（同時に動作している）デバイスも、その一時キーリストから任意の他のキーリストへは特定のキーの所有権を譲渡できない。これは、当然ながら、他のユニットの一時キーリストだけでなく、標的１００独自の永久キーリストも同様に含む。これは、どのデバイスが（および、いつ）任意の特定のキーを「借用」することができるようになるかを永久所有者のみが決定できることを意味する。しかしながら、この「貸出」期間は無期限にできる（および、このトランザクションは使用許諾権限に連絡する必要なく実行できる）ことに留意されたい。この「永久貸出」特徴は、最も近代的なデジタル著作権コントロール情報（ＣＣＩ）システムの一部である、標準的「コピーワンス」機能要件と同等である。

次に、図２３を参照すると、一時「キー借出」手順を描写する詳細なフロー図が、示される。「キー所有権」譲渡手順は、図書館から本のコピーを借り出す手順といくぶん同様である。「借り手２３２０」が永久所有者（「貸し手２３１０」）から特定のアプリケーション特有のキー２１５０の一時使用を要求する場合、貸し手２３１０はまず、キー借出交渉工程の持続時間にわたって特定のキーの使用を禁止する、自らのための更新された一時キーリストを生成する。このアクションは、２つ以上の借り手２３２０ユニットが同じキーを要求することを禁止する。貸し手ユニット２３１０の一時キーリスト上の「借り出されたキー」の存在は、任意の特定のキーへのアクセスを制御するために、セマフォとして効果的に使用される。しかしながら、キーが「制限」に設置される初期時間量は、比較的短い期間に限定されるべきである。これは、借り手２３２０デバイスが、長い期間にわたって特定のキーのアクセスを要求し、次いで、特定のキーの使用を不正に独占することにより、何らかの理由でトランザクションを完了できない場合を防止するためである。この比較的短い借出交渉段階のタイムアウトもまた、貸し手ユニット２３１０に対する「サービス妨害」攻撃の同様のものを搭載しようとしているかもしれない、悪意のあるデバイスの対策に役立つ。実際、貸し手ユニット２３１０は、選択的に、その「承認された借り手」リスト上にないデバイスからの要求、または、万一これらのユニットのうちのいずれか１つがある期間内に過度に多くの要求を行おうとした場合に要求を無視することができる。この一時ブロックがキーに設置される正確な時間の長さは重要ではないが、任意の所与の借出手順が完了することを可能にするように十分長くなるべきである。高ネットワークトラフィックまたは潜時の時には、この期間を延長することができる。

所与のキーの２つ移譲のコピーが同時に借り出されることが可能となる場合、所与のキーのいくつのコピーがいずれか１つの時点で借り出されるかを示すために、貸し手デバイス２３１０の一時キーリスト内の適切なフィールドを使用できることに留意されたい。いったん借り手２３２０および貸し手２３１０が所与のキーの特定の借出期間を交渉すると、貸し手２３１０は、借り手２３２０にキー２３４０の暗号化されたコピーを送信する。この暗号化は、貸し手デバイス２３１０のみに知られている、一時秘密キー２３３０を使用して実行される。次いで、借り手２３２０が暗号化されたキーの正確な受信を確認する（暗号化されたメッセージから計算されるメッセージダイジェストを用いて）と、貸し手２３１０は、借り出されたキーの「貸出期間」を延長し、借り手デバイス２３２０に一時秘密キー２３３０を送信する。この貸出工程の最大持続時間は、プロトコルの動作にとって重要ではなく、この値の選択において行われなければならないいくつかのトレードオフがある。これらの特定の問題点をこの項の以降で繰り返す。上記の例では、「借り手２３２０」および「貸し手２３１０」デバイスは、キー毎に借り出し期間の実際の長さを交渉できると想定するが、これは、確かにプロトコルの要件ではない。

借り手２３２０または貸し手２３１０のいずれかの一時キーリストが更新される時点の直前に、新しい一時リストに関連付けられるタイムスタンプ値１８３０のコピーが、標的１００上に不揮発性様式で記憶される。その時点で、一時キーリストデータ構造の暗号化されたバージョンは、安全にメモリに書き出すことができる（または、オンボードＮＶＲＡＭ、フラッシュＲＯＭ、または何らかのハードディク上のどこか２３５０のバックアップファイル等の、何らかの他のより永久的な場所に記憶される）。一時キーリストは、潜在的に、永久キーリストよりもはるかに頻繁に読み取られ、更新されるため、このリストは標的ユニットに迅速にアクセス可能であるべきことが望ましく、よって、アクセス潜時が比較的短い少なくとも１つの場所に、このリストが記憶されることが推奨される（しかし、プロトコルの実際の要件ではない）。一方で、電力不具合が不確定時間量にわたってユニット１００の機能性の損失を潜在的に引き起こし得るため、このリストが記憶される唯一の場所が、何らかの揮発性記憶媒体（ＤＲＡＭ等）であることが推奨される。この問題点について、この項の以降で詳細に述べる。

特定のキーの借り出し期間が満了すると、借り手２３２０および貸し手２３１０デバイスの両方は、それぞれの一時キーリストデータベースを独立して更新することができる。したがって、「特定のキーを流通に戻す」ために、借り手２３２０が貸し手２３１０ユニットと連絡を取っていることは要件ではない。これは、借り手２３２０および貸し手２３１０デバイスが大きく離れている場合に、主要な利便性要因である。当然ながら、この動作のセキュリティは、キータイムスタンプ記録を生成および制御するために使用されるオンチップクロック間の非常に緊密な相関に依存してもよい。したがって、時間／日付クロックは、セキュリティシステムの不可欠な部分でなければならず、そのようなものとして、中央サーバとのトランザクションによって上書きされることができるべきである。また、クロックは、悪意のあるユーザが内部タイムスタンプ値１８３０を修正しようとする場合に改ざん抵抗し、また、通常発生するシステム電力不具合を乗り切ることができるように、十分にロバストとなるように設計されなければならない。このクロックがバッテリ電源式であること、およびバッテリが除去され得るか、または経時的に電池切れになり得ることが想定できないわけではないため、システムは、クロックが潜在的に、使用許諾権限との相互作用によって再開およびリセットされ得るような態様で設計されるべきである。

こうして、特定のアプリケーション特有のキー２１５０の所有権を１つのユニットから別のユニットへ一時的に譲渡することができる状況を説明した。「貸出期間」の最後に、「借り手２３２０」および「貸し手２３１０」ユニットの両方は、それらの一時キーリストデータ構造を更新して、本来の所有者へのキーの「返却」を反映することができる。この手順は、両方のユニット上で独立して実行することができ、したがって、２つのデバイス間の相互作用を必要としないことに留意されたい。

ここで、１つ以上のキーが「借り出されている」または「貸出中」である間に、一時キーリストデータ構造の一方または他方が破損および／または損失した場合に対処しなければならない。「貸し手２３１０」ユニット側では、キーが借り出されると、それが最初に行うことは、「貸出」期間の終了を決定することである。この値は明らかに、現在の時間／日付フィールドの値に貸出期間の持続時間を加算することによって構築される。次いで、この時間／日付値は、デバイスの一時キーリストが最後に更新された時の結果としてオンチップに記憶されている値と比較される。新しい値が古い値よりも大きい（後である）場合、新しい値は、古い値の代わりに上書きされる。「借り手２３２０」側では、この同じ処理が使用されるため、結果は、任意の所与の標的ユニットにおいて、一時キーリストタイムスタンプは、常に特定のユニット１００の一時キーリストの一部として保存されるタイムスタンプのうちのいずれかの最新のものである。

ユニット１００の一時キーリストが損失あるいは不正に修正された場合、この「最新のタイムスタンプ」値が満了する時点まで（事実上、「タイムアウト」期間）、一時キーリストおよび永久リストの両方は無効となる。次いで、その時点で、ユニットは、永久キーリストを使用することに再び着手することができ、新しい一時キーリストを再構築する工程を開始することができる。

したがって、デバイスの一時リストが改ざんまたは削除された場合、ユニットは、タイムアウト期間が満了するまで、効果的に動作不能となる。このタイムアウト手順は、不必要に制限的と思われる場合がある一方で、何らかの悪意のある行為の結果として、または１つのユニットから別のユニットへのキーの譲渡中に発生し得る何らかの故障（停電またはネットワーク接続の停止等）により存在する、任意の特定のアプリケーション特有のキーの複数のコピーの潜在的問題を回避する。また、一時キーリストデータ構造の改ざんの結果としてのそのようないくつかの影響の可能性は、より複雑化された攻撃を除くすべてによる実践の阻止を助長するはずである。

この点で、プロトコルの動作を強化するために使用され得る、多数のオプションの付加的特徴がある。１つのそのような考えられるオプションは、標的ユニットのオンチップセキュリティセクションに保存されている値に、暗号化されたキーリストデータ構造のうちのいずれか一方（または両方）から生成される、署名されたメッセージダイジェスト（デジタル署名）を追加することである。デジタル署名の暗号復号化に起因するＭＡＣ値は、暗号復号化工程全体を経過する必要なく、任意の特定のキーリストのうちのいずれかの有効性を迅速に検証するために使用され得る。しかしながら、複数のネスト化されたキーリストの問題点は、暗号化されていないキーを最終的に産出するために、この暗号復号化手順をある時点で複数回行わなければならない可能性が全面的に高いことを意味し、よって、これらのデジタル署名がオンチップに保存されることは、プロトコルの動作にとって重大ではない。

別の強化の可能性は、１つだけよりもむしろ、１対のオンチップタイムスタンプ値を記憶することである。一時キーリストを更新しなければならない最も早い（次の）時間を示すために、付加的なタイムスタンプが使用され得る。リストを常にチェックする（暗号復号化工程を経過することを伴う）必要がないため、これにより、標的デバイス１００が、その一時キーリストを改訂する必要がある時を決定しやすくなる。この特徴は、非常に有用となるが、再度、ユニットがこのプロトコルを実行できるための基本要件ではない。しかしながら、この第２のタイムスタンプを含むシステムが実装される場合、２つのタイムスタンプが何らかの理由で「同期しなくなる」場合に混乱の可能性を提起する。思い浮かぶ１つのそのような例は、１つのそのようなタイムスタンプが書き込まれた直後であるが、第２のものが更新される前の時点で発生する、電力故障が存在する場合である。

対処されるべき最後の問題点は、これらの一時キーリストタイムスタンプの値に対して、何が最小限度および最大限度であるかという問題である。一方で、最大「一時貸出期間」のより大きい限度は、ユーザが、適度に長期間にわたって１つのユニットから別のユニットへ、特定のデータアプリケーション（またはメディアストリーム）の使用を譲渡できるようにし得る。これは、ユーザが「ホームユニット」から携帯用ユニットへメディアストリームの所有権を譲渡することを希望する場合に、潜在的に役立つ。長い「借り出し期間」を有することにより、本来の「貸し手」ユニット２３１０と連絡を取っていることを必要とせずに、ユーザが長期の旅行に携帯用ユニット（その関連一時キーとともに）を持っていくことが可能となる。長い「借り出し」期間の不利な面は、万一、元のユニット上の一時キーリストデータ構造に何かが起こった場合、そのユニットが長期間にわたって潜在的に無効となることである。

この最後の問題点はまた、１つの悪意のあるコードが、オンチップタイムスタンプレジスタの値をある不確定値に設定できる場合に、標的ユニット１００に対する潜在的危険も指摘する。これは、潜在的に、攻撃の標的を無効化することに等しくなり得るため、このタイムスタンプレジスタの値は、「安全な」コードブロックによって書き込まれることができるのみとなるべきである。再度、各ユニットは、異なる１組の秘密キーを有するため、悪意のあるデバイスが正当なユニットを効果的に装う場合を除いて、１つの特定のユニット１００の秘密キー１０４データの発見は、他のユニットへの関心を引き起こすべきではない。この攻撃のモードを、同一性確認に関する問題点を扱う以降の項で論議する。

（永久ライセンス譲渡）
この手順の要素の多くを、本書の以前の項において論議した。特有のキーが１つのユニットから別のユニットへ永久に譲渡される基本工程を図２１に示した。多くの点で、この手順は、この項の直前の項で説明されているような、キー所有権の一時譲渡の手順と本質的に同様である。

２つの手順の間の主要な差異は、永久譲渡が一時譲渡よりも単純な工程であること、永久キー所有権の譲渡手順が使用許諾権限２１１０と標的ユニット１００との間の相互作用を利用すべきことである。永久譲渡工程がより単純である理由は、一時キー借り出し手順において必須条件である借出期間交渉を必要としないという事実にある。永久譲渡機能が使用許諾権限２１１０と標的ユニット１００との間の相互作用を利用する理由は、更新されたキーリストデータ構造が、トランザクションの両端で再構築されることができなければならないという事実によるものである。

永久ライセンス譲渡は、通常、使用許諾権限２１１０との相互作用を用いて発生するため、どのアプリケーションまたはメディアストリーム特有のキーがどの標的ユニットに属するかという記録がある。前述のように、これは、標的ユニット１００のキーリストが何らかの壊滅的なデータ損失状況後に修復されなければならない場合に、または特定の標的ユニット１００の所有権が異なる実体に譲渡される場合に、必要である。使用許諾権限２１１０側のこの干渉はまた、特定のキーの永久所有権が１つの標的ユニット１００から別のユニットへ譲渡される場合にも必要である。別の実体から最初に購入された資産を所有者が再販売する能力は、「第１販売権」として知られており、本明細書で説明されているプロトコルがこの特定の機能を支援する能力は重要である。

標的ユニット１００の永久キーリストが使用許諾権限２１１０によって維持されるという事実の別の重要な側面は、ユニット１００がどういうわけか損なわれたことが証明された場合に、またはキーが損なわれているとして識別された場合に、この本体が、個別標的ユニット１００のライセンスキーのいずれかまたは全てを取り消す能力を有することである。（前述のように）あらゆる標的ユニット１００にキーの一意のリストを付与する可能性が存在するため、使用許諾権限２１１０が損なわれたキーのソースを追跡する機会も提供し得る。そのような状況では、このプロトコルは、通常は「透かし」特徴に関連付けられる機能を果たし得るが、従来の透かし処理の欠点（透かしがメディアストリームの質に悪影響を及ぼす可能性等）がない。

たとえ事実と思えないかもしれなくても、アプリケーションコードまたはメディアストリーム特有のＩＤ情報がアプリケーション開発者２１２０から発生し、使用許諾権限２１１０が、任意の特定のアプリケーションまたはメディアストリームとその許諾所有者との間で関連付けを行うことができるように、十分な情報を必ずしも有するわけではないため、デジタルコンテンツ所有者のプライバシーは、この工程によって依然として維持される。ユーザのプライバシーを保護する能力もまた、このプロトコルの重要な側面である。

永久キー譲渡工程について留意すべき最後の問題点は、永久キー譲渡が果たす同じ機能の全てを、一時キーライセンス譲渡によって達成することが実際に可能なことである。しかしながら、標的ユニットのセキュリティシステムの維持は、中央の安全なサーバによって理想的に制御されるべき機能であるため、チェーンのどこかにそのようなメカニズムを設置することが必要である。また、ユーザがプライバシーを維持することを懸念する場合、中央サーバが著作権所有者と標的ユニット１００との間の緩衝の役割を果たすことができるという事実は、大変有用である。最後に、使用許諾権限２１１０は、一時キー譲渡メカニズムからこの機能を除外する、特定の標的ユニット１００の永久キーリストに対する中央バックアップ記憶メカニズムの役割を果たすことができるという魅力もある。

（システム所有権譲渡、ライセンス取消、およびセキュリティシステム更新）
標的ユニット１００のライセンス（またはキー）のうちの１つ以上が取り消されてもよい、いくつかの異なる手段がある。最も単純な方法は、標的１００の一次秘密キーを単純に更新する方法である。この点で、標的１００は、その永久キーリストにアクセスできなくなり、したがって、新しいものを作成する工程を開始しなければならない。一次秘密キーが一時キーリストデータ構造に対する暗号化工程で使用されなかった場合、たとえそうでなければ永久キーリストがアクセス不可能となる場合があるとしても、この一時キーリストは、潜在的に依然としてアクセスされ得ることに留意されたい。この点は、一時キーリストに対する暗号化工程の説明で以前に述べた。この理由により、永久および一時キーリストデータ構造の両方に対する暗号化キーとして、標的ユニット１００の一次秘密キーを使用することがおそらく最善の考えである。

標的ユニット１００の所有権がある個人から別の個人へ変わる場合、この所有権変更を達成するための最も単純な方式は、ユニット１００の一次秘密キーを何らかの新しい値に設定することである。しかしながら、本来の所有者が標的から永久キーの全てを回復する機会を有する前に、これが発生した場合には、ライセンスを失う。本来の所有者が、標的ユニットとともに関連永久キーリストの所有権を譲渡することを希望する場合には、特定のデバイスに関連付けられる所有権情報（使用許諾権限２１１０において記憶される）を変更すること以外に、何も標的ユニット１００になされる必要はない。

ライセンス取消が発生することができる別の方式は、特定の標的ユニット１００の永久キーリストに対するマスターキーが「満了する」場合である。ユニット１００のセキュリティシステムの更新が永久キーリストの一部として保存されるため、この状況は、潜在的に破滅的な影響を及ぼし得る。

この窮地から回復することは潜在的に可能となるが、標的１００が、徹底的に構築される全く新しい「信用の連鎖」を有する必要があることを要求する。この状況では、新しく初期化されたセキュリティシステムのコアは、標的１００のある部分上でアトミックに作動することができるとして検証され得る計算のみに基づかなければならない。したがって、これは、（潜在的に疑わしくなり得る）最小量の他の汎用コードさえも要求した、任意のハッシング関数の使用を排除する。幸運にも、この状況は、検証可能な形で安全なコード断片の永久コアを終了しない永久キーリストデータ構造の一部として常に保つという単純な事柄によって回避することができる。しかしながら、これは、セキュリティの危険自体であり、上記に論じられた理由から、したがって、この永久コードコアのコンテンツは、できる限り制限されるべきである。

ライセンス取消のさらに別の方式は、使用許諾権限２１１０が標的ユニット１００の永久または一時キーリストにおける特定のキー入力を無視することを選択した場合に、発生することができる。これは、セキュリティシステムアップグレードが必要とされる場合に、または特定の標的ユニット１００が特定のアプリケーションまたはメディアストリームの無許諾コピーを有していると識別された場合に、使用され得る。標的ユニット１００は通常、独自のキーリストデータ構造を維持するため、この手順は、使用許諾権限２１１０と標的ユニットとの間で、通常よりも大量のネットワークトラフィックを伴う。

それでもなお、そのような手順は、破壊されたキーを検索して無効にする、および／または古いソフトウェアを更新されたバージョンと交換するように設計される、標的特有のカスタムバージョンで、問題の標的デバイス１００にセキュリティシステムソフトウェアを強制的に改訂させることによって、達成することができる。当然ながら、この手順は、標的デバイス１００が使用許諾権限の中央サーバとの接続を開始する時点でしか発動させることができない。通常の状況下で、任意の特定の標的ユニット１００が、任意の特定のスケジュール通りに使用許諾権限２１１０への連絡を開始することは保証できない。幸運にも、問題の標的デバイス１００は、その永久キーリストへの任意の新しい追加を認可するために、使用許諾権限２１１０に接続しなければならない（直接または間接的のいずれかで）ため、あらゆるキー取消アクションは、新しいキー使用許諾手順の一部として達成することができる。また、この「リスト監視」アクションを支援するために、前述の「セキュリティシステムタイムアウト」メカニズムが使用され得ることも可能である。しかしながら、これが事実であることは、このプロトコルにとっての要件ではなく、そのようなシステムがユーザのプライバシー権利の侵害をもたらす可能性が高い。

（他の懸念事項：）
必ずしもプロトコル自体の一部ではないが、それでもなお、本明細書で説明されるプロトコルを適正に実行することができる特定のシステムを作成する工程で対処されなければならない、多数の問題点が存在する。これらの問題点のうちのいくつかは、実際の工程またはデバイスの実装に依存しており、他のものは、大部分はアプリケーションに特有である。この情報は、好適な標的デバイス１００の適正な構成に密接に結び付いているため、これらの問題のいくつかを以下の項で論議する。

（相互動作することができるユニットの数の限度）
著作権所有者が、主要標的が一時的に所有権を譲渡することができるデバイスの合計数を限定することを希望する場合、これは、どの時点においても有効であってもよい限定数の公開／プライベートキーペアを確立することによって達成されてもよい。これは、以前の項で説明された、同じアプリケーション特有のキーの複数のコピーが同時に「貸出中」であった場合とは異なることに留意されたい。他のシナリオが可能であり、その場合、特定の標的デバイス１００からアプリケーション特有のキーのうちのいずれかを「借り出す」ことができる、デバイスのリストは、ある１組のシリアル番号に限定することができる。使用許諾権限２１１０は、標的ユニット１００のセキュリティシステムが管理される正確に同じ方式で、そのような「承認された借り手」リストを管理することができる。したがって、使用許諾権限２１１０は、例えば、「承認された借り手」リスト上の１組のシリアル番号を、元の標的デバイス１００と同じ所有権情報を有する者に限定し得る。本課題に対する別の可能な解決策は、任意の「借り手２３２０」が、存在する証明書（例えば、署名証明書）によって「認証された」借り手として貸し手に確認されることを要求することであり、貸し手は、中央使用許諾権限２１１０公開キーを用いて証明書を復号化することによって確認される。当然ながら、このシナリオは、特定のユニットが危殆化されることを決定される場合に、そのような証明書を無効にする使使用許諾権限２１１０の能力に関係している。本証明書無効プロセスが達成され得る１つの周知の方法は、定期的に公開される「無効リスト」を介する。

（秘密キー発見および同一性確認の問題点）
特定のプレーヤに対する一次秘密キーが、物理的分解およびチップ金型検査によって発見された場合、これは、各デバイスが異なる１組の秘密キー１０４を有するため、任意の他のデバイスのセキュリティを損なうべきではない。しかしながら、特定のプレーヤに対する一次キーがどういうわけか損なわれた場合、無許諾デバイスが正当な標的ユニットを装うことが潜在的に可能である。この問題が未検出のままとなった場合、この知識を装備した無許諾デバイスが、その特定の標的ユニットへ発行されたアプリケーション特有の暗号復号化キーのうちのいずれかを損ない得るという可能性存在する。標的ユニット１００のシリアル番号１０６は、まず第１に、使用許諾権限２１１０がデバイスへ暗号復号化キーを発行するために登録されなければならないため、この目的の問題は、表向きは、無許諾デバイスによる他の正当な標的ユニット１００の限定に限定される。

しかしながら、ユニット１００の秘密キーの両方がそのような工程によって発見された場合、暗号化されたキーリストダイジェストの以前にバックアップされたコピーの検査に基づいて、そのユニットに許諾されたアプリケーション特有のキーの全てのセキュリティを損なうことが可能となる可能性がある。この理由により、一次および二次秘密キーの両方は、これらのキーの値を発見しようとする試行がキーデータの損失をもたらすように、「改ざん防止」方式で標的チップ上に実装されるべきである。

この改ざん防止特徴を標的デバイス１００上に実装することができる、多数の手段があるが、そのようなものの正確な実装は、本書で説明されるプロトコルにとって重要ではない。「秘密キー損失」状況が、ユーザ側の怠慢（または乱用）という何らかの悪意のない行為を通して発生した場合、正当なユーザは、損傷されたユニットのアプリケーション特有のキーを新しいデバイスに譲渡させるように手配することができる使用許諾権限２１１０に、損傷されたユニットを戻すことができるべきである。しかしながら、元の標的デバイス１００が機能しない場合、新しい標的デバイス１００へのキーの譲渡は、アプリケーション開発者２１２０とのトランザクションを伴わなければならない（少なくとも、まず第１に暗号化されていない状態で使用許諾権限２１１０に供給されなかったキーに対して）ことに留意されたい。

しかしながら、他の真性標的ユニット１００に扮することができたデバイスは、表向きは、疑いを持たない合法的に許諾されたデバイスをだまして、そのアプリケーション特有のキーのうちの１つ以上の所有権を一時的に放棄させるか、または（前述のように）動作を一時停止させることが可能となり得たことに留意されたい。後者が発生した場合、それからキーを借用しようとしたユニットの全てを無効にし得る「不正ユニット」を有する可能性が存在する。前者が発生した場合、任意の数のアプリケーションまたはメディア特有のキーが潜在的に損なわれ得る。

したがって、特定の標的ユニット１００に対する潜在的な「許諾された借り手」の数を、使用許諾権限２１１０サーバからの安全な更新を用いて、正当なユニットに供給されることしかできないリストに限定するという、以前に議論された概念は、賢明なものである。前者の場合、これは、他の疑いを持たないユニットの所有者が、そのユニットがそもそもハッカーに実際に属しない限り、機能ユニットを分解してその秘密キーへのアクセスを獲得するハッカーによって無効化された正当なデバイスを有することを防止する。後者の場合、これは、アプリケーションまたはメディア特有のキーの譲渡を、使用許諾権限により適正に登録された、ある時点で許諾されたデバイスであったデバイスのみに限定する。それでもなお、断固としたハッカーは、依然として正当なユニットを購入し、それを暴露し、何とかして秘密キーデータへのアクセスを獲得し、次いで、正当なデバイスを装うためにこの情報を使用し得る。

そのため、この種の偽装イベントをどのように検出しようとするかという問題点が残る。この性質の極度に資金力のある敵を打倒するための唯一の成功する戦略は、少なくとも費用トレードオフの観点から、潜在的利得が必要とされる努力に値しないように、システムを設計することである。

通信している他の未知のデバイスの真正性を証明しようとする、いくつかの手段が存在する。しかしながら、デバイスが実際に主張するものであることを証明するための最も成功する方法は、このデバイスを他のデバイスから独特にする特性に焦点を当てることである。本明細書によって説明されるもの等の、デジタル暗号復号化メカニズム等の特殊目的装置の場合、セキュリティプロトコルを適正に実行すること、および所与の１組の入力変数に基づいて正しい結果を計算することは、デバイスの能力となる。しかしながら、本明細書で説明されるセキュリティプロトコルは、公知のアルゴリズムに基づくため、計算を完了するまで十分な時間があることを考慮すれば、これは、表向きは、任意の汎用計算デバイスによって達成され得る。実際、デバイスを独特にする秘密キー情報がどういうわけか損なわれた場合に、この問題点は、公的に利用可能な技術に基づく任意のデバイスにとって潜在的な問題となる。したがって、分解およびチップ金型点検に直面しても、正当な標的デバイスの全てに対してオンチップに記憶される秘密キー情報が秘密のままでなければならないという教訓に、最終的には依存しなければならない。

ある時間量内で検証可能なＭＡＣ値を正しく見つけ出す能力等の要件を、標的識別および検証工程に確かに追加することができる。最終的なＭＡＣ値が複数回に暗号化されることを要求することによって、手順をさらに困難にすることができる。したがって、ライセンスの正当なコピーを自ら単純に購入する費用よりも通常はるかに高価となる、（より一般的な）計算リソースへのアクセスを有することを必要とされる点で、攻撃者が正当なデバイスを模倣する能力を潜在的に制限することができる。メディアストリームプレーヤの場合、プレーヤが表向きは適応するように設計されている、メディアストリームのうちの１つ以上の一部分を正しく復号する能力も含むことができる。

しかしながら、どのような場合でも、デジタル著作権保護の全工程は、チューリング問題である。したがって、十分な時間およびリソースを考慮すると、いずれのデジタル著作権保護方式も、断固とした敵に打倒される可能性がある。これは、当然ながら、秘密キー情報へのアクセスが間違いなく攻撃未遂者にとって大きな利点となるという事実とは無関係でさえある。したがって、ユニットの秘密キーが損なわれることを防ぐ能力は、このセキュリティプロトコルの重要な部分である。

（結論：）
上記の著作権保護プロトコルは、いくつかの点で独特である。第１は、ユーザが合法的に購入されたアプリケーションまたはメディア特有のキーデータのバックアップコピーを作製する能力を有することを禁止しようとしないという事実である。第２に、このプロトコルは、いずれの種類のデジタルデータの区別も行わず、したがって、セキュリティプロトコルが、保護するように設計されているデータストリームと同じように容易に更新されることを可能にする。第３に、このプロトコルは、ユーザが、それらのアプリケーションまたはメディア特有のキーの所有権を、プロトコルを実行することが可能な別のユニットに一時的に譲渡できるようにする。また、このプロトコルは、ライセンス取得者が１つの標的ユニット１００から別のユニットへの所有権の永久譲渡を達成する能力を提供する。この最後の特性は、このプロトコルの下で、消費者の合法的な「第１販売権」の実現を可能にする。

実際、本明細書で説明されるプロトコルと他のコピー保護方式との間の基本的な差異のうちの１つは、このシステムのセキュリティが、特定のデータセットにアクセスする能力を制御することに依存しないが、むしろ、そのデータセット内に含まれる着想を表現する行為を制御する能力に依存することである。

前述のように、プロセッサに、所定の方法において、任意のコードのセグメントを実行させることが望ましい。とりわけ、ここで、この所望に対処する解決策が議論される。この制御の問題は、合法ソフトウェアでさえ、意図しないかまたは悪質な結果さえももたらし得るように操作され得る多くの多様な方法によって悪化する。これらの攻撃の方法として、入力データの稀なケースまたはさらに他のアルゴリズムの欠損を利用するために、偽引数を入力としてルーチンにフィードすることによって、不完全に書き込まれてはいるが、その他の点においては有効なコードを利用することを含み得る。他の可能性のある攻撃の手段として、不適切または意図的に誤った結果をもたらすように、その他の点においては合法的であるコードによって参照される種々のプロセッサレジスタ（スタックポインタ等）あるいは外部記憶位置内に記憶されているデータを個別に修正することを含む。

この種類の制御が影響を受け得るいくつかのメカニズムが存在する。これらのシステムは、この種類の意図しない使用からプロセッサを保護することを試みる単純な方式だけではなく、複雑な方式も含む。合理的にセキュアではあるが、複雑なメカニズムの１つとして、その実行の前に、コードセグメントを事前に暗号化することを含む。コードセグメントが、メモリからプロセッサにロードされると、注意深く制御された環境下において復号化され、次いで、セキュアな様式で実行されなければならない（言い換えると、復号化動作と後続の実行との間において修正または改竄されてはならない）。このメカニズムは、プロセッサが、当該コードセグメントが、実行開始可能となること前に復号化されるまで、待機しなければならないために被り得る性能上の非効率性に悩まされる。実行される特定のコードセグメントの選択と、実際の復号化後の実行との間のこの待ち時間は、プロセッサパイプラインの失速およびデータパスの非効率性を含むが、それらに限定されない多くの問題を生じさせるだけではなく、潜在的な攻撃のための別の手段を提供し得る（復号化と実行動作との間に、何らかの形でコードを乗っ取ることによる）。

また、この暗号化されたコードメカニズムは、表面上保護されている暗号化コードセグメントを適切に復号化しようとする（または、復号化されたコピーを取得する）ハッカーという不測の事態からプロセッサを保護するものでは全くない。その場合、次いで、彼らは、標的プロセッサまたはある他の非承認プロセッサのいずれかにおいて、その非保護コードを非制御様式で作動させ得る。したがって、コードが、平文（すなわち、プレーンテキスト形式）において、または暗号化された形式で配信されているかどうかにかかわらず、どのコードセグメントが、特定のプロセッサまたは複数のプロセッサにおいて作動可能であるかを正確に制御する方法を見出すことが好ましい。一方、特定のプロセッサにおいて作動可能なコードが、ある事前に選択された部分集合に限定される場合、プロセッサ自体の汎用的性質が侵害され得る。これは、可能性として、プロセッサの汎用性が低くなり、したがって、その潜在的応用の余地における融通性がほとんどなくなるようにアーキテクチャを制約するという影響を有し得る。最大限に融通性のある汎用プロセッサアーキテクチャが、常に、強く求められているが、マルウェア攻撃を最も受けやすいのは、まさにそれらのプロセッサである。

したがって、任意の特定のプロセッサアーキテクチャに依存しない、十分に汎用性のあるコード実行の制御のための方法の必要性が存在する。また、そのような方法が、標的プロセッサのオブジェクトコード密度または実行パイプラインのいずれにも悪影響を及ぼさないかどうかも有用であろう。同時に、そのようなシステムおよび方法が、元の標的プロセッサまたは何らかの他の意図されない標的プロセッサのいずれかにおける、その他の点において合法的であるコードセグメントの無許可使用に対する保護を提供することが望ましい。そのような方法は、ソフトウェアウイルスおよびマルウェアの制御のための戦いにおける貴重なツールとなるだけではなく、デジタルコンテンツの世界において、著作権を保護するための一意に強力なメカニズムとなる。

これを受けて、汎用コードブロックの実行に対する高度に特有の制御を提供し、それによって、所与のコードブロックが実行される的確な環境をプログラマが決定することを可能にするシステムおよび方法の実施形態に焦点が向けられる。これらの条件として、コードブロックが実行を試みる個々のデバイス、コードブロックが呼び出される環境、実行の時間、実行の順序、および、コードブロックが特定の実行スレッドにおいて呼び出された回数等の制約を含み得る（しかしながら、それらに限定されない）。

そのような制御メカニズムは、例えば、一実施形態では、再帰的実行を介して実装される、呼び出されたコードセグメントのセットの明示的に順序付けられた実行に基づいて、データ隠蔽システムおよび方法の実施形態と結合されてもよい。これらのシステムおよび方法の実施形態がともに利用されると、妨害されることのない普遍性だけではなく、多くの他のセキュリティシステムに勝る、攻撃に対する一定レベルの保護が得られ得る。

図１は、効果的に利用され得る説明された実施形態におけるアーキテクチャの一般的概要である一方、図２は、受信されたデジタルコンテンツと併せて、デジタルコンテンツの実行を制御することまたはセキュリティプロトコルを実装するいることが可能である標的ユニットの特定の実施形態のアーキテクチャを説明する。

標的ユニットの一方向ハッシュ関数ハードウェアに関してより詳細に論じることが有用であり得る。次に、図３６を参照すると、後続の反復内の一方向ハッシュ関数に対するシード値として、再帰的セキュリティプロトコルの一反復で生成されるデジタル署名動作の結果を使用することができる一方向ハッシュ関数ブロックの一実施形態が、描写される。一実施形態では、標的ユニットの状態がセキュア化実行モードで動作しているかどうかに関している限り、標的ユニットの状態は、ハードウェアビット３６７０の値によって反映され得、ハードウェアビット３６７０は、本明細書では、「セキュア化モード有効化」ビットと称される。

ここでは、このハードウェアビットのデフォルト状態は消去されてもよい（すなわち、標的プロセッサのデフォルト状態は、セキュア化実行モードにおいて動作することができない）。ある実施形態における、一方向ハッシュ関数ハードウェアブロック３６６１とのこのビットの交信は、２つに分けて説明されてもよい。第１の（非セキュア化）場合、「セキュア化モード有効化」ビットが、このハードウェアビットが設定されると（例えば、「１」に、しかしながら、また、あるアーキテクチャでは、ビットは、「０」の値を有するときに「設定された」とみなされてもよいことに留意されたい）、秘密ハードウェアキーの使用のみを可能にするゲートキーパーとして作用するため、秘密ハードウェアキー３６４０へのアクセスはすべて阻止される。また、この場合、デジタル署名レジスタ３６６４の出力がフィードバックされ、一方向ハッシュ関数３６６１の入力「シード」３６１０を形成する。したがって、プロセッサが、この「非セキュア化実行」モードにおいて実行中、一方向ハッシュ関数演算のいずれかの中間結果がフィードバックされ、任意の後続の一方向ハッシュ関数演算のためのシードを形成する。これは、ネスト化または連結された機能集合の呼出しチェーン全体に相当する自走チェックサムを維持可能にする。実行が試みられる各コードブロックが、実行が可能になることに先立って、この一方向ハッシュ関数によって、最初に評価される場合、任意の所与のコードブロックの呼出しチェーン全体が、実質的に、この単一メカニズムによって明確に決定可能である。

同様に、「セキュア化モード有効化」ビットが設定される場合（すなわち、プロセッサが、「セキュア化実行モード」で動作中の場合）、秘密ハードウェアキーは、アクセス可能である（言い換えると、直接アクセス可能、またはその値がプロセッサ自体によって直接アクセス可能ではない場合でも、少なくともその値は、計算動作において使用可能である）。加えて、セキュア化実行モードで動作時に、デジタル署名レジスタの出力は、一方向ハッシュ関数の後続の評価のためのシード値を形成するために、フィードバックされない。このデジタル署名発生器ブロックのまさにその実装については、後にさらに詳細に論じられる。次いで、理解されるように、ある実施形態では、特定のコードブロックの呼出しチェーン全体が、システム全体のソフトウェアまたはハードウェア照合（または、認証）動作等の手段を利用する必要なく、そのセキュアな実行に先立って照合可能である。タイムスタンプレジスタに関して上述の場合のように、ある実施形態では、この「セキュア化モード有効化」ビットは、プロセッサに対して構造上可視であってもよく、またはそうでなくてもよいが、その状態は、プロセッサによって、明示的に設定されなくてもよいことに留意されたい。このハードウェアビットは、非セキュア化コードセグメントを読み出すことによって、デフォルト値にリセットされ得るが、一実施形態では、このビットが設定可能な唯一の態様は、ハードウェアの一部への直接作用を介してである。ビットが、構造上可視である場合、プロセッサが、セキュア化実行モードで動作中であるかどうかを明示的に決定可能である。構造上可視ではない場合、それでもなお、決定は、その値がハードウェア秘密キーに何らかの形で依存する何らかの式を評価することによって、黙示的に可能である。

ここで、コード実行の制御およびセキュリティプロトコルの実装と密接な関係があり得る、主題に内在する基本的問題について、さらに詳細に説明することは、有用となるであろう。次いで、上述のハードウェアの実施形態を使用して、任意の汎用プロセッサ上の任意コードの実行の制御をどのように実装するか、ならびにこれらのシステムおよび方法の実施形態が、どのようにセキュリティプロトコルおよびシステムと効果的に併用され、効果的セキュリティシステム全体を構築し得るかを示すことが可能となる。

（秘密キーの隠蔽）
市販のデジタルコンテンツ送達システムの大部分は、デジタルメディアデータが自由に複製および配信されることを保護しようとする、ある形式の暗号化またはデータ隠蔽を含む。大部分の場合、データ隠蔽戦略は、最終的には、コンテンツ保護の完全に非効果的な手段であることがわかる。この隠蔽が不成功であることがわかる主要な理由の１つは、曝露から保護されるべきまさにそのデータが、それでもなお、任意の承認された当事者による使用に対して自由に利用可能でなければならないことである。したがって、一見矛盾した要件集合が、デジタルコンテンツの配信には存在する。

オリジナルデジタルコンテンツが、意図された受信者すべてに対して、別個に暗号化可能であって、意図された受信者のみが、配信されたデジタルコンテンツを利用し得る場合、システムのセキュリティは、潜在的に、非常に優れたものとなることが可能である。しかしながら、いくつかの特有の条件が合致しない限り、この種類のシステムのセキュリティは、いくつかの点において、不完全があることが示され得る。第１に、そのようなシステムは、配信されたデータ集合全体が、各意図された受信者に対して、別個に再暗号化されなければならないことを必要とする点において、あまり効率的ではない。第２に、配信者は、汎用プロセッサ上において、いかなる未承認の復号化も不可能であることを保証する必要があり得る。第３に、各個々の受信デバイスが、別の終点デバイスにおいては容易に複製（または、汎用プロセッサ上でエミュレート）できない、ある属性を保有しなければならないという点において、一意的でなければならない。これらの最後の２つの条件のうちのいずれかが侵害される場合、このシステムは、個々に暗号化されたデータだけではなく、そのデータと関連付けられたデバイス特有のキーの両方を傍受することによって簡単に攻撃を受けやすくなる。

実際、そのようなシステムのセキュリティは、受信デバイスのそれぞれの一意的な属性のセキュリティに基づき得ることが分かる。この一意的な属性は、一般的には、配信者および承認受信者のみに知られている秘密キーを使用して実装される。原則として、この種類の設定は、効果的セキュリティシステムであり得るが、オリジナルデジタルコンテンツが、各受信者に対して別個に暗号化されるという要件は、大部分の目的に対して現実の実装を非実用的にする。オリジナルデジタルコンテンツが一度暗号化され、潜在的に承認された当事者すべてに完全に同じように配信されることが望ましいならば、問題はデータ隠蔽へと逆戻りする。これらの種類の問題は、ブロードキャスト暗号化の分野として知られている。

ほとんどのあらゆる種類の配信された秘密データシステムが有する基礎的問題の１つは、大部分の場合、セキュリティシステムの別個のエンティティ間を行き来するメッセージおよびデータがすべて、通常、公に伝送され、したがって、盗聴者によって観察可能であることである。したがって、そのようなシステムの個々の構成要素間で伝送される、任意のメッセージまたはデータは、暗号化され、未承認当事者による傍受に対して保護されなければならない。そのようなシステムにおいて対処されなければならない別の問題は、任意のそのような秘密データ伝送において、送信者だけではなく、受信者の両方の身元の照合である。２人の当事者が相互に知らない場合、相互に信頼される媒介戦略が、一般的に採用される。

しかしながら、加えて、秘密データがその宛先に到達したときに対処されなければならない同様に困難な問題は、危殆化されない態様において、その秘密データをどのようにセキュアに使用するかである。この予防措置は、通常、合法的な終点であっても、それに偽情報を提供することによって、セキュリティを傷つけられ得る可能性があるので必要である。したがって、配信の際の未承認発見に対する保護に加え、時として、その他の点では承認されているユーザによってその秘密データが発見されることから、秘密データを保護することが望ましい。

一実施形態では、そのような望ましい制御は、構造上隠蔽されている秘密キーの単純な時間依存的な使用、または実行に先立ってリアルタイムで復号化されなければならない暗号化オブジェクトコードブロックを利用して、実装されてもよい。前者の場合、コードブロック実行は、制御メカニズムに対して完全に透明であり得、実行速度が最小の影響を受けるはずであることを意味する。後者の場合、作動されるコードブロックは、実行に先立って復号化されてもよく、したがって、復号化プロセスの呼出し時間に起因する性能の同時損失の可能性が最も高い。しかしながら、この後者の場合、オブジェクトコードは、分解されるおそれが比較的なく、したがって、潜在的に、可能性のある攻撃者による妨害はより困難である。後に本明細書において論じられる実施形態は、高度にセキュアな暗号化されたオブジェクトコードの方法から、比較的高度な性能であるが、それでもなお、依然として非常にセキュアな選択的に利用可能な秘密キーの方法に及ぶ、一連の可能性のある解決策において実装可能なシステムおよび方法を開示する。

一実施形態では、そのような秘密キーのユーザからの秘密キーの隠蔽は、ハーバードアーキテクチャメモリ空間分岐に類似する方法で達成されてもよい。しかしながら、本実施形態では、秘密キーが、暗号化／復号化計算において使用されてもよいが、プロセッサによって実際に直接読み取られることが決してないように区別がなされ得る。この区別は、ハードウェア内に実装されたもの、またはハードウェアの設計時に定められた所定のソフトウェアマクロ（また、マイクロコードとしても知られる）に、暗号化／復号化動作を限定することによって実施されてもよい。例えば、ハードウェア秘密キーが、任意のコードによって使用され得る場合、プロセッサによって直接読取り可能でない場合でも、それでもなお、単純計算によって容易に決定可能である。したがって、セキュリティ関連計算のみ、ハードウェア秘密キーにアクセスし、そのようなコードセグメントをより汎用的ではあるが、あまりセキュアではないコードブロックから差別化し得るように規定することが望ましいであろう。

この区別は、ある実施形態では、この明細書に説明されるものに本質的に類似する照合方法を利用して達成されてもよい。上述の適応デジタル署名方法の実施形態が、ハードウェア秘密キーがアクセスされ得るかどうかを決定するために利用される場合、標的プロセッサが、セキュリティ関連計算（すなわち、標的プロセッサが、「セキュア化実行」モードで動作時に行われる計算）およびセキュア化されていないものを実行中であるかどうかを容易かつ確実に決定可能である。加えて、上述のものに実質的に類似する再帰的方法を利用して、最終計算が完了し、完全に復号化された結果が報告されるまで、任意の中間キー結果が発見されないように隠蔽されてもよい。したがって、本明細書に説明される実施形態は、同一ビットストリームを発生させるために使用される、秘密グローバルキーを曝露することなく、暗号化されたデジタルビットストリームを復号化する能力を有してもよい。

（コード実行の制御）
特定のコードセグメントが、所与のプロセッサにおいてセキュアに実行されることを保証するための方法は、長年、広範囲に研究されている。セキュアなコード実行の保護をもたらすための以前の試みのいくつかとして、「特権的」命令集合を確立するために、プロセッサアーキテクチャに書換えを行うことが挙げられる。これらの特権的命令は、プロセッサが「監視者」または「カーネル」モードとして知られる、特定のモードで作動中にのみ、これらの特権的命令が実行可能であるようにアーキテクチャを設計することによってセキュア化されていた。この種類のプロセッサアーキテクチャの分岐は、プロセッサの汎用性の潜在的損失だけではなく、潜在的性能の劣化を含むいくつかの欠点を有する。これらの欠点に加え、そのような保護手段は、多くの場合、プロセッサが監視者モードで実行中、想定外の実行パスを利用するように、標準システムルーチンに対して、特異的に設計されたソフトウェア読み出しを使用することによって迂回可能である。そのような特異的に設計されたマルウェア攻撃の例として、いわゆる「スタックオーバーフロー」、「スタックオーバーラン」、および「コードインジェクション」攻撃が挙げられる。

これらの種類のセキュリティ上の弱点に対する保護を支援するための試みにおいて、主に、チェックサム照合または引数上下限検査の種々の手段に基づいて、いくつかの戦略が考案されている。これらの種類の保護手段にもかかわらず、多形性ウイルス（すなわち、自己書換えコード）を含む、種々の対対抗手段が進化している。上下限検査にもかかわらず、プロセッサの脆弱性を悪用するための別の戦略として、上下限検査「監視者」ルーチン自体を単純に迂回することが挙げられる。また、この種類の搾取は、種々のコピー保護システムを回避する際に、頻繁に使用される。結局、監視ルーチンを奪取する戦略は、コンピュータセキュリティの世界にとって一意的ではなく、全く新しい概念ではない。実際、正にこの問題は、種々の用途において類似点を有し、Ｐｌａｔｏの文献「Ｔｈｅ Ｒｅｐｕｂｌｉｃ」にまで遡って参照されている。基本的問題は、任意の所与のシステムにおいて、最終的なセキュリティまたは構造の安定性が委ねられるある種類のグローバルな監視者を常に識別可能であることである。あらゆる後続のセキュリティ機能に対するグローバルな基礎についてのそのような概念は、「Ｒｏｏｔ−ｏｆ−Ｔｒｕｓｔ（信頼の基点）」として、セキュリティシステムの最新の研究において知られている。

より最近では、プロセッサが、本質的に読取り専用である命令をそこから取り出すメモリセグメントを制限することによって、プロセッサを監視ルーチン攻撃から保護する試みがなされている（これは、いわゆるＷ＾Ｘまたは「ｗｒｉｔｅ−ＸＯＲ−ｅｘｅｃｕｔｅ」アプローチを含む）。データベースのパーティションと、コードベースのパーティションとに、その他の点では汎用であるコンピュータのメモリ空間を分割する概念は、いわゆる「Ｈａｒｖａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ハーバードアーキテクチャ）」の変形例として示され得る。この方法は、保護メカニズムだけではなく、メモリ利用の同時増加と関連付けられたある性能に不利な条件を有する。最後に、最近、これらの種類の防護でさえも、いわゆる「戻り値ベース」のプログラミングのセキュリティ上の弱点の使用によって、または２つの別個の実行スレッドが、異なるモード（一方は、「データモード」、他方は、「実行モード」）において、メモリの同一ブロックを参照可能である、単純なメモリ−エイリアシングのセキュリティ上の弱点によってさえ回避可能であることも示されている。

プロセッサの実行スレッドが奪取されることを保護する別の提案される手段として、暗号化されたコードブロックの使用が挙げられる。この方法では、実行されるコードセグメントは事前に暗号化され、したがって、プロセッサへのそれらのロードの前には読取り不可能である（おそらく、さらにより重要なこととして、改ざん不可能である）。また、この方法は、いくつかの脆弱性を有する。第１に、コードセグメント自体が、保護され得るが、引数は、必ずしも同一レベルのセキュリティを備えていない。したがって、完全に合法かつセキュアなコードセグメントは、それでもなお、予想外の方式で挙動させることが可能な、その呼出しルーチンからの偽引数を備え得る。第２に、ある場合には、実行スレッドは、必ずしも、上述の戻り値ベースのプログラミング攻撃に対して保護されていない。また、プロセッサバスが、攻撃者によって容易に観察可能である場合、正確に実行される（暗号化されていても）コードセグメントの長期観察だけではなく、実行可能ストリームに投入される不適切に暗号化されたコードセグメントによって生じる例外欠陥の観察が、書き換えられた辞書攻撃方法を使用して、暗号化キーを明らかにすることに有用となり得る。最後に、そのようなシステムにおけるプロセッサ性能は、必然的に、類似するが、暗号化されていないコードシステムよりも大きく低下させられる。この性能上の不利な条件は、いくつかの問題によって生じ得、その最も重要なものは、メモリから取り出されるときと、実行されるために利用可能となるときとの間のコードブロックの必須復号化によって被る待ち時間である。最新のプロセッサは、パイプライン方式メカニズムを使用して、並行して実行可能な命令の数を増加させようとするが（種々の手段によって）、暗号化されたコードのブロックは、最初に復号化されるまで、そのようなパイプラインに読み込まれることは不可能である。コードが頻繁に分岐する場合、復号化プロセスは、潜在的に、ハードウェア支援復号化によってさえ、コード実行自体よりもさらに時間がかかり得る。

本発明に説明されるシステムおよび方法の実施形態は、非暗号化コードブロックの利用を可能にし得、したがって、暗号化された実行ファイルと関連付けられた性能上の不利な条件は、あまり問題とならない。しかしながら、実行効率が重大な懸念ではない場合、暗号化されたコードブロックが、依然として利用されてもよい。したがって、本明細書に開示される実施形態は、プレーンテキスト実行ファイルの効率だけではなく、同一または類似の方法およびシステムを利用して、暗号化されたコードセグメントの追加のセキュリティの両方を有し得る。加えて、本明細書に説明されるセキュリティシステムおよび方法の実施形態は、その場でアップデートされ、新しく発見されたセキュリティ上の懸念を解決するだけではなく、実施形態が既に配備された後においても新しい機能を追加することが可能である。

本発明の実施形態は、とりわけ、「セキュア化コードセグメント」が、暗号学的ハッシュ関数によって、実行に先立って照合されることを保証することによって、これらの利点を成就し得る。この照合は、例えば、そのようなセキュア化コードセグメントのために生成されたメッセージダイジェストまたはデジタル署名を認証することによって達成されてもよい。この暗号学的ハッシュ関数の評価が、デジタル署名を形成するために、上述のように、複合キー構造を使用して、結果として生じるメッセージダイジェストの暗号化と併せて生じる場合、特定のコードブロックは、特有の標的ユニットまたはプロセッサと一意的に関連付けられることが可能である。このプロセスは、ある実施形態において、このセキュア化コードブロックが、デジタル署名に基づく複合キーを使用して、特定の標的ユニットに暗号学的に結合することが可能であるという事実に基づいて、本明細書では、「セキュア化コード結合」と呼ばれる。

そのようなハッシュ関数の実行は、リソースフリーであってもよいが、このアプローチの利点は、セキュア化コードセグメントが、その暗号学的照合の完了の前に、実行パイプラインに導入可能であることである。したがって、ハッシュ関数は、潜在的に、セキュア化コードセグメント自体の実行と並行して評価可能である（推論的分岐実行に類似する方式において）。この実施形態では、セキュア化コードセグメントの結果は、結果として生じるメッセージダイジェストが本物であると決定される場合にのみ利用されてもよい。しかしながら、別の実施形態では、セキュア化コードセグメントの結果は、後続の動作において利用されてもよいが、結果自体が、プロセッサがセキュア化実行モードで動作しているかどうかに応じて、異なってもよい。この実施形態は、デジタル署名において使用するための複合キーの評価に関して上述のプロセスに実質的に類似し、図３６に図示されるようなハードウェアの使用によって生成することが可能である。

しかしながら、暗号学的照合の使用は、暗号化されたコードセグメントの使用を妨げるものではない。実際、正確に復号化されたコード（任意の種類の暗号化を適用する前のそのオリジナル状態において、セキュア化されているコードセグメント）のメッセージダイジェストまたはデジタル署名の使用は、付加的レベルの保護を提供し得る。これは、潜在的な攻撃者が、偽造メッセージダイジェストを生成するためには、正確に復号化されたコードブロックの演繹的知識を有する必要があるだろうという事実によるものである。したがって、コードセグメント照合だけではなく、暗号化されたコード方法の両方が同時に使用可能である場合に、攻撃に対してより高いロバスト性が実現され得る。

しかしながら、また、理解され得るように、そのようなハッシュ照合を迂回可能ないくつかの方法が存在し、その最も単純なものは、ハッシュ関数自体を妨害することであろう。この戦略が、ある実施形態について不可能であることが想定される場合でも（例えば、ハードウェアハッシュ関数を利用することについて）、適切に照合されたメッセージダイジェストとともに偽りのコードセグメントを提供することによって、依然として、そのような実施形態のセキュリティを攻撃することが可能であり得る。多くのメッセージダイジェストは、実際に、暗号化され、デジタル署名を形成するので、表面上、この攻撃戦略は、一見、困難であることがわかるであろう。しかしながら、デジタル署名メカニズムでさえ、デジタル署名の公開キー検索部分をスプーフィングし、したがって、偽りのデジタル署名の人為的照合を提供することによって、または代替として、署名照合ルーチン自体の悪質な破壊によって、潜在的に攻撃され得る。

これらの制限は、セキュア化コードセグメントと関連付けられたメッセージダイジェストを二重に暗号化することによって、本明細書に開示されるシステムおよび方法の実施形態において克服される（一度目は、（グローバルな）「著者の」秘密キーによって、次いで、再度、終点「製造業者」（実際には、オリジナルチップ製造業者ではなく、二次レベルの配信者、システムインテグレータ、サービスプロバイダ等であり得る）および当該コードセグメントが実行される特定の終点デバイスにのみ知られている秘密キーによって）。この実施形態の利点は、上述のデジタル署名が、類似した終点デバイス間で共有される場合でも、異なる標的ユニットの秘密キーが異なるので、その意図された標的ユニットにおいてのみ正確に機能することである。したがって、任意のそのようなデジタル署名は、暗号化されていない状態で伝送かつ格納可能である。

秘密キーを二重に暗号化する技術（いわゆる「階層化キー」システムだけではなく、再帰的セキュリティシステムにおいても使用され得る）の実施形態は、不正確に使用される場合、ある問題を有し得る。第１に、そのような階層化暗号化プロセスの中間結果が傍受されると、この中間キーを使用してそのようなシステムの一部または全部のより高いレベルのセキュリティを迂回可能である。また、そのような階層化システムの「最下層」においては、この中間結果が、実際に発見されると実質的に類似した終点デバイスすべてに対するセキュリティシステム全体を迂回するために使用可能である「グローバル」復号化キーであることに留意されたい。この種類の「傍受」攻撃が、復号化プロセスの際に、任意のメモリトランザクションを単に注視し、次いで、潜在的グローバル復号化キーのそのような記憶場所すべてを検証することによって、１回以上生じ得る。復号化プロセスの際のメモリアクセスすべてを注視するプロセスは、最初は、煩わしく思われ得るが、ほぼ確実に、そのような秘密キーの値の総当たりによる推測よりも効率的な攻撃戦略である。階層化キーシステムにおける第２の潜在的な脆弱性が、反射攻撃の改良型によって悪用可能である。階層化キーシステムのセキュリティが危殆化され、そのキーがアップデートされなければならない場合、古い（危殆化された）キーは、依然として、オリジナルシステムがその以前の状態にリセットされるとき、またはその以前の状態が、偽りのユニットによってクローン化されるとき、使用され得る。

これらの脆弱性は、「階層化キー」構造とは対照的に、「複合キー」と呼ばれるものを使用して、本明細書に論じられる実施形態において解決され得る。複合キーと階層化キーとの間の主要な相違の１つは、前者のセグメントがすべて単一モノリシックパスにおいて評価され得ることである。対照的に、階層化キーシステムでは、「最外」層キーを最初に評価することが可能であって、次の最内キー（これは、次に、引数として使用され、キースタック全体がトラバースされるまで次の層のキーを生成する）に戻る。このシステムに伴う問題は、より低いレベルのキーが傍受かつ後に使用され、効果的に最外セキュリティ層を迂回可能であることである。したがって、そのような階層化キー実施形態においては、最も重要な（この場合、グローバル）キーは、チェーン内において最後に生成され、使用されるものであって、ここにおいて、任意の付加的な（または、より新しい）層のセキュリティは完全に欠如している。

この理由から、そのようなセキュリティスタックをトラバースするためのよりロバストな方法が利用されて、「インサイドアウト」からトラバースされ得る。これは、セキュリティチェーンへの最も新しい追加物が、順序通り最初に実行されるが、実際は、セキュリティシステムの最内層に位置するものであることを意味する。故に、実施形態を使用して、そのような「インサイドアウト」の実行順序が実施され得る。この特定のコードスタックトラバーサルの順序は、単純反復アプローチを使用して達成可能であって、そこでは、コードループは、最初に現在のセキュリティレベルを評価し、次いで、それに従って、分岐する。しかしながら、反復方法では、セキュリティシステムトラバーサルの中間結果は、上述のように、攻撃者が、次のより低いレベルのキーが合法セキュリティシステムトラバーサルにおいて曝露されることを単に待機し、次いで、その傍受したキーを使用して、システムの偽造「初期」バージョンをクローン化し得るので、潜在的に、迂回可能である。したがって、システムおよび方法の実施形態は、この「インサイドアウト」実行順序を実施するだけではなく、また、中間結果が悪質なコードまたは他の周知のセキュリティシステムのセキュリティ上の弱点によって傍受されることから保護可能であるように説明される。

そのような「インサイドアウト」セキュリティアプローチを使用する場合の別の主要利点は、呼出し引数のシーケンス全体が、セキュリティシステムの最内層（したがって、最も新しいバージョン）に対して可視であり得ることである。この「インサイドアウト」実行シーケンスが、適切に実装される場合、そのようなシステムで採用される正確に構築された上下限検査メカニズムが、呼出しチェーン全体にわたって可視性を有し得ることが分かる。したがって、実施形態は、通常、そのような機能と関連付けられる任意の付加的性能上の不利な条件を被ることなく、相当量のシステム認証機能を行うための組込メカニズムを有してもよい。

故に、ある実施形態は、中間キーがより高いレベルの（したがって、あまりセキュアではない）セキュリティシステムルーチンに曝露されることを防止するだけではなく、適切なセキュリティスタックトラバーサル方法を保証するための手段を利用してもよい。これを達成するためのそのような方法の１つは、再帰的セキュリティ構造の使用であって、その一実施形態は、２００３年６月１９日に出願され、その後、２００７年４月１０日に米国特許出願公開第７，２０３，８４４号として発行されている、Ｗｉｌｌｉａｍ Ｖ． Ｏｘｆｏｒｄによる米国特許出願公開第１０／４６５，２７４号「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ ａ Ｒｅｃｕｒｓｉｖｅ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｄｉｇｉｔａｌ Ｃｏｐｙｒｉｇｈｔ Ｃｏｎｔｒｏｌ」に図示されており、あらゆる目的のために、参照することによって本明細書に組み込まれる。

そのような再帰的セキュリティプロトコルの実施形態が利用される場合、ある利点が実現され得る。第１に、スタック順序トラバーサルは、「インサイドアウト」から評価されなければならないように設計可能である。これは、最も新しいセキュリティシステムの追加が、最初に実行され、システムは、「途中から開始」不可能であることを意味する（例えば、「戻り値ベース」のプログラミングのセキュリティ上の弱点において使用されるように）。再帰的システムの第２の利点は、セキュリティシステムへの任意のアップデートの追加が、セキュリティシステム自体において、オリジナル呼出し引数を変更できないことである。故に、従来のリプレーベースの攻撃メカニズムを使用することによって、セキュリティシステムをスプーフィングすることはより困難となり得る。本明細書に開示される実施形態の場合、反復方式において、逆の順序でインライン実行スタックを採用することが確実に可能であるが、反復メカニズムは、割り込みを受け得、したがって、また、セキュリティスタックの部分的評価が行われる環境をもたらすことも可能であり得る。これは、潜在的に、外部観察者によって、１つ以上の中間結果が傍受されることを可能にするであろう。本明細書の実施形態によって利用され得るように、再帰を介して実装されるインサイドアウトセキュリティシステムでは、中間結果は、引数として、任意の時点において、次のレベルのルーチンにパス不可能であって、現在実行されているセキュリティシステム層の最終結果のみが、セキュリティシステムスタックの次の上位レベルで利用可能である。

また、複合キー構造は、ある実施形態では、標的ユニットの秘密キーへのアクセスを厳密に制御することによって、部分的評価から保護されてもよい。例えば、秘密キーが、構造上可視ではないアクセス不可能な記憶場所内に格納されている場合、特定のセキュリティ関連命令または機能の一部としてのみアクセスされてもよい。ある実施形態では、この機能または命令は、非自明な一方向変換等、容易に反転され得ないものである。そうすることによって、偽造セキュリティシステムさえ、秘密キーの値を明らかにすることが不可能であるはずである。その結果、一方向機能の一部として、秘密キーを間接的に参照のみさせることによって、秘密キーは、数学的動作の一部として、それ自体では決して使用可能ではなく、単独で、またはある別のデータとともに、ハッシュ動作の一部としてのみ使用可能であって、そこでは、ハッシュ関数の結果のみが観察可能であり得るので、秘密キーは保護され得る。

また、秘密キーを保護するための付加的メカニズムが、ある実施形態では、有用であることがわかり得る。そのような潜在的メカニズムの１つは、複合キーの使用であって、そこでは、標的ユニットの秘密キーは、ある別の制約または付加的オペランド集合に厳密に結合される。そのような二次オペランドの例として、別個の秘密キー、グローバル的可視レジスタ（タイムスタンプまたはシステムバージョン番号等）、秘密キーにアクセスするコードのメッセージダイジェスト等を含んでもよい。そのようなシステムの実施形態では、この最後の例は、秘密キーが、その全く同一キーを使用するために承認される、コードのセグメントによってのみアクセスされてもよいことを保証し得る。さらに、メッセージダイジェストが暗号化され、デジタル署名を形成する場合、かつそのメッセージダイジェストを暗号化するために使用されるキーが、秘密キー自体である場合、秘密キーにアクセスする唯一の方法が、その秘密キーが何であったかを既に知っている者によって作成されたコードセグメントを使用することであることを保証可能なように、依存性の循環を生成することが可能である。

この場合、複合キー構造の使用は、そのキーを使用可能にする前に、標的ユニットの秘密キーの使用を要求する、コードの一部の「権限」を照合させる。「階層化キー」構造と「複合キー」構造との間の差異は、ある実施形態においては、後者は、それ自体が再帰的手段によって達成可能である解剖学的方式で評価され得ることであることを思い起こされたい。再帰的構造とは対照的に、反復アプローチを使用して類似構造のアセンブルを試みる場合、キー評価プロセスの中間結果を曝露する（したがって、潜在的に、秘密キーを曝露する）危険性があり得る。この「曝露」は、秘密キー（または、それらの原体）が、割り込みが生じるとメインメモリに押し出される、汎用レジスタ等の公的に利用可能な場所に格納されるときに（または、直接メモリ自体内でさえ）生じ得る。

ある実施形態において解決され得る潜在的セキュリティの崩壊は、セキュリティスタック動作が、評価中に割り込まれ、次いで、標的ユニットのプロセッサの状態が、外部観察者によって検証を受けやすいメインメモリに書き出されるときの部分的結果の保護である。一実施形態では、このメモリ「曝露」を防止するために、プロセッサがセキュア化実行モードにある間、ヒーププッシュは拒否される。その条件が実施される場合、再帰的セキュリティプロトコルは、その現在の状態を損失することなく、割り込みは不可能である（中間引数が存在しないため）。再帰的セキュリティプロトコルの実施形態では、セキュリティプロトコル全体は、再帰が終了し、プロセッサがセキュア化実行モードで作動しているときにトラバースされ、したがって、割り込み以外のいかなる場合でも、ヒープへの任意の引数のさらなるプッシュは存在し得ないことに留意されたい。したがって、複合キー評価が、任意の時点で割り込まれる場合、かつ、ヒーププッシュがセキュア化実行モードにおいて拒否される場合、セキュリティシステムスタックトラバーサルは、実行中に再開できない（すなわち、計算は、最初から再開しなければならない）。したがって、再帰的セキュリティプロトコルは、任意の中間結果がシステムヒープ上に格納される（したがって、潜在的に、未承認観察者に曝露される）ことを防止するように使用可能である。当然ながら、ある実施形態では、反復セキュリティシステム評価の際、ヒープ動作を無効にすることが可能であって、したがって、効果的に、そのような割り込されたセキュリティシステム動作が、最初から再開されなければならないことを要求する。しかしながら、そのような反復アプローチは、「インサイドアウト」実行順序、「戻り値ベースの」プログラミングのセキュリティ上の弱点に対する保護、オリジナル機能に対して、呼出し引数を改善しないように、後続のセキュリティ層に追加する能力だけではなく、中間結果および最終機能出力結果の隔離等、再帰的構造が提供する条件のすべてを施行しない場合がある。セキュリティシステム再帰が終了し、プロセッサがセキュア化実行モードに入ることが許可されるメカニズムについては、より詳細に後述される。

（再帰の終了）
一実施形態では、再帰は、所与のコードセグメントのメッセージダイジェストが、コードセグメント自体とともに供給されたものと整合すると、終了するように信号伝達可能である。この方法論は、メッセージダイジェストが、ハードウェアハッシュ関数によって計算される場合、攻撃に対してよりロバストになり得る。また、ある実施形態では、デジタル署名が利用されてもよい。デジタル署名メカニズムは、１）コードセグメントが改ざんされていないことの保証と、２）コードセグメント著者の即時識別の少なくとも２つの主要属性を提供する潜在性を有する。しかしながら、そのようなデジタル署名が、公的に可視または書換え可能場所にキャッシュされる実施形態の場合、デジタル署名自体が、任意の時間に書き換えられ、したがって、必ずしも、本物ではない可能性があるので、付加的セキュリティが望ましいであろう。したがって、これらの種類の実施形態においては、公開キーシステムを使用して、デジタル署名を照合してもよく、または複合キー構造（上述のように）を使用して、当該コードセグメントを備えるデジタル署名が、標的ユニットの秘密キーを所有していたある当事者によって作成されていることを保証してもよい。後者の場合、また、複合キーの使用は、単一終点またはある終点集合に限定されてもよい。加えて、公開キーだけではなく、複合キーアプローチの両方を併用してもよい。その態様では、コードセグメントが本物であることだけではなく、コードセグメントが複合デジタル署名の受信者のために意図されたものであることの両方を保証可能である。

また、ある実施形態においては、標的ユニット上のセキュリティメカニズムを照合することが望ましいであろう。標的デバイス上のセキュリティシステムの任意の１つのセグメントに対して、ハードウェア生成デジタル署名が利用されてもよいが、セキュリティシステムが再帰的である場合、個別デジタル署名が、セキュリティシステム自体がトラバースされることに伴って、実質的に、自動的に生成され得る。上述のように、再帰的セキュリティプロトコルの実行が終了すると、呼出しチェーン全体が曝露される。したがって、セキュリティプロトコルの最内（したがって、最も新しい）部分は、潜在的に、スタック上に格納された呼出し引数だけではなく、システムヒープ（または、さらにメモリ内のいずれかの場所）内に格納される別の環境変数を含む、呼び出される環境全体へのアクセスを有する。この組込システム認証メカニズムは、特に、セキュリティプロトコル自体のトラバーサルと同時に評価されるので、効率的であるだけではなく、攻撃に対してロバストである。

一実施形態においては、次いで、セキュリティシステムスタックトラバーサルの「実行段階」の前に導入されていなければならない条件集合が、規定され得る。一実施形態では、これらの条件は、個々に要求されるセキュリティ条件のすべての「共通集合」として表現可能である。そうすることによって、新しいセキュリティの危険性が発見されるとき、それらの危険性を考慮する付加的条件が、容易に導入され得る。これらの条件は、セキュリティシステムのいかなる部分も、新しいのも、古いのも、条件すべてが合致するまで、実行されないように保証可能である。種々のセキュリティシステム条件のこの「共通集合」は、上述のように、複合キー構造メカニズムの使用を通して達成可能である。例えば、そのような複合キー構造の構成要素の１つが、部分的に、標的ユニットの秘密キーに基づく場合、この秘密キーは、セキュリティシステム全体の「信頼の基点」の１つとしてみなされ得る。さらに、ハードウェアベースのタイムスタンプメカニズムが、複合キーの他の構成要素の１つとして利用される場合、システムは、反射攻撃に対してより保護され得る。ある実施形態では、他の条件を実施するために、上述に加え、ある実施形態において採用され得るいくつかの構成要素が存在する。そのような構成要素は、コードが改ざんされている場合、キーを適切に評価されることを防止するために、複合キーの一部として、コードブロックのメッセージダイジェストのハードウェアベースのハッシュ計算の使用を含む。一実施形態では、別のそのような構成要素は、スタックオーバーフロー型攻撃に対して保護し得る、実行されるコードブロックの呼出し引数のある選択されたサブ集合のデジタル署名であってもよい。

コードセグメントが、タイムスタンプまたは使用関連制限等、その実行に関する他の制約を有する場合、ある実施形態においては、さらなる条件が複合デジタル署名に追加され、それらの制約もまた適切に実施されていることを保証することが可能である。また、この同一メカニズムを使用して、中間セキュリティトークンの正確な評価に基づいて、システムの各層内で適切なコード分岐を実施することによって、種々のセキュリティスタック層を通して、特有の複数の反復を強いることが可能であることに留意されたい。

上述のように、再帰的セキュリティシステムの実施形態は、条件のすべてが、セキュリティトークンの評価開始に先立って導入されていることを保証することが望ましいある実施形態において、有利である。したがって、インサイドアウトセキュリティスタックトラバーサルを実施するその能力および中間結果の可視性に関する制限を有する再帰的システムは、最小に破壊的な方式において、セキュリティシステム評価に関してより制約を追加することが望ましいとき、外部攻撃に対する向上したロバスト性だけではなく、融通性を提供することが可能である。

ここでは、セキュリティシステムスタックの再帰的トラバーサルは、必ずしも、アルゴリズム的フロー全体に対する再帰的形式と等しいわけではないことに留意されたい。したがって、セキュリティシステムの論理的フローおよびシステムのセキュリティシステムを利用するコードスレッドの論理的フローは、完全に異なってもよい。

加えて、ある実施形態では、特定のコードセグメントが解析されることに伴って、デジタル署名がどのように書き換えられるかを規定する機能集合を含むことによって、デジタル署名がどのように使用されるかの融通性が向上させられ得る。例えば、コードセグメントが、第１の反復後、デジタル署名を不変のまま解析プロセスを通過させる場合、そのコードセグメントは、セキュリティシステムが何回特定のコードブロックを循環するかを事前に規定する必要なく、照合可能である。同様に、デジタル署名は、特定のコードセグメントに直面することに伴って、既知の「シード」状態にリセットされるように規定可能である。したがって、単に、単一の一意的数（暗号化されていない状態で格納可能）を供給することによって、セキュリティシステムの種々の部分が、何回およびどの順序でトラバースされるかの一意的変動が、規定されてもよい。実際、そのようなコード照合プロセスを使用して、種々の有用な機能を実装可能であって、したがって、この技術は、必ずしも、セキュリティシステム自体の排他的使用に限定される必要はない。

適切なデジタル署名が、一般的コード（セキュリティの実装に関連し得る、またはし得ないコード）を備える場合、コードのその特定のブロックが、特有の標的ユニット上で実行される態様は、非常に特異的に制御されてもよい。これは、一般的コードを標的デバイス集合にセキュアに分配するために使用可能な、非常に強力なメカニズムである。この分配方法は、例えば、効果的にアプリケーションへの無料または有料アップグレードに、またはソフトウェアウイルスおよび他の望ましくないマルウェアの拡散を管理するために効果的に適用されてもよい。この後者の実施形態では、再帰的セキュリティシステムを使用して、標的デバイス上での実行のための候補であるあらゆるコードブロックを照合可能である。したがって、マルウェアアプリケーションまたは以前に認証されたコードセグメント上の多形性ウイルス攻撃さえ実行が防止され得る。

ハードウェア依存性をセキュリティシステム評価に組み込む能力を提供するために、ある実施形態においては、ハードウェア実装バージョン番号が、デジタル署名評価の複合構成要素の１つとして利用されてもよい。セキュリティシステムが書き換えられる度に、ハードウェアバージョン番号が、アップデートされる場合（かつ、そのアップデートがセキュアである場合）、セキュリティシステムが、実行されている標的ユニットと整合されることを保証することが可能である。これは、上述のタイムスタンプメカニズムと異なるが、複合キー評価において、２つを併用し、反射攻撃シナリオまたは他の侵害に対して保護し得ることに留意されたい。

例えば、我々の複合キー構造の一部として、ＪＴＡＧ署名等のハードウェア導出チェックサムを使用する場合、ハードウェア実装自体が認証されてもよい。次いで、この種類のメカニズムは、ソフトウェアおよびハードウェアが整合された対であって、ハードウェアが本物である（または、改ざんされていない）ことを保証し得る。さらに、複合キー評価の一部として使用されるＪＴＡＧ署名が、直接観察可能ではない場合（例えば、その状態が、外的に可視でもなく、構造上可視でもない場合、スキャンチェーンのある時点から求められる）、ハードウェアのクローン化に基づく潜在的攻撃をマウントする困難性は、数倍も高まり得る。この戦略は、例えば、デバイスの個々の通し番号が、このスキャンチェーンに含まれる場合、効果的となり得る。

ここでは、プロセッサの観点から、本質的に、暗号化されたコードブロック（直接実行可能ではない）と「アップデートされていない」コードブロック（正確なデジタル署名整合を前提として、可能性として同時に実行可能であり得るが、そのデジタル署名は、もはや有効ではないので、もはや実行可能ではない）と間に論理的差異は存在し得ないことに留意されたい。このシナリオは、例えば、標的デバイスのタイムスタンプレジスタが変更されたため、または代替として標的デバイスのハードウェアがある未承認態様において書き換えられた場合に生じ得る。

したがって、特定のコードブロックが、アップデートされたバージョンと置換される場合（両方とも、潜在的に、実行可能であっても）、一実施形態では、これを達成するための単純ではあるが、さらに効果的方法は、最初に、当該コードブロックのための復号化キーポインタを、コードブロックの古いバージョンをアップデートされたバージョンと置換するための手段につながる新しいポインタと置換し、次いで、標的終点デバイスのタイムスタンプレジスタをアップデートすることであり得る。ここでは、アップデートされたタイムスタンプレジスタ値は、古い値を使用して生成された以前のデジタル署名すべてを無効にし、したがって、セキュリティシステム全体が更新され（理想的には、セキュアな態様において）、最新の状態にし、古いデジタル署名（または、キー）を新しいキー／デジタル署名値およびアップデートされた機能と置換することを伴い得る。これは、終点デバイスのタイムスタンプレジスタ内に格納された値への単一の変更によって容易に影響を受け得る、非常に強力な（かつ、潜在的に、非常に広範囲に及ぶ）メカニズムである。この場合、終点タイムスタンプレジスタ値が、非セキュアまたは無謀な態様において変更されないように注意を払う必要がある。そのような強制アップデートシナリオの一実施形態は、暗号化の層をその他の点では直接実行可能なコードブロックに追加する（単に、単一デジタル署名不整合を強いることによって）ことと論理的に同等とみなされ得る。

（セキュア化モードおよびセキュア化コード結合）
システムが、上述のように、構造上不可視である秘密キーの１つを利用する実施形態では、そのようなキーを利用するコードは、これらの秘密キーが危殆化されることを防止するように設計されなければならない。上述のように、セキュア化コード結合メカニズムを使用して未承認態様で使用される際に、特定の終点デバイスにおいてその他の点では合法であるコードブロックの正確な実行を防止可能である。

一実施形態では、このセキュア化コード結合は、特有の種類のハッシュ関数を候補コードセグメントに適用する結果が、コードセグメントが実行可能となる前に、そのコードセグメントを備えた特別に事前に決定されたメッセージダイジェストと整合しなければならないという要件に基づいている。このハッシュ関数は、候補コードセグメントが読み出された後、実行が可能となる前に適用されてもよい。このハッシュ関数が開始されると、候補コードセグメントを備える、その特定のメモリ空間へのいかなる書き込みも、無効化または無視され得る。候補コードセグメントが、ＣＰＵの命令キャッシュ内等のＣＰＵ実行ユニットと同一チップ上に位置する場合、これは、容易に実装され得る。しかしながら、マルチプロセッサシステムでは、例えば、Ｉ−キャッシュが、同一チップ上に存在する２つ以上のプロセッサ間に共有され得る場合、見た目ほど実装は単純ではないであろう。メッセージダイジェストが算出された後に、コードが書き換えら得ることを防止するための別の潜在的方法は、ハッシュ関数が開始された後に生じる、そのメモリ空間へのいかなる書き込みの試みも、プロセッサ割り込みを生じさせるように、システムを構成することである。上述のように、これは、プロセッサのセキュアな実行モードをそのデフォルトの初期「非セキュア」モードにリセットし得る。そのような侵入に対する別の対応は、例えば、メモリセグメンテーション違反を開始することによって、エラーによってセキュア化実行スレッドを決定させることであろう。

候補コードセグメントの計算されたメッセージダイジェストが、候補コードセグメントとともに受信した事前に決定されたメッセージダイジェストと整合する場合、候補コードセグメントは、「セキュア化モード」または「セキュア化実行モード」と呼ばれるもので実行可能となる。上述のように、セキュア化モードで動作中のコードのみ、構造上不可視の秘密キーを利用可能である。特定のコードセグメントが、セキュア化モードで動作していない場合、秘密キーは、無効化され、それらの１つに対する任意の参照は、ある他の値（ゼロ等）を返すであろう。

ある実施形態においては、候補コードセグメントのためのメッセージダイジェストを計算する差異に利用されるハッシュ関数は、ある特性を有し得る。第１の特性は、ハッシュ関数が、標的ユニットのハードウェア内に実装され得ることである。これは、この機能が、このオリジナルハードウェアハッシュ関数のある別の（おそらく破壊された）バージョンによって、完全に置換できないことを意味する。このハッシュ関数は、所望に応じて、オリジナル機能の改良バージョンによって補完（または、条件付き完全置換さえ）されてもよいことに留意されたい。一実施形態では、ハードウェアハッシュ関数を改良バージョンと置換する方法は、セキュリティシステムの構造の再帰的定義を介して新しい層をセキュリティシステム内に挿入するために使用される、上述の手順と実質的に類似するであろう。しかしながら、この場合、新しいハッシュ関数が、あらゆる後続のセキュリティシステム動作の目的のために、オリジナル機能を置換可能である場合でも、この新しいハッシュ関数自体は、依然として、その信頼の基点の基礎として、オリジナルハードウェアハッシュ関数に依存し得ることに留意されたい。したがって、用語「条件付き完全置換」が使用される。一実施形態では、オリジナルのハードウェアベースの信頼の基点は、一定のままであってもよい。これは、そのようなハードウェアベースのセキュリティシステムを攻撃することが非常に難しくなり得るという点において、望ましいであろう。しかしながら、オリジナルハードウェアハッシュ関数における欠点が、標的デバイスが現場に配備された後に見つかる場合、そのような欠点は、潜在的に、呼出し引数を効果的に制限可能な単一アプリケーション内においてオリジナルハッシュ関数を使用することによって含まれ得る。

ハードウェアハッシュ関数の第２の特性は、構造上不可視の秘密キーをそのシード値として使用し得ることである。したがって、同一入力引数を前提とする場合でも、そのようなハードウェアハッシュ関数のメッセージダイジェスト結果は、ユニット毎に異なり得る。この差異は、あらゆる標的ユニットに対して一意的なメッセージダイジェストをもたらし得るという点において活用されることが可能である。この特性は、デジタル署名の概念と類似するが、必ずしも、ハードウェアハッシュ関数に対して、別個の暗号化／復号化ブロックの追加を要求しない。次いで、候補コードセグメントは、ハードウェア生成メッセージダイジェストが、候補コードセグメントとともに分配されるものと整合するユニット上のみでの実行（少なくとも、セキュア化モードにおいて）に制約されるので、循環依存関係が生成される。この循環依存関係は、そのメッセージダイジェストが、正確な標的ユニットの秘密キーによって生成されたコードのみが、実際に、この同一秘密キーを利用可能であることを意味する。この特性は、標的デバイス上においてセキュア化モードで実行可能となるコードセグメントを生成する、可能性のある攻撃者の能力を実質的に損なわせる。

コードセグメントは、特定の標的デバイス（または、さらに特有の終点デバイス集合）に「結合」可能であるので、上述のメカニズムは、「セキュア化コード結合」と呼ばれる。上述のように、セキュア化コードの実行ブロックが割り込まれると、コンテキストは保存されず、したがって、このコードセグメントの実行は中止されるか、または最初から再開されなければならない。また、セキュア化モードにおけるコードセグメントの実行が割り込まれると、プロセッサは、もはやセキュア化モードで動作せず、構造上不可視の秘密キーへの任意のアクセスは、プロセッサがセキュア化モードに戻るまで、遮断され得る。また、ある実施形態においては、任意のオフチップ格納動作は、プロセッサがセキュア化モードで動作中は、制御されるか、または禁止され得る。

論じられるように、ある実施形態においては、各標的ユニットは、構造上不可視の一意的な秘密キー集合を有してもよい。しかしながら、別の実施形態においては、これらのキーのあるサブ集合が、いくつかの同等のデバイスに対して共通であってもよい。したがって、特定のコードセグメントは、キーの共通サブ集合によって、特定の種類の終点デバイスに結合可能である一方で、依然として、そのようなデバイス間で共通に保持される、この構造上不可視の秘密キー集合を保護する。したがって、ハードウェアハッシュ関数と１つ以上の構造上不可視の秘密キーの組み合わせは、高度に効果的かつロバストな再帰的セキュリティプロトコルのための信頼の連鎖の基礎を提供し得る。

次に、種々の実施形態の実装の詳細について、添付図面を使用して、さらに説明される。これらの例のすべてにおいて、用語「デジタルビットストリーム」とは、デジタルデータの一般的集合を指し、したがって、この用語は、デジタルコンテンツ、コードブロック、またはデジタルデータ集合等の用語と交換可能に使用されてもよいことに留意されたい。コードブロック用語の場合、参照データは、さらに、実行可能ファイル、実行可能スクリプト、あるいはアルゴリズム的記述または疑似コードのブロックさえ表すものと想定され得る。

図２４は、デジタルコンテンツのための複合キー作成の一実施形態を図示する。この複合キー２４１０、特定の終点デバイス（標的ユニット）と関連付けられた構造上不可視の秘密キー（上述のような）であり得る終点特有のハードウェアキー２４４０を利用して、暗号化エンジン２４２０をグローバルコンテンツキー２４３０（デジタルコンテンツの所有者または著者によって提供あるいは決定されてもよい）を適用することによって、作成されてもよい。特定の終点およびデジタルコンテンツの両方に特有である、結果として生じる複合キーは、複合キーが提供される終点デバイス上に伝送および格納され、そこに暗号化されていない状態で格納されてもよい。

図２５Ａは、セキュア化デジタルデータブロック構造の作成の一実施形態を図示する。この実施形態では、デジタルデータブロック２５１０は、暗号化されなくてもよいが、デジタル署名２５２０は、１つ以上のトークン２５４０または２５５０によって、デジタルデータブロックからのハッシュ関数２５３０によって計算されたメッセージダイジェストを暗号化することによって形成される。これらのトークンは、タイムスタンプ等の秘密キーまたは公的に利用可能なデータであってもよい。暗号化エンジン２５６０および２５６１を通過するデータを暗号化するために採用される方法は、同じであっても、またはそうでなくてもよいことに留意されたい。秘密キーが、暗号化キーの１つとして使用される場合、その秘密キー値の知識なく、デジタル署名を偽造することはより困難となり得る。また、暗号化動作２５６０および２５６１の順序は、結果のセキュリティ全体に関連しないが、結果として生じるデジタル署名２５２０は、動作の順序が変更されると異なるであろうことに留意することは有益である。

図２５Ｂは、セキュア化コードブロックデータ構造の作成の代替実施形態を図示する。この場合、秘密キー２５７０は、デジタルデータブロック２５７１に付加され、メッセージ２５８０全体を形成する。上述のように、この付加作用が、オリジナルデジタルデータ集合２５７１の前または後に秘密キー２５７０を置くかは、必ずしも、得られたセキュリティのロバスト性に関連しないが、順序が変更されると最終結果は異なるであろう。また、セキュリティを保証するために、秘密キー２５７０は、オリジナルデジタルデータ集合２５７１とともに公開されるべきであることに留意されたい。したがって、公開されるデータ集合は、データ構造２５８０全体ではなく、デジタルデータ集合２５７１だけに制限されるであろう。次いで、このデータ構造２５８０全体は、図２５Ａに関して上述のものと本質的に同一態様で、ハッシュ関数２５３０にかけられる。しかしながら、本実施形態では、最終出力４９０は、図２５Ａに示されるデジタル署名２５２０の特徴の多くを有するが、暗号化エンジン２５６０または２５６１の使用を必要とし得ない。したがって、この動作の結果２５９０は、デジタル署名同様のものと呼ばれるであろう。このデジタル署名同様のもの２５９０は、各一意的データ構造２５８０全体に対して、一意的である（ハッシュ関数２５３０が、適切に構築されていると想定して）ことに留意されたい。したがって、秘密キー２５７０が、デジタルデータ集合２５７１の著者およびそのデジタルデータ集合の消費者（終点デバイスまたは標的デバイス）によってのみ共有される場合、これらの２人の当事者のみが、同一の正確なデジタル署名同様のもの２５９０を再作成することが可能であるはずである。この場合、デジタルデータブロック２５７１は、その秘密キー２５７０（したがって、標的デバイス）に「結合」されているとみなされ得る。

図２６Ａは、本明細書に説明されるもの等のセキュリティシステムを使用して、どのように暗号化されたデータブロック２６１０を特有の復号化エンジンコードブロック２６６２に暗号学的に結合し、次いで、ハッシュ関数２６４０および暗号化エンジン２６６１によって計算されるデジタル署名２６２４を使用して、その組み合わせ２６３０を特有の終点のハードウェア秘密キー２６２３に結合し得るかの一実施形態を図示する。この例では、公開キー２６２２（グローバルコンテンツ秘密キー２６２０によって、復号化エンジンコードブロック２６６２のメッセージダイジェスト２６２１を暗号化することによって構築される）は、単一の連結されたデータ集合２６３０として、オリジナルの暗号化されたデータブロック２６１０とともに公的に分配されることに留意されたい。組み合わせられたメッセージ２６３０（公開キー２６２２と組み合わせられたオリジナルの暗号化されたデータブロック２６１０を備える）のメッセージダイジェストから、デジタル署名２６２４を作成する作用は、適切に承認された終点デバイスのみが、オリジナルの暗号化されたデータブロック２６１０を復号化可能であるだけでなく、この復号化プロセスが、復号化エンジン２６６２の所定の方法を使用することによってのみ達成可能であることを保証する。暗号化エンジンチェーン２６６０により多くの構成要素（例えば、多項複合暗号化等）を追加することによって、より多くの制約が、復号化承認手順に容易に追加可能であることに留意されたい。

図２６Ｂは、図２６Ａに示される実施形態の変形例を図示する。この実施形態においては、特定の暗号化されたメッセージ２６１１の著者は、特有の終点デバイス上においてのみ明確に認証可能である。ここでは、オリジナルの暗号化されたデータブロック２６１１は、上述のように、特有の復号化ルーチン２６６２に暗号学的に結合される。この時点では、復号化ルーチン２６６２は、非対称暗号化エンジンであって、入力は、著者の秘密個人キー２６２５であり得、出力は、著者の公開キーを使用してのみ、正確に復号化されるであろうことが、さらに規定され得る。非対称暗号化ルーチン２６６２のメッセージダイジェスト２６２７は、デジタル署名２６２６とともに、オリジナルの暗号化されたデジタルデータ２６１１に付加され、データ構造２６３１全体を形成する。次いで、データ構造２６３１は、その終点デバイスの秘密キー２６２３、ハッシュ関数２６４４、および暗号化エンジン２６６１を使用して、デジタル署名２６２８を形成することによって、特有の終点デバイスに暗号学的に結合可能である。この実施形態の場合、暗号化されたメッセージ２６１１が、本物であって、その著者が、既知であるだけではなく、著者がハードウェア秘密キー２６２３を所有しているという事実を保証可能である。ここでは、本明細書において使用されるように、著者という用語は、必ずしも、データの創設者を意味するわけではなく、また、使用許諾者、配信者、あるいはそのようなデータの配信または別様に通信を所望する別の種類のエンティティをも指し得ることに留意されたい。この特定の信頼の連鎖の使用が重要となり得る一例は、終点デバイスのセキュリティシステムが、セキュア化コードブロック（オリジナルデータブロック２６１１内に、暗号化された形式で含まれるであろう）を使用して、アップデートされるべき場合である。

図２７は、セキュア化コードブロック２７２０の実行を制御するために、カスケード式ハッシュ方法を利用する一実施形態を図示する。この場合、２つの独立コードブロック２７１０、２７２０が存在する。本例では、第１のコードブロック（セキュア化コードブロック２７１０）は、第２のルーチン（セキュア化コードブロック２７２０）に対する埋め込みサブルーチン呼出しを含む。したがって、セキュア化コードブロック２７１０のためのハッシュ関数２７４０によって算出されたメッセージダイジェスト２７３０は、セキュア化コードブロック２７１０内に含まれる、セキュア化コードブロック２７２０への参照に依存する。次いで、このメッセージダイジェスト２７３０は、セキュア化コードブロック２７１０の観点から、２つのセキュア化コードブロックをともにリンクする。次に、メッセージダイジェスト２７５０は、ハッシュ関数２７７０を使用して、コードブロック２７２０のために構築されてもよい。しかしながら、メッセージダイジェスト２７５０をセキュア化コードブロック２７２０だけではなく、その呼出し親ルーチン（この場合、セキュア化コードブロック２７１０）の両方に結び付けるために、オリジナルメッセージダイジェスト２７３０は、ハッシュ関数２７７０によって算出されるメッセージダイジェスト２７５０へのシードとして使用されてもよい。そのようなシード値は、多くの方法において実装可能であるが、しかし、１つのそのような方法は、単に、オリジナルメッセージダイジェスト２７３０を第２のデジタルデータ集合（例えば、この場合、セキュア化コードブロック２７２０）に連結し、メッセージ２７６０全体を形成することであることを思い起こされたい。次いで、メッセージ２７６０全体は、ハッシュ関数２７７０（ハッシュ関数２７４０と同一である、またはある別の独立ハッシュ関数であることが可能である）にかけられ、第２のメッセージダイジェスト２７５０を形成し、したがって、セキュア化コードブロック２７２０だけではなく、オリジナルメッセージダイジェスト２７３０（それ自体、セキュア化コードブロック２７１０および２７２０の両方に依存する）の両方に依存する。図２５Ｂの議論に記載したように、これらの連結された要素２７２０および２７３０の順序は、結果として生じるメッセージダイジェスト２７５０に重要であり得るが、ハッシュ関数２７７０の場合、メッセージ２７６０全体を備える要素の順序は、ハッシュ関数２７７０のセキュリティに実質的な影響を及ぼし得ない。

次いで、この第２のメッセージダイジェスト２７５０は、セキュア化コードブロック２７２０が、コードブロック２７１０から呼び出される場合にのみ正確に実行され得ることを保証する、上述と実質的に類似する態様で使用可能である。コードブロック２７２０は、実際に、コードブロック２７１０の正確な複製（または、同等参照）であり得、これは、再帰的システムの実施形態となるであろうことに留意されたい。同一コードブロックの２つの事例間の唯一の相違は、セキュア化コードブロックメッセージダイジェストを形成するために、コードブロックに付加される特定のメッセージダイジェストであり得る。

この特定の実施形態においては、任意の秘密キーを使用しておらず、したがって、この種類の構造は、本明細書において説明されるものと同一のセキュリティシステム全体を使用する、任意の終点デバイス上で適切な実行順序を実施するための特異性を伴わずに使用可能であることに留意されたい。また、上述のように、類似の例は、加えて、セキュア化コードブロック２７１０または２７２０のいずれかの実行が、それぞれ、メッセージダイジェスト２７３０または２７５０の代わりに、複合キーベースのデジタル署名構造あるいはその同様のものを利用することによって、ある特有の終点デバイスもしくはデバイスの集合に制約されるように構築されてもよい。

図２８Ａは、セキュア化コードブロックメッセージの構築の実施形態を図示する。一実施形態では、暗号化されたデジタルデータ集合２８１１は、ポインタ２８２０によって識別される暗号化アルゴリズムを使用して暗号化されている。データ構造２８３０は、デジタルデータ集合２８１１およびポインタ２８２０の連結によって形成される。データ構造２８３０のメッセージダイジェスト２８５０は、ハッシュ関数２８４０によって生成される。この配設は、暗号化されたデータ集合およびその関連付けられた復号化ルーチンの暗号学的結合を可能にする。

第２の実施形態では、付加的条件が、連結されたデータ構造２８３１に、すなわち、ポインタ２８２１が復号化キー２８６０に追加される。このキー２８６０は、この特定の実施形態に図示されるように、必ずしも、ハードウェアベースの秘密キーではないことに留意されたい。実際、ポインタ２８２１によってポイントされるキー２８６０は、以下の図２８Ｃの説明に論じられるように、それ自体がデータ構造であってさえよい。その他の点では、この実施形態は、上述の実施形態に実質的に類似する。暗号化されたデジタルデータ集合２８１１は、オリジナルの非暗号化データ集合２８１０に作用する暗号化エンジン２８７０および１つ以上のキー２８６０を使用する結果として作成される。メッセージダイジェスト２８５１は、連結されたデータ構造２８３１にハッシュ関数２８４１を使用して生成される。この場合、現状では、非暗号化データ集合２８１０を暗号化エンジン２８７０だけではなく、暗号化されたデータ集合２８１１から非暗号化データ集合２８１０を再作成するために使用することが可能な一意的キー２８６０の両方に暗号学的に関連付けるためのメカニズムが存在する。上述の実施形態と同様に、構造全体を所与の終点デバイスおよびその一意的秘密ハードウェアキー２８６０に関して充足されているべき特有の条件集合に暗号学的に結合するために、付加的条件が、暗号化チェーンに追加されてもよい。デジタルデータ集合２８１０および２８１１のフォーマットおよび暗号化状態（すなわち、暗号化されているか、またはそうでないか）は、これらの詳細が、ポインタ２８２０、２８２１から推測可能であるので、このプロセスに関連し得ないことは着目に値する。

この点を考慮して、図２８Ｂは、このように、再帰的セキュリティシステムにおいて使用可能なユニバーサル暗号化データ構造のための基本的な汎用フォーマットの１つの可能性のある実施形態を図示する。この構造の実施形態は、単純かつ強力であり得、一般的データブロック２８１２、復号化ポインタ２８２０、および復号化キーポインタ２８２１の３つの基本的要素の単純にリンクされたリストとして実装可能である。リンクされたリスト全体は、データ構造２８３２内でともにバンドルされる。リンクされたリストを使用することによって、連結されたデータ構造２８３２内の要素の順序が、その機能に関連しないが、データ構造の動作または評価に影響を及ぼし得ることが容易に分かる。一般的（例えば、所定ではない）データブロック構造およびリンクされたリストのフォーマットを使用する、別の興味深い側面は、３つの要素２８１２、２８２０、ならびに２８２１もまた、必ずしも、線形または連続的にさえ、順序付けられる必要がないことである。したがって、一実施形態は、データ構造２８３２全体と併せて格納される、独立しているが、恐らく、関連している、ある他のデータを含む、補助データ構造２８１３を備えてもよい。この概念の一実施形態は、図２８の補助データ構造２８１３内のポインタ２８２０によってポイントされるもの等、実際の復号化エンジンコードブロック２８７１を特定することであろう。別のそのような例は、この補助データブロック内のポインタ２８２１によって規定される、実際のキー値を格納し得る。

これら両方の場合、そのような補助データブロック内に含まれる実際のデータは、図２５Ａ、２５Ｂ、２６Ａ、２６Ｂ、２７、および２８Ａに提示される、実施形態の例に様々に図示されるように、メッセージダイジェストまたはデジタル署名を生成するプロセスにおいて使用されてもよい。この開示に記載されるように、連結されたデータ集合内に格納される種々のデータフィールドの順序は、ハッシュ関数が適切に設計される場合、結果として生じるメッセージダイジェスト（または、デジタル署名）に影響を及ぼし得る。

したがって、また、類似ブロック構造を使用して、ある実施形態で利用されるキーをセキュア化してもよいことは、明白であろう。図２８Ｃは、キーのみを備える、そのようなセキュア化データブロック２８３３の一実施形態を図示する。ここでは、データブロックは、デバイス特有のキー２８１４、２８１５、２８１６（または、所望に応じて、その他）のリストを備えてもよい。この例では、これらのキーのいずれも、（例えば）終点デバイス２８６０の秘密キーと、それぞれ、暗号化エンジン２８７１および２８７２を使用して暗号化された終点デバイスタイムスタンプレジスタ２８９０を使用して作成されてもよい。セキュリティシステムのロバスト性の観点からのそのような動作の上述の説明と同様、暗号化エンジン２８７１および２８７２が、個別またはさらに異なっているべきであるという要件は存在せず、暗号化チェーンにおけるある数のこれらの暗号化動作に対して、基礎的限度がなくてもよい一方、これらの動作の順序は、結果として生じる複合キーに重要でなくてもよく、暗号化動作のための特定の順序に対する要件は存在しない。この場合に留意すべき他の特徴の１つは、連結されたキーリストデータ構造２８３３のキーリストポインタ要素２８２１が、さらに別の連結されたキーリストデータ構造２８３４をポイントし得ることである。これらのデータ構造は両方とも、図２８Ｂに図示されるように、同一ユニバーサル暗号フォーマットであるため、キーリストデータ構造は、再帰的態様で形成可能である。故に、そのような再帰的セキュリティシステムにおける実施形態で使用するためのキー２８３３は、そのようなセキュリティプロトコルの実施形態が適用され得る、任意の他のデータと同一態様および同一構造を使用して、保護されてもよく、同様に、これらの保護されたキーは、また、本明細書に開示されるシステムおよび方法の実施形態によってセキュア化された他のデータと同一態様において、終点デバイス上で復号化および認証されてもよい。

次に図２９を参照すると、複合キーがどのように暗号化されたコンテンツを復号化するために利用され得るかについての一実施形態が図示されている。この復号化動作は、上述のように、「セキュア化モード」において生じてもよい。ここでは、コンテンツ２９１０は、複合キー２９３０とともに、終点デバイスに提供されてもよく、そこでは、コンテンツは、最初に、グローバルコンテンツキーを使用して暗号化される。複合キー２９３０は、図２４に上述のように、作成されてもよい。故に、暗号化されたコンテンツ２９１０が、終点デバイスで受信されると、関連付けられた複合キー２９３０とともに受信され得る。デバイスにおける秘密キー２９４０が、アクセスされ得るように、セキュア化モードで実行することによって、複合キー２９３０は、セキュア化コードブロック２９６０内で復号化され、グローバルコンテンツキーをもたらし得る。グローバルコンテンツキーは、次に、セキュア化コードブロック２９６０内で使用され、オリジナルの暗号化されたコンテンツ２９１０を復号化し、復号化されたコンテンツ２９８０をもたらしてもよい。

図３０は、コードブロックが、実行前に特定の終点デバイスにおいて作動するために承認されていることを照合するために、どのように秘密キーが利用され得るかの一実施形態を図示する。実行のための候補コードブロック３０１０は、終点デバイスに提供されてもよく、または受信された暗号化されたデジタルコンテンツを復号化することによって得られてもよい（例えば、図２９に上述のように）。加えて、終点デバイスは、候補コードブロック３０１０に相当する、対応するデジタル署名３０２０を受信してもよい。このデジタル署名３０２０は、終点デバイスハードウェア特有の秘密キー３０３０を使用して暗号化されているコードブロックから作成される（例えば、そのコードブロックをハッシュすることによって）、メッセージダイジェストを備えてもよい。したがって、候補コードブロック３０１０が実行され得るかどうかを照合するために、認証動作が、セキュア化モードで実装されてもよく、それによって、候補コードブロック３０１０が、メッセージダイジェスト（３０１２）を作成するためにハッシュされる。次いで、このメッセージダイジェスト３０１２は、終点デバイスの終点デバイスハードウェア特有のキー３０３０（照合がセキュア化モードで生じるため、アクセス可能であってもよい）を使用して暗号化され、ステップ３０１４において、オリジナルとして供給されたデジタル署名３０２０と比較される、デジタル署名を作成可能である。このデジタルハードウェア生成デジタル署名が、候補コードブロック３０１０に対応する、受信したデジタル署名３０２０と整合する場合、候補コードブロック３０１０は、照合され、考えられ、実行可能であるとみなされてもよく、そうでなければ、例外エラーが生じ得る（ステップ３０１６）。

図３１は、コードブロックが、どのように「セキュア化実行」モードにおいて、特定の終点プロセッサ（所定の環境下）上で作動可能となり得るかの一実施形態のブロック図である。この特定の場合、コードブロック３１１１の事前に算出されたデジタル署名３１３０（また、終点特有の復号化キーとも称され得る）は、コードブロックのメッセージダイジェストを使用し、承認標的終点デバイスの秘密キー３１４０、承認標的終点デバイスの最も新しいタイムスタンプ値３１４１、または上述のような任意の数の制約条件の１つ以上（この特定の実施形態では図示せず）の１つ以上によって暗号化することによって構築される。

また、これらの条件の任意の１つも、マスク機能を条件自体のサブ集合に適用することによって事前に条件付けられ得ることに留意されたい。例えば、タイムスタンプフィールドのいくつかの最小有効ビットのマスクが、外されている場合（したがって、デジタル署名の計算では考慮され得ない）、そのタイムスタンプ値の有効粒度は、ハードウェアにおける任意の変更を伴わずに、コードセグメント基準によって、コードセグメント上で容易に制御可能である。この同一原理は、ある実施形態において、デジタル署名の計算において使用される、任意の数の条件に提供可能である。

図２８に図示されるキーリストデータ構造と同様、コードブロック３１１１を含む、連結されたデジタルデータ集合３１１０は、また、少なくとも１つの復号化ポインタ３１１２および少なくとも１つの復号化キーまたはキーリストポインタ３１１３を含む。また、上述のように、これらのいずれか１つは、外部データ構造（終点特有のデジタルキーまたはデジタル署名３１３０等）、あるいは連結されたデータ集合３１１０内に全体として含まれる、埋め込みデータ構造を参照してもよい。

図３１に示される実施形態を説明する目的として、コードブロック３１１１は、暗号化されていない（したがって、潜在的に、終点デバイス標的プロセッサ上で実行可能である）ことを前提する。この場合、復号化ポインタは、その使用に先立って、コードブロック３１１１のためにさらなる復号化が要求されないため、空値であってもよい。この場合のように、コードブロックが、暗号化されていない場合、その対応する復号化キー（ポインタ）３１１３は、関連付けられた終点またはハードウェア特有のデジタル署名３１３０をポイントしてもよい。したがって、図２５Ａ、２５Ｂ、２６Ａ、および２６Ｂに上述のもの等のデータ構造ならびに方法の実施形態を使用して、ブロック３１１１に図示されるような非暗号化データ集合の使用に関する、多種多様な認証、暗号学的結合、または他の制約を施行してもよい。

終点特有のデジタル署名（または、復号化キー）３１３０が、ハードウェア秘密キー３１４０のみ、または代替として、ハードウェア秘密キー３１４０および終点デバイスタイムスタンプレジスタ３１４１のみをポイントする場合、セキュリティシステム関連呼出しが、呼出しチェーンの「最下層」に到達し、この特定の呼出しチェーンにおけるセキュリティシステムの付加的層へのさらなる呼出しが存在しないことを決定可能となる。したがって、セキュリティシステム再帰は、この時点で「終了」する。この再帰終了条件は、終点特有のハードウェア秘密キー３１４０の値へのアクセスを選択的に許可または拒否する「ゲートキーパー」として、したがって、ハードウェアハッシュ関数ブロック３１６１の使用する暗号化機能への入力成分としてのみ作用する、ハードウェアブロック３１５０によって検出される。図３１に示される例では、ハードウェア特有の秘密キー３１４０およびハードウェアハッシュ関数ブロック３１６１の（メッセージダイジェスト）出力は、暗号化エンジン３１６２および３１６３への入力引数として使用される。

最後に、そこで、暗号化エンジン３１６３の出力（オリジナルの連結されたデータ構造３１１０のデジタル署名である）が、供給されたデジタル署名３１３０の値と整合する場合、「セキュア化モード有効化」ハードウェアビット３１７０が、設定される。この条件は、終点ハードウェアＩ−キャッシュ３１２０にロードされた候補コードブロック３１１１が、現時点において、「セキュア化」モードで実行することが承認されていることを示す。Ｉ−キャッシュ３１２０内に存在する候補コードブロック３１１１への物理的変更、またはＩ−キャッシュ３１２０自体への任意の変更が存在しないことに留意されたい。この時点で変更されている唯一のものは、「セキュア化モード有効化」ハードウェアビット３１７０の値である。

図３２は、再帰的セキュリティシステムによって行われ得る、復号化動作の一実施形態を図示する。この復号化動作は、配信されたコンテンツを復号化または別様に操作および利用するプロセスにおいて、使用されるべきセキュア化コードブロックを照合してもよい。上述のように、終点デバイスは、暗号化されたコンテンツ３２１１を含むデータ構造３２１０、復号化エンジン３２２０へのポインタ３２１２（または、復号化エンジン自体）、および終点特有の複合キー３２３０へのポインタ３２１３（図３０に関して上述のように）を受信してもよい。セキュア化モードにおいて実行可能にされる前に、ポイントまたは受信される複合復号化エンジン３２４０が認証されるであろう。この認証は、終点デバイス内に存在するハッシュ関数３２２１を使用して、複合復号化エンジン３２４０コードブロックのメッセージダイジェスト３２２２を計算することによって、達成されてもよい。ハッシュ関数３２２１は、本例では、ハードウェアブロックとして図示されているが、このハッシュ関数３２２１は、上述のように、例えば、終点デバイスの組込ハードウェアハッシュ関数の代わりに使用可能なセキュア化ソフトウェアコードブロックであってもよいことに留意されたい。しかしながら、この場合、ハッシュ関数のソフトウェアバージョンは、依然として、最終的には、認証または承認目的のために、組込ハードウェアハッシュ関数に依存し得、したがって、この場合の最終的信頼の基点は、依然として、終点の組込ハードウェアハッシュ関数ブロック３２２１とともに存在する。

次いで、このハッシュブロック３２２１によって生成されるメッセージダイジェスト３２２２は、ステップ３２２３において、復号化エンジン３２４０に対応する、事前に算出されたメッセージダイジェスト３２５０と比較されてもよい。この事前に算出されたメッセージダイジェスト３２５０は、例えば、セキュアな方式において、終点デバイスに提供されるか、または終点デバイス自体で事前に算出され、格納されてもよい。メッセージダイジェストが整合する場合、複合復号化エンジン３２４０は、終点デバイス（ステップ３２２５）上で実行可能となってもよい。メッセージダイジェストが、実質的に等しくない場合、無効なコード例外が生じ得る（ステップ３２２６）。

しかしながら、メッセージダイジェストが、実質的に等しい場合、終点デバイスのプロセッサは、セキュア化実行モードを入力し、複合復号化エンジン３２４０内に含まれるコードを実行してもよい。この複合復号化エンジン３２４１の第１の部分は、複合キーからグローバルコンテンツ特有のキーを生成するために、終点デバイスのハードウェア特有の秘密キー１１３１を利用して達成されてもよい（ステップ３２３２）。次いで、第２の復号化動作３２４２は、得られたグローバルコンテンツ特有のキーを使用して、暗号化されたコンテンツ３２１０から復号化されたコンテンツ３２５２を生成するために、復号化動作３２４１によって生成された中間結果を使用してもよい。ここでは、復号化エンジン３２４０は、一対の復号化アルゴリズム（３２４１および３２４２）として図示されるが、オリジナルの暗号化されたデータ集合３２１０に適用される、セキュア化コードブロック３２４０の種々の個々の構成要素（３２４１、３２４２等）の動作の最終結果が、所望の復号化されたコンテンツ結果３２５２を生成するように、任意のより少ないまたはより多い数のカスケード式復号化段階を包含してもよいことに留意されたい。また、これらの種々の個々の復号化構成要素の任意の２つは、同一または異なるアルゴリズムであってもよいことに留意されたい。

ある実施形態では、加えて、さらなるセキュリティを層状にすることが所望さ得、したがって、いくつかの実施形態では、複合キーは、図２５、２８Ｃ、および３１に関して上述のように、実質的に同一態様において、終点デバイス特有のハードウェアキーおよび終点特有のタイムスタンプ値を使用して、事前に算出されたメッセージダイジェストから形成されてもよい。

図３３は、終点デバイスにおける、再帰的セキュリティプロトコルの実装の一実施形態を図示する。具体的には、セキュア化コードブロックの照合のためだけではなく、配信されたデジタルビットストリームの実際の復号化／または他の使用のための複合キー集合の使用の一実施形態について図示される。本実施形態は、多くの側面において、図３２に図示される実施形態に類似しており、したがって、実施形態の異なるそれらの側面のみ、図３３に関して焦点が当てられる。暗号化されたコンテンツ３３１１を備えるメッセージ３３１０は、復号化エンジン３３４０（または、復号化エンジン自体）、コンテンツ特有の複合キー３３３１（図２９に関して上述のように）、ならびに終点およびタイムスタンプ特有の複合キー３３３２へのポインタ３３１２を含め、受信されてもよい。暗号化されたコンテンツ３３１１は、終点デバイスにおけるメモリ内にロード可能であって、また、復号化エンジン３３４０へのポインタ３３１２も、メモリ（例えば、終点デバイスにおける命令キャッシュまたは命令キャッシュのセキュア化部分）内にロードされてもよい。次いで、ポイントされる復号化エンジン３３４０が認証されるであろう。この認証は、図３２に関して上述のものと実質的に類似態様において、終点デバイス内に存在するハッシュ関数３３２１を使用して、暗号化エンジン３３４０のメッセージダイジェストを算出することによって達成されてもよい。

次いで、本例では、ハードウェア生成メッセージダイジェストは、ハードウェアまたは終点デバイス上のソフトウェアの中に実装されてもよく、算出されたメッセージダイジェストおよび終点デバイスハードウェア特有の秘密キー３３７０または終点デバイスタイムスタンプレジスタ３３６０の値等のハードウェア特有のキーあるいはレジスタの１つ以上に作用する、１つ以上のカスケード式複合暗号化エンジン段階３３２４、３３２５等を備える暗号化エンジンを使用して、暗号化されてもよい。生成される、結果として生じる複合デジタル署名３３２６は、復号化エンジンコードブロック３３４０に正確に対応してもよく、したがって、また、特有の終点デバイスに暗号学的に結合されてもよい（１つ以上の暗号化段階３３２４、３３２５と、３３６０および３３７０等の種々の秘密または公開変数あるいは定数を使用することによって）。上述のように、この生成されたデジタル署名は、必要に応じて、この複合デジタル署名の可用性をさらに制限するために、他の制約変数または定数とともに、さらに暗号化されてもよい（同一または異なる暗号化エンジンを使用して）。また、例えば、このデジタル署名３３３２と関連付けられたコードブロック３３４０の用途が、単一の一意的終点ユニットを超えて、拡張することが所望される場合、暗号化段階の１つ以上は、必要に応じて潜在的に生成された複合デジタル署名整合のフィールドを拡大するために制限されてもよい。

次いで、生成された複合デジタル署名３３２６は、ステップ３３２３において、オリジナルとして終点デバイスに提供され得る（例えば、事前に、終点コード使用許諾プロセスの一部として、使用許諾権限者によって）、その暗号化エンジン３３４０に対応する終点およびタイムスタンプ特有の複合デジタル署名３３３２と比較されてもよい。データ構造は、このトークン３３３２が、デジタル署名またはキーであるかにかかわらず、等しくあり得、したがって、用語「キー」および「デジタル署名」は、それらの場合、可能性として、交換可能に使用されてもよいことに留意されたい。

複合デジタル署名３３２６および３３３２が、実質的に同じである場合、終点デバイスのプロセッサは、復号化エンジンコードブロック３３４０内に含まれるコードをセキュア化実行モードで作動することが可能となり得る。セキュア化実行モードで作動すると、復号化エンジン３３４０は、復号化エンジン３３４１または３３４２を使用して、デバイス特有の複合キー３３３１からグローバルコンテンツ特有のキーを生成するために、終点デバイスのハードウェアキー３３７０を利用してもよい。したがって、グローバルコンテンツ特有のキーは、中間結果であってもよく、故に、複合復号化エンジンコードブロック３３４０以外の任意のソフトウェアまたはハードウェアエンティティに決してキャッシュされないか、あるいは別様に可視となり得ない。次いで、このグローバルコンテンツ特有のキーは、復号化エンジン３３４３によって使用され、オリジナルの暗号化されたコンテンツ３３１１から、最終復号化コンテンツ３３５０を生成する。

しかしながら、生成されたデジタル署名３３２６が、供給されたデジタル署名３３３２と実質的に整合しない場合、復号化エンジンコードブロック３３４０利用の試みが、未承認当事者によって行われる場合を含む不整合が生じ得る、いくつかの可能性のある理由が存在するであろう。しかしながら、不整合の別の可能性のある理由は、復号化エンジンのためのソフトウェアがアップデートされた（および、終点のタイムスタンプレジスタが、同様に、漸増または別様に変更された）場合であろう。この場合、２つのデジタル署名は整合し得ず、ステップ３３８１において、暗号化エンジンコード３３４０自体が、暗号化されている（例えば）か、または別様に置換を必要としているかどうかチェックされてもよい。本明細書に論じられる実施形態は、再帰的セキュリティプロトコルのために効果的に利用され得、したがって、多くの場合、暗号化アルゴリズム（ポイントされるか、または暗号化されたコンテンツとともに含まれてもよい）自体が暗号化される、これらの暗号化された暗号化アルゴリズム自体が暗号化される等であってもよいことを思い起こされたい。したがって、暗号化アルゴリズムのための生成された終点およびタイムスタンプ特有の複合キー３３２６と、受信した終点およびタイムスタンプ特有の複合キー３３３２が整合しない場合、少なくとも１つ以上の層の間接参照または暗号化が利用されている場合であり得る。

上述のように、特定の実行可能コードブロックに暗号化の層を追加する概念は、特定のコードブロックのアップデートされていないバージョンをそのコードブロックのより新しいバージョンと置換する作用と論理的に同等であり得る。故に、終点およびタイムスタンプ特有の複合デジタル署名３３３２、コードブロックの復号化ポインタ（図示せず）、またはコードブロックの復号化キーポインタ（同様に、図示せず）といった、そのコードブロックと関連付けられたトークンの１つ以上を検証することによって示されるように、復号化エンジン３３４０自体が、暗号化されているか、または別様に置換を必要とするか（ステップ１２８２に示されるように）どうかを決定可能である。一例では、コードブロック３３４０の関連付けられた復号化ポインタが、空値をポイントする場合、暗号化エンジン３３４０が、暗号化されていない、または別様にアップデートされておらず、したがって、生成されたデジタル署名３３２６および供給されたデジタル署名３３３２が、実質的に等しくないが、コードブロックを正確なデジタル署名を可能性として生成し得る異なるバージョンと置換するための他のリソースが存在し得ないため、例外エラーが生じ得る結果（ステップ３３８３）ことを示すであろう。しかしながら、復号化エンジンコードブロック３３４０の復号化ポインタが、別のコードブロック（別の（可能性として、アップデートされている）暗号化エンジン（図示せず）またはある他のコードブロック）をポイントする場合、この新しいコードブロックがロードされ、上述の認証ステップが、この次の暗号化エンジンに適用されてもよい（言い換えると、別の再帰層が導入されてもよい）。この再帰的実行メカニズムは、生成された終点およびタイムスタンプ特有の複合デジタル署名３３２６と供給された終点およびタイムスタンプ特有の複合デジタル署名３３３２との間に整合が生じると決定される（ステップ３３２７）、または整合が存在せず、復号化エンジン３３４０自体が、暗号化されておらず、その時点で、例外エラーが生じ得ると決定される（ステップ３３８３）まで、継続してもよい。

生成された終点およびタイムスタンプ特有の複合デジタル署名３３２６と、供給された終点およびタイムスタンプ特有の複合デジタル署名３３３２が整合すると決定される場合に、再帰が終了され、巻き戻されてもよい。これは、再帰的呼出しチェーン全体を通しての初期順方向パスの際に直面し、スタックに保存される、コードブロックのそれぞれの認証および実行を伴ってもよい。これらのコードブロックの一部または恐らく全部さえ、必ずしも、暗号化または復号化エンジンでなくてもよいことに留意されたい。いずれの場合も、これらのコードブロックはそれぞれ、標的終点デバイスのプロセッサがセキュア化実行モードで動作中に認証され得る。

この実行は、再帰的セキュリティシステムによって行われ得る復号化動作の一実施形態を図示する、図３４を参照することによって、より詳細に説明されるであろう。説明されるように、終点デバイスは、特に、暗号化されたコンテンツ３４１２とともに、コンテンツ特有の複合キー３４１６（図２９を参照して論じられるように）、復号化エンジンデータ構造３４２０へのポインタ３４１３、またはオリジナルメッセージ３４１０内に埋め込まれる場合、復号化エンジン自体、およびキーまたはキーリストデータ構造３４１８をポイントするキーリストポインタ３４１４を含み得る、メッセージ３４１０を受信してもよい。上述のように、このデータ構造は、キーまたはキーリスト３４１６あるいはデジタル署名３４１７を含んでもよい。同様に、復号化エンジンデータ構造３４２０は、暗号化されたコードブロック３４２１、暗号化された（または代替として、置換を必要とする古い）復号化コードブロック３４２１と関連付けられた後続の復号化ポインタ３４２２、および関連付けられた復号化キーリストポインタ３４２３を含んでもよい。後続の復号化ポインタ３４２２は、復号化コードブロックデータ構造３４２０のものと実質的に類似する構造を有するが、データ構造３４３０の場合、復号化コードブロック３４３１自体は、暗号化された形式ではない最終復号化コードブロックデータ構造３４３０をポイントしてもよい。

図３４に図示される実施形態の動作は、以下のように説明可能である。暗号化されたコンテンツデータ構造３４１０が、その中に含まれる暗号化されたコンテンツ３４１２を復号化することを予測して、終点プロセッサのメモリ空間内にロードされる。データ構造３４１０は、復号化ポインタ３４１３を含むので関連付けられた復号化エンジンコードブロックデータ構造３４２０は、メモリ内にロードされ、読み込まれる。また、この後続のデータ構造３４２０は、復号化ポインタ３４２２を含むため、次いで、ポインタ３４２２と関連付けられた復号化エンジンコードブロックデータ構造３４３０が特定され、メモリ内にロードされる。データ構造３４３０の場合、本例の埋め込み復号化ポインタ３４３２は、空値ポインタであると決定され、したがって、標的終点デバイスのセキュリティシステムは、現在の復号化再帰チェーンが終了し（例えば、図３１に論じられるように）、したがって、データ構造３４３０の一部として、メモリにちょうど読み込まれた復号化エンジン３４３１が、非暗号化（したがって、潜在的に、実行可能）コードブロックを含み得ることを決定可能である。

デジタルコンテンツ３４３１が、コードブロックであって、データではないことが決定可能であるため（呼び出された態様によって）、また、復号化キーリストポインタ３４３３（データ構造３４３０の一部として、メモリに内に読み込まれた）によってポイントされるキーリストデータ構造３４３８が、デジタル署名３４３７（複合キー３４３６に加え）を含み得ることも決定可能である。また、本例におけるキーリストデータ構造（３４１８、３４２８、および３４３８）は、図２８Ｂに関して上述のように、ユニバーサル暗号化データ構造を使用して実装されてもよいことに留意されたい。したがって、これらのキーリストデータ構造３４１８、３４２８、および３４３８内の引数の順序は、必ずしも、固定ではなく、したがって、データ構造自体がトラバースされるのに伴って、ランタイム時に解釈されてもよい。実際、これらのキーリストデータ構造（３４１８、３４２８、および３４３８）自体、補助的復号化ポインタおよびキーリストポインタをこれらのキーリストデータ構造（３４１８、３４２８、および３４３８）自体の一部または全部内に組み込ことによって、さらなる復号化または後続の解釈への参照を含んでもよいが、この特定の選択肢は、単純化を目的として、図３４の実施形態には図示されないことに留意されたい。

さらに、キーリストデータ構造３４３８内のキーポインタ３４３６の少なくとも１つが、終点のハードウェア秘密キー３４９２への参照に対応することを決定可能である。終点のハードウェア秘密キー３４９２へのこの参照は、適切に確保された記憶場所（プロセッサのアーキテクチャの中に規定され得るが、決して、プロセッサによって直接読み取られ得ず、したがって、構造上直接不可視である場所）へポイントすることによって明示的に、またはポインタのためにある特別に確保された値を使用することによって暗示的に達成されてもよい。いずれの場合も、この参照は、種々の手段を使用して実装されてもよいが、１つのそのような実施形態の例は、キーリストデータ構造内の「０」の値（「空値」とは別として）を終点のハードウェア秘密キー３４９２への参照と一致させることであろう。キーリストデータ構造の少なくとも一部は、終点のハードウェア秘密キー３４９２を参照するという事実は、復号化エンジンコードブロック３４３１が、標的終点デバイスのプロセッサ上において、セキュア化実行モードで作動することが意図されることをさらに示し得る。したがって、ハードウェアベースのデジタル署名発生器ブロック３４９０の出力は、データ構造３４３７内に格納された値と比較される。２つの値が実質的に整合する場合、プロセッサは、セキュア化実行モードに入ることが可能となる。

ここでは、ハードウェアベースのデジタル署名発生器ブロック３４９０（その一実施形態の詳細は、図３６に関して、より包括的に提示される）は、一実施形態では、１つ以上のソフトウェアベースの要素を備えてもよいが、また、上述のように、直接または間接的に、少なくとも１つのハードウェアベースのセキュリティ構成要素を備えてもよいことに留意されたい。そのハードウェア構成要素は、本明細書に含まれる上述の説明の多くにおいて参照され、標的終点ユニットのセキュリティシステムの信頼の基点全体を成す、ハードウェアベースのハッシュ関数である。

この時点では、次いで、復号化エンジンコードブロック３４３１が、セキュア化実行モードで作動可能となり、終点プロセッサが、潜在的に、セキュリティ関連動作の一部として、終点のハードウェアデバイス特有の秘密キー３４９２を利用可能となる（本明細書で上述のように）。プロセッサが、セキュア化実行モードで動作していない場合、秘密キー３４９２の値は、そのようなセキュリティ関連動作における使用のために利用可能とならないであろう。この概念は、プロセッサがセキュア化実行モードにおいて作動中の場合にのみ、秘密キー３４９２の値を後続の使用（例えば、復号化エンジンコードブロック３４３１における）に通過させる、ハードウェアアクセス制御ブロック３４４３として、図３４に関して図示される。

加えて、ハードウェアアクセス制御ブロック３４４３への入力パラメータの１つは、アクセス制御ブロック３４４１の出力であることが分かる。このように、ハードウェアアクセス制御ブロック３４４３の状態（事実上、復号化コードブロック３４２１のための「セキュア化実行モード有効化」インジケータである）は、復号化コードブロック３４３１もまた、セキュア化実行モードで作動中であるという事実に依存する。これは、復号化コードブロック３４３１（例えば、ハードウェアアクセス制御ブロック３４４１の出力）のための「セキュア化実行モード有効化」インジケータの状態によって示されてもよい。この依存性は、復号化エンジンコードブロック３４２１の能力を、復号化コードブロック３４３１が、またセキュア化実行モードで作動中である場合にのみ、セキュア化実行モードで機能可能となるように制約する。本質的に同様の態様において、ハードウェアアクセス制御ブロック３４４３の出力は、復号化コードブロック３４１１のための「セキュア化実行モード有効化」インジケータである、ハードウェアアクセス制御ブロック３４４５への入力の１つとして使用される。したがって、両方が適切に認証され（図３５に関して、より詳細に説明されるように）、再帰的呼出しチェーン内の下位のセキュリティチェーンの適切に承認された部分からの認証復号化結果が供給されている場合のみ、先行する親コードブロックがセキュア化実行モードで作動することを許可する目的として、呼出しチェーンを逆方向に後退して、「セキュア化実行モード有効化」ビットを伝播させるメカニズムとなる。上述のように、いくつかの条件の任意の１つは、「セキュア化実行モード有効化」ビットのいずれかを「非セキュア化」デフォルト状態にリセットさせてもよい（したがって、潜在的に、セキュリティチェーン全体を再開させることを必要とする）ことに留意されたい。そのような条件は、プロセッサ割り込みまたは後続のデジタル署名比較不整合を含んでもよい。これらのハードウェアアクセス制御ブロック３４４１、３４４３、および３４４５は、図３４において、明確性を目的として、別個のエンティティとして図示されるが、それらは、実際、単一ハードウェアユニット（図３６に関して説明されるような）に埋め込まれてもよく、したがって、その出力は、その独自入力条件と１つとして、フィードバックされることが分かる。最終的には、チェーン全体における最高レベルまたは最終「セキュア化実行モード有効化」ビットの出力（本実施形態では、ハードウェアアクセス制御ブロック３４４５の出力）は、制御メカニズムの一部として使用され、標的デバイスに対するある外部可視出力を有効または無効にしてもよい（例えば、音声または映像出力を有効にする）。

ステップ３４７０における復号化エンジンコードブロック３４３１の作用は、データ構造３４２０の復号化エンジンコードブロック部分３４２１内に格納されたデータ集合を、オリジナルデータのアップデートおよび／または適切に実行可能バージョンと置換または別様に補完することである。この作用は、３４２１内に格納されたオリジナルデータを利用して、キーリストデータ構造３４２８内に格納されたか、またはポイントされた１つ以上の復号化キーによって復号化することによって達成されてもよい。代替として、上述のように、復号化エンジンコードブロック３４３１の作用３４７０は、復号化コードブロック３４２１をアップデートされたバージョンと置換するか、またはさらに復号化エンジンコードブロック３４２１の代わりに直接実行することであってもよい。いずれの場合も、復号化エンジンコードブロック３４３１は、最初、（本実施形態では）標的終点デバイスのタイムスタンプレジスタ３４９４内に含まれる値、標的終点デバイスのハードウェア特有の秘密キー３４９２（ハードウェアアクセス制御３４４２を通過することによって書き換えられるような）、ならびに終点およびタイムスタンプ特有の複合デジタルキー３４２６を含む、種々の入力データを使用して動作してもよい。復号化エンジンコードブロック３４３１が、続いて、復号化エンジンコードブロック３４２１の直接置換として動作する場合に、第２の入力データ集合（例えば、この実施形態においては、標的終点デバイスのタイムスタンプレジスタ３４９４内に含まれる値、標的終点デバイスのハードウェア特有の秘密キー３４９２（ハードウェアアクセス制御３４４４を通過することによって書き換えられるような）、ならびに終点およびタイムスタンプ特有の複合デジタルキー３４１６）を利用してもよい。

ステップ３４７１におけるアップデートされた復号化エンジンコードブロック３４２１のさらなる作用は、所望の出力データ３４８０を生成するために、オリジナルの暗号化されたコンテンツデータ３４１２を置換または別様に解釈することである。本作用は、３４１２内に格納されたオリジナルデータを利用して、キーリストデータ構造３４１８内に格納またはそれによってポイントされた１つ以上の復号化キーによって復号化することによって達成されてもよい。復号化エンジンコードブロック３４２１および３４３１両方の作用は、性質上類似するので、復号化エンジンコードブロック３４３１の動作の説明において上述の選択肢のいずれかが、復号化エンジンコードブロック３４２１のアップデートされたバージョンの動作に等しく適用可能であることは明白であるはずである。また、復号化エンジンコードブロック３４２１の動作の場合、いくつかの実施形態では、関連付けられたハードウェアアクセス制御ブロック３４４４は、ハードウェアアクセス制御ブロック３４４２と異なることに留意されたい。しかしながら、これらの２つのハードウェアアクセス制御ブロック３４４２および３４４４の作用は、それらの目的が、それぞれ、それらの関連付けられた復号化エンジン３４３１または３４２１によって、標的終点デバイスのハードウェア特有の秘密キー３４９２の使用を有効あるいは無効にするという点において、性質上類似しており、したがって、他の実施形態では、異なっていなくてもよい。

最後に、上述の図３４の実施形態に図示される動作すべてにおいて、標的終点デバイスのタイムスタンプレジスタ３４９４の使用は、他の実施形態に対して本明細書に上述のそれらの例と本質的に類似する。したがって、レジスタ３４９４内に格納された値は、図３４に図示される特定の実施形態に記載される異なる承認ならびに復号化動作で採用される、種々の複合キーおよび／またはデジタル署名の発生において、付加的要素として使用されてもよいということになる。

図３５は、再帰的呼出しチェーンが、そのようにトラバースおよび終了され、プロセッサが、どのように１つ以上の埋め込みコードブロックのメッセージ−ダイジェストベースの認証を使用して、セキュア化実行モードに入ることが可能となり得るかの一実施形態を図示する。本実施形態では、２つの候補コードブロック３５１２および３５２２の動作が説明され得、その両方とも、図２８Ｂに関して上述のように、ユニバーサル暗号化データ構造（それぞれ、３５１１および３５２１）内に含まれてもよい。

図３５では、コードブロックデータ構造３５２１が、２回現れていることに気付かれたい。この重複は、明確にすることを目的として、別個の反復を表すように例示されるが、これは、両方の事例において、正確に同一のデータ構造であることに留意されたい。しかしながら、気付かれ得る差異の１つは、キーリストポインタ３５２１の事例によってポイントされるのはキーリストデータ構造３５２８および３５３８であることである。キーリストポインタ３５２１の値は、この図に示される２つの事例間で変動しないが、キーリストデータ構造３５２８内に含まれる（または、それによってポイントされる）値は、２つの反復間で変化してもよく、したがって、この詳細は、データ構造（および、その種々の構成要素）を、それぞれ、３５２６、３５２７、および３５２８から、３５３６、３５３７、および３５３８に再ナンバリングすることによって示される。この構造が再ナンバリングされるという事実は、必ずしも、データ構造の実際の場所が移動したことを示すものではなく、そのコンテンツが変化した可能性があるにすぎない。同様に、また、ハードウェアハッシュ関数３５８０が、本図では、明確性を増大させるという同一理由から、複数化図示される。最後に、２つの候補コードブロック３５１２または３５２２のいずれも、暗号化されておらず、したがって、それらの関連付けられた復号化ポインタ３５１６、３５２６、および３５３６はすべて、空値ポインタであってもよいことに留意されたい。

本実施形態では、候補コードブロック３５１２に対する読み出しが、開始されてもよい。上述と同一態様において、コードブロックデータ構造３５１１が、メモリ内に読み込まれてもよく、そのメッセージダイジェスト３５４１は、ハッシュ関数３５８０によって算出されてもよい（上述のように、ハードウェア内で全体的または部分的に実現されてもよい）。しかしながら、本実施形態では、ハッシュ関数は、初期シード値３５４０が与えられてもよい（すべてゼロに設定されてもよく、またはそうでなくてもよい）。上述のように、このハッシュ関数シード値特徴は、いくつかの方法の１つを使用して実装されてもよいが、本実施形態では、シード値３５４０は、既知であって、ハッシュ関数ブロック３５８０のメッセージダイジェスト出力３５４１に影響を及ぼす方法は、反復可能かつ決定性である。

ハッシュ関数の結果３５４１が生成されると、プロセッサは、コードブロック３５１２内に含まれるコードの実行を開始可能となる。図３５に示される実施形態では、復号化ポインタ３５１３ならびにキーリストポインタ３５１４によってポイントされる両場所３５１６および３５１７（キーリストデータ構造３５１８内に含まれる）の両方の値がすべて、空値である場合、コードブロック３５１２は、セキュア化実行モードで作動するように設計されなくてもよく、したがって、標的終点ユニットのセキュリティハードウェア特徴のいずれかの使用を必要としない。したがって、プロセッサは、コードブロック３５２２をポイントする埋め込みサブルーチン呼出しに到達するまで、コードブロック３５１２内に含まれる命令の実行を開始する。

その時点で、コードブロックデータ構造３５２１は、メモリ内にロードされ、次のメッセージダイジェスト３５４２を生成するプロセスが、ハッシュ関数ブロック３５８０によって繰り返される。しかしながら、この特定の事例では、ハッシュ関数シード値は、もはや初期シード値３５４０ではなく、以前に生成された結果３５４１であり得る。したがって、メッセージダイジェスト３５４２の値は、コードブロック３５１１および３５２１の両方のメッセージダイジェストに確定的に依存することが分かる。しかしながら、上述の場合のように、復号化ポインタ３５２３の値およびキーリストポインタ３５２４によってポイントされるキーリストデータ構造３５２８内に含まれる値は、依然として、空値であってもよく、したがって、プロセッサは、上述のように、非セキュア化実行モードで継続する。

後に、プロセッサは、別のサブルーチン呼出しに直面するが、本例では、コードブロック３５２２は、再帰的呼出し（例えば、それ自体に対するサブルーチン呼出し）を含む。ある実施形態では、そのような再帰的呼出し構造は、例示にすぎず、標的終点デバイスのセキュリティシステムの正確な動作は、他の手段、例えば、セキュリティシステムに対する任意の呼出しが、コードの単一層内に含まれることを保証する、他の手段によって達成されてもよいことに留意されたい。しかしながら、多重レベルのセキュリティシステムがトラバースされると、再帰的呼出し形式は、上述のように、比較的によりセキュアであって、図示された実施形態と併せて、セキュリティシステムを実装するために、効果的に利用され得る。

いずれの場合も、プロセッサが、コードブロック３５２２内に埋め込まれたサブルーチン呼出し（それ自体を参照する）に直面すると、コードブロックデータ構造３５２１は、再び、メモリ内にロードされ（例えば、最新システムでは、データ構造３５２１は、フェッチされる２度目は、異なる物理的場所にロードされてもよい）、ハッシュ関数３５８０は、新しいメッセージダイジェスト３５４３を計算する。この新しいメッセージダイジェスト３５４３は、初期メッセージダイジェストシード値３５４０、（コードブロック３５１２の）メッセージダイジェスト３５４１だけではなく、コードブロック３５２２の２つの別個の反復のメッセージダイジェストに依存することに気付かれたい。

また、この２度目は、キーリストポインタは、非空値デジタル署名値３５３７を含む、新しいデータ構造３５３８をポイントすることに留意されたい。この非空値は、コードブロック３５２２のこの反復が、標的終点ハードウェア特有のセキュリティシステムへの参照を含む、セキュリティシステムに対するインジケータである。したがって、本実施形態では、そのような参照が、適切に動作するために、プロセッサは、ある時点において、セキュア化実行モードに入らなければならない。したがって、次いで、コードブロックデータ構造３５２１が、メモリ内に最も新しくロードされた時に生成されたデジタル署名３５４３が、キーリストデータ構造３５３８内に含まれるデジタル署名３５３７と比較されてもよい。ステップ３５９１において、２つの値が、実質的に類似することが分かった場合、標的終点プロセッサは、セキュア化実行モードに入ることが可能となる。しかしながら、２つのデジタル署名値３５３７および３５４３が、整合しない場合（デジタル署名３５３７が、この時点では、非空値であることが分かっていることを前提とする）、ステップ３５９２の結果は、プロセッサに、セキュリティシステムの適切な例外エラーハンドラ部分３５７０を実行させることになる。

図３６は、デジタル署名発生器ブロック３６６０が、どのように上述の特徴をサポートするために、ハードウェア内に実装され得るかの一実施形態を図示する。図３６に図示される実施形態は、図３１に図示され、例えば、図３２、３３、３４、および３５に関して、動作の詳細において説明された機能特徴をサポートする、デジタル署名発生器ブロックの機能に類似する機能のハードウェア実装を示す。

ハッシュ関数シードレジスタ３６１０は、図３５のブロック３５４０として標識されたものと類似機能を備えてもよく、ハッシュ関数ブロック３６６１にフィードされる、初期値を保持するように動作可能であってもよい。ハッシュ関数ブロック３６６１の出力は、複合暗号化エンジンの第１の段階３６６２への入力の１つとしてフィードされる。暗号化エンジン３６６２への他の入力は、標的終点デバイスのタイムスタンプレジスタ３６４１の出力である。次いで、第１の段階の暗号化エンジン３６６２の結果として生じる出力は、第２の段階の暗号化エンジン３６６３への入力の１つとして供給される。第２の段階の暗号化エンジン３６６３への他の入力は、セキュア化実行モードアクセスポイント３６６６の出力である。

アクセスポイント３６６６は、標的終点デバイスが、セキュア化実行モードで作動中であるとき、または図３５に関して上述のように、「再帰終了」条件が検出されるときにのみ、標的終点のハードウェア特有の秘密キー３６４０の値を通過するように動作可能である。次いで、第２の段階の暗号化エンジン３６６３からの結果として生じる出力値は、この生成されたデジタル署名を候補コードブロックとともに供給されるデジタル署名と比較する際に使用するために、デジタル署名レジスタ３６６４内に格納される（例えば、図３０、３１、３２、３３、３４、および３５の説明において参照されるように）。

デジタル署名レジスタ３６６４の出力は、その作用が、標的終点デバイスがセキュア化実行モードで作動中ではないとき、デジタル署名レジスタ３６６４の値を通過させることであるアクセスポイント３６６５によってゲートされる。次いで、アクセスポイント３６６５の出力は、図３５に関する説明において詳述されたカスケード式メッセージダイジェスト特徴を作成するために、ハッシュ関数シードレジスタ３６１０の入力にフィードバックされる。標的終点デバイスが、セキュア化実行モードで作動中の時、ハッシュ関数シードレジスタ３６１０への入力は、デジタル署名レジスタ３６６４の値に依存せず、したがって、ある初期値に（図３５に関する説明において詳述されるように）、またはある他の手段（例えば、特有の記憶場所へのプロセッサ書き込み等）によって、設定可能である。

本明細書に説明される実施形態は、ソフトウェア、またはハードウェア、または両方の組み合わせにおいて、制御論理の形態で実装されることができる。制御論理は、情報処理デバイスに、種々の実施形態に開示される一式のステップを行うよう指示するように適合された複数の命令として、コンピュータ読み取り可能な媒体等の情報記憶媒体内に記憶されてもよい。本明細書に提供される本開示および教示に基づいて、当業者は、本発明を実装するための他の手法および／または方法を理解する。

ソフトウェアプログラミング内に本明細書に説明されるステップ、動作、方法、ルーチン、またはその一部のいずれかを実装することもまた、本発明の精神および範囲内であり、そのようなソフトウェアプログラミングまたはコードは、コンピュータ読み取り可能な媒体内に記憶されることができ、プロセッサによって、コンピュータに、本明細書に説明されるステップ、動作、方法、ルーチン、またはその一部のいずれかを行わせるように動作させられることができる。本発明は、１つ以上の汎用デジタルコンピュータ内のソフトウェアプログラミングまたはコードを使用することによって実装されてもよく、特定用途向け集積回路、プログラマブル論理デバイス、フィールドプログラマブルゲートアレイ、光学システム、化学システム、生物学システム、量子力学システム、またはナノ工学システムを使用することによって、構成要素およびメカニズムが、使用されてもよい。一般に、本発明の機能は、当技術分野において公知のような任意の手段によって達成することができる。例えば、分散またはネットワーク化システム、構成要素、および回路を使用することができる。別の例では、データの通信または転送（または別様に、ある場所から別の場所に移動する）は、有線、無線、または任意の他の手段によるものであってもよい。

「コンピュータ読み取り可能な媒体」は、命令実行システム、装置、システム、またはデバイスによって、あるいはそれらと併せて使用するために、プログラムを含み、記憶し、通信し、伝搬し、もしくは転送することができる任意の媒体であってもよい。コンピュータ読み取り可能な媒体は、限定ではなく、単なる一例として、電子システム、磁気システム、光学システム、電磁システム、赤外線システム、または半導体システム、装置、システム、デバイス、伝搬媒体、あるいはコンピュータメモリであることができる。そのようなコンピュータ読み取り可能な媒体は、概して、機械読み取り可能であり、ヒト読み取り可能（例えば、ソースコード）または機械読み取り可能（例えば、オブジェクトコード）であり得るソフトウェアプログラミングまたはコードを含むものとする。

「プロセッサ」は、データ、信号、または他の情報を処理する任意のハードウェアシステム、メカニズム、または構成要素を含む。プロセッサは、汎用中央処理ユニット、複数の処理ユニット、機能性を達成するための専用回路、または他のシステムを伴うシステムを含むことができる。処理は、地理的位置に限定されることも、時間的制限を有することも必要ない。例えば、プロセッサは、「リアルタイム」、「オフライン」、「バッチモード」等でその機能を行うことができる。処理の一部は、異なる時間および異なる場所で、異なる（または、同一の）処理システムによって行われることができる。

また、図面／図に描写される要素のうちの１つ以上は、特定のアプリケーションに従って有用であるように、より分離された様式または統合された様式において実装されるか、あるいは、特定の場合には、除去されるかまたは動作不能にさえされ得ることを理解されたい。加えて、図面／図の任意の信号矢印は、別様に具体的に記載されない限り、限定ではなく、例示にすぎないと見なされるべきである。

さらに、用語「ｏｒ（または）」は、本明細書で使用される場合、別様に示されない限り、概して、「ａｎｄ／ｏｒ（および／または）」を意味すると意図される。本明細書で使用される場合、「ａ」または「ａｎ」（および、先行詞が「ａ」または「ａｎ」であるときは、「ｔｈｅ」）によって先行される用語は、そのような用語の単数形および複数形の両方を含む（すなわち、「ａ」または「ａｎ」の参照は、単数形のみまたは複数形のみを明確に示す）。また、本明細書の説明で使用される場合、「ｉｎ（の中に）」の意味は、文脈によって明確に別様に示されない限り、「ｉｎ（の中に）」および「ｏｎ（の上に）」を含む。

効果、他の利点、および問題の解決策について、特定の実施形態に関して、前述された。しかしながら、効果、利点、問題の解決策、および任意の利益、利点、または解決策を生じさせる、あるいはそれらがより顕著となり得る、任意の構成要素は、必須、必要、または不可欠な特徴または構成要素と解釈されるべきではない。

Claims (21)

1. プロセッサと、
   メモリと、
   ハードウェア内に記憶された秘密キーと、
   セキュアモードにおいて、前記プロセッサ上で実行されるプロセスのデータを含むラインを有する、キャッシュと、
   前記プロセスのみが前記キャッシュのラインにアクセスすることができるように、前記秘密キーに基づき、かつ、前記プロセスと関連付けられた第１のセキュア記述子を使用して、前記キャッシュのラインへのアクセスを制御するように構成されている、セキュア実行コントローラと
   を備える、システム。
2. 前記システムは、前記第１のセキュア記述子に基づいて、セキュアモードに置かれた、請求項１に記載のシステム。
3. 前記セキュア実行コントローラは、前記プロセスの作業セット全体が前記キャッシュ内に記憶され、前記キャッシュ以外のメモリ位置への書込が、前記セキュアモードでは、無効にされることをもたらすように構成されている、請求項１に記載のシステム。
4. 前記プロセスは、終了している、請求項１に記載のシステム。
5. 前記セキュア実行コントローラは、前記キャッシュのラインが前記プロセスと関連付けられた前記第１のセキュア記述子と関連付けられることをもたらすように構成されている、請求項３に記載のシステム。
6. 前記セキュア実行コントローラは、前記プロセスが前記データを書き込むとき、前記キャッシュのラインと関連付けられたセキュリティフラグが設定されることをもたらすように構成されている、請求項５に記載のシステム。
7. 前記セキュア実行コントローラは、
   前記キャッシュのラインが現在実行中のプロセスによってアクセスされていることを決定することと、
   現在実行中のプロセスがセキュアモードで実行中であるかどうかを決定することと、
   前記現在実行中のプロセスと関連付けられた第２のセキュア記述子を決定することと、
   前記第２のセキュア記述子と前記第２のセキュア記述子とを比較することと、
   前記現在実行中のプロセスがセキュアモードで実行中であり、かつ、前記第１のセキュア記述子が前記第２のセキュア記述子と整合する場合のみ、アクセスを可能にすることと
   を行なわせることによって、アクセスを制御するように構成されている、請求項６に記載のシステム。
8. セキュアモードにおいて、プロセッサ上でプロセスを実行することと、
   データをキャッシュのライン内に記憶することであって、前記データは、前記セキュアモードにおいて、前記プロセッサ上で実行されるプロセスによって記憶された、ことと、
   前記プロセスのみが前記キャッシュのラインにアクセスすることができるように、前記プロセスと関連付けられた第１のセキュア記述子を使用して、前記ラインへのアクセスを制御することであって、前記第１のセキュア記述子は、前記プロセッサおよび前記キャッシュを含むシステム上のハードウェア内に記憶された秘密キーに基づいている、ことと
   を含む、方法。
9. 前記第１のセキュア記述子に基づいて、前記セキュアモードに入った、請求項８に記載の方法。
10. 前記プロセスの作業セット全体を前記キャッシュ内に記憶することと、前記セキュアモードでは、前記キャッシュ以外のメモリ位置への書込を無効にすることとをさらに含む、請求項８に記載の方法。
11. 前記プロセスは、終了している、請求項８に記載の方法。
12. 前記プロセスと関連付けられた前記第１のセキュア記述子と前記キャッシュのラインとを関連付けることさらに含む、請求項１０に記載の方法。
13. 前記プロセスが前記データを書き込むとき、前記キャッシュのラインと関連付けられたセキュリティフラグを設定することをさらに含む、請求項１２に記載の方法。
14. 前記アクセスを制御することは、
    前記キャッシュのラインが現在実行中のプロセスによってアクセスされていることを決定することと、
    現在実行中のプロセスがセキュアモードで実行中であるかどうかを決定することと、
    前記現在実行中のプロセスと関連付けられた第２のセキュア記述子を決定することと、
    前記第２のセキュア記述子と前記第２のセキュア記述子とを比較することと、
    前記現在実行中のプロセスがセキュアモードで実行中であり、かつ、前記第１のセキュア記述子が前記第２のセキュア記述子と整合する場合のみ、アクセスを可能にすることと
    を含む、請求項１３に記載の方法。
15. 非一過性のコンピュータ読み取り可能な媒体であって、前記コンピュータ読み取り可能な媒体は、
    セキュアモードにおいて、プロセッサ上でプロセスを実行することと、
    データをキャッシュのライン内に記憶することであって、前記データは、前記セキュアモードにおいて、前記プロセッサ上で実行されるプロセスによって記憶された、ことと、
    前記プロセスのみが前記キャッシュのラインにアクセスすることができるように、前記プロセスと関連付けられた第１のセキュア記述子を使用して、前記ラインへのアクセスを制御することであって、前記第１のセキュア記述子は、前記プロセッサおよび前記キャッシュを含むシステム上のハードウェア内に記憶された秘密キーに基づいている、ことと
    のための命令を含む、コンピュータ読み取り可能な媒体。
16. 前記第１のセキュア記述子に基づいて、前記セキュアモードに入った、請求項１５に記載のコンピュータ読み取り可能な媒体。
17. 前記プロセスの作業セット全体を前記キャッシュ内に記憶することと、前記セキュアモードでは、前記キャッシュ以外のメモリ位置への書込を無効にすることとのための命令をさらに含む、請求項１５に記載のコンピュータ読み取り可能な媒体。
18. 前記プロセスは、終了している、請求項１５に記載のコンピュータ読み取り可能な媒体。
19. 前記プロセスと関連付けられた前記第１のセキュア記述子と前記キャッシュのラインとを関連付けることのための命令をさらに含む、請求項１７に記載のコンピュータ読み取り可能な媒体。
20. 前記プロセスが前記データを書き込むとき、前記キャッシュのラインと関連付けられたセキュリティフラグを設定することのための命令をさらに含む、請求項１９に記載のコンピュータ読み取り可能な媒体。
21. 前記アクセスを制御することは、
    前記キャッシュのラインが現在実行中のプロセスによってアクセスされていることを決定することと、
    現在実行中のプロセスがセキュアモードで実行中であるかどうかを決定することと、
    前記現在実行中のプロセスと関連付けられた第２のセキュア記述子を決定することと、
    前記第２のセキュア記述子と前記第２のセキュア記述子とを比較することと、
    前記現在実行中のプロセスがセキュアモードで実行中であり、前記第１のセキュア記述子が前記第２のセキュア記述子と整合する場合のみ、アクセスを可能にすることと
    を含む、請求項２０に記載のコンピュータ読み取り可能な媒体。
    

Images