JP6402034B2 - コンピュータ内の情報を安全に保つシステム及び方法 - Google Patents

Description

本発明は、コンピュータセキュリティ、特にソフトウェア及びハードウェアコンポーネントの完全性及びプライバシーの信頼の確立に関する。

電子コンピューティングが始まって以来、ユーザデータ等のデータは言うまでもなく、コンピュータを含むハードウェア及び/又はソフトウェアは故意に又は不注意に破壊されるという終わりなき懸念が存在している。この問題の中心は信頼できるか信頼できないかである。現代のコンピュータ、サーバ、モバイルデバイス等で実行されるソフトウェア、ハイパーバイザ（仮想コンピュータシステムにおける）、オペレーティングシステム（ＯＳ）及びアプリケーション等は、例えば、それらを実行するハードウェアを信頼できると仮定し、ソフトウェアが情報をメモリに記憶するとき、その情報は次にメモリから読み出されるときにも同一で、攻撃者により改ざんや漏洩がされてないことを期待している。

プラットフォームのモジュール化の増加とともに、人間オペレータ又はハードウェアコンポーネントはその実行帯域外でソフトウェアの状態を変更することが可能である。例えば、Ｉ／Ｏバス（例えば、ＰＣＩバス）を介してメインメモリに接続されたすべてのデバイスは、共有領域への書き込み及び読み出しのみならずメインメモリに格納されている、アプリケーションのプライベート状態からの書き込み及び読み出しによってソフトウェアと通信することができる。これらの及び他の多くの理由のために、特にそれらのソフトウェアを実行するため及びそれらを実行するシステムの構築のためにますます多くの組織がサービスプロバイダ又は製造者に依存しているので、今日では信頼の問題は以前よりもより一般的になっている。

攻撃者はアプリケーションの状態を変更することなく監視するだけでソフトウェアシステムに首尾よく侵入することができる。このような攻撃の一例は、メモリに格納されたデータ（例えばクレジットカード番号、個人識別情報等）を監視するだけであり、パスワード等の証明書にアクセスする必要はない。別の例は「コールドブート」攻撃として知られ、この攻撃は、電源を切っても記憶内容が短時間保持されるというシステムメモリ（特にＤＲＡＭ）の物理特性を利用するものである。このような攻撃では、人はしばしば電源の喪失又はリセットを生じさせるだけでシステムのリブートを強制することができ、その後データが潜在する間に小型の（ＵＳＢベース）ＯＳにリブートし、セキュアであるはずのハードウェアからのデータを監視又はコピーすることができ、或いはまた、ユーザは一つのホストからメインメモリデバイスを素早く除去し、それを別のホストに装着してその内容を読み出すことができる。コールドブート攻撃は、例えばhttp://citp.princeton.edu/memory/で説明されている。ソフトウェアの状態、即ちメモリの内容を監視することによって、攻撃者は秘密及び証明情報（例えば鍵情報）を取得することができ、その後攻撃者はソフトウェアスタックの正面ドアから入ることが可能になる。

従って、コンピュータ科学の全部門が信頼の問題に対する解決策（ソリューション）を見つけることに専念している。その概念及び試行された解決策の幾つかは以下の通りである。

「休止データ（data-at-rest）」の暗号化は、ストレージバックエンドにあるデータ、即ち所定の瞬時にデバイス間で転送されないか処理されないデータを暗号化するものである。この方法は不揮発性ストレージのほぼ全体を暗号化する比較的容易で簡単な方法を提供するが、現在処理中又は使用中のデータを保護しない。更に他の欠点として、「休止」データの暗号化のために使用する鍵をデータと一緒に格納し保持しなければならず、鍵自体がメモリ内にある間に窃盗を受け、全体として暗号が解読され得る。

「クリプトプロセッサ」はコンピュータの初期から使用されている。大まかに言えば、従来の現代のクリプトプロセッサは暗号化処理をサポートする内蔵ハードウェアを含むある種のマイクロプロセッサ（スマートカードを含む）である。要するに、既存のクリプトプロセッサベースのセキュリティ解決策は専用又は専門のハードウェアに依存し、一般的にはプロセッサ回路自体に対する変更にも依存している。このコンセプトの一つの変形は「インラインプロセッサＲＡＭ暗号化」であり、これはＣＰＵが暗号化ロジックをキャッシュ回路に統合する問題に対するハードウェアベースのアプローチであり、キャッシュデータが追い出される（エビクトされる）かフィルされる（満たされる）ときに暗号化／復号化を可能にする。コモディティオペレーティングシステムはいくつかの既知のクリプトプロセッサ上で動作するが、今のところ、ｘ８６アーキテクチャに対して、フルメモリ暗号化と言う意味でのクリプトプロセッサ実装は存在しない。

信頼される コンピューティング グループ（ＴＣＧ）（http://www.trustedcomputinggrup.org）は、システムブート後に、又はインテルのＴＸＴ（Trusted ExcecutionTechonology）(http://download.Intel.com./technology/security/downloads/315168.pdf)の場合には、ソフトウェアコンポーネントが測定された環境内で実行することを決定するときに、プロセッサ上で実行を開始したソフトウェアを証明することができる解決策に取り組んでいる。しかしながら、システムが測定したコードの実行を開始すると、ＴＣＧフレームワークはもはや追加の実行時保護を提供しない。

「メッセージ暗号化」は、ホスト又は他のソフトウェアエンティティが公衆ネットワークを介して専用通信することを可能にするセキュア通信（例えば、ＶＰＮ、ＩＰｓｅｃ、ＳＳＬ）のシステムコンセプトである。これは「データ・イン・モーション（data-in-motion）」に対する暗号化の一形式であることに注意されたい。この方法は２つのエンティティ間で転送されるデータに一定レベルのセキュリティを提供するが、転送前又は後に処理されるデータを保護するように設計されておらず、適切でない。

