Method for linking a backup of a secret to an identity of a person

Abstract

A method for backing up and restoring a secret held by a secure electronic device, the method comprising a step of backing up the secret, the step comprising: providing a plurality of backup servers (BCKi); collecting data (PID) defining the identity of a first user and communicating the data to each backup server; generating, using the secure electronic device, a plurality of secret shards (Si) from the secret; transmitting one of the secret shards (Si) to each backup server; and generating (B13.2.a, B13.2.b, B13.2.c, B13.2.d, B13.2.e) in each backup server encrypted link data (LNKSi) that is a function of the secret shard (Si) and the data (PID) defining the identity of the first user; and storing the encrypted link data in a memory of the backup server.

Description

Technical Field

[0001] This invention relates to a method for backing up and restoring secrets held by secure electronic devices. In particular, this invention relates to the backup and restoration of master keys held by a hierarchical deterministic hardware wallet used to store private keys associated with cryptographic asset accounts. Background Technology

[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 (“smart contracts”), has spurred various methods for storing and maintaining the private and public keys associated with these different types of crypto assets. This has led to the creation of crypto asset wallets (commonly referred to as “wallets”) for storing and maintaining these keys. A crypto asset wallet is a hardware or software device that functions to store the private and public keys associated with a crypto asset account and to sign transactions using these keys. There is a distinction between so-called “hot” wallets (“hot wallets”) and so-called cold wallets (“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 wallet”). Such wallets are connected to the internet and are therefore inherently vulnerable to attack. On the other hand, “cold” wallets or hardware wallets (“hardware wallets”) do not have direct internet access, which reduces the attack surface and thus lowers the risk of theft by hackers. Hardware wallets are typically portable electronic devices equipped with a processor that has a cryptographic computing device. Signing transactions involving private keys in an offline environment. Any online transactions executed are temporarily transferred to a hardware wallet for offline digital signing before the signature is sent to the online network. Because the private keys are not transmitted to the online server during the signing process, hackers cannot access them.

[0003] Therefore, this type of hardware wallet is now considered the most secure solution against hacking. The only drawback is the risk of the hardware wallet being lost, stolen, or destroyed (e.g., by fire), or the loss of the personal password of the user authorized to use the hardware wallet. Therefore, the keys contained in the hardware wallet must typically be backed up in a secure location.

[0004] The first problem that arose was finding a way to simplify the number of keys that needed to be backed up, which could be enormous if a user had many crypto asset accounts on the blockchain. To address this, the hierarchical deterministic wallet was proposed. First proposed in the BIP32 standard and then optimized with BIP39, BIP43, and BIP44 standards, this wallet allows users to perform a single backup of all keys in their wallet without having to perform a new backup for every new key pair generated. 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 (often called the "seed" or "master key"). Users only need to keep the seed in a secure place to recover all their keys, which are derived from the seed and can be reconstructed from that seed ("subkeys").

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

[0007] To generate the mnemonic phrase, the hardware wallet uses a random number generator to generate 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. These 264 bits are divided into 24 groups of 11 bits each. Each 11-bit group is interpreted as a number between 0 and 2047, which is used as an index to the BIP39 word list, thus enabling the generation of a 24-word mnemonic phrase. Therefore, this type of wallet preferably requires only a single backup of the seed upon activation, from which the entire downlink key tree can be derived.

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

[0009] Once linked to the host device, the device HW can interact with the accompanying software to allow user USRs to transact on the blockchain BCN or on decentralized exchanges. The device HW can also communicate with a security module HSM (“Hardware Security Module”) located in the data center. The HSM module is typically a hardware encryption box that allows for the generation, storage, and protection of cryptographic keys. The HSM module does not store any user private keys; instead, it only ensures verification of: the authenticity of the device HW, the device's activation, updates to the device's operating system, the download of certified applications, and so on.

[0010] During the initial activation of the device HW, the device provides the user with a 24-word phrase that the user must save on an appropriate physical medium (such as a piece of paper or an immutable medium, such as an engraved metal plate), and the user must store the physical medium in a safe place.

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

[0012] Therefore, it may be desirable to provide a means that allows users to have a simple and convenient way to store their seeds in a highly secure manner, and more generally, to provide a method for backing up and restoring secrets held by secure electronic devices.

[0013] It may also be expected that a backup of the secret will be linked to the individual's identity in a way that can withstand attacks from fraudsters who intend to replace the identity of the legitimate holder of the secret with that of another person. Summary of the Invention

[0014] The implementation scheme relates to a method for backing up and restoring a secret held by a secure electronic device. The method includes the step of backing up the secret, which comprises the following steps: providing multiple backup servers; collecting data defining the identity of a first user and transmitting that data to each backup server; using the secure electronic device, generating multiple secret fragments from the secret; transmitting one of these secret fragments to each backup server; and generating encrypted link data in each backup server, the encrypted link data being a function of the secret fragment and the data defining the identity of the first user, and storing the encrypted link data in the memory of that backup server.

[0015] According to one implementation, in at least one backup server, the step of generating the encrypted link data includes the following steps: generating a backup code based on the identity of the first user; combining the secret fragment and the backup code; and encrypting the combination of the secret fragment and the backup code using a secret key of the backup server.

[0016] According to one implementation, in at least one backup server, the step of generating the encrypted linked data includes the following steps: generating a backup code based on the identity of the first user; using the backup code as a derivation diversifier, applying a key derivation function to the secret key of the backup server to obtain a first derivation key as a function of the data defining the identity of the first user; and encrypting the secret fragment using the first derivation key.

[0017] According to one implementation, in at least one backup server, the step of generating the encrypted link data includes the following steps: generating a backup code based on the identity of the first user; combining the secret fragment and the backup code; and hashing the combination of the secret fragment and the backup code to obtain the encrypted link data. The method further includes: encrypting the secret fragment using a secret key of the backup server, and storing the encrypted secret fragment in the memory of the backup server.

[0018] According to one embodiment, in at least one backup server, the step of generating the encrypted link data includes the following steps: encrypting the secret fragment using the backup server's secret key; generating a backup code based on the identity of the first user; combining the encrypted secret fragment and the backup code; and encrypting the combination of the encrypted secret fragment and the backup code using the backup server's secret key and a cryptographic hash function, the method further including the step of storing the encrypted secret fragment in the memory of the backup server.

[0019] According to one implementation, the step of generating the backup code includes concatenating data that defines the user's pivot identity.

[0020] According to one implementation, the step of generating the backup code includes concatenating data defining the user's pivot identity and hashing the concatenated pivot identity data.

[0021] According to one implementation, the method includes a step of recovering the secret, which includes the following steps: collecting data defining the identity of a second user; verifying the validity of the data with the participation of the second user, and providing the data to at least one backup server; and using the backup server to verify that the identity of the second user is the same as the identity of the first user based on the encrypted link data.

[0022] According to one implementation, the step of verifying the identity of the second user includes at least one of the following operations: decrypting the encrypted link data, extracting the identity of the first user or data that is a function of the first user's identity, and comparing the identity or the data with the identity of the second user or data that is a function of the second user's identity; decrypting the encrypted link data using a key that is a function of the second user's identity; calculating new encrypted link data from the second user's identity, and comparing the new encrypted link data with the initial encrypted link data.

[0023] According to one implementation, the method includes a step of recovering the secret, the step comprising the following steps: collecting data defining the identity of a second user, verifying the validity of the data with the participation of the second user, and providing the data to at least one backup server; and using the backup server to: generate a recovery code based on the identity of the second user, decrypt the encrypted linked data using the backup server's secret key, and extract the backup code therefrom; compare the recovery code with the backup code; and if the two codes are the same, return the secret fragment present in the encrypted linked data, and if the two codes are different, refuse to return the secret fragment.

[0024] According to one embodiment, the method includes a step of recovering the secret, the step comprising the following steps: collecting data defining the identity of a second user, verifying the validity of the data with the participation of the second user, and providing the data to at least one backup server; and using the backup server to: generate a recovery code based on the identity of the second user; apply the key derivation function to the secret key of the backup server using the recovery code as a derivation distinguisher to obtain a second derivation key as a function of the data defining the identity of the second user; and if the first derivation key and the second derivation key are the same, decrypt the encrypted linked data using the second derivation key, and extract the secret fragment therefrom.

[0025] According to one implementation, the method includes a step of recovering the secret, the step comprising the following steps: collecting data defining the identity of a second user, verifying the validity of the data with the participation of the second user, and providing the data to at least one backup server; and using the backup server to: generate a recovery code based on the identity of the second user; decrypt the secret fragment using the secret key of the backup server; combine the secret fragment and the recovery code, and hash the combination of the secret fragment and the recovery code to obtain new encrypted link data; compare the new encrypted link data with the encrypted link data; and if the new encrypted link data and the encrypted link data are the same, return the secret fragment; otherwise, refuse to return the secret fragment.

[0026] According to one implementation, the method includes a step of recovering the secret, which includes the following steps: collecting data defining the identity of a second user, verifying the validity of the data with the participation of the second user, and providing the data to at least one backup server; and using the backup server to: generate a recovery code based on the identity of the second user; combine the secret fragment and the recovery code, and encrypt the combination of the secret fragment and the recovery code using the backup server's secret key and the cryptographic hash function to obtain new encrypted link data; compare the new encrypted link data with the encrypted link data; if the new encrypted link data and the encrypted link data are the same, then decrypt the secret fragment and return the secret fragment; otherwise, refuse to return the secret fragment.

[0027] According to one implementation, the step of generating the recovery code includes concatenating data that defines the user's pivot identity.

[0028] According to one implementation, the step of generating the recovery code includes concatenating data defining the user's pivot identity and hashing the concatenated pivot identity data.

[0029] According to one implementation plan, a user's identity is defined by at least the user's first name, last name, and date of birth.

[0030] According to one implementation, the secure electronic device is configured to generate multiple secret fragments using a secret sharing function, which is set to generate m secret fragments from the secret and allow the secret to be reconstructed from a threshold of n secret fragments.

[0031] According to one implementation, the secure electronic device includes a hardware wallet for a crypto asset account, which does not have any device for connecting to the Internet. The hardware wallet is linked to or configured to be linked to a host device that executes accompanying software and has a connection to the Internet.

[0032] The implementation scheme relates to a server for backing up and returning secret data items, the server being configured to, in response to a request to back up the secret data item,: receive the secret data item; receive data defining the identity of a first user; generate encrypted link data, the encrypted link data being a function of the secret data item and the data defining the identity of the first user; and store the encrypted link data in the server's memory.

[0033] According to one implementation, the server is configured to generate the encrypted link data by performing the following steps: generating a backup code based on the identity of the first user; combining the secret data item and the backup code; and encrypting the combination of the secret data item and the backup code using the server's secret key.

[0034] According to one implementation, the server is configured to generate the encrypted link data by performing the following steps: generating a backup code based on the identity of the first user; applying a key derivation function to the server's secret key using the backup code as a derivation distinguisher to obtain a first derivation key that is a function of the data defining the identity of the first user; and encrypting the secret data item using the first derivation key.

[0035] According to one implementation, the server is configured to generate the encrypted link data by performing the following steps: generating a backup code based on the identity of the first user; combining the secret data item and the backup code; hashing the combination of the secret data item and the backup code; the server is also configured to encrypt the secret data item using the server's secret key; and storing the encrypted secret data item in the server's memory.

[0036] According to one implementation, the server is configured to generate the encrypted link data by performing the following steps: encrypting the secret data item using the server's secret key; generating a backup code based on the identity of the first user; combining the encrypted secret data item and the backup code; and encrypting the combination of the encrypted secret data item and the backup code using the server's secret key and a cryptographic hash function. The server is also configured to store the encrypted secret data item in the server's memory.

[0037] According to one implementation, the server is configured to include a step of splicing data defining the user's pivot identity in the step of generating the backup code.

[0038] According to one implementation, the server is configured to include, in the step of generating the backup code, a step of concatenating data defining the user's pivot identity, and a step of hashing the concatenated pivot identity data.

[0039] According to one implementation, the server is configured to, in response to a request to return the secret data item,: collect data defining the identity of a second user; generate a recovery code based on the identity of the second user; decrypt the encrypted link data and extract the backup code therefrom; compare the recovery code with the backup code; and if the two codes are the same, return the secret data item present in the encrypted link data, and if the two codes are different, refuse to return the secret data item.

[0040] According to one implementation, the server is configured to, in response to a request to return the secret data item,: collect data defining the identity of a second user; generate a recovery code based on the identity of the second user; apply the key derivation function to the server's secret key using the recovery code as a derivation distinguisher to obtain a second derivation key that is a function of the data defining the identity of the second user; and if the first derivation key and the second derivation key are the same, decrypt the encrypted linked data using the second derivation key and extract the secret data item therefrom.

[0041] According to one implementation, the server is configured to, in response to a request to return the secret data item,: collect data defining the identity of a second user; generate a recovery code based on the identity of the second user; decrypt the secret data item using the server's secret key; combine the secret data item and the recovery code; hash the combination of the secret data item and the recovery code to obtain new encrypted link data; compare the new encrypted link data with the encrypted link data; and if the new encrypted link data and the encrypted link data are the same, return the secret data item; otherwise, refuse to return the secret data item.

[0042] According to one implementation, the server is configured to, in response to a request to return the secret data item,: collect data defining the identity of a second user; generate a recovery code based on the identity of the second user; combine the secret data item and the recovery code; and encrypt the combination of the secret data item and the recovery code using the server's secret key and the cryptographic hash function to obtain new encrypted link data; compare the new encrypted link data with the encrypted link data; if the new encrypted link data and the encrypted link data are the same, then decrypt the secret data item and return the secret data item; otherwise, refuse to return the secret data item.

[0043] According to one implementation, the server is configured to generate the recovery code by concatenating data that defines the user's pivot identity.

[0044] According to one implementation, the server is configured to generate the recovery code by concatenating data defining the user's pivot identity and hashing the concatenated pivot identity data. Attached Figure Description

[0045] These and other features of the invention will be better understood by reading the following description, given by way of non-limiting example in conjunction with the accompanying drawings, in which: -Previously described Figure 1 The illustration shows examples of crypto asset wallets and their use. - Figure 2A and Figure 2B The architecture of a crypto-asset wallet according to the present invention and a system provided for implementing a first embodiment of the method according to the present invention is illustrated. Figure 2A The steps for backing up data are illustrated and Figure 2B The steps for data recovery are illustrated. - Figure 3A and Figure 3B The architecture of a crypto-asset wallet according to the present invention and a system provided for implementing a second embodiment of the method according to the present invention is illustrated. Figure 3A The steps for backing up data are illustrated and Figure 3B The steps for data recovery are illustrated. - Figure 4A and Figure 4B Describes the steps during data backup. Figure 3A , Figure 3B The algorithm executed by the system. - Figure 4C Therefore Figure 3A , Figure 3B The form of interaction between different components of the system Figure 4A , Figure 4B A sequence diagram of the algorithm steps. - Figure 5A and Figure 5B Describes the steps during data recovery by Figure 3A , Figure 3B The algorithm executed by the system. - Figure 5C Therefore Figure 3A , Figure 3B The form of interaction between different components of the system Figure 5A , Figure 5B A sequence diagram of the algorithm steps. - Figure 6A and Figure 6B The architecture of a crypto-asset wallet according to the present invention and a system provided for implementing a third embodiment of the method according to the present invention is shown. Figure 6A The steps for backing up data are illustrated and Figure 6B The steps for data recovery are illustrated. - Figure 7 An example of a cryptographic asset wallet according to the present invention and an example of a hardware wallet architecture according to the present invention that allows implementation of the method according to the present invention are shown. - Figure 8 Another embodiment that allows for the implementation of a crypto-asset wallet according to the method of the present invention is shown. - Figure 9 Another implementation scheme that allows for the implementation of a crypto-asset wallet according to the method of the present invention is shown. Detailed Implementation

[0046] This invention provides a method for generating crypto asset wallets that offer unique functionality in the hardware wallet field: automated seed backup while maintaining high security. This functionality frees users from all the difficulties and dangers associated with having to keep the recovery phrase in a safe place.

[0047] Figure 2A A crypto-asset wallet CW1 and a system providing an embodiment for implementing the method of the present invention are illustrated. The crypto-asset wallet CW1 includes a device HW and a host device HDV. The device HW is a hardware wallet (“hardware wallet”) that secures the cold storage of a seed S or master key for a set of crypto-assets. The device HW does not include any device for connecting to the Internet, but is linked to the host device HDV, which executes accompanying software HSW, thereby allowing it to connect to the Internet, for example, via USB or Bluetooth. The system and method according to the present invention allow for the backup or restoration of the seed S (master key) stored in the device HW.

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

[0049] According to the method of the present invention, the device HW is configured to divide the seed S into multiple secret data items Si (S1, S2…Si,… Sm), which will be backed up on the server BCKi. This “division” is not a simple split (although this is not excluded from the scope of the invention), but is preferably performed using a secret sharing function SS, which allows the generation of m secret data items referred to as “shards”, and allows the generation of a threshold from n secret data items Si: S1, S2, ..., Si, ..., Sm = SS (S)), and the seed is reconstructed.

