Method for backing up and recovering secrets held by encrypted asset wallets

Abstract

A method for backing up and restoring a secret (S) held by an encrypted asset wallet (CW1), the method comprising the steps of: providing a plurality of backup servers (BCKi) for backing up the secret; collecting information about the identity of the user (BCKDT); communicating the information relating to the identity of the user to each backup server; generating a plurality of secret data (Si) from the secret (S) by means of the encrypted asset wallet; and transmitting one of the secret data provided by the encrypted asset wallet in encrypted form to each backup server, and associating the secret data in the backup server with the identity of the user.

Description

Technical Field

[0001] The present invention relates to a method for backing up and restoring secrets held by an electronic device, and a method for ensuring the backup and restoration of secrets held by an electronic device. The present invention also relates to ensuring a secure data connection between an electronic device and a server. In particular, the present invention relates to a hierarchical deterministic hardware wallet for storing private keys used to manage accounts on a blockchain. Background Art

[0002] In recent years, the development of cryptocurrencies or other types of blockchain-managed crypto assets, such as non-fungible tokens (NFTs) and smart contracts, has led to the emergence of various ways to store and safeguard the private and public keys associated with these different types of crypto assets. This has led to the emergence of crypto asset wallets capable of storing and safeguarding these keys. A crypto asset wallet is a hardware or software device whose function is to store the private and public keys associated with a crypto asset account and use these keys to sign transactions. There is a distinction between "hot wallets" and "cold wallets." "Hot wallets" are connected to the internet and are vulnerable to hacking or exposure to viruses and malware. These wallets can be managed by a centralized exchange platform or program installed on a mobile phone, tablet, or personal computer ("software wallets"). Such wallets are connected to the internet and are therefore themselves vulnerable to attacks. On the other hand, "cold wallets," or hardware wallets, do not have direct access to the internet, which reduces the attack surface and, therefore, the risk of hacking. Hardware wallets are typically portable electronic devices equipped with a processor with cryptographic computing capabilities. Transactions involving private keys are signed in an offline environment. Any online transaction is temporarily transferred to a hardware wallet for offline digital signing before the signature is sent to the online network. Since the private keys are not communicated to the online server during the signing process, hackers cannot access them.

[0003] As a result, this type of hardware wallet is now considered the most secure solution against hacker attacks. The only drawback is the risk of the hardware wallet being lost, stolen, or destroyed (e.g., by fire), or the user's personal password that allows its use being lost. Therefore, the keys contained in the hardware wallet should usually be backed up in a safe place.

[0004] The first problem that arose in the past was finding a way to simplify the number of keys to back up, which could be quite large if a user has many crypto-asset accounts on the blockchain. To address this, Bitcoin proposed a hierarchical deterministic wallet. First proposed in the BIP32 standard and then refined in the BIP39, BIP43, and BIP44 standards, this hierarchical deterministic wallet eliminates the need to create a new backup for each new key pair generated; a single backup of all the keys in their wallet is sufficient. This solution is now used by the vast majority of software and hardware crypto-asset wallets.

[0005] With a hierarchical deterministic wallet, all of a user's private keys are generated from an original random seed, or "master key." The user only needs to keep the seed in a safe place to recover all of their keys that are derived from and reconstructable from the seed ("child keys").

[0006] To facilitate memorization and storage of seeds, the BIP39 standard also specifies that seeds be expressed in the form of a mnemonic phrase (also known as a "recovery phrase"), which is a long binary number. The exact type of BIP39 seed currently used in applicant's devices is a recovery phrase consisting of 24 words selected from a list of 2048 words defined by the above standard.

[0007] To generate the recovery phrase, the hardware wallet uses a random number generator to create a sequence of 256 random bits. The first 8 bits of the initial 256-bit SHA-256 hash are added to this bit string, providing 264 bits. The device divides these 264 bits into 24 groups of 11 bits each. Each group of 11 bits is interpreted as a number between 0 and 2047, which is used as an index into the BIP39 word list, resulting in a 24-word mnemonic phrase. Therefore, this type of wallet preferably only requires a single backup of the seed from which the entire descending key tree can be derived when it is enabled.

[0008] Figure 1 A crypto-asset wallet is schematically illustrated, comprising a hardware wallet HW (e.g., a device marketed by the applicant under the names "Nano" or "Stax") and a host device HDV executing a companion application HSW (e.g., the "Ledger Live" application developed by the applicant). Because the HW device cannot directly connect to the internet, it is associated with the host device HDV to perform transactions on the blockchain. The host device HDV is, for example, a computer, mobile phone, tablet, or equivalent. The connection between the HW device and the host device HDV can be achieved, for example, via USB or Bluetooth.

[0009] Once connected to a host device, the device HW interacts with supporting software to allow the user (USR) to execute transactions on the blockchain (BCN) or on decentralized exchanges. The device HW also communicates with a hardware security module (HSM) located in a data center. The HSM module is typically a hardware cryptographic device that allows for the generation, storage, and protection of cryptographic keys. The HSM module does not store any of the user's private keys and only ensures control over the following: the authenticity of the device HW, device activation, updates to the device's operating system, the download of authorized applications, and so on.

[0010] When the device HW is first enabled, the device provides the user with a 24-word recovery phrase, which the user will have to save on a suitable physical medium, such as a piece of paper or an unalterable medium such as an engraved metal plate, which the user will store in a safe place.

[0011] Keeping the recovery phrase in a safe place is not without its problems. In fact, if a third party gets hold of the recovery phrase, they will be able to access all the user's crypto-asset accounts generated from the seed and transfer the total amount contained in these crypto-asset accounts to other accounts, making it very difficult to identify the third party.

[0012] Therefore, it is desirable to provide users with a simple and practical way to keep their recovery phrases in a highly secure manner. Summary of the Invention

[0013] The present invention relates to a method for backing up and restoring secrets held by a crypto-asset wallet. To back up the secrets, the method comprises the following steps: providing a plurality of backup servers; collecting information related to a user's identity; communicating the information related to the user's identity to each backup server; generating a plurality of secret data from the secret by the crypto-asset wallet; and transmitting one of the secret data provided by the crypto-asset wallet to each backup server in an encrypted form, and associating the secret data with the user's identity in the backup server.

[0014] According to one embodiment, each encrypted data is encrypted using an encryption key that is known only to the crypto-asset wallet and the backup server to which the encrypted data is intended.

[0015] According to one embodiment, the information related to the identity of the user includes at least the user's first name, last name and date of birth.

[0016] According to one embodiment, the crypto-asset wallet is configured to generate a plurality of secret data by a secret sharing function, the secret sharing function being designed to generate m secret data from the secret and allowing reconstruction of the secret from a threshold n secret data.

[0017] According to one embodiment, the crypto-asset wallet comprises a hardware wallet that is unable to connect to the internet and is connected or configured to connect to a host device that executes supporting software and has an internet connection.

[0018] According to one embodiment, to recover the secret, the method includes the following steps: communicating the information related to the identity of the user to each backup server; receiving, by the crypto-asset wallet, all or a portion of the secret data held by the backup server in encrypted form; and reconstructing, by the crypto-asset wallet, the secret from the secret data after decrypting the secret data provided by the backup server.

[0019] According to one embodiment, the method includes steps consisting of: providing an orchestrator program executed by a server, and configuring the orchestrator program and the crypto-asset wallet to perform at least one of the following steps: during backing up the secret, the crypto-asset wallet transmits the secret data generated by the crypto-asset wallet to the orchestrator program, and transmits the secret data received from the crypto-asset wallet to the backup servers by the orchestrator program; during restoring the secret, the orchestrator program receives all or a portion of the secret data held by the backup servers, and transmits the secret data to the crypto-asset wallet by the orchestrator program.

[0020] According to one embodiment, the method includes the steps consisting of: establishing a first secure communication channel between the crypto asset wallet and the orchestrator program via a first session key generated following a key exchange between the crypto asset wallet and the orchestrator program; and establishing a second secure communication channel between the crypto asset wallet and each backup server via the orchestrator program via a plurality of second session keys generated following a key exchange between the crypto asset wallet and each backup server via the orchestrator program.

[0021] According to one embodiment, the orchestrator program and the crypto-asset wallet each possess a private key, a public key, a certificate signed by a certification authority, and a public key provided by the certification authority, and the method includes the following steps: the orchestrator program transmits the certificate of the orchestrator program to the crypto-asset wallet; the crypto-asset wallet transmits the certificate of the crypto-asset wallet to the orchestrator program; the orchestrator program generates a temporary private key, a temporary public key, and a temporary certificate signed with the private key of the orchestrator program, and transmits the temporary certificate of the orchestrator program to the crypto-asset wallet; the crypto-asset wallet generates a temporary private key, a temporary public key, and a temporary certificate signed with the private key of the crypto-asset wallet, and transmits the temporary certificate of the crypto-asset wallet to the orchestrator program; the crypto-asset wallet generates the first session key from the temporary private key of the crypto-asset wallet and the temporary public key of the orchestrator program; and the orchestrator program generates the first session key from the temporary private key of the orchestrator program and the temporary public key of the crypto-asset wallet.

[0022] According to one embodiment, before transmitting the temporary certificate of the crypto-asset wallet to the orchestrator program: the crypto-asset wallet generates a first signature of the temporary public key of the crypto-asset wallet from the private key of the crypto-asset wallet; the crypto-asset wallet encrypts the first signature by the first session key to obtain an encrypted signature; the crypto-asset wallet transmits the temporary certificate including the temporary public key of the crypto-asset wallet and the encrypted signature to the orchestrator; then: the orchestrator program generates the first session key from the temporary private key of the orchestrator program and the temporary public key of the crypto-asset wallet; and the orchestrator program decrypts the signature present in the temporary certificate by the first session key.

[0023] According to one embodiment, the crypto-asset wallet concatenates the temporary public key of the crypto-asset wallet with data before generating the first signature of the temporary public key of the crypto-asset wallet from the private key of the crypto-asset wallet.

[0024] According to one embodiment, the method includes the following steps: the crypto-asset wallet encrypts the certificate of the crypto-asset wallet with the first session key before transmitting the certificate of the crypto-asset wallet to the orchestrator program; and the orchestrator program decrypts the certificate of the crypto-asset wallet by the first session key.

[0025] According to one embodiment, each of these backup servers possesses a private key, a public key, a certificate signed by a certification authority, and a public key provided by the certification authority; the orchestrator program transmits the certificate of the crypto-asset wallet and the temporary certificate of the crypto-asset wallet to each of these backup servers; each backup server transmits the certificate of the backup server to the orchestrator program, and the orchestrator program transmits the certificate to the crypto-asset wallet; each backup server generates a temporary private key, a temporary public key, and a temporary certificate signed with the private key of the backup server, and transmits the temporary certificate to the orchestrator program, and the orchestrator program transmits the temporary certificate to the crypto-asset wallet; each backup server generates the second session key from the temporary private key of the backup server and the temporary public key of the crypto-asset wallet; and the crypto-asset wallet generates the second session key of each backup server from the temporary private key of the crypto-asset wallet and the temporary public key of the backup server.

[0026] According to one embodiment, the method includes the following steps: for each backup server, the crypto-asset wallet encrypts the secret data intended for the backup server using the second session key, transmits the encrypted secret data to the orchestrator program, and the orchestrator program transmits the encrypted secret data to the backup server; and each backup server decrypts the received secret data by the second session key and stores the decrypted secret data in a memory.

