JP5038396B2

JP5038396B2 - トラステッドコンピューティングの完全性測定の通知を実行する装置および方法

Info

Publication number: JP5038396B2
Application number: JP2009506616A
Authority: JP
Inventors: モバ、サシダー; ハーシャフト、リチャード、ディー．; ラチャ、レヌカ; チャ、インヨク
Original assignee: インターデイジタルテクノロジーコーポレーション
Priority date: 2006-04-21
Filing date: 2007-04-23
Publication date: 2012-10-03
Anticipated expiration: 2027-04-23
Also published as: CN101473329B; KR101041543B1; CN101473329A; WO2007124091A1; JP2009534749A; KR20080112404A; KR20090006876A; EP2013808A1; ES2664413T3; US20090307487A1; EP2013808B1; US8566606B2

Description

本発明は、複数のプラットフォーム（即ちサブシステム）間のトラステッドコンピューティング（即ちコンピュータセキュリティ）に関する。特に、本発明は、トラステッドコンピューティングの完全性測定の通知を実行する装置および方法に関する。

プラットフォーム構成レジスタ（ＰｌａｔｆｏｒｍＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｇｉｓｔｅｒｓ：ＰＣＲｓ）は、データのハッシュを格納するために使用するトラステッド・プラットフォーム・モジュール（ｔｒｕｓｔｅｄｐｌａｔｆｏｒｍｍｏｄｕｌｅ：ＴＰＭ）内の記憶域である。前記ＰＣＲに使用されるＴＰＭメモリは、本来揮発性でもよく、不揮発性でもよい。

従来のトラステッド・コンピューティング・グループ（ＴｒｕｓｔｅｄＣｏｍｐｕｔｉｎｇＧｒｏｕｐ：ＴＣＧ）規格は、前記ＴＰＭによって前記ＰＣＲ上で実行される読み出し、拡張、および引用動作を可能とする。前記読み出し動作は、所定のＰＣＲの値を読み出すために使用される。前記拡張動作は、その古い内容を新しい内容で拡張することによって前記ＰＣＲの値を修正するために使用される。これによって、最終的なＰＣＲダイジェストがどのように構築されたかを呼掛器が知ることができる。前記引用動作は、構成証明アイデンティティ鍵（ａｔｔｅｓｔａｔｉｏｎｉｄｅｎｔｉｆｉｃａｔｉｏｎｋｅｙ：ＡＩＫ）を使用して、前記ＰＣＲの値が前記ＴＰＭによって暗号化される、完全性通知に使用される。この状況における構成証明とは、そのシステムの信頼性の程度をこのような情報の内部または外部呼掛器、またはリクエスタに供給するための前記プラットフォームの作業をいう。プラットフォームの現在の構成を決定するために、完全性通知を使用することができる。

ハッシュされた一片のコードまたはデータの完全性の検証のために後に使用する完全性基準を生成する動作を前記ＴＰＭが実行するとき、前記ＴＰＭは、ただ単にその目的のデータまたはコードの最新の値のハッシュを計算し、その値をＰＣＲに入力するのではない。その代わりに、前記ＴＰＭは、前記ＰＣＲの現在存在する値にシステムの構成要素の新たに測定されるべき値を繋げ、その繋がったデータにセキュア・ハッシュ・アルゴリズム（ｓｅｃｕｒｅｈａｓｈａｌｇｏｒｉｔｈｍ：ＳＨＡ）を実行することによって拡張動作を実行し、その結果を前記目標ＰＣＲに入力する。

ＰＣＲが拡張される度に、前記ＴＣＧのイベントログへのログ入力もまた行われる。ＴＣＧイベントログは格納測定ログ（ｓｔｏｒｅｄｍｅａｓｕｒｅｍｅｎｔｌｏｇ：ＳＭＬ）とも呼ばれ、ＴＰＭが設置されたプラットフォーム上で生じるイベントのログである。ＳＭＬは、ＴＰＭを含むシステムプラットフォーム内の構成要素（例えば一片のコード）の測定値のログである。前記ＴＰＭは、前記ＴＰＭが設置されたプラットフォーム内で生じるイベント（特定のアプリケーションソフトウェア（ｓｏｆｔｗａｒｅ：ＳＷ）の読み込み工程など）の測定を実行する。前記プラットフォームのオペレーティングシステム（ｏｐｅｒａｔｉｎｇｓｙｓｔｅｍ：ＯＳ）の要求に従って、前記ＴＰＭを制御する前記ＯＳの信頼できる部分である測定カーネルが測定イベントを生成する。「測定イベント」とは前記プラットフォーム自体の中で生じるイベントではなく、むしろ前記プラットフォーム内で生じるイベントに関して実行される「測定」の作業またはイベントを示す用語であることに留意されたい。このようなプラットフォームのイベントの例として、一片のソフトウェアのコードのシステムメモリ内への読み込み工程が挙げられるであろう。測定イベントは、１）測定値−埋め込まれたデータまたはプログラムのコードの表示、２）測定ダイジェスト−それら値のＳＨＡハッシュ、の２種類のデータからなる。前記ＴＰＭによってデータをスキャンすることでメッセージダイジェストが生成される。ダイジェストはその機械の動作状態のスナップショットである。前記２つのデータ要素（測定値および測定ダイジェスト）は別個に格納される。前記測定ダイジェストは前記ＴＰＭ内のＰＣＲ内に格納される。前記測定値は、事実上任意の場所に格納でき、一般的にはＳＭＬに格納されるが、暗号化された形式で格納しなければならない。実際には、前記測定値を全く格納せず、前記直列化された表示が必要な度に再計算してもよい。測定データは前記測定要素の特性および特徴を表す。前記ＳＭＬは関連した測定値の数列を含む。各数列は共通の測定ダイジェストを共有する。測定値は前記共通の測定ダイジェストに付加され、再ハッシュされる。これは、より一般的には前記ダイジェストの拡張工程として参照される。拡張工程によって、関連した測定値が無視されないことが保証され、動作の順番が保たれる。

代数的に、任意の時点ｔ＋１におけるｎ番目のＰＣＲに対する更新は、方程式（１）に従う。
ＰＣＲ［ｎ］（ｔ＋１）＝ＳＨＡ−１（ＰＣＲ［ｎ］（ｔ）＋測定データ（ｔ＋１））方程式（１）
ＰＣＲ値は一時的であり、システムの再起動時にリセットされる。測定イベントの検証は、前記測定ダイジェストの再生成および前記ダイジェスト値の（コンパレータの１つとして前記ＰＣＲ値を使用した）単純比較を必要とする。ＴＣＧはＳＭＬの内容に関するデータ符号化の規則を定めていないが、拡張マーク付け言語（ＥｘｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ：ＸＭＬ）のような適切な標準に従って広範なアクセス性を保証することを推奨している。

図１は、呼掛器１０５と、プラットフォームエージェント１１０と、ＴＰＭ１１５と、リポジトリ１２０とを含むシステム１００によって実施された従来のＴＣＧ構成証明手順（即ちプロトコル）を示す。

前記呼掛器１０５は、前記プラットフォームエージェント１１０に１若しくはそれ以上のＰＣＲ値を要求する（工程１２５）。前記プラットフォームエージェント１１０は、完全性測定値であるＳＭＬ入力を収集する（工程１３０）。前記プラットフォームエージェント１１０が、前記ＴＰＭにＰＣＲを要求する（工程１３５）。前記ＰＣＲ値は、前記完全性測定値の測定ダイジェスト（即ち、前記完全性測定値の署名付きハッシュ）である。前記ＴＰＭ１１５は、ＡＩＫを使用して前記ＰＣＲ値に署名し（工程１４０）、前記プラットフォームエージェント１１０に前記署名付きＰＣＲ値を送信する（工程１４５）。また、前記プラットフォームエージェント１１０は、前記リポジトリ１２０から前記ＴＰＭ１１５を保証する証明書も収集する（工程１５０、１５５）。前記プラットフォームエージェント１１０は、前記呼掛器１０５に、前記署名付きＰＣＲ値、前記ＳＭＬ入力、および前記証明書を送信する（工程１６０）。次に、前記呼掛器１０５は、前記プラットフォーム構成を検証する（工程１６５）。前記検証のために、前記呼掛器１０５は、受信した前記ＳＭＬ入力から測定ダイジェストを計算し、計算された前記測定ダイジェストを前記ＰＣＲ値と比較する。また、前記呼掛器１０５は、前記プラットフォーム証明書を評価し、署名を確認する。

