JP5735509B2 - マルウェアがある状態でユーザが検証可能な信頼性のあるパスを得るための方法および機器 - Google Patents

Description

本発明は、一般にマルウェアがある状態でユーザが検証可能な信頼性のあるパスを得るための方法および機器を対象とし、より詳細には、信頼できないコンピュータプラットフォーム上で使用するためのそのような方法および機器を対象とする。

セキュアコンピューティングにおける基本的構成は、信頼性のあるパス（trusted path:ＴＰ）［３７，３８］の構成である。一般にＴＰとは、コンピューティング装置と人間との間の高保証接続である。例えば人間は、コンピュータのインターフェイスとの自身の対話が、悪意ある類似ソフトウェアではなく、そのコンピューティング装置上の意図されたソフトウェアに接続されている保証を得ることができる。対照的に、信頼性のあるチャネル（trusted channel:ＴＣ）とは、２台のコンピューティング装置間の、認証され、完全性が保護され、暗号化された接続である。ＴＰの従来の概念は、ユーザが（セキュリティカーネルまたは信頼性のあるアプリケーションによって実装される）１組の信頼性のあるコマンドを用いて、信頼性のある入力装置（例えばキーボード）から直接的、非仲介的方法により通信することを可能にするものである。次いで、それらの信頼性のあるコマンドは実行時に、ＴＰの活性化をユーザが検証できるようにする独自のプロンプトをユーザの端末上に表示する。そのようなＴＰを使用する典型例は、セキュアログインの応用例に関する。しかし、信頼性のあるパスの必要性はセキュリティの基礎であり、他の多くの状況において生じる。例えば、ユーザが入力した銀行のウェブアドレスが、ユーザのマシン上のウェブブラウザに到達する前に変更されないことを確実にするために、または銀行のウェブサイト用のパスワードがユーザのマシン上にあるマルウェアに漏れないことを確実にするために、信頼性のあるパスは不可欠である。同様に、信頼性のあるパスは、アプリケーションが自らの出力を、マルウェアによって不正に読み取られるか、または修正されない保証がある状態で、ユーザの装置上に表示することを可能にする。ユーザの見地からすれば、信頼性のあるパスを介したアプリケーションの出力は、アプリケーションの出力が秘密かつ真正であることをユーザに保証するのに役立つ。

信頼性のあるパスは特定の基礎特性を提供し、その特性とはつまり、やり取りされるデータの機密性および完全性、パスの両端におけるエンティティの認証、および信頼性のあるパス上でのコマンドの適時実行（可用性の一形式）である。さらにＴＰは３つの基本特性を提供し、その３つの特性とは次のものである。（１）ＴＰは拡張可能であるべきである。これは、適用分野の需要、保護必要度、および完全性要件に応じて、ユーザがさらなる信頼性のあるコマンドをＴＰに追加でき、他の信頼性のあるコマンドを除去できることを意味する。（２）ＴＰは永続的であるべきである。これは、信頼性のあるパスが常に存在することをユーザに保証できることを意味する。さらに、より強い特性であるユーザの検証可能性を要求することができ、ユーザの検証可能性は、ＴＰが活性化されていることをユーザが任意の時点において検証することを可能にする。（３）ＴＰは、システムが損なわれた後、回復可能であるべきである。これは、ユーザが例えば信頼性のあるソースからセキュリティカーネルをリブートすることにより、常にＴＰを回復できることを意味する。

従来より、これらの特性のすべてを満たすＴＰがあることは、（ａ）侵入のない（ｐｅｎｅｔｒａｔｉｏｎ−ｆｒｅｅ）セキュリティカーネル（すなわち回避不能で、隔離されかつ検証可能なカーネル）−信頼性のある計算処理機構（trusted computing base:ＴＣＢ）があること、ならびに（ｂ）悪意あるソフトウェア、および可能性としてカーネルを修正することができる内部者のいない環境を前提としていた。信頼性のあるパスを実現した最初の商用のセキュアＵＮＩＸ（登録商標）型システムは、１９８０年代にグリゴル（Ｇｌｉｇｏｒ）らによりＳｅｃｕｒｅ Ｘｅｎｉｘにおいて設計された［２０，２２］。しかし今日のコンピューティング環境では、これらの仮定のいずれも、内部者による攻撃が重大なセキュリティ上の危険を示す大企業で使用される商用既製オペレーティングシステムに関して妥当ではない。さらに、そのようなシステムをインターネットに接続することは、すべてのシステムコードおよびデータに完全にアクセスできるマルウェアの存在をただ保証するだけである。（現在、インターネットに接続する保護されていないホストは平均１２分以内に感染する。）したがって、そのようなシステム上に実装されるＴＰの永続性、およびそのＴＰの回復可能性の両方が失われる。この見解は、信頼性のあるパスを実装するシステムに要求するもう１つの特性を策定することにつながり、その特性とはつまり、（４）信頼性のあるパスに仮定される特性は、形式的に検証可能であるべきである。さもなければ、設計および実装の誤りが、ＴＰをマルウェアおよび悪意ある内部者による攻撃にさらされたままにする。

信頼性のあるパスを確立するために使用可能な最近のＴＣＧの提案［３５］は、測定プロトコルのための信頼の静的ルート（Ｓｔａｔｉｃ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ）および信頼の動的ルート（Ｄｙｎａｍｉｃ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ）として大きく分類することができる。どちらのプロトコルも、公開鍵暗号方式を使用して、システムがブート又はリブートしてからシステムソフトウェアに署名し、システムソフトウェアを認証する。ブートされたコードに暗号ハッシュ関数を適用することにより、プロセッサがそのブート済みコードを「測定」し、ハードウェア保護された秘密鍵を使ってハッシュに署名する。検証エージェントは、そのハッシュを自らがコピーを有する予期されるブートコードのハッシュと比較し、それにより、ブートされたコードが修正されていないことを証明することができる。この基礎に基づいてすべての信頼性のあるソフトウェアを裏付けることができ、その結果ユーザは、たとえマルウェアおよび悪意ある内部者があっても、原則として金融取引を扱うアプリケーション、暗号取引（例えばローカルおよびリモートシステム又はアプリケーションのキーイングおよび再キーイング）を扱うアプリケーション、コマンドおよび制御アプリケーション、オンラインフォレンジックアプリケーションなど、機密情報を扱う重要度の高いアプリケーションに対してＴＰを確立し、拡張することができる。

ＳＲＴＭ（Ｓｔａｔｉｃ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ ｆｏｒ Ｍｅａｓｕｒｅｍｅｎｔ）プロトコルでは、ＢＩＯＳ、アダプタカード上のファームウェア、ブートローダ、オペレーティングシステムから始まり、所望のＴＰアプリケーションコマンドで終わるすべてのシステムコードが証明プロセスによって署名され、認証される。したがって、（ＳＲＴＭブートシーケンスを含む）何百万行ものソースコードを形式的に検証することは現在のソフトウェア検証ツールの技術的現状を超えるので、特性（４）を達成することができない。対照的に、ＤＲＴＭ（Ｄｙｎａｍｉｃ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ ｆｏｒ Ｍｅａｓｕｒｅｍｅｎｔ）プロトコル［２９，２５］は、信頼性のある処理機構（ｔｒｕｓｔｅｄ ｂａｓｅ）を形式的な分析および検証を潜在的に受け入れることができる管理可能な大きさ（例えばセキュアローダやＢＩＯＳの選択された部分）にまで減らすことにより、この問題に対処する。しかし、ＴＰの（１）信頼性のある拡張可能性、（２）永続性およびユーザの検証可能性、ならびに（３）回復特性を、ＳＲＴＭプロトコルおよびＤＲＴＭプロトコルによって達成できるかどうかは、敵対者の攻撃の強さ次第である。ＴＣＧ仕様［３５］内で述べられているように、ＴＰＭ（Trusted Platform Module）は、改竄を防ぐ、すなわち物理的に攻撃される恐れがないように設計されていないことを最初に指摘しておく。さらに、たとえ証明用に使用する秘密鍵を記憶するＴＰＭの物理的改竄防止を想定しても、内部者がシステムのＴＰＭに対してではなく、所有者によって放置されたままのシステムに対して物理的攻撃を仕掛けるときはいつでも、ＳＲＴＭプロトコルもＤＲＴＭプロトコルも特性（１）〜（３）をサポートすることはできない。

システムのマザーボード上のＬＰＣ（Ｌｏｗ Ｐｉｎ Ｃｏｕｎｔ）バスおよびＴＰＭドライバを含むＢＩＯＳコードの両方にアクセス可能な内部者は、ＴＰＭリセット攻撃を仕掛けることができる［２５，３４，１］。この攻撃では、正しいＢＩＯＳ、アダプタカードファームウェア、ブートローダ、およびＯＳのハッシュをロードする一方で、内部者が仕込んだそのブートシーケンスの不正バージョンが実行されることにより、ＴＰＭがＳＲＴＭブートシーケンスをリスタートする。この攻撃は、内部者が自身の攻撃を仕掛ける前にＬＰＣバスを受動的にモニタし［２８］、攻撃されているのと同一のシステムの正しいハッシュ値を記録することにより、ＴＰＭによって署名され、後に証明を通過する正しいブートシーケンスのハッシュ値を得ることができるので実践的である。最近報告されたＴＰＭリセット攻撃［３４，１］が示すように、正しいハッシュ値は、ＳＲＴＭブートシーケンス中に、内部者によって修正されたＢＩＯＳによりＴＰＭに供給される。ＳＲＴＭブートシーケンスに対するこの攻撃に反撃するために、ＤＲＴＭプロトコルは、アトミックに（すなわち非割込的に）（１）ＣＰＵを、知られている信頼性のある状態に初期化し、（２）ＬＰＣバスを介してセキュアローダのコードを、その内部レジスタの１つの中にハッシュするＴＰＭに転送し、（３）制御をセキュアローダのエントリポイントに移す新たなＣＰＵ命令を使用する［２，２４］。次いで、セキュアローダはＢＩＯＳの関連部分を測定し、セキュアブートシーケンスを開始する。内部者によるＴＰＭリセット攻撃の唯一の影響は、セキュアＤＲＴＭブートシーケンスをリスタートすることである。しかし、このＤＲＴＭプロトコルは、ＴＰＭをリセットしない別の等しく有力な内部者攻撃によって覆される可能性がある。その代わりとして、内部者は、その新たなＣＰＵ命令から生じたように装う信号をＬＰＣバス内に投入することにより、その新たなＣＰＵ命令のアトミック性を欺く［３４，１］。このように欺くことは、内部者が、自身の修正済みローダが実行されながら、正しいローダのハッシュ値をＴＰＭに伝達することを可能にする。したがって、内部者が仕込んだブートシーケンスは、ＤＲＴＭプロトコルを始動させ、証明を通過し、信頼性のあるパスの特性を欺くことになる。原則として、ＴＰＭがどんなに物理的に改竄防止されていようが、ＴＰＭのＬＰＣバスが無許可の外部アクセスにさらされている限り、新たな攻撃に弱い可能性があるビルトインシークレットに依拠することなしにＤＲＴＭプロトコルを保護することはできない。

ＳＲＴＭプロトコルまたはＤＲＴＭプロトコルに対する、物理的ではないが、より有力な攻撃が内部者およびマルウェアのうちの少なくとも一方によって仕掛けられる可能性がある。これらの攻撃は、改竄防止ＴＰＭの秘密鍵を敵対者に漏らすサイドチャネル技法を使用する。例えば、オープンＳＳＬの秘密ＲＳＡ鍵に対するブルームレイ（Ｂｒｕｍｌｅｙ）およびボネ（Ｂｏｎｅｈ）のタイミング攻撃［５］が、ＴＰＭの秘密ＲＳＡ鍵に対するデモ攻撃において最近使用された［３４］。原則として、改竄防止ＴＰＭのプライベート鍵または秘密鍵を知るために、例えば差分電力解析［２７］およびフォルト投入［４］に基づく他のサイドチャネル攻撃を改竄防止ＴＰＭに対して仕掛けることができる。そのような攻撃は信頼性のあるパスを使用不能にするだけでなく、より重要なことに、ＳＲＴＭプロトコルまたはＤＲＴＭプロトコルのいずれによっても、ユーザはそのような攻撃から回復すること（すなわち上記の特性（３））ができない。

ＴＰの設計が、ハードウェア自体によって（例えばＰＵＦ（Ｐｈｙｓｉｃａｌｌｙ Ｕｎｃｌｏｎｅａｂｌｅ Ｆｕｎｃｔｉｏｎ）を使用して［１９］）生成され、またはＥＰＲＯＭ上に記憶される秘密（対称）鍵に基づく場合、ＴＰ回復のとりわけ問題となる事例が生じる。この場合、秘密鍵はハードウェアベースに恒久的に付加されることになり、変更することはできない。そのように秘密鍵を変更できないことは、暗号がどんなに安全であろうと、一定の使用量の後に鍵の寿命が切れることを理由に、または完全なもしくは部分的な鍵の発見につながる可能性がある不良環境内の不可避の攻撃（例えばタイミング攻撃や差分電力解析攻撃などのサイドチャネル攻撃）を阻止しなければならないことを理由に鍵を変えなければならないことを示す暗号法の根本原理に背く。さらに、ランダムであろうとフォルト投入攻撃によって引き起こされようと、鍵の完全性を損なう可能性がある任意の起こり得るハードウェア障害が、ＴＰだけでなくシステム全体を回復不能にする。このアーキテクチャを僅かに変更することでは、この状況は改善されないことも指摘しておく。例えば、秘密鍵がプログラム可能レジスタ内に記憶され、変更可能になる場合、ユーザ自身ではないにせよ信頼性のあるパーティにより、何らかの形のＴＰを介して鍵へのアクセスを管理する必要があり、更新を行う必要がある。すなわちそのＴＰは別のＴＰなしにブートストラップすることはできない。ＣＰＵとＴＰＭとの間のＬＰＣバス上の通信を暗号化することにより、ＤＲＴＭプロセスが想定する基礎をなすＴＰＭアーキテクチャを保護しようと試みるときに同様のブートストラップ問題が発生し、つまり信頼性のあるパスは秘密のバス暗号鍵をセットおよびリセットするように求められる。

したがって、ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムおよびＬＩＮＵＸ（登録商標）オペレーティングシステムを実行する商用システムが含まれる商用システムのための、上記に特定した特性（１）〜（４）を満たす信頼性のあるパスを提供することが求められている。

よって、マルウェアがある状態でユーザが検証可能な信頼性のあるパスを確立すること、より詳細には、信頼できないコンピュータプラットフォーム上で使用するためのそのような方法および機器が求められている。本発明のそれらのおよび他の利点について以下により詳細に説明する。

本発明は、一般にＷｉｎｄｏｗｓオペレーティングシステムおよびＬｉｎｕｘオペレーティングシステムを実行する商用システムを含む商用システムのための、上記に特定した特性（１）〜（４）を満たす信頼性のあるパスを提供するためのシステムを対象とする。さらに本発明の改変形態には、既存の手法、とりわけＴＣＧ（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ）［３５］が提案する、暗号鍵を保護し、装置上にロードされたソフトウェアを特定するためのハードウェアベースの手法を包含する実施形態が含まれ得る。本発明では要求されていないが、本発明の一実施形態は、ＴＣＧの提案とは異なり、ハードウェアまたはソフトウェア内に記憶されたどんな秘密も使用しない信頼性のあるパス確立プロトコルを使用し、それにより広い攻撃面を除去し、システムが損なわれた後にユーザが開始する信頼性のあるパスの回復（すなわち特性（３））を容易にすることができる。さらに、本発明者らのプロトコルの信頼性のあるコンポーネントは小さく、特性（４）を満たすために要求されるような形式的分析を可能にする。以下に、内部者およびマルウェアの攻撃を前にして、ＴＣＧの提案が、なぜ４つすべての所望の特性を満たすことができないのかを示す論拠を概説する。これらの事項は最近の研究［２８，２５，３４，１］、ならびにＴＣＧのアーキテクチャおよびプロトコルについての進行中の正式な研究［１８］に基づく。その後、本発明者らの手法がどのようにこれらの問題を回避し、４つすべての特性を成功裏に達成するのかを要約する。

本発明のＴＰ設計の（以下に詳細に説明する）１つの独自の特徴は、本発明のＴＰが、システム内のどこでも、ハードウェア保護された秘密に依拠することなしにオプションで動作できることである。したがって、本発明者らの設計は、代替的で根本的に異なるＴＰ設計への取り組み、および秘密鍵が使用されるとき、秘密鍵が漏洩することからの信頼性のある回復基盤の両方を提供する。この設計は、ＴＣＧの提唱が提案するように、ことによるとユーザ自身および信頼性のあるサードパーティが安全かつ実践的方法で変更可能なハードウェア保護された秘密鍵を使用し、アプリケーションレベルのユーザ検証されたＴＰをブートストラップすることを可能にする。この設計は、マルウェアがないこと、または内部者攻撃がない環境内で動作することが予期されていない既製ソフトウェア（例えばＷｉｎｄｏｗｓ、Ｌｉｎｕｘ、およびそれらのアプリケーション）をユーザが実行することも可能にする。

本発明は、プロセッサによって実行されるとき、本発明による特定のアクションをそのプロセッサに実行させるソフトウェア、ファームウェア、ハードウェア、他の実施形態などのコンピュータ可読命令を含み、またはそうしたコンピュータ可読命令として実施することができる。一実施形態では、本発明は、プロセッサと、メモリと、入力装置と、出力装置とを含む機器を含み、そのメモリは、実行時に本明細書に記載の方法をプロセッサに実行させるコンピュータ可読命令を含む。

要約すれば、本発明は、今日までに知られている最も強力な敵対者からの攻撃に対する耐性を改善した。本発明は、マルウェアおよび悪意ある内部者の攻撃がある状態で、例えばコマンドおよび制御システム、暗号取引、金融取引、オンラインフォレンジック分析など、機密情報を扱う高価な用途に使用することができる。

本発明では他の多くの改変形態が可能であり、本発明の説明および図面から、本発明のそれらのおよび他の教示、改変形態、および利点が明らかになる。
次に本発明の諸実施形態を専ら例として、本発明を限定するためではなく、それらの実施形態を例示するための添付図面に関して説明する。