[0050] For example, if m equals 3 and n equals 2, the function SS allows the seed to be divided into three pieces S1, S2, and S3, but reconstructing the seed will only require two pieces. If m equals 2 and n equals 2, the function SS allows the seed to be divided into two pieces S1 and S2, both of which are necessary for reconstructing the seed.

[0051] When a user wishes to back up their seed, device HW establishes data links LNKi (LNK1 to LNKm) of type HTTPS with each backup server BCKi via host device HDV. These data links are then secured by creating a secure channel of type SCP (“Secure Channel Protocol”) between device HW and each backup server BCKi in a manner to be described.

[0052] The creation of such secure channels is performed through a public key infrastructure managed by a Certificate Authority (CA). The device HW and the backup server BCKi each possess a private key, a public key, a certificate signed by the CA or a static certificate, and the CA's public key. The following symbols will be used in the following text: pL: The private key of the certification authority PL: Public key of the certification authority pD: The private key of the device's hardware. PD: Public key of the device's hardware CD = [PD, Sign(pL, PD)]: The device's certificate (static certificate), which includes its public key PD and a signature of its public key using a certification authority's private key pL. pBi: The private key of server BCKi (i ranges from i to m) PBi: The public key of server BCKi (i ranges from i to m) CBi = [PBi, Sign(pL, PBi)]: The certificate (static certificate) of the server BCKi, including its public key PBi and the signature of its public key using the private key pL of the certification authority.

[0053] The signature function "Sign" is generated, for example, using the elliptic curve-based ECDSA signature algorithm ("Elliptic Curve Digital Signature Algorithm").

[0054] The Certification Authority (CA) is preferably held by the manufacturer of the device (HW) to allow it to control the distribution of the certificate CBi to the backup server BCKi. The backup server BCKi may be held by the manufacturer of the device (HW) or by a third-party collaborating server involved in implementing this method. The backup server BCKi's keys pBi and PBi are held by its corresponding HSM modules, which handle the cryptographic calculations performed using these keys. For simplicity, such cryptographic calculations will be considered to be performed by the server itself in the following text.

[0055] To achieve a secure communication channel, a key exchange is provided between device HW and each backup server BCKi, allowing the generation of session keys kBi that are specific to each server BCKi but known to device HW. This key exchange is, for example, a Diffie-Hellman key exchange performed according to the following steps: i) Each backup server BCKi uses an asymmetric key generator to generate a temporary private key peBi and a public key PeBi pair, and then transmits its temporary public key PeBi to the device HW in its temporary certificate CeBi, which has already been signed with its private key pBi, and its certificate CBi, which has been signed by a trusted authority: CeBi = [PeBi, Sign(pBi, PeBi)] CBi = [PBi, Sign(pL, PBi)] ii) The device HW generates a temporary private key peD and public key PeD pair, and then transmits its temporary public key PeD to the backup server BCKi in its temporary certificate CeD (signed with its private key pD) and its certificate CD (signed by a trusted authority), i.e.: CeD = [PeD, Sign(pD, PeD)] CD = [PD, Sign(pL, PD)] iii) Each backup server BCKi uses the public key PD stored in the certificate CD of the device HW to verify the signature of the temporary public key PeD of the device HW, and then uses the public key PL of the certification authority to verify the signature of the public key PD stored in the certificate CD, or vice versa (verifying the signature of the public key PD before verifying the signature of the temporary public key PeD). iv) Similarly, the device HW uses the public key PBi stored in the certificate CB to verify the signature of the temporary public key PeBi of each server BCKi, and then uses the certificate authority's public key PL to verify the signature of the public key PBi stored in the certificate CB, or vice versa. v) Each backup server BCKi uses a key exchange function (such as, for example, the function ECDH (Elliptic Curve Diffie-Hellman Key Exchange or "Elliptic Curve Diffie-Hellman")) to generate a temporary session key kBi from its temporary private key peBi and the temporary public key PeD from the device HW, i.e.: kBi = ECDH(peBi, PeD) vi) Device HW uses the same function to generate a temporary session key kBi for each backup server BCKi from its temporary private key peD and the temporary public key PeBi from the backup server BCKi, i.e.: kBi = ECDH(peD, PeBi) After generating fragments Si of seed S, device HW uses the session key kBi shared with the backup server BCKi to which fragment Si will be transmitted to perform symmetric encryption steps for each fragment Si, thereby forming a shared key. In a simple implementation example, device HW generates three fragments S1, S2, and S3 (the threshold n can be equal to 2 or 3) and provides three backup servers BCK1, BCK2, and BCK3. Each server BCKi generates its own session keys kB1, kB2, and kB3, and device HW generates each of these session keys after exchanging keys with each server in the manner just described. Then, device HW uses these keys to perform symmetric encryption steps for fragments S1, S2, and S3, i.e.: - Encrypt fragment S1 using key kB1, i.e., {S1}kB1, and then send it to server BCK1. Encrypt fragment S2 using key kB2, i.e., {S2}kB2, and then send it to server BCK2. - Encrypt fragment S3 with key kB3, i.e. {S3}kB3, and then send it to server BCK3.

[0056] Then, each backup server BCKi decrypts the encrypted fragment {Si}kBi it receives from device HW and stores it in its memory MEM.

[0057] According to this method, and as Figure 2B As illustrated, the recovery of seed S is performed in a second hardware wallet denoted as HW. If device HW has been lost, stolen, or destroyed, the aforementioned device can be any device other than device HW. If device HW has been reset, from a methodological perspective, device HW is considered "another" device because it no longer possesses the seed, and the aforementioned device can also be device HW.

[0058] To recover the seed, repeat the steps described above for creating a secure channel. Generate a new session key kBi. Next, each server encrypts its held fragment Si using the session key kBi, i.e., {Si}kBi, and then transmits it to device HW. Device HW then decrypts each fragment Si using the corresponding session key kBi, and then uses the inverse function of the function that allows the generation of fragment Si (denoted as "SS-1"). S = SS-1 (S1, S2,…, Si,…, Sm)), reconstructing the seed S.

[0059] Figure 3A The architecture of a system that allows for another embodiment of the method of the present invention is shown. In this embodiment, a server ORCSRV1 is interposed between the host device HDV and the backup server BCKi. This server (referred to as, but not limited to, the "Orchestrator Server") executes a backend program ORC1, which is hereinafter referred to as the "Orchestrator Program" or "Orchestrator". The server ORCSRV1 is linked to a security module HSM, which is configured with a private key pO, a public key PO, and a certificate CO (static certificate) signed by a certification authority CA. CO = [PO, Sign(pL, PO)] To implement this method, a first data link LNK1, such as an HTTPS link, is established between the host device HDV and the orchestrator ORC1. Multiple data links LNK2i, such as HTTPS links and VPN IPsec links, are also established between the orchestrator and the backup server BCKi.