新たに測定が行われる度に前記ＰＣＲ値が拡張され、この情報が前記ＴＰＭ１１５によって記録される。この拡張工程によって、測定の順序が保たれ、全ての測定値が考慮される。前記ＰＣＲ値の拡張に関連した課題の１つは、任意の測定が実行されたときにプラットフォームの状態が変化し、現在のアプリケーションに関連のないアプリケーションが前記ＰＣＲを拡張する場合に前記システムの状態が正確ではないかもしれないことである。

現在、前記起動処理のために確保されたＰＣＲ以外には、アプリケーションに対するＰＣＲの標準化された割当てはない。これにより１より多くのアプリケーションが同一のＰＣＲを使用している状況を引き起こす可能性があり、これは下記に概述する理由で問題となる。

例えば、信頼できるデジタル著作権管理（ｄｉｇｉｔａｌｒｉｇｈｔｓｍａｎａｇｅｍｅｎｔ：ＤＲＭ）アプリケーションの前に信頼できるブラウザーアプリケーションが読み込まれた場合、両方のアプリケーションが同一のＰＣＲを使用すると、前記ＤＲＭアプリケーションが必要とするシステム状態が予期される状態と一致しない可能性がある。これによって、前記システムの状態が本来あるべき状態でないために、前記アプリケーションの読み込みが失敗する可能性がある。前記ＤＲＭアプリケーション用の呼掛器もまた、前記ブラウザーが実行中であるという情報を得る。これによって、その使用者のプライバシーが侵される。

例えば、図２は、第１の呼掛器２０５と、第２の呼掛器２１０と、プラットフォームエージェント２２０およびＴＰＭ２２５を含むユーザー装置２１５とを含むシステム２００によって実施された、異なるアプリケーションが、相互の拡張動作について知らずに異なる状態からＰＣＲを拡張する、従来のＴＣＧ手順を示す。前記第１の呼掛器２０５が、前記第２の呼掛器２１０の要求したそれと同じＰＣＲ値の変更を要求すると、前記第２の呼掛器２１０によるプラットフォーム構成の検証は、前記プラットフォームの構成が有効であっても失敗することになる。

図２を参照して、前記第１の呼掛器２０５が前記プラットフォームエージェント２２０に前記プラットフォーム構成の要求を送信し（工程２３０）、次に前記プラットフォームエージェント２２０が常駐の前記ＴＰＭ２２５上のＰＣＲを拡張し（工程２３５）、次に前記ＴＰＭ２２５に前記ＰＣＲの署名付き値を要求し（工程２４０）、前記ＴＰＭ２２５が前記プラットフォームエージェント２２０に（前記ＴＰＭ２２５がＡＩＫを用いて署名した）署名付きＰＣＲ値を返信する（工程２４５）。次に、前記第１の呼掛器２０５が前記プラットフォームエージェント２２０から前記プラットフォーム構成を受信する（工程２５０）。この処理（工程２５０）において、通常、前記第１の呼掛器２０５はまた、前記署名付きＰＣＲ値およびＳＭＬ入力（図２にはどちらも図示せず）も受信し、受信した前記プラットフォーム構成データ、前記署名付きＰＣＲ値、および前記ＳＭＬ入力を使用して前記プラットフォーム構成を検証する（工程２５５）ことに留意されたい。

一方、前記第２の呼掛器２１０は、前記プラットフォームエージェント２２０に前記プラットフォーム構成を要求し（工程２６０）、次にこれを受信する（工程２８０）ことができ、このプラットフォームエージェント２２０は、前記ＴＰＭ２２５内の同一のＰＣＲを拡張し（工程２６５）、前記ＴＰＭ２２５から前記ＰＣＲの署名付き値を要求し（工程２７０）、次に受信する（工程２７５）。次に、前記第２の呼掛器２１０は、受信した前記プラットフォーム構成を検証できる（工程２８５）。前記第１の呼掛器２０５および前記第２の呼掛器２１０は相互について知らない可能性があり、現行のＴＣＧ規格は、異なる呼掛器について適切かつ有用な測定ダイジェストを安全かつ個人情報を保護できる方法で記録するために、どのＰＣＲが使用できるかを割り当てる系統的な方法を指定していないので、同一のＰＣＲを使用してこれら関連性のない呼掛器の両方についての測定ダイジェストを記録する可能性がある。これによって、前記第１の呼掛器２０５のための測定値によって拡張されたＰＣＲ値が提示するシステム状態について、前記第２の呼掛器２１０が必ずしも知らないという問題が発生する。このように、前記第２の呼掛器２１０の観点から、第１の呼掛器２０５の測定および検証のために同一のＰＣＲが拡張されているという事実を既に追跡していない限り、前記第２の呼掛器２１０は自らによる前記ＰＣＲの検証の前に実行された前記ＰＣＲの拡張の順序を再生成するために必要な前記ＳＭＬの全てを受信しない可能性があるため、前記第２の呼掛器２１０は、その検証処理において誤ったデータのセットを比較するかもしれない。もしくは、前記ＰＣＲ拡張を何度も繰り返した後では、このようなＳＭＬは大きくなり過ぎかねないので、前記第２の呼掛器２１０は、以前のＳＭＬ入力の全てを処理して前記ＰＣＲの直近の状態を再生成する処理能力が単純に不足するかもしれない。

また、図２のＴＣＧ手順は、一方の呼掛器には開示できて他方には開示できない個人情報のリークを生成する可能性もある。また、現行の手順は、前記呼掛器の側で、保証されていない（検証が発生すべきではないときの）検証を生じさせ、または、意図しない（検証すべきときの）非検証という決定を生じさせる可能性がある。現在、この問題は以下の１若しくはそれ以上の方法を使用することによって対処されている。

ＰＣＲの指定：前記ＰＣＲを使用して前記システムの状態が提示されている時、一定のＰＣＲを一定のアプリケーションに割り当てることができる。この方法の不利な点は、一般的に前記ＴＰＭ内のＰＣＲの数は、そのコストおよびサイズの配慮から１６個程度である（ＴＣＧ標準はＰＣＲの数を制限していない）。このために、全ての種類のアプリケーションに固定ＰＣＲを割り当てる能力には限界がある。

ＰＣＲイベントログの使用：前記ＰＣＲ値に対する変更の全てが前記ＴＰＭによって記録される。このログが前記ＰＣＲ値と共に使用され、前記システムが正しい状態にあるかを確かめることができる。しかし、この方法の問題は、前記ログが問題のアプリケーションに直接関係のない情報を含んでいるかも知れず、従って使用者のプライバシーを侵害する恐れがある。

起動時に、所定の順序で全てのアプリケーションを読み込むことでもこの問題を排除できる。しかし、起動時に全てのアプリケーションを検証して読み込まなければならないので、その起動時間が長くなり、この方法は実用的ではない。

これらの方法には、信頼できるプラットフォームの機能を制限する観点から、または使用者のプライバシーの喪失の観点から重大な限界がある。

本発明は、複数のサブシステムの完全性測定のためにＴＰＭを使用する方法および装置に関する。起動後のＰＣＲの状態がそのシステムの基本状態として格納される。この状況における基本状態が、前記システムの起動が完了したときの前記システムの状態として定義され、そのカーネルレベルにおいて新しいソフトウェア読み込まれるときにのみ変更できる。この状態自体は、そのオペレーティングシステム（ｏｐｅｒａｔｉｎｇｓｙｓｔｅｍ：ＯＳ）の完全性の検証に関心のある呼掛器に通知される可能性がある。

本発明の別の実施形態において、保護された外部メモリ上の暗号化された記憶域を使用することによって、従来のＴＰＭが物理的ＰＣＲに提供するそれよりも大きなメモリ空間を使用する仮想ＰＣＲが使用される。

本発明のさらに別の実施形態において、検証されるべきアプリケーションが、その状態を前記システムの基本状態から拡張することを要求する。このような要求を受信すると、前記システムの状態は、前記システム状態からではなく、前記基本状態ＰＣＲの内容から直接拡張される。

