JP2013519929A - 情報処理装置、情報処理システム、ソフトウェアルーチン実行方法およびリモート認証方法 - Google Patents

Abstract

マルチステークホルダーモデルによるステークホルダーのエンジン内における記憶場所と、３つの動作主を識別するさらなる証拠を提供するマルチステークホルダーモデルをサポートする装置に対するリモート認証用プロトコルとを保護する技術。

Description

本発明は、データの完全性をチェックする情報処理装置、情報処理システム、および、ソフトウェアルーチン実行方法、ならびに、機器間でのリモート認証を行うリモート認証方法に関する。

オープン性および柔軟性を維持しながらパソコンや携帯電話などの電子機器を保護するため、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ（ＴＣＧ）は作られた。Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐは、全体的なセキュリティ解決策の重要な側面である規格策定に重点的に取り組んでおり、特に、ＩＳＯ／ＩＥＣ１１８８９としても公開されている「ＴＰＭ Ｍａｉｎ Ｐａｒｔ １ Ｄｅｓｉｇｎ Ｐｒｉｎｃｉｐａｌｓ， Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．２， Ｒｅｖｉｓｉｏｎ １０３」（非特許文献１）に記載されているようなトラステッドプラットフォームモジュール（ＴＰＭ）と呼ばれるハードウェアコンピュータチップに取り組んでいる。このトラステッドプラットフォームモジュールは、特に、暗号化による情報のセキュアな格納、セキュアな環境で実行される一連の暗号化処理、および、一連の完全性メトリクスを提供するハードウェア装置である。

また、ＴＣＧのワーキンググループである携帯電話ワーキンググループ（ＭＰＷＧ）は、「ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖｅｒｓｉｏｎ １．０ １２ Ｊｕｎｅ ２００７」（非特許文献２）および「ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｖｅｒｓｉｏｎ １．０ １２ Ｊｕｎｅ ２００７」（非特許文献３）において携帯電話などの機器を対象としたＴＰＭの強化について説明し、ハードウェアＴＰＭの代わりに、ソフトウェアかハードウェアのどちらか一方で実現されても構わないモバイルトラステッドモジュール（ＭＴＭ）の仕様を定めている。

さらに、別のＴＣＧワーキンググループである仮想化プラットフォームワーキンググループ（ＶＰＷＧ）は、仮想化されたプラットフォームでＴＰＭをどのようにサポートしてもよいのか説明している。

携帯に関連する文献は、信頼性や安全性が機器の耐用年数の間保持されるということを保証するため徹底的に見直されてきており、その結果、セキュアな機器の実装を要求する人々に有用な基準を提供している。仮想化に関連する文献もまた、信頼性や安全性が仮想化処理の間保持されるということを保証するため見直されてきており、その結果、セキュアに仮想化できる機器の実装を要求する人々に有用な基準を提供している。

「Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」の特徴の１つはマルチステークホルダーモデル（ＭＳＭ）であり、多数の利害関係者（ステークホルダー）がそれら独自のモバイルトラステッドモジュールおよび周辺サービス（ＭＴＭと関連サービスとのセットはエンジンとして周知である）をそれぞれ独自にどう開発し、それらを単一機器にどうインストールしたらよいかという仕様である。例えば、機器メーカーには、信頼性や安全性を保証するＭＴＭを使用することによってシステム内の基本ハードウェア全てを制御するエンジンがある。次に、キャリアエンジンはＭＴＭで保護されたよりハイレベルな接続サービスを提供し、オペレータエンジンは電子メールやＳＮＳなどのＭＴＭで保護されたサービスを提供し、そして最後に、バンキングエンジンがセキュアな信頼性のあるバンキングクライアントアプリケーションなどのＭＴＭで保護されたバンキングサービスを提供する。第１エンジンが、第２エンジンにサービスを要求するか、または、機能を第２エンジンに渡しても構わない。このようなＭＳＭベースのシステムを実現するためには、仮想化を用いてもよく、ＡＲＭ社のＴｒｕｓｔＺｏｎｅやソフトウェアに別のエンジンのＭＴＭを有するシステムオンチップ（ＳｏＣ）ソリューションなどのハードウェアでサポートされた信頼性のある環境またはハードウェアに機器メーカーの基本ＭＴＭを実装しても構わない。あるいは、セキュリティが強化されたオペレーティングシステムのカーネルモードで、または、オペレーティングシステムが提供する通常アプリケーション実行環境ですら、仮想化せずにエンジンのＭＴＭを実行することが可能であろう。

「ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」の提言によると、プログラムコードのみ完全性をチェックすべきであって、データの完全性はそのデータを用いるコードの機能であるはずである。なぜなら、「Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」で述べられているように、何が「良い」データなのか予め決定することは実質的に不可能（ゆえに、良いデータへの変化を防ぐ）であり、また、何が「悪い」データなのか事後に決定することも実質的に不可能（ゆえに、反応をもたらす）だからである。

米国特許第７４５７９５１号明細書

TPM Main Part 1 Design Principals, Specification Version 1.2, Revision 103 TCG Mobile Reference Architecture version 1.0 12 June 2007 TCG Mobile Trusted Module Specification version 1.0 12 June 2007

Ｐｒｏｕｄｌｅｒらによる米国特許第７４５７９５１号明細書（特許文献１）では、信頼性のある環境に属するメモリに格納される場合にはデータは変化しないはずであると仮定し、記憶媒体において統計的に有意でない欠陥（いわゆるビット崩壊であって、経年、電気的スパイク、または宇宙線によっても反転するランダムビットの傾向）と有意な変化を分別することによりデータの良し悪しを決定することで上記の課題を対処しようとしているが、警告表示を生成する以外の何らかの手段で有意だが予期されるデータの変化に対応する方法については何も言及していない。

しかしながら、ソフトウェアに実装されたＭＴＭに格納されているプラットフォーム設定レジスタ（ＰＣＲｓ）などのデータに対しては、数少ない特定のＡＰＩだけがこれらのＰＣＲを変更することができるので、良いデータと悪いデータとを分別できる可能性が高く、良い変化はこれらのＡＰＩの実行中にのみ生じるはずである。

したがって、変化が生じると予期される場合にデータを変更できるが、予期される間隔外でデータ変化を検出してデータの信頼性を維持できる、データメモリのブロックの完全性をチェックする方法が必要である。

また、ＰＣＲを変更するこれらの特定ＡＰＩは、ＡＰＩに対するパラメータで記述された方法により動作するため、特定ＡＰＩ中にのみ変化を許可するだけでなく、特定ＡＰＩ中にのみ予期される変化を許可することも可能である。

さらに、ＰＣＲを変更するＡＰＩの結果を予測して、予期されるＰＣＲの変化のみ実際に生じていることを完全性監視ソフトウェアが検証できる方法が必要である。

ＴＣＧによるＭＴＭのもう１つ重要な特徴はリモート認証できること、つまり、ＰＣＲに保持された完全性メトリクスの記述通りに第三者のチャレンジャーがＭＴＭの現状を問い合わせることができることである。返された状態は、リプレーアタックを防ぐためにノンスと組み合わせられ、ＭＴＭが保持していたキーで署名されて第三者証明機関（ＣＡ）により証明される。しかしながら、ＰＣＲ完全性メトリクスはプラットフォームの状態に関する情報を含んでいるが、リモート認証の結果の機密性に対する保護はない。

ゆえに、ステークホルダーのエンジンがリモート認証の実行を希望する第三者へ認証暗号化キーを提供する方法がさらに必要である。また、この認証暗号化キーが他の認証暗号化キーとは別個に無効化される方法も必要である。

マルチステークホルダーモデルにおいては、ステークホルダーのエンジンのＭＴＭを認証するだけでなく、ステークホルダーのエンジンが実行されている環境を検証するために機器メーカーのエンジン内のＭＴＭも認証する必要があるかもしれない。しかしながら、２つの異なるステークホルダーから２つのエンジンが提供されるため、チャレンジャーは、報告されたステークホルダーのエンジンの認証結果は信用できるものであると機器メーカーのエンジンによって保証される必要がある。このように、マルチステークホルダーモデルは、機器メーカーのエンジンが親であって、その他全てのステークホルダーのエンジンが子となる親子関係を定義する。

ゆえに、機器メーカーが検証可能である限り、チャレンジャーは、ステークホルダーから受信した認証結果が正しいことを実証するために、チャレンジャーが親機器メーカーのエンジンにチャレンジする方法がさらに必要である。

また、マルチステークホルダーモデルにおいては、子ステークホルダーのエンジンからのリモート認証後に、親機器メーカーのエンジンにチャレンジャーがリモート認証を要求する場合、親エンジンは、機器上に存在する別のステークホルダーのエンジンに関連するＰＣＲ内の完全値を返すことを希望しない可能性がある。

ゆえに、チャレンジャーがすでにリモート認証を要求した子ステークホルダーに基づき、チャレンジャーに返された、機器メーカーのエンジンのＭＴＭに保持していた完全値セットを機器メーカーのエンジンが制限する方法がさらに必要である。

したがって、データの完全性の管理および親エンジンによる子エンジン内の予測を実装する方法、システムおよびコンピュータプログラム製品を本願にて提案する。さらに、マルチステークホルダーモデルの環境内におけるリモート認証を実装する方法、システムおよびコンピュータプログラム製品を本願にて提案する。

大まかに言うと、本発明は、コンピュータ読み取り可能な媒体に格納されたデータを保護する改良技術に関するものである。

本発明の１つの態様は、特に、より高いレベルの信頼性および／または安全性で信頼性のある親環境に子のデータを監視させて予期せぬ変化を探すことによって、信頼性のある子環境が所有するデータを悪意あるハッカーが変更するのを防ぐために、信頼性のある子環境内に格納されたデータを保護する技術を提供することである。本発明のその他の態様は、このようなデータ保護を一時的に無効にして監視データに対する認証または予期された更新を許可する技術を提供することである。本発明のさらなる他の態様は、このような予期された更新を承認し、かつ、データモニタリングを再度有効にして更新されたデータを保護する技術を提供することである。

また、本発明のその他の態様は、特に、監視データに対して認証されたが予期せぬ更新を同時に行う悪意あるハッカーを検出するために、認証または予期された更新の結果を予測する技術を提供することである。

また、本発明のさらなる他の態様は、特に、悪意あるハッカーが信頼性のある子環境を前の状態にリセットすることを防ぐために、信頼性のある子環境における認証または予期された変化の継続的な蓄積を信頼性のある親環境内で維持する技術を提供することである。

また、本発明のさらなる他の態様は、特に、どの第三者がリモート認証を行うことが許可されるのかを制御するために、第三者に与えても構わない公開キーと秘密キーとのペアをステークホルダーが特定する技術を提供することである。

また、本発明のさらなる他の態様は、特に、子における親の信頼性をより高くするために、第三者との認証を実行したことを信頼性のある子環境が信頼性のある親環境に知らせ、かつ、子が動作を正しく表していることを親が検証する技術を提供することである。

また、本発明のさらなる他の態様は、特に、子における親の信頼性をより高くするために、信頼性のある子環境で認証が完了したことを第三者が信頼性のある親環境に知らせ、かつ、第三者の情報が子から直接受信した情報と一致することを親が検証する技術を提供することである。

また、本発明のさらなる他の態様は、特に、機器に対するプライバシー制御を向上させるために、第三者がすでに認証した子に応じて信頼性のある親環境が第三者にＰＣＲデータのサブセットのみを報告する技術を提供することである。

例えば、本発明の一態様に係る情報処理装置は、ステークホルダーエンジンが、i）実行コードを格納するプログラム格納部と、ii）メモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、機器メーカーエンジンが、i）前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェック値格納部と、ii）前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、iii）データに対して完全性チェック値を算出する完全性チェック値算出部と、iv）無効にされない場合にエラーレスポンスを呼び出す失敗処理部とを備え、前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、ａ）前記失敗処理部を無効にし、ｂ）前記格納部の前記データに要求された修正を行い、ｃ）前記格納部の前記データに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、ｄ）前記新たな完全性チェック値を前記完全性チェック値格納部に格納し、かつ、ｅ）前記失敗処理部を再び有効にする。

また、本発明の別の一態様に係る情報処理装置は、ステークホルダーエンジンが、i）実行コードを格納するプログラム格納部と、ii）メモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、機器メーカーエンジンが、i）前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェック値格納部と、ii）前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、iii）データに対して完全性チェック値を算出する完全性チェック値算出部と、iv）無効にされない場合にエラーレスポンスを呼び出す失敗処理部と、v）データ修正部による動作の結果を予測する予測部とを備え、前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、ａ）前記失敗処理部を無効にし、ｂ）前記要求の結果を予測するよう前記予測部に要求し、ｃ）前記予測結果に対して予測完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、ｄ）前記格納部の前記データに要求された修正を行い、ｅ）前記完全性チェック対象のデータに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、ｆ）新たな完全性チェック値が予測完全性チェック値と等しくなければ、エラーを記録するよう前記失敗処理部に要求し、ｇ）前記格納されている完全性チェック値を新たな完全性チェック値で更新するよう前記完全性チェック部に要求し、かつ、ｈ）前記失敗処理部を再び有効にする。

また、本発明の別の一態様に係る情報処理システムは、認証キーを発行するキー発行部を有するキー発行デバイスと、リモート認証チャレンジを発行するチャレンジャー部を有するチャレンジャーデバイスと、チャレンジに応答する認証部を有する認証デバイスとを備え、ａ）前記キー発行部は前記チャレンジャーに認証キーを発行し、ｂ）前記チャレンジャー部は、前記認証キーの公開部分を用いて前記認証部にチャレンジを発行し、ｃ）前記認証部は前記チャレンジャーのチャレンジに基づき認証を行い、かつ、ｄ）前記認証部は、前記認証キーの前記公開部分で暗号化された認証結果を前記チャレンジャーに返す。

また、本発明の別の一態様に係る情報処理システムは、認証キーを発行するキー発行部を有するキー発行デバイスと、リモート認証チャレンジを発行するチャレンジャー部を有するチャレンジャーデバイスと、チャレンジに応答する第１認証部を有する認証デバイスであって、さらに、チャレンジに応答する第２認証部と、さらに、前記第１認証部が前記第２認証部と通信できるようにするコネクタ部とを有する前記認証デバイスとを備え、ａ）前記キー発行部は前記チャレンジャーに認証キーを発行し、ｂ）前記チャレンジャー部は、前記認証キーの公開部分を用いて前記第１認証部にチャレンジを発行し、ｃ）前記第１認証部は前記チャレンジャーのチャレンジに基づき第１認証を行い、ｄ）前記第１認証部は、前記認証キーの前記公開部分で暗号化された第１認証結果を前記チャレンジャーに返し、ｅ）前記コネクタ部は、前記第１認証部から前記第２認証部へ第１認証結果を伝達し、ｆ）前記チャレンジャー部は、前記第２認証部にチャレンジを発行し、ｇ）前記第２認証部は、前記チャレンジャーのチャレンジおよび前記コネクタ部を介して伝達された前記第１認証結果に基づき第２認証を行い、かつ、ｈ）前記第２認証部は、第２認証結果を前記チャレンジャーに返す。

また、本発明の別の一態様に係るソフトウェアルーチン実行方法は、完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法であって、ａ）前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、ｂ）前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、ｃ）前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、ｄ）前記失敗処理部を無効にするステップと、ｅ）前記ソフトウェアルーチンを実行するステップと、ｆ）前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、ｇ）前記完全性チェック基準値を前記新たな完全性チェック値で更新するステップと、ｈ）前記失敗処理部を再び有効にするステップとを含む。

