Method for transferring secret data between two devices.
Patent Information
- Authority / Receiving Office
- FR · FR
- Patent Type
- Patents
- Current Assignee / Owner
- LEDGER
- Filing Date
- 2023-11-23
- Publication Date
- 2026-06-26
AI Technical Summary
Existing methods for transferring secret data, such as recovery phrases for cryptoasset accounts, between hardware wallets are either insecure or cumbersome, lacking a simple and highly secure solution for automated transfer.
A method for transferring secret data between two devices with secure processors involves using a shared random process code to generate symmetric encryption keys, encrypting certificates and data, and verifying authenticity through certification authorities and ephemeral public keys.
This method provides a secure and automated way to transfer secret data, ensuring the integrity and confidentiality of the data during transfer while eliminating the need for manual intervention.
Abstract
Description
Title of the invention: Method for transferring secret data between two devices. Technical field
[0001] The present invention relates to a method for transferring secret data from a first device to a second device, in which each device comprises a secure processor comprising cryptographic calculation means, a secure memory and communication means. Background
[0002] In recent years, the development of cryptocurrencies or other types of cryptoassets managed by blockchains, such as non-fungible tokens ("NFTs") and smart contracts, has given rise to various means of storing and preserving the private and public keys attached to these different types of cryptoassets. This is how cryptoasset wallets, commonly called "wallets", appeared, allowing the storage and preservation of these keys. A cryptoasset wallet is a hardware or software device whose function is to store the private and public keys attached to cryptoasset accounts, and to sign transactions using these keys. A hardware wallet is generally a portable electronic device, equipped with a secure processor having cryptographic calculation means. Transactions involving private keys are signed in an offline environment.Any transaction made online is transferred to the hardware wallet to be digitally signed offline, with the signature then being associated with the transaction when it is placed on a blockchain. Because private keys are not shared with online servers during the signing process, a hacker cannot access them.
[0003] Hardware wallets are therefore now considered the most secure solution against hacker attacks. Their only drawback is the risk of loss, theft or destruction (fire for example), or loss of the user's personal password allowing them to be used. The keys to the crypto-asset accounts they contain must therefore generally be saved in a safe place.
[0004] A first problem that arose in the past was to find a way to simplify the number of keys to be saved, these can be very numerous if the user has many crypto-asset accounts. To solve this problem, the hierarchical deterministic wallet was proposed by Bitcoin. First proposed in the BIP32 standard, then optimized with the BIP39, BIP43 and BIP44 standards, it allows a user to not have to make a new backup for any new key pair generated, a single backup for all the keys in its wallet being sufficient. This solution is now used by the majority of software or hardware cryptoasset wallets.
[0005] With a hierarchical deterministic wallet, all of the user's private keys are generated from an original random seed, usually called a "seed" or "master key." A user only needs to keep the seed safe to retrieve all of their keys, which are derived from the seed and can be reconstructed from it ("child keys").
[0006] Since the master key is a very long binary number that is impossible for a human being to memorize and especially difficult to reproduce manually, the BIP39 standard also proposes that such a master key be generated from a secret phrase also called a "mnemonic phrase", or "recovery phrase" or "seed phrase". According to BIP39, the recovery phrase can be 12 or 24 words long. The type of BIP39 seed currently used in the applicant's devices is a recovery phrase that consists of 24 words chosen from a list of 2048 words defined by the aforementioned standard.
[0007] For the initial generation of the recovery phrase, a hardware wallet generates a sequence of 256 random bits using a random number generator. This initial sequence is sometimes referred to as "entropy." The first 8 bits of a SHA-256 hash of the initial 256 bits are added to this bit string, resulting in 264 bits. The 264 bits are divided into 24 groups of 11 bits by the device. Each group of 11 bits is interpreted as a number between 0 and 2047, which serves as an index to the BIP39 word list, resulting in the 24-word recovery phrase. Through this process, the device generates one recovery phrase out of 2256 possible phrases (i.e. 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possible mnemonic phrases).
[0008] Within the hardware wallet, the master key is derived from the recovery phrase according to a standardized and reproducible process, consisting for example of applying to the recovery phrase a PBKDF2 key derivation function (“Password-Based Key Derivation Function 2”) using an HMAC authentication function (“Keyed-Hash Message Authentication Code”) based on the SHA512 hash function, with a salt comprising the term “mnemonic” and an optional passphrase, and carrying out 2048 iterations.
[0009] Hierarchical deterministic wallets therefore only require a backup of the recovery phrase, preferably at the time of their commissioning, from which it is possible to derive the entire descending key tree. Saving the recovery phrase, however, poses various problems in terms of security, because knowing it alone allows access to all the crypto-asset accounts derived from it, and to seize the sums or values they contain. The most commonly used solutions for saving the recovery phrase are as follows:
[0010] - write down the recovery phrase on a sheet of paper, or on several sheets of paper each receiving some of the words that make up the recovery phrase, then storing the sheet(s) of paper in a safe place, for example a bank vault or several bank vaults,
[0011] - engrave the recovery phrase on one or more steel plates, which are durable and more secure than sheets of paper, and store the steel plate(s) in a safe place, bank vault or other means,
[0012] - use the “Capsule Cryptosteel” solution proposed by the applicant, Consisting of pre-engraved steel micro-tiles, accompanied by a cylindrical backup tool designed to securely store data up to 123 characters in length. The outer casing and tiles are made of solid stainless steel to provide maximum durability for the recovery phrase. The capsule is fire, water, and shock resistant.
[0013] Recently, the applicant has proposed to the public a new solution for saving the recovery phrase called "Ledger Recover", which is easier to implement than the aforementioned known solutions, and is highly secure. According to this solution, the entropy of the recovery phrase, i.e. the initial random binary string from which the recovery phrase is derived, is divided into a plurality of fragments called shares. Each fragment is then sent securely, via authenticated and end-to-end encrypted channels, to the hardware security modules (HSMs) of independent companies. Each fragment cannot be used individually and is linked to the identity of the user, who is therefore the only one who can recover it.
[0014] Another problem related to the recovery phrase arises when a user decides to change hardware wallets, for example from an older model to a newer one. The applicant markets various generations of hardware wallets, each offering improved functionality and usability over previous models, such as the Ledger Nano S, the Ledger Nano X, and the Ledger Stax. The Ledger Nano S offers only a USB connection to a host device running the Ledger Live companion software (computer, tablet, or mobile phone), and a 128 x 32 pixel LCD screen. The Ledger Nano X offers a USB or Bluetooth connection to the host device, and a 128 x 64 pixel LCD screen. The Ledger Stax offers USB, Bluetooth, and NFC connectivity, and features a large 3.7-inch touchscreen. It is therefore common for a user The user decides to switch from one model to another, which requires the laborious operation of copying the recovery phrase to manually provide it to the newly acquired hardware wallet.
[0015] It has been considered to provide for a computer transfer of the recovery phrase from one hardware wallet to another through secure servers equipped with hardware security modules (HSM) which would authenticate the two hardware wallets. The transport of a single block of the recovery phrase in a computer network, however, appears risky in terms of security, and would not be accepted by the public. A method such as "Ledger Recover" could also be used. For this purpose, the recovery phrase would first be saved in several parts ("shares") in backup servers, then restored in the new hardware wallet. However, this method includes steps for verifying the user's identity which are very strict and whose implementation can last several days.It is more suitable for restoring the recovery phrase after it has been lost, rather than transferring it when a new hardware wallet is put into operation.
[0016] It might therefore be desirable to provide a method for transferring the recovery phrase between two hardware wallets, which is simpler to implement while being highly secure.
[0017] More generally, it might be desired to provide a method for transferring secret data between two electronic devices each comprising a secure processor comprising cryptographic calculation means, a secure memory and communication means. Summary
[0018] Embodiments relate to a method for transferring secret data from a first device to a second device, wherein each device comprises a secure processor having cryptographic computing means, a secure memory, and communication means, the method comprising the steps of providing each device with a private key, a public key, a public key of a certification authority, a certificate signed by the certification authority, the certificate comprising the public key of the device and the signature of its public key by the certification authority, providing the devices with a random process code common to both devices, and by means of the first device: generating an integer that is a function of the process code, defining a first symmetric encryption key as being equal to the integer or generating it from the integer,receiving the certificate of the second device in encrypted form using the first symmetric encryption key, decrypting the certificate of the second device with the first symmetric encryption key, using the key, public key of the certification authority, verify the authenticity of the certificate of the second device, to ensure that the second device is authorized by the certification authority to receive the secret data, receive an ephemeral public key from the second device, generate an ephemeral public key, transmit the ephemeral public key, generate a second symmetric encryption key from the ephemeral public key of the second device, encrypt the secret data with the second symmetric encryption key, and transmit the secret data in its encrypted form with the second symmetric encryption key.
[0019] According to one embodiment, the method comprises the steps of, by means of the first device: receiving a signature of the ephemeral public key of the second device, generated by means of the private key of the second device, and verifying the authenticity of the ephemeral public key of the second device by means of the public key of the second device present in the certificate of the second device, to ensure that the second device which issued the ephemeral public key is the same as the second device which issued the certificate.
[0020] According to one embodiment, the first device generates the second symmetric encryption key from the ephemeral public key of the second device and the ephemeral public key of the first device.
[0021] According to one embodiment, the first device generates the second symmetric encryption key from the ephemeral public key of the second device and an ephemeral private key of the first device.
[0022] According to one embodiment, the first device generates its ephemeral public key from the integer.
[0023] According to one embodiment, the method comprises the steps of, by means of the second device: generating the integer which is a function of the process code, in the same manner as the first device, setting the first symmetric encryption key as equal to the integer or generating it from the integer, in the same manner as the first device, encrypting the certificate of the second device with the first symmetric encryption key, transmitting the certificate of the second device in its encrypted form, generating the ephemeral public key of the second device, transmitting the ephemeral public key of the second device, receiving the ephemeral public key of the first device, generating said second symmetric encryption key from the ephemeral public key of the first device, receiving the secret data in said encrypted form with the second symmetric encryption key,and decrypt the secret data with the second symmetric encryption key and store the secret data in the secure memory.
[0024] According to one embodiment, the method comprises the steps of, by means of the second device: sign the second device's ephemeral public key using the second device's private key, and transmit the signature of the second device's ephemeral public key.
[0025] According to one embodiment, the second device generates the second symmetric encryption key from the ephemeral public key of the first device and the ephemeral public key of the second device.
[0026] According to one embodiment, the second device generates the second symmetric encryption key from the ephemeral public key of the first device and an ephemeral private key of the second device.
[0027] According to one embodiment, the second device generates its ephemeral public key from the integer.
[0028] According to one embodiment, the step of providing the devices with a process code is implemented according to one of the following two methods: the first device generates random data forming the process code which is then provided to the second device, or the second device generates random data forming the process code which is then provided to the first device via a keyboard.
[0029] According to one embodiment, the first device and the second device do not communicate directly and are connected to a host device, the method comprising the steps of, by means of the host device: sequentially sending commands to one or the other of the devices, receiving data from each device in response to the commands, and transferring to each device data received from the other device in response to the commands.
[0030] According to one embodiment, the method comprises the steps of: disconnecting the second device from the host device and connecting the first device to the host device, to enable the host device to exchange data with the first device, and disconnecting the first device from the host device and connecting the second device to the host device, to enable the host device to exchange data with the second device.
[0031] According to one embodiment, the first device and the second device are hardware cryptoasset wallets.
[0032] According to one embodiment, the secret data is a cryptoasset account recovery phrase.
[0033] Embodiments also relate to a portable electronic device comprising a secure processor comprising cryptographic calculation means, a secure memory, communication means, the secure memory comprising a private key, a public key, a public key of a certification authority, a certificate signed by the certification authority, the certificate comprising the key public key of the device and the signature of the public key of the device by the certification authority, the device comprising a program enabling it to transmit to an external device a secret data item that the device holds in the secure memory, and being configured to: receive or generate a random process code and store it, generate an integer that is a function of the process code, define a first symmetric encryption key as being equal to the integer or generate it from the integer, receive an external certificate in an encrypted form using the first symmetric encryption key, decrypt the external certificate with the first symmetric encryption key, using the public key of the certification authority, verify the authenticity of the external certificate, to ensure that it is issued by a device authorized by the certification authority to receive the secret data item,receiving an outer ephemeral public key, generating an inner ephemeral public key, transmitting the inner ephemeral public key, generating a second symmetric encryption key from the outer ephemeral public key, encrypting the secret data with the second symmetric encryption key, and transmitting the secret data in its encrypted form with the second symmetric encryption key.
[0034] According to one embodiment, the device is configured to receive a signature of the external ephemeral public key, verify the authenticity of the external ephemeral public key using the external public key present in the external certificate, to ensure that a device that issued the external ephemeral public key is the same as a device that issued the external certificate.
[0035] According to one embodiment, the device is configured to generate the second symmetric encryption key from the external ephemeral public key and the internal ephemeral public key.
[0036] According to one embodiment, the device is configured to generate the second symmetric encryption key from the external ephemeral public key and an internal ephemeral private key.
[0037] According to one embodiment, the device is configured to generate the internal ephemeral public key from the integer.
[0038] According to one embodiment, the device is configured to generate the random process code and display it on a display means.
[0039] According to one embodiment, the device forms a hardware wallet of cryptoassets.
[0040] According to one embodiment, the secret data is a cryptoasset account recovery phrase.
[0041] Embodiments also relate to a portable electronic device comprising a secure processor comprising cryptographic calculation means, a secure memory, communication means, the secure memory comprising a private key, a public key, a public key of a certification authority, a certificate signed by the certification authority, the certificate comprising the public key of the device and the signature of the public key of the device by the certification authority, the device comprising a program enabling it to receive an external secret data item, and being configured to receive or generate a random process code and store it, generate an integer which is a function of the process code, define a first symmetric encryption key as being equal to the integer or generate it from the integer, encrypt the certificate with the first symmetric encryption key, transmit the certificate in its encrypted form, generate an internal ephemeral public key, transmit the internal ephemeral public key, receive an external ephemeral public key,generating a second symmetric encryption key from the external ephemeral public key, receiving the external secret data in an encrypted form with the second symmetric encryption key, and decrypting the secret data with the second symmetric encryption key and storing the secret data in the secure memory.
[0042] According to one embodiment, the device is configured to sign the internal ephemeral public key using the private key, and transmit the signature of the ephemeral public key.
[0043] According to one embodiment, the device is configured to generate the second symmetric encryption key from the external ephemeral public key and the internal ephemeral public key.
[0044] According to one embodiment, the device is configured to generate the second symmetric encryption key from the external ephemeral public key and an internal ephemeral private key.
[0045] According to one embodiment, the device is configured to generate the internal ephemeral public key from the integer.
[0046] According to one embodiment, the device is configured to generate the random process code and display it on a display means.
[0047] According to one embodiment, the device forms a hardware wallet of cryptoassets.
[0048] According to one embodiment, the secret data is a cryptoasset account recovery phrase. Summary description of the drawings
[0049] These characteristics as well as others of the present invention, will be better understood on reading the following description of embodiments of a method for transferring a recovery phrase between two hardware wallets, made without limitation in relation to the attached figures among which:
[0050] - [Fig.l] shows two hardware cryptoasset wallets configured for exchanging a recovery phrase according to a first embodiment of the method,
[0051] - [Fig.2] is a sequence diagram of the first embodiment of the process,
[0052] - [Fig.3] describes steps of the sequence diagram of [Fig.2],
[0053] - [Fig.4] shows two hardware cryptoasset wallets configured for exchanging a recovery phrase according to a second embodiment of the method,
[0054] - [Fig.5] is a sequence diagram of the second embodiment of the process,
[0055] - [Fig.6] describes steps of the sequence diagram of [Fig.5],
[0056] - [Fig.7] is a sequence diagram of a third embodiment of the recovery phrase exchange method implemented with the hardware wallets of [Fig.l],
[0057] - [Fig.8] describes steps of the sequence diagram of [Fig.7]. Detailed description
[0058] The invention provides a method for producing a cryptoasset wallet offering a unique functionality in the field of hardware wallets, namely a functionality for transferring the recovery phrase to another hardware wallet that is automated while being highly secure. Such a method allows users to free themselves from all the difficulties associated with having to manually transfer the recovery phrase to a new hardware wallet.
[0059] [Fig.2] schematically shows the conventional architecture of two devices WA, WB forming hardware wallets and configured to implement an embodiment of the method according to the invention. Each device comprises a secure processor SP comprising cryptographic calculation means, a secure memory SMEM, a communication interface CINT, a display screen DSP, a keyboard KBD, and a random data generator RGEN which in practice can be integrated into the secure processor. The secure processor SP can be a secure element, namely an integrated circuit comprising various protections against hardware and software attacks. The secure memory SMEM, although represented here as distinct from the secure processor SP, can be integrated into the secure processor SP, in particular if it is a secure element.The SMEM memory comprises a non-volatile memory area receiving the secure processor's operating system OS, and a non-volatile memory area receiving or intended to receive the recovery phrase RPH from which the master key of crypto-asset accounts is generated. It also comprises a volatile memory area receiving volatile data or variables, for example PCD data specific to the method according to the invention, which will be described later. The operating system OS of each device WA, WB comprises a TAPI transfer application program (“Transfer Application”) intended to implement this method.
[0060] In the embodiment shown in [Fig.l], the devices WA, WB cannot communicate with each other and can only be connected to a host device HD (personal computer, tablet or mobile phone). This host device comprises an application processor AM and a companion program CAP such as the “Ledger Live” software marketed by the applicant. Such a configuration corresponds to the most generally encountered case of hardware wallets whose CINT communication interface only offers USB or Bluetooth connectivity allowing them to connect only to a host device. The device WA is for example a Ledger NanoX and the device WB another Ledger NanoX or a Ledger Stax, the latter being equipped with a virtual KBD keyboard displayed on a PCD touch screen.In order to implement the method of the invention, the host device is here provided with a TAPHS application program (“Transfer Application Host Service”) which supplements the TAPI program executed by each WA, WB device and establishes a deferred-time communication link between the two WA, WB devices, as will be seen later.
[0061] In the example shown in [Fig.l], the WA device holds the keys to the cryptoasset accounts of a user USR and in particular the recovery phrase RPH that we wish to transfer to the WB device. The sole transfer of this will allow the WB device to find the private and public keys of all the cryptoasset accounts associated with it.
[0062] Figures 2 and 3 describe an embodiment of the method according to the invention making it possible to carry out such a transfer. The different steps represented in these figures are described below.
[0063] Step S10, applied to the device WA:
[0064] PersoWA: PkA, SkA, CIA=PkA, SIGN(SkI, PkA)
[0065] Step S20, applied to the WB device:
[0066] PersoWB: PkB, SkB, CIB=PkB, SIGN(SkI, PkB)
[0067] In order to implement the method of the invention, each device WA, WB receives beforehand during these personalization steps S10 and S20, a private key SkA, SkB, a public key PkA, PkB, a public key Pki from a certification authority ICA and a certificate CIA, CIB signed by the certification authority. It will be noted, concerning this personalization step, that the expression “each device WA, WB receives a key” or “provide a key to each device WA, WB” is not related to the personalization step. mitative and includes the embodiment where the key(s) considered is(are) created locally by each device WA, WB. The certificate CIA, CIB includes the public key PkA, PkB of the device and the signature SIGN(SkI, PkA), SIGN(SkI, PkB) of its public key by the certification authority, generated by the certification authority using its private key Ski. These keys are strictly confidential and are stored in the non-volatile part of the secure memory SMEM of each device.
[0068] Step S30, applied to the devices WB, WA:
[0069] Prepared Transfer
[0070] The user USR activates the TAPI application in each WB and WA device, and configures the WA and WB devices by indicating to the WB device that it is the receiver of the recovery phrase and to the WA device that it is the giver of the recovery phrase. The user also activates in the host device HD the TAPHS transfer application.
[0071] Step S40: “PCD_GEN”
[0072] (1) WB PCD -> USR -> WA
[0073] (2) WA -> PCD -> USR -> WB
[0074] (3) USR -> PCD -> WB, WA
[0075] During this step, which is divided into three variants, a random process code PCD (“Process Code”) is provided to the devices WA, WB. These variants are as follows:
[0076] (1) the WB device generates the PCD process code by means of the generator random RGEN, stores it and displays it to the USR user on his DSP screen. The user reads the PCD process code and provides it to the WA device via the WA device's KBD keyboard, which stores the code.
[0077] (2) the WA device generates the PCD process code by means of the generator random RGEN, stores it and displays it to the user USR. The user provides the PCD code to the WB device via the KBD keyboard of the WB device, which stores the code.
[0078] (3) the user USR generates the PCD process code, for example by means of a external random code generator, then provides the PCD code to the WB device and WA device via their respective KBD keyboards. The latter memorize the PCD code.
[0079] Step S50, applied to the HD device:
[0080] Start Transfer
[0081] The user initiates the process by indicating to the TAPHS transfer application of the HD host device that the step of providing the PCD code to the WA, WB devices is complete. The HD host device has a list of commands intended to be sent sequentially to the WB and WA devices, which it will transmit in the manner described below. In this embodiment, the WA, WB devices can only receive and respond to commands from the host device.
[0082] Step S60, executed by the HD device:
[0083] Connect WB
[0084] The HD host device asks the user to connect the WB device to the HD host device if this is not done.
[0085] Step S101, executed by the HD device for the attention of the WB device:
[0086] Get Certificate
[0087] The HD host device here requests the WB device to communicate its certificate
[0088] Step S103, executed by the device WB:
[0089] w=HASH384(PCD) mod n
[0090] The WB device prepares to send its certificate by first generating a 384-bit integer w by hashing the PCD process code using a HASH hash function, for example SHA384. The choice of an integer modulo n is optional for this step but is linked here to a need for subsequent calculation on an elliptic curve of order n involving the number w. For example, in the case of the elliptic curve SECP384R1, n is equal to: [0091 ] 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC7634D81F437 2DDF581A0DB248B0A77AECEC196ACCC52973,
[0092] Cf. Standards for Efficient Cryptography - SEC 2: Recommended Elliptic Curve Domain Parameters - Certicom Research - January 27, 2010 - Version 2.0 -
[0093] https: / / www.secg.org / sec2-v2.pdf.
[0094] Step S105, executed by the WB device:
[0095] ENC(w, CIB)
[0096] The WB device encrypts the CIB certificate using the number w as the key encryption, using a symmetric encryption function, for example the AES ("Advanced Encryption Standard") function. Alternatively, an encryption key w' different from the number w can be derived from it and used for this operation.
[0097] Step S107, executed by the WB device for the attention of the HD device:
[0098] Response to Get Certificate: ENC(w, CIB)
[0099] In response to the command, the result of the CIB certificate encryption is now sent to the HD host device, which stores it.
[0100] Step S109, executed by the HD device for the attention of the WB device:
[0101] Get Ephemeral Certificate
[0102] The HD host device here sends to the WB device the following command appearing in the list of commands to send. This command asks the WB device to communicate an ephemeral public key accompanied by its signature generated using its private key, the whole forming an ephemeral certificate. Alternatively, the host device could ask the WB device to provide only an ephemeral public key, without a signature. However, it will be seen later that this signature allows the WA device to ensure that the device that provided the encrypted certificate "ENC(w, CIB)" is the same one that provides the ephemeral public key.
[0103] Step SI 11, executed by the WB device:
[0104] X=x*P
[0105] To initiate the process of generating an ephemeral public key, the WB device randomly draws a number x and calculates a number X with a generator P of the elliptic curve used, for example the SECP384R1 curve making it possible to generate 384-bit words, X being a point of the curve, the operation x*P being scalar multiplication.
[0106] Step S113, executed by the device WB:
[0107] PkeB=w*M + X
[0108] The WB device then generates an ephemeral public key PkeB by performing the scalar product of w with M to which X is added. M is a constant whose values can for example be found in section 6.6 of the document RFC 9382 -Spake2 - September 2023 - ISSN 2070-1721 - W. Ladd -
[0109] https: / / www.rfc-editor.org / rfc / rfc9382.html.
[0110] It will be noted here that the ephemeral private key of the device WB, corresponding to the ephemeral public key PkeB, can be considered as being formed by the pair [x, w].
[0111] Step S115, executed by the device WB:
[0112] SIGN(SkB, PkeB)
[0113] The WB device then calculates the signature of the ephemeral public key using its private key SkB, to form an ephemeral certificate PkeB, SIGN(SkB, PkeB). The signature function used is for example the ECDSA signature (“Elliptic Curve Digital Signature Algorithm”) used with the SECP384R1 elliptic curve.
[0114] Step S117, executed by the WB device for the attention of the HD device:
[0115] Response to Get Ephemeral Certificate: PkeB, SIGN (SkB, PkeB)
[0116] In response to this command, the WB device sends the ephemeral certificate PkeB, SIGN(SkB, PkeB) to the HD host device. This is stored by the HD host device.
[0117] Step SI 19, executed by the HD device for the attention of the USR device:
[0118] ConnectWA
[0119] The user is prompted by the HD host device to disconnect the WB device and connect the WA device. It may be provided that the user must then press a key to confirm the continuation of the process.
[0120] Step S121, executed by the HD device for the attention of the WA device:
[0121] Verify Certificate ENC(w, CIB)
[0122] During this step, the host device HD passes the CIB certificate of the WB device to the WA device and asks it to verify it.
[0123] Step S123, executed by the device WA:
[0124] w=HASH384(PCD) mod n
[0125] For this purpose, the device WA in turn calculates the number w from the PCD process code.
[0126] Step S125, executed by the device WA:
[0127] DEC(w, ENC(w, CIB))
[0128] Once w is calculated, the WA device can decrypt the certificate of the WB device using the number w as a decryption key and a decryption function DEC corresponding to the encryption function ENC.
[0129] Step S127, executed by the device WA:
[0130] Verify(PkI, CIB)
[0131] Once the CIB certificate is decrypted (CIB=PkB, SIGN(SkI, PkB)), the WA device verifies that this certificate has an authentic signature, using the public key Pki of the certification authority.
[0132] Step S129, executed by the device WA for the attention of the device HD:
[0133] Success / Error
[0134] The WA device is now able to respond to the previously received “Verify Certificate” command and returns a success or error message. If the authenticity of the certificate is verified, this confirms that the second WB device is authorized by the ICA certification authority to receive the recovery phrase,
[0135] Step S131, executed by the HD device for the attention of the WA device:
[0136] Verify Ephemeral Certificate PkeB, SIGN (SkB, PkeB)
[0137] The host device HD now requests the device WA to verify the ephemeral certificate of the device WB comprising the ephemeral public key and its signature using the private key SkB.
[0138] Step S133, executed by the device WA:
[0139] Verify(PkB, SIGN(SkB, PkeB)
[0140] The WA device which previously obtained, after decryption of the CIB certificate, the public key PkB of the WB device present in this certificate, can now verify that the signature of the ephemeral public key PkeB present in the ephemeral certificate is correct, using the public key PkB.
[0141] Step S135, executed by the device WA for the attention of the device HD:
[0142] Success / Error
[0143] The WA device confirms the success of the verification step. In case of error the process is interrupted.
[0144] Step S137, executed by the HD device for the attention of the WA device:
[0145] Get Ephemeral Public Key
[0146] The host device HD now asks the WA device to provide it with an ephemeral public key.
[0147] Step S139, executed by the device WA:
[0148] Y=y*P
[0149] To begin, the device WA randomly draws a number y and calculates a number Y with the generator P of the chosen elliptic curve, the same as previously, for example the curve SECP384R1, Y being a point of the curve P.
[0150] Step S141, executed by the device WA:
[0151] PkeA=w*N + Y
[0152] The WA device then generates the ephemeral public key PkeA by performing the scalar product of w with N to which Y is added. N is a constant whose values can for example be found in section 6.6 of the aforementioned RFC 9382 Spake2 document. As before, we can consider here that the ephemeral private key of the WA device, corresponding to the ephemeral public key PkeA, is formed by the pair [y, w]
[0153] Step S143, executed by the device WA for the attention of the device HD:
[0154] Response to Get Ephemeral Public Key: PkeA
[0155] The WA device here responds to the previously received command by sending to the host device HD the ephemeral public key PkeA that it has just generated.
[0156] Step S145, executed by the HD device for the attention of the WA device:
[0157] Get Transfer RPH
[0158] The host device HD now requests the WA device to transfer the recovery phrase RPH to it
[0159] Step S147, executed by the device WA:
[0160] K=y*(PkeB-w*N)
[0161] Following this command, the device WA first calculates a shared secret K using the above formula, which involves the part y of its private key, the number w, the constant N and the ephemeral key PkeB of the device WB.
[0162] Step S149, executed by the device WA:
[0163] TT=len(A)IIAIIlen(B)IIBIIlen(PkeB)IPkeBlllen(PkeA)IIPkeA
[0164] lllen(K)IIKIIlen(w)llw
[0165] During this step, the WA device calculates a TT transcript by concatenating the data mentioned in the formula above and their respective lengths (“len”). Indeed K is a shared value, which must not be used or brought into play directly in data exchanges, and must therefore be protected as a shared secret. A and B are two additional data of predetermined value used for the calculation of TT. In one embodiment, the string len(A)IIAIIlen(B) IIBII may not be used. It will finally be noted that the use of the TT transcript guarantees that any manipulation by a forger of the sent messages will be reflected in the keys generated during the next step.
[0166] Step S151, executed by the device WA:
[0167] KellKa=HASH(TT)
[0168] During this step, the device WA generates a binary string, for example of 512 bits, forming two keys Ke and Ka, for example of 256 bits each. The hash function HASH used is for example SHA 512. The key Ke will be used as a symmetric encryption key for the transfer in encrypted form of the recovery phrase RPH while the key Ka will be used for the derivation of two keys KcA, KcB.
[0169] Step S153, executed by the device WA:
[0170] KcAIIKcB=KDF(Ka, “ConfirmationKeys”IIAAD)
[0171] During this step, the WA device generates keys KcA and KcB using a key derivation function KDF, for example the HMAC-based Key Derivation Function (HKDF) based on the HMAC message authentication code. The keys KcA and KcB will be used later to prove that each WB, WA device has correctly calculated the key on its side. The term "ConfirmationKeys" is a predetermined character string. Generally, any other consensus-defined character string can be used here to form a domain separation. Finally, AAD is an optional additional data string to add entropy to the key derivation, where AAD must be known to both WA, WB devices.
[0172] Step S155, executed by the device WA:
[0173] cB=MAC(KcB, TT)
[0174] The WA device here calculates an authentication code cB by applying a MAC function (“Message Authentication Code”) to the transcript TT, the code being generated from the key KcB. The MAC function can for example be the HMAC (“Keyed Hash Message Authentication Code”) or CMAC (“Cipher-based Message Authentication Code”) algorithm.
[0175] Those skilled in the art will have noted in the above that various steps of the method are based on the same random variable w. It will further be noted that according to the usual usage of certain steps of the method just described, K should be a secret data that two devices share, cB being the confirmation data that two devices exchange. Here, these steps are used to generate the key of Ke encryption of the RPH recovery phrase to be transmitted, to which the cB code can optionally be attached.
[0176] Step S157, executed by the device WA:
[0177] ENC(Ke, RPH)
[0178] During this step, the WA device encrypts the recovery phrase RPH using the shared secret Ke used as an encryption key. The ENC encryption algorithm can, as previously, be for example an AES (“Advanced Encryption Standard”) function.
[0179] Step S159, executed by the device WA for the attention of the device HD:
[0180] Response to Get Transfer RPH: ENC(Ke, RPH), cB
[0181] In response to the previously received command, the WA device therefore transmits here to the host device HD the encrypted recovery phrase RPH, as well as, optionally, the confirmation code cB.
[0182] Step S161, executed by the HD device for the attention of the USR device:
[0183] ConnectWB
[0184] The user is prompted by the host device to disconnect the WA device and connect the WB device. It may be provided that the user must then press a key to confirm the continuation of the process.
[0185] Step S163, executed by the HD device for the attention of the WB device:
[0186] Set Ephemeral Public Key: PkeA
[0187] During this step, the host device HD passes on to the WB device the ephemeral public key PkeA of the WA device, which it has memorized.
[0188] Step S165, executed by the WB device:
[0189] K=x*(PkeA-w*M)
[0190] The WB device calculates the shared secret K using the part x of its private key, the ephemeral key PkeA of the WA device and the constant M.
[0191] Step S167, executed by the WB device for the attention of the HD device:
[0192] Success / Error
[0193] This response message may be optionally provided in application of a rule according to which any command must be followed by a response, the role of which is at least to confirm the correct receipt of the command.
[0194] Step S169, executed by the HD device for the attention of the WB device:
[0195] Set transfer: ENC(Ke, RPH), cB
[0196] During this step, the host device HD transmits to the WB device the encrypted recovery phrase RPH as well as, optionally, the confirmation data cB.
[0197] Step S171, executed by the WB device:
[0198] TT=len(A)IIAIIlen(B)IIBIIlen(PkeB)IPkeBlllen(PkeA)IIPkeA
[0199] lllen(K)IIKIIlen(w)llw
[0200] As the WA device did previously, the WB device here calculates the TT transcript.
[0201] Step S173, executed by the WB device:
[0202] KellKa=HASH(TT)
[0203] As the WA device did previously, the WB device here generates the keys Ke and Ka.
[0204] Step S175, executed by the WB device:
[0205] KcAIIKcB=KDF(Ka, “ConfirmationKeys”IIAAD)
[0206] As the WA device did previously, the WB device here calculates keys KcA and KcB.
[0207] Step S177, executed by the WB device:
[0208] cB=MAC(KcB, TT)
[0209] As the WA device did previously, the WB device here calculates the authentication code cB.
[0210] Step S179, executed by the WB device:
[0211] DEC(Ke, ENC(Ke, RPH))=RPH
[0212] The WB device here decrypts the recovery phrase RPH using the key Ke and the decryption function DEC, then stores it in its secure memory.
[0213] Step S181, executed by the device WB to the attention of the device HD:
[0214] Success / Error
[0215] This success message confirms to the user that the recovery phrase has been successfully transferred. The user can then, if desired, erase all data present in the WA device.
[0216] [Fig.4] illustrates an embodiment of the transfer method in which the two devices WA, WB can communicate directly with each other, without going through the host device HD, which is represented here in dotted lines because it is still likely to be used by each device WA, WB to place transactions on a blockchain. The communication interfaces CINT of each device WA, WB are here directly connected by a communication channel, by which the recovery phrase RPH will be sent by the device WA to the device WB. The devices WA, WB are here provided with a transfer application TAP2 which manages the direct exchanges between the two devices. The devices WA, WB are for example Ledger Stax marketed by the applicant, equipped with NFC connectivity allowing them to communicate directly.These may also be mobile phones equipped with a crypto asset wallet function and not requiring pairing with a host device. The host device in this case is formed by the application processor of the mobile phone, while the function of . Hardware wallet is implemented by software (“software wallet”) or by means of a secure element integrated into the mobile phone.
[0217] Figures 5 and 6 which describe an embodiment of the method for carrying out the transfer of the recovery phrase without going through the host device. The different steps represented in these figures are described in the following. The steps previously described will be mentioned but will not be described again.
[0218] Step S10, applied to the device WA:
[0219] PersoWA: PkA, SkA, CIA=PkA, SIGN(SkI, PkA)
[0220] Step S20, applied to the WB device:
[0221] PersoWB: PkB, SkB, CIB=PkB, SIGN(SkI, PkB)
[0222] Step S31 applied to the devices WB, WA:
[0223] Prepared Transfer
[0224] This step differs from step S30 previously described in that the user here activates the TAP2 transfer applications in the WB and WA devices. The TAP2 applications are configured so that each device can send commands or respond to commands issued by the other device. The user here configures the WA and WB devices by indicating to the WB device that it is the receiver of the recovery phrase and to the WA device that it is the giver of the recovery phrase.
[0225] Step S40 “PCD_GEN”, generating the PCD code according to one of the three aforementioned variants:
[0226] (1) WB PCD USR WA
[0227] (2) WA -> PCD -> USR -> WB
[0228] (3) USR PCD WB, WA
[0229] Step S51, applied to devices WA, WB:
[0230] Start Transfer
[0231] This step differs from step S50 previously described in that the user activates in each device WA, WB the engagement of the transfer process which begins with the establishment of a communication between the two devices.
[0232] Step S201 executed by the WA device for the attention of the WB device:
[0233] Get Certificate
[0234] The WA device requests the WB device to communicate its CIB certificate to it. This command is the same as that sent in step S101 previously described but is here sent directly by the WA device since the host device no longer acts as an intermediary.
[0235] Step S103 executed by the WB device:
[0236] w = HASH384(PCD) mod n
[0237] Step S105 executed by the WB device:
[0238] ENC(w, CIB)
[0239] Step S207 executed by the WB device for the attention of the WA device:
[0240] Response to Get Certificate: ENC(w, CIB)
[0241] This step corresponds to the combination of steps S107, S121 previously described, since the host device no longer acts as an intermediary.
[0242] Step S123 executed by the device WA:
[0243] w = HASH384(PCD) mod n
[0244] Step S125 executed by the device WA:
[0245] DEC(w, ENC(w, CIB))
[0246] Step S127 executed by the device WA:
[0247] Verify(PkI, CIB)
[0248] Step S209 executed by the device WA for the attention of the device WB:
[0249] Get Ephemeral Certificate
[0250] This command is the same as that sent in step S109 previously described but the command is here sent directly by the WA device since the host device no longer acts as an intermediary.
[0251] Step S111 executed by the WB device:
[0252] X = x*P
[0253] Step S113 executed by the WB device:
[0254] PkeB = w*M + X
[0255] Step S115 executed by the WB device:
[0256] SIGN(SkB, PkeB)
[0257] Step S217 executed by the WB device for the attention of the WA device:
[0258] Response to Get Ephemeral Certificate: PkeB, SIGN (SkB, PkeB)
[0259] This step corresponds to the combination of steps S117, S131 previously described.
[0260] Step S133 executed by the device WA:
[0261] Verify(PkB, SIGN(SkB, PkeB)
[0262] This step has been previously described but is initiated here upon receipt of the ephemeral certificate and without it being necessary to send to the WA device the command “Verify Ephemeral Certificate PkeB, SIGN(SkB, PkeB)” issued in step S131 previously described. As the WA device decrypted the CIB certificate in step S125, it has knowledge of the public key PkB of the WB device and can verify the ephemeral certificate.
[0263] Step S235 executed by the device WA for the attention of the device WB:
[0264] Success / Error
[0265] This response is identical to the response of step S135 previously described, but is sent directly to the WA device since the host device no longer acts as high intermediate
[0266] Step S139 executed by the device WA:
[0267] Y = y*P
[0268] Step S141 executed by the device WA:
[0269] PkeA = w*N + Y
[0270] Step S243 executed by the device WA for the attention of the device WB:
[0271] Set ephemeral public key: PkeA
[0272] This step corresponds to the combination of steps S143, S163 previously described.
[0273] Step S165 executed by the WB device:
[0274] K = x*(PkeA - w*M)
[0275] Step S266 executed by the WB device for the attention of the WA device:
[0276] Success / Error
[0277] The WB device here confirms to the WA device that it has finished its calculation.
[0278] Step S147 executed by the device WA:
[0279] K = y*(PkeB - w*N)
[0280] Step S149 executed by the device WA:
[0281] TT=len(A)IIAIIlen(B)IIBIIlen(PkeB)IPkeBlllen(PkeA)IIPkeA
[0282] lllen(K)IIKIIlen(w)llw
[0283] Step S151 executed by the device WA:
[0284] KelIKa = HASH(TT)
[0285] Step S153 executed by the device WA:
[0286] KcAIIKcB = KDF(Ka, “ConfirmationKeys”IIAAD)
[0287] Step S155 executed by the device WA:
[0288] cB=MAC(KcB, TT)
[0289] Step S157 executed by the device WA:
[0290] ENC(Ke, RPH)
[0291] Step S259 executed by the device WA for the attention of the device WB:
[0292] Set transfer: ENC(Ke, RPH), cB
[0293] This step by which the device WA sends to the device WB the encrypted recovery phrase RPH as well as, optionally, the code cB, corresponds to the combination of steps S159, S169 previously described.
[0294] Step S171 executed by the WB device:
[0295] TT=len(A)IIAIIlen(B)IIBIIlen(PkeB)IPkeBlllen(PkeA)IIPkeA
[0296] lllen(K)IIKIIlen(w)llw
[0297] Step S173 executed by the WB device:
[0298] KelIKa = HASH(TT)
[0299] Step S175 executed by the WB device:
[0300] KcAIIKcB = KDF(Ka, “ConfirmationKeys”IIAAD)
[0301] Step S177 executed by the WB device:
[0302] cB=MAC(KcB, TT)
[0303] Step S179 executed by the WB device:
[0304] DEC(Ke, ENC(Ke, RPH)) = RPH
[0305] Step S281 executed by the WB device for the attention of the WA device:
[0306] Success / Error
[0307] This response is identical to the response sent in step S181 previously described but is sent directly to the device WA.
[0308] It will be clear to those skilled in the art that the method of the invention can be implemented with other methods allowing the devices WA, WB to define a common encryption key. By way of example, Figures 7 and 8 describe a variant of the method of Figures 2 and 3 in which an ECDH (“Elliptic Curve Diffie-Hellman”) key exchange based on elliptic curves is implemented. The different steps shown in these figures are described in the following. The steps previously described will be mentioned but will not be described again.
[0309] Step S10, applied to the device WA:
[0310] PersoWA: PkA, SkA, CIA=PkA, SIGN(SkI, PkA)
[0311] Step S20, applied to the WB device:
[0312] PersoWB: PkB, SkB, CIB=PkB, SIGN(SkI, PkB)
[0313] Step S30, applied to devices WB, WA:
[0314] Prepared Transfer
[0315] Step S40: “PCD_GEN”
[0316] (1) WB —> PCD —> USR —> WA
[0317] (2) WA -> PCD -> USR -> WB
[0318] (3) USR PCD WB, WA
[0319] Step S50, applied to the HD device:
[0320] Start Transfer
[0321] Step S60, executed by the HD device:
[0322] Connect WB
[0323] Step S101, executed by the HD device for the attention of the WB device:
[0324] Get Certificate
[0325] Step S103, executed by the WB device:
[0326] w = HASH384(PCD) mod n
[0327] Step S105, executed by the WB device:
[0328] ENC(w, CIB)
[0329] Step S107, executed by the device WB to the attention of the device HD:
[0330] Response to Get Certificate: ENC(w, CIB)
[0331] Step S109, executed by the HD device for the attention of the WB device:
[0332] Get Ephemeral Certificate
[0333] Step S311, executed by the WB device:
[0334] (SkeB, PkeB) = AsymKeyGen()
[0335] The WB device generates an ephemeral private key SkeB and an ephemeral public key PkeA using an asymmetric key generator.
[0336] Step S115, executed by the WB device:
[0337] SIGN(SkB, PkeB)
[0338] Step S117, executed by the WB device for the attention of the HD device:
[0339] Response to Get Ephemeral Certificate: PkeB, SIGN (SkB, PkeB)
[0340] Step SI 19, executed by the HD device for the attention of the USR device:
[0341] ConnectWA
[0342] Step S121, executed by the HD device for the attention of the WA device:
[0343] Verify Certificate ENC(w, CIB)
[0344] Step S123, executed by the device WA:
[0345] w = HASH384(PCD) mod n
[0346] Step S125, executed by the device WA:
[0347] DEC(w, ENC(w, CIB))
[0348] Step S127, executed by the device WA:
[0349] Verify(PkI, CIB)
[0350] Step S129, executed by the device WA for the attention of the device HD:
[0351] Success / Error
[0352] Step S131, executed by the HD device for the attention of the WA device:
[0353] Verify Ephemeral Certificate PkeB, SIGN(SkB, PkeB)
[0354] Step S133, executed by the device WA:
[0355] Verify(PkB, SIGN(SkB, PkeB)
[0356] Step S135, executed by the device WA for the attention of the device HD:
[0357] Success / Error
[0358] Step S137, executed by the HD device for the attention of the WA device:
[0359] Get Ephemeral Public Key
[0360] Step S339, executed by the device WA:
[0361] (SkeA, PkeA) = AsymKeyGen()
[0362] The WA device generates an ephemeral private key SkeA and an ephemeral public key PkeA using the asymmetric key generator.
[0363] Step S143, executed by the WA device for the attention of the HD device:
[0364] Response to Get Ephemeral Public Key: PkeA
[0365] Step S145, executed by the HD device for the attention of the WA device:
[0366] Get Transfer RPH
[0367] Step S347, executed by the device WA:
[0368] K = SkeA*PkeB
[0369] According to the Diffie-Hellman key exchange method based on elliptic curves, the WA device here generates a shared key K by calculating the scalar product of its ephemeral private key SkeA and the ephemeral public key PkeB of the WB device.
[0370] Step S348, executed by the device WA:
[0371] KelIKa = KDF(K)
[0372] The device WA calculates keys Ke and Ka from K and by means of the key derivation function KDF.
[0373] Step S349, executed by the device WA:
[0374] ENC-MAC(KellKa, RPH)
[0375] The device WA encrypts the recovery phrase RPH with the key Ke, using the encryption function ENC, and calculates a message authentication code with the key Ka and using a signature function MAC.
[0376] Step S359, executed by the WA device for the attention of the HD device:
[0377] Response to Get Transfer RPH: ENC-MAC(KellKa, RPH)
[0378] The WA device here transmits to HD the encrypted recovery phrase RPH, as well as the MAC authentication code.
[0379] Step S161, executed by the HD device for the attention of the USR device:
[0380] Connect WB
[0381] Step S163, executed by the HD device for the attention of the WB device:
[0382] Set Ephemeral Public Key: PkeA
[0383] Step S365, executed by the WB device:
[0384] K = SkeB*PkeA (=SkeA*PkeB)
[0385] The WB device here generates the shared key K by calculating the scalar product of its ephemeral private key SkeB and the ephemeral public key PkeA of the WA device.
[0386] Step S167, executed by the WB device for the attention of the HD device:
[0387] Success / Error
[0388] Step S369, executed by the HD device for the attention of the WB device:
[0389] Set transfer: ENC-MAC(KellKa, RPH)
[0390] The HD host device passes the encrypted RPH recovery phrase and the MAC authentication code to the WB device.
[0391] Step S371, executed by the WB device:
[0392] KelIKa = KDF(K)
[0393] The WB device calculates keys Ke and Ka from K and using the key derivation function KDF.
[0394] Step S373, executed by the WB device:
[0395] DEC-MAC(KellKa, ENC-MAC(KellKa, RPH))
[0396] The WA device decrypts the recovery phrase RPH with the key Ke, and verifies the MAC authentication code.
[0397] Step S181, executed by the WB device for the attention of the HD device:
[0398] Success / Error
[0399] It will be apparent to those skilled in the art that the method just described is susceptible to various other variations. Although initially designed to allow the transfer of a recovery phrase between two hardware wallets, the method is also susceptible to various applications for the transfer of other types of secret data between various types of devices.
Claims
Claims
1. Method for transferring secret data (RPH) from a first device (WA) to a second device (WB), in which each device comprises a secure processor (SP) comprising cryptographic calculation means, a secure memory (SMEM), and communication means (CINT), the method comprising the steps of: - provide (S 10, S20) to each device a private key (SkA, SkB), a public key (PkA, PkB), a public key (Pki) of a certification authority (ICA), a certificate (CIA, CIB) signed by the certification authority, the certificate comprising the public key of the device (PkA, PkB) and the signature (SIGN(SkI, PkA), SIGN(SkI, PkB)) of its public key by the certification authority, - provide (S40) the devices with a random process code (PCD) common to both devices, and by means of the first device (WA): - generate (S 123) an integer (w) which is a function of the process code (PCD), - define a first symmetric encryption key as equal to the integer (w) or generate it from the integer (w), - receiving (S107, S121, S221) the certificate (CIB) of the second device (WB) in an encrypted form (ENC(w, CIB)) by means of the first symmetric encryption key (w), - decrypt (S 125) the certificate (CIB) of the second device (WB) with the first symmetric encryption key (w), - using the public key (Pki) of the certification authority, verify (S 127) the authenticity of the certificate of the second device, to ensure that the second device is authorized by the certification authority (ICA) to receive the secret data, - receive (SI 17, S131, S217) an ephemeral public key (PkeB) from the second device (WB), - generate (S139-S141) an ephemeral public key (PkeA), - transmit (S143, S163, S263) the ephemeral public key (PkeA), - generate (S147-S149-S151, S347) a second symmetric encryption key (Ke) from the ephemeral public key (PkeB) of the second device (WB), - encrypt (S 157) the secret data (RPH) with the second key of symmetric encryption (Ke), and - transmit (S 159, S169, S269) the secret data (RPH) in its encrypted form (ENC(Ke, RPH) with the second symmetric encryption key (Ke).
2. Method according to claim 1, comprising the steps of, by means of the first device (WA): - receiving (S1 17, S131, S217) a signature (SIGN(SkB, PkeB)) of the ephemeral public key (PkeB) of the second device, generated by means of the private key (SkB) of the second device (WB), and - verifying (S133) the authenticity of the ephemeral public key (PkeB) of the second device (WB) by means of the public key (PkB) of the second device present in the certificate (CIB) of the second device, to ensure that the second device which issued the ephemeral public key is the same as the second device which issued the certificate.
3. Method according to one of claims 1 and 2, wherein the first device (WA) generates (S147-S149-S151) the second symmetric encryption key (Ke) from the ephemeral public key (PkeB) of the second device (WB) and the ephemeral public key (PkeA) of the first device (WA).
4. Method according to one of claims 1 and 2, wherein the first device (WA) generates (S347) the second symmetric encryption key (Ke) from the ephemeral public key (PkeB) of the second device (WB) and an ephemeral private key (SkeA) of the first device (WA).
5. Method according to one of claims 1 to 4, in which the first device (WA) generates (S139-S141) its ephemeral public key (PkeA) from the integer (w).
6. Method according to claim 1, comprising the steps of, by means of the second device (WB): - generating (S 103) the integer (w) which is a function of the process code (PCD), in the same manner as the first device (WA), - setting the first symmetric encryption key as being equal to the integer (w) or generating it from the integer (w), in the same manner as the first device (WA), - encrypting (S 105) the certificate (CIB) of the second device (WB) with the first symmetric encryption key (w), - transmitting (S 107, S207) the certificate (CIB) of the second device (WB) in its encrypted form (ENC(w, CIB)), - generating (SI 11, SI 13) the ephemeral public key (PkeB) of the second device (WB), - transmitting (SI 17, S131, S217) the ephemeral public key (PkeB) of the second device (WB), - receiving (S143, S163, S263) the ephemeral public key (PkeA) of the first device (WA), - generating (S 171, S173, S365) said second symmetric encryption key (Ke) from the ephemeral public key (PkeA) of the first device (WA), - receiving (S 159, S169, S269) the secret data (RPH) in said encrypted form (ENC(Ke, RPH) with the second symmetric encryption key (Ke), and - decrypting (S 179) the secret data (RPH) with the second symmetric encryption key (Ke) and store the secret data in the secure memory (SMEM).
7. Method according to claim 6, comprising the steps of, by means of the second device (WB): - signing (SI 15) the ephemeral public key (PkeB) of the second device by means of the private key (SkB) of the second device, and - transmitting (SI 17, S131, S217) the signature of the ephemeral public key (PkeB) of the second device.
8. Method according to one of claims 6 and 7, wherein the second device (WB) generates (S 171, S173) the second symmetric encryption key (Ke) from the ephemeral public key (PkeA) of the first device (WA) and the ephemeral public key (PkeB) of the second device (WB).
9. Method according to one of claims 6 and 7, wherein the second device (WB) generates (S365) the second symmetric encryption key (Ke) from the ephemeral public key (PkeA) of the first device (WA) and an ephemeral private key (SkeB) of the second device (WB).
10. Method according to one of claims 6 to 9, in which the second device (WB) generates (SI 11, SI 13) its ephemeral public key (PkeB) from the integer (w).
11. A method according to one of claims 1 to 10, wherein the step (S40) of providing the devices with a process code (PCD) is implemented according to one of the following two methods: - the first device (WA, RGEN) generates random data forming the process code (PCD) which is then provided to the second device (WB), or - the second device (WB, RGEN) generates random data forming the process code (PCD) which is then provided to the first device (WA) via a keyboard.
12. A method according to one of claims 1 to 11, wherein the first device (WA) and the second device (WB) do not communicate directly and are connected to a host device (HD), the method comprising the steps of, by means of the host device: - sequentially sending commands to one or other of the devices, - receiving data from each device in response to commands, and - transferring to each device data received from the other device in response to commands.
13. Method according to claim 12, comprising the steps of: - disconnecting the second device (WB) from the host device and connecting the first device (WA) to the host device, to allow the host device to exchange data with the first device (WA), and - disconnecting the first device (WA) from the host device and connecting the second device (WB) to the host device, to allow the host device to exchange data with the second device (WB).
14. Method according to one of claims 1 to 13, in which the first device (WA) and the second device (WB) are hardware wallets of cryptoassets.
15. Method according to one of claims 1 to 14, in which the secret data is a phrase (RPH) for recovering crypto-asset accounts.
16. Portable electronic device (WA) comprising a secure processor (SP) comprising cryptographic calculation means, a secure memory (SMEM), communication means (CINT), the secure memory comprising a private key (SkA), a public key (PkA), a public key (Pki) of a certification authority (ICA), a certificate (CIA) signed by the certification authority, the certificate comprising the public key (PkA) of the device and the signature (SIGN(SkI, PkA)) of the key public disclosure of the device by the certification authority, characterized in that it comprises a program (TAPI, TAP2) allowing it to transmit to an external device (WB) secret data (RPH) that the device holds in the secure memory, and in that it is configured to: - receive or generate (S40) a random process code (PCD) and store it, - generate (S 123) an integer (w) which is a function of the process code (PCD), - define a first symmetric encryption key as equal to the integer (w) or generate it from the integer (w), - receive (S107, S121, S221) an external certificate (CIB) in an encrypted form (ENC(w, CIB)) using the first symmetric encryption key (w), - decrypt (S 125) the external certificate (CIB) with the first symmetric encryption key (w), - using the public key (Pki) of the certification authority, verify (S127) the authenticity of the external certificate, to ensure that it is issued by a device (WB) authorized by the certification authority (ICA) to receive the secret data, - receive (SI 17, S131, S217) an external ephemeral public key (PkeB), - generate (S139-S141) an internal ephemeral public key (PkeA), - transmit (S143, S163, S263) the internal ephemeral public key (PkeA), - generate (S147-S149-S151, S347) a second symmetric encryption key (Ke) from the external ephemeral public key (PkeB), - encrypt (S 157) the secret data (RPH) with the second symmetric encryption key (Ke), and - transmit (S 159, S169, S269) the secret data (RPH) in its encrypted form (ENC(Ke, RPH) with the second symmetric encryption key (Ke).
17. Device according to claim 16, configured to - receive (SI 17, S131, S217) a signature (SIGN(SkB, PkeB)) of the external ephemeral public key (PkeB), - verify (S 133) the authenticity of the external ephemeral public key (PkeB) by means of the external public key (PkB) present in the external certificate (CIB), to ensure that a device which issued the key external ephemeral public is the same as a device that issued the external certificate.
18. Device according to one of claims 16 and 17, configured to generate (S147-S149-S151) the second symmetric encryption key (Ke) from the external ephemeral public key (PkeB) and the internal ephemeral public key (PkeA).
19. Device according to one of claims 16 to 18, configured to generate (S347) the second symmetric encryption key (Ke) from the external ephemeral public key (PkeB) and an internal ephemeral private key (SkeA).
20. Device according to one of claims 16 to 19, configured to generate (S139-S141) the internal ephemeral public key (PkeA) from the integer (w).
21. Device according to one of claims 16 to 20, configured to generate (S40) the random process code (PCD) and display it on a display means (DSP).
22. Device according to one of claims 16 to 21, forming a hardware wallet of cryptoassets.
23. Device according to one of claims 16 to 22, in which the secret data is a recovery phrase (RPH) of crypto-asset accounts.
24. Portable electronic device (WB) comprising a secure processor (SP) comprising cryptographic calculation means, a secure memory (SMEM), communication means (CINT), the secure memory comprising a private key (SkB), a public key (PkB), a public key (Pki) of a certification authority (ICA), a certificate (CIB) signed by the certification authority, the certificate comprising the public key (PkB) of the device and the signature (SIGN(SkI, PkB)) of the public key of the device by the certification authority, characterized in that it comprises a program (TAPI, TAP2) allowing it to receive external secret data (RPH), the device being configured to: - receive or generate (S40) a random process code (PCD) and store it, - generate (S 103) an integer (w) which is a function of the process code (PCD),- define a first symmetric encryption key as equal to the integer (w) or generate it from the integer (w), - encrypt (S 105) the certificate (CIB) with the first symmetric encryption key (w), - transmit (S 107, S207) the certificate (CIB) in its encrypted form (ENC(w, CIB)), - generate (SI 11, SI 13) an internal ephemeral public key (PkeB), - transmit (SI 17, S131, S217) the internal ephemeral public key (PkeB), - receive (S143, S163, S263) an external ephemeral public key (PkeA), - generate (S 171, S173, S365) a second symmetric encryption key (Ke) from the external ephemeral public key (PkeA), - receive (S 159, S169, S269) the external secret data (RPH) in an encrypted form (ENC(Ke, RPH) with the second encryption key symmetric (Ke), and - decrypt (S 179) the secret data (RPH) with the second symmetric encryption key (Ke) and store the secret data in the secure memory (SMEM).
25. Device according to claim 24, configured to sign (SI 15) the internal ephemeral public key (PkeB) by means of the private key (SkB), and transmit (SI 17, S131, S217) the signature of the ephemeral public key (PkeB).
26. Device according to one of claims 24 and 25, configured to generate (S 171, S173) the second symmetric encryption key (Ke) from the external ephemeral public key (PkeA) and the internal ephemeral public key (PkeB).
27. Device according to one of claims 24 and 25, configured to generate (S365) the second symmetric encryption key (Ke) from the external ephemeral public key (PkeA) and an internal ephemeral private key (SkeB).
28. Device according to one of claims 24 to 27, configured to generate (SI 11, SI 13) the internal ephemeral public key (PkeB) from the integer (w).
29. Device according to one of claims 24 to 28, configured to generate (S40) the random process code (PCD) and display it on a display means (DSP).
30. Device according to one of claims 24 to 29, forming a hardware wallet of cryptoassets.
31. Device according to one of claims 24 to 30, in which the data secret is a recovery phrase (RPH) for crypto-asset accounts.