さらに、システム状態の測定および検証のための参照開始点として機能する前記基本状態に関するステートメントがシステムに供給され、参照基本状態証明書の形式で格納される。測定が実行され、前記システムの状態の測定結果（一般的にはダイジェストの形式として）がこのような証明書に記述された前記基本状態の値と比較され、前記生の測定ダイジェスト値の代わりにステートメントが物理的ＰＣＲまたは仮想ＰＣＲに拡張される。

図３および図４は、本発明の基本状態に対してＰＣＲが検索される信号図を示す。

図３は、第１の呼掛器３０５と、第２の呼掛器３１０と、プラットフォームエージェント３２０およびＴＰＭ３２５を含むユーザー装置３１５とを含むシステム３００によって実施されることで、共通基本状態からの状態拡張が使用されるＴＣＧ手順を示す。図３を参照して、前記第１の呼掛器３０５が前記プラットフォームエージェント３２０に、基本状態から計算した前記プラットフォーム構成を要求し（工程３３０）、次に、前記プラットフォームエージェント３２０がＴＰＭ３２５上のＰＣＲを前記基本状態から拡張し（工程３３５）、次に前記ＴＰＭ３２５に前記ＰＣＲの署名付き値を要求し（工程３４０）、前記ＴＰＭ３２５が前記プラットフォームエージェント３２０に前記署名付きＰＣＲ値を返信する（工程３４５）。次に、前記第１の呼掛器３０５が前記プラットフォームエージェント３２０から前記プラットフォーム構成を受信する（工程３５０）。次に、前記第１の呼掛器３０５が、工程３５０で受信した前記プラットフォーム構成データをそれ自身が計算する値と比較し、前記プラットフォーム構成を検証する（工程３５５）。

一方、前記第２の呼掛器３１０は、前記工程３３５において使用され、しかしその後前記第２の呼掛器３１０およびその検証目標および目的に適した異なる測定値で拡張された、前記基本状態の同一の値から再度計算された前記プラットフォーム構成を後に要求し（工程３６０）、次に受信する（工程３８０）ことができる。このように、前記第２の呼掛器３１０による要求に応じて、前記プラットフォームエージェント３２０は、次に、それの前の値ではなく、再度工程３３５において使用した同じ基本状態からの同一のＰＣＲを拡張することになる（工程３６５）。次に、前記プラットフォームエージェント３２０は、前記ＴＰＭ３２５から、前記ＰＣＲの署名付き（ＡＩＫを用いて前記ＴＰＭ３２５によって署名付き）値を要求し（工程３７０）、受信する（工程３７５）。次に、前記第２の呼掛器３１０は、受信した前記プラットフォーム構成を検証する（工程３８５）ことができる。前記第１の呼掛器３０５および前記第２の呼掛器３１０は共に、前記基本状態から各々独自の測定値を用いて独立して計算された各々のプラットフォーム構成データを受信するため、図３において説明した手順は、図２の従来の手順において説明した問題を回避できる。

図４は、従来技術を、異なる呼掛器について異なる拡張状態が実施される本発明と比較する。図４に示すように、起動４０５を完了し、基本状態４１０に達しているシステムが描かれている。従来技術において、呼掛器によって第１のアプリケーションが読み込まれ、次に検証されるとき、前記システム状態４１５は、前記第１のアプリケーションの読み込み工程を反映するように変更される。次に、別の呼掛器によって第２のアプリケーション４２５が読み込まれ、検証される必要があるとき、前記システム状態４２０は、今度は前記基本状態４１０からではなく、前記システム状態４１５からの変更を反映する。

本発明によれば、異なる呼掛器に割り当てられたＰＣＲ（または仮想ＰＣＲ）は全て前記基本状態から拡張され、全ての呼掛器は、検証する必要のある特定の前記アプリケーションの読み込み工程の正味効果のみによって各々のターゲットの状態を検証することとなる。このような２つの呼掛器１および２がこの例に描かれ、これらは共に、前記基本状態４１０から独立して拡張されて、各々の派生ターゲット状態（呼掛器１では派生状態４２５であり、呼掛器２では派生状態４３０である）を検証することとなる。

本発明の第１の実施形態によれば、前記システムの再起動時に前記ＴＰＭが前記ＰＣＲ値を各々の初期値にリセットする。ここで参照するシステムは、パーソナルコンピュータ（ｐｅｒｓｏｎａｌｃｏｍｐｕｔｅｒ：ＰＣ）、携帯型情報端末（ｐｅｒｓｏｎａｌｄａｔａａｓｓｉｓｔａｎｔ：ＰＤＡ）、埋め込みシステム、携帯電話、埋め込みシステムを伴う周辺装置、ネットワーク要素、およびＴＣＧ技術、具体的には、ＴＰＭまたは等価物の使用によって実行可能となる、またはそれを実行可能とする機能およびサービスを備えたその他のプラットフォームなどの、任意のプラットフォームである。前記ＰＣＲ値は、前記ＴＰＭの既知の基本状態に対して通知される。前記ＴＰＭのこの基本状態は、好ましくは前記ＴＰＭ内に格納され、新しいアプリケーションを測定しなければならない度に使用できる。前記システムの起動処理が完了しているとき、前記ＴＰＭの基本状態は、前記プラットフォーム状態を提示し、この基本状態に対して各アプリケーションの状態が計算される。

ＴＰＭの基本状態はシステムの基本状態とは異なる概念である。本発明によれば、現行のＴＰＭの追加機能は、それらが起動時に全てのＰＣＲ値をリセットせず、その代わりに「成功した起動直後の前記ＴＰＭの状態」を「前記ＴＰＭの基本状態」として提示できる一定の値を有し、そのような値を前記ＴＰＭ自体の内部のシールドされた不揮発性メモリ内に格納するよう定義される。このような不揮発性メモリは、ここでも、起動直後にリセットする前記ＰＣＲとは異なることに留意されたい。前記ＴＰＭの基本状態は前記ＴＰＭを収容するシステムの成功した起動直後の前記ＴＰＭの状態を提示する値であるので、そのような基本状態は、前記システム自体の「真新しい」状態を間接的に提示できる。さらに、このようなＴＰＭ基本状態は不揮発であり、起動直後に回復でき、前記ＰＣＲの拡張動作のための基本状態として機能する。前記ＴＰＭ内部に前記基本状態を格納するためには、追加のシールドされた（即ち保護された）不揮発性メモリが必要であり、また、現行状態を前記システムの基本状態から計算しなければならないことを示すためには、伝送制御プロトコル・ソフトウェア・スタック（ｔｒａｎｓｍｉｓｓｉｏｎｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ：ＴＣＰ，ｓｏｆｔｗａｒｅｓｔａｃｋ：ＴＳＳ）からの指示が必要である。

ＴＳＳは、前記ＴＰＭの外部で、しかし前記プラットフォーム自体（前記プラットフォームのＯＳなど）またはそのエージェント（即ち図３内のプラットフォームエージェント３２０）の内部またはその制御下で行われる完全性測定および通知、ならびに検証のためのこのような手順（例えば、図３に描かれた工程３３０、３３５、３４０、３４５、および３５０）の始動および制御を可能とするソフトウェアスタックである。

前記第１の実施形態によれば、ＴＰＭ基本状態は前記ＴＰＭ自体内に安全に格納され、起動直後にＴＳＳを通じて前記ＴＰＭの外部、即ち、前記プラットフォームエージェントまたは前記プラットフォームＯＳに知らされるので、前記呼掛器がこのような「ＴＰＭ基本状態」を、前記呼掛器による検証の必要な前記アプリケーションの完全性測定を構築できる参照基本状態として使用することができる。前記ＴＰＭ内には、一定量のメモリ容量（前記ＴＰＭが収容するＰＣＲの数に等しい）のみが必要である。前記システムによって新しいアプリケーションが読み込まれる度に、この既知の基本状態が使用されることで、前記完全性測定が意図された通りに機能することが可能となる。例えば、前記ＴＰＭがＸ個のＰＣＲを有するとき、Ｘ個の「ＴＰＭ基本状態」もまた、前記Ｘ個のＰＣＲの各々について各々１個存在する。格納された前記ＴＰＭ基本状態は、読み込まれた特定のアプリケーションの完全性を測定するために割り当てられた前記ＰＣＲの各々を拡張するために使用される。従って、最大でＸ個の異なるアプリケーションの読み込み工程の完全性が、このようにして追跡され、測定される。

