UNE CHAINE DE BLOCS

DESCRIPTION

DOMAINE TECHNIQUE

La présente invention concerne de manière générale les chaînes de blocs et plus particulièrement les dispositifs de stockage de clés cryptographiques permettant à un utilisateur de s'authentifier et de signer des transactions sur une chaîne de blocs.

ÉTAT DE LA TECHNIQUE ANTÉRIEURE

Les chaînes de blocs, au premier rang desquelles Bitcoin et Ethereum, ont pris un essor considérable ces dernières années.

On rappelle qu'une chaîne de blocs se compose d'une séquence de blocs chaînés par un mécanisme cryptographique à intervalles de temps réguliers. Le chaînage est obtenu en insérant le hash du bloc précédent dans le contenu du bloc courant. La chaîne de blocs forme un registre qui est distribué et répliqué à tous les nœuds du réseau.

Les utilisateurs peuvent interagir avec la chaîne de blocs au moyen de clients légers pour effectuer c'est-à-dire pour former et signer des transactions qui, si elles sont validées, sont stockées dans un bloc de la chaîne de blocs. Un exemple d'une telle transaction est le transfert d'un montant en cryptomonnaie à un tiers. Ces transactions sont vérifiées puis validées par un mécanisme de consensus entre des nœuds, appelés mineurs, disposant d'une copie complète de la chaîne, et entrant en compétition pour construire des blocs selon le mécanisme cryptographique précité. Chaque transaction validée est stockée dans un bloc qui est diffusé à l'ensemble des nœuds du réseau.

La réalisation d'opérations financières, et de manière générale de transactions via une chaîne de blocs, nécessite de disposer d'une adresse de portefeuille sur cette chaîne (adresse bitcoin par exemple). Une telle adresse est généralement obtenue par hachage de la clé publique d'un couple de clés asymétriques (clé privée - clé publique). Plus précisément, un utilisateur génère d'abord une clé privée qu'il devra tenir confidentielle et en déduit au moyen d'un chiffrement par un cryptosystème asymétrique, en l'occurrence un cryptosystème sur courbe elliptique ou ECC (Elliptic Curve Cryptogrpahy), la clé publique correspondante. Cette clé publique est ensuite hachée par une fonction de hachage (Keccak, SHA-3 par exemple) pour fournir l'adresse de portefeuille en question.

De manière schématique, une adresse de portefeuille sur une chaîne de blocs peut être considérée comme un numéro de compte bancaire et la clé privée comme un mot de passe permettant de valider l'accès à ce compte.

Dans un chaîne de blocs telle que Bitcoin, une transaction représente généralement un transfert d'un montant libellé en cryptomonnaie (satoshis ou bitcoins) d'une ou plusieurs adresses de portefeuille d'un émetteur vers une ou plusieurs adresses de portefeuilles de bénéficiaires. Plus précisément, transaction consomme un ou plusieurs UTXO (Unspent Transaction Output), chaque UTXO représentant un montant non dépensé par son destinataire et étant verrouillé à l'adresse de portefeuille de ce dernier par un script de verrouillage. Pour pouvoir dépenser un UTXO, le propriétaire doit s'identifier en présentant à l'UTXO des éléments cryptographiques (généralement sa clé publique et une signature générée à partir de la clé privée correspondante) sous la forme d'un script de déverrouillage. Si les éléments présentés dans le script de déverrouillage satisfont aux conditions spécifiées dans le script de verrouillage, la transaction est considérée comme validée.

La Fig. 1 illustre de manière schématique l'exemple d'un transfert d'un montant en cryptomonnaie entre deux utilisateurs d'une chaîne de blocs, Alice et Bob.

Alice forme une transaction depuis son portefeuille dont l'adresse, @wa Net Alice, est liée à une clé publique cryptographique (plus précisément, @wa Net Alice est le haché de sa clé publique).

On suppose que la transaction ne consomme qu'un seul UTXO du portefeuille d'Alice (de valeur fund ), dit UTXO d'entrée. La transaction crée un UTXO, dit premier UTXO de sortie dans le portefeuille de Bob avec le montant du paiement envisagé (de valeur amount ). De même, la transaction crée un second UTXO de sortie dans le portefeuille d'Alice avec le solde (de valeur balance = fund - amount ).

Pour effectuer le paiement (de la valeur amount ), Alice forme une transaction, T _a , composée d'un segment d'entrée et un segment de sortie.

