JP5530460B2 - セキュアブート方法およびセキュアブート装置 - Google Patents

Description

本発明は、コンポーネントを信頼性の高い方法で起動するセキュアブート方法およびセキュアブート装置に関し、特に、オプショナルコンポーネントを起動するセキュアブート方法およびセキュアブート装置に関する。

信頼性の高い確実な方法でいかに装置を起動するかということについては、先導的な文献である「ｔｈｅ Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ’ｓ （ＴＣＧ） Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ （ＭＴＭ） ｄｏｃｕｍｅｎｔｓ ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｖｅｒｓｉｏｎ １．０ １２ Ｊｕｎｅ ２００７」（非特許文献１）および「ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｖｅｒｓｉｏｎ １．０ １２ Ｊｕｎｅ ２００７」（非特許文献２）などに記載されている。これらの方法は、信頼性や安全性がブートプロセスの間保持されるということを確実にするため徹底的に見直されてきており、その結果、安全にブートができる装置の実装を要求する人々に有用な基準を提供している。このセキュアブートプロセスのキーコンポーネントは、ＲＩＭ証明書である。これは、現在期待されるプラットフォームの状態がどのようなものであるべきかを定義する署名付きの構造体である。プラットフォームの状態は、プラットフォーム設定レジスタ（ＰＣＲｓ）の集合に対するハッシュによって表され、各ＰＣＲは一般に定義されたハッシュ値を含む。これらのＰＣＲは、完全性測定（ｉｎｔｅｇｒｉｔｙ ｍｅａｓｕｒｅｍｅｎｔ）情報として用いられるものであり、期待される装置の状態を定義するためにＲＩＭ証明書に記録されていてもよい。さらに、ＲＩＭ証明書はまた、現在の状態が検証される場合に、拡張されるべきＰＣＲを特定する。この拡張の処理では、指定されたＰＣＲの値を取得し、ＲＩＭ証明書内で定義される新たな既知の値と以前のＰＣＲ値とを連結させた値に基づいて新たなハッシュ値を算出する。ＴＣＧによって定義される典型的なセキュアブートシーケンスは、コアコンポーネントの初期化および自己検証から開始する。ここで、コアコンポーネントとは、検証および測定の信頼性のルート（ＲＴＶ＋ＲＴＭ）、ＭＴＭ自体、および関連するコアＭＴＭインタフェースコンポーネント等である。次に、ファームウェアの他の部分をサポートする追加コンポーネントが、信頼された方法で起動される。ここで信頼された方法とは、例えば、各追加コンポーネントの起動時に、先にブートされた他のコンポーネントによって検証されることである。そして、最後に、オペレーティングシステムが、クライアントアプリケーションに対して、ＭＴＭサービスへとアクセスする安全で信頼されたパスを提供するために起動される。

しかし、仕様書は、ブートプロセスを通して、完全に成功するか失敗するかのどちらかの結果にしかならない単一の制御パスのみを提供しており、融通の利かない内容となっている。言い換えると、もし１つのコンポーネントのブートプロセスが失敗すると、他のコンポーネントの全ては、たとえ、そのコンポーネント自身のブートプロセスが成功していたとしても使用されないこととなる。

ＴＣＧ仕様書は、携帯電話などの携帯端末ではリソースが限られていることを認識した上での監査機能を提供している。仕様書では、これらの監査の形態はＭＴＭではオプショナルであると定義されているが、これは下記に示す問題を生じる。上述したように、この機構はオプショナルに過ぎないが、この機構に対するブートプロセスが失敗すると、携帯電話の全てのコンポーネントが使用できなくなる。さらに、この形態は実装される必要がないことに関わらず（というのもオプショナルなため）、この形態を実装しなくては、検証が常に失敗することとなる。これにより、他のプロセスに対して、ブートプロセス中でなぜ、またはどこで失敗があったのかを検出することがより難しくなる。さらに、装置製造者は、所定の信頼されたコンポーネントをオプションとして提供することを望むことがある。

ここでオプショナルコンポーネントとは、例えば、ユーザが追加契約した後に有効化できるシステムまたはアプリケーションソフトウェアのことである。ここで、「有効な（またはアクティブな）」とは、そのアプリケーションソフトウェアの状態を、ユーザが実行可能な状態に変化させることである。そのソフトウェアが有効化されていなければ、たとえそのシステムまたはアプリケーションソフトウェア自体がコンピュータに事前にインストールされているか、またはサーバからダウンロードされていても、ユーザはそのシステムまたはアプリケーションソフトウェアを使用することができない。

上述のように、オプショナルコンポーネントが有効化されているか否かは、各ユーザが決定してもよい。よって、更新されたＲＩＭ証明書を装置に送信するサーバは、有効化されたコンポーネントに対応する更新された証明書を送信するために、各装置においてどのコンポーネントが有効であるかを知ると思われる。

さらに多くの市場では、ユーザが現在サービス契約していないか、または現在のサービス契約のエリア外にある携帯電話からでも緊急電話をできるようにするという、サービスプロバイダへの法的な要求がある。ＭＴＭを備えた電話では、証明書が無効化されたり、重要でないコンポーネントのデータが破損したりした場合に、全く操作できなくなってしまうため、この法的な要求を満たすことができない。

Ｚｉｍｍｅｒらによる米国特許出願公開第２００５／０１３８４１４号明細書（特許文献１）には、オプショナルコンポーネントを伴う検証されたブート方法が開示されているが、そのオプショナルコンポーネントは、明示的なスイッチに応じて実装されており、コンポーネントプログラムファイルの破損、またはハードウェアの初期化の失敗のようなオプショナルコンポーネントを処理するときに生じるエラーをどのように処理するかということを考慮していない。

Ｓｃｈｅｌｌらによる米国特許第６４７７６４８号明細書（特許文献２）には、検証に失敗する可能性のあるオプショナルコンポーネントを伴う検証されたブート方法が開示されているが、この課題の解決方法は教示されていない。

したがって、必要なことは、ＴＣＧ携帯電話ワーキンググループによって定義されるセキュアブートの状況内でオプショナルコンポーネントをサポートする方法であり、たとえいくつかのＲＩＭ証明書が無効化されるか、またはコンポーネントが機能していなくても、少ない機能で動作する方法であり、また、セキュアブートが終了した後、ＭＴＭの状態を決定する、より簡単な、リソース負荷のより少ない方法である。

したがって、さらに、更新された証明書のセットを装置毎にカスタマイズして作成することなく、有効化または無効化されたコンポーネントを更新するための装置およびサーバが必要である。

米国特許出願公開第2005/0138414号明細書 米国特許第6477648号明細書

the Trusted Computing Group’s (TCG) Mobile Trusted Module (MTM) documents TCG Mobile Reference Architecture version 1.0 12 June 2007 TCG Mobile Trusted Module Specification version 1.0 12 June 2007

従来技術では、単一の定められたシーケンスに応じてブートする方法を述べているが、そこでは、もし１つの必須でないコンポーネントが失敗するか、または存在しない場合に、どうするのかを提案していない。さらに、失敗の状態は、セキュアブートプロセス全体で記録されるのみであり、各個別のコンポーネントごとに記録されていない。結果として、ＲＩＭ証明書が必要とされる各役割のうち、たった１つしか用いることができない。

そのため、ブートされている装置の安全性や信頼性を保持しつつ、セキュアブートに関する複数の実行シーケンスを定義することで、オプショナルかつ失敗したコンポーネントのために装置をサポートすることのできるシステムや方法については、満たされないニーズがあり、このようなシステムや方法を得ることは大いに役立つことである。

さらに、上記に加えて、セキュアブートシステム内の各個別のコンポーネントの成功または失敗を記録することで、セキュアブートが完了した後にユーザが安全な環境の状態を決定できるシステムや方法に関して満たされていない要求があり、このようなシステムや方法を得ることは大いに役立つことである。

さらに、上記に加えて、各役割ごとに複数のＲＩＭ証明書を使用することで装置の安全性や信頼性を保持する一方、オプショナルコンポーネントをサポートできるようにするシステムや方法については、満たされていない要求があり、このようなシステムや方法を得ることは大いに役立つことである。

本発明の一態様に係るセキュアブート方法は、完全性測定によって検証されるソフトウェアコンポーネントを実行する方法であって、ａ）論理識別子からソフトウェアコンポーネントの有効状態フラグへの第１マッピングを提供するステップと、ｂ）前記論理識別子と、前のソフトウェアコンポーネントの状態情報とから、検証データを含む実際の完全性測定証明書への第２マッピングを提供するステップと、ｃ）前記ソフトウェアコンポーネントを識別する所定の論理識別子を前記第１マッピングから検索することで、前記ソフトウェアコンポーネントが有効であるか否かを示す状態フラグを得るステップ（２１２２）と、ｄ）前記ソフトウェアコンポーネントの検証証明書を識別する所定の論理識別子と、前記前のコンポーネントの状態とを前記第２マッピングから検索することで、完全性測定証明書を得るステップ（２１２２）と、ｅ）実行すべき前記ソフトウェアコンポーネントのチェック値を算出するステップ（２１２６）と、ｆ）前記完全性測定値が前記完全性測定証明書内の完全性測定値に一致することと、前記算出されたチェック値が前記完全性測定証明書内のチェック値に一致することとを検証するステップ（２１２８）と、ｇ）前記状態フラグによって、前記ソフトウェアコンポーネントが有効であることを示し、かつ前記検証が成功していれば、前記完全性測定証明書内の前記チェック値の指示を含むように現在の完全性測定値を更新するステップ（２２００）と、ｈ）前記ソフトウェアコンポーネントが有効であり、かつ前記検証が成功していれば、前記ソフトウェアコンポーネントを実行するステップ（２２０６）とを含む。

また、前記方法は、さらに、ａ）前記コンポーネントが有効でなければ、前記コンポーネントの検証失敗証明書を識別する所定の論理識別子と、前記前のコンポーネントの状態とを前記第２マッピングから検索することで、無効な完全性測定証明書を得るステップ（２１３４）と、ｂ）前記無効な完全性測定証明書内に格納されている、コンポーネントの状態が無効である旨の指示を示すように現在の完全性測定値を更新するステップ（２１３４）とを含んでもよい。

また、前記方法は、さらに、ａ）前記検証が不成功であれば、前記コンポーネントの検証失敗証明書を識別する所定の論理識別子と、前記前のコンポーネントの状態とを前記第２マッピングから検索することで、失敗完全性測定証明書を得るステップ（２１３６）と、ｂ）前記失敗完全性測定証明書内に格納されている、完全性測定が不成功である旨の指示を含むように現在の完全性測定値を更新するステップ（２１３６）とを含んでもよい。

また、前記方法は、さらに、ａ）前記コンポーネントが有効でないか、または前記検証が不成功であれば、論理識別子と、前のソフトウェアコンポーネントの状態情報とからコンポーネント識別子への第３マッピングを提供するステップ（２４０４）と、ｂ）前記コンポーネントを識別する所定の論理識別子と、前記前のコンポーネントの状態とを前記第３マッピングから検索することで、実行すべき別のソフトウェアコンポーネントを得るステップ（２４０４）とを含んでもよい。

本発明に係る好ましい実施の形態においては、各個別のコンポーネントの成功または失敗は、他の全ての信頼されたコンポーネントによって利用できるテーブル内に記録される。

本発明の別の好ましい実施の形態においては、複数の実行シーケンスは、所定のコンポーネントが失敗した後に実行すべき別のコンポーネントを記述するテーブル内に記述される。このテーブルは、失敗したモジュールや、以前に実行したか、または失敗したコンポーネントの状態に関する識別子の組み合わせを用いて索引が付けられる。

本発明の別の好ましい実施の形態においては、オプショナルコンポーネントは、そのコンポーネントが有効化されているか否かを示すフラグを含むテーブル内に記述される。このテーブルは、オプショナルコンポーネントがブートされるか否かを制御するためにセキュアブート中に参照されるため、そのオプショナルコンポーネントの好ましい実行シーケンスを明示的に記述している。

本発明の別の好ましい形態においては、各個別のコンポーネントが以前に実行したか、または失敗したコンポーネントの状態に応じて正確に検証するために、各コンポーネントは、コンポーネントを実行する前に明らかにしなくてはならない様々な有効な前提条件を記述する複数のＲＩＭ証明書を有する。

この課題を解決するために、本発明によると、サーバに接続可能な装置は、各々が１つの証明書に割り当てられる複数のソフトウェア、および前記複数のソフトウェアに関連し、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書を格納する格納手段と、前記複数のソフトウェアの１つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な１つのソフトウェアとして、前記装置に対し設定する設定手段と、前記複数のソフトウェアのうちの前記有効な１つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な１つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行手段と、前記複数の証明書のうち、サーバによって、何れが前記複数のソフトウェアのうちの前記有効な１つのソフトウェアに対応するかを検出することなく更新すると判定された、所定の証明書に対応する複数の更新された証明書をサーバから受信する受信手段と、前記複数のソフトウェアのうちの前記有効な１つのソフトウェアに関連する証明書に対応する１つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択手段とを備え、前記実行手段は前記１つの最新かつ選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な１つのソフトウェアを検証する。

この構成により、装置は、どの更新された証明書が有効なコンポーネントに対応するかを検出することなく、サーバ上にある更新された証明書を受信する。よって、発明の本態様によると、サーバが送信する証明書のセットをカスタマイズすることなく、有効なコンポーネント用に適切な証明書を更新することが可能であり、よって、複数の更新された証明書の発行に必要な潜在的に秘密性の高い鍵をサーバに置く必要がなく、安全なオフラインの設備において管理される。

