次の方法で共有

Resource Virtualization

  • [アーティクル]

TBS の主な機能は、特定の限られた TPM リソース (キー、承認、トランスポート セッション) を効率的に共有することです。

これらのリソースのいずれかのインスタンスが作成されると、TBS はリソースの仮想インスタンスを作成し、(TPM によって返される実際のハンドル インスタンスではなく) 結果コマンド ストリーム内のこの仮想インスタンスにハンドルを返します。 TBS は、仮想ハンドルと実際のハンドルの間のマッピングを内部的に維持します。 特定の種類のリソースを保持するために TPM の領域が不足すると、TPM が新しいリソースを保持できるようになるまで、リソースの既存のインスタンスが選択的に保存され、削除されます。 古いリソースが再び必要になると、TBS は、コマンドを送信する前に、保存されたコンテキストを読み込みます (必要に応じて他のリソースを保存および削除します)。

TBS 内のすべての仮想化は、特定のコンテキストに代わって実行されます。 各コンテキストは、その代わりに特別に作成された仮想リソースと、それらの仮想リソースに対応する TPM 上の物理リソースにのみアクセスできます。 既定では、すべての仮想化リソースの合計数は 500 に制限されています。 この数値は、HKEY_LOCAL_MACHINE\Software\Microsoft\Tpmの下 MaxResources という名前の DWORD レジストリ値を作成または変更することで変更できます。 パフォーマンス モニター ツールを使用して TBS リソースの数を追跡することで、TBS リソースの使用状況をリアルタイムで確認できます。 この制限は、Windows 8 と Windows Server 2012 で廃止されました。

TBS によって仮想化されていない限られた TPM リソース (カウンターや NV ストアなど) は、ソフトウェア スタック間で協調的に共有する必要があります。

手記

このハンドル仮想化により、HMAC 承認パラメーターの計算にキー ハンドルを含むコマンドが失敗します。 そのため、TPM バージョン 1.2 で非推奨になったコマンドの多くは、TBS 環境のアプリケーション ソフトウェアでは使用できません。

 

リソースの制限

TPM を使用すると、呼び出し元はその機能に対してクエリを実行して、特定の種類のリソースで使用可能な領域の量を判断できます。 これらのリソース制限の一部 (キー、承認セッション、トランスポート セッションで使用可能な領域の量など) は、仮想化によって TBS によって効果的に拡張されます。 MaxResources レジストリ設定によって制御される TBS 制限は、通常、基になる TPM ハードウェアの実際の制限よりもはるかに大きくなります。 TPM ハードウェアの制限とは別に TBS 制限のクエリを実行するためのメカニズムは提供されていません。 この TBS の制限は、Windows 8 および Windows Server 2012 で廃止されました。

キー

TBS はキー ハンドルを仮想化して、キーが使用されていないときに TPM から透過的にアンロードし、必要に応じて TPM に読み込み戻すことができるようにします。 キーが作成されると、TBS は仮想ハンドルを読み込まれたキーに関連付けます。 リソースの有効期間中は、同じ仮想ハンドルが使用されます。 仮想キー ハンドルは、仮想キー ハンドルを作成したコンテキストでのみ有効であり、関連付けられているリソースはコンテキストの有効期間を超えて保持されません。

  • TPM_LoadKey2を使用したキーの作成

    TPM_LoadKey2、TPM2_CreatePrimary、TPM2_Load、または TPM2_LoadExternal コマンドを使用してキーが作成された場合、TBS は、返されるバイト ストリーム内のハンドルを、選択した仮想キー ハンドルに置き換えます。 その結果、TBS は各仮想ハンドルが一意であることを保証します。 TBS が競合 (非常に可能性の低いイベント) を検出した場合、TBS は TPM からキーをアンロードし、呼び出し元ソフトウェアに通知します。 その後、ソフトウェアは操作を再送信できます。 このプロセスは、TBS が一意のキー ハンドルを取得するまで繰り返すことができます。

  • キーのクリア

    TBS は、クライアント コンテキストからその仮想ハンドルのTPM_FlushSpecificまたはTPM2_FlushContext メッセージを受信すると、仮想キー ハンドルを無効にします。 フラッシュ メッセージの受信時にキーが TPM に物理的に存在する場合、TBS はその時点で TPM からキーをフラッシュします。

  • キーの一時的な削除

    TPM からキーを削除して新しい項目の余地を作るとき、TBS はキーに対してTPM_SaveContextまたはTPM2_ContextSaveコマンドを実行してから削除します。

  • キーの復元

    読み込まれたキーを参照するコマンドが TBS に送信されると、キーが TPM に物理的に存在することが保証されます。 キーが存在しない場合、TBS はTPM_LoadContextまたはTPM2_ContextLoadを呼び出してキーを復元します。 キーを TPM に復元できない場合、TBS は TPM の結果としてTPM_E_INVALID_KEYHANDLEを返します。