[0027] According to one embodiment, the crypto-asset wallet verifies the validity of the certificate of the orchestrator program through the public key of the certification authority; the crypto-asset wallet verifies the validity of the temporary certificate of the orchestrator program through the public key of the certificate of the orchestrator program; the crypto-asset wallet verifies the validity of the certificate of each backup server through the public key of the certification authority; the crypto-asset wallet verifies the validity of the temporary certificate of each backup server through the public key of the certificate of each backup server; the orchestrator program verifies the validity of the certificate of the crypto-asset wallet through the public key of the certification authority; the orchestrator program verifies the validity of the temporary certificate of the crypto-asset wallet through the public key of the certificate of the crypto-asset wallet; each backup server verifies the validity of the certificate of the crypto-asset wallet through the public key of the certification authority; and each backup server verifies the validity of the temporary certificate of the crypto-asset wallet through the public key of the certificate of the crypto-asset wallet.

[0028] According to one embodiment, data sent by the backup server to the orchestrator program is resent by the orchestrator program to the crypto-asset wallet in a form encrypted by the first session key, and some of the data was previously hashed by the backup server using a hash function and then encrypted by the second session key.

[0029] According to one embodiment, before providing the secret data held by the at least one backup server, the at least one backup server subjects the user to an authentication step and refuses to return the secret data if the verification of the user's identity is not conclusive.

[0030] Embodiments also relate to a crypto-asset wallet that holds or is intended to hold a secret, the crypto-asset wallet being configured to provide a user with the options of: manually backing up the secret in the form of a recovery phrase that must be saved by the user, or backing up the secret in multiple backup servers, and, if the user chooses to back up the secret in multiple backup servers: performing, in the presence of the user, the steps of collecting information related to the user's identity and communicating the information related to the user's identity to each backup server; generating multiple secret data from the secret; and transmitting the secret data in encrypted form to the multiple backup servers.

[0031] According to one embodiment, the crypto-asset wallet is configured to further provide the user with the options of manually recovering the secret based on a recovery phrase or recovering the secret from multiple backup servers, and, if the user chooses to recover the secret based on multiple secret data held by multiple backup servers, reconstructing the secret from the data provided by the backup servers.

[0032] According to one embodiment, the crypto-asset wallet is configured to generate a plurality of secret data from the secret by a secret sharing function, the secret sharing function being designed to generate m secret data and to allow reconstruction of the secret from a threshold n secret data.

[0033] According to one embodiment, the crypto asset wallet is configured to: transmit the secret data to the plurality of backup servers via an orchestrator program executed by a server; and restore each of the data provided by the backup servers via the orchestrator program.

[0034] According to one embodiment, the crypto-asset wallet is configured to perform at least one step of verifying the identity of the user upon request of the backup server in the event that the user chooses to restore the secret based on the secret data.

[0035] According to one embodiment, the crypto-asset wallet includes a hardware wallet that cannot connect to the internet and a host device that executes supporting software and has an internet connection, the supporting software supplementing the hardware wallet to implement steps that require interaction with the user, in particular steps that collect information related to the user's identity.

[0036] According to one embodiment, the hardware wallet comprises a touch screen having a diagonal greater than or equal to 3.5 inches and controlled exclusively by a secure element, the touch screen being specifically used to collect information related to the identity of the user. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] These and other characteristics of the present invention will be better understood upon reading the following non-limiting description taken in conjunction with the accompanying drawings, in which:

[0038] Previously described Figure 1 Schematically illustrating an example of a crypto asset wallet and its use,

[0039] Figure 2A and Figure 2B The crypto asset wallet according to the present invention and the architecture of the system provided for implementing the first embodiment of the method according to the present invention are shown, wherein Figure 2A illustrates the data backup steps, and Figure 2B Illustrate the data recovery steps,

[0040] Figure 3A and Figure 3B The crypto-asset wallet according to the present invention and the architecture of a system provided for implementing a second embodiment of the method according to the present invention are shown, wherein Figure 3A illustrates the data backup steps, and Figure 3B Illustrate the data recovery steps,

[0041] Figure 4A Describes the process of backing up data during Figure 3A 、 Figure 3B The algorithm executed by the system,

[0042] Figure 4B Therefore Figure 3A 、 Figure 3B The interaction between different elements of the system is represented in the form of Figure 4A A sequence diagram of the steps of the algorithm,

[0043] Figure 5A Describes the steps that occur during data recovery. Figure 3A 、 Figure 3B The algorithm executed by the system,

[0044] Figure 5B Therefore Figure 3A 、 Figure 3B The interaction between different elements of the system is represented in the form of Figure 5A A sequence diagram of the steps of the algorithm,

[0045] Figure 6A and Figure 6B The crypto-asset wallet according to the present invention and the architecture of a system provided for implementing a third embodiment of the method according to the present invention are shown, wherein Figure 6A illustrates the data backup steps, and Figure 6B Illustrate the data recovery steps,

[0046] Figure 7 shows an example of a crypto-asset wallet according to the invention and a hardware wallet architecture according to the invention allowing the implementation of the method according to the invention,

[0047] Figure 8 Shown by Figure 7 The steps for backing up the seed stored in the hardware wallet are performed by the user of the hardware wallet.

[0048] Figure 9 Shown by Figure 7 The steps for recovering the seed performed by the user of the hardware wallet are:

[0049] Figure 10 Another embodiment of a crypto-asset wallet allowing implementation of the method according to the invention is shown,

[0050] Figure 11 A further embodiment of a crypto-asset wallet allowing implementation of the method according to the invention is shown. DETAILED DESCRIPTION

[0051] The present invention provides a method for creating a crypto-asset wallet that provides unique functionality in the hardware wallet space, namely, highly secure automated seed backup functionality. This functionality allows users to avoid the difficulties and dangers associated with keeping their own recovery phrases in a safe place. The unique functionality provided by the crypto-asset wallet according to the present invention will be discussed later with respect to Figure 8 、 Figure 9 and Table 2 and Table 3. First, an embodiment of the method according to the present invention will be described.

[0052] Figure 2AA cryptoasset wallet CW1 and a system for implementing an embodiment of the method of the present invention are shown. Cryptoasset wallet CW1 comprises a device HW and a host device HDV. Device HW is a hardware wallet that ensures cold storage of a seed S, or master key, for a set of cryptoassets. Device HW cannot connect to the internet, but is instead connected to a host device HDV, which executes companion software HSW, allowing it to connect to the internet, for example, via a USB or Bluetooth connection. The system and method according to the present invention allow for the backup or recovery of the seed S (master key) stored in device HW.

[0053] The system essentially comprises a set of m backup servers BCKi (BCK1, BCK2, ... BCKi, ... BCKm), each of which is provided with a backup memory MEM (magnetic hard disk or solid-state memory) for backing up a share Si of a seed S. Each backup server comprises a backend program BEi (BE1, ... BEi, ... BEm) designed to implement the method. Each backup server BCKi is also associated with a security module HSM.

[0054] According to the method of the invention, the device HW is configured to divide the seed S into a plurality of secret data Si (S1, S2 ... Si, ... Sm), which are to be backed up on the server BCKi. Rather than a simple split (although this is not excluded from the scope of the invention), this "division" is preferably ensured by a secret sharing function SS that allows the generation of m secret data, called "shards", and the reconstruction of the seed from a threshold number n of secret data Si:

[0055] S1,S2,...,Si,...,Sm=SS(S)

[0056] For example, if m is equal to 3 and n is equal to 2, the SS function allows the seed to be divided into three slices S1, S2, S3, but only two slices are needed to reconstruct the seed.

[0057] When a user wishes to back up his seed, the device HW establishes a data connection LNKi (LNK1 to LNKm) with each backup server BCKi via the host device HDV (e.g., via HTTPS). These data connections are then protected by creating a secure channel of the SCP type ("Secure Channel Protocol") between the device HW and each backup server BCKi in a manner to be described.

[0058] The establishment of such a secure channel is ensured by a public key infrastructure managed by a certification authority (CA). The device HW and the backup server BCKi each possess a private key, a public key, a certificate signed by the certification authority or a static certificate, and the certification authority's public key. The following notation will be used in the following text:

[0059] pL: Private key of the certification authority

[0060] PL: Public key of the certification authority

[0061] pD: Private key of device HW

[0062] PD: public key of the device HW

[0063] CD = [PD, Sign (pL, PD)]: The device's certificate (static certificate), including its public key PD and the signature of its public key using the certification authority's private key pL

[0064] pBi: Private key of server BCKi (i ranges from i to m)

[0065] PBi: Public key of server BCKi (i ranges from i to m)

[0066] CBi=[PBi, Sign(pL, PBi)]: the certificate of the server BCKi (static certificate), including its public key PD and the signature of its public key using the private key pL of the certification authority.

[0067] The signature function “Sign” is generated, for example, by the ECDSA signature algorithm (“Elliptic Curve Digital Signature Algorithm”) based on an elliptic curve.

[0068] The certification authority CA is preferably held by the manufacturer of the device HW, allowing it to control the distribution of certificates CBi to the backup servers BCKi. The backup servers BCKi can, in turn, be hosted by the manufacturer of the device HW, or can be third-party partner servers involved in implementing the method. The keys pBi and PBi of the backup servers BCKi are held by their corresponding modules HSM, which handle the cryptographic calculations performed using these keys. In the following, for simplicity of language, it will be considered that the servers themselves perform these cryptographic calculations.

[0069] In order to achieve a secure communication channel, a key exchange is provided between the device HW and each backup server BCKi, thereby allowing the generation of a session key kBi specific to each server BCKi but known to the device HW. This key exchange is, for example, a Diffie-Hellman key exchange performed according to the following steps:

[0070] i) Each backup server BCKi uses an asymmetric key generator to generate a pair of temporary private keys

[0071] peBi and the public key PeBi, then communicates its temporary public key PeBi to the device HW in a temporary certificate CeBi that it has signed with its private key pBi and its certificate CBi signed by the trusted authority:

[0072] CeBi=[PeBi,Sign(pBi,PeBi)]

[0073] CBi=[PBi,Sign(pL,PBi)]

[0074] ii) The device HW generates a pair of temporary private and public keys PeD by itself, and then communicates its temporary public key PeD to the backup server BCKi in a temporary certificate CeD that it has signed with its private key pD and its certificate CD signed by a trusted authority, i.e.:

[0075] CeD=[PeD,Sign(pD,PeD)]

[0076] CD=[PD,Sign(pL,PD)]

[0077] iii) each backup server BCKi verifies the signature of the temporary public key PeD of the device HW by means of the public key PD present in the certificate CD of the device HW and then verifies the signature of the public key PD present in the certificate CD by means of the public key PL of the certification authority, or vice versa (verifying the signature of the public key PD before verifying the signature of the temporary public key PeD),

[0078] iv) Similarly, the device HW verifies the signature of the temporary public key PeBi of each server BCKi by the public key PBi present in the certificate CB and then verifies the signature of the public key PBi present in the certificate CB by the public key PL of the certification authority, or vice versa,

[0079] v) Each backup server BCKi generates a temporary session key kBi from its temporary private key peBi and the temporary public key PeD of the device HW by means of a key exchange function such as, for example, the ECDH function (Elliptic Curve Diffie-Hellman Key Exchange), namely:

[0080] kBi=ECDH(peBi,PeD)

[0081] vi) The device HW uses the same function to obtain the temporary private key peD and the backup server

[0082] BCKi's temporary public key PeBi generates each backup server's temporary session key BCKi

[0083] kBi, that is:

[0084] kBi=ECDH(peD,PeBi)

