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

Abstract

The invention relates to 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, which comprises the steps of providing a plurality of backup servers (BCKi), collecting data (PID) defining the identity of a first user and transmitting them to each backup server via the secure electronic device, generating, fromt he secret, a plurality of secret parts (Si), transferring one of the secret parts (Si) to each backup server, and, in each backup server, generating (B13.2.a, B13.2.b, B13.2.c, B13.2.d, B13.2.e) an encrypted link datum (LNKSi) that is a function of the secret part (Si) and the data (PID) defining the identity of the first user, and storing the encrypted link datum in a memory of the backup server.

Description

Process for linking the identity of a person to the safeguarding of a secret.

[0001] The present invention relates to a method for backing up and restoring a secret held by a secure electronic device. In particular, the present invention relates to backing up and restoring a master key held by a hierarchical deterministic hardware wallet used for storing private keys associated with cryptoasset accounts. Background

[0002] In recent years, the development of cryptocurrencies or other types of cryptoassets managed by the blockchain, such as non-fungible tokens ("NFTs") and smart contracts, has given rise to various means of storing and preserving the private and public keys attached to these different types of cryptoassets. This is how cryptoasset wallets, commonly called "wallets", have emerged, allowing the storage and preservation of these keys. A cryptoasset wallet is a hardware or software device whose function is to store the private and public keys attached to cryptoasset accounts, and to sign transactions using these keys. A distinction is made between so-called "hot wallets" and so-called "cold wallets". "Hot" wallets are connected to the Internet and susceptible to hacker attacks or exposure to viruses and malware.These can be wallets managed by centralized exchange platforms or programs installed on mobile phones, tablets, or personal computers ("software wallets"). Such wallets are connected to the Internet and are therefore themselves susceptible to attack. "Cold" or hardware wallets, on the other hand, do not have any direct access to the Internet, which reduces the attack surface and therefore the risk of theft by hacking. A hardware wallet is generally a portable electronic device, equipped with a processor with cryptographic computing capabilities. Transactions involving private keys are signed in an offline environment. Any transaction made online is temporarily transferred to the hardware wallet to be digitally signed offline, before the signature is transmitted to the online network.Since private keys are not shared with online servers during the signing process, a hacker cannot access them.

[0003] This type of hardware wallet is therefore currently considered the most secure solution against hacker attacks. Its only drawback is the risk of loss, theft, or destruction (e.g., by fire) of the hardware wallet, or of losing the user's personal password to use it. The keys it contains must therefore generally be stored in a safe place.

[0004] A first problem that arose in the past was to find a way to simplify the number of keys to be saved, these can be very numerous if the user has many cryptoasset accounts on the blockchain. To solve this problem, the hierarchical deterministic wallet was proposed by Bitcoin. First proposed in the BIP32 standard, then optimized with the BIP39, BIP43 and BIP44 standards, it allows a user to not have to make a new backup for each new pair of keys generated, a single backup for all the keys of his wallet being sufficient. This solution is today used by the vast majority of software or hardware cryptoasset wallets.

[0005] With a hierarchical deterministic wallet, all of the user's private keys are generated from a random seed, usually called the seed or master key. A user only needs to keep the seed safe to retrieve all of their keys, which are derived from the seed and can be reconstructed from it ("child keys").

[0006] In order to facilitate the memorization and storage of the seed, the BIP39 standard also provides for expressing the seed, which is a long binary number, in the form of a mnemonic phrase also called a "recovery phrase". The exact type of BIP39 seed currently used in the applicant's devices is a recovery phrase that consists of 24 words chosen from a list of 2048 words defined by the aforementioned standard.

[0007] To generate a recovery phrase, a hardware wallet generates a sequence of 256 random bits using a random number generator. The first 8 bits of a SHA-256 hash of the initial 256 bits are added to this bit string, resulting in 264 bits. The 264 bits are divided into 24 groups of 11 bits by the device. Each group of 11 bits is interpreted as a number between 0 and 2047, which serves as an index to the BIP39 word list, resulting in the 24-word mnemonic phrase. This type of wallet therefore requires only a single backup of the seed, preferably at the time of commissioning, from which the entire descending key tree can be derived.

[0008] The diagram shows a cryptoasset wallet comprising a hardware wallet HW, for example the device marketed by the applicant under the name "Ledger Nano" and a host device HDV running a companion application HSW, for example the application "Ledger Live" developed by the applicant. Since the HW device cannot connect directly to the Internet, it is associated with the host device HDV to carry out transactions on the blockchain. The host device HDV is for example a computer, a mobile phone, a tablet or equivalent. The connection between the HW device and the host device HDV can be of the USB or Bluetooth type for example.

[0009] Once connected to the host device, the HW device can interact with the companion software to allow a USR user to carry out transactions on the BCN blockchain or on decentralized exchange sites. The HW device can also communicate with a HSM ("Hardware Security Module") located in a data center. The HSM module is typically a hardware encryption box used to generate, store and protect cryptographic keys. The HSM module does not store any of the user's private keys and only ensures the authenticity of the HW device, its commissioning, the updating of its operating system, the downloading of certified application programs, etc.

[0010] When the HW device is first put into service, it provides the user with a 24-word recovery phrase which the user must keep on a suitable physical medium, for example a sheet of paper or an unalterable medium such as an engraved metal plate, which the user must keep in a safe place.

[0011] Keeping the recovery phrase safe in this way is not without risk. If a third party obtains the recovery phrase, they will be able to access all of the user's crypto accounts generated from the seed and transfer the amounts they contain to other accounts, making it very difficult to identify them.

[0012] It might therefore be desirable to provide a means of offering users a simple and practical means of storing their seed in a highly secure manner, and more generally a method for saving and restoring a secret held by a secure electronic device.

[0013] It might also be desirable that the safeguarding of a secret be linked to a person's identity in a way that can withstand an attack by a fraudster seeking to substitute the identity of another person for that of the person legitimately holding the secret. Summary

[0014] Embodiments relate to a method for backing up and restoring a secret held by a secure electronic device, comprising a step of backing up the secret comprising the steps of providing a plurality of backup servers, collecting data defining the identity of a first user, and communicating it to each backup server, by means of the secure electronic device, generating a plurality of secret shares from the secret, transferring to each backup server one of the secret shares, and, in each backup server, generating an encrypted link data which is a function of the secret share and the data defining the identity of the first user, and storing the encrypted link data in a memory of the backup server.

[0015] According to one embodiment, in at least one backup server the step of generating the encrypted link data comprises the steps of generating a backup code based on the identity of the first user, combining the secret part and the backup code, and encrypting the combination of the secret part and the backup code using a secret key of the backup server.

[0016] According to one embodiment, in at least one backup server the step of generating the encrypted link data comprises the steps of generating a backup code depending on the identity of the first user, applying a key derivation function to a secret key of the backup server, using the backup code as a derivation diversifier, to obtain a first derived key depending on the data defining the identity of the first user, and encrypting the secret part using the first derived key.

[0017] According to one embodiment, in at least one backup server the step of generating the encrypted link data comprises the steps of generating a backup code based on the identity of the first user, combining the secret part and the backup code, and hashing the combination of the secret part and the backup code to obtain the encrypted link data, the method further comprising steps of encrypting the secret part using a secret key of the backup server and storing the encrypted secret part 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 comprises the steps of encrypting the secret part using a secret key of the backup server, generating a backup code depending on the identity of the first user, combining the encrypted secret part and the backup code, and encrypting the combination of the encrypted secret part and the backup code using a secret key of the backup server and a cryptographic hash function, the method further comprising a step of storing the encrypted secret part in the memory of the backup server.

[0019] According to one embodiment, the step of generating the backup code comprises a step of concatenating data defining a pivot identity of the user.

[0020] According to one embodiment, the step of generating the backup code comprises a step of concatenating data defining a pivot identity of the user, and a step of hashing the concatenated pivot identity data.

[0021] According to one embodiment, the method comprises a step of restoring the secret comprising the steps of collecting data defining the identity of a second user, verifying their validity with the participation of the second user, and providing them to at least one backup server, and by means of the backup server, verifying, by means of the encrypted link data, that the identity of the second user is the same as the identity of the first user.

[0022] According to one embodiment, the step of verifying the identity of the second user comprises at least one of the following operations: decrypting the encrypted link data, extracting therefrom the identity of the first user or data depending on his identity, and comparing it to the identity of the second user or to data depending on the identity of the second user; decrypting the encrypted link data using a key depending on the identity of the second user; calculating a new encrypted link data from the identity of the second user and comparing it to the initial encrypted link data.

[0023] According to one embodiment, the method comprises a step of restoring the secret comprising the steps of collecting data defining the identity of a second user, verifying their validity with the participation of the second user, and providing them to at least one backup server, and, by means of the backup server: generating a restoration code depending on the identity of the second user, decrypting the encrypted link data using the secret key of the backup server and extracting the backup code therefrom, comparing the restoration code and the backup code, restoring the secret part present in the encrypted link data if the two codes are identical, and refusing to restore it if the two codes are not identical.

[0024] According to one embodiment, the method comprises a secret restoration step comprising the steps of collecting data defining the identity of a second user, verifying their validity with the participation of the second user, and providing them to at least one backup server, and, by means of the backup server: generating a restoration code depending on the identity of the second user, applying the key derivation function to the secret key of the backup server using the restoration code as a derivation diversifier, to obtain a second derived key depending on the data defining the identity of the second user, and if the first and second derived keys are identical, decrypting the encrypted link data by means of the second derived key and extracting the secret part therefrom.

[0025] According to one embodiment, the method comprises a secret restoration step comprising the steps of collecting data defining the identity of a second user, verifying their validity with the participation of the second user, and providing them to at least one backup server, and, by means of the backup server, generating a restoration code depending on the identity of the second user, decrypting the secret part using the secret key of the backup server, combining the secret part and the restoration code, and hashing the combination of the secret part and the restoration code to obtain a new encrypted link data, comparing the new encrypted link data and the encrypted link data, and restoring the secret part if the new encrypted link data and the encrypted link data are identical, otherwise refusing to restore the secret part.

[0026] According to one embodiment, the method comprises a secret restoration step comprising the steps of collecting data defining the identity of a second user, verifying their validity with the participation of the second user, and providing them to at least one backup server, and, by means of the backup server, generating a restoration code depending on the identity of the second user, combining the secret part and the restoration code, and encrypting the combination of the secret part and the restoration code using the secret key of the backup server and the cryptographic hash function, to obtain a new encrypted link data, comparing the new encrypted link data and the encrypted link data, decrypting and restoring the secret part if the new encrypted link data and the encrypted link data are identical, otherwise refusing to restore the secret part.

[0027] According to one embodiment, the step of generating the restoration code comprises a step of concatenating data defining a pivot identity of the user.

[0028] According to one embodiment, the step of generating the restoration code comprises a step of concatenating data defining a pivot identity of the user, and a step of hashing the concatenated pivot identity data.

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

[0030] According to one embodiment, the secure electronic device is configured to generate a plurality of secret shares by means of a secret sharing function provided to generate a number m of secret shares from the secret and allow the reconstitution of the secret from a threshold of n secret shares.

[0031] According to one embodiment, the secure electronic device comprises a hardware wallet of cryptoasset accounts without a means of connecting to the Internet connected or configured to be connected to a host device running companion software and provided with a connection to the Internet.

[0032] Embodiments also relate to a server for saving and restoring secret data, configured to, in response to a request to save the secret data: receive the secret data, receive data defining the identity of a first user, generate encrypted link data that is a function of the secret data and the data defining the identity of the first user, and store the encrypted link data in a memory of the server.

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

[0034] According to one embodiment, the server is configured to generate the encrypted link data by performing the steps of: generating a backup code based on the identity of the first user, applying a key derivation function to a secret key of the server using the backup code as a derivation diversifier, to obtain a first derived key based on the data defining the identity of the first user, and encrypting the secret data using the first derived key.

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

[0036] According to one embodiment, the server is configured to generate the encrypted link data by performing the steps of: encrypting the secret data using a secret key of the server, generating a backup code based on the identity of the first user, combining the encrypted secret data and the backup code, and encrypting the combination of the encrypted secret data and the backup code using a secret key of the server and a cryptographic hash function, the server being further configured to store the encrypted secret data in the memory of the server.

[0037] According to one embodiment, the server is configured to include in the backup code generation step a data concatenation step defining a pivot identity of the user.

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

