JP4732513B2 - ソフトウェア・ベースのセキュリティ・コプロセッサを提供する方法および装置 - Google Patents

Description

本開示は、概括的にはデータ処理の分野に関し、より詳細には安全な（secure）仮想化をサポートする方法および関係する装置に関する。

通常の処理システムは、中央処理装置（CPU）およびランダム・アクセス・メモリ（RAM）といったハードウェア資源ならびにオペレーティング・システム（OS）および一つまたは複数のエンドユーザー・プログラムまたはアプリケーションといったソフトウェア資源を含みうる。アプリケーションは典型的には、特定のOS上で走るように開発される。典型的な従来のコンピュータ・システムが始動されると、システムは、エンドユーザー・プログラムまたはアプリケーションをロードする前にOSをロードする。OSは典型的には、ソフトウェア・アプリケーションと処理システム中のハードウェアとの間の仲介者としてはたらく。

RAMおよび一つまたは複数のCPUに加えて、処理システムは、信頼されるプラットフォーム・モジュール（TPM: trusted platform module）のようなセキュリティ・コプロセッサ（SC: security coprocessor）を含みうる。TPMは、処理システム内に存在するハードウェア・コンポーネントであり、処理システムのセキュリティを向上させるためのさまざまな機能およびサービスを提供する。たとえば、TPMは集積回路（IC）または半導体チップとして実装されることができ、データを保護し、プラットフォームの構成を構成証明するために使うことができる。

TPMは、2003年10月2日付けの信頼コンピューティング・グループ（TCG: Trusted Computing Group）TPM規格、バージョン1.2（以下、「TPM規格」）のような規格に従って実装されうる。このTPM規格は、設計原理、TPMの構造およびTPMコマンドといった部を含んでいる。TPM規格はTCGによって公表されており、インターネットからwww.trustedcomputinggroup.org/homeにおいて入手可能である。

TPMのサブコンポーネントは、実行エンジンおよび安全な不揮発性（NV: non-volatile）メモリまたは記憶装置を含みうる。安全なNVメモリは、暗号鍵のような機微な情報を記憶するために使われ、実行エンジンは該機微な情報をTPMの制御論理によって指定されるセキュリティ・ポリシーに従って保護する。

一般に、TCG準拠のTPMは、プラットフォームの特性に基づいて、プラットフォームの素性（identity）および／または完全性（integrity）を構成証明する（attest）といったセキュリティ・サービスを提供する。TPMによって典型的に考慮されるプラットフォーム特性は、プロセッサ（単数または複数）およびチップセットといったプラットフォームのハードウェア・コンポーネントならびにファームウェアおよびOSといったプラットフォーム内に存在するソフトウェアを含む。TPMは、ソフトウェア・プロセスの監査およびログ記録ならびにプラットフォーム・ブート完全性、ファイル完全性およびソフトウェア・ライセンスの検証をもサポートしてもよい。したがって、TPMはプラットフォームについての信頼の根幹を提供するものと言うことができる。

したがって、サーバーのような処理システムが他のクライアントのような処理システムからの要求を扱うとき、サーバーはTPMに基づく構成証明（attestation）に基づいてセキュリティ・ポリシーを実施しうる。たとえば、サーバーは、どんなクライアント・システムからの要求でも、該要求がそのクライアント・システムからの有効なTPMに基づくプラットフォーム構成証明を伴っていない限りは、拒否するよう構成されうる。しかしながら、従来の処理システムがTPMを使うとき、その処理システムは同時には一つのソフトウェア環境しかサポートできないことがある。

仮想化製品は、処理システムを複数の仮想機械（VM: virtual machine）に分割するための機能を提供する。たとえば、仮想化製品は、複数のOSが同じ機械上で同時並行して実行されることを許容するような仕方で処理システムのハードウェア資源を分割および管理できる。具体的には、各OSは異なるVMで走ることができる。従って、各VMは実質的に独立したソフトウェア環境と考えてよい。VMで走っているOSは、ゲストOSと称されうる。VMは、仮想機械モニタ（VMM: virtual machine monitor）またはハイパーバイザ（hypervisor）のような仮想化製品によって管理されうる。

本発明の認識するところでは、OSのそれぞれが、実質的に自分の独立した物理的な機械にあるかのように動作することを許容できるようなVMMが有益である。本出願と同じ主体に譲渡された米国特許出願第10/876,944（「'944出願」）はVMによるTPMの使用をサポートする機能を論じている。本出願は、TPMおよび仮想化に関する追加的な特徴および機能を開示する。

本発明の特徴および利点は、付属の請求項、一つまたは複数の例示的な実施形態の以下の詳細な記載および対応する図面から明らかになるであろう。

VMを生成する技術のようなプラットフォーム分割技術は、その潜在的なセキュリティ上の価値のため、近年、ますます関心を集めている。仮想化技術は、プラットフォームをVMに分割し、可能性として各VMが今日の複雑なプラットフォームよりも少ないソフトウェアを走らせるようにすることを許容する。別に、上に示したように、TCGは、信頼されるプラットフォームと分類できる処理システムの生成を容易にするための、ハードウェアで増強されたセキュリティのための規格を提供している。TPMは信頼されるプラットフォームのための信頼の根幹を提供しうる。

所与のVM内のすべてのソフトウェアが同定できて、TPMがそのVM内のすべてのソフトウェアを有意に構成証明できれば有益であろう。しかしながら、TPMを複数のVMによる使用のために共有することは困難である。それは少なくとも部分的には、TPMが状態をもち（stateful）、不透明であるという性質のためである。

きちんと書かれたVMMは、あるVMで走っている悪意あるソフトウェアが、別のVMで走っているソフトウェアに工作（タンパー）することを防止するべきである。さらに、TCGの信頼されたブート・モデルを使う際、TPMがOSおよび各VM内のアプリケーションを測定して、それによりOSおよびアプリケーションのためのデータ保護を提供するとともに、リモート・エンティティの構成証明を容易にすることができれば有益であろう。

残念ながら、TPMの測定設備は、ぴったり一つのオペレーティング・システムの測定結果を保存するよう設計されている。従来のTPMは、複数の同時並行して走るOSの測定結果を別個に保存する機能を欠いている。さらに、TPMの閉じた、スマートカード様の性質のため、その状態は読むことも、スワップ・アウトすることもできない。結果として、デバイス共有または仮想化のための伝統的な技法はTPMのために使うことができない。

図１は、本発明のある例示的な実施形態のある種の側面が実装されうる好適なデータ処理環境１２を描いたブロック図である。データ処理環境１２は処理システム２０を含み、該処理システム２０に含まれる一つまたは複数のプロセッサまたは中央処理装置（CPU）２２は、一つまたは複数のシステム・バス２４またはその他の通信経路または媒体を介してさまざまな他のコンポーネントに通信上結合されている。

ここでの用法では、用語「処理システム」および「データ処理システム」は、単一の機械または一緒に動作する通信上結合された機械もしくは装置のシステムを幅広く包括することが意図されている。例示的な処理システムに含まれるものとしては、限定することなく、分散コンピューティング・システム、スーパーコンピュータ、ハイ・パフォーマンス・コンピューティング・システム、コンピューティング・クラスタ、メインフレーム・コンピュータ、ミニコンピュータ、クライアント‐サーバー・システム、パーソナル・コンピュータ、ワークステーション、サーバー、ポータブル・コンピュータ、ラップトップ・コンピュータ、タブレット、電話、携帯情報端末（PDA）、ハンドヘルド機器、オーディオおよび／またはビデオ機器のような娯楽機器ならびに情報を処理または送信するその他の装置がある。

処理システム２０は、少なくとも部分的には、キーボード、マウスなどといった従来の入力装置からの入力によって、および／または別の機械、バイオメトリック・フィードバックもしくはその他の入力源もしくは信号から受信された指令によって制御されうる。処理システム２０は、ネットワーク・インターフェース・コントローラ（NIC）、モデムまたはその他の通信ポートもしくは結合などを通じて、一つまたは複数のリモートのデータ処理システム７６〜７８への一つまたは複数の接続を利用しうる。処理システムは、構内ネットワーク（LAN）、広域ネットワーク（WAN）、イントラネット、インターネットなどといった物理的および／または論理的なネットワーク８０によって相互接続されうる。ネットワーク８０に関わる通信は、さまざまな有線および／または無線の短距離または長距離搬送波およびプロトコルを利用しうる。それには、無線周波（RF）、衛星、マイクロ波、電気電子学会（IEEE）802.11、ブルートゥース、光、赤外線、ケーブル、レーザーなどが含まれる。

処理システム２０内で、プロセッサ２２は一つまたは複数の揮発性または不揮発性データ記憶装置に通信上結合されていてもよい。そうした記憶装置は、ランダム・アクセス・メモリ（RAM）２６、読み出し専用メモリ（ROM）、統合ドライブ・エレクトロニクス（IDE）ハード・ドライブのような大容量記憶装置および／またはフロッピー（登録商標）・ディスク、光記憶、テープ、フラッシュメモリ、メモリー・スティック、デジタル・ビデオ・ディスク、生物記憶（biological storage）などといったその他の装置もしくは媒体といったものである。この開示の目的のためには、「ROM」の用語は一般に、消去可能なプログラム可能ROM（EPROM）、電気的に消去可能なプログラム可能ROM（EEPROM）、フラッシュROM、フラッシュメモリなどといった不揮発性のメモリ・デバイスを指して使われうる。プロセッサ２２は、ビデオ・コントローラ、小型コンピュータ・システム・インターフェース（SCSI）コントローラ、ネットワーク・コントローラ、ユニバーサル・シリアル・バス（USB）コントローラ、キーボードおよびマウスといった入力装置などといった追加的なコンポーネントに通信上結合されていてもよい。処理システム２０はまた、さまざまなシステム・コンポーネントを通信上結合するために、メモリ・コントローラ・ハブ、入出力（I/O）コントローラ・ハブ、PCIルート・ブリッジなどといった、一つまたは複数のブリッジまたはハブ３４をも含みうる。ここでの用法では、「バス」の用語は、共有通信経路とともにポイント・ツー・ポイント経路を指して使用されうる。

たとえばNICのようないくつかのコンポーネントは、バスと通信するためのインターフェース（たとえばPCIコネクタ）をもつアダプタ・カードとして実装されてもよい。ある実施形態では、一つまたは複数の装置は、プログラム可能または非プログラム可能な論理デイバスまたはアレイ、特定用途向け集積回路（ASIC）、組み込みコンピュータ（embedded computer）、スマートカードなどといったコンポーネントを使って、埋め込まれたコントローラとして実装されうる。

図のように、処理システム２０はまた、プロセッサ２４に通信上結合されたTPM３０をも含む。TPM３０はまた、物理的なTPMまたはハードウェアTPM（hwTPM）３０と称もされうる。ある実施形態では、TPM３０は埋め込みデバイスとして実装され、処理システム２０のシステム・マザーボードまたはバックプレーン上にある。TPM３０はいくつかの記憶設備を含み、それには揮発性のプラットフォーム構成レジスタ（PCR: platform configuration register）および権限付与（authorization）セッションならびに持続的なデータ完全性レジスタ（DIR: data integrity register）、権限付与ダイジェストおよび汎用持続性記憶装置が含まれる。これらの設備のそれぞれは、対応するメモリ内データ構造を有しうる。

本発明は、命令、関数、手続き、データ構造、アプリケーション・プログラムなどを含む関連データを参照し、あるいはそれとともに記述されうる。機械がこれにアクセスすると、該機械はタスクを実行するか、抽象データ型または低レベルのハードウェア・コンテキストを定義するかする。該データは、揮発性および／または不揮発性のデータ記憶装置内に保存されうる。

たとえば、RAM２６は、実行されたときに、TPM３０の安全な仮想化をサポートするための一般化された仮想TPM（GVTPM: generalized virtual TPM）フレームワーク４０を実装する一つまたは複数組の命令を含みうる。GVTPMフレームワーク４０はまた、仮想TPMサービスとも称されうる。この開示の目的のためには、仮想TPM（vTPM）は、TPMのような機能を提供する論理的な（すなわち、主としてソフトウェアで実装される）コンポーネントである。同様に、仮想セキュリティ・コプロセッサ（vSC: virtual security coprocessor）は、ハードウェアのセキュリティ・コプロセッサによって潜在的に提供されうるもののような機能を提供する論理的なデバイスである。

ある例示的な実施形態では、GVPTMフレームワーク４０は、部分的または完全にVMM６４内から動作しうる。別の実施形態では、GVTPMフレームワーク４０は、VMMによってサポートされる一つまたは複数のサービスVM内に存在する。サービスVMは、要求する資源がゲストOSをもつVMより少なくてよいので、軽量VM（lightweight VM）と称されることができる。代替的な実施形態では、GVTPMフレームワーク４０のためのモジュールの一部または全部は、ファームウェアまたは他の任意の保護された環境内に存在してもよい。GVTPMフレームワークの種々の実施形態により、幅広い多様なVMMアーキテクチャのための仮想TPMサービスを提供しうる。他の実施形態では、GVTPMフレームワーク４０は全くVMMの一部でなくてもよい。

今の例示的実施形態では、処理システム２０は、ブート時または何らかの後刻に、処理システム２０内で一つまたは複数のVM ６０Ａ〜６０Ｃをサポートするために、VMM６４をRAM２６にロードしうる。VMM６４は、マイクロカーネルおよびサービスOSのようなソフトウェアまたはファームウェア・コンポーネントの実行を通じて実装されうる。マイクロカーネルは、命令スケジューリングのようなシステム管理タスクのための命令の小さな核を含みうる。サービスOSは、VMを生成し、維持するためのデバイス・ドライバおよび環境仮想化ソフトウェアを含みうる。サービスOS内のデバイス・ドライバは、TPM３０と通信するためのTPMドライバを含みうる。代替的に、図３に示されるように、TPMドライバ１３０は、GVTPMマネージャ１１０のような異なるソフトウェア・コンポーネント内にロードされてもよい。処理システム２０は、VMM６４およびGVTPMフレームワーク４０を実装する命令を、たとえばROMから、および／または一つもしくは複数のローカルもしくはリモートの大容量記憶装置からロードしうる。TPM仮想化をサポートまたは容易化するために使われるいかなる追加的な命令が、たとえばROMから、および／または一つもしくは複数のローカルもしくはリモートの大容量記憶装置からロードされてもよい。今の例示的実施形態では、VMM６４は、それぞれが自分の独立したゲストOSを走らせる複数のVM ６０Ａ〜６０Ｃをサポートする。VMの一つまたは複数は、信頼されるソフトウェア・スタックまたはTCG規格に準拠したTCGソフトウェア・スタック（TSS: TCG software stack）を走らせうる。