[0085] After generating the fragments Si of the seed S, the device HW performs a symmetric encryption step for each fragment Si using a session key kBi shared with the backup server BCKi to which the fragment Si will be transmitted, thereby forming a shared key. In a simple implementation example, the device HW generates three fragments S1, S2, S3 (the threshold n can then be equal to 2 or 3), and three backup servers BCK1, BCK2, BCK3 are provided. Each server BCKi generates its own session key kB1, kB2, kB3, and the device HW then generates each of these session keys after exchanging keys with each server in the manner just described. The device HW then performs a symmetric encryption step for the fragments S1, S2, S3 using these keys, namely:

[0086] - Encrypt the fragment S1 with the key kB1, that is, {S1}kB1, and then send it to the server BCK1,

[0087] - Encrypt the fragment S2 with the key kB2, that is, {S2}kB2, and then send it to the server BCK2,

[0088] - Encrypt shard S3 with key kB3, i.e. {S3}kB3, and then transmit it to server BCK3.

[0089] Each backup server BCKi then decrypts the encrypted slice {Si}kBi it received from the device HW and stores it in its memory MEM.

[0090] According to this method, and as Figure 2B As illustrated in FIG, the recovery of the seed S is performed in a second hardware wallet, designated HW′. This device may be a device other than the device HW if the device HW has been lost, stolen, or destroyed. This device may also be the device HW if the device HW has been reset, which is considered "another" device from the method's perspective because it no longer holds the seed.

[0091] To recover the seed, the secure channel creation steps described above are repeated. A new session key kBi is generated. Each server then encrypts the slice Si it holds with this session key kBi, i.e. {Si}kBi, and transmits it to the device HW. The latter then decrypts each slice Si by means of the corresponding session key kBi and reconstructs the seed S by means of the inverse function of the function that allowed the generation of the slice Si, which is denoted as "SS -1 ”:

[0092] S=SS -1(S1,S2,...,Si,...,Sm)

[0093] Figure 3A The following shows the architecture of a system that allows for the implementation of another embodiment of the method of the present invention. In this embodiment, a server ORCSRV1 is inserted between the host device HDV and the backup server BCKi. This server (referred to as the "orchestrator server" for illustrative purposes) executes a backend program ORC1, hereinafter referred to as the "orchestrator program" or "orchestrator." The server ORCSRV1 is connected to a security module HSM, which is provided with a private key pO, a public key PO, and a certificate CO (static certificate) signed by a certification authority CA:

[0094] CO=[PO,Sign(pL,PO)]

[0095] To implement the method, a first data connection LNK1, such as an HTTPS connection, is established between the device HW and the orchestrator ORC1 via the host device HDV. Multiple data connections LNK2i, such as HTTPS connections, VPN IPsec, etc., are also established between the orchestrator and the backup server BCKi.

[0096] The data connection between the orchestrator and the device HW is protected by creating a secure channel according to the same technique as described above:

[0097] i) Orchestrator ORC1 generates a pair of private and public keys PeO, then PeO communicates its temporary public key PeO to device HW in its temporary certificate CeO that it has signed with its private key pO and its certificate CO signed by the trusted authority, i.e.:

[0098] CeO=[PeO,Sign(pO,PeO)]

[0099] CO=[PO,Sign(pL,PO)]

[0100] ii) The device HW generates a pair of temporary private and public keys PeD, and then communicates its temporary public key PeD to the orchestrator in a temporary certificate CeD that it has signed with its private key pD, and its certificate CD signed by the trusted authority, i.e.:

[0101] CeD=[PeD,Sign(pD,PeD)]

[0102] CD=[PD,Sign(pL,PD)]

[0103] iii) the orchestrator ORC1 verifies the signature of the temporary public key PeD of the device HW by means of the public key PD present in the certificate CD and then verifies the signature of the public key PD by means of the public key PL of the certification authority, or vice versa,

[0104] iv) Similarly, the device HW verifies the signature of the orchestrator's temporary public key PeO by the public key PO present in the certificate CO and then verifies the signature of the public key PO by the certification authority's public key PL, or vice versa,

[0105] v) Orchestrator ORC1 generates a temporary session key k0 from its temporary private key peO and the temporary public key PeD of the device HW:

[0106] k0=ECDH(peO,PeD)

[0107] vi) The device HW generates a temporary session key k0 from its temporary private key peD and the orchestrator's temporary public key PeO:

[0108] k0=ECDH(peD,PeO)

[0109] Once a secure channel is established between the orchestrator and device HW, device HW can securely transmit data from backup server BCKi to the orchestrator thanks to symmetric encryption using the shared session key k0 for all or part of the exchanged data. Conversely, the orchestrator can communicate data received from backup server BCKi to device HW in encrypted form using key k0.

[0110] A secure channel is also created between the device HW and the backup server BCKi via the session keys kBi generated at the end of the key exchange over the data connection LNK1, the orchestrator acting as a gateway or "proxy server" between the device HW and the server BCKi.

[0111] After performing these steps, we distinguish the following two cases:

[0112] - a secure channel implemented via the data connection LNK1, protected by a session key k0 shared by the orchestrator and the device HW, allowing encryption of the data exchanged between the orchestrator and the device HW,

[0113] - A secure channel implemented via the data connection LNK2i, protected by a session key kBi specific to each backup server BCKi and known to the device HW, allowing the device HW to exchange data in encrypted form with each server BCKi.

[0114] In some cases, a step may also be provided of encrypting with the key k0 the data received by the organizer in a form encrypted with the key kBi, this encrypted form corresponding to a super encryption of these data.

[0115] In one embodiment, the method of the present invention implements two improvements regarding the transmission of the device HW's certificate CD as part of a key exchange with any server. Indeed, the device's transmission of its certificate CD as part of such a key exchange constitutes a confidentiality vulnerability, as the public key PD contained in the certificate can be exposed in the event of wiretapping. Furthermore, it has been demonstrated that ECDSA signatures allow the retrieval of the corresponding public key's value. Therefore, transmitting the signature Sign(pD, PeD) of the temporary public key PeD in the temporary certificate CeD may also allow a third party to discover the public key PD.

[0116] The two improvements lie in the encryption of the certificate CD and the encryption of the signature Sign(pD, PeD) respectively. As an example, the implementation of these methods will be described in the context of the calculation of the session key k0 described above. The steps related to the key exchange described previously are modified as follows:

[0117] i) The orchestrator generates a temporary private key peO, a temporary public key PeO, and a temporary certificate CeO signed with its private key pO, and transmits its temporary certificate CeO and its certificate CO to the device:

[0118] CeO=[PeO,Sign(pO,PeO)]

[0119] CO=[PO,Sign(pL,PO)]

[0120] ii) The device HW generates a temporary private key peD and a temporary public key PeD, and calculates the first signature Sign(pD, PeD) of its temporary public key PeD based on its private key pD using the ECDSA algorithm,

[0121] iii) The device generates a session key k0 from its ephemeral private key peD and the orchestrator’s ephemeral public key PeO,

[0122] iv) The device encrypts its certificate CD with the session key k0:

[0123] {CD}k0

[0124] v) The device encrypts the first signature Sign(pD, PeD) using the session key k0:

[0125] {Sign(pD,PeD)}k0

[0126] vi) The device transmits to the orchestrator its certificate CD encrypted with the session key k0 and its temporary certificate CeD including the signature of its temporary public key PeD encrypted with the session key k0:

[0127] {CD}k0||CeD

[0128] Right now,

[0129] {CD}k0||PeD||{Sign(pD,PeD)}k0

[0130] (|| is a concatenation symbol)

[0131] vii) The orchestrator generates a session key k0 from its ephemeral private key pe0 and the ephemeral public key PeD received from the device, and

[0132] viii) Using the session key k0, the orchestrator decrypts the signature present in the temporary certificate CeD and decrypts the device's certificate CD.

[0133] It will be clear to those skilled in the art that the two methods of encrypting the certificate CD and encrypting the signature of the temporary public key PeD can be implemented separately, the public key can be encrypted without encrypting the signature, or vice versa. It will also be obvious to those skilled in the art that these two methods have universal application and can be implemented during the creation of any secure channel based on key exchange and the generation of a signature using the ECDSA algorithm.

[0134] return Figure 3A As can be seen above, providing an orchestrator ORC1 allows reducing the number of data connections between the device HW and the backup server BCKi. These connections are replaced by a single data connection LNK1 between the device HW and the orchestrator, while also ensuring a higher level of security due to the super-encryption of the data transmitted via connection LNK1 (as noted above). Furthermore, due to the improvements just described, the confidentiality of the public key PD can be maintained. Providing an orchestrator offers various other advantages, which will be described later with respect to the implementation of the user authentication step.

[0135] In this case, reference Figure 3A , the steps of backing up the seed S can be implemented as follows:

[0136] i) a connection LNK1 is established between the device HW and the orchestrator, and the device HW transmits a backup request BCKRQ to the orchestrator,

[0137] ii) The orchestrator generates a backup random identifier BCKID, establishes a connection LNK2i between the orchestrator and the backup server BCKi, and transmits the identifier BCKID to the backup server BCKi.

[0138] iii) creating a secure channel between the device HW and the orchestrator ORC1 via the session key k0, iv) creating a secure channel between the device HW and the backup server BCKi via the orchestrator ORC1 via the session key kBi,

[0139] v) The device HW generates the fragments Si of the seed S:

[0140] S1,S2,...,Si,...,Sm=SS(S)

[0141] vi) Session key of backup server BCKi intended by device HW via shard Si

[0142] kBi is used to encrypt each shard Si.

[0143] vii) The device HW transmits all encrypted segments {Si}kBi to the orchestrator:

[0144] {S1}kB1||{S2}kB2||....||{Si}kBi||...||{Sm}kBm

[0145] viii) transmitting, by the orchestrator, the encrypted segment {Si}kBi to each backup server BCKi for which it is intended,

[0146] ix) Each server BCKi decrypts the fragment Si it has communicated and stores it in its memory in association with the backup identifier BCKID.

[0147] Furthermore, the step of restoring the seed S in the new device HW' is triggered at the request of the user USR (in Figure 3B ) includes the following steps:

[0148] i) a connection LNK1 is established between the device HW and the orchestrator, and the device HW transmits a recovery request RESTRQ and a backup identifier BCKID to the orchestrator,

[0149] ii) establishing a LNKi connection between the orchestrator and the backup servers BCKi, and transmitting identifiers BCKID by the orchestrator to the backup servers BCKi so that these backup servers are informed of the recovery to be performed,

[0150] iii) creating a secure channel between the device HW and the orchestrator ORC1 via the new session key k0,

[0151] iv) creating a secure channel between the device HW and the backup server BCKi via the orchestrator ORC1 using the new session key kBi,

[0152] v) Each backup server BCKi reads the shard Si it holds in its memory by the identifier BCKID and encrypts it by the new session key kBi,

[0153] vi) Each backup server BCKi sends the encrypted segments {Si}kBi to the orchestrator,

[0154] vii) The orchestrator collects all encrypted segments {Si}kBi provided by the backup servers BCKi:

[0155] {S1}kB1, {S2}kB2,…,{Si}kBi,…,{Sm}kBm

[0156] viii) Send each encrypted fragment {Si}kBi to the device HW, one by one or all together:

[0157] {S1}kB1||{S2}kB2||....||{Si}kBi||...||{Sm}kBm

[0158] ix) Each fragment Si is decrypted by the device HW using the session key kBi of the corresponding backup server BCKi:

[0159] Si={Si} -1 kBi

[0160] x) The seed is reconstructed by the device HW and stored in its memory:

[0161] S=SS -1 (S1,S2,...,Si,...,Sm)

[0162] Note that in an embodiment, if n is less than m, the orchestrator may only collect the n shards needed to reconstruct the seed. In this case, the seed is reconstructed from n restored shards:

