FR 3160482 A1 20250926 FR 2402958 A 20240325 L’invention concerne un procédé pour authentifier des versions successives d’un fichier informatique à partir d’une première version dont l’authenticité est certaine ou admise, comprenant les étapes consistant à prévoir une source unique de paires de clés d’authentification, générer une première clé publique d’authentification et une première clé privée d’authentification, former une version finale de la première version du fichier comprenant la première version du fichier et au moins la première clé publique d’authentification, générer ou obtenir une deuxième version du fichier, générer une deuxième clé publique d’authentification et une deuxième clé privée d’authentification, calculer une signature d’authentification de la deuxième version du fichier au moyen de la clé privée d’authentification de la première paire de clés d’authentification et à partir d’un bloc de données comprenant au moins la deuxième version du fichier et la deuxième clé publique d’authentification, et former une version finale de la deuxième version du fichier comprenant au moins la deuxième version du fichier, la deuxième clé publique d’authentification et la signature d’authentification de la deuxième version du fichier. Figure 8B Procédé pour authentifier des versions successives d’un fichier informatique La présente invention concerne un procédé pour authentifier des versions successives d’un fichier informatique, et un procédé de fabrication d’au moins deux versions d’un fichier informatique liées entre elles par un lien d’authentification. Arrière-plan Les modules de sécurité matérielle ou « HSM » (« Hardware Security Modules ») sont des périphériques physiques renforcés et inviolables qui sécurisent les processus cryptographiques en générant, protégeant et gérant les clés utilisées pour le chiffrement et le déchiffrement des données et la création de signatures numériques et de certificats. Les modules de sécurité matérielle sont testés, validés et certifiés selon les normes de sécurité les plus strictes. Ils sont devenus à l’heure actuelle des outils essentiels pour renforcer la sécurité des données et des transactions dans divers environnements et applications. Les modules de sécurité matérielle sont utilisés dans des applications financières ou de gestion de cryptoactifs, pour sécuriser les transactions et les données sensibles, pour la gestion d'identité et l’authentification de personnes, pour sécuriser l'émission et la gestion de certificats numériques et de clés d'authentification, pour le chiffrement de bases de données et d’archives, pour sécuriser des communications réseau, et enfin gérer des clés et des certificats dans des infrastructures à clé publique (PKI). La maintenance régulière d’un module de sécurité matérielle, qui inclut la mise à jour de son microprogramme (« firmware »), est essentielle pour garantir qu’il reste protégé contre les nouvelles vulnérabilités et menaces. A cet égard, la personne qui exploite un module de sécurité matérielle doit être assurée que chaque nouvelle version du microprogramme qui lui est communiquée est authentique et n’est pas passée entre les mains d’un fraudeur. A cet effet, chaque nouvelle version ou mise à jour est généralement livrée accompagnée d’une signature générée par le concepteur au moyen d’une clé privée connue uniquement de lui. Avant d’installer cette mise à jour, l’opérateur vérifie la validité de cette signature au moyen d’une clé publique qui lui est communiquée par le concepteur. Ce procédé offre une garantie à l’opérateur que le microprogramme a été produit par le concepteur agréé, grâce à la communication par ce dernier de la clé publique correspondante. En revanche, il ne permet pas au concepteur de s’assurer que le microprogramme et ses mises à jour ultérieures, sont correctement mis en œuvre par l’opérateur. Notamment, l’administrateur d’un module de sécurité matérielle a généralement tous les droits sur la mémoire programme de celui-ci. Une personne qui parviendrait à lui dérober ses codes d'accès pourrait apporter au microprogramme des modifications visant à modifier son fonctionnement, voire le remplacer par une version corrompue. Par ailleurs, dans certaines applications, le concepteur du microprogramme utilise le module de sécurité matérielle pour ses propres besoins dans le cadre d’un service qu’il offre au public, mais fait appel à des tiers partenaires pour déployer ce service. Dans ce cas, le microprogramme est utilisé par les tiers partenaires dans leurs propres environnements informatiques, qui ne sont pas sous le contrôle du concepteur. Il est donc essentiel, notamment au moment où une mise à jour est envoyée à un tiers partenaire, que le concepteur puisse s’assurer que personne chez les tiers partenaires ne pourra en profiter pour falsifier la mémoire programme du système concerné. Or, il est connu que la mise à jour sécurisée d'un système à distance peut s'avérer difficile lorsque le système d'exploitation sous-jacent, qui est responsable de la vérification des mises à jour, n'est pas totalement fiable pour cette tâche. Notamment, les systèmes d'exploitation des modules de sécurité matérielle ne sont généralement pas protégés contre les menaces d'initiés lors de la signature des microprogrammes ou les menaces d'initiés lors de l'installation des microprogrammes. Un autre type d’attaque pouvant être redouté, appelé « attaque par rétrogradation » (« rollback attack »), consiste dans l’installation d’une version antérieure ayant une faille de sécurité. Il pourrait donc être souhaité de prévoir un moyen permettant de sécuriser les mises à jour de microprogrammes et de garantir que personne ne pourra tirer profit de ces opérations pour corrompre le fonctionnement d’un processeur tel qu’un module de sécurité matérielle. Plus particulièrement, il pourrait être souhaité de prévoir un procédé pour sécuriser la mise à jour d’un microprogramme, permettant de s’assurer, après l’installation d’une version initiale du microprogramme, que toutes les versions ultérieures seront installées sans possibilité pour une personne détenant des codes d’accès d’administrateur d’effacer le microprogramme ou de le modifier, ou encore de procéder à une rétrogradation de celui-ci. Il pourrait également être souhaité de prévoir un procédé permettant d’authentifier de manière simple et efficace des versions successives d’un fichier informatique, notamment un fichier de microprogramme, et un procédé de fabrication de différentes versions d’un fichier informatique liées entre elles par un lien d’authentification. Résumé Des modes de réalisation concernent un procédé pour authentifier des versions successives d’un fichier informatique, à partir d’une première version du fichier dont l’authenticité est certaine ou admise, comprenant les étapes consistant à prévoir une source unique de paires de clés d’authentification, chaque paire de clé d’authentification comprenant une clé privée d’authentification et une clé publique d’authentification ; au moyen de la source unique de paires de clés d’authentification, générer une première paire de clés d’authentification comprenant une première clé publique d’authentification et une première clé privée d’authentification ; former une version finale de la première version du fichier, la version finale de la première version du fichier comprenant la première version du fichier et au moins la première clé publique d’authentification ; générer ou obtenir une deuxième version du fichier, au moyen de la source unique de paires de clés d’authentification, générer une deuxième paire de clés d’authentification comprenant une deuxième clé publique d’authentification et une deuxième clé privée d’authentification ; calculer une signature d’authentification de la deuxième version du fichier au moyen de la clé privée d’authentification de la première paire de clés d’authentification et à partir d’un bloc de données comprenant au moins la deuxième version du fichier et la deuxième clé publique d’authentification ; et former une version finale de la deuxième version du fichier, la version finale comprenant au moins la deuxième version du fichier, la deuxième clé publique d’authentification et la signature d’authentification de la deuxième version du fichier. Selon un mode de réalisation, le procédé comprend une étape de vérification de l’authenticité de la version finale de la deuxième version du fichier en référence à la version finale de la première version du fichier, l’étape de vérification de l’authenticité de la version finale de la deuxième version du fichier comprenant l’étape consistant à vérifier la validité de la signature d’authentification de la deuxième version du fichier au moyen de la première clé publique d’authentification présente dans la version finale de la première version du fichier et à partir du bloc de données comprenant au moins la deuxième version du fichier et la deuxième clé publique d’authentification. Selon un mode de réalisation, l’étape de vérification d’authenticité est conduite par une personne, une machine ou un processeur ne connaissant aucune des clés privées. Selon un mode de réalisation, le procédé comprend les étapes consistant à attribuer à la deuxième version du fichier une information permettant de le distinguer de la première version du fichier, telle qu’un numéro de version, une date de création ou autre information d’identification, et ajouter l’information concernant la deuxième version du fichier au bloc de données à partir duquel la signature d’authentification de la deuxième version du fichier est calculée. Selon un mode de réalisation, le procédé comprend l’étape consistant à insérer des marqueurs dans le bloc de données à partir duquel la signature d’authentification de la deuxième version du fichier est calculée, pour distinguer la deuxième version du fichier de la deuxième clé publique d’authentification et distinguer la deuxième clé publique d’authentification de l’information concernant la deuxième version du fichier. Selon un mode de réalisation, le procédé comprend les étapes consistant à générer ou obtenir une troisième version du fichier, au moyen de la source unique de paires de clés d’authentification, générer une troisième paire de clés d’authentification comprenant une troisième clé publique d’authentification et une troisième clé privée d’authentification, calculer une signature d’authentification de la troisième version du fichier au moyen de la clé privée d’authentification de la deuxième paire de clés d’authentification et à partir d’un bloc de données comprenant au moins la troisième version du fichier et la troisième clé publique d’authentification, et former une version finale de la troisième version du fichier, la version finale comprenant au moins la troisième version du fichier, la troisième clé publique d’authentification et la signature d’authentification de la troisième version du fichier. Selon un mode de réalisation, le procédé comprend une étape de vérification de l’authenticité de la version finale de la troisième version du fichier en référence à la version finale de la deuxième version du fichier, l’étape de vérification de l’authenticité de la version finale de la troisième version du fichier comprenant l’étape consistant à vérifier la validité de la signature d’authentification de la troisième version du fichier au moyen de la deuxième clé publique d’authentification présente dans la version finale de la deuxième version du fichier et à partir du bloc de données comprenant au moins la troisième version du fichier et la troisième clé publique d’authentification. Selon un mode de réalisation, l’étape de vérification de l’authenticité de la version finale de la troisième version du fichier est conduite par une personne, une machine ou un processeur ne connaissant aucune des clés privées. Selon un mode de réalisation, le procédé comprend les étapes consistant à attribuer à la troisième version du fichier une information permettant de le distinguer de la deuxième du fichier, telle qu’un numéro de version, une date de création ou autre information d’identification, et ajouter l’information permettant de distinguer la troisième version du fichier de la deuxième version du fichier au bloc de données à partir duquel la signature d’authentification de la troisième version du fichier est calculée. Selon un mode de réalisation, le procédé comprend comprenant l’étape consistant à insérer des marqueurs dans le bloc de données à partir duquel la signature d’authentification de la troisième version du fichier est calculée, pour distinguer la troisième version du fichier de la troisième clé publique d’authentification et distinguer la troisième clé publique d’authentification de l’information concernant la troisième version du fichier. Selon un mode de réalisation, dans lequel deux paires de clés de rangs successifs peuvent être identiques ou différentes. Selon un mode de réalisation, le procédé comprend chaque version du fichier est une version d’un document comprenant du texte et/ou des images. Selon un mode de réalisation, chaque version du fichier est une œuvre d’art numérique ou numérisée et chaque version du fichier correspond à une version de l’œuvre à des stades différents de sa création ou à des dates différentes de l’œuvre finalisée. Selon un mode de réalisation, chaque fichier est un fichier microprogramme installé ou destiné à être installé dans un processeur. Selon un mode de réalisation, l’étape de vérification d’authenticité est conduite par un module de protection du processeur, le module de protection étant configuré pour empêcher que le fichier microprogramme ne soit effacé et empêcher qu’une version non authentique d’une mise à jour du fichier microprogramme ne soit installée dans le processeur. Selon un mode de réalisation, le procédé comprend les étapes consistant à concaténer la version finale de la deuxième version du fichier microprogramme avec une signature d’installation générée au moyen d’une clé privée d’installation et à partir de la version finale de la deuxième version du fichier microprogramme, et fournir une clé publique d’installation correspondant à la clé privée d’installation au processeur dans lequel la deuxième version du fichier microprogramme doit être installée. Selon un mode de réalisation, les versions finales du fichier microprogramme sont fournies à un exploitant du processeur n’ayant accès à aucune clé privée. Des modes de réalisation concernant également un procédé de fabrication d’au mois deux versions d’un fichier informatique liées entre elles par un lien d’authentification, comprenant les étapes consistant à prévoir une source unique de paires de clés d’authentification, chaque paire de clé d’authentification comprenant une clé privée d’authentification et une clé publique d’authentification ; au moyen de la source unique de paires de clés d’authentification, générer une première paire de clés d’authentification comprenant une première clé publique d’authentification et une première clé privée d’authentification ; générer ou obtenir une première version du fichier ; former une version finale de la première version du fichier, la version finale de la première version du fichier comprenant la première version du fichier et au moins la première clé publique d’authentification ; enregistrer la version finale de la première version du fichier sur un support ; générer ou obtenir une deuxième version du fichier ; au moyen de la source unique de paires de clés d’authentification, générer une deuxième paire de clés d’authentification comprenant une deuxième clé publique d’authentification et une deuxième clé privée d’authentification ; calculer une signature d’authentification de la deuxième version du fichier au moyen de la clé privée d’authentification de la première paire de clés d’authentification et à partir d’un bloc de données comprenant au moins la deuxième version du fichier et la deuxième clé publique d’authentification ; former une version finale de la deuxième version du fichier, la version finale comprenant au moins la deuxième version du fichier, la deuxième clé publique d’authentification et la signature d’authentification de la deuxième version du fichier ; et enregistrer la version finale de la deuxième version du fichier sur un support. Selon un mode de réalisation, le procédé comprend les étapes consistant à attribuer à la deuxième version du fichier au moins une information permettant de le distinguer de la première version du fichier, et ajouter l’information concernant la deuxième version du fichier au bloc de données à partir duquel la signature d’authentification de la deuxième version du fichier est calculée. Selon un mode de réalisation, le procédé comprend les étapes consistant à générer ou obtenir une troisième version du fichier ; au moyen de la source unique de paires de clés d’authentification, générer une troisième paire de clés d’authentification comprenant une troisième clé publique d’authentification et une troisième clé privée d’authentification ; calculer une signature d’authentification de la troisième version du fichier au moyen de la clé privée d’authentification de la deuxième paire de clés d’authentification et à partir d’un bloc de données comprenant au moins la troisième version du fichier et la troisième clé publique d’authentification ; former une version finale de la troisième version du fichier, la version finale comprenant au moins la troisième version du fichier, la troisième clé publique d’authentification et la signature d’authentification de la troisième version du fichier ; et enregistrer la version finale de la troisième version du fichier sur un support. Description sommaire des dessins Ces caractéristiques et avantages de l’objet de la présente divulgation seront mieux compris à la lecture de la description suivante d’exemples de réalisation détaillés, faite à titre non limitatif en relation avec les figures jointes, parmi lesquelles : - la FIG. 1 précédemment décrite montre des étapes d’un procédé de fabrication classique d’un microprogramme, - la FIG. 2 montre la structure logicielle classique d’un module de sécurité matérielle, - la FIG. 3 montre des étapes de modification de l’architecture logicielle d’un module de sécurité matérielle pour sécuriser ses mises à jour, - la FIG. 4 montre la structure logicielle d’un module de sécurité matérielle sécurisé comme illustré sur la FIG. 3 , - la FIG. 5 est un organigramme illustrant le traitement de commandes d’effacement et de mise à jour par le module de sécurité matérielle sécurisé de la FIG. 4 , - la FIG. 6 et la FIG. 6 illustrent un mode de réalisation d’un procédé de fabrication de versions successives sécurisées d’un microprogramme, - la FIG. 7 montre des étapes d’authentification des versions successives sécurisées du microprogramme, - la FIG. 8 illustre un autre mode de réalisation d’un procédé de fabrication de versions successives sécurisées d’un microprogramme, - la FIG. 8 montre la structure de trois versions successives de microprogrammes sécurisés réalisées selon le procédé de la FIG. 8 , - la FIG. 9 est un diagramme de séquence montrant plus en détail des étapes du procédé de fabrication de la FIG. 8 , - la FIG. 9 décrit les étapes de la FIG. 9 , - la FIG. 10 est un diagramme de séquence montrant des étapes d’installation d’une version initiale d’un microprogramme sécurisé dans un module de sécurité matérielle, - la FIG. 10 décrit les étapes de la FIG. 10 , - la FIG. 11 et la FIG. 12 sont des diagrammes de séquence montrant des étapes d’installation d’une version ultérieure sécurisée du microprogramme, - la FIG. 11 et la FIG. 12 décrivent les étapes de la FIG. 11 et de la FIG. 12 , et - la FIG. 13 montre une architecture de système utilisant des modules de sécurité matérielle sécurisés conformément à la présente divulgation. Description détaillée La FIG. 1 montre schématiquement un procédé classique de signature d’un microprogramme, destiné par exemple à être installé dans un module de sécurité matérielle. Un code source du microprogramme FW est tout d’abord transformé par un serveur d’intégration BSRV0 (« Build Server ») en code objet ou code exécutable formant un bloc de données DB1, par exemple au format ELF (Executable and Linkable Format). Une signature d’installation ISIGN est ensuite calculée, au moyen d’un clé privée d’installation IpK. A cet effet, le bloc de données DB1 est appliqué à une fonction de hachage FH1 qui fournit un condensé H1 de celui-ci. Le condensé H1 et la clé privée d’installation IpK sont appliqués à une fonction de signature FS1 qui fournit la signature ISIGN. L’opération peut être réalisée par un module de sécurité matérielle HSMa, qui fournit la clé privée d’installation IpK ainsi qu’une clé publique d’installation IPK correspondante. La signature ISIGN est ensuite concaténée avec le bloc de données DB1 précédée d’un champ SIZE(ISIGN) indiquant la taille de la signature, le tout étant suivi d’un champ OID(FS1) (« Object Identifier ») donnant une information sur la fonction de signature FS1 utilisée. Le champ OID est précédé d’un champ SIZE(OID) indiquant la taille de l’identifiant OID. Un champ SIZE(DB1) peut aussi être inséré avant le bloc de données DB1, pour indiquer la taille de celui-ci. Le code exécutable DB1 concaténé avec les métadonnées SIZE(DB1), SIZE(ISIGN), ISIGN, SIZE(OID) et OID(FS1) forme un bloc de données final DBF qui est fourni à l’exploitant d’un module de sécurité matérielle HSMo en tant que version finale du microprogramme. La clé publique d’installation IPK est également fournie à l’exploitant, qui l’enregistre dans un compte d'administrateur du module de sécurité matérielle. Au moment de l’installation du microprogramme, le système d’exploitation du module de sécurité matérielle vérifie la validité de la signature ISIGN au moyen de la clé publique d’installation IPK, et refuse de procéder à cette installation si la signature est trouvée invalide. Par exemple, si la signature ISIGN, est une signature RSA, la vérification de la signature comprend les opérations consistant d’une part à retrouver le condensé d’origine H1 en fournissant à une fonction FS1 -1 inverse de FS1 le bloc de données DB1 et la clé publique IPK, et d’autre part calculer le condensé H1’ du bloc de données DB1 au moyen de la fonction FH1. Les deux condensés sont ensuite comparés (COMP). Si le résultat de la comparaison COMP est positif (« OK »), le système d’exploitation OS du module de sécurité matérielle HSMo accepte de charger le microprogramme dans sa mémoire programme PMEM. La FIG. 2 montre l’architecture logicielle classique du module de sécurité matérielle HSMo. Ce dernier est relié à un dispositif hôte HDV tel un serveur, par l’intermédiaire d’une liaison de type PCI (« Peripheral Component Interconnect Express ») ou Ethernet. Le dispositif hôte exécute un programme applicatif PGR qui fait appel au module de sécurité matérielle HSMo pour réaliser des calculs cryptographiques et stocker des clés. A cet effet le dispositif HDV utilise une librairie standard SLIB1, par exemple la librairie Cryptoki (« Cryptographic Token Interface Standard ») composée de fonctions PKCS#11. Il sera rappelé ici que la norme PKCS#11 est une interface de programmation d’application API (« Application Programming Interface ») prévue pour les jetons cryptographiques tels que les modules de sécurité matérielle et les cartes à puce. La librairie SLIB1 fournit des fonctions standards à une interface MDA (« Message Dispatch API ») qui envoie les commandes de fonctions standards SF au module de sécurité matérielle HSMo via l’interface PCI ou Ethernet. Dans le module de sécurité matérielle HSMo, les appels de fonctions standards SF sont reçus par un module de traitement de messages MPM0 (« Message Processing Module ») conçu par exemple pour traiter des fonctions PKCS#11. Le module MPM0 transmet les appels de fonctions à une librairie SLIB2 du système d’exploitation OS. La librairie SLIB2 est de même nature que la librairie SLIB1, par exemple une librairie Cryptoki. Parmi ces fonctions standards, sont généralement prévues une fonction d’effacement de la mémoire programme PMEM du module de sécurité matérielle et une fonction de mise à jour du microprogramme présent dans la mémoire programme. Ainsi, le module de sécurité matérielle constitue une sorte d’extension matérielle du dispositif hôte HDV, offrant des sécurités matérielles et logicielles contre des attaques, permettant de stocker des données sensibles en toute sécurité et de réaliser des calculs cryptographiques à travers une librairie de fonctions standards. Selon un aspect de la présente divulgation, on modifie le traitement des fonctions d’effacement et de mise à jour du module de sécurité matérielle HSMo en implantant dans le fonctionnement de la machine un module de protection PM qui filtre ces deux types de commandes, susceptibles d’être utilisées par une personne malintentionnée. Divers fabricants de modules de sécurité matérielle prévoient des commandes permettant de modifier le fonctionnement des modules de sécurité matérielle en y injectant un microprogramme utilisateur (« custom firmware ») pouvant modifier le dispatching des messages reçus ou mettre en œuvre des commandes propriétaires. En relation avec l’architecture logicielle qui vient d’être décrite, la possibilité est donc souvent offerte d’ajouter des fonctions personnalisées à la bibliothèque SLIB2 ou de modifier l’exécution de fonctions standards. Ceci est par exemple possible au moyen de la commande Cprov avec certains modules de sécurité matérielle. Notamment, dans certains modules de sécurité matérielle, la fonction « OS_GetCprovFuncTable » permet d'obtenir l'adresse de la structure d’une table de fonctions Cprov utilisée par un composant Cprov Filter du microprogramme. La modification des adresses des fonctions dans la table permet d'appeler des fonctions personnalisées lorsque la fonction Cprov est demandée du côté de l'hôte. La FIG. 3 est un organigramme simplifié décrivant des étapes d’un procédé d’implantation du module de protection PM dans le module de sécurité matérielle HSMo. Un mode de réalisation de ce procédé sera décrit plus en détail en relation avec les figures 10A, 10B. A une étape I01, le dispositif hôte envoie au module de sécurité matérielle HSMo un appel à la fonction « Installation d’un microprogramme » et lui fournit un microprogramme correctif FW1. La commande est reçue par le module de traitement de messages MPM0 et est répercutée au système d’exploitation OS. A une étape I02, le système d’exploitation vérifie que les conditions d’exécution classiques de la fonction d’installation sont réunies. A une étape I03, le système d’exploitation installe puis exécute le microprogramme correctif FW1. A une étape I04, le microprogramme FW1 est exécuté et met en service le module de protection PM, qui fait partie intégrante du microprogramme. A une étape I05, le microprogramme FW1 corrige ensuite la table d’attribution des fonctions du module de gestion de messages MPM0 afin que celui-ci, sur réception d’appels aux fonctions standards « effacement » ou « mise à jour », les répercute au module de protection PM au lieu de les adresser directement à la librairie SLIB2 du système d’exploitation. Le module de gestion de messages MPM0 dans sa version modifiée sera désormais désigné MPM1. Ainsi, les fonctions standards SF « installation de programme » et « effacement de programme » deviennent des fonctions modifiées PF (« Patched Functions ») qui sont traitées par le module de protection PM de la manière suivante : - Effacement : interdit ; - Installation : uniquement si des conditions de recevabilité sont satisfaites (conditions gérées par le module de protection PM). La FIG. 4 montre l’architecture logicielle d’un module de sécurité matérielle HSMp ayant été modifié comme cela vient d’être décrit. Le module de sécurité matérielle est comme précédemment relié au dispositif hôte HDV, dont la structure et le fonctionnement sont inchangés. Le dispositif hôte HDV adresse au module de sécurité matérielle HSMp des commandes d’exécution de fonctions standards SF, ou « appels de fonctions » (« function calls »). Contrairement au module de traitement de messages MPM0, le module MPM1 n’adresse pas systématiquement à la librairie SLIB2 du système d’exploitation OS tous les appels de fonctions reçus. Sa table d’attribution des fonctions ayant été modifiée, les appels à la fonction « effacement » et à la fonction « mise à jour » sont envoyés au module de protection PM. Les appels à la fonction « effacement » sont rejetés par le module de protection PM tandis que les appels à la fonction « mise à jour » font l’objet d’un traitement pour déterminer si les conditions de recevabilité sont satisfaites. Si ces conditions sont satisfaites, la demande de mise à jour est transférée à la librairie standard SLIB2 pour être exécutée par le système d’exploitation, le chargement de la mise à jour impliquant l’écrasement de la version actuelle du microprogramme dans la mémoire programme PMEM. La FIG. 5 est un organigramme qui illustre le traitement des appels de fonction par le module de sécurité matérielle HSMp. A une étape E01, le module de gestion de messages MPM1 reçoit un appel à une fonction. A une étape E02, le module MPM1 détermine si la commande reçue se rapporte à une fonction modifiée PF, à savoir l’effacement ou la mise à jour du microprogramme (cette étape peut être implicite et simplement résulter de la modification de la table d’attribution des fonctions). Si la réponse est négative, il s’agit d’une fonction standard et le module MPM1 transmet la commande à la librairie SLIB2 à une étape E03. Si la réponse est positive, à une étape E04 le module MPM1 transmet la commande au module de protection PM. A une étape E05, le module de protection PM détermine si la commande reçue est une demande d’effacement de la mémoire programme PMEM. Si la réponse est positive, le module de protection PM envoie une réponse de refus au module de traitement des messages MPM1. Si la réponse est négative, ce qui signifie ici que la commande reçue est une demande de mise à jour du microprogramme, le module de protection PM détermine à une étape E06 si les conditions de recevabilité de la commande sont remplies. Si la réponse est négative, le module de protection PM envoie une réponse de refus au module de traitement des messages MPM1. Si la réponse est positive, le module de protection PM transmet la commande à la librairie SLIB2 à une étape E07. A une étape E08, la librairie SLIB2 vérifie si les conditions d’exécution de la fonction modifiée PF ou standard SF sont satisfaites. Si la réponse est négative, la librairie SLIB2 envoie un message de refus au module de traitement de message MPM1. Si la réponse est positive, le système d’exploitation exécute la fonction à une étape E09. On a décrit dans ce qui précède un procédé permettant de modifier le traitement des appels aux fonctions pour rejeter une demande d’effacement et appliquer des conditions de recevabilité à une demande de mise à jour d’un microprogramme. Un autre aspect de la présente divulgation concerne un procédé d’authentification d’une mise à jour d’un microprogramme, mis en œuvre par le module de protection PM. Le résultat de l’authentification de la mise à jour est utilisé par le module PM comme condition de recevabilité d’une demande de mise à jour. En d’autres termes, le module de sécurité matérielle n’acceptera de procéder à une mise à jour que si cette mise à jour est estimée authentique selon les règles et étapes définies par ce procédé. Dans certains modes de réalisation, un tel procédé d’authentification utilise une clé secrète symétrique qui est fournie au module de sécurité matérielle HSMp lors de la première installation du microprogramme correctif FW1. Cette clé est présente uniquement dans la première version installée du microprogramme et est sauvegardée par celle-ci dans une mémoire sécurisée du module de sécurité matérielle HSMp, qui ne sera pas effacée lors de prochaines mises à jour. Ensuite, chaque version suivante du microprogramme est fournie avec une signature de celle-ci qui est générée au moyen de cette clé secrète. Le module PM vérifie que cette signature est valide avant d’accepter l’installation de la mise à jour. Dans d’autres modes de réalisation, le procédé d’authentification utilise une clé publique fournie dans le premier microprogramme correctif, pour vérifier l’authenticité de la signature insérée dans chaque mise à jour ultérieure. Cette clé publique correspond à une clé privée qui n’est jamais révélée. Dans un mode de réalisation avantageux, il est prévu un procédé d’authentification itératif, qui repose sur l’établissement d’un chaînage de signatures entre chaque version du microprogramme et la version suivante, afin qu’à partir d’une version initiale dont l’authenticité est assurée ou admise, le chaînage des signatures des versions ultérieures certifie que toutes ces versions sont authentiques. Selon ce procédé : - on désigne une source unique de génération de paires de clés d’authentification, chaque paire de clés comprenant une clé publique d’authentification et une clé privée d’authentification. Dans les exemples qui suivent, cette source unique est par exemple un collège d’approbateurs APRV qui peut comprendre une ou plusieurs personnes. Dans un mode de réalisation, ce collège d’approbateurs génère les paires de clés au moyen d’un module de sécurité matérielle qui lui est propre, cité plus loin en relation avec les figures 8, 9A, 9B avec la référence HSM1a. - pour l’installation de la première version du microprogramme, le collège d’approbateurs émet une première paire de clés d’authentification comprenant une première clé publique d’authentification PK 1 et une première clé privée d’authentification pK 1 . - la première version installée du microprogramme comprend la première clé publique PK 1 . Optionnellement, elle peut également comprendre une signature SIGN 1 générée au moyen de la clé privée pK1 et à partir d’un bloc de données incluant la première clé publique PK1. - le collège d’approbateurs émet une deuxième paire de clés d’authentification comprenant une deuxième clé publique d’authentification PK 2 et une deuxième clé privée d’authentification pK 2 , - une deuxième version du microprogramme, conçue comme une mise à jour de la première version comporte la clé publique PK 2 et une signature SIGN 2 générée au moyen de la clé privée pK 1 et à partir d’un bloc de données incluant au moins la clé publique PK 2 , - l’authenticité de la deuxième version du microprogramme est vérifiée par la première version du microprogramme et plus particulièrement, dans l’application considérée ici, par le module de protection PM, - la vérification de l’authenticité de la deuxième version du microprogramme par la première version du microprogramme comprend une étape de vérification de la signature SIGN 2 au moyen de la clé publique PK 1 et à partir du bloc de données de la deuxième version du microprogramme à partir duquel la signature SIGN 2 a été générée. On procède de la même manière pour chaque version suivante du microprogramme, comme illustré sur les figures 6A et 6B. La FIG. 6 illustre une étape de formation d’une version de rang N du microprogramme. Le microprogramme comporte initialement un code exécutable formant un bloc de données DB1 N . Une paire de clés d’authentification de rang N-1 comprenant une clé publique d’authentification PK N-1 et une clé privée d’authentification pK N-1 a été préalablement générée par le collège d’approbateurs et associée à une version précédente de rang N-1 du microprogramme, non représentée. Une paire de clés d’authentification de rang N comprenant une clé publique d’authentification PK N et une clé privée d’authentification pK N est maintenant générée par le collège d’approbateurs et est associée au bloc de données DB1 N . La clé publique PK N est concaténée avec le bloc de données DB1 N pour former un bloc de données DB2 N . Le bloc de données DB2 N est appliqué à une fonction de hachage FH2 qui fournit un condensé H2 N . Le condensé H2 N et la clé privée pK N-1 sont appliqués à une fonction de signature FS2 qui fournit une signature SIGN N telle que : SIGN N = FS2 [pKN-1] (H2 N ) = FS2 [pKN-1] (FH2(DB1 N ||PK N )) « || » représentant l’opération de concaténation. La signature SIGN N est ensuite concaténée au bloc de données DB2 N pour obtenir un bloc de données DB3 N qui forme ici la version finale du microprogramme, dont l’authenticité pourra être vérifiée au moyen de la clé publique PK N-1 présente dans la version précédente du microprogramme. La FIG. 6 illustre une étape de formation d’une version de rang N+1 du microprogramme. Le microprogramme comporte initialement un code exécutable formant un bloc de données DB1 N+1 . Une paire de clés d’authentification de rang N+1 comprenant une clé publique d’authentification PK N+1 et une clé privée d’authentification pK N+1 est générée par le collège d’approbateurs et est associée au bloc de données DB1 N+1 . La clé publique PK N+1 est concaténée avec le bloc de données DB1 N+1 pour former un bloc de données DB2 N+1 . Le bloc de données DB2 N+1 est appliqué à la fonction de hachage FH2 qui fournit un condensé H2 N+1 . Le condensé H2 N+1 et la clé privée pK N sont appliqués à la fonction de signature FS2 qui fournit une signature SIGN N+1 , telle que : SIGN N+1 = FS2 [pKN] (H2 N+1 ) = FS2 [pKN] (FH2(DB1 N+1 ||PK N+1 )) La signature SIGN N+1 est ensuite concaténée au bloc de données DB2 N+1 pour obtenir un bloc de données DB3 N+1 qui forme ici la version finale du microprogramme, dont l’authenticité pourra être vérifiée au moyen de la clé publique PK N présente dans la version de rang N installée dans le module de sécurité matérielle. Il sera noté qu’à chaque nouvelle itération du procédé, la « nouvelle paire de clés » peut être identique à la paire de clés précédente, le procédé pouvant aussi être mis en œuvre en conservant la même paire de clés pour toutes les versions du microprogramme. En pratique, le collège d’approbateurs peut décider de conserver la même paire de clés d’une version à une autre du microprogramme, ou décider de générer une nouvelle paire de clés de temps en temps. Vue sous l’angle de ce procédé, une clé d’authentification de rang N est toutefois une « nouvelle clé » relativement à la clé de rang N-1, même s’il s’agit de la même clé puisque la signature d’authentification du microprogramme de rang N est faite avec la clé privée d’authentification de rang N-1 et la vérification de cette signature faite au moyen de la clé publique d’authentification de rang N-1. La FIG. 7 montre des étapes de vérification de l’authenticité des blocs de données DB3 N et DB3 N+1 . La signature SIGN N du bloc DB3 N est vérifiée au moyen d’une fonction de vérification de signature VRFY qui reçoit en entrée : - la signature à vérifier SIGN N , présente dans le bloc DB3 N , - le bloc de données DB2 N à partir duquel la signature SIGN N a été générée, présent dans le bloc DB3 N , ce bloc de données comprenant ici le bloc de données DB1 N (le code exécutable) et la clé publique PK N , - la clé publique PK N-1 présente dans le bloc DB3 N-1 , correspondant à la clé privée pK N-1 au moyen de laquelle la signature SIGN N a été générée De la même manière, la signature SIGN N+1 du bloc DB3 N+1 est vérifiée au moyen de la fonction VRFY qui reçoit en entrée : - la signature à vérifier SIGN N+1 , présente dans le bloc DB3 N+1 , - le bloc de données DB2 N+1 à partir duquel la signature SIGN N+1 a été générée, présent dans le bloc DB3 N+1 , ce bloc de données comprenant ici le bloc de données DB1 N+1 et la clé publique PK N+1 , et - la clé publique PK N présente dans le bloc DB3 N , correspondant à la clé privée pK N au moyen de laquelle la signature SIGN N a été générée. Pour chaque vérification, la fonction de vérification VRFY fournit un résultat « VALID » ou « INVALID » en fonction des données d’entrée qui lui sont fournies. Ainsi, chaque signature SIGN d’un bloc de données de rang déterminée peut être vérifiée au moyen de la clé publique présente dans le bloc de données de rang précédent et des données présentes dans le bloc de données considéré. La validité de cette signature implique la validité de la clé publique présente dans le bloc de données qu’elle signe. Ainsi, chaque bloc de données DB3 est authentifié relativement au bloc de données précédent, et chaque authentification d’un bloc de données DB3 implique la validation de la clé publique PK qu’il comporte, qui permettra ensuite de valider le bloc de données suivant. La fonction de vérification VRFY est en soi classique et dépend du type de signature utilisée. Diverses fonctions de signature et de vérification de signatures sont à la disposition des concepteurs. Si la signature SIGN est une signature RSA, la fonction de vérification utilise la clé publique d’authentification pour retrouver le condensé d’origine H2 à partir de la signature SIGN, puis calcule un condensé H2’ du bloc de données DB2 avec le même algorithme de hachage, et enfin compare les condensés H2 et H2’. Si la signature SIGN est une signature ECDSA (« Elliptic Curve Digital Signature Algorithm »), ce même algorithme est utilisable pour la vérification des signatures au moyen de la clé publique d’authentification et des données ayant été signées avec la clé privée d’authentification. Par exemple, l'ECDSA mis en œuvre avec la courbe elliptique P-256 vérifie les signatures électroniques à l'aide de cette courbe elliptique, normalisée par le NIST (« National Institute of Standards and Technology »), cf. FIPS Publication 186-3. La FIG. 8 illustre une variante de l’étape de formation d’un micrologiciel de rang N+1 qui a été décrite en relation avec les figures 6A, 6B. Dans ce mode de réalisation, d’autres métadonnées sont ajoutées au bloc de données initial DB1 mais le principe d’authentification de chaque nouvelle version relativement à la version précédente reste le même. Une version FW N+1 de rang N+1 du microprogramme est tout d’abord conçue, sous forme de code source. Cette version comporte un programme applicatif AFW N+1 (« Application Firmware ») et un programme modificatif PFW N+1 (« Patch Firmware »). Le programme applicatif vise à réaliser des opérations prévues dans le cadre d’une application déterminée. Un exemple d’une telle application sera décrit plus loin en relation avec la FIG. 13 . Le programme modificatif PFW N+1 vise à implanter le module de protection PM précédemment décrit dans le fonctionnement de la machine, tout en transformant le module de traitement de message MPM0 ( FIG. 2 ) en module de traitement des messages MPM1 ( FIG. 4 ) configuré pour répercuter au module de protection PM des appels à la fonction d’effacement ou à la fonction de mise à jour. La version FW N+1 du microprogramme est tout d’abord envoyée à un serveur d’intégration BSRV1 qui compile le microprogramme pour fournir un code objet ou code exécutable formant le bloc de données DB1 N+1 . Le serveur d’intégration ajoute ensuite au bloc de données DB1 N+1 , par concaténation, les métadonnées suivantes : - un premier marqueur MK1, - un numéro de version VN. Ce numéro de version peut consister dans toute information autre qu’un simple numéro permettant d’identifier de manière certaine la version concernée, par exemple une date de conception, un numéro de série, etc. - un deuxième marqueur MK2, - la clé publique d’authentification PK N+1 associée à cette version du microprogramme, et - un troisième marqueur MK3. Le bloc de données DB1 N+1 concaténé avec ces différentes métadonnées forme le bloc de données DB2 N+1 , qui se distingue de celui précédemment décrit avec la même référence en ce qu’il comporte un plus grand nombre de métadonnées. Ensuite, et comme précédemment décrit, le bloc de données DB2 N+1 est appliqué à la fonction de hachage FH2 qui fournit le condensé H2 N+1 . Le condensé H2 N+1 et la clé privée d’authentification pK N sont appliqués à la fonction FS2 qui fournit la signature SIGN N+1 . Cette étape de génération de la signature SIGN N+1 peut, dans un mode de réalisation, être réalisée par un module de sécurité matérielle HSM1a du collège d’approbateurs APRV. La signature SIGN N+1 est ensuite concaténée au bloc de données DB2 N+1 pour obtenir le bloc de données DB3 N+1 qui formait précédemment la version finale du microprogramme. Ici, le bloc de données DB3 N+1 subit une étape de traitement supplémentaire avant d’obtenir la version finale du microprogramme. Au cours de cette étape, le bloc de données DB3 N+1 est signé au moyen d’une fonction FS1. Cette signature est classiquement générée par un module de sécurité matérielle signataire HSM1b, qui génère une clé publique d’installation IPK N+1 et une clé privée d’installation IpK N+1 puis procède avec le bloc de données DB3 N+1 de la même manière que le module de sécurité matérielle HSMa de la FIG. 1 procède avec le bloc de données DB1. Ainsi, le bloc de données DB3 N+1 est appliqué à une fonction de hachage FH1 qui fournit un condensé H1 N+1 . Le condensé H1 N+1 ainsi que la clé privée d’installation IpK N+1 sont appliqués à la fonction FS1 qui fournit une signature ISIGN N+1 . La signature ISIGN N+1 est ensuite concaténée par le module de sécurité matérielle signataire HSM1b avec le bloc de données DB3 N+1 , en étant précédée d’un champ SIZE(ISIGN) indiquant la taille de cette signature, suivie d’un champ OID(FS1) (« Object Identifier ») donnant une information sur la fonction de signature FS1 utilisée, lui-même précédé d’un champ SIZE(OID) indiquant la taille de cet identifiant. Un champ SIZE(DB3) peut aussi être ajouté avant le bloc de données DB3 N+1 pour indiquer la taille de celui-ci. L’ensemble forme un bloc de données DB4 N+1 qui constitue ici la version finale du microprogramme. Afin de permettre l’installation de cette version DB4 N+1 du microprogramme, la clé publique d’installation IPK N+1 est fournie à l’administrateur du module de sécurité matérielle HSMp, qui l’enregistre dans un compte d'administrateur du module de sécurité matérielle. Le module de sécurité matérielle HSMp vérifie ensuite la validité de la signature d’installation ISIGN N+1 au moyen de la clé publique d’installation IPK N+1 . Si la signature est valide, le système d’exploitation du module de sécurité matérielle HSMp accepte de charger le microprogramme dans sa mémoire programme PMEM. Toutefois, ici, le module de protection PM intervient avant la vérification de la validité de la signature d’installation ISIGN N+1 par le système d’exploitation, pour vérifier la signature d’authentification SIGN N+1 . La FIG. 8 montre la structure de trois microprogrammes successifs de rangs respectifs N, N+1, N+2 réalisés selon le procédé de la FIG. 8 . Le microprogramme de rang N comprend, dans l’ordre représenté, le champ SIZE(DB3 N ), le code exécutable formant le bloc DB1 N , le marqueur MK1, le numéro de version VN( N ), le marqueur MK2, la clé publique d’authentification PK N , le marqueur MK3, la signature d’authentification SIGN N , le champ SIZE(ISIGN), la signature d’installation ISIGN N , le champ SIZE(OID) et l’identifiant OID(FS1). De façon similaire, le microprogramme de rang N+1 comprend le champ SIZE(DB3 N+1 ), le code exécutable formant le bloc DB1 N+1 , le marqueur MK1, le numéro de version VN( N+1 ), le marqueur MK2, la clé publique d’authentification PK N+1 , le marqueur MK3, la signature d’authentification SIGN N+1 , le champ SIZE(ISIGN), la signature d’installation ISIGN N+1 , le champ SIZE(OID) et l’identifiant OID(FS1). De même, le microprogramme de rang N+2 comprend le champ SIZE(DB3 N+2 ), le code exécutable formant le bloc DB1 N+2 , le marqueur MK1, le numéro de version VN( N+2 ), le marqueur MK2, la clé publique d’authentification PK N+2 , le marqueur MK3, la signature d’authentification SIGN N+2 , le champ SIZE(ISIGN), la signature d’installation ISIGN N+2 , le champ SIZE(OID) et l’identifiant OID(FS1). La FIG. 8 montre également les différentes paires de clés d’authentification générées par le collège d’approbateurs APRV : - la clé privée d’authentification pK N-1 ayant permis de générer la signature d’authentification SIGN N , et la clé publique correspondante PK N-1 . Cette dernière est insérée dans un bloc DB3 N- 1 d’une version précédente du microprogramme, non représentée sur la figure, - la clé privée d’authentification pK N ayant permis de générer la signature d’authentification SIGN N+1 , et la clé publique correspondante PK N qui est insérée dans le bloc de données DB3 N , - la clé privée d’authentification pK N+1 ayant permis de générer la signature d’authentification SIGN N+2 , et la clé publique correspondante PK N+1 qui est insérée dans le bloc de données DB3 N+1 , et - la clé privée d’authentification pK N+2 qui permettra de générer la signature d’authentification d’une version suivante du microprogramme, et la clé publique correspondante PK N+2 , qui est insérée dans le bloc de données DB3 N+2 . et La FIG. 8 montre également : - les blocs DB2 N , DB2 N+1 , DB2 N+2 à partir desquels les signatures d’authentification SIGN N , SIGN N+1 , SIGN N+2 sont générées, - la clé privée d’installation IpK N ayant permis de générer la signature d’installation ISIGN N , et la clé publique correspondante IPK N , - la clé privée d’installation IpK N+1 ayant permis de générer la signature d’installation ISIGN N+1 , et la clé publique correspondante IPK N+1 , ainsi que - la clé privée d’installation IpK N+2 ayant permis de générer la signature d’installation ISIGN N+2 , et la clé publique correspondante IPK N+1 . En résumé, chaque microprogramme suivant est lié au microprogramme précédent par un lien d’authentification qui réside dans la clé privée d’authentification correspondant à la clé publique d’authentification insérée dans le microprogramme précédent. Cette clé privée est utilisée pour générer la signature d’authentification insérée dans le microprogramme suivant, tandis que la clé publique d’authentification insérée dans le microprogramme précédent permet de vérifier cette signature. Par ailleurs, l’inviolabilité de la chaîne de signatures est obtenue par le fait que la clé publique d’authentification qui est insérée dans le microprogramme précédent, forme la donnée d’entrée de la signature d’authentification insérée dans le microprogramme précédent, elle-même générée au moyen de la clé privée associée au microprogramme qui précède le microprogramme précédent. Le fait d’ajouter à cette donnée d’entrée d’autres données du microprogramme telles que le numéro de version VN et le code exécutable DB1, permet en outre de vérifier que ces données n’ont pas été altérées, ce qui est en soi la fonction classique d’une signature. Ainsi, la signature d’authentification remplit ici une double fonction, d’une part de permettre de vérifier la validité des données présentes dans le microprogramme, et d’autre part de rendre inviolable le processus d’authentification itératif. Comme évoqué plus haut, selon un aspect de la présente divulgation, le procédé d’authentification itératif qui vient d’être décrit est mis en œuvre par le module de protection PM qui est incorporé dans le microprogramme du module de sécurité matérielle. La FIG. 9 est un diagramme de séquence décrivant un mode de réalisation du procédé de fabrication de microprogramme de la FIG. 8 . La FIG. 9 décrit les étapes de la FIG. 9 . Le rang du microprogramme concerné, ainsi que le rang des clés publiques et privées, ne figurent pas sur les figures 9A, 9B. On considérera dans ce qui suit qu’il s’agit du rang N, sauf information contraire. La FIG. 9 montre quatre entités : le serveur d’intégration BSRV1, le module de sécurité matérielle HSM1a du collège d’approbateurs APRV, le module de sécurité matérielle signataire HSM1b et le microprogramme FW en cours de fabrication. A une étape S01, le module de sécurité matérielle HSM1a génère une clé privée d’authentification pK et une clé publique d’authentification PK et communique la clé publique PK au serveur BSRV1. A une étape S03, le serveur BSRV1 compile un code source et génère le code binaire compilé du microprogramme formant le bloc de données DB1. A une étape S05, le serveur BSRV1 ajoute un numéro de version VN au bloc de données DB1. Cette étape peut inclure l’insertion d’un premier marqueur MK1 avant le numéro de version. A une étape S07, le serveur BSRV1 ajoute la clé publique d’authentification PK au bloc de données DB1, pour obtenir le bloc de données DB2. Cette étape peut inclure l’insertion d’un deuxième marqueur MK2 avant la clé publique. A une étape S09, le module de sécurité matérielle HSM1a audite le code binaire pour vérifier que sa structure est correcte. A une étape S11, le module de sécurité matérielle HSM1a vérifie que le numéro de version VN ajouté au microprogramme est correct. A une étape S13, le module de sécurité matérielle HSM1a vérifie que la clé publique d’authentification PK ajoutée au microprogramme est correcte. A une étape S15, le module de sécurité matérielle HSM1a calcule le condensé H2 du bloc DB2 au moyen de la fonction de hachage FH2, soit H2 = FH2(DB2). Dans un mode de réalisation, la fonction FH2 est la fonction SHA256. A une étape S17, le module de sécurité matérielle HSM1a calcule la signature SIGN du condensé avec la fonction de signature FS2 et la clé privée de l’itération précédente de rang N-1, soit, en supposant que la version en cours de réalisation est une version de rang N : SIGN = FS2 [pKN-1] (H2). Dans un mode de réalisation, la fonction de signature FS2 est la fonction ECDSA-secp256k1. A une étape S19, le module de sécurité matérielle HSM1a compile la signature SIGN avec DB2 pour obtenir le bloc de données DB3. A une étape S21, le bloc de données DB3 est fourni au module de sécurité matérielle signataire HSM1b. A une étape S23, le module de sécurité matérielle HSM1b calcule le condensé H1 avec la fonction de hachage FH1, soit FH1(DB3). Dans un mode de réalisation, la fonction de hachage FH1 est la fonction SHA512. A une étape S24, le module de sécurité matérielle HSM1b génère une clé privée d’installation IpK et une clé publique d’installation IPK, calcule la signature d’installation ISIGN au moyen de la fonction de signature FS1 et de la clé privée d’installation IpK, soit ISIGN = FS1 [IpK] (H1). Dans un mode de réalisation, la fonction de signature FS1 est la fonction RSA2048_pkcs. A une étape S25, le module de sécurité matérielle HSM1b ajoute au bloc de données DB3 l’identifiant OID de la fonction FS1 et la signature ISIGN, pour obtenir le bloc de données DB4. La FIG. 10 est un diagramme de séquence décrivant un mode de réalisation détaillé d’une étape d’installation dans le module de sécurité matérielle HSMp, d’une première version FW1 du microprogramme selon la présente divulgation. La FIG. 10 est un organigramme décrivant les étapes de la FIG. 10 . Il s’agit ici d’une première installation qui fait l’objet de diverses précautions en matière de sécurité informatique et est notamment accompagnée de l’intervention d’un observateur pour superviser sa mise en œuvre, vérifier que le module de sécurité matérielle dans laquelle elle est faite est vierge de tout microprogramme et que le microprogramme installé est authentique. Une fois installé, le microprogramme implante le module de protection PM au cœur du fonctionnement du module de sécurité matérielle HSMp. Ce dernier est alors autoprotégé contre l’effacement ou l’installation de versions ultérieures qui ne seraient pas authentiques, et il n’est notamment plus nécessaire de faire intervenir un observateur. Les installations des versions suivantes sont ensuite considérablement simplifiées, et peuvent même être réalisées à distance. Le procédé fait intervenir ici quatre entités : - une partie PART1, par exemple une société ayant développé le microprogramme comme cela a été décrit en relation avec les figures 9A, 9B, - un observateur OBS, par exemple une personne membre de la partie PART1, - une partie PART2 qui va exploiter le microprogramme sur un module de sécurité matérielle HSMp qui lui appartient, - le module de traitement des messages MPM0 du module de sécurité matérielle HSMp dans son état initial en sortie d’usine (celui-ci deviendra le module de traitement de messages MPM1 à un certain stade du processus l’installation), et - le système d’exploitation OS du module de sécurité matérielle HSMp. A une étape S27, la partie PART1 communique à la partie PART2 la clé publique d’installation IPK. A une étape S28, la partie PART2 communique la clé d’installation IPK au module de sécurité matérielle HSMp. Le système d’exploitation OS du module de sécurité matérielle HSMp enregistre la clé dans un registre AREG accessible uniquement à un administrateur. A une étape S30, l’observateur OBS audite le module de sécurité matérielle HSMp et s’assure que celui-ci est vierge de tout programme et qu’il est dans l’état d’usine (état dans lequel il est livré par le fabricant). A une étape S32, l’observateur OBS audite le processus d’approvisionnement du microprogramme par la partie PART2. A une étape S34, la partie PART1 envoie à la partie PART2 le microprogramme FW1. Dans un mode de réalisation, la partie PART1 communique également à la partie PART2 le code source du microprogramme, ainsi que la clé publique d’authentification PK et le numéro de version. Par contre, la clé privée d’authentification pK ne lui est pas communiquée. Avec ces données, la partie PART2 peut auditer le code source et vérifier en le compilant qu’il correspond bien au code exécutable qu’elle va installer sur son module de sécurité matérielle. Elle peut aussi vérifier la signature d’authentification SIGN avec la clé publique d’authentification PK. A une étape S36, la partie PART2 audite le microprogramme FW1 de la manière qui vient d’être indiquée. A une étape S38, la partie PART2 envoie au module de traitement de messages MPM0 une commande d’installation du microprogramme FW1. A ce stade, le module de traitement de messages MPM0 est dans son état de sortie d’usine et transmet directement l’appel de fonction au système d’exploitation. A une étape S40, le module de traitement des messages MPM0 demande au système d’exploitation d’installer le microprogramme FW1. A une étape S42, le système d’exploitation OS installe le microprogramme FW1 avec le mécanisme classique d’installation, qui consiste à vérifier que la signature d’installation ISIGN est correcte en utilisant à cet effet la clé publique IPK dont il dispose dans le registre AREG. A une étape S44, le système d’exploitation OS exécute le microprogramme FW1 et installe le module de protection PM. A une étape S46, le module de protection PM modifie la table d’attribution des fonctions du module de traitement des messages MPM0 pour verrouiller les points d’entrée du HSM : le module de traitement de messages MPM0 devient le module de traitement de messages MPM1, conçu pour rejeter les demandes d’effacement et vérifier, avant d’exécuter une demande de mise à jour, que le microprogramme de mise à jour est authentique. A une étape S48, le module de protection PM génère une paire de clés d’attestation aléatoires AKEYP comprenant une clé privée d’attestation ApK et une clé publique d’attestation APK. La paire de clés est par exemple générée sur la courbe ECDSA P-256. Cette paire de clés d'attestation est sauvegardée dans une mémoire sécurisée du module de sécurité matérielle HSMp, qui ne sera pas effacée lors de prochaines mises à jour. A une étape S50, le module de protection PM communique la clé publique d’attestation APK au module de traitement de messages MPM1. A une étape S52, le module de traitement des messages MPM1 communique la clé APK à la partie PART2. A une étape S54, la partie PART2 communique la clé APK à l’observateur OBS. A une étape S56, l’observateur OBS calcule une signature OSIGN de la clé APK avec une fonction de signature FS3 et en utilisant une clé privée OpK qui lui est propre, soit : OSIGN = FS3 [OpK] (APK). La fonction FS3 est par exemple l’algorithme ECDSA. A une étape S58, l’observateur OBS communique à la partie PART1 la clé d’attestation APK et sa signature OSIGN. A une étape S60, la partie PART1 utilise la clé publique OPK de l’observateur pour vérifier l’authenticité de la signature APK, en vérifiant la signature OSIGN au moyen de la clé publique OPK. A compter de cette étape, l’établissement d’un lien de confiance est possible en utilisant la clé publique d’attestation APK de la paire AKEYP. Par exemple, dans un mode de réalisation, la partie PART1 intègre le module de sécurité matérielle HSMp dans une infrastructure à clé publique PKI (« Public Key Infrastructure ») qui lui est propre. A cet effet la partie PART1 communique la clé publique d’attestation APK à l’autorité de certification CA de cette infrastructure. L’autorité de certification CA renvoie une signature SIGNCA(APK) de la clé publique APK générée avec sa propre clé privée, formant avec la clé publique APK un certificat {APK, SIGNCA(APK)}. A une étape S62, la partie PART1 renvoie le certificat au module de protection PM du module de sécurité matérielle HSMp, via le module de traitement de messages MPM1. La signature SIGNCA(APK) est sauvegardée par celui-ci dans la mémoire sécurisée dans laquelle sont déjà stockées la clé privée d’attestation ApK et la clé publique d’attestation APK. Aucune interface API n’est prévue, qui permettrait de modifier cette partie de la mémoire du module de sécurité matérielle, seul le microprogramme modifié conformément à la présente divulgation pouvant le faire. En résumé, l’installation de la première version du microprogramme diffère des installations de mise à jour suivantes par le fait : - qu’il n’est pas nécessaire de prévoir la signature d’authentification SIGN dans le premier microprogramme, puisqu’il n’y a pas de version précédente, l’authentification de la première version étant assurée par des mesures appropriées dont certaines viennent d’être décrites : audit du code binaire, présence d’un observateur, utilisation de la clé publique d’installation IPK et vérification de la signature d’installation ISIGN, etc. Cela n’exclut pas, toutefois, que dans un mode de réalisation cette signature soit prévue et vérifiée. - que la première version génère la clé d’attestation AKEYP permettant de créer le lien de confiance susmentionné avec la partie PART1. Une fois la première installation terminée, le module de sécurité matérielle peut être ajouté à l’infrastructure PKI de la partie PART1, ce qui lui permettra de l’utiliser en toute sécurité même si celui-ci se trouve dans un datacenter géré par la partie PART2. Les figures 11A, 12A sont des diagrammes de séquence décrivant un mode de réalisation détaillé d’une étape de mise à jour, dans le module de sécurité matérielle HSMp, de la première version du microprogramme. Les figures 11B, 12B sont des organigrammes décrivant les étapes des figures 11A, 12A. Dans un souci de simplicité, le rang du microprogramme concerné, des clés publiques et privées, ne figure pas sur ces figures. On considérera qu’il s’agit par exemple du rang N, sauf information contraire. Le procédé fait intervenir ici quatre entités : - la partie PART2, qui contrôle le module de sécurité matérielle HSMp. - le module de traitement des messages MPM1 dans sa version modifiée à l’étape S46 de la première installation du microprogramme précédemment décrite, - le module de protection PM du module de sécurité matérielle HSMp installé au cours de l’étape S44 de la première installation du microprogramme, et - le système d’exploitation OS du module de sécurité matérielle HSMp (considéré ici comme incluant la librairie SLIB2 de la FIG. 4 ). Le microprogramme à installer se présente sous la forme du bloc de données DB4 dont la structure a été précédemment décrite en relation avec les figures 8A, 8B et 9A, 9B. Dans cet exemple de réalisation, la fonction de mise à jour du microprogramme qui est modifiée pour être traitée par le module de protection PM se décompose en trois appels de fonction PKCS#11 : - C_VerifyInit, - C_VerifyUpdate, - C_VerifyFinal. Par ailleurs, pour transformer le module de traitement de messages MPM0 en module MPM1, la commande « CprovFnTable » est utilisée. Cette commande permet de modifier une table d’attribution de fonctions afin de renvoyer au module de protection PM le traitement des appels aux trois fonctions précitées. L’exemple ci-après est une séquence de programme qui permet de renvoyer le traitement de ces trois fonctions vers le module de protection PM : FunctionTable *table = OS_GetFunctionTable(); table->C_VerifyInit = Custom_C_VerifyInit; table->C_VerifyUpdate = Custom_C_VerifyUpdate; table->C_VerifyFinal = Custom_C_VerifyFinal; table->C_SetAttributeValue = Custom_C_SetAttributeValue On distingue ainsi dans le procédé montré sur les figures 11A, 11B, 12A et 12B : - une phase de traitement de l’appel de fonction « VerifyInit(mechanism= FirmwareUpdate) », le champ « mechanism » inclus dans la commande signifiant que la fonction VerifyInit est ici appelée pour préparer une opération de mise à jour, - une phase de traitement de l’appel de fonction « VerifyUpdate(BUF) » ; cette étape sera répétée plusieurs fois jusqu’à ce que l’intégralité du bloc de données DB4 soit stockée dans un tampon mémoire BUF, et - une phase de traitement de l’appel de fonction « VerifyFinal(ISIGN) ». Dans l’art antérieur, ce traitement consiste seulement dans la vérification de la signature d’installation ISIGN par le système d’exploitation. Ce traitement va ici être précédé de la vérification de la signature d’authentification SIGN par le module de protection PM. On décrira maintenant ces trois phases d’installation de la mise à jour. Phase 1, traitement de l’appel de fonction « VerifyInit(mechanism= FirmwareUpdate) » A une étape S70, la partie la PART2 télécharge le bloc de données DB4. A une étape S72, la partie PART2 envoie au module de traitement de messages MPM1 la commande « VerifyInit(mechanism=FirmwareUpdate) ». A une étape S74, le module de traitement des messages MPM1 transfère la commande « VerifyInit(mechanism=FirmwareUpdate) » au module de protection PM. A une étape S76, le module de protection PM initialise une machine d’état dont il va avoir besoin pour l’analyse de la structure du bloc de données DB4. A une étape S78, le module de protection PM initialise la fonction de hachage FH2, par exemple la fonction SHA256. A une étape S80, le module de protection PM a terminé la phase d’initialisation et transmet la commande « VerifyInit(mechanism=FirmwareUpdate) » au système d’exploitation. Phase 2, traitement de l’appel de fonction « VerifyUpdate(BUF) ». Ce traitement peut inclure le traitement en boucle d’une pluralité de commandes « VerifyUpdate(BUF) » jusqu’à ce que l’intégralité du bloc de données DB4 soit stockée dans le tampon mémoire BUF. A une étape S82, la partie PART2 envoie au module de traitement de messages MPM1 la commande « VerifyUpdate(BUF) ». A une étape S84, le module de traitement des messages MPM1 transfère la commande « VerifyUpdate(BUF) » au module de protection PM, la commande étant accompagnée d’une portion du bloc de données DB4. A une étape S86, le module de protection PM analyse la portion du bloc de données DB4 et cherche à détecter les marqueurs MK1 (marqueur du numéro de version VN) et MK3 (marqueur de la signature d’authentification SIGN). Il sera noté qu’à ce stade, le module de protection n’a pas besoin de trouver le marqueur MK2 de la clé publique d’authentification PK N , car cette clé est de rang N et ne sera utilisée qu’après installation de la mise à jour, pour l’authentification d’une mise à jour suivante. A une étape S88, le module de protection PM analyse la portion du bloc de données DB4 qui est attachée à la commande et recherche la signature d’authentification SIGN. A une étape S90, le module de protection PM prépare les données DB2 à fournir à la fonction de hachage FH2 (sans inclure la signature d’authentification SIGN). A une étape S92, le module de protection PM stocke le numéro de version VN. A une étape S94, le module de protection PM ajoute le contenu du tampon BUF à la fonction de hachage FH2 A une étape S96, le module de protection PM a terminé l’étape préparatoire et transfère au système d’exploitation la commande VerifyUpdate(BUF) pour que le système d’exploitation exécute les étapes classiques de traitement de cette commande. Phase 3, traitement de l’appel de fonction « VerifyFinal(ISIGN) » ( FIG. 12 ). A une étape S98, la partie PART2 envoie au module de traitement de messages MPM1 la commande VerifyFinal(ISIGN). A une étape S100, le module de traitement des messages MPM1 transfère la commande au module de protection PM, Si le module de protection PM n’a pas pu identifier les marqueurs valides MK1 et MK3 au cours de la phase précédente, le module PM envoie au module de traitement de messages MPM1 un message « Format Invalide (défaut de marqueurs) » à une étape S102, et refuse de transférer la commande au système d’exploitation pour mise à jour du microprogramme. A une étape S104, si l’étape S102 est mise en œuvre, le module de traitement des messages MPM1 répercute le message « Format Invalide » à la partie PART2. Si un numéro de version VN invalide a été détecté au cours de la phase précédente, le module de protection PM renvoie au module de traitement de messages MPM1, à une étape S106, un message « Retour en arrière détecté », et refuse également de transférer la commande au système d’exploitation pour mise à jour du microprogramme. A une étape S108, si l’étape S106 est mise en œuvre, le module de traitement des messages MPM1 répercute à la partie PART2 un message « Retour en arrière détecté ». A une étape S110, le module de protection PM calcule le condensé H2' à partir du bloc de données DB2 (voir FIG. 8 ). La fonction de hachage FH2 est par exemple la fonction SHA256. Le module PM vérifie ensuite la signature d’authentification SIGN à partir de H2' et au moyen de la clé publique d’authentification PK de rang N-1 présente dans le code actuel du microprogramme (et non dans le code de la mise à jour qui vient d’être analysé), cette clé étant identifiable au moyen du marqueur MK2. A une étape S114, si la signature n’est pas valide, le module de protection PM envoie au module de traitement des messages MPM1 un message « Signature Invalide » et refuse de transférer la commande au système d’exploitation pour mise à jour du microprogramme. A une étape S116, si l’étape S114 a été mise en œuvre, le module de traitement des messages MPM1 répercute à la partie PART2 le message « Signature Invalide ». A une étape S118, si aucune des erreurs citées ci-dessus n’a été trouvée, le module PM transfère la commande « VerifyFinal(ISIGN) » au système d’exploitation pour mise à jour du microprogramme. Ce dernier exécute alors cette commande de manière classique, en vérifiant la signature d’installation ISIGN. Ainsi, à une étape S120, le système d’exploitation OS calcule le condensé H1 à partir du bloc de données DB3, soit H1' = FH1(DB3) (voir FIG. 8 ). La fonction de hachage FH1 est par exemple la fonction SHA512. Le système d’exploitation calcule ensuite le condensé H1 de la signature ISIGN au moyen de la clé publique d’installation IPK, puis vérifie que les deux condensés H1' et H1 sont égaux. A une étape S122, si les condensés ne sont pas égaux, ce qui signifie que la signature d’installation ISIGN est invalide, le système d’exploitation OS envoie au module de protection PM un message « Signature Invalide ». A une étape S124, le module de protection PM répercute au module de traitement des messages MPM1 le message « Signature Invalide ». A une étape S126, le module de traitement des messages MPM1 répercute à la partie PART2 le message « Signature Invalide » A une étape S128, si aucune erreur sur la signature ISIGN n’a été détectée, le système d’exploitation accepte la mise à jour du microprogramme et envoie au module de protection PM un message « microprogramme en cours de mise à jour ». A une étape S130, le système d’exploitation OS envoie ensuite au module de protection PM un message « succès de la mise à jour ». A une étape S132, le module de protection PM répercute au module de traitement des messages MPM1 le message « succès de la mise à jour ». A une étape S134, le module de traitement des messages MPM1 répercute à la partie PART2 le message « succès de la mise à jour ». La FIG. 13 montre un portefeuille de cryptoactifs CW1 et un système prévu pour mettre en œuvre un procédé de sauvegarde de la graine S (« seed ») de comptes de cryptoactifs détenus par le portefeuille CW1. Un tel procédé est par exemple proposé au public sous la dénomination commerciale « Recover ». Le portefeuille de cryptoactifs CW1 comprend un dispositif HW et un dispositif hôte HDV. Le dispositif HW est un portefeuille matériel ("hardware wallet") assurant le stockage à froid de la graine S, laquelle peut aussi être conservée sous la forme d’une phrase de récupération ou phrase mnémonique. Le dispositif HW ne comporte aucun moyen de connexion à Internet et est relié au dispositif hôte HDV, qui exécute un logiciel compagnon HSW lui permettant de se relier à l'Internet, par exemple au moyen d'une liaison USB ou Bluetooth. Le système de sauvegarde de la graine comprend un ensemble de m serveur de sauvegarde BCKi (BCK1,…BCKi,…BCKm) pourvu chacun d'un module de sécurité matérielle HSM (HSM1,… HSMi,…HSMm). Chaque serveur de sauvegarde comporte un programme dorsal, ou programme "back-end", conçu pour la mise en œuvre du procédé de sauvegarde de la graine. Le portefeuille matériel HW est configuré pour diviser la graine S en une pluralité de données secrètes Si (S1,…Si,…Sm) qui seront sauvegardées dans les modules de sécurité matérielle HSMi des serveurs BCKi. Plutôt qu'un simple fractionnement, cette "division" peut être réalisée au moyen d'une fonction de partage de secret SS permettant de générer un nombre m de données secrètes appelées "parts " ("shares"), permettant la reconstitution de la graine à partir d’un seuil de n données secrètes Si. Lorsque l'utilisateur souhaite sauvegarder sa graine, le dispositif HW établit avec chaque serveur de sauvegarde BCKi, par l'intermédiaire du dispositif hôte HDV, des liaisons de données LNKi (LNK1 à LNKm), par exemple de type HTTPS. Ces liaisons de données servent ensuite de support à l’établissement de canaux sécurisés de type SCP ("Secure Channel Protocol") entre le dispositif HW et chaque serveur de sauvegarde BCKi, d'une manière qui va être décrite. L’établissement de tels canaux sécurisés est assuré au moyen d'une infrastructure à clé publique gérée par une autorité de certification CA. Le dispositif HW et les serveurs de sauvegarde BCKi possèdent chacun une clé privée, une clé publique, un certificat signé par l'autorité de certification, ou certificat statique, ainsi que la clé publique de l'autorité de certification. La notation suivante sera utilisée dans ce qui suit : - pD : clé privée du dispositif HW - PD : clé publique du dispositif HW - CD[PD, SIGNCA(PD)] : certificat du dispositif, comprenant sa clé publique PD et une signature de sa clé publique au moyen de la clé privée de l’autorité de certification, - ApKi : clé privée d’attestation d'un serveur BCKi (pour i allant de i à m) - APKi : clé publique d’attestation d'un serveur BCKi (pour i allant de i à m) - CBi[APKi, SIGNCA(APKi)] : certificat d'un serveur BCKi, comprenant sa clé publique d’attestation APK et une signature de sa clé publique au moyen de la clé privée de l’autorité de certification. Les signatures des certificats par l’autorité de certification sont par exemple générées au moyen de l’algorithme ECDSA ("Elliptic Curve Digital Signature Algorithm"). L'autorité de certification CA est de préférence détenue par le fabricant du dispositif HW, pour lui permettre de contrôler l'allocation de certificats CBi aux serveurs de sauvegarde BCKi, afin que ceux-ci puissent être membres de l’infrastructure à clé publique. Ce fabricant est par exemple la partie PART1 citée dans ce qui précède. Les serveurs de sauvegarde BCKi et les modules de sécurité matérielle HSMi sont, ou au moins une partie d’entre eux, détenus par des prestataires de sauvegarde, chacun étant par exemple la partie PART2 citée dans ce qui précède. Le microprogramme exécuté par les modules de sécurité matérielle est développé par la partie PART1 et est mis à jour par celle-ci. La source unique de clés d’authentification pKi, PKi des modules de sécurité matérielle HSMi est détenue par la partie PART1, par exemple le collège d’approbateurs APRV et le module de sécurité matérielle HSM1a. Grâce au procédé décrit dans ce qui précède, la partie PART1 a l’assurance que les microprogrammes des différents modules de sécurité matérielle HSMi ne peuvent pas être corrompus par un fraudeur qui s’immiscerait dans les équipes de maintenance des serveurs de l’une des parties PART2. En effet, comme on l’a vu plus haut, grâce au module de protection PM, l’administrateur d'un module de sécurité matérielle d’une partie PART2 ne peut ni effacer le microprogramme chargé dans le module de sécurité matérielle, ni charger une mise à jour ne comportant pas de signature d’authentification SIGN valide au regard de la clé publique d’authentification PK présente dans la version du microprogramme actuellement installée dans le module de sécurité matérielle. Pour mettre en œuvre un canal de communication sécurisé, un échange de clés est prévu entre le dispositif HW et chaque serveur de sauvegarde BCKi, permettant de générer des clés de session kBi propres à chaque serveur BCKi mais connues du dispositif HW. Cet échange de clés comprend par exemple les étapes suivantes : i) chaque serveur de sauvegarde BCKi génère une clé privée peBi et une clé publique PeBi éphémères au moyen d'un générateur de clés asymétriques, puis communique sa clé publique éphémère PeBi au dispositif HW dans un certificat éphémère CeBi qu'il a signé avec sa clé privée ApKi, ainsi que son certificat CBi signé par l'autorité de certification : CeBi = [PeBi, SIGN [ApKi] (PeBi)] CBi = [APKi, SIGNCA(APKi)] ii) le dispositif HW génère lui-même une paire de clés privée peD et publique PeD éphémères, puis communique sa clé publique éphémère PeD aux serveurs de sauvegarde BCKi dans un certificat éphémère CeD qu'il a signé avec sa clé privée pD, ainsi que son certificat CD signé par l'autorité de certification, soit : CeD = [PeD, SIGN [pD] (PeD)] CD = [PD, SIGNCA(PD)] iii) chaque serveur de sauvegarde BCKi vérifie la signature de la clé publique éphémère PeD du dispositif HW au moyen de la clé publique PD présente dans son certificat CD, puis vérifie la signature de la clé publique PD présente dans le certificat CD au moyen de la clé publique de l'autorité de certification, ou vice-versa, iv) de même, le dispositif HW vérifie la signature de la clé publique éphémère PeBi de chaque serveur BCKi au moyen de la clé publique APKi présente dans le certificat CB, puis vérifie la signature de la clé publique APKi présente dans le certificat CB au moyen de la clé publique de l'autorité de certification, ou vice-versa, v) chaque serveur de sauvegarde BCKi génère une clé de session éphémère kBi à partir de sa clé privée éphémère peBi et de la clé publique éphémère PeD du dispositif HW, au moyen d'une fonction d'échange de clés telle, par exemple la fonction ECDH (échange de clés Diffie Hellman basé sur les courbes elliptiques ou "Elliptic Curve Diffie–Hellman"), soit : kBi = ECDH(peBi, PeD) vi) le dispositif HW génère la clé de session éphémère kBi de chaque serveur de sauvegarde BCKi à partir de sa clé privée éphémère peD et de la clé publique éphémère PeBi du serveur de sauvegarde BCKi, au moyen de la même fonction, soit : kBi = ECDH(peD, PeBi) Après avoir généré les parts Si de la graine S, le dispositif HW conduit des étapes de chiffrement symétrique de chaque part Si avec la clé de session kBi commune au serveur de sauvegarde BCKi à qui la part Si doit être envoyée. Dans un exemple simple de réalisation, le dispositif HW génère trois parts S1, S2, S3 (le seuil n pouvant alors être égal à 2 ou à 3) et trois serveurs de sauvegarde BCK1, BCK2, BCK3 sont prévus. Chaque serveur BCKi génère sa propre clé de session kB1, kB2, kB3. Le dispositif HW génère de son côté chacune de ces clés de session après un échange de clés avec chaque serveur, de la manière qui vient d'être décrite. Ensuite, le dispositif HW conduit des étapes de chiffrement symétrique des parts S1, S2, S3 au moyen de ces clés, soit : - chiffre la part S1 avec la clé kB1, soit {S1}kB1, puis l'envoie au serveur BCK1, - chiffre la part S2 avec la clé kB2, soit {S2}kB2, puis l'envoie au serveur BCK2, - chiffre la part S3 avec la clé kB3, soit {S3}kB3, puis l'envoie au serveur BCK3. Chaque serveur de sauvegarde BCKi déchiffre ensuite la part chiffrée {Si}kBi qu'il a reçue du dispositif HW, et la stocke dans sa mémoire MEM, éventuellement sous une forme chiffrée. Il apparaîtra clairement à l’homme du métier que le procédé d’authentification itératif qui a été décrit dans ce qui précède est susceptible de diverses applications autres que celle concernant la mise à jour d’un microprogramme. Le procédé qui vient d’être décrit est indépendant de la nature du bloc de données DB1 qui est encapsulé dans le bloc de données DB3. Ce bloc de données peut être autre chose qu'un code exécutable par un processeur. Le procédé peut également être utilisé pour sécuriser un fichier de configuration, par exemple de type JSON, que l'on insère dans un module de sécurité matérielle pour en modifier le comportement dynamique, le HSM étant configuré pour vérifier l'authenticité de ce fichier et le non-retour en arrière. Le bloc de données DB1 peut également être le résultat de la numérisation d’un document, comprenant du texte et/ou une ou plusieurs images, par exemple un livre, une œuvre d’art numérique ou numérisée ou de tout autre fichier numérique. Le procédé permet dans ce cas d’authentifier les différentes versions du document ou du fichier, à partir d’une première version dont l’authenticité est assurée ou admise. Par ailleurs, l’encapsulation du bloc de données DB3 dans le bloc de données DB4, propre aux exigences des modules de sécurité matérielle lors de l’installation d’un microprogramme, peut ne pas être prévue dans une autre application, ou être remplacée par un autre type d’encapsulation. Également, comme indiqué dans ce qui précède, les paires de clés d’authentification successives utilisées pour authentifier les différentes versions du bloc de données DB1 peuvent être toutes différentes ou toutes identiques, ou parfois identiques et parfois différentes, le procédé nécessitant seulement qu’il y ait une source unique de génération des paires de clés d’authentification, décrite dans ce qui précède comme un collège d’approbateurs APRV. Le terme « source unique de génération des paires de clés d’authentification », ne désigne pas nécessairement une même entité physique ou informatique. Pour la mise en œuvre du procédé, il est seulement nécessaire que la source d’une paire de clés d’authentification de rang N ait connaissance de la clé privée de rang N-1, sans quoi elle ne pourra pas signer la clé publique de rang N au moyen de la clé privée de rang N-1. Ainsi, si un changement de source génératrice des paires de clés d’authentification intervient pendant le processus itératif, cela signifie qu’il y a eu « passation de secret », à savoir que la nouvelle source de paires de clés a reçu, de la part de la source de paires de clés précédentes, la dernière clé privée que la source précédente a générée. Même dans ce cas, deux sources peuvent être considérées comme une « même source génératrice » puisqu’il y a continuité dans la connaissance des clés privées d’une itération à l’autre. Procédé pour authentifier des versions successives d’un fichier informatique (DB3 N , DB3 N+1 , DB3 N+2 ), à partir d’une première version (DB1 N ) du fichier dont l’authenticité est certaine ou admise, comprenant les étapes consistant à : - prévoir une source unique (HSM1a, APRV) de paires de clés d’authentification (pK N -PK N , pK N+1 -PK N+1 , pK N+2 -PK N+2 ), chaque paire de clé d’authentification comprenant une clé privée d’authentification (pK N , pK N+1 , pK N+2 ) et une clé publique d’authentification (PK N , PK N+1 , PK N+2 ), - au moyen de la source unique de paires de clés d’authentification, générer une première paire de clés d’authentification (pK N -PK N ) comprenant une première clé publique d’authentification (PK N ) et une première clé privée d’authentification (pK N ), - former une version finale (DB3 N ) de la première version (DB1 N ) du fichier, la version finale de la première version du fichier comprenant la première version (DB1 N ) du fichier et au moins la première clé publique d’authentification (PK N ), - générer ou obtenir une deuxième version (DB1 N+1 ) du fichier, - au moyen de la source unique de paires de clés d’authentification, générer une deuxième paire de clés d’authentification (pK N+1 -PK N+1 ) comprenant une deuxième clé publique d’authentification (PK N+1 ) et une deuxième clé privée d’authentification (pK N+1 ), - calculer une signature d’authentification (SIGN N+1 ) de la deuxième version (DB1 N+1 ) du fichier au moyen de la clé privée d’authentification (pK N ) de la première paire de clés d’authentification (pK N -PK N ) et à partir d’un bloc de données (DB2 N+1 ) comprenant au moins la deuxième version (DB1 N+1 ) du fichier et la deuxième clé publique d’authentification (PK N+1 ), et - former une version finale (DB3 N+1 ) de la deuxième version (DB1 N+1 ) du fichier, la version finale comprenant au moins la deuxième version (DB1 N+1 ) du fichier, la deuxième clé publique d’authentification (PK N+1 ) et la signature d’authentification (SIGN N+1 ) de la deuxième version (DB1 N+1 ) du fichier. Procédé selon la revendication 1, comprenant une étape de vérification de l’authenticité de la version finale (DB3 N+1 ) de la deuxième version (DB1 N+1 ) du fichier en référence à la version finale (DB3 N ) de la première version (DB1 N ) du fichier, l’étape de vérification de l’authenticité de la version finale (DB3 N+1 ) de la deuxième version (DB1 N+1 ) du fichier comprenant l’étape consistant à vérifier la validité de la signature d’authentification (SIGN N+1 ) de la deuxième version (DB1 N+1 ) du fichier au moyen de la première clé publique d’authentification (PK N ) présente dans la version finale (DB3 N ) de la première version (DB1 N ) du fichier et à partir du bloc de données comprenant au moins la deuxième version (DB1 N+1 ) du fichier et la deuxième clé publique d’authentification (PK N+1 ). Procédé selon la revendication 2, dans lequel l’étape de vérification d’authenticité est conduite par une personne, une machine ou un processeur ne connaissant aucune des clés privées. Procédé selon l’une des revendications 1 à 3, comprenant les étapes consistant à : - attribuer à la deuxième version (DB1 N+1 ) du fichier une information (VN) permettant de le distinguer de la première version (DB1 N ) du fichier, telle qu’un numéro de version, une date de création ou autre information d’identification, et - ajouter l’information concernant la deuxième version (DB1 N+1 ) du fichier au bloc de données à partir duquel la signature d’authentification (SIGN N+1 ) de la deuxième version (DB1 N+1 ) du fichier est calculée. Procédé selon la revendication 4, comprenant l’étape consistant à insérer des marqueurs dans le bloc de données (DB2 N+1 ) à partir duquel la signature d’authentification (SIGN N+1 ) de la deuxième version (DB1 N+1 ) du fichier est calculée, pour distinguer la deuxième version (DB1 N+1 ) du fichier de la deuxième clé publique d’authentification (PK N+1 ) et distinguer la deuxième clé publique d’authentification (PK N+1 ) de l’information concernant la deuxième version (DB1 N+1 ) du fichier. Procédé selon l’une des revendications 1 à 5, comprenant les étapes consistant à : - générer ou obtenir une troisième version (DB1 N+2 ) du fichier, - au moyen de la source unique de paires de clés d’authentification, générer une troisième paire de clés d’authentification (pK N+2 -PK N+2 ) comprenant une troisième clé publique d’authentification (PK N+2 ) et une troisième clé privée d’authentification (pK N+2 ), - calculer une signature d’authentification (SIGN N+2 ) de la troisième version (DB1 N+2 ) du fichier au moyen de la clé privée d’authentification (pK N+1 ) de la deuxième paire de clés d’authentification (pK N+1 -PK N+1 ) et à partir d’un bloc de données (DB2 N+2 ) comprenant au moins la troisième version (DB1 N+2 ) du fichier et la troisième clé publique d’authentification (PK N+2 ), et - former une version finale (DB3 N+2 ) de la troisième version (DB1 N+2 ) du fichier, la version finale comprenant au moins la troisième version (DB1 N+2 ) du fichier, la troisième clé publique d’authentification (PK N+2 ) et la signature d’authentification (SIGN N+2 ) de la troisième version (DB1 N+2 ) du fichier. Procédé selon la revendication 6, comprenant une étape de vérification de l’authenticité de la version finale (DB3 N+2 ) de la troisième version (DB1 N+2 ) du fichier en référence à la version finale (DB3 N+1 ) de la deuxième version (DB1 N+1 ) du fichier, l’étape de vérification de l’authenticité de la version finale (DB3 N+2 ) de la troisième version (DB1 N+2 ) du fichier comprenant l’étape consistant à vérifier la validité de la signature d’authentification (SIGN N+2 ) de la troisième version (DB1 N+2 ) du fichier au moyen de la deuxième clé publique d’authentification (PK N+1 ) présente dans la version finale (DB3 N+1 ) de la deuxième version (DB1 N+1 ) du fichier et à partir du bloc de données comprenant au moins la troisième version (DB1 N+2 ) du fichier et la troisième clé publique d’authentification (PK N+2 ). Procédé selon la revendication 7, dans lequel l’étape de vérification de l’authenticité de la version finale (DB3 N+2 ) de la troisième version (DB1 N+2 ) du fichier est conduite par une personne, une machine ou un processeur ne connaissant aucune des clés privées. Procédé selon l’une des revendications 6 à 8, comprenant les étapes consistant à : - attribuer à la troisième version (DB1 N+2 ) du fichier une information (VN) permettant de le distinguer de la deuxième (DB1 N+1 ) du fichier, telle qu’un numéro de version, une date de création ou autre information d’identification, et - ajouter l’information (VN) permettant de distinguer la troisième version (DB1 N+2 ) du fichier de la deuxième version (DB1 N+1 ) du fichier au bloc de données à partir duquel la signature d’authentification (SIGN N+2 ) de la troisième version (DB1 N+2 ) du fichier est calculée. Procédé selon la revendication 9, comprenant l’étape consistant à insérer des marqueurs dans le bloc de données (DB2 N+2 ) à partir duquel la signature d’authentification (SIGN N+2 ) de la troisième version (DB1 N+2 ) du fichier est calculée, pour distinguer la troisième version (DB1 N+2 ) du fichier de la troisième clé publique d’authentification (PK N+2 ) et distinguer la troisième clé publique d’authentification (PK N+2 ) de l’information concernant la troisième version (DB1 N+2 ) du fichier. Procédé selon l’une des revendications 1 à 10, dans lequel deux paires de clés de rangs successifs peuvent être identiques ou différentes. Procédé selon l’une des revendications 1 à 11, dans lequel chaque version du fichier est une version d’un document comprenant du texte et/ou des images. Procédé selon l’une des revendications 1 à 12, dans lequel chaque version du fichier est une œuvre d’art numérique ou numérisée et chaque version du fichier correspond à une version de l’œuvre à des stades différents de sa création ou à des dates différentes de l’œuvre finalisée. Procédé selon l’une des revendications 1 à 11, dans lequel chaque fichier est un fichier microprogramme installé ou destiné à être installé dans un processeur (HSMp). Procédé selon la revendication 14, dans lequel l’étape de vérification d’authenticité est conduite par un module de protection (PM) du processeur, le module de protection étant configuré pour empêcher que le fichier microprogramme ne soit effacé et empêcher qu’une version non authentique d’une mise à jour du fichier microprogramme ne soit installée dans le processeur. Procédé selon l’une des revendications 14 et 15, comprenant les étapes consistant à : - concaténer la version finale (DB3 N+1 ) de la deuxième version (DB1 N+1 ) du fichier microprogramme avec une signature d’installation (ISIGN N+1 ) générée au moyen d’une clé privée d’installation (IpK N+1 ) et à partir de la version finale (DB3 N+1 ) de la deuxième version du fichier microprogramme, et - fournir une clé publique d’installation (IPK N+1 ) correspondant à la clé privée d’installation (IpK N+1 ) au processeur dans lequel la deuxième version (DB1 N+1 ) du fichier microprogramme doit être installée. Procédé selon l’une des revendications 14 à 16, dans lequel les versions finales du fichier microprogramme sont fournies à un exploitant du processeur n’ayant accès à aucune clé privée. Procédé de fabrication d’au moins deux versions (DB3 N , DB3 N+1 , DB3 N+2 ) d’un fichier informatique liées entre elles par un lien d’authentification, comprenant les étapes consistant à : - prévoir une source unique (HSM1a, APRV) de paires de clés d’authentification (pK N -PK N , pK N+1 -PK N+1 , pK N+2 -PK N+2 ), chaque paire de clé d’authentification comprenant une clé privée d’authentification (pK N , pK N+1 , pK N+2 ) et une clé publique d’authentification (PK N , PK N+1 , PK N+2 ), - au moyen de la source unique de paires de clés d’authentification, générer une première paire de clés d’authentification (pK N -PK N ) comprenant une première clé publique d’authentification (PK N ) et une première clé privée d’authentification (pK N ), - générer ou obtenir une première version (DB1 N ) du fichier, - former une version finale (DB3 N ) de la première version (DB1 N ) du fichier, la version finale de la première version du fichier comprenant la première version (DB1 N ) du fichier et au moins la première clé publique d’authentification (PK N ), - enregistrer la version finale (DB3 N ) de la première version (DB1 N ) du fichier sur un support, - générer ou obtenir une deuxième version (DB1 N+1 ) du fichier, - au moyen de la source unique de paires de clés d’authentification, générer une deuxième paire de clés d’authentification (pK N+1 -PK N+1 ) comprenant une deuxième clé publique d’authentification (PK N+1 ) et une deuxième clé privée d’authentification (pK N+1 ), - calculer une signature d’authentification (SIGN N+1 ) de la deuxième version (DB1 N+1 ) du fichier au moyen de la clé privée d’authentification (pK N ) de la première paire de clés d’authentification (pK N -PK N ) et à partir d’un bloc de données (DB2 N+1 ) comprenant au moins la deuxième version (DB1 N+1 ) du fichier et la deuxième clé publique d’authentification (PK N+1 ), - former une version finale (DB3 N+1 ) de la deuxième version (DB1 N+1 ) du fichier, la version finale comprenant au moins la deuxième version (DB1 N+1 ) du fichier, la deuxième clé publique d’authentification (PK N+1 ) et la signature d’authentification (SIGN N+1 ) de la deuxième version (DB1 N+1 ) du fichier, et - enregistrer la version finale (DB3 N+1 ) de la deuxième version (DB1 N+1 ) du fichier sur un support. Procédé de fabrication selon la revendication 18, comprenant les étapes consistant à : - attribuer à la deuxième version (DB1 N+1 ) du fichier au moins une information (VN) permettant de le distinguer de la première version (DB1 N ) du fichier, et - ajouter l’information (VN) concernant la deuxième version (DB1 N+1 ) du fichier au bloc de données à partir duquel la signature d’authentification (SIGN N+1 ) de la deuxième version (DB1 N+1 ) du fichier est calculée. Procédé de fabrication selon l’une des revendications 18 et 19, comprenant les étapes consistant à : - générer ou obtenir une troisième version (DB1 N+2 ) du fichier, - au moyen de la source unique de paires de clés d’authentification, générer une troisième paire de clés d’authentification (pK N+2 -PK N+2 ) comprenant une troisième clé publique d’authentification (PK N+2 ) et une troisième clé privée d’authentification (pK N+2 ), - calculer une signature d’authentification (SIGN N+2 ) de la troisième version (DB1 N+2 ) du fichier au moyen de la clé privée d’authentification (pK N+1 ) de la deuxième paire de clés d’authentification (pK N+1 -PK N+1 ) et à partir d’un bloc de données (DB2 N+2 ) comprenant au moins la troisième version (DB1 N+2 ) du fichier et la troisième clé publique d’authentification (PK N+2 ), - former une version finale (DB3 N+2 ) de la troisième version (DB1 N+2 ) du fichier, la version finale comprenant au moins la troisième version (DB1 N+2 ) du fichier, la troisième clé publique d’authentification (PK N+2 ) et la signature d’authentification (SIGN N+2 ) de la troisième version (DB1 N+2 ) du fichier, et - enregistrer la version finale (DB3 N+2 ) de la troisième version (DB1 N+2 ) du fichier sur un support.