Ressourcenvirtualisierung
Die primäre Funktion von TBS besteht in der effizienten Freigabe bestimmter eingeschränkter TPM-Ressourcen: Schlüssel, Autorisierung und Transportsitzungen.
Wenn eine Instanz einer dieser Ressourcen erstellt wird, erstellt TBS eine virtuelle Instanz der Ressource und gibt ein Handle an diese virtuelle Instanz im Ergebnisbefehlsstream zurück (anstelle der tatsächlichen Handleinstanz, die vom TPM zurückgegeben wird). Der TBS verwaltet intern eine Zuordnung zwischen dem virtuellen Handle und dem tatsächlichen Handle. Wenn für das TPM nicht mehr Speicherplatz verfügbar ist, um mehr Ressourcen eines bestimmten Typs zu speichern, werden vorhandene Instanzen der Ressource selektiv gespeichert und gelöscht, bis das TPM die neue Ressource speichern kann. Wenn die alten Ressourcen erneut benötigt werden, lädt tbs die gespeicherten Kontexte (speichern und gegebenenfalls andere Ressourcen), bevor der Befehl übermitteln wird.
Die virtualisierungsspezifische Virtualisierung im TBS erfolgt im Namen eines bestimmten Kontexts. Jeder Kontext darf nur auf virtuelle Ressourcen zugreifen, die speziell in seinem Namen erstellt wurden, sowie auf die physischen Ressourcen auf dem TPM, die diesen virtuellen Ressourcen entsprechen. Standardmäßig ist die Gesamtzahl aller virtualisierten Ressourcen auf 500 beschränkt. Diese Zahl kann durch Erstellen oder Ändern eines DWORD-Registrierungswerts namens MaxResources unter HKEY _ LOCAL _ MACHINE \ Software Microsoft Tpm \ \ geändert werden. Die TbS-Ressourcennutzung in Echtzeit kann mithilfe des Leistungsmonitor zur Nachverfolgung der Anzahl von TBS-Ressourcen beobachtet werden. Diese Einschränkung wurde mit Windows 8 und Windows Server 2012.
Eingeschränkte TPM-Ressourcen, die nicht vom TBS virtualisiert werden (z. B. Leistungsindikatoren und NV-Speicher), müssen von Softwarestapeln kooperativ gemeinsam genutzt werden.
Hinweis
Diese Handlevirtualisierung bewirkt, dass Befehle, die Schlüsselhandles in die Berechnung von HMAC-Autorisierungsparametern enthalten, fehlschlagen. Daher können viele Befehle, die in TPM-Version 1.2 veraltet sind, nicht von Anwendungssoftware in der TBS-Umgebung verwendet werden.
Ressourceneinschrä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 Ressourcenlimits, z. B. die Menge des verfügbaren Speicherplatzes für Schlüssel, Autorisierungssitzungen und Transportsitzungen, werden durch TBS durch Virtualisierung effektiv erweitert. TBS-Einschränkungen, die durch die MaxResources-Registrierungseinstellung gesteuert werden, sind in der Regel deutlich 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.
Schlüssel
Der TBS virtualisiert Schlüsselhandles, sodass Schlüssel transparent aus dem TPM entladen werden können, wenn sie nicht verwendet und bei Bedarf wieder in 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 in dem Kontext gültig, in dem sie erstellt wurden, und die zugeordneten Ressourcen werden nicht über die Lebensdauer des Kontexts hinaus beibehalten.
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ückgabe-Bytestream durch ein virtuelles Schlüsselhandl seiner _ Wahl. Dadurch stellt TBS sicher, dass jedes virtuelle Handle eindeutig ist. Wenn der TBS einen Kollisionsfall erkennt (ein äußerst unwahrscheinliches Ereignis), entlädt TBS den Schlüssel aus dem TPM und informiert die aufrufende Software. Die Software kann den Vorgang dann erneut senden. Dieser Prozess kann wiederholt werden, bis TBS ein eindeutiges Schlüsselhand handle erhält.
Löschen von Schlüsseln
Der TBS macht das Handle des virtuellen Schlüssels ungültig, wenn eine TPM _ FlushSpecific- oder TPM2 FlushContext-Nachricht für dieses virtuelle Handle aus dem _ Clientkontext empfangen wird. Wenn der Schlüssel physisch auf dem TPM vorhanden ist, wenn die Leerungsnachricht empfangen wird, leert TBS den Schlüssel zu diesem Zeitpunkt aus dem TPM.
Vorübergehendes Entfernen von Schlüsseln
Beim Löschen eines Schlüssels aus dem TPM, um Platz für ein neues Element zu machen, führt tbs einen TPM _ SaveContext- oder TPM2 ContextSave-Befehl für den Schlüssel aus, bevor er entfernt _ wird.
Wiederherstellen von Schlüsseln
Wenn ein Befehl, der auf einen geladenen Schlüssel verweist, an den TBS übermittelt wird, wird sichergestellt, dass der Schlüssel physisch im TPM vorhanden ist. Wenn der Schlüssel nicht vorhanden ist, stellt tbs ihn mit einem Aufruf von TPM _ LoadContext oder TPM2 _ ContextLoad wieder auf. Wenn ein Schlüssel nicht auf dem 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 Befehlsstream zugeordnet ist, durch das physische Handle des Schlüssels, der 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 Fehlerstream 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ückgabe-Bytestream 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 das virtuelle Handle im Befehlsstream durch das physische Handle der Autorisierungssitzung. Der TBS stellt sicher, dass die Lebensdauer der virtuellen Autorisierungssitzung mit der der physischen Autorisierungssitzung abspricht. Wenn ein Client versucht, ein abgelaufenes virtuelles Handle zu verwenden, formatiert tbs einen Fehlerdatenstrom mit dem Fehler TPM _ INVALIDAUTHHANDLE.
Sitzungsslots sind begrenzt, und für TBS sind möglicherweise keine externen Slots mehr verfügbar, in denen Autorisierungssitzungskontexte gespeichert werden können. In diesem Fall wählt tbs eine Autorisierungssitzung aus, die ungültig gemacht werden soll, damit der neue Kontext erfolgreich gespeichert werden kann. Eine Anwendung, die versucht, den alten Kontext zu verwenden, muss die Autorisierungssitzung neu erstellen.
Der TBS macht die virtuelle Autorisierungssitzung ungültig, wenn einer der folgenden Fälle eintritt:
Das flag continue-use, das der Autorisierungssitzung im zurückgegebenen Befehlsstream vom 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 für ungültig erklärt (z. B. TPM _ CreateWrapKey).
Ein Schlüssel, der einer OSAP- oder DSAP-Sitzung zugeordnet ist, wird mit einem Aufruf von TPM FlushSpecific oder TPM2 FlushContext aus dem TPM entfernt (unabhängig davon, ob dieser Befehl aus dem TBS oder einer höheren Software _ _ stammt).
Der TBS synchronisiert die Autorisierungssitzungen nach erfolgreicher Ausführung bestimmter nicht deterministischer Befehle automatisch neu, um sicherzustellen, dass der TBS-Zustand mit dem TPM-Zustand konsistent bleibt. Die betroffenen Befehle sind:
- TPM _ _ ORD-Delegat _ verwalten
- TPM _ _ ORD-Delegat _ CreateOwnerDelegation
- TPM _ _ ORD-Delegat _ LoadOwnerDelegation
In jedem der folgenden Fälle wird die Autorisierungssitzung auf dem TPM automatisch vom TPM geleert:
Erstellen von Autorisierungssitzungen
Virtuelle Autorisierungssitzungshandles sind nur in dem Kontext gültig, in dem sie erstellt wurden, und die zugeordneten Ressourcen werden nicht über die Lebensdauer des zugeordneten Kontexts hinaus beibehalten.
Löschen von Autorisierungssitzungen
TbS macht die virtuelle Autorisierungssitzung ungültig, 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 Flush-Befehl empfangen wird, leert TBS die physische Sitzung sofort aus dem TPM.
Vorübergehendes Entfernen von Autorisierungssitzungen
Wenn eine Autorisierungssitzung aus dem TPM entfernt wird, um Platz für eine neue Entität zu machen, führt TBS TPM SaveContext oder TPM2 ContextSave in dieser _ Autorisierungssitzung _ aus.
Wiederherstellen von Autorisierungssitzungen
Wenn ein autorisierter TPM-Befehl an tbs übermittelt wird, stellt tbs sicher, dass alle virtuellen Autorisierungssitzungen, auf die im Befehl verwiesen wird, physisch auf dem TPM vorhanden sind. Wenn keine der Autorisierungssitzungen vorhanden ist, stellt TBS sie mit einem Aufruf von TPM _ LoadContext oder TPM2 _ ContextLoad wieder wieder auf. Wenn eine Autorisierungssitzung nicht auf dem TPM wiederhergestellt werden kann, gibt TBS TPM _ E INVALID HANDLE als _ _ TPM-Ergebnis zurück.
Der TBS ersetzt jedes virtuelle Handle, das einer Autorisierungssitzung in einem Befehlsstream zugeordnet ist, durch das physische 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 tbs einen Fehlerstream für den Aufrufer mit dem Fehler TPM _ E _ INVALID _ HANDLE.
Transportsitzungen
Hinweis
Die Hier beschriebene Verarbeitung von Transportsitzungen beträgt Windows Vista und Windows Server 2008.
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 übergeht. Dadurch wird verhindert, dass ein Kontrahent die Daten abfing, während er den Hardwarebus übergibt.
Wichtig
Nur die Nutzlastdaten werden verschlüsselt. Die ausgeführten Befehle können weiterhin identifiziert werden.
Leider verhindert dieser Mechanismus auch, dass der TBS Nutzlastdaten untersucht. In den meisten Fällen ist dies kein Problem, da der TBS nur Handles und nicht Nutzlastdaten ändert. Im Fall von TPM LoadContext wird das zurückgegebene Ressourcenhand handle _ jedoch durch die Verschlüsselung abgedeckt. Daher verhindert TBS Versuche, einen TPM _ LoadContext-Vorgang auszuführen, der von einer Transportsitzung abgedeckt wird.
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 einer 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. Auf dem TPM ist eine begrenzte Anzahl von gespeicherten Transportsitzungskontextslots verfügbar.
Der TBS macht die virtuelle Transportsitzung ungültig, wenn einer der folgenden Fälle auftritt:
Das flag continue-use, das der Transportsitzung im Rückgabebefehlsstream des TPM zugeordnet ist, ist FALSE.
Wie bei autorisierungssitzungen oben synchronisiert der TBS Transportsitzungen nach erfolgreicher Ausführung bestimmter nicht deterministischer Befehle automatisch erneut, um sicherzustellen, dass der TBS-Status mit dem TPM-Zustand konsistent bleibt. Die folgenden Befehle sind betroffen:
- TPM _ ORD _ Delegate _ Manage
- TPM _ ORD _ Delegate _ CreateOwnerDelegation
- TPM _ ORD _ Delegate _ LoadOwnerDelegation
In jedem dieser Fälle wird die Transportsitzung auf dem TPM automatisch vom TPM geleert:
Erstellen von Transportsitzungen
Der TBS erstellt ein virtuelles Handle für jede Transportsitzung, die von einem Client erstellt wird. Virtuelle Transporthandles sind nur in dem Kontext gültig, in dem sie erstellt wurden, und die zugeordneten Ressourcen werden nicht über die Lebensdauer des zugeordneten Kontexts hinaus beibehalten.
Löschen von Transportsitzungen
Der TBS macht die virtuelle Transportsitzung ungültig, wenn er 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 Flush-Befehl empfangen wird, leert der TBS die physische Sitzung sofort aus dem TPM.
Vorübergehendes Entfernen von Transportsitzungen
Beim Löschen einer Transportsitzung aus dem TPM, um Platz für eine neue Entität zu schaffen, führt der TBS TPM _ SaveContext für diese Transportsitzung aus.
Wiederherstellen von Transportsitzungen
Wenn ein _ TPM-ExecuteTransport-Befehl an den TBS übermittelt wird, stellt der TBS sicher, dass die Transportsitzung, auf die im Befehl verwiesen wird, physisch auf dem TPM vorhanden ist. Wenn die Transportsitzung nicht vorhanden ist, stellt der TBS sie mit einem Aufruf von TPM LoadContext wieder _ her.
Der TBS ersetzt das virtuelle Handle, das der Transportsitzung in einem Befehlsstream zugeordnet ist, durch das physische Handle der Transportsitzung, die auf dem 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 Fehlerstream für den Aufrufer mit TPM _ E _ INVALID _ HANDLE.
Exklusive Transportsitzungen
Exklusive, umschlossene Transportsitzungen sind eine Möglichkeit für Software der obersten Ebene, um zu bestimmen, ob eine andere Software während einer Befehlskette auf das TPM zugegriffen hat. Sie verhindern nicht, dass andere Software auf das TPM zugreift, sie geben dem Ersteller der Transportsitzung lediglich eine Möglichkeit, zu bestimmen, ob ein anderer Zugriff erfolgt ist. Der TBS unternimmt keine spezifischen Spezifischen, um exklusive Transportsitzungen zu beeinträchtigen, ist jedoch etwas inkompatibel. Der TBS versucht, das natürliche Verhalten des TPM zu duplizieren, indem er transparent ist, sodass er keine Befehle aus Kontexten bevorzugt, die eine exklusive Transportsitzung einrichten. Wenn z. B. Client B einen Befehl sendet, wenn client A sich in einer exklusiven Transportsitzung befindet, wird die exklusive Transportsitzung von Client A ungültig.
Von TBS initiierte Befehle können auch die exklusive Transportsitzung beenden. Dies geschieht, wenn sich Client A in einer exklusiven Transportsitzung befindet und ein von Client A ausgeführter Befehl eine Ressource aufruft, die nicht physisch im TPM vorhanden ist. Diese Situation löst den TBS-Virtualisierungs-Manager aus, einen TPM _ LoadContext-Befehl auszuführen, um diese Ressource zur Verfügung zu stellen, wodurch die exklusive Transportsitzung von Client A beendet wird.