[0163] S=SS -1 (S1,S2,...,Si,...,Sn)

[0164] It has been assumed above that, despite the loss of the device HW used during the backup, the backup identifier BCKID is stored by the companion software HSW of the host device HDV. In an embodiment that overcomes the situation in which the user will eventually uninstall the companion software HSW, a customer account server UASRV can be provided, which includes a user account UACC in which various data about the user, in particular the backup identifier BCKID, is stored. The server UASRV is associated with a security module HSM, which receives a private key pC, a public key PC, a certificate CC signed by a certification authority, and the certification authority's public key PL. In this case, due to a key exchange that defines the session key for establishing a secure channel, a data connection is established between the device HW' and the server UASRV, with mutual authentication of the certificates. Once the secure channel is established, the companion software HSW connects to the customer account UACC to restore the identifier BCKID. In one variant, the identifier BCKID is stored on the server UASRV but is not communicated to the companion software. A secure connection is established between the server UASRV and the orchestrator ORC1. The orchestrator transmits the identifier BCKID to the server UASRV when backing up, and in turn receives it from the server UASRV when the user wants to restore his seed.

[0165] In one embodiment, the user's identity is also associated with the backup process by defining a set of information fragments that form a "pivot identity" that allows identification. The information that forms the pivot identity includes, for example, the user's first name, last name, and date of birth, and optionally other information such as their place of birth. This information is collected by the supporting software and communicated to the orchestrator, which assembles it to form a binary string that will be designated as "backup data" BCKDT. The data BCKDT may contain other information such as the date and time of the backup, and the name given to the backup by the user (allowing the user to distinguish between multiple backups later in the case of multiple backups with several hardware wallets).

[0166] When initiating a backup, Figure 3A As shown, the orchestrator communicates the data BCKDT to the backup servers BCKi, which associate these data BCKDT and the identifier BCKID with the backed-up shard Si. For confidentiality reasons, in some embodiments, it may be preferable that the orchestrator does not store the data BCKDT once the backup is performed. In this case, the data BCKDT is stored only by the servers BCKi, which communicate these data BCKDT to the user USR for the user USR to confirm their identity during the restore, as shown in FIG. Figure 3B shown.

[0167] In an embodiment of the method, the user's fulcrum identity is verified during at least one authentication step designated "IDV" (identity verification) performed before restoring the seed. In one embodiment, several authentication steps IDVi are preferably provided before continuing with the seed restoration, these steps being performed by the backup servers BCKi of all or part of the shard Si that is prompted to return the seed S.

[0168] exist Figure 3B In the embodiment shown, these authentication steps are delegated to a dedicated service provider, rather than being performed by the backup server BCKi itself. Such a service provider hosts servers IDVSRVi, each of which performs an automated authentication service IDVSi accessible via the gateway GTW. Each backup server BCKi can be assigned a different server IDVSRVi and configured to connect to the gateway GTW for the service IDVSi performed by that server. Preferably, such a service IDVSi is not fully automated, at least in part, and includes human intervention, particularly in cases where the identity of an individual is in doubt.

[0169] Therefore, each backup server BCKi or at least a part thereof is configured to perform a step IDVi of verifying the user's fulcrum identity when it receives a request to return a shard of a seed. The server is then preferably configured to refuse to return the shard if this verification is not conclusive.

[0170] In one embodiment, the seed backup step is preceded by an initial step IDV0 of verifying the user's pivot identity (i.e., at least their first name, last name, and date of birth), performed or supervised by the orchestrator. In this case, server IDVSRV0 is also associated with orchestrator ORC1, and the orchestrator is configured to connect to gateway GTW of service IDVS0, executed by the server, to perform step IDV0.

[0171] During each step of the optional step IDV0 before the backup or the intervening step IDVi before the return of the seed shard, the orchestrator directs the user USR to the appropriate service IDVS0 or IDVSi via the appropriate gateway GTW. The user must perform certain actions requested by the screen and the included camera of the host device HDV (e.g., a mobile phone camera, a personal computer webcam, etc.). For example, the service IDVS0 or IDVSi requires the user to provide a valid identification document including a photo, take a photo of the identification document with the camera and transmit the photo. The service IDVS0 or IDVSi then requires the user to take a photo (selfie) or video of their face and transmit the photo or video. The service IDVS0 or IDVSi then verifies the authenticity of the identification document based on the photo or video of the face, and once the identification document is verified, it allows the data of the fulcrum identity to be verified with a certain degree of certainty, which in some embodiments can be represented by a score. The result of this verification and, optionally, the score, are communicated to the orchestrator. In one embodiment, step IDV also includes verification against a government database.

[0172] Although step IDV0 is not as critical as the steps performed by the server BCKi when returning the shard Si, it ensures that the user did not make any mistakes when providing information related to their identity, which will be incorporated into the data BCKDT. In addition, the information collected by the orchestrator during this step (such as a photo of the identity document and a photo or video of the face) can optionally be communicated to the backup server BCKi via a specific communication channel, since this information is not part of the backup data BCKDT.

[0173] In one embodiment, the orchestrator ORC1 can suspend the seed backup process if it deems the initial verification of the user's identity to be inconclusive or to have received a score that is too low. Furthermore, in another embodiment or in addition, the orchestrator receives information from backup servers BCKi regarding the success of the authentication steps IDVi that have been performed by these backup servers or by the service providers to which they are affiliated. If a certain number of servers BCKi have not successfully verified the user's identity and refuse to return the shards Si they hold, the orchestrator can be configured to suspend the return of shards Si by servers that have successfully verified the user's identity. The orchestrator can optionally decide to subject the user to additional steps to verify their identity.

[0174] In a variant, or in addition, the orchestrator receives a certainty score about the user's identity from each backup server BCKi that has undergone an authentication step. If the average of the scores is below a first threshold, and / or if one of the scores is below a second threshold, the orchestrator pauses the recovery process and optionally subjects the user to an additional step of verifying their identity.

[0175] In the event that the user may have closed their account on the account server UASRV, may have uninstalled the supporting software by deleting the data contained in the supporting software, and may have lost their hardware wallet HW and therefore will no longer be able to retrieve the backup identifier BCKID, a solution can be provided to allow the user to restore their seed. The user will then go through multiple separate steps to verify their identity with each server BCKi in order to restore each shard Si of the seed. A process involving ministerial officials (such as notaries) can also be provided. Each provider IDV will also be able to verify the legality of their methods by ensuring that there are no accounts belonging to the user in the system's account servers, and will entrust a more in-depth investigation process to a natural person, such as a telephone interview with the user, a video conference with the user, a face-to-face interview with the user, verification of the user's school or career, etc.

[0176] It will be clear to those skilled in the art that the method of the present invention is applicable to various other embodiments and variations. Specifically, in one embodiment, the backup data BCKID may include in compressed form the information collected at step IDV0 for verifying the user's fulcrum identity, such as a photo or video of their face and a photo of their identity document. The automated step of verifying the user's fulcrum identity performed by the server IDVSRVi or by the service IDVSi performed by the backup server BCKi itself may include at least two of the following steps: obtaining a photo of an unexpired identity document including a photo of the user by a camera; obtaining one or more photos of the user's face by a camera; obtaining a video recording of the user's face in motion by a camera, wherein liveness detection is used to verify that the user is real; obtaining proof of residence, such as a utility bill or telephone bill; obtaining the user's fingerprint; obtaining a verification code received by the user in a telephone message, by email or by mail; activating by the user a link received by the user in a telephone message, by email or by mail; and obtaining a hologram present on an unexpired identity document.

[0177] Now it will be relative to Figure 4A Description Applicable to Figure 3A Examples of systems and backup algorithms that implement various aspects of the previously described method embodiments. Figure 4B Is a sequence diagram that represents the steps of an algorithm in the form of interactions between:

[0178] -User USR,

[0179] - the device HW and its host device HDV (which are considered as a single entity forming the crypto-asset wallet CW1),

[0180] - the orchestrator ORC1 and its associated security module HSM (which is also considered a single entity), and

[0181] a server IDVSRV0 associated with the orchestrator, which is used to perform the step IDV0 of verifying the identity of the user,

[0182] - backup server BCKi, and

[0183] - The server ID VSRVi associated with the server BCKi, which is used to perform subsequent authentication steps when the seed is restored.

[0184] As a non-limiting example, some functions used in the algorithm are indicated in Table 1 below:

[0185] [Table 1]

[0186]

[0187] Relative to Figure 4A and Figure 4B A description of the algorithm.

[0188] B1. Initiate backup

[0189] User USR selects the seed backup option on device HW. The user creates a backup account on the account server UASRV through the host device HDV. Device HW establishes a data connection with orchestrator ORC1 and sends it a backup request:

[0190] [HW→ORC1]

[0191] BCKRQ

[0192] Optionally, the device HW offers the user the possibility to select the number m of shards Si they wish to generate for the backup seed, as well as a corresponding threshold n for the number of shards required to reconstruct the seed S. Still optionally, the device HW may present the user with a list of backup servers BCKi (some of which are potential external partners) and ask the user to indicate which backup servers they wish to use. Otherwise, these backup servers are automatically selected by the orchestrator. The orchestrator ORC1 establishes a data connection with the servers BCKi and then proceeds with the backup process according to the steps described below.

[0193] B2. Generate a backup identifier and transmit it to the device HW and server BCKi

[0194] [ORC1→BCKi,HW]BCKID

[0195] The orchestrator ORC1 generates a backup identifier BCKID, such as a random number, and transmits it to the device HW and the server BCKi.

[0196] B3. Server IDVSRV0 performs authentication IDV0

[0197] [IDVSRV0]IDV0

[0198] Orchestrator ORC1 connects the user to server IDVSRV0 through gateway GTW. Service IDVS0 proceeds with verification of the user's pivot identity IDV0.

[0199] B4. The orchestrator confirms the success of the authentication

[0200] IDV_OK→HW

[0201] The server IDVSRV0 confirms to the orchestrator ORC1 that IDV has been successfully executed, and the orchestrator ORC1 confirms to the user through the device HW that the user identity has been verified and the seed backup step can be initiated. In this step, the orchestrator ORC1 can generate the backup data BCKDT and transmit it to the device HW.

[0202] B5. Mutual authentication and secure channel creation between the orchestrator and the device

[0203] B5.1 Temporary certificate generated by the orchestrator

[0204] (peO,PeO)=AsymKeyGen()

[0205] Sign(pO,ReO||PeO)

[0206] CeO=PeO||Sign(pO,ReO||PeO)

[0207] The orchestrator ORC1 generates a temporary private key peO and a temporary public key PeO. The orchestrator calculates a signature for its temporary public key PeO using its private key pO. In the illustrated variant, the orchestrator calculates the signature after concatenating its temporary public key PeO with data ReO. The data ReO specifies, for example, the role played by the orchestrator server in the method, such as the orchestrator's role in establishing a secure channel. The orchestrator then generates a temporary certificate CeO by concatenating the temporary public key PeO with the signature.

[0208] B5.2 Sending the orchestrator's certificate to the device

[0209] CeO||CO→HW

[0210] The orchestrator ORC1 transmits its temporary certificate and its certificate CO to the device HW.

[0211] B5.3. Verify the orchestrator's certificate by the device

[0212] Verif CeO,Verif CO

[0213] The device HW verifies the orchestrator's certificate chain using the certification authority's public key PL in the manner described above.

[0214] B5.4. The device HW generates the session key k0 and temporary certificate

[0215] (peD,PeD)=AsymKeyGen()

[0216] k0=ECDH(peD,PeO)

[0217] Sign(pD,ReD||PeD)