この開示の目的のためには、さまざまなvTPM、メーカー独自vSCおよび同様な仮想デバイスは、デバイス・モデル（DM: device model）と称されうる。今の例示的実施形態では、そのようなデバイス・モデルはGVTPMフレームワーク４０によってサポートされる。さらに、GVTPMフレームワーク４０は複数のDM設計をサポートしうる。たとえば、図３に関してのちにより詳細に述べるように、GVTPMフレームワーク４０があるDM設計に基づく複数のvTPMを生成し、GVTPMフレームワーク４０が別のDM設計に基づくメーカー独自のvSCを生成してもよい。こうして、異なる型のセキュリティ・コプロセッサの仮想化を容易にするために、異なるDM設計が使用されてもよい。GVTPMフレームワーク４０はこのように、セキュリティとパフォーマンスの種々の兼ね合いをもって、vTPMおよび他のvSCをサポートしうる。vSCはvTPMに限定されないので、GVTPMフレームワーク４０はまた、仮想セキュリティ・コプロセッサ（vSC）フレームワークとも称されうる。

図１に示されるように、ある実施形態では、処理システム２０は、一つまたは複数のVM定義４１、５１を含むデータ記憶装置２８を含む。ある実施形態では、VM定義はハードディスク・ドライブ（HDD）上に存在してもよい。代替的な実施形態では、VM定義は他の型の記憶装置に存在してもよい。たとえば、VM定義はリモート・システムから取得されて、RAM２６中またはプロセッサ２２のキャッシュ・メモリ中にロードされてもよい。VM定義は、仮想機械内に含まれるべき属性を定義しうる。たとえば、VMM６４がVM６０Ａを生成すべきであると判定するとき、処理システム２０は、VM定義４１をブート・ブロックのように扱い、GVTPMフレームワーク４０はVM定義４１を測定し、次いでVMM６４は制御をVM定義４１内の初期化命令またはブート・コードに渡しうる。VM６０Ａは、少なくとも部分的には、そのブート・コードの実行を通じてインスタンス生成されうる。具体的には、vTPM４４Ａは、VM定義４１内の制御論理および／または初期化データに基づいてVM６０Ａのために生成されうる。のちにより詳細に述べるように、その制御論理は、vTPMを実装するためのプログラム・コード・セグメント（PCS: program code segment）を構成または包含しうる。同様に、対応するPCS５５をもつVM定義５１は、VM６０Ｃおよび対応するvSC４４Ｃを生成するために使用されうる。

今の例示的実施形態では、GVTPMフレームワーク４０は、保護されたホスト・メモリから動作する。たとえば、処理システム２０は、米国特許第6,507,904号；第6,633,963号；および／または第6,678,825号（すべてインテル・コーポレイションに譲渡されている）に記載されたもののような技術を使って、GVTPMフレームワーク４０をメモリの孤立領域にロードし、該孤立領域からGVTPMフレームワーク４０を実行しうる。該孤立領域は、他のパーティション内のソフトウェアからのアクセスや工作からハードウェアによって保護されている。たとえば、ある環境は、保護されたメモリを提供するシステム管理モード（SMM: system management mode）を含んでいてもよく、保護された実行環境は耐タンパー性のソフトウェア・コンパイラを使って生成できる。その他のコンポーネント（たとえば、VMM６４、マイクロカーネルなど）も保護されたメモリ領域に存在していてもよい。今の例示的実施形態では、保護されたメモリは、ソフトウェア／命令が、干渉または観察されることなく走ることができることを保証する。

保護されたメモリはまた、権限のないプログラムが機微な情報にアクセスしたり、工作したりすることを防止するはたらきもしうる。たとえば、のちにより詳細に述べるように、GVTPMフレームワーク４０は、VM６０ＡのためにハードウェアTPMをエミュレートするために仮想TPM４４Ａを生成しうる。GVTPMフレームワーク４０は、vTPM４４Ａの構造に保存されているデータを保存し、保護するために保護されたメモリを使用しうる。

図３に示されるように、GVTPMフレームワーク４０は、プロテクト記憶サービス（PSS: protected storage service）１００を含んでいてもよく、PSS１００はTPM３０を使用して、vTPMが走っていないときでさえvTPMを保護しうる。たとえば、vTPMがアクティブに動作していないとき、そのvTPMのための持続的なデータ構造はディスク上に記憶され、親SRKをもつvTPMサービスのPCRに封印されうる。

今の例示的実施形態では、vTPM４４Ａは、単一のユーザー権限付与セッションのもとで、自分自身とhwTPM３０の両方から、TPM機能を透明に提供できる。vTPM４４Ａはこの目的を、ユーザーおよびhwTPMの両方について別個の権限付与セッションを維持することによって達成する。すなわち、ユーザーは、あたかもvTPM４４ａがhwTPMであるかのように、vTPM４４Ａについての権限付与セッションを生成するのである。vTPM４４Ａは、このセッションに基づいて、hwTPMがするはずの同じ権限付与検査をすべて完遂しうる。vTPM４４Ａが要求された機能を直接提供できるならば、vTPM４４Ａは単にセッション・ノンスを更新し、返答すればよい。vTPM４４Ａがサービスを提供するためにhwTPMを必要とするならば、vTPM４４Ａは権限付与セッションを生成し、あるいはその要求をするhwTPMについての既存の権限付与セッションを再利用する。ひとたびhwTPMを使ってvTPM４４Ａができたら、vTPM４４Ａはユーザーのセッションのノンスを更新して返答すればよい。

今の例示的実施形態では、GVTPMフレームワーク４０は、信頼できる仮想TPM（vTPM）４４Ａおよび４４Ｂのための、および／またはvSC４４Ｃのような他のTPM様仮想コンポーネントのための実行環境を提供する。vSC４４Ａ〜４４Ｃによって使用される機微なデータを保護するために、GVTPMフレームワーク４０はTPM３０を使って、vSCの信頼性がTPMを使うソフトウェアの期待を満足するハードウェアにおいてアンカーされることを保証する。この開示の目的のためには、仮想TPMおよびvTPMの用語は、物理的なTPMのソフトウェア・エミュレーションまたはシミュレーションならびに類似の種類のセキュリティ・サブシステムのソフトウェア・エミュレーションを指すのに使われる。

GVTPMフレームワーク４０は、ゲストOSやゲストOS上で走るアプリケーションへの修正を要することなく、複数の互いに信頼しないおよび／または互いに気づいていないゲストがTPMを共有することを許容しうる。さらに、GVTPMフレームワーク４０は、向上された独自機能をもつカスタム暗号サブシステムを生成するための必要な環境を提供する特徴を含んでいてもよい。この開示はまた、GVTPMフレームワーク４０のようなフレームワークのもとで仮想化を最適化するための追加的なTPM特徴をも記述する。

一つまたは複数の例示的な実施形態のこの詳細な記述の残りの部分は次のようになっている：「セキュリティ背景」の節は、TPMについての背景を与える。「一般化された仮想TPMフレームワーク」の節は例示的なフレームワークを論じた。「例示的なvTPMデバイス・モデル設計」の節は、二つの例示的なvTPM設計または設計モデルを記述する。「ハードウェア最適化」の節は、TPM仮想化を容易にしうる例示的なハードウェア特徴を記述する。それに続くのが「仮想TPMのリモート展開およびプロビジョニング」について、および「仮想TPMの移行」についての節である。

１．０ セキュリティ背景
１．１ TPM機能的な序説
業界団体TCGはTPMを、プラットフォーム上での信頼の基盤を提供する見込みのある小さな暗号サブシステムとして標準化している。この目的に向け、TPMは構成証明および保護された記憶を容易にするための機能を提供する。

TPMの機能性のコアは、プラットフォームの構成についての情報を記憶できることにある。この情報は、次いで、TPMの主たる機能の両方のために使用できる。プラットフォームは、リモート・エンティティに対して、該リモート・エンティティがプラットフォームの信頼性について判断できるようにするのに必要な情報を提供できる。プラットフォームはまた、TPMに、鍵または機微なデータが放出されるのがシステムがある既知の「良好な」構成にあるときのみであることを保証するよう命令もできる。

プラットフォーム状態を保存するために、従来のTPMは、プラットフォームについてのソフトウェアおよび構成情報の測定結果を、PCRを使って、160ビットSHA1（secure hashing algorithm 1［安全なハッシュ・アルゴリズム１］）ハッシュの形で保存する。これらの測定結果はブート・ブロックで始まる。各ブート・コンポーネントが次を測定し、それをTPMに記録し、次いでそのコンポーネントを立ち上げることを、オペレーティング・システムがそのコアの測定結果を引き継ぐまで続ける。PCRへの書き込みのたびに、以前の測定結果を上書きするのではなく、レジスタに測定結果が追加されるので、いかなるエンティティも、先行コンポーネントによって作られたコードの測定結果を変更はできない。こうして、連鎖の始まり（測定のための信頼のルートとして知られる）と各リンクが信頼できれば連鎖全体が信頼できるような測定結果の連鎖が作られる。

１．２ 構成証明
構成証明（attestation）とは、プラットフォームがその構成（configuration）をリモート当事者に信頼できる仕方で報告できるようにする、TPM機能およびプロトコルの組をいう。たとえば、TPMは、プラットフォーム状態を保存するのに使われるPCRに署名する能力を提供する。たとえば、プラットフォームはPCRに署名するのに、構成証明素性鍵（AIK: attestation identity key）を使用しうる。そのような署名されたPCRは引用（quote）と称されうる。

引用が本物のTPMによって署名されたことの証明をリモート・エンティティに提供するため、各TPMは一組のクレデンシャル（credential）を有する。たとえば、TPM製造業者によって署名された裏書きクレデンシャル（endorsement credential）は、TPMがTPM規格を満たすことを述べる。製造業者はまた、裏書き鍵（EK: endorsement key）として知られる一意的な鍵をTPMに保存し、製造業者はEKを使って裏書きクレデンシャルに署名する。理論的には、EKはPCRの引用に署名するために直接使えるが、EKは一意的なので、プライバシーを提供するために第三者が使用される。具体的には、プラットフォームは、プライバシー証明機関（CA: certification authority）として知られる第三者を使って、各AIKについて素性クレデンシャル（identity credential）を生成する。TCGは、TPMがプライバシーCAに対して、EKおよび裏書きクレデンシャルを使って、該TPMが本物のTPMであることを証明できるようにするプロトコルを定義している。プライバシーCAのほうは、TPMが所有していると主張するAIKについての素性クレデンシャルを生成する。

リモート・エンティティが測定のためにTPMの製造業者、プライバシーCAおよび信頼の根幹を信頼すると想定すると、素性クレデンシャルが付随するAIKによって署名された引用は、プラットフォームの現在状態の暗号学的な証明である。たとえば、図１に示したのと同様のネットワーク環境において従来の構成証明アプローチが使われたとすると、プライバシーCA７６のようなリモートの処理システムは、従来のTPMのAIKについて素性クレデンシャルを提供でき、処理システム２０はその素性クレデンシャルを使って、チャレンジャー７８のようなリモートの処理システムに対する信頼性主張（trustworthiness assertion）をすることができる。しかしながら、のちにより詳細に述べるように、本開示は、たとえば処理システム２０のようなデバイスにおける、仮想機械６０Ａ〜６０Ｃのようなパーティションのための仮想セキュリティ・プロセッサまたは仮想TPMをサポートする修正された構成証明アプローチをも導入する。

図２は、TPM３０のような例示的なTPMを、TPM仮想化のような機能をサポートするさまざまな構造および鍵に関して、描いたブロック図である。図２には、TPM３０のEKがhwEK５２として示され、記憶装置ルート鍵（storage root key）はhwSRK５０として示され、TPM製造業者によって提供される裏書きクレデンシャルがEK_Cred５４として示されている。図２はまた、記憶装置３８内のPCR３２およびDIR３６をも描いている。

１．３ 安全な保管
TPMが提供するもう一組のサービスは、鍵その他のデータの安全な保管である。TPMは、リヴェスト‐シャミール‐アドルマン（RSA）鍵を生成できる。TPMはRSA鍵の使用を、（ａ）要求者が秘密のSHA1ハッシュを介して権限付与を提供し、（ｂ）PCRによって決定される現在の構成（configuration）が「良好な」状態を指示して初めて許可する。この強力な機能は、プラットフォームがデータを暗号化し、その機械が危殆化されたり、外部媒体からブートされたり、他の仕方で工作されたりしてもそのデータがアクセス不能のままであるようにすることを許容する。

安全な保管のようなサービスをサポートするため、TPMは種々の動作について、単一目的の型の鍵を生成する。型EKの鍵は、プライバシーCAからの素性クレデンシャルを解読するためにのみ利用可能である。AIKは他の鍵に署名し、PCRを引用するために使用される。記憶装置鍵（SK: storage key）は他の鍵を保護するため、あるいはデータを「封印する（seal）」ために使用される。これは、パスワードまたはPCRバインドによりデータを保護する特殊なデータ暗号化である。バインド鍵（BK: binding key）は任意データを暗号化するため、およびデータをTPMバインドされたデータ構造に変換するために使用される。署名鍵（SigK: signing key）は任意のデータに署名するために使用される。最後に、レガシー鍵は、データに署名するかデータを暗号化することができ、該データがTPMバインドされたデータ構造の形であることは要求しない。

各TPMは二つのコア鍵を有する。EKおよび記憶装置ルート鍵（SRK）として知られる特殊な型のSKである。SRKは、システムまたはユーザーによって生成されることができる、鍵の階層構造の頂点である。この階層構造は、枝としての記憶装置鍵および葉としてのEK型以外の他の任意の型の鍵の上に構築される。この階層構造中の鍵のうち、SRKおよびEKだけが、常時TPMにロードされていることが要求される。他の鍵は、「包装鍵（wrapped key）」として暗号化されてTPMの外部に保存されていて、使用に先立ってロードされるのでもよい。包装鍵についてはのちにより詳細に述べる。ひとたび鍵がロードされると、鍵型が動作のために正しくて、適正な権限付与が与えられており、PCRが鍵によって指定されるいずれかのPCRバインドに一致していれば、いかなる機能でも実行できる。