Le segment d'entrée de T _a (dénommé scriptSig dans Bitcoin) est un script chargé de déverrouiller le script de verrouillage (dénommé scriptPubKey dans Bitcoin) figurant dans le segment de sortie de la transaction, T^, ayant créé l'UTXO d'entrée.

Le segment de sortie de T _a comprend :

- un premier script de verrouillage (scriptPubKey) qui verrouille la valeur amount à l'adresse de portefeuille de Bob, @walletBob, verrou que Bob ne pourra déverrouiller qu'en présentant un script de déverrouillage (scriptSig) contenant une signature l'authentifiant ;

- un second script de verrouillage (scriptPubKey) qui verrouille la valeur balance , associée à l'adresse de portefeuille d'Alice, @walletAlice, verrou qu'Alice ne pourra déverrouiller qu'en présentant un script de déverrouillage (scriptSig) contenant une signature l'authentifiant ;

Le script de déverrouillage, figurant dans le segment d'entrée de T _a , est concaténé au script de verrouillage correspondant, figurant dans le segment de sortie de T _{j M} et le script résultant est exécuté.

L'exécution du script résultant permet de vérifier que les éléments cryptographiques fournis par Alice sont bien légitimes, c'est-à-dire que l'adresse de portefeuille @wa Net Alice correspond bien à la clé publique d'Alice (vérification par hachage) et qu'Alice est bien la détentrice de cette clé publique (vérification au moyen de la signature).

Si la vérification est positive, la transaction est validée et stockée dans un nouveau bloc de la chaîne de blocs et ce bloc est miné. La validation et le stockage de la transaction matérialise de facto la création du premier UTXO de sortie vers le portefeuille de Bob et du second UTXO de sortie dans le portefeuille d'Alice.

Bob pourra alors à son tour dépenser le montant amount en utilisant comme UTXO d'entrée le premier UTXO de sortie précédemment crée. Pour ce faire, il devra le déverrouiller en présentant ses propres éléments cryptographiques (clé publique et signature).

On comprend que la seule détention d'une clé privée permet de réaliser des transactions sur la chaîne de blocs à partir de l'adresse de portefeuille correspondante. En d'autres termes, la clé privée constitue la seule preuve de propriété du portefeuille et sa perte interdira tout accès aux avoirs en cryptomonnaie (UTXOs) détenus dans ce portefeuille. De même, si sa clé secrète lui est dérobée par un tiers malveillant, l'utilisateur s'expose à ce que l'ensemble de ses avoirs soient dépensés par ce tiers.

Etant donné la criticité de la clé privée, il est généralement recommandé de la stocker généralement sous forme papier et non au format électronique dans la mémoire d'un smartphone ou d'un ordinateur. En outre, la longueur de la clé privée rend quasi- impossible sa mémorisation par l'utilisateur lui-même et, quand bien même réussirait-il à la mémoriser, il serait particulièrement fastidieux de la fournir à chaque transaction.

Le stockage sous forme papier n'est guère compatible avec une utilisation nomade. En outre, un utilisateur peut posséder une multiplicité de clés privées et autant d'adresses de portefeuille correspondantes.

Pour remédier à ce problème, il a été récemment commercialisé des portefeuilles physiques ( hardware wallets), essentiellement sous la forme de clés USB, dans lesquelles un utilisateur peut stocker ses clés privées ainsi que les clés publiques correspondantes ou les adresses de portefeuille (obtenues par hachage de ces dernières). Des exemples de tel portefeuille physique sont les dispositifs commercialisés sous le nom de Trezor™ ou de « Ledger Nano S ».

Ces clés USB sont généralement pourvues d'une interface simple (écran LCD et quelques boutons) permettant à son propriétaire de la déverrouiller au moyen d'un code PIN et de signer les transactions au moyen de la clé privée requise. Les clés secrètes sont stockées dans un élément sécurisé, à l'abri des attaques physiques, qui ne peut être accédé qu'au moyen du code PIN. Ces clés USB permettent de stocker différentes clés et de signer des transactions sur une chaîne de blocs sans recourir à un support papier. En revanche, elles ne sont pas totalement immunes contre des attaques physiques dans la mesure où les clés privées peuvent être déduites de signaux captés soit par radiation électromagnétique soit encore via l'interface USB.

Un objet de la présente invention est par conséquent de proposer un dispositif de stockage de clés numériques permettant à son propriétaire de s'authentifier et de signer des transactions sur une chaîne de blocs, dans des conditions de sécurité sensiblement accrues par rapport à celles de l'état de la technique.

EXPOSÉ DE L'INVENTION

