Ressourcenvirtualisierung

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

Wenn ein instance einer dieser Ressourcen erstellt wird, erstellt der TBS eine virtuelle instance der Ressource und gibt ein Handle an diese virtuelle instance im Ergebnisbefehlsdatenstrom zurück (anstelle des tatsächlichen Handles, das vom TPM zurückgegeben instance). Die TBS verwaltet intern eine Zuordnung zwischen dem virtuellen Handle und dem tatsächlichen Handle. Wenn dem TPM der Speicherplatz für weitere Ressourcen eines bestimmten Typs ausgeht, 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 bei Bedarf andere Ressourcen), bevor der Befehl übermittelt wird.

Die gesamte Virtualisierung im TBS wird im Namen eines bestimmten Kontexts ausgeführt. Jeder Kontext darf nur auf virtuelle Ressourcen zugreifen, die speziell in seinem Namen erstellt wurden, sowie auf die physischen Ressourcen im TPM, das diesen virtuellen Ressourcen entspricht. Standardmäßig ist die Gesamtzahl aller virtualisierten Ressourcen auf 500 beschränkt. Diese Nummer 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 tools Leistungsmonitor beobachtet werden, um die Anzahl der TBS-Ressourcen nachzuverfolgen. Diese Einschränkung ist mit Windows 8 und Windows Server 2012 veraltet.

Eingeschränkte TPM-Ressourcen, die nicht vom TBS virtualisiert werden (z. B. Leistungsindikatoren und NV-Speicher), müssen gemeinsam zwischen Softwarestapeln verwendet werden.

Hinweis

Diese Handlevirtualisierung führt dazu, dass Befehle, die Schlüsselhandles bei der 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 Ressourcengrenzwerte, z. B. der für Schlüssel, Autorisierungssitzungen und Transportsitzungen verfügbare Speicherplatz, werden durch die TBS durch Virtualisierung effektiv erweitert. TBS-Einschränkungen, die durch die Registrierungseinstellung MaxResources 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 ist 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 werden, und bei Bedarf wieder in das TPM geladen werden können. Wenn ein Schlüssel erstellt wird, ordnet die TBS dem geladenen Schlüssel ein virtuelles Handle zu. Das gleiche virtuelle Handle wird für die Lebensdauer der Ressource verwendet. Virtuelle Schlüsselhandles sind nur in dem Kontext gültig, der sie erstellt hat, 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 der TBS das Handle im Rückgabebytestream durch ein virtuelles Schlüsselhandle seiner Wahl. Daher stellt die TBS sicher, dass jedes virtuelle Handle eindeutig ist. Wenn der TBS eine Kollision erkennt (ein äußerst unwahrscheinliches Ereignis), entlädt der TBS den Schlüssel aus dem TPM und informiert die aufrufende Software. Die Software kann den Vorgang dann erneut übermitteln. Dieser Vorgang kann wiederholt werden, bis der TBS ein eindeutiges Schlüsselhandle erhält.

• Löschen von Schlüsseln

  Der TBS ungültigt das Handle des virtuellen Schlüssels, wenn es eine TPM_FlushSpecific- oder TPM2_FlushContext-Nachricht für dieses virtuelle Handle aus dem Clientkontext empfängt. Wenn der Schlüssel physisch im TPM vorhanden ist, wenn die Leerungsmeldung empfangen wird, leert der TBS den Schlüssel zu diesem Zeitpunkt aus dem TPM.

• Vorübergehendes Entfernen von Schlüsseln

  Beim Entfernen eines Schlüssels aus dem TPM, um Platz für ein neues Element zu schaffen, führt der TBS vor dem Entfernen einen TPM_SaveContext- oder TPM2_ContextSave-Befehl für den Schlüssel aus.

• Wiederherstellen von Schlüsseln

  Wenn ein Befehl, der auf einen geladenen Schlüssel verweist, an die TBS übermittelt wird, wird sichergestellt, dass der Schlüssel physisch im TPM vorhanden ist. Wenn der Schlüssel nicht vorhanden ist, wird er vom TBS mit einem Aufruf von TPM_LoadContext oder TPM2_ContextLoad wiederhergestellt. Wenn ein Schlüssel nicht im TPM wiederhergestellt werden kann, gibt der TBS als TPM-Ergebnis TPM_E_INVALID_KEYHANDLE 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 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ückgabebytestream 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 der TBS das virtuelle Handle im Befehlsdatenstrom durch das physische 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 der TBS einen Fehlerdatenstrom mit fehler TPM_INVALIDAUTHHANDLE.