１．４ TPMコンポーネント
TPM、スマートカード、インターナショナル・ビジネス・マシーンズ社からのモデル4758暗号コプロセッサおよび他の同様のデバイスまたはサブシステムは、本質的には、耐タンパー性のような境界保護を一般に含む小さな自己完結したコンピューティング環境である。よって、そのようなデバイスは動作のための外部資源に頼ることなくある種の計算を行うと信頼できる。

典型的なTPMは次の４つのコンポーネントを含んでいる。

１．プログラム・コード・セグメント（PCS）：TPMの制御論理のコード・セグメント、これは典型的にはROM内にあり、読み出し専用データとして保存されている。

２．プロセッサ：PCSを実行する小さなCPU。

３．不揮発性メモリ（NVメモリまたはNVM）：NVMは、持続的な鍵、秘密情報およびTPMの他の状態が保存されるTPM内の記憶装置。典型的には、耐タンパー性のフラッシュ内に位置し、リスタートをまたいでも内容が保存される。

４．アクティブ・メモリ：電源を切ると失われる非持続性のデータを保存するために使われる揮発性メモリである。

これらのプリミティブから構築されるデバイスの技術的性能は、主としてその内的な資源によって制限される。実際上は、高い開発および展開費用を回避する努力の結果として、これらのデバイスは典型的には、データ保護のためには若干数の単純な汎用構造体しか含んでいない。たとえば、典型的なデバイスでは、単純な暗号化および復号機能が利用可能であるが、洗練されたアクセス・コントロール・ポリシーは利用可能ではない。ここに開示されるフレームワークは、同じ資源制約をもたず、開発および展開が安価な計算領域を提供することによってこの問題を軽減する。

２．０ 一般化された仮想TPMフレームワーク
図３は、例示的なGVTPMフレームワークのさまざまなコンポーネントおよび関係する項目を示すブロック図を呈示している。図示した実施形態では、GVTPMフレームワーク４０は、TPMコンポーネントのさまざまな機能上およびセキュリティの属性を提供する助けとなるいくつかのコンポーネントを含んでいる。

また、GVTPM PSS１００は、各DMのNVMのための中央貯蔵所としてはたらき、一方、プラットフォームのCPU２２およびRAM２６はプロセッサおよびアクティブ・メモリの資源を提供する。PSS１００は各DMの持続的データのための保護された記憶を提供するので、PSS１００は保護された持続性記憶とも称されうる。例示的な実施形態では、フレームワークがプラットフォームの残りの部分から保護されることを保証するため、GVTPMフレームワーク４０は、プラットフォームがCPU２２およびRAM２６の使用を孤立させるというセキュリティ要請を課す。孤立要請を満足させる一つの方法は、信頼される仮想機械モニタ（TVMM: trusted virtual machine monitor）内でコンポーネントを実装するか、あるいはTVMMを使ってGVTPMフレームワーク４０をそれ自身のVM内に孤立させることである。今の例示的実施形態では、VMM６４は一般にTVMMとして受け容れられている。代替的な実施形態は、NVMをPSS内に保存していなくてもよい。PSSはその代わり、上記のものと同様なNVMを暗号化してもよく、NVMをvSCに返してもよい。

さらに、vSC ４４Ａ〜４４Ｃのための生成、非アクティブ化および他の管理機能をGVTPMマネージャ１１０が提供し、vSC４４Ａ〜４４Ｃのためのクレデンシャルを得るために仮想製造機関（MA: manufacture authority）１２４、１２６が使用される。GVTPMフレームワーク４０はまた、鍵およびセッション・マネージャ１４０を含む。GVTPMマネージャ１１０はこれを、一つのvTPMがプロセッサ２２からアンロードされて別のvTPMがアクティブになる準備ができたときに鍵および権限付与セッションをスワップ・アウトするといったタスクのために使う。たとえば、ロードされているが現在プロセッサ２２上での実行のためにスケジュールされていないvTPMに属する鍵は、プロセッサ２２上で走るようスケジュールされている（またはまもなくスケジュールされる）vTPMによって必要とされる鍵のための余地を作るためにどけられてもよい。

今の例示的実施形態では、これらのコンポーネントに保存された秘密情報の安全性を保証するために、GVTPMフレームワーク４０のすべてのコンポーネントはシステムの残りの部分から孤立させられる。

２．１ GVTPMデバイス・モデル
GVTPMフレームワーク４０は、DM ４４Ａおよび４４Ｂを生成するためにVM定義４１を使用してもよく、GVTPMフレームワーク４０は、DM４４Ｃを生成するためにVM定義５１を使用してもよい。GVTPMフレームワーク４０は、DMを提供または使用するときに、仮想化イベント（VE: virtualization event）を使用してもよい。たとえば、VM６０Ａ内のソフトウェアがあるTPMにアクセスしようとするとき、VEがトリガーされうる。VEに応答して、制御はVM６０ＡからVMM６４に移されてもよい。GVTPMマネージャ１１０は、vTPM４４Ａを参照することによってイベントを処理するためにVEに割り込んでもよい。今の例示的実施形態では、VM ６０ＡはvTPM４４Ａ以外のいかなるTPMにも気づいていないかもしれないが、GVTPMマネージャ１１０はvTPM４４ＡをサポートするためにhwTPM３０を使ってもよい。

実際には、DMは，VM６０Ａ〜６０ＣのようなOSパーティションにまでGVTPM機能を拡張する。各DMの保護境界は、TVMMのようなそれが実行されている環境によって与えられる。境界を各GVTPMコンポーネントおよび各DMのまわりに個々に置くことにより、各DMは別のDMが危殆化された場合にも孤立性を維持する。したがって、デバイス・モデル設計に従ってDM内に実装されるデータ構造は、そのデバイス・モデルの耐タンパー性構造と考えうる。

フレームワークの設計は、デバイス・モデルの設計における柔軟性を許容する。たとえば、VMMによって許容されるいかなる機能性も、DM内で走ることができる。これは典型的なハードウェアSCによってサポートされる限られた機能性と対照的である。メーカー独自の機能性の場合には、フレームワークの柔軟性は、幅広い多様な暗号化アルゴリズム、署名方式、アクセス・コントロール・ポリシーおよび記憶機構を許容する。

今の例示的実施形態では、仮想TPMについて、各DMは自分のTPM構造および資源の組を管理する。それには自分のEK、SRK、PCR、DIR、単調カウンタ、ユーザー鍵階層構造、汎用NVMなどが含まれる。これは、vTPMがハードウェアTPMと同一に機能し、アプリケーションがハードウェアTPMまたは仮想TPMのいずれをも透明に使用しうることを保証するようにできる。

今の例示的実施形態では、vTPM４４Ａは、ソフトウェアを使って、シミュレートされた持続的な単調なカウンタを提供する。カウンタの数は実質的に無制限である。今の例示的実施形態では、vTPM４４Ａは、hwTPMから期待される４つのカウンタを少なくとも提供する。vTPMカウンタは、ハードウェアTPMカウンタへのいかなる直接的リンクも要求しなくてもよい。

vPCR９２のような仮想PCRは、hwTPMの資源制約をもたず、代わりに、構成設定可能な数のPCRを利用可能な状態でもちうる。今の例示的実施形態では、vPCR９２は、PSS１００内のvTPM４４Ａのメモリ空間内に保存され、vTPM４４ＡはvPCR９２上で標準的なPCR動作をエミュレートする。

フレームワークは、個々のDM設計が、パフォーマンスとセキュリティをバランスさせることができるようにする。いくつかの実装は、DM内にソフトウェアで鍵を実装することにより、より高速な暗号化動作あるいは向上された移行（マイグレーション）を享受してもよい。その一方、他の実装はすべての鍵が常にハードウェアTPM内に存在し、DMが鍵へのポータルとして作用することを要求してもよい。さらに、このアプローチは透明な仕方で、種々のDM設計が、種々の地理のデータ保護および暗号法則を一致させるよう自らのサービスを調整することを許容する。

のちにより詳細に述べるように、GVTPMマネージャ１１０は、各DM設計のために異なる仮想製造業者機関（vMA: virtual manufacturer authority）を提供しうる。たとえば、図３で、仮想製造業者機関１２４は、VM定義４１によって提供されるDM設計に基づくDMにサービスし、仮想製造業者機関１２６は、VM定義５１によって提供されるDM設計に基づくDMにサービスする。

２．２ GVTPMマネージャ
GVTPMマネージャ１１０はGVTPMフレームワーク４０のための中央管理コンポーネントである。今の例示的実施形態では、GVTPMマネージャ１１０は、vTPMプロビジョニング、他のフレームワーク・コンポーネントをブリッジすることおよび諸DMのためのTPM３０へのシリアル化されたアクセスを承認することを担う管理コンポーネントである。ある実施形態では、GVTPMマネージャ１１０は、VMM６４が（ａ）必要なVMを生成し、（ｂ）通信チャネルを提供することを要求することによって新しいDMをプロビジョンする。新しいDMをプロビジョンするプロセスの間に、GVTPMマネージャ１１０は、DMコードの測定結果など、PSS１００が該DMを認証するために要求するあらゆる情報を収集する。たとえば、GVTPMマネージャ１１０は、問題のDMをインスタンス生成するための基礎としてのはたらきをする特定のVM定義内でPCSを測定しうる。たとえば、VM定義４１は、TPMのある特定の型またはモデルのためのPCS４５を含みうる。その一方、VM定義５１は、スマートカードのある特定の型またはモデルのためのPCS５５を含みうる。ある実施形態では、処理システムによってサポートされるべき異なるDM設計のそれぞれは、完全にまたは主としてVM定義内のPCSによって定義される。

GVTPMマネージャ１１０は、各特定のOSパーティションと個別DMとの間の通信チャネルを提供しうる。GVTPMマネージャ１１０はまた、自分自身と各DMとの間の通信チャネルをも提供しうる。GVTPMマネージャ１１０はDMに他のGVTPMコンポーネントへのアクセスを提供する。他のGVTPMコンポーネントへのアクセスとは、仮想製造業者機関へのアクセス、PSS１００へのアクセスおよびhwTPM３０へのシリアル化されたアクセスなどである。したがって、GVTPMマネージャ１１０は複数のDMにまたがってhwTPM３０を共有することを担う。管理下にある主要な資源は、ロードされた鍵および権限付与セッションの組である。上記のTPM規格参考文献の「コア・サービス」の部分において提案されているような共有技法がこのタスクのために適合しうる。

今の例示的実施形態では、GVTPMマネージャ１１０は、同時には一つのvTPMしかTPM３０にアクセスしないことを保証する。さらに、GVTPMマネージャ１１０は、鍵および権限付与セッションをTPM３０にスワップ・インし、TPM３０からスワップ・アウトして、各vTPMが必要とする資源をもつことを保証する。

２．３ GVTPMプロテクト記憶サービス
DMにおける柔軟性を維持するため、GVTPMフレームワーク４０は、各DMがどのように機能するかに対して、比較的少数の要求しか課さない。ある実施形態では、唯一の要求は、すべての持続性データ（たとえば、鍵、カウンタ、NVMデータおよびシステム・リブートをまたいで機能するためにvTPMが必要とする他の任意の状態）がNVMからアクティブ・メモリにロードの際にコピーされ、次いで必要なときにNVMに保存し戻されるということである。この要求によれば、PSSは、DMが動作していない間、DMのNVMを保護することを担う。DMがロードしたあとは、DMが実行されている間、データの孤立化および保護を提供するのはTVMMの責任となる。

今の例示的実施形態では、PSS１００はvTPMを認証し、vTPMの状態が、その状態を以前に保存していたvTPMにのみロードされることを保証する。PSS１００はまた、保存された状態の完全性（integrity）を保証し、リプレイに対する保護を提供する。各DMについてオフラインNVMを保護するため、PSS１００は、TPM３０に根ざす強力な認証および保護機構を提供する。この認証は、以前にそのNVMを保存したDMのPCSを識別し、そのNVMが保存されて以降にそのPCSが工作されていないことを保証する。そのNVMをロードしているPCSを認証することに加えて、TPMは、TVMM、GVTPMマネージャ１１０およびコンポーネント孤立化を損なう能力のある他の任意のコードがそのNVMが保存されて以降、工作されていないことを保証することも重要である。

これをするため、今の例示的実施形態では、GVTPMコンポーネントのハッシュがTPM３０内のPCR中に記憶される。根底にある信頼されるコンピューティング・ベース（TCB: trusted computing base）中にあるあらゆるソフトウェアのハッシュも同様である。一般に、TCBの用語は、処理システムの基本的セキュリティ・ポリシーに影響できる処理システムのコンポーネントをまとめて指す。たとえば、TCBはハードウェア、ブート・コード、カーネル、システム動作を制御する構成（configuration）ファイルおよびカーネルまたは構成ファイルを変更する特権またはアクセス権をもって走ることのできる任意のプログラムを含みうる。今の例示的実施形態では、TPM３０は、GVTPMコンポーネントまたはTCBの工作を検出し、秘密情報の不適切なDMへの開示を防止し、適正なメモリ保護がまだなされていることを保証する。

２．３．１ NVMの保存
今の例示的実施形態では、ある動作によってあるDMのNVMが変わるときは常に、そのDMはPSS１００に対してそのNVMを保存するよう要求を発する。代替的な実装では、DMは、そのNVMの保存を遅らせるよう設計されることもできる。保証（assurance）が低下する可能性を代償としてパフォーマンスを上げるためである。

PSS１００がNVMを受け取るとき、NVMは不透明なデータとして到着する。NVMデータが不透明と考えられるのは、PSS１００が受け取ったNVMデータを解析しないからである。PSS１００は単にノンスを生成し、次いでそのNVMデータおよびノンスを暗号化すればよい。今の例示的実施形態では、PSS１００は自分の移行不能なTPM鍵を使って前記暗号化を実行する。この鍵は、プラットフォームTCB、GVTPMマネージャ１１０およびPSS１００の測定結果に設定されたそのPCRバインドを有する。PCRバインドを使うことによって、TPM３０は、このブロブ（blob）がその鍵で復号できるのは、TCBおよびGVTPMマネージャ１１０が修正されていない場合のみであることを保証する。PSS１００は次いで暗号化されたNVMブロブのコピーをDMに与えうる。