[0039] According to one embodiment, the server is configured to, in response to a request to restore the secret data: collect data defining the identity of a second user, generate a restoration code based on the identity of the second user, decrypt the encrypted link data and extract the backup code therefrom, compare the restoration code and the backup code, and restore the secret data present in the encrypted link data if the two codes are identical, and refuse to restore it if the two codes are not identical.

[0040] According to one embodiment, the server is configured to, in response to a request for restitution of the secret data: collect data defining the identity of a second user, generate a restoration code depending on the identity of the second user, apply the key derivation function to the secret key of the server using the restoration code as a derivation diversifier, to obtain a second derived key depending on the data defining the identity of the second user, and if the first and second derived keys are identical, decrypt the encrypted link data using the second derived key and extract the secret data therefrom.

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

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

[0043] According to one embodiment, the server is configured to generate the restoration code by concatenating data defining a pivot identity of the user.

[0044] According to one embodiment, the server is configured to generate the restoration code comprising a step of concatenating data defining a pivot identity of the user, and a step of hashing the concatenated pivot identity data. Summary description of the drawings

[0045] These characteristics as well as others of the present invention, will be better understood on reading the following description, given without limitation in relation to the attached figures among which:

[0046] - the previously described diagram shows a cryptoasset portfolio and an example of its use,

[0047] - laet lashow a cryptoasset portfolio according to the invention and the architecture of a system intended for the implementation of a first embodiment of the method according to the invention, laillustrating a data backup step and laa data restoration step,

[0048] - laet lashow a cryptoasset portfolio according to the invention and the architecture of a system provided for the implementation of a second embodiment of the method according to the invention, laillustrating a data backup step and laa data restoration step,

[0049] - laet ladescribe an algorithm executed by the system of figures 3A, 3B, during the data saving step,

[0050] - is a sequence diagram which represents the steps of the algorithm of figures 4A, 4B in the form of interactions between different elements of the system of figures 3A, 3B,

[0051] - laet ladescribe an algorithm executed by the system of figures 3A, 3B, during the data restoration step,

[0052] - is a sequence diagram which represents the steps of the algorithm of 1a, 5B in the form of interactions between different elements of the system of figures 3A, 3B,

[0053] - laet lashow a cryptoasset portfolio according to the invention and the architecture of a system intended for the implementation of a third embodiment of the method according to the invention, laillustrating a data backup step and laa data restoration step,

[0054] - shows a cryptoasset portfolio according to the invention and an example of hardware portfolio architecture according to the invention allowing the implementation of the method according to the invention,

[0055] - shows another embodiment of a cryptoasset portfolio enabling the method according to the invention to be implemented,

[0056] - shows yet another embodiment of a cryptoasset portfolio enabling the method according to the invention to be implemented. Detailed description

[0057] The invention provides a method for creating a cryptoasset wallet that offers a unique feature in the field of hardware wallets, namely a seed backup feature that is automated yet highly secure. Such a feature allows users to avoid all the difficulties and dangers associated with having to store a recovery phrase themselves in a secure location.

[0058] Lamontre a cryptoasset wallet CW1 and a system intended for implementing an embodiment of the method of the invention. The cryptoasset wallet CW1 here comprises an HW device and a host device HDV. The HW device is a hardware wallet ensuring the cold storage of a seed S or master key, of a set of cryptoassets. The HW device does not have any means of connection to the Internet and is connected to the host device HDV, which runs HSW companion software allowing it to connect to the Internet, for example by means of a USB or Bluetooth connection. The system and the method according to the invention make it possible to save or restore the seed S (master key) stored in the HW device.

[0059] The system essentially comprises a set of BCKi backup servers (BCK1, BCK2,… BCKi,…BCKm) each provided with a backup memory MEM (magnetic hard disk or solid state memory) for backing up shares Si of the seed S. Each backup server comprises a BEi back-end program (BE1,…BEi,…BEm), or "back-end" program, designed for implementing the method. Each BCKi backup server is also associated with an HSM security module.

[0060] According to the method of the invention, the HW device is configured to divide the seed S into a plurality of secret data Si (S1, S2…Si,…Sm) which will be saved on the BCKi servers. Rather than a simple splitting, which is however not excluded from the scope of the present invention, this "division" is preferably ensured by means of a secret sharing function SS making it possible to generate a number of secret data called "shares", and allowing the reconstitution of the seed from a threshold of secret data Si:

[0061] S1, S2,…, Si,…, Sm = SS (S)

[0062] For example, if m is equal to 3 and n is equal to 2, the SS function allows the seed to be divided into three parts S1, S2, S3, but only two parts will be needed to reconstitute the seed. If m is equal to 2 and n is equal to 2, the SS function allows the seed to be divided into two parts S1, S2, both of which are needed to reconstitute the seed.

[0063] When the user wants to back up his seed, the HW device establishes LNKi data links (LNK1 to LNKm), for example of the HTTPS type, with each BCKi backup server via the HDV host device. These data links are then secured by creating secure channels of the SCP ("Secure Channel Protocol") type between the HW device and each BCKi backup server, in a manner that will be described.

[0064] The creation of such secure channels is ensured by means of a public key infrastructure managed by a CA. The HW device and the BCKi backup servers each have a private key, a public key, a certificate signed by the CA, or static certificate, as well as the public key of the CA. The following notation will be used in the following:

[0065] pL: private key of the certification authority

[0066] PL: public key of the certification authority

[0067] pD: HW device private key

[0068] PD: public key of the HW device

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

[0070] pBi: private key of a BCKi server (for i ranging from i to m)

[0071] PBi: public key of a BCKi server (for i ranging from i to m)

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

[0073] The signature function "Sign" is for example generated using an ECDSA signature algorithm based on elliptic curves ("Elliptic Curve Digital Signature Algorithm").

[0074] The CA certification authority is preferably held by the manufacturer of the HW device, to allow it to control the allocation of CBi certificates to the BCKi backup servers. The BCKi backup servers may be held by the manufacturer of the HW device, or be servers of third-party partners participating in the implementation of the method. The keys pBi, PBi of the BCKi backup servers are held by their respective HSM modules, which handle the cryptographic calculations performed using these keys. In the following and for the sake of simplification of the language, it will be considered that such cryptographic calculations are performed by the servers themselves.

[0075] To implement a secure communication channel, a key exchange is planned between the HW device and each BCKi backup server, allowing the generation of kBi session keys specific to each BCKi server but known to the HW device. This key exchange is for example a Diffie Hellman key exchange carried out in accordance with the following steps:

[0076] i) each BCKi backup server generates an ephemeral private key pair peBi and public key PeBi using an asymmetric key generator, then communicates its ephemeral public key PeBi to the HW device in an ephemeral certificate CeBi that it has signed with its private key pBi, as well as its certificate CBi signed by the trusted authority:

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

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

[0079] ii) the HW device itself generates an ephemeral private key pair peD and public key PeD, then communicates its ephemeral public key PeD to the BCKi backup servers in an ephemeral certificate CeD that it has signed with its private key pD, as well as its certificate CD signed by the trusted authority, i.e.:

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

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

[0082] iii) each BCKi backup server verifies the signature of the ephemeral public key PeD of the HW device using the public key PD present in its CD certificate, then verifies the signature of the public key PD present in the CD certificate using the public key PL of the certification authority, or vice versa (verification of the signature of the public key PD before verification of the signature of the ephemeral public key PeD),

[0083] iv) similarly, the HW device verifies the signature of the ephemeral public key PeBi of each BCKi server using the public key PBi present in the CB certificate, then verifies the signature of the public key PBi present in the CB certificate using the public key PL of the certification authority, or vice versa,

[0084] v) each backup server BCKi generates an ephemeral session key kBi from its ephemeral private key peBi and the ephemeral public key PeD of the HW device, by means of a key exchange function such as, for example, the ECDH function (Elliptic Curve Diffie–Hellman key exchange), i.e.:

[0085] kBi = ECDH(peBi, PeD)

[0086] vi) the HW device generates the ephemeral session key kBi of each BCKi backup server from its ephemeral private key peD and the ephemeral public key PeBi of the BCKi backup server, using the same function, either:

[0087] kBi = ECDH(peD, PeBi)

[0088] After generating the shares Si of the seed S, the HW device conducts symmetric encryption steps for each share Si with the session key kBi common to the backup server BCKi to which the share Si must be sent, which therefore forms a shared key. In a simple implementation example, the HW device generates three shares S1, S2, S3 (the threshold n can then be equal to 2 or 3) and three backup servers BCK1, BCK2, BCK3 are provided. Each BCKi server generates its own session key kB1, kB2, kB3 and the HW device generates each of these session keys on its side after a key exchange with each server in the manner just described. Then, the HW device conducts symmetric encryption steps for the shares S1, S2, S3 using these keys, namely:

[0089] - encrypts the part S1 with the key kB1, i.e. {S1}kB1, then sends it to the server BCK1,

[0090] - encrypts the part S2 with the key kB2, i.e. {S2}kB2, then sends it to the server BCK2,

[0091] - encrypts the S3 share with the key kB3, i.e. {S3}kB3, then sends it to the BCK3 server.

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

[0093] According to the method, and as illustrated in the, the restoration of the seed S is carried out in a second hardware wallet denoted HW'. This can be a device other than the HW device if the latter has been lost, stolen or destroyed. It can also be the HW device if the latter has been reset, the HW device then being considered as an "other" device from the perspective of the method, since it no longer has the seed.

[0094] To restore the seed, the secure channel creation steps described above are repeated. New session keys kBi are generated. Then, each server encrypts the share Si it holds with the session key kBi, i.e. {Si}kBi, and sends it to the HW device. The latter then decrypts each share Si using the corresponding session key kBi, and then reconstructs the seed S using the inverse function of the one used to generate the shares Si, denoted "SS -1 " :

[0095] S = SS -1 (S1, S2,…, Si,…, Sm)

[0096] Lamontre the architecture of a system for implementing another embodiment of the method of the invention. In this embodiment, an ORCSRV1 server is interposed between the HDV host device and the BCKi backup servers. This server, referred to as a non-limiting term "orchestrator server", executes a back-end program ORC1 referred to below as the "orchestrator program" or "orchestrator". The ORCSRV1 server is connected to an HSM security module provided with a private key pO, a public key PO, and a CO certificate (static certificate) signed by the CA certification authority:

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

[0098] For implementing the method, a first data link LNK1 is established between the HW device and the orchestrator ORC1 by means of the host device HDV, for example an HTTPS link. A plurality of data links LNK2i are also established between the orchestrator and the backup servers BCKi, for example HTTPS, IPsec VPN links, etc.

[0099] The data link between the orchestrator and the HW device is secured by creating a secure channel using the same technique as described above:

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

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

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

[0103] ii) the HW device generates an ephemeral private key pair peD and public key PeD and then communicates its ephemeral public key PeD to the orchestrator in an ephemeral certificate CeD that it has signed with its private key pD, accompanied by its certificate CD signed by the trusted authority, i.e.:

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

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

[0106] iii) the ORC1 orchestrator verifies the signature of the ephemeral public key PeD of the HW device using the public key PD present in the CD certificate, then verifies the signature of the public key PD using the public key PL of the certification authority, or vice versa,

[0107] iv) similarly, the HW device verifies the signature of the ephemeral public key PeO of the orchestrator using the public key PO present in the CO certificate, then verifies the signature of the public key PO using the public key PL of the certification authority, or vice versa,

[0108] v) the orchestrator ORC1 generates an ephemeral session key k0 from its ephemeral private key peO and the ephemeral public key PeD of the HW device:

[0109] k0 = ECDH(peO, PeD)

[0110] vi) the HW device generates the ephemeral session key k0 from its ephemeral private key peD and the ephemeral public key PeO of the orchestrator:

[0111] k0 = ECDH(peD, PeO)

[0112] Once the secure channel is created between the orchestrator and the HW device, data intended for the BCKi backup servers can be securely sent by the HW device to the orchestrator, thanks to symmetric encryption using the shared session key k0 of all or part of the exchanged data. Conversely, the orchestrator can communicate to the HW device in an encrypted form using the key k0 of the data received from the BCKi backup servers.

[0113] Secure channels are also created between the HW device and the BCKi backup servers using kBi session keys that are generated after a key exchange via the LNK1 data link, with the orchestrator acting as a gateway or "proxy server" between the HW device and the BCKi servers.

