JP5455318B2 - 動的信頼管理 - Google Patents

Description

本発明は、コンピューティングプラットフォームで動的信頼管理を可能にする方法及び装置に関する。

検証可能な信頼は、コンピューティングシステムにとって望ましい特性である。ユーザは、自身が使用しようとしている（又は使用中の）コンピューティングプラットフォームが、信用でき且つ予測できる方法で振る舞うのか、又は破壊を受けやすい（又は既に破壊を受けている）のかを知ることには根本的な興味を持っている。

既存のトラステッドプラットフォームは、通常、破壊から少なくとも論理的に保護されているコンポーネントを含んでいる。このようなプラットフォームは、トラステッドコンピューティンググループ（ＴＣＧ）を形成する企業によって開発されている。この団体は、この分野の仕様を策定し、現行のＴＣＧ仕様は、http://www.trustedcomputinggroup.org（詳細には、トラステッドプラットフォームモジュール設計原理（Trusted Platform Module Design Principles）仕様を参照）で入手可能である。トラステッドプラットフォームの暗黙的なトラステッドコンポーネント（及び、詳細には、トラステッドプラットフォームモジュール、すなわち「ＴＰＭ」）は、プラットフォームの完全性の測定を確実に行って記憶し、その後、完全性メトリックとして、そのプラットフォームとの対話を望むユーザ（リモートコンピューティングエンティティを含む）へ報告することを可能にする。このようなユーザは、その後、測定された完全性メトリックが既知の値又は予測値と一致していることから、プラットフォームが予測通りに動作していることを判断することができる。

資源共有を（たとえば、仮想化技術を通じて）最大にするシステムを設計する一般的な傾向に伴って、これらの資源を消費するパーティは、情報機密コンテンツをこれらのシステム上にデプロイする前に、検証可能な信頼の手段をますます必要としている。この問題は、抵触する可能性のある関心を有するパーティをホスティングするシステムにとって特に重大である。信頼管理の課題は、非常に動的な仮想化コンピュータシステムで信頼性を管理することである。これは、現在のシステム状態を反映するために進行形式でシステム完全性を監視して、変化を報告することを可能にすることを伴う。これは、システム構成及びセキュリティポリシーが頻繁に変化し、コンポーネントがさまざまなセキュリティモードで動作することが認められるシステムにとって特に重大である。現在の解決法は、通例、このような変化を悪意のあるものと考え、信頼を再確立できるように、たとえば、システムのリセット及び再起動を要求する。これらの解決法は、実用的でないか、又は、複雑なコンピュータシステムでシステムコンポーネントの数が増加するにつれてスケーリングしない。

ＴＣＧ仕様で説明されている信頼アーキテクチャは、主として、ソフトウェアコンポーネントの関連のある状態がロード時に一度測定される静的な方法での信頼チェーンの作成を扱っている。これらの測定は、ＴＰＭのいわゆるプラットフォーム構成レジスタ（ＰＣＲ）に記憶され、インクリメンタルである。すなわち、一連の測定は、前の測定を、そのサイズを変えることなく増加的に拡張することによって同じＰＣＲで報告することができ、したがって、実質的には無限個の測定が可能になる。このように、完全な実行シーケンスを記録することができ、サードパーティは後の段階でそれを検証することが可能になる。この静的なアーキテクチャは、システム構成及びセキュリティポリシーが頻繁に変化することが認められている複雑な動的システムにいくつかの制限を課す。

ＴＣＧ信頼アーキテクチャは、クリティカルな（すなわち、測定された）システムコンポーネントが（たとえば、ソフトウェア更新を通じて）別の形態に変化するか若しくは現在の状態に適応することが認められている状況、又は、システムコンポーネントが（たとえば、異なる構成を有する）さまざまな動作モードで機能して、変化するセキュリティニーズと共にオペレーションを実行する状況を効率的に取り扱わない。いずれの状況でも、ＴＣＧ仕様は、保守的な手法を取り、このようなどの変化も、悪意があり、撤回できない可能性があるものと考える。

本発明は、コンピューティングプラットフォームで動的信頼管理を可能にするための方法及び装置を提供する。

本発明の第１の態様によれば、コンピューティングプラットフォーム上で使用されているソフトウェアコンポーネントの状態を追跡する方法が提供され、その方法は、
ソフトウェアコンポーネントの第１のタイプの変更時に、ソフトウェアコンポーネントの適切な完全性メトリックを確実に測定すると共に、ソフトウェアコンポーネントに対する上記第１のタイプの変更について記録されるあらゆる前の完全性メトリック値と累積的に組み合わせて記録すること、及び
ソフトウェアコンポーネントの第２のタイプの変更時に、ソフトウェアコンポーネントの適切な完全性メトリックを確実に測定すると共に、ソフトウェアコンポーネントに対する上記第２のタイプの変更について記録されるあらゆる前の完全性メトリック値の代わりとして記録すること
を含む。

本発明の第２の態様によれば、コンピューティングプラットフォームであって、当該コンピューティングプラットフォーム上で使用されているソフトウェアコンポーネントの状態を追跡する監視機構を含む、コンピューティングプラットフォームが提供され、監視機構は、
ソフトウェアコンポーネントに対する第１のタイプの変更及び第２のタイプの変更を検出及び区別する変更応答手段と、
第１のメモリレジスタ及び第２のメモリレジスタと、
ソフトウェアコンポーネントの第１のタイプの変更の検出に応答して、ソフトウェアコンポーネントの適切な完全性メトリックを確実に測定する第１の測定手段と、
第１の測定手段によって測定される完全性メトリックを、ソフトウェアコンポーネントに対する上記第１のタイプの変更について第１のレジスタに記録されるあらゆる前の完全性メトリック値と累積的に組み合わせて、第１のレジスタに記録する第１の記録手段と、
ソフトウェアコンポーネントの第２のタイプの変更の検出に応答して、ソフトウェアコンポーネントの適切な完全性メトリックを確実に測定する第２の測定手段と、
第２の測定手段によって測定される完全性メトリックを、ソフトウェアコンポーネントに対する上記第２のタイプの変更について第２のレジスタに記録されるあらゆる前の完全性メトリック値の代わりとして、第２のレジスタに記録する第２の記録手段と
を備える。

次に、従来技術及び本発明の実施の形態の添付の概略図面を参照して本発明の実施の形態を非限定的な例として説明することにする。

本発明の実施形態を説明する前に、本発明の実施形態の説明で後に使用されるいくつかの用語及び概念を紹介するために、２つの従来技術のトラステッドコンピューティングプラットフォームを図１〜図６を参照して説明することにする。説明する従来技術のトラステッドコンピューティングプラットフォームの詳細（次の段落から始まる）は、特に言及のない限り、本発明の範囲を限定するように意図されていない。本明細書で使用されるように、「コンピューティングプラットフォーム」という用語は、計算を行うことができるあらゆる装置を包含するものと理解されるべきであり、コンピュータに限定されるものではない。たとえば、デジタルセルラー機器（移動電話を含む）は、実質的なコンピューティング能力を有し、「コンピューティングプラットフォーム」という用語の範囲内に含まれる。さらに、本文脈では、「信頼」は、デバイスが特定の方法で特定の目的のために振る舞うと予測されることであり、「ユーザ」は、ローカルユーザ、又は、リモートコンピューティングエンティティ等のリモートユーザとすることができる。

従来技術のトラステッドプラットフォームの一般的特徴
トラステッドコンピューティングプラットフォームは、信頼可能なプラットフォーム完全性の測定及び報告を提供し、この目的のために、複数のシールドされているロケーション、すなわち、機密データに対する操作が安全である場所（メモリ、レジスタ等）を有する。完全性の測定は、プラットフォームの完全性メトリック測定値（すなわち、プラットフォームの完全性、つまり信頼性に影響を与えるプラットフォームの特徴の測定）を取得すると共に、それら測定値（ここでは、ダイジェスト等の派生する値を包含するようにみなされる）をシールドされているロケーションに配置するプロセスである。ＴＣＧ用語において、完全性メトリックを記憶するのに使用されるシールドされているロケーションは、プラットフォーム構成レジスタ（Platform Configuration Register）、すなわち「ＰＣＲ」と呼ばれ、以下では、この術語が使用される。ＰＣＲに保持された値は、報告可能な完全性メトリック値である。完全性の報告は、関係しているプラットフォームにメトリックを関連付ける方法でＰＣＲに記録された完全性メトリックを証明するプロセスである。トラステッドコンピューティングプラットフォームは、シールドされているロケーションに加えて、暗号化された形でデータをセキュアに記憶し、且つ、このデータへのアクセスが、指定された環境でのみ行われることを確実にする信頼可能なストレージも提供することができる。上記トラステッド機能は、暗号機能の使用を標準的に伴う。

ユーザは、たとえば、プラットフォームとデータを交換する前に、１つ又は２つ以上の完全性メトリックを提供するようにトラステッドプラットフォームに要求することによって、トラステッドコンピューティングプラットフォームの正しいオペレーションを検証することができる。ユーザは、１つ又は複数の完全性メトリックを受け取り、それら完全性メトリックを、ユーザが正確であると考えている値と比較する（これらの値は、プラットフォームの信頼性を保証するために準備されたトラステッドパーティＴＰによって、又は、ユーザが快く信頼する別のパーティによって提供される）。一致する場合には、それが暗に意味するものは、完全性メトリックの範囲に応じて、プラットフォームの少なくとも一部が正しく動作しているということである。一致しない場合には、想定されることは、プラットフォーム全体が破壊されており、（切り離し技術が、信頼することができないものの範囲を限定するのに用いられない限り）信頼することができないということである。

ユーザは、プラットフォームの確立されたトラステッドオペレーションを確立すると、プラットフォームとデータを交換する。ローカルユーザの場合、この交換は、プラットフォーム上に実行されている或るソフトウェアアプリケーションと対話することによるものである場合がある。リモートユーザの場合、この交換は、セキュアなトランザクションを伴う場合がある。いずれの場合も、交換されるデータは、好ましくは、トラステッドプラットフォームによって「署名」される。ユーザは、その後、データが振る舞いを信頼することができるプラットフォームと交換されているというより大きな確信を有することができる。交換されるデータは、そのコンピュータプラットフォーム上で実行されているソフトウェアの一部又は全部に関する情報とすることができる。

信頼のルート（root of trust）を提供するトラステッドエンティティ
コンピューティングプラットフォームにトラステッドコンピューティングプラットフォームの特徴を与えるには、一定の本来的に信頼可能な機能（本明細書では、「トラステッドエンティティ」と呼ばれるものを集合的に構成する）をプラットフォームに提供することが必要である。これら信頼可能な機能は、プラットフォームに物理的又は論理的にバインドされ、コンピューティングプラットフォームのエレメントと共に、所望のトラステッドな特徴（最小で完全性の測定及び報告）を提供するように動作する。実際には、トラステッドエンティティは、プラットフォームに「信頼ルート」を提供する。この一例を以下で述べる。