TBS は、コマンド ストリーム内のキーに関連付けられている各仮想ハンドルを、TPM に読み込まれたキーの物理ハンドルに置き換えます。 呼び出し元のコンテキストで TBS によって認識されない仮想ハンドルを使用してコマンドが送信された場合、TBS は呼び出し元のエラー ストリームをTPM_E_INVALID_KEYHANDLE形式にします。

承認セッション

承認セッションは、TPM_OIAP、TPM_OSAP、またはTPM_DSAPを呼び出すことによって作成されます。 いずれの場合も、戻りバイト ストリームには、新しく作成された承認セッションの物理 TPM ハンドルが含まれます。 TBS は、これを仮想ハンドルに置き換えます。 承認セッションが後で参照されると、TBS は、コマンド ストリーム内の仮想ハンドルを承認セッションの物理ハンドルに置き換えます。 TBS は、仮想承認セッションの有効期間が物理承認セッションの有効期間と一致することを保証します。 クライアントが期限切れの仮想ハンドルを使用しようとすると、TBS によってエラー ストリームがエラー TPM_INVALIDAUTHHANDLE形式になります。

セッション スロットは制限されており、TBS では、承認セッション コンテキストを保存する外部スロットが不足する可能性があります。 この場合、TBS は、新しいコンテキストを正常に保存できるように、無効にする承認セッションを選択します。 古いコンテキストを使用しようとするアプリケーションは、承認セッションを再作成する必要があります。

TBS は、次のいずれかの場合に仮想承認セッションを無効にします。

  • TPM から返されたコマンド ストリームの承認セッションに関連付けられている continue-use フラグは、FALSE 。

  • 承認セッションを使用するコマンドは失敗します。

  • コマンドが実行され、コマンドに関連付けられている承認セッションが無効になります (TPM_CreateWrapKeyなど)。

  • OSAP または DSAP セッションに関連付けられているキーは、(このコマンドが TBS または上位レベルのソフトウェアのいずれで発生したかに関係なく) TPM_FlushSpecificまたはTPM2_FlushContextの呼び出しによって TPM から削除されます。

    TBS は、特定の非決定的コマンドが正常に実行された後に承認セッションを自動的に再同期し、TBS 状態が TPM 状態と一致するようにします。 影響を受けるコマンドは次のとおりです。

    • TPM_ORD_Delegate_Manage
    • TPM_ORD_Delegate_CreateOwnerDelegation
    • TPM_ORD_Delegate_LoadOwnerDelegation

次の各ケースでは、TPM の承認セッションが TPM によって自動的にフラッシュされます。

  • 承認セッションの作成

    仮想承認セッション ハンドルは、それらを作成したコンテキストでのみ有効であり、関連付けられたリソースは、関連付けられたコンテキストの有効期間を超えて保持されません。

  • 承認セッションのクリア

    TBS は、クライアント コンテキストから仮想ハンドルのTPM_FlushSpecificまたはTPM2_FlushContextコマンドを受信した場合、仮想承認セッションを無効にします。 フラッシュ コマンドの受信時に承認セッションが TPM に物理的に存在する場合、TBS はすぐに TPM から物理セッションをフラッシュします。

  • 承認セッションの一時的な削除

    TPM から承認セッションを削除して新しいエンティティの空き時間を設定すると、TBS はその承認セッションでTPM_SaveContextまたはTPM2_ContextSaveを実行します。

  • 承認セッションの復元

    承認された TPM コマンドが TBS に送信されると、TBS は、コマンドで参照されるすべての仮想承認セッションが TPM に物理的に存在することを保証します。 承認セッションのいずれかが存在しない場合、TBS は、TPM_LoadContextまたはTPM2_ContextLoadの呼び出しでそれらのセッションを復元します。 承認セッションを TPM に復元できない場合、TBS は TPM の結果としてTPM_E_INVALID_HANDLEを返します。

TBS は、コマンド ストリーム内の承認セッションに関連付けられている各仮想ハンドルを、TPM に読み込まれた承認セッションの物理ハンドルに置き換えます。

呼び出し元のコンテキストで TBS によって認識されない仮想ハンドルを使用してコマンドが送信された場合、TBS はエラー TPM_E_INVALID_HANDLEで呼び出し元のエラー ストリームを書式設定します。

トランスポート セッション

手記

ここで説明するトランスポート セッションの処理は、Windows Vista および Windows Server 2008 に固有です。

 

トランスポート セッションは、ソフトウェア スタックがソフトウェアと TPM の間を通過するコマンド内のデータを暗号化できるようにする TPM によって提供されるメカニズムです。 これにより、敵対者がハードウェア バスを通過する際にデータをインターセプトできなくなります。

大事な

ペイロード データのみが暗号化されます。 実行中のコマンドは引き続き識別できます。

 