[0114] After carrying out these steps, we distinguish:

[0115] - through the data link LNK1, a channel secured by the session key k0 shared by the orchestrator and the HW device, which allows the encryption of the data exchanged between the orchestrator and the HW device,

[0116] - through the LNK2i data links, channels secured by the kBi session keys specific to each BCKi backup server and known to the HW device, which allows the HW device to exchange data with each BCKi server in encrypted form.

[0117] It may also be provided, in certain cases, to encrypt with the key k0 data which is received by the orchestrator in a form encrypted by the keys kBi, which corresponds to an over-encryption of this data.

[0118] In one embodiment, the previously described key exchange steps are modified as follows:

[0119] i) the orchestrator generates an ephemeral private key peO, an ephemeral public key PeO and an ephemeral certificate CeO signed with its private key pO, and transfers its ephemeral certificate CeO to the device as well as its certificate CO:

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

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

[0122] ii) the HW device generates an ephemeral private key peD and an ephemeral public key PeD and calculates a first signature Sign(pD, PeD) of its ephemeral public key PeD from its private key pD and using the ECDSA algorithm,

[0123] iii) the device generates the session key k0 from its ephemeral private key peD and the orchestrator's ephemeral public key PeO,

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

[0125] {CD}k0

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

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

[0128] vi) the device transfers to the orchestrator its CD certificate encrypted with the session key k0 as well as its ephemeral certificate CeD including the signature of its ephemeral public key PeD encrypted with the session key k0:

[0129] {CD}k0 || CeD

[0130] either

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

[0132] ("||" being the symbol for concatenation)

[0133] vii) the orchestrator generates the session key k0 from its ephemeral private key peO and the ephemeral public key PeD received from the device, and

[0134] viii) using the session key k0, the orchestrator decrypts the signature present in the ephemeral certificate CeD and decrypts the device's CD certificate.

[0135] Returning to the, it is clear from the above that the provision of the ORC1 orchestrator makes it possible to reduce the number of data links between the HW device and the BCKi backup servers, these links being replaced by the single LNK1 data link between the HW device and the orchestrator, while ensuring an additional degree of security thanks to the possibility of over-encrypting data passing through the LNK1 link. It is also possible to preserve the confidentiality of the public key PD thanks to the improvements just described. The provision of the orchestrator has various other advantages which will be described later in relation to the implementation of user identity verification steps.

[0136] The step of saving the seed S can in this case be implemented as follows, with reference to:

[0137] i) establishment of the LNK1 connection between the HW device and the orchestrator and sending by the HW device of a backup request BCKRQ to the orchestrator,

[0138] ii) generation by the orchestrator of a random identifier BCKID of the backup, establishment of LNK2i links between the orchestrator and the BCKi backup servers, sending by the orchestrator to the BCKi backup servers of the identifier BCKID,

[0139] iii) creation of the secure channel between the HW device and the ORC1 orchestrator using the session key k0,

[0140] iv) creation of secure channels between the HW device and the BCKi backup servers using kBi session keys, via the ORC1 orchestrator,

[0141] v) generation by the HW device of the parts Si of the seed S:

[0142] S1, S2,…, Si,…, Sm = SS (S)

[0143] vi) encryption by the HW device of each part Si using the session key kBi of the backup server BCKi to which the part Si is intended,

[0144] vii) sending by the HW device of all the encrypted shares {Si}kBi to the orchestrator:

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

[0146] viii) sending by the orchestrator to each backup server BCKi of the encrypted part {Si}kBi intended for it,

[0147] ix) decryption by each BCKi server of the part Si communicated to it, and storage in its memory in association with the backup identifier BCKID.

[0148] Furthermore, the step of restoring the seed S in a new HW' device, illustrated in the, triggered at the request of the user USR, includes the following steps:

[0149] i) establishment of the LNK1 connection between the HW device and the orchestrator and sending by the HW device of a restoration request RESTRQ to the orchestrator, accompanied by the backup identifier BCKID,

[0150] ii) establishment of LNKi links between the orchestrator and the BCKi backup servers, and sending by the orchestrator to the BCKi backup servers of the BCKID identifier, so that they are informed of the restoration to be carried out,

[0151] iii) creation of the secure channel between the HW device and the ORC1 orchestrator using a new session key k0,

[0152] iv) creation of secure channels between the HW device and the BCKi backup servers using new kBi session keys, through the ORC1 orchestrator,

[0153] v) reading by each backup server BCKi, in its memory, using the identifier BCKID, of the part Si that it holds, and encryption of this part using the new session key kBi,

[0154] vi) transmission to the orchestrator, by each backup server BCKi, of the encrypted part {Si}kBi,

[0155] vii) collection by the orchestrator of all encrypted shares {Si}kBi provided by the BCKi backup servers:

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

[0157] viii) transmission to the HW device of each encrypted part {Si}kBi, one after the other or all together:

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

[0159] ix) decryption, by the HW device, of each part Si using the session key kBi of the corresponding backup server BCKi:

[0160] If = {If} -1 kBi

[0161] x) reconstitution of the seed by the HW device and storage of it in its memory:

[0162] S = SS -1 (S1, S2,…, Si,…, Sm)

[0163] It will be noted that in one embodiment the orchestrator may collect only n shares necessary to reconstitute the seed, if n is less than m. In this case, the seed is reconstituted from the n shares recovered:

[0164] S = SS -1 (S1, S2,…, Si,…, Sn)

[0165] It has been assumed in the above that the backup identifier BCKID has been retained by the HSW companion software of the HDV host device despite the loss of the HW device used during the backup. In an embodiment making it possible to prevent the case where the user has permanently uninstalled the HSW companion software, a client account server UASRV can be provided, comprising a UACC user account in which various data concerning the user are retained, in particular the backup identifier BCKID. The UASRV server is associated with an HSM security module receiving a private key pC, a public key PC, a certificate CC signed by the certification authority, and the public key PL of the latter. In this case, the HW device establishes a data link with the UASRV server thanks to a key exchange making it possible to define a session key for the creation of a secure channel, with reciprocal verification of the certificates.Once the secure channel is established, the HSW companion software connects to the UACC client account to retrieve the BCKID. Alternatively, the BCKID is stored on the UASRV server but is not communicated to the companion software. A secure connection is established between the UASRV server and the ORC1 orchestrator. The orchestrator transfers the BCKID to the UASRV server at backup time and reciprocally receives the BCKID from the UASRV server when the user wants to restore their seed.

[0166] In one embodiment, the user's identity is also associated with the backup process, by defining a set of PID data forming a "pivot identity" allowing the user to be identified. The information forming the pivot identity includes, for example, the user's first name, last name, and date of birth, and optionally other data such as their place of birth. This information is collected by the companion software and is communicated to the orchestrator, which assembles it to form a binary string that will be designated "c" BCKDT.

[0167] In some embodiments, the BCKDT data contains, in addition to the PID data, ODT data other than that relating to the user's identity, such as the date and time of the backup, and / or a name given by the user to the backup (to allow the user to subsequently distinguish several backups, if the user holds several hardware wallets). In this case, the BCKDT data is written as follows:

[0168] BCKDT = PID||ODT

[0169] When the backup is initialized, as shown in the, the orchestrator communicates the BCKDT data to the BCKi backup servers, which will associate them, along with the BCKID identifier, with the backed up Si shares. For confidentiality reasons, it might be preferred, in some embodiments, that the orchestrator does not retain the BCKDT data once the backup is performed. In this case, the BCKDT data is only retained by the BCKi servers, which communicate it to the user USR for confirmation by the latter of his identity at the time of restoration, as shown in the.

[0170] In one embodiment of the method, the pivot identity of the user is verified during at least one identity verification step designated “IDV” (“Identity Verification”) which is conducted before the restoration of the seed. In one embodiment, several identity verification steps IDVi are preferably provided before proceeding with the restoration of the seed, these steps being conducted by all or part of the backup servers BCKi requested for the restitution of a part Si of the seed S.

[0171] In one embodiment shown in the, these identity verification steps are entrusted to specialized service providers instead of being carried out by the BCKi backup servers themselves. Such service providers have IDVSRVi servers each running an automated IDVSi identity verification service accessible via a GTW gateway ("Gateway"). Each BCKi backup server can be assigned a different IDVSRVi server, and be configured to connect to the GTW gateway of the IDVSi service executed by this server. Preferably, such IDVSi services are not fully automated, at least for some of them, and include human intervention, particularly in the event of doubt about the identity of a person.

[0172] Thus, each BCKi backup server, or at least some of them, is configured to perform an IDVi step to verify the pivot identity of the user when it receives a request to return a share of the seed. The server is then preferably configured to refuse to return the share if this verification is not conclusive.

[0173] In one embodiment, the seed backup step is also preceded by an initial IDV0 step, conducted by the orchestrator or supervised by the latter, of verifying the pivot identity of the user (i.e. at least his first name, last name and date of birth). In this case, an IDVSRV0 server is also associated with the orchestrator ORC1, and the orchestrator is configured to connect to a GTW gateway of an IDVS0 service executed by this server for carrying out the IDV0 step.

[0174] During the optional IDV0 step before the backup or each of the IDVi steps occurring before the restitution of the shares of the seed, the orchestrator connects the USR user with the appropriate IDVS0 or IDVSi service, via the appropriate GTW gateway. The user must perform certain actions requested via the screen of the HDV host device and the camera with which it is equipped (for example, a mobile phone camera, a personal computer webcam, etc.). For example, the IDVS0 or IDVSi service asks the user to present a valid ID including a photo of himself, to take a photo of the ID with his camera and to send it to him. The IDVS0 or IDVSi service then asks the user to take a photo (selfie) or a video of his face and to send it.The IDVS0 or IDVSi service then verifies the authenticity of the ID document from the photo or video of its face, and the ID document, once verified, allows it to verify the data of the pivot identity with a degree of certainty which may, in certain embodiments, result in a score. The result of this verification, and optionally the score, is communicated to the orchestrator. In one embodiment, the IDV steps may also include verifications on government databases.

[0175] Although the IDV0 step is not as critical as those performed by the BCKi servers at the time of Si share restitution, it ensures that the user has not made a mistake in providing the information relating to his identity, which is incorporated into the BCKDT data. Furthermore, the information collected by the orchestrator during this step, such as the photo of his ID and the photo or video of his face, can optionally be communicated to the BCKi backup servers through a specific communication channel, since this information is not part of the BCKDT backup data.

[0176] In one embodiment, the ORC1 orchestrator may suspend the seed backup process if it considers that the initial verification of the user's identity is inconclusive or is assigned too low a score. Furthermore, in another embodiment or in addition, the orchestrator receives from the BCKi backup servers information on the success of the IDVi identity verification steps that they have conducted or that have been conducted by the service providers with which they are affiliated. If a determined number of BCKi servers have not successfully verified the user's identity and refuse to return the Si shares that they hold, the orchestrator may be configured to suspend the return of the Si shares by the servers that have successfully verified the user's identity. The orchestrator may optionally decide to subject the user to an additional identity verification step.

[0177] Alternatively, or in addition, the orchestrator receives from each BCKi backup server that has conducted an identity verification step, a certainty score regarding the user's identity. If the average of the scores is lower than a first threshold, and / or if one of the scores is lower than a second threshold, the orchestrator suspends the restoration process and optionally subjects the user to an additional identity verification step.

[0178] In the ultimate case where the user has closed his account on the UASRV account server, has uninstalled the companion software by erasing the data it contained, and has lost his hardware wallet HW and can therefore no longer recover the identifier of the backup BCKID, a solution can be provided to allow him to recover his seed. The user will then have to undergo a plurality of individual steps of verification of his identity with each BCKi server to recover each share Si of the seed. A procedure involving a ministerial officer, such as a notary, can also be provided.Each IDV provider may also verify that its approach is legitimate by ensuring that there is no account attached to this user in the system's account server, and entrust more in-depth investigation procedures to individuals, such as conducting a telephone interview with the user, conducting a video conference with the user, conducting a face-to-face interview with the user, validating the user's educational or employment history, etc.

