Brevet FR3157601A1 — publié le 20250627

Procédé pour la sauvegarde et la restauration d'un secret détenu par un dispositif électronique sécurisé, comprenant une étape de sauvegarde du secret comportant les étapes consistant à prévoir une pluralité de serveurs de sauvegarde (BCKi), collecter des données (PID) définissant l’identité d’un premier utilisateur et les communiquer à chaque serveur de sauvegarde, au moyen du dispositif électronique sécurisé, générer une pluralité de parts secrètes (Si) à partir du secret, transférer à chaque serveur de sauvegarde l'une des parts secrètes (Si), et, dans chaque serveur de sauvegarde, générer (B13.2.a, B13.2.b, B13.2.c, B13.2.d, B13.2.e) une donnée de liaison chiffrée (LNKSi) qui est fonction de la part secrète (Si) et des données (PID) définissant l’identité du premier utilisateur, et stocker la donnée de liaison chiffrée dans une mémoire du serveur de sauvegarde. Figure pour l'abrégé : Fig. 4B Procédé pour lier à l’identité d’une personne la sauvegarde d'un secret. La présente invention concerne un procédé pour la sauvegarde et la restauration d'un secret détenu par un dispositif électronique sécurisé. La présente invention concerne notamment la sauvegarde et la restauration d’une clé maître détenue par un portefeuille matériel déterministe hiérarchique utilisée pour le stockage de clés privées associées à des comptes de cryptoactifs. Arrière-plan Ces dernières années, le développement des cryptomonnaies ou autres types de cryptoactifs gérés par la blockchain, tels que les jetons non fongibles ("NFT") et les contrats intelligents ("Smart Contracts"), a donné naissance à divers moyens de stockage et de conservation des clés privées et publiques attachées à ces différents types de cryptoactifs. C’est ainsi que sont apparus les portefeuilles de cryptoactifs communément appelés "wallets" permettant le stockage et la conservation de ces clés. Un portefeuille de cryptoactifs est un dispositif matériel ou logiciel dont la fonction est de stocker les clés privées et publiques attachées à des comptes de cryptoactifs, et de signer des transactions au moyen de ces clés. On distingue les portefeuilles dits "chauds" ("hot wallets") et les portefeuilles dit froids ("cold wallets"). Les portefeuilles "chauds " sont connectés à l’Internet et susceptibles d’attaques de pirates ou d’exposition à des virus et malwares. Il peut s’agir de portefeuilles gérés par des plateformes d’échange centralisé ou de programmes installés sur des téléphones mobiles, tablettes ou ordinateurs personnels ("software wallets"). De tels portefeuilles sont connectés à Internet et donc eux-mêmes susceptibles d’attaques. Les portefeuilles "froids" ou portefeuilles matériels ("hardware wallet") sont en revanche dépourvus de tout accès direct à Internet, ce qui réduit la surface d'attaque et donc le risque de vol par piratage informatique. Un portefeuille matériel est généralement un dispositif électronique portatif, équipé d’un processeur ayant des moyens de calcul cryptographique. Les transactions mettant en jeu des clés privées sont signées dans un environnement hors ligne. Toute transaction réalisée en ligne est temporairement transférée vers le portefeuille matériel pour y être signée numériquement hors ligne, avant que la signature ne soit transmise au réseau en ligne. Comme les clés privées ne sont pas communiquées aux serveurs en ligne pendant le processus de signature, un pirate informatique ne peut pas y accéder. Un tel type de portefeuille matériel est donc aujourd’hui considéré comme la solution la plus sûre contre les attaques de pirates informatiques. Son seul inconvénient réside dans le risque de perte, de vol ou de destruction (incendie par exemple) du portefeuille matériel, ou de perte du mode de passe personnel de l'utilisateur permettant de s’en servir. Les clés qu’il contient doivent donc généralement être sauvegardées en lieu sûr. Un premier problème qui s’est posé dans le passé a été de trouver un moyen de simplifier le nombre de clés à sauvegarder, celles-ci pouvant être très nombreuses si l’utilisateur possède de nombreux comptes de cryptoactifs sur la blockchain. Pour solutionner ce problème, le portefeuille déterministe hiérarchique a été proposé par Bitcoin. D'abord proposé dans la norme BIP32, puis optimisé avec les normes BIP39, BIP43 et BIP44, il permet à un utilisateur de ne pas avoir à réaliser une nouvelle sauvegarde pour toute nouvelle paire de clés générée, une unique sauvegarde pour l'ensemble des clés de son portefeuille étant suffisante. Cette solution est aujourd’hui utilisée par la grande majorité des portefeuilles de cryptoactifs logiciels ou matériels. Avec un portefeuille déterministe hiérarchique, toutes les clés privées de l’utilisateur sont générées à partir d’une graine aléatoire d’origine, généralement appelée "seed" ou "master key" (clé maître). Il suffit qu’un utilisateur conserve en lieu sûr la graine pour récupérer toutes ses clés, qui sont dérivées de la graine et peuvent être reconstituées à partir de celle-ci ("clés enfants"). Afin de faciliter la mémorisation et le stockage de la graine, la norme BIP39 prévoit également d'exprimer la graine, qui est un nombre binaire de grande longueur, sous la forme d’une phrase mnémonique appelée aussi "phrase de récupération" ("recovery phrase"). Le type exact de graine BIP39 utilisé actuellement dans les appareils de la demanderesse est une phrase de récupération qui se compose de 24 mots choisis dans une liste de 2048 mots définis par la norme précitée. Pour la génération d’une phrase de récupération, un portefeuille matériel génère une séquence de 256 bits aléatoires à l'aide d’un générateur de nombres aléatoires. Les 8 premiers bits d’un hachage SHA-256 des 256 bits initiaux sont ajoutés à cette chaîne de bits, ce qui donne 264 bits. Les 264 bits sont répartis en 24 groupes de 11 bits par l’appareil. Chaque groupe de 11 bits est interprété comme un nombre compris entre 0 et 2047, qui sert d'index à la liste de mots BIP39, ce qui permet d’obtenir la phrase mnémonique de 24 mots. Ce type de portefeuille ne nécessite donc qu’une seule sauvegarde de la graine, de préférence au moment de sa mise en service, à partir de laquelle il est possible de dériver l’ensemble de l’arbre descendant de clés. La FIG. 1 montre schématiquement un portefeuille de cryptoactifs comprenant un portefeuille matériel HW, par exemple le dispositif commercialisé par la demanderesse sous l’appellation "Ledger Nano" et un dispositif hôte HDV exécutant une application compagnon HSW, par exemple l’application "Ledger Live" développée par la demanderesse. Le dispositif HW ne pouvant pas se connecter directement à l’Internet, il est associé au dispositif hôte HDV pour réaliser des transactions sur la blockchain. Le dispositif hôte HDV est par exemple un ordinateur, un téléphone mobile, une tablette ou équivalent. La connexion entre le dispositif HW et le dispositif hôte HDV peut être de type USB ou Bluetooth par exemple. Une fois relié au dispositif hôte, le dispositif HW peut interagir avec le logiciel compagnon pour permettre à un utilisateur USR de réaliser des transactions sur la blockchain BCN ou sur des sites d’échange décentralisé. Le dispositif HW peut par ailleurs communiquer avec un module de sécurité HSM ("Hardware Security Module") situé dans un datacenter. Le module HSM est classiquement un boîtier de chiffrement matériel permettant de générer, stocker et protéger des clés cryptographiques. . Le module HSM ne stocke aucune clé privée de l’utilisateur et assure seulement le contrôle de l’authenticité du dispositif HW, sa mise en service, la mise à jour de son système d’exploitation, le téléchargement de programmes d’application certifiés, etc. Lors de la première mise en service du dispositif HW, celui-ci fournit à l’utilisateur une phrase de récupération de 24 mots que celui-ci devra conserver sur un support physique approprié, par exemple une feuille de papier ou un support inaltérable tel une plaque de métal gravée, qu'il devra conserver en lieu sûr. Une telle conservation en lieu sûr de la phrase de récupération ne va pas sans risque. En effet, si un tiers s’empare de la phrase de récupération, le tiers pourra accéder à l’ensemble des comptes de cryptoactifs de l’utilisateur générés à partir de la graine et transférer sur d’autres comptes les sommes qu’ils comportent, et il sera ensuite très difficile de l’identifier. Il pourrait donc être souhaité de prévoir un moyen permettant d’offrir aux utilisateurs un moyen simple et pratique pour conserver leur graine de manière hautement sécurisée, et de façon plus générale un procédé pour la sauvegarde et la restauration d'un secret détenu par un dispositif électronique sécurisé. Il pourrait également être souhaité que la sauvegarde d’un secret soit liée à l’identité d’une personne d’une manière qui puisse résister à une attaque de fraudeur visant à substituer l’identité d’une autre personne à celle de la personne légitimement détentrice du secret. Résumé Des modes de réalisation concernent un procédé pour la sauvegarde et la restauration d'un secret détenu par un dispositif électronique sécurisé, comprenant une étape de sauvegarde du secret comportant les étapes consistant à prévoir une pluralité de serveurs de sauvegarde, collecter des données définissant l’identité d’un premier utilisateur, et les communiquer à chaque serveur de sauvegarde, au moyen du dispositif électronique sécurisé, générer une pluralité de parts secrètes à partir du secret, transférer à chaque serveur de sauvegarde l'une des parts secrètes, et, dans chaque serveur de sauvegarde, générer une donnée de liaison chiffrée qui est fonction de la part secrète et des données définissant l’identité du premier utilisateur, et stocker la donnée de liaison chiffrée dans une mémoire du serveur de sauvegarde. Selon un mode de réalisation, dans au moins un serveur de sauvegarde l’étape de génération de la donnée de liaison chiffrée comprend les étapes consistant à générer un code de sauvegarde fonction de l’identité du premier utilisateur, combiner la part secrète et le code de sauvegarde, et chiffrer la combinaison de la part secrète et du code de sauvegarde au moyen d’une clé secrète du serveur de sauvegarde. Selon un mode de réalisation, dans au moins un serveur de sauvegarde l’étape de génération de la donnée de liaison chiffrée comprend les étapes consistant à générer un code de sauvegarde fonction de l’identité du premier utilisateur, appliquer une fonction de dérivation de clé à une clé secrète du serveur de sauvegarde, en utilisant le code de sauvegarde comme diversifiant de dérivation, pour obtenir une première clé dérivée fonction des données définissant l’identité du premier utilisateur, et chiffrer la part secrète au moyen de la première clé dérivée. Selon un mode de réalisation, dans au moins un serveur de sauvegarde l’étape de génération de la donnée de liaison chiffrée comprend les étapes consistant à générer un code de sauvegarde fonction de l’identité du premier utilisateur, combiner la part secrète et le code de sauvegarde, et hacher la combinaison de la part secrète et du code de sauvegarde pour obtenir la donnée de liaison chiffrée, le procédé comprenant en outre des étapes consistant à chiffrer la part secrète au moyen d’une clé secrète du serveur de sauvegarde et stocker la part secrète chiffrée dans la mémoire du serveur de sauvegarde. Selon un mode de réalisation, dans au moins un serveur de sauvegarde l’étape de génération de la donnée de liaison chiffrée comprend les étapes consistant à chiffrer la part secrète au moyen d’une clé secrète du serveur de sauvegarde, générer un code de sauvegarde fonction de l’identité du premier utilisateur, combiner la part secrète chiffrée et le code de sauvegarde, et chiffrer la combinaison de la part secrète chiffrée et du code de sauvegarde au moyen d’une clé secrète du serveur de sauvegarde et d'une fonction de hachage cryptographique, le procédé comprenant en outre une étape consistant à stocker la part secrète chiffrée dans la mémoire du serveur de sauvegarde. Selon un mode de réalisation, l'étape de génération du code de sauvegarde comprend une étape de concaténation de données définissant une identité pivot de l’utilisateur. Selon un mode de réalisation, l’étape de génération du code de sauvegarde comprend une étape de concaténation de données définissant une identité pivot de l’utilisateur, et une étape de hachage des données d’identité pivot concaténées. Selon un mode de réalisation, le procédé comprend une étape de restauration du secret comprenant les étapes consistant à collecter des données définissant l’identité d’un deuxième utilisateur, vérifier leur validité avec la participation du deuxième utilisateur, et les fournir à au moins un serveur de sauvegarde, et au moyen du serveur de sauvegarde, vérifier, au moyen de la donnée de liaison chiffrée, que l’identité du deuxième utilisateur est la même que l’identité du premier utilisateur. Selon un mode de réalisation, l'étape de vérification de l’identité du deuxième utilisateur comprend au moins l’une des opérations suivantes : déchiffrer la donnée de liaison chiffrée, en extraire l’identité du premier utilisateur ou une donnée fonction de son identité, et la comparer à l’identité du deuxième utilisateur ou à une donnée fonction de l’identité du deuxième utilisateur ; déchiffrer la donnée de liaison chiffrée au moyen d’une clé fonction de l’identité du deuxième utilisateur ; calculer une nouvelle donnée de liaison chiffrée à partir de l’identité du deuxième utilisateur et la comparer à la donnée de liaison chiffrée initiale. Selon un mode de réalisation, le procédé comprend une étape de restauration du secret comportant les étapes consistant à collecter des données définissant l’identité d’un deuxième utilisateur, vérifier leur validité avec la participation du deuxième utilisateur, et les fournir à au moins un serveur de sauvegarde, et, au moyen du serveur de sauvegarde : générer un code de restauration fonction de l’identité du deuxième utilisateur, déchiffrer la donnée de liaison chiffrée au moyen de la clé secrète du serveur de sauvegarde et en extraire le code de sauvegarde, comparer le code de restauration et le code de sauvegarde, restituer la part secrète présente dans la donnée de liaison chiffrée si les deux codes sont identiques, et refuser de la restituer si les deux codes ne sont pas identiques. Selon un mode de réalisation, le procédé comprend une étape de restauration du secret comportant les étapes consistant à collecter des données définissant l’identité d’un deuxième utilisateur, vérifier leur validité avec la participation du deuxième utilisateur, et les fournir à au moins un serveur de sauvegarde, et, au moyen du serveur de sauvegarde : générer un code de restauration fonction de l’identité du deuxième utilisateur, appliquer la fonction de dérivation de clé à la clé secrète du serveur de sauvegarde en utilisant comme diversifiant de dérivation le code de restauration, pour obtenir une deuxième clé dérivée fonction des données définissant l’identité du deuxième utilisateur, et si la première et la deuxième clé dérivées sont identiques, déchiffrer la donnée de liaison chiffrée au moyen de la deuxième clé dérivée et en extraire la part secrète. Selon un mode de réalisation, le procédé comprend une étape de restauration du secret comportant les étapes consistant à collecter des données définissant l’identité d’un deuxième utilisateur, vérifier leur validité avec la participation du deuxième utilisateur, et les fournir à au moins un serveur de sauvegarde, et, au moyen du serveur de sauvegarde, générer un code de restauration fonction de l’identité du deuxième utilisateur, déchiffrer la part secrète au moyen de la clé secrète du serveur de sauvegarde, combiner la part secrète et le code de restauration, et hacher la combinaison de la part secrète et du code de restauration pour obtenir une nouvelle donnée de liaison chiffrée, comparer la nouvelle donnée de liaison chiffrée et la donnée de liaison chiffrée, et restituer la part secrète si la nouvelle donnée de liaison chiffrée et la donnée de liaison chiffrée sont identiques, sinon refuser de restituer la part secrète. Selon un mode de réalisation, le procédé comprend une étape de restauration du secret comportant les étapes consistant à collecter des données définissant l’identité d’un deuxième utilisateur, vérifier leur validité avec la participation du deuxième utilisateur, et les fournir à au moins un serveur de sauvegarde, et, au moyen du serveur de sauvegarde, générer un code de restauration fonction de l’identité du deuxième utilisateur, combiner la part secrète et le code de restauration, et chiffrer la combinaison de la part secrète et du code de restauration au moyen de la clé secrète du serveur de sauvegarde et de la fonction de hachage cryptographique, pour obtenir une nouvelle donnée de liaison chiffrée, comparer la nouvelle donnée de liaison chiffrée et la donnée de liaison chiffrée, déchiffrer et restituer la part secrète si la nouvelle donnée de liaison chiffrée et la donnée de liaison chiffrée sont identiques, sinon refuser de restituer la part secrète. Selon un mode de réalisation, l'étape de génération du code de restauration comprend une étape de concaténation de données définissant une identité pivot de l’utilisateur. Selon un mode de réalisation, l’étape de génération du code de restauration comprend une étape de concaténation de données définissant une identité pivot de l’utilisateur, et une étape de hachage des données d’identité pivot concaténées. Selon un mode de réalisation, l’identité d’un utilisateur est définie par au moins un prénom, un nom de famille et une date de naissance de l’utilisateur. Selon un mode de réalisation, le dispositif électronique sécurisé est configuré pour générer une pluralité de parts secrètes au moyen d’une fonction de partage de secret prévue pour générer un nombre m de parts secrètes à partir du secret et permettre la reconstitution du secret à partir d’un seuil de n parts secrètes. Selon un mode de réalisation, le dispositif électronique sécurisé comprend un portefeuille matériel de comptes de cryptoactifs dépourvu de moyen de connexion à l’Internet relié ou configuré pour être relié à un dispositif hôte exécutant un logiciel compagnon et pourvu d’une connexion à l’Internet. Des modes de réalisation concernent également un serveur pour la sauvegarde et la restitution d'une donnée secrète, configuré pour, en réponse à une demande de sauvegarde de la donnée secrète : recevoir la donnée secrète, recevoir des données définissant l’identité d’un premier utilisateur, générer une donnée de liaison chiffrée qui est fonction de la donnée secrète et des données définissant l’identité du premier utilisateur, et stocker la donnée de liaison chiffrée dans une mémoire du serveur. Selon un mode de réalisation, le serveur est configuré pour générer la donnée de liaison chiffrée en exécutant les étapes consistant à : générer un code de sauvegarde fonction de l’identité du premier utilisateur, combiner la donnée secrète et le code de sauvegarde, et chiffrer la combinaison de la donnée secrète et du code de sauvegarde au moyen d’une clé secrète du serveur. Selon un mode de réalisation, le serveur est configuré pour générer la donnée de liaison chiffrée en exécutant les étapes consistant à : générer un code de sauvegarde fonction de l’identité du premier utilisateur, appliquer une fonction de dérivation de clé à une clé secrète du serveur en utilisant le code de sauvegarde comme diversifiant de dérivation, pour obtenir une première clé dérivée fonction des données définissant l’identité du premier utilisateur, et chiffrer la donnée secrète au moyen de la première clé dérivée. Selon un mode de réalisation, le serveur est configuré pour générer la donnée de liaison chiffrée en exécutant les étapes consistant à : générer un code de sauvegarde fonction de l’identité du premier utilisateur, combiner la donnée secrète et le code de sauvegarde, et hacher la combinaison de la donnée secrète et du code de sauvegarde, le serveur étant également configuré pour chiffrer la donnée secrète au moyen d’une clé secrète du serveur et stocker la donnée secrète chiffrée dans la mémoire du serveur. Selon un mode de réalisation, le serveur est configuré pour générer la donnée de liaison chiffrée en exécutant les étapes consistant à : chiffrer la donnée secrète au moyen d’une clé secrète du serveur, générer un code de sauvegarde fonction de l’identité du premier utilisateur, combiner la donnée secrète chiffrée et le code de sauvegarde, et chiffrer la combinaison de la donnée secrète chiffrée et du code de sauvegarde au moyen d’une clé secrète du serveur et d'une fonction de hachage cryptographique, le serveur étant en outre configuré pour stocker la donnée secrète chiffrée dans la mémoire du serveur. Selon un mode de réalisation, le serveur est configuré pour inclure dans l'étape de génération du code de sauvegarde une étape de concaténation de données définissant une identité pivot de l’utilisateur. Selon un mode de réalisation, le serveur est configuré pour inclure dans l’étape de génération du code de sauvegarde une étape de concaténation de données définissant une identité pivot de l’utilisateur, et une étape de hachage des données d’identité pivot concaténées. Selon un mode de réalisation, le serveur est configuré pour, en réponse à une demande de restitution de la donnée secrète : collecter des données définissant l’identité d’un deuxième utilisateur, générer un code de restauration fonction de l’identité du deuxième utilisateur, déchiffrer la donnée de liaison chiffrée et en extraire le code de sauvegarde, comparer le code de restauration et le code de sauvegarde, et restituer la donnée secrète présente dans la donnée de liaison chiffrée si les deux codes sont identiques, et refuser de la restituer si les deux codes ne sont pas identiques. Selon un mode de réalisation, le serveur est configuré pour, en réponse à une demande de restitution de la donnée secrète : collecter des données définissant l’identité d’un deuxième utilisateur, générer un code de restauration fonction de l’identité du deuxième utilisateur, appliquer la fonction de dérivation de clé à la clé secrète du serveur en utilisant comme diversifiant de dérivation le code de restauration, pour obtenir une deuxième clé dérivée fonction des données définissant l’identité du deuxième utilisateur, et si la première et la deuxième clé dérivées sont identiques, déchiffrer la donnée de liaison chiffrée au moyen de la deuxième clé dérivée et en extraire la donnée secrète. Selon un mode de réalisation, le serveur est configuré pour, en réponse à une demande de restitution de la donnée secrète : collecter des données définissant l’identité d’un deuxième utilisateur, générer un code de restauration fonction de l’identité du deuxième utilisateur, déchiffrer la donnée secrète au moyen de la clé secrète du serveur, combiner la donnée secrète et le code de restauration, hacher la combinaison de la donnée secrète et du code de restauration pour obtenir une nouvelle donnée de liaison chiffrée, comparer la nouvelle donnée de liaison chiffrée et la donnée de liaison chiffrée, et restituer la donnée secrète si la nouvelle donnée de liaison chiffrée et la donnée de liaison chiffrée sont identiques, sinon refuser de restituer la donnée secrète. Selon un mode de réalisation, le serveur est configuré pour, en réponse à une demande de restitution de la donnée secrète : collecter des données définissant l’identité d’un deuxième utilisateur, générer un code de restauration fonction de l’identité du deuxième utilisateur, combiner la donnée secrète et le code de restauration, et chiffrer la combinaison de la donnée secrète et du code de restauration au moyen de la clé secrète du serveur et de la fonction de hachage cryptographique, pour obtenir une nouvelle donnée de liaison chiffrée, comparer la nouvelle donnée de liaison chiffrée et la donnée de liaison chiffrée, déchiffrer et restituer la donnée secrète si la nouvelle donnée de liaison chiffrée et la donnée de liaison chiffrée sont identiques, sinon refuser de restituer la donnée secrète. Selon un mode de réalisation, le serveur est configuré pour générer le code de restauration par concaténation de données définissant une identité pivot de l’utilisateur. Selon un mode de réalisation, le serveur est configuré pour générer le code de restauration comprenant une étape de concaténation de données définissant une identité pivot de l’utilisateur, et une étape de hachage des données d’identité pivot concaténées. Description sommaire des dessins Ces caractéristiques ainsi que d'autres de la présente invention, seront mieux comprises à la lecture de la description suivante, faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : - la FIG. 1 précédemment décrite montre schématiquement un portefeuille de cryptoactifs et un exemple d'utilisation de celui-ci, - la FIG. 2 et la FIG. 2 montrent un portefeuille de cryptoactifs selon l’invention et l'architecture d'un système prévu pour la mise en œuvre d'un premier mode de réalisation du procédé selon l'invention, la FIG. 2 illustrant une étape de sauvegarde de données et la FIG. 2 une étape de restauration des données, - la FIG. 3 et la FIG. 3 montrent un portefeuille de cryptoactifs selon l’invention et l'architecture d'un système prévu pour la mise en œuvre d'un deuxième mode de réalisation du procédé selon l'invention, la FIG. 3 illustrant une étape de sauvegarde de données et la FIG. 3 une étape de restauration des données, - la FIG. 4 et la FIG. 4 décrivent un algorithme exécuté par le système des figures 3A, 3B, lors de l'étape de sauvegarde de données, - la FIG. 4 est un diagramme de séquences qui représente les étapes de l'algorithme des figures 4A, 4B sous forme d'interactions entre différents éléments du système des figures 3A, 3B, - la FIG. 5 et la FIG. 5 décrivent un algorithme exécuté par le système des figures 3A, 3B, lors de l'étape de restauration de données, - la FIG. 5 est un diagramme de séquences qui représente les étapes de l'algorithme de la FIG. 5 , 5B sous forme d'interactions entre différents éléments du système des figures 3A, 3B, - la FIG. 6 et la FIG. 6 montrent un portefeuille de cryptoactifs selon l’invention et l'architecture d'un système prévu pour la mise en œuvre d'un troisième mode de réalisation du procédé selon l'invention, la FIG. 6 illustrant une étape de sauvegarde de données et la FIG. 6 une étape de restauration des données, - la FIG. 7 montre un portefeuille de cryptoactifs selon l’invention et un exemple d'architecture de portefeuille matériel selon l'invention permettant la mise en œuvre du procédé selon l'invention, - la FIG. 8 montre un autre mode de réalisation d’un portefeuille de cryptoactifs permettant de mettre en œuvre le procédé selon l’invention, - la FIG. 9 montre encore un autre mode de réalisation d’un portefeuille de cryptoactifs permettant de mettre en œuvre le procédé selon l'invention. Description détaillée L'invention prévoit un procédé permettant de réaliser un portefeuille de cryptoactifs offrant une fonctionnalité unique dans le domaine des portefeuilles matériels, à savoir une fonctionnalité de sauvegarde de la graine qui est automatisée tout en étant hautement sécurisée. Une telle fonctionnalité permet aux utilisateurs de s'affranchir de toutes les difficultés et dangers qui s'attachent au fait de devoir préserver eux-mêmes dans un lieu sûr une phrase de récupération. La FIG. 2 montre un portefeuille de cryptoactifs CW1 et un système prévu pour la mise en œuvre d'un mode de réalisation du procédé de l'invention. Le portefeuille de cryptoactifs CW1 comprend ici un dispositif HW et un dispositif hôte HDV. Le dispositif HW est un portefeuille matériel ("hardware wallet") assurant le stockage à froid d’une graine S ou clé maître, d’un ensemble de cryptoactifs. Le dispositif HW ne comporte aucun moyen de connexion à l'internet et est relié au dispositif hôte HDV, qui exécute un logiciel compagnon HSW lui permettant de se relier à l'Internet, par exemple au moyen d'une liaison USB ou Bluetooth. Le système et le procédé selon l'invention permettent de sauvegarder ou de restaurer la graine S (clé maître) stockée dans le dispositif HW. Le système comprend essentiellement un ensemble de m serveur de sauvegarde BCKi (BCK1, BCK2,… BCKi,…BCKm) pourvu chacun d'une mémoire de sauvegarde MEM (disque dur magnétique ou mémoire à l'état solide) pour sauvegarder des parts Si de la graine S. Chaque serveur de sauvegarde comporte un programme dorsal BEi (BE1,…BEi,…BEm), ou programme "back-end", conçu pour la mise en œuvre du procédé. Chaque serveur de sauvegarde BCKi est également associé à un module de sécurité HSM. Selon le procédé de l'invention, le dispositif HW est configuré pour diviser la graine S en une pluralité de données secrètes Si (S1, S2…Si,…Sm) qui seront sauvegardées sur les serveurs BCKi. Plutôt qu'un simple fractionnement, qui n'est toutefois pas exclu du champ de la présente invention, cette "division" est de préférence assurée au moyen d'une fonction de partage de secret SS permettant de générer un nombre m de données secrètes appelées "parts " ("shares"), et permettant la reconstitution de la graine à partir d’un seuil de n données secrètes Si : S1, S2,…, Si,…, Sm = SS (S) Par exemple si m est égal à 3 et n égal à 2, la fonction SS permet de diviser la graine en trois parts S1, S2, S3 mais deux parts seulement seront nécessaires pour reconstituer la graine. Si m est égal à 2 et n égal à 2, la fonction SS permet de diviser la graine en deux parts S1, S2 qui sont toutes deux nécessaires pour reconstituer la graine. Lorsque l'utilisateur souhaite sauvegarder sa graine, le dispositif HW établit avec chaque serveur de sauvegarde BCKi, par l'intermédiaire du dispositif hôte HDV, des liaisons de données LNKi (LNK1 à LNKm), par exemple de type HTTPS. Ces liaisons de données sont ensuite sécurisées par la création de canaux sécurisés de type SCP ("Secure Channel Protocol") entre le dispositif HW et chaque serveur de sauvegarde BCKi, d'une manière qui va être décrite. La création de tels canaux sécurisés est assurée au moyen d'une infrastructure à clés publiques gérée par une autorité de certification CA. Le dispositif HW et les serveurs de sauvegarde BCKi possèdent chacun une clé privée, une clé publique, un certificat signé par l'autorité de certification, ou certificat statique, ainsi que la clé publique de l'autorité de certification. La notation suivante sera utilisée dans ce qui suit : pL : clé privée de l'autorité de certification PL : clé publique de l'autorité de certification pD : clé privée du dispositif HW PD : clé publique du dispositif HW CD = [PD, Sign(pL, PD)] : certificat du dispositif (certificat statique), comprenant sa clé publique PD et une signature de sa clé publique au moyen de la clé privée pL de l'autorité de certification pBi : clé privée d'un serveur BCKi (pour i allant de i à m) PBi : clé publique d'un serveur BCKi (pour i allant de i à m) CBi = [PBi, Sign(pL, PBi)] : certificat d'un serveur BCKi (certificat statique), comprenant sa clé publique PD et une signature de sa clé publique au moyen de la clé privée pL de l'autorité de certification. La fonction de signature "Sign" est par exemple générée au moyen d'un algorithme de signature ECDSA basé sur les courbes elliptiques ("Elliptic Curve Digital Signature Algorithm"). L'autorité de certification CA est de préférence détenue par le fabricant du dispositif HW, pour lui permettre de contrôler l'allocation de certificats CBi aux serveurs de sauvegarde BCKi. Les serveurs de sauvegarde BCKi peuvent quant à eux être détenus par le fabricant du dispositif HW, ou être des serveurs de tiers partenaires participant à la mise en œuvre du procédé. Les clés pBi, PBi des serveurs de sauvegarde BCKi sont détenues par leurs modules HSM respectifs, qui prennent en charge les calculs cryptographiques réalisés au moyen de ces clés. Dans ce qui suit et dans un souci de simplification du langage, on considérera que de tels calculs cryptographiques sont réalisés par les serveurs eux-mêmes. Pour mettre en œuvre un canal de communication sécurisé, un échange de clés est prévu entre le dispositif HW et chaque serveur de sauvegarde BCKi, permettant de générer des clés de session kBi propres à chaque serveur BCKi mais connues du dispositif HW. Cet échange de clés est par exemple un échange de clés Diffie Hellman réalisé conformément aux étapes suivantes : i) chaque serveur de sauvegarde BCKi génère une paire de clés privée peBi et publique PeBi éphémères au moyen d'un générateur de clés asymétriques, puis communique sa clé publique éphémère PeBi au dispositif HW dans un certificat éphémère CeBi qu'il a signé avec sa clé privée pBi, ainsi que son certificat CBi signé par l'autorité de confiance : CeBi = [PeBi, Sign(pBi, PeBi)] CBi = [PBi, Sign(pL, PBi)] ii) le dispositif HW génère lui-même une paire de clés privée peD et publique PeD éphémères, puis communique sa clé publique éphémère PeD aux serveurs de sauvegarde BCKi dans un certificat éphémère CeD qu'il a signé avec sa clé privée pD, ainsi que son certificat CD signé par l'autorité de confiance, soit : CeD = [PeD, Sign(pD, PeD)] CD = [PD, Sign(pL, PD)] iii) chaque serveur de sauvegarde BCKi vérifie la signature de la clé publique éphémère PeD du dispositif HW au moyen de la clé publique PD présente dans son certificat CD, puis vérifie la signature de la clé publique PD présente dans le certificat CD au moyen de la clé publique PL de l'autorité de certification, ou vice-versa (vérification de la signature de la clé publique PD avant vérification de la signature de la clé publique éphémère PeD), iv) de même, le dispositif HW vérifie la signature de la clé publique éphémère PeBi de chaque serveur BCKi au moyen de la clé publique PBi présente dans le certificat CB, puis vérifie la signature de la clé publique PBi présente dans le certificat CB au moyen de la clé publique PL de l'autorité de certification, ou vice-versa, v) chaque serveur de sauvegarde BCKi génère une clé de session éphémère kBi à partir de sa clé privée éphémère peBi et de la clé publique éphémère PeD du dispositif HW, au moyen d'une fonction d'échange de clés telle, par exemple la fonction ECDH (échange de clé Diffie Hellman basée sur les courbes elliptiques ou "Elliptic Curve Diffie–Hellman"), soit : kBi = ECDH(peBi, PeD) vi) le dispositif HW génère la clé de session éphémère kBi de chaque serveur de sauvegarde BCKi à partir de sa clé privée éphémère peD et de la clé publique éphémère PeBi du serveur de sauvegarde BCKi, au moyen de la même fonction, soit : kBi = ECDH(peD, PeBi) Après avoir généré les parts Si de la graine S, le dispositif HW conduit des étapes de chiffrement symétrique de chaque part Si avec la clé de session kBi commune au serveur de sauvegarde BCKi à qui la part Si doit être envoyée, qui forme donc une clé partagée. Dans un exemple simple de mise en œuvre, le dispositif HW génère trois parts S1, S2, S3 (le seuil n pouvant alors être égal à 2 ou à 3) et trois serveurs de sauvegarde BCK1, BCK2, BCK3 sont prévus. Chaque serveur BCKi génère sa propre clé de session kB1, kB2, kB3 et le dispositif HW génère de son côté chacune de ces clés de sessions après un échange de clés avec chaque serveur de la manière qui vient d'être décrite. Ensuite, le dispositif HW conduit des étapes de chiffrement symétrique des parts S1, S2, S3 au moyen de ces clés, soit : - chiffre la part S1 avec la clé kB1, soit {S1}kB1, puis l'envoie au serveur BCK1, - chiffre la part S2 avec la clé kB2, soit {S2}kB2, puis l'envoie au serveur BCK2, - chiffre la part S3 avec la clé kB3, soit {S3}kB3, puis l'envoie au serveur BCK3. Chaque serveur de sauvegarde BCKi déchiffre ensuite la part chiffrée {Si}kBi qu'il a reçu du dispositif HW, et la stocke dans sa mémoire MEM. Selon le procédé, et comme illustré sur la FIG. 2 , la restauration de la graine S est réalisée dans un deuxième portefeuille matériel noté HW'. Il peut s'agir d'un autre dispositif que le dispositif HW si celui-ci a été perdu, volé ou détruit. Il peut aussi s'agir du dispositif HW si celui-ci a été réinitialisé, le dispositif HW étant alors considéré comme un "autre" dispositif sous l'angle du procédé, puisqu'il ne possède plus la graine. Pour la restauration de la graine, les étapes de création de canaux sécurisés décrites ci-dessus sont répétées. De nouvelles clés de sessions kBi sont générées. Ensuite, chaque serveur chiffre la part Si qu'il détient avec la clé de session kBi, soit {Si}kBi, puis l'envoie au dispositif HW. Ce dernier déchiffre ensuite chaque part Si au moyen de la clé de session kBi correspondante, puis reconstitue la graine S au moyen de la fonction inverse de celle qui a permis de générer les parts Si, notée "SS -1 " : S = SS -1 (S1, S2,…, Si,…, Sm) La FIG. 3 montre l'architecture d'un système permettant de mettre en œuvre un autre mode de réalisation du procédé de l'invention. Dans ce mode de réalisation, un serveur ORCSRV1 est interposé entre le dispositif hôte HDV et les serveurs de sauvegarde BCKi. Ce serveur, appelé à titre non limitatif "serveur orchestrateur", exécute un programme dorsal ou "back-end" ORC1 appelé dans ce qui suit "programme orchestrateur" ou "orchestrateur". Le serveur ORCSRV1 est relié à un module de sécurité HSM pourvu d'une clé privée pO, d'une clé publique PO, et d'un certificat CO (certificat statique) signé par l'autorité de certification CA : CO = [PO, Sign(pL, PO)] Pour la mise en œuvre du procédé, une première liaison de données LNK1 est établie entre le dispositif HW et l'orchestrateur ORC1 au moyen du dispositif hôte HDV, par exemple une liaison HTTPS. Une pluralité de liaisons de données LNK2i sont également établies entre l'orchestrateur et les serveurs de sauvegarde BCKi, par exemple des liaisons HTTPS, VPN IPsec, etc. La liaison de données entre l'orchestrateur et le dispositif HW est sécurisée par la création d'un canal sécurisé selon la même technique que celle décrite ci-dessus : i) l'orchestrateur ORC1 génère une paire de clés privée PeO et publique PeO puis communique sa clé publique éphémère PeO au dispositif HW dans un certificat éphémère CeO qu'il a signé avec sa clé privée pO, accompagné de son certificat CO signé par l'autorité de confiance, soit : CeO = [PeO, Sign(pO, PeO)] CO = [PO, Sign(pL, PO)] ii) le dispositif HW génère une paire de clés privée peD et publique PeD éphémères puis communique sa clé publique éphémère PeD à l'orchestrateur dans un certificat éphémère CeD qu'il a signé avec sa clé privée pD, accompagné de son certificat CD signé par l'autorité de confiance, soit : CeD = [PeD, Sign(pD, PeD)] CD = [PD, Sign(pL, PD)] iii) l'orchestrateur ORC1 vérifie la signature de la clé publique éphémère PeD du dispositif HW au moyen de la clé publique PD présente dans le certificat CD, puis vérifie la signature de la clé publique PD au moyen de la clé publique PL de l'autorité de certification, ou vice-versa, iv) de même, le dispositif HW vérifie la signature de la clé publique éphémère PeO de l'orchestrateur au moyen de la clé publique PO présente dans le certificat CO, puis vérifie la signature de la clé publique PO au moyen de la clé publique PL de l'autorité de certification, ou vice-versa, v) l'orchestrateur ORC1 génère une clé de session éphémère k0 à partir de sa clé privée éphémère peO et de la clé publique éphémère PeD du dispositif HW : k0 = ECDH(peO, PeD) vi) le dispositif HW génère la clé de session éphémère k0 à partir de sa clé privée éphémère peD et de la clé publique éphémère PeO de l'orchestrateur : k0 = ECDH(peD, PeO) Une fois le canal sécurisé créé entre l'orchestrateur et le dispositif HW, des données à l'attention des serveurs de sauvegarde BCKi peuvent être envoyées en toute sécurité par le dispositif HW à l'orchestrateur, grâce à un chiffrement symétrique au moyen de la clé de session partagée k0 de tout ou partie des données échangées. Réciproquement l'orchestrateur peut communiquer au dispositif HW sous une forme chiffrée au moyen de la clé k0 des données reçues des serveurs de sauvegarde BCKi. Des canaux sécurisés sont également créés entre le dispositif HW et les serveurs de sauvegarde BCKi au moyen de clés de session kBi qui sont générées au terme d'un échange de clés par l'intermédiaire de la liaison de données LNK1, l'orchestrateur agissant comme passerelle ou "serveur proxy" entre le dispositif HW et les serveurs BCKi. Après exécution de ces étapes, on distingue : - à travers la liaison de données LNK1, un canal sécurisé par la clé de session k0 partagée par l'orchestrateur et le dispositif HW, qui permet de chiffrer les données échangées entre l'orchestrateur et le dispositif HW, - à travers les liaisons de données LNK2i, des canaux sécurisés par les clés de session kBi propre à chaque serveur de sauvegarde BCKi et connues du dispositif HW, ce qui permet au dispositif HW d'échanger avec chaque serveur BCKi des données sous forme chiffrée. Il peut par ailleurs être prévu, dans certains cas, de chiffrer avec la clé k0 des données qui sont reçues par l'orchestrateur sous une forme chiffrée par les clés kBi, ce qui correspond à un surchiffrement de ces données. Dans un mode de réalisation, les étapes relatives à l'échange de clés précédemment décrites sont modifiées comme suit : i) l'orchestrateur génère une clé privée éphémère peO, une clé publique éphémère PeO et un certificat éphémère CeO signé avec sa clé privée pO, et transfère son certificat éphémère CeO au dispositif ainsi que son certificat CO : CeO = [PeO, Sign(pO, PeO)] CO = [PO, Sign(pL, PO)] ii) le dispositif HW génère une clé privée éphémère peD et une clé publique éphémère PeD et calcule une première signature Sign(pD, PeD) de sa clé publique éphémère PeD à partir de sa clé privée pD et au moyen de l'algorithme ECDSA, iii) le dispositif génère la clé de session k0 à partir de sa clé privée éphémère peD et de la clé publique éphémère PeO de l'orchestrateur, iv) le dispositif chiffre son certificat CD avec la clé de session k0 : {CD}k0 v) le dispositif chiffre la première signature Sign(pD, PeD) au moyen de la clé de session k0 : {Sign(pD, PeD)}k0 vi) le dispositif transfère à l'orchestrateur son certificat CD chiffré avec la clé de session k0 ainsi que son certificat éphémère CeD comprenant la signature de sa clé publique éphémère PeD chiffrée avec la clé de session k0 : {CD}k0 || CeD soit {CD}k0 || PeD || {Sign(pD, PeD)}k0 ("||" étant le symbole de la concaténation) vii) l'orchestrateur génère la clé de session k0 à partir de sa clé privée éphémère peO et de la clé publique éphémère PeD reçue du dispositif , et viii) au moyen de la clé de session k0, l'orchestrateur déchiffre la signature présente dans le certificat éphémère CeD et déchiffre le certificat CD du dispositif. De retour à la FIG. 3 , il ressort de ce qui précède que la prévision de l'orchestrateur ORC1 permet de réduire le nombre de liaison de données entre le dispositif HW et les serveurs de sauvegarde BCKi, ces liaisons étant remplacées par l'unique liaison de données LNK1 entre le dispositif HW et l'orchestrateur, tout en assurant un degré de sécurité supplémentaire grâce à la possibilité de surchiffrer des données transitant par la liaison LNK1. Il est de plus possible de préserver la confidentialité de la clé publique PD grâce aux perfectionnements qui viennent d'être décrits. La prévision de l'orchestrateur présente divers autres avantages qui seront décrits plus loin en relation avec la mise en œuvre d'étapes de vérification de l'identité de l'utilisateur. L'étape de sauvegarde de la graine S peut dans ce cas être mise en œuvre comme suit, en référence à la FIG. 3 : i) établissement de la liaison LNK1 entre le dispositif HW et l'orchestrateur et envoi par le dispositif HW d'une requête en sauvegarde BCKRQ à l'orchestrateur, ii) génération par l'orchestrateur d'un identifiant aléatoire BCKID de la sauvegarde, établissement des liaisons LNK2i entre l'orchestrateur et les serveurs de sauvegarde BCKi, envoi par l'orchestrateur aux serveurs de sauvegarde BCKi de l'identifiant BCKID, iii) création du canal sécurisé entre le dispositif HW et l'orchestrateur ORC1 au moyen de la clé de session k0, iv) création de canaux sécurisés entre le dispositif HW et les serveurs de sauvegarde BCKi au moyen des clés de session kBi, par l'intermédiaire de l'orchestrateur ORC1, v) génération par le dispositif HW des parts Si de la graine S : S1, S2,…, Si,…, Sm = SS (S) vi) chiffrement par le dispositif HW de chaque part Si au moyen de la clé de session kBi du serveur de sauvegarde BCKi à qui la part Si est destinée, vii) envoi par le dispositif HW de l'ensemble des parts chiffrées {Si}kBi à l'orchestrateur : {S1}kB1||{S2}kB2||….||{Si}kBi||…||{Sm}kBm viii) envoi par l'orchestrateur à chaque serveur de sauvegarde BCKi de la part chiffrée {Si}kBi qui lui est destinée, ix) déchiffrement par chaque serveur BCKi de la part Si qui lui est communiquée, et stockage dans sa mémoire en association avec l'identifiant de la sauvegarde BCKID. Par ailleurs, l'étape de restauration de la graine S dans un nouveau dispositif HW', illustrée sur la FIG. 3 , déclenchée à la demande de l'utilisateur USR, comprend les étapes suivantes, : i) établissement de la liaison LNK1 entre le dispositif HW et l'orchestrateur et envoi par le dispositif HW d'une requête en restauration RESTRQ à l'orchestrateur, accompagnée de l'identifiant de la sauvegarde BCKID, ii) établissement des liaisons LNKi entre l'orchestrateur et les serveurs de sauvegarde BCKi, et envoi par l'orchestrateur aux serveurs de sauvegarde BCKi de l'identifiant BCKID, pour qu'ils soient informés de la restauration à réaliser, iii) création du canal sécurisé entre le dispositif HW et l'orchestrateur ORC1 au moyen d'une nouvelle clé de session k0, iv) création de canaux sécurisés entre le dispositif HW et les serveurs de sauvegarde BCKi au moyen de nouvelles clés de session kBi, par l'intermédiaire de l'orchestrateur ORC1, v) lecture par chaque serveur de sauvegarde BCKi, dans sa mémoire, au moyen de l'identifiant BCKID, de la part Si qu'il détient, et chiffrement de celle-ci au moyen de la nouvelle clé de session kBi, vi) transmission à l'orchestrateur, par chaque serveur de sauvegarde BCKi, de la part chiffrée {Si}kBi, vii) collecte par l'orchestrateur de toutes les parts chiffrées {Si}kBi fournies par les serveurs de sauvegarde BCKi : {S1}kB1, {S2}kB2,…., {Si}kBi,…, {Sm}kBm viii) transmission au dispositif HW de chaque part chiffrée {Si}kBi, une après l'autre ou toutes ensemble : {S1}kB1||{S2}kB2||….||{Si}kBi||…||{Sm}kBm ix) déchiffrement, par le dispositif HW, de chaque part Si au moyen de la clé de session kBi du serveur de sauvegarde BCKi correspondant : Si = {Si} -1 kBi x) reconstitution de la graine par le dispositif HW et stockage de celle-ci dans sa mémoire : S = SS -1 (S1, S2,…, Si,…, Sm) Il sera noté que dans un mode de réalisation l'orchestrateur peut ne collecter que n parts nécessaires à la reconstitution de la graine, si n est inférieur à m. Dans ce cas, la graine est reconstituée à partir des n parts récupérées : S = SS -1 (S1, S2,…, Si,…, Sn) On a supposé dans ce qui précède que l'identifiant de la sauvegarde BCKID a été conservé par le logiciel compagnon HSW du dispositif hôte HDV malgré la perte du dispositif HW utilisé lors de la sauvegarde. Dans un mode de réalisation permettant de prévenir le cas où l’utilisateur aurait désinstallé définitivement le logiciel compagnon HSW, un serveur de comptes clients UASRV peut être prévu, comprenant un compte utilisateur UACC dans lequel diverses données concernant l'utilisateur sont conservées, notamment l'identifiant BCKID de la sauvegarde. Le serveur UASRV est associé à un module de sécurité HSM recevant une clé privée pC, une clé publique PC, un certificat CC signé par l'autorité de certification, et la clé publique PL de cette dernière. Dans ce cas, le dispositif HW' établit une liaison de données avec le serveur UASRV grâce à un échange de clés permettant de définir une clé de session pour la création d'un canal sécurisé, avec vérification réciproque des certificats. Une fois le canal sécurisé établi, le logiciel compagnon HSW se connecte au compte client UACC pour récupérer l’identifiant BCKID. Dans une variante, l’identifiant BCKID est stocké sur le serveur UASRV mais n'est pas communiqué au logiciel compagnon. Une liaison sécurisée est établie entre le serveur UASRV et l'orchestrateur ORC1. L'orchestrateur transfère l'identifiant BCKID au serveur UASRV au moment de la sauvegarde et réciproquement reçoit l'identifiant BCKID du serveur UASRV lorsque l'utilisateur veut restaurer sa graine. Dans un mode de réalisation, l'identité de l'utilisateur est également associée au processus de sauvegarde, en définissant un ensemble de données PID formant une "identité pivot" permettant de l'identifier. Les informations formant l'identité pivot comprennent par exemple le prénom, le nom et la date de naissance de l'utilisateur, et optionnellement d'autres données telles que son lieu de naissance. Ces informations sont collectées par le logiciel compagnon et sont communiquées à l'orchestrateur qui les rassemble pour former une chaîne binaire que l'on désignera "c" BCKDT. Dans certains modes de réalisation, les données BCKDT contiennent, en sus des données PID, des données ODT autres que celles relatives à l’identité de l’utilisateur, comme la date et l’heure de la sauvegarde, et/ou un nom donné par l’utilisateur à la sauvegarde (pour lui permettre ultérieurement de distinguer plusieurs sauvegardes, s’il détient plusieurs portefeuilles matériels). Dans ce cas les données BCKDT s’écrivent comme suit : BCKDT = PID||ODT A l’initialisation de la sauvegarde, comme montré sur la FIG. 3 , l’orchestrateur communique les données BCKDT aux serveurs de sauvegarde BCKi qui vont les associer, ainsi que l’identifiant BCKID, aux parts Si sauvegardées. Pour des raisons de confidentialité, il pourrait être préféré, dans certains modes de réalisation, que l’orchestrateur ne conserve pas les données BCKDT une fois la sauvegarde réalisée. Les données BCKDT sont dans ce cas uniquement conservées par les serveurs BCKi, qui les communiquent à l’utilisateur USR pour confirmation par ce dernier de son identité au moment de la restauration, comme montré sur la FIG. 3 . Dans un mode de réalisation du procédé, l’identité pivot de l’utilisateur est vérifiée au cours d’au moins une étape de vérification d’identité désignée « IDV » (« Identity Vérification ») qui est conduite avant la restauration de la graine. Dans un mode de réalisation, plusieurs étapes de vérification d’identité IDVi sont de préférence prévues avant de procéder à la restauration de la graine, ces étapes étant conduites par tout ou partie des serveurs de sauvegarde BCKi sollicités pour la restitution d’une part Si de la graine S. Dans un mode de réalisation montré sur la FIG. 3 , ces étapes de vérification d’identité sont confiées à des prestataires spécialisés au lieu d’être réalisées par les serveurs de sauvegarde BCKi eux-mêmes. De tels prestataires possèdent des serveurs IDVSRVi exécutant chacun un service de vérification d’identité automatisé IDVSi accessible via une passerelle GTW (« Gateway »). Chaque serveur de sauvegarde BCKi peut se voir attribuer un serveur IDVSRVi différent, et être configuré pour se relier à la passerelle GTW du service IDVSi exécuté par ce serveur. De préférence, de tels services IDVSi ne sont pas entièrement automatisés, au moins pour une partie d’entre eux, et incluent une intervention humaine notamment en cas de doute sur l’identité d’une personne. Ainsi, chaque serveur de sauvegarde BCKi ou au moins une partie d’entre eux, est configuré pour réaliser une étape IDVi de vérification de l’identité pivot de l’utilisateur lorsqu’il reçoit une demande de restitution d’une part de la graine. Le serveur est alors de préférence configuré pour refuser de restituer la part si cette vérification n’est pas concluante. Dans un mode de réalisation, l’étape de sauvegarde de la graine est également précédée d’une étape initiale IDV0, conduite par l’orchestrateur ou supervisée par celui-ci, de vérification de l’identité pivot de l’utilisateur (soit au moins son prénom, son nom et sa date de naissance). Dans ce cas, un serveur IDVSRV0 est également associé à l’orchestrateur ORC1, et l’orchestrateur est configuré pour se relier à une passerelle GTW d’un service IDVS0 exécuté par ce serveur pour la réalisation de l’étape IDV0. Au cours de l’étape optionnelle IDV0 précédant la sauvegarde ou de chacune des étapes IDVi intervenant avant la restitution des parts de la graine, l’orchestrateur met l’utilisateur USR en relation avec le service IDVS0 ou IDVSi approprié, via la passerelle GTW appropriée. L’utilisateur doit réaliser certaines actions qui lui sont demandées par l’intermédiaire de l’écran du dispositif hôte HDV et la caméra dont il est équipé (par exemple une caméra de téléphone mobile, une webcam d’ordinateur personnel, etc.). A titre d’exemple, le service IDVS0 ou IDVSi lui demande de présenter une pièce d’identité valide comprenant une photo de sa personne, de prendre une photo de la pièce d’identité avec sa caméra et de la lui envoyer Le service IDVS0 ou IDVSi lui demande ensuite de prendre une photo (selfie) ou une vidéo de son visage et de l’envoyer. Le service IDVS0 ou IDVSi vérifie ensuite l'authenticité de la pièce d'identité à partir de la photo ou de la vidéo de son visage, et la pièce d’identité, une fois vérifiée, lui permet de vérifier les données de l’identité pivot avec un degré de certitude qui peut, dans certains modes de réalisation, donner lieu à un score. Le résultat de cette vérification, et optionnellement le score, est communiqué à l’orchestrateur. Dans un mode de réalisation, les étapes d’IDV peuvent également inclure des vérifications sur des bases gouvernementales. Bien que l’étape IDV0 ne soit pas aussi critique que celles réalisées par les serveurs BCKi au moment de la restitution des parts Si, elle permet de s’assurer que l’utilisateur n’a pas fait d’erreur en fournissant les informations relatives à son identité, qui sont incorporées dans les données BCKDT. Par ailleurs, les informations collectées par l’orchestrateur au cours de cette étape, telle que la photo de sa pièce d’identité et la photo ou la vidéo de son visage, peuvent optionnellement être communiquées aux serveurs de sauvegarde BCKi par un canal de communication spécifique, puisque ces informations ne font pas partie des données de la sauvegarde BCKDT. Dans un mode de réalisation, l’orchestrateur ORC1 peut suspendre le processus de sauvegarde de la graine s’il estime que la vérification initiale de l’identité de l’utilisateur n’est pas concluante ou se voit attribuer un score trop faible. Par ailleurs, dans un autre mode de réalisation ou en complément, l’orchestrateur reçoit des serveurs de sauvegarde BCKi des informations sur le succès des étapes de vérification d’identité IDVi qu’ils ont conduites ou qui ont été conduites par les prestataires auxquels ils sont affiliés. Si un nombre déterminé de serveurs BCKi n’a pas vérifié avec succès l’identité de l’utilisateur et refuse de restituer les parts Si qu’ils détiennent, l’orchestrateur peut être configuré pour suspendre la restitution des parts Si par les serveurs qui ont vérifié avec succès l’identité de l’utilisateur. L’orchestrateur peut optionnellement décider de soumettre l’utilisateur à une étape supplémentaire de vérification de son identité. Dans une variante, ou en complément, l’orchestrateur reçoit de chaque serveur de sauvegarde BCKi ayant conduit une étape de vérification d’identité, un score de certitude quant à l’identité de l’utilisateur. Si la moyenne des scores est inférieure à un premier seuil, et/ou si l’un des scores est inférieur à un deuxième seuil, l’orchestrateur suspend le processus de restauration et optionnellement soumet l’utilisateur à une étape supplémentaire de vérification de son identité. Dans le cas, ultime, où l’utilisateur aurait fermé son compte sur le serveur de compte UASRV, aurait désinstallé le logiciel compagnon en effaçant les données qu’il comportait, et aurait perdu son portefeuille matériel HW et ne pourrait donc plus récupérer l’identifiant de la sauvegarde BCKID, une solution peut être prévue pour lui permettre de récupérer sa graine. L’utilisateur devra alors se soumettre à une pluralité d’étapes individuelles de vérification de son identité auprès de chaque serveur BCKi pour récupérer chaque part Si de la graine. Une procédure faisant intervenir un officier ministériel, tel un notaire, peut également être prévue. Chaque prestataire d’IDV pourra également vérifier que sa démarche est légitime en s’assurant qu’il n’existe aucun compte attaché à cet utilisateur dans le serveur de comptes du système, et confier à des personnes physiques des procédures d’investigation plus approfondies, telles que la conduite d’un entretien téléphonique avec l’utilisateur, la conduite d’une vidéo conférence avec l’utilisateur, la conduite d’un entretien en face à face avec l’utilisateur, la validation d’un parcours scolaire ou d’un parcours d’employé de l’utilisateur, etc. Il apparaîtra clairement à l’homme de l’art que le procédé de l’invention est susceptible de divers autres modes de réalisation et variantes. Notamment, les données de la sauvegarde BCKID pourraient, dans un mode de réalisation, inclure sous une forme compressée les données recueillies à l’étape IDV0 pour vérifier l’identité pivot de l’utilisateur, telle que la photo ou la vidéo de son visage et une photo d’une pièce d’identité. Les étapes automatisées de vérification de l’identité pivot de l’utilisateur telles que conduites par des services IDVSi exécutés par des serveurs IDVSRVi ou par les serveurs de sauvegarde BCKi eux-mêmes, peuvent comprendre au moins deux des étapes suivantes : acquisition, par l’intermédiaire d’une caméra, d’une photo d’une pièce d’identité non périmée comprenant une photo de l’utilisateur ; acquisition, par l’intermédiaire d’une caméra, d’une ou de plusieurs photos du visage de l’utilisateur ; acquisition, par l’intermédiaire d’une caméra, d’un enregistrement vidéo montrant le visage de l’utilisateur en mouvement, avec détection du vivant pour vérifier que l’utilisateur est réel ; acquisition d’une justification de domicile, telle une facture d’électricité, de téléphone ; acquisition d’une empreinte digitale de l’utilisateur ; acquisition d’un code de validation reçu par l’utilisateur dans un message téléphonique, par email ou par courrier ;activation par l’utilisateur d’un lien reçu par l’utilisateur dans un message téléphonique, par email ou par courrier, et acquisition d’un hologramme présent sur une pièce d’identité non périmée. On décrira maintenant en relation avec les figures 4A et 4B un exemple d’algorithme de sauvegarde de la graine applicable au système de la FIG. 3 et mettant en œuvre divers aspects des modes de réalisation du procédé précédemment décrits. La FIG. 4 est un diagramme de séquences qui représente les étapes de l’algorithme sous forme d’interactions entre : - l’utilisateur USR, - le dispositif HW et son dispositif hôte HDV (considérés comme une seule et même entité formant le portefeuille de cryptoactifs CW1), - l’orchestrateur ORC1 et le module de sécurité HSM qui lui est associé (considérés également comme une seule et même entité), et - le serveur IDVSRV0 associé à l’orchestrateur pour réaliser l’étape IDV0 de vérification de l’identité de l’utilisateur, - les serveurs de sauvegarde BCKi, et - les serveurs IDVSRVi associés aux serveurs BCKi pour réaliser les étapes de vérification d’identité ultérieures, au moment de la restauration de la graine. Certaines fonctions utilisées dans l’algorithme sont indiquées dans le tableau 1 ci-après, à titre d’exemple non limitatif : Type de cryptographie Cryptographie à courbes elliptiques Sign Signature de type ECDSA (« Elliptic Curve Digital Signature Algorithm ») avec la courbe elliptique secp256k1 ECDH Échange de clés Diffie-Hellman basé sur les courbes elliptiques utilisant par exemple la courbe elliptique secp256k1 Fonction de hachage SHA-256 (« Secure Hash Algorithm ») Chiffrement symétrique {.}k0 Algorithme AEAD-AES-SIV-CMAC-256 Fonction SS Fonction de Partage de secret de Shamir ou autre fonction similaire, ou Partage de secret vérifiable publiquement de Pedersen PVSS basé sur la courbe secp384r1 Description de l’algorithme, en relation avec les figures 4A, 4B et 4C. B1. Initialisation de la sauvegarde L’utilisateur USR sélectionne dans le dispositif HW une option de sauvegarde de la graine. L’utilisateur, par l’intermédiaire du dispositif hôte HDV, crée un compte de sauvegarde sur le serveur de compte UASRV. Le dispositif HW établit une liaison de données avec l’orchestrateur ORC1 et lui envoie la requête en sauvegarde : [HW → ORC1] BCKRQ Optionnellement le dispositif HW offre la possibilité à l’utilisateur de choisir le nombre m de parts Si qu’il souhaite générer pour la sauvegarde de la graine, et le seuil n correspondant au nombre de parts nécessaires à la reconstitution de la graine S. Toujours de manière optionnelle, le dispositif HW peut présenter à l’utilisateur une liste de serveurs de sauvegarde BCKi, certains pouvant être des partenaires externes, et demander à l’utilisateur d’indiquer ceux qu’il souhaite utiliser. Sinon, ceux-ci sont sélectionnés automatiquement par l’orchestrateur. L’orchestrateur ORC1 établit une liaison de données avec les serveurs BCKi, puis engage le processus de sauvegarde selon les étapes décrites dans ce qui suit. B2. Génération et envoi au dispositif HW et aux serveurs BCKi de l’identifiant de la sauvegarde [ORC1 → BCKi, HW] BCKID L’orchestrateur ORC1 génère l’identifiant BCKID de la sauvegarde, par exemple un nombre aléatoire, et le transfère au dispositif HW et aux serveurs BCKi. B3. Réalisation d’une vérification d’identité IDV0 par le serveur IDVSRV0 [IDVSRV0] IDV0 L’orchestrateur ORC1 connecte l’utilisateur au serveur IDVSRV0 à travers une passerelle GTW. Le service IDVS0 procède à une vérification de l’identité pivot de l’utilisateur IDV0. B4. Confirmation par l’orchestrateur du succès de la vérification d’identité IDV_OK → HW Le serveur IDVSRV0 confirme à l’orchestrateur ORC1 que l’IDV a été réalisée avec succès, et l’orchestrateur ORC1 confirme à l’utilisateur par l’intermédiaire du dispositif HW que son identité a été vérifiée et que l’étape de sauvegarde de la graine peut être initiée. A l’occasion de cette étape l’orchestrateur ORC1 peut générer les données de la sauvegarde BCKDT, et les envoyer au dispositif HW. B5. Authentification mutuelle et création d’un canal sécurisé entre l’orchestrateur et le dispositif B5.1. Génération par l’orchestrateur d‘un certificat éphémère (peO, PeO) = AsymKeyGen() Sign(pO, ReO||PeO) CeO = PeO||Sign(pO, ReO||PeO) L’orchestrateur ORC1 génère une clé privée éphémère peO et une clé publique éphémère PeO. L’orchestrateur calcule la signature de sa clé publique éphémère PeO au moyen de sa clé privée pO. Dans une variante retenue ici, l’orchestrateur calcule la signature de sa clé publique éphémère PeO après avoir concaténée celle-ci avec une donnée ReO. La donnée ReO spécifie par exemple le rôle que joue le serveur orchestrateur dans le processus, par exemple le rôle d’orchestrateur pour l’établissement d’un canal sécurisé. L’orchestrateur génère ensuite un certificat éphémère CeO par concaténation de la clé publique éphémère PeO et de la signature. B5.2. Envoi au dispositif des certificats de l’orchestrateur CeO||CO → HW L’orchestrateur ORC1 envoie au dispositif HW son certificat éphémère et son certificat CO. B5.3. Vérification par le dispositif des certificats de l’orchestrateur Verif CeO, Verif CO Le dispositif HW vérifie la chaîne de certificats de l’orchestrateur, de la manière décrite plus haut, au moyen de la clé publique PL de l’autorité de certification. B5.4. Génération par le dispositif HW d’une clé de session k0 et d’un certificat éphémère (peD, PeD) = AsymKeyGen() k0 = ECDH(peD, PeO) Sign(pD, ReD||PeD) {Sign(pD, ReD||PeD)}k0 CeD = PeD||{Sign(pD, ReD||PeD)}k0 {CD}k0 Le dispositif HW génère une clé privée éphémère peD et une clé publique éphémère PeD, puis une clé de session k0 à partir de sa clé privée éphémère peD et de la clé publique éphémère PeO de l’orchestrateur au moyen de l’algorithme ECDH. Le dispositif HW calcule ensuite la signature de sa clé publique éphémère PeD au moyen de sa clé privée pD, ici après avoir concaténé la clé publique éphémère PeD avec une donnée ReD. La donnée ReD spécifie par exemple le rôle que joue HW dans le processus. Le dispositif HW chiffre ensuite la signature de sa clé publique éphémère avec la clé de session k0. Le dispositif HW forme ensuite un certificat éphémère CeD par concaténation de la clé publique éphémère PeD et de la signature chiffrée. Enfin, le dispositif HW chiffre son certificat CD au moyen de la clé k0. B5.5. Envoi à l’orchestrateur des certificats du dispositif [HW → ORC1] CeD||{CD}k0 Le dispositif HW envoie à l’orchestrateur ORC1 son certificat CD chiffré au moyen de la clé k0 ainsi que son certificat éphémère CeD comprenant la signature chiffrée. Grâce au chiffrement du certificat et au chiffrement de la signature du certificat éphémère, la clé publique PD n’est pas exposée. L’ordre de ces étapes peut être inversé, le dispositif pouvant envoyer son certificat, ici chiffré, avant d’envoyer son certificat éphémère, comprenant ici la signature chiffrée. B5.6. Génération par l’orchestrateur de la clé de session k0 k0 = ECDH(peO, PeD) L’orchestrateur ORC1 génère la clé de session k0 à partir de sa clé privée éphémère peO et de la clé publique éphémère PeD du dispositif HW au moyen de l’algorithme ECDH. B5.7. Vérification par l’orchestrateur des certificats du dispositif CD={CD} -1 k0 Sign(pD, ReD||PeD) = {Sign(pD, ReD||PeD)} -1 k0 Verif CeD, Verif CD L’orchestrateur ORC1 déchiffre le certificat CD du dispositif HW ainsi que la signature du certificat éphémère du dispositif HW, puis vérifie la chaîne de certificats. B6. Envoi aux serveurs BCKi des données BCKID, BCKDT et des certificats CeD, CD du dispositif [ORC1 → BCKi] Pour chaque serveur BCKi, i allant de 1 à m BCKID||BCKDT||CeD||CD L’orchestrateur ORC1 envoie à chaque serveur BCKi l’identifiant de la sauvegarde BCKID, les données de la sauvegarde BCKDT qui incluent au moins les données de l’identité pivot. D’autres données peuvent optionnellement être envoyées ou avoir été envoyées aux serveurs de sauvegarde par d’autres canaux, comme la photo ou vidéo du visage de l’utilisateur prise à l’étape IDV0, et la photo d’un document d’identité. Si ces données ne sont pas incluses dans les données de la sauvegarde BCKDT, elles pourront être stockées par le serveur de comptes clients et transmises aux serveurs BCKi après la sauvegarde. B7. Vérification par chaque serveur BCKi des certificats du dispositif Pour chaque serveur BCKi, i allant de 1 à m Verif CeD, Verif CD Chaque serveur BCKi vérifie la chaîne de certificats du dispositif HW de la manière précédemment décrite. B8. Authentification mutuelle et création d’un canal sécurisé entre les serveurs BCKi et le dispositif, par l’intermédiaire de l’orchestrateur B8.1. Génération par chaque serveur BCKi d’un certificat éphémère Pour chaque serveur BCKi, i allant de 1 à m (peBi, PeBi) = AsymKeyGen() Sign(pBi, ReB||PeBi) CeBi = PeBi||Sign(pBi, ReB||PeBi) Chaque serveur BCKi génère une clé privée éphémère peBi et une clé publique éphémère PeBi. Chaque serveur BCKi calcule la signature de sa clé publique éphémère PeBi après l’avoir concaténée avec une donnée ReB au moyen de sa clé privée pBi. ReB spécifie par exemple le rôle que joue chaque serveur dans le processus, par exemple le rôle de serveur de sauvegarde pour la gestion du canal sécurisé. Ensuite chaque serveur BCKi génère un certificat éphémère CeBi par concaténation de la clé publique éphémère PeBi et de sa signature. B8.2. Génération par chaque serveur BCKi d’une clé de session kBi Pour chaque serveur BCKi, i allant de 1 à m kBi = ECDH(peBi, PeD) Chaque serveur BCKi génère ensuite une clé de session kBi à partir de sa clé privée éphémère peBi et de la clé publique éphémère PeD du dispositif HW, au moyen de l’algorithme ECDH. B8.3.1. Génération par chaque serveur BCKi d’un code de hachage chiffré Pour chaque serveur BCKi, i allant de 1 à m Hi = Hash(PeBi||BCKID||BCKDT) CHi = {Hi}kBi Chaque serveur BCKi génère ensuite un code de hachage Hi à partir d’une chaîne binaire comprenant sa clé publique éphémère PeBi, les données BCKID et les données de la sauvegarde BCKDT. Chaque serveur BCKi chiffre ensuite le code Hi au moyen de la clé de session kBi pour obtenir un code de hachage chiffré CHi. B8.3.2. Génération par chaque serveur BCKi d’un code de sauvegarde fonction de l’identité pivot PID de l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m HPIDi = Hash(PID) → STORE Chaque serveur BCKi génère ensuite un code de sauvegarde HPIDi qu’il stocke dans sa mémoire. Le code de sauvegarde HPIDi est au moins fonction des données PID formant l’identité pivot de l’utilisateur. Dans un mode de réalisation, le code de sauvegarde HPIDi est calculé par hachage des données de l’identité pivot PID. Dans un autre mode de réalisation, le code de sauvegarde HPIDi est calculé par hachage des données de la sauvegarde BCKDT, qui contiennent les données de l’identité pivot PID et peuvent contenir les informations complémentaires citées plus haut, comme la date et l’heure de la sauvegarde, et un nom donné par l’utilisateur à la sauvegarde. La fonction de hachage est par exemple la fonction SHA256 (« Secure Hash Algorithm »). B8.4. Envoi à l’orchestrateur des certificats des serveurs BCKi et du code de hachage chiffré [BCKi → ORC1] RETDTi = CeBi||CBi||CHi Chaque serveur BCKi envoie à l’orchestrateur ORC1 une chaîne binaire RETDTi comprenant son certificat éphémère CeBi, son certificat CBi et le code de hachage chiffré CHi. B8.5. Envoi au dispositif des certificats des serveurs BCKi et du code de hachage chiffré [ORC1 → HW] {BCKI D||BCKDT||RETDT1||….||RETDTi||…||RETDTm}ko L’orchestrateur ORC1 renvoie au dispositif les données BCKID, BCKDT et toutes les données RETDTi reçues des serveurs de sauvegarde BCKi, sous une forme chiffrée au moyen de la clé k0. Il sera noté ici que l’orchestrateur n’a pas accès aux données RETDTi car il ne connaît pas les clés privées kBi des serveurs BCKi. Les données dans le canal sécurisé de communication entre l’orchestrateur et le dispositif, sont donc chiffrées deux fois. B8.6. Déchiffrement par le dispositif des certificats des serveurs BCKi et du code de hachage chiffré {BCKID||BCKDT||RETDT1|…||RETDTi||…||RETDTm } -1 k0 Le dispositif HW déchiffre la chaîne de données pour en extraire les données BCKID, BCKDT et les certificats CeBi, CBi, CHi. B8.7. Validation des données BCKDT et des serveurs BCKi par l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m Validate BCKDT, BCKi L’utilisateur personne physique valide les données de la sauvegarde BCKDT et les serveurs BCKi en charge de la sauvegarde, qui lui sont présentées sur l’écran du dispositif hôte. B8.8. Vérification par le dispositif des certificats des serveurs BCKi Pour chaque serveur BCKi, i allant de 1 à m Verif CeBi, Verif CBi Le dispositif HW vérifie la chaîne de certificats de chaque serveur BCKi. B8.9. Génération par le dispositif des clés de session kBi et vérification des codes de hachage chiffrés Pour chaque serveur BCKi, i allant de 1 à m kBi = ECDH(peD, PeBi) {Hi} -1 kBi Validate Hi Pour chaque serveur BCKi, le dispositif HW génère la clé de session kBi puis déchiffre le code Hi et le valide en recalculant lui-même le code Hi et en le comparant au code déchiffré. B9. Préparation de la sauvegarde, génération des m parts Si S1, S2,…Si,..Sm = SS(S) Au moyen de la fonction SS de partage de secret, le dispositif HW génère les m parts Si à sauvegarder dans les différents serveurs BCK1, BCK2… BCKm, avec un seuil de n parts pour récupérer la graine S. Dans une variante B9’ de l’étape B9, l’étape B9’ comprend d’abord le chiffrement de la graine S au moyen d’une clé de chiffrement de graine Kseed et d’une fonction de chiffrement Fseed, avant de générer les m parts Si à sauvegarder dans les différents serveurs BCK1, BCK2… BCKm. La fonction Fseed est par exemple le chiffrement AES 256 soit un chiffrement symétrique, la clé de chiffrement de graine Kseed formant également une clé de déchiffrement. L’étape B9’ comprend dans ce cas les étapes suivantes : S=Fseed(S) Kseed puis : S1, S2,…Si,..Sm = SS(S) Ainsi, les parts Si sont ici générées à partir de la graine chiffrée au moyen de la fonction Fseed et de la clé Kseed. Dans encore une variante B9’ de l’étape B9, ce sont les m parts Si qui, après avoir été générées, sont chiffrées individuellement au moyen de la clé de chiffrement de graine Kseed. Ce chiffrement des parts Si de la graine peut être comme précédemment un chiffrement AES 256. L’étape B9’ comprend dans ce cas les étapes suivantes : S1, S2,…Si,..Sm = SS(S) puis : S1 = Fseed(S1) Kseed S2 = Fseed(S2) Kseed … Si = Fseed(Si) Kseed … Sm = Fseed(Sm) Kseed Dans un souci de simplicité, on utilisera, pour la description des étapes qui suivent, la même notation « Si » pour désigner les parts, que celles-ci soient générées à partir de la graine non chiffrée ou de la graine chiffrée au moyen de la clé de chiffrement de graine, ou encore que celles-ci aient été chiffrées après avoir été générées. D’autres variantes de l’étape B9 peuvent être prévues, notamment une combinaison des deux variantes B9’ et B9’ qui viennent d’être décrites, ou une variante dans laquelle seulement une partie des parts Si fait l’objet de l’étape de chiffrement au moyen de la clé Kseed. Dans un mode de réalisation, la clé de chiffrement de graine Kseed est enregistrée dans une mémoire non volatile du portefeuille matériel HW, par exemple celle qui contient le système d’exploitation du dispositif. Cet enregistrement peut être fait lors de la personnalisation du dispositif, avant sa commercialisation, ou au cours d’une mise à jour de son firmware. Dans un mode de réalisation, la clé de chiffrement de graine Kseed est commune à une pluralité de portefeuilles matériels HW. La clé peut n’être connue que du fabricant des portefeuilles matériels HW, de sorte qu’il n’est pas nécessaire que l’utilisateur la conserve quelque part. Dans un autre mode de réalisation, la clé de chiffrement de graine est dérivée d’un secret connu de l’utilisateur. Par exemple, la clé de chiffrement dérivée d’un secret connu de l’utilisateur et d’une clé de chiffrement stockée dans le portefeuille matériel. B10. Chiffrement des parts Si par le dispositif ( FIG. 4 ) Pour chaque serveur BCKi, i allant de 1 à m {Si}kBi Pour chaque serveur BCKi, le dispositif HW chiffre la part Si qui lui est destinée avec la clé kBi qui lui est propre. Il s’agit ici d’un chiffrement des parts Si au moyen des clés de session kBi propres à chaque serveur BCKi, soit un chiffrement de canal de communication, qu’il convient de distinguer du chiffrement au moyen de la clé de chiffrement de graine Kseed qui a été proposé plus haut en option. Ainsi, si cette option est retenue, les parts Si, avant d’être chiffrées au moyen des clés de session kBi, peuvent avoir été préalablement chiffrées au moyen de la clé de chiffrement de graine Kseed ou être issues d’une graine ayant été préalablement chiffrée avec la clé de chiffrement de graine Kseed. B11. Envoi à l’orchestrateur des parts Si chiffrées [HW → ORC1] {S1}kB1||{S2}kB2||….||{Si}kBi||…||{Sm}kBm → ORC1 Le dispositif HW envoie ensuite l’ensemble des parts à l’orchestrateur ORC1. Il sera noté que l’orchestrateur n’a pas connaissance de la valeur de chaque part Si car celle-ci est chiffrée avec la clé kBi qu’il ne connaît pas. B12. Envoi aux serveurs BCKi des parts Si chiffrées [ORC1 → BCKi] Pour chaque serveur BCKi, i allant de 1 à m BCKID||{Si}kBi → BCKi L’orchestrateur ORC1 envoie à chaque serveur BCKi la part Si chiffrée qui lui est destinée, accompagnée de l’identifiant de la sauvegarde. B13.1. Déchiffrement et enregistrement par chaque serveur BCKi de la part Si. Pour chaque serveur BCKi, i allant de 1 à m {Si} -1 kBi → STORE Chaque serveur BCKi déchiffre la part Si qu’il a reçue. B13.2.a. Sauvegarde par chaque serveur BCKi de la part Si d’une manière telle qu’elle soit liée à l’identité de l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m LNKSi = {Si||HPIDi} pBi → STORE Au cours de cette étape, chaque serveur BCKi concatène la part Si et le code de sauvegarde HPIDi fonction de l’identité pivot de l’utilisateur, tel que calculé à l’étape B8.3.2, puis chiffre la chaîne binaire ainsi obtenue au moyen d’une clé secrète connue de lui seul, par exemple sa clé privée pBi, et d’une fonction cryptographique. La donnée LNKSi résultant de ce calcul, forme une donnée chiffrée de liaison de la part Si et de l’identité pivot PID de l’utilisateur et sera désignée « donnée de liaison chiffrée » dans ce qui suit. La donnée de liaison chiffrée LNKSi est ensuite stockée dans la mémoire MEM de chaque serveur BCKi. Ainsi, la part Si telle que sauvegardée dans la mémoire de chaque serveur BCKI, est liée à l’identité pivot PID de l’utilisateur par le fait qu’elle a été concaténée avec le code de sauvegarde HPIDi qui est fonction de l’identité pivot PID, avant d’être chiffrée pour former la donnée de liaison chiffrée LNKSi. B13.2.b. Sauvegarde par chaque serveur BCKi de la part Si d’une manière telle qu’elle soit liée à l’identité de l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m KIDi= FDERIV(pBi, HPIDi) LNKSi= {Si} KIDi → STORE Cette étape est une variante de l’étape B13.2.a, qui peut donc être exécutée à la place de cette dernière par chaque serveur ou par certains serveurs seulement. Au cours de cette étape, chaque serveur BCKi configuré pour mettre en œuvre cette variante calcule une clé secrète KIDi par dérivation de sa clé privée pBi en utilisant comme diversifiant de dérivation le code de sauvegarde HPIDi qui est fonction de l’identité pivot de l’utilisateur. Une fois la clé KIDi calculée, chaque serveur BCKi chiffre la part Si qu’il a reçue au moyen de cette clé. La donnée de liaison chiffrée LNKSi résultant de cette étape de chiffrement est ensuite stockée dans la mémoire MEM de chaque serveur BCKi. Ainsi, dans cette variante, la part Si telle que sauvegardée dans la mémoire de chaque serveur BCKI, est liée à l’identité pivot de PID l’utilisateur par le fait qu’elle est chiffrée au moyen d’une clé KIDi qui est fonction de cette identité pivot. La fonction de dérivation FDERIV est par exemple la fonction HKDF qui est une fonction de dérivation de clé simple (KDF) basée sur le code d’authentification de message HMAC. La clé KIDi obtenue est donc fonction de l’identité pivot. Pour mettre en œuvre la fonction HKDF, on utilise la clé privée pBi en tant que paramètre « IKM » (« Input Key Material ») et le code de sauvegarde HPIDi en tant que champ « INFO ». Le champ « info » n’a pas de taille prédéfinie et peut donc contenir l’identité dans son ensemble, ou le « hash » de cette identité. B13.2.c. Sauvegarde par chaque serveur BCKi de la part Si d’une manière telle qu’elle soit liée à l’identité de l’utilisateur Dans une variante B13.2.c de l’étape B13.2.b, chaque serveur ou certains serveurs seulement, dérive(nt) la clé KIDi directement des données PID de l’identité pivot, sans passer par l’intermédiaire du code de sauvegarde, soit : KIDi= FDERIV(pBi, PID) B13.2.d. Sauvegarde par chaque serveur BCKi de la part Si d’une manière telle qu’elle soit liée à l’identité de l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m LNKSi = Hash(Si||HPIDi) → STORE EncSi = {Si}pBi → STORE Cette étape est encore une variante de l’étape B13.2.a, qui peut donc être exécutée à la place de cette dernière par chaque serveur ou par certains serveurs seulement. Au cours de cette étape, chaque serveur BCKi configuré pour mettre en œuvre cette variante concatène Si et HPIDi puis hache de la chaîne binaire résultante pour obtenir la donnée de liaison chiffrée LNKSi. Cette donnée ne peut pas être recalculée sans avoir accès à la part Si non chiffrée. Elle ne peut donc pas être recalculée par un fraudeur depuis l’extérieur du système. Une fois la donnée de liaison chiffrée LNKSi calculée, chaque serveur BCKi chiffre la part Si qu’il a reçue au moyen d’une clé privée connue de lui seul, par exemple pBi, pour obtenir une part chiffrée EncSi. La part chiffrée EncSi et les données de liaison chiffrées LNKSi correspondantes sont ensuite stockées dans la mémoire MEM de chaque serveur BCKi. B13.2.e. Sauvegarde par chaque serveur BCKi de la part Si d’une manière telle qu’elle soit liée à l’identité de l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m EncSi = {Si}pBi LNKSi= HMAC(pBi, EncSi||HPIDi) → STORE EncSi → STORE Cette étape est encore une variante de l’étape B13.2.a, qui peut donc être exécutée à la place de cette dernière par tout ou partie des serveurs de sauvegarde. Au cours de cette étape, chaque serveur BCKi configuré pour mettre en œuvre cette variante chiffre la part Si qu’il a reçue au moyen d’une clé privée connue de lui seul, par exemple sa clé privée pBi, pour obtenir une part chiffrée EncSi. Chaque serveur BCKi calcule ensuite une donnée de liaison chiffrée LNKSi par concaténation de la donnée chiffrée EncSi et du code de sauvegarde HPIDi puis signe la chaîne binaire obtenue au moyen d’une fonction de hachage cryptographique de type HMAC, par exemple l’algorithme HMAC-SHA256, en utilisant une clé privée connue de lui seul, par exemple sa clé privée pBi. La part chiffrée EncSi et les données de liaison chiffrées LNKSi correspondantes sont ensuite stockées dans la mémoire MEM de chaque serveur BCKi. B14. Confirmation de la sauvegarde à l’orchestrateur par chaque serveur BCKi [BCKi → ORC1] OKi Chaque serveur BCKi confirme à l’orchestrateur ORC1 par un message « OKi » (i allant de 1 à m) qu’il a déchiffré et stocké la part de la graine qui lui a été confiée. Optionnellement, chaque serveur BCKi peut envoyer une preuve chiffrée du déchiffrement de la part Si à l’aide d’un code de hachage signé avec sa clé de session. Ce code de hachage signé sera répercuté au dispositif HW pour être vérifié. B15. Confirmation de la sauvegarde à l’utilisateur [ORC1 → HW] OK L’orchestrateur ORC1 renvoie un message de réussite (« OK ») de la sauvegarde au dispositif HW, lequel affiche sur son écran à l’attention de l’utilisateur un message de confirmation de sauvegarde. A la fin du processus : - le dispositif HW détient toujours la graine S, - le logiciel compagnon HSW enregistre l’identifiant de la sauvegarde BCKID, - l’orchestrateur ORC1 ne détient pas la graine S ni les données de la sauvegarde BCKDT, et détient seulement l’identifiant de la sauvegarde BCKID, - chaque serveur BCKi détient dans sa mémoire MEM l’identifiant de la sauvegarde BCKID, les données de la sauvegarde BCKDT qui contiennent au moins les données PID de l’identité pivot de l’utilisateur, la donnée de liaison chiffrée LNKSi et la part Si de la graine qui lui a été confiée et a été liée à l’identité pivot de l’utilisateur légitime grâce à la donnée de liaison chiffrée LNKSi. Le logiciel compagnon HSW enregistre l’identifiant de la sauvegarde BCKID et peut aussi mettre à jour le compte client UACC de l’utilisateur en y enregistrant l’identifiant de la sauvegarde BCKID. Comme cela apparaîtra clairement dans ce qui suit, la prévision de la donnée de liaison chiffrée liant la part Si à l’identité de son détenteur initial légitime, rend le lien entre la part Si et l’identité pivot PID de l’utilisateur légitime inaltérable et inattaquable. Ce procédé permet de contrer une attaque ultérieure qui consisterait à dissocier chaque part Si des données BCKDT auxquelles elle est associée, qui contiennent les données d’identité PID de l’utilisateur légitime initial, pour l’associer à d’autres données BCKDT contenant des données d’identité PID d’un utilisateur illégitime. Une telle attaque par « échange de liens » entre des parts Si et des données BCKDT pourrait par exemple consister dans une attaque sur une base de données dans laquelle sont répertoriés de tels liens. Si chaque part Si de la graine est sauvegardée sous une forme chiffrée liée aux données PID de l’identité pivot de l’utilisateur légitime, les données de la sauvegarde BCKDT pourraient, dans certains modes de réalisation, ne pas comprendre les données PID. Bien qu’il soit plus pratique d’inclure les données PID dans les données BCKDT pour retrouver les parts Si dans les serveurs BCKi à partir d’informations relatives à l’identité de leurs propriétaires, les données BCKDT pourraient être réduites à d’autres types d'informations, par exemple le nom de la sauvegarde et/ou la date de la sauvegarde, sous réserve que l’utilisateur légitime puisse s’en souvenir au moment où il souhaite récupérer les parts Si. Dans d’autres modes de réalisation où au contraire les données de la sauvegarde BCKDT comprennent systématiquement les données PID de l’identité pivot, l’étape B8.3.2 de génération du code de sauvegarde HPIDi peut être réalisée à partir des données BCKDT au lieu d’être réalisée à partir des données PID. Dans ce cas, l’étape B8.3.2 s’écrit comme suit : Pour chaque serveur BCKi, i allant de 1 à m HPIDi = Hash(BCKDT) = Hash(PID||ODT) → STORE On décrira maintenant en relation avec les figures 5A, 5B, 5C un exemple d’algorithme de restauration de la graine applicable au système de la FIG. 3 et mettant en œuvre divers aspects des modes de réalisation du procédé précédemment décrits. La FIG. 5 est un diagramme de séquences qui représente les étapes de l’algorithme décrites par les figures 5A, 5B sous forme d’interactions entre les entités précédemment citées. On considère ici que l’utilisateur a perdu son dispositif HW, ou a perdu de manière irrécupérable le mot de passe qui permet de l’utiliser. Il se procure un nouveau dispositif HW’ qu’il va utiliser pour récupérer la graine S, et le connecte au dispositif hôte HDV dont le logiciel compagnon HSW a mémorisé l’identifiant de la sauvegarde BCKID. Le nouveau dispositif HW’ pourrait aussi être le dispositif HW qui a été réinitialisé. Au commencement du processus, le dispositif HW’ détient une clé privée pD, une clé publique PD, un certificat CD certifié par l’autorité de certification et la clé publique PL de l’autorité de certification (la même désignation que précédemment sera utilisée pour les clés et certificats du dispositif HW’). L’étape de restauration comprend les étapes décrites ci-après. Les étapes semblables à celles précédemment décrites ne seront pas de nouveau commentées. R1. Envoi par le dispositif d’une requête de restauration à l’orchestrateur HW’ → ORC1 RESTRQ[BCKID] La restauration est initiée par l’envoi par le dispositif HW’ à l’orchestrateur d’une requête en restauration RESTRQ. La requête contient l’identifiant de la sauvegarde BCKID. Elle est émise à la demande de l’utilisateur et sélectionnée à travers un menu affiché sur l’écran du dispositif HW’ ou sur l’écran du dispositif hôte HDV. R2. Authentification mutuelle et création d’un canal sécurisé entre l’orchestrateur et le dispositif R2.1. Génération par l’orchestrateur d’un certificat éphémère (peO, PeO) = AsymKeyGen() Sign(pO, ReO||PeO) CeO = PeO||Sign(pO, ReO||PeO ) R2.2 Envoi au dispositif des certificats de l’orchestrateur ORC1 → HW’ CeO||CO R2.3. Vérification par le dispositif des certificats de l’orchestrateur Verif CeO, Verif CO R2.4. Génération par le dispositif d’une clé de session et d’un certificat éphémère chiffré (peD, PeD) = AsymKeyGen() k0 = ECDH(peD, PeO) Sign(pD, ReD||PeD) {Sign(pD, ReD||PeD)}k0 CeD = PeD||{Sign(pD, ReD||PeD)}k0 {CD}k0 R2.5. Envoi à l’orchestrateur des certificats du dispositif HW’ [HW’ → ORC1] CeD||{CD}k0 R2.6. Génération par l’orchestrateur de la clé de session k0 k0 = ECDH(peO, PeD) CD={CD} -1 k0 Sign(pD, ReD||PeD) = {Sign(pD, ReD||PeD)} -1 k0 R2.7. Vérification par l’orchestrateur des certificats du dispositif Verif CeD, Verif CD R3. Envoi aux serveurs BCKi des données BCKID et certificats CeD, CD [ORC1 → BCKi] Pour chaque serveur BCKi, i allant de 1 à m BCKID||CeD||CD → BCKi L’orchestrateur ORC1 envoie à chaque serveur de sauvegarde BCKi l’identifiant de la sauvegarde BCKID, le certificat éphémère CeD et le certificat CD du dispositif HW’. R4. Vérification par chaque serveur BCKi des certificats du dispositif Pour chaque serveur BCKi, i allant de 1 à m Verif CeD, Verif CD R5. Authentification mutuelle et création d’un canal sécurisé entre les serveurs BCKi et le dispositif, par l’intermédiaire de l’orchestrateur R5.1. Génération par chaque serveur BCKi d’un certificat éphémère Pour chaque serveur BCKi, i allant de 1 à m (peBi, PeBi) = AsymKeyGen() Sign(pBi, ReB||PeBi) CeBi = PeBi||Sign(pBi, ReB||PeBi) R5.2. Génération par chaque serveur BCKi d’une clé de session Pour chaque serveur BCKi, i allant de 1 à m kBi = ECDH(peBi, PeD) R5.3. Génération par chaque serveur BCKi d’un code de hachage chiffré Hi = Hash(PeBi||BCKID||BCKDT) CHi = {Hi}kBi R5.4. Envoi à l’orchestrateur par chaque serveur BCKi de son certificat et du code de hachage chiffré [BCKi → ORC1] Pour chaque serveur BCKi, i allant de 1 à m RETDTi = CeBi||CBi||CHi R5.5. Envoi au dispositif des données reçues des serveurs BCKi [ORC1 → HW’] {BCKID||BCKDT||RETDT1|…||RETDTi||…||RETDTm}k0 R5.6. Déchiffrement par le dispositif de la chaine de données reçue de l’orchestrateur {BCKID||BCKDT||RETDT1|…||RETDTi||…||RETDTm} -1 k0 R5.7. Validation des données de la sauvegarde par l’utilisateur Validate BCKDT L’utilisateur valide les données de la sauvegarde BCKDT, notamment prénom, nom de famille, date de naissance, optionnellement lieu de naissance. R5.8. Vérification par le dispositif des certificats des serveurs BCKi Pour chaque serveur BCKi, i allant de 1 à m Verif CeBi, Verif CBi R5.9. Génération par le dispositif des clés de session kBi et vérification des codes de hachage chiffrés CHi Pour chaque serveur BCKi, i allant de 1 à m kBi = ECDH(peD, PeBi) {Hi} -1 kBi Validate Hi (Hi = Hash(PeBi||BCKID||BCKDT) R6. Préparation de la restauration R6.1. Envoi par le dispositif à l’orchestrateur de confirmations de restauration [HW’→ ORC1] {ConfirmRestore1}kB1||{ConfirmRestore2}kB2||…||{ConfirmRestore i }kBi||…|| {ConfirmRestore m }kBm → ORC1 Le dispositif HW’ renvoie à l’orchestrateur ORC1 pour chaque serveur BCKi, une confirmation de restauration individuelle « ConfirmRestore i » qui est chiffrée avec la clé kBi de chaque serveur BCKi. Chaque confirmation est un code binaire prédéfini. R6.2. Envoi aux serveurs BCKi des confirmations de restauration Pour chaque serveur BCKi, i allant de 1 à m BCKID||{ConfirmRestore i }kBi → BCKi L’orchestrateur ORC1 envoie à chaque serveur BCKi l’identifiant de la sauvegarde BCKID concaténé et la confirmation de restauration {ConfirmRestore i }kBi qui lui est destinée. R6.3. Vérification par les serveurs BCKi des confirmations de restauration Pour chaque serveur BCKi, i allant de 1 à m {ConfirmRestore i } -1 kBi Store CD Chaque serveur BCKi déchiffre le message de confirmation émis par le dispositif HW’ et qui lui a été communiqué par l’orchestrateur ORC1, et mémorise le certificat CD du dispositif HW’ qu’il a précédemment vérifié. R6.4. Confirmation par chaque serveur BCKi que la restauration peut être initiée sous réserve de vérification d’identité [BCKi→ ORC1] Pour chaque serveur BCKi, i allant de 1 à m OK_for_IDV Claque serveur BCKi indique à l’orchestrateur ORC1 qu’il est prêt à restituer la part Si qu’il a sauvegardée sous réserve que l’utilisateur s’identifie à travers une étape IDVi. R7.1. Réalisation des étapes de vérification d’identité IDVi par les serveurs IDVSRVi Pour chaque serveur BCKi, i allant de 1 à m IDVRi L’utilisateur est redirigé par l’orchestrateur ORC1 sur chaque serveur BCKi et chaque serveur BCKi procède à sa propre vérification IDVi de l’identité pivot de l’utilisateur. Dans le présent mode de réalisation où les étapes IDVi sont confiées à des prestataires, chaque serveur BCKi connecte l’utilisateur au serveur IDVSRVi auquel il est affilié à travers une passerelle GTW. Le service IDVSi du prestataire procède à une vérification de l’identité de l’utilisateur, puis confirme à l’orchestrateur ORC1 que son identité a été vérifiée et que l’étape de sauvegarde de la graine peut être initiée. Il sera noté que la durée de chaque étape de vérification d’identité IDVRi peut aller de quelques minutes à plusieurs jours selon les exigences de chaque serveur BCKi ou du prestataire qui réalise l’IDVRi. Des vérifications par des personnes physiques peuvent être systématiquement prévues avec certains prestataires d’IDV. R7.2. Génération par chaque serveur BCKi d’un code de restauration fonction de l’identité pivot PID’ de l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m IDVi → PID’ HPIDi’ = Hash(PID’) → STORE Chaque serveur BCKi reçoit un rapport de l’étape IDV ou du service IDVSi, contenant l’identité de l’utilisateur et le résultat de l’IDV, lui permettant de reconstituer les données de l’identité pivot PID’. Ce rapport est de préférence signé par le service d’IDV. Le serveur BCKi peut alors valider que l’IDV est un succès, et que l’identité contenue dans le rapport correspond bien à l’identité sauvegardée PID. Suite à cette vérification, chaque serveur BCKi valide les données PID’ de l’identité pivot de l’utilisateur. Ces données sont désignées ici PID’ et sont supposées identiques aux données PID utilisées pour la sauvegarde des parts de la graine, si l’utilisateur qui tente ici de restaurer la graine n’est pas un usurpateur. Chaque serveur BCKi génère ensuite un code de restauration HPIDi’ en fonction des données PID’ de la même manière que celle qui a permis de générer le code de sauvegarde HPIDi en fonction des données PID. Ainsi, par exemple, le code de restauration HPIDi’ est calculé par hachage des données PID’, comme cela a été fait au cours de l’étape B8.3.2 pour calculer le code HPIDi en fonction des données PID. Ainsi, si l’utilisateur qui demande la restauration de la graine n’est pas un usurpateur, le code de restauration HPIDi’ est égal au code de sauvegarde HPIDi. Une fois calculé, chaque serveur stocke le code de restauration HPIDi’ dans sa mémoire MEM. Il sera noté que si l’étape B8.3.2 de génération du code de sauvegarde HPIDi a été conduite à partir des données de la sauvegarde BCKDT contenant les données PID de l’identité pivot et d’autres données ODT, l’étape R7.2 de génération du code de restauration HPIDi’ est elle-même conduite à partir des données de la sauvegarde BCKDT. Dans ce cas l’étape R7.2 s’écrit comme suit : Pour chaque serveur BCKi, i allant de 1 à m HPIDi’ = Hash(BCKDT’) → STORE avec : BCKDT’ = PID’||ODT ODT étant les autres données contenues dans les données BCKDT, comme la date et l’heure de la sauvegarde, et/ou un nom donné par l’utilisateur à la sauvegarde. R8. Rétablissement des canaux de communication sécurisés après réalisation des étapes de vérification d’identité IDVi [HW’ → ORC1] Continue Restore Une fois l’étape de vérification d’identité terminée, soit parfois plusieurs jours plus tard, l’utilisateur relance l’étape de restauration. Le dispositif HW’ envoie à l’orchestrateur ORC1 une demande de reprise de la restauration « Continue Restore ». Répétition des étapes R2.1 à R2.7, R3, R5.1 à R5.9 ( FIG. 5 ) Comme plusieurs jours peuvent s’écouler pendant la réalisation des étapes de vérification IDVi, dans un mode de réalisation les certificats de session précédents ne sont pas conservés. Ainsi, les étapes R2.1 à R2.7, R3, R5.1 à R5.9 sont exécutées de nouveau pour reprendre le processus de restauration là où il s’était arrêté, mais avec de nouvelles clés de session k0 et kBi. R9. Reprise de la restauration [ORC1 → BCKi] Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n) Continue Restore → BCKi Une fois les canaux sécurisés réouverts au moyen de nouvelles clés de session, l’orchestrateur répercute aux serveurs BCKi la demande de poursuite de la restauration. Il sera noté que si au cours des étapes IDVRi l’un des serveurs BCKi n’a pas pu vérifier l’identité de l’utilisateur avec un degré de certitude déterminé, il refusera de restituer la part qu’il détient et en informera l’orchestrateur ORC1. Si un nombre déterminé de serveurs de sauvegarde BCKi n’a pas vérifié avec succès l’identité de l’utilisateur et refuse de restituer les données qu’ils détiennent, l’orchestrateur peut être configuré pour suspendre la restitution des parts par les serveurs qui ont vérifié avec succès l’identité de l’utilisateur. Il peut optionnellement décider de soumettre l’utilisateur à une procédure supplémentaire de vérification de son identité. L’orchestrateur peut également être configuré pour analyser des scores de certitude quant à la vérification de l’identité de l’utilisateur, comme indiqué plus haut, et prendre une décision en fonction de cette analyse. Par ailleurs, dans une variante du procédé mentionnée ci-dessus et dans ce qui suit entre parenthèses, cette étape est limitée n serveurs de sauvegarde BCKi, au lieu de l’ensemble des serveurs de sauvegarde, si n parts seulement sont nécessaires à la reconstitution de la graine, avec n inférieur à m. R10.1. Vérification du certificat du dispositif Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n) Verif CD = CD Chaque serveur BCKi s’assure que le certificat CD du dispositif HW’ est le même que le certificat CD reçu avant la conduite des étapes de vérification d’identité IDVi, qu’il a conservé. R10.2.a. Déchiffrement par chaque serveur BCKi de la donnée de liaison chiffrée LNKSi contenant la part Si et vérification de l’identité pivot de l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n) LNKSi = Si||HPIDi = {Si||HPIDi} pBi -1 COMPARE {HPIDi’, HPIDi} Au cours de cette étape, chaque serveur BCKi déchiffre la donnée LNKSi stockée dans sa mémoire pour en extraire la part Si et le code de sauvegarde HPIDi. Le déchiffrement est réalisé avec la même clé que celle utilisée pour l’étape de chiffrement B13.2.a, ici la clé privée pBi. Chaque serveur BCKi compare ensuite le code de restauration HPIDi’ et le code de sauvegarde HPIDi. Si l’utilisateur qui demande la restauration de la graine n’est pas un usurpateur, le code de restauration HPIDi’ est égal au code de sauvegarde HPIDi et chaque serveur BCKi accepte de restituer la part Si qu’il détient, sinon refuse de la restituer. R10.2.b. Déchiffrement par chaque serveur BCKi de la donnée de liaison chiffrée LNKSi contenant la part Si et vérification de l’identité pivot de l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n) KIDi’ = FDERIV(pBi, HPIDi’) Si = {LNKSi} KIDi’ -1 Cette étape est une variante de l’étape R10.2.a et est mise en œuvre si la variante B13.2.b de l’étape B13.2.a a été mise en œuvre au stade de la sauvegarde. Au cours de cette étape, chaque serveur BCKi concerné par cette variante calcule une clé secrète KIDi’ par dérivation de sa clé privée pBi en utilisant comme diversifiant le code de restauration HPIDi’ qui est fonction de l’identité pivot PID’ de l’utilisateur. Si l’utilisateur qui demande la restauration de la graine n’est pas un usurpateur, la clé KIDi’ dérivée de la clé privée pBi avec diversification au moyen du code de restauration HPIDi’, est identique à la clé KIDi dérivée de la clé privée pBi avec diversification au moyen du code de sauvegarde HPIDi, telle que calculée à l’étape B13.2’, car les codes HPIDi’ et HPIDi sont identiques. La même fonction de dérivation que celle utilisée à l’étape B13.2’ doit bien entendu être utilisée, par exemple la fonction HKDF. Chaque serveur BCKi déchiffre ensuite au moyen de la clé secrète KIDi’ la part chiffrée LNKSi stockée dans sa mémoire, pour en extraire la part Si. Si l’utilisateur qui demande la restauration de la graine est un usurpateur, la clé KIDi’ ne sera pas la même que la clé KIDi ayant permis de générer la part chiffrée LNKSi. Le déchiffrement de la part Si ne sera pas possible ou sera erroné et les serveurs BCKi ne pourront pas restituer leurs parts Si. R10.2.c. Déchiffrement par chaque serveur BCKi de la donnée de liaison chiffrée LNKSi contenant la part Si et vérification de l’identité pivot de l’utilisateur Dans le cas où la variante B13.2.c de l’étape B13.2.a a été mise en œuvre, le code de restauration HPIDi’ n’est pas calculé et l’étape R7.2 n’est pas réalisée. L’étape R10.2.a devient l’étape R10.2.c qui est exécutée ainsi : Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n) KIDi’ = FDERIV(pBi, PID’) Si = {LNKSi} KIDi’ -1 R10.2.d. Déchiffrement par chaque serveur BCKi de la part Si, calcul de la donnée de liaison chiffrée et vérification de l’identité pivot de l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n) Si = {EncSi} pBi -1 LNKSi’ = Hash(Si||HPIDi’) COMPARE {LNKSi, LNKSi’} Cette étape est une variante de l’étape R10.2.a et est mise en œuvre si la variante B13.2.d de l’étape B13.2.a a été mise en œuvre au stade de la sauvegarde. Au cours de cette étape, chaque serveur BCKi concerné par cette variante déchiffre au moyen de la clé secrète pBi la part chiffrée EncSi stockée dans sa mémoire, pour en extraire la part Si. Chaque serveur BCKi calcule une nouvelle donnée de liaison chiffrée LNKSi’ en concaténant la part Si déchiffrée avec le code de restauration HPIDi’ qui est fonction de l’identité pivot PID’ de l’utilisateur, et en appliquant la fonction de hachage précédemment utilisée à la chaîne binaire résultante. Chaque serveur BCKi compare ensuite la nouvelle donnée de liaison chiffrée LNKSi’ issue du code de restauration HPIDi’ et la donnée de liaison chiffrée LNKSi calculée au moment de la sauvegarde. Si l’utilisateur qui demande la restauration de la graine n’est pas un usurpateur, LNKSi’ est égal à LNKSi et chaque serveur BCKi accepte de restituer la part Si qu’il détient, sinon refuse de la restituer. R10.2.e. Déchiffrement par chaque serveur BCKi de la part Si, calcul de la donnée de liaison chiffrée et vérification de l’identité pivot de l’utilisateur Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n) LNKSi’ = HMAC(pBi, EncSi||HPIDi’) COMPARE {LNKSi, LNKSi’} Si = {EncSi} pBi -1 Cette étape est une variante de l’étape R10.2.a et est mise en œuvre si la variante B13.2.e de l’étape B13.2.a a été mise en œuvre au stade de la sauvegarde. Au cours de cette étape, chaque serveur BCKi concerné par cette variante calcule une nouvelle donnée de liaison chiffrée en concaténant la part chiffrée EncSi avec le code de restauration HPIDi’ qui est fonction de l’identité pivot PID’ de l’utilisateur, puis en appliquant un algorithme de signature symétrique à la chaîne binaire résultante tel que HMAC-SHA256, en utilisant par exemple sa clé secrète pBi. Chaque serveur BCKi compare ensuite la nouvelle donnée de liaison chiffrée LNKSi’ issue du code de restauration HPIDi’ et la donnée de liaison chiffrée LNKSi calculée au moment de la sauvegarde. Si l’utilisateur qui demande la restauration de la graine n’est pas un usurpateur, la donnée de liaison chiffrée LNKSi’ est égale à LNKSi et chaque serveur BCKi accepte de restituer la part Si qu’il détient, après l’avoir déchiffrée au moyen de la clé secrète pBi, sinon refuse de la restituer. R11. Transfert des parts à l'orchestrateur par les serveurs BCKi Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n) {S1}kB1||{S2}kB2||….||{Si}kBi||…||{Sm}kBm → ORC1 Chaque serveur BCKi envoie à l'orchestrateur ORC1 la part Si qu’il détient, chiffrée au moyen de sa clé kBi, que l'orchestrateur ne connaît pas. R12. Transfert des parts au dispositif par l'orchestrateur {S1}kB1||{S2}kB2||….||{Si}kBi||…||{Sm}kBm → HW’ L'orchestrateur ORC1 envoie au dispositif HW’ toutes les parts Si reçues des serveurs BCKi sous forme chiffrée au moyen des clés kBi. R13. Déchiffrement des parts par le dispositif et restauration de la graine Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n) {Si} -1 kBi S = SS -1 (S1, S2,…Si…Sm) (ou S = SS -1 (S1, S2,…Si…Sn)) Après avoir déchiffré chaque part de rang i au moyen de la clé kBi correspondante, le dispositif HW’ restaure la graine à partir des parts reçues, ou d’une partie de celles-ci si leur nombre est supérieur à n. Dans une variante R13’ de l’étape R13 correspondant à la variante B9’ de l’étape B9 décrite plus haut, la graine S que le dispositif HW’ a restauré est la graine originale chiffrée avec la clé de chiffrement de graine Kseed. Une étape supplémentaire de déchiffrement au moyen de la clé Kseed doit donc être prévue pour restaurer la graine, au moyen de la fonction de déchiffrement Fseed -1 correspondant à la fonction inverse de la fonction Fseed : S = Fseed -1 (S) Kseed Dans une variante R13’ de l’étape R13 correspondant à la variante B9’ de l’étape B9, chaque part Si que le dispositif HW’ a déchiffrée a été originellement chiffrée avec la clé de chiffrement de graine Kseed. Chaque part Si doit donc être déchiffrée au moyen de la clé Kseed après avoir été déchiffrée au moyen de la clé de session kBi, avant de reconstituer la graine, soit : Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n) {Fseed -1 (Si) Kseed } -1 kBi S = SS -1 (S1, S2,…Si…Sm) Dans le mode de réalisation décrit plus haut dans lequel la clé de chiffrement de graine est dérivée d’un secret connu de l’utilisateur, les étapes R13’ et R13’ incluent une étape de génération de la clé de chiffrement de graine à partir du secret de l’utilisateur. Cette génération peut éventuellement faire intervenir une clé de chiffrement stockée dans le portefeuille matériel. R14. Confirmation finale OK → ORC1 Le dispositif HW’ confirme à l'orchestrateur ORC1 que la restauration de la graine est terminée. Il apparaîtra clairement à l'homme de l'art que le procédé qui a été décrit est susceptible de nombreuses autres variantes et modes de réalisation. La structure des certificats mis en jeu dans le procédé a été décrite ci-dessus selon deux variantes, par exemple : Cx = [Px, Sign(pL, Px)] Cex = Pex||{Sign(px, Rex||Pex) Les certificats éphémères pourraient aussi être du type : Cex = Pex||{Sign(px, Pex) Le procédé peut aussi être mis en œuvre avec toute structure de certificat. Des certificats de type X509 peuvent notamment être utilisés. De même, d'autres fonctions de chiffrement ou algorithmes cryptographiques peuvent être utilisés, notamment dans le cadre d'une mise en œuvre basée sur la crytographie RSA. La FIG. 6 montre un système pour la mise en œuvre du procédé de l'invention qui se distingue de celui de la FIG. 3 en ce que le serveur ORCSRV1 est remplacé par un serveur ORCSRV2 qui exécute un programme orchestrateur ORC2 (ci-après "orchestrateur ORC2"). L'orchestrateur OCR2 diffère de l'orchestrateur ORC1 en ce qu'il n'assure pas la transmission au dispositif HW des données émises par les serveurs de sauvegarde BCKi, et réciproquement, et n'agit donc pas comme une passerelle ou "serveur proxy". Lorsque l'utilisateur initie une étape de sauvegarde de la graine, le dispositif HW adresse à l'orchestrateur OCR2 une requête en sauvegarde BCKRQ à la suite de quoi l'orchestrateur ORC2 engage les étapes précédemment décrites de génération d'un identifiant BCKID de la sauvegarde, et de collecte d'informations concernant l'utilisateur, pour générer les données de la sauvegarde BCKDT. L'orchestrateur conduit également l'étape initiale IDV0 de vérification de l'identité de l'utilisateur. Si cette étape est concluante, l'orchestrateur délivre au dispositif HW des autorisations de sauvegarde BCKPASSi, à raison d'une autorisation par serveur de sauvegarde BCKi, et envoie chaque autorisation au serveur BCKi concerné. Chaque autorisation BCKPASSi forme une sorte de "passeport" permettant au dispositif HW de savoir à quel serveur BCKi il doit s'adresser pour sauvegarder une part Si de la graine, et lui permettant de se connecter au serveur BCKi pour procéder à la sauvegarde sans être rejeté par ce dernier. Chaque autorisation BCKPASSi peut comprendre diverses informations et notamment les informations qui figuraient précédemment dans les données de la sauvegarde BCKDT et l'identifiant BCKID. Les autorisations BCKPASSi sont conservées par le logiciel compagnon ainsi que, de préférence, dans le compte de l'utilisateur UACC sur le serveur de compte UASRV. Dans une variante, l'orchestrateur délivre une autorisation générale BCKPASS contenant une concaténation de toutes les informations figurant dans les autorisations BCKPASSi. En référence à la FIG. 6 , lorsque l'utilisateur veut restaurer la graine, le logiciel compagnon se connecte aux serveurs de sauvegarde BCKi qu'il identifie au moyen des adresses contenues dans les autorisations BCKPASSi, puis passe la main au dispositif HW pour qu'il établisse des canaux sécurisés avec les serveurs de sauvegarde BCKi, par des échanges de clé tels que décrits plus haut. Lorsque les canaux sécurisés ont été créés, les serveurs de sauvegarde BCKi engagent les étapes IDVi de vérification de l'identité pivot de l'utilisateur. Le rôle de superviseur des étapes IDVi qui a été précédemment dévolu à l'orchestrateur ORC1 peut également être dévolu ici à l'orchestrateur ORC2. Ce dernier est alors sollicité par les serveurs de sauvegarde BCKi pour analyser les résultats des étapes IDVi. Si ces résultats sont concluants, l'orchestrateur ORC2 délivre au dispositif HW des autorisations de restauration RESTPASSi qu'il communique également aux serveurs de sauvegarde BCKi. Le dispositif HW rétablit ensuite un canal sécurisé avec les serveurs de sauvegarde BCKi et leur présente les autorisations RESTPASSi pour récupérer les parts Si de la graine. Dans le cas, ultime, où l’utilisateur aurait fermé son compte sur le serveur de compte UASRV, désinstallé le logiciel compagnon en effaçant les données qu'il comportait, et ne pourrait donc plus récupérer les autorisations BCKPASSi, ainsi que dans le cas, tout aussi ultime, où l'orchestrateur ORC2 n'existerait plus, une solution peut être prévue pour permettre à l'utilisateur de récupérer sa graine, en lui permettant de conduire une pluralité d'étapes individuelles de vérification de son identité auprès de chaque serveur de sauvegarde BCKi . Dans une variante du procédé permettant de faciliter la récupération des parts en cas de défaillance totale du système, ou de perte de l'identifiant BCKID (mode de réalisation figures 3A, 3B) ou des autorisations BCKPASSi, il peut être prévu que l'organisation en charge de l'orchestrateur ORC1 ou ORC2 délivre à l'utilisateur, par exemple par la voie postale, un certificat de sauvegarde revêtu d'un certificat d'authenticité inviolable tel un hologramme. Un tel certificat de sauvegarde n'épargnera pas l'utilisateur des étapes de vérification de son identité auprès des serveurs de sauvegarde, mais comportera suffisamment d'informations pour offrir un degré supplémentaire de certitude quant à sa qualité de détenteur légitime de la graine lorsque les étapes de vérification IDVi seront conduites. La FIG. 7 montre un exemple de réalisation d’un portefeuille matériel HW permettant la mise en œuvre du procédé. Le dispositif HW comprend un élément sécurisé SE1, un microcontrôleur MCU1 et un écran tactile TS1 ("Touch Screen"). L’écran tactile TS1 comprend un afficheur à encre électronique EID ("E-Ink Display") et un module tactile TM ("Touch Module"). L’écran tactile TS1 est sous le contrôle de l’élément sécurisé SE1. A cet effet, les ressources en termes d’entrées/sorties de l’élément sécurisé SE1 sont réparties en trois groupes d’entrées/sorties IOGA, IOGB, IOGC. Le groupe d’entrées/sorties IOGA est affecté à la mise en œuvre d’un bus BS1 reliant l’élément sécurisé SE1 au microcontrôleur MCU1. Le groupe d’entrées/sorties IOGB est affecté à la mise en œuvre d’un bus BS2 reliant l’élément sécurisé SE1 à l’afficheur EID, et le groupe d’entrées/sorties IOGC est affecté à la mise en œuvre d’un bus BS3 reliant l’élément sécurisé SE1 au module tactile TM. Le bus BS1 est par exemple un bus IEC/ISO 7816, le bus BS2 est par exemple un bus SPI et le bus BS3 un bus I2C. L’élément sécurisé est par exemple une puce STMicroelectronics® de la série ST33K. Le dispositif HW comporte par ailleurs divers périphériques contrôlés par le microcontrôleur MCU1, par exemple : - une batterie BAT ; - un circuit intégré PMIC de gestion d’alimentation reçoit une tension Vbat de la batterie lorsque celle-ci est chargée, fournit la tension Vbat à la batterie lorsque celle-ci doit être chargée, et fournit une tension d’alimentation régulée Vcc au microcontrôleur MCU1, à l’élément sécurisé SE1 et à l’écran tactile TS1 ; - une antenne QiA pour la charge de la batterie par induction. L’antenne QiA est reliée à un circuit intégré de charge sans fil WCIC (“Wireless Charging Integrated Circuit") . Le circuit WCIC fournit une tension Vqi au circuit PMIC pour la charge de la batterie ; - un port USB U1. Le port USB fournit au circuit PMIC une tension Vusb pour la charge de la batterie, fournit au microcontrôleur MCU1 des données DTu reçues d’un dispositif externe connecté au port USB, et transmet des données DTu au dispositif externe ; - une antenne Bluetooth BTA, recevant un signal radiofréquence RFS fourni par un circuit BTM de gestion des communications Bluetooth. Le circuit BTM fournit des données DTb échangées avec un dispositif externe via une liaison Bluetooth ou transmet des données DTb au dispositif externe via la liaison Bluetooth. Le dispositif HW présente l’avantage de posséder un écran tactile exclusivement contrôlé par l’élément sécurisé SE1 et donc non susceptible de corruption, y compris en cas d’attaque sur le microcontrôleur MCU1. Ce dernier n'exécute aucun programme d’application et ne stocke aucun des secrets cryptographiques utilisés par l’élément sécurisé. Il gère seulement les périphériques en transmettant à l’élément sécurisé les données DTb, DTu reçues par l’interface de communication choisie par l’utilisateur, ou en transmettant au dispositif externe des données DTb, DTu fournies par l’élément sécurisé. Le dispositif HW n’offre donc aucune possibilité de connexion directe à l’Internet et reste, malgré son écran tactile, un portefeuille matériel pour le stockage à froid de clés privées offrant le plus haut niveau de sécurité. L’élément sécurisé SE1 comporte également un espace mémoire MS1 comprenant une zone de mémoire morte, une zone mémoire non volatile programmable et effaçable électriquement et une zone mémoire volatile. La zone mémoire non volatile programmable et effaçable électriquement reçoit un système d’exploitation de l’élément sécurisé. Celui-ci est configuré pour permettre la mise en œuvre du procédé de l'invention. Le dispositif HW se prête bien à la mise en œuvre du procédé grâce à son écran tactile, qui peut être choisi de grande taille et présenter par exemple une diagonale supérieure ou égale à 3,5 pouces (un pouce étant égal à 2,54 cm), et comprendre au moins 600 x 400 pixels. Dans un mode de réalisation, l’écran présente une diagonale de 3,9 pouces (9,906 cm) et offre 670 x 496 pixels, ce qui constitue un très grand écran pour un portefeuille matériel de cryptoactifs dépourvu de connectivité Internet. Le procédé qui vient d'être décrit peut également être mis en œuvre avec divers autres types de portefeuilles de cryptoactifs. Le procédé peut notamment être mis en œuvre avec un portefeuille de cryptoactifs CW2 du type montré sur la FIG. 8 . Le portefeuille de cryptoactifs CW2 comprend un microcontrôleur sécurisé SMCU, un écran TS2 pouvant être tactile, des circuits d’interface de communication CINT1 comprenant notamment une connectivité wifi et/ou Ethernet et lui permettant de se relier à l'Internet. Le microcontrôleur sécurisé utilise deux processeurs virtuels associés à un contrôle d'accès matériel, permettant de gérer deux zones TZ, NTZ d’exécution d’applications offrant des degrés de sécurité différents, la zone TZ étant appelée "zone de confiance" ("Trust Zone"). Le microcontrôleur sécurisé peut, dans certains modes de réalisation, être équipé d’un élément sécurisé SE2 couplé à la zone de confiance TZ pour réaliser des calculs cryptographiques et conduire les opérations les plus sensibles en termes de sécurité, notamment stocker la graine ainsi que diverses clés de comptes de cryptoactifs. Chaque zone peut fonctionner indépendamment de l'autre tout en utilisant le même noyau. En général, le microcontrôleur exécute un système d'exploitation dit "riche" dans la zone la moins fiable NTZ, par exemple Android, et un code spécialisé dans la zone de confiance TZ. Un tel dispositif est l'équivalent de la combinaison du portefeuille matériel HW (équivalent à la zone de confiance) et du dispositif hôte HDV (équivalent à la zone moins sécurisée) décrits dans ce qui précède, et n’a pas besoin d’être relié à un dispositif hôte pour exécuter des opérations sur la blockchain. Le procédé de l’invention peut également être mis en œuvre avec un portefeuille de cryptoactifs de type logiciel ("software wallet"). Contrairement à un portefeuille en ligne, un portefeuille logiciel permet stocker des clés de cryptoactifs directement sur un ordinateur de bureau, un ordinateur portable, un téléphone mobile ou équivalent. L'utilisateur conserve la propriété de ses clés et de la graine, et doit sécuriser lui-même leur stockage en faisant en sorte qu'un fraudeur ne puisse pas s'en emparer. A titre d'exemple, la FIG. 9 montre un portefeuille de cryptoactifs CW3 de type logiciel exécuté par un dispositif électronique DV qui peut être du type précité, ordinateur, téléphone mobile ou équivalent. Le dispositif DV comprend un microprocesseur MPU équipé d'une interface de communication CINT2 lui permettant de se relier à l'Internet, d'une mémoire volatile RAM et d'une mémoire non volatile NVM, par exemple un disque dur magnétique ou un disque dur à l'état solide (SSD). Le programme CW3 formant le portefeuille de cryptoactifs logiciel est stocké dans la mémoire non volatile NVM du dispositif DV et est exécuté par le microprocesseur MPU à l'aide de sa mémoire RAM. Procédé pour la sauvegarde et la restauration d'un secret (S) détenu par un dispositif électronique sécurisé (CW1, CW2, CW3, HW, HDV), comprenant une étape de sauvegarde du secret comportant les étapes consistant à : - prévoir une pluralité de serveurs de sauvegarde (BCKi), - collecter (B3) des données (BCKDT, PID) définissant l’identité d’un premier utilisateur, et les communiquer (B6) à chaque serveur de sauvegarde, - au moyen du dispositif électronique sécurisé, générer une pluralité de parts secrètes (Si) à partir du secret (S), - transférer (B11, B12) à chaque serveur de sauvegarde l'une des parts secrètes (Si), et - dans chaque serveur de sauvegarde : - générer (B13.2.a, B13.2.b, B13.2.c, B13.2.d, B13.2.e) une donnée de liaison chiffrée (LNKSi) qui est fonction de la part secrète (Si) et des données (BCKDT, PID) définissant l’identité du premier utilisateur, et - stocker la donnée de liaison chiffrée dans une mémoire (MEM) du serveur de sauvegarde. Procédé selon la revendication 1, dans lequel dans au moins un serveur de sauvegarde l’étape (B13.2.a) de génération de la donnée de liaison chiffrée (LNKSi) comprend les étapes consistant à : - générer (B8.3.2) un code de sauvegarde (BCKDT, PID, HPIDi) fonction de l’identité du premier utilisateur, - combiner la part secrète (Si) et le code de sauvegarde, et - chiffrer la combinaison de la part secrète et du code de sauvegarde au moyen d’une clé secrète (pBi) du serveur de sauvegarde. Procédé selon l’une des revendications 1 et 2, dans lequel dans au moins un serveur de sauvegarde l’étape (B13.2.b, B13.2.c) de génération de la donnée de liaison chiffrée (LNKSi) comprend les étapes consistant à : - générer un code de sauvegarde (BCKDT, PID, HPIDi) fonction de l’identité du premier utilisateur, - appliquer une fonction (FDERIV) de dérivation de clé à une clé secrète (pBi) du serveur de sauvegarde, en utilisant le code de sauvegarde comme diversifiant de dérivation, pour obtenir une première clé dérivée (KIDi) fonction des données (BCKDT, PID) définissant l’identité du premier utilisateur, et - chiffrer la part secrète (Si) au moyen de la première clé dérivée (KIDi). Procédé selon l’une des revendications 1 à 3, dans lequel dans au moins un serveur de sauvegarde l’étape (B13.2.d) de génération de la donnée de liaison chiffrée (LNKSi) comprend les étapes consistant à : - générer un code de sauvegarde (BCKDT, PID, HPIDi) fonction de l’identité du premier utilisateur, - combiner la part secrète (Si) et le code de sauvegarde, et - hacher la combinaison de la part secrète et du code de sauvegarde pour obtenir la donnée de liaison chiffrée (LNKSi), le procédé comprenant en outre des étapes consistant à chiffrer la part secrète (Si) au moyen d’une clé secrète (pBi) du serveur de sauvegarde et stocker la part secrète chiffrée (EncSi) dans la mémoire (MEM) du serveur de sauvegarde. Procédé selon l’une des revendications 1 à 4, dans lequel dans au moins un serveur de sauvegarde l’étape (B13.2.e) de génération de la donnée de liaison chiffrée (LNKSi) comprend les étapes consistant à : - chiffrer la part secrète (Si) au moyen d’une clé secrète (pBi) du serveur de sauvegarde, - générer un code de sauvegarde (BCKDT, PID, HPIDi) fonction de l’identité du premier utilisateur, - combiner la part secrète chiffrée (EncSi) et le code de sauvegarde, et - chiffrer la combinaison de la part secrète chiffrée et du code de sauvegarde au moyen d’une clé secrète (pBi) du serveur de sauvegarde et d'une fonction de hachage cryptographique (HMAC), le procédé comprenant en outre une étape consistant à stocker la part secrète chiffrée (EncSi) dans la mémoire (MEM) du serveur de sauvegarde. Procédé selon l’une des revendications 2 à 5, dans lequel l'étape de génération du code de sauvegarde (BCKDT, PID, HPIDi) comprend une étape de concaténation de données définissant une identité pivot de l’utilisateur. Procédé selon l’une des revendications 2 à 5, dans lequel l’étape de génération du code de sauvegarde (HPIDi) comprend une étape de concaténation de données définissant une identité pivot de l’utilisateur, et une étape de hachage (B8.3.2) des données d’identité pivot concaténées. Procédé selon la revendication 1, comprenant une étape de restauration du secret (S) comprenant les étapes consistant à : - collecter (R7.1) des données (BCKDT’, PID’) définissant l’identité d’un deuxième utilisateur, vérifier leur validité avec la participation du deuxième utilisateur, et les fournir à au moins un serveur de sauvegarde, et - au moyen du serveur de sauvegarde, vérifier, au moyen de la donnée de liaison chiffrée (LNKSi), que l’identité du deuxième utilisateur est la même que l’identité du premier utilisateur. Procédé selon la revendication 8, dans lequel l'étape de vérification de l’identité du deuxième utilisateur comprend au moins l’une des opérations suivantes : - déchiffrer (R10.2.a) la donnée de liaison chiffrée, en extraire l’identité du premier utilisateur ou une donnée (HPIDi) fonction de son identité, et la comparer à l’identité du deuxième utilisateur ou à une donnée (HPIDi’) fonction de l’identité du deuxième utilisateur, - déchiffrer (R10.2.b, R10.2.c) la donnée de liaison chiffrée au moyen d’une clé (KIDi’) fonction de l’identité du deuxième utilisateur, - calculer (R10.2.d, R10.2.e) une nouvelle donnée de liaison chiffrée (LNKSi’) à partir de l’identité du deuxième utilisateur et la comparer à la donnée de liaison chiffrée initiale (LNKSi). Procédé selon la revendication 2, comprenant une étape de restauration du secret (S) comportant les étapes consistant à : - collecter (R7.1) des données (BCKDT’, PID’) définissant l’identité d’un deuxième utilisateur, vérifier leur validité avec la participation du deuxième utilisateur, et les fournir à au moins un serveur de sauvegarde, et - au moyen du serveur de sauvegarde : - générer (R7.2) un code de restauration (BCKDT’, PID’, HPIDi’) fonction de l’identité du deuxième utilisateur, - déchiffrer (R10.2.a) la donnée de liaison chiffrée (LNKSi) au moyen de la clé secrète (pBi) du serveur de sauvegarde et en extraire le code de sauvegarde (BCKDT, PID, HPIDi), - comparer le code de restauration (BCKDT’, PID’, HPIDi’) et le code de sauvegarde (BCKDT, PID, HPIDi), et - restituer la part secrète (Si) présente dans la donnée de liaison chiffrée (LNKSi) si les deux codes sont identiques, et refuser de la restituer si les deux codes ne sont pas identiques. Procédé selon la revendication 3, comprenant une étape de restauration du secret comportant les étapes consistant à : - collecter (R7.1) des données (BCKDT’, PID’) définissant l’identité d’un deuxième utilisateur, vérifier leur validité avec la participation du deuxième utilisateur, et les fournir à au moins un serveur de sauvegarde, et - au moyen du serveur de sauvegarde : - générer (R7.2) un code de restauration (BCKDT’, PID’, HPIDi’) fonction de l’identité du deuxième utilisateur, - appliquer (R10.2.b, R10.2.c) la fonction (FDERIV) de dérivation de clé à la clé secrète (pBi) du serveur de sauvegarde en utilisant comme diversifiant de dérivation le code de restauration (BCKDT’, PID’, HPIDi’), pour obtenir une deuxième clé dérivée (KIDi’) fonction des données (BCKDT’, PID ») définissant l’identité du deuxième utilisateur, et - si la première et la deuxième clé dérivées sont identiques, déchiffrer la donnée de liaison chiffrée (LNKSi) au moyen de la deuxième clé dérivée (KIDi’) et en extraire la part secrète (Si). Procédé selon la revendication 4, comprenant une étape de restauration du secret comportant les étapes consistant à : - collecter (R7.1) des données (BCKDT’, PID’) définissant l’identité d’un deuxième utilisateur, vérifier leur validité avec la participation du deuxième utilisateur, et les fournir à au moins un serveur de sauvegarde, et - au moyen du serveur de sauvegarde, - générer (R7.2) un code de restauration (BCKDT’, PID’, HPIDi’) fonction de l’identité du deuxième utilisateur, - déchiffrer la part secrète (Si) au moyen de la clé secrète du serveur de sauvegarde, - combiner (R10.2.d) la part secrète et le code de restauration, et hacher la combinaison de la part secrète et du code de restauration pour obtenir une nouvelle donnée de liaison chiffrée (LNKSi’), - comparer la nouvelle donnée de liaison chiffrée (LNKSi’) et la donnée de liaison chiffrée (LNKSi), et - restituer la part secrète (Si) si la nouvelle donnée de liaison chiffrée (LNKSi’) et la donnée de liaison chiffrée (LNKSi) sont identiques, sinon refuser de restituer la part secrète (Si). Procédé selon la revendication 5, comprenant une étape de restauration du secret comportant les étapes consistant à : - collecter (R7.1) des données (BCKDT’, PID’) définissant l’identité d’un deuxième utilisateur, vérifier leur validité avec la participation du deuxième utilisateur, et les fournir à au moins un serveur de sauvegarde, et - au moyen du serveur de sauvegarde, - générer (R7.2) un code de restauration (BCKDT’, PID’, HPIDi’) fonction de l’identité du deuxième utilisateur, - combiner (R10.2.e) la part secrète et le code de restauration, et chiffrer la combinaison de la part secrète et du code de restauration au moyen de la clé secrète (pBi) du serveur de sauvegarde et de la fonction de hachage cryptographique (HMAC), pour obtenir une nouvelle donnée de liaison chiffrée (LNKSi’), - comparer la nouvelle donnée de liaison chiffrée (LNKSi’) et la donnée de liaison chiffrée (LNKSi), - déchiffrer et restituer la part secrète (Si) si la nouvelle donnée de liaison chiffrée (LNKSi’) et la donnée de liaison chiffrée (LNKSi) sont identiques, sinon refuser de restituer la part secrète (Si). Procédé selon l’une des revendications 10 à 13, dans lequel l'étape de génération du code de restauration (BCKDT’, PID’, HPIDi’) comprend une étape de concaténation de données définissant une identité pivot de l’utilisateur. Procédé selon l’une des revendications 10 à 13, dans lequel l’étape de génération du code de restauration (HPIDi’) comprend une étape de concaténation de données définissant une identité pivot de l’utilisateur, et une étape de hachage (B8.3.2) des données d’identité pivot concaténées. Procédé selon l’une des revendications 1 à 15, dans lequel l’identité d’un utilisateur est définie par au moins un prénom, un nom de famille et une date de naissance de l’utilisateur. Procédé selon l'une des revendications 1 à 16, dans lequel le dispositif électronique sécurisé est configuré pour générer une pluralité de parts secrètes (Si) au moyen d’une fonction de partage de secret (SS) prévue pour générer un nombre m de parts secrètes à partir du secret (S) et permettre la reconstitution du secret (S) à partir d’un seuil de n parts secrètes (Si). Procédé selon la revendication 17, dans lequel le dispositif électronique sécurisé (CW1) comprend un portefeuille matériel (HW) de comptes de cryptoactifs dépourvu de moyen de connexion à l’Internet relié ou configuré pour être relié à un dispositif hôte (HDV) exécutant un logiciel compagnon (HSW) et pourvu d’une connexion à l’Internet. Serveur pour la sauvegarde et la restitution d'une donnée secrète (Si), configuré pour, en réponse à une demande de sauvegarde de la donnée secrète : - recevoir la donnée secrète (Si), - recevoir des données (BCKDT, PID) définissant l’identité d’un premier utilisateur, - générer (B13.2.a, B13.2.b, B13.2.c, B13.2.d, B13.2.e) une donnée de liaison chiffrée (LNKSi) qui est fonction de la donnée secrète (Si) et des données (BCKDT, PID) définissant l’identité du premier utilisateur, et - stocker la donnée de liaison chiffrée dans une mémoire (MEM) du serveur. Serveur selon la revendication 19, configuré pour générer la donnée de liaison chiffrée (LNKSi) en exécutant les étapes consistant à : - générer (B8.3.2) un code de sauvegarde (BCKDT, PID, HPIDi) fonction de l’identité du premier utilisateur, - combiner la donnée secrète (Si) et le code de sauvegarde, et - chiffrer la combinaison de la donnée secrète et du code de sauvegarde au moyen d’une clé secrète (pBi) du serveur. Serveur selon la revendication 19, configuré pour générer la donnée de liaison chiffrée (LNKSi) en exécutant les étapes consistant à : - générer un code de sauvegarde (BCKDT, PID, HPIDi) fonction de l’identité du premier utilisateur, - appliquer une fonction (FDERIV) de dérivation de clé à une clé secrète (pBi) du serveur en utilisant le code de sauvegarde comme diversifiant de dérivation, pour obtenir une première clé dérivée (KIDi) fonction des données (BCKDT, PID) définissant l’identité du premier utilisateur, et - chiffrer la donnée secrète (Si) au moyen de la première clé dérivée (KIDi). Serveur selon la revendication 19, configuré pour générer la donnée de liaison chiffrée (LNKSi) en exécutant les étapes consistant à : - générer un code de sauvegarde (BCKDT, PID, HPIDi) fonction de l’identité du premier utilisateur, - combiner la donnée secrète (Si) et le code de sauvegarde, et - hacher la combinaison de la donnée secrète et du code de sauvegarde, le serveur étant également configuré pour chiffrer la donnée secrète (Si) au moyen d’une clé secrète (pBi) du serveur et stocker la donnée secrète chiffrée (EncSi) dans la mémoire (MEM) du serveur. Serveur selon la revendication 19, configuré pour générer la donnée de liaison chiffrée (LNKSi) en exécutant les étapes consistant à : - chiffrer la donnée secrète (Si) au moyen d’une clé secrète (pBi) du serveur, - générer un code de sauvegarde (BCKDT, PID, HPIDi) fonction de l’identité du premier utilisateur, - combiner la donnée secrète chiffrée (EncSi) et le code de sauvegarde, et - chiffrer la combinaison de la donnée secrète chiffrée et du code de sauvegarde au moyen d’une clé secrète (pBi) du serveur et d'une fonction de hachage cryptographique (HMAC), le serveur étant en outre configuré pour stocker la donnée secrète chiffrée (EncSi) dans la mémoire (MEM) du serveur. Serveur selon l’une des revendications 20 à 23, configuré pour inclure dans l'étape de génération du code de sauvegarde (BCKDT, PID, HPIDi) une étape de concaténation de données définissant une identité pivot de l’utilisateur. Serveur selon l’une des revendications 20 à 23, configuré pour inclure dans l’étape de génération du code de sauvegarde (HPIDi) une étape de concaténation de données définissant une identité pivot de l’utilisateur, et une étape de hachage (B8.3.2) des données d’identité pivot concaténées. Serveur selon la revendication 20, configuré pour, en réponse à une demande de restitution de la donnée secrète (Si) : - collecter (R7.1) des données (BCKDT’, PID’) définissant l’identité d’un deuxième utilisateur, - générer (R7.2) un code de restauration (BCKDT’, PID’, HPIDi’) fonction de l’identité du deuxième utilisateur, - déchiffrer (R10.2.a) la donnée de liaison chiffrée (LNKSi) et en extraire le code de sauvegarde (BCKDT, PID, HPIDi), - comparer le code de restauration (BCKDT’, PID’, HPIDi’) et le code de sauvegarde (BCKDT, PID, HPIDi), et - restituer la donnée secrète (Si) présente dans la donnée de liaison chiffrée (LNKSi) si les deux codes sont identiques, et refuser de la restituer si les deux codes ne sont pas identiques. Serveur selon la revendication 21, configuré pour, en réponse à une demande de restitution de la donnée secrète (Si) : - collecter (R7.1) des données (BCKDT’, PID’) définissant l’identité d’un deuxième utilisateur, - générer (R7.2) un code de restauration (BCKDT’, PID’, HPIDi’) fonction de l’identité du deuxième utilisateur, - appliquer (R10.2.b, R10.2.c) la fonction (FDERIV) de dérivation de clé à la clé secrète (pBi) du serveur en utilisant comme diversifiant de dérivation le code de restauration (BCKDT’, PID’, HPIDi’), pour obtenir une deuxième clé dérivée (KIDi’) fonction des données (BCKDT’, PID ») définissant l’identité du deuxième utilisateur, et - si la première et la deuxième clé dérivées sont identiques, déchiffrer la donnée de liaison chiffrée (LNKSi) au moyen de la deuxième clé dérivée (KIDi’) et en extraire la donnée secrète (Si). Serveur selon la revendication 22, configuré pour, en réponse à une demande de restitution de la donnée secrète (Si) : - collecter (R7.1) des données (BCKDT’, PID’) définissant l’identité d’un deuxième utilisateur, - générer (R7.2) un code de restauration (BCKDT’, PID’, HPIDi’) fonction de l’identité du deuxième utilisateur, - déchiffrer la donnée secrète (Si) au moyen de la clé secrète du serveur, - combiner (R10.2.d) la donnée secrète et le code de restauration, hacher la combinaison de la donnée secrète et du code de restauration pour obtenir une nouvelle donnée de liaison chiffrée (LNKSi’), - comparer la nouvelle donnée de liaison chiffrée (LNKSi’) et la donnée de liaison chiffrée (LNKSi), et - restituer la donnée secrète (Si) si la nouvelle donnée de liaison chiffrée (LNKSi’) et la donnée de liaison chiffrée (LNKSi) sont identiques, sinon refuser de restituer la donnée secrète (Si). Serveur selon la revendication 23, configuré pour, en réponse à une demande de restitution de la donnée secrète (Si) : - collecter (R7.1) des données (BCKDT’, PID’) définissant l’identité d’un deuxième utilisateur, - générer (R7.2) un code de restauration (BCKDT’, PID’, HPIDi’) fonction de l’identité du deuxième utilisateur, - combiner (R10.2.e) la donnée secrète et le code de restauration, et chiffrer la combinaison de la donnée secrète et du code de restauration au moyen de la clé secrète (pBi) du serveur et de la fonction de hachage cryptographique (HMAC), pour obtenir une nouvelle donnée de liaison chiffrée (LNKSi’), - comparer la nouvelle donnée de liaison chiffrée (LNKSi’) et la donnée de liaison chiffrée (LNKSi), - déchiffrer et restituer la donnée secrète (Si) si la nouvelle donnée de liaison chiffrée (LNKSi’) et la donnée de liaison chiffrée (LNKSi) sont identiques, sinon refuser de restituer la donnée secrète (Si). Serveur selon l’une des revendications 26 à 29, configuré pour générer le code de restauration (BCKDT’, PID’, HPIDi’) par concaténation de données définissant une identité pivot de l’utilisateur. Serveur selon l’une des revendications 26 à 29, configuré pour générer le code de restauration (HPIDi’) comprenant une étape de concaténation de données définissant une identité pivot de l’utilisateur, et une étape de hachage (B8.3.2) des données d’identité pivot concaténées.