JP5398824B2 - セキュア処理システムのアプリケーション空間において信頼性を実現するための一時的ｐｃｒ利用 - Google Patents

セキュア処理システムのアプリケーション空間において信頼性を実現するための一時的ｐｃｒ利用 Download PDF

Info

Publication number
JP5398824B2
JP5398824B2 JP2011510771A JP2011510771A JP5398824B2 JP 5398824 B2 JP5398824 B2 JP 5398824B2 JP 2011510771 A JP2011510771 A JP 2011510771A JP 2011510771 A JP2011510771 A JP 2011510771A JP 5398824 B2 JP5398824 B2 JP 5398824B2
Authority
JP
Japan
Prior art keywords
module
modules
information
active
platform information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2011510771A
Other languages
English (en)
Other versions
JP2012505437A (ja
Inventor
アレクサンダー ニコルソン ケネス
秀樹 松島
久 高山
孝幸 伊藤
智之 芳賀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2011510771A priority Critical patent/JP5398824B2/ja
Publication of JP2012505437A publication Critical patent/JP2012505437A/ja
Application granted granted Critical
Publication of JP5398824B2 publication Critical patent/JP5398824B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2145—Inheriting rights or properties, e.g., propagation of permissions or restrictions within a hierarchy

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Storage Device Security (AREA)

Description

本発明は、アクティブモジュールと、アクティブモジュールの次のモジュールとをロードする情報処理装置に関する。
例えば、非特許文献１、および、非特許文献２のような先導的な先行文献は、装置を、どのようにして、保証、また、信頼できる方法で起動するかを記述している。これらの方法は、信頼性や安全性が、ブートプロセスの間保持されるということを保証するため、徹底的に見直されてきており、その結果、安全にブートができる装置の実装を要求する人々に、有用な基準を提供している。このセキュアブートプロセスのキーコンポーネントは、RIM証明書である。これは、現在期待されるプラットフォームの状態が、どのようなものであるべきかを定義する、署名つきの構造体である。プラットフォーム状態は、プラットフォーム設定レジスタ(PCRs)の集合に対するハッシュによって表され、各ＰＣＲは、一般に、定義されたハッシュ値を含む。これらのPCRは、完全性測定（integrity measurement）情報として用いられるものであり、期待される装置の状態を定義するために、RIM証明書に記録されていてもよい。さらに、RIM証明書はまた、現在の状態が検証される場合に、拡張されるべきPCRを特定する。この拡張の処理では、特定されたPCRの値を取得し、RIM証明書内で定義される新たな既知の値に連結された前のPCR値に基づいて、新たなハッシュ値を算出する。TCGによって定義される典型的なセキュアブートシーケンスは、コアコンポーネントの初期化および自己検証から開始する。ここで、コアコンポーネントとは、検証および測定の信頼性のルート(RTV+RTM)、MTM自体、および関連するコアMTMインターフェースコンポーネント等である。次に、ファームウェアの他の部分をサポートする追加コンポーネントが、信頼できる方法で起動される。ここで、信頼できる方法とは、各コンポーネントが、信頼性のあるコンポーネントから立ち上げられたものであることを保証するために、制御が渡される前に、信頼済みのコンポーネントにより、各コンポーネントを検証してから、自分自身を検証するような方法である。検証→実行→自己検証というこのシーケンスには、システム内において、信頼性のルートから、各コンポーネントへ、動的に信頼性の境界を拡張するという効果がある。そして、最後に、オペレーティングシステムを起動して、MTMサービスへとアクセスするクライアントアプリケーションに対し、安全で信頼性のあるパスを提供する。
米国特許出願公開第2006/0212939号明細書
tTrusted Computing Group (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 TCG TPM Specification Version 1.2 Revision 103
しかしながら、セキュアブートプロセスで、PCRへの書き込みが終了すると、問題が生じる。上述したセキュアなブートコンポーネントとは異なり、通常のアプリケーションは、ユーザからの作用、プログラム障害、またはアプリケーション改ざんの検出でさえ原因となって、当然ながら、終了する。非特許文献３では、特別な状況下において、いくつかのPCRをリセットすることが許可されているが、「TCG Mobile Trusted Module Specification v1.0 Revision 1」では、RIM証明書により制御されるPCRは、リセット可能とすべきではないと記載されている。「TCG Mobile Reference Architecture v1.0 Revision 1」の参考コメントでは、この問題に対して、何もしない、１回目の実行に限り拡張する、または１つのPCRを繰り返し拡張するという、３つの解決策が提案されている。何もしないことでは、アプリケーションの安全性または信頼性は改善されない。１回目の実行に限り拡張するということでは、アプリケーションをカバーできるように、信頼性の境界は拡張されるけれども、信頼性がある境界内のアプリケーションを、不正なプロセスが、強制的に終了させて、以前信頼されていたアプリケーションに成り済ますことが可能であることを意味する。最後に、拡張の繰り返しでは、複数のRIM証明書作成および格納によるオーバーヘッドがあり、ランタイムで、要求に応じてRIM証明書を作成するので、システムを攻撃する別の経路が与えられる。さらに、PCRでは、リソースが制限されている。非特許文献２の第50頁第5.3.2項では、セキュアブート中などデバイスメーカー向けに13個のPCRが確保されているが、最悪の場合、アプリケーション向けには、その他のPCRが3つしか残されていないため、複数のアプリケーションが互いに無関係な場合でも、複数のアプリケーション開発者間で、これらのPCRの使用の調整が重大な問題となる。
特許文献１では、指定されたPCRの無限の集合を管理するコンテキストを作成するという手段によってPCR数を増やす方法が開示されているが、RIM証明書の扱い方については考慮されていない。また、全ての仮想PCRを単一の物理的PCRに集約するという開示された方法は、RIM証明書を介して、仮想PCRの一部だけを、どのようにテストするのか、つまりRIM証明書の重要な面について教示していない。さらに、この方法では、単一の物理的PCRへ仮想PCRを集約することが、仮想PCRの存在を認識していないけれども他の目的でその物理的PCRを使用したいアプリケーションと互いに影響し合うことになるという問題をどのように回避するのか教示していない。その上、この方法では、拡張動作をどのようにして効率的に取り消すのか教示していない。ここで、拡張動作を取り消すとは、あるアプリケーションを終了する場合に、このアプリケーションと、この終了されるアプリケーションの従属アプリケーション全てとの周辺に広がる仮想PCRを利用することによって構築された信頼性の境界を、動的に縮小して、信頼性のあるアプリケーションの集合から、これらのアプリケーションを削除するといったことである。代わりに、この方法では、仮想PCRをリセットしてもよいとしか教示していないため、信頼性の境界を再構築する唯一の方法は、従属アプリケーションだけでなく、従属として終了アプリケーションを有する全てのアプリケーションも終了した後に、それら全てを再検証かつ再実行して、信頼性の境界を一から再構築することである。
したがって、１以上のモジュールが終了した後でも、信頼性のある境界に従って動的にPCRの値を変更かつ生成できる装置が必要である。
さらに、「Trusted Computing Group’s (TCG) Trusted Platform Module (TPM) documents」などの先導的な先行文献では、プラットフォームと特定のクライアント両方のリモート認証をどのように確立するか説明されている。セキュアブートプロセスによりプラットフォーム状態が保証されるので、プラットフォームの認証は必ずしも必要ではない。しかしながら、MTMベースのプラットフォーム上で実行するアプリケーションには、認証が対応していなかった。
したがって、動的に変化するPCRsの状態をサーバに認証させることができる装置がさらに必要である。
本発明の第１の形態における情報処理装置は、複数のモジュール各々に先立ってロードされるモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示すアクティブ情報を記録する管理手段と、前記アクティブモジュールの次のモジュールをロードする場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記次のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記次のモジュールをロードし、かつ、(iv)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する、ロード制御手段とを備えることを特徴とする情報処理装置である。
本発明は、一時的PCRs（transient PCR）を用いる環境で実行しているクライアントのリモート認証を実装する方法、システムおよびコンピュータプログラム製品に関する。
本発明では、tPCR（transient PCR） RIM証明書を用いる。クライアントは、認証用に用いるためのtPCR値を確立する基礎として、このtPCR RIM証明書を用いてスタートアップ時に自分自身を検証する。
この構成によると、情報処理装置は、複数のモジュールのうちで、どれがアクティブモジュールであるかを示す情報を管理し、そして、そのアクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成する。
したがって、当該情報処理装置は、アクティブモジュール全てに対応する蓄積プラットフォーム情報を生成することができる。ゆえに、ロード対象の第１モジュールの期待プラットフォーム情報と蓄積プラットフォーム情報とを比較して、検証を行うことによって、情報処理装置は、第１モジュールを正常にロードする前に、ロード対象の全てのモジュールを検証することができる。さらに、複数のモジュールのうちで、どれがアクティブモジュールであるかを管理することによって、１以上のモジュールが終了した後であっても、情報処理装置が、現在の信頼性の境界に従って（PCR値に対応する）蓄積プラットフォーム情報を動的に生成することができる。
（本願の技術的背景に関する情報）
２００８年１０月１０日に出願された、特願２００８−２６４５３０の日本出願の明細書、図面および特許請求の範囲等における開示の全体は、参照用として、本願に取り込まれる。
また、２００８年１２月１７日に出願された、特願２００８−３２１５４０の日本出願の明細書、図面および特許請求の範囲等における開示の全体も、参照用として、本願に取り込まれる。
図１は、先行技術を表すブロック図である。 図１Ａは、先行技術を表すブロック図である。 図２は、本発明を表すブロック図である。 図２Ａは、本発明を表すブロック図である。 図３は、PCRアクセスが期待されるモジュールを表すブロック図である。 図３Ａは、プラットフォーム状態証明書のツリーにおける関係を表すブロック図である。 図４は、プラットフォーム状態証明書の構造体を示す。 図５は、一時的PCRをサポートするための拡張を含んだRIM証明書の構造体を示す。 図６は、拡張PSCツリーノードの構造体を示す。 図７は、コンポーネント・PSCマップの構造体を示す。 図８は、先行技術にかかるプラットフォーム状態証明書のサンプルを示す。 図９は、本発明の一形態にかかるプラットフォーム状態証明書および図8に基づくプラットフォーム状態証明書の２つのサンプルを示す。 図１０は、アプリケーションの起動および終了中のモジュール間通信を示す。 図１１は、PSCを拡張するフローチャートである。 図１２は、PSCを拡張するフローチャートである。 図１３は、PSCを拡張するフローチャートである。 図１４は、取り消し前から取り消し後に拡張PSCツリーがどう変化するかを示したものである。 図１５は、PSCの拡張を取り消すフローチャートである。 図１６は、PSCの拡張を取り消すフローチャートである。 図１７は、アプリケーションのリモート認証でのモジュール間通信を示す図である。 図１８は、解決される問題を示す図である。 図１９は、tPCRを示す図である。 図２０は、情報処理装置による処理を示す図である。 図２１Ａは、先行技術を表すブロック図である。 図２１Ｂは、先行技術を表すブロック図である。 図２２Ａは、本発明を表すブロック図である。 図２２Ｂは、本発明を表すブロック図である。 図２３Ａは、PCRアクセスが期待されるモジュールを表すブロック図である。 図２３Ｂは、プラットフォーム状態証明書のツリーにおける関係を表すブロック図である。 図２４は、プラットフォーム状態証明書の構造体を示す。 図２５は、一時的PCRをサポートするための拡張を含んだRIM証明書の構造体を示す。 図２６は、拡張PSCツリーノードの構造体を示す。 図２７は、コンポーネント・PSCマップの構造体を示す。 図２８は、先行技術にかかるプラットフォーム状態証明書のサンプルを示す。 図２９は、本発明の一形態にかかるプラットフォーム状態証明書および図8に基づくプラットフォーム状態証明書の２つのサンプルを示す。 図３０は、アプリケーションの起動および終了中のモジュール間通信を示す。 図３１は、PSCを拡張するフローチャートである。 図３２は、PSCを拡張するフローチャートである。 図３３は、PSCを拡張するフローチャートである。 図３４は、取り消し前から取り消し後に拡張PSCツリーがどう変化するかを示したものである。 図３５は、PSCの拡張を取り消すフローチャートである。 図３６は、PSCの拡張を取り消すフローチャートである。 図３７Ａは、リモート認証の先行技術を表すブロック図である。 図３７Ｂは、リモート認証の先行技術を表すブロック図である。 図３８Ａは、リモート認証に対する本発明のその他の実施形態を表すブロック図である。 図３８Ｂは、リモート認証に対する本発明のその他の実施形態を表すブロック図である。 図３９は、アプリケーションがリモート認証している間のモジュール間通信を示す。 図４０は、Quote情報記録の構造体を示す。 図４１は、tPCRのみに対してアプリケーションがリモート認証している間のモジュール間通信を示す。
本発明の第１の形態における情報処理装置（装置１１２０）は、複数のモジュール各々に先立ってロードされるモジュールを示す期待プラットフォーム情報（tPCR値）を前記複数のモジュールごとに格納する格納手段（PSCデータベース1112）と、前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示すアクティブ情報を記録する管理手段（コンポーネント・PSCマップ1202）と、前記アクティブモジュールの次のモジュールをロードする場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報（PSCツリー1206の中にあるtPCR状態1604（図６））を生成し、(ii)前記次のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記次のモジュールをロードし、かつ、(iv)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する、ロード制御手段（OSサポート1200）とを備えることを特徴とする情報処理装置である。
図１８は、第１の形態の情報処理装置により解決される課題を説明する図である。
図１９は、tPCR(Transient PCR)を説明する図である。
図２０は、第１の形態の情報処理装置による処理を説明する図である。
なお、図１８では、遷移図1101Aが示される。また、図１９では、第１の形態の情報処理装置の処理を示す欄1101Baと、従来例の処理を示す欄1101Bbとが示される。
第１の形態の情報処理装置は、上述の通り、格納手段（PSCデータベース1112）と、管理手段（コンポーネント・PSCマップ1202）と、ロード制御手段（OSサポート1200）とを備える。これにより、図１９、図２０により示される機能が実現される。これにより、図１８により説明される課題が解決される効果が得られる。
他方、第１の形態の情報処理装置と対比される従来例では、上記３つの手段のうちの一部又は全部がない。このため、従来例では、図１９、図２０により示される機能が実現されず、図１８の課題が解決される効果が得られない。
すなわち、上記の構成、作用、効果を有するか否かの点で、第１の形態の情報処理装置は、従来例に対して相違する。
なお、実施形態の説明の第１部分における装置1120（図１）は、後述される、実施形態の説明の第２部分における装置2120（図２１Ａ）に対応する。そして、装置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”、及びその他の文献を含む。
本発明の第２の形態における情報処理装置は、前記ロード制御手段が、モジュールが終了する場合に、前記モジュールはアクティブモジュールでないと示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とする情報処理装置である。
この構成によると、第１モジュールが終了する場合に、ロード制御手段は管理手段を制御してアクティブ情報を更新し、その終了モジュールがアクティブモジュールでないことを示す。
したがって、当該情報処理装置は、１以上のモジュールが終了した後であっても、拡張されたプラットフォーム情報を用いて検証することにより、現在ロードされているモジュールに正確に対応するアクティブモジュール全ての蓄積プラットフォーム情報を生成することができる。
本発明の第３の形態における情報処理装置は、さらに、前記アクティブモジュールの次のモジュールをロードする場合に、前記次のモジュールのダイジェスト値（ハッシュ）を算出し、期待ダイジェスト値と算出したダイジェスト値とを比較することで前記次のモジュールが有効であるかどうかを判定する判定手段（抽象化レイヤAPI1108）を備え、前記ロード制御手段は、前記次のモジュールが有効であると判定され、検証手段による検証が成功した場合には、前記次のモジュールをロードし、前記アクティブモジュールのうちの１つが終了した後にアクティブモジュールが少なくとも１つ残っている場合であって、前記少なくとも１つの残ったアクティブモジュールの次のモジュールをロードする場合には、前記少なくとも１つの残ったアクティブモジュールのダイジェスト値の算出をスキップするよう算出手段を制御し、前記少なくとも１つの残ったアクティブモジュールの判定をスキップするよう前記判定手段を制御することを特徴とする情報処理装置である。
この構成によると、情報処理装置は、アクティブモジュールのうちの１つが終了した後にアクティブモジュールが少なくとも１つ残っている場合であって、少なくとも１つの残ったアクティブモジュールの次のモジュールをロードする場合に、アクティブモジュールのダイジェスト値の算出をスキップして、算出されたダイジェスト値を用いてアクティブモジュールを再び判定することをスキップする。
先行技術では、（この構成の蓄積プラットフォーム情報に対応する）PCR値をリセットまたは蓄積することしかできない。ゆえに、PCRを、それの以前の値に、モジュールが終了した後に戻すために、PCR値がリセットされなければならず、そこで、以前実行された各モジュールについて、それらのダイジェスト値を再計算して、それぞれのダイジェスト値をPCRに蓄積する。
一方、本発明の本形態では、情報処理装置が、どのモジュールがアクティブモジュールであるかを管理し、アクティブモジュールに対応する期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成する。ゆえに、アクティブモジュールのダイジェスト値の算出と、算出されたダイジェスト値を用いた判定とをスキップすることができる。これは、アクティブモジュールに対するこれらの処理が前もって行われており、それ以降はアクティブモジュールは変更されないことになっているからである。したがって、この構成により、第２モジュールのローディング処理を高速化することができる。
本発明の第４の形態における情報処理装置は、前記管理手段が、有向非巡回グラフを用いて前記アクティブモジュールを示す情報を管理することを特徴とする情報処理装置である。
この構成によると、管理手段は、有向非巡回グラフを用いてアクティブモジュールを示す情報を管理する。通常、複数のモジュールは他のモジュールに従属したり従属されたりしてロードされるので、有向非巡回グラフはこの関係を表現するのに適している。したがって、この構成によって、管理手段は、１以上のアクティブモジュールを容易に管理することができる。
本発明の第５の形態における情報処理装置は、前記ロード制御手段が、前記次のモジュールをロードする場合に、前記次のモジュールと当該次のモジュールの期待プラットフォーム情報とを示すノードを生成し、かつ、前記アクティブモジュールに対応するノードに、生成したノードが従属するように、前記生成したノードを前記有向非巡回グラフに付け加えるよう、前記管理手段を制御することを特徴とする情報処理装置である。
この構成によると、情報処理装置は、次のモジュールをロードする場合に、次のモジュールと当該次のモジュールの期待プラットフォーム情報とを示すノードを生成し、かつ、アクティブモジュールに対応するノードに、生成したノードが従属するように、生成したノードを有向非巡回グラフに付け加えるよう、管理手段を制御する。すなわち、非巡回グラフは、どのアクティブモジュールが他のアクティブモジュールに従属しているかを正しく反映するものとなる。したがって、この構成により、管理手段は、アクティブモジュール間の従属関係を正確に管理することができる。
本発明の第６の形態における情報処理装置は、前記ロード制御手段が、前記次のモジュールがロードされて終了した場合に、前記次のモジュールを示すノードと当該ノードに従属するノード全てとを削除するよう、前記管理手段を制御することを特徴とする情報処理装置である。
この構成によると、情報処理装置は、次のモジュールがロードされて終了した場合に、次のモジュールを示すノードと当該ノードに従属するノード全てとを削除するよう、管理手段を制御する。すなわち、終了したモジュールに対応するノードだけでなく、当該ノードに従属するノードも削除される。終了したモジュールのノードに従属するノードは終了モジュールの子モジュールに対応しており、その親モジュールの終了時に子モジュールは終了する。したがって、この構成により、管理手段は、複数のモジュールのうちどれを本当にロード中なのかを正確に管理することができる。
本発明の第７の形態における情報処理装置は、前記ロード制御手段が、前記次のモジュールを示すノードが従属することになっている親ノードを検索して、各ノードの期待プラットフォーム情報を前記有向非巡回グラフのルートから前記親ノードへ蓄積することによって前記蓄積プラットフォーム情報を生成することを特徴とする情報処理装置である。
この構成によると、ロード制御手段は、次のモジュールを示すノードが従属することになっている親ノードを検索して、各ノードの期待プラットフォーム情報を前記有向非巡回グラフのルートから親ノードへ蓄積することによって蓄積プラットフォーム情報を生成する。この構成によって、情報処理装置は、次のモジュールに先立ってブートするアクティブモジュールを反映した蓄積プラットフォーム情報を間違いなく生成することができる。これは、有向非巡回グラフがアクティブモジュール間の従属関係を反映するからである。
本発明の第８の形態における情報処理装置は、前記ロード制御手段が前記蓄積プラットフォーム情報を所定期間の後に削除することを特徴とする情報処理装置である。
この構成によると、ロード制御手段は、蓄積プラットフォーム情報を所定期間の後に削除する。したがって、この構成により、プラットフォーム情報の存続期間を制限することによって改ざんは困難になる。
本発明の第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モジュールグループと第2モジュールグループとを含み、前記情報処理装置は、さらに、前記第1モジュールグループのうち、どのモジュールをロードしたかを示す第1蓄積プラットフォーム情報を格納する登録手段を備え、前記格納手段は、さらに、前記第2モジュールグループのモジュールをロードする前に前記第1モジュールグループのモジュール全てをロードすべきことを示す第1期待プラットフォーム情報を格納し、前記ロード制御手段は、前記第1モジュールグループのモジュールに対して、(i)当該モジュールを検証し、(ii)検証が成功した場合には前記モジュールをロードし、かつ、(iii)前記モジュールがロードされた場合には前記モジュールのプラットフォーム情報を前記第1蓄積プラットフォーム情報に蓄積することによって前記第1蓄積プラットフォーム情報を更新し、前記第２モジュールグループのモジュールをロードする場合には、(i)前記第１期待プラットフォーム情報を前記登録手段に格納された第１蓄積プラットフォーム情報と比較することによって第１モジュールグループのモジュール全てが正常にロードされたことを検証し、前記アクティブモジュールに続く、第２モジュールグループの１のモジュールをロードする場合であって、前記第１モジュールグループのモジュール全てが正常にロードされたことが検証された場合には、前記ロード制御手段は、(i)第２モジュールグループのモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記１のモジュールの前記期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記１のモジュールをロードし、かつ、(iv)前記１のモジュールがロードされた場合には、前記１のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とする情報処理装置。
この構成によると、ロード制御手段は、(i)第１期待プラットフォーム情報を登録手段に格納された第１蓄積プラットフォーム情報と比較することによって第１モジュールグループのモジュール全てが正常にロードされたことを検証し、(ii)第１モジュールグループのモジュール全てが正常にロードされたことが検証された場合に、第２モジュールグループのモジュールに対して、生成、検証、ロードおよび制御を行う。
この構成により、情報処理装置は、第１モジュールグループに対する検証と第２モジュールグループに対する検証とを別々に行うことができる。したがって、当該情報処理装置は、第２モジュールグループのモジュールがいくつか終了しても、モジュール全ての検証を行う必要がない。
さらに、第２モジュールグループに対する処理は、第１モジュールに対する検証が失敗すれば、開始されない。したがって、たとえ第２モジュールグループに対する検証しか再度行わないとしても、第２モジュールグループのモジュールを、第１モジュールを含むモジュールが正常にロードされている信頼性のある環境上にロードすることができる。
本発明の第１１の形態における情報処理装置は、前記第２モジュールグループのモジュールが終了して第２モジュールグループのモジュールをロードする場合に、前記ロード制御手段は、前記第１期待プラットフォーム情報を前記第１蓄積プラットフォーム情報と比較することによって、前記第１モジュールグループのモジュール全てが正常にロードされ、かつ、終了していないことを検証し、検証が成功した場合には、前記第１モジュールグループのモジュールに対する検証をスキップすることを特徴とする情報処理装置である。
この構成によると、ロード制御手段は記第１期待プラットフォーム情報を第１蓄積プラットフォーム情報と比較することによって、第１モジュールグループのモジュール全てが正常にロードされ、かつ、終了していないことを検証し、検証が成功した場合には、第１モジュールグループのモジュールに対する検証をスキップする。
したがって、当該情報処理装置は、第２モジュールグループの終了されたモジュールを高速にリロードしたり、第２モジュールグループの他のモジュールを高速にロードすることができる。
本発明の第１２の形態における情報処理装置は、前記第１モジュールグループが、システム層のモジュールを含み、前記第２モジュールグループは、アプリケーション層のモジュールを含むことを特徴とする情報処理装置である。
この構成によると、第１モジュールグループは、システム層のモジュールを含み、第２モジュールグループは、アプリケーション層のモジュールを含む。
したがって、アプリケーション層のモジュールなど、頻繁に終了することになるモジュールに対する検証を、たとえそのモジュールが終了した後であっても、高速に再開することができる。
本発明の第１３の形態における情報処理方法は、情報処理装置用の情報処理方法であって、前記情報処理装置は、複数のモジュール各々に先立ってロードされるモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示すアクティブ情報を記録する管理手段とを備え、前記情報処理方法は、前記アクティブモジュールの次のモジュールをロードする場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記次のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記次のモジュールをロードし、かつ、(iv)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する、ロード制御ステップを備えることを特徴とする情報処理方法である。
本発明の第１４の形態におけるコンピュータプログラムは、情報処理装置用の記録媒体に記録されたコンピュータプログラムであって、前記情報処理装置は、複数のモジュール各々に先立ってロードされるモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示すアクティブ情報を記録する管理手段とを備え、前記コンピュータプログラムは、ロード制御ステップを前記情報処理装置に実行させるコンピュータプログラムであって、前記ロード制御ステップでは、前記アクティブモジュールの次のモジュールをロードする場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記次のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記次のモジュールをロードし、かつ、(iv)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とするコンピュータプログラムである。
本発明の第１５の形態における集積回路デバイスは、情報処理装置に用いられる集積回路デバイスであって、前記情報処理装置は、複数のモジュール各々に先立ってロードされるモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示すアクティブ情報を記録する管理手段とを備え、前記集積回路デバイスは、前記アクティブモジュールの次のモジュールをロードする場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記次のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記次のモジュールをロードし、かつ、(iv)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する、ロード制御手段を備えることを特徴とする集積回路デバイスである。
本発明の第１６の形態における情報処理装置は、当該情報処理装置は、サーバに接続され、前記ロード制御手段は、前記蓄積プラットフォーム情報を送信する要求を前記サーバから受信した場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、かつ、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記１のモジュールの前記期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)前記検証が成功した場合には、前記蓄積プラットフォーム情報を前記サーバに送信することを特徴とする情報処理装置である。
本発明の第１７の形態における情報処理装置は、前記ロード制御手段は、さらに、(i)前記蓄積プラットフォーム情報を生成するために、どの期待プラットフォームを用いるかを示す情報を生成し、(ii)前記情報に基づいて、前記蓄積プラットフォーム情報を検証するために用いる署名情報を生成し、(iii)前記署名情報が付加されている前記蓄積プラットフォーム情報を送信することを特徴とする情報処理装置である。
本発明の第１８の形態における情報処理装置は、請求項１６に記載の情報処理装置であって、前記ロード制御手段は、１のモジュールが終了する場合に、前記１のモジュールはアクティブモジュールでないと示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とする情報処理装置である。
本発明の第１９の形態における情報処理装置は、さらに、前記アクティブモジュールに続く１のモジュールをロードする場合に、前記１のモジュールのダイジェスト値を算出し、期待ダイジェスト値と算出したダイジェスト値とを比較することで前記１のモジュールが有効であるかどうかを判定する判定手段を備え、前記ロード制御手段は、前記１のモジュールが有効であると判定され、検証手段による検証が成功した場合には、前記１のモジュールをロードし、前記アクティブモジュールのうちの１つが終了した後にアクティブモジュールが少なくとも１つ残っている場合であって、前記少なくとも１つの残ったアクティブモジュールに続く１のモジュールをロードする場合には、前記少なくとも１つの残ったアクティブモジュールのダイジェスト値の算出をスキップするよう算出手段を制御し、前記少なくとも１つの残ったアクティブモジュールの判定をスキップするよう前記判定手段を制御することを特徴とする情報処理装置である。
本発明の第２０の形態における情報処理装置は、前記管理手段は、有向非巡回グラフを用いて前記アクティブモジュールを示す情報を管理することを特徴とする情報処理装置である。
本発明の第２１の形態における情報処理装置は、前記ロード制御手段は、前記１のモジュールをロードする場合に、前記１のモジュールと当該１のモジュールの前記期待プラットフォーム情報とを示すノードを生成し、かつ、従属する当該モジュールに対応するノードに、前記生成したノードが従属するように、前記生成したノードを前記有向非巡回グラフに付け加えるよう、前記管理手段を制御することを特徴とする情報処理装置である。
本発明の第２２の形態における情報処理装置は、前記ロード制御手段は、前記１のモジュールがロードされて終了した場合に、前記１のモジュールを示すノードと、前記１のモジュールを示す前記ノードに従属するノード全てとを削除するよう、前記管理手段を制御することを特徴とする情報処理装置である。
本発明の第２３の形態における情報処理装置は、前記ロード制御手段は、前記１のモジュールを示す前記ノードが従属することになっている親ノードを検索して、各ノードの期待プラットフォーム情報を前記有向非巡回グラフのルートから前記親ノードへ蓄積することによって前記蓄積プラットフォーム情報を生成することを特徴とする情報処理装置である。
本発明の第２４の形態における情報処理装置は、前記ロード制御手段は前記蓄積プラットフォーム情報を所定期間の後に削除することを特徴とする情報処理装置である。
本発明の第２５の形態における情報処理装置は、前記ロード制御手段は、前記複数のモジュールのうち１つが正常にロードされるたびに前記蓄積プラットフォーム情報を削除し、前記複数のモジュールのうち１つをロードすることになるたびに蓄積プラットフォーム情報を生成することを特徴とする情報処理装置である。
本発明の第２６の形態における情報処理装置は、前記複数のモジュールは、それぞれが１以上のモジュールを含む第１モジュールグループと第２モジュールグループとを含み、前記情報処理装置は、さらに、前記第１モジュールグループのうち、どのモジュールをロードしたかを示す第１蓄積プラットフォーム情報を格納する登録手段を備え、前記格納手段は、さらに、前記第２モジュールグループのモジュールをロードする前に前記第１モジュールグループのモジュール全てをロードすべきことを示す第１期待プラットフォーム情報を格納し、前記ロード制御手段は、前記第１モジュールグループのモジュールに対して、(i)当該モジュールを検証し、(ii)検証が成功した場合には前記モジュールをロードし、かつ、(iii)前記モジュールがロードされた場合には前記モジュールのプラットフォーム情報を前記第１蓄積プラットフォーム情報に蓄積することによって前記第１蓄積プラットフォーム情報を更新し、前記第２モジュールグループのモジュールをロードする場合には、(i)前記第１期待プラットフォーム情報を前記登録手段に格納された第１蓄積プラットフォーム情報と比較することによって第１モジュールグループのモジュール全てが正常にロードされたことを検証し、前記アクティブモジュールに続く、第２モジュールグループの１のモジュールをロードする場合であって、前記第１モジュールグループのモジュール全てが正常にロードされたことが検証された場合には、前記ロード制御手段は、(i)第２モジュールグループのモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記１のモジュールの前記期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)検証が成功した場合には前記１のモジュールをロードし、かつ、(iv)前記１のモジュールがロードされた場合には、前記１のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御することを特徴とする情報処理装置である。
本発明の第２７の形態における情報処理装置は、前記第２モジュールグループのモジュールが終了して第２モジュールグループのモジュールをロードする場合に、前記ロード制御手段は、前記第１期待プラットフォーム情報を前記第１蓄積プラットフォーム情報と比較することによって、前記第１モジュールグループのモジュール全てが正常にロードされ、かつ、まだ終了していないことを検証し、検証が成功した場合には、前記第１モジュールグループのモジュールに対する検証をスキップすることを特徴とする情報処理装置である。
本発明の第２８の形態における情報処理装置は、前記第１モジュールグループは、システム層のモジュールを含み、前記第２モジュールグループは、アプリケーション層のモジュールを含むことを特徴とする情報処理装置である。
本発明の第２９の形態における情報処理方法は、前記蓄積プラットフォーム情報を送信する要求をサーバから受信する受信ステップと、前記受信ステップにおいて前記要求を受信した場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、かつ、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記１のモジュールの期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)前記検証が成功した場合には、前記蓄積プラットフォーム情報を前記サーバに送信する、送信ステップとを含むことを特徴とする情報処理方法である。
本発明の第３０の形態におけるコンピュータプログラムは、のコンピュータプログラムであって、前記蓄積プラットフォーム情報を送信する要求をサーバから受信する受信ステップと、前記受信ステップにおいて前記要求を受信した場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、かつ、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記１のモジュールの前記期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)前記検証が成功した場合には、前記蓄積プラットフォーム情報を前記サーバに送信する送信ステップとを前記情報処理装置に実行させるためのコンピュータプログラムである。
本発明の第３１の形態における集積回路デバイスは、前記蓄積プラットフォーム情報を送信する要求をサーバから受信する受信部と、前記受信部が前記要求を受信した場合に、(i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、かつ、前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、(ii)前記１のモジュールの前記期待プラットフォーム情報を前記蓄積プラットフォーム情報と比較することによって、前記アクティブモジュールが正常にロードされたことを検証し、(iii)前記検証が成功した場合には、前記蓄積プラットフォーム情報を前記サーバに送信する、送信手段とを備えることを特徴とする集積回路デバイスである。
拡張動作を取り消しできるようにすることによって、アプリケーションがPCRの使用を希望する度に新たな証明書を作成するという問題を回避しながら、PCRおよびRIM証明書の手段で信頼性の境界を実行中のアプリケーションに拡張できるようにする方法が必要である。
さらに、既存のRIM証明書および管理ツールを活用するため、TCGが定義したようなRIM証明書の構造体を使用する方法も必要である。
さらに、２つのアプリケーションが気づかずに同じPCRを共有することによって生じる問題を防ぎつつ利用可能なPCR数を拡張する方法も必要である。
さらに、アプリケーションを起動および終了しながら、信頼性の境界を、動的、効果的かつ信頼的に拡大縮小できる方法も必要である。
本発明では、tPCRの状態について安全に問い合わせるRIM証明書をアプリケーションが使用できる、一時的なPCR（tPCR）の概念を実現することにより、当該技術分野の上記の制限に対処している。これらのtPCRの存続期間は、これらを使用するアプリケーションの存続期間ほど長くなく、必要であればより短い期間でもよい。本発明のtPCRは、物理的PCRとは全く異なるものであるため、tPCRを認識していないアプリケーションは、同じ環境で従来どおりに動作してもよい。
好ましい実施形態によると、本発明は、MTMを備えた装置において実現されるが、その他の同類の安全策をMTMの代用としてもよい。必要なキーコンポーネントとは、セキュア処理環境（SPE）と前述したPCRとプラットフォーム状態証明書（PSC）に署名するための検証キーとPSCのデータを認証および処理する方法である。先行技術で説明されたようなRIM証明書が、PSCの具体例である。
本発明の他の好ましい実施形態によると、アプリケーションが実行開始するときに、アプリケーションに関連付けられたPSCを記録し、そして、そのアプリケーションが終了するときに、記録されたPSCおよび従属しているもの全てによりそれらの拡張動作が取り消される。
他の好ましい実施形態によると、拡張動作が行われる場合には、有向非巡回グラフに拡張証明書が記録される。この有向非巡回グラフには、その拡張証明書が子として従属する、拡張済みの他の証明書全てが含まれる。この拡張動作は、拡張動作の有向非巡回グラフから、その拡張動作のレコードと全ての従属レコードとを削除することによって取り消される。
他の好ましい実施形態によると、拡張動作が必要な場合には、この証明書が従属する証明書は、すでに拡張済みの証明書の現在の有向非巡回グラフに基づき動的に評価される。
（第１の実施形態）
以下に、本発明の好ましい実施形態について説明する。
第１の実施形態は、一時的なPCRの利用をサポートするシステムに関し、この一時的なPCRは、証明書によって定められた値以外の定義済み存続期間を有する。前述の追加オペレーティングシステム機能およびPSCの信頼できる検証を行うことによって、SPE付き装置の開発者は、これらのtPCRを扱うシステムを作成できる。使用対象のtPCRについて記述するPSCを提供することによって、このような装置におけるアプリケーションの開発者は、信頼できる実行を柔軟な方法で提供するアプリケーションを作成できる。本発明によると、アプリケーションは、いずれかのコンポーネントタイプとして定義されるが、独立型のプログラムや独立型のプログラム用プラグインモジュールやプラグイン用ヘルパーモジュールに限定されるものではない。
図１に、「TCG Mobile Reference Architecture」に記載された手段などのシステムのセキュアブートをサポートする場合における先行技術を示す。標準実行環境において、抽象化レイヤAPI1102を使用するアプリケーション1100が存在する。破線は、上方の前述した標準実行モードと、下方のセキュアモードとの間のセキュアモードインターフェース1106を示す。標準実行モードとは、ほとんどのコンピュータシステムが提供するような通常の実行環境である。セキュアモードでは、標準実行環境からはアクセスできないメモリ空間において、許可されたソフトウェアに限り実行可能なセキュア実行環境を提供する。本発明の好ましい実施形態では、セキュアモードしか分からないキーのプライベート部分を有するソフトウェアを暗号化することによって、この許可が行われるが、ホワイトリストや証明書などその他の技術を用いても構わない。この実行環境は、必要に応じて他のモジュールとともに、セキュアブートモジュールとセキュア処理環境1114とを有する。上記のセキュアモードインターフェース1106は、セキュアブートの信頼性の境界1104であって、そのライン以下全てが、信頼性のある環境内となる。そのラインは、「TCG Mobile Trusted Module Specification」で定義されたように、検証および拡張を行うセキュアブートプロセス中に構築される。セキュアモードの抽象化レイヤAPI1108は、サービスに対する、通常モードからの要求を取り扱い、更なる処理のために、抽象化レイヤ1110にこれらの要求をわたす。抽象化レイヤのタスクの１つはPSCデータベース1112を管理することである。また、別のタスクとしては、物理的PCRs1116の操作など、セキュア処理環境1114へのアクセスを含む、セキュアブートコンポーネント1113が提供するサービスの要求を取り扱うことがある。また、セキュアブートコンポーネント1113も、PSCデータベース1112へのアクセスを要求する。セキュア処理環境1114は、ハードウェアまたはソフトウェアのいずれで実現されてもよいが、好ましい実装では、「Trusted Computing Group specifications」で定義されたようなモバイルトラステッドモジュールであり、別の好ましい実装では、トラステッドプラットフォームモジュールである。ソフトウェア処理環境1113は、ハードウェアまたはソフトウェアのいずれか、あるいは双方の組み合わせで実現されてもよい。そして、セカンダリRIC（Runtime Integrity Checker）モニタ1118が存在する。このモニタのタスクには、改ざんが行われたと思われる場合に、アプリケーション1100を終了させることが含まれる。これは、好ましい実装では、PSCに格納された基準ハッシュに対して現在のアプリケーションのハッシュを検証することによって実現される。この検証は、特定のイベントが発生した時あるいは定期的な間隔で行われてもよく、これらのRICモニタに階層があっても構わない。これらのRICモニタは、１以上の子RICモニタの完全性をチェックする各RICモニタレベルを有する。プライマリRICは図示されていないが、そのタスクは、システム全体に対するマスター検証ルートとして、例えばハイパーバイザなどの図示されたシステム外で次のことを実行することである。すなわち、プライマリRICは、１以上のコンポーネントに対する完全性チェックを一定間隔で行い、PSCに格納された基準ハッシュに対してこれらのコンポーネントハッシュを検証する。このプライマリRICモニタのコンポーネントのうち１つは、セカンダリRICを備える必要がある。「TCG Mobile Reference Architecture」では、これをPRMVA、すなわちPrimary Runtime Measurement Verification Agentと称しており、このPRMVAは、セカンダリRICモニタに相当するSRMVA、すなわちSecondary Runtime Measurement Verification Agentを有している。図示されたもの全ては装置1120に配置される。
セキュアモードは、システムプロセッサの単独実行モード、オペレーティングシステムカーネルモード、セキュリティコプロセッサ、仮想マシン、ハイパーバイザ、完全性チェックされたメモリなど、当業者にとって周知な数々の技術により実現されてもよい。各コンポーネントは、本発明の新規性を有する教示と効果を逸脱しない範囲で、１以上の記載されている技術またはその他の技術によって保護されても構わない。
当該先行技術のその他の実施形態では、セキュアモードインターフェース1106は、抽象化レイヤ1110とセキュア処理環境1114との間に配置される。当業者は、抽象化レイヤの実行に対してセキュアモードの完全な保護を必要とせず、上述したRICモニタが行う完全性保護のみを要するようなかたちで当該抽象化レイヤを実装してもよく、また、本発明を、完全性保護された環境に実装してもよいと分かるであろう。当該完全性保護は、ソフトウェアまたはハードウェア、あるいは双方の組み合わせで行われる。
図１Ａに、セキュアモードのサポートはないが、「TCG Specification Architecture Overview Revision 1.2 28 April 2004」に記載された手段などの独立したセキュア処理環境を有し、セキュアモードインターフェースが存在しない場合における先行技術のその他の実施形態を示す。セキュアモードインターフェースがないため、抽象化レイヤAPI1108は１つしか存在せず、セキュアブートコンポーネントの代わりに、トラステッド/セキュアブートコンポーネント1152が存在する。セカンダリRICモニタ1118は、セキュア処理環境1114以外のシステムにおける全てのコンポーネントをカバーできるように拡張され、このようにトラステッド/セキュアブートの信頼性の境界1150を確立する補助を行う。しかしながら、そうでない場合には、コンポーネントとそれらの役割は図１で説明した通りである。
図２に、図１の先行技術に基づいた本発明を示す。すでに述べたように、標準実行環境における抽象化レイヤAPI1102を使用するアプリケーション1100が存在する。破線は、上方の前述の標準実行モードと、下方のセキュアモードとの間のセキュアモードインターフェース1106を示す。上記のセキュアモードインターフェース1106は、先に述べたような実行前にコンポーネントを検証するプロセスによって構築されたセキュアブートの信頼性の境界1104であって、そのライン以下全てが信頼性のある環境内となる。OSサポート1200モジュールは、標準実行空間にあるが、信頼性のある境界内である。このモジュールは、どのアプリケーションが、起動前の検証にどの証明書を用いたかを示すマッピングを維持するためのコンポーネント・PSCマップ1202を管理する。セキュアモード内に、サービスに対する、通常モードからの要求を取り扱い、更なる処理のために抽象化レイヤ1110に、これらの要求をわたす抽象化レイヤAPI1108がある。抽象化レイヤのタスクの１つは、PSCデータベース1112を管理することであり、また別のタスクには、tPCRサポート1204を実装することがある。このサポートモジュールが、拡張されたけれども取り消されていないPSC全ての有向非巡回グラフを含む拡張PSCツリー1206データを維持する。さらに別のタスクは、物理的PCRs1116の操作など、セキュア処理環境1114へのアクセスを含む、セキュアブートコンポーネント1113が提供するサービスの要求を取り扱うことである。また、セキュアブートコンポーネント1113も、PSCデータベース1112へのアクセスを要求する。そして、セカンダリRIC（Runtime Integrity Checker）モニタ1118が存在し、そのタスクには、改ざんが行われたと思われる場合にアプリケーション1100を終了させることが含まれる。図示されたもの全ては装置1120に配置される。
先行技術と同様に、先行技術の好ましい実施形態では、セキュアモードインターフェース1106は、抽象化レイヤ1110とセキュア処理環境1114との間に配置される。当業者は、抽象化レイヤの実行に対してセキュアモードの完全な保護を必要とせず、上述したRICモニタが行う完全性保護のみを要するようなかたちで当該抽象化レイヤを実装してもよく、また、本発明を、完全性保護された環境に実装してもよいと分かるであろう。当該完全性保護は、ソフトウェアまたはハードウェア、あるいは双方の組み合わせで行われる。
セキュアモードは、システムプロセッサの単独実行モード、オペレーティングシステムカーネルモード、セキュリティコプロセッサ、仮想マシン、ハイパーバイザ、完全性チェック済みメモリなど、当業者にとって周知な数々の技術により実現されてもよい。各コンポーネントは、本発明の新規性を有する教示と効果を逸脱しない範囲で、１以上の記載されている技術またはその他の技術によって保護されても構わない。
また、当業者は、tPCRサポート1204と拡張PSCツリー1206とを、セキュア処理環境1114に移動させたものが、その他の実施形態であると分かるであろう。さらなる実施形態は、抽象化レイヤ1110が、セキュアモードインターフェース1106の外側になって、tPCRサポート1204と拡張PSCツリー1206が、セキュア処理環境1114の内側になるように、これらの他の実施形態を組み合わせたものである。
図２Ａに、セキュアモードのサポートはないが、「TCG Specification Architecture Overview Revision 1.2 28 April 2004」に記載された手段などの独立したセキュア処理環境を有し、セキュアモードインターフェースが存在しない場合における、図１Ａに基づく本発明のその他の実施形態を示す。セキュアモードインターフェースがないため、抽象化レイヤAPI1108は１つしか存在せず、セキュアブートコンポーネントの代わりに、トラスティッド/セキュアブートコンポーネント1152が存在する。セカンダリRICモニタ1118は、セキュア処理環境1114以外のシステム内における全てのコンポーネントをカバーできるように拡張され、このようにして、トラステッド/セキュアブートの信頼性の境界1150を確立する補助を行う。しかしながら、そうでない場合には、コンポーネントとそれらの役割は、図２で説明した通りである。
図３に、本発明にかかるPCRの２タイプの利用パターンを示す。まず、通常アプリケーション空間におけるアプリケーション階層を示す。第１マッシュアップ1300は、第１プラグイン1302と第２プラグイン1304とから、サービスを利用する。これらのプラグインは、第１アプリケーション1306と第２アプリケーション1308とがそれぞれ所有するものである。どちらのアプリケーションも、抽象化レイヤAPI1102からサービスを利用する。次に、セキュアモードインターフェース1106の反対側に、抽象化レイヤAPI1108のセキュアモードのサポートが存在する。これは、抽象化レイヤ1110とやり取りする。抽象化レイヤのタスクの１つは、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をどのように使用するか選択の自由度がある。しかしながら、図例のような場合には、第１マッシュアップ1300の開発者は、第１プラグイン1302と第２プラグイン1304の開発者達と調整して、どのtPCRをそれぞれ利用する予定か全員が把握できていると確認する必要があるであろう。
図３Ａに、拡張PSCツリー1206を示す。ノードの追加および削除方法については、後で述べる。図示された有向非巡回グラフは、図２に示したように拡張されているとしてtPCRサポートモジュール1204が記録したPSCを表している。図２に示されたモジュールとこの図の証明書との間には1対2の関係があり、信頼性の境界を拡張して、第１アプリケーション1306をカバーするには、先行技術で教示されているように、２つの証明書、つまり第１アプリケーション開始1350および第１アプリケーションロード1354が必要である。第２アプリケーション1308に対しては、第２アプリケーション開始1352および第２アプリケーションロード1356が必要である。第１プラグイン1302に対しては、第１プラグイン開始1358および第１プラグインロード1362、第２プラグイン1304に対しては、第２プラグイン開始1360および第２プラグインロード1364、第１マッシュアップ1300に対しては、第１マッシュアップ開始1366および第１マッシュアップロード1368が必要である。証明書間の矢印は、これらの証明書の従属関係を示している。従属関係は、各証明書の拡張時に各証明書が検出を期待するPCR状態により定義される。ツリーの各ノードの構造体は、図６において後ほど定義する。
図示したように、先行技術によると、各モジュールにはそのモジュールに関連付けられた２つの証明書があり、１つは、起動前にモジュールを検証するためにその親が使用し、もう１つは、期待された環境でモジュールが起動されたことを検証するためにモジュール自身が使用する。当業者は、モジュールごとに２つ以外の証明書を使用しても、本発明の範囲内であると分かるであろう。
図４に、プラットフォーム状態証明書1400（PSC）を示す。これは、そのプラットフォーム状態証明書が定める（物理的または一時的な）PCRで定義されるプラットフォームの状態と、プラットフォームの状態の検証がうまくいった時に、（物理的または一時的な）PCRへ拡張する値とを表す構造体である。これらの構造体を、PSCデータベース1112に格納してもよい。本構造体の第１フィールドは、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をチェックすべきか決定するのは、それを用いる状況である。この利点の１つは、セキュアブート用に証明書を作成する既存のツールを、アプリケーション空間用に証明書を作成するために再利用できることである。
好ましい実施形態では、検証用PCR状態1404の対リストを、テスト対象であるPCRインデックス1406を表すビットマップとPCR値1408の集合に対するハッシュとで置き換えてもよい。これは、RIM証明書に対して「TCG Mobile Trusted Module Specification」が定義した表示である。より複雑なチェックコードを費やせば、一時的なPCRを検証する証明書を変更することなく、このような表示を用いることが可能である。しかし、好ましい実施形態では、図５に図示された一時的PCR用RIM証明書1500を用いる。この構造体と図４のプラットフォーム状態証明書とのフィールドの関係および追加フィールドについて詳しく述べる。
ラベル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フィールドを格納する必要さえないと分かるであろう。
図６に、拡張PSCツリーノード1600を示す。これは、証明書１つの拡張を記録する構造体である。このノードの構造体では、図３Ａに図示したような各ノードの内容、つまり項目1350〜1368を詳しく説明している。拡張PSCツリー1206は、当該技術分野において周知の技術を用いて有向非巡回グラフを実装する。例えば、ブーストC++ライブラリには、ブーストグラフライブラリが含まれている。これは、上述した有向非巡回グラフなど様々なグラフの作成および操作をサポートする。このように、拡張PSCツリーノード1600は、グラフの各頂点に関連付けられる。拡張PSC名1602は、拡張されたプラットフォーム状態証明書1400のPSC名1402のフィールドである。tPCR状態1604は、このノードにおける現在の一時的PCR状態のキャッシュであり、このノードの先祖に当たる拡張済みのPSCから算出される。tPCR状態は、tPCRインデックス1606とtPCR値1608との対リストで構成される。当業者は、このデータの別の表現、例えば、用いたtPCRを表すビットマップでtPCRインデックス1606フィールドを置き換えるなどが存在すると分かるであろう。
図７に、OSサポートモジュール1200によって維持されたコンポーネント・PSCマップ1202を示す。このコンポーネント・PSCのマップ1202には、コンポーネントをPSCへマッピングするリスト1700が含まれる。このリストの各エントリーには、コンポーネントID1702と、拡張PSC名1704、つまりアプリケーションの起動前に拡張されたプラットフォーム状態証明書1400のPSC名1402フィールドとが含まれる。Windows（登録商標）ベースのプラットフォームにおける本発明の好ましい実施形態では、コンポーネントID1702は２つのフィールドから構成されている。第１フィールドは、プロセスID1706である。このプロセスIDは、GetCurrentProcessId()などのWin32APIによって決定されるような、コンポーネントが属するプロセスを一意的に表す識別子をもつ。第２フィールドはモジュールハンドル1708である。単独で実行可能なコンポーネントに対しては、このフィールドを必ず0に設定する。リンクライブラリとして実装されたコンポーネントに対しては、第１パラメータのDllMainエントリーポイントに渡されるように、ライブラリ用のHMODULEがこのフィールドに含まれる。この構造体の利用法については後で述べる。
「TCG Mobile Reference Architecture」によると、PCR0は、基礎を成すハードウェアプラットフォームの特徴を表す値を保持する。PCR1は、信頼性のルートを表す値を含む。PCR2は、エンジンロードイベントを表す値を含む。PCR3〜6および8〜12は、専有手段を含む。PCR13〜15はアプリケーションが自由に使用できる。セキュアブートが正しく行われたことをPCR0、1および2が期待通りに示すかどうかのテスト、PCR13が0に設定されたかどうかのテスト、そして、全てが正しければ新たな値をPCR13に拡張することをアプリケーションプログラマが希望したとする。図８に、先行技術にかかる、「第１アプリケーション開始」と名付けられたプラットフォーム状態証明書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 が存在する。
先行技術にかかる図８の証明書に関する問題として次のものがある。他のアプリケーションがPCR13を使用してしまった場合、検証用PCR状態1404はもはや正確ではなくなってしまうという問題がある。アプリケーションが終了して再起動する場合、1818と1820に定義した先に拡張された値によってPCR13は0以外の状態に設定されてしまい、検証用PCR状態1404はもはや正確ではなくなってしまうという問題がある。
しかしながら、本発明では、図８の証明書と類似の証明書は、アプリケーション自身と同じ時間または別々の時間で対象装置に展開するためにアプリケーション開発者によって、図９に示すような２つの証明書に分けられる。なぜ分けるかというと、既存の証明書により２つの異なるPCRセットを検証するためである。第１のセットにはセキュアブートプロセスの結果、つまり既知の不変な結果が含まれ、第２のセットには動的状態、つまりアプリケーションレベルの状態が含まれる。図８において、項目1802および1804は、ハードウェアプラットフォームを表す既知のセキュアブートPCR0の値を指している。項目1806および1808は、信頼性のルートを表す既知のセキュアブートPCR1の値を指し、項目1810および1812は、エンジンロードイベントを表す既知のセキュアブートPCR2の値を指している。また、項目1814および1816は、期待される前提条件を表す、ブート後のPCR13の望ましい値を指している。このように、アプリケーション開発者は、セキュア処理環境が管理する物理的PCR、すなわち本例ではPCR0、1および2をテストするために用いられる片方の証明書に既知のセキュアブートPCRの値を置くことによって、図８の単一証明書を図９に示した２つの証明書に分けてもよい。第２の証明書は、アプリケーション空間の一時的PCR、すなわち本例ではPCR13用に用いられる。
「第１アプリケーション開始（セキュアブート）」1900と名付けられた第１証明書によって、セキュア環境が正しいことを確保するため、セキュアブートプロセスがセットアップした物理的PCR（PCR0 1802、PCR1 1806およびPCR2 1810）はテストされる。ここで、拡張用PCRは、拡張がないことを示すために-1 1902に設定され、拡張用値1904はゼロという名目上の値である。この証明書は検証のみに使われる。そして、アプリケーションレベルでは、図３に示すように物理的PCRへの書き込みをやめ、一時的PCRを用いることによってより柔軟性が高まり、前述した当該技術分野における課題を回避することができる。「第１アプリケーション開始（一時的）」1920と名付けられた第２証明書によって、ゼロ 1816である一時的PCR13 1814はテストされ、同じレジスタ1818および1820に値を拡張する。tPCRのインデックス13を選択したことに特に意味はない。先行技術の状況とは異なり、tPCR0またはtPCR99が用いられやすいであろう。
図１０に、シーケンス図を示す。この図では、アプリケーション起動時には図９の２つの証明書、つまり一方が物理的PCRをテストする証明書であり、もう一方が、一時的PCRをテストする証明書を用い、アプリケーション終了時には、「第１アプリケーション開始（一時的）」1920の第２証明書を用いて、値をtPCRに拡張してからその拡張を取り消すという本発明にかかるイベントシーケンスを示す。相互に作用する６つのオブジェクト、11000、11002、11004、11006、11008および11010を図示している。まず、tPCR13 11000は、この例の状況における一時的PCR13の状態を表す。図６で説明したように、tPCRは、特定のメモリ位置というよりむしろ拡張PSCツリー1206のノードごとに記録されるが、本例においては理解しやすいよう、tPCR13 11000をそのような位置にあるかのごとく表す。次に、tPCRサポート11002が存在する。これは、tPCRを参照するPSCの取得と現在のtPCR状態の検証との処理を行い、有効であれば、証明書は拡張されたと記録する。SPE11004は、先行技術にかかるセキュア処理環境である。好ましい実施形態では、それはMTMである。抽象化レイヤ11006は、通常モードのアプリケーションからの要求を取り扱い、要求を他のモジュールにわたす。OS11008はオペレーティングシステムであり、ここでは、一時的PCRを正確にアップデートするようなアプリケーションの起動および終了の処理に関するシステムである。そして、アプリケーション11010は、任意のタスクを行うサンプルアプリケーションである。図１０のシーケンス図のプロセスは入れ子されてもよいので、アプリケーション11010は、例えば、アプリケーション実行11042が11014から始まるイベントシーケンスに従う別のアプリケーションの開始を含むような、PSCによって保護された他のアプリケーションの開始を要求するなどのアプリケーションであっても構わない。図を単純化するため、エラー処理については図示しないが、本発明から除外されるものではない。
まず最初に、tPCR13 11000は、0の値11012で始まる。本発明では、拡張PSCツリー1206のルートは、全tPCRを０に設定させた状態で始まるというのがルールである。当業者であれば、セキュアブートの完了後に物理的PCRの値でtPCRを初期化するというような他の初期値候補が可能だと分かるであろう。OS11008は、要求を検出してアプリケーション11010を起動するので、まず、起動しようとするアプリケーションによってどのPSCが用いられるのかを決定する11014。Windowsベースのオペレーティングシステムにおける好ましい実施形態では、実行ファイルに組み込まれたカスタムアセンブリが、使用する２つのPSCを特定する。そのアプリケーションは、改ざんから保護するためにマイクロソフトのストロングネームツールを用いて署名される。次に、11014で特定されたPSC、この図では「第１アプリケーション開始（セキュアブート）」および「第１アプリケーション開始（一時的）」を抽象化レイヤ11006に要求する11016、11018。そして、これら２つのPSCの検証が、抽象化レイヤAPIであるAL_VerifyPSCsAndExtendtPCRを呼び出す11020ことによって行われる。このAPIは、システムが開始したいアプリケーションを検証する２つのPSC、つまり、図９で示したような物理的PCR用のPSCおよび一時的PCR用のPSCを引数とする。まず、図の11024で表されたPSC「第１アプリケーション開始（セキュアブート）」を引数とした、SPEのAPIであるSPE_VerifyPSCStateを呼び出す11022。先行技術によれば、これによって、PSC自身のフォーマットおよび署名のチェックが行われ、そして、PSCの検証用PCRが物理的PCRの現在の値と一致することを検証する。先行技術によれば、PSCがプラットフォームに渡されると、セキュア処理環境1114に組み込まれたキーか、この組み込まれたキーによって正当であると検証されることのできるキーのいずれかでPSCは署名される。そして、有効であれば、セキュア処理環境1114が生成かつ安全に格納した他のキーで再び署名され、証明書はPSCデータベース1112に格納される。
本発明の好ましい実施形態によると、物理的PCRをチェックするPSCはオプショナルなので、ステップ11016および11018を省略してもよい。その他の好ましい実施形態によると、物理的PCRのチェック用のPSCがアプリケーション全てについて同じである場合、物理的PCR用のPSC１つを２つ以上の異なる一時的PCRのPSCが用いてもよい。
次に、SPEの他のAPI、すなわち、図の11030で表されたPSC「第１アプリケーション開始（一時的）」にパラメータを設定したSPE_VerifyPSCを呼び出す11026。先行技術によると、これによって、物理的レジスタに対してPCRの設定を検証せずとも、PSC自身のフォーマットおよび署名のチェックが行われる。そこで、tPCRサポートモジュール、すなわち、図の11030で表されたPSC「第１アプリケーション開始（一時的）」にパラメータを設定したAPIであるTPCR_VerifyPSCAndExtendを呼び出す11028。このAPIの最初のタスクは、拡張PSCツリー1206内の既存状態に対応する検証用PCR状態1404をチェックすることにより、PSCを拡張できることを検証する11032ことである。この動作の詳細については後で述べる。検証が正常に完了した時点で、このPSCにおける動作の成功が、拡張PSCツリーの正しい位置へその表示を付け加える11034ことによって記録される。この動作の詳細については後に述べる。このPSCをツリーへ付け加えたことによる結果の１つは、tPCR13 11000、つまり拡張対象のレジスタが、以前の値、この場合は０、とPCRから拡張するための値1030、つまり0xABCD1234とを連結したもののハッシュに設定されたレジスタの値を有することである。これは、合成ハッシュと呼ばれ、数式的には、tPCR13 = SHA-1（0xABCD1234と連結されたtPCR13）と書き込まれる。この動作は11036の構文 (+)=で表される。このように、環境が期待された状態であることを検証し、成功したことの記録が生成され、そして、制御がオペレーティングシステムに戻る。先行技術によると、11020におけるPSC検証の前の、更なる安全性の評価として、アプリケーションのハッシュを算出し、拡張するPSCに格納された基準値と比較する。本発明では、この値は、好ましい実施形態において0xABCD1234と表された、拡張用の値として、PSC「第１アプリケーション開始（一時的）」11030に格納される。しかしながら、このステップは図から省略されている。
アプリケーションを起動する際に、OSは、そのアプリケーションのプロセスIDを取得し、コンポーネント・PSCマップ1202に、この識別子と一時的レジスタ用の対応PSC、つまりPSC「第１アプリケーション開始（一時的）」とを記録する11038。マイクロソフトのWindows環境における好ましい実施形態では、本プロセスは、http://www.codeproject.com/KB/system/InterceptWinAPICalls.aspxのコードプロジェクトにおけるAndriy OriekhovのIntercepting WinAPI callsに記載されたようなプロセス作成プロセスを途中でインターセプトすることによって実装される。取得したプロセスハンドルは、プロセスID1706に変換され、そのフィールドに設定される。そして、モジュールハンドル1708を０に設定する。コンポーネントがダイナミックリンクライブラリである場合、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()の第１引数に設定する。
アプリケーションは起動されると11040、PSCに関連付けられた他のアプリケーションを起動またはtPCR自体を参照する他のPSCを拡張したとしても、プログラムされたように実行し続ける11042。そして、アプリケーションを閉じるとユーザが選択する、クラッシュする、または、アプリケーションを強制的にシャットダウンするセカンダリRICモニタ（この図では図示していない）が改ざんを検出するといういずれかの原因で、アプリケーションは終了する11044。
アプリケーションが終了するので、OSはアプリケーションのプロセスIDを取得し、そのプロセスIDと0であるモジュールハンドルとを用いて、コンポーネントID1702を作成する。このコンポーネントIDを用いてコンポーネント・PSCマップ1202を検索し、アプリケーションを起動するのに用いられたPSCを見つける11046。これにより、PSC「第１アプリケーション開始（一時的）」11030が返されるので、取り消しを行うため、OSは、抽象化レイヤ11006のAPIであるAL_UndoPSCExtendを、PSCを引数として呼び出す11048。コンポーネントがダイナミックリンクライブラリである場合、上述したようにFreeLibrary() APIをフックするので、そのルーチン内で現在のプロセスIDを問い合わせ、FreeLibrary()のパラメータからモジュールハンドルを取得し、そしてこれら２つのデータ項目を用いて、コンポーネントID1702を作成する。このコンポーネントIDを用いてコンポーネント・PSCマップ1202を検索し、ライブラリを起動するのに用いられたPSCを見つける。前述と同様に、SPEの他のAPI、すなわち、図の11030で表されたPSC「第１アプリケーション開始（一時的）」にパラメータを設定したSPE_VerifyPSCを呼び出す11026。先行技術によると、これによって、物理的レジスタに対してPCRの設定を検証せずとも、PSC自身のフォーマットおよび署名のチェックが行われる。そこで、tPCRサポートモジュール11002、すなわち、図の11030で表されたPSC「第１アプリケーション開始（一時的）」にパラメータを設定したAPIであるTPCR_VerifyPSCAndExtendを呼び出す11050。このAPIの最初のタスクは、拡張PSCツリー1206にそのPSCがすでに存在するかどうか確認することによって、PSCが拡張されたことを検証する11052ことである。検証が正常に完了した時点で、これは、11028における拡張動作を取り消すことが可能であることを意味する。これは、拡張PSCツリー11034から、PSCを表すノードおよびそれに従属する他のノード全てを削除することによって実現される。この動作の詳細は後で述べる。ツリーからこのPSCを削除することの結果の１つは、tPCR13 11000、つまり取り消す対象のレジスタが効率よくその状態を0にリセットされる11056ことである。このように、環境が期待した状態であることを検証し、拡張PSCツリーからノードを削除する11034ことによって先に拡張された動作を取り消し、制御がオペレーティングシステムに戻り、本システムは他の動作をすぐに実行することができる。当業者であれば、これらの他の実行動作の１つとして、終了したアプリケーションを再起動することもあると分かるであろう。tPCR13が11056において00…00、つまり11012で示されたtPCR用の開始値にリセットされた後は、アプリケーションの開始PSC11030の検証は２回目も正常に再実行されるので、本発明によると、アプリケーションを再起動することができる。
図１０に、実行ファイルの起動および終了時に信頼性の境界を動的に拡張かつ縮小するシーケンス図を示す。注釈を用いて、好ましい実施形態に沿ったダイナミックリンクライブラリに対する同様のタスクを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クラスを用いて検証してもよい。この場合、好ましい実施形態において、図７に示されたモジュールハンドル1708は、コンポーネントを含むJARファイルを参照するハンドルである。
図１１に、tPCRサポートモジュール11002のAPI、TPCR_VerifyPSCAndExtend 11028の詳細に関するフローチャートを示す。本関数は、検証および記録するためのPSCをパラメータとしてわたして11100で開始し、次の図１２で示す、拡張PSCツリーの各ノードに対してtPCR状態を算出する11102サブルーチンを呼び出す。次に、現在のtPCR状態とソリューションリストの変数とを、NULLに初期化する11104。これら２つの変数の利用法については図１３で説明する。そして、渡されたPSCのtPCR値に、現在の拡張PSCツリーに記述された状態から達することができることを検証するサブルーチンが呼び出される11106。戻りコードをテストすることで、本関数が、拡張PSCツリー内で、渡されたPSCが保持する検証用の状態にtPCRを設定したノードを１以上見つけたかどうか分かる11108。この設定された親が見つからなかった場合、プロセスは、呼び出しルーチンへ拡張できなかったことを示すエラーコードを返す11110。見つかった場合は、渡されたPSCを、ソリューションリストに記述されたノードに設定した先のPSCを有する拡張PSCツリーに付け加え11112、プロセスは、呼び出しルーチンにサクセスコードを返す11114。
図１２に、図６における拡張PSCツリーの各ノードのtPCR状態1604をどのように算出するか説明するフローチャートを示す。当該フローチャートは引数なしに呼び出され11200、行きがけ順に拡張PSCツリーの走査を行う11202ことで処理が開始する。この走査は、ツリーのノードを続く処理にとって望ましい順序で収集するためにルートから始まる。好ましい実装では、ブーストグラフライブラリ関数breadth_first_search()を用いてこれらのノードを収集する。次に、記録されている各ノード11204に対し、深さ優先走査によって現在のtPCR状態1604をNULLに設定する11206。セキュアブート完了の際に定義されたtPCRの開始値、好ましい実施形態では０の値、に初期化されたtPCRを検証する証明書の特別処理が必要なので、現在の証明書に格納された検証用PCR状態1404のtPCR対ごとに、その値をセキュアブート完了の際に定義されたtPCR初期値、好ましい実施形態では０の値と照合する11210。それらが等しい場合は、tPCRのインデックスおよび値の対をこのノードのtPCR状態に付け加え11212、次のtPCRに対してループを続ける。そうでない場合は、ノードのtPCR状態を付け加えずにループを続ける。各tPCRをチェックすると、本関数は、現在のノードの親それぞれに対するループへと移行する11214。親ノードが拡張PSCツリーのルートノードであれば11216、前回のループがこの特殊ケースを処理したため、何も行われない。そうでない場合には、親ノードのtPCR状態1604を問い合わせ、コピーする11218。親の拡張PSC名1602により参照されるPSCによって定義された拡張動作が親の状態のコピー11220において行われ、その結果のtPCR状態が現在のノードのtPCR状態に付加される11222。この拡張PSCツリー構築方法により、２つの親が同じtPCRに対して異なる値を指定する事態は決しておこらない。そのため、当業者は、この状況をチェックする必要はないが、検証目的で実装してもよいと分かるであろう。tPCR状態の収集は、前述したように、全ての親に対して繰り返され、終了すれば、走査中の次のノード11204が処理される。このように各ノードが処理されると、各ノードのtPCR状態を返してプロセスは終了する11224。
当業者は、例えばbfs_visitor’s examine_vertex()でステップ11204から11222を実行するなど、上記アルゴリズムを実行する別の方法が存在するので、ノードの別々のリストの必要性はなくなると分かるであろう。さらに、この関数は、PSC関連の動作が行われるたびに呼び出されるが、その値をキャッシュして再計算にかかる労力を削減してもよい。
図１３に、ノードごとの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。先行技術に従ってこれらのノードをどのように取得できるかは図１２の説明で示した。まず、２つの構造体において一致する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。
図１４に、取り消し前と取り消し後のサンプル拡張PSCツリー1206の状態を示す。取り消し前の状態11400は図３Ａで述べたとおり、図３のモジュールツリーから構築された状態である。ところで、図１０で示されたように、ユーザからの作用、プログラムバグ、または改ざん検出により第１プラグインが終了すれば、オペレーションシステムは第１プラグインの終了を検出して、「第１プラグイン開始」証明書1358は起動時にテストされたPSCであったと判断するので、証明書の拡張を取り消す必要がある。「第１プラグイン開始」1358とともに、それに従属する全ての証明書、すなわち、「第１プラグインロード」1362、「第１マッシュアップ開始」1366および「第１マッシュアップロード」1368も拡張PSCツリー1206から削除しなければならない。その結果、取り消し後の状態11402の拡張PSCツリー1206となる。
図１５に、拡張プロセスをどのようにして取り消すか説明するフローチャートを示す。本関数は、引数として、取り消し対象PSCをとる11500。まず、本関数は、上記の図１２で示された、拡張PSCツリーのノードごとにtPCR状態を算出する11502サブルーチンを呼び出す。次に、対象PSCのPSC名1402とツリー内の各ノードの拡張PSC名1602との一致を探すことで、拡張PSCツリー内で対象PSCへの参照を検索する11504。一致するノードが見つからない場合11506、エラーコードを呼び出し側に返して取り消すことができなかったことを示す11512。次に、対象PSCの検証用PCR状態1404を見つかったノードのtPCR状態1604とを比較する。それらの状態が等しくない場合11510、エラーコードを呼び出し側に返して取り消すことができなかったことを示す11512。状態が等しい場合は、見つかったノードとそれに従属するもの全てを削除する関数を呼び出し、その関数がサクセスコードを呼び出し側に返す11516。
図１６に、取り消し処理が拡張PSCツリーからどのようにしてノードを削除するか説明するフローチャートを示す。本関数は、引数として、ツリーから削除するノードをとる11600。まず、このノードの子PSC全てに対してループし11602、再帰的に自分自身を呼び出してその子それぞれを順に削除する11604。全ての子が削除された時点で、ノード自身を削除し11606、本関数はリターンする11608。このようにして、終了中のモジュールおよびそれに従属する信頼性のあるモジュール全てをカバーする、以前の拡張処理によって確立された信頼性の境界は、終了する必要のないモジュールをカバーしたまま、装置のアプリケーション空間における信頼性レベルを落とすことなく、終了するモジュールを除外するように縮小される。
図１７に、アプリケーションがリモート認証する間のモジュール間通信について説明するシーケンス図を示す。相互に作用する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は、図１０で述べたようなプロセス空間の情報を用いて、どのアプリケーションまたはダイナミックロードライブラリが関数を呼び出したのかと、モジュールがどの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仕様書に固有なものであるため、省略してもよい。
(２)上述の実施形態では、証明書(RIM証明書)内でハッシュ値を使用することにより検証は行われた。しかしながら、ハッシュ値を使用しない他の検証方法が本発明に適用されてもよい。
従来のチェックサムや、コンポーネントから抽出される別のデータ(例えば、コンポーネントから抽出される第１所定ビット)が、検証を行うために使用されてもよい。また、証明書は、完全性チェック値を含むデータの集合に置き換えられてもよい。
さらに、検証方法は、コンポーネントから抽出される値と期待される値が等しいか否かをチェックすることに限定されない。例えば、コンポーネントのサイズを確認し、もしサイズが所定量より大きいか、または小さいなら、コンポーネントは検証されたと判断されるとしてもよい。これらの検証方法は、ハッシュ値と、その期待値とを比較するほど厳密なものではないが、それよりも高速に行われる。
（３）上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
（４）上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムLSIは、その機能を達成する。
さらに、各装置を構成する構成部品の各ユニットは、別個の個別チップとして、または、一部もしくは全てを含む単一のチップとして作られてもよい。
さらに、ここでは、LSIが述べられているが、集積化の程度の違いにより、指定IC、LSI、スーパLSI、ウルトラLSIが使用される場合もある。
さらに、回路の集積化の手段は、LSIに限定されるものではなく、専用回路、もしくは汎用プロセッサによる実装も利用できる。さらに、LSIが製造された後にプログラム可能なフィールドプログラムゲートアレイ(FPGA)を使用することもまた可能であり、またLSI内で回路セルの接続および設定を再構成可能なリコンフィギュアラブルプロセッサも使用可能である。
さらに、もしLSIに置き換わる集積回路技術が半導体技術もしくは他の派生する技術の進歩を通じて現われるのであれば、その技術は当然に構成要素の集積化を実現するために使用することができる。バイオ技術の適用が予想される。
（５）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩに含まれるとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
（６）本発明は、上記に示す方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムなどのデジタル信号であるとしてもよい。
また、本発明は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray Disc）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。
また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記憶しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。
また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
（７）本技術分野の当業者にとっては、説明した実施形態の、本発明固有の教示および利点から原理的に離れることのない多くの変形がありえることを容易に理解することができるだろう。また、上記変更および実施形態の任意の組み合わせは、本発明の範囲内に含まれる。
（第２の実施形態）
以下に、本発明の好ましい実施形態について説明する。
第２の実施形態は一時的なPCRの利用をサポートするシステムに関し、この一時的なPCRは、証明書によって定められた値以外の定義済み存続期間を有する。前述の追加オペレーティングシステム機能およびPSCの信頼できる検証を行うことによって、SPE付き装置の開発者はこれらのtPCRを扱うシステムを作成できる。使用対象のtPCRについて記述するPSCを提供することによって、このような装置におけるアプリケーションの開発者は、信頼できる実行を柔軟な方法で提供するアプリケーションを作成できる。本発明によると、アプリケーションはいずれかのコンポーネントタイプとして定義されるが、独立型のプログラムや独立型のプログラム用プラグインモジュールやプラグイン用ヘルパーモジュールに限定されるものではない。
図２１Ａに、「TCG Mobile Reference Architecture」に記載された手段などのシステムのセキュアブートをサポートする場合における先行技術を示す。標準実行環境において、抽象化レイヤAPI2102を使用するアプリケーション2100が存在する。破線は、上方の前述した標準実行モードと下方のセキュアモードとの間のセキュアモードインターフェース2106を示す。標準実行モードとは、ほとんどのコンピュータシステムが提供するような通常の実行環境である。セキュアモードでは、標準実行環境からはアクセスできないメモリ空間において、許可されたソフトウェアに限り実行可能なセキュア実行環境を提供する。本発明の好ましい実施形態では、セキュアモードしか分からないキーのプライベート部分を有するソフトウェアを暗号化することによってこの許可が行われるが、ホワイトリストや証明書などその他の技術を用いても構わない。この実行環境は、必要に応じて他のモジュールとともに、セキュアブートモジュールとセキュア処理環境2114とを有する。上記のセキュアモードインターフェース2106はセキュアブートの信頼性の境界2104であって、そのライン以下全てが信頼性のある環境内となる。そのラインは、「TCG Mobile Trusted Module Specification」で定義されたように検証および拡張を行うセキュアブートプロセス中に構築される。セキュアモードの抽象化レイヤAPI2108は、サービスに対する通常モードからの要求を取り扱い、更なる処理のために抽象化レイヤ2110にこれらの要求をわたす。抽象化レイヤのタスクの１つはPSCデータベース2112を管理することである。また別のタスクとしては、物理的PCRs2116の操作など、セキュア処理環境2114へのアクセスを含む、セキュアブートコンポーネント2113が提供するサービスの要求を取り扱うことがある。また、セキュアブートコンポーネント2113もPSCデータベース2112へのアクセスを要求する。セキュア処理環境2114は、ハードウェアまたはソフトウェアのいずれで実現されてもよいが、好ましい実装では、「Trusted Computing Group specifications」で定義されたようなモバイルトラステッドモジュールであり、別の好ましい実装では、トラステッドプラットフォームモジュールである。ソフトウェア処理環境2113は、ハードウェアまたはソフトウェアのいずれか、あるいは双方の組み合わせで実現されてもよい。そして、セカンダリRIC（Runtime Integrity Checker）モニタ2118が存在する。このモニタのタスクには、改ざんが行われたと思われる場合にアプリケーション2100を終了させることが含まれる。これは、好ましい実装では、PSCに格納された基準ハッシュに対して現在のアプリケーションのハッシュを検証することによって実現される。この検証は、特定のイベントが発生した時あるいは定期的な間隔で行われてもよく、これらのRICモニタに階層があっても構わない。これらのRICモニタは１以上の子RICモニタの完全性をチェックする各RICモニタレベルを有する。プライマリRICは図示されていないが、そのタスクは、システム全体に対するマスター検証ルートとして、例えばハイパーバイザなどの図示されたシステム外で次のことを実行することである。すなわち、プライマリRICは、１以上のコンポーネントに対する完全性チェックを一定間隔で行い、PSCに格納された基準ハッシュに対してこれらのコンポーネントハッシュを検証する。このプライマリRICモニタのコンポーネントのうち１つはセカンダリRICを備える必要がある。「TCG Mobile Reference Architecture」では、これをPRMVA、すなわちPrimary Runtime Measurement Verification Agentと称しており、このPRMVAは、セカンダリRICモニタに相当するSRMVA、すなわちSecondary Runtime Measurement Verification Agentを有している。図示されたもの全ては装置2120に配置される。
セキュアモードは、システムプロセッサの単独実行モード、オペレーティングシステムカーネルモード、セキュリティコプロセッサ、仮想マシン、ハイパーバイザ、完全性チェックされたメモリなど、当業者にとって周知な数々の技術により実現されてもよい。各コンポーネントは、本発明の新規性を有する教示と効果を逸脱しない範囲で、１以上の記載されている技術またはその他の技術によって保護されても構わない。
当該先行技術のその他の実施形態では、セキュアモードインターフェース2106は抽象化レイヤ2110とセキュア処理環境2114との間に配置される。当業者は、抽象化レイヤの実行に対してセキュアモードの完全な保護を必要とせず、上述したRICモニタが行う完全性保護のみを要するようなかたちで当該抽象化レイヤを実装してもよく、また、本発明を、完全性保護された環境に実装してもよいと分かるであろう。当該完全性保護は、ソフトウェアまたはハードウェア、あるいは双方の組み合わせで行われる。
図２１Ｂに、セキュアモードのサポートはないが、「TCG Specification Architecture Overview Revision 1.2 28 April 2004」に記載された手段などの独立したセキュア処理環境を有し、セキュアモードインターフェースが存在しない場合における先行技術のその他の実施形態を示す。セキュアモードインターフェースがないため、抽象化レイヤAPI2108は１つしか存在せず、セキュアブートコンポーネントの代わりに、トラステッド/セキュアブートコンポーネント2152が存在する。セカンダリRICモニタ2118は、セキュア処理環境2114以外のシステムにおける全てのコンポーネントをカバーできるように拡張され、このようにトラステッド/セキュアブートの信頼性の境界2150を確立する補助を行う。しかしながら、そうでない場合には、コンポーネントとそれらの役割は図２１Ａで説明した通りである。
図２２Ａに、図２１Ｂなどの先行技術に基づいた本発明の第２の実施形態を示す。すでに述べたように、標準実行環境における抽象化レイヤAPI2102を使用するアプリケーション2100が存在する。破線は、上方の前述の標準実行モードと下方のセキュアモードとの間のセキュアモードインターフェース2106を示す。上記のセキュアモードインターフェース2106は、先に述べたような実行前にコンポーネントを検証するプロセスによって構築されたセキュアブートの信頼性の境界2104であって、そのライン以下全てが信頼性のある環境内となる。OSサポート2200モジュールは、標準実行空間にあるが、信頼性のある境界内である。このモジュールは、どのアプリケーションが起動前の検証にどの証明書を用いたかを示すマッピングを維持するためのコンポーネント・PSCマップ2202を管理する。セキュアモード内に、サービスに対する通常モードからの要求を取り扱い、更なる処理のために抽象化レイヤ2110にこれらの要求をわたす抽象化レイヤAPI2108がある。抽象化レイヤのタスクの１つは、PSCデータベース2112を管理することであり、また別のタスクにはtPCRサポート2204を実装することがある。このサポートモジュールが、拡張されたけれども取り消されていないPSC全ての有向非巡回グラフを含む拡張PSCツリー2206データを維持する。さらに別のタスクは、物理的PCRs2116の操作など、セキュア処理環境2114へのアクセスを含む、セキュアブートコンポーネント2113が提供するサービスの要求を取り扱うことである。また、セキュアブートコンポーネント2113もPSCデータベース2112へのアクセスを要求する。そして、セカンダリRIC（Runtime Integrity Checker）モニタ2118が存在し、そのタスクには、改ざんが行われたと思われる場合にアプリケーション2100を終了させることが含まれる。図示されたもの全ては装置2120に配置される。
先行技術と同様に、先行技術の好ましい実施形態では、セキュアモードインターフェース2106は抽象化レイヤ2110とセキュア処理環境2114との間に配置される。当業者は、抽象化レイヤの実行に対してセキュアモードの完全な保護を必要とせず、上述したRICモニタが行う完全性保護のみを要するようなかたちで当該抽象化レイヤを実装してもよく、また、本発明を、完全性保護された環境に実装してもよいと分かるであろう。当該完全性保護は、ソフトウェアまたはハードウェア、あるいは双方の組み合わせで行われる。
セキュアモードは、システムプロセッサの単独実行モード、オペレーティングシステムカーネルモード、セキュリティコプロセッサ、仮想マシン、ハイパーバイザ、完全性チェック済みメモリなど、当業者にとって周知な数々の技術により実現されてもよい。各コンポーネントは、本発明の新規性を有する教示と効果を逸脱しない範囲で、１以上の記載されている技術またはその他の技術によって保護されても構わない。
また、当業者は、tPCRサポート2204と拡張PSCツリー2206とをセキュア処理環境2114に移動させたものがその他の実施形態であると分かるであろう。さらなる実施形態は、抽象化レイヤ2110がセキュアモードインターフェース2106の外側になって、tPCRサポート2204と拡張PSCツリー2206がセキュア処理環境2114の内側になるように、これらの他の実施形態を組み合わせたものである。
図２２Ｂに、セキュアモードのサポートはないが、”TCG Specification Architecture Overview Revision ”に記載された手段などの独立したセキュア処理環境を有し、セキュアモードインターフェースが存在しない場合における、図２１Ｂに基づいた本発明の第２の実施形態の変形例を示す。セキュアモードインターフェースがないため、抽象化レイヤAPI2108は１つしか存在せず、セキュアブートコンポーネントの代わりに、トラスティッド/セキュアブートコンポーネント2152が存在する。セカンダリRICモニタ2118は、セキュア処理環境2114以外のシステム内における全てのコンポーネントをカバーできるように拡張され、このようにしてトラステッド/セキュアブートの信頼性の境界2150を確立する補助を行う。しかしながら、そうでない場合には、コンポーネントとそれらの役割は図２２Ａで説明した通りである。
図２３Ａに、本発明にかかるPCRの2タイプの利用パターンを示す。まず、通常アプリケーション空間におけるアプリケーション階層を示す。第１マッシュアップ2300は、第１プラグイン2302と第２プラグイン2304とからサービスを利用する。これらのプラグインは第１アプリケーション2306と第２アプリケーション2308とがそれぞれ所有するものである。どちらのアプリケーションも抽象化レイヤAPI2102からサービスを利用する。次に、セキュアモードインターフェース2106の反対側に、抽象化レイヤAPI2108のセキュアモードのサポートが存在する。これは抽象化レイヤ2110とやり取りする。抽象化レイヤのタスクの１つは、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をどのように使用するか選択の自由度がある。しかしながら、図例のような場合には、第１マッシュアップ2300の開発者は、第１プラグイン2302と第２プラグイン2304の開発者達と調整して、どのtPCRをそれぞれ利用する予定か全員が把握できていると確認する必要があるであろう。
図２３Ｂに、拡張PSCツリー2206を示す。ノードの追加および削除方法については、後で述べる。図示された有向非巡回グラフは、図２２Ａに示したように拡張されているとしてtPCRサポートモジュール2204が記録したPSCを表している。図２２Ａに示されたモジュールとこの図の証明書との間には1対2の関係があり、信頼性の境界を拡張して第１アプリケーション2306をカバーするには、先行技術で教示されているように、２つの証明書、つまり第１アプリケーション開始2350および第１アプリケーションロード2354が必要である。第２アプリケーション2308に対しては、第２アプリケーション開始2352および第２アプリケーションロード2356が必要である。第１プラグイン2302に対しては、第１プラグイン開始2358および第１プラグインロード2362、第２プラグイン2304に対しては、第２プラグイン開始2360および第２プラグインロード2364、第１マッシュアップ2300に対しては、第１マッシュアップ開始2366および第１マッシュアップロード2368が必要である。証明書間の矢印は、これらの証明書の従属関係を示している。従属関係は、各証明書の拡張時に各証明書が検出を期待するPCR状態により定義される。ツリーの各ノードの構造体は、図２６において後ほど定義する。
図示したように、先行技術によると、各モジュールにはそのモジュールに関連付けられた２つの証明書があり、１つは、起動前にモジュールを検証するためにその親が使用し、もう１つは、期待された環境でモジュールが起動されたことを検証するためにモジュール自身が使用する。当業者は、モジュールごとに２つ以外の証明書を使用しても本発明の範囲内であると分かるであろう。
図２４に、プラットフォーム状態証明書2400（PSC）を示す。これは、そのプラットフォーム状態証明書が定める（仮想的または一時的な）PCRで定義されるプラットフォームの状態と、プラットフォームの状態の検証がうまくいった時に（仮想的または一時的な）PCRへ拡張する値とを表す構造体である。これらの構造体をPSCデータベース2112に格納してもよい。本構造体の第１フィールドは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をチェックすべきか決定するのは、それを用いる状況である。この利点の１つは、セキュアブート用に証明書を作成する既存のツールを、アプリケーション空間用に証明書を作成するために再利用できることである。
好ましい実施形態では、検証用PCR状態2404の対リストを、テスト対象であるPCRインデックス2406を表すビットマップとPCR値2408の集合に対するハッシュとで置き換えてもよい。これは、RIM証明書に対して「TCG Mobile Trusted Module Specification」が定義した表示である。より複雑なチェックコードを費やせば、一時的なPCRを検証する証明書を変更することなく、このような表示を用いることが可能である。しかし、好ましい実施形態では、図２５に図示された一時的PCR用RIM証明書2500を用いる。この構造体と図２４のプラットフォーム状態証明書とのフィールドの関係および追加フィールドについて詳しく述べる。
ラベル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フィールドを格納する必要さえないと分かるであろう。
図２６に、拡張PSCツリーノード2600を示す。これは、証明書１つの拡張を記録する構造体である。このノードの構造体では、図２３Ｂに図示したような各ノードの内容、つまり項目2350〜2368を詳しく説明している。拡張PSCツリー2206は、当該技術分野において周知の技術を用いて有向非巡回グラフを実装する。例えば、ブーストC++ライブラリにはブーストグラフライブラリが含まれている。これは、上述した有向非巡回グラフなど様々なグラフの作成および操作をサポートする。このように、拡張PSCツリーノード2600はグラフの各頂点に関連付けられる。拡張PSC名2602は、拡張されたプラットフォーム状態証明書2400のPSC名2402のフィールドである。tPCR状態2604は、このノードにおける現在の一時的PCR状態のキャッシュであり、このノードの先祖に当たる拡張済みのPSCから算出される。tPCR状態は、tPCRインデックス2606とtPCR値2608との対リストで構成される。当業者は、このデータの別の表現、例えば、用いたtPCRを表すビットマップでtPCRインデックス2606フィールドを置き換えるなどが存在すると分かるであろう。
図２７に、OSサポートモジュール2200によって維持されたコンポーネント・PSCマップ2202を示す。このコンポーネント・PSCのマップ2202には、コンポーネントをPSCへ2700マッピングするリストが含まれる。このリストの各エントリーには、コンポーネントID2702と拡張PSC名2704、つまりアプリケーションの起動前に拡張されたプラットフォーム状態証明書2400のPSC名2402フィールドとが含まれる。Windows（登録商標）ベースのプラットフォームにおける本発明の好ましい実施形態では、コンポーネントID2702は２つのフィールドから構成されている。第１フィールドは、プロセスID2706である。このプロセスIDは、GetCurrentProcessId()などのWin32APIによって決定されるような、コンポーネントが属するプロセスを一意的に表す識別子をもつ。第２フィールドはモジュールハンドル2708である。単独で実行可能なコンポーネントに対しては、このフィールドを必ず0に設定する。リンクライブラリとして実装されたコンポーネントに対しては、第１パラメータのDllMainエントリーポイントに渡されるように、ライブラリ用のHMODULEがこのフィールドに含まれる。この構造体の利用法については後で述べる。
「TCG Mobile Reference Architecture」によると、PCR0は、基礎を成すハードウェアプラットフォームの特徴を表す値を保持する。PCR1は、信頼性のルートを表す値を含む。PCR2は、エンジンロードイベントを表す値を含む。PCR3〜6および8〜12は、専有手段を含む。PCR13〜15はアプリケーションが自由に使用できる。セキュアブートが正しく行われたことをPCR0、1および2が期待通りに示すかどうかのテスト、PCR13が0に設定されたかどうかのテスト、そして、全てが正しければ新たな値をPCR13に拡張することをアプリケーションプログラマが希望したとする。図２８に、先行技術にかかる、「第１アプリケーション開始」と名付けられたプラットフォーム状態証明書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 が存在する。
先行技術にかかる図２８の証明書に関する問題として次のものがある。他のアプリケーションがPCR13を使用してしまった場合、検証用PCR状態2404はもはや正確ではなくなってしまうという問題がある。アプリケーションが終了して再起動する場合、2818と2820に定義した先に拡張された値によってPCR13は0以外の状態に設定されてしまい、検証用PCR状態2404はもはや正確ではなくなってしまうという問題がある。
しかしながら、本発明では、図２８の証明書と類似の証明書は、アプリケーション自身と同じ時間または別々の時間で対象装置に展開するためにアプリケーション開発者によって、図２９に示すような２つの証明書に分けられる。なぜ分けるかというと、既存の証明書により２つの異なるPCRセットを検証するためである。第１のセットにはセキュアブートプロセスの結果、つまり既知の不変な結果が含まれ、第２のセットには動的状態、つまりアプリケーションレベルの状態が含まれる。図２８において、項目2802および2804は、ハードウェアプラットフォームを表す既知のセキュアブートPCR0の値を指している。項目2806および2808は、信頼性のルートを表す既知のセキュアブートPCR1の値を指し、項目2810および2812は、エンジンロードイベントを表す既知のセキュアブートPCR2の値を指している。また、項目2814および2816は、期待される前提条件を表す、ブート後のPCR13の望ましい値を指している。このように、アプリケーション開発者は、セキュア処理環境が管理する物理的PCR、すなわち本例ではPCR0、1および2をテストするために用いられる片方の証明書に既知のセキュアブートPCRの値を置くことによって、図２８の単一証明書を図２９に示した２つの証明書に分けてもよい。第２の証明書は、アプリケーション空間の一時的PCR、すなわち本例ではPCR13用に用いられる。
「第１アプリケーション開始（セキュアブート）」2900と名付けられた第１証明書によって、セキュア環境が正しいことを確保するため、セキュアブートプロセスがセットアップした物理的PCR（PCR0 2802、PCR1 2806およびPCR2 2810）はテストされる。ここで、拡張用PCRは、拡張がないことを示すために-1 2902に設定され、拡張用値2904はゼロという名目上の値である。この証明書は検証のみに使われる。そして、アプリケーションレベルでは、図２３Ａに示すように物理的PCRへの書き込みをやめ、一時的PCRを用いることによってより柔軟性が高まり、前述した当該技術分野における課題を回避することができる。「第１アプリケーション開始（一時的）」2920と名付けられた第２証明書によって、ゼロ 2816である一時的PCR13 2814はテストされ、同じレジスタ2818および2820に値を拡張する。tPCRのインデックス13を選択したことに特に意味はない。先行技術の状況とは異なり、tPCR0またはtPCR99が用いられやすいであろう。
図３０に、シーケンス図を示す。この図では、アプリケーション起動時には図２９の２つの証明書、つまり一方が物理的PCRをテストする証明書でありもう一方が一時的PCRをテストする証明書を用い、アプリケーション終了時には「第１アプリケーション開始（一時的）」2920の第２証明書を用いて、値をtPCRに拡張してからその拡張を取り消すという本発明にかかるイベントシーケンスを示す。相互に作用する6つのオブジェクト、21000、21002、21004、21006、21008および21010を図示している。まず、tPCR13 21000は、この例の状況における一時的PCR13の状態を表す。図２６で説明したように、tPCRは、特定のメモリ位置というよりむしろ拡張PSCツリー2206のノードごとに記録されるが、本例においては理解しやすいよう、tPCR13 21000をそのような位置にあるかのごとく表す。次に、tPCRサポート21002が存在する。これは、tPCRを参照するPSCの取得と現在のtPCR状態の検証との処理を行い、有効であれば、証明書は拡張されたと記録する。SPE21004は、先行技術にかかるセキュア処理環境である。好ましい実施形態では、それはMTMである。抽象化レイヤ21006は、通常モードのアプリケーションからの要求を取り扱い、要求を他のモジュールにわたす。OS21008はオペレーティングシステムであり、ここでは、一時的PCRを正確にアップデートするようなアプリケーションの起動および終了の処理に関するシステムである。そして、図３０のシーケンス図のプロセスは入れ子されてもよいので、アプリケーション21010は、例えば、アプリケーション実行21042が21014から始まるイベントシーケンスに従う別のアプリケーションの開始を含むような、PSCによって保護された他のアプリケーションの開始を要求するアプリケーションであっても構わない。図を単純化するため、エラー処理については図示しないが、本発明から除外されるものではない。
まず最初に、tPCR13 21000は、0の値21012で始まる。本発明では、拡張PSCツリー2206のルートは、全tPCRを０に設定させた状態で始まるというのがルールである。当業者であれば、セキュアブートの完了後に物理的PCRの値でtPCRを初期化するというような他の初期値候補が可能だと分かるであろう。OS21008は、要求を検出してアプリケーション21010を起動するので、まず、起動しようとするアプリケーションによってどのPSCが用いられるのかを決定する21014。Windowsベースのオペレーティングシステムにおける好ましい実施形態では、実行ファイルに組み込まれたカスタムアセンブリが、使用する２つのPSCを特定する。そのアプリケーションは、改ざんから保護するためにマイクロソフトのストロングネームツールを用いて署名される。次に、21014で特定されたPSC、この図では「第１アプリケーション開始（セキュアブート）」および「第１アプリケーション開始（一時的）」を抽象化レイヤ21006に要求する21016、21018。そして、これら２つのPSCの検証が、抽象化レイヤAPIであるAL_VerifyPSCsAndExtendtPCRを呼び出す21020ことによって行われる。このAPIは、システムが開始したいアプリケーションを検証する２つのPSC、つまり、図２９で示したような物理的PCR用のPSCおよび一時的PCR用のPSCを引数とする。まず、図の21024で表されたPSC「第１アプリケーション開始（セキュアブート）」を引数とした、SPEのAPIであるSPE_VerifyPSCStateを呼び出す21022。先行技術によれば、これによって、PSC自身のフォーマットおよび署名のチェックが行われ、そして、PSCの検証用PCRが物理的PCRの現在の値と一致することを検証する。先行技術によれば、PSCがプラットフォームに渡されると、セキュア処理環境2114に組み込まれたキーか、この組み込まれたキーによって正当であると検証されることのできるキーのいずれかでPSCは署名される。そして、有効であれば、セキュア処理環境2114が生成かつ安全に格納した他のキーで再び署名され、証明書はPSCデータベース2112に格納される。
本発明の好ましい実施形態によると、物理的PCRをチェックするPSCはオプショナルなので、ステップ21016および21018を省略してもよい。その他の好ましい実施形態によると、物理的PCRのチェック用のPSCがアプリケーション全てについて同じである場合、物理的PCR用のPSC１つを２つ以上の異なる一時的PCRのPSCが用いてもよい。
次に、SPEの他のAPI、すなわち、図の21030で表されたPSC「第１アプリケーション開始（一時的）」にパラメータを設定したSPE_VerifyPSCを呼び出す21026。先行技術によると、これによって、物理的レジスタに対してPCRの設定を検証せずとも、PSC自身のフォーマットおよび署名のチェックが行われる。そこで、tPCRサポートモジュール、すなわち、図の21030で表されたPSC「第１アプリケーション開始（一時的）」にパラメータを設定したAPIであるTPCR_VerifyPSCAndExtendを呼び出す21028。このAPIの最初のタスクは、拡張PSCツリー2206内の既存状態に対応する検証用PCR状態2404をチェックすることにより、PSCを拡張できることを検証する21032ことである。この動作の詳細については後で述べる。検証が正常に完了した時点で、このPSCにおける動作の成功が、拡張PSCツリーの正しい位置へその表示を付け加える21034ことによって記録される。この動作の詳細については後に述べる。このPSCをツリーへ付け加えたことによる結果の１つは、tPCR13 21000、つまり拡張対象のレジスタが、以前の値、この場合は０、とPCRから拡張するための値1030、つまり0xABCD1234とを連結したもののハッシュに設定されたレジスタの値を有することである。これは、合成ハッシュと呼ばれ、数式的には、tPCR13 = SHA-1（0xABCD1234と連結されたtPCR13）と書き込まれる。この動作は21036の構文 (+)=で表される。このように、環境が期待された状態であることを検証し、成功したことの記録が生成され、そして、制御がオペレーティングシステムに戻る。先行技術によると、21020におけるPSC検証の前の、更なる安全性の評価として、アプリケーションのハッシュを算出し、拡張するPSCに格納された基準値と比較する。本発明では、この値は、好ましい実施形態において0xABCD1234と表された、拡張用の値として、PSC「第１アプリケーション開始（一時的）」21030に格納される。しかしながら、このステップは図から省略されている。
アプリケーションを起動する際に、OSは、そのアプリケーションのプロセスIDを取得し、コンポーネント・PSCマップ2202に、この識別子と一時的レジスタ用の対応PSC、つまりPSC「第１アプリケーション開始（一時的）」とを記録する21038。マイクロソフトのWindows環境における好ましい実施形態では、本プロセスは、http://www.codeproject.com/KB/system/InterceptWinAPICalls.aspxのコードプロジェクトにおけるAndriy OriekhovのIntercepting WinAPI callsに記載されたようなプロセス作成プロセスを途中でインターセプトすることによって実装される。取得したプロセスハンドルは、プロセスID2706に変換され、そのフィールドに設定される。そして、モジュールハンドル2708を０に設定する。コンポーネントがダイナミックリンクライブラリである場合、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()の第１引数に設定する。
アプリケーションは起動されると21040、PSCに関連付けられた他のアプリケーションを起動またはtPCR自体を参照する他のPSCを拡張したとしても、プログラムされたように実行し続ける21042。そして、アプリケーションを閉じるとユーザが選択する、クラッシュする、または、アプリケーションを強制的にシャットダウンするセカンダリRICモニタ（この図では図示していない）が改ざんを検出するといういずれかの原因で、アプリケーションは終了する21044。
アプリケーションが終了するので、OSはアプリケーションのプロセスIDを取得し、そのプロセスIDと0であるモジュールハンドルとを用いて、コンポーネントID2702を作成する。このコンポーネントIDを用いてコンポーネント・PSCマップ2202を検索し、アプリケーションを起動するのに用いられたPSCを見つける21046。これにより、PSC「第１アプリケーション開始（一時的）」21030が返されるので、取り消しを行うため、OSは、抽象化レイヤ21006のAPIであるAL_UndoPSCExtendを、PSCを引数として呼び出す21048。コンポーネントがダイナミックリンクライブラリである場合、上述したようにFreeLibrary() APIをフックするので、そのルーチン内で現在のプロセスIDを問い合わせ、FreeLibrary()のパラメータからモジュールハンドルを取得し、そしてこれら２つのデータ項目を用いて、コンポーネントID2702を作成する。このコンポーネントIDを用いてコンポーネント・PSCマップ2202を検索し、ライブラリを起動するのに用いられたPSCを見つける。前述と同様に、SPEの他のAPI、すなわち、図の21030で表されたPSC「第１アプリケーション開始（一時的）」にパラメータを設定したSPE_VerifyPSCを呼び出す21026。先行技術によると、これによって、物理的レジスタに対してPCRの設定を検証せずとも、PSC自身のフォーマットおよび署名のチェックが行われる。そこで、tPCRサポートモジュール21002、すなわち、図の21030で表されたPSC「第１アプリケーション開始（一時的）」にパラメータを設定したAPIであるTPCR_VerifyPSCAndExtendを呼び出す21050。このAPIの最初のタスクは、拡張PSCツリー2206にそのPSCがすでに存在するかどうか確認することによって、PSCが拡張されたことを検証する21052ことである。検証が正常に完了した時点で、これは、21028における拡張動作を取り消すことが可能であることを意味する。これは、拡張PSCツリー21034から、PSCを表すノードおよびそれに従属する他のノード全てを削除することによって実現される。この動作の詳細は後で述べる。ツリーからこのPSCを削除することの結果の１つは、tPCR13 21000、つまり取り消す対象のレジスタが効率よくその状態を0にリセットされる21056ことである。このように、環境が期待した状態であることを検証し、拡張PSCツリーからノードを削除する21034ことによって先に拡張された動作を取り消し、制御がオペレーティングシステムに戻り、本システムは他の動作をすぐに実行することができる。当業者であれば、これらの他の実行動作の１つとして、終了したアプリケーションを再起動することもあると分かるであろう。tPCR13が21056において00…00、つまり21012で示されたtPCR用の開始値にリセットされた後は、アプリケーションの開始PSC21030の検証は２回目も正常に再実行されるので、本発明によると、アプリケーションを再起動することができる。
図３０に、実行ファイルの起動および終了時に信頼性の境界を動的に拡張かつ縮小するシーケンス図を示す。注釈を用いて、好ましい実施形態に沿ったダイナミックリンクライブラリに対する同様のタスクを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クラスを用いて検証してもよい。この場合、好ましい実施形態において、図２７に示されたモジュールハンドル2708は、コンポーネントを含むJARファイルを参照するハンドルである。
図３１に、tPCRサポートモジュール21002のAPI、TPCR_VerifyPSCAndExtend 21028の詳細に関するフローチャートを示す。本関数は、検証および記録するためのPSCをパラメータとしてわたして21100で開始し、次の図３２で示す、拡張PSCツリーの各ノードに対してtPCR状態を算出する21102サブルーチンを呼び出す。次に、現在のtPCR状態とソリューションリストの変数とを、NULLに初期化する21104。これら２つの変数の利用法については図３３で説明する。そして、渡されたPSCのtPCR値に、現在の拡張PSCツリーに記述された状態から達することができることを検証するサブルーチンが呼び出される21106。戻りコードをテストすることで、本関数が、拡張PSCツリー内で、渡されたPSCが保持する検証用の状態にtPCRを設定したノードを１以上見つけたかどうか分かる21108。この設定された親が見つからなかった場合、プロセスは、呼び出しルーチンへ拡張できなかったことを示すエラーコードを返す21110。見つかった場合は、渡されたPSCを、ソリューションリストに記述されたノードに設定した先のPSCを有する拡張PSCツリーに付け加え21112、プロセスは、呼び出しルーチンにサクセスコードを返す21114。
図３２に、図２６における拡張PSCツリーの各ノードのtPCR状態2604をどのように算出するか説明するフローチャートを示す。当該フローチャートは引数なしに呼び出され21200、行きがけ順に拡張PSCツリーの走査を行う21202ことで処理が開始する。この走査は、ツリーのノードを続く処理にとって望ましい順序で収集するためにルートから始まる。好ましい実装では、ブーストグラフライブラリ関数breadth_first_search()を用いてこれらのノードを収集する。次に、記録されている各ノード21204に対し、深さ優先走査によって現在のtPCR状態2604をNULLに設定する21206。セキュアブート完了の際に定義されたtPCRの開始値、好ましい実施形態では０の値、に初期化されたtPCRを検証する証明書の特別処理が必要なので、現在の証明書に格納された検証用PCR状態2404のtPCR対ごとに、その値をセキュアブート完了の際に定義されたtPCR初期値、好ましい実施形態では０の値と照合する21210。それらが等しい場合は、tPCRのインデックスおよび値の対をこのノードのtPCR状態に付け加え21212、次のtPCRに対してループを続ける。そうでない場合は、ノードのtPCR状態を付け加えずにループを続ける。各tPCRをチェックすると、本関数は、現在のノードの親それぞれに対するループへと移行する21214。親ノードが拡張PSCツリーのルートノードであれば21216、前回のループがこの特殊ケースを処理したため、何も行われない。そうでない場合には、親ノードのtPCR状態2604を問い合わせ、コピーする21218。親の拡張PSC名2602により参照されるPSCによって定義された拡張動作が親の状態のコピー21220において行われ、その結果のtPCR状態が現在のノードのtPCR状態に付加される21222。この拡張PSCツリー構築方法により、２つの親が同じtPCRに対して異なる値を指定する事態は決しておこらない。そのため、当業者は、この状況をチェックする必要はないが、検証目的で実装してもよいと分かるであろう。tPCR状態の収集は、前述したように、全ての親に対して繰り返され、終了すれば、走査中の次のノード21204が処理される。このように各ノードが処理されると、各ノードのtPCR状態を返してプロセスは終了する21224。
当業者は、例えばbfs_visitor’s examine_vertex()でステップ21204から21222を実行するなど、上記アルゴリズムを実行する別の方法が存在するので、ノードの別々のリストの必要性はなくなると分かるであろう。さらに、この関数は、PSC関連の動作が行われるたびに呼び出されるが、その値をキャッシュして再計算にかかる労力を削減してもよい。
図３３に、ノードごとの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。先行技術に従ってこれらのノードをどのように取得できるかは図３２の説明で示した。まず、２つの構造体において一致する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。
図３４に、取り消し前と取り消し後のサンプル拡張PSCツリー2206の状態を示す。取り消し前の状態21400は図２３Ｂで述べたとおり、図２３Ａのモジュールツリーから構築された状態である。ところで、図３０で示されたように、ユーザからの作用、プログラムバグ、または改ざん検出により第１プラグインが終了すれば、オペレーションシステムは第１プラグインの終了を検出して、「第１プラグイン開始」証明書2358は起動時にテストされたPSCであったと判断するので、証明書の拡張を取り消す必要がある。「第１プラグイン開始」2358とともに、それに従属する全ての証明書、すなわち、「第１プラグインロード」2362、「第１マッシュアップ開始」2366および「第１マッシュアップロード」2368も拡張PSCツリー2206から削除しなければならない。その結果、取り消し後の状態21402の拡張PSCツリー2206となる。
図３５に、拡張プロセスをどのようにして取り消すか説明するフローチャートを示す。本関数は、引数として、取り消し対象PSCをとる21500。まず、本関数は、上記の図３２で示された、拡張PSCツリーのノードごとにtPCR状態を算出する21502サブルーチンを呼び出す。次に、対象PSCのPSC名2402とツリー内の各ノードの拡張PSC名2602との一致を探すことで、拡張PSCツリー内で対象PSCへの参照を検索する21504。一致するノードが見つからない場合21506、エラーコードを呼び出し側に返して取り消すことができなかったことを示す21512。次に、対象PSCの検証用PCR状態2404を見つかったノードのtPCR状態2604とを比較する。それらの状態が等しくない場合21510、エラーコードを呼び出し側に返して取り消すことができなかったことを示す21512。状態が等しい場合は、見つかったノードとそれに従属するもの全てを削除する関数を呼び出し、その関数がサクセスコードを呼び出し側に返す21516。
図３６に、取り消し処理が拡張PSCツリーからどのようにしてノードを削除するか説明するフローチャートを示す。本関数は、引数として、ツリーから削除するノードをとる21600。まず、このノードの子PSC全てに対してループし21602、再帰的に自分自身を呼び出してその子それぞれを順に削除する21604。全ての子が削除された時点で、ノード自身を削除し21606、本関数はリターンする21608。このようにして、終了中のモジュールおよびそれに従属する信頼性のあるモジュール全てをカバーする、以前の拡張処理によって確立された信頼性の境界は、終了する必要のないモジュールをカバーしたまま、装置のアプリケーション空間における信頼性レベルを落とすことなく、終了するモジュールを除外するように縮小される。
（第３の実施形態）
本発明の第３の実施形態は、リモート認証のためのものである。先行技術によると、リモート認証のプロセスには異なる段階が２つある。まず、共有されるAIK、すなわち、認証識別キー（Attestation Identity Key）が、TPM v1.2にある匿名認証（Direct Anonymous Attestation）プロトコルをおそらく用いて、装置上のクライアントとリモートサーバとの間で確立される。次のステップは、このAIKを用いて特定のデバイス構成の認証を行うことである。図３７Ａおよび図３７Ｂに、当該リモート認証の先行技術を示す。装置2120とその構成要素とは、図１１Ａおよび図１１Ｂで示されたものに、セキュア処理環境2114内に格納されたAIK21710を加えたものである。図３７Ａに、当該システムのセキュアブートをサポートする場合における先行技術を示し、本発明にとって重要な２つの要素を含むサーバ21700も示す。認証プロセスを制御する認証器21702があり、これは、先に確立されており、装置2120のAIK21710と関連付けられているAIK証明書21704を用いる。認証器21702は、認証要求21706を生成し、認証を要求したアプリケーション2100にその認証要求を送信する。アプリケーション2100における認証プロセスでは、認証要求21708をセキュアブートコンポーネント2113に送信し、セキュアブートコンポーネント2113はセキュア処理環境2114と連携して先行技術で定義したような認証を実行する。
図３７Ｂも同様に、セキュアモードのサポートはないが、「TCG Specification Architecture Overview Revision 」に記載した手段などの独立したセキュア処理環境2114を有し、セキュアモードインターフェースが存在しない場合における先行技術を示す。前述したように、本発明にとって重要な２つの要素を含むサーバ21700も存在する。認証プロセスを制御する認証器21702があり、これは、先に確立されており、装置2120のAIK21710と関連付けられているAIK証明書21704を用いる。認証器21702は、認証要求21706を生成し、認証を要求したアプリケーション2100にその認証要求を送信する。アプリケーション2100における認証プロセスでは、認証要求21705をトラステッド/セキュアブートコンポーネント2152に送信し、セキュアブートコンポーネントはセキュア処理環境2114と連携して先行技術で定義したような認証を実行する。
図３８Ａに、図３７Ａの先行技術に基づいた、一時的PCRに対するリモート認証のための本発明における第３の実施形態を示す。サ―バ21700は前述したものであり、前述した認証要求21706は、アプリケーション2100に対して行われる。しかしながら、第３の実施形態では、セキュアブートコンポーネント2113へ認証要求21708を直接行う代わりに、サーバへ返される認証情報にtPCRサポート2204からの情報も含めることができるよう、システムのレイヤ全てを介して認証要求21800を行う。
図３８Ｂに、図３７Ｂの先行技術に基づいた、一時的PCRに対するリモート認証のための本発明における第３の実施形態を示す。サ―バ21700は前述したものであり、前述した認証要求21706は、アプリケーション2100に対して行われる。しかしながら、第３の実施形態では、トラステッド/セキュアブートコンポーネント2152へ認証要求21708を直接行う代わりに、サーバに返される認証情報にtPCRサポート2204からの情報も含めることができるよう、システムのレイヤ全てを介して認証要求21850を行う。
図３９に、アプリケーションがリモート認証する間のモジュール間通信について説明するシーケンス図を示す。相互に作用する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は、図３０で述べたようなプロセス空間の情報を用いて、どのアプリケーションまたはダイナミックロードライブラリが関数を呼び出したのかと、モジュールがどの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である第３の実施形態において、SPE_QuoteはTPM_Quoteのエイリアスであり、TCG仕様書で定義されたように動作する。この得られた署名値は、SPE21004からサーバ21900へ、21922、21924、21926そして21928と遡って渡される。サーバ21900は、渡された結果が期待される結果と等しいかどうかを検証し21930、等しければ、アプリケーション21010に認証が正常に完了したことを通知する21932。
第３の実施形態では、アプリケーション21010およびサーバ21900間の通信（21903、21904、21928、21930および21932）は、インターネットを介したワイヤレスリンクで行われるが、固定リンクや無線リンクを用いる実施形態でも可能であると当業者は分かるであろう。この通信のプロトコルは、メッセージコンテンツを暗号化する必要がないように設計されているが、SSLなどの暗号化プロトコルを用いる実施形態でも可能であると当業者は分かるであろう。
もう1つの方法として、tPCR値に対するリモート認証のみを要求しても構わない。図４０に、この場合のリモート認証で用いられるQuote情報記録22000の構造体を示す。versionフィールド22002には、定値1.1.0.0と定義されたバージョン表示が含まれる。fixedフィールド22004には、定値「QUOT」と定義された構造体タイプの識別子が含まれる。digestValueフィールド22006には、認証されるtPCRダイジェスト値が含まれる。externalDataフィールド22008には、クライアントノンスとサーバノンスとChallenge値とを連結したもののハッシュとしてリモート認証プロトコルにより定義された外部データが含まれる。そして、signatureフィールド22010には、上記のフィールドの暗号化署名が含まれる。この署名は、先に確立されたAIKとしてリモート認証プロトコルにより定義された、署名生成ルーチンに渡されたキーリファレンスを用いて生成される。
図４１に、tPCRのみに対し、アプリケーションが図４０で示したQuote情報構造体22000を用いてリモート認証する間のモジュール間通信を示す。この通信シーケンスの第１段階は、図３９で示したシーケンスと全く同じである。前述したように、抽象化レイヤ21006は、SPE21004を用いて、認証要求の署名を検証し21912、一時的PCRのPSCの完全性を検証する21914。そして、tPCRサポートを用いてPSC内の実tPCR値を検証する21916。前述した検証が正常に行われた場合は、ここから、図３９とシーケンスが異なってくる。抽象化レイヤ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仕様書に固有なものであるため、省略してもよい。
(２)上述の実施形態では、証明書(RIM証明書)内でハッシュ値を使用することにより検証は行われた。しかしながら、ハッシュ値を使用しない他の検証方法が本発明に適用されてもよい。
従来のチェックサムや、コンポーネントから抽出される別のデータ(例えば、コンポーネントから抽出される第１所定ビット)が、検証を行うために使用されてもよい。また、証明書は、完全性チェック値を含むデータの集合に置き換えられてもよい。
さらに、検証方法は、コンポーネントから抽出される値と期待される値が等しいか否かをチェックすることに限定されない。例えば、コンポーネントのサイズを確認し、もしサイズが所定量より大きいか、または小さいなら、コンポーネントは検証されたと判断されるとしてもよい。これらの検証方法は、ハッシュ値と、その期待値とを比較するほど厳密なものではないが、それよりも高速に行われる。
（３）上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
（４）上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムLSIは、その機能を達成する。
さらに、各装置を構成する構成部品の各ユニットは、別個の個別チップとして、または、一部もしくは全てを含む単一のチップとして作られてもよい。
さらに、ここでは、LSIが述べられているが、集積化の程度の違いにより、指定IC、LSI、スーパLSI、ウルトラLSIが使用される場合もある。
さらに、回路の集積化の手段は、LSIに限定されるものではなく、専用回路、もしくは汎用プロセッサによる実装も利用できる。さらに、LSIが製造された後にプログラム可能なフィールドプログラムゲートアレイ(FPGA)を使用することもまた可能であり、またLSI内で回路セルの接続および設定を再構成可能なリコンフィギュアラブルプロセッサも使用可能である。
さらに、もしLSIに置き換わる集積回路技術が半導体技術もしくは他の派生する技術の進歩を通じて現われるのであれば、その技術は当然に構成要素の集積化を実現するために使用することができる。バイオ技術の適用が予想される。
（５）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩに含まれるとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
（６）本発明は、上記に示す方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムなどのデジタル信号であるとしてもよい。
また、本発明は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray Disc）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。
また、本発明は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記憶しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。
また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
（７）本技術分野の当業者にとっては、説明した実施形態の、本発明固有の教示および利点から原理的に離れることのない多くの変形がありえることを容易に理解することができるだろう。また、上記変更および実施形態の任意の組み合わせは、本発明の範囲内に含まれる。
この構成によると、情報処理装置は、複数のモジュールのうちどれがアクティブモジュールであるかを示す情報を管理し、そして、そのアクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成する。
したがって、当該情報処理装置は、アクティブモジュール全てに対応する蓄積プラットフォーム情報を生成することができる。ゆえに、ロード対象の第１モジュールの期待プラットフォーム情報と蓄積プラットフォーム情報を比較して検証を行うことによって、情報処理装置は、第１モジュールを正常にロードする前にロード対象の全てのモジュールを検証することができる。さらに、複数のモジュールのうちどれがアクティブモジュールであるかを管理することによって、１以上のモジュールが終了した後であっても、情報処理装置が、現在の信頼性の境界に従って（PCR値に対応する）蓄積プラットフォーム情報を動的に生成することができる。
1100 アプリケーション
1102, 1108 抽象化レイヤAPI
1104 セキュアブートの信頼性の境界
1106 セキュアモードインターフェース
1110 抽象化レイヤ
1112 PSCデータベース
1113 セキュアブートコンポーネント
1114 セキュア処理環境
1116 物理的PCRs
1118 セカンダリRICモニタ
1120 装置
1200 OSサポート
1202 コンポーネント・PSCマップ
1204 tPCRサポート
1206 拡張PSCツリー

Claims (27)

  1. 情報処理装置であって、
    複数のモジュール各々に先立ってロードされているモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、
    前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示す、何れの前記アクティブモジュールも、ロード済みでまだ終了していないモジュールであるアクティブ情報を記録する管理手段と、
    次のモジュールをロードする場合に、
    (i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、
    (ii)それぞれの前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、
    (iii)前記次のモジュールの前記期待プラットフォーム情報を特定し、
    (iv)１以上の前記アクティブモジュールからの１以上のモジュールのリストであって、当該リストの前記蓄積プラットフォーム情報は、前記次のモジュールの前記期待プラットフォーム情報に等しいリストを生成し、
    (v)アクティブモジュールの前記リストが正常に生成された場合には前記次のモジュールをロードし、かつ、
    (vi)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する、ロード制御手段とを備える
    ことを特徴とする情報処理装置。
  2. 請求項１に記載の情報処理装置であって、
    前記ロード制御手段は、前記次のモジュールが終了する場合に、前記次のモジュールはアクティブモジュールでないと示すように前記アクティブ情報を更新するよう、前記管理手段を制御する
    ことを特徴とする情報処理装置。
  3. 請求項１に記載の情報処理装置であって、
    前記管理手段は、有向非巡回グラフを用いて、１以上の前記アクティブモジュールを示す情報を管理する
    ことを特徴とする情報処理装置。
  4. 請求項３に記載の情報処理装置であって、
    前記ロード制御手段は、前記次のモジュールをロードする場合に、前記次のモジュールと当該次のモジュールの期待プラットフォーム情報とを示すノードを生成し、かつ、従属するそのモジュールに対応する１以上のノードに、前記生成したノードが従属するように、前記生成したノードを前記有向非巡回グラフに付け加えるよう、前記管理手段を制御する
    ことを特徴とする情報処理装置。
  5. 請求項４に記載の情報処理装置であって、
    前記ロード制御手段は、前記次のモジュールがロードされて終了した場合に、前記次のモジュールを示すノードと、前記次のモジュールを示す前記ノードに従属するノード全てとを削除するよう、前記管理手段を制御する
    ことを特徴とする情報処理装置。
  6. 請求項５に記載の情報処理装置であって、
    前記ロード制御手段は、前記次のモジュールを示す前記ノードが従属することになっている親ノードを検索して、各ノードの期待プラットフォーム情報を前記有向非巡回グラフのルートから前記親ノードへ蓄積することによって前記蓄積プラットフォーム情報を生成する
    ことを特徴とする情報処理装置。
  7. 請求項１に記載の情報処理装置であって、
    前記ロード制御手段は前記蓄積プラットフォーム情報を所定期間の後に削除する
    ことを特徴とする情報処理装置。
  8. 請求項６に記載の情報処理装置であって、
    前記ロード制御手段は、前記複数のモジュールのうち１つが正常にロードされるたびに前記蓄積プラットフォーム情報を削除し、前記複数のモジュールのうち１つをロードすることになるたびに蓄積プラットフォーム情報を生成する
    ことを特徴とする情報処理装置。
  9. 請求項１に記載の情報処理装置であって、
    前記複数のモジュールは、それぞれが１以上のモジュールを含む第１モジュールグループと第２モジュールグループとを含み、
    前記情報処理装置は、さらに、
    前記第１モジュールグループのうち、何れの１以上のモジュールをロードしたかを示す第１蓄積プラットフォーム情報を格納する登録手段を備え、
    前記格納手段は、さらに、前記第２モジュールグループのモジュールをロードする前に前記第１モジュールグループのモジュール全てをロードすべきことを示す第１期待プラットフォーム情報を格納し、
    前記ロード制御手段は、
    前記第１モジュールグループのモジュールに対して、(i)当該モジュールを検証し、(ii)検証が成功した場合には前記モジュールをロードし、かつ、(iii)前記モジュールがロードされた場合には前記モジュールのプラットフォーム情報を前記第１蓄積プラットフォーム情報に蓄積することによって前記第１蓄積プラットフォーム情報を更新し、
    前記第２モジュールグループのモジュールをロードする場合には、(i)前記第１期待プラットフォーム情報を前記登録手段に格納された第１蓄積プラットフォーム情報と比較することによって第１モジュールグループのモジュール全てが正常にロードされたことを検証し、
    前記第１モジュールグループのモジュール全てが正常にロードされたことが検証された場合には、
    前記ロード制御手段は、
    (i)第２モジュールグループのモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、
    (ii)それぞれの前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、
    (iii)前記次のモジュールの前記期待プラットフォーム情報を特定し、
    (iv)１以上の前記アクティブモジュールからの１以上のモジュールのリストであって、当該リストの前記蓄積プラットフォーム情報は、前記次のモジュールの前記期待プラットフォーム情報に等しいリストを生成し、
    (v)アクティブモジュールの前記リストが正常に生成された場合に、前記次のモジュールをロードし、かつ、
    (vi)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する
    ことを特徴とする情報処理装置。
  10. 請求項９に記載の情報処理装置であって、
    前記第１モジュールグループは、システム層の１以上のモジュールを含み、前記第２モジュールグループは、アプリケーション層の１以上のモジュールを含む
    ことを特徴とする情報処理装置。
  11. 情報処理装置用の情報処理方法であって、
    前記情報処理装置は、
    複数のモジュール各々に先立ってロードされていると予期されるモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、
    前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示す、何れの前記アクティブモジュールも、ロード済みでまだ終了していないモジュールであるアクティブ情報を記録する管理手段とを備え、
    前記情報処理方法は、
    前記アクティブモジュールに続く次のモジュールをロードする場合に、
    (i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、
    (ii)それぞれの前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、
    (iii)前記次のモジュールの前記期待プラットフォーム情報を特定し、
    (iv)１以上の前記アクティブモジュールからの１以上のモジュールのリストであって、当該リストの前記蓄積プラットフォーム情報は、前記次のモジュールの前記期待プラットフォーム情報に等しいリストを生成し、
    (v)アクティブモジュールの前記リストが正常に生成された場合に、前記次のモジュールをロードし、かつ、
    (vi)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する、ロード制御ステップを備える
    ことを特徴とする情報処理方法。
  12. 情報処理装置用の記録媒体に記録されたコンピュータプログラムであって、
    前記情報処理装置は、
    複数のモジュール各々に先立ってロードされていると予期されるモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、
    前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示す、何れの前記アクティブモジュールも、ロード済みでまだ終了していないモジュールであるアクティブ情報を記録する管理手段とを備え、
    前記コンピュータプログラムは、ロード制御ステップを前記情報処理装置に実行させるためのコンピュータプログラムであって、
    前記ロード制御ステップでは、前記アクティブモジュールに続く次のモジュールをロードする場合に、
    (i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、
    (ii)それぞれの前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、
    (iii)前記次のモジュールの前記期待プラットフォーム情報を特定し、
    (iv)１以上の前記アクティブモジュールからの１以上のモジュールのリストであって、当該リストの前記蓄積プラットフォーム情報は、前記次のモジュールの前記期待プラットフォーム情報に等しいリストを生成し、
    (v)アクティブモジュールの前記リストが正常に生成された場合には前記次のモジュールをロードし、かつ、
    (vi)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する
    ことを特徴とするコンピュータプログラム。
  13. 情報処理装置に用いられる集積回路デバイスであって、
    前記情報処理装置は、
    複数のモジュール各々に先立ってロードされていると予期されるモジュールを示す期待プラットフォーム情報を前記複数のモジュールごとに格納する格納手段と、
    前記複数のモジュールのうち、どれがロード済みでまだ終了していないアクティブモジュールであるかを示す、何れの前記アクティブモジュールも、ロード済みでまだ終了していないモジュールであるアクティブ情報を記録する管理手段とを備え、
    前記集積回路デバイスは、
    前記アクティブモジュールに続く次のモジュールをロードする場合に、
    (i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、
    (ii)それぞれの前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、
    (iii)前記次のモジュールの前記期待プラットフォーム情報を特定し、
    (iv)１以上の前記アクティブモジュールからの１以上のモジュールのリストであって、当該リストの前記蓄積プラットフォーム情報は、前記次のモジュールの前記期待プラットフォーム情報に等しいリストを生成し、
    (v)アクティブモジュールの前記リストが正常に生成された場合には前記次のモジュールをロードし、かつ、
    (vi)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する、ロード制御手段を備える
    ことを特徴とする集積回路デバイス。
  14. 請求項１記載の情報処理装置であって、
    当該情報処理装置は、サーバに接続され、
    前記ロード制御手段は、予期される蓄積プラットフォーム情報を検証する要求を前記サーバから受信した場合に、
    (i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、
    (ii)それぞれの前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、
    (iii)前記次のモジュールの前記期待プラットフォーム情報を特定し、
    (iv)１以上の前記アクティブモジュールからの１以上のモジュールのリストであって、当該リストの前記蓄積プラットフォーム情報は、前記次のモジュールの前記期待プラットフォーム情報に等しいリストを生成し、かつ、
    (v)アクティブモジュールの前記リストが正常に生成された場合には、前記蓄積プラットフォーム情報を前記サーバに送信する
    ことを特徴とする情報処理装置。
  15. 請求項１４に記載の情報処理装置であって、
    前記ロード制御手段は、さらに、
    (i)前記蓄積プラットフォーム情報を生成するために、どの期待プラットフォームを用いるかを示す情報を生成し、
    (ii)前記情報に基づいて、前記蓄積プラットフォーム情報を検証するために用いる署名情報を生成し、
    (iii)前記署名情報が付加されている前記蓄積プラットフォーム情報を送信する
    ことを特徴とする情報処理装置。
  16. 請求項１４に記載の情報処理装置であって、
    前記ロード制御手段は、前記次のモジュールが終了する場合に、前記次のモジュールはアクティブモジュールでないと示すように前記アクティブ情報を更新するよう、前記管理手段を制御する
    ことを特徴とする情報処理装置。
  17. 請求項１４に記載の情報処理装置であって、
    前記管理手段は、有向非巡回グラフを用いて、１以上の前記アクティブモジュールを示す情報を管理する
    ことを特徴とする情報処理装置。
  18. 請求項１７に記載の情報処理装置であって、
    前記ロード制御手段は、前記次のモジュールをロードする場合に、前記次のモジュールと当該次のモジュールの前記期待プラットフォーム情報とを示すノードを生成し、かつ、従属するそのモジュールに対応する１以上のノードに、前記生成したノードが従属するように、前記生成したノードを前記有向非巡回グラフに付け加えるよう、前記管理手段を制御する
    ことを特徴とする情報処理装置。
  19. 請求項１８に記載の情報処理装置であって、
    前記ロード制御手段は、前記次のモジュールがロードされて終了した場合に、前記次のモジュールを示すノードと、前記次のモジュールを示す前記ノードに従属するノード全てとを削除するよう、前記管理手段を制御する
    ことを特徴とする情報処理装置。
  20. 請求項１９に記載の情報処理装置であって、
    前記ロード制御手段は、前記次のモジュールを示す前記ノードが従属することになっている親ノードを検索して、各ノードの期待プラットフォーム情報を前記有向非巡回グラフのルートから前記親ノードへ蓄積することによって前記蓄積プラットフォーム情報を生成する
    ことを特徴とする情報処理装置。
  21. 請求項１４に記載の情報処理装置であって、
    前記ロード制御手段は前記蓄積プラットフォーム情報を所定期間の後に削除する
    ことを特徴とする情報処理装置。
  22. 請求項２０に記載の情報処理装置であって、
    前記ロード制御手段は、前記複数のモジュールのうち１つが正常にロードされるたびに前記蓄積プラットフォーム情報を削除し、前記複数のモジュールのうち１つをロードすることになるたびに蓄積プラットフォーム情報を生成する
    ことを特徴とする情報処理装置。
  23. 請求項１４に記載の情報処理装置であって、
    前記複数のモジュールは、それぞれが１以上のモジュールを含む第１モジュールグループと第２モジュールグループとを含み、
    前記情報処理装置は、さらに、
    前記第１モジュールグループのうち、何れの１以上のモジュールをロードしたかを示す第１蓄積プラットフォーム情報を格納する登録手段を備え、
    前記格納手段は、さらに、前記第２モジュールグループのモジュールをロードする前に前記第１モジュールグループのモジュール全てをロードすべきことを示す第１期待プラットフォーム情報を格納し、
    前記ロード制御手段は、
    前記第１モジュールグループのモジュールに対して、(i)当該モジュールを検証し、(ii)検証が成功した場合には前記モジュールをロードし、かつ、(iii)前記モジュールがロードされた場合には前記モジュールのプラットフォーム情報を前記第１蓄積プラットフォーム情報に蓄積することによって前記第１蓄積プラットフォーム情報を更新し、
    前記第２モジュールグループのモジュールをロードする場合には、(i)前記第１期待プラットフォーム情報を前記登録手段に格納された第１蓄積プラットフォーム情報と比較することによって第１モジュールグループのモジュール全てが正常にロードされたことを検証し、
    前記第１モジュールグループのモジュール全てが正常にロードされたことが検証された場合には、
    前記ロード制御手段は、
    (i)第２モジュールグループのモジュールのうち、どれがアクティブモジュールであるかを前記アクティブ情報を用いて判断して、
    (ii)それぞれの前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、
    (iii)前記次のモジュールの前記期待プラットフォーム情報を特定し、
    (iv)１以上の前記アクティブモジュールからの１以上のモジュールのリストであって、当該リストの前記蓄積プラットフォーム情報は、前記次のモジュールの前記期待プラットフォーム情報に等しいリストを生成し、
    (v)アクティブモジュールの前記リストが正常に生成された場合に、前記次のモジュールをロードし、かつ、
    (vi)前記次のモジュールがロードされた場合には、前記次のモジュールがアクティブモジュールであると示すように前記アクティブ情報を更新するよう、前記管理手段を制御する
    ことを特徴とする情報処理装置。
  24. 請求項２３に記載の情報処理装置であって、
    前記第１モジュールグループは、システム層の１以上のモジュールを含み、前記第２モジュールグループは、アプリケーション層の１以上のモジュールを含む
    ことを特徴とする情報処理装置。
  25. 請求項１１記載の情報処理方法であって、
    前記蓄積プラットフォーム情報を送信する要求をサーバから受信する受信ステップと、
    前記受信ステップにおいて前記要求を受信した場合に、
    (i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、
    (ii)それぞれの前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、
    (iii)前記次のモジュールの期待プラットフォーム情報を特定し、
    (iv)１以上の前記アクティブモジュールからの１以上のモジュールのリストであって、当該リストの前記蓄積プラットフォーム情報は、前記次のモジュールの前記期待プラットフォーム情報に等しいリストを生成し、かつ、
    (v)アクティブモジュールの前記リストが正常に生成された場合には、前記蓄積プラットフォーム情報を前記サーバに送信する、送信ステップとを含む
    ことを特徴とする情報処理方法。
  26. 請求項１２記載のコンピュータプログラムであって、
    前記蓄積プラットフォーム情報を送信する要求をサーバから受信する受信ステップと、
    前記受信ステップにおいて前記要求を受信した場合に、
    (i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、
    (ii)それぞれの前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、
    (iii)前記次のモジュールの前記期待プラットフォーム情報を特定し、
    (iv)１以上の前記アクティブモジュールからの１以上のモジュールのリストであって、当該リストの前記蓄積プラットフォーム情報は、前記次のモジュールの前記期待プラットフォーム情報に等しいリストを生成し、かつ、
    (v)アクティブモジュールの前記リストが正常に生成された場合には、前記蓄積プラットフォーム情報を前記サーバに送信する送信ステップとを前記情報処理装置に実行させるための
    コンピュータプログラム。
  27. 請求項１３記載の集積回路デバイスであって、
    前記蓄積プラットフォーム情報を送信する要求をサーバから受信する受信手段と、
    前記受信手段が前記要求を受信した場合に、
    (i)前記複数のモジュールのうち、どれがアクティブモジュールであるかを、前記アクティブ情報を用いて判断し、
    (ii)それぞれの前記アクティブモジュールの期待プラットフォーム情報を蓄積することによって蓄積プラットフォーム情報を生成し、
    (iii)前記次のモジュールの前記期待プラットフォーム情報を特定し、
    (iv)１以上の前記アクティブモジュールからの１以上のモジュールのリストであって、当該リストの前記蓄積プラットフォーム情報は、前記次のモジュールの前記期待プラットフォーム情報に等しいリストを生成し、かつ、
    (v)アクティブモジュールの前記リストが正常に生成された場合には、前記蓄積プラットフォーム情報を前記サーバに送信する、送信手段とを備える
    ことを特徴とする集積回路デバイス。
JP2011510771A 2008-10-10 2009-10-09 セキュア処理システムのアプリケーション空間において信頼性を実現するための一時的ｐｃｒ利用 Expired - Fee Related JP5398824B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011510771A JP5398824B2 (ja) 2008-10-10 2009-10-09 セキュア処理システムのアプリケーション空間において信頼性を実現するための一時的ｐｃｒ利用

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2008264530 2008-10-10
JP2008264530 2008-10-10
JP2008321540 2008-12-17
JP2008321540 2008-12-17
PCT/JP2009/005289 WO2010041467A2 (en) 2008-10-10 2009-10-09 USING TRANSIENT PCRs TO REALISE TRUST IN APPLICATION SPACE OF A SECURE PROCESSING SYSTEM
JP2011510771A JP5398824B2 (ja) 2008-10-10 2009-10-09 セキュア処理システムのアプリケーション空間において信頼性を実現するための一時的ｐｃｒ利用

Publications (2)

Publication Number Publication Date
JP2012505437A JP2012505437A (ja) 2012-03-01
JP5398824B2 true JP5398824B2 (ja) 2014-01-29

Family

ID=42027920

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011510771A Expired - Fee Related JP5398824B2 (ja) 2008-10-10 2009-10-09 セキュア処理システムのアプリケーション空間において信頼性を実現するための一時的ｐｃｒ利用

Country Status (5)

Country Link
US (1) US20110173643A1 (ja)
EP (1) EP2344974A2 (ja)
JP (1) JP5398824B2 (ja)
CN (1) CN102246179A (ja)
WO (1) WO2010041467A2 (ja)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102282564B (zh) * 2009-02-18 2014-10-15 松下电器产业株式会社 信息处理设备和信息处理方法
US8914888B1 (en) * 2009-10-21 2014-12-16 Symantec Corporation Systems and methods for classifying an unclassified process as a potential trusted process based on dependencies of the unclassified process
US20110154501A1 (en) * 2009-12-23 2011-06-23 Banginwar Rajesh P Hardware attestation techniques
US8312137B1 (en) * 2010-01-04 2012-11-13 Google Inc. Live experiment framework
EP2543215A2 (en) * 2010-03-05 2013-01-09 InterDigital Patent Holdings, Inc. Method and apparatus for providing security to devices
US20110225425A1 (en) * 2010-03-11 2011-09-15 Microsoft Corporation Preventing causality violations in decentralized distributed systems
GB2482652B (en) 2010-05-21 2016-08-24 Hewlett Packard Development Co Lp Extending integrity measurements in a trusted device using a policy register
WO2012023050A2 (en) 2010-08-20 2012-02-23 Overtis Group Limited Secure cloud computing system and method
US9087196B2 (en) * 2010-12-24 2015-07-21 Intel Corporation Secure application attestation using dynamic measurement kernels
JP5932837B2 (ja) 2011-01-19 2016-06-08 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ コードを更新および認証するための方法およびシステム、プログラムの完全性を試験する方法およびシステム
KR20140043068A (ko) * 2011-02-17 2014-04-08 타세라, 아이엔씨. 애플리케이션 증명을 위한 시스템 및 방법
EP2710509A4 (en) * 2011-05-18 2015-02-25 Nokia Corp SECURE PRIMER WITH TRUSTED COMPUTER GROUP PLATFORM REGISTERS
US8812830B2 (en) 2011-08-31 2014-08-19 Microsoft Corporation Attestation protocol for securely booting a guest operating system
US8990948B2 (en) 2012-05-01 2015-03-24 Taasera, Inc. Systems and methods for orchestrating runtime operational integrity
JP5969845B2 (ja) * 2012-07-18 2016-08-17 キヤノン株式会社 情報処理装置及びその制御方法
WO2014047293A1 (en) * 2012-09-19 2014-03-27 Interdigital Patent Holdings, Inc. Layered certification
US20140282925A1 (en) * 2013-03-15 2014-09-18 Sypris Electronics, Llc Personal Authentication Device and System for Securing Transactions on a Mobile Device
US9576153B2 (en) * 2013-08-23 2017-02-21 Cellco Partnership Device and method for providing information from a backend component to a frontend component by a secure device management abstraction and unification module
US9544293B2 (en) 2013-09-20 2017-01-10 Oracle International Corporation Global unified session identifier across multiple data centers
CN104715183B (zh) * 2013-12-13 2018-06-01 中国移动通信集团公司 一种虚拟机运行时的可信验证方法和设备
US9363087B2 (en) 2014-10-02 2016-06-07 Microsoft Technology Licensing, Inc. End-to-end security for hardware running verified software
GB2531586A (en) 2014-10-23 2016-04-27 Ibm Methods and systems for starting computerized system modules
US9881176B2 (en) 2015-06-02 2018-01-30 ALTR Solutions, Inc. Fragmenting data for the purposes of persistent storage across multiple immutable data structures
US10193696B2 (en) * 2015-06-02 2019-01-29 ALTR Solutions, Inc. Using a tree structure to segment and distribute records across one or more decentralized, acylic graphs of cryptographic hash pointers
US10693859B2 (en) 2015-07-30 2020-06-23 Oracle International Corporation Restricting access for a single sign-on (SSO) session
US10581826B2 (en) * 2015-10-22 2020-03-03 Oracle International Corporation Run-time trust management system for access impersonation
EP3378005B1 (en) 2015-11-19 2020-01-08 Nagravision S.A. Method to verify the execution integrity of an application in a target device
US10623501B2 (en) 2016-09-15 2020-04-14 Oracle International Corporation Techniques for configuring sessions across clients
US10666443B2 (en) * 2016-10-18 2020-05-26 Red Hat, Inc. Continued verification and monitoring of application code in containerized execution environment
US10482034B2 (en) * 2016-11-29 2019-11-19 Microsoft Technology Licensing, Llc Remote attestation model for secure memory applications
US11290438B2 (en) 2017-07-07 2022-03-29 Oracle International Corporation Managing session access across multiple data centers
US11050730B2 (en) 2017-09-27 2021-06-29 Oracle International Corporation Maintaining session stickiness across authentication and authorization channels for access management
US10482258B2 (en) * 2017-09-29 2019-11-19 Nxp Usa, Inc. Method for securing runtime execution flow
US11790119B2 (en) * 2018-11-16 2023-10-17 Apple Inc. Application integrity attestation
US11134078B2 (en) 2019-07-10 2021-09-28 Oracle International Corporation User-specific session timeouts
CN112486073B (zh) * 2020-12-03 2022-04-19 用友网络科技股份有限公司 机器人控制方法、控制系统和可读存储介质
US20210283165A1 (en) * 2021-03-11 2021-09-16 Nidal Toman Constituent combination for treating stress

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5841869A (en) * 1996-08-23 1998-11-24 Cheyenne Property Trust Method and apparatus for trusted processing
US7191464B2 (en) * 2001-10-16 2007-03-13 Lenovo Pte. Ltd. Method and system for tracking a secure boot in a trusted computing environment
US7480804B2 (en) * 2004-04-29 2009-01-20 International Business Machines Corporation Method and system for hierarchical platform boot measurements in a trusted computing environment
US7706975B2 (en) * 2004-10-19 2010-04-27 Qualcomm Incorporated Mobile cellular identification database for enhanced GPS performance
US7725703B2 (en) * 2005-01-07 2010-05-25 Microsoft Corporation Systems and methods for securely booting a computer with a trusted processing module
US7836299B2 (en) * 2005-03-15 2010-11-16 Microsoft Corporation Virtualization of software configuration registers of the TPM cryptographic processor
US8751922B2 (en) * 2005-08-09 2014-06-10 Zalag Corporation Methods and apparatuses to assemble, extract and deploy content from electronic documents
JP4093494B2 (ja) * 2005-09-08 2008-06-04 インターナショナル・ビジネス・マシーンズ・コーポレーション 秘密情報へのアクセスを制御するシステムおよびその方法
US8117429B2 (en) * 2006-11-01 2012-02-14 Nokia Corporation System and method for a distributed and flexible configuration of a TCG TPM-based local verifier
US8433924B2 (en) * 2006-12-18 2013-04-30 Lenovo (Singapore) Pte. Ltd. Apparatus, system, and method for authentication of a core root of trust measurement chain
GB0701518D0 (en) * 2007-01-26 2007-03-07 Hewlett Packard Development Co Methods, devices and data structures for protection of data
GB0707150D0 (en) * 2007-04-13 2007-05-23 Hewlett Packard Development Co Dynamic trust management
GB2450869B (en) * 2007-07-09 2012-04-25 Hewlett Packard Development Co Establishing a trust relationship between computing entities
AR076088A1 (es) * 2009-03-06 2011-05-18 Interdigital Patent Holding Inc Plataforma de validacion y gestion de dispositivos inalambricos

Also Published As

Publication number Publication date
JP2012505437A (ja) 2012-03-01
WO2010041467A2 (en) 2010-04-15
WO2010041467A3 (en) 2010-06-24
CN102246179A (zh) 2011-11-16
US20110173643A1 (en) 2011-07-14
EP2344974A2 (en) 2011-07-20

Similar Documents

Publication Publication Date Title
JP5398824B2 (ja) セキュア処理システムのアプリケーション空間において信頼性を実現するための一時的ｐｃｒ利用
JP6014286B2 (ja) 機器にセキュリティを提供する方法および装置
US7962952B2 (en) Information processing apparatus that executes program and program control method for executing program
JP5745061B2 (ja) 起動プロセスの際の対話型コンポーネントの使用の認証
JP5530460B2 (ja) セキュアブート方法およびセキュアブート装置
JP5399397B2 (ja) セキュアブート方法、セキュアブート装置、プログラムおよび集積回路
JP2014112892A5 (ja)
CN103329093A (zh) 更新软件
JP2013519929A (ja) 情報処理装置、情報処理システム、ソフトウェアルーチン実行方法およびリモート認証方法
US20220253297A1 (en) Automated deployment of changes to applications on a cloud computing platform
US20080178257A1 (en) Method for integrity metrics management
US11044096B2 (en) Blockchain based digital identity generation and verification
US8732444B2 (en) Information processing device and information processing method
Sailer et al. The role of TPM in enterprise security
CN109165509B (zh) 软件实时可信度量的方法、设备、系统及存储介质
Alam et al. Analysis of existing remote attestation techniques
Akram et al. An introduction to the trusted platform module and mobile trusted module
CN112445705A (zh) 软件运行系统、方法、装置、计算机设备和存储介质
Cam et al. Detect repackaged android applications by using representative graphs
US20240095337A1 (en) Security compliance for modular code
US20240095029A1 (en) Catalog for managing modular code
Juhász et al. Secure remote firmware update on embedded IoT devices
CN114428956A (zh) 一种基于扩展属性的文件验证方法、装置及系统
Ferro Container Attestation with Linux IMA namespaces
Furrer Safe Software and Secure Software

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120628

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130918

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20131001

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131022

R150 Certificate of patent or registration of utility model

Ref document number: 5398824

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees