本発明の第1の形態における情報処理装置(装置1120)は、複数のモジュール各々に先立ってロードされるモジュールを示す期待プラットフォーム情報(tPCR値)を前記複数のモジュールごとに格納する格納手段(PSCデータベース1112)と、前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示すアクティブ情報を記録する管理手段(コンポーネント・PSCマップ1202)と、前記アクティブモジュールの次のモジュールをロードする場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報(PSCツリー1206の中にあるtPCR状態1604(図6))を生成し、(ii)前記次のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記次のモジュールをロードし、かつ、(iv)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する、ロード制御手段(OSサポート1200)とを備えることを特徴とする情報処理装置である。
図18は、第1の形態の情報処理装置により解決される課題を説明する図である。
図19は、tPCR(Transient PCR)を説明する図である。
図20は、第1の形態の情報処理装置による処理を説明する図である。
なお、図18では、遷移図1101Aが示される。また、図19では、第1の形態の情報処理装置の処理を示す欄1101Baと、従来例の処理を示す欄1101Bbとが示される。
第1の形態の情報処理装置は、上述の通り、格納手段(PSCデータベース1112)と、管理手段(コンポーネント・PSCマップ1202)と、ロード制御手段(OSサポート1200)とを備える。これにより、図19、図20により示される機能が実現される。これにより、図18により説明される課題が解決される効果が得られる。
他方、第1の形態の情報処理装置と対比される従来例では、上記3つの手段のうちの一部又は全部がない。このため、従来例では、図19、図20により示される機能が実現されず、図18の課題が解決される効果が得られない。
すなわち、上記の構成、作用、効果を有するか否かの点で、第1の形態の情報処理装置は、従来例に対して相違する。
なお、実施形態の説明の第1部分における装置1120(図1)は、後述される、実施形態の説明の第2部分における装置2120(図21A)に対応する。そして、装置1120のアプリケーション1100は、装置2120のアプリケーション2100に対応する。このように、装置1120の各構成は、その構成が例外的な構成である場合を除いて、装置2120における、その構成と同様の構成に対応する。以下では、このような、構成の間の対応についての詳しい説明は、適宜省略される。
なお、以下では、公知の文献に記載された技術事項については、その技術事項の詳しい説明が、適宜省略される。ここで、公知の文献は、先述された、”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”、及びその他の文献を含む。
本発明の第2の形態における情報処理装置は、前記ロード制御手段が、モジュールが終了する場合に、前記モジュールはアクティブモジュールでないと示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とする情報処理装置である。
この構成によると、第1モジュールが終了する場合に、ロード制御手段は管理手段を制御してアクティブ情報を更新し、その終了モジュールがアクティブモジュールでないことを示す。
したがって、当該情報処理装置は、1以上のモジュールが終了した後であっても、拡張されたプラットフォーム情報を用いて検証することにより、現在ロードされているモジュールに正確に対応するアクティブモジュール全ての蓄積プラットフォーム情報を生成することができる。
本発明の第3の形態における情報処理装置は、さらに、前記アクティブモジュールの次のモジュールをロードする場合に、前記次のモジュールのダイジェスト値(ハッシュ)を算出し、期待ダイジェスト値と算出したダイジェスト値とを比較することで前記次のモジュールが有効であるかどうかを判定する判定手段(抽象化レイヤAPI1108)を備え、前記ロード制御手段は、前記次のモジュールが有効であると判定され、検証手段による検証が成功した場合には、前記次のモジュールをロードし、前記アクティブモジュールのうちの1つが終了した後にアクティブモジュールが少なくとも1つ残っている場合であって、前記少なくとも1つの残ったアクティブモジュールの次のモジュールをロードする場合には、前記少なくとも1つの残ったアクティブモジュールのダイジェスト値の算出をスキップするよう算出手段を制御し、前記少なくとも1つの残ったアクティブモジュールの判定をスキップするよう前記判定手段を制御することを特徴とする情報処理装置である。
この構成によると、情報処理装置は、アクティブモジュールのうちの1つが終了した後にアクティブモジュールが少なくとも1つ残っている場合であって、少なくとも1つの残ったアクティブモジュールの次のモジュールをロードする場合に、アクティブモジュールのダイジェスト値の算出をスキップして、算出されたダイジェスト値を用いてアクティブモジュールを再び判定することをスキップする。
先行技術では、(この構成の蓄積プラットフォーム情報に対応する)PCR値をリセットまたは蓄積することしかできない。ゆえに、PCRを、それの以前の値に、モジュールが終了した後に戻すために、PCR値がリセットされなければならず、そこで、以前実行された各モジュールについて、それらのダイジェスト値を再計算して、それぞれのダイジェスト値をPCRに蓄積する。
一方、本発明の本形態では、情報処理装置が、どのモジュールがアクティブモジュールであるかを管理し、アクティブモジュールに対応する期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成する。ゆえに、アクティブモジュールのダイジェスト値の算出と、算出されたダイジェスト値を用いた判定とをスキップすることができる。これは、アクティブモジュールに対するこれらの処理が前もって行われており、それ以降はアクティブモジュールは変更されないことになっているからである。したがって、この構成により、第2モジュールのローディング処理を高速化することができる。
本発明の第4の形態における情報処理装置は、前記管理手段が、有向非巡回グラフを用いて前記アクティブモジュールを示す情報を管理することを特徴とする情報処理装置である。
この構成によると、管理手段は、有向非巡回グラフを用いてアクティブモジュールを示す情報を管理する。通常、複数のモジュールは他のモジュールに従属したり従属されたりしてロードされるので、有向非巡回グラフはこの関係を表現するのに適している。したがって、この構成によって、管理手段は、1以上のアクティブモジュールを容易に管理することができる。
本発明の第5の形態における情報処理装置は、前記ロード制御手段が、前記次のモジュールをロードする場合に、前記次のモジュールと当該次のモジュールの期待プラットフォーム情報とを示すノードを生成し、かつ、前記アクティブモジュールに対応するノードに、生成したノードが従属するように、前記生成したノードを前記有向非巡回グラフに付け加えるよう、前記管理手段を制御することを特徴とする情報処理装置である。
この構成によると、情報処理装置は、次のモジュールをロードする場合に、次のモジュールと当該次のモジュールの期待プラットフォーム情報とを示すノードを生成し、かつ、アクティブモジュールに対応するノードに、生成したノードが従属するように、生成したノードを有向非巡回グラフに付け加えるよう、管理手段を制御する。すなわち、非巡回グラフは、どのアクティブモジュールが他のアクティブモジュールに従属しているかを正しく反映するものとなる。したがって、この構成により、管理手段は、アクティブモジュール間の従属関係を正確に管理することができる。
本発明の第6の形態における情報処理装置は、前記ロード制御手段が、前記次のモジュールがロードされて終了した場合に、前記次のモジュールを示すノードと当該ノードに従属するノード全てとを削除するよう、前記管理手段を制御することを特徴とする情報処理装置である。
この構成によると、情報処理装置は、次のモジュールがロードされて終了した場合に、次のモジュールを示すノードと当該ノードに従属するノード全てとを削除するよう、管理手段を制御する。すなわち、終了したモジュールに対応するノードだけでなく、当該ノードに従属するノードも削除される。終了したモジュールのノードに従属するノードは終了モジュールの子モジュールに対応しており、その親モジュールの終了時に子モジュールは終了する。したがって、この構成により、管理手段は、複数のモジュールのうちどれを本当にロード中なのかを正確に管理することができる。
本発明の第7の形態における情報処理装置は、前記ロード制御手段が、前記次のモジュールを示すノードが従属することになっている親ノードを検索して、各ノードの期待プラットフォーム情報を前記有向非巡回グラフのルートから前記親ノードへ蓄積することによって前記蓄積プラットフォーム情報を生成することを特徴とする情報処理装置である。
この構成によると、ロード制御手段は、次のモジュールを示すノードが従属することになっている親ノードを検索して、各ノードの期待プラットフォーム情報を前記有向非巡回グラフのルートから親ノードへ蓄積することによって蓄積プラットフォーム情報を生成する。この構成によって、情報処理装置は、次のモジュールに先立ってブートするアクティブモジュールを反映した蓄積プラットフォーム情報を間違いなく生成することができる。これは、有向非巡回グラフがアクティブモジュール間の従属関係を反映するからである。
本発明の第8の形態における情報処理装置は、前記ロード制御手段が前記蓄積プラットフォーム情報を所定期間の後に削除することを特徴とする情報処理装置である。
この構成によると、ロード制御手段は、蓄積プラットフォーム情報を所定期間の後に削除する。したがって、この構成により、プラットフォーム情報の存続期間を制限することによって改ざんは困難になる。
本発明の第9の形態における情報処理装置は、前記複数のモジュールが、それぞれが1以上のモジュールを含む第1モジュールグループと第2モジュールグループとを含み、前記情報処理装置は、さらに、前記第1モジュールグループのうち、どのモジュールをロードしたかを示す第1蓄積プラットフォーム情報を格納する登録手段を備え、前記格納手段は、さらに、前記第2モジュールグループのモジュールをロードする前に前記第1モジュールグループのモジュール全てをロードすべきことを示す第1期待プラットフォーム情報を格納し、前記ロード制御手段は、前記第1モジュールグループのモジュールに対して、(i)当該モジュールを検証し、(ii)検証が成功した場合には前記モジュールをロードし、かつ、(iii)前記モジュールがロードされた場合には前記モジュールのプラットフォーム情報を前記第1蓄積プラットフォーム情報に蓄積することによって前記第1蓄積プラットフォーム情報を更新し、前記第2モジュールグループのモジュールをロードする場合には、(i)前記第1期待プラットフォーム情報を前記登録手段に格納された第1蓄積プラットフォーム情報と比較することによって第1モジュールグループのモジュール全てが正常にロードされたことを検証し、前記アクティブモジュールの次の第2モジュールグループのモジュールをロードする場合であって、前記第1モジュールグループのモジュール全てが正常にロードされたことが検証された場合には、前記ロード制御手段は、(i)第2モジュールグループのモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記次のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記次のモジュールをロードし、かつ、(iv)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とする情報処理装置である。
この構成によると、ロード制御手段は、複数のモジュールのうち1つが正常にロードされるたびに蓄積プラットフォーム情報を削除し、複数のモジュールのうち1つをロードすることになるたびに蓄積プラットフォーム情報を生成する。したがって、蓄積プラットフォーム情報を改ざんから保護することができる。
本発明の第10の形態における情報処理装置は、前記複数のモジュールが、それぞれが1以上のモジュールを含む第1モジュールグループと第2モジュールグループとを含み、前記情報処理装置は、さらに、前記第1モジュールグループのうち、どのモジュールをロードしたかを示す第1蓄積プラットフォーム情報を格納する登録手段を備え、前記格納手段は、さらに、前記第2モジュールグループのモジュールをロードする前に前記第1モジュールグループのモジュール全てをロードすべきことを示す第1期待プラットフォーム情報を格納し、前記ロード制御手段は、前記第1モジュールグループのモジュールに対して、(i)当該モジュールを検証し、(ii)検証が成功した場合には前記モジュールをロードし、かつ、(iii)前記モジュールがロードされた場合には前記モジュールのプラットフォーム情報を前記第1蓄積プラットフォーム情報に蓄積することによって前記第1蓄積プラットフォーム情報を更新し、前記第2モジュールグループのモジュールをロードする場合には、(i)前記第1期待プラットフォーム情報を前記登録手段に格納された第1蓄積プラットフォーム情報と比較することによって第1モジュールグループのモジュール全てが正常にロードされたことを検証し、前記アクティブモジュールに続く、第2モジュールグループの1のモジュールをロードする場合であって、前記第1モジュールグループのモジュール全てが正常にロードされたことが検証された場合には、前記ロード制御手段は、(i)第2モジュールグループのモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記1のモジュールの前記期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記1のモジュールをロードし、かつ、(iv)前記1のモジュールがロードされた場合には、前記1のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とする情報処理装置。
この構成によると、ロード制御手段は、(i)第1期待プラットフォーム情報を登録手段に格納された第1蓄積プラットフォーム情報と比較することによって第1モジュールグループのモジュール全てが正常にロードされたことを検証し、(ii)第1モジュールグループのモジュール全てが正常にロードされたことが検証された場合に、第2モジュールグループのモジュールに対して、生成、検証、ロードおよび制御を行う。
この構成により、情報処理装置は、第1モジュールグループに対する検証と第2モジュールグループに対する検証とを別々に行うことができる。したがって、当該情報処理装置は、第2モジュールグループのモジュールがいくつか終了しても、モジュール全ての検証を行う必要がない。
さらに、第2モジュールグループに対する処理は、第1モジュールに対する検証が失敗すれば、開始されない。したがって、たとえ第2モジュールグループに対する検証しか再度行わないとしても、第2モジュールグループのモジュールを、第1モジュールを含むモジュールが正常にロードされている信頼性のある環境上にロードすることができる。
本発明の第11の形態における情報処理装置は、前記第2モジュールグループのモジュールが終了して第2モジュールグループのモジュールをロードする場合に、前記ロード制御手段は、前記第1期待プラットフォーム情報を前記第1蓄積プラットフォーム情報と比較することによって、前記第1モジュールグループのモジュール全てが正常にロードされ、かつ、終了していないことを検証し、検証が成功した場合には、前記第1モジュールグループのモジュールに対する検証をスキップすることを特徴とする情報処理装置である。
この構成によると、ロード制御手段は記第1期待プラットフォーム情報を第1蓄積プラットフォーム情報と比較することによって、第1モジュールグループのモジュール全てが正常にロードされ、かつ、終了していないことを検証し、検証が成功した場合には、第1モジュールグループのモジュールに対する検証をスキップする。
したがって、当該情報処理装置は、第2モジュールグループの終了されたモジュールを高速にリロードしたり、第2モジュールグループの他のモジュールを高速にロードすることができる。
本発明の第12の形態における情報処理装置は、前記第1モジュールグループが、システム層のモジュールを含み、前記第2モジュールグループは、アプリケーション層のモジュールを含むことを特徴とする情報処理装置である。
この構成によると、第1モジュールグループは、システム層のモジュールを含み、第2モジュールグループは、アプリケーション層のモジュールを含む。
したがって、アプリケーション層のモジュールなど、頻繁に終了することになるモジュールに対する検証を、たとえそのモジュールが終了した後であっても、高速に再開することができる。
本発明の第13の形態における情報処理方法は、情報処理装置用の情報処理方法であって、前記情報処理装置は、複数のモジュール各々に先立ってロードされるモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示すアクティブ情報を記録する管理手段とを備え、前記情報処理方法は、前記アクティブモジュールの次のモジュールをロードする場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記次のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記次のモジュールをロードし、かつ、(iv)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する、ロード制御ステップを備えることを特徴とする情報処理方法である。
本発明の第14の形態におけるコンピュータプログラムは、情報処理装置用の記録媒体に記録されたコンピュータプログラムであって、前記情報処理装置は、複数のモジュール各々に先立ってロードされるモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示すアクティブ情報を記録する管理手段とを備え、前記コンピュータプログラムは、ロード制御ステップを前記情報処理装置に実行させるコンピュータプログラムであって、前記ロード制御ステップでは、前記アクティブモジュールの次のモジュールをロードする場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記次のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記次のモジュールをロードし、かつ、(iv)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とするコンピュータプログラムである。
本発明の第15の形態における集積回路デバイスは、情報処理装置に用いられる集積回路デバイスであって、前記情報処理装置は、複数のモジュール各々に先立ってロードされるモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示すアクティブ情報を記録する管理手段とを備え、前記集積回路デバイスは、前記アクティブモジュールの次のモジュールをロードする場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記次のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記次のモジュールをロードし、かつ、(iv)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する、ロード制御手段を備えることを特徴とする集積回路デバイスである。
本発明の第16の形態における情報処理装置は、当該情報処理装置は、サーバに接続され、前記ロード制御手段は、前記蓄積プラットフォーム情報を送信する要求を前記サーバから受信した場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、かつ、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記1のモジュールの前記期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)前記検証が成功した場合には、前記蓄積プラットフォーム情報を前記サーバに送信することを特徴とする情報処理装置である。
本発明の第17の形態における情報処理装置は、前記ロード制御手段は、さらに、(i)前記蓄積プラットフォーム情報を生成するために、どの期待プラットフォームを用いるかを示す情報を生成し、(ii)前記情報に基づいて、前記蓄積プラットフォーム情報を検証するために用いる署名情報を生成し、(iii)前記署名情報が付加されている前記蓄積プラットフォーム情報を送信することを特徴とする情報処理装置である。
本発明の第18の形態における情報処理装置は、請求項16に記載の情報処理装置であって、前記ロード制御手段は、1のモジュールが終了する場合に、前記1のモジュールはアクティブモジュールでないと示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とする情報処理装置である。
本発明の第19の形態における情報処理装置は、さらに、前記アクティブモジュールに続く1のモジュールをロードする場合に、前記1のモジュールのダイジェスト値を算出し、期待ダイジェスト値と算出したダイジェスト値とを比較することで前記1のモジュールが有効であるかどうかを判定する判定手段を備え、前記ロード制御手段は、前記1のモジュールが有効であると判定され、検証手段による検証が成功した場合には、前記1のモジュールをロードし、前記アクティブモジュールのうちの1つが終了した後にアクティブモジュールが少なくとも1つ残っている場合であって、前記少なくとも1つの残ったアクティブモジュールに続く1のモジュールをロードする場合には、前記少なくとも1つの残ったアクティブモジュールのダイジェスト値の算出をスキップするよう算出手段を制御し、前記少なくとも1つの残ったアクティブモジュールの判定をスキップするよう前記判定手段を制御することを特徴とする情報処理装置である。
本発明の第20の形態における情報処理装置は、前記管理手段は、有向非巡回グラフを用いて前記アクティブモジュールを示す情報を管理することを特徴とする情報処理装置である。
本発明の第21の形態における情報処理装置は、前記ロード制御手段は、前記1のモジュールをロードする場合に、前記1のモジュールと当該1のモジュールの前記期待プラットフォーム情報とを示すノードを生成し、かつ、従属する当該モジュールに対応するノードに、前記生成したノードが従属するように、前記生成したノードを前記有向非巡回グラフに付け加えるよう、前記管理手段を制御することを特徴とする情報処理装置である。
本発明の第22の形態における情報処理装置は、前記ロード制御手段は、前記1のモジュールがロードされて終了した場合に、前記1のモジュールを示すノードと、前記1のモジュールを示す前記ノードに従属するノード全てとを削除するよう、前記管理手段を制御することを特徴とする情報処理装置である。
本発明の第23の形態における情報処理装置は、前記ロード制御手段は、前記1のモジュールを示す前記ノードが従属することになっている親ノードを検索して、各ノードの期待プラットフォーム情報を前記有向非巡回グラフのルートから前記親ノードへ蓄積することによって前記蓄積プラットフォーム情報を生成することを特徴とする情報処理装置である。
本発明の第24の形態における情報処理装置は、前記ロード制御手段は前記蓄積プラットフォーム情報を所定期間の後に削除することを特徴とする情報処理装置である。
本発明の第25の形態における情報処理装置は、前記ロード制御手段は、前記複数のモジュールのうち1つが正常にロードされるたびに前記蓄積プラットフォーム情報を削除し、前記複数のモジュールのうち1つをロードすることになるたびに蓄積プラットフォーム情報を生成することを特徴とする情報処理装置である。
本発明の第26の形態における情報処理装置は、前記複数のモジュールは、それぞれが1以上のモジュールを含む第1モジュールグループと第2モジュールグループとを含み、前記情報処理装置は、さらに、前記第1モジュールグループのうち、どのモジュールをロードしたかを示す第1蓄積プラットフォーム情報を格納する登録手段を備え、前記格納手段は、さらに、前記第2モジュールグループのモジュールをロードする前に前記第1モジュールグループのモジュール全てをロードすべきことを示す第1期待プラットフォーム情報を格納し、前記ロード制御手段は、前記第1モジュールグループのモジュールに対して、(i)当該モジュールを検証し、(ii)検証が成功した場合には前記モジュールをロードし、かつ、(iii)前記モジュールがロードされた場合には前記モジュールのプラットフォーム情報を前記第1蓄積プラットフォーム情報に蓄積することによって前記第1蓄積プラットフォーム情報を更新し、前記第2モジュールグループのモジュールをロードする場合には、(i)前記第1期待プラットフォーム情報を前記登録手段に格納された第1蓄積プラットフォーム情報と比較することによって第1モジュールグループのモジュール全てが正常にロードされたことを検証し、前記アクティブモジュールに続く、第2モジュールグループの1のモジュールをロードする場合であって、前記第1モジュールグループのモジュール全てが正常にロードされたことが検証された場合には、前記ロード制御手段は、(i)第2モジュールグループのモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記1のモジュールの前記期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記1のモジュールをロードし、かつ、(iv)前記1のモジュールがロードされた場合には、前記1のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とする情報処理装置である。
本発明の第27の形態における情報処理装置は、前記第2モジュールグループのモジュールが終了して第2モジュールグループのモジュールをロードする場合に、前記ロード制御手段は、前記第1期待プラットフォーム情報を前記第1蓄積プラットフォーム情報と比較することによって、前記第1モジュールグループのモジュール全てが正常にロードされ、かつ、まだ終了していないことを検証し、検証が成功した場合には、前記第1モジュールグループのモジュールに対する検証をスキップすることを特徴とする情報処理装置である。
本発明の第28の形態における情報処理装置は、前記第1モジュールグループは、システム層のモジュールを含み、前記第2モジュールグループは、アプリケーション層のモジュールを含むことを特徴とする情報処理装置である。
本発明の第29の形態における情報処理方法は、前記蓄積プラットフォーム情報を送信する要求をサーバから受信する受信ステップと、前記受信ステップにおいて前記要求を受信した場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、かつ、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記1のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)前記検証が成功した場合には、前記蓄積プラットフォーム情報を前記サーバに送信する、送信ステップとを含むことを特徴とする情報処理方法である。
本発明の第30の形態におけるコンピュータプログラムは、のコンピュータプログラムであって、前記蓄積プラットフォーム情報を送信する要求をサーバから受信する受信ステップと、前記受信ステップにおいて前記要求を受信した場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、かつ、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記1のモジュールの前記期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)前記検証が成功した場合には、前記蓄積プラットフォーム情報を前記サーバに送信する送信ステップとを前記情報処理装置に実行させるためのコンピュータプログラムである。
本発明の第31の形態における集積回路デバイスは、前記蓄積プラットフォーム情報を送信する要求をサーバから受信する受信部と、前記受信部が前記要求を受信した場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、かつ、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記1のモジュールの前記期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)前記検証が成功した場合には、前記蓄積プラットフォーム情報を前記サーバに送信する、送信手段とを備えることを特徴とする集積回路デバイスである。
拡張動作を取り消しできるようにすることによって、アプリケーションがPCRの使用を希望する度に新たな証明書を作成するという問題を回避しながら、PCRおよびRIM証明書の手段で信頼性の境界を実行中のアプリケーションに拡張できるようにする方法が必要である。
さらに、既存のRIM証明書および管理ツールを活用するため、TCGが定義したようなRIM証明書の構造体を使用する方法も必要である。
さらに、2つのアプリケーションが気づかずに同じPCRを共有することによって生じる問題を防ぎつつ利用可能なPCR数を拡張する方法も必要である。
さらに、アプリケーションを起動および終了しながら、信頼性の境界を、動的、効果的かつ信頼的に拡大縮小できる方法も必要である。
本発明では、tPCRの状態について安全に問い合わせるRIM証明書をアプリケーションが使用できる、一時的なPCR(tPCR)の概念を実現することにより、当該技術分野の上記の制限に対処している。これらのtPCRの存続期間は、これらを使用するアプリケーションの存続期間ほど長くなく、必要であればより短い期間でもよい。本発明のtPCRは、物理的PCRとは全く異なるものであるため、tPCRを認識していないアプリケーションは、同じ環境で従来どおりに動作してもよい。
好ましい実施形態によると、本発明は、MTMを備えた装置において実現されるが、その他の同類の安全策をMTMの代用としてもよい。必要なキーコンポーネントとは、セキュア処理環境(SPE)と前述したPCRとプラットフォーム状態証明書(PSC)に署名するための検証キーとPSCのデータを認証および処理する方法である。先行技術で説明されたようなRIM証明書が、PSCの具体例である。
本発明の他の好ましい実施形態によると、アプリケーションが実行開始するときに、アプリケーションに関連付けられたPSCを記録し、そして、そのアプリケーションが終了するときに、記録されたPSCおよび従属しているもの全てによりそれらの拡張動作が取り消される。
他の好ましい実施形態によると、拡張動作が行われる場合には、有向非巡回グラフに拡張証明書が記録される。この有向非巡回グラフには、その拡張証明書が子として従属する、拡張済みの他の証明書全てが含まれる。この拡張動作は、拡張動作の有向非巡回グラフから、その拡張動作のレコードと全ての従属レコードとを削除することによって取り消される。
他の好ましい実施形態によると、拡張動作が必要な場合には、この証明書が従属する証明書は、すでに拡張済みの証明書の現在の有向非巡回グラフに基づき動的に評価される。
(第1の実施形態)
以下に、本発明の好ましい実施形態について説明する。
第1の実施形態は、一時的なPCRの利用をサポートするシステムに関し、この一時的なPCRは、証明書によって定められた値以外の定義済み存続期間を有する。前述の追加オペレーティングシステム機能およびPSCの信頼できる検証を行うことによって、SPE付き装置の開発者は、これらのtPCRを扱うシステムを作成できる。使用対象のtPCRについて記述するPSCを提供することによって、このような装置におけるアプリケーションの開発者は、信頼できる実行を柔軟な方法で提供するアプリケーションを作成できる。本発明によると、アプリケーションは、いずれかのコンポーネントタイプとして定義されるが、独立型のプログラムや独立型のプログラム用プラグインモジュールやプラグイン用ヘルパーモジュールに限定されるものではない。
図1に、「TCG Mobile Reference Architecture」に記載された手段などのシステムのセキュアブートをサポートする場合における先行技術を示す。標準実行環境において、抽象化レイヤAPI1102を使用するアプリケーション1100が存在する。破線は、上方の前述した標準実行モードと、下方のセキュアモードとの間のセキュアモードインターフェース1106を示す。標準実行モードとは、ほとんどのコンピュータシステムが提供するような通常の実行環境である。セキュアモードでは、標準実行環境からはアクセスできないメモリ空間において、許可されたソフトウェアに限り実行可能なセキュア実行環境を提供する。本発明の好ましい実施形態では、セキュアモードしか分からないキーのプライベート部分を有するソフトウェアを暗号化することによって、この許可が行われるが、ホワイトリストや証明書などその他の技術を用いても構わない。この実行環境は、必要に応じて他のモジュールとともに、セキュアブートモジュールとセキュア処理環境1114とを有する。上記のセキュアモードインターフェース1106は、セキュアブートの信頼性の境界1104であって、そのライン以下全てが、信頼性のある環境内となる。そのラインは、「TCG Mobile Trusted Module Specification」で定義されたように、検証および拡張を行うセキュアブートプロセス中に構築される。セキュアモードの抽象化レイヤAPI1108は、サービスに対する、通常モードからの要求を取り扱い、更なる処理のために、抽象化レイヤ1110にこれらの要求をわたす。抽象化レイヤのタスクの1つはPSCデータベース1112を管理することである。また、別のタスクとしては、物理的PCRs1116の操作など、セキュア処理環境1114へのアクセスを含む、セキュアブートコンポーネント1113が提供するサービスの要求を取り扱うことがある。また、セキュアブートコンポーネント1113も、PSCデータベース1112へのアクセスを要求する。セキュア処理環境1114は、ハードウェアまたはソフトウェアのいずれで実現されてもよいが、好ましい実装では、「Trusted Computing Group specifications」で定義されたようなモバイルトラステッドモジュールであり、別の好ましい実装では、トラステッドプラットフォームモジュールである。ソフトウェア処理環境1113は、ハードウェアまたはソフトウェアのいずれか、あるいは双方の組み合わせで実現されてもよい。そして、セカンダリRIC(Runtime Integrity Checker)モニタ1118が存在する。このモニタのタスクには、改ざんが行われたと思われる場合に、アプリケーション1100を終了させることが含まれる。これは、好ましい実装では、PSCに格納された基準ハッシュに対して現在のアプリケーションのハッシュを検証することによって実現される。この検証は、特定のイベントが発生した時あるいは定期的な間隔で行われてもよく、これらのRICモニタに階層があっても構わない。これらのRICモニタは、1以上の子RICモニタの完全性をチェックする各RICモニタレベルを有する。プライマリRICは図示されていないが、そのタスクは、システム全体に対するマスター検証ルートとして、例えばハイパーバイザなどの図示されたシステム外で次のことを実行することである。すなわち、プライマリRICは、1以上のコンポーネントに対する完全性チェックを一定間隔で行い、PSCに格納された基準ハッシュに対してこれらのコンポーネントハッシュを検証する。このプライマリRICモニタのコンポーネントのうち1つは、セカンダリRICを備える必要がある。「TCG Mobile Reference Architecture」では、これをPRMVA、すなわちPrimary Runtime Measurement Verification Agentと称しており、このPRMVAは、セカンダリRICモニタに相当するSRMVA、すなわちSecondary Runtime Measurement Verification Agentを有している。図示されたもの全ては装置1120に配置される。
セキュアモードは、システムプロセッサの単独実行モード、オペレーティングシステムカーネルモード、セキュリティコプロセッサ、仮想マシン、ハイパーバイザ、完全性チェックされたメモリなど、当業者にとって周知な数々の技術により実現されてもよい。各コンポーネントは、本発明の新規性を有する教示と効果を逸脱しない範囲で、1以上の記載されている技術またはその他の技術によって保護されても構わない。
当該先行技術のその他の実施形態では、セキュアモードインターフェース1106は、抽象化レイヤ1110とセキュア処理環境1114との間に配置される。当業者は、抽象化レイヤの実行に対してセキュアモードの完全な保護を必要とせず、上述したRICモニタが行う完全性保護のみを要するようなかたちで当該抽象化レイヤを実装してもよく、また、本発明を、完全性保護された環境に実装してもよいと分かるであろう。当該完全性保護は、ソフトウェアまたはハードウェア、あるいは双方の組み合わせで行われる。
図1Aに、セキュアモードのサポートはないが、「TCG Specification Architecture Overview Revision 1.2 28 April 2004」に記載された手段などの独立したセキュア処理環境を有し、セキュアモードインターフェースが存在しない場合における先行技術のその他の実施形態を示す。セキュアモードインターフェースがないため、抽象化レイヤAPI1108は1つしか存在せず、セキュアブートコンポーネントの代わりに、トラステッド/セキュアブートコンポーネント1152が存在する。セカンダリRICモニタ1118は、セキュア処理環境1114以外のシステムにおける全てのコンポーネントをカバーできるように拡張され、このようにトラステッド/セキュアブートの信頼性の境界1150を確立する補助を行う。しかしながら、そうでない場合には、コンポーネントとそれらの役割は図1で説明した通りである。
図2に、図1の先行技術に基づいた本発明を示す。すでに述べたように、標準実行環境における抽象化レイヤAPI1102を使用するアプリケーション1100が存在する。破線は、上方の前述の標準実行モードと、下方のセキュアモードとの間のセキュアモードインターフェース1106を示す。上記のセキュアモードインターフェース1106は、先に述べたような実行前にコンポーネントを検証するプロセスによって構築されたセキュアブートの信頼性の境界1104であって、そのライン以下全てが信頼性のある環境内となる。OSサポート1200モジュールは、標準実行空間にあるが、信頼性のある境界内である。このモジュールは、どのアプリケーションが、起動前の検証にどの証明書を用いたかを示すマッピングを維持するためのコンポーネント・PSCマップ1202を管理する。セキュアモード内に、サービスに対する、通常モードからの要求を取り扱い、更なる処理のために抽象化レイヤ1110に、これらの要求をわたす抽象化レイヤAPI1108がある。抽象化レイヤのタスクの1つは、PSCデータベース1112を管理することであり、また別のタスクには、tPCRサポート1204を実装することがある。このサポートモジュールが、拡張されたけれども取り消されていないPSC全ての有向非巡回グラフを含む拡張PSCツリー1206データを維持する。さらに別のタスクは、物理的PCRs1116の操作など、セキュア処理環境1114へのアクセスを含む、セキュアブートコンポーネント1113が提供するサービスの要求を取り扱うことである。また、セキュアブートコンポーネント1113も、PSCデータベース1112へのアクセスを要求する。そして、セカンダリRIC(Runtime Integrity Checker)モニタ1118が存在し、そのタスクには、改ざんが行われたと思われる場合にアプリケーション1100を終了させることが含まれる。図示されたもの全ては装置1120に配置される。
先行技術と同様に、先行技術の好ましい実施形態では、セキュアモードインターフェース1106は、抽象化レイヤ1110とセキュア処理環境1114との間に配置される。当業者は、抽象化レイヤの実行に対してセキュアモードの完全な保護を必要とせず、上述したRICモニタが行う完全性保護のみを要するようなかたちで当該抽象化レイヤを実装してもよく、また、本発明を、完全性保護された環境に実装してもよいと分かるであろう。当該完全性保護は、ソフトウェアまたはハードウェア、あるいは双方の組み合わせで行われる。
セキュアモードは、システムプロセッサの単独実行モード、オペレーティングシステムカーネルモード、セキュリティコプロセッサ、仮想マシン、ハイパーバイザ、完全性チェック済みメモリなど、当業者にとって周知な数々の技術により実現されてもよい。各コンポーネントは、本発明の新規性を有する教示と効果を逸脱しない範囲で、1以上の記載されている技術またはその他の技術によって保護されても構わない。
また、当業者は、tPCRサポート1204と拡張PSCツリー1206とを、セキュア処理環境1114に移動させたものが、その他の実施形態であると分かるであろう。さらなる実施形態は、抽象化レイヤ1110が、セキュアモードインターフェース1106の外側になって、tPCRサポート1204と拡張PSCツリー1206が、セキュア処理環境1114の内側になるように、これらの他の実施形態を組み合わせたものである。
図2Aに、セキュアモードのサポートはないが、「TCG Specification Architecture Overview Revision 1.2 28 April 2004」に記載された手段などの独立したセキュア処理環境を有し、セキュアモードインターフェースが存在しない場合における、図1Aに基づく本発明のその他の実施形態を示す。セキュアモードインターフェースがないため、抽象化レイヤAPI1108は1つしか存在せず、セキュアブートコンポーネントの代わりに、トラスティッド/セキュアブートコンポーネント1152が存在する。セカンダリRICモニタ1118は、セキュア処理環境1114以外のシステム内における全てのコンポーネントをカバーできるように拡張され、このようにして、トラステッド/セキュアブートの信頼性の境界1150を確立する補助を行う。しかしながら、そうでない場合には、コンポーネントとそれらの役割は、図2で説明した通りである。
図3に、本発明にかかるPCRの2タイプの利用パターンを示す。まず、通常アプリケーション空間におけるアプリケーション階層を示す。第1マッシュアップ1300は、第1プラグイン1302と第2プラグイン1304とから、サービスを利用する。これらのプラグインは、第1アプリケーション1306と第2アプリケーション1308とがそれぞれ所有するものである。どちらのアプリケーションも、抽象化レイヤAPI1102からサービスを利用する。次に、セキュアモードインターフェース1106の反対側に、抽象化レイヤAPI1108のセキュアモードのサポートが存在する。これは、抽象化レイヤ1110とやり取りする。抽象化レイヤのタスクの1つは、tPCRサポート1204を実装することである。このサポートモジュールにより、拡張され、かつ、取り消されていないPSC全ての有向非巡回グラフを含む拡張PSCツリー1206データが維持される。また別のタスクは、物理的PCR1116を操作する要求をセキュア処理環境1114に渡すことなどである。これは、ハードウェアまたはソフトウェアのいずれで実現されても構わない。
ところで、物理的PCR1116と一時的PCR1204を利用する典型的なパターンは以下の通りである。物理的PCRの読み取り1310動作は、随時有効である。セキュア処理環境1114でサポートされる全ての関数は、必ず物理的PCRを使用し、決して、一時的PCRを使用しない。しかしながら、もし、上述したように、tPCRサポートコンポーネント1204を、セキュア処理環境1114内に移動したならば、SPEがtPCRを使用することも可能である。物理的PCRへの書き込み1314は、先行技術で教示されたように、主にブート時に行われるが、さらに、アプリケーション空間から物理的PCRの書き込みが可能である1312。どの書き込み動作をアプリケーション空間から行うかを決定するのはシステム設計者または実装者次第である。一時的PCRに対し、読み取り1316と書き込み1318の双方は、アプリケーション空間において、排他的に行われるのが一般的である。一時的PCRの性質により、各実装者にはこれらのtPCRをどのように使用するか選択の自由度がある。しかしながら、図例のような場合には、第1マッシュアップ1300の開発者は、第1プラグイン1302と第2プラグイン1304の開発者達と調整して、どのtPCRをそれぞれ利用する予定か全員が把握できていると確認する必要があるであろう。
図3Aに、拡張PSCツリー1206を示す。ノードの追加および削除方法については、後で述べる。図示された有向非巡回グラフは、図2に示したように拡張されているとしてtPCRサポートモジュール1204が記録したPSCを表している。図2に示されたモジュールとこの図の証明書との間には1対2の関係があり、信頼性の境界を拡張して、第1アプリケーション1306をカバーするには、先行技術で教示されているように、2つの証明書、つまり第1アプリケーション開始1350および第1アプリケーションロード1354が必要である。第2アプリケーション1308に対しては、第2アプリケーション開始1352および第2アプリケーションロード1356が必要である。第1プラグイン1302に対しては、第1プラグイン開始1358および第1プラグインロード1362、第2プラグイン1304に対しては、第2プラグイン開始1360および第2プラグインロード1364、第1マッシュアップ1300に対しては、第1マッシュアップ開始1366および第1マッシュアップロード1368が必要である。証明書間の矢印は、これらの証明書の従属関係を示している。従属関係は、各証明書の拡張時に各証明書が検出を期待するPCR状態により定義される。ツリーの各ノードの構造体は、図6において後ほど定義する。
図示したように、先行技術によると、各モジュールにはそのモジュールに関連付けられた2つの証明書があり、1つは、起動前にモジュールを検証するためにその親が使用し、もう1つは、期待された環境でモジュールが起動されたことを検証するためにモジュール自身が使用する。当業者は、モジュールごとに2つ以外の証明書を使用しても、本発明の範囲内であると分かるであろう。
図4に、プラットフォーム状態証明書1400(PSC)を示す。これは、そのプラットフォーム状態証明書が定める(物理的または一時的な)PCRで定義されるプラットフォームの状態と、プラットフォームの状態の検証がうまくいった時に、(物理的または一時的な)PCRへ拡張する値とを表す構造体である。これらの構造体を、PSCデータベース1112に格納してもよい。本構造体の第1フィールドは、PSC名1402である。この名前は、PSCデータベース1112へのPSCの格納、および、PSCデータベース1112からのPSCの取り出しに用いられるキーフィールドなので、固有でなければならない。また、好ましい実装では、この名前は、人間が読み取り可能な名前を表すバイト文字列である。アプリケーション開発者が使用する名前を決定してもよい。あるいは、プラットフォームの製造者が、アプリケーション開発者に名前を提供してもよい。当業者は、GUIDなどの他の表示を代わりに用いてもよく、PSC名を選択する方法は、他にもあると分かるであろう。次に、検証用PCR状態1404を表すエントリーリストが存在する。検証対象のPCRごとに、一対の値、つまりPCRインデックス1406およびPCR値1408が存在する。次に、拡張用PCR値が存在する。最初に拡張用PCRインデックス1410そして拡張用値1412である。最後に、セキュア処理環境1114の知る鍵により暗号化されたデータの残りのハッシュを表す暗号署名1414が存在する。この署名鍵は、セキュア処理環境1114へ安全に組み込まれたキーのプライベート部分か、署名PSCに使用するものであるとして上記の組み込まれたキーが直接または間接的に承認したキーのいずれかである。また、署名者は、プラットフォーム開発者またはアプリケーション開発者のエージェント、あるいは有効な署名鍵を発行した他の者でも構わない。
本発明によると、プラットフォーム状態証明書1400を単に確認するだけでは、物理的PCRなのか一時的PCRなのか判断することはできない。どの種類のPCRをチェックすべきか決定するのは、それを用いる状況である。この利点の1つは、セキュアブート用に証明書を作成する既存のツールを、アプリケーション空間用に証明書を作成するために再利用できることである。
好ましい実施形態では、検証用PCR状態1404の対リストを、テスト対象であるPCRインデックス1406を表すビットマップとPCR値1408の集合に対するハッシュとで置き換えてもよい。これは、RIM証明書に対して「TCG Mobile Trusted Module Specification」が定義した表示である。より複雑なチェックコードを費やせば、一時的なPCRを検証する証明書を変更することなく、このような表示を用いることが可能である。しかし、好ましい実施形態では、図5に図示された一時的PCR用RIM証明書1500を用いる。この構造体と図4のプラットフォーム状態証明書とのフィールドの関係および追加フィールドについて詳しく述べる。
ラベル1502は、PCS名1402に相当する。measurementPCRIndex 1504と、measurementValue 1506とは、拡張用PCRインデックス1410と、拡張用値1412とに相当する。検証用tPCR状態1518、およびPCRインデックス1514とtPCR値1516とを含む対リストは、プラットフォーム状態証明書1400で定義されたフィールドと類似のものである。検証用tPCR状態1518を一時的PCR用RIM証明書1500に関連付けるためには、extensionDigestSize 1508とextensionDigest 1510のフィールドを使用することが必要である。extensionDigestSize 1508は、extensionDigest 1510のバイトサイズであり、extensionDigest 1510には検証用tPCR状態1518の構造体のハッシュが含まれる。state 1512フィールドに設定されたビット数は、テーブルのペア数を示すので、サイズインジケータを格納する必要はない。当業者は、tPCRインデックス系列など、tPCR値1516フィールドに所定順序がある場合には、tPCRインデックス1514フィールドを格納する必要さえないと分かるであろう。
図6に、拡張PSCツリーノード1600を示す。これは、証明書1つの拡張を記録する構造体である。このノードの構造体では、図3Aに図示したような各ノードの内容、つまり項目1350〜1368を詳しく説明している。拡張PSCツリー1206は、当該技術分野において周知の技術を用いて有向非巡回グラフを実装する。例えば、ブーストC++ライブラリには、ブーストグラフライブラリが含まれている。これは、上述した有向非巡回グラフなど様々なグラフの作成および操作をサポートする。このように、拡張PSCツリーノード1600は、グラフの各頂点に関連付けられる。拡張PSC名1602は、拡張されたプラットフォーム状態証明書1400のPSC名1402のフィールドである。tPCR状態1604は、このノードにおける現在の一時的PCR状態のキャッシュであり、このノードの先祖に当たる拡張済みのPSCから算出される。tPCR状態は、tPCRインデックス1606とtPCR値1608との対リストで構成される。当業者は、このデータの別の表現、例えば、用いたtPCRを表すビットマップでtPCRインデックス1606フィールドを置き換えるなどが存在すると分かるであろう。
図7に、OSサポートモジュール1200によって維持されたコンポーネント・PSCマップ1202を示す。このコンポーネント・PSCのマップ1202には、コンポーネントをPSCへマッピングするリスト1700が含まれる。このリストの各エントリーには、コンポーネントID1702と、拡張PSC名1704、つまりアプリケーションの起動前に拡張されたプラットフォーム状態証明書1400のPSC名1402フィールドとが含まれる。Windows(登録商標)ベースのプラットフォームにおける本発明の好ましい実施形態では、コンポーネントID1702は2つのフィールドから構成されている。第1フィールドは、プロセスID1706である。このプロセスIDは、GetCurrentProcessId()などのWin32APIによって決定されるような、コンポーネントが属するプロセスを一意的に表す識別子をもつ。第2フィールドはモジュールハンドル1708である。単独で実行可能なコンポーネントに対しては、このフィールドを必ず0に設定する。リンクライブラリとして実装されたコンポーネントに対しては、第1パラメータのDllMainエントリーポイントに渡されるように、ライブラリ用のHMODULEがこのフィールドに含まれる。この構造体の利用法については後で述べる。
「TCG Mobile Reference Architecture」によると、PCR0は、基礎を成すハードウェアプラットフォームの特徴を表す値を保持する。PCR1は、信頼性のルートを表す値を含む。PCR2は、エンジンロードイベントを表す値を含む。PCR3〜6および8〜12は、専有手段を含む。PCR13〜15はアプリケーションが自由に使用できる。セキュアブートが正しく行われたことをPCR0、1および2が期待通りに示すかどうかのテスト、PCR13が0に設定されたかどうかのテスト、そして、全てが正しければ新たな値をPCR13に拡張することをアプリケーションプログラマが希望したとする。図8に、先行技術にかかる、「第1アプリケーション開始」と名付けられたプラットフォーム状態証明書1400のサンプルを示す。証明書の名前は1800に記録される。上述したように、検証用PCR状態1404は、チェックするPCRインデックスとPCR値との対を4つ含み、1802、1804、1806、1808、1810、1812、1814、1816と番号付けする。1802はPCR0を示し、1804の<ハードウェアプラットフォーム>は、基礎を成すハードウェアプラットフォームを表す公表値を示す。1806はPCR1を示し、1808の<信頼性のルート>は、基礎を成す信頼性のルートを表す公表値を示す。1810はPCR2を示し、1812の<エンジンロードイベント>は、PCR2に拡張されたロードイベント値から算出された合成ハッシュを表す公表値を示す。1814はPCR13を示し、1816の0の値は、PCR13がまだ初期状態であるという予測を示す。次に、1818へ拡張するPCRが存在し、そして、そのPCRへ拡張する値1820 が存在する。
先行技術にかかる図8の証明書に関する問題として次のものがある。他のアプリケーションがPCR13を使用してしまった場合、検証用PCR状態1404はもはや正確ではなくなってしまうという問題がある。アプリケーションが終了して再起動する場合、1818と1820に定義した先に拡張された値によってPCR13は0以外の状態に設定されてしまい、検証用PCR状態1404はもはや正確ではなくなってしまうという問題がある。
しかしながら、本発明では、図8の証明書と類似の証明書は、アプリケーション自身と同じ時間または別々の時間で対象装置に展開するためにアプリケーション開発者によって、図9に示すような2つの証明書に分けられる。なぜ分けるかというと、既存の証明書により2つの異なるPCRセットを検証するためである。第1のセットにはセキュアブートプロセスの結果、つまり既知の不変な結果が含まれ、第2のセットには動的状態、つまりアプリケーションレベルの状態が含まれる。図8において、項目1802および1804は、ハードウェアプラットフォームを表す既知のセキュアブートPCR0の値を指している。項目1806および1808は、信頼性のルートを表す既知のセキュアブートPCR1の値を指し、項目1810および1812は、エンジンロードイベントを表す既知のセキュアブートPCR2の値を指している。また、項目1814および1816は、期待される前提条件を表す、ブート後のPCR13の望ましい値を指している。このように、アプリケーション開発者は、セキュア処理環境が管理する物理的PCR、すなわち本例ではPCR0、1および2をテストするために用いられる片方の証明書に既知のセキュアブートPCRの値を置くことによって、図8の単一証明書を図9に示した2つの証明書に分けてもよい。第2の証明書は、アプリケーション空間の一時的PCR、すなわち本例ではPCR13用に用いられる。
「第1アプリケーション開始(セキュアブート)」1900と名付けられた第1証明書によって、セキュア環境が正しいことを確保するため、セキュアブートプロセスがセットアップした物理的PCR(PCR0 1802、PCR1 1806およびPCR2 1810)はテストされる。ここで、拡張用PCRは、拡張がないことを示すために-1 1902に設定され、拡張用値1904はゼロという名目上の値である。この証明書は検証のみに使われる。そして、アプリケーションレベルでは、図3に示すように物理的PCRへの書き込みをやめ、一時的PCRを用いることによってより柔軟性が高まり、前述した当該技術分野における課題を回避することができる。「第1アプリケーション開始(一時的)」1920と名付けられた第2証明書によって、ゼロ 1816である一時的PCR13 1814はテストされ、同じレジスタ1818および1820に値を拡張する。tPCRのインデックス13を選択したことに特に意味はない。先行技術の状況とは異なり、tPCR0またはtPCR99が用いられやすいであろう。
図10に、シーケンス図を示す。この図では、アプリケーション起動時には図9の2つの証明書、つまり一方が物理的PCRをテストする証明書であり、もう一方が、一時的PCRをテストする証明書を用い、アプリケーション終了時には、「第1アプリケーション開始(一時的)」1920の第2証明書を用いて、値をtPCRに拡張してからその拡張を取り消すという本発明にかかるイベントシーケンスを示す。相互に作用する6つのオブジェクト、11000、11002、11004、11006、11008および11010を図示している。まず、tPCR13 11000は、この例の状況における一時的PCR13の状態を表す。図6で説明したように、tPCRは、特定のメモリ位置というよりむしろ拡張PSCツリー1206のノードごとに記録されるが、本例においては理解しやすいよう、tPCR13 11000をそのような位置にあるかのごとく表す。次に、tPCRサポート11002が存在する。これは、tPCRを参照するPSCの取得と現在のtPCR状態の検証との処理を行い、有効であれば、証明書は拡張されたと記録する。SPE11004は、先行技術にかかるセキュア処理環境である。好ましい実施形態では、それはMTMである。抽象化レイヤ11006は、通常モードのアプリケーションからの要求を取り扱い、要求を他のモジュールにわたす。OS11008はオペレーティングシステムであり、ここでは、一時的PCRを正確にアップデートするようなアプリケーションの起動および終了の処理に関するシステムである。そして、アプリケーション11010は、任意のタスクを行うサンプルアプリケーションである。図10のシーケンス図のプロセスは入れ子されてもよいので、アプリケーション11010は、例えば、アプリケーション実行11042が11014から始まるイベントシーケンスに従う別のアプリケーションの開始を含むような、PSCによって保護された他のアプリケーションの開始を要求するなどのアプリケーションであっても構わない。図を単純化するため、エラー処理については図示しないが、本発明から除外されるものではない。
まず最初に、tPCR13 11000は、0の値11012で始まる。本発明では、拡張PSCツリー1206のルートは、全tPCRを0に設定させた状態で始まるというのがルールである。当業者であれば、セキュアブートの完了後に物理的PCRの値でtPCRを初期化するというような他の初期値候補が可能だと分かるであろう。OS11008は、要求を検出してアプリケーション11010を起動するので、まず、起動しようとするアプリケーションによってどのPSCが用いられるのかを決定する11014。Windowsベースのオペレーティングシステムにおける好ましい実施形態では、実行ファイルに組み込まれたカスタムアセンブリが、使用する2つのPSCを特定する。そのアプリケーションは、改ざんから保護するためにマイクロソフトのストロングネームツールを用いて署名される。次に、11014で特定されたPSC、この図では「第1アプリケーション開始(セキュアブート)」および「第1アプリケーション開始(一時的)」を抽象化レイヤ11006に要求する11016、11018。そして、これら2つのPSCの検証が、抽象化レイヤAPIであるAL_VerifyPSCsAndExtendtPCRを呼び出す11020ことによって行われる。このAPIは、システムが開始したいアプリケーションを検証する2つのPSC、つまり、図9で示したような物理的PCR用のPSCおよび一時的PCR用のPSCを引数とする。まず、図の11024で表されたPSC「第1アプリケーション開始(セキュアブート)」を引数とした、SPEのAPIであるSPE_VerifyPSCStateを呼び出す11022。先行技術によれば、これによって、PSC自身のフォーマットおよび署名のチェックが行われ、そして、PSCの検証用PCRが物理的PCRの現在の値と一致することを検証する。先行技術によれば、PSCがプラットフォームに渡されると、セキュア処理環境1114に組み込まれたキーか、この組み込まれたキーによって正当であると検証されることのできるキーのいずれかでPSCは署名される。そして、有効であれば、セキュア処理環境1114が生成かつ安全に格納した他のキーで再び署名され、証明書はPSCデータベース1112に格納される。
本発明の好ましい実施形態によると、物理的PCRをチェックするPSCはオプショナルなので、ステップ11016および11018を省略してもよい。その他の好ましい実施形態によると、物理的PCRのチェック用のPSCがアプリケーション全てについて同じである場合、物理的PCR用のPSC1つを2つ以上の異なる一時的PCRのPSCが用いてもよい。
次に、SPEの他のAPI、すなわち、図の11030で表されたPSC「第1アプリケーション開始(一時的)」にパラメータを設定したSPE_VerifyPSCを呼び出す11026。先行技術によると、これによって、物理的レジスタに対してPCRの設定を検証せずとも、PSC自身のフォーマットおよび署名のチェックが行われる。そこで、tPCRサポートモジュール、すなわち、図の11030で表されたPSC「第1アプリケーション開始(一時的)」にパラメータを設定したAPIであるTPCR_VerifyPSCAndExtendを呼び出す11028。このAPIの最初のタスクは、拡張PSCツリー1206内の既存状態に対応する検証用PCR状態1404をチェックすることにより、PSCを拡張できることを検証する11032ことである。この動作の詳細については後で述べる。検証が正常に完了した時点で、このPSCにおける動作の成功が、拡張PSCツリーの正しい位置へその表示を付け加える11034ことによって記録される。この動作の詳細については後に述べる。このPSCをツリーへ付け加えたことによる結果の1つは、tPCR13 11000、つまり拡張対象のレジスタが、以前の値、この場合は0、とPCRから拡張するための値1030、つまり0xABCD1234とを連結したもののハッシュに設定されたレジスタの値を有することである。これは、合成ハッシュと呼ばれ、数式的には、tPCR13 = SHA-1(0xABCD1234と連結されたtPCR13)と書き込まれる。この動作は11036の構文 (+)=で表される。このように、環境が期待された状態であることを検証し、成功したことの記録が生成され、そして、制御がオペレーティングシステムに戻る。先行技術によると、11020におけるPSC検証の前の、更なる安全性の評価として、アプリケーションのハッシュを算出し、拡張するPSCに格納された基準値と比較する。本発明では、この値は、好ましい実施形態において0xABCD1234と表された、拡張用の値として、PSC「第1アプリケーション開始(一時的)」11030に格納される。しかしながら、このステップは図から省略されている。
アプリケーションを起動する際に、OSは、そのアプリケーションのプロセスIDを取得し、コンポーネント・PSCマップ1202に、この識別子と一時的レジスタ用の対応PSC、つまりPSC「第1アプリケーション開始(一時的)」とを記録する11038。マイクロソフトのWindows環境における好ましい実施形態では、本プロセスは、http://www.codeproject.com/KB/system/InterceptWinAPICalls.aspxのコードプロジェクトにおけるAndriy OriekhovのIntercepting WinAPI callsに記載されたようなプロセス作成プロセスを途中でインターセプトすることによって実装される。取得したプロセスハンドルは、プロセスID1706に変換され、そのフィールドに設定される。そして、モジュールハンドル1708を0に設定する。コンポーネントがダイナミックリンクライブラリである場合、http://www.lenholgate.com/archives/000369.htmlの/* Rambling comments... */におけるLen HolgateAPIのWhy does windows hold the loader lock whilst calling DllMain?に記載されたように、LoadLibrary()およびFreeLibrary()コードをフックし、DllMain()への呼び出しをトラップする。このトラップを設けたまま、プロセスID1706を現在のプロセスIDに設定し、モジュールハンドル1708をDllMain()の第1引数に設定する。
アプリケーションは起動されると11040、PSCに関連付けられた他のアプリケーションを起動またはtPCR自体を参照する他のPSCを拡張したとしても、プログラムされたように実行し続ける11042。そして、アプリケーションを閉じるとユーザが選択する、クラッシュする、または、アプリケーションを強制的にシャットダウンするセカンダリRICモニタ(この図では図示していない)が改ざんを検出するといういずれかの原因で、アプリケーションは終了する11044。
アプリケーションが終了するので、OSはアプリケーションのプロセスIDを取得し、そのプロセスIDと0であるモジュールハンドルとを用いて、コンポーネントID1702を作成する。このコンポーネントIDを用いてコンポーネント・PSCマップ1202を検索し、アプリケーションを起動するのに用いられたPSCを見つける11046。これにより、PSC「第1アプリケーション開始(一時的)」11030が返されるので、取り消しを行うため、OSは、抽象化レイヤ11006のAPIであるAL_UndoPSCExtendを、PSCを引数として呼び出す11048。コンポーネントがダイナミックリンクライブラリである場合、上述したようにFreeLibrary() APIをフックするので、そのルーチン内で現在のプロセスIDを問い合わせ、FreeLibrary()のパラメータからモジュールハンドルを取得し、そしてこれら2つのデータ項目を用いて、コンポーネントID1702を作成する。このコンポーネントIDを用いてコンポーネント・PSCマップ1202を検索し、ライブラリを起動するのに用いられたPSCを見つける。前述と同様に、SPEの他のAPI、すなわち、図の11030で表されたPSC「第1アプリケーション開始(一時的)」にパラメータを設定したSPE_VerifyPSCを呼び出す11026。先行技術によると、これによって、物理的レジスタに対してPCRの設定を検証せずとも、PSC自身のフォーマットおよび署名のチェックが行われる。そこで、tPCRサポートモジュール11002、すなわち、図の11030で表されたPSC「第1アプリケーション開始(一時的)」にパラメータを設定したAPIであるTPCR_VerifyPSCAndExtendを呼び出す11050。このAPIの最初のタスクは、拡張PSCツリー1206にそのPSCがすでに存在するかどうか確認することによって、PSCが拡張されたことを検証する11052ことである。検証が正常に完了した時点で、これは、11028における拡張動作を取り消すことが可能であることを意味する。これは、拡張PSCツリー11034から、PSCを表すノードおよびそれに従属する他のノード全てを削除することによって実現される。この動作の詳細は後で述べる。ツリーからこのPSCを削除することの結果の1つは、tPCR13 11000、つまり取り消す対象のレジスタが効率よくその状態を0にリセットされる11056ことである。このように、環境が期待した状態であることを検証し、拡張PSCツリーからノードを削除する11034ことによって先に拡張された動作を取り消し、制御がオペレーティングシステムに戻り、本システムは他の動作をすぐに実行することができる。当業者であれば、これらの他の実行動作の1つとして、終了したアプリケーションを再起動することもあると分かるであろう。tPCR13が11056において00…00、つまり11012で示されたtPCR用の開始値にリセットされた後は、アプリケーションの開始PSC11030の検証は2回目も正常に再実行されるので、本発明によると、アプリケーションを再起動することができる。
図10に、実行ファイルの起動および終了時に信頼性の境界を動的に拡張かつ縮小するシーケンス図を示す。注釈を用いて、好ましい実施形態に沿ったダイナミックリンクライブラリに対する同様のタスクをWindows Portable Executable形式のモジュールでどのように行うかを示す。Java ArchiveモジュールやJARなどのPortable Executableベースでないモジュール形式に対しては、モジュールをロードかつアンロードするエンジンによって同様の手法が用いられるか、代わりに、モジュール自身によって抽象化レイヤ11006への明示的な呼び出しが行われるかして、信頼性の境界を拡張かつ縮小してもよいと当業者は分かるであろう。先行技術によると、JARは、Javaバイトコードベースのモジュールだけでなく、例えばECMAスクリプト(Javaスクリプト)など、その他の言語モジュールを含んでもよい。これらを、http://java.sun.com/j2se/1.3/docs/tooldocs/win32/jarsigner.htmlのSunからjarsignerツールを用いて署名し、その署名を、http://java.sun.com/j2se/1.4.2/docs/api/java/util/jar/JarFile.htmlに記載されたようなjava.util.jar.JarFileクラスを用いて検証してもよい。この場合、好ましい実施形態において、図7に示されたモジュールハンドル1708は、コンポーネントを含むJARファイルを参照するハンドルである。
図11に、tPCRサポートモジュール11002のAPI、TPCR_VerifyPSCAndExtend 11028の詳細に関するフローチャートを示す。本関数は、検証および記録するためのPSCをパラメータとしてわたして11100で開始し、次の図12で示す、拡張PSCツリーの各ノードに対してtPCR状態を算出する11102サブルーチンを呼び出す。次に、現在のtPCR状態とソリューションリストの変数とを、NULLに初期化する11104。これら2つの変数の利用法については図13で説明する。そして、渡されたPSCのtPCR値に、現在の拡張PSCツリーに記述された状態から達することができることを検証するサブルーチンが呼び出される11106。戻りコードをテストすることで、本関数が、拡張PSCツリー内で、渡されたPSCが保持する検証用の状態にtPCRを設定したノードを1以上見つけたかどうか分かる11108。この設定された親が見つからなかった場合、プロセスは、呼び出しルーチンへ拡張できなかったことを示すエラーコードを返す11110。見つかった場合は、渡されたPSCを、ソリューションリストに記述されたノードに設定した先のPSCを有する拡張PSCツリーに付け加え11112、プロセスは、呼び出しルーチンにサクセスコードを返す11114。
図12に、図6における拡張PSCツリーの各ノードのtPCR状態1604をどのように算出するか説明するフローチャートを示す。当該フローチャートは引数なしに呼び出され11200、行きがけ順に拡張PSCツリーの走査を行う11202ことで処理が開始する。この走査は、ツリーのノードを続く処理にとって望ましい順序で収集するためにルートから始まる。好ましい実装では、ブーストグラフライブラリ関数breadth_first_search()を用いてこれらのノードを収集する。次に、記録されている各ノード11204に対し、深さ優先走査によって現在のtPCR状態1604をNULLに設定する11206。セキュアブート完了の際に定義されたtPCRの開始値、好ましい実施形態では0の値、に初期化されたtPCRを検証する証明書の特別処理が必要なので、現在の証明書に格納された検証用PCR状態1404のtPCR対ごとに、その値をセキュアブート完了の際に定義されたtPCR初期値、好ましい実施形態では0の値と照合する11210。それらが等しい場合は、tPCRのインデックスおよび値の対をこのノードのtPCR状態に付け加え11212、次のtPCRに対してループを続ける。そうでない場合は、ノードのtPCR状態を付け加えずにループを続ける。各tPCRをチェックすると、本関数は、現在のノードの親それぞれに対するループへと移行する11214。親ノードが拡張PSCツリーのルートノードであれば11216、前回のループがこの特殊ケースを処理したため、何も行われない。そうでない場合には、親ノードのtPCR状態1604を問い合わせ、コピーする11218。親の拡張PSC名1602により参照されるPSCによって定義された拡張動作が親の状態のコピー11220において行われ、その結果のtPCR状態が現在のノードのtPCR状態に付加される11222。この拡張PSCツリー構築方法により、2つの親が同じtPCRに対して異なる値を指定する事態は決しておこらない。そのため、当業者は、この状況をチェックする必要はないが、検証目的で実装してもよいと分かるであろう。tPCR状態の収集は、前述したように、全ての親に対して繰り返され、終了すれば、走査中の次のノード11204が処理される。このように各ノードが処理されると、各ノードのtPCR状態を返してプロセスは終了する11224。
当業者は、例えばbfs_visitor’s examine_vertex()でステップ11204から11222を実行するなど、上記アルゴリズムを実行する別の方法が存在するので、ノードの別々のリストの必要性はなくなると分かるであろう。さらに、この関数は、PSC関連の動作が行われるたびに呼び出されるが、その値をキャッシュして再計算にかかる労力を削減してもよい。
図13に、ノードごとのtPCR状態が算出された後、あるPSCに定義された状態へtPCRを設定する拡張済みのPSC全てのリストを見つけることによって、どのようにしてそのPSCを検証するか説明するフローチャートを示す。この図で説明するルーチンは、再帰的なルーチンであることに注意されたい。このルーチンへのエントリーポイントは、引数として、リスト形式の検証用tPCR状態と、現在のtPCRの一致の状況と、tPCR状態によってPSCの親だと判明した拡張PSCツリーのノードのリストとをとる11300。ソリューション方法の概要は、tPCRのインデックスおよび値の対ごとに、望ましい値を現在のtPCRに拡張する証明書であり、かつ、このソリューションの一部である別のtPCRに拡張する他の証明書と互換性をもつ証明書を見つけようと試みることである。候補が見つかれば、ルーチンを再帰的に呼び出して、PSCの一部である別のtPCRを一致の状態へ拡張する他の証明書を見つける。
最初のステップは、一致するtPCRのリストをチェックすることである。これが空である場合11302、ルーチンはリストの最後に正常に再帰されたので、呼び出し側に成功を示すためFOUND値を返す11304。そうでない場合は、tPCRリストの先頭を削除し、これを現在のtPCRとして用いて親の証明書を見つけようと試みる11306。ソリューションリストにまだ割り当てられていない拡張PSCツリーの各ノードを親になる候補として選択する11308。先行技術に従ってこれらのノードをどのように取得できるかは図12の説明で示した。まず、2つの構造体において一致するtPCRインデックスが同じtPCR値であることを検証することによって、このノードのtPCR状態を、渡された現在の一致tPCR状態と互換性があるかどうかチェックする11312。値が一致しなければ11316、ルーチンは、拡張PSCツリーの次のノードへ移行する11308。一致する場合には、ノードに格納された拡張PSC名1602を用いて検証用ノードのPSCを検索し11314、拡張用PSCのインデックス1410を11306で取り出した現在のtPCRのインデックスと比較する。インデックスが一致しない場合11316、ルーチンは、拡張PSCツリーの次のノードへ移行する11308。インデックスが一致する場合は、親ノード候補が見つかったので、このノードをソリューションリストに付け加え11318、このノードの状態を拡張して現在のtPCRリストにマージする。tPCR検証ルーチンを、短縮したtPCRリストと現在のtPCR状態とソリューションリストとを引数にして、再帰的に呼び出す11332。再帰的呼び出しが成功すれば11324、呼び出し側にその成功を示すためFOUND値を返す11326。失敗した場合は、現在のノードをソリューションリストから削除して11320での状態のマージを取り消し11328、そして、ツリーの次のノードを調べるためにループを続ける。全てのノードが調べられ、一致がなかった場合は、NOTFOUNDを返す11310。
図14に、取り消し前と取り消し後のサンプル拡張PSCツリー1206の状態を示す。取り消し前の状態11400は図3Aで述べたとおり、図3のモジュールツリーから構築された状態である。ところで、図10で示されたように、ユーザからの作用、プログラムバグ、または改ざん検出により第1プラグインが終了すれば、オペレーションシステムは第1プラグインの終了を検出して、「第1プラグイン開始」証明書1358は起動時にテストされたPSCであったと判断するので、証明書の拡張を取り消す必要がある。「第1プラグイン開始」1358とともに、それに従属する全ての証明書、すなわち、「第1プラグインロード」1362、「第1マッシュアップ開始」1366および「第1マッシュアップロード」1368も拡張PSCツリー1206から削除しなければならない。その結果、取り消し後の状態11402の拡張PSCツリー1206となる。
図15に、拡張プロセスをどのようにして取り消すか説明するフローチャートを示す。本関数は、引数として、取り消し対象PSCをとる11500。まず、本関数は、上記の図12で示された、拡張PSCツリーのノードごとにtPCR状態を算出する11502サブルーチンを呼び出す。次に、対象PSCのPSC名1402とツリー内の各ノードの拡張PSC名1602との一致を探すことで、拡張PSCツリー内で対象PSCへの参照を検索する11504。一致するノードが見つからない場合11506、エラーコードを呼び出し側に返して取り消すことができなかったことを示す11512。次に、対象PSCの検証用PCR状態1404を見つかったノードのtPCR状態1604とを比較する。それらの状態が等しくない場合11510、エラーコードを呼び出し側に返して取り消すことができなかったことを示す11512。状態が等しい場合は、見つかったノードとそれに従属するもの全てを削除する関数を呼び出し、その関数がサクセスコードを呼び出し側に返す11516。
図16に、取り消し処理が拡張PSCツリーからどのようにしてノードを削除するか説明するフローチャートを示す。本関数は、引数として、ツリーから削除するノードをとる11600。まず、このノードの子PSC全てに対してループし11602、再帰的に自分自身を呼び出してその子それぞれを順に削除する11604。全ての子が削除された時点で、ノード自身を削除し11606、本関数はリターンする11608。このようにして、終了中のモジュールおよびそれに従属する信頼性のあるモジュール全てをカバーする、以前の拡張処理によって確立された信頼性の境界は、終了する必要のないモジュールをカバーしたまま、装置のアプリケーション空間における信頼性レベルを落とすことなく、終了するモジュールを除外するように縮小される。
図17に、アプリケーションがリモート認証する間のモジュール間通信について説明するシーケンス図を示す。相互に作用する6つのオブジェクト、11004、11002、11006、11008、11010および11700を図示している。まず、SPE11004は先行技術に係るセキュア処理環境である。好ましい実施形態では、それはMTMである。次に、tPCRサポート11002が存在する。これは、tPCRを参照するPSCを取って、任意のPSCに基づくtPCR状態を検証する処理を行い、有効であれば、証明書を拡張したことを記録する。抽象化レイヤ11006は、通常モードのアプリケーションからの要求を取り扱い、要求を他のモジュールにわたす。OS11008はオペレーティングシステムであり、ここでは、一時的PCRを正確にアップデートするようなアプリケーションの起動および終了の処理に関するシステムである。アプリケーション11010は、この例における認証を含む任意のタスクを行うサンプルアプリケーションである。そして、サーバ11700はリモート認証を行う。
まず、アプリケーション11010は、抽象化レイヤ11006にクライアントノンスNc を要求し11701、このランダムに生成された値が返ってくる11702。この値は、アプリケーション11010がサーバ11700に認証を要求する場合に用いられる11703。例えば、保護されたサービスへの、アプリケーション11010によるアクセスを許可する前に、サーバ11700は、アプリケーション11010が期待された環境で動作しているか確認する必要があるため、アプリケーション11010は、サーバ11700からこの許可を得るため認証手順を開始する。アプリケーション11010は、生成されたクライアントノンスNc をサーバ11700に渡す。このクライアントノンスは、リプレイ攻撃やその他の攻撃に対する保護を実現するための値である。サーバ11700は、クエリ用の、サーバノンスNsとランダムに生成されたChallengeと物理的PCRセットとを含むメッセージを付けた認証要求を送信することによって応答する11704。このメッセージは、先行技術で述べられているような匿名証明プロトコルなどでクライアントとサーバとの間において先に確立されたAIKを用いて署名される。ここで、好ましい実施形態では、このメッセージフォーマットはTCGで指定されたものと同じである。アプリケーション11010は、この認証要求の処理11706をOS11008に託す。OS11008は、図10で述べたようなプロセス空間の情報を用いて、どのアプリケーションまたはダイナミックロードライブラリが関数を呼び出したのかと、モジュールがどのRIM証明書を使ってそのモジュール自身の検証を行ったのかとを判断し11708、アプリケーションのリモート認証用の、先に確立されたAIKを決定する11709。検索されたRIM証明書は、モジュールへ認証要求するために、他の認証パラメータとともに抽象化レイヤ11006へ渡される11710。ここで、認証が開始可能になる。まず、認証用の、サーバノンスとランダムChallengeと物理的PCRとを含むメッセージの署名が、先行技術に基づき先に確立されたAIKを用いてSPE11004によって検証される11712。次に、SPE11004を再び用いて、今度は、アプリケーション11010に対するRIM証明書の完全性を検証し11714、そして、tPCRサポート11002を用いて前記RIM証明書内のtPCRセットの検証を行う11716。これらのチェックが正常に行われたとすると、抽象化レイヤ11006はSPE_Quoteで用いられるハッシュ値を作成する11718。このハッシュは、先にサーバへ送信されたクライアントノンスとサーバノンスと11710で渡されたChallengeとを連結したものおよびアプリケーション11010のRIM証明書に格納されている一時的PCRハッシュから算出される。SPE11004が、サーバから受信したPCRセレクション11704に対応したPCRセットと、11718で算出されたハッシュ値とを含み、確立されたAIKのプライベート部分を用いて署名された署名済みハッシュの生成を要求される11722。SPE11004がMTMである好ましい実施形態において、SPE_QuoteはTPM_Quoteのエイリアスであり、TCG仕様書で定義されたように動作する。この得られた署名値は、SPE11004からサーバ11700へ、11722、11724、11726そして11728と遡って渡される。サーバ11700は、渡された結果が期待される結果と等しいかどうかを検証し11730、等しければ、アプリケーション11010に認証が正常に完了したことを通知する11732。
好ましい実施形態では、アプリケーション11010およびサーバ11700間の通信(11703、11704、11728、11730および11732)は、インターネットを介したワイヤレスリンクで行われるが、固定リンクや無線リンクを用いる実施形態でも可能であると当業者は分かるであろう。この通信のプロトコルは、メッセージコンテンツを暗号化する必要がないように設計されているが、SSLなどの暗号化プロトコルを用いる実施形態でも可能であると当業者は分かるであろう。
本発明は上記の実施形態に基づいて述べられているが、本発明は明らかにそのような実施形態に限定されるものではない。下記のケースもまた本発明に含まれる。
(1)上述の実施形態では、MTM仕様書と同様の方法で検証は行われた。しかしながら、本発明を他の検証システムに適用してもよい。ただし、コンポーネントをチェーンのように検証する検証方法で検証システムがシステムのコンポーネントを検証できる場合(例えば、あるコンポーネントがそのコンポーネントの後に起動する他のコンポーネントを検証する)に限る。例えば、ハッシュ値のMTMへの拡張などの動作はTCG仕様書に固有なものであるため、省略してもよい。
(2)上述の実施形態では、証明書(RIM証明書)内でハッシュ値を使用することにより検証は行われた。しかしながら、ハッシュ値を使用しない他の検証方法が本発明に適用されてもよい。
従来のチェックサムや、コンポーネントから抽出される別のデータ(例えば、コンポーネントから抽出される第1所定ビット)が、検証を行うために使用されてもよい。また、証明書は、完全性チェック値を含むデータの集合に置き換えられてもよい。
さらに、検証方法は、コンポーネントから抽出される値と期待される値が等しいか否かをチェックすることに限定されない。例えば、コンポーネントのサイズを確認し、もしサイズが所定量より大きいか、または小さいなら、コンポーネントは検証されたと判断されるとしてもよい。これらの検証方法は、ハッシュ値と、その期待値とを比較するほど厳密なものではないが、それよりも高速に行われる。
(3)上記の各装置は、具体的には、マイクロプロセッサ、ROM、RAM、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。RAMまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
(4)上記の各装置を構成する構成要素の一部または全部は、1個のシステムLSI(Large Scale Integration:大規模集積回路)から構成されているとしてもよい。システム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、BD(Blu-ray Disc)、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。
また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記憶しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。
また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
(7)本技術分野の当業者にとっては、説明した実施形態の、本発明固有の教示および利点から原理的に離れることのない多くの変形がありえることを容易に理解することができるだろう。また、上記変更および実施形態の任意の組み合わせは、本発明の範囲内に含まれる。
(第2の実施形態)
以下に、本発明の好ましい実施形態について説明する。
第2の実施形態は一時的なPCRの利用をサポートするシステムに関し、この一時的なPCRは、証明書によって定められた値以外の定義済み存続期間を有する。前述の追加オペレーティングシステム機能およびPSCの信頼できる検証を行うことによって、SPE付き装置の開発者はこれらのtPCRを扱うシステムを作成できる。使用対象のtPCRについて記述するPSCを提供することによって、このような装置におけるアプリケーションの開発者は、信頼できる実行を柔軟な方法で提供するアプリケーションを作成できる。本発明によると、アプリケーションはいずれかのコンポーネントタイプとして定義されるが、独立型のプログラムや独立型のプログラム用プラグインモジュールやプラグイン用ヘルパーモジュールに限定されるものではない。
図21Aに、「TCG Mobile Reference Architecture」に記載された手段などのシステムのセキュアブートをサポートする場合における先行技術を示す。標準実行環境において、抽象化レイヤAPI2102を使用するアプリケーション2100が存在する。破線は、上方の前述した標準実行モードと下方のセキュアモードとの間のセキュアモードインターフェース2106を示す。標準実行モードとは、ほとんどのコンピュータシステムが提供するような通常の実行環境である。セキュアモードでは、標準実行環境からはアクセスできないメモリ空間において、許可されたソフトウェアに限り実行可能なセキュア実行環境を提供する。本発明の好ましい実施形態では、セキュアモードしか分からないキーのプライベート部分を有するソフトウェアを暗号化することによってこの許可が行われるが、ホワイトリストや証明書などその他の技術を用いても構わない。この実行環境は、必要に応じて他のモジュールとともに、セキュアブートモジュールとセキュア処理環境2114とを有する。上記のセキュアモードインターフェース2106はセキュアブートの信頼性の境界2104であって、そのライン以下全てが信頼性のある環境内となる。そのラインは、「TCG Mobile Trusted Module Specification」で定義されたように検証および拡張を行うセキュアブートプロセス中に構築される。セキュアモードの抽象化レイヤAPI2108は、サービスに対する通常モードからの要求を取り扱い、更なる処理のために抽象化レイヤ2110にこれらの要求をわたす。抽象化レイヤのタスクの1つはPSCデータベース2112を管理することである。また別のタスクとしては、物理的PCRs2116の操作など、セキュア処理環境2114へのアクセスを含む、セキュアブートコンポーネント2113が提供するサービスの要求を取り扱うことがある。また、セキュアブートコンポーネント2113もPSCデータベース2112へのアクセスを要求する。セキュア処理環境2114は、ハードウェアまたはソフトウェアのいずれで実現されてもよいが、好ましい実装では、「Trusted Computing Group specifications」で定義されたようなモバイルトラステッドモジュールであり、別の好ましい実装では、トラステッドプラットフォームモジュールである。ソフトウェア処理環境2113は、ハードウェアまたはソフトウェアのいずれか、あるいは双方の組み合わせで実現されてもよい。そして、セカンダリRIC(Runtime Integrity Checker)モニタ2118が存在する。このモニタのタスクには、改ざんが行われたと思われる場合にアプリケーション2100を終了させることが含まれる。これは、好ましい実装では、PSCに格納された基準ハッシュに対して現在のアプリケーションのハッシュを検証することによって実現される。この検証は、特定のイベントが発生した時あるいは定期的な間隔で行われてもよく、これらのRICモニタに階層があっても構わない。これらのRICモニタは1以上の子RICモニタの完全性をチェックする各RICモニタレベルを有する。プライマリRICは図示されていないが、そのタスクは、システム全体に対するマスター検証ルートとして、例えばハイパーバイザなどの図示されたシステム外で次のことを実行することである。すなわち、プライマリRICは、1以上のコンポーネントに対する完全性チェックを一定間隔で行い、PSCに格納された基準ハッシュに対してこれらのコンポーネントハッシュを検証する。このプライマリRICモニタのコンポーネントのうち1つはセカンダリRICを備える必要がある。「TCG Mobile Reference Architecture」では、これをPRMVA、すなわちPrimary Runtime Measurement Verification Agentと称しており、このPRMVAは、セカンダリRICモニタに相当するSRMVA、すなわちSecondary Runtime Measurement Verification Agentを有している。図示されたもの全ては装置2120に配置される。
セキュアモードは、システムプロセッサの単独実行モード、オペレーティングシステムカーネルモード、セキュリティコプロセッサ、仮想マシン、ハイパーバイザ、完全性チェックされたメモリなど、当業者にとって周知な数々の技術により実現されてもよい。各コンポーネントは、本発明の新規性を有する教示と効果を逸脱しない範囲で、1以上の記載されている技術またはその他の技術によって保護されても構わない。
当該先行技術のその他の実施形態では、セキュアモードインターフェース2106は抽象化レイヤ2110とセキュア処理環境2114との間に配置される。当業者は、抽象化レイヤの実行に対してセキュアモードの完全な保護を必要とせず、上述したRICモニタが行う完全性保護のみを要するようなかたちで当該抽象化レイヤを実装してもよく、また、本発明を、完全性保護された環境に実装してもよいと分かるであろう。当該完全性保護は、ソフトウェアまたはハードウェア、あるいは双方の組み合わせで行われる。
図21Bに、セキュアモードのサポートはないが、「TCG Specification Architecture Overview Revision 1.2 28 April 2004」に記載された手段などの独立したセキュア処理環境を有し、セキュアモードインターフェースが存在しない場合における先行技術のその他の実施形態を示す。セキュアモードインターフェースがないため、抽象化レイヤAPI2108は1つしか存在せず、セキュアブートコンポーネントの代わりに、トラステッド/セキュアブートコンポーネント2152が存在する。セカンダリRICモニタ2118は、セキュア処理環境2114以外のシステムにおける全てのコンポーネントをカバーできるように拡張され、このようにトラステッド/セキュアブートの信頼性の境界2150を確立する補助を行う。しかしながら、そうでない場合には、コンポーネントとそれらの役割は図21Aで説明した通りである。
図22Aに、図21Bなどの先行技術に基づいた本発明の第2の実施形態を示す。すでに述べたように、標準実行環境における抽象化レイヤAPI2102を使用するアプリケーション2100が存在する。破線は、上方の前述の標準実行モードと下方のセキュアモードとの間のセキュアモードインターフェース2106を示す。上記のセキュアモードインターフェース2106は、先に述べたような実行前にコンポーネントを検証するプロセスによって構築されたセキュアブートの信頼性の境界2104であって、そのライン以下全てが信頼性のある環境内となる。OSサポート2200モジュールは、標準実行空間にあるが、信頼性のある境界内である。このモジュールは、どのアプリケーションが起動前の検証にどの証明書を用いたかを示すマッピングを維持するためのコンポーネント・PSCマップ2202を管理する。セキュアモード内に、サービスに対する通常モードからの要求を取り扱い、更なる処理のために抽象化レイヤ2110にこれらの要求をわたす抽象化レイヤAPI2108がある。抽象化レイヤのタスクの1つは、PSCデータベース2112を管理することであり、また別のタスクにはtPCRサポート2204を実装することがある。このサポートモジュールが、拡張されたけれども取り消されていないPSC全ての有向非巡回グラフを含む拡張PSCツリー2206データを維持する。さらに別のタスクは、物理的PCRs2116の操作など、セキュア処理環境2114へのアクセスを含む、セキュアブートコンポーネント2113が提供するサービスの要求を取り扱うことである。また、セキュアブートコンポーネント2113もPSCデータベース2112へのアクセスを要求する。そして、セカンダリRIC(Runtime Integrity Checker)モニタ2118が存在し、そのタスクには、改ざんが行われたと思われる場合にアプリケーション2100を終了させることが含まれる。図示されたもの全ては装置2120に配置される。
先行技術と同様に、先行技術の好ましい実施形態では、セキュアモードインターフェース2106は抽象化レイヤ2110とセキュア処理環境2114との間に配置される。当業者は、抽象化レイヤの実行に対してセキュアモードの完全な保護を必要とせず、上述したRICモニタが行う完全性保護のみを要するようなかたちで当該抽象化レイヤを実装してもよく、また、本発明を、完全性保護された環境に実装してもよいと分かるであろう。当該完全性保護は、ソフトウェアまたはハードウェア、あるいは双方の組み合わせで行われる。
セキュアモードは、システムプロセッサの単独実行モード、オペレーティングシステムカーネルモード、セキュリティコプロセッサ、仮想マシン、ハイパーバイザ、完全性チェック済みメモリなど、当業者にとって周知な数々の技術により実現されてもよい。各コンポーネントは、本発明の新規性を有する教示と効果を逸脱しない範囲で、1以上の記載されている技術またはその他の技術によって保護されても構わない。
また、当業者は、tPCRサポート2204と拡張PSCツリー2206とをセキュア処理環境2114に移動させたものがその他の実施形態であると分かるであろう。さらなる実施形態は、抽象化レイヤ2110がセキュアモードインターフェース2106の外側になって、tPCRサポート2204と拡張PSCツリー2206がセキュア処理環境2114の内側になるように、これらの他の実施形態を組み合わせたものである。
図22Bに、セキュアモードのサポートはないが、”TCG Specification Architecture Overview Revision ”に記載された手段などの独立したセキュア処理環境を有し、セキュアモードインターフェースが存在しない場合における、図21Bに基づいた本発明の第2の実施形態の変形例を示す。セキュアモードインターフェースがないため、抽象化レイヤAPI2108は1つしか存在せず、セキュアブートコンポーネントの代わりに、トラスティッド/セキュアブートコンポーネント2152が存在する。セカンダリRICモニタ2118は、セキュア処理環境2114以外のシステム内における全てのコンポーネントをカバーできるように拡張され、このようにしてトラステッド/セキュアブートの信頼性の境界2150を確立する補助を行う。しかしながら、そうでない場合には、コンポーネントとそれらの役割は図22Aで説明した通りである。
図23Aに、本発明にかかるPCRの2タイプの利用パターンを示す。まず、通常アプリケーション空間におけるアプリケーション階層を示す。第1マッシュアップ2300は、第1プラグイン2302と第2プラグイン2304とからサービスを利用する。これらのプラグインは第1アプリケーション2306と第2アプリケーション2308とがそれぞれ所有するものである。どちらのアプリケーションも抽象化レイヤAPI2102からサービスを利用する。次に、セキュアモードインターフェース2106の反対側に、抽象化レイヤAPI2108のセキュアモードのサポートが存在する。これは抽象化レイヤ2110とやり取りする。抽象化レイヤのタスクの1つは、tPCRサポート2204を実装することである。このサポートモジュールにより、拡張され、かつ、取り消されていないPSC全ての有向非巡回グラフを含む拡張PSCツリー2206データが維持される。また別のタスクは、物理的PCR2116を操作する要求をセキュア処理環境2114に渡すことなどである。これは、ハードウェアまたはソフトウェアのいずれで実現されても構わない。
ところで、物理的PCR2116と一時的PCR2204を利用する典型的なパターンは以下の通りである。物理的PCRの読み取り2310動作は随時有効である。セキュア処理環境2114でサポートされる全ての関数は必ず物理的PCRを使用し、決して一時的PCRを使用しない。しかしながら、もし上述したように、tPCRサポートコンポーネント2204をセキュア処理環境2114内に移動したならば、SPEがtPCRを使用することも可能である。物理的PCRへの書き込み2314は、先行技術で教示されたように主にブート時に行われるが、さらに、アプリケーション空間から物理的PCRの書き込みが可能である2312。どの書き込み動作をアプリケーション空間から行うかを決定するのはシステム設計者または実装者次第である。一時的PCRに対し、読み取り2316と書き込み2318の双方はアプリケ―ション空間において排他的に行われるのが一般的である。一時的PCRの性質により、各実装者にはこれらのtPCRをどのように使用するか選択の自由度がある。しかしながら、図例のような場合には、第1マッシュアップ2300の開発者は、第1プラグイン2302と第2プラグイン2304の開発者達と調整して、どのtPCRをそれぞれ利用する予定か全員が把握できていると確認する必要があるであろう。
図23Bに、拡張PSCツリー2206を示す。ノードの追加および削除方法については、後で述べる。図示された有向非巡回グラフは、図22Aに示したように拡張されているとしてtPCRサポートモジュール2204が記録したPSCを表している。図22Aに示されたモジュールとこの図の証明書との間には1対2の関係があり、信頼性の境界を拡張して第1アプリケーション2306をカバーするには、先行技術で教示されているように、2つの証明書、つまり第1アプリケーション開始2350および第1アプリケーションロード2354が必要である。第2アプリケーション2308に対しては、第2アプリケーション開始2352および第2アプリケーションロード2356が必要である。第1プラグイン2302に対しては、第1プラグイン開始2358および第1プラグインロード2362、第2プラグイン2304に対しては、第2プラグイン開始2360および第2プラグインロード2364、第1マッシュアップ2300に対しては、第1マッシュアップ開始2366および第1マッシュアップロード2368が必要である。証明書間の矢印は、これらの証明書の従属関係を示している。従属関係は、各証明書の拡張時に各証明書が検出を期待するPCR状態により定義される。ツリーの各ノードの構造体は、図26において後ほど定義する。
図示したように、先行技術によると、各モジュールにはそのモジュールに関連付けられた2つの証明書があり、1つは、起動前にモジュールを検証するためにその親が使用し、もう1つは、期待された環境でモジュールが起動されたことを検証するためにモジュール自身が使用する。当業者は、モジュールごとに2つ以外の証明書を使用しても本発明の範囲内であると分かるであろう。
図24に、プラットフォーム状態証明書2400(PSC)を示す。これは、そのプラットフォーム状態証明書が定める(仮想的または一時的な)PCRで定義されるプラットフォームの状態と、プラットフォームの状態の検証がうまくいった時に(仮想的または一時的な)PCRへ拡張する値とを表す構造体である。これらの構造体をPSCデータベース2112に格納してもよい。本構造体の第1フィールドはPSC名2402である。この名前は、PSCデータベース2112へのPSCの格納およびPSCデータベース2112からのPSCの取り出しに用いられるキーフィールドなので固有でなければならない。また、好ましい実装では、この名前は、人間が読み取り可能な名前を表すバイト文字列である。アプリケーション開発者が使用する名前を決定してもよい。あるいは、プラットフォームの製造者がアプリケーション開発者に名前を提供してもよい。当業者は、GUIDなどの他の表示を代わりに用いてもよく、PSC名を選択する方法は他にもあると分かるであろう。次に、検証用PCR状態2404を表すエントリーリストが存在する。検証対象のPCRごとに、一対の値、つまりPCRインデックス2406およびPCR値2408が存在する。次に、拡張用PCR値が存在する。最初に拡張用PCRインデックス2410そして拡張用値2412である。最後に、セキュア処理環境2114の知る鍵により暗号化されたデータの残りのハッシュを表す暗号署名2414が存在する。この署名鍵は、セキュア処理環境2114へ安全に組み込まれたキーのプライベート部分か、署名PSCに使用するものであるとして上記の組み込まれたキーが直接または間接的に承認したキーのいずれかである。また、署名者は、プラットフォーム開発者またはアプリケーション開発者のエージェント、あるいは有効な署名鍵を発行した他の者でも構わない。
本発明によると、プラットフォーム状態証明書2400を単に確認するだけでは、物理的PCRなのか一時的PCRなのか判断することはできない。どの種類のPCRをチェックすべきか決定するのは、それを用いる状況である。この利点の1つは、セキュアブート用に証明書を作成する既存のツールを、アプリケーション空間用に証明書を作成するために再利用できることである。
好ましい実施形態では、検証用PCR状態2404の対リストを、テスト対象であるPCRインデックス2406を表すビットマップとPCR値2408の集合に対するハッシュとで置き換えてもよい。これは、RIM証明書に対して「TCG Mobile Trusted Module Specification」が定義した表示である。より複雑なチェックコードを費やせば、一時的なPCRを検証する証明書を変更することなく、このような表示を用いることが可能である。しかし、好ましい実施形態では、図25に図示された一時的PCR用RIM証明書2500を用いる。この構造体と図24のプラットフォーム状態証明書とのフィールドの関係および追加フィールドについて詳しく述べる。
ラベル2502はPCS名2402に相当する。measurementPCRIndex 2504とmeasurementValue 2506とは、拡張用PCRインデックス2410と拡張用値2412とに相当する。検証用tPCR状態2518、およびPCRインデックス2514とtPCR値2516とを含む対リストは、プラットフォーム状態証明書2400で定義されたフィールドと類似のものである。検証用tPCR状態2518を一時的PCR用RIM証明書2500に関連付けるためには、extensionDigestSize 2508とextensionDigest 2510のフィールドを使用することが必要である。extensionDigestSize 2508は、extensionDigest 2510のバイトサイズであり、extensionDigest 2510には検証用tPCR状態2518の構造体のハッシュが含まれる。state 2512フィールドに設定されたビット数はテーブルのペア数を示すので、サイズインジケータを格納する必要はない。当業者は、tPCRインデックス系列など、tPCR値2516フィールドに所定順序がある場合には、tPCRインデックス2514フィールドを格納する必要さえないと分かるであろう。
図26に、拡張PSCツリーノード2600を示す。これは、証明書1つの拡張を記録する構造体である。このノードの構造体では、図23Bに図示したような各ノードの内容、つまり項目2350〜2368を詳しく説明している。拡張PSCツリー2206は、当該技術分野において周知の技術を用いて有向非巡回グラフを実装する。例えば、ブーストC++ライブラリにはブーストグラフライブラリが含まれている。これは、上述した有向非巡回グラフなど様々なグラフの作成および操作をサポートする。このように、拡張PSCツリーノード2600はグラフの各頂点に関連付けられる。拡張PSC名2602は、拡張されたプラットフォーム状態証明書2400のPSC名2402のフィールドである。tPCR状態2604は、このノードにおける現在の一時的PCR状態のキャッシュであり、このノードの先祖に当たる拡張済みのPSCから算出される。tPCR状態は、tPCRインデックス2606とtPCR値2608との対リストで構成される。当業者は、このデータの別の表現、例えば、用いたtPCRを表すビットマップでtPCRインデックス2606フィールドを置き換えるなどが存在すると分かるであろう。
図27に、OSサポートモジュール2200によって維持されたコンポーネント・PSCマップ2202を示す。このコンポーネント・PSCのマップ2202には、コンポーネントをPSCへ2700マッピングするリストが含まれる。このリストの各エントリーには、コンポーネントID2702と拡張PSC名2704、つまりアプリケーションの起動前に拡張されたプラットフォーム状態証明書2400のPSC名2402フィールドとが含まれる。Windows(登録商標)ベースのプラットフォームにおける本発明の好ましい実施形態では、コンポーネントID2702は2つのフィールドから構成されている。第1フィールドは、プロセスID2706である。このプロセスIDは、GetCurrentProcessId()などのWin32APIによって決定されるような、コンポーネントが属するプロセスを一意的に表す識別子をもつ。第2フィールドはモジュールハンドル2708である。単独で実行可能なコンポーネントに対しては、このフィールドを必ず0に設定する。リンクライブラリとして実装されたコンポーネントに対しては、第1パラメータのDllMainエントリーポイントに渡されるように、ライブラリ用のHMODULEがこのフィールドに含まれる。この構造体の利用法については後で述べる。
「TCG Mobile Reference Architecture」によると、PCR0は、基礎を成すハードウェアプラットフォームの特徴を表す値を保持する。PCR1は、信頼性のルートを表す値を含む。PCR2は、エンジンロードイベントを表す値を含む。PCR3〜6および8〜12は、専有手段を含む。PCR13〜15はアプリケーションが自由に使用できる。セキュアブートが正しく行われたことをPCR0、1および2が期待通りに示すかどうかのテスト、PCR13が0に設定されたかどうかのテスト、そして、全てが正しければ新たな値をPCR13に拡張することをアプリケーションプログラマが希望したとする。図28に、先行技術にかかる、「第1アプリケーション開始」と名付けられたプラットフォーム状態証明書2400のサンプルを示す。証明書の名前は2800に記録される。上述したように、検証用PCR状態2404は、チェックするPCRインデックスとPCR値との対を4つ含み、2802、2804、2806、2808、2810、2812、2814、2816と番号付けする。2802はPCR0を示し、2804の<ハードウェアプラットフォーム>は、基礎を成すハードウェアプラットフォームを表す公表値を示す。2806はPCR1を示し、2808の<信頼性のルート>は、基礎を成す信頼性のルートを表す公表値を示す。2810はPCR2を示し、2812の<エンジンロードイベント>は、PCR2に拡張されたロードイベント値から算出された合成ハッシュを表す公表値を示す。2814はPCR13を示し、2816の0の値は、PCR13がまだ初期状態であるという予測を示す。次に、2818へ拡張するPCRが存在し、そして、そのPCRへ拡張する値820 が存在する。
先行技術にかかる図28の証明書に関する問題として次のものがある。他のアプリケーションがPCR13を使用してしまった場合、検証用PCR状態2404はもはや正確ではなくなってしまうという問題がある。アプリケーションが終了して再起動する場合、2818と2820に定義した先に拡張された値によってPCR13は0以外の状態に設定されてしまい、検証用PCR状態2404はもはや正確ではなくなってしまうという問題がある。
しかしながら、本発明では、図28の証明書と類似の証明書は、アプリケーション自身と同じ時間または別々の時間で対象装置に展開するためにアプリケーション開発者によって、図29に示すような2つの証明書に分けられる。なぜ分けるかというと、既存の証明書により2つの異なるPCRセットを検証するためである。第1のセットにはセキュアブートプロセスの結果、つまり既知の不変な結果が含まれ、第2のセットには動的状態、つまりアプリケーションレベルの状態が含まれる。図28において、項目2802および2804は、ハードウェアプラットフォームを表す既知のセキュアブートPCR0の値を指している。項目2806および2808は、信頼性のルートを表す既知のセキュアブートPCR1の値を指し、項目2810および2812は、エンジンロードイベントを表す既知のセキュアブートPCR2の値を指している。また、項目2814および2816は、期待される前提条件を表す、ブート後のPCR13の望ましい値を指している。このように、アプリケーション開発者は、セキュア処理環境が管理する物理的PCR、すなわち本例ではPCR0、1および2をテストするために用いられる片方の証明書に既知のセキュアブートPCRの値を置くことによって、図28の単一証明書を図29に示した2つの証明書に分けてもよい。第2の証明書は、アプリケーション空間の一時的PCR、すなわち本例ではPCR13用に用いられる。
「第1アプリケーション開始(セキュアブート)」2900と名付けられた第1証明書によって、セキュア環境が正しいことを確保するため、セキュアブートプロセスがセットアップした物理的PCR(PCR0 2802、PCR1 2806およびPCR2 2810)はテストされる。ここで、拡張用PCRは、拡張がないことを示すために-1 2902に設定され、拡張用値2904はゼロという名目上の値である。この証明書は検証のみに使われる。そして、アプリケーションレベルでは、図23Aに示すように物理的PCRへの書き込みをやめ、一時的PCRを用いることによってより柔軟性が高まり、前述した当該技術分野における課題を回避することができる。「第1アプリケーション開始(一時的)」2920と名付けられた第2証明書によって、ゼロ 2816である一時的PCR13 2814はテストされ、同じレジスタ2818および2820に値を拡張する。tPCRのインデックス13を選択したことに特に意味はない。先行技術の状況とは異なり、tPCR0またはtPCR99が用いられやすいであろう。
図30に、シーケンス図を示す。この図では、アプリケーション起動時には図29の2つの証明書、つまり一方が物理的PCRをテストする証明書でありもう一方が一時的PCRをテストする証明書を用い、アプリケーション終了時には「第1アプリケーション開始(一時的)」2920の第2証明書を用いて、値をtPCRに拡張してからその拡張を取り消すという本発明にかかるイベントシーケンスを示す。相互に作用する6つのオブジェクト、21000、21002、21004、21006、21008および21010を図示している。まず、tPCR13 21000は、この例の状況における一時的PCR13の状態を表す。図26で説明したように、tPCRは、特定のメモリ位置というよりむしろ拡張PSCツリー2206のノードごとに記録されるが、本例においては理解しやすいよう、tPCR13 21000をそのような位置にあるかのごとく表す。次に、tPCRサポート21002が存在する。これは、tPCRを参照するPSCの取得と現在のtPCR状態の検証との処理を行い、有効であれば、証明書は拡張されたと記録する。SPE21004は、先行技術にかかるセキュア処理環境である。好ましい実施形態では、それはMTMである。抽象化レイヤ21006は、通常モードのアプリケーションからの要求を取り扱い、要求を他のモジュールにわたす。OS21008はオペレーティングシステムであり、ここでは、一時的PCRを正確にアップデートするようなアプリケーションの起動および終了の処理に関するシステムである。そして、図30のシーケンス図のプロセスは入れ子されてもよいので、アプリケーション21010は、例えば、アプリケーション実行21042が21014から始まるイベントシーケンスに従う別のアプリケーションの開始を含むような、PSCによって保護された他のアプリケーションの開始を要求するアプリケーションであっても構わない。図を単純化するため、エラー処理については図示しないが、本発明から除外されるものではない。
まず最初に、tPCR13 21000は、0の値21012で始まる。本発明では、拡張PSCツリー2206のルートは、全tPCRを0に設定させた状態で始まるというのがルールである。当業者であれば、セキュアブートの完了後に物理的PCRの値でtPCRを初期化するというような他の初期値候補が可能だと分かるであろう。OS21008は、要求を検出してアプリケーション21010を起動するので、まず、起動しようとするアプリケーションによってどのPSCが用いられるのかを決定する21014。Windowsベースのオペレーティングシステムにおける好ましい実施形態では、実行ファイルに組み込まれたカスタムアセンブリが、使用する2つのPSCを特定する。そのアプリケーションは、改ざんから保護するためにマイクロソフトのストロングネームツールを用いて署名される。次に、21014で特定されたPSC、この図では「第1アプリケーション開始(セキュアブート)」および「第1アプリケーション開始(一時的)」を抽象化レイヤ21006に要求する21016、21018。そして、これら2つのPSCの検証が、抽象化レイヤAPIであるAL_VerifyPSCsAndExtendtPCRを呼び出す21020ことによって行われる。このAPIは、システムが開始したいアプリケーションを検証する2つのPSC、つまり、図29で示したような物理的PCR用のPSCおよび一時的PCR用のPSCを引数とする。まず、図の21024で表されたPSC「第1アプリケーション開始(セキュアブート)」を引数とした、SPEのAPIであるSPE_VerifyPSCStateを呼び出す21022。先行技術によれば、これによって、PSC自身のフォーマットおよび署名のチェックが行われ、そして、PSCの検証用PCRが物理的PCRの現在の値と一致することを検証する。先行技術によれば、PSCがプラットフォームに渡されると、セキュア処理環境2114に組み込まれたキーか、この組み込まれたキーによって正当であると検証されることのできるキーのいずれかでPSCは署名される。そして、有効であれば、セキュア処理環境2114が生成かつ安全に格納した他のキーで再び署名され、証明書はPSCデータベース2112に格納される。
本発明の好ましい実施形態によると、物理的PCRをチェックするPSCはオプショナルなので、ステップ21016および21018を省略してもよい。その他の好ましい実施形態によると、物理的PCRのチェック用のPSCがアプリケーション全てについて同じである場合、物理的PCR用のPSC1つを2つ以上の異なる一時的PCRのPSCが用いてもよい。
次に、SPEの他のAPI、すなわち、図の21030で表されたPSC「第1アプリケーション開始(一時的)」にパラメータを設定したSPE_VerifyPSCを呼び出す21026。先行技術によると、これによって、物理的レジスタに対してPCRの設定を検証せずとも、PSC自身のフォーマットおよび署名のチェックが行われる。そこで、tPCRサポートモジュール、すなわち、図の21030で表されたPSC「第1アプリケーション開始(一時的)」にパラメータを設定したAPIであるTPCR_VerifyPSCAndExtendを呼び出す21028。このAPIの最初のタスクは、拡張PSCツリー2206内の既存状態に対応する検証用PCR状態2404をチェックすることにより、PSCを拡張できることを検証する21032ことである。この動作の詳細については後で述べる。検証が正常に完了した時点で、このPSCにおける動作の成功が、拡張PSCツリーの正しい位置へその表示を付け加える21034ことによって記録される。この動作の詳細については後に述べる。このPSCをツリーへ付け加えたことによる結果の1つは、tPCR13 21000、つまり拡張対象のレジスタが、以前の値、この場合は0、とPCRから拡張するための値1030、つまり0xABCD1234とを連結したもののハッシュに設定されたレジスタの値を有することである。これは、合成ハッシュと呼ばれ、数式的には、tPCR13 = SHA-1(0xABCD1234と連結されたtPCR13)と書き込まれる。この動作は21036の構文 (+)=で表される。このように、環境が期待された状態であることを検証し、成功したことの記録が生成され、そして、制御がオペレーティングシステムに戻る。先行技術によると、21020におけるPSC検証の前の、更なる安全性の評価として、アプリケーションのハッシュを算出し、拡張するPSCに格納された基準値と比較する。本発明では、この値は、好ましい実施形態において0xABCD1234と表された、拡張用の値として、PSC「第1アプリケーション開始(一時的)」21030に格納される。しかしながら、このステップは図から省略されている。
アプリケーションを起動する際に、OSは、そのアプリケーションのプロセスIDを取得し、コンポーネント・PSCマップ2202に、この識別子と一時的レジスタ用の対応PSC、つまりPSC「第1アプリケーション開始(一時的)」とを記録する21038。マイクロソフトのWindows環境における好ましい実施形態では、本プロセスは、http://www.codeproject.com/KB/system/InterceptWinAPICalls.aspxのコードプロジェクトにおけるAndriy OriekhovのIntercepting WinAPI callsに記載されたようなプロセス作成プロセスを途中でインターセプトすることによって実装される。取得したプロセスハンドルは、プロセスID2706に変換され、そのフィールドに設定される。そして、モジュールハンドル2708を0に設定する。コンポーネントがダイナミックリンクライブラリである場合、http://www.lenholgate.com/archives/000369.htmlの/* Rambling comments... */におけるLen HolgateAPIのWhy does windows hold the loader lock whilst calling DllMain?に記載されたように、LoadLibrary()およびFreeLibrary()コードをフックし、DllMain()への呼び出しをトラップする。このトラップを設けたまま、プロセスID2706を現在のプロセスIDに設定し、モジュールハンドル2708をDllMain()の第1引数に設定する。
アプリケーションは起動されると21040、PSCに関連付けられた他のアプリケーションを起動またはtPCR自体を参照する他のPSCを拡張したとしても、プログラムされたように実行し続ける21042。そして、アプリケーションを閉じるとユーザが選択する、クラッシュする、または、アプリケーションを強制的にシャットダウンするセカンダリRICモニタ(この図では図示していない)が改ざんを検出するといういずれかの原因で、アプリケーションは終了する21044。
アプリケーションが終了するので、OSはアプリケーションのプロセスIDを取得し、そのプロセスIDと0であるモジュールハンドルとを用いて、コンポーネントID2702を作成する。このコンポーネントIDを用いてコンポーネント・PSCマップ2202を検索し、アプリケーションを起動するのに用いられたPSCを見つける21046。これにより、PSC「第1アプリケーション開始(一時的)」21030が返されるので、取り消しを行うため、OSは、抽象化レイヤ21006のAPIであるAL_UndoPSCExtendを、PSCを引数として呼び出す21048。コンポーネントがダイナミックリンクライブラリである場合、上述したようにFreeLibrary() APIをフックするので、そのルーチン内で現在のプロセスIDを問い合わせ、FreeLibrary()のパラメータからモジュールハンドルを取得し、そしてこれら2つのデータ項目を用いて、コンポーネントID2702を作成する。このコンポーネントIDを用いてコンポーネント・PSCマップ2202を検索し、ライブラリを起動するのに用いられたPSCを見つける。前述と同様に、SPEの他のAPI、すなわち、図の21030で表されたPSC「第1アプリケーション開始(一時的)」にパラメータを設定したSPE_VerifyPSCを呼び出す21026。先行技術によると、これによって、物理的レジスタに対してPCRの設定を検証せずとも、PSC自身のフォーマットおよび署名のチェックが行われる。そこで、tPCRサポートモジュール21002、すなわち、図の21030で表されたPSC「第1アプリケーション開始(一時的)」にパラメータを設定したAPIであるTPCR_VerifyPSCAndExtendを呼び出す21050。このAPIの最初のタスクは、拡張PSCツリー2206にそのPSCがすでに存在するかどうか確認することによって、PSCが拡張されたことを検証する21052ことである。検証が正常に完了した時点で、これは、21028における拡張動作を取り消すことが可能であることを意味する。これは、拡張PSCツリー21034から、PSCを表すノードおよびそれに従属する他のノード全てを削除することによって実現される。この動作の詳細は後で述べる。ツリーからこのPSCを削除することの結果の1つは、tPCR13 21000、つまり取り消す対象のレジスタが効率よくその状態を0にリセットされる21056ことである。このように、環境が期待した状態であることを検証し、拡張PSCツリーからノードを削除する21034ことによって先に拡張された動作を取り消し、制御がオペレーティングシステムに戻り、本システムは他の動作をすぐに実行することができる。当業者であれば、これらの他の実行動作の1つとして、終了したアプリケーションを再起動することもあると分かるであろう。tPCR13が21056において00…00、つまり21012で示されたtPCR用の開始値にリセットされた後は、アプリケーションの開始PSC21030の検証は2回目も正常に再実行されるので、本発明によると、アプリケーションを再起動することができる。
図30に、実行ファイルの起動および終了時に信頼性の境界を動的に拡張かつ縮小するシーケンス図を示す。注釈を用いて、好ましい実施形態に沿ったダイナミックリンクライブラリに対する同様のタスクをWindows Portable Executable形式のモジュールでどのように行うかを示す。Java ArchiveモジュールやJARなどのPortable Executableベースでないモジュール形式に対しては、モジュールをロードかつアンロードするエンジンによって同様の手法が用いられるか、代わりに、モジュール自身によって抽象化レイヤ21006への明示的な呼び出しが行われるかして、信頼性の境界を拡張かつ縮小してもよいと当業者は分かるであろう。先行技術によると、JARは、Javaバイトコードベースのモジュールだけでなく、例えばECMAスクリプト(Javaスクリプト)など、その他の言語モジュールを含んでもよい。これらを、http://java.sun.com/j2se/1.3/docs/tooldocs/win32/jarsigner.htmlのSunからjarsignerツールを用いて署名し、その署名を、http://java.sun.com/j2se/1.4.2/docs/api/java/util/jar/JarFile.htmlに記載されたようなjava.util.jar.JarFileクラスを用いて検証してもよい。この場合、好ましい実施形態において、図27に示されたモジュールハンドル2708は、コンポーネントを含むJARファイルを参照するハンドルである。
図31に、tPCRサポートモジュール21002のAPI、TPCR_VerifyPSCAndExtend 21028の詳細に関するフローチャートを示す。本関数は、検証および記録するためのPSCをパラメータとしてわたして21100で開始し、次の図32で示す、拡張PSCツリーの各ノードに対してtPCR状態を算出する21102サブルーチンを呼び出す。次に、現在のtPCR状態とソリューションリストの変数とを、NULLに初期化する21104。これら2つの変数の利用法については図33で説明する。そして、渡されたPSCのtPCR値に、現在の拡張PSCツリーに記述された状態から達することができることを検証するサブルーチンが呼び出される21106。戻りコードをテストすることで、本関数が、拡張PSCツリー内で、渡されたPSCが保持する検証用の状態にtPCRを設定したノードを1以上見つけたかどうか分かる21108。この設定された親が見つからなかった場合、プロセスは、呼び出しルーチンへ拡張できなかったことを示すエラーコードを返す21110。見つかった場合は、渡されたPSCを、ソリューションリストに記述されたノードに設定した先のPSCを有する拡張PSCツリーに付け加え21112、プロセスは、呼び出しルーチンにサクセスコードを返す21114。
図32に、図26における拡張PSCツリーの各ノードのtPCR状態2604をどのように算出するか説明するフローチャートを示す。当該フローチャートは引数なしに呼び出され21200、行きがけ順に拡張PSCツリーの走査を行う21202ことで処理が開始する。この走査は、ツリーのノードを続く処理にとって望ましい順序で収集するためにルートから始まる。好ましい実装では、ブーストグラフライブラリ関数breadth_first_search()を用いてこれらのノードを収集する。次に、記録されている各ノード21204に対し、深さ優先走査によって現在のtPCR状態2604をNULLに設定する21206。セキュアブート完了の際に定義されたtPCRの開始値、好ましい実施形態では0の値、に初期化されたtPCRを検証する証明書の特別処理が必要なので、現在の証明書に格納された検証用PCR状態2404のtPCR対ごとに、その値をセキュアブート完了の際に定義されたtPCR初期値、好ましい実施形態では0の値と照合する21210。それらが等しい場合は、tPCRのインデックスおよび値の対をこのノードのtPCR状態に付け加え21212、次のtPCRに対してループを続ける。そうでない場合は、ノードのtPCR状態を付け加えずにループを続ける。各tPCRをチェックすると、本関数は、現在のノードの親それぞれに対するループへと移行する21214。親ノードが拡張PSCツリーのルートノードであれば21216、前回のループがこの特殊ケースを処理したため、何も行われない。そうでない場合には、親ノードのtPCR状態2604を問い合わせ、コピーする21218。親の拡張PSC名2602により参照されるPSCによって定義された拡張動作が親の状態のコピー21220において行われ、その結果のtPCR状態が現在のノードのtPCR状態に付加される21222。この拡張PSCツリー構築方法により、2つの親が同じtPCRに対して異なる値を指定する事態は決しておこらない。そのため、当業者は、この状況をチェックする必要はないが、検証目的で実装してもよいと分かるであろう。tPCR状態の収集は、前述したように、全ての親に対して繰り返され、終了すれば、走査中の次のノード21204が処理される。このように各ノードが処理されると、各ノードのtPCR状態を返してプロセスは終了する21224。
当業者は、例えばbfs_visitor’s examine_vertex()でステップ21204から21222を実行するなど、上記アルゴリズムを実行する別の方法が存在するので、ノードの別々のリストの必要性はなくなると分かるであろう。さらに、この関数は、PSC関連の動作が行われるたびに呼び出されるが、その値をキャッシュして再計算にかかる労力を削減してもよい。
図33に、ノードごとのtPCR状態が算出された後、あるPSCに定義された状態へtPCRを設定する拡張済みのPSC全てのリストを見つけることによって、どのようにしてそのPSCを検証するか説明するフローチャートを示す。この図で説明するルーチンは、再帰的なルーチンであることに注意されたい。このルーチンへのエントリーポイントは、引数として、リスト形式の検証用tPCR状態と、現在のtPCRの一致の状況と、tPCR状態によってPSCの親だと判明した拡張PSCツリーのノードのリストとをとる21300。ソリューション方法の概要は、tPCRのインデックスおよび値の対ごとに、望ましい値を現在のtPCRに拡張する証明書であり、かつ、このソリューションの一部である別のtPCRに拡張する他の証明書と互換性をもつ証明書を見つけようと試みることである。候補が見つかれば、ルーチンを再帰的に呼び出して、PSCの一部である別のtPCRを一致の状態へ拡張する他の証明書を見つける。
最初のステップは、一致するtPCRのリストをチェックすることである。これが空である場合21302、ルーチンはリストの最後に正常に再帰されたので、呼び出し側に成功を示すためFOUND値を返す21304。そうでない場合は、tPCRリストの先頭を削除し、これを現在のtPCRとして用いて親の証明書を見つけようと試みる21306。ソリューションリストにまだ割り当てられていない拡張PSCツリーの各ノードを親になる候補として選択する21308。先行技術に従ってこれらのノードをどのように取得できるかは図32の説明で示した。まず、2つの構造体において一致するtPCRインデックスが同じtPCR値であることを検証することによって、このノードのtPCR状態を、渡された現在の一致tPCR状態と互換性があるかどうかチェックする21312。値が一致しなければ21316、ルーチンは、拡張PSCツリーの次のノードへ移行する21308。一致する場合は、ノードに格納された拡張PSC名2602を用いて検証用ノードのPSCを検索し21314、拡張用PSCのインデックス2410を21306で取り出した現在のtPCRのインデックスと比較する。インデックスが一致しない場合21316、ルーチンは、拡張PSCツリーの次のノードへ移行する21308。インデックスが一致する場合は、親ノード候補が見つかったので、このノードをソリューションリストに付け加え21318、このノードの状態を拡張して現在のtPCRリストにマージする。tPCR検証ルーチンを、短縮したtPCRリストと現在のtPCR状態とソリューションリストとを引数にして、再帰的に呼び出す21332。再帰的呼び出しが成功すれば21324、呼び出し側にその成功を示すためFOUND値を返す21326。失敗した場合は、現在のノードをソリューションリストから削除して21320での状態のマージを取り消し21328、そして、ツリーの次のノードを調べるためにループを続ける。全てのノードが調べられ、一致がなかった場合は、NOTFOUNDを返す21310。
図34に、取り消し前と取り消し後のサンプル拡張PSCツリー2206の状態を示す。取り消し前の状態21400は図23Bで述べたとおり、図23Aのモジュールツリーから構築された状態である。ところで、図30で示されたように、ユーザからの作用、プログラムバグ、または改ざん検出により第1プラグインが終了すれば、オペレーションシステムは第1プラグインの終了を検出して、「第1プラグイン開始」証明書2358は起動時にテストされたPSCであったと判断するので、証明書の拡張を取り消す必要がある。「第1プラグイン開始」2358とともに、それに従属する全ての証明書、すなわち、「第1プラグインロード」2362、「第1マッシュアップ開始」2366および「第1マッシュアップロード」2368も拡張PSCツリー2206から削除しなければならない。その結果、取り消し後の状態21402の拡張PSCツリー2206となる。
図35に、拡張プロセスをどのようにして取り消すか説明するフローチャートを示す。本関数は、引数として、取り消し対象PSCをとる21500。まず、本関数は、上記の図32で示された、拡張PSCツリーのノードごとにtPCR状態を算出する21502サブルーチンを呼び出す。次に、対象PSCのPSC名2402とツリー内の各ノードの拡張PSC名2602との一致を探すことで、拡張PSCツリー内で対象PSCへの参照を検索する21504。一致するノードが見つからない場合21506、エラーコードを呼び出し側に返して取り消すことができなかったことを示す21512。次に、対象PSCの検証用PCR状態2404を見つかったノードのtPCR状態2604とを比較する。それらの状態が等しくない場合21510、エラーコードを呼び出し側に返して取り消すことができなかったことを示す21512。状態が等しい場合は、見つかったノードとそれに従属するもの全てを削除する関数を呼び出し、その関数がサクセスコードを呼び出し側に返す21516。
図36に、取り消し処理が拡張PSCツリーからどのようにしてノードを削除するか説明するフローチャートを示す。本関数は、引数として、ツリーから削除するノードをとる21600。まず、このノードの子PSC全てに対してループし21602、再帰的に自分自身を呼び出してその子それぞれを順に削除する21604。全ての子が削除された時点で、ノード自身を削除し21606、本関数はリターンする21608。このようにして、終了中のモジュールおよびそれに従属する信頼性のあるモジュール全てをカバーする、以前の拡張処理によって確立された信頼性の境界は、終了する必要のないモジュールをカバーしたまま、装置のアプリケーション空間における信頼性レベルを落とすことなく、終了するモジュールを除外するように縮小される。
(第3の実施形態)
本発明の第3の実施形態は、リモート認証のためのものである。先行技術によると、リモート認証のプロセスには異なる段階が2つある。まず、共有されるAIK、すなわち、認証識別キー(Attestation Identity Key)が、TPM v1.2にある匿名認証(Direct Anonymous Attestation)プロトコルをおそらく用いて、装置上のクライアントとリモートサーバとの間で確立される。次のステップは、このAIKを用いて特定のデバイス構成の認証を行うことである。図37Aおよび図37Bに、当該リモート認証の先行技術を示す。装置2120とその構成要素とは、図11Aおよび図11Bで示されたものに、セキュア処理環境2114内に格納されたAIK21710を加えたものである。図37Aに、当該システムのセキュアブートをサポートする場合における先行技術を示し、本発明にとって重要な2つの要素を含むサーバ21700も示す。認証プロセスを制御する認証器21702があり、これは、先に確立されており、装置2120のAIK21710と関連付けられているAIK証明書21704を用いる。認証器21702は、認証要求21706を生成し、認証を要求したアプリケーション2100にその認証要求を送信する。アプリケーション2100における認証プロセスでは、認証要求21708をセキュアブートコンポーネント2113に送信し、セキュアブートコンポーネント2113はセキュア処理環境2114と連携して先行技術で定義したような認証を実行する。
図37Bも同様に、セキュアモードのサポートはないが、「TCG Specification Architecture Overview Revision 」に記載した手段などの独立したセキュア処理環境2114を有し、セキュアモードインターフェースが存在しない場合における先行技術を示す。前述したように、本発明にとって重要な2つの要素を含むサーバ21700も存在する。認証プロセスを制御する認証器21702があり、これは、先に確立されており、装置2120のAIK21710と関連付けられているAIK証明書21704を用いる。認証器21702は、認証要求21706を生成し、認証を要求したアプリケーション2100にその認証要求を送信する。アプリケーション2100における認証プロセスでは、認証要求21705をトラステッド/セキュアブートコンポーネント2152に送信し、セキュアブートコンポーネントはセキュア処理環境2114と連携して先行技術で定義したような認証を実行する。
図38Aに、図37Aの先行技術に基づいた、一時的PCRに対するリモート認証のための本発明における第3の実施形態を示す。サ―バ21700は前述したものであり、前述した認証要求21706は、アプリケーション2100に対して行われる。しかしながら、第3の実施形態では、セキュアブートコンポーネント2113へ認証要求21708を直接行う代わりに、サーバへ返される認証情報にtPCRサポート2204からの情報も含めることができるよう、システムのレイヤ全てを介して認証要求21800を行う。
図38Bに、図37Bの先行技術に基づいた、一時的PCRに対するリモート認証のための本発明における第3の実施形態を示す。サ―バ21700は前述したものであり、前述した認証要求21706は、アプリケーション2100に対して行われる。しかしながら、第3の実施形態では、トラステッド/セキュアブートコンポーネント2152へ認証要求21708を直接行う代わりに、サーバに返される認証情報にtPCRサポート2204からの情報も含めることができるよう、システムのレイヤ全てを介して認証要求21850を行う。
図39に、アプリケーションがリモート認証する間のモジュール間通信について説明するシーケンス図を示す。相互に作用する6つのオブジェクト、21004、21002、21006、21008、21010および21900を図示している。まず、SPE21004は先行技術に係るセキュア処理環境である。好ましい実施形態では、それはMTMである。次に、tPCRサポート21002が存在する。これは、tPCRを参照するPSCをとって任意のPSCに基づくtPCR状態を検証する処理を行い、有効であれば、証明書を拡張したことを記録する。抽象化レイヤ21006は、通常モードのアプリケーションからの要求を取り扱い、要求を他のモジュールにわたす。OS21008はオペレーティングシステムであり、ここでは、一時的PCRを正確にアップデートするようなアプリケーションの起動および終了の処理に関するシステムである。アプリケーション21010は、リモート認証を要求するアプリケーションである。そして、サーバ21900はリモート認証を行う。
まず、アプリケーション21010は、抽象化レイヤ21006にクライアントノンスNc を要求し21901、このランダムに生成された値が返ってくる21902。この値は、アプリケーション21010がサーバ21900に認証を要求する場合に用いられる21903。例えば、アプリケーション21010が保護されたサービスへのアクセスを許可する前に、サーバ21900はアプリケーション21010が期待された環境で動作しているか確認する必要があるため、アプリケーション21010はサーバ21900からこの許可を得るため認証手順を開始する。アプリケーション21010は、生成されたクライアントノンスNc をサーバ21900に渡す。このクライアントノンスは、アプリケーション21010およびサーバ21900間の通信ストリームに対するリプレイ攻撃やその他の攻撃に対する保護を実現するための値である。サーバ21900は、クエリ用のサーバノンスNsとランダムに生成されたChallengeと物理的PCRセットとを含むメッセージを付けた認証要求を送信することによって応答する21904。このメッセージは、先行技術で述べられているような匿名証明プロトコルなどでクライアントとサーバとの間において先に確立されたAIKを用いて署名される。ここで、好ましい実施形態では、このメッセージフォーマットはTCGで指定されたものと同じである。アプリケーション21010は、この認証要求の処理21906をOS21008に託す。OS21008は、図30で述べたようなプロセス空間の情報を用いて、どのアプリケーションまたはダイナミックロードライブラリが関数を呼び出したのかと、モジュールがどのPSCを使ってそのモジュール自身の検証を行ったのかとを判断し21908、アプリケーションのリモート認証用の先に確立されたAIKを決定する21909。検索されたPSCは、モジュールへ認証要求するために、他の認証パラメータとともに抽象化レイヤ21006へ渡される21910。ここで、認証が開始可能になる。まず、認証用のサーバノンスとランダムChallengeと物理的PCRとを含むメッセージの署名が、先行技術に基づき先に確立されたAIKを用いてSPE21004によって検証される21912。次に、SPE21004を再び用いて、今度は、アプリケーション21010に対するPSCの完全性を検証し21914、そして、tPCRサポート21002を用いて前記PSC内のtPCRセットの検証を行う21916。これらのチェックが正常に行われたとすると、抽象化レイヤ21006はSPE_Quoteで用いられるハッシュ値を作成する21918。このハッシュは、先にサーバへ送信されたクライアントノンスとサーバノンスと21910で渡されたChallengeとを連結したものおよびアプリケーション21010のPSCに格納されている一時的PCRハッシュから算出される。SPE21004が、サーバから受信したPCRセレクション21904に対応したPCRセットと、21918で算出されたハッシュ値とを含み、確立されたAIKのプライベート部分を用いて署名された署名済みハッシュの生成を要求される21922。SPE21004がMTMである第3の実施形態において、SPE_QuoteはTPM_Quoteのエイリアスであり、TCG仕様書で定義されたように動作する。この得られた署名値は、SPE21004からサーバ21900へ、21922、21924、21926そして21928と遡って渡される。サーバ21900は、渡された結果が期待される結果と等しいかどうかを検証し21930、等しければ、アプリケーション21010に認証が正常に完了したことを通知する21932。
第3の実施形態では、アプリケーション21010およびサーバ21900間の通信(21903、21904、21928、21930および21932)は、インターネットを介したワイヤレスリンクで行われるが、固定リンクや無線リンクを用いる実施形態でも可能であると当業者は分かるであろう。この通信のプロトコルは、メッセージコンテンツを暗号化する必要がないように設計されているが、SSLなどの暗号化プロトコルを用いる実施形態でも可能であると当業者は分かるであろう。
もう1つの方法として、tPCR値に対するリモート認証のみを要求しても構わない。図40に、この場合のリモート認証で用いられるQuote情報記録22000の構造体を示す。versionフィールド22002には、定値1.1.0.0と定義されたバージョン表示が含まれる。fixedフィールド22004には、定値「QUOT」と定義された構造体タイプの識別子が含まれる。digestValueフィールド22006には、認証されるtPCRダイジェスト値が含まれる。externalDataフィールド22008には、クライアントノンスとサーバノンスとChallenge値とを連結したもののハッシュとしてリモート認証プロトコルにより定義された外部データが含まれる。そして、signatureフィールド22010には、上記のフィールドの暗号化署名が含まれる。この署名は、先に確立されたAIKとしてリモート認証プロトコルにより定義された、署名生成ルーチンに渡されたキーリファレンスを用いて生成される。
図41に、tPCRのみに対し、アプリケーションが図40で示したQuote情報構造体22000を用いてリモート認証する間のモジュール間通信を示す。この通信シーケンスの第1段階は、図39で示したシーケンスと全く同じである。前述したように、抽象化レイヤ21006は、SPE21004を用いて、認証要求の署名を検証し21912、一時的PCRのPSCの完全性を検証する21914。そして、tPCRサポートを用いてPSC内の実tPCR値を検証する21916。前述した検証が正常に行われた場合は、ここから、図39とシーケンスが異なってくる。抽象化レイヤ21008は、Q1と名付けられたQuote情報構造体22000を作成し22100、versionフィールド22002およびfixedフィールド22004をそれぞれ予め定義した値へ初期化する22102。次に、digestValueフィールドを先に検証されたPSC内のフィールドのダイジェスト値へ設定する22106。このダイジェスト値は、検証用PCR状態2404のPCR値nフィールド2408全てのハッシュ値をまとめて計算することによって算出される。次に、externalDataフィールド22008を、クライアントノンスとサーバノンスとChallenge値とを連結したもののハッシュ値へ設定する22106。これらのうちサーバノンスとChallenge値は、21910で抽象化レイヤから渡されたものである。全てのデータが正しく設定されると、抽象化レイヤ21006は、Quote情報22000の最初の4つのフィールドを暗号化署名用のデータとして、最後のフィールドを署名用のキーとしてAIKを用いて署名を保存する場所であるsignature 22010として、SPE21004のSPE_Sign関数を呼び出す。SPE_Sign関数22108の動作は、TPM_Sign APIの先行技術において詳述されたとおりである。この結果は、signatureフィールド22010に置かれ、抽象化レイヤ21006に返される22110。そして、このQuote情報構造体22000一式は、抽象化レイヤ21006からサーバ21900へ、22112、22114、22116へと遡って渡される。サーバ21900は、渡された結果が期待される結果と等しいかどうかを検証し22118、等しければ、アプリケーション21010に認証が正常に完了したことを通知する21932。
本発明は上記の実施形態に基づいて述べられているが、本発明は明らかにそのような実施形態に限定されるものではない。下記のケースもまた本発明に含まれる。
(1)上述の実施形態では、MTM仕様書と同様の方法で検証は行われた。しかしながら、本発明を他の検証システムに適用してもよい。ただし、コンポーネントをチェーンのように検証する検証方法で検証システムがシステムのコンポーネントを検証できる場合(例えば、あるコンポーネントがそのコンポーネントの後に起動する他のコンポーネントを検証する)に限る。例えば、ハッシュ値のMTMへの拡張などの動作はTCG仕様書に固有なものであるため、省略してもよい。
(2)上述の実施形態では、証明書(RIM証明書)内でハッシュ値を使用することにより検証は行われた。しかしながら、ハッシュ値を使用しない他の検証方法が本発明に適用されてもよい。
従来のチェックサムや、コンポーネントから抽出される別のデータ(例えば、コンポーネントから抽出される第1所定ビット)が、検証を行うために使用されてもよい。また、証明書は、完全性チェック値を含むデータの集合に置き換えられてもよい。
さらに、検証方法は、コンポーネントから抽出される値と期待される値が等しいか否かをチェックすることに限定されない。例えば、コンポーネントのサイズを確認し、もしサイズが所定量より大きいか、または小さいなら、コンポーネントは検証されたと判断されるとしてもよい。これらの検証方法は、ハッシュ値と、その期待値とを比較するほど厳密なものではないが、それよりも高速に行われる。
(3)上記の各装置は、具体的には、マイクロプロセッサ、ROM、RAM、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。RAMまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
(4)上記の各装置を構成する構成要素の一部または全部は、1個のシステムLSI(Large Scale Integration:大規模集積回路)から構成されているとしてもよい。システム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、BD(Blu-ray Disc)、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。
また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記憶しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。
また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
(7)本技術分野の当業者にとっては、説明した実施形態の、本発明固有の教示および利点から原理的に離れることのない多くの変形がありえることを容易に理解することができるだろう。また、上記変更および実施形態の任意の組み合わせは、本発明の範囲内に含まれる。