La présente invention est définie par un dispositif de stockage de clés numériques pour signer des transactions sur une chaîne de blocs, ledit dispositif comprenant un microphone, un haut-parleur, un processeur DSP possédant un élément sécurisé destiné à stocker au moins une clé secrète, le DSP comprenant en outre un codeur/décodeur utilisant un dictionnaire, S, dont les mots de code, stockés dans une mémoire du DSP ou dans une mémoire sécurisée seulement accessible par le DSP, représentent des signaux ultrasonores aléatoires ou pseudo-aléatoires, le DSP ne communiquant avec l'extérieur du dispositif que par un canal acoustique, le DSP étant adapté à décoder un message constitué de mots de S, reçus d'un canal acoustique, via le microphone, à signer le message ainsi décodé au moyen de ladite clé privée et à transmettre en réponse une signature dudit message sous la forme d'une réponse constituée de mots successifs de S, sur ledit canal acoustique, via le haut-parleur.

Avantageusement, le dispositif comprend une interface HMI au moyen de laquelle un utilisateur peut saisir une clé privée ou une graine permettant de générer une succession de clés privées, ladite/lesdites clé(s) privée(s) étant stockée(s) dans l'élément sécurisé du processeur DSP. Le processeur DSP utilise typiquement un cryptosystème asymétrique sur courbe elliptique pour calculer une clé publique à partir de la clé privée saisie par l'utilisateur ou générée par le DSP à partir de ladite graine.

Qui plus est, le processeur DSP est adapté à calculer un haché de ladite clé publique au moyen d'une fonction de hachage afin d'obtenir une adresse de portefeuille sur une chaîne de blocs.

Le dispositif héberge avantageusement un module logiciel adapté à requérir du processeur DSP la transmission sur le canal acoustique de la clé publique et/ou de l'adresse de portefeuille sur le canal acoustique.

Selon un premier exemple de réalisation, le dispositif est un smartphone, le processeur DSP étant implémenté dans un chip distinct du microprocesseur sur lequel tourne le système d'exploitation du smartphone.

Selon un second exemple de réalisation, le dispositif est une clé USB ne comportant pas de broches de connexion autres que des broches d'alimentation.

La présente invention concerne en outre une méthode de paiement par un utilisateur à un tiers d'un montant en cryptomonnaie au moyen d'un dispositif de stockage de clés numériques comme défini ci-dessus et d'un terminal hébergeant un second module logiciel, ledit terminal étant connecté via Internet au réseau P2P mettant en œuvre la chaîne de blocs, caractérisé en ce que ledit utilisateur saisit dans une fenêtre affiché par le second module logiciel, le montant du paiement et l'adresse de portefeuille du tiers, et que le second module logiciel forme une transaction comportant un segment d'entrée et un segment de sortie, le segment d'entrée comprenant au moins une référence à une transaction antérieure dont l'utilisateur est destinataire, un script de verrouillage de la transaction antérieure, le segment de sortie comprenant ledit montant ainsi qu'un script de verrouillage dudit montant à l'adresse de portefeuille du tiers, le second module logiciel transmettant un premier message ( M ) comprenant la transaction ainsi formée au dispositif de stockage de clés numérique, et en cas de validation par l'utilisateur, le processeur DSP signe ledit message et renvoie la signature ainsi obtenue sous la forme d'un second message ( Sig ) audit terminal, les premier et second messages étant transmis sur le canal acoustique sous forme codée au moyen de mots de code du dictionnaire S, et le second module logiciel substituant dans ladite transaction le script de verrouillage de la transaction antérieure par un script de déverrouillage contenant la signature ainsi reçue et la clé publique de l'utilisateur.

La présente invention concerne enfin une méthode de paiement par un utilisateur à un tiers d'un montant en cryptomonnaie au moyen d'un dispositif de stockage de clés numériques comme défini ci-dessus, réalisé sous la forme d'un ordinateur ou d'un smartphone, le dispositif hébergeant un second module logiciel (225), et étant connecté via Internet au réseau P2P mettant en œuvre la chaîne de blocs, selon laquelle ledit utilisateur saisit dans une fenêtre affichée par le second module logiciel, le montant du paiement et l'adresse de portefeuille du tiers, et que le second module logiciel forme une transaction comportant un segment d'entrée et un segment de sortie, le segment d'entrée comprenant au moins une référence à une transaction antérieure