また、本発明の別の一態様に係るソフトウェアルーチン実行方法は、完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法であって、ａ）前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、ｂ）前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、ｃ）前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、ｄ）前記失敗処理部を無効にするステップと、ｆ）前記ソフトウェアルーチンに対して予測結果を算出するステップと、ｈ）前記予測結果に対して予測完全性チェック値を算出するステップと、ｇ）前記ソフトウェアルーチンを実行するステップと、ｈ）前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、ｉ）前記新たな完全性チェック値が予測完全性チェック値と等しくなければ、前記失敗処理部を呼び出すステップと、ｊ）前記完全性チェック基準値を前記予測完全性チェック値で更新するステップと、ｋ）前記失敗処理部を再び有効にするステップとを含む。

また、本発明の別の一態様に係るリモート認証方法は、チャレンジャーデバイスとクライアントデバイスとの間でリモート認証を行う方法であって、ａ）前記クライアントデバイスが使用可能な前記チャレンジャーデバイスに認証キーを発行するキー発行デバイスを提供するステップと、ｂ）前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の認証部を提供するステップであって、前記認証の要求が前記キー発行デバイスが発行した認証キーの公開部分を有するステップと、ｃ）認証結果を得るために前記認証部において認証を行うステップと、ｄ）認証キーの前記公開部分で前記認証結果を暗号化するステップと、ｅ）前記暗号化された認証結果を前記チャレンジャーに返すステップとを含む。

また、本発明の別の一態様に係るリモート認証方法は、チャレンジャーデバイスとクライアントデバイスとの間でリモート認証を行う方法であって、ａ）前記クライアントデバイスが使用可能な前記チャレンジャーデバイスに認証キーを発行する第１キー発行デバイスを提供するステップと、ｂ）前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の第１認証部を提供するステップであって、前記認証の要求が前記第１キー発行デバイスが発行した認証キーの公開部分を有するステップと、ｂ１）前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の第２認証部を提供するステップと、ｃ）前記第１認証部が前記第２認証部と通信できるようにするコネクタ部を提供するステップと、ｄ）第１認証結果を得るために前記第１認証部において認証を行うステップと、ｅ）前記認証キーの前記公開部分で前記第１認証結果を暗号化するステップと、ｆ）前記暗号化された第１認証結果を前記チャレンジャーに返すステップと、ｇ）前記コネクタ部は、前記第１認証部から第２認証部へ、前記第１認証結果を含むメッセージを伝達するステップと、ｈ）第２認証結果を得るために前記第２認証部において認証を行うステップと、ｉ）前記第２認証結果を前記チャレンジャーに返すステップとを含む。

本発明のその他の態様および利点は、本発明の原理を例として説明する図面とともに以下の詳細な説明から明らかになるであろう。

本発明によれば、データの改ざんを防止することができ、データの信頼性を維持することができる。

後述の好ましい実施形態の詳細な説明を以下の図面と共に考察することで、本発明のよりよい理解が得られる。
図１は、先行技術にかかるモバイル機器である。 図２は、本発明にかかるモバイル機器である。 図３は、先行技術にかかるエンジン証明書である。 図４は、エンジン間相互作用のタイムラインである。 図５は、スタートアップ時の動作である。 図６は、子エンジンテーブルである。 図７は、タイマーイベント時の動作である。 図８は、ＡＰＩエントリ時におけるフック関数の動作である。 図９は、ＡＰＩ終了時におけるフック関数の動作である。 図１０は、置換用エンジン証明書の作成について示す。 図１１は、その他の実施形態にかかるタイマーイベント時の動作である。 図１２は、その他の実施形態にかかるＡＰＩ終了時におけるフック関数の動作である。 図１３は、その他の実施形態にかかる子エンジンテーブルである。 図１４は、その他の実施形態にかかるＡＰＩエントリ時におけるフック関数の動作である。 図１５は、動作結果の予測について示す。 図１６Ａは、その他の実施形態にかかるタイマーイベント時の動作である。 図１６Ｂは、その他の実施形態にかかるタイマーイベント時の動作である。 図１７は、その他の実施形態にかかるＡＰＩ終了時におけるフック関数の動作である。 図１８は、エンジン証明書の置換について示す。 図１９Ａは、先行技術にかかるリモート認証について示す。 図１９Ｂは、先行技術にかかるリモート認証について示す。 図２０Ａは、本発明にかかるリモート認証について示す。 図２０Ｂは、本発明にかかるリモート認証について示す。 図２１は、先行技術にかかるＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ構造体である。 図２２Ａは、ＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹの読み込みおよび検証について示す。 図２２Ｂは、ＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹの読み込みおよび検証について示す。 図２３Ａは、本発明にかかるリモートマルチステークホルダー認証について示す。 図２３Ｂは、本発明にかかるリモートマルチステークホルダー認証について示す。 図２４Ａは、本発明にかかるリモートマルチステークホルダー認証について示す。 図２４Ｂは、本発明にかかるリモートマルチステークホルダー認証について示す。 図２５は、報告された引用値の検証について示す。 図２６は、保留認証テーブルである。 図２７は、チャレンジャーによって発行された子認証結果の検証について示す。 図２８は、使用済みの子認証結果の削除について示す。 図２９は、子エンジンＰＣＲアクセステーブルである。 図３０は、その他の実施形態にかかるリモートマルチステークホルダー認証製造について示す。 図３１は、その他の実施形態にかかるリモートマルチステークホルダー認証について示す。

以下に、本発明の好ましい実施形態を説明する。

図１は、完全性をチェックする機能性に重点を置いた、機器メーカー（ＤＭ）のエンジンと２つのステークホルダーのエンジンとを備えたシステムの場合の「ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」の実施形態にかかるマルチステークホルダーモデル先行技術である。マルチステークホルダーモデルの一実施形態において、第１のステークホルダーはモバイルサービスキャリアであり、第２のステークホルダーはモバイルサービスオペレーターである。まず最初に、後述するコンポーネントから構成されるモバイル装置１００がある。下から、中央処理装置、つまりＣＰＵ１０２と、ＰＣＲ０からＰＣＲ３１までのプラットフォーム設定レジスタ１０６を含む機器メーカーのモバイルトラステッドモジュール１０４と、機器ハードウェア１０８がある。そして、信頼性のルート１１２と、ハードウェア１０８用のハードウェアドライバ１１４と、当該システムにおいて他のコンポーネントが使用するメーカーによって提供された様々な機器メーカーサービス１１６とを含む機器メーカーエンジン１１０がある。ＤＭ ＭＴＭ１０４およびＰＣＲ１０６は、異なるコンポーネントにおいて必ずしも必要ではないが、機器メーカーエンジン１１０のソフトウェアまたはファームウェアに実装されてもよいと当業者であれば分かるであろう。そして、ＤＭチェッカー１１８があり、「ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」の記載通り、これは、ＤＭ自身のエンジン内サービスの完全性を監視するだけでなく、第１ステークホルダーエンジン１２２および第２ステークホルダーエンジン１３２内のステークホルダーチェッカー１２４および１３４の完全性も監視する。これらのステークホルダーチェッカー１２４および１３４は、第１ステークホルダーエンジン１２２および第２ステークホルダーエンジン１３２内コンポーネントの完全性をそれぞれチェックする。ステークホルダーチェッカーの動作は、「ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」に記載されているようなＳＲＭＶＡの動作と同じである。ＤＭチェッカー１１８が完全性エラーを検出すれば、全エンジンにおいて信頼性のある全ての動作を無効にしたり、機器を再起動するなど適した行いをすることによって失敗を処理する失敗ハンドラ１２０が動作する。失敗ハンドラの動作は、「ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」に記載されているようなＴＣＧ＿Ｒｅａｃｔｉｖｅ機能の動作と同じである。

そして、第１ステークホルダーエンジン１２２は、上述のようなステークホルダーチェッカー１２４を含み、第１ステークホルダーサービス１２６の完全性をチェックする。これらのサービスは、ステークホルダーのＳＨ ＭＴＭ１ １２８とインターフェースで接続され、信頼性のあるサービスを要求に応じてクライアントに提供する。なお、第１ステークホルダーサービス１２６およびＳＨ ＭＴＭ１ １２８は、実行コードを格納するプログラム格納部の一例である。ＳＨ ＭＴＭ１ １２８は、ＰＣＲ０からＰＣＲ１５のＰＣＲセット１３０を有している。なお、ＳＨ ＭＴＭ１ １２８は、メモリデバイス内に完全性チェック対象のデータを格納するデータ格納部の一例である。ＴＣＧ仕様書では、信頼性のある単一モジュール内の最低ＰＣＲ数についてしか述べていないため、本発明の実施形態は信頼性のあるモジュールにつき適度にＰＣＲを有すればよい。第２ステークホルダーエンジン１３２は、同様の構造であり、ステークホルダーチェッカー１３４と、第２ステークホルダーサービス１３６と、ＳＨ ＭＴＭ２ １３８と、ＰＣＲ０からＰＣＲ２３ １４０とを有する。図１では異なるエンティティとして３つのエンジン１１０、１２２および１３２を示しているが、それらの区別は、単なる論理的な区分であっても、異なる仮想マシンのそれぞれであっても構わず、また、プロセス分離を政策に基づいて実施しても、上記または当該技術分野において周知の他の技術を組み合わせても構わない。３つのエンジンの実装にかかわらず、機器メーカーエンジン１１０がより信頼できる親であってステークホルダーエンジン１２２および１３２が信頼性に劣る子である論理階層も存在する。なお、機器メーカーエンジン１１０は、ステークホルダーエンジン１２２および１３２よりも強い権限で動作可能である。言い換えると、機器メーカーエンジン１１０は、ステークホルダーエンジン１２２および１３２が実行するソフトウェアルーチンより強い権限で動作する完全性チェック部を有する。当該図において、点線矢印を使うことによって、より信頼できるコンポーネントが信頼性に劣るコンポーネントの完全性チェックを行うことを示している。これらの完全性チェックは非同期的に行われてもよい。「ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」で定義されているように、完全性チェックは、保護するデータの暗号化ハッシュを算出してその値と基準値とを比較することによって行われる。

図２は、図１で述べた先行技術に基づく、本発明にかかるマルチステークホルダーモデルである。ＤＭチェッカー１１８およびステークホルダーチェッカー１２４および１３４によってサポートされるような完全性をチェックする既存の機能性は維持されるが、さらに、エンジンチェッカー２００を加えて、子ステークホルダーエンジン１２２および１３２内に親の機器メーカーエンジン１１０による追加データの完全性メンテナンスを実装した。本発明によると、第１ステークホルダーＭＴＭ１２８および第２ステークホルダーＭＴＭ１３８はソフトウェアに実装され、ＰＣＲセット１３０および１４０は非ハードウェア保護メモリに実装される。エンジンチェッカー２００は、ＰＣＲセット１３０および１４０の予期せぬ変化を検出するために用いられる完全性基準値を格納するエンジン証明書２０２を用いて、ステークホルダーのエンジンのＭＴＭのＰＣＲ１３０および１４０の完全性を非同期的に監視する。もし予期せぬ変化が検出されれば、失敗ハンドラ１２０を用いて失敗例を処理する。なお、エンジン証明書２０２は、完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェック値格納部の一例である。また、エンジンチェッカー２００は、完全性チェック値格納部の基準値に対してデータの完全性をチェックする完全性チェック部の一例である。さらに、エンジンチェッカー２００は、データに対して完全性チェック値を算出する完全性チェック値算出部の一例でもある。例えば、完全性チェック値算出部の一例であるエンジンチェッカー２００は、暗号化ハッシュ値を算出する。また、失敗ハンドラ１２０は、無効にされない場合にエラーレスポンスを呼び出す失敗処理部の一例である。

図３は、先行技術にかかるエンジン証明書の構造体である。このエンジン証明書のフォーマット３００は先行技術である携帯電話ワーキンググループのＲＩＭ証明書の構造体のフォーマットと同一であるが、いくつかのフィールドは違って解釈される。まず、ｔａｇフィールド３０２、ｌａｂｅｌフィールド３０４およびｒｉｍＶｅｒｓｉｏｎフィールド３０６は予め定義された意味のままである。好ましい形態では、ｌａｂｅｌフィールド３０４には「ＳｈＥｘｘ＿ｙｙ」を用いる。ここで、文字「ＳｈＥ」はこの証明書がステークホルダーのエンジンデータ証明書であることを示し、「ｘｘ」は特定のステークホルダーのエンジンを表す数値識別子であり、「ｙｙ」はエンジン内のどの特定データ項目を保護中なのかを表す数値識別子である。ｒｉｍＶｅｒｓｉｏｎフィールド３０６は、再起動後にゼロで始まるカウンターを含んでおり、所定のｌａｂｅｌの新たなエンジン証明書が更新されるたびに１ずつ増える。ｒｅｆｅｒｅｎｃｅＣｏｕｎｔｅｒ３０８は単調カウンタを保持すると定義されているが、好ましい形態において、この単調カウンタは必要ではない。なぜなら、単調カウンタはリソースを共有かつ制限するものであり、証明書のカレンシーをシステムの再起動中に保存しておく必要がないため、好ましい形態ではこのカレンシーを確立する代替方法を用いるからである。ｓｔａｔｅフィールド３１０には予期されるＰＣＲ状態が記述されると定義されている。これは機器メーカーエンジン１１０の状態である。好ましい形態においては、ＰＣＲ３１またはロールバック攻撃からの保護用に用いるよう割り当てられた他のレジスタなどの状態が記述される。好ましい形態において、ｍｅａｓｕｒｅｍｅｎｔＰＣＲＩｎｄｅｘフィールド３１２は、ｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅフィールド３１４に保持されている値を用いて、拡張動作の対象としてＰＣＲ３１を表す値３１を保持する。ロールバック攻撃からの保護用にどのレジスタを用いるかの選択は、機器メーカーによってなされる。下図で詳細に示されているように、エンジン証明書２０２が監視しているデータに対する更新が行われた後、累積ハッシュ演算を機器メーカーＭＴＭ１０４の適切なＰＣＲ１０６に行うことによって、指示されたｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅ３１４がｍｅａｓｕｒｅｍｅｎｔＰＣＲＩｎｄｅｘ３１２に記述されたレジスタへ拡張される。したがって、アタッカーはステークホルダーのエンジンの状態をロールバックできず、それを保護するために用いられるエンジン証明書２０２をロールバックする。なぜなら、ｓｔａｔｅフィールド３１０に、不正なｍｅａｓｕｒｅｍｅｎｔＰＣＲＩｎｄｅｘ３１２のレジスタの値が記述されると考えられるからである。このｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅ３１４は、監視中であるステークホルダーのエンジン内のデータの代表値を保持する。好ましい形態においては、この代表値は、ＰＣＲ１３０または１４０などのデータの、周知の優れた暗号化ハッシュであり、この値を用いて監視データの完全性が危険にさらされたかどうかを検証する。多数のステークホルダーエンジンが機器上に存在する場合、当業者であれば各エンジンを異なるＰＣＲに割り当てて、その状態を記録してもよいと気づくであろう。ｐａｒｅｎｔＩＤフィールド３１６は、先行技術に記載されているような内部検証キーでｉｎｔｅｇｒｉｔｙＣｈｅｃｋＤａｔａフィールド３２４に署名していることを示す、センティネル値ＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ＿ＩＤ＿ＩＮＴＥＲＮＡＬに設定される。好ましい形態では、ｅｘｔｅｎｓｉｏｎＤｉｇｅｓｔＳｉｚｅフィールド３１８が０であるため、ｅｘｔｅｎｓｉｏｎＤｉｇｅｓｔフィールド３２０はゼロバイト長である。最後に、ｉｎｔｅｇｒｉｔｙＣｈｅｃｋＳｉｚｅフィールド３２２およびｉｎｔｅｇｒｉｔｙＣｈｅｃｋＤａｔａフィールド３２４は、先行技術で記載されているように、フィールド３０２から３２０の残りのフィールドに対する完全性チェック値を含んでいる。