[0218] {Sign(pD,ReD||PeD)}k0

[0219] CeD=PeD||{Sign(pD,ReD||PeD)}k0

[0220] {CD}k0

[0221] Device HW generates a temporary private key peD and a temporary public key PeD, and then generates a session key k0 from its temporary private key peD and the orchestrator's temporary public key PeO using the ECDH algorithm. Device HW then calculates the signature of its temporary public key PeD using its private key pD, after concatenating the temporary public key PeD with data ReD. The data ReD specifies, for example, the role played by HW in the method. Device HW then encrypts the signature of its temporary public key with the session key k0 according to the signature encryption process described above. Device HW then forms a temporary certificate CeD by concatenating the temporary public key PeD with the encrypted signature. Finally, device HW encrypts its certificate CD using the key k0 according to the certificate encryption process described above.

[0222] B5.5. Sending the device's certificate to the orchestrator

[0223] [HW→ORC1]

[0224] CeD||{CD}k0

[0225] The device HW transmits its certificate CD, encrypted with the key k0, and its temporary certificate CeD, including its encrypted signature, to the orchestrator ORC1. Due to the encryption of the certificate and the encryption of the signature of the temporary certificate, the public key PD is not exposed, as explained above. As indicated above, the order of these steps can be reversed, and the device can transmit its certificate (which is encrypted here) before transmitting its temporary certificate (which includes its encrypted signature).

[0226] B5.6. The session key k0 is generated by the orchestrator

[0227] k0=ECDH(peO,PeD)

[0228] The orchestrator ORC1 generates a session key k0 from its temporary private key peO and the temporary public key PeD of the device HW using the ECDH algorithm.

[0229] B5.7. Verify the device's certificate by the orchestrator

[0230] CD={CD} -1 k0

[0231] Sign(pD,ReD||PeD)={Sign(pD,ReD||PeD)} -1 k0

[0232] Verif CeD,Verif CD

[0233] The orchestrator ORC1 decrypts the device HW's certificate CD and the signature of the device HW's temporary certificate, and then verifies the certificate chain.

[0234] B6. Send the device data BCKID, BCKDT and certificates CeD, CD to the server BCKi

[0235] [ORC1→BCKi]

[0236] For each server BCKi, i ranges from 1 to m

[0237] BCKID||BCKDT||CeD||CD

[0238] Orchestrator ORC1 transmits a backup identifier BCKID and backup data BCKDT, including at least the pivot identity data, to each server BCKi. As indicated above, other data may optionally be transmitted to the backup server via other channels, or may have already been transmitted to the backup server via other channels, such as a photo or video of the user's face taken at step IDV0, and a photo of an identification document. If this data is not included in the backup data BCKDT, it may be stored by the customer account server and sent to the server BCKi after the backup.

[0239] B7. Verify the device's certificate by each server BCKi

[0240] For each server BCKi, i ranges from 1 to m

[0241] Verif CeD,Verif CD

[0242] Each server BCKi verifies the certificate chain of the device HW in the manner previously described.

[0243] B8. Mutual authentication and secure channel creation between the server BCKi and the device through the orchestrator

[0244] B8.1 Generate a temporary certificate from each server BCKi

[0245] For each server BCKi, i ranges from 1 to m

[0246] (peBi,PeBi)=AsymKeyGen()

[0247] Sign(pBi,ReB||PeBi)

[0248] CeBi=PeBi||Sign(pBi,ReB||PeBi)

[0249] Each server BCKi generates a temporary private key peBi and a temporary public key PeBi. After concatenating its temporary public key PeBi with the data ReB, each server BCKi calculates a signature for its temporary public key using its private key pBi. ReB specifies, for example, the role each server plays in the method, such as a backup server for managing a secure channel. Each server BCKi then generates a temporary certificate CeBi by concatenating its temporary public key PeBi with its signature.

[0250] B8.2 Generation of session keys kBi by each server BCKi

[0251] For each server BCKi, i ranges from 1 to m

[0252] kBi=ECDH(peBi,PeD)

[0253] Each server BCKi then generates a session key kBi from its temporary private key peBi and the temporary public key PeD of the device HW by means of the ECDH algorithm.

[0254] B8.3 Generate an encrypted hash code by each server BCKi

[0255] For each server BCKi, i ranges from 1 to m

[0256] Hi=Hash(PeBi||BCKID||BCKDT)

[0257] CHi={Hi}kBi

[0258] Next, each server BCKi generates a hash code Hi from a binary string comprising its temporary public key PeBi, the data BCKID and the backup data BCKDT. Each server BCKi then encrypts the code Hi by means of the session key kBi to obtain an encrypted hash code CHi.

[0259] B8.4 Send the server BCKi's certificate and encrypted hash code to the orchestrator

[0260] [BCKi→ORC1]

[0261] RETDTi=CeBi||CBi||CHi

[0262] Each server BCKi transmits to the orchestrator ORC1 a binary string RETDTi comprising its temporary certificate CeBi, its certificate CBi and the encrypted hash code CHi.

[0263] B8.5 Send the server BCKi's certificate and encrypted hash code to the device

[0264] [ORC1→HW]

[0265] {BCKID||BCKDT||RETDT1||...||RETDTi||...||RETDTm}ko

[0266] Orchestrator ORC1 transmits the data BCKID, BCKDT, and all data RETDTi received from backup server BCKi back to the device, encrypted with key k0. Note that the orchestrator cannot access the RETDTi data because it does not know the private key kBi of server BCKi. Therefore, the data in the secure communication channel between the orchestrator and the device is encrypted twice.

[0267] B8.6 The device decrypts the server BCKi's certificate and the encrypted hash code

[0268] {BCKID||BCKDT||RETDT1|...||RETDTi||...||RETDTm} -1 k0

[0269] The device HW decrypts the data string to extract the data BCKID, BCKDT and the certificates CeBi, CBi, CHi.

[0270] B8.7 User Verification Data BCKDT and Server BCKi

[0271] For each server BCKi, i ranges from 1 to m

[0272] Validate BCKDT,BCKi

[0273] The user, who is a natural person, verifies the backup data BCKDT presented to the user on the screen of the host device and the server BCKi responsible for the backup.

[0274] B8.8 The device verifies the certificate of the server BCKi

[0275] For each server BCKi, i ranges from 1 to m

[0276] Verif CeBi,Verif CBi

[0277] The device HW verifies the certificate chain of each server BCKi.

[0278] B8.9 Device generates session key kBi and verifies encrypted hash code For each server BCKi, i ranges from 1 to m

[0279] kBi=ECDH(peD,PeBi)

[0280] {Hi} -1 k

[0281] Validate Hi

[0282] For each server BCKi, the device HW generates a session key kBi, then decrypts the code Hi and verifies it by recalculating the code Hi itself and comparing it with the decrypted code.

[0283] B9. Prepare for backup and generate m fragments Si

[0284] S1, S2, ... Si, ... Sm = SS (S)

[0285] By means of a secret sharing function SS, the device HW generates m shards Si to be backed up in different servers BCK1, BCK2, ..., BCKm, wherein a seed S is restored with a threshold number n of shards.

[0286] B10. The device encrypts the fragment Si

[0287] For each server BCKi, i ranges from 1 to m

[0288] {Si}kBi

[0289] For each server BCKi, the device HW encrypts the slice Si intended for this server with a key kBi specific to this server.

[0290] B11. Send encrypted fragment Si to the orchestrator

[0291] [HW→ORC1]

[0292] {S1}kB1||{S2}kB2||...||{Si}kBi||...||{Sm}kBm→ORC1

[0293] Device HW then transmits all the shards to orchestrator ORC1. Note that the orchestrator lacks knowledge of the value of each shard Si, since the shards Si are encrypted with a key kBi unknown to the orchestrator.

[0294] B12. Send encrypted fragment Si to server BCKi

[0295] [ORC1→BCKi]

[0296] For each server BCKi, i ranges from 1 to m

[0297] BCKID||{Si}kBi→BCKi

[0298] The orchestrator ORC1 sends the encrypted shard Si assigned to it and the backup identifier to each server BCKi.

[0299] B13. Each server BCKi decrypts and records the encrypted fragment Si For each server BCKi, i ranges from 1 to m

[0300] {Si} -1 kBi→STORE

[0301] Each server BCKi decrypts the slice Si it has received and stores it in its memory MEM for backup.

[0302] B14. Each server BCKi confirms the backup to the orchestrator

[0303] [BCKi→ORC1]OKi

[0304] Each server BCKi confirms to the orchestrator ORC1 that it has successfully decrypted and stored the shard of the seed entrusted to it via the message "OKi" (where i ranges from 1 to m). Optionally, each server BCKi can transmit an encrypted proof of having decrypted the shard Si using a hash code signed with its session key. This signed hash code will be passed to the device HW for verification.

[0305] B15. Confirm backup to user

[0306] [ORC1→HW]

[0307] OK

[0308] The orchestrator ORC1 transmits a success message ("OK") of the backup to the device HW, which displays the backup confirmation message on its screen to attract the user's attention.

[0309] At the end of the process:

[0310] -The device HW still holds the seed S,

[0311] - The HSW backup software records the BCKID identifier,

[0312] - Orchestrator ORC1 does not hold the seed S or the backup data BCKDT, and only holds the backup identifier BCKID,

[0313] - Each server BCKi holds a backup identifier BCKID, backup data BCKDT containing at least the user's pivot identity, and the shards Si of the seeds that have been delegated to this server.

[0314] The companion software HSW records the backup identifier BCKID and may also update the user's customer account UACC by recording the backup identifier BCKID in the user's customer account UACC.

[0315] Now it will be relative to Figure 5A Description Applicable to Figure 3A Examples of seed recovery algorithms for systems and implementing various aspects of embodiments of the previously described methods. Figure 5B It is a sequence diagram that represents the steps of an algorithm in the form of interactions between the previously mentioned entities.

[0316] Here, it is assumed that the user has lost their device HW, or has irretrievably lost the password that allows use of the device HW. The user obtains a new device HW', which they will use to restore the seed S, and connects it to the host device HDV, whose companion software HSW already stores the backup identifier BCKID. The new device HW' can also be a device HW that has been reset.

