Virtualisation des ressources

La fonction principale du tbS consiste à partager efficacement certaines ressources TPM limitées : clés, autorisation et sessions de transport.

Lorsqu’une instance de l’une de ces ressources est créée, le tbS crée une instance virtuelle de la ressource et retourne un handle à cette instance virtuelle dans le flux de commandes de résultat (plutôt que l’instance de handle réelle retournée par le module TPM). Le tbS gère un mappage entre le handle virtuel et le handle réel en interne. Si le module TPM manque d’espace pour contenir davantage de ressources d’un type donné, les instances existantes de la ressource sont enregistrées de manière sélective et supprimées jusqu’à ce que le module de plateforme sécurisée puisse contenir la nouvelle ressource. Lorsque les anciennes ressources sont à nouveau requises, le service TbS charge les contextes enregistrés (enregistrement et expulsion d’autres ressources si nécessaire) avant d’envoyer la commande.

Toutes les virtualisations dans le tbS sont effectuées au nom d’un contexte spécifique. Chaque contexte est uniquement autorisé à accéder aux ressources virtuelles créées spécifiquement en son nom, ainsi que les ressources physiques sur le module de plateforme sécurisée qui correspond à ces ressources virtuelles. Par défaut, le nombre total de toutes les ressources virtualisées est limité à 500. Ce nombre peut être modifié en créant ou en modifiant une valeur de Registre DWORD nommée MaxResources sous HKEY_LOCAL_MACHINE\Software\Microsoft\Tpm. L’utilisation des ressources TBS en temps réel peut être observée à l’aide de l’outil Analyseur de performances pour suivre le nombre de ressources TBS. Cette restriction est devenue obsolète avec Windows 8 et Windows Server 2012.

Les ressources TPM limitées qui ne sont pas virtualisées par le tbS (par exemple, les compteurs et le magasin NV) doivent être partagées de manière coopérative entre les piles logicielles.

Limites des ressources

Le module TPM permet aux appelants d’interroger ses fonctionnalités pour déterminer la quantité d’espace disponible pour certains types de ressources. Certaines de ces limites de ressources, telles que la quantité d’espace disponible pour les clés, les sessions d’autorisation et les sessions de transport, sont efficacement étendues par le tbS via la virtualisation. Les limitations tbS, contrôlées par les MaxResources paramètre de Registre, sont généralement beaucoup plus importantes que les limitations réelles du matériel TPM sous-jacent. Aucun mécanisme n’est fourni pour interroger les limitations tbS séparément des limites matérielles du module TPM. Cette limitation toS est devenue obsolète avec Windows 8 et Windows Server 2012.

Clés

ToS virtualise les handles de clé afin que les clés puissent être déchargées de manière transparente à partir du module de plateforme sécurisée lorsqu’elles ne sont pas utilisées et chargées sur le module de plateforme sécurisée quand elles sont nécessaires. Lorsqu’une clé est créée, tbS associe un handle virtuel à la clé chargée. Le même handle virtuel est utilisé pour la durée de vie de la ressource. Les handles de clés virtuelles sont valides uniquement dans le contexte qui les a créés, et les ressources associées ne sont pas conservées au-delà de la durée de vie du contexte.

• Création de clés avec TPM_LoadKey2

  Si une clé est créée à l’aide de la commande TPM_LoadKey2, TPM2_CreatePrimary, TPM2_Load ou TPM2_LoadExternal, tbS remplace le handle dans le flux d’octets de retour par un handle de clé virtuelle de son choix. Par conséquent, le tbS garantit que chaque handle virtuel est unique. Si le tbS détecte une collision (un événement extrêmement peu probable), le tbS décharge la clé à partir du module TPM et informe le logiciel appelant. Le logiciel peut ensuite soumettre à nouveau l’opération. Ce processus peut être répété jusqu’à ce que le tbS obtienne un handle de clé unique.

• Effacement des clés

  TbS invalide le handle de clé virtuelle lorsqu’il reçoit un message TPM_FlushSpecific ou TPM2_FlushContext pour ce handle virtuel à partir du contexte client. Si la clé est physiquement présente sur le module de plateforme sécurisée lorsque le message de vidage est reçu, tbS vide la clé du module TPM à ce moment-là.

• Suppression temporaire des clés

  Lors de l’expulsion d’une clé du module de plateforme sécurisée pour créer de la place pour un nouvel élément, tbS exécute une commande TPM_SaveContext ou TPM2_ContextSave sur la clé avant de la supprimer.

• Restauration des clés

  Lorsqu’une commande qui fait référence à une clé chargée est envoyée au service TbS, elle garantit que la clé est physiquement présente sur le module TPM. Si la clé n’est pas présente, le tbS le restaure avec un appel à TPM_LoadContext ou TPM2_ContextLoad. Si une clé ne peut pas être restaurée sur le module de plateforme sécurisée, le service TbS retourne TPM_E_INVALID_KEYHANDLE en tant que résultat du module de plateforme sécurisée.