図１は、先行技術を表すブロック図である。 図２は、先行技術のセキュアブートシーケンスを示す。 図３は、オプショナルコンポーネント制御構造体に係る携帯装置のライフタイムおよび外部との相互関係を示す。 図４は、オプショナルコンポーネント制御テーブルおよび関連データを維持するためのキーコンポーネントを表すブロック図である。 図５は、オプショナルコンポーネントをサポートするために必要とされるテーブルを表す付加的なデータを含むＲＩＭ証明書を示す。 図６は、ラベル−証明書対応テーブルを示す。 図７は、次コンポーネントテーブルを示す。 図８は、カウンタ値、証明書の識別子および証明書の状態を示すテーブル、およびオプショナルコンポーネントの状態を表す暗号署名を含むオプショナルコンポーネント制御テーブルを示す。 図９は、本発明のオプショナルコンポーネント制御テーブルを初期化するプロセスを示すフローチャートである。 図１０は、内部ＲＩＭ証明書の無効化プロセスと、本発明のオプショナルコンポーネント制御テーブルに必要な相互作用を示すフローチャートである。 図１１は、本発明のオプショナルコンポーネント制御テーブルを更新するための、サーバとの交信プロセスを示すシーケンス線図である。 図１２は、証明書の識別子および証明書の状態を示すテーブルを含むオプショナルコンポーネント制御テーブルを示しており、オプショナルコンポーネントの状態を表す。 図１３は、図１２のテーブルを保護するオプショナルコンポーネント制御テーブルＲＩＭ証明書を示す。 図１４は、本発明の初期ブート中にオプショナルコンポーネント制御テーブルを初期化するプロセスを示すフローチャートである。 図１５は、本発明のオプショナルコンポーネント制御テーブルを用いた、内部ＲＩＭ証明書の無効化プロセスを示すフローチャートである。 図１６は、本発明のオプショナルコンポーネント制御テーブルを更新するための、サーバとの交信プロセスを示すシーケンス線図である。 図１７は、サーバから携帯装置へ送られるオプショナルコンポーネント更新テーブルを示す。 図１８は、顧客機器によるオプショナルコンポーネント制御テーブルの維持をサポートするために用いられる、サーバ内のキーコンポーネントを表すブロック図である。 図１９は、オプショナルコンポーネントを伴うセキュアブートを表すブロック図である。 図２０は、エラー検出およびオプショナルコンポーネントを伴うセキュアブートの追加的なシーケンスを示す。 図２１Ａは、本発明のオプショナルコンポーネントを伴うセキュアブートを実行するプロセスを示すフローチャートである。 図２１Ｂは、本発明のオプショナルコンポーネントを伴うセキュアブートを実行するプロセスを示すフローチャートである。 図２１Ｃは、本発明のオプショナルコンポーネントを伴うセキュアブートを実行するプロセスを示すフローチャートである。 図２２は、本発明のオプショナルコンポーネントを伴うセキュアブートを実行するプロセスを示すフローチャートである。 図２３は、本発明のオプショナルコンポーネントを伴うセキュアブートを実行するプロセスを示すフローチャートである。 図２４は、本発明のオプショナルコンポーネントを伴うセキュアブートを実行するプロセスを示すフローチャートである。

本発明の第１の態様によると、サーバに接続可能な装置は、各々が１つの証明書に割り当てられる複数のソフトウェアと、前記複数のソフトウェアに関連付けられ、かつ各々が前記複数のソフトウェア各々の検証に用いられる複数の証明書とを格納する格納手段と、前記複数のソフトウェアの１つを、前記装置で実行可能な前記複数のソフトウェアのうちの有効な１つのソフトウェアとして、前記装置に設定する設定手段と、前記複数のソフトウェアのうちの前記有効な１つのソフトウェアに関連する証明書を用いて、前記複数のソフトウェアのうちの前記有効な１つのソフトウェアを検証し、前記検証の後に、前記複数のソフトウェアのうちの前記有効かつ検証されたソフトウェアを実行する実行手段と、前記複数の証明書のうち、何れが前記複数のソフトウェアのうちの前記有効な１つのソフトウェアに対応するかを検出することなく、更新すべきと前記サーバによって判定された所定の証明書に対応する複数の更新された証明書を前記サーバから受信する受信手段と、前記複数のソフトウェアのうちの前記有効な１つのソフトウェアに関連する証明書に対応する１つの更新された証明書を、前記受信した複数の更新された証明書から選択する選択手段とを備え、前記実行手段は前記１つの更新され選択された証明書を用いて前記複数のソフトウェアのうちの前記有効な１つのソフトウェアを検証する。

本発明の第２の態様によると、前記サーバは、前記複数の更新された証明書を前記装置およびもう１つの別の装置に共通して送信する。

本発明の第３の態様によると、前記複数の更新された証明書は、前記複数のソフトウェアのうちの前記１つの有効なソフトウェアとは異なる、前記複数のソフトウェアのうちの１つのソフトウェアに関連する証明書に対応する更新された証明書を含む。

本発明の第４の態様によると、前記装置はさらに、前記１つの更新された証明書に基づき、前記複数のソフトウェアのうちの前記１つの有効なソフトウェアに関連する証明書を更新する更新手段を備え、前記実行手段は、前記更新手段が更新した証明書を用いて前記複数のソフトウェアのうちの前記有効な１つのソフトウェアを検証する。

本発明の第５の態様によると、前記装置はさらに、前記装置の固有鍵である装置鍵を格納する装置鍵格納手段を備え、前記更新手段は、前記装置鍵を用いて前記１つの更新された証明書を変換し、前記変換された１つの更新された証明書で前記複数のソフトウェアのうちの前記有効な１つのソフトウェアに関連する証明書を上書きすることにより、前記複数のソフトウェアのうちの前記有効な１つのソフトウェアに関連する証明書を更新する。

本発明の第６の態様によると、前記装置はさらに、前記設定手段が前記装置に、前記複数のソフトウェアのうちの１つを前記複数のソフトウェアのうちの前記有効な１つのソフトウェアとして設定したとき、前記複数のソフトウェアのうちの前記有効な１つのソフトウェアを示す許可フラグを格納するフラグ格納手段を備え、前記選択手段は、前記複数のソフトウェアのうちの前記有効な１つのソフトウェアに関連する証明書に対応する１つの更新された証明書を、前記フラグ格納手段に格納されている前記許可フラグに基づいて、前記受信した複数の更新された証明書から選択する。

本発明の第７の態様によると、前記装置はさらに、前記無効化手段が前記格納手段に格納されている前記１つの証明書を無効化するときに、カウンタ値をインクリメントするカウンタと、カウンタ値がインクリメントされたとき、前記許可フラグを含む管理情報に前記インクリメントされたカウンタ値を設定するカウンタ値設定手段と、前記管理情報に設定された前記カウンタ値を用いて前記管理情報が改竄されているか否かを判定する判定手段とを備える。

本発明の第８の態様によると、前記装置はさらに、前記許可フラグと前記カウンタ値とを含む前記管理情報の暗号技術的ハッシュ値を算出する算出手段と、前記算出された暗号技術的ハッシュ値に対応する検証値を格納する値格納手段と、前記選択手段が前記１つの更新された証明書を選択するために前記管理情報を用いる前に、前記格納された検証値と前記算出された暗号技術的ハッシュ値とを比較することにより、前記管理情報が改竄されているか否かを検証する検証手段を備える。

本発明の第９の態様によると、前記装置はさらに、前記複数のソフトウェアと前記複数の証明書の間のマッピングを示すマッピングデータを格納するマッピングデータ格納手段と、前記マッピングデータの暗号技術的ハッシュ値を算出する算出手段と、前記算出された暗号技術的ハッシュ値に対応する検証値を格納する値格納手段と、前記選択手段が前記１つの更新された証明書を選択する前に、前記格納された検証値と前記算出された暗号技術的ハッシュ値とを比較することにより、前記マッピングデータが改竄されているか否かを検証する検証手段を備え、前記選択手段は、前記マッピングデータに基づき前記１つの更新された証明書を選択する。

本発明の第１０の態様によると、前記装置はさらに、前記無効化手段が前記格納手段に格納されている前記１つの証明書を無効化するときに、カウンタ値をインクリメントするカウンタと、カウンタ値がインクリメントされたとき、前記マッピングデータに前記インクリメントされたカウンタ値を割り当てるカウンタ値割り当て手段とを備え、前記算出手段は、前記マッピングデータと前記マッピングデータに割り当てられた前記カウンタ値とを用いて前記暗号技術的ハッシュ値を算出する。

＜本実施形態の概要＞
本実施形態は、ソフトウェアの検証に用いられる証明書を更新することができるシステムに関する。装置が１つ以上のオプショナルコンポーネントを有する場合、どのコンポーネントを有効化するかは、ユーザの決定次第である。よって通常、サーバは、有効なコンポーネントに対応する更新された証明書を送信するために、各装置においてどのコンポーネントが有効であるかの情報を知っている必要がある。そしてサーバは、各装置の有効なコンポーネントに対応する、更新された証明書のカスタマイズされたセットを、各装置に送信する。

しかし、装置毎にカスタマイズされたセットを作成するのは煩雑で、費用もかかる。よって、本実施形態は、装置毎にカスタマイズされたセットを作成することなく、証明書を更新するシステムを示す。

本発明は、セキュアブートを実行するシステム内でオプショナルまたは失敗のコンポーネントをサポートするためのシステムに関する。後述する追加のＲＩＭ証明書およびデータテーブルを提供することにより、セキュアブートをサポートする装置の開発者は、起動に失敗したコンポーネント、または無効であると示されたコンポーネントを柔軟に扱うシステムや、セキュアブートによってもたらされる信頼された環境内で、コンポーネントの状態を報告できる装置を生産できる。さらに、有効なオプショナルコンポーネントのリストを備えることで、システムが、外部関係者によって有効化および無効化される可能性のあるコンポーネントも処理できるようになる。本実施形態は、装置内の少なくとも１つのコンポーネントがオプショナルコンポーネントであり、そのコンポーネントおよびそのコンポーネントのブート時よりも前にブートした他のコンポーネントを検証するために証明書を用いるシステムを想定している。よって、通常のシステムでは、あるコンポーネントのブートプロセスの失敗、または無効であるためブートされなかったコンポーネントが、その失敗したコンポーネントの後にブートする他のコンポーネントに影響を与える。これは、その失敗したコンポーネントがオプショナルコンポーネントであり、他のコンポーネント自体は有効だとしても起こることである。この問題を避けるために、本実施形態では、以下に説明するように、失敗ＲＩＭ証明書および成功ＲＩＭ証明書を用いている。

この構成もまた、従来技術よりも新しい技術である。しかしながら、証明書の無効化に関する本発明の一部は、上記に示した課題を扱わないシステムにも適用できる。

セキュアブートをサポートする装置の、オプショナルコンポーネントの取り扱いを含む、コンポーネントを無効化するための新しいシステムおよび方法を説明する。本願を完全に理解するため、以下、具体的な詳細を多数挙げて説明する。他の例では、周知の構造および装置をブロック図に示し、説明を簡単にするため、具体的な詳細は説明していない。しかしながら、当業者であれば、改良により、またはそのような具体的な説明がなくとも、本願を実施することができるのは明らかである。好適な実施形態の説明により、クレームの範囲が限定されるものではない。

＜本実施形態の詳細＞
本発明は、セキュアブートを実行するシステム内でオプショナルまたは失敗のコンポーネントをサポートするためのシステムに関する。後述する追加のＲＩＭ証明書およびデータテーブルを提供することにより、セキュアブートをサポートする装置の開発者は、起動に失敗したコンポーネントを柔軟に扱うシステムや、セキュアブートによってもたらされる信頼された環境内で、コンポーネントの状態を報告できる装置を生産できる。

図１は、先行技術を示す。この図は、ＲＴＶ＋ＲＴＭ、および信頼エリア１００内のＭＴＭインタフェース等のコアエレメントが自己検証を終えた時点でのセキュアブートプロセスの状態をとらえたものである。ＭＴＭ１０２は、この信頼エリア１００のコアであるが、他の重要な構成要素として、セキュアブートが正しく進んできたか否かを示すフラグであるシステムの状態１０４、システムの状態１０４を設定するシステムエラーレコーダ１０６、信頼エリア１００に追加される次コンポーネントを立ち上げるランチャ１０８、および必要な成功ＲＩＭ証明書１１４を検索する証明書データベース１１０がある。これらの成功ＲＩＭ証明書１１４は、セキュアブートが完全に成功した時の期待されるプラットフォームの状態を記述している。ＲＩＭ証明書は、セキュアブートが成功するか否かを正しくチェックするために、変更できないように保護されなければならないので、完全性が保護され、完全性保護１１２のデータ項目の集合内に置かれている。ＴＣＧに定義されているように、この完全性の保護は、署名されたハッシュをＲＩＭ証明書内に埋め込むことで達成でき、それによりＭＴＭ１０２による改竄の検出が可能になる。

セキュアブートの目的は、信頼エリア１００を拡大し、信頼コンポーネント１ １１６、信頼コンポーネント２ １１８、および信頼コンポーネント３ １２０のような追加的コンポーネントを包含することである。１２２、１２４および１２６とラベル付けされた、ランチャ１０８から、信頼コンポーネント１ １１６、信頼コンポーネント２ １１８、および信頼コンポーネント３ １２０への点線は、先行技術の一態様における通常の実行パスを示す。先行技術の他の態様においては、最終的な信頼コンポーネントとしてのオペレーティングシステム（図示せず）に伴って、さらなる信頼コンポーネントが存在してもよい。信頼コンポーネントを立ち上げるための特定のシーケンスは、その特定のセキュアブートシステムの設計によって決まる。