本発明の前記第２の実施形態によれば、システムが有することのできるＰＣＲの数に一定サイズの制約が存在しない。しかし、殆どの実施において実際的なＰＣＲの数は約１６個である。ＰＣＲ識別番号（ＰＣＲのアドレスは０〜２^３２−１の範囲であることができ、２^３０を超える値は将来用途に保存されている）の観点から、その拡張性は、前記ＴＰＭ上に物理的に存在せずに本来仮想である仮想ＰＣＲの概念を生成するために使用できる。これら仮想ＰＣＲの内容は、外部記憶装置または前記ＴＰＭ自体に暗号化されたデータとして格納できる。これら仮想ＰＣＲ値の内容は、他のＰＣＲ値からのみ拡張できる。これによって、前記ＰＣＲ値を拡張できるものに基づいて、アプリケーションが基本状態を定義することが可能となる。完全性測定を実行するために使用できる仮想ＰＣＲ番号が、各アプリケーションに与えられることが好ましい。これによって、周知のインターネットアプリケーションに対するポート番号の割り当てに類似した、アプリケーションに対するＰＣＲ番号の割り当てが可能となる。

このように、前記第２の実施形態によれば、プラットフォームが生成することのできる暗号化され保護された記憶空間が、前記ＴＰＭの暗号機能と共に、そのハードウェアで実施されたＰＣＲの代替として使用される。前記ＰＣＲのために確保されたアドレス空間はおよそ２^３２と非常に大きいので、前記ＰＣＲの代替として前記アドレス空間を使用するだけで前記プラットフォームのシステム内の任意の暗号化されて保護されたメモリ要素（読み書き可能メモリ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ：ＲＡＭ）など）を指定することができる。このようにすれば、現実のハードウェアＰＣＲよりも多くのこのような「仮想ＰＣＲ」を有することができる。従って、このようなより多くの「仮想ＰＣＲ」を使用して、より多くのアプリケーションの読み込み工程の完全性およびその他の「測定に値する」イベントを追跡することができる。

本発明の第３の実施形態によれば、システムの起動時に全てのＰＣＲの内容がリセットされる。上述の第２の実施形態のように、多くの仮想または現実のＰＣＲが存在する場合、前記アプリケーションに割り当てられたＰＣＲは前記始動状態から直接計算されることが好ましい。これには、アプリケーションに対する固定されたＰＣＲの割り当てが必要となるが、前記基本状態を格納する必要はない。

本発明の前記第３の実施形態によれば、システム内に多くの現実のまたは仮想のＰＣＲを有するとき、基本的にはそれらを群に分割することができ、次に各群のＰＣＲはただ１つのアプリケーションの完全性測定を追跡するために事前割り当てされることとなり、その他一切のアプリケーションの測定は、前記特定のアプリケーションが割り当てられた群に属さない前記現実のまたは仮想のＰＣＲの何れにも記録できない。このようにすれば、全てのＰＣＲがリセットされたときでも、かつ前記完全性測定の履歴を構築するための特別な「基本状態」が実際には存在しないときでも、各群から１つのＰＣＲを前記システムの起動後の「真新しい初期状態」のための状態維持空間として使用し、次に、同一の群内の他のＰＣＲを使用して、所定の手順に従って前記イベントの履歴の詳細なスナップショット（同一のアプリケーションの異なるバージョンの読み込み工程など）を記録することができる。このように、全てのイベントを同一のＰＣＲ内に拡張する必要はなく、むしろこのような拡張のスナップショットを、個別のＰＣＲを実際に拡張することなく、単に異なるＰＣＲ内に記録することができる。さらに、（全て同一の群に属する）多数のＰＣＲおよびそれらの値、および前記更新されたＰＣＲの順番の知識を使用して、そのスナップショットがその群に属するＰＣＲの各々に保存された、前記プラットフォームにおけるその特定のアプリケーションの履歴にのみ適用される、完全性測定ダイジェストの履歴ログを生成することができる。

図５は、アプリケーション１およびアプリケーション２用のＰＣＲが使い捨て可能な、このようなＰＣＲ構成を示す。前記アプリケーションを測定する必要がある度に前記ＰＣＲの内容がリセットでき、前記ＰＣＲの内容がこの初期化された状態から拡張されることになる。前記アプリケーション用に計算されたＰＣＲ値と共にオペレーティングシステムおよびドライバーに割り当てられたＰＣＲの内容を、前記システムの完全性を検証するための呼掛器に送信することができる。

上記に提示された３つの実施形態の全ては、呼掛器が、前記プラットフォームの状態がそのあるべき状態にあるかを、その使用者のプライバシーを侵害せずに検証する助けをする。

また、これら３つの実施形態の全ては、参照完全性基準（ｒｅｆｅｒｅｎｃｅｉｎｔｅｇｒｉｔｙｍｅｔｒｉｃ：ＲＩＭ）証明書の使用によっても補強できる。従来のＲＩＭ証明書は、携帯電話の起動処理のためのステートメントを提供する特定の方法として定義されている。前記従来のＲＩＭ証明書は、起動後にシステムが得るべき参照状態についてのステートメントを含む。起動後、前記システムが前記ＲＩＭ証明書内で指定されたものと同じ状態に達したと決定すると、次に前記システムは、前記ＴＰＭにそのＰＣＲ０（前記第１のＰＣＲ）を更新して、同じく検証された前記獲得した状態を記述する前記ステートメントのＳＨＡハッシュ動作の値を含むように要求する。

本発明によれば、参照基本状態（ｒｅｆｅｒｅｎｃｅｂａｓｅｓｔａｔｅ：ＲＢＳ）証明書が使用される。全てのアプリケーションに共通して適用される、前記プラットフォームのＯＳの単一の共通起動後状態のみのステートメントを提供することができる前記従来のＲＩＭ証明書と違って、前記新しいＲＢＳ証明書は、アプリケーションに特定の参照基本状態についてのステートメントを提供するために使用される。この概念の違いによって、ＲＢＳ証明書を使用するシステムについて、プラットフォームが、異なるアプリケーションまたはアプリケーション群の基本状態を各々指定する複数の異なるＲＢＳ証明書に、任意の時点で適応できることにもなる。これは、任意の時点において前記プラットフォームが１つのＲＩＭ証明書のみに取り組むことができる、単にＲＩＭ証明書を支持するだけのシステムとは対照的である。重ねて、多くの異なるアプリケーションのイベント（読み込み工程など）の参照基本状態を指定するように各々調整され、各々がアプリケーション特定の基本状態の同時参照用のプラットフォームに適応し、それによって使用される、複数のＲＢＳ証明書を有することができる。ＰＣＲの観点から、各ＲＢＳ証明書は、少なくとも１つのそれ専用の（現実の、または仮想の）ＰＣＲを必要とすることとなる。ＲＢＳ証明書毎のこのような専用ＰＣＲは、前記プラットフォームＯＳが前記システムの実際の状態と前記基本状態との間の確認の検証または非検証状況についての情報を示すように構築するステートメントのハッシュ値を記録するために使用されることとなる。前記ハッシュ値は、前記ＲＢＳ証明書に含まれる状態関連ステートメントに示された基本状態に等しいシステムの実際の状態の前記ＴＰＭを利用して、前記プラットフォームエージェントが検証した直後に記録されることとなる。

このようなステートメントの例としては、「実際のシステム状態と基本状態が同一であることが検証されました」であってもよい。そのＲＢＳ証明書に専用のＰＣＲに今記録されているこのようなステートメントのハッシュは、その専用ＰＣＲ、ならびに前記割り当てられたアプリケーションまたはアプリケーション群の完全性測定検証に使用できる、その他任意のＰＣＲのための更なる拡張動作の開始点を提供できる。ＲＢＳ証明書は、構築されたこのような「状態確認ステートメント」のハッシュ値をも含むことに留意されたい。このように、前記プラットフォームＯＳによって構築された前記ステートメント上で実行されたハッシュ動作の結果を同一のＲＢＳ証明書の異なる部分に含まれる、または異なるＲＢＳ証明書に含まれる同一のステートメントのハッシュ値と比較して、前記システム状態が前記基本状態と一致するかを示すことによって、前記プラットフォームＯＳが、特定のアプリケーションまたはアプリケーション群の完全性測定ダイジェスト格納用に割り当てられたＰＣＲを外部から検証可能な開始点の値から拡張する手段によってプロビジョニングされる。ここでも、その値は、前記システムの実際の状態と前記関連づけられたＲＢＳ証明書に示された基本状態との間の確認に関わるステートメントのＳＨＡ−１ハッシュである。