ひとたびNVMブロブが保存されると、PSS１００はDMを測定し、PSS１００はDMの測定結果、NVMブロブの素性およびノンスを持続的データベースに記録する。ブロブのハッシュは、良好な一意的な識別子のはたらきをしうる。このDMが以前に保存された状態を有していれば、PSS１００は古いレコードを新しいレコードで上書きしうる。

２．３．２ NVMの復元
今の例示的実施形態では、DMが始動するとき、DMはその以前に保存されたNVMがPSS１００によって復元されることを要求する。応答して、PSS１００は、PSS１００がそのレコードをデータベースで探索できるよう、まずそのブロブのための識別子を計算する。次に、PSS１００は、DMを測定し、DM測定結果がレコードにあるものと一致することを検証する。次いで、PSS１００はそのTPM鍵を使ってブロブを復号し、中のノンスを検証する。

今の例示的実施形態では、NVMを復元する前に、PSS１００は５つの条件を保証する：
・NVMは要求しているDMに対応する。
・NVMはそのDMについての最も最近のNVMである。
・NVMは保存以降修正されていない。
・NVMブロブはPSS１００によって生成された。
・そのNVMが保存されて以来TCBが変化していない。

DM測定結果の比較により条件１が満たされることが保証される。探索成功および復号成功の組み合わせが、条件２および３も真であることを示す。秘密のノンスを含んでいることは、そのPSSがこのブロブを生成したことと、そのPSSの公開鍵を使っての偽造ではないこととを示し、よって条件４を保証する。最後に、PSS TPM鍵を使って復号を行うことに成功したことは、GVTPMフレームワークおよびTCBが両方とも以前と同じ状態にあることがTPMによって検証されたことを示す。

ひとたび５つすべての条件が検証されれば、不透明なNVMがDMに返され、DMはその初期化を経ていく。

２．４ 仮想製造業者機関
多くの場合、ある所与の鍵が、ある所与のGVTPM環境内に存在するあるDM中に存在している証拠を有することが貴重である。ハードウェアTPMの場合には、TPM製造業者が、EKがTPM内で保護されていると述べる裏書きクレデンシャルに署名し、プラットフォーム製造業者が、TPMがTCG準拠プラットフォーム内に存在していると述べるプラットフォーム・クレデンシャルに署名する。GVTPMフレームワーク４０では、各仮想製造業者機関が同様な仕方ではたらき、鍵が、TCG準拠プラットフォーム内のGVTPMフレームワーク４０内のある特定のデバイス・モデルに準拠するあるDM内に存在することを証明する。

実際上は、GVTPMフレームワーク４０は、信頼された証明機関が、TPM製造業者およびプラットフォーム製造業者の地位を仮想製造業者機関に委任する（delegate）ことを許容する。ある例示的な実施形態では、仮想製造業者機関は、TPM製造業者、プラットフォーム製造業者またはその両方としてはたらくプラットフォーム上の測定可能なソフトウェアである。仮想製造業者機関は、仮想化を使ったプラットフォームが、構成証明のために要求される適切なクレデンシャルをもった新たなvTPMを安全に生成することを許容する。

図５は、vTPMのためのセキュリティ構成証明を提供するよう仮想製造業者機関を用意する例示的なコンポーネントおよび動作を示すブロック図である。図５では、処理システム２０のハードウェアはまとめてプラットフォーム・ハードウェア２５２として描かれている。そのハードウェアはTPM３０を含む。該ハードウェアの上で走るのが一つまたは複数の信頼されるパーティションである。ある実施形態では、これらのパーティションはVM６０ＡおよびvMAパーティション２５４を含む。VMM６４は第三の別個のパーティション内で動作しうる。前記パーティションのうちの一つまたは複数は、たとえば仮想機械として実装されうる。代替的な実施形態では、コンポーネントのうちの一つまたは複数が保護されたパーティションを共有できる。

今の例示的実施形態では、仮想製造業者機関は信頼されるコンポーネント内の処理システム２０上でローカルに存在する。たとえば、仮想製造業者機関１２４は信頼されるVMM６４内またはVMM６４によってサポートされる信頼されるパーティション２５４（たとえば信頼されるVM）中に存在しうる。しかしながら、代替的な実施形態では、仮想製造業者機関は、該仮想製造業者機関が測定されることができ、その測定結果があるプラットフォームのTPMに保存されることができる、ファームウェアまたは他のいかなる保護パーティション中に存在していてもよい。vTPMはまた、信頼されるコンポーネント内で処理システム２０上にローカルに存在する。たとえば、今の例示的実施形態では、vTPM４４Ａは、VM６０Ａ内に存在する。

各仮想製造業者機関は、TPMクレデンシャルに署名するために使われる、TPM３０内の署名鍵２５０を生成する。今の例示的実施形態では、仮想製造業者機関１２４からの証明を有意なものにするためには、仮想製造業者機関１２４はまず、仮想製造業者機関１２４の構成が信頼でき、仮想製造業者機関１２４の署名鍵がTPMによって保護されていることを第三者（たとえば外部CA）に説得する。この第三者は、仮想製造業者証明機関（VMCA: virtual manufacturer certifying authority）と考えられる。本質的には、VMCAは、どのGVTPM環境が信頼できる仮想TPMを製造するのに十分信頼できるかを決定するための、プライバシーCAによって信頼されるエンティティである。同じエンティティがプライバシーCAおよびVMCAとしてはたらくこともでき、あるいは図１に描かれるように、プライバシーCA７６とVMCA７７は別個のエンティティで、プライバシーCA７６がVMCA７７を、vSCフレームワークおよびDMを正確に評価するものと信頼しているのでもよい。

今の例示的実施形態では、処理システム２０がVMM６４を立ち上げるとき、およびVMM６４がパーティション２５４を生成して仮想製造業者機関２４をそのパーティションにロードするとき、PCR３２中の値は、矢印２７０および２７１によって示されるように、プラットフォームの進化を反映するよう修正される。

矢印２７２によって示されるように、次いで仮想製造業者機関１２４は、TPM署名鍵２５０を生成する。生成されるTPM署名鍵２５０は、仮想製造業者機関１２４および仮想製造業者機関１２４の完全性に影響する任意のソフトウェアの状態にバインドされている。該ソフトウェアは、GVTPMフレームワーク４０、VMM６４およびPCR３２中に反映されるようなTCB中の他の任意の構成要素といったものである。次いで仮想製造業者機関１２４は、VMCA７７に対して、TPM３０が仮想製造業者機関１２４以外のいかなるエンティティにもそのTPMの署名鍵にアクセスすることを許容しないということを証明する。

仮想製造業者機関およびTCBの状態へのバインドは、仮想製造業者機関１２４がGVTPMフレームワーク４０内に具現されるポリシーに従って動作することを証明する。仮想製造業者機関１２４はこうして、該仮想製造業者機関１２４が指定されたプラットフォームおよびソフトウェア構成によって制御されることを証明する。したがって、署名鍵２５０は暗黙的に、GVTPMフレームワーク４０によって生成されたいかなる仮想TPMも、GVTPMフレームワーク４０内に具現されるポリシーに従って動作することを検証する。するとVMCA７７は、その環境が信頼できるかどうかを、たとえば承認された環境のリストを参照することによって、判断できる。

たとえば、図３の仮想製造業者機関１２４は、仮想製造業者機関１２４のための署名鍵２５０がTPM３０内に存在しており、仮想製造業者機関１２４にとって利用可能になるのが処理システム２０が署名鍵が生成されたときと同じ構成にある場合のみであることを、VMCA７７に対して証明するためのプロトコルを使ってもよい。そのようなプロトコルの一例は、仮想製造業者機関１２４がTPM３０内でAIKを生成することである。標準的なチャネルを通じて、仮想製造業者機関１２４は次いでこの鍵についての素性クレデンシャルを取得する。該素性クレデンシャルはプライバシーCAによって署名されており、その素性鍵によってなされるいかなる主張も信頼されるTPMによってなされていることの証明である。この素性鍵は次いで、署名鍵２５０を証明するために使用される。これは、TPM３０がその素性鍵を使って、その署名鍵が同じTPM内に位置しており、その署名鍵が、仮想製造業者機関１２４をサポートする環境のための信頼を保証する指定された構成にバインドされているという陳述に署名するというプロセスである。この陳述が、その素性が本物のTPM内にあると述べる素性クレデンシャルと組み合わされると、仮想製造業者機関１２４の署名鍵２５０は正当なTPMによって保護されており、仮想製造業者機関１２４の動作のために信頼を提供する指定された構成においてのみ利用可能であることが導かれる。

ひとたび仮想製造業者機関１２４によって、VMCA７７が、仮想製造業者機関１２４がある特定の構成にバインドされたTPM署名鍵を有しているとの確信に至ると、VMCA７７はその構成が信頼されるに十分安全かどうかについて、情報に基づく判断をする。この構成が十分信頼できるとみなされる場合、VMCA７７は、署名鍵の公開部分を用いて証明書を生成する。その証明書は、VMCA７７が、裏書きクレデンシャルおよびプラットフォーム・クレデンシャルに署名する権限を、仮想製造業者機関の署名鍵に委任したことを述べるものである。証明書は、VMCA７７の判断を信頼する他のCAのネットワークを通じてプッシュされる。

ある仮想製造業者機関のクレデンシャル上および該仮想製造業者機関によって署名されたクレデンシャル上の有効期間は、GVTPMフレームワークとそのTCBの吟味がどのくらい包括的だったかに相応しそうである。GVTPMフレームワークまたは根底にあるTCBにおける脆弱性の発見は、GVTPM DMにおける信頼の除去につながるはずである。そのような状況下では、VMCA７７は、その仮想製造業者機関への委任を撤回したくなり、典型的には他のCAのネットワークに対して、VMCA７７がもはやその仮想製造業者機関を信頼しないことを通知するであろう。たとえば、仮想製造業者機関１２４に権限を委任したのちに、VMCA７７がその後、仮想製造業者機関１２４および／またはそのvTPMアーキテクチャの構成が脆弱であると判定した場合には、VMCA７７はその委任を撤回する。

VMCA７７が仮想製造業者機関１２４からの証明を受け容れたのちは、仮想製造業者機関１２４は、vTPM４４Ａのような仮想TPMの信頼性を構成証明するために、署名鍵２５０を使用してもよい。具体的には、今の例示的実施形態では、矢印２７４によって示されるように、仮想製造業者機関１２４は新たな裏書きおよびプラットフォーム・クレデンシャル２６０をvTPM４４Ａについての情報に基づいて生成し、仮想製造業者機関１２４はTPM３０からの署名鍵２５０を使って、VCMA７７とのさらなる相互作用なくそれらのクレデンシャルに署名する。したがって、その新しい署名２６２は証明書２６０に付加されて、矢印２７６で示されるように、完成した証明書２８０が生成される。完成した証明書２８０のような、仮想製造業者機関によって署名された証明書は、vMA証明書またはvMAクレデンシャルと称されうる。

すると、仮想TPM４４ＡはvMAクレデンシャル２８０を、あたかもTPM製造業者およびプラットフォーム製造業者によって署名されたハードウェアTPMについてのクレデンシャルであるかのように、使用しうる。したがって、処理システム２０は、vTPM４４Ａのような仮想セキュリティ・コプロセッサをリアルタイムで（すなわち、外部の処理システムからクレデンシャルを入手することにまつわる遅延なしに）生成でき、それでいて高いセキュリティ保証を与える。

上に示したように、今の例示的実施形態では、少なくともDMの各型は固有の仮想製造業者機関を有している。たとえば、ある特定のGVTPMフレームワークは、すべてのTPM DMについて一つの仮想製造業者機関を、メーカー独自のDM設計それぞれについては異なる仮想製造業者機関を含みうる。したがって、仮想製造業者機関１２４は、たとえばvTPM４４Ａおよび４４Ｂにサービスしうる。今の例示的実施形態では、処理システム２０がvTPM４４Ａのような新しいvTPMを生成するとき、GVTPMマネージャ１１０は仮想製造業者機関１２４に、新しいvTPMのための裏書き鍵を、必要な他の任意の情報とともに提供する。必要な他の任意の情報というのは、仮想製造業者機関１２４が、TPM３０に対するソフトウェア拡張およびvTPMアーキテクチャが存在するソフトウェア・プラットフォームを適正に識別する裏書きクレデンシャルおよびプラットフォーム・クレデンシャルを生成するために必要な情報である。その後は仮想製造業者機関１２４が、信頼されるCAによって裏書きされた署名鍵を使って、それらの裏書きクレデンシャルおよびプラットフォーム・クレデンシャルに署名することを担う。

上の諸段落は、仮想製造業者機関がTPMからの署名鍵および素性鍵を使って仮想製造業者機関の構成を構成証明する例示的実施形態を記載している。代替的な実施形態では、メーカー独自のセキュリティ・コプロセッサのような他の型のセキュリティ・サブシステムおよび他の型の鍵を使ってもよい。同様に、仮想製造業者機関についての構成が、事実上VMCAとしてはたらく外部のCAにとって受け容れ可能であることを検証するためには他のアプローチを使ってもよい。たとえば、外部のCAは、秘密情報を鍵で封印し、仮想製造業者機関が該秘密情報の封印を解けるのは、該仮想製造業者機関が所定の構成を有する場合のみであるようにしてもよい。外部CAが該秘密情報を該仮想製造業者機関に送信したのち、仮想製造業者機関の構成が所定の構成に一致していれば、仮想製造業者機関はその秘密情報の封印を解くことができる。次いで仮想製造業者機関は、該仮想製造業者機関が秘密情報の封印を解けたという証明を外部CAに送ってもよい。応答して、外部CAは要求された権限をその仮想製造業者機関に委任してもよい。次いで仮想製造業者機関は、委任された権限を使って、そのvTPMについてのクレデンシャルに署名してもよい。