ＴＣＧ仕様に従うトラステッドプラットフォームの場合、トラステッドエンティティは、トラステッドプラットフォームモジュール（「ＴＰＭ」）と呼ばれ、トラステッドエンティティがバインドされるコンピューティングプラットフォームのエレメントと共に、次の複数の「信頼ルート」を提供する働きをする。すなわち、１つは測定用の信頼ルート（root of trust for measurement）（ＲＴＭ）である。このＲＴＭは、本来的に信用できる完全性測定を行うことができるコンピューティングエンジンであり、通常は、いわゆる測定用のコア信頼ルート（core root of trust for measurement）（ＣＲＴＭ）によって制御される標準的なプラットフォームコンピューティングエンジン（メインプロセッサ）である。ＣＲＴＭは、ＲＴＭとして動作する時にプラットフォームによって実行される命令である。ＣＲＴＭは、論理的には、上記トラステッドエンティティの一部であり、理想的にはＴＰＭに含まれるが、コストの理由から、通常は、別個のＲＯＭによって実装される。

１つはストレージ用の信頼ルート（root of trust for storage）（ＲＴＳ）である。このＲＴＳは、完全性測定のダイジェストの値の正確な概要をＰＣＲに保持することができるコンピューティングエンジンである。また、ＲＴＳは、「保護されているストレージ」も提供し、ＲＴＳによるアクセス用のオパークな「ブロブ」（opaque blob）及び「シール」／「アンシール」として外部ストレージデバイスに保持されたデータ（多くの場合、鍵）を特定の環境（ＰＣＲ値によって示される）から保護するように働く。

１つは報告用の信頼ルート（root of trust for reporting）（ＲＴＲ）である。このＲＴＲは、プラットフォームの識別情報の確立、プラットフォーム構成（ＰＣＲ値）の報告、報告された値の保護、及び報告された値を証明する状況の確立を担当するコンピューティングエンジンである。ＲＴＲは、測定のダイジェストの保護の役割をＲＴＳと共有する。

上記に示したように、ＲＴＭを形成するエレメントは、通常（必ずしもそうではないが）、ＴＰＭの外部にあり、これとは対照的に、ＲＴＳ及びＲＴＲは、標準的にはＴＰＭ自体によって提供されることに留意することができる。

一般に、どのトラステッドプラットフォームも、このような信頼ルートを（ただし、場合によっては異なる概念的構成で）提供する。

トラステッドエンティティは、ハードウェアデバイス（プログラム制御されるプロセッサを含むことができる）として実施することもできるし、プラットフォームのメインプロセッサによって実行されるソフトウェアで実施することもできる（この場合、このプラットフォームは通例「仮想」トラステッドエンティティ／デバイス、又はＴＰＭの場合には仮想ＴＰＭと呼ばれる）。実際には、仮想トラステッドエンティティは、標準的には、基本プラットフォーム環境の基本ハードウェアトラステッドエンティティを有するプラットフォーム上ではあるが、プラットフォーム上に作成された仮想環境用のさらなるトラステッドエンティティを使用するプラットフォーム上に設けられる。

もちろん、ハードウェアデバイスと、プラットフォームプロセッサ上での実行を意図されるソフトウェアとの組み合わせとしてトラステッドエンティティを実装することも可能である。これは、たとえば、ＲＴＭをルートとした信頼チェーンによってソフトウェアの信頼性を確立できるトラステッドエンティティのより高レベルな機能（非コアの機能）を有するソフトウェアの実装に適している。

トラステッドエンティティの機能は、複数のデバイス間（ハードウェアの実施形態の場合）又はコードブロック間（「仮想的」な実施形態の場合）に分散させることができる。

トラステッドエンティティは、暗号プロセスを使用するが、必ずしもそれらの暗号プロセスに外部インターフェースを提供するとは限らない。トラステッドエンティティは、他のエンティティから論理的に保護されるべきである。これら他のエンティティには、トラステッドエンティティ自体がプラットフォームの一部である当該プラットフォームの他の部分が含まれる。また、ほとんどの望ましい実施態様は、トラステッドエンティティによって記憶された機密又は処理されている機密を他のプラットフォーム機能に対してアクセス不能にすることによってそれら機密を保護する保護用機能をトラステッドエンティティに提供し、認可されていない変更を実質的に免れる環境を提供する。

ハードウェアの実施形態の場合、トラステッドエンティティは、したがって、好ましくは、耐タンパ性を有する１つの物理コンポーネントから成る。耐タンパ性に関連のある技法は、セキュリティの当業者に既知である。これらの技法には、タンパリングを阻止する方法（トラステッドエンティティの適切なカプセル化等）、タンパリングを検出する方法（指定外の電圧の検出、Ｘ線の検出、又はトラステッドエンティティのケーシングの物理的完全性の喪失の検出等）、及び、タンパリングが検出された時にデータを削除する方法が含まれる。「仮想」トラステッドエンティティに関して、ソフトウェアは、このような高度な耐タンパ性をハードウェアデバイスとして与えない場合があるが、これは、追加の保護対策によって補償することができる。たとえば、ソフトウェアコードは、トラステッド機能の完全性をチェックする自己試験機能を含むことができる。ソフトウェアベースの実施態様を保護する他の対策も既知であろう。

信頼チェーン
プラットフォームにトラステッドエンティティが存在することによって可能にされる信頼可能な完全性の測定及び報告によって、通常、さらなるプラットフォームのコンポーネント又は機能等の信頼可能な完全性測定を次に行う他のプラットフォームのコンポーネント又は機能に信頼を置くことが可能になる。信頼可能であるものの境界を拡張するこのプロセスは、「推移的信頼（transitive trust）」と呼ばれ、プラットフォームの信頼ルートをルートとする信頼チェーンを確立するものとみなすことができる。したがって、一般的な例では、
初期完全性測定（ＴＣＧ用語でのＣＲＴＭ）を行うトラステッドコードは、（完全性メトリックが予測値と一致する場合に）ＯＳローダコードに信頼を置くことができるようにするために、このコードの完全性メトリックを測定する働きをする。
ＯＳローダコードは、次に、オペレーティングシステムに信頼を置くことができるようにするために、オペレーティングシステムコードの完全性メトリックを求める。
次に、オペレーティングシステムは、アプリケーションに信頼を置くことができるようにするために、アプリケーションコードの完全性メトリックを求める。

第１の例の従来技術のトラステッドプラットフォーム−概観
一例のトラステッドプラットフォーム１０が、図１の図式に示されている。このコンピューティングプラットフォーム１０は、いわゆるパーソナルコンピュータとして示され、外観は完全に従来のものである。コンピューティングプラットフォーム１０は、キーボード１４、マウス１６、及び視覚表示ユニット（ＶＤＵ）１８の標準的機能を関連付けている。これらの標準的機能は、プラットフォームの物理的な「ユーザインターフェース」を提供する。コンピューティングプラットフォーム１０は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ＸＰ等の標準的なオペレーティングシステムを実行するように構成されている。

図２に示すように、トラステッドコンピューティングプラットフォーム１０のマザーボード２０は、（他の標準的なコンポーネントの中でも特に）メインプロセッサ２１、メインメモリ２２、ここではトラステッドデバイス２４の形で具現化されたトラステッドエンティティ（ハードウェアＴＰＭ等）、データバス２６並びに各制御ライン２７及び各アドレスライン２８、プラットフォーム１０用のＢＩＯＳプログラムを含むＢＩＯＳメモリ２９、入出力（ＩＯ）デバイス２３、並びにリモートデバイス又はリモートシステムとの通信を制御するたとえばイーサネット（登録商標）コントローラといったＩ／Ｏデバイス２５を含む。入出力デバイス２３は、マザーボードのコンポーネントと、キーボード１４、マウス１６、及びＶＤＵ１８との間の相互作用を制御する。メインシステムメモリ２２は、通常、ランダムアクセスメモリ（ＲＡＭ）である。動作中、プラットフォーム１０は、この場合にはＷｉｎｄｏｗｓ（登録商標） ＸＰであるオペレーティングシステムをハードディスク（図示せず）からＲＡＭにロードする。加えて、動作中、プラットフォーム１０は、プラットフォーム１０によって実行可能なプロセス又はアプリケーションをハードディスク（図示せず）からＲＡＭにロードする。マザーボード上のトラステッドデバイス２４の実装は、トラステッドデバイス２４をプラットフォームにバインドする働きをする。

通常、パーソナルコンピュータでは、ＢＩＯＳプログラムは、システムメモリの最初の１メガバイトの上位６４Ｋ（アドレスＦ０００ｈ〜ＦＦＦＦｈ）等の特別な予約済みのメモリエリアに配置され、メインプロセッサは、業界全体の標準規格に従って、このメモリロケーションを最初に調べるように構成されている。説明されているトラステッドプラットフォームと従来のプラットフォームとの間の大きな相違は、リセット後、メインプロセッサが、初期にＣＲＴＭコード（本例では、トラステッドデバイス２４に記憶されたハッシュ関数コードを含む）によって制御されるということである。ＣＲＴＭコードは、次に、プラットフォーム特有のＢＩＯＳプログラムに制御を手渡す。プラットフォーム特有のＢＩＳＯプログラムは、次に、通常通りすべての入出力デバイスを初期化する。ＢＩＯＳプログラムが実行された後、制御は、通常通り、ＢＩＯＳプログラムによって、Ｗｉｎｄｏｗｓ（登録商標） ＸＰ等のオペレーティングシステムプログラムに手渡される。オペレーティングシステムプログラムは、通常、ハードディスクドライブ（図示せず）からメインメモリ２２にロードされる。

トラステッドプラットフォーム上で実行される最初の測定に信頼を置くことが必要であることから、メインプロセッサ２１は、初期にＣＲＴＭコードによって制御される。ＣＲＴＭコードは、通常、その出所によって、少なくとも部分的に信頼される。すでに示したように、メインプロセッサ２１は、ＣＲＴＭの制御下にある時、「測定用の信頼ルート」ＲＴＭを形成する。通常通り、この場合のＲＴＭの１つの役割は、他の測定エージェントが使用されてそれらの測定が依拠される前に、それら他の測定エージェントを測定することである。ＲＴＭは、上述した「信頼チェーン」の基礎である。ＲＴＭ及び後続の測定エージェントは、後続の測定エージェントを検証する必要がないことに留意されたい。ＲＴＭ及び後続の測定エージェントは、後続の測定エージェントが実行される前にそれら後続の測定エージェントを単に測定して記録するだけである。これは、「認証されたブートプロセス（authenticated boot process）」と呼ばれる。測定エージェントのダイジェストを有効な測定エージェントのダイジェストのリストと比較することによって、有効な測定エージェントを認識することができる。リストされていない測定エージェントは、認識されず、それら測定エージェント及び後続の測定エージェントによって行われた測定は疑わしいと考えられる。

トラステッドデバイスの例
次に、トラステッドデバイス２４の一実施態様のさらに詳細な内容を述べることにする。対応する機能は、ソフトウェアトラステッドエンティティ（すなわち、仮想トラステッドデバイス）で提供できることが理解される。

トラステッドデバイス２４は、図３に示すように、複数のブロックを備える。すでに示したように、システムリセット後、トラステッドデバイス２４は、認証されたブートプロセスに参加して、プラットフォーム１０の動作状態が安全な方法で確実に記録されるようにする。認証されたブートプロセスの期間中、トラステッドデバイス２４は、コンピューティングプラットフォーム１０の少なくとも１つの完全性メトリックを取得する。また、トラステッドデバイス２４は、自身とスマートカードとの間で暗号化／解読及び署名／検証を介して、セキュアなデータ転送、及び、たとえば認証も行うことができる。さらに、トラステッドデバイス２４は、ユーザインターフェースのロック等、さまざまなセキュリティ制御ポリシーをセキュアに施行することもできる。特に好ましい一構成では、コンピューティングプラットフォームのディスプレイドライバは、トラステッドデバイス２４内に配置され、その結果として、ローカルユーザは、トラステッドデバイス２４によってディスプレイに提供されたデータの表示を信頼することができる。

