EP3707857A1 - Dispositif de stockage de clés numériques pour signer des transactions sur une chaine de blocs - Google Patents

Dispositif de stockage de clés numériques pour signer des transactions sur une chaine de blocs

Info

Publication number
EP3707857A1
EP3707857A1 EP18833920.4A EP18833920A EP3707857A1 EP 3707857 A1 EP3707857 A1 EP 3707857A1 EP 18833920 A EP18833920 A EP 18833920A EP 3707857 A1 EP3707857 A1 EP 3707857A1
Authority
EP
European Patent Office
Prior art keywords
dsp
transaction
user
storage device
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.)
Pending
Application number
EP18833920.4A
Other languages
German (de)
English (en)
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
Application filed by Copsonic SAS filed Critical Copsonic SAS
Publication of EP3707857A1 publication Critical patent/EP3707857A1/fr
Pending legal-status Critical Current

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
    • 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/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
    • 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

Definitions

  • the present invention generally relates to blockchains and more particularly to cryptographic key storage devices enabling a user to authenticate and sign transactions on a blockchain.
  • a block chain consists of a sequence of blocks chained by a cryptographic mechanism at regular time intervals. Chaining is obtained by inserting the hash of the previous block into the contents of the current block.
  • the blockchain forms a registry that is distributed and replicated to all nodes in the network.
  • Users can interact with the blockchain by means of thin clients to perform that is, to form and sign transactions that, if validated, are stored in a block of the blockchain.
  • An example of such a transaction is the transfer of an amount in cryptocurrency to a third party.
  • These transactions are verified and validated by a consensus mechanism between nodes, called minors, having a complete copy of the chain, and competing to build blocks according to the aforementioned cryptographic mechanism.
  • Each validated transaction is stored in a block that is broadcast to all the nodes of the network.
  • a wallet address on a blockchain can be considered as a bank account number and the private key as a password to validate access to this account.
  • a transaction typically represents a transfer of a cryptocurrency-denominated amount (satoshis or bitcoins) from one or more portfolio addresses of an issuer to one or more recipient portfolios.
  • transaction consumes one or more UTXOs (Unspent Transaction Output), each UTXO representing an amount not spent by its recipient and being locked to the recipient's wallet address by a lock script.
  • UTXOs Unspent Transaction Output
  • each UTXO representing an amount not spent by its recipient and being locked to the recipient's wallet address by a lock script.
  • the owner To be able to spend a UTXO, the owner must identify himself by presenting to the UTXO cryptographic elements (usually his public key and a signature generated from the corresponding private key) in the form of an unlocking script. If the items presented in the unlock script satisfy the conditions specified in the lock script, the transaction is considered committed.
  • Fig. 1 schematically illustrates the example of a transfer of a cryptocurrency amount between two users of a blockchain, Alice and Bob.
  • Alice forms a transaction from her wallet whose address, @wa Net Alice, is linked to a cryptographic public key (specifically, @wa Net Alice is the hash of her public key).
  • T a To make the payment (of the amount value), Alice forms a transaction, T a , consisting of an input segment and an output segment.
  • the input segment of T a (called scriptSig in Bitcoin) is a script responsible for unlocking the lock script (called scriptPubKey in Bitcoin) contained in the output segment of the transaction, T ⁇ , having created the UTXO of Entrance.
  • the output segment of T a comprises:
  • scriptPubKey a first lock script that locks the amount value to Bob's wallet address, @walletBob, lock that Bob can unlock only by presenting an unlock script (scriptSig) containing a signature authenticating it;
  • scriptPubKey a second lock script that locks the balance value, associated with Alice's wallet address, @walletAlice, lock that Alice can only unlock by presenting an unlock script (scriptSig) containing a signature the authenticator;
  • the unlocking script contained in the input segment of T a , is concatenated with the corresponding locking script contained in the output segment of T j M and the resulting script is executed.
  • the execution of the resulting script makes it possible to verify that the cryptographic elements provided by Alice are legitimate, that is to say that the wallet address @wa Net Alice corresponds to the public key of Alice (hash verification ) and that Alice is indeed the holder of this public key (verification by means of the signature).
  • Validation and storage of the transaction de facto materializes the creation of the first exit UTXO to Bob's wallet and the second exit UTXO in Alice's wallet.
  • Bob will then be able to spend the amount amount by using as input UTXO the first output UTXO previously created. To do this, he will have to unlock it by presenting his own cryptographic elements (public key and signature).
  • the mere possession of a private key makes it possible to carry out transactions on the blockchain from the corresponding portfolio address.
  • the private key is the only proof of ownership of the portfolio and its loss will prevent any access to the cryptocurrency holdings (UTXOs) held in this portfolio.
  • UXOs cryptocurrency holdings
  • his secret key is stolen from him by a malicious third party, the user is liable for all his assets are spent by this third party.
  • the private key Given the criticality of the private key, it is generally recommended to store it generally in paper form and not in electronic format in the memory of a smartphone or computer. In addition, the length of the private key makes it virtually impossible for the user to memorize it and, even if he manages to memorize it, it would be particularly tedious to provide it for each transaction.
  • USB keys are usually provided with a simple interface (LCD screen and a few buttons) allowing the owner to unlock it by means of a PIN code and to sign transactions using the required private key.
  • the secret keys are stored in a secure element, safe from physical attacks, which can only be accessed by means of the PIN code.
  • These USB keys can store different keys and sign transactions on a blockchain without using paper. On the other hand, they are not totally immune against physical attacks insofar as the private keys can be deduced from signals picked up either by electromagnetic radiation or again via the USB interface.
  • An object of the present invention is therefore to provide a digital key storage device for its owner to authenticate and sign transactions on a chain of blocks, in significantly increased security conditions compared to those of the state of the art.
  • the present invention is defined by a digital key storage device for signing transactions on a blockchain, said device comprising a microphone, a loudspeaker, a DSP processor having a secure element for storing at least one secret key, the DSP further comprising an encoder / decoder using a dictionary, S, whose code words, stored in a memory of the DSP or in a secure memory only accessible by the DSP, represent random or pseudo-random ultrasound signals, the DSP communicating with the outside of the device only by an acoustic channel, the DSP being adapted to decode a message consisting of words of S, received from an acoustic channel, via the microphone, to sign the message thus decoded by means of said key private and to transmit in response a signature of said message in the form of a response consisting of successive words of S, on said acoustic channel, via the speaker.
  • the device comprises an HMI interface by means of which a user can enter a private key or a seed for generating a succession of private keys, said private key (s) being stored in the secure element of the DSP processor.
  • the DSP processor typically uses an elliptic curve asymmetric cryptosystem to compute a public key from the private key entered by the user or generated by the DSP from said seed.
  • the DSP processor is adapted to calculate a hash of said public key by means of a hash function to obtain a portfolio address on a blockchain.
  • the device advantageously hosts a software module adapted to require the DSP processor transmission on the acoustic channel of the public key and / or the portfolio address on the acoustic channel.
  • the device is a smartphone, the DSP processor being implemented in a chip separate from the microprocessor on which the operating system of the smartphone runs.
  • the device is a USB key that does not include connection pins other than power pins.
  • the present invention further relates to a method of payment by a user to a third party of an amount in cryptocurrency using a digital key storage device as defined above and a terminal hosting a second software module, said terminal being connected via the Internet to the P2P network implementing the blockchain, characterized in that said user enters in a window displayed by the second software module, the payment amount and the third party's wallet address, and that the second software module forms a transaction comprising an input segment and an output segment, the input segment including at least one reference to a previous transaction of which the user is a recipient, a lock script of the previous transaction, the output segment comprising the said amount and a lock script of the said amount to the third party's wallet address, the second software module transmitting a first message ( M) comprising the transaction thus formed to the digital key storage device, and in the event of validation by the user, the DSP processor signs said message and sends the signature thus obtained in the form of a second message (Sig) to said terminal , the first and second messages being transmitted on the acoustic channel
  • the present invention finally relates to a method of payment by a user to a third party of an amount in cryptocurrency using a digital key storage device as defined above, realized in the form of a computer or a smartphone, the device hosting a second software module (225), and being connected via Internet to the P2P network implementing the blockchain, according to which said user enters in a window displayed by the second software module, the amount of the payment and the third party's portfolio address, and that the second software module forms a transaction comprising an input segment and an output segment, the input segment including at least one reference to a previous transaction
  • the second software module transmitting a first message (M) comprising the transaction thus formed to the digital key storage device, and in the event of validation by the user, the DSP processor signs said message and returns the signature thus obtained in the form of a second message ( Sig) to the device, the first and second messages being transmitted on the acoustic channel in coded form by means of code words of the dictionary S, and the second software module substituting in said transaction the locking script of the previous transaction by a script of unlocking containing the signature thus received and the public key of the user.
  • M first message
  • Sig second message
  • the transaction ⁇ T a is advantageously broadcast to the nodes of the P2P network to be validated and incorporated into a next block of the blockchain.
  • Fig. 1 already described, schematically shows the transfer of a cryptocurrency amount between two users of a blockchain
  • Fig. 2 schematically shows a system using a digital key storage device according to one embodiment of the invention
  • Fig. 3A schematically represents a first exemplary architecture of the key storage device of the system of FIG. 2;
  • Fig. 3B schematically represents a first exemplary architecture of the key storage device of the system of FIG. 2;
  • Fig. 4A is a timing diagram of a portfolio consultation operation using the system of FIG. 2;
  • Fig. 4B is a timing diagram of a payment transaction using the system of FIG. 2;
  • Fig. 5A schematically shows a digital key storage device according to a first implementation variant of the invention
  • Fig. 5B schematically shows a digital key storage device according to a second implementation variant of the invention.
  • the basic idea of the present invention is to provide a digital key storage device (or physical wallet) comprising a loudspeaker, a microphone and a Digital Signal Processor (DSP) digital signal processor with a secure element in which the secret key and public key pairs are stored, the DSP communicating with the outside of the physical device only by random (or pseudo-random) ultrasound signals via said microphone and said speaker.
  • the DSP comprises an acoustic coding / decoding module using a coding dictionary (codebook) S, the code words of which represent random or pseudorandom ultrasonic signals stored in the memory of the DSP or in a secure memory of the DSP. device to which only the DSP has access.
  • a code word is a digital representation of such a random or pseudo-random ultrasound signal, this signal being generated by converting the code word to an analog signal, by amplifying this analog signal if necessary before attacking a signal. transducer.
  • the device is adapted to transmit to and receive from a wallet application (wallet application) cryptographic data, in the form of words from said dictionary, via an acoustic channel between said device and the terminal hosting the wallet application.
  • wallet application wallet application
  • the cryptographic data are not transmitted via a USB or Bluetooth interface as in the prior art, with the inherent risks of interception (eavesdropping) or physical attacks.
  • the use of ultrasonic signals at short range makes these intrusion attempts ineffective.
  • the transmission of cryptographic data by means of random or pseudo-random ultrasound signals substantially increases the robustness of the channel to such attacks.
  • Fig. 2 schematically shows a system comprising a digital key storage device according to one embodiment of the invention.
  • the digital key storage device (or physical wallet) has been shown at 210 with the DSP at 219, the microphone at 213, and the loudspeaker at 217.
  • the device can be implemented in the form of a smartphone as illustrated in the figure, or in the form of a specific USB key provided with a simple HMI interface (LCD screen and buttons for example), or even in the form of an authentication token (box specific electronics), or even in the form of a laptop.
  • the DSP 219 may be the one already present by construction in the laptop.
  • the physical storage portfolio is implemented as a specific USB key, it only includes power pins.
  • the key can be plugged into a USB connector of a computer and thus be powered without this computer can access the data stored in the physical portfolio.
  • the system 200 includes a terminal (typically a laptop computer, PC), 220, connected to the Internet and therefore able to communicate with other nodes of the P2P network (Peer to Peer) implementing the blockchain .
  • a terminal typically a laptop computer, PC
  • PC personal computer
  • the user's terminal, 220 hosts a wallet app 225, such as a thin client SPV (Simplified! Payment Verification) conferring on the terminal the function of lightweight node and allowing it to train and verify transactions on the blockchain.
  • a wallet app 225 such as a thin client SPV (Simplified! Payment Verification) conferring on the terminal the function of lightweight node and allowing it to train and verify transactions on the blockchain.
  • SPV Simple! Payment Verification
  • the terminal of the user will be able to host a complete client, allowing him to have access to a copy of the entire shared register.
  • the wallet application 225 also includes a decoding module using the dictionary S enabling it to decode the random / pseudorandom signals received from the storage device.
  • the terminal may include a DSP (not shown) performing such a decoding on request of the application and returning to it the messages thus decoded.
  • the terminal will be able to transmit the random / pseudorandom signals that it has received to a decoding server in the cloud, which will then send back the decoded messages.
  • This last embodiment is advantageous insofar as one can switch the dictionary S adaptively in the decoding server and the storage device.
  • the digital key storage device, 210 comprises a software module, 215, called wallet control module (walletctrl app), whose main function is to generate a pair (s) (private key, public) and to sign messages using the private key thus generated, for example transactions formed by the wallet application.
  • wallet control module wallet control module
  • the physical portfolio of digital key storage is initialized.
  • the physical portfolio can be password protected (PIN code), fingerprint reader, iris sensor, or other biometric authentication sensor. Password entry or biometric entry is simply to protect access to the physical portfolio.
  • a password used for authentication, that can be entered using the HMI interface (touch screen for example) and validated for example by pressing a validation button or by clicking on an icon of validation displayed on the screen.
  • the initialization phase comprises the generation of at least one key pair (private key, public key) by an elliptic curve cryptosystem or ECC, the domain parameters of which have previously been stored in the DSP.
  • the private key can be obtained for example from a sequence of words entered or selected by means of the HMI interface. Preferably, this sequence is used as a seed to create successive generations of pairs (private key - public key) of a deterministic hierarchical portfolio (HD wallet or Hierarchical Deterministic Wallet), according to the BIP0032 and BIP044 standards.
  • the private keys / public keys do not appear explicitly on the HMI interface but are generated within the DSP, 219, and stored locally, the private keys being stored in the aforementioned secure element.
  • the simplest operation is the consultation of the portfolio, that is to say obtaining the list of UTXO which the user, or more precisely the address of his wallet, is recipient.
  • the wallet address is obtained by a hash of the public key of the user.
  • the user can of course have several public keys and several corresponding wallet addresses.
  • the destination UTXOs each of these addresses can be stored in a separate directory in the wallet app.
  • the user can request, via the HMI interface of the physical portfolio, to transmit the public key, or even the corresponding portfolio address, to the application 225.
  • the user can select via the HMI interface the public key or the desired wallet address and request its transmission to the application 225.
  • the DSP transmits the public key / wallet address by means of random S-code (or pseudo-random) ultrasound signals on the acoustic channel 250.
  • the code words of S (random or ultrasonic signals) pseudo random) are chosen so that the correlation matrix of these signals, possibly filtered by the equivalent filter of the acoustic channel, is as close as possible to a diagonal matrix.
  • the random (or pseudo-random) ultrasound signals are chosen so that the values of the intercorrelation coefficients are minimal and those of the autocorrelation coefficients are maximum.
  • These signals are emitted by the loudspeaker (electro-acoustic transducer for example piezoelectric), 217, of the physical device 210 and received by a microphone (for example a piezoelectric transducer), 223, of the terminal, to be provided.
  • the wallet application 225 either directly in the case where the wallet application takes care of the decoding, or after decoding by the DSP residing in the terminal, or again by decoding by a decoding server as indicated above.
  • the wallet application can then query the blockchain for transactions (for example by blocking a block browser such as block explorer or an API such as blockchain.info ) to this address. If the public key is transmitted to the terminal, the wallet application can simply hash the corresponding wallet address and start the request as before. The chain is then scanned for transactions to this address. In all cases, the transactions that Alice receives are displayed in a window of the application 225.
  • Fig. 3A represents a first exemplary architecture of the digital key storage device in the system of FIG. 2.
  • the operating system 212 (for example Andro ⁇ d TM) runs on the microprocessor 211.
  • the operating system communicates to the DSP only through the microprocessor so as to reinforce the robustness to attacks.
  • the microprocessor receives from the DSP digital messages in the form of words of the dictionary S and transfers them to the driver of the loudspeaker 217. These messages are converted into analog, amplified and the resulting signals are transformed into corresponding ultrasonic signals by the loudspeaker 217. to be transmitted on the acoustic channel 250.
  • the microprocessor receives ultrasonic signals from the microphone 213, previously converted into digital form, and transmits them to the DSP 219.
  • microprocessor plays a transparent role in the exchanges between the DSP and the outside of the device.
  • Fig. 3B is a second exemplary architecture of the digital key storage device in the system of FIG. 2.
  • the DSP may receive control messages and, if necessary, return response messages to the microprocessor as before.
  • the DSP receives and directly transmits the random / pseudo-random ultrasound signals without passing through the microprocessor.
  • the DSP, the loudspeaker and the microphone are part of the same sound card.
  • Fig. 4A schematically summarizes the exchanges within the system 200 when Alice consults her portfolio.
  • the physical wallet transmits Alice's public key pK a or the walletAlice wallet address, via the acoustic channel, to the wallet app of the terminal.
  • the public key pK a is transmitted in the form of a random / pseudo-random ultrasound signal s ⁇ rK a ) where s denotes the coding operation using the aforementioned dictionary S.
  • the portfolio address @ walletAlice will be transmitted as a random / pseudo random ultrasound signal ⁇ t (@ walletAlice).
  • the application After decoding this signal, the application transmits a request at 420 to scan in the block chain the transactions for which @ walletAlice is addressed. After retrieving these transactions in 430, Alice can list the UTXOs at her address (transactions of which @ walletAlice is a recipient whose output is not spent) to eventually aggregate them.
  • the UTXO may (and) be used as input (s) for a new transaction to make a payment.
  • the address @ walletAlice can be communicated in the coded form ⁇ j (@ walletAlice) via an acoustic channel to a third party having a terminal 220 as previously described, so that it can perform a payment to Alice's wallet address.
  • Tr, M in other words transaction T created this UTXO.
  • the wallet application then forms a new transaction, T, for example, using a script P2PKH (Pay to Public Key Hash).
  • P2PKH Payment to Public Key Hash
  • the application In the input segment of T , the application first provides the reference of the selected UTXO, i.e. the hash of the source transaction, 7 ⁇ , ie h (T j ⁇ ). In the T output segment the application then provides the amount to transfer and locking locking script that amount to the portfolio @walletBob address.
  • the application 225 must then provide the cryptographic elements to unlock the lock script that protects the input UTXO from T a (UTXO to @walletAlice in the source transaction 7 ⁇ ), namely its public key and a signature by means of his private key.
  • the wallet software 225 requests the physical wallet 210 to sign the transaction by transmitting a message to it, M, including the hash of the source transaction, and the lock script (scriptPubKey) of the source transaction 7 ⁇ , the cryptocurrency amount and the lock script (scriptPubKey) locking the amount to the @walletBob wallet address.
  • the message M is transmitted to the DSP via the acoustic channel, in the form s (M) obtained by encoding M by means of the dictionary S.
  • the corresponding ultrasonic signals are emitted by the speaker 227 of the terminal and received by the microphone 213 of the physical portfolio 210.
  • the DSP transmits via the microprocessor to the application walletctrl _ app the address of the recipient of the payment as well as the amount.
  • the application then asks the user to confirm the transaction (by pressing an icon on the touch screen or button). If the user confirms it before the expiry of a time-out, the application walletctrl _ app warns the DSP which then signs the message M with the private key (by means of an elliptic curve signature algorithm or ECDSA) and transmits the Sig signature, at the terminal 220.
  • the signature Sig is transmitted in coded form, a (Sig), by means of the signals of the dictionary S, via the acoustic channel
  • the signal a can be decoded by the wallet application, the local DSP or a remote decoding server.
  • the wallet application 225 retrieves the Sig signature and concatenates it with Alice's public key, pK has to form the unlock script (scriptSig).
  • the wallet _ app provides the hash of the source transaction, T ⁇ ) and the unlock script to form the input segment of the transaction T a .
  • the wallet application then prompts the user to confirm the payment (for example by clicking on an icon). If the payment is confirmed, the transaction T a is broadcast to the nodes of the P2P network to be validated and incorporated in a next block of the chain.
  • Fig. 4B schematically summarizes the exchanges within the system 200 when Alice makes a payment.
  • step 450 after the user has entered the payment amount and the portfolio address of the beneficiary in a window of the wallet application, the latter builds a message, M, from the hash of the transaction. source, h ⁇ T ⁇ ), the source transaction locking script, the cryptocurrency payment amount, and a lock script locking the amount to the recipient's portfolio address, @walletBob.
  • the signal S (M) obtained by encoding M (by means of the dictionary S) is transmitted on the acoustic channel by means of the random ultrasound signals of the dictionary S.
  • the DSP After decoding s (M) and retrieving the message M by the DSP, the latter transmits in 451 the recipient's wallet address and the amount to the control application walletctrl _ app.
  • the validation by the user is transmitted by walletctrl _ app to the DSP at 452.
  • the DSP then signs the message M with the help of its private key (EDCSA), codes the signature obtained with the dictionary S to obtain a signal a ( Sig) and transmits the latter to the terminal 220, as before, via the acoustic channel.
  • EDCSA public key
  • the signal a (Sig) is decoded at the terminal 220 to provide the signature
  • the wallet wallet application _ app then builds in 370 the unlocking script from the signature thus received and the public key of Alice to form the input segment of the transaction. Similarly, it concatenates the lock script to the amount to form the output segment of the transaction.
  • this one broadcasts it in 480 to the other nodes of the P2P network.
  • the blockchain was Bitcoin.
  • it can be a block chain in which it is possible to register and execute smart contracts.
  • An example of such a chain of blocks is Ethereum.
  • a smart contract is a program that can be executed by any node of the P2P network implementing the blockchain. It can store data, send and receive payments, execute actions autonomously and decentralized as a software agent.
  • a smart contract verifies if a number of conditions are met and, if so, automatically runs to provide a result coded in the contract.
  • the physical portfolio of digital keys also makes it possible to authenticate as a party to a smart contract and, for example, to give consent.
  • the wallet application (or account Ethereum terminology) can form a transaction and the owner can sign it through the physical portfolio, the transaction thus signed being transmitted to the smart contract stored in the block chain.
  • the terminal 220 was separate from the digital key storage device 210. If the latter is a smartphone, it can also act as a terminal connected to the Internet: the terminal is then confused with the device and the first and second software modules are modules of the same application (or separate applications) of the smartphone as shown in the embodiment of FIG. 5A. They then talk via a local acoustic channel between the speaker 217 and the microphone 213.
  • the terminal can incorporate the DSP 219 with its secure element, the first and second software modules forming part of the same application (or even separate applications) of the terminal, as shown in the embodiment of FIG. 5B. These software modules then communicate via a local acoustic channel between the speaker 217 and the microphone 213, as in the first implementation example.
  • the key storage device / terminal has the same coding dictionary S for sending and receiving messages.
  • S and 5 two separate coding dictionaries, S and 5 "for transmission and reception, the transmission dictionary of one being the dictionary and reception of the other and vice versa. the extent that it allows a full-duplex exchange on the acoustic channel.

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, @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, 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, T^, 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 Tj 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
( Tfimd ) 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 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 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 s{rKa ) 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, Ta par exemple au moyen d'un script P2PKH (Pay to Public Key Hash).
Dans le segment d'entrée de Ta 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(Tj ^) . Dans le segment de sortie de Ta 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, 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, pKa 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 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, 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.