データ、特にｘ８６内部状態、をメインメモリから隠すためにＣＰＵ内に専用ストレージの使用を試みる様々な研究が始まっている。一つの例はＴＲＥＳＯＲであり(http://www.usenix.org/events/sec11/tech/full_papers/muller.pdf)、これは「フローズンキャッシュ」への参照を含んでいる。この領域の研究は一部のデータをＲＡＭへの到達から保護する能力を証明しているが、ソフトウェアスタック全体ではない。それゆえ、この解決策は、攻撃者がＲＡＭへ暴露される他のデータを容易に変更することができるとともにすべての秘密を暴露するようにそのソフトウェアコンポーネントを変更することができるという弱点を有する。

「ページカラーリングによるキャッシュ管理」（http://en.Wikipedia.org/wiki/cache_coloring）はキャッシュ内容を単一ｘ８６プロセッサ上で動作する多数のアプリケーション間で分割する方法である。この方法は、物理ページの全体セットを「キャッシュ配列に関する限り」コンフリクトしないことが「知られている」ページに分割し、各アプリケーションがカラーＡを有するページの１つのプールからのみ割り当てると仮定すると、そのアプリケーションはカラーＢを有するページの別のプールから割り当てる別のアプリケーションと決して競合しない。このように、カラーＡを用いるアプリケーションはカラーＢを用いるアプリケーションと関連するキャッシュデータの追い出しを生じず、逆も同様であるが、所与のプール内のどのページが今現在キャッシュ又はシステムメモリ内に存在するかに関して何の保証も提供しない。

図１は本発明の主要ハードウェア及びソフトウェアコンポーネント並びにオペレーションの主要原理を示す。 セキュリティ／検証コンポーネントをＣＰＵキャッシュ内に完全に又は部分的に存在するシステムソフトウェアの一部分とし得る実施形態の一例を示す。 代表的な実施形態における様々なハードウェア及びソフトウェアコンポーネントによるシステムメモリとのインタラクションを示す。

本発明の様々な実施形態はより緩やかな要件及び前提で動作し得るが、最も広義には、本発明は、ＣＰＵキャッシュ内に含まれ、プロセッサコアへ又はプロセッサコアから転送されるデータ及び／又は命令を暗号化／復号化及び／又は検証／認証する「エージェント」（ソフトウェア又はファームウェア）を提供する。従って、本発明は、メインプロセッサ自体に搭載されたソフトウェアとして具体化されるクリプトプロセッサ（特定のハードウェアサポート又は変更を必要としない）を提供する。従って、このキャッシュソフトウェアモジュール／エージェントはＣＰＵコアの周囲にソフトウェア「ウォール」を構成し、これは処理のために暗号化されてない形でコアに入来する命令及びデータを利用可能にするが、ＣＰＵがそれをシステムメモリ、デバイスメモリ等の任意の外部モジュールに格納する前に全ての送出データを暗号化する。このおかげで、高々限定された製造者レベルの例外（下記参照）で、実行時間中信頼される必要がある唯一のソフトウェア（ファームウェアの概念も含む）又はハードウェアはプロセッサ及びエージェントを定義するコードである。この考察に関連して、「信頼される（トラステッド）」とは、メインプロセッサがその仕様に従って動作し、関連するソフトウェアスタックを好適に利用可能なプロセッサ使用から逸脱することなく実行することを期待されていることを意味する。換言すれば、メインプロセッサ自体はキャッシュしたソフトウェアへの攻撃を可能にするかもしれない裏口がないことで信頼される。この側面によれば、システム全体の信頼のレベルは、キャッシュしたエージェントを一緒に有するメインプロセッサ自体の信頼と同じである。この場合、エンドユーザは、人間オペレータも悪意のハードウェア又はソフトウェアも機密データ又はアプリケーションを攻撃できないことを知りつつ、任意のアプリケーションを読み込み（ロードし）、機密情報を処理することが可能になる。

信頼のレベルに対する他の可能な制限は実行時のＣＰＵの状態を検査する悪意の主体の理論的能力に由来する。しかしながら、概して、動作しているＣＰＵの内部状態の改ざんは困難で費用のかかる操作であるため、本明細書に記載するシステムが可能な信頼のレベルは従来の解決策よりも一層大きい。

プロセッサ（キャッシュしたエージェントを共に有する）が唯一の信頼されるコンポーネントである場合、コンポーネント及び人間オペレータが仕様に従って作業していると信じる場合にのみ信頼できる既存のシステムと比較して複雑さが大幅に減少する。もちろん、人間オペレータはコンピュータコンポーネントと同様に「検査」することはできず、これは信頼をもっと困難にする。すべてのコンポーネント及び人を信頼できる場合でも、依然としてそれらの動作がソフトウェアスタックのプライバシー及び完全性を支持するかどうかを監視し評価する必要がある。要するに、チェーン内の多くの異なるリンクの完全性を信頼することは、強いことが知られている単一リンクの完全性を信頼するよりもはるかに難しい。

一実施形態では、既存のソフトウェア解決策（ハイパーバイザ、オペレーティングシステム及びアプリケーション）をソフトウェアスタックの最下位のコンポーネント、例えばオペレーティングシステム（ＯＳ）又はハイパーバイザの小さな変更のみで動作させることができる。特に、本実施形態では、エージェントはそれ自体ＯＳ／ハイパーバイザのコンポーネントとして、キャッシュ管理モジュール又はこのモジュールの一部として含められ、実行時にキャッシュに常駐する。これは汎用アプリケーションに対するサポート及びレガシーアプリケーションに対するサポートを提供する。これは「ハードウェア・セキュリティ・モジュール」（ＨＳＭ）(http://en.wikipedia.org/wiki/hardware_security_module)と対照的であり、このモジュールは特定のアプリケーションを保護するように設計された専用の外部コンポーネントであるが、任意のアプリケーションを実行できない限定プログラミングインタフェースを有する。

一般に、本発明は現在のシステムにインストールされているシステムメモリより遥かに小さいメインプロセッサキャッシュの使用に焦点を合わせている。この新しいアーキテクチャで実行するためには２つの変更をソフトウェアスタックに行う必要鵜がある。これらの変更はＯＳ／ハイパーバイザに行うことができ、どちらもメインプロセッサ上で直接動作する。第１に、ＯＳ/ハイパーバイザのいずれにも、ハードウェアにより送られるインタラプトを処理するある種のコード及びアプリケーションによりトリガされるソフトウェアフォールトがある。この「常時存在する」コードは一般にメインメモリキャッシュ内に収めることができる。第２に、最新のＯＳ／ハイパーバイザは大きなメインメモリを前提とするが、この前提は絶対的な要件ではなく、アプリケーションは極めて限定された量の物理メモリしか利用可能でない場合でも、例えば仮想メモリの助けで正しく働く可能性が高いが、ＯＳ／ハイパーバイザの変更を行わないと性能は損なわれる。

様々な態様によれば、メインメモリのどの部分がキャッシュを占有できるかをソフトウェアエージェントが常に制御するようにメインプロセッサキャッシュを管理するシステム及び方法が提供される。いくつかのプロセッサが既にこのようなグラニュラ制御を可能にするように設定され、このような場合には設定された命令及び手順を用いてこの機能を実装することができる。しかしながら、いくつかのメインプロセッサはそれらのメモリキャッシュのグラニュラ制御が欠けているため、任意の所定の時間にメモリのどの部分がキャッシュを占有するかをソフトウェアエージェントが制御できる状態にメインプロセッサを操作するために注意深いソフトウェアアルゴリズムを必要とする。

ｘ８６プロセッサはグラニュラキャッシュ制御を欠くプロセッサの一例である。ｘ８６クラスのプロセッサは当業界において周知であり、例えばインテルから入手可能な「intel 64 and IA-32 Architecture Software Developer’s Manual, Volume 3: System Programming Guide」に記載されているメモリキャッシュ制御を有する。しかしながら、キャッシュ内容のセキュリティを達成するために、メインプロセッサは、キャッシュラインがまさに追い出されようとするたびにソフトウェアスタックに通知する必要があり、これによりソフトウェアスタックはそのキャッシュラインがメインメモリに追い出される前にそのキャッシュラインを変更することができる。ｘ８６はこのようなソフトウェア通知が欠けている。

図１は本発明の様々な態様を具体化できるコンピュータシステムの概略図である。本システムの中心はメインプロセッサＣＰＵ１０００であり、メインプロセッサＣＰＵ１０００は周知のコンポーネント及び回路を用いて命令を受信し処理する少なくとも１つのコア１１００を含む。ＣＰＵは、内部クロック回路からＡＬＵまで、多くの種々のコンポーネントを含むが、それらは周知であるため、それらがＣＰＵ１０００の一部分であるとしても図に示されていない。

オペレーティングシステム（ＯＳ）及び／又はハイパーバイザ２０００等のシステムレベルソフトウェアは一般に周知の機能を実行するために含まれる。仮想マシン６２００及びアプリケーション６３００はＯＳ／ハイパーバイザ２０００の監視の下で動作するものとして示されている。ハイパーバイザは、仮想マシンが含まれない場合には、一般に不要であるが、この２つは単に完全を期すために図１にオプションとして示されている。種々のデバイス６７００も含むことができ、それは例えばストレージ、ネットワーク、ヒューマンインタフェース、チップセットなどの既知のデバイスのほとんどを含み得る。通常、ハードディスクシステムのようなある種のストレージ６１００がシステムメモリ７０００のような一般的でなく持続的でないが高速であるメモリデバイスと一緒に含まれる。

図１において、システムメモリ７０００は単一のコンポーネントＭＥＭとして示されているが、これは単に明瞭化のためであり、ほとんどの実施形態では、システムメモリ７０００は種々の高速度メモリデバイスを備え、例えばメインシステムメモリ用のスタンドアロン、専用メモリ、異なるデバイスの内蔵メモリの何れかとして含めることができる。ＲＡＭ、フラッシュメモリ、フラッシュバックＲＡＭ、相変化メモリ（ＰＣＭ）及び他のメモリ技術も本発明の目的のために一般用語「システムメモリ７０００」で網羅されるものとする。それゆえ、ＣＰＵの観点からすれば、システムメモリ７０００はアドレス可能メモリ空間であり、１つのコンポーネント内に収める必要はなく、また連続にする必要もない。

一般的なコンピュータシステムは、アドレスバス、データバス、場合によっては専用Ｉ／Ｏバス等の種々のバス４０００を含む。１以上のデバイスがリモートである場合には、一般にある種のネットワークチャネル、バス、又はインテルＱＰＩ（Quick Path Interconnect）などのポイントツーポイント相互接続が存在し、これは簡単のために別個に示されていない。

本発明に必須のコンポーネントはキャッシュ５０００であり、これはＣＰＵ１０００の一部である。キャッシュの一般構造及び特性はコンピュータ科学の分野において周知であるため、ここではこれ以上説明しない。

しかしながら、エージェント５１００は本発明に独自であり、これは暗号化／復号化モジュール５１１０及び任意選択の検証モジュール５１２０を含むソフトウェアコンポーネントである。一実施形態では、エージェント５１００はシステムソフトウェア２０００内のソフトウェアコンポーネントであり、実行時にキャッシュ５０００に存在する。幾つかの実施形態では、システムソフトウェア２０００は様々なキャッシュ関連タスクも実行するキャッシュ管理モジュール２１００を含むことができ、その場合には、エージェント５１００はこのようなキャッシュ管理モジュール２１００と同一にするかそのサブコンポーネントにすることができる。エージェント５１００はシステムソフトウェア内の専用コンポーネントとして含めるか、他の任意の適切なシステムソフトウェアコンポーネントに組み込むことができる。別の実施形態では、エージェント５１００はキャッシュ内に常駐する独立のコンポーネントとすることができ、その場合にはキャッシュ管理モジュール２１００は不要にすることができ、ＯＳ／ハイパーバイザは非変更システムソフトウェア層とすることができる。

異なるプロセッサアーキテクチャは必然的に異なるキャッシュ構造を有し、一部のアーキテクチャは２つ以上のキャッシュ構造を有する。本発明の目的のためには、選択の自由があれば、キャッシュ管理モジュール２１００／エージェント５１００を定義するコードのすべてを保持するに十分な大きさのキャッシュを選択するのが好ましい。なぜなら、この選択によりキャッシュとメインメモリとの間のトラヒック（メモリ−ディスクスワッピング及びページングと同様）及びそれに伴う暗号化／復号化アクティビティの増大が減少するためである。しかしながら、エージェントの全コンポーネントとともに任意の他のキャッシュしたソフトウェアを一度にキャッシュに収めることができないかもしれないことを受け入れる意思がある場合には、他のキャッシュを選択することもできる。多くの既存のプロセッサでは、ＬＬＣ（ラストレベルキャッシュ）が一般に最大であるため、このキャッシュが最も適している。ｘ８６システムでは、これはＬ３キャッシュであり、少なくとも部分的に下位レベルＬ１及びＬ２を含むため、下位レベルキャッシュが失敗すると、このキャッシュはメモリから直接ではなく次のレベルのキャッシュから読み出す。

破線で示されるように、コアに供給され且つコアから返送される命令及びデータはエージェント５１００にとって可視的で、且つエージェント５１００によりインターセプトすることができることが明示されている。本発明の一つの態様によれば、情報（データ及び／又は命令）がＣＰＵから、特にコア１１００又は他の内部ＣＰＵコンポーネントから、送信されるとき、この送信はエージェント５１００で遮断され、その情報がＣＰＵ１０００の論理境界外のシステムメモリ７０００に戻される前に、エージェントモジュール５１１０で暗号化される。ＣＰＵコア又は内部コンポーネントに入った命令及びデータは次に、それらが処理のために送出される前に、エージェント５１１０により復号化される。幾つかの実施形態では、すべての受信及び送信情報（ＣＰＵからみて）は暗号化及び復号化することができるが、他の実施形態ではこの暗号化及び復号化はシステムメモリ７０００の所定の部分に対してのみ実行することができる。システム設計者はモジュール５１１０がどのような暗号化及び復号化アルゴリズムを使用するか自由に選択することができる。このとき設計者は、エージェントにとってキャッシュ内の利用可能サイズ及び高レベルの暗号セキュリティを得るためにどの程度性能を犠牲にできるかなどの要素を考慮する。適切な処理手順（プロシージャ）は、暗号鍵を一般的にはキャッシュ５０００自体内に、好ましくは鍵の使用時にのみ格納するように実装される。

キャッシュしたエージェント５１００を経てＣＰＵとメインシステムメモリとの間を通る情報のすべてのバイトを個別に暗号化／復号化することは一般に無益であり、許容し得ない性能の劣化を生じる。代わりに、より大きなグラニュラリティ（粒度）が一般に好ましい。ｘ８６システムでは、通常、例えば仮想メモリサブシステムが情報をページレベルで移動させる。一実施形態では、それゆえエージェント５１００はフルページのグラニュラリティでアクセスをトラップし、殆どのソフトウェア実行はページサイズのトラヒックを発生させるため、エージェントは一般にページごとに暗号化及び復号化を行う。この動作は、例えば（仮想化された実施形態において）ソフトウェアの実行を促進するためハイパーバイザにシステムメモリの次の部分を取得するよう命令するために発生するページフォールトを検出することによってトリガすることができる。

アプリケーション実行に加えて、エージェント５１００はキャッシュ内に収めることができなくなるほど大きくなり得る自己のメタデータを有することができる。このようなメタデータは暗号化された形でメインメモリに格納し、エージェントにより積極的にアクセスすることができ、ページフォールトによりトリガする必要はなく、その結果このようなアクセスは同じページサイズのグラニュラリティにする必要はない。

エージェントはソフトウェアをＣＰＵ上で直接実行する必要はなく、むしろエージェントはソフトウェア、例えば非変更仮想マシン及びアプリケーションを解釈するように設定することができる。これはエージェントがソフトウェアによるメモリアクセスの必要を積極的に検出することを可能にするとともに、このようなメモリへの読み込みを小さいチャンク（塊）で可能にし、それによってスループット及び性能が向上する。これは設計上の選択であり、このような既知の技術をプリフェッチング及びコードスキャニングとして含むこともできる。使用可能なインタプリタの一例はｘ８６命令セットのインタプリタである。

システムソフトウェア２０００、仮想マシン６２００及びアプリケーション６３００は多くの場合図１のようなシステム図において個別のエンティティとして概念化されるが、これらは当然のことながら実際にはデータ及びコードのそれぞれの本体であり、それらは “１”又は“０”の任意の他の本体としてシステムストレージ６１００内に格納され、システムソフトウェア２０００の制御の下での実行のために全体として又はページのような単位として高速システムメモリ７０００に読み込まれる。それゆえ、それぞれのメモリアドレス位置にあるそれらのコード及びデータの内容を性能向上のために他のどれよりもＣＰＵによってキャッシュすることができる。しかしながら、この点の一つの他の重要性は、エージェント５１００は、システムメモリに格納される任意の他の情報と同様に、このようなソフトウェアコンポーネントを定義するコードも安全にすることができることにある。

この点でも、本発明と既知の解決策との差異が理解できる。少なくとも、ＣＰＵ自体を初期化するために必要な常時存在するコードを除けば、図示の実施形態はメインプロセッサ１０００の一部分以外の如何なるハードウェア又はソフトウェアコンポーネントの一部分へのアクションも必要としない。一つの他の重要な差異は、エージェント５１００はキャッシュ５０００に常駐するソフトウェアモジュールとして実装できることである。要するに、エージェント５０００はコモディティ処理システムを、ハードウェアの変更を必要とすることも、実行時にＣＰＵ外部に信頼できるハードウェア又はソフトウェアを必要とすることもなく、クリプトプロセッサに変換することができる。

ＣＰＵからシステムメモリへ送信される情報のキャッシュベース暗号化はこのような情報のセキュリティを保証することができるが、暗号化だけではその完全性を保証することができず、暗号化情報でも改ざんすることができ、また偶然に変更され得る。それゆえ、図１にも示すように、エージェント５１００は検証ソフトウェアモジュール５１２０も含み、このモジュール５１２０はモジュール５１１０が暗号化しシステムメモリに格納したものと関連するある種の検証データを計算する。この検証データはチェックサムのような簡単なものとすることができるが、殆どの場合、ハッシュ値、メッセージ認証コード（ＭＡＣ）又は暗号化された情報の各ブロック（例えばページ）と関連するディジタル署名を計算するために任意の既知のメッセージ統合アルゴリズム用いてより安全にする。検証モジュール５１２０はその後同じメモリブロックに対して検証データを再計算し、再計算された検証データを先に計算され格納された検証データと比較して、任意の変化を検出する（これは不一致により示される）。この検証処理手順は、メモリブロックが読み出されるときに背景プロセスとして、又はシステム設計者が望む他のスケジュールで実行することができる。

暗号化は厳密には検証を必要とせず、逆も同様である。従って、エージェントは検証のみを行うように、或いは暗号化と検証の両方を選択的に可能にするように設定することができる。換言すれば、エージェントは暗号化／復号化モジュール５１１０、又は検証モジュール５１２０、又はその両方（図１に示す実施形態及び最もセキュアな好ましい実施形態）を含むことができる。検証のみの実施形態に関しては、この実施形態は、プライバシーは不要もしくは希望しないが、データ完全性は必要もしくは希望する環境において有効である。検証のみの実施形態でもハードウェアプロセッサの信頼できるキャッシュ内のエージェントという本発明の最高レベルの概念の利点を依然として有している点に注意されたい。

モジュール５１１０及びモジュール５１２０の両方及び対応する機能を含む実施形態でも、これらの選択を可能にすることができる。例えば、ユーザはデータのプライバシーの維持を希望することができ、その場合には暗号化モジュールはデータがメモリに書き込まれる前にそのデータを暗号化するが、ユーザはコモディティオペレーティングシステム又はアプリケーションの既によく知られたコードのような他の情報の暗号化／復号化の性能コストを（わずかであっても）負担することは希望しないことができる。しかしながら、暗号化されてないメモリブロック（例えばページ）が改ざんされてないことを確認するのが望ましく、そのような場合には検証だけで十分とすることができる。この場合、簡単なインデックス付きリストのような適切なデータ構造をエージェントに含めて、特定のメモリブロック（例えばページ）が暗号化及び／又は検証すべきかあるいは暗号化済み及び/又は検証済みであるかを示すことができる。

図２は、エージェント５１００がＯＳ/ハイパーバイザ２０００のキャッシュ管理モジュール２１００のサブコンポーネントである実施形態を実行時に示したものである。換言すれば、この実施形態では、ＯＳ／ハイパーバイザ２０００はエージェント５１００を既存のキャッシュ管理モジュール２１００（他の無関係な機能を含む場合もある）の一部分として、又はキャッシュ管理モジュール自体として含むように変更される。キャッシュ管理モジュール２１００はＯＳ／ハイパーバイザへのアクセスが許されるページのリスト、ページレンジ等を維持し、キャッシュをアクティブに管理し、例えばキャッシュは決して失敗しないことをパフォーマンスカウンタにより監視し、エラーが発見された場合に処置する。

図２に示すように、実行時に、ＯＳ／ハイパーバイザ２０００は一般に少なくとも部分的にキャッシュ５０００に読み込まれ、これは従来のシステムにおいても普通のことである。所定の実施形態ではそれらの相対的なサイズに依存してＯＳ／ハイパーバイザ２０００は完全にはキャッシュ５０００内に収まらない可能性がある。そのような場合、図２に示すようにＯＳ／ハイパーバイザ２０００の陰影付きの上部が論理的にキャッシュ５０００の外にはみ出る場合、ＯＳ／ハイパーバイザ２０００の一部分は必要とされるまで９１００として示される暗号化されたシステムメモリ領域に格納しておくことができる。図に示すように、ＶＭ６２００及びアプリケーション６３００等のユーザレベルソフトウェアも、システムソフトウェア２０００と同時にキャッシュ５０００に読み込むことができ、必要に応じ、対応するコードの部分（陰影付き部分）は暗号化されたシステムメモリ領域９１００へ又はシステムメモリ領域９１００において少なくとも一時的に退出又は残存させることができる。これは、通常のコンピュータにおいてメモリページがシステムメモリとディスクストレージとの間で頻繁にスワップされる態様に類似する。しかしながら、本発明の全ての特徴、特に、ＣＰＵ及びエージェントだけは信頼される（トラステッドである）必要があるという特徴を適正に機能させるためには、エージェント５１００の全部を実行時間中キャッシュに常駐させるのが好ましい。

グラニュラキャッシュ制御が欠けているメインプロセッサのためにキャッシュ内容を管理する方法の一例は以下の通りである。
１．キャッシュの幾何配置（ジオメトリ）及び連想（アソシアティビティ）を、例えばサポートされたインタフェースを用いて又は直接評価により決定する（例えば、一つの既知の技術は異なるサイズのメモリ領域へのアクセス時間を測定する；キャッシュヒットがキャッシュミスより遥かに速い）
２．物理アドレスで動作する一般的なキャッシュに対してキャッシュ内に共存し得る物理ページの最大セットを決定する。キャッシュメモリをインデックスするために代わりに仮想アドレスを使用する（場合によっては追加の物理アドレスタグを使用する）プロセッサに対して、エージェント５１００はマップされたメモリの全部がキャッシュ内に同時に共存できることを保証するように仮想アドレスの割り当てを管理すべく設定することができる。
３．発見された物理ページのセットを、例えばハイパーバイザ，ＯＳ又はアプリケーションにより使用される仮想アドレスに割り当てることができる唯一のページとして維持する。しかしながら（以下に記載するように）、一つの代案として、仮想対物理ページマッピング及び/又は物理メモリの特定領域はキャッシュ不能としてマークすることができ、従って唯一のキャッシュページが共存し得る物理ページのセット（上記のステップ２参照）内の１つであれば、任意のマッピングも可能であることに注意されたい。

キャッシュ内容を管理する手順の別の例は以下の通りである。
１．キャッシュの幾何配置（ジオメトリ）及び連想（アソシアティビティ）を、例えば既知のサポートされたインタフェースを用いて又は直接評価により決定する。
２．キャッシュが物理アドレスで動作することに注意しながらキャッシュ内に共存し得る物理ページの最大セットを決定する。上記の方法では、代わりに仮想アドレスを使用して（場合によっては追加の物理アドレスタグを使用する）、キャッシュメモリをインデックスするプロセッサに対して、エージェント５１００は、仮想アドレスの割り当てを管理すべく設定して、マップされたメモリの全部がキャッシュ内に同時に共存できることを保証する。
３．決定された物理ページのセットを、例えばハイパーバイザ，ＯＳ又はアプリケーションにより使用される仮想アドレスに割り当てることができる唯一のページとして維持する。上述したように、代案として、仮想対物理ページマッピング及び／又は物理メモリの特定領域はキャッシュ不能としてマークすることができることに注意されたい。
４．上述したページのセット外の任意のメモリを読み出すために、ＯＳ又はハイパーバイザは任意のサポートされたプロセッサ方法を使用して、キャッシュをバイパスしながらメモリをＣＰＵレジスタ内に読み込むことができる。一旦コピーされたメモリがプロセッサレジスタ内に入れば、レジスタ内容はキャッシュを占める物理ページの１つにコピーしても安全である。
５．上述したページのセット外の任意のメモリを書き込むために、ステップ４に対して逆の論理を使用する。
６．ＣＰＵをＤＭＡによるアクセスから保護するために、ＩＯＭＭＵ（ｘ８６アーキテクチャ等の多くの現在のプロセッサアーキテクチャに設けられている）又は他のＣＰＵ特有方法を、キャッシュ占有ページへのＤＭＡを阻止するように設定する。

特定のアドレス又はレンジのアドレスへのアクセス時にキャッシュのバイパスを可能にする様々な方法が知られている。いくつかあるアーキテクチャの中で特にｘ８６に利用可能なこのような方法の例には、ｘ８６プロセッサに所定のメモリ領域をキャッシュしないように命令することができるメモリタイプレンジレジスタ（ＭＴＴＲ）、個々のページのキャッシングを制御するＭＭＵに対するＰＡＴ拡張子、及びＭＯＶＮＴＤＱ及びＭＯＶＮＴＤＱＡ等の特殊非一時的読み込み及び記憶命令がある。

ほとんどの既存のx８６システムでは、ＣＰＵキャッシュに共存できる物理ページのセットは複数のキャッシュサイズで始まる連続するページセットである。例えば、キャッシュサイズが８ＭＢである場合、第１のページセットは（０−８）ＭＢのシステムアドレス空間を占めるページであり、第２のページセットは（８−１６ＭＢ）のシステムアドレス空間を占め、以下同様である。この特徴は、ソフトウェアスタックはテストしたページセット内に収まると仮定して、所定の物理ページセットが共存できるかどうかを検査するために様々な方法で活用することができる。これは様々な方法で達成することができ、例えばプロセッサキャッシュパフォーマンスカウンタ又はハードウェアバスアナライザ（即ち「メモリプロトコルアナライザ」）の何れかを用いてキャッシュ追い出しが生じたかどうかを決定することによって達成することができる。これらの方法は、具体的には以下の通りである。

プロセッサキャッシュパフォーマンスカウンタを用いて、
１．キャッシュした内容を無効にする。
２．検査すべきページセット内のすべてのバイト（又は他のメモリ単位）を読み出す。
３．プロセッサキャッシュパフォーマンスカウンタの値（キャッシュミスの数）を記録する。
４．ステップ２を繰り返す。即ち、すべてのバイト（又は他のメモリ単位）を再度読み出す。
５．プロセッサキャッシュパフォーマンスカウンタの値（キャッシュミスの数）を再び読み出す。
６．その結果を比較する。キャッシュミスの数がステップ３と同数である場合、これは全レンジの再読み出しが全くミスを生じなかったことを示すため、すべてのページはキャッシュに共存していたとする。

ハードウェアバスアナライザを用いて、
１．検査すべきページセット内のすべてのバイト（又は他のメモリ単位）を読み出す。
２．バスアナライザを用いて、メインプロセッサによるメインメモリへの如何なるアクセスも測定開始する。
３．ステップ１を繰り返す。
４．バスアナライザの結果を分析する。特に、ページセット内のアドレスからの如何なる読み出しも検索する。そのレンジ内に読み出しがなければ、すべてのページはキャッシュに共存していたとする。

キャッシュミスが起こったかどうかを決定する他の方法もあり、上で概説した方法の代わりに使用できる。その一例はメモリの非キャッシュコヒーレント読み出し（キャッシュのバイパス）を実行しうるデバイスを使用するものである。

別の代替方法は、ｘ８６ＩＮＶＤ命令を用いてキャッシュ内容を無効にし、次に関連するシステムメモリページを検査していずれかのラインが書き戻されたかどうかを確かめるものである。特に、キャッシュ領域は初期パターンで満たし、その後ＷＢＩＮＶＤによりメモリにフラッシュ（書き出す）することができる。キャッシュ領域はその後個別のテストパターンで満たされ、キャッシュはＩＮＶＤ命令により無効にされる。キャッシュをバックアップするメモリはその後検査され、どのラインが追い出されたかに関する情報を用いてキャッシュ内でコンフリクトするページのセットを決定し、非コンフリクトページのセットを検出することができる。この決定方法の一例は、オリジナルパターンを含まないキャッシュラインはテストパターンの書き込み時にコンフリクト（競合）のために追い出されたはずであることを監視するものである。

上記のキャッシュ検査は所定の実装上の選択に応じて異なる時間に実行することができる。一実施形態では、例えばキャッシュ検査は各プロセッサ設定に対してオフラインで手動的に実行することができる。別の実施形態では、読み込み可能なリナックスカーネルモジュールでコンフリクト検査を実行することができる。他の実施形態では、キャッシュ検査は、キャッシュ管理／エージェントソフトウェアが最初に読み込まれるとき、起動時に実行することができる。更に他の実施形態では、このような検査は、実行時にセキュアなＯＳ／ハイパーバイザにより追加の保護層として周期的に実行し、予期せぬキャッシュ追い出しを検出する（これにより、後で更に説明するように、それらを急速に中止させ、機密データの暴露時間を低減することができる。）。

更に他のアプローチは、キャッシュミスパフォーマンスカウンタを使用する代わりとして、メモリアクセスを計時してキャッシュミスを検出する（例えばｘ８６ＲＤＴＳＣを用いて「リードタイムスタンプカウンタ」命令を用いる）。

最新のインテルｘ８６プロセッサ（「Sandy Bridge」のコードネームで始まる）はいわゆる「コンプレックスキャッシュアドレシング」を使用し、そのハードウェアはメモリアドレスをハッシュ化してそれがキャッシュ内に存在するかどうかを決定する。換言すれば、このようなシステムではページカラーリングは最早働かない。このようなシステムでは、非コンフリクトページのセットを計算する方法は一般に上で概説した生成・検査処理手順を必要とする。

多くの共通システムでは、現在のハイパーバイザ又はＯＳを、使用が許される物理ページのセットに制約として与え、ハイパーバイザ又はＯＣがその制約を尊重し、実行のために所与のページのみを参照することを見込む。しかしながら、ハードウェアデバイスがＣＰＵキャッシュの状態を読み出すのを防止するために追加のステップが通常必要とされる。規定値（デフォルト）により、デバイスは通常任意のシステムアドレスからの読み出しのためにＤＭＡ（ダイレクトメモリアクセス）要求を発行することができる。そのメモリがたまたま例えばｘ８６システム内のＤＭＡ−キャッシュ−コヒーレントＣＰＵによりキャッシュされた場合、ＣＰＵはこのようなメモリにアクセスことが可能になり、これは信頼モジュールを破り、ソフトウェア状態を暴露することになる。

ＩＯＭＭＵ（Ｉ／Ｏメモリマネジメントユニット）１３００はソフトウェアで設定可能なデバイスであり、ハードウェアデバイスがシステムアドレスにアクセスするのを制限して、デバイスが明示的に割り当てられなかった（マップされなかった）メモリの読み出し又は書き込みを行うことができないようにすることができる。多くのコモディティプロセッサはＩＯＭＭＵをそのＣＰＵ回路の一部分として含む。他の場合には、別個のコンポーネントであり、その場合にはそのセキュリティを確保するために既知の手段を講じる必要がある。ＩＯＭＭＵに加えて、ある種のＣＰＵはＤＭＡ保護を提供し得る他の技術、例えばインテルｘ８６ＴＸＴ技術を有している。従って、ＤＭＡ保護を提供する１つの方法はＩＯＭＭＵを使用するが、他のＣＰＵ固有の代替技術を用いて本発明の様々な実施形態を実装することもできる。それゆえ、デバイスによるＣＰＵキャッシュへのアクセスを軽減するために、ＩＯＭＭＵはこのようなアクセスを阻止するように設定することができる。これは通常、キャッシュを占有するページセット内の各ページがマッピングを持たないように、又は無効アドレスレンジ、例えばいかなるデバイス又はシステムアドレス空間内のメモリによってもマップされないアドレスへのマッピングを持つようにＩＯＭＭＵを設定することによって行われる。通常動作では、ソフトウェアスタックはキャッシュを占有するメモリからの読み出しに何のデバイスも必要としないため、通常動作は予期できる。しかしながら、悪意のハードウェアデバイスがソフトウェア状態を読み出そうとする場合、これはＩＯＭＭＵにより防止される。その一つの例外は、キャッシュを占有するページであって、デバイスとのＩ／Ｏ通信のためにソフトウェアスタックにより意図的に選択される幾つかのページである。このようなページに対して、ＩＯＭＭＵはこれらのページにハードウェアデバイスがアクセスできるようにこれらのページをマップするように設定される。このようなページがある一つの理由は、幾つかの旧ハードウェアデバイスはアドレス空間の少量にしかアドレスできないからであり、例えばＩＳＡデバイスはシステムアドレス空間の最初の１６ＭＢにしかアドレスできない。従って、このようなデバイスとの通信はキャッシュ内にあるメモリを用いて起こる必要がある。

しかしながら、Ｉ／Ｏのためにキャッシュ内の所定のページへのアクセスが許可されるときでも、デバイスに対するアクセスが許可されるページはＩ／Ｏ通信に間に合う時点で使用されるページのみである。Ｉ／Ｏ通信が完了すると、ＩＯＭＭＵ保護を再び確立することができ、そのページは他の目的、例えば他のソフトウェアコードを実行するために使用できる。エージェントはＩ／Ｏに使用されているページを知っていてそれを適宜処理できるので、これはセキュリティリスクにならない点に注意されたい。

エージェント５１００はＣＰＵキャッシュ５０００に読み込まれた実行可能なコードを含み、このキャッシュはＣＰＵの最初の起動時又はリセット後に空であるため、どのようにエージェントに安全に読み込むという問題が生じる。各プロセッサアーキテクチャはこの問題に対処する様々な方法を有し、熟練設計士はそれらについて知っているが、説明のために、本発明は現在のｘ８６アーキテクチャに基づくシステムに実装するものと仮定する。上述したように、インテルは現在、信頼される実行技術（トラステッド・エグゼキューション・テクノロジ）（ＴＸＴ）を提供し、これは信頼されるプラットフォームモジュール（ＴＰＭ）チップをｘ８６型ＣＰＵのハードウェア拡張として含んでいる。ＴＸＴはＴＰＭを有するシステム上で起動するソフトウェアを認証する既知の方法である。幾つかの提案によれば、ＴＰＭは将来、ＣＰＵ自体に組み込まれる。図１はそれらをＴＸＴ３０００及びＴＰＭ３１００として示している。

エージェント５１００の安全な読み込みを準備する一つの方法は以下の通りである。０）信頼されるシステムを用いて、エージェントとして読み込むべきコードのハッシュ値を計算し、これを安全に格納する。
１）エージェントローダコードをシステムメインメモリに他のアプリケーションと同様に読み込む。この段階では、エージェントコードはメインメモリにおいて見えるかもしれないので、悪意の攻撃を受けるかもしれない。
２）インテル指定の、よって既知のＴＸＴ技術のオペレーションに従って、エージェントローダコードをＭＬＥ（メジャード・ラウンチ・エンバイロンメント）において実行してエージェント５１００をキャッシュ５０００に読み込み、エージェントハッシュ値をＴＰＭ３１００に記録する。ＭＬＥはＤＭＡからのエージェントローダコーダ全体の保護を提供する。この段階ではメモリ内に読み込まれた秘密情報は存在せず、エージェントローダコードのみが存在する。
３）キャッシュしたエージェントコードを再ハッシュし、リモートシステムを介して（好ましくは専用ネットワークエージェントを通じて）ＴＰＭと通信し、この再ハッシュ値を先に格納されたエージェントハッシュ値と比較する。両ハッシュ値が一致する場合、キャッシュしたエージェントは認証され、実行時に変更されずに動作することが知られる。
４）今ではエージェントは安全に読み込まれ、すべての実行はＣＰＵキャッシュ内でのみ起こるため、個人情報（記憶鍵、ＶＭ画像等）を、エージェント５１００を実行するホストに送ることができる。ＣＰＵはＣＰＵ自体の外部と通信する必要なしに暗号鍵を安全に生成し、キャッシュに存在させることができる点に注意されたい。

図３は、一般的な実施形態における様々なハードウェア及びソフトウェアコンポーネントによるシステムメモリとの相互作用を示し、更に本発明がシステムメモリとの動作のみならず、自身のメモリを含むＩ／Ｏデバイスとの動作をどのようにサポートするかも示す。図３は更に安全／プライベートシステムメモリアドレス領域（９０００）と安全でなく潜在的に悪意のシステムメモリアドレス領域（９００１）との区別も示す。

安全／プライベートメモリ９０００に関しては、概して、キャッシュ５０００内に現在あるメモリは安全にアクセスできる、即ち信頼できるとみなせる。エージェントにより暗号化されたメモリ内の情報は、キャッシュ情報という意味で信頼できないが、それにもかかわらず暗号化及び更なる検証のおかげで安全である。スタック内のソフトウェアはこのようなアドレス領域を、それらはアドレスするシステムメモリが物理アドレスであるとみなすが実際にはキャッシュ５０００内にあり、信頼できるという意味で安全とみなす。換言すれば、ソフトウェアスタックは、システムメモリを通常通りにアドレスするが実際にはキャッシュ５０００をアドレスすると考える。

モジュール５１１０（図１）による暗号化は、これらのメモリ領域に格納される情報（仮想マシン６２００及びアプリケーション６３００の状態のような情報及びキャッシュ５０００に収まらないＯＳ／ハイパーバイザ２０００の部分を含む）の機密性をもたらし、モジュール５１２０（図１）による検証はデータの完全性をもたらすが、実際の可用性は保証されない点に注意されたい。従って、悪意のエンティティは依然としてコード又はデータを改ざんできるが、この改ざんは上述したように検出され、改ざんは影響を受けたブロックに対してハッシュ又は他の検証データの不一致を生じる。検証モジュール５１２０及びその関連動作なしでも、暗号化された形で格納される実行可能コードの改ざんは、殆ど確実に検出可能なランタイムエラー又は影響を受けたコードの明白な失敗を生じ、更に前進する。

図３において、ソフトウェアスタック２０００，６２００，６３００はキャッシュの外部として示されている。これは単に説明のためである。上述したように、実行時にＯＳ／ハイパーバイザ２０００、特にエージェント５１００の大部分又は好ましくは全部のみならず、通常の性能上の理由のためにＯＳ／ハイパーバイザ２０００がキャッシュに読み込むために選択するスタックの他の部分（例えばＶＭ６２００及び／又はアプリケーション６３００）も信頼されるキャッシュ５０００内に存在する。

非暗号化メモリ領域９００１は信頼できず、攻撃から安全でない。一般に、キャッシュ内に現在存在しないメモリは安全でないとみなせ、プライバシー及び完全性攻撃を阻止するためにエージェントにより暗号化しなければならない。信頼されない（アントラステッドな）メモリ空間９００１は通常のシステムにより使用される通常のシステムメモリを含む。特別な属性をこのようなメモリ空間内の特定のアドレスと関連付ける必要はなく、よってそれらの特別な属性はコード（好ましくはコード自体ではないが）、ストレージ又はデバイスＩ／Ｏを実行することによって使用することができる。上述したように、信頼されないメモリ空間は暗号化／検証された実行可能なコードを格納するためにも使用でき、このコードはエージェント５１００による再検証及び復号化後にページインされ実行されるようにすることができる。

非暗号化システムメモリは全システムの唯一のマッピング可能なメモリではない。デバイス６７００が何であるか及びデバイスがどのようの構築されるかに応じて、それらは、例えばそれらの専用の一般的に基板に乗ったデバイスメモリ６７１０（例えばビデオカード上のメモリ）にアクセスすることができる。従来のシステムでも、デバイスメモリ６７１０をＩ／Ｏデバイス以外の目的のためにマッピングすることはまれであり、特にコードは一般的にデバイスメモリから実行されない。ＣＰＵキャッシュ５０００はシステムアドレスへのアクセスを提供するので、アドレスの一部はシステムメモリにより全くバックアップされないかもしれず、代わりに、システムメモリの一部分ではなく理論的にそのようなものとして使用することができるデバイスメモリ６７１０、例えば５１２ＭＢのビデオカードによりバックアップされてもよい。

デバイスはＤＭＡ Ｉ／Ｏチャネル９６００を経て信頼されないシステムメモリアドレス空間９５１０にアクセスすることもできる。しかしながら、信頼されるセットアップでは、ＤＭＡ保護９２０１（例えばＩＯＭＭＵ１３００により提供される（図１参照））はＣＰＵキャッシュを占有するシステムアドレスレンジへのアクセスを阻止するように設定される。これはＩ／Ｏチャネル９６００から出てＤＭＡ保護モジュール９２１０で「跳ね返る」矢印により示されている。このＩＯＭＭＵ保護機構は上で詳細に記載されている。

図３に示す暗号化ストレージ領域９６１０は単なる非専用メモリである。システムメモリを一般に信頼しないシステムに対しては、暗号化スワップストレージ等の暗号化ＲＡＭディスクを格納するために９６１０のような領域を信頼されないストレージ領域として含めるのが有益である。これは低速ストレージデバイスに比較して性能を向上することができ、限定されたプロセッサキャッシュサイズを補償することができる。

ＣＰＵキャッシュをバックアップするシステムメモリ領域は９５００として示されている。一例として、この領域は、例えば偶発的な書き戻しによりキャッシュから何のメモリもシステムメモリへ漏れ戻されないことを示す零又は他のパターン（例えば、ランダム生成ビット、その場合にはその後の再計算及び検証のためにシードを格納する必要がある）を含むことができる。換言すれば、エージェントによる後の検査時に、システムメモリ領域９５００が同じパターンを含まない場合、システムは何らかのキャッシュ漏洩があったことを知ることになる。オールゼロ以外のいくつかのパターンは、リセットが正しい状態と混同しない利点を有する。このバックアップメモリ領域９５００は、キャッシュ内にも暗号化領域にもないので、依然として信頼できないが、依然として上述したエージェントにより安全に使用することができる。

非コンフリクトメモリ９５００の領域はエージェント５１００の初期読み込み中も使用することができる。キャッシュバックアップメモリ領域９５００を使用する処理手順の一例は次のステップを含む。
１． ＴＯ：ＯＳ／ハイパーバイザ２０００のカーネルイメージがメモリ領域９５００に読み込まれる。この時点では、領域９５００内の全ての情報は平文であり、つまり、どの情報もまだ安全でない。
２． Ｔ１：ＯＳ／ハイパーバイザカーネルは、エージェント５１００を初期化し、（エージェント５１００はその後カーネルを非コンフリクトページのセットのみに制限するように物理メモリのキャッシュ特性を管理する）、ＩＯＭＭＵを設定し、適切な実行時状態に入る。
３． Ｔ２：エージェント５１００はキャッシュでバックアップされるメモリ領域９５００を、追い出し・検出・フィル・パターンで満たす。
４． Ｔ３−Ｔｎ：システムはキャッシュのみから実行される。キャッシュをバックアップするメモリ領域９５００は実行状態の暗号化バージョンではなく、むしろフィルパターンを含む「ステイル（古い）」メモリである。エージェント５１００は周期的にメモリ領域９５００を検査し、このフィルパターンが無傷であるかどうか及び従って幾つかのキャッシュラインがエビクションのために漏洩したかどうかを検査する。

キャッシュは整列した連続データチャンク（キャッシュラインとも称される）で動作することが知られている。例えば、現在のｘ８６プロセッサでは６４バイトが共通のキャッシュラインサイズであり、キャッシュとシステムメモリとの間のデータの移動はキャッシュラインのグラニュラリティで起こる。プロセッサキャッシュは一般にセットアソシアティブ法で編成され、各キャッシュインデックスはＮ個のキャッシュラインまでＮウェイセットアソシアティブキャッシュに格納することができる。現在のｘ８６プロセッサに対して、Ｎは一般に８又は１６である。プロセッサは一般的にメモリアドレスからキャッシュインデックスへの決定論的マッピングを使用するため、システムメモリ内の多数のラインは同じキャッシュインデックスにマッピングされるが、キャッシュはそれらのうちのＮまでを一度に保持することができるのみである。同じキャッシュインデックスにマッピングするＮより多数のメモリアドレスがアクセスされるとき、それらはすべてがキャッシュ内に同時に収まるわけではなく、キャッシュエビクションが生じる。現在のプロセッサは、システムメモリからの新たなアクセスラインのための空間を作るためにどのキャッシュ済みラインを追い出すべきかを最長時間未使用（ＬＲＵ）ポリシー（又は一種の近似）を用いて決定している。変更されたライン（「ダーティ」ラインとして知られている）が追い出されるとき、そのラインはシステムメモリに書き戻される。一般に、プロセッサはキャッシュ追い出し又は書き戻しに介入する何の方法もソフトウェアに供給しない。

本発明は、Xi Chen, Robert P. Dick, and Alok Choudhary, “Operating System Controlled Processor-Memory Bus Encryption”, in Proceedings of Design, Automation and Test in Europe, (DATE 2008), Munich, Germany, March 2008, or the CARMA system (cited below)，に記載されている「バス暗号化」により必要とされように、キャッシュ内容の部分をロックダウンする特別のハードウェアサポート又はプロセッサモードの存在に依存しない。

制御されない（アンコントロールド）キャッシュ追い出しは信頼されないキャッシュメモリからのデータを信頼されないシステムメモリへ漏洩し、プライバシーを侵害する。また、追い出されたラインへの次のアクセスは信頼されないステムメモリからのデータを信頼されるキャッシュに読み込み、攻撃者が完全性を侵害することが可能になる。その結果、コード及びデータの両方のプライバシー及び完全性を保護するために有効なキャッシュ管理が不可欠である。従って、一つの重要な課題は、追い出しがキャッシュをコンフリクトしないようにすることであり、関連の取り組みにおいて議論されていない問題である。これは、キャッシュ可能なメモリの部分を注意深く選択し、キャッシュ不可能なメモリの残部をマークすることを伴う。一般に、プロセッサメモリ管理ユニット（ＭＭＵ）１２００（図１）は、ソフトウェアが一般にキャッシュラインよりずっと大きいページのグラニュラリティで、メモリを制御し、マッピングし及び保護することを可能にする。例えば、最小ページサイズはｘ８６プロセッサで４０９６バイトである。

この問題に対処する一つの方法は、（１）非コンフリクトページのセットを見つけ出し、（２）現在のソフトウェアを実行するためにこれらのページのみを使用する。その理由は、これらのページのみがこれらのページのキャッシュをＣＰＵに許可するというキャッシュポリシーを有し、システム内の残りのページはキャッシュを阻止するというキャッシュポリシーを有するためである。非コンフリクトとして見つけ出す必要があるページのセットは、これまでキャッシュにマップされたことがあるページのみであるため、データが信頼されないメモリの残部から読み出されるときでも、そのデータは依然として、キャッシュに置かれないように且つ一般に現在キャッシュに存在するメモリの追い出しを生じないように読み出される。

非コンフリクトページのセットはメモリアドレスをキャッシュインデックスにマッピングするプロセッサで使用される特定の機能に依存し、これは更にプロセッサ実装の詳細に依存する。ある場合には、キャッシュ構成（サイズ及び連想（アソシアティビティ））が一旦決定されると、マッピングはページカラーリングにより計算及び制御される。最新のインテルｘ８６プロセッサ（”Sandy bridge”で始まる）のような他の場合には、マッピングはプロセッサベンダにより公開されていない不透明な複素ハッシュ関数である。その結果、非コンフリクトページの適切なセットを見つけ出すために実験的な取り組みが必要とされ、ひいてはコンフリクトを検出する信頼できる処理手順が必要とされる。プライベートコア社は、システムメモリから非コヒーレントな読み出しを実行するためにキャッシュをバイパスする方法及びハードウェア性能カウンタの監視を含む方法等の幾つかの追い出し検出技術を開発している。生産システム作動中に実行時の追い出しを検出する更なる能力も、予期せぬ漏洩を素早くキャッチしスクラブするとともに暴露時間を短くするために重要である。

この時点において、コンピュータセキュリティ分野のシステムレベルの技術者は、文献で提案されている他の解決策に対する本発明の様々な特徴の利点のいくつかを理解されよう。一つの明らかな利点は、本発明のソフトウェアのみによるアプローチは何も特別なハードウェアサポートを必要とせず、現在のｘ８６プロセッサベースのシステムのようなコモディティハードウェアとともに使用することもできる点にある。暗号化／復号化の特徴と検証の特徴の両方を実装する場合（任意）、開示されたシステムはシステム内のすべてのコード及びデータに対してプライバシー（機密性）及び完全性の両方を保証するように設計される。

上述した本発明の実施形態の信頼されるコンピューティングベース（ＴＣＢ）はプロセッサを超えて拡大する必要はなく、すべての他のハードウェアは信頼されず、潜在的に悪意であると明確に仮定する脅威モデルに従って動作することができる。しかしながら、安全な起動及び認証のために、ＴＣＢは好ましくはルート・オブ・トラストを確立するために必要なコンポーネント、例えばインテルの信頼される実行技術（ＴＸＴ）も含むべきであり、これは幾つかの実施形態ではプロセッサ外の信頼されるプラットフォームモジュール（ＴＰＭ）を含むことができる。

特に、システムメモリ自体は信頼されないと考えられ、その内容は攻撃者により読み出しや書き込みの攻撃を受けやすく、プライバシー又は完全性がそれぞれ侵害されると考えられる。同様に、プロセッサ外のすべての他のハードウェアデバイス及び相互接続は信頼されず、潜在的に攻撃者のコントロール下にある。例えば、ＤＭＡを実行し得る共通ネットワークインタフェースカード（ＮＩＣ）等の危険にさらされたＩ／Ｏデバイスは、メインメモリ又はキャッシュ内のコード及びデータの内容を故意に検査又は破壊することによってプライバシー又は完全性を侵害するために利用することができる。

本発明では、信頼される必要がある唯一のメモリはプロセッサ自体に物理的に一体化された部分であるプロセッサキャッシュであり、使用する他のメモリは暗号化することができ、またデバイスメモリ又は可能なＤＭＡの場合にはＩＯＭＭＵを用いて制御することができる。これは、Peter A. H. Peterson, “Cryptkeeper: Improving Security with Encrypted RAM”, in IEEE International Conference on Technologies for Homeland Security (HST 2010), November 2010に記載されているクリプトキーパシステムと対照的である。クリプトキーパはメインメモリを個別の平文部分と暗号化部分に分割し、キャッシュ内容を管理しようとせず、ＲＡＭ全体がキャッシュ可能である。その結果、クリプトキーパはその平文メモリ領域に対するプライバシーの保護に失敗し、性能を高めるためにある程度のメモリ内容の漏洩を許す明示的な選択を行うことになる。クリプトキーパがその平文のサイズをキャッシュに収まるように減少しても、暗号化領域へのアクセスは依然としてキャッシュ追い出しを誘起するため、平文データはメモリに漏れ戻る。クリプトキーパはまた完全性に対応せず、ＲＡＭの平文部分又は暗号化部分のコード及びデータを変更又は破壊する攻撃に対する保護を提供しない。

同様に、先に引用したChen他の文献に提案されているバス暗号化方式は、攻撃者は「メモリの内容を改ざんできない」とともに、「カーネルを変更できない」と仮定しているが、カーネルは、幾つかのエンベデッドシステムの場合と同様に、プロセッサ外のリードオンリー不揮発性メモリ内に存在すると考えられる。

本出願の優先権日後にのみ公開されたアプローチとの単なる比較として、Amit Vasudevan, Jonathan M. McCune, James Newsome, Adrian Perrig, and Leendert van Doom. "CARMA: A Hardware Tamper-Resistant Isolated Execution Environment on Commodity x86 Platforms", in Proceedings of the ACM Symposium on Information, Computer and Communications Security (ASIACCS 2012), Seoul, Korea, May 2012, に記載されたＣＡＲＭＡシステムは排他的にキャッシュメモリに依存しているため、 システムメモリは決してアクセスされず、存在させる必要はない。著者等は、「実行は完全にキャッシュ内で行われ、信頼されないＲＡＭと相互に作用しない」と明言しており、彼らはプロトタイプ実装におけるすべてのＤＲＡＭを除去することに成功している。この選択はＣＡＲＭＡによりサポートすることができる作業負荷のタイプを著しく制約するので、特にＣＡＲＭＡは本質的に、殆どが大きすぎてキャッシュに完全に収めることができない大きな汎用仮想メモリ、複雑なアプリケーション、又は変更されてないほとんどの市販ソフトウェアに役立たないものとなる。更に、Ｉ／Ｏデバイスに対するサポートの概念としてＣＡＲＭＡが含む唯一の機構は、受動デバイスへの入力／出力コマンドを介して、ＣＰＵ自体により起動される。これは、デバイスでもデータをＣＰＵと共有するために共有メモリを介してメモリ書き込みを開始することができる本発明と比較して厳しい制約である。

Tilo Muller, Felix C. Freiling, and Andreas Dewald, "TRESOR Runs Encryption Securely Outside RAM", in Proceedings of the 20th USENIX Security Symposium, San Francisco, California, August 201 1 に記載されたＴＲＥＳＯＲシステム（前述した）は、ディスク暗号鍵を安全に格納するというより限定的問題に対処するように設計されているためＲＡＭへの物理攻撃は暗号化されたディスク内容を危険にさらさない。ＴＲＳＯＲは暗号鍵をマシン固有の特権プロセッサレジスタ（ｘ８６デバグレジスタ）に格納し、如何なる機密情報もＲＡＭに格納することなくＡＥＳ暗号化アルゴリズムを実行する。システム内のすべてのコード及びデータのプライバシー及び任意選択で完全性を保護する本出願に記載する本発明のアーキテクチャと対照的に、ＴＲＥＳＯＲは暗号鍵のみを保護する。情報を安全に格納するために特権プロセッサレジスタを用いるアプローチは極めて少量の状態を超えるスケールにできず、ＴＲＥＳＯＲは、例えば単一のＡＥＳ−２５６鍵を保持するのにちょうど十分な２５６ビットを（４つの６４ビットデバグレジスタに）安全に格納できるのみである。ｘ８６デバグレジスタ機構の（誤）使用はハードウェアブレークポイント及びウォッチポイントに対する目的の用途を不可能にする。更に、コード及びデータ全体のプライバシー及び完全性は保護されないので、攻撃者はＴＲＥＳＯＲ実装を操作し、変更することにより、ＣＰＵデバグレジスタに格納された鍵へアクセスすることが可能である。

Claims (23)

1. コンピュータ内の情報を安全に保つシステムにおいて、
   命令を受信し実行するとともにデータを処理する少なくとも１つのコア（１１００）を含む中央処理デバイス（ＣＰＵ）（１０００）、
   前記ＣＰＵ内のキャッシュ（５０００）、
   システムメモリアドレス空間を有するシステムメモリ、
   前記ＣＰＵ上で動作し、前記システムメモリに格納された命令及びデータとして少なくとも部分的に具体化されるソフトウェアスタック（２０００、６２００、６３００）、及び
   前記キャッシュに格納されるエージェント（５１００）であって暗号化／復号化モジュール（５１１０）を備えるエージェント（５１００）を備え、前記暗号化／復号化モジュール（５１１０）は、
   前記ＣＰＵから送信された情報をインターセプトし、
   前記情報を暗号化し、
   当該暗号化された情報を前記ＣＰＵの論理境界外へ戻し、
   前記エージェントは、前記キャッシュの一部をロックダウンするプロセッサモードに依存すること無く、ソフトウェアクリプトプロセッサとして動作することを特徴とするシステム。
2. 請求項１記載のシステムにおいて、更に、
   前記エージェント（５１００）は前記情報をブロック単位で暗号化し、
   前記エージェントは、符号化され、格納された各情報ブロックと検証値を関連付ける検証モジュール（５１２０）を含む、
   ことを特徴とする請求項１記載のシステム。
3. 請求項２記載のシステムにおいて、更に、
   前記検証モジュール（５１２０）はその後各情報ブロックについて前記検証値を再計算し、前記再計算された前記検証値を先に関連付けられた対応する検証値と比較し、それによって前記検証モジュール（５１２０）は前記情報ブロックに対する如何なる変更も検出することができる、
   ことを特徴とするシステム。
4. 請求項１記載のシステムにおいて、更に、
   前記ソフトウェアスタックは前記キャッシュ（５０００）をバックアップする前記システムメモリアドレス空間の第１の部分上で動作し、前記ソフトウェアスタック内のエンティティによる前記第１の部分へアドレスされる読み出し又は書き込み要求は、システムメモリにアクセスすることなく前記キャッシュによって実行される、
   ことを特徴とするシステム。
5. 請求項４記載のシステムにおいて、更に、
   前記ソフトウェアスタックはシステムメモリ空間の第２の暗号化された部分（９０００）にもアドレスする、
   ことを特徴とするシステム。
6. 請求項１記載のシステムにおいて、更に、
   デバイスメモリ（６７１０）を含む少なくとも１つのＩ／Ｏデバイス（６７００）、及び、
   前記Ｉ／Ｏデバイスが前記エージェント（５１００）の監視の下で所定のＩ／Ｏ動作のために前記キャッシュにのみアドレスしアクセスするように設定されたＩ／Ｏメモリ管理部（１３００）を備える、
   ことを特徴とするシステム。
7. 請求項１記載のシステムにおいて、更に、
   Ｉ／Ｏチャネル（９６００）を介する直接メモリアクセス（ＤＭＡ）用に設定された少なくとも１つのＩ／Ｏデバイス（６７００）、及び
   前記キャッシュへのＤＭＡを阻止するように設定されたＩ／Ｏメモリ管理部（１３００）を備える、
   ことを特徴とするシステム。
8. 請求項１記載のシステムにおいて、更に、
   前記ソフトウェアスタック内の他のソフトウェアの実行前に前記エージェント（５１００）を前記キャッシュ（５０００）に安全に読み込むように設けられた信頼されるプロセッサモジュール（ＴＰＭ）コンポーネント（３１００）を備える、
   ことを特徴とするシステム。
9. 請求項１記載のシステムにおいて、更に、
   前記ソフトウェアスタックはハイパーバイザ及び少なくとも１つの仮想マシン（６２００）を含む、
   ことを特徴とするシステム。
10. 請求項１記載のシステムにおいて、更に、
    前記ソフトウェアスタックは変更されてないコモディティソフトウェアを実行するため
    に設けられたインタプリタを含む、
    ことを特徴とするシステム。
11. 請求項１記載のシステムにおいて、更に、
    前記エージェントは実行時間中、前記キャッシュに常駐することを特徴とするシステム。
12. 命令を受信し実行するとともにデータを処理する少なくとも１つのコア（１１００）を含む中央処理装置（ＣＰＵ）（１０００）、
    前記ＣＰＵ内のキャッシュ（５０００）、
    システムメモリアドレス空間を有するシステムメモリ、及び
    前記ＣＰＵ上で動作し、前記システムメモリに格納された命令及びデータとして少なくとも部分的に具体化されるソフトウェアスタック（２０００、６２００、６３００）を有するコンピュータ内の情報を安全に保つ方法において、
    前記キャッシュにエージェント（５１００）を読み込むステップと、
    前記ＣＰＵから送信された情報を前記エージェントによってインターセプトするステップと、
    前記情報を前記エージェントによって暗号化するステップと、
    当該暗号化された情報を前記エージェントによって前記ＣＰＵの論理境界外へ戻すステップと、
    を含み、
    前記エージェントは、前記キャッシュの一部をロックダウンするプロセッサモードに依存すること無く、ソフトウェアクリプトプロセッサとして動作することを特徴とする方法。
13. 請求項１２記載の方法において、更に、
    前記情報をメモリブロック単位で暗号化するステップ、
    検証データを計算し、前記検証データを暗号化された各メモリブロックと関連付けるステップを備える、
    ことを特徴とする方法。
14. 請求項１３記載の方法において、更に、
    前記メモリブロックはメモリページである、
    ことを特徴とする方法。
15. 請求項１３記載の方法において、更に、
    各情報ブロックについて前記検証データを再計算し、前記再計算した前記検証データを先に関連付けられた対応する検証データと比較するステップを備え、それにより前記情報ブロックに対する変更を検出する、
    ことを特徴とする方法。
16. 請求項１２記載の方法において、更に、
    前記ソフトウェアスタックを、前記キャッシュ（５０００）をバックアップする前記システムメモリアドレス空間の第１の部分上で実行するステップ、
    前記ソフトウェアスタック内のエンティティによる前記第１の部分へアドレスされる読み出し又は書き込み要求を、システムメモリにアクセスすることなく、前記キャッシュ内で実行するステップを備える、
    ことを特徴とする方法。
17. 請求項１６記載の方法において、更に、
    前記ソフトウェアスタックに、前記暗号化された情報部分を含む、前記システムメモリアドレス空間の第２の部分（９０００）にもアドレスすることを許すステップを備える、ことを特徴とする方法。
18. 請求項１２記載の方法において、更に、
    前記コンピュータは、デバイスメモリ（６７１０）を含む少なくとも１つのＩ／Ｏデバイス（６７００）を含み、
    前記Ｉ／Ｏデバイスに、所定のＩ／Ｏ動作に対してのみ前記キャッシュへアドレスし及びアクセスすることを許すステップを更に備える、
    ことを特徴とする方法。
19. 請求項１２記載の方法において、更に、
    前記コンピュータは、デバイスメモリ（６７１０）を含む少なくとも１つのＩ／Ｏデバイス（６７００）を含み、
    前記Ｉ／Ｏデバイスによる前記キャッシュへの直接メモリアクセス（ＤＭＡ）を阻止するステップを更に備える、
    ことを特徴とする方法。
20. 請求項１２記載の方法において、更に、
    前記ソフトウェアスタックにおける他のソフトウェアの実行前に前記エージェント（５１００）をキャッシュ（５０００）に安全に読み込む、
    ことを特徴とする方法。
21. 請求項１２記載の方法において、更に、
    前記システムメモリアドレス空間はメモリブロックに編成され、
    前記メモリブロックの非キャッシュコンフリクトセットを決定するステップ、及び
    前記非キャッシュコンフリクトセットと関連する前記システムメモリのみをキャッシュ可能としてマークし、それにより前記システムメモリによるキャッシュコンフリクトを防止するステップを更に備える、
    ことを特徴とする方法。
22. 請求項１２記載の方法において、更に、
    前記ソフトウェアスタック内の変更されてないソフトウェアを、インタプリタを用いて実行するステップを備える、
    ことを特徴とする方法。
23. 請求項１２記載の方法において、更に、
    キャッシュバックアップメモリ領域（９５００）にデータパターンを格納するステップ、及び
    前記キャッシュバックアップメモリ領域の内容を検査して前記データパターンの変化を決定し、前記キャッシュバックアップメモリ領域への前記キャッシュの内容の少なくとも一部分の追い出しを示すステップを備える、
    ことを特徴とする方法。

Images