[0179] It will be clear to those skilled in the art that the method of the invention is susceptible to various other embodiments and variants. In particular, the data of the BCKID backup could, in one embodiment, include in a compressed form the data collected in step IDV0 to verify the pivot identity of the user, such as the photo or video of his face and a photo of an identity document. The automated steps for verifying the pivot identity of the user as conducted by IDVSi services executed by IDVSRVi servers or by the BCKi backup servers themselves, may comprise at least two of the following steps: acquisition, via a camera, of a photo of an unexpired identity document comprising a photo of the user; acquisition, via a camera, of one or more photos of the user's face;acquisition, via a camera, of a video recording showing the user's face in motion, with detection of the living to verify that the user is real; acquisition of proof of address, such as an electricity or telephone bill; acquisition of a fingerprint of the user; acquisition of a validation code received by the user in a telephone message, by email or by post; activation by the user of a link received by the user in a telephone message, by email or by post, and acquisition of a hologram present on an identity document that has not expired.;

[0180] An example of a seed saving algorithm applicable to the laet system implementing various aspects of the previously described embodiments of the method will now be described in relation to Figures 4A and 4B. Laet is a sequence diagram that represents the steps of the algorithm in the form of interactions between:

[0181] - the USR user,

[0182] - the HW device and its host device HDV (considered as a single entity forming the cryptoasset wallet CW1),

[0183] - the ORC1 orchestrator and the HSM security module associated with it (also considered as a single entity), and

[0184] - the IDVSRV0 server associated with the orchestrator to carry out the IDV0 step of verifying the user's identity,

[0185] - BCKi backup servers, and

[0186] - IDVSRVi servers associated with BCKi servers to perform subsequent identity verification steps, when restoring the seed.

[0187] Some functions used in the algorithm are shown in Table 1 below, as a non-limiting example:

[0188] Cryptography typeElliptic curve cryptographySignECDSA (Elliptic Curve Digital Signature Algorithm) signature with the elliptic curve secp256k1ECDHElliptic curve-based Diffie-Hellman key exchange using, for example, the elliptic curve secp256k1Hash functionSHA-256 (Secure Hash Algorithm)Symmetric encryption {.}k0AEAD-AES-SIV-CMAC-256 algorithmSS functionShamir Secret Sharing function or other similar function, or Pedersen PVSS publicly verifiable secret sharing based on the curve secp384r1

[0189] Description of the algorithm, in relation to figures 4A, 4B and 4C.

[0190] B1. Initializing the backup

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

[0192] [HW → ORC1]

[0193] BCKRQ

[0194] Optionally, the HW device offers the user the possibility to choose the number m of shares Si that he wishes to generate for the backup of the seed, and the threshold n corresponding to the number of shares necessary for the reconstitution of the seed S. Still optionally, the HW device can present to the user a list of BCKi backup servers, some of which may be external partners, and ask the user to indicate those he wishes to use. Otherwise, these are selected automatically by the orchestrator. The orchestrator ORC1 establishes a data link with the BCKi servers, then initiates the backup process according to the steps described below.

[0195] B2. Generation and sending to the HW device and BCKi servers of the backup identifier

[0196] [ORC1 → BCKi, HW] BCKID

[0197] The ORC1 orchestrator generates the backup identifier BCKID, for example a random number, and transfers it to the HW device and BCKi servers.

[0198] B3. Performing an IDV0 identity verification by the IDVSRV0 server

[0199] [IDVSRV0] IDV0

[0200] The ORC1 orchestrator connects the user to the IDVSRV0 server through a GTW gateway. The IDVS0 service performs a verification of the pivot identity of the IDV0 user.

[0201] B4. Confirmation by the orchestrator of the success of the identity verification

[0202] IDV_OK → HW

[0203] The IDVSRV0 server confirms to the ORC1 orchestrator that the IDV has been successfully completed, and the ORC1 orchestrator confirms to the user via the HW device that his identity has been verified and that the seed backup step can be initiated. At this step, the ORC1 orchestrator can generate the BCKDT backup data and send it to the HW device.

[0204] B5. Mutual authentication and creation of a secure channel between the orchestrator and the device

[0205] B5.1. Generation of an ephemeral certificate by the orchestrator

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

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

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

[0209] The orchestrator ORC1 generates an ephemeral private key peO and an ephemeral public key PeO. The orchestrator calculates the signature of its ephemeral public key PeO using its private key pO. In a variant chosen here, the orchestrator calculates the signature of its ephemeral public key PeO after concatenating it with a ReO data item. The ReO data item specifies, for example, the role played by the orchestrator server in the process, for example, the role of orchestrator for establishing a secure channel. The orchestrator then generates an ephemeral certificate CeO by concatenating the ephemeral public key PeO and the signature.

[0210] B5.2. Sending the orchestrator's certificates to the device

[0211] CeO||CO → HW

[0212] The ORC1 orchestrator sends its ephemeral certificate and CO certificate to the HW device.

[0213] B5.3. Verification by the device of the orchestrator's certificates

[0214] Verif CeO, Verif CO

[0215] The HW device verifies the orchestrator's certificate chain, as described above, using the CA's PL public key.

[0216] B5.4. Generation by the HW device of a session key k0 and an ephemeral certificate

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

[0218] k0 = ECDH(peD, PeO)

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

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

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

[0222] {CD}k0

[0223] The HW device generates an ephemeral private key peD and an ephemeral public key PeD, and then a session key k0 from its ephemeral private key peD and the orchestrator's ephemeral public key PeO using the ECDH algorithm. The HW device then calculates the signature of its ephemeral public key PeD using its private key pD, here after concatenating the ephemeral public key PeD with a piece of data ReD. The data ReD specifies, for example, the role played by HW in the process. The HW device then encrypts the signature of its ephemeral public key with the session key k0. The HW device then forms an ephemeral certificate CeD by concatenating the ephemeral public key PeD and the encrypted signature. Finally, the HW device encrypts its certificate CD using the key k0.

[0224] B5.5. Sending device certificates to the orchestrator

[0225] [HW → ORC1]

[0226] CeD||{CD}k0

[0227] The HW device sends its CD certificate encrypted using the key k0 and its ephemeral certificate CeD, including the encrypted signature, to the orchestrator ORC1. By encrypting the certificate and encrypting the signature of the ephemeral certificate, the public key PD is not exposed. The order of these steps can be reversed, with the device sending its certificate, here encrypted, before sending its ephemeral certificate, here including the encrypted signature.

[0228] B5.6. Generation of session key k0 by the orchestrator

[0229] k0 = ECDH(peO, PeD)

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

[0231] B5.7. Verification by the orchestrator of the device certificates

[0232] CD={CD} -1 k0

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

[0234] Verif CeD, Verif CD

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

[0236] B6. Sending BCKID, BCKDT data and CeD, CD certificates of the device to the BCKi servers

[0237] [ORC1 → BCKi]

[0238] For each BCKi server, i ranging from 1 to m

[0239] BCKID||BCKDT||CeD||CD

[0240] The ORC1 orchestrator sends to each BCKi server the backup identifier BCKID, the backup data BCKDT which includes at least the pivot identity data. Other data can optionally be sent or have been sent to the backup servers by other channels, such as the photo or video of the user's face taken in step IDV0, and the photo of an identity document. If this data is not included in the backup data BCKDT, it can be stored by the client accounts server and transmitted to the BCKi servers after the backup.

[0241] B7. Verification by each BCKi server of the device's certificates

[0242] For each BCKi server, i ranging from 1 to m

[0243] Verif CeD, Verif CD

[0244] Each BCKi server verifies the HW device's certificate chain in the manner previously described.

[0245] B8. Mutual authentication and creation of a secure channel between BCKi servers and the device, via the orchestrator

[0246] B8.1. Generation by each BCKi server of an ephemeral certificate

[0247] For each BCKi server, i ranging from 1 to m

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

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

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

[0251] Each BCKi server generates an ephemeral private key peBi and an ephemeral public key PeBi. Each BCKi server calculates the signature of its ephemeral public key PeBi after concatenating it with a data ReB using its private key pBi. ReB specifies for example the role that each server plays in the process, for example the role of backup server for the management of the secure channel. Then each BCKi server generates an ephemeral certificate CeBi by concatenating the ephemeral public key PeBi and its signature.

[0252] B8.2. Generation by each BCKi server of a kBi session key

[0253] For each BCKi server, i ranging from 1 to m

[0254] kBi = ECDH(peBi, PeD)

[0255] Each BCKi server then generates a session key kBi from its ephemeral private key peBi and the ephemeral public key PeD of the HW device, using the ECDH algorithm.

[0256] B8.3.1. Generation by each BCKi server of an encrypted hash code

[0257] For each BCKi server, i ranging from 1 to m

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

[0259] CHi = {Hi}kBi

[0260] Each BCKi server then generates a hash code Hi from a binary string including its ephemeral public key PeBi, the BCKID data, and the backup data BCKDT. Each BCKi server then encrypts the code Hi using the session key kBi to obtain an encrypted hash code CHi.

[0261] B8.3.2. Generation by each BCKi server of a backup code based on the user's pivot identity PID

[0262] For each BCKi server, i ranging from 1 to m

[0263] HPIDi = Hash(PID) → STORE

[0264] Each BCKi server then generates an HPIDi backup code that it stores in its memory. The HPIDi backup code is at least a function of the PID data forming the user's pivot identity. In one embodiment, the HPIDi backup code is calculated by hashing the pivot identity PID data. In another embodiment, the HPIDi backup code is calculated by hashing the BCKDT backup data, which contains the pivot identity PID data and may contain the additional information mentioned above, such as the date and time of the backup, and a name given by the user to the backup. The hash function is, for example, the SHA256 function ("Secure Hash Algorithm").

[0265] B8.4. Sending BCKi server certificates and encrypted hash code to the orchestrator

[0266] [BCKi → ORC1]

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

[0268] Each BCKi server sends to the ORC1 orchestrator a RETDTi binary string including its CeBi ephemeral certificate, its CBi certificate and the CHi encrypted hash code.

[0269] B8.5. Sending BCKi server certificates and encrypted hash code to the device

[0270] [ORC1 → HW]

[0271] {BCKI D||BCKDT||RETDT1||….||RETDTi||…||RETDTm}ko

[0272] The ORC1 orchestrator returns to the device the BCKID, BCKDT and all RETDTi data received from the BCKi backup servers, in a form encrypted using the key k0. It will be noted here that the orchestrator does not have access to the RETDTi data because it does not know the private keys kBi of the BCKi servers. The data in the secure communication channel between the orchestrator and the device is therefore encrypted twice.

[0273] B8.6. Device decryption of BCKi server certificates and encrypted hash code

[0274] {BCKID||BCKDT||RETDT1|…||RETDTi||…||RETDTm} -1 k0

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

[0276] B8.7. User Validation of BCKDT Data and BCKi Servers

[0277] For each BCKi server, i ranging from 1 to m

[0278] Validate BCKDT, BCKi

[0279] The individual user validates the BCKDT backup data and the BCKi servers responsible for the backup, which are presented to him on the screen of the host device.

[0280] B8.8. Device verification of BCKi server certificates

[0281] For each BCKi server, i ranging from 1 to m

[0282] Verif CeBi, Verif CBi

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

[0284] B8.9. Device generation of kBi session keys and verification of encrypted hash codes

[0285] For each BCKi server, i ranging from 1 to m

[0286] kBi = ECDH(peD, PeBi)

[0287] {Hi} -1 kBi

[0288] Validate Hi

[0289] For each BCKi server, the HW device generates the session key kBi then decrypts the code Hi and validates it by recalculating the code Hi itself and comparing it to the decrypted code.

[0290] B9. Preparing the backup, generating the m parts If

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

[0292] Using the secret sharing function SS, the HW device generates the m shares Si to be saved in the different servers BCK1, BCK2… BCKm, with a threshold of n shares to recover the seed S.

[0293] In a variant B9' of step B9, step B9' first comprises the encryption of the seed S using a seed encryption key Kseed and an encryption function Fseed, before generating the m parts Si to be saved in the different servers BCK1, BCK2… BCKm. The function Fseed is for example the AES 256 encryption, i.e. a symmetric encryption, the seed encryption key Kseed also forming a decryption key.

[0294] Step B9' in this case includes the following steps:

[0295] S=Fseed(S) Kseed

[0296] Then :

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

[0298] Thus, the Si shares are generated here from the encrypted seed using the Fseed function and the Kseed key.

[0299] In yet another variant B9' of step B9, the m shares Si, after being generated, are individually encrypted using the seed encryption key Kseed. This encryption of the shares Si of the seed can be, as before, an AES 256 encryption. Step B9' in this case comprises the following steps:

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