[0060] The data link between the orchestrator and the device HW is protected by creating a secure channel using the same technique described above. i) The orchestrator ORC1 generates a temporary private key peo and a public key peo pair, and then transmits its temporary public key peo to the device HW in its temporary certificate CeO, which has already been signed with its private key peo, and its certificate CO, which has been signed by a trusted authority. CeO = [PeO, Sign(pO, PeO)] CO = [PO, Sign(pL, PO)] ii) The device HW generates a temporary private key peD and a public key PeD pair, and then transmits its temporary public key PeD to the orchestrator in its temporary certificate CeD, which has already been signed with its private key pD, and its certificate CD, which has been signed by a trusted authority, i.e.: CeD = [PeD, Sign(pD, PeD)] CD = [PD, Sign(pL, PD)] iii) The orchestrator ORC1 uses the public key PD stored in the certificate CD to verify the signature of the temporary public key PeD of the device HW, and then uses the public key PL of the certification authority to verify the signature of the public key PD, or vice versa. iv) Similarly, the device HW uses the public key PO stored in the certificate CO to verify the signature of the orchestrator's temporary public key PeO, and then uses the certification authority's public key PL to verify the signature of the public key PO, or vice versa. v) The orchestrator ORC1 generates a temporary session key k0 from its temporary private key peO and the temporary public key PeD of the device HW: k0 = ECDH(peO, PeD) vi) Device HW generates a temporary session key k0 from its temporary private key peD and from the orchestrator's temporary public key PeO: k0 = ECDH(peD, PeO) Once a secure channel is established between the orchestrator and the device HW, the device HW can securely transmit data intended for use with the backup server BCKi to the orchestrator using symmetric encryption with a shared session key k0 for all or part of the data exchange. Conversely, the orchestrator can transmit data received from the backup server BCKi to the device HW in a form encrypted using key k0.

[0061] It also uses session keys kBi to create a secure channel between device HW and backup server BCKi. These session keys are generated at the end of the key exchange via data link LNK1. The orchestrator acts as a gateway or "proxy server" between device HW and server BCKi.

[0062] After performing these steps, distinguish between the following: - A channel implemented via data link LNK1, protected by a session key k0 shared by the orchestrator and device HW, allows for encryption of data exchanged between the orchestrator and device HW. - Channels implemented via data link LNK2i, protected by session keys kBi specific to each backup server BCKi and known to the device HW, allow the device HW to exchange data with each server BCKi in encrypted form.

[0063] In some cases, the following steps may also be provided: encrypting data received by the orchestrator in the form of data encrypted with key kBi with key k0, which corresponds to over-encryption of this data.

[0064] In one implementation, the steps related to the previously described key exchange are modified as follows: 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: CeO = [PeO, Sign(pO, PeO)] CO = [PO, Sign(pL, PO)] ii) 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 and using the ECDSA algorithm. iii) The device generates a session key k0 from its temporary private key peD and from the orchestrator's temporary public key PeO. iv) The device encrypts its certificate CD using the session key k0: {CD}k0 v) The device encrypts the first signature Sign(pD, PeD) using the session key k0: {Sign(pD, PeD)}k0 vi) The device transmits its certificate CD, encrypted with session key k0, and its temporary certificate CeD to the orchestrator. The temporary certificate includes a signature of its temporary public key PeD, encrypted with session key k0. {CD}k0 || CeD Right now {CD}k0 || PeD || {Sign(pD, PeD)}k0 ("||" is the symbol for splicing) vii) The orchestrator generates a session key k0 from its temporary private key peO and the temporary public key PeD received from the device, and viii) Using session key k0, the orchestrator decrypts the signature present in the temporary certificate CeD and decrypts the device's certificate CD.

[0065] return Figure 3A As can be seen from the foregoing, providing the orchestrator ORC1 allows for a reduction in the number of data links between the device HW and the backup server BCKi. These links are replaced by a single data link LNK1 between the device HW and the orchestrator, while ensuring a higher level of security due to the ability to over-encrypt data transmitted via link LNK1. Furthermore, due to the improvements described above, the confidentiality of the public key PD can be maintained. Providing the orchestrator offers various other advantages, which will be described later in conjunction with the implementation of the user authentication steps.

[0066] In this case, refer to Figure 3A The steps to back up seed S can be implemented as follows: i) Establish a link LNK1 between device HW and the orchestrator, and have device HW send a backup request BCKRQ to the orchestrator. ii) The orchestrator generates a random identifier BCKID for backup, establishes a link LNK2i between the orchestrator and the backup server BCKi, and transmits the identifier BCKID to the backup server BCKi. iii) Use session key k0 to create a secure channel between device HW and orchestrator ORC1. iv) A secure channel is established between device HW and backup server BCKi via orchestrator ORC1 using session key kBi. v) The seed S is generated by device HW, and the resulting fragment Si is generated: S1, S2,…, Si,…, Sm = SS (S), vi) The device HW encrypts each shard Si using the session key kBi intended for the backup server BCKi. vii) The device HW transmits all encrypted fragments {Si}kBi to the orchestrator: {S1}kB1||{S2}kB2||….||{Si}kBi||…||{Sm}kBm, viii) The orchestrator transmits the encrypted fragment {Si}kBi to each backup server BCKi intended for use. ix) Each server BCKi decrypts the fragment Si transmitted to it and stores it in its memory in association with the backup identifier BCKID.

[0067] Furthermore, the step of restoring seed S in the new device HW' triggered at the request of user USR (in Figure 3B (As illustrated in the example) includes the following steps: i) Establish a link LNK1 between device HW and the orchestrator, and have device HW send a recovery request RESTRQ and a backup identifier BCKID to the orchestrator. ii) Establish an LNKi connection between the orchestrator and the backup server BCKi, and have the orchestrator send the identifier BCKID to the backup server BCKi so that these backup servers are notified of the recovery to be performed. iii) Use the new session key k0 to create a secure channel between device HW and orchestrator ORC1. iv) A secure channel is created between device HW and backup server BCKi via orchestrator ORC1 using the new session key kBi. v) Each backup server BCKi reads the fragment Si it holds in its memory using the identifier BCKID and encrypts it using the new session key kBi. vi) Each backup server BCKi sends encrypted fragments {Si}kBi to the orchestrator. vii) The orchestrator collects all encrypted fragments {Si}kBi provided by the backup server BCKi: {S1}kB1, {S2}kB2,…., {Si}kBi,…, {Sm}kBm, viii) Send each encrypted fragment {Si}kBi to device HW one by one or all at once: {S1}kB1||{S2}kB2||….||{Si}kBi||…||{Sm}kBm, ix) Device HW decrypts each fragment Si using the session key kBi of the corresponding backup server BCKi: Si = {Si}-1kBi, x) The seed is reconstructed by device HW and stored in the memory of device HW: S = SS-1 (S1, S2,…, Si,…, Sm).

[0068] It should be noted that in the implementation scheme, if n is less than m, the orchestrator may only collect the n fragments required to reconstruct the seed. In this case, the seed is reconstructed from the n restored fragments: S = SS-1 (S1, S2,…, Si,…, Sn).

[0069] The above assumes that although the device HW used during backup is lost, the backup identifier BCKID has been stored by the companion software HSW of the host device HDV. In an implementation that allows for preventing users from permanently uninstalling the companion software HSW, a client account server UASRV can be provided, which includes a user account UACC storing various data about the user, particularly the backup identifier BCKID. 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 the key exchange that allows defining session keys used to create secure channels, the device HW' establishes a data link with the server UASRV after mutual certificate verification. Once the secure channel is established, the companion software HSW connects to the client account UACC to recover the identifier BCKID. In a variant, the identifier BCKID is stored on the server UASRV but not communicated to the companion software. A secure link is established between the server UASRV and the orchestrator ORC1. The orchestrator transmits the identifier BCKID to the server UASRV during backup, and in turn, receives the identifier BCKID from the server UASRV when a user wants to restore their seed.

[0070] In one implementation, a user's identity is also associated with the backup process by defining a set of data PIDs that form a identifiable "pivot identity." Information forming the pivot identity includes, for example, the user's first name, last name, and date of birth, as well as optional data such as their place of birth. This information is collected by accompanying software and communicated to an orchestrator, which assembles it into a binary string that will be designated as BCKDT.

[0071] In some implementations, in addition to the data PID, the data BCKDT also includes data ODT other than data related to the user's identity, such as the date and time of the backup, and / or the name given to the backup by the user (to allow these backups to be subsequently distinguished among several backups, if they hold several hardware wallets). In this case, the data BCKDT is written as follows: BCKDT = PID||ODT.

[0072] When initiating a backup, such as Figure 3AAs shown, the orchestrator conveys the data BCKDT to the backup servers BCKi, which associate this data, along with the identifier BCKID, with the backup shard Si. For confidentiality reasons, in some implementations, it may be preferable that the orchestrator does not save the data BCKDT once a backup is performed. In this case, the data BCKDT is only stored by the servers BCKi, which convey this data to the user USR for identification during recovery, such as... Figure 3B As shown.

[0073] In one embodiment of the method, the user's pivot identity is verified during at least one authentication step designated as "IDV" ("authentication") performed prior to seed recovery. In one embodiment, preferably, several authentication steps IDVi are provided before proceeding with seed recovery, these steps being performed by a backup server BCKi that is required to return all or part of the shard Si of seed S.

[0074] exist Figure 3B In the illustrated implementation, these authentication steps are delegated to a specialized provider, rather than being performed by the backup server BCKi itself. Such a provider owns servers IDVSRVi, each executing an automated authentication service IDVSi accessible via a gateway GTW (“Gateway”). Each backup server BCKi may be assigned a different server IDVSRVi and configured to link itself to the gateway GTW of the service IDVSi executed by that server. Preferably, such service IDVSi is not fully automated, at least for a portion thereof, and includes human intervention, particularly in cases of suspected personal identity.

[0075] Therefore, each backup server BCKi, or at least a portion thereof, is configured to perform the step IDVi of verifying the user's pivot identity when it receives a request to return a fragment of the seed. The server is then preferably configured to refuse to return the fragment if the verification is inconclusive.

[0076] In one implementation, prior to the seed backup step, there is an initial step IDV0 performed or supervised by the orchestrator to verify the pivotal identity of the users (i.e., at least their first name, last name, and date of birth). In this case, the server IDVSRV0 is also associated with the orchestrator ORC1, which is configured to link itself to the gateway GTW of the service IDVS0 performed by that server to implement step IDV0.

[0077] During each step of the optional IDV0 step before backup or during the IDVi step before returning fragments of the seed, the orchestrator associates the user USR with the appropriate service IDVS0 or IDVSi via the appropriate gateway GTW. The user must perform certain actions requested via the screen of the host device HDV and its equipped camera (e.g., mobile phone camera, PC webcam, etc.). For example, service IDVS0 or IDVSi requests the user to provide a valid identification document including their personal photograph, takes a photo of the identification document with the camera, and transmits the photo. Then, service IDVS0 or IDVSi requests the user to take a photo (selfie) or video of their face and transmits the photo or video. Service IDVS0 or IDVSi then verifies the authenticity of the identification document from the user's facial photo or video, and once the identification document is verified, it allows for verification of the pivot identity data with a certain degree of affirmation, which in some embodiments may be scored. The result of this verification, and optionally the score, is communicated to the orchestrator. In one embodiment, the IDV step also includes verification against a government database.

[0078] While step IDV0 is not as critical as those steps performed by server BCKi during the return of fragment Si, it ensures that users are providing accurate information about their identity, which is then incorporated into the data BCKDT. Furthermore, information collected by the orchestrator during this step (such as photos of the user's identification documents and photos or videos of the user's face) can optionally be communicated to the backup server BCKi via a specific communication channel, as this information is not part of the backup data BCKDT.

[0079] In one implementation, if the orchestrator ORC1 deems the initial authentication of a user's identity not conclusive or assigned too low a score, the orchestrator can pause the backup seeding process. Furthermore, in another implementation or otherwise, the orchestrator receives information from the backup servers BCKi regarding the success of authentication steps IDVi performed by these backup servers or by their affiliated providers. If a determined number of servers BCKi have not successfully authenticated the user and refuse to return the shard Si they hold, the orchestrator can be configured to pause the return of shard Si by servers that have successfully authenticated the user. The orchestrator may optionally decide to perform additional steps to authenticate the user's identity.

[0080] In a variant, or otherwise, the orchestrator receives a positive score about the user's identity from each backup server BCKi that has already undergone authentication steps. If the average score 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 additional steps to verify their identity.

[0081] In the event that a user has closed their account on the UASRV account server, uninstalled the accompanying software and erased the data contained in the software, and lost their hardware wallet HW, thus making it impossible to recover the backup identifier BCKID, a solution can be provided to allow the user to recover their seed. The user will then have to go through multiple separate steps with each server's BCKi to recover each shard Si of the seed. Procedures involving public officials (such as notaries) can also be provided. Each IDV provider can also verify the legitimacy of their methods by ensuring that no account belonging to the user exists on the system's account servers, and delegate more in-depth investigation procedures to natural persons, such as conducting telephone interviews with users, video conferences with users, face-to-face interviews with users, verifying users' educational background or professional records, etc.