( Tfi _md ) dont l'utilisateur est destinataire, un script de verrouillage de la transaction antérieure, le segment de sortie comprenant ledit montant ainsi qu'un script de verrouillage dudit montant à l'adresse de portefeuille du tiers, le second module logiciel transmettant un premier message (M) comprenant la transaction ainsi formée au dispositif de stockage de clés numérique, et en cas de validation par l'utilisateur, le processeur DSP signe ledit message et renvoie la signature ainsi obtenue sous la forme d'un second message ( Sig ) au dispositif, les premier et second messages étant transmis sur le canal acoustique sous forme codée au moyen de mots de code du dictionnaire S, et le second module logiciel substituant dans ladite transaction le script de verrouillage de la transaction antérieure par un script de déverrouillage contenant la signature ainsi reçue et la clé publique de l'utilisateur.

Après substitution, la transaction { T _a ) est avantageusement diffusée aux nœuds du réseau P2P pour être validée et incorporée dans un prochain bloc de la chaîne de blocs. BRÈVE DESCRIPTION DES DESSINS

D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture d'un mode de réalisation préférentiel de l'invention, fait en référence aux figures jointes parmi lesquelles :

La Fig. 1, déjà décrite, représente de manière schématique le transfert d'un montant en cryptomonnaie entre deux utilisateurs d'une chaîne de blocs ;

La Fig. 2 représente de manière schématique un système utilisant un dispositif de stockage de clés numériques selon un mode de réalisation de l'invention ;

La Fig. 3A représente de manière schématique un premier exemple d'architecture du dispositif de stockage de clés du système de la Fig. 2 ;

La Fig. 3B représente de manière schématique un premier exemple d'architecture du dispositif de stockage de clés du système de la Fig. 2 ;

La Fig. 4A représente un chronogramme d'une opération de consultation de portefeuille au moyen du système de la Fig. 2 ;

La Fig. 4B représente un chronogramme d'une opération de paiement au moyen du système de la Fig. 2 ;

La Fig. 5A représente de manière schématique un dispositif de stockage de clés numériques selon une première variante d'implémentation de l'invention ;

La Fig. 5B représente de manière schématique un dispositif de stockage de clés numériques selon une seconde variante d'implémentation de l'invention.

EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS

L'idée de base de la présente invention est de prévoir un dispositif (ou portefeuille physique) de stockage de clés numériques comprenant un haut-parleur, un microphone et un processeur de signal numérique DSP (Digital Signal Processor) avec un élément sécurisé dans lequel sont stockés les couples de clés secrètes et de clés publiques, le DSP ne communiquant avec l'extérieur du dispositif physique que par signaux ultrasonores aléatoires (ou pseudo-aléatoires) via ledit microphone et ledit haut- parleur. A cette fin, le DSP comprend un module de codage/décodage acoustique utilisant un dictionnaire de codage (codebook) S, dont les mots de code représentent des signaux ultrasonores aléatoires ou pseudo-aléatoires stockés dans la mémoire du DSP ou dans une mémoire sécurisée du dispositif à laquelle seul le DSP a accès. Autrement dit, un mot de code est une représentation numérique d'un tel signal ultrasonore aléatoire ou pseudo-aléatoire, ce signal étant généré en convertissant le mot de code un signal analogique, en amplifiant ce signal analogique le cas échéant avant d'attaquer un transducteur.

Le dispositif est adapté à émettre vers et à recevoir d'une application de portefeuille (wallet application) des données cryptographiques, sous forme de mots dudit dictionnaire, via un canal acoustique entre ledit dispositif et le terminal hébergeant l'application de portefeuille.

Ainsi, les données cryptographiques ne sont pas transmises via une interface USB ou Bluetooth comme dans l'art antérieur, avec les risques inhérents d'interception (eavesdropping) ou d'attaques physiques. L'utilisation de signaux ultrasonores à faible portée rend ces tentatives d'intrusion inopérantes. En outre, la transmission de données cryptographiques au moyen de signaux ultrasonores aléatoires ou pseudo-aléatoires augmente sensiblement la robustesse du canal à de telles attaques.

La Fig. 2 représente de manière schématique un système comprenant un dispositif de stockage de clés numériques selon un mode de réalisation de l'invention.

Le dispositif (ou portefeuille physique) de stockage de clés numériques a été représenté en 210 avec le DSP en 219, le microphone en 213 et le haut-parleur en 217.

Le dispositif peut être implémenté sous forme de smartphone comme illustré sur la figure, ou sous forme d'une clé USB spécifique pourvue d'une interface HMI simple (écran LCD et boutons par exemple), voire sous forme de jeton d'authentification (boîtier électronique spécifique), voire encore sous la forme d'un ordinateur portable. Dans ce cas, le DSP 219 pourra être celui déjà présent par construction dans l'ordinateur portable.