本発明によるコンピュータの一実施形態を示す図である。 数台のコンピュータがネットワークを介して共に接続される本発明の別の実施形態を示す図である。 本発明により作成し、使用することができるコンピューティングプラットフォームの一実施形態を示す図である。 プロセッサが検証装置と対話する方法の一実施形態を示す図である。 コンピュータ内のプロセッサによって実行される本発明によるプロセスの一実施形態を示す図である。 コンピュータ内のプロセッサによって実行される本発明によるプロセスの一実施形態を示す図である。 プロセッサから選択実行ファイルに関係する情報を受け取った後、検証装置によって実行される本発明によるプロセスの一実施形態を示す図である。 本発明によって実行される方法の実施形態を示す図である。 本発明によって実行される方法の実施形態を示す図である。 本発明によって実行される方法の実施形態を示す図である。 本発明によって実行される方法の実施形態を示す図である。 本発明によって実行される方法の実施形態を示す図である。 本発明によって実行される方法の実施形態を示す図である。 本発明によって実行される方法の実施形態を示す図である。 本発明によって実行される方法の実施形態を示す図である。 本発明によって実行される方法の実施形態を示す図である。 本発明によって実行される方法の実施形態を示す図である。 本発明の一実施形態による基本的システムアーキテクチャの全体像の一実施形態を示す図である。 本発明による信頼性のある検証器の状態機械の一実施形態を示す図である。 本発明による信頼性のある検証器証明プロトコルの一実施形態を示す図である。 本発明による信頼性のあるアプリケーションのアーキテクチャの一実施形態を示す図である。Ｅ１およびＥ２は２つの実行ファイルである。 本発明による検証可能コード実行プロトコルの概要の一実施形態を示す図である。数字は各イベントの時間的順序を表す。 本発明による検証可能コード実行プロトコルの一実施形態を示す図である。各イベントの番号付けは図２１にあるのと同じである。Ｖは検証器、Ｐは検証関数、Ｅは目標実行ファイルである。

図１は、本発明によるコンピュータ１１０の一実施形態を示す。その実施形態では、コンピュータ１１０は、プロセッサ１１２、メモリ１１４、入力装置１１６、出力装置または表示装置１１８、および検証装置１２０を含む。プロセッサ１１２は、メモリ１１４、入力装置１１６、および出力装置１１８に接続される。メモリ１１４は、プロセッサ１１２によって実行されるとき、本明細書に記載の特定の機能をプロセッサ１１２に実行させるコンピュータハードウェア、ソフトウェア、ファームウェア、または他の形式のコンピュータ可読命令などのコンピュータ可読命令を含む。コンピュータ１１０は、本明細書に示さない１つまたは複数の他の装置を含んでもよい。この実施形態は、検証装置１２０をコンピュータ１１０の一部として説明するが、検証装置１２０はコンピュータ１１０から分かれていてもよい。

プロセッサ１１２は、入力装置１１６から入力を受け取り、出力装置１１８を制御するための信号を提供し、例えば検証装置１２０との間の信号などの他の信号を提供し、受け取る。プロセッサ１１２は、本明細書に記載の特定の機能も実行する。

メモリ１１４は、任意の形式のコンピュータ可読メモリであり、情報を磁気形式、光学形式、電気形式、または他の形式で記憶する。メモリ１１４は、プロセッサ１１２によって実行されるとき、本明細書に記載の特定の機能をプロセッサ１１２に実行させるコンピュータ可読命令を含む。

メモリ１１４は、多くの改変形態を有することができる。例えば、メモリ１１４はプロセッサ１１２から分けるか、またはメモリ１１４はプロセッサ１１２と一体化する。メモリ１１４は、１つのメモリ装置を含むか、またはメモリ１１４は、複数のメモリ装置を含む。例えばメモリ１１４は、１つまたは複数の不揮発性メモリのメモリ装置を含むか、１つまたは複数の揮発性メモリのメモリ装置を含む。例えばメモリ１１４は、磁気ディスクドライブ、光学ドライブ、フラッシュメモリなど、長期にわたりデータを記憶するための記憶媒体装置１３０を含む。メモリ１１４は、ＲＡＭ１３２または他の機能用の他のメモリ装置も含む。本発明とともに、メモリ１１４の他の組合せおよび改変形態も使用する。

入力装置１１６は、キーボード、タッチスクリーン、コンピュータマウス、またはユーザからの情報を入力する他の形態とする。入力装置１１６は、別のコンピュータから入力を受け取るためのデータポートなどの、人間のユーザ以外のソースから情報を入力するように使用される。

出力装置１１８は、ビデオディスプレイまたはユーザに対して情報を出力する他の形態とすることができる。出力装置１１８は、ビデオ装置、オーディオ装置、プリンタ、または例えばライト、スピーカや他の形式の出力など、ユーザに情報を伝えまたはユーザの注意を引くために使用可能な他の装置とする。出力装置１１８は、データポートなど、人間のユーザ以外のものに情報を出力するように使用される。

入力装置１１６および出力装置１１８を、ユーザインターフェイス１５０と呼ぶ。ユーザインターフェイス１５０は、入力装置１１６および出力装置１１８の両方を含んでよく、またはユーザインターフェイス１５０は、入力装置１１６および出力装置１１８の一方だけを含んでもよい。本発明は、１つまたは複数の信頼性のあるチャネル１５２も含む。一部の実施形態では、信頼性のあるチャネル１５２は、ユーザインターフェイス１５０とプロセッサ１１２との間に存在する。他の実施形態では、信頼性のあるチャネル１５２は、プロセッサ１１２とユーザインターフェイス１５０とを相互接続する他のシステムコンポーネントを通過し、プロセッサとユーザインターフェイス１５０との間に延びることができる。そのようなコンポーネントには、バス、相互接続器、メモリコントローラハブ、入出力コントローラハブ、および他のコンポーネントが含まれ得る。一部の実施形態では、これらの他のコンポーネントがチャネルの信頼性に極めて重要である。他の実施形態では、これらのコンポーネントの挙動がチャネルに影響を及ぼさない場合がある。また、他の構成もあり得る。

検証装置１２０は、プロセッサ１２２およびメモリ１２４を含む。検証装置１２０は、入力装置１２６および出力装置１２８も含む。一部の実施形態では、検証装置１２０は本明細書に記載の理由で比較的小さい。例えば、検証装置１２０を小さく単純にしておくことで、装置１２０が提供するセキュリティについて利点をもたらすことができる。また、検証装置１２０がコンピュータ１１０から取外し可能であり、ユーザが身に付けて持ち運べるように意図される場合、比較的小さいサイズは有利である。しかし、小さいサイズは必須ではなく、とりわけ検証装置１２０がコンピュータ内に組み込まれる場合、または検証装置１２０が、ユーザが身に付けて持ち運べるように意図されない場合、検証装置１２０はより大きく、他の特徴および機能を含み得る。取外し可能な検証装置１２０の場合、検証装置１２０は、コンピュータ１１０に恒久的に取り付けられないように通信インターフェイス１４０も含むことができる。インターフェイス１４０は、例えばＵＳＢポート、赤外線送信機／受信機、またはユーザが検証装置１２０を接続し、取り外すことを可能にする他の通信インターフェイスとすることができる。それらの実施形態では、コンピュータ１１０も、検証装置１２０の通信インターフェイス１４０を補足する通信インターフェイス１４０を有する。

検証装置１２０は、コンピュータ１１０の他のパーツと一体化するか、または検証装置１２０は、ユーザにより取外し可能であり、持ち運び可能とすることができる。一実施形態では、検証装置１２０は、コンピュータの一部であり、かつユーザがアクセス可能であり得るＵＳＢポートや他の任意のポートなど、コンピュータのポートに差し込まれる。

検証装置１２０は、コンピュータ１１０の他のパーツに関する情報またはポリシを含む。例えば検証装置１２０は、安全な実行ファイル３１２（図３参照）およびハイパーバイザ３１６（図３参照）に関するポリシならびに他の情報を含む。この検証装置は、実行ファイルごとにポリシを含むか、または複数の実行ファイルによって共有されるポリシを含む。例えばそのポリシは、選択実行ファイル３１２、ハイパーバイザ３１６、およびコンピュータ１１０の他のパーツに関する既知の良好なアイデンティティ測定（identity measurement）を含む。実行ファイルに関するアイデンティティ測定は、それらの実行ファイルについて計算される暗号学的ハッシュとするか、デジタル署名を含むか、または他の形をとる。

また、そのポリシは、ネットワークインターフェイスを有する実行ファイル、または他の方法でネットワーク２１０（図２参照）にアクセスできる実行ファイルのための、ネットワーク２１０上の信頼性のあるエンドポイントのリストを含む。検証装置１２０は、例えばネットワーク２１０上の信頼性のあるエンドポイントの単一のリストを含むか、実行ファイルごとに信頼性のあるエンドポイントのリストを含むか、または信頼性のあるエンドポイントの複数のリストを含み、それらの複数のリストの一部は特定の実行ファイルに固有であり、それらの複数のリストの一部は複数の実行ファイルによって共有される。各ポリシは、異なる実行ファイルに適用するか、または一部のポリシを複数の実行ファイルが共有する。

そのポリシは、特定の実行ファイルが情報を共有するか、または他の方法で通信することができる他の実行ファイルを特定する。例えば、選択実行ファイル３１２が情報を共有することができる他の実行ファイルを特定する、選択実行ファイル３１２用のポリシがある。

検証装置１２０は、ポリシまたは他の情報を追加するか、削除するか、もしくは修正することを許可してもしなくてもよい。例えば一実施形態では、検証装置１２０は、ネットワーク２１０上の信頼性のあるエンドポイントを更新することを許可する。別の実施形態では、検証装置１２０が危険にさらされるリスクを減らすために、検証装置１２０は読取り専用である。

検証装置１２０は、プロセッサ１１２に接続される。これは、検証装置１２０がプロセッサ１１２と一体化するか、またはプロセッサ１１２に物理的に取り付けられることを必ずしも意味するものではなく、むしろ本明細書に記載の方法を実行するために、検証装置１２０とプロセッサ１１２との間に直接的または間接的通信リンクがあることを意味する。

検証装置１２０内のプロセッサ１２２は、本明細書に記載の特定の機能を実行する。検証装置１２０内のプロセッサ１２２は、プロセッサ１１２に接続され、プロセッサ１１２と通信する。

検証装置内のメモリ１２４は、任意の形式のコンピュータ可読メモリであり、情報を磁気形式、光学形式、電気形式、または他の形式で記憶する。メモリ１２４は、メモリ１１４に関して上記に記載したものなど、多くの改変形態を有する。例えば、検証装置内のメモリ１２４は検証装置内のプロセッサ１２２から分離されるか、または検証装置内のメモリ１２４は検証装置内のプロセッサ１２２と一体化する。また、検証装置内のメモリ１２４は複数のメモリ装置を含み、それらのメモリ装置は検証装置内のプロセッサ１２２と一体化するか、検証装置内のプロセッサ１２２から分離するか、またはその両方とする。他の改変形態もあり得る。

メモリ１２４は、検証装置内のプロセッサ１２２によって実行されるとき、本明細書に記載の特定の機能を検証装置内のプロセッサ１２２に実行させるコンピュータ可読命令を含む。

入力装置１２６および出力装置１２８は、コンピュータ１１０の入力装置１１６および出力装置１１８と同じでも異なってもよい。例えば、検証装置１２０は比較的小さな装置であり、その結果、入力装置１２６および出力装置１２８はそれに応じて小さく簡易化される。例えば、キーボードやコンピュータマウスではなく、入力装置１２６は、アナログスイッチや多位置ノブなど、ユーザからの入力用の１つまたは複数のボタンもしくはスイッチを含む。同様に、完全なビデオディスプレイではなく、出力装置１２８は、ユーザにフィードバックを与えるための１つまたは複数のライト、ブザー、もしくは他の装置を含む。あるいは、検証装置１２０は、より大きくかつ／またはより複雑な入力装置１２６および出力装置１２８を有してもよい。一実施形態では、検証装置１２０は、ＰＤＡまたはスマートフォンで使用するような「ソフトキー」および電子ディスプレイを含む。他の実施形態では、検証装置１２０は、ソフトキーと物理的なボタンまたはスイッチとの組合せを含む。他の改変形態もあり得る。

本発明によるコンピュータ１１０では、多くの改変形態があり得る。例えば、コンピュータ１１０内にまたはコンピュータ１１０とともに、複数のプロセッサ１１２、メモリ１１４、入力装置１１６、出力装置１１８、および検証装置１２０（それに加え検証装置１２０内の各コンポーネントの複数）が設けられている。さらに、図１に不図示の装置がコンピュータ１１０内に含まれていてもよく、図１に示す各装置は、単一の装置へと組み合わせもしくは一体化するか、または場合によっては省略することができる。本明細書に記載し、図示する他の実施形態でも、同様の改変および修正が可能である。

本発明は多くの形態で実施する。例えば本発明は、チップ上のソフトウェアなどの埋め込みシステムとする。別の実施形態では、本発明は、図１に示す本発明の１つまたは複数のパーツ内に位置する１つまたは複数の装置として実施する。例えば本発明は、コンピュータ可読命令（例えばチップ上のソフトウェア、可搬メモリ装置または統合メモリ装置内のソフトウェア、ハードウェア装置内に組み入れられるハードワイヤード命令、または他の改変形態）として実施される。別の実施形態では、本発明を１台または複数台の個別のコンピュータとして実施される。本発明は、コンピュータ可読命令（例えばコンピュータソフトウェア、ファームウェア、またはハードウェア）として実施される。それらのコンピュータ可読命令は、別の装置内に一体化されるかもしくは埋め込まれるメモリ装置内に、または取外し可能および持ち運び可能なメモリ装置内に記憶される。他の改変形態および実施形態もあり得る。

図２は、数台のコンピュータ１１０がネットワーク２１０を介して共に接続される本発明の別の実施形態を示す。ネットワーク２１０は、数台のコンピュータ１１０間の接続を可能にする。コンピュータ１１０を、ネットワーク２１０上の「エンドポイント」と呼ぶ。つまり、ネットワーク２１０上のコンピュータ１１０のうちの１台の観点からすれば、他のコンピュータ１１０は、ネットワーク接続を行うことができるネットワーク２１０上のエンドポイントである。

ネットワーク２１０は、例えばインターネット、ローカルエリアネットワーク、広域ネットワーク、メトロエリアネットワーク、または他の種類のネットワークとすることができる。ネットワーク２１０は、有線ネットワーク（電気ネットワークや光ネットワークなど）、無線ネットワーク、または様々な種類のネットワークの組合せとすることができる。

上記に記載したように、本発明はソフトウェア、ハードウェア、またはファームウェアとして実施されるか、または他の形式で具体化される。本発明は、例えばネットワーク２１０内のコンピュータ１１０の一部により、またはそのすべてにより具体化される。例えば、１台のコンピュータ１１０だけが検証装置１２０を含むことができる一方、ネットワーク２１０上の他のコンピュータ１１０は検証装置１２０なしで動作する。他の実施形態では、コンピュータ１１０の数台またはすべてが検証装置１２０を含む。他の実施形態では、検証装置１２０を含む本発明を実施する１つまたは複数のパーツを、ネットワーク２１０自体が含む。

図３は、本発明により作成されて、使用されるコンピューティングプラットフォーム３１０の一実施形態を示す。コンピューティングプラットフォーム３１０は、例えばプロセッサ１１２によって実行されるときであって、コンピュータ１１０のメモリ１１４内のコンピュータ可読命令が、プロセッサ１１２にコンピューティングプラットフォーム３１０を作成させるときに作成される。

図示の実施形態では、コンピューティングプラットフォーム３１０が、信頼性のある実行ファイル、ドライバシム（ｄｒｉｖｅｒ ｓｈｉｍ）３１４、およびハイパーバイザ３１６を含む。コンピューティングプラットフォーム３１０は、１つまたは複数のネットワークインターフェイス３２０、および１つまたは複数の信頼できない実行ファイル３３０も含んでもよい。ユーザインターフェイス１５０、信頼性のある実行ファイル３１２、ドライバシム３１４、ハイパーバイザ３１６、および信頼できない実行ファイル３３０は、特権レベル、アイデンティティ（identity）、および他の特徴など、１つまたは複数の特徴をそれぞれ有してもよい。

信頼性のある実行ファイル３１２は、破損しておらず、安全に実行できると想定される実行ファイルである。信頼性のある実行ファイル３１２は、例えば保護された金融取引に使用されるか、またはヘルスケア提供者と個人情報および機密情報をやり取りするために使用されるアプリケーション、またはユーザが信頼する情報もしくは他の何らかのアプリケーションである。

対照的に、信頼できない実行ファイル３３０は、信頼されていない実行ファイル、または安全であるかもしくはマルウェアによる感染などの望ましくない状態が存在しないと考えられていない実行ファイルである。

ハイパーバイザ３１６は、信頼性のある実行ファイル３１２および信頼できない実行ファイル３３０の両方にアクセスでき、信頼性のある実行ファイル３１２および信頼できない実行ファイル３３０が利用できる情報とアクセスを管理する。ハイパーバイザ３１６は、例えばメモリ１１４の分割など、他のタスクも実行することができる。一実施形態では、ハイパーバイザ３１６は、信頼性のある実行ファイル３１２が排他的に使用するためにメモリ１１４の固有の部分を分割し、信頼できない実行ファイル３３０が排他的に使用するためにメモリ１１４の固有の部分を分割し、ハイパーバイザ３１６が排他的に使用するためにメモリ１１４の固有の部分を分割する。複数の信頼性のある実行ファイル３１２、複数の信頼できない実行ファイル３３０、および複数のハイパーバイザ３１６のためにメモリ１１４を分割することなど、他の多くの実施形態もあり得る。メモリ１１４の固有の部分は、同一メモリ装置の異なる部分とするか、別々のメモリ装置の部分とするか、またはその組合せとする。さらに、ハイパーバイザ３１６は、それらの装置が共用するためにメモリを分割することもでき、ハイパーバイザ３１６は、コンピュータ１１０の他のパーツが排他的に使用するか、または共用するためにメモリを分割することができる。