[0082] It will be apparent to those skilled in the art that the method of the present invention can have various other embodiments and variations. In particular, in one embodiment, the backup data BCKDT may include, in compressed form, information collected at step IDV0 for verifying the pivotal identity of the user, such as a photograph or video of their face and a photograph of their identification document. The automated steps for verifying the pivotal identity of the user, performed by the server IDVSRVi or the service IDVSi performed by the backup server BCKi itself, may include at least two of the following steps: acquiring a photograph of an unexpired identification document including the user's photograph using a camera; acquiring one or more photographs of the user's face using a camera; acquiring a video recording showing the user's face in motion using a camera, verifying the user's authenticity with liveness detection; acquiring proof of residence, such as an electricity or telephone bill; acquiring the user's fingerprint; acquiring a verification code received by the user in a phone message, via email, or in mail; activating a link received by the user in a phone message, via email, or in mail by the user; and acquiring a hologram present on the unexpired identification document.

[0083] Now we will combine Figure 4A and Figure 4B Description applicable Figure 3A This is an example of an algorithm for backing up seeds, which implements various aspects of the previously described methods in the system. Figure 4CThis is a sequence diagram representing the steps of the algorithm in the form of interactions between the following items: -User USR, - Device HW and its host device HDV (which are considered the same entity that forms the crypto asset wallet CW1). - The orchestrator ORC1 and its associated security module HSM (also considered the same entity), and - The server IDVSRV0 associated with the orchestrator is used to perform the steps of verifying the user's identity. - Backup server BCKi, and - The server IDVSRVi associated with server BCKi is used to perform subsequent authentication steps when restoring the seed.

[0084] As a non-restrictive example, some of the functions used in the algorithm are shown in Table 1 below: Table 1 Combination Figure 4A , Figure 4B and Figure 4C Describe the algorithm.

[0085] B1. Initiate Backup User USR selects the option for backup seed on device HW. The user creates a backup account on account server UASRV via host device HDV. Device HW establishes a data link with orchestrator ORC1 and sends a backup request to it. [HW→ORC1] BCKRQ 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, and 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 may be 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 link with the server BCKi and then initiates the backup process according to the steps described below.

[0086] B2. Generate a backup identifier and send it to device HW and server BCKi. [ORC1 → BCKi, HW] BCKID The orchestrator ORC1 generates a backup identifier BCKID (e.g., a random number) and transmits it to the device HW and the server BCKi.

[0087] B3. Authentication is performed by server IDVSRV0. [IDVSRV0] IDV0 The orchestrator ORC1 connects users to server IDVSRV0 via gateway GTW. Server IDVS0 then proceeds to verify the user's pivot identity IDV0.

[0088] B4. Successful authentication is confirmed by the orchestrator. IDV_OK→HW Server IDVSRV0 confirms to orchestrator ORC1 that IDV has been successfully implemented, and orchestrator ORC1 uses device HW to confirm with the user that the user's identity has been verified and that the backup seeding process can be initiated. In this case, orchestrator ORC1 can generate backup data BCKDT and transmit it to device HW.

[0089] B5. Perform mutual authentication and create secure channels between the orchestrator and the device. B5.1. Generating temporary certificates by the arranger (peO, PeO) = AsymKeyGen() Sign(pO, ReO||PeO) CeO = PeO||Sign(pO, ReO||PeO) The orchestrator ORC1 generates a temporary private key peO and a temporary public key PeO. The orchestrator uses its private key pO to compute a signature of its temporary public key PeO. In the variant used here, the orchestrator computes a signature of its temporary public key after concatenating it with data ReO. Data ReO specifies, for example, the role played by the orchestrator server in this process, such as the role of the orchestrator used to establish a secure channel. The orchestrator then generates a temporary certificate CeO by concatenating the temporary public key PeO with the signature.

[0090] B5.2. Transmit the orchestrator's certificate to the device CeO||CO → HW The orchestrator ORC1 sends its temporary certificate and its certificate CO to the device HW.

[0091] B5.3. Certificate of Equipment Verification for the Orchestrator Verif CeO, Verif CO The device HW uses the public key PL of the certification authority to verify the orchestrator's certificate chain in the manner described above.

[0092] B5.4. The device HW generates session key k0 and temporary certificate. (peD, PeD) = AsymKeyGen() k0 = ECDH(peD, PeO) Sign(pD, ReD||PeD) {Sign(pD, ReD||PeD)}k0 CeD = PeD||{Sign(pD, ReD||PeD)}k0 {CD}k0 Device HW generates a temporary private key peD and a temporary public key PeD, and then uses the ECDH algorithm to generate a session key k0 from its temporary private key peD and the orchestrator's temporary public key PeO. Device HW then uses its private key pD to compute a signature of its temporary public key PeD, here after concatenating the temporary public key PeD with data ReD. Data ReD, for example, specifies the role HW plays in this process. Device HW then encrypts the signature of its temporary public key with the session key k0. 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 with key k0.

[0093] B5.5. Sending device certificates to the orchestrator [HW→ORC1] CeD||{CD}k0 Device HW sends its certificate CD, encrypted with key k0, and its temporary certificate CeD, which includes an encrypted signature, to orchestrator ORC1. Because of the encryption of both the certificate and the signature of the temporary certificate, the public key PD is not exposed. The order of these steps can be reversed; the device can send its certificate (which is encrypted here) before sending its temporary certificate (which includes an encrypted signature).

[0094] B5.6. The session key k0 is generated by the orchestrator. k0 = ECDH(peO, PeD) The orchestrator ORC1 uses the ECDH algorithm to generate the session key k0 from its temporary private key peO and the temporary public key PeD of the device HW.

[0095] B5.7. Certificates for equipment verified by the orchestrator CD = {CD} - 1k0 Sign(pD, ReD||PeD) = {Sign(pD, ReD||PeD)}-1k0 Verif CeD, Verif CD The orchestrator ORC1 decrypts the signatures of the device HW's certificate CD and temporary certificate, and then verifies the certificate chain.

[0096] B6. Transmit device data BCKID, BCKDT, and certificate CeD, CD to server BCKi. [ORC1 → BCKi] For each server BCKi, i ranges from 1 to m. BCKID||BCKDT||CeD||CD The orchestrator ORC1 transmits a backup identifier BCKID and backup data BCKDT, which includes at least pivot identity data, to each server BCKi. Other data, such as a photograph or video of the user's face taken at step IDV0 and a photograph of their identification document, may optionally be transmitted to or has already been transmitted to the backup server via other channels. If this data is not included in the backup data BCKDT, it may be stored by the customer account server and sent to server BCKi after backup.

[0097] B7. Certificates for devices verified by each server BCKi For each server BCKi, i ranges from 1 to m. Verif CeD, Verif CD Each server BCKi verifies the certificate chain of the device HW in the manner previously described.

[0098] B8. Perform mutual authentication and create a secure channel between the server BCKi and the device via the orchestrator. B8.1. Generate temporary certificates for each server using BCKi. For each server BCKi, i ranges from 1 to m. (peBi, PeBi) = AsymKeyGen() Sign(pBi, ReB||PeBi) CeBi = PeBi||Sign(pBi, ReB||PeBi) 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 uses its private key pBi to calculate the signature of its temporary public key. ReB specifies, for example, the role each server plays in the process, such as the role of a backup server for managing secure channels. Each server BCKi then generates a temporary certificate CeBi by concatenating its temporary public key PeBi with its signature.

[0099] B8.2. Generate session key kBi from each server BCKi. For each server BCKi, i ranges from 1 to m. kBi = ECDH(peBi, PeD) Then, each server BCKi uses the ECDH algorithm to generate a session key kBi from its temporary private key peBi and the temporary public key PeD of the device HW.

[0100] B8.3.1. Each server generates an encrypted hash code using BCKi. For each server BCKi, i ranges from 1 to m. Hi = Hash(PeBi||BCKID||BCKDT) CHi = {Hi}kBi Next, each server BCKi generates a hash code Hi from a binary string including its temporary public key PeBi, data BCKID, and backup data BCKDT. Then, each server BCKi encrypts the code Hi using the session key kBi to obtain the encrypted hash code CHi.

[0101] B8.3.2. Backup codes are generated by each server BCKi based on the user's pivot identity (PID). For each server BCKi, i ranges from 1 to m. HPIDi = Hash(PID) → STORE Each server, BCKi, then generates its backup code, HPDI, which is stored in its memory. The backup code HPDI is at least a function of a numerical PID that forms the user's pivot identity. In one implementation, the backup code HPDI is calculated by hashing the pivot identity PID data. In another implementation, the backup code HPDI is calculated by hashing backup data BCKDT, which contains the pivot identity PID data and may include supplementary information as cited above, such as the date and time of the backup, and the name given to the backup by the user. The hash function is, for example, the SHA256 function (“Secure Hash Algorithm”).

[0102] B8.4. Send the server BCKi certificate and encrypted hash code to the orchestrator. [BCKi → ORC1] RETDTi = CeBi||CBi||CHi Each server BCKi sends a binary string RETDTi to the orchestrator ORC1, which includes its temporary certificate CeBi, its certificate CBi, and the encrypted hash code CHi.

[0103] B8.5. Send the server BCKi certificate and encrypted hash code to the device. [ORC1→HW] {BCKID||BCKDT||RETDT1||….||RETDTi||…||RETDTm}k0 The orchestrator ORC1 returns the data BCKID, BCKDT, and all data RETDTi received from the backup server BCKi to the device in encrypted form using key k0. It's important to note that the orchestrator cannot access the data RETDTi because it does not know the server BCKi's session key kBi. Therefore, data in the secure communication channel between the orchestrator and the device is encrypted twice.

[0104] B8.6. The device decrypts the server BCKi certificate and the encrypted hash code. {BCKID||BCKDT||RETDT1|…||RETDTi||…||RETDTm}-1k0 Device HW decrypts the data string to extract the data BCKID, BCKDT, and certificates CeBi, CBi, and CHi.

[0105] B8.7. User-verified data BCKDT and server BCKi For each server BCKi, i ranges from 1 to m. Validate BCKDT, BCKi The user verification process, as an individual, presents the backup data BCKDT and the backup server BCKi to the user on the host device's screen.

[0106] B8.8. Certificate verified by the device verification server BCKi For each server BCKi, i ranges from 1 to m. Verif CeBi, Verif CBi The device HW verifies the certificate chain of each server BCKi.

[0107] B8.9. The device generates a session key kBi and verifies an encrypted hash code. For each server BCKi, i ranges from 1 to m. kBi = ECDH(peD, PeBi) {Hi}-1kBi Validate Hi For each server BCKi, device HW generates a session key kBi, then decrypts the code Hi, and verifies the code by recalculating the code Hi itself and comparing it with the decrypted code.

[0108] B9. Prepare for backup by generating m fragments Si. S1, S2,…Si,..Sm = SS(S) Using the secret sharing function SS, device HW generates m shards Si to be backed up on different servers BCK1, BCK2...BCKm, and uses the threshold of n shards to restore seed S.

[0109] In a variation of step B9, B9', step B9' first includes: before generating the m fragments Si to be backed up on different servers BCK1, BCK2, ..., BCKm, encrypting the seed S using a seed encryption key Kseed and an encryption function Fseed. The function Fseed is, for example, AES 256 encryption, i.e., symmetric encryption, and the seed encryption key Kseed also forms the decryption key.

[0110] In this case, step B9' includes the following steps: S = Fseed(S)Kseed Then: S1, S2,…Si,..Sm = SS(S) Therefore, here, the fragment Si is generated from the seed encrypted using the function Fseed and the key Kseed.

[0111] In another variation B9' of step B9, after generating m fragments Si, these fragments are individually encrypted using the seed encryption key Kseed. This encryption of the seed fragments Si can be AES 256 encryption, as described previously. In this case, step B9' includes the following steps: S1, S2,…Si,..Sm = SS(S) Then: S1 = Fseed(S1)Kseed S2 = Fseed(S2)Kseed … Si = Fseed(Si)Kseed … Sm = Fseed(Sm)Kseed For simplicity, the same notation “Si” will be used to designate the fragments in the following descriptions, regardless of whether the fragments are generated from an unencrypted seed or from a seed encrypted with the seed encryption key, or whether the fragments are encrypted after generation.