Claims

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 haut- parleur (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. 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. 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. 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. 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. 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. 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. 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 ) 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. 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 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. Méthode de paiement selon la revendication 8 ou 9, caractérisée en ce que, après substitution, la transaction ( Ta ) 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.
EP18833920.4A 2017-12-14 2018-12-12 Dispositif de stockage de clés numériques pour signer des transactions sur une chaine de blocs Pending EP3707857A1 (fr)

Applications Claiming Priority (2)

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
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

Publications (1)

Publication Number Publication Date
EP3707857A1 true EP3707857A1 (fr) 2020-09-16

Family

ID=61802094

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18833920.4A Pending 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

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
WO2019116187A1 (fr) 2017-12-13 2019-06-20 nChain Holdings Limited Système et procédé pour partager en toute sécurité du matériel cryptographique
CN113508410A (zh) * 2019-02-15 2021-10-15 区块链控股有限公司 用于通过区块链网络实现转账的计算机实现的系统和方法
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

Family Cites Families (13)

* 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
US20100281261A1 (en) * 2007-11-21 2010-11-04 Nxp B.V. Device and method for near field communications using audio transducers
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
EP2966792B1 (fr) * 2015-06-17 2018-05-16 Nxp B.V. Système de communication à ultrasons
US9916432B2 (en) * 2015-10-16 2018-03-13 Nokia Technologies Oy Storing and retrieving cryptographic keys from biometric data
GB2560274C (en) * 2016-02-23 2022-06-15 Nchain Holdings Ltd Personal device security using elliptic curve cryptography for secret sharing
CN106779636B (zh) * 2016-11-29 2020-06-26 北京欧凯联创网络科技有限公司 一种基于手机耳机接口的区块链数字货币钱包
CN107392702A (zh) * 2017-07-10 2017-11-24 北京云知科技有限公司 一种基于声纹的商品推送方法及装置