図２は、図１に示す方法における先行技術のセキュアブートプロセスの結果を示す。ここで、標準的なブートシーケンスはＭＴＭ１０２から開始し、その後信頼コンポーネント１ １１６が動作し、信頼コンポーネント２ １１８、さらに信頼コンポーネント３ １２０、信頼コンポーネント４ ２００、信頼コンポーネント５ ２０２、そして最後にオペレーティングシステム２０４へと制御が移る。信頼コンポーネント２ １１８、信頼コンポーネント４ ２００、および信頼コンポーネント５ ２０２は、信頼コンポーネント１ １１６および信頼コンポーネント３ １２０が提供する基本的なサービスに加えて、さらにオプショナルサービスを提供するコンポーネントである。成功の場合は、フロー２０６のように、全コンポーネントが動作に成功し、完全に動作している信頼エリア２０８が利用できる。しかしながら、フロー２１０においては、信頼コンポーネント４ ２００がロードに失敗した結果、失敗した状態であるため信頼エリア２１２全体が利用できなくなる。信頼エリアの図２０８および２１２において、ＭＴＭはＭＴＭ１０２、ＴＣ１は信頼コンポーネント１ １１６、ＴＣ２は信頼コンポーネント２ １１８、ＴＣ３は信頼コンポーネント３ １２０、ＴＣ４は信頼コンポーネント４ ２００、ＴＣ５は信頼コンポーネント５ ２０２、ＯＳはオペレーティングシステム２０４を表している。全コンポーネントはＭＴＭ１０２に依存し、加えて、信頼コンポーネント２ １１８は信頼コンポーネント１ １１６に依存し、信頼コンポーネント４ ２００および信頼コンポーネント５ ２０２は信頼コンポーネント３ １２０に依存する。オペレーティングシステム２０４は信頼コンポーネント１ １１６および信頼コンポーネント３ １２０に依存する。陰付きの部分は、使用できないコンポーネントを示す。

図３は、セキュアブートを特徴とする携帯装置のライフサイクルを示す。工場３００で、初期化プロセス３０２において、各装置でどのオプショナルコンポーネントが利用可能であるかを示す情報と共にオプショナルコンポーネントのセットをインストールする。携帯装置が携帯電話販売店３０４またはオンラインストア等の他の販売業者に出荷されると、顧客はオプショナルコンポーネントに対応する様々なオプション３０６を購入または契約することができる。これで携帯装置３０８が使用できる状態になり、ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅに定義されているように、その装置の使用期間中に、オプショナルコンポーネントおよび必須のコンポーネント用の証明書３１０の全装置への送信３１２等が行われる。さらに、その装置の所有者は、携帯通信事業者または他の装置管理団体が提供するサーバ３１６を介して契約オプション３１４のセットを明示的に更新し、ある特定の装置で利用可能なオプショナルコンポーネントを更新することが可能である。オプショナルコンポーネントの管理に係る各プロセスの動作を以下に説明する。

図４は、本発明の一態様、具体的には、システム内のオプショナルコンポーネントを生成および維持する方法を示す。重要な機能上の構成要素およびデータの項目は以下の通りである。まず、データ構造は全て、完全性保護４００されており、好適な実施形態において、これは署名されたハッシュを用いることで達成されている。このデータ構造は、まず、成功ＲＩＭ証明書４０２および失敗ＲＩＭ証明書４０４である。成功ＲＩＭ証明書は、全てのコンポーネントが適切に動作している場合の、セキュアブート中に期待されるプラットフォームの状態を記述したものであり、失敗ＲＩＭ証明書は、１つ以上のコンポーネントが適切に動作しなかった場合の、セキュアブート中に期待されるプラットフォームの状態を記述したものである。ラベル−証明書対応テーブル４０６は、信頼されたコンポーネントの状態を特定の成功ＲＩＭ証明書４０２または失敗ＲＩＭ証明書４０４に対してマッピングし、オプショナルコンポーネント制御テーブル４０８は、どのオプショナル信頼コンポーネントが有効で、どれが無効かを記述し、デフォルトオプショナルコンポーネント制御テーブル４１０は、携帯電話の初回ブート時、または万一オプショナルコンポーネント制御テーブル４０８が破損した場合等に、オプショナルコンポーネント制御テーブル４０８を初期化する際に用いられる。好適な実施形態において、このテーブルの構成はオプショナルコンポーネント制御テーブル４０８の構成と同様である。このオプショナルコンポーネント制御テーブル４０８を初期化するため、初期化部４２６が、デフォルトオプショナルコンポーネント制御テーブル４１０に基づいて、オプショナルコンポーネント制御テーブル４０８を作成する。このプロセスの詳細は後に説明する。

証明書更新部４１２は、携帯電話通信塔から無線ネットワーク４１６を通じて送出され、更新受信部４１４により装置が受信する証明書リストを処理することにより、成功ＲＩＭ証明書４０２および失敗ＲＩＭ証明書４０４を最新の状態に保つ。このプロセスの詳細は後に説明する。当業者であれば、メモリカードやその他の有線または無線の送信手段を介する等、他にも更新を可能にする方法があることがわかるであろう。

契約更新部４１８は、機器上のウェブブラウザ４２０に、サーバ４２４にあるオプショナルコンポーネントの維持ページにアクセスするよう要求することで、オプショナルコンポーネント制御テーブル４０８を有効な状態または無効な状態に保つ。好適な実施形態において、ウェブブラウザ４２０からサーバ４２４への接続４２２には、通信路を攻撃から守るためにセキュアソケットレイヤ（ＳＳＬ）を用いる。このプロセスの詳細は後に説明する。

図５は、ＲＩＭ証明書５００、ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ仕様書により定義されるＲＩＭ証明書に基づく、成功ＲＩＭ証明書４０２および失敗ＲＩＭ証明書４０４の詳細を示す。オプショナルコンポーネントへの対応を可能にするため、ｍａｐＩＤｔｏＣｅｒｔＴａｂｌｅＳｉｚｅ ５０６、ｍａｐＩＤｔｏＣｅｒｔＴａｂｌｅ ５０８、ｎｅｘｔＣｏｍｐｏｎｅｎｔＴａｂｌｅＳｉｚｅ５１０およびｎｅｘｔＣｏｍｐｏｎｅｎｔＴａｂｌｅ ５１２が証明書に加えられ、ｅｘｔｅｎｓｉｏｎＤｉｇｅｓｔ ５０４のエントリは、これらの追加されたデータの暗号技術的ハッシュ値を含む。この拡張されたＲＩＭ証明書の例は１つだけでよく、また実施の形態ではこれらのテーブルをＲＴＶ＋ＲＴＭが自己検証に使用する単一のＲＩＭ証明書に付加する。しかし、従来技術のこの態様は、ここでは述べない。

加えて、ＲＩＭ証明書５００は、ＲＩＭ証明書を特定するラベルフィールド５０２を有する。

技術分野の当業者は、ＲＩＭ証明書５００を使用することなく、ｍａｐＩＤｔｏＣｅｒｔＴａｂｌｅ ５０８およびｎｅｘｔＣｏｍｐｏｎｅｎｔＴａｂｌｅ ５１２の完全性を利用可能にし、かつ維持する他の方法、例えば、署名者および信頼エリア１００の両方が知っている秘密鍵を使用して、各テーブルに対し個々にまたは一度にデジタル署名するなど、他の方法があることを理解できるであろう。

図６は、コンポーネントを識別する識別子となる論理証明書ラベルおよび１つ前に起動するソフトウェアコンポーネントから、実際のＲＩＭ証明書までのマッピングを示すデータエントリを持つＩＤ−証明書対応テーブル５０８のフォーマットを示す。ＩＤ−証明書対応テーブル５０８は、論理識別子と、前のソフトウェアコンポーネントの状態情報とから、検証データを含む実際の完全性測定証明書への第２マッピングの一例である。第１列の論理証明書ラベル６００は、論理識別子の一例であって、特定の成功ＲＩＭ証明書、および、ゼロまたは１つ以上の失敗ＲＩＭ証明書の特定の役割を示す識別ラベルであり、かつ、システムの他の部分がＲＩＭ証明書を要求するために使用するラベルである。第２列の、依存する信頼コンポーネントの状態６０２には、どの信頼コンポーネントエラー状態のセットに対して各行が有効であるかを示すフラグが並べられている。第３列の、依存する信頼コンポーネントのマスク６０４には、どのコンポーネントの状態をチェックするべきかを示すフラグが並べられている。実施の形態では、これらの２つの列は、ビットマップを使用して実装される。最後に、ＲＩＭ証明書ラベル６０６の列には、ＲＩＭ証明書データベースから成功ＲＩＭ証明書４０２または失敗ＲＩＭ証明書４０４を検索するために用いられる実際のＲＩＭ証明書ラベルが保持されている。ＲＩＭ証明書ラベル６０６は、検証データを含む実際の完全性測定証明書の一例である。この値は、ＴＣＧで定義されるＲＩＭ証明書ラベルフィールド５０２の例を表す。

図７は、サンプルデータのエントリを持つ次コンポーネントテーブル５１２のフォーマットを示す。次コンポーネントテーブル５１２は、論理識別子と、前のソフトウェアコンポーネントの状態情報とからコンポーネント識別子への第３マッピングの一例である。第１列の失敗信頼コンポーネント７００は、論理識別子の一例であって、失敗したコンポーネントを示す識別子である。第２列の依存する信頼コンポーネントの状態７０２には、前のソフトウェアコンポーネントの状態情報の一例であって、どの信頼コンポーネントエラー状態のセットに対して現在の行が有効であるかを示すフラグが並べられている。第３列の、依存する信頼コンポーネントマスク７０４には、どのコンポーネントの状態をチェックするべきかを示すフラグが並べられている。実施の形態では、これらの２つの列は、ビットマップを使用して実装される。最後に、立ち上げるべき信頼コンポーネント７０６の列は、コンポーネント識別子の一例であって、所定の失敗信頼コンポーネント７００と、依存する信頼コンポーネントの状態７０２のセットとに対して、次にどのモジュールを立ち上げるべきか、またはセキュアブートが回復不可能な状態に陥ったためにブートを中止すべきか否かを記述する識別子である。図４を参照すると、信頼コンポーネント１ １１６または信頼コンポーネント３ １２０がロードに失敗した場合、次に立ち上げるべき信頼コンポーネント７０６が、実際にブート中止の指示を示してもよい。これは、これら２つのコンポーネントが、完全な信頼システムの動作に必要不可欠な基本コンポーネントであるからである。信頼コンポーネント２ １１８、信頼コンポーネント４ ２００、または信頼コンポーネント５ ２０２が失敗した場合、例えば、信頼コンポーネント３ １２０、信頼コンポーネント５ ２０２、およびオペレーティングシステム２０４の各々が次に立ち上げるべき信頼コンポーネント７０６であることを示すエントリが存在してもよい。

ＩＤ−証明書対応テーブル５０８および次コンポーネントテーブル５１２の内容は、ある特定の機器に必要なセキュアブートシーケンスの設計によって決まる。ＲＴＶ＋ＲＴＭが自己検証に使用するＲＩＭ証明書にこれらのテーブルを付加する上述の実施形態において、ＴＣＧが定めるＲＩＭ証明書発行機関（ほとんどの場合、装置の製造者）は、これらのテーブルを生成し、特定のＲＩＭ証明書にそのデータを追加し、その後証明書に署名して、装置での利用を可能にする。しかしながら、これらのテーブルは他者によって生成され、ＲＩＭ証明書とは別に送信されてもよい。さらに、セキュアブートシステムが自身のセキュアブートシーケンスを分析できれば、そのセキュアブートシステム自身がそれらのテーブルを生成してもよい。

これらのテーブルは、どのコンポーネントが他のコンポーネントに依存するかを示す情報に従って生成される。コンポーネントＡが他のコンポーネントＢに依存する場合、コンポーネントＢのブート手順が失敗すれば、コンポーネントＡのブートは行われるべきではない。そしてコンポーネントＡがコンポーネントＢから独立していれば、コンポーネントＢのブートが成功しなかった場合でも、ブートプロセスをコンポーネントＡのブート手順から再開することができる。もちろん、これらのテーブルはより多くの情報に従って生成されてもよい。例えば、これらのテーブルは、他の独立コンポーネントのブート手順が失敗すればブートされるべきではないコンポーネントを示す情報に従って生成されてもよい。この情報は、各信頼コンポーネントの作成者によって生成され、提供されてもよい。