[0112] Other variations of step B9 may be provided, particularly a combination of the two variations B9' and B9'' just described, or a variation in which only a portion of the fragments in fragment Si undergoes an encryption step using the key Kseed.

[0113] In one implementation, the seed encryption key Kseed is recorded in the non-volatile memory of the hardware wallet HW, such as the non-volatile memory containing the device's operating system. This recording can be done during device personalization, before its sale, or during firmware updates.

[0114] In one implementation, the seed encryption key Kseed is shared by multiple hardware wallets (HW). The key may only be known to the manufacturer of the hardware wallet (HW), so users do not need to store it somewhere.

[0115] In another implementation, the seed encryption key is derived from a secret known to the user. For example, the encryption key is derived from a secret known to the user and an encryption key stored in a hardware wallet.

[0116] B10. The device encrypts the Si segments ( Figure 4B ) For each server BCKi, i ranges from 1 to m. {Si}kBi For each server BCKi, device HW encrypts the fragment Si intended for use with that server using a server-specific key kBi. Here, this encryption of fragment Si uses a session key kBi specific to each server BCKi, i.e., communication channel encryption, which should be distinguished from the encryption using the seed encryption key Kseed proposed as an option above. Therefore, if this option is adopted, fragment Si may have been previously encrypted with the seed encryption key Kseed or may have been derived from a seed previously encrypted with the seed encryption key Kseed before encryption using the session key kBi.

[0117] B11. Send the encrypted Si fragments to the orchestrator. [HW→ORC1] {S1}kB1||{S2}kB2||….||{Si}kBi||…||{Sm}kBm → ORC1 Then, device HW sends all fragments to orchestrator ORC1. Note that the orchestrator lacks knowledge of the value of each fragment Si because fragment Si is encrypted with a key kBi unknown to the orchestrator.

[0118] B12. Send the encrypted fragment Si to server BCKi. [ORC1 → BCKi] For each server BCKi, i ranges from 1 to m. BCKID||{Si}kBi → BCKi The orchestrator ORC1 sends each server BCKi an encrypted shard Si intended for use therein, along with a backup identifier.

[0119] B13.1. Each server BCKi decrypts and records the fragment Si.

[0120] For each server BCKi, i ranges from 1 to m. {Si}-1kBi → STORE Each server BCKi decrypts the Si fragments it has received.

[0121] B13.2.a. The shard is processed by each server BCKi in a manner that links the shard Si to the user's identity. Row backup For each server BCKi, i ranges from 1 to m. LNKSi = {Si||HPIDi}pBi → STORE During this step, each server BCKi concatenates the shard Si and backup code HPDIi according to the user's pivot identity as calculated in step B8.3.2, and then encrypts the resulting binary string using its individually known secret key (e.g., its private key pBi) and a cryptographic function. The LNKSi data obtained from this calculation forms encrypted information linking the shard Si and the user's pivot identity PID, and will be designated below as "encrypted link data". The encrypted link data LNKSi is then stored in the memory MEM of each server BCKi. Thus, the shard Si, backed up in the memory of each server BCKi, is linked to the user's pivot identity PID by the fact that the shard was concatenated with the backup code HPDIi, which is a function of the pivot identity PID, before being encrypted to form the encrypted link data LNKSi.

[0122] B13.2.b. The shard is processed by each server BCKi in a manner that links the shard Si to the user's identity. Row backup For each server BCKi, i ranges from 1 to m. KIDi = FDERIV(pBi, HPIDi) LNKSi = {Si}KIDi → STORE This step is a variation of step B13.2.a, and therefore can be performed by each server or only by some servers in place of step B13.2.a. During this step, each server BCKi configured to implement this variation derives its private key pBi by using the backup code HPDIi, a function serving as the user's pivot identity, as the derivation distinguisher, and computes the secret key KIDi.

[0123] Once the key KIDi is calculated, each server BCKi uses this key to encrypt the received fragment Si. The encrypted link data LNKSi obtained from this encryption step is then stored in the memory MEM of each server BCKi. Therefore, in this variant, the fragment Si, backed up in the memory of each server BCKi, is linked to the user's pivot identity PID by the fact that the fragment Si is encrypted using the key KIDi, which is a function of the pivot identity.

[0124] The derived function FDERIV is, for example, the HKDF function, which is a Simple Key Derivation Function (KDF) based on the HMAC Message Authentication Code. Therefore, the resulting key KIDi is a function of the pivot identity. To implement the HKDF function, the private key pBi is used as the "IKM" parameter ("Input Key Material"), and the backup code HPDIi is used as the "INFO" field. The "info" field has no predefined size and can therefore contain the entire identity or a "hash" of that identity.

[0125] B13.2.c. The shard is processed by each server BCKi in a manner that links the shard Si to the user's identity. Row backup In a variant of step B13.2.b, B13.2.c, each server or certain servers derive the key KIDi directly from the pivot identity's data PID, without going through the intermediate step of backup code, i.e.: KIDi = FDERIV(pBi, PID) B13.2.d. The shard is processed by each server BCKi in a way that links the shard Si to the user's identity. Row backup For each server BCKi, i ranges from 1 to m. LNKSi = Hash(Si||HPIDi) → STORE EncSi = {Si}pBi → STORE This step is another variation of step B13.2.a, and therefore can be performed by each server or only by some servers instead of step B13.2.a. During this step, each server BCKi configured to implement this variation concatenates Si and HPDI, and then hashes the resulting binary string to obtain the encrypted link data LNKSi. This data cannot be recalculated without accessing the unencrypted fragment Si. Therefore, this data cannot be recalculated by a fraudster from outside the system. Once the encrypted link data LNKSi is calculated, each server BCKi encrypts its received fragment Si using its individually known private key (e.g., pBi) to obtain the encrypted fragment EncSi. The encrypted fragment EncSi and the corresponding encrypted link data LNKSi are then stored in the memory MEM of each server BCKi.

[0126] B13.2.e. The shard is processed by each server BCKi in a way that links the shard Si to the user's identity. Row backup For each server BCKi, i ranges from 1 to m. EncSi = {Si}pBi LNKSi= HMAC(pBi, EncSi||HPIDi) → STORE EncSi → STORE This step is another variation of step B13.2.a, and therefore can be performed by all or part of the backup servers instead of step B13.2.a. During this step, each server BCKi configured to implement this variation encrypts its received fragment Si using its individually known private key (e.g., its private key pBi) to obtain an encrypted fragment EncSi. Each server BCKi then computes the encrypted link data LNKSi by concatenating the encrypted data EncSi and the backup code HPDITi, and then signs the binary string obtained using an HMAC-type cryptographic hash function (e.g., the HMAC-SHA256 algorithm) with its individually known private key (e.g., its private key pBi). The encrypted fragment EncSi and the corresponding encrypted link data LNKSi are then stored in the memory MEM of each server BCKi.

[0127] B14. Each server BCKi confirms backup with the orchestrator. [BCKi → ORC1] OKi Each server BCKi acknowledges to the orchestrator ORC1 via the message "OKi" (where i ranges from 1 to m) that it has decrypted and stored the fragment of the seed entrusted to it. Optionally, each server BCKi may transmit an encrypted proof of the decrypted fragment Si using a hash code signed with its session key. This signed hash code is then forwarded to device HW for verification.

[0128] B15. Confirm backup with user [ORC1→HW] OK The orchestrator ORC1 returns a backup success message (“OK”) to the device HW, which then displays the backup confirmation message to the user on its screen.

[0129] At the end of the process: - Device HW still holds seed S. -The identifier BCKID for backup records in the accompanying software HSW. - The orchestrator ORC1 does not hold the seed S or backup data BCKDT, and only holds the backup identifier BCKID. - Each server BCKi holds in its memory MEM a backup identifier BCKID, backup information BCKDT containing at least the user's pivot identity data PID, encrypted link data LNKSi, and a fragment Si that has been delegated to the server and linked to the legitimate user's pivot identity by means of the encrypted link data LNKSi.

[0130] The accompanying software HSW records the backup identifier BCKID, and the user's customer account UACC can also be updated by recording the backup identifier BCKID.

[0131] As will be clearly seen below, encrypted link data is provided to link fragment Si to the identity of its legitimate initial holder, making the link between fragment Si and the pivot identity PID of the legitimate user immutable and tamper-proof. This method allows for defense against subsequent attacks that would involve separating each fragment Si from its associated data BCKDT containing the identity data PID of the legitimate initial user, in order to associate that fragment with another data BCKDT containing the identity data PID of an illegitimate user. Such attacks, by “exchanging links” between fragment Si and data BCKDTs, could include, for example, attacks on the database that records such links.

[0132] If each shard Si of the seed is backed up in encrypted form with a data PID linked to the pivot identity of the legitimate user, then in some implementations, the backup data BCKDT may not include the data PID. While it is more convenient to include the data PID in the data BCKDT to locate the shard Si in the server BCKi from information associated with the owner's identity, the data BCKDT can be reduced to other types of information, such as the name of the backup and / or the date of the backup, as long as the legitimate user can remember this data when they wish to restore the shard Si.

[0133] In other implementations, instead of the backup data BCKDT, the backup data systematically includes the pivot identity data PID, and step B8.3.2, which generates the backup code HPDI, can be performed based on the data BCKDT, rather than the data PID. In this case, step B8.3.2 is written as follows: For each server BCKi, i ranges from 1 to m. HPIDi = Hash(BCKDT) = Hash(PID||ODT) → STORE Now we will combine Figure 5A , Figure 5B , Figure 5C Description applicable Figure 3A This is an example of an algorithm for recovering seeds, which implements various aspects of the previously described methods in a system. Figure 5C It is represented in the form of the interactions between the entities previously cited. Figure 5A , Figure 5B A sequence diagram of the steps of the described algorithm.

[0134] Here, it is assumed that the user has lost their device HW, or has irrecoverably lost the password that allows the use of device HW. The user receives a new device HW' which they will use to recover seed S and connects it to the host device HDV, whose accompanying software HSW has stored the backup identifier BCKID. The new device HW' can also be a device HW that has already been reset.

[0135] At the start of this process, 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 name as previously used for device HW's key and certificate). The recovery steps consist of those described below. Steps similar to those previously described will not be described again.

[0136] R1. The device sends a recovery request to the orchestrator. HW' → ORC1 RESTRQ[BCKID] Recovery is initiated by sending a recovery request (RESTRQ) from device HW' to the orchestrator. This request contains the backup identifier (BCKID). The request is issued at the user's request and is selected via a menu displayed on the screen of device HW' or the host device HDV.

[0137] R2. Perform mutual authentication and create secure channels between the orchestrator and the device. R2.1. Generating temporary certificates by the orchestrator (peO, PeO) = AsymKeyGen() Sign(pO, ReO||PeO) CeO = PeO||Sign(pO, ReO||PeO) R2.2 transmits the orchestrator's certificate to the device. ORC1→HW' CeO||CO R2.3. Certificate of Equipment Verification for the Orchestrator Verif CeO, Verif CO R2.4. The device generates a session key and an encrypted temporary certificate. (peD, PeD) = AsymKeyGen() k0 = ECDH(peD, PeO) Sign(pD, ReD||PeD) {Sign(pD, ReD||PeD)}k0 CeD = PeD||{Sign(pD, ReD||PeD)}k0 {CD}k0 R2.5. Send the certificate of device HW' to the orchestrator [HW' → ORC1] CeD||{CD}k0 R2.6. The session key k0 is generated by the orchestrator. k0 = ECDH(peO, PeD) CD = {CD} - 1k0 Sign(pD, ReD||PeD) = {Sign(pD, ReD||PeD)}-1k0 R2.7. Certificates for equipment verified by the orchestrator Verif CeD, Verif CD R3. Send data BCKID and certificate CeD, CD to server BCKi. [ORC1 → BCKi] For each server BCKi, i ranges from 1 to m. BCKID||CeD||CD → BCKi The orchestrator ORC1 sends the backup identifier BCKID, temporary certificate CeD, and device certificate CD to each backup server BCKi.