ネットワークインターフェイス３２０は、ネットワーク２１０への接続を可能にする。一部の実施形態では、物理的ネットワークインターフェイス３２０が検証装置１２０内に位置する。このことは、ハイパーバイザ３１６がネットワークインターフェイス３２０へのアクセスを制御することを可能にするので有利である。他の実施形態では、ネットワークインターフェイス３２０は、コンピュータの別のパーツ内など、検証装置１２０の外部に位置する。ネットワークインターフェイス３２０が検証装置１２０内に位置する場合のように、この実施形態も、ハイパーバイザ３１６がネットワークインターフェイス３２０へのアクセスを制御することを可能にする。

コンピューティングプラットフォーム３１０は、多くの構成をとることができる。例えばコンピューティングプラットフォーム３１０は、１つまたは複数の信頼性のある実行ファイル３１２、１つまたは複数の信頼できない実行ファイル３３０、１つまたは複数のドライバシム３１４、および１つまたは複数のハイパーバイザ３１６を含む。さらに、コンピューティングプラットフォーム３１０は、本明細書に示さない他の機能を含むことができる。

図４は、本発明の一実施形態による信頼性のあるパスを確立するために、プロセッサ１１２が検証装置１２０と対話する方法の一実施形態を示す。図示の実施形態において、このプロセスは、信頼性のある実行ファイル３１２を実行する要求が最初にある状況を表す。信頼性のあるパスを確立するこのプロセスは、安全な接続を認証するステップを含むことができる。

図５Ａは、信頼性のある実行ファイル３１２を実行する要求を示す信号をプロセッサ１１２が受け取った後、プロセッサ１１２によって実行される本発明によるプロセスの一実施形態を示す。信頼性のある実行ファイル３１２を実行する要求は、コンピューティングプラットフォーム３１０を作成した直後に受け取るか、またはその要求は１つもしくは複数の信頼できない実行ファイル３３０を実行することなど、プロセッサ１１２が他のタスクを実行した後の時点において受け取る。その要求を受け取った後、プロセッサ１１２は信頼性のある実行ファイル３１２に関係する特定の情報を検証装置１２０に送る。

図６は、プロセッサ１１２から信頼性のある実行ファイル３１２に関係する情報を受け取った後、検証装置１２０によって実行される本発明によるプロセスの一実施形態を示す。検証装置１２０は、信頼性のある実行ファイル３１２を実行すべきかどうかを判定し、プロセッサ１１２に信号を送り返す。

図５Ｂは、検証装置１２０から信号を受け取った後、プロセッサ１１２によって実行される本発明によるプロセスの一実施形態を示す。
次に図５Ａ、図５Ｂ、および図６のそれぞれをより詳細に説明する。

図５Ａおよび図５Ｂは、プロセッサ１１２によって実行される別の方法の一実施形態を示す。この方法は、コンピューティングプラットフォーム３１０を作成し終え、ユーザが信頼性のある実行ファイル３１２を実行したいときに実行する。この方法は、例えば、プロセッサ１１２によって実行されるとき、プロセッサ１１２のメモリ１１４内のコンピュータ可読命令が、プロセッサ１１２に以下のステップを実行させるときに実行する。

ステップ５１０は、信頼性のある実行ファイル３１２を実行する要求を示す信号を受け取ることを含む。この信号は人間のユーザによって開始されてもよく、またはコンピュータ１１０の他の何らかのパーツによってもしくは別のコンピュータによって開始されてもよい。

ステップ５１２は、ハイパーバイザ３１６と検証装置１２０との間の安全な接続を認証することを含む。このステップは、選択実行ファイル３１２を実行する要求を示す信号を受け取った後に実行される。

ステップ５１４は、ハイパーバイザ３１６の少なくとも一部分のアイデンティティを測定することを含む。このステップは、ハイパーバイザ３１６全体のアイデンティティを測定するか、またはハイパーバイザ３１６の一部のアイデンティティを測定する。この測定は、ハイパーバイザ３１６が既知の状態にあるときに行う。ハイパーバイザ３１６のこの測定は、ハイパーバイザ３１６が適切な状態にあるかどうか、または修正されるかもしくは他の方法で損なわれているかどうかを判定するために使用される。例えばハイパーバイザ３１６がマルウェアに感染した場合、ハイパーバイザ３１６のアイデンティティの測定値は、感染していないハイパーバイザ３１６の測定値とは異なる。

ステップ５１６は、ハイパーバイザ３１６のアイデンティティの測定値を検証装置１２０に送ることを含み、検証装置１２０において、その測定値は検証装置１２０内に記憶されるポリシと比較される。あるいは、この比較はプロセッサ１１２によって実行されてもよいが、プロセッサ１１２よりも検証装置１２０の方が安全な場合があり、したがって検証装置１２０を使用することが好ましいことがある。

ステップ５１８は、ドライバシム３１４の少なくとも一部分のアイデンティティを測定することを含む。
ステップ５２０は、ドライバシムのアイデンティティの測定値を検証装置１２０に送ることを含み、検証装置１２０において、その測定値は検証装置１２０内に記憶されるポリシと比較される。あるいは、この比較はプロセッサ１１２によって実行されてもよいが、プロセッサ１１２よりも検証装置１２０の方が安全な場合があり、したがって検証装置１２０を使用することが好ましい。

ステップ５２２は、ユーザインターフェイス１５０の少なくとも一部分のアイデンティティを測定することを含む。
ステップ５２４は、ユーザインターフェイス１５０のアイデンティティの測定値を、ユーザインターフェイス１５０用のポリシと比較することを含む。このステップは、プロセッサ１１２によって実行されてもよく、または検証装置１２０内で実行されてもよい。

測定値を受け取った後に検証装置１２０が実行するステップについて、図６を参照して以下に説明する。
ステップ５２６は、信頼性のあるパス１５２が確立されているかどうかを示す信号を検証装置１２０から受け取ることを含む。信頼性のあるパス１５２が確立されている場合、このプロセスはステップ５２０に進む。信頼性のあるパスが確立されていない場合、このプロセスはステップ５２０には進まない。

ステップ５２８は、信頼性のあるパスが確立されていることを検証装置１２０からの信号が示す場合、信頼性のある実行ファイルを実行することを含む。このステップ５２８は、信頼性のある実行ファイル３１２を実行する前に、さらなる条件が満たされていることも必要とし得る。

ただし、信頼性のある実行ファイル３１２を実行すべきでないことを検証装置１２０からの信号が示す場合、ステップ５２８は実行しなくてもよい。例えばコンピュータ１１０は、これらの状況において信頼性のある実行ファイル３１２が決して実行されない省略時解釈（default）を含む。あるいは、例えば（たとえ検証装置１２０が受け取った信頼性のある実行ファイル３１２の測定値が、検証装置１２０内に記憶されるポリシに一致しないことを示す信号をユーザが受け取った後でさえ）ユーザが追加入力を行って信頼性のある実行ファイル３１２を実行する場合など、コンピュータ１１０はオーバーライドを含む。ユーザからのこの入力は、図６に関して以下に説明するように例えば検証装置１２０上の入力を介して行う。

ステップ５１２〜５２４は、信頼性のある実行ファイル３１２を実行する要求を示す信号を受け取るステップ５１０の後に実行される。選択実行ファイル３１２が測定後かつ実行前に損なわれる状況を避けるために、最近の測定値が望ましい。これらのステップはさらに、コンピュータ１１０をリブートすることなしに実行される。コンピュータ１１０をリブートすることは時間がかかり、ユーザが待たなければならない時間を減らすことが望ましいので、このことは重要である。ただし、コンピュータ１１０をリブートする実施形態など、本発明は様々な実施形態で使用することができる。

図６は、検証装置１２０のプロセッサ１２２によって実行される方法の一実施形態を示す。この方法は、選択実行ファイル３１２が依然として安全であり、損なわれていないことを検証するために、図５Ａのステップ５１４および５１８の後に実行することができる。例えば、検証装置１２０内のプロセッサ１２２によって実行されるときであって、検証装置１２０のメモリ１２４内のコンピュータ可読命令が、検証装置１２０内のプロセッサ１２２に以下のステップを実行させるときにこの方法は実行される。

ステップ６１０は、コンピュータ１１０内のプロセッサ１１２からハイパーバイザ３１６の測定値を受け取ることを含む。この測定値および測定値を送ることについては、図５Ａにおいて上述した。

ステップ６１２は、検証装置１２０内に記憶されるポリシを、検証装置１２０が受け取るハイパーバイザ３１６の測定値と比較することを含む。このステップは、ハイパーバイザ３１６の測定値を検証装置１２０内にポリシとして記憶される既知の値と比較し、検証装置１２０が受け取ったハイパーバイザ３１６の測定値が検証装置１２０内に記憶されるポリシに一致するかどうかを判定する。

ステップ６１４および６１６は、ドライバシム３１４に適用されることを除き、ステップ６１０および６１２と同様である。
ステップ６１８は、検証装置１２０が受け取ったハイパーバイザ３１６およびドライバシム３１４の測定値が、検証装置１２０内に記憶される対応するポリシに一致するかどうかについての、人間が知覚できる指示を提供することを含む。他の実施形態では、このステップは、ハイパーバイザ３１６およびドライバシム３１４のそれぞれの状態についての人間が知覚できる指示を提供することでもよく、またはそのような指示を提供することも含む。

ステップ６２０は、信頼性のある実行ファイル３１２を実行する確認を示す入力をユーザから受け取ることを含む。このステップにおける人間による確認は、検証装置１２０が受け取ったハイパーバイザ３１６およびドライバシム３１４の測定値が検証装置１２０内に記憶されるポリシに一致すると判定された後、信頼性のある実行ファイル３１２を実行する確認である。あるいは、このステップにおける人間による確認は、検証装置１２０が受け取ったハイパーバイザ３１６およびドライバシム３１４の測定値が検証装置１２０内に記憶されるポリシに一致しないが、潜在的な問題にもかかわらず、ユーザが信頼性のある実行ファイル３１２を依然として実行したい状況をオーバーライドする確認とすることができる。一部の実施形態では、このステップは省略してもよい。例えば本発明は、検証装置１２０が受け取ったハイパーバイザ３１６およびドライバシム３１４のアイデンティティの測定値が検証装置１２０内に記憶されるポリシに一致する場合など、特定の状況においてユーザからの入力を必要としない場合がある。別の実施形態では、たとえハイパーバイザ３１６およびドライバシム３１４が損なわれているように思われても、本発明は、信頼性のある実行ファイル３１２を実行する前に警告を出すが、ユーザ入力を必要としない場合がある。

ステップ６２２は、信頼性のある実行ファイル３１２を実行するかどうかを示す信号をプロセッサ１１２に送ることを含む。信頼性のある実行ファイル３１２を実行するための信号は、検証装置１２０が受け取ったハイパーバイザ３１６およびドライバシム３１４の測定値が検証装置１２０内に記憶されるポリシに一致するかどうかに基づく。あるいは、信頼性のある実行ファイル３１２を実行するための信号は、ステップ６２０におけるユーザからの確認に基づくことができる。

ステップ５１２、５１４、５１６、５１８、５２０、５２２、５２４、６１０、６１２、６１４、および６１６は、信頼性のある実行ファイル３１２を実行する要求を示す信号を受け取るステップ５１０の後に実行される。信頼性のある実行ファイル３１２が測定後かつ実行前に損なわれる状況（検査時−使用時の脆弱性：ｔｉｍｅ−ｏｆ−ｃｈｅｃｋ，ｔｉｍｅ−ｏｆ−ｕｓｅ ｖｕｌｎｅｒａｂｉｌｉｔｙ）を避けるために、信頼性のある実行ファイル３１２の最近の測定値が望ましい。これらのステップはさらに、コンピュータ１１０をリブートすることなしに実行される。コンピュータ１１０をリブートすることは時間がかかり、ユーザが待たなければならない時間を減らすことが望ましいので、このことは重要である。ただし、コンピュータ１１０をリブートする実施形態など、本発明は様々な実施形態で使用することができる。

各ステップの順序は、本明細書に示す順序と全く同じである必要はない。例えば、ステップ６１０および６１２は、ステップ６１４および６１６の前に実行するように記載したが、他の実施形態ではステップ６１０および６１２を、ステップ６１４および６１６の後に実行してもよい。図５および図６に記載のプロセスに関し、他の改変形態もあり得る。

図７は、ユーザインターフェイス１５０と信頼性のある実行ファイル３１２との間に信頼性のあるパス１５２を確立するための本発明の方法の一実施形態を示し、信頼性のあるパス１５２は、ハイパーバイザ３１６およびドライバシム３１４を含む。

ステップ７１０は、ハイパーバイザ３１６のアイデンティティを測定することを含む。このステップは、ハイパーバイザ３１６のアイデンティティの測定値を証明することを含むことができる。さらに、ハイパーバイザ３１６のアイデンティティの測定値を証明することは、ソフトウェアベースの証明を含むことができる。

ステップ７１２は、ハイパーバイザ３１６のアイデンティティの測定値を、ハイパーバイザ用のポリシと比較することを含む。
ステップ７１４は、ドライバシム３１４のアイデンティティを測定することを含む。このステップは、ドライバシム３１４のアイデンティティの測定値を証明することを含むことができる。さらに、ドライバシム３１４のアイデンティティの測定値を証明することは、ソフトウェアベースの証明を含むことができる。

ステップ７１６は、ドライバシム３１４のアイデンティティの測定値を、ドライバシム３１４用のポリシと比較することを含む。
ステップ７１８は、ユーザインターフェイス１５０のアイデンティティを測定することを含む。このステップは、ユーザインターフェイス１５０のアイデンティティの測定値を証明することを含むことができる。さらに、ユーザインターフェイス１５０のアイデンティティの測定値を証明することは、ソフトウェアベースの証明を含むことができる。

ステップ７２０は、ユーザインターフェイス１５０のアイデンティティの測定値を、ユーザインターフェイス用のポリシと比較することを含む。
ステップ７２２は、ハイパーバイザ３１６のアイデンティティ、ドライバシム３１４のアイデンティティ、およびユーザインターフェイス１５０のアイデンティティが、ハイパーバイザ３１６用のポリシ、ドライバシム３１４用のポリシ、およびユーザインターフェイス１５０用のポリシにそれぞれ一致するかどうかについての、人間が知覚できる指示を提供することを含む。

ステップ７２２は、人間が知覚できる単一の指示を提供することを含むか、または人間が知覚できる複数の指示を提供することを含む。一実施形態では、ステップ７２２は、ハイパーバイザ３１６のアイデンティティ、ドライバシム３１４のアイデンティティ、およびユーザインターフェイス１５０のアイデンティティのすべてが、ハイパーバイザ３１６用のポリシ、ドライバシム３１４用のポリシ、およびユーザインターフェイス１５０用のポリシにそれぞれ一致する場合に人間が知覚できる第１の指示を提供すること、ハイパーバイザ３１６のアイデンティティ、ドライバシム３１４のアイデンティティ、およびユーザインターフェイス１５０のアイデンティティのうちの少なくとも１つが、ハイパーバイザ３１６用のポリシ、ドライバシム３１４用のポリシ、およびユーザインターフェイス１５０用のポリシそれぞれに一致しない場合に人間が知覚できる第２の指示を提供することを含み、人間が知覚できる第１の指示は、人間が知覚できる第２の指示とは異なる。

ステップ７２４は、信頼性のある実行ファイル３１２を実行することを含む。
本発明では他の多くの改変形態もあり得る。例えば一実施形態では、ハイパーバイザ３１６用のポリシおよびドライバシム３１４用のポリシが、ユーザインターフェイス１５０と信頼性のある実行ファイル３１２との間の信頼性のあるパス１５２の一部ではないコンポーネント内に記憶される。

別の実施形態では、ハイパーバイザ３１６およびドライバシム３１４がコンピュータ１１０によって実装され、ハイパーバイザ３１６用のポリシおよびドライバシム３１４用のポリシは、ハイパーバイザ３１６およびドライバシム３１４が実装されるコンピュータ１１０から離れた装置内に記憶される。

別の実施形態では、ユーザインターフェイス１５０用のポリシがドライバシム３１４内に記憶される。
図８は、図７のステップ７２０と７２２との間で追加のステップが実行される、本発明の別の実施形態を示す。

ステップ８１０は、信頼性のある実行ファイル３１２のアイデンティティを測定することを含む。このステップでは、改変形態があり得る。
ステップ８１２は、信頼性のある実行ファイル３１２のアイデンティティの測定値を、信頼性のある実行ファイル３１２用のポリシと比較することを含む。

本発明では改変形態があり得る。具体的には、各方法を実行する順序を修正することができる。例えば、上記で述べたように、ステップ７１４（ドライバシムのアイデンティティを測定すること）およびステップ７１６（ドライバシムのアイデンティティの測定値を比較すること）は、ステップ７１０（ハイパーバイザのアイデンティティを測定すること）の後で、およびステップ７１２（ハイパーバイザのアイデンティティの測定値を比較すること）の後に実行することができる。また、図８に関し、ステップ８１０（信頼性のある実行ファイルのアイデンティティを測定すること）およびステップ８１２（信頼性のある実行ファイルのアイデンティティの測定値を比較すること）は、ステップ７１４（ドライバシムのアイデンティティを測定すること）の後で、およびステップ７１６（ドライバシムのアイデンティティの測定値を比較すること）の後に実行することができる。他の改変形態もあり得る。

図９は、図７のステップ７２０と７２２との間で追加のステップが実行される、本発明の別の実施形態を示す。
ステップ９１０は、ユーザインターフェイス１５０とハイパーバイザ３１６との間の信頼性のあるパス１５２内の追加コンポーネントのアイデンティティを測定することを含む。ユーザインターフェイス１５０とハイパーバイザ３１６との間の追加コンポーネントは、例えばメモリコントローラハブ、入出力コントローラハブ、グラフィックスコントローラ、ＵＳＢコントローラ、専用キーボードコントローラ、またはユーザインターフェイス１５０とハイパーバイザ３１６との間で使用されるバス（例えばＰＣＩｅバス）である。