図４は、本発明にかかる機器におけるイベントフローの一例である。各イベントの詳細な説明は後に示す。当該略図の左側は、ステークホルダーサービス１２６およびステークホルダーＭＴＭ１２８に関するステークホルダーエンジン１２２内のイベントシーケンスを示しており、右側は、エンジンチェッカー２００に関する機器メーカーエンジン１１０内のイベントシーケンスを示している。先行技術によると、エンジンブート４００上にはＴＰＭ＿Ｓｔａｒｔｕｐ ＡＰＩへの呼び出し４０２がある。これは先行技術で定義されているようなスタートアップ動作を行う４０４。しかし、制御を返す前に、このＡＰＩは初期エンジン証明書の作成４０６を要求するエンジンチェッカー２００のＡＰＩを呼び出す。機器メーカーのエンジン内エンジンチェッカーモジュールはエンジン証明書を作成し、ＰＣＲ値を変更する可能性があるステークホルダーのエンジンのＭＴＭ ＡＰＩをフックし、そして、エンジン証明書が監視するメモリの完全性チェック失敗を検出した際には失敗処理ルーチンを有効にする４０８。この処理の詳細は図５に示す。そして、制御をステークホルダーサービス１２６に戻す。他の動作が発生する一方、エンジン証明書が保護するメモリは変化していないことを検証する完全性チェッキングルーチンを呼び出す非同期のイベントジェネレーターが存在する。しかし、このルーチンが保護メモリにおいて変化を検出すれば失敗となり４１０、失敗ハンドラ１２０を呼び出す。

次に、ステークホルダーサービス１２６は、適切なパラメータでＭＴＭ＿ＶｅｒｉｆｙＲＩＭＣｅｒｔＡｎｄＥｘｔｅｎｄ ＡＰＩを呼び出す４１２ことによって、このステークホルダーが管理するＰＣＲセット１３０のうち１つのＰＣＲを変更することを希望する。ステークホルダーＭＴＭがその要求を処理する前に、あらかじめインストールしたフック関数を呼び出し４１４、エンジンチェッカー２００は失敗処理を無効にして４１６、ＰＣＲが変化する場合に非同期チェッキングが原因で失敗４１０とならないようにする。制御はステークホルダーＭＴＭ１２８に戻り、要求されたパラメータの検証とＰＣＲの更新を行う４１８。そして、呼び出し側へ制御を戻す前に、フック終了を呼び出し４２０、エンジンチェッカーはエンジン証明書内に保持されているハッシュ値を更新して更新されたＰＣＲを反映し、非同期チェッキング４２４における失敗処理を再び有効にする４２２。そして、呼び出し側のステークホルダーサービス１２６に制御を戻してもかまわない。

次に、ステークホルダーのエンジンがＡＰＩを介してこのステークホルダーが管理するＰＣＲセット１３０のうち１つのＰＣＲを変更できない場合の対応を説明する。ステークホルダーサービス１２６はＴＰＭ＿Ｅｘｔｅｎｄ ＡＰＩを呼び出す４２６。ステークホルダーＭＴＭがその要求を処理する前に、あらかじめインストールしたフック関数を呼び出し４２８、エンジンチェッカー２００は失敗処理を無効にして４３０、ステークホルダーのエンジン内ＰＣＲ１３０が変化する場合に非同期チェッキングが原因で失敗４２４とならないようにする。制御はステークホルダーＭＴＭ１２８に戻り、ＴＰＭ＿Ｅｘｔｅｎｄ動作を行おうと試みるが失敗する４３２。失敗通知がフック終了関数に渡されるため４３４、エンジンチェッカー２００は単に失敗処理を再び有効にするだけである４３６。なぜなら、エラーによって完全性チェック済みのＰＣＲは変化しなかったため、４２２ですでに生成されたエンジン証明書は依然、ＰＣＲの期待値を表しているからである。最後に、制御はステークホルダーサービス１２６に戻る。

なお、ステークホルダーＭＴＭ１２８は、データ格納部によって格納されているデータを修正するデータ修正部の一例である。データ修正部の一例であるステークホルダーＭＴＭ１２８は、上述のように、完全性チェック対象のデータを修正するために、プログラム格納部に格納された実行中のコードから要求を受信した場合に、ａ）失敗処理部を無効にし、ｂ）完全性チェック値格納部のデータに要求された修正を行い、ｃ）完全性チェック値格納部のデータに対して新たな完全性チェック値を算出するよう完全性チェック値算出部に要求し、ｄ）新たな完全性チェック値を完全性チェック値格納部に格納し、かつ、ｅ）失敗処理部を再び有効にする。

図５は、ＴＰＭ＿Ｓｔａｒｔｕｐ ＡＰＩの間にエンジンチェッカーを初期化するフローチャートである。左側は子ステークホルダーエンジン１２２内で生じる処理であり、右側は本発明の一部を形成する親の機器メーカーエンジンのエンジンチェッカー２００内で生じる処理である。ＴＰＭ＿Ｓｔａｒｔｕｐ ＡＰＩ ５００へのエントリ後、ＭＴＭのスタートアップ手順が先行技術で定義されたように実行される５０２。しかしながら、ルーチンは、戻る直前に、ステークホルダーが管理しているＰＣＲ１３０のメモリアドレスをＤＭエンジンへ渡す５０４。制御はＤＭエンジンのエンジンチェッカー２００へ渡され、まず最初に、呼び出し側の子ステークホルダーエンジンの識別情報を決定する５０６。好ましい形態では、呼び出し側の関数のリターンアドレスを用いて図６に示した子エンジンテーブル６００を検索する。ステークホルダーエンジン１２２と機器メーカーエンジン１１０とを区別するために選択された方法に従い、機器メーカーは、当該技術分野において周知の技術を用いて、例えばステークホルダーの仮想アドレス位置を機器メーカーの物理アドレスにマッピングする仮想環境内など呼び出し側の子のアドレスおよびＰＣＲのアドレスを変換する必要があるかもしれない。子ステークホルダーエンジンの識別情報が確定されると、ＰＣＲのメモリアドレス位置情報を子エンジンテーブル６００に付け加える５０８。次に、ＭＤ４、ＭＤ５、ＳＨＡ１、またはＳＨＡ２５６などのアルゴリズムを用いて子ステークホルダーエンジン内のＰＣＲのハッシュを算出する５１０。ＭＤ４やＭＤ５などのアルゴリズムは衝突攻撃（ｃｏｌｌｉｓｉｏｎ ａｔｔａｃｋｓ）に対して脆弱であるが、ＰＣＲのメモリサイズは固定サイズで、また、ハッシュ計測期間が比較的短いため、このような攻撃に対する範囲は限定される。また、ＨＭＡＣによって保護されるエンジン証明書に基準ハッシュが格納されている好ましい形態では、ハッシュを長期間放置する必要もないので、この基準ハッシュは攻撃に対して脆弱ではない。したがって、当業者であれば、高性能の暗号化ハッシュ関数を選択しても、安全性のためにスピードをトレードオフすることにはならないことが分かるであろう。

次のステップは、ＰＣＲの現在のハッシュに対してエンジン証明書を作成することである５１２。まず、ｔａｇ３０２をＴＰＭ＿ＴＡＧ＿ＲＩＭ＿ＣＥＲＴＩＦＩＣＡＴＥに設定する。ｌａｂｅｌ３０４は、ＰＣＲチェッキング証明書を示すように「ｘｘ」を子エンジンテーブルの値、「ｙｙ」を「００」に設定した「ＳｈＥｘｘ＿ｙｙ」に設定する。ｒｉｍＶｅｒｓｉｏｎ３０６は０に、ｃｏｕｎｔｅｒＳｅｌｅｃｔｉｏｎフィールド付のｒｅｆｅｒｅｎｃｅＣｏｕｎｔｅｒ３０８はＭＴＭ＿ＣＯＵＮＴＥＲ＿ＳＥＬＥＣＴ＿ＮＯＮＥに、ｓｔａｔｅ３１０は、このエンジンＩＤに対する子エンジンテーブル６００に示されている通りＰＣＲインデックスとＰＣＲの現在値とを表すように設定する。そして、ｍｅａｓｕｒｅｍｅｎｔＰｃｒＩｎｄｅｘ３１２は子エンジンテーブル６００に示されたＰＣＲインデックスに設定し、ｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅ３１４は５１０で算出されたハッシュに、ただし、そのハッシュ値がフィールドサイズよりも短い場合はゼロで埋めて設定する。ｅｘｔｅｎｓｉｏｎＤｉｇｅｓｔＳｉｚｅ３１８はゼロに設定してｅｘｔｅｎｓｉｏｎＤｉｇｅｓｔフィールド３２０を空にする。この構造体は、欠けているフィールドを埋めて構造体に署名するＭＴＭ＿ＩｎｓｔａｌｌＲＩＭ ＡＰＩに渡されるので、その他のフィールドは空白のままでかまわない。次に、エンジンチェッカーはエンジン証明書を定期チェックするスケジュールを立てる５１４。このチェックのスケジューリングは、ウォッチドッグタイマとＲＩＭ＿Ｒｕｎ証明書に関する「Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」および「ＴＣＧ Ｍｏｂｉｌｅ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ」の文献に記載されている。そのため、好ましい形態において、エンジンチェッカーは、このようなスケジューリングを用いて、プロセッサ要求のスパイクや他の動作の割り込みを避けるために低バックグラウンド処理としてチェックを行う。また、現在のＰＣＲ値を読み込む何らかのＭＴＭ関数の前など特定のイベントが発生する場合にはエンジン証明書をさらにチェックする。次に、エンジンチェッカーは、ＰＣＲ値を変更する可能性のある子ステークホルダーエンジンＡＰＩをフックする５１６。フックが必要なこれらのＡＰＩは、ＴＰＭ＿Ｅｘｔｅｎｄ、ＴＰＭ＿ＰＣＲ＿ＲｅｓｅｔおよびＭＴＭ＿ＶｅｒｉｆｙＲＩＭＣｅｒｔＡｎｄＩｎｓｔａｌｌなどであり、各ＡＰＩへのエントリ時および各ＡＰＩからの終了時ともに、インストールされたフックが呼び出しをエンジンチェッカーに付け加える。ＴＣＧ仕様書の特定の実装では、同様にフックが必要なＰＣＲを変更するその他の関数があってもかまわない。最後に、エンジンチェッカーは、処理失敗フラグ６１０をＴＲＵＥに設定することにより、作成されたエンジン証明書に対して失敗処理を有効にする５２０。これでエンジンチェッカーの初期化は完了するので、制御をステークホルダーのエンジンに戻して、スタートアップ手順中５０２に生成されたステータスコードを返す５２２ことによってＴＰＭ＿Ｓｔａｒｔｕｐ処理を完了する。

図６は、機器メーカーエンジンが使用する子エンジンテーブルである。子エンジンテーブル６００は４つの列で構成される。まず、エンジンＩＤフィールド６０２は、子のエンジン証明書用のｔａｇ３０２を作成するために用いる２つの文字コードを含む。したがって、テーブルの第１行目に対しｔａｇ３０２は「ＳｈＥ０１＿００」となる。エンジンアドレス範囲６０４は、子エンジンが作成されたアドレス範囲を示している。好ましい形態では、アドレス範囲は単一の連続したメモリブロックであるが、当業者であれば、連続していない複数のブロックを代わりに用いても、より複雑なアドレス方式を用いてもよいと分かるであろう。同様に、エンジンＰＣＲアドレス範囲６０６は、子ステークホルダーエンジンのＰＣＲが位置するアドレス範囲を示している。好ましい形態では、アドレス範囲は単一の連続したメモリブロックであるが、当業者であれば、子ステークホルダーエンジン自身が使用する仮想アドレスよりむしろ仮想化物理アドレスを格納する場合など、連続していない複数のブロックを代わりに用いても、より複雑なアドレス方式を用いてもよいと分かるであろう。ＤＭ ＰＣＲ６０８は、子のエンジン証明書内のｍｅａｓｕｒｅｍｅｎｔＰｃｒＩｎｄｅｘ３１２に用いられる予定の機器メーカーエンジンのＰＣＲを含んでいる。ＤＭ ＰＣＲ６０８列で示されているように、１以上の子エンジンが機器メーカーエンジン内で同じＰＣＲを共有できる。このＤＭ ＰＣＲ列では、エンジンＩＤ０１および０２はＰＣＲ３１を使用するが、エンジンＩＤ０３はＰＣＲ３０を使用する。さらに、機器メーカーエンジン内のどのＰＣＲを使用するかは機器メーカーが決定し、子エンジンは使用するＰＣＲを知っておく必要はない。処理失敗フィールド６１０は完全性失敗が強制エラーレスポンスを呼び出すべきかどうかを示している。このテーブルは機器メーカーによって管理されており、当業者であれば、テーブルの管理が行われる方法のうちの１つは、ＤＭ強制エンジンリスト用の「ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」に記載されているものと同様の方法であり、かつ、テーブルを使用するときはいつでも検証用のテーブルの基準ハッシュを格納することによってテーブルの完全性を管理してもよいと分かるであろう。

図７は、エンジンチェッカーにおけるタイマーイベントを処理するフローチャートである。その処理は全てＤＭエンジンエンジンチェッカーモジュール２００内で行われ、先行技術に記載されているようなＰＲＭＶＡ用の既存のタイマーイベント処理から呼び出された際に７００で開始する。ルーチンが完了し成功裏にイベントから戻る７０４まで、そのルーチンは子エンジンテーブル６００の各行を処理する７０２。エラー処理については後述する。前述の通り、各行に対するエンジン証明書の名前はエンジンＩＤフィールド６０２から生成され、この名前を用いて対応するエンジン証明書をＲＩＭ証明書データベース内から見つける７０６。ＲＩＭ証明書データベースとは、機器内にＲＩＭ証明書を全て格納したものであり、ＲＩＭ証明書のサブセットがエンジン証明書である。「ＴＣＧ Ｍｏｂｉｌｅ Ａｂｓｔｒａｃｔｉｏｎ ｌａｙｅｒ」には、このデータベースに保持されている証明書にアクセスするためのインターフェースが記載されている。もし証明書が見つからなければ７０８、制御を強制エラーレスポンスへ渡し７１０、先行技術に記載されているように適切に対処する。そうでない場合は、このエンジン証明書をチェックする必要があるかどうかイベントハンドラが決定する７１２。図５のステップ５１４に記載されているように、エンジンチェッカーは、エンジン証明書が保護するメモリの完全性を定期的にチェックするスケジュールを立てる５１４ので、イベントが発生するたびに全ての証明書をチェックする必要はない。チェックが必要なければ、子エンジンテーブルの次のエントリをチェックする。チェックする必要があれば、次に、エンジン証明書を検証する７１４。この検証では、ｓｔａｔｅフィールド３１０に機器メーカーのＭＴＭのＰＣＲの現状が記述されていることをチェックし、ｉｎｔｅｇｒｉｔｙＣｈｅｃｋＤａｔａフィールド３２４が有効な署名であることをチェックする。もし検証失敗であれば７１６、制御を強制エラーレスポンスへ渡し７１０、先行技術に記載されているように適切に対処する。次に、エンジンＰＣＲアドレス範囲６０６情報を用いて子エンジンのＰＣＲの暗号化ハッシュを生成し７１８、その結果をエンジン証明書のｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅフィールド３１４と比較する７２０。値が一致すれば、データは改ざんされていなかったと決定されるので、子エンジンテーブルの次のエントリが処理される７０２。しかしながら、値が一致しない場合は、処理失敗フラグ６１０をチェックする。もしフラグがＴＲＵＥであれば、制御を強制エラーレスポンスへ渡し７１０、先行技術に記載されているように適切に対処する。もしＦＡＬＳＥであれば、ハッシュエラーを無視するので、制御をイベントハンドラの先頭に戻して子エンジンテーブルの次のエントリを処理してもよい７０２。