Le tbS remplace chaque handle virtuel associé à une clé dans un flux de commandes par le handle physique de la clé chargée sur le module TPM. Si une commande est envoyée avec un handle virtuel qui n’est pas reconnu par le tbS dans le contexte de l’appelant, le tbS met en forme un flux d’erreur pour l’appelant avec TPM_E_INVALID_KEYHANDLE.

Sessions d’autorisation

Les sessions d’autorisation sont créées en appelant TPM_OIAP, TPM_OSAP ou TPM_DSAP. Dans chaque cas, le flux d’octets de retour contient le handle TPM physique de la session d’autorisation nouvellement créée. Le tbS remplace cela par un handle virtuel. Lorsque la session d’autorisation est référencée par la suite, le tbS remplace le handle virtuel dans le flux de commandes par le handle physique de la session d’autorisation. Le tbS garantit que la durée de vie de la session d’autorisation virtuelle correspond à celle de la session d’autorisation physique. Si un client tente d’utiliser un handle virtuel expiré, le tbS met en forme un flux d’erreurs avec une erreur TPM_INVALIDAUTHHANDLE.

Les emplacements de session sont limités et le tbS peut manquer d’emplacements externes dans lesquels enregistrer des contextes de session d’autorisation. Si cela se produit, le tbS choisit une session d’autorisation pour invalider afin que le nouveau contexte puisse être enregistré avec succès. Une application qui tente d’utiliser l’ancien contexte doit recréer la session d’autorisation.

Le tbS invalide la session d’autorisation virtuelle lorsque l’un des cas suivants se produit :

• L’indicateur d’utilisation continue associé à la session d’autorisation dans le flux de commande retourné à partir du module de plateforme sécurisée est FALSE.

• Une commande qui utilise une session d’autorisation échoue.

• Une commande est exécutée qui invalide la session d’autorisation associée à la commande (par exemple, TPM_CreateWrapKey).

• Une clé associée à une session OSAP ou DSAP est supprimée du module de plateforme sécurisée avec un appel à TPM_FlushSpecific ou TPM2_FlushContext (sans tenir compte de la provenance de cette commande avec le tbS ou avec un logiciel de niveau supérieur).

  Le tbS resynchronise automatiquement les sessions d’autorisation après l’exécution réussie de certaines commandes non déterministes pour s’assurer que l’état TBS reste cohérent avec l’état TPM. Les commandes affectées sont les suivantes :

  • TPM_ORD_Delegate_Manage
  • TPM_ORD_Delegate_CreateOwnerDelegation
  • TPM_ORD_Delegate_LoadOwnerDelegation

Dans chacun des cas suivants, la session d’autorisation sur le module de plateforme sécurisée est vidée automatiquement par le module de plateforme sécurisée :

• Création de sessions d’autorisation

  Les handles de session d’autorisation virtuelle sont valides uniquement dans le contexte qui les a créés, et les ressources associées ne sont pas conservées au-delà de la durée de vie du contexte associé.

• Effacement des sessions d’autorisation

  TbS invalide la session d’autorisation virtuelle si elle reçoit une commande TPM_FlushSpecific ou TPM2_FlushContext pour le handle virtuel à partir du contexte client. Si la session d’autorisation est physiquement présente sur le module de plateforme sécurisée lorsque la commande de vidage est reçue, le tbS vide immédiatement la session physique du module de plateforme sécurisée.

• Suppression temporaire de sessions d’autorisation

  Lors de l’expulsion d’une session d’autorisation à partir du module TPM pour créer de la place pour une nouvelle entité, tbS exécute TPM_SaveContext ou TPM2_ContextSave sur cette session d’autorisation.

• Restauration de sessions d’autorisation

  Lorsqu’une commande de module de plateforme sécurisée autorisée est envoyée au TST, le ST s’assure que toutes les sessions d’autorisation virtuelle référencées dans la commande sont physiquement présentes sur le module de plateforme sécurisée. Si l’une des sessions d’autorisation n’est pas présente, le tbS les restaure avec un appel à TPM_LoadContext ou TPM2_ContextLoad. Si une session d’autorisation ne peut pas être restaurée sur le module de plateforme sécurisée, le module tbS retourne TPM_E_INVALID_HANDLE en tant que résultat du module de plateforme sécurisée.

Le tbS remplace chaque handle virtuel associé à une session d’autorisation dans un flux de commandes par le handle physique de la session d’autorisation chargée sur le module TPM.

Si une commande est envoyée avec un handle virtuel qui n’est pas reconnu par le tbS dans le contexte de l’appelant, le tbS met en forme un flux d’erreur pour l’appelant avec l’erreur TPM_E_INVALID_HANDLE.

Transport Sessions