次の諸段落は、VMCAから確認（acknowledgement）を得るために仮想製造業者機関が使うことのできる例示的なプロトコルならびにそのようなクレデンシャルを生成する例示的な方法を記述する。VMCAからの確認は、仮想製造業者機関に、TPMクレデンシャルおよび非TPMクレデンシャルに署名するために必要とされるクレデンシャルを提供しうる。

２．５ vTPMクレデンシャル
上に示すように、各仮想製造業者機関はまずTPM素性鍵（AIK）を生成し、TGC仕様に概説されているプロセスを使って信頼される第三者CA（TTPCA: trusted third-party CA）から素性クレデンシャルを取得しうる。TTPCAはたとえばTCGプライバシーCAでもよい。次いで仮想製造業者機関は、現在のプラットフォーム構成にバインドされたその署名鍵を生成する。たとえば、仮想製造業者機関１２４がTPM_CertifyKey動作を使うことにより、TPM３０が仮想製造業者機関のAIKを使って該署名鍵の属性に署名するようにしてもよい。署名鍵の属性とは、該署名鍵の移行能および該署名鍵がバインドされているPCRを含む。次いで仮想製造業者機関１２４は、CertifyKeyの結果を、素性クレデンシャルとともにVMCA７７に送りうる。

一般に、VMCA７７は、TCGプライバシーCAによって署名された素性クレデンシャルを信頼すべきである。クレデンシャルは、素性鍵が有効なTPM内に存在することを示し、CertifyKey証明書は署名鍵がその特定の仮想製造業者機関およびTCBにしか利用可能にならないことを示す。

ひとたびVMCA７７が、仮想製造業者機関１２４が信頼できると確信したら、VMCA７７はTPM製造業者の地位を仮想製造業者機関１２４に委任する。たとえば、VMCA７７は委任証明書を生成し、その証明書をTCGプライバシーCAに配布してもよい。

次いで仮想製造業者機関１２４は委任されたTPM製造業者の地位を使って、DM（たとえばvTPM４４Ａ）のための裏書きクレデンシャルおよびプラットフォーム・クレデンシャルを生成しうる。これらのクレデンシャル中のモデル・フィールドは、vTPM４４Ａが存在するハードウェアおよびソフトウェア・プラットフォーム両方を示しうる。ある実施形態では、裏書きクレデンシャルのために、モデル・フィールドはハードウェアTPMモデルおよびGVTPMマネージャ１１０を示す。プラットフォーム・クレデンシャルのためには、モデル・フィールドはハードウェア・プラットフォームおよびTCBを示す。TCBはVMM６４および同様のソフトウェアを含む。

２．６ 非vTPMクレデンシャル
TCG仕様に従わない独自DM（たとえばDM ４４Ｃ）は裏書きクレデンシャルやプラットフォーム・クレデンシャルをもたないはずである。もっとも、同様のクレデンシャルの恩恵を受けることはできるが。独自DMの開発者は、クレデンシャル発行というはっきりした目的のため、プライバシーCAと同様の独自の評価者サービスを運営しうる。それにより、開発者は、データが鍵で暗号化される前にその鍵が開発者のDMのインスタンス内にあることを保証できる。それをする正確なプロトコルは、完全に、その独自DMおよび該DMに対応する仮想製造業者機関を設計したエンティティ次第である。

３．０ 例示的なvTPMデバイス・モデル設計
本節は、vTPMを生成するための二つの例示的なDM設計を記述する。GVTPMフレームワーク４０のためには、これらはおおまかに、厳密なセキュリティからより高いパフォーマンスおよび柔軟性までに及ぶ範囲の両端に相当する。ソフトウェア・ベースのDMと称される第一のモデルは、ひとたびvTPMがTPMハードウェア内にアンカーされれば、ソフトウェアが完全なTPM機能性をVM内のOSに提供できる。あらゆる秘密鍵は、仮想TPMに保存されている他のすべてと同様、デバイス・モデルのメモリ内に保存されている。ハードウェア・ベースのDMと称される第二のモデルでは、あらゆる鍵はハードウェアTPMに保存されている。第二のモデルでは、鍵が使われるとき、デバイス・モデルはその鍵を使う要求をTPMに発する。第一のモデルでは、vTPMはTPMのパフォーマンス制限によって妨害されない一方、第二のモデルはたいていの要求にサービスするためにいまだハードウェアTPMに頼る。通常に機能している間の第一のモデルと第二のモデルの間のセキュリティ上の差は同一である。しかしながら、危殆化が発生したあとに結果として得られるシステムおよびその秘密情報の状態はモデル間で異なる。

プラットフォームのDMまたはVMMが危殆化される場合、DMのメモリ内に保存されているあらゆるデータが危殆化されうる。危殆化の間、両モデルは攻撃者がそのvTPM内の鍵を使うことを許容しうる。ひとたび脆弱性がパッチされて危殆化が終了すると、それらの鍵へのアクセスはハードウェア・ベースのDMにおいては打ち切られる。ところが、ソフトウェア・ベースのDMの場合には、秘密鍵はメモリ中で利用可能であったので、秘密鍵は恒久的に危殆化されたかもしれない。

たいていの環境では、ソフトウェア・ベースのアプローチは十分なレベルのセキュリティを達成できる。しかしながら、危殆化された鍵を失効させ、再生成するのがより高価な環境にあっては、危殆化が一時的となるハードウェア・ベースのアプローチが適切でありうる。これらの型の環境に含まれるものとしては、高性能で高度に耐タンパー性のTPMが重要な企業鍵を保護するために使用されるサーバーがありうる。提案されるフレームワークは、それらの選択を実装者に任せる。特定の実装の保証の必要性を満たすために好ましいアプローチを実装者が決定できるのである。たとえば、ある種の実装については、いくつかの鍵および／またはデータ構造を収容するのにTPMを使用するハイブリッド・アプローチが適切であることもある。

３．１ ソフトウェア・ベースのvTPMデバイス・モデル
完全にソフトウェア・ベースのvTPM DMはTPM機能性を提供するためにほとんどまたは全くハードウェアTPM資源を使用しない。ひとたびPSSおよびハードウェアTPMが、DMおよびTCBがDMのクレデンシャルに反映されているものと同じであると保証したら、DMはハードウェアTPMとは独立に機能するに任される。あらゆる仮想PCR、単調カウンタ、不揮発性記憶および他のTPM資源は、DMのメモリ内で保存され、管理される。

この設計の恩恵は、デバイス・モデルによって提示される機能性がいかなる形でも、ハードウェアTPMによって提供される機能性またはパフォーマンスによって妨げられないことである。より強い鍵、より多数の鍵スロットおよびより多くのPCRは、どれも簡単にサポートされる。さらに、典型的なハードウェアTPMは非常に資源的に制約されており、あまり高性能なデバイスではない。しかしながら、ソフトウェア・ベースのDMのパフォーマンスは、ハードウェアTPMのパフォーマンスに縛られない。たとえば、ソフトウェア・ベースのDMはバルク暗号化をサポートできる一方、通常のハードウェアTPMを用いたバルク暗号化はきわめて遅い。

３．２ ハードウェア・ベースのvTPMデバイス・モデル
vTPMデバイス・モデルの第二の例は、ハードウェアTPM内の保護された処理の使用を最大限にすることを試みる。ハードウェアTPM資源の主たる使用は、各DMについてのあらゆる鍵がハードウェアTPM内に保存され、秘密鍵が決してメイン・メモリに保存されないことである。

３．２．１ 鍵階層構造
この節は、ハードウェア・ベースのデバイス・モデルの例示的な実施形態において利用される全体的な鍵階層構造を記述する。この例示的な実施形態は、図３に示されるような、VM６０ＡのためのvTPMとしてはたらくDM４４Ａのコンテキストで記述される。

再び図２を参照すると、TPM３０は、通常通り、標準的な裏書き鍵（hwEK）５２および記憶装置ルート鍵（hwSRK）５０を維持している。さらに、鍵バインド鍵（KBK: key binding key）１６０として知られるAIKがvTPM鍵を保護するために使用される。

また、各DMは、各個別VMのためのハードウェアTPMをエミュレートするための適切な鍵およびデータ構造を有しうる。たとえば、例示的な実施形態では、DM４４Ａは、hwSRK５０を親鍵とする仮想EK（vEK）１５０および仮想SRK（vSRK）１５２をもつ。vSRKを親として、仮想署名鍵（vSigK）１５４、仮想記憶装置／暗号化鍵（vEncK）１５６および仮想素性鍵（vAIK）１５８がある。ハードウェアTPMをエミュレートするための各DMにおける追加的な構造は、仮想PCR（vPCR）９２および仮想DIR（vDIR）９４を含みうる。各DMはまた、仮想EKクレデンシャル（vEK_Cred）９６および一つまたは複数の仮想AIKクレデンシャル（vAIK_Cred）９８を含みうる。

図２の右下隅の凡例によって示されるように、記憶装置鍵は白い楕円として示されており、構成証明素性鍵（AIK）は横線のはいった楕円として示されており、署名鍵は網掛けのある楕円として示されている。さらに、太線の楕円は、TPM３０のPCR３２にバインドされた鍵を表す。鍵の間の線は、鍵の間の親子関係を示す。たとえば、これらの線は、SRK５０が各DM内のある種の仮想鍵についての親鍵であることを示している。クレデンシャルは平行四辺形で表されている。

ある実施形態では、仮想鍵およびvTPM内のその他の構造またはオブジェクトは、ハードウェアのTPM鍵またはオブジェクトと同じ構造を有していてもよいが、仮想TPM内の仮想オブジェクトは、EK５２、SRK５０およびPCR３２といったTPM３０内の標準的なオブジェクトへの単なる参照ではない。その代わり、のちにより詳細に述べるように、各仮想TPMは、vEK１５０などのような自分の別個のオブジェクトを獲得する。それらの仮想オブジェクトは、ハードウェアTPMのオブジェクトに基づく、またはそれから導かれるものでありうる。たとえば、今の例示的実施形態では、仮想SRKおよび仮想EKは、ハードウェアSRKの子、あるいはネストされたvTPMの場合には、究極的にはハードウェアSRKに基づく仮想SRKの子である。vTPM鍵がvSRKに根をもつことを許容することにより、このモデルはvTPMのネストを許容する。

vEK１５０、vSRK１５２およびvPCR９２といった仮想TPMオブジェクトのほうは、vSigK１５４、仮想AIK（vAIK）１５８および仮想記憶装置／暗号化鍵（vEncK）１５６といったDM４４Ａ内の追加的な仮想オブジェクトのための基礎としてはたらきうる。今の例示的実施形態では、各DMは、対応するハードウェア・デバイスによって提供される機能のすべてを、同じアプリケーション・プログラム・インターフェース（AIP）をもって提供しうる。たとえば、DM４４Ａは自分のvDIR９４、vPCR９２、vAIK１５８などを含んでいてもよい。結果として、各VM内のゲストOSは、対応するvTPMがhwTPMではないことに全く気づかないことがありうる。したがってVMはレガシーOSコードを使ってもよい。さらに、今の例示的実施形態によれば、通常のhwTPMをもつ処理システムは、hwTPMにいかなる修正も必要とすることなく、vTPMを提供するよう構成されうる。

仮想機械アーキテクチャは、仮想鍵および関係するデータを保護するようハードウェアTPMをてこ入れしうる。ある実施形態では、vTPM鍵階層構造および関係するデータは、標準的なhwTPM内で保護される。たとえば、仮想TPM鍵は、ハードウェアTPMに保存され、データがまず暗号化されることなくして決してハードウェアTPMから出されないことがありうる。結果として、仮想TPMが危殆化された場合、関連するvTPM鍵の公開部分は可能性としては不正使用を受けることがありうるが、危殆化の間じゅうだけである。今の例示的ハードウェア・ベースの実施形態では、すべての鍵はハードウェアTPM内に留まり、したがって、ひとたび危殆化が終息すれば、秘密鍵は盗まれたり使われたりすることができない。

本発明に基づく処理システムはまた、vTPMが通常のTPM構成証明サービスを提供することを許容する構成証明プロトコル・アーキテクチャをも提供しうる。仮想TPMに気づかないリモートのチャレンジャーは、構成証明プロセスに完全に参加しうる。加えて、vTPMに気づくリモートのチャレンジャーは、追加的なプロトコルなしに、hwTPMをvTPMから区別することができてもよく、それからvTPMをホストするプラットフォームを信頼するかどうかを決定してもよい。リモートのチャレンジャーは、限定することなく、検証可能な形で安全なクライアントにのみデータを提供するエンティティを含みうる。そのようなチャレンジャーは、第三者データ・プロバイダーと称されうる。

上に示したように、今の例示的ハードウェア・ベースのモデルでは、各DMについてのあらゆる鍵はTPM３０内に保存される。TPM３０の能力および具体的な実装の具体的なセキュリティ要件に依存して、クレデンシャル９６および９８、vPCR９２、vDIR９４などといったその他の構造およびデータ項目の一つまたは複数もハードウェアTPM内に保存されていてもよく、あるいはGVTPMフレームワーク４０のPSS１００に保存されていていてもよい。

プライバシーCAがあるプラットフォームのために素性クレデンシャルを生成するとき、プライバシーCAは該素性クレデンシャルをそのプラットフォームに送信する前に、該素性クレデンシャルをプラットフォームのEKで暗号化する。ある実施形態では、VM６０Ａは、プライバシーCA７６と相互作用するプラットフォームとして動作し、VM６０Ａはハードウェア・ベースのvTPMデバイス・モデル（たとえばDM４４Ａ）を使用する。したがって、プライバシーCA７６は素性クレデンシャル（たとえばvAIK_Cred９８）をVMのvEK１５０で暗号化する。この暗号化は、輸送中にクレデンシャルを保護する。VM６０Ａがその素性クレデンシャルをプライバシーCAから受け取るとき、VM６０ＡはDM４４ＡからのvEKの秘密鍵を使ってこのクレデンシャルを復号する。vAIK_Cred９８がTCGに縛られたデータ構造にないので、vEK１５０は、このクレデンシャルの復号をサポートするためには、TPMレガシー鍵でなければならない。

