Ressourcenvirtualisierung

Die Hauptfunktion des TBS besteht darin, bestimmte eingeschränkte TPM-Ressourcen effizient gemeinsam zu nutzen: Schlüssel, Autorisierung und Transportsitzungen.

Wenn eine Instanz dieser Ressourcen erstellt wird, erstellt TBS eine virtuelle Instanz der Ressource und gibt ein Handle an diese virtuelle Instanz im Ergebnisbefehlsstream zurück (und nicht die tatsächliche Handleinstanz, die vom TPM zurückgegeben wird). Der TBS verwaltet eine Zuordnung zwischen dem virtuellen Handle und dem tatsächlichen Handle intern. Wenn das TPM nicht mehr Ressourcen eines bestimmten Typs enthält, werden vorhandene Instanzen der Ressource selektiv gespeichert und entfernt, bis das TPM die neue Ressource enthalten kann. Wenn die alten Ressourcen erneut benötigt werden, lädt der TBS die gespeicherten Kontexte (speichern und entfernen sie ggf. andere Ressourcen), bevor der Befehl übermittelt wird.

Die gesamte Virtualisierung im TBS wird im Auftrag eines bestimmten Kontexts ausgeführt. Jeder Kontext darf nur auf virtuelle Ressourcen zugreifen, die speziell in seinem Auftrag erstellt wurden, sowie auf die physischen Ressourcen im TPM, die diesen virtuellen Ressourcen entsprechen. Standardmäßig ist die Gesamtanzahl aller virtualisierten Ressourcen auf 500 beschränkt. Diese Zahl kann durch Erstellen oder Ändern eines DWORD- Registrierungswerts mit dem Namen MaxResources unter HKEY_LOCAL_MACHINE\Software\Microsoft\Tpm-geändert werden. Die Verwendung von TBS-Ressourcen in Echtzeit kann mithilfe des Tools "Leistungsüberwachung" beobachtet werden, um die Anzahl der TBS-Ressourcen nachzuverfolgen. Diese Einschränkung wurde mit Windows 8 und Windows Server 2012 veraltet.

Eingeschränkte TPM-Ressourcen, die nicht vom TBS (z. B. Zähler und NV-Speicher) virtualisiert werden, müssen kooperativ zwischen Softwarestapeln geteilt werden.

Ressourcenbeschränkungen

Mit dem TPM können Aufrufer ihre Funktionen abfragen, um zu bestimmen, wie viel Speicherplatz für bestimmte Ressourcentypen verfügbar ist. Einige dieser Ressourcenbeschränkungen, z. B. die Menge des verfügbaren Speicherplatzes für Schlüssel, Autorisierungssitzungen und Transportsitzungen, werden effektiv durch die TBS durch Virtualisierung erweitert. TBS-Einschränkungen, die durch die MaxResources Registrierungseinstellung gesteuert werden, sind in der Regel weit größer als die tatsächlichen Einschränkungen der zugrunde liegenden TPM-Hardware. Es wird kein Mechanismus zum Abfragen von TBS-Einschränkungen getrennt von den TPM-Hardwaregrenzwerten bereitgestellt. Diese TBS-Einschränkung wurde mit Windows 8 und Windows Server 2012 veraltet.

Tasten

Der TBS virtualisiert Schlüsselhandles, sodass Schlüssel transparent aus dem TPM entladen werden können, wenn sie nicht verwendet und bei Bedarf wieder auf das TPM geladen werden. Wenn ein Schlüssel erstellt wird, ordnet tbS dem geladenen Schlüssel ein virtuelles Handle zu. Dasselbe virtuelle Handle wird für die Lebensdauer der Ressource verwendet. Virtuelle Schlüsselhandles sind nur im Kontext gültig, in dem sie erstellt wurden, und die zugehörigen Ressourcen bleiben nicht über die Lebensdauer des Kontexts hinaus erhalten.

• Erstellen von Schlüsseln mit TPM_LoadKey2

  Wenn ein Schlüssel mithilfe des Befehls TPM_LoadKey2, TPM2_CreatePrimary, TPM2_Load oder TPM2_LoadExternal erstellt wird, ersetzt TBS das Handle im Rückgabebytedatenstrom durch ein virtuelles Schlüsselhandle der Auswahl. Daher stellt der TBS sicher, dass jeder virtuelle Handle eindeutig ist. Wenn der TBS eine Kollision erkennt (ein extrem unwahrscheinliches Ereignis), entlädt tbS den Schlüssel aus dem TPM und informiert die aufrufende Software. Die Software kann dann den Vorgang erneut übermitteln. Dieser Vorgang kann wiederholt werden, bis der TBS ein eindeutiges Schlüsselhandle erhält.