ＲＩＭ証明書は、コアＯＳソフトウェア、およびそのバージョン番号などの、このようなＯＳの関連情報の完全性基準に関する情報を伝達する。次に、前記証明書内に含まれる完全性参照値が実際の測定値に照らして確認された後、前記ＲＩＭ証明書の「検証または非検証」ステートメントを運ぶために、前記プラットフォームのＴＰＭの特定のＰＣＲ、即ち前記ＰＣＲ０が割り当てられる。

本発明によって使用される基本状態は、種々の異なる証明書に含まれるステートメントと比較される可能性のある異なる「状態確認ステートメント」を含んでもよい。これら証明書の各々は、各々が特定のアプリケーションまたはアプリケーション群、またはその他のコンテクストに属する異なる基本状態に関する情報を含んでもよい。

図６は、第１の呼掛器６０５と、第２の呼掛器６１０と、プラットフォームエージェント６２０、ＴＰＭ６２５、およびＲＢＳ証明書６３０を含むユーザー機器６１５とを含むシステム６００によって実施されたＴＣＧ手順を示す。図６に示す通り、前記第１の呼掛器６０５は、前記プラットフォームエージェント６２０にコマンドを発行して、前記第１の呼掛器６０５がその完全性を検証しようと意図する読み込まれたアプリケーションに適用される基本状態によって指定された初期構成から計算されたプラットフォーム構成を取得する（工程６３５）ことができる。次に、前記プラットフォームエージェント６２０が前記ＴＰＭ６２５にコマンドを発行して（工程６４０）、前記第１の呼掛器６０５がその完全性状況を検証しようとするアプリケーションに適用されるＲＢＳ証明書を確認させる。前記ＴＰＭ６２５が、これを受けてコマンドを発行し、前記ＴＰＭ６２５が制御する証明書リポジトリから前記ＲＢＳ証明書６３０を取得する（工程６４５）。前記ＴＰＭ６２５が、同様に署名付き前記ＲＢＳ証明書６３０を取得する（工程６５０）。次に、前記プラットフォームエージェント６２０が前記ＴＰＭ６２５にコマンドを発行して（工程６５５）検証および拡張動作を実行する。この動作において、前記システム状態と（前記ＲＢＳ証明書に示された）前記基本状態が同一であることが検証された後で、前記プラットフォームエージェント６２０が構築するステートメントのハッシュが前記ＲＢＳ証明書に含まれるハッシュ値と同一であることを検証して初めて、前記ＴＰＭ６２５によって制御された、前記第１の呼掛器６０５のために完全性を検証中のアプリケーションに特定の、（現実の、または仮想の）特定ＰＣＲを、前記ＴＰＭ６２５が拡張する。次に、前記ＴＰＭ６２５は、ＡＩＫを用いて前記ＰＣＲ値に署名し、それを前記プラットフォームエージェント６２０に送信する（工程６６０）。次に、前記プラットフォームエージェント６２０は、前記署名付きＰＣＲ値を含む前記プラットフォーム構成情報を前記第１の呼掛器６０５に送信することができる（工程６６５）。次に、前記第１の呼掛器６０５は、前記プラットフォームエージェント６２０から受信した前記プラットフォーム構成情報を使用して、それの意図する前記アプリケーションが、前記ＲＢＳ証明書に示された正しい基本システム状態から正しくかつ前記アプリケーションに対して支障を来さずに読み込まれたかを検証する（工程６７０）ことができる。

別の呼掛器（即ち前記第２の呼掛器６１０）が意図したアプリケーションの完全性を検証しようとするとき、この呼掛器は、（工程６８０、６９２、および６９４を実行する）前記プラットフォームエージェント６２０および（工程６８５、６９０、および６９４を実行する）前記ＴＰＭ６２５の助けを得て、しかしその第２の呼掛器６１０が意図する前記アプリケーションに特定の異なるＲＢＳ証明書を使用して、同様の方法、実質的に同一の手順（工程６７５および６９８）で実行することができる。

図６は、提案されたＲＢＳ証明書による前記第２の実施形態の補強を描写している。拡張を必要とする実際の完全性測定値を格納することによってではなく、携帯トラストモジュール（ｍｏｂｉｌｅｔｒｕｓｔｍｏｄｕｌｅｓ：ＭＴＭｓ）内のＲＩＭ証明書の現在の使い方と同じように「確認」または「非確認」のステートメントを格納することによって、仮想ＰＣＲを使用して前記基本状態に関する情報が格納される。一方的に前記ＰＣＲを拡張する代わりに、異なるコマンド(即ち、擬似拡張結果が前記ＲＢＳ証明書に含まれる状態を確認するとＰＣＲを拡張するコマンド)を使用すべきであることに留意されたい。さらに、前記ＰＣＲ内で拡張された値は実際の測定結果ではなく、前記実際の拡張と前記ＲＢＳ証明書に含まれる状態情報の比較がなされたときに「確認」または「非確認」イベントが発生したか否かを述べるステートメントである。

図６において、呼掛器特定の構成検証について、前記異なる呼掛器は、前記特定の呼掛器の各々に１つ、共通の単一ＲＢＳ証明書、または異なるＲＢＳ証明書を使用できることに留意されたい。

前記標準によって定義されていない前記システムの状態を要求するためにその相手局エンティティーによって使用される手順には、一定の態様がある。このような態様の１つは、前記相手局エンティティーがどのようにして前記測定値を要求できるかである。

図７は、主リストおよび副リストを使用した実施形態のブロック図を示す。そのリクエスタは、好ましくは前記主リストから１若しくはそれ以上のエンティティーを選択し、次に、受信を希望する測定値の前記サブリストから１若しくはそれ以上の要素を選択することによって、必要とする測定値を正確に識別する。副リストが指定されていない場合、前記主リスト内の全てのエンティティーの測定値がリクエスタに送信されると想定することができる。ｘが前記主リストの識別情報を表し、ｙが前記副リスト内の要素を識別するとき、前記要求は要求［ｘ］［ｙ］の形式であってよい。上述の通り、ｙは前記要求構造において選択的要素である。この要求は、前記主リストおよび副リストの要素を伝えるために、拡張マーク付け言語（ｅｘｔｅｎｓｉｂｌｅｍａｒｋｕｐｌａｎｇｕａｇｅ：ＸＭＬ）のような言語の使用を含む任意の機構を使用して行うことができる。

以下に示すＸＭＬの例は、インターネットエクスプローラ（ＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒ）およびメディア・プレイヤー・アプリケーション（ＭｅｄｉａＰｌａｙｅｒＡｐｐｌｉｃａｔｉｏｎｓ）用の測定値を要求するために使用される。

開示の実施形態に基づいて、仮想ＰＣＲ番号が前記アプリケーションに割り当てられている。これらの値は、好ましくは任意の識別子（例えば、グローバル一意識別子（ｇｌｏｂａｌｌｙｕｎｉｑｕｅｉｄｅｎｔｉｆｉｅｒ：ＧＵＩＤ）または汎用一意識別子（ｕｎｉｖｅｒｓａｌｌｙｕｎｉｑｕｅｉｄｅｎｔｉｆｉｅｒ：ＵＵＩＤ）など）であり、前記ＴＰＭと前記現実のＰＣＲ割り当てとの間のマッピングテーブルは、前記ＴＰＭメモリに格納されることが好ましい。このシナリオでは、前記ＰＣＲ値を要求する前記アプリケーションは前記アプリケーションに割り当てられたＰＣＲ値のことを知らず、複数のプラットフォームに亘って有効な一意識別子を使用して要求を実行する。