Also Published As

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

Similar Documents

Publication Publication Date Title
EP3707857A1 (fr) Dispositif de stockage de clés numériques pour signer des transactions sur une chaine de blocs
EP1368930B1 (fr) Authentification cryptographique par modules ephemeres
EP2619941B1 (fr) Procede, serveur et systeme d&#39;authentification d&#39;une personne
WO2001056352A2 (fr) Procede et dispositif de paiement electronique
WO2003056750A2 (fr) Systeme cryptographique de signature de groupe
EP2345202A2 (fr) Procédé de signature numérique en deux étapes
EP3595236A1 (fr) Procédé de génération synchrone d&#39;aléa en vue de traitements cryptographiques
WO2003107587A1 (fr) Procede et dispositif d’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
EP3262553A1 (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
FR2817067A1 (fr) Procede et dispositif d&#39;authentification de documents electroniques au moyen d&#39;une signature numerique
WO2019038323A1 (fr) Procédé d&#39;authentification d&#39;un utilisateur auprès d&#39;un serveur d&#39;authentification
EP3570518B1 (fr) Systeme et procede d&#39;authentification utilisant un jeton a usage unique de duree limitee
EP3270315B1 (fr) Procédé de mise en relation sécurisée d&#39;un premier dispositif avec un deuxième dispositif
FR2903544A1 (fr) Procede de securisation d&#39;une authentification par utilisation de plusieurs canaux
WO2012022856A1 (fr) Procédé d&#39;authentification d&#39; un utilisateur du réseau internet
EP2330772A1 (fr) Procédé de chiffrement à clef publique sans certificat
FR2971350A1 (fr) Procede et dispositif de connexion a un service distant depuis un dispositif hote
FR2957216A1 (fr) Procede d&#39;authentification forte a distance, et procede d&#39;initialisation, dispositif et systemes associes

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200611

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: PILOTO FONSECA, CARLOS, DAVID

Inventor name: RUIZ, EMMANUEL

Inventor name: ALFONSO REYES, RUBEN

Inventor name: ROETEN, BRIAN

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
19U Interruption of proceedings before grant

Effective date: 20220628