FR 3160250 A1 20250919 FR 2402455 A 20240312 METHODE D’ATTESTATION D’UN PROGRAMME LOGICIEL L'invention concerne une méthode d’attestation d’un programme logiciel. L’invention se caractérise en ce que on fournit un environnement d’exécution du programme logiciel comprenant un agent de mesure, on fournit un vérifieur, le système d’exploitation charge en mémoire volatile des pages exécutables du programme logiciel dont un contenu constitue une empreinte du programme logiciel, l’empreinte du programme logiciel chargée dans la mémoire volatile est modifiée à l’initiative du vérifieur, de l’agent de mesure ou du système d’exploitation, l’agent de mesure exécute une fonction de mesure, la mesure de l’empreinte modifiée du programme logiciel est transférée au vérifieur, le vérifieur obtient une mesure de référence réputée correcte de l’empreinte modifiée du programme logiciel, le vérifieur compare la mesure de l’empreinte modifiée du programme logiciel dans la mémoire volatile qui lui a été transférée avec la mesure de référence de l’empreinte modifiée. Figure de l’abrégé : Fig. 1 METHODE D’ATTESTATION D’UN PROGRAMME LOGICIEL DOMAINE DE L’INVENTION La présente invention concerne une méthode d’attestation d’un programme logiciel, la méthode vérifiant une égalité entre un état mesuré du programme et un état de référence connu de celui-ci, cet état de référence étant réputé correct, et représentant classiquement son état original. La mesure du programme consiste par exemple à produire une fonction de hachage à partir des contenus des pages chargées par le système d’exploitation en mémoire pour l’exécution du programme par le processeur. Le contenu de ces pages mémoire est désigné par le terme empreinte mémoire dans ce qui suit. La fonction de hachage permet de détecter toute modification réalisée sur l’empreinte et aboutit à une mesure. ART ANTERIEUR L’attestation d’un programme logiciel est un pilier de la sécurité informatique, ayant pour principe la vérification, par la mesure, qu’un objet est bien ce qu’il doit être, par comparaison avec une référence de son état original réputée correcte. Un objet, par exemple une donnée ou un programme logiciel, est identifié par sa signature produite par une fonction mathématique de hachage, résultant en une valeur numérique non inversable, calculée à partir des données caractérisant l’objet stocké en mémoire. Il est théoriquement impossible de construire une empreinte mémoire à partir d’une valeur numérique de hachage et théoriquement impossible de disposer du même résultat de hachage pour deux empreintes différentes. Le contenu du fichier peut résulter d’une opération de collecte préalable des différentes parties de son contenu. Cette collecte peut être produite de manière séquentielle et par parties ou en une fois pour l’intégralité. Ainsi, dans le cas d’une attestation d’un programme à l’exécution, on vérifie que le programme chargé en mémoire vive, notamment une mémoire de type DRAM, est identique à l’empreinte des pages mémoire lors de son chargement initial par le système d’exploitation ou que l’on peut également comparer avec une signature du programme logiciel délivré par le fournisseur. Par exemple, on produit un fichier par agrégation de toutes les pages mémoire de 4 Kilo-octets de la mémoire vive utilisées lors du placement en mémoire vive du programme pour son exécution par le processeur, avant de produire le hachage. Etat de l’art sur l’attestation locale ou à distance L’attestation est une méthode très utilisée, qui porte sur des objets de types différents tels que des données, un programme logiciel du système d’exploitation, un programme logiciel embarqué, un programme logiciel de couche basse (i.e., BIOS) ou un programme logiciel applicatif, à savoir une application logicielle. De ce fait, l’attestation a donné lieu à de très nombreux types d’implémentations locales ou à distance. Le niveau de confiance attribué à l’attestation locale ou à distance repose sur la solidité des logiciels réalisant la mesure, à savoir la réalisation du hachage, sur la sécurisation du transfert de celle-ci et, enfin, sur la sécurisation de la vérification d’authenticité de cette mesure. La sécurisation de la mesure est caractérisée, d’une part, par la solidité de ses points d’accès aux données mesurées, c’est-à-dire des points d’accès à la zone mémoire contenant l’objet et, d’autre part, par la solidité de la routine produisant le hachage contre une modification. L’état de l’art classifie trois types d’implémentations pour la réalisation de la mesure, avec et sans dispositif matériel, de deux types différents. On se réfère alors à l’attestation matérielle, hybride ou purement logicielle. L’attestation matérielle apporte un niveau de confiance supérieur. Le schéma standard propose l’utilisation d’une puce dédiée de type Module de plate-forme sécurisée TPM (« Trusted Platform Module » en langue anglaise) et répondant à un standard. Les TPM produisent des mesures dans des puces dédiées et imperméables à l’analyse et à la modification, et qui délivrent ainsi des assurances totales en confidentialité et intégrité sur ses mesures. Les TPM disposent de la clé privée d’une paire de clés de chiffrement asymétrique leur permettant de signer les mesures avant envoi. Cette clé privée n’est ni accessible en lecture ni exportable à l’extérieur du TPM. Les mesures signées sont envoyées au vérifieur distant. Le TPM dernier peut alors en valider l’origine en se référant à la clé publique délivrée avec la mesure, identifiant le TPM et peut par ailleurs valider l’intégrité de l’état du logiciel par comparaison avec une valeur de référence. Par ailleurs, pour les TPM, lorsque la mesure porte sur des pages mémoire d’une application ou d’un module système du noyau ou du système d’exploitation de la plateforme d’exécution, ces TPM accèdent à ces pages de manière totalement sécurisée, sans qu’il soit possible à l’attaquant d’intercepter et de corrompre ces lectures. Conçus pour cette mission et standardisés, les TPM sont susceptibles d’apporter, vis-à-vis de la mesure d’attestation, une sécurité optimale. Cependant, des attaques dites par le côté (« side attacks » en langue anglaise) sur la dernière version de TPM 2.0, corrélant par force brute des temps de réalisation d’opérations avec un contenu, ont permis de reconstruire la clef privée et donc de produire des mesures factices et arbitraires que le vérifieur attribuera au TPM. Ces attaques ont entraîné une réplique de la part des fabricants de TPM, qui ont produit un correctif du logiciel embarqué, repositionnant les TPM au plus niveau de confiance. Pour les applications logicielles et à l’exclusion des logiciels système (i.e. BIOS, système d’exploitation), une alternative à l’utilisation de TPM est apportée par les Environnements d’Exécution de Confiance TEE (« Trusted Execution Environments » en langue anglaise). Les TEE sont matérialisés par une excroissance du processeur et, donc, par un dispositif activable par la programmation, qui apporte les mêmes garanties élevées de confidentialité et d’intégrité pour leur contenu (i.e. le logiciel applicatif et les données) arbitrairement défini par l’utilisateur. Contrairement aux TPM, dont le logiciel est fixé par le fabricant et invariant, les TEE sont chargés par le logiciel des utilisateurs. Les TEE ne permettent pas de loger ou d’accéder aux logiciels système, ne constituant pas ainsi une alternative aux TPM pour l’attestation des logiciels système. Dans un TEE, les logiciels système et leurs données sont généralement destinés à une ou plusieurs fonctions de sécurité de différents types et nécessitent d’être sécurisés. Une fois embarqués en TEE, ces logiciels et leurs données constituent la Base d’Exécution de Confiance TCB (« Trusted Computing Basis » en langue anglaise). Dans le cas particulier où la TCB est une routine d’attestation avec les données d’attestation, on dispose alors d’une mesure d’attestation réalisée par un TEE avec les mêmes garanties de sécurité qu’avec un TPM. En corollaire, et par construction des garanties de sécurités apportées par les TEE, et, notamment, la garantie d’intégrité, un agent de mesure embarqué dans un TEE ne pourra se modifier lui-même ou être modifié par l’extérieur durant son exécution. De même, le logiciel embarqué dans un TPM est immuable. Les implémentations d’attestation matérielle exploitent une base de confiance statique et immuable. Ces implémentations sécurisent aussi totalement les clefs privées utilisées pour la réalisation des signatures des mesures réalisées avant leur envoi au vérifieur. Au même titre que les TPM ont fait l’objet d’attaques par le côté, de nombreuses attaques de ce type ont ciblé les TEE (par ex. Intel™ SGX, AMD™ SEV, arm™ Trustzone) qui ont aussi engendré des correctifs remédiant à ces attaques et sous la forme de microcode. Ces implémentations matérielles apportent, dès lors qu’elles reposent du logiciel à jour, notamment un microcode à jour, un niveau de confiance inégalable pour les mesures qu’elles apportent au vérifieur. Elles engendrent de facto une contrainte de déploiement imposant la présence du TPM ou du TEE là où la mesure d’attestation est réalisée. L’attestation hybride a été conçue pour des environnements d’exécution contraints pour lesquels les dispositifs matériels (TPM et TEE) ne sont pas présents. Pour les environnements d’exécution courants dans le domaine de l’Internet des Objets IoT (« Internet of Things » en langue anglaise), la taille, l’encombrement général du dispositif et ses ressources excluent ces dispositifs. Différents schémas d’attestation hybride exploitant des fonctions de base du processeur telles que le compteur d’horloge ou une mémoire uniquement accessible en lecture (ROM) sont utilisés par la routine d’attestation logicielle pour atteindre un niveau de sécurité jugé optimal pour ces dispositifs, sans offrir le même niveau de confiance que les configurations matérielles sur la confidentialité et l’intégrité du logiciel réalisant la mesure et sur la clef utilisée pour la signature de celle-ci. L’attestation logicielle n’utilise pas de dispositifs matériels utilisés par les attestations matérielles ou hybrides. On distingue deux types d’implémentations selon que le vérifieur est distant ou local. Elles sont de manière générale davantage utilisées pour réaliser l’attestation de logiciel applicatif. Si le vérifieur est situé dans le même environnement d’exécution que le logiciel mesuré, l’attestation est locale. Un cas particulier de l’attestation locale est quand le logiciel incorpore en son sein les fonctions de mesure et de vérification. L’attestation est alors désignée auto-attestation. A contrario , les fonctions de mesure et de vérification peuvent être intégrées dans le système d’exploitation ou dans un agent séparé au programme logiciel. Tout comme les attestations hybrides, elles ne délivrent alors pas de garanties de confidentialité et d’intégrité pleines mais relatives. Les routines de mesure des attestations logicielles sont notamment exposées à l’analyse et modification par un attaquant local. Des techniques logicielles d’offuscation consistant à opacifier le logiciel et les techniques d’auto-vérification pourront être déployées pour réduire ce risque, sans toutefois l’annuler. Un fait connu est l’impossibilité de garantir des assurances de confidentialité et d’intégrité quand l’attaquant est en situation de produire une analyse dynamique et d’écrire sur les pages mémoire du programme logiciel. Les techniques d’offuscation offrent un niveau de sécurité relatif, défini selon des exigences de performance et de sécurité des parties du programme logiciel. Concernant l’attestation, pour être efficace et pour éviter une attaque réalisée par analyse antérieure d’une instance d’un agent offusqué déployé, l’offuscation idéale, appliquée sur l’agent réalisant une mesure, se devrait de présenter une variabilité suffisante d’un déploiement d’un agent à un autre déploiement de ce même agent, créant ainsi une multiplicité d’agents d’attestation iso-fonctionnels et dont l’analyse est ardue. Pour de grandes quantités d’instanciations d’un agent d’attestation unique déployé pour de nombreuses applications ou intégrant le noyau, cette variabilité crée une instabilité opérationnelle impraticable, notamment parce qu’elle peut entraîner des aléas de fonctionnement et des impacts de performance variables et nécessiterait un test unitaire de tous les déploiements. Si l’offuscation idéale produit une très grande complexité à l’analyse, elle se traduit forcément par une excroissance très importante du logiciel engendrant une consommation de temps calcul du processeur en relation. L’offuscation se doit donc d’être poussée à un niveau restant acceptable de ce point de vue. Pour les solutions engendrant un fonctionnement spécifique de l’agent d’attestation tel qu’un hachage pseudo-aléatoire à chaque déploiement, l’offuscation peut être utilisée dans le but de retarder suffisamment l’analyse spécifique nécessaire l’attaquant engendrant des efforts non réductibles sur une durée minimale. La mise en place d’un compteur temporel par le vérifieur à la réception des mesures permet d’identifier les réponses tardives générées par une attaque. Ce principe de détection par le temps de réalisation de la mesure a été développé dans les publications suivantes, déployant différentes techniques (offuscation, chiffrement, code auto-modifiant) sur la routine d’attestation destinées à retarder l’analyse par l’attaquant des zones mémoire ciblées et utilisées par celles-ci : SWATT: SoftWare-based ATTestation for Embedded Devices, A. Seshadri et al., IEEE Symposium on Security and Privacy, 2004 PIONEER: Verifying code integrity and enforcing untampered code execution on legacy code, A. Seshadi et al., ACM SIGOPS Operating Systems Review, Volume 39, Issue 5, December 2005, pp 1–16, Remote Software Based Attestation for Wireless Sensors, M Shanek et al., lecture Notes in Computer Science, 2005 Soft Tamper-Proofing via Program integrity Verification in Wireless Sensor Networks, T. Park et al., EEE Transactions on Mobile Computing 4(3):297- 309, Juin 2005 Dans le document Tamper resistant software : an implementation, D. Aucsmith, Hiding, 30 mai 1996, il est présenté une combinaison de techniques exploitant le chiffrement, l’offuscation et la modification spontanée de la routine de mesure afin d’engendrer l’effort maximum à chaque attaque, réduisant l’acquisition de connaissance aboutissant à un contournement unique. Cependant, les techniques proposées dans les publications précitées n’ont jamais été mises en œuvre industriellement. Quelles que soient les promesses des auteurs de ces techniques, l’offuscation et les schémas de modifications auto-produites offrent un niveau de sécurité décroissant rapidement avec le temps lorsque l’attaquant peut disposer de plusieurs instances dans son champ d’analyse. De manière séparée et en complément, les méthodes exploitant le temps de réalisation de la mesure par le processeur engendrent des fausses détections d’attaque, si le processeur est fortement chargé par d’autres charges logicielles ou si le réseau intervenant dans la transmission est lui-même congestionné. Dans l’intégralité des techniques d’attestation logiciel décrites précédemment, aucune ne sort du schéma dans lequel la variabilité ne s’applique qu’à la fonction ou agent de mesure, jamais à l’empreinte mesurée elle-même. Dans toutes les techniques de l’art antérieur, y compris lorsque la routine de lecture est embarquée dans le programme lui-même, la mesure est produite sur des sections ou sur l’intégralité de l’empreinte du programme, partant d’une hypothèse de l’invariance de celle-ci. Dans le domaine de l’attestation à distance, l’homme de l’art peut remettre en cause la cible de sécurité utilisée dans laquelle l’attaquant produirait localement une analyse de la fonction de mesure ou de l’agent d’attestation. En effet, cette cible de sécurité ne correspond pas à la réalité qui met en présence deux modes d’attaque privilégiés. Les deux modes d’attaque de type de l'heure de contrôle à l'heure de consommation ToCToU (« Time-of-Check to Time-of-Use » en langue anglaise) décrits ci-dessous sont prépondérants et consistent en la remise en état de la mémoire avant que la mesure soit produite, sans qu’il soit nécessaire à l’attaquent d’analyser le type d’opérations et les zones mémoire ciblées par la mesure. Etat de l’art sur les attaques de type ToC/ToU Attaques par reconstruction de pages Au contraire des implémentations matérielles et de certaines implémentations hybrides, les implémentations logicielles partagent toutes la faiblesse d’être possiblement modifiées au niveau des adresses mémoire lues pour la mesure. Avec les implémentations logicielles, l’attaque consiste à modifier la routine de production de la mesure par le contournement des lectures en mémoire. Une modification classique utilise une zone mémoire préalablement chargée des données reflétant un état antérieur récupéré par l’attaquant de l’objet et sur laquelle on déroute systématiquement les lectures mémoire portant sur le programme mesuré. Cette attaque requiert une modification de l’agent de mesure pour dévier les opérations de lectures mémoire visant la plage d’adressage de l’empreinte. Cette attaque, désignée par reconstruction de pages (« Page-reconstruction » en langue anglaise) contourne les lectures de l’agent des pages du programme chargées par le processeur par des lectures sur la zone tampon préalablement produite. La réalisation de cette attaque repose sur le caractère supposé invariant du programme logiciel mesuré offrant la possibilité de récupérer son empreinte mémoire au démarrage ou à tout moment de son exécution et d’utiliser celle-ci pour les mesures à venir durant son exécution. Les schémas d’attestation engendrant une mesure différente telles que précédemment citées ne modifient pas ce postulat, c’est-à-dire l’invariance de l’empreinte mémoire sur lesquelles ces mesures sont réalisées, de telle sorte que les auteurs excluent les attaques par reconstruction de pages de la cible de sécurité. Pour contrer les attaques par reconstruction de pages, deux parades ont été élaborées. La première distingue le type de mémoire utilisée, à savoir les pages contenant les instructions fortement sollicitées par processeur et accédées rapidement par le processeur et les pages contenant les données dont l’accès est plus lent, notamment, mais pas seulement, parce que ces pages ne sont pas chargées en mémoire cache par le processeur. Par analyse des temps de réalisation de la mesure, on identifie si la mesure a été produite à partir des pages mémoire du programme ou en utilisant le contenu d’un tampon « image » de mémoire données préalablement monté par l’attaquant. Cette méthode est en particulier décrite dans le document Secure Remote Attestation, M. Jackobsson, 2018. Comme toutes les méthodes reposant sur des temps d’accès variant avec une grande amplitude, elle engendre ses fausses détections notamment parce que les variations de charge du processeur peuvent ralentir considérablement la réalisation de routines, sans qu’il y ait d’attaque réalisée. L’autre méthode consiste à casser la condition de réalisation de l’attaque, c’est-à-dire l’invariance du programme logiciel, par des changements d’instructions lors de l’exécution. Cette autre méthode est décrite dans le document : Strengthening software self-checksumming via self-modifying code. In ACSAC, pages 23–32. IEEE Computer Society, 2005, J. T. Giffin, M. Christodorescu, and L. Kruger. La méthode décrite dans ce document permet l’identification, par le programme lui-même embarquant une routine spécifique de détection, d’une attaque par reconstruction de pages mémoire. Il s’agit d’une méthode théorique de détection par le programme lui-même de l’architecture et du type de mémoire utilisée (i.e., Van Neumann, Harvard). La publication expose un principe d’invariance de l’empreinte sans permettre une réalisation d’un système d’attestation. La modification de l’empreinte par le programme lui-même étant asynchrone avec un vérifieur distant, engendre de facto un dysfonctionnement de l’attestation par la désynchronisation entre la modification spontanée du logiciel et une mesure de référence détenue par le vérifieur. La publication ne permet pas et n’ pas donné lieu à une mise en œuvre industrielle. Enfin, dans son implémentation, le test de détection, situé dans le programme, est exposé directement au contournement de ce test par l’attaquant. Attaques en zone aveugle Un second type d’attaque exploite la désynchronisation entre mesure et état courant du logiciel. Cette attaque consiste à modifier le logiciel entre deux mesures et à remettre en état la mémoire du processeur avant la prochaine mesure, sans nécessiter de reconstruction de pages comme explicité précédemment. Ce second type d’attaque, réalisé dans la zone aveugle entre deux mesures, peut être mis en œuvre pour tous types d’attestation matérielles, hybrides et logicielles. En effet, dans tous les cas, la mesure ne reflète que l’état du logiciel au moment précis où la mesure a été produite. Ces attaques modifiant l’empreinte entre deux mesures évitent la détection à la prochaine mesure par une identification du déclenchement de celle-ci, préférablement de manière automatisée. Différentes techniques ont été développées pour contrer ces attaques. Une première technique consiste à produire des mesures partielles, potentiellement consécutives et accumulatives, au cours de l’exécution du logiciel. Ces mesures (i.e., self-measurements) sont réalisées par le logiciel durant son exécution et apportent une détection partielle mais continue dans le temps et donc sans zone aveugle. Les mesures réalisées peuvent permettre de couvrir l’intégralité de l’empreinte du programme logiciel par accumulation successive de mesures partielles ou être restreintes à une partie de celle-ci seulement, notamment en ciblant des parties plus exposées. Pour réduire leur impact sur la performance du logiciel, ces mesures réalisées en continu portent chacune sur une zone mémoire réduite, avant leur agrégation différée. La stratégie pseudo-aléatoire de sélection des zones séquentiellement mesurées réduit la capacité de l’attaquant à prévoir où et quand sera réalisée la prochaine mesure, aboutissant à une approche probabiliste de détection de l’attaque. Le document brevet US9654499B2, intitulé System and Method for Mitigating TOC/TOU attacks in a cloud computing environment, propose une autre méthode de détection, basée sur la modification engendrée par l’attaque du flot de contrôle de la routine de mesure par l’extraction d’une valeur pseudo-aléatoire du registre processeur LBR contenant les adresses des blocs d’instructions exécutés. Cette méthode revendique d’assurer que la routine de mesure a bien été exécutée de bout en bout sans déviation vers un point d’arrêt ou une routine remettant la mémoire à l’état original. Dans I. De Oiveira Nunes et al, On the TOCTOU Problem in Remote Attestation (Nov 2021), les auteurs présentent deux techniques destinées pour les environnements contraints, visant des implémentations hybrides. Elles reposent sur le verrouillage en écriture des pages mémoire ouvertes en exécution et affectées à un logiciel applicatif restreignant le cadre des modifications de ces pages par l’administrateur du système et potentiellement un attaquant disposant des privilèges équivalents. Deux modes de réalisation permettent de tracer les dates de création-modification de ces pages par l’emploi ou non du compteur d’horloge. E tat de l’art relatif aux mesures partielles par le programme (i.e. « self measurements » ) L’état de l’art présente des techniques d’auto vérification de l’intégrité du programme par lui-même, utilisées pour la réalisation d’une attestation du programme ou pour vérifier l’intégrité de certaines parties du programme, notamment les plus exposées aux modifications. Ces mesures accèdent au contenu des pages chargées du programme logiciel et portent sur l’intégralité de son empreinte ou une partie restreinte. Les techniques d’attestation continue sont destinées à réduire l’impact de la mesure sur l’état de fonctionnement du programme (A.Brahim et al, 2017 SeED secure non intrusive attestation for embedded devices, X.Carpent et al, 2018 ERASMUS, efficient remote attestation via self measurements for unattended settings) destinées à réduire le risque d’attaques en déni de service par saturation de l’environnement d’exécution du programme logiciel. Ces attaques résultent du schéma général dans lequel le vérifieur initie les demandes d’attestation à l’agent de mesure qui doit s’exécuter, quel que soit l’état d’exécution du programme et la charge pesant sur son environnement d’exécution. Ces solutions inversent le schéma en positionnant l’agent pour initier l’attestation, réaliser sa mesure sans peser sur l’environnement d’exécution et la délivrer quand elle est prête. Ce schéma suit le postulat de la sécurité au meilleur effort en privilégiant la disponibilité du système mais sans garantir de fraîcheur freshness » en langue anglaise) de la mesure d’attestation réalisée spontanément par l’agent. Ce schéma de récupération de mesures successives et contenues ne réduit pas le risque de l’attaque par reconstruction de pages, chaque mesure étant réalisée sur les pages reconstruites préalablement. L’état de l’art comprend aussi la technique d’auto-vérification d’intégrité par le programme sur une partie restreinte sans agglomération de l’empreinte totale. Ces mesures ne délivrent une preuve d’intégrité que sur ce seul périmètre. Ces mesures délivrent une garantie dans un seul sens. En cas de détection d’un écart entre la mesure et ce qu’elle est supposée être, on peut conclure de manière certaine que le programme logiciel a été modifié mais la réciproque est fausse. Sans écart constaté sur la mesure partielle, on ne peut conclure de manière certaine que le programme logiciel est intact. En ciblant des parties du programme plus exposées à la modification, telle qu’une routine de vérification de droit d’utilisation, on met en place une stratégie de minage du programme logiciel optimisant la détection de la modification à dégradation de performance acceptable. Le domaine de la gestion de droits utilisateur DRM (« Digital Rights Management » en langue anglaise) a exploité cette technique pour protéger de manière non prédictive la routine de gestion de droits. Dans la pratique, on constate que chacun de ces pièges est contournable dès lors qu’il est identifié. L’état de l’art engendre aussi une réaction instantanée à la détection d’un écart. Pour les systèmes de DRM exploitant cette technique, les accès partiels aux pages mémoire du programme logiciel sont directement utiles au programme logiciel lui-même et utilisés dans le programme logiciel de telle sorte qu’une modification des valeurs lues engendrent une modification du comportement du programme logiciel durant son exécution, de manière instantanée et sans connaître à l’avance le changement de comportement du programme logiciel. Un attaquant disposant des moyens de tracer l’exécution du logiciel, notamment par l’utilisation d’un débogueur, peut remonter séquentiellement, pas à pas, à la cause, identifier la lecture génératrice et modifier la valeur de celle-ci par la valeur attendue, correspondant au programme original, avant modification, pour revenir à un comportement normal. Ainsi, dès lors que la cause de la réaction peut être identifiée, l’attaquant peut contourner le piège placé volontairement dans le programme. Les techniques décrites ci-dessus reposant sur la comparaison avec une référence immuable de l’empreinte, restent perméables aux attaques par reconstruction de pages. Etat de l’art sur les échanges sécurisés entre vérifieur et agent de mesure Quand les vérifications sont produites à distance, la sécurisation du transfert exploite le chiffrement asymétrique tel que par le protocole RSA pour la réalisation des signatures par l’agent et la vérification de l’origine de la signature par le vérifieur. La confiance attribuée aux signatures est conditionnée par l’impossibilité pour l’attaquant de disposer de la clef privée utilisée par l’émetteur. Pour éviter les attaques par rejeu rendues possibles par une interception du lien de communication entre le vérifieur et l’agent de mesure, les demandes de vérification intègrent un challenge basé sur un aléa détenu par le vérifieur et modifiant la réponse attendue par l’agent mais sans modifier la mesure réalisée par l’agent en tant que telle. Le challenge consiste à rajouter une couche de sécurité sur la transmission et non pas sur la mesure vérifiée, par comparaison à une référence fixe détenue par le vérifieur, et donc par définition qui ne peut changer avec l’aléa du challenge. Etat de l’art sur la sécurisation de la vérification La sécurisation de la fonction de vérification est cruciale. Dans tous les cas, le vérifieur doit disposer de l’état de la mesure d’attestation attendue et servant de référence. Dans l’état de l’art, cette condition est obtenue par la fourniture par une entité tiers durant le processus d’attestation, par le stockage de cette référence dans l’environnement d’exécution du vérifieur ou par la capacité du vérifieur à produire la signature par lui-même. Comme énoncé précédemment et, à l’exception des tentatives de J. T. Giffin et al. décrites dans le document précité, le caractère statique de cette unique référence pour un programme logiciel est un atout par l’attaquant. Des mécanismes de challenge pour contrer cette unicité et éviter les attaques par interception de la transmission et l’envoi du résultat généré sur un nœud valide ou par rejeu sont produit par le vérifieur et doivent évidemment rester secrets. Le caractère invariant de l’empreinte du programme mesuré et de la signature exposent le vérifieur aux attaques en confidentialité pour extraire la signature de référence qu’il utilisera pour son test de comparaison. Enfin, au bout du cycle d’attestation, la routine de vérification génère un résultat de test sur un seul bit (test positif ou négatif). Le résultat de ce test peut être forcé par l’attaquant si la routine de comparaison est identifiée et exposée à la modification. Ainsi, l’intégralité du procédé d’attestation est court-circuitée en s’attaquant directement au résultat. En définitive, l’état de l’art délivre différents schémas de sécurisation de la vérification, soit par sa localisation en lieu sûr, soit son intégration dans un environnement d’exécution de confiance (i.e., TEE). Les risques de déni de service associés à la concentration de la fonction en un seul lieu a aussi donné lieu à de nombreuses expérimentations de distribution de la fonction de vérification et, en particulier, à des schémas d’attestation mutuelle dans lesquels les fonctions de vérification et de mesure sont présentes dans tous les nœuds. Etat de l’art sur l’attestation d’un logiciel dont l’empreinte varie La variation de l’empreinte d’un programme logiciel peut s’inscrire dans une défense vis-à-vis de certaines attaques, cassant les conditions de réalisation de l’attaque. De manière emblématique, le procédé Address Space Layout Randomization (ASLR), à l’œuvre sur les systèmes d’exploitation récents, produit une allocation mémoire distincte à chaque nouveau chargement d’une application par le processeur, remédiant aux attaques par dépassement de tampon et aux attaques par contournement du flot de contrôle. Ce réarrangement mémoire contrevient au principe de l’attestation en rendant une mesure de référence du programme logiciel caduque. Cependant, le dispositif d’allocation mémoire produit un ordonnancement des fonctions du programme logiciel sans y toucher. Les instructions sont donc translatées en bloc par la modification des adresses mémoire du même incrément. Dans A. Cabutto et al. 2015 Software Protection with Code Mobility, les auteurs réconcilient la mobilité des fonctions en mémoire et la possibilité d’établir une mesure d’attestation en réduisant le périmètre mesuré aux fonctions prises séparément. Les mesures de référence sont restreintes aux fonctions. La routine d’attestation dispose des moyens nécessaires à leur localisation pour la production des mesures correspondantes. Il convient de noter que les mesures de référence correspondent à un périmètre invarié par l’attestation. L’attestation porte sur les fonctions prises séparément et dont les empreintes n’ont pas varié, en restant donc dans le schéma classique d’invariance de l’empreinte mesurée. L’ASLR a pour objectif de contrer des attaques d’un type différent que les attaques de type TOCTOU visant l’attestation. L’attaque par reconstruction de pages pourra être réalisée dès que les pages réallouées du programme logiciel sont chargées en mémoire. Ces pages ne variant plus après leur chargement seront récupérées et copiées en mémoire par l’attaquant. A notre connaissance, qu’elles que soient le type d’implémentation d’attestation dont celles intégrant les agents dans le système d’exploitation, aucune ne modifient l’empreinte avant la mesure, de manière contrôlée et anticipée, et réalisée au moment même où la mesure est produite. La méthode selon l’invention s’attaque au problème des attaques par reconstruction de pages pour les implémentations d’attestation logicielles. Son champ d’application couvre les mesures complètes ou partielles de l’empreinte du programme par un agent de mesure ou par le programme logiciel lui-même (i.e., « self measurements »). Pour ce faire, la méthode propose de rompre avec le schéma général reposant sur la constance de l’empreinte du programme une fois chargée par le processeur par la réalisation de modifications de celle-ci lors de la réalisation de la mesure et de telle sorte que l’empreinte modifiée permette de réaliser la mesure telle qu’attendue par le vérifieur, c’est-à-dire la mesure de référence. En revanche, toute récupération de l’empreinte du programme récupérée antérieurement à la mesure ne correspond pas à la mesure attendue. Dans la pratique, un élément critique des solutions d’attestation est la fourniture et la sécurisation des mesures de référence au vérifieur. Comme traité précédemment, la modification de l’empreinte requiert que celle-ci corresponde à l’état modifié de l’empreinte. L’invention apporte différentes réponses techniques à ce sujet, notamment, en permettant au vérifieur de produire par lui-même la mesure de référence de cet état modifié. Dans un mode de réalisation particulier de l’invention, on utilise des mesures statiques provenant de l’extérieur. Ce mode propose de modifier l’empreinte du programme dès son chargement en mémoire et de produire une modification inverse avant la mesure. Compte tenu de ce qui précède, l’invention a pour objet une méthode d’attestation d’un programme logiciel, comprenant des étapes selon lesquelles : on fournit un environnement d’exécution du programme logiciel comprenant un processeur, une mémoire volatile, un système d’exploitation, et un agent de mesure, on fournit un vérifieur, pour une exécution du programme logiciel par le processeur, le système d’exploitation charge en mémoire volatile des pages exécutables du programme logiciel dont un contenu constitue une empreinte du programme logiciel, l’empreinte du programme logiciel chargée dans la mémoire volatile est modifiée à l’initiative du vérifieur, de l’agent de mesure ou du système d’exploitation, l’agent de mesure exécute une fonction de mesure pour obtenir une mesure de l’empreinte modifiée du programme logiciel, la mesure de l’empreinte modifiée du programme logiciel est transférée au vérifieur, le vérifieur obtient une mesure de référence de l’empreinte modifiée du programme logiciel, cette mesure de référence étant réputée correcte, le vérifieur compare la mesure de l’empreinte modifiée du programme logiciel dans la mémoire volatile qui lui a été transférée avec la mesure de référence de l’empreinte modifiée, pour l’obtention d’un résultat de comparaison, et une intégrité du programme logiciel est attestée si le résultat de comparaison montre que les deux mesures sont identiques. De manière avantageuse, l’environnement d’exécution du programme logiciel est porté par une plateforme du programme logiciel et selon laquelle le vérifieur est contenu dans une plateforme distante, située en dehors de la plateforme du programme logiciel ; - l’empreinte du programme logiciel est remise dès la réalisation de la mesure dans son état avant la production de la mesure ; - l’agent de mesure est contenu dans le programme logiciel, le vérifieur génère la fonction de mesure, le vérifieur envoie la fonction de mesure à l’agent de mesure, et l’agent de mesure est modifié par l’insertion de la fonction de mesure ; - la méthode est appliquée à une pluralité d’attestations, et selon laquelle la fonction de mesure diffère pour chaque attestation ; - l’agent de mesure est doté d’un tampon mémoire accessible en écriture et exécution, le tampon mémoire permettant une insertion directe ou une construction d’instructions de la fonction de mesure, puis un transfert d’exécution de l’agent de mesure vers le tampon pour exécuter des instructions soit directement soit par reconstruction des instructions lors de l’exécution de l’agent de mesure ; - le tampon mémoire est remis dans son état initial, après la réalisation de la mesure ; - le tampon mémoire est chargé d’un contenu prédéfini par le vérifieur et différent de la fonction de mesure, une fois la mesure réalisée ; - la mesure ne porte que sur une partie restreinte du programme logiciel ; - l’agent ou le vérifieur intègrent et sont des fonctionnalités du système d’exploitation de l’environnement d’exécution du programme logiciel ; - à l’initiative du vérifieur ou de l’agent de mesure, l’empreinte du programme logiciel dans la mémoire volatile est modifiée au lancement ou dès une première phase d’exécution du programme logiciel et selon laquelle l’empreinte du programme est modifiée une seconde fois et de façon à récupérer l’empreinte du programme logiciel. BREVE DESCRIPTION DES FIGURES L'invention sera mieux comprise à la lecture de la description non limitative qui suit, rédigée au regard des dessins annexés, dans lesquels : FIG. 1 la FIG. 1 schématise un mode de réalisation particulier de l’invention selon lequel la modification de l’empreinte du programme repose sur les modifications engendrées sur le tampon, à savoir une zone mémoire ouverte en écriture et en lecture accessible à l’agent de mesure qui charge la fonction de mesure du vérifieur. Ces modifications peuvent provenir de la récupération de la fonction de mesure produite par le vérifieur ou la création de celle-ci par l’agent à la réception d’une donnée produite par le vérifieur. Cette figure présente finalement le périmètre de l’empreinte mémoire mesurée par la fonction de mesure et qui correspond à l’intégralité du programme logiciel, intégrant donc l’agent et son tampon. FIG. 2 la FIG. 2 présente le séquencement des différentes opérations réalisées par le vérifieur et l’agent, dans le mode de réalisation particulier de la FIG. 1 . La séquence recouvre les opérations d’un cycle d’attestation complet. FIG. 3 la FIG. 3 schématise un mode de réalisation particulier dans lequel les modifications sur l’empreinte du programme débordent de l’agent et lorsque l’agent est situé à l’extérieur du programme à mesurer. Le schéma présente une séquence d’opérations type réalisées par l’agent à la réception d’une donnée de synchronisation et/ou de sélection de la mesure à réaliser. L’agent peut intégrer le système d’exploitation de l’environnement d’exécution du programme logiciel. FIG. 4 la FIG. 4 schématise le vérifieur et ses interfaces avec l’agent de mesure, et un service de fourniture distant. La figure montre la capacité du vérifieur à produire la mesure de référence modifiée, par utilisation des éléments dont il dispose localement ou par échange avec le service distant. FIG. 5 la FIG. 5 schématise le périmètre de la mesure quand celle-ci ne porte que sur une sous-partie du programme logiciel et notamment le périmètre de cette mesure pour comprendre la modification de l’empreinte mesurée. FIG. 6 la FIG. 6 schématise le mode de réalisation consistant à la double modification de l’empreinte permettant de réaliser une mesure sur l’empreinte originale. DESCRIPTION DETAILLEE DE L’INVENTION La méthode selon l’invention propose d’engendrer de manière transitoire, éventuellement éphémère, une modification de l’empreinte du programme lors de la mesure. L'invention concerne une attestation locale ou à distance d’un programme logiciel, service de sécurité permettant de vérifier la conformité de celui-ci avec une mesure de référence portant sur son empreinte en mémoire. L’invention propose une modification de l’empreinte avec l’objectif de contrer les attaques par reconstruction de pages utilisant le contenu de l’empreinte récupérée antérieurement à la mesure. Elle s’applique à toutes les implémentations d’attestation logicielle, qu’elles utilisent ou pas un dispositif matériel, qu’elle soit réalisée à distance ou localement. Attestation transitoire et modifiant l’empreinte lors de la mesure Pour contrer les attaques par reconstruction de pages, l’invention modifie les schémas antérieurs en cassant le principe d’invariance de la mesure du programme. L’invention modifie de façon transitoire, éventuellement éphémère, l’empreinte du programme lors de la mesure elle-même. Une fois la mesure réalisée sur l’empreinte ainsi modifiée, elle peut avantageusement être remise dans l’état antérieur à la mesure. Les mesures réalisées selon la méthode de l’invention peuvent porter sur une empreinte partielle du programme logiciel. Différents modes de réalisation sont possibles et s’opposent sur la ou les localisation(s) des logiciels de modification de l’empreinte et de mesure, situées de manière regroupée ou inversement séparée à l’intérieur du logiciel mesuré ou à l’extérieur de celui-ci. Dans tous les cas, les opérations de mesure et de modification de l’empreinte sont synchronisées de manière à ce que la mesure porte sur l’empreinte dans son état modifié. Si l’invention permet tous les modes de réalisation précités, les modes de réalisation regroupant les deux opérations de mesure et de modification de l’empreinte dans un seul programme logiciel conçu pour une synchronisation de celles-ci sont à privilégier par facilité de réalisation. Une description de ce mode de réalisation privilégié est donnée ci-dessous. On notera que la vérification de l’empreinte mesurée se fait par comparaison avec une référence réputée correcte et qui doit correspondre à l’empreinte modifiée. Dans le cas où l’empreinte mesurée et le type de mesure varient au fil du temps, il convient de faire fournir de manière synchronisée au vérifieur le moyen de disposer des mesures de référence correspondant aux variations sur l’empreinte et le type de mesure. En pratique, le mode de réalisation privilégié est celui dans lequel le vérifieur initie la mesure, connaissant la fonction de mesure qu’il enverra ou qu’il commandera à l’agent de mesure. Par connaissance du programme mesuré, il peut disposer de son empreinte reconstituée, c’est-à-dire d’une représentation de celle-ci comprenant les adresses et le contenu des pages mémoire du programme logiciel telles qu’elles sont chargées par le processeur. Cette empreinte de référence peut lui être fournie par un service de fourniture externe ou en disposer dans son sein. Disposant de l’empreinte reconstituée et de la fonction de mesure, le vérifieur peut produire la mesure de référence qu’il utilisera pour sa comparaison. Une alternative est de disposer ou de récupérer, par un service de fourniture externe, des mesures de référence. Différentes structures de type centralisées ou distribuées, telles qu’une chaine de blocs, permettent d’assurer le service de fourniture externe de ces éléments. Dans un autre mode de réalisation, l’agent de mesure, ou le système d’exploitation, initient de manière spontanée le processus de mesure comprenant préalablement la modification de l’empreinte. Le vérifieur peut être informé de différentes façons sur le type de mesure et sur la modification préalable de l’empreinte, notamment par la transmission de l’agent ou du système d’exploitation au vérifieur simultanément à la mesure d’éléments caractérisant le type de mesure et la modification opérée avant la mesure. Comme mentionné plus haut, un autre mode d’utilisation de l’invention propose à produire une modification de l’empreinte du programme lors de son chargement en mémoire et une modification inverse de l’empreinte lors de la mesure résultant en ce que la mesure porte sur l’empreinte originale. Modes de réalisation privilégiés Les modes de réalisation privilégiés traitent du problème de la synchronisation entre la modification de l’empreinte et la réalisation de la mesure, en privilégiant le mode de réalisation où le vérifieur initie le processus d’attestation. La méthode selon l’invention propose alors d’intégrer un agent de mesure dans le programme mesuré. L’agent de mesure est chargé lors de la réalisation de la mesure d’une fonction de mesure. La modification de l’empreinte intervient à l’insertion, dans l’agent de mesure, de la fonction de mesure, intégrant le périmètre de la mesure. En complément, on peut, avantageusement, restaurer l’empreinte initiale par un effacement de la fonction de mesure ou son remplacement par des données postérieurement à la mesure, ne laissant aucune trace sur la fonction de mesure et donc l’empreinte mesurée postérieurement à la réalisation de la mesure. Ce premier mode de réalisation propose ainsi une insertion, dans l’agent de mesure, d’un tampon mémoire ouvert en écriture et en exécution, chargé lors d’une demande d’attestation par le vérifieur par la fonction de mesure. Celle-ci peut contenir une séquence d’instructions ou, alternativement, une donnée nécessaire et utilisée par l’agent pour construire par lui-même cette séquence d’instructions. Dans le premier mode de réalisation, la génération de la fonction de mesure peut être produite par le vérifieur. Elle peut résulter d’une construction pseudo-aléatoire de la séquence d’instructions, initiée par un aléa généré par le vérifieur et résultant en une séquence d’instructions et des données constituant la fonction de mesure. Ces instructions produisent une collecte des pages de l’empreinte du programme, puis un hachage de ces pages du programme, potentiellement prises dans un ordre aléatoire et modifiées par des opérations logiques de tous types (par ex. une addition ou un ou exclusif). Les séquences d’instructions utilisées peuvent aussi être sélectionnées dans un ensemble de combinaisons d’instructions iso-fonctionnelles, telles que fournies par les solutions d’offuscation. Dans un second mode de réalisation, la fonction de mesure peut résulter d’une construction dynamique par l’agent de mesure, utilisant une donnée transmise lors de la mesure par le vérifieur. L’agent de mesure peut directement exécuter la fonction de mesure une fois constituée et chargée dans le tampon. Ces deux modes de réalisation assurent, par construction, la cohérence et la synchronisation des opérations de modifications de l’empreinte et de mesure sur cette empreinte, étant observé que, dans les deux cas, les mesures sont produites par la fonction de mesure là où elle a déjà modifié par sa présence l’empreinte, c’est-à dire dans le tampon intégrant le périmètre de l’agent, intégrant lui-même le périmètre mesuré. Un troisième mode de réalisation propose de placer un agent de mesure situé à l’extérieur du programme logiciel, qui coordonne les opérations de réalisation de modification totale ou partielle de l’empreinte puis de mesure. L’agent peut éventuellement intégrer le système d’exploitation de l’environnement d’exécution. Les modifications de l’empreinte peuvent comprendre un remplacement iso-fonctionnel de séquences d’instructions, un réagencement des adresses en mémoire des différentes fonctions du programme. Ce mode de réalisation nécessite de contrôler le flot de contrôle du programme, d’interrompre celui-ci, de récupérer le contexte d’exécution du programme (i.e., les registres du processeurs), d’insérer les modifications du programme puis de relancer le programme avec son contexte d’exécution récupéré au point d’arrêt. Une fois la modification réalisée, l’agent peut alors produire et envoyer sa mesure. Tout comme explicité plus haut, il conviendra d’assurer la synchronicité entre la modification totale ou partielle de l’empreinte et la fourniture ou le calcul par le vérifieur de la mesure de référence correspondant aux modifications de l’empreinte. Processus d’attestation engendrant une modification de l’empreinte avant la mesure L’invention apporte une réponse purement logicielle et par principe aux attaques TOCTOU par reconstruction de pages, pour les implémentations logicielles d’attestation locale ou à distance d’un programme logiciel. Pour ce faire, elle met en œuvre le principe de la modification transitoire, éventuellement éphémère, de l’empreinte du programme lors de la réalisation de la mesure d’attestation, rompant avec le caractère invariant de l’empreinte mémoire du programme à mesurer. Elle engendre de ce fait le besoin de synchronisation des opérations de modification de l’empreinte, de mesure de l’empreinte et de vérification sur la bonne référence de l’empreinte. Un premier mode de réalisation est décrit dans la FIG. 1 . L’agent fait partie intégrante du programme logiciel, modifié à cet effet, notamment et, en particulier, par des opérations de modification automatiques du fichier exécutable du programme afin d’insérer cet agent. L’agent comprend une zone mémoire ouverte en écriture et en exécution (i.e., le tampon mémoire), réceptacle de la fonction de mesure qui lui est envoyée par le vérifieur. Cette fonction est une séquence d’instructions dont l’exécution réalise la mesure. Cette séquence d’instruction peut soit être directement produite et transférée par le vérifieur soit résulter d’une construction à partir de données préalablement chargées dans le tampon de l’agent et par utilisation d’une donnée fournie par le vérifieur lors de sa demande d’attestation à l’agent. Cette donnée peut être un élément cryptographique permettant de décoder et transformer la donnée déjà présente dans l’agent sous forme chiffrée pour résulter en la séquence d’instructions recherchée. La construction de la séquence d’instructions de la charge résulte toujours de l’exécution de l’agent. La mesure de l’agent portera sur l’intégralité du programme logiciel intégrant ainsi les instructions de l’agent lui-même et donc de celles produites spécifiquement pour la fonction de mesure. La mesure est exécutée dès son placement ou réalisation dans le tampon. Toute récupération par l’attaquant de l’empreinte du programme antérieure à l’exécution de la mesure par la fonction de mesure, ne comprenant pas les instructions de la fonction de mesure, ne pourra être utilisée. Postérieurement à la réalisation de la mesure, le tampon mémoire peut être remis dans son état initial ou chargé d’une valeur prédéfinie et connue du vérifieur, avant que la mesure fut produite, supprimant toute trace pour une analyse ultérieure du logiciel par l’attaquant. La FIG. 1 présente le cas où le vérifieur est situé dans un autre environnement d’exécution que celui du programme logiciel, donnant lieu à une attestation à distance. L’intégration du vérifieur dans l’environnement d’exécution du programme logiciel donne lieu à une attestation locale. L’intégration du vérifieur dans le programme logiciel donne lieu à une auto attestation. La FIG. 2 décrit le séquencement des opérations et la collaboration entre le vérifieur et l’agent de mesure. Un second mode de réalisation est présenté à la FIG. 3 , avec un agent extérieur au programme mesuré mais qui dispose des moyens intrusifs de contrôle sur l’exécution du programme et ses pages mémoire. Dans ce cas extrême et représentant un cas théorique, l’agent pourra intercepter le flot de contrôle, bloquer l’exécution, récupérer le contexte d’exécution, modifier des pages du programme, produire la mesure sur l’intégralité du programme (dont les pages ainsi modifiées) et lancer le programme modifié avec le contexte d’exécution modifié. L’agent peut intégrer le périmètre du système d’exploitation, le programme mesuré ou être situé à l’extérieur de ceux-ci. La FIG. 4 schématise le fonctionnement du vérifieur. Le vérifieur comprend des instructions logicielles, un espace de stockage dans lequel se trouvent potentiellement des empreintes de programme logiciel, des mesures de références et des fonctions de mesures. Le vérifieur est potentiellement interfacé à un service de fourniture externe délivrant des mesures de référence, des empreintes et des fonctions de mesure. Le vérifieur est aussi interfacé aux agents de mesure. Dans le mode de réalisation privilégié, le vérifieur initie la demande d’attestation. Pour la production de la fonction de mesure, il peut se référer à son espace de stockage ou établir une demande auprès du service de fourniture externe. Il transmet à l’agent la fonction de mesure elle-même ou un élément permettant à l’agent de construire cette fonction de mesure avant son chargement. Le vérifieur peut récupérer dans son espace de stockage ou par l’établissement d’un échange avec le service de fourniture externe, la mesure de référence ou la calculer en disposant de l’empreinte du programme et de la fonction de mesure appliquée. Quand l’agent de mesure initie l’attestation, le vérifieur pourra récupérer, notamment lors de la réception de mesures, les éléments complémentaires transmis par l’agent et caractérisant la fonction de mesure et/ou la modification de l’empreinte opérée. La FIG. 5 schématise le mode de réalisation de mesures partielles. Les différents modes de réalisation décrits, quand la mesure porte sur l’empreinte intégrale du programme, sont possibles, tout en respectant le principe de la modification de l’empreinte mesurée avant la mesure de celle-ci. L’empreinte mesurée doit donc comprendre la partie ayant été modifiée par la mesure. Il peut s’agir de la partie restreinte modifiée ou alternativement de l’agent. Dans le premier cas, l’empreinte mesurée est uniquement la sous-partie du programme logiciel. Dans le second cas, l’empreinte mesurée correspond à la réunion de parties restreintes du programme logiciel et de l’agent de mesure. La figure présente l’agent de mesure dans le programme logiciel. Ce dernier pourra être extérieur et éventuellement intégrer le système d’exploitation. La FIG. 6 présente le flot des opérations mises en œuvre pour permettre l’exploitation de l’invention en réalisant une mesure sur l’empreinte originale du programme logiciel, à travers une double modification de l’empreinte, la seconde modification étant inverse à la première. La première modification est réalisée dès la phase de chargement ou au lancement du programme logiciel. La seconde modification réalisée juste avant la mesure. Une méthode d’attestation d’un programme logiciel, comprenant des étapes selon lesquelles : on fournit un environnement d’exécution du programme logiciel comprenant un processeur, une mémoire volatile, un système d’exploitation, et un agent de mesure, on fournit un vérifieur, pour une exécution du programme logiciel par le processeur, le système d’exploitation charge en mémoire volatile des pages exécutables du programme logiciel dont un contenu constitue une empreinte du programme logiciel, l’empreinte du programme logiciel chargée dans la mémoire volatile est modifiée à l’initiative du vérifieur, de l’agent de mesure ou du système d’exploitation, l’agent de mesure exécute une fonction de mesure pour obtenir une mesure de l’empreinte modifiée du programme logiciel, la mesure de l’empreinte modifiée du programme logiciel est transférée au vérifieur, le vérifieur obtient une mesure de référence de l’empreinte modifiée du programme logiciel, cette mesure de référence étant réputée correcte, le vérifieur compare la mesure de l’empreinte modifiée du programme logiciel dans la mémoire volatile qui lui a été transférée avec la mesure de référence de l’empreinte modifiée, pour l’obtention d’un résultat de comparaison, et une intégrité du programme logiciel est attestée si le résultat de comparaison montre que les deux mesures sont identiques. La méthode selon la revendication 1, selon laquelle l’environnement d’exécution du programme logiciel est porté par une plateforme du programme logiciel et selon laquelle le vérifieur est contenu dans une plateforme distante, située en dehors de la plateforme du programme logiciel. La méthode selon l’une des revendications 1 ou 2, selon laquelle l’empreinte du programme logiciel est remise dès la réalisation de la mesure dans son état avant la production de la mesure. La méthode selon l’une des revendications précédentes, selon laquelle l’agent de mesure est contenu dans le programme logiciel, le vérifieur génère la fonction de mesure, le vérifieur envoie la fonction de mesure à l’agent de mesure, et l’agent de mesure est modifié par l’insertion de la fonction de mesure. La méthode selon l’une des revendications précédentes, appliquée à une pluralité d’attestations, et selon laquelle la fonction de mesure diffère pour chaque attestation. La méthode selon l’une des revendications précédentes, caractérisée en ce que l’agent de mesure est doté d’un tampon mémoire accessible en écriture et exécution, le tampon mémoire permettant une insertion directe ou une construction d’instructions de la fonction de mesure, puis un transfert d’exécution de l’agent de mesure vers le tampon pour exécuter des instructions soit directement soit par reconstruction des instructions lors de l’exécution de l’agent de mesure. La méthode selon la revendication 6, dans laquelle le tampon mémoire est remis dans son état initial, après la réalisation de la mesure. La méthode selon la revendication 6, selon laquelle le tampon mémoire est chargé d’un contenu prédéfini par le vérifieur et différent de la fonction de mesure, une fois la mesure réalisée. La méthode selon l’une des revendications précédentes, selon laquelle la mesure ne porte que sur une partie restreinte du programme logiciel. La méthode selon l’une des revendications précédentes, selon laquelle l’agent ou le vérifieur intègrent et sont des fonctionnalités du système d’exploitation de l’environnement d’exécution du programme logiciel. La méthode selon l’une des revendications précédentes, selon laquelle, à l’initiative du vérifieur ou de l’agent de mesure, l’empreinte du programme logiciel dans la mémoire volatile est modifiée au lancement ou dès une première phase d’exécution du programme logiciel et selon laquelle l’empreinte du programme est modifiée une seconde fois et de façon à récupérer l’empreinte du programme logiciel.