[0317] At the start of the process, the device HW' holds a private key pD, a public key PD, a certificate CD certified by a certification authority, and the certification authority's public key PL (the same names as before will be used for the device HW's keys and certificates). The recovery process includes the steps described below. Steps similar to those described previously will not be described again.

[0318] R1. The device sends a recovery request to the orchestrator.

[0319] HW'→ORC1

[0320] RESTRQ[BCKID]

[0321] The restoration is initiated by the device HW' transmitting a restoration request RESTRQ to the orchestrator. This request contains the backup identifier BCKID. This request is issued at the request of the user and is selected through a menu displayed on the screen of the device HW' or on the screen of the host device HDV.

[0322] R2. Mutual authentication and secure channel creation between the orchestrator and the device

[0323] R2.1 Temporary certificate generated by the orchestrator

[0324] (peO,PeO)=AsymKeyGen()

[0325] Sign(pO,ReO||PeO)

[0326] CeO=PeO||Sign(pO,ReO||PeO)

[0327] R2.2 Send the orchestrator's certificate to the device

[0328] ORC1→HW'

[0329] CeO||CO

[0330] R2.3. Verify the orchestrator's certificate by the device

[0331] Verif CeO,Verif CO

[0332] R2.4. Device generates session key and encrypted temporary certificate

[0333] (peD,PeD)=AsymKeyGen()

[0334] k0=ECDH(peD,PeO)

[0335] Sign(pD,ReD||PeD)

[0336] {Sign(pD,ReD||PeD)}k0

[0337] CeD=PeD||{Sign(pD,ReD||PeD)}k0

[0338] {CD}k0

[0339] R2.5. Send the device HW's certificate to the orchestrator

[0340] [HW'→ORC1]

[0341] CeD||{CD}k0

[0342] R2.6. The session key k0 is generated by the orchestrator

[0343] k0=ECDH(peO,PeD)

[0344] CD={CD} -1 k0

[0345] Sign(pD,ReD||PeD)={Sign(pD,ReD||PeD)} -1 k0

[0346] R2.7. Verify the device's certificate by the orchestrator

[0347] Verif CeD,Verif CD

[0348] R3. Send data BCKID and certificates CeD, CD to server BCKi

[0349] [ORC1→BCKi]

[0350] For each server BCKi, i ranges from 1 to m

[0351] BCKID||CeD||CD→BCKi

[0352] The orchestrator ORC1 transmits to each backup server BCKi the backup identifier BCKID, the temporary certificate CeD and the certificate CD of the device HW′.

[0353] R4. Each server BCKi verifies the device's certificate

[0354] For each server BCKi, i ranges from 1 to m

[0355] Verif CeD,Verif CD

[0356] R5. Perform mutual authentication and create a secure channel between the server BCKi and the device through the orchestrator

[0357] R5.1 Generate a temporary certificate by each server BCKi

[0358] For each server BCKi, i ranges from 1 to m

[0359] (peBi,PeBi)=AsymKeyGen()

[0360] Sign(pBi,ReB||PeBi)

[0361] CeBi=PeBi||Sign(pBi,ReB||PeBi)

[0362] R5.2 Generate session keys from each server BCKi

[0363] For each server BCKi, i ranges from 1 to m

[0364] kBi=ECDH(peBi,PeD)

[0365] R5.3 Generate an encrypted hash code by each server BCKi

[0366] Hi=Hash(PeBi||BCKID||BCKDT)

[0367] CHi={Hi}kBi

[0368] R5.4 Each server BCKi transmits the corresponding certificate and encrypted hash code to the orchestrator

[0369] [BCKi→ORC1]

[0370] For each server BCKi, i ranges from 1 to m

[0371] RETDTi=CeBi||CBi||CHi

[0372] R5.5 transmits data received from the server BCKi to the device

[0373] [ORC1→HW']

[0374] {BCKID||BCKDT||RETDT1|...||RETDTi||...||RETDTm}k0

[0375] R5.6 The device decrypts the data string received from the orchestrator

[0376] {BCKID||BCKDT||RETDT1|...||RETDTi||...||RETDTm} -1 k0

[0377] R5.7 The user verifies the backup data

[0378] Validate BCKDT

[0379] The user verifies the backup data BCKDT, in particular the first name, last name, date of birth and optionally the place of birth.

[0380] R5.8 The device verifies the certificate of the server BCKi

[0381] For each server BCKi, i ranges from 1 to m

[0382] Verif CeBi,Verif CBi

[0383] R5.9 The device generates a session key kBi and verifies the encrypted hash code CHi

[0384] For each server BCKi, i ranges from 1 to m

[0385] kBi=ECDH(peD,PeBi)

[0386] {Hi} -1 kBi

[0387] Validate Hi(Hi=Hash(PeBi||BCKID||BCKDT)

[0388] R6. Prepare for recovery

[0389] R6.1 The device sends a recovery confirmation to the orchestrator

[0390] [HW'→ORC1]

[0391] {ConfirmRestore1}kB1||{ConfirmRestore2}kB2||...||{ConfirmRestore_i_}kBi||...

[0392] ||{ConfirmRestore_m_}kBm→ORC1

[0393] The device HW′ transmits back to the orchestrator ORC1 for each server BCKi an individual restoration confirmation “ConfirmRestore_i_” encrypted with the key kBi of each server BCKi. Each confirmation is a predefined binary code.

[0394] R6.2 Send recovery confirmation to server BCKi

[0395] For each server BCKi, i ranges from 1 to m

[0396] BCKID||{ConfirmRestore_i_}kBi→BCKi

[0397] The orchestrator ORC1 transmits to each server BCKi the concatenated backup identifier BCKID and a restoration confirmation {ConfirmRestore_i_}kBi intended for that server.

[0398] R6.3 is verified and restored by the server BCKi

[0399] For each server BCKi, i ranges from 1 to m

[0400] {ConfirmRestore_i_} -1 k

[0401] Store CD

[0402] Each server BCKi decrypts the confirmation message issued by device HW′ and communicated to it by orchestrator ORC1 and remembers the certificate CD of device HW′ that it has previously verified.

[0403] R6.4 After authentication, each server BCKi confirms that recovery can be initiated

[0404] [BCKi→ORC1]

[0405] For each server BCKi, i ranges from 1 to m

[0406] OK_for_IDV

[0407] After the user has confirmed his identity through step IDVi, each server BCKi indicates to the orchestrator ORC1 that it is ready to return the shard Si that it has backed up.

[0408] R7. Server IDVSRVi performs authentication step IDVi

[0409] For each server BCKi, i ranges from 1 to m

[0410] IDVRi

[0411] The user is redirected by orchestrator ORC1 to each server BCKi, and each server BCKi proceeds with its own verification of the user's pivot identity IDVi. In this embodiment, where step IDVi is delegated to a service provider, each server BCKi connects the user to a server IDVSRVi affiliated with those service providers via gateway GTW. The provider's service IDVSi proceeds with the verification of the user's identity, then confirms to orchestrator ORC1 that the user's identity has been verified and that the seed backup step can be initiated.

[0412] It should be noted that the duration of each authentication step IDVRi can range from a few minutes to several days, depending on the requirements of each server BCKi or the provider that performs the IDVRi. The verification of natural persons can be systematically planned by a specific IDV provider.

[0413] R8. Re-establish the secure communication channel after completing the authentication step IDVi

[0414] [HW'→ORC1]

[0415] Continue Restore

[0416] Once the authentication step is completed, sometimes after a few days, the user restarts the recovery step. The device HW' transmits a request "Continue Recovery" to the orchestrator ORC1 to proceed with the recovery.

[0417] Repeat steps R2.1 to R2.7, R3, R5.1 to R5.9

[0418] Since several days may pass during the implementation of the verification step IDVi, in one embodiment, the previous session credentials are not saved. Therefore, steps R2.1 to R2.7, R3, R5.1 to R5.9 are performed again to continue the recovery process from the point where it stopped, but using the new session keys k0 and kBi.

[0419] R9. Then restore

[0420] [ORC1→BCKi]

[0421] For each server BCKi, i ranges from 1 to m (or i ranges from 1 to n)

[0422] Continue Restore→BCKi

[0423] Once the secure channel is reopened with the new session key, the orchestrator passes the request to resume recovery to the servers BCKi. Note that if, during step IDVRi, one of the servers BCKi is unable to verify the user's identity with a certain degree of certainty, that server will refuse to return the shards it holds and will notify the orchestrator ORC1. In the event that a certain number of backup servers BCKi have not successfully verified the user's identity and refuse to return the data they hold, the orchestrator can be configured to suspend the return of shards by servers that have successfully verified the user's identity. The orchestrator can optionally decide to subject the user to additional procedures for verifying their identity. The orchestrator can also be configured to analyze the certainty score regarding the user's identity verification, as noted above, and make decisions based on this analysis.

[0424] Furthermore, in a variation of the method mentioned above and as indicated in the brackets below, if only n shards are needed to reconstruct the seed (n is less than m), this step is limited to n backup servers BCKi, rather than all backup servers.

[0425] R10. Verification of device certificates

[0426] For each server BCKi, i ranges from 1 to m (or i ranges from 1 to n)

[0427] Verif CD=CD

[0428] Each server BCKi ensures that the certificate CD of the device HW′ is identical to the certificate CD received and stored before the authentication step IDVi.

[0429] R11. The server BCKi transmits the shards to the orchestrator

[0430] For each server BCKi, i ranges from 1 to m (or i ranges from 1 to n)

[0431] {S1}kB1||{S2}kB2||...||{Si}kBi||...||{Sm}kBm→ORC1

[0432] Each server BCKi transmits the shard Si it holds to the orchestrator ORC1, where the shard Si is encrypted using the server's key kBi, which is unknown to the orchestrator.

[0433] R12. Transferring shards from the orchestrator to the device

[0434] {S1}kB1||{S2}kB2||...||{Si}kBi||...||{Sm}kBm→HW'

[0435] The orchestrator ORC1 transmits to the device HW′ all the shards Si received from the server BCKi in encrypted form with the key kBi.

[0436] R13. The device decrypts the shards and recovers the seed

[0437] For each server BCKi, i ranges from 1 to m (or i ranges from 1 to n)

[0438] {Si} -1 kBi

[0439] S=SS -1 (S1,S2,...Si...Sm)

[0440] (or S=SS -1 (S1,S2,...Si...Sn))

[0441] After decrypting each slice of rank i by means of the corresponding key kBi, the device HW′ recovers the seed from the received slices or, if the number of these slices is greater than n, from a part of these slices.

[0442] R14. Final Confirmation

[0443] OK→ORC1

[0444] Device HW' confirms to orchestrator ORC1 that seed recovery is complete.

[0445] It will be clear to those skilled in the art that the method described is applicable to many other variants and embodiments. The structure of the certificate involved in the method has been described above according to two variants, for example:

[0446] Cx=[Px,Sign(pL,Px)]

[0447] Cex=Pex||{Sign(px,Rex||Pex)

[0448] Temporary certificates can also be of the following types:

[0449] Cex=Pex||{Sign(px,Pex)

[0450] The method can also be implemented with any certificate structure. Specifically, an X509 certificate can be used. Similarly, other encryption functions or cryptographic algorithms can be used, particularly in the context of a specific implementation based on RSA cryptography.

[0451] Figure 6A A system for implementing the method of the present invention is shown. Figure 3A The system differs in that the server ORCSRV1 is replaced by a server ORCSRV2 that executes an orchestrator program ORC2 (hereinafter referred to as "orchestrator ORC2"). Orchestrator ORC2 differs from orchestrator ORC1 in that it does not ensure that the data sent by the backup server BCKi is sent to the device HW and vice versa, and therefore does not act as a gateway or "proxy server".

[0452] When the user initiates the seed backup step, the device HW directs the backup request BCKRQ to the orchestrator ORC2, which then proceeds to the previously described steps of generating a backup identifier BCKID and collecting information about the user to generate the backup data BCKDT. The orchestrator also performs an initial step IDV0 of verifying the user's pivot identity (i.e., at least their first name, last name, and date of birth). If this step is confirmed, the orchestrator delivers backup authorizations BCKPASSi to the device HW, one for each backup server BCKi, and transmits each authorization to the relevant server BCKi.

[0453] Each authorization BCKPASSi forms a kind of "pass" that allows the device HW to know which server BCKi it should be directed to connect to in order to back up the seed's shard Si, and allows it to connect to the server BCKi to continue the backup without being rejected by that server. Each authorization BCKPASSi may include various pieces of information, in particular information previously in the backup data BCKDT and the identifier BCKID. The authorization BCKPASSi is saved by the supporting software and is preferably saved in the user account UACC on the account server UASRV. In one variant, the orchestrator delivers a universal authorization BCKPASS that contains the concatenation of all the information contained in the authorization BCKPASSi.

[0454] refer to Figure 6B When the user wishes to restore the seed, the companion software connects to the backup server BCKi identified by the address contained in the authorization BCKPASSi, and then returns operational control to the device HW so that the device can establish a secure channel with the backup server BCKi through the key exchange as described above. Once the secure channel has been established, the backup server BCKi enters the step IDVi of verifying the user's fulcrum identity.

[0455] The supervisory role for step IDVi, previously delegated to orchestrator ORC1, is now transferred to orchestrator ORC2. This orchestrator is then requested by backup server BCKi to analyze the results of step IDVi. If these results are positive, orchestrator ORC2 delivers the recovery authorization RESTPASSi to device HW, which it also communicates to backup server BCKi. Device HW then reestablishes a secure channel with backup servers BCKi and presents them with the authorization RESTPASSi to restore seed shard Si.

[0456] In the eventual case that the user may have closed their account on the account server UASRV, may have uninstalled the companion software by deleting the data it contained and therefore may no longer be able to restore the authorization BCKPASSi, and in the eventual case that the orchestrator ORC2 may no longer exist, a solution is provided to allow the user to restore their seed by allowing the user to go through multiple separate steps of verifying their identity with each backup server BCKi.

[0457] In the event of a complete system failure or the identifier BCKID ( Figure 3A 、 Figure 3B In an embodiment of the invention) or in a variant that authorizes the restoration of a shard in the event of loss of BCKPASSi, provision may be made for the organization responsible for orchestrator ORC1 or ORC2 to deliver to the user, for example by postal mail, a backup certificate accompanied by an inviolable certificate of authenticity (such as a hologram). Such a backup certificate will not save the user the step of verifying their identity with the backup server, but will contain sufficient information to provide an additional degree of certainty regarding the authenticity of their identity as the legitimate holder of the seed when performing the verification step IDVi.

[0458] Figure 7An example of a specific implementation of a hardware wallet HW that allows the implementation of the method is shown. The device HW comprises a secure element SE1, a microcontroller MCU1 and a touch screen TS1. The touch screen TS1 comprises an electronic ink display EID and a touch module TM. The touch screen TS1 is controlled by the secure element SE1. To this end, the input / output resources of the secure element SE1 are divided into three groups of inputs / outputs: IOGA, IOGB, IOGC. The input / output group IOGA is assigned to implement a bus BS1 that connects the secure element SE1 to the microcontroller MCU1. The input / output group IOGB is assigned to implement a bus BS2 that connects the secure element SE1 to the display EID, and the input / output group IOGC is assigned to implement a bus BS3 that connects the secure element SE1 to the touch module TM. Bus BS1 is, for example, an IEC / ISO 7816 bus, bus BS2 is, for example, an SPI bus, and bus BS3 is an I2C bus. The secure element is, for example The device hardware also includes various peripherals controlled by the microcontroller MCU1, such as:

[0459] -Battery BAT;

[0460] an integrated circuit PMIC for power management, which receives a voltage Vbat from the battery when it is being charged, supplies the voltage Vbat to the battery when it needs to be charged, and provides a regulated supply voltage Vcc to the microcontroller MCU1, the secure element SE1 and the touch screen TS1;

[0461] an antenna QiA for inductively charging the battery using Qi technology. The antenna QiA is connected to a wireless charging integrated circuit WCIC. The WCIC circuit supplies a voltage Vqi to the PMIC circuit for charging the battery;

[0462] USB port U1. This USB port supplies a voltage Vusb to the circuit PMIC for charging the battery, supplies data DTu received from an external device connected to this USB port to the microcontroller MCU1, and transmits data DTu to the external device;

[0463] A Bluetooth antenna BTA receives radio frequency signals RFS provided by a Bluetooth management circuit BTM. This circuit BTM provides data DTb to be exchanged with an external device via a Bluetooth connection or to be sent to the external device via a Bluetooth connection.

[0464] The device hardware features a touchscreen controlled exclusively by the secure element SE1, making it invulnerable even if the microcontroller MCU1 is compromised. The microcontroller does not execute any applications and does not store any cryptographic secrets used by the secure element. The microcontroller manages peripheral devices solely by sending data DTb and DTu received via the user's selected communication interface to the secure element, or by sending data DTb and DTu provided by the secure element to external devices. Therefore, the device hardware does not offer any direct internet connection, and despite its touchscreen, it remains a hardware wallet for cold storage of private keys, providing a high degree of security. The secure element SE1 also includes a memory space MS1, which comprises a read-only memory area, a non-volatile electrically erasable programmable memory area, and a volatile memory area. The non-volatile electrically erasable programmable memory area receives the secure element's operating system, which is configured to implement the method of the present invention.

[0465] The device HW is well suited for implementation of this method due to its touch screen, which can be selected to be large in size and exhibit, for example, a diagonal greater than or equal to 3.5 inches (one inch equals 2.54 cm) and include at least 600×400 pixels. In an embodiment, the screen has a diagonal of 3.9 inches (9.906 cm) and provides 670×496 pixels, which constitutes a very large screen for a crypto asset hardware wallet without an Internet connection.

[0466] Tables 2 and 3 below and Figure 8 and Figure 9 An example configuration of a device HW and companion software HSW for implementing an embodiment of the method of the present invention is described, in which three backup servers are used, so that the seed is backed up across three shards. The device HW is used in conjunction with a host device HDV, to which the device HW can be connected via its USB or Bluetooth interface. In addition to the device HW's touch screen TS1, the host device HDV has its own screen, which allows a user USR to perform certain steps of the method using the companion software and other steps using the device HW.

[0467] In Tables 2 and 3, the instructions in parentheses correspond to virtual buttons that the user must press to select the option of their choice. The instructions in quotation marks are information displayed by the device HW or host device HDV. The instructions "xx" correspond to areas of the display or areas where the user provides the requested information.

[0468] Table 2 below and Figure 8A specific implementation of the method for backing up seeds is described. During step D0, the supporting software offers the user the following options: (i) backing up seeds, (ii) initializing or restoring the device HW. It is assumed here that the device HW has been previously enabled, but the user has never backed up their seeds. Therefore, the user selects the first option. During step D1, the supporting software offers the user two options, namely: a regular backup, in which the recovery phrase is displayed by the device HW so that the user can save the recovery phrase according to his own choice; or a backup implemented by calling an automatic protection service that implements the method according to the present invention. During step D3, the user is invited to create an account on the customer account server. During step D4, the user creates the account and provides information related to their identity, at least part of which constitutes the information of the user's fulcrum identity incorporated into the backup data BCKDT. During step D5, they define the password for their account.

[0469] During step D6, the companion software reminds the user that they will have to go through an identity verification step. This is step IDV0, which allows the orchestrator to ensure that the information constituting the user's pivot identity is correct, specifically the user's first name, last name, and date of birth. Step IDV0 is performed using the host device HDV's screen and its camera at steps D7 to D11. Once step IDV0 has successfully completed, the user should connect the device HW to the host device HDV at step D12.

[0470] The device HW then takes care of the rest of the method by asking the user to enter their password at step D13 and then verifying their identity at steps D14 and D15. The device HW then proceeds to back up the seed at step D16.

[0471] Table 3 below and Figure 9 The seed recovery steps are described. At step D0, the user selects the Initialize / Restore option. During step D20, the companion software asks the user to connect the device HW' to the host device HDV. During step D21, the companion software and the device HW' confirm that the connection has been made. During step D22, the user enters the password of the device HW'. During step D22, the device HW' suggests that the user specify whether they want to initialize the device HW' as a new device or whether they want to continue with the recovery according to the recovery phrase. Here, the user selects the "Restore" option. During step D24, the device HW' asks the user whether they want to restore the device HW' by means of the protection service according to the invention or according to the recovery phrase they have saved (manual recovery). The user selects the protection service.

[0472] During step D25, the companion software takes care of the rest of the method and informs the user that they will have to go through three authentication steps. The first authentication step will be performed using device HW', and the other two authentication steps will be performed using the IDV provider. During step D26, the user should confirm the information about their pivot identity displayed by device HW' (during this step, device HW' may display additional information forming the pivot identity, as shown in Table 3). During step D27, the companion software indicates to the user that they will be contacted with the first IDV partner and asks the user to confirm their consent. The user's consent causes the companion software to connect to the partner server IDVSRVi via its gateway GTW, as described above. During steps D28 to D32, the user uses the screen and camera of the host device HDV to perform the actions requested by the first IDV partner to obtain the information required for the first authentication. During step D33, the companion software indicates to the user that they will be contacted with the second IDV partner and asks the user to confirm their consent. The user's consent causes the companion software to connect to another partner server IDVSRVi via its gateway GTW. During the steps summarized in the table by a single step D34, the user performs the actions requested by the second IDV partner to obtain the information required for the second authentication. These steps may be the same, similar, or different from those for the first authentication. It should be noted that after performing these steps, the authentication is not complete, and the results of each authentication may be delayed for several hours or even days, as explained above. When the user's identity has been verified, the device HW' recovers the seed's fragments S1, S2, and S3 and restores the seed during step D35.

[0473] It will be clear to those skilled in the art that the method just described can also be implemented using other types of crypto asset wallets besides the crypto asset wallet just described. Figure 10The crypto-asset wallet CW2 of the type shown is implemented as a secure microcontroller SMCU, a screen TS2, which can be a touchscreen, and a communication interface circuit CINT1, which specifically includes Wi-Fi and / or Ethernet connectivity and allows it to connect to the internet. The secure microcontroller uses two virtual processors associated with hardware access control, allowing it to manage two application execution zones TZ and NTZ, each providing different levels of security. These zones are referred to as "trust zones." In certain embodiments, the secure microcontroller may be equipped with a secure element SE2, which is coupled to the trust zone TZ to perform cryptographic calculations and carry out the most security-sensitive operations, particularly storing seeds and various crypto-asset account keys. While using the same kernel, each zone can function independently of the other. Typically, the microcontroller executes a so-called "rich" operating system (e.g., Android) in the less-reliable zone NTZ and executes specialized code in the trust zone TZ. This device is equivalent to a combination of the hardware wallet HW (equivalent to the trust zone) and the host device HDV (equivalent to the less-secure zone) described above, and does not require connection to the host device to perform operations on the blockchain.

[0474] The method of the present invention can also be implemented using a software-based crypto-asset wallet ("software wallet"). Unlike online wallets, software wallets allow crypto-asset keys to be stored directly on a desktop computer, laptop computer, mobile phone, or equivalent. Users retain ownership of their keys and seeds and should protect their storage security by ensuring that fraudsters cannot obtain them. As an example, Figure 11 A software-based crypto-asset wallet CW3 is shown, executed by an electronic device DV, which may be a device of the type described above, a mobile phone, or the like. Device DV comprises a microprocessor MPU equipped with a communication interface CINT2 allowing it to connect to the internet, volatile RAM memory, and non-volatile memory NVM, such as a magnetic hard drive or solid-state drive (SSD). The program CW3 forming the software crypto-asset wallet is stored in the non-volatile memory NVM of device DV and executed by the microprocessor MPU using its RAM memory.

[0475] Table 2: Seed backup, interaction between user, hardware wallet HW and host device HDV

[0476] [Table 2]

[0477]

[0478]

[0479] Table 3: Seed recovery, user interaction with hardware wallet HW' and host device HDV

[0480] [Table 3]

[0481]

[0482]

[0483]

Claims

1. A method for backing up and restoring secrets (S) held by a crypto-asset wallet (CW1, CW2, CW3, HW, HDV), characterized in that, in order to back up the secrets, the method comprises the following steps: —Provide multiple backup servers (BCKi), — collect (B3) information related to the user’s identity (BCKDT), - communicating (B6) said information (BCKDT) relating to the identity of said user to each backup server, — generating, by said crypto-asset wallet, a plurality of secret data (Si) from said secret (S), and - transmitting (B11, B12) one of the secret data provided by the crypto-asset wallet to each backup server in encrypted form ({Si}kBi) and associating the secret data with the identity of the user in the backup server.

2. The method of claim 1 , wherein each encrypted data ({Si}kBi) is encrypted using an encryption key (kBi) known only to the crypto-asset wallet and the backup server to which the encrypted data is intended.

3. The method according to one of claims 1 and 2, wherein the information related to the identity of the user comprises at least the first name, last name and date of birth of the user.

4. The method according to claim 1 , wherein the crypto-asset wallet is configured to generate a plurality of secret data (Si) by means of a secret sharing function (SS), the secret sharing function being designed to generate m secret data from the secret (S) and allowing reconstruction of the secret (S) from a threshold n secret data.

5. The method according to claim 1 , wherein the crypto-asset wallet (CW1) comprises a hardware wallet (HW) that is unable to connect to the internet and is connected or configured to connect to a host device (HDV) that executes companion software (HSW) and has an internet connection.

6. The method according to claim 1 , wherein, in order to recover the secret, the method comprises the following steps: - communicating (R3) said information (BCKDT) relating to the identity of said user to each backup server, — receiving (R11) by the crypto-asset wallet all or part of the secret data (Si) held by the backup server in encrypted form ({Si}kBi), and - reconstructing (R13) the secret from the secret data ({Si}kBi) provided by the backup server after decrypting the secret data by the crypto-asset wallet.

7. The method according to claim 1 , comprising the steps of: — providing an orchestrator program (ORC1) to be executed by a server (ORCSRV1), and —Configuring the orchestrator program and the crypto-asset wallet to perform at least one of the following steps: — during backing up the secrets, the crypto-asset wallet transmits the secret data generated by the crypto-asset wallet to the orchestrator program, and the orchestrator program transmits (B12) the secret data received from the crypto-asset wallet to the backup server, and During recovery of the secret, receiving (R11) by the orchestrator program all or a portion of the secret data held by the backup server, and transmitting (R12) by the orchestrator program the secret data to the crypto-asset wallet.

8. The method according to claim 7, comprising the steps of: — establishing a first secure communication channel between the crypto-asset wallet and the orchestrator program (ORC1) via a first session key (k0) generated following a key exchange (PD, PeD, PO, PeO) between the crypto-asset wallet and the orchestrator program (ORC1), and —establishing, via the orchestrator program (ORC1), a second secure communication channel between the crypto asset wallet and each backup server (BCKi) using a plurality of second session keys (kBi) generated following a key exchange (PD, PeD, PBi, PeBi) between the crypto asset wallet and each backup server (BCKi) via the orchestrator program (ORC1).

9. The method of claim 8, wherein the orchestrator program (ORC1) and the crypto-asset wallet each possess a private key (pO, pD), a public key (PO, PD), a certificate (CO, CD) signed by a certification authority (CA), and a public key (PL) provided by the certification authority, and wherein: — the orchestrator program transmits (B5.2) the certificate (CO) of the orchestrator program to the crypto-asset wallet, — the crypto-asset wallet transmits (B5.5) the certificate (CD) of the crypto-asset wallet to the orchestrator program, — the orchestrator program generates (B5.1) a temporary private key (peO), a temporary public key (PeO), and a temporary certificate (CeO) signed with the private key (pO) of the orchestrator program, and transmits (B5.2) the temporary certificate of the orchestrator program to the crypto-asset wallet, — the crypto-asset wallet generates (B5.4) a temporary private key (peD), a temporary public key (PeD), and a temporary certificate (CeD) signed with the private key (pD) of the crypto-asset wallet, and transmits (B5.5) the temporary certificate of the crypto-asset wallet to the orchestrator program, —The crypto asset wallet obtains the temporary private key (peD) from the crypto asset wallet and said temporary public key (PeO) of said orchestrator program generates (B5.4) said first session key (k0), —The orchestrator program generates (B5.6) the first session key (k0) from the temporary private key (peO) of the orchestrator program and the temporary public key (PeD) of the crypto-asset wallet.

10. The method of claim 9, wherein prior to transmitting the temporary credentials of the crypto-asset wallet to the orchestrator program: — the crypto-asset wallet generates (B5.4) a first signature of the temporary public key (PeD) of the crypto-asset wallet from the private key (pD) of the crypto-asset wallet, — the crypto-asset wallet encrypts (B5.4) the first signature by the first session key (k0) to obtain an encrypted signature, — the crypto-asset wallet transmits (B5.5) the temporary public key (PeD) of the crypto-asset wallet and the cryptographically signed temporary certificate (CeD) to the orchestrator, Then: — the orchestrator program generates (B5.6) the first session key (k0) from the temporary private key (pe0) of the orchestrator program and the temporary public key (PeD) of the crypto-asset wallet, and - The orchestrator program decrypts (B5.7) the signature present in the temporary certificate (CeD) by means of the first session key (k0).

11. The method according to claim 10, wherein the crypto-asset wallet concatenates (B5.4) the temporary public key (PeD) of the crypto-asset wallet with data (ReD) before generating the first signature of the temporary public key (PeD) of the crypto-asset wallet from the private key (pD) of the crypto-asset wallet.

12. The method according to claim 10 , comprising the steps of: - the crypto-asset wallet encrypts (B5.4) the certificate (CD) of the crypto-asset wallet with the first session key (k0) before transmitting (B5.5) the certificate to the orchestrator program, and —The orchestrator program decrypts the certificate (CD) of the crypto-asset wallet using the first session key (k0) (B5.7).

13. The method according to claim 9 , wherein the backup servers (BCKi) each possess a private key (pBi), a public key (PBi), a certificate (CBi) signed by a certification authority (CA), and a public key (PL) provided by the certification authority, — said orchestrator program transmits (B6) said certificate (CD) of said crypto-asset wallet and said temporary certificate (CeD) of said crypto-asset wallet to each of said backup servers (BCKi), — Each backup server transmits (B8.4) the certificate (CBi) of the backup server to the orchestrator program, and the orchestrator program transmits (B8.5) the certificate to the crypto-asset wallet, — Each backup server (BCKi) generates (B8.1) a temporary private key (peBi), a temporary public key (PeBi), and a temporary certificate (CeBi) signed with the private key (pBi) of the backup server, and transmits (B8.4) the temporary certificate to the orchestrator program, which transmits (B8.5) the temporary certificate to the crypto-asset wallet, — each backup server generates (8.2) the second session key (kBi) from the temporary private key (peBi) of the backup server and the temporary public key (PeD) of the crypto-asset wallet, and The crypto-asset wallet generates (8.9) the second session key (kBi) of each backup server from the temporary private key (peD) of the crypto-asset wallet and the temporary public key (PeBi) of the backup server.

14. The method according to claim 13, comprising the steps of: — for each backup server, the crypto-asset wallet encrypts (B10) the secret data intended for the backup server with the second session key (kBi), transmits (B11) the encrypted secret data to the orchestrator program, and the orchestrator program transmits (B12) the encrypted secret data to the backup server, and - Each backup server decrypts (B13) the received secret data (Si) by means of said second session key (kBi) and stores the decrypted secret data in a memory (MEM).

15. The method according to one of claims 13 and 14, wherein: — the crypto-asset wallet verifies (B5.3) the validity of the certificate (CO) of the orchestrator program using the public key (PL) of the certification authority, — the crypto-asset wallet verifies (B5.3) the validity of the temporary certificate (CeO) of the orchestrator program using the public key of the certificate (CO) of the orchestrator program, — the crypto asset wallet verifies (B8.8) the validity of the certificate (CBi) of each backup server (CBi) by using the public key (PL) of the certification authority, — the crypto asset wallet verifies (B8.8) the validity of the temporary certificate (CeBi) of each backup server by using the public key of the certificate (CBi) of each backup server, — the orchestrator program verifies (B5.7) the validity of the certificate (CD) of the crypto-asset wallet by means of the public key (PL) of the certification authority, — the orchestrator program verifies (B5.7) the validity of the temporary certificate (CeD) of the crypto-asset wallet by means of the public key of the certificate (CD) of the crypto-asset wallet, — Each backup server verifies (B7) the validity of the certificate (CD) of the crypto-asset wallet by means of the public key (PL) of the certification authority, and —Each backup server (BCKi) verifies (B7) the validity of the temporary certificate (CeD) of the crypto-asset wallet by means of the public key of the certificate (CD) of the crypto-asset wallet.

16. The method according to claim 13 , wherein the data sent by the backup server to the orchestrator program is resent ( 8.5 ) by the orchestrator program to the crypto-asset wallet in a form encrypted by the first session key ( k0 ), and wherein some of the data ( RETDTi ) is previously hashed ( B8.3 ) by the backup server using a hash function and then encrypted ( B8.3 ) by the second session key ( kBi ).

17. Method according to one of the preceding claims, wherein before providing (R11) said secret data (Si) held by at least one backup server, said at least one backup server subjects said user to an authentication step and refuses to return said secret data if said verification of said user's identity is not conclusive.

18. A cryptoasset wallet (CW1, HW, HDV, CW2, CW3) holding or intended to hold a secret (S), the cryptoasset wallet being characterized in that the cryptoasset wallet is configured to provide a user with the following options: - manually backing up the secret in the form of a recovery phrase for saving by the user (D2.1), or - backing up the secret in multiple backup servers (D2.2), and In the case where the user chooses to back up the secret in multiple backup servers: - in the presence of the user, performing a step of collecting (B3, D4, BCKID, D8-D11, D28-D32, D34) information related to the identity of the user, and performing a step of communicating (B6, D9, D11, D30, D32) the information related to the identity of the user to each backup server, - generating a plurality of secret data (Si) from said secret (S), and - transmitting (B12) said secret data in encrypted form ({Si}kBi) to said plurality of backup servers (BCKi).

19. The crypto asset wallet of claim 18, wherein the crypto asset wallet is configured to further provide the user with the following options: - manually recover the secret from the recovery phrase (D24.2), or - recover the secret from multiple backup servers (D24.2), and In case the user chooses to restore the secret from a plurality of secret data held by a plurality of backup servers, the secret is reconstructed (R13) from the data provided by the backup servers.

20. The crypto-asset wallet according to one of claims 18 and 19, wherein the crypto-asset wallet is configured to generate a plurality of secret data (Si) from the secret (S) by means of a secret sharing function (SS), the secret sharing function being designed to generate m secret data and to allow reconstruction of the secret (S) from a threshold n secret data (Si).

21. The crypto asset wallet according to one of claims 18 to 20, wherein the crypto asset wallet is configured to: - transmitting (B12) said secret data to said plurality of backup servers (BCKi) by means of an orchestrator program (ORC1) executed by a server (ORCSRV1), and - Restoring (R12) each of the data provided by the backup server by the orchestrator program.

22. The crypto-asset wallet of claim 19, wherein the crypto-asset wallet is configured to, upon request of a backup server, perform at least one step of verifying the identity of the user if the user chooses to restore the secret based on the secret data.

23. The crypto-asset wallet (CW1) according to one of claims 18 to 22, comprising a hardware wallet (HW) that cannot be connected to the Internet and a host device (HDV) that executes supporting software (HSW) and has an Internet connection, wherein the supporting software supplements the hardware wallet (HW) to implement the steps (D1-D13, D20-D38) that require interaction with the user, in particular the steps of collecting information related to the identity of the user.

24. The crypto-asset wallet according to claim 23, wherein the hardware wallet (HW) comprises a touch screen (TS) having a diagonal greater than or equal to 3.5 inches and being exclusively controlled by a secure element (SE), the touch screen being specifically used to collect information related to the identity of the user.

Images