[0301] Then :

[0302] S1 = Fseed(S1) Kseed

[0303] S2 = Fseed(S2) Kseed

[0304] …

[0305] If = Fseed(If) Kseed

[0306] …

[0307] Sm = Fseed(Sm) Kseed

[0308] For the sake of simplicity, the following steps will use the same "If" notation to designate the shares, whether they are generated from the unencrypted seed or from the seed encrypted using the seed encryption key, or whether they have been encrypted after being generated.

[0309] Other variants of step B9 may be provided, in particular a combination of the two variants B9' and B9' which have just been described, or a variant in which only part of the shares Si is the subject of the encryption step using the key Kseed.

[0310] In one embodiment, the Kseed seed encryption key is stored in a non-volatile memory of the HW hardware wallet, for example the one containing the device's operating system. This storage may be done when customizing the device, before it is marketed, or during a firmware update.

[0311] In one embodiment, the Kseed seed encryption key is common to a plurality of HW hardware wallets. The key may be known only to the manufacturer of the HW hardware wallets, so there is no need for the user to store it anywhere.

[0312] In another embodiment, 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 the hardware wallet.

[0313] B10. Encryption of shares If by the device ()

[0314] For each BCKi server, i ranging from 1 to m

[0315] {Si}kBi

[0316] For each BCKi server, the HW device encrypts the share Si intended for it with its own key kBi. This is an encryption of the shares Si using the session keys kBi specific to each BCKi server, i.e. a communication channel encryption, which should be distinguished from encryption using the seed encryption key Kseed which was proposed above as an option. Thus, if this option is chosen, the shares Si, before being encrypted using the session keys kBi, may have been previously encrypted using the seed encryption key Kseed or come from a seed having been previously encrypted with the seed encryption key Kseed.

[0317] B11. Sending the encrypted shares to the orchestrator

[0318] [HW → ORC1]

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

[0320] The HW device then sends all the shares to the orchestrator ORC1. It will be noted that the orchestrator does not know the value of each share Si because it is encrypted with the key kBi which it does not know.

[0321] B12. Sending encrypted Si shares to BCKi servers

[0322] [ORC1 → BCKi]

[0323] For each BCKi server, i ranging from 1 to m

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

[0325] The ORC1 orchestrator sends to each BCKi server the encrypted Si share intended for it, accompanied by the backup identifier.

[0326] B13.1. Decryption and recording by each BCKi server from Si.

[0327] For each BCKi server, i ranging from 1 to m

[0328] {If} -1 kBi → STORE

[0329] Each BCKi server decrypts the Si share it received.

[0330] B13.2.a. Backup by each BCKi server of the Si share in such a way that it is linked to the user's identity

[0331] For each BCKi server, i ranging from 1 to m

[0332] LNKSi = {Si||HPIDi} pBi → STORE

[0333] During this step, each BCKi server concatenates the part Si and the backup code HPIDi depending on the pivot identity of the user, as calculated in step B8.3.2, then encrypts the binary string thus obtained using a secret key known only to it, for example its private key pBi, and a cryptographic function. The data LNKSi resulting from this calculation forms an encrypted data linking the part Si and the pivot identity PID of the user and will be referred to as “encrypted link data” in the following. The encrypted link data LNKSi is then stored in the memory MEM of each BCKi server. Thus, the Si part, as saved in the memory of each BCKI server, is linked to the user's pivot identity PID by the fact that it has been concatenated with the HPIDi backup code which is a function of the pivot identity PID, before being encrypted to form the encrypted link data LNKSi.

[0334] B13.2.b. Backup by each BCKi server of the Si share in such a way that it is linked to the user's identity

[0335] For each BCKi server, i ranging from 1 to m

[0336] KIDi= FDERIV(pBi, HPIDi)

[0337] LNKSi= {Si} KIDi → STORE

[0338] This step is a variant of step B13.2.a, which can therefore be executed instead of the latter by each server or by only some servers. During this step, each BCKi server configured to implement this variant calculates a secret key KIDi by deriving its private key pBi using as derivation diversifier the backup code HPIDi which is a function of the pivot identity of the user.

[0339] Once the KIDi key has been calculated, each BCKi server encrypts the part Si that it has received using this key. The encrypted link data LNKSi resulting from this encryption step is then stored in the memory MEM of each BCKi server. Thus, in this variant, the part Si as saved in the memory of each BCKI server is linked to the pivot identity of PID the user by the fact that it is encrypted using a KIDi key that is a function of this pivot identity.

[0340] The FDERIV derivation function is for example the HKDF function which is a simple key derivation function (KDF) based on the HMAC message authentication code. The resulting KIDi key is therefore a function of the pivot identity. To implement the HKDF function, the private key pBi is used as the "IKM" ("Input Key Material") parameter and the HPIDi backup code as the "INFO" field. The "info" field has no predefined size and can therefore contain the identity as a whole, or the "hash" of this identity.

[0341] B13.2.c. Backup by each BCKi server of the Si share in such a way that it is linked to the user's identity

[0342] In a variant B13.2.c of step B13.2.b, each server or only some servers derive(s) the KIDi key directly from the PID data of the pivot identity, without going through the backup code, i.e.:

[0343] KIDi= FDERIV(pBi, PID)

[0344] B13.2.d. Backup by each BCKi server of the part Si in such a way that it is linked to the identity of the user

[0345] For each BCKi server, i ranging from 1 to m

[0346] LNKSi = Hash(Si||HPIDi) → STORE

[0347] EncSi = {Si}pBi → STORE

[0348] This step is still a variant of step B13.2.a, which can therefore be executed instead of the latter by each server or by certain servers only. During this step, each BCKi server configured to implement this variant concatenates Si and HPIDi then hashes the resulting binary string to obtain the encrypted link data LNKSi. This data cannot be recalculated without having access to the unencrypted part Si. It therefore cannot be recalculated by a fraudster from outside the system. Once the encrypted link data LNKSi has been calculated, each BCKi server encrypts the part Si that it has received using a private key known only to it, for example pBi, to obtain an encrypted part EncSi. The encrypted part EncSi and the corresponding encrypted link data LNKSi are then stored in the MEM memory of each BCKi server.

[0349] B13.2.e. Backup by each BCKi server of the Si share in such a way that it is linked to the user's identity

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

[0351] EncSi = {Si}pBi

[0352] LNKSi= HMAC(pBi, EncSi||HPIDi) → STORE

[0353] EncSi → STORE

[0354] This step is still a variant of step B13.2.a, which can therefore be executed instead of the latter by all or some of the backup servers. During this step, each BCKi server configured to implement this variant encrypts the part Si that it has received using a private key known only to it, for example its private key pBi, to obtain an encrypted part EncSi. Each BCKi server then calculates an encrypted link data LNKSi by concatenation of the encrypted data EncSi and the backup code HPIDi and then signs the binary string obtained using a cryptographic hash function of the HMAC type, for example the HMAC-SHA256 algorithm, using a private key known only to it, for example its private key pBi. The encrypted part EncSi and the corresponding encrypted link data LNKSi are then stored in the memory MEM of each BCKi server.

[0355] B14. Confirmation of backup to the orchestrator by each BCKi server

[0356] [BCKi → ORC1] OKi

[0357] Each BCKi server confirms to the ORC1 orchestrator with an "OKi" message (i ranging from 1 to m) that it has decrypted and stored the share of the seed entrusted to it. Optionally, each BCKi server can send an encrypted proof of the decryption of the share Si using a hash code signed with its session key. This signed hash code will be passed back to the HW device for verification.

[0358] B15. Confirmation of backup to the user

[0359] [ORC1 → HW]

[0360] OK

[0361] The ORC1 orchestrator returns a backup success message (“OK”) to the HW device, which displays a backup confirmation message on its screen for the user.

[0362] At the end of the process:

[0363] - the HW device still holds the seed S,

[0364] - the HSW companion software records the backup identifier BCKID,

[0365] - the orchestrator ORC1 does not hold the seed S nor the data of the backup BCKDT, and only holds the backup identifier BCKID,

[0366] - each BCKi server holds in its MEM memory the backup identifier BCKID, the backup data BCKDT which contains at least the PID data of the user's pivot identity, the encrypted link data LNKSi and the part Si of the seed which has been entrusted to it and has been linked to the pivot identity of the legitimate user thanks to the encrypted link data LNKSi.

[0367] The HSW companion software stores the backup ID BCKID and can also update the user's UACC client account with the backup ID BCKID.

[0368] As will become clear in the following, the provision of the encrypted link data linking the share Si to the identity of its initial legitimate holder makes the link between the share Si and the pivot identity PID of the legitimate user unalterable and unattackable. This method makes it possible to counter a subsequent attack which would consist of dissociating each share Si from the BCKDT data with which it is associated, which contains the identity data PID of the initial legitimate user, to associate it with other BCKDT data containing identity data PID of an illegitimate user. Such an attack by "exchanging links" between shares Si and BCKDT data could for example consist of an attack on a database in which such links are listed.

[0369] If each Si share of the seed is saved in an encrypted form linked to the PID data of the legitimate user's pivot identity, the BCKDT backup data could, in some embodiments, not include the PID data. Although it would be more convenient to include the PID data in the BCKDT data to retrieve the Si shares in the BCKi servers from information about the identity of their owners, the BCKDT data could be reduced to other types of information, for example, the backup name and / or the backup date, provided that the legitimate user can remember them at the time they wish to retrieve the Si shares.

[0370] In other embodiments where, on the contrary, the data of the BCKDT backup systematically includes the PID data of the pivot identity, step B8.3.2 of generating the HPIDi backup code can be carried out from the BCKDT data instead of being carried out from the PID data. In this case, step B8.3.2 is written as follows:

[0371] For each BCKi server, i ranging from 1 to m

[0372] HPIDi = Hash(BCKDT) = Hash(PID||ODT) → STORE

[0373] An example of a seed restoration algorithm applicable to the system of laet implementing various aspects of the previously described embodiments of the method will now be described in relation to Figures 5A, 5B, 5C. Laest is a sequence diagram which represents the steps of the algorithm described by Figures 5A, 5B in the form of interactions between the previously cited entities.

[0374] Here we assume that the user has lost his HW device, or has irrecoverably lost the password that allows him to use it. He obtains a new HW device that he will use to recover the seed S, and connects it to the HDV host device whose HSW companion software has memorized the backup identifier BCKID. The new HW device could also be the HW device that was reset.

[0375] At the beginning of the process, the HW' device holds a private key pD, a public key PD, a certificate CD certified by the CA, and the public key PL of the CA (the same designation as before will be used for the keys and certificates of the HW' device). The restoration step includes the steps described below. Steps similar to those previously described will not be commented on again.

[0376] R1. Sending a restoration request to the orchestrator by the device

[0377] HW' → ORC1

[0378] RESTRQ[BCKID]

[0379] The restoration is initiated by the HW' device sending a RESTRQ restore request to the orchestrator. The request contains the backup identifier BCKID. It is issued at the user's request and selected through a menu displayed on the HW' device screen or on the HDV host device screen.

[0380] R2. Mutual authentication and creation of a secure channel between the orchestrator and the device

[0381] R2.1. Generation by the orchestrator of an ephemeral certificate

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

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

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

[0385] R2.2 Sending the orchestrator's certificates to the device

[0386] ORC1 → HW'

[0387] CeO||CO

[0388] R2.3. Verification by the device of the orchestrator's certificates

[0389] Verif CeO, Verif CO

[0390] R2.4. Device generation of a session key and an encrypted ephemeral certificate

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

[0392] k0 = ECDH(peD, PeO)

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

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

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

[0396] {CD}k0

[0397] R2.5. Sending the HW device certificates to the orchestrator