ステップ９１２は、ユーザインターフェイス１５０とハイパーバイザ３１６との間の信頼性のあるパス１５２内の追加コンポーネントのアイデンティティの測定値を、そのコンポーネント用のポリシと比較することを含む。追加コンポーネント用のポリシは、例えばユーザインターフェイス１５０と信頼性のある実行ファイル３１２との間の信頼性のあるパス１５２の一部ではないコンポーネント内に記憶する。例えば、追加コンポーネントはコンピュータ１１０によって実装され、追加コンポーネント用のポリシは、追加コンポーネントが実装されるコンピュータ１１０から離れた装置内に記憶される。

他の改変形態および修正形態もあり得る。
図１０は、ステップ７２２が、人間が知覚できる第１の指示および第２の指示の両方を提供することを含む、本発明の別の実施形態を示す。この実施形態では、人間が知覚できる第２の指示を提供した後に、およびハイパーバイザのアイデンティティ、ドライバシムのアイデンティティ、およびユーザインターフェイスのアイデンティティのうちの少なくとも１つが、ハイパーバイザ用のポリシ、ドライバシム用のポリシ、およびユーザインターフェイス用のポリシそれぞれに一致しない場合、ステップ１０１０が実行される。

ステップ１０１０は、ハイパーバイザ３１６、ドライバシム３１４、およびユーザインターフェイス１５０の少なくとも１つを既知の良好な状態に復元することを含む。
図１１は、ステップ７２２の後に追加のステップが実行される本発明の別の実施形態を示す。

ステップ１１１０は、ハイパーバイザ３１６のアイデンティティが、ハイパーバイザ３１６用のポリシに一致すると判定することを含む。
ステップ１１１２は、ドライバシム３１４のアイデンティティが、ドライバシム３１４用のポリシに一致するかどうかを判定することを含む。このステップは、ハイパーバイザ３１６のアイデンティティが、ハイパーバイザ３１６用のポリシに一致すると判定した後に実行される。

ステップ１１１４は、ドライバシム３１４のアイデンティティが、ドライバシム３１４用のポリシに一致しない場合にドライバシム３１４を既知の良好な状態に復元することを含む。

ステップ１１１６は、ユーザインターフェイス１５０のアイデンティティが、ユーザインターフェイス１５０用のポリシに一致するかどうかを判定することを含む。このステップは、ドライバシム３１４のアイデンティティが、ドライバシム３１４用のポリシに一致しない場合にドライバシム３１４を既知の良好な状態に復元した後に実行される。

ステップ１１１８は、ユーザインターフェイス１５０のアイデンティティが、ユーザインターフェイス１５０用のポリシに一致しない場合にユーザインターフェイス１５０を既知の良好な状態に復元することを含む。

これらのステップは、好ましくは厳密な順序で実行される。具体的には、ドライバシム３１４はユーザインターフェイス１５０の前に検証される。ドライバシム３１４が不良の場合、ユーザインターフェイス１５０も不良とみなされる。ドライバシム３１４は、ユーザインターフェイス１５０より前に直される。別の言い方をすれば、本発明の一実施形態によれば、ドライバシム３１４のアイデンティティがドライバシム３１４用のポリシに一致しない場合、ユーザインターフェイス１５０のアイデンティティは、ユーザインターフェイス１５０用のポリシに一致しないと想定される。

図１２は、本発明の別の実施形態を示す。この実施形態は、ステップ１０１０の後に追加のステップを含む。
ステップ１２１０は、既知の良好な状態に復元したハイパーバイザ３１６、ドライバシム３１４、およびユーザインターフェイス１５０のうちの少なくとも１つのアイデンティティを測定することを含む。

ステップ１２１２は、既知の良好な状態に復元したハイパーバイザ３１６、ドライバシム３１４、およびユーザインターフェイス１５０のうちの少なくとも１つのアイデンティティの測定値を、ハイパーバイザ３１６、ドライバシム３１４、およびユーザインターフェイス１５０のうちの少なくとも１つのための対応するポリシと比較することを含む。

図１３は、本発明の別の実施形態を示す。この実施形態は、ステップ７１２の後に追加のステップを含む。
ステップ１３１０は、ハイパーバイザ３１６のアイデンティティが、ハイパーバイザ３１６用のポリシに一致すると判定することを含む。

ステップ１３１２は、ＴＰＭ装置が損なわれていると判定することを含む。
ステップ１３１４は、ＴＰＭ装置を既知の良好な状態に戻すことを含む。このステップは、例えば既知の良好な状態に戻るようにＴＰＭ装置に指示する適切な命令をＴＰＭ装置に送るハイパーバイザ３１６によって実施される。

ステップ１３１６は、ＴＰＭ装置内の既存の鍵を破壊することを含む。このステップは、例えばＴＰＭ装置に適切な命令を送るハイパーバイザ３１６によって実施される。
ステップ１３１８は、ＴＰＭ装置内の新たな鍵を作成することを含む。このステップは、例えばＴＰＭ装置に適切な命令を送るハイパーバイザ３１６によって実施される。

図１４は、信頼性のあるパス１５２が信頼性のあるシェル（shell）を含む、本発明の別の実施形態を示す。
ステップ１４１０は、信頼性のあるシェルのアイデンティティを測定することを含む。

ステップ１４１２は、信頼性のあるシェルのアイデンティティの測定値を、信頼性のあるシェル用のポリシと比較することを含む。信頼性のあるシェル用のポリシは、信頼性のあるパス１５２の外部に記憶することができる。例えば、信頼性のあるシェルはコンピュータ１１０によって実装され、信頼性のあるシェル用のポリシは、信頼性のあるシェルが実装されるコンピュータ１１０から離れた装置内に記憶される。

図１５は、ステップ７２４の後に追加のステップが実行される本発明の別の実施形態を示す。
ステップ１５１０は、信頼性のある実行ファイル３１２の実行を一時停止することを含む。

ステップ１５１２は、信頼性のある実行ファイル３１２が一時停止されたという、人間が知覚できる指示を提供することを含む。
図１６は、ステップ７２２と７２４との間で追加のステップが実行される、本発明の別の実施形態を示す。

ステップ１６１０は、信頼性のある実行ファイル３１２を実行する確認を示す入力を人間のユーザから受け取ることを含む。
１例示的実施形態
１．１ 概要
次に本発明をいくつかの特定の実施形態に関して説明する。これらの実施形態は本発明の例証だが、本発明は本明細書に示し説明する特定の実施形態に限定されることはない。
１．２ アーキテクチャ概要
この節は、本発明のアーキテクチャの一実施形態（図１７参照）の概要を含む。使用可能なシステムを構築することが重要な目標なので、安全な環境を築くためにユーザが行わなければならないステップ、ユーザエクスペリエンスを最初に説明する。次いで、安全な環境を確立するためにシステムが行うステップを列挙する、システムコンポーネントおよびシステム動作を示す。次の節では、技術的手法についての詳細を示す。

ユーザエクスペリエンス。ユーザの観点から、入出力用の信頼性のあるパスを有する安全な環境を確立することは以下のように進められる。（例えばＵＳＢインターフェイスを介してＰＣに接続し、ＵＳＢメモリスティックと同じくらいの大きさである）信頼性のある検証装置１２０上のボタンを押すことにより、ユーザは、標準的なキーボード１１６からの入力用の信頼性のあるパス１５２と、標準的なディスプレイ１１８上への出力用の信頼性のあるパスとを提供する安全な環境を立ち上げる。安全な環境が成功裏に確立される場合（確立されたかどうかは信頼性のある検証器１２０が検査することができる）、ユーザは、例えば装置１２０上で点灯する緑色のＬＥＤと、ブザーが発する短い「ＯＫ」ビープ音とを使って知らされる。安全な環境を確立することをマルウェアが妨げる場合、信頼性のある検証器１２０がそれを検知し、例えば装置１２０上に赤色のＬＥＤを点灯させ、アラームを鳴らし、キーボード１１６にいかなる秘密も入力しないよう、およびディスプレイ１１８上に表示されるいかなる内容も信頼しないようにユーザに注意を喚起する。

システムコンポーネント。図１７に示すアーキテクチャの主要なコンポーネントには、（上記では検証装置と呼んだ）信頼性のある検証器１２０、（上記ではハイパーバイザと呼んだ）トラストバイザ（ＴｒｕｓｔＶｉｓｏｒ）３１６、および信頼性のあるアプリケーションが含まれる。

信頼性のある検証器１２０。標準的なＰＣ（コンピュータ１１０を「ＰＣ」と呼ぶこともある）上にマルウェアがある状態でユーザが検証可能な信頼性のあるパスを実現するために、最初の信頼性のあるエンティティが必要である。このために、信頼性のある検証器と呼ぶ、ユーザが持ち運べる最小限の追加装置を提案する。信頼性のある検証器は、ＵＳＢインターフェイスを介してＰＣに接続し、多色ＬＥＤ、ブザー、ボタンなどの最小限のユーザＩ／Ｏ機能を有する、ＵＳＢメモリスティックと同様の小さな装置である。信頼性のある検証器は、ＰＣ環境の検証中に暗号操作を行うのに十分な最小限の計算能力を提供する。

トラストバイザ３１６。トラストバイザは、レガシＯＳを実行するためのハイパーバイザ機能を実装するとともに、レガシＯＳ内の信頼できないコンポーネントと強く隔離した状態で独立型アプリケーションを実行する能力を提供する、システムのコアコンポーネントである。トラストバイザは、キーボード１１６から信頼性のあるアプリケーション３１２への、および信頼性のあるアプリケーション３１２からディスプレイ１１８への入出力用の信頼性のあるパスも提供する。トラストバイザは、信頼性のある検証器１２０がトラストバイザ３１６の動作の正しさを検査することを可能にする検証関数をさらに備える。

信頼性のあるアプリケーション。信頼性のあるアプリケーションは、ドライバシム３１４と、レガシＯＳ１７１２空間内の任意のマルウェアからトラストバイザ３１６によって保護される隔離された実行環境内で実行ファイル３１２を実行するための信頼性のあるシェル１７１０とからなる（１．３．３節はこれらのコンポーネントについてより多くの詳細を示す）。図１７が示すように、トラストバイザ３１６は、ドライバシム３１４内のドライバを介し、信頼性のあるアプリケーション空間に信頼性のあるＩ／Ｏを提供する。一実施形態において、（図１７内のＥで示す）２つの信頼性のある実行ファイル３１２を構築することを計画する。第１の信頼性のある実行ファイルは、信頼性のあるパス１５２を活用して安全なディスク暗号化をサポートする一方で、第２の信頼性のある実行ファイルは、信頼性のある方法でＴＰＭチップ上の保証鍵を鍵更新するための機構を提供する。１．４節により多くの詳細を示す。

システム動作。本発明はシステムの観点から言及することがあり、そのシステムは通常、一体化されていてもされていなくてもよいコンピュータ１１０および検証装置１２０を意味する。システムの動作を説明するために、１つのあり得るシステムの具体例のライフサイクルをここで示す。検討するシナリオは、ユーザが信頼性のある検証器１２０装置上のボタンを押すと、アプリケーションとしての信頼性のあるシェル１７１０と信頼性のある環境を確立するようにシステムが設定されるシナリオである。

この例では、ＰＣのブートプロセスが最初にトラストバイザ３１６をロードするように設定されており、そのトラストバイザ３１６が、レガシＯＳ１７１２をロードして実行すると想定する。ユーザの観点から、システムはこの段階ではレガシシステムの区分がつかない。ここでユーザは、自らの信頼性のある検証器１２０装置をＰＣのＵＳＢインターフェイスに接続する。信頼性のあるシェル１７１０を立ち上げるために、そのユーザは信頼性のある検証器１２０上のボタンを押す。信頼性のある検証器１２０装置は、トラストバイザ３１６のコードおよび実行完全性を最初に検証し、すなわちマルウェアまたは悪意ある内部者によってことによると修正されたバージョンではなく、予期されたトラストバイザ３１６のコードが実行されていることを確認する。このために、信頼性のある検証器１２０およびトラストバイザ３１６は、１．３．４節でより詳細に説明するソフトウェアベースの証明プロトコルに関与する。他の証明プロトコルもあり得る。ハードウェアベースの証明プロトコルも使用することができる。検証が成功する場合、信頼性のある検証器１２０は緑色のＬＥＤを点灯させ、「成功」ビープ音を鳴らし、さもなければ赤色のＬＥＤを点灯させてアラームを鳴らす。

入出力用の信頼性のあるパス１５２を確立するために、トラストバイザ３１６は、キーボードコントローラおよびディスプレイコントローラから、信頼性のあるパス１５２を妨げる可能性がある任意の潜在的に有害な構成またはコード残余（ｃｏｄｅ ｒｅｓｉｄｕｅ）を除去する必要がある。例えば、キーボードはキーリマッピングを含む可能性があり、またはディスプレイは、信頼性のあるシェル１７１０が可視領域の外側に書くような解像度で構成されている可能性がある。したがって、トラストバイザ３１６は、キーボード１１６およびディスプレイ１１８に関連するすべての状態およびコードをリセットする。次いでトラストバイザ３１６は、信頼性のあるシェル１７１０をロードし、信頼性のあるシェル１７１０のハッシュを既知の良好な値と比較することによってコードの完全性を検証し、信頼性のあるシェル１７１０を実行し始める。

システムが損なわれている場合、トラストバイザ３１６自体では侵入を検知し、実行を阻止することはできないことに留意されたい。このことを説明するために、信頼性のあるパス１５２を改竄するようにハードディスク上のトラストバイザのコードを変更した悪意ある内部者を考察されたい。ただしこの場合、信頼性のある検証器１２０は変更を検知し、アラームを鳴らす。したがってユーザは、機密情報の入力を控えるように注意を喚起される。
１．３ 技術的手法の詳細
１．２節で論じたように、本発明のこの実施形態は３つの主要なコンポーネント、つまり信頼性のある検証器装置１２０、トラストバイザ３１６と呼ばれる安全なハイパーバイザ、およびソフトウェアベースの証明コンポーネントを含む。次に各コンポーネントについて順に論じる。図１７は、システムの高レベル全体像を示す。
１．３．１ 信頼性のある検証器装置
信頼性のある検証器１２０装置は、ユーザのための信頼のルートを形成する。信頼性のある検証器１２０は、ユーザがその正しい動作を信頼性のあるものである。より詳細には、一実施形態によれば、信頼性のある検証器３１６装置の要件は以下の通りである。

正しい動作：信頼性のある検証器３１６上で実行されているソフトウェアが、危険にさらされることに対して非常に高いロバスト性を提供することを確実にする必要がある。信頼性のある検証器３１６上で実行されるすべてのソフトウェアを形式的に検証することを計画する（１．４．３節参照）。

最小入力機能：装置１２０は、信頼性のある環境を立ち上げるためにユーザが使用可能な少なくとも１つのボタンを有する。
最小出力機能：この装置は、様々な状態を示すための出力能力を有するべきである。例えば、オレンジ色のライトは信頼性のある環境が実行されていないことを示し、緑色のライトは信頼性のある環境が正しく実行されていることを示し、アラームビープ音を伴う赤色のライトは信頼性のある環境が正しく実行されていないか、またはセットアップに失敗したことを示す。

信頼性のある検証器装置３１６は、３つのＬＥＤ（オレンジ、緑、および赤）、１つのブザー、および１つのボタンを含む。ＬＥＤはシステムの検証状態を示し、ブザーは聴覚上のフィードバックを与え（検証に失敗する場合アラームが鳴る）、ボタンは検証プロセスを開始するために使用される。ハードウェアプラットフォームとして、ＵＳＢ周辺機器を開発するための人気のあるソリューションであるＬＰＣ２１４８開発ボードを使用することができる。信頼性のある検証器１２０は、ＬＰＣ２１４ｘマイクロコントローラのビルトインＵＳＢデバイスに関するハードウェアインターフェイスおよびＵＳＢエニュメレーション／構成を処理するＵＳＢコアスタックである、ＬＰＣ２１４ｘＵＳＢスタックに基づくことができる。

図１７が示すように、信頼性のある検証器装置３１６はＵＳＢリンクを介してＰＣと通信する。一実施形態では本発明は、トラストバイザ３１６と一体化される小さな独立型ＵＳＢホストコントローラデバイスドライバを含む。このことは、本発明が、信頼性のある検証器１２０と通信するためにＯＳ１７１２を信頼しないようにすることを可能にする。

図１８は、信頼性のある検証器１２０の状態機械を示す。信頼性のある検証器１２０が最初にＰＣにプラグで接続されると、信頼性のある検証器１２０は初期状態に留まり、オレンジ色のＬＥＤを点灯させる。トラストバイザ３１６は、信頼性のある検証器１２０からの任意のコマンドがないかどうかＵＳＢインターフェイス１４０を周期的に問い合わせる（query）。ユーザが信頼性のある検証器１２０上のボタンを押すと、信頼性のある検証器１２０は証明開始コマンドをトラストバイザ３１６に送る。トラストバイザ３１６はそのコマンドを取得し、信頼性のある検証器１２０にチャレンジを要求する。受け取ったチャレンジに基づき、トラストバイザ３１６は検証関数を呼び出してチャレンジについてのチェックサム値を計算し、その値を信頼性のある検証器１２０に返す。１．３．４節は、ソフトウェアベースの証明関数についてより詳細に説明する。トラストバイザ３１６が誤ったチェックサム値を返すか、または正しい値をあまりにも遅く返す場合、信頼性のある検証器１２０は何らかのマルウェアが存在する可能性があるとみなし、アラームを発し、赤色のＬＥＤをつけることによってユーザの注意を喚起しなければならない。さもなければ、検証関数がトラストバイザ３１６のハッシュ値を計算し、そのハッシュ値を信頼性のある検証器１２０に送る。ハッシュ値が正しくない場合、信頼性のある検証器１２０はユーザの注意を喚起する。さもなければ、トラストバイザ３１６が正しいことを意味する緑色のＬＥＤが点灯し、それによりユーザは、トラストバイザ３１６によって開始される信頼性のあるアプリケーションを今度は信頼することができる。信頼性のあるアプリケーションが終了した後、トラストバイザ３１６は信頼性のある検証器１２０に通知し、信頼性のある検証器１２０はその初期状態に戻る。

