情報処理装置であって、ステークホルダーエンジンが、i実行コードを格納するプログラム格納部と、iiメモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、機器メーカーエンジンが、i前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェック値格納部と、ii前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、iiiデータに対して完全性チェック値を算出する完全性チェック値算出部と、iv無効にされない場合にエラーレスポンスを呼び出す失敗処理部とを備え、前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、a前記失敗処理部を無効にし、b前記格納部の前記データに要求された修正を行い、c前記格納部の前記データに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、d前記新たな完全性チェック値を前記完全性チェック値格納部に格納し、かつ、e前記失敗処理部を再び有効にする情報処理装置。請求項1に記載の情報処理装置であって、前記機器メーカーエンジンは前記ステークホルダーエンジンよりも強い権限で動作可能である情報処理装置。請求項1に記載の情報処理装置であって、前記完全性チェック値算出部は暗号化ハッシュ値を算出する情報処理装置。情報処理装置であって、ステークホルダーエンジンが、i実行コードを格納するプログラム格納部と、iiメモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、機器メーカーエンジンが、i前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェック値格納部と、ii前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、iiiデータに対して完全性チェック値を算出する完全性チェック値算出部と、iv無効にされない場合にエラーレスポンスを呼び出す失敗処理部と、vデータ修正部による動作の結果を予測する予測部とを備え、前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、a前記失敗処理部を無効にし、b前記要求の結果を予測するよう前記予測部に要求し、c前記予測結果に対して予測完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、d前記格納部の前記データに要求された修正を行い、e前記完全性チェック対象のデータに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、f新たな完全性チェック値が予測完全性チェック値と等しくなければ、エラーを記録するよう前記失敗処理部に要求し、g前記格納されている完全性チェック値を新たな完全性チェック値で更新するよう前記完全性チェック部に要求し、かつ、h前記失敗処理部を再び有効にする情報処理装置。請求項4に記載の情報処理装置であって、前記機器メーカーエンジンは前記ステークホルダーエンジンよりも強い権限で動作可能である情報処理装置。請求項4に記載の情報処理装置であって、前記完全性チェック値算出部は暗号化ハッシュ値を算出する情報処理装置。請求項4に記載の情報処理装置であって、前記予測部はaデータのコピーを作成するために前記データ格納部から前記完全性チェック対象のデータをコピーし、かつ、b前記データのコピーに、前記予測部に対するパラメータで定義された動作を行うことを特徴とする情報処理装置。情報処理システムであって、認証キーを発行するキー発行部を有するキー発行デバイスと、リモート認証チャレンジを発行するチャレンジャー部を有するチャレンジャーデバイスと、チャレンジに応答する認証部を有する認証デバイスとを備え、a前記キー発行部は前記チャレンジャーに認証キーを発行し、b前記チャレンジャー部は、前記認証キーの公開部分を用いて前記認証部にチャレンジを発行し、c前記認証部は前記チャレンジャーのチャレンジに基づき認証を行い、かつ、d前記認証部は、前記認証キーの前記公開部分で暗号化された認証結果を前記チャレンジャーに返す情報処理システム。請求項8に記載の情報処理システムであって、前記認証キーの前記公開部分はそのキーが前記認証デバイスに既知のキーであるという証拠を備える情報処理システム。請求項9に記載の情報処理システムであって、認証キーは前記認証デバイスにとって既知であるという前記証拠が前記認証デバイスに既知の第2キーを参照する情報処理システム。請求項8に記載の情報処理システムであって、前記認証部は、さらに、前記認証キーの前記公開部分の正当性を確認する情報処理システム。請求項11に記載の情報処理システムであって、前記キー発行部は、さらに、前記認証キーに対する失効証明書を発行する情報処理システム。請求項12に記載の情報処理システムであって、前記認証部は、さらに、前記失効証明書を受信すると前記認証キーを無効にする情報処理システム。請求項13に記載の情報処理システムであって、前記認証部は、さらに、前記認証キーの親キーの前記公開部分の正当性を確認する情報処理システム。請求項14に記載の情報処理システムであって、前記認証部は、さらに、前記認証部の状態を表す情報項目セットの値に対して認証を行う情報処理システム。請求項15に記載の情報処理システムであって、前記情報項目セットにおける各項目は前記認証部の特性を表す数値を有する情報処理システム。請求項16に記載の情報処理システムであって、前記情報項目セットにおける各項目はTrustedComputingGroupが定義したようなプラットフォーム設定レジスタである情報処理システム。請求項15に記載の情報処理システムであって、前記チャレンジャー部が発行した前記認証チャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する情報処理システム。情報処理システムであって、認証キーを発行するキー発行部を有するキー発行デバイスと、リモート認証チャレンジを発行するチャレンジャー部を有するチャレンジャーデバイスと、チャレンジに応答する第1認証部を有する認証デバイスであって、さらに、チャレンジに応答する第2認証部と、さらに、前記第1認証部が前記第2認証部と通信できるようにするコネクタ部とを有する前記認証デバイスとを備え、a前記キー発行部は前記チャレンジャーに認証キーを発行し、b前記チャレンジャー部は、前記認証キーの公開部分を用いて前記第1認証部にチャレンジを発行し、c前記第1認証部は前記チャレンジャーのチャレンジに基づき第1認証を行い、d前記第1認証部は、前記認証キーの前記公開部分で暗号化された第1認証結果を前記チャレンジャーに返し、e前記コネクタ部は、前記第1認証部から前記第2認証部へ第1認証結果を伝達し、f前記チャレンジャー部は、前記第2認証部にチャレンジを発行し、g前記第2認証部は、前記チャレンジャーのチャレンジおよび前記コネクタ部を介して伝達された前記第1認証結果に基づき第2認証を行い、かつ、h前記第2認証部は、第2認証結果を前記チャレンジャーに返す情報処理システム。請求項19に記載の情報処理システムであって、前記認証キーの前記公開部分はそのキーが前記認証デバイスに既知のキーであるという証拠を備える情報処理システム。請求項20に記載の情報処理システムであって、認証キーは前記認証デバイスにとって既知であるという前記証拠が前記認証デバイスに既知の第2キーを参照する情報処理システム。請求項19に記載の情報処理システムであって、前記第1認証部は、さらに、前記認証キーの前記公開部分の正当性を確認する情報処理システム。請求項22に記載の情報処理システムであって、前記キー発行部は、さらに、前記認証キーに対する失効証明書を発行する情報処理システム。請求項23に記載の情報処理システムであって、前記第1認証部が前記失効証明書を受信すると前記認証キーを無効にする情報処理システム。請求項24に記載の情報処理システムであって、前記認証キーの正当性確認は、さらに、前記認証キーの親キーの正当性を確認する情報処理システム。請求項25に記載の情報処理システムであって、前記第1認証部は、さらに、前記第1認証部の状態を表す情報項目セットの値に対して認証を行う情報処理システム。請求項26に記載の情報処理システムであって、前記第1認証部の状態を表す前記情報項目セットにおける各項目は前記認証部の特性を表す数値を有する情報処理システム。請求項27に記載の情報処理システムであって、前記第1認証部の状態を表す前記情報項目セットにおける各項目はTrustedComputingGroupが定義したようなプラットフォーム設定レジスタである情報処理システム。請求項26に記載の情報処理システムであって、前記チャレンジャー部が発行した前記第1認証部へのチャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する情報処理システム。請求項19に記載の情報処理システムであって、前記第2認証部は、さらに、前記第2認証部の状態を表す情報項目セットの値に対して認証を行う情報処理システム。請求項30に記載の情報処理システムであって、前記第2認証部の状態を表す前記情報項目セットにおける各項目は前記認証部の特性を表す数値を有する情報処理システム。請求項31に記載の情報処理システムであって、前記第2認証部の状態を表す前記情報項目セットにおける各項目はTrustedComputingGroupが定義したようなプラットフォーム設定レジスタである情報処理システム。請求項32に記載の情報処理システムであって、前記チャレンジャー部が発行した前記第2認証部へのチャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する情報処理システム。請求項33に記載の情報処理システムであって、前記第2認証部も、前記チャレンジャーが要求可能な認証情報のサブセットを表す表示を有する情報処理システム。請求項19に記載の情報処理システムであって、前記第1認証結果の伝達は、さらに、前記第2認証部が前記伝達された第1認証結果を検証することを含む情報処理システム。請求項35に記載の情報処理システムであって、前記伝達された第1認証結果の検証では、さらに、前記第2認証部が前記第1認証部の認証情報に直接アクセスする情報処理システム。完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法であって、a前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、b前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、c前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、d前記失敗処理部を無効にするステップと、e前記ソフトウェアルーチンを実行するステップと、f前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、g前記完全性チェック基準値を前記新たな完全性チェック値で更新するステップと、h前記失敗処理部を再び有効にするステップとを含む方法。請求項37に記載の方法であって、新たな完全性チェック値を算出する前記ステップは、前記完全性チェック済みデータの暗号化ハッシュを算出するステップを含む方法。完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法であって、a前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、b前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、c前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、d前記失敗処理部を無効にするステップと、e前記ソフトウェアルーチンに対して予測結果を算出するステップと、f前記予測結果に対して予測完全性チェック値を算出するステップと、g前記ソフトウェアルーチンを実行するステップと、h前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、i前記新たな完全性チェック値が予測完全性チェック値と等しくなければ、前記失敗処理部を呼び出すステップと、j前記完全性チェック基準値を前記予測完全性チェック値で更新するステップと、k前記失敗処理部を再び有効にするステップとを含む方法。請求項39に記載の方法であって、新たな完全性チェック値を算出する前記ステップは、前記完全性チェック済みデータの暗号化ハッシュを算出するステップを含む方法。請求項39に記載の方法であって、前記ソフトウェアルーチンに対して予測結果を算出する前記ステップは、aデータのコピーを作成するために前記完全性チェック済みデータをコピーするステップと、b前記データのコピーに、前記ソフトウェアルーチンに対するパラメータで定義された動作を行うステップとを含む方法。請求項41に記載の方法であって、前記ソフトウェアルーチンに対する予測結果の算出では、さらに、a前記予測完全性チェック値として前記データのコピーの暗号化ハッシュを算出および格納し、かつ、b前記データのコピーを破棄する方法。チャレンジャーデバイスとクライアントデバイスとの間でリモート認証を行う方法であって、a前記クライアントデバイスが使用可能な前記チャレンジャーデバイスに認証キーを発行するキー発行デバイスを提供するステップと、b前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の認証部を提供するステップであって、前記認証の要求が前記キー発行デバイスが発行した認証キーの公開部分を有するステップと、c認証結果を得るために前記認証部において認証を行うステップと、d認証キーの前記公開部分で前記認証結果を暗号化するステップと、e前記暗号化された認証結果を前記チャレンジャーに返すステップとを含むリモート認証を行う方法。請求項43に記載の方法であって、前記認証キーはそのキーが前記クライアントデバイスに既知のキーであるという証拠を含む方法。請求項44に記載の方法であって、認証キーは前記クライアントデバイスにとって既知であるという前記証拠が前記クライアントデバイスに既知の第2キーを参照する方法。請求項43に記載の方法であって、認証を行う前に、前記認証部が認証キーの前記公開部分の正当性を確認する方法。請求項46に記載の方法であって、前記キー発行デバイスは前記認証キーに対する失効証明書を発行する方法。請求項47に記載の方法であって、前記認証部が前記失効証明書を受信すると前記認証キーを無効にする方法。請求項48に記載の方法であって、前記認証キーの正当性確認は前記キーの親キーの正当性を確認するステップを有する方法。請求項49に記載の方法であって、前記認証部は、前記認証部の状態を表す情報項目セットの値に対して認証を行う方法。請求項50に記載の方法であって、前記情報項目セットにおける各項目は前記認証部の特性を表す数値を有する方法。請求項51に記載の方法であって、前記情報項目セットにおける各項目はTrustedComputingGroupが定義したようなプラットフォーム設定レジスタである方法。請求項52に記載の方法であって、前記認証チャレンジは、返すための認証情報のサブセットを表す表示を有する方法。チャレンジャーデバイスとクライアントデバイスとの間でリモート認証を行う方法であって、a前記クライアントデバイスが使用可能な前記チャレンジャーデバイスに認証キーを発行する第1キー発行デバイスを提供するステップと、b前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の第1認証部を提供するステップであって、前記認証の要求が前記第1キー発行デバイスが発行した認証キーの公開部分を有するステップと、b1前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の第2認証部を提供するステップと、c前記第1認証部が前記第2認証部と通信できるようにするコネクタ部を提供するステップと、d第1認証結果を得るために前記第1認証部において認証を行うステップと、e前記認証キーの前記公開部分で前記第1認証結果を暗号化するステップと、f前記暗号化された第1認証結果を前記チャレンジャーに返すステップと、g前記コネクタ部は、前記第1認証部から第2認証部へ、前記第1認証結果を含むメッセージを伝達するステップと、h第2認証結果を得るために前記第2認証部において認証を行うステップと、i前記第2認証結果を前記チャレンジャーに返すステップとを備えるリモート認証を行う方法。請求項54に記載の方法であって、前記認証キーはそのキーが前記クライアントデバイスに既知のキーであるという証拠を含む方法。請求項55に記載の方法であって、認証キーは前記クライアントデバイスにとって既知であるという前記証拠が前記クライアントデバイスに既知の第2キーを参照する方法。請求項54に記載の方法であって、認証を行う前に、前記第1認証部が前記認証キーの前記公開部分の正当性を確認する方法。請求項57に記載の方法であって、前記第1キー発行デバイスが前記認証キーに対する失効証明書を発行する方法。請求項58に記載の方法であって、前記第1認証部が前記失効証明書を受信すると前記第1認証キーを無効にする方法。請求項59に記載の方法であって、前記第1認証キーの正当性確認は、前記認証キーの親キーの正当性を確認するステップを有する方法。請求項60に記載の方法であって、前記第1認証部は、前記第1認証部の状態を表す情報項目セットの値に対して認証を行う方法。請求項61に記載の方法であって、前記第1認証部の状態を表す前記情報項目セットにおける各項目は前記認証部の特性を表す数値を有する方法。請求項62に記載の方法であって、前記第1認証部の状態を表す前記情報項目セットにおける各項目はTrustedComputingGroupが定義したようなプラットフォーム設定レジスタである方法。請求項61に記載の方法であって、前記第1認証部へのチャレンジは、返すための認証情報のサブセットを表す表示を有する方法。請求項54に記載の方法であって、前記第2認証部は、前記第2認証部の状態を表す情報項目セットの値に対して認証を行う方法。請求項65に記載の方法であって、前記第2認証部の状態を表す前記情報項目セットにおける各項目は前記認証部の特性を表す数値を有する方法。請求項66に記載の方法であって、前記第2認証部の状態を表す前記情報項目セットにおける各項目はTrustedComputingGroupが定義したようなプラットフォーム設定レジスタである方法。請求項67に記載の方法であって、前記第2認証部へのチャレンジは、返すための認証情報のサブセットを表す表示を有する方法。請求項68に記載の方法であって、前記第2認証部も、前記チャレンジャーが要求可能な認証情報のサブセットを表す表示を有する方法。請求項54に記載の方法であって、前記第1認証結果を含むメッセージを伝達するステップでは、前記第2認証部が前記伝達された第1認証結果を検証する方法。請求項70に記載の方法であって、前記伝達された第1認証結果を検証するステップでは、前記第2認証部が前記第1認証部の認証情報に直接アクセスするステップを有する方法。完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法をコンピュータに実行させるためのプログラムであって、a前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、b前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、c前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、d前記失敗処理部を無効にするステップと、e前記ソフトウェアルーチンを実行するステップと、f前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、g前記完全性チェック基準値を前記新たな完全性チェック値で更新するステップと、h前記失敗処理部を再び有効にするステップとを含むプログラム。完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法をコンピュータに実行させるためのプログラムであって、a前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、b前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、c前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、d前記失敗処理部を無効にするステップと、e前記ソフトウェアルーチンに対して予測結果を算出するステップと、f前記予測結果に対して予測完全性チェック値を算出するステップと、g前記ソフトウェアルーチンを実行するステップと、h前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、i前記新たな完全性チェック値が予測完全性チェック値と等しくなければ、前記失敗処理部を呼び出すステップと、j前記完全性チェック基準値を前記予測完全性チェック値で更新するステップと、k前記失敗処理部を再び有効にするステップとを含むプログラム。集積回路であって、ステークホルダーエンジンが、i実行コードを格納するプログラム格納部と、iiメモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、機器メーカーエンジンが、i前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェック値格納部と、ii前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、iiiデータに対して完全性チェック値を算出する完全性チェック値算出部と、iv無効にされない場合にエラーレスポンスを呼び出す失敗処理部とを備え、前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、a前記失敗処理部を無効にし、b前記格納部の前記データに要求された修正を行い、c前記格納部の前記データに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、d前記新たな完全性チェック値を前記完全性チェック値格納部に格納し、かつ、e前記失敗処理部を再び有効にする集積回路。集積回路であって、ステークホルダーエンジンが、i実行コードを格納するプログラム格納部と、iiメモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、機器メーカーエンジンが、i前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェック値格納部と、ii前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、iiiデータに対して完全性チェック値を算出する完全性チェック値算出部と、iv無効にされない場合にエラーレスポンスを呼び出す失敗処理部と、vデータ修正部による動作の結果を予測する予測部とを備え、前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、a前記失敗処理部を無効にし、b前記要求の結果を予測するよう前記予測部に要求し、c前記予測結果に対して予測完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、d前記格納部の前記データに要求された修正を行い、e前記完全性チェック対象のデータに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、f新たな完全性チェック値が予測完全性チェック値と等しくなければ、エラーを記録するよう前記失敗処理部に要求し、g前記格納されている完全性チェック値を新たな完全性チェック値で更新するよう前記完全性チェック部に要求し、かつ、h前記失敗処理部を再び有効にする集積回路。Proudlerらによる米国特許第7457951号明細書特許文献1では、信頼性のある環境に属するメモリに格納される場合にはデータは変化しないはずであると仮定し、記憶媒体において統計的に有意でない欠陥いわゆるビット崩壊であって、経年、電気的スパイク、または宇宙線によっても反転するランダムビットの傾向と有意な変化を分別することによりデータの良し悪しを決定することで上記の課題を対処しようとしているが、警告表示を生成する以外の何らかの手段で有意だが予期されるデータの変化に対応する方法については何も言及していない。しかしながら、ソフトウェアに実装されたMTMに格納されているプラットフォーム設定レジスタPCRsなどのデータに対しては、数少ない特定のAPIだけがこれらのPCRを変更することができるので、良いデータと悪いデータとを分別できる可能性が高く、良い変化はこれらのAPIの実行中にのみ生じるはずである。したがって、変化が生じると予期される場合にデータを変更できるが、予期される間隔外でデータ変化を検出してデータの信頼性を維持できる、データメモリのブロックの完全性をチェックする方法が必要である。また、PCRを変更するこれらの特定APIは、APIに対するパラメータで記述された方法により動作するため、特定API中にのみ変化を許可するだけでなく、特定API中にのみ予期される変化を許可することも可能である。さらに、PCRを変更するAPIの結果を予測して、予期されるPCRの変化のみ実際に生じていることを完全性監視ソフトウェアが検証できる方法が必要である。TCGによるMTMのもう1つ重要な特徴はリモート認証できること、つまり、PCRに保持された完全性メトリクスの記述通りに第三者のチャレンジャーがMTMの現状を問い合わせることができることである。返された状態は、リプレーアタックを防ぐためにノンスと組み合わせられ、MTMが保持していたキーで署名されて第三者証明機関CAにより証明される。しかしながら、PCR完全性メトリクスはプラットフォームの状態に関する情報を含んでいるが、リモート認証の結果の機密性に対する保護はない。ゆえに、ステークホルダーのエンジンがリモート認証の実行を希望する第三者へ認証暗号化キーを提供する方法がさらに必要である。また、この認証暗号化キーが他の認証暗号化キーとは別個に無効化される方法も必要である。マルチステークホルダーモデルにおいては、ステークホルダーのエンジンのMTMを認証するだけでなく、ステークホルダーのエンジンが実行されている環境を検証するために機器メーカーのエンジン内のMTMも認証する必要があるかもしれない。しかしながら、2つの異なるステークホルダーから2つのエンジンが提供されるため、チャレンジャーは、報告されたステークホルダーのエンジンの認証結果は信用できるものであると機器メーカーのエンジンによって保証される必要がある。このように、マルチステークホルダーモデルは、機器メーカーのエンジンが親であって、その他全てのステークホルダーのエンジンが子となる親子関係を定義する。ゆえに、機器メーカーが検証可能である限り、チャレンジャーは、ステークホルダーから受信した認証結果が正しいことを実証するために、チャレンジャーが親機器メーカーのエンジンにチャレンジする方法がさらに必要である。また、マルチステークホルダーモデルにおいては、子ステークホルダーのエンジンからのリモート認証後に、親機器メーカーのエンジンにチャレンジャーがリモート認証を要求する場合、親エンジンは、機器上に存在する別のステークホルダーのエンジンに関連するPCR内の完全値を返すことを希望しない可能性がある。ゆえに、チャレンジャーがすでにリモート認証を要求した子ステークホルダーに基づき、チャレンジャーに返された、機器メーカーのエンジンのMTMに保持していた完全値セットを機器メーカーのエンジンが制限する方法がさらに必要である。したがって、データの完全性の管理および親エンジンによる子エンジン内の予測を実装する方法、システムおよびコンピュータプログラム製品を本願にて提案する。さらに、マルチステークホルダーモデルの環境内におけるリモート認証を実装する方法、システムおよびコンピュータプログラム製品を本願にて提案する。大まかに言うと、本発明は、コンピュータ読み取り可能な媒体に格納されたデータを保護する改良技術に関するものである。本発明の1つの態様は、特に、より高いレベルの信頼性および/または安全性で信頼性のある親環境に子のデータを監視させて予期せぬ変化を探すことによって、信頼性のある子環境が所有するデータを悪意あるハッカーが変更するのを防ぐために、信頼性のある子環境内に格納されたデータを保護する技術を提供することである。本発明のその他の態様は、このようなデータ保護を一時的に無効にして監視データに対する認証または予期された更新を許可する技術を提供することである。本発明のさらなる他の態様は、このような予期された更新を承認し、かつ、データモニタリングを再度有効にして更新されたデータを保護する技術を提供することである。また、本発明のその他の態様は、特に、監視データに対して認証されたが予期せぬ更新を同時に行う悪意あるハッカーを検出するために、認証または予期された更新の結果を予測する技術を提供することである。また、本発明のさらなる他の態様は、特に、悪意あるハッカーが信頼性のある子環境を前の状態にリセットすることを防ぐために、信頼性のある子環境における認証または予期された変化の継続的な蓄積を信頼性のある親環境内で維持する技術を提供することである。また、本発明のさらなる他の態様は、特に、どの第三者がリモート認証を行うことが許可されるのかを制御するために、第三者に与えても構わない公開キーと秘密キーとのペアをステークホルダーが特定する技術を提供することである。また、本発明のさらなる他の態様は、特に、子における親の信頼性をより高くするために、第三者との認証を実行したことを信頼性のある子環境が信頼性のある親環境に知らせ、かつ、子が動作を正しく表していることを親が検証する技術を提供することである。また、本発明のさらなる他の態様は、特に、子における親の信頼性をより高くするために、信頼性のある子環境で認証が完了したことを第三者が信頼性のある親環境に知らせ、かつ、第三者の情報が子から直接受信した情報と一致することを親が検証する技術を提供することである。また、本発明のさらなる他の態様は、特に、機器に対するプライバシー制御を向上させるために、第三者がすでに認証した子に応じて信頼性のある親環境が第三者にPCRデータのサブセットのみを報告する技術を提供することである。例えば、本発明の一態様に係る情報処理装置は、ステークホルダーエンジンが、i実行コードを格納するプログラム格納部と、iiメモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、機器メーカーエンジンが、i前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェック値格納部と、ii前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、iiiデータに対して完全性チェック値を算出する完全性チェック値算出部と、iv無効にされない場合にエラーレスポンスを呼び出す失敗処理部とを備え、前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、a前記失敗処理部を無効にし、b前記格納部の前記データに要求された修正を行い、c前記格納部の前記データに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、d前記新たな完全性チェック値を前記完全性チェック値格納部に格納し、かつ、e前記失敗処理部を再び有効にする。また、本発明の別の一態様に係る情報処理装置は、ステークホルダーエンジンが、i実行コードを格納するプログラム格納部と、iiメモリデバイス内に完全性チェック対象のデータを格納するデータ格納部とを備え、機器メーカーエンジンが、i前記完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェック値格納部と、ii前記完全性チェック値格納部の基準値に対して前記データの完全性をチェックする完全性チェック部と、iiiデータに対して完全性チェック値を算出する完全性チェック値算出部と、iv無効にされない場合にエラーレスポンスを呼び出す失敗処理部と、vデータ修正部による動作の結果を予測する予測部とを備え、前記ステークホルダーエンジンは、さらに、前記データ格納部によって格納されているデータを修正するデータ修正部を備え、前記完全性チェック対象のデータを修正するために前記プログラム格納部に格納された実行中のコードから要求を受信した場合に、このデータ修正部は、a前記失敗処理部を無効にし、b前記要求の結果を予測するよう前記予測部に要求し、c前記予測結果に対して予測完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、d前記格納部の前記データに要求された修正を行い、e前記完全性チェック対象のデータに対して新たな完全性チェック値を算出するよう前記完全性チェック値算出部に要求し、f新たな完全性チェック値が予測完全性チェック値と等しくなければ、エラーを記録するよう前記失敗処理部に要求し、g前記格納されている完全性チェック値を新たな完全性チェック値で更新するよう前記完全性チェック部に要求し、かつ、h前記失敗処理部を再び有効にする。また、本発明の別の一態様に係る情報処理システムは、認証キーを発行するキー発行部を有するキー発行デバイスと、リモート認証チャレンジを発行するチャレンジャー部を有するチャレンジャーデバイスと、チャレンジに応答する認証部を有する認証デバイスとを備え、a前記キー発行部は前記チャレンジャーに認証キーを発行し、b前記チャレンジャー部は、前記認証キーの公開部分を用いて前記認証部にチャレンジを発行し、c前記認証部は前記チャレンジャーのチャレンジに基づき認証を行い、かつ、d前記認証部は、前記認証キーの前記公開部分で暗号化された認証結果を前記チャレンジャーに返す。また、本発明の別の一態様に係る情報処理システムは、認証キーを発行するキー発行部を有するキー発行デバイスと、リモート認証チャレンジを発行するチャレンジャー部を有するチャレンジャーデバイスと、チャレンジに応答する第1認証部を有する認証デバイスであって、さらに、チャレンジに応答する第2認証部と、さらに、前記第1認証部が前記第2認証部と通信できるようにするコネクタ部とを有する前記認証デバイスとを備え、a前記キー発行部は前記チャレンジャーに認証キーを発行し、b前記チャレンジャー部は、前記認証キーの公開部分を用いて前記第1認証部にチャレンジを発行し、c前記第1認証部は前記チャレンジャーのチャレンジに基づき第1認証を行い、d前記第1認証部は、前記認証キーの前記公開部分で暗号化された第1認証結果を前記チャレンジャーに返し、e前記コネクタ部は、前記第1認証部から前記第2認証部へ第1認証結果を伝達し、f前記チャレンジャー部は、前記第2認証部にチャレンジを発行し、g前記第2認証部は、前記チャレンジャーのチャレンジおよび前記コネクタ部を介して伝達された前記第1認証結果に基づき第2認証を行い、かつ、h前記第2認証部は、第2認証結果を前記チャレンジャーに返す。また、本発明の別の一態様に係るソフトウェアルーチン実行方法は、完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法であって、a前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、b前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、c前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、d前記失敗処理部を無効にするステップと、e前記ソフトウェアルーチンを実行するステップと、f前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、g前記完全性チェック基準値を前記新たな完全性チェック値で更新するステップと、h前記失敗処理部を再び有効にするステップとを含む。また、本発明の別の一態様に係るソフトウェアルーチン実行方法は、完全性チェック済みデータを変更する可能性があるソフトウェアルーチンを実行する方法であって、a前記ソフトウェアルーチンより強い権限で動作する完全性チェック部を提供するステップと、b前記完全性チェック済みデータに対する有効な完全値を表す完全性チェック基準値を提供するステップと、c前記完全性チェック基準値が算出された完全性チェック値と等しくなければ前記完全性チェック部が呼び出す失敗処理部を提供するステップと、d前記失敗処理部を無効にするステップと、f前記ソフトウェアルーチンに対して予測結果を算出するステップと、h前記予測結果に対して予測完全性チェック値を算出するステップと、g前記ソフトウェアルーチンを実行するステップと、h前記完全性チェック済みデータに対して新たな完全性チェック値を算出するステップと、i前記新たな完全性チェック値が予測完全性チェック値と等しくなければ、前記失敗処理部を呼び出すステップと、j前記完全性チェック基準値を前記予測完全性チェック値で更新するステップと、k前記失敗処理部を再び有効にするステップとを含む。また、本発明の別の一態様に係るリモート認証方法は、チャレンジャーデバイスとクライアントデバイスとの間でリモート認証を行う方法であって、a前記クライアントデバイスが使用可能な前記チャレンジャーデバイスに認証キーを発行するキー発行デバイスを提供するステップと、b前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の認証部を提供するステップであって、前記認証の要求が前記キー発行デバイスが発行した認証キーの公開部分を有するステップと、c認証結果を得るために前記認証部において認証を行うステップと、d認証キーの前記公開部分で前記認証結果を暗号化するステップと、e前記暗号化された認証結果を前記チャレンジャーに返すステップとを含む。また、本発明の別の一態様に係るリモート認証方法は、チャレンジャーデバイスとクライアントデバイスとの間でリモート認証を行う方法であって、a前記クライアントデバイスが使用可能な前記チャレンジャーデバイスに認証キーを発行する第1キー発行デバイスを提供するステップと、b前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の第1認証部を提供するステップであって、前記認証の要求が前記第1キー発行デバイスが発行した認証キーの公開部分を有するステップと、b1前記チャレンジャーから認証の要求を受信する前記クライアントデバイス上の第2認証部を提供するステップと、c前記第1認証部が前記第2認証部と通信できるようにするコネクタ部を提供するステップと、d第1認証結果を得るために前記第1認証部において認証を行うステップと、e前記認証キーの前記公開部分で前記第1認証結果を暗号化するステップと、f前記暗号化された第1認証結果を前記チャレンジャーに返すステップと、g前記コネクタ部は、前記第1認証部から第2認証部へ、前記第1認証結果を含むメッセージを伝達するステップと、h第2認証結果を得るために前記第2認証部において認証を行うステップと、i前記第2認証結果を前記チャレンジャーに返すステップとを含む。本発明のその他の態様および利点は、本発明の原理を例として説明する図面とともに以下の詳細な説明から明らかになるであろう。本発明によれば、データの改ざんを防止することができ、データの信頼性を維持することができる。以下に、本発明の好ましい実施形態を説明する。図1は、完全性をチェックする機能性に重点を置いた、機器メーカーDMのエンジンと2つのステークホルダーのエンジンとを備えたシステムの場合のTCGMobileReferenceArchitectureの実施形態にかかるマルチステークホルダーモデル先行技術である。マルチステークホルダーモデルの一実施形態において、第1のステークホルダーはモバイルサービスキャリアであり、第2のステークホルダーはモバイルサービスオペレーターである。まず最初に、後述するコンポーネントから構成されるモバイル装置100がある。下から、中央処理装置、つまりCPU102と、PCR0からPCR31までのプラットフォーム設定レジスタ106を含む機器メーカーのモバイルトラステッドモジュール104と、機器ハードウェア108がある。そして、信頼性のルート112と、ハードウェア108用のハードウェアドライバ114と、当該システムにおいて他のコンポーネントが使用するメーカーによって提供された様々な機器メーカーサービス116とを含む機器メーカーエンジン110がある。DMMTM104およびPCR106は、異なるコンポーネントにおいて必ずしも必要ではないが、機器メーカーエンジン110のソフトウェアまたはファームウェアに実装されてもよいと当業者であれば分かるであろう。そして、DMチェッカー118があり、TCGMobileReferenceArchitectureの記載通り、これは、DM自身のエンジン内サービスの完全性を監視するだけでなく、第1ステークホルダーエンジン122および第2ステークホルダーエンジン132内のステークホルダーチェッカー124および134の完全性も監視する。これらのステークホルダーチェッカー124および134は、第1ステークホルダーエンジン122および第2ステークホルダーエンジン132内コンポーネントの完全性をそれぞれチェックする。ステークホルダーチェッカーの動作は、TCGMobileReferenceArchitectureに記載されているようなSRMVAの動作と同じである。DMチェッカー118が完全性エラーを検出すれば、全エンジンにおいて信頼性のある全ての動作を無効にしたり、機器を再起動するなど適した行いをすることによって失敗を処理する失敗ハンドラ120が動作する。失敗ハンドラの動作は、TCGMobileReferenceArchitectureに記載されているようなTCG_Reactive機能の動作と同じである。そして、第1ステークホルダーエンジン122は、上述のようなステークホルダーチェッカー124を含み、第1ステークホルダーサービス126の完全性をチェックする。これらのサービスは、ステークホルダーのSHMTM1128とインターフェースで接続され、信頼性のあるサービスを要求に応じてクライアントに提供する。なお、第1ステークホルダーサービス126およびSHMTM1128は、実行コードを格納するプログラム格納部の一例である。SHMTM1128は、PCR0からPCR15のPCRセット130を有している。なお、SHMTM1128は、メモリデバイス内に完全性チェック対象のデータを格納するデータ格納部の一例である。TCG仕様書では、信頼性のある単一モジュール内の最低PCR数についてしか述べていないため、本発明の実施形態は信頼性のあるモジュールにつき適度にPCRを有すればよい。第2ステークホルダーエンジン132は、同様の構造であり、ステークホルダーチェッカー134と、第2ステークホルダーサービス136と、SHMTM2138と、PCR0からPCR23140とを有する。図1では異なるエンティティとして3つのエンジン110、122および132を示しているが、それらの区別は、単なる論理的な区分であっても、異なる仮想マシンのそれぞれであっても構わず、また、プロセス分離を政策に基づいて実施しても、上記または当該技術分野において周知の他の技術を組み合わせても構わない。3つのエンジンの実装にかかわらず、機器メーカーエンジン110がより信頼できる親であってステークホルダーエンジン122および132が信頼性に劣る子である論理階層も存在する。なお、機器メーカーエンジン110は、ステークホルダーエンジン122および132よりも強い権限で動作可能である。言い換えると、機器メーカーエンジン110は、ステークホルダーエンジン122および132が実行するソフトウェアルーチンより強い権限で動作する完全性チェック部を有する。当該図において、点線矢印を使うことによって、より信頼できるコンポーネントが信頼性に劣るコンポーネントの完全性チェックを行うことを示している。これらの完全性チェックは非同期的に行われてもよい。TCGMobileReferenceArchitectureで定義されているように、完全性チェックは、保護するデータの暗号化ハッシュを算出してその値と基準値とを比較することによって行われる。図2は、図1で述べた先行技術に基づく、本発明にかかるマルチステークホルダーモデルである。DMチェッカー118およびステークホルダーチェッカー124および134によってサポートされるような完全性をチェックする既存の機能性は維持されるが、さらに、エンジンチェッカー200を加えて、子ステークホルダーエンジン122および132内に親の機器メーカーエンジン110による追加データの完全性メンテナンスを実装した。本発明によると、第1ステークホルダーMTM128および第2ステークホルダーMTM138はソフトウェアに実装され、PCRセット130および140は非ハードウェア保護メモリに実装される。エンジンチェッカー200は、PCRセット130および140の予期せぬ変化を検出するために用いられる完全性基準値を格納するエンジン証明書202を用いて、ステークホルダーのエンジンのMTMのPCR130および140の完全性を非同期的に監視する。もし予期せぬ変化が検出されれば、失敗ハンドラ120を用いて失敗例を処理する。なお、エンジン証明書202は、完全性チェック対象のデータ用の完全性チェック基準値を格納する完全性チェック値格納部の一例である。また、エンジンチェッカー200は、完全性チェック値格納部の基準値に対してデータの完全性をチェックする完全性チェック部の一例である。さらに、エンジンチェッカー200は、データに対して完全性チェック値を算出する完全性チェック値算出部の一例でもある。例えば、完全性チェック値算出部の一例であるエンジンチェッカー200は、暗号化ハッシュ値を算出する。また、失敗ハンドラ120は、無効にされない場合にエラーレスポンスを呼び出す失敗処理部の一例である。図3は、先行技術にかかるエンジン証明書の構造体である。このエンジン証明書のフォーマット300は先行技術である携帯電話ワーキンググループのRIM証明書の構造体のフォーマットと同一であるが、いくつかのフィールドは違って解釈される。まず、tagフィールド302、labelフィールド304およびrimVersionフィールド306は予め定義された意味のままである。好ましい形態では、labelフィールド304にはShExx_yyを用いる。ここで、文字ShEはこの証明書がステークホルダーのエンジンデータ証明書であることを示し、xxは特定のステークホルダーのエンジンを表す数値識別子であり、yyはエンジン内のどの特定データ項目を保護中なのかを表す数値識別子である。rimVersionフィールド306は、再起動後にゼロで始まるカウンターを含んでおり、所定のlabelの新たなエンジン証明書が更新されるたびに1ずつ増える。referenceCounter308は単調カウンタを保持すると定義されているが、好ましい形態において、この単調カウンタは必要ではない。なぜなら、単調カウンタはリソースを共有かつ制限するものであり、証明書のカレンシーをシステムの再起動中に保存しておく必要がないため、好ましい形態ではこのカレンシーを確立する代替方法を用いるからである。stateフィールド310には予期されるPCR状態が記述されると定義されている。これは機器メーカーエンジン110の状態である。好ましい形態においては、PCR31またはロールバック攻撃からの保護用に用いるよう割り当てられた他のレジスタなどの状態が記述される。好ましい形態において、measurementPCRIndexフィールド312は、measurementValueフィールド314に保持されている値を用いて、拡張動作の対象としてPCR31を表す値31を保持する。ロールバック攻撃からの保護用にどのレジスタを用いるかの選択は、機器メーカーによってなされる。下図で詳細に示されているように、エンジン証明書202が監視しているデータに対する更新が行われた後、累積ハッシュ演算を機器メーカーMTM104の適切なPCR106に行うことによって、指示されたmeasurementValue314がmeasurementPCRIndex312に記述されたレジスタへ拡張される。したがって、アタッカーはステークホルダーのエンジンの状態をロールバックできず、それを保護するために用いられるエンジン証明書202をロールバックする。なぜなら、stateフィールド310に、不正なmeasurementPCRIndex312のレジスタの値が記述されると考えられるからである。このmeasurementValue314は、監視中であるステークホルダーのエンジン内のデータの代表値を保持する。好ましい形態においては、この代表値は、PCR130または140などのデータの、周知の優れた暗号化ハッシュであり、この値を用いて監視データの完全性が危険にさらされたかどうかを検証する。多数のステークホルダーエンジンが機器上に存在する場合、当業者であれば各エンジンを異なるPCRに割り当てて、その状態を記録してもよいと気づくであろう。parentIDフィールド316は、先行技術に記載されているような内部検証キーでintegrityCheckDataフィールド324に署名していることを示す、センティネル値TPM_VERIFICATION_KEY_ID_INTERNALに設定される。好ましい形態では、extensionDigestSizeフィールド318が0であるため、extensionDigestフィールド320はゼロバイト長である。最後に、integrityCheckSizeフィールド322およびintegrityCheckDataフィールド324は、先行技術で記載されているように、フィールド302から320の残りのフィールドに対する完全性チェック値を含んでいる。図4は、本発明にかかる機器におけるイベントフローの一例である。各イベントの詳細な説明は後に示す。当該略図の左側は、ステークホルダーサービス126およびステークホルダーMTM128に関するステークホルダーエンジン122内のイベントシーケンスを示しており、右側は、エンジンチェッカー200に関する機器メーカーエンジン110内のイベントシーケンスを示している。先行技術によると、エンジンブート400上にはTPM_StartupAPIへの呼び出し402がある。これは先行技術で定義されているようなスタートアップ動作を行う404。しかし、制御を返す前に、このAPIは初期エンジン証明書の作成406を要求するエンジンチェッカー200のAPIを呼び出す。機器メーカーのエンジン内エンジンチェッカーモジュールはエンジン証明書を作成し、PCR値を変更する可能性があるステークホルダーのエンジンのMTMAPIをフックし、そして、エンジン証明書が監視するメモリの完全性チェック失敗を検出した際には失敗処理ルーチンを有効にする408。この処理の詳細は図5に示す。そして、制御をステークホルダーサービス126に戻す。他の動作が発生する一方、エンジン証明書が保護するメモリは変化していないことを検証する完全性チェッキングルーチンを呼び出す非同期のイベントジェネレーターが存在する。しかし、このルーチンが保護メモリにおいて変化を検出すれば失敗となり410、失敗ハンドラ120を呼び出す。次に、ステークホルダーサービス126は、適切なパラメータでMTM_VerifyRIMCertAndExtendAPIを呼び出す412ことによって、このステークホルダーが管理するPCRセット130のうち1つのPCRを変更することを希望する。ステークホルダーMTMがその要求を処理する前に、あらかじめインストールしたフック関数を呼び出し414、エンジンチェッカー200は失敗処理を無効にして416、PCRが変化する場合に非同期チェッキングが原因で失敗410とならないようにする。制御はステークホルダーMTM128に戻り、要求されたパラメータの検証とPCRの更新を行う418。そして、呼び出し側へ制御を戻す前に、フック終了を呼び出し420、エンジンチェッカーはエンジン証明書内に保持されているハッシュ値を更新して更新されたPCRを反映し、非同期チェッキング424における失敗処理を再び有効にする422。そして、呼び出し側のステークホルダーサービス126に制御を戻してもかまわない。次に、ステークホルダーのエンジンがAPIを介してこのステークホルダーが管理するPCRセット130のうち1つのPCRを変更できない場合の対応を説明する。ステークホルダーサービス126はTPM_ExtendAPIを呼び出す426。ステークホルダーMTMがその要求を処理する前に、あらかじめインストールしたフック関数を呼び出し428、エンジンチェッカー200は失敗処理を無効にして430、ステークホルダーのエンジン内PCR130が変化する場合に非同期チェッキングが原因で失敗424とならないようにする。制御はステークホルダーMTM128に戻り、TPM_Extend動作を行おうと試みるが失敗する432。失敗通知がフック終了関数に渡されるため434、エンジンチェッカー200は単に失敗処理を再び有効にするだけである436。なぜなら、エラーによって完全性チェック済みのPCRは変化しなかったため、422ですでに生成されたエンジン証明書は依然、PCRの期待値を表しているからである。最後に、制御はステークホルダーサービス126に戻る。なお、ステークホルダーMTM128は、データ格納部によって格納されているデータを修正するデータ修正部の一例である。データ修正部の一例であるステークホルダーMTM128は、上述のように、完全性チェック対象のデータを修正するために、プログラム格納部に格納された実行中のコードから要求を受信した場合に、a失敗処理部を無効にし、b完全性チェック値格納部のデータに要求された修正を行い、c完全性チェック値格納部のデータに対して新たな完全性チェック値を算出するよう完全性チェック値算出部に要求し、d新たな完全性チェック値を完全性チェック値格納部に格納し、かつ、e失敗処理部を再び有効にする。図5は、TPM_StartupAPIの間にエンジンチェッカーを初期化するフローチャートである。左側は子ステークホルダーエンジン122内で生じる処理であり、右側は本発明の一部を形成する親の機器メーカーエンジンのエンジンチェッカー200内で生じる処理である。TPM_StartupAPI500へのエントリ後、MTMのスタートアップ手順が先行技術で定義されたように実行される502。しかしながら、ルーチンは、戻る直前に、ステークホルダーが管理しているPCR130のメモリアドレスをDMエンジンへ渡す504。制御はDMエンジンのエンジンチェッカー200へ渡され、まず最初に、呼び出し側の子ステークホルダーエンジンの識別情報を決定する506。好ましい形態では、呼び出し側の関数のリターンアドレスを用いて図6に示した子エンジンテーブル600を検索する。ステークホルダーエンジン122と機器メーカーエンジン110とを区別するために選択された方法に従い、機器メーカーは、当該技術分野において周知の技術を用いて、例えばステークホルダーの仮想アドレス位置を機器メーカーの物理アドレスにマッピングする仮想環境内など呼び出し側の子のアドレスおよびPCRのアドレスを変換する必要があるかもしれない。子ステークホルダーエンジンの識別情報が確定されると、PCRのメモリアドレス位置情報を子エンジンテーブル600に付け加える508。次に、MD4、MD5、SHA1、またはSHA256などのアルゴリズムを用いて子ステークホルダーエンジン内のPCRのハッシュを算出する510。MD4やMD5などのアルゴリズムは衝突攻撃collisionattacksに対して脆弱であるが、PCRのメモリサイズは固定サイズで、また、ハッシュ計測期間が比較的短いため、このような攻撃に対する範囲は限定される。また、HMACによって保護されるエンジン証明書に基準ハッシュが格納されている好ましい形態では、ハッシュを長期間放置する必要もないので、この基準ハッシュは攻撃に対して脆弱ではない。したがって、当業者であれば、高性能の暗号化ハッシュ関数を選択しても、安全性のためにスピードをトレードオフすることにはならないことが分かるであろう。次のステップは、PCRの現在のハッシュに対してエンジン証明書を作成することである512。まず、tag302をTPM_TAG_RIM_CERTIFICATEに設定する。label304は、PCRチェッキング証明書を示すようにxxを子エンジンテーブルの値、yyを00に設定したShExx_yyに設定する。rimVersion306は0に、counterSelectionフィールド付のreferenceCounter308はMTM_COUNTER_SELECT_NONEに、state310は、このエンジンIDに対する子エンジンテーブル600に示されている通りPCRインデックスとPCRの現在値とを表すように設定する。そして、measurementPcrIndex312は子エンジンテーブル600に示されたPCRインデックスに設定し、measurementValue314は510で算出されたハッシュに、ただし、そのハッシュ値がフィールドサイズよりも短い場合はゼロで埋めて設定する。extensionDigestSize318はゼロに設定してextensionDigestフィールド320を空にする。この構造体は、欠けているフィールドを埋めて構造体に署名するMTM_InstallRIMAPIに渡されるので、その他のフィールドは空白のままでかまわない。次に、エンジンチェッカーはエンジン証明書を定期チェックするスケジュールを立てる514。このチェックのスケジューリングは、ウォッチドッグタイマとRIM_Run証明書に関するMobileReferenceArchitectureおよびTCGMobileAbstractionLayerの文献に記載されている。そのため、好ましい形態において、エンジンチェッカーは、このようなスケジューリングを用いて、プロセッサ要求のスパイクや他の動作の割り込みを避けるために低バックグラウンド処理としてチェックを行う。また、現在のPCR値を読み込む何らかのMTM関数の前など特定のイベントが発生する場合にはエンジン証明書をさらにチェックする。次に、エンジンチェッカーは、PCR値を変更する可能性のある子ステークホルダーエンジンAPIをフックする516。フックが必要なこれらのAPIは、TPM_Extend、TPM_PCR_ResetおよびMTM_VerifyRIMCertAndInstallなどであり、各APIへのエントリ時および各APIからの終了時ともに、インストールされたフックが呼び出しをエンジンチェッカーに付け加える。TCG仕様書の特定の実装では、同様にフックが必要なPCRを変更するその他の関数があってもかまわない。最後に、エンジンチェッカーは、処理失敗フラグ610をTRUEに設定することにより、作成されたエンジン証明書に対して失敗処理を有効にする520。これでエンジンチェッカーの初期化は完了するので、制御をステークホルダーのエンジンに戻して、スタートアップ手順中502に生成されたステータスコードを返す522ことによってTPM_Startup処理を完了する。図6は、機器メーカーエンジンが使用する子エンジンテーブルである。子エンジンテーブル600は4つの列で構成される。まず、エンジンIDフィールド602は、子のエンジン証明書用のtag302を作成するために用いる2つの文字コードを含む。したがって、テーブルの第1行目に対しtag302はShE01_00となる。エンジンアドレス範囲604は、子エンジンが作成されたアドレス範囲を示している。好ましい形態では、アドレス範囲は単一の連続したメモリブロックであるが、当業者であれば、連続していない複数のブロックを代わりに用いても、より複雑なアドレス方式を用いてもよいと分かるであろう。同様に、エンジンPCRアドレス範囲606は、子ステークホルダーエンジンのPCRが位置するアドレス範囲を示している。好ましい形態では、アドレス範囲は単一の連続したメモリブロックであるが、当業者であれば、子ステークホルダーエンジン自身が使用する仮想アドレスよりむしろ仮想化物理アドレスを格納する場合など、連続していない複数のブロックを代わりに用いても、より複雑なアドレス方式を用いてもよいと分かるであろう。DMPCR608は、子のエンジン証明書内のmeasurementPcrIndex312に用いられる予定の機器メーカーエンジンのPCRを含んでいる。DMPCR608列で示されているように、1以上の子エンジンが機器メーカーエンジン内で同じPCRを共有できる。このDMPCR列では、エンジンID01および02はPCR31を使用するが、エンジンID03はPCR30を使用する。さらに、機器メーカーエンジン内のどのPCRを使用するかは機器メーカーが決定し、子エンジンは使用するPCRを知っておく必要はない。処理失敗フィールド610は完全性失敗が強制エラーレスポンスを呼び出すべきかどうかを示している。このテーブルは機器メーカーによって管理されており、当業者であれば、テーブルの管理が行われる方法のうちの1つは、DM強制エンジンリスト用のTCGMobileReferenceArchitectureに記載されているものと同様の方法であり、かつ、テーブルを使用するときはいつでも検証用のテーブルの基準ハッシュを格納することによってテーブルの完全性を管理してもよいと分かるであろう。図7は、エンジンチェッカーにおけるタイマーイベントを処理するフローチャートである。その処理は全てDMエンジンエンジンチェッカーモジュール200内で行われ、先行技術に記載されているようなPRMVA用の既存のタイマーイベント処理から呼び出された際に700で開始する。ルーチンが完了し成功裏にイベントから戻る704まで、そのルーチンは子エンジンテーブル600の各行を処理する702。エラー処理については後述する。前述の通り、各行に対するエンジン証明書の名前はエンジンIDフィールド602から生成され、この名前を用いて対応するエンジン証明書をRIM証明書データベース内から見つける706。RIM証明書データベースとは、機器内にRIM証明書を全て格納したものであり、RIM証明書のサブセットがエンジン証明書である。TCGMobileAbstractionlayerには、このデータベースに保持されている証明書にアクセスするためのインターフェースが記載されている。もし証明書が見つからなければ708、制御を強制エラーレスポンスへ渡し710、先行技術に記載されているように適切に対処する。そうでない場合は、このエンジン証明書をチェックする必要があるかどうかイベントハンドラが決定する712。図5のステップ514に記載されているように、エンジンチェッカーは、エンジン証明書が保護するメモリの完全性を定期的にチェックするスケジュールを立てる514ので、イベントが発生するたびに全ての証明書をチェックする必要はない。チェックが必要なければ、子エンジンテーブルの次のエントリをチェックする。チェックする必要があれば、次に、エンジン証明書を検証する714。この検証では、stateフィールド310に機器メーカーのMTMのPCRの現状が記述されていることをチェックし、integrityCheckDataフィールド324が有効な署名であることをチェックする。もし検証失敗であれば716、制御を強制エラーレスポンスへ渡し710、先行技術に記載されているように適切に対処する。次に、エンジンPCRアドレス範囲606情報を用いて子エンジンのPCRの暗号化ハッシュを生成し718、その結果をエンジン証明書のmeasurementValueフィールド314と比較する720。値が一致すれば、データは改ざんされていなかったと決定されるので、子エンジンテーブルの次のエントリが処理される702。しかしながら、値が一致しない場合は、処理失敗フラグ610をチェックする。もしフラグがTRUEであれば、制御を強制エラーレスポンスへ渡し710、先行技術に記載されているように適切に対処する。もしFALSEであれば、ハッシュエラーを無視するので、制御をイベントハンドラの先頭に戻して子エンジンテーブルの次のエントリを処理してもよい702。図8は、516でインストールされたようなフックルーチンのエントリポイントから、子エンジンから機器メーカーのエンジンへの呼び出しを処理するフローチャートである。フックに入った後800、呼び出し側のアドレスを決定する802。好ましい形態によると、呼び出しアドレスは引数として渡されるが、当業者であれば、呼び出しスタックを調べてエントリポイントを決定するなど他の方法でも可能であると分かるであろう。このアドレス仮想環境におけるアドレス。仮想アドレスはまず物理アドレスに変換するを用いて子エンジンテーブルのエンジンアドレス範囲604フィールドを検索し、呼び出し側のアドレスに該当するアドレス範囲の行を見つける804。一致するものが見つからなければ806、制御を強制エラーレスポンスへ渡し808、先行技術に記載されているように適切に対処する。そうでない場合は、その行の処理失敗フラグ610をFALSEに設定し810、PCRを変更するAPIの処理を続けるために制御を呼び出し側へ戻す812。図9は、516でインストールされたようなフックルーチンの終了ポイントから、子エンジンから機器メーカーのエンジンへの呼び出しを処理するフローチャートである。フックに入った後900、呼び出し側のアドレスを決定する902。好ましい形態によると、呼び出しアドレスは引数として渡されるが、当業者であれば、呼び出しスタックを調べてエントリポイントを決定するなど他の方法でも可能であると分かるであろう。このアドレスを用いて子エンジンテーブルのエンジンアドレス範囲604フィールドを検索し、呼び出し側のアドレスに該当するアドレス範囲の行を見つける904。一致するものが見つからなければ906、制御を強制エラーレスポンスへ渡し908、先行技術に記載されているように適切に対処する。ここで、フックされたAPIからのリターンコードをチェックして、そのAPIが何れかのPCRの変更に成功したかどうか把握する910。TCGMobileTrustedModuleSpecificationおよびTCGMainPart3の文献には、コマンドごとに、PCRの変更が成功したことを示すTPM_SUCCESSのリターンコードを含む全リターンコード候補とPCRに変化がなかったことを示すその他全てのコードとが記載されている。このように、リターンコードがTPM_SUCCESSであれば子エンジンのPCRは変化しているので、子エンジンテーブル内の当該エントリに対して置換用エンジン証明書を作成するコードが呼び出される912。この呼び出しの後、または、フックされたAPIが失敗だった場合、現在のエントリは、処理失敗フラグをTRUEに設定させて914、図7に示したようなタイマーイベント中のエラー失敗処理を再起動する必要もある。図10は、子エンジンテーブル600内の所定のエントリ行に対して置換用エンジン証明書を作成する1000フローチャートであり、図4におけるエンジン証明書の更新および失敗処理の再有効化ステップ422について詳しく説明する。前述の通り、各行に対するエンジン証明書の名前はエンジンIDフィールド602から生成され、この名前を用いてRIM証明書データベース内から対応するエンジン証明書を見つける1002。もし証明書が見つからなければ1004、制御を強制エラーレスポンスへ渡し1006、先行技術に記載されているように適切に対処する。そうでない場合は、MTM_VeritfyRIMCertAndExtendAPIを用いてエンジン証明書を機器メーカーのMTMに拡張する1008。もし失敗すれば、制御を強制エラーレスポンスへ渡し1006、先行技術に記載されているように適切に対処する。成功した場合は、エンジン証明書のstateフィールド310を更新し1012、measurementPcrIndex312で示されるPCRにその変化を反映させる。次に、エンジンPCRアドレス範囲606情報を用いて子エンジンのPCRの暗号化ハッシュを生成し1014、その結果をエンジン証明書内のmeasurementValueフィールド314に代入する1016。次に、エンジン証明書のrimVersionフィールド306をインクリメントして1018エンジン証明書の新バージョンを示し、先行技術に記載されているようなMTM_InstallRIMAPIを用いて機器メーカーのMTMに新たなRIM証明書へ署名するよう要求する1020。RAM上の旧エンジン証明書を、TCGMobileAbstractionLayerに記載されているAPIを用いてRIM証明書データベース内の新たに生成された証明書で置換する1022。最後に制御を呼び出し側へ戻す1024。当該システムにおける他の好ましい実施形態では、APIが終了するまで待機してエンジン証明書を更新するわけではない。タイマーイベント中に置換用エンジン証明書を作成するフローチャートを図11に示す1100。このフローチャートは図7を基にしており、PCRのハッシュ値が一致しないことを検出した後に変更点となる機能が存在するが、処理失敗フラグ610はFALSEに設定される722。エラーを無視するのではなく、むしろ子エンジンテーブル内の当該エントリに対して置換用エンジン証明書を作成する図10で示したようなコードを呼び出す1102。次に、処理失敗フラグをTRUEに設定する1104。このようにして、フック終了関数を呼び出すまで更新を先延ばしにするのではなく、むしろPCRのさらなる変化を防ぐ。図12は、当該他の実施形態に対するフック終了関数のフローチャートであり、図9のフローチャートを基にしている。PCRを変更する子関数に対するフック関数1200に1つ追加されたステップは、処理失敗フラグの状態をチェックする1202ことである。もしフラグがFALSEに設定されていれば、それはタイマーイベントがまだ実行されていないことを意味するので、置換用エンジン証明書の生成912を行う必要があるかもしれない。もしフラグがTRUEに設定されていれば、タイマーイベントは実行済みであり、新たなエンジン証明書が生成済みなので、追加処理は必要ない。当該システムにおける他の好ましい実施形態では、APIのパラメータで記述されたPCRの変化しか行われていないことを確実にするために、エンジンチェッカー200は、APIの動作をシミュレートすることによってフックされたAPIの結果を予測する。つまり、エンジンチェッカー200は、データ修正部による動作の結果を予測する予測部の一例である。先に述べたように、フックされたAPIは、TPM_Extend、TPM_PCR_ResetおよびMTM_VerifyRIMCertAndInstallなどである。図13は、図6に示されたテーブルを基にした、当該実施形態に対して機器メーカーエンジンが使用する子エンジンテーブルである。子エンジンテーブル1300は4つの列で構成される。まず、エンジンIDフィールド602は、子のエンジン証明書用のtag302を作成するために用いる2つの文字コードを含む。したがって、テーブルの第1行目に対しtag302はShE01_00となる。エンジンアドレス範囲604は、子エンジンが作成されたアドレス範囲を示している。好ましい形態では、アドレス範囲は単一の連続したメモリブロックであるが、当業者であれば、複数の連続していないブロックを代わりに用いても、より複雑なアドレス方式を用いてもよいと分かるであろう。同様に、エンジンPCRアドレス範囲606は、子エンジンのPCRが位置するアドレス範囲を示している。好ましい形態では、アドレス範囲は単一の連続したメモリブロックであるが、当業者であれば、複数の連続していないブロックを代わりに用いても、より複雑なアドレス方式を用いてもよいと分かるであろう。DMPCR608は、子のエンジン証明書内のmeasurementPcrIndex312に用いられる予定の機器メーカーエンジンのPCRを含んでいる。予測エンジン証明書フィールド1302には予測エンジン証明書の名前またはNULLが保持される。NULLは保留中の予測がないということである。予測エンジン証明書は、図3に示したエンジン証明書用のフォーマットと同一のフォーマットである。このテーブルは機器メーカーによって管理されており、当業者であれば、テーブルの管理が行われる方法のうちの1つはDM強制エンジンリスト用のTCGMobileReferenceArchitectureに記載されているものと同様の方法であり、かつ、テーブルを使用するときはいつでも検証用のテーブルの基準ハッシュを格納することによってテーブルの完全性を管理してもよいと分かるであろう。図14は、516でインストールされたようなフックルーチンのエントリポイントから、子エンジンから機器メーカーのエンジンへの呼び出しを処理するフローチャートであり、図8の処理を基にしている。フックに入った後1400、呼び出し側のアドレスを決定する802。好ましい形態によると、呼び出しアドレスは引数として渡されるが、当業者であれば、呼び出しスタックを調べてエントリポイントを決定するなど他の方法でも可能であると分かるであろう。このアドレスを用いて子エンジンテーブルのエンジンアドレス範囲604フィールドを検索し、呼び出し側のアドレスに該当するアドレス範囲の行を見つける804。一致するものが見つからなければ806、制御を強制エラーレスポンスへ渡し808、先行技術に記載されているように適切に対処する。そうでない場合は、結果予測関数を呼び出し1402、これが成功すれば、PCRを変更するAPIの処理を続けるために制御を呼び出し側へ戻す812。図15は、所定のエンジンにおける所定のPCRを変更する動作結果を予測するフローチャートである。結果予測関数へのエントリ1500時に、対応する現在のエンジン証明書を見つける1502。もし証明書が見つからなければ、制御を強制エラーレスポンスへ渡し1506、先行技術に記載されているように適切に対処される。見つかる場合は、エンジン証明書のstateフィールド310のサブフィールドであるpcrSelectionに記述されている機器メーカーの現在のPCRを機器メーカーのMTMから読み出す1508。measurementPCRIndex312に記述されているPCRインデックスのコピーにmeasurementValue314の値を用いて合成ハッシュ計算を行うことにより、エンジン証明書に記述されている拡張動作をシミュレートする1510。そして、PCRのコピーは算出されたハッシュを有し、これらのハッシュは、stateフィールド310のサブフィールドであるdigestAtReleaseに代入される1512。この新たな状態を、新しいラベルとともに、すでに検索されたエンジン証明書のコピーへ与える1514。次に、エンジンPCRアドレス範囲606フィールドを用いて子のPCRのコピーを作成する1516。この関数に渡された動作を子のPCRのコピー上でシミュレートする1518。フックされた関数の動作をシミュレートするために、先行技術にかかる動作の記述を参照する。例えば、TCGMobileTrustedModuleSpecificationによると、MTM_VerifyRIMCertAndExtendAPIは、このAPIに引数として渡されるRIM証明書のmeasurementPcrIndexフィールドに示されたPCRを、既存値プラスmeasurementValueフィールドに保持されている値に累積ハッシュ演算を行うことによって変換する。この変換は1516で検索された子のPCRのコピーに適用される。そして、その結果得られたPCRのハッシュを算出する1520。この新たな値は、エンジン証明書のコピーのmeasurementValueフィールドに代入され1522、rimVersionフィールドをインクリメントする1524。機器メーカーのMTM内にあるMTM_InstallRIMAPIを用いることによって、エンジン証明書のコピーは追加の署名を有し1526、子エンジンテーブル1300の予測エンジン証明書フィールド1302にこの証明書のラベルを付け加える1528。最後に、新たな予測エンジン証明書をRIM証明書データベースへ保存し1530、ルーチンを終了する1532。上述のように、予測部は、aデータのコピーを作成するためにデータ格納部から完全性チェック対象のデータをコピーし、かつ、bデータのコピーに、予測部に対するパラメータで定義された動作を行う。図16Aおよび図16Bは、エンジンチェッカーにおけるタイマーイベントを処理するフローチャートである。タイマーイベントが発生すると1600、図7に従って処理される。しかしながら、この実施形態において追加した処理は、子エンジンのPCRの暗号化ハッシュを算出してエンジン証明書内のmeasurementValueフィールド314と比較した720後に行われる。失敗すると、予測エンジン証明書フィールドをチェックする1602。そして、このフィールドがNULLに設定されていれば予測された変化がないので、これは予期せぬエラーであり、制御を強制エラーレスポンスへ渡し710、先行技術に記載されているように適切に対処する。NULLでない場合は関連する証明書を検索する1604。この検索で指名されたエンジン証明書が見つからなければ1606、制御を強制エラーレスポンスへ渡し710、先行技術に記載されているように適切に対処する。見つかった場合は、718で算出されたPCRハッシュを図15のエンジン証明書に格納された予測ハッシュと比較する1608。新たな実ハッシュが予測ハッシュと一致しなければ、制御を強制エラーレスポンスへ渡し710、先行技術に記載されているように適切に対処する。一致する場合は、予測変化が起こったため、制御をイベントハンドラの先頭に戻して子エンジンテーブルの次のエントリを処理してもよい702。図17は、516でインストールされたようなフックルーチンの終了ポイントから、子エンジンから機器メーカーのエンジンへの呼び出しを処理するフローチャートである。フックに入った後1700、最初は図9に従い、呼び出し側のアドレスを決定する902。好ましい形態によると、呼び出しアドレスは引数として渡されるが、当業者であれば、呼び出しスタックを調べてエントリポイントを決定するなど他の方法でも可能であると分かるであろう。このアドレスを用いて子エンジンテーブルのエンジンアドレス範囲604フィールドを検索し、呼び出し側のアドレスに該当するアドレス範囲の行を見つける904。一致するものが見つからなければ906、制御を強制エラーレスポンスへ渡し908、先行技術に記載されているように適切に対処する。次に、予測エンジン証明書フィールド1302をチェックし1702、それがNULLであれば、予測エンジン証明書はないので、ルーチンは戻ることができる916。予測エンジン証明書がある場合は、フックされたAPIからのリターンコードをチェックして成功したかどうかを把握する910。成功していれば、子エンジンのPCRは変化したので、子エンジンテーブルの当該エントリに対してエンジン証明書を予測エンジン証明書で置換するコードを呼び出す1704。この呼び出しの後、または、フックされたAPIが失敗の場合は、子エンジンテーブルの現在のエントリは予測エンジン証明書フィールドをNULLに設定させて1706、予測がもはや有効ではないことを示す必要がある。ここで、コードは呼び出し側に戻ることができる916。データ修正部の一例であるステークホルダーMTM128は、上述のように、完全性チェック対象のデータを修正するために、プログラム格納部に格納された実行中のコードから要求を受信した場合に、a失敗処理部を無効にし、b要求の結果を予測するように予測部に要求し、c予測結果に対して予測完全性チェック値を算出するよう完全性チェック値算出部に要求し、d完全性チェック値格納部のデータに要求された修正を行い、e完全性チェック対象のデータに対して新たな完全性チェック値を算出するよう完全性チェック値算出部に要求し、f新たな完全性チェック値が予測完全性チェック値と等しくなければ、エラーを記録するよう失敗処理部に要求し、g格納されている完全性チェック値を新たな完全性チェック値で更新するよう完全性チェック部に要求し、かつ、h失敗処理部を再び有効にする。図18は、子エンジンテーブル1300内の所定のエントリ行に対してエンジン証明書を渡された予測エンジン証明書で置換する1800フローチャートである。図10に対して説明した通り、各行に対するエンジン証明書の名前はエンジンIDフィールド602から生成され、この名前を用いてRIM証明書データベース内から対応するエンジン証明書を見つける1002。もし証明書が見つからなければ1004、制御を強制エラーレスポンスへ渡し1006、先行技術に記載されているように適切に対処する。そうでない場合は、MTM_VeritfyRIMCertAndExtendAPIを用いてエンジン証明書を機器メーカーのMTMに拡張する1008。もし失敗すれば、制御を強制エラーレスポンスへ渡し1006、先行技術に記載されているように適切に対処する。そうでない場合は、渡された予測エンジン証明書のlabelフィールド302を1002で検索されたエンジン証明書のlabelフィールドに設定し1802、先行技術に記載されているようなMTM_InstallRIMAPIを用いて機器メーカーのMTMに新たなRIM証明書へ署名するよう要求する1804。最後に、RIM証明書データベース内の前回のエンジン証明書を予測エンジン証明書で置換し1806、制御を呼び出し側へ戻す1024。図19Aは、先行技術にかかるリモート認証の概要を示す。3つの動作主は、キー証明書の発行および検証を担当するプライバシー証明機関1902と、モバイル機器上のステークホルダーエンジン122と、ステークホルダーエンジン122に認証を要求するチャレンジャー1900である。これらの動作主間の3つの重要な相互作用として、まず、ステークホルダーエンジン122は、プライバシー証明機関において自分自身で生成するAIK証明書を登録し1950、そして、チャレンジャー1900からのリモート認証要求に応答してAIKで署名されたPCR状態およびプライバシー証明機関1902によって証明されたAIK証明書を返す1952。そして最後に、チャレンジャー1900がプライバシー証明機関1902でAIK証明書を検証する1954。図19Bにおいて、先行技術にかかるリモート認証を詳細に説明する。4つの動作主は、チャレンジャー1900として機能するリモートサービスと、プライバシー証明機関1902と、機器上のステークホルダーの信頼性のあるソフトウェアスタックTSSや抽象化レイヤなど1904と、機器上のステークホルダーのMTM1906とである。TSSは、先行技術で説明されているような信頼性のあるモジュールとアプリケーションとのインターフェースを処理するステークホルダーサービス126および136の一部である。図19Aのステークホルダーエンジン122は、これから説明するモバイル機器の動作をさらに詳細に説明できるよう、2つの別個のコンポーネント1904および1906に分けられている。チャレンジャー1900は、信頼性のあるコンポーネントの有無にかかわらず、機器が使用したいサービスを提供するサーバーでも、別のピア装置でも構わず、また、スマートカードなどの周辺機器や計算装置の他の形態でも構わない。段階は2つあり、第1段階のプロビジョニング1908では、ステークホルダーがAIK認証識別キーを作成してそれをプライバシーCAで登録する。第2段階は認証そのものである1910。先行技術に記載されているように、AIKは、証明された信頼性のあるモジュールによって認証要求が確かに処理されたという証拠として利用可能な公に知られた証明書を有する信頼性のあるモジュールTPMまたはMTMが所有するキーである。機器がAIKのプロビジョニングを終了した時点で、複数の認証要求をサポートできるようになる。このプロビジョニング処理は、機器の第1起動などの時点や、認証を行いたいがAIKがないことを検出するプログラムの要求時、または、ユーザが機器を認証準備OKとして明示的に開始されたアプリケーションによる要求から行われる。ステークホルダーTSS1904内にAIKを作成する処理が呼び出された時点で、まず、TSSは、先行技術に記載されているようなTPM_MakeIndentityAPIを用いてMTMがAIKを作成するよう要求する1912。そして、TSSは、このキーをX.509または他のフォーマットで記述した適切なAIK証明書を作成し1914、その証明書をプライバシーCAに引き渡す1916。プライバシーCAはキー構造および機器の権限を検証し、証明書に副署してそれをステークホルダーTSSへ返す。リモート認証を行うために、ステークホルダーTSSへの通信経路をどのように確立するか把握しているチャレンジャーは、まずランダムにノンスを生成し1918、そして、認証要求におけるノンスをステークホルダーに送信する1920。TSSは、先行技術に記載されているようなTPM_Quote2APIを用いて、ノンスと共にMTM内のPCRのサブセットの引用にMTMがAIKで署名するよう要求する1922。1914で生成された署名キーに対するAIK証明書および引用結果をチャレンジャーに返す1924。チャレンジャーは、返されたAIKを用いて署名が生成されたことを検証し1926、プライバシーCAでAIKが確実に有効に署名されたAIKであることを検証する1928。図20Aは、本発明にかかるリモート認証について示す。3つの動作主は、AIKおよびその証明書およびTPM_VERIFICATION_KEYキー証明書の作成を担当するステークホルダー2000と、モバイル機器上のステークホルダーエンジン122と、ステークホルダーエンジン122に認証を要求するチャレンジャー1900である。チャレンジャー1900は、リモート認証チャレンジを発行するチャレンジャー部を有するチャレンジャーデバイスの一例である。チャレンジャー部は、認証キーの公開部分を用いて認証部にチャレンジを発行する。これらの動作主間の3つの重要な相互作用として、まず、ステークホルダー2000がAIKを作成し、それをステークホルダーエンジン122に組み込む2050。ステークホルダー2000は、認証キーを発行するキー発行部を有するキー発行デバイスの一例である。キー発行部は、チャレンジャーに認証キーを発行する。好ましい形態では、この組み込み処理は機器の製造中に行われる。次に、ステークホルダー2000はそのAIK証明書とTPM_VERIFICATION_KEYとをチャレンジャー1900に引き渡し2052、最後に、ステークホルダーエンジン122は、リモート認証要求に応じて、AIKで署名されたPCR状態であって、チャレンジャー1900から送信されたTPM_VERIFICATION_KEYで暗号化されたそのPCR状態を、チェレンジャーに返す2054。ステークホルダーエンジン122は、チャレンジに応答する認証部を有する認証デバイスの一例である。認証部は、チャレンジャーのチャレンジに基づき認証を行い、かつ、認証キーの公開部分で暗号化された認証結果をチャレンジャーに返す。図20Bにおいて、本発明にかかるリモート認証を詳細に説明する。4つの動作主が、チャレンジャー1900として機能するリモートサービスと、機器外のステークホルダーサーバー2000と、機器上のステークホルダーの信頼性のあるソフトウェアスタックまたは抽象化レイヤなど1904と、機器上のステークホルダーのMTM1906とである。図20Aのステークホルダーエンジン122は、これから説明するモバイル機器の動作をさらに詳細に説明できるよう、2つの別個のコンポーネント1904および1906に分けられている。チャレンジャー1900は、信頼性のあるコンポーネントの有無にかかわらず、機器が使用したいサービスを提供するサーバーでも、別のピア装置でも構わず、また、スマートカードなどの周辺機器や計算装置の他の形態でもかまわない。ステークホルダーは機器メーカーまたはマルチステークホルダーモデルで定義されたような他のステークホルダーのどちらでも構わない。段階は3つあり、第1段階の製造段階では、ステークホルダーがAIK認証識別キーを作成してそれを機器に組み込み2002、第2段階のプロビジョニング2004では、ステークホルダーが、先行技術に記載されているようにTPM_VERIFICATION_KEYを作成してそれをチャレンジャーに引き渡す。なお、認証キーAIKの公開部分は、そのキーが認証デバイスに既知のキーであるという証拠を有する。認証キーの公開部分の正当性は、認証部によって確認される。また、認証キーは、認証デバイスにとって既知であるという証拠が、認証デバイスに既知の第2キーTPM_VERIFICATION_KEYへの参照を含んでいる。そして、第3段階は認証そのものである2006。本発明のその他の好ましい実施形態ではAIK証明書をプライバシー証明機関で登録しているが、先行技術によると、プライバシーCAは必要ではない。ステークホルダーがAIKを組み込んだ装置を製造し終えた時点で、1以上のチャレンジャーに対してTPM_VERIFICATION_KEY構造体のプロビジョニングをサポートできるようになる。ステークホルダーがチャレンジャーに対するTPM_VERIFICATION_KEYのプロビジョニングを終了した時点で、チャレンジャーは複数の認証要求を実行してもよい。製造プロセスは、ハードウェアの製造中や機器が顧客にリリースされる前の他の処理などの時点で行われる。プロビジョニング処理は、ステークホルダーの装置に認証チャレンジを行いたいと第三者がステークホルダーに要求した場合などの時点で行われる。製造時2002に、ステークホルダーはAIKおよび一致する証明書を作成し2008、ステークホルダーのMTM内にAIKの秘密部分を組み込む2010。ハードウェアMTMに対し、これはセキュアなメモリへ物理的に情報を書き込むことであってもよく、ソフトウェアMTMに対しては、実行ファイルへデータを投入しそれを署名することであってもよい。プロビジョニング中2004に、RVAIから導出される、MobileTrustedModuleSpecificationで定義されているようなTPM_VERIFICATION_KEY2100が作成される2012。usageFlags2104をTPM_VERIFICATION_KEY_USAGE_REMOTE_ATTESTATIONに設定して、暗号化認証要求に対してこのキーを用いることを示す。好ましい形態において、keyAlgorithmフィールド2112は、データが対称的な暗号化アルゴリズムに対するキーであるため秘密キー部分はないことを示す。その他の好ましい形態においては、公開キーを用いるため秘密キー部分もある。指示された親キーを用いてTPM_VERIFICATION_KEY2100構造体に署名する。好ましい形態では、この親キーはステークホルダーに秘密である。作成されたAIK証明書と、TPM_VERIFICATION_KEYと、存在すれば、TPM_VERIFICATION_KEYの秘密キーとを、認証チャレンジャーとして機能する第三者に引き渡す2014。送信されてくるデータにより受信側は認証要求の結果を把握することができるので、伝送中のデータの安全性は維持されるはずである。電子的な伝送に対し、SSLベースのシステムは移動しているデータを確実に保護すると考えられ、物理的な伝送に対しては、帯域外の異なる経路を介して一致したキーで伝送媒体上のデータを暗号化しても構わない。リモート認証2006を行うために、ステークホルダーTSSへの通信経路をどのように確立するか把握しているチャレンジャーは、まずランダムにノンスを生成し2016、そして、認証要求におけるそのノンスとすでにセットアップされているTPM_VERIFICATION_KEYとをステークホルダーに送信する2018。keyAlgorithm2112が対称的である場合、当業者であれば、SSLベースの体系を用いるなど、通信経路を保護する必要があると分かるであろう。TSSは、先行技術に記載されているようなTPM_Quote2APIを用いて、ノンスと共にMTM内のPCRのサブセットの引用に製造時に組み込まれたAIKでMTMが署名するよう要求する2020。次に、チャレンジャーから引き渡されたTPM_VERIFICATION_KEYをステークホルダーのMTMに読み込み2022、その処理が成功したことをチェックすることで検証する。汎用的な暗号化に対しては、MTMはTPM_VERIFICATION_KEYを用いることができないため、引用動作の結果2020をステークホルダーのTSS内で暗号化し2024、チャレンジャーに返す2026。チャレンジャーは返されたメッセージを解読し2028、署名されたメッセージがすでにセットアップされているAIK証明書のキーで署名されたものであることを検証する2030。検証が成功すれば、ここで、チャレンジャーはステークホルダーのMTMのPCRの状態をリモート認証する。なお、チャレンジャー部が発行した認証チャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する。図21は、TCGMobileTrustedModuleSpecificationの先行技術にかかるTPM_VERIFICATION_KEY構造体である。まず、tag2102はTPM_TAG_VERIFICATION_KEYを保持する。usageFlags2104はTPM_VERIFICATION_KEY_USAGE_REMOTE_ATTESTATIONのビットセットを有し、本発明では0x1000に定義される。parentId2106、myId2108、referenceCounter2110、keyAlgorithm2112、およびkeyScheme2114は先行技術に記載されている通りである。本発明によると、拡張データは定義されていないため、extensionDigestSize2116およびextensionDigest2118はそれぞれゼロおよび空で構わない。最後に、その他のフィールド、keySize2120、keyData2122、integrityCheckSize2124およびintegrityCheckData2126も先行技術に記載されている通りである。好ましい実施形態によれば、parentId2106はルートキーではなく中間キーであるため、ステークホルダーは多くのTPM_TAG_VERIFICATION_KEYをセットアップすることができるが、先行技術に記載されているような中間のTPM_TAG_VERIFICATION_KEYを無効にすることによってそれら全てを無効にすることができる。図22Aおよび図22Bは、本発明にかかるTPM_VERIFICATION_KEYの読み込みおよび検証を示している。この図は、図20のステップ2022を詳細に説明したものである。この再帰的ルーチンのエントリポイントではパラメータとして読み込まれるキーが必要である2200。まず、parentIdフィールド2106をチェックしてこのキーがルートキーであることを示すTPM_VERIFICATION_KEY_ID_NONEを保持するかどうかチェックする2202。ルートキーでなれけば、ルーチンは所定のparentIdでTPM_VERIFICATION_KEYの検索を試みる2204。先行技術によると、ステークホルダーは、システム上に存在するTPM_VERIFICATION_KEYの管理が求められる。親キーが見つからなければ2206、エラーが発生し、ルーチンはTPM_KEYNOTFOUNDエラーコードを返す2208。さらに、先行技術によると、ステークホルダーは、これらのキーの失効ステータスを管理することも求められる。ゆえに、キーが見つかれば、その失効ステータスもチェックする必要がある2210。キーが無効になったと判断されれば、ルーチンはTPM_AUTHFAILエラーコードを返す2212。このように、キー発行部は、認証キーに対する失効証明書を発行する。そして、認証部は、失効証明書を受信すると認証キーを無効にする。次に、親キーを読み込みかつ検証できるようルーチンに対する再帰的呼び出しを行う2214。つまり、認証部は、認証キーの親キーの公開部分の正当性を確認する。例えば、認証部は、さらに、認証部の状態を表す情報項目セットの値に対して認証を行う。このときの各項目は、認証部の特性を表す数値を有する。具体的には、各項目は、TrustedComputingGroupが定義したようなプラットフォーム設定レジスタPCRである。親の読み込みおよび検証が失敗すれば2216、ルーチンは失敗エラーコードを返す2218。成功した場合は、この関数に渡されたTPM_VERIFICATION_KEYをチェックしてキーがMTMに読み込み済みかどうか把握する2220。当該分野における周知の技術、好ましくはTPM_VERIFICATION_KEY_HANDLEへ変換するためのmyIdフィールド2108のマップなどを用いて、読み込まれたキーを記録する。キーが読み込み済みでなければ、MTM_LoadVerificationKeyAPIを呼び出し2222、読み込みおよび検証処理を実行する。読み込みが失敗すれば2224、ルーチンは失敗エラーコードを返す2218。成功した場合、好ましい実施形態では、myIdフィールド2108とTPM_VERIFICATION_KEY_HANDLEとのペアを、読み込まれたキーのマップへ付け加えることによって、返されたTPM_VERIFICATION_KEY_HANDLEを記録する2226。最後に、ルーチンは呼び出し側にTPM_SUCCESSコードを返して2228、再帰的呼び出しの場合は子キーの読み込みを続け、最上位の呼び出しの場合はキー階層を検証したと認証処理に報告する。図23Aは、本発明にかかるリモートマルチステーク認証の概要について示す。5つの動作主は、モバイル機器上のステークホルダーエンジン122用のAIKおよびその証明書およびTPM_VERIFICATION_KEYキー証明書の作成を担当するステークホルダー2000と、モバイル機器上の機器メーカーエンジン110用のAIKおよびその証明書の作成を担当する機器メーカー2300と、2つのエンジン112および110に認証を要求するチャレンジャー1900である。つまり、ステークホルダー2000および機器メーカー2300は、認証キーを発行するキー発行部を有するキー発行デバイスの一例である。また、チャレンジャー1900は、リモート認証チャレンジを発行するチャレンジャー部を有するチャレンジャーデバイスの一例である。認証デバイスは、チャレンジに応答する第1認証部の一例であるステークホルダーエンジン122と、チャレンジに応答する第2認証部の一例である機器メーカーエンジン110とを備える。また、認証デバイスは、さらに、第1認証部が第2認証部と通信できるようにするコネクタ部を有する。これらの動作主間の重要な相互作用として、まず、ステークホルダー2000がAIKを作成し、それをステークホルダーエンジン122に組み込み2350、そして、機器メーカー2300がAIKを作成し、それを機器メーカーエンジン110に組み込む2352。好ましい形態では、この組み込み処理は機器の製造中に行われる。次に、ステークホルダー2000はステークホルダーのAIK証明書とTPM_VERIFICATION_KEYとをチャレンジャー1900に引き渡し2354、機器メーカー2300は機器メーカーのAIK証明書をチャレンジャー1900に引き渡す2356。最後に、ステークホルダーエンジン122は、リモート認証要求に応じて、AIKで署名されたPCR状態であって、チャレンジャー1900から送信されたTPM_VERIFICATION_KEYで暗号化されたステークホルダーエンジンのPCR状態を、チェレンジャー1900に返す2358。要するに、キー発行部はチャレンジャーに認証キーを発行し、チャレンジャー部は、認証キーの公開部分を用いて第1認証部の一例であるステークホルダーエンジン122にチャレンジを発行する。第1認証部は、チャレンジャーのチャレンジに基づき、第1認証を行い、認証キーの公開部分で暗号化された第1認証結果をチャレンジャーに返す。そして、機器メーカーエンジン110は、リモートマルチステークホルダー認証要求に応じて、AIKで署名された機器メーカーエンジンのPCR状態をチャレンジャー1900に返す2360。要するに、コネクタ部は、第1認証部から第2認証部の一例である機器メーカーエンジン110へ第1認証結果を伝達し、チャレンジャー部は、第2認証部にチャレンジを発行し、第2認証部は、チャレンジャーのチャレンジおよびコネクタ部を介して伝達された第1認証結果に基づき第2認証を行い、かつ、第2認証結果をチャレンジャーに返す。図23Bにおいて、本発明にかかるリモートマルチステークホルダー認証に備えた製造およびプロビジョニングを詳細に説明する。ここで、チャレンジャーはステークホルダーのMTMの状態を問い合わせることを希望し、そして、その結果を機器メーカーのMTMで確認する。5つの動作主は、チャレンジャー1900として機能するリモートサービスと、機器外のステークホルダーサーバー2000と、機器上のステークホルダーのMTM1906と、機器外の機器メーカーサーバー2300と、機器上の機器メーカーのMTM2302とである。製造時に2304、機器メーカーはAIKおよび一致する証明書を作成し2308、機器メーカーのMTM内にAIKの秘密部分を組み込む2310。なお、認証キーAIKの公開部分は、そのキーが認証デバイスに既知のキーであるという証拠を有する。認証キーの公開部分の正当性は、第1認証部の一例であるステークホルダーエンジン122によって確認される。また、認証キーは、認証デバイスにとって既知であるという証拠が、認証デバイスに既知の第2キーTPM_VERIFICATION_KEYへの参照を含んでいる。ハードウェアMTMに対し、これはセキュアなメモリへ物理的に情報を書き込むことであってもよく、ソフトウェアMTMに対しては、実行ファイルへデータを投入しそれを署名することであってもよい。次に、ステークホルダーはAIKおよび一致する証明書を作成し2312、ステークホルダーのMTM内にAIKの秘密部分を組み込む2314。ハードウェアMTMに対し、これはセキュアなメモリへ物理的に情報を書き込むことであってもよく、ソフトウェアMTMに対しては、実行ファイルへデータを投入しそれを署名することであってもよい。プロビジョニング中2306に、RVAIから導出される、MobileTrustedModuleSpecificationで定義されているようなTPM_VERIFICATION_KEY2100が作成される2316。usageFlags2104をTPM_VERIFICATION_KEY_USAGE_REMOTE_ATTESTATIONに設定して、暗号化認証要求に対してこのキーを用いることを示す。好ましい形態において、keyAlgorithm2112は、対称的なキーであるため秘密キー部分はない。その他の好ましい形態においては、公開キーを用いるため秘密キー部分もある。指示された親キーを用いてTPM_VERIFICATION_KEY2100構造体に署名する。好ましい形態では、この親キーはステークホルダーに秘密である。作成されたAIK証明書と、TPM_VERIFICATION_KEYと、存在すれば、TPM_VERIFICATION_KEYの秘密キーとを、認証チャレンジャーとして機能する第三者に引き渡す2318。送信されてくるデータにより受信側は認証要求の結果を把握することができるので、伝送中のデータの安全性は維持されるはずである。電子的な伝送に対し、SSLベースのシステムは移動しているデータを確実に保護すると考えられ、物理的な伝送に対しては、帯域外の異なる経路を介して一致したキーで伝送媒体上のデータを暗号化しても構わない。機器メーカーに対しては、AIK証明書のみをプロビジョニングする2320。なぜなら、後述するように、機器メーカーのMTM用のTPM_VERIFICATION_KEYは必要ないからである。しかしながら、当業者であれば、他の実施形態において、機器メーカーのMTMを認証するためにTPM_VERIFICATION_KEYを用いてもよいと気づくであろう。図24Aおよび24Bにおいて、本発明にかかるリモートマルチステークホルダー認証を詳細に説明する。ここで、チャレンジャーはステークホルダーのMTMの状態を問い合わせることを希望し、そして、その結果を機器メーカーのMTMに確認する。5つの動作主は、チャレンジャーとして機能するリモートサービス1900と、機器上の信頼性のあるステークホルダーのソフトウェアスタック1904と、機器上のステークホルダーのMTM1906と、機器上の信頼性のある機器メーカーのソフトウェアスタック2400と、機器上の機器メーカーのMTM2302である。ただし、これから説明するモバイル機器の動作をさらに詳細に説明できるよう、図23Aのステークホルダーエンジン122は2つの別個のコンポーネント1904および1906に、図23Aの機器メーカーエンジン110は2つの別個のコンポーネント2400および2302に分けられている。図23に示されたステークホルダーサーバー2000および機器メーカーサーバー2300は、実際の認証に影響を及ぼさないため、本図では図示しない。図24Aにおいて、ステークホルダーTSS1904および下層の機器メーカーTSS2400への通信経路をどのように確立するか把握しているチャレンジャー1900がランダムにステークホルダーノンスを生成し2402、そして、認証要求におけるそのノンスとステークホルダーのすでにセットアップされているTPM_VERIFICATION_KEYとをステークホルダーに送信する2404と、リモートマルチステークホルダー認証2006が開始する。なお、チャレンジャー部が発行した第1認証部へのチャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する。keyAlgorithm2112フィールドがキーは対称的であると示す場合、当業者であれば、SSLベースの体系を用いるなど、通信経路を保護する必要があると分かるであろう。ステークホルダーTSSは、先行技術に記載されているようなTPM_Quote2APIを用いて、ステークホルダーノンスと共にMTM内のPCRのサブセットの引用に、製造時に組み込まれたステークホルダーのAIKでステークホルダーMTM1906が署名するよう要求する2406。次に、チャレンジャーから引き渡されたステークホルダーのTPM_VERIFICATION_KEYをステークホルダーのMTMに読み込み2408、その処理が成功したことをチェックすることによって検証する。つまり、第1認証部は、認証キーの親キーの公開部分の正当性を確認する。例えば、認証部は、さらに、第1認証部の状態を表す情報項目セットの値に対して認証を行う。このときの各項目は、第1認証部の特性を表す数値を有する。具体的には、各項目は、TrustedComputingGroupが定義したようなプラットフォーム設定レジスタPCRである。ステークホルダーTSSは機器メーカーTSS2400に引用動作の結果2406とステークホルダーノンスを通知する2410。そして、機器メーカーTSSは、報告された引用結果を検証し2412、ステークホルダーノンスとステークホルダーのPCR引用とを連結したもの、およびステークホルダーを表す識別子を格納する2414。これらの動作の詳細については後で説明する。汎用的な暗号化に対してTPM_VERIFICATION_KEYをMTMは用いることができないため、引用動作の結果2406をステークホルダーのTSS内で暗号化し2416、チャレンジャーに返す2418。チャレンジャーは返されたメッセージを解読し2420、署名されたメッセージがすでにセットアップされているステークホルダーAIK証明書のキーで署名されたものであることを検証する2422。検証が成功すれば、ここでチャレンジャーは、ステークホルダーのMTMのPCRの状態に対するリモート認証を完了し、図24Bに示すように、機器メーカーのMTMにおいてリモートマルチステークホルダー認証を実行できる状態になっている。次に、チャレンジャー1900は、ランダムに機器メーカーノンスを生成し2424、そのノンス、および前もって生成したステークホルダーノンス2402と結果として得られたPCR引用データ2406とを連結したものの暗号化ハッシュを、リモートマルチステークホルダー認証要求として送信する2426。なお、チャレンジャー部が発行した第2認証部へのチャレンジは、さらに、返すための認証情報のサブセットを表す表示を有する。好ましい実施形態では、暗号化ハッシュルーチンはSHA1である。機器メーカーTSSは、すでに行った有効なステークホルダー認証をこの暗号化ハッシュが表していることを検証する2428。この動作の詳細については後で説明する。要するに、第2認証部は、第2認証部の状態を表す情報項目セットの値に対して認証を行う。このときの各項目は、第2認証部の特性を表す数値を有する。具体的には、各項目は、TrustedComputingGroupが定義したようなプラットフォーム設定レジスタPCRである。認証に失敗すれば、好ましい実施形態では、機器メーカーTSSは適切なエラーで認証セッションを終了する。次に、機器メーカーTSSは、前もって生成したステークホルダーノンス2402と結果として得られたPCR引用データ2406と機器メーカーノンス2424とを連結したものの暗号化ハッシュを評価することによって新たな機器メーカーノンスを算出する2430。この新たなノンスが、先行技術に記載されているようなTPM_Quote2APIを用いて、製造時に組み込まれた機器メーカーのAIKへの処理とともに機器メーカーMTM2302へ引き渡されて、MTM内のPCRのサブセットの署名済み引用をノンスとともに生成する2432。この署名済みの新たなノンスプラスPCR引用データをチャレンジャーに返す2434と、このチャレンジャーは、機器メーカーによってすでにセットアップされているAIK証明書を用いて署名を検証することができる2436。また、チャレンジャーは、機器メーカーTSSが2430で行ったのと同じ計算をローカルに行うことにより返された新たなノンスを検証する2440ことによって、チャレンジャーが2404で送信したノンスをステークホルダーTSSは機器メーカーTSSに正確に通知したことがまた証明される。最後に、機器メーカーが成功裏にリモートマルチステークホルダー認証プロトコルを完了して以降、機器メーカーTSSは、2414においてすでに記録されているステークホルダーノンスおよびPCRを使用していることに注意する2438。この動作の詳細については後で説明する。図25は、本発明にかかる子ステークホルダーエンジンから報告された引用結果の検証について示しており、ステップ2412の処理を詳しく説明したものである。つまり、第2認証部は、伝達された第1認証結果を検証する。具体的には、第2認証部は、第1認証部の認証情報に直接アクセスしてもよい。子ステークホルダーのTSSから渡された先行技術で定義されたようなTPM_PCR_INFO_SHORT構造体は報告された引用結果を検証する2500関数に対するパラメータである。まず、呼び出し側のアドレスを決定する2502。好ましい形態によると、呼び出しアドレスは引数として渡されるが、当業者であれば、呼び出しスタックを調べてエントリポイントを決定するなど他の方法でも可能であると分かるであろう。このアドレスを用いて子エンジンテーブルのエンジンアドレス範囲604フィールドを検索し、呼び出し側のアドレスに該当するアドレス範囲の行を見つける2504。一致するものが見つからなければ2506、制御を強制エラーレスポンスへ渡し2508、先行技術に記載されているように適切に対処する。見つかった場合は、エンジンPCRアドレス範囲フィールド606データを用いて子PCRを子MTMのアドレス空間からコピーし2510、そして、渡されたTPM_PCR_INFO_SHORT内のpcrSelectionフィールドを用いてコピーされたPCRのハッシュ値を求める2512。この算出されたハッシュが、渡されたTPM_PCR_INFO_SHORT内のdigestAtReleaseフィールドと等しくなければ2514、ルーチンは失敗を示す値を返す2516。そうではなくこれらのハッシュが等しい場合は、子エンジンテーブルの現在の行のエンジンIDフィールド602および渡されたTPM_PCR_INFO_SHORTパラメータを保留認証テーブルに付け加え2518、ルーチンは成功を示す値を返す2520。当業者であれば、実行が成功した場合にパラメータが保留認証テーブルへ付け加えられる限り、全く検証しないなどの代替検証方法を用いても構わないと分かるであろう。図26は、現在進行中の認証要求を保持する保留認証テーブル2600である。まず、エンジンIDフィールド602は保留中の認証要求があるステークホルダーエンジンを表す2つの文字コードを含み、次に、ステークホルダーノンスフィールド2602はチャレンジャーが認証ルーチンへ供給したノンスを保持する。そして最後に、TPM_PCR_INFO_SHORTフィールド2604はステークホルダーTSSが機器メーカーTSSに報告した検証済み認証値を保持する。ただし、ステークホルダーノンスフィールド2602はランダム値であるため、何の問題も引き起こすことなく同じエンジンIDがテーブルに1回以上現れる可能性はある。図27は、機器メーカーTSSへのリモートマルチステークホルダー認証要求が有効な子ステークホルダー値を含んでいることを検証する図示である。保留中のマルチステークホルダー認証用の、子ステークホルダーに用いたノンスの暗号化ハッシュだと主張するチャレンジャーによって供給された値と子ステークホルダーが報告したPCR値とがルーチンに渡される2700。保留認証テーブル2600の各行ごとに2702、TPM_PCR_INFO_SHORTフィールド2604のdigestAtReleaseと連結されたステークホルダーノンスフィールド2602のハッシュを算出し2706、渡された値と比較する2708。2つの値が等しければ、渡された値はまさに保留中のマルチステークホルダー認証要求を表しているので、成功を示すステータスフラグとともにステークホルダーノンスフィールド2602およびTPM_PCR_INFO_SHORTフィールド2604を呼び出し側へ返す2710。一方、全ての行をチェックして一致しなければ、渡された値は保留中のマルチステークホルダー認証要求を表していないので、失敗を示すステータスフラグを代わりに返す2704。図28は、保留中のリモートマルチステークホルダー認証要求が実行されたことに注意する図示である。使用されていたステークホルダーノンスおよびPCR引用値がルーチンに渡される2800。保留認証テーブル2600の各行ごとに2802、ルーチンに渡されたステークホルダーノンスおよびPCR引用値を保留認証テーブル2600の現在の行で対応するデータと比較する2806。一致するならば、使用済みとしてその行に印を付ける必要があるが、好ましい形態では、現在の行をテーブルから削除して2808、ルーチンを成功裏に呼び出し側へ戻す2810。一致しなければ、次の行をチェックする。一致することなくテーブルの最後に到達すれば、ルーチンをエラーとともに呼び出し側へ戻す2804。当該システムにおける他の好ましい実施形態では、ステークホルダーエンジンごとにリモートマルチステークホルダー認証を行う場合、機器メーカーTSSはチャレンジャーへ折り返し報告するPCRを制限する。図29は、子エンジンPCRアクセステーブル2900である。まず、エンジンIDフィールド602はステークホルダーエンジンを表す2つの文字コードを含み、そして、TPM_PCR_SELECTIONフィールド2902は、リモートマルチステークホルダー認証要求が引用できる機器メーカーのMTM内のPCRを示す。テーブル内に、好ましい実施形態では文字列に設定される、決して起こり得ないエンジンID値となるよう定義されたEID_DEFAULT2904に設定されたエンジンIDフィールドの行が存在しても構わない。この行には、検索したエンジンIDがテーブル内に存在しない場合に用いるTPM_PCR_SELECTION2902が記述される。図30は、本発明にかかるリモートマルチステークホルダー認証に備えた製造プロセスのサブセットであり、リモートマルチステークホルダー認証を行う場合に機器メーカーがチャレンジャーへ折り返し報告するPCRを制限するため実行するステップに着目したものである。3つの動作主は、機器外の機器メーカーサーバー2300と機器上の機器メーカーのTSS2400と機器上の機器メーカーのMTM2302である。製造時に2304、機器メーカーはAIKおよび一致する証明書を作成し2308、機器メーカーのMTM内にAIKの秘密部分を組み込む2310。ハードウェアMTMに対し、これはセキュアなメモリへ物理的に情報を書き込むことであってもよく、ソフトウェアMTMに対しては、実行ファイルへデータを投入しそれを署名することであってもよい。次に、機器メーカーは、機器上に存在する可能性がある、既知のステークホルダーエンジン全てに対して子エンジンアクセステーブルを作成し3000、各行のTPM_PCR_SELECTIONフィールド2902に所望の値を代入することにより、各エンジンがアクセス許可されるPCRを選択する。そして、これを機器メーカーのTSS内に組み込む3002。当業者であれば、テーブルを完全に保護する必要があり、暗号化署名などの当該技術分野において周知の技術はこの目的として十分であると分かるであろう。図31において、本発明にかかるリモートマルチステークホルダー認証の一部を説明する。ここで、チャレンジャーはステークホルダー認証の結果を機器メーカーのMTMで確認することを希望する。ステークホルダーを相手にしたこの認証は図24Aに示したシーケンスに従うので、本実施形態において、図24Bをこの図で置き換える。上述したように、チャレンジャー1900は、ランダムに機器メーカーノンスを生成し2424、そのノンス、および前もって生成したステークホルダーノンス2402と結果として得られたPCR引用データ2406とを連結したものの暗号化ハッシュを、リモートマルチステークホルダー認証要求として送信する2426。好ましい実施形態では、暗号化ハッシュルーチンはSHA1である。機器メーカーTSSは、すでに行った有効なステークホルダー認証をこの暗号化ハッシュが表していることを検証する2428。この動作の詳細については後で説明する。認証に失敗すれば、好ましい実施形態では、機器メーカーTSSは適切なエラーで認証セッションを終了する。次に、機器メーカーTSSは、前もって生成したステークホルダーノンス2402と結果として得られたPCR引用データ2406と機器メーカーノンス2424とを連結したものの暗号化ハッシュを評価することによって新たな機器メーカーノンスを算出する2430。図27で説明されているように、ステップ2428および2430中に子ステークホルダーエンジンのエンジンIDを決定する。このエンジンIDを用いて子エンジンアクセステーブル2900のエンジンIDフィールド602を調べて、対応するTPM_PCR_SELECTIONフィールド2902を検索する3100。エンジンIDが見つからなければ、代わりにEID_DEFAULT行を用いる。EID_DEFAULT行もなければ、空のTPM_PCR_SELECTIONを使用する。次に、引用するPCRサブセットの値を求める3102。好ましい実施形態では、サブセットは必ずちょうど子エンジンアクセステーブルの関連する行内のフィールドであるため何も処理は必要ないが、他の実施形態においては、チャレンジャーが所望のTPM_PCR_SELECTIONを認証要求に付け加え、2つのTPM_PCR_SELECTIONpcrSelectフィールド間で論理積演算を行うことによって許可されなかったフィールドをチャレンジャーの要求から取り除く。次に、新たなノンスおよび算出されたPCRサブセットが、先行技術に記載されているようなTPM_Quote2APIを用いて、製造時に組み込まれた機器メーカーのAIKへの処理とともに機器メーカーMTM2302へ引き渡されて、MTM内のPCRのサブセットの署名済み引用をノンスとともに生成する3104。この署名済みの新たなノンスプラスPCR引用データをチャレンジャーに返す2434と、このチャレンジャーは、機器メーカーによってすでにセットアップされているAIK証明書を用いて署名を検証することができる2436。また、チャレンジャーは、機器メーカーTSSが2430で行ったのと同じ計算をローカルに行うことで返された新たなノンスを検証する2440ことによっても、チャレンジャーが2404で送信したノンスをステークホルダーTSSは機器メーカーTSSへ正確に通知したと証明される。さらに、返されたPCR引用情報にはTPM_PCR_SELECTIONを含むTPM_PCR_INFO_SHORTが含まれるため、チャレンジャーはどのPCRサブセットが実際に引用されたのかを発見することができる。最後に、機器メーカーが成功裏にリモートマルチステークホルダー認証プロトコルを完了して以降、機器メーカーTSSは、2414においてすでに記録されているステークホルダーノンスおよびPCRを使用していることに注意する2438。本発明は上記の実施形態に基づいて述べられているが、本発明は明らかにそのような実施形態に限定されるものではない。下記のケースもまた本発明に含まれる。1上述の実施形態は、モバイルトラステッドモジュールおよびセキュアブートの仕様の要件に従う。しかしながら、本発明を、TrustedComputingGroup’sTCGInfrastructureWorkingGroupArchitecturePartII-IntegrityManagementSpecificationVersion1.0.で定義したような、トラステッドプラットフォームモジュールを備え、かつ/または、トラステッドブート仕様をサポートするシステムに適用してもよい。2上述の実施形態では、MTM仕様書と同様の方法で認証は行われた。しかしながら、本発明を他の認証システムに適用してもよい。ただし、認証システムがシステムの状態を表す一連の値を維持する場合に限る。3上記の各装置は、具体的には、マイクロプロセッサ、ROM、RAM、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。RAMまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。4上記の各装置を構成する構成要素の一部または全部は、1個のシステムLSILargeScaleIntegration:大規模集積回路から構成されているとしてもよい。システムLSIは、複数の構成部を1個のチップ上に集積して製造された超多機能LSIであり、具体的には、マイクロプロセッサ、ROM、RAMなどを含んで構成されるコンピュータシステムである。RAMには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムLSIは、その機能を達成する。さらに、各装置を構成する構成部品の各ユニットは、別個の個別チップとして、または、一部もしくは全てを含む単一のチップとして作られてもよい。さらに、ここでは、LSIが述べられているが、集積化の程度の違いにより、指定IC、LSI、スーパLSI、ウルトラLSIが使用される場合もある。さらに、回路の集積化の手段は、LSIに限定されるものではなく、専用回路、もしくは汎用プロセッサによる実装も利用できる。さらに、LSIが製造された後にプログラム可能なフィールドプログラムゲートアレイFPGAを使用することもまた可能であり、またLSI内で回路セルの接続および設定を再構成可能なリコンフィギュアラブルプロセッサも使用可能である。さらに、もしLSIに置き換わる集積回路技術が半導体技術もしくは他の派生する技術の進歩を通じて現われるのであれば、その技術は当然に構成要素の集積化を実現するために使用することができる。バイオ技術の適用が予想される。5上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なICカードまたは単体のモジュールから構成されているとしてもよい。ICカードまたはモジュールは、マイクロプロセッサ、ROM、RAMなどから構成されるコンピュータシステムである。ICカードまたはモジュールは、上記の超多機能LSIに含まれるとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ICカードまたはモジュールは、その機能を達成する。このICカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。6本発明は、上記に示す方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムなどのデジタル信号であるとしてもよい。また、本発明は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、CD-ROM、MO、DVD、DVD-ROM、DVD-RAM、BDBlu-rayDisc、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記憶しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。7本技術分野の当業者にとっては、説明した実施形態の、本発明固有の教示および利点から原理的に離れることのない多くの変形がありえることを容易に理解することができるだろう。また、上記変更および実施形態の任意の組み合わせは、本発明の範囲内に含まれる。