具体的には、この実施形態のトラステッドデバイス２４は、コントローラ３０、測定機能３１、暗号機能３２、認証機能３３、及びインターフェース回路部３４を備える。コントローラ３０は、トラステッドデバイス２４の全体オペレーションを制御し、且つ、トラステッドデバイス２４上の他の機能及びマザーボード２０上の他のデバイスと相互作用するようにプログラミングされている。測定機能３１は、直接的な測定を介して、代替的には、プラットフォームのメインプロセッサで実行される実行可能命令を介して間接的にのいずれかでプラットフォーム１０から第１の完全性メトリックを取得する。暗号機能３２は、指定されたデータの署名、暗号化／解読を行う。認証機能３３は、スマートカードを認証する。インターフェース回路部３４は、トラステッドデバイス２４を、マザーボード２０のデータバス２６、制御ライン２７、及びアドレスライン２８にそれぞれ接続する適切なポート（３６、３７、及び３８）を有する。トラステッドデバイス２４のブロックのそれぞれは、トラステッドデバイス２４の適切な揮発性メモリエリア４及び／又は不揮発性メモリエリア３に（通常はコントローラ３０を介して）アクセスすることができる。既に説明したように、トラステッドデバイス２４は、既知の方法で、耐タンパ性を有するように設計されている。

性能の理由から、トラステッドデバイス２４は、特定用途向け集積回路（ＡＳＩＣ）として実装される場合がある。一方、柔軟性のために、トラステッドデバイス２４は、好ましくは、適切にプログラミングされたマイクロコントローラである。ＡＳＩＣ及びマイクロコントローラの双方は、マイクロエレクトロニクスの技術分野で既知であり、本明細書では、これ以上詳細に検討しないことにする。

好ましくはトラステッドデバイス２４の不揮発性メモリ３に記憶された１つのデータアイテムは証明書３５０である。この証明書３５０は、トラステッドデバイス２４の公開鍵３５１、及び、トラステッドパーティ（ＴＰ）によって測定されたプラットフォーム完全性メトリックの認証値３５２を少なくとも含む。証明書３５０は、トラステッドデバイス２４に記憶される前に、ＴＰの私有鍵を使用してＴＰによって署名される。後の通信セッションにおいて、プラットフォーム１０のユーザは、証明書のＴＰの署名を検証することによって、公開鍵がトラステッドデバイスに属することを推論することができる。また、プラットフォーム１０のユーザは、取得された完全性メトリックを真正な完全性メトリック３５２と比較することによってプラットフォーム１０の完全性を検証することもできる。一致する場合、ユーザは、プラットフォーム１０が破壊されていないことを確信することができる。ＴＰの一般に利用可能な公開鍵を知ることによって、証明書３５０の簡単な検証が可能になる。不揮発性メモリ３５は、識別（ＩＤ）ラベル３５３も含む。ＩＤラベル３５３は、或る状況において一意である、たとえばシリアル番号といった従来のＩＤラベルである。ＩＤラベル３５３は、一般に、トラステッドデバイス２４に関連のあるデータのインデックス及びラベルに使用されるが、それ自体では、信頼された状況下でプラットフォーム１０の識別情報を証明するには不十分である。

すでに示したように、トラステッドデバイス２４は、プラットフォームの少なくとも１つの完全性メトリックを確実に取得するために、プラットフォーム１０の他の要素と協力する。本実施形態では、トラステッドデバイス２４に記憶されるＣＲＴＭコードをメインプラットフォームプロセッサに実行させることによって、第１の完全性メトリックが取得される。ＣＲＴＭは、プラットフォームプロセッサによって実行されると、ＢＩＯＳメモリにおけるＢＩＯＳ命令のダイジェストを生成し、このダイジェストを、記憶するために測定機能に渡す。取得されたこのような完全性メトリックは、上述したように検証された場合、プラットフォーム１０がハードウェアレベル又はＢＩＯＳプログラムレベルにおいて破壊されていないという高レベルの確信をプラットフォーム１０の見込みユーザに与える。

代替的に、トラステッドデバイス内に測定エンジンを設け、このエンジンに、プラットフォームの起動（リセット）時にＢＩＯＳコードについての完全性メトリックを形成させることも可能である。

本例では、測定機能３１は、トラステッドデバイス２４のＣＲＴＭハッシュコード３５４及び私有鍵３５５を記憶する不揮発性メモリ３、並びに、取得された完全性メトリック測定値を記憶する揮発性メモリ４にアクセスすることができる。トラステッドデバイス２４は、メモリが限られているが、多数の完全性メトリック測定に関する情報を記憶することが望ましい場合がある。これは、トラステッドコンピューティンググループによって説明されているようなトラステッドコンピューティングプラットフォームでは、プラットフォーム構成レジスタ（ＰＣＲ）８ａ〜８ｎを使用することによって行われる。トラステッドデバイス２４は、固定サイズ（標準的な測定ダイジェストと同じサイズ）の複数のＰＣＲを有する。プラットフォームの初期化の際に、これらＰＣＲは、一定の初期値に設定される。完全性測定値は、次に、図４に示すプロセスによってＰＣＲ内に「拡張される（extended）」。ＰＣＲ８ｉの値は、入力４１と連結される（４３）。この入力４１は、ＰＣＲまで拡張される完全性測定の値である。この連結したものは、次に、ハッシュされて（４２）、新しい１６０ビット値が形成される。このハッシュは、ＰＣＲにフィードバックされて、関係している完全性メトリックの新たな値が形成される。完全性測定値のＰＣＲ内への拡張に加えて、実行された測定の明瞭な履歴を提供するために、測定プロセスも、従来のログファイル（単純にコンピュータプラットフォームのメインメモリに存在することができる）に記録することができる。しかしながら、信頼のために、このログファイルは、依拠されるＰＣＲ値であり、ソフトウェアログではない。

明らかに、必要とされる信頼の範囲に応じて、初期の完全性メトリック値を計算できる複数の異なる方法が存在する。ＢＩＯＳプログラムの完全性の測定は、プラットフォームの基礎を成す処理環境の完全性に対する基本的なチェックを提供する。完全性メトリックの測定は、ブートプロセスの有効性についての論理的判断を可能にするような形態を有するべきである。完全性メトリックの値は、プラットフォームが、正しいＢＩＯＳを使用してブートしたか否かを検証するのに使用することができる。オプションとして、ＢＩＯＳ内の個々の機能ブロックは、それら機能ブロック自体のダイジェスト値を有することができ、集合ＢＩＯＳダイジェスト（ensemble BIOS digest）は、これらの個々のダイジェストのダイジェストである。これによって、ポリシーは、ＢＩＯＳオペレーションのどの部分が、意図された目的にとって重要であるのか、及び、どの部分が無関係であるのかを提示することが可能になる（この場合、このポリシーの下でのオペレーションの有効性を確立できるような方法で個々のダイジェストを記憶しなければならない）。

好ましくは、ＢＩＯＳブートプロセスは、ブートプロセス自体の完全性を検証するメカニズムを含むことに留意することができる。このようなメカニズムは、たとえば、Intelの草案「Wired for Management baseline specification v 2.0 - BOOT Integrity Service」からすでに知られており、ソフトウェア又はファームウェアをロードする前に、そのソフトウェア又はファームウェアのダイジェストを計算することを伴う。このような計算されたダイジェストは、トラステッドエンティティによって提供される証明書に記憶された値と比較される。この証明書の公開鍵はＢＩＯＳに知られている。次に、ソフトウェア／ファームウェアは、計算された値が証明書からの予測値と一致し、且つ、証明書が、トラステッドエンティティの公開鍵を使用することによって有効であると証明された場合にのみロードされる。そうでない場合、適切な例外ハンドリングルーチンが起動される。オプションとして、トラステッドデバイス２４は、計算されたＢＩＯＳダイジェストを受け取った後、証明書のＢＩＯＳダイジェストの適切な値を検査することができ、計算されたダイジェストがこの適切な値と一致しない場合には、ＢＩＯＳに制御を渡すことができず、適切な例外ハンドリングルーチンを起動することができる。

ＢＩＯＳコードが測定され（且つ、好ましくは検証され）、次いでロードされると、ＢＩＯＳは、好ましくは、次のソフトウェアコンポーネント（ＯＳローダ等）を、そのソフトウェアのロード前に測定して、対応する完全性メトリック測定値をトラステッドデバイス２４に記憶する。このように、オペレーティングシステム及びオペレーティングシステムによってロードされるアプリケーションを含め、対応する完全性メトリックがトラステッドデバイス２４のＰＣＲに記憶されるように、信頼チェーンを構築することができる。

他の完全性チェックは、プログラムコードの測定、及び、対応する完全性メトリック測定のトラステッドデバイスへの記憶を伴って実行することができる。たとえば、ＳＣＳＩコントローラに関連するＢＩＯＳプログラムを測定するようにＣＲＴＭ又はＢＩＯＳを構成して、周辺機器との通信を信頼できるようにすることができる。他の形態の完全性チェックも行うことができ、たとえば、一定の誰何／応答相互作用を規定して一致した結果を確実にすることによって、プラットフォーム上のメモリデバイス又はコプロセッサを検証することができる。これらのチェックによっても、完全性メトリックはトラステッドデバイス２４のＰＣＲに記憶することができる。

上記から明らかなように、ＲＴＭによって直接又は間接に測定されるエージェントを測定することによって、多数の完全性測定値を収集することができ、これらの完全性測定値をトラステッドデバイス２４のＰＣＲ内に拡張することができる。これらの完全性測定値のいくらか−多く−は、トラステッドプラットフォームのソフトウェア状態に関係する。ＰＣＲを割り当てる方法は、好ましくは、プラットフォームタイプごとに標準化される。例として、ＰＣクライアント用のＴＣＧ仕様によれば、ＰＣＲは、２つの主要セットに分割される。第１のセットは、プラットフォームのＯＳ以前の環境用に指定され（ＰＣＲ［０〜７］）、他方は、プラットフォームのＯＳ用に指定される（ＰＣＲ［８〜１５］）。この場合、ＯＳ以前のＰＣＲは、プラットフォームのリセットから開始するプラットフォームの初期信頼チェーンを提供する。換言すれば、ＯＳ以前のＰＣＲは、ＯＳのＩＰＬ（初期プログラムロード）コードを通じてＣＲＴＭからの信頼チェーンを確立する。

ソフトウェアコンポーネントの初期の測定及びロードの後におけるそのソフトウェアコンポーネントに対する変更の結果、ソフトウェアコンポーネントは再測定され、その結果得られた完全性測定値はトラステッドデバイスに渡されて、そのコンポーネントに関連付けられるＰＣＲは拡張される。

すでに示したように、ユーザは、プラットフォームと通信したいとき、チャレンジ／レスポンスルーチンを使用して、トラステッドデバイス２４をチャレンジする（プラットフォームのオペレーティングシステム又は適切なソフトウェアアプリケーションは、そのチャレンジを認識し、通常はＢＩＳＯタイプのコールを介して適切な方法でそのチャレンジをトラステッドデバイス２４に渡すように構成されている）。トラステッドデバイス２４は、チャレンジを受け取り、測定された１つ又は複数の完全性メトリックに基づいて適切なレスポンスを作成する。このレスポンスは、予測された完全性メトリック値（複数可）を与える証明書（複数可）と共に提供することができ、署名することができる。このレスポンスは、ユーザによる検証を可能にするのに十分な情報を提供する。