携帯装置の所有者、プロバイダー、製造業者等の外部関係者によって選択的に有効にされる可能性のあるこれらの信頼コンポーネントを管理するため、その装置は、どのオプショナル信頼コンポーネントが有効で、どれが無効であるかを示すリストを維持する。図８は、オプショナルコンポーネント制御テーブル４０８におけるこのデータの好適な実施形態を示す。オプショナルコンポーネント制御テーブル４０８は、論理識別子からソフトウェアコンポーネントの有効状態フラグへの第１マッピングの一例である。ＲＩＭＰｒｏｔｅｃｔＶａｌｕｅ ８０２は、ロールバックまたはリフラッシュの攻撃からの構造体の保護を支援するための、構造体作成時または更新時のＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ仕様書が定義するｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタのコピーである。その下に来るのは各行が２つのフィールドをもつテーブルである。最初のフィールドは、オプショナル信頼コンポーネントの論理証明書ラベル８０４であり、ここではｍａｐＩＤｔｏＣｅｒｔＴａｂｌｅ ５０８内の論理証明書ＩＤ ６００に用いられるものと同一のコンポーネント識別子が用いられている。なお、論理証明書ラベル８０４は、論理識別子の一例である。次は、論理証明書ＩＤ ８０４が特定したオプショナル信頼コンポーネントが有効か否かを示すフラグ８０６であり、当該フラグを、有効である場合はＴＲＵＥに、無効である場合はＦＡＬＳＥに設定する。フラグ８０６は、ソフトウェアコンポーネントの有効状態フラグの一例である。この値のペアは、システム内の各オプショナル信頼コンポーネントに対し繰り返され、−１の論理証明書ＩＤ ８０８、および無効にするために通常はＦＡＬＳＥに設定されるフラグ８１０によりテーブルを終了する。この値のペアのセットの集合は、論理証明書ラベルテーブル８１４として知られている。最後に、オプショナルコンポーネント制御構造内の上記データ全てを改竄から保護するために、ＰＫＣＳ ＃１ ｖ１．５仕様書に従って生成され、下記図９で説明する通りに作成された外部プロセスからは利用できない秘密鍵を使って署名された暗号署名８１２がある。当該技術分野の当業者は、各オプショナルコンポーネントの状態の完全性を利用可能にし、維持できる他の方法や、ＨＭＡＣのような他のデジタル署名アルゴリズムを用いてもよいことを理解するだろう。

図９は、本発明のオプショナルコンポーネント制御テーブルの、初期作成を示す。図示されたプロセスは、ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ仕様書に初期ブート用に詳述されている通り、ひとたびＭＴＭが初期起動すると起こる、装置を初めてブートする時のプロセスである。また、そのドキュメントに詳述されているように、初期ブートは携帯装置のライフサイクルにおいて他の時点でも起こりえるため、図９は必要に応じた構造体の再作成も示す。まず、一連の初期ブートにおいてＭＴＭおよび信頼性のルートを確立して初期化するために十分な初期化を行った後に、ＭＴＭからのオプショナルコンポーネント制御構造体に署名するための秘密鍵が要求される９００。好適な実施形態において、秘密鍵はＲＳＡキーペアの私有鍵を示す。この要求の成功または失敗がチェックされ９０２、ＭＴＭが要求された鍵を発見できなかったときは、ＭＴＭ内で秘密鍵を作成する９０４。この鍵は、ＴＰＭメイン仕様書パート２に定義されている使用法タイプであるＴＰＭ＿ＫＥＹ＿ＳＩＧＮＩＮＧで作成されなければならない。また、好適な実施例において、この鍵のアルゴリズムは１０２４ビット長のＴＰＭ＿ＡＬＧ＿ＲＳＡであり、ＴＰＭ＿ＳＳ＿ＲＳＡＳＳＡＰＫＣＳＡ１ｖ１５＿ＳＨＡ１署名スキームとともに使用できる。しかし、秘密鍵が見つかったときは、鍵を作成する必要がなく、その代わりに、既存の、有効に署名されたオプショナルコンポーネント制御テーブルがあるか否かを確認する９０６。既存の、有効に署名されたオプショナルコンポーネント制御テーブルがある場合は、構造体を再作成すると例えば変更されたオプションを上書きする可能性があることから、再作成する必要がなく、ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅに定められているように、初期ブート手順が他の処理と共に進む９２０。オプショナルコンポーネント制御テーブルがない場合（または秘密鍵が見つからなかったので作成しなければならなかった場合９０４）、ＲＩＭ証明書を保護するためにＭＴＭによって管理される単調カウンタが要求され９１０、オプショナルコンポーネントのデフォルト状態情報が要求される９１２。新たなオプショナルコンポーネント制御テーブルが作成され９１４、単調カウンタがＲＩＭＰｒｏｔｅｃｔＶａｌｕｅフィールド８０２に、また、オプショナルコンポーネントおよびその状態がフィールド８０４およびフィールド８０６に挿入され、テーブル終了信号値８０８および８１０が作成される。次に、この新たな構造体が、先に作成または取得された鍵を用いた暗号署名の要求と共に、ＭＴＭに送られる９１６。この署名プロセスにより、暗号署名８１２が作成される。これで、公にアクセス可能な位置においてさえ、改竄防止オプショナルコンポーネント制御テーブル４０８が、望む通りに格納できる。これで、オプショナルコンポーネント制御テーブルの作成プロセスが完了し、初期ブート手順が、ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅに定められている通り、他の処理と共に進む９２０。

図１０は、ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅのセクション６．３．４．５に記載されているＲＩＭ無効化のタスクに必要な、本発明の追加的な処理を示す。その仕様書には、ＲＩＭ＿Ａｕｔｈがどのように検証されるか、ＲＩＭ＿Ｃｅｒｔ有効性リストがどのようにチェックされ、新たな有効性リスト上の対応する外部ＲＩＭ＿Ｃｅｒｔを有しない全ての内部ＲＩＭ＿Ｃｅｒｔが削除されるか、残りの全ての内部ＲＩＭ＿Ｃｅｒｔがどのように再有効化されるか、また、ｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタがどのように更新されるかが説明されている。図１０が示すプロセスにより、ｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタが更新され、残りの全ての内部ＲＩＭ＿Ｃｅｒｔが再有効化される。まず、オプショナルコンポーネント制御構造体を取得する１０００。次に、データが依然として有効で、かつ改竄されていないことの検証を可能にするために、暗号署名５１２の作成に用いられる秘密鍵の公開部分をＭＴＭから取得し（１００２）、かつ現在のｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタをＭＴＭから取得する（１００４）。署名を検証して当該データが改竄されていないことを確かめ（１００６）、現在のｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタを、オプショナルコンポーネント制御構造体（４０８）に格納されているＲＩＭＰｒｏｔｅｃｔＶａｌｕｅ８０２と比較する。その格納された値が、現在の単調カウンタ値よりも大きいか、または同じである場合、オプショナルコンポーネント制御構造体は最新であり、その構造体にリフラッシュやロールバック攻撃が起こっていないことを示している。その２つのチェックの結果が、署名が正しくない（１００８）か、または現在の単調カウンタの値がオプショナルコンポーネント制御構造体（４０８）内のＲＩＭＰｒｏｔｅｃｔＶａｌｕｅ８０２よりも大きいことを示す場合は、このＲＩＭ無効化プロセスは失敗し（１０１０）、インストールされたプログラムも、ＲＩＭ証明書も変更されない。しかしながら、そのチェック結果が、オプショナルコンポーネント制御構造体が有効であることを示す場合は、オプショナルコンポーネント制御構造体（４０８）内のＲＩＭＰｒｏｔｅｃｔＶａｌｕｅ８０２を、１００４で取得したｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタの現在の値に１を足したものに設定する（１０１２）。暗号署名は、１００２で取得した秘密鍵で署名されたＰＫＣＳ ｖ１．５アルゴリズムに従って生成される（１０１４）。次に、ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ仕様書に説明されているタスクを実行する。既存の内部ＲＩＭ証明書が、インクリメントされたＲＩＭＰｒｏｔｅｃｔカウンタ値で再有効化され（１０１６）、ＲＩＭ証明書およびオプショナルコンポーネント制御構造体（４０８）をロールバックやリフラッシュの攻撃から保護するために、ｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタの値がインクリメントされる（１０１８）。最後に、残りの無効化機能をＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ仕様書に説明されているように実行する（１０２０）。

図１１は、オプショナルコンポーネントの有効化および無効化を制御する携帯装置１１００とサーバ１１０４の間の通信処理を示す。加えて、携帯装置１１００のＭｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ １１０２から、携帯装置１１００が要求するサービスも示す。まず、ユーザが、サーバに格納されている契約維持オプションを要求する１１０６。好適な実施形態において、これは、サーバとＳＳＬ（セキュアソケットレイヤ）セッションを確立することによって実行する。そしてサーバは、装置のＩＤおよび信頼性を検証するために、ＴＣＧ仕様書アーキテクチャの概要で定義されているような装置の認証を行う１１０８。装置は、ＭＴＭからサーバへのレポートを可能にするために、ＭＴＭへ認証の要求を転送する１１１０。ＭＴＭ１１０２から、装置を介してサーバへ確認メッセージを返す１１１２、１１１４。認証が成功し完了すると、好適な実施形態においては、顧客はＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換によってサーバとの間で共有秘密を確立する１１１６、１１１８。次にサーバが、特定された携帯電話に適した、カスタマイズされたオプショナルコンポーネントのページを送信する１１２０。好適な実施形態において、これは、ＨＴＭＬベースのページであり、どのオプションを装置に追加するか、または削除するかを選択するために、装置のユーザが交信を行う１１２２。所望の変更がなされた後、装置は、各オプショナルコンポーネントの新しい有効な状態または無効な状態を含む、交信完了を示すメッセージを送信する１１２４。好適な実施形態において、これはＰＯＳＴによって、先に送信されカスタマイズされたオプションページ１１２０内に記述されているＨＴＴＰＳページに実行される。他の好適な実施形態において、装置は、装置のユーザが行った変更毎に別々のメッセージを送信する。他の好適な実施形態において、装置は、ＡＪＡＸベースのメカニズムを用いて変更が行われる毎にすぐに、別々のメッセージを送信し、ユーザは、一旦変更を終えると完了メッセージを送信するオプションを選択する。サーバは、サーバの顧客データベースを適切に更新してから、装置に、１１１６および１１１８で確立された鍵で暗号化された、更新されたオプショナルコンポーネントの状態フラグの新たなセットを送信する１１２６。これらのステップは、図１８の項目１８１４、１８１６、１８１８、１８２０および１８２２に対応する。好適な実施例において、そのデータは論理証明書ラベルテーブル８１４と類似のフォーマットで記述される。つまり、論理証明書ラベル８０４と有効フラグ８０６との複数のペアを有し、−１ ８０８とＦＡＬＳＥ ８１０との一組のペアで終了する。これは図１７に示されており、オプショナルコンポーネント更新テーブル１７００は、上述のような論理証明書ラベルテーブル８１４と、およびデータが送信中に破損していないことを保証するテーブルのハッシュ１７０２とを有する。装置はオプショナルコンポーネント更新構造体を復号して検証し１１２８、それが成功すると、有効なコンポーネントおよび無効なコンポーネントを確実に正しく構成できるようにオプションの処理を開始する。

次のタスクは、この装置による各ＲＩＭ証明書の再インストールである１１３０。このインストールは、装置に、成功ＲＩＭ証明書と失敗ＲＩＭ証明書との何れも含む全ての内部ＲＩＭ証明書に対して繰り返される１１３２。この動作により、ＲＩＭ Ｐｒｏｔｅｃｔカウンタがインクリメントされる１１４６前に、証明書内に保持されるＲＩＭ Ｐｒｏｔｅｃｔカウンタ値が確実にインクリメントされる。それとは逆にカウンタが先にインクリメントされると、再インストールプロセスの完了前にシステムが機能停止し、装置はブートできない状態のままになる可能性がある。全ての既存の内部ＲＩＭ証明書が更新されると、現在のＲＩＭＰｒｏｔｅｃｔカウンタ値がＭＴＭから要求され１１３４、この値が返される１１３６。新たなオプショナルコンポーネント制御テーブルが、１１３４で取得されたＲＩＭＰｒｏｔｅｃｔカウンタ値よりも１つ大きな値と、１１２８からの更新されたオプション情報とを用いて作成される１１３８。ＭＴＭ１１０２に対し、図９に示した方法により生成された署名鍵を用いてデータに署名するよう要求する１１４０。ＭＴＭ １１０２が署名を返し１１４２、装置が、新たなオプショナルコンポーネント制御テーブルで以前のテーブルを上書きして格納する１１４４。

ロールバックやリフラッシュの攻撃から保護するために、装置はＭＴＭ１１０２に対しＲＩＭＰｒｏｔｅｃｔ単調カウンタのインクリメントを要求し１１４６、ＭＴＭ１１０２は動作の成功を応答する１１４８。これで、オプショナルコンポーネントに関連する、装置の全ての情報、具体的には、オプショナルコンポーネント制御構造体４０８、適切な成功ＲＩＭ証明書４０２および失敗ＲＩＭ証明書４０４、ならびにｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタが成功裏に更新され、装置がサーバに対し、処理の完了を通知する１１５０。最後に、確実に新たに有効化されたコンポーネントが動作し、無効なコンポーネントが動作を停止するように、装置が再ブートする１１５２。

上述のように、図８〜図１１はオプショナルコンポーネント制御テーブル４０８がＲＩＭＰｒｏｔｅｃｔＶａｌｕｅ８０２および暗号署名８１２を有する場合の好適な実施例を示しているが、以下に、オプショナルコンポーネントの、有効な状態、または無効な状態
を維持するための他の好適な実施形態を説明する。

図１２は、上記に説明したオプショナルコンポーネント制御テーブル８０８の簡易版であるオプショナルコンポーネント制御テーブル１２００における、このデータの好適な実施形態を示す。オプショナルコンポーネント制御テーブル１２００は、第１マッピングの一例である。上述のように、各行に２つのフィールドをもつテーブルがあり、最初のフィールドは、オプショナル信頼コンポーネントの論理証明書ラベル８０４であり、ここではｍａｐＩＤｔｏＣｅｒｔＴａｂｌｅ ５０８内の論理証明書ラベル６００に用いられるものと同一のコンポーネント識別子が用いられている。次は、論理証明書ラベルによって特定されるオプショナル信頼コンポーネントが有効か否かを示すフラグ８０６であり、有効な場合はＴＲＵＥに、無効な場合はＦＡＬＳＥに設定される。この値のペアは、システム内の各オプショナル信頼コンポーネントに対し繰り返され、−１の論理証明書ラベル８０８と、無効にするために通常はＦＡＬＳＥに設定されるフラグ８１０とによりテーブルを終了する。この値のペアのセットの集合は、論理証明書ラベルテーブル８１４として知られている。