Il est important de noter que lorsque le portefeuille physique de stockage est implémenté sous la forme d'une clé USB spécifique, celle-ci ne comprend que des broches d'alimentation. Ainsi, la clé pourra être enfichée dans un connecteur USB d'un ordinateur et être ainsi alimentée sans que cet ordinateur puisse accéder aux données stockées dans le portefeuille physique.

Outre le portefeuille physique, le système 200 comprend un terminal (typiquement un ordinateur portable, PC), 220, relié à Internet et pouvant par conséquent communiquer avec d'autres nœuds du réseau P2P (Peer to Peer) mettant en œuvre la chaîne de blocs.

Dans la suite de la description, nous supposerons, sans perte de généralité, que la chaîne de blocs est Bitcoin.

Le terminal de l'utilisateur, 220, héberge une application de portefeuille ( wallet _ app ), 225, telle qu'un client léger SPV ( Simplifiée! Payment Vérification) conférant au terminal la fonction de nœud léger (lightweight node) et lui permettant de former et de vérifier des transactions sur la chaîne de blocs. Alternativement, dans le cas d'une utilisation non nomade, le terminal de l'utilisateur pourra héberger un client complet, lui permettant d'avoir accès à une copie de l'ensemble du registre partagé.

L'application de portefeuille 225 comprend également un module de décodage utilisant le dictionnaire S lui permettant de décoder les signaux aléatoires/pseudo aléatoires reçus du dispositif de stockage. Alternativement, le terminal pourra comprendre un DSP (non représenté) effectuant un tel décodage sur requête de l'application et retournant à celle-ci les messages ainsi décodés. Alternativement encore, le terminal pourra transmettre les signaux aléatoires/pseudo-aléatoires qu'il aura reçus à un serveur de décodage dans le Cloud qui lui renverra alors les messages décodés. Ce dernier exemple de réalisation est avantageux dans la mesure où l'on pourra commuter le dictionnaire S de manière adaptative dans le serveur de décodage et le dispositif de stockage.

Le dispositif de stockage de clés numériques, 210, comprend un module logiciel, 215, dit module de contrôle de portefeuille ( walletctrl _ app ), ayant essentiellement pour fonction de générer une (ou des) paire(s) (clé privée, publique) et de signer des messages à l'aide de la clé privée ainsi générée, par exemple des transactions formées par l'application de portefeuille. Dans une première phase, le portefeuille physique de stockage de clés numériques est initialisé.

Tout d'abord, le portefeuille physique pourra être protégé à l'aide d'un mot de passe (code PIN), un lecteur d'empreintes digitales, un capteur d'iris ou tout autre capteur d'authentification biométrique. La saisie de mot de passe ou la saisie biométrique a simplement pour objet de protéger l'accès au portefeuille physique.

Dans le cas où un mot de passe est utilisé pour l'authentification, celui pourra être saisi au moyen de l'interface HMI (écran tactile par exemple) et validé par exemple en appuyant sur un bouton de validation ou en cliquant sur une icône de validation affichée à l'écran.

En outre, la phase d'initialisation comprend la génération d'au moins une paire de clés (clé privée, clé publique) par un cryptosystème sur courbe elliptique ou ECC, dont les paramètres de domaine ont été préalablement stockés dans le DSP. La clé privée pourra être obtenue par exemple à partir d'une séquence de mots saisis ou sélectionnés au moyen de l'interface HMI. De préférence, cette séquence est utilisée comme graine (seed) pour créer des générations successives de paires (clé privée - clé publique) d'un portefeuille hiérarchique déterministe (HD wallet ou Hierarchical Deterministic Wallet), selon les standards BIP0032 et BIP044. Dans tous les cas, les clés privées/clés publiques n'apparaissent pas explicitement sur l'interface HMI mais sont générées au sein du DSP, 219, et stockées localement, les clés privées étant stockées dans l'élément sécurisé précité.

Une fois la phase d'initialisation effectuée et l'application de portefeuille 225 lancée sur le terminal 220, il est possible de réaliser sur la chaîne de blocs des opérations à l'aide du portefeuille en question.

L'opération la plus simple est la consultation du portefeuille, c'est-à-dire l'obtention de la liste des UTXO dont l'utilisateur, ou plus précisément l'adresse de son portefeuille, est destinataire.

On rappelle que l'adresse de portefeuille est obtenue par un hachage de la clé publique de l'utilisateur. L'utilisateur peut bien entendu posséder plusieurs clés publiques et plusieurs adresses de portefeuille correspondantes. Dans ce cas, les UTXO à destination de chacune de ces adresses pourront être stockés dans un répertoire distinct dans l'application wallet _ app .