図８は、５１６でインストールされたようなフックルーチンのエントリポイントから、子エンジンから機器メーカーのエンジンへの呼び出しを処理するフローチャートである。フックに入った後８００、呼び出し側のアドレスを決定する８０２。好ましい形態によると、呼び出しアドレスは引数として渡されるが、当業者であれば、呼び出しスタックを調べてエントリポイントを決定するなど他の方法でも可能であると分かるであろう。このアドレス（仮想環境におけるアドレス。仮想アドレスはまず物理アドレスに変換する）を用いて子エンジンテーブルのエンジンアドレス範囲６０４フィールドを検索し、呼び出し側のアドレスに該当するアドレス範囲の行を見つける８０４。一致するものが見つからなければ８０６、制御を強制エラーレスポンスへ渡し８０８、先行技術に記載されているように適切に対処する。そうでない場合は、その行の処理失敗フラグ６１０をＦＡＬＳＥに設定し８１０、ＰＣＲを変更するＡＰＩの処理を続けるために制御を呼び出し側へ戻す８１２。

図９は、５１６でインストールされたようなフックルーチンの終了ポイントから、子エンジンから機器メーカーのエンジンへの呼び出しを処理するフローチャートである。フックに入った後９００、呼び出し側のアドレスを決定する９０２。好ましい形態によると、呼び出しアドレスは引数として渡されるが、当業者であれば、呼び出しスタックを調べてエントリポイントを決定するなど他の方法でも可能であると分かるであろう。このアドレスを用いて子エンジンテーブルのエンジンアドレス範囲６０４フィールドを検索し、呼び出し側のアドレスに該当するアドレス範囲の行を見つける９０４。一致するものが見つからなければ９０６、制御を強制エラーレスポンスへ渡し９０８、先行技術に記載されているように適切に対処する。ここで、フックされたＡＰＩからのリターンコードをチェックして、そのＡＰＩが何れかのＰＣＲの変更に成功したかどうか把握する９１０。「ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」および「ＴＣＧ Ｍａｉｎ Ｐａｒｔ ３」の文献には、コマンドごとに、ＰＣＲの変更が成功したことを示すＴＰＭ＿ＳＵＣＣＥＳＳのリターンコードを含む全リターンコード候補とＰＣＲに変化がなかったことを示すその他全てのコードとが記載されている。このように、リターンコードがＴＰＭ＿ＳＵＣＣＥＳＳであれば子エンジンのＰＣＲは変化しているので、子エンジンテーブル内の当該エントリに対して置換用エンジン証明書を作成するコードが呼び出される９１２。この呼び出しの後、または、フックされたＡＰＩが失敗だった場合、現在のエントリは、処理失敗フラグをＴＲＵＥに設定させて９１４、図７に示したようなタイマーイベント中のエラー失敗処理を再起動する必要もある。

図１０は、子エンジンテーブル６００内の所定のエントリ行に対して置換用エンジン証明書を作成する１０００フローチャートであり、図４におけるエンジン証明書の更新および失敗処理の再有効化ステップ４２２について詳しく説明する。前述の通り、各行に対するエンジン証明書の名前はエンジンＩＤフィールド６０２から生成され、この名前を用いてＲＩＭ証明書データベース内から対応するエンジン証明書を見つける１００２。もし証明書が見つからなければ１００４、制御を強制エラーレスポンスへ渡し１００６、先行技術に記載されているように適切に対処する。そうでない場合は、ＭＴＭ＿ＶｅｒｉｔｆｙＲＩＭＣｅｒｔＡｎｄＥｘｔｅｎｄ ＡＰＩを用いてエンジン証明書を機器メーカーのＭＴＭに拡張する１００８。もし失敗すれば、制御を強制エラーレスポンスへ渡し１００６、先行技術に記載されているように適切に対処する。成功した場合は、エンジン証明書のｓｔａｔｅフィールド３１０を更新し１０１２、ｍｅａｓｕｒｅｍｅｎｔＰｃｒＩｎｄｅｘ３１２で示されるＰＣＲにその変化を反映させる。次に、エンジンＰＣＲアドレス範囲６０６情報を用いて子エンジンのＰＣＲの暗号化ハッシュを生成し１０１４、その結果をエンジン証明書内のｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅフィールド３１４に代入する１０１６。次に、エンジン証明書のｒｉｍＶｅｒｓｉｏｎフィールド３０６をインクリメントして１０１８エンジン証明書の新バージョンを示し、先行技術に記載されているようなＭＴＭ＿ＩｎｓｔａｌｌＲＩＭ ＡＰＩを用いて機器メーカーのＭＴＭに新たなＲＩＭ証明書へ署名するよう要求する１０２０。ＲＡＭ上の旧エンジン証明書を、「ＴＣＧ Ｍｏｂｉｌｅ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ」に記載されているＡＰＩを用いてＲＩＭ証明書データベース内の新たに生成された証明書で置換する１０２２。最後に制御を呼び出し側へ戻す１０２４。

当該システムにおける他の好ましい実施形態では、ＡＰＩが終了するまで待機してエンジン証明書を更新するわけではない。タイマーイベント中に置換用エンジン証明書を作成するフローチャートを図１１に示す１１００。このフローチャートは図７を基にしており、ＰＣＲのハッシュ値が一致しないことを検出した後に変更点となる機能が存在するが、処理失敗フラグ６１０はＦＡＬＳＥに設定される７２２。エラーを無視するのではなく、むしろ子エンジンテーブル内の当該エントリに対して置換用エンジン証明書を作成する図１０で示したようなコードを呼び出す１１０２。次に、処理失敗フラグをＴＲＵＥに設定する１１０４。このようにして、フック終了関数を呼び出すまで更新を先延ばしにするのではなく、むしろＰＣＲのさらなる変化を防ぐ。

図１２は、当該他の実施形態に対するフック終了関数のフローチャートであり、図９のフローチャートを基にしている。ＰＣＲを変更する子関数に対するフック関数１２００に１つ追加されたステップは、処理失敗フラグの状態をチェックする１２０２ことである。もしフラグがＦＡＬＳＥに設定されていれば、それはタイマーイベントがまだ実行されていないことを意味するので、置換用エンジン証明書の生成９１２を行う必要があるかもしれない。もしフラグがＴＲＵＥに設定されていれば、タイマーイベントは実行済みであり、新たなエンジン証明書が生成済みなので、追加処理は必要ない。

当該システムにおける他の好ましい実施形態では、ＡＰＩのパラメータで記述されたＰＣＲの変化しか行われていないことを確実にするために、エンジンチェッカー２００は、ＡＰＩの動作をシミュレートすることによってフックされたＡＰＩの結果を予測する。つまり、エンジンチェッカー２００は、データ修正部による動作の結果を予測する予測部の一例である。先に述べたように、フックされたＡＰＩは、ＴＰＭ＿Ｅｘｔｅｎｄ、ＴＰＭ＿ＰＣＲ＿ＲｅｓｅｔおよびＭＴＭ＿ＶｅｒｉｆｙＲＩＭＣｅｒｔＡｎｄＩｎｓｔａｌｌなどである。図１３は、図６に示されたテーブルを基にした、当該実施形態に対して機器メーカーエンジンが使用する子エンジンテーブルである。子エンジンテーブル１３００は４つの列で構成される。まず、エンジンＩＤフィールド６０２は、子のエンジン証明書用のｔａｇ３０２を作成するために用いる２つの文字コードを含む。したがって、テーブルの第１行目に対しｔａｇ３０２は「ＳｈＥ０１＿００」となる。エンジンアドレス範囲６０４は、子エンジンが作成されたアドレス範囲を示している。好ましい形態では、アドレス範囲は単一の連続したメモリブロックであるが、当業者であれば、複数の連続していないブロックを代わりに用いても、より複雑なアドレス方式を用いてもよいと分かるであろう。同様に、エンジンＰＣＲアドレス範囲６０６は、子エンジンのＰＣＲが位置するアドレス範囲を示している。好ましい形態では、アドレス範囲は単一の連続したメモリブロックであるが、当業者であれば、複数の連続していないブロックを代わりに用いても、より複雑なアドレス方式を用いてもよいと分かるであろう。ＤＭ ＰＣＲ６０８は、子のエンジン証明書内のｍｅａｓｕｒｅｍｅｎｔＰｃｒＩｎｄｅｘ３１２に用いられる予定の機器メーカーエンジンのＰＣＲを含んでいる。予測エンジン証明書フィールド１３０２には予測エンジン証明書の名前またはＮＵＬＬが保持される。ＮＵＬＬは保留中の予測がないということである。予測エンジン証明書は、図３に示したエンジン証明書用のフォーマットと同一のフォーマットである。このテーブルは機器メーカーによって管理されており、当業者であれば、テーブルの管理が行われる方法のうちの１つはＤＭ強制エンジンリスト用の「ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」に記載されているものと同様の方法であり、かつ、テーブルを使用するときはいつでも検証用のテーブルの基準ハッシュを格納することによってテーブルの完全性を管理してもよいと分かるであろう。

図１４は、５１６でインストールされたようなフックルーチンのエントリポイントから、子エンジンから機器メーカーのエンジンへの呼び出しを処理するフローチャートであり、図８の処理を基にしている。フックに入った後１４００、呼び出し側のアドレスを決定する８０２。好ましい形態によると、呼び出しアドレスは引数として渡されるが、当業者であれば、呼び出しスタックを調べてエントリポイントを決定するなど他の方法でも可能であると分かるであろう。このアドレスを用いて子エンジンテーブルのエンジンアドレス範囲６０４フィールドを検索し、呼び出し側のアドレスに該当するアドレス範囲の行を見つける８０４。一致するものが見つからなければ８０６、制御を強制エラーレスポンスへ渡し８０８、先行技術に記載されているように適切に対処する。そうでない場合は、結果予測関数を呼び出し１４０２、これが成功すれば、ＰＣＲを変更するＡＰＩの処理を続けるために制御を呼び出し側へ戻す８１２。

図１５は、所定のエンジンにおける所定のＰＣＲを変更する動作結果を予測するフローチャートである。結果予測関数へのエントリ１５００時に、対応する現在のエンジン証明書を見つける１５０２。もし証明書が見つからなければ、制御を強制エラーレスポンスへ渡し１５０６、先行技術に記載されているように適切に対処される。見つかる場合は、エンジン証明書のｓｔａｔｅフィールド３１０のサブフィールドであるｐｃｒＳｅｌｅｃｔｉｏｎに記述されている機器メーカーの現在のＰＣＲを機器メーカーのＭＴＭから読み出す１５０８。ｍｅａｓｕｒｅｍｅｎｔＰＣＲＩｎｄｅｘ３１２に記述されているＰＣＲインデックスのコピーにｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅ３１４の値を用いて合成ハッシュ計算を行うことにより、エンジン証明書に記述されている拡張動作をシミュレートする１５１０。そして、ＰＣＲのコピーは算出されたハッシュを有し、これらのハッシュは、ｓｔａｔｅフィールド３１０のサブフィールドであるｄｉｇｅｓｔＡｔＲｅｌｅａｓｅに代入される１５１２。この新たな状態を、新しいラベルとともに、すでに検索されたエンジン証明書のコピーへ与える１５１４。次に、エンジンＰＣＲアドレス範囲６０６フィールドを用いて子のＰＣＲのコピーを作成する１５１６。この関数に渡された動作を子のＰＣＲのコピー上でシミュレートする１５１８。フックされた関数の動作をシミュレートするために、先行技術にかかる動作の記述を参照する。例えば、「ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」によると、ＭＴＭ＿ＶｅｒｉｆｙＲＩＭＣｅｒｔＡｎｄＥｘｔｅｎｄ ＡＰＩは、このＡＰＩに引数として渡されるＲＩＭ証明書のｍｅａｓｕｒｅｍｅｎｔＰｃｒＩｎｄｅｘフィールドに示されたＰＣＲを、既存値プラスｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅフィールドに保持されている値に累積ハッシュ演算を行うことによって変換する。この変換は１５１６で検索された子のＰＣＲのコピーに適用される。そして、その結果得られたＰＣＲのハッシュを算出する１５２０。この新たな値は、エンジン証明書のコピーのｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅフィールドに代入され１５２２、ｒｉｍＶｅｒｓｉｏｎフィールドをインクリメントする１５２４。機器メーカーのＭＴＭ内にあるＭＴＭ＿ＩｎｓｔａｌｌＲＩＭ ＡＰＩを用いることによって、エンジン証明書のコピーは追加の署名を有し１５２６、子エンジンテーブル１３００の予測エンジン証明書フィールド１３０２にこの証明書のラベルを付け加える１５２８。最後に、新たな予測エンジン証明書をＲＩＭ証明書データベースへ保存し１５３０、ルーチンを終了する１５３２。

上述のように、予測部は、ａ）データのコピーを作成するためにデータ格納部から完全性チェック対象のデータをコピーし、かつ、ｂ）データのコピーに、予測部に対するパラメータで定義された動作を行う。

図１６Ａおよび図１６Ｂは、エンジンチェッカーにおけるタイマーイベントを処理するフローチャートである。タイマーイベントが発生すると１６００、図７に従って処理される。しかしながら、この実施形態において追加した処理は、子エンジンのＰＣＲの暗号化ハッシュを算出してエンジン証明書内のｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅフィールド３１４と比較した７２０後に行われる。失敗すると、予測エンジン証明書フィールドをチェックする１６０２。そして、このフィールドがＮＵＬＬに設定されていれば予測された変化がないので、これは予期せぬエラーであり、制御を強制エラーレスポンスへ渡し７１０、先行技術に記載されているように適切に対処する。ＮＵＬＬでない場合は関連する証明書を検索する１６０４。この検索で指名されたエンジン証明書が見つからなければ１６０６、制御を強制エラーレスポンスへ渡し７１０、先行技術に記載されているように適切に対処する。見つかった場合は、７１８で算出されたＰＣＲハッシュを図１５のエンジン証明書に格納された予測ハッシュと比較する１６０８。新たな実ハッシュが予測ハッシュと一致しなければ、制御を強制エラーレスポンスへ渡し７１０、先行技術に記載されているように適切に対処する。一致する場合は、予測変化が起こったため、制御をイベントハンドラの先頭に戻して子エンジンテーブルの次のエントリを処理してもよい７０２。