今の例示的実施形態では、vSRK１５２およびvEncK１５６は伝統的なTPM記憶装置鍵であり、何ら特別な注意は必要としない。同様に、vSigK１５４は伝統的なTPM署名鍵であり、何ら特別な注意は必要としない。しかしながら、素性鍵は引用されるPCR値に署名することができるのみである。これは、vAIKは、もしAIKとして実装されるならば、DMメモリに保存された仮想PCRに署名することができないということを意味する。仮想PCRはhwTPM３０の外部にあるデータだからである。したがって、vAIK１５８が、TPM署名鍵として実装されうる。引用構造は、DM４４Ａ内で仮想PCR９２のために構築され、次いでvAIKで署名されうる。最後に、KBK１６０は伝統的なバインド鍵である。

３．２．２ TPM鍵に基づく仮想PCRの実施
ハードウェアTPM（たとえばTPM３０）とvTPMを使うVM（たとえばDM４４Ａを使うVM６０Ａ）は、現在のPCR値が何であるかについて異なる概念をもつ。vTPMとTPMとの間で情報の流れが一貫したままであることを保証するよう、注意を払う必要がある。vTPM中で鍵が生成されることをVMが要求するとき、その要求には、vPCRバインドが伴う。もっとも、ゲストはバインドが仮想であることを認識しなくてもよいが。この要求がハードウェアTPMに転送されるとき、要求中のPCRフィールドが正しいhwPCRバインドに翻訳されなければならない。バインドとして、DMはGVTPM＋TCBを使用してもよいし、あるいはパフォーマンスのためにバインドを省略してもよい。こうして、ハードウェアTPMから返された、結果として得られる新たに生成された包装鍵は、VMによって要求されたvPCRバインドを含まないことになる。包装鍵がそれらのバインドを含まないので、攻撃者が元の包装鍵を入手して、それをハードウェアTPMに直接ロードするようなことがあれば、攻撃者はvTPMをバイパスすることが可能となりうる。

さらに、ハードウェアTPMによって返される包装鍵は、TPMバージョン、PCRバインド、公開鍵、暗号化された秘密鍵および要求者に返されるその他の情報を含むTCG_KEY構造である。バージョンおよびPCRバインドの情報は、vTPMではなくハードウェアTPMの情報である。透明性を保存するため、vTPMによって返されるTPM_KEY構造は、vPCRバインドおよびvTPMバージョンの情報をもつべきである。ある実施形態では、この問題に対処するため、vTPMによって返される包装鍵は、ハードウェアTPMによって返される包装鍵の修正された形となる。この開示の目的のためには、vTPMによって返された包装鍵は、vTPM二重包装鍵（double wrapped key）と称されうる。

図４は、vTPM二重包装鍵の例示的な実施形態のブロック図を呈示している。図４では、vTPM包装鍵２１０は、TPM３０によって返される包装鍵２００の修正された形である。ある実施形態では、下記の動作は、新しい鍵がvTPM４４Ａによって生成されることをVM６０Ａが要求するときに常に、たとえばVM６０Ａ内のDM４４Ａが新しいvAIKを生成するときに実行されてもよく、処理システム２０はその鍵をTPM３０内に保存することに進む。

vTPM包装鍵２１０においては、透明性を保証するために当該構造のあらゆる公開部分が手つかずのまま残っている。また、ブロック２１４に示されるように、TCG_KEY構造の暗号化された秘密鍵セクション２１６はhwPCRバインド、この鍵を使用する権限付与、ハードウェアTPMのバージョン、鍵の公開部分のダイジェストおよび元の暗号化された秘密鍵セクションを含むよう拡張される。該元の暗号化された秘密鍵セクションは、vTPMデバイス・モデル（たとえばDM４４Ａ）には読めないものである。ブロック２１２で示されるように、TCG_KEY構造の公開部分におけるPCRバインドは、vPCRバインドで置き換えられることになり、バージョンはvTPMのバージョンに設定されることになる。秘密部分に保存されるダイジェストはこれらの修正を反映する。最後に、拡張された秘密鍵セクション２１６はKBK１６０で暗号化される（前述）。結果は、期待されるバージョンおよびvPCRバインドをもつTCG_KEY２１０および読めない暗号化セクションであり、該読めない暗号化セクションはハードウェアTPMに渡されても適正に復号されない。

使用のためには、ユーザーに返される鍵は、仮想TPM（たとえばDM４４Ａ）にロードされなければならない。該仮想TPMが秘密鍵セクション２１６を復号し、仮想PCRバインド２１２を復号し、元の包装鍵２００を再構築する。ひとたびvPCRおよび権限付与が検証されたら、DMは、秘密鍵セクション２１６のコピー２０４を含む元の包装鍵２００をTPMに読み込む。元の包装鍵２００は同様にハードウェアTPMによって復号され、ハードウェアPCRバインド２０２が検証され、そうして初めて鍵２００が完全にロードされ、使用のために入手可能となる。

３．２．３ 他のデバイス・モデル資源
仮想TPMデバイス・モデルは、他のTPM資源のほとんどを多くのDMにまたがって共有することはできないことがありうる。単調カウンタは典型的には、非排他的なカウンタ使用を期待するための修正アプリケーションなしには共有できず、よって特定のDMに恒久的に割り当てられるか、ソフトウェア・ベースのデバイス・モデルと同様にソフトウェアで実装されるかしうる。vTPM不揮発性記憶は、ハードウェアTPMの記憶を超過しない限り、ハードウェアTPM内に記憶されることができる。ハードウェアTPMの記憶が不十分であれば、不揮発性記憶もソフトウェア・ベースのDMと同様に仮想化されることもできる。

VMは、TPM機能の多くを使用するためには権限付与セッションを生成できる必要がある。だが典型的には、vTPMデバイス・モデルによって直接扱われる機能とハードウェアTPMに渡される機能との間の区別をするべきではない。ある実施形態では、DMは、単一のユーザー権限付与セッションのもとで、自分自身およびハードウェアTPMの両方から透明にTPM機能を提供する。

これを達成するために、DMはVMおよびハードウェアTPMの両方について別個の権限付与セッションを維持する。すなわち、ユーザーは通常通りにDMについて権限付与セッションを生成する。DMは、このセッションに基づいて、ハードウェアTPMがするであろう同じ権限付与検査をすべて行いうる。DMが要求された機能を直接提供する場合、DMは単にセッション・ノンスを更新して返答すればよい。そのサービスを提供するためにDMがハードウェアTPMを必要とする場合には、DMは、ハードウェアTPMについて有している既存の権限付与セッションを生成または再利用してその要求をしてもよい。ひとたびDMがハードウェアTPMを使ってできると、DMはそのユーザーのセッションに対するノンスを更新して返答しうる。

４．０ ハードウェア最適化
上で論じたフレームワークは、単一の通常TPMを使って複数のゲストにTPM機能を提供しうる。フレームワークは、TPM機能性を提供するためにソフトウェアかハードウェアのいずれを使うこともできるが、仮想PCRを実施するためにTPMを使うのはわずらわしことがありうる。本節は、ハードウェア・ベースのデバイス・モデルを最適化し、単純化するためのTPM特徴を記述する。それらの特徴は次のようなものを含む：
・仮想PCR
・仮想構成証明素性鍵
・仮想EK
典型的な通常TPMは、vPCRを保存し、TPMが鍵バインドを実施してvPCR引用を提供するのを許容することができないことがありうる。これは、DMがvPCRを実施および管理する、二重包装鍵の必要性につながる。vPCRを保存することのできる修正されたTPMは、複雑さの多大な部分を取り除き、向上したパフォーマンスを提供する。本出願と同じ被譲渡者に譲渡された米国特許出願第11/095,034号は、仮想機械のためにPCRおよび／またはvPCRをサポートする技術を論じている。

ひとたびvPCRが修正されたTPMにおいて利用可能になれば、AIKはそれを引用できるはずである。ある実施形態では、修正されたTPMは、主たるPCRではなくvPCRを引用する仮想AIK（vAIK）を生成する能力を有する。

最後に、事実上PCRを引用するために、vAIKは素性クレデンシャルを要求する。前記したように、素性クレデンシャルはEKで暗号化される。ある実施形態では、修正されたTPMは、vAIKのためのクレデンシャルを復号できるvEKのサポートを含む。

これらの修正により、GVTPMフレームワーク４０内におけるハードウェア・ベースのDMのパフォーマンスを向上させ、それと同時にフレームワークの複雑さを減じ、よってその信頼性を増すことができる。

５．０ 仮想TPMのリモート展開およびプロビジョニング
プラットフォーム上でのTPMの使用は、ソフトウェアおよびデータの配布のために新たな課題を生じうる。たとえば、組織内の情報技術（IT）部門はソフトウェアのビルドまたはパッチを作成し、次いでそのビルドまたはパッチを組織を通じた何百、何千もの機械にプッシュすることがありうる。TPMは、鍵を保護し、データを封印するためにTPMが使われる仕方のため、この過程に新たな原動力を提供する。新しいソフトウェア・パッケージを機械に配布するため、IT部門は、そのソフトウェアによって必要とされる何らかの鍵を機械のTPMに配布する必要があることを見出しうる。

以下の諸段落は、vTPMをある機械（たとえばサーバー）上で準備し、その後、そのvTPMを利用すると期待されるソフトウェアとともに他の機械（たとえばクライアント）に配布することがどのようにしてできるかを記述する。以下に記述されるアプローチのための例示的な使用モデルは企業内でのものであるが、そのアプローチまたはその変形は、vTPMのサービスの消費者がそのサービスを提供するエンティティと十分密接な関係を有しているいかなる環境においても使用できる。該環境とは、クライアント・システムがある特定のエンティティからのソフトウェアを走らせており、クライアント・システムがそのソフトウェアを同じエンティティによって提供されるデータにアクセスするのに使用するときなどである。たとえば、医師の診療室にあるクライアント・システムは、保険会社からvTPMを、そのvTPMを使うコンテンツ・ビューアとともに取得できる。次いでクライアント・システムはそのコンテンツ・ビューアを使って、保険会社からの保護された保険記録にアクセスできる。ある例示的な実施形態では、vTPMを信頼する必要のある唯一のエンティティは保険会社であり、これはvTPMを提供したのと同じエンティティである。

リモートでプロビジョニングされたvTPMは、通常のvTPMと異なり、動作するプラットフォームの外部で生成される。これは、仮想製造業者機関が、そのvTPMについての裏書きクレデンシャルおよびプラットフォーム・クレデンシャルの両方にはもはや署名しないことを意味する。ある例示的なプロビジョニング環境では、IT部門がvTPMを製造し、そのvTPMについての裏書き鍵を生成し、裏書きクレデンシャルに署名し、次いでそのvTPMおよび裏書きクレデンシャルを宛先機械に送る。ひとたびvTPMが宛先機械に挿入されると、仮想製造業者機関がその新しいvTPMのためのプラットフォーム・クレデンシャルを生成してそれに署名する。これら二つのクレデンシャル上の署名は、チャレンジャーが信頼しなければならない二つのエンティティを識別する。IT部門はその秘密の裏書き鍵へも該vTPMにIT部門が事前にロードした他のいかなる鍵へもアクセスを有していたので、IT部門は裏書きクレデンシャルに署名する。vTPMアーキテクチャ・コンポーネント（たとえばGVTPMフレームワーク４０）およびプラットフォームの孤立化機構は、vTPMをソフトウェア・プラットフォームに統合する。それらは潜在的には、vTPMに保存された秘密情報へのアクセスを有する。したがって、それらのエンティティもチャレンジャーによって信頼される必要がある。結果として、プラットフォーム・クレデンシャルは仮想製造業者機関によって署名される。

チャレンジャーが裏書きクレデンシャルに署名するエンティティおよびプラットフォーム・クレデンシャルに署名するエンティティを信頼しない場合、チャレンジャーはこのvTPMからの構成証明を拒否しうる。企業の場合、vTPM、vTPMプラットフォームおよびチャレンジャー・ソフトウェアの製造はおそらくIT部門が制御するであろう。こうして、これらのエンティティの間には本来的な信頼がある。同様に、コンテンツ・プロバイダーはvTPMおよび関係するチャレンジャー・ソフトウェアの製造は制御でき、よってそのようなコンテンツ・プロバイダーはvTPMプラットフォームを信頼する必要があるだけでよい。

展開のための一つの例示的な機構は、vTPMを宛先のPSSに転送することである。これがいかにして達成されるかは、PSSとGVTPMマネージャとの実装に依存する。ある例示的実装では、PSSは、ハードウェアTPMによって保護されていて特定のvTPMアーキテクチャにバインドされていると該PSSが外部のエンティティに証明できる記憶装置鍵を維持する。この鍵が状態を保存するために使われる一方、この鍵は状態を受け取るためにも使える。以下のステップはこの送信がどのように起こりうるかを例示する。
１）プロビジョナーが新しいvTPMとvTPM内で必要とされるすべての鍵とを生成する。プロビジョナーはまた、そのvTPMのために新しい裏書きクレデンシャルを生成して署名する。
２）プロビジョナーが、宛先PSSがリプレイ対策のノンスを提供することを要求する。
３）PSSがプロビジョナーにノンスと任意的に該PSSの公開鍵を送る。この鍵は以前の通信からすでに知られていてもよい。
４）プロビジョナーが次いで、新しいvTPMの状態およびステップ３からのノンスをPSSの記憶装置鍵で暗号化する。
５）プロビジョナーが、暗号化されたブロブを、そのvTPMのための裏書きクレデンシャルとともにPSSに送る。
６）PSSはvTPM状態を受け取り、復号し、あらゆるオフラインvTPMにしているように封印し、既知vTPMとして記録する。このvTPMは今では公式に当該PSSのプラットフォームの一部である。
７）PSSについての仮想製造業者機関がvTPMについてのプラットフォーム・クレデンシャルを生成する。
PSSはこれで、他の任意のものと同様、vTPMをロードして使用できる。

TPM鍵を要求するソフトウェアがクライアントに配布されるとき、vTPMがサーバーで生成されてからクライアントに転送されるのではなく、vTPMがクライアント・システム上で生成される場合、サーバーは典型的にはクライアントに、vTPMを生成するよう命令し、次いでクライアントがソフトウェアによって要求される各鍵を生成する間待つ必要がある。次いでクライアントは生成された鍵の公開鍵部分をサーバーに送ることができ、サーバーは次いでそれらの公開鍵を展開すべきアプリケーションおよびデータを生成するために使う。何百、何千ものクライアントが更新される場合には、このプロセスは完了まで長い時間がかかる。さらに、サーバーは鍵を生成する環境の制御をもたない。