図１３は、オプショナルコンポーネント制御テーブル１２００の完全性を維持するために用いられるオプショナルコンポーネント制御ＲＩＭ証明書の好適な実施形態を示す。このＲＩＭ証明書１３００は、装置内で作成されることから、ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ仕様書に定義されるように、常に内部ＲＩＭ証明書である。単一の装置の中に、そのような証明書は１つのみしかないことから、ｌａｂｅｌ １３０２は固定ストリングであり、好適な実施形態において「ＯＣＣ＿ＲＩＭＣ」に設定される。先の実施形態において、ロールバックまたはリフラッシュの攻撃からの保護にはＲＩＭＰｒｏｔｅｃｔＶａｌｕｅ ８０２が用いられたが、ここではｒｅｆｅｒｅｎｃｅＣｏｕｎｔｅｒ １３０４が用いられる。このフィールドは、ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ仕様書に定義されるように、ＭＴＭにより管理される。このＲＩＭ証明書は、決してＭＴＭ ＡＰＩ ＭＴＭ＿ＶｅｒｉｆｙＲＩＭＣｅｒｔＡｎｄＥｘｔｅｎｄには送られないため、ｓｔａｔｅ １３０６はＴＰＭ＿ＰＣＲ＿ＳＥＬＥＣＴＩＯＮが空になるように設定され、ｍｅａｓｕｒｅｍｅｎｔＰＣＲＩｎｄｅｘ １３０８の値は０に設定される。ｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅ １３１０は、オプショナルコンポーネント制御テーブル１２００のハッシュを格納する。好適な実施形態では、この値の生成にＳＨＡ−１アルゴリズムを用いる。このハッシュに署名する必要はない。フィールドｅｘｔｅｎｓｉｏｎＤｉｇｅｓｔＳｉｚｅ １３１２は０に設定され、ｅｘｔｅｎｔｉｏｎＤｉｇｅｓｔ １３１４は表示されない。他の好適な実施形態において、フィールドを０に設定したｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅ １３１０のハッシュを格納する代わりに、ｅｘｔｅｎｔｉｏｎＤｉｇｅｓｔ １３１４がオプショナルコンポーネント制御テーブル１２００のハッシュを格納し、ｅｘｔｅｎｓｉｏｎＤｉｇｅｓｔＳｉｚｅ １３１２がこのハッシュの大きさをバイト単位で保持する。最後に、ｉｎｔｅｇｒｉｔｙＣｈｅｃｋＳｉｚｅ １３１６およびｉｎｔｅｇｒｉｔｙＣｈｅｃｋ １３１８が、ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ仕様書に定義されるように、完全性チェック情報を格納する。

図１４は、本発明のオプショナルコンポーネント制御テーブルの、初期作成を示す。図示されたプロセスは、初期ブート用のＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ仕様書に詳述されている通り、ひとたびＭＴＭ １０２が初期起動すると起こる、装置を初めてブートする時のプロセスである。また、そのドキュメントに詳述されているように、初期ブートは携帯装置のライフサイクルにおいて他の時点でも起こりえるため、図１４は必要に応じた構造体の再作成も示す。まず、初期ブートシーケンスにおいてＭＴＭおよび信頼性のルートを確立して初期化するために十分な初期化を行った後に、既存のオプショナルコンポーネント制御テーブル１２００が存在するか否かを確認する１４００。存在する場合１４０２、その構造体のハッシュを算出し１４０４、オプショナルコンポーネント制御ＲＩＭ証明書１３００を呼び出す１４０６。呼び出しが成功し、ｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅ １３１０に格納されたハッシュ値が１４０４で算出したハッシュ値と等しい場合、ＭＴＭ＿ＶｅｒｉｆｙＲＩＭＣｅｒｔがＴＰＭ＿ＳＵＣＣＥＳＳを返し、構造体が最新でかつ改竄されていないことを確認した場合は、ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅに定義されているように、他の処理と共にその初期ブート手順を続ける１４２０。１４０２または１４０８における何れかのチェック結果が失敗である場合は、オプショナルコンポーネント制御テーブル１２００およびオプショナルコンポーネント制御ＲＩＭ証明書を再作成するか、または初めて作成する。まず、デフォルトのオプショナルコンポーネント制御テーブル１２００を作成し１４１０、その構造体のハッシュを算出する１４１２。次に、ｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅ １３１０を１４１２で算出したハッシュ値に設定して、署名されていないオプショナルコンポーネント制御ＲＩＭ証明書１３００を作成する１４１４。この署名されていない証明書を用いてＭＴＭ ＡＰＩ ＭＴＭ＿ＩｎｓｔａｌｌＲＩＭを呼び出すことにより１４１６、ＭＴＭは、ＭＴＭ ＡＰＩ ＭＴＭ＿ＩｎｓｔａｌｌＲＩＭを、有効な内部ＲＩＭ証明書を作成するためのテンプレートとして用いる。有効な内部ＲＩＭ証明書は、現在のｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ値をｒｅｆｅｒｅｎｃｅＣｏｕｎｔｅｒフィールド１３０４に挿入し、ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ仕様書に定義されているように秘密内部鍵を用いてｉｎｔｅｇｒｉｔｙＣｈｅｃｋＤａｔａ １３１８を生成することで作成される。これら２つの新たな構造体が格納され１４１８、初期ブート手順が、ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅで指定されている通り、他の処理と共に続く１４２０。

図１５は、ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅのセクション６．３．４．５で説明されているＲＩＭ無効化のタスクに必要な、本発明の追加の処理を示す。その仕様書には、ＲＩＭ＿Ａｕｔｈがどのように検証されるか、ＲＩＭ＿Ｃｅｒｔ有効性リストがどのようにチェックされ、新しい有効性リスト上に対応する外部ＲＩＭ＿Ｃｅｒｔを有しない全ての内部ＲＩＭ＿Ｃｅｒｔがどのように削除されるか、残りの全ての内部ＲＩＭ＿Ｃｅｒｔがどのように再有効化されるか、また、ｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタがどのように更新されるかが説明されている。図１５が示すプロセスにより、ｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタが更新され、残りの全ての内部ＲＩＭ＿Ｃｅｒｔが再有効化される。まず、オプショナルコンポーネント制御テーブル１２００を取得し１５００、その構造体のハッシュを算出し１５０２、オプショナルコンポーネント制御ＲＩＭ証明書１３００を呼び出す１５０４。この呼び出しに失敗した場合、つまり、ｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅ １３１０に格納されたハッシュ値が１５０２で算出したハッシュ値と等しくない場合、またはＭＴＭ＿ＶｅｒｉｆｙＲＩＭＣｅｒｔがＴＰＭ＿ＳＵＣＣＥＳＳ以外の値を返し、この構造体が最新でないか、または改竄されていることを示す場合は１５０６、ＲＩＭ無効化処理は失敗であり１５０８、インストールされたプログラムもＲＩＭ証明書も変更されない。

一方、チェックの結果がオプショナルコンポーネント制御テーブル１２００が有効であることを示している場合は、ＭＴＭは、１５０４で取得した既存の証明書を用いてＭＴＭ ＡＰＩ ＭＴＭ＿ＩｎｓｔａｌｌＲＩＭを呼び出して１５１０、ｒｅｆｅｒｅｎｃｅＣｏｕｎｔｅｒ フィールド１３０４に挿入され、インクリメントされたｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ値を伴う新しい内部ＲＩＭ証明書を作成するためのテンプレートとして使用し、ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ 仕様書に説明されているように、秘密内部鍵を用いてｉｎｔｅｇｒｉｔｙＣｈｅｃｋＤａｔａ １３１８を生成する。

次に、ＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ仕様書に説明されているタスクを実行する。既存の内部ＲＩＭ証明書はインクリメントされたＲＩＭＰｒｏｔｅｃｔカウンタ値で再有効化され１５１２、ｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタがインクリメントされ１５１４、信頼されたコンポーネントのＲＩＭ証明書およびオプショナルコンポーネント制御ＲＩＭ証明書１３００の両方をロールバックまたはリフラッシュの攻撃から保護する。最後に、残りの無効化機能をＴＣＧ Ｍｏｂｉｌｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ仕様書に説明されている通りに実行する１５１６。

図１６は、オプショナルコンポーネントの有効化および無効化を制御する携帯装置１６００とサーバ１６０４の間の通信処理を示す。加えて、携帯装置１６００のＭｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ １６０２から、携帯装置１６００が要求するサービスも示す。

まず、ユーザが、サーバに格納されている契約維持オプションを要求する１６０６。好適な実施形態において、これは、サーバとＳＳＬ（セキュアソケットレイヤ）セッションを確立することによって実行する。そしてサーバは、装置のＩＤおよび信頼性を検証するために、ＴＣＧ仕様書アーキテクチャの概要で定義されているような装置の認証を行う１６０８。装置は、ＭＴＭからサーバへのレポートを可能にするために、ＭＴＭへ要求を転送する１６１０。ＭＴＭ１６０２から、装置を介してサーバへ確認メッセージを返す１６１２、１６１４。認証が成功し完了すると、好適な実施形態においては、顧客はＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換によってサーバとの間で共有秘密を確立する１６１６、１６１８。次にサーバが、特定された携帯電話に適した、カスタマイズされたオプショナルコンポーネントのページを送信する１６２０。好適な実施形態において、これは、ＨＴＭＬベースのページであり、どのオプションを装置に追加するか、または削除するかを選択するために装置のユーザが交信する１６２２。所望の変更がなされた後、装置は、各オプショナルコンポーネントの新しい有効な状態または無効な状態を含む、交信完了を示すメッセージを送信する１６２４。好適な実施形態において、これはＰＯＳＴによって先に送信されカスタマイズされたオプションページ１６２０内に記述されているＨＴＴＰＳページに実行される。他の好適な実施形態において、装置は、装置のユーザが行った変更毎に別々のメッセージを送信する。他の好適な実施形態において、装置は、ＡＪＡＸベースのメカニズムを用いて変更が行われる毎にすぐに、別々のメッセージを送信し、ユーザは、一旦変更を終えると完了メッセージを送信するオプションを選択する。サーバは、サーバの顧客データベースを適切に更新してから、装置に、１６１６および１６１８で確立された鍵で暗号化された、更新されたオプショナルコンポーネントの状態フラグの新たなセットを送信する１６２６。これらのステップは、図１８の項目１８１４、１８１６、１８１８、１８２０および１８２２に対応する。好適な実施例において、そのデータは論理証明書ラベルテーブル８１４と類似のフォーマットで記述される。つまり、論理証明書ラベル８０４と有効フラグ８０６との複数のペアを有し、−１ ８０８とＦＡＬＳＥ ８１０との一組のペアで終了する。これは図１７に示されており、オプショナルコンポーネント更新テーブル１７００は、上述のような論理証明書ラベルテーブル８１４、およびデータが送信中に破損していないことを保証するテーブルのハッシュ１７０２を有する。装置はオプショナルコンポーネント更新構造体を復号して検証し１６２８、それが成功すると、有効なコンポーネントおよび無効なコンポーネントを確実に正しく構成できるようにオプションの処理を開始する。

次のタスクは、装置が各ＲＩＭ証明書を、装置に存在する成功ＲＩＭ証明書と失敗ＲＩＭ証明書の両方の、全ての内部ＲＩＭ証明書に対して繰り返し再インストールすることである１６３０、１６３２。この動作により、ＲＩＭ Ｐｒｏｔｅｃｔカウンタがインクリメントされる１６４６前に、証明書内に保持されるＲＩＭ Ｐｒｏｔｅｃｔカウンタ値が確実にインクリメントされる。それとは逆にカウンタが先にインクリメントされると、再インストールプロセスの完了前にシステムが機能停止し、装置はブートできない状態のままになるかも知れない。全ての既存の内部ＲＩＭ証明書が更新されると、１６２８で得られたオプショナルコンポーネント更新構造体からの状態フラグを用いて、新しいオプショナルコンポーネント制御テーブル１２００を作成し１６３４、このテーブルのハッシュを算出する１６３６。次に、ｍｅａｓｕｒｅｍｅｎｔＶａｌｕｅ １３１０を１６３６で算出したハッシュ値に設定して、署名されていないオプショナルコンポーネント制御ＲＩＭ証明書１３００を作成する１６３８。この署名されていない証明書を用いてＭＴＭ ＡＰＩ ＭＴＭ＿ＩｎｓｔａｌｌＲＩＭを呼び出すことにより１６４０、ＭＴＭはＭＴＭ ＡＰＩ ＭＴＭ＿ＩｎｓｔａｌｌＲＩＭを、有効な内部ＲＩＭ証明書を作成するためのテンプレートとして用いる。有効な内部ＲＩＭ証明書は、現在のｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ値をｒｅｆｅｒｅｎｃｅＣｏｕｎｔｅｒフィールド１３０４に挿入し、ＴＣＧ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ仕様書に定義されているように秘密内部鍵を用いてｉｎｔｅｇｒｉｔｙＣｈｅｃｋＤａｔａ １３１８を生成することで作成される。そして、ＭＴＭは携帯装置に署名された構造体を返す１６４２。この新しい構造体は格納される１６４４。