図１７は、５１６でインストールされたようなフックルーチンの終了ポイントから、子エンジンから機器メーカーのエンジンへの呼び出しを処理するフローチャートである。フックに入った後１７００、最初は図９に従い、呼び出し側のアドレスを決定する９０２。好ましい形態によると、呼び出しアドレスは引数として渡されるが、当業者であれば、呼び出しスタックを調べてエントリポイントを決定するなど他の方法でも可能であると分かるであろう。このアドレスを用いて子エンジンテーブルのエンジンアドレス範囲６０４フィールドを検索し、呼び出し側のアドレスに該当するアドレス範囲の行を見つける９０４。一致するものが見つからなければ９０６、制御を強制エラーレスポンスへ渡し９０８、先行技術に記載されているように適切に対処する。次に、予測エンジン証明書フィールド１３０２をチェックし１７０２、それがＮＵＬＬであれば、予測エンジン証明書はないので、ルーチンは戻ることができる９１６。予測エンジン証明書がある場合は、フックされたＡＰＩからのリターンコードをチェックして成功したかどうかを把握する９１０。成功していれば、子エンジンのＰＣＲは変化したので、子エンジンテーブルの当該エントリに対してエンジン証明書を予測エンジン証明書で置換するコードを呼び出す１７０４。この呼び出しの後、または、フックされたＡＰＩが失敗の場合は、子エンジンテーブルの現在のエントリは予測エンジン証明書フィールドをＮＵＬＬに設定させて１７０６、予測がもはや有効ではないことを示す必要がある。ここで、コードは呼び出し側に戻ることができる９１６。

データ修正部の一例であるステークホルダーＭＴＭ１２８は、上述のように、完全性チェック対象のデータを修正するために、プログラム格納部に格納された実行中のコードから要求を受信した場合に、ａ）失敗処理部を無効にし、ｂ）要求の結果を予測するように予測部に要求し、ｃ）予測結果に対して予測完全性チェック値を算出するよう完全性チェック値算出部に要求し、ｄ）完全性チェック値格納部のデータに要求された修正を行い、ｅ）完全性チェック対象のデータに対して新たな完全性チェック値を算出するよう完全性チェック値算出部に要求し、ｆ）新たな完全性チェック値が予測完全性チェック値と等しくなければ、エラーを記録するよう失敗処理部に要求し、ｇ）格納されている完全性チェック値を新たな完全性チェック値で更新するよう完全性チェック部に要求し、かつ、ｈ）失敗処理部を再び有効にする。

図１８は、子エンジンテーブル１３００内の所定のエントリ行に対してエンジン証明書を渡された予測エンジン証明書で置換する１８００フローチャートである。図１０に対して説明した通り、各行に対するエンジン証明書の名前はエンジンＩＤフィールド６０２から生成され、この名前を用いてＲＩＭ証明書データベース内から対応するエンジン証明書を見つける１００２。もし証明書が見つからなければ１００４、制御を強制エラーレスポンスへ渡し１００６、先行技術に記載されているように適切に対処する。そうでない場合は、ＭＴＭ＿ＶｅｒｉｔｆｙＲＩＭＣｅｒｔＡｎｄＥｘｔｅｎｄ ＡＰＩを用いてエンジン証明書を機器メーカーのＭＴＭに拡張する１００８。もし失敗すれば、制御を強制エラーレスポンスへ渡し１００６、先行技術に記載されているように適切に対処する。そうでない場合は、渡された予測エンジン証明書のｌａｂｅｌフィールド３０２を１００２で検索されたエンジン証明書のｌａｂｅｌフィールドに設定し１８０２、先行技術に記載されているようなＭＴＭ＿ＩｎｓｔａｌｌＲＩＭ ＡＰＩを用いて機器メーカーのＭＴＭに新たなＲＩＭ証明書へ署名するよう要求する１８０４。最後に、ＲＩＭ証明書データベース内の前回のエンジン証明書を予測エンジン証明書で置換し１８０６、制御を呼び出し側へ戻す１０２４。

図１９Ａは、先行技術にかかるリモート認証の概要を示す。３つの動作主は、キー証明書の発行および検証を担当するプライバシー証明機関１９０２と、モバイル機器上のステークホルダーエンジン１２２と、ステークホルダーエンジン１２２に認証を要求するチャレンジャー１９００である。これらの動作主間の３つの重要な相互作用として、まず、ステークホルダーエンジン１２２は、プライバシー証明機関において自分自身で生成するＡＩＫ証明書を登録し１９５０、そして、チャレンジャー１９００からのリモート認証要求に応答してＡＩＫで署名されたＰＣＲ状態およびプライバシー証明機関１９０２によって証明されたＡＩＫ証明書を返す１９５２。そして最後に、チャレンジャー１９００がプライバシー証明機関１９０２でＡＩＫ証明書を検証する１９５４。

図１９Ｂにおいて、先行技術にかかるリモート認証を詳細に説明する。４つの動作主は、チャレンジャー１９００として機能するリモートサービスと、プライバシー証明機関１９０２と、機器上のステークホルダーの信頼性のあるソフトウェアスタック（ＴＳＳ）や抽象化レイヤなど１９０４と、機器上のステークホルダーのＭＴＭ１９０６とである。ＴＳＳは、先行技術で説明されているような信頼性のあるモジュールとアプリケーションとのインターフェースを処理するステークホルダーサービス１２６および１３６の一部である。図１９Ａのステークホルダーエンジン１２２は、これから説明するモバイル機器の動作をさらに詳細に説明できるよう、２つの別個のコンポーネント１９０４および１９０６に分けられている。チャレンジャー１９００は、信頼性のあるコンポーネントの有無にかかわらず、機器が使用したいサービスを提供するサーバーでも、別のピア装置でも構わず、また、スマートカードなどの周辺機器や計算装置の他の形態でも構わない。段階は２つあり、第１段階のプロビジョニング１９０８では、ステークホルダーがＡＩＫ（認証識別キー）を作成してそれをプライバシーＣＡで登録する。第２段階は認証そのものである１９１０。先行技術に記載されているように、ＡＩＫは、証明された信頼性のあるモジュールによって認証要求が確かに処理されたという証拠として利用可能な公に知られた証明書を有する信頼性のあるモジュール（ＴＰＭまたはＭＴＭ）が所有するキーである。機器がＡＩＫのプロビジョニングを終了した時点で、複数の認証要求をサポートできるようになる。このプロビジョニング処理は、機器の第１起動などの時点や、認証を行いたいがＡＩＫがないことを検出するプログラムの要求時、または、ユーザが機器を「認証準備ＯＫ」として明示的に開始されたアプリケーションによる要求から行われる。ステークホルダーＴＳＳ１９０４内にＡＩＫを作成する処理が呼び出された時点で、まず、ＴＳＳは、先行技術に記載されているようなＴＰＭ＿ＭａｋｅＩｎｄｅｎｔｉｔｙ ＡＰＩを用いてＭＴＭがＡＩＫを作成するよう要求する１９１２。そして、ＴＳＳは、このキーをＸ．５０９または他のフォーマットで記述した適切なＡＩＫ証明書を作成し１９１４、その証明書をプライバシーＣＡに引き渡す１９１６。プライバシーＣＡはキー構造および機器の権限を検証し、証明書に副署してそれをステークホルダーＴＳＳへ返す。リモート認証を行うために、ステークホルダーＴＳＳへの通信経路をどのように確立するか把握しているチャレンジャーは、まずランダムにノンスを生成し１９１８、そして、認証要求におけるノンスをステークホルダーに送信する１９２０。ＴＳＳは、先行技術に記載されているようなＴＰＭ＿Ｑｕｏｔｅ２ ＡＰＩを用いて、ノンスと共にＭＴＭ内のＰＣＲのサブセットの引用にＭＴＭがＡＩＫで署名するよう要求する１９２２。１９１４で生成された署名キーに対するＡＩＫ証明書および引用結果をチャレンジャーに返す１９２４。チャレンジャーは、返されたＡＩＫを用いて署名が生成されたことを検証し１９２６、プライバシーＣＡでＡＩＫが確実に有効に署名されたＡＩＫであることを検証する１９２８。

図２０Ａは、本発明にかかるリモート認証について示す。３つの動作主は、ＡＩＫおよびその証明書およびＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹキー証明書の作成を担当するステークホルダー２０００と、モバイル機器上のステークホルダーエンジン１２２と、ステークホルダーエンジン１２２に認証を要求するチャレンジャー１９００である。チャレンジャー１９００は、リモート認証チャレンジを発行するチャレンジャー部を有するチャレンジャーデバイスの一例である。チャレンジャー部は、認証キーの公開部分を用いて認証部にチャレンジを発行する。これらの動作主間の３つの重要な相互作用として、まず、ステークホルダー２０００がＡＩＫを作成し、それをステークホルダーエンジン１２２に組み込む２０５０。ステークホルダー２０００は、認証キーを発行するキー発行部を有するキー発行デバイスの一例である。キー発行部は、チャレンジャーに認証キーを発行する。好ましい形態では、この組み込み処理は機器の製造中に行われる。次に、ステークホルダー２０００はそのＡＩＫ証明書とＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹとをチャレンジャー１９００に引き渡し２０５２、最後に、ステークホルダーエンジン１２２は、リモート認証要求に応じて、ＡＩＫで署名されたＰＣＲ状態であって、チャレンジャー１９００から送信されたＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹで暗号化されたそのＰＣＲ状態を、チェレンジャーに返す２０５４。ステークホルダーエンジン１２２は、チャレンジに応答する認証部を有する認証デバイスの一例である。認証部は、チャレンジャーのチャレンジに基づき認証を行い、かつ、認証キーの公開部分で暗号化された認証結果をチャレンジャーに返す。

図２０Ｂにおいて、本発明にかかるリモート認証を詳細に説明する。４つの動作主が、チャレンジャー１９００として機能するリモートサービスと、機器外のステークホルダーサーバー２０００と、機器上のステークホルダーの信頼性のあるソフトウェアスタック（または抽象化レイヤなど）１９０４と、機器上のステークホルダーのＭＴＭ１９０６とである。図２０Ａのステークホルダーエンジン１２２は、これから説明するモバイル機器の動作をさらに詳細に説明できるよう、２つの別個のコンポーネント１９０４および１９０６に分けられている。チャレンジャー１９００は、信頼性のあるコンポーネントの有無にかかわらず、機器が使用したいサービスを提供するサーバーでも、別のピア装置でも構わず、また、スマートカードなどの周辺機器や計算装置の他の形態でもかまわない。ステークホルダーは機器メーカーまたはマルチステークホルダーモデルで定義されたような他のステークホルダーのどちらでも構わない。段階は３つあり、第１段階の製造段階では、ステークホルダーがＡＩＫ（認証識別キー）を作成してそれを機器に組み込み２００２、第２段階のプロビジョニング２００４では、ステークホルダーが、先行技術に記載されているようにＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹを作成してそれをチャレンジャーに引き渡す。なお、認証キー（ＡＩＫ）の公開部分は、そのキーが認証デバイスに既知のキーであるという証拠を有する。認証キーの公開部分の正当性は、認証部によって確認される。また、認証キーは、認証デバイスにとって既知であるという証拠が、認証デバイスに既知の第２キー（ＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ）への参照を含んでいる。そして、第３段階は認証そのものである２００６。本発明のその他の好ましい実施形態ではＡＩＫ証明書をプライバシー証明機関で登録しているが、先行技術によると、プライバシーＣＡは必要ではない。ステークホルダーがＡＩＫを組み込んだ装置を製造し終えた時点で、１以上のチャレンジャーに対してＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ構造体のプロビジョニングをサポートできるようになる。ステークホルダーがチャレンジャーに対するＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹのプロビジョニングを終了した時点で、チャレンジャーは複数の認証要求を実行してもよい。製造プロセスは、ハードウェアの製造中や機器が顧客にリリースされる前の他の処理などの時点で行われる。プロビジョニング処理は、ステークホルダーの装置に認証チャレンジを行いたいと第三者がステークホルダーに要求した場合などの時点で行われる。製造時２００２に、ステークホルダーはＡＩＫおよび一致する証明書を作成し２００８、ステークホルダーのＭＴＭ内にＡＩＫの秘密部分を組み込む２０１０。ハードウェアＭＴＭに対し、これはセキュアなメモリへ物理的に情報を書き込むことであってもよく、ソフトウェアＭＴＭに対しては、実行ファイルへデータを投入しそれを署名することであってもよい。プロビジョニング中２００４に、ＲＶＡＩから導出される、「Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」で定義されているようなＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ２１００が作成される２０１２。ｕｓａｇｅＦｌａｇｓ２１０４をＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ＿ＵＳＡＧＥ＿ＲＥＭＯＴＥ＿ＡＴＴＥＳＴＡＴＩＯＮに設定して、暗号化認証要求に対してこのキーを用いることを示す。好ましい形態において、ｋｅｙＡｌｇｏｒｉｔｈｍフィールド２１１２は、データが対称的な暗号化アルゴリズムに対するキーであるため秘密キー部分はないことを示す。その他の好ましい形態においては、公開キーを用いるため秘密キー部分もある。指示された親キーを用いてＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ２１００構造体に署名する。好ましい形態では、この親キーはステークホルダーに秘密である。作成されたＡＩＫ証明書と、ＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹと、存在すれば、ＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹの秘密キーとを、認証チャレンジャーとして機能する第三者に引き渡す２０１４。送信されてくるデータにより受信側は認証要求の結果を把握することができるので、伝送中のデータの安全性は維持されるはずである。電子的な伝送に対し、ＳＳＬベースのシステムは移動しているデータを確実に保護すると考えられ、物理的な伝送に対しては、帯域外の異なる経路を介して一致したキーで伝送媒体上のデータを暗号化しても構わない。リモート認証２００６を行うために、ステークホルダーＴＳＳへの通信経路をどのように確立するか把握しているチャレンジャーは、まずランダムにノンスを生成し２０１６、そして、認証要求におけるそのノンスとすでにセットアップされているＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹとをステークホルダーに送信する２０１８。ｋｅｙＡｌｇｏｒｉｔｈｍ２１１２が対称的である場合、当業者であれば、ＳＳＬベースの体系を用いるなど、通信経路を保護する必要があると分かるであろう。ＴＳＳは、先行技術に記載されているようなＴＰＭ＿Ｑｕｏｔｅ２ ＡＰＩを用いて、ノンスと共にＭＴＭ内のＰＣＲのサブセットの引用に製造時に組み込まれたＡＩＫでＭＴＭが署名するよう要求する２０２０。次に、チャレンジャーから引き渡されたＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹをステークホルダーのＭＴＭに読み込み２０２２、その処理が成功したことをチェックすることで検証する。汎用的な暗号化に対しては、ＭＴＭはＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹを用いることができないため、引用動作の結果２０２０をステークホルダーのＴＳＳ内で暗号化し２０２４、チャレンジャーに返す２０２６。チャレンジャーは返されたメッセージを解読し２０２８、署名されたメッセージがすでにセットアップされているＡＩＫ証明書のキーで署名されたものであることを検証する２０３０。検証が成功すれば、ここで、チャレンジャーはステークホルダーのＭＴＭのＰＣＲの状態をリモート認証する。なお、チャレンジャー部が発行した認証チャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する。

図２１は、「ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」の先行技術にかかるＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ構造体である。まず、ｔａｇ２１０２はＴＰＭ＿ＴＡＧ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹを保持する。ｕｓａｇｅＦｌａｇｓ２１０４はＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ＿ＵＳＡＧＥ＿ＲＥＭＯＴＥ＿ＡＴＴＥＳＴＡＴＩＯＮのビットセットを有し、本発明では０ｘ１０００に定義される。ｐａｒｅｎｔＩｄ２１０６、ｍｙＩｄ２１０８、ｒｅｆｅｒｅｎｃｅＣｏｕｎｔｅｒ２１１０、ｋｅｙＡｌｇｏｒｉｔｈｍ２１１２、およびｋｅｙＳｃｈｅｍｅ２１１４は先行技術に記載されている通りである。本発明によると、拡張データは定義されていないため、ｅｘｔｅｎｓｉｏｎＤｉｇｅｓｔＳｉｚｅ２１１６およびｅｘｔｅｎｓｉｏｎＤｉｇｅｓｔ２１１８はそれぞれゼロおよび空で構わない。最後に、その他のフィールド、ｋｅｙＳｉｚｅ２１２０、ｋｅｙＤａｔａ２１２２、ｉｎｔｅｇｒｉｔｙＣｈｅｃｋＳｉｚｅ２１２４およびｉｎｔｅｇｒｉｔｙＣｈｅｃｋＤａｔａ２１２６も先行技術に記載されている通りである。好ましい実施形態によれば、ｐａｒｅｎｔＩｄ２１０６はルートキーではなく中間キーであるため、ステークホルダーは多くのＴＰＭ＿ＴＡＧ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹをセットアップすることができるが、先行技術に記載されているような中間のＴＰＭ＿ＴＡＧ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹを無効にすることによってそれら全てを無効にすることができる。