• Löschen von Schlüsseln

  TbS ungültig das Handle des virtuellen Schlüssels, wenn er eine TPM_FlushSpecific oder TPM2_FlushContext Nachricht für dieses virtuelle Handle aus dem Clientkontext empfängt. Wenn der Schlüssel beim Empfang der leeren Nachricht physisch auf dem TPM vorhanden ist, löscht TBS den Schlüssel zu diesem Zeitpunkt vom TPM.

• Vorübergehendes Entfernen von Schlüsseln

  Wenn Sie einen Schlüssel aus dem TPM entfernen, um Platz für ein neues Element zu schaffen, führt TBS einen TPM_SaveContext- oder TPM2_ContextSave-Befehl auf der Taste aus, bevor sie entfernt wird.

• Wiederherstellen von Schlüsseln

  Wenn ein Befehl, der auf einen geladenen Schlüssel verweist, an tbS übermittelt wird, wird sichergestellt, dass der Schlüssel physisch im TPM vorhanden ist. Wenn der Schlüssel nicht vorhanden ist, stellt der TBS ihn mit einem Aufruf von TPM_LoadContext oder TPM2_ContextLoad wieder her. Wenn ein Schlüssel nicht im TPM wiederhergestellt werden kann, gibt TBS TPM_E_INVALID_KEYHANDLE als TPM-Ergebnis zurück.

Der TBS ersetzt jedes virtuelle Handle, das einem Schlüssel in einem Befehlsdatenstrom zugeordnet ist, durch den physischen Handle des schlüssels, der im TPM geladen wurde. Wenn ein Befehl mit einem virtuellen Handle übermittelt wird, das vom TBS im Kontext des Aufrufers nicht erkannt wird, formatiert der TBS einen Fehlerdatenstrom für den Aufrufer mit TPM_E_INVALID_KEYHANDLE.

Autorisierungssitzungen

Autorisierungssitzungen werden durch Aufrufen von TPM_OIAP, TPM_OSAP oder TPM_DSAP erstellt. In jedem Fall enthält der Rückgabebytedatenstrom das physische TPM-Handle der neu erstellten Autorisierungssitzung. Der TBS ersetzt dies durch ein virtuelles Handle. Wenn anschließend auf die Autorisierungssitzung verwiesen wird, ersetzt TBS den virtuellen Handle im Befehlsstream durch den physischen Handle der Autorisierungssitzung. Der TBS stellt sicher, dass die Lebensdauer der virtuellen Autorisierungssitzung mit der der physischen Autorisierungssitzung übereinstimmt. Wenn ein Client versucht, ein abgelaufenes virtuelles Handle zu verwenden, formatiert TBS einen Fehlerdatenstrom mit fehler TPM_INVALIDAUTHHANDLE.

Sitzungsplätze sind begrenzt, und der TBS kann keine externen Slots mehr haben, in denen Autorisierungssitzungskontexte gespeichert werden. In diesem Fall wählt TBS eine Autorisierungssitzung aus, die ungültig wird, damit der neue Kontext erfolgreich gespeichert werden kann. Eine Anwendung, die versucht, den alten Kontext zu verwenden, muss die Autorisierungssitzung erneut erstellen.

TbS ungültigt die virtuelle Autorisierungssitzung, wenn eine der folgenden Fälle auftritt:

• Das weiterverwendende Flag, das der Autorisierungssitzung im zurückgegebenen Befehlsdatenstrom aus dem TPM zugeordnet ist, ist FALSE.

• Ein Befehl, der eine Autorisierungssitzung verwendet, schlägt fehl.

• Ein Befehl wird ausgeführt, der die dem Befehl zugeordnete Autorisierungssitzung ungültig macht (z. B. TPM_CreateWrapKey).

