Brevet FR3164301A1 — publié le 20260109

Procédé pour l’exécution d’un programme par un processeur sécurisé (SPROC), comprenant les étapes consistant à prévoir un espace mémoire non volatile (DMEM) pour stocker les données nécessaires à l'exécution du programme d’application, prévoir dans l’espace mémoire non volatile une première base de données (ADB) et stocker les données dans la première base de données (ADB), et une seconde base de données (TDB) configurée pour former un arbre de Merkle clairsemé, prévoir au moins un processeur de gestion (DPROC) pour gérer les première et seconde bases de données, lire (S52) dans la première base de données (ADB) des données créées ou modifiées par le processeur sécurisé, et mettre à jour la seconde base de données après chaque modification du contenu de la première base de données, pour que son état actuel reflète l’état actuel de la première base de données, calculer ou déterminer puis stocker dans une mémoire non volatile sécurisée (SMEM) un code de hachage racine (RHm) de l’arbre de Merkle représentatif de l’état actuel de la seconde base de données. Figure abrégé : Figure 1 Procédé pour l’exécution d’un programme d’application au moyen d’un module de sécurité matérielle équipé d’une mémoire sécurisée. La présente invention concerne un procédé pour l’exécution d’un programme d’application au moyen d’un module de sécurité matérielle équipé d’une mémoire sécurisée, l’exécution du programme d’application comprenant des étapes de création et de modification par le module de sécurité matérielle de données nécessaire à l’exécution du programme. La présente invention concerne également un système sécurisé comprenant un module de sécurité matérielle équipé d’une mémoire sécurisée et configuré pour exécuter au moins un programme d’application, l’exécution du programme d’application comprenant des étapes de création et de modification de données par le module de sécurité matérielle. Arrière-plan La sécurisation de données stockées dans un espace mémoire non volatile est une préoccupation majeure dans des domaines sensibles tels que le secteur bancaire ou celui des cryptomonnaies. L'utilisation de processeurs sécurisés, tels que les modules de sécurité matérielle ou « HSM », offre une solution robuste pour protéger ces informations. L'intégration de protocoles de sécurité robustes et l'application de normes de sécurité internationales, telles que FIPS 140-2, garantissent que la mise en œuvre d’une infrastructure de sécurité répond aux exigences les plus strictes. Ces mesures, combinées à l'utilisation judicieuse d'un HSM pour la gestion de clés, permettent de sécuriser efficacement de grandes quantités de données dans des espaces mémoire non volatiles, répondant ainsi aux besoins critiques des secteurs bancaires et des cryptomonnaies. Cependant, un défi notable réside dans le fait que les processeurs sécurisés tels les HSM ne disposent que d'un espace mémoire limité. Cela pose un problème particulier lorsqu'il s'agit de sécuriser de grandes quantités de données qui nécessitent un stockage de masse tout en garantissant un haut degré de sécurité contre des attaques de hackers. Une solution connue efficace pour surmonter cette limitation consiste à utiliser le HSM non pas pour stocker directement toutes les données, mais pour gérer les clés de chiffrement, les données elles-mêmes étant stockées dans des systèmes de stockage de masse moins sécurisés, mais chiffrées de manière à ce qu'elles soient inutilisables sans les clés appropriées, qui sont protégées par le HSM. Cette approche permet de tirer parti de la capacité de stockage élevée des systèmes de stockage de masse tout en assurant que les données restent sécurisées. En pratique, cela implique que les données sensibles soient chiffrées avant d'être écrites sur le stockage de masse. Le HSM génère, stocke et gère les clés de chiffrement de manière sécurisée, assurant ainsi que même si un attaquant parvient à accéder au stockage de masse, les données restent illisibles sans les clés appropriées. Dans le domaine bancaire, par exemple, les transactions financières et les informations personnelles des clients peuvent être protégées par un chiffrement fort. Le HSM garantit que les clés de chiffrement utilisées pour sécuriser ces données ne peuvent pas être extraites ou manipulées par des entités non autorisées. De même, dans le domaine des cryptomonnaies, les clés privées nécessaires pour signer des transactions peuvent être stockées en toute sécurité dans un HSM, offrant ainsi une protection contre les vols et les fraudes. L'utilisation de techniques de chiffrement avancées permet d'optimiser l'utilisation de l'espace mémoire limité d’un HSM. Par exemple, les données peuvent être chiffrées à l'aide d'une clé symétrique, tandis que cette clé est elle-même chiffrée à l'aide d'une clé symétrique stockée dans le HSM, dite clé d’encapsulation (« wrapping key »)» . Lorsqu'il est nécessaire de déchiffrer les données, la clé symétrique est récupérée et déchiffrée par le HSM. Cette "clé de wrapping" est habituellement insérée dans le HSM en utilisant une ou plusieurs cartes à puces ce qui permet de l'insérer dans un nouveau HSM en cas de problème avec le HSM actuel. Ces solutions connues ont toutefois elles-mêmes leurs propres limites, notamment en ce qu’elles ne protègent pas les données contre les attaques dites « par rejeu », à savoir l’insertion frauduleuse de données initialement authentiques mais périmées. Par ailleurs, dans certaines mises en œuvre, les programmes exécutant ces applications, ou programmes d'application, sont directement exécutés par un HSM, qui doit à cet effet manipuler une grande quantité de données. Ces données varient sans cesse au fur et à mesure de l’exécution du programme, et sont manipulées en temps réel par le HSM. Lorsque l’exécution du programme d’application est interrompue, elles doivent être stockées de manière sécurisée puis récupérées par le HSM lors de la reprise de l’exécution du programme. Une autre solution connue, pouvant être combinée avec les précédentes, consiste à utiliser des compteurs monotones dont les valeurs sont conservées dans la mémoire d’un HSM, chaque donnée à protéger étant associée à un compteur monotone. Une telle solution est par exemple décrite dans la demande internationale WO 2019/175482. En plus de la sécurité apportée par les techniques de chiffrement/signature évoquée plus haut, les compteurs monotones ajoutent une protection contre les attaques par rejeu en associant une valeur unique et incrémentale à chaque opération ou transaction entraînant la modification d’une donnée. Ainsi, lorsqu'une donnée est enregistrée ou mise à jour, le compteur monotone associé à la donnée est incrémenté par le HSM et cette valeur est stockée avec la donnée chiffrée sur le stockage de masse, tandis que le HSM conserve la valeur du compteur dans une mémoire sécurisée, empêchant toute modification non autorisée. Lors de la lecture ou de la vérification de la donnée ou du bloc de données, le compteur monotone associé est comparé avec la valeur attendue stockée dans le HSM, ce qui permet de détecter toute altération ou tentative de relecture d’une donnée périmée. Cette solution permet de sécuriser efficacement de grandes quantités de données à partir d’un stockage de masse tout en maintenant un haut degré de sécurité. Elle assure que même si un attaquant accède au stockage de masse, il ne pourra ni modifier ni rejouer des données sans être détecté, grâce à la gestion des compteurs monotones par le HSM. Cela offre une protection robuste contre les attaques de hackers, tout en optimisant l'utilisation de l'espace mémoire limité du HSM. Cette solution montre toutefois ses limites en ce qu’elle entraîne une démultiplication du nombre de compteurs monotones devant être mémorisés par le HSM, pouvant conduire à une saturation de sa mémoire sécurisée. Il pourrait donc être souhaité de prévoir un procédé pour l’exécution d’un programme d’application au moyen d’un module de sécurité matérielle équipé d’une mémoire sécurisée, l’exécution du programme d’application comprenant des étapes de création et de modification par le module de sécurité matérielle d’une grande quantité de données ne pouvant pas être stockée dans la mémoire sécurisée de celui-ci. Résumé Des modes de réalisation concernent un procédé pour l’exécution d’un programme d’application au moyen d’un processeur sécurisé équipé d’une mémoire non volatile sécurisée, l’exécution du programme d’application comprenant des étapes de création et de modification par le processeur sécurisé de données nécessaires à l’exécution du programme d’application, le procédé comprenant les étapes consistant à : prévoir un espace mémoire non volatile présentant une capacité de stockage suffisante pour stocker les données nécessaires à l'exécution du programme d’application ; prévoir dans l’espace mémoire non volatile une première base de données indexée et stocker les données dans la première base de données, la première base de données comprenant une pluralité d’emplacements identifiables chacun par un index, chaque emplacement pouvant recevoir une donnée ; prévoir dans l’espace mémoire non volatile une seconde base de données associée à la première base de données et configurée pour former un arbre de Merkle clairsemé comprenant des nœuds feuilles et des nœuds internes s’étendant sur une pluralité de niveaux de l’arbre jusqu’à un nœud sommet, chaque emplacement de la première base de données pouvant être associé à un nœud feuille, chaque nœud feuille recevant un code de hachage de la donnée présente dans l’emplacement auquel il est associé ou un code de hachage de nœud vide), chaque nœud de niveau supérieur recevant un code de hachage calculé à partir de la concaténation des codes de hachage présents dans deux nœuds de niveau précédent, jusqu’au nœud sommet, le nœud sommet comprenant un code de hachage racine ; prévoir au moins un processeur de gestion pour gérer les première et seconde bases de données ; au moyen du processeur de gestion, lire dans la première base de données ou stocker dans la première base de données des données créées ou modifiées par le processeur sécurisé, et mettre à jour la seconde base de données après chaque modification du contenu de la première base de données, pour que son état actuel reflète l’état actuel de la première base de données ; au moyen du processeur sécurisé, calculer ou déterminer puis stocker dans la mémoire non volatile sécurisée un code de hachage racine de l’arbre de Merkle représentatif de l’état actuel de la seconde base de données, et mettre à jour le code de hachage racine mémorisé avant ou après chaque enregistrement d’au moins une nouvelle donnée dans la première base de données par le processeur de gestion. Selon un mode de réalisation, le procédé comprend, lorsqu’une donnée est lue par le processeur de gestion dans un emplacement cible de la première base de données, les étapes consistant à : au moyen du processeur de gestion, fournir au processeur sécurisé la preuve de Merkle d’un nœud feuille cible associé à l’emplacement cible, et, au moyen du processeur sécurisé : calculer ou déterminer un premier code de hachage racine de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données ; comparer le premier code de hachage racine au code de hachage racine mémorisé dans la mémoire non volatile sécurisée, et considérer la donnée comme valide si le premier code de hachage racine est égal au code de hachage racine mémorisé. Selon un mode de réalisation, le procédé comprend, lorsqu’au moins une nouvelle donnée doit être générée par le processeur sécurisé puis stockée dans un emplacement cible de la première base de données, les étapes consistant à : au moyen du processeur de gestion, fournir au processeur sécurisé, la preuve de Merkle d’un nœud feuille cible associé à l’emplacement cible, et une donnée se trouvant dans l’emplacement cible ou une indication que l’emplacement est vide ; au moyen du processeur sécurisé : calculer ou déterminer un premier code de hachage racine de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données, et comparer le premier code de hachage racine au code de hachage racine mémorisé dans la mémoire non volatile sécurisée ; si le premier code de hachage racine est identique au code de hachage racine mémorisé : générer la nouvelle donnée ; calculer ou déterminer un second code de hachage racine de l’arbre de Merkle fondé sur l’état dans lequel sera la seconde base de données après enregistrement de la nouvelle donnée dans la première base de données et mise à jour de la seconde base de données, et stocker le second code de hachage racine dans la mémoire non volatile sécurisée, en remplacement du code de hachage racine anciennement mémorisé, et, au moyen du processeur de gestion, mettre à jour la première et la seconde base de données sur la base de la nouvelle donnée. Selon un mode de réalisation, le calcul ou la détermination par le processeur sécurisé du second code de hachage racine comprend les étapes consistant à : identifier des nœuds liés au nœud feuille cible, les nœuds liés se trouvant sur un chemin reliant le nœud feuille cible au nœud sommet, sur la base de la nouvelle donnée, calculer ou déterminer un nouveau code de hachage que le nœud feuille cible contiendra ; sur la base du nouveau code de hachage que le nœud feuille cible contiendra et de la preuve de Merkle, calculer ou déterminer des codes de hachage que les nœuds liés au nœud feuille cible contiendront ; calculer ou déterminer le second code de hachage racine sur la base du nouveau code de hachage que le nœud feuille cible contiendra, de la preuve de Merkle et des nouveaux codes de hachage que les nœuds liés au nœud feuille cible contiendront. Selon un mode de réalisation, le calcul ou la détermination par le processeur sécurisé du premier code de hachage racine comprend les étapes consistant à identifier des nœuds liés au nœud feuille cible, les nœuds liés se trouvant sur un chemin reliant le nœud feuille cible au nœud sommet ; calculer ou déterminer un code de hachage que le nœud feuille cible est supposé contenir ; sur la base du code de hachage que le nœud feuille cible est supposé contenir et de la preuve de Merkle, calculer ou déterminer des codes de hachage que des nœuds liés au nœud feuille cible sont supposés contenir ; calculer ou déterminer le premier code de hachage racine sur la base du code de hachage que le nœud feuille cible est supposé contenir, de la preuve de Merkle et des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir. Selon un mode de réalisation, un nœud feuille vide est un nœud associé à un emplacement vide de la base de données, et un nœud feuille vide contient par convention un code de hachage de nœud vide) de valeur prédéterminée. Selon un mode de réalisation, le code de hachage de nœud vide) est égal à zéro. Selon un mode de réalisation, un nœud parent de deux nœuds vides est un nœud vide contenant par convention le code de hachage de nœud vide). Selon un mode de réalisation, un nœud parent d’un nœud vide et d’un nœud non vide contient par convention un code de hachage présent dans le nœud non vide suivi d’un bit égal à 0 ou à 1 selon que le nœud feuille vide se trouve dans l’arbre de Merkle à droite ou à gauche du nœud feuille non vide, ou vice-versa. Selon un mode de réalisation, un nœud parent de deux nœuds feuilles vides contient par convention un code de hachage égal au résultat du hachage de la concaténation des codes de hachage de nœud vide contenus par chacun des deux nœuds feuilles vides. Selon un mode de réalisation, le processeur sécurisé ne stocke que le code de hachage racine dans la mémoire non volatile sécurisée, et aucune autre donnée de la première ou de la seconde base de données. Selon un mode de réalisation, le processeur de gestion stocke dans la seconde base de données au moins tous les codes de hachage contenus dans des nœuds non vides de l’arbre de Merkle. Selon un mode de réalisation, le procédé comprend la prévision d’une entité utilisatrice interposée opérationnellement entre le processeur de gestion et le processeur sécurisé, et les étapes consistant à, au moyen de l’entité utilisatrice, recevoir des données fournies par le processeur de gestion et les transférer au processeur sécurisé, ou recevoir des données fournies par le processeur sécurisé et les transférer au processeur de gestion. Selon un mode de réalisation, les données sont des données affectées à des titulaires de comptes de cryptoactifs. Des modes de réalisation concernent également un système sécurisé comprenant un module de sécurité matérielle équipé d’une mémoire sécurisée et configuré pour exécuter au moins un programme d’application, dans lequel l’exécution du programme d’application comprend des étapes de création et de modification par le module de sécurité matérielle de données nécessaires à l’exécution du programme d’application, le système comprenant un espace mémoire non volatile comprenant une première base de données indexée comprenant une pluralité d’emplacements identifiables chacun par un index, chaque emplacement pouvant recevoir une donnée, et une seconde base de données associée à la première base de données et configurée pour former un arbre de Merkle clairsemé comprenant des nœuds feuilles et des nœuds internes s’étendant sur une pluralité de niveaux de l’arbre jusqu’à un nœud sommet, chaque emplacement de la première base de données pouvant être associé à un nœud feuille, chaque nœud feuille recevant un code de hachage de la donnée présente dans l’emplacement auquel il est associé ou un code de hachage de nœud vide, chaque nœud de niveau supérieur recevant un code de hachage calculé à partir de la concaténation des codes de hachage présents dans deux nœuds de niveau précédent, jusqu’au nœud sommet, le nœud sommet comprenant un code de hachage racine ; et au moins un processeur de gestion pour gérer les première et seconde bases de données. Le processeur de gestion est configuré pour lire dans la première base de données ou stocker dans la première base de données des données créées ou modifiées par le module de sécurité matérielle, et mettre à jour la seconde base de données après chaque modification du contenu de la première base de données, pour que son état actuel reflète l’état actuel de la première base de données. Le module de sécurité matérielle est configuré pour calculer ou déterminer puis stocker dans la mémoire non volatile sécurisée un code de hachage racine de l’arbre de Merkle représentatif de l’état actuel de la seconde base de données, et mettre à jour le code de hachage racine mémorisé avant ou après chaque enregistrement d’au moins une nouvelle donnée dans la première base de données par le processeur de gestion. Selon un mode de réalisation, 15, lorsqu’une donnée est lue par le processeur de gestion dans un emplacement cible de la première base de données, le processeur de gestion est configuré pour fournir au module de sécurité matérielle la preuve de Merkle d’un nœud feuille cible associé à l’emplacement cible, et le module de sécurité matérielle est configuré pour calculer ou déterminer un premier code de hachage racine de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données ; comparer le premier code de hachage racine au code de hachage racine mémorisé dans la mémoire non volatile sécurisée, et considérer la donnée comme valide si le premier code de hachage racine est égal au code de hachage racine mémorisé. Selon un mode de réalisation, lorsqu’au moins une nouvelle donnée doit être générée par le module de sécurité matérielle puis stockée dans un emplacement cible de la première base de données, le processeur de gestion est configuré pour fournir au module de sécurité matérielle, la preuve de Merkle d’un nœud feuille cible associé à l’emplacement cible, et une donnée se trouvant dans l’emplacement cible ou une indication que l’emplacement est vide, et le module de sécurité matérielle est configuré pour calculer ou déterminer un premier code de hachage racine de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données, et comparer le premier code de hachage racine au code de hachage racine mémorisé dans la mémoire non volatile sécurisée, et, si le premier code de hachage racine est identique au code de hachage racine mémorisé : générer la nouvelle donnée ; calculer ou déterminer un second code de hachage racine de l’arbre de Merkle fondé sur l’état dans lequel sera la seconde base de données après enregistrement de la nouvelle donnée dans la première base de données et mise à jour de la seconde base de données, et stocker le second code de hachage racine dans la mémoire non volatile sécurisée, en remplacement du code de hachage racine anciennement mémorisé, le processeur de gestion étant également configuré pour mettre à jour la première et la seconde base de données sur la base de la nouvelle donnée. Selon un mode de réalisation, pour calculer ou déterminer le second code de hachage racine, le module de sécurité matérielle est configuré pour identifier des nœuds liés au nœud feuille cible, les nœuds liés se trouvant sur un chemin reliant le nœud feuille cible au nœud sommet ; sur la base de la nouvelle donnée, calculer ou déterminer un nouveau code de hachage que le nœud feuille cible contiendra ; sur la base du nouveau code de hachage que le nœud feuille cible contiendra et de la preuve de Merkle, calculer ou déterminer des codes de hachage que les nœuds liés au nœud feuille cible contiendront, et calculer ou déterminer le second code de hachage racine sur la base du nouveau code de hachage que le nœud feuille cible contiendra, de la preuve de Merkle et des nouveaux codes de hachage que les nœuds liés au nœud feuille cible contiendront. Selon un mode de réalisation, pour calculer ou déterminer le premier code de hachage racine, le module de sécurité matérielle est configuré pour identifier des nœuds liés au nœud feuille cible, les nœuds liés se trouvant sur un chemin reliant le nœud feuille cible au nœud sommet ; calculer ou déterminer un code de hachage que le nœud feuille cible est supposé contenir ; sur la base du code de hachage que le nœud feuille cible est supposé contenir et de la preuve de Merkle, calculer ou déterminer des codes de hachage que des nœuds liés au nœud feuille cible sont supposés contenir ; calculer ou déterminer le premier code de hachage racine sur la base du code de hachage que le nœud feuille cible est supposé contenir, de la preuve de Merkle et des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir. Selon un mode de réalisation, le module de sécurité matérielle ne stocke que le code de hachage racine dans la mémoire non volatile sécurisée, et aucune autre donnée de la première ou de la seconde base de données. Selon un mode de réalisation, le processeur de gestion stocke dans la seconde base de données au moins tous les codes de hachage contenus dans des nœuds non vides de l’arbre de Merkle. Selon un mode de réalisation, le système comprend une entité utilisatrice interposée opérationnellement entre le processeur de gestion et le module de sécurité matérielle, et dans lequel des données fournies par le processeur de gestion à l’attention du processeur sécurisé sont reçues par l’entité utilisatrice qui les fournit au processeur sécurisé et réciproquement. Des modes de réalisation concernent également un procédé pour sécuriser des données mémorisées dans un espace mémoire non volatile, le procédé comprenant les étapes consistant à prévoir dans l’espace mémoire non volatile une première base de données indexée et stocker les données dans la première base de données, la première base de données comprenant une pluralité d’emplacements identifiables chacun par un index, chaque emplacement pouvant recevoir une donnée ; prévoir dans l’espace mémoire non volatile une seconde base de données indexée associée à la première base de données et configurée pour former un arbre de Merkle clairsemé tel que défini dans ce qui précède, après chaque mise à jour de la première base de données, mettre à jour l’arbre de Merkle dans la seconde base de données pour que son état actuel reflète l’état actuel de la première base de données ; prévoir une mémoire non volatile sécurisée ; stocker dans la mémoire non volatile sécurisée un code de hachage racine de l’arbre de Merkle représentatif de l’état actuel de la seconde base de données, et lorsqu’une donnée doit être lue dans la première base de données : lire la donnée dans la première base de données ; calculer un premier code de hachage racine de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données, et comparer le premier code de hachage racine à un code de hachage racine mémorisé dans la mémoire non volatile sécurisée, la donnée étant valide si le premier code de hachage racine est égal au code de hachage racine mémorisé. Selon un mode de réalisation, le procédé comprend, lorsqu’une donnée doit être stockée dans un emplacement cible de la première base de données, les étapes consistant à : calculer le premier code de hachage racine de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données, et comparer le premier code de hachage racine au code de hachage racine mémorisé dans la mémoire non volatile sécurisée, et, si le premier code de hachage racine est identique au code de hachage racine mémorisé : calculer un second code de hachage racine fondé sur l’état dans lequel sera la seconde base de données après enregistrement de la nouvelle donnée dans la première base de données et mise à jour de la seconde base de données ; stocker le second code de hachage racine dans la mémoire non volatile sécurisée, en remplacement du code de hachage racine anciennement mémorisé ; mettre à jour la première base de données avec la nouvelle donnée, et mettre à jour l’arbre de Merkle dans la seconde base de données. Selon un mode de réalisation, l’étape de calcul du premier code de hachage racine de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données comprend les étapes consistant à lire une donnée contenue dans l’emplacement cible ou déterminer le fait que l’emplacement est vide ; identifier un nœud feuille cible associé à l’emplacement cible ; identifier des nœuds liés au nœud feuille cible, les nœuds liés se trouvant sur un chemin reliant le nœud feuille cible au nœud sommet ; extraire de la seconde base de données une preuve de Merkle du nœud feuille cible, la preuve de Merkle comprenant des codes de hachage contenus dans des nœuds voisins aux nœuds liés ; calculer ou déterminer un code de hachage que le nœud feuille cible est supposé contenir ; sur la base du code de hachage que le nœud feuille cible est supposé contenir et de la preuve de Merkle extraite de la seconde base de données, calculer ou déterminer des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir ; calculer ou déterminer le premier code de hachage racine sur la base du code de hachage que le nœud feuille cible est supposé contenir, de la preuve de Merkle extraite de la seconde base de données, et des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir. Selon un mode de réalisation, l’étape de calcul du second code de hachage racine fondé sur l’état dans lequel sera la seconde base de données après enregistrement de la nouvelle donnée dans la première base de données et mise à jour de la seconde base de données, comprend les étapes consistant à : sur la base de la nouvelle donnée, calculer ou déterminer un nouveau code de hachage que le nœud feuille cible contiendra ; sur la base du nouveau code de hachage que le nœud feuille cible contiendra et de la preuve de Merkle extraite de la seconde base de données, calculer ou déterminer de nouveaux codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir, et calculer ou déterminer le second code de hachage racine sur la base du nouveau code de hachage que le nœud feuille cible contiendra, de la preuve de Merkle extraite de la seconde base de données, et des nouveaux codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir. Description sommaire des dessins Des exemples de réalisation d’un procédé et d’un système mettant en œuvre le procédé selon la présente divulgation seront décrits dans ce qui suit à titre non limitatif en relation avec les figures jointes, parmi lesquelles : - la FIG. 1 montre un exemple d’architecture de système de stockage de données mettant en œuvre un mode de réalisation du procédé, - la FIG. 2 montre un exemple simplifié d’arbre de Merkle, - la FIG. 3 montre l’attribution de codes de hachage prédéterminés à des nœuds feuilles vides et leurs nœuds parents, selon une première convention, - la FIG. 4 montre l’attribution de codes de hachage déterminés à des nœuds feuilles vides et leurs nœuds parents, selon une seconde convention, - la FIG. 5 montre une partie de l’arbre de Merkle de la FIG. 2 et montre, pour un nœud feuille déterminé, un ensemble de nœuds liés au nœud feuille et un ensemble de nœuds formant une preuve de Merkle pour le nœud feuille considéré, - la FIG. 6 montre une partie de l’arbre de Merkle de la FIG. 2 et montre, pour deux nœuds feuilles déterminés, un ensemble de nœuds liés aux deux nœuds feuilles et un ensemble de nœuds formant une preuve de Merkle pour les deux nœuds feuilles considérés, - la FIG. 7 montre un exemple simplifié d’arbre de Merkle, - la FIG. 8 montre l’arbre de Merkle de la FIG. 7 après écriture d’une nouvelle donnée, - la FIG. 9 est un diagramme de séquence montrant des étapes d’écriture de la nouvelle donnée, - la FIG. 9 décrit des étapes du diagramme de la FIG. 9 , - la FIG. 10 montre l’arbre de Merkle de la FIG. 8 après modification d’une donnée, - la FIG. 11 est un diagramme de séquence montrant des étapes de modification de la nouvelle donnée, et - la FIG. 11 décrit des étapes du diagramme de la FIG. 11 . Description détaillée La FIG. 1 montre un système de stockage de données mettant en œuvre un mode de réalisation du procédé de stockage sécurisé de données selon la présente divulgation. Le système comprend un espace mémoire non volatile DMEM de taille suffisante pour recevoir un grand nombre de données DTi. Cet espace mémoire peut être réalisé de diverses manières connues, par exemple être constitué d’une mémoire en circuit intégré de type FLASH, EEPROM, ou d’un assemblage de plusieurs mémoires en circuits intégrés sur un support d’interconnexion, ou être constitué d’un ou de plusieurs disques durs, notamment des disques durs magnétiques ou à l’état solide (SSD). L’espace mémoire DMEM est sous le contrôle d’un processeur DPROC assurant la gestion des données DTi qu’il contient, et ayant des droits de lecture et d’écriture de données dans l’espace mémoire DMEM. Les données DTi sont généralement des données d’application ou contextuelles, c'est-à-dire des données générées, modifiées ou effacées par un ou plusieurs programmes applications qui exécutent des tâches diverses. Le système comporte également une mémoire sécurisée SMEM sous le contrôle d’un processeur sécurisé SPROC, lequel possède des droits exclusifs d’accès à la mémoire SMEM en lecture et en écriture. L'accès à la mémoire SMEM peut être contrôlé par des mécanismes d'authentification et d'autorisation, garantissant que seul le processeur SPROC peut y accéder. Dans un mode de réalisation, le processeur sécurisé SPROC est un module de sécurité matérielle ou « HSM » et le processeur DPROC forme un dispositif hôte HDV du module de sécurité matérielle. Le processeur DPROC est relié au processeur SPROC par une liaison de données LK1. La liaison LK1 peut être une liaison au sein d’un réseau local de type LAN (« Local Area Network »), une liaison sur carte mère via un bus PCI (« Peripheral Component InterConnect »), ou autre type de liaison sécurisée. Le système inclut également une entité utilisatrice USR, qui est reliée au processeur DPROC par une liaison de données LK2. L’entité utilisatrice USR peut être un serveur, un ordinateur personnel, un portefeuille matériel de cryptomonnaies tel que la demanderesse en commercialise, utilisé via une application compagnon telle de « Ledger Live ®». La liaison de donnée LK2 est de préférence des liaisons sécurisées https (« Hypertext Transfer Protocol Secure »). Pour une sécurité encore plus forte, la liaison LK2 peut consister dans un canal chiffré de type SCP (« Secure Channel Protocol ») basé sur un échange de clés Diffie-Hellman. L’espace mémoire DMEM contient une base de données ABD (« Application Data Database ») et une base de données TDB (« Merkle Tree Database ») configurée en arbre de Merkle (« Merkle Tree »). La base de données ADB contient les données DTi précitées et la base de données TDB contient des codes de hachage Hi. L’arbre de Merkle est du type dit « clairsemé » (« Sparse Merkle Tree »), c'est-à-dire que sa topologie est préconfigurée et n’évolue pas au fur et à mesure qu’il reçoit des codes de hachage, à partir d’un état initial où il est complètement vide. Toutefois, dans un souci de simplification du langage, on désignera dans ce qui suit « arbre de Merkle » ou « arbre » cet arbre de Merkle clairsemé. Le processeur DPROC exécute un programme AMP de gestion de la base de données ADB (« Application Data Database Management Program ») et un programme TMP de gestion de l'arbre de Merkle (« Merkle Tree Management Program »), en d’autres termes un programme de gestion de la base de données TDB. Les deux programmes agissent en coordination de sorte que les deux bases de données ADB et TDB soient synchronisées d’une manière qui apparaîtra plus loin. Le processeur DPROC exécute également un programme d’interface MDA (« Message Dispatch API ») qui permet à l’entité utilisatrice USR, via la liaison LK2, d’envoyer au processeur SPROC les commandes qui lui parviennent via l’interface PCI ou Ethernet LK1. Dans le processeur SPROC, ces commandes sont reçues par un programme de traitement de messages MPP (« Message Processing Program ») qui les transmet à un programme d’application sécurisé SAP (« Secure Application Program »), les deux programmes étant exécutés par le processeur SPROC. Le programme d’application SAP, représenté schématiquement par un bloc, peut en pratique être chargé dans une mémoire non volatile du processeur SPROC ou être chargé à la volée dans une mémoire externe volatile (RAM) le temps de son exécution. Le programme d’application SAP est configuré pour exécuter les commandes envoyées par l’entité utilisatrice. Au moins certaines de ces commandes peuvent lui demander de générer ou de modifier des données DTi, ou peuvent nécessiter, pour être exécutées, de générer ou de modifier des données DTi. L’entité utilisatrice USR exécute un programme utilisateur UAP (« User Application Program ») qui sollicite le programme d’application SAP du processeur sécurisé pour l’exécution d’opérations conduisant ce dernier, comme on vient de l’indiquer, à générer ou modifier des données DTi. Le programme d’application SAP utilise la base de données ADB pour stocker de telles données, sous une forme chiffrée ou non. Ces données peuvent être renvoyées au programme UAP via le lien LK2 si nécessaire, ou peuvent être modifiées par le programme d’application SAP à partir de paramètres reçus du programme UAP via le lien LK2. Elles sont toutefois ici de la propriété du programme d’application SAP, en ce qui concerne leur lecture et leur écriture. Les données DTi générées ou modifiées par le programme d’application SAP sont stockées dans la base de données ADB de l’espace mémoire DMEM. Dans certains modes de réalisation, elles sont en tout ou en partie stockées dans la base de données ADB sous une forme chiffrée au moyen d’une clé de chiffrement connue uniquement du processeur sécurisé. L’espace mémoire DMEM constitue donc une extension de la mémoire SMEM du processeur SPROC, celle-ci étant insuffisante pour recevoir de telles données. Plus particulièrement, la mémoire SMEM ne stocke ici aucune donnée d’application ou contextuelle DTi et ne reçoit que le code de hachage racine RHm. Il va toutefois de soi que cette mémoire peut contenir d’autres données sensibles, notamment des clés secrètes, qui ne seront pas décrites ici. Un exemple simplifié d’arbre de Merkle est montré sur la FIG. 2 . L’arbre de Merkle comprend des nœuds feuilles LN et des nœuds internes IN s’étendant sur une pluralité de niveaux de l’arbre jusqu’à un nœud sommet TN (« Top Node » appelé également nœud racine (« Root Node »). Dans cet exemple, l'arbre contient huit nœuds feuilles d’index [I1] à [I8], quatre nœuds internes IN de niveau 1 et d’index [I12], [I34], [I56] et [I78], deux nœuds internes IN de niveau 2 et d’index [I14] et [I58], et un nœud sommet TN d’index [I18]. Chaque nœud correspond à un bloc de donnée indexé dans la base de données TDB. La base de données ABD comporte une pluralité d’emplacements LO indexés, chaque emplacement ayant un index déterminé associé à un nœud feuille LN d’index déterminé de la base de données TDB. De préférence, l’index de chaque emplacement LO est choisi identique à l’index du nœud feuille LN auquel il est associé, ce qui permet d’éviter de recourir à une table de correspondance. Ainsi, dans l’exemple représenté, la base de données ABD comporte huit emplacements LO d’index [I1] à [I8]. L’emplacement d’index [I1] est associé au nœud feuille d’index [I1], l’emplacement d’index [I2] est associé au nœud feuille d’index [I2], et ainsi de suite jusqu’à l’emplacement d’index [I8] qui est associé au nœud feuille d’index [I8]. De façon en soi classique, chaque nœud feuille comporte un code de hachage obtenu par hachage de la donnée DTi contenue dans l’emplacement LO auquel il est associé. Dans l’exemple représenté, l’emplacement [I1] (c'est-à-dire l’emplacement d’index [I1]) comprend une donnée DT1 et le nœud feuille [I1] (c'est-à-dire le nœud feuille d’index [I1]) qui lui est associé reçoit un code de hachage H1 égal à H(DT1), « H » étant une fonction de hachage retenue pour construire l'arbre de Merkle. Cette fonction de hachage est, dans un mode de réalisation, la fonction SHA256 (Secure Hash Algorithm), une fonction de hachage cryptographique qui génère, quelle que soit la taille de la donnée d’entrée, un code de hachage de taille fixe de 256 bits (32 octets). De même, l’emplacement [I2] comprend une donnée DT2 et le nœud feuille associé [I2] reçoit un code de hachage H2 égal à H(DT2). L’emplacement [I4] comprend une donnée DT4 et le nœud feuille associé [I4] reçoit un code de hachage H2 égal à H(DT4). L’emplacement [I6] comprend une donnée DT6 et le nœud feuille associé [I6] reçoit un code de hachage H6 égal à H(DT6). Les emplacements [I3], [I5], [I7] et [I8] sont vides, c'est-à-dire n’ont reçu aucune donnée, le symbole d’un emplacement vide étant « ∅ » sur la FIG. 2 . Par convention, les nœuds feuilles [I3], [I5, [I7], [I8] associés à des emplacements vides reçoivent un code de hachage de nœud vide noté H(∅), soit ici H3=H5=H7=H8= H(∅). Chaque nœud interne IN reçoit un code de hachage calculé par hachage d’une chaîne de bits formée par concaténation des codes de hachage présents dans deux nœuds de niveau précédent, ou nœuds enfants, et ce jusqu’au nœud sommet, qui comprend un code de hachage racine RH. Ainsi, dans l’exemple représenté, le nœud [I12] reçoit un code de hachage H12=H(H1|H2), « | » étant le symbole de la concaténation. Le nœud [I34] reçoit un code de hachage H34=H(H3|H4). Le nœud [I56] reçoit un code de hachage H56=H(H5|H6). Le nœud [I78] reçoit un code de hachage H78=H(H7|H8). Le nœud [I14] reçoit un code de hachage H14=H(H12|H34). Le nœud [I58] reçoit un code de hachage H58=H(H56|H78). Le nœud [I18] ou nœud sommet TN reçoit le code de hachage racine RH=H(H14|H58) Le code de hachage de nœud vide H(∅) est une valeur prédéterminée choisie par convention, ainsi que la façon dont il se propage dans l'arbre de Merkle. Dans un mode de réalisation montré sur la FIG. 3 , qui ne représente qu’une partie de l'arbre de Merkle de la FIG. 2 , le code de hachage de nœud vide H(∅) est égal à 0, soit en pratique une chaîne de bit de valeur nulle contenant un nombre de bits égaux à 0, par exemple 256 bits. Le code de hachage d’un nœud parent de deux nœuds vides H(∅), ici le nœud I[78] est également égal à 0 et est de même longueur. Toujours par convention, le code de hachage d’un nœud parent d’un nœud enfant vide et d’un nœud enfant non vide est égal au code de hachage du nœud enfant non vide suivi d’un bit égal à 0 ou à 1 selon que le nœud enfant vide se trouve dans l’arbre de Merkle à droite ou à gauche du nœud enfant non vide, ou vice-versa. Ainsi, dans l’exemple représenté, le code de hachage H78 du nœud [I78] est égal à H(∅) soit 0, car le code de hachage H7 du nœud [I7] est égal à H(∅) et le code de hachage H8 du nœud [I8] est égal à H(∅). Le code de hachage H56 du nœud [I56] est égal à H6|0 soit H(DT6)|0 car le nœud vide [I5] se trouve à gauche du nœud non vide [I6] dont le code de hachage H6 est égal à H(DT6). Le code H56 est de 257 bits si le code de hachage H(DT6) est de 256 bits. Enfin, le code de hachage H58 du nœud [I58] est égal à H56|1 soit H(DT6)|0|1 car le nœud vide [I78] se trouve à droite du nœud non vide [I56]. Ce code fait 258 bits si le code de hachage H(DT6) fait 256 bits. En d’autres termes, la détermination des codes de hachage selon cette convention fait appel à une fonction FH de plus haut niveau que la fonction de hachage H elle-même. On peut formaliser les règles qui viennent d’être décrites avec la notation suivante : H5=FH(∅)=∅ H6=FH(DT6)=H(DT6) H7=FH(∅)=∅ H8=FH(∅)=∅ H56=FH(∅,H6)=H6|0=H(DT6)|0 H78=FH(∅,∅)=∅ H58=FH(H56,∅)=H56|1=H(DT6)|0|1. Dans cette notation, la virgule indique que l’on fait appel à la fonction de plus haut niveau FH. Il sera noté que le terme de « code de hachage » peut donc couvrir la concaténation d’un code de hachage avec un ou plusieurs bits, en raison de la convention retenue, ici la fonction FH. Ainsi, le ce terme ne désigne pas seulement le résultat du hachage d’une donnée. Dans certains cas, comme ceux qui viennent d’être décrits, il désigne seulement le code affecté par convention au nœud considéré. Dans un autre mode de réalisation de l'arbre de Merkle montré sur la FIG. 4 , qui représente la même partie de l'arbre de la FIG. 2 que celle montrée sur la FIG. 3 , le code de hachage de nœud vide H(∅) est égal à 0 mais le code de hachage d’un nœud parent de deux nœuds enfants vides, ici le nœud I[78], est égal à H(0|0) soit le résultat du hachage au moyen de la fonction H de la concaténation des deux codes de hachage nuls, par exemple une chaîne binaire de valeur nulle de 512 bits si chacun des codes de hachage des nœuds enfant est une chaîne binaire de 256 bits de valeur nulle. Le résultat d’un tel hachage d’une chaîne de bit de valeur nulle n’est jamais égal à 0. Toujours par convention, le code de hachage d’un nœud parent d’un nœud enfant vide et d’un nœud enfant non vide est calculé normalement, comme étant le code de hachage d’une chaîne de bits obtenue par concaténation du code de hachage de nœud vide présent dans le nœud enfant vide et du code de hachage présent dans le nœud enfant non vide, si ce dernier se trouve à droite du nœud enfant vide, ou obtenue par concaténation du code de hachage présent dans le nœud enfant non vide et du code de hachage de nœud vide présent dans le nœud enfant vide, si ce dernier se trouve à droite du nœud enfant non vide. Ainsi, dans l’exemple représenté, le code de hachage H56 du nœud [I56] est égal à H(H5|H6) soit H(0|H(DT6)). Le code de hachage H78 du nœud [I78] est égal à H(0|0). Le code de hachage H58 du nœud [I58] est égal à H(H56|H78) soit H(H(0|H(DT6))|H(0|0)). Dans ce cas, tous les codes de hachages font 256 bits si la fonction de hachage utilisée fournit des codes de 256 bits. De façon en soi classique, toute modification de la valeur d’une donnée DTi provoque une modification correspondante du code de hachage contenu dans le nœud feuille qui lui est associé, qui provoque elle-même une modification du code de hachage racine. Une propriété remarquable de l'arbre de Merkle est qu’il est possible de calculer la modification du code de hachage racine sans recalculer l’ensemble des codes de hachage contenu dans l'arbre de Merkle. Il est donc possible de modifier une donnée dans la base de données ADB et de mettre à jour l’arbre de Merkle dans la base de données TDB sans avoir besoin de connaître les codes de hachage contenus par les nœuds de l’arbre non affectés par cette modification. Il est également possible de prouver qu’un code de hachage est intègre et appartient à l’arbre de Merkle, sans avoir besoin de révéler les autres codes de hachage ni l’arbre de Merkle dans son ensemble. Plus précisément, après modification d’une donnée de la base de données, il suffit, pour calculer une nouvelle valeur du code de hachage racine, de calculer les codes de hachages contenus dans les nœuds liés LN au nœud feuille considéré, soit les nœuds se trouvant sur un chemin reliant le nœud feuille considéré au nœud racine. Or, pour calculer les codes de hachage des nœuds liés au nœud feuille considéré, il suffit de connaître les codes de hachage contenus dans les nœuds voisins à ces nœuds liés, formant ensemble ce qu’il est commun d’appeler « preuve de Merkle » MP. A titre d’exemple, la FIG. 5 montre les nœuds liés au nœud feuille [I1] dans l’arbre de Merkle de la FIG. 1 , ici les nœuds [I12] et [I14]. Par ailleurs, les nœuds voisins aux nœuds liés sont ici les nœuds [I2], [I34] et [I58]. Les codes de hachage contenus dans ces nœuds forment ensemble la preuve de Merkle MP pour le nœud feuille [I1]. Ainsi, si la donnée DT1 d’index [1] est connue, et que la preuve de Merkle MP est connue, il est possible de calculer le code de hachage contenu dans le nœud feuille [I1], puis, au moyen de la preuve de Merkle, de calculer le code de hachage contenu dans le nœud [I12], puis le code de hachage contenu dans le nœud [I14] et enfin le code de hachage racine RH. Cette propriété s’applique également à plusieurs nœuds feuilles en même temps, une preuve de Merkle MP pouvant être fournie pour deux nœuds feuilles ou plus. Dans l’exemple de la FIG. 6 , la preuve de Merkle concernant deux nœuds feuilles [I1] et [I6] est mise en évidence par des flèches. On distingue les nœuds [I12], [I14] liés au nœud feuille [I1], notés LN1, et les nœuds feuilles [l78], [I58] liés au nœud feuille [I8], notés LN2. La preuve de Merkle contient ici les codes de hachage des nœuds [I2], [I34], [I7], [I56] et permet de calculer les codes de hachage des nœuds [I12], [I14], [I78], [I58], puis de de calculer le code de hachage racine RH. Dans cet exemple, l’emplacement [I8] de la base de données ABD est vide est le code de hachage contenu dans le nœud feuille [I8] est le code de hachage de nœud vide H(∅) dont la valeur ainsi que sa propagation dans l’arbre de Merkle sont définies par convention, par exemple l’une des deux conventions décrites dans ce qui précède en relation avec les figures 3 et 4. Ainsi, le code de hachage racine du nœud sommet permet non seulement de prouver la valeur d’un nœud non vide mais également de prouver qu’un nœud est vide puisqu’un nœud vide reçoit un code de hachage défini par convention. L’homme du métier notera que ce point est essentiel pour la mise en œuvre du procédé selon la présente divulgation, afin que le processeur sécurisé SPROC soit en mesure de stocker des données qu’il vient de créer dans des emplacements vides de la base de données ADB, et de vérifier préalablement qu’ils sont vides, comme on le verra par la suite. Cette propriété de l'arbre de Merkle est exploitée ici en stockant dans la mémoire SMEM du processeur sécurisé SPROC une valeur RHm du code de hachage racine de l'arbre de Merkle et en vérifiant, à chaque lecture ou avant chaque écriture d’une donnée dans un emplacement cible de la base de données ABD, que le code de hachage racine actuel de l'arbre de Merkle est identique à celui RHm précédemment mémorisé. A cet effet, le programme de gestion AMP de la base de données ABD est configuré pour fournir, en sus de la valeur contenue par l’emplacement considéré, la preuve de Merkle associée à l’emplacement cible, soit la preuve de Merkle du nœud feuille associé à cet emplacement. On décrira maintenant en relation avec les figures 9A, 9B un exemple d’exécution par le processeur SPROC, au moyen du programme d’application SAP, d’une séquence d’instructions visant à écrire une nouvelle donnée dans la base de données ABD. Cet exemple est considéré en relation avec un exemple simplifié de base de données ABD et d’arbre de Merkel montré sur les figures 10 et 11, dans lequel la base de données ne comprend que quatre emplacements d’index [I1], [I2], [I3], [I4]. Sur la FIG. 7 , l’emplacement [I1] de la base de données ADB comprend une donnée « user=bob » tandis que les emplacements [I2], [I3], [I4] sont vides (∅). Dans la base de données TDB, le nœud feuille d’index [I1] contient un code de hachage H1 égal au condensé par la fonction SHA256 de la donnée « user=bob », tandis que les nœuds feuilles d’index [I2], [I3], [I4] contiennent par convention des codes de hachage H2, H3, H4 nuls. Au niveau suivant de l’arbre de Merkle, le nœud feuille d’index [I12] contient un code de hachage H12 égal au condensé par la fonction SHA256 de la concaténation des codes de hachage H1, H2, et le nœud feuille d’index [I34] contient un code de hachage égal au condensé par la fonction SHA256 de la concaténation des codes de hachage H3 et H4. Enfin, le nœud sommet TN contient un code de hachage racine RH égal au condensé par la fonction SHA256 de la concaténation des codes de hachage H12, H34. Sur la FIG. 8 , l’emplacement [I1] de la base de données ADB comprend toujours la donnée « user=bob », tandis que l’emplacement [I2] comprend une donnée « user=alice », les emplacements [I3], [I4] étant de nouveau vides (∅). Dans la base de données TDB, le nœud feuille d’index [I1] contient un code de hachage H1 égal au condensé par la fonction SHA256 de la donnée « user=bob », le nœud feuille d’index [I2] contient un code de hachage H2 égal au condensé par la fonction SHA256 de la donnée « user=alice », tandis que les nœuds feuilles d’index [I3], [I4] contiennent par convention des codes de hachage H3, H4 nuls. Au niveau suivant de l’arbre de Merkle, le nœud feuille d’index [I12] contient un code de hachage H12 égal au condensé par la fonction SHA256 de la concaténation des codes de hachage H1, H2, et le nœud feuille d’index [I34] contient un code de hachage égal au condensé par la fonction SHA256 de la concaténation des codes de hachage H3 et H4. Au sommet de l’arbre de Merkle, le nœud TN contient un code de hachage racine RH égal au condensé par la fonction SHA256 de la concaténation des codes de hachage H12, H34. Les figures 9A, 9B décrivent des étapes exécutées par le système de la FIG. 1 pour ajouter la donnée « user=alice » à la base de données se trouvant dans l’état montré sur la FIG. 7 , afin d’obtenir la base de données dont l’état est montré sur la FIG. 8 . Les entités agissantes sont ici : - le programme TMP de gestion de l'arbre de Merkle, exécuté par le processeur DPROC, - le programme AMP de gestion de la base de données ADB, exécuté par le processeur DPROC, - l’entité utilisatrice USR, exécutant le programme utilisateur UAP, - le processeur SPROC exécutant le programme d’application sécurisé SAP, et - la mémoire sécurisée SMEM. A une étape S10 l’entité utilisatrice USR demande au programme AMP de lui communiquer l’index d’un emplacement non utilisé (index de nœud vide) en lui envoyant une commande du type : get empty index() A une étape S12, le programme AMP fournit l'index [I2] à l’entité utilisatrice USR. A une étape S14, l’entité utilisatrice USR demande au programme TMP de lui communiquer la preuve de Merkle pour l’emplacement d’index [I2], en lui envoyant une commande du type : Get MP([I2]) A une étape S16, le programme TMP fournit la preuve de Merkle à l’entité utilisatrice. Il s’agit ici des codes de hachage présents dans les nœuds [I1] et [I34] : MP=[ Node I1=9fe0ad17617f7c7dada0b94b16fa2ee009f9b61fc195a3f6aea9448de532145a Node I34=f5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b A une étape S18, l’entité utilisatrice USR demande au processeur sécurisé SPROC de créer une donnée à l'emplacement d’index [I2], en lui envoyant une commande du type : create data([I2], MP) A une étape S20, processeur SPROC calcule un code de hachage racine RH1 que l’arbre de Merkle est supposé contenir, à partir de la preuve de Merkel MP : RH1=2613bb239dd614364de3224ee093a36c436c975a18323308303c34dfb2046e57 A cet effet, le processeur SPROC, au moyen du programme d’application SAP : - identifie les nœuds liés au nœud feuille cible d’index [I2], ici le nœud d’index [I12] - détermine un code de hachage que le nœud feuille cible vide d’index [I2] est supposé contenir, en appliquant la convention retenue, par exemple H(∅))=0, - calcule des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir, ici uniquement le nœud d’index [I12], sur la base du code de hachage que le nœud feuille cible est supposé contenir et de la preuve de Merkle, qui contient ici le code de hachage que contient le nœud voisin d’index [I1], - puis calcule le code de hachage racine RH1 sur la base du code de hachage que le nœud feuille cible d’index [I1] est supposé contenir, des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir, ici uniquement le nœud d’index [I12], et de la preuve de Merkle qui contient ici le code de hachage que contient le nœud voisin d’index |I34]. A une étape S22, le processeur SPROC demande à la mémoire SMEM de lui communiquer le code de hachage racine RHm en lui envoyant une commande du type : get RHm A une étape S24, a mémoire SMEM fournit au processeur SPROC le code de hachage racine mémorisé RHm : RHm=2613bb239dd614364de3224ee093a36c436c975a18323308303c34dfb2046e57 A une étape S26, le processeur SPROC vérifie que RH1 et RHm sont égaux, dans la négative retourne un message d’erreur à l’entité utilisatrice USR. Si les deux codes sont égaux, le processeur a la preuve que le nœud d’index [I2] est vide, et continue l’exécution de la commande. A une étape S28, le processeur SPROC crée la donnée user=alice A une étape S30, le processeur SPROC calcule un code de hachage racine RH2 que l’arbre de Merkle contiendra lorsque la base de données ADB aura été mise à jour avec la donnée user=alice à l’emplacement d’index |I2], et que la base de données TDB aura été synchronisée à la base de données ADB : b0280d3d756c53e0a69333103cb5d456db3459bbdab4d6c14e986fa677574249 A cet effet, le processeur SPROC, au moyen du programme d’application SAP : - identifie les nœuds liés au nœud feuille cible d’index [I2], ici le nœud d’index [I12] - détermine un code de hachage que le nœud feuille vide d’index [I2] contiendra, ici H(user=alice), - calcule des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir, ici uniquement le nœud d’index [I12], sur la base du code de hachage que le nœud feuille cible contiendra et de la preuve de Merkle, qui contient ici le code de hachage que contient le nœud voisin d’index [I1], - puis calcule le code de hachage racine RH2 sur la base du code de hachage que le nœud feuille cible d’index [I1] contiendra, des codes de hachage que les nœuds liés au nœud feuille cible contiendront, ici uniquement le nœud d’index [I12], et de la preuve de Merkle qui contient ici le code de hachage que contient le nœud voisin d’index |I34]. A une étape S32, le processeur SPROC sauvegarde le nouveau code de hachage racine dans la mémoire SMEM au moyen d’une commande du type : set RHm=RH2 A une étape S34 la mémoire SMEM confirme que le code de hachage racine a été enregistré en envoyant un message « OK ». A une étape S36, le processeur SPROC envoie à l’entité utilisatrice USR la nouvelle donnée accompagnée de son index : ([I2], "user=alice") A une étape S38, l’entité utilisatrice USR demande au programme AMP de sauvegarder la nouvelle donnée à l'emplacement cible d’index [I2] , en lui envoyant une commande du type : set data([I2], "user=alice") A une étape S40, le programme AMP de gestion de la base de données ADB confirme l’enregistrement en renvoyant un message « OK ». A une étape S42, l’entité utilisatrice USR demande au programme TMP de mettre à jour l'arbre de Merkle dans la base de données ADB, en lui envoyant une commande du type : update merkletree([I2], "user=alice") Cette étape est conduite par le programme TMP du processeur DPROC selon des étapes similaires à celle de l’étape S30 conduite par le processeur sécurisé, à ceci près que le programme TMP modifie ici les vraies données qui se trouvent dans l’arbre de Merkle stocké dans la base de données TDB de la mémoire DMEM, et pas seulement celles qui seront supposées s’y trouver. Après cette étape, l’arbre de Merkle stocké dans la base de données TDB contient donc les valeurs montrées sur la FIG. 8 . A une étape S44, le programme TMP confirme la mise à jour de l’arbre en renvoyant un message « OK ». Sur la FIG. 10 , la base de données ADB a été modifiée une nouvelle fois. L’emplacement [I1] comprend toujours la donnée « user=bob » mais dans l’emplacement [I2], la donnée « user=alice » a été remplacée par la donnée « user=eve ». Par ailleurs, les emplacements [I3], [I4] restent vides (∅). Dans la base de données TDB, le nœud feuille d’index [I1] contient un code de hachage H1 égal au condensé par la fonction SHA256 de la donnée « user=bob », le nœud feuille d’index [I2] contient un code de hachage H2 égal au condensé par la fonction SHA256 de la donnée « user=eve », tandis que les nœuds feuilles d’index [I3], [I4] contiennent par convention des codes de hachage H3, H4 nuls. Au niveau suivant de l’arbre de Merkle, le nœud feuille d’index [I12] contient un code de hachage H12 égal au condensé par la fonction SHA256 de la concaténation des codes de hachage H1, H2, et le nœud feuille d’index [I34] contient un code de hachage égal au condensé par la fonction SHA256 de la concaténation des codes de hachage H3 et H4. Au sommet de l’arbre, le nœud sommet TN contient un code de hachage racine RH égal au condensé par la fonction SHA256 de la concaténation des codes de hachage H12, H34. Les figures 11A, 11B décrivent des étapes exécutées par le système de la FIG. 1 pour remplacer la donnée « user=alice » par la donnée « user=eve ». A une étape S50, l’entité utilisatrice USR demande au programme AMP de lui fournir la donnée présente à l’emplacement d’index [I2], en lui envoyant une commande du type : get data([I2]) A une étape S52, le programme AMP fournit à l’entité utilisatrice USR de la donnée "user=alice" d’index [I2] : ([I2], "user=alice") A une étape S54, l’entité utilisatrice USR demande au programme TMP de lui fournir la preuve de Merkle pour l’emplacement d’index ([I2] contenant la donnée « user=alice », en lui envoyant une commande du type : Get MP([I2]) A une étape S56, le programme TMP fournit la preuve de Merkle à l’entité utilisatrice. Il s’agit comme précédemment des codes de hachage présents dans les nœuds [I1] et [I34] : MP=[ NodeI1=9fe0ad17617f7c7dada0b94b16fa2ee009f9b61fc195a3f6aea9448de532145a Node I34=f5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b, A une étape S58, l’entité utilisatrice demande au processeur SPROC de modifier la donnée « user=alice » et lui fournit à cet effet la donnée, son index [I2] et la preuve de Merkel correspondante, en lui envoyant une commande du type : modify data([I2], "user=alice", MP) A une étape S60, le processeur SPROC calcule le code de hachage racine RH1 que l’arbre de Merkle est supposé contenir à partir de la preuve de Merkel MP et de la donnée « user=alice » : RH1=b0280d3d756c53e0a69333103cb5d456db3459bbdab4d6c14e986fa677574249 A cet effet, le processeur SPROC applique la même méthode que celle décrite plus haut en relation avec l’étape S20, avec ici le code de hachage du nœud feuille cible d’index [I2] égal à H(user=alice). A une étape S62 processeur SPROC demande à la mémoire SMEM de lui communiquer le code de hachage racine RHm en lui envoyant une commande du type : get RHm A une étape S64, la mémoire SMEM lui fournit le code de hachage racine mémorisé RHm : RHm=b0280d3d756c53e0a69333103cb5d456db3459bbdab4d6c14e986fa677574249 A une étape S66, le processeur SPROC détermine si RH1 est égal à RHm, dans la négative le processeur SPROC retourne un message d’erreur à l’entité utilisatrice USR, sinon continue d’exécuter la commande. A une étape S68, le processeur SPROC modifie la donnée: "user=eve" A une étape S70, le processeur SPROC calcule le code de hachage racine RH2 que l’arbre de Merkle contiendra lorsque la base de données ADB aura été mise à jour avec la donnée user=eve à l’emplacement d’index |I2], et que la base de données TDB aura été synchronisée à la base de données ADB : ab2d731487f9c5dd12ba0d58c6698fe7ec1675ca62a2cdd6c94d8ee2c7aff359 A cet effet, le processeur SPROC applique la même méthode que celle décrite plus haut en relation avec l’étape S30, avec ici le code de hachage du nœud feuille cible d’index [I2] égal à H(user=eve). A une étape S72, le processeur SPROC sauvegarde le nouveau code de hachage racine dans la mémoire SMEM, au moyen d’une commande du type : set RHm=RH2 A une étape S74, la mémoire confirme l’enregistrement du code de hachage racine en renvoyant un message « OK ». A une étape S76, le processeur SPROC envoie à l’entité utilisatrice USR la donnée modifiée ([I2], "user=eve"). A une étape S78, l’entité utilisatrice USR demande au programme AMP de sauvegarder la donnée modifiée en lui envoyant une commande du type : set data([I2], “user=eve") A une étape S80, le programme AMP confirme l’enregistrement de la donnée en renvoyant un message « OK ». A une étape S82, l’entité utilisatrice USR demande au programme TMP de mettre à jour l'arbre de Merkle en fonction de la nouvelle donnée, en lui envoyant une commande du type : update merkletree([I2], "user=eve") Après cette étape, conduite comme l’étape S42, l’arbre de Merkle contient les valeurs montrées sur la FIG. 10 . A une étape S84, le programme TMP confirme la mise à jour de l’arbre de Merkle en renvoyant un message « OK ». Bien que la description qui précède se fonde sur des exemples simplifiés d’arbre de Merkle, des modes de réalisation de l’invention susceptibles d’être mis en œuvre utilisent un arbre de Merkle de très grande taille. Par exemple, un arbre de Merkle de 256 niveaux contient 2 256 nœuds feuilles, ce qui permet de prévoir une base de données correspondante ayant 2 256 emplacements de données, soit un nombre quasi infini d’emplacements pouvant recevoir chacun un bloc de données. Par ailleurs, la taille de chaque emplacement peut être variable et chaque emplacement peut recevoir toutes sortes de données, blocs de données ou « objets » de tailles différentes, puisque la fonction de hachage utilisée fournit toujours des codes de hachage de même taille (256 bits avec SHA256). En pratique, la gestion d’un arbre de Merkle de très grande taille ne nécessite que peu de ressources de calcul lorsque celui-ci est majoritairement vide, et contient de ce fait un très grand nombre de nœuds feuilles comprenant le code de hachage de nœud vide H(∅) égal à 0, ainsi qu’un grand nombre de nœuds parents comprenant un code de hachage de nœud vide H(∅) égal à 0 conformément à la convention illustrée sur la FIG. 3 ou 4, ou un code de hachage ayant toujours la même valeur tel que H(0|0) conformément à la convention illustrée sur la FIG. 4 . Dans ce cas, il n’est pas nécessaire que le code de hachage contenu dans chacun de ces nœuds soit calculé puisque sa valeur est prédéterminée. Une gestion simplifiée de l’arbre de Merkle consiste donc à mémoriser, pour chaque niveau de l’arbre de Merkle, le code de hachage attribué à des nœuds parents de deux nœuds recevant le code de hachage de nœud vide, puisque celui-ci est invariable. En ce qui concerne les nœuds parents d’un nœud enfant recevant un code de hachage non nul et d’un nœud enfant recevant le code de hachage de nœud vide, il suffit, par exemple si la convention illustrée en FIG. 3 est retenue, de recopier la valeur du code de hachage non nul du premier nœud enfant et d’y ajouter un bit égal à 0 ou à 1 selon que le second nœud enfant se trouve à droit ou à gauche du premier nœud enfant. Le fait que la base de données ADB puisse être de très grande taille n’affecte aucunement sa sécurité car le code de hachage racine est une preuve cryptographique de l’authenticité de l’ensemble de la base de données quelle que soit sa taille, et garantit un non-retour en arrière. En effet, la modification d’un seul bit de n’importe quelle donnée de la base de données provoque un changement du code de hachage racine. Le procédé selon la présente divulgation offre l’avantage de permettre la mise en œuvre d’un stockage illimité en taille et en nombre de données, une donnée pouvant consister dans un bloc de données ou en un fichier, sans compromettre la sécurité par rapport à un stockage interne à un HSM. Un autre avantage du procédé devant les procédés à base de compteurs monotones est la vérification triviale et instantanée de la synchronisation du code de hachage racine RHm détenu par le processeur sécurisé avec celui de l’arbre de Merkel stocké dans l’espace mémoire externe. Inversement, lorsque les données à mémoriser sont associées chacune à un compteur monotone, il convient de vérifier la validité des données l’une après l’autre en les communiquant au processeur sécurisé. Encore un autre avantage du procédé est qu’il est facile de s’assurer de l’intégrité de l’ensemble de la base de données externe, sans solliciter le processeur sécurisé. Il suffit pour cela de recalculer chaque nœud de l’arbre de Merkel, puis de vérifier que l’on retrouve le même code de hachage racine. Cette vérification peut être faite par le processeur DPROC sans faire appel au processeur sécurisé, ce qui n’est pas possible avec les procédés à base de compteurs monotones, qui nécessitent d’envoyer chaque donnée au processeur sécurisé pour qu’il vérifie sa signature à l’aide de sa clé privée. Ces avantages permettent de mettre en place des solutions de surveillance de la base de données (« monitoring ») et d’être alerté le plus vite possible en cas de corruption d’une donnée de la base de données externe, et cela sans solliciter le processeur sécurisé. Il est donc possible de détecter une erreur sur une donnée dans la base de données ADB sans attendre que le processeur sécurisé ait besoin de cette donnée, ce qui conduirait à détecter l’erreur trop tard. Il apparaîtra clairement à l’homme de l’art que le procédé qui vient d’être décrit est susceptible de nombreuses variantes. Le procédé peut être mis en œuvre avec tout type de base de données connue, notamment une base de données clé-valeur ou une base de données relationnelle (base de données SQL). Bien que l’on ait indiqué dans ce qui précède que le procédé fait intervenir deux bases de données ADB, TDB, la notion de « deux bases de données » doit être comprise au sens large. En effet, en pratique la base de données TDB de l’arbre de Merkle et la base de données ABD des données d’application peuvent prendre la forme de deux tables différentes dans une même base de données. Egalement, bien que l’on ait indiqué dans ce qui précède que chaque emplacement de la base de données ADB correspond à un nœud feuille de l’arbre de Merkle, l’usage d’une table de correspondance dynamique pourrait être prévu par lequel des emplacements de la base de données ADB ne sont initialement pas liés à des nœuds feuilles de la base de données TDB, ce lien étant créé de façon dynamique en fonction du besoin. Dans ce cas, chaque emplacement de la base de données ADB n’est pas systématiquement associé à un nœud feuille de l’arbre de Merkle, mais peut être associé à un nœud feuille lorsque cela est nécessaire. Dans ce cas toujours, le code de hachage de nœud vide H(∅) pourrait être attribué aux nœuds feuilles non affectés à un emplacement de la base de données ADB, en sus d’être attribué aux nœuds feuilles affectés à un emplacement vide de la base de données ADB ou à un emplacement ayant été effacé. Dans certaines applications, le même arbre de Merkle peut être utilisé pour sécuriser plusieurs bases de données ou plusieurs tables différentes d’une même base de données, chaque table ou base de données étant par exemple attribuée à une personne déterminée. Dans ce cas, vu sous l’angle de l’une de ces bases de données, le nombre de nœuds feuilles que contient l’arbre de Merkle peut être très supérieur au nombre d’emplacements de la base de données. Inversement, un arbre de Merkle comprenant un nombre de nœuds de feuilles inférieurs au nombre d’emplacements de la base de données ADB pourrait être prévu, si la base de données contient un mélange de données sensibles et de données non sensibles. Dans ce cas, seuls les emplacements recevant des données sensibles sont associés à des nœuds feuilles de l’arbre de Merkle. En définitive, il ressort de ces divers exemple que le nombre de nœuds feuilles de l’arbre de Merkle ne correspond pas nécessairement au nombre d’emplacements de la base de données ou d’une base de données qui utilise cet arbre de Merkle pour sécuriser les données qu'elle contient. De même, le caractère « effacé » d’un emplacement de la base de données ADB peut varier selon le type de base de données et les conventions utilisées. Ce caractère « effacé » peut se traduire par une absence d’index pour cet emplacement dans la base de données ADB et dans ce cas ne correspond à aucune valeur binaire, même si en pratique le bloc de données correspondant peut contenir une donnée. Dans ce cas, le processeur DPROC fournit uniquement le code de hachage de nœud vide H(∅) et la preuve de Merkle au processeur sécurisé SPROC, en réponse à une requête en lecture. Dans d’autres modes de réalisation, le caractère effacé peut se traduire par la présence d’un bit ou drapeau (« flag ») à 1 ou à 0 dans la donnée. Dans ce cas, la donnée peut être fournie au processeur SPROC avec la preuve de Merkle. Le processeur sécurisé SPROC déduit de l’examen du drapeau qu’il s’agit d’une donnée effacée, d’où il vient que le nœud feuille correspondant reçoit le code de hachage de nœud vide. Enfin, comme on l’a indiqué précédemment, le fait que chaque nœud feuille reçoive un code de hachage de la donnée présente dans l’emplacement (LO) auquel il est associé ou un code de hachage de nœud vide (H(∅)), ne signifie pas que tous les blocs de données qui forment la base de données TDB contiennent des codes de hachage. Comme on l'a indiqué plus haut, comme le code de hachage de nœud vide est connu par convention, ainsi que les codes issus de sa propagation dans l’arbre de Merkle, il n’est pas nécessaire de renseigner la base de données TDB avec ces valeurs et d’occuper de l’espace mémoire inutilement. Il suffit de mémoriser une seule fois les valeurs des codes de hachage qui sont invariables pour chaque niveau de l’arbre de Merkle, et le programme TMP de gestion de l'arbre de Merkle utilise ces valeurs prédéfinies lorsqu'il en a besoin, pour fournir la preuve de Merkle. Le procédé qui vient d’être décrit est également susceptible de nombreuses applications. Dans une application, il permet de mettre en œuvre une gestion par un HSM de données affectées à des comptes de cryptoactifs. Ces données peuvent inclure des noms d’utilisateurs, des adresses d’utilisateurs, des données diverses relatives à ces utilisateurs (photos, pièces d’identité numérisées…), des droits de ces utilisateurs sur des comptes de cryptoactifs et/ou, dans le cadre d’une gestion mutualisée de comptes de cryptoactifs, des statuts de ces utilisateurs à l’égard de tels comptes de cryptoactifs (administrateur, gestionnaire de compte, titulaire de compte, etc.), des clés secrètes de tels comptes de cryptoactifs, etc. Procédé pour l’exécution d’un programme d’application au moyen d’un processeur sécurisé (SPROC, HSM) équipé d’une mémoire non volatile sécurisée (SMEM), l’exécution du programme d’application comprenant des étapes de création et de modification par le processeur sécurisé de données (DTi) nécessaires à l’exécution du programme d’application, procédé caractérisé en ce qu’il comprend les étapes consistant à : - prévoir un espace mémoire non volatile (DMEM) présentant une capacité de stockage suffisante pour stocker les données nécessaires à l'exécution du programme d’application, - prévoir dans l’espace mémoire non volatile une première base de données (ADB) indexée et stocker les données dans la première base de données (ADB), la première base de données comprenant une pluralité d’emplacements identifiables chacun par un index, chaque emplacement pouvant recevoir une donnée, - prévoir dans l’espace mémoire non volatile une seconde base de données (TDB) associée à la première base de données (ADB) et configurée pour former un arbre de Merkle clairsemé comprenant des nœuds feuilles et des nœuds internes s’étendant sur une pluralité de niveaux de l’arbre jusqu’à un nœud sommet (TN), chaque emplacement de la première base de données (ADB) pouvant être associé à un nœud feuille, chaque nœud feuille recevant un code de hachage de la donnée présente dans l’emplacement (LO) auquel il est associé ou un code de hachage de nœud vide (H(∅)), chaque nœud de niveau supérieur recevant un code de hachage calculé à partir de la concaténation des codes de hachage présents dans deux nœuds de niveau précédent, jusqu’au nœud sommet, le nœud sommet comprenant un code de hachage racine (RH), - prévoir au moins un processeur de gestion (DPROC) pour gérer les première et seconde bases de données, - au moyen du processeur de gestion, lire (S52) dans la première base de données (ADB) ou stocker (S38, S78) dans la première base de données des données créées ou modifiées par le processeur sécurisé, et mettre à jour (S42, S82) la seconde base de données (TDB) après chaque modification du contenu de la première base de données (ADB), pour que son état actuel reflète l’état actuel de la première base de données (ADB), - au moyen du processeur sécurisé, calculer ou déterminer (S30, S70) puis stocker (S32, S72) dans la mémoire non volatile sécurisée (SMEM) un code de hachage racine (RHm) de l’arbre de Merkle représentatif de l’état actuel de la seconde base de données (TDB), et mettre à jour (S72) le code de hachage racine mémorisé (RHm) avant ou après chaque enregistrement (S78) d’au moins une nouvelle donnée dans la première base de données par le processeur de gestion. Procédé selon la revendication 1, comprenant, lorsqu’une donnée est lue par le processeur de gestion dans un emplacement cible de la première base de données (ADB), les étapes consistant à : - au moyen du processeur de gestion, fournir (S16, S56) au processeur sécurisé la preuve de Merkle d’un nœud feuille cible associé à l’emplacement cible, et - au moyen du processeur sécurisé : - calculer ou déterminer (S20, S60) un premier code de hachage racine (RH1) de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données (TDB), - comparer (S26, S66) le premier code de hachage racine (RH1) au code de hachage racine (RHm) mémorisé dans la mémoire non volatile sécurisée (SMEM), et - considérer la donnée comme valide si le premier code de hachage racine (RH1) est égal au code de hachage racine mémorisé (RHm). Procédé selon la revendication 2 comprenant, lorsqu’au moins une nouvelle donnée doit être générée par le processeur sécurisé puis stockée dans un emplacement cible de la première base de données (ADB), les étapes consistant à : - au moyen du processeur de gestion, fournir (S16, S56) au processeur sécurisé, la preuve de Merkle d’un nœud feuille cible associé à l’emplacement cible, et une donnée se trouvant dans l’emplacement cible ou une indication que l’emplacement est vide, - au moyen du processeur sécurisé : - calculer ou déterminer (S20, S60) un premier code de hachage racine (RH1) de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données (TDB), et - comparer (S26, S66) le premier code de hachage racine (RH1) au code de hachage racine (RHm) mémorisé dans la mémoire non volatile sécurisée (SMEM), - si le premier code de hachage racine (RH1) est identique au code de hachage racine mémorisé (RHm) : - générer (S28, S68) la nouvelle donnée, - calculer ou déterminer (S30, S70) un second code de hachage racine (RH2) de l’arbre de Merkle fondé sur l’état dans lequel sera la seconde base de données après enregistrement de la nouvelle donnée dans la première base de données (ADB) et mise à jour de la seconde base de données, et - stocker (S32, S72) le second code de hachage racine (RH2) dans la mémoire non volatile sécurisée (SMEM), en remplacement du code de hachage racine anciennement mémorisé (RHm), - au moyen du processeur de gestion, mettre à jour (S38, S78, S42, S82) la première et la seconde base de données sur la base de la nouvelle donnée. Procédé selon la revendication 3, dans lequel le calcul ou la détermination (S30, S70) par le processeur sécurisé du second code de hachage racine (RH2) comprend les étapes consistant à : - identifier des nœuds liés au nœud feuille cible, les nœuds liés se trouvant sur un chemin reliant le nœud feuille cible au nœud sommet (TN), -sur la base de la nouvelle donnée, calculer ou déterminer un nouveau code de hachage que le nœud feuille cible contiendra, - sur la base du nouveau code de hachage que le nœud feuille cible contiendra et de la preuve de Merkle, calculer ou déterminer des codes de hachage que les nœuds liés au nœud feuille cible contiendront, - calculer ou déterminer le second code de hachage racine (RH2) sur la base du nouveau code de hachage que le nœud feuille cible contiendra, de la preuve de Merkle et des nouveaux codes de hachage que les nœuds liés au nœud feuille cible contiendront. Procédé selon l’une des revendications 2 à 4, dans lequel le calcul ou la détermination (S20, S60) par le processeur sécurisé du premier code de hachage racine (RH1) comprend les étapes consistant à : - identifier des nœuds liés au nœud feuille cible, les nœuds liés se trouvant sur un chemin reliant le nœud feuille cible au nœud sommet, - calculer ou déterminer un code de hachage que le nœud feuille cible est supposé contenir, - sur la base du code de hachage que le nœud feuille cible est supposé contenir et de la preuve de Merkle, calculer ou déterminer des codes de hachage que des nœuds liés au nœud feuille cible sont supposés contenir, - calculer ou déterminer le premier code de hachage racine (RH1) sur la base du code de hachage que le nœud feuille cible est supposé contenir, de la preuve de Merkle et des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir. Procédé selon l’une des revendications 1 à 5, dans lequel : - un nœud feuille vide est un nœud associé à un emplacement vide de la base de données, et - un nœud feuille vide contient par convention un code de hachage de nœud vide (H(∅)) de valeur prédéterminée. Procédé selon la revendication 6, dans lequel le code de hachage de nœud vide (H(∅)) est égal à zéro. Procédé selon l’une des revendications 6 et 7, dans lequel un nœud parent de deux nœuds vides est un nœud vide contenant par convention le code de hachage de nœud vide (H(∅)). Procédé selon l’une des revendications 6 à 8, dans lequel un nœud parent d’un nœud vide et d’un nœud non vide contient par convention un code de hachage présent dans le nœud non vide suivi d’un bit égal à 0 ou à 1 selon que le nœud feuille vide se trouve dans l’arbre de Merkle à droite ou à gauche du nœud feuille non vide, ou vice-versa. Procédé selon l’une des revendications 6 et 7, dans lequel un nœud parent de deux nœuds feuilles vides contient par convention un code de hachage égal au résultat du hachage de la concaténation des codes de hachage de nœud vide contenus par chacun des deux nœuds feuilles vides. Procédé selon l’une des revendications 1 à 10, dans lequel le processeur sécurisé ne stocke que le code de hachage racine dans la mémoire non volatile sécurisée (SMEM), et aucune autre donnée de la première ou de la seconde base de données (TDB). Procédé selon l’une des revendications 1 à 11, dans lequel le processeur de gestion stocke dans la seconde base de données (TDB) au moins tous les codes de hachage contenus dans des nœuds non vides de l’arbre de Merkle. Procédé selon l’une des revendications 1 à 12, comprenant la prévision d’une entité utilisatrice (USR) interposée opérationnellement entre le processeur de gestion et le processeur sécurisé, et les étapes consistant à, au moyen de l’entité utilisatrice, recevoir des données fournies par le processeur de gestion et les transférer au processeur sécurisé, ou recevoir des données fournies par le processeur sécurisé et les transférer au processeur de gestion. Procédé selon l’une des revendications 1 à 13, dans lequel les données sont des données affectées à des titulaires de comptes de cryptoactifs. Système sécurisé comprenant un module de sécurité matérielle (SPROC, HSM) équipé d’une mémoire sécurisée (SMEM) et configuré pour exécuter au moins un programme d’application, dans lequel l’exécution du programme d’application comprend des étapes de création et de modification par le module de sécurité matérielle de données (DTi) nécessaires à l’exécution du programme d’application, système caractérisé en ce qu’il comprend : - un espace mémoire non volatile (DMEM) comprenant : - une première base de données (ADB) indexée comprenant une pluralité d’emplacements identifiables chacun par un index, chaque emplacement pouvant recevoir une donnée, - une seconde base de données (TDB) associée à la première base de données (ADB) et configurée pour former un arbre de Merkle clairsemé comprenant des nœuds feuilles et des nœuds internes s’étendant sur une pluralité de niveaux de l’arbre jusqu’à un nœud sommet (TN), chaque emplacement de la première base de données (ADB) pouvant être associé à un nœud feuille, chaque nœud feuille recevant un code de hachage de la donnée présente dans l’emplacement (LO) auquel il est associé ou un code de hachage de nœud vide (H(∅)), chaque nœud de niveau supérieur recevant un code de hachage calculé à partir de la concaténation des codes de hachage présents dans deux nœuds de niveau précédent, jusqu’au nœud sommet (TN), le nœud sommet (TN) comprenant un code de hachage racine, - au moins un processeur de gestion (DPROC) pour gérer les première et seconde bases de données, et dans lequel : - le processeur de gestion est configuré pour lire (S52) dans la première base de données (ADB) ou stocker (S38, S78) dans la première base de données des données créées ou modifiées par le module de sécurité matérielle, et mettre à jour (S42, S82) la seconde base de données (TDB) après chaque modification du contenu de la première base de données (ADB), pour que son état actuel reflète l’état actuel de la première base de données (ADB), - le module de sécurité matérielle est configuré pour calculer ou déterminer (S30, S70) puis stocker (S32, S72) dans la mémoire non volatile sécurisée (SMEM) un code de hachage racine (RHm) de l’arbre de Merkle représentatif de l’état actuel de la seconde base de données, et mettre à jour (S72) le code de hachage racine mémorisé (RHm) avant ou après chaque enregistrement (S78) d’au moins une nouvelle donnée dans la première base de données par le processeur de gestion. Système selon la revendication 15, dans lequel, lorsqu’une donnée est lue par le processeur de gestion dans un emplacement cible de la première base de données (ADB), le processeur de gestion est configuré pour fournir (S16, S56) au module de sécurité matérielle la preuve de Merkle d’un nœud feuille cible associé à l’emplacement cible, et le module de sécurité matérielle est configuré pour : - calculer ou déterminer (S20, S60) un premier code de hachage racine (RH1) de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données (TDB), - comparer (S26, S66) le premier code de hachage racine (RH1) au code de hachage racine (RHm) mémorisé dans la mémoire non volatile sécurisée (SMEM), et - considérer la donnée comme valide si le premier code de hachage racine (RH1) est égal au code de hachage racine mémorisé (RHm). Système selon la revendication 16, dans lequel lorsqu’au moins une nouvelle donnée doit être générée par le module de sécurité matérielle puis stockée dans un emplacement cible de la première base de données (ADB), le processeur de gestion est configuré pour fournir (S16, S56) au module de sécurité matérielle, la preuve de Merkle d’un nœud feuille cible associé à l’emplacement cible, et une donnée se trouvant dans l’emplacement cible ou une indication que l’emplacement est vide, et le module de sécurité matérielle est configuré pour : - calculer ou déterminer (S20, S60) un premier code de hachage racine (RH1) de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données (TDB), et - comparer (S26, S66) le premier code de hachage racine (RH1) au code de hachage racine (RHm) mémorisé dans la mémoire non volatile sécurisée (SMEM), - si le premier code de hachage racine (RH1) est identique au code de hachage racine mémorisé (RHm) : - générer (S28, S68) la nouvelle donnée, - calculer ou déterminer (S30, S70) un second code de hachage racine (RH2) de l’arbre de Merkle fondé sur l’état dans lequel sera la seconde base de données après enregistrement de la nouvelle donnée dans la première base de données (ADB) et mise à jour de la seconde base de données, et - stocker (S32, S72) le second code de hachage racine (RH2) dans la mémoire non volatile sécurisée (SMEM), en remplacement du code de hachage racine anciennement mémorisé (RHm), - le processeur de gestion étant également configuré pour mettre à jour (S38, S78, S42, S82) la première et la seconde base de données sur la base de la nouvelle donnée. Système selon la revendication 17, dans lequel pour calculer ou déterminer (S30, S70) le second code de hachage racine (RH2), le module de sécurité matérielle est configuré pour : - identifier des nœuds liés au nœud feuille cible, les nœuds liés se trouvant sur un chemin reliant le nœud feuille cible au nœud sommet (TN), -sur la base de la nouvelle donnée, calculer ou déterminer un nouveau code de hachage que le nœud feuille cible contiendra, - sur la base du nouveau code de hachage que le nœud feuille cible contiendra et de la preuve de Merkle, calculer ou déterminer des codes de hachage que les nœuds liés au nœud feuille cible contiendront, - calculer ou déterminer le second code de hachage racine (RH2) sur la base du nouveau code de hachage que le nœud feuille cible contiendra, de la preuve de Merkle et des nouveaux codes de hachage que les nœuds liés au nœud feuille cible contiendront. Système selon l’une des revendications 16 à 18, dans lequel pour calculer ou déterminer le premier code de hachage racine (RH1), le module de sécurité matérielle est configuré pour : - identifier des nœuds liés au nœud feuille cible, les nœuds liés se trouvant sur un chemin reliant le nœud feuille cible au nœud sommet, - calculer ou déterminer un code de hachage que le nœud feuille cible est supposé contenir, - sur la base du code de hachage que le nœud feuille cible est supposé contenir et de la preuve de Merkle, calculer ou déterminer des codes de hachage que des nœuds liés au nœud feuille cible sont supposés contenir, - calculer ou déterminer le premier code de hachage racine (RH1) sur la base du code de hachage que le nœud feuille cible est supposé contenir, de la preuve de Merkle et des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir. Système selon l’une des revendications 15 à 19, dans lequel le module de sécurité matérielle ne stocke que le code de hachage racine dans la mémoire non volatile sécurisée (SMEM), et aucune autre donnée de la première ou de la seconde base de données (TDB). Système selon l’une des revendications 15 à 19, dans lequel le processeur de gestion stocke dans la seconde base de données (TDB) au moins tous les codes de hachage contenus dans des nœuds non vides de l’arbre de Merkle. Système selon l’une des revendications 15 à 21, comprenant une entité utilisatrice (USR) interposée opérationnellement entre le processeur de gestion (DPROC) et le module de sécurité matérielle (SPROC), et dans lequel des données fournies par le processeur de gestion à l’attention du processeur sécurisé sont reçues par l’entité utilisatrice qui les fournit au processeur sécurisé et réciproquement.