FR 3164300 A1 20260109 FR 2503796 A 20250409 Procédé pour sécuriser des données mémorisées dans un espace mémoire non volatile (DMEM), comprenant : prévoir dans l’espace mémoire une première base de données indexée (ADB) et une seconde base de données indexée (TDB) configurée pour former un arbre de Merkle clairsemé ; 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, 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, et l'utiliser pour vérifier la validité de données lues dans la première base de données. Figure 1 Procédé pour sécuriser des données stockées dans un espace mémoire non volatile. La présente invention concerne un procédé pour sécuriser des données mémorisées dans un espace mémoire non volatile et un système de stockage de données. La présente invention concerne également 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 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é 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 étant associée à 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 fonction 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 ; 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 ; stocker dans une 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, et 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. 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, on ne stocke que le code de hachage racine dans la mémoire non volatile sécurisée, et aucune donnée de la première ou de la seconde base de données. Selon un mode de réalisation, on 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 les étapes consistant à : prévoir au moins un premier processeur pour gérer la première et la seconde base de données, et prévoir un second processeur de type sécurisé pour gérer la mémoire non volatile sécurisée. Selon un mode de réalisation, on exécute au moyen du second processeur les étapes de calcul du premier code de hachage racine et de comparaison du premier code de hachage racine au code de hachage racine mémorisé dans la mémoire non volatile sécurisée. Selon un mode de réalisation, lorsqu’une nouvelle donnée doit être stockée dans un emplacement cible de la première base de données, on fournit au second processeur au moyen du premier processeur un index du nœud feuille cible correspondant à l’emplacement cible, une donnée contenue dans cet emplacement ou une indication selon laquelle l’emplacement est vide, et la preuve de Merkle correspondante. Des modes de réalisation concernent également un système de stockage de données comprenant : un espace mémoire non volatile comprenant une première base de données indexée dans laquelle sont stockées les 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, 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é 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 étant associée à 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 fonction 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 ; une mémoire non volatile sécurisée, dans laquelle est stocké un code de hachage racine de l’arbre de Merkle représentatif de l’état actuel de la seconde base de données. Le système est configuré pour, 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, et lorsqu’une donnée doit être lue dans la première base de données, pour : 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 système est configuré pour, lorsqu’une donnée doit être stockée dans un emplacement cible de la première base de données : 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, le système est configuré pour conduire de la façon suivante 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 : 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, le système est configuré pour conduire de la façon suivante 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 : 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. Selon un mode de réalisation, la mémoire non volatile sécurisée ne stocke que le code de hachage racine et aucune donnée de la première ou de la seconde base de données. Selon un mode de réalisation, la seconde base de données stocke 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 au moins un premier processeur pour gérer la première et la seconde base de données, un second processeur de type sécurisé pour gérer la mémoire non volatile sécurisée, la mémoire non volatile sécurisée n’étant pas accessible en lecture ou écriture au premier processeur. Selon un mode de réalisation, le système est configuré pour exécuter au moyen du second processeur les étapes 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, et de comparaison du premier code de hachage racine au code de hachage racine mémorisé dans la mémoire non volatile sécurisée. Selon un mode de réalisation, le système est configuré pour que, lorsqu’une nouvelle donnée doit être stockée dans un emplacement cible de la première base de données, le premier processeur fournisse à l’attention du second processeur un index du nœud feuille cible correspondant à l’emplacement cible, une donnée contenue dans cet emplacement ou une indication selon laquelle l’emplacement est vide, et la preuve de Merkle correspondante. Selon un mode de réalisation, le système comprend une entité utilisatrice interposée opérationnellement entre le premier et le second processeur, les données fournies par le second processeur à l’attention du premier processeur étant reçues par l’entité utilisatrice qui les fournit au premier processeur. 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 est un organigramme décrivant des étapes de sécurisation de la lecture d’une donnée dans le système de la FIG. 1 , selon un mode de réalisation du procédé, - la FIG. 8 est un organigramme décrivant des étapes de sécurisation de l’écriture d’une donnée dans le système de la FIG. 1 , selon un mode de réalisation du procédé, - la FIG. 9 montre un second exemple d’architecture de système de stockage de données mettant en œuvre un autre mode de réalisation du procédé, - la FIG. 10 montre un exemple simplifié d’arbre de Merkle, - la FIG. 11 montre l’arbre de Merkle de la FIG. 10 après écriture d’une nouvelle donnée, - la FIG. 12 est un diagramme de séquence montrant des étapes d’écriture de la nouvelle donnée par le système de la FIG. 9 , - la FIG. 12 décrit des étapes du diagramme de la FIG. 12 , - la FIG. 13 montre l’arbre de Merkle de la FIG. 11 après modification d’une donnée, - la FIG. 14 est un diagramme de séquence montrant des étapes de modification de la nouvelle donnée par le système de la FIG. 9 , et - la FIG. 14 décrit des étapes du diagramme de la FIG. 14 . 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". 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 et au processeur SPROC par une liaison de données LK3. 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 ®". Les liaisons de données LK2, LK3 sont de préférence des liaisons sécurisées https ("Hypertext Transfer Protocol Secure"). Pour une sécurité encore plus forte, les liaisons LK2, LK3 peuvent consister dans des canaux chiffrés de type SCP ("Secure Channel Protocol") basés sur un échange de clés Diffie-Hellman. Dans un mode de réalisation, la liaison LK3 prend la forme d’un canal chiffré SCP basé sur un échange de clés Diffie-Hellman qui est établie par l’intermédiaire des liaisons LK2 et LK1. 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. Par ailleurs, le processeur sécurisé SPROC exécute un programme ACP de vérification de la base de données (“Application Data Database Check Program”) dont la fonction sera également décrite plus loin. L’entité utilisatrice USR exécute un programme utilisateur UAP ("User Application Program") qui utilise la base de données ADB pour stocker des données. 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 H4 é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 [I78] 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 [I78], 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. Les figures 7 et 8 décrivent un exemple de mise en œuvre de ce procédé pour la lecture et l’écriture de données dans la base de données ADB. La FIG. 7 décrit des étapes de lecture et la FIG. 8 des étapes d’écriture ou d’effacement de la base de données ADB. Les actions décrites sur ces figures sont exécutées : - par le processeur DPROC au moyen du programme AMP de gestion de la base de données ADB et du programme TMP de gestion de l'arbre de Merkle, - par l’entité utilisatrice USR au moyen du programme utilisateur UAP, et - par le processeur sécurisé SPROC, au moyen du programme ACP de vérification de la base de données ADB. Sur la FIG. 7 , le processeur DPROC est dans l’attente d’une commande de lecture ou d’écriture à une étape D01. A une étape U01 l’entité utilisatrice lui envoie une commande de lecture d’un emplacement d’index [Ii]. A une étape D02, le processeur DPROC reçoit la commande. A une étape D03 le processeur communique à l’entité utilisatrice USR la donnée DTi d’index [Ii] et la preuve de Merkle MP correspondante. Si l’emplacement d’index [Ii] est vide (DTi=∅) le processeur DPROC envoie une indication que l’emplacement est vide. A une étape U02, l’entité utilisatrice reçoit ces informations et les communique au processeur SPROC et lui demande de valider la donnée DTi. A une étape H01 le processeur SPROC reçoit donc la donnée DTi (ou l’information que l’emplacement est vide), l’index [Ii] et la preuve de Merkle MP. A une étape H02, le processeur SPROC calcule un code de hachage racine RH1 que la base de données TDB est supposée contenir, à partir de DTi, de l’index [Ii] et de la preuve de Merkle MP. A cet effet, le processeur SPROC, au moyen du programme ACP : - identifie les nœuds liés au nœud feuille cible d’index [Ii], - calcule un code de hachage Hi que le nœud feuille cible est supposé contenir, ou le détermine par convention (cas où DTi=∅ pour lequel H(DTi)= H(∅)), et - calcule des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir, sur la base du code de hachage que le nœud feuille cible est supposé contenir et de la preuve de Merkle, - puis calcule le 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. A une étape H03 le processeur SPROC vérifie que le code de hachage racine RH1 qu’il vient de calculer est identique au code de hachage racine RHm mémorisé dans la mémoire SMEM. Si les deux codes sont différents, le processeur SPROC envoie un message d’erreur à l’entité utilisatrice qui va alors à une étape U10 de gestion es erreurs. Si les deux codes sont identiques, le processeur SPROC va à une étape H04 où il envoie à l’entité utilisatrice une confirmation de validité de la donnée DTi. A une étape U03 l’entité utilisatrice reçoit la confirmation de la validité de DTi et peut l’utiliser pour les besoins de son application. On se référera maintenant à la FIG. 8 . A l’étape D01 le processeur DPROC est dans l’attente d’une commande. A une étape U11, l’entité utilisatrice USR envoie au processeur DPROC une commande d’écriture d’une nouvelle donnée DTj à un emplacement d’index [Ii], ou une commande d’effacement de cet emplacement. A une étape D12 le processeur DPROC reçoit la commande. A une étape D13 le processeur DPROC communique à l’entité utilisatrice USR une donnée DTi présente à l’emplacement d’index [Ii] et la preuve de Merkle MP correspondante. Si l’emplacement d’index [Ii] est vide (DTi=∅), le processeur DPROC envoie une indication que l’emplacement est vide. A une étape U12 l’entité utilisatrice reçoit la donnée DTi et la preuve de Merkle MP, puis envoie au processeur SPROC : - la donnée DTi où une indication que l’emplacement est vide, - l’index [Ii] de l’emplacement, - la preuve de Merkle MP pour cet emplacement (un emplacement même vide ayant toujours une preuve de Merkle associée puisque le code de hachage du nœud feuille associé a été défini par convention), - la nouvelle donnée DTj ou une indication que DTj=∅ dans le cas d’une commande d’effacement, et - une information que DTj doit remplacer DTi dans l’emplacement considéré. A une étape H11, le processeur SPROC reçoit la donnée actuelle DTi, l’index [Ii], la preuve de Merkle MP pour l’emplacement d’index [Ii], et la nouvelle donnée DTj. A une étape H12, le processeur SPROC calcule, au moyen du programme ACP, le code de hachage racine RH1 que la base de données ADB est supposée contenir, de la même façon qu’à l’étape H02, à savoir à partir de la donnée DTi, de l’index [Ii] et de la preuve de Merkle. A une étape H13, le processeur SPROC vérifie que le code de hachage racine RH1 qu’il vient de calculer est identique au code de hachage racine RHm mémorisé dans la mémoire SMEM. Si les deux codes sont différents, le processeur SPROC envoie un message d’erreur à l’entité utilisatrice qui va alors à l’étape susmentionnée U10 de gestion des erreurs. Si les deux codes sont identiques, le processeur SPROC va à une étape H14 où il calcule un nouveau code de hachage racine RH2 à partir de la nouvelle donnée DTj, de l’index [Ii], et de la preuve de Merkle MP, et stocke le nouveau code de hachage racine RH2 dans la mémoire SMEM. Pour calculer le nouveau code de hachage racine RH2, le processeur SPROC, au moyen du programme ACP : - identifie les nœuds liés au nœud feuille cible d’index [Ii], - calcule un code de hachage Hi que le nœud feuille cible contiendra lorsque l’arbre de Merkel dans la base de données TDB aura été mis à jour avec la donnée DTj, ou le détermine par convention (cas où DTj=∅ pour lequel H(DTj)= H(∅)), - calcule des codes de hachage que les nœuds liés au nœud feuille cible contiendront, sur la base du code de hachage que le nœud feuille cible contiendra et de la preuve de Merkle, - calcule des codes de hachage que les nœuds liés au nœud feuille cible contiendront, sur la base du code de hachage que le nœud feuille cible contiendra et de la preuve de Merkle, - puis calcule le code de hachage racine RH2 sur la base du code de hachage que le nœud feuille cible contiendra, de la preuve de Merkle et des codes de hachage que les nœuds liés au nœud feuille cible contiendront. Le processeur SPROC va ensuite à une étape H15 où il envoie à l’entité utilisatrice USR une confirmation de validité de la donnée DTi accompagnée du code de hachage racine RH2 que l'arbre de Merkle dans la base de données TDB devra contenir lorsque la donnée DTj aura été enregistrée dans la base de données ADB. Cette confirmation de validité de la donnée DTi peut être implicite dans l’envoi du futur code de hachage racine RH2. A une étape U13, l’entité utilisatrice USR reçoit la confirmation de validité et le code de hachage racine RH2 pour la donnée DTj. A une étape U14, l’entité utilisatrice peut donc décider d’envoyer au processeur DPROC une commande d’écriture de la donnée DTj ou d’effacement de la donnée DTi si DTj=∅, la commande comprenant la donnée DTj ou une indication que la donnée DTi doit être effacée, et l’index [Ii]. Dans un mode de réalisation optionnel, l’entité utilisatrice envoie également le code de hachage racine RH2 au processeur DPROC. Dans ce dernier cas, à une étape D14 optionnelle, le processeur DPROC calcule lui-même le code de hachage racine RH2 à partir des données qu’il détient dans la base de données TDB, et le compare au code de hachage racine RH2 reçu. Si les deux codes RH2 sont identiques ou si l’étape optionnelle D14 n’est pas mise en œuvre, le processeur DPROC, à une étape D15, stocke la nouvelle donnée DTj ou efface la donnée DTi dans la base de données ADB, et met à jour l’arbre de Merkle dans la base de données TDB. Si les deux codes RH2 ne sont pas identiques quand l’étape optionnelle D14 est mise en œuvre, le processeur DPROC va à une étape D20 de gestion des erreurs. Il apparaîtra clairement à l’homme de l’art que le procédé de lecture et d’écriture qui vient d’être décrit peut être mis en œuvre de la même manière pour la lecture ou l’écriture simultanée de plusieurs données. Les étapes qui viennent d’être décrites restent substantiellement les mêmes, à ceci près que la preuve de Merkel extraite de la base de données ADB concerne plusieurs données en même temps, comme cela a été vu précédemment. Dans les modes de réalisations qui viennent d’être décrits, le processeur sécurisé SPROC est utilisé comme une entité de confiance permettant de vérifier que la base de données ADB est saine à chaque lecture, écriture ou effacement d’une ou de plusieurs données, de sorte qu’il est impossible à un fraudeur d’altérer la base de données ADB sans que cela ne soit immédiatement détecté. Le processeur sécurisé est donc, d’une certaine manière, au service de la base de données et de l’entité utilisatrice. Dans un mode de réalisation illustré sur la FIG. 9 , 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. Les processeurs DPROC et SPROC sont reliés par une liaison LK1 de type PCI ("Peripheral Component Interconnect Express") ou Ethernet. Le processeur DPROC exécute une 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. 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. Ce programme prend également en charge la fonction du programme ACP précédemment décrit, de vérification de la base de données ADB par comparaison du code de hachage racine mémorisé RHm avec le code de hachage racine calculé RH1 ou RH2. Le programme utilisateur UAP exécuté par l’entité utilisatrice USR sollicite ici le programme d’application SAP du processeur sécurisé pour l’exécution d’opérations conduisant ce dernier à 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 si nécessaire, ou peuvent être modifiées par le programme d’application SAP à partir de paramètres reçus du programme UAP. Elles sont toutefois ici 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. On décrira maintenant en relation avec les figures 12A, 12B 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. 10 , 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. 11 , 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 12A, 12B décrivent des étapes exécutées par le système de la FIG. 9 pour ajouter la donnée "user=alice" à la base de données se trouvant dans l’état montré sur la FIG. 10 , afin d’obtenir la base de données dont l’état est montré sur la FIG. 11 . 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 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. 13 , 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 14A, 14B décrivent des étapes exécutées par le système de la FIG. 9 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. 13 . 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. En résumé, on a décrit dans ce qui précède deux applications différentes d’un arbre de Merkle clairsemé. Dans l’application illustrée sur la FIG. 1 , le processeur sécurisé SPROC est "au service" de l’espace mémoire DMEM et du processeur DPROC qui gère les bases de données AMP et TMP, en ce sens que le processeur sécurisé SPROC permet au processeur DPROC de valider les opérations de lecture ou d’écriture de données dans la base de données AMP, les données étant fournies de l’extérieur par l’entité utilisatrice USR. Dans l’application illustrée sur la FIG. 9 , pouvant notamment être mise en œuvre avec un HSM comme processeur sécurisé SPROC, l’espace mémoire DMEM et le processeur DPROC sont au contraire "au service" du processeur sécurisé qui exécute l’application SAP, par laquelle il est amené à générer ou modifier un grand nombre de données, l’espace mémoire DMEM formant dans ce cas une extension de la mémoire propre SMEM du processeur sécurisé. Les deux applications mettent en œuvre des mécanismes de sécurité identiques ou similaires, et notamment : i) le fait que le code de hachage racine de l’arbre de Merkle soit stocké dans une mémoire sécurisée, ii) le fait que chaque lecture d’une donnée ou lecture simultanée d’une pluralité de données dans la base de données ne soit validée qu’après avoir recalculé le code de hachage racine correspondant RH1 à partir d’une preuve de Merkel extraite de la base de données ADB, et vérifié ce celui-ci correspond au code de hachage racine mémorisé RHm, iii) le fait que chaque écriture d’une nouvelle donnée ou écriture simultanée d’une pluralité de nouvelles données dans la base de données ne soit validée qu’après avoir tout d’abord vérifié, en appliquant la méthode mentionnée au point ii), que les données initiales se trouvant dans la base de données sont valides, et qu’après avoir recalculé le code de hachage racine correspondant RH2 à partir de la preuve de Merkle (la même que celle utilisée au point ii) et mémorisé le code de hachage racine RH2 dans la mémoire sécurisée en remplacement de l’ancienne valeur RHm. 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 sécuriser des données mémorisées dans un espace mémoire non volatile (DMEM), caractérisé en ce qu’il comprend les étapes consistant à : - prévoir dans l’espace mémoire non volatile une première base de données indexée (ADB) 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 (LO) 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 (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 (LN) et des nœuds internes (IN) s’étendant sur une pluralité de niveaux de l’arbre jusqu’à un nœud sommet (TN), chaque emplacement (LO) de la première base de données étant associée à un nœud feuille, chaque nœud feuille recevant un code de hachage (Hi) de la donnée (DTi) présente dans l’emplacement 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 fonction 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), - après chaque mise à jour de la première base de données (ADB), mettre à jour l’arbre de Merkle dans la seconde base de données (TDB) pour que son état actuel reflète l’état actuel de la première base de données, - 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 (TDB), 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 (H02) un premier code de hachage racine (RH1) de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données, et - comparer (H03) le premier code de hachage racine (RH1) à un code de hachage racine (RHm) mémorisé dans la mémoire non volatile sécurisée (SMEM), la donnée étant valide si le premier code de hachage racine est égal au code de hachage racine mémorisé. Procédé selon la revendication 1, comprenant, lorsqu’une donnée doit être stockée dans un emplacement cible de la première base de données, les étapes consistant à : - calculer (H12) le premier code de hachage racine (RH1) de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données, et - comparer (H13) le premier code de hachage racine au code de hachage racine (RHm) 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 (H14) un second code de hachage racine (RH2) 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 (H14) le second code de hachage racine dans la mémoire non volatile sécurisée, en remplacement du code de hachage racine (RHm) anciennement mémorisé, - mettre à jour (D15) la première base de données avec la nouvelle donnée, et - mettre à jour (D15) l’arbre de Merkle dans la seconde base de données. Procédé selon la revendication 2, dans lequel 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 (D03, D13) 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 (D03, D13) de la seconde base de données une preuve de Merkle (MP) du nœud feuille cible, la preuve de Merkle (MP) comprenant des codes de hachage contenus dans des nœuds voisins aux nœuds liés, - calculer ou déterminer (H03, H13) 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 (MP) extraite de la seconde base de données, calculer ou déterminer (H03, H13) des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir, et - calculer ou déterminer (H03, H13) 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 (MP) 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. Procédé selon l’une des revendications 2 et 3, dans lequel l’étape (H14) de calcul du second code de hachage racine (RH2) 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 (H14) 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 (MP) extraite de la seconde base de données, calculer ou déterminer (H14) 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 (H14) sur la base du nouveau code de hachage que le nœud feuille cible contiendra, de la preuve de Merkle (MP) 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. Procédé selon l’une des revendications 1 à 4, 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 5, dans lequel le code de hachage de nœud vide (H(∅)) est égal à zéro. Procédé selon l’une des revendications 5 et 6, 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 5 à 7, 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 7 et 8, 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 à 9, dans lequel on ne stocke que le code de hachage racine dans la mémoire non volatile sécurisée, et aucune donnée de la première ou de la seconde base de données. Procédé selon l’une des revendications 1 à 10, dans lequel on 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. Procédé selon l’une des revendications 1 à 11, comprenant les étapes consistant à : - prévoir au moins un premier processeur (APROC) pour gérer la première (ADB) et la seconde (TDB) base de données, et - prévoir un second processeur (SPROC) de type sécurisé pour gérer la mémoire non volatile sécurisée (SMEM). Procédé selon la revendication 12, dans lequel on exécute au moyen du second processeur (SMEM) les étapes (H02, H12) de calcul du premier code de hachage racine (RH1) et de comparaison (H02, H13) du premier code de hachage racine (RHm) au code de hachage racine mémorisé dans la mémoire non volatile sécurisée. Procédé selon la revendication 13, dans lequel lorsqu’une nouvelle donnée (DTi, DTj) doit être stockée dans un emplacement cible de la première base de données, on fournit au second processeur (SPROC) au moyen du premier processeur (DPROC) un index du nœud feuille cible correspondant à l’emplacement cible, une donnée (DTi) contenue dans cet emplacement ou une indication selon laquelle l’emplacement est vide, et la preuve de Merkle (MP) correspondante. Système de stockage de données comprenant : - un espace mémoire non volatile comprenant : - une première base de données indexée (ADB) dans laquelle sont stockées les données, la première base de données comprenant une pluralité d’emplacements (LO) identifiables chacun par un index, chaque emplacement pouvant recevoir une donnée, - une seconde base de données indexée (TDB) associée à la première base de données et configurée pour former un arbre de Merkle clairsemé comprenant 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, chaque emplacement (LO) de la première base de données étant associée à un nœud feuille, chaque nœud feuille recevant un code de hachage (Hi) de la donnée (DTi) présente dans l’emplacement 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 fonction 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, - une mémoire non volatile sécurisée, dans laquelle est stocké un code de hachage racine de l’arbre de Merkle représentatif de l’état actuel de la seconde base de données, le système étant configuré pour, après chaque mise à jour de la première base de données (ADB), mettre à jour l’arbre de Merkle dans la seconde base de données (TDB) pour que son état actuel reflète l’état actuel de la première base de données, et lorsqu’une donnée doit être lue dans la première base de données, pour : - lire la donnée dans la première base de données, - calculer (H02) un premier code de hachage racine (RH1) de l’arbre de Merkle fondé sur l’état actuel de la seconde base de données, et - comparer (H03, H13) le premier code de hachage racine (RH1) à un code de hachage racine (RHm) mémorisé dans la mémoire non volatile sécurisée (SMEM), la donnée étant valide si le premier code de hachage racine est égal au code de hachage racine mémorisé. Système selon la revendication 15, configuré pour, lorsqu’une donnée doit être stockée dans un emplacement cible de la première base de données : - calculer le premier code de hachage racine (RH1) 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 (RHm) 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 (H14) un second code de hachage racine (RH2) 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 (H14) le second code de hachage racine dans la mémoire non volatile sécurisée, en remplacement du code de hachage racine (RHm) 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. Système selon la revendication 16, configuré pour conduire de la façon suivante 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 : - lire (D03, D13) 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 (D03, D13) de la seconde base de données une preuve de Merkle (MP) du nœud feuille cible, la preuve de Merkle (MP) comprenant des codes de hachage contenus dans des nœuds voisins aux nœuds liés, - calculer ou déterminer (H03, H13) 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 (MP) extraite de la seconde base de données, calculer ou déterminer (H03, H13) des codes de hachage que les nœuds liés au nœud feuille cible sont supposés contenir, - calculer ou déterminer (H03, H13) 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 (MP) 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. Système selon l’une des revendications 16 et 17, configuré pour conduire de la façon suivante 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 : - sur la base de la nouvelle donnée, calculer ou déterminer (H14) 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 (MP) extraite de la seconde base de données, calculer ou déterminer (H14) 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 (H14) sur la base du nouveau code de hachage que le nœud feuille cible contiendra, de la preuve de Merkle (MP) 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.. Système selon l’une des revendications 15 à 18, dans lequel la mémoire non volatile sécurisée ne stocke que le code de hachage racine et aucune donnée de la première ou de la seconde base de données. Système selon l’une des revendications 15 à 19, dans lequel la seconde base de données stocke 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 à 20, comprenant : - au moins un premier processeur (DPROC) pour gérer la première et la seconde base de données, - un second processeur (SPROC) de type sécurisé pour gérer la mémoire non volatile sécurisée, la mémoire non volatile sécurisée n’étant pas accessible en lecture ou écriture au premier processeur. Système selon la revendication 21, configuré pour exécuter au moyen du second processeur (SPROC) les étapes 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, et de comparaison du premier code de hachage racine au code de hachage racine mémorisé dans la mémoire non volatile sécurisée. Système selon la revendication 22, configuré pour que, lorsqu’une nouvelle donnée doit être stockée dans un emplacement cible de la première base de données, le premier processeur fournisse à l’attention du second processeur un index du nœud feuille cible correspondant à l’emplacement cible, une donnée contenue dans cet emplacement ou une indication selon laquelle l’emplacement est vide, et la preuve de Merkle (MP) correspondante. Système selon l’une des revendications 15 à 23, comprenant une entité utilisatrice (USR) interposée opérationnellement entre le premier et le second processeur, les données fournies par le second processeur à l’attention du premier processeur étant reçues par l’entité utilisatrice qui les fournit au premier processeur.