• Ein mit einer OSAP- oder DSAP-Sitzung verknüpfter Schlüssel wird vom TPM mit einem Aufruf von TPM_FlushSpecific oder TPM2_FlushContext entfernt (ohne Rücksicht darauf, ob dieser Befehl mit dem TBS oder mit Software auf höherer Ebene stammt).

  TbS synchronisiert die Autorisierungssitzungen automatisch nach erfolgreicher Ausführung bestimmter nichtdeterministischer Befehle erneut, um sicherzustellen, dass der TBS-Zustand mit dem TPM-Zustand konsistent bleibt. Die betroffenen Befehle sind:

  • TPM_ORD_Delegate_Manage
  • TPM_ORD_Delegate_CreateOwnerDelegation
  • TPM_ORD_Delegate_LoadOwnerDelegation

In jedem der folgenden Fälle wird die Autorisierungssitzung im TPM automatisch vom TPM geleert:

• Erstellen von Autorisierungssitzungen

  Virtuelle Autorisierungssitzungshandles sind nur im Kontext gültig, in dem sie erstellt wurden, und die zugehörigen Ressourcen bleiben nicht über die Lebensdauer des zugeordneten Kontexts hinaus erhalten.

• Löschen von Autorisierungssitzungen

  Der TBS ungültigt die virtuelle Autorisierungssitzung, wenn sie einen TPM_FlushSpecific oder TPM2_FlushContext Befehl für das virtuelle Handle aus dem Clientkontext empfängt. Wenn die Autorisierungssitzung physisch auf dem TPM vorhanden ist, wenn der Befehl zum Leeren empfangen wird, löscht TBS die physische Sitzung sofort vom TPM.

• Vorübergehendes Entfernen von Autorisierungssitzungen

  Wenn Eine Autorisierungssitzung aus dem TPM entfernt wird, um Platz für eine neue Entität zu schaffen, führt tbS TPM_SaveContext oder TPM2_ContextSave für diese Autorisierungssitzung aus.

• Wiederherstellen von Autorisierungssitzungen

  Wenn ein autorisierter TPM-Befehl an TBS übermittelt wird, stellt TBS sicher, dass alle im Befehl genannten virtuellen Autorisierungssitzungen physisch auf dem TPM vorhanden sind. Wenn eine der Autorisierungssitzungen nicht vorhanden ist, stellt der TBS sie mit einem Aufruf von TPM_LoadContext oder TPM2_ContextLoad wieder her. Wenn eine Autorisierungssitzung nicht im TPM wiederhergestellt werden kann, gibt TBS TPM_E_INVALID_HANDLE als TPM-Ergebnis zurück.

TbS ersetzt jedes virtuelle Handle, das einer Autorisierungssitzung in einem Befehlsstream zugeordnet ist, durch den physischen Handle der Autorisierungssitzung, die auf das TPM geladen wurde.

Wenn ein Befehl mit einem virtuellen Handle übermittelt wird, das vom TBS im Kontext des Aufrufers nicht erkannt wird, formatiert der TBS einen Fehlerdatenstrom für den Aufrufer mit dem Fehler TPM_E_INVALID_HANDLE.

Transportsitzungen

Transportsitzungen sind ein Vom TPM bereitgestellter Mechanismus, der es einem Softwarestapel ermöglicht, Daten in einem Befehl zu verschlüsseln, während er zwischen der Software und dem TPM übergeben wird. Dadurch wird verhindert, dass ein Angreifer die Daten abfangen kann, wenn er über den Hardwarebus übergeht.

Leider verhindert dieser Mechanismus auch, dass tbS Nutzlastdaten untersucht. In den meisten Fällen ist dies kein Problem, da die TBS nur Handles ändert und keine Nutzlastdaten. Im Fall von TPM_LoadContext wird der zurückgegebene Ressourcenhandle jedoch von der Verschlüsselung abgedeckt. Daher verhindert tbS, dass versucht wird, einen TPM_LoadContext Vorgang auszuführen, der von einer Transportsitzung abgedeckt wird.

Der TBS blockiert die folgenden Befehle in der Transportsitzung:

• 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

Wenn eines dieser Befehle von einer Transportsitzung abgedeckt wird, gibt TBS TPM_E_EMBEDDED_COMMAND_UNSUPPORTED als TPM-Ergebnis zurück.

Transportsitzungshandles werden ähnlich wie Schlüsselhandles und Autorisierungshandles virtualisiert. Es gibt eine begrenzte Anzahl gespeicherter Transportsitzungskontextplätze, die im TPM verfügbar sind.