ロールバックやリフラッシュの攻撃から保護するために、装置はＭＴＭ１６０２に対しＲＩＭＰｒｏｔｅｃｔ単調カウンタのインクリメントを要求し１６４６、ＭＴＭ１６０２は動作の成功を応答する１６４８。これで、オプショナルコンポーネントに関連する、装置の全ての情報、具体的には、オプショナルコンポーネント制御構造体４０８、適切な成功ＲＩＭ証明書４０２および失敗ＲＩＭ証明書４０４、ならびにｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタが成功裏に更新され、装置がサーバに対し、処理の完了を通知する１６５０。最後に、確実に新たに有効化されたコンポーネントが動作し、無効なコンポーネントが動作を停止するように、装置が再ブートする１６５２。

図１８は、本発明の別の態様、つまり、装置のユーザによるオプショナルコンポーネントの維持を可能にするサーバ３１６の構造体が、その装置上で有効化または無効化されることを示す。重要な機能上の構成要素およびデータの項目は以下の通りである。秘密生成部１８０２、ページ生成部１８０８、オプション処理部１８１６、暗号化部１８２０、およびトランザクションコミッタ１８２６の５つのブロックは、外部装置へのインタフェースポイントであり、情報の伝達は左から右へ進む。まず、秘密生成部１８０２が、Ｄｉｆｆｅ−Ｈｅｌｌｍａｎ等の、双方向通信プロトコル１８００を用いて共有鍵１８０４を確立する。次に、携帯装置が契約維持ウェブページを要求する１８０６。その結果、ページ生成部１８０８がページを作成し、ページ生成部１８０８が現在のオプショナルコンポーネントの状態を顧客オプション維持部１８１０に要求し、顧客オプション維持部１８１０が現在の状態を知るために顧客オプションデータベース１８１２に問い合わせを行う。装置のユーザが生成されたウェブページとの交信を終えると、完了メッセージがサーバに送信され１８１４、オプション処理部１８１６が、顧客オプション維持部１８１０にその新たなオプションを通知し、顧客オプションデータベース１８１２内でトランザクションを開始する。そのオプションはオプショナルコンポーネント制御テーブル生成部１８１８に送られ、そこでオプショナルコンポーネント更新テーブル１７００にフォーマットされる。暗号化部１８２０が、共有鍵１８０４でこの構造体を暗号化し、その構造体を携帯装置に返す１８２２。最後に、携帯装置が全ての内部構造体を更新し終えると、トランザクションコミッタ１８２６が完了メッセージを受信し１８２４、顧客オプション維持部１８１０に、顧客オプションデータベース１８１２内で進行中のトランザクションを完了しなければならないことを通知する。

上記の図は、オプショナルコンポーネント制御テーブルがどのように管理されるかを説明しており、以下の項では、それがマルチパスセキュアブート中にどのように使用されるかを説明する。

図１９は、図１の先行技術に基づいて、本発明を示すものである。この図は、ＲＴＶ＋ＲＴＭ、および信頼エリア１００内のＭＴＭインタフェース等のコアエレメントが自己検証を終えた時点でのセキュアブートプロセスの状態をとらえたものである。ＭＴＭ １０２は、この信頼エリア１００のコアであるが、他の重要な構成要素としては、セキュアブートにおいて各コンポーネントが正しく開始し、動作しているか否かを示すフラグであるコンポーネントエラー状態１９００と、適切なコンポーネントに対しコンポーネントエラー状態１９００を設定するコンポーネントエラーレコーダ１９０２と、信頼エリア１００に追加される次のコンポーネントを立ち上げるランチャ１０８と、ラベル−証明書対応テーブル１９０８に従って必要な成功ＲＩＭ証明書１１４または失敗ＲＩＭ証明書１９０６を検索する証明書検索部１９０４と、オプショナルコンポーネント制御テーブル１９１０と、コンポーネントエラー状態１９００とがある。証明書検索部１９０４は、検索手段の一例である。また、ランチャ１０８は、信頼コンポーネント１ １１６を実行する場合において、算出手段、検証手段、更新手段および実行手段の一例である。また、実行されたコンポーネント（例えば、実行が成功した信頼コンポーネント１ １１６）が、次のコンポーネントを実行する場合において、算出手段、検証手段、更新手段および実行手段の一例である。ラベル−証明書対応テーブル１９０８は、第２マッピングの一例である。オプショナルコンポーネント制御テーブル１９１０は、第１マッピングの一例である。失敗ＲＩＭ証明書１９０６は、１つ以上のコンポーネントが正しく動作しなかった場合の、セキュアブート中に期待されるプラットフォームの状態を記述したものである。オプショナルコンポーネント制御テーブル１９１０は、図８および図１２に示されるように、論理証明書ラベルテーブル８１４によって記述されたデータを有し、完全性が保護されたコンテナに格納されている。すなわち、提供手段（又は記憶手段、図示せず）によって、第２マッピングの一例であるラベル−証明書対応テーブル１９０８および第１マッピングの一例であるオプショナルコンポーネント制御テーブル１９１０が提供（格納）される。

失敗シーケンサ１９１８は、次コンポーネントテーブル１９１２およびコンポーネントエラー状態１９００を用いて、どのコンポーネントを次に立ち上げるかを選択する。失敗シーケンサ１９１８は、コンポーネントの実行が失敗した場合において、算出手段、検証手段、更新手段および実行手段の一例である。これは図２４に詳細に説明されている。これらのＲＩＭ証明書１１４および１９０６、次コンポーネントテーブル１９１２、オプショナルコンポーネント制御テーブル１９１０、ならびにラベル−証明書対応テーブル１９０８は、完全性が保護されるべきであることから、完全性保護１１２されたデータ項目の集合内に置かれる。次コンポーネントテーブル１９１２は、第３マッピングの一例である。なお、図１と同様に、完全性保護はデータの外的特性ではなく、固有特性である。また、成功ＲＩＭ証明書１１４および失敗ＲＩＭ証明書１９０６のフォーマットは内容的に同じであり、重要な違いは、ＩＤ−証明書対応テーブル１９０８に従ってそれらに割り当てられた役割である。そのテーブルに基づく以外には、２つを区別することは不可能であり、区別する必要もない。

オプショナルコンポーネントを伴うセキュアブートの目的は、信頼エリア１００を拡大し、可能であれば全ての追加的コンポーネント、つまり信頼コンポーネント１ １１６、信頼コンポーネント２ １１８、および信頼コンポーネント３ １２０を包含することであるが、何れかのコンポーネントが起動に失敗した場合、信頼エリア１００は拡大してそれらをカバーすることはない。１２２、１２４および１２６とラベル付けされた、ランチャ１０８から、信頼コンポーネント１ １１６、信頼コンポーネント２ １１８、および信頼コンポーネント３ １２０への点線は、先行技術の一態様による通常の実行パスを示す。先行技術の他の態様においては、最終的な信頼コンポーネントとしてのオペレーティングシステム（図示せず）に伴って、さらなる信頼コンポーネントが存在してもよい。１９１４および１９１６とラベル付けされた、信頼コンポーネント１ １１６から、失敗シーケンサ１９１８、および信頼コンポーネント３ １２０への太線は、本発明の一態様による、信頼コンポーネント２ １１８が起動に失敗した場合、またはオプショナルコンポーネント制御テーブル１９１０において無効であると印付けられている場合は、別の実行パスが利用可能であることを示す。

図２０は、本発明から得られる新たなセキュアブートの結果を示す。利用可能なコンポーネントは図２の通りであり、期待される成功結果２０８は、当然、１つの有効な結果である。しかしながら、失敗の状態２１２の代わりに、新しいフロー２０００は、失敗または無効な信頼コンポーネント４ ２００をスキップし、信頼コンポーネント５ ２０２まで継続することで、機能する信頼エリア２００２を作成することができるが、その機能は限られている。同様に、フロー２００４は、信頼コンポーネント２ １１８および信頼コンポーネント５ ２０２が正しく動作しないか、またはオプショナルコンポーネント制御テーブル１９１０において無効であると印付けられている場合に、別の機能する信頼エリア２００６を作成することを示しているが、その機能もまた限られている。信頼エリアの図２０８、２００２、および２００６において、ＴＣ１は信頼コンポーネント１ １１６、ＴＣ２は信頼コンポーネント２ １１８、ＴＣ３は信頼コンポーネント３ １２０、ＴＣ４は信頼コンポーネント４ ２００、ＴＣ５は信頼コンポーネント５ ２０２、ＯＳはオペレーティングシステム２０４を表している。全コンポーネントはＭＴＭ１０２に依存し、加えて、信頼コンポーネント２ １１８は信頼コンポーネント１ １１６に依存し、信頼コンポーネント４ ２００および信頼コンポーネント５ ２０２は信頼コンポーネント３ １２０に依存する。オペレーティングシステム２０４は、信頼コンポーネント１ １１６および信頼コンポーネント３ １２０に依存する。陰付きの部分は、使用できないコンポーネントを示す。

図２１Ａから図２４は、本発明のセキュアブートシステムの重要な構成要素間の制御フローシーケンスを示す。本発明のセキュアブートシステムは、完全性測定によって検証されるソフトウェアコンポーネントを実行する方法を実行する。まず、先行技術に係る図２１Ａにおいて、システムは電源オン２１００から開始し、システムの基本ブート実行２１０２に進み、ＲＴＶ、ＲＴＭ、ＭＴＭ等を初期化し２１０４、信頼エリアの自己検証に用いるＲＩＭ証明書を要求し２１０８、見つからない場合は、致命的エラーがあるので、装置は失敗の状態へ移行する２１３２しかない。ＲＩＭ証明書が見つかった場合２１１０、ＲＩＭ証明書内で特定されているＰＣＲのサブセットを連結させることで、そのＲＩＭ証明書をＭＴＭ内に拡張する２１１２。拡張動作が失敗した場合２１１４は、致命的エラーがあるので、装置は失敗の状態へ移行する２１３２しかない。そうでなければ、重要なデータテーブルの完全性を検証する必要がある。次コンポーネントテーブル１９１２およびラベル−証明書対応テーブル１９０８は、ＲＩＭ証明書５００のｅｘｔｅｎｓｉｏｎＤｉｇｅｓｔフィールド５０４によって保護されているので、ハッシュの有効性をチェック可能であり、ＭＴＭ ＡＰＩ ＭＴＭ＿ＶｅｒｉｆｙＲＩＭＣｅｒｔが、ＲＩＭ証明書５００自体の完全性を検証する２１１６ために用いられる。オプショナルコンポーネント制御テーブル１９１０の２つの実施形態は、異なる検証手順を要するため、その検証プロセス２１１８は、図２１Ｂおよび図２１Ｃにおいて説明する。何れかの検証動作が失敗した場合２１２０は、致命的エラーがあるので、装置は失敗の状態へ移行する２１３２しかない。当業者は、この検証プロセスには、後続のシーケンスにおいてテーブルを使用する毎に、先だって検証を実行する等、他にも可能な実施方法があることを理解すると思われる。

次に、信頼コンポーネント１の検証のためのＲＩＭ証明書を要求する２１２２ことにより、期待される現在の状態と、信頼コンポーネント１ １１６の期待される状態とを記述したＲＩＭ証明書が得られる。つまり、ソフトウェアコンポーネント（信頼コンポーネント１ １１６）を識別する所定の論理識別子を第１マッピング（オプショナルコンポーネント制御テーブル４０８または１２００）から検索することで、ソフトウェアコンポーネントが有効であるか否かを示す状態フラグを取得する。そして、ソフトウェアコンポーネントの検証証明書を識別する所定の論理識別子と前のコンポーネントの状態とを第２マッピング（ＩＤ−証明書対応テーブル５０８）から検索することで、完全性測定証明書（ＲＩＭ証明書）を取得する（２１２６）。ＲＩＭ証明書が返されないと２１２４、ＣＰＵは、信頼コンポーネント１に用いられるＲＩＭ証明書を取得する際にエラーがあったことを示すインジケータを伴って、制御を失敗シーケンサに引き渡し２１３４、失敗シーケンサがそのエラーを処理できるようにする。つまり、コンポーネントが有効でなければ、失敗シーケンサがエラー処理を行う。この処理は、下記図２４に示されている。失敗の理由として考えられることは、２１２２でＲＩＭ証明書を要求する際に、証明書検索プロセス１９０４でオプショナルコンポーネント制御テーブル１９１０を参照し、要求されたＲＩＭ証明書に対応するコンポーネントが無効であることが分かると、独特のエラーコードを返し、要求されたＲＩＭ証明書が無効なコンポーネントに対応することを示すことである。

この信頼コンポーネントのハッシュ値を算出し２１２６、その算出値がＲＩＭ証明書に格納されている値と等しいか否かを確認する２１２８。つまり、実行すべきソフトウェアコンポーネント（信頼コンポーネント１ １１６）のチェック値（ハッシュ値）を算出する（２１２６）。そして、完全性測定値が完全性測定証明書内の完全性測定値に一致することと、算出されたチェック値が完全性測定証明書（取得したＲＩＭ証明書）内のチェック値に一致することとを検証する（２１２８）。ハッシュ値が等しくない場合、偶発的または意図的な破損等の問題がコンポーネントにあることを示している。その後、ＣＰＵが、信頼コンポーネント１にハッシュエラーがあったことを示すインジケータを伴って、制御を失敗シーケンサに引き渡し２１３６、失敗シーケンサがそのエラーを処理できるようにする。つまり、検証が不成功であれば、失敗シーケンサがエラー処理を行う。この処理は、下記図２４に示されている。ハッシュ値が等しければ、コンポーネントエラーレコーダが、このコンポーネントに対するハッシュのチェックが成功したことを記録する２１３０。処理が図２２へ続く。