Si le portefeuille physique n'a stocké qu'une paire (clé privée, clé publique), l'utilisateur peut demander, via l'interface HMI du portefeuille physique, de transmettre la clé publique, voire l'adresse de portefeuille correspondante, à l'application 225.

Si le portefeuille physique a stocké en mémoire une pluralité de clés publiques, l'utilisateur peut sélectionner via l'interface HMI la clé publique ou l'adresse de portefeuille souhaitée et demander sa transmission à l'application 225.

Dans les deux cas, le DSP transmet la clé publique/l'adresse de portefeuille au moyen de signaux ultrasonores aléatoires (ou pseudo-aléatoires) du dictionnaire S, sur le canal acoustique 250. Les mots de code de S (signaux ultrasonores aléatoires ou pseudo aléatoires) sont choisis de manière à ce que la matrice de corrélation de ces signaux, éventuellement filtrés par le filtre équivalent du canal acoustique, soit la plus proche possible d'une matrice diagonale. Autrement dit, les signaux ultrasonore aléatoires (ou pseudo-aléatoires) sont choisis de manière à ce que les valeurs des coefficients d'intercorrélation soient minimales et celles des coefficients d'autocorrélation soient maximales. La création d'un tel dictionnaire S est détaillée dans la demande française N° 16 55443 déposée le 13 juin 2016 dont le contenu est incorporé ici par référence.

Ces signaux sont émis par le haut-parleur (transducteur électro-acoustique par exemple piézo-électrique), 217, du dispositif physique 210 et reçus par un microphone (par exemple un transducteur piézo-électrique), 223, du terminal, pour être fournis à l'application de portefeuille 225, soit directement dans le cas où l'application de portefeuille se charge du décodage, soit après décodage par le DSP résidant dans le terminal, soit encore par décodage par un serveur de décodage comme indiqué plus haut.

Quelle que soit la variante de décodage, l'application de portefeuille peut ensuite lancer une requête sur la chaîne de blocs pour rechercher les transactions (par exemple au moyen d'un block chain browser tel que block explorer ou une API telle que blockchain.info) à destination de cette adresse. Si la clé publique est transmise au terminal, l'application de portefeuille peut déterminer par simple hachage l'adresse de portefeuille correspondante et lancer la requête comme précédemment. La chaîne est alors scannée pour rechercher les transactions à destination de cette adresse. Dans tous les cas, les transactions dont Alice est destinataire sont affichées dans une fenêtre de l'application 225.

La Fig. 3A représente un premier exemple d'architecture du dispositif de stockage de clés numériques dans le système de la Fig. 2.

Le système d'exploitation 212 (par exemple Androïd™) tourne sur le microprocesseur 211. De préférence, le système d'exploitation ne communique au DSP qu'à travers le microprocesseur de manière à renforcer la robustesse aux attaques.

Le microprocesseur reçoit du DSP des messages numériques sous forme de mots du dictionnaire S et les transfère au pilote du haut-parleur 217. Ces messages sont convertis en analogique, amplifiés et les signaux résultants sont transformés en signaux ultrasonores correspondants par le haut-parleur 217 pour être transmis sur le canal acoustique 250.

Réciproquement, le microprocesseur reçoit du microphone 213 des signaux ultrasonores, préalablement convertis sous forme numérique, et les transmet au DSP, 219.

On comprend ici que le microprocesseur joue un rôle transparent dans les échanges entre le DSP et l'extérieur du dispositif.

La Fig. 3B représente un second exemple d'architecture du dispositif de stockage de clés numériques dans le système de la Fig. 2.

Le DSP peut recevoir des messages de contrôle et, le cas échéant, retourner des messages de réponse au microprocesseur comme précédemment. En revanche, dans cet exemple, le DSP reçoit et transmet directement les signaux ultrasonores aléatoires/pseudo-aléatoires sans passer par l'intermédiaire du microprocesseur. Dans un exemple de réalisation particulier, le DSP, le haut-parleur et le microphone font partie d'une même carte son. La Fig. 4A récapitule de manière schématique les échanges au sein du système 200 lorsqu'Alice consulte son portefeuille. En 410, le portefeuille physique transmet la clé publique d'Alice pK _a ou l'adresse de portefeuille @ walletAlice , via le canal acoustique, à l'application wallet _ app du terminal.