残念ながら、このメカニズムにより、TBS がペイロード データを調べることもできなくなります。 ほとんどの場合、これは問題ではありません。TBS はペイロード データではなくハンドルのみを変更するためです。 ただし、たとえばTPM_LoadContextの場合、返されるリソース ハンドルは暗号化によってカバーされます。 そのため、TBS では、トランスポート セッションの対象となるTPM_LoadContext操作を実行できません。

TBS は、トランスポート セッションで次のコマンドをブロックします。

  • TPM_EstablishTransport
  • TPM_ExecuteTransport
  • TPM_Terminate_Handle
  • TPM_LoadKey
  • TPM_EvictKey
  • TPM_SaveKeyContext
  • TPM_LoadKeyContext
  • TPM_SaveAuthContext
  • TPM_LoadAuthContext
  • TPM_SaveContext
  • TPM_LoadContext
  • TPM_FlushSpecific

これらのコマンドのいずれかがトランスポート セッションでカバーされている場合、TBS は TPM の結果としてTPM_E_EMBEDDED_COMMAND_UNSUPPORTEDを返します。

トランスポート セッション ハンドルは、キー ハンドルと承認ハンドルと同様の方法で仮想化されます。 TPM で使用できる保存済みトランスポート セッション コンテキスト スロットの数は限られています。

TBS は、次のいずれかの場合に仮想トランスポート セッションを無効にします。

  • TPM からのリターン コマンド ストリームのトランスポート セッションに関連付けられている continue-use フラグは、FALSE 。

    上記の承認セッションと同様に、TBS は特定の非決定的コマンドが正常に実行された後にトランスポート セッションを自動的に再同期し、TBS 状態が TPM 状態と一致するようにします。 影響を受けるコマンドは次のとおりです。

    • TPM_ORD_Delegate_Manage
    • TPM_ORD_Delegate_CreateOwnerDelegation
    • TPM_ORD_Delegate_LoadOwnerDelegation

これらの各ケースでは、TPM のトランスポート セッションが TPM によって自動的にフラッシュされます。

  • トランスポート セッションの作成

    TBS は、クライアントによって作成されたトランスポート セッションごとに仮想ハンドルを作成します。 仮想トランスポート ハンドルは、それらを作成したコンテキストでのみ有効であり、関連付けられたリソースは、関連付けられたコンテキストの有効期間を超えて保持されません。

  • トランスポート セッションのクリア

    TBS は、クライアント コンテキストから仮想ハンドルのTPM_FlushSpecific コマンドを受け取ると、仮想トランスポート セッションを無効にします。 フラッシュ コマンドの受信時にトランスポート セッションが TPM に物理的に存在する場合、TBS は TPM から物理セッションを直ちにフラッシュします。

  • トランスポート セッションの一時的な削除

    TPM からトランスポート セッションを削除して新しいエンティティの空き時間を設定すると、TBS はそのトランスポート セッションでTPM_SaveContext実行されます。

  • トランスポート セッションの復元

    TPM_ExecuteTransport コマンドが TBS に送信されると、TBS によって、コマンドで参照されるトランスポート セッションが TPM に物理的に存在することが保証されます。 トランスポート セッションが存在しない場合、TBS はTPM_LoadContextの呼び出しで復元します。

TBS は、コマンド ストリーム内のトランスポート セッションに関連付けられている仮想ハンドルを、TPM に読み込まれたトランスポート セッションの物理ハンドルに置き換えます。 呼び出し元のコンテキストで TBS によって認識されない仮想ハンドルを使用してコマンドが送信された場合、TBS は、TPM_E_INVALID_HANDLEを使用して呼び出し元のエラー ストリームを書式設定します。

排他トランスポート セッション

排他的ラップされたトランスポート セッションは、最上位レベルのソフトウェアが、コマンドチェーン中に他のソフトウェアが TPM にアクセスしたかどうかを判断する方法です。 他のソフトウェアが TPM にアクセスするのを防ぐのではなく、トランスポート セッションの作成者に他のアクセスが発生したことを判断する手段を提供するだけです。 TBS は、排他トランスポート セッションを妨げることに固有の何もしませんが、それらと多少互換性がありません。 TBS は透過的であることによって TPM の自然な動作を複製しようとします。そのため、排他的トランスポート セッションを確立するコンテキストからのコマンドは優先されません。 たとえば、クライアント A が排他トランスポート セッションにあるときにクライアント B がコマンドを送信すると、クライアント A の排他トランスポート セッションが無効になります。

TBS によって開始されたコマンドは、排他トランスポート セッションを終了することもできます。 これは、クライアント A が排他的トランスポート セッションにあり、クライアント A によって実行されるコマンドが、TPM に物理的に存在しないリソースを呼び出す場合に発生します。 この状況により、TBS 仮想化マネージャーは、TPM_LoadContext コマンドを実行してそのリソースを提供し、クライアント A の排他トランスポート セッションを終了します。