上述の方法に関連して、図８は、ＴＰＭと仮想ＰＣＲとを有するユーザー装置システムを使用して、呼掛器に対して、前記プラットフォーム構成の完全性の検証のためのデータを供給できる様子を示す。図８は、呼掛器８０５と、プラットフォームエージェント８１５、ＴＰＭ８２０、および仮想ＰＣＲ８２５を含むユーザー装置８１０とを含むシステム８００内で実施されるＴＣＧ手順を示す。前記ユーザー装置システムはおよそ２^３２までの仮想ＰＣＲを有することができることに留意されたい。

図８に示すように、前記呼掛器８０５が、後に前記プラットフォームの完全性の検証に使用する前記プラットフォーム構成データを取得するように前記プラットフォームエージェント８１５に要求する（工程８３０）。前記プラットフォームエージェント８１５が、前記ＴＰＭ８２０にコマンドを発行して（工程８３５）参照基本状態からのＰＣＲを拡張させる。前記プラットフォームエージェント８１５は、前記ＴＰＭ８２０に拡張させたいＰＣＲが物理的ＰＣＲか仮想ＰＣＲかを、必ずしも指定しなければならないとは限らない。次に、前記ＴＰＭ８２０が、前記仮想ＰＣＲの値を拡張し、前記ＴＰＭ８２０自体の中に格納された暗号鍵、または前記ＴＰＭの外部に格納されていながら前記ＴＰＭ８２０自体の中に格納された鍵によって保護されている鍵によって、その新しい拡張された値を用いて前記仮想ＰＣＲ８２５を暗号化する（工程８４０）。前記プラットフォームエージェント８１５は後に、前記ＰＣＲの値を署名し、それを前記プラットフォームエージェント８１５に送信するように、前記ＴＰＭ８２０に命令する（工程８４５）。次に、前記ＴＰＭ８２０が前記仮想ＰＣＲ８２５をアクセスし、前記仮想ＰＣＲ８２５から前記暗号化されたＰＣＲ値を取得する（工程８５０および８５５）。次に、前記ＴＰＭが前記暗号化された仮想ＰＣＲ値を復号化する（工程８６０）。次に、前記ＴＰＭ８２０が前記復号化された仮想ＰＣＲ値を署名し、それを（前記呼掛器８０５が有するそれとは異なる鍵で）再暗号化し、それを前記プラットフォームエージェント８１５に送信する（工程８６５）。前記プラットフォームエージェント８１５が前記仮想ＰＣＲ８２５からのデータを含むプラットフォーム構成データを作成し、それを前記呼掛器８０５に送信する（工程８７０）。次に、前記呼掛器８０５が受信した前記プラットフォーム構成データを使用して、前記ユーザー装置８０５の完全性状態（または前記プラットフォーム構成の状態）を検証する（工程８７５）。

