【文献】
Xi Chen, Robert P. Dick, Alok Choudhary,Operating System Controlled Processor−Memory Bus Encryption,2008 esign,Automation and test in Europe,IEEE ,2008年 3月10日,1154−1159
(58)【調査した分野】(Int.Cl.,DB名)
【背景技術】
【0002】
電子コンピューティングが始まって以来、ユーザデータ等のデータは言うまでもなく、コンピュータを含むハードウェア及び/又はソフトウェアは故意に又は不注意に破壊されるという終わりなき懸念が存在している。この問題の中心は信頼できるか信頼できないかである。現代のコンピュータ、サーバ、モバイルデバイス等で実行されるソフトウェア、ハイパーバイザ(仮想コンピュータシステムにおける)、オペレーティングシステム(OS)及びアプリケーション等は、例えば、それらを実行するハードウェアを信頼できると仮定し、ソフトウェアが情報をメモリに記憶するとき、その情報は次にメモリから読み出されるときにも同一で、攻撃者により改ざんや漏洩がされてないことを期待している。
【0003】
プラットフォームのモジュール化の増加とともに、人間オペレータ又はハードウェアコンポーネントはその実行帯域外でソフトウェアの状態を変更することが可能である。例えば、I/Oバス(例えば、PCIバス)を介してメインメモリに接続されたすべてのデバイスは、共有領域への書き込み及び読み出しのみならずメインメモリに格納されている、アプリケーションのプライベート状態からの書き込み及び読み出しによってソフトウェアと通信することができる。これらの及び他の多くの理由のために、特にそれらのソフトウェアを実行するため及びそれらを実行するシステムの構築のためにますます多くの組織がサービスプロバイダ又は製造者に依存しているので、今日では信頼の問題は以前よりもより一般的になっている。
【0004】
攻撃者はアプリケーションの状態を変更することなく監視するだけでソフトウェアシステムに首尾よく侵入することができる。このような攻撃の一例は、メモリに格納されたデータ(例えばクレジットカード番号、個人識別情報等)を監視するだけであり、パスワード等の証明書にアクセスする必要はない。別の例は「コールドブート」攻撃として知られ、この攻撃は、電源を切っても記憶内容が短時間保持されるというシステムメモリ(特にDRAM)の物理特性を利用するものである。このような攻撃では、人はしばしば電源の喪失又はリセットを生じさせるだけでシステムのリブートを強制することができ、その後データが潜在する間に小型の(USBベース)OSにリブートし、セキュアであるはずのハードウェアからのデータを監視又はコピーすることができ、或いはまた、ユーザは一つのホストからメインメモリデバイスを素早く除去し、それを別のホストに装着してその内容を読み出すことができる。コールドブート攻撃は、例えばhttp://citp.princeton.edu/memory/で説明されている。ソフトウェアの状態、即ちメモリの内容を監視することによって、攻撃者は秘密及び証明情報(例えば鍵情報)を取得することができ、その後攻撃者はソフトウェアスタックの正面ドアから入ることが可能になる。
【0005】
従って、コンピュータ科学の全部門が信頼の問題に対する解決策(ソリューション)を見つけることに専念している。その概念及び試行された解決策の幾つかは以下の通りである。
【0006】
「休止データ(data-at-rest)」の暗号化は、ストレージバックエンドにあるデータ、即ち所定の瞬時にデバイス間で転送されないか処理されないデータを暗号化するものである。この方法は不揮発性ストレージのほぼ全体を暗号化する比較的容易で簡単な方法を提供するが、現在処理中又は使用中のデータを保護しない。更に他の欠点として、「休止」データの暗号化のために使用する鍵をデータと一緒に格納し保持しなければならず、鍵自体がメモリ内にある間に窃盗を受け、全体として暗号が解読され得る。
【0007】
「クリプトプロセッサ」はコンピュータの初期から使用されている。大まかに言えば、従来の現代のクリプトプロセッサは暗号化処理をサポートする内蔵ハードウェアを含むある種のマイクロプロセッサ(スマートカードを含む)である。要するに、既存のクリプトプロセッサベースのセキュリティ解決策は専用又は専門のハードウェアに依存し、一般的にはプロセッサ回路自体に対する変更にも依存している。このコンセプトの一つの変形は「インラインプロセッサRAM暗号化」であり、これはCPUが暗号化ロジックをキャッシュ回路に統合する問題に対するハードウェアベースのアプローチであり、キャッシュデータが追い出される(エビクトされる)かフィルされる(満たされる)ときに暗号化/復号化を可能にする。コモディティオペレーティングシステムはいくつかの既知のクリプトプロセッサ上で動作するが、今のところ、x86アーキテクチャに対して、フルメモリ暗号化と言う意味でのクリプトプロセッサ実装は存在しない。
【0008】
信頼される コンピューティング グループ(TCG)(http://www.trustedcomputinggrup.org)は、システムブート後に、又はインテルのTXT(Trusted ExcecutionTechonology)(http://download.Intel.com./technology/security/downloads/315168.pdf)の場合には、ソフトウェアコンポーネントが測定された環境内で実行することを決定するときに、プロセッサ上で実行を開始したソフトウェアを証明することができる解決策に取り組んでいる。しかしながら、システムが測定したコードの実行を開始すると、TCGフレームワークはもはや追加の実行時保護を提供しない。
【0009】
「メッセージ暗号化」は、ホスト又は他のソフトウェアエンティティが公衆ネットワークを介して専用通信することを可能にするセキュア通信(例えば、VPN、IPsec、SSL)のシステムコンセプトである。これは「データ・イン・モーション(data-in-motion)」に対する暗号化の一形式であることに注意されたい。この方法は2つのエンティティ間で転送されるデータに一定レベルのセキュリティを提供するが、転送前又は後に処理されるデータを保護するように設計されておらず、適切でない。
【0010】
データ、特にx86内部状態、をメインメモリから隠すためにCPU内に専用ストレージの使用を試みる様々な研究が始まっている。一つの例はTRESORであり(http://www.usenix.org/events/sec11/tech/full_papers/muller.pdf)、これは「フローズンキャッシュ」への参照を含んでいる。この領域の研究は一部のデータをRAMへの到達から保護する能力を証明しているが、ソフトウェアスタック全体ではない。それゆえ、この解決策は、攻撃者がRAMへ暴露される他のデータを容易に変更することができるとともにすべての秘密を暴露するようにそのソフトウェアコンポーネントを変更することができるという弱点を有する。
【0011】
「ページカラーリングによるキャッシュ管理」(http://en.Wikipedia.org/wiki/cache_coloring)はキャッシュ内容を単一x86プロセッサ上で動作する多数のアプリケーション間で分割する方法である。この方法は、物理ページの全体セットを「キャッシュ配列に関する限り」コンフリクトしないことが「知られている」ページに分割し、各アプリケーションがカラーAを有するページの1つのプールからのみ割り当てると仮定すると、そのアプリケーションはカラーBを有するページの別のプールから割り当てる別のアプリケーションと決して競合しない。このように、カラーAを用いるアプリケーションはカラーBを用いるアプリケーションと関連するキャッシュデータの追い出しを生じず、逆も同様であるが、所与のプール内のどのページが今現在キャッシュ又はシステムメモリ内に存在するかに関して何の保証も提供しない。
【発明を実施するための形態】
【0013】
本発明の様々な実施形態はより緩やかな要件及び前提で動作し得るが、最も広義には、本発明は、CPUキャッシュ内に含まれ、プロセッサコアへ又はプロセッサコアから転送されるデータ及び/又は命令を暗号化/復号化及び/又は検証/認証する「エージェント」(ソフトウェア又はファームウェア)を提供する。従って、本発明は、メインプロセッサ自体に搭載されたソフトウェアとして具体化されるクリプトプロセッサ(特定のハードウェアサポート又は変更を必要としない)を提供する。従って、このキャッシュソフトウェアモジュール/エージェントはCPUコアの周囲にソフトウェア「ウォール」を構成し、これは処理のために暗号化されてない形でコアに入来する命令及びデータを利用可能にするが、CPUがそれをシステムメモリ、デバイスメモリ等の任意の外部モジュールに格納する前に全ての送出データを暗号化する。このおかげで、高々限定された製造者レベルの例外(下記参照)で、実行時間中信頼される必要がある唯一のソフトウェア(ファームウェアの概念も含む)又はハードウェアはプロセッサ及びエージェントを定義するコードである。この考察に関連して、「信頼される(トラステッド)」とは、メインプロセッサがその仕様に従って動作し、関連するソフトウェアスタックを好適に利用可能なプロセッサ使用から逸脱することなく実行することを期待されていることを意味する。換言すれば、メインプロセッサ自体はキャッシュしたソフトウェアへの攻撃を可能にするかもしれない裏口がないことで信頼される。この側面によれば、システム全体の信頼のレベルは、キャッシュしたエージェントを一緒に有するメインプロセッサ自体の信頼と同じである。この場合、エンドユーザは、人間オペレータも悪意のハードウェア又はソフトウェアも機密データ又はアプリケーションを攻撃できないことを知りつつ、任意のアプリケーションを読み込み(ロードし)、機密情報を処理することが可能になる。
【0014】
信頼のレベルに対する他の可能な制限は実行時のCPUの状態を検査する悪意の主体の理論的能力に由来する。しかしながら、概して、動作しているCPUの内部状態の改ざんは困難で費用のかかる操作であるため、本明細書に記載するシステムが可能な信頼のレベルは従来の解決策よりも一層大きい。
【0015】
プロセッサ(キャッシュしたエージェントを共に有する)が唯一の信頼されるコンポーネントである場合、コンポーネント及び人間オペレータが仕様に従って作業していると信じる場合にのみ信頼できる既存のシステムと比較して複雑さが大幅に減少する。もちろん、人間オペレータはコンピュータコンポーネントと同様に「検査」することはできず、これは信頼をもっと困難にする。すべてのコンポーネント及び人を信頼できる場合でも、依然としてそれらの動作がソフトウェアスタックのプライバシー及び完全性を支持するかどうかを監視し評価する必要がある。要するに、チェーン内の多くの異なるリンクの完全性を信頼することは、強いことが知られている単一リンクの完全性を信頼するよりもはるかに難しい。
【0016】
一実施形態では、既存のソフトウェア解決策(ハイパーバイザ、オペレーティングシステム及びアプリケーション)をソフトウェアスタックの最下位のコンポーネント、例えばオペレーティングシステム(OS)又はハイパーバイザの小さな変更のみで動作させることができる。特に、本実施形態では、エージェントはそれ自体OS/ハイパーバイザのコンポーネントとして、キャッシュ管理モジュール又はこのモジュールの一部として含められ、実行時にキャッシュに常駐する。これは汎用アプリケーションに対するサポート及びレガシーアプリケーションに対するサポートを提供する。これは「ハードウェア・セキュリティ・モジュール」(HSM)(http://en.wikipedia.org/wiki/hardware_security_module)と対照的であり、このモジュールは特定のアプリケーションを保護するように設計された専用の外部コンポーネントであるが、任意のアプリケーションを実行できない限定プログラミングインタフェースを有する。
【0017】
一般に、本発明は現在のシステムにインストールされているシステムメモリより遥かに小さいメインプロセッサキャッシュの使用に焦点を合わせている。この新しいアーキテクチャで実行するためには2つの変更をソフトウェアスタックに行う必要鵜がある。これらの変更はOS/ハイパーバイザに行うことができ、どちらもメインプロセッサ上で直接動作する。第1に、OS/ハイパーバイザのいずれにも、ハードウェアにより送られるインタラプトを処理するある種のコード及びアプリケーションによりトリガされるソフトウェアフォールトがある。この「常時存在する」コードは一般にメインメモリキャッシュ内に収めることができる。第2に、最新のOS/ハイパーバイザは大きなメインメモリを前提とするが、この前提は絶対的な要件ではなく、アプリケーションは極めて限定された量の物理メモリしか利用可能でない場合でも、例えば仮想メモリの助けで正しく働く可能性が高いが、OS/ハイパーバイザの変更を行わないと性能は損なわれる。
【0018】
様々な態様によれば、メインメモリのどの部分がキャッシュを占有できるかをソフトウェアエージェントが常に制御するようにメインプロセッサキャッシュを管理するシステム及び方法が提供される。いくつかのプロセッサが既にこのようなグラニュラ制御を可能にするように設定され、このような場合には設定された命令及び手順を用いてこの機能を実装することができる。しかしながら、いくつかのメインプロセッサはそれらのメモリキャッシュのグラニュラ制御が欠けているため、任意の所定の時間にメモリのどの部分がキャッシュを占有するかをソフトウェアエージェントが制御できる状態にメインプロセッサを操作するために注意深いソフトウェアアルゴリズムを必要とする。
【0019】
x86プロセッサはグラニュラキャッシュ制御を欠くプロセッサの一例である。x86クラスのプロセッサは当業界において周知であり、例えばインテルから入手可能な「intel 64 and IA-32 Architecture Software Developer’s Manual, Volume 3: System Programming Guide」に記載されているメモリキャッシュ制御を有する。しかしながら、キャッシュ内容のセキュリティを達成するために、メインプロセッサは、キャッシュラインがまさに追い出されようとするたびにソフトウェアスタックに通知する必要があり、これによりソフトウェアスタックはそのキャッシュラインがメインメモリに追い出される前にそのキャッシュラインを変更することができる。x86はこのようなソフトウェア通知が欠けている。
【0020】
図1は本発明の様々な態様を具体化できるコンピュータシステムの概略図である。本システムの中心はメインプロセッサCPU1000であり、メインプロセッサCPU1000は周知のコンポーネント及び回路を用いて命令を受信し処理する少なくとも1つのコア1100を含む。CPUは、内部クロック回路からALUまで、多くの種々のコンポーネントを含むが、それらは周知であるため、それらがCPU1000の一部分であるとしても図に示されていない。
【0021】
オペレーティングシステム(OS)及び/又はハイパーバイザ2000等のシステムレベルソフトウェアは一般に周知の機能を実行するために含まれる。仮想マシン6200及びアプリケーション6300はOS/ハイパーバイザ2000の監視の下で動作するものとして示されている。ハイパーバイザは、仮想マシンが含まれない場合には、一般に不要であるが、この2つは単に完全を期すために
図1にオプションとして示されている。種々のデバイス6700も含むことができ、それは例えばストレージ、ネットワーク、ヒューマンインタフェース、チップセットなどの既知のデバイスのほとんどを含み得る。通常、ハードディスクシステムのようなある種のストレージ6100がシステムメモリ7000のような一般的でなく持続的でないが高速であるメモリデバイスと一緒に含まれる。
【0022】
図1において、システムメモリ7000は単一のコンポーネントMEMとして示されているが、これは単に明瞭化のためであり、ほとんどの実施形態では、システムメモリ7000は種々の高速度メモリデバイスを備え、例えばメインシステムメモリ用のスタンドアロン、専用メモリ、異なるデバイスの内蔵メモリの何れかとして含めることができる。RAM、フラッシュメモリ、フラッシュバックRAM、相変化メモリ(PCM)及び他のメモリ技術も本発明の目的のために一般用語「システムメモリ7000」で網羅されるものとする。それゆえ、CPUの観点からすれば、システムメモリ7000はアドレス可能メモリ空間であり、1つのコンポーネント内に収める必要はなく、また連続にする必要もない。
【0023】
一般的なコンピュータシステムは、アドレスバス、データバス、場合によっては専用I/Oバス等の種々のバス4000を含む。1以上のデバイスがリモートである場合には、一般にある種のネットワークチャネル、バス、又はインテルQPI(Quick Path Interconnect)などのポイントツーポイント相互接続が存在し、これは簡単のために別個に示されていない。
【0024】
本発明に必須のコンポーネントはキャッシュ5000であり、これはCPU1000の一部である。キャッシュの一般構造及び特性はコンピュータ科学の分野において周知であるため、ここではこれ以上説明しない。
【0025】
しかしながら、エージェント5100は本発明に独自であり、これは暗号化/復号化モジュール5110及び任意選択の検証モジュール5120を含むソフトウェアコンポーネントである。一実施形態では、エージェント5100はシステムソフトウェア2000内のソフトウェアコンポーネントであり、実行時にキャッシュ5000に存在する。幾つかの実施形態では、システムソフトウェア2000は様々なキャッシュ関連タスクも実行するキャッシュ管理モジュール2100を含むことができ、その場合には、エージェント5100はこのようなキャッシュ管理モジュール2100と同一にするかそのサブコンポーネントにすることができる。エージェント5100はシステムソフトウェア内の専用コンポーネントとして含めるか、他の任意の適切なシステムソフトウェアコンポーネントに組み込むことができる。別の実施形態では、エージェント5100はキャッシュ内に常駐する独立のコンポーネントとすることができ、その場合にはキャッシュ管理モジュール2100は不要にすることができ、OS/ハイパーバイザは非変更システムソフトウェア層とすることができる。
【0026】
異なるプロセッサアーキテクチャは必然的に異なるキャッシュ構造を有し、一部のアーキテクチャは2つ以上のキャッシュ構造を有する。本発明の目的のためには、選択の自由があれば、キャッシュ管理モジュール2100/エージェント5100を定義するコードのすべてを保持するに十分な大きさのキャッシュを選択するのが好ましい。なぜなら、この選択によりキャッシュとメインメモリとの間のトラヒック(メモリ−ディスクスワッピング及びページングと同様)及びそれに伴う暗号化/復号化アクティビティの増大が減少するためである。しかしながら、エージェントの全コンポーネントとともに任意の他のキャッシュしたソフトウェアを一度にキャッシュに収めることができないかもしれないことを受け入れる意思がある場合には、他のキャッシュを選択することもできる。多くの既存のプロセッサでは、LLC(ラストレベルキャッシュ)が一般に最大であるため、このキャッシュが最も適している。x86システムでは、これはL3キャッシュであり、少なくとも部分的に下位レベルL1及びL2を含むため、下位レベルキャッシュが失敗すると、このキャッシュはメモリから直接ではなく次のレベルのキャッシュから読み出す。
【0027】
破線で示されるように、コアに供給され且つコアから返送される命令及びデータはエージェント5100にとって可視的で、且つエージェント5100によりインターセプトすることができることが明示されている。本発明の一つの態様によれば、情報(データ及び/又は命令)がCPUから、特にコア1100又は他の内部CPUコンポーネントから、送信されるとき、この送信はエージェント5100で遮断され、その情報がCPU1000の論理境界外のシステムメモリ7000に戻される前に、エージェントモジュール5110で暗号化される。CPUコア又は内部コンポーネントに入った命令及びデータは次に、それらが処理のために送出される前に、エージェント5110により復号化される。幾つかの実施形態では、すべての受信及び送信情報(CPUからみて)は暗号化及び復号化することができるが、他の実施形態ではこの暗号化及び復号化はシステムメモリ7000の所定の部分に対してのみ実行することができる。システム設計者はモジュール5110がどのような暗号化及び復号化アルゴリズムを使用するか自由に選択することができる。このとき設計者は、エージェントにとってキャッシュ内の利用可能サイズ及び高レベルの暗号セキュリティを得るためにどの程度性能を犠牲にできるかなどの要素を考慮する。適切な処理手順(プロシージャ)は、暗号鍵を一般的にはキャッシュ5000自体内に、好ましくは鍵の使用時にのみ格納するように実装される。
【0028】
キャッシュしたエージェント5100を経てCPUとメインシステムメモリとの間を通る情報のすべてのバイトを個別に暗号化/復号化することは一般に無益であり、許容し得ない性能の劣化を生じる。代わりに、より大きなグラニュラリティ(粒度)が一般に好ましい。x86システムでは、通常、例えば仮想メモリサブシステムが情報をページレベルで移動させる。一実施形態では、それゆえエージェント5100はフルページのグラニュラリティでアクセスをトラップし、殆どのソフトウェア実行はページサイズのトラヒックを発生させるため、エージェントは一般にページごとに暗号化及び復号化を行う。この動作は、例えば(仮想化された実施形態において)ソフトウェアの実行を促進するためハイパーバイザにシステムメモリの次の部分を取得するよう命令するために発生するページフォールトを検出することによってトリガすることができる。
【0029】
アプリケーション実行に加えて、エージェント5100はキャッシュ内に収めることができなくなるほど大きくなり得る自己のメタデータを有することができる。このようなメタデータは暗号化された形でメインメモリに格納し、エージェントにより積極的にアクセスすることができ、ページフォールトによりトリガする必要はなく、その結果このようなアクセスは同じページサイズのグラニュラリティにする必要はない。
【0030】
エージェントはソフトウェアをCPU上で直接実行する必要はなく、むしろエージェントはソフトウェア、例えば非変更仮想マシン及びアプリケーションを解釈するように設定することができる。これはエージェントがソフトウェアによるメモリアクセスの必要を積極的に検出することを可能にするとともに、このようなメモリへの読み込みを小さいチャンク(塊)で可能にし、それによってスループット及び性能が向上する。これは設計上の選択であり、このような既知の技術をプリフェッチング及びコードスキャニングとして含むこともできる。使用可能なインタプリタの一例はx86命令セットのインタプリタである。
【0031】
システムソフトウェア2000、仮想マシン6200及びアプリケーション6300は多くの場合
図1のようなシステム図において個別のエンティティとして概念化されるが、これらは当然のことながら実際にはデータ及びコードのそれぞれの本体であり、それらは “1”又は“0”の任意の他の本体としてシステムストレージ6100内に格納され、システムソフトウェア2000の制御の下での実行のために全体として又はページのような単位として高速システムメモリ7000に読み込まれる。それゆえ、それぞれのメモリアドレス位置にあるそれらのコード及びデータの内容を性能向上のために他のどれよりもCPUによってキャッシュすることができる。しかしながら、この点の一つの他の重要性は、エージェント5100は、システムメモリに格納される任意の他の情報と同様に、このようなソフトウェアコンポーネントを定義するコードも安全にすることができることにある。
【0032】
この点でも、本発明と既知の解決策との差異が理解できる。少なくとも、CPU自体を初期化するために必要な常時存在するコードを除けば、図示の実施形態はメインプロセッサ1000の一部分以外の如何なるハードウェア又はソフトウェアコンポーネントの一部分へのアクションも必要としない。一つの他の重要な差異は、エージェント5100はキャッシュ5000に常駐するソフトウェアモジュールとして実装できることである。要するに、エージェント5000はコモディティ処理システムを、ハードウェアの変更を必要とすることも、実行時にCPU外部に信頼できるハードウェア又はソフトウェアを必要とすることもなく、クリプトプロセッサに変換することができる。
【0033】
CPUからシステムメモリへ送信される情報のキャッシュベース暗号化はこのような情報のセキュリティを保証することができるが、暗号化だけではその完全性を保証することができず、暗号化情報でも改ざんすることができ、また偶然に変更され得る。それゆえ、
図1にも示すように、エージェント5100は検証ソフトウェアモジュール5120も含み、このモジュール5120はモジュール5110が暗号化しシステムメモリに格納したものと関連するある種の検証データを計算する。この検証データはチェックサムのような簡単なものとすることができるが、殆どの場合、ハッシュ値、メッセージ認証コード(MAC)又は暗号化された情報の各ブロック(例えばページ)と関連するディジタル署名を計算するために任意の既知のメッセージ統合アルゴリズム用いてより安全にする。検証モジュール5120はその後同じメモリブロックに対して検証データを再計算し、再計算された検証データを先に計算され格納された検証データと比較して、任意の変化を検出する(これは不一致により示される)。この検証処理手順は、メモリブロックが読み出されるときに背景プロセスとして、又はシステム設計者が望む他のスケジュールで実行することができる。
【0034】
暗号化は厳密には検証を必要とせず、逆も同様である。従って、エージェントは検証のみを行うように、或いは暗号化と検証の両方を選択的に可能にするように設定することができる。換言すれば、エージェントは暗号化/復号化モジュール5110、又は検証モジュール5120、又はその両方(
図1に示す実施形態及び最もセキュアな好ましい実施形態)を含むことができる。検証のみの実施形態に関しては、この実施形態は、プライバシーは不要もしくは希望しないが、データ完全性は必要もしくは希望する環境において有効である。検証のみの実施形態でもハードウェアプロセッサの信頼できるキャッシュ内のエージェントという本発明の最高レベルの概念の利点を依然として有している点に注意されたい。
【0035】
モジュール5110及びモジュール5120の両方及び対応する機能を含む実施形態でも、これらの選択を可能にすることができる。例えば、ユーザはデータのプライバシーの維持を希望することができ、その場合には暗号化モジュールはデータがメモリに書き込まれる前にそのデータを暗号化するが、ユーザはコモディティオペレーティングシステム又はアプリケーションの既によく知られたコードのような他の情報の暗号化/復号化の性能コストを(わずかであっても)負担することは希望しないことができる。しかしながら、暗号化されてないメモリブロック(例えばページ)が改ざんされてないことを確認するのが望ましく、そのような場合には検証だけで十分とすることができる。この場合、簡単なインデックス付きリストのような適切なデータ構造をエージェントに含めて、特定のメモリブロック(例えばページ)が暗号化及び/又は検証すべきかあるいは暗号化済み及び/又は検証済みであるかを示すことができる。
【0036】
図2は、エージェント5100がOS/ハイパーバイザ2000のキャッシュ管理モジュール2100のサブコンポーネントである実施形態を実行時に示したものである。換言すれば、この実施形態では、OS/ハイパーバイザ2000はエージェント5100を既存のキャッシュ管理モジュール2100(他の無関係な機能を含む場合もある)の一部分として、又はキャッシュ管理モジュール自体として含むように変更される。キャッシュ管理モジュール2100はOS/ハイパーバイザへのアクセスが許されるページのリスト、ページレンジ等を維持し、キャッシュをアクティブに管理し、例えばキャッシュは決して失敗しないことをパフォーマンスカウンタにより監視し、エラーが発見された場合に処置する。
【0037】
図2に示すように、実行時に、OS/ハイパーバイザ2000は一般に少なくとも部分的にキャッシュ5000に読み込まれ、これは従来のシステムにおいても普通のことである。所定の実施形態ではそれらの相対的なサイズに依存してOS/ハイパーバイザ2000は完全にはキャッシュ5000内に収まらない可能性がある。そのような場合、
図2に示すようにOS/ハイパーバイザ2000の陰影付きの上部が論理的にキャッシュ5000の外にはみ出る場合、OS/ハイパーバイザ2000の一部分は必要とされるまで9100として示される暗号化されたシステムメモリ領域に格納しておくことができる。図に示すように、VM6200及びアプリケーション6300等のユーザレベルソフトウェアも、システムソフトウェア2000と同時にキャッシュ5000に読み込むことができ、必要に応じ、対応するコードの部分(陰影付き部分)は暗号化されたシステムメモリ領域9100へ又はシステムメモリ領域9100において少なくとも一時的に退出又は残存させることができる。これは、通常のコンピュータにおいてメモリページがシステムメモリとディスクストレージとの間で頻繁にスワップされる態様に類似する。しかしながら、本発明の全ての特徴、特に、CPU及びエージェントだけは信頼される(トラステッドである)必要があるという特徴を適正に機能させるためには、エージェント5100の全部を実行時間中キャッシュに常駐させるのが好ましい。
【0038】
グラニュラキャッシュ制御が欠けているメインプロセッサのためにキャッシュ内容を管理する方法の一例は以下の通りである。
1.キャッシュの幾何配置(ジオメトリ)及び連想(アソシアティビティ)を、例えばサポートされたインタフェースを用いて又は直接評価により決定する(例えば、一つの既知の技術は異なるサイズのメモリ領域へのアクセス時間を測定する;キャッシュヒットがキャッシュミスより遥かに速い)
2.物理アドレスで動作する一般的なキャッシュに対してキャッシュ内に共存し得る物理ページの最大セットを決定する。キャッシュメモリをインデックスするために代わりに仮想アドレスを使用する(場合によっては追加の物理アドレスタグを使用する)プロセッサに対して、エージェント5100はマップされたメモリの全部がキャッシュ内に同時に共存できることを保証するように仮想アドレスの割り当てを管理すべく設定することができる。
3.発見された物理ページのセットを、例えばハイパーバイザ,OS又はアプリケーションにより使用される仮想アドレスに割り当てることができる唯一のページとして維持する。しかしながら(以下に記載するように)、一つの代案として、仮想対物理ページマッピング及び/又は物理メモリの特定領域はキャッシュ不能としてマークすることができ、従って唯一のキャッシュページが共存し得る物理ページのセット(上記のステップ2参照)内の1つであれば、任意のマッピングも可能であることに注意されたい。
【0039】
キャッシュ内容を管理する手順の別の例は以下の通りである。
1.キャッシュの幾何配置(ジオメトリ)及び連想(アソシアティビティ)を、例えば既知のサポートされたインタフェースを用いて又は直接評価により決定する。
2.キャッシュが物理アドレスで動作することに注意しながらキャッシュ内に共存し得る物理ページの最大セットを決定する。上記の方法では、代わりに仮想アドレスを使用して(場合によっては追加の物理アドレスタグを使用する)、キャッシュメモリをインデックスするプロセッサに対して、エージェント5100は、仮想アドレスの割り当てを管理すべく設定して、マップされたメモリの全部がキャッシュ内に同時に共存できることを保証する。
3.決定された物理ページのセットを、例えばハイパーバイザ,OS又はアプリケーションにより使用される仮想アドレスに割り当てることができる唯一のページとして維持する。上述したように、代案として、仮想対物理ページマッピング及び/又は物理メモリの特定領域はキャッシュ不能としてマークすることができることに注意されたい。
4.上述したページのセット外の任意のメモリを読み出すために、OS又はハイパーバイザは任意のサポートされたプロセッサ方法を使用して、キャッシュをバイパスしながらメモリをCPUレジスタ内に読み込むことができる。一旦コピーされたメモリがプロセッサレジスタ内に入れば、レジスタ内容はキャッシュを占める物理ページの1つにコピーしても安全である。
5.上述したページのセット外の任意のメモリを書き込むために、ステップ4に対して逆の論理を使用する。
6.CPUをDMAによるアクセスから保護するために、IOMMU(x86アーキテクチャ等の多くの現在のプロセッサアーキテクチャに設けられている)又は他のCPU特有方法を、キャッシュ占有ページへのDMAを阻止するように設定する。
【0040】
特定のアドレス又はレンジのアドレスへのアクセス時にキャッシュのバイパスを可能にする様々な方法が知られている。いくつかあるアーキテクチャの中で特にx86に利用可能なこのような方法の例には、x86プロセッサに所定のメモリ領域をキャッシュしないように命令することができるメモリタイプレンジレジスタ(MTTR)、個々のページのキャッシングを制御するMMUに対するPAT拡張子、及びMOVNTDQ及びMOVNTDQA等の特殊非一時的読み込み及び記憶命令がある。
【0041】
ほとんどの既存のx86システムでは、CPUキャッシュに共存できる物理ページのセットは複数のキャッシュサイズで始まる連続するページセットである。例えば、キャッシュサイズが8MBである場合、第1のページセットは(0−8)MBのシステムアドレス空間を占めるページであり、第2のページセットは(8−16MB)のシステムアドレス空間を占め、以下同様である。この特徴は、ソフトウェアスタックはテストしたページセット内に収まると仮定して、所定の物理ページセットが共存できるかどうかを検査するために様々な方法で活用することができる。これは様々な方法で達成することができ、例えばプロセッサキャッシュパフォーマンスカウンタ又はハードウェアバスアナライザ(即ち「メモリプロトコルアナライザ」)の何れかを用いてキャッシュ追い出しが生じたかどうかを決定することによって達成することができる。これらの方法は、具体的には以下の通りである。
【0042】
プロセッサキャッシュパフォーマンスカウンタを用いて、
1.キャッシュした内容を無効にする。
2.検査すべきページセット内のすべてのバイト(又は他のメモリ単位)を読み出す。
3.プロセッサキャッシュパフォーマンスカウンタの値(キャッシュミスの数)を記録する。
4.ステップ2を繰り返す。即ち、すべてのバイト(又は他のメモリ単位)を再度読み出す。
5.プロセッサキャッシュパフォーマンスカウンタの値(キャッシュミスの数)を再び読み出す。
6.その結果を比較する。キャッシュミスの数がステップ3と同数である場合、これは全レンジの再読み出しが全くミスを生じなかったことを示すため、すべてのページはキャッシュに共存していたとする。
【0043】
ハードウェアバスアナライザを用いて、
1.検査すべきページセット内のすべてのバイト(又は他のメモリ単位)を読み出す。
2.バスアナライザを用いて、メインプロセッサによるメインメモリへの如何なるアクセスも測定開始する。
3.ステップ1を繰り返す。
4.バスアナライザの結果を分析する。特に、ページセット内のアドレスからの如何なる読み出しも検索する。そのレンジ内に読み出しがなければ、すべてのページはキャッシュに共存していたとする。
【0044】
キャッシュミスが起こったかどうかを決定する他の方法もあり、上で概説した方法の代わりに使用できる。その一例はメモリの非キャッシュコヒーレント読み出し(キャッシュのバイパス)を実行しうるデバイスを使用するものである。
【0045】
別の代替方法は、x86INVD命令を用いてキャッシュ内容を無効にし、次に関連するシステムメモリページを検査していずれかのラインが書き戻されたかどうかを確かめるものである。特に、キャッシュ領域は初期パターンで満たし、その後WBINVDによりメモリにフラッシュ(書き出す)することができる。キャッシュ領域はその後個別のテストパターンで満たされ、キャッシュはINVD命令により無効にされる。キャッシュをバックアップするメモリはその後検査され、どのラインが追い出されたかに関する情報を用いてキャッシュ内でコンフリクトするページのセットを決定し、非コンフリクトページのセットを検出することができる。この決定方法の一例は、オリジナルパターンを含まないキャッシュラインはテストパターンの書き込み時にコンフリクト(競合)のために追い出されたはずであることを監視するものである。
【0046】
上記のキャッシュ検査は所定の実装上の選択に応じて異なる時間に実行することができる。一実施形態では、例えばキャッシュ検査は各プロセッサ設定に対してオフラインで手動的に実行することができる。別の実施形態では、読み込み可能なリナックスカーネルモジュールでコンフリクト検査を実行することができる。他の実施形態では、キャッシュ検査は、キャッシュ管理/エージェントソフトウェアが最初に読み込まれるとき、起動時に実行することができる。更に他の実施形態では、このような検査は、実行時にセキュアなOS/ハイパーバイザにより追加の保護層として周期的に実行し、予期せぬキャッシュ追い出しを検出する(これにより、後で更に説明するように、それらを急速に中止させ、機密データの暴露時間を低減することができる。)。
【0047】
更に他のアプローチは、キャッシュミスパフォーマンスカウンタを使用する代わりとして、メモリアクセスを計時してキャッシュミスを検出する(例えばx86RDTSCを用いて「リードタイムスタンプカウンタ」命令を用いる)。
【0048】
最新のインテルx86プロセッサ(「Sandy Bridge」のコードネームで始まる)はいわゆる「コンプレックスキャッシュアドレシング」を使用し、そのハードウェアはメモリアドレスをハッシュ化してそれがキャッシュ内に存在するかどうかを決定する。換言すれば、このようなシステムではページカラーリングは最早働かない。このようなシステムでは、非コンフリクトページのセットを計算する方法は一般に上で概説した生成・検査処理手順を必要とする。
【0049】
多くの共通システムでは、現在のハイパーバイザ又はOSを、使用が許される物理ページのセットに制約として与え、ハイパーバイザ又はOCがその制約を尊重し、実行のために所与のページのみを参照することを見込む。しかしながら、ハードウェアデバイスがCPUキャッシュの状態を読み出すのを防止するために追加のステップが通常必要とされる。規定値(デフォルト)により、デバイスは通常任意のシステムアドレスからの読み出しのためにDMA(ダイレクトメモリアクセス)要求を発行することができる。そのメモリがたまたま例えばx86システム内のDMA−キャッシュ−コヒーレントCPUによりキャッシュされた場合、CPUはこのようなメモリにアクセスことが可能になり、これは信頼モジュールを破り、ソフトウェア状態を暴露することになる。
【0050】
IOMMU(I/Oメモリマネジメントユニット)1300はソフトウェアで設定可能なデバイスであり、ハードウェアデバイスがシステムアドレスにアクセスするのを制限して、デバイスが明示的に割り当てられなかった(マップされなかった)メモリの読み出し又は書き込みを行うことができないようにすることができる。多くのコモディティプロセッサはIOMMUをそのCPU回路の一部分として含む。他の場合には、別個のコンポーネントであり、その場合にはそのセキュリティを確保するために既知の手段を講じる必要がある。IOMMUに加えて、ある種のCPUはDMA保護を提供し得る他の技術、例えばインテルx86TXT技術を有している。従って、DMA保護を提供する1つの方法はIOMMUを使用するが、他のCPU固有の代替技術を用いて本発明の様々な実施形態を実装することもできる。それゆえ、デバイスによるCPUキャッシュへのアクセスを軽減するために、IOMMUはこのようなアクセスを阻止するように設定することができる。これは通常、キャッシュを占有するページセット内の各ページがマッピングを持たないように、又は無効アドレスレンジ、例えばいかなるデバイス又はシステムアドレス空間内のメモリによってもマップされないアドレスへのマッピングを持つようにIOMMUを設定することによって行われる。通常動作では、ソフトウェアスタックはキャッシュを占有するメモリからの読み出しに何のデバイスも必要としないため、通常動作は予期できる。しかしながら、悪意のハードウェアデバイスがソフトウェア状態を読み出そうとする場合、これはIOMMUにより防止される。その一つの例外は、キャッシュを占有するページであって、デバイスとのI/O通信のためにソフトウェアスタックにより意図的に選択される幾つかのページである。このようなページに対して、IOMMUはこれらのページにハードウェアデバイスがアクセスできるようにこれらのページをマップするように設定される。このようなページがある一つの理由は、幾つかの旧ハードウェアデバイスはアドレス空間の少量にしかアドレスできないからであり、例えばISAデバイスはシステムアドレス空間の最初の16MBにしかアドレスできない。従って、このようなデバイスとの通信はキャッシュ内にあるメモリを用いて起こる必要がある。
【0051】
しかしながら、I/Oのためにキャッシュ内の所定のページへのアクセスが許可されるときでも、デバイスに対するアクセスが許可されるページはI/O通信に間に合う時点で使用されるページのみである。I/O通信が完了すると、IOMMU保護を再び確立することができ、そのページは他の目的、例えば他のソフトウェアコードを実行するために使用できる。エージェントはI/Oに使用されているページを知っていてそれを適宜処理できるので、これはセキュリティリスクにならない点に注意されたい。
【0052】
エージェント5100はCPUキャッシュ5000に読み込まれた実行可能なコードを含み、このキャッシュはCPUの最初の起動時又はリセット後に空であるため、どのようにエージェントに安全に読み込むという問題が生じる。各プロセッサアーキテクチャはこの問題に対処する様々な方法を有し、熟練設計士はそれらについて知っているが、説明のために、本発明は現在のx86アーキテクチャに基づくシステムに実装するものと仮定する。上述したように、インテルは現在、信頼される実行技術(トラステッド・エグゼキューション・テクノロジ)(TXT)を提供し、これは信頼されるプラットフォームモジュール(TPM)チップをx86型CPUのハードウェア拡張として含んでいる。TXTはTPMを有するシステム上で起動するソフトウェアを認証する既知の方法である。幾つかの提案によれば、TPMは将来、CPU自体に組み込まれる。
図1はそれらをTXT3000及びTPM3100として示している。
【0053】
エージェント5100の安全な読み込みを準備する一つの方法は以下の通りである。0)信頼されるシステムを用いて、エージェントとして読み込むべきコードのハッシュ値を計算し、これを安全に格納する。
1)エージェントローダコードをシステムメインメモリに他のアプリケーションと同様に読み込む。この段階では、エージェントコードはメインメモリにおいて見えるかもしれないので、悪意の攻撃を受けるかもしれない。
2)インテル指定の、よって既知のTXT技術のオペレーションに従って、エージェントローダコードをMLE(メジャード・ラウンチ・エンバイロンメント)において実行してエージェント5100をキャッシュ5000に読み込み、エージェントハッシュ値をTPM3100に記録する。MLEはDMAからのエージェントローダコーダ全体の保護を提供する。この段階ではメモリ内に読み込まれた秘密情報は存在せず、エージェントローダコードのみが存在する。
3)キャッシュしたエージェントコードを再ハッシュし、リモートシステムを介して(好ましくは専用ネットワークエージェントを通じて)TPMと通信し、この再ハッシュ値を先に格納されたエージェントハッシュ値と比較する。両ハッシュ値が一致する場合、キャッシュしたエージェントは認証され、実行時に変更されずに動作することが知られる。
4)今ではエージェントは安全に読み込まれ、すべての実行はCPUキャッシュ内でのみ起こるため、個人情報(記憶鍵、VM画像等)を、エージェント5100を実行するホストに送ることができる。CPUはCPU自体の外部と通信する必要なしに暗号鍵を安全に生成し、キャッシュに存在させることができる点に注意されたい。
【0054】
図3は、一般的な実施形態における様々なハードウェア及びソフトウェアコンポーネントによるシステムメモリとの相互作用を示し、更に本発明がシステムメモリとの動作のみならず、自身のメモリを含むI/Oデバイスとの動作をどのようにサポートするかも示す。
図3は更に安全/プライベートシステムメモリアドレス領域(9000)と安全でなく潜在的に悪意のシステムメモリアドレス領域(9001)との区別も示す。
【0055】
安全/プライベートメモリ9000に関しては、概して、キャッシュ5000内に現在あるメモリは安全にアクセスできる、即ち信頼できるとみなせる。エージェントにより暗号化されたメモリ内の情報は、キャッシュ情報という意味で信頼できないが、それにもかかわらず暗号化及び更なる検証のおかげで安全である。スタック内のソフトウェアはこのようなアドレス領域を、それらはアドレスするシステムメモリが物理アドレスであるとみなすが実際にはキャッシュ5000内にあり、信頼できるという意味で安全とみなす。換言すれば、ソフトウェアスタックは、システムメモリを通常通りにアドレスするが実際にはキャッシュ5000をアドレスすると考える。
【0056】
モジュール5110(
図1)による暗号化は、これらのメモリ領域に格納される情報(仮想マシン6200及びアプリケーション6300の状態のような情報及びキャッシュ5000に収まらないOS/ハイパーバイザ2000の部分を含む)の機密性をもたらし、モジュール5120(
図1)による検証はデータの完全性をもたらすが、実際の可用性は保証されない点に注意されたい。従って、悪意のエンティティは依然としてコード又はデータを改ざんできるが、この改ざんは上述したように検出され、改ざんは影響を受けたブロックに対してハッシュ又は他の検証データの不一致を生じる。検証モジュール5120及びその関連動作なしでも、暗号化された形で格納される実行可能コードの改ざんは、殆ど確実に検出可能なランタイムエラー又は影響を受けたコードの明白な失敗を生じ、更に前進する。
【0057】
図3において、ソフトウェアスタック2000,6200,6300はキャッシュの外部として示されている。これは単に説明のためである。上述したように、実行時にOS/ハイパーバイザ2000、特にエージェント5100の大部分又は好ましくは全部のみならず、通常の性能上の理由のためにOS/ハイパーバイザ2000がキャッシュに読み込むために選択するスタックの他の部分(例えばVM6200及び/又はアプリケーション6300)も信頼されるキャッシュ5000内に存在する。
【0058】
非暗号化メモリ領域9001は信頼できず、攻撃から安全でない。一般に、キャッシュ内に現在存在しないメモリは安全でないとみなせ、プライバシー及び完全性攻撃を阻止するためにエージェントにより暗号化しなければならない。信頼されない(アントラステッドな)メモリ空間9001は通常のシステムにより使用される通常のシステムメモリを含む。特別な属性をこのようなメモリ空間内の特定のアドレスと関連付ける必要はなく、よってそれらの特別な属性はコード(好ましくはコード自体ではないが)、ストレージ又はデバイスI/Oを実行することによって使用することができる。上述したように、信頼されないメモリ空間は暗号化/検証された実行可能なコードを格納するためにも使用でき、このコードはエージェント5100による再検証及び復号化後にページインされ実行されるようにすることができる。
【0059】
非暗号化システムメモリは全システムの唯一のマッピング可能なメモリではない。デバイス6700が何であるか及びデバイスがどのようの構築されるかに応じて、それらは、例えばそれらの専用の一般的に基板に乗ったデバイスメモリ6710(例えばビデオカード上のメモリ)にアクセスすることができる。従来のシステムでも、デバイスメモリ6710をI/Oデバイス以外の目的のためにマッピングすることはまれであり、特にコードは一般的にデバイスメモリから実行されない。CPUキャッシュ5000はシステムアドレスへのアクセスを提供するので、アドレスの一部はシステムメモリにより全くバックアップされないかもしれず、代わりに、システムメモリの一部分ではなく理論的にそのようなものとして使用することができるデバイスメモリ6710、例えば512MBのビデオカードによりバックアップされてもよい。
【0060】
デバイスはDMA I/Oチャネル9600を経て信頼されないシステムメモリアドレス空間9510にアクセスすることもできる。しかしながら、信頼されるセットアップでは、DMA保護9201(例えばIOMMU1300により提供される(
図1参照))はCPUキャッシュを占有するシステムアドレスレンジへのアクセスを阻止するように設定される。これはI/Oチャネル9600から出てDMA保護モジュール9210で「跳ね返る」矢印により示されている。このIOMMU保護機構は上で詳細に記載されている。
【0061】
図3に示す暗号化ストレージ領域9610は単なる非専用メモリである。システムメモリを一般に信頼しないシステムに対しては、暗号化スワップストレージ等の暗号化RAMディスクを格納するために9610のような領域を信頼されないストレージ領域として含めるのが有益である。これは低速ストレージデバイスに比較して性能を向上することができ、限定されたプロセッサキャッシュサイズを補償することができる。
【0062】
CPUキャッシュをバックアップするシステムメモリ領域は9500として示されている。一例として、この領域は、例えば偶発的な書き戻しによりキャッシュから何のメモリもシステムメモリへ漏れ戻されないことを示す零又は他のパターン(例えば、ランダム生成ビット、その場合にはその後の再計算及び検証のためにシードを格納する必要がある)を含むことができる。換言すれば、エージェントによる後の検査時に、システムメモリ領域9500が同じパターンを含まない場合、システムは何らかのキャッシュ漏洩があったことを知ることになる。オールゼロ以外のいくつかのパターンは、リセットが正しい状態と混同しない利点を有する。このバックアップメモリ領域9500は、キャッシュ内にも暗号化領域にもないので、依然として信頼できないが、依然として上述したエージェントにより安全に使用することができる。
【0063】
非コンフリクトメモリ9500の領域はエージェント5100の初期読み込み中も使用することができる。キャッシュバックアップメモリ領域9500を使用する処理手順の一例は次のステップを含む。
1. TO:OS/ハイパーバイザ2000のカーネルイメージがメモリ領域9500に読み込まれる。この時点では、領域9500内の全ての情報は平文であり、つまり、どの情報もまだ安全でない。
2. T1:OS/ハイパーバイザカーネルは、エージェント5100を初期化し、(エージェント5100はその後カーネルを非コンフリクトページのセットのみに制限するように物理メモリのキャッシュ特性を管理する)、IOMMUを設定し、適切な実行時状態に入る。
3. T2:エージェント5100はキャッシュでバックアップされるメモリ領域9500を、追い出し・検出・フィル・パターンで満たす。
4. T3−Tn:システムはキャッシュのみから実行される。キャッシュをバックアップするメモリ領域9500は実行状態の暗号化バージョンではなく、むしろフィルパターンを含む「ステイル(古い)」メモリである。エージェント5100は周期的にメモリ領域9500を検査し、このフィルパターンが無傷であるかどうか及び従って幾つかのキャッシュラインがエビクションのために漏洩したかどうかを検査する。
【0064】
キャッシュは整列した連続データチャンク(キャッシュラインとも称される)で動作することが知られている。例えば、現在のx86プロセッサでは64バイトが共通のキャッシュラインサイズであり、キャッシュとシステムメモリとの間のデータの移動はキャッシュラインのグラニュラリティで起こる。プロセッサキャッシュは一般にセットアソシアティブ法で編成され、各キャッシュインデックスはN個のキャッシュラインまでNウェイセットアソシアティブキャッシュに格納することができる。現在のx86プロセッサに対して、Nは一般に8又は16である。プロセッサは一般的にメモリアドレスからキャッシュインデックスへの決定論的マッピングを使用するため、システムメモリ内の多数のラインは同じキャッシュインデックスにマッピングされるが、キャッシュはそれらのうちのNまでを一度に保持することができるのみである。同じキャッシュインデックスにマッピングするNより多数のメモリアドレスがアクセスされるとき、それらはすべてがキャッシュ内に同時に収まるわけではなく、キャッシュエビクションが生じる。現在のプロセッサは、システムメモリからの新たなアクセスラインのための空間を作るためにどのキャッシュ済みラインを追い出すべきかを最長時間未使用(LRU)ポリシー(又は一種の近似)を用いて決定している。変更されたライン(「ダーティ」ラインとして知られている)が追い出されるとき、そのラインはシステムメモリに書き戻される。一般に、プロセッサはキャッシュ追い出し又は書き戻しに介入する何の方法もソフトウェアに供給しない。
【0065】
本発明は、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),に記載されている「バス暗号化」により必要とされように、キャッシュ内容の部分をロックダウンする特別のハードウェアサポート又はプロセッサモードの存在に依存しない。
【0066】
制御されない(アンコントロールド)キャッシュ追い出しは信頼されないキャッシュメモリからのデータを信頼されないシステムメモリへ漏洩し、プライバシーを侵害する。また、追い出されたラインへの次のアクセスは信頼されないステムメモリからのデータを信頼されるキャッシュに読み込み、攻撃者が完全性を侵害することが可能になる。その結果、コード及びデータの両方のプライバシー及び完全性を保護するために有効なキャッシュ管理が不可欠である。従って、一つの重要な課題は、追い出しがキャッシュをコンフリクトしないようにすることであり、関連の取り組みにおいて議論されていない問題である。これは、キャッシュ可能なメモリの部分を注意深く選択し、キャッシュ不可能なメモリの残部をマークすることを伴う。一般に、プロセッサメモリ管理ユニット(MMU)1200(
図1)は、ソフトウェアが一般にキャッシュラインよりずっと大きいページのグラニュラリティで、メモリを制御し、マッピングし及び保護することを可能にする。例えば、最小ページサイズはx86プロセッサで4096バイトである。
【0067】
この問題に対処する一つの方法は、(1)非コンフリクトページのセットを見つけ出し、(2)現在のソフトウェアを実行するためにこれらのページのみを使用する。その理由は、これらのページのみがこれらのページのキャッシュをCPUに許可するというキャッシュポリシーを有し、システム内の残りのページはキャッシュを阻止するというキャッシュポリシーを有するためである。非コンフリクトとして見つけ出す必要があるページのセットは、これまでキャッシュにマップされたことがあるページのみであるため、データが信頼されないメモリの残部から読み出されるときでも、そのデータは依然として、キャッシュに置かれないように且つ一般に現在キャッシュに存在するメモリの追い出しを生じないように読み出される。
【0068】
非コンフリクトページのセットはメモリアドレスをキャッシュインデックスにマッピングするプロセッサで使用される特定の機能に依存し、これは更にプロセッサ実装の詳細に依存する。ある場合には、キャッシュ構成(サイズ及び連想(アソシアティビティ))が一旦決定されると、マッピングはページカラーリングにより計算及び制御される。最新のインテルx86プロセッサ(”Sandy bridge”で始まる)のような他の場合には、マッピングはプロセッサベンダにより公開されていない不透明な複素ハッシュ関数である。その結果、非コンフリクトページの適切なセットを見つけ出すために実験的な取り組みが必要とされ、ひいてはコンフリクトを検出する信頼できる処理手順が必要とされる。プライベートコア社は、システムメモリから非コヒーレントな読み出しを実行するためにキャッシュをバイパスする方法及びハードウェア性能カウンタの監視を含む方法等の幾つかの追い出し検出技術を開発している。生産システム作動中に実行時の追い出しを検出する更なる能力も、予期せぬ漏洩を素早くキャッチしスクラブするとともに暴露時間を短くするために重要である。
【0069】
この時点において、コンピュータセキュリティ分野のシステムレベルの技術者は、文献で提案されている他の解決策に対する本発明の様々な特徴の利点のいくつかを理解されよう。一つの明らかな利点は、本発明のソフトウェアのみによるアプローチは何も特別なハードウェアサポートを必要とせず、現在のx86プロセッサベースのシステムのようなコモディティハードウェアとともに使用することもできる点にある。暗号化/復号化の特徴と検証の特徴の両方を実装する場合(任意)、開示されたシステムはシステム内のすべてのコード及びデータに対してプライバシー(機密性)及び完全性の両方を保証するように設計される。
【0070】
上述した本発明の実施形態の信頼されるコンピューティングベース(TCB)はプロセッサを超えて拡大する必要はなく、すべての他のハードウェアは信頼されず、潜在的に悪意であると明確に仮定する脅威モデルに従って動作することができる。しかしながら、安全な起動及び認証のために、TCBは好ましくはルート・オブ・トラストを確立するために必要なコンポーネント、例えばインテルの信頼される実行技術(TXT)も含むべきであり、これは幾つかの実施形態ではプロセッサ外の信頼されるプラットフォームモジュール(TPM)を含むことができる。
【0071】
特に、システムメモリ自体は信頼されないと考えられ、その内容は攻撃者により読み出しや書き込みの攻撃を受けやすく、プライバシー又は完全性がそれぞれ侵害されると考えられる。同様に、プロセッサ外のすべての他のハードウェアデバイス及び相互接続は信頼されず、潜在的に攻撃者のコントロール下にある。例えば、DMAを実行し得る共通ネットワークインタフェースカード(NIC)等の危険にさらされたI/Oデバイスは、メインメモリ又はキャッシュ内のコード及びデータの内容を故意に検査又は破壊することによってプライバシー又は完全性を侵害するために利用することができる。
【0072】
本発明では、信頼される必要がある唯一のメモリはプロセッサ自体に物理的に一体化された部分であるプロセッサキャッシュであり、使用する他のメモリは暗号化することができ、またデバイスメモリ又は可能なDMAの場合にはIOMMUを用いて制御することができる。これは、Peter A. H. Peterson, “Cryptkeeper: Improving Security with Encrypted RAM”, in IEEE International Conference on Technologies for Homeland Security (HST 2010), November 2010に記載されているクリプトキーパシステムと対照的である。クリプトキーパはメインメモリを個別の平文部分と暗号化部分に分割し、キャッシュ内容を管理しようとせず、RAM全体がキャッシュ可能である。その結果、クリプトキーパはその平文メモリ領域に対するプライバシーの保護に失敗し、性能を高めるためにある程度のメモリ内容の漏洩を許す明示的な選択を行うことになる。クリプトキーパがその平文のサイズをキャッシュに収まるように減少しても、暗号化領域へのアクセスは依然としてキャッシュ追い出しを誘起するため、平文データはメモリに漏れ戻る。クリプトキーパはまた完全性に対応せず、RAMの平文部分又は暗号化部分のコード及びデータを変更又は破壊する攻撃に対する保護を提供しない。
【0073】
同様に、先に引用したChen他の文献に提案されているバス暗号化方式は、攻撃者は「メモリの内容を改ざんできない」とともに、「カーネルを変更できない」と仮定しているが、カーネルは、幾つかのエンベデッドシステムの場合と同様に、プロセッサ外のリードオンリー不揮発性メモリ内に存在すると考えられる。
【0074】
本出願の優先権日後にのみ公開されたアプローチとの単なる比較として、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, に記載されたCARMAシステムは排他的にキャッシュメモリに依存しているため、 システムメモリは決してアクセスされず、存在させる必要はない。著者等は、「実行は完全にキャッシュ内で行われ、信頼されないRAMと相互に作用しない」と明言しており、彼らはプロトタイプ実装におけるすべてのDRAMを除去することに成功している。この選択はCARMAによりサポートすることができる作業負荷のタイプを著しく制約するので、特にCARMAは本質的に、殆どが大きすぎてキャッシュに完全に収めることができない大きな汎用仮想メモリ、複雑なアプリケーション、又は変更されてないほとんどの市販ソフトウェアに役立たないものとなる。更に、I/Oデバイスに対するサポートの概念としてCARMAが含む唯一の機構は、受動デバイスへの入力/出力コマンドを介して、CPU自体により起動される。これは、デバイスでもデータをCPUと共有するために共有メモリを介してメモリ書き込みを開始することができる本発明と比較して厳しい制約である。
【0075】
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 に記載されたTRESORシステム(前述した)は、ディスク暗号鍵を安全に格納するというより限定的問題に対処するように設計されているためRAMへの物理攻撃は暗号化されたディスク内容を危険にさらさない。TRSORは暗号鍵をマシン固有の特権プロセッサレジスタ(x86デバグレジスタ)に格納し、如何なる機密情報もRAMに格納することなくAES暗号化アルゴリズムを実行する。システム内のすべてのコード及びデータのプライバシー及び任意選択で完全性を保護する本出願に記載する本発明のアーキテクチャと対照的に、TRESORは暗号鍵のみを保護する。情報を安全に格納するために特権プロセッサレジスタを用いるアプローチは極めて少量の状態を超えるスケールにできず、TRESORは、例えば単一のAES−256鍵を保持するのにちょうど十分な256ビットを(4つの64ビットデバグレジスタに)安全に格納できるのみである。x86デバグレジスタ機構の(誤)使用はハードウェアブレークポイント及びウォッチポイントに対する目的の用途を不可能にする。更に、コード及びデータ全体のプライバシー及び完全性は保護されないので、攻撃者はTRESOR実装を操作し、変更することにより、CPUデバグレジスタに格納された鍵へアクセスすることが可能である。