図１９は、トラストバイザ３１６と信頼性のある検証器１２０との間の通信のより詳細なプロトコル図を示す。このやり取りの単純さに基づき、両方のコンポーネント上のコードがセキュリティ上の弱点を一切含まないことを完全に検証する。

不都合なことに、検査時−使用時（ＴＯＣＴＴＯＵ）の脆弱性を防ぐ必要がある。検証が成功する場合、信頼性のある検証器１２０はユーザに成功の信号を供給し、ユーザはそのとき入出力用の信頼性のあるパス１５２を想定する。しかし、ユーザが一瞬気をそらし、ユーザが気付くことなしにマシンがどういうわけか素早くリブートされる場合、今では悪意あるアプリケーションがディスプレイ上に予期される画面を提示する。当然ながら、信頼性のある検証器１２０上の緑色のライトがオンであることはないが、ユーザが確認しない可能性はある。この明らかに人為的な脆弱性を回避するために、信頼性のある検証器１２０の装置がリセットし、またはリブートされるときを知らせるためのビープ音を追加する。ＰＣがリセットする場合は取り付けられるすべてのＵＳＢデバイスがリセットされるので、ビープ音がおそらくユーザの注意を喚起する。
１．３．２ トラストバイザ：
信頼性のあるセキュリティハイパーバイザであるトラストバイザ３１６、信頼性のあるハイパーバイザは、以下の要件および特性を有することができる。

１．システムのＴＣＢを形成するＣＰＵ１１２およびメモリコントローラだけに依拠しながら、システムの残りの部分から隔離して実行されること。
２．システム上にあり得る任意のマルウェアから、信頼性のあるアプリケーション３１２のコードを（ＯＳ１７１２からの支援なしに）強く隔離すること。

３．完全に隔離された様式で正しいコードを実行していることを、信頼性のある検証器１２０に立証（証明）すること。
４．自らのセキュリティ特性を（数学的な意味で）証明するために、形式的な検証を受け入れること。

５．既存のシステムに容易に統合すべきこと。すなわちトラストバイザ３１６とともに動作するように、既存のシステムを移植する相当な労力を必要とすべきでないこと。
トラストバイザ３１６は、システム上の最高の特権レベルである仮想マシンモニタ（ＶＭＭ）の特権レベルで実行される。トラストバイザ３１６は、Ｉｎｔｅｌ（登録商標）およびＡＭＤ（登録商標）からの汎用ＣＰＵ内に含まれる、ＣＰＵによってサポートされる仮想化を使用して、システムの残りの部分から隔離されて実行される。ただし、他のＣＰＵアーキテクチャ上の仮想化サポートも、トラストバイザをそれらのアーキテクチャに移植できるようにすることができる。トラストバイザは、ｘ８６アーキテクチャに固有のものではない。ＣＰＵ１１２およびメモリコントローラは、そのような隔離をもたらすためのハードウェア保護機構を提供する。

ＯＳ１７１２よりも高い特権レベルで実行されることにより、トラストバイザ３１６は、ＯＳ１７１２とは独立に、信頼性のあるアプリケーションを強く隔離することができる。トラストバイザ３１６は、信頼性のあるアプリケーションを、カーネルルートキットなどのあらゆるＯＳレベルのマルウェア、ならびにアプリケーションレベルのマルウェアから隔離することができる。さらに、トラストバイザ３１６は、マルウェアがＶＭＭの特権レベルで実行されることを防ぐことができる。例えば、仮想マシンベースのルートキット（ＶＭＢＲ）Ｂｌｕｅ Ｐｉｌｌ［３１］またはＳｕｂ Ｖｉｒｔ［２６］は、ＶＭＭ特権を使って実行することにより検出を逃れる。

１．３．４節で説明するように、信頼性のある検証器１２０は、システムのソフトウェアベースの証明コンポーネントを使用して、トラストバイザ３１６が完全に隔離された様式で正しいコードを実行していることを検証する。トラストバイザ３１６は、本発明の発明者の一部によって開発された以前のセキュリティハイパーバイザであるＳｅｃＶｉｓｏｒに基づいて設計し、実装した［３３］。トラストバイザ３１６の詳細を示す前に、ＳｅｃＶｉｓｏｒの概要を示す。

ＳｅｃＶｉｓｏｒの概要。ＳｅｃＶｉｓｏｒは、商品ＯＳカーネルのコードの完全性を保証する極めて小さなハイパーバイザである［３３］。具体的には、ＳｅｃＶｉｓｏｒは、全システム寿命にわたり、ユーザが承認したコードしかカーネルモードで実行できないことを確実にする。このことは、カーネルルートキットなどのコード投入攻撃からカーネルを守る。ＳｅｃＶｉｓｏｒは、ＣＰＵ１１２、メモリコントローラ、およびシステムメモリチップ以外のすべてを制御する攻撃者に対してさえ、この特性を達成することができる。さらにＳｅｃＶｉｓｏｒは、ゼロデイカーネルエクスプロイトの知識を有する攻撃者に備えることさえも可能である。

ＳｅｃＶｉｓｏｒは、ユーザが承認したコードしかカーネルモードで実行できない特性を達成するために、ハードウェアメモリ保護に依拠する。ＳｅｃＶｉｓｏｒは、ソフトウェアメモリ仮想化技法およびハードウェアメモリ仮想化技法の両方を実装する。どちらの仮想化技法も、ＳｅｃＶｉｓｏｒがアドレス変換のためのページテーブルを設定することを要求する。また、これらのページテーブルは、ＳｅｃＶｉｓｏｒによって用いられて、メモリ上のハードウェア保護を設定する。

ＳｅｃＶｉｓｏｒの主な設計目標は、形式的な検証を受け入れられること、および商品ＯＳを移植する容易さである。ＳｅｃＶｉｓｏｒのソフトウェアおよびハードウェアのメモリ仮想化バージョンの実行時部分のコードサイズは、２０００行未満である。そのような小さなコードサイズは、ＳｅｃＶｉｓｏｒのコードが形式的な検証ツールを受け入れるようにする。さらに、ＳｅｃＶｉｓｏｒ上で実行するようにＬｉｎｕｘカーネルバージョン２．６．２０を移植することは最小限の変更しか必要とせず、カーネル内の約４３０万行のコードのうち、１００行未満のコードを変更する必要があった。

トラストバイザ３１６の設計。ＳｅｃＶｉｓｏｒが使用するハードウェアメモリ保護を修正して、信頼性のあるアプリケーションをシステムの残りの部分から隔離することであるトラストバイザ３１６の目標を達成することができる。トラストバイザ３１６に対して実装する重要なコンポーネントは、複数の実行ファイルを処理し、それらの実行ファイルを切り替える能力であり、具体的にはＯＳ１７１２が１つの実行ファイルであり、信頼性のあるアプリケーションがもう一方の実行ファイルである。

ＳｅｃＶｉｓｏｒのコードベースを再利用することは、トラストバイザ３１６がＳｅｃＶｉｓｏｒの望ましい特性を自動的に得ることを可能にする。このことは、トラストバイザ３１６を形式的に検証することを可能にし、トラストバイザ３１６を既存のシステムに統合することを簡単にするはずである。重要な目標は検証を受け入れるコードを作り出すことなので、トラストバイザ３１６を形式的に検証することは、トラストバイザ３１６の設計および実装形態に影響を及ぼす。

１．３．３ 信頼性のあるアプリケーション。信頼性のあるアプリケーションは、（実行ファイル３１２と呼ぶ）複数のプログラム、信頼性のあるシェル１７１０、およびドライバシム３１４からなる。信頼性のあるシェル１７１０は、実行ファイル３１２への単純な実行インターフェイスを提供する。図２０は、信頼性のあるアプリケーションのアーキテクチャを示す。実行ファイルを、それぞれが１つまたは多くてもいくつかのセキュリティ面での配慮を要する（ｓｅｃｕｒｉｔｙ ｓｅｎｓｉｔｉｖｅ）操作を実行する、小さな相対的に自己完結型のプログラムであるものとして視覚化する。１．４節に、２つの実行ファイル候補の例を示す。信頼性のあるアプリケーションは任意の数の実行ファイル３１２を含み、トラストバイザ３１６が信頼性のあるアプリケーションを呼び出すとき、それらのうちの１つまたは複数が実行される。

ドライバシム３１４は、キーボードドライバおよびディスプレイドライバを有する層を扱う装置である。信頼性のあるシェル１７１０は、実行ファイル３１２のための有限リソースマネージャの役割を担い、ユーザインターフェイスに対処する。信頼性のあるシェル１７１０は、余計なものを省いたＯＳカーネルと非常に単純なシェルとの組合せと考える。目標は、形式的な検証を行うためにコードが十分に小さく単純であるように、信頼性のあるシェル１７１０を設計することである。この目標を達成するために、信頼性のあるシェル１７１０のリソース管理機能を最小限に留める。活用するつもりである１つの技法は、セキュリティ上、重大ではない任意のリソース管理機能を信頼できないレガシＯＳ１７１２に実行させることである。したがって、信頼性のあるシェル１７１０は、セキュリティを危険にさらすことなくＯＳによって実行することができないリソース管理機能だけを実行する。以下では、ドライバシム３１４、信頼性のあるシェル１７１０、および実行ファイル３１２をより詳細に説明する。

ドライバシム３１４。ドライバシム３１４は、キーボードドライバおよびディスプレイドライバからなる。ディスプレイドライバはテキストモードしかサポートせず、したがって非常に小さく単純である。さらに、信頼性のあるシェル１７１０のメニュー方式の特性により、キーボードドライバは非常に限られた数のキー（矢印キー、エンターキー、および数字キー）しかサポートする必要がない。したがって、キーボードドライバも非常に小さく単純である。

ディスプレイドライバおよびキーボードドライバを信頼性のあるアプリケーション内に有する主な理由は、信頼性のあるアプリケーションが、ＯＳとは独立にキーボードおよびディスプレイを制御できるようにするためである。ユーザのあらゆるＩ／Ｏは隔離された区分によって処理されるので、このことは、ユーザと信頼性のあるアプリケーション内の任意の実行ファイルとの間に信頼性のあるパス１５２を築くことを可能にする。ドライバシム３１４をトラストバイザ３１６内に配置することもできるが、トラストバイザ３１６のコードサイズを最小限に留めるために、ドライバシム３１４をトラストバイザ３１６の外側に配置することにする。このことは、攻撃に対するトラストバイザ３１６の脆弱性を低減する。

キーボードとディスプレイは、ＯＳと信頼性のあるアプリケーションとの間で時分割されるので、ＯＳが中断されるときに、ＯＳがこれらの装置の制御を放棄する方法が必要である。同様に、信頼性のあるアプリケーションも、ＯＳに制御を戻す前にキーボードおよびディスプレイの制御を放棄すべきである。さもなければ、これらの装置が不安定な状態に移行し、システムをロックアップし得る可能性が非常に高い。

ＯＳが中断される前にキーボードコントローラおよびディスプレイコントローラをリセットする、ＯＳのための信頼性のあるアプリケーションのインターフェイスモジュールを構築することを提案する。このインターフェイスモジュールは、システムがロックアップするリスクなしに、信頼性のあるアプリケーションがこれらの装置を使用することを可能にする。さらに、このインターフェイスモジュールが装置を正しく再初期化し損なう場合、トラストバイザ３１６およびドライバシム３１４がそのことを検知し、ＴＰの確立を拒否することができる。同様に、ＯＳに制御を譲る前に、ドライバシム３１４もキーボードコントローラおよびディスプレイコントローラをリセットする。

信頼性のあるシェル１７１０。信頼性のあるシェル１７１０は、実行ファイル３１２のための有限リソースマネージャの役割を担い、ユーザインターフェイスに対処する。ユーザインターフェイスハンドラとしての役割では、信頼性のあるシェル１７１０は、様々な実行ファイル３１２を呼び出すためのメニュー方式のインターフェイスをユーザに提供する。リソースマネージャとしての役割では、信頼性のあるシェル１７１０は、簡単なスケジューラ、メモリ管理機能、およびプログラムロード機能を提供する。信頼性のあるシェル１７１０は、簡単なシステムコールインターフェイスを有して、実行ファイル３１２が信頼性のあるシェル１７１０と対話することを可能にする。次に、信頼性のあるシェル１７１０の様々なコンポーネントについてより詳細に説明し、それらのコンポーネントの複雑さを評価する。

信頼性のあるシェル１７１０が提供するメニューインターフェイスは、非常に単純である。そのメニューインターフェイスは、実行可能な実行ファイルのリストを表示する。ユーザは、例えば矢印キーまたは数字キーを使用して１つもしくは複数の所望の実行ファイルを選択し、エンターキーを押すことによりそれらの実行ファイルを呼び出すことができる。当然ながら、本発明はこれらの例の中で示す特定のキーの組合せまたは同様の詳細に限定されない。

本発明の一実施形態では、信頼性のあるシェル１７１０のスケジューラは、ユーザが選択したすべての実行ファイルを順に実行する簡単なラウンドロビンスケジューラである。コンテキストスイッチは、現在実行している実行ファイルがシステムコールを使用して信頼性のあるシェル１７１０を呼び出すことにより、ＣＰＵ１１２の制御を明確に発生させる（ｙｉｅｌｄ）協同マルチタスキングを使用して生じる。このスケジューラは、極めて単純で小さいことを予期する。他の改変形態もあり得る。

メモリマネージャは、実行ファイルをロードするためのマルチページリクエストから、動的メモリ割当てルーチンによって行われるより小さなリクエストに及ぶ様々なサイズのメモリ割当てに対処することを担う。メモリマネージャは、実行ファイルを互いに隔離することも担う。実行ファイルが比較的単純なので、このメモリマネージャはＯＳのメモリマネージャほど複雑である必要はないと考える。

信頼性のあるシェル１７１０内のプログラムローダは、ＥＬＦ（Ｅｘｅｃｕｔａｂｌｅ ａｎｄ Ｌｉｎｋａｂｌｅ Ｆｏｒｍａｔ）のバイナリイメージを再配置することができる。ＥＬＦ標準は、いくつかの普及しているＵＮＩＸ（登録商標）ディストリビューションおよびＬｉｎｕｘ（登録商標）を含む改変形態の中に存在するバイナリによって使用される。ＥＬＦプログラムローダは、実行ファイルにメモリを割り当て、それらの実行ファイルが割り当てられたメモリ位置から実行することができるように、実行ファイルディスクイメージを再配置することを担う。プログラムローダのメモリマネージャは、実行ファイルイメージにしかメモリを割り当てず、他の動的メモリ割当てはサポートしないので非常に単純であり得ることに留意されたい。また、再配置コードは約１００行のＣコードからなり、非常に小さく単純である。

プログラムローダを単純化する重要な設計上の決定は、ＯＳが実行ファイルのバイナリをディスクからロードできるようにすることである。ただし、他の設計もあり得ることに留意されたい。この設計は、プログラムローダの中にファイルシステムおよびディスクドライバを有する必要性をなくす。しかしこの設計では、実行ファイルイメージが信頼できないＯＳによってロードされるので、実行ファイルイメージの完全性を検証する方法が要求される。実行ファイルコードの完全性を検証するために使用される一般的な技法は、信頼性のある検証器１２０に実行ファイルの暗号学的ハッシュを計算させ、既知の良好な値と突き合わせて結果を確認させることである。プログラムローダは、実行ファイルの既知の良好なハッシュを保持し、ＯＳによってロードされる実行ファイルディスクイメージのハッシュをそれらの値と突き合わせて比較することができる。

信頼性のあるシェル１７１０によって提供されるシステムコールインターフェイスは、キーボードおよびディスプレイを使用するためのＩ／Ｏシステムコール、実行ファイルとＯＳとの間でデータを転送するためのデータ転送システムコール、および実行ファイルがＣＰＵ１１２の制御を発生させることを可能にする発生システムコールからなる。Ｉ／Ｏシステムコールは、端末ライン制御機能からなり、ドライバシム３１４を利用してハードウェアにアクセスする。データ転送システムコールは、ＯＳと実行ファイルとの間でデータを送るために必要である。最後に、発生システムコールは、協同マルチタスキングに必要である。

実行ファイル。実行ファイルを、それぞれが１つまたは多くてもいくつかのセキュリティ面での配慮を要する操作を実行する、小さな相対的に自己完結型のプログラムであるものとして視覚化する。１．４節に、２つの実行ファイル候補の例を示す。信頼性のあるシェル１７１０によって提供されるシステムコールインターフェイスを使用して実行するために、実行ファイルを移植しなければならないと今は考えているが、信頼性のあるシェル１７１０を単純に保ちながら、未修正のプログラムを実行ファイルとして実行できるように、信頼性のあるシェル１７１０のシステムコールインターフェイスを設計可能かどうかについても検討する。

信頼性のあるアプリケーションは任意の数の実行ファイルを含み、トラストバイザ３１６が信頼性のあるアプリケーションを呼び出すとき、任意の数の実行ファイルのうちの１つまたは複数が実行される。実行ファイルとの間のコンテキストスイッチは、協同マルチタスキングを使用して生じる。現在実行している実行ファイルは、発生システムコールを呼び出すことによりＣＰＵ１１２の制御を発生させる。次いで信頼性のあるシェル１７１０は、実行するために別の実行ファイルをスケジュールする。

実行ファイルはセキュリティ面での配慮を要する操作を行うので、実行ファイルの一部はそのメモリ内に秘密を有する可能性が高い。実行ファイルの秘密が漏洩することを防ぐために、そのように秘密が残ることは、電源切断イベントおよび中断イベントを慎重に扱うことを必要とする。電源切断イベントも中断イベントも、イベントが完了する前に実行ファイルにそのメモリから秘密を消去させるべきである。さもなければ、攻撃者は次の電源投入時または再開時にその秘密をメモリから読み取ることができる。
１．３．４ ソフトウェアベースの証明および検証可能コード実行
この節では、トラストバイザ３１６が任意のマルウェアと隔離された中で正しく実行されている保証を、信頼性のある検証器１２０の装置が得ることを可能にするために使用されるシステムのコンポーネントについて説明する。この技術は相当新しいので、システムの設計および実装されたシステムへのポインタに関する多くの技術的詳細を提供する。次いで、このシステムをよりロバストにするために本発明によって実装することができる改変形態または改善形態を説明する。

