Brevet FR3095282A1 — publié le 20201023

Description Titre de l'invention : Procédé de fourniture d'attestations mis en oeuvre par une plateforme informatique virtualisée. Technique antérieure [0001] L'invention se situe dans le domaine des plateformes informatiques virtualisées. [0002] La figure 1 représente l'architecture connue d'une telle plateforme PIV. Elle comporte dans cet exemple trois couches (en anglais layers), à savoir : - une couche matérielle CM; - une couche de virtualisation VMM (en anglais Virtual Machine Manager) ou hyperviseur ; et - une couche de machines virtuelles ou VMs. [0003] D'une façon générale, le mécanisme de virtualisation donne aux ressources d'une couche, la perception d'une utilisation exclusive de ressources sous-jacentes potentiellement partagées, ces ressources sous-jacentes apparaissant sous la forme de multiples instances isolées allouées à des ressources d'une couche supérieure. Chaque ressource de niveau supérieur estime qu'elle dispose de l'utilisation exclusive de fonctionnalités rendues par des ressources sous-jacentes et n'ignore pas qu'elle ne s'exécute pas directement sur le matériel. [0004] La plateforme informatique virtualisée peut être utilisée pour assurer les fonc- tionnalités d'un réseau mobile de nouvelle génération ou mettre en oeuvre une plateforme NFV (en anglais Network Function Virtualization). 100051 Chaque machine virtuelle exécute une instance de système d'exploitation unique, appelée système d'exploitation invité, et fonctionne indépendamment des autres machines virtuelles de la plateforme. Chaque système d'exploitation invité nécessite une machine virtuelle isolée pour son exécution. 100061 La couche logicielle de virtualisation VMM ou hyperviseur est une couche s'exécutant sous les machines virtuelles fournissant l'environnement d'exécution. 100071 La présente invention se situe plus particulièrement dans le contexte des plateformes informatiques virtualisées comportant une racine de confiance RoT (en anglais Roots of Trust). 100081 De manière conventionnelle, une telle racine de confiance RoT est confieurée pour exécuter une ou plusieurs fonctions spécifiques de sécurisation de la plateforme virtuelle 11V. Il s'agit donc d'un élément auquel il est fait confiance pour se comporter de manière attendue, un mauvais comportement de la racine de confiance RoT ne pouvant pas être détecté. Il convient de noter qu'une telle racine de confiance RoT peut être constituée d'éléments logiciels mais elle est préférentiellement implémentée sous 2 la forme d'un module matériel. [0009] La racine de confiance RoT offre ainsi les services de sécurisation de la plateforme PIV. Elle est notamment utilisée pour stocker et protéger les clés cryptographiques de la plateforme PIV, ces clés ne pouvant être utilisées par les autres ressources sans cette racine de confiance RoT. [0010] Cette racine de confiance RoT peut être constituée par un module de confiance TPM conforme aux spécifications techniques définies par le consortium Trustcd Computing Group (TCG). Il peut notamment être conforme au standard ISO/IEC 11889. [0011] Dans l'exemple de la figure 1, l'hyperviscur VMM comporte, pour chaque machine virtuelle VM, une racine de confiance virtualisée vRoT (en anglais Virtualized Roots of Trust) qui fournit, au système d'exploitation invité de cette machine virtuelle VM, les services de la racine de confiance RoT. Une telle racine de confiance virtualisée vRoT fait donc référence à une combinaison de fonctionnalités fournies par la racine de confiance RoT associée, ainsi que par l'hyperviscur (ce dernier donnant accès aux fonctionnalités de la racine de confiance RoT). [0012] Dans l'exemple de la figure 1, la plateforme informatique virtualisée PIV comporte deux machines virtuelles VM1, VM2, chaque machine virtuelle VMi bénéficiant des ressources d'une racine de confiance virtualisée vRoTi, les racines de confiance virtualisées vRoTl étant des instances indépendantes représentatives de la même racine de confiance RoT. [0013] L'invention ne se limite pas à une telle architecture. [0014] Pour plus de renseignements sur les concepts et définitions introduits pour la figure 1, l'homme du métier peut se reporter au document [TCG]. [0015] L'invention se situe plus particulièrement dans le contexte de l'attestation des pla- tefonnes informatiques virtualisées. [0016] D'une manière générale, dans le contexte de l'invention, l'attestation est un processus permettant à une plateforme informatique virtualisée d'affirmer une propriété à une entité de vérification, en apportant la preuve de cette propriété à cette entité. Par exemple, la plateforme informatique virtualisée peut affirmer qu'elle est digne de confiance et qu'elle n'a pas été corrompue. Dans cet exemple, ce processus d'attestation consiste à fournir une preuve de l'intégrité de la plateforme. [0017] D'autres propriétés peuvent faire l'objet d'une attestation de la plateforme, et notamment, toujours à titre d'exemple : - une attestation relative à la localisation de la plateforme ; - une attestation relative à des droits d'accès gérés par la plateforme. [0018] L'invention se situe encore plus particulièrement dans le contexte de l'attestation ap- profondie (en anglais deep attestation) dans laquelle un tel processus d'attestation est opéré pour chacune des couches de la plateforme informatique virtualisée. 3 [0019] En pratique, l'attestation de la couche matérielle CM est implicite car celle-ci est di- rectement conférée par la racine de confiance RoT présente dans cette couche. [0020] Par conséquent, en reprenant l'exemple de la figure 1, l'attestation approfondie de la plateforme PIV implique : - l'attestation de chaque machine virtuelle VM ; - l'attestation de la couche de virtualisation (ou hyperviseur) VMM ; et - la fourniture d'une liaison vérifiable et explicite entre les couches (en anglais layer binding problem), preuve que les différentes attestations (attestation de l' hyperviseur VMM, attestation de chacune des machines virtuelles VMs) ont bien été délivrées pour des couches d'une même plateforme PIV. [0021] Le statut de confiance d'une plateforme informatique virtualisée PIV peut être déterminé par un tiers uniquement à l'aide de primitives de la racine de confiance RoT, ces primitives étant intrinsèquement fiables et implémentées par un module logiciel niais préférentiellement matériel de cette plateforme. [0022] La couche de virtualisation VMM (autrement dit l'hyperviscur) utilise pour générer ses données d'attestation les racines de confiance matérielles RoT du module matériel de confiance. [0023] Ces racines de confiance matérielles RoT offrent notamment des services de protection des clés cryptographiques et des services d'exécution sécurisée d'opérations cryptographiques. Ces services sont nécessaires pour permettre à un tiers de vérifier l'état de confiance de la plateforme PIV. [0024] Contrairement à la couche de virtualisation VMM qui doit s'exécuter directement sur la couche matérielle CM, les machines virtuelles VM s'exécutent dans un environnement d'exécution créé par 1' hyperviseur, appelé plateforme virtuelle. [0025] Ces platefonnes virtuelles peuvent utiliser les fonctionnalités des racines de confiance matérielles RoT, mais l'hyperviseur est impliqué dans la configuration de l'accès à ces fonctionnalités ainsi que dans la communication entre ces plateformes virtuelles et les racines de confiance matérielles RoT. [0026] Ces services de sécurisation, par exemple de protection des clés cryptographiques et des services d'exécution sécurisée d'opérations cryptographiques, peuvent être considérés eux-mêmes comme des racines virtuelles de confiance vRoTi. [0027] Comme mentionné précédemment, l'attestation d'une plateforme informatique vir- tualisée implique des étapes de rapport et de vérification de tous ses composants logiciels, autrement dit des machines virtuelles VMi et de la couche de virtualisation ou hyperviseur VMM. [0028] Pour son attestation, chaque machine virtuelle VMi exploite l'instance de plateforme sécurisée virtuelle qui lui est associée, et en particulier les fonctionnalités de sécurité offertes par les racines virtuelles de confiance vRoTi. [0029] Ces racines virtuelles de confiance vRoTi peuvent être implémentées de façon lo- gicielle et / ou matérielle, dans le sens où la racine virtuelle de confiance vRoTi communique avec la RoT. Elles ont pour objectif d'inférer la confiance dans les attestations des machines virtuelles VM en établissant une chaîne de confiance de la couche matérielle CM jusqu'à la machine virtuelle. [0030] Par conséquent, une évaluation de l'état d'une machine virtuelle ne peut être effectuée que si l'état de l'hyperviseur VMM est également validé dans le cadre de l'attestation de cette machine virtuelle VMi. [0031] Ce processus constitue l'attestation approfondie (en anglais « deep attestation ») in- troduite précédemment : elle permet d'étendre la confiance des racines de confiance RoT, en passant par l'hyperviseur avec la mise en oeuvre des racines virtuelles de confiance vRoTi, jusqu'aux machines virtuelles VMi et donc à la plateforme informatique virtualisée PD/ dans son ensemble. [0032] Une attestation approfondie implique la récupération et la validation ultérieure, par une entité de vérification distante, des données d'attestation des machines virtuelles VMi et des données d'attestation de l'hyperviseur VMM sous-jacent. Du point de vue du vérificateur distant, ces deux rapports d'attestation peuvent être fournis par deux entités indépendantes. Par conséquent, l'entité de vérification distante requiert la preuve que l'hyperviseur VMM, dont il témoigne dans le cadre d'une attestation approfondie, exécute réellement une instance de la racine virtuelle de confiance vRoTi associée à la machine virtuelle VMi cible de l'attestation. Ce problème de la création d'une liaison explicite et vérifiable entre l'attestation d'une machine virtuelle et l'attestation de l'hyperviseur sur lequel les instances vRoT de la machine virtuelle s'exécutent constitue le problème de liaison de couches (en anglais « layer binding problem ») déjà mentionné. [0033] Les figures 2A et 2B illustrent deux modèles d'attestations approfondies, qui diffèrent par la manière dont les données d'attestation de l'hyperviseur sont transmises à l'entité de vérification distante : - via le canal d'attestation de la machine virtuelle VM (attestation approfondie à canal unique) ; ou - via un canal distinct dédié (attestation approfondie multicanal). [0034] La figure 2A représente le mécanisme connu d'attestation approfondie à canal unique. [0035] Dans ce modèle, l'entité de vérification distante EV établit un canal de commu- nication C avec la machine virtuelle VM via lequel il obtient les données d'attestation spécifiques à la machine virtuelle VM ainsi que les données d'attestation de l'hyperviseur VMM sur lequel la machine virtuelle s'exécute. [0036] Dans ce modèle, le problème de la liaison des couches peut être résolu en incluant, dans les données d'attestation de l'hyperviseur, des données spécifiques au module de confiance virtuel vRoT fournissant ainsi une preuve cryptographique vérifiable de la liaison des couches. [0037] Ce modèle n'est pas adapté aux déploiements dans lesquels un grand nombre de machines virtuelles s'exécutent sur le même hyperviscur, notamment car la génération de rapports multiples d'attestations de l'hyperviseur ne peut s'effectuer en parallèle. [0038] La figure 2B représente le modèle connu d'attestation multicanal dans lequel l'entité de vérification distante EV établit un premier canal de communication Cl avec la machine virtuelle pour récupérer ses données d'attestation, puis, par la suite, un deuxième canal de communication indépendant C2 avec l'hyperviseur pour récupérer ses données d'attestation. [0039] Ce modèle s'adapte bien aux déploiements impliquant un grand nombre de machines virtuelles s'exécutant sur un même hyperviseur. Malheureusement, la liaison entre les données d'attestation des différentes couches est très lâche, et le problème de la liaison des couches n'est pas simple à résoudre. [0040] Pour plus de renseignements sur les mécanismes d'attestation, l'homme du métier peut se reporter aux références [NFV] et [PRA]. [0041] L'invention vise à offrir un mécanisme d'attestation approfondie d'une plateforrne informatique virtualisée qui ne présente pas les inconvénients de l'art antérieur. Exposé de l'invention [0042] Selon un premier aspect, l'invention concerne un procédé de fourniture d'attestations mis en oeuvre par une plateforme informatique virtualisée comportant une racine de confiance, un hyperviseur et au moins une machine virtuelle, l'hyperviseur mettant en oeuvre une racine de confiance virtualisée par machine virtuelle et offrant des services de la racine de confiance, ce procédé comportant : - une étape d'établissement d'un premier canal sécurisé entre cet hyperviseur et une entité de vérification ; - une étape d'envoi de données d'attestation de cet hyperviseur dans ledit premier canal sécurisé à destination de l'entité de vérification, ces données d'attestation étant obtenues en utilisant des services de la racine de confiance ; - une étape de réception, par l'hyperviseur, dans le premier canal sécurisé, en provenance de l'entité de vérification, d'au moins une donnée cryptographique destinée à la racine de confiance; - une étape d'établissement d'un deuxième canal sécurisé entre au moins une machine virtuelle et l'entité de vérification, des primitives de la racine de confiance appliquées à la donnée cryptographique étant nécessaires pour l'établissement de ce deuxième canal sécurisé ; 6 - une étape d'envoi de données d'attestation de ladite machine virtuelle dans le canal sécurisé établi pour cette machine virtuelle, ces données d'attestations de machine virtuelle étant obtenues par la machine virtuelle en utilisant des services de la racine de confiance virtualisée associée à ladite machine virtuelle. [0043] Corrélativement, l'invention vise une plateforme informatique virtualisée comportant une racine de confiance, un hyperviseur et au moins une machine virtuelle, r hyperviscur mettant en oeuvre une racine de confiance virtualisée par machine virtuelle et offrant des services de la racine de confiance, dans laquelle : - ledit hyperviseur est configure pour : - établir un premier canal sécurisé avec une entité de vérification ; - obtenir des données d'attestation de cet hyperviseur en utilisant des services de la racine de confiance ; - envoyer lesdites données d'attestation de cet hyperviseur dans ledit premier canal sécurisé à destination de l'entité de vérification ; - recevoir, en provenance de ladite entité de vérification, dans le premier canal sécurisé, au moins une donnée cryptographique destinée à la racine de confiance ; - chaque dite machine virtuelle est configurée pour : - établir un deuxième canal sécurisé entre cette machine virtuelle et l'entité de vérification, des primitives de la racine de confiance appliquées à la donnée cryptographique étant nécessaires pour l'établissement de cc deuxième canal sécurisé ; - envoyer des données d'attestation de cette machine virtuelle dans le deuxième canal sécurisé établi pour cette machine virtuelle, ces données d'attestation étant obtenues par la machine virtuelle en utilisant des services de la racine de confiance virtualisée associée à ladite machine virtuelle. [0044] Corrélativement, l'invention vise aussi un ensemble de programmes d'ordinateurs comportant : - un programme d'ordinateur sur un support d'information, ce programme étant susceptible d'être mis en oeuvre par un hyperviseur d'une plateforme informatique virtualisée, ce programme comportant des instructions configurées pour : - établir un premier canal sécurisé entre l'hyperviseur et une entité de vérification - envoyer des données d'attestation de cet hyperviseur dans le premier canal sécurisé à destination de l'entité de vérification, ces données d'attestation étant obtenues en utilisant des services d'une racine de confiance de la plateforme ; - recevoir au moins une donnée cryptographique en provenance de l'entité de vérification dans le premier canal sécurisé, cette donnée cryptographique étant destinée à la racine de confiance ; - un programme d'ordinateur sur un support d'information, une instance de ce 7 programme étant susceptible d'être mise en oeuvre par une machine virtuelle de la plateforme informatique virtualisée, cette instance de programme comportant des instructions configurécs pour : - établir un deuxième canal sécurisé entre la machine virtuelle et l'entité de vérification, des primitives de la racine de confiance appliquées à la donnée cryptographique étant nécessaires pour l'établissement de cc deuxième canal sécurisé ; - envoyer des données d'attestation de la machine virtuelle dans le deuxième canal sécurisé, ces données d'attestation étant obtenues par la machine virtuelle en utilisant des services d'une racine de confiance virtualisée de l'hyperviseur associée à la machine virtuelle et offrant des services de ladite racine de confiance. [0045] Selon un deuxième aspect, l'invention vise aussi un procédé de demande d'attestations d'une plateforme informatique virtualisée comportant une racine de confiance, un hyperviscur et au moins une machine virtuelle, l'hyperviseur mettant en oeuvre une racine de confiance virtualisée par machine virtuelle et offrant des services de la racine de confiance, ce procédé étant mis en oeuvre par une entité de vérification et comportant : - une étape d'établissement d'un premier canal sécurisé entre l'entité de vérification et l'hyperviseur; - une étape de réception de données d'attestation de l'hyperviseur dans le premier canal sécurisé ; - une étape d'envoi, à l'hyperviseur, dans le premier canal sécurisé, d'au moins une donnée cryptographique destinée à la racine de confiance ; - une étape d'établissement d'un deuxième canal sécurisé entre cette entité de vérification et chacune des machines virtuelles, des primitives de la racine de confiance appliquées à la donnée cryptographique étant nécessaires pour l'établissement de ce deuxième canal sécurisé ; - une étape de réception de données d'attestations de chaque machine virtuelle dans le deuxième canal sécurisé établi pour cette machine virtuelle, ces données d'attestation étant obtenues par la machine virtuelle en utilisant des services de la racine de confiance virtualisée associée à ladite machine virtuelle. [0046] Corrélativement l'invention vise aussi une entité de vérification configurée pour demander des attestations à une plateforme informatique virtualisée comportant une racine de confiance, un hyperviseur et au moins une machine virtuelle, l'hyperviseur mettant en oeuvre une racine de confiance virtualisée par machine virtuelle et offrant des services de la racine de confiance, cette entité de vérification comportant : - un module d'établissement d'un premier canal sécurisé entre l'entité de vérification et l'hyperviseur ; - un module de communication configuré pour : 8 - recevoir des données d'attestation de r hyperviscur dans le premier canal sécurisé ; - envoyer au moins une donnée cryptographique à l'hyperviseur dans le premier canal sécurisé, cette donnée cryptographique étant destinée à la racine de confiance ; et - un module d'établissement d'un deuxième canal sécurisé entre l'entité de vérification et chacune des machines virtuelle, des primitives de la racine de confiance appliquées à la donnée cryptographique étant nécessaires pour l'établissement de ce deuxième canal sécurisé ; - un module de communication configure pour recevoir des données d'attestation de chaque machine virtuelle dans le deuxième canal sécurisé établi pour cette machine virtuelle, ces données d'attestation étant obtenues par la machine virtuelle en utilisant des services de la racine de confiance virtualisée associée à la machine virtuelle. [0047] L'invention vise aussi un programme d'ordinateur, sur un support d'informations, cc programme comportant des instructions adaptées à la mise en oeuvre des étapes du procédé de demande d'attestations selon l'invention. [0048] Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. [0049] L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. [0050] Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. [0051] D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. [0052] Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. [0053] Ainsi, et d'une façon générale, l'invention propose, pour apporter la preuve de la liaison entre les données d'attestation des différentes couches d'établir des canaux sécurisés (deuxièmes canaux au sens de l'invention) entre chaque machine virtuelle et l'entité de vérification, un tel canal sécurisé étant établi en utilisant des primitives de la racine de confiance de la platefonne appliquées à une donnée cryptographique envoyée par l'entité de vérification dans le premier canal sécurisé établi avec l'hyperviseur. [0054] Par conséquent, seules les couches en mesure d'utiliser les services de la racine de 9 confiance (directement pour r hyperviscur ou indirectement pour les machines virtuelles via les racines de confiance virtualisées) peuvent être à l'origine de ces canaux sécurisés. [0055] L'invention apporte ainsi la preuve d'une liaison vérifiable et explicite entre la couche matérielle qui héberge la racine de confiance, l'hyperviscur, et les machines virtuelles de la plateforme informatique virtualisée. [0056] Dans un mode de réalisation, l'entité de vérification produit un rapport d'attestation approfondie de la plateformc. [0057] Dans le mode de réalisation décrit ici, ce rapport est positif si les canaux sécurisés établis entre ladite machine virtuelle et l'entité de vérification ont pu être établis. Ce rapport comporte : - les données d'attestation de l'hyperviscur ; et - les données d'attestation de chaque machine virtuelle. [0058] La donnée cryptographique envoyée par l'entité de vérification à r hyperviscur dans le premier canal sécurisé et utilisée par la racine de confiance pour établir les canaux sécurisés entre les machines virtuelles et l'entité de vérification peut être d'une nature quelconque. [0059] Dans un mode particulier de réalisation de l'invention, l'entité de vérification comporte un serveur, l'hyperviscur comporte un client, ce client et cc serveur étant configurés pour établir entre eux le premier canal sécurisé dans le cadre d'une première session confoime au protocole TLS. Ce premier canal sécurisé est utilisé : - par l'hyperviseur pour envoyer ses dites données d'attestation à l'entité de vérification ; et par - l'entité de vérification pour envoyer la donnée cryptographique à l'hyperviseur. [0060] Le protocole TLS peut être utilisé pour établir le premier canal sécurisé même si les machines virtuelles et l'entité de vérification utilisent ensuite un autre protocole. [0061] Dans un mode particulier de réalisation le protocole TLS est également utilisé pour établir les deuxièmes canaux sécurisés. Plus précisément : - les données cryptographiques envoyées par l'entité de vérification dans le premier canal sécurisé TLS comportent, associés à chaque machine virtuelle, un ticket et une variable aléatoire à usage unique ; - la racine de confiance est configurée pour calculer, pour chaque machine virtuelle, une clé pré-partagée en utilisant la variable aléatoire à usage unique associée à cette machine virtuelle ; - la clé pré-partagée est utilisée par la machine virtuelle pour demander l'établissement d'une deuxième session avec l'entité de vérification, cette deuxième session constituant une reprise de la première session conformément au protocole TLS - le deuxième canal sécurisé utilisé par une machine virtuelle pour envoyer ses données d'attestation à l'entité de vérification étant établi dans le cadre de ladite deuxième session. [0062] L'utilisation du protocole TLS permet avantageusement d'établir les deuxièmes canaux rapidement. Brève description des dessins [0063] D'autres caractéristiques et avantages de la présente invention ressortiront de la des- cription faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif Sur les figures : [fie.11 la figure 1 déjà décrite représente l'architecture d'une plateforme informatique virtualisée conforme à l'état de la technique ; [fig.2A] la figure 2A déjà décrite illustre le mécanisme d'attestation approfondie à canal unique de l'état de la technique ; [fig.213] la figure 2B déjà décrite illustre le mécanisme d'attestation approfondie multicanal de l'état de la technique ; [fig.3] la figure 3 représente, sous forme d'organigramme, les principales étapes d'un procédé d'attestation approfondie conforme à l'invention ; [fig.4] la figure 4 illustre des concepts connus du protocole TLS utiles à la compréhension d'un mode particulier de réalisation de l'invention ; [fig.51 la figure 5 illustre un mode particulier de réalisation de l'invention dans lequel l'entité de vérification et la plateforme informatique virtualisée communiquent conformément au protocole TLS ; et [fig.6] la figure 6 représente une entité dé vérification conforme à un mode particulier de réalisation de l'invention. Description des modes de réalisation 100641 La figure 3 représente sous forme d'organigramme les principales étapes d'un procédé d'attestation approfondie PAE d'une plateforme informatique virtualisée PIV conforme à l'invention. 100651 Ce procédé est conforme à un mode particulier de réalisation de l'invention. 100661 Il est mis en oeuvre par la plateforme informatique PIV virtualisée conforme à l'invention et par une entité de vérification EV conforme à l'invention. 100671 Plus précisément : - la plateforme informatique virtualisée PIV met en oeuvre les étapes FIO à F60 d'un procédé PFA de fourniture d'attestations conforme à l'invention ; et - l'entité de vérification EV met en oeuvre les étapes D10 à D60 d'un procédé PDA de demande d'attestations conforme à l'invention. 100681 Dans ce mode de réalisation, l'hyperviseur VMM de la plateforme PIV et l'entité de 11 vérification établissent un premier canal sécurisé CSO. L'établissement de ce premier canal CSO correspond à une étape D10 du procédé de demande d'attestation PDA et à une étape F10 du procédé de fourniture d'attestations PFA. [0069] Au cours d'une étape F20 du procédé de fourniture d'attestation, l'hyperviseur VMM envoie, dans le premier canal sécurisé CSO, à destination de l'entité de vérification VM, des données d'attestation de cet hyperviscur. Ces données sont obtenues par l'hyperviseur en utilisant des services de ladite racine de confiance RoT de la couche matérielle. Elles sont reçues par l'entité de vérification EV au cours d'une phase D20 du procédé de demande d'attestations. [0070] Au cours d'une étape D30, l'entité de vérification EV envoie, à l'hyperviseur VMM, dans le premier canal sécurisé CSO, au moins une donnée cryptographique TOK destinée à la racine de confiance RoT de la plateforme PIV. Cette donnée cryptographique TOK est reçue par l'hyperviseur VMM au cours d'une étape F30. [0071] L'hyperviseur VMM mémorise la donnée cryptographique TOK dans ladite racine de confiance RoT au cours d'une étape F40. [0072] Ensuite, chaque machine virtuelle de la plateforme PTV établit un canal sécurisé avec l'entité de vérification EV. Cet établissement correspond à une étape D50 du procédé de demande d'attestation PDA et à une étape F50 du procédé de fourniture d'attestations PFA. [0073] Conformément à l'invention, des primitives de la racine de confiance RoT appliquées à la donnée cryptographique TOK sont nécessaires pour l'établissement de ce deuxième canal sécurisé. [0074] Au cours d'une étape F60, chaque machine virtuelle envoie ses propres données d'attestation à l'entité de vérification EV dans le canal sécurisé établi pour cette machine virtuelle. [0075] Ces données d'attestations sont reçues par l'entité de vérification EV au cours d'une étape D60. [0076] Conformément à l'invention, les canaux sécurisés établis entre chacune des machines virtuelles et l'entité de vérification sont établis en utilisant des primitives de la racine de confiance de la plateforme appliquées à la donnée cryptographique envoyée par l'entité de vérification dans le premier canal sécurisé établi avec l'hyperviseur VMM. [0077] Par conséquent, seules les couches en mesure d'utiliser les services de la racine de confiance (directement pour l'hyperviseur VMM ou indirectement pour les machines virtuelles VM) peuvent être à l'origine de ces canaux sécurisés. [0078] L'invention apporte ainsi la preuve d'une liaison vérifiable et explicite entre la couche matérielle qui héberge la racine de confiance Rot l'hyperviseur VMM, et les machines virtuelles de la plateforme informatique virtualisée PIV. [0079] Dans le mode de réalisation décrit ici, l'entité de vérification EV produit un rapport 12 d'attestation approfondie de la plateformc PIV au cours d'une étape D70. [0080] Dans le mode de réalisation décrit ici, ce rapport est positif si les canaux sécurisés établis entre chaque machine virtuelle et l'entité de vérification EV ont pu être établis. Ce rapport comporte : - les données d'attestation de l'hyperviscur ; et - les données d'attestation de chaque machine virtuelle. [0081] Dans un mode de réalisation de l'invention, l'entité de vérification EV et la plateforme informatique virtualisée PIV communiquent selon le protocole TLS dont les concepts importants pour la compréhension de ce mode de réalisation de l'invention vont maintenant être décrits en référence à la fiQure 4. [0082] Cette figure illustre plus précisément des opérations effectuées par un client CLT_TLS et un serveur SRV_TLS dans la mise en oeuvre du protocole TLS. [0083] Le protocole TLS comprend un protocole de négociation HS, ou poignée de mains (en anglais « handshake protocol ») qui authentifie les parties communicantes, négocie les modes et les paramètres cryptographiques permettant le calcul, par le client CLT_TLS et par le serveur SRV TLS, au cours d'une étape T10, d'un secret maître partagé (en anglais master secret) MS. [0084] Ce secret maître partagé MS est utilisé par les parties pour dériver leurs clés crypto- graphiques, telles que des clés de chiffrement de canaux. [0085] Au cours d'une étape T20, le serveur SRV_TLS tire aléatoirement un nonce NONCE, à savoir un nombre aléatoire ou pseudo-aléatoire à usage unique pour chaque machine virtuelle VMi. Le serveur utilise le secret maître partagé MS pour calculer des tickets TICKi, en utilisant ces nonces NONCEi. Le serveur SRV_TLS envoie au client CLT_TLS les tickets TICKi associés à leurs nonces NONCE. [0086] Plus précisément, le serveur SRV_TLS calcule autant de tickets TICKi qu'il envisage de reprises de sessions (« session resumption » en anglais) à l'initiative du client CLT_TLS. [0087] Au cours d'une étape T30, le serveur SRV_TLS et le client CLT_TLS calculent, pour chaque ticket TICKi, une clé pré-partagée PSKi (en anglais pre-shared key) obtenue en utilisant le secret maître partagé MS et le nonce NONCEi associé à ce ticket. [0088] Ces tickets TICKi peuvent être utilisés par le client CLT_TLS pour démarrer ra- pidement de futures négociations. [0089] Plus précisément, lorsque le client CLT_TLS souhaite démarrer une nouvelle session basée sur une session précédente (en anglais « resume »), le dispositif client envoie dans son premier message au serveur, au cours d'une étape T40, un ticket TICKi. [0090] Au cours d'une étape T45, le client CLT_TLS et le serveur SRV_TLS calculent un nouveau secret partagé MSi' en utilisant leurs clés pré-partagées PSKi respectives. 13 [0091] Ce nouveau secret partagé MSi' est utilisé pour monter un nouveau canal sécurisé dans le cadre de la nouvelle session demandée par la machine virtuelle VMi avec l'entité de vérification EV. [0092] Ce mécanisme du protocole TLS permet avantageusement de simplifier l'échange de clés, de paramètres, et l'authentification du serveur de la nouvelle session (étape générale T50). Si les deux parties acceptent cette nouvelle session, autrement dit si les nouveaux secrets déterminés par le client CLT TLS et le serveur SRV_TLS correspondent, cela implique que ce sont ces mêmes parties CLT TLS et SRV_TLS qui ont participé à la phase de négociation initiale HS. [0093] Pour plus de renseignements sur le protocole TLS, l'homme du métier peut se reporter à la référence [TUS]. [0094] La figure 5 illustre le mode de réalisation de l'invention dans lequel l'entité de véri- fication EV conforme à l'invention et la plateforme informatique virtualisée PIV conforme à l'invention communiquent selon le protocole TLS. [0095] Dans ce mode de réalisation : - l'entité de vérification EV comporte un serveur SRV_TLS ; - l'hyperviseur VMM comporte un client CLT_TLS_VMM ; et - chaque machine virtuelle VMi comporte un client CLT TLS VMi. [0096] Au cours d'une étape préliminaire non représentée, l'entité de vérification EV envoie un message à la plateforme informatique virtualisée pour que le client CLT_TLS_VMM de l'hyperviseur VMM effectue une demande d'établissement de session auprès du serveur SRV_TLS de l'entité de vérification EV. [0097] Au cours d'une étape générale E50, le serveur SRV_TLS de l'entité de vérification EV et le client CLT_TLS_VMM de l'hyperviseur VMM effectuent, dans le cadre d'une première session SO, une phase de négociation conforme au protocole TLS (en anglais handshake) similaire à la phase HS décrite précédemment en référence à la figure 4. [0098] On rappelle que cette phase de négociation HS comporte notamment le calcul par le client CLT_TLS_VMM de l'hyperviseur VMM d'une part et par le serveur SRV_TLS de l'entité de vérification EV d'autre part d'un secret maître partagé MS. [0099] Pour calculer ce secret maître partagé MS, le client CLT_TLS_VMM de l'hyperviseur VMM invoque des primitives de la racine de confiance RoT de la plateforme PIV. Ces primitives calculent le secret maître partagé MS et l'enregistrent de façon sécurisée dans la racine de confiance RoT. Autrement dit, le client CLT_TLS_VMM de l'hyperviseur délègue le calcul du secret maître partagé MS à la racine de confiance RoT. [0100] La phase de négociation permet d'établir, pour la durée de la première session SO, un canal sécurisé CSO entre l'entité de vérification EV et l'hyperviseur VMM. 14 [0101] Ce canal sécurisé CSO est utilisé par l'hyperviscur VMM pour communiquer (étape E54) ses données d'attestation DA VMM à l'entité de vérification EV, ces données étant obtenues par rhyperviscur en utilisant les services de la racine de confiance RoT. [0102] Toujours au cours de la même session 50, le serveur SRV TES de l'entité de véri- fication EV envoie (étape E56) au client CLT TLS VMM autant de tickets TICKi qu'il existe de machines virtuelles VMi dans la platefortne informatique virtualisée PIV, chaque ticket étant associé à un nonce NONCEi. Ce nombre de machines virtuelles a pu être communiqué précédemment par r hyperviscur VMM à l'entité de vérification EV. En effet, le serveur SRV TES s'attend à cc que chacune des machines virtuelles VMi initie une session propre avec lui-même pour lui communiquer ses données d'attestation DA VMi. [0103] Au cours d'une étape E58, le client CLT TLS VMM de l'hyperviscur VMM communique ces couples ticketslnonce TICKiINONCEi à la racine de confiance RoT de la plateformc PIV. [0104] Au cours d'une étape E60, le serveur SRV TES et la racine de confiance RoT calculent, pour chaque ticket TICKi, une clé pré-partagée PSKi à partir du secret maître partagé MS et du nonce NONCEi associé à ce ticket. [0105] Au cours d'une étape E62, le module de confiance virtualisé vRoTl associé à chaque machine virtuelle VMi obtient un ticket TICKi. [0106] Une fois que les tickets et nonces TICKiINONCEi ont été envoyés par l'entité de vé- rification EV (étape E56) au client CLT_TES_VMM de l'hyperviseur VMM, la session SO se termine. [0107] Au cours d'une étape E64, le client CLT_TLS_VMI de la machine virtuelle VM1 demande à démarrer une nouvelle session SI avec le serveur SRV_TLS de l'entité de vérification EV en lui envoyant le ticket TICK1. Un nouveau secret MS1' est calculé par la racine de confiance RoT et par le serveur SRV_TES à partir de leurs valeurs respectives de la clé pré-partagée PSK1. [0108] Cette nouvelle session s'établit si les nouveaux secrets MS1' sont identiques et se déroule conformément aux étapes T45 / T50 décrites précédemment en référence à la figure 4. [0109] Un canal sécurisé CSI est établi, pour la durée de cette session Si, entre l'entité de vérification EV et la machine virtuelle VM1. [0110] Ce canal sécurisé CS1 est utilisé par la machine virtuelle VMi pour communiquer (étape E66) ses données d'attestation DA_VM1 à l'entité de vérification EV, ces données étant obtenues par la machine virtuelle VMi en utilisant les services de la racine de confiance virtualisée vRoTI. [0111] Une fois que les données d'attestation DA_VM1 ont été envoyées à l'entité de véri- fication EV, la session 51 se termine. [0112] Au cours d'une étape E68, le client CLT TLS VM2 de la machine virtuelle VM2 demande à démarrer une nouvelle session S2 avec le serveur SRV TES de l'entité de vérification EV en lui envoyant le ticket TICK2. Un nouveau secret MS2' est calculé par la racine de confiance RoT et par le serveur SRV TLS à partir de leurs valeurs respectives de la clé pré-partagée PSK2. [0113] Un canal sécurisé CS2 est établi, pour la durée de cette session 52, entre l'entité de vérification EV et la machine virtuelle VM2. [0114] Ce canal sécurisé CS2 est utilisé par la machine virtuelle VM2 pour communiquer (étape E70) ses données d'attestation DA VM2 à l'entité de vérification EV, ces données étant obtenues par la machine virtuelle VM2 en utilisant les services de la racine de confiance virtualisée vRoT2. [0115] Une fois que les données d'attestation DA VM2 ont été envoyées à l'entité de véri- fication EV, la session S2 se termine. [0116] L'entité de vérification EV a ainsi reçu : - les données d'attestation DA VMM de l'hyperviseur ; - les données d'attestation DA VMi de chacune des machines virtuelles VMi. [0117] Les canaux sécurisés CS1 et CS2 ont été établis sur la base des tickets TICK1 et TICK2 reçus de l'entité de vérification EV et des clés pré-partagées PSK1, PSK2 calculées par la racine de confiance RoT sur la base du secret maître partagé MS et des nonces NONCE], NONCE2. De plus, les sessions S1 et S2 sont des sessions dérivées de la première session SO de la phase de négociation HS. [0118] Par conséquent, seules les couches en mesure d'utiliser les services de la racine de confiance RoT (directement pour l'hyperviseur VMM ou indirectement pour les machines virtuelles VMi via les racines de confiance virtualisées vRoTi) peuvent être à l'origine de ces sessions liées Si et S2. [0119] L'invention apporte ainsi la preuve d'une liaison vérifiable et explicite entre la couche matérielle CM qui héberge la racine de confiance RoT, l'hyperviseur VMM, et les machines virtuelles VMI, VM2 de la platefon-ne informatique virtualisée PIV. [0120] La figure 6 représente une entité de vérification EV conforme à l'invention. Dans le mode de réalisation décrit ici, cette entité de vérification EV a l'architecture matérielle d'un ordinateur. Elle comporte un processeur 21, une mémoire morte de type ROM 22, une mémoire vive de type RAM 23 et des moyens de communication 24. [0121] La mémoire morte de type ROM 22 constitue un support d'enregistrement au sens de l'invention. Elle comporte un programme d'ordinateur conforme à l'invention, ce programme comportant des instructions aptes à mettre en oeuvre un procédé de demandes d'attestations conforme à l'invention et dont les principales étapes ont décrites en référence à la figure 3. [0122] Lorsque le processeur 21 exécute le programme d'ordinateur, l'entité de vérification 16 EV est apte à établir, en utilisant des moyens dc communication 24 un premier canal sécurisé avec l'hyperviseur VMM d'une plateforme informatique virtual iséc. [0123] Dans un mode de réalisation de l'invention, la mémoire morte 22 comporte une pile de protocole permettant d'installer un serveur SRV TLS dans l'entité de vérification EV, ce serveur SRV TLS étant apte à établir un canal de communication sécurisé avec un client CLT TLS installé dans r hyperviscur VMM, conformément au protocole TLS. [0124] Les moyens de communication 24 sont des moyens matériels et logiciels. Ils sont aptes à recevoir des données d'attestation DA VMM de l'hyperviscur dans ce premier canal sécurisé. [0125] Lorsque le processeur 21 est configure pour envoyer au moins une donnée crypto- graphique à l'hyperviscur VMM dans le premier canal sécurisé en utilisant les moyens de communication 24. En particulier, dans le mode dc réalisation dans lequel l'entité de vérification EV et la plateforme PIV utilisent le protocole TLS, le processeur 21 est configure pour calculer les tickets TICKi et les envoyer dans le canal de communication sécurisé à l'hyperviseur VMM. [0126] Lorsque le processeur 21 exécute le programme d'ordinateur, l'entité de vérification EV est également apte à établir, en utilisant des moyens de communication 24 un canal sécurisé avec chacune des machines virtuelles dc la plateforme PIV. [0127] L'entité dc vérification EV reçoit les données d'attestation DA VMi de ces machines virtuelles, dans ces canaux sécurisés, via les moyens de communication 24. [0128] La plateforme informatique virtualisée PIV peut avoir l'architecture matérielle d'un ordinateur conventionnel. L'invention ne présage pas du type d'hyperviseur. [0129] Références : [TCG] : TCG Virtual Platform WG : Virtualized Trusted Platftorm Architecture Specification. Specification Version 1.0. Revision 0.26. September 27, 2011. [NEV] : Network Functions Virtualization (NFV) ; Trust ; Report on Attestation Techniologies and Practices for Secure Deployments. ETSI GR NFV-SEC 007 v1.1.1 (2017-10). [PRA] : G. Coker, J. Guttman, P. Loscocco, A. Herzog, J. Milien, B. O'Hanlon, J. Ramsdell, A. Segall, J. Sheehy, B. Sniffen « Principles of Remote Attestation. Int. J. Inf. Secur. 1, 2 Hune 2011), 63-81. DOI=http://dx.doi.org/10.1007/s10207-011-0124-7. [TLS] : E. Rescorla, « The Transport Security Layer (TLS) Protocol Version 1.3 », RFC 8446, DOI 10.17487/RFC8446, August 2018. 17 [Revendication 1] [Revendication 2] REVENDICATIONSProcédé (PFA) de fourniture d'attestations mis en oeuvre par une plateforme informatique virtualisée (PIV) comportant une racine de confiance (RoT), un hyperviseur (VMM) et au moins une machine virtuelle (V M I, VM2), l'hyperviseur (VMM) mettant en oeuvre une racine de confiance virtualisée (vRoT1, vRoT2) par machine virtuelle (VM1, VM2) et offrant des services de la racine de confiance (RoT), ce procédé comportant : - une étape (F10) d'établissement d'un premier canal sécurisé (CSO) entre ledit hyperviseur (VMM) et une entité de vérification (EV) ; - une étape (F20) d'envoi de données d'attestation (DA_VMM) de cet hyperviseur dans ledit premier canal sécurisé (CSO) à destination de l'entité de vérification (EV), lesdites données d'attestation étant obtenues en utilisant des services de ladite racine de confiance (RoT) ; - une étape de (F30) réception, par ledit hyperviseur (VMM), dans ledit premier canal sécurisé (CSO), en provenance de ladite entité de vérification (EV), d'au moins une donnée cryptographique (TOK) destinée à ladite racine de confiance (RoT); - une étape (F50) d'établissement d'un deuxième canal sécurisé (CS1, CS2) entre au moins une machine virtuelle (VM1, VM2) et ladite entité de vérification (EV), des primitives de la racine de confiance (RoT) appliquées à la donnée cryptographique (TOK) étant nécessaires pour l'établissement de ce deuxième canal sécurisé (CS1, CS2) ; - une étape (F60) d'envoi de données d'attestation (DA_VM1, DA_VM2) de ladite machine virtuelle (VM1, VM2) dans le deuxième canal sécurisé (CS1, CS2) établi pour ladite machine virtuelle (VM1, VM2), lesdites données d'attestations (DA_VM1, DA_VM2) étant obtenues par ladite machine virtuelle (VM1, VM2) en utilisant des services de la racine de confiance virtualisée (vRoT1, vRoT2) associée à ladite machine virtuelle (VM1, VM2). Procédé (PDA) de demande d'attestations d'une plateforme informatique virtualisée (PIV) comportant une racine de confiance (RoT), un hyperviseur (VMM) et au moins une machine virtuelle (VM1, VM2), l'hyperviseur (VMM) mettant en oeuvre une racine de confiance virtualisée (vRoTi, vRoT2) par machine virtuelle (VM1, VM2) et offrant des services de la racine de confiance (RoT), ce procédé étant mis en oeuvre par une entité de vérification (EV) et. comportant : 18 [Revendication 3] [Revendication 4] - une étape (D10) d'établissement d'un premier canal sécurisé (CSO) entre ladite entité de vérification (EV) et ledit hyperviseur (VMM) ; - une étape (D20) de réception de données d'attestation (DA VMM) dudit hyperviseur dans le premier canal sécurisé (CSO) ; - une étape (D30) d'envoi, audit hyperviseur (VMM), dans ledit premier canal sécurisé (CSO), d'au moins une donnée cryptographique (TOK) destinée à la racine de confiance (RoT) ; - une étape (D50) d'établissement d'un deuxième canal sécurisé (CS1, CS2) entre ladite entité de vérification (EV) et chacune desdites machines virtuelles (VM1, VM2), des primitives de la racine de confiance (RoT) appliquées à la donnée cryptographique (TOK) étant nécessaires pour l'établissement de ce deuxième canal sécurisé (CS1, CS2) ; - une étape (D60) de réception de données d'attestations (DA VM1, DA VM2) de chaque machine virtuelle (VM1, VM2) dans le deuxième canal sécurisé (CS1. CS2) établi pour ladite machine virtuelle, lesdites données d'attestation (DA VM1, DA VM2) étant obtenues par ladite machine virtuelle (VM1, VM2) en utilisant des services de la racine de confiance virtualisée (vRoT1, voRT2) associée à ladite machine virtuelle (VM1, VM2). Procédé (PDA) de demande d'attestations selon la revendication 2 comportant en outre une étape (D70) de production d'un rapport (ATT_REP) d'attestation approfondie de ladite plateforme (PIV), ce rapport étant positif si ledit deuxième canal sécurisé (CS1, CS2) a été établi pour ladite machine virtuelle (VMI, VM2), ledit rapport (ATT_REP) comportant : - les données (DA_VMM) d'attestation de l'hyperviseur ; et - les données (DA_VM1) d'attestation de chaque machine virtuelle (VMi). Procédé (PDA, PFA) selon l'une quelconque des revendications 1 à 3 dans lequel : - ladite entité de vérification (EV) comporte un serveur (TLS SRV_TLS) ; - ledit hyperviseur (VMM) comporte un client (TLS CLT_TLS_VMM), ledit client et ledit serveur étant configurés pour établir entre eux ledit premier canal sécurisé (CSO) dans le cadre d'une première session (SO) conforme au protocole TLS, ledit premier canal sécurisé étant utilisé : 19 [Revendication 5] [Revendication 6] - par ledit hyperviseur pour envoyer (F20) ses dites données d'attestation (DA_VMM) à l'entité de vérification (EV) ; et par - ladite entité de vérification (EV) pour envoyer (D30) ladite donnée cryptographique (TOK) au dit hyperviseur (VMM). Procédé (PDA, PFA) selon la revendication 4, caractérisé en ce que : - ladite au moins une donnée cryptographique comporte, associés à chaque dite machine virtuelle (VM1, VM2), un ticket (TICKi) et une variable aléatoire à usage unique (NONCED ; - ladite racine de confiance (RoT) étant configurée pour calculer, pour chaque machine virtuelle (VM1), une clé pré-partagée (PSK1) en utilisant la variable aléatoire à usage unique (NONCE1) associée à cette machine virtuelle ; - ladite clé partagée (PSK1) étant utilisée par ladite machine virtuelle pour demander (F50) l'établissement d'une deuxième session (Si) avec ladite entité de vérification (EV), ladite deuxième session (Si) constituant une reprise de ladite première session (S0) conformément au protocole TLS ; - ledit deuxième canal sécurisé (CS1) utilisé par ladite machine virtuelle (VM1) pour envoyer (F60) ses données d'attestation (DA VM1) à ladite entité de vérification étant établi (F50) dans le cadre de ladite deuxième session (SI). Plateforme informatique virtualisée (PIV) comportant une racine de confiance (RoT), un hyperviseur (VMM) et au moins une machine virtuelle (VMI, VM2), l'hyperviseur (VMM) mettant en oeuvre une racine de confiance virtualisée (vRoTI, vRoT2) par machine virtuelle (VMI, VM2) et offrant des services de la racine de confiance (RoT), dans laquelle : - ledit hyperviseur (VMM) est configuré pour : - établir un premier canal sécurisé (CSO) avec une entité de vérification (EV) ; - obtenir des données d'attestation (DA_VMM) de cet hyperviseur en utilisant des services de ladite racine de confiance (RoT) ; - envoyer lesdites données d'attestation (DA_VMM) de cet hyperviseur dans ledit premier canal sécurisé (CSO) à destination de l'entité de vérification (VM) ; - recevoir, en provenance de ladite entité de vérification (EV) dans ledit premier canal sécurisé (CSO), au moins une donnée cryptographique (TOK) destinée à la racine de confiance (RoT) ; 20 [Revendication 7] - chaque dite machine virtuelle (VM1) est configurée pour : - établir un deuxième canal sécurisé (CS1) entre cette machine virtuelle et ladite entité de vérification (EV), des primitives de la racine de confiance (RoT) appliquées à la donnée cryptographique (TOK) étant nécessaires pour l'établissement de ce deuxième canal sécurisé (CS1) ; - envoyer des données d'attestation (DA VM1) de ladite machine virtuelle (VM1) dans le canal sécurisé (CS1) établi pour cette machine virtuelle (VM1), ces données d'attestation (DA VM1) étant obtenues par ladite machine virtuelle (VM1) en utilisant des services d'une racine de confiance virtualisée (vRoT1) associée à ladite machine virtuelle (VM1). Entité de vérification (EV) configurée pour demander des attestations à une plateforrne informatique virtualisée (PIV) comportant une racine de confiance (RoT), un hyperviscur (VMM) et au moins une machine virtuelle (VM1, VM2), rhyperviscur (VMM) mettant en oeuvre une racine de confiance virtualisée (vRoT1, vRoT2) par machine virtuelle (VM1, VM2) et offrant des services de la racine de confiance (RoT), ladite entité de vérification (EV) comportant : - un module d'établissement d'un premier canal sécurisé (CSO) entre ladite entité de vérification (EV) et ledit hyperviscur (VMM) ; - un module de communication configuré pour : - recevoir des données d'attestation (DA_VMM) dudit hyperviseur dans ledit premier canal sécurisé (CSO) ; - envoyer au moins une donnée cryptographique (TOK) audit hyperviseur (VMM) dans ledit premier canal sécurisé (CSO), ladite donnée cryptographique (TOK) étant destinée à la racine de confiance (RoT) ; - un module d'établissement d'un deuxième canal sécurisé (CSI, CS2) entre ladite entité de vérification (EV) et chacune desdites machines virtuelles (VMI, VM2), des primitives de la racine de confiance (RoT) appliquées à la donnée cryptographique (TOK) étant nécessaires pour pour l'établissement de ce deuxième canal sécurisé (CS1, CS2) - un module de communication configuré pour recevoir des données d'attestation (DA_VM1, DA_VM2) de chaque machine virtuelle (VMI, VM2) dans le deuxième canal sécurisé (CS1, CS2) établi pour ladite machine virtuelle, lesdites données d'attestation (DA_VMi) étant obtenues par ladite machine virtuelle (VMi) en des services d'une racine de confiance virtualisée (vRoTI, vRoT2) associée à ladite machine virtuelle (VMI, VM2). 21 [Revendication 8] Ensemble de programmes d'ordinateurs comportant : - un programme d'ordinateur (CLT TLS VMM) sur un support d'information, ledit programme étant susceptible d'être mis en oeuvre par un hyperviseur (VMM) d'une plateforme informatique virtualisée (PIV), ce programme comportant des instructions configurées pour : - établir un premier canal sécurisé (CSO) entre ledit hyperviscur (VMM) et une entité de vérification (EV) ; - envoyer des données d'attestation (DA VMM) de cet hyperviseur dans ledit premier canal sécurisé (CSO) à destination de l'entité de vérification (VM), lesdites données d'attestation étant obtenues en utilisant des services d'une racine de confiance (RoT) de ladite plateforme (PIV) [Revendication 9] [Revendication 10] - recevoir au moins une donnée cryptographique (TOK) en provenance de ladite entité de vérification (EV) dans ledit premier canal sécurisé (CSO), cette donnée cryptographique (TOK) étant destinée à la racine de confiance (RoT); - un programme d'ordinateur sur un support d'information, une instance (CLT TLS VM1, CLT TLS VM2) de cc programme étant susceptible d'être mise en oeuvre par une machine virtuelle (VM1, VM2) de ladite plateforme informatique virtualisée (PIV), cette instance de programme comportant des instructions configurées pour : - établir un deuxième canal sécurisé (CS1) entre ladite machine virtuelle (VMI) et ladite entité de vérification (EV), des primitives de la racine de confiance (RoT) appliquées à la donnée cryptographique étant nécessaires pour l'établissement de ce deuxième canal sécurisé (CSI) ; - envoyer des données d'attestation (DA_VM1) de ladite machine virtuelle (VMI) dans le deuxième canal sécurisé (CS1), lesdites données d'attestation étant obtenues par ladite machine virtuelle (VMi) en utilisant des services d'une racine de confiance virtualisée (vRoT1) dudit hyperviseur (VMM) associée à ladite machine virtuelle (VMI) et offrant des services de ladite racine de confiance (RoT). Programme d'ordinateur sur un support d'information, ledit programme étant susceptible d'être mis en oeuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre d'un procédé de demandes d'attestations (PDA) selon l'une quelconque des revendications 2 à 5. Support d'enregistrement lisible par un ordinateur (PIV, EV) sur lequel est enregistré au moins : - un programme d'ordinateur selon la revendication 9 ; ou - un programme d'ordinateur d'un ensemble de programmes d'ordinateurs selon la revendication 8..