[0398] [HW' → ORC1]

[0399] CeD||{CD}k0

[0400] R2.6. Generation of the session key k0 by the orchestrator

[0401] k0 = ECDH(peO, PeD)

[0402] CD={CD} -1 k0

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

[0404] R2.7. Verification by the orchestrator of the device certificates

[0405] Verif CeD, Verif CD

[0406] R3. Sending BCKID data and CeD, CD certificates to BCKi servers

[0407] [ORC1 → BCKi]

[0408] For each BCKi server, i ranging from 1 to m

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

[0410] The ORC1 orchestrator sends to each BCKi backup server the backup identifier BCKID, the ephemeral certificate CeD and the CD certificate of the HW device.

[0411] R4. Verification by each BCKi server of the device certificates

[0412] For each BCKi server, i ranging from 1 to m

[0413] Verif CeD, Verif CD

[0414] R5. Mutual authentication and creation of a secure channel between BCKi servers and the device, via the orchestrator

[0415] R5.1. Generation by each BCKi server of an ephemeral certificate

[0416] For each BCKi server, i ranging from 1 to m

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

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

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

[0420] R5.2. Generation of a session key by each BCKi server

[0421] For each BCKi server, i ranging from 1 to m

[0422] kBi = ECDH(peBi, PeD)

[0423] R5.3. Generation by each BCKi server of an encrypted hash code

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

[0425] CHi = {Hi}kBi

[0426] R5.4. Sending to the orchestrator by each BCKi server of its certificate and the encrypted hash code

[0427] [BCKi → ORC1]

[0428] For each BCKi server, i ranging from 1 to m

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

[0430] R5.5. Sending data received from BCKi servers to the device

[0431] [ORC1 → HW']

[0432] {BCKID||BCKDT||RETDT1|…||RETDTi||…||RETDTm}k0

[0433] R5.6. Decryption by the device of the data string received from the orchestrator

[0434] {BCKID||BCKDT||RETDT1|…||RETDTi||…||RETDTm} -1 k0

[0435] R5.7. User validation of backup data

[0436] Validate BCKDT

[0437] The user validates the data from the BCKDT backup, including first name, last name, date of birth, and optionally place of birth.

[0438] R5.8. Device verification of BCKi server certificates

[0439] For each BCKi server, i ranging from 1 to m

[0440] Verif CeBi, Verif CBi

[0441] R5.9. Device generation of session keys kBi and verification of encrypted hash codes CHi

[0442] For each BCKi server, i ranging from 1 to m

[0443] kBi = ECDH(peD, PeBi)

[0444] {Hi} -1 kBi

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

[0446] R6. Preparation of restoration

[0447] R6.1. Sending restoration confirmations to the orchestrator by the device

[0448] [HW'→ ORC1]

[0449] {ConfirmRestore1}kB1||{ConfirmRestore2}kB2||…||{ConfirmRestore i}kBi||…|| {ConfirmRestore m}kBm → ORC1

[0450] The HW device returns to the ORC1 orchestrator for each BCKi server, an individual restore confirmation "ConfirmRestore i » which is encrypted with the kBi key of each BCKi server. Each confirmation is a predefined binary code.

[0451] R6.2. Sending restoration confirmations to BCKi servers

[0452] For each BCKi server, i ranging from 1 to m

[0453] BCKID||{ConfirmRestore i}kBi → BCKi

[0454] The ORC1 orchestrator sends to each BCKi server the concatenated backup identifier BCKID and the restore confirmation {ConfirmRestore i}kBi intended for him.

[0455] R6.3. Verification by BCKi servers of restoration confirmations

[0456] For each BCKi server, i ranging from 1 to m

[0457] {ConfirmRestore i} -1 kBi

[0458] CD Store

[0459] Each BCKi server decrypts the confirmation message sent by the HW' device and communicated to it by the ORC1 orchestrator, and stores the CD certificate of the HW' device that it previously verified.

[0460] R6.4. Confirmation by each BCKi server that restoration can be initiated subject to identity verification

[0461] [BCKi→ ORC1]

[0462] For each BCKi server, i ranging from 1 to m

[0463] OK_for_IDV

[0464] The BCKi server click indicates to the ORC1 orchestrator that it is ready to restore the Si share that it has saved, provided that the user identifies himself through an IDVi step.

[0465] R7.1. Performance of IDVi identity verification steps by IDVSRVi servers

[0466] For each BCKi server, i ranging from 1 to m

[0467] IDVRi

[0468] The user is redirected by the ORC1 orchestrator to each BCKi server and each BCKi server performs its own IDVi verification of the user's pivot identity. In the present embodiment where the IDVi steps are entrusted to service providers, each BCKi server connects the user to the IDVSRVi server to which it is affiliated through a GTW gateway. The service provider's IDVSi service performs a verification of the user's identity, then confirms to the ORC1 orchestrator that its identity has been verified and that the seed backup step can be initiated.

[0469] Please note that each IDVRi identity verification step can take anywhere from a few minutes to several days, depending on the requirements of each BCKi server or the service provider performing the IDVRi. Verifications by individuals may be routinely scheduled with some IDV service providers.

[0470] R7.2. Generation by each BCKi server of a restoration code based on the user's pivot identity PID

[0471] For each BCKi server, i ranging from 1 to m

[0472] IDVi → PID'

[0473] HPIDi' = Hash(PID') → STORE

[0474] Each BCKi server receives a report from the IDV step or the IDVSi service, containing the user's identity and the result of the IDV, allowing it to reconstruct the data of the pivot identity PID. This report is preferably signed by the IDV service. The BCKi server can then validate that the IDV is successful, and that the identity contained in the report corresponds to the saved identity PID.

[0475] Following this verification, each BCKi server validates the PID' data of the user's pivot identity. This data is referred to here as PID' and is assumed to be identical to the PID data used for saving the seed shares, if the user attempting to restore the seed here is not an impersonator. Each BCKi server then generates an HPIDi' restoration code based on the PID' data in the same way that the HPIDi backup code was generated based on the PID data. Thus, for example, the HPIDi' restoration code is calculated by hashing the PID' data, as was done in step B8.3.2 to calculate the HPIDi code based on the PID data. Thus, if the user requesting the restoration of the seed is not an impersonator, the HPIDi' restoration code is equal to the HPIDi backup code. Once calculated, each server stores the HPIDi' restoration code in its MEM memory.

[0476] It will be noted that if step B8.3.2 of generating the HPIDi backup code was conducted from the data of the BCKDT backup containing the PID data of the pivot identity and other ODT data, step R7.2 of generating the HPIDi' restoration code is itself conducted from the data of the BCKDT backup. In this case, step R7.2 is written as follows:

[0477] For each BCKi server, i ranging from 1 to m

[0478] HPIDi' = Hash(BCKDT') → STORE

[0479] with :

[0480] BCKDT' = PID'||ODT

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

[0482] R8. Reestablishment of secure communication channels after completion of IDVi identity verification steps

[0483] [HW' → ORC1]

[0484] Continue Restore

[0485] Once the identity verification step is complete, sometimes several days later, the user restarts the restore step. The HW device sends a "Continue Restore" request to the ORC1 orchestrator to resume the restore.

[0486] Repeat steps R2.1 to R2.7, R3, R5.1 to R5.9 ()

[0487] Since several days may pass during the IDVi verification steps, in one embodiment the previous session certificates are not retained. Thus, steps R2.1 to R2.7, R3, R5.1 to R5.9 are executed again to resume the restoration process where it left off, but with new session keys k0 and kBi.

[0488] R9. Resumption of restoration

[0489] [ORC1 → BCKi]

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

[0491] Continue Restore → BCKi

[0492] Once the secure channels are reopened using new session keys, the orchestrator relays to the BCKi servers the request to continue the restoration. It should be noted that if during the IDVRi steps one of the BCKi servers was unable to verify the user's identity with a determined degree of certainty, it will refuse to return the share it holds and will inform the ORC1 orchestrator. If a determined number of BCKi backup servers 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 shares by the servers that have successfully verified the user's identity. It can optionally decide to subject the user to an additional identity verification procedure.The orchestrator can also be configured to analyze certainty scores regarding user identity verification, as discussed above, and make a decision based on that analysis.

[0493] Furthermore, in a variant of the method mentioned above and in the following in parentheses, this step is limited to n BCKi backup servers, instead of all backup servers, if only n shares are needed to reconstitute the seed, with n less than m.

[0494] R10.1. Verification of the device certificate

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

[0496] Verif CD = CD

[0497] Each BCKi server ensures that the HW device's CD certificate is the same as the CD certificate received before conducting the IDVi identity verification steps, which it has stored.

[0498] R10.2.a. Decryption by each BCKi server of the encrypted link data LNKSi containing the Si part and verification of the user's pivot identity

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

[0500] LNKSi = Si||HPIDi = {Si||HPIDi} pBi -1

[0501] COMPARE {HPIDi', HPIDi}

[0502] During this step, each BCKi server decrypts the LNKSi data stored in its memory to extract the Si share and the HPIDi backup code. The decryption is performed with the same key as that used for the encryption step B13.2.a, here the private key pBi. Each BCKi server then compares the HPIDi' restoration code and the HPIDi backup code. If the user requesting the restoration of the seed is not a usurper, the HPIDi' restoration code is equal to the HPIDi backup code and each BCKi server agrees to return the Si share it holds, otherwise refuses to return it.

[0503] R10.2.b. Decryption by each BCKi server of the encrypted link data LNKSi containing the Si part and verification of the user's pivot identity

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

[0505] KIDi' = FDERIV(pBi, HPIDi')

[0506] If = {LNKSi}KIDi’ -1

[0507] This step is a variant of step R10.2.a and is implemented if variant B13.2.b of step B13.2.a was implemented at the backup stage.

[0508] During this step, each BCKi server concerned by this variant calculates a secret key KIDi' by deriving its private key pBi using as diversifier the restoration code HPIDi' which is a function of the pivot identity PID' of the user. If the user requesting the restoration of the seed is not a usurper, the key KIDi' derived from the private key pBi with diversification by means of the restoration code HPIDi', is identical to the key KIDi derived from the private key pBi with diversification by means of the backup code HPIDi, as calculated in step B13.2', because the codes HPIDi' and HPIDi are identical. The same derivation function as the one used in step B13.2' must of course be used, for example the function HKDF.

[0509] Each BCKi server then decrypts the encrypted LNKSi share stored in its memory using the secret key KIDi' to extract the Si share. If the user requesting the restoration of the seed is a usurper, the KIDi' key will not be the same as the KIDi key used to generate the encrypted LNKSi share. Decryption of the Si share will not be possible or will be erroneous and the BCKi servers will not be able to restore their Si shares.

[0510] R10.2.c. Decryption by each BCKi server of the encrypted link data LNKSi containing the Si part and verification of the user's pivot identity

[0511] In the case where variant B13.2.c of step B13.2.a has been implemented, the restoration code HPIDi' is not calculated and step R7.2 is not performed. Step R10.2.a becomes step R10.2.c which is executed as follows:

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

[0513] KIDi' = FDERIV(pBi, PID')

[0514] If = {LNKSi} KIDi’ -1

[0515] R10.2.d. Decryption by each BCKi server of the Si part, calculation of the encrypted link data and verification of the user's pivot identity

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

[0517] If = {EncIf} pBi -1

[0518] LNKSi' = Hash(Si||HPIDi')

[0519] COMPARE {LNKSi, LNKSi'}

[0520] This step is a variant of step R10.2.a and is implemented if variant B13.2.d of step B13.2.a has been implemented at the backup stage. During this step, each BCKi server concerned by this variant decrypts, using the secret key pBi, the encrypted part EncSi stored in its memory, to extract the part Si. Each BCKi server calculates a new encrypted link data LNKSi' by concatenating the decrypted part Si with the restoration code HPIDi' which is a function of the pivot identity PID' of the user, and by applying the previously used hash function to the resulting binary string.

[0521] Each BCKi server then compares the new encrypted link data LNKSi' from the HPIDi' recovery code with the encrypted link data LNKSi calculated at backup time. If the user requesting seed recovery is not a spoofer, LNKSi' is equal to LNKSi and each BCKi server agrees to return the Si share it holds, otherwise refuses to return it.

[0522] R10.2.e. Decryption by each BCKi server of the Si part, calculation of the encrypted link data and verification of the user's pivot identity

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

[0524] LNKSi' = HMAC(pBi, EncSi||HPIDi')