外部から検証可能なコード実行のためのコンポーネントは、コンピューティング装置上のターゲット実行ファイルと呼ばれる任意のコード片の実行が、存在し得る任意のマルウェアによって改竄されていない保証を、外部エンティティ（検証器）が得ることを可能にする。ターゲット実行ファイルが自己完結型である、すなわち実行中に他の任意のコードを呼び出さず、ターゲット実行ファイルが任意のソフトウェア脆弱性を含まないと仮定し、外部から検証可能なコード実行は以下の２つの保証と等価である。

１．正しい呼出し：検証器は、正しいターゲット実行ファイルイメージがメモリにロードされ、実行するために呼び出される保証を得る。
２．改竄されていない実行：コンピューティング装置上に存在し得るどのマルウェアも、ターゲット実行ファイルの実行をいかなる方法によっても妨げることはできない。

外部から検証可能なコード実行のためのソフトウェアベースの技法、およびハードウェアベースの技法の両方が提案されている。どちらの種類の技法も、コンピューティング装置上の信頼のルートに依拠する。信頼のルートとは、外部から検証可能なコード実行を実施する役割を担う信頼性のある計算処理機構である。信頼のルートは、ターゲット実行ファイルの完全性測定を行い、コンピューティング装置上で実行されている他のすべてのソフトウェアからターゲット実行ファイルを隔離するために適切な保護を設定し、実行するためにターゲット実行ファイルを呼び出す。信頼のルートはさらに、完全性測定値を認証済みの通信チャネルを介して検証器に送る。ターゲット実行ファイルの完全性測定値の正しい値を知る検証器は、受け取った完全性測定値を使用して、実行するために正しいターゲット実行ファイルが呼び出されたかどうかを検証する。さらに、ターゲット実行ファイルの実行はコンピューティング装置上の他のすべてのソフトウェアから隔離されているので、検証器はターゲット実行ファイルが改竄されずに実行される保証を得る。

外部から検証可能なコード実行のための２つの広く利用できるハードウェアベースの手法、ＡＭＤによるＳＶＭ（Ｓｅｃｕｒｅ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）［２］技術およびＩｎｔｅｌによるＴＸＴ（Ｔｒｕｓｔｅｄ Ｅｘｅｃｕｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）［２３］では、信頼のルートはコンピューティング装置のハードウェアのサブセットからなる。提案するシステムでは、動作するために任意の秘密に依拠しないシステムを構築するためにソフトウェアベースの証明機構を活用する。秘密を一切必要としないことは、任意の秘密を保つ必要性をなくし、それにより多数の攻撃手段を除去するので極めて大きな利点である。ただし、ハードウェアによる信頼のルートを活用する本発明の改変形態もあり得る。

外部から検証可能なコード実行のためのソフトウェアベースの技法では、信頼のルートが動的に、すなわち要求に応じて確立される［３２］。パイオニア（Ｐｉｏｎｅｅｒ）では、コンピューティング装置は、自らの命令シーケンスについてチェックサムを計算する、検証関数と呼ばれる自己チェックサム関数を有する。検証関数は、その実行がコンピューティング装置上の他のすべてのソフトウェアから隔離される、自らのための隔離された実行環境も設定する。隔離された実行環境は、コンピューティング装置上のどのマルウェアも、検証関数の実行を妨げることはできないことを保証する。攻撃者が任意の方法で検証関数を修正し、または隔離された実行環境の作成を捏造する場合、検証関数によって計算されるチェックサムは誤ったものになる。修正した検証関数または不適当に作成した隔離された実行環境を有するにもかかわらず、攻撃者が正しいチェックサムを偽造しようと試みる場合、そのチェックサムを計算するのにかかる時間は顕著に増加する。したがって以下の２つの条件が該当する場合、検証器は、コンピューティング装置上の検証関数が修正されておらず、隔離された実行環境が正しく設定されている保証を得る。

１．コンピューティング装置によって返されるチェックサムが正しい。
２．そのチェックサムが、予期される時間内に返される。
これらの２つの条件が該当する場合、検証器は、検証関数の方式で動的に作成された信頼のルートがコンピューティング装置上に存在する保証を得る。

想定。ＣＰＵのモデル、ＣＰＵのクロック速度、およびメモリレイテンシを含むコンピューティング装置の正確なハードウェア構成を検証器が検出していると想定する。コンピューティング装置のＣＰＵ１１２がオーバークロックされていないことも想定する。

ターゲット実行ファイルが自己完結型である、すなわち実行中にコンピューティング装置上の他の任意のソフトウェアを呼び出さないことも想定する。さらにターゲット実行ファイルは、例外を作り出さずにかつすべての割込みをオフにした状態で、ＣＰＵ１１２の最も高い特権レベルで実行する。

攻撃者モデル。コンピューティング装置のソフトウェアを完全に支配する攻撃者を想定する。つまり、攻撃者はＯＳを含むあらゆるソフトウェアを改竄し、コンピューティング装置に悪意あるソフトウェアを恣意的に投入する。しかし、攻撃者がハードウェアを修正することはないと想定する。例えば、攻撃者は悪意あるファームウェアをネットワークカードやディスクコントローラなどの周辺装置上にロードし、またはＣＰＵ１１２をより速いＣＰＵに置換することはない。さらに、攻撃者は、検証関数またはターゲット実行ファイルを含むメモリ領域を良好な周辺装置に上書きさせるＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）書込みをスケジュールすることなど、ＤＭＡ攻撃を行うことはない。

検証可能コード実行概要。検証関数は、コンピューティング装置上に信頼のルートを動的にインスタンス化することを担う。図２１に示すように、検証関数は、チェックサムコード、送信関数、およびハッシュ関数の３つの部分からなる。チェックサムコードは検証関数の命令についてのチェックサムを計算し、検証関数を実行するための隔離された実行環境も設定する。チェックサムコードがチェックサムを計算し終えた後、チェックサムコードは、送信関数を呼び出して、通信チャネルを介してそのチェックサムを検証器に転送する。検証器にチェックサムを送り返した後、チェックサムコードはハッシュ関数を呼び出し、そのハッシュ関数は、実行ファイルイメージについてのハッシュを計算することによりターゲット実行ファイルの完全性測定値を計算する。ハッシュ関数は、送信関数を使用してターゲット実行ファイルのハッシュを検証器に返し、ターゲット実行ファイルを呼び出す。ターゲット実行ファイルは、チェックサムコードによって設定される隔離された実行環境内で実行されるハッシュ関数によって直接呼び出されるので、ターゲット実行ファイルは同じ隔離された実行環境を継承する。また、このターゲット実行ファイルは自己完結型である。したがって、コンピューティング装置上のどのマルウェアも、ターゲット実行ファイルの実行に影響を及ぼすことができないことが保証される。

隔離された実行環境は、検証関数およびターゲット実行ファイルの実行のアトミック性を実現する。つまり、コンピューティング装置上の他のどのコードも、検証関数およびターゲット実行ファイルが実行し終わるまで実行することを許可されない。このアトミック性は、あらゆるマスク可能割込みをオフにした状態で、検証関数およびターゲット実行ファイルがＣＰＵ１１２の最も高い特権レベルで実行されることを確実にすることにより達成される。さらにチェックサム計算プロセスの一部として、あらゆるマスク不可能割込みおよび例外のために、検証関数イメージの一部である新たなハンドラを導入する。ターゲット実行ファイルは自己完結型なので、検証関数またはターゲット実行ファイル内のコード以外のどのコードも、これら２つのエンティティのいずれかが実行している限り実行することはできない。

パイオニアは、検証器とコンピューティング装置との間のチャレンジ・レスポンスプロトコルに基づく。図２２にパイオニア・プロトコルを示す。検証器が、チャレンジとしてランダムノンス（random nonce）を送ることにより、コンピューティング装置上の検証関数を呼び出す。検証関数の中のチェックサムコードが、ランダムノンスに応じて、検証関数の命令シーケンスについてのチェックサムを計算する。ランダムノンスを使用することは、事前計算攻撃およびリプレイ攻撃を防ぐ。チェックサムコードは、送信関数を使用し、計算したチェックサムを検証器に送り返す。検証器は検証関数のコピーを有し、したがって独立にチェックサムを計算することができる。検証器は、コンピューティング装置が返すチェックサムの正当性、およびそのチェックサムが予期される時間内に返されることを確認する。これらの２つの条件が満たされる場合、検証器は、信頼のルートがコンピューティング装置上に正しくインスタンス化されている保証を得る。検証器にチェックサムを送り返した後、チェックサムコードはハッシュ関数を呼び出し、そのハッシュ関数は、検証器が送ったランダムノンスに連結するターゲット実行ファイルイメージのハッシュを計算する。次いでハッシュ関数は、ターゲット実行ファイルのハッシュを検証器に送り返す。検証器は、ターゲット実行ファイルイメージの自らのコピーを使用し、そのハッシュ値の正当性を検証する。コンピューティング装置が返すチェックサムを、検証器が以前成功裏に検証している場合、検証器はハッシュ関数が修正されておらず、隔離された実行環境内で実行されることを知ることに留意されたい。したがって検証器は、ハッシュ関数がターゲット実行ファイルイメージを正しくハッシュする保証を得る。最後に、ハッシュ関数が、実行するためにターゲット実行ファイルを呼び出す。

第２世代パイオニア・チェックサム関数。第１世代の関数よりも高度な攻撃者タイムオーバーヘッドを提供する第２世代のパイオニア・チェックサム関数を開発した［３２］。この高レベルの概念は、ＣＰＵの速度とメモリの速度との間の大きな差を活用することであり、つまり攻撃者のチェックサム関数がメモリにアクセスするように強制されるのに対し、正しいチェックサム関数はいかなるメモリアクセスも行わない。メモリにアクセスさせることは、攻撃者のチェックサム計算を遅らせる。ＣＰＵのレベル１、レベル２、および（妥当な場合）レベル３キャッシュを満たす、空間最適（ｓｐａｃｅ ｏｐｔｉｍａｌ）チェックサム関数を構築する。攻撃者のチェックサム関数はより大きいので、ＣＰＵのキャッシュ内には収まらず、その結果、攻撃者がメモリアクセスを実行することを強いる。

増やされた攻撃者オーバーヘッドを有することに加え、第２世代のチェックサム関数はさらに、プロテクトモードのセグメント化サポートを有する３２ビットｘ８６ＣＰＵ上で確実に動作し、あらゆる仮想メモリベースの攻撃に対処し、信頼できないＳＭＭ（システム管理モード）ハンドラに対応する。このチェックサム関数はリアルモードで実行され、それにより攻撃者がプロテクトモードのセグメント化を使用することを拒否する。リアルモードで動作することは、あらゆる仮想メモリベースの攻撃に対処することも可能にする。リアルモードではページングが使用可能にされていないので、これらの攻撃は起こり得ない。最後に、チェックサム関数レジスタはＳＭＭ内で実行され、ＳＭＭハンドラを信頼しなくて済むようにする。

これらの機能強化は、第２世代のチェックサム関数を第１世代の関数よりも大幅に安全にする。
１．４ 評価
本システムの適用性を、２つの重要なセキュリティアプリケーションを構築することによって論証する。第１のアプリケーションは、信頼性のあるパス１５２を活用して安全なディスク暗号化をサポートする一方で、第２のアプリケーションは、信頼性のある方法でＴＰＭチップ上の保証鍵を鍵更新するための機構を提供する。さらに、本システムのセキュリティ評価の大部分は、端末間のセキュリティ保証を提供するための、本システムの様々なコンポーネントの厳密な形式的分析を伴う。この安全なシステムの設計、実装、および分析の融合は、本発明に利点を与え、本発明の独自の特徴である。

１．４．１ ディスク暗号化。ラップトップなどの携帯機器上に記憶される機密情報を保護するセキュリティ機構が強く求められている。ラップトップが盗難に遭うことによる最近の多数のプライバシ喪失事故を考えると、そのような需要はとりわけ関連している。この問題に対処するための普及している手法は、ユーザが与えるパスワードに由来する鍵を使用し、ディスク上に記憶されるデータを暗号化する。現在の手法の深刻な弱点は、コンピューティング装置が使用中のときに、その鍵およびユーザのパスワードが攻撃を受けやすいことである。例えば、攻撃者はユーザのパスワードを傍受するためにキーストロークロガーを設置するか、またはＯＳに障害を生じさせてメモリから秘密鍵を盗む。本発明を使用し、たとえマルウェアおよび内部者攻撃を前にしても安全なディスク暗号化を行うために、本システムを使用して設定される信頼性のあるパス１５２を活用するアプリケーションを構築することができる。ユーザのパスワードおよび秘密鍵は、信頼性のあるコンポーネント、つまり信頼性のあるアプリケーションおよびトラストバイザ３１６にとって、信頼性のあるパス１５２内でしかアクセスすることができない。ユーザエクスペリエンスは単純であり、ディスクを暗号化または復号することを選択するオプションとともに１．２節でまさに説明した通りである。

１．４．２ ＴＰＭ（トラステッドプラットフォームモジュール）の構成。このアプリケーションは、ＴＰＭ（トラステッドプラットフォームモジュール）チップ上の保証鍵を鍵更新することをサポートし［３６］、それにより（上記に挙げた問題である）鍵が漏洩することからの回復性を与える。ＴＰＭチップは、製造者からの証明済み保証鍵の対（Endorsement Keypair:ＥＫ）と一緒に出荷される。この鍵の対は、暗号化および復号専用に使用される２０４８ビットのＲＳＡ鍵の対である。ＥＫは、ＴＰＭの最終的なアイデンティティとしての役割を果たす。製造者からのＥＫ証明書は、そのＴＰＭがＴＣＧ仕様［３５］に準拠することをサードパーティに確信させるのに役立つように設計される。不都合なことに、その低価格が原因でＴＰＭチップは改竄防止されていない。高度なセキュリティアプリケーションでは、ＥＫのプライベートコンポーネントが外部に一度もさらされていないように、ＴＰＭのＥＫがチップ上に生成された保証を実現することが望ましい場合がある。ＴＰＭの製造者は、ＴＰＭのＥＫを取消し可能として設定し、製造者が供給する秘密（ＥＫリセット）がパラメータとして与えられるとき、ＴＰＭ内のＥＫを破壊するコマンドを使用可能にするオプションを有する。ＴＰＭに新たなＥＫを内部的に生成させ、オプションでその新たなＥＫを取り消すために必要な新たなＥＫリセット値を割り当てるために、２つの追加のコマンドのうちの１つを使用することができる。

ＴＰＭにより新たなＥＫが内部的に生成されるとき、そのＥＫが有効なＴＰＭに対応することをサードパーティに確信させるための証明書は作成されない。したがって、新たなＥＫの作成を引き起こすエンティティ（例えばシステム管理者）は、その新たなＥＫが適切に生成されたことを証明する責任を負わなければならない。悪意あるＢＩＯＳまたはＳＭＭコードを含み得るプラットフォーム上では、ＥＫがＴＰＭ内で正しく生成されたという保証を得ることは困難である。

物理的に存在する管理者から入力を受け付け、新たなＥＫの対を作成するのに必要なＴＰＭコマンドを発行することができる専用アプリケーション、ＥＫａｐｐを設計し構築することができる。図１７にあるように、ＥＫａｐｐは、トラストバイザ３１６上で（ドライバシム３１４および信頼性のあるシェル１７１０を含む）信頼性のあるアプリケーションとして直接実行される。トラストバイザ３１６は、１つの使用可能な関数としてＥＫａｐｐの呼び出しを提供する。実行されるとき、ＥＫａｐｐはＴＰＭのＥＫの状態を検査し、その状態を以下の３つの状態のうちの１つに分類する。
１．有効かつ取消し可能
２．有効かつ永続的
３．取消し済み
ＥＫａｐｐは、ＥＫリセットを保持することをユーザが実証する場合、ユーザがＴＰＭを状態１から状態３に遷移するように、（新たなＥＫリセット値を提供することにより）状態３から状態１または２に遷移するように構成される。ＥＫがＴＰＭの存在期間にわたってＴＰＭ内に永続的に導入されたままであるので、ＥＫａｐｐは、状態２のＥＫを有するＴＰＭに対していかなる構成変更を行うこともできない。

１．４．３ 形式的分析。本発明は、アーキテクチャレベルおよび実装レベルの両方において、設計システムの厳密なセキュリティ分析を促進するように設計される。分析は以下のパートからなる。

１．システムおよび攻撃者の明確なモデル、ならびにシステムアーキテクチャのセキュリティ特性、具体的には導入部に記載した特性（１）〜（３）の仕様および検証を発展させる本発明の実施形態を予見する。さらに、この分析はＴＣＢおよびＴＣＢの予期される特性も明示的に特定する。技術的手法は、ネットワークプロトコルのセキュリティ特性を指定し、検証するためのロジックであるＰＣＬ（Ｐｒｏｔｏｃｏｌ Ｃｏｍｐｏｓｉｔｉｏｎ Ｌｏｇｉｃ）についての本発明者の従来のかつ進行中の研究［９，１０，１１，１２，１３，１４，１５，１６，１７，２１，３０］に基づく。ＴＣＧプロトコルについての進行中の正式な研究［１８］に部分的に基づき、ＰＣＬによってサポートされる推論形式は、信頼性のあるコンピューティングドメインに適用できると考える。しかし、信頼性のあるコンピューティングシステムを形式的に論証するために、ＰＣＬの構文、セマンティクス、および証明システムを拡張することに伴うかなりの量の技術的作業もある。特に、トラストバイザ３１６形式のハイパーバイザによって与えられる隔離の保証など、関連するシステム特性を忠実に作るために、プロセス間の共用メモリを可能にするように、ＰＣＬのプロセスベースモデルを拡張しなければならない。高レベルでは、形式的な分析タスクのこのコンポーネントは、数理論理学ならびにプログラミング言語の設計および分析の技法を利用する。

