Brevet FR3155925A1 — publié le 20250530

Procédé pour transférer une donnée secrète (RPH) d’un premier dispositif (WA) à un deuxième dispositif (WB), comprenant les étapes consistant à fournir (S10, S20) à chaque dispositif une clé privée (SkA, SkB), une clé publique (PkA, PkB), une clé publique (PkI) d’une autorité de certification (ICA), un certificat (CIA, CIB) signé par l’autorité de certification ; fournir à chaque dispositif un code de processus aléatoire (PCD) commun au deux dispositifs ; générer un nombre entier fonction du code de processus (PCD) ; définir une première clé de chiffrement symétrique fonction du nombre entier ; chiffrer le certificat (CIB) du deuxième dispositif avec la première clé de chiffrement ; transmettre au premier dispositif le certificat (CIB) du deuxième dispositif sous sa forme chiffrée ; générer une clé publique éphémère ; transmettre au premier dispositif la clé publique éphémère ; recevoir une clé publique éphémère du premier dispositif ; générer une deuxième clé de chiffrement symétrique à partir de la clé publique éphémère du premier dispositif ; recevoir la donnée secrète (RPH) sous une forme chiffrée avec la deuxième clé de chiffrement symétrique ; et déchiffrer la donnée secrète (RPH) avec la deuxième clé de chiffrement symétrique. Figure abrégé : Figure 2 Procédé pour transférer une donnée secrète entre deux dispositifs. La présente invention concerne un procédé pour transférer une donnée secrète d’un premier dispositif à un deuxième dispositif, dans lequel chaque dispositif comprend un processeur sécurisé comprenant des moyens de calcul cryptographique, une mémoire sécurisée et des moyens de communication. Arrière-plan Ces dernières années, le développement des cryptomonnaies ou autres types de cryptoactifs gérés par des blockchains, 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. Un portefeuille matériel est généralement un dispositif électronique portatif, équipé d’un processeur sécurisé 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 transférée vers le portefeuille matériel pour y être signée numériquement hors ligne, la signature étant ensuite associée à la transaction lorsque celle-ci est placée sur une blockchain. 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. Les portefeuilles matériels sont donc aujourd’hui considérés comme la solution la plus sûre contre les attaques de pirates informatiques. Leur seul inconvénient réside dans le risque de perte, de vol ou de destruction (incendie par exemple), ou de perte du mot de passe personnel de l'utilisateur permettant de s’en servir. Les clés des comptes de cryptoactifs 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. 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 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 »). La clé maître étant un nombre binaire de grande longueur impossible à mémoriser pour un être humain et surtout difficile à reproduire manuellement, la norme BIP39 propose également qu’une telle clé maître soit générée à partir d’une phrase secrète également appelée « phrase mnémonique », ou « phrase de récupération » (« recovery phrase ») ou encore « seed phrase » (phrase permettant de générer la graine »). Selon BIP39, la phrase de récupération peut être de 12 ou de 24 mots. Le type 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 initiale de la 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. Cette séquence initiale est parfois appelée « entropie ». 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 de récupération de 24 mots. Grâce à ce processus, l’appareil génère une phrase de récupération sur 2 256 phrases possibles (soit 115 792 089 237 316 195 423 570 985 008 687 907 853 269 984 665 640 564 039 457 584 007 913 129 639 936 phrases mnémoniques possibles). Au sein du portefeuille matériel, la clé maître est dérivée de la phrase de récupération selon un processus normalisé et reproductible, consistant par exemple à appliquer à la phrase de récupération une fonction de dérivation de clé PBKDF2 (« Password-Based Key Derivation Function 2 ») utilisant une fonction d’authentification HMAC (« Keyed-Hash Message Authentication Code ») basée sur la fonction de hachage SHA512, avec un sel comprenant le terme « mnemonic » et une phrase de passe optionnelle, et à réaliser 2048 itérations. Les portefeuilles déterministes hiérarchiques ne nécessitent donc qu’une sauvegarde de la phrase de récupération, de préférence au moment de leur mise en service, à partir de laquelle il est possible de dériver l’ensemble de l’arbre descendant de clés. La sauvegarde de la phrase de récupération pose cependant divers problèmes en termes de sécurité, car sa seule connaissance permet d’accéder à l’ensemble des comptes de cryptoactifs qui en sont dérivés, et de s’emparer des sommes ou des valeurs qu’ils renferment. Les solutions pour sauvegarder la phrase de récupération qui sont les plus généralement utilisées sont les suivantes : - noter la phrase de récupération sur une feuille de papier, ou sur plusieurs feuilles de papier recevant chacune certains des mots qui constituent la phrase de récupération, puis stocker la ou les feuilles de papier en lieu sûr, par exemple un coffre de banque ou plusieurs coffres de banque, - graver la phrase de récupération sur une ou plusieurs plaques d’acier, qui sont durables et plus sûres que des feuilles de papier, et stocker la ou les plaques d’acier en lieu sûr, coffre de banque ou autre moyen, - utiliser la solution « Capsule Cryptosteel » proposée par la demanderesse, consistant en des micro-tuiles pré-gravées en acier, accompagnées d’un outil de sauvegarde cylindrique conçu pour stocker en toute sécurité des données d’une longueur maximale de 123 caractères. Le boîtier extérieur et les tuiles sont fabriqués en acier massif inoxydable pour offrir une durabilité maximale à la phrase de récupération. La capsule est résistante au feu, à l’eau et aux chocs. Récemment, la demanderesse a proposé au public une nouvelle solution de sauvegarde de la phrase de récupération appelée « Ledger Recover », plus facile à mettre en œuvre que les solutions connues susmentionnées, et hautement sécurisée. Selon cette solution, l’entropie de la phrase de récupération, c’est-à-dire la chaîne binaire aléatoire initiale dont la phrase de récupération est dérivée, est divisée en une pluralité de fragments appelés parts (« shares »). Chaque fragment est ensuite envoyé en toute sécurité, par l’intermédiaire de canaux authentifiés et chiffrés de bout en bout, vers les modules de sécurité matériels (HSM) d’entreprises indépendantes. Chaque fragment ne peut pas être utilisé individuellement et est lié à l’identité de l’utilisateur, qui se trouve donc le seul à pouvoir le récupérer. Un autre problème en relation avec la phrase de récupération se pose lorsqu’un utilisateur décide de changer de portefeuille matériel, par exemple pour passer d’un modèle plus ancien à un modèle plus récent. La demanderesse commercialise diverses générations de portefeuilles matériels offrant chacune des fonctionnalités et une ergonomie améliorées par rapport aux modèles précédents, comme le Ledger Nano S, le Ledger Nano X, et le Ledger Stax. Le Ledger Nano S offre uniquement une connexion USB à un dispositif hôte exécutant le logiciel compagnon Ledger Live (ordinateur, tablette ou téléphone mobile), et un écran LCD de 128 x 32 pixels. Le Ledger Nano X offre une connexion USB ou Bluetooth au dispositif hôte, et un écran LCD de 128 x 64 pixels. Le Ledger Stax offre une connectivité USB, Bluetooth et NFC, et comporte un grand écran tactile de 3,7 pouces. Il est donc fréquent qu’un utilisateur décide de passer d’un modèle à un autre, ce qui nécessite l’opération laborieuse consistant à recopier la phrase de récupération pour la fournir manuellement au nouveau portefeuille matériel acquis. Il a été envisagé de prévoir un transfert informatique de la phrase de récupération d’un portefeuille matériel à un autre à travers des serveurs sécurisés équipés de modules de sécurité matériels (HSM) qui authentifieraient les deux portefeuilles matériels. Le transport d’un seul bloc de la phrase de récupération dans un réseau informatique apparaît toutefois hasardeux en termes de sécurité, et ne serait pas accepté par le public. Un procédé tel que « Ledger Recover » pourrait aussi être utilisé. A cet effet, la phrase de récupération serait tout d’abord sauvegardée en plusieurs parts (« shares ») dans des serveurs de sauvegarde, puis restaurée dans le nouveau portefeuille matériel. Toutefois ce procédé comporte des étapes de vérification de l’identité de l’utilisateur qui sont très strictes et dont la mise en œuvre peut durer plusieurs journées. Il est plus adapté à la restauration de la phrase de récupération après que celle-ci a été perdue, qu’à son transfert au moment de la mise en service d’un nouveau portefeuille matériel. Il pourrait donc être souhaité de prévoir un procédé de transfert de la phrase de récupération entre deux portefeuilles matériels, qui soit plus simple à mettre en œuvre tout en étant hautement sécurisé. De façon plus générale, il pourrait être souhaité de prévoir un procédé de transfert d’une donnée secrète entre deux dispositifs électroniques comprenant chacun un processeur sécurisé comprenant des moyens de calcul cryptographiques, une mémoire sécurisée et des moyens de communication. Résumé Des modes de réalisation concernent un procédé pour transférer une donnée secrète d’un premier dispositif à un deuxième dispositif, dans lequel chaque dispositif comprend un processeur sécurisé comportant des moyens de calcul cryptographique, une mémoire sécurisée, et des moyens de communication, le procédé comprenant les étapes consistant à fournir à chaque dispositif une clé privée, une clé publique, une clé publique d’une autorité de certification, un certificat signé par l’autorité de certification, le certificat comprenant la clé publique du dispositif et la signature, de sa clé publique par l’autorité de certification, fournir aux dispositifs un code de processus aléatoire commun aux deux dispositifs, et au moyen du premier dispositif : générer un nombre entier qui est fonction du code de processus, définir une première clé de chiffrement symétrique comme étant égale au nombre entier ou la générer à partir du nombre entier, recevoir le certificat du deuxième dispositif sous une forme chiffrée au moyen de la première clé de chiffrement symétrique, déchiffrer le certificat du deuxième dispositif avec la première clé de chiffrement symétrique, au moyen de la clé publique de l’autorité de certification, vérifier l’authenticité du certificat du deuxième dispositif, pour s’assurer que le deuxième dispositif est habilité par l’autorité de certification à recevoir la donnée secrète, recevoir une clé publique éphémère du deuxième dispositif, générer une clé publique éphémère, transmettre la clé publique éphémère, générer une deuxième clé de chiffrement symétrique à partir de la clé publique éphémère du deuxième dispositif, chiffrer la donnée secrète avec la deuxième clé de chiffrement symétrique, et transmettre la donnée secrète sous sa forme chiffrée avec la deuxième clé de chiffrement symétrique. Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du premier dispositif : recevoir une signature de la clé publique éphémère du deuxième dispositif, générée au moyen de la clé privée du deuxième dispositif, et vérifier l’authenticité de la clé publique éphémère du deuxième dispositif au moyen de la clé publique du deuxième dispositif présente dans le certificat du deuxième dispositif, pour s’assurer que le deuxième dispositif qui a émis la clé publique éphémère est le même que le deuxième dispositif qui a émis le certificat. Selon un mode de réalisation, le premier dispositif génère la deuxième clé de chiffrement symétrique à partir de la clé publique éphémère du deuxième dispositif et de la clé publique éphémère du premier dispositif. Selon un mode de réalisation, le premier dispositif génère la deuxième clé de chiffrement symétrique à partir de la clé publique éphémère du deuxième dispositif et d’une clé privée éphémère du premier dispositif. Selon un mode de réalisation, le premier dispositif génère sa clé publique éphémère à partir du nombre entier. Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du deuxième dispositif : générer le nombre entier qui est fonction du code de processus, de la même manière que le premier dispositif, définir la première clé de chiffrement symétrique comme étant égale au nombre entier ou la générer à partir du nombre entier, de la même manière que le premier dispositif, chiffrer le certificat du deuxième dispositif avec la première clé de chiffrement symétrique, transmettre le certificat du deuxième dispositif sous sa forme chiffrée, générer la clé publique éphémère du deuxième dispositif, transmettre la clé publique éphémère du deuxième dispositif, recevoir la clé publique éphémère du premier dispositif, générer ladite deuxième clé de chiffrement symétrique à partir de la clé publique éphémère du premier dispositif, recevoir la donnée secrète sous ladite forme chiffrée avec la deuxième clé de chiffrement symétrique, et déchiffrer la donnée secrète avec la deuxième clé de chiffrement symétrique et stocker la donnée secrète dans la mémoire sécurisé. Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du deuxième dispositif : signer la clé publique éphémère du deuxième dispositif au moyen de la clé privée du deuxième dispositif, et transmettre la signature de la clé publique éphémère du deuxième dispositif. Selon un mode de réalisation, le deuxième dispositif génère la deuxième clé de chiffrement symétrique à partir de la clé publique éphémère du premier dispositif et de la clé publique éphémère du deuxième dispositif. Selon un mode de réalisation, le deuxième dispositif génère la deuxième clé de chiffrement symétrique à partir de la clé publique éphémère du premier dispositif et d’une clé privée éphémère du deuxième dispositif. Selon un mode de réalisation, le deuxième dispositif génère sa clé publique éphémère à partir du nombre entier. Selon un mode de réalisation, l’étape consistant à fournir aux dispositifs un code de processus est mise en œuvre selon l’une des deux méthodes suivantes : le premier dispositif génère une donnée aléatoire formant le code de processus qui est ensuite fourni au deuxième dispositif, ou le deuxième dispositif génère une donnée aléatoire formant le code de processus qui est ensuite fourni au premier dispositif par l’intermédiaire d’un clavier. Selon un mode de réalisation, le premier dispositif et le deuxième dispositif ne communiquent pas directement et sont reliés à un dispositif hôte, le procédé comprenant les étapes consistant à, au moyen du dispositif hôte : envoyer séquentiellement des commandes à l’un ou l’autre des dispositifs, recevoir des données de chaque dispositif en réponse à des commandes, et transférer à chaque dispositif des données reçues de l’autre dispositif en réponse à des commandes. Selon un mode de réalisation, le procédé comprend les étapes consistant à : déconnecter le deuxième dispositif du dispositif hôte et connecter le premier dispositif au dispositif hôte, pour permettre au dispositif hôte d’échanger des données avec le premier dispositif, et déconnecter le premier dispositif du dispositif hôte et connecter le deuxième dispositif au dispositif hôte, pour permettre au dispositif hôte d’échanger des données avec le deuxième dispositif. Selon un mode de réalisation, le premier dispositif et le deuxième dispositif sont des portefeuilles matériels de cryptoactifs. Selon un mode de réalisation, la donnée secrète est une phrase de récupération de comptes de cryptoactifs. Des modes de réalisation concernent également un dispositif électronique portatif comprenant un processeur sécurisé comportant des moyens de calcul cryptographique, une mémoire sécurisée, des moyens de communication, la mémoire sécurisée comprenant une clé privée, une clé publique, une clé publique d’une autorité de certification, un certificat signé par l’autorité de certification, le certificat comprenant la clé publique du dispositif et la signature de la clé publique du dispositif par l’autorité de certification, le dispositif comprenant un programme lui permettant de transmettre à un dispositif externe une donnée secrète que le dispositif détient dans la mémoire sécurisée, et étant configuré pour : recevoir ou générer un code de processus aléatoire et le mémoriser, générer un nombre entier qui est fonction du code de processus, définir une première clé de chiffrement symétrique comme étant égale au nombre entier ou la générer à partir du nombre entier, recevoir un certificat externe sous une forme chiffrée au moyen de la première clé de chiffrement symétrique, déchiffrer le certificat externe avec la première clé de chiffrement symétrique, au moyen de la clé publique de l’autorité de certification, vérifier l’authenticité du certificat externe, pour s’assurer qu’il est émis par un dispositif habilité par l’autorité de certification à recevoir la donnée secrète, recevoir une clé publique éphémère externe, générer une clé publique éphémère interne, transmettre la clé publique éphémère interne, générer une deuxième clé de chiffrement symétrique à partir de la clé publique éphémère externe, chiffrer la donnée secrète avec la deuxième clé de chiffrement symétrique, et transmettre la donnée secrète sous sa forme chiffrée avec la deuxième clé de chiffrement symétrique. Selon un mode de réalisation, le dispositif est configuré pour recevoir une signature de la clé publique éphémère externe, vérifier l’authenticité de la clé publique éphémère externe au moyen de la clé publique externe présente dans le certificat externe, pour s’assurer qu’un dispositif qui a émis la clé publique éphémère externe est le même qu’un dispositif qui a émis le certificat externe. Selon un mode de réalisation, le dispositif est configuré pour générer la deuxième clé de chiffrement symétrique à partir de la clé publique éphémère externe et de la clé publique éphémère interne. Selon un mode de réalisation, le dispositif est configuré pour générer la deuxième clé de chiffrement symétrique à partir de la clé publique éphémère externe et d’une clé privée éphémère interne. Selon un mode de réalisation, le dispositif est configuré pour générer la clé publique éphémère interne à partir du nombre entier. Selon un mode de réalisation, le dispositif est configuré pour générer le code de processus aléatoire et l’afficher sur un moyen d’affichage. Selon un mode de réalisation, le dispositif forme un portefeuille matériel de cryptoactifs. Selon un mode de réalisation, la donnée secrète est une phrase de récupération de comptes de cryptoactifs. Des modes de réalisation concernant également un dispositif électronique portatif comprenant un processeur sécurisé comportant des moyens de calcul cryptographique, une mémoire sécurisée, des moyens de communication, la mémoire sécurisée comprenant une clé privée, une clé publique, une clé publique d’une autorité de certification, un certificat signé par l’autorité de certification, le certificat comprenant la clé publique du dispositif et la signature de la clé publique du dispositif par l’autorité de certification, le dispositif comprenant un programme lui permettant de recevoir une donnée secrète externe, et étant configuré pour recevoir ou générer un code de processus aléatoire et le mémoriser, générer un nombre entier qui est fonction du code de processus, définir une première clé de chiffrement symétrique comme étant égale au nombre entier ou la générer à partir du nombre entier, chiffrer le certificat avec la première clé de chiffrement symétrique, transmettre le certificat sous sa forme chiffrée, générer une clé publique éphémère interne, transmettre la clé publique éphémère interne, recevoir une clé publique éphémère externe, générer une deuxième clé de chiffrement symétrique à partir de la clé publique éphémère externe, recevoir la donnée secrète externe sous une forme chiffrée avec la deuxième clé de chiffrement symétrique, et déchiffrer la donnée secrète avec la deuxième clé de chiffrement symétrique et stocker la donnée secrète dans la mémoire sécurisé. Selon un mode de réalisation, le dispositif est configuré pour signer la clé publique éphémère interne au moyen de la clé privée, et transmettre la signature de la clé publique éphémère. Selon un mode de réalisation, le dispositif est configuré pour générer la deuxième clé de chiffrement symétrique à partir de la clé publique éphémère externe et de la clé publique éphémère interne. Selon un mode de réalisation, le dispositif est configuré pour générer la deuxième clé de chiffrement symétrique à partir de la clé publique éphémère externe et d’une clé privée éphémère interne. Selon un mode de réalisation, le dispositif est configuré pour générer la clé publique éphémère interne à partir du nombre entier. Selon un mode de réalisation, le dispositif est configuré pour générer le code de processus aléatoire et l’afficher sur un moyen d’affichage. Selon un mode de réalisation, le dispositif forme un portefeuille matériel de cryptoactifs. Selon un mode de réalisation, la donnée secrète est une phrase de récupération de comptes de cryptoactifs. 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 de modes de réalisation d’un procédé de transfert d’une phrase de récupération entre deux portefeuilles matériels, faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : - la FIG. 1 montre deux portefeuilles matériels de cryptoactifs configurés pour échanger une phrase de récupération selon un premier mode de réalisation du procédé, - la FIG. 2 est un diagramme de séquence du premier mode de réalisation du procédé, - la FIG. 3 décrit des étapes du diagramme de séquence de la FIG. 2 , - la FIG. 4 montre deux portefeuilles matériels de cryptoactifs configurés pour échanger une phrase de récupération selon un deuxième mode de réalisation du procédé, - la FIG. 5 est un diagramme de séquence du deuxième mode de réalisation du procédé, - la FIG. 6 décrit des étapes du diagramme de séquence de la FIG. 5 , - la FIG. 7 est un diagramme de séquence d’un troisième mode de réalisation du procédé d’échange de phrase de récupération mis en œuvre avec les portefeuilles matériels de la FIG. 1 , - la FIG. 8 décrit des étapes du diagramme de séquence de la FIG. 7 . 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 transfert de la phrase de récupération dans un autre portefeuille matériel qui est automatisé tout en étant hautement sécurisé. Un tel procédé permet aux utilisateurs de s'affranchir de toutes les difficultés qui s'attachent au fait de devoir transférer manuellement la phrase de récupération dans un nouveau portefeuille matériel. La FIG. 2 montre schématiquement l’architecture classique de deux dispositifs WA, WB formant des portefeuilles matériels et configurés pour mettre en œuvre un mode de réalisation du procédé selon l’invention. Chaque dispositif comprend un processeur sécurisé SP comportant des moyens de calcul cryptographique, une mémoire sécurisée SMEM, une interface de communication CINT, un écran d’affichage DSP, un clavier KBD, et un générateur de données aléatoires RGEN qui en pratique peut être intégré dans le processeur sécurisé. Le processeur sécurisé SP peut être un élément sécurisé, à savoir un circuit intégré comprenant diverses protections contre des attaques matérielles et logicielles. La mémoire sécurisée SMEM, bien que représentée ici comme distincte du processeur sécurisé SP, peut être intégrée dans le processeur sécurisé SP, notamment s’il s’agit d’un élément sécurisé. La mémoire SMEM comprend une zone de mémoire non volatile recevant le système d’exploitation OS du processeur sécurisé, et une zone mémoire non volatile recevant ou destinée à recevoir la phrase de récupération RPH à partir de laquelle la clef maître de comptes de cryptoactifs est générée. Elle comprend également une zone de mémoire volatile recevant des données ou des variables volatiles, par exemple une donnée PCD spécifique au procédé selon l’invention, qui sera décrite plus loin. Le système d’exploitation OS de chaque dispositif WA, WB comprend un programme-application de transfert TAP1 (« Transfert Application ») prévu pour mettre en œuvre ce procédé. Dans le mode de réalisation montré sur la FIG. 1 , les dispositifs WA, WB ne peuvent pas communiquer ensemble et ne peuvent qu’être reliés à un dispositif hôte HD (ordinateur personnel, tablette ou téléphone mobile). Ce dispositif hôte comprend un processeur d’application AM et un programme compagnon CAP tel le logiciel « Ledger Live » commercialisé par la demanderesse. Une telle configuration correspond au cas le plus généralement rencontré de portefeuilles matériels dont l’interface de communication CINT n’offre qu’une connectivité USB ou Bluetooth ne leur permettant que de se connecter à un dispositif hôte. Le dispositif WA est par exemple un Ledger NanoX et le dispositif WB un autre Ledger NanoX ou un Ledger Stax, ce dernier étant équipé d’un clavier KBD virtuel affiché sur un écran tactile PCD. Afin de mettre en œuvre le procédé de l’invention, le dispositif hôte est ici pourvu d’un programme-application TAPHS (« Transfert Application Host Service ») qui complète le programme TAP1 exécuté par chaque dispositif WA, WB et établit un lien de communication en temps différé entre les deux dispositifs WA, WB, comme sera vu par la suite. Dans l’exemple représenté sur la FIG. 1 , le dispositif WA détient les clés des comptes de cryptoactifs d’un utilisateur USR et notamment la phrase de récupération RPH que l’on souhaite transférer au dispositif WB. Le seul transfert de celle-ci permettra au dispositif WB de retrouver les clés privées et publiques de l’ensemble des comptes de cryptoactifs qui y sont associés. Les figures 2 et 3 décrivent un mode de réalisation du procédé selon l’invention permettant de réaliser un tel transfert. Les différentes étapes représentées sur ces figures sont décrites dans ce qui suit. Etape S10, appliquée au dispositif WA : PersoWA : PkA, SkA, CIA=PkA, SIGN(SkI, PkA) Etape S20, appliquée au dispositif WB : PersoWB : PkB, SkB, CIB=PkB, SIGN(SkI, PkB) Afin de mettre en œuvre le procédé de l’invention, chaque dispositif WA, WB reçoit préalablement au cours de ces étapes de personnalisation S10 et S20, une clé privée SkA, SkB, une clé publique PkA, PkB, une clé publique PkI d’une autorité de certification ICA et un certificat CIA, CIB signé par l’autorité de certification. Il sera noté, concernant cette étape de personnalisation, que l’expression « chaque dispositif WA, WB reçoit une clé » ou « fournir une clé à chaque dispositif WA, WB » n'est pas limitative et inclut le mode de réalisation où la ou les clés considérée(s) est(sont) créée(s) localement par chaque dispositif WA, WB. Le certificat CIA, CIB comprend la clé publique PkA, PkB du dispositif et la signature SIGN(SkI, PkA), SIGN(SkI, PkB) de sa clé publique par l’autorité de certification, générée par l’autorité de certification au moyen de sa clé privée SkI. Ces clés sont strictement confidentielles et sont stockées dans la partie non volatile de la mémoire sécurisée SMEM de chaque dispositif. Etape S30, appliquée aux dispositifs WB, WA : Prepare Transfer L’utilisateur USR active l’application TAP1 dans chaque dispositif WB et WA, et configure les dispositifs WA et WB en indiquant au dispositif WB qu’il est le receveur de la phrase de récupération et au dispositif WA qu’il est le donneur de la phrase de récupération. L’utilisateur active également dans le dispositif hôte HD l’application de transfert TAPHS. Etape S40 : « PCD_GEN » (1) WB → PCD → USR → WA (2) WA → PCD → USR → WB (3) USR → PCD → WB, WA Au cours de cette étape, qui se décline en trois variantes, un code de processus aléatoire PCD (« Process Code ») est fourni aux dispositifs WA, WB. Ces variantes sont les suivantes : (1) le dispositif WB génère le code de processus PCD au moyen du générateur aléatoire RGEN, le mémorise et l’affiche à l’utilisateur USR sur son écran DSP. L’utilisateur lit le code de processus PCD et le fournit au dispositif WA via le clavier KBD du dispositif WA, qui mémorise le code. (2) le dispositif WA génère le code de processus PCD au moyen du générateur aléatoire RGEN, le mémorise et l’affiche à l’utilisateur USR. L’utilisateur fournit le code PCD au dispositif WB via le clavier KBD du dispositif WB, qui mémorise le code. (3) l’utilisateur USR génère le code de processus PCD, par exemple au moyen d’un générateur de code aléatoire externe, puis fournit le code PCD au dispositif WB et au dispositif WA via leurs claviers KBD respectifs. Ces derniers mémorisent le code PCD. Etape S50, appliquée au dispositif HD : Start Transfer L’utilisateur initie le processus en indiquant à l’application de transfert TAPHS du dispositif hôte HD que l'étape de fourniture du code PCD aux dispositifs WA, WB est terminée. Le dispositif hôte HD dispose d’une liste de commandes destinées à être envoyées séquentiellement au dispositif WB et WA, qu’il va émettre de la manière décrite dans ce qui suit. Dans ce mode de réalisation, les dispositifs WA, WB ne peuvent que recevoir et répondre à des commandes du dispositif hôte. Etape S60, exécutée par le dispositif HD : Connect WB Le dispositif hôte HD demande à l’utilisateur de connecter le dispositif WB au dispositif hôte HD si cela n’est pas fait. Etape S101, exécutée par le dispositif HD à l’attention du dispositif WB : Get Certificate Le dispositif hôte HD demande ici au dispositif WB de lui communiquer son certificat Etape S103, exécutée par le dispositif WB : w=HASH384(PCD) mod n Le dispositif WB prépare l’envoi de son certificat en générant tout d’abord un nombre entier w de 384 bits par hachage du code de processus PCD au moyen d’une fonction de hachage HASH, par exemple SHA384. Le choix d’un nombre entier modulo n est optionnel pour cette étape mais est lié ici à un besoin de calcul ultérieur sur une courbe elliptique d’ordre n faisant intervenir le nombre w. Par exemple, dans le cas de la courbe elliptique SECP384R1, n est égal à : 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC7634D81F4372DDF581A0DB248B0A77AECEC196ACCC52973, Cf. Standards for Efficient Cryptography - SEC 2: Recommended Elliptic Curve Domain Parameters - Certicom Research - January 27, 2010 - Version 2.0 – https://www.secg.org/sec2-v2.pdf. Etape S105, exécutée par le dispositif WB : ENC(w, CIB) Le dispositif WB chiffre le certificat CIB en utilisant le nombre w comme clé de chiffrement, au moyen d’une fonction de chiffrement symétrique, par exemple la fonction AES (« Advanced Encryption Standard »). Dans une variante, une clé de chiffrement w’ différente du nombre w peut être dérivée de celui-ci et utilisée pour cette opération. Etape S107, exécutée par le dispositif WB à l’attention du dispositif HD : Response to Get Certificate : ENC(w, CIB) En réponse à la commande, le résultat du chiffrement du certificat CIB est maintenant envoyé au dispositif hôte HD, qui le mémorise. Etape S109, exécutée par le dispositif HD à l’attention du dispositif WB : Get Ephemeral Certificate Le dispositif hôte HD envoie ici au dispositif WB la commande suivante figurant dans la liste de commandes à envoyer. Cette commande demande au dispositif WB de communiquer une clé publique éphémère accompagnée de sa signature générée au moyen de sa clé privée, l’ensemble formant un certificat éphémère. Dans une variante, le dispositif hôte pourrait demander au dispositif WB de ne fournir qu’une clé publique éphémère, sans signature. Il sera toutefois vu plus loin que cette signature permet au dispositif WA de s’assurer que le dispositif qui a fourni le certificat chiffré « ENC(w, CIB) » est le même que celui qui fournit la clé publique éphémère. Etape S111, exécutée par le dispositif WB : X=x*P Pour initier le processus de génération d’une clé publique éphémère, le dispositif WB tire aléatoirement un nombre x et calcule un nombre X avec un générateur P de la courbe elliptique utilisée, par exemple la courbe SECP384R1 permettant de générer des mots de 384 bits, X étant un point de la courbe, l’opération x*P étant la multiplication scalaire. Etape S113, exécutée par le dispositif WB : PkeB=w*M + X Le dispositif WB génère ensuite une clé publique éphémère PkeB en effectuant le produit scalaire de w avec M auquel est additionné X. M est une constante dont des valeurs peuvent par exemple être trouvées dans la section 6.6 du document RFC 9382 - Spake2 - Septembre 2023 - ISSN 2070- 1721 - W. Ladd – https://www.rfc-editor.org/rfc/rfc9382.html. Il sera noté ici que la clé privée éphémère du dispositif WB, correspondant à la clé publique éphémère PkeB, peut être considérée comme étant formée par la paire [x, w]. Etape S115, exécutée par le dispositif WB : SIGN(SkB, PkeB) Le dispositif WB calcule ensuite la signature de la clé publique éphémère au moyen de sa clé privée SkB, pour former un certificat éphémère PkeB, SIGN(SkB, PkeB). La fonction de signature utilisée est par exemple la signature ECDSA (« Elliptic Curve Digital Signature Algorithm ») utilisée avec la courbe elliptique SECP384R1. Etape S117, exécutée par le dispositif WB à l’attention du dispositif HD : Response to Get Ephemeral Certificate : PkeB, SIGN(SkB, PkeB) En réponse à cette commande, le dispositif WB envoie ici au dispositif hôte HD le certificat éphémère PkeB, SIGN(SkB, PkeB). Celui-ci est mémorisé par le dispositif hôte HD. Etape S119, exécutée par le dispositif HD à l’attention du dispositif USR : Connect WA L’utilisateur est invité par le dispositif hôte HD à déconnecter le dispositif WB et à connecter le dispositif WA. Il peut être prévu que l’utilisateur doit ensuite appuyer sur une touche pour confirmer la poursuite du processus. Etape S121, exécutée par le dispositif HD à l’attention du dispositif WA : Verify Certificate ENC(w, CIB) Au cours de cette étape, le dispositif hôte HD répercute au dispositif WA le certificat CIB du dispositif WB et lui demande de le vérifier. Etape S123, exécutée par le dispositif WA : w=HASH384(PCD) mod n Dans ce but, le dispositif WA calcule à son tour le nombre w à partir du code de processus PCD. Etape S125, exécutée par le dispositif WA : DEC(w, ENC(w, CIB)) Une fois w calculé, le dispositif WA peut déchiffrer le certificat du dispositif WB en utilisant le nombre w comme clé de déchiffrement et une fonction de déchiffrement DEC correspondant à la fonction de chiffrement ENC. Etape S127, exécutée par le dispositif WA : Verify(PkI, CIB) Une fois le certificat CIB déchiffré (CIB=PkB, SIGN(SkI, PkB)), le dispositif WA vérifie que ce certificat possède une signature authentique, en utilisant la clé publique PkI de l’autorité de certification. Etape S129, exécutée par le dispositif WA à l’attention du dispositif HD : Success/Error Le dispositif WA est maintenant en mesure de répondre à la commande « Verify Certificate » précédemment reçue et renvoie un message de succès ou d’erreur. Si l’authenticité du certificat est vérifiée, cela confirme que le deuxième dispositif WB est habilité par l’autorité de certification ICA à recevoir la phrase de récupération, Etape S131, exécutée par le dispositif HD à l’attention du dispositif WA : Verify Ephemeral Certificate PkeB, SIGN(SkB, PkeB) Le dispositif hôte HD demande maintenant au dispositif WA de vérifier le certificat éphémère du dispositif WB comprenant la clé publique éphémère et sa signature au moyen de la clé privée SkB. Etape S133, exécutée par le dispositif WA : Verify(PkB, SIGN(SkB, PkeB) Le dispositif WA qui a précédemment obtenu, après déchiffrement du certificat CIB, la clé publique PkB du dispositif WB présente dans ce certificat, peut maintenant vérifier que la signature de la clé publique éphémère PkeB présente dans le certificat éphémère est correcte, en utilisant la clé publique PkB. Etape S135, exécutée par le dispositif WA à l’attention du dispositif HD : Success/Error Le dispositif WA confirme le succès de l’étape de vérification. En cas d’erreur le processus est interrompu. Etape S137, exécutée par le dispositif HD à l’attention du dispositif WA : Get Ephemeral Public Key Le dispositif hôte HD demande maintenant au dispositif WA de lui fournir une clé publique éphémère. Etape S139, exécutée par le dispositif WA : Y=y*P Pour commencer, le dispositif WA tire aléatoirement un nombre y et calcule un nombre Y avec le générateur P de la courbe elliptique retenue, la même que précédemment, par exemple la courbe SECP384R1, Y étant un point de la courbe P. Etape S141, exécutée par le dispositif WA : PkeA=w*N + Y Le dispositif WA génère ensuite la clé publique éphémère PkeA en effectuant le produit scalaire de w avec N auquel est additionné Y. N est une constante dont des valeurs peuvent par exemple être trouvées dans la section 6.6 du document RFC 9382 Spake2 précité. Comme précédemment, on peut considérer ici que la clé privée éphémère du dispositif WA, correspondant à la clé publique éphémère PkeA, est formée par la paire [y, w] Etape S143, exécutée par le dispositif WA à l’attention du dispositif HD : Response to Get Ephemeral Public Key : PkeA Le dispositif WA répond ici à la commande précédemment reçue en envoyant au dispositif hôte HD la clé publique éphémère PkeA qu’il vient de générer. Etape S145, exécutée par le dispositif HD à l’attention du dispositif WA : Get Transfer RPH Le dispositif hôte HD demande maintenant au dispositif WA de lui transférer la phrase de récupération RPH Etape S147, exécutée par le dispositif WA : K=y*(PkeB-w*N) Suite à cette commande, le dispositif WA calcule tout d’abord un secret partagé K au moyen de la formule ci-dessus, qui met en jeu la partie y de sa clé privée, le nombre w, la constante N et la clé éphémère PkeB du dispositif WB. Etape S149, exécutée par le dispositif WA : TT=len(A)||A||len(B)||B||len(PkeB)|PkeB||len(PkeA)||PkeA ||len(K)||K||len(w)||w Au cours de cette étape, le dispositif WA calcule un transcript TT par concaténation des données mentionnées dans la formule ci-dessus et de leurs longueurs respectives (« len »). En effet K est une valeur partagée, qui ne doit pas être utilisée ou mise en jeu directement dans des échanges de données, et doit donc être protégée en tant que secret partagé. A et B sont deux données supplémentaires de valeur prédéterminée utilisés pour le calcul de TT. Dans un mode de réalisation, la chaîne len(A)||A||len(B) ||B|| peut ne pas être utilisée. Il sera enfin noté que l’utilisation du transcript TT garantit que toute manipulation par un faudeur des messages envoyés se reflétera dans les clés générées au cours de l’étape suivante. Etape S151, exécutée par le dispositif WA : Ke||Ka=HASH(TT) Au cours de cette étape, le dispositif WA génère une chaîne binaire, par exemple de 512 bits, formant deux clés Ke et Ka, par exemple de 256 bits chacune. La fonction de hachage HASH utilisée est par exemple SHA 512. La clé Ke sera utilisée comme clé de chiffrement symétrique pour le transfert sous forme chiffrée de la phrase de récupération RPH tandis que la clé Ka sera utilisée pour la dérivation de deux clés KcA, KcB. Etape S153, exécutée par le dispositif WA : KcA||KcB=KDF(Ka, “ConfirmationKeys”||AAD) Au cours de cette étape, le dispositif WA génère des clés KcA et KcB au moyen d’une fonction KDF de dérivation de clés, par exemple la fonction HKDF (« HMAC-based Key Derivation Fonction ») basée sur le code d'authentification de message HMAC. Les clés KcA et KcB seront utilisées plus loin pour prouver que chaque dispositif WB, WA a bien calculé la clé de son côté. Le terme « ConfirmationKeys » est une chaîne de caractère prédéterminée. De façon générale, toute autre chaîne de caractères définie par consensus peut être utilisée ici pour former une séparation de domaines. Enfin, AAD est une chaîne de données additionnelle optionnelle pour ajouter de l’entropie à la dérivation de clés, AAD devant être connu des deux dispositifs WA, WB. Etape S155, exécutée par le dispositif WA : cB=MAC(KcB, TT) Le dispositif WA calcule ici un code d’authentification cB en appliquant une fonction MAC (« Message Authentication Code ») au transcript TT, le code étant généré à partir de la clé KcB. La fonction MAC peut par exemple être l’algorithme HMAC (« Keyed Hash Message Authentication Code ») ou CMAC (« Cipher-based Message Authentication Code »). L’homme de l’art aura noté dans ce qui précède que diverses étapes du procédé se fondent sur la même variable aléatoire w. Il sera en outre noté que selon l’usage habituel de certaines étapes du procédé qui vient d’être décrit, K devrait être une donnée secrète que deux dispositifs partagent, cB étant la donnée de confirmation que s’échangent deux dispositifs. Ici, ces étapes sont utilisées pour générer la clé de chiffrement Ke de la phrase de récupération RPH à transmettre, à laquelle le code cB pourra optionnellement être joint. Etape S157, exécutée par le dispositif WA : ENC(Ke, RPH) Au cours de cette étape, le dispositif WA chiffre la phrase de récupération RPH au moyen du secret partagé Ke utilisé comme clé de chiffrement. L’algorithme de chiffrement ENC peut comme précédemment être par exemple une fonction AES (« Advanced Encryption Standard »). Etape S159, exécutée par le dispositif WA à l’attention du dispositif HD : Response to Get Transfer RPH : ENC(Ke, RPH), cB En réponse à la commande précédemment reçue, le dispositif WA transmet donc ici au dispositif hôte HD la phrase de récupération RPH chiffrée, ainsi que, optionnellement, le code de confirmation cB. Etape S161, exécutée par le dispositif HD à l’attention du dispositif USR : Connect WB L’utilisateur est invité par le dispositif hôte à déconnecter le dispositif WA et à connecter le dispositif WB. Il peut être prévu que l’utilisateur doive ensuite appuyer sur une touche pour confirmer la poursuite du processus. Etape S163, exécutée par le dispositif HD à l’attention du dispositif WB : Set Ephemeral Public Key : PkeA Au cours de cette étape, le dispositif hôte HD répercute au dispositif WB la clé publique éphémère PkeA du dispositif WA, qu’il a mémorisée. Etape S165, exécutée par le dispositif WB : K=x*(PkeA-w*M) Le dispositif WB calcule le secret partagé K en utilisant la partie x de sa clé privée, la clé éphémère PkeA du dispositif WA et la constante M. Etape S167, exécutée par le dispositif WB à l’attention du dispositif HD : Success/Error Ce message de réponse peut être prévu optionnellement en application d’une règle selon laquelle toute commande doit être suivie d’une réponse, dont le rôle est au moins de confirmer la bonne réception de la commande. Etape S169, exécutée par le dispositif HD à l’attention du dispositif WB : Set transfer : ENC(Ke, RPH), cB Au cours de cette étape, le dispositif hôte HD répercute au dispositif WB la phrase de récupération RPH chiffrée ainsi que, optionnellement, la donnée de confirmation cB. Etape S171, exécutée par le dispositif WB : TT=len(A)||A||len(B)||B||len(PkeB)|PkeB||len(PkeA)||PkeA ||len(K)||K||len(w)||w Comme le dispositif WA l’a fait précédemment, le dispositif WB calcule ici le transcript TT. Etape S173, exécutée par le dispositif WB : Ke||Ka=HASH(TT) Comme le dispositif WA l’a fait précédemment, le dispositif WB génère ici les clés Ke et Ka. Etape S175, exécutée par le dispositif WB : KcA||KcB=KDF(Ka, “ConfirmationKeys”||AAD) Comme le dispositif WA l’a fait précédemment, le dispositif WB calcule ici des clés KcA et KcB. Etape S177, exécutée par le dispositif WB : cB=MAC(KcB, TT) Comme le dispositif WA l’a fait précédemment, le dispositif WB calcule ici le code d’authentification cB. Etape S179, exécutée par le dispositif WB : DEC(Ke, ENC(Ke, RPH))=RPH Le dispositif WB déchiffre ici au moyen de la clé Ke et de la fonction de déchiffrement DEC la phrase de récupération RPH, puis la stocke dans sa mémoire sécurisée. Etape S181, exécutée par le dispositif WB à l’attention du dispositif HD : Success/Error Ce message de succès confirme à l’utilisateur que la phrase de récupération a bien été transférée. Ce dernier peut alors, s’il le souhaite, effacer toutes les données présentes dans le dispositif WA. La FIG. 4 illustre un mode de réalisation du procédé de transfert dans lequel les deux dispositifs WA, WB peuvent communiquer directement ensemble, sans passer par l’intermédiaire du dispositif hôte HD, qui est représenté ici en traits pointillés car il est toujours susceptible d’être utilisé par chaque dispositif WA, WB pour placer des transactions sur une blockchain. Les interfaces de communication CINT de chaque dispositif WA, WB sont ici directement reliées par un canal de communication, par lequel la phrase de récupération RPH va être envoyée par le dispositif WA au dispositif WB. Les dispositifs WA, WB sont ici pourvu d’une application de transfert TAP2 qui gère les échanges directs entre les deux dispositifs. Les dispositifs WA, WB sont par exemple des Ledger Stax commercialisés par la demanderesse, équipés d’une connectivité NFC leur permettant de communiquer directement. Il peut également s’agir de téléphones mobiles équipés d’une fonction de portefeuille de cryptoactifs et ne nécessitant pas d’être couplés à un dispositif hôte. Le dispositif hôte est dans ce cas formé par le processeur d'application du téléphone mobile, tandis que la fonction de portefeuille matériel est mise en œuvre par logiciel (« software wallet ») ou au moyen d’un élément sécurisé intégré dans le téléphone mobile. Les figures 5 et 6 qui décrivent un mode de réalisation du procédé permettant de réaliser le transfert de la phrase de récupération sans passer par le dispositif hôte. Les différentes étapes représentées sur ces figures sont décrites dans ce qui suit. Les étapes précédemment décrites seront mentionnées mais ne seront pas décrites de nouveau. Etape S10, appliquée au dispositif WA : PersoWA : PkA, SkA, CIA=PkA, SIGN(SkI, PkA) Etape S20, appliquée au dispositif WB : PersoWB : PkB, SkB, CIB=PkB, SIGN(SkI, PkB) Etape S31 appliquée aux dispositifs WB, WA : Prepare Transfer Cette étape se distingue de l’étape S30 précédemment décrite en ce que l’utilisateur active ici les applications de transfert TAP2 dans les dispositifs WB et WA. Les applications TAP2 sont configurées pour que chaque dispositif puisse envoyer des commandes ou réponde à des commandes émises par l’autre dispositif. L’utilisateur configure ici les dispositifs WA et WB en indiquant au dispositif WB qu’il est le receveur de la phrase de récupération et au dispositif WA qu’il est le donneur de la phrase de récupération. Etape S40 « PCD_GEN », de génération du code PCD selon l’une des trois variantes susmentionnées : (1) WB → PCD → USR → WA (2) WA → PCD → USR → WB (3) USR → PCD → WB, WA Etape S51, appliquée aux dispositifs WA, WB : Start Transfer Cette étape se distingue de l’étape S50 précédemment décrite en ce que l’utilisateur active dans chaque dispositif WA, WB l’engagement du processus de transfert qui commence par l’établissement d’une communication entre les deux dispositifs. Etape S201 exécutée par le dispositif WA à l’attention du dispositif WB : Get Certificate Le dispositif WA demande au dispositif WB de lui communiquer son certificat CIB. Cette commande est la même que celle envoyée à l’étape S101 précédemment décrite mais est ici envoyée directement par le dispositif WA puisque le dispositif hôte n’agit plus comme intermédiaire. Etape S103 exécutée par le dispositif WB : w = HASH384(PCD) mod n Etape S105 exécutée par le dispositif WB : ENC(w, CIB) Etape S207 exécutée par le dispositif WB à l’attention du dispositif WA : Response to Get Certificate : ENC(w, CIB) Cette étape correspond à la combinaison des étapes S107, S121 précédemment décrites, puisque le dispositif hôte n’agit plus comme intermédiaire. Etape S123 exécutée par le dispositif WA : w = HASH384(PCD) mod n Etape S125 exécutée par le dispositif WA : DEC(w, ENC(w, CIB)) Etape S127 exécutée par le dispositif WA : Verify(PkI, CIB) Etape S209 exécutée par le dispositif WA à l’attention du dispositif WB : Get Ephemeral Certificate Cette commande est la même que celle envoyée à l’étape S109 précédemment décrite mais la commande est ici envoyée directement par le dispositif WA puisque le dispositif hôte n’agit plus comme intermédiaire. Etape S111 exécutée par le dispositif WB : X = x*P Etape S113 exécutée par le dispositif WB : PkeB = w*M + X Etape S115 exécutée par le dispositif WB : SIGN(SkB, PkeB) Etape S217 exécutée par le dispositif WB à l’attention du dispositif WA : Response to Get Ephemeral Certificate : PkeB, SIGN(SkB, PkeB) Cette étape correspond à la combinaison des étapes S117, S131 précédemment décrites. Etape S133 exécutée par le dispositif WA : Verify(PkB, SIGN(SkB, PkeB) Cette étape a été précédemment décrite mais est engagée ici à réception du certificat éphémère et sans qu’il soit nécessaire d’envoyer au dispositif WA le commande « Verify Ephemeral Certificate PkeB, SIGN(SkB, PkeB) » émise à l’étape S131 précédemment décrite. Comme le dispositif WA a déchiffré le certificat CIB à l’étape S125, il a connaissance de la clé publique PkB du dispositif WB et peut vérifier le certificat éphémère. Etape S235 exécutée par le dispositif WA à l’attention du dispositif WB : Success/Error Cette réponse est identique à la réponse de l’étape S135 précédemment décrite, mais est envoyée directement au dispositif WA puisque le dispositif hôte n’agit plus comme intermédiaire haut Etape S139 exécutée par le dispositif WA : Y = y*P Etape S141 exécutée par le dispositif WA : PkeA = w*N + Y Etape S243 exécutée par le dispositif WA à l’attention du dispositif WB : Set ephemeral public key : PkeA Cette étape correspond à la combinaison des étapes S143, S163 précédemment décrites. Etape S165 exécutée par le dispositif WB : K = x*(PkeA - w*M) Etape S266 exécutée par le dispositif WB à l’attention du dispositif WA : Success/Error Le dispositif WB confirme ici au dispositif WA qu’il a fini son calcul. Etape S147 exécutée par le dispositif WA : K = y*(PkeB - w*N) Etape S149 exécutée par le dispositif WA : TT=len(A)||A||len(B)||B||len(PkeB)|PkeB||len(PkeA)||PkeA ||len(K)||K||len(w)||w Etape S151 exécutée par le dispositif WA : Ke||Ka = HASH(TT) Etape S153 exécutée par le dispositif WA : KcA||KcB = KDF(Ka, “ConfirmationKeys”||AAD) Etape S155 exécutée par le dispositif WA : cB=MAC(KcB, TT) Etape S157 exécutée par le dispositif WA : ENC(Ke, RPH) Etape S259 exécutée par le dispositif WA à l’attention du dispositif WB : Set transfer : ENC(Ke, RPH), cB Cette étape par laquelle le dispositif WA envoie au dispositif WB la phrase de récupération RPH chiffrée ainsi que, optionnellement, le code cB, correspond à la combinaison des étapes S159, S169 précédemment décrites. Etape S171 exécutée par le dispositif WB : TT=len(A)||A||len(B)||B||len(PkeB)|PkeB||len(PkeA)||PkeA ||len(K)||K||len(w)||w Etape S173 exécutée par le dispositif WB : Ke||Ka = HASH(TT) Etape S175 exécutée par le dispositif WB : KcA||KcB = KDF(Ka, “ConfirmationKeys”||AAD) Etape S177 exécutée par le dispositif WB : cB=MAC(KcB, TT) Etape S179 exécutée par le dispositif WB : DEC(Ke, ENC(Ke, RPH)) = RPH Etape S281 exécutée par le dispositif WB à l’attention du dispositif WA : Success/Error Cette réponse est identique à la réponse envoyée à l’étape S181 précédemment décrite mais est envoyée directement au dispositif WA. Il apparaîtra clairement à l’homme de l’art que le procédé de l’invention peut être mis en œuvre avec d’autres procédés permettant aux dispositifs WA ,WB de définir une clé de chiffrement commune. A titre d’exemple, les figures 7 et 8 décrivent une variante du procédé des figures 2 et 3 dans laquelle un échange de clés ECDH (« Elliptic Curve Diffie–Hellman ») basé sur les courbes elliptiques est mis en œuvre. Les différentes étapes représentées sur ces figures sont décrites dans ce qui suit. Les étapes précédemment décrites seront mentionnées mais ne seront pas décrites de nouveau. Etape S10, appliquée au dispositif WA : PersoWA : PkA, SkA, CIA=PkA, SIGN(SkI, PkA) Etape S20, appliquée au dispositif WB : PersoWB : PkB, SkB, CIB=PkB, SIGN(SkI, PkB) Etape S30, appliquée aux dispositifs WB, WA : Prepare Transfer Etape S40 : « PCD_GEN » (1) WB → PCD → USR → WA (2) WA → PCD → USR → WB (3) USR → PCD → WB, WA Etape S50, appliquée au dispositif HD : Start Transfer Etape S60, exécutée par le dispositif HD : Connect WB Etape S101, exécutée par le dispositif HD à l’attention du dispositif WB : Get Certificate Etape S103, exécutée par le dispositif WB : w = HASH384(PCD) mod n Etape S105, exécutée par le dispositif WB : ENC(w, CIB) Etape S107, exécutée par le dispositif WB à l’attention du dispositif HD : Response to Get Certificate : ENC(w, CIB) Etape S109, exécutée par le dispositif HD à l’attention du dispositif WB : Get Ephemeral Certificate Etape S311, exécutée par le dispositif WB : (SkeB, PkeB ) = AsymKeyGen() Le dispositif WB génère une clé privée éphémère SkeB et une clé publique éphémère PkeA au moyen d'un générateur de clés asymétriques. Etape S115, exécutée par le dispositif WB : SIGN(SkB, PkeB) Etape S117, exécutée par le dispositif WB à l’attention du dispositif HD : Response to Get Ephemeral Certificate : PkeB, SIGN(SkB, PkeB) Etape S119, exécutée par le dispositif HD à l’attention du dispositif USR : Connect WA Etape S121, exécutée par le dispositif HD à l’attention du dispositif WA : Verify Certificate ENC(w, CIB) Etape S123, exécutée par le dispositif WA : w = HASH384(PCD) mod n Etape S125, exécutée par le dispositif WA : DEC(w, ENC(w, CIB)) Etape S127, exécutée par le dispositif WA : Verify(PkI, CIB) Etape S129, exécutée par le dispositif WA à l’attention du dispositif HD : Success/Error Etape S131, exécutée par le dispositif HD à l’attention du dispositif WA : Verify Ephemeral Certificate PkeB, SIGN(SkB, PkeB) Etape S133, exécutée par le dispositif WA : Verify(PkB, SIGN(SkB, PkeB) Etape S135, exécutée par le dispositif WA à l’attention du dispositif HD : Success/Error Etape S137, exécutée par le dispositif HD à l’attention du dispositif WA : Get Ephemeral Public Key Etape S339, exécutée par le dispositif WA : (SkeA, PkeA ) = AsymKeyGen() Le dispositif WA génère une clé privée éphémère SkeA et une clé publique éphémère PkeA au moyen du générateur de clés asymétriques. Etape S143, exécutée par le dispositif WA à l’attention du dispositif HD : Response to Get Ephemeral Public Key : PkeA Etape S145, exécutée par le dispositif HD à l’attention du dispositif WA : Get Transfer RPH Etape S347, exécutée par le dispositif WA : K = SkeA*PkeB Conformément au procédé d’échange de clés Diffie-Hellman basé sur les courbes elliptiques, le dispositif WA génère ici une clé partagée K en calculant le produit scalaire de sa clé privée éphémère SkeA et de la clé publique éphémère PkeB du dispositif WB. Etape S348, exécutée par le dispositif WA : Ke||Ka = KDF(K) Le dispositif WA calcule des clés Ke et Ka à partir de K et au moyen de la fonction KDF de dérivation de clés. Etape S349, exécutée par le dispositif WA : ENC-MAC(Ke||Ka, RPH) Le dispositif WA chiffre la phrase de récupération RPH avec la clé Ke, au moyen de la fonction de chiffrement ENC, et calcule un code d’authentification de message avec la clé Ka et au moyen d’une fonction de signature MAC. Etape S359, exécutée par le dispositif WA à l’attention du dispositif HD : Response to Get Transfer RPH : ENC-MAC(Ke||Ka, RPH) Le dispositif WA transmet ici à HD la phrase de récupération RPH chiffrée, ainsi que le code d’authentification MAC. Etape S161, exécutée par le dispositif HD à l’attention du dispositif USR : Connect WB Etape S163, exécutée par le dispositif HD à l’attention du dispositif WB : Set Ephemeral Public Key : PkeA Etape S365, exécutée par le dispositif WB : K = SkeB*PkeA (=SkeA*PkeB) Le dispositif WB génère ici la clé partagée K en calculant le produit scalaire de sa clé privée éphémère SkeB et de la clé publique éphémère PkeA du dispositif WA. Etape S167, exécutée par le dispositif WB à l’attention du dispositif HD : Success/Error Etape S369, exécutée par le dispositif HD à l’attention du dispositif WB : Set transfer : ENC-MAC(Ke||Ka, RPH) Le dispositif hôte HD répercute au dispositif WB la phrase de récupération RPH chiffrée ainsi que le code d’authentification MAC. Etape S371, exécutée par le dispositif WB : Ke||Ka = KDF(K) Le dispositif WB calcule des clés Ke et Ka à partir de K et au moyen de la fonction KDF de dérivation de clés. Etape S373, exécutée par le dispositif WB : DEC-MAC(Ke||Ka, ENC-MAC(Ke||Ka, RPH)) Le dispositif WA déchiffre la phrase de récupération RPH avec la clé Ke, et vérifie le code d’authentification MAC. Etape S181, exécutée par le dispositif WB à l’attention du dispositif HD : Success/Error Il apparaîtra clairement à l’homme de l’art que le procédé qui vient d’être décrit est susceptible de diverses autres variantes. Bien qu’initialement conçu pour permettre le transfert d’une phrase de récupération entre deux portefeuilles matériels, le procédé est également susceptible de diverses applications pour le transfert d’autres types de données secrètes entre divers types de dispositifs. Procédé pour transférer une donnée secrète (RPH) d’un premier dispositif (WA) à un deuxième dispositif (WB), dans lequel chaque dispositif comprend un processeur sécurisé (SP) comportant des moyens de calcul cryptographique, une mémoire sécurisée (SMEM), et des moyens de communication (CINT), le procédé comprenant les étapes consistant à : - fournir (S10, S20) à chaque dispositif une clé privée (SkA, SkB), une clé publique (PkA, PkB), une clé publique (PkI) d’une autorité de certification (ICA), un certificat (CIA, CIB) signé par l’autorité de certification, le certificat comprenant la clé publique du dispositif (PkA, PkB) et la signature (SIGN(SkI, PkA), SIGN(SkI, PkB)) de sa clé publique par l’autorité de certification, - fournir (S40) aux dispositifs un code de processus aléatoire (PCD) commun aux deux dispositifs, et au moyen du premier dispositif (WA) : - générer (S123) un nombre entier (w) qui est fonction du code de processus (PCD), - définir une première clé de chiffrement symétrique comme étant égale au nombre entier (w) ou la générer à partir du nombre entier (w), - recevoir (S107, S121, S221) le certificat (CIB) du deuxième dispositif (WB) sous une forme chiffrée (ENC(w, CIB)) au moyen de la première clé de chiffrement symétrique (w), - déchiffrer (S125) le certificat (CIB) du deuxième dispositif (WB) avec la première clé de chiffrement symétrique (w), - au moyen de la clé publique (PkI) de l’autorité de certification, vérifier (S127) l’authenticité du certificat du deuxième dispositif, pour s’assurer que le deuxième dispositif est habilité par l’autorité de certification (ICA) à recevoir la donnée secrète, - recevoir (S117, S131, S217) une clé publique éphémère (PkeB) du deuxième dispositif (WB), - générer (S139-S141) une clé publique éphémère (PkeA), - transmettre (S143, S163, S263) la clé publique éphémère (PkeA), - générer (S147-S149-S151, S347) une deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère (PkeB) du deuxième dispositif (WB), - chiffrer (S157) la donnée secrète (RPH) avec la deuxième clé de chiffrement symétrique (Ke), et - transmettre (S159, S169, S269) la donnée secrète (RPH) sous sa forme chiffrée (ENC(Ke, RPH) avec la deuxième clé de chiffrement symétrique (Ke). Procédé selon la revendication 1, comprenant les étapes consistant à, au moyen du premier dispositif (WA) : - recevoir (S117, S131, S217) une signature (SIGN(SkB, PkeB)) de la clé publique éphémère (PkeB) du deuxième dispositif, générée au moyen de la clé privée (SkB) du deuxième dispositif (WB), et - vérifier (S133) l’authenticité de la clé publique éphémère (PkeB) du deuxième dispositif (WB) au moyen de la clé publique (PkB) du deuxième dispositif présente dans le certificat (CIB) du deuxième dispositif, pour s’assurer que le deuxième dispositif qui a émis la clé publique éphémère est le même que le deuxième dispositif qui a émis le certificat. Procédé selon l’une des revendications 1 et 2, dans lequel le premier dispositif (WA) génère (S147-S149-S151) la deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère (PkeB) du deuxième dispositif (WB) et de la clé publique éphémère (PkeA) du premier dispositif (WA). Procédé selon l’une des revendications 1 et 2, dans lequel le premier dispositif (WA) génère (S347) la deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère (PkeB) du deuxième dispositif (WB) et d’une clé privée éphémère (SkeA) du premier dispositif (WA). Procédé selon l’une des revendications 1 à 4, dans lequel le premier dispositif (WA) génère (S139-S141) sa clé publique éphémère (PkeA) à partir du nombre entier (w). Procédé selon la revendication 1, comprenant les étapes consistant à, au moyen du deuxième dispositif (WB) : - générer (S103) le nombre entier (w) qui est fonction du code de processus (PCD), de la même manière que le premier dispositif (WA), - définir la première clé de chiffrement symétrique comme étant égale au nombre entier (w) ou la générer à partir du nombre entier (w), de la même manière que le premier dispositif (WA), - chiffrer (S105) le certificat (CIB) du deuxième dispositif (WB) avec la première clé de chiffrement symétrique (w), - transmettre (S107, S207) le certificat (CIB) du deuxième dispositif (WB) sous sa forme chiffrée (ENC(w, CIB)), - générer (S111, S113) la clé publique éphémère (PkeB) du deuxième dispositif (WB), - transmettre (S117, S131, S217) la clé publique éphémère (PkeB) du deuxième dispositif (WB), - recevoir (S143, S163, S263) la clé publique éphémère (PkeA) du premier dispositif (WA), - générer (S171, S173, S365) ladite deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère (PkeA) du premier dispositif (WA), - recevoir (S159, S169, S269) la donnée secrète (RPH) sous ladite forme chiffrée (ENC(Ke, RPH) avec la deuxième clé de chiffrement symétrique (Ke), et - déchiffrer (S179) la donnée secrète (RPH) avec la deuxième clé de chiffrement symétrique (Ke) et stocker la donnée secrète dans la mémoire sécurisé (SMEM). Procédé selon la revendication 6, comprenant les étapes consistant à, au moyen du deuxième dispositif (WB) : - signer (S115) la clé publique éphémère (PkeB) du deuxième dispositif au moyen de la clé privée (SkB) du deuxième dispositif, et - transmettre (S117, S131, S217) la signature de la clé publique éphémère (PkeB) du deuxième dispositif. Procédé selon l’une des revendications 6 et 7, dans lequel le deuxième dispositif (WB) génère (S171, S173) la deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère (PkeA) du premier dispositif (WA) et de la clé publique éphémère (PkeB) du deuxième dispositif (WB). Procédé selon l’une des revendications 6 et 7, dans lequel le deuxième dispositif (WB) génère (S365) la deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère (PkeA) du premier dispositif (WA) et d’une clé privée éphémère (SkeB) du deuxième dispositif (WB). Procédé selon l’une des revendications 6 à 9, dans lequel le deuxième dispositif (WB) génère (S111, S113) sa clé publique éphémère (PkeB) à partir du nombre entier (w). Procédé selon l’une des revendications 1 à 10, dans lequel l’étape (S40) consistant à fournir aux dispositifs un code de processus (PCD) est mise en œuvre selon l’une des deux méthodes suivantes : - le premier dispositif (WA, RGEN) génère une donnée aléatoire formant le code de processus (PCD) qui est ensuite fourni au deuxième dispositif (WB), ou - le deuxième dispositif (WB, RGEN) génère une donnée aléatoire formant le code de processus (PCD) qui est ensuite fourni au premier dispositif (WA) par l’intermédiaire d’un clavier. Procédé selon l’une des revendications 1 à 11, dans lequel le premier dispositif (WA) et le deuxième dispositif (WB) ne communiquent pas directement et sont reliés à un dispositif hôte (HD), le procédé comprenant les étapes consistant à, au moyen du dispositif hôte : - envoyer séquentiellement des commandes à l’un ou l’autre des dispositifs, - recevoir des données de chaque dispositif en réponse à des commandes, et - transférer à chaque dispositif des données reçues de l’autre dispositif en réponse à des commandes. Procédé selon la revendication 12, comprenant les étapes consistant à : - déconnecter le deuxième dispositif (WB) du dispositif hôte et connecter le premier dispositif (WA) au dispositif hôte, pour permettre au dispositif hôte d’échanger des données avec le premier dispositif (WA), et - déconnecter le premier dispositif (WA) du dispositif hôte et connecter le deuxième dispositif (WB) au dispositif hôte, pour permettre au dispositif hôte d’échanger des données avec le deuxième dispositif (WB). Procédé selon l’une des revendications 1 à 13, dans lequel le premier dispositif (WA) et le deuxième dispositif (WB) sont des portefeuilles matériels de cryptoactifs. Procédé selon l’une des revendications 1 à 14, dans lequel la donnée secrète est une phrase (RPH) de récupération de comptes de cryptoactifs. Dispositif électronique portatif (WA) comprenant un processeur sécurisé (SP) comportant des moyens de calcul cryptographique, une mémoire sécurisée (SMEM), des moyens de communication (CINT), la mémoire sécurisée comprenant une clé privée (SkA), une clé publique (PkA), une clé publique (PkI) d’une autorité de certification (ICA), un certificat (CIA) signé par l’autorité de certification, le certificat comprenant la clé publique (PkA) du dispositif et la signature (SIGN(SkI, PkA)) de la clé publique du dispositif par l’autorité de certification, caractérisé en ce qu’il comprend un programme (TAP1, TAP2) lui permettant de transmettre à un dispositif externe (WB) une donnée secrète (RPH) que le dispositif détient dans la mémoire sécurisée, et en ce qu’il est configuré pour : - recevoir ou générer (S40) un code de processus aléatoire (PCD) et le mémoriser, - générer (S123) un nombre entier (w) qui est fonction du code de processus (PCD), - définir une première clé de chiffrement symétrique comme étant égale au nombre entier (w) ou la générer à partir du nombre entier (w), - recevoir (S107, S121, S221) un certificat externe (CIB) sous une forme chiffrée (ENC(w, CIB)) au moyen de la première clé de chiffrement symétrique (w), - déchiffrer (S125) le certificat externe (CIB) avec la première clé de chiffrement symétrique (w), - au moyen de la clé publique (PkI) de l’autorité de certification, vérifier (S127) l’authenticité du certificat externe, pour s’assurer qu’il est émis par un dispositif (WB) habilité par l’autorité de certification (ICA) à recevoir la donnée secrète, - recevoir (S117, S131, S217) une clé publique éphémère externe (PkeB), - générer (S139-S141) une clé publique éphémère interne (PkeA), - transmettre (S143, S163, S263) la clé publique éphémère interne (PkeA), - générer (S147-S149-S151, S347) une deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère externe (PkeB), - chiffrer (S157) la donnée secrète (RPH) avec la deuxième clé de chiffrement symétrique (Ke), et - transmettre (S159, S169, S269) la donnée secrète (RPH) sous sa forme chiffrée (ENC(Ke, RPH) avec la deuxième clé de chiffrement symétrique (Ke). Dispositif selon la revendication 16, configuré pour - recevoir (S117, S131, S217) une signature (SIGN(SkB, PkeB)) de la clé publique éphémère externe (PkeB), - vérifier (S133) l’authenticité de la clé publique éphémère externe (PkeB) au moyen de la clé publique externe (PkB) présente dans le certificat externe (CIB), pour s’assurer qu’un dispositif qui a émis la clé publique éphémère externe est le même qu’un dispositif qui a émis le certificat externe. Dispositif selon l’une des revendications 16 et 17, configuré pour générer (S147-S149-S151) la deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère externe (PkeB) et de la clé publique éphémère interne (PkeA). Dispositif selon l’une des revendications 16 à 18, configuré pour générer (S347) la deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère externe (PkeB) et d’une clé privée éphémère interne (SkeA). Dispositif selon l’une des revendications 16 à 19, configuré pour générer (S139-S141) la clé publique éphémère interne (PkeA) à partir du nombre entier (w). Dispositif selon l’une des revendications 16 à 20, configuré pour générer (S40) le code de processus aléatoire (PCD) et l’afficher sur un moyen d’affichage (DSP). Dispositif selon l’une des revendications 16 à 21, formant un portefeuille matériel de cryptoactifs. Dispositif selon l’une des revendications 16 à 22, dans lequel la donnée secrète est une phrase de récupération (RPH) de comptes de cryptoactifs. Dispositif électronique portatif (WB) comprenant un processeur sécurisé (SP) comportant des moyens de calcul cryptographique, une mémoire sécurisée (SMEM), des moyens de communication (CINT), la mémoire sécurisée comprenant une clé privée (SkB), une clé publique (PkB), une clé publique (PkI) d’une autorité de certification (ICA), un certificat (CIB) signé par l’autorité de certification, le certificat comprenant la clé publique (PkB) du dispositif et la signature (SIGN(SkI, PkB)) de la clé publique du dispositif par l’autorité de certification, caractérisé en ce qu’il comprend un programme (TAP1, TAP2) lui permettant de recevoir une donnée secrète externe (RPH), le dispositif étant configuré pour : - recevoir ou générer (S40) un code de processus aléatoire (PCD) et le mémoriser, - générer (S103) un nombre entier (w) qui est fonction du code de processus (PCD), - définir une première clé de chiffrement symétrique comme étant égale au nombre entier (w) ou la générer à partir du nombre entier (w), - chiffrer (S105) le certificat (CIB) avec la première clé de chiffrement symétrique (w), - transmettre (S107, S207) le certificat (CIB) sous sa forme chiffrée (ENC(w, CIB)), - générer (S111, S113) une clé publique éphémère interne (PkeB), - transmettre (S117, S131, S217) la clé publique éphémère interne (PkeB), - recevoir (S143, S163, S263) une clé publique éphémère externe (PkeA), - générer (S171, S173, S365) une deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère externe (PkeA), - recevoir (S159, S169, S269) la donnée secrète externe (RPH) sous une forme chiffrée (ENC(Ke, RPH) avec la deuxième clé de chiffrement symétrique (Ke), et - déchiffrer (S179) la donnée secrète (RPH) avec la deuxième clé de chiffrement symétrique (Ke) et stocker la donnée secrète dans la mémoire sécurisé (SMEM). Dispositif selon la revendication 24, configuré pour signer (S115) la clé publique éphémère interne (PkeB) au moyen de la clé privée (SkB), et transmettre (S117, S131, S217) la signature de la clé publique éphémère (PkeB). Dispositif selon l’une des revendications 24 et 25, configuré pour générer (S171, S173) la deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère externe (PkeA) et de la clé publique éphémère interne (PkeB). Dispositif selon l’une des revendications 24 et 25, configuré pour générer (S365) la deuxième clé de chiffrement symétrique (Ke) à partir de la clé publique éphémère externe (PkeA) et d’une clé privée éphémère interne (SkeB). Dispositif selon l’une des revendications 24 à 27, configuré pour générer (S111, S113) la clé publique éphémère interne (PkeB) à partir du nombre entier (w). Dispositif selon l’une des revendications 24 à 28, configuré pour générer (S40) le code de processus aléatoire (PCD) et l’afficher sur un moyen d’affichage (DSP). Dispositif selon l’une des revendications 24 à 29, formant un portefeuille matériel de cryptoactifs. Dispositif selon l’une des revendications 24 à 30, dans lequel la donnée secrète est une phrase de récupération (RPH) de comptes de cryptoactifs.