Virtualisation des ressources

La fonction principale du TBS est de partager efficacement certaines ressources TPM limitées : clés, autorisations 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 le handle réel instance retourné par le module de plateforme sécurisée). Le TBS gère un mappage entre le handle virtuel et le handle réel en interne. Si le module de plateforme sécurisée manque d’espace pour contenir davantage de ressources d’un type donné, les instances existantes de la ressource sont enregistrées et supprimées de manière sélective jusqu’à ce que le module de plateforme sécurisée puisse contenir la nouvelle ressource. Lorsque les anciennes ressources sont à nouveau nécessaires, le TBS charge les contextes enregistrés (enregistrement et suppression d’autres ressources si nécessaire) avant d’envoyer la commande.

Toute la virtualisation dans le TBS est effectuée pour le compte d’un contexte spécifique. Chaque contexte est uniquement autorisé à accéder aux ressources virtuelles créées spécifiquement en son nom, ainsi qu’aux 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 du SCT. 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 SCT (comme les compteurs et le magasin NV) doivent être partagées en coopération entre les piles de logiciels.

Limites de ressources

Le module de plateforme sécurisée permet aux appelants d’interroger ses fonctionnalités afin de 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 effectivement étendues par le SCT via la virtualisation. Les limitations tbS, qui sont contrôlées par le paramètre de Registre MaxResources , sont généralement bien plus grandes que les limitations réelles du matériel TPM sous-jacent. Aucun mécanisme n’est fourni pour interroger les limitations de TBS séparément des limites matérielles du module de plateforme sécurisée. Cette limitation du SCT est devenue obsolète avec Windows 8 et Windows Server 2012.

Touches

Le TBS virtualise les handles de clé afin que les clés puissent être déchargées en toute transparence à partir du module TPM lorsqu’elles ne sont pas utilisées et chargées à nouveau sur le module de plateforme sécurisée quand elles sont nécessaires. Lorsqu’une clé est créée, le SCT associe un handle virtuel à la clé chargée. Le même handle virtuel est utilisé pendant la durée de vie de la ressource. Les handles de clé virtuelle ne sont valides que 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, le sct 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 SCT détecte une collision (événement extrêmement improbable), le SCT décharge la clé du module de plateforme sécurisée et informe le logiciel appelant. Le logiciel peut ensuite renvoyer 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

  Le TBS invalide le handle de clé virtuelle lorsqu’il reçoit un message TPM_FlushSpecific ou TPM2_FlushContext pour ce handle virtuel 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, le TBS vide la clé du module de plateforme sécurisée à ce moment-là.

• Suppression temporaire de clés

  Lors de la suppression d’une clé du module de plateforme sécurisée pour faire de l’espace pour un nouvel élément, le SCT exécute une commande TPM_SaveContext ou TPM2_ContextSave sur la clé avant de la supprimer.

• Restauration de clés

  Lorsqu’une commande qui fait référence à une clé chargée est envoyée au TBS, elle garantit que la clé est physiquement présente sur le module de plateforme sécurisée. Si la clé n’est pas présente, le SCT la restaure avec un appel à TPM_LoadContext ou TPM2_ContextLoad. Si une clé ne peut pas être restaurée dans le module de plateforme sécurisée, le 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 SCT dans le contexte de l’appelant, le TBS met en forme un flux d’erreurs 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 ce par un handle virtuel. Lorsque la session d’autorisation est ensuite référencée, 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 TPM_INVALIDAUTHHANDLE d’erreur.

Les emplacements de session sont limités et le TBS peut être à court d’emplacements externes dans lesquels enregistrer les contextes de session d’autorisation. Si cela se produit, le TBS choisit une session d’autorisation à invalider afin que le nouveau contexte puisse être correctement enregistré. 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 continue-use associé à la session d’autorisation dans le flux de commandes 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 du fait que cette commande provient du TBS ou d’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 du module de plateforme sécurisée. 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 ne sont valides que 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

  Le TBS invalide la session d’autorisation virtuelle s’il reçoit une commande TPM_FlushSpecific ou TPM2_FlushContext pour le handle virtuel 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 TPM.

• Suppression temporaire de sessions d’autorisation

  Lors de la suppression d’une session d’autorisation du module de plateforme sécurisée pour faire de l’espace pour une nouvelle entité, le SCT exécute TPM_SaveContext ou TPM2_ContextSave sur cette session d’autorisation.

• Restauration des sessions d’autorisation

  Lorsqu’une commande TPM autorisée est envoyée au SCT, le SCT s’assure que toutes les sessions d’autorisation virtuelles auxquelles il fait référence 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 SCT 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 TBS retourne TPM_E_INVALID_HANDLE comme 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 SCT dans le contexte de l’appelant, le TBS met en forme un flux d’erreurs pour l’appelant avec l’erreur TPM_E_INVALID_HANDLE.

Transport Sessions

Les sessions de transport sont un mécanisme fourni par le module de plateforme sécurisée qui permet à une pile logicielle de chiffrer des données dans une commande à mesure qu’elles passent 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’elles passent sur le bus matériel.

Malheureusement, ce mécanisme empêche également le SCT d’examiner les données de charge utile. Dans la plupart des cas, il ne s’agit pas d’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 pour instance, le handle de ressource retourné est couvert par le chiffrement. Par conséquent, le SCT empêche toute tentative 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, le TBS retourne TPM_E_EMBEDDED_COMMAND_UNSUPPORTED comme résultat du module de plateforme sécurisée.

Les handles de session de transport sont virtualisés d’une 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 continue-use 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 du module de plateforme sécurisée. 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 de plateforme sécurisée est automatiquement vidée 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 virtuels ne sont valides que 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

  Le TBS invalide la session de transport virtuel s’il reçoit une commande TPM_FlushSpecific pour le handle virtuel du contexte client. Si la session de transport est physiquement présente sur le module de plateforme sécurisée lors de la réception de la commande de vidage, le TBS vide immédiatement la session physique du module de plateforme sécurisée.

• Suppression temporaire des sessions de transport

  Lors de la suppression d’une session de transport du module de plateforme sécurisée pour faire de l’espace pour une nouvelle entité, le tbs exécute TPM_SaveContext sur cette session de transport.

• Restauration des sessions de transport

  Lorsqu’une commande TPM_ExecuteTransport est envoyée au SCT, le SCT s’assure que la session de transport mentionnée dans la commande est physiquement présente sur le module de plateforme sécurisée. Si la session de transport n’est pas présente, le TBS la 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 SCT dans le contexte de l’appelant, le SCT met en forme un flux d’erreurs 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 d’autres logiciels ont accédé au module de plateforme sécurisée au cours d’une chaîne de commandes. Ils n’empêchent pas d’autres logiciels d’accéder au module de plateforme sécurisée, 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 SCT ne fait rien de spécifique pour entraver les séances de transport exclusif, mais il est quelque peu incompatible avec eux. Le TBS tente de dupliquer le comportement naturel du module de plateforme sécurisée en étant transparent, de sorte qu’il ne favorise 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, cela invalidera 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 module de plateforme sécurisée. Cette situation déclenche l’exécution par le gestionnaire de virtualisation TBS d’une commande TPM_LoadContext pour fournir cette ressource, ce qui met fin à la session de transport exclusive du client A.