Plus précisément, la clé publique pK _a est transmise sous la forme d'un signal ultrasonore aléatoire/pseudo-aléatoire s{rK _a ) où _s désigne l'opération de codage au moyen du dictionnaire S précité. Alternativement, l'adresse de portefeuille @ walletAlice sera transmise sous la forme d'un signal ultrasonore aléatoire/pseudo aléatoire <t( @ walletAlice) .

Après décodage de ce signal, l'application transmet une requête en 420 pour scanner dans la chaîne de blocs les transactions dont @ walletAlice est destinataire. Après avoir récupéré ces transactions en 430, Alice peut lister les UTXO à son adresse (transactions dont @ walletAlice est destinataire dont la sortie est non dépensée) pour les agréger éventuellement.

L'UTXO, voire les UTXO agrégés dans le cas d'une agrégation, pourra(ont) ainsi être utilisé(s) comme entrée(s) d'une nouvelle transaction pour effectuer un paiement.

A l'inverse, l'adresse @ walletAlice pourra être communiquée sous la forme codée <j( @ walletAlice) via un canal acoustique à un tiers disposant d'un terminal 220 comme celui précédemment décrit, de manière à ce qu'il puisse effectuer un paiement à destination de l'adresse de portefeuille d'Alice.

Ainsi, si Alice souhaite effectuer un paiement à Bob, elle ouvre son application de portefeuille, 225, sur le terminal 220 et remplit les paramètres nécessaires à la transaction.

Elle sélectionne dans son portefeuille l'UTXO (voire les UTXO en cas d'agrégation) qu'elle souhaite utiliser pour le transfert, le montant à transférer et l'adresse de portefeuille du bénéficiaire, @walletBob. Sans perte de généralité, on suppose dans la suite qu'un seul UTXO est sélectionné. Cet UTXO est la sortie d'une transaction source

Tr, _M , autrement dit la transaction T a créé cet UTXO. L'application de portefeuille forme alors une nouvelle transaction, T _a par exemple au moyen d'un script P2PKH (Pay to Public Key Hash).

Dans le segment d'entrée de T _a l'application fournit d'abord la référence de l'UTXO sélectionné, c'est-à-dire le haché de la transaction source, 7^, soit h(T _j ^) . Dans le segment de sortie de T _a l'application fournit ensuite le montant à transférer et un script de verrouillage verrouillant ce montant à l'adresse de portefeuille @walletBob.

L'application 225 doit ensuite fournir les éléments cryptographiques pour déverrouiller le script de verrouillage qui protège l'UTXO d'entrée de T _a (UTXO à destination de @walletAlice dans la transaction source 7^ ), à savoir sa clé publique et une signature au moyen de sa clé privée.

Pour ce faire, le logiciel de portefeuille 225 demande au portefeuille physique 210 de signer la transaction en lui transmettant un message, M, comprenant le haché de la transaction source, hÇT^), le script de verrouillage (scriptPubKey) de la transaction source 7^, le montant en cryptomonnaie et le script de verrouillage (scriptPubKey) verrouillant ledit montant à l'adresse de portefeuille @walletBob.

Le message M est transmis au DSP via le canal acoustique, sous la forme s(M ) obtenue par codage de M au moyen du dictionnaire S. Les signaux ultrasonores correspondants sont émis par le haut-parleur 227 du terminal et reçus par le microphone 213 du portefeuille physique 210.

Le DSP transmet, via le microprocesseur à l'application walletctrl _ app l'adresse du destinataire du paiement ainsi que le montant. L'application demande alors à l'utilisateur de confirmer la transaction (en appuyant sur une icône de l'écran tactile ou bouton). Si l'utilisateur la confirme avant l'expiration d'un time _ out , l'application walletctrl _ app en avertit le DSP qui signe alors le message M avec la clé privée (au moyen d'un algorithme de signature sur courbe elliptique ou ECDSA) et transmet la signature obtenue, Sig , au terminal 220. La signature Sig est transmise sous une forme codée, a(Sig) , au moyen des signaux du dictionnaire S, via le canal acoustique

Là encore, le signal a(Sig) peut être décodé par l'application de portefeuille, le DSP local ou un serveur de décodage distant. Après décodage, l'application de portefeuille 225 récupère la signature Sig et la concatène avec la clé publique d'Alice, pK _a pour former le script de déverrouillage (scriptSig). L'application wallet _ app fournit le haché de la transaction source, T^) et le script de déverrouillage pour former le segment d'entrée de la transaction T _a .

L'application de portefeuille invite alors l'utilisateur à confirmer le paiement (par exemple en cliquant sur une icône). Si le paiement est confirmé, la transaction T _a est diffusée aux nœuds du réseau P2P pour être validée et incorporée dans un prochain bloc de la chaîne.