[0138] R4. Certificates for devices verified by each server BCKi. For each server BCKi, i ranges from 1 to m. Verif CeD, Verif CD R5. Performs mutual authentication and establishes secure channels between the server BCKi and the device via the orchestrator. R5.1. Generate temporary certificates from BCKi on each server. For each server BCKi, i ranges from 1 to m. (peBi, PeBi) = AsymKeyGen() Sign(pBi, ReB||PeBi) CeBi = PeBi||Sign(pBi, ReB||PeBi) R5.2. Generate session keys from each server's BCKi. For each server BCKi, i ranges from 1 to m. kBi = ECDH(peBi, PeD) R5.3. Each server generates an encrypted hash code using BCKi. Hi = Hash(PeBi||BCKID||BCKDT) CHi = {Hi}kBi R5.4. Each server BCKi sends its certificate and encrypted hash code to the orchestrator. [BCKi → ORC1] For each server BCKi, i ranges from 1 to m. RETDTi = CeBi||CBi||CHi R5.5. Transmit data received from server BCKi to the device. [ORC1→HW'] {BCKID||BCKDT||RETDT1|…||RETDTi||…||RETDTm}k0 R5.6. The device decrypts the data string received from the orchestrator. {BCKID||BCKDT||RETDT1|…||RETDTi||…||RETDTm}-1k0 R5.7. Backup data is verified by the user. Validate BCKDT User verification of backup data BCKDT, especially first name, last name, date of birth, and optional place of birth.