図２１Ｂは、オプショナルコンポーネント制御テーブルの実施形態が図８に示す通りである場合に、オプショナルコンポーネント制御テーブル１９１０が有効であることを検証するための、オプショナルコンポーネント制御テーブルを検証するステップ２１１８の詳細を示す。まず、オプショナルコンポーネント制御テーブル上の署名を検証するための秘密鍵の公開部分を取得する２１５０。鍵が見つからなければ２１５２、エラーが起こり、エラーコードが呼び出しプロセスに返される２１５４。鍵がある場合は、次のオプショナルコンポーネント制御テーブルを探す２１５６。テーブルが存在しなければ２１５８、エラーが起こり、エラーコードが呼び出しプロセスに返される２１５４。ここで、ｃｏｕｎｔｅｒＲＩＭＰｒｏｔｅｃｔ単調カウンタ値を取得し２１６０、オプショナルコンポーネント制御テーブルを検証する２１６２。この検証とは、算出された署名と格納されている署名とが一致することを確認して改竄を検知すること、および、格納されているＲＩＭＰｒｏｔｅｃｔＶａｌｕｅ ８０２が呼び出された単調カウンタ値よりも大きいかまたは同じであることを確認することの両方を含む。検証が失敗すれば２１６４、エラーが起こり、エラーコードが呼び出しプロセスに返される２１５４。検証が成功すれば、オプショナルコンポーネント制御テーブルは有効であり、成功コードが呼び出しプロセスに返され２１６６、図２１Ａに示されているようにセキュアブートプロセスを継続する。

図２１Ｃは、オプショナルコンポーネント制御テーブルを検証するステップ２１１８の詳細を示す。ここでオプショナルコンポーネント制御テーブルの実施形態は図１２および図１３に示す通りであり、オプショナルコンポーネント制御テーブル１９１０が有効であることを検証するためのものである。まず、オプショナルコンポーネント制御テーブルを保護するＲＩＭ証明書を探す２１７０。ＲＩＭ証明書が見つからなければ２１７２、エラーが起こり、エラーコードが呼び出しプロセスに返される２１７４。次に、オプショナルコンポーネント制御テーブルを探す２１７６。テーブルが存在しなければ２１７８、エラーが起こり、エラーコードが呼び出しプロセスに返される２１７４。そうでなければ、オプショナルコンポーネント制御テーブル１２００のハッシュを算出し２１８０、その結果をオプショナルコンポーネント制御テーブルのＲＩＭ証明書内に格納されている参照ハッシュ値と比較する２１８２。一致しなければ２１８４、エラーが起こり、エラーコードが呼び出しプロセスに返される２１７４。次に、証明書自体が有効であることを確かめるために、ＭＴＭに対し、ＭＴＭのＡＰＩ ＭＴＭ＿ＶｅｒｉｆｙＲＩＭＣｅｒｔをオプショナルコンポーネント制御テーブルのＲＩＭ証明書に対して実行するよう要求する２１８６。ＡＰＩがエラーコードを返せば２１８８、エラーが起こり、エラーコードが呼び出しプロセスに返される２１７４。これが成功すれば、オプショナルコンポーネント制御テーブルは有効であり、成功コードが呼び出しプロセスに返され２１９０、図２１Ａに示されているようにセキュアブートプロセスを継続する。

図２２は、セキュアブートシーケンスのさらなる動作を示す。先行技術に従って、このＲＩＭ証明書に定義されているＰＣＲに、このＲＩＭ証明書に定義されている値を付加することによって、以前に取得されたＲＩＭ証明書をＭＴＭ内に拡張する２２００。つまり、状態フラグによってソフトウェアコンポーネントが有効であることを示し、かつ、検証（２１２８）が成功していれば、完全性測定証明書内のチェック値の指示を含むように、現在の完全性測定値を更新する（２２００）。この拡張が正しく機能したか否かを確認するために、拡張動作の結果をチェックする２２０２。正しく機能していなければ、ＣＰＵは、制御を失敗シーケンサに引き渡し２２０４、失敗シーケンサがそのエラーを処理できるようにする。この処理は、下記図２４に示されている。ハッシュ値が正しく拡張された場合は、コンポーネントが信頼エリアによって完全に信頼できることを示し、その結果、信頼コンポーネント１が立ち上げられ２２０６、制御がこの新たなコンポーネントに渡される。つまり、ソフトウェアコンポーネントが有効であり、かつ、検証が成功していれば、ソフトウェアコンポーネントを実行する（２２０６）。

最初の処理は、信頼コンポーネントを初期化する２２０８ことであり、これにより当該コンポーネントや当該コンポーネントが制御できる他のハードウェア等が必要とする初期化を実行することができる。コンポーネントは、初期化に成功したことをセルフチェックし２２１０、エラーがあれば、信頼コンポーネントは、現在の信頼コンポーネントが初期化に失敗したことを示すエラーコードを伴って、制御を失敗シーケンサに引き渡し２２１２、失敗シーケンサがそのエラーを処理できるようにする。この処理は、下記図２４に示されている。エラーがなければ、コンポーネントエラーレコーダが、このコンポーネントの初期化が成功したことを記録する２２１４。次に、信頼コンポーネントは、自己検証に用いるＲＩＭ証明書を要求し２２１６、期待される現在の状態と、所定のＰＣＲに拡張される所定の値とを記述したＲＩＭ証明書を得る。必要なＲＩＭ証明書が見つからなければ２２１７、信頼コンポーネントは、現在の信頼コンポーネントが初期化に失敗したことを示すエラーコードを伴って、制御を失敗シーケンサに引き渡し２２１２、失敗シーケンサがそのエラーを処理できるようにする。この処理は、下記図２４に示されている。そうでなければ、先行技術に従ってＲＩＭ証明書がＭＴＭ内に拡張され２２１８、拡張動作が成功したか否かがチェックされる２２２０。拡張動作が失敗すれば、信頼コンポーネントは、現在の信頼コンポーネントが自己検証に失敗したことを示すエラーコードを伴って、制御を失敗シーケンサに引き渡し２２２２、失敗シーケンサがそのエラーを処理できるようにする。この処理は、下記図２４に示されている。値が正しく拡張されれば、現在の信頼コンポーネントは、必要に応じ他のタスクの実行を継続する２２２４。処理が図２３へ続く。

図２３は、セキュアブートシーケンスのさらなる動作を示す。まず、他にロードすべき信頼コンポーネントがあるか否かを確認し２３００、なければ、セキュアブートは成功裏に完了している２３０２。なお、この実施形態において、オプショナルコンポーネントの検証が失敗していれば、このオプショナルコンポーネントはブートされていない。よって、ステップ２３０２において、セキュアブートが成功裏に完了していても、ブートされていないオプショナルコンポーネントがあるかも知れない。１の実施形態において、これは本当の確認ではない。つまり、１の実施形態のオペレーティングシステムにおいて、実行が定義されている他のタスクが完了した２２２４後には、他のコンポーネントを探さないように、ロードシーケンスの最後のコンポーネントが実装される。他に立ち上げるべきコンポーネントがあれば、次の信頼コンポーネントの検証に用いられるＲＩＭ証明書が要求される２３０４。ここで、次の信頼コンポーネントとは、次にブートされるべき信頼コンポーネントを意味する。ＲＩＭ証明書が返されないと２３０５、ＣＰＵは、次の信頼コンポーネントに用いられるＲＩＭ証明書を取得する際にエラーがあったことを示すインジケータを伴って、制御を失敗シーケンサに引き渡し２３２２、失敗シーケンサがそのエラーを処理できるようにする。この処理は、下記図２４に示されている。失敗の理由として考えられることは、２３０４でＲＩＭ証明書を要求する際に、証明書検索プロセス１９０４でオプショナルコンポーネント制御テーブル１９１０を参照し、要求されたＲＩＭ証明書に対応するコンポーネントが無効であることが分かると、独特のエラーコードを返し、要求されたＲＩＭ証明書が無効なコンポーネントに対応することを示すことである。

次の信頼コンポーネントに用いるためのハッシュの算出におけるＲＩＭ証明書に記述されているものと同じ方法で、信頼コンポーネントのハッシュ値を計算する２３０６。その後、この算出されたハッシュ値が次の信頼コンポーネントのＲＩＭ証明書に格納されているハッシュ値と等しいか否かを確認する２３０８。等しくなければ、偶発的または意図的な破損等の問題がコンポーネントにあることを示しており、信頼コンポーネントは、次の信頼コンポーネントのハッシュが有効化されなかったことを示すエラーコードを伴って、制御を失敗シーケンサに引き渡し２３１０、失敗シーケンサがそのエラーを処理できるようにする。この処理は、下記図２４に示されている。ハッシュ値が等しければ、コンポーネントエラーレコーダが、次の信頼コンポーネントに対するハッシュのチェックが成功したことを記録する２３１２。次に、先行技術に従ってこのＲＩＭ証明書がＭＴＭ内に拡張され２３１４、拡張動作が成功したか否かを確認する２３１６。拡張動作が失敗すれば、信頼コンポーネントは、次の信頼コンポーネントのＭＴＭへの拡張に失敗したことを示すエラーコードを伴って、制御を失敗シーケンサの開始時点に引き渡し２３１８、失敗シーケンサがそのエラーを処理できるようにする。この処理は、下記図２４に示されている。その代わりにハッシュ値が正しく拡張された場合は、次の信頼コンポーネントは信頼エリアによって完全に信頼できることを示しているので、次の信頼コンポーネントを立ち上げ２３２０、ステップ２２０８からの処理を繰り返す。

図２４は、本発明の失敗シーケンサの動作を示す。まず、渡されたエラーコードを、コンポーネントエラー状態１９００に記録する２４００。例えば、状態フラグによってコンポーネントが有効でないと示されていれば（２１３４）、コンポーネントの検証失敗証明書を識別する所定の論理識別子と、前のコンポーネントの状態とを第２マッピング（ＩＤ−証明書対応テーブル５０８）から検索することで、無効な完全性測定証明書（失敗ＲＩＭ証明書４０４）を取得する。そして、無効な完全性測定証明書内に格納されている、コンポーネントの状態が無効である旨の指示を示すように現在の完全性測定値を更新する。また、検証が不成功であれば（２１３６）、コンポーネントの検証失敗証明書を識別する所定の論理識別子と、前のコンポーネントの状態とを第２マッピング（ＩＤ−証明書対応テーブル５０８）から検索することで、失敗完全性測定証明書（失敗ＲＩＭ証明書４０４）を取得する。そして、失敗完全性測定証明書内に格納されている、完全性測定が不成功である旨の指示を含むように現在の完全性測定値を更新する。

次に、現在のコンポーネントエラー状態全てをコンポーネントエラー状態１９００から取得する２４０２。これらは、後に、立ち上げるべき次の信頼コンポーネントを見つけるための、次のコンポーネントテーブル１９１２の検索２４０４に用いられる。つまり、コンポーネントを識別する所定の論理識別子と、前のコンポーネントの状態とを第３マッピング（次コンポーネントテーブル１９１２）から検索することで、実行すべき別のソフトウェアコンポーネントを取得する。定められた次コンポーネントがあるか否かを確認し２４０６、なければ、セキュアブートは失敗の状態に入り２４０８、装置は通常の安全な方法での起動に失敗することになる。次の信頼コンポーネントがあれば、次の信頼コンポーネント検証に用いるＲＩＭ証明書を要求し２４１０、期待される現在の状態および次の信頼コンポーネントの期待される状態を記述した失敗ＲＩＭ証明書を取得する。ここで、次の信頼コンポーネントとは、次にブートされるべき信頼コンポーネントを意味する。ＲＩＭ証明書が返されないと２４１１、ＣＰＵは、次の信頼コンポーネントに用いられるＲＩＭ証明書を取得する際にエラーがあったことを示すインジケータを伴って、制御を失敗シーケンサに引き渡し２４２８、失敗シーケンサがそのエラーを処理できるようにする。ＲＩＭ証明書が正しく返された場合、次の信頼コンポーネントのハッシュ値を算出し２４１２、その算出されたハッシュ値をＲＩＭ証明書内のハッシュ値と比較する２４１４。等しくなければ、偶発的または意図的な破損等の問題がコンポーネントにあることを示しており、信頼コンポーネントは、次の信頼コンポーネントのハッシュが有効化されなかったことを示すエラーコードを伴って、制御を失敗シーケンサの開始時点に戻し２４１６、失敗シーケンサがそのエラーを処理できるようにする。ハッシュ値が等しければ、コンポーネントエラーレコーダが、次の信頼コンポーネントに対するハッシュのチェックが成功したことを記録する２４１８。次に、このＲＩＭ証明書は、先行技術に従ってＭＴＭ内に拡張され２４２０、拡張動作が成功したか否かが確認される２４２２。拡張動作が失敗すれば、失敗シーケンサは、次の信頼コンポーネントのＭＴＭへの拡張に失敗したことを示すエラーコードを伴って、制御を失敗シーケンサの開始時点に戻し２４２６、失敗シーケンサがそのエラーを処理できるようにする。ハッシュ値が正しく拡張された場合は、次の信頼コンポーネントは信頼エリアによって完全に信頼できることを示しているので、次の追加的信頼コンポーネントを立ち上げ２４２４、示されているとおり、制御フローが上記信頼コンポーネントの初期化２２０８から継続する。

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