保護されているストレージシール／アンシールデータ
上記に示したように、トラステッドデバイス２４等のトラステッドエンティティは、そのトラステッドエンティティの外部に保持されたオパークブロブ内にデータ（通常は鍵又はパスワード）をシールする「保護されているストレージ」メカニズムを提供するトラステッド機能（ＲＴＳ）を含むことができる。このブロブは、その後、プラットフォームが特定の（トラステッド）状態にある時にのみアクセス可能になる。この状態は、一部又は全部のＰＣＲの値のダイジェストによって、シールの時に指定される。データブロブをアンシールするには、ＰＣＲの現在の値から同じダイジェストが形成されなければならない。新しいダイジェストが、オパークブロブのダイジェストと同じでない場合、ユーザは、データを回復することができない。

次に、保護されているストレージをトラステッドデバイス２４で実装する１つの手法を説明することにする。この手法は、ＴＰＭで使用されるものである。図５に示すように、この手法では、保護されているストレージは、データオブジェクトの階層（ツリー）５２として実装される。このツリーのルートは、トラステッドデバイス２４に永久記憶される（且つ、トラステッドデバイス２４から解放されない）ストレージルート鍵（ＳＲＫ）５１である。ツリー５２は、ＳＲＫから離れて、トラステッドデバイスの外部の標準的なメモリ５４に記憶することができる。ノードの情報が使用されるか又は明らかにされる時、そのノードは、トラステッドデバイスによって操作される。ＳＲＫルートノードまでのすべてにわたって、ツリーの各中間ノードオブジェクトは、ツリーにおいてその中間ノードオブジェクトの上のノードオブジェクト（親ノード）の鍵によって暗号化される。図５では、ＳＲＫの下に２つのレベル、すなわち、鍵Ｋ１−１〜Ｋ１−３を記憶する第１のレベル、並びに、鍵Ｋ２−１及びＫ２−２を記憶する第２のレベルが示されている。各鍵が暗号化されているという性質は、周囲の網掛けされた輪によって示されている。各鍵は、トラステッドデバイスがその鍵の使用を許可する前に、その鍵を利用したいエンティティがトラステッドデバイス２４に提示しなければならない関連する認可値を有する（又は、より正確には、その値を明らかにすることなく、その値を知っていることを証明するプロトコルで使用される）。ツリーの中間ノードは、常に鍵であるが、リーフノードは、任意のデータとすることができる（ただし、リーフノードも、バルクデータを保護する際にアプリケーションプロセスによる使用用の対称鍵等の鍵であることが多い）。ツリーの鍵は、私有鍵がトラステッドデバイスにのみ知られていることを意味する「マイグレーション不可能」とすることもできるし、私有鍵の起源及び使用についての保証がないことを意味する「マイグレーション可能」とすることもできる。

第２の例の従来技術のトラステッドプラットフォーム
オペレーティングシステム及びオペレーティングシステムによってロードされたアプリケーションの完全性メトリックが記録されているものと仮定すると、上述したトラステッドプラットフォーム１０によって、ユーザは、プラットフォームの状態をチェックし、そのプラットフォームを信頼するか否かを決定することが可能になる。オペレーティングシステムが、第１のユーザによって信頼されない（ただし、場合によっては異なるユーザによって信頼される）アプリケーションを実行していた場合、その第１のユーザは、（たとえ、アプリケーションが終了した後であっても）、関連のあるＰＣＲをチェックすることによってこれを検出することができる。しかしながら、この場合、上述したトラステッドプラットフォームについて、プラットフォームにおける信頼を第１のユーザに対して再確立する唯一の方法は、そのプラットフォームを再起動することである。この欠点は、プラットフォームが、複数のコンピューティング環境をサポートする区画化されたオペレーティングシステムを実行するのに使用される場合に増大される。その理由は、適切な対策が機能していない限り、非トラステッドアプリケーションを複数の環境のうちのいずれかで実行するには、プラットフォームを再起動して信頼を再確立する必要があるからである。

これに対する解決法は、コアソフトウェア（ＢＩＯＳ及びオペレーティングシステム／ハイパーバイザ）を高レベルソフトウェアから切り離すことを可能にするハードウェア／ソフトウェアアーキテクチャを提供し、高レベルソフトウェアが信頼されない場合に、コアソフトウェア（コアソフトウェアは信頼されるものと仮定する）から信頼を再構築するだけで足りるようにすることである。コアソフトウェアが、複数のコンピューティング環境をサポートする場合において、複数のコンピューティング環境が互いに切り離されているときは、コアソフトウェアも、コアソフトウェアによってサポートされる他のコンピューティング環境も再起動することなく、非トラステッド環境を再起動することができる。さらに、複数のコンピューティング環境がサポートされる場合に、このような各環境についてそれぞれのトラステッドエンティティ（通常は仮想トラステッドデバイス）を提供することが好都合である。

次に、図６を参照して、複数の切り離されたコンピューティング環境をサポートする一例のトラステッドプラットフォーム６０を簡潔に説明することにする。このタイプのトラステッドプラットフォームのより完全な説明は、米国公開特許出願第ＵＳ２００３／０２２６０３１号に見つけることができる。

図６に示すトラステッドプラットフォーム６０は、１つ又は２つ以上のプラットフォームプロセッサ６１及びハードウェアトラステッドデバイス６２を有する。このハードウェアトラステッドデバイス６２は、上述したトラステッドデバイス２４と同様のものであるが、ＣＲＴＭを形成するコードが別個のＲＯＭ６３に存在する。プラットフォーム１０及びトラステッドデバイス２４について上述したのと同等の方法で、プラットフォームのリセットに続いて、ＣＲＴＭコードは、メインプラットフォームプロセッサ６１の１つによって実行されて、（たとえばＣＲＴＭと同じＲＯＭ６３に記憶された）ＢＩＯＳコードの完全性メトリックを求め、そして、そのメトリックをＰＣＲに挿入するためにトラステッドデバイス６２に渡す。その後、ＢＩＯＳ６４がロードされる。ＢＩＯＳは、次に、セキュリティカーネル６５をロードする前に、セキュリティカーネルコードの完全性メトリックを測定してトラステッドデバイス６２に記録する。セキュリティカーネル６５は、次に、ハイパーバイザ６６（仮想マシンモニタとも呼ばれる）をロードする前に、ハイパーバイザコードの完全性メトリックを測定してトラステッドデバイス６２に記録する。実際には、通常、より多くの完全性メトリックが記録され、中間コードモジュールがロードされるであろう。ＢＩＯＳ６４及びセキュリティカーネル６５は、メインプラットフォームプロセッサ６１の最高特権レベルで実行される一方、ハイパーバイザ６６は、メインプラットフォームプロセッサ６１の２番目に高い特権レベルで実行される。他のすべてのコードは、より低い特権レベルで実行され、したがって、ＢＩＯＳ及びハイパーバイザ／セキュリティカーネル６５を信頼できない可能性のあるコードから切り離すことが提供される。エレメント６１〜６５は、プラットフォーム６０のトラステッドコンピューティングベース６００を形成する。ハイパーバイザ６６等の任意の複雑なプログラムについて、プラットフォーム上のハイパーバイザコードが基準バージョンと同一であることを検証することは可能であるが、その基準バージョン自体がセキュリティ弱点を全く所有していないことを確信することが非常に困難であることを条件として、ハイパーバイザ６６も、トラステッドコンピューティングベースの一部とみなすことができる。

ハイパーバイザ６６によって、複数のオペレーティングシステム環境を他のオペレーティングシステム環境から切り離されたそれ自身のパーティションにそれぞれ設けることが可能になる。図６では、例として、３つのオペレーティングシステム環境６８Ａ、６８Ｂ、及び６８Ｃが、それ自身のそれぞれのパーティション６７Ａ、６７Ｂ、６７Ｃにそれぞれ示されている。各パーティションは、異なるプラットフォームプロセッサ６１上で実行されるように構成することができ、それによって、切り離しの程度が改善される。ハイパーバイザ６６は、パーティション間の通信及び外部の世界との通信を可能にし且つ保護する。アプリケーションは、オペレーティングシステム環境のうちの適切な１つで必要に応じて実行される。この場合では、オペレーティングシステム環境６８Ａで実行される１つのアプリケーション６０１が示されている。アプリケーションは、通常、オペレーティングシステム環境の特権レベルよりも下の最低特権レベルで実行される。

本例では、各パーティション６７Ａ、６７Ｂ、６７Ｃは、それ自身の関連する仮想トラステッドデバイス６９Ａ、６９Ｂ、６９Ｃを有する（ただし、図６では、各パーティションにおいて、仮想トラステッドデバイスは、論理的にセキュリティカーネルの一部であり、同じ特権レベル又は個別のパーティションで実行される）。パーティションの仮想トラステッドデバイスは、関連するオペレーティングシステム環境及びこのオペレーティングシステム環境が実行しているあらゆるアプリケーションの完全性メトリックを測定して記録するのに使用される。

プラットフォーム６０によって提供された切り離しは、任意の特定のパーティションにおいて、信頼を再確立するために再起動しなければならないソフトウェアを最小にすることが十分理解されよう。また、パーティションごとに１つのハードウェアトラステッドデバイス６２及び１つの仮想トラステッドデバイスを有する構成は、すべてのプラットフォーム用に単一のハードウェアトラステッドデバイス又は仮想トラステッドデバイスしか有しないことを含む、多くのものの中の１つの可能性にすぎないことも十分理解されよう。

発明の実施形態
上述した従来技術のトラステッドデバイス２４では、特定のソフトウェアコンポーネント又はコンポーネントの集合に関する完全性測定値は、同じＰＣＲの最後のリセット以降、その同じＰＣＲに前に記憶された値と累積的に組み合わせることによって特定のＰＣＲに記憶される。これによって、信頼できないソフトウェアを示す測定値が、ＰＣＲのすべての後続の値に影響を与え、（たとえ、関連しているソフトウェアがアンロードされた後であっても）信頼できないソフトウェアがロードされたことを可視的に保つことが可能になる。しかしながら、この構成は、ソフトウェアコンポーネントが（たとえば、ソフトウェア更新を通じて）別の形態に変化するか若しくは現在の状態に適応することが認められている状況、又は、システムコンポーネントが（たとえば、異なる構成を有する）さまざまな動作モード間で変化して、変化するセキュリティニーズを有するオペレーションを実行する状況を効率的に取り扱わない。いずれの状況でも、たとえこの変化がコンポーネントのセキュリティに影響を与えることができない場合であっても、ソフトウェアコンポーネントは、この変化に続いて更新されたその関連するＰＣＲの値に従って信頼される状態から信頼されない状態に移行する可能性がある。ＴＣＧ仕様は、保守的な手法を取り、このようなどの変化も、悪意があり、撤回できない可能性があるものと考え、その結果、信頼を再確立するために、プラットフォーム（特権レベルなしで動作するプラットフォームの場合）、又は、関連しているパーティション（図６を参照して上述したようなプラットフォームの場合）のいずれかを再起動することが必要である。