実施形態
１．トラステッド・プラットフォーム・モジュール（ｔｒｕｓｔｅｄｐｌａｔｆｏｒｍｍｏｄｕｌｅ：ＴＰＭ）と、プラットフォームエージェントと、参照基本状態（ｒｅｆｅｒｅｎｃｅｂａｓｅｓｔａｔｅ：ＲＢＳ）証明書とを有するユーザー装置を含むコンピュータシステムにおける方法であって、
呼掛器（ｃｈａｌｌｅｎｇｅｒ）が前記プラットフォームエージェントにコマンドを発行し、読み込まれたアプリケーションに適用される基本状態によって特定される初期構成に基づいて計算されたプラットフォーム構成を取得する工程であって、当該読み込まれたアプリケーションは前記呼掛器が完全性の検証を意図するものである、前記取得する工程を有する方法。
２．実施形態１記載の方法において、この方法は、さらに、
前記プラットフォームエージェントが前記ＴＰＭにコマンドを発行し、前記呼掛器が完全性の検証を意図する前記アプリケーションに適用される前記ＲＢＳ証明書を確認させる工程と、
前記ＴＰＭが、基本状態を示す署名付きＲＢＳ証明書を取得する工程と、
前記プラットフォームエージェントが前記ＴＰＭにコマンドを発行して検証および拡張動作を実行させる工程であって、これにより、当該ＴＰＭは、制御している特定のプラットフォーム構成レジスタ（ｐｌａｔｆｏｒｍｃｏｎｆｉｇｕｒａｔｉｏｎｒｅｇｉｓｔｅｒ：ＰＣＲ）であって、且つ前記呼掛器のために完全性が検証されている前記アプリケーションに固有のプラットフォーム構成レジスタを拡張するものである、前記実行させる工程と
を有するものである。
３．実施形態２記載の方法において、この方法は、さらに、
前記システムの状態および前記基本状態は同一であることを検証する工程と、
前記プラットフォームエージェントがステートメントのハッシュは前記ＲＢＳ証明書に含まれるハッシュ値と同一であることを検証する工程と
を有するものである。
４．実施形態３記載の方法において、この方法は、さらに、
前記ＴＰＭが構成証明アイデンティティ鍵（ａｔｔｅｓｔａｔｉｏｎｉｄｅｎｔｉｆｉｃａｔｉｏｎｋｅｙ：ＡＩＫ）を用いてＰＣＲ値に署名する工程と、
前記ＴＰＭが前記署名付きＰＣＲ値を前記プラットフォームエージェントに送信する工程と、
前記プラットフォームエージェントが前記署名付きＰＣＲ値を含むプラットフォーム構成情報を前記呼掛器に送信する工程と
を有するものである。
５．実施形態１〜４のうちのいずれか１つの方法において、この方法は、さらに、
前記呼掛器が、前記ＲＢＳ証明書に示された正しい基本システム状態に基づいて前記アプリケーションが正しく、且つ支障なく読み込まれたかどうかを検証する工程を有するものである。
６．ユーザー装置であって、
少なくとも１つの参照基本状態（ｒｅｆｅｒｅｎｃｅｂａｓｅｓｔａｔｅ：ＲＢＳ）と、
呼掛器から第１のコマンドを受信し、読み込まれたアプリケーションに適用される基本状態によって特定される初期状態に基づいて計算されたプラットフォーム構成を取得するように構成されたプラットフォームエージェントであって、当該読み込まれたアプリケーションは前記呼掛器が完全性の検証を意図するものである、前記プラットフォームエージェントと、
第２のコマンドを受信し、前記呼掛器がその完全性の検証を意図する前記アプリケーションに適用されるＲＢＳ証明書を確認して、基本状態を示す署名付きＲＢＳ証明書を取得するように構成されたトラステッド・プラットフォーム・モジュール（ｔｒｕｓｔｅｄｐｌａｔｆｏｒｍｍｏｄｕｌｅ：ＴＰＭ）であって、前記プラットフォームエージェントは前記ＴＰＭに第３のコマンドを発行して検証および拡張動作を実行させ、これにより、当該ＴＰＭは、制御している特定のプラットフォーム構成レジスタ（ｐｌａｔｆｏｒｍｃｏｎｆｉｇｕｒａｔｉｏｎｒｅｇｉｓｔｅｒ：ＰＣＲ）であって、且つ前記呼掛器のために完全性が検証されている前記アプリケーションに固有のプラットフォーム構成レジスタを拡張するものである、前記トラステッド・プラットフォーム・モジュールと
を有するユーザー装置。
７．実施形態６記載のユーザー装置において、システムの状態および前記基本状態が同一であることが検証された場合、前記プラットフォームエージェントは、ステートメントのハッシュが前記ＲＢＳ証明書に含まれるハッシュ値と同一であることを検証するものである。
８．実施形態７記載のユーザー装置において、前記ＴＰＭは、構成証明アイデンティティ鍵（ａｔｔｅｓｔａｔｉｏｎｉｄｅｎｔｉｆｉｃａｔｉｏｎｋｅｙ：ＡＩＫ）を用いてＰＣＲ値に署名し、前記署名付きＰＣＲ値を前記プラットフォームエージェントに送信するものである。
９．実施形態８記載のユーザー装置において、前記プラットフォームエージェントは、前記署名付きＰＣＲ値を含むプラットフォーム構成情報を前記呼掛器に送信するものである。
１０．実施形態６〜９のうちのいずれか１つのユーザー装置において、前記呼掛器は、前記ＲＢＳ証明書に示されたように、正しい基本システム状態に基づいて前記アプリケーションが正しく、且つ支障なく読み込まれたかどうかを検証するものである。
１１．アプリケーションを検証するトラステッド・プラットフォーム・モジュール（ｔｒｕｓｔｅｄｐｌａｔｆｏｒｍｍｏｄｕｌｅ：ＴＰＭ）であって、
シールドされた不揮発性メモリを有し、このメモリは、
複数のプラットフォーム構成レジスタ（ｐｌａｔｆｏｒｍｃｏｎｆｉｇｕｒａｔｉｏｎｒｅｇｉｓｔｅｒｓ：ＰＣＲｓ）を格納するための第１の記憶域であって、前記ＴＰＭはシステムの再起動時に前記ＰＣＲ値を初期値にリセットするものである、前記第１の記憶域と、
システムの起動処理の完了が成功したときのプラットフォーム状態を表す複数の基本状態を格納するための第２の記憶域であって、少なくとも１つのアプリケーションの状態が基本状態に対して計算されるものである、前記第２の記憶域と
を有する
トラステッド・プラットフォーム・モジュール。
１２．実施形態１１のＴＰＭにおいて、前記システムは、パーソナルコンピュータ（ｐｅｒｓｏｎａｌｃｏｍｐｕｔｅｒ：ＰＣ）、携帯型情報端末（ｐｅｒｓｏｎａｌｄａｔａａｓｓｉｓｔａｎｔ：ＰＤＡ）、埋め込みシステム、携帯電話、埋め込みシステムを伴う周辺装置、ネットワーク要素、およびトラステッド・コンピューティング・グループ（ＴｒｕｓｔｅｄＣｏｍｐｕｔｉｎｇＧｒｏｕｐ：ＴＣＧ）技術、具体的には、前記ＴＰＭの使用によって実行可能となり、または当該ＴＰＭの使用を可能とする機能およびサービスを備えたその他のプラットフォームを含むグループから選択されるものである。
１３．複数のプラットフォーム構成レジスタ（ｐｌａｔｆｏｒｍｃｏｎｆｉｇｕｒａｔｉｏｎｒｅｇｉｓｔｅｒｓ：ＰＣＲｓ）を格納するためのシールドされた不揮発性メモリを有するトラステッド・プラットフォーム・モジュール（ｔｒｕｓｔｅｄｐｌａｔｆｏｒｍｍｏｄｕｌｅ：ＴＰＭ）とプラットフォームエージェントとを有するユーザー装置を含むコンピュータシステムにおける方法であって、
第１の呼掛器が、前記プラットフォームエージェントからの特定の基本状態に基づいて計算されたプラットフォーム構成に対する要求を送信する工程と、
前記プラットフォームエージェントが、第１の測定値を用いて前記特定の基本状態から前記ＴＰＭの特定プラットフォーム構成レジスタ（ｐｌａｔｆｏｒｍｃｏｎｆｉｇｕｒａｔｉｏｎｒｅｇｉｓｔｅｒ：ＰＣＲ）を拡張する工程と、
前記プラットフォームエージェントが前記ＴＰＭから前記特定ＰＣＲの署名付きの値を要求する工程と、
前記ＴＰＭが前記署名付きＰＣＲ値を前記プラットフォームエージェントに送信する工程と、
前記第１の呼掛器が前記プラットフォームエージェントからプラットフォーム構成を受信する工程と、
前記第１の呼掛器が前記プラットフォーム構成データを、当該第１の呼掛器により計算され前記プラットフォーム構成を検証する値と比較する工程と
を有する方法。
１４．実施形態１３記載の方法において、この方法は、さらに、
第２の呼掛器が前記特定の基本状態に基づいて再計算されたプラットフォーム構成を要求し、且つ受信する工程と、
前記プラットフォームエージェントが、前記第１の測定値とは異なる第２の測定値を用いて前記特定ＰＣＲを拡張する工程と、
前記プラットフォームエージェントが前記ＴＰＭから前記特定ＰＣＲの署名付きの値を要求し、且つ受信する工程と、
前記第２の呼掛器が受信したプラットフォーム構成を検証する工程と
を有するものである。
１５．実施形態１４記載の方法において、前記第１および第２の呼掛器は共に、前記基本状態に基づいて各々独自に計算され、固有の測定値を伴うプラットフォーム構成データを受信するものである。
１６．複数のプラットフォーム構成レジスタ（ｐｌａｔｆｏｒｍｃｏｎｆｉｇｕｒａｔｉｏｎｒｅｇｉｓｔｅｒｓ：ＰＣＲｓ）を格納する、シールドされた不揮発性メモリを有するトラステッド・プラットフォーム・モジュール（ＴｒｕｓｔｅｄＰｌａｔｆｏｒｍＭｏｄｕｌｅ：ＴＰＭ）における方法であって、
前記ＰＣＲをグループに分割する工程と、
各ＰＣＲのグループを事前割り当てして特定のアプリケーションの完全性測定値を追跡する工程であって、前記特定のアプリケーションが割り当てられたグループに属さないＰＣＲのいずれにも当該特定のアプリケーション以外のアプリケーションの測定値を記録できないものである、前記追跡する工程と
を有する方法。
１７．実施形態１６記載の方法において、この方法は、前記ＰＣＲの全てがリセットされるとき、各グループのうちの１つのＰＣＲを起動後のシステムの「真新しい初期状態」のための状態保持空間として使用する工程を有するものである。
１８．実施形態１７記載の方法において、この方法は、さらに、
前記グループ内のその他のＰＣＲを使用して、イベントの履歴の詳細なスナップショットを所定の手順で記録する工程を有するものである。
１９．実施形態１８記載の方法において、前記イベントは、同一のアプリケーションの異なるバージョンを読み込む工程を含むものである。
２０．実施形態１８記載の方法であって、この方法は、さらに、
個々のＰＣＲを実際に拡張せずに、ＰＣＲ拡張のスナップショットを異なるＰＣＲの中に記録する工程を有するものである。
２１．トラステッド・プラットフォーム・モジュール（ｔｒｕｓｔｅｄｐｌａｔｆｏｒｍｍｏｄｕｌｅ：ＴＰＭ）と、プラットフォームエージェントと、仮想プラットフォーム構成レジスタ（ｐｌａｔｆｏｒｍｃｏｎｆｉｇｕｒａｔｉｏｎｒｅｇｉｓｔｅｒ：ＰＣＲ）とを有するユーザー装置を含むコンピュータシステムにおいて、プラットフォーム構成データを供給してプラットフォーム構成の完全性を呼掛器に対して検証するための方法であって、
前記呼掛器が、後にプラットフォームの完全性の検証に使用する前記プラットフォーム構成データを取得するように前記プラットフォームエージェントに要求する工程と、
前記プラットフォームエージェントが、前記ＴＰＭにコマンドを送信して、参照基本状態からＰＣＲを拡張させる工程と、
前記ＴＰＭが前記仮想ＰＣＲの値を拡張する工程と、
前記ＴＰＭが、新しく拡張された値を伴う前記仮想ＰＣＲを暗号鍵を用いて暗号化する工程であって、前記暗号鍵は前記ＴＰＭ自体の中に格納されるか、または前記ＴＰＭの外部に格納され、前記ＴＰＭ内に格納された鍵によって保護されているものである、前記暗号化する工程と
を有する方法。
２２．実施形態２１記載の方法において、この方法は、さらに、
前記プラットフォームエージェントが前記ＴＰＭに命令して前記ＰＣＲの値に署名させ、前記署名付きＰＣＲ値を当該プラットフォームエージェントに送信させる工程と、
前記ＴＰＭが前記仮想ＰＣＲにアクセスし、当該仮想ＰＣＲから前記暗号化されたＰＣＲ値を取得する工程と、
前記ＴＰＭが、前記暗号化された仮想ＰＣＲ値を復号化する工程と
を有するものである。
２３．実施形態２２記載の方法において、この方法は、さらに、
前記ＴＰＭが、前記復号化された仮想ＰＣＲ値に署名する工程と、
前記ＴＰＭが、前記呼掛器が有する鍵とはは異なる鍵を用いて前記復号化されたＰＣＲ値を再暗号化する工程と、
前記ＴＰＭが、前記再暗号化されたＰＣＲ値を前記プラットフォームエージェントに送信する工程と
を有するものである。
２４．実施形態２３記載の方法において、この方法は、さらに、
前記プラットフォームエージェントが、前記仮想ＰＣＲからのデータを含むプラットフォーム構成データを作成する工程と、
前記プラットフォームエージェントが、前記作成されたデータを前記呼掛器に送信する工程と、
前記呼掛器が、前記作成されたデータを使用して前記ユーザー装置の完全性状態または前記プラットフォーム構成の状態を検証する工程と
を有するものである。