[0525] COMPARE {LNKSi, LNKSi'}

[0526] If = {EncIf} pBi -1

[0527] This step is a variant of step R10.2.a and is implemented if variant B13.2.e of step B13.2.a was implemented at the backup stage. During this step, each BCKi server concerned by this variant calculates a new encrypted link data by concatenating the encrypted part EncSi with the recovery code HPIDi' which is a function of the pivot identity PID' of the user, then by applying a symmetric signature algorithm to the resulting binary string such as HMAC-SHA256, using for example its secret key pBi.

[0528] Each BCKi server then compares the new encrypted link data LNKSi' from the restoration code HPIDi' and the encrypted link data LNKSi calculated at the time of backup. If the user requesting the restoration of the seed is not a usurper, the encrypted link data LNKSi' is equal to LNKSi and each BCKi server agrees to return the share Si it holds, after having decrypted it using the secret key pBi, otherwise refuses to return it.

[0529] R11. Transfer of shares to the orchestrator by BCKi servers

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

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

[0532] Each BCKi server sends to the ORC1 orchestrator the share Si that it holds, encrypted using its key kBi, which the orchestrator does not know.

[0533] R12. Transfer of shares to the device by the orchestrator

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

[0535] The ORC1 orchestrator sends to the HW' device all the Si shares received from the BCKi servers in encrypted form using the kBi keys.

[0536] R13. Decryption of shares by the device and restoration of the seed

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

[0538] {If} -1 kBi

[0539] S = SS -1 (S1, S2,…Si…Sm)

[0540] (or S = SS -1 (S1, S2,…Si…Sn))

[0541] After decrypting each share of rank i using the corresponding key kBi, the HW' device restores the seed from the received shares, or from a part of them if their number is greater than n.

[0542] In a variant R13' of step R13 corresponding to variant B9' of step B9 described above, the seed S that the device HW' has restored is the original seed encrypted with the seed encryption key Kseed. An additional decryption step using the key Kseed must therefore be provided to restore the seed, using the decryption function Fseed -1 corresponding to the inverse function of the Fseed function:

[0543] S = Fseed -1 (S) Kseed

[0544] In a variant R13' of step R13 corresponding to variant B9' of step B9, each share Si that the HW' device has decrypted has been originally encrypted with the seed encryption key Kseed. Each share Si must therefore be decrypted using the key Kseed after having been decrypted using the session key kBi, before reconstituting the seed, i.e.:

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

[0546] {Fseed -1 (If) Kseed} -1 kBi

[0547] S = SS -1 (S1, S2,…Si…Sm)

[0548] In the embodiment described above in which the seed encryption key is derived from a secret known to the user, steps R13' and R13' include a step of generating the seed encryption key from the user's secret. This generation may optionally involve an encryption key stored in the hardware wallet.

[0549] R14. Final confirmation

[0550] OK → ORC1

[0551] The HW device confirms to the ORC1 orchestrator that the seed restoration is complete.

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

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

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

[0555] Ephemeral certificates could also be of the type:

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

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

[0558] Lamontre a system for implementing the method of the invention which differs from that of laen that the ORCSRV1 server is replaced by an ORCSRV2 server which executes an ORC2 orchestrator program (hereinafter "ORC2 orchestrator"). The OCR2 orchestrator differs from the ORC1 orchestrator in that it does not ensure the transmission to the HW device of the data emitted by the BCKi backup servers, and vice versa, and therefore does not act as a gateway or "proxy server".

[0559] When the user initiates a seed backup step, the HW device sends a backup request BCKRQ to the OCR2 orchestrator, following which the ORC2 orchestrator initiates the previously described steps of generating a backup identifier BCKID and collecting information about the user to generate the backup data BCKDT. The orchestrator also conducts the initial step IDV0 of verifying the user's identity. If this step is successful, the orchestrator issues backup authorizations BCKPASSi to the HW device, one authorization per backup server BCKi, and sends each authorization to the BCKi server concerned.

[0560] Each BCKPASSi authorization forms a kind of "passport" allowing the HW device to know which BCKi server it should contact to back up a Si share of the seed, and allowing it to connect to the BCKi server to perform the backup without being rejected by the latter. Each BCKPASSi authorization can include various information, including the information previously contained in the BCKDT backup data and the BCKID identifier. The BCKPASSi authorizations are stored by the companion software and, preferably, in the UACC user account on the UASRV account server. Alternatively, the orchestrator issues a general BCKPASS authorization containing a concatenation of all the information contained in the BCKPASSi authorizations.

[0561] With reference to the, when the user wants to restore the seed, the companion software connects to the BCKi backup servers that it identifies by means of the addresses contained in the BCKPASSi authorizations, then passes the hand to the HW device so that it establishes secure channels with the BCKi backup servers, by key exchanges as described above. When the secure channels have been created, the BCKi backup servers initiate the IDVi steps of verifying the pivot identity of the user.

[0562] The role of supervisor of the IDVi steps that was previously assigned to the ORC1 orchestrator can also be assigned here to the ORC2 orchestrator. The latter is then requested by the BCKi backup servers to analyze the results of the IDVi steps. If these results are conclusive, the ORC2 orchestrator delivers RESTPASSi restoration authorizations to the HW device, which it also communicates to the BCKi backup servers. The HW device then reestablishes a secure channel with the BCKi backup servers and presents them with the RESTPASSi authorizations to recover the Si shares of the seed.

[0563] In the ultimate case where the user has closed his account on the UASRV account server, uninstalled the companion software by erasing the data it contained, and could therefore no longer recover the BCKPASSi authorizations, as well as in the equally ultimate case where the ORC2 orchestrator no longer exists, a solution can be provided to allow the user to recover his seed, by allowing him to carry out a plurality of individual steps to verify his identity with each BCKi backup server.

[0564] In a variant of the method for facilitating the recovery of shares in the event of a total system failure, or loss of the BCKID identifier (embodiment figures 3A, 3B) or the BCKPASSi authorizations, it may be provided that the organization in charge of the ORC1 or ORC2 orchestrator delivers to the user, for example by post, a backup certificate bearing a tamper-evident certificate of authenticity such as a hologram. Such a backup certificate will not spare the user the steps of verifying his identity with the backup servers, but will include sufficient information to provide an additional degree of certainty as to his status as the legitimate holder of the seed when the IDVi verification steps are carried out.

[0565] Lamontre an example of an embodiment of a hardware wallet HW allowing the implementation of the method. The HW device comprises a secure element SE1, a microcontroller MCU1 and a touch screen TS1 ("Touch Screen"). The touch screen TS1 comprises an electronic ink display EID ("E-Ink Display") and a touch module TM ("Touch Module"). The touch screen TS1 is under the control of the secure element SE1. For this purpose, the resources in terms of inputs / outputs of the secure element SE1 are divided into three groups of inputs / outputs IOGA, IOGB, IOGC. The group of inputs / outputs IOGA is assigned to the implementation of a bus BS1 connecting the secure element SE1 to the microcontroller MCU1. The IOGB input / output group is assigned to the implementation of a BS2 bus connecting the SE1 secure element to the EID display, and the IOGC input / output group is assigned to the implementation of a BS3 bus connecting the SE1 secure element to the TM touch module.The BS1 bus is for example an IEC / ISO 7816 bus, the BS2 bus is for example an SPI bus and the BS3 bus is an I2C bus. The secure element is for example an STMicroelectronics® chip of the ST33K series. The HW device also includes various peripherals controlled by the MCU1 microcontroller, for example:.

[0566] - a BAT battery;

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

[0568] - a QiA antenna for inductive battery charging. The QiA antenna is connected to a WCIC (“Wireless Charging Integrated Circuit”) wireless charging integrated circuit. The WCIC circuit provides a Vqi voltage to the PMIC circuit for battery charging;

[0569] - a USB port U1. The USB port provides the PMIC circuit with a Vusb voltage for battery charging, provides the MCU1 microcontroller with DTu data received from an external device connected to the USB port, and transmits DTu data to the external device;

[0570] - a Bluetooth antenna BTA, receiving a radio frequency signal RFS provided by a BTM circuit for managing Bluetooth communications. The BTM circuit provides DTb data exchanged with an external device via a Bluetooth link or transmits DTb data to the external device via the Bluetooth link.

[0571] The HW device has the advantage of having a touch screen exclusively controlled by the secure element SE1 and therefore not susceptible to corruption, including in the event of an attack on the MCU1 microcontroller. The latter does not execute any application program and does not store any of the cryptographic secrets used by the secure element. It only manages the peripherals by transmitting to the secure element the DTb, DTu data received via the communication interface chosen by the user, or by transmitting to the external device DTb, DTu data provided by the secure element. The HW device therefore does not offer any possibility of direct connection to the Internet and remains, despite its touch screen, a hardware wallet for cold storage of private keys offering the highest level of security.The secure element SE1 also comprises a memory space MS1 comprising 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 an operating system of the secure element. The latter is configured to allow the implementation of the method of the invention.

[0572] The HW device is well suited to implementing the method thanks to its touch screen, which can be chosen to be large and have, for example, a diagonal greater than or equal to 3.5 inches (one inch being equal to 2.54 cm), and comprise at least 600 x 400 pixels. In one embodiment, the screen has a diagonal of 3.9 inches (9.906 cm) and offers 670 x 496 pixels, which constitutes a very large screen for a cryptoasset hardware wallet without Internet connectivity.

[0573] The method just described can also be implemented with various other types of cryptoasset wallets. The method can in particular be implemented with a CW2 cryptoasset wallet of the type shown in the. The CW2 cryptoasset wallet comprises a secure microcontroller SMCU, a screen TS2 which can be touch-sensitive, communication interface circuits CINT1 including in particular Wi-Fi and / or Ethernet connectivity and allowing it to connect to the Internet. The secure microcontroller uses two virtual processors associated with hardware access control, making it possible to manage two zones TZ, NTZ for executing applications offering different degrees of security, the zone TZ being called the "Trust Zone".The secure microcontroller may, in some embodiments, be equipped with a secure element SE2 coupled to the trusted zone TZ to perform cryptographic calculations and conduct the most security-sensitive operations, including storing the seed and various keys of cryptoasset accounts. Each zone can operate independently of the other while using the same kernel. Typically, the microcontroller runs a so-called "rich" operating system in the less trusted zone NTZ, for example Android, and specialized code in the trusted zone TZ. Such a device is equivalent to the combination of the hardware wallet HW (equivalent to the trusted zone) and the host device HDV (equivalent to the less secure zone) described above, and does not need to be connected to a host device to execute operations on the blockchain.

[0574] The method of the invention can also be implemented with a software-type cryptoasset wallet. Unlike an online wallet, a software wallet allows cryptoasset keys to be stored directly on a desktop computer, laptop, mobile phone or equivalent. The user retains ownership of his keys and the seed, and must secure their storage himself by ensuring that a fraudster cannot seize them. As an example, the shows a software-type cryptoasset wallet CW3 executed by an electronic device DV which can be of the aforementioned type, computer, mobile phone or equivalent. The device DV comprises a microprocessor MPU equipped with a communication interface CINT2 allowing it to connect to the Internet, a volatile memory RAM and a non-volatile memory NVM, for example a magnetic hard disk or a solid-state hard disk (SSD).The CW3 program forming the software cryptoasset wallet is stored in the non-volatile memory NVM of the DV device and is executed by the MPU microprocessor using its RAM memory.

Claims

Method for backing up and restoring a secret (S) held by a secure electronic device (CW1, CW2, CW3, HW, HDV), comprising a step of backing up the secret comprising the steps of:- providing a plurality of backup servers (BCKi),- collecting (B3) data (BCKDT, PID) defining the identity of a first user, and communicating them (B6) to each backup server,- by means of the secure electronic device, generating a plurality of secret shares (Si) from the secret (S),- transferring (B11, B12) to each backup server one of the secret shares (Si), and- in each backup server:- generating (B13.2.a, B13.2.b, B13.2.c, B13.2.d, B13.2.e) an encrypted link data item (LNKSi) which is a function of the secret share (Si) and the data (BCKDT, PID) defining the identity of the first user, and- store the encrypted link data in a memory (MEM) of the backup server. Method according to claim 1, wherein in at least one backup server the step (B13.2.a) of generating the encrypted link data (LNKSi) comprises the steps of:- generating (B8.3.2) a backup code (BCKDT, PID, HPIDi) depending on the identity of the first user,- combining the secret part (Si) and the backup code, and- encrypting the combination of the secret part and the backup code using a secret key (pBi) of the backup server. Method according to one of claims 1 and 2, wherein in at least one backup server the step (B13.2.b, B13.2.c) of generating the encrypted link data (LNKSi) comprises the steps of:- generating a backup code (BCKDT, PID, HPIDi) depending on the identity of the first user,- applying a key derivation function (FDERIV) to a secret key (pBi) of the backup server, using the backup code as a derivation diversifier, to obtain a first derived key (KIDi) depending on the data (BCKDT, PID) defining the identity of the first user, and- encrypting the secret part (Si) using the first derived key (KIDi). Method according to one of claims 1 to 3, wherein in at least one backup server the step (B13.2.d) of generating the encrypted link data (LNKSi) comprises the steps of:- generating a backup code (BCKDT, PID, HPIDi) depending on the identity of the first user,- combining the secret part (Si) and the backup code, and- hashing the combination of the secret part and the backup code to obtain the encrypted link data (LNKSi), the method further comprising steps of encrypting the secret part (Si) using a secret key (pBi) of the backup server and storing the encrypted secret part (EncSi) in the memory (MEM) of the backup server. Method according to one of claims 1 to 4, wherein in at least one backup server the step (B13.2.e) of generating the encrypted link data (LNKSi) comprises the steps of:- encrypting the secret part (Si) using a secret key (pBi) of the backup server,- generating a backup code (BCKDT, PID, HPIDi) depending on the identity of the first user,- combining the encrypted secret part (EncSi) and the backup code, and- encrypting the combination of the encrypted secret part and the backup code using a secret key (pBi) of the backup server and a cryptographic hash function (HMAC),the method further comprising a step of storing the encrypted secret part (EncSi) in the memory (MEM) of the backup server. Method according to one of claims 2 to 5, in which the step of generating the backup code (BCKDT, PID, HPIDi) comprises a step of concatenating data defining a pivot identity of the user. Method according to one of claims 2 to 5, in which the step of generating the backup code (HPIDi) comprises a step of concatenating data defining a pivot identity of the user, and a step of hashing (B8.3.2) the concatenated pivot identity data. Method according to claim 1, comprising a step of restoring the secret (S) comprising the steps of:- collecting (R7.1) data (BCKDT', PID') defining the identity of a second user, verifying their validity with the participation of the second user, and providing them to at least one backup server, and- by ​​means of the backup server, verifying, by means of the encrypted link data (LNKSi), that the identity of the second user is the same as the identity of the first user. Method according to claim 8, in which the step of verifying the identity of the second user comprises at least one of the following operations:- decrypting (R10.2.a) the encrypted link data, extracting therefrom the identity of the first user or a data item (HPIDi) depending on his identity, and comparing it to the identity of the second user or to a data item (HPIDi') depending on the identity of the second user,- decrypting (R10.2.b, R10.2.c) the encrypted link data using a key (KIDi') depending on the identity of the second user,- calculating (R10.2.d, R10.2.e) a new encrypted link data item (LNKSi') from the identity of the second user and comparing it to the initial encrypted link data item (LNKSi). Method according to claim 2, comprising a step of restoring the secret (S) comprising the steps of:- collecting (R7.1) data (BCKDT', PID') defining the identity of a second user, verifying their validity with the participation of the second user, and providing them to at least one backup server, and- by ​​means of the backup server:- generating (R7.2) a restoration code (BCKDT', PID', HPIDi') depending on the identity of the second user,- decrypting (R10.2.a) the encrypted link data (LNKSi) by means of the secret key (pBi) of the backup server and extracting the backup code (BCKDT, PID, HPIDi),- comparing the restoration code (BCKDT', PID', HPIDi') and the backup code (BCKDT, PID, HPIDi), and- restoring the secret part (Si) present in the encrypted link data (LNKSi) if the two codes are identical, and refuse to return it if the two codes are not identical. Method according to claim 3, comprising a step of restoring the secret comprising the steps of:- collecting (R7.1) data (BCKDT', PID') defining the identity of a second user, verifying their validity with the participation of the second user, and providing them to at least one backup server, and- by ​​means of the backup server:- generating (R7.2) a restoration code (BCKDT', PID', HPIDi') depending on the identity of the second user,- applying (R10.2.b, R10.2.c) the function (FDERIV) of key derivation to the secret key (pBi) of the backup server using as derivation diversifier the restoration code (BCKDT', PID', HPIDi'), to obtain a second derived key (KIDi') function of the data (BCKDT', PID') defining the identity of the second user, and- if the first and second derived keys are identical, decrypting the encrypted link data (LNKSi) by means of the second derived key (KIDi') and extracting the secret part (Si) therefrom. Method according to claim 4, comprising a step of restoring the secret comprising the steps of:- collecting (R7.1) data (BCKDT', PID') defining the identity of a second user, verifying their validity with the participation of the second user, and providing them to at least one backup server, and- by ​​means of the backup server,- generating (R7.2) a restoration code (BCKDT', PID', HPIDi') depending on the identity of the second user,- decrypting the secret part (Si) by means of the secret key of the backup server,- combining (R10.2.d) the secret part and the restoration code, and hash the combination of the secret part and the restoration code to obtain a new encrypted link data (LNKSi'),- compare the new encrypted link data (LNKSi') and the encrypted link data (LNKSi), and- restore the secret part (Si) if the new encrypted link data (LNKSi') and the encrypted link data (LNKSi) are identical, otherwise refuse to restore the secret part (Si). Method according to claim 5, comprising a step of restoring the secret comprising the steps of:- collecting (R7.1) data (BCKDT', PID') defining the identity of a second user, verifying their validity with the participation of the second user, and providing them to at least one backup server, and- by ​​means of the backup server,- generating (R7.2) a restoration code (BCKDT', PID', HPIDi') depending on the identity of the second user,- combining (R10.2.e) the secret part and the recovery code, and encrypt the combination of the secret part and the recovery code using the secret key (pBi) of the backup server and the cryptographic hash function (HMAC), to obtain a new encrypted link data (LNKSi'),- compare the new encrypted link data (LNKSi') and the encrypted link data (LNKSi),- decrypt and restore the secret part (Si) if the new encrypted link data (LNKSi') and the encrypted link data (LNKSi) are identical, otherwise refuse to restore the secret part (Si). Method according to one of claims 10 to 13, in which the step of generating the restoration code (BCKDT', PID', HPIDi') comprises a step of concatenating data defining a pivot identity of the user. Method according to one of claims 10 to 13, in which the step of generating the restoration code (HPIDi') comprises a step of concatenating data defining a pivot identity of the user, and a step of hashing (B8.3.2) the concatenated pivot identity data. Method according to one of claims 1 to 15, in which the identity of a user is defined by at least a first name, a last name and a date of birth of the user. Method according to one of claims 1 to 16, in which the secure electronic device is configured to generate a plurality of secret shares (Si) by means of a secret sharing function (SS) provided to generate a number m of secret shares from the secret (S) and allow the reconstitution of the secret (S) from a threshold of n secret shares (Si). Method according to claim 17, wherein the secure electronic device (CW1) comprises a hardware wallet (HW) of cryptoasset accounts without means of connection to the Internet connected or configured to be connected to a host device (HDV) running companion software (HSW) and provided with a connection to the Internet. Server for saving and restoring secret data (Si), configured to, in response to a request to save the secret data:- receive the secret data (Si),- receive data (BCKDT, PID) defining the identity of a first user,- generate (B13.2.a, B13.2.b, B13.2.c, B13.2.d, B13.2.e) an encrypted link data (LNKSi) which is a function of the secret data (Si) and the data (BCKDT, PID) defining the identity of the first user, and- store the encrypted link data in a memory (MEM) of the server. Server according to claim 19, configured to generate the encrypted link data (LNKSi) by performing the steps of:- generating (B8.3.2) a backup code (BCKDT, PID, HPIDi) depending on the identity of the first user,- combining the secret data (Si) and the backup code, and- encrypting the combination of the secret data and the backup code using a secret key (pBi) of the server. Server according to claim 19, configured to generate the encrypted link data (LNKSi) by performing the steps of:- generating a backup code (BCKDT, PID, HPIDi) depending on the identity of the first user,- applying a key derivation function (FDERIV) to a secret key (pBi) of the server using the backup code as a derivation diversifier, to obtain a first derived key (KIDi) depending on the data (BCKDT, PID) defining the identity of the first user, and- encrypting the secret data (Si) using the first derived key (KIDi). Server according to claim 19, configured to generate the encrypted link data (LNKSi) by performing the steps of:- generating a backup code (BCKDT, PID, HPIDi) depending on the identity of the first user,- combining the secret data (Si) and the backup code, and- hashing the combination of the secret data and the backup code, the server also being configured to encrypt the secret data (Si) using a secret key (pBi) of the server and storing the encrypted secret data (EncSi) in the memory (MEM) of the server. Server according to claim 19, configured to generate the encrypted link data (LNKSi) by performing the steps of:- encrypting the secret data (Si) using a secret key (pBi) of the server,- generating a backup code (BCKDT, PID, HPIDi) depending on the identity of the first user,- combining the encrypted secret data (EncSi) and the backup code, and- encrypting the combination of the encrypted secret data and the backup code using a secret key (pBi) of the server and a cryptographic hash function (HMAC),the server being further configured to store the encrypted secret data (EncSi) in the memory (MEM) of the server. Server according to one of claims 20 to 23, configured to include in the step of generating the backup code (BCKDT, PID, HPIDi) a step of concatenating data defining a pivot identity of the user. Server according to one of claims 20 to 23, configured to include in the step of generating the backup code (HPIDi) a step of concatenating data defining a pivot identity of the user, and a step of hashing (B8.3.2) the concatenated pivot identity data. Server according to claim 20, configured to, in response to a request for restitution of the secret data (Si):- collect (R7.1) data (BCKDT', PID') defining the identity of a second user,- generate (R7.2) a restoration code (BCKDT', PID', HPIDi') depending on the identity of the second user,- decrypt (R10.2.a) the encrypted link data (LNKSi) and extract the backup code (BCKDT, PID, HPIDi),- compare the restoration code (BCKDT', PID', HPIDi') and the backup code (BCKDT, PID, HPIDi), and- restore the secret data (Si) present in the encrypted link data (LNKSi) if the two codes are identical, and refuse to restore it if the two codes are not identical. Server according to claim 21, configured to, in response to a request for restitution of the secret data (Si):- collect (R7.1) data (BCKDT', PID') defining the identity of a second user,- generate (R7.2) a restoration code (BCKDT', PID', HPIDi') depending on the identity of the second user,- apply (R10.2.b, R10.2.c) the key derivation function (FDERIV) to the secret key (pBi) of the server using as derivation diversifier the restoration code (BCKDT', PID', HPIDi'), to obtain a second derived key (KIDi') depending on the data (BCKDT', PID') defining the identity of the second user, and- if the first and second derived keys are identical, decrypt the encrypted link data (LNKSi) by means of the second derived key (KIDi') and extract the data therefrom secret (Yes). Server according to claim 22, configured to, in response to a request for restitution of the secret data (Si):- collect (R7.1) data (BCKDT', PID') defining the identity of a second user,- generate (R7.2) a restoration code (BCKDT', PID', HPIDi') depending on the identity of the second user,- decrypt the secret data (Si) using the server's secret key,- combine (R10.2.d) the secret data and the restoration code, hash the combination of the secret data and the restoration code to obtain a new encrypted link data (LNKSi'),- compare the new encrypted link data (LNKSi') and the encrypted link data (LNKSi), and- restore the secret data (Si) if the new encrypted link data (LNKSi') and the encrypted link data (LNKSi) are identical, otherwise refuse to restore the secret data (If). Server according to claim 23, configured to, in response to a request for restitution of the secret data (Si):- collect (R7.1) data (BCKDT', PID') defining the identity of a second user,- generate (R7.2) a restoration code (BCKDT', PID', HPIDi') depending on the identity of the second user,- combine (R10.2.e) the secret data and the restoration code, and encrypt the combination of the secret data and the restoration code by means of the secret key (pBi) of the server and the cryptographic hash function (HMAC), to obtain a new encrypted link data (LNKSi'),- compare the new encrypted link data (LNKSi') and the encrypted link data (LNKSi),- decrypt and restore the secret data (Si) if the new encrypted link data (LNKSi') and the encrypted link data (LNKSi) are identical, otherwise refuse to return the secret data (If). Server according to one of claims 26 to 29, configured to generate the restoration code (BCKDT', PID', HPIDi') by concatenation of data defining a pivot identity of the user. Server according to one of claims 26 to 29, configured to generate the restoration code (HPIDi') comprising a step of concatenating data defining a pivot identity of the user, and a step of hashing (B8.3.2) the concatenated pivot identity data.

Images