本発明の実施形態の以下の説明では、ソフトウェアコンポーネントが受ける可能性がある変更が、第１のタイプと第２のタイプとに分割される。第１のタイプ又は第２のタイプとしての変更のカテゴリー化は、コンポーネントに依存し、コンポーネントに関連付けられる「変更タイプ」ポリシーに設定されるが、大まかに言えば以下の通りである。
第１のタイプの変更は、コンポーネントの完全性を再確立するためにそのコンポーネントを再起動する必要がある変更である。このような変更は、コンポーネントの完全性にクリティカルな部分（integrity critical part）に対して行われる変更、すなわち、コンポーネントがその目的とする機能を正しく実施する能力に影響を与える可能性のあるコンポーネントのコード又は他のデータに対して行われる変更である。便宜上、以下では、このような変更を「クリティカル」変更と呼ぶ。クリティカル変更の一例は、カーネルが、新しいドライバをコンポーネントのメモリにロードすること、又は、アプリケーションが、コンポーネントの振る舞いに影響を与えるようにコンポーネントのメモリにプラグインをロードすることとすることができる。
第２のタイプの変更は、第１のタイプの変更とは異なる変更である。このような変更は、コンポーネントの完全性にクリティカルでない部分に対して行われる変更、すなわち、コンポーネントがその目的とする機能を実施する能力に実質的に影響を与えないコンポーネントのコード又は他のデータに対して行われる変更である。以下では、第２のタイプの変更を「非クリティカル」変更と呼ぶ。非クリティカル変更の特定の例は、構成の変更又はモード変更とすることができる。

変更のこのような分類が行われて、コンポーネントの完全性を判断する際に使用されるソフトウェアコンポーネントを、以下では、「動的」コンポーネントと呼ぶ（その理由は、理解されるように、その信頼性が何度も変化する可能性があるからである）。

第１の実施形態
次に、図７及び図８を参照して、本発明の第１の実施形態を説明することにする。この実施形態によれば、動的コンポーネント７１が作成される時、特殊なタイプのトラステッドエンティティ７５が、その動的コンポーネント７１に１対１に関連付けられる（この特殊なタイプのトラステッドエンティティは、以下では、動的コンポーネントに関係していることを示すために、「動的トラステッドエンティティ」、すなわち「ＤＴＥ」と呼ぶ）。

動的コンポーネント７１は、そのコンポーネントの目的とする標準的な機能Ｆを提供するコードに加えて、コンポーネントに対する変更が信頼回復不能な変更であるのか、又は信頼回復可能な変更であるのかを判断する際に使用する変更タイプポリシーエレメント７２、及び、コンポーネント自体に対する変更を測定する測定エージェント（複数可）７３を備える。動的コンポーネントがその関連付けられるＤＴＥ７５と通信することを可能にする適切なメカニズムが提供される。変更タイプポリシー７２及び測定エージェント７３の双方は、動的コンポーネント７１の一部として示されているが、コンポーネント７１に関連付けられる状態を維持しながら、分離して配置することもできる。

すでに示したように、ＤＴＥ７５は、特殊なタイプのトラステッドエンティティであり、ほとんどの場合、（たとえば、適切な特権レベルにおいて、又は、別個のパーティションで実行することによって）セキュアな環境で実行される仮想トラステッドエンティティとして実施される。図７にボックス７６によって示すように、ＤＴＥ７５は、永続的な識別情報を有する。ＤＴＥ７５は、動的コンポーネント７１上で行われた完全性測定を保持する静的レジスタ７８及び動的レジスタ７９の双方を備える。「レジスタ」は、単にメモリロケーションを意味するものにすぎない。静的レジスタ７８に記憶される完全性測定値は、そのレジスタに保持された既存の値と組み合わされる。すなわち、このレジスタ値は、（たとえば、従来技術のＰＣＲが拡張される方法と同様の方法で）拡張される。これとは対照的に、動的レジスタ７９に記憶される完全性測定値は、そのレジスタに保持された前の値に単に取って代わるだけである。ＤＴＥ７５は、完全性メトリックマネージャ７７をさらに備える。この完全性メトリックマネージャ７７は、レジスタ７８、７９に完全性測定を記憶し、且つ、レジスタ値を確実に報告する機能を提供する。また、ＤＴＥ７５は、コンポーネント７１の予測測定値も保持することができる。

動的コンポーネント７１が作成される時、作成エンティティは、少なくとも、動的コンポーネントがその目的とする機能を正しく実施する能力に影響を与える可能性のある動的コンポーネント７１の部分（コード及び他のデータ）の完全性メトリックを取得し、このメトリックの値をＤＴＥ７５の静的レジスタ７８に置く。また、作成エンティティは、少なくとも、コンポーネントがその目的とする機能を実施する能力に影響を与えない動的コンポーネントの部分（コード及び他のデータ）の完全性メトリックも取得することができ、このメトリックの値をＤＴＥ７５の動的レジスタ７９に置く。それ以降、静的レジスタ７８は、（完全性メトリックマネージャ７７の援助を受けて）コンポーネント７１自体によってのみ更新を受けることができるのに対して、動的レジスタ７９は、（完全性メトリックマネージャ７７を介して）コンポーネント７１及び作成エンティティの双方によって更新を受けることができる（作成エンティティは、ポリシー７２にアクセスするか、又は、非クリティカル変更を認識できるように同等の知識を有するものと仮定する）。

動的コンポーネント７１は、その構造に対する変更を測定して報告する権限を有する。したがって、変更が、（たとえば、動的コンポーネントのいずれかの部分を保持するロケーションに対する何らかの書き込みオペレーションを検出するコードセットによって）判断されると、動的コンポーネントは、その実行された部分（すなわち、クリティカル変更の場合にはその完全性にクリティカルな部分、又は、非クリティカル変更については完全性にクリティカルでない部分のいずれか）を測定する。クリティカル変更の場合、結果として行われる測定は、静的レジスタ７９の値を拡張するのに使用され、クリティカル変更が行われたという永続的表示が効果的に作成される。非クリティカル変更の場合、新しい完全性測定が、動的レジスタ７９に保持されている以前の値に単に取って代わるだけである。

レジスタ７８及び７９の双方に記憶されている測定値に応じて、動的コンポーネント７１は、次の３つのローカルな完全性状態の１つになることができる。

静的レジスタ７８及び動的レジスタ７９の値が、予測測定値と一致する場合には、完全性は「損なわれていない」（コンポーネント自体は信頼可能である）。

静的レジスタ７８の値が予測測定値と一致しているが、動的レジスタの値が一致していない場合には、完全性は「回復可能」である。

それ以外のすべての場合には、完全性は「回復不可能」である。これらの状態間の関係は、図８の状態図に示されている。

上記構成によって、非クリティカル変更しか受けていない動的コンポーネントは、その信頼可能な状態に復旧することが可能になり、これを、レジスタ７８及び７９に記憶されているその完全性メトリック値に反映させることが可能になる。また、動的レジスタは、ユーザに知られているがＤＴＥには知られていない予測値と一致するので、ユーザは、ＤＴＥ７５に知られている予測レジスタ値に従ってその回復可能な状態にある動的コンポーネントを快く信頼することができる。

コンポーネントの階層
関連付けられるＤＴＥ７５と共に動的コンポーネント７１を有するという概念は、このようなコンポーネントの階層の状況で特に効果を発揮する。各コンポーネントは、好ましくはそれ自身の切り離された環境（ハイパーバイザパーティション等）にあり、子コンポーネントを作成することができる。図９に示すように、この場合、親コンポーネント７０によって起動された動的コンポーネント７１は有利には、（ポリシー７２及び測定エージェント（複数可）７３に加えて）
１．必要なコンポーネント機能を提供する機能群Ｆと、
２．機能群が実行される実行環境ＥＮＶと、
３．１）及び２）の双方のパラメータを定義する構成群Φと
を備える。

図１０は、それぞれがそれ自身の動的トラステッドエンティティ７５（ＤＴＥｉ−１、ＤＴＥｉ、ＤＴＥｉ＋１）を有する３つの動的コンポーネント７１（Ｃｉ−１、Ｃｉ、Ｃｉ＋１）の階層的配置を示す。各動的コンポーネントＣｉは、関連付けられるＤＴＥｉと共に、その親コンポーネントＣｉ−１によって作成される。作成中、各ＤＴＥｉには、階層におけるそのコンポーネントのロケーションをも示す永続的な識別情報が与えられる。図１０に示すように、子コンポーネントの実行環境ＥＮＶＣは、親の実行環境ＥＮＶＰのサブセットである。したがって、各コンポーネントＣｉは、１つの直接の祖先（すなわち、親）しか有することができない。その結果生成される依存関係は、関係しているトラステッドプラットフォームの信頼ルートをルートとするコンポーネントツリーで表すことができる。

この依存ツリーは、動的コンポーネントの機密に付属した動的アクセス制御ポリシーを施行するのに使用することができる。これらのポリシーは、どのような状態の下でコンポーネントが、関連付けられるＤＴＥによって提供された保護されているストレージに保持された自身の機密にアクセスすることを認められるのかを決定する。ポリシーは、ＤＴＥによって施行される。たとえば、アクセス制御ポリシーは、動的コンポーネント及びその祖先の完全性が損なわれていない場合に限って、動的コンポーネントが自身の機密にアクセスすることを認めることができる（これは、ＤＴＥが、適切な要求をその親コンポーネントに行うことによって祖先コンポーネントの完全性状態を取得することを必要とし、これを行うことを可能にするために、各ＤＴＥ７５は、その関連付けられる動的コンポーネント７１の親７０を知っていることが好ましい）。

第２の実施形態
次に、図１１を参照して本発明の第２の実施形態を説明する。図９に関連して説明した第１の実施形態の階層形態と同様に、第２の実施形態では、動的コンポーネント７１が、それぞれの動的トラステッドエンティティＤＴＥにそれぞれ関連付けられている。動的コンポーネント７１は、階層的に編成される。図１１では、文字Ｂ〜Ｉによって個別に識別される８つの動的コンポーネント７１が示されているが、明瞭にするために、動的コンポーネント７１ＥのＤＴＥ７５'Ｅしか示されていない。ＤＴＥ７５'の形態は、第１の実施形態に関連して説明したものとは異なる。詳細には、第２の実施形態では、動的コンポーネント７１に関連付けられる静的レジスタ及び動的レジスタは、対応するＤＴＥ７５'の一部としてはもはや提供されず、階層７４Ｂ〜７４ＩのルートコンポーネントＡを形成するベースコンポーネント１０２によって提供される保護されているストレージ１０３に配置される。一例として、図１１は、動的コンポーネント７１Ｅに関連付けられる静的レジスタ７８Ｅ及び動的レジスタ７９Ｅを保護されているストレージ１０３内に示している。ベースコンポーネント１０２は、各子孫動的コンポーネントの予測測定値も保持する。

ベースコンポーネント１０２は、動的コンポーネント７１Ａ〜７１Ｉと同様に、好ましくは、機能群Ｆ、実行環境ＥＮＶ、及び構成群Φを備え、ユニット７４によって使用される保護されているストレージを提供することに加えて、以前は各ＤＴＥ７５の完全性メトリックマネージャに見られた暗号資源も提供する。図１１の各ＤＴＥのマネージャ７７'は、ここでは、主として、ベースコンポーネント１０２へのインターフェースとして機能する。動的コンポーネント７１は、これらのインターフェースを使用して、それらの動的コンポーネントのそれぞれに関連付けられる静的レジスタ７８及び動的レジスタ７９を更新し、自身のために保護されているストレージ１０３に記憶された他の機密へのアクセスを要求する。アクセスの詳細は、ベースコンポーネント１０２によって施行されるポリシーによって制御される。