２．本発明者の設計は、前のステップにおいて特定した予期される特性をＴＣＢが実際に満たすことを検証できるようにし、すなわちシステム実装が、導入部に記載した特性（４）を満たすことを検証することができる。このステップは、ソフトウェアモデルチェッキング技法を使用して実行することができる。特に、セキュリティハイパーバイザのコードを、適切なソフトウェアモデルチェッカを使用して（かつ必要に応じて拡張して）分析することができる。進行中の取り組みでは、Ｃプログラム用のモデルチェッカ、具体的にはＭＡＧＩＣ［６］およびＣＭＢＣ［８］を使って実験を行っている。最近の研究では、セマンティクセキュリティ特性（認証および機密性）について、ＳＳＬハンドシェイクプロトコルのＯｐｅｎＳＳＬ実装を検証するためにＣモデルチェッカを使用した［７］。小さなコードベースを有し（ＳｅｃＶｉｓｏｒ［３３］など）、隔離などのセキュリティ特性に関する限られた並行性を有するセキュリティハイパーバイザを分析することは、現在のモデルチェッカにとって実現可能である。ソフトウェアモデルチェッカを使用し、信頼性のある検証器１２０装置のデバイスドライバも、そのドライバが予期される方法で動作する保証を得るために、検証することができる。本発明者のソフトウェアモデルチェッカでの経験およびデバイスドライバ検証における最近の成功は、これが妥当な終着点であることを示す（例えばマイクロソフトリサーチにおけるＳＬＡＭプロジェクトを参照されたい［３］）。
１．５ 技術プログラム要約
本発明では、任意のセキュアシステムの基本的構成である、ユーザが検証可能な信頼性のあるパス１５２を確立するための重要な特性を明らかにする。これらの特性は、たとえマルウェアおよび悪意ある内部者がある状態でも、信頼性のあるシェル１７１０と安全なユーザ通信を行えることを保証する。マルウェアおよび悪意ある内部者による攻撃は、汎用コンピューティングプラットフォーム内で信頼性のあるパス１５２を構築するための今日までの他の唯一の使用可能なオプションである、ＴＣＧ（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ）が提案する信頼測定の静的ルート及び信頼測定の動的ルート（Ｓｔａｔｉｃ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ ＭｅａｓｕｒｅｍｅｎｔおよびＤｙｎａｍｉｃ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ Ｍｅａｓｕｒｅｍｅｎｔ）の両方の低レベルブートシーケンスを破損する可能性がある。さらに、ＴＣＧの提案は、トラステッドプラットフォームモジュールの秘密鍵の発見につながり得る攻撃に耐える証明可能機構を欠き、（例えば証明に基づく）任意の信頼性のあるパス１５２の確立を安全でなくし、検証できなくし、ユーザが回復することをできなくする。ＴＣＧの提案とは対照的に、信頼性のあるパス１５２の機構は、今日までに定められている最も強い敵対者を前にしても永続的であり、ユーザによって検証可能であり、回復可能である。さらに、この機構は形式的に検証され、したがって他の同様のシステムでは達成できない一定の保証を約束する。

このＴＰ設計の独自の特徴は、この設計がハードウェア保護された秘密をシステム内のどこにも使用しないことである。したがって、この設計はシステムの広い攻撃面をなくし、他のシステムコンポーネントに関する秘密鍵（および秘密対称鍵）の漏洩からの信頼性の回復を助ける。この設計は、ＴＣＧの提唱が提案するように、ユーザ自身および信頼性のあるサードパーティが安全かつ実践的方法で変更可能なハードウェア保護された秘密鍵を使用し、アプリケーションレベルのユーザ検証されたＴＰをブートストラップすることも可能にする。最も重要なことに、この設計は、マルウェアがないこと、または内部者攻撃がない環境内で動作することが予期されていない既製ソフトウェア（例えばＷｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標））をユーザが実行することを可能にする。

この手法は、コンピューティング装置のＵＳＢポートにつながり、トラストバイザ３１６（コンピューティング装置上で実行され、レガシＯＳ１７１２をサポートする小さなハイパーバイザ機能を提供するコンポーネント）と通信する信頼性のある検証器１２０装置を開発することを必要とする。トラストバイザ３１６は、信頼性のあるパス１５２の関数も実装し、信頼性のある検証器１２０がトラストバイザ３１６の動作の正しさを検査することを可能にする検証関数を備える。トラストバイザ３１６は使用されて、信頼性のあるパス１５２の機能をユーザアプリケーションに拡張する。ユーザによりプラグ脱着可能な（取外し可能な）信頼性のある検証器１２０の重要な利点は、攻撃されているコンピューティング装置からの隔離性および動作上の独立性であり、すなわちそのような信頼性のある検証器１２０は、信頼性のあるパス１５２が確立されるまで、および確立されない限りオンラインになる必要がない。トラストバイザ３１６は、マルウェアおよび悪意ある内部者がその内部状態にアクセスできないような方法で設計されており、そのためトラストバイザ３１６が実行する検証関数の完全性を保証することができる。

要約すると、本発明者は、今日までに知られている最も強力な敵対者からの攻撃を耐える、任意のコンピューティングシステムの最も基本的なセキュリティ機構のうちの１つを構成し、構築し、形式的に検証する。本発明者のシステムと同様のシステムは、マルウェアおよび悪意ある内部者の攻撃がある状態で、コマンドおよび制御システム、暗号取引、金融取引、オンラインフォレンジック分析など、機密情報を扱う高価な用途に不可欠であると考える。
１．６ リスク分析および代替策
過去３０年にわたるセキュアシステムの設計および動作での経験は、３つの包括的な危険因子がシステムセキュリティ分野内の他のあらゆるものを支配することを示した。３つの危険因子とはつまり、（１）セキュアシステムを使用する際のユーザ／管理者／オペレータの誤り、（２）セキュアシステムを開発する際の設計および実装の誤り（すなわちバグや過度の複雑さ）、および（３）システム構成の誤りである。

本発明の脈絡では、起こり得るユーザの誤りを最小限にする人的要因についての設計が重要な役割を果たす。（先に言及した）潜在的な１つの脆弱性は、気をそらしたユーザがＴＰの検証を実行した後にマシンのリブートに気付かない可能性がある場合である。本発明者は、視覚的表示器だけでなく、「音の側面」をＴＰの検証に追加することによりこの潜在的な検査時−使用時の脆弱性に対処した。セキュリティ機構の設計および使用に対する人的要因の重要さを切に認識し、ＣｙＬａｂにおける人的要因研究にささげられた意義深いリソースを上手く利用して設計についての広範な使用性分析を行う予定である（例えばローリー クレノア（Ｌｏｒｉｅ Ｃｒａｎｏｒ）教授のグループは広範な研究を行い、人的要因の分野において数多くの設計を評価し、現在はアクセス制御の使用性に重点的に取り組んでいる）。信頼性のあるパス１５２の動作における人的要因のレビューおよび評価は、本発明で可能な設計代替策の主要なソースを構成する。

本発明は、任意のセキュアシステムにおいて重要な信頼の基礎を形成するＴＰ技術が、設計および実装のうちの少なくとも一方の誤りを含み得る可能性を予期する。そのような誤りは、本発明を任意の安全なシステム動作にとって不可欠なものにする目標を正確に達成できないことにつながる。このリスクを２つの重要な方法で取り除くために、本発明を修正することができる。第１は、信頼性のあるパス１５２の機構が反撃しようとする脅威を特定する正確な敵対者モデルを定め、この設計がそれらの脅威に効果的な方法で反撃することを示すことによる。第２は、信頼性のあるパス１５２技術を形式的に検証することである。実際に、信頼性のあるパス１５２に関する本発明者の定義のうちの特性（４）は、機構を形式的に分析し、検証することを必要とする。これを達成することは、バグのリスクがＴＰの機構に悪影響を及ぼさない重大な保証を得ることになる。

最後に、信頼性のあるパス１５２構成の誤りの領域に、そのような誤りの潜在的な原因を明らかにすることにより、明確に対処するつもりである。例えば、ユーザが検証可能な信頼性のあるパス１５２機構の基礎であるソフトウェア証明手法では、信頼性のある検証器１２０がＣＰＵのモデル、クロック速度、およびメモリレイテンシを含むコンピューティング装置の正確なハードウェア構成を知っていると想定する。ソフトウェア証明は、証明されているターゲット実行ファイルが自己完結型であることも想定する。つまり、信頼性のある検証器１２０によって想定されるターゲット実行ファイルの構成は変わらず、例えばそのターゲット実行ファイルは、実行中にコンピューティング装置上の他のソフトウェアを呼び出さない。これらの領域内の構成のミスマッチは、信頼性のあるパス１５２のユーザ検証においてセキュリティ違反につながる可能性があり、その理由から、構成検証検査を、そのような検査が必要になるどんな所にも、例えばトラストバイザ３１６内に組み込むつもりである。構成検証のすべての部分は、システムの設計によって対処する。
結論
本発明を特定の実施形態および実装形態の観点から概して説明してきたが、本発明は他の方法、機器、システム、および技術に適用することができる。本明細書に示した例は限定的ではなく説明的であり、本発明の他の改変形態および修正形態も考えられる。本発明のそれらのおよび他の改変形態および修正形態が可能であり考えられ、上記の明細書および特許請求の範囲はそのような修正形態および改変形態を範囲として含むことを意図する。