Les sessions de transport sont un mécanisme fourni par le module TPM qui permet à une pile logicielle de chiffrer les données dans une commande lors de leur passage entre le logiciel et le module de plateforme sécurisée. Cela empêche un adversaire d’intercepter les données au fur et à mesure qu’il passe sur le bus matériel.

Malheureusement, ce mécanisme empêche également le TBS d’examiner les données de charge utile. Dans la plupart des cas, ce n’est pas un problème, car le tbS modifie uniquement les handles, et non les données de charge utile. Toutefois, dans le cas de TPM_LoadContext par exemple, le handle de ressource retourné est couvert par le chiffrement. Par conséquent, le tbS empêche les tentatives d’exécution d’une opération de TPM_LoadContext couverte par une session de transport.

Le tbS bloque les commandes suivantes sous la session de transport :

• 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

Lorsque l’une de ces commandes est couverte par une session de transport, la fonction TBS retourne TPM_E_EMBEDDED_COMMAND_UNSUPPORTED en tant que résultat du module TPM.

Les handles de session de transport sont virtualisés de manière similaire aux handles de clé et aux handles d’autorisation. Il existe un nombre limité d’emplacements de contexte de session de transport enregistrés disponibles sur le module TPM.

Le tbS invalide la session de transport virtuel si l’un des cas suivants se produit :

• L’indicateur d’utilisation continue associé à la session de transport dans le flux de commandes de retour à partir du module de plateforme sécurisée est FALSE.

  Comme pour les sessions d’autorisation ci-dessus, le tbS resynchronise automatiquement les sessions de transport après l’exécution réussie de certaines commandes non déterministes pour s’assurer que l’état tbS reste cohérent avec l’état TPM. Les commandes affectées sont les suivantes :

  • TPM_ORD_Delegate_Manage
  • TPM_ORD_Delegate_CreateOwnerDelegation
  • TPM_ORD_Delegate_LoadOwnerDelegation

Dans chacun de ces cas, la session de transport sur le module TPM est vidée automatiquement par le module de plateforme sécurisée :

• Création de sessions de transport

  Le tbS crée un handle virtuel pour chaque session de transport créée par un client. Les handles de transport virtuel sont valides uniquement dans le contexte qui les a créés, et les ressources associées ne sont pas conservées au-delà de la durée de vie du contexte associé.

• Effacement des sessions de transport

  TbS invalide la session de transport virtuel si elle reçoit une commande TPM_FlushSpecific pour le handle virtuel à partir du contexte client. Si la session de transport est physiquement présente sur le module de plateforme sécurisée lorsque la commande de vidage est reçue, le service TbS vide immédiatement la session physique du module de plateforme sécurisée.

• Suppression temporaire des sessions de transport

  Lors de l’expulsion d’une session de transport à partir du module de plateforme sécurisée pour créer la place d’une nouvelle entité, tbS exécute TPM_SaveContext sur cette session de transport.

• Restauration de sessions de transport

  Lorsqu’une commande de TPM_ExecuteTransport est envoyée au module TBS, le tbS garantit que la session de transport référencée dans la commande est physiquement présente sur le module TPM. Si la session de transport n’est pas présente, le tbS le restaure avec un appel à TPM_LoadContext.

Le tbS remplace le handle virtuel associé à la session de transport dans un flux de commandes par le handle physique de la session de transport chargée sur le module TPM. Si une commande est envoyée avec un handle virtuel qui n’est pas reconnu par le tbS dans le contexte de l’appelant, le service TBS met en forme un flux d’erreur pour l’appelant à l’aide de TPM_E_INVALID_HANDLE.

Sessions de transport exclusives

Les sessions de transport encapsulées exclusives permettent aux logiciels de niveau supérieur de déterminer si un autre logiciel a accédé au module TPM pendant une chaîne de commandes. Ils n’empêchent pas d’autres logiciels d’accéder au module TPM, ils donnent simplement au créateur de la session de transport un moyen de déterminer qu’un autre accès s’est produit. Le TBS ne fait rien de spécifique pour entraver les sessions de transport exclusives, mais il est quelque peu incompatible avec eux. Le tbS tente de dupliquer le comportement naturel du TPM en étant transparent, il ne favorise donc pas les commandes provenant de contextes qui établissent une session de transport exclusive. Par exemple, si le client B envoie une commande lorsque le client A se trouve dans une session de transport exclusive, il invalide la session de transport exclusive du client A.

Les commandes lancées par TBS peuvent également mettre fin à la session de transport exclusive. Cela se produit lorsque le client A se trouve dans une session de transport exclusive et qu’une commande exécutée par le client A appelle une ressource qui n’est pas physiquement présente dans le TPM. Cette situation déclenche le gestionnaire de virtualisation TBS pour exécuter une commande TPM_LoadContext pour fournir cette ressource, ce qui met fin à la session de transport exclusive du client A.