この場合では、ベースコンポーネント１０２は、プラットフォームのトラステッドコンピューティングベースＴＣＢ１００の一部である（トラステッドコンピューティングベースは、ベースコンポーネント１０２を含めて、プラットフォームの信頼性に影響を与える可能性のあるエンティティの集合である）。プラットフォームの信頼チェーンは、（通常はハードウェアＴＰＭに基づく）その信頼ルート１０１からベースコンポーネント１０２に伸び、次に、動的コンポーネントの階層を通じて、それら動的コンポーネントのそれぞれの状態が正しいとする範囲まで伸びる。

この実施形態では、現行のＴＣＧ方法が使用されて、ＴＣＢ１００の完全性測定が実行されるのに対して、第１の実施形態に関連して説明した方法で静的レジスタ７８及び動的レジスタ７９が使用されて、トラステッドコンピューティングベース１００の外部の動的コンポーネント７１の完全性がよりきめ細かく追跡される。

ベースコンポーネント１０２は、従属コンポーネントのツリーの構造を詳述するデータ及びこのツリーを管理するソフトウェアを保持する。簡単にするために、単一のベースコンポーネント１０２しか説明されていないが、上述した構成は、それ自身のツリーをそれぞれ有する複数のベースコンポーネントに一般化することができる。動的コンポーネント７１は、自身の親コンポーネントの識別情報を除いて、ツリーの構造についていかなる情報も所有しない（この情報は、対応するＤＴＥによって保持される）。

すでに示したように、ツリーの構造の知識は、動的コンポーネントの機密に適用される動的アクセス制御ポリシーを施行するのに使用される。これらのポリシーは、動的コンポーネントがどのような条件下で自身の機密にアクセスすることを認められるのかを決定する。これらのポリシーは、ベースコンポーネント１０２によって施行される。たとえば、完全性ポリシーは、動的コンポーネント及びその祖先の完全性が損なわれていない場合に限って機密へのアクセスを認める。この方式の結果、各コンポーネントイメージの進行中の測定によって制御される再帰的な完全性定義が得られる。

セキュリティサービス管理フレームワーク（ＳＳＭＦ）
ベースコンポーネント及び従属動的コンポーネントを有する上述したアーキテクチャは、ベースコンポーネントに基づくセキュリティサービス管理フレームワーク（ＳＳＭＦ）を提供するのによく適しており、（動的コンポーネントによって）ユーザに提供されるセキュリティサービス間の信頼関係を管理する。

たとえば、ＳＳＭＦによって提供される重要なサービスは、ユーザによって要求されたセキュリティにクリティカルなオペレーションを実行するために動的コンポーネントによって使用されるセキュリティ信用証明書の管理である。一般的な実施は、各信用証明書をアクセスポリシーと結合して、一定のセキュリティ特性が満たされている場合に限って、その使用を認めることである。このために、ＳＳＭＦは、関連する完全性が損なわれていない場合に限って、完全性ポリシーを使用して、コンポーネント信用証明書がアクセスされるという保証をユーザに提供するように構成することができる。このように、ユーザは、プラットフォームとデータを交換する前にセキュリティサービスの正確なオペレーション及びプラットフォームを検証することができる。ＳＳＭＦは、これを、セキュリティサービスとユーザとの間のこの信頼関係と同様の信頼関係とを組み合わせて、必要なトラステッドインターフェースを提供する。以下で、フレームワークアーキテクチャをより十分に説明する。

図１２に示すように、ＳＳＭＦ２００は、コアセキュリティサービス管理（ＳＳＭ）モジュール２０２、信用証明書モジュール２０３、及びリモートサービスレベル証明用の証明モジュール（attestation module）２０４から成る。ＳＳＭＦは、セキュリティサービスコンポーネント（ライフサイクル管理、信用証明書管理、及び完全性報告用）及びユーザ（リモート証明用）の双方によって使用されるセキュリティサービス管理インターフェース（ＳＳＭＩ）２０１を通じてアクセスされる。詳細には、ＳＳＭＩ２０１によって、サービスは、ＳＳＭＦを使用して、
親の実行環境内に動的子サービスコンポーネントを作成して、それら動的子サービスコンポーネントのライフサイクルを管理すること、
動的子サービスコンポーネントのセキュリティ信用証明書を保護されているストレージに記憶すること、
動的子サービスコンポーネントのセキュリティ信用証明書に、それぞれと結合された完全性ポリシーでインラインにアクセスすること、
動的子サービスコンポーネントの構造及び構成に対する進行中の動的変更及び静的変更を報告すること、及び
サービスレベルにおける動的子サービスコンポーネントの完全性ステータスを報告すること
が可能になる。

コアＳＳＭモジュール２０２は、コンポーネント階層のベースコンポーネント（図１１参照）として機能し、サービス（コンポーネント）階層の経過を追跡し、動的測定を可能にする。詳細には、コアＳＳＭモジュール２０２によって提供される主要な機能は、（１）ＳＳＭＦによって管理されるサービスコンポーネントの構造を詳述するデータの保持、（２）測定値及び信用証明書用の保護されているストレージの提供、並びに（３）動的サービスの作成のサービスインターフェース及び完全性測定の報告インターフェースの提供である。これらの機能のそれぞれを以下でさらに説明する。

サービス階層マネージャ（ブロック２０６）。すでに述べたように、セキュリティサービスは、動的コンポーネントによって提供される。各動的コンポーネントは、上述したように、永続的な識別情報を保持する動的トラステッドエンティティ（ＤＴＥ）に関連付けられている。ＳＳＭＦの目的のために、この識別情報は、ＤＴＥに関連付けられるサービスコンポーネントを識別する働きもする。したがって、サービス階層の経過を追跡するために、コアＳＳＭモジュール２０２は、ノードがＤＴＥ識別情報から成るデータ構造を単に管理する。その結果のデータ構造は、図１１に示すツリーと同様のツリーであり、このツリーでは、各ノードは、対応するサービスコンポーネントを表すＤＴＥである。これらのＤＴＥは、サービス階層におけるサービスコンポーネントの位置指定子であり、サービスコンポーネント上のどのオペレーションも、その対応するＤＴＥを通じて行われる。

保護されているストレージ（ブロック２０７）。コアＳＳＭモジュール２０２は、サービスコンポーネントの動的完全性測定及び静的完全性測定の双方の経過を追跡する。さらに、各サービスによって使用されるセキュリティ信用証明書が、コアＳＳＭによって取り扱われて記憶される。双方のタイプの情報は、機密データであり、コアＳＳＭモジュール２０２は、保護されているストレージを使用して、各コンポーネントの各データを記憶する。このストレージの実際の性質は、実施態様によって決まる。一例として、トラステッドハードウェアモジュール（ＴＰＭ）を使用して、図５を参照して上述したような通常のストレージに記憶されるこのような情報を保護することができる。

サービス／報告マネージャ（ブロック２０８）。サービス／報告マネージャは、サービスインターフェース及び報告インターフェースを提供する。サービスインターフェースは、単一のcreate()コマンドを提供し、当該単一のcreate()コマンドを使用して、サービスはそれらのＤＴＥと共に子サービスを作成することができる。同様に、報告インターフェースは、静的変更及び動的変更の双方を要求側サービスに報告するのに使用できる単一のreport()要求から成る。

信用証明書モジュール２０２によって提供される信用証明書管理に関して、サービスが、さまざまな方法でセキュリティ信用証明書を使用できることが十分理解されよう。たとえば、信用証明書は、サービスがデータを署名するのに使用する対称暗号鍵とすることができる。この場合、セキュリティ信用証明書を所有する能力又はセキュリティ信用証明書にアクセスする能力によって、サービスユーザに、そのサービスが信頼できることの十分なプルーフを与えることができる。アクセスポリシーは、これらの信用証明書にアクセスすることをサービスに認める条件を定義するのに使用することができる。これらのポリシーを施行する基礎となるプラットフォームが信頼できる場合、ユーザは、ポリシーの条件が満たされる場合に限って、サービスが信用証明書にアクセスできるものと推論することができる。

信用証明書モジュール２０２は、セキュリティ信用証明書への使用アクセス（usage access）をセキュアに記憶、管理、及び提供する検証可能な手段を提供し、これらの信用証明書の管理及び使用が、サードパーティユーザによって検証可能なトラステッドエンティティによって実行されることを保証する。完全性ポリシーは、サービスが、自身のセキュリティ信用証明書にアクセスできるか否かを判断するのに使用される。完全性ポリシーは、サービスが、そのサービスの完全性及びその祖先の完全性に加えて、プラットフォーム（すなわち、トラステッドコンピューティングベースＴＣＢ）の完全性がすべて損なわれていない場合に限って、自身のセキュリティ信用証明書にアクセスできることを提示する。一例として、図１１では、動的サービスコンポーネントＦは、Ｆ、Ｃ、Ｂ、及びＴＣＢの完全性が損なわれていない場合に限って、自身の信用証明書にアクセスすることができる。たとえば、Ｅの完全性は、この特定の決定に影響がないことに留意されたい。

信用証明書管理は、登録及び使用の２つのフェーズを伴う。登録フェーズは、１回限りのフェーズであり、その期間中、信用証明書がＳＳＭＦに登録され、そのアクセスポリシーと共に保護されているストレージにシールされる。それを行うために、サービスコンポーネントは、信用証明書モジュール２０３の信用証明書インターフェースのregister()要求を起動する。これは、好ましくは非対称鍵で暗号化された入力信用証明書の登録要求を開始する。登録が成功すると、信用証明書モジュール２０３は、シールされた信用証明書への使用アクセスを要求する要求側サービスコンポーネントが後に使用することができるチケットを返す。好ましくは、このチケットは、保護されているストレージのシールサービスによって返されたブロブである。

使用フェーズでは、サービスコンポーネントは、信用証明書インターフェースを介してチケットを信用証明書モジュール２０３に供給することによって、自身のセキュリティ信用証明書への使用アクセスを得る。信用証明書モジュール２０３は、最初に、サービスの永続的なＤＴＥ識別情報を使用してサービス階層でサービスを位置特定する。チケットが有効であり、且つ、アクセスポリシーが現在のサービス及びプラットフォーム構成に適用できる（たとえば、サービス、そのサービスの祖先、及びＴＣＢの完全性が損なわれていない）場合に限り、信用証明書へのアクセスは許可される。信用証明書への使用アクセスは、信用証明書の性質に関するどの情報も要求側サービスコンポーネントに明らかにすべきでない。この理由は、サービスが自身のセキュリティ信用証明書を所有する場合において、動的サービスコンポーネントが報告インターフェースを通じて静的変更又は動的変更を報告するときは、ＳＳＭＦが、信用証明書を無効にする能力を失うためである。したがって、信用証明書の使用を要求するオペレーション（暗号化、解読）は、ＳＳＭＦの内部で（たとえば、信用証明書モジュール２０３によって）実行される。したがって、サービスコンポーネントから信用証明書モジュール２０３の信用証明書インターフェースへの信用証明書使用要求は、encrypt()要求又はdecrypt()要求の形を取る。