引用文献
[1] TPM reset attack. Available at
http : / /www . cs . dartmouth . edu/~pkilab/ sparks. Checked on February 7, 2008.
[2] Advanced Micro Devices. AMD64 virtualization: Secure virtual machine architecture reference manual. AMD Publication no. 33047 rev. 3.01, May 2005.
[3] Thomas Ball, Ella Bounimova, Byron Cook, Vladimir Levin, Jakob Lichtenberg, Con McGarvey, Bohus Ondrusek, Sriram K. Rajamani, and Abdullah Ustuner. Thorough static analysis of device drivers. In EuroSys, pages 73-85, 2006.
[4] Dan Boneh, Richard A. DeMillo, and Richard J. Lipton. On the importance of eliminating errors in cryptographic computations. Journal of Cryptology, 14(2):101- 119, 2001.
[5] David Brumley and Dan Boneh. Remote timing attacks are practical. In Proceedings of USENL Security Symposium, pages 1-14, August 2003.
[6] Sagar Chaki, Edmund M. Clarke, Alex Groce, Somesh Jha, and Helmut Veith. Modular verification of software components in c. IEEE Trans. Software Eng. , 30(6):388- 02, 2004.
[7] Sagar Chaki and Anupam Datta. Automated verification of security protocol implementations, 2008. Technical Report CMU-Cylab-08-002.
[8] Edmund Clarke, Daniel Kroening, and Flavio Lerda. A tool for checking ANSI-C programs. In Kurt Jensen and Andreas Podelski, editors, Tools and Algorithms for the Construction and Analysis of Systems (TACAS 2004), volume 2988 of Lecture Notes in Computer Science, pages 168-176. Springer, 2004.
[9] Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. A derivation system for security protocols and its logical formalization. In Proceedings of 16th IEEE Computer Security Foundations Workshop, pages 109-125. IEEE, 2003.
[10] Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. Secure protocol composition (extended abstract). In Proceedings of ACM Workshop on Formal Methods in Security Engineering, pages 11-23, 2003.
[11] AnupamDatta, Ante Derek, John C.Mitchell, and Dusko Pavlovic. Abstraction and refinement in protocol derivation. In Proceedings of 17th IEEE Computer Security Foundations Workshop, pages 30-45. IEEE, 2004.
[12] Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. Secure protocol composition. In Proceedings of 19th Annual Conference on Mathematical Foundations of Programming Semantics. ENTCS, 2004.
[13] Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. A derivation system and compositional logic for security protocols. Journal of Computer Security, 13(3):423- 482, 2005.
[14] Anupam Datta, Ante Derek, John C. Mitchell, Vitaly Shmatikov, and Mathieu Turuani. Probabilistic polynomial-time semantics for a protocol security logic. In Proceedings of the 32nd International Colloquium on Automata, Languages and Programming (ICALP '05), Lecture Notes in Computer Science, pages 16-29. Springer- Verlag, 2005.
[15] Anupam Datta, Ante Derek, John C. Mitchell, and Bogdan Warinschi.
Computationally sound compositional logic for key exchange protocols. In Proceedings of 19th IEEE Computer Security Foundations Workshop, pages 321-334. IEEE, 2006.
[16] Nancy Durgin, John C. Mitchell, and Dusko Pavlovic. A compositional logic for protocol correctness. In Proceedings of 14th IEEE Computer Security Foundations Workshop, pages 241-255. IEEE, 2001.
[17] Nancy Durgin, John C. Mitchell, and Dusko Pavlovic. A compositional logic for proving security properties of protocols. Journal of Computer Security, 11 :677-721 , 2003.
[18] Deepak Garg, Jason Franklin, Dilsun Kaynar, and Anupam Datta. Towards a theory of secure systems, 2008. Technical Report CMU-Cylab-08-003.
[19] Blaise Gassend, Dwaine Clarke, Marten van Dijk, and Srinivas Devadas. Silicon physical random functions. In Proceedings of the 9th ACM Conference on Computer and Communications Security, pages 148-160, November 2002.
[20] V. Gligor, C. Burch, R. Chandersekaran, L. Chanpman, M. Hecht, W. Jiang, G. Luckenbaugh, and N. Vasudevan. On the design and the implementation of secure xenix workstations. In Proceedings of the IEEE Symposium on Research in Security and Privacy, pages 102-117, April 1986.
[21] Changhua He, Mukund Sundararajan, Anupam Datta, Ante Derek, and John C. Mitchell. A modular correctness proof of IEEE 802.1 li and TLS. In CCS '05: Proceedings of the 12th ACM conference on Computer and communications security, pages 2-15, 2005.
[22] M.S. Hecht, M.E. Carson, C.S. Chandersekaran, R.S. Chapman, L.J. Dotterer, V.D. Gligor, W.D. Jiang, A. Johri, G.L. Luckenbaugh, and N. Vasudevan. UNIX without the superuser. In Proceedings of Summer USENIX Technical Conference, 1987.
[23] Intel Corporation. LaGrande technology preliminary architecture specification. Intel Publication no. D52212, May 2006.
Intel Corporation. Trusted execution Technology - preliminary architecture specification and enabling considerations. Document number 31516803, November 2006.
[25] Bernhard Kauer. OSLO: Improving the security of Trusted Computing. In Proceedings of the USENLX Security Symposium, August 2007.
[26] Samuel T. King, Peter M. Chen, Yi-Min Wang, Chad Verbowski, Helen J. Wang, and Jacob R. Lorch. SubVirt: Implementing malware with virtual machines. In Proceedings of the IEEE Symposium on Research in Security and Privacy, May 2006.
[27] Paul Kocher, Joshua Jaffe, and Benjamin Jun. Differential power analysis. In Advances in Cryptology - CRYPTO, pages 399-397, 1999.
[28] K. Kursawe, D. Schellekens, and B. Preneel. Analyzing trusted platform communication. In Proceedings of CRASH Workshop: Cryptographic Advances in Secure Hardware, September 2005.
[29] Jonathan M. McCune, Adrian Perrig, and Michael K. Reiter. Seeing-is-believing: Using camera phones for human- verifiable authentication. In Proceedings of IEEE Symposium on Security and Privacy, May 2005.
[30] Arnab Roy, Anupam Datta, Ante Derek, John C. Mitchell, and Jean-Pierre Seifert. Secrecy analysis in protocol composition logic, 2006. to appear in Proceedings of 11th Annual Asian Computing Science Conference, December 2006.
[31] Joanna Rutkowska. Subverting vista kernel for fun and profit. Presentation at BlackHat Briefings, available at http : //blackhat . com/presentations /bh-usa- 06/BH-US- 06-Rutkows ka . pdf , August 2006.
[32] A. Seshadri, M. Luk, E. Shi, A. Perrig, L. van Doom, and P. Khosla. Pioneer: Verifying integrity and guaranteeing execution of code on legacy platforms. In Proceedings of ACM Symposium on Operating Systems Principles (SOSP), pages 1-15, October 2005.
[33] Arvind Seshadri, Mark Luk, Ning Qu, and Adrian Perrig. Sec Visor: A tiny hypervisor to provide lifetime kernel code integrity for commodity OSes. In Proceedings of ACM SOSP, October 2007.
[34] E.R. Sparks. A security assessment of trusted platform modules. Technical Report TR2007-597, Computer Science Department, Dartmouth University, June 2007.
[35] Trusted Computing Group (TCG).
https : //www . trustedcomputinggroup . org/, 2003.
[36] Trusted Computing Group. Trusted platform module main specification, Part 1 : Design principles, Part 2: TPM structures, Part 3: Commands. Version 1.2, Revision 103, July 2007.
[37] U.S. Department of Defense. Trusted computer systems evaluation criteria.
(Orange Book) CSC-STD- 001-83, DoD ComputerSecurity Center, Fort Meade, MD, August 1983.
[38] U.S. Department of Defense. Trusted computer systems evaluation criteria.
(Orange Book) 5200.28-STD, National ComputerSecurity Center, Fort Meade, MD, December 1985.

Claims (29)

1. プロセッサ（１１２）によって、ユーザインターフェイス（１５０）と安全に実行できると想定される実行ファイル（３１２）との間に、ハイパーバイザ（３１６）およびドライバシム（３１４）を含む信頼性のあるパス（１５２）を確立する方法であって、前記プロセッサ（１１２）は、前記ユーザインターフェイス（１５０）と、メモリ（１１４）とに接続され、前記メモリ（１１４）は、前記プロセッサ（１１２）に実行される実行ファイル（３１２）、ハイパーバイザ（３１６）、およびドライバシム（３１４）を記憶する、前記方法であって、
   前記ハイパーバイザのアイデンティティを測定すること（７１０）、
   前記ハイパーバイザのアイデンティティを測定すること（７１０）により取得された前記ハイパーバイザの前記アイデンティティの測定値を、前記ハイパーバイザ用のポリシと比較すること（７１２）、
   前記ドライバシムのアイデンティティを測定すること（７１４）、
   前記ドライバシムのアイデンティティを測定すること（７１４）により取得された前記ドライバシムの前記アイデンティティの測定値を、前記ドライバシム用のポリシと比較すること（７１６）、
   前記ユーザインターフェイスのアイデンティティを測定すること（７１８）、
   前記ユーザインターフェイスのアイデンティティを測定すること（７１８）により取得された前記ユーザインターフェイスの前記アイデンティティの測定値を、前記ユーザインターフェイス用のポリシと比較すること（７２０）、
   前記ハイパーバイザの前記アイデンティティの測定値、前記ドライバシムの前記アイデンティティの測定値、および前記ユーザインターフェイスの前記アイデンティティの測定値が、前記ハイパーバイザ用の前記ポリシ、前記ドライバシム用の前記ポリシ、および前記ユーザインターフェイス用の前記ポリシにそれぞれ一致するかどうかについての、人間が知覚できる指示を提供すること（７２２）
   を含む、方法。
2. 前記ユーザインターフェイス（１５０）が、入力装置（１１６）および出力装置（１１８）の少なくとも一方を含む、請求項１に記載の方法。
3. 前記入力装置（１１６）が、キーボードおよびコンピュータマウスからなる群から選択され、
   前記出力装置（１１８）が、ビデオディスプレイ装置、プリンタ、およびオーディオ装置からなる群から選択される、請求項２に記載の方法。
4. 前記ハイパーバイザの前記アイデンティティの測定値、前記ドライバシムの前記アイデンティティの測定値、および前記ユーザインターフェイスの前記アイデンティティの測定値が、前記ハイパーバイザ用の前記ポリシ、前記ドライバシム用の前記ポリシ、および前記ユーザインターフェイス用の前記ポリシにそれぞれ一致するかどうかについての、人間が知覚できる指示を提供すること（７２２）は、
   前記ハイパーバイザの前記アイデンティティの測定値、前記ドライバシムの前記アイデンティティの測定値、および前記ユーザインターフェイスの前記アイデンティティの測定値のすべてが、前記ハイパーバイザ用の前記ポリシ、前記ドライバシム用の前記ポリシ、および前記ユーザインターフェイス用の前記ポリシにそれぞれ一致する場合に人間が知覚できる第１の指示を提供すること、
   前記ハイパーバイザの前記アイデンティティの測定値、前記ドライバシムの前記アイデンティティの測定値、および前記ユーザインターフェイスの前記アイデンティティの測定値のうちの少なくとも１つが、前記ハイパーバイザ用の前記ポリシ、前記ドライバシム用の前記ポリシ、および前記ユーザインターフェイス用の前記ポリシそれぞれに一致しない場合に人間が知覚できる第２の指示を提供すること
   を含み、前記人間が知覚できる第１の指示は、前記人間が知覚できる第２の指示とは異なる、請求項１に記載の方法。
5. 前記ハイパーバイザ用の前記ポリシおよび前記ドライバシム用の前記ポリシが、前記ユーザインターフェイス（１５０）と前記安全に実行できると想定される実行ファイル（３１２）との間の前記信頼性のあるパス（１５２）の一部ではないコンポーネント内に記憶される、請求項１に記載の方法。
6. 前記ハイパーバイザ（３１６）および前記ドライバシム（３１４）がコンピュータによって実装され、前記ハイパーバイザ用の前記ポリシおよび前記ドライバシム用の前記ポリシが、前記ハイパーバイザおよび前記ドライバシムが実装される前記コンピュータから離れた装置内に記憶される、請求項１に記載の方法。
7. 前記ユーザインターフェイス用の前記ポリシが、前記ドライバシム内に記憶される、請求項１に記載の方法。
8. 前記安全に実行できると想定される実行ファイルのアイデンティティを測定すること（８１０）、
   前記安全に実行できると想定される実行ファイルの前記アイデンティティの測定値を、前記安全に実行できると想定される実行ファイル用のポリシと比較すること（８１２）
   をさらに含む、請求項１に記載の方法。
9. 前記ドライバシムの前記アイデンティティを測定すること（７１４）、および前記ドライバシムの前記アイデンティティの測定値を比較すること（７１６）は、
   前記ハイパーバイザの前記アイデンティティを測定した（７１０）後に、および前記ハイパーバイザの前記アイデンティティの測定値を比較した（７１２）後に実行され、
   前記安全に実行できると想定される実行ファイルの前記アイデンティティを測定すること（８１０）、および前記安全に実行できると想定される実行ファイルの前記アイデンティティの測定値を比較すること（８１２）は、
   前記ドライバシムの前記アイデンティティを測定した（７１４）後に、および前記ドライバシムの前記アイデンティティの測定値を比較した（７１６）後に実行される、請求項８に記載の方法。
10. 前記ハイパーバイザの前記アイデンティティを測定すること（７１０）が、前記ハイパーバイザの前記アイデンティティの測定値を証明することを含み、
    前記ドライバシムの前記アイデンティティを測定すること（７１４）が、前記ドライバシムの前記アイデンティティの測定値を証明することを含み、
    前記ユーザインターフェイスの前記アイデンティティを測定すること（７１８）が、前記ユーザインターフェイスの前記アイデンティティの測定値を証明することを含む、請求項１に記載の方法。
11. 前記ハイパーバイザの前記アイデンティティの測定値を証明することは、ソフトウェアベースの証明であり、
    前記ドライバシムの前記アイデンティティの測定値を証明することは、ソフトウェアベースの証明であり、
    前記ユーザインターフェイスの前記アイデンティティの測定値を証明することは、ソフトウェアベースの証明である、請求項１０に記載の方法。
12. 前記ユーザインターフェイスと前記ハイパーバイザとの間の前記信頼性のあるパス１５２内の追加コンポーネントのアイデンティティを測定すること（９１０）、
    前記ユーザインターフェイスと前記ハイパーバイザとの間の前記信頼性のあるパス１５２内の前記追加コンポーネントの前記アイデンティティの測定値を、前記追加コンポーネント用のポリシと比較すること（９１２）
    をさらに含む、請求項１に記載の方法。
13. 前記ユーザインターフェイスと前記ハイパーバイザとの間の前記追加コンポーネントが、メモリコントローラハブ、入出力コントローラハブ、グラフィックスコントローラ、ＵＳＢコントローラ、専用キーボードコントローラ、および前記ユーザインターフェイスと前記ハイパーバイザとの間のバスからなる群から選択される、請求項１２に記載の方法。
14. 前記追加コンポーネント用の前記ポリシが、前記ユーザインターフェイスと前記安全に実行できると想定される実行ファイルとの間の前記信頼性のあるパスの一部ではないコンポーネント内に記憶される、請求項１２に記載の方法。
15. 前記追加コンポーネントがコンピュータによって実装され、前記追加コンポーネント用の前記ポリシが、前記追加コンポーネントが実装される前記コンピュータから離れた装置内に記憶される、請求項１２に記載の方法。
16. 前記ハイパーバイザの前記アイデンティティの測定値、前記ドライバシムの前記アイデンティティの測定値、および前記ユーザインターフェイスの前記アイデンティティの測定値のうちの少なくとも１つが、前記ハイパーバイザ用の前記ポリシ、前記ドライバシム用の前記ポリシ、および前記ユーザインターフェイス用の前記ポリシそれぞれに一致しない場合に前記人間が知覚できる第２の指示を提供した後に、
    自らのポリシに一致しない前記ハイパーバイザ、前記ドライバシム、および前記ユーザインターフェイスの少なくとも１つを既知の良好な状態に復元すること（１０１０）
    をさらに含む、請求項４に記載の方法。
17. 前記ハイパーバイザの前記アイデンティティの測定値が前記ハイパーバイザ用の前記ポリシに一致すると判定すること（１１１０）、
    前記ハイパーバイザの前記アイデンティティの測定値が前記ハイパーバイザ用の前記ポリシに一致すると判定した後に、前記ドライバシムの前記アイデンティティの測定値が、前記ドライバシム用の前記ポリシに一致するかどうかを判定すること（１１１２）、
    前記ドライバシムの前記アイデンティティの測定値が前記ドライバシム用の前記ポリシに一致しない場合、前記ドライバシムを既知の良好な状態に復元すること（１１１４）、
    前記ドライバシムの前記アイデンティティの測定値が前記ドライバシム用の前記ポリシに一致しない場合、前記ドライバシムを既知の良好な状態に復元した後に、前記ユーザインターフェイスの前記アイデンティティの測定値が、前記ユーザインターフェイス用の前記ポリシに一致するかどうかを判定すること（１１１６）、
    前記ユーザインターフェイスの前記アイデンティティの測定値が前記ユーザインターフェイス用の前記ポリシに一致しない場合、前記ユーザインターフェイスを既知の良好な状態に復元すること（１１１８）
    をさらに含む、請求項１６に記載の方法。
18. 前記ドライバシムの前記アイデンティティの測定値が前記ドライバシム用の前記ポリシに一致しない場合、前記ユーザインターフェイスの前記アイデンティティの測定値が、前記ユーザインターフェイス用のポリシに一致しないと想定される、請求項１７に記載の方法。
19. 前記ハイパーバイザ、前記ドライバシム、および前記ユーザインターフェイスの少なくとも１つを既知の良好な状態に復元した後に、
    既知の良好な状態に復元した前記ハイパーバイザ、前記ドライバシム、および前記ユーザインターフェイスの少なくとも１つの前記アイデンティティを測定すること（１２１０）、
    前記既知の良好な状態に復元した前記ハイパーバイザ、前記ドライバシム、および前記ユーザインターフェイスの少なくとも１つの前記アイデンティティを測定すること（１２１０）により取得された既知の良好な状態に復元した前記ハイパーバイザ、前記ドライバシム、および前記ユーザインターフェイスの少なくとも１つの前記アイデンティティの測定値を、前記ハイパーバイザ、前記ドライバシム、および前記ユーザインターフェイスの前記少なくとも１つのための対応するポリシと比較すること（１２１２）
    をさらに含む、請求項１６に記載の方法。
20. 前記ハイパーバイザの前記アイデンティティの測定値が前記ハイパーバイザ用の前記ポリシに一致すると判定すること（１３１０）、
    ＴＰＭ装置がセキュリティ侵害されていると判定すること（１３１２）
    をさらに含む、請求項１に記載の方法。
21. 前記ＴＰＭ装置がセキュリティ侵害されていると判定した（１３１２）後に、
    前記ＴＰＭ装置を既知の良好な状態に戻すこと（１３１４）
    をさらに含む、請求項２０に記載の方法。
22. 前記ハイパーバイザから前記ＴＰＭ装置に命令を送った後、
    前記ＴＰＭ装置内の既存の鍵を破壊すること（１３１６）、
    前記ＴＰＭ装置内の新たな鍵を作成すること（１３１８）
    をさらに含む、請求項２１に記載の方法。
23. 前記信頼性のあるパスが安全に実行できると想定されるシェルを含み、
    前記安全に実行できると想定されるシェルのアイデンティティを測定すること（１４１０）、
    前記安全に実行できると想定されるシェルのアイデンティティを測定すること（１４１０）により取得された前記安全に実行できると想定されるシェルの前記アイデンティティの測定値を、前記安全に実行できると想定されるシェル用のポリシと比較すること（１４１２）
    をさらに含む、請求項１に記載の方法。
24. 前記安全に実行できると想定されるシェル用の前記ポリシが、前記信頼性のあるパスの外側に記憶される、請求項２３に記載の方法。
25. 安全に実行できると想定されるシェルがコンピュータによって実装され、前記安全に実行できると想定されるシェル用のポリシが、前記安全に実行できると想定されるシェルが実装される前記コンピュータから離れた装置内に記憶される、請求項１に記載の方法。
26. 前記ハイパーバイザの前記アイデンティティの測定値、前記ドライバシムの前記アイデンティティの測定値、および前記ユーザインターフェイスの前記アイデンティティの測定値が、前記ハイパーバイザ用の前記ポリシ、前記ドライバシム用の前記ポリシ、および前記ユーザインターフェイス用の前記ポリシにそれぞれ一致するかどうかについての、人間が知覚できる指示を提供した後に、
    前記安全に実行できると想定される実行ファイルを実行すること（７２４）
    をさらに含む、請求項１に記載の方法。
27. 前記安全に実行できると想定される実行ファイルを実行した後に、
    前記安全に実行できると想定される実行ファイルの前記実行を一時停止すること（１５１０）、
    前記安全に実行できると想定される実行ファイルが一時停止されたという、人間が知覚できる指示を提供すること（１５１２）
    をさらに含む、請求項２６に記載の方法。
28. 前記安全に実行できると想定される実行ファイルを実行する前に、且つ前記ハイパーバイザの前記アイデンティティの測定値、前記ドライバシムの前記アイデンティティの測定値、および前記ユーザインターフェイスの前記アイデンティティの測定値が、前記ハイパーバイザ用の前記ポリシ、前記ドライバシム用の前記ポリシ、および前記ユーザインターフェイス用の前記ポリシにそれぞれ一致するかどうかについての、人間が知覚できる指示を提供した後に、
    前記安全に実行できると想定される実行ファイルを実行する確認を示す入力を人間のユーザから受け取ること（１６１０）
    をさらに含む、請求項２６に記載の方法。
29. コンピュータであって、
    プロセッサ（１１２）と、
    前記プロセッサ（１１２）に接続されるユーザインターフェイス（１５０）と、
    前記プロセッサ（１１２）に接続され、且つ前記プロセッサ（１１２）によって実行されるとき、前記プロセッサ（１１２）にコンピューティングプラットフォームを作成させるコンピュータ可読命令を記憶するメモリ（１１４）であって、
    ハイパーバイザ（３１６）、およびドライバシム（３１４）を記憶し、
    前記ユーザインターフェイス（１５０）と前記プロセッサ（１１２）との間の信頼性のあるパス（１５２）であって、前記ハイパーバイザ（３１６）および前記ドライバシム（３１４）を含む、前記信頼性のあるパス（１５２）とを有する、前記メモリ（１１４）と、
    前記プロセッサ（１１２）に接続され、且つプロセッサ（１２２）およびメモリ（１２４）を含む検証装置（１２０）であって、前記検証装置（１２０）の前記メモリ（１２４）は、コンピュータ可読命令と、前記ハイパーバイザ（３１６）用のポリシと、前記ドライバシム（３１４）用のポリシとを含む、前記検証装置（１２０）と
    を備えるコンピュータ（１１０）であって、
    前記コンピュータ（１１０）の前記プロセッサ（１１２）によって実行されるとき、前記コンピュータ（１１０）の前記メモリ（１１４）内の前記コンピュータ可読命令が、
    安全に実行できると想定される実行ファイルを実行する要求を示す信号を受け取ること（５１０）、
    前記安全に実行できると想定される実行ファイルを実行する前記要求を示す前記信号を受け取った後に、前記ハイパーバイザと前記検証装置との間の安全な接続を認証すること（５１２）、
    前記ハイパーバイザの少なくとも一部分のアイデンティティを測定すること（５１４）、
    前記ハイパーバイザの少なくとも一部分のアイデンティティを測定すること（５１４）により取得された前記ハイパーバイザの前記アイデンティティの測定値を前記検証装置に送ること（５１６）、
    前記ドライバシムの少なくとも一部分の前記アイデンティティを測定すること（５１８）、
    前記ドライバシムの少なくとも一部分の前記アイデンティティを測定すること（５１８）により取得された前記ドライバシムの前記アイデンティティの測定値を前記検証装置に送ること（５２０）、
    前記ユーザインターフェイスの少なくとも一部分の前記アイデンティティを測定すること（５２２）、
    前記ユーザインターフェイスの少なくとも一部分の前記アイデンティティを測定すること（５２２）により取得された前記ユーザインターフェイスの前記アイデンティティの測定値を前記ユーザインターフェイス用のポリシと比較すること（５２４）
    を前記コンピュータ（１１０）の前記プロセッサ（１１２）に実行させ、
    前記検証装置（１２０）内の前記プロセッサ（１２２）によって実行されるとき、前記検証装置（１２０）の前記メモリ（１２４）内の前記コンピュータ可読命令が、
    前記コンピュータ（１１０）内の前記プロセッサから前記ハイパーバイザの測定値を受け取ること（６１０）、
    前記検証装置内に記憶される前記ハイパーバイザ用の前記ポリシを、前記検証装置が受け取る前記ハイパーバイザの測定値と比較すること（６１２）、
    前記コンピュータ（１１０）内の前記プロセッサから前記ドライバシムの測定値を受け取ること（６１４）、
    前記検証装置内に記憶される前記ドライバシム用の前記ポリシを、前記検証装置が受け取る前記ドライバシムの測定値と比較すること（６１６）
    を前記検証装置（１２０）内の前記プロセッサ（１２２）に実行させ、
    前記認証すること（５１２）、前記ハイパーバイザの少なくとも一部分の前記アイデンティティを測定すること（５１４）、前記ハイパーバイザの前記アイデンティティの測定値を前記検証装置に送ること（５１６）、前記ドライバシムの少なくとも一部分の前記アイデンティティを測定すること（５１８）、前記ドライバシムの前記アイデンティティの測定値を前記検証装置に送ること（５２０）、前記ユーザインターフェイスの少なくとも一部分の前記アイデンティティを測定すること（５２２）、前記ユーザインターフェイスの前記アイデンティティの測定値を前記ユーザインターフェイス用のポリシと比較すること（５２４）、前記コンピュータ（１１０）内の前記プロセッサから前記ハイパーバイザの測定値を受け取ること（６１０）、前記検証装置内に記憶される前記ハイパーバイザ用の前記ポリシを、前記検証装置が受け取る前記ハイパーバイザの測定値と比較すること（６１２）、前記コンピュータ（１１０）内の前記プロセッサから前記ドライバシムの測定値を受け取ること（６１４）、および前記検証装置内に記憶される前記ドライバシム用の前記ポリシを、前記検証装置が受け取る前記ドライバシムの測定値と比較すること（６１６）が、前記安全に実行できると想定される実行ファイルを実行する前記要求を示す前記信号を受け取ること（５１０）の後に、かつ前記コンピュータ（１１０）をリブートすることなしに実行される、
    コンピュータ（１１０）。