Method for transferring a secret datum between two devices

Abstract

The invention relates to a method for transferring a secret datum (RPH) from a first device (WA) to a second device (WB), which comprises: providing each device with a random process code (PCD); generating an integer as a function of the process code (PCD); defining a first symmetric encryption key as a function of the integer; encrypting the certificate (CIB) of the second device with the first encryption key; transmitting the encrypted certificate (CIB) of the second device to the first device; generating an ephemeral public key; transmitting the ephemeral public key to the first device; receiving an ephemeral public key from the first device; generating a second symmetric encryption key from the ephemeral public key of the first device; receiving the secret datum (RPH) in a form encrypted with the second symmetric encryption key; and decrypting the secret datum (RPH).

Description

Method for transferring secret data between two devices.

[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", have emerged, 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 with cryptographic computing 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 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 (such as fire), or of losing the user's personal password to use them. The keys to the crypto-asset accounts they contain must therefore generally be stored in a secure location.

[0004] A first problem that arose in the past was to find a way to simplify the number of keys to be backed up, which could 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 each new key pair generated, a single backup for all the keys in their wallet being sufficient. This solution is now used by the majority of software or hardware crypto-asset wallets.

[0005] With a hierarchical deterministic wallet, all of the user's private keys are generated from a 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, above all, 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 2 256 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 using a standardized and reproducible process, such as applying a Password-Based Key Derivation Function 2 (PBKDF2) to the recovery phrase using a Keyed-Hash Message Authentication Code (HMAC) authentication function based on the SHA512 hash function, with a salt including the term "mnemonic" and an optional passphrase, and performing 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. However, saving the recovery phrase poses various security problems, 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 containing some of the words that make up the recovery phrase, then store 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 “Cryptosteel Capsule” 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 long. The outer casing and tiles are made of solid stainless steel to provide maximum durability to the recovery phrase. The capsule is fire, water and shock resistant.

[0013] Recently, the applicant has publicly proposed a new recovery phrase backup solution called "Ledger Recover", which is easier to implement than the aforementioned known solutions and 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 securely sent, 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 issue related to the recovery phrase arises when a user decides to upgrade their hardware wallet, for example, from an older model to a newer one. The plaintiff 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 to decide 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 (HSMs) that would authenticate the two hardware wallets. However, transporting a single block of the recovery phrase in a computer network appears risky in terms of security, and would not be accepted by the public. A process such as "Ledger Recover" could also be used. To this end, the recovery phrase would first be saved in several shares in backup servers, then restored in the new hardware wallet. However, this process involves steps for verifying the user's identity that 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 desirable 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, 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, setting a first symmetric encryption key as equal to the integer or generating it from the integer, receiving the certificate from the second device in an encrypted form using the first symmetric encryption key,decrypting the certificate of the second device with the first symmetric encryption key, using the public key of the certification authority, verifying 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, receiving an ephemeral public key from the second device, generating an ephemeral public key, transmitting the ephemeral public key, generating a second symmetric encryption key from the ephemeral public key of the second device, 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.,

[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: signing the ephemeral public key of the second device by means of the private key of the second device, and transmitting the signature of the ephemeral public key of the second device.

[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 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] In 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 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 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, receive an external ephemeral public key, generate an internal ephemeral public key, transmit the internal ephemeral public key, generate a second symmetric encryption key from the external ephemeral public key, 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.,

[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 outer ephemeral public key and the inner ephemeral public key.

[0036] According to one embodiment, the device is configured to generate the second symmetric encryption key from the outer ephemeral public key and an inner 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 device comprising a program enabling it to receive external secret data, 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,receiving 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 outer ephemeral public key and the inner ephemeral public key.

[0044] According to one embodiment, the device is configured to generate the second symmetric encryption key from the outer ephemeral public key and an inner 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 and other features of the present invention will be better understood upon reading the following description of embodiments of a method for transferring a recovery phrase between two hardware wallets, given without limitation in relation to the attached figures, among which:

[0050] - shows two hardware wallets of cryptoassets configured to exchange a recovery phrase according to a first embodiment of the method,

[0051] - is a sequence diagram of the first embodiment of the method,

[0052] - describes the steps of the sequence diagram of the,

[0053] - shows two hardware wallets of cryptoassets configured to exchange a recovery phrase according to a second embodiment of the method,

[0054] - is a sequence diagram of the second embodiment of the method,

[0055] - describes the steps of the sequence diagram of the,

[0056] - is a sequence diagram of a third embodiment of the recovery phrase exchange method implemented with the hardware wallets of the,

[0057] - describes the steps in the sequence diagram. Detailed description

[0058] The invention provides a method for creating a cryptoasset wallet that offers a unique feature in the field of hardware wallets, namely a feature for transferring the recovery phrase to another hardware wallet that is automated while being highly secure. Such a method allows users to avoid all the difficulties associated with having to manually transfer the recovery phrase to a new hardware wallet.

[0059] The diagram shows the classic 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 operating system OS of the secure processor, 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 transfer application program TAP1 (“Transfer Application”) provided to implement this method.

[0060] In the embodiment shown in the, the WA, WB devices 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 AP and a companion program CAP such as the “Ledger Live” software marketed by the applicant. Such a configuration corresponds to the most commonly 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 WA device is for example a Ledger NanoX and the WB device 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 completes the TAP1 program executed by each device WA, WB and establishes a deferred-time communication link between the two devices WA, WB, as will be seen later.

[0061] In the example shown in the figure, the WA device holds the keys to the crypto-asset accounts of a USR user, including the recovery phrase RPH that we wish to transfer to the WB device. The mere transfer of this phrase will allow the WB device to retrieve the private and public keys of all the crypto-asset accounts associated with it.

[0062] Figures 2 and 3 describe an embodiment of the method according to the invention for carrying out such a transfer. The different steps shown in these figures are described below.

[0063] Step S10, applied to the WA device:

[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 limiting and includes the embodiment where the key(s) considered is(are) created locally by each device WA, WB. The certificate CIA, CIB comprises 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 by means of its private key SkI.These keys are strictly confidential and are stored in the non-volatile part of the SMEM secure memory of each device.

[0068] Step S30, applied to WB, WA devices:

[0069] Prepare Transfer

[0070] The USR user activates the TAP1 application in each WB and WA device, and configures the WA and WB devices by indicating to the WB device that it is the recovery phrase recipient and to the WA device that it is the recovery phrase giver. The user also activates the TAPHS transfer application in the HD host device.

[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 comes in 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 random generator RGEN, stores it and displays it to the user USR on its DSP screen. The user reads the PCD process code and provides it to the WA device via the KBD keyboard of the WA device, which stores the code.

[0077] (2) The WA device generates the PCD process code by means of the random generator 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 USR user generates the PCD process code, for example by means of an external random code generator, and then provides the PCD code to the WB device and the 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 issue 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 will prompt 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 asks the WB device to provide its certificate

[0088] Step S103, executed by the WB device:

[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 SECP384R1 elliptic curve, n is equal to:

[0091] 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC7634D81F4372DDF581A0DB248B0A77AECEC196ACCC52973,

[0092] Cf. Standards for Efficient Cryptography - SEC 2: Recommended Elliptic Curve Domain Parameters - Certicom Research - January 27, 2010 - Version 2.0 - https: / www.secg.org / sec2-v2.pdf.

[0093] Step S105, executed by the WB device:

[0094] ENC(w, CIB)

[0095] The WB device encrypts the CIB certificate using the number w as an encryption key, using a symmetric encryption function, for example the AES (Advanced Encryption Standard) function. Alternatively, an encryption key w' different from the number w may be derived therefrom and used for this operation.

[0096] Step S107, executed by the WB device for the attention of the HD device:

[0097] Response to Get Certificate: ENC(w, CIB)

[0098] In response to the command, the result of the CIB certificate encryption is now sent to the HD host device, which stores it.

[0099] Step S109, executed by the HD device for the attention of the WB device:

[0100] Get Ephemeral Certificate

[0101] The host device HD here sends the following command from the list of commands to the WB device. This command requests 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 request 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.

[0102] Step S111, executed by the WB device:

[0103] X=x*P

[0104] 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 allowing the generation of 384-bit words, X being a point of the curve, the operation x*P being scalar multiplication.

[0105] Step S113, executed by the WB device:

[0106] PkeB=w*M + X

[0107] The WB device then generates an ephemeral public key PkeB by performing the dot 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 RFC 9382 - Spake2 - September 2023 - ISSN 2070-1721 - W. Ladd - https: / www.rfc-editor.org / rfc / rfc9382.html.

[0108] 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].

[0109] Step S115, executed by the WB device:

[0110] SIGN(SkB, PkeB)

[0111] 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.

[0112] Step S117, executed by the WB device for the attention of the HD device:

[0113] Response to Get Ephemeral Certificate: PkeB, SIGN(SkB, PkeB)

[0114] 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.

[0115] Step S119, executed by the HD device for the USR device:

[0116] Connect WA

[0117] 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.

[0118] Step S121, executed by the HD device for the attention of the WA device:

[0119] Verify Certificate ENC(w, CIB)

[0120] During this step, the HD host device passes the CIB certificate of the WB device to the WA device and asks it to verify it.

[0121] Step S123, executed by the WA device:

[0122] w=HASH384(PCD) mod n

[0123] For this purpose, the WA device in turn calculates the number w from the PCD process code.

[0124] Step S125, executed by the WA device:

[0125] DEC(w, ENC(w, CIB))

[0126] Once w is calculated, the WA device can decrypt the WB device's certificate using the number w as the decryption key and a decryption function DEC corresponding to the encryption function ENC.

[0127] Step S127, executed by the WA device:

[0128] Verify(PkI, CIB)

[0129] Once the CIB certificate is decrypted (CIB=PkB, SIGN(SkI, PkB)), the WA device verifies that this certificate has an authentic signature, using the PkI public key of the certification authority.

[0130] Step S129, executed by the WA device for the attention of the HD device:

[0131] Success / Error

[0132] The WA device is now able to respond to the previously received "Verify Certificate" command and returns a success or error message. If the certificate authenticity is verified, this confirms that the second WB device is authorized by the ICA certificate authority to receive the recovery phrase,

[0133] Step S131, executed by the HD device for the attention of the WA device:

[0134] Verify Ephemeral Certificate PkeB, SIGN(SkB, PkeB)

[0135] The host device HD now asks the WA device to verify the ephemeral certificate of the WB device including the ephemeral public key and its signature using the private key SkB.

[0136] Step S133, executed by the WA device:

[0137] Verify(PkB, SIGN(SkB, PkeB)

[0138] The WA device, which previously obtained, after decrypting the CIB certificate, the PkB public key of the WB device present in this certificate, can now verify that the signature of the ephemeral PkeB public key present in the ephemeral certificate is correct, using the PkB public key.

[0139] Step S135, executed by the WA device for the attention of the HD device:

[0140] Success / Error

[0141] The WA device confirms the success of the verification step. In case of error the process is interrupted.

[0142] Step S137, executed by the HD device for the attention of the WA device:

[0143] Get Ephemeral Public Key

[0144] The HD host device now asks the WA device to provide it with an ephemeral public key.

[0145] Step S139, executed by the WA device:

[0146] Y=y*P

[0147] To begin, the WA device 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 SECP384R1 curve, Y being a point of the curve P.

[0148] Step S141, executed by the WA device:

[0149] PkeA=w*N + Y

[0150] 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]

[0151] Step S143, executed by the WA device for the attention of the HD device:

[0152] Response to Get Ephemeral Public Key: PkeA

[0153] The WA device here responds to the previously received command by sending the host device HD the ephemeral public key PkeA that it has just generated.

[0154] Step S145, executed by the HD device for the attention of the WA device:

[0155] Get Transfer RPH

[0156] The HD host device now asks the WA device to transfer the RPH recovery phrase to it

[0157] Step S147, executed by the WA device:

[0158] K=y*(PkeB-w*N)

[0159] Following this command, the WA device first calculates a shared secret K using the above formula, which involves the y part of its private key, the number w, the constant N and the ephemeral key PkeB of the WB device.

[0160] Step S149, executed by the WA device:

[0161] TT=len(A)||A||len(B)||B||len(PkeB)|PkeB||len(PkeA)||PkeA

[0162] ||len(K)||K||len(w)||w

[0163] 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 put 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 TT calculation. In one embodiment, the string len(A)||A||len(B) ||B|| 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.

[0164] Step S151, executed by the WA device:

[0165] Ke||Ka=HASH(TT)

[0166] In this step, the WA device generates a binary string, for example 512 bits, forming two keys Ke and Ka, for example 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 encrypted transfer of the recovery phrase RPH while the key Ka will be used for the derivation of two keys KcA, KcB.

[0167] Step S153, executed by the WA device:

[0168] KcA||KcB=KDF(Ka, “ConfirmationKeys”||AAD)

[0169] In 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 string. Generally, any other consensus-defined 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.

[0170] Step S155, executed by the WA device:

[0171] cB=MAC(KcB, TT)

[0172] 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 algorithm ("Keyed Hash Message Authentication Code") or CMAC ("Cipher-based Message Authentication Code").

[0173] 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 encryption key Ke of the recovery phrase RPH to be transmitted, to which the code cB may optionally be attached.

[0174] Step S157, executed by the WA device:

[0175] ENC(Ke, RPH)

[0176] In this step, the WA device encrypts the recovery phrase RPH using the shared secret Ke used as the encryption key. The ENC encryption algorithm can, as before, be, for example, an AES (“Advanced Encryption Standard”) function.

[0177] Step S159, executed by the WA device for the attention of the HD device:

[0178] Response to Get Transfer RPH: ENC(Ke, RPH), cB

[0179] In response to the previously received command, the WA device therefore transmits the encrypted recovery phrase RPH to the host device HD, as well as, optionally, the confirmation code cB.

[0180] Step S161, executed by the HD device for the USR device:

[0181] Connect WB

[0182] 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.

[0183] Step S163, executed by the HD device for the attention of the WB device:

[0184] Set Ephemeral Public Key: PkeA

[0185] 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.

[0186] Step S165, executed by the WB device:

[0187] K=x*(PkeA-w*M)

[0188] The WB device calculates the shared secret K using the x part of its private key, the ephemeral key PkeA of the WA device and the constant M.

[0189] Step S167, executed by the WB device for the attention of the HD device:

[0190] Success / Error

[0191] This response message can be optionally provided in application of a rule according to which every command must be followed by a response, the role of which is at least to confirm the correct receipt of the command.

[0192] Step S169, executed by the HD device for the attention of the WB device:

[0193] Set transfer: ENC(Ke, RPH), cB

[0194] During this step, the host device HD passes on to the WB device the encrypted recovery phrase RPH as well as, optionally, the confirmation data cB.

[0195] Step S171, executed by the WB device:

[0196] TT=len(A)||A||len(B)||B||len(PkeB)|PkeB||len(PkeA)||PkeA

[0197] ||len(K)||K||len(w)||w

[0198] As the WA device did previously, the WB device here calculates the TT transcript.

[0199] Step S173, executed by the WB device:

[0200] Ke||Ka=HASH(TT)

[0201] As the WA device did previously, the WB device here generates the keys Ke and Ka.

[0202] Step S175, executed by the WB device:

[0203] KcA||KcB=KDF(Ka, “ConfirmationKeys”||AAD)

[0204] As the WA device did previously, the WB device here calculates keys KcA and KcB.

[0205] Step S177, executed by the WB device:

[0206] cB=MAC(KcB, TT)

[0207] As the WA device did previously, the WB device here calculates the authentication code cB.

[0208] Step S179, executed by the WB device:

[0209] DEC(Ke, ENC(Ke, RPH))=RPH

[0210] The WB device here decrypts the recovery phrase RPH using the key Ke and the decryption function DEC, and then stores it in its secure memory.

[0211] Step S181, executed by the WB device for the attention of the HD device:

[0212] Success / Error

[0213] 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 on the WA device.

[0214] 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 hardware wallet function is implemented by software ("software wallet") or by means of a secure element integrated into the mobile phone.

[0215] Figures 5 and 6 which describe an embodiment of the method for transferring the recovery phrase without going through the host device. 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.

[0216] Step S10, applied to the WA device:

[0217] PersoWA: PkA, SkA, CIA=PkA, SIGN(SkI, PkA)

[0218] Step S20, applied to the WB device:

[0219] PersoWB: PkB, SkB, CIB=PkB, SIGN(SkI, PkB)

[0220] Step S31 applied to WB, WA devices:

[0221] Prepare Transfer

[0222] 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.

[0223] Step S40 “PCD_GEN”, generation of the PCD code according to one of the three variants mentioned above:

[0224] (1) WB → PCD → USR → WA

[0225] (2) WA → PCD → USR → WB

[0226] (3) USR → PCD → WB, WA

[0227] Step S51, applied to devices WA, WB:

[0228] Start Transfer

[0229] 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 communication between the two devices.

[0230] Step S201 executed by device WA for device WB:

[0231] Get Certificate

[0232] The WA device requests the WB device to communicate its CIB certificate. 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.

[0233] Step S103 executed by the WB device:

[0234] w = HASH384(PCD) mod n

[0235] Step S105 executed by the WB device:

[0236] ENC(w, CIB)

[0237] Step S207 executed by the WB device for the attention of the WA device:

[0238] Response to Get Certificate: ENC(w, CIB)

[0239] This step corresponds to the combination of steps S107, S121 previously described, since the host device no longer acts as an intermediary.

[0240] Step S123 executed by the WA device:

[0241] w = HASH384(PCD) mod n

[0242] Step S125 executed by the WA device:

[0243] DEC(w, ENC(w, CIB))

[0244] Step S127 executed by device WA:

[0245] Verify(PkI, CIB)

[0246] Step S209 executed by device WA for device WB:

[0247] Get Ephemeral Certificate

[0248] 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.

[0249] Step S111 executed by the WB device:

[0250] X = x*P

[0251] Step S113 executed by the WB device:

[0252] PkeB = w*M + X

[0253] Step S115 executed by the WB device:

[0254] SIGN(SkB, PkeB)

[0255] Step S217 executed by the WB device for the attention of the WA device:

[0256] Response to Get Ephemeral Certificate: PkeB, SIGN(SkB, PkeB)

[0257] This step corresponds to the combination of steps S117, S131 previously described.

[0258] Step S133 executed by device WA:

[0259] Verify(PkB, SIGN(SkB, PkeB)

[0260] 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. Since the WA device has 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.

[0261] Step S235 executed by device WA for device WB:

[0262] Success / Error

[0263] This response is identical to the response of step S135 previously described, but is sent directly to the WA device since the host device is no longer acting as a high-level intermediary.

[0264] Step S139 executed by device WA:

[0265] Y = y*P

[0266] Step S141 executed by the WA device:

[0267] PkeA = w*N + Y

[0268] Step S243 executed by device WA for device WB:

[0269] Set ephemeral public key: PkeA

[0270] This step corresponds to the combination of steps S143, S163 previously described.

[0271] Step S165 executed by the WB device:

[0272] K = x*(PkeA - w*M)

[0273] Step S266 executed by the WB device for the attention of the WA device:

[0274] Success / Error

[0275] The WB device here confirms to the WA device that it has finished its calculation.

[0276] Step S147 executed by device WA:

[0277] K = y*(PkeB - w*N)

[0278] Step S149 executed by device WA:

[0279] TT=len(A)||A||len(B)||B||len(PkeB)|PkeB||len(PkeA)||PkeA

[0280] ||len(K)||K||len(w)||w

[0281] Step S151 executed by the WA device:

[0282] Ke||Ka = HASH(TT)

[0283] Step S153 executed by the WA device:

[0284] KcA||KcB = KDF(Ka, “ConfirmationKeys”||AAD)

[0285] Step S155 executed by the WA device:

[0286] cB=MAC(KcB, TT)

[0287] Step S157 executed by the WA device:

[0288] ENC(Ke, RPH)

[0289] Step S259 executed by device WA for device WB:

[0290] Set transfer: ENC(Ke, RPH), cB

[0291] This step by which the WA device sends to the WB device the encrypted recovery phrase RPH as well as, optionally, the code cB, corresponds to the combination of steps S159, S169 previously described.

[0292] Step S171 executed by the WB device:

[0293] TT=len(A)||A||len(B)||B||len(PkeB)|PkeB||len(PkeA)||PkeA

[0294] ||len(K)||K||len(w)||w

[0295] Step S173 executed by the WB device:

[0296] Ke||Ka = HASH(TT)

[0297] Step S175 executed by the WB device:

[0298] KcA||KcB = KDF(Ka, “ConfirmationKeys”||AAD)

[0299] Step S177 executed by the WB device:

[0300] cB=MAC(KcB, TT)

[0301] Step S179 executed by the WB device:

[0302] DEC(Ke, ENC(Ke, RPH)) = RPH

[0303] Step S281 executed by the WB device for the attention of the WA device:

[0304] Success / Error

[0305] This response is identical to the response sent in step S181 previously described but is sent directly to the device WA.

[0306] 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. As an 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 previously described steps will be mentioned but will not be described again.

[0307] Step S10, applied to the WA device:

[0308] PersoWA: PkA, SkA, CIA=PkA, SIGN(SkI, PkA)

[0309] Step S20, applied to the WB device:

[0310] PersoWB: PkB, SkB, CIB=PkB, SIGN(SkI, PkB)

[0311] Step S30, applied to WB, WA devices:

[0312] Prepare Transfer

[0313] Step S40: “PCD_GEN”

[0314] (1) WB → PCD → USR → WA

[0315] (2) WA → PCD → USR → WB

[0316] (3) USR → PCD → WB, WA

[0317] Step S50, applied to the HD device:

[0318] Start Transfer

[0319] Step S60, executed by the HD device:

[0320] Connect WB

[0321] Step S101, executed by the HD device for the attention of the WB device:

[0322] Get Certificate

[0323] Step S103, executed by the WB device:

[0324] w = HASH384(PCD) mod n

[0325] Step S105, executed by the WB device:

[0326] ENC(w, CIB)

[0327] Step S107, executed by the WB device for the attention of the HD device:

[0328] Response to Get Certificate: ENC(w, CIB)

[0329] Step S109, executed by the HD device for the attention of the WB device:

[0330] Get Ephemeral Certificate

[0331] Step S311, executed by the WB device:

[0332] (SkeB, PkeB ) = AsymKeyGen()

[0333] The WB device generates an ephemeral private key SkeB and an ephemeral public key PkeA using an asymmetric key generator.

[0334] Step S115, executed by the WB device:

[0335] SIGN(SkB, PkeB)

[0336] Step S117, executed by the WB device for the attention of the HD device:

[0337] Response to Get Ephemeral Certificate: PkeB, SIGN(SkB, PkeB)

[0338] Step S119, executed by the HD device for the USR device:

[0339] Connect WA

[0340] Step S121, executed by the HD device for the attention of the WA device:

[0341] Verify Certificate ENC(w, CIB)

[0342] Step S123, executed by the WA device:

[0343] w = HASH384(PCD) mod n

[0344] Step S125, executed by the WA device:

[0345] DEC(w, ENC(w, CIB))

[0346] Step S127, executed by the WA device:

[0347] Verify(PkI, CIB)

[0348] Step S129, executed by the WA device for the attention of the HD device:

[0349] Success / Error

[0350] Step S131, executed by the HD device for the attention of the WA device:

[0351] Verify Ephemeral Certificate PkeB, SIGN(SkB, PkeB)

[0352] Step S133, executed by the WA device:

[0353] Verify(PkB, SIGN(SkB, PkeB)

[0354] Step S135, executed by the WA device for the attention of the HD device:

[0355] Success / Error

[0356] Step S137, executed by the HD device for the attention of the WA device:

[0357] Get Ephemeral Public Key

[0358] Step S339, executed by the WA device:

[0359] (SkeA, PkeA ) = AsymKeyGen()

[0360] The WA device generates an ephemeral private key SkeA and an ephemeral public key PkeA using the asymmetric key generator.

[0361] Step S143, executed by the WA device for the attention of the HD device:

[0362] Response to Get Ephemeral Public Key: PkeA

[0363] Step S145, executed by the HD device for the attention of the WA device:

[0364] Get Transfer RPH

[0365] Step S347, executed by the WA device:

[0366] K = SkeA*PkeB

[0367] According to the elliptic curve-based Diffie-Hellman key exchange method, the WA device here generates a shared key K by calculating the dot product of its ephemeral private key SkeA and the ephemeral public key PkeB of the WB device.

[0368] Step S348, executed by the WA device:

[0369] Ke||Ka = KDF(K)

[0370] The WA device calculates keys Ke and Ka from K and using the key derivation function KDF.

[0371] Step S349, executed by the WA device:

[0372] ENC-MAC(Ke||Ka, RPH)

[0373] The WA device 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.

[0374] Step S359, executed by the WA device for the attention of the HD device:

[0375] Response to Get Transfer RPH: ENC-MAC(Ke||Ka, RPH)

[0376] The WA device here transmits to HD the encrypted RPH recovery phrase, along with the MAC authentication code.

[0377] Step S161, executed by the HD device for the USR device:

[0378] Connect WB

[0379] Step S163, executed by the HD device for the attention of the WB device:

[0380] Set Ephemeral Public Key: PkeA

[0381] Step S365, executed by the WB device:

[0382] K = SkeB*PkeA (=SkeA*PkeB)

[0383] 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.

[0384] Step S167, executed by the WB device for the attention of the HD device:

[0385] Success / Error

[0386] Step S369, executed by the HD device for the attention of the WB device:

[0387] Set transfer: ENC-MAC(Ke||Ka, RPH)

[0388] The HD host device echoes the encrypted RPH recovery phrase and MAC authentication code to the WB device.

[0389] Step S371, executed by the WB device:

[0390] Ke||Ka = KDF(K)

[0391] The WB device calculates keys Ke and Ka from K and using the key derivation function KDF.

[0392] Step S373, executed by the WB device:

[0393] DEC-MAC(Ke||Ka, ENC-MAC(Ke||Ka, RPH))

[0394] The WA device decrypts the recovery phrase RPH with the key Ke, and verifies the MAC authentication code.

[0395] Step S181, executed by the WB device for the attention of the HD device:

[0396] Success / Error

[0397] 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 enable 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

A method for transferring secret data (RPH) from a first device (WA) to a second device (WB), wherein 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:- providing (S10, 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,- providing (S40) to the devices a random process code (PCD) common to both devices, andby means of the first device (WA):- generating (S123) an integer (w) which is a function of the process code (PCD),- defining a first symmetric encryption key as being equal to the integer (w) or generating it from the integer (w),- receiving (S107, S121,S221) the certificate (CIB) of the second device (WB) in an encrypted form (ENC(w, CIB)) using the first symmetric encryption key (w),- decrypt (S125) 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 (S127) 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 (S117, S131, S217) an ephemeral public key (PkeB) of 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 (S157) the secret data (RPH) with the second symmetric encryption key (Ke),and- transmit (S159, S169, S269) the secret data (RPH) in its encrypted form (ENC(Ke, RPH) with the second symmetric encryption key (Ke)., Method according to claim 1, comprising the steps of, by means of the first device (WA):- receiving (S117, 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. Method according to one of claims 1 and 2, in which 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), the ephemeral public key (PkeA) of the first device (WA) and the integer (w). Method according to one of claims 1 and 2, in which 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). 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). Method according to claim 1, comprising the steps of, by means of the second device (WB):- generating (S103) 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 (S105) the certificate (CIB) of the second device (WB) with the first symmetric encryption key (w),- transmitting (S107, S207) the certificate (CIB) of the second device (WB) in its encrypted form (ENC(w, CIB)),- generating (S111, S113) the ephemeral public key (PkeB) of the second device (WB),- transmitting (S117, 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),- generate (S171, S173,S365) said second symmetric encryption key (Ke) from the ephemeral public key (PkeA) of the first device (WA),- receive (S159, S169, S269) the secret data (RPH) in said encrypted form (ENC(Ke, RPH) with the second symmetric encryption key (Ke), and- decrypt (S179) the secret data (RPH) with the second symmetric encryption key (Ke) and store the secret data in the secure memory (SMEM)., Method according to claim 6, comprising the steps of, by means of the second device (WB):- signing (S115) the ephemeral public key (PkeB) of the second device by means of the private key (SkB) of the second device, and- transmitting (S117, S131, S217) the signature of the ephemeral public key (PkeB) of the second device. Method according to one of claims 6 and 7, in which the second device (WB) generates (S171, S173) the second symmetric encryption key (Ke) from the ephemeral public key (PkeA) of the first device (WA), the ephemeral public key (PkeB) of the second device (WB) and the integer (w). Method according to one of claims 6 and 7, in which 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). Method according to one of claims 6 to 9, in which the second device (WB) generates (S111, S113) its ephemeral public key (PkeB) from the integer (w). Method according to one of claims 1 to 10, in which 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. 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 the 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. The method of 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 enable 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 enable the host device to exchange data with the second device (WB). Method according to one of claims 1 to 13, in which the first device (WA) and the second device (WB) are hardware wallets of crypto assets. Method according to one of claims 1 to 14, in which the secret data is a phrase (RPH) for recovering crypto-asset accounts. 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, characterized in that it comprises a program (TAP1, TAP2) allowing it to transmit to an external device (WB) a secret data item (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 (S123) an integer (w) which is a function of the process code (PCD),- define a first symmetric encryption key as being 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 (S125) 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 (S117, 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 (S157) the secret data (RPH) with the second symmetric encryption key (Ke), and- transmit (S159, S169,S269) the secret data (RPH) in its encrypted form (ENC(Ke, RPH) with the second symmetric encryption key (Ke)., Device according to claim 16, configured to- receive (S117, S131, S217) a signature (SIGN(SkB, PkeB)) of the external ephemeral public key (PkeB),- verify (S133) 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 external ephemeral public key is the same as a device which issued the external certificate. 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), the internal ephemeral public key (PkeA) and the integer (w). 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). Device according to one of claims 16 to 19, configured to generate (S139-S141) the internal ephemeral public key (PkeA) from the integer (w). 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). Device according to one of claims 16 to 21, forming a hardware wallet of cryptoassets. Device according to one of claims 16 to 22, in which the secret data is a recovery phrase (RPH) of crypto-asset accounts. 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, characterized in that it comprises a program (TAP1, TAP2) allowing it to receive an external secret data item (RPH), the device being configured to:- receive or generate (S40) a random process code (PCD) and store it,- generate (S103) an integer (w) which is a function of the process code (PCD),- define a first symmetric encryption key as being equal to the integer (w) or generate it from the integer (w),- encrypt (S105) the certificate (CIB) with the first symmetric encryption key (w),- transmit (S107,S207) the certificate (CIB) in its encrypted form (ENC(w, CIB)),- generate (S111, S113) an internal ephemeral public key (PkeB),- transmit (S117, S131, S217) the internal ephemeral public key (PkeB),- receive (S143, S163, S263) an external ephemeral public key (PkeA),- generate (S171, S173, S365) a second symmetric encryption key (Ke) from the external ephemeral public key (PkeA),- receive (S159, S169, S269) the external secret data (RPH) in an encrypted form (ENC(Ke, RPH) with the second symmetric encryption key (Ke), and- decrypt (S179) the secret data (RPH) with the second symmetric encryption key (Ke) and store secret data in secure memory (SMEM)., Device according to claim 24, configured to sign (S115) the internal ephemeral public key (PkeB) using the private key (SkB), and transmit (S117, S131, S217) the signature of the ephemeral public key (PkeB). Device according to one of claims 24 and 25, configured to generate (S171, S173) the second symmetric encryption key (Ke) from the external ephemeral public key (PkeA), the internal ephemeral public key (PkeB) and the integer (w). 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). Device according to one of claims 24 to 27, configured to generate (S111, S113) the internal ephemeral public key (PkeB) from the integer (w). 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). Device according to one of claims 24 to 29, forming a hardware wallet of cryptoassets. Device according to one of claims 24 to 30, in which the secret data is a recovery phrase (RPH) of crypto-asset accounts.

Images