[0139] R5.8. Certificate verified by the device verification server BCKi For each server BCKi, i ranges from 1 to m. Verif CeBi, Verif CBi R5.9. The device generates a session key kBi and a verification encrypted hash code CHi. For each server BCKi, i ranges from 1 to m. kBi = ECDH(peD, PeBi) {Hi}-1kBi Validate Hi (Hi = Hash(PeBi||BCKID||BCKDT) R6. Preparing for Recovery R6.1. The device sends a recovery confirmation to the orchestrator. [HW'→ORC1] {ConfirmRestore1}kB1||{ConfirmRestore2}kB2||…||{ConfirmRestorei}kBi||…|| {ConfirmRestorem}kBm → ORC1 Device HW' returns a separate recovery acknowledgment "ConfirmRestorei" encrypted with the key kBi for each server BCKi to the orchestrator ORC1. Each acknowledgment is a predefined binary code.

[0140] R6.2. Send recovery confirmation to server BCKi For each server BCKi, i ranges from 1 to m. BCKID||{ConfirmRestorei}kBi → BCKi The orchestrator ORC1 sends the identifier BCKID of the assembled backup and the recovery confirmation {ConfirmRestorei}kBi intended for that server to each server BCKi.

[0141] R6.3. Recovery confirmation verified by server BCKi For each server BCKi, i ranges from 1 to m. {ConfirmRestorei}-1kBi Store CD Each server BCKi decrypts the acknowledgment message sent by device HW' and relayed to the server by orchestrator ORC1, and remembers the certificate CD of device HW' that it has previously verified.

[0142] R6.4. After authentication, each server's BCKi confirms that a recovery can be initiated. [BCKi→ ORC1] For each server BCKi, i ranges from 1 to m. OK_for_IDV Once the user has confirmed their identity through step IDVi, each server BCKi instructs the orchestrator ORC1 that it is ready to return the shard Si that it has already backed up.

[0143] R7.1. Authentication steps performed by server IDVSRVi. For each server BCKi, i ranges from 1 to m. IDVRi Users are redirected from orchestrator ORC1 to each server BCKi, and each server BCKi continues its own verification of the user's pivot identity, IDVi. In this embodiment, where the IDVi step is delegated to a provider, each server BCKi connects the user to a server IDVSRVi affiliated with those providers via gateway GTW. The provider's service IDVSi continues user authentication and then confirms with orchestrator ORC1 that the user's identity has been verified and the seed recovery step can be initiated.

[0144] It should be noted that the duration of each authentication step in IDVRi can range from minutes to days, depending on the requirements of each server BCKi or the provider implementing IDVRi. Authentication of natural persons can be systematically provided through a specific IDV provider.

[0145] R7.2. Each server BCKi generates a recovery code based on the user's pivot identity 'PID'. For each server BCKi, i ranges from 1 to m. IDVi → PID HPIDi' = Hash(PID') → STORE Each server BCKi receives a report from either step IDV or service IDVSi, which contains the user's identity and the result of IDV, allowing the server to reconstruct the data for the pivot identity 'PID'. This report is preferably signed by the IDV service. The server BCKi can then verify that the IDV was successful and that the identity included in the report does indeed correspond to the backed-up identity PID.

[0146] Following this verification, each server BCKi verifies the user's pivot identity data PID'. If the user attempting to restore the seed here is not an imposter, this data is designated as PID' and is assumed to be the same as the data PID used for the shard used to back up the seed. Each server BCKi then generates a recovery code HPDI' based on the data PID' in the same manner that allows the generation of a backup code HPDI' based on the data PID. Therefore, for example, the recovery code HPDI' is calculated by hashing the PID', as done during step B8.3.2, to calculate the code HPDI' based on the PID. Thus, if the user requesting to restore the seed is not an imposter, the recovery code HPDI' is equal to the backup code HPDI'. Once calculated, each server stores the recovery code HPDI' in its memory MEM.

[0147] It should be noted that if step B8.3.2, which generates backup code HPDIi, is based on backup data BCKDT containing the pivot identity data PID and other data ODT, then step R7.2, which generates recovery code HPDIi', itself is based on the backup data BCKDT. In this case, step R7.2 is written as follows: For each server BCKi, i ranges from 1 to m. HPIDi' = Hash(BCKDT') → STORE, in: BCKDT' = PID'||ODT.

[0148] ODT is other data contained in the data BCKDT, such as the date and time of the backup, and / or the name given to the backup by the user.

[0149] R8. Re-establish the secure communication channel after performing the authentication step IDVi. [HW' → ORC1] Continue Restore Once the authentication process is complete, sometimes a few days later, the user restarts the recovery process. Device HW' sends a request to orchestrator ORC1 to continue the recovery process, "Continue Recovery".

[0150] Repeat steps R2.1 to R2.7, R3, and R5.1 to R5.9. Figure 5B ) Since several days may pass during the verification step IDVi, in one implementation, the previous session certificate is not saved. Therefore, steps R2.1 to R2.7, R3, and R5.1 to R5.9 are executed again to continue the recovery process from where it stopped, but using new session keys k0 and kBi.

[0151] R9. Then proceed with the recovery. [ORC1 → BCKi] For each server BCKi, i ranges from 1 to m (or from 1 to n). Continue Restore → BCKi Once the secure channel is reopened using the new session key, the orchestrator will continue forwarding recovery requests to server BCKi. Note that if, during step IDVRi, one of the servers in BCKi cannot verify the user's identity with a certain degree of certainty, that server will refuse to return the fragments it holds and will notify its orchestrator ORC1. If a certain number of backup servers in 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 fragments by servers that have successfully verified the user's identity. The orchestrator may optionally decide to subject the user to additional procedures for verifying their identity. The orchestrator can also be configured to analyze the certainty score of the user's identity verification (as noted above) and make decisions based on that analysis.

[0152] Furthermore, in the variations of the method mentioned in parentheses above and below, if the reconstruction seed only requires n shards (where n is less than m), then this step is limited to n backup servers BCKi, rather than all backup servers.

[0153] R10.1. Verify the equipment certificate For each server BCKi, i ranges from 1 to m (or from 1 to n). Verif CD = CD Each server BCKi ensures that the certificate CD of device HW' is the same as the certificate CD it has saved before the authentication step IDVi was performed.

[0154] R10.2.a. Each server BCKi decrypts the encrypted link data LNKSi containing the fragment Si to... And verify the user's pivot identity For each server BCKi, i ranges from 1 to m (or from 1 to n). LNKSi = Si||HPIDi = {Si||HPIDi}pBi-1 COMPARE {HPIDi', HPIDi} During this step, each server BCKi decrypts the data LNKSi stored in its memory to extract the fragment Si and backup code HPDIi. This decryption is performed using the same key used for encryption step B13.2.a (here, the private key pBi). Each server BCKi then compares the recovery code HPDIi' with the backup code HPDIi. If the user requesting the recovery seed is not an imposter, the recovery code HPDIi' equals the backup code HPDIi, and each server BCKi accepts and returns the fragment Si it holds; otherwise, it refuses to return the fragment.

[0155] R10.2.b. Each server BCKi decrypts the encrypted link data LNKSi containing the fragment Si to... And verify the user's pivot identity For each server BCKi, i ranges from 1 to m (or from 1 to n). KIDi' = FDERIV(pBi, HPIDi') Si = {LNKSi}KIDi'-1 This step is a variation of step R10.2.a, and is implemented if variation B13.2.b of step B13.2.a is implemented during the backup phase.

[0156] During this step, each server BCKi involved in this variant derives its private key pBi using the recovery code HPDI', a function of the user's pivot identity PID', as a distinguisher, and calculates the secret key KIDi. If the user requesting the recovery seed is not an imposter, the key KIDi' derived from the private key pBi using the recovery code HPDI' (diversified) is the same as the key KIDi derived from the private key pBi using the backup code HPDI, since the codes HPDI' and HPDI are identical. Of course, the same derivation function used in step B13.2' must be used, such as the HKDF function.

[0157] Each server BCKi then uses its secret key KIDi' to decrypt the encrypted fragment LNKSi stored in its memory to retrieve fragment Si. If the user requesting to recover the seed is an imposter, the key KIDi' will be different from the key KIDi that allows the generation of the encrypted shared LNKSi. Decryption of the fragment Si will be impossible or will be erroneous, and server BCKi will not be able to return its fragment Si.

[0158] R10.2.c. Each server BCKi decrypts the encrypted link data LNKSi containing the fragment Si to... And verify the user's pivot identity In implementing the variant B13.2.c of step B13.2.a, the recovery code HPDI' is not calculated, and step R7.2 is not performed. Step R10.2.a becomes step R10.2.c, and step R10.2.c is executed as follows: For each server BCKi, i ranges from 1 to m (or from 1 to n). KIDi' = FDERIV(pBi, PID') Si = {LNKSi}KIDi'-1 R10.2.d. Each server BCKi decrypts the fragment Si, calculates the encrypted link data, and verifies it. User's pivot identity For each server BCKi, i ranges from 1 to m (or from 1 to n). Si = {EncSi}pBi-1 LNKSi' = Hash(Si||HPIDi') COMPARE {LNKSi, LNKSi'} This step is a variation of step R10.2.a, and is implemented if variation B13.2.d of step B13.2.a is implemented during the backup phase. During this step, each server BCKi involved in this variation uses the secret key pBi to decrypt the encrypted fragment EncSi stored in its memory to extract fragment Si. Each server BCKi computes the new encrypted link data LNKSi' by concatenating the decrypted fragment Si with the recovery code HPDIi', a function of the user's pivot identity PID', and by applying the previously used hash function to the resulting binary string.

[0159] Then, each server BCKi compares the new encrypted link data LNKSi' derived from the recovery code HPDIi' with the encrypted link data LNKSi calculated during backup. If the user requesting the recovery seed is not an imposter, then LNKSi' equals LNKSi, and each server BCKi accepts and returns the fragment Si it holds; otherwise, it refuses to return the fragment.

[0160] R10.2.e. Each server BCKi decrypts the fragment Si, calculates the encrypted link data, and verifies it. User's pivot identity For each server BCKi, i ranges from 1 to m (or from 1 to n). LNKSi' = HMAC(pBi, EncSi||HPIDi') COMPARE {LNKSi, LNKSi'} Si = {EncSi}pBi-1 This step is a variation of step R10.2.a, and is implemented if variation B13.2.e of step B13.2.a is implemented during the backup phase. During this step, each server BCKi involved in this variation computes new encrypted link data by concatenating the encrypted fragment EncSi with the recovery code HPDIi' (which is a function of the user's pivot identity PID), and then applying a symmetric signature algorithm (such as HMAC-SHA256) to the resulting binary string using, for example, its secret key pBi.

[0161] Then, each server BCKi compares the new encrypted link data LNKSi' derived from the recovery code HPDIi' with the encrypted link data LNKSi calculated during backup. If the user requesting the recovery seed is not an imposter, the encrypted link data LNKSi' equals LNKSi, and each server BCKi accepts and returns the fragment Si after decrypting it using the secret key pBi; otherwise, it rejects and returns the fragment.

[0162] R11. Fragments are transferred from server BCKi to the orchestrator. For each server BCKi, i ranges from 1 to m (or from 1 to n). {S1}kB1||{S2}kB2||….||{Si}kBi||…||{Sm}kBm → ORC1 Each server BCKi sends its held shard Si to the orchestrator ORC1, which is encrypted using a key kBi from a server unknown to the orchestrator.

[0163] R12. Fragment transfer from orchestrator to device {S1}kB1||{S2}kB2||….||{Si}kBi||…||{Sm}kBm → HW' The orchestrator ORC1 transmits all the fragments Si received from the server BCKi to the device HW' in encrypted form using the key kBi.

[0164] R13. The device decrypts the fragments and recovers the seed. For each server BCKi, i ranges from 1 to m (or from 1 to n). {Si}-1kBi S = SS⁻¹ (S₁, S₂, …Si…Sm) (Or S = SS-1 (S1, S2,…Si…Sn)) After each fragment of rank i has been decrypted using the corresponding key kBi, device HW' recovers the seed from the received fragments, or, if the number of these fragments is greater than n, recovers the seed from a portion of these fragments.

[0165] In a variant of step R13' corresponding to step B9' described above, the seed S recovered by device HW' is the original seed encrypted with the seed encryption key Kseed. Therefore, an additional decryption step using the key Kseed must be provided to recover the seed using the decryption function Fseed-1, which corresponds to the inverse function of function Fseed: S = Fseed-1(S)Kseed In variant R13' of step R13, corresponding to variant B9' of step B9, each fragment Si that device HW' has already decrypted was initially encrypted with the seed encryption key Kseed. Therefore, before reconstructing the seed, after each fragment Si has been decrypted using the session key kBi, it must be decrypted using the key Kseed, i.e.: For each server BCKi, i ranges from 1 to m (or from 1 to n). {Fseed-1(Si)Kseed}-1kBi S = SS⁻¹ (S₁, S₂, …Si…Sm) In the implementation described above, where the seed encryption key is derived from a secret known to the user, steps R13' and R13' include generating the seed encryption key from the user's secret. This generation may involve an encryption key stored in a hardware wallet.

[0166] R14. Final Confirmation OK→ORC1 Device HW' confirms to the orchestrator ORC1 that seed recovery is complete.

[0167] It will be apparent to those skilled in the art that the described method can have many other variations and implementations. The structure of the certificate involved in this method has been described above according to two variations, for example: Cx = [Px, Sign(pL, Px)] Cex = Pex||{Sign(px, Rex||Pex) Temporary certificates can also be of the following types: Cex = Pex||{Sign(px, Pex) This method can also be implemented using any certificate structure. X.509 type certificates are particularly useful. Similarly, other encryption functions or cryptographic algorithms can be used, especially in implementations based on RSA cryptography.

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

[0169] When a user initiates the backup seeding step, device HW sends a backup request BCKRQ to orchestrator ORC2. Orchestrator ORC2 then initiates the previously described steps of generating the backup identifier BCKID and collecting information about the user to generate backup data BCKDT. The orchestrator also performs an initial step IDV0 to verify the user's identity. If this step is successful, the orchestrator delivers backup authorization BCKPASSi to device HW at a rate of one authorization per backup server BCKi, and transmits each authorization to the relevant server BCKi.

[0170] Each authorized BCKPASSi forms a "passport" that allows the device HW to know which server BCKi it must connect to to back up the seed fragment Si, and allows it to connect to the server BCKi to continue the backup without being rejected by that server. Each authorized BCKPASSi may include various information, particularly information that previously appeared in the backup data BCKDT and the identifier BCKID. The authorized BCKPASSi is stored by the accompanying software and preferably in the user account UACC on the account server UASRV. In a variant, the orchestrator delivers a concatenated generic authorized BCKPASSi containing all the information that appears in the authorized BCKPASSi.

[0171] refer to Figure 6B When a user wants to restore a seed, the accompanying software connects to the backup server BCKi, identified by the address contained in their authorized BCKPASSi, and then hands it over to device HW, which establishes a secure channel with the backup server BCKi through key exchange as described above. Once the secure channel is established, the backup server BCKi initiates the step IDVi to verify the user's pivot identity.

[0172] The supervisory role of step IDVi, previously handed over to orchestrator ORC1, can also be handed over to orchestrator ORC2 here. The orchestrator is then requested by backup server BCKi to analyze the results of step IDVi. If these results are conclusive, orchestrator ORC2 delivers a recovery authorization RESTPASSi to device HW, which also conveys the recovery authorization to backup server BCKi. Device HW then re-establishes a secure channel with backup server BCKi and presents the authorization RESTPASSi to these backup servers to restore the seed fragment Si.

[0173] In the event that a user has closed their account on the account server UASRV, uninstalled the companion software and erased the data contained in the companion software, and therefore may no longer be able to restore the licensed BCKPASSi, and in the equally eventual event that the orchestrator ORC2 no longer exists, a solution can be provided to allow users to restore their seeds by allowing users to perform multiple separate steps to verify their identity with each backup server BCKi.

[0174] This method allows for system complete failure or identification BCKID ( Figure 3A , Figure 3B In implementation schemes (or variants of schemes that facilitate fragment recovery in the event of a lost BCKPASSi), it may be stipulated that the organization responsible for orchestrators ORC1 or ORC2 delivers a backup certificate with an inviolable authenticity certificate (such as a hologram) to the user, for example, via postal mail. This backup certificate will not eliminate the step of verifying the user's identity with the backup server, but will include sufficient information to provide additional assurance of their status as the legitimate holder of the seed during the verification step IDVi.

[0175] Figure 7An example implementation of a hardware wallet HW that allows this method to be implemented is shown. The device HW includes a secure element SE1, a microcontroller MCU1, and a touchscreen TS1 (“Touchscreen”). The touchscreen TS1 includes an electronic ink display EID (“E-Ink Display”) and a touch module TM (“Touch Module”). The touchscreen TS1 is controlled by the secure element SE1. For this purpose, the input / output resources of the secure element SE1 are distributed across three sets of inputs / outputs: IOGA, IOGB, and IOGC. The input / output group IOGA is assigned to implement bus BS1, which links the secure element SE1 to the microcontroller MCU1. The input / output group IOGB is assigned to implement bus BS2, which links the secure element SE1 to the display EID, and the input / output group IOGC is assigned to implement bus BS3, which links 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, STMicroelectronics. ® ST33K series chips. Furthermore, the device HW includes various peripherals controlled by the microcontroller MCU1, such as: -Battery BAT; - The power management integrated circuit (PMIC) receives voltage Vbat from the battery when the battery is charging, supplies voltage Vbat to the battery when the battery needs to be charged, and supplies the regulated supply voltage Vcc to the microcontroller MCU1, safety element SE1, and touch screen TS1. - Antenna QiA is used to charge the battery via induction. Antenna QiA is linked to the wireless charging integrated circuit WCIC (“Wireless Charging Integrated Circuit”). The circuit WCIC supplies voltage Vqi to the circuit PMIC for charging the battery; -USB port U1. This USB port supplies voltage Vusb to the PMIC circuit for charging the battery, supplies data DTu received from external devices connected to this USB port to the microcontroller MCU1, and sends data DTu to the external devices; - Bluetooth antenna BTA, which receives the radio frequency signal RFS provided by the circuit BTM for managing Bluetooth communication. The circuit BTM provides data DTb for exchange with external devices via the Bluetooth link, or transmits data DTb to external devices via the Bluetooth link.

[0176] Therefore, the advantage of device HW is that it has a touchscreen specifically controlled by the secure element SE1, and is thus immune to damage (including attacks on the microcontroller MCU1). The microcontroller does not execute any applications and does not store any cryptographic secrets used by the secure element. The microcontroller only manages peripheral devices by sending data DTb, DTu received by the user-selected communication interface to the secure element, or by sending data DTb, DTu provided by the secure element to external devices. Therefore, device HW does not offer any possibility of direct internet connection, and despite the touchscreen, it remains a hardware wallet used for cold storage of private keys to provide a high level of security. The secure element SE1 also includes a memory space MS1, which includes a read-only memory area, an electrically erasable and programmable non-volatile memory area, and a volatile memory area. The electrically erasable and programmable non-volatile memory area receives the operating system from the secure element. This operating system is configured to allow the implementation of the methods of the present invention.

[0177] Device HW is well-suited for implementing this method due to its touchscreen, which can be selected to be large and have a diagonal of, for example, greater than or equal to 3.5 inches (one inch equals 2.54 cm), and includes at least 600 × 400 pixels. In one 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 hardware wallet for crypto assets without an internet connection.

[0178] The method just described can also be implemented using various other types of crypto asset wallets. This method is particularly useful for... Figure 8The CW2 crypto-asset wallet of the type shown is implemented as an example. The CW2 crypto-asset wallet includes a secure microcontroller (SMCU), a screen (TS2) that may be a touchscreen, and a communication interface circuit (CINT1) that 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 the management of two application execution zones (TZ and NTZ) providing different levels of security; the TZ zone is referred to as the "trust zone." In some implementations, the secure microcontroller may be equipped with a secure element (SE2) coupled to the trust zone (TZ) to perform cryptographic computations and conduct the most security-sensitive operations, particularly storing seeds and various crypto-asset account keys. Each zone can operate independently of the others while using the same kernel. Generally, the microcontroller executes a so-called "rich" operating system in the less trusted zone (NTZ, e.g., Android) and executes proprietary code in the trust zone (TZ). This device is equivalent to a combination of the hardware wallet HW (corresponding to the trust zone) and the host device HDV (corresponding to the less secure zone) described above, and does not require a link to a host device to perform operations on the blockchain.

[0179] The method of this 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, or mobile phone, etc. Users retain ownership of their keys and seeds and must protect their storage security themselves by ensuring that fraudsters cannot intercept them. For example, Figure 9 A software-based crypto-asset wallet, CW3, executed by an electronic device (DV), such as a computer, mobile phone, etc., is illustrated. The DV includes a microprocessor (MPU) equipped with a communication interface (CINT2) allowing it to connect to the internet, volatile RAM, and non-volatile memory (NVM), such as a magnetic hard disk or solid-state drive (SSD). The program CW3 that forms the software crypto-asset wallet is stored in the DV's NVM and executed by the MPU via its RAM.

Claims

1. A method for backing up and restoring secrets (S) held by secure electronic devices (CW1, CW2, CW3, HW, HDV), the method comprising the step of backing up the secrets, the step comprising the following steps: - Provides multiple backup servers (BCKi). - Collect (B3) data defining the identity of the first user (BCKDT, PID), and transmit (B6) said data to each backup server. - Using the secure electronic device, generate multiple secret fragments (Si) from the secret (S). - Send one secret fragment (B11, B12) of the secret fragment (Si) to each backup server, and - In each backup server: - Generates encrypted link data (LNKSi) of (B13.2.a, B13.2.b, B13.2.c, B13.2.d, B13.2.e), wherein the encrypted link data is a function of the secret fragment (Si) and the data (BCKDT, PID) defining the identity of the first user, and - The encrypted linked data is stored in the memory (MEM) of the backup server.

2. The method of claim 1, wherein the step (B13.2.a) of generating the encrypted link data (LNKSi) in at least one backup server comprises: - Generate backup code (BCKDT, PID, HPIDi) based on the identity of the first user (B8.3.2). - Combine the secret fragment (Si) and the backup code, and - Encrypt the combination of the secret fragment and the backup code using the backup server's secret key (pBi).

3. The method according to claim 1 or 2, wherein the step (B13.2.b, B13.2.c) of generating the encrypted link data (LNKSi) in at least one backup server comprises: - Generate backup code (BCKDT, PID, HPIDi) based on the identity of the first user. - Using the backup code as a derivation distinguisher, apply the key derivation function (FDERIV) to the secret key (pBi) of the backup server to obtain a first derived key (KIDi) as a function of the data (BCKDT, PID) defining the identity of the first user, and - Encrypt the secret fragment (Si) using the first derived key (KIDi).

4. The method according to any one of claims 1 to 3, wherein the step (B13.2.d) of generating the encrypted link data (LNKSi) in at least one backup server comprises: - Generate backup code (BCKDT, PID, HPIDi) based on the identity of the first user. - Combine the secret fragment (Si) and the backup code, and - Hash the combination of the secret shard and the backup code to obtain the encrypted link data (LNKSi). The method further includes: encrypting the secret fragment (Si) using the secret key (pBi) of the backup server, and storing the encrypted secret fragment (EncSi) in the memory (MEM) of the backup server.

5. The method according to any one of claims 1 to 4, wherein the step (B13.2.e) of generating the encrypted link data (LNKSi) in at least one backup server comprises: - Encrypt the secret fragment (Si) using the backup server's secret key (pBi). - Generate backup code (BCKDT, PID, HPIDi) based on the identity of the first user. - Combine the encrypted secret fragment (EncSi) and the backup code, and - The combination of the encrypted secret fragment and the backup code is encrypted using the backup server's secret key (pBi) and a cryptographic hash function (HMAC). The method further includes the step of storing the encrypted secret fragment (EncSi) in the memory (MEM) of the backup server.

6. The method according to any one of claims 2 to 5, wherein the step of generating the backup code (BCKDT, PID, HPDI) includes the step of concatenating data defining the pivot identity of the user.

7. The method according to any one of claims 2 to 5, wherein the step of generating the backup code (HPIDi) includes the step of concatenating data defining the pivot identity of the user, and the step of hashing the concatenated pivot identity data (B8.3.2).

8. The method of claim 1, wherein the method includes the step of recovering the secret (S), the step comprising: - Collect (R7.1) data (BCKDT', PID') defining the identity of the second user, verify the validity of the data with the participation of the second user, and provide the data to at least one backup server, and - The backup server is used to verify that the identity of the second user is the same as that of the first user based on the encrypted link data (LNKSi).

9. The method of claim 8, wherein the step of verifying the identity of the second user includes at least one of the following operations: - Decrypt the encrypted link data (R10.2.a), extract the identity of the first user or data (HPIDi) which is a function of the first user's identity, and compare the identity or the data with the identity of the second user or data (HPIDi') which is a function of the second user's identity. - Decrypt the encrypted link data using the key (KIDi') of the function representing the identity of the second user (R10.2.b, R10.2.c). - Calculate new encrypted link data (LNKSi') from the identity of the second user (R10.2.b, R10.2.c) and compare the new encrypted link data with the initial encrypted link data (LNKSi).

10. The method of claim 2, the method comprising the step of recovering the secret (S), the step comprising: - Collect (R7.1) data (BCKDT', PID') defining the identity of the second user, verify the validity of the data with the participation of the second user, and provide the data to at least one backup server, and -Use the backup server to: - Generate a recovery code (BCKDT', PID', HPIDi') based on the identity of the second user (R7.2). - Use the secret key (pBi) of the backup server to decrypt the encrypted link data (LNKSi) (R10.2.a) and extract the backup code (BCKDT, PID, HPIDi) from it. - Compare the recovery code (BCKDT', PID', HPIDi') with the backup code (BCKDT, PID, HPIDi), and If the two codes are the same, the secret fragment (Si) existing in the encrypted link data (LNKSi) is returned; if the two codes are different, the secret fragment is rejected.

11. The method of claim 3, wherein the method includes the step of recovering the secret, the step comprising: - Collect (R7.1) data (BCKDT', PID') defining the identity of the second user, verify the validity of the data with the participation of the second user, and provide the data to at least one backup server, and -Use the backup server to: - Generate a recovery code (BCKDT', PID', HPIDi') based on the identity of the second user (R7.2). - Using the recovery code (BCKDT', PID', HPIDi') as the derivation distinguisher, apply the key derivation function (FDERIV) (R10.2.b, R10.2.c) to the secret key (pBi) of the backup server to obtain a second derived key (KIDi') as a function of the data (BCKDT', PID') defining the identity of the second user, and - If the first derived key and the second derived key are the same, the second derived key (KIDi') is used to decrypt the encrypted link data (LNKSi) and the secret fragment (Si) is extracted from it.

12. The method of claim 4, wherein the method includes the step of recovering the secret, the step comprising: - Collect (R7.1) data (BCKDT', PID') defining the identity of the second user, verify the validity of the data with the participation of the second user, and provide the data to at least one backup server, and -Use the backup server to: - Generate a recovery code (BCKDT', PID', HPIDi') based on the identity of the second user (R7.2). - Decrypt the secret fragment (Si) using the secret key of the backup server. - Combine the secret fragment and the recovery code (R10.2.d), and hash the combination of the secret fragment and the recovery code to obtain new encrypted link data (LNKSi'). - Compare the new encrypted link data (LNKSi') with the encrypted link data (LNKSi), and If the new encrypted link data (LNKSi') is the same as the encrypted link data (LNKSi), then the secret fragment (Si) is returned; otherwise, the secret fragment (Si) is rejected.

13. The method of claim 5, wherein the method includes the step of recovering the secret, the step comprising: - Collect (R7.1) data (BCKDT', PID') defining the identity of the second user, verify the validity of the data with the participation of the second user, and provide the data to at least one backup server, and -Use the backup server to: - Generate a recovery code (BCKDT', PID', HPIDi') based on the identity of the second user (R7.2). - Combine the secret fragment and the recovery code (R10.2.e), and encrypt the combination of the secret fragment and the recovery code using the secret key (pBi) of the backup server and the cryptographic hash function (HMAC) to obtain new encrypted link data (LNKSi'). - Compare the new encrypted link data (LNKSi') with the encrypted link data (LNKSi). If the new encrypted link data (LNKSi') is the same as the encrypted link data (LNKSi), then the secret fragment (Si) is decrypted and returned; otherwise, the secret fragment (Si) is rejected.

14. The method according to any one of claims 10 to 13, wherein the step of generating the recovery code (BCKDT', PID', HPIDi') includes the step of concatenating data defining the pivot identity of the user.

15. The method according to any one of claims 10 to 13, wherein the step of generating the recovery code (HPIDi') includes concatenating data defining the pivot identity of the user, and hashing the concatenated pivot identity data (B8.3.2).

16. The method according to any one of claims 1 to 15, wherein the identity of the user is defined at least by the user's first name, last name, and date of birth.

17. The method according to any one of claims 1 to 16, wherein the secure electronic device is configured to generate a plurality of secret fragments (Si) using a secret sharing function (SS), the secret sharing function being configured to generate m secret fragments from the secret (S) and to allow reconstruction of the secret (S) from a threshold of n secret fragments (Si).

18. The method of claim 17, wherein the secure electronic device (CW1) comprises a hardware wallet (HW) for a crypto-asset account, the hardware wallet having no means of connecting to the Internet, the hardware wallet being linked to or configured to be linked to a host device (HDV), the host device executing companion software (HSW) and having a connection to the Internet.

19. A server for backing up and returning secret data items (Si), the server being configured to, in response to a request to back up the secret data items: - Receive the secret data item (Si). - Receive data defining the identity of the first user (BCKDT, PID). - Generates encrypted link data (LNKSi) of (B13.2.a, B13.2.b, B13.2.c, B13.2.d, B13.2.e), wherein the encrypted link data is a function of the secret data item (Si) and the data (BCKDT, PID) defining the identity of the first user, and - The encrypted link data is stored in the server's memory (MEM).

20. The server of claim 19, wherein the server is configured to generate the encrypted link data (LNKSi) by performing the following steps: - Generate backup code (BCKDT, PID, HPIDi) based on the identity of the first user (B8.3.2). - Combine the secret data item (Si) and the backup code, and - The combination of the secret data item and the backup code is encrypted using the server's secret key (pBi).

21. The server of claim 19, wherein the server is configured to generate the encrypted link data (LNKSi) by performing the following steps: - Generate backup code (BCKDT, PID, HPIDi) based on the identity of the first user. - Using the backup code as a derivation distinguisher, apply the key derivation function (FDERIV) to the server's secret key (pBi) to obtain a first derivation key (KIDi) as a function of the data (BCKDT, PID) defining the identity of the first user, and - Encrypt the secret data item (Si) using the first derived key (KIDi).

22. The server of claim 19, wherein the server is configured to generate the encrypted link data (LNKSi) by performing the following steps: - Generate backup code (BCKDT, PID, HPIDi) based on the identity of the first user. - Combine the secret data item (Si) and the backup code, and - Hash the combination of the secret data item and the backup code. The server is also configured to encrypt the secret data item (Si) using the server's secret key (pBi) and to store the encrypted secret data item (EncSi) in the server's memory (MEM).

23. The server of claim 19, wherein the server is configured to generate the encrypted link data (LNKSi) by performing the following steps: - Encrypt the secret data item (Si) using the server's secret key (pBi). - Generate backup code (BCKDT, PID, HPIDi) based on the identity of the first user. - Combine the encrypted secret data item (EncSi) and the backup code, and - The combination of the encrypted secret data item and the backup code is encrypted using the server's secret key (pBi) and a cryptographic hash function (HMAC). The server is also configured to store the encrypted secret data item (EncSi) in the server's memory (MEM).

24. The server according to any one of claims 20 to 23, wherein the server is configured to include, in the step of generating the backup code (BCKDT, PID, HPIDi), a step of concatenating data defining the pivot identity of the user.

25. The server according to any one of claims 20 to 23, wherein the server is configured to include, in the step of generating the backup code (HPIDi), a step of concatenating data defining the pivot identity of the user, and a step of hashing the concatenated pivot identity data (B8.3.2).

26. The server of claim 20, wherein the server is configured to, in response to a request to return the secret data item (Si): - Collect (R7.1) data (BCKDT', PID') defining the identity of the second user. - Generate a recovery code (BCKDT', PID', HPIDi') based on the identity of the second user (R7.2). - Decrypt the encrypted link data (LNKSi) (R10.2.a) and extract the backup code (BCKDT, PID, HPIDi) from it. - Compare the recovery code (BCKDT', PID', HPIDi') with the backup code (BCKDT, PID, HPIDi), and If the two codes are the same, the secret data item (Si) existing in the encrypted link data (LNKSi) is returned; if the two codes are different, the secret data item is rejected.

27. The server of claim 21, wherein the server is configured to, in response to a request to return the secret data item (Si): - Collect (R7.1) data (BCKDT', PID') defining the identity of the second user. - Generate a recovery code (BCKDT', PID', HPIDi') based on the identity of the second user (R7.2). - Using the recovery code (BCKDT', PID', HPIDi') as the derivation distinguisher, apply the key derivation function (FDERIV) (R10.2.b, R10.2.c) to the server's secret key (pBi) to obtain a second derived key (KIDi') as a function of the data (BCKDT', PID') defining the identity of the second user, and - If the first derived key and the second derived key are the same, the second derived key (KIDi') is used to decrypt the encrypted link data (LNKSi) and the secret data item (Si) is extracted from it.

28. The server of claim 22, wherein the server is configured to, in response to a request to return the secret data item (Si): - Collect (R7.1) data (BCKDT', PID') defining the identity of the second user. - Generate a recovery code (BCKDT', PID', HPIDi') based on the identity of the second user (R7.2). - Decrypt the secret data item (Si) using the server's secret key. - Combine the secret data item and the recovery code (R10.2.d), and hash the combination of the secret data item and the recovery code to obtain new encrypted link data (LNKSi'). - Compare the new encrypted link data (LNKSi') with the encrypted link data (LNKSi), and If the new encrypted link data (LNKSi') is the same as the encrypted link data (LNKSi), then the secret data item (Si) is returned; otherwise, the secret data item (Si) is rejected.

29. The server of claim 23, wherein the server is configured to, in response to a request to return the secret data item (Si): - Collect (R7.1) data (BCKDT', PID') defining the identity of the second user. - Generate a recovery code (BCKDT', PID', HPIDi') based on the identity of the second user (R7.2). - Combine the secret data item and the recovery code (R10.2.e), and encrypt the combination of the secret data item and the recovery code using the server's secret key (pBi) and the cryptographic hash function (HMAC) to obtain new encrypted link data (LNKSi'). - Compare the new encrypted link data (LNKSi') with the encrypted link data (LNKSi). If the new encrypted link data (LNKSi') is the same as the encrypted link data (LNKSi), then the secret data item (Si) is decrypted and returned; otherwise, the secret data item (Si) is refused to be returned.

30. The server according to any one of claims 26 to 29, wherein the server is configured to generate the recovery code (BCKDT', PID', HPIDi') by concatenating data defining the pivot identity of the user.

31. The server according to any one of claims 26 to 29, wherein the server is configured to generate the recovery code (HPIDi'), generating the recovery code comprising the steps of concatenating data defining the pivot identity of the user, and hashing the concatenated pivot identity data (B8.3.2).

Images