FR3075534A1 - Dispositif de stockage de cles numeriques pour signer des transactions sur une chaine de blocs - Google Patents

Dispositif de stockage de cles numeriques pour signer des transactions sur une chaine de blocs Download PDF

Info

Publication number
FR3075534A1
FR3075534A1 FR1762129A FR1762129A FR3075534A1 FR 3075534 A1 FR3075534 A1 FR 3075534A1 FR 1762129 A FR1762129 A FR 1762129A FR 1762129 A FR1762129 A FR 1762129A FR 3075534 A1 FR3075534 A1 FR 3075534A1
Authority
FR
France
Prior art keywords
dsp
transaction
user
message
software module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1762129A
Other languages
English (en)
Other versions
FR3075534B1 (fr
Inventor
Emmanuel Ruiz
Carlos David Piloto Fonseca
Ruben Alfonso Reyes
Brian Roeten
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Copsonic SAS
Original Assignee
Copsonic SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR1762129A priority Critical patent/FR3075534B1/fr
Application filed by Copsonic SAS filed Critical Copsonic SAS
Priority to US16/771,754 priority patent/US20210073795A1/en
Priority to EP18833920.4A priority patent/EP3707857A1/fr
Priority to CN201880087464.7A priority patent/CN111656732A/zh
Priority to PCT/FR2018/053211 priority patent/WO2019115936A1/fr
Priority to KR1020207020393A priority patent/KR20200116455A/ko
Priority to JP2020532556A priority patent/JP2021507586A/ja
Priority to AU2018382778A priority patent/AU2018382778A1/en
Publication of FR3075534A1 publication Critical patent/FR3075534A1/fr
Application granted granted Critical
Publication of FR3075534B1 publication Critical patent/FR3075534B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B11/00—Transmission systems employing sonic, ultrasonic or infrasonic waves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Algebra (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computing Systems (AREA)
  • Power Engineering (AREA)
  • Mathematical Physics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention concerne un dispositif physique destiné à stocker des clés numériques pour effectuer des transactions sur une chaine de blocs. Le dispositif physique (200) comprend un microphone (213), un haut-parleur (215), un processeur DSP (219) possédant un élément sécurisé dans lequel sont stockés les couples de clés secrètes et de clés publiques, le DSP comprenant en outre un codec acoustique utilisant un dictionnaire, S, dont les mots représentent des signaux ultrasonores aléatoires ou pseudo-aléatoires stockés dans la mémoire du DSP. Le DSP (219) est adapté à décoder un message constitué de mots de S, reçus d'un canal acoustique via le microphone (213), à signer le message ainsi décodé au moyen d'une clé privée et à transmettre la signature ainsi obtenue sous forme d'une réponse constituée de mots successifs de S, sur ledit canal acoustique (250), via le haut-parleur (217).

Description

DISPOSITIF DE STOCKAGE DE CLÉS NUMÉRIQUES POUR SIGNER DES TRANSACTIONS SUR 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, @walletAlice, est liée à une clé publique cryptographique (plus précisément, @walletAlice 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, Ta, composée d'un segment d'entrée et un segment de sortie.
Le segment d'entrée de Ta (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, 7^, ayant créé l'UTXO d'entrée.
Le segment de sortie de Ta 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 Ta, est concaténé au script de verrouillage correspondant, figurant dans le segment de sortie de 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 @walletAlice 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 quasiimpossible 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 (7^) 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 ( 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 (Ta ) 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 hautparleur.
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 (Simplified 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/pseudoalé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 BIPOO32 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 pseudoalé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 pKa ou l'adresse de portefeuille @ walletAlice, via le canal acoustique, à l'application wallet _app du terminal.
Plus précisément, la clé publique pKa est transmise sous la forme d'un signal ultrasonore aléatoire/pseudo-aléatoire σ(ρΚα) où σ 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/pseudoaléatoire cr(@ 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 cr(@ 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 T^, autrement dit la transaction TJiiiid a créé cet UTXO.
L'application de portefeuille forme alors une nouvelle transaction, Tat par exemple au moyen d'un script P2PKH (Pay to Public Key Hash).
Dans le segment d'entrée de Tat 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
Dans le segment de sortie de Tat 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 Ta (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, 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 σ(Μ ) 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, pKat pour former le script de déverrouillage (scriptSig). L'application wallet _ app fournit le haché de la transaction source, KT/m) et le script de déverrouillage pour former le segment d'entrée de la transaction Ta .
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 Ta 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, 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 σ(Μ) obtenu par codage de M (au moyen du dictionnaire 5) est transmis sur le canal acoustique au moyen des signaux ultrasonores aléatoires du dictionnaire S.
Après décodage de σ(Μ) 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 S' 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.

Claims (10)

  1. REVENDICATIONS
    1. Dispositif de stockage de clés numériques pour signer des transactions sur une chaîne de blocs, caractérisé en ce qu'il comprend un microphone (213), un hautparleur (217), un processeur DSP (219) 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 (250), le DSP étant adapté à décoder un message constitué de mots de S, reçus d'un canal acoustique, via le microphone (213), à 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 (217).
  2. 2. Dispositif de stockage de clés numériques selon la revendication 1, caractérisé en ce que ledit 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.
  3. 3. Dispositif de stockage de clés numériques selon la revendication 2, caractérisé en ce que le processeur DSP utilise 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.
  4. 4. Dispositif de stockage de clés numériques, selon la revendication 3, caractérisé en ce que 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.
  5. 5. Dispositif de stockage de clés numériques, selon la revendication 4, caractérisé en ce que le dispositif héberge un module logiciel (215) 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.
  6. 6. Dispositif de stockage de clés numériques selon l'une des revendications précédentes caractérisé en ce qu'il est réalisé sous forme de smartphone, le processeur DSP étant implémenté dans un chip distinct du microprocesseur sur lequel tourne le système d'exploitation du smartphone.
  7. 7. Dispositif de stockage de clés numériques selon l'une des revendications 1 à 5, caractérisé en ce qu'il est réalisé sous forme d'une clé USB ne comportant pas de broches de connexion autres que des broches d'alimentation.
  8. 8. 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 selon l'une des revendications précédentes et d'un terminal (220) hébergeant un second module logiciel (225), ledit terminal étant connecté via Internet au réseau P2P mettant en œuvre la chaîne de blocs, caractérisée 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 (7^) 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 (450) 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 (452), le processeur DSP signe ledit message et renvoie (460) 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.
  9. 9. 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 selon l'une des revendications 1 à 5, 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, caractérisée en ce que 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 (7^) 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 (450) 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 (452), le processeur DSP signe ledit message et renvoie (460) 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 (250) 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.
  10. 10. Méthode de paiement selon la revendication 8 ou 9, caractérisée en ce que, après substitution, la transaction (T) est diffusée (480) aux nœuds du réseau P2P pour être validée et incorporée dans un prochain bloc de la chaîne de blocs.
FR1762129A 2017-12-14 2017-12-14 Dispositif de stockage de cles numeriques pour signer des transactions sur une chaine de blocs Expired - Fee Related FR3075534B1 (fr)

Priority Applications (8)

Application Number Priority Date Filing Date Title
FR1762129A FR3075534B1 (fr) 2017-12-14 2017-12-14 Dispositif de stockage de cles numeriques pour signer des transactions sur une chaine de blocs
EP18833920.4A EP3707857A1 (fr) 2017-12-14 2018-12-12 Dispositif de stockage de clés numériques pour signer des transactions sur une chaine de blocs
CN201880087464.7A CN111656732A (zh) 2017-12-14 2018-12-12 用于存储用于在区块链上对交易进行签名的数字钥匙的设备
PCT/FR2018/053211 WO2019115936A1 (fr) 2017-12-14 2018-12-12 Dispositif de stockage de clés numériques pour signer des transactions sur une chaine de blocs
US16/771,754 US20210073795A1 (en) 2017-12-14 2018-12-12 Device for storing digital keys for signing transactions on a blockchain
KR1020207020393A KR20200116455A (ko) 2017-12-14 2018-12-12 블록체인에 트랜잭션들을 서명하기 위한 디지털 키들을 저장하는 장치
JP2020532556A JP2021507586A (ja) 2017-12-14 2018-12-12 ブロックチェーン上でトランザクションに署名するためのデジタル鍵を格納するためのデバイス
AU2018382778A AU2018382778A1 (en) 2017-12-14 2018-12-12 Device for storing digital keys for signing transactions on a blockchain

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1762129 2017-12-14
FR1762129A FR3075534B1 (fr) 2017-12-14 2017-12-14 Dispositif de stockage de cles numeriques pour signer des transactions sur une chaine de blocs

Publications (2)

Publication Number Publication Date
FR3075534A1 true FR3075534A1 (fr) 2019-06-21
FR3075534B1 FR3075534B1 (fr) 2020-01-10

Family

ID=61802094

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1762129A Expired - Fee Related FR3075534B1 (fr) 2017-12-14 2017-12-14 Dispositif de stockage de cles numeriques pour signer des transactions sur une chaine de blocs

Country Status (8)

Country Link
US (1) US20210073795A1 (fr)
EP (1) EP3707857A1 (fr)
JP (1) JP2021507586A (fr)
KR (1) KR20200116455A (fr)
CN (1) CN111656732A (fr)
AU (1) AU2018382778A1 (fr)
FR (1) FR3075534B1 (fr)
WO (1) WO2019115936A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB201720946D0 (en) * 2017-12-15 2018-01-31 Nchain Holdings Ltd Computer-implemented system and method
EP3725028A1 (fr) 2017-12-13 2020-10-21 Nchain Holdings Limited Système et procédé pour partager en toute sécurité du matériel cryptographique
CN113874898A (zh) * 2019-02-15 2021-12-31 区块链控股有限公司 用于通过区块链网络实现转账的计算机实现的系统和方法
KR20210041404A (ko) * 2019-10-07 2021-04-15 삼성전자주식회사 전자 장치 및 그 전자 장치를 이용한 블록체인 주소 관리 방법
CN110889128A (zh) * 2019-11-27 2020-03-17 上海禾一网络科技有限公司 基于区块链存储与交换加密密钥的输入方法和装置
CN112468301B (zh) * 2020-10-23 2022-08-02 苏州浪潮智能科技有限公司 一种基于区块链的云平台认证的方法、系统、设备及介质
US20220417030A1 (en) * 2021-06-26 2022-12-29 Redpine Signals, Inc. Device Authentication using Blockchain
CN113315639A (zh) * 2021-07-05 2021-08-27 安徽中科晶格技术有限公司 身份认证系统及方法
US20230421363A1 (en) * 2022-06-28 2023-12-28 Fmr Llc Secure storage and transmission of a cryptocurrency encryption key

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009066212A1 (fr) * 2007-11-21 2009-05-28 Nxp B.V. Dispositif et procédé pour des communications en champ proche à l'aide de transducteurs audio
EP2966792A1 (fr) * 2015-06-17 2016-01-13 Nxp B.V. Système de communication à ultrasons

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7328350B2 (en) * 2001-03-29 2008-02-05 Arcot Systems, Inc. Method and apparatus for secure cryptographic key generation, certification and use
US20030217268A1 (en) * 2002-05-15 2003-11-20 Alexander Gantman System and method for using acoustic digital signature generator as oracle
US8879986B2 (en) * 2005-12-31 2014-11-04 Michelle Fisher Wireless bidirectional communications between a mobile device and associated secure element using inaudible sound waves
RU2409897C1 (ru) * 2009-05-18 2011-01-20 Самсунг Электроникс Ко., Лтд Кодер, передающее устройство, система передачи и способ кодирования информационных объектов
JP6120206B2 (ja) * 2012-10-11 2017-04-26 公立大学法人岩手県立大学 音響コードの符号化・復号化装置および音響コードの符号化・復号化方法
US20150324787A1 (en) * 2014-05-08 2015-11-12 Sequitur Labs, Inc. Policy-Based Control and Augmentation of Cryptocurrencies and Cryptocurrency Security
US20150365384A1 (en) * 2014-06-16 2015-12-17 Wul4 System and Methods for Transmitting Information Using Inaudible Acoustic Signals
US9916432B2 (en) * 2015-10-16 2018-03-13 Nokia Technologies Oy Storing and retrieving cryptographic keys from biometric data
KR101999188B1 (ko) * 2016-02-23 2019-07-11 엔체인 홀딩스 리미티드 비밀 공유를 위한 타원 곡선 암호를 사용하는 개인용 장치 보안
CN106779636B (zh) * 2016-11-29 2020-06-26 北京欧凯联创网络科技有限公司 一种基于手机耳机接口的区块链数字货币钱包
CN107392702A (zh) * 2017-07-10 2017-11-24 北京云知科技有限公司 一种基于声纹的商品推送方法及装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009066212A1 (fr) * 2007-11-21 2009-05-28 Nxp B.V. Dispositif et procédé pour des communications en champ proche à l'aide de transducteurs audio
EP2966792A1 (fr) * 2015-06-17 2016-01-13 Nxp B.V. Système de communication à ultrasons

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BAMERT TOBIAS ET AL: "BlueWallet: The Secure Bitcoin Wallet", 10 September 2014, MEDICAL IMAGE COMPUTING AND COMPUTER-ASSISTED INTERVENTION - MICCAI 2015 : 18TH INTERNATIONAL CONFERENCE, MUNICH, GERMANY, OCTOBER 5-9, 2015; PROCEEDINGS; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER INTERNATIONAL PUBLISHING, CH, ISBN: 978-3-642-38287-1, ISSN: 0302-9743, XP047298907 *
LEDGER: "Ledger Blue: an enterprise grade security device", 25 November 2016 (2016-11-25), XP055492588, Retrieved from the Internet <URL:https://blog.ledger.co/2016/11/25/ledger-blue-an-enterprise-grade-security-device/> [retrieved on 20180713] *
NEVENA LAZIC AND PURHAM AARABI: "Communication over an acoustic channel using data hiding techniques", IEEE TRANSACTIONS ON MULTIME, IEEE SERVICE CENTER, PISCATAWAY, NJ, US, vol. 8, no. 5, 1 October 2006 (2006-10-01), pages 918 - 924, XP009106139, ISSN: 1520-9210, DOI: 10.1109/TMM.2006.879880 *

Also Published As

Publication number Publication date
CN111656732A (zh) 2020-09-11
JP2021507586A (ja) 2021-02-22
US20210073795A1 (en) 2021-03-11
KR20200116455A (ko) 2020-10-12
EP3707857A1 (fr) 2020-09-16
WO2019115936A1 (fr) 2019-06-20
FR3075534B1 (fr) 2020-01-10
AU2018382778A1 (en) 2020-07-23

Similar Documents

Publication Publication Date Title
FR3075534A1 (fr) Dispositif de stockage de cles numeriques pour signer des transactions sur une chaine de blocs
US20190050554A1 (en) Logo image and advertising authentication
WO2018131004A9 (fr) Procedes et systemes pour l&#39;execution de contrats intelligents dans des environnements securises
EP2619941B1 (fr) Procede, serveur et systeme d&#39;authentification d&#39;une personne
WO2001056352A2 (fr) Procede et dispositif de paiement electronique
WO2008030184A1 (fr) Systeme d&#39;authentification perfectionne
EP1368930A2 (fr) Authentification cryptographique par modules ephemeres
WO2012031755A2 (fr) Procede d&#39;authentification pour l&#39;acces a un site web
EP1514377A1 (fr) Procede et dispositif d&#39;interface pour echanger de maniere protegee des donnees de contenu en ligne
EP3991381B1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
EP3262553B1 (fr) Procede de transaction sans support physique d&#39;un identifiant de securite et sans jeton, securise par le decouplage structurel des identifiants personnels et de services
EP4012972A1 (fr) Méthode de divulgation sélective de données via une chaine de blocs
EP3673633B1 (fr) Procédé d&#39;authentification d&#39;un utilisateur auprès d&#39;un serveur d&#39;authentification
FR2817067A1 (fr) Procede et dispositif d&#39;authentification de documents electroniques au moyen d&#39;une signature numerique
EP3570518B1 (fr) Systeme et procede d&#39;authentification utilisant un jeton a usage unique de duree limitee
Reddy et al. A comparative analysis of various multifactor authentication mechanisms
EP2084679A1 (fr) Entite electronique portable et procede de blocage, a distance, d&#39;une fonctionnalite d&#39;une telle entite electronique portable
WO2012022856A1 (fr) Procédé d&#39;authentification d&#39; un utilisateur du réseau internet
FR3089031A1 (fr) Procédé de protection par secret d’une donnée stockée sur un équipement mettant en œuvre un paramètre de biométrie comportementale, système de protection de donnée et programme d’ordinateur correspondants.
FR2971350A1 (fr) Procede et dispositif de connexion a un service distant depuis un dispositif hote
EP2330772A1 (fr) Procédé de chiffrement à clef publique sans certificat
FR2957216A1 (fr) Procede d&#39;authentification forte a distance, et procede d&#39;initialisation, dispositif et systemes associes

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20190621

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

ST Notification of lapse

Effective date: 20230808