Sitzungsslots sind begrenzt, und die TBS verfügt möglicherweise über keine externen Slots, in denen Autorisierungssitzungskontexte gespeichert werden. In diesem Fall wählt der 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 neu erstellen.

Der TBS ungültig die virtuelle Autorisierungssitzung, wenn einer der folgenden Fälle auftritt:

• Das flag continue-use, das der Autorisierungssitzung im zurückgegebenen Befehlsdatenstrom vom TPM zugeordnet ist, ist FALSE.

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

• Es wird ein Befehl ausgeführt, der die dem Befehl zugeordnete Autorisierungssitzung ungültig macht (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 (ohne Rücksicht darauf, ob dieser Befehl mit dem TBS oder mit höherer 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. Folgende Befehle sind betroffen:

  • 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 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

  Der TBS ungültigt die virtuelle Autorisierungssitzung, wenn er einen TPM_FlushSpecific- oder TPM2_FlushContext-Befehl für das virtuelle Handle aus dem Clientkontext empfängt. Wenn die Autorisierungssitzung beim Empfang des Leerungsbefehls physisch im TPM vorhanden ist, löscht der 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 schaffen, führt der TBS TPM_SaveContext oder TPM2_ContextSave für diese Autorisierungssitzung aus.

• Wiederherstellen von Autorisierungssitzungen

  Wenn ein autorisierter TPM-Befehl an die TBS übermittelt wird, stellt der TBS sicher, dass alle virtuellen Autorisierungssitzungen, auf die im Befehl verwiesen wird, physisch im TPM vorhanden sind. Wenn keine der Autorisierungssitzungen 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 der 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 wird.

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

Hinweis

Die hier beschriebene Behandlung von Transportsitzungen ist spezifisch für 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 Angreifer die Daten abfängt, 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 die TBS Nutzlastdaten untersucht. In den meisten Fällen ist dies kein Problem, da der TBS nur Handles und keine Nutzlastdaten ändert. Im Fall von TPM_LoadContext für instance wird das zurückgegebene Ressourcenhandle jedoch von der Verschlüsselung abgedeckt. Daher verhindert der TBS versuche, 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 einer dieser Befehle von einer Transportsitzung abgedeckt wird, gibt der TBS TPM_E_EMBEDDED_COMMAND_UNSUPPORTED als TPM-Ergebnis zurück.

Transportsitzungshandles werden ähnlich wie Schlüsselhandles und Autorisierungshandles virtualisiert. Im TPM ist eine begrenzte Anzahl gespeicherter Kontextslots für Transportsitzungen verfügbar.

Der TBS ungültig die virtuelle Transportsitzung, wenn einer der folgenden Fälle auftritt:

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

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

  • 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 Transportsitzung, die von einem Client erstellt wird. Virtuelle Transporthandles sind nur im Kontext gültig, der sie erstellt hat, und die zugeordneten Ressourcen werden nicht über die Lebensdauer des zugeordneten Kontexts hinaus beibehalten.

• Löschen von Transportsitzungen

  Der TBS ungültigt die virtuelle Transportsitzung, wenn er einen TPM_FlushSpecific-Befehl für das virtuelle Handle aus dem Clientkontext empfängt. Wenn die Transportsitzung beim Empfang des Leerungsbefehls physisch im TPM vorhanden ist, löscht der TBS die physische Sitzung sofort aus dem TPM.

• Vorübergehendes Entfernen von Transportsitzungen

  Beim Entfernen einer Transportsitzung aus dem TPM, 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 die TBS übermittelt wird, stellt der TBS sicher, dass die transport session, auf die im Befehl verwiesen wird, physisch im TPM vorhanden ist. Wenn die Transportsitzung nicht vorhanden ist, stellt der TBS sie mit einem Aufruf von TPM_LoadContext wiederhergestellt.

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

Exklusive Transportsitzungen

Exklusive umschlossene Transportsitzungen sind eine Möglichkeit für Software auf oberster 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 ein Mittel, um festzustellen, ob ein anderer Zugriff erfolgt ist. Der TBS führt keine spezifischen Aktionen aus, um exklusive Transportsitzungen zu verhindern, ist aber mit ihnen nicht kompatibel. Der TBS versucht, das natürliche Verhalten des TPM zu duplizieren, indem er transparent ist, sodass befehle aus Kontexten, die eine exklusive Transportsitzung einrichten, nicht bevorzugt werden. Wenn Client B beispielsweise einen Befehl übermittelt, wenn sich Client A 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 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 anzugeben, wodurch die exklusive Transportsitzung von Client A beendet wird.