(57)【要約】第１のコンピュータ装置がトラステッド・エンティティであるかどうかを判断するために、該第１のコンピュータ装置の第１の完全性メトリックを取得する手段であって、入力手段に応答して該取得を起動する取得手段と、該第１のコンピュータ装置がトラステッド・デバイスであるという標示をユーザに示す提示手段と、を備える携帯型ハンドヘルドコンピューティング装置。【選択図】図５
2004508619.tif 000002
【特許請求の範囲】
【請求項１】
第１のコンピュータ装置がトラステッド・エンティティであるかどうかを判断するために該第１のコンピュータ装置の第１の完全性メトリックを取得する取得手段であって、入力手段に応答して該取得を起動する取得手段と、
前記第１のコンピュータ装置がトラステッド・デバイスであるという標示をユーザに提示する提示手段と、
を備える携帯型ハンドヘルドコンピューティング装置。
【請求項２】
前記携帯型ハンドヘルドコンピューティング装置の第２の完全性メトリックを取得して該携帯型ハンドヘルドコンピューティング装置がトラステッド・エンティティであるかどうかについての判断を可能にするよう構成されたトラステッド・デバイスと、
前記第２の完全性メトリックを前記第１のコンピュータ装置に伝達して、該携帯型ハンドヘルドコンピューティング装置および前記第１のコンピュータ装置の信頼状態に関しての相互判定を可能にする通信手段と、
をさらに備える請求項１に記載の携帯型ハンドヘルドコンピューティング装置。
【請求項３】
前記第１のコンピュータ装置に認証データを提供するように構成された暗号手段をさらに備える、請求項１に記載の携帯型ハンドヘルドコンピューティング装置。
【請求項４】
前記コンピューティング装置が、携帯情報端末である請求項１から請求項３のいずれかに記載の携帯型ハンドヘルドコンピューティング装置。
【請求項５】
前記コンピューティング装置が、無線電話機である請求項１から請求項４のいずれかに記載の携帯型ハンドヘルドコンピューティング装置。
【請求項６】
前記コンピューティング装置が、スマートカードである請求項１から請求項４のいずれかに記載の携帯型ハンドヘルドコンピューティング装置。
【請求項７】
前記コンピューティング装置が、バイオメトリック・リーダである、請求項１から請求項４のいずれかに記載の携帯型ハンドヘルドコンピューティング装置。
【発明の詳細な説明】
【０００１】
（背景技術）
商業用途では、通常、クライアント・コンピューティング・プラットフォームは、その挙動が、ローカルのエンティティまたは遠隔のエンティティによる変更に対して無防備となっている環境で動作している。該プラットフォームについてのセキュリティが脅かされる可能性は、そのことがなければ該プラットフォームを快く使用するであろうローカル・パーティや、そのことがなければ該プラットフォームと通信するであろう遠隔のパーティが、電子商取引の目的で該プラットフォームを使用する場合の制約となる。
【０００２】
既存のセキュリティ・アプリケーション、例えばウィルス検出ソフトウェアは、プラットフォームが意図するとおり動作し、かつプロセスおよびアプリケーションを破壊することがないという想定の下で、コンピューティング・プラットフォーム上で実行される。これは、意図するソフトウェアの状態が不安定になっていない、またはウィルスなどの他のソフトウェアによって損傷を与えられていないという条件の下では、妥当な想定である。したがって、ユーザは、通常、そのようなプラットフォームの使用をクリティカルでないアプリケーションに制限し、プラットフォームを使用することの便利さを、センシティブなデータまたはビジネスにとってクリティカルなデータに対するリスクと比較検討することとなる。
【０００３】
したがって、プラットフォームへの信頼のレベルを高めることにより、既存のセキュリティ・アプリケーション（「セキュア・ソケット・レイヤ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）」または「ＩＰＳｅｃ」）、または遠隔の管理アプリケーションに対するユーザの信用をより大きくすることができる。これにより、それらのアプリケーションへの依拠を大きくすることができ、よって「管理費（ｃｏｓｔ ｏｆ ｏｗｎｅｒｓｈｉｐ）」を低減することができる。また、より高い信頼により、ビジネスの新しい電子方法が可能になる。というのは、ローカルのコンピューティング・プラットフォームと遠隔のコンピューティング・プラットフォームの両方の正しい動作に対してより大きな信用が存在することとなるからである。
【０００４】
欧州特許出願９９３０１１００．６は、コンピューティング・プラットフォームのアイデンティティ（ｉｄｅｎｔｉｔｙ）を、該プラットフォームの完全性メトリック（ｉｎｔｅｇｒｉｔｙ ｍｅｔｒｉｃ）を提供するように確実に測定されたデータに結びつける機能を持つ物理的なトラステッド・デバイス（ｔｒｕｓｔｅｄ ｄｅｖｉｃｅ；信頼できるデバイス）を、該プラットフォームに組み込むことを開示する。アイデンティティおよび完全性メトリックは、プラットフォームの信頼性を保証するために設けられたトラステッド・パーティ（ｔｒｕｓｔｅｄ ｐａｒｔｙ：ＴＰ、信頼できるパーティ）によって提供される期待値（ｅｘｐｅｃｔｅｄ ｖａｌｕｅ）と比較される。一致するものがあれば、これは、完全性メトリックの範囲に応じて、プラットフォームの少なくとも一部が正しく動作していることを示す。
【０００５】
ユーザは、プラットフォームの正しい動作を確認した後に、他のデータを、該プラットフォームと交換する。ユーザは、プラットフォームのアイデンティティおよび完全性メトリックを提供するようトラステッド・デバイスに要求することによって、これを行う。（オプションとしてだが、トラステッド・デバイスは、自分自身がプラットフォームの正しい動作を確認することができなかった場合、アイデンティティの証拠を提供することを拒否する。）ユーザは、アイデンティティの証拠および完全性メトリックを受け取り、それを、真であると信じられている値と比較する。この適切な値は、ＴＰにより、またはユーザが信頼する別のエンティティにより提供される。トラステッド・デバイスによって報告されたデータが、ＴＰによって提供されたものと同じである場合、ユーザは、そのプラットフォームを信頼する。これは、ユーザがそのエンティティを信頼するからである。エンティティは、該アイデンティティを以前に確証して、該プラットフォームの適切な完全性メトリックを判定しているので、該エンティティは該プラットフォームを信頼している。
【０００６】
ユーザは、プラットフォームの信頼できる動作を確立した後に、他のデータを該プラットフォームと交換する。ローカル・ユーザの場合、該交換は、プラットフォーム上で実行される何らかのソフトウェアアプリケーションと対話することによって行われることができる。遠隔ユーザの場合、該交換に、セキュアなトランザクションを伴うことができる。いずれの場合も、交換されるデータには、トラステッド・デバイスによって「署名される（ｓｉｇｎｅｄ）」。次に、ユーザは、その挙動を信頼することができるプラットフォームとデータが交換されているという、より高い信用を有することができる。
【０００７】
しかしながら、遠隔ユーザは、装置からの応答が、信頼できるやり方で確認されるということを保証することができない。したがって、この状況を改善することが望ましい。
【０００８】
本明細書では、「信頼（ｔｒｕｓｔ）」という語を用いているが、これは、意図する目的のために、何かしらが常に予期されるやり方で動作する場合に、その何かしらを「信頼」することができるという意味で使用されている。
【０００９】
（発明の概要）
本発明の第１の側面によれば、第１のコンピュータ装置がトラステッド・エンティティ（ｅｎｔｉｔｙ）であるかどうかを判断するために、該第１のコンピュータ装置の第１の完全性メトリックを取得する取得手段であって、入力手段に応答して該取得を起動する取得手段と、該第１のコンピュータ装置がトラステッド・デバイスであることを示す標示をユーザに提示する提示手段と、を備える携帯型ハンドヘルドコンピューティング装置が提供される。
【００１０】
好ましくは、携帯型ハンドヘルドコンピューティング装置は、さらに、該携帯型ハンドヘルドコンピューティング装置の第２の完全性メトリックを取得して、該携帯型ハンドヘルドコンピューティング装置がトラステッド・エンティティであるかどうかについての判断を可能にするよう構成されるトラステッド・デバイスと、該第２の完全性メトリックを第１のコンピュータ装置に伝達して、該携帯型ハンドヘルドコンピューティング装置および第１のコンピュータ装置の信頼状態（ｔｒｕｓｔｅｄ ｓｔａｔｅ）について相互判定を可能にする伝達手段と、を備える。
【００１１】
オプションとして、携帯型ハンドヘルドコンピューティング装置は、さらに、第１のコンピュータ装置に認証データ（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄａｔａ）を提供するように構成される暗号手段を備える。
【００１２】
本発明は、携帯型セキュリティ・チャレンジャ（Ｐｏｒｔａｂｌｅ Ｓｅｃｕｒｉｔｙ Ｃｈａｌｌｅｎｇｅｒ）を使用して装置の完全性を検査することによって、ユーザの信頼および信用を高める装置および方法に関する。携帯型セキュリティ・チャレンジャは、携帯情報端末（ＰＤＡ）、モバイル電話機、スマートカード、またはバイオメトリック・リーダ（ｂｉｏｍｅｔｒｉｃ ｒｅａｄｅｒ）であることができる。携帯型セキュリティ・チャレンジャは、トラステッド・デバイスから完全性メトリックを得るために該トラステッド・デバイスにチャレンジするのに使用され、また携帯型セキュリティ・チャレンジャは、そのユーザを認証するのにも使用されることができる。携帯型セキュリティ・チャレンジャは、専用のチャレンジを行うデバイスでなくてもよく、コンピューティング・パワー、ユーザ・インターフェース、および通信媒体を備えた任意のデバイスを、携帯型セキュリティ・チャレンジャにすることができる。
【００１３】
本発明は、コンピューティング装置の完全性を検査する従来技術の方法を拡張し、ユーザが、強力なユーザ・インターフェースを備えたトラステッド携帯型チャレンジャを使用して、該装置に対してチャレンジすることができるようにする。強力なユーザ・インターフェースを備えた携帯型セキュリティ・チャレンジャにより、コンピューティングの完全性検査へのユーザの信頼および信用を高めることが可能となる。
【００１４】
本発明では、相互の完全性チャレンジが定義される。さらなるセキュアな通信のために、さらなる交換セッション鍵が提供される。
【００１５】
本発明は、コンピューティング装置にチャレンジする装置を提供し、該コンピューティング装置から送られる応答を確認して、信頼できる結果をユーザに示そうとする。
【００１６】
好ましくは、携帯型ハンドヘルドコンピューティング装置は、完全性の検査以外の機能をも実行することができ、完全性検査プロセスを行いながら、他の機能を切り離すことができる。完全性検査のすべてのデータおよびすべてのプロセスが保護され、そのようなチャレンジャにおける他の機能、プロセス、またはプログラムは、完全性検査プロセスのどの部分にも干渉しない。
【００１７】
好ましくは、該装置は、携帯情報端末（ＰＤＡ）デバイス、すなわちトラステッドＰＤＡデバイスである。トラステッドＰＤＡは、物理的に画定されたトラステッド・デバイスを備える通常のＰＤＡである。該トラステッド・デバイスを備えるＰＤＡは、自己完全性検査を行うことができ、ユーザは、該自己完全性検査の結果を信頼することができる。オプションとして、トラステッドＰＤＡは、スマートカードを備えた通常のＰＤＡであり、これは、該ＰＤＡの完全性を検査して該完全性検査の結果を表示することができ、ユーザは、該完全性検査の結果を信頼することができる。
【００１８】
好ましくは、該装置は、モバイル電話機、すなわちトラステッド・モバイル電話機である。トラステッド・モバイル電話機は、物理的に画定されたトラステッド・デバイスを備える通常のモバイル電話機である。該トラステッド・デバイスを備えるモバイル電話機は自己完全性検査を行うことができ、ユーザは、該自己完全性検査の結果を信頼することができる。オプションとして、トラステッド・モバイル電話機は、スマートカードを備えた通常のモバイル電話機であり、これは、該モバイル電話機の完全性を検査して、該完全性検査の結果を表示することができ、ユーザは、該完全性検査の結果を信頼することができる。
【００１９】
好ましくは、該装置は、自己表示機能を備えたスマートカードである。好ましくは、該装置は、自己表示機能を備えたバイオメトリック・リーダである。トラステッド・バイオメトリック・リーダは、物理的に画定されたトラステッド・デバイスを備える通常のバイオメトリック・リーダである。該トラステッド・デバイスを備えたバイオメトリック・リーダは、自己完全性検査を行うことができ、該自己完全性検査の結果を表示することができ、ユーザは、該自己完全性検査の結果を信頼することができる。
【００２０】
次に、本発明の好ましい実施形態を単に例として、図面を参照して説明する。
【００２１】
（発明の詳細な説明）
図１には、トラステッド・プラットフォーム（ｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ；信頼できるプラットフォーム）１０が示されている。プラットフォーム１０は、プラットフォームの物理的な「ユーザ・インターフェース」を提供する標準機能を持つキーボード１４、マウス１６、および視覚的表示装置（ＶＤＵ：ｖｉｓｕａｌ ｄｉｓｐｌａｙ ｕｎｉｔ）１８を含む。トラステッド・プラットフォームのこの実施形態はまた、スマートカード・リーダ１２を含む。スマートカード・リーダは、すべてのトラステッド・プラットフォームの必要不可欠な要素ではないが、以下で説明する様々な好ましい実施形態において使用される。スマートカード・リーダ１２とともに、スマートカード１９が示されており、これにより、以下でさらに説明するトラステッド・プラットフォームとの信頼できるユーザ対話が可能となる。プラットフォーム１０には複数のモジュール１５が存在し、これらは、該プラットフォームに適切なものではあるが本質的に任意の種類の、該トラステッド・プラットフォームの他の機能的要素である（このような要素の機能上の意義は、本発明には関係しないので、本明細書でさらに述べることはしない）。
【００２２】
図２に示されるように、トラステッド・コンピューティング・プラットフォーム１０のマザーボード２０は、（他の標準の構成要素もあるが、とりわけ）メイン・プロセッサ２１、メイン・メモリ２２、トラステッド・デバイス２４、データ・バス２６、それぞれの制御ライン２７およびライン２８、プラットフォーム１０のためのＢＩＯＳプログラムを含むＢＩＯＳメモリ２９、および入出力（ＩＯ）デバイス２３を含み、入出力デバイス２３は、マザーボードの構成要素と、スマートカード・リーダ１２、キーボード１４、マウス１６、およびＶＤＵ１８との間の対話を制御する。メイン・メモリ２２は通常、ランダム・アクセス・メモリ（ＲＡＭ）である。プラットフォーム１０は、動作の際、オペレーティング・システム、例えばＷｉｎｄｏｗｓ　ＮＴ（商標）をハードディスク（図示せず）からＲＡＭにロードする。さらに、プラットフォーム１０は、動作の際、プラットフォーム１０によって実行されることのできるプロセスまたはアプリケーションをハードディスク（図示せず）からＲＡＭにロードする。
【００２３】
パーソナル・コンピュータにおいては通常、ＢＩＯＳプログラムは、特別に確保されたメモリ領域に置かれており、第１のメガバイトの上位６４Ｋがシステム・メモリ（アドレスＦ０００ｈからＦＦＦＦｈ）を示し、メイン・プロセッサは、業界全体の標準に従ってまずこのメモリ位置を見るように構成される。
【００２４】
このプラットフォームと従来のプラットフォームの間の顕著な違いは、リセット後に、メイン・プロセッサがトラステッド・デバイスによって最初に制御され、その後、該トラステッド・デバイスが、プラットフォームに固有のＢＩＯＳプログラムに制御を渡し、該ＢＩＯＳプログラムが、通常どおりにすべての入出力デバイスを初期化することである。ＢＩＯＳプログラムが実行された後、制御は、通常どおりに、ＢＩＯＳプログラムによってＷｉｎｄｏｗｓ　ＮＴ（商標）などのオペレーティング・システム・プログラムに渡され、該オペレーティング・システム・プログラムは通常、ハードディスク・ドライブ（図示せず）からメイン・メモリ２２にロードされる。
【００２５】
明らかに、通常の手順からのこの変更は、業界標準の実装に対する変更を必要とし、これにより、メイン・プロセッサ２１は、最初の命令を受け取るためにトラステッド・デバイス２４をアドレスすることとなる。この変更は、異なるアドレスをメイン・プロセッサ２１にハードコーディング（ｈａｒｄ−ｃｏｄｉｎｇ）することによって簡単に行うことができる。代替的に、トラステッド・デバイス２４に、標準のＢＩＯＳプログラムのアドレスを割り当てることができ、この場合は、メイン・プロセッサの構成を変更する必要はない。
【００２６】
ＢＩＯＳのブート・ブロックが、トラステッド・デバイス２４内に含まれるようにすることが極めて望ましい。これにより、完全性メトリック（ＩＭ）を取得することによる破壊（ｓｕｂｖｅｒｓｉｏｎ、これは、悪性の（ｒｏｇｕｅ）ソフトウェア・プロセスが存在する場合に生じるおそれがある）を防止し、また、オペレーティング・システムのための適切な環境をＢＩＯＳ（たとえ、ＢＩＯＳが正しくても）が構築することができない状況を悪性のソフトウェア・プロセスが作り出すことを防止する。説明する好ましい実施形態では、トラステッド・デバイス２４は単一の別個の構成要素であるが、代替的に、トラステッド・デバイス２４の機能をマザーボード上の複数のデバイスに分割することができ、またはプラットフォームの既存の１つまたは複数の標準デバイスに統合することさえできるということは、予測されるであろう。例えば、機能およびそれらの通信を破壊することができないという条件の下に、トラステッド・デバイスの１つまたは複数の機能をメイン・プロセッサ自体に組み込むことができる。しかしながら、このことはおそらく、信頼できる機能（ｔｒｕｓｔｅｄ ｆｕｎｃｔｉｏｎｓ）が単独で使用するために、プロセッサ上に別個のリード線（ｌｅａｄ）を必要とする。加えて、または代替的に、この実施形態ではトラステッド・デバイスはマザーボード２０に組み込まれるように適合されたハードウェア・デバイスであるが、トラステッド・デバイスを、必要とされるときにプラットフォームに取り付けることができるドングル（ｄｏｎｇｌｅ）などの「取外し可能な」デバイスとして実現できることも予測される。トラステッド・デバイスを組み込むか、または取外し可能にするかは、設計上の選択である。しかし、トラステッド・デバイスが分離可能である場合、トラステッド・デバイスとプラットフォームとの間に論理的結合を提供するための機構が存在しなければならない。
【００２７】
図３に示されるように、トラステッド・デバイス２４は、いくつかのブロックを含む。システム・リセットの後、トラステッド・デバイス２４は、セキュアなブート・プロセスを行って、プラットフォーム１０のオペレーティング・システムが（システム・クロックおよびモニタ上の表示も含めて）適切でセキュアなやり方で確実に実行されるようにする。セキュアなブート・プロセス中、トラステッド・デバイス２４は、コンピューティング・プラットフォーム１０の完全性メトリックを取得する。また、トラステッド・デバイス２４は、セキュアなデータ転送を行うことができ、例えば、暗号化／暗号化解除および署名（ｓｉｇｎａｔｕｒｅ）／確認（ｖｅｒｉｆｉｃａｔｉｏｎ）を介して、自分自身とスマートカードとの間の認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）を行うこともできる。また、トラステッド・デバイス２４は、ユーザ・インターフェースをロックするなどの様々なセキュリティ制御ポリシーをもセキュアに実施することもできる。
【００２８】
具体的には、トラステッド・デバイスは、該トラステッド・デバイス２４の動作全体を制御し、かつトラステッド・デバイス２４上の他の機能およびマザーボード２０上の他のデバイスと対話するようにプログラムされたコントローラ３０と、プラットフォーム１０から完全性メトリックを取得する測定機能３１と、指定されたデータを署名、暗号化、または暗号化解除を行う暗号機能３２と、スマートカードを認証する認証機能３３と、トラステッド・デバイス２４をマザーボード２０のデータ・バス２６、制御ライン２７、およびアドレス・ライン２８にそれぞれ接続するための適切なポート（３６、３７、および３８）を有するインターフェース回路３４と、を備える。トラステッド・デバイス２４におけるブロックのそれぞれは、トラステッド・デバイス２４の適切な揮発性メモリ領域４および／または不揮発性メモリ領域３へのアクセスを有する（通常、コントローラ３０を介して）。さらに、トラステッド・デバイス２４は、既知のやり方で、耐タンパー（ｔａｍｐｅｒ ｒｅｓｉｓｔａｎｔ）であるように設計される。
【００２９】
パフォーマンス上の理由で、トラステッド・デバイス２４を、特定用途向け集積回路（ＡＳＩＣ）として実現することができる。しかしながら、柔軟性を考慮して、トラステッド・デバイス２４は好ましくは適切にプログラムされたマイクロコントローラである。ＡＳＩＣとマイクロコントローラはともに、マイクロエレクトロニクスの技術分野では周知であり、本明細書でさらに詳細に考察することはしない。
【００３０】
トラステッド・デバイス２４の不揮発性メモリ３に記憶されるデータのうちの１つのアイテムは、証明書（ｃｅｒｔｉｆｉｃａｔｅ）３５０である。証明書３５０は、トラステッド・デバイス２４の公開鍵３５１、およびトラステッド・パーティ（ＴＰ）によって測定されたプラットフォームの完全性メトリックの認証された値３５２を少なくとも含む。証明書３５０は、トラステッド・デバイス２４に記憶される前に、ＴＰの秘密鍵を使用してＴＰによって署名が行われる。後の通信セッションにおいて、プラットフォーム１０のユーザは、取得された完全性メトリックを真正の完全性メトリック３５２と比較することによって、プラットフォーム１０の完全性（ｉｎｔｅｇｒｉｔｙ）を確認することができる。一致するものが存在する場合、ユーザは、プラットフォーム１０が破壊（ｓｕｂｖｅｒｔ）されていないことを確信することができる。ＴＰの一般に入手可能な公開鍵を知ることにより、証明書３５０を簡単に確認（ｖｅｒｉｆｉｃａｔｉｏｎ）することができる。不揮発性メモリ３はまた、アイデンティティ（ＩＤ）ラベル３５３をも含む。ＩＤラベル３５３は、何らかの状況（コンテキスト）内において固有である従来のＩＤラベル、例えばシリアル番号である。ＩＤラベル３５３は、一般に、トラステッド・デバイス２４に関係するデータに索引付けおよびラベル付けを行うために使用されるが、それ自体は、信頼できる条件下でプラットフォーム１０のアイデンティティを証明するには不十分である。
【００３１】
トラステッド・デバイス２４は、自らが関連するコンピューティング・プラットフォーム１０の完全性メトリックを確実に測定し、または取得する少なくとも１つの方法を備えている。この実施形態では、完全性メトリックは、ＢＩＯＳメモリにおけるＢＩＯＳ命令のダイジェスト（ｄｉｇｅｓｔ）を生成することにより、測定機能３１によって取得される。そのような取得された完全性メトリックが前述したように確認されたならば、プラットフォーム１０がハードウェア・レベルにおいてもＢＩＯＳプログラム・レベルにおいても破壊されていないという高レベルの信用を、プラットフォーム１０の潜在的なユーザに与える。他の既知のプロセス、例えばウィルス・チェッカーは、通常どおり適切に動作し、オペレーティング・システムおよびアプリケーション・プログラム・コードが破壊されていないことをチェックするであろう。
【００３２】
測定機能３１は、トラステッド・デバイス２４のハッシュ・プログラム３５４および秘密鍵３５５を記憶する不揮発性メモリ３と、取得した完全性メトリックをダイジェスト３６１の形態で記憶する揮発性メモリ４とに対するアクセスを有する。適切な実施形態では、揮発性メモリ４は、プラットフォーム１０へのアクセスを得るのに使用することができる１つまたは複数の真正のスマートカード１９ｓの公開鍵および関連するＩＤラベル３６０ａ〜３６０ｎを記憶するのにも使用することができる。
【００３３】
１つの好ましい実施形態では、ダイジェストと同様に、完全性メトリックはブール値を含み、ブール値は、以下に明白となる理由により、測定機能３１によって揮発性メモリ４に記憶される。
【００３４】
次に、完全性メトリックを取得するための好ましいプロセスを図４を参照して説明する。
【００３５】
ステップ５００において、スイッチをオンにしたとき、測定機能３１は、データ・ライン、制御ライン、およびアドレス・ライン（２６、２７、および２８）上でメイン・プロセッサ２１の活動（アクティビティ）を監視し、トラステッド・デバイス２４が、アクセスされる最初のメモリであるかどうかを判断する。従来の動作では、メイン・プロセッサは、ＢＩＯＳプログラムをまず実行するために最初にＢＩＯＳメモリに向かう。しかしながら、本発明によれば、メイン・プロセッサ２１は、メモリとして動作するトラステッド・デバイス２４に向けられる。ステップ５０５において、トラステッド・デバイス２４が、アクセスされる最初のメモリであった場合、ステップ５１０において測定機能３１は、トラステッド・デバイス２４がアクセスされた最初のメモリであったことを示すブール値を揮発性メモリ３に書き込む。ステップ５０５での判定が上記と異なる場合には、ステップ５１５において、測定機能は、トラステッド・デバイス２４がアクセスされた最初のメモリではなかったことを示すブール値を書き込む。
【００３６】
トラステッド・デバイス２４が最初にアクセスされたものでない場合、当然ながら、トラステッド・デバイス２４へのアクセスが全く行われない場合が存在する。このような場合として、例えば、メイン・プロセッサ２１がＢＩＯＳプログラムを最初に実行するように操作された場合がある。このような状況下では、プラットフォームは動作するが、オンデマンドでプラットフォームの完全性を確認することはできない。というのは、完全性メトリックが入手可能でないからである。さらに、ＢＩＯＳプログラムにアクセスが行われた後に、トラステッド・デバイス２４がアクセスされた場合には、ブール値は、プラットフォームの完全性の欠如を明示的に示す。
【００３７】
ステップ５２０において、メイン・プロセッサ２１によってメモリとしてアクセスされると（すなわち、アクセスされた場合）、ステップ５２５において、メイン・プロセッサ２１は、測定機能３１から、記憶されている固有の（ｎａｔｉｖｅ）ハッシュ命令３５４を読み取る。ハッシュ命令３５４は、メイン・プロセッサ２１による処理のためにデータ・バス２６を介して送られる。ステップ５３０において、メイン・プロセッサ２１はハッシュ命令３５４を実行し、ステップ５３５において、ＢＩＯＳメモリ２９の内容を読み取ってその内容をハッシュ・プログラムに従い処理することによって、これらのハッシュ命令を使用してＢＩＯＳメモリ２９のダイジェストを計算する。ステップ５４０において、メイン・プロセッサ２１は、計算されたダイジェスト３６１を、トラステッド・デバイス２４の不揮発性メモリ４の適切な位置に書き込む。ステップ５４５において、測定機能３１は、ＢＩＯＳメモリ２９のＢＩＯＳプログラムを呼び出し、その後、ＢＩＯＳプログラムが従来のやり方で実行される。
【００３８】
必要とされる信頼の範囲に応じて、完全性メトリックを計算することができるいくつかの異なるやり方が存在することは明らかである。ＢＩＯＳプログラムの完全性を測定することにより、プラットフォームの基礎をなす処理環境の完全性に関する基本的な検査が提供される。完全性メトリックは、ブート・プロセスの有効性に関する推論を可能にするような形態、すなわち、完全性メトリックの値を使用して、正しいＢＩＯＳを使用してプラットフォームがブートされたかどうかを確認することができる形態のものでなければならない。オプションとして、ＢＩＯＳ内の個々の機能ブロックが自分自身のダイジェスト値を有し、総体的な１つのＢＩＯＳダイジェストは、これらの個々のダイジェストのうちの１つであることができる。これにより、ポリシー（ｐｏｌｉｃｙ）は、意図する目的について、ＢＩＯＳ動作のどの部分がクリティカルであり、またどの部分が無関係であるかを明示することができるようになる（この場合、個々のダイジェストは、該ポリシーの下で動作の有効性を確立することができるようなやり方で記憶されなければならない）。
【００３９】
他の完全性検査は、プラットフォームに取り付けられた様々な他のデバイス、構成要素、または装置が存在して正常に動作する状態にあるということを証明することを伴うことができる。一例では、ＳＣＳＩコントローラに関連するＢＩＯＳプログラムを確認して、周辺機器との信頼できる通信を確保することができる。別の例では、プラットフォーム上の他のデバイス、例えばメモリ・デバイスまたはコプロセッサ（ｃｏ−ｐｒｏｃｅｓｓｏｒ）の完全性を、固定されたチャレンジ／応答の対話を実施することによって確認し、整合性のある結果を確実に得るようにすることができる。そのような形態の何らかの対話は、トラステッド・デバイス２４が別個の構成要素である場合、該トラステッド・デバイス２４とプラットフォームとの間に適切な論理的結合を提供するので望ましい。また、この実施形態では、トラステッド・デバイス２４は、プラットフォームの他の部分との通信の主な手段としてデータ・バスを利用するが、ハードワイヤド（ｈａｒｄ−ｗｉｒｅｄ）の経路または光学経路などの代替の通信経路を提供することも、それほど好都合ではないが実現可能である。さらに、この実施形態では、トラステッド・デバイス２４は、メイン・プロセッサ２１に、完全性メトリックを計算するよう命令するが、他の実施形態では、トラステッド・デバイス自体が、１つまたは複数の完全性メトリックを測定するように構成される。
【００４０】
好ましくは、ＢＩＯＳブート・プロセスは、ブート・プロセス自体の完全性を確認する機構を含む。そのような機構は、例えば、Ｉｎｔｅｌの草案「Ｗｉｒｅ ｆｏｒ Ｍａｎａｇｅｍｅｎｔ ｂａｓｅｌｉｎｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖ２．０−ＢＯＯＴ Ｉｎｔｅｇｒｉｔｙ Ｓｅｒｖｉｃｅ」で既に既知であり、ソフトウェアまたはファームウェアのダイジェストを計算した後に、該ソフトウェアまたはファームウェアをロードすることを伴う。このように計算されたダイジェストは、トラステッド・エンティティ（ｔｒｕｓｔｅｄ ｅｎｔｉｔｙ）によって提供される証明書に記憶された値と比較され、トラステッド・エンティティの公開鍵はＢＩＯＳに対して既知である。次に、該計算された値が、証明書の該期待値に一致し、かつトラステッド・エンティティの公開鍵を使用することによって証明書が有効であると証明された場合にだけ、該ソフトウェア／ファームウェアがロードされる。それ以外の場合、適切な例外処理ルーチンが呼び出される。
【００４１】
オプションとして、計算されたＢＩＯＳダイジェストを受け取った後、トラステッド・デバイス２４は、証明書におけるＢＩＯＳダイジェストの適切な値を点検し、計算されたダイジェストがその適切な値に一致しない場合、制御をＢＩＯＳに渡さないことができる。加えて、または代替的に、トラステッド・デバイス２４は、ブール値を点検して、トラステッド・デバイス２４が、アクセスされた最初のメモリではない場合、制御をＢＩＯＳに戻さないことができる。これらのケースのどちらの場合も、適切な例外処理ルーチンが呼び出されることができる。
【００４２】
次に、ユーザが、信頼できるやり方でトラステッド・プラットフォーム１０を確認することができるようにする遠隔の携帯型セキュリティ・チャレンジャ（ＰＳＣ：ｐｏｒｔａｂｌｅ ｓｅｃｕｒｉｔｙ ｃｈａｌｌｅｎｇｅｒ）について述べる。ＰＳＣは、携帯情報端末（ＰＤＡ）、モバイル電話機、スマートカード、またはバイオメトリック・リーダ（ｂｉｏｍｅｔｒｉｃｓ ｒｅａｄｅｒ）であることができる。ＰＳＣは、専用のチャレンジング・デバイスである必要はない。ＰＳＣは、完全性検査以外の付加的な機能を有することができる。相応のコンピュータ能力、ユーザ・インターフェース、ＴＤの完全性メトリックを表示するためのディスプレイ、および通信媒体を備えた任意のデバイスをＰＳＣにすることが可能であるが、ＰＳＣは、以下についての耐タンパーなストーレッジを含むことが望ましい。
【００４３】
・共用鍵、または公開鍵／秘密鍵のペア
・ＰＳＣのデータを保護するＰＩＮ
・他のサービス（例えば、ＴＤを使用する支払い）のためのオプションの鍵のペア
【００４４】
ＰＳＣは、好ましくは、以下のプロパティを有する。
・センシティブなデータ（例えば、秘密鍵）は、アクセスが制限された耐タンパーなすなわち保護されたメモリに記憶される。
・センシティブなデータは、許可された人々だけが使用することができる（例えば、パスワードによって保護される）。
・センシティブなデータは、ＰＳＣ内の他の機能、プログラム、またはプロセスによっては、開示され、変更され、削除され、またはコピーされることができない。
・ＰＳＣにおける他の機能、プロセス、またはプログラムは、完全性検査プロセスに干渉することができない。
【００４５】
ＰＳＣは、トラステッド・プラットフォーム１０のＩＭをトラステッド・デバイス２４から得るため、トラステッド・デバイス２４を含むトラステッド・プラットフォーム１０にチャレンジするのに使用される。さらに、ＰＳＣは、ＰＳＣおよびトラステッド・プラットフォーム１０のユーザを認証するのにも使用されることができる。
【００４６】
図５は、トラステッド・デバイス２４と、トラステッド・デバイス５０２を含むＰＳＣ５０１との間における双方向の認証および完全性検査を示す。
【００４７】
ユーザ認証のために利用可能な２つのオプションは、秘密鍵／公開鍵のペアを備えたＰＳＴと、ＴＤとの対称共有鍵を有するＰＳＴである。
【００４８】
両方のオプションについて良好な鍵管理方式が非常に重要であり、例えば、鍵を生成する際、鍵を取り消す際、鍵を破壊する際などに従うべき手順が存在すべきである。
【００４９】
第１のオプションの場合、秘密鍵／公開鍵のペアを導入する必要がある。ＰＳＣ５０１に導入されるＴＤ５０２により、ＴＤ５０２に導入される鍵のペアを使用することができるようになる。ＴＤ５０２を使用することの別の利点は、ＴＤ５０２が、耐タンパーを提供することである。
【００５０】
しかしながら、ＰＳＣが、鍵をセキュアなメモリに記憶して認証および完全性検査を行うことができる場合、ＰＳＣにＴＤを導入することは必須ではない。しかしながら、ＴＤを導入すれば、ＰＳＣの完全性をチェックすることもできるようになる。
【００５１】
チャレンジ（すなわち、ＴＤのＩＭに対する要求を起動すること、および／または、ユーザの認証を起動すること）は、ネットワークまたはインターネットを介して行うことができ、したがって、ＰＳＣ５０１の認証（および、オプションとして、トラステッド・プラットフォーム１０におけるＴＤ２４の認証）は、セキュアなプロトコルを使用して行う必要があり、セキュリティのレベルは、アプリケーションに依存する。ＰＳＣ５０１およびＴＤ２４が互いを認証した後に、ＴＤ２４は、そのＩＭをＰＳＣ５０１に送る。その後、ＰＳＣ５０１のユーザは、ＴＤ２４を信頼してＴＤ２４上のサービスを使用するかどうかを決定することができる。
【００５２】
第１のオプション（秘密鍵／公開鍵）を使用することの１つの利点は、任意の既存の公開鍵インフラストラクチャ（ＰＫＩ）に容易に組み込むことができることである。これにより、公開鍵および秘密鍵を使用して、ＴＤ２４とＰＳＣ５０１（ＰＳＣ５０１は、ＴＤを備えていても、備えていなくてもよい）の間でセキュアな通信チャネル（暗号化および署名）および認証を提供することができる。すべてのアプリケーションが暗号化および署名を使用する必要があるわけではないが、ユーザが、暗号化および署名を使用するか否かを決定することができることに留意されたい。プロトコルは、オプションの暗号化機能および署名機能を提供することができる。
【００５３】
図６は、ＰＳＣ６０１が、トラステッド・プラットフォーム１０のＴＤ２４にチャレンジを行って該ＴＤのＩＭを取得できるようにするのに使用されるプロトコルを示す。このプロトコルは、暗号化および署名用の公開鍵／秘密鍵のペアを使用する。セッション鍵（ＳＫ）は、さらなる通信のためのオプションである。プロトコルは、以下の情報を使用する。
【００５４】
ＮＰＳＣ＝ＰＳＣによって生成されるノンス（Ｎｏｎｃｅ；乱数）
ＮＴＤ＝ＴＤによって生成されるノンス
ＮＴＤ２＝ＴＤ２によって生成されるノンス
ＲｅｑＩＭ＝ＴＤの完全性メトリックの要求
ＲｅｑＩＭ２＝ＴＤ２の完全性メトリックの要求
ＥＰＳＣ＝ＰＳＣの公開鍵を使用する暗号化
ＥＴＤ＝ＴＤの公開鍵を使用する暗号化
ＥＴＤ２＝ＴＤ２の公開鍵を使用する暗号化
ＳＰＳＣ＝ＰＳＣの秘密鍵を使用する署名
ＳＴＤ＝ＴＤの秘密鍵を使用する署名
ＳＴＤ２＝ＴＤ２の秘密鍵を使用する署名
ＣｅｒｔＰＳＣ＝ＰＳＣの証明書、したがってＰＳＣの公開鍵
ＣｅｒｔＴＤ＝ＴＤの証明書、したがってＴＤの公開鍵
ＣｅｒｔＴＤ２＝ＴＤ２の証明書、したがってＴＤ２の公開鍵
ＩＤＰＳＣ＝ＰＳＣのアイデンティティ／名前
ＩＤＴＤ＝ＴＤのアイデンティティ／名前
ＩＤＴＤ２＝ＴＤ２のアイデンティティ／名前
ＳＫ＝オプションのセッション鍵
Ｈ＝ハッシュ
ＨＭＡＣ＝ハッシュ・メッセージ認証コード
ＥＳ＝共有鍵を使用する暗号化
Ｋｅｙ＝共有鍵
【００５５】
第１のメッセージＭ１　６０２が、ＰＳＣ６０１からＴＤ２４に伝送される。第１のメッセージＭ１　６０２は、ＮＰＳＣ、ＲｅｑＩＭ、およびＣｅｒｔＰＳＣを含む。第１のメッセージＭ１　６０２に応答して、ＴＤ２４は、第２のメッセージＭ２　６０３をＰＳＣ６０１に伝送する。第２のメッセージＭ２　６０３は、ＮＴＤ、ＣｅｒｔＴＤと、ＴＤの秘密鍵を使用して署名された（ＩＤＰＳＣ　　ＮＴＤ　　ＮＰＳＣ　　ＩＭ）とを含む。第２のメッセージＭ２　６０３に応答して、ＰＳＣ６０１は、第３のメッセージＭ３　６０４をＴＤ２４に伝送する。第３のメッセージＭ３　６０４は、ＩＤＰＳＣと、ＰＳＣの秘密鍵を使用して署名された（ＩＤＴＤ　　ＮＰＳＣ　　ＮＴＤ）とを含む。オプションとして、メッセージＭ３　６０４は、ＴＤの公開鍵を使用して暗号化されたＳＫ、およびＰＳＣの秘密鍵を使用して署名されたＳＫのハッシュを含むことができる。
【００５６】
このプロトコルにより、ＰＳＣ６０１は、信頼できる応答をＴＤ２４から取得することができ、またＴＤ２４に対してＰＳＣ６０１のユーザの正当性を証明することができるようになる。秘密にしておく必要があるものは何もない（オプションのＳＫを除いて）ので、Ｍ１　６０２およびＭ２　６０３を暗号化する必要がない。しかし、通信を行うものが、他のパーティに対して該通信を機密にしておくことを望む場合には、暗号化を使用することができる。
【００５７】
ＴＤ２４は、信頼できるＣＡ（ｔｒｕｓｔｅｄ ＣＡ、図示せず）を介して公開鍵を確認することができるものと想定する。これにより、証明書は、署名を確認するのに使用することができる公開鍵の真正性を提供することができる。ＴＤ２４の公開鍵と秘密鍵のペアは、裏書きの鍵（Ｅｎｄｏｒｓｅｍｅｎｔ ｋｅｙ）のペア（マスターキーのペア）であってはならず、ＴＤ２４の所有者によって生成された鍵のペアでなければならない。この理由は、秘密鍵が漏洩した場合に、ユーザが、鍵のペアを取り消すことができるからである。
【００５８】
図７は、ＰＳＣ７０１が自分自身のＴＤ７０２を含む場合に、ＰＳＣ７０１が、ＴＤ２４にチャレンジしてＴＤのＩＭを取得できるようにするのに使用されるプロトコルを示す。
【００５９】
第１のメッセージＭ１　７０３が、ＰＳＣ７０１からＴＤ２４に伝送される。第１のメッセージＭ１　７０３は、ＮＴＤ２、ＲｅｑＩＭ、およびＣｅｒｔＴＤ２を含む。第１のメッセージＭ１　７０３に応答して、ＴＤ２４は、第２のメッセージＭ２　７０４をＰＳＣ７０１に伝送する。第２のメッセージＭ２　７０４は、ＮＴＤ、ＣｅｒｔＴＤ、ＲｅｑＩＭ２と、ＴＤの秘密鍵を使用して署名された（ＩＤＴＤ２　　ＮＴＤ　　ＮＴＤ２　　ＩＭ）とを含む。第２のメッセージＭ２　７０４に応答して、ＰＳＣ７０１は、第３のメッセージＭ３　７０５をＴＤ２４に伝送する。第３のメッセージＭ３　７０５は、ＩＤＴＤ２と、ＰＳＣの秘密鍵を使用して署名された（ＩＤＴＤ　　ＮＴＤ２　　ＮＴＤ　　ＩＭ２）とを含む。オプションとして、メッセージＭ３　７０５は、ＴＤの公開鍵を使用して暗号化されたＳＫ、およびＰＳＣの秘密鍵を使用して署名されたＳＫのハッシュを含むことができる。
【００６０】
オプションのＴＤ２　７０２が設けられている場合、すべてのチャレンジ・プロセスは、ＴＤ２　７０２によって行われ、その場合、双方のパーティが、図７のプロトコルを使用して互いのＩＭを獲得する（互いのＩＭにチャレンジする）ことができるが、ＴＤ２　７０２にチャレンジするか否かは、アプリケーションに依存する。
【００６１】
ＴＤ２は、別のトラステッド・デバイスであるが、このデバイスを使用するか否かは、ユーザおよびアプリケーションに依存してオプションである。
【００６２】
このモデルで行われる可能性がある攻撃（ａｔｔａｃｋ）の１つは、攻撃側がＩＭをメッセージ２（Ｍ２）に含めることができる場合、該攻撃側がＴＤであるかのように装うことができることである。また、ＴＤのサービスに誰がアクセスできるかの規制が存在せず、有効な証明書（公開鍵）を有する場合には誰でもそのサービスにアクセスすることができる。
【００６３】
上記の問題の１つの解決策は、トラステッド・デバイス（ＴＤ）だけに証明書を与える信頼できるＣＡを有することである。また、任意の特定のＴＤのユーザまたはチャレンジャが、自身の公開鍵を特定のＴＤに事前に登録しなければならず、そうすることにより、該ＴＤは、Ｍ１に含まれる証明書を比較することによって、ユーザが、登録された／許可されたユーザであるかどうかを検査することができる。
【００６４】
上記の問題の別の解決策は、秘密鍵／公開鍵のペアを使用せず、異なるプロトコルを備えた対称暗号化（ｓｙｍｍｅｔｒｉｃ ｃｒｙｐｔｏｇｒａｐｈｙ）を使用することであるが、チャレンジの前に共有鍵を合意で決めなければならない。ＰＳＣ８０１およびＴＤ２４が共有鍵を導入した後、ＰＳＣ８０１は、図８で示したプロトコルを使用してＴＤ２４にチャレンジすることができる。チャレンジの目的は、ＰＳＣ８０１のアイデンティティをＴＤ２４に対して証明し（ユーザの正当性を証明し）、ＩＭについて信頼できる応答を提供することである。
【００６５】
第１のメッセージＭ１　８０２が、ＰＳＣ８０１からＴＤ２４に伝送される。第１のメッセージＭ１　８０２は、ＮＰＳＣ、ＲｅｑＩＭ、およびＩＤＰＳＣを含む。第１のメッセージＭ１　８０２に応答して、ＴＤ２４は、第２のメッセージＭ２　８０３をＰＳＣ８０１に伝送する。第２のメッセージＭ２　８０３は、ＮＴＤ、ＩＭ、ＩＤＴＤと、ハッシュ・メッセージ認証コードを使用して署名された（Ｋｅｙ　ＮＴＤ　　ＮＰＳＣ　　ＩＭ）とを含む。第２のメッセージＭ２　８０３に応答して、ＰＳＣ８０１は、第３のメッセージＭ３　８０４をＴＤ２４に伝送する。第３のメッセージＭ３　８０４は、ＩＤＰＳＣと、ハッシュ・メッセージ認証コードを使用して署名された（ＩＤＴＤ　　ＮＰＳＣ　　Ｋｅｙ　ＮＴＤ）を含む。オプションとして、メッセージＭ３　８０４は、共有鍵を使用する暗号を使用して暗号化されたＳＫ、およびハッシュ・メッセージ認証コードを使用して署名されたＳＫのハッシュを含むことができる。
【００６６】
ＴＤ２４は、自分自身の秘密鍵／公開鍵のペアを有するので、メッセージ２（Ｍ２）を、ＮＴＤ　ＣｅｒｔＴＤ　ＳＴＤ（ＩＤＰＳＣ、ＮＴＤ、ＮＰＳＣ、ＩＭ）で置き換えることができる。
【００６７】
非対称システムと同様に、オプションとして、トラステッド・デバイスＴＤ２　９０２をＰＳＣ９０１に導入して、双方のパーティが互いのＩＭを検査できるようにすることができる。ただし、この場合、対称暗号化が使用される。この実施形態のプロトコルを図９に示す。
【００６８】
第１のメッセージＭ１　９０３が、ＰＳＣ９０１からＴＤ２４に伝送される。第１のメッセージＭ１　９０３は、ＮＴＤ２、ＲｅｑＩＭ、およびＣｅｒｔＴＤ２を含む。第１のメッセージＭ１　９０３に応答して、ＴＤ２４は、第２のメッセージＭ２　９０４をＰＳＣ９０１に伝送する。第２のメッセージＭ２　９０４は、ＮＴＤ、ＩＭ、ＣｅｒｔＴＤ、ＲｅｑＩＭ２と、ハッシュ・メッセージ認証コードを使用して署名された（Ｋｅｙ　ＮＴＤ　　ＮＴＤ２　　ＩＭ）を含む。第２のメッセージＭ２　９０４に応答して、ＰＳＣ９０１は、第３のメッセージＭ３　９０５をＴＤ２４に伝送する。第３のメッセージＭ３　９０５は、ＩＤＴＤ２と、ハッシュ・メッセージ認証コードを使用して署名された（ＩＤＴＤ　　ＮＴＤ２　　Ｋｅｙ　ＮＴＤとを含む。オプションとして、メッセージＭ３　９０５は、共有鍵を使用する暗号を使用して暗号化されたＳＫ、およびハッシュ・メッセージ認証コードを使用して署名されたＳＫのハッシュを含むことができる。
【００６９】
必要とされる認証のレベルは、ＴＤのどのサービスをユーザが使用することを望むかに依存する。一部のサービス、例えばＴＤを支払いプロセスの一環として使用することは、相互認証（ユーザおよびＴＤの正当性を証明する）を必要とする。しかし、一部のサービス、例えばＴＤを使用して電子メールを送信することは、単方向認証（ＴＤの正当性のみを認証する）だけしか必要としない。ただし、ＴＤによって提供される何らかのサービスをユーザが使用できる前に、該ＴＤは、ユーザに関する詳細を有し、どのユーザが何のサービスにアクセスすることができるかを規定する何らかのルールを設定すべきである。
【００７０】
一部のユーザは、ＴＤとの共有鍵を全く有していないが、それでも、ユーザは、ＩＭを検査し、ＴＤのサービスを使用することを望むか否かを調べることができる。ユーザは、ＴＤとの共有鍵を有しておらず、またＴＤに登録した公開鍵も有していないので、ＴＤは、そのユーザ（ＰＳＣ）を認証することができない。しかし、これらのユーザは、ＴＤ上の限られたサービスを使用することだけしか許されないので、簡単なＩＭチャレンジ・プロトコルで十分である。適切なプロトコルの例を図１０に示す。
【００７１】
第１のメッセージＭ１　１００２が、ＰＳＣ１００１からＴＤ２４に伝送される。第１のメッセージＭ１　１００２は、ＮＰＳＣ、ＲｅｑＩＭ、およびＩＤＰＳＣを含む。第１のメッセージＭ１　１００２に応答して、ＴＤ２４は、第２のメッセージＭ２　１００３をＰＳＣ１００１に伝送する。第２のメッセージＭ２　１００３は、ＩＭと、ＴＤの秘密鍵およびハッシュ・メッセージ認証コードを使用して署名された（ＩＤＰＳＣ　　ＮＰＳＣ　　ＩＭ）を含む。
【００７２】
以上、これらのプロトコルは、完全性検査および認証プロセスにおいて非常に重要である。良好なプロトコルなしには、完全性メトリックに関して信頼できるレポートを生成することが不可能である。
【図面の簡単な説明】
【図１】本発明の実施形態を実現することができるシステムを示す図。
【図２】スマートカード・リーダを介してスマートカードと通信し、また一群のモジュールと通信するように構成されたトラステッド・デバイスを含むマザーボードを示す図。
【図３】トラステッド・デバイスをより詳細に示す図。
【図４】コンピューティング装置の完全性メトリックを取得するのに関連するステップを示す流れ図。
【図５】携帯型セキュリティ・チャレンジャを使用する相互完全性検査を示す図。
【図６】携帯型セキュリティ・チャレンジャと、公開鍵／秘密鍵ペアを有するトラステッド・デバイスとの間の相互完全性検査を示す図。
【図７】コンピューティング装置（トラステッド・デバイス）とトラステッド携帯型セキュリティ・チャレンジャとの間の相互完全性検査を示す図である。
【図８】共有秘密鍵を使用している際のコンピューティング装置（トラステッド・デバイス）と携帯型セキュリティ・チャレンジャとの間におけるプロトコルの例を示す図。
【図９】共有秘密鍵を使用している際のコンピューティング装置（トラステッド・デバイス）とトラステッド携帯型セキュリティ・チャレンジャとの間における相互完全性検査を示す図。
【図１０】ユーザを認証する必要がない場合のコンピューティング装置（トラステッド・デバイス）とトラステッド携帯型セキュリティ・チャレンジャとの間におけるプロトコルの例を示す図。
【符号の説明】
１０　　プラットフォーム
２４　　トラステッド・デバイス
５０１、６０１、７０１、８０１、９０１、１００１　　ＰＳＣ
【図１】
2004508619.tif 000003
【図２】
2004508619.tif 000004
【図３】
2004508619.tif 000005
【図４】
2004508619.tif 000006
【図５】
2004508619.tif 000007
【図６】
2004508619.tif 000008
【図７】
2004508619.tif 000009
【図８】
2004508619.tif 000010
【図９】
2004508619.tif 000011
【図１０】
2004508619.tif 000012
【国際公開パンフレット】
2004508619.tif 000013
2004508619.tif 000014
2004508619.tif 000015
2004508619.tif 000016
2004508619.tif 000017
2004508619.tif 000018
2004508619.tif 000019
2004508619.tif 000020
2004508619.tif 000021
2004508619.tif 000022
2004508619.tif 000023
2004508619.tif 000024
2004508619.tif 000025
2004508619.tif 000026
2004508619.tif 000027
2004508619.tif 000028
2004508619.tif 000029
2004508619.tif 000030
2004508619.tif 000031
2004508619.tif 000032
2004508619.tif 000033
2004508619.tif 000034
2004508619.tif 000035
2004508619.tif 000036
2004508619.tif 000037
2004508619.tif 000038
2004508619.tif 000039
2004508619.tif 000040
2004508619.tif 000041
【国際公開パンフレット（コレクトバージョン）】
2004508619.tif 000042
【国際調査報告】
2004508619.tif 000043
2004508619.tif 000044
2004508619.tif 000045