（１）仮想化環境の場合、１の実施形態において、ハイパーバイザが、実行すべき最後の信頼コンポーネントとなる。他の実施形態では、ハイパーバイザ信頼コンポーネントが実行された後に、オペレーティングシステム等の他の信頼コンポーネントが実行される。

（２）上記実施形態において、各コンポーネントは、立ち上げの前に検証される。しかしながら、本発明は、各コンポーネントが立ち上げの後に検証されるシステムにも適用できる。その場合、各コンポーネントの検証に失敗すれば、システムはそのコンポーネントを停止させる。

（３）上述の実施の形態では、ＴＣＧ仕様書に類似の方法で検証が行われる。しかしながら、本発明は、コンポーネントが鎖のように連鎖して検証される（つまり、あるコンポーネントがその後に立ち上がるコンポーネントを検証する）検証方法を用いてシステムのコンポーネントを検証することが可能な検証システムである限り、他の検証システムにも適用できる。例えば、ハッシュ値をＭＴＭ内に拡張することは、ＴＣＧ仕様書に特有の動作であるため省略してもよい。

（４）上述の実施の形態では、検証は証明書（ＲＩＭ証明書）内でハッシュ値を使用することにより実行された。しかしながら、ハッシュ値を使用しない他の検証方法が本発明に適用されてもよい。

従来のチェックサムや、コンポーネントから抽出される別のデータ（例えば、コンポーネントから抽出される第１所定ビット）が、検証を実行するために使用されてもよい。また、証明書は、完全性チェック値を含むデータグループに置き換えられてもよい。

さらに、検証方法は、コンポーネントから抽出される値と期待される値が等しいか否かをチェックすることに限定されない。例えば、コンポーネントのサイズを確認し、もしサイズが所定量より大きいか、または小さいなら、コンポーネントは検証されたと判断されるとしてもよい。これらの検証方法は、ハッシュ値と、その期待値とを比較するほど厳密なものではないが、高速に実行される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１００ 信頼エリア
１０２ ＭＴＭ
１０８ ランチャ
１１２、４００ 完全性保護
１１４、４０２ 成功ＲＩＭ証明書
１１６ 信頼コンポーネント１
１１８ 信頼コンポーネント２
１２０ 信頼コンポーネント３
４０４、１９０６ 失敗ＲＩＭ証明書
４０６、１９０８ ラベル−証明書対応テーブル
４０８、１２００、１９１０ オプショナルコンポーネント制御テーブル
４１０ デフォルトオプショナルコンポーネント制御テーブル
１９００ コンポーネントエラー状態
１９０２ コンポーネントエラーレコーダ
１９０４ 証明書検索部
１９１２ 次コンポーネントテーブル
１９１８ 失敗シーケンサ

Claims (7)

1. 装置が、完全性測定によって検証されるソフトウェアコンポーネントを実行する方法であって、
   前記装置は、提供手段と、検索手段と、算出手段と、検証手段と、更新手段と、実行手段とを備え、
   前記方法は、
   ａ）前記提供手段が、論理識別子からソフトウェアコンポーネントの有効状態フラグへの第１マッピングを提供するステップと、
   ｂ）前記提供手段が、前記論理識別子と、前のソフトウェアコンポーネントの状態情報とから、検証データを含む実際の完全性測定証明書への第２マッピングを提供するステップと、
   ｃ）前記検索手段が、前記ソフトウェアコンポーネントを識別する所定の論理識別子を前記第１マッピングから検索することで、前記ソフトウェアコンポーネントが有効であるか否かを示す状態フラグを得るステップとを含み、
   ｄ）前記ソフトウェアコンポーネントが有効でないことを前記状態フラグが示す場合に、
   ｉ）前記検索手段が、前記ソフトウェアコンポーネントの検証失敗証明書を識別する所定の論理識別子と、前記前のソフトウェアコンポーネントの状態とを前記第２マッピングから検索することで、無効な完全性測定証明書を得るステップと、
   ii）前記更新手段が、前記無効な完全性測定証明書内に格納されている、ソフトウェアコンポーネントの状態が無効である旨の指示を示すように現在の完全性測定値を更新するステップとを含み、
   ｅ）前記ソフトウェアコンポーネントが有効であることを前記状態フラグが示す場合に、
   ｉ）前記検索手段が、前記ソフトウェアコンポーネントの検証証明書を識別する所定の論理識別子と、前記前のソフトウェアコンポーネントの状態とを前記第２マッピングから検索することで、完全性測定証明書を得るステップと、
   ii）前記算出手段が、実行すべき前記ソフトウェアコンポーネントのチェック値を算出するステップと、
   iii）前記検証手段が、前記完全性測定値が前記完全性測定証明書内の完全性測定値に一致することと、前記算出されたチェック値が前記完全性測定証明書内のチェック値に一致することとを検証するステップと、
   iv）前記更新手段が、前記検証が成功していれば、前記完全性測定証明書内の前記チェック値の指示を含むように現在の完全性測定値を更新するステップと、
   ｖ）前記実行手段が、前記検証が成功していれば、前記ソフトウェアコンポーネントを実行するステップと
   を含む方法。
2. 装置が、完全性測定によって検証されるソフトウェアコンポーネントを実行する方法であって、
   前記装置は、提供手段と、検索手段と、算出手段と、検証手段と、更新手段と、実行手段とを備え、
   前記方法は、
   ａ）前記提供手段が、論理識別子からソフトウェアコンポーネントの有効状態フラグへの第１マッピングを提供するステップと、
   ｂ）前記提供手段が、前記論理識別子と、前のソフトウェアコンポーネントの状態情報とから、検証データを含む実際の完全性測定証明書への第２マッピングを提供するステップと、
   ｃ）前記検索手段が、前記ソフトウェアコンポーネントを識別する所定の論理識別子を前記第１マッピングから検索することで、前記ソフトウェアコンポーネントが有効であるか否かを示す状態フラグを得るステップと、
   ｄ）前記検索手段が、前記ソフトウェアコンポーネントの検証証明書を識別する所定の論理識別子と、前記前のソフトウェアコンポーネントの状態とを前記第２マッピングから検索することで、完全性測定証明書を得るステップと、
   ｅ）前記算出手段が、実行すべき前記ソフトウェアコンポーネントのチェック値を算出するステップと、
   ｆ）前記検証手段が、前記完全性測定値が前記完全性測定証明書内の完全性測定値に一致することと、前記算出されたチェック値が前記完全性測定証明書内のチェック値に一致することとを検証するステップと、
   ｇ）前記検証が不成功であれば、
   ｉ）前記検索手段が、前記ソフトウェアコンポーネントの検証失敗証明書を識別する所定の論理識別子と、前記前のソフトウェアコンポーネントの状態とを前記第２マッピングから検索することで、失敗完全性測定証明書を得るステップと、
   ii）前記更新手段が、前記失敗完全性測定証明書内に格納されている、完全性測定が不成功である旨の指示を含むように現在の完全性測定値を更新するステップとを含み、
   ｈ）前記検証が成功であれば、
   i）前記更新手段が、前記ソフトウェアコンポーネントが有効であることを前記状態フラグが示していれば、前記完全性測定証明書内の前記チェック値の指示を含むように現在の完全性測定値を更新するステップと、
   ii）前記実行手段が、前記ソフトウェアコンポーネントが有効であることを前記状態フラグが示していれば、前記ソフトウェアコンポーネントを実行するステップと
   を含む方法。
3. 前記方法は、さらに、
   前記ソフトウェアコンポーネントが有効でないか、または前記検証が不成功である場合に、
   ｉ）前記提供手段が、論理識別子と、前のソフトウェアコンポーネントの状態情報とからコンポーネント識別子への第３マッピングを提供するステップと、
   ii）前記検索手段が、前記ソフトウェアコンポーネントを識別する所定の論理識別子と、前記前のソフトウェアコンポーネントの状態とを前記第３マッピングから検索することで、実行すべき別のソフトウェアコンポーネントを識別する論理識別子を得るステップと、
   iii）前記検索手段が、前記実行すべき別のソフトウェアコンポーネントを識別する論理識別子と、前記前のソフトウェアコンポーネントの状態情報とを前記第２マッピングから検索することで、別のソフトウェアコンポーネントの完全性測定証明書を取得し、
   iv）前記算出手段が、前記実行すべき別のソフトウェアコンポーネントのチェック値を算出し、
   ｖ）前記検証手段が、前記完全性測定値が前記別のソフトウェアコンポーネントの完全性測定証明書内の完全性測定値に一致すること、前記別のソフトウェアコンポーネントの算出されたチェック値が前記別のソフトウェアコンポーネントの完全性測定証明書内のチェック値に一致することとを検証し、
   vi）前記更新手段が、前記別のソフトウェアコンポーネントの検証が成功である場合に、前記別のソフトウェアコンポーネントの完全性測定値内の前記別のソフトウェアコンポーネントのチェック値の指示を含むように現在の完全性測定値を更新し、
   vii）前記実行手段が、前記別のソフトウェアコンポーネントの検証が成功である場合に、前記別のソフトウェアコンポーネントを実行する
   を含む請求項１又は２に記載の方法。
4. 請求項１又は２記載の完全性測定によって検証されるソフトウェアコンポーネントを実行する方法を、コンピュータに実行させるためのコンピュータソフトウェアコードを格納するコンピュータ読み取り可能な記録媒体。
5. 完全性測定によって検証されるソフトウェアコンポーネントを実行する装置であって、
   ａ）論理識別子からソフトウェアコンポーネントの有効状態フラグへの第１マッピングと、前記論理識別子と前のソフトウェアコンポーネントの状態情報とから、検証データを含む実際の完全性測定証明書への第２マッピングとを提供する提供手段と、
   ｂ）前記ソフトウェアコンポーネントを識別する所定の論理識別子を前記第１マッピングから検索することで、前記ソフトウェアコンポーネントが有効であるか否かを示す状態フラグを取得し、かつ、前記ソフトウェアコンポーネントが有効であることを前記状態フラグが示す場合に、前記ソフトウェアコンポーネントの検証証明書を識別する所定の論理識別子と前記前のソフトウェアコンポーネントの状態とを前記第２マッピングから検索することで完全性測定証明書を得る検索手段と、
   ｃ）前記ソフトウェアコンポーネントが有効であることを前記状態フラグが示す場合に、実行すべき前記ソフトウェアコンポーネントのチェック値を算出する算出手段と、
   ｄ）前記ソフトウェアコンポーネントが有効であることを前記状態フラグが示す場合に、前記完全性測定値が前記完全性測定証明書内の完全性測定値に一致し、かつ前記算出されたチェック値が前記完全性測定証明書内のチェック値に一致することを検証する検証手段と、
   ｅ）前記ソフトウェアコンポーネントが有効であることを前記状態フラグが示す場合に、前記検証が成功していれば、前記完全性測定証明書内の前記チェック値の指示を含むように現在の完全性測定値を更新する更新手段と、
   ｆ）前記ソフトウェアコンポーネントが有効であることを前記状態フラグが示す場合に、前記検証が成功していれば、前記コンポーネントを実行する実行手段と
   を備え、
   前記ソフトウェアコンポーネントが有効でないことを前記状態フラグが示す場合、
   ｉ）前記検索手段は、前記ソフトウェアコンポーネントの検証失敗証明書を識別する所定の論理識別子と、前記前のソフトウェアコンポーネントの状態とを前記第２マッピングから検索することで、無効な完全性測定証明書を取得し、
   ｉｉ）前記更新手段は、前記無効な完全性測定証明書に格納されている、ソフトウェアコンポーネントの状態が無効である旨の指示を示すように現在の完全性測定値を更新する
   装置。
6. 完全性測定によって検証されるソフトウェアコンポーネントを実行する装置であって、
   ａ）論理識別子からソフトウェアコンポーネントの有効状態フラグへの第１マッピングと、前記論理識別子と前のソフトウェアコンポーネントの状態情報とから、検証データを含む実際の完全性測定証明書への第２マッピングとを提供する提供手段と、
   ｂ）前記ソフトウェアコンポーネントを識別する所定の論理識別子を前記第１マッピングから検索することで、前記ソフトウェアコンポーネントが有効であるか否かを示す状態フラグを取得し、かつ、前記ソフトウェアコンポーネントの検証証明書を識別する所定の論理識別子と前記前のソフトウェアコンポーネントの状態とを前記第２マッピングから検索することで完全性測定証明書を得る検索手段と、
   ｃ）実行すべき前記コンポーネントのチェック値を算出する算出手段と、
   ｄ）前記完全性測定値が前記完全性測定証明書内の完全性測定値に一致し、かつ前記算出されたチェック値が前記完全性測定証明書内のチェック値に一致することを検証する検証手段と、
   ｅ）前記検証が成功していれば、前記ソフトウェアコンポーネントが有効であることを前記状態フラグが示していれば、前記完全性測定証明書内の前記チェック値の指示を含むように現在の完全性測定値を更新する更新手段と、
   ｆ）前記検証が成功していれば、前記ソフトウェアコンポーネントが有効であることを前記状態フラグが示していれば、前記ソフトウェアコンポーネントを実行する実行手段と
   を備え、
   前記検証が不成功である場合、
   ｉ）前記検索手段は、前記ソフトウェアコンポーネントの検証失敗証明書を識別する所定の論理識別子と、前記前のソフトウェアコンポーネントの状態とを前記第２マッピングから検索することで、失敗完全性測定証明書を取得し、
   ｉｉ）前記更新手段は、前記失敗完全性測定証明書内に格納されている、完全性測定が不成功である旨の指示を含むように現在の完全性測定値を更新する
   装置。
7. 請求項５又は６記載の装置は、集積回路として構成されている
   装置。

Images