図２２Ａおよび図２２Ｂは、本発明にかかるＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹの読み込みおよび検証を示している。この図は、図２０のステップ２０２２を詳細に説明したものである。この再帰的ルーチンのエントリポイントではパラメータとして読み込まれるキーが必要である２２００。まず、ｐａｒｅｎｔＩｄフィールド２１０６をチェックしてこのキーがルートキーであることを示すＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ＿ＩＤ＿ＮＯＮＥを保持するかどうかチェックする２２０２。ルートキーでなれけば、ルーチンは所定のｐａｒｅｎｔＩｄでＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹの検索を試みる２２０４。先行技術によると、ステークホルダーは、システム上に存在するＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹの管理が求められる。親キーが見つからなければ２２０６、エラーが発生し、ルーチンはＴＰＭ＿ＫＥＹＮＯＴＦＯＵＮＤエラーコードを返す２２０８。さらに、先行技術によると、ステークホルダーは、これらのキーの失効ステータスを管理することも求められる。ゆえに、キーが見つかれば、その失効ステータスもチェックする必要がある２２１０。キーが無効になったと判断されれば、ルーチンはＴＰＭ＿ＡＵＴＨＦＡＩＬエラーコードを返す２２１２。このように、キー発行部は、認証キーに対する失効証明書を発行する。そして、認証部は、失効証明書を受信すると認証キーを無効にする。次に、親キーを読み込みかつ検証できるようルーチンに対する再帰的呼び出しを行う２２１４。つまり、認証部は、認証キーの親キーの公開部分の正当性を確認する。例えば、認証部は、さらに、認証部の状態を表す情報項目セットの値に対して認証を行う。このときの各項目は、認証部の特性を表す数値を有する。具体的には、各項目は、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したようなプラットフォーム設定レジスタ（ＰＣＲ）である。親の読み込みおよび検証が失敗すれば２２１６、ルーチンは失敗エラーコードを返す２２１８。成功した場合は、この関数に渡されたＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹをチェックしてキーがＭＴＭに読み込み済みかどうか把握する２２２０。当該分野における周知の技術、好ましくはＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ＿ＨＡＮＤＬＥへ変換するためのｍｙＩｄフィールド２１０８のマップなどを用いて、読み込まれたキーを記録する。キーが読み込み済みでなければ、ＭＴＭ＿ＬｏａｄＶｅｒｉｆｉｃａｔｉｏｎＫｅｙ ＡＰＩを呼び出し２２２２、読み込みおよび検証処理を実行する。読み込みが失敗すれば２２２４、ルーチンは失敗エラーコードを返す２２１８。成功した場合、好ましい実施形態では、ｍｙＩｄフィールド２１０８とＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ＿ＨＡＮＤＬＥとのペアを、読み込まれたキーのマップへ付け加えることによって、返されたＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ＿ＨＡＮＤＬＥを記録する２２２６。最後に、ルーチンは呼び出し側にＴＰＭ＿ＳＵＣＣＥＳＳコードを返して２２２８、再帰的呼び出しの場合は子キーの読み込みを続け、最上位の呼び出しの場合はキー階層を検証したと認証処理に報告する。

図２３Ａは、本発明にかかるリモートマルチステーク認証の概要について示す。５つの動作主は、モバイル機器上のステークホルダーエンジン１２２用のＡＩＫおよびその証明書およびＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹキー証明書の作成を担当するステークホルダー２０００と、モバイル機器上の機器メーカーエンジン１１０用のＡＩＫおよびその証明書の作成を担当する機器メーカー２３００と、２つのエンジン１１２および１１０に認証を要求するチャレンジャー１９００である。つまり、ステークホルダー２０００および機器メーカー２３００は、認証キーを発行するキー発行部を有するキー発行デバイスの一例である。また、チャレンジャー１９００は、リモート認証チャレンジを発行するチャレンジャー部を有するチャレンジャーデバイスの一例である。認証デバイスは、チャレンジに応答する第１認証部の一例であるステークホルダーエンジン１２２と、チャレンジに応答する第２認証部の一例である機器メーカーエンジン１１０とを備える。また、認証デバイスは、さらに、第１認証部が第２認証部と通信できるようにするコネクタ部を有する。これらの動作主間の重要な相互作用として、まず、ステークホルダー２０００がＡＩＫを作成し、それをステークホルダーエンジン１２２に組み込み２３５０、そして、機器メーカー２３００がＡＩＫを作成し、それを機器メーカーエンジン１１０に組み込む２３５２。好ましい形態では、この組み込み処理は機器の製造中に行われる。次に、ステークホルダー２０００はステークホルダーのＡＩＫ証明書とＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹとをチャレンジャー１９００に引き渡し２３５４、機器メーカー２３００は機器メーカーのＡＩＫ証明書をチャレンジャー１９００に引き渡す２３５６。最後に、ステークホルダーエンジン１２２は、リモート認証要求に応じて、ＡＩＫで署名されたＰＣＲ状態であって、チャレンジャー１９００から送信されたＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹで暗号化されたステークホルダーエンジンのＰＣＲ状態を、チェレンジャー１９００に返す２３５８。要するに、キー発行部はチャレンジャーに認証キーを発行し、チャレンジャー部は、認証キーの公開部分を用いて第１認証部の一例であるステークホルダーエンジン１２２にチャレンジを発行する。第１認証部は、チャレンジャーのチャレンジに基づき、第１認証を行い、認証キーの公開部分で暗号化された第１認証結果をチャレンジャーに返す。そして、機器メーカーエンジン１１０は、リモートマルチステークホルダー認証要求に応じて、ＡＩＫで署名された機器メーカーエンジンのＰＣＲ状態をチャレンジャー１９００に返す２３６０。要するに、コネクタ部は、第１認証部から第２認証部の一例である機器メーカーエンジン１１０へ第１認証結果を伝達し、チャレンジャー部は、第２認証部にチャレンジを発行し、第２認証部は、チャレンジャーのチャレンジおよびコネクタ部を介して伝達された第１認証結果に基づき第２認証を行い、かつ、第２認証結果をチャレンジャーに返す。

図２３Ｂにおいて、本発明にかかるリモートマルチステークホルダー認証に備えた製造およびプロビジョニングを詳細に説明する。ここで、チャレンジャーはステークホルダーのＭＴＭの状態を問い合わせることを希望し、そして、その結果を機器メーカーのＭＴＭで確認する。５つの動作主は、チャレンジャー１９００として機能するリモートサービスと、機器外のステークホルダーサーバー２０００と、機器上のステークホルダーのＭＴＭ１９０６と、機器外の機器メーカーサーバー２３００と、機器上の機器メーカーのＭＴＭ２３０２とである。製造時に２３０４、機器メーカーはＡＩＫおよび一致する証明書を作成し２３０８、機器メーカーのＭＴＭ内にＡＩＫの秘密部分を組み込む２３１０。なお、認証キー（ＡＩＫ）の公開部分は、そのキーが認証デバイスに既知のキーであるという証拠を有する。認証キーの公開部分の正当性は、第１認証部の一例であるステークホルダーエンジン１２２によって確認される。また、認証キーは、認証デバイスにとって既知であるという証拠が、認証デバイスに既知の第２キー（ＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ）への参照を含んでいる。ハードウェアＭＴＭに対し、これはセキュアなメモリへ物理的に情報を書き込むことであってもよく、ソフトウェアＭＴＭに対しては、実行ファイルへデータを投入しそれを署名することであってもよい。次に、ステークホルダーはＡＩＫおよび一致する証明書を作成し２３１２、ステークホルダーのＭＴＭ内にＡＩＫの秘密部分を組み込む２３１４。ハードウェアＭＴＭに対し、これはセキュアなメモリへ物理的に情報を書き込むことであってもよく、ソフトウェアＭＴＭに対しては、実行ファイルへデータを投入しそれを署名することであってもよい。プロビジョニング中２３０６に、ＲＶＡＩから導出される、「Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」で定義されているようなＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ２１００が作成される２３１６。ｕｓａｇｅＦｌａｇｓ２１０４をＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ＿ＵＳＡＧＥ＿ＲＥＭＯＴＥ＿ＡＴＴＥＳＴＡＴＩＯＮに設定して、暗号化認証要求に対してこのキーを用いることを示す。好ましい形態において、ｋｅｙＡｌｇｏｒｉｔｈｍ２１１２は、対称的なキーであるため秘密キー部分はない。その他の好ましい形態においては、公開キーを用いるため秘密キー部分もある。指示された親キーを用いてＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹ２１００構造体に署名する。好ましい形態では、この親キーはステークホルダーに秘密である。作成されたＡＩＫ証明書と、ＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹと、存在すれば、ＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹの秘密キーとを、認証チャレンジャーとして機能する第三者に引き渡す２３１８。送信されてくるデータにより受信側は認証要求の結果を把握することができるので、伝送中のデータの安全性は維持されるはずである。電子的な伝送に対し、ＳＳＬベースのシステムは移動しているデータを確実に保護すると考えられ、物理的な伝送に対しては、帯域外の異なる経路を介して一致したキーで伝送媒体上のデータを暗号化しても構わない。機器メーカーに対しては、ＡＩＫ証明書のみをプロビジョニングする２３２０。なぜなら、後述するように、機器メーカーのＭＴＭ用のＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹは必要ないからである。しかしながら、当業者であれば、他の実施形態において、機器メーカーのＭＴＭを認証するためにＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹを用いてもよいと気づくであろう。

図２４Ａおよび２４Ｂにおいて、本発明にかかるリモートマルチステークホルダー認証を詳細に説明する。ここで、チャレンジャーはステークホルダーのＭＴＭの状態を問い合わせることを希望し、そして、その結果を機器メーカーのＭＴＭに確認する。５つの動作主は、チャレンジャーとして機能するリモートサービス１９００と、機器上の信頼性のあるステークホルダーのソフトウェアスタック１９０４と、機器上のステークホルダーのＭＴＭ１９０６と、機器上の信頼性のある機器メーカーのソフトウェアスタック２４００と、機器上の機器メーカーのＭＴＭ２３０２である。ただし、これから説明するモバイル機器の動作をさらに詳細に説明できるよう、図２３Ａのステークホルダーエンジン１２２は２つの別個のコンポーネント１９０４および１９０６に、図２３Ａの機器メーカーエンジン１１０は２つの別個のコンポーネント２４００および２３０２に分けられている。図２３に示されたステークホルダーサーバー２０００および機器メーカーサーバー２３００は、実際の認証に影響を及ぼさないため、本図では図示しない。図２４Ａにおいて、ステークホルダーＴＳＳ１９０４および下層の機器メーカーＴＳＳ２４００への通信経路をどのように確立するか把握しているチャレンジャー１９００がランダムにステークホルダーノンスを生成し２４０２、そして、認証要求におけるそのノンスとステークホルダーのすでにセットアップされているＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹとをステークホルダーに送信する２４０４と、リモートマルチステークホルダー認証２００６が開始する。なお、チャレンジャー部が発行した第１認証部へのチャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する。ｋｅｙＡｌｇｏｒｉｔｈｍ２１１２フィールドがキーは対称的であると示す場合、当業者であれば、ＳＳＬベースの体系を用いるなど、通信経路を保護する必要があると分かるであろう。ステークホルダーＴＳＳは、先行技術に記載されているようなＴＰＭ＿Ｑｕｏｔｅ２ ＡＰＩを用いて、ステークホルダーノンスと共にＭＴＭ内のＰＣＲのサブセットの引用に、製造時に組み込まれたステークホルダーのＡＩＫでステークホルダーＭＴＭ１９０６が署名するよう要求する２４０６。次に、チャレンジャーから引き渡されたステークホルダーのＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹをステークホルダーのＭＴＭに読み込み２４０８、その処理が成功したことをチェックすることによって検証する。つまり、第１認証部は、認証キーの親キーの公開部分の正当性を確認する。例えば、認証部は、さらに、第１認証部の状態を表す情報項目セットの値に対して認証を行う。このときの各項目は、第１認証部の特性を表す数値を有する。具体的には、各項目は、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したようなプラットフォーム設定レジスタ（ＰＣＲ）である。ステークホルダーＴＳＳは機器メーカーＴＳＳ２４００に引用動作の結果２４０６とステークホルダーノンスを通知する２４１０。そして、機器メーカーＴＳＳは、報告された引用結果を検証し２４１２、ステークホルダーノンスとステークホルダーのＰＣＲ引用とを連結したもの、およびステークホルダーを表す識別子を格納する２４１４。これらの動作の詳細については後で説明する。汎用的な暗号化に対してＴＰＭ＿ＶＥＲＩＦＩＣＡＴＩＯＮ＿ＫＥＹをＭＴＭは用いることができないため、引用動作の結果２４０６をステークホルダーのＴＳＳ内で暗号化し２４１６、チャレンジャーに返す２４１８。チャレンジャーは返されたメッセージを解読し２４２０、署名されたメッセージがすでにセットアップされているステークホルダーＡＩＫ証明書のキーで署名されたものであることを検証する２４２２。検証が成功すれば、ここでチャレンジャーは、ステークホルダーのＭＴＭのＰＣＲの状態に対するリモート認証を完了し、図２４Ｂに示すように、機器メーカーのＭＴＭにおいてリモートマルチステークホルダー認証を実行できる状態になっている。

次に、チャレンジャー１９００は、ランダムに機器メーカーノンスを生成し２４２４、そのノンス、および前もって生成したステークホルダーノンス２４０２と結果として得られたＰＣＲ引用データ２４０６とを連結したものの暗号化ハッシュを、リモートマルチステークホルダー認証要求として送信する２４２６。なお、チャレンジャー部が発行した第２認証部へのチャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する。好ましい実施形態では、暗号化ハッシュルーチンはＳＨＡ１である。機器メーカーＴＳＳは、すでに行った有効なステークホルダー認証をこの暗号化ハッシュが表していることを検証する２４２８。この動作の詳細については後で説明する。要するに、第２認証部は、第２認証部の状態を表す情報項目セットの値に対して認証を行う。このときの各項目は、第２認証部の特性を表す数値を有する。具体的には、各項目は、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したようなプラットフォーム設定レジスタ（ＰＣＲ）である。認証に失敗すれば、好ましい実施形態では、機器メーカーＴＳＳは適切なエラーで認証セッションを終了する。次に、機器メーカーＴＳＳは、前もって生成したステークホルダーノンス２４０２と結果として得られたＰＣＲ引用データ２４０６と機器メーカーノンス２４２４とを連結したものの暗号化ハッシュを評価することによって新たな機器メーカーノンスを算出する２４３０。この新たなノンスが、先行技術に記載されているようなＴＰＭ＿Ｑｕｏｔｅ２ ＡＰＩを用いて、製造時に組み込まれた機器メーカーのＡＩＫへの処理とともに機器メーカーＭＴＭ２３０２へ引き渡されて、ＭＴＭ内のＰＣＲのサブセットの署名済み引用をノンスとともに生成する２４３２。この署名済みの新たなノンスプラスＰＣＲ引用データをチャレンジャーに返す２４３４と、このチャレンジャーは、機器メーカーによってすでにセットアップされているＡＩＫ証明書を用いて署名を検証することができる２４３６。また、チャレンジャーは、機器メーカーＴＳＳが２４３０で行ったのと同じ計算をローカルに行うことにより返された新たなノンスを検証する２４４０ことによって、チャレンジャーが２４０４で送信したノンスをステークホルダーＴＳＳは機器メーカーＴＳＳに正確に通知したことがまた証明される。最後に、機器メーカーが成功裏にリモートマルチステークホルダー認証プロトコルを完了して以降、機器メーカーＴＳＳは、２４１４においてすでに記録されているステークホルダーノンスおよびＰＣＲを使用していることに注意する２４３８。この動作の詳細については後で説明する。