Die TBS ungültigt die virtuelle Transportsitzung, wenn eine der folgenden Fälle auftritt:

• Das weiterverwendende Flag, das der Transportsitzung im Rückgabebefehlsdatenstrom aus dem TPM zugeordnet ist, ist FALSE.

  Wie bei den oben genannten Autorisierungssitzungen synchronisiert TBS transportsitzungen automatisch nach erfolgreicher Ausführung bestimmter nicht deterministischer Befehle, um sicherzustellen, dass der TBS-Zustand mit dem TPM-Zustand konsistent bleibt. Die betroffenen Befehle sind:

  • TPM_ORD_Delegate_Manage
  • TPM_ORD_Delegate_CreateOwnerDelegation
  • TPM_ORD_Delegate_LoadOwnerDelegation

In jedem dieser Fälle wird die Transportsitzung im TPM automatisch vom TPM geleert:

• Erstellen von Transportsitzungen

  Der TBS erstellt ein virtuelles Handle für jede von einem Client erstellte Transportsitzung. Virtuelle Transporthandles sind nur im Kontext gültig, in dem sie erstellt wurden, und die zugehörigen Ressourcen bleiben nicht über die Lebensdauer des zugeordneten Kontexts hinaus erhalten.

• Löschen von Transportsitzungen

  Der TBS ungültigt die virtuelle Transportsitzung, wenn sie einen TPM_FlushSpecific Befehl für das virtuelle Handle aus dem Clientkontext empfängt. Wenn die Transportsitzung physisch auf dem TPM vorhanden ist, wenn der Befehl zum Leeren empfangen wird, löscht TBS die physische Sitzung sofort vom TPM.

• Vorübergehendes Entfernen von Transportsitzungen

  Wenn Sie eine Transportsitzung aus dem TPM entfernen, um Platz für eine neue Entität zu schaffen, führt tbS TPM_SaveContext für diese Transportsitzung aus.

• Wiederherstellen von Transportsitzungen

  Wenn ein TPM_ExecuteTransport-Befehl an tbS übermittelt wird, stellt tbS sicher, dass die transportsitzung, auf die im Befehl verwiesen wird, physisch im TPM vorhanden ist. Wenn die Transportsitzung nicht vorhanden ist, stellt tbS sie mit einem Aufruf von TPM_LoadContext wieder her.

TbS ersetzt das virtuelle Handle, das der Transportsitzung in einem Befehlsstream zugeordnet ist, durch den physischen Handle der transportsitzung, die auf das TPM geladen wurde. Wenn ein Befehl mit einem virtuellen Handle übermittelt wird, das vom TBS im Kontext des Aufrufers nicht erkannt wird, formatiert der TBS einen Fehlerdatenstrom für den Aufrufer mithilfe von TPM_E_INVALID_HANDLE.

Exklusive Transportsitzungen

Exklusive umschlossene Transportsitzungen sind eine Möglichkeit für Software auf oberster Ebene, um zu bestimmen, ob während einer Befehlskette auf das TPM zugegriffen wurde. Sie verhindern nicht, dass andere Software auf das TPM zugreift, sie geben dem Ersteller der Transportsitzung lediglich die Möglichkeit, zu bestimmen, dass ein anderer Zugriff aufgetreten ist. Der TBS führt keine spezifischen Aktionen aus, um exklusive Transportsitzungen zu verhindern, aber es ist etwas inkompatibel mit ihnen. Die TBS versucht, das natürliche Verhalten des TPM zu duplizieren, indem es transparent ist, sodass Befehle aus Kontexten, die eine exklusive Transportsitzung herstellen, nicht bevorzugt werden. Wenn client B beispielsweise einen Befehl sendet, wenn client A sich in einer exklusiven Transportsitzung befindet, wird die exklusive Transportsitzung von Client A ungültig.

Befehle, die von TBS initiiert werden, können auch die exklusive Transportsitzung beenden. Dies geschieht, wenn sich Client A in einer exklusiven Transportsitzung befindet, und ein Befehl, der von Client A ausgeführt wird, für eine Ressource, die nicht physisch im TPM vorhanden ist. Diese Situation löst den TBS-Virtualisierungs-Manager aus, um einen TPM_LoadContext Befehl auszuführen, um diese Ressource zu liefern, wodurch die exklusive Transportsitzung von Client A beendet wird.