証明モジュール２０４に関して、これは、データをサービスと交換する前にサービスの完全性を検証しようと望むサードパーティユーザにサービスレベル証明を提供する。使用される証明プロトコルは、ＴＣＧ仕様に記載されたものと同様のものである。しかしながら、ここでは、ＳＳＭＦは、フルスケールのプラットフォーム証明を行う代わりに、ユーザが、はるかにきめ細かなサービス完全性クォート（service integrity quote）を行うことを可能にする。このように、ユーザは、任意のサービスコンポーネントの累積的完全性（cumulative integrity）を要求することができる。サービスコンポーネントの累積的完全性は、サービス、そのサービスの祖先、及び基礎と成るＴＣＢのローカルな測定を組み合わせたものである。

証明プロトコルの２つの例を以下に説明する。これらのプロトコルは、完全性の結果を検証するのに使用されるエンティティ（すなわち、ユーザ又はプラットフォーム）に関して異なる。双方のプロトコルは、証明モジュールに対して行われる単一のattest()要求（適切なオプションを有する）を使用して開始される。

第１の例の証明プロトコル。この場合、サードパーティユーザは、対象となるサービスの完全性の検証者として機能する（すなわち、プラットフォーム及びＴＣＢのすべての関連のあるコンポーネントの予測値にアクセスする）。以下は、図１１の階層のコンポーネントＣが、対象となるコンポーネントであるものと仮定している。
１．サードパーティユーザは、証明モジュール２０４によって提供された証明インターフェースを使用して、サービスコンポーネントＣの完全性をチェックし、関連する現在のすべての完全性測定の署名されたコピーを要求する。
２．証明モジュール２０４は、コンポーネントＣのＤＴＥの識別情報を使用して階層内でＣを位置特定する。
３．証明モジュール２０４は、Ｃ、Ｂ、及びＴＣＢの完全性（すなわち、レジスタ値）に加えて、コンポーネントＣ、Ｂ、及びＴＣＢの完全性測定の署名されたコピーから成る署名をサードパーティユーザに返す。コンポーネントＣ、Ｂの完全性測定のコピーは、証明モジュール２０４によって署名され、ＴＣＢの完全性測定のコピーは、プラットフォームのトラステッドモジュールＴＭによって署名され、これら署名されたコピーから成る署名は、以下の通りである。

式中、

は、添え字のエンティティによる署名であり、Ｉは、添え字の要素に関して行われた完全性測定を示す。
４．サードパーティユーザは測定を受け取り、署名を検証すると、ＴＣＢ及びコンポーネントＢ、Ｃの現在のレジスタ値を予測値と比較し、Ｃを信頼するか否かを決定する。

第２の例の証明プロトコル。この場合、検証者はプラットフォームであり、サードパーティユーザは、プルーフを有する信頼される回答又は単一の信頼されない回答のいずれかを受け取る。プロトコルの最初の２つのステップは、上記と同じである。３番目のステップでは、フレームワークは、完全性測定を返す代わりに、現在の値と予測値とを比較する。たとえば、サービスコンポーネントＣについて、フレームワークは、Ｃ及びＢの双方の静的測定及び動的測定を予測値と比較した後、信頼される回答を返す。その回答と共に、フレームワークは、ＴＣＢの完全性、及び、プルーフとして署名

を返す。この理由は、この例では、サードパーティユーザが、まだ、回答がトラステッドプラットフォームによって生成されたことを検証する必要があるためである。

本発明の説明した実施形態によって、動的コンポーネントは、一定の条件の下で全ての再起動を必要とすることなく信頼を再確立することが可能になることが十分理解されよう。これは、頻繁に変化すると共にさまざまなセキュリティモードで動作するコンポーネントを有するシステムにとって特に好都合である。監視及び報告が進行中であることによって、コンポーネントは、最新のシステム状態を反映することが可能になる。これは、ブート中に１回、コンポーネントを測定する現在の実施態様とは対照的に、システムについての最新の情報を提供する。

さらに、完全性測定値は、ソフトウェアレジスタに記憶されるので、説明した実施形態は、ハードウェアレジスタが完全性測定値の全部のセットを記憶することを必要とする現在の構成よりも拡張性がある。

説明した階層的完全性管理方式（すなわち、信頼ツリー）は、複雑なシステムにとっては、線形モデル（すなわち、信頼チェーン）を提供する現在の解決法よりも適している。必要な切り離し特性が保証される場合、この階層的手法は、以下のものを可能にするきめ細かな完全性管理解決法を提供する。
より良好な表現：階層的手法によって、互いに依存関係を有しないコンポーネントは、別々の完全性チェーンを構築することが可能になる。したがって、コンポーネントの完全性は、自身に加えてその祖先の完全性のみを伴う。
切り離し：コンポーネントに対する変更は、完全性チェーンの適切な分岐に切り離されるにすぎず、したがって、プラットフォーム全体に影響を与えることはない。その結果、クリティカル変更は、もはや、プラットフォーム全体の再起動及び再測定を必要とせず、適切な分岐の再起動及び再測定のみを必要とする。

本発明の上述した実施形態に対して多くの変形が可能であることが十分理解されよう。詳細には、当業者は、本発明が、そのオペレーションについて、図１〜図６を参照して上述した特定の形態のトラステッドプラットフォーム技術の使用にも、ＴＣＧ仕様で説明されたような特定の形態のトラステッドプラットフォーム技術の使用にも依拠しないことを十分理解するであろう。

上述した変更の分類とは異なる変更の分類を使用することができる。

コンポーネントは、実行を通じてプラットフォームの信頼状態を変更できる任意のプラットフォームエンティティであることに留意すべきである。プラットフォームコンポーネントの詳細に対する制限はない。一例として、コンポーネントは、仮想ドメイン（パーティション）に存在するサービスとすることができる。代替的に、コンポーネントは、仮想ドメインそのものとすることもできる。したがって、プラットフォームコンポーネントを定義する際の正確な粒度は、プラットフォーム上で必要とする完全性管理の粒度に依存する。

完全性管理の好都合に異なる粒度を同時に使用することができる。たとえば、異なるコンポーネント粒度を有する２つのレベルの信頼管理を同じプラットフォーム上で使用することができる。したがって、上述したＳＳＭＦを、以下のローカルな状況及びグローバルな状況の双方で適用することができる。
ローカル状況では、ローカルＳＳＭＦが、（それ自身の仮想ドメイン又はパーティションに確立された）単一の仮想マシンに存在するセキュリティサービスを管理するのに使用される。複数の仮想ドメインの場合、各ドメインは、他のドメインのローカルＳＳＭＦから独立して機能するローカルＳＳＭＦの実施態様を含む）。
グローバルな状況では、グローバルＳＳＭＦが、それぞれが自身の仮想ドメイン内に存在する複数の仮想マシンから成る階層を管理するのに使用される。この場合、仮想マシン間の依存関係は、暗黙的なものでははく、明示的に提示されることに留意されたい（すなわち、実行順序によって、ＶＭ間の暗黙的な祖先関係はない）。たとえば、仮想マシンの１つが、仮想マシンの残りのものの管理を担当する管理マシンとして機能する場合、管理仮想マシンが、残りの子仮想マシンの親の役割を引き受ける明示的な依存関係が存在する。

図１３は、セキュアなハイパーバイザ３０１を実行して複数の仮想ドメイン（「Ｄｏｍ０」〜「ＤｏｍＸ」と呼ぶ）３０２〜３０９を提供するホスト３００についてグローバルＳＳＭＦの使用及びローカルＳＳＭＦの使用を組み合わせたものを示している。グローバルＳＳＭＦ３３２は、Ｄｏｍ０のトラステッドアプリケーションとして実行され、それぞれが自身の仮想ドメイン内に存在する仮想マシンから成る階層を管理する働きをする。グローバルＳＳＭＦ３３２と、グローバルＳＳＭＦ３３２が管理する仮想マシンとの間の通信は、ドメイン間通信機構３２０を通じて行われる。ドメイン３０３〜３０９のそれぞれは、それ自身のローカルＳＳＭＦ３３３〜３３９をそれぞれ有する。

一例示の従来技術のコンピュータプラットフォームの図である。 従来技術のトラステッドコンピュータプラットフォームのマザーボード上に存在する機能エレメントを示す図である。 図２のトラステッドコンピュータプラットフォームの従来技術のトラステッドデバイスの機能エレメントを示す図である。 図２のトラステッドデバイスのプラットフォーム構成レジスタ内に値を拡張する既知の従来技術のプロセスを示す図である。 図４のトラステッドデバイスに関連付けられる鍵の階層の図である。 ハイパーバイザを実行し、複数の切り離されたオペレーティングシステム環境を提供する別の従来技術のコンピューティングプラットフォームの図である。 動的コンポーネント及び関連付けられる動的トラステッドエンティティを示す本発明の第１の実施形態の図である。 図７の動的コンポーネントの状態図である。 図７と同様であるが、第１の実施形態の階層的実施態様を示す図である。 図９の形態の動的コンポーネント及び関連付けられる動的トラステッドエンティティの階層の図である。 本発明の第２の実施形態について、動的コンポーネント及びそれらに関連付けられる動的トラステッドエンティティの別の階層を示す図であって、この階層がトラステッドプラットフォームのトラステッドコンピューティングベースのコンポーネントをルートとする図である。 第２の実施形態に基づくセキュリティサービス管理フレームワークを示す図である。 複数の仮想ドメインを有し、グローバルセキュリティサービス管理フレームワーク及びドメイン特有のローカルセキュリティサービス管理フレームワークの双方が提供されたホストプラットフォームを示す図である。

符号の説明

３・・・不揮発性メモリエリア
４・・・揮発性メモリエリア
８ａ〜８ｎ・・・プラットフォーム構成レジスタ（ＰＣＲ）
１０・・・トラステッドプラットフォーム
１４・・・キーボード
１６・・・マウス
１８・・・視覚表示ユニット（ＶＤＵ）
２０・・・マザーボード
２１・・・メインプロセッサ
２２・・・メインメモリ
２３・・・入出力（ＩＯ）デバイス
２４・・・トラステッドデバイス
２６・・・データバス
２７・・・制御ライン
２８・・・アドレスライン
２９・・・ＢＩＯＳメモリ
３０・・・コントローラ
３１・・・測定機能
３２・・・暗号機能
３３・・・認証機能
３４・・・インターフェース回路部
３６、３７、３８・・・ポート
４１・・・入力
４２・・・ハッシュ
４３・・・連結
５１・・・ストレージルート鍵（ＳＲＫ）
５２・・・データオブジェクトの階層（ツリー）
５４・・・標準的なメモリ
６０・・・トラステッドプラットフォーム
６１・・・プラットフォームプロセッサ
６２・・・トラステッドデバイス
６３・・・ＲＯＭ
６４・・・ＢＩＯＳ
６５・・・セキュリティカーネル
６６・・・ハイパーバイザ
６７Ａ〜６７Ｃ・・・パーティション
６８Ａ〜６８Ｃ・・・オペレーティングシステム環境
６９Ａ〜６９Ｃ・・・仮想トラステッドデバイス
７０・・・親コンポーネント
７１・・・動的コンポーネント
７２・・・変更タイプポリシー
７３・・・測定エージェント
７５、７５'Ｅ・・動的トラステッドエンティティ（ＤＴＥ）
７６・・・識別情報
７６'Ｅ・・・識別情報およびAssoc Data
７７、７７'Ｅ・・・完全性メトリックマネージャ
７８・・・静的レジスタ
７９・・・動的レジスタ
１００・・・トラステッドコンピューティングベース
１０１・・・信頼ルート
１０２・・・ベースコンポーネント
１０３・・・保護されているストレージ
２００・・・セキュリティサービス管理フレームワーク（ＳＳＭＦ）
２０１・・・セキュリティサービス管理インターフェース（ＳＳＭＩ）
２０２・・・コアセキュリティサービス管理モジュール
２０３・・・信用証明書モジュール
２０４・・・証明モジュール
２０６・・・サービス階層マネージャ
２０７・・・保護されているストレージ
２０８・・・サービス／報告マネージャ
３００・・・ホスト
３０１・・・セキュアなハイパーバイザ
３０２〜３０９・・・仮想ドメイン
３２０・・・ドメイン間通信機構
３３２・・・グローバルＳＳＭＦ
３３３〜３３９・・・ローカルＳＳＭＦ
３５０・・・証明書
３５１・・・トラステッドデバイスの公開鍵
３５２・・・プラットフォーム完全性メトリックの認証値
６００・・・トラステッドコンピューティングベース
６０１・・・アプリケーション