図２５は、本発明にかかる子ステークホルダーエンジンから報告された引用結果の検証について示しており、ステップ２４１２の処理を詳しく説明したものである。つまり、第２認証部は、伝達された第１認証結果を検証する。具体的には、第２認証部は、第１認証部の認証情報に直接アクセスしてもよい。子ステークホルダーのＴＳＳから渡された先行技術で定義されたようなＴＰＭ＿ＰＣＲ＿ＩＮＦＯ＿ＳＨＯＲＴ構造体は報告された引用結果を検証する２５００関数に対するパラメータである。まず、呼び出し側のアドレスを決定する２５０２。好ましい形態によると、呼び出しアドレスは引数として渡されるが、当業者であれば、呼び出しスタックを調べてエントリポイントを決定するなど他の方法でも可能であると分かるであろう。このアドレスを用いて子エンジンテーブルのエンジンアドレス範囲６０４フィールドを検索し、呼び出し側のアドレスに該当するアドレス範囲の行を見つける２５０４。一致するものが見つからなければ２５０６、制御を強制エラーレスポンスへ渡し２５０８、先行技術に記載されているように適切に対処する。見つかった場合は、エンジンＰＣＲアドレス範囲フィールド６０６データを用いて子ＰＣＲを子ＭＴＭのアドレス空間からコピーし２５１０、そして、渡されたＴＰＭ＿ＰＣＲ＿ＩＮＦＯ＿ＳＨＯＲＴ内のｐｃｒＳｅｌｅｃｔｉｏｎフィールドを用いてコピーされたＰＣＲのハッシュ値を求める２５１２。この算出されたハッシュが、渡されたＴＰＭ＿ＰＣＲ＿ＩＮＦＯ＿ＳＨＯＲＴ内のｄｉｇｅｓｔＡｔＲｅｌｅａｓｅフィールドと等しくなければ２５１４、ルーチンは失敗を示す値を返す２５１６。そうではなくこれらのハッシュが等しい場合は、子エンジンテーブルの現在の行のエンジンＩＤフィールド６０２および渡されたＴＰＭ＿ＰＣＲ＿ＩＮＦＯ＿ＳＨＯＲＴパラメータを保留認証テーブルに付け加え２５１８、ルーチンは成功を示す値を返す２５２０。当業者であれば、実行が成功した場合にパラメータが保留認証テーブルへ付け加えられる限り、全く検証しないなどの代替検証方法を用いても構わないと分かるであろう。

図２６は、現在進行中の認証要求を保持する保留認証テーブル２６００である。まず、エンジンＩＤフィールド６０２は保留中の認証要求があるステークホルダーエンジンを表す２つの文字コードを含み、次に、ステークホルダーノンスフィールド２６０２はチャレンジャーが認証ルーチンへ供給したノンスを保持する。そして最後に、ＴＰＭ＿ＰＣＲ＿ＩＮＦＯ＿ＳＨＯＲＴフィールド２６０４はステークホルダーＴＳＳが機器メーカーＴＳＳに報告した検証済み認証値を保持する。ただし、ステークホルダーノンスフィールド２６０２はランダム値であるため、何の問題も引き起こすことなく同じエンジンＩＤがテーブルに１回以上現れる可能性はある。

図２７は、機器メーカーＴＳＳへのリモートマルチステークホルダー認証要求が有効な子ステークホルダー値を含んでいることを検証する図示である。保留中のマルチステークホルダー認証用の、子ステークホルダーに用いたノンスの暗号化ハッシュだと主張するチャレンジャーによって供給された値と子ステークホルダーが報告したＰＣＲ値とがルーチンに渡される２７００。保留認証テーブル２６００の各行ごとに２７０２、ＴＰＭ＿ＰＣＲ＿ＩＮＦＯ＿ＳＨＯＲＴフィールド２６０４のｄｉｇｅｓｔＡｔＲｅｌｅａｓｅと連結されたステークホルダーノンスフィールド２６０２のハッシュを算出し２７０６、渡された値と比較する２７０８。２つの値が等しければ、渡された値はまさに保留中のマルチステークホルダー認証要求を表しているので、成功を示すステータスフラグとともにステークホルダーノンスフィールド２６０２およびＴＰＭ＿ＰＣＲ＿ＩＮＦＯ＿ＳＨＯＲＴフィールド２６０４を呼び出し側へ返す２７１０。一方、全ての行をチェックして一致しなければ、渡された値は保留中のマルチステークホルダー認証要求を表していないので、失敗を示すステータスフラグを代わりに返す２７０４。

図２８は、保留中のリモートマルチステークホルダー認証要求が実行されたことに注意する図示である。使用されていたステークホルダーノンスおよびＰＣＲ引用値がルーチンに渡される２８００。保留認証テーブル２６００の各行ごとに２８０２、ルーチンに渡されたステークホルダーノンスおよびＰＣＲ引用値を保留認証テーブル２６００の現在の行で対応するデータと比較する２８０６。一致するならば、使用済みとしてその行に印を付ける必要があるが、好ましい形態では、現在の行をテーブルから削除して２８０８、ルーチンを成功裏に呼び出し側へ戻す２８１０。一致しなければ、次の行をチェックする。一致することなくテーブルの最後に到達すれば、ルーチンをエラーとともに呼び出し側へ戻す２８０４。

当該システムにおける他の好ましい実施形態では、ステークホルダーエンジンごとにリモートマルチステークホルダー認証を行う場合、機器メーカーＴＳＳはチャレンジャーへ折り返し報告するＰＣＲを制限する。図２９は、子エンジンＰＣＲアクセステーブル２９００である。まず、エンジンＩＤフィールド６０２はステークホルダーエンジンを表す２つの文字コードを含み、そして、ＴＰＭ＿ＰＣＲ＿ＳＥＬＥＣＴＩＯＮフィールド２９０２は、リモートマルチステークホルダー認証要求が引用できる機器メーカーのＭＴＭ内のＰＣＲを示す。テーブル内に、好ましい実施形態では文字列「！！」に設定される、決して起こり得ないエンジンＩＤ値となるよう定義されたＥＩＤ＿ＤＥＦＡＵＬＴ２９０４に設定されたエンジンＩＤフィールドの行が存在しても構わない。この行には、検索したエンジンＩＤがテーブル内に存在しない場合に用いるＴＰＭ＿ＰＣＲ＿ＳＥＬＥＣＴＩＯＮ２９０２が記述される。

図３０は、本発明にかかるリモートマルチステークホルダー認証に備えた製造プロセスのサブセットであり、リモートマルチステークホルダー認証を行う場合に機器メーカーがチャレンジャーへ折り返し報告するＰＣＲを制限するため実行するステップに着目したものである。３つの動作主は、機器外の機器メーカーサーバー２３００と機器上の機器メーカーのＴＳＳ２４００と機器上の機器メーカーのＭＴＭ２３０２である。製造時に２３０４、機器メーカーはＡＩＫおよび一致する証明書を作成し２３０８、機器メーカーのＭＴＭ内にＡＩＫの秘密部分を組み込む２３１０。ハードウェアＭＴＭに対し、これはセキュアなメモリへ物理的に情報を書き込むことであってもよく、ソフトウェアＭＴＭに対しては、実行ファイルへデータを投入しそれを署名することであってもよい。次に、機器メーカーは、機器上に存在する可能性がある、既知のステークホルダーエンジン全てに対して子エンジンアクセステーブルを作成し３０００、各行のＴＰＭ＿ＰＣＲ＿ＳＥＬＥＣＴＩＯＮフィールド２９０２に所望の値を代入することにより、各エンジンがアクセス許可されるＰＣＲを選択する。そして、これを機器メーカーのＴＳＳ内に組み込む３００２。当業者であれば、テーブルを完全に保護する必要があり、暗号化署名などの当該技術分野において周知の技術はこの目的として十分であると分かるであろう。

図３１において、本発明にかかるリモートマルチステークホルダー認証の一部を説明する。ここで、チャレンジャーはステークホルダー認証の結果を機器メーカーのＭＴＭで確認することを希望する。ステークホルダーを相手にしたこの認証は図２４Ａに示したシーケンスに従うので、本実施形態において、図２４Ｂをこの図で置き換える。上述したように、チャレンジャー１９００は、ランダムに機器メーカーノンスを生成し２４２４、そのノンス、および前もって生成したステークホルダーノンス２４０２と結果として得られたＰＣＲ引用データ２４０６とを連結したものの暗号化ハッシュを、リモートマルチステークホルダー認証要求として送信する２４２６。好ましい実施形態では、暗号化ハッシュルーチンはＳＨＡ１である。機器メーカーＴＳＳは、すでに行った有効なステークホルダー認証をこの暗号化ハッシュが表していることを検証する２４２８。この動作の詳細については後で説明する。認証に失敗すれば、好ましい実施形態では、機器メーカーＴＳＳは適切なエラーで認証セッションを終了する。次に、機器メーカーＴＳＳは、前もって生成したステークホルダーノンス２４０２と結果として得られたＰＣＲ引用データ２４０６と機器メーカーノンス２４２４とを連結したものの暗号化ハッシュを評価することによって新たな機器メーカーノンスを算出する２４３０。図２７で説明されているように、ステップ２４２８および２４３０中に子ステークホルダーエンジンのエンジンＩＤを決定する。このエンジンＩＤを用いて子エンジンアクセステーブル２９００のエンジンＩＤフィールド６０２を調べて、対応するＴＰＭ＿ＰＣＲ＿ＳＥＬＥＣＴＩＯＮフィールド２９０２を検索する３１００。エンジンＩＤが見つからなければ、代わりにＥＩＤ＿ＤＥＦＡＵＬＴ行を用いる。ＥＩＤ＿ＤＥＦＡＵＬＴ行もなければ、空のＴＰＭ＿ＰＣＲ＿ＳＥＬＥＣＴＩＯＮを使用する。次に、引用するＰＣＲサブセットの値を求める３１０２。好ましい実施形態では、サブセットは必ずちょうど子エンジンアクセステーブルの関連する行内のフィールドであるため何も処理は必要ないが、他の実施形態においては、チャレンジャーが所望のＴＰＭ＿ＰＣＲ＿ＳＥＬＥＣＴＩＯＮを認証要求に付け加え、２つのＴＰＭ＿ＰＣＲ＿ＳＥＬＥＣＴＩＯＮ ｐｃｒＳｅｌｅｃｔフィールド間で論理積演算を行うことによって許可されなかったフィールドをチャレンジャーの要求から取り除く。次に、新たなノンスおよび算出されたＰＣＲサブセットが、先行技術に記載されているようなＴＰＭ＿Ｑｕｏｔｅ２ ＡＰＩを用いて、製造時に組み込まれた機器メーカーのＡＩＫへの処理とともに機器メーカーＭＴＭ２３０２へ引き渡されて、ＭＴＭ内のＰＣＲのサブセットの署名済み引用をノンスとともに生成する３１０４。この署名済みの新たなノンスプラスＰＣＲ引用データをチャレンジャーに返す２４３４と、このチャレンジャーは、機器メーカーによってすでにセットアップされているＡＩＫ証明書を用いて署名を検証することができる２４３６。また、チャレンジャーは、機器メーカーＴＳＳが２４３０で行ったのと同じ計算をローカルに行うことで返された新たなノンスを検証する２４４０ことによっても、チャレンジャーが２４０４で送信したノンスをステークホルダーＴＳＳは機器メーカーＴＳＳへ正確に通知したと証明される。さらに、返されたＰＣＲ引用情報にはＴＰＭ＿ＰＣＲ＿ＳＥＬＥＣＴＩＯＮを含むＴＰＭ＿ＰＣＲ＿ＩＮＦＯ＿ＳＨＯＲＴが含まれるため、チャレンジャーはどのＰＣＲサブセットが実際に引用されたのかを発見することができる。最後に、機器メーカーが成功裏にリモートマルチステークホルダー認証プロトコルを完了して以降、機器メーカーＴＳＳは、２４１４においてすでに記録されているステークホルダーノンスおよびＰＣＲを使用していることに注意する２４３８。

本発明は上記の実施形態に基づいて述べられているが、本発明は明らかにそのような実施形態に限定されるものではない。下記のケースもまた本発明に含まれる。

（１）上述の実施形態は、モバイルトラステッドモジュールおよびセキュアブートの仕様の要件に従う。しかしながら、本発明を、「Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ’ｓ ＴＣＧ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｐａｒｔ ＩＩ − Ｉｎｔｅｇｒｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．０．」で定義したような、トラステッドプラットフォームモジュールを備え、かつ／または、トラステッドブート仕様をサポートするシステムに適用してもよい。

（２）上述の実施形態では、ＭＴＭ仕様書と同様の方法で認証は行われた。しかしながら、本発明を他の認証システムに適用してもよい。ただし、認証システムがシステムの状態を表す一連の値を維持する場合に限る。

（３）上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。

（４）上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

さらに、各装置を構成する構成部品の各ユニットは、別個の個別チップとして、または、一部もしくは全てを含む単一のチップとして作られてもよい。

さらに、ここでは、ＬＳＩが述べられているが、集積化の程度の違いにより、指定ＩＣ、ＬＳＩ、スーパＬＳＩ、ウルトラＬＳＩが使用される場合もある。

さらに、回路の集積化の手段は、ＬＳＩに限定されるものではなく、専用回路、もしくは汎用プロセッサによる実装も利用できる。さらに、ＬＳＩが製造された後にプログラム可能なフィールドプログラムゲートアレイ（ＦＰＧＡ）を使用することもまた可能であり、またＬＳＩ内で回路セルの接続および設定を再構成可能なリコンフィギュアラブルプロセッサも使用可能である。

さらに、もしＬＳＩに置き換わる集積回路技術が半導体技術もしくは他の派生する技術の進歩を通じて現われるのであれば、その技術は当然に構成要素の集積化を実現するために使用することができる。バイオ技術の適用が予想される。

（５）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩに含まれるとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。

（６）本発明は、上記に示す方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムなどのデジタル信号であるとしてもよい。

また、本発明は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。

また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。

また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記憶しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。

また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

（７）本技術分野の当業者にとっては、説明した実施形態の、本発明固有の教示および利点から原理的に離れることのない多くの変形がありえることを容易に理解することができるだろう。また、上記変更および実施形態の任意の組み合わせは、本発明の範囲内に含まれる。

本発明は、パーソナルコンピュータ、携帯電話、オーディオプレーヤ、テレビ、ビデオレコーダなどの、プログラムデータの更新を行う情報通信機器、および、家電機器などに利用することができる。