鍵を生成するエンティティがチャレンジャー（すなわち、構成証明を要求するまたはそれ以外の仕方で鍵に頼るエンティティ）でもある場合、この開示で導入されたアプローチは、必要な鍵およびそれらの鍵をサポートするvTPMを生成するより高速かつより効率的な方法を提供しうる。

図２に反映されているように、TPM同様、vTPMは、vTPMの状態をなすデータを保存するための構造を含んでいる。たとえば、vTPMについての状態のいくらかはPCRおよびDIRに保存される。さらに、vTPMの状態はさまざまな鍵、クレデンシャル、カウンタなどを含みうる。この開示の目的のためには、vTPMについての状態データの著しい部分を生成することは、vTPMを生成することと考えられてもよい。

具体的には、この開示の目的のためには、EKの生成はvTPMの生成をなす。上記のように、ひとたびvTPMが生成されたら、該vTPMは目標システムに転送されうる。そのvTPMについての状態の残りは、プラットフォーム、VMMまたはVMがvTPMの所有権を受けたときに生成されうる。vTPMを生成し、それを別の処理システムに転送するプロセスは、一般に、vTPMのリモート・プロビジョニングおよび展開と称されうる。

６．０ 仮想TPMの移行（マイグレーション）
環境によってはTPMが固定であるという性質が重要であるが、環境によってはプラットフォームをまたいだTPMの制御された可動性から裨益することもできる。TCGは単一の鍵が第三者の介入によってあるTPMから別のTPMに移行されることのできる機構を承認している。だが、この機構はわずらわしいことがある。二つ以上の鍵を移行する必要があるときは特にそうである。以下の諸段落は、制御された仕方でプラットフォームからプラットフォームへvTPMを移行させる新しい方法を導入する。今の例示的実施形態では、すべての鍵が、移行される各鍵についての第三者の介入を要求することなしに、同時に移行される。

以下に述べる移行の方法は、重要な保証を提供する。たとえば、vTPMが特定のセキュリティ属性をもつと広告される場合には、鍵がvTPMにおいて生成されるときは、その鍵についてのあらゆる利害関係者は、そのvTPMが別のプラットフォームに移行させられてもそれらのセキュリティ属性が新しいプラットフォームにも存在することになると保証される必要がある。また、vTPMが移行されるとき、vTPM状態は、源プラットフォームから宛先プラットフォームにコピーされるのではなく、移動される必要がある。

広告されたセキュリティ属性の保証をサポートするために移行ポリシーが使用される。このポリシーは、特定のvTPMがプラットフォームに移行されるために、vTPMアーキテクチャおよび該アーキテクチャを保護するプラットフォーム機構がどんな基準を満たさなければならないかを決定する。さらに、このポリシーは厳密に実施される。ある例示的な実施形態では、仮想製造業者機関が移行ポリシーを実施する目的のためにはたらき、該仮想製造業者機関は移行ポリシーごとに一つの鍵を維持する（たとえば署名鍵）。仮想製造業者機関が、製造業者の地位を得るために信頼されたCAに登録するとき、該仮想製造業者機関は、該仮想製造業者機関があらゆるvTPMについて実施する移行ポリシーを同定するデータをも、該仮想製造業者機関がこの署名鍵で署名するクレデンシャルとともに送る。

ある例示的な実施形態では、GVTPMマネージャ１１０が通常扱うことが要求されるvTPM管理機能に加えて移行可能なvTPMの生成をサポートするため、GVTPMマネージャ１１０はvTPM生成の間にvTPMを移行可能または移行不可能のいずれかと宣言する。移行可能vTPMは、どの利用可能な移行ポリシーが使われるかを示すさらなる指定を要求しうる。たとえば、仮想製造業者機関が裏書きクレデンシャルおよびプラットフォーム・クレデンシャルを生成するとき、該仮想製造業者機関はvTPMが移行可能であることを示すモデル番号を使用することができ、クレデンシャルに移行可能vTPM用製造業者鍵で署名してもよい。すなわち、仮想製造業者機関は、移行可能なvTPMの製造業者に属すると認識される署名鍵でクレデンシャルに署名しうる。

こうして、ある実施形態では、移行可能なvTPMの裏書きクレデンシャルはある署名鍵で署名され、一方移行不可能vTPMの裏書きクレデンシャルは異なる署名鍵で署名される。この方法論は、移行可能vTPMのよりよい同定を許容する。実施形態によっては、移行可能vTPMについてのクレデンシャルにはある仮想製造業者機関が署名し、移行不可能vTPMについてのクレデンシャルには異なる仮想製造業者機関が署名する。

移行のための一つの例示的な機構は、源プラットフォーム上のPSSが移行可能vTPMの状態を宛先プラットフォーム内のPSSに転送するというものである。しかしながら、この移行がどのように達成されるかは、PSSおよびGVTPMマネージャの実装に依存する。

ある例示的な実装では、PSSは、ハードウェアTPMによって保護されていて特定のvTPMアーキテクチャにバインドされていると該PSSが外部のエンティティに証明できる記憶装置鍵を維持する。この鍵が状態を保存するために使われる一方、この鍵は状態を受け取るためにも使える。第一のプラットフォームのPSS（PSS1）がvTPMを第二のプラットフォームのPSS（PSS2）に移行させることを望む場合、以下のステップが起こりうる。
１．PSS1が、PSS2がその記憶装置公開鍵および該鍵のバインドの証明を送信することを要求する。
２．PSS2が、その記憶装置公開鍵およびノンスをPSS1に送る。
３．PSS1は、PSS2の状態に対するvTPMのポリシーを評価する。PSS1は、該ポリシーによってPSS2の状態がvTPMの安全な動作を提供し、次の移行のためにこのポリシーを堅持すると信頼できると宣言される場合にのみvTPMを移行させるべきである。
４．PSS2が合格したら、PSS1はvTPMが走っていないことを確かめる。次いでPSS1は次のものをPSS2の記憶装置鍵で暗号化する：vTPMの持続的状態、ステップ２からのノンスおよびこの状態が走るべき正しいvTPMの測定結果。
５．PSS1は、このvTPMのためのレコードを既知のvTPMのリストから削除する。これは、この状態がこのサービスに再ロードされることができないこと、移行が完了したらこのvTPMはPSS2のもとでのみ存在することを保証する。
６．PSS1はPSS2に、暗号化されたブロブを、vTPMのための裏書きクレデンシャルとともに送る。
７．PSS2はvTPM状態を受け取り、復号し、あらゆるオフラインvTPMにしているように封印し、既知のvTPMとして記録する。このvTPMは今では公式にPSS2のプラットフォームの一部である。
８．（任意的） PSS2の仮想製造業者機関がvTPMについてのプラットフォーム・クレデンシャルを生成する。vTPMがPSS1のプラットフォーム・クレデンシャルを使うことを続けるのは、vTPMはもはやそのプラットフォーム上にないので、不正確である。しかしながら、vTPMの信頼性はポリシーに合格する最も弱い構成の信頼性でしかないので、この新しいクレデンシャルが使われることはセキュリティのためには決定的（critical）ではない。
PSS2はこれで、他の任意のものと同様、vTPMをロードして使用できる。

移行プロトコルの安全性が検証されてもよい。それは、次のことを保証するためである：所与の移行可能vTPMについて、vTPMはその移動の間決して危殆化されなかった。帰納的証明法によって、この保証は、次の二つの命題がチャレンジャーに対して証明できれば確立されうる：
１．vTPM状態が元は安全なvTPM内で生成された。
２．vTPMが安全なvTPM内にあれば、vTPMアーキテクチャはvTPM状態を別の安全なvTPMにしか移行させない。
これら二つの陳述の保証は、クレデンシャルに対する署名に見出される。vTPMが生成されたとき、その裏書きクレデンシャルが仮想製造業者機関によって生成され、署名された。これに先立ち、仮想製造業者機関はその署名鍵を生成し、移行ポリシーとともにそれを証明機関と交換した。このCAは、仮想製造業者機関のことを安全なvTPMを提供し、安全な移行ポリシーを実施するものとして認識するのでない限り、仮想製造業者機関についての裏書きクレデンシャルに署名することはない。したがって、CAが署名したクレデンシャルをもつ仮想製造業者機関は、vTPMを安全でないvTPMに移行させることは決してしない。

典型的には、チャレンジャーはAIKによって署名されたPCRの組および付随するプライバシーCAによって署名された素性クレデンシャルを受け取る。チャレンジャーは、vTPMの評価をこの情報に基づいて行いうる。このクレデンシャルを見ることによって、チャレンジャーは、vTPMがプライバシーCAに信頼できる署名鍵で署名された裏書きクレデンシャルを見せたと安全に結論しうる。プライバシーCAは、自分自身または別のCAが保証している署名しか信頼しない。裏書きクレデンシャルにある署名が別のCAによって保証される唯一の方法は、署名鍵が安全な仮想製造業者機関にあり、かつ、署名鍵が他の安全なvTPMへの移行しか許容しない移行ポリシーに対応している場合である。

したがって、素性クレデンシャルの存在は、チャレンジャーに、このvTPMが正当なvTPMにおいて生成されたことと、この構成証明を与える前に邪悪なvTPM内に存在したことがないこととを確信させるはずである。

同様に、上記の移行アプローチは、vTPMを提供するプラットフォームではなく、vTPMを受け取るプラットフォームから開始されてもよい。

開示された移行方法論は、幅広い範囲の応用にとって有用でありうる。それには、個人が複数の機械からのデータにアクセスすることを望む使用モデルも含まれる。たとえば、医師は自宅のコンピュータと職場のコンピュータとの間でvTPMを便利に移行させることができる。それにより、医師は二つ以上の位置からの保護された医療記録にアクセスすることが許容される。アクセス可能な保護されたデータの型としては、限定なしに、デジタル権利管理（DRM）プロトコルによって保護されたコンテンツ、同じエンティティからの、コンテンツにアクセスするためのソフトウェアを提供する独自コンテンツ、ならびにある種のエンティティにのみ利用可能であるべき個人情報、機微な情報および／または秘匿情報（たとえば、医療記録、金融データなど）が含まれる。

同様に、上記の移行アプローチは、事実上、個人のコンピューティング環境をいかなる特定のワークステーションからも自由にする使用モデルをサポートすることができる。たとえば、http://info.pittsburgh.intel-research.net/project/isr/で記述されているインターネット・サスペンド／レジューム（ISR: Internet Suspend/Resume）プロジェクトは「ユーザーのコンピューティング環境がユーザーが移動するにつれて［ワークステーションからワークステーションへと］ユーザーに追随する移動コンピューティングへのアプローチ」に係るものである。ISRプロジェクトは、可搬コンピューティング環境の一つの例示的な展開を次のように記述している。

たとえば、午前中は自宅から、午後はオフィスで仕事をする在宅通勤者を思い描いてみる。午前中の仕事を完了したのち、ユーザーは自宅の機械で「サスペンド」をクリックし、オフィスへの移動を開始する。ユーザーの移動中、ユーザーのコンピューティング環境の状態もネットワークを通じてユーザーのオフィスの機械へと移動する。在宅通勤者がオフィスに着くと、オフィスの機械はユーザーが自宅に残してきたのと同じ環境を呈示している：同じアプリケーションおよびファイルが開かれており、ウィンドウはみな期待された場所にあり、カーソルは適切な位置にある。

そのようなモデルおよび同様のモデルは、可搬なTPM保護されたコンピューティング環境をサポートするためにvTPM移行を使用することができる。該環境の例は、TPM保護されたOS、TPM保護されたアプリケーションおよび／またはTPM保護されたデータを含む環境である。

８．０ 結語
この開示は、TPMのようなセキュリティ・コプロセッサの仮想化のための一般化されたフレームワークを記述する。ある例示的な実施形態は、安全な仮想TPM動作を可能にするためにTPMを使用する。開示された実施形態は、複数のVMがTPM機能性を使用することを、複数の専用ハードウェアTPMを要求することなく、VM内のソフトウェアへの修正を要求することなく、そしてTPMまたはvTPM保護されたシステムと相互作用するリモート・エンティティへの修正を要求することなく、許容する。本開示によれば、仮想TPMは、VM内のOSおよびアプリケーションを測定して、リモート・エンティティに構成証明を提供することができる。さらに、仮想TPMはハードウェアTPMチャレンジャーのために、VMの状態を構成証明できる。これは、ハードウェアTPMおよびチャレンジャーが上で参照したTPMバージョン1.2、設計規格のような現行のTPM規格で記述されている機能のみを利用していたとしてもできる。VM中のゲストOSは、ハードウェアTPMが共有されていることに気づかないままでもよく、システム内のVMどうしの間には信頼関係は要求されない。

開示されたフレームワークはまた、ハードウェアで実装するとしたらコスト的に禁止的な、安全なソフトウェアによるカスタム暗号サブシステムの開発を容易にする。仮想TPMは、VM技術によって生成される孤立化とハードウェアに基づく安全な記憶および構成証明を提供するTPM機能との組み合わせを可能にする。カスタム暗号サブシステムは、アクセス・コントロールと暗号プロトコルを提供するためのTPMの機能に比べて豊かな機能を可能にする。この開示は、仮想化の透明性を保証しつつ、セキュリティとパフォーマンスの種々の兼ね合いをもっていかにしてフレームワークが使用できるかの例を示す実施形態を含んでいる。これは、アプリケーションがVM内からのTPMアクセスを、仮想化なしのプラットフォーム上でのTPMアクセスと異なる仕方で扱う必要がないということを意味している。たとえば、アプリケーションはDMと通信するために、物理的なセキュリティ・コプロセッサと通信するときと同じAPIを使いうる。

この開示はまた、より単純な、最適化されたTPM仮想化のための追加的なハードウェアTPM特徴をも記述する。さらに、この開示は、仮想TPMをリモートでプロビジョニングおよび展開するための機構およびプラットフォーム間で仮想TPMを移行させるための機構を記述する。

