JP4812168B2 - 信用コンピューティング・プラットフォーム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、信用デバイス（trusted device）、信用コンピューティング・プラットフォーム（trusted computing platform）、信用トランザクション(trusted transaction)および同じ動作の方法一般に関連する。
【０００２】
【従来の技術】
商用アプリケーションでは、ローカルまたはリモートのエンティティによる修正に対し振る舞いが脆弱な環境において、クライアント・コンピューティング・プラットフォームが典型的に動作する。プラットフォームの潜在的不安定さは、（例えば電子商取引の目的で）プラットフォームを使用しようとするローカル・パーティ（local party）か、さもなければプラットフォームと通信するリモート・パーティ(remote party)による使用の制限となる。本明細書では、他に述べられないかぎり、ローカル・パーティおよびリモート・パーティの両方を「ユーザ」として参照する。
【０００３】
既存のセキュリティ・アプリケーション（例えばウイルス検出ソフトウェア）は、プラットフォームが意図されたとおりに動作し、プラットフォームがプロセスおよびアプリケーションを破壊しないという想定の下にコンピューティング・プラットフォーム上で動作する。これは、意図されたソフトウェアの状態が不安定になっていないか、またはウイルスなどの他のソフトウェアによって破損されていない条件で有効な想定である。したがって、ユーザは、典型的には、その様なプラットフォームの使用を重要ではないアプリケーションに制限し、センシティブなデータまたはビジネスの重要なデータのリスクに対して、そのプラットフォームを使用することの利便性を比較検討する。
【０００４】
【発明が解決しようとする課題】
したがって、プラットフォームにおける信用のレベルを大きくすれば、既存のセキュリティ・アプリケーション（例えば「セキュア・ソケット・レイヤー」または「ＩＰＳｅｃ」など）またはリモート管理アプリケーションに対するユーザの信頼をより大きくすることができる。これは、これらのアプリケーションに対する依存度をより大きくすることができ、その結果、所有者のコストを低減することができる。信用が大きくなれば、ローカルおよびリモートコンピューティング・プラットフォームの両方の正しい動作に対する信頼が大きくなるので、新しい電子ビジネス方法も可能にする。
【０００５】
この文書では、意図された目的に対して常に予期した態様で何かが振る舞う場合にその何かを「信用する」ことができるという意味で、用語「信用（trust）」を使用する。
【０００６】
【課題を解決するための手段】
本発明者は、プラットフォームにおける信用を検証し可能な限り強化するために、コンピューティング・プラットフォームにおいて物理的デバイスを使用するのが望ましいと考えた。典型的には、本デバイスは、信用測定および関連するプラットフォームの属性の報告を提供し、この属性がプラットフォームの完全性（integrity）を示す。さらに最も好ましくは、本デバイスは耐タンパ性(tamper-resistant)である。
【０００７】
第１の観点によれば、本発明は、コンピューティング装置を提供し、この装置は、１つまたは複数の他のコンポーネントと通信するためにそれぞれ接続された主処理手段および主メモリ手段を実装されたアセンブリと、それと共にアセンブリ上に実装され、アセンブリ上の１つまたは複数の他のコンポーネントと通信するために接続される信用デバイスとを含む。この信用デバイスは、前記コンピューティング装置の完全性測定の値を獲得するよう構成される。
【０００８】
説明の簡単化の理由でこの明細書で使用するような、用語「デバイス（device）」は、等価な機能、若しくは１つまたは複数の既存のプラットフォームデバイスまたはアセンブリに統合された等価な機能性を有する複数のデバイスを包含する。さらに、この明細書で使用される用語「真(true)」は、その値がコンピューティング装置の状態を正しく反映する値であることを意味している。測定方法が信用デバイスによって以外には実質的に修正することができない場合、このことが成立する。
【０００９】
第２の観点によれば、本発明は、信用コンピューティング装置およびユーザを含むシステムを動作する方法を提供し、信用デバイスを組み込む信用コンピューティング装置は、コンピューティング装置の完全性測定の真の値を獲得するよう構成される。この方法は、以下のステップを含む。
【００１０】
信用コンピューティング装置の完全性測定の真の値を信用デバイスが獲得するステップと、
ユーザが完全性を証明するために信用コンピューティング装置についてチャレンジを生成して、信用コンピューティング装置にチャレンジを提出するステップと、
信用コンピューティング装置がチャレンジを受信し、信用デバイスが完全性測定を含むレスポンスを生成し、ユーザにレスポンスを返すステップと、
ユーザがレスポンスを受信し、レスポンスから完全性測定を抽出し、信用パーティにより生成されている信用コンピューティング装置のための認証測定基準と完全性整合基準とを比較するステップと、を含む。
【００１１】
第３の観点によれば、本発明は、信用コンピューティング装置とリモート・コンピューティング装置との間にシステムにおける通信チャネルを確立する方法を提供する。この方法は、リモート・コンピューティング装置が前述の方法を使用して信用コンピューティング装置の完全性を検証するステップと、信用コンピューティング装置の完全性がリモート・コンピューティング装置によってうまく検証された場合に、さらなるトランザクションのために通信チャネルを維持するステップと、を含む。
【００１２】
第４の形態によれば、本発明は、特定のアプリケーションを処理するためのユーザによる使用に、信用コンピューティング装置が信用されることができることを検証する方法を提供する。この方法は、ユーザが前述の方法を使用して信用コンピューティング装置の完全性を検証するステップと、信用コンピューティング装置の完全性がリモート・コンピューティング装置によってうまく検証された場合に、ユーザが信用コンピューティング装置を使用して特定のアプリケーションを処理するステップとを含む。
【００１３】
本発明の他の観点および形態は、以下の説明から明らかになるだろう。
【００１４】
【発明の実施の形態】
本発明の模式的形態は、物理的な信用デバイスのコンピューティング・プラットフォームへの組み込みを提供する。この信用デバイスの機能は、プラットフォームの完全性測定（integrity metric）を提供する信頼性のある測定データとプラットフォームのアイデンティティ（identity;身元）とを結び付けることである。アイデンティティおよび完全性測定は、プラットフォームの信用を保証するために用意された信用パーティ（ＴＰ；trusted party）によって提供された期待値と比較される。合致する場合、完全性測定の範囲に応じて、少なくともプラットフォームの部分が正しく動作していることを意味する。
【００１５】
ユーザは、プラットフォームと他のデータを交換する前に、プラットフォームの正しい動作を検証する。ユーザは、そのアイデンティティおよび完全性測定を提供するよう信用デバイスに要求することによってこれを行う（選択的に、信用デバイスは、それ自身がプラットフォームの正しい動作を検証することができなければ、アイデンティティの証拠を提供することを拒否する）。ユーザは、アイデンティティのプルーフ（proof;証拠）とアイデンティティの測定基準を受け取り、真であると信じる値に対してそれらを比較する。これらの適当な値は、ＴＰによってかまたはユーザが信用した別のエンティティによって提供される。信用デバイスにより報告されたデータがＴＰによって提供されたものと同じであれば、ユーザはプラットフォームを信用する。これは、ユーザがエンティティを信用するからである。エンティティは、以前にアイデンティティを検証し、プラットフォームの適当な完全性測定を求めているので、そのプラットフォームを信用する。
【００１６】
一旦、ユーザがプラットフォームの信用動作を確立したならば、他のデータをプラットフォームと交換する。ローカル・ユーザの場合、交換は、プラットフォーム上で走る任意のソフトウェア・アプリケーションと相互作用することによってなされるかもしれない。リモート・ユーザの場合、交換は、セキュア・トランザクション（secure transaction）を含むかもしれない。どちらの場合も、データ交換は、信用デバイスにより「署名（sign）」される。そのとき、ユーザは、信用できる振る舞いのプラットフォームとデータが交換されているという、より大きな信頼を持つことができる。
【００１７】
信用デバイスは、暗号プロセスを使用するが、必ずしも暗号プロセスへの外部インターフェースを提供するとはかぎらない。さらに、最も好ましい実施は、信用デバイスをタンパプルーフ（tamperproof）にして、プラットフォームの他の機能に対してアクセス不可能にすることによって秘密情報を保護し、権限の無い修正に対して実質的に免疫のある環境を提供することであろう。タンパプルーフ化（tamper-proofing）が不可能なので、最良の近似は、耐タンパ性（tamper-resistant）の信用デバイスまたはタンパ検出(tamper-detecting)する信用デバイスである。したがって、信用デバイスは、耐タンパ性である１つの物理的コンポーネントからなるのが好ましい。
【００１８】
耐タンパ性に関する技術は、セキュリティ技術における当業者に既知のものである。この技術は、不正変更（tampering）に抵抗する方法（例えば信用デバイスの適当なカプセル化など）、タンパ検出の方法（例えば仕様電圧、Ｘ線、または信用デバイスのケーシングにおける物理的な完全性の損失からの検出など）および不正変更を検出したときにデータを除去する方法を含む。適当な技術のさらなる説明は、http://www.cl.cam.ac.uk/~mgk25/tamper.htmlで見つけることができる。タンパプルーフが本発明の最も望ましい機能であるけれども、これは、本発明の通常の動作に入らず、したがって、本発明の範囲を超えるので、ここでは詳細に記載しない。
【００１９】
信用デバイスは、偽造困難でなければならないので、物理的デバイスであることが好ましい。これは、模造困難でなければならないので、耐タンパ性であることが最も好ましい。典型的には、ローカルおよびリモートの距離の両方でアイデンティティを証明する必要があるので、暗号プロセスを使用することができるエンジンを有し、関連するプラットフォームのなんらかの完全性測定をする少なくとも１つの方法を含む。
【００２０】
図１に信用プラットフォーム１０を図示する。プラットフォーム１０は、キーボード１４、マウス１６、および視覚表示ユニット（ＶＤＵ）１８の標準的機能を有し、これらがプラットフォームの物理的「ユーザ・インターフェース」を提供する。信用プラットフォームのこの実施形態は、スマートカード読み取り装置１２も有する（スマートカード読み取り装置は全ての信用プラットフォームの必須の要素ではないが、以下で説明する様々な好ましい実施形態において用いられる。）スマートカード読み取り装置１２の側に沿ってスマートカード１９が図示される。このスマートカードが、以下でさらに述べるように、信用ユーザが信用プラットフォームと相互に作用することを可能にする。プラットフォーム１０には複数のモジュール１５が存在する。これらは、そのプラットフォームに適する必須の任意の種類の信用プラットフォームの他の機能的要素である（その様な要素の機能的意義が本発明に関連しないので、ここではさらに説明しない）。
【００２１】
図２に示すように、信用コンピューティング・プラットフォーム１０のマザーボード２０は、（他の標準的コンポーネントの中の）メイン・プロセッサ２１、メイン・メモリ２２、信用デバイス２４、データバス２６、並びに各制御ライン２７およびライン２８を含む。さらにマザーボード２０は、プラットフォーム１０のためのＢＩＯＳプログラムを含むＢＩＯＳメモリ２９および入出力（ＩＯ）デバイス２３を含む。入出力デバイス２３は、マザーボードのコンポーネントと、スマートカード読み取り装置１２、キーボード１４、マウス１６、ＶＤＵ１８との間の相互作用を制御する。メイン・メモリ２２は、典型的にランダム・アクセス・メモリ（ＲＡＭ）である。動作中、プラットフォーム１０は、ハードディスク（図示せず）からＲＡＭにオペレーティング・システム（例えばWindows NT（商標）など）をロードする。さらに、動作中、プラットフォーム１０は、プラットフォーム１０により実行されるプロセスまたはアプリケーションをハードディスク（図示せず）からＲＡＭにロードする。
【００２２】
典型的には、パーソナル・コンピュータでは、ＢＩＯＳプログラムは、特別の予約メモリ領域（最初のメガバイトのうちの上部６４Ｋがシステムメモリ（アドレスＦ０００ｈ〜ＦＦＦＦｈ）を行う）に配置され、メイン・プロセッサは、工業的な規格に従って、このメモリの場所を最初に見るよう構成される。
【００２３】
このプラットフォームと従来技術のプラットフォームとの間の重大な差違は、リセット後にメイン・プロセッサが最初に信用デバイスによって制御され、それから、プラットフォームの特定のＢＩＯＳプログラムに制御を渡し、その次に通常通りに入出力デバイスを制御することである。ＢＩＯＳプログラムが実行された後で、ＢＩＯＳプログラムによって通常どおりに（例えばWindows NTなどの）オペレーティング・システム・プログラムに制御が渡され、このオペレーティング・システムは、典型的にはハードディスクデバイス（図示せず）からメイン・メモリ２２にロードされる。
【００２４】
明らかに、通常の手順からの変更は、工業規格の実施に修正を必要とし、それによってメイン・プロセッサ２１が信用デバイス２４をアドレス指定するよう指示されてその最初の命令を受信する。この変更は、メイン・プロセッサ２１に異なるアドレスをハード・コーディング(hard-coding)することによって簡単に行うことができる。もう１つの方法として、信用デバイス２４が標準ＢＩＯＳプログラムのアドレスに割り当てられてもよい。この場合、メイン・プロセッサのコンフィギュレーション（configuration）を修正する必要が無くなる。
【００２５】
信用デバイス２４内部にＢＩＯＳブート・ブロックが含まれることが非常に好ましい。これは、完全性測定の獲得をだめにすること（これは、ローグ・ソフトウェア・プロセス（rogue software process）が存在する場合に発生する）を防ぎ、オペレーティング・システムのためにＢＩＯＳが適当な環境を確立するのを（正しい場合にすら）失敗する状況を作るローグ・ソフトウェア・プロセスを防ぐ。
【００２６】
記載する好ましい実施形態では、信用デバイス２４は、単一のディスクリート・コンポーネントであるけれども、代替的に信用デバイス２４の機能がマザーボード上の複数のデバイスに分離されてもよいし、またはプラットフォームの１つまたは複数の既存の標準的デバイスに統合されてもよいことが分かる。例えば、機能およびそれらの通信をだめにすることなく、信用デバイスの１つまたは複数の機能をメイン・プロセッサそれ自体に統合することができる。しかしながら、これは、おそらくプロセッサ上に信用機能による別個の専用リード線を必要とする。さらにまたは代替的に、本発明の実施形態では、信用デバイスは、マザーボード２０への統合に適合したハードウェアデバイスであるけれども、信用デバイスは、例えばドングル（dongle）などの「リムーバブル（取り外し可能）」デバイス（これは、必要なときにプラットフォームに取り付けられる）として実施されてもよいことが考えられる。信用デバイスが統合されるかまたリムーバブルにされるかどうかは、設計の選択事項である。しかしながら、信用デバイスが分離可能である場合、信用デバイスとプラットフォームとの間の論理的結合を提供するメカニズムが存在すべきである。
【００２７】
図３に示すように、信用デバイス２４は、たくさんのブロックを含む。システムのリセットの後で、信用デバイス２４は、セキュア・ブート・プロセスを実行して、プラットフォーム１０のオペレーティング・システム（システムクロックおよびモニタ上の表示を含む）が適当かつセキュアな態様で走ることを確実にする。セキュア・ブート・プロセス中に、信用デバイス２４は、コンピューティング・プラットフォーム１０の完全性測定を獲得する。信用デバイス２４は、セキュア・データ転送（例えば暗号化／解読および署名／照合を介するスマートカードとそれとの間の認証）も実行することができる。信用デバイス２４は、例えばユーザ・インターフェースのロックなどの様々なセキュリティ制御ポリシーをセキュアに実現することもできる。
【００２８】
具体的には、信用デバイスは、信用デバイス２４の全体的動作を制御するようプログラムされ信用デバイス２４上の他の機能およびマザーボード２０上の他のデバイスと相互作用するようプログラムされたコントローラ３０と、プラットフォーム１０から完全性測定を獲得する測定機能３１と、規定されたデータを署名、暗号化または解読する暗号機能３２と、スマートカードを認証する認証機能３３と、マザーボードのデータバス２６、制御ライン２７、およびアドレス・ライン２８にそれぞれ信用デバイス２４を接続する適当なポート（３６、３７、３７）を有するインターフェース回路３４と、を含む。信用デバイス２４におけるそれぞれのブロックは、信用デバイス２４の適当な揮発性メモリ領域４および／または不揮発性メモリ領域３への（典型的にはコントローラ３０を介する）アクセス権を有する。さらに、信用デバイス２４は、既知の方法で耐タンパ性となるよう設計される。
【００２９】
パフォーマンスの理由から信用デバイス２４は応用特定集積回路（ＡＳＩＣ）として実施される。しかしながら、柔軟性のために、信用デバイス２４は適当にプログラムされたマイクロ・コントローラであることが好ましい。ＡＳＩＣとマイクロ・コントローラのどちらもマイクロ・エレクトロニクスの技術分野では既知のものであり、ここでは詳細に考察されない。
【００３０】
信用デバイス２４の不揮発性メモリ３に記憶されるデータの１項目は、証明書３５０（certificate）である。証明書３５０は、少なくとも信用デバイス２４の公開鍵３５１および信用パーティ（ＴＰ）によって測定されたプラットフォームの完全性測定の認証された値３５２を含む。証明書３５０は、信用デバイス２４に記憶される前に、ＴＰの私有鍵を使用してＴＰにより署名される。後の通信セッションでは、プラットフォーム１０のユーザは、獲得された完全性測定と認証された完全性測定３５２とを比較することによって、プラットフォーム１０の完全性を検証する。合致した場合、ユーザは、プラットフォーム１０が破壊されていないことを信用することができる。ＴＰの一般利用可能な公開鍵の知識は、証明書３５０の簡単な検証を可能にする。不揮発性メモリ３５は、アイデンティティ（ＩＤ）ラベル３５３も含む。ＩＤラベル３５３は、例えばシリアル番号などの従来技術のＩＤラベルであり、ある範囲で固有である。ＩＤラベル３５３は、信用デバイス２４に関するデータを索引付けし、ラベル付けするのに一般に使用されるが、それ自身では、信用条件下でプラットフォーム１０のアイデンティティを証明するのに不十分である。
【００３１】
信用デバイスは、関連するコンピューティング・プラットフォーム１０の完全性測定を高い信頼性で測定するかまたは獲得する少なくとも１つの方法を備える。本発明の実施形態では、完全性測定は、ＢＩＯＳメモリにおけるＢＩＯＳ命令のダイジェスト（digest）を生成することによる測定機能３１によって獲得される。その様に獲得された完全性測定は、前述のように検証されれば、プラットフォーム１０がハードウェアまたはＢＩＯＳプログラムの段階で破壊されていないという高いレベルの信用をプラットフォーム１０の潜在的ユーザに与える。他の既知のプロセス（例えばウイルス・チェッカー）が典型的には存在して、オペレーティング・システムおよびアプリケーション・プログラム・コードが破壊されていないことをチェックする。
【００３２】
測定機能３１は、ハッシュ・プログラム３５４および信用デバイス２４の私有鍵３５５を記憶する不揮発性メモリ３、並びに、ダイジェスト３６１の形態で獲得された完全性測定を記憶する揮発性メモリ４へのアクセス権を有する。適当な実施形態では、揮発性メモリ４は、公開鍵およびプラットフォーム１０へのアクセス権を与えるのに使用される１つまたは複数の認証スマートカード１９の関連するＩＤラベル３６０ａ〜３６０ｎを記憶するのにも使用される。
【００３３】
１つの好ましい実施では、ダイジェストおよび完全性測定は、ブール値を含み、これは、明白になるという理由で、測定機能３１により揮発性メモリ４に記憶される。
【００３４】
完全性測定を獲得する好ましいプロセスを図４を参照して説明する。
【００３５】
スイッチオンで、測定機能は、ステップ５００においてデータ、制御およびアドレス・ライン（２６、２７、２８）上でメイン・プロセッサ２１の活動を監視して、信用デバイス２４がアクセスされた最初のメモリであるかどうかを判断する。従来の動作の下では、メイン・プロセッサは、ＢＩＯＳプログラムを最初に実行するために、ＢＩＯＳメモリに最初に向けられていた。しかしながら、本発明の実施形態によれば、メイン・プロセッサ２１は、信用デバイス２４に向けられ、これがメモリとして作用する。ステップ５０５において信用デバイス２４が最初にアクセスされたメモリであれば、ステップ５１０で、測定機能３１は、信用デバイス２４がアクセスされた最初のメモリであったことを示すブール値を揮発性メモリ３に書き込む。そうでなければ、ステップ５１５において、測定機能は、信用デバイス２４がアクセスされた最初のメモリではなかったことを示すブール値を書き込む。
【００３６】
信用デバイス２４がアクセスされた最初のメモリではない場合、当然、信用デバイス２４が全くアクセスされないという機会が存在する。これは、例えばメイン・プロセッサ２１がＢＩＯＳプログラムを最初に走らすよう操作された場合であろう。これらの状況では、プラットフォームは、動作するだろうが、完全性測定を利用することができないので、要望に応じてその完全性を検証することができない。さらに、ＢＩＯＳプログラムがアクセスされた後で信用デバイス２４がアクセスされた場合、明らかに、ブール値は、プラットフォームの完全性の欠如を示す。
【００３７】
ステップ５２０においてメイン・プロセッサ２１によりメモリとしてアクセスされたとき（または場合）、メイン・プロセッサ２１は、ステップ５２５において測定機能３１から記憶されたネイティブ・ハッシュ命令３５４（native hash instruction）を読み取る。ハッシュ命令３５４は、メイン・プロセッサ２１による処理のためにデータバス２６を介して渡される。ステップ５３０では、メイン・プロセッサ２１は、ハッシュ命令３５４を実行し、それらを使用して、ステップ５３５において、ＢＩＯＳメモリ２９の内容を読み取り、これらの内容をハッシュ・プログラムに従って処理することによって、ＢＩＯＳメモリ２９のダイジェストを演算する。ステップ５４０では、メイン・プロセッサ２１は、信用デバイス２４における不揮発性メモリ４の適当な場所に演算されたダイジェスト３６１を書き込む。それから測定機能３１は、ステップ５４５において、ＢＩＯＳメモリ２９におけるＢＩＯＳプログラムを呼びだし、従来技術の態様で実行が続けられる。
【００３８】
明らかに、必要とされる信用の範囲に応じて、完全性測定の値を演算する多数の様々な態様が存在する。ＢＩＯＳプログラムの完全性の測定は、プラットフォームの基礎を成す処理環境の完全性についての基本的なチェックを提供する。完全性測定は、ブート・プロセスの検証についての推論を可能にするような形態であるべきである（正しいＢＩＯＳを使用してプラットフォームがブートされたかどうかを検証するのに完全性測定の値を使用することができる）。選択的にＢＩＯＳ内部の個々の機能ブロックはそれら自身のダイジェストの値を有し、全体的なＢＩＯＳのダイジェストはこれら個別のダイジェストのダイジェストである。これは、意図した目的にどの部分のＢＩＯＳ動作が重要であり、どれが無関係であるかをポリシーが言明することを可能にする（この場合、個別のダイジェストは、ポリシーの下での動作の有効性を確立するような態様で記憶されなければならない）。
【００３９】
他の完全性チェックは、プラットフォームに取り付けられた様々な他のデバイス、コンポーネント、または装置が存在し、正しく正常運転にあることを確立することを含む。１つの例では、周辺デバイスとの通信が信用されることを確実にするために、ＳＣＳＩコントローラに関連するＢＩＯＳプログラムが検証される。もう１つの例では、プラットフォーム上の他のデバイス（例えばメモリデバイスまたはコプロセッサなど）の完全性が、固定のチャレンジ／レスポンスの相互作用を成立させることによって検証されて、一貫性のある結果を確実にする。信用デバイス２４が別個のコンポーネントである場合、その様な相互作用のなんらかの形態は、信用デバイス２４とプラットフォームとの間での適当な論理的結合を提供する。さらに、本発明では信用デバイス２４はプラットフォームの他の部分との主通信手段としてデータバスを利用するけれども、（さほど便利ではないが）ハードワイアード経路または光学的経路などのような代替的な通信経路を提供することも可能である。さらに、本発明の実施形態では、信用デバイス２４がメイン・プロセッサ２１に完全性測定を検証するよう指示するけれども、他の実施形態では、信用デバイス自体が１つまたは複数の完全性測定をするよう構成される。
【００４０】
好ましくは、ＢＩＯＳブート・プロセスは、ブート・プロセスそれ自体の完全性を検証するメカニズムを有する。その様なメカニズムは、既に例えばインテルのドラフト「Wired for Management baseline specification v2.0 - BOOT Integrity Service」から分かり、ソフトウェアまたはファームウェアをロードする前にソフトウェアまたはファームウェアのダイジェストを演算することを含む。その様な演算されたダイジェストは、信用されたエンティティにより提供された証明書に記憶された値と比較される。これの公開鍵はＢＩＯＳに知られている。それから、演算された値が証明書からの期待値に合致し、かつ信用されたエンティティの公開鍵の使用によりその証明書が有効性を証明された場合にだけ、ソフトウェア／ファームウェアがロードされる。そうでなければ、適当な例外処理ルーチンが起動される。
【００４１】
選択的に、演算されたＢＩＯＳのダイジェストを受信した後で、信用デバイス２４は、証明書におけるＢＩＯＳの適当な値を検査することができ、演算されたダイジェストが適当な値に合致しない場合、ＢＩＯＳに制御を渡さないことができる。さらにまたは代替的に、信用デバイス２４は、ブール値を検査し、信用デバイス２４がアクセスされた最初のメモリでなかった場合にＢＩＯＳに戻る制御を渡さないことができる。これらの場合のどちらにおいても適当な例外処理ルーチンを起動することができる。
【００４２】
図５は、ＴＰ、プラットフォームに組み込まれた信用デバイス２４、および信用プラットフォームの完全性を検証したい（リモート・プラットフォームの）ユーザによる動作のフローを示す。ユーザがローカル・ユーザである場合、実質的に図５に示すのと同じステップが含まれることが考えられる。どちらの場合も、ユーザは、典型的には、検証を成立するソフトウェア・アプリケーションの形態に依存する。リモート・プラットフォームまたは信用プラットフォーム上でソフトウェア・アプリケーションを走らすことが可能である。しかしながら、リモート・プラットフォーム上でさえ、ソフトウェア・アプリケーションは何らかの方法で破壊される機会が存在する。したがって、高いレベルの完全性では、ユーザのスマートカード上にソフトウェア・アプリケーションが常駐し、そのユーザが検証目的のために適当な読み取り装置にスマートカードを挿入することが考えられる。図５は、一般的な場合についての動作のフローを示す。ユーザのスマートカードによる検証のための動作のより具体的なフローをさらに以下の図６を参照して説明する。
【００４３】
最初の例では、ＴＰ（これが信用プラットフォームを保証する）は、プラットフォームのタイプを検査して、それを保証するかどうかを判断する。これは、ポリシーの問題である。全てがよければ、ステップ６００において、ＴＰは、プラットフォームの完全性測定の値を測定する。それから、ＴＰは、ステップ６０５においてプラットフォームのために証明書を生成する。証明書は、信用デバイスの公開鍵、および選択的にそのＩＤラベルを完全性測定に追加し、ＴＰの私有鍵でストリングを署名することによってＴＰにより生成される。
【００４４】
信用デバイス２４は、次に信用デバイスの私有鍵を使用して、ユーザから受信されたなんらかの入力データを処理し、私有鍵の知識なしに入力／出力のペアを生成することが統計上不可能になるよう出力データを生成することによって信用デバイスのアイデンティティを証明することができる。そのため、私有鍵の知識は、この場合のアイデンティティの基礎をなす。アイデンティティの基礎をなすのに対象な暗号（symmetric encryption）を利用することが可能であることは明らかである。しかしながら、対象な暗号を使用する欠点は、ユーザが信用デバイスとユーザの秘密情報（secret）を共有する必要があるということである。さらに、ユーザと秘密情報を共有する必要性の結果、対象な暗号は、ユーザにアイデンティティを証明するのに原則として充分であるが、第三者にアイデンティティを証明するのには不十分であり。第三者は、信用デバイスまたはユーザから発生した検証を全く確認することができない。
【００４５】
ステップ６１０では、信用デバイス２４の不揮発性メモリの適当な場所３に証明書３５０を書き込むことによって、信用デバイス２４が初期化される。これは、好ましくは、マザーボード２０にインストールされた後で、信用デバイス２４とセキュア通信することによってなされる。信用デバイス２４に証明書を書き込む方法は、そこに私有鍵を書き込むことによってスマートカードを初期化するのに使用される方法に類似する。セキュア通信は、ＴＰだけに知られている「マスター鍵」によってサポートされ、製造中に信用デバイス（またはスマートカード）に書き込まれており、信用デバイス２４にデータの書き込みを可能にするのに使用される。マスター鍵の知識なしに信用デバイス２４にデータを書き込むことは不可能である。
【００４６】
プラットフォームの動作期間のどこか後の時点（例えばスイッチオンまたはリセットになるとき）で、ステップ６１５において、信用デバイス２４は、プラットフォームの完全性測定３６１を獲得し記憶する。
【００４７】
ユーザがプラットフォームと通信するのを望むとき、ステップ６２０において、ユーザは、例えば乱数などの臨時符号（nonce）を生成し、ステップ６２５において、信用デバイス２４にチャレンジする（プラットフォームのオペレーティング・システムまたは適当なソフトウェア・アプリケーションは、チャレンジを認識し、適当なやり方でＢＩＯＳタイプ・コールを介して信用デバイス２４にそれを渡すよう構成される）。臨時符号は、信用できないプラットフォームによる、古いが本物の署名のリプレイ（リプレイ攻撃と呼ばれる）によって生じるごまかし（deception）からユーザを保護するのに使用される。臨時符号を提供し、そのレスポンスを検証するプロセスは、既知のチャレンジ／レスポンス・プロセス（challenge/response protocol）の例である。
【００４８】
ステップ６３０において、信用デバイス２４は、チャレンジを受け取り、適当なレスポンスを生成する。これは、測定された完全性測定および臨時符号のダイジェストであってもよく、選択的にそのＩＤラベルであってもよい。それから、信用デバイス２４は、ステップ６３５においてその私有鍵を使用してダイジェストに署名し、証明書３５０に添えて署名されたダイジェストをユーザに返す。
【００４９】
ステップ６４０では、ユーザは、そのチャレンジのレスポンスを受け取り、ＴＰの既知の公開鍵を使用して証明書を検証する。それから、ユーザは、ステップ６５０において、証明書から信用デバイス２４の公開鍵を抽出し、それを使用して、チャレンジのレスポンスから署名されたダイジェストを解読する。それからステップ６６０において、ユーザは、チャレンジのレスポンス内の命令符号を検証する。次に、ステップ６７０において、ユーザは、演算された完全性測定（チャレンジのレスポンスから抽出する）と適当なプラットフォームの完全性測定（証明書から抽出する）とを比較する。ステップ６４５、６５５、６６５、または６７５における前述の検証ステップのいずれかが失敗した場合、全体のプロセスは、ステップ６８０で終わり、さらなる通信は発生しない。
【００５０】
全てがうまくいくと想定すると、ステップ６８５および６９０において、ユーザおよび信用プラットフォームは、他のプロトコルを使用して、他のデータのためにセキュア通信を設定する。ここで、プラットフォームからのデータは、信用デバイス２４によって署名されることが好ましい。
【００５１】
この検証プロセスのさらなる補強が可能である。チャレンジャー（challenger）は、チャレンジを通じて、プラットフォームの完全性測定の値とそれを得た方法の両方を認識することが好ましい。これら両方の情報部分は、チャレンジャーがプラットフォームの完全性について適当に判断することを可能にするのが望ましい。チャレンジャーは、利用することができる多くの異なる選択肢も有している。すなわち、チャレンジャーは、信用デバイス２４において完全性測定が有効として認識されることを受け入れる。またはチャレンジャーは、代替的に完全性測定の値がチャレンジャーによって保持された値（または、これら２つの場合において信用の異なるレベルになるようそこで保持してもよい）に等しい場合、関連するレベルの完全性をプラットフォームが有することだけを受け入れることができる。
【００５２】
証明書を署名し、使用する技術、およびそれらを使用してアイデンティティを証明する技術は、セキュリティの分野において既知であるので、ここでは詳細に述べる必要はない。
【００５３】
先に示すように、図６は、スマートカード１９を有する信用プラットフォームと相互に作用するユーザによるプラットフォームの完全性の検証の例における動作のフローを示す。先に述べたように、プロセスは、チャレンジ／レスポンスのルーチンを実装するのが便利である。利用することができる多くのチャレンジ／レスポンスのメカニズムが存在する。本発明の実施形態で使用される認証プロトコルの実施は、ＩＳＯ／ＩＥＣ ９７９８−３「Information technology-Security techniques-Entity authentication mechanisms; Part 3; Entity authentication using a public key algorithm」(International Organization for Standardization, November 1993)に記載されるような、相互（または３ステップ）認証である。もちろん、例えばこの参照文献にも記載されるような２ステップまたは４ステップなどの他の認証プロシージャを利用することができない理由はない。
【００５４】
最初にステップ７００において、ユーザは、スマートカード１９をプラットフォームのスマートカード読み取り装置１２に挿入する。
【００５５】
事前に、この態様のユーザによる使用のためにコンフィギュレートされたプラットフォームは、典型的には、標準的なオペレーティング・システムの制御下で動作し、認証プロセスを実行し、ユーザがスマートカード１９を挿入するのを待っている。この態様でアクティブになるスマートカード読み取り装置１２とは別に、プラットフォームは、典型的には、ユーザ・インターフェース（すなわち、スクリーン、キーボード、およびマウス）をロックすることによってユーザがアクセスすることができない状態にある。しかしながら、これは、本発明の形態の全ての場合ではない。
【００５６】
スマートカード１９がスマートカード読み取り装置１２に挿入された場合、信用デバイス２４は、ステップ７０５において、臨時符号Ａを生成しスマートカード１９に転送することによって、ステップにおける相互認証を試みるようトリガーされる。例えば乱数などの臨時符号は、信用することができない第三者による、古いが本物のレスポンスのリプレイ（リプレイ攻撃と呼ばれる）によって生じるごまかしから発信者（originator）を保護するのに使用される。
【００５７】
それに応答して、ステップ７１０において、スマートカード１９は、レスポンスを生成して返す。このレスポンスは、プレーンテキストＡ、スマートカード１９により生成された新しい臨時符号Ｂ、信用デバイス２４のＩＤ、およびなんらかの冗長、スマートカード１９の私有鍵でプレーンテキストに署名することによって生成されたプレーンテキストの署名、並びにスマートカード１９のＩＤおよび公開鍵を含む証明書、の連結（concatenation）を含む。
【００５８】
信用デバイス２４は、ステップ７１５においてプレーンテキストの署名を検証するために証明書の公開鍵を使用することによってレスポンスを認証する。レスポンスが信用できなければ、プロセスはステップ７２０で終わる。レスポンスが信用できれば、ステップ７２５において信用デバイス２４は、さらなるレスポンスを生成し送信する。このさらなるレスポンスは、プレーンテキストＡ、臨時符号Ｂ、スマートカード１９のＩＤ、および獲得された完全性測定、信用デバイス２４の私有鍵を使用してプレーンテキストに署名することによって生成されたプレーンテキストの署名、並びにＴＰの私有鍵によって両方とも署名された信用デバイス２４の私有鍵および認証完全性測定、の連結を含む。
【００５９】
スマートカード１９は、ＴＰの公開鍵を使用し、認証完全性測定と獲得された完全性測定とを比較して、このレスポンスを認証する。ステップ７３０において、合致は検証の成功を示している。さらなるレスポンスが認証されなければ、プロセスは、ステップ７３５で終わる。
【００６０】
プロシージャが成功した場合、信用デバイス２４がログオンカード１９を認証し、スマートカード１９が信用プラットフォームの完全性を検証し、ステップ７４０において、認証プロセスがユーザのためにセキュア・プロセスを実行する。
【００６１】
ある種の相互作用では、認証プロセスはこの時点で終わる。しかしながら、セッションをユーザと信用プラットフォームとの間で続けるべきであれば、プラットフォームに認証されるのをユーザが維持することを確実にするのが望ましい。
【００６２】
続けられる認証が必要である場合、認証プロセスは、ステップ７４５においてインターバル・タイマを設定する。その後で、適当なオペレーティング・システムの割り込みルーチンを使用して、認証プロセスは、インターバル・タイマをサービスして、ステップ７５０において予め定めたタイムアウト周期にタイマが合うかまたは超過するときを周期的に検出する。
【００６３】
明らかに、認証プロセスおよびインターバル・タイマは、セキュア・プロセスと並列に走る。タイムアウト周期になるか超過するとき、認証プロセスは、信用デバイス２４をトリガーして、ステップ７６０においてスマートカード１９に対しチャレンジを転送しそれ自体を識別することによってスマートカード１９を再認証する。スマートカード１９は、ステップ７６５においてそのＩＤと公開鍵を含む証明書を返す。ステップ７７０では、レスポンスが無いか（例えばスマートカード１９が取り除かれた結果）または証明書がなんらかの理由によりもはや有効ではなければ（例えばスマートカードが異なるスマートカードと取り替えられた）、ステップ７７５において信用デバイス２４によってセッションが終了される。そうでなければ、ステップ７７０において、ステップ７４５からのプロセスがインターバル・タイマをリセットすることによって繰り返される。
【００６４】
さらにまたは代替的に、いくつかの実施形態では、ユーザ・プロファイルが暗号化され、プライバシーと完全性を保護するよう署名されることが必要とされる。その場合、セキュア・データ転送プロトコルが信用デバイス２４とスマートカード１９との間に必要とされる。２つのエンティティ間でセキュア証明書を転送するために、利用することができる多くのメカニズムが存在する。本発明の実施形態で使用することができる可能性のある実施は、ＩＳＯ／ＩＥＣ ＤＩＳ１１７７０−３「Information technology - Security techniques - Key management - Part3 : Mechanisms using asymmetric techniques」(International Organization for Standardization, March 1997)からのセキュア・キー・トランスポート・メカニズム(secure key transport mechanism)である。
【００６５】
他の既知のチャレンジおよびレスポンス技術を使用する検証プロセスの修正は、当業者によって容易に実現される。同様に、代替的な検証プロセスが様々な態様（すなわちスマートカードを備えたユーザ以外）におけるプラットフォームと相互に作用するパーティによって使用されることができる。
【図面の簡単な説明】
【図１】本発明の実施形態を実施することができるシステムを示す図。
【図２】スマートカード読み取り装置を介してスマートカードおよび一連のモジュールと通信するよう構成された信用デバイスを含むマザーボードを示す図。
【図３】より詳細な信用デバイスを示す図
【図４】コンピューティング装置の完全性測定基準を獲得することを含むステップを示すフロー図。
【図５】完全性を検証する信用プラットフォームを含む信用コンピューティング・プラットフォームとリモート・プラットフォームとの間の通信を確立することを含むステップを示すフロー図。
【図６】スマートカードによるプラットフォームの潜在的なユーザによる信用コンピューティング・プラットフォームの検証を含むステップを示す図。
【符号の説明】
２０ マザーボード
２１ メイン・プロセッサ
２２ メイン・メモリ
２３ ＩＯデバイス
２４ 信用デバイス
２９ ＢＩＯＳメモリ

