(57)【要約】【課題】コンピューティングプラットフォームで動的信頼管理を可能にする方法及び装置を提供する。【解決手段】コンピューティングプラットフォーム上で使用されているソフトウェアコンポーネントの状態を追跡する方法及び装置が提供される。ソフトウェアコンポーネントの第１のタイプ変更時に、ソフトウェアコンポーネントの適切な完全性メトリックが確実に測定され、ソフトウェアコンポーネントに対する第１のタイプの変更について記録されるあらゆる前の完全性メトリック値と累積的に組み合わせて記録される。ソフトウェアコンポーネントの第２のタイプ変更時に、ソフトウェアコンポーネントの適切な完全性メトリックが確実に測定され、ソフトウェアコンポーネントに対する第２のタイプの変更について記録されるあらゆる前の完全性メトリック値の代わりとして記録される。これら２つの結果の値は、ソフトウェアコンポーネントの完全性状態の表示を提供する。【選択図】  図７
2009015818.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティングプラットフォーム上で使用されているソフトウェアコンポーネントの状態を追跡する方法であって、
前記ソフトウェアコンポーネントの第１のタイプの変更時に、前記ソフトウェアコンポーネントの適切な完全性メトリックを確実に測定すると共に、前記ソフトウェアコンポーネントに対する前記第１のタイプの変更について記録されるあらゆる前の完全性メトリック値と累積的に組み合わせて記録することと、
前記ソフトウェアコンポーネントの第２のタイプの変更時に、前記ソフトウェアコンポーネントの適切な完全性メトリックを確実に測定すると共に、前記ソフトウェアコンポーネントに対する前記第２のタイプの変更について記録されるあらゆる前の完全性メトリック値の代わりとして記録することと
を含む方法。
【請求項２】
前記第１のタイプの変更は、
前記コンポーネントの完全性にクリティカルな部分に対して行われる変更、すなわち、前記コンポーネントがその目的とする機能を実施する能力に影響を与える可能性のある前記コンポーネントのコード又は他のデータに対して行われる変更であり、
前記第２のタイプの変更は、
前記コンポーネントの完全性にクリティカルでない部分に対して行われる変更、すなわち、前記コンポーネントがその目的とする機能を実施する能力に実質的に影響を与えない前記コンポーネントのコード又は他のデータに対して行われる変更である
請求項１に記載の方法。
【請求項３】
前記第１のタイプの変更の結果として測定される前記完全性メトリックは、
少なくとも、前記ソフトウェアコンポーネントの前記完全性にクリティカルな部分について測定され、
前記第２のタイプの変更の結果として測定される前記完全性メトリックは、
少なくとも、前記ソフトウェアコンポーネントの前記完全性にクリティカルでない部分について測定される
請求項２に記載の方法。
【請求項４】
前記ソフトウェアコンポーネントは、
必要なコンポーネント機能を提供する機能群と、
前記機能群が実行される実行環境と
を含む請求項１に記載の方法。
【請求項５】
前記第１のタイプの変更の結果として測定される前記完全性メトリックは、第１のレジスタに記録され、
前記第２のタイプの変更の結果として測定される前記完全性メトリックは、第２のレジスタに記録され、
前記第１のレジスタ及び前記第２のレジスタは、論理的に、前記ソフトウェアコンポーネントに関連付けられるトラステッドエンティティの一部である
請求項１に記載の方法。
【請求項６】
前記方法は、
階層における自身の親のソフトウェアコンポーネントの実行環境で実行される前記階層における子である各ソフトウェアコンポーネントによって階層的に配置される複数のソフトウェアコンポーネントのそれぞれに適用され、
前記階層の各ソフトウェアコンポーネントの状態は、別個に追跡され、
各コンポーネントは、第１のレジスタ及び第２のレジスタから成る関連付けられる各ペアを有する
請求項５に記載の方法。
【請求項７】
前記プラットフォームは、
すべての前記ソフトウェアコンポーネントに共通のトラステッドベースコンポーネントを提供し、
各ソフトウェアコンポーネントに関連付けられる第１のレジスタ及び第２のレジスタから成る前記ペアは、
前記トラステッドベースコンポーネントによって保持される
請求項６に記載の方法。
【請求項８】
前記ベースコンポーネントは、前記階層のルートを形成する
請求項７に記載の方法。
【請求項９】
前記ベースコンポーネントは、前記階層の実行環境を提供する
請求項８に記載の方法。
【請求項１０】
前記ベースコンポーネントは、前記プラットフォームのトラステッドコンピューティングベースの一部である
請求項７に記載の方法。
【請求項１１】
前記第１のタイプの変更について記録される前記完全性メトリックから生じる現在の累積値と、前記第２のタイプの変更について最後に記録される前記完全性メトリック値とが、共にそれぞれの予測値と一致しない限り、
前記ソフトウェアコンポーネントに関連付けられる機密データの使用を防止することをさらに含む
請求項１に記載の方法。
【請求項１２】
前記方法は、
前記プラットフォームのトラステッドベースコンポーネントをルートにする階層に配置される複数のソフトウェアコンポーネントのそれぞれに適用され、
前記第１のタイプ及び前記第２のタイプの変更の結果として測定される前記完全性メトリックは、
前記トラステッドベースコンポーネントによって保持されるセキュアなロケーションに記憶され、
前記方法は、
前記ソフトウェアコンポーネントの前記完全性メトリック及び前記階層におけるその祖先の前記完全性メトリックがすべてそれぞれの予測値と一致しない限り、
前記ソフトウェアコンポーネントに関連付けられる機密データの使用を防止することをさらに含む
請求項１に記載の方法。
【請求項１３】
前記ソフトウェアコンポーネントは、前記プラットフォーム上で実行されるハイパーバイザによって確立されるドメインである
請求項１に記載の方法。
【請求項１４】
前記ソフトウェアコンポーネントは、前記プラットフォーム上で実行されるハイパーバイザによって確立されるドメインで実行されるコンポーネントである
請求項１に記載の方法。
【請求項１５】
コンピューティングプラットフォームであって、前記コンピューティングプラットフォーム上で使用されているソフトウェアコンポーネントの状態を追跡する監視機構を含み、
前記監視機構は、
前記ソフトウェアコンポーネントに対する第１のタイプの変更及び第２のタイプの変更を検出及び区別する変更応答手段と、
第１のメモリレジスタ及び第２のメモリレジスタと、
前記ソフトウェアコンポーネントの前記第１のタイプの変更の検出に応答して、前記ソフトウェアコンポーネントの適切な完全性メトリックを確実に測定する第１の測定手段と、
前記第１の測定手段によって測定される前記完全性メトリックを、前記ソフトウェアコンポーネントに対する前記第１のタイプの変更について前記第１のレジスタに記録されるあらゆる前の完全性メトリック値と累積的に組み合わせて、前記第１のレジスタに記録する第１の記録手段と、
前記ソフトウェアコンポーネントの前記第２のタイプの変更の検出に応答して、前記ソフトウェアコンポーネントの適切な完全性メトリックを確実に測定する第２の測定手段と、
前記第２の測定手段によって測定される前記完全性メトリックを、前記ソフトウェアコンポーネントに対する前記第２のタイプの変更について前記第２のレジスタに記録されるあらゆる前の完全性メトリック値の代わりとして、前記第２のレジスタに記録する第２の記録手段と
を備えるコンピューティングプラットフォーム。
【請求項１６】
前記第１のタイプの変更は、
前記コンポーネントの完全性にクリティカルな部分に対して行われる変更、すなわち、前記コンポーネントがその目的とする機能を実施する能力に影響を与える可能性のある前記コンポーネントのコード又は他のデータに対して行われる変更であり、
前記第２のタイプの前記変更は、
前記コンポーネントの完全性にクリティカルでない部分に対して行われる変更、すなわち、前記コンポーネントがその目的とする機能を実施する能力に実質的に影響を与えない前記コンポーネントのコード又は他のデータに対して行われる変更である
請求項１５に記載のコンピューティングプラットフォーム。
【請求項１７】
前記第１のタイプの変更の結果として測定される前記完全性メトリックは、
少なくとも、前記ソフトウェアコンポーネントの前記完全性にクリティカルな部分について測定され、
前記第２のタイプの変更の結果として測定される前記完全性メトリックは、
少なくとも、前記ソフトウェアコンポーネントの前記完全性にクリティカルでない部分について測定される
請求項１６に記載のコンピューティングプラットフォーム。
【請求項１８】
前記ソフトウェアコンポーネントは、
必要なコンポーネント機能を提供する機能群と、
前記機能群が実行される実行環境と
を含む請求項１５に記載のコンピューティングプラットフォーム。
【請求項１９】
前記第１のレジスタ及び前記第２のレジスタは、論理的に、前記ソフトウェアコンポーネントに関連付けられるトラステッドエンティティの一部である
請求項１５に記載のコンピューティングプラットフォーム。
【請求項２０】
前記コンピューティングプラットフォームは、
階層における自身の親のソフトウェアコンポーネントの実行環境で実行される前記階層における子である各ソフトウェアコンポーネントによって階層的に配置される複数のソフトウェアコンポーネントを含み、
前記階層の各ソフトウェアコンポーネントの状態は、別個に追跡され、
各コンポーネントは、
それぞれの関連付けられる第１のレジスタ及び第２のレジスタと、それぞれの第１の測定手段及び第１の記録手段並びに第２の測定手段及び第２の記録手段とを有する
請求項１９に記載のコンピューティングプラットフォーム。
【請求項２１】
前記プラットフォームは、すべての前記ソフトウェアコンポーネントに共通のトラステッドベースコンポーネントを含み、
各ソフトウェアコンポーネントに関連付けられる第１のレジスタ（７８）及び第２のレジスタ（７９）から成る前記ペアは、
前記トラステッドベースコンポーネントによって保持される
請求項２０に記載のコンピューティングプラットフォーム。
【請求項２２】
前記ベースコンポーネントは、前記階層のルートを形成する
請求項２０に記載のコンピューティングプラットフォーム。
【請求項２３】
前記ベースコンポーネントは、前記階層の実行環境を提供する
請求項２２に記載のコンピューティングプラットフォーム。
【請求項２４】
前記ベースコンポーネントは、前記プラットフォームのトラステッドコンピューティングベースの一部である
請求項１９に記載のコンピューティングプラットフォーム。
【請求項２５】
前記第１のタイプの変更について記録される前記完全性メトリックから生じる現在の累積値と、前記第２のタイプの変更について最後に記録される前記完全性メトリック値とが、共にそれぞれの予測値と一致しない限り、
前記ソフトウェアコンポーネントに関連付けられる機密データの使用を防止するアクセス制御機構をさらに含む
請求項１５に記載のコンピューティングプラットフォーム。
【請求項２６】
前記プラットフォームは、
前記プラットフォームのトラステッドベースコンポーネントをルートにする階層に配置される複数のソフトウェアコンポーネントを含み、
各ソフトウェアコンポーネントは、
それぞれの第１のレジスタ及び第２のレジスタ並びにそれぞれの第１の測定手段及び第２の測定手段を有し、
前記第１のレジスタ及び前記第２のレジスタは、
前記トラステッドベースコンポーネントによって保持されるセキュアなロケーションを含み、
前記コンピューティングプラットフォームは、
前記ソフトウェアコンポーネントの前記完全性メトリック及び前記階層におけるその祖先の前記完全性メトリックがすべてそれぞれの予測値と一致しない限り、
前記コンポーネントに関連付けられる機密データの使用を防止するアクセス制御機構をさらに含む
請求項１５に記載のコンピューティングプラットフォーム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューティングプラットフォームで動的信頼管理を可能にする方法及び装置に関する。
【背景技術】
【０００２】
検証可能な信頼は、コンピューティングシステムにとって望ましい特性である。ユーザは、自身が使用しようとしている（又は使用中の）コンピューティングプラットフォームが、信用でき且つ予測できる方法で振る舞うのか、又は破壊を受けやすい（又は既に破壊を受けている）のかを知ることには根本的な興味を持っている。
【０００３】
既存のトラステッドプラットフォームは、通常、破壊から少なくとも論理的に保護されているコンポーネントを含んでいる。このようなプラットフォームは、トラステッドコンピューティンググループ（ＴＣＧ）を形成する企業によって開発されている。この団体は、この分野の仕様を策定し、現行のＴＣＧ仕様は、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()要求（適切なオプションを有する）を使用して開始される。
【００９０】
第１の例の証明プロトコル。この場合、サードパーティユーザは、対象となるサービスの完全性の検証者として機能する（すなわち、プラットフォーム及びＴＣＢのすべての関連のあるコンポーネントの予測値にアクセスする）。以下は、図１１の階層のコンポーネントＣが、対象となるコンポーネントであるものと仮定している。
１．サードパーティユーザは、証明モジュール２０４によって提供された証明インターフェースを使用して、サービスコンポーネントＣの完全性をチェックし、関連する現在のすべての完全性測定の署名されたコピーを要求する。
２．証明モジュール２０４は、コンポーネントＣのＤＴＥの識別情報を使用して階層内でＣを位置特定する。
３．証明モジュール２０４は、Ｃ、Ｂ、及びＴＣＢの完全性（すなわち、レジスタ値）に加えて、コンポーネントＣ、Ｂ、及びＴＣＢの完全性測定の署名されたコピーから成る署名をサードパーティユーザに返す。コンポーネントＣ、Ｂの完全性測定のコピーは、証明モジュール２０４によって署名され、ＴＣＢの完全性測定のコピーは、プラットフォームのトラステッドモジュールＴＭによって署名され、これら署名されたコピーから成る署名は、以下の通りである。
【００９１】
【数１】
2009015818.tif 000003
【００９２】
式中、
【００９３】
【数２】
2009015818.tif 000004
【００９４】
は、添え字のエンティティによる署名であり、Ｉは、添え字の要素に関して行われた完全性測定を示す。
４．サードパーティユーザは測定を受け取り、署名を検証すると、ＴＣＢ及びコンポーネントＢ、Ｃの現在のレジスタ値を予測値と比較し、Ｃを信頼するか否かを決定する。
【００９５】
第２の例の証明プロトコル。この場合、検証者はプラットフォームであり、サードパーティユーザは、プルーフを有する信頼される回答又は単一の信頼されない回答のいずれかを受け取る。プロトコルの最初の２つのステップは、上記と同じである。３番目のステップでは、フレームワークは、完全性測定を返す代わりに、現在の値と予測値とを比較する。たとえば、サービスコンポーネントＣについて、フレームワークは、Ｃ及びＢの双方の静的測定及び動的測定を予測値と比較した後、信頼される回答を返す。その回答と共に、フレームワークは、ＴＣＢの完全性、及び、プルーフとして署名
【００９６】
【数３】
2009015818.tif 000005
【００９７】
を返す。この理由は、この例では、サードパーティユーザが、まだ、回答がトラステッドプラットフォームによって生成されたことを検証する必要があるためである。
【００９８】
本発明の説明した実施形態によって、動的コンポーネントは、一定の条件の下で全ての再起動を必要とすることなく信頼を再確立することが可能になることが十分理解されよう。これは、頻繁に変化すると共にさまざまなセキュリティモードで動作するコンポーネントを有するシステムにとって特に好都合である。監視及び報告が進行中であることによって、コンポーネントは、最新のシステム状態を反映することが可能になる。これは、ブート中に１回、コンポーネントを測定する現在の実施態様とは対照的に、システムについての最新の情報を提供する。
【００９９】
さらに、完全性測定値は、ソフトウェアレジスタに記憶されるので、説明した実施形態は、ハードウェアレジスタが完全性測定値の全部のセットを記憶することを必要とする現在の構成よりも拡張性がある。
【０１００】
説明した階層的完全性管理方式（すなわち、信頼ツリー）は、複雑なシステムにとっては、線形モデル（すなわち、信頼チェーン）を提供する現在の解決法よりも適している。必要な切り離し特性が保証される場合、この階層的手法は、以下のものを可能にするきめ細かな完全性管理解決法を提供する。
より良好な表現：階層的手法によって、互いに依存関係を有しないコンポーネントは、別々の完全性チェーンを構築することが可能になる。したがって、コンポーネントの完全性は、自身に加えてその祖先の完全性のみを伴う。
切り離し：コンポーネントに対する変更は、完全性チェーンの適切な分岐に切り離されるにすぎず、したがって、プラットフォーム全体に影響を与えることはない。その結果、クリティカル変更は、もはや、プラットフォーム全体の再起動及び再測定を必要とせず、適切な分岐の再起動及び再測定のみを必要とする。
【０１０１】
本発明の上述した実施形態に対して多くの変形が可能であることが十分理解されよう。詳細には、当業者は、本発明が、そのオペレーションについて、図１〜図６を参照して上述した特定の形態のトラステッドプラットフォーム技術の使用にも、ＴＣＧ仕様で説明されたような特定の形態のトラステッドプラットフォーム技術の使用にも依拠しないことを十分理解するであろう。
【０１０２】
上述した変更の分類とは異なる変更の分類を使用することができる。
【０１０３】
コンポーネントは、実行を通じてプラットフォームの信頼状態を変更できる任意のプラットフォームエンティティであることに留意すべきである。プラットフォームコンポーネントの詳細に対する制限はない。一例として、コンポーネントは、仮想ドメイン（パーティション）に存在するサービスとすることができる。代替的に、コンポーネントは、仮想ドメインそのものとすることもできる。したがって、プラットフォームコンポーネントを定義する際の正確な粒度は、プラットフォーム上で必要とする完全性管理の粒度に依存する。
【０１０４】
完全性管理の好都合に異なる粒度を同時に使用することができる。たとえば、異なるコンポーネント粒度を有する２つのレベルの信頼管理を同じプラットフォーム上で使用することができる。したがって、上述したＳＳＭＦを、以下のローカルな状況及びグローバルな状況の双方で適用することができる。
ローカル状況では、ローカルＳＳＭＦが、（それ自身の仮想ドメイン又はパーティションに確立された）単一の仮想マシンに存在するセキュリティサービスを管理するのに使用される。複数の仮想ドメインの場合、各ドメインは、他のドメインのローカルＳＳＭＦから独立して機能するローカルＳＳＭＦの実施態様を含む）。
グローバルな状況では、グローバルＳＳＭＦが、それぞれが自身の仮想ドメイン内に存在する複数の仮想マシンから成る階層を管理するのに使用される。この場合、仮想マシン間の依存関係は、暗黙的なものでははく、明示的に提示されることに留意されたい（すなわち、実行順序によって、ＶＭ間の暗黙的な祖先関係はない）。たとえば、仮想マシンの１つが、仮想マシンの残りのものの管理を担当する管理マシンとして機能する場合、管理仮想マシンが、残りの子仮想マシンの親の役割を引き受ける明示的な依存関係が存在する。
【０１０５】
図１３は、セキュアなハイパーバイザ３０１を実行して複数の仮想ドメイン（「Ｄｏｍ０」〜「ＤｏｍＸ」と呼ぶ）３０２〜３０９を提供するホスト３００についてグローバルＳＳＭＦの使用及びローカルＳＳＭＦの使用を組み合わせたものを示している。グローバルＳＳＭＦ３３２は、Ｄｏｍ０のトラステッドアプリケーションとして実行され、それぞれが自身の仮想ドメイン内に存在する仮想マシンから成る階層を管理する働きをする。グローバルＳＳＭＦ３３２と、グローバルＳＳＭＦ３３２が管理する仮想マシンとの間の通信は、ドメイン間通信機構３２０を通じて行われる。ドメイン３０３〜３０９のそれぞれは、それ自身のローカルＳＳＭＦ３３３〜３３９をそれぞれ有する。
【図面の簡単な説明】
【０１０６】
【図１】一例示の従来技術のコンピュータプラットフォームの図である。
【図２】従来技術のトラステッドコンピュータプラットフォームのマザーボード上に存在する機能エレメントを示す図である。
【図３】図２のトラステッドコンピュータプラットフォームの従来技術のトラステッドデバイスの機能エレメントを示す図である。
【図４】図２のトラステッドデバイスのプラットフォーム構成レジスタ内に値を拡張する既知の従来技術のプロセスを示す図である。
【図５】図４のトラステッドデバイスに関連付けられる鍵の階層の図である。
【図６】ハイパーバイザを実行し、複数の切り離されたオペレーティングシステム環境を提供する別の従来技術のコンピューティングプラットフォームの図である。
【図７】動的コンポーネント及び関連付けられる動的トラステッドエンティティを示す本発明の第１の実施形態の図である。
【図８】図７の動的コンポーネントの状態図である。
【図９】図７と同様であるが、第１の実施形態の階層的実施態様を示す図である。
【図１０】図９の形態の動的コンポーネント及び関連付けられる動的トラステッドエンティティの階層の図である。
【図１１】本発明の第２の実施形態について、動的コンポーネント及びそれらに関連付けられる動的トラステッドエンティティの別の階層を示す図であって、この階層がトラステッドプラットフォームのトラステッドコンピューティングベースのコンポーネントをルートとする図である。
【図１２】第２の実施形態に基づくセキュリティサービス管理フレームワークを示す図である。
【図１３】複数の仮想ドメインを有し、グローバルセキュリティサービス管理フレームワーク及びドメイン特有のローカルセキュリティサービス管理フレームワークの双方が提供されたホストプラットフォームを示す図である。
【符号の説明】
【０１０７】
３・・・不揮発性メモリエリア
４・・・揮発性メモリエリア
８ａ〜８ｎ・・・プラットフォーム構成レジスタ（ＰＣＲ）
１０・・・トラステッドプラットフォーム
１４・・・キーボード
１６・・・マウス
１８・・・視覚表示ユニット（ＶＤＵ）
２０・・・マザーボード
２１・・・メインプロセッサ
２２・・・メインメモリ
２３・・・入出力（ＩＯ）デバイス
２４・・・トラステッドデバイス
２６・・・データバス
２７・・・制御ライン
２８・・・アドレスライン
２９・・・ＢＩＯＳメモリ
３０・・・コントローラ
３１・・・測定機能
３２・・・暗号機能
３３・・・認証機能
３４・・・インターフェース回路部
３６、３７、３８・・・ポート
４１・・・入力
４２・・・ハッシュ
４３・・・連結
５１・・・ストレージルート鍵（ＳＲＫ）
５２・・・データオブジェクトの階層（ツリー）
５４・・・標準的なメモリ
６０・・・トラステッドプラットフォーム
６１・・・プラットフォームプロセッサ
６２・・・トラステッドデバイス
６３・・・ＲＯＭ
６４・・・ＢＩＯＳ
６５・・・セキュリティカーネル
６６・・・ハイパーバイザ
６７Ａ〜６７Ｃ・・・パーティション
６８Ａ〜６８Ｃ・・・オペレーティングシステム環境
６９Ａ〜６９Ｃ・・・仮想トラステッドデバイス
７０・・・親コンポーネント
７１・・・動的コンポーネント
７２・・・変更タイプポリシー
７３・・・測定エージェント
７５、７５'Ｅ・・動的トラステッドエンティティ（ＤＴＥ）
７６・・・識別情報
７６'Ｅ・・・識別情報およびAssoc Data
７７、７７'Ｅ・・・完全性メトリックマネージャ
７８・・・静的レジスタ
７９・・・動的レジスタ
１００・・・トラステッドコンピューティングベース
１０１・・・信頼ルート
１０２・・・ベースコンポーネント
１０３・・・保護されているストレージ
２００・・・セキュリティサービス管理フレームワーク（ＳＳＭＦ）
２０１・・・セキュリティサービス管理インターフェース（ＳＳＭＩ）
２０２・・・コアセキュリティサービス管理モジュール
２０３・・・信用証明書モジュール
２０４・・・証明モジュール
２０６・・・サービス階層マネージャ
２０７・・・保護されているストレージ
２０８・・・サービス／報告マネージャ
３００・・・ホスト
３０１・・・セキュアなハイパーバイザ
３０２〜３０９・・・仮想ドメイン
３２０・・・ドメイン間通信機構
３３２・・・グローバルＳＳＭＦ
３３３〜３３９・・・ローカルＳＳＭＦ
３５０・・・証明書
３５１・・・トラステッドデバイスの公開鍵
３５２・・・プラットフォーム完全性メトリックの認証値
６００・・・トラステッドコンピューティングベース
６０１・・・アプリケーション
【図１】
2009015818.tif 000006
【図２】
2009015818.tif 000007
【図３】
2009015818.tif 000008
【図４】
2009015818.tif 000009
【図５】
2009015818.tif 000010
【図６】
2009015818.tif 000011
【図７】
2009015818.tif 000012
【図８】
2009015818.tif 000013
【図９】
2009015818.tif 000014
【図１０】
2009015818.tif 000015
【図１１】
2009015818.tif 000016
【図１２】
2009015818.tif 000017
【図１３】
2009015818.tif 000018
【外国語明細書】
Dynamic Trust Management
Field of the Invention
The present invention relates to methods and apparatus for enabling dynamic trust management in computing platforms. 
Background of the Invention
Verifiable trust is a desirable property for computing systems - a user has a fundamental interest in knowing whether a computing platform about to be used (or in use) by the user will behave in a reliable and predictable manner, or will be (or already is) subject to subversion. 
Existing trusted platforms typically contain a component at least logically protected from subversion; such platforms have been developed by the companies forming the Trusted Computing Group (TCG) - this body develops specifications in this area and the current TCG specifications are available at http://www.trustedcomputinggroup.org (see, in particular,  the Trusted Platform Module Design Principles specification). The implicitly trusted components of a trusted platform (and, in particular, the Trusted Platform Module or 'TPM') enable integrity measurements of the platform to be reliably made and stored and subsequently reported as integrity metrics to users (including remote computing entities) wishing to interact with the platform.  Such users are then able to determine from the consistency of the measured integrity metrics with known or expected values that the platform is operating as expected.
With the general trend of designing systems that maximize resource sharing (e.g., through virtualization technology), parties that consume these resources increasingly require a means of verifiable trust before deploying information-sensitive content on these systems. This issue is particularly critical for systems that host parties with potentially conflicting interests. A challenge in trust management is to manage trustworthiness in highly dynamic virtualized computer systems. This involves being able to monitor system integrity in an on-going fashion and to report changes in order to reflect the current system state. This is particularly crucial for systems in which system configuration and security policies frequently change and components are allowed to operate in various security modes. Current solutions usually deem such changes as malicious and, for example, require a system reset and restart to be able to re - establish trust. These solutions are either impractical or do not scale as the number of system components increase in a complex computer system.
The trust architecture set out in the TCG specifications mainly addresses the creation of a chain-of-trust in a static manner in which the relevant state of software components is measured once at the time it is loaded. These measurements are stored in so-called Platform Configuration Registers (PCR) of the TPM, and are incremental, that is, a sequence of measurements can be reported in the same PCR by incrementally extending the previous measurement without changing its size, thus enabling virtually infinite number of measurements. This way, the complete execution sequence can be recorded enabling a third-party to verify it at a later phase. This static architecture imposes several limitations on complex dynamic systems in which system configuration and security policies are allowed to change frequently:
The TCG trust architecture does not efficiently handle the situation in which critical (i.e., measured) system components are allowed to change into another form (e.g., through a software update) or adapt to current conditions, or the situation in which system components may function in various operating modes (e.g., with different configurations) to perform operations with varying security needs. In either situation, the TCG specifications takes the conservative approach and deem any such change as potentially malicious and irreversible.
Summary of the Invention
According to a first aspect of the present invention, there is provided a method of tracking the state of a software component in use on a computing platform, the method comprising:
upon a change of a first type in the software component, reliably measuring and recording an appropriate integrity metric of the software component in cumulative combination with any previous integrity metric values recorded for changes of said first type to the software component; and 
upon a change of a second type in the software component, reliably measuring and recording an appropriate integrity metric of the software component as a replacement for any previous integrity metric value recorded for changes of said second type to the software component.
According to a second aspect of the present invention, there is provided a computing platform including a monitoring arrangement for tracking the state of a software component in use on the computing platform, the monitoring arrangement comprising:
change responsive means for detecting and distinguishing first and second types of changes to the software component;
first and second memory registers;
first measuring means responsive to detection of a change of the first type in the software component, to reliably measure an appropriate integrity metric of the software component;
first recording means for recording the integrity metric measured by the first measuring means in the first register in cumulative combination with any previous integrity metric values recorded in the first register for changes of said first type to the software component;
second measuring means responsive to detection of a change of the second type in the software component, to reliably measure an appropriate integrity metric of the software component;
second recording means for recording the integrity metric measured by the second measuring means in the second register as a replacement for any previous integrity metric values recorded in the second register for changes of said second type to the software component.
Brief Description of the Drawings
Embodiments of the invention will now be described, by way of non-limiting example, with reference to the accompanying diagrammatic drawings of the prior art and of embodiments of the invention, in which:
Figure 1  is an illustration of an exemplary prior-art computer platform;
Figure 2  indicates functional elements present on the motherboard of a prior-art trusted computer platform;
Figure 3  indicates the functional elements of a prior-art trusted device of the trusted computer platform of Figure 2; 
Figure 4  illustrates the known prior-art process of extending values into a platform configuration register of the trusted device of Figure 2;
Figure 5  is a diagram of a key hierarchy associated with the trusted device of Figure 4;
Figure 6  is a diagram of a further prior-art computing platform running a hypervisor and providing for multiple isolated operating system environments;
Figure 7  is a diagram of a first embodiment of the invention showing a dynamic component and an associated dynamic trusted entity;
Figure 8  is a state diagram of the dynamic component of Figure 7;
Figure 9  is a diagram, similar to Figure 7, but showing an hierarchical  implementation of the first embodiment;
Figure 10  is a diagram of a hierarchy of dynamic components and  associated dynamic trusted entities of the  Figure 9 form; 
Figure 11  is a diagram showing, for a second embodiment of the invention, a  further hierarchy of dynamic components and  their associated dynamic trusted entities, this hierarchy being rooted in a component of the trusted computing base of a trusted platform;
Figure 12 is a diagram illustrating a security-services management framework based on the second embodiment; and
Figure 13 is a diagram illustrating a host platform with multiple virtual domains and provided both with a global security- services management framework and with domain-specific local security-services management frameworks.
Detailed Description of Embodiments of the Invention
Before describing embodiments of the present invention,  two prior-art trusted computing platforms will be described with reference to Figures 1 to 6 to introduce certain terms and concepts later used in describing the embodiments of the invention.  The specifics of the described prior-art trusted computing platforms (starting with the next paragraph) are not intended to limit the scope of the present invention unless otherwise stated.  As used herein, the term "computing platform" is to be understood as encompassing any apparatus capable of effecting computation and is not limited to computers; for example, digital cellular equipment (including mobile telephones) have substantial computing capability and are within the scope of the term "computing platform". Furthermore, in the present context "trust" is the expectation that a device will behave in a particular manner for a specific purpose, and. a "user" can be a local user or a remote user such as a remote computing entity.  
General Characteristics of a Prior-Art Trusted Platform
A trusted computing platform provides for trustable platform integrity measurement and reporting. and to this end has a plurality of shielded locations, that is, places (memory, registers, etc.) where it is safe to operate on sensitive data. Integrity measurement is the process of obtaining integrity metric measurements of a platform (that is, measurements of platform characteristics that affect the integrity - trustworthiness - of the platform) and putting the measurements (here taken to encompass derivative values such as digests) into shielded locations; in TCG parlance, the shielded locations used for storing integrity metrics are referred to as Platform Configuration Registers or "PCRs" and this terminology will be used hereinafter. The values held in the PCRs are reportable integrity metric values. Integrity reporting is the process of attesting to integrity metrics recorded in PCRs in a way that associates the metrics with the platform concerned. A trusted computing platform may also provide, in addition to shielded locations, trustable storage for securely storing data in encrypted form and for ensuring that access to this data only occurs in a named environment. The foregoing trusted features will normally involve the use of cryptographic functions.
A user can verify the correct operation of a trusted computing platform, for example, before exchanging data with the platform, by requesting the trusted platform to provide one or more integrity metrics.  The user receives the integrity metric or metrics, and compares them against values which it believes to be true (these values being provided by a trusted party, TP that is prepared to vouch for the trustworthiness of the platform or by another party the user is willing to trust).  If there is a match, the implication is that at least part of the platform is operating correctly, depending on the scope of the integrity metric.  If there is no match, the assumption is that the entire platform has been subverted and cannot be trusted (unless isolation technologies are employed to restrict the scope of what cannot be trusted).
Once a user has established trusted operation of the platform, he exchanges  data with the platform.  For a local user, the exchange might be by interacting with some software application running on the platform.  For a remote user, the exchange might involve a secure transaction.  In either case, the data exchanged is  preferably 'signed' by the trusted platform.  The user can then have greater confidence that data is being exchanged with a platform whose behaviour can be trusted.  Data exchanged may be information relating to some or all of the software running on the computer platform.  
Trusted Entity Providing for Roots of Trust
In order to impart to a computing platform the characteristics of a trusted computing platform, it is necessary to provide the platform with certain inherently trustable functionalities (collectively making up what is herein referred to as a "trusted entity") which are is physically or logically bound to the platform and operate, together with elements of the computing platform, to provide the desired trusted characteristics (minimally, integrity measurement and reporting). In effect, the trusted entity provides the platform with 'roots of trust' and an example of this is given below.
For trusted platforms following the TCG Specifications, the trusted entity is called a Trusted Platform Module ("TPM") and serves to provide, together with elements of the computing platform to which the trusted entity is bound, the following "roots of trust": 
:A root of trust for measurement (RTM), - the RTM is a computing engine capable of making inherently reliable integrity measurements and is typically the normal platform computing engine (main processor) controlled by the so-called core root of trust for measurement (CRTM), that is the instructions executed by the platform when it acts as the RTM. The CRTM is logically part of the aforesaid trusted entity and would ideally be included in the TPM but for cost reasons is usually implemented by a separate ROM .
A root of trust for storage (RTS) - the RTS is a computing engine capable of maintaining an accurate summary in PCRs of values of integrity measurement digests; the RTS may also provide for  'protected storage' serving to protect data (frequently keys) held in external storage devices as opaque "blobs" and 'sealed' / 'unsealed' for access by the RTS against a particular environment (as indicated by PCR values). 
A root of trust for reporting (RTR) - the RTR is a computing engine responsible for establishing platform identities, reporting platform configurations (PCR values), protecting reported values and establishing a context for attesting to reported values. The RTR shares responsibility of protecting measurement digests with the RTS.
It may be noted that, as indicated above, the elements forming the RTM are typically (though not necessarily) outside a TPM; in contrast, the RTS and RTR are normally provided by the TPM itself.
Generally, any trusted platform will provide such roots of trust (though possibly in a different conceptual arrangement).
A trusted entity can be embodied as a hardware device (which may include a program-controlled processor) or in software for execution by a main processor of the platform (in which case it is usually referred to as a 'virtual' trusted entity/device or in the case of a TPM, a virtual TPM). In practice, virtual trusted entities are normally provided on platforms that have a basic hardware trusted entity for the basic platform environment but which employ further trusted entities for virtual environments created on the platform.
It is, of course, also possible to implement a trusted entity as a combination of a hardware device and software intended for execution on the platform processor; this is suitable, for example, for the software implementation of higher-level features of the trusted entity (non core features) where the trustworthiness of the software can be established by a chain of trust rooted in the RTM.
The functionality of the trusted entity can be distributed between multiple devices (in the case of a hardware embodiment) or code blocks (in the case of a 'virtual' embodiment).
The trusted entity uses cryptographic processes but does not necessarily provide an external interface to those cryptographic processes.  The trusted entity should be logically protected from other entities - including other parts of the platform of which it is itself a part.  Also, most desirable implementations provide the trusted entity with protective features to protect secrets stored by or being processed by the trusted entity by making them inaccessible to other platform functions, and provide an environment that is substantially immune to unauthorised modification 
For a hardware embodiment, the trusted entity, therefore, preferably consists of one physical component that is tamper-resistant.  Techniques relevant to tamper-resistance are well known to those skilled in the art of security.  These techniques include methods for resisting tampering (such as appropriate encapsulation of the trusted entity), methods for detecting tampering (such as detection of out of specification voltages, X-rays, or loss of physical integrity in the trusted entity casing), and methods for eliminating data when tampering is detected. As regards a 'virtual' trusted entity, although software may not afford such a high degree of tamper-resistance as a hardware device, this may be compensated for by additional protection measures.  For example, the software code may include self-test functions, to check the integrity of the trusted functionality.  Other measures would be known for protecting software-based implementations.
Chain of Trust
The trustable integrity measurement and reporting enabled by the presence of the trusted entity in the platform typically enables trust to be placed in other platform components or functions which in turn perform trustable integrity measurement of further platform components or functions and so on. This process of extending the boundary of what is trustable is called "transitive trust" and can be thought of as establishing a chain of trust rooted in the platform's roots of trust. Thus in a typical example:
-      the trusted code for effecting an initial integrity measurement (the CRTM in TCG parlance) serves to measure an integrity metric of OS loader code to enable trust to be placed in this code (if the metric match the expected value); 
-      the OS loader code in turn determines an integrity metric for Operating System code to enable trust to be placed in the operating system; 
-      the operating system in turn determines an integrity metric for application code to enable trust to be placed in the application.  
First Example Prior-Art Trusted Platform - Overview
An example trusted platform 10 is illustrated in the diagram in Figure 1.  The computing platform 10 is shown as a so-called personal computer and is  entirely conventional in appearance - it has associated the standard features of a keyboard 14, mouse 16 and visual display unit (VDU) 18, which provide the physical 'user interface' of the platform.  The computing platform 10 is arranged to run a standard operating system such as MicrosoftTM Windows XPTM.
As illustrated in Figure 2, the motherboard 20 of the trusted computing platform 10 includes (among other standard components) a main processor 21, main memory 22, a trusted entity here embodied in the form of trusted device 24 (such as a hardware TPM), a data bus 26 and respective control lines 27 and address lines 28, BIOS memory 29 containing the BIOS program for the platform 10, an Input/Output (IO) device 23, which controls interaction between the components of the motherboard and the keyboard 14, the mouse 16 and the VDU 18, and an I/O device 25, for example an Ethernet controller, for controlling communications with remote devices or systems.  The main system memory 22 is typically random access memory (RAM).  In operation, the platform 10 loads the operating system, in this case Windows XPTM, into RAM from hard disk (not shown).  Additionally, in operation, the platform 10 loads the processes or applications that may be executed by the platform 10 into RAM from hard disk (not shown). The mounting of the trusted device 24 on the mother board serves to bind it to the platform.
Typically, in a personal computer, the BIOS program is located in a special reserved memory area, such as the upper 64K of the first megabyte of the system memory (addresses FOOOh to FFFFh), and the main processor is arranged to look at this memory location first, in accordance with an industry wide standard.  A significant difference between the trusted platform under discussion and a conventional platform is that, after reset, the main processor is initially controlled by CRTM code (which in the present example comprise hash function code stored in the trusted device 24) which then hands control over to the platform-specific BIOS program, which in turn initialises all input/output devices as normal.  After the BIOS program has executed, control is handed over as normal by the BIOS program to an operating system program, such as Windows XPTM, which is typically loaded into main memory 22 from a hard disk drive (not shown).  
The main processor 21 is initially controlled by the CRTM code because it is necessary to place trust in the first measurement to be carried out on the trusted platform.  The CRTM code is typically trusted at least in part because its provenance.  As already indicated, the main processor 21 when under control of the CRTM forms the "root of trust for measurement" RTM.  As is typical, one role of the RTM in the present case is to measure other measuring agents before these measuring agents are used and their measurements relied upon.  The RTM is the basis for the aforementioned 'chain of trust'.  Note that the RTM and subsequent measurement agents do not need to verify subsequent measurement agents; they merely measure and record them before they execute.  This is called an "authenticated boot process".  Valid measurement agents may be recognised by comparing a digest of a measurement agent against a list of digests of valid measurement agents.  Unlisted measurement agents will not be recognised, and measurements made by them and subsequent measurement agents are deemed to be suspect.
Example Trusted Device
Further details will now be given of an implementation of the trusted device 24, it being understood that corresponding functionality can be provided in a software trusted entity (that is, virtual trusted device).
The trusted device 24 comprises a number of blocks, as illustrated in Figure 3. As already indicated, after system reset the trusted device 24 participates in an authenticated boot process to ensure that the operating state of the platform 10 is recorded in a secure manner.  During the authenticated boot process, the trusted device 24 acquires at least one integrity metric of the computing platform 10.   The trusted device 24 can also perform secure data transfer and, for example, authentication between it and a smart card via encryption/decryption and signature/verification.  The trusted device 24 can also securely enforce various security control policies, such as locking of the user interface.  In a particularly preferred arrangement, the display driver for the computing platform is located within the trusted device 24 with the result that a local user can trust the display of data provided by the trusted device 24 to the display.
Specifically, the trusted device 24 in this embodiment comprises: a controller 30 programmed to control the overall operation of the trusted device 24, and interact with the other functions on the trusted device 24 and with the other devices on the motherboard 20; a measurement function 31 for acquiring a first integrity metric from the platform 10 either via direct measurement or alternatively indirectly via executable instructions to be executed on the platform's main processor; a cryptographic function 32 for signing, encrypting / decrypting specified data; an authentication function 33 for authenticating a smart card; and interface circuitry 34 having appropriate ports (36, 37 & 38) for connecting the trusted device 24 respectively to the data bus 26, control lines 27 and address lines 28 of the motherboard 20.  Each of the blocks in the trusted device 24 has access (typically via the controller 30) to appropriate volatile memory areas 4 and/or non-volatile memory areas 3 of the trusted device 24.  As has already been described, the trusted device 24 is designed, in a known manner, to be tamper resistant.
For reasons of performance, the trusted device 24 may be implemented as an application specific integrated circuit (ASIC).  However, for flexibility, the trusted device 24 is preferably an appropriately programmed micro-controller.  Both ASICs and micro-controllers are well known in the art of microelectronics and will not be considered herein in any further detail.  
One item of data that is preferably stored in the non-volatile memory 3 of the trusted device 24 is a certificate 350.  The certificate 350 contains at least a public key 351 of the trusted device 24 and an authenticated value 352 of the platform integrity metric measured by a trusted party (TP).  The certificate 350 is signed by the TP using the TP's private key prior to it being stored in the trusted device 24.  In later communications sessions, a user of the platform 10 can deduce that the public key belongs to a trusted device by verifying the TP's signature on the certificate. Also, a user of the platform 10 can verify the integrity of the platform 10 by comparing the acquired integrity metric with the authentic integrity metric 352.  If there is a match, the user can be confident that the platform 10 has not been subverted.  Knowledge of the TP's generally-available public key enables simple verification of the certificate 350.  The non-volatile memory 35 also contains an identity (ID) label 353.  The ID label 353 is a conventional ID label, for example a serial number, that is unique within some context.  The ID label 353 is generally used for indexing and labeling of data relevant to the trusted device 24, but is insufficient in itself to prove the identity of the platform 10 under trusted conditions.
As already indicated, the trusted device 24 cooperates with other elements of the platform 10 to reliably acquire at least one integrity metric of the platform.   In the present embodiment, a first integrity metric is acquired by having the main platform processor execute the CRTM code that is stored in the trusted device 24; the CRTM when executed by the platform processor generates a digest of the BIOS instructions in the BIOS memory and passes it to the measurement function for storage.  Such an acquired integrity metric, if verified as described above, gives a potential user of the platform 10 a high level of confidence that the platform 10 has not been subverted at a hardware, or BIOS program, level..
It would alternatively be possible to provide a measurement engine within the trusted device and have this engine form an integrity measurement on the BIOS code on platform start up (reset). 
In the present example, the measurement function 31 has access to: non-volatile memory 3 for storing the CRTM hash code 354 and a private key 355 of the trusted device 24, and volatile memory 4 for storing acquired integrity metric measurements.  The trusted device 24 has limited memory, yet it may be desirable to store information relating to a large number of integrity metric measurements.  This is done in trusted computing platforms as described by the Trusted Computing Group by the use of Platform Configuration Registers (PCRs) 8a-8n.  The trusted device 24 has a number of PCRs of fixed size (the same size as a standard measurement digest) - on initialisation of the platform, these are set to a fixed initial value.  Integrity measurements are then "extended" into PCRs by a process shown in Figure 4.  The PCR 8i value is concatenated 43 with the input 41 which is the value of the integrity measurement to be extended into the PCR.  The concatenation is then hashed 42 to form a new 160 bit value.  This hash is fed back into the PCR to form the new value of the integrity metric concerned.  In addition to the extension of the integrity measurement into the PCR, to provide a clear history of measurements carried out the measurement process may also be recorded in a conventional log file (which may be simply in main memory of the computer platform).  For trust purposes, however, it is the PCR value that will be relied on and not the software log.
Clearly, there are a number of different ways in which an initial integrity metric value may be calculated, depending upon the scope of the trust required.  The measurement of the BIOS program's integrity provides a fundamental check on the integrity of a platform's underlying processing environment.  The integrity metric measurement should be of such a form that it will enable reasoning about the validity of the boot process - the value of the integrity metric can be used to verify whether the platform booted using the correct BIOS.  Optionally, individual functional blocks within the BIOS could have their own digest values, with an ensemble BIOS digest being a digest of these individual digests.  This enables a policy to state which parts of BIOS operation are critical for an intended purpose, and which are irrelevant (in which case the individual digests must be stored in such a manner that validity of operation under the policy can be established).
It may also be noted that, preferably, the BIOS boot process includes mechanisms to verify the integrity of the boot process itself.  Such mechanisms are already known from, for example, Intel's draft "Wired for Management baseline specification v 2.0 - BOOT Integrity Service", and involve calculating digests of software or firmware before loading that software or firmware.  Such a computed digest is compared with a value stored in a certificate provided by a trusted entity, whose public key is known to the BIOS.  The software/firmware is then loaded only if the computed value matches the expected value from the certificate, and the certificate has been proven valid by use of the trusted entity's public key.  Otherwise, an appropriate exception handling routine is invoked.  Optionally, after receiving the computed BIOS digest, the trusted device 24 may inspect the proper value of the BIOS digest in the certificate and not pass control to the BIOS if the computed digest does not match the proper value -  an appropriate exception handling routine may be invoked.
Once the BIOS code has been measured (and, preferably, verified) and then loaded, the BIOS preferably measures the next software component (such as OS loader) and causes a corresponding integrity metric measurement to be stored in the trusted device 24 before loading that software; in this way, a chain of trust can be built up to include the operating system and applications loaded by it, with corresponding integrity metrics being stored in the PCRs of the trusted device 24.
Other integrity checks may be carried out involving the measuring of program code and storing of a corresponding integrity metric measurement in the trusted device; for example, the CRTM or BIOS could be arranged to measure the BIOS programs associated with a SCSI controller to enable communications with peripheral equipment  to be trusted.  Other forms of integrity check may also be effected, for example memory devices or co-processors, on the platform could be verified by enacting fixed challenge/response interactions to ensure consistent results; these checks can also give rise to integrity metrics stored in the PCRs of the trusted device 24.
As will be clear from the foregoing, a large number of integrity measurement may be collected by measuring agents directly or indirectly measured by the RTM, and these integrity measurement extended into the PCRs of the trusted device 24.  Some - many - of these integrity measurement will relate to the software state of the trusted platform.  How the PCRs are allocated is preferably standardized for each platform type. By way of example, according to the TCG Specification for PC Clients, the PCRs are divided into two primary sets: the first set is designated for the platform's pre-OS environment (PCR[0-7]) and the other designated for the platform's OS (PCR[8-15]). In this case, the pre-OS PCRs provide the platform's initial chain of trust starting from platform reset; in other words, they establish a chain of trust from the CRTM through the OS's IPL (Initial Program Load) Code. 
Changes to a software component after its initial measurement  and loading result in the software component being re-measured and the resulting integrity measurement being passed to the trusted device to extend the PCR associated with that component. 
As already indicated, when a user wishes to communicate with the platform, he uses a challenge/response routine to challenge the trusted device 24 (the operating system of the platform, or an appropriate software application, is arranged to recognise the challenge and pass it to the trusted device 24, typically via a BIOS-type call, in an appropriate fashion).  The trusted device 24 receives the challenge and creates an appropriate response based on the measured integrity metric or metrics - this may be provided with the certificate(s) giving expected integrity-metric value(s) and signed.  This provides sufficient information to allow verification by the user.
Protected storage - sealing/unsealing data
As indicated above, a trusted entity such as the trusted device 24 may include trusted functionality (RTS) that provides a 'protected storage' mechanism for sealing data (typically keys or passwords) into an opaque blob held outside the trusted entity, the blob being subsequently accessible only when the platform is in a particular (trusted) state. This state is specified at the time of sealing by a digest of the values of some or all the PCRs.  To unseal the data blob, the same digest must be formed from the current values of the PCRs.  If the new digest is not the same as the digest in the opaque blob, then the user cannot recover the data.  
One approach to implementing protected storage in the trusted device 24 will now be described, this approach being that used in TPMs. As illustrated in Figure 5, in this approach, protected storage is implemented as a hierarchy (tree) 52 of data objects the root of which is a Storage Root Key (SRK) 51 that is permanently stored in the trusted device 24 (and not released from it). Apart from the SRK, the tree 52 can be stored outside of the trusted device in normal memory 54. When information in a node is used or revealed, the node is manipulated by the trusted device.  Each intermediate node object in the tree is encrypted by a key in the node object above it in the tree (the parent node), all the way back to the SRK root node; in Figure 5 two levels are shown below the SRK, namely a first level storing keys K1-1 to K1-3 and a second level storing keys K2-1and K2-2, the encrypted nature of each key being indicated by the surrounding hatched annulus). Each key has an associated authorisation value that an entity wishing to make use of the key must present to the trusted device 24 (or, more accurately, used in a protocol that proves knowledge of the value without revealing the value) before the trusted device permits the key to be used. Intermediate nodes in the tree will always be keys but leaf nodes can be arbitrary data (though frequently they will also be keys, such as symmetric keys for use by application processes in protecting bulk data). Keys in the tree can either be "non-migratable" meaning that the private key is only known to the trusted device, or "migratable" meaning that there is no guarantee about the origin and use of the private key.
Second Example Prior-Art Trusted Platform
Assuming that integrity metrics are recorded for the operating system and applications loaded by the operating system, the above-described trusted platform 10 enables a user to check the state of the platform and decide whether or not to trust it. If the operating system has run an application that is not trusted by a first user (though possibly trusted by a different user), the first user can detect this (even after the application has terminated) by checking the relevant PCRs. However, in this case, for the above-described trusted platform, the only way for trust in the platform to be re-established for the first user is for the platform to be re-started. This drawback is multiplied where the platform is used to run a compartmented operating system supporting multiple computing environments since, unless appropriate measures are in place, running an un-trusted application in any of the environments requires the platform to be re-started to re-establish trust.
A solution to this is to provide a hardware/software architecture that enables the core software (BIOS & operating system / hypervisor) to be isolated from higher-level software so that if the latter is not trusted, it is only necessary to rebuild trust from the core software (assuming the latter is trusted). Where the core software supports multiple computing environments, then provided the latter are isolated from each other, an untrusted environment can be restarted without restarting the core software or the other computing environments supported by it. Furthermore, where multiple computing environments are supported, it is convenient to provide a respective trusted entity (typically a virtual trusted device) for each such environment.
An example trusted platform 60 supporting multiple isolated computing environments will now be briefly described with reference to Figure 6. A fuller description of a trusted platform of this type can be found in US published patent application US 2003/0226031.
The trusted platform 60 shown in Figure 6 has one or more platform processors 61 and a hardware trusted device 62 similar to the previously described trusted device 24 but with the code forming the CRTM being in a separate ROM 63. In equivalent manner to that described above for the platform 10 and trusted device 24, following a platform reset, the CRTM code is run by one of the main platform processor 61 to determine an integrity metric for the BIOS code (stored for example in the same ROM 63 as the CRTM) and pass the metric to the trusted device 62 for insertion into a PCR. Thereafter, the BIOS is loaded 64 which in turn measures and records in trusted device 62 an integrity metric of security kernel code before loading the security kernel 65 ; the security kernel 65 then measures and records in trusted device 62 an integrity metric of hypervisor code before loading the hypervisor 66 (also called a virtual machine monitor). In practice, there will typically be more integrity metrics recorded and intermediate code modules loaded. The BIOS 64 and the security kernel 65 are run at the most privileged level of the main platform processor 61 while the hypervisor 66 is run at the second most privileged level of the main platform processor 61. All other code is run at a lower privilege level thus providing isolation of the BIOS and the hypervisor / security kernel 65 from potentially untrustworthy code. The elements 61 to 65 form the trusted computing base 600 of the platform 60. The hypervisor 66 may also be considered part of the trusted computing base with the proviso that for any complex program such as hypervisor 66, while it is possible to verify that the hypervisor code on the platform is identical to a reference version, it is very difficult to be sure that the reference version itself does not possess any security weaknesses.
The hypervisor 66 enables a plurality of operating system environments to be provided each in its own partition isolated from the other operating system environments; in Figure 6, by way of example, three operating system environments 68A, 68B and 68C are shown, each in its own respective partition 67A, 67B, 67C; each partition may be arranged to execute on a different platform processor 61, thereby improving the degree of isolation. The hypervisor 66 enables and protects communications between the partitions and with the outside world. Applications are run as required in an appropriate one of operating system environments; in the present case one application 601 is shown running in operating system environment 68A. Applications typically run at the lowest privilege level, below that of the operating system environments.
In the present example, each partition 67A, 67B, 67C has its own associated virtual trusted device 69A, 69B, 69C (although shown in Figure 6 in each partition, the virtual trusted devices are logically part of the security kernel and run at the same privilege level or in a separate partition.). The virtual trusted device of a partition is used to measure and record integrity metrics for the related operating system environment and any applications it is running.
It will be appreciated that the isolation provided by the platform 60, minimizes the software that must be re-started to re-establish trust in any particular partition. It will also be appreciated that the arrangement of having one hardware trusted device 62 and one virtual trusted device per partition is merely one possibility among many, including just having a single hardware or virtual trusted device for all the platform.
Embodiments of the Invention
In the above-described prior art trusted device 24, integrity measurements concerning a particular software component or collection of components are stored in a particular PCR by cumulative combination with values previously stored to the same PCR since its last reset. This ensures that a measurement indicating untrustworthy software will impact all subsequent values of the PCR enabling the fact that untrustworthy software has been loaded to be kept visible (even after the software concerned has been unloaded). This arrangement does not, however, efficiently handle the situation in which software components are allowed to change into another form (e.g., through a software update) or adapt to current conditions, or the situation in which system components may change between various operating modes (e.g., with different configurations) to perform operations with varying security needs. In either situation, the software component is likely to move from a trusted state to a state that is not trusted according to the value of its related PCR as updated following the change, even though the change may not affect the security of the component. The TCG specifications takes the conservative approach and deem any such change as potentially malicious and irreversible so that to re-establish trust it is necessary either to restart the platform (for a platform operating without privilege levels) or the partition concerned(for a platform such as described above with reference to Figure 6).
In the following description of embodiments of the invention, changes to which a software component may be subject are divided into first and second  types; the categorization of a change as first or second type is component dependent, being set in a 'change-type' policy associated with the component, but as a rule of thumb:
-        a change of the first type is one that requires the component to be restarted to re-establish its integrity; such a change is one made to the integrity critical part of the component, that is, to the code or other data of the component that has a potential impact on the ability of the component to implement its intended functionality correctly - for convenience such a change is referred below to as an "critical" change. An example of a critical change might be a kernel loading a new driver in its memory or an application loading a plug-in in its memory in a way that will affect its behaviour.
-        a change of the second type is a change that is not of the first type; such a change is one made to a non integrity-critical part of the component, that is to code or other data of the component that has no impact on the component's ability to implement its intended functionality  - a change of the second type is referred to below as a "non-critical" change. A particular example of a non-critical change might be a configuration or mode change,.
A software component for which such a classification of changes is made and used in determining the integrity of the component is referred to below as a "dynamic" component (because, as will be seen its trustworthiness may change any number of times) 
First Embodiment
A first embodiment of the invention will now be described with reference to Figures 7 and 8.  According to this embodiment, when a dynamic component 71 is created, a special type of trusted entity 75 is associated with it on a one-to-one basis (this special type of trusted entity is hereinafter called a "dynamic trusted entity" - or 'DTE' - to indicate that it is related to a dynamic component). 
The dynamic component 71 comprises, in addition to code providing the component's intended normal functionality F, a change-type policy element 72 for use in determining whether a change to the component is a trust-irrecoverable or trust recoverable change, and measurement agent(s) 73 for measuring changes to the component itself. An appropriate mechanism is provided for enabling the dynamic component to communicate with its associated DTE 75. Both the change-type policy 72 and the measuring agent 73, although shown as part of the dynamic component 71, can be separately disposed while remaining associated with the component 71.
As already indicated, the DTE 75 is a special type of trusted entity and will almost always be implemented as a virtual trusted entity running in a secure environment (for example, by running at an appropriate privilege level or in a separate partition). As indicated by box 76 in Figure 7, the DTE 75 has a persistent identity. The DTE 75 comprises both a static register 78 and a dynamic register 79 for holding integrity measurements made on the dynamic component 71; by 'register' is simply meant a memory location. An integrity measurement stored to the static register 78 is combined with the existing value held in the register, that is, the register value is extended (for example, in a manner similar to the way a prior-art PCR is extended); in contrast, an integrity measurement stored to the dynamic register 79 simply replaces the previous value held in that register.  The DTE 75 further comprises an integrity metrics manager 77 providing functionality for storing integrity measurements in the register 78, 79 and reliably reporting the register values. The DTE 75 may also hold the expected measurement values for the component 71.
When the dynamic component 71 is created, the creating entity acquires an integrity metric of at least those parts (code and other data) of the dynamic component 71 that have a potential impact on the ability of the dynamic component to implement its intended functionality correctly, and puts the value of this metric into the static register 78 of the DTE 75; the creating entity may also acquire an integrity metric of at least those parts (code and other data) of the dynamic component that have no impact on the component's ability to implement its intended functionality, and puts the value of this metric into the dynamic register 79 of the DTE 75. From then on, the static register 78 can only be updated by the component 71 itself (with the aid of the integrity metrics manager 77) whereas the dynamic register 79 can be updated (via the integrity metrics manager 77) both by the component  71 and the creating entity (assuming the latter has access to the policy 72 or has equivalent knowledge to be able to recognise a non-critical change).
The dynamic component 71 is entitled to measure and report changes to its structure. Thus when a change is determined (for example, by code set to detect any write operation to locations holding any part of the dynamic component), the dynamic component measures its effected part (that is, either its integrity-critical parts in the case of a critical change or the non integrity critical parts for non-critical changes. For a critical change, the resultant measurement is used to extend the value in the static register 79, effectively creating a permanent indication that a critical change has taken place; for a non-critical change, the new integrity measurement simply replaces the previous value held in the dynamic register 79.
Depending on the measurement values stored in both registers 78 and 79, the dynamic component 71 can be in one of three local integrity states: 
If the values in the static and dynamic registers 78, 79 are consistent with the expected measurement values, the integrity is 'intact' (the component itself is trustable). 
If the value in the static register 78 is consistent with the expected measurement value but the value in the dynamic register is not, the integrity is "recoverable". 
In all other cases, the integrity is "irrecoverable". 
The relations between these states is depicted in the state diagram of Figure 8.
The foregoing arrangement enables a dynamic component that has only been subject to non-critical changes to be restored to its trustable condition and have this reflected in its integrity metric values stored in the registers 78 and 79. Also, a user may be willing to trust a dynamic component which according to the expected register values known to the DTE 75 is in its recoverable state because the dynamic register matches an expected value known to the user and not the DTE.
Hierarchy of Components
The concept of having a dynamic component 71 with an associated DTE 75 is particularly powerful in the context of a hierarchy of such components, each preferably in its own isolated environment (such as a hypervisor partition) and capable of creating child components. As is illustrated in Figure 9, in this case, the dynamic component 71 launched by a parent component 70 advantageously comprises (in addition to policy 72 and measurement agent(s) 73):
1. A functionality group F that provides the necessary component functionality.
2. An execution environment ENV in which the functionality group executes.
3. A configuration group ф that defines the parameters for both 1) and 2).
Figure 10 shows a hierarchical arrangement of three dynamic components 71 (Ci-1, Ci, Ci+1) each with its own dynamic trusted entity 75 (DTEi-1, DTEi, DTEi+1). Each dynamic component Ci is created by its parent component Ci-1 along with the associated DTEi. During creation, each DTEi is given a persistent identity that also denotes the component's location in the hierarchy. As illustrated in Figure 10, the child component's execution environment ENVC is a subset of the parent's execution environment ENVP. Thus, each component Ci can only have one immediate ancestor (i.e., parent). The resulting dependency relation can be represented with a component tree that is rooted in the root-of-trust of the trusted platform concerned.
This dependency tree can be used to enforce dynamic access control policies attached to secrets of a dynamic component. These policies determine under what conditions a component is allowed to access its secrets held in protected storage provided by the associated DTE. The policies are enforced by the DTE. For example, the access control policies may allow a dynamic component access to its secrets if and only if the integrity of the component and of its ancestors is intact (this requires the DTE to obtain the integrity states of the ancestor components by making appropriate requests to its parent component and to enable this to happen each DTE 75 preferably knows the parent 70 of its associated dynamic component 71). 
Second Embodiment
A second embodiment of the invention will now be described with reference to Figure 10. Like the hierarchical form of the first embodiment described with respect to Figure 9, in the second embodiment dynamic components 71 are each associated with a respective dynamic trusted entity  DTE. The dynamic components 71 are organised hierarchically. In Figure 10, eight dynamic components 71 are shown, individually identified by the letters B to I, but only the DTE 75'E of the dynamic component 71E has been shown for reasons of clarity. The form of the DTE 75' differs from that described with respect to the first embodiment. In particular, in the second embodiment the static and dynamic registers associated with a dynamic component 71 are no longer provided as part of the corresponding DTE 75' but are disposed in protected storage 103 provided by a base component 102 that forms the root component A of the hierarchy 74B-74I; by way of example, Figure 10 shows in protected storage 103 the static and dynamic registers 78E and 79E associated with the dynamic component 71E. The base component 102 also holds the expected measurement values for each descendent dynamic component.
The base component 102, like the dynamic components71A-71I, preferably comprises a functionality group F, an execution environment ENV, and a configuration group ф, and in addition to providing protected storage for use by the units 74, provides cryptographic resources that previously were to be found in the integrity metrics manager of each DTE 75. The manager 77' of each DTE of Figure 10 now primarily serves as an interface to the base component 102. Dynamic components 71 use these interfaces to update their respective associated static and dynamic registers 78, 79 and to request access to other secrets stored in protected storage 103 on their behalf. The specifics of the access are controlled by a policy that is enforced by the base component 102.
In the present case, the base component 102 is part of the trusted computing base, TCB, 100 of the platform (the trusted computing base being the collection of entities, including the base component 102, that can potentially affect the trustworthiness of the platform). The trust chain of the platform extends from its roots of trust 101 (typically based on a hardware TPM)  to the base component 102 and then on through the hierarchy of dynamic components, to the extent that their respective states justify this.
In this embodiment, the current TCG methods are used to carry out integrity measurements for the TCB 100 whereas the static and dynamic registers 78, 79 are used in the manner described with respect to the first embodiment to track, on more fine-grained basis, the integrity of the dynamic components 71 outside the trusted computing base 100.
The base component 102 holds data detailing the structure of the tree of dependent components and the software to manage this tree. For simplicity, only a single base component 102 has been described, but the above-described arrangement can be generalized to multiple base components each with its own tree. Dynamic components 71 do not possess any information about the tree structure except the identity of their parent components (this information is held by the corresponding DTE).
As already indicated, knowledge of the tree's structure is used to enforce dynamic access control policies applying to the secrets of dynamic components. These policies determine under what conditions dynamic components are allowed to access their secrets. The policies are enforced by the base component 102. For example, integrity policies allow access to the secrets if and only if the integrity of the dynamic component and its ancestors is intact. This scheme results in a recursive integrity definition which is controlled by on-going measurements of each component image.
Security Services Management Framework (SSMF)
The above described architecture with a base component and dependent dynamic components is well suited to provide a security services management framework (SSMF) founded on the base component and manages the trust relations between security services provided (by dynamic components) to users. 
For example, an important service offered by the SSMF is the management of security credentials that are used by the dynamic components to perform security-critical operations requested by users. A popular practice is to couple each credential with an access policy and allow its usage if an only if certain security properties are met. To this end, the SSMF can be arranged to employ integrity policies to provide guarantees to users that component credentials will be accessed only if the relevant integrity is intact. This way, users can verify the correct operation of the security services and the platform before exchanging data with it. The SSMF orchestrates this and similar trust relations between the security services and users and provides the necessary trusted interfaces. A fuller description of the framework architecture is given below. 
As depicted in Figure 12, the SSMF 200 is made up of a core security service management (SSM) module 202, a credentials module 203 and an attestation module 204 that for remote service-level attestation. The SSMF is accessed through a security services management interface (SSMI) 201 that is both used by the security services components (for life-cycle management, credential management, and integrity reporting) and users (for remote attestation). In particular, the SSMI 201 allows services to use the SSMF to:
・        Create dynamic child service components within the parent's execution environment and manage their life-cycle;
・        Store their security credentials in protected storage;
・        Access their security credentials inline with the integrity policies coupled with each;
・        Report ongoing dynamic and static changes to their structure and configuration;
・        Report their integrity status on service-level;
The core SSM module 202 serves as the base component of the component hierarchy (c.f. Figure 11) and keeps track of the service (component) hierarchy and enables dynamic measurements. In particular, the main functions provided by the core  SSM module 202 are (1) the holding of data detailing the structure of the service components that are managed by the SSMF, (2) the provision of protected storage for measurements and credentials, and (3) the provision of service and reporting interfaces for dynamic service creation and integrity measurement, respectively. Each of these functions is further described below:
Service Hierarchy Manager (block 206). As already mentioned, the security services are provided by dynamic components. Each dynamic component is, as previously described, associated with a dynamic trusted entity (DTE) that holds a persistent identity; for the purposes of the SSMF, this identity that also serves to identify the service component associated with the DTE. Therefore, to keep track of the service hierarchy, the core SSM module 202 simply manages a data structure whose nodes are composed of the DTE identities. The resulting data structure is a tree similar to the one illustrated in Figure 11 in which each node is now a DTE representing the corresponding service component. These DTEs are the locators of service components in the service hierarchy and any operation on a service component is done through its corresponding DTE.
Protected Storage (block 207). The core SSM module 202 keeps track of both dynamic and static integrity measurements of the service components. Further, security credentials that are used by each service are handled and stored by the core SSM. Both types of information are sensitive data and the core SSM module 202 employs protected storage to store each piece of data for each component. The actual nature of this storage is implementation dependent. As an example, one can employ a trusted hardware module (TPM) to protect such information that is stored in ordinary storage as described above with reference to Figure 5.
Service and Reporting Manager (block 208). The service and reporting manager provides services and reporting interfaces. The service interface offers a single create() command using which services can create child services along with their DTEs. Similarly, the reporting interface is composed of a single report() request that can be used to report both static and dynamic changes to the requesting services.
With regard to credential management provided by the credentials module 202, it will be appreciated that services may employ security credentials in variety of ways. For example, a credential can be a symmetric cryptographic key that a service uses to sign data. In this case, the ability to possess or have access to the security credential may give the service user sufficient proof that the service can be trusted. Access policies can be used to define the conditions under which the services are allowed to access these credentials. If the underlying platform that enforces these policies can be trusted, users can deduce that the service can access to the credential if and only if the policy conditions are satisfied.
The credentials module 202 provides verifiable means to securely store, manage, and provide usage access to security credentials and provides guarantees that the management and usage of these credentials will be performed by trusted entities that can be verified by third-party users. Integrity policies are used to determine whether a service can have access to its security credential or not. An integrity policy states that a service can access to its security credential if and only if the integrity of the service, its ancestors, plus the integrity of the platform (i.e., the trusted computing base, TCB) are all intact. As an example, in Figure 11, the dynamic service component F can have access to its credential if and only if the integrity of F, C, B, and the TCB are intact. Note that, for example, the integrity of E has no effect on this particular decision.
Credential management involves two phases: registration and usage. The registration phase is a one time phase during which the credential is registered with the SSMF and sealed to the protected storage along with its access policy. To do so, a service component invokes a register() request of a  credential interface of the credentials module 203; this initiates a registration request for the input credential preferably encrypted with an asymmetric key. Upon successful registration, the credentials module 203 returns a ticket that can be used later by the requesting service component to request usage access to the sealed credential. Preferably, this ticket is a blob, returned by the protected storage sealing service.
In the usage phase, the service component gains usage access to its security credential by supplying the ticket to the credentials module 203 via the credential interface. The credentials module 203 first locates the service in the service hierarchy using the service's persistent DTE identity. Access to the credential is granted if and only if the ticket is valid and the access policy holds for the current service and platform configuration (e.g., the integrity of the service, its ancestors, and the TCB is intact). Usage access to the credential should not reveal any information on the nature of the credential to the requesting service component; this is because if a service obtains the possession of its security credential, the SSMF loses the ability to revoke the credential should the dynamic service component reports a static or a dynamic change through the reporting interface. Therefore operations (encryption, decryption) requiring use of the credential are performed inside the SSMF (for example by the credentials module 203). Accordingly credential usage requests from a service component to the credential interface of the credential module 203 take the form of an encrypt() or decrypt() request. 
With regard to the attestation module 204, this provides service-level attestation  to third-party users that would like verify the integrity of the service before exchanging data with it. The attestation protocol employed is similar to that described in the TCG specifications.  However, now, instead of running a full-scale platform attestation, the SSMF allows users to run a much finer-grained service integrity quote. This way, a user can request the cumulative integrity of any service component. The cumulative integrity of a service component is the combination of the local measurements of the service, its ancestors, and the underlying TCB.
Two example attestation protocols are described below, these protocols differing in respect of the entity (i.e., the user or the platform) employed to verify the integrity results Both protocols are initiated using the single attest() request (with the appropriate option) made to the attestation module.
First Example Attestation Protocol.  In this case a third-party user acts as the verifier of the integrity of the service of interest (i.e., has access to the expected values for all relevant components of the platform and of the TCB). The following assumes that the component C of the Figure 11 hierarchy is the component of interest.
1.        The third-party user uses the attestation interface provided by the attestation module 204 to check the integrity of service component C and request signed copies of all related current integrity measurements.
2.        The attestation module 204 locates C in the hierarchy using the identity of component C's DTE.
3.        The attestation module 204  returns to the third-party user the integrity of C, B, and the TCB (i.e., the register values) plus a signature that is composed of signed copies of the integrity measurements of  the components C, B and of the TCB, signed respectively by the attestation module 204 and by a platform trusted module TM:
2009015818.tif 000019
where
2009015818.tif 000020
indicates signature by the suffixed entity and I indicates the integrity measurement made in respect of the suffixed element.
4.        Upon receiving the measurements and verifying the signatures, the third-party user compares the current register values for the TCB and the components B, C with the expected ones and decides whether to trust C or not. 
Second Example Attestation Protocol.  In this case, the verifier is the platform and the third-party user either receives a trusted answer with a proof or a single not-trusted answer. The first two steps of the protocol are the same as above. In the third step, instead of returning the integrity measurements, the framework compares the current and the expected values. For example, for service component C, it returns a trusted answer after comparing the static and dynamic measurements of both C and B to the expected values. Along with the answer, the framework returns the integrity of the TCB and the signature 
2009015818.tif 000021
as the proof. This is because, for this example, the third-party user still needs to verify that the answer is generated by a trusted platform. 
It will be appreciated that the described embodiments of the invention enables dynamic components to re-establish trust without requiring a complete restart under certain conditions. This is particularly advantageous for systems with components that change frequently and operate in various security modes. On-going monitoring and reporting allow components to reflect the latest system state. This provides up-to-date information about the system in contrast to current implementations that measure the components once during booting. 
Furthermore, because integrity measurements are stored in software registers, the described embodiments are  more scalable than current arrangements that require hardware registers to store the complete set of integrity measurements.
The described hierarchical integrity management scheme (i.e., tree-of-trust) is more suitable for complex systems than current  solutions that offer linear models (i.e., chain-of-trust). If the necessary isolation properties are guaranteed, the hierarchical approach provides a finer-grained integrity management solution that allows:
Better representation: The hierarchical approach enables components with no dependency relation to each other to build separate integrity chains. Thus, the integrity of a component only involves the integrity of itself plus its ancestors. 
Isolation: Changes to components are isolated only to the appropriate branch of the integrity chain, thus do not affect the complete platform. As a result, a critical change will no longer require restarting and re-measuring the complete platform but only the appropriate branch. 
It will be appreciated that many variants are possible to the above described embodiments of the invention. In particular, the skilled person will appreciate that the present invention does not rely for its operation on use of a trusted platform technology of the particular form described above with reference to Figures 1 to 6 or as described in the TCG Specifications.
Different change classifications may be used to those described above. 
It is to be noted that a component is any platform entity that can change the trust state of a platform through execution. There are no restrictions on the specifics of a platform component. As an example, a component can be a service residing in a virtual domain (partition); alternatively, a component can be the virtual domain itself. Hence, the exact granularity in defining platform components depends on the granularity of integrity management we require on the platform.
Advantageously different granularities of integrity management can be used together. For example, two levels of trust management with different component granularity can be employed on the same platform. Thus the above-described SSMF can be applied both:
in a local context, in which a local SSMF is used to manage the security services that reside in a single virtual machine (established in its own virtual domain or partition) - in the case of multiple virtual domains, each domain contains a local SSMF implementation that works independently of local SSMFs in other domains); 
in the global context, in which a global SSMF is used to manage a hierarchy of virtual machines each in its own virtual domain. Note that in this case the dependency between virtual machines is not an implicit one but is stated explicitly (i.e., there is no implicit ancestry relation between VMs due to execution order). For example, if one of the virtual machines serves as a management machine that is responsible for managing the rest of the virtual machines, there is an explicit dependency in which the management virtual machine assumes the role of the parent for the remaining child virtual machines. setting.
Figure 13 illustrates the combined use of global and local SSMFs for a host 300 running a secure hypervisor 301 to provide multiple virtual domains (named "Dom 0" to "Dom X") 302 -309. A global SSMF 332 runs as a trusted application in Dom0 and serves to manage a hierarchy of virtual machines each in its own virtual domain. Communication between the global SSMF 332 and the virtual machines that it manages is through an inter-domain communication arrangement 320. Each of the domains 303 to 309 has its own local SSMF 333 to 339 respectively. 
CLAIMS
1.  A method of tracking the state of a software component in use on a computing platform, the method comprising:
upon a change of a first type in the software component, reliably measuring and recording an appropriate integrity metric of the software component in cumulative combination with any previous integrity metric values recorded for changes of said first type to the software component; and 
upon a change of a second type in the software component, reliably measuring and recording an appropriate integrity metric of the software component as a replacement for any previous integrity metric value recorded for changes of said second type to the software component.
2.  A method according to claim 1, wherein
a change of said first type is one made to the integrity critical part of the component, that is, to code or other data of the component that has a potential impact on the ability of the component to implement its intended functionality; and
a change of said second type is one made to a non integrity-critical part of the component, that is to code or other data of the component that has substantially no impact on the component's ability to implement its intended functionality.  
3.  A method according to claim 2, wherein 
the integrity metric measured as a result of  a change of said first type is measured over at least the integrity critical part of the software component; and 
the integrity metric measured as a result of change of said second type is measured over at least the non integrity-critical part of the software component.
4.  A method according to claim 1, wherein the software component comprises:
a functionality group that provides the necessary component functionality; and
an execution environment in which the functionality group executes.
5.  A method according to claim 1, wherein the integrity metric measured as a result of  a change of said first type is recorded to a first register and the integrity metric measured as a result of change of said second type is recorded to a second register, the first and second registers being logically part of a trusted entity associated with the software component.
6.  A method according to claim 5, applied to each of a plurality of software components arranged hierarchically with each software component that is a child in the hierarchy running in the  execution environment of its parent software component in the hierarchy, the state of each software component of the hierarchy being separately tracked with each component having a respective associated pair of first and second registers.
7.  A method according to claim 6, wherein the platform provides a trusted base component common to all said software components, the pair of first and second registers associated with each software component being maintained by the trusted base component.
8.  A method according to claim 7, wherein the base component forms the root of said hierarchy. 
9.  A method according to claim 8, wherein the base component provides an execution environment for said hierarchy.
10.  A method according claim 7, wherein the base component is part of a trusted computing base of the platform.
11.  A method according to claim 1, further comprising preventing use of confidential data associated with a said software component unless:
the current cumulative value arising from integrity metrics recorded for changes of said first type, and 
the integrity metric value last recorded for changes of said second type, 
both match respective expected values.
12.  A method according to claim 1, applied to each of a plurality of software components arranged in a hierarchy rooted in a trusted base component of the platform; wherein the integrity metrics measured as a result of  changes of said first and second types are stored in secure locations maintained by the trusted base component; the method further comprising preventing use of confidential data associated with a said software component unless the integrity metrics of that component and of its ancestors in said hierarchy, all match respective expected values.
13.  A method according to claim 1, wherein the software component is a domain established by a hypervisor executing on the platform.
14.  A method according to claim 1, wherein the software component is a component running in domain established by a hypervisor executing on the platform.
15.  A computing platform including a monitoring arrangement for tracking the state of a software component in use on the computing platform, the monitoring arrangement comprising:
change responsive means for detecting and distinguishing first and second types of changes to the software component;
first and second memory registers;
first measuring means responsive to detection of a change of the first type in the software component, to reliably measure an appropriate integrity metric of the software component;
first recording means for recording the integrity metric measured by the first measuring means in the first register in cumulative combination with any previous integrity metric values recorded in the first register for changes of said first type to the software component;
second measuring means responsive to detection of a change of the second type in the software component, to reliably measure an appropriate integrity metric of the software component;
second recording means for recording the integrity metric measured by the second measuring means in the second register as a replacement for any previous integrity metric values recorded in the second register for changes of said second type to the software component.
16.  A computing platform according to claim 15, wherein: 
a change of said first type is one made to the integrity critical part of the component, that is, to code or other data of the component that has a potential impact on the ability of the component to implement its intended functionality; and
a change of said second type is one made to a non integrity-critical part of the component, that is to code or other data of the component that has substantially no impact on the component's ability to implement its intended functionality.  
17.  A computing platform according to claim 16, wherein 
the integrity metric measured as a result of  a change of said first type is measured over at least the integrity critical part of the software component; and 
the integrity metric measured as a result of change of said second type is measured over at least the non integrity-critical part of the software component.
18.  A computing platform according to claim 15, wherein the software component comprises:
a functionality group that provides the necessary component functionality; and
an execution environment in which the functionality group executes.
19.  A computing platform according to  claims 15, wherein the first and second registers are logically part of a trusted entity associated with the software component.
20.  A computing platform according to claim 19, including a plurality of software components arranged hierarchically with each software component that is a child in the hierarchy running in the  execution environment of its parent software component in the hierarchy, the state of each software component of the hierarchy  being separately tracked  with each component having respective associated first and second registers and respective first and second measuring and recording means.
21.  A computing platform according to claim 20, wherein the platform further includes a trusted base component common to all said software components, the pair of first and second registers (78, 79) associated with each software component being maintained by the trusted base component.
22.  A computing platform according to claim 20, wherein the base component forms the root of said hierarchy. 
23.  A computing platform according to claim 22, wherein the base component provides an execution environment for said hierarchy.
24.  A computing platform according to claim 19, wherein the base component is part of a trusted computing base of the platform.
25.  A computing platform according to 15, further including an access control arrangement for preventing use of confidential data associated with a said software component unless:
the current cumulative value arising from integrity metrics recorded for changes of said first type, and 
the integrity metric value last recorded for changes of said second type,
both match respective expected values
26.  A computing platform according to claim 15, including a plurality of software components arranged in a hierarchy rooted in a trusted base component of the platform; each software component having respective first and second registers and respective first and second measuring means;  the first and second registers comprising secure locations maintained by the trusted base component; and the computing platform further including an access control arrangement for preventing use of confidential data associated with a said software component unless the integrity metrics of that component and of its ancestors in said hierarchy, all match respective expected values.
ABSTRACT OF THE DISCLOSURE
A method and apparatus are provided for tracking the state of a software component  in use on a computing platform.  Upon a change of a first type in the software component (such as a change to an integrity-critical part of the component), an appropriate integrity metric of the software component is reliably measured and recorded in cumulative combination with any previous integrity metric values recorded for changes of the first type to the software component. Upon a change of a second type in the software component (such as a change to a non integrity-critical part of the component), an appropriate integrity metric of the software component is reliably measured and recorded as a replacement for any previous integrity metric value recorded for changes of  the second type to the software component. The two resultant values provide an indication of the integrity state of the software component.
2009015818.tif 000022
2009015818.tif 000023
2009015818.tif 000024
2009015818.tif 000025
2009015818.tif 000026
2009015818.tif 000027
2009015818.tif 000028
2009015818.tif 000029
2009015818.tif 000030
2009015818.tif 000031
2009015818.tif 000032
2009015818.tif 000033
2009015818.tif 000034