Claims (20)

1. コンピューティングプラットフォーム上でソフトウェアコンポーネント（７１）の状態を追跡する方法であって、
   前記ソフトウェアコンポーネントに関連付けられた変更タイプポリシーエレメント（７２）を用いて、ソフトウェアコンポーネントにおける変更が、
   前記ソフトウェアコンポーネントが、その目的とする機能を実施する能力に影響を与える可能性がある前記ソフトウェアコンポーネントのコードまたは他のデータである完全性にクリティカルな部分に対して行われ、前記ソフトウェアコンポーネントにおける信用を回復するためにソフトウェアコンポーネントの再起動を要求する第１のタイプであるか、
   前記第１のタイプの変更以外の変更であって、前記ソフトウェアコンポーネントが目的とする機能を実施する能力に影響を与えない前記ソフトウェアコンポーネントのコードまたは他のデータである完全性に非クリティカルな部分に対して行われ、信用を回復できる第２のタイプであるか
   を判断することと、
   前記ソフトウェアコンポーネントにおける変更が前記第１のタイプである場合に、前記ソフトウェアコンポーネントの完全性メトリックを、少なくとも前記ソフトウェアコンポーネントの完全性にクリティカルな部分について測定し、前記ソフトウェアコンポーネントに対する前記第１のタイプの変更のために記録されるあらゆる前の完全性メトリック値と累積的に組み合わせて記録することと、
   前記ソフトウェアコンポーネントにおける変更が前記第２のタイプである場合に、前記ソフトウェアコンポーネントの完全性メトリックを、少なくとも前記ソフトウェアコンポーネントの完全性に非クリティカルな部分について測定し、前記ソフトウェアコンポーネントに対する前記第２のタイプの変更について記録されるあらゆる前の完全性メトリック値の代わりとして記録することと、
   前記ソフトウェアコンポーネントの測定を、前記ソフトウェアコンポーネントに関連付けられた１つ以上の測定エージェント（７３）を用いて行うことと
   を含む方法。
2. 前記第１のタイプの変更の結果として測定される前記完全性メトリックは、第１のレジスタ（７８）に記録され、
   前記第２のタイプの変更の結果として測定される前記完全性メトリックは、第２のレジスタ（７９）に記録され、
   前記第１のレジスタ及び前記第２のレジスタは、論理的に、前記ソフトウェアコンポーネントに関連付けられるトラステッドエンティティ（７５）の一部である
   請求項１に記載の方法。
3. 階層における自身の親のソフトウェアコンポーネントの実行環境で実行される前記階層における子であるソフトウェアコンポーネントそれぞれによって階層的に配置される複数のソフトウェアコンポーネント（７１ Ｂ−Ｉ）それぞれに適用され、
   前記階層のソフトウェアコンポーネント（７１ Ｂ−Ｉ）それぞれの状態は、別個に追跡され、
   前記ソフトウェアコンポーネントそれぞれは、
   それぞれ関連付けられた第１のレジスタおよび第２のレジスタのペア
   を有する
   請求項２に記載の方法。
4. 前記プラットフォームは、すべての前記ソフトウェアコンポーネント（７１ Ｂ−Ｉ）に共通のトラステッドベースコンポーネント（１０２）を提供し、
   前記ソフトウェアコンポーネントそれぞれに関連付けられる前記第１のレジスタおよび前記第２のレジスタのペアは、前記トラステッドベースコンポーネントによって保持される
   請求項３に記載の方法。
5. 前記ベースコンポーネントは、前記階層のルートを形成する
   請求項４に記載の方法。
6. 前記ベースコンポーネントは、前記階層の実行環境を提供する
   請求項５に記載の方法。
7. 前記ベースコンポーネントは、前記プラットフォームのトラステッドコンピューティングベース（１００）の一部である
   請求項４〜１０のいずれかに記載の方法。
8. 前記第１のタイプの変更のために記録された前記完全性メトリックから求められる累積値と、前記第２のタイプの変更のために最後に記録された前記完全性メトリック値とがそれぞれの予測値と一致しない限り、前記ソフトウェアコンポーネントに関連付けられる機密データの使用を防止すること
   をさらに含む請求項１に記載の方法。
9. 前記プラットフォームのトラステッドベースコンポーネントをルートにする階層に配置される複数のソフトウェアコンポーネント（７１ Ｂ−Ｉ）それぞれに適用される方法であって、
   前記第１のタイプおよび前記第２のタイプの変更の結果として測定される前記完全性メトリックは、前記トラステッドベースコンポーネントによって保持されるセキュアなロケーションに記憶され、
   前記ソフトウェアコンポーネントの前記完全性メトリックおよび前記階層におけるその祖先の前記完全性メトリックがすべてそれぞれの予測値と一致しない限り、前記ソフトウェアコンポーネントに関連付けられる機密データの使用を防止すること
   をさらに含む請求項１に記載の方法。
10. 前記ソフトウェアコンポーネントは、前記プラットフォーム上で実行されるハイパーバイザによって確立されるドメインである
    請求項１に記載の方法。
11. 前記ソフトウェアコンポーネントは、前記プラットフォーム上で実行されるハイパーバイザ（３０１）によって確立されるドメインで実行される
    請求項１に記載の方法。
12. コンピューティングプラットフォームであって、
    前記コンピューティングプラットフォーム上で使用されているソフトウェアコンポーネント（７１）の状態を追跡する監視機構
    を含み、
    前記監視機構は、
    前記ソフトウェアコンポーネントに対する第１のタイプの変更および第２のタイプの変更が、
    前記ソフトウェアコンポーネントに関連付けられた変更タイプポリシーエレメント（７２）を用いて、ソフトウェアコンポーネントにおける変更が、
    前記ソフトウェアコンポーネントが、その目的とする機能を実施する能力に影響を与える可能性がある前記ソフトウェアコンポーネントのコードまたは他のデータである完全性にクリティカルな部分に対して行われ、前記ソフトウェアコンポーネントにおける信用を回復するためにソフトウェアコンポーネントの再起動を要求する第１のタイプであるか、
    前記第１のタイプの変更以外の変更であって、前記ソフトウェアコンポーネントが目的とする機能を実施する能力に影響を与えない前記ソフトウェアコンポーネントのコードまたは他のデータである完全性に非クリティカルな部分に対して行われ、信用を回復できる第２のタイプであるか
    を検出し、区別する変更応答手段（７２）と、
    第１のメモリレジスタおよび第２のメモリレジスタ（７８，７９）と、
    前記ソフトウェアコンポーネントの前記第１のタイプの変更の検出に応答して、前記ソフトウェアコンポーネントの完全性メトリックを測定する第１の測定手段（７３）と、
    前記第１の測定手段によって測定された完全性メトリックを、前記ソフトウェアコンポーネントに対する前記第１のタイプの変更のために前記第１のレジスタに記録されるあらゆる前の完全性メトリック値と累積的に組み合わせて、前記第１のレジスタに記録する第１の記録手段（７７）と、
    前記ソフトウェアコンポーネントの前記第２のタイプの変更の検出に応答して、前記ソフトウェアコンポーネントの完全性メトリックを測定する第２の測定手段（７３）と、
    前記第２の測定手段によって測定された完全性メトリックを、前記ソフトウェアコンポーネントに対する前記第２のタイプの変更のために前記第２のレジスタに記録されるあらゆる変更以前の完全性メトリック値の代わりとして、前記第２のレジスタに記録する第２の記録手段（７７）と
    を備えるコンピューティングプラットフォーム。
13. 前記第１のレジスタおよび前記第２のレジスタは、前記ソフトウェアコンポーネントに論理的に関連付けられるトラステッドエンティティの一部である
    請求項１２に記載のコンピューティングプラットフォーム。
14. 前記コンピューティングプラットフォームは、
    階層における自身の親のソフトウェアコンポーネントの実行環境で実行される前記階層における子であるソフトウェアコンポーネントそれぞれによって階層的に配置される複数のソフトウェアコンポーネント
    を含み、
    前記階層のソフトウェアコンポーネントそれぞれの状態は、別個に追跡され、
    前記ソフトウェアコンポーネントそれぞれは、
    それぞれに関連付けられる第１のレジスタ（７８）および第２のレジスタ（７９）と、
    それぞれの第１の測定手段、第１の記録手段、第２の測定手段および第２の記録手段（７３，７７）と
    を有する
    請求項１３に記載のコンピューティングプラットフォーム。
15. 前記プラットフォームは、
    すべての前記ソフトウェアコンポーネントに共通のトラステッドベースコンポーネント（１０２）
    を含み、
    前記ソフトウェアコンポーネントそれぞれに関連付けられる前記第１のレジスタおよび第２のレジスタのペアは、前記トラステッドベースコンポーネントによって保持される
    請求項１４に記載のコンピューティングプラットフォーム。
16. 前記ベースコンポーネントは、前記階層のルートを形成する
    請求項１４に記載のコンピューティングプラットフォーム。
17. 前記ベースコンポーネントは、前記階層の実行環境を提供する
    請求項１６に記載のコンピューティングプラットフォーム。
18. 前記ベースコンポーネントは、前記プラットフォームのトラステッドコンピューティングベースの一部である
    請求項１５〜１７のいずれかに記載のコンピューティングプラットフォーム。
19. 前記第１のタイプの変更のために記録された前記完全性メトリックから求められる累積値と、前記第２のタイプの変更のために最後に記録された前記完全性メトリック値とがそれぞれの予測値と一致しない限り、前記ソフトウェアコンポーネントに関連付けられる機密データの使用を防止するアクセス制御機構
    をさらに含む請求項１２〜１８のいずれかに記載のコンピューティングプラットフォーム。
20. 前記プラットフォームは、
    前記プラットフォームのトラステッドベースコンポーネントをルートにする階層に配置される複数のソフトウェアコンポーネント（７１ Ｂ−Ｉ）
    を含み、
    前記ソフトウェアコンポーネントは、
    それぞれの前記第１のレジスタ、前記第２のレジスタ、前記第１の測定手段および前記第２の測定手段
    を有し、
    前記第１のレジスタおよび前記第２のレジスタは、
    前記トラステッドベースコンポーネントによって保持されるセキュアなロケーション
    を含み、
    前記コンピューティングプラットフォームは、
    前記ソフトウェアコンポーネントの前記完全性メトリックおよび前記階層におけるその祖先の前記完全性メトリックがすべてそれぞれの予測値と一致しない限り、前記ソフトウェアコンポーネントに関連付けられる機密データの使用を防止するアクセス制御機構
    をさらに含む
    請求項１５に記載のコンピューティングプラットフォーム。
    

Images