Claims (11)

1. メイン・プロセッサおよびメイン・メモリを備えるコンピューティング装置であって、該コンピューティング装置は、さらに１つ又は複数の他のコンポーネントと通信可能に接続された信用デバイスを備え、
   前記信用デバイスは、信用パーティによって認証された前記コンピューティング装置の完全性の測定値を格納する該信用デバイス上のメモリと、コントローラとを備え、
   前記コントローラは、完全性を測定して測定値を前記信用デバイス上のメモリに格納するために返信させる命令を前記メイン・プロセッサに出すようプログラムされており、該測定値（獲得した測定値）は、前記コンピューティング装置が意図された目的通りに動作していることを示す目安であり、
   前記コントローラは、前記コンピューティング装置に挿入されたスマートカードその他の外部装置による完全性に対するチャレンジに応じて、前記獲得した測定値および前記認証された完全性の測定値を含む応答を該スマートカードその他の外部装置に提供するよう構成されており、
   前記スマートカードその他の外部装置が、前記獲得した測定値および認証された完全性の測定値を前記応答から抽出して比較することにより、前記コンピューティング装置の完全性を検証するよう構成されている、コンピューティング装置。
2. 前記コントローラは、前記信用デバイス上のメモリに記憶された前記メイン・プロセッサにネイティブなハッシュ命令を前記メイン・プロセッサに転送することによって、前記メイン・プロセッサに命令するようプログラムされている、請求項１に記載のコンピューティング装置。
3. 前記コンピューティング装置は、当該コンピューティング装置のリセット後において、前記命令が最初の命令になるようプログラムされている、請求項２に記載のコンピューティング装置。
4. 前記信用デバイスは、前記メイン・プロセッサからのメモリ読み取り信号に応答して、該メイン・プロセッサに前記命令を転送するようプログラムされている、請求項２または３に記載のコンピューティング装置。
5. 前記信用デバイスは、通信可能な接続をするためのデータバス手段を監視して、前記コンピューティング装置がリセット後に前記メイン・プロセッサによって生成された最初のメモリ読み取り信号が前記信用デバイスにアドレス指定された場合、前記信用デバイス上のメモリに当該アドレス指定があったことを示すフラグを記憶するようプログラムされている、請求項１から４のいずれかに記載のコンピューティング装置。
6. 前記信用デバイスのＩＤ、
   前記認証された完全性の測定値、
   および暗号化用の私有鍵、
   のうちの少なくとも１つを前記信用デバイスが前記信用デバイス上のメモリに記憶している請求項１から５のいずれかに記載のコンピューティング装置。
7. 暗号化用の私有鍵を前記信用デバイスが前記信用デバイス上のメモリに記憶している請求項６に記載のコンピューティング装置。
8. 署名された公開暗号鍵を前記信用デバイスが該信用デバイス上のメモリに記憶している請求項７に記載のコンピューティング装置。
9. 前記信用デバイスは、認証された完全性の測定値を該信用デバイス上のメモリに記憶し、
   前記コントローラは、暗号化機能を提供し、前記信用デバイスは、受信された前記チャレンジに対するレスポンスを生成するようプログラムされ、当該レスポンスが、前記私有鍵を使用する暗号化機能によって暗号化された、前記獲得した測定値および前記認証された完全性の測定値を含む、請求項７または８に記載のコンピューティング装置。
10. 前記信用デバイスは、複数の完全性の測定値を取得するようプログラムされている、請求項１から９のいずれかに記載のコンピューティング装置。
11. 前記信用デバイスは、耐タンパ性を有する、請求項１から１０のいずれかに記載のコンピューティング装置。

Images