La Fig. 4B récapitule de manière schématique les échanges au sein du système 200 lorsqu'Alice effectue un paiement.

A l'étape 450, après que l'utilisateur ait saisi le montant du paiement et l'adresse de portefeuille du bénéficiaire dans une fenêtre de l'application de portefeuille, cette dernière construit un message, M, à partir du haché de la transaction source, hÇT^), du script de verrouillage de la transaction source, du montant du paiement en cryptomonnaie, ainsi que d'un script de verrouillage verrouillant le montant à l'adresse de portefeuille du bénéficiaire, @walletBob.

Le signal s (M ) obtenu par codage de M (au moyen du dictionnaire S) est transmis sur le canal acoustique au moyen des signaux ultrasonores aléatoires du dictionnaire S.

Après décodage de s (M ) et récupération du message M par le DSP, celui-ci transmet en 451 l'adresse de portefeuille du bénéficiaire ainsi que le montant à l'application de contrôle walletctrl _ app . La validation par l'utilisateur est transmise par walletctrl _ app au DSP en 452. Le DSP signe alors le message M à l'aide de sa clé privée (EDCSA), code la signature obtenue avec le dictionnaire S pour obtenir un signal a(Sig) et transmet ce dernier au terminal 220, comme précédemment, via le canal acoustique.

Le signal a(Sig) est décodé au niveau du terminal 220 pour fournir la signature

Sig .

L'application de portefeuille wallet _ app construit alors en 370 le script de déverrouillage à partir de la signature ainsi reçue et de la clé publique d'Alice pour former le segment d'entrée de la transaction. De même, elle concatène le script de verrouillage au montant pour former le segment de sortie de la transaction.

Une fois le paiement validé par l'utilisateur sur la fenêtre de l'application de portefeuille, celle-ci la diffuse en 480 aux autres nœuds du réseau P2P.

Dans la description ci-dessus, nous avons supposé que la chaîne de blocs était Bitcoin. Alternativement, elle peut être une chaîne blocs dans laquelle il est possible d'enregistrer et d'exécuter des contrats intelligents (smart contracts). Un exemple d'une telle chaîne de blocs est Ethereum. On rappelle qu'un contrat intelligent est un programme qui peut être exécuté par n'importe quel nœud du réseau P2P mettant en œuvre la chaîne de blocs. Il peut notamment stocker des données, envoyer et recevoir des paiements, exécuter des actions de manière autonome et décentralisée comme un agent logiciel. Généralement, un contrat intelligent vérifie si un certain nombre de conditions sont remplies et, dans l'affirmative, s'exécute automatiquement pour fournir un résultat codé dans le contrat.

Le portefeuille physique de clés numériques permet de la même façon de s'authentifier comme une partie à un contrat intelligent et, par exemple, de donner son consentement. Pour ce faire, l'application de portefeuille (ou de compte selon la terminologie Ethereum) pourra former une transaction et le propriétaire pourra la signer au moyen du portefeuille physique, la transaction ainsi signée étant transmise au contrat intelligent stocké dans la chaîne de blocs. Enfin, dans la description précédente on a supposé que le terminal 220 était distinct du dispositif de stockage de clés numériques 210. Si ce dernier est un smartphone, celui-ci peut également faire office de terminal connecté à Internet : le terminal est alors confondu avec le dispositif et les premier et second modules de logiciel sont des modules d'une même application (voire d'applications distinctes) du smartphone comme représenté dans l'exemple de réalisation de la Fig. 5A. Ils dialoguent alors via un canal acoustique local entre le haut-parleur 217 et le microphone 213.

Inversement, le terminal peut incorporer le DSP 219 avec son élément sécurisé, les premier et second modules de logiciel faisant partie d'une même application (voire d'applications distinctes) du terminal, comme représenté dans l'exemple de réalisation de la Fig. 5B. Ces modules de logiciels dialoguent alors via un canal acoustique local entre le haut-parleur 217 et le microphone 213, comme dans le premier exemple d'implémentation.

Nous avons également supposé dans la description que le dispositif de stockage de clés/le terminal disposait du même dictionnaire de codage S pour l'émission et la réception de messages. Alternativement, on pourra utiliser deux dictionnaires de codage distincts, S et 5" pour l'émission et la réception, le dictionnaire en émission de l'un étant le dictionnaire et réception de l'autre et réciproquement. Ce mode de réalisation est avantageux dans la mesure où il autorise un échange full-duplex sur le canal acoustique.