本発明の特徴および要素は、前記最良の実施形態の中に特定の組み合わせで述べられているが、各特徴または要素は、前記最良の実施形態のその他の特徴または要素を伴わずに単独で、または本発明のその他の特徴または要素と種々組み合わせて、あるいは組み合わせずに使用できる。本発明内で提供された方法またはフローチャートは、汎用コンピュータまたはプロセッサによって実行されるコンピュータ可読記憶媒体内で具体的に実施されたコンピュータプログラム、ソフトウェア、またはファームウェア内で実施することができる。コンピュータ可読記憶媒体の例には、読み出し専用メモリ（ｒｅａｄｏｎｌｙｍｅｍｏｒｙ：ＲＯＭ）、読み書き可能メモリ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ：ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリ装置、内部固定ディスク、取り外し可能ディスクなどの磁気ディスク、光磁気媒体、およびＣＤ−ＲＯＭディスクおよびデジタル・ビデオ・ディスク（ｄｉｇｉｔａｌｖｅｒｓａｔｉｌｅｄｉｓｋｓ：ＤＶＤｓ）などの光媒体が含まれる。

例として、好適なプロセッサには、汎用プロセッサ、専用プロセッサ、通常プロセッサ、デジタル信号処理装置（ｄｉｇｉｔａｌｓｉｇｎａｌｐｒｏｃｅｓｓｏｒ：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連づけられた１若しくはそれ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向けＩＣ（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔｓ：ＡＳＩＣｓ）、プログラマブルゲート配列（ＦｉｅｌｄＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙｓ：ＦＰＧＡｓ）回路、その他任意の種類の集積回路（ＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ：ＩＣ）、および／または状態機械が含まれる。

ワイヤレス送受信装置（ｗｉｒｅｌｅｓｓｔｒａｎｓｍｉｔｒｅｃｅｉｖｅｕｎｉｔ：ＷＴＲＵ）、第３世代携帯電話端末（ｕｓｅｒｅｑｕｉｐｍｅｎｔ：ＵＥ）、端末、基地局、無線ネットワークコントローラ（ｒａｄｉｏｎｅｔｗｏｒｋｃｏｎｔｒｏｌｌｅｒ：ＲＮＣ）、または任意のホストコンピュータに使用する無線通信機を実施するために、ソフトウェアに関連づけられたプロセッサを使用してもよい。前記ＷＴＲＵは、カメラ、ビデオ・カメラ・モジュール、テレビ電話、スピーカフォン、振動装置、スピーカー、マイク、テレビ用送受信器、ハンズ・フリー・ヘッドセット、キーボード、ブルートゥース（登録商標）モジュール、ＦＭ（ｆｒｅｑｕｅｎｃｙｍｏｄｕｌａｔｅｄ：ＦＭ）ラジオ装置、液晶表示（ｌｉｑｕｉｄｃｒｙｓｔａｌｄｉｓｐｌａｙ：ＬＣＤ）装置、有機ＬＥＤ（ｏｒｇａｎｉｃｌｉｇｈｔ−ｅｍｉｔｔｉｎｇｄｉｏｄｅ：ＯＬＥＤ）表示装置、デジタル音楽プレイヤー、メディアプレイヤー、ビデオゲーム機モジュール、インターネットブラウザー、および／または任意の無線ローカル・エリア・ネットワーク（ｗｉｒｅｌｅｓｓｌｏｃａｌａｒｅａｎｅｔｗｏｒｋ：ＷＬＡＮ）モジュールなどのハードウェアおよび／またはソフトウェア内で実施するモジュールと連結して使用することができる。

例として提供され、添付の図面と併せて理解されるべき最良の実施形態の以下の記述によって、本発明のより詳細な理解を得ることができる。
図１は、呼掛器と、プラットフォームエージェントと、ＴＰＭと、リポジトリとを含むシステムにおいて実施される従来のＴＣＧ構成証明手順を示す。図２は、２つの呼掛器とユーザー装置を含む、相互の拡張動作について知らない異なるアプリケーションが異なる状態からＰＣＲを拡張するシステムにおいて実施される従来のＴＣＧ手順を示す。図３は、本発明による、２つの呼掛器と、共通の基本状態からの状態拡張を使用するユーザー装置とを含むシステムにおいて実施されるＴＣＧ手順を示す。図４は、従来技術を、異なる拡張された状態が異なる呼掛器について実施される本発明と比較する。図５は、本発明による、異なるＰＣＲ上の異なる拡張された状態の割り当てを示す。図６は、本発明による、２つの呼掛器と、参照基本状態（ｒｅｆｅｒｅｎｃｅｂａｓｅｓｔａｔｅ：ＲＢＳ）証明書を用いた基本状態拡張を使用するユーザー装置とを含むシステムにおいて実施されるＴＣＧ手順を示す。図７は、本発明による測定の選択的要求を図示する。図８は、本発明による、物理的ＴＰＭの暗号化機能によって保護された外部メモリを使用する仮想ＰＣＲ、およびＴＰＭと仮想ＰＣＲとを有するシステムを使用して、呼掛器によるプラットフォーム構成の完全性検証のためのデータを供給できる様子を示す。

Claims

ユーザー装置であって、
複数の署名付き参照基本状態（ｒｅｆｅｒｅｎｃｅｂａｓｅｓｔａｔｅ：ＲＢＳ）証明書を有する証明書リポジトリであって、前記複数の署名付きＲＢＳ証明書の各々は、アプリケーションに関連付けられ、並びに基本状態およびハッシュ値を含む証明書リポジトリと、
呼掛器が完全性の検証を意図する、前記ユーザー装置に読み込まれたアプリケーションに関連付けられたプラットフォーム構成を取得するように構成されたプラットフォームエージェントであって、当該プラットフォーム構成は、前記読み込まれたアプリケーションについて、前記複数の署名付きＲＢＳ証明書のうちの前記署名付きＲＢＳ証明書の基本状態を用いて計算され、もう１つのハッシュ値を構築するようさらに構成されたプラットフォームエージェントと、
トラステッド・プラットフォーム・モジュール（ｔｒｕｓｔｅｄｐｌａｔｆｏｒｍｍｏｄｕｌｅ：ＴＰＭ）であって、前記証明書リポジトリから前記署名付きＲＢＳ証明書を取得し、および当該ＴＰＭにより制御され、前記署名付きＲＢＳ証明書のハッシュ値が前記プラットフォームエージェントにより構築された他のハッシュ値と同一であると検証した後、前記読み込まれたアプリケーションに関連付けられ、前記署名付きＲＢＳ証明書用のプラットフォーム構成レジスタ（ｐｌａｔｆｏｒｍｃｏｎｆｉｇｕｒａｔｉｏｎｒｅｇｉｓｔｅｒ：ＰＣＲ）を拡張するよう構成されたＴＰＭと
を有するユーザー装置。
前記ＴＰＭは、構成証明アイデンティティ鍵（ａｔｔｅｓｔａｔｉｏｎｉｄｅｎｔｉｆｉｃａｔｉｏｎｋｅｙ：ＡＩＫ）を用いてＰＣＲ値に署名し、前記署名付きＰＣＲ値を前記プラットフォームエージェントに送信するようさらに構成された請求項１記載のユーザー装置。
前記プラットフォームエージェントは、前記署名付きＰＣＲ値を含むプラットフォーム構成情報を前記呼掛器に送信するようさらに構成された請求項２記載のユーザー装置。
前記呼掛器は、前記署名付きＲＢＳ証明書に示されたように、正しい基本状態に基づいて前記読み込まれ、前記署名付きＲＢＳ証明書に関連付けられたアプリケーションが読み込まれたことを検証するようさらに構成された請求項３記載のユーザー装置。