１００ モバイル装置
１０２ ＣＰＵ
１０４ ＤＭ ＭＴＭ
１０６ プラットフォーム設定レジスタ（ＰＣＲ）
１０８ 機器ハードウェア
１１０ 機器メーカーエンジン
１１２ 信頼性のルート
１１４ ハードウェアドライバ
１１６ 機器メーカーサービス
１１８ ＤＭチェッカー
１２０ 失敗ハンドラ
１２２ 第１ステークホルダーエンジン
１２４ 第１ステークホルダーチェッカー
１２６ 第１ステークホルダーサービス
１２８ ＳＨ ＭＴＭ１
１３０、１４０ ＰＣＲセット
１３２ 第２ステークホルダーエンジン
１３４ 第２ステークホルダーチェッカー
１３６ 第２ステークホルダーサービス
１３８ ＳＨ ＭＴＭ２
２００ エンジンチェッカー
２０２ エンジン証明書
１９００ チャレンジャー
２０００ ステークホルダー
２３００ 機器メーカー

Claims (75)

1. 情報処理装置であって、
   ステークホルダーエンジンが、
   i）実行コードを格納するプログラム格納部と、
   ii）メモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、
   機器メーカーエンジンが、
   i）前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェ
   ック値格納部と、
   ii）前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、
   iii）データに対して完全性チェック値を算出する完全性チェック値算出部と、
   iv）無効にされない場合にエラーレスポンスを呼び出す失敗処理部とを備え、
   前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、
   ａ）前記失敗処理部を無効にし、
   ｂ）前記格納部の前記データに要求された修正を行い、
   ｃ）前記格納部の前記データに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、
   ｄ）前記新たな完全性チェック値を前記完全性チェック値格納部に格納し、かつ、
   ｅ）前記失敗処理部を再び有効にする
   情報処理装置。
2. 請求項１に記載の情報処理装置であって、前記機器メーカーエンジンは前記ステークホルダーエンジンよりも強い権限で動作可能である
   情報処理装置。
3. 請求項１に記載の情報処理装置であって、前記完全性チェック値算出部は暗号化ハッシュ値を算出する
   情報処理装置。
4. 情報処理装置であって、
   ステークホルダーエンジンが、
   i）実行コードを格納するプログラム格納部と、
   ii）メモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、
   機器メーカーエンジンが、
   i）前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェ
   ック値格納部と、
   ii）前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、
   iii）データに対して完全性チェック値を算出する完全性チェック値算出部と、
   iv）無効にされない場合にエラーレスポンスを呼び出す失敗処理部と、
   v）データ修正部による動作の結果を予測する予測部とを備え、
   前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、
   ａ）前記失敗処理部を無効にし、
   ｂ）前記要求の結果を予測するよう前記予測部に要求し、
   ｃ）前記予測結果に対して予測完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、
   ｄ）前記格納部の前記データに要求された修正を行い、
   ｅ）前記完全性チェック対象のデータに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、
   ｆ）新たな完全性チェック値が予測完全性チェック値と等しくなければ、エラーを記録するよう前記失敗処理部に要求し、
   ｇ）前記格納されている完全性チェック値を新たな完全性チェック値で更新するよう前記完全性チェック部に要求し、かつ、
   ｈ）前記失敗処理部を再び有効にする
   情報処理装置。
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. 請求項２６に記載の情報処理システムであって、前記チャレンジャー部が発行した前記第１認証部へのチャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する
    情報処理システム。
30. 請求項１９に記載の情報処理システムであって、前記第２認証部は、さらに、前記第２認証部の状態を表す情報項目セットの値に対して認証を行う
    情報処理システム。
31. 請求項３０に記載の情報処理システムであって、前記第２認証部の状態を表す前記情報項目セットにおける各項目は前記認証部の特性を表す数値を有する
    情報処理システム。
32. 請求項３１に記載の情報処理システムであって、前記第２認証部の状態を表す前記情報項目セットにおける各項目はＴｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したようなプラットフォーム設定レジスタである
    情報処理システム。
33. 請求項３２に記載の情報処理システムであって、前記チャレンジャー部が発行した前記第２認証部へのチャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する
    情報処理システム。
34. 請求項３３に記載の情報処理システムであって、前記第２認証部も、前記チャレンジャーが要求可能な認証情報のサブセットを表す表示を有する
    情報処理システム。
35. 請求項１９に記載の情報処理システムであって、前記第１認証結果の伝達は、さらに、前記第２認証部が前記伝達された第１認証結果を検証することを含む
    情報処理システム。
36. 請求項３５に記載の情報処理システムであって、前記伝達された第１認証結果の検証では、さらに、前記第２認証部が前記第１認証部の認証情報に直接アクセスする
    情報処理システム。
37. 完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法であって、
    ａ）前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、
    ｂ）前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、
    ｃ）前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、
    ｄ）前記失敗処理部を無効にするステップと、
    ｅ）前記ソフトウェアルーチンを実行するステップと、
    ｆ）前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、
    ｇ）前記完全性チェック基準値を前記新たな完全性チェック値で更新するステップと、
    ｈ）前記失敗処理部を再び有効にするステップとを含む
    方法。
38. 請求項３７に記載の方法であって、新たな完全性チェック値を算出する前記ステップは、前記完全性チェック済みデータの暗号化ハッシュを算出するステップを含む
    方法。
39. 完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法であって、
    ａ）前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、
    ｂ）前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、
    ｃ）前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、
    ｄ）前記失敗処理部を無効にするステップと、
    ｅ）前記ソフトウェアルーチンに対して予測結果を算出するステップと、
    ｆ）前記予測結果に対して予測完全性チェック値を算出するステップと、
    ｇ）前記ソフトウェアルーチンを実行するステップと、
    ｈ）前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、
    ｉ）前記新たな完全性チェック値が予測完全性チェック値と等しくなければ、前記失敗処理部を呼び出すステップと、
    ｊ）前記完全性チェック基準値を前記予測完全性チェック値で更新するステップと、
    ｋ）前記失敗処理部を再び有効にするステップとを含む
    方法。
40. 請求項３９に記載の方法であって、新たな完全性チェック値を算出する前記ステップは、前記完全性チェック済みデータの暗号化ハッシュを算出するステップを含む
    方法。
41. 請求項３９に記載の方法であって、前記ソフトウェアルーチンに対して予測結果を算出する前記ステップは、
    ａ）データのコピーを作成するために前記完全性チェック済みデータをコピーするステップと、
    ｂ）前記データのコピーに、前記ソフトウェアルーチンに対するパラメータで定義された動作を行うステップとを含む
    方法。
42. 請求項４１に記載の方法であって、前記ソフトウェアルーチンに対する予測結果の算出では、さらに、
    ａ）前記予測完全性チェック値として前記データのコピーの暗号化ハッシュを算出および格納し、かつ、
    ｂ）前記データのコピーを破棄する
    方法。
43. チャレンジャーデバイスとクライアントデバイスとの間でリモート認証を行う方法であって、
    ａ）前記クライアントデバイスが使用可能な前記チャレンジャーデバイスに認証キーを発行するキー発行デバイスを提供するステップと、
    ｂ）前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の認証部を提供するステップであって、前記認証の要求が前記キー発行デバイスが発行した認証キーの公開部分を有するステップと、
    ｃ）認証結果を得るために前記認証部において認証を行うステップと、
    ｄ）認証キーの前記公開部分で前記認証結果を暗号化するステップと、
    ｅ）前記暗号化された認証結果を前記チャレンジャーに返すステップとを含む
    リモート認証を行う方法。
44. 請求項４３に記載の方法であって、前記認証キーはそのキーが前記クライアントデバイスに既知のキーであるという証拠を含む
    方法。
45. 請求項４４に記載の方法であって、認証キーは前記クライアントデバイスにとって既知であるという前記証拠が前記クライアントデバイスに既知の第２キーを参照する
    方法。
46. 請求項４３に記載の方法であって、認証を行う前に、前記認証部が認証キーの前記公開部分の正当性を確認する
    方法。
47. 請求項４６に記載の方法であって、前記キー発行デバイスは前記認証キーに対する失効証明書を発行する
    方法。
48. 請求項４７に記載の方法であって、前記認証部が前記失効証明書を受信すると前記認証キーを無効にする
    方法。
49. 請求項４８に記載の方法であって、前記認証キーの正当性確認は前記キーの親キーの正当性を確認するステップを有する
    方法。
50. 請求項４９に記載の方法であって、前記認証部は、前記認証部の状態を表す情報項目セットの値に対して認証を行う
    方法。
51. 請求項５０に記載の方法であって、前記情報項目セットにおける各項目は前記認証部の特性を表す数値を有する
    方法。
52. 請求項５１に記載の方法であって、前記情報項目セットにおける各項目はＴｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したようなプラットフォーム設定レジスタである
    方法。
53. 請求項５２に記載の方法であって、前記認証チャレンジは、返すための認証情報のサブセットを表す表示を有する
    方法。
54. チャレンジャーデバイスとクライアントデバイスとの間でリモート認証を行う方法であって、
    ａ）前記クライアントデバイスが使用可能な前記チャレンジャーデバイスに認証キーを発行する第１キー発行デバイスを提供するステップと、
    ｂ）前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の第１認証部を提供するステップであって、前記認証の要求が前記第１キー発行デバイスが発行した認証キーの公開部分を有するステップと、
    ｂ１）前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の第２認証部を提供するステップと、
    ｃ）前記第１認証部が前記第２認証部と通信できるようにするコネクタ部を提供するステップと、
    ｄ）第１認証結果を得るために前記第１認証部において認証を行うステップと、
    ｅ）前記認証キーの前記公開部分で前記第１認証結果を暗号化するステップと、
    ｆ）前記暗号化された第１認証結果を前記チャレンジャーに返すステップと、
    ｇ）前記コネクタ部は、前記第１認証部から第２認証部へ、前記第１認証結果を含むメッセージを伝達するステップと、
    ｈ）第２認証結果を得るために前記第２認証部において認証を行うステップと、
    ｉ）前記第２認証結果を前記チャレンジャーに返すステップとを備える
    リモート認証を行う方法。
55. 請求項５４に記載の方法であって、前記認証キーはそのキーが前記クライアントデバイスに既知のキーであるという証拠を含む
    方法。
56. 請求項５５に記載の方法であって、認証キーは前記クライアントデバイスにとって既知であるという前記証拠が前記クライアントデバイスに既知の第２キーを参照する
    方法。
57. 請求項５４に記載の方法であって、認証を行う前に、前記第１認証部が前記認証キーの前記公開部分の正当性を確認する
    方法。
58. 請求項５７に記載の方法であって、前記第１キー発行デバイスが前記認証キーに対する失効証明書を発行する
    方法。
59. 請求項５８に記載の方法であって、前記第１認証部が前記失効証明書を受信すると前記第１認証キーを無効にする
    方法。
60. 請求項５９に記載の方法であって、前記第１認証キーの正当性確認は、前記認証キーの親キーの正当性を確認するステップを有する
    方法。
61. 請求項６０に記載の方法であって、前記第１認証部は、前記第１認証部の状態を表す情報項目セットの値に対して認証を行う
    方法。
62. 請求項６１に記載の方法であって、前記第１認証部の状態を表す前記情報項目セットにおける各項目は前記認証部の特性を表す数値を有する
    方法。
63. 請求項６２に記載の方法であって、前記第１認証部の状態を表す前記情報項目セットにおける各項目はＴｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したようなプラットフォーム設定レジスタである
    方法。
64. 請求項６１に記載の方法であって、前記第１認証部へのチャレンジは、返すための認証情報のサブセットを表す表示を有する
    方法。
65. 請求項５４に記載の方法であって、前記第２認証部は、前記第２認証部の状態を表す情報項目セットの値に対して認証を行う
    方法。
66. 請求項６５に記載の方法であって、前記第２認証部の状態を表す前記情報項目セットにおける各項目は前記認証部の特性を表す数値を有する
    方法。
67. 請求項６６に記載の方法であって、前記第２認証部の状態を表す前記情報項目セットにおける各項目はＴｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐが定義したようなプラットフォーム設定レジスタである
    方法。
68. 請求項６７に記載の方法であって、前記第２認証部へのチャレンジは、返すための認証情報のサブセットを表す表示を有する
    方法。
69. 請求項６８に記載の方法であって、前記第２認証部も、前記チャレンジャーが要求可能な認証情報のサブセットを表す表示を有する
    方法。
70. 請求項５４に記載の方法であって、前記第１認証結果を含むメッセージを伝達するステップでは、前記第２認証部が前記伝達された第１認証結果を検証する
    方法。
71. 請求項７０に記載の方法であって、前記伝達された第１認証結果を検証するステップでは、前記第２認証部が前記第１認証部の認証情報に直接アクセスするステップを有する
    方法。
72. 完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法をコンピュータに実行させるためのプログラムであって、
    ａ）前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、
    ｂ）前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、
    ｃ）前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、
    ｄ）前記失敗処理部を無効にするステップと、
    ｅ）前記ソフトウェアルーチンを実行するステップと、
    ｆ）前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、
    ｇ）前記完全性チェック基準値を前記新たな完全性チェック値で更新するステップと、
    ｈ）前記失敗処理部を再び有効にするステップとを含む
    プログラム。
73. 完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法をコンピュータに実行させるためのプログラムであって、
    ａ）前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、
    ｂ）前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、
    ｃ）前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、
    ｄ）前記失敗処理部を無効にするステップと、
    ｅ）前記ソフトウェアルーチンに対して予測結果を算出するステップと、
    ｆ）前記予測結果に対して予測完全性チェック値を算出するステップと、
    ｇ）前記ソフトウェアルーチンを実行するステップと、
    ｈ）前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、
    ｉ）前記新たな完全性チェック値が予測完全性チェック値と等しくなければ、前記失敗処理部を呼び出すステップと、
    ｊ）前記完全性チェック基準値を前記予測完全性チェック値で更新するステップと、
    ｋ）前記失敗処理部を再び有効にするステップとを含む
    プログラム。
74. 集積回路であって、
    ステークホルダーエンジンが、
    i）実行コードを格納するプログラム格納部と、
    ii）メモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、
    機器メーカーエンジンが、
    i）前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェ
    ック値格納部と、
    ii）前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、
    iii）データに対して完全性チェック値を算出する完全性チェック値算出部と、
    iv）無効にされない場合にエラーレスポンスを呼び出す失敗処理部とを備え、
    前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、
    ａ）前記失敗処理部を無効にし、
    ｂ）前記格納部の前記データに要求された修正を行い、
    ｃ）前記格納部の前記データに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、
    ｄ）前記新たな完全性チェック値を前記完全性チェック値格納部に格納し、かつ、
    ｅ）前記失敗処理部を再び有効にする
    集積回路。
75. 集積回路であって、
    ステークホルダーエンジンが、
    i）実行コードを格納するプログラム格納部と、
    ii）メモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、
    機器メーカーエンジンが、
    i）前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェ
    ック値格納部と、
    ii）前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、
    iii）データに対して完全性チェック値を算出する完全性チェック値算出部と、
    iv）無効にされない場合にエラーレスポンスを呼び出す失敗処理部と、
    v）データ修正部による動作の結果を予測する予測部とを備え、
    前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、
    ａ）前記失敗処理部を無効にし、
    ｂ）前記要求の結果を予測するよう前記予測部に要求し、
    ｃ）前記予測結果に対して予測完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、
    ｄ）前記格納部の前記データに要求された修正を行い、
    ｅ）前記完全性チェック対象のデータに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、
    ｆ）新たな完全性チェック値が予測完全性チェック値と等しくなければ、エラーを記録するよう前記失敗処理部に要求し、
    ｇ）前記格納されている完全性チェック値を新たな完全性チェック値で更新するよう前記完全性チェック部に要求し、かつ、
    ｈ）前記失敗処理部を再び有効にする
    集積回路。