上に示したように、種々の実施形態がデータを保護するためにハードウェアTPMに頼る度合いは多いことも少ないこともありうる。たとえば、すべての鍵がハードウェアTPM内に記憶されていてもよく、あるいは柔軟性および／またはパフォーマンスの向上のためにvTPMソフトウェアによって仮想鍵を生成して使うこともでき、仮想鍵はhwTPM内に保存されたりhwTPMによって直接保護されたりしなくてもよい。仮想TPMに属するまたは仮想TPMによって生成される秘密鍵は、ハードウェアTPMが暗号動作を実行するためにそれらの秘密鍵を使用してはならないという意味で、ハードウェアTPMによる作用を受けてはならない。代わりに、仮想TPMは、ホスト・プロセッサおよび暗号ソフトウェアを使って、その暗号鍵を用いた暗号動作を実行しうる。これを行うため、仮想TPMサービスはその秘密鍵を保護されたホスト・メモリに保存しうる。しかしながら、秘密鍵が使用されていない間は、仮想TPMサービスは、ハードウェアTPM特徴を使って、該鍵をそのソフトウェア構成に包装してもよい。

これらのオプションは、オブジェクトの暗号化、復号、署名および検証を、vTPMソフトウェアにおいて、ハードウェアTPMによって提供されうるよりもずっと高いパフォーマンスで許容しうる。よってこれらのオプションは、たとえばバルク暗号化またはパフォーマンスに敏感なサーバー環境での使用のために好まれうる。しかしながら、上乗せされるパフォーマンスのための代償は、vTPMが危殆化された場合に仮想鍵は恒久的に危殆化されうるということである。

ここで記載され、図示された原理および例示的な実施形態に照らして、示された実施形態がそのような原理から外れることなく構成および詳細において修正できることは認識されるであろう。たとえば、仮想TPMはVMとの関連で記述してきたが、代替的な実施形態は、ハードウェアTPMを共有するサーバーまたはサーバー群の中のパーティションなど、他の型のシステム細分との関連で使用されるvTPMをも含む。たとえば、仮想TPMは、二つの論理的な２プロセッサ・システムに区分された４プロセッサ・システムで使用されてもよい。ここでの教示は、論理的なTPMを一つまたは複数のサービス・コプロセッサに、あるいはハードウェア・プラットフォーム上の一つまたは複数の他の型の独立した処理要素に提供するためにも使われることができる。

さらに、代替的な実施形態は、ハードウェアTPMをエミュレートしないが（たとえばより多くのPCR、より多くの記憶などを提供することによって）ハードウェアTPMの機能を拡張および／または増幅するvTPMサービスを含む。また、代替的な実施形態に含まれる仮想TPMサービスは、安全なOSの上、管理されたランタイム環境（MRTE: managed run-time environment）の上、サービス・プロセッサまたはコプロセッサ中、プラットフォームのシステム管理モード（SMM: system management mode）中などで走る。仮想TPMを提供する代わり、またはそれに加えて、追加的な実施形態は、エミュレートされたセキュリティ・コプロセッサの他の種類を提供する。

また、以上の議論は個別的な実施形態に焦点を当ててきたが、他の構成も考えられる。具体的には、「ある実施形態では」「別の実施形態では」などといった表現がここで使われているが、これらの句は、実施形態の可能性に一般的に言及することを意味するのであって、本発明を個別的な実施形態の構成に限定することを意図したものではない。ここでの用法では、これらの用語は、同じまたは異なる実施形態を指すことがあり、他の実施形態に組み合わせ可能でありうる。

同様に、例示的なプロセスを特定の序列で実行される個別的な動作に関して記述してきたが、数多くの修正がそれらのプロセスに適用されて本発明の数多くの代替的な実施形態が導出されることができる。たとえば、代替的な実施形態は、開示された動作の全部よりも少ない部分を使用するプロセス、追加的な動作を使うプロセス、同じ動作を異なる序列で使用するプロセスおよびここで開示されている個々の動作が組み合わされ、細分され、あるいは他の仕方で変更されているプロセスを含みうる。

本発明の代替的な実施形態はまた、本発明の動作を実行するための命令をコードしている機械アクセス可能媒体を含む。そのような実施形態はまた、プログラム・プロダクトとも称されうる。そのような機械アクセス可能媒体は、限定することなく、フロッピー（登録商標）・ディスク、ハードディスク、CD-ROM、ROMおよびRAMといった記憶媒体ならびにアンテナ、ワイヤ、光ファイバー、マイクロ波、電波およびその他の電磁搬送波もしくは工学的搬送波といった通信媒体を含みうる。したがって、命令およびその他のデータは、伝送環境またはネットワークを通じて、パケット、シリアル・データ、パラレル・データ、伝搬信号などの形で配送されることができ、分散環境で使用され、単一プロセッサ機械またはマルチプロセッサ機械によるアクセスのためにローカルおよび／またはリモートに保存されてもよい。

また、ここで描写されているハードウェアおよびソフトウェア・コンポーネントは、合理的な程度自己完結した機能要素を表していることも理解しておくべきである。よって、おのおのは互いに実質的に独立に設計、構築または更新されることができる。代替的な実施形態では、コンポーネントの多くが、ここに記載され、図示された機能性を提供するために、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの組み合わせとして実装されうる。

ここに記載された例示的な実施形態からすぐ導かれうる幅広く多様な有用な置換に鑑みて、この詳細な記述はあくまでも例示的であることを意図したものであり、本発明の範囲を限定するものと解釈すべきではない。したがって、本発明として請求されるものは、付属の請求項の範囲および精神のうちにはいるあらゆる実装およびそうした実装へのあらゆる等価物である。

本発明のある例示的な実施形態のある種の側面が実施されうる好適なデータ処理環境を描いたブロック図である。 TPM仮想化のような機能をサポートするためのさまざまな構造および鍵に関する、例示的なTPMを描いたブロック図を呈示する図である。 例示的な一般化された仮想TPMフレームワークのさまざまなコンポーネントおよび関係した項目を示すブロック図である。 仮想TPM二重包装鍵の例示的な実施形態のブロック図を呈示する図である。 仮想TPMのためのセキュリティ構成証明を提供する仮想製造業者機関を用意する例示的なコンポーネントおよび動作を示すブロック図である。

Claims (21)

1. 処理システムの保護された部分に、所定の暗号コプロセッサに対応する所定のデバイス・モデル設計に少なくとも部分的に基づくデバイス・モデル（DM）を、該DMを実装するためのプログラム・コード・セグメント（PCS）を含む仮想機械（VM）定義を使って生成する段階と；
   前記DMにおいて、前記処理システムの保護された部分の外にあるソフトウェア・エンティティから情報を受領する段階と；
   前記DMにおいて前記ソフトウェア・エンティティから前記情報を受領するのに反応して、ユーザーおよび信頼されるプラットフォーム・モジュール（TPM）について前記DMによって別個の権限付与セッションを維持することを含む単一ユーザー権限付与セッションのもとで、前記所定のデバイス・モデル設計に従った暗号サービスを前記ソフトウェア・エンティティに提供することによって、前記所定の暗号コプロセッサをエミュレートする段階とを有する方法。
2. 前記DMをサポートするために前記処理システムの信頼されるプラットフォーム・モジュール（TPM）を使用することをさらに含む、請求項１記載の方法。
3. 前記ソフトウェア・エンティティに暗号サービスを提供する動作が：
   前記処理システムの物理的な暗号コプロセッサを使って前記DMに関連するデータを封印する段階と；
   前記処理システムのランダム・アクセス・メモリ（RAM）内に前記の封印されたデータを格納する段階とを有する、請求項１記載の方法。
4. 前記ソフトウェア・エンティティに暗号サービスを提供する動作が：
   前記処理システムの物理的な暗号コプロセッサからの鍵を使って前記DMに関連するデータを暗号化する段階と；
   プロテクト記憶サービス（PSS）を使って前記の暗号化された情報を格納する段階とを有する、請求項１記載の方法。
5. 前記PSSが前記の暗号化された情報を格納するために、前記処理システムのランダム・アクセス・メモリ（RAM）を少なくとも一時的に使う、請求項４記載の方法。
6. 前記処理システムにおいて、第一のデバイス・モデル設計に少なくとも部分的に基づいた一つまたは複数のDMの第一の組を生成する段階と；
   前記処理システムにおいて、第二のデバイス・モデル設計に少なくとも部分的に基づいた一つまたは複数のDMの第二の組を生成する段階とをさらに有する、請求項１記載の方法。
7. 前記デバイス・モデル設計が、信頼されるプラットフォーム・モジュール（TPM）のある特定の型を表す、請求項１記載の方法。
8. 前記デバイス・モデル設計が、セキュリティ・コプロセッサのある特定の型を表す、請求項１記載の方法。
9. 前記デバイス・モデル設計が、前記処理システムの前記保護された部分の外にあるソフトウェア・エンティティが前記デバイス・モデルのインスタンスと通信するために使うためのインターフェースの定義を含んでいる、請求項１記載の方法。
10. 機械アクセス可能媒体と；
    該機械アクセス可能媒体中でエンコードされている命令とを有する装置であって、前記命令は、処理システムによって実行されたときに、前記処理システムをして：
    所定の暗号コプロセッサに対応する所定のデバイス・モデル設計に少なくとも部分的に基づくデバイス・モデル（DM）を、該DMを実装するためのプログラム・コード・セグメント（PCS）を含む仮想機械（VM）定義を使って生成する段階と；
    前記DMにおいて、前記処理システムにおいて実行されるソフトウェア・エンティティから情報を受領する段階と；
    前記DMにおいて前記ソフトウェア・エンティティから前記情報を受領するのに反応して、ユーザーおよび信頼されるプラットフォーム・モジュール（TPM）について前記DMによって別個の権限付与セッションを維持することを含む単一ユーザー権限付与セッションのもとで、前記所定のデバイス・モデル設計に従った暗号サービスを前記ソフトウェア・エンティティに提供することによって、前記所定の暗号コプロセッサをエミュレートする段階とを含む動作を実行させることを特徴とする、装置。
11. 前記DMが、前記DMをサポートするものとして前記処理システムの信頼されるプラットフォーム・モジュール（TPM）を使用する、請求項１０記載の装置。
12. 前記DMが、前記DMの構造に関連するデータを封印するための前記処理システムの物理的なセキュリティ・コプロセッサを使用する、請求項１０記載の装置。
13. 前記命令が前記処理システムをして：
    前記処理システムにおいて、第一のデバイス・モデル設計に少なくとも部分的に基づいた一つまたは複数のDMの第一の組を生成する段階と；
    前記処理システムにおいて、第二のデバイス・モデル設計に少なくとも部分的に基づいた一つまたは複数のDMの第二の組を生成する段階とを含む動作を実行させることを特徴とする、請求項１０記載の装置。
14. 前記デバイス・モデル設計が、ソフトウェア・エンティティが前記デバイス・モデルのインスタンスと通信するために使うためのインターフェースの定義を含んでいる、請求項１０記載の装置。
15. プロセッサと；
    前記プロセッサに通信上結合されたセキュリティ・コプロセッサと；
    前記プロセッサに通信上結合された機械アクセス可能媒体と；
    前記機械アクセス可能媒体中にエンコードされた、仮想セキュリティ・コプロセッサ・フレームワークを実装するための命令とを有する処理システムであって：
    前記仮想セキュリティ・コプロセッサ・フレームワークは、所定の暗号コプロセッサに対応する少なくとも一つのデバイス・モデル設計を有しており；
    前記仮想セキュリティ・コプロセッサ・フレームワークは、当該処理システムにおいて、前記デバイス・モデル設計に少なくとも部分的に基づくデバイス・モデル（DM）を生成し；
    前記仮想セキュリティ・コプロセッサ・フレームワークは、前記DMをサポートするために前記セキュリティ・コプロセッサを使用し；
    前記DMは、ユーザーおよび信頼されるプラットフォーム・モジュール（TPM）について前記DMによって別個の権限付与セッションを維持することを含む単一ユーザー権限付与セッションのもとで、前記デバイス・モデル設計に従って前記所定の暗号コプロセッサをエミュレートする、ことを特徴とする、処理システム。
16. 前記仮想セキュリティ・コプロセッサ・フレームワークが、前記DMに関連するデータを封印するために前記セキュリティ・コプロセッサを使用する、請求項１５記載の処理システム。
17. 前記仮想セキュリティ・コプロセッサ・フレームワークが、それぞれ第一および第二の型の暗号コプロセッサを表す第一および第二のデバイス・モデル設計を有しており；
    前記命令が前記処理システムをして：
    前記処理システムにおいて、前記第一のデバイス・モデル設計に少なくとも部分的に基づいた一つまたは複数のDMの第一の組を生成する段階と；
    前記処理システムにおいて、前記第二のデバイス・モデル設計に少なくとも部分的に基づいた一つまたは複数のDMの第二の組を生成する段階とを含む動作を実行させることを特徴とする、請求項１５記載の処理システム。
18. 前記セキュリティ・コプロセッサが、信頼されるプラットフォーム・モジュール（TPM）を含む、請求項１５記載の処理システム。
19. 前記デバイス・モデル設計が、ソフトウェア・エンティティが前記デバイス・モデルのインスタンスと通信するために使うためのインターフェースの定義を含んでいる、請求項１５記載の装置。
20. 処理システムの保護された部分に、所定の暗号コプロセッサに対応する所定のデバイス・モデル設計に少なくとも部分的に基づくデバイス・モデル（DM）を、該DMを実装するためのプログラム・コード・セグメント（PCS）を含む仮想機械（VM）定義を使って生成する段階と；
    前記DMにおいて、前記処理システムの保護された部分の外にあるソフトウェア・エンティティから情報を受領する段階と；
    前記DMにおいて前記ソフトウェア・エンティティから前記情報を受領するのに反応して、ユーザーおよび信頼されるプラットフォーム・モジュール（TPM）について前記DMによって別個の権限付与セッションを維持することを含む単一ユーザー権限付与セッションのもとで、前記ソフトウェア・エンティティに、前記所定の暗号コプロセッサによってサポートされる動作を使う暗号サービスを提供する段階とを有する方法。
21. 前記ソフトウェア・エンティティに暗号サービスを提供する動作が：
    前記処理システムの暗号コプロセッサを使って、前記所定の暗号コプロセッサのエミュレーションをサポートする段階を含む、請求項２０記載の方法。

Images