A method for linking the safeguarding of a secret to a person's identity

Abstract

A method for backing up and restoring a secret held by a secure electronic device, comprising a step of backing up the secret including the steps of providing a plurality of backup servers (BCKi), collecting data (PID) 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 parts (Si) from the secret, 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 data (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 data in a memory of the backup server. Figure for the abstract: Fig. 4B

Description

Title of the invention: Method for linking the safeguarding of a secret to the identity of a person. Technical field

[0001] The present invention relates to a method for backing up and restoring a secret held by a secure electronic device. The present invention relates in particular 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", appeared, allowing the storage and preservation of these keys. A cryptoasset wallet is a hardware or software device whose function is to store the private and public keys attached to cryptoasset accounts, and to sign transactions using these keys. A 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 therefore themselves susceptible to attack. "Cold" wallets 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 means. 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 communicated to online servers during the signing process, a hacker cannot access them.

[0003] Such a type of hardware wallet is therefore today considered the solution The most secure 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 crypto-asset 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 in his wallet being sufficient. This solution is today used by the vast majority of software or hardware crypto-asset wallets.

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

[0006] 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 which consists of 24 words chosen from a list of 2048 words defined by the aforementioned standard.

[0007] For recovery phrase generation, 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] [Fig.l] schematically 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 HDV host device to carry out transactions on the blockchain. The HDV host device is for example a computer, a mobile phone, a tablet or equivalent. The connection between the HW device and the HDV host device can be USB or Bluetooth 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 for generating, storing and protecting cryptographic keys. The HSM module does not store any private key of the user and only ensures the control of 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 that the user must keep on an appropriate 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] Such safekeeping of the recovery phrase is not without risk. Indeed, if a third party obtains the recovery phrase, the third party will be able to access all of the user's crypto-asset accounts generated from the seed and transfer the amounts they contain to other accounts, and it will then be 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 desired that the safeguarding of a secret be linked to the identity of a person in a way that can resist an attack by a fraudster aiming 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, generate an encrypted link data which is a function of the secret share and the data defining the identity of the first user, and store 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 depending 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 depending 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, verify their validity with the participation of the second user, and provide them to at least one backup server, and by means of the backup server, verify, 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 that is a function of his identity, and comparing it to the identity of the second user or to data that is a function of the identity of the second user; decrypting the encrypted link data using a key that is a function of 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 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. reader, decrypt the secret share using the secret key of the backup server, combine the secret share and the recovery code, and hash the combination of the secret share and the recovery code to obtain a new encrypted link data, compare the new encrypted link data and the encrypted link data, and restore the secret share if the new encrypted link data and the encrypted link data are identical, otherwise refuse to restore the secret share.

[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 means of connection 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 which is a function of the secret data and the data defining the identity of the first user reader, and store the encrypted link data in a server memory.

[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 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, decrypt the encrypted link data and extract therefrom the backup code, 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 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, 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 restore the secret data if the new encrypted link data and the encrypted link data are identical, otherwise refuse to restore 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. Brief 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 [Fig.l] schematically shows a crypto wallet assets and an example of its use,

[0047] - [Fig.2A] and [Fig.2B] show 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, [Fig.2A] illustrating a data backup step and [Fig.2B] a data restoration step,

[0048] - [Fig.3A] and [Fig.3B] show a cryptoasset portfolio according to the invention and the architecture of a system intended for the implementation of a second embodiment of the method according to the invention, [Fig.3A] illustrating a data backup step and [Fig.3B] a data restoration step,

[0049] - [Fig.4A] and [Fig.4B] describe an algorithm executed by the system of Figures 3A, 3B, during the data backup step,

[0050] - [Fig.4C] 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] - [Fig.5A] and [Fig.5B] describe an algorithm executed by the system of Figures 3A, 3B, during the data restoration step,

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

[0053] - [Fig.6A] and [Fig.6B] show 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, [Fig.6A] illustrating a data backup step and [Fig.6B] a data restoration step,

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

[0055] - [Fig.8] shows another embodiment of a cryptoasset wallet enabling the method according to the invention to be implemented,

[0056] - [Fig.9] shows yet another embodiment of a crypto wallet active ingredients for implementing the method according to the invention. Detailed description

[0057] The invention provides a method for creating a cryptoasset wallet offering a unique functionality in the field of hardware wallets, namely A seed backup feature that is automated yet highly secure. This feature allows users to avoid all the hassle and risk of having to store a recovery phrase in a secure location themselves.

[0058] [Fig.2A] shows a cryptoasset wallet CW1 and a system intended for implementing an embodiment of the method of the invention. The cryptoasset wallet CW 1 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 executes 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 m BCKi backup servers (BCK1, BCK2,... BCKi,.. .BCKm) each provided with a backup memory MEM (magnetic hard disk or solid state memory) for saving shares Si of the seed S. Each backup server comprises a BEi back-end program (BEI,.. .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 (SI, 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 m of secret data called "shares", and allowing the reconstitution of the seed from a threshold of n secret data Si:

[0061] SI, 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 SI, S2, S3, but only two parts will be necessary 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 SI, S2, both of which are necessary to reconstitute the seed.

[0063] When the user wishes to save his seed, the HW device establishes with each backup server BCKi, via the host device HDV, LNKi data links (LNK1 to LNKm), for example of the HTTPS type. These data links are then secured by the creation of secure channels of the SCP ("Secure Channel Protocol") type between the HW device and each backup server BCKi, 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 certification authority CA. The HW device and the BCKi backup servers each have a private key, a public key, a certificate signed by the certification authority, or static certificate, as well as the public key of the certification authority. 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: private key of the HW device

[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 going from i to m)

[0071] PBi: public key of a BCKi server (for i going 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 by means of 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 enable 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 take charge of the cryptographic calculations carried out using these keys. In the following and for the sake of simplification of the language, it will be considered that such cryptographic calculations are carried out by the servers themselves.

[0075] To implement a secure communication channel, a key exchange is provided between the HW device and each BCKi backup server, making it possible to generate 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 PeBi and public key PeBi pair using an asymmetric key generator, then communicates its ephemeral public key PeBi to the HW device in a certificate ephemeral CeBi that he signed with his private key pBi, as well as his CBi certificate signed by the trusted authority:

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

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

[0079] ii) the HW device itself generates a pair of ephemeral private key PeD and public key PeD, then communicates its ephemeral public key PeD to the backup servers BCKi 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 backup server BCKi verifies the signature of the ephemeral public key PeD of the HW device by means of the public key PD present in its CD certificate, then verifies the signature of the public key PD present in the CD certificate by means of 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 by means of the public key PBi present in the CB certificate, then verifies the signature of the public key PBi present in the CB certificate by means of 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 (Diffie Hellman key exchange based on elliptic curves or "Elliptic Curve Diffie-Hellman"), i.e.:

[0085] kBi = ECDH(peBi, PeD)

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

[0087] kBi = ECDH(peD, PeBi)

[0088] After generating the shares Si of the seed S, the HW device carries out symmetric encryption steps of 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 example of implementation, the HW device generates three shares SI, S2, S3 (the threshold n can then be equal to 2 or 3) and three backup servers BCKI, BCK2, BCK3 are provided. Each server BCKi generates its own session key kB 1, kB2, kB3 and the HW device generates on its side each of these session keys after an exchange of keys with each server in the manner which comes to be described. Then, the HW device carries out symmetric encryption steps of the shares SI, S2, S3 using these keys, namely:

[0089] - encrypts the part SI with the key kBl, i.e. {Sl]kBl, 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 backup server BCKi then decrypts the encrypted part {Si]kBi that it has received from the HW device, and stores it in its MEM memory.

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

[0094] For seed restoration, the secure channel creation steps described above are repeated. New session keys kBi are generated. Then, each server encrypts the share Si that it holds with the session key kBi, i.e. {Si]kBi, and then 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 that generated the shares Si, denoted "SS1":

[0095] S = SS 1 (SI, S2,..., Si,..., Sm)

[0096] [Fig.3A] shows 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 "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 the implementation of 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 links, IPsec VPN, 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 PeO and public PeO keys and then communicates its ephemeral public PeO key to the HW device in a certificate ephemeral CeO that he signed with his private key pO, accompanied by his CO certificate 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 a pair of ephemeral private keys peD and public PeD 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 orchestrator ORC1 verifies the signature of the ephemeral public key PeD of the HW device by means of the public key PD present in the certificate CD, then verifies the signature of the public key PD by means of 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 by means of the public key PO present in the certificate CO, then verifies the signature of the public key PO by means of the public key PL of the certification authority, or vice versa,

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

[0109] kO = ECDH(peO, PeD)

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

[0111] kO = ECDH(peD, PeO)

[0112] Once the secure channel has been 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 kO of all or part of the exchanged data. Conversely, the orchestrator can communicate to the HW device in an encrypted form using the key kO of the data received from the BCKi backup servers.

[0113] Secure channels are also created between the HW device and the BCKi backup servers by means of kBi session keys which are generated at the end of a key exchange via the LNK1 data link, 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 kO shared by the orchestrator and the HW device, which allows data to be encrypted exchanged between the orchestrator and the HW device,

[0116] - through LNK2i data links, channels secured by session keys kBi 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 kO data which are 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 steps relating to the exchange of keys previously described 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 by means of the ECDSA algorithm,

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

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

[0125] {CD}k0

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

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

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

[0129] {CD}k0 II CeD

[0130] either

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

[0132] (“II” being the symbol for concatenation)

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

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

[0135] Returning to [Fig.3A], 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 [Fig.3A]:

[0137] i) establishment of the LNK1 link 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 the 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 orchestrator ORC1 using the session key kO,

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

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

[0142] SI, 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] {Sl}kBlll{S2}kB2ll....ll{Si}kBill...ll{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 device HW', illustrated in [Fig.3B], triggered at the request of the user USR, comprises the following steps:

[0149] i) establishment of the LNK1 link 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 identifier BCKID, 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 orchestrator ORC1 by means of a new session key kO,

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

[0153] v) reading by each backup server BCKi, in its memory, by means of the identifier BCKID, of the part Si that it holds, and encryption of this by means of 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 backup servers BCKi:

[0156] {Sl]kBl, {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] {Sl}kBlll{S2}kB2ll....ll{Si}kBill...ll{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} 'kBi

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

[0162] S = SS 1 (SI, S2,..., Si,..., Sm)

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

[0164] S = SS 1 (SI, 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 channel secure, with mutual certificate verification. Once the secure channel is established, the HSW companion software connects to the UACC client account to retrieve the BCKID identifier. Alternatively, the BCKID identifier 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 0RC1 orchestrator. The orchestrator transfers the BCKID identifier to the UASRV server at backup time and reciprocally receives the BCKID identifier 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" making it possible to identify it. 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 gathers 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 = PIDIIODT

[0169] When the backup is initialized, as shown in [Fig.3A], the orchestrator communicates the BCKDT data to the BCKi backup servers which will associate them, as well as the identifier BCKID, with the backed up Si shares. For confidentiality reasons, it could be preferred, in certain embodiments, that the orchestrator does not keep the BCKDT data once the backup has been carried out. The BCKDT data are in this case only kept by the BCKi servers, which communicate them to the user USR for confirmation by the latter of his identity at the time of restoration, as shown in [Fig.3B].

[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 an embodiment shown in [Fig.3B], these verification steps identity verification services 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 may 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 part of them, is configured to perform an IDVi step of verifying 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 IDVO 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 IDVSRVO server is also associated with the orchestrator ORC1, and the orchestrator is configured to connect to a GTW gateway of an IDVSO service executed by this server for carrying out the IDVO step.

[0174] During the optional IDVO step preceding the backup or each of the IDVi steps occurring before the restitution of the shares of the seed, the orchestrator puts the USR user in contact with the appropriate IDVSO or IDVSi service, via the appropriate GTW gateway. The user must carry out certain actions requested of him via the screen of the HDV host device and the camera with which he is equipped (for example a mobile phone camera, a personal computer webcam, etc.). For example, the IDVSO or IDVSi service asks him to present a valid identity document including a photo of himself, to take a photo of the identity document with his camera and to send it to him. The IDVSO or IDVSi service then asks him to take a photo (selfie) or a video of his face and to send it.The IDVSO 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, give rise to 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 bases.

[0175] Although the IDVO step is not as critical as those performed by the BCKi servers at the time of returning the Si shares, 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 identity document 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 orchestrator ORC1 may suspend the seed backup process if it considers that the initial verification of the user's identity is inconclusive or is given too low a score. Furthermore, in another embodiment or in addition, the orchestrator receives from the backup servers BCKi information on the success of the identity verification steps IDVi 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 identity of the user 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 identity of the user. The orchestrator may optionally decide to subject the user to an additional step of verifying his identity.

[0177] In a variant, or in addition, the orchestrator receives from each BCKi backup server having carried out an identity verification step, a certainty score as to the identity of the user. 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 step of verifying his identity.

[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 the IDVO step 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 system of [Fig.3A] and implementing various aspects of the previously described embodiments of the method will now be described in relation to Figures 4A and 4B. [Fig.4C] is a sequence diagram which represents the steps of the algorithm in the form of interactions between:

[0181] - user USR,

[0182] - the HW device and its HDV host device (considered as one and the same entity forming the CW 1 cryptoasset portfolio),

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

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

[0185] - BCKi backup servers, and

[0186] - the IDVSRVi servers associated with the BCKi servers to carry out the verification steps subsequent identity verification, at the time of seed restoration.

[0187] Some functions used in the algorithm are shown in Table 1 below. after, by way of non-limiting example:

[0188] [Tables 1] Cryptography type Elliptic curve cryptography Sign Signature of type ECDSA (Elliptic Curve Digital Signature Algorithm) with the elliptic curve secp256kl ECDH Diffie-Hellman key exchange based on elliptic curves using for example the elliptic curve secp256kl Hash function SHA-256 (Secure Hash Algorithm) Symmetric encryption {.}k0 Algorithm AEAD-AES-SIV-CMAC-256 SS function Shamir Secret Sharing function or other similar function, or Pedersen Publicly Verifiable Secret Sharing PVSS based on the curve secp384rl

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

[0190] Bl. Backup Initialization

[0191] The USR user selects a seed backup option in the HW device. The user, via 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 of choosing 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 backup servers BCKi, 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 to the BCKi servers of the identifier of the backup

[0196] [ORC1 -> BCKi, HW] BCKID

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

[0198] B3. Performance of an IDVO identity verification by the IDVSRVO server

[0199] [IDVSRVO] IDVO

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

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

[0202] IDV_OK -> HW

[0203] The IDVSRVO server confirms to the ORC1 orchestrator that the IDV has been successfully performed, 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. During 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 by the orchestrator of an ephemeral certificate

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

[0207] Sign(pO, ReOIIPeO)

[0208] CeO = PeOIISign (pO, ReOIIPeO)

[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 having concatenated it with a piece of data ReO. The data ReO specifies, for example, the role played by the or-chestrator 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] CeOIICO —> HW

[0212] The ORC1 orchestrator sends its ephemeral certificate and its 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 certificate chain of the orchestrator, in the manner described above, using the public key PL of the certification authority.

[0216] B5.4. Generation by the HW device of a session key kO and a certificate short-lived

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

[0218] kO = ECDH(peD, PeO)

[0219] Sign(pD, ReDIIPeD)

[0220] {Sign(pD, ReDIIPeD)}k0

[0221] CeD = PeDII{Sign(pD, ReDIIPeD)]kO

[0222] {CD]kO

[0223] The HW device generates an ephemeral private key peD and an ephemeral public key PeD, then a session key kO 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 ReD data item. The ReD data item 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 kO. 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 kO.

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

[0225] [HW -> ORC1]

[0226] CeDII{CD}k0

[0227] The HW device sends to the orchestrator ORC1 its certificate CD encrypted using the key kO as well as its ephemeral certificate CeD including the encrypted signature. Thanks to the encryption of the certificate and the encryption of the signature of the ephemeral certificate, the public key PD is not exposed. The order of these steps can be reversed, the device being able to send its certificate, here encrypted, before sending its ephemeral certificate, here including the encrypted signature.

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

[0229] kO = ECDH(peO, PeD)

[0230] The orchestrator ORC1 generates the session key kO 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}1k0

[0233] Sign(pD, ReDIIPeD) = {Sign(pD, ReDIIPeD)} *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 certificates to BCKi servers, Device CD

[0237] [ORC1 -> BCKi]

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

[0239] BCKIDIlBCKDTIlCeDIlCD

[0240] The orchestrator ORC1 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 the IDVO step, 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 account server and transmitted to the BCKi servers after the backup.

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

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

[0243] Verif CeD, Verif CD

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

[0245] B8. Mutual authentication and creation of a secure channel between BCKi servers and the device, through 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, ReBIIPeBi)

[0250] CeBi = PeBillSign (pBi, ReBIIPeBi)

[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(PeBillBCKIDIIBCKDT)

[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 PID pivot identity data. In another embodiment, the HPIDi backup code is calculated by hashing the BCKDT backup data, which contains the PID pivot identity 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 hash code to the orchestrator figure

[0266] [BCKi -> ORC1]

[0267] RETDTi = CeBillCBillCHi

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

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

[0270] [ORC1 -> HW]

[0271] {BCKI DIIBCKDTIIRETDTlll....llRETDTill...llRETDTm}ko

[0272] The ORC1 orchestrator returns to the device the BCKID, BCKDT data and all the RETDTi data received from the BCKi backup servers, in an encrypted form using the key kO. 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. Decryption by the device of the certificates of the BCKi servers and of the code of encrypted hash

[0274] {BCKIDIIBCKDTIIRETDTll...llRETDTill...llRETDTm} *k0

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

[0276] B8.7. Validation of BCKDT data and BCKi servers by the user

[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. Generation by the device of kBi session keys and verification of the session codes encrypted hashes

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

[0286] kBi = ECDH(peD, PeBi)

[0287] {Hi}'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] SI, S2,...Si,..Sm = SS(S)

[0292] By means of the secret sharing function SS, the HW device generates the m shares Si to be saved in the different servers BCKI, 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 by means of a seed encryption key Kseed and an encryption function Fseed, before generating the m parts Si to be saved in the different servers BCKI, 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 comprises the following steps:

[0295] S=Fseed(S)Kseed

[0296] then:

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

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

[0299] In yet another variant B9' of step B9, it is the m shares Si which, after having been generated, are encrypted individually by means of the seed encryption key Kseed. This encryption of the shares Si of the seed can be, as previously, an AES 256 encryption. Step B9' in this case comprises the following steps:

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

[0301] then:

[0302] SI = Fseed(Sl)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 same “If” notation will be used to describe the following steps 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 recorded in a non-volatile memory of the hardware wallet HW, for example that which contains the operating system of the device. This recording can be done during the customization of the device, before its commercialization, or during an update of its firmware.

[0311] In one embodiment, the seed encryption key Kseed is common to a plurality of HW hardware wallets. The key may only be known to the manufacturer of the HW hardware wallets, so that it is not necessary for the user to keep it somewhere.

[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 ([Fig.4B])

[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 the key kBi which is specific to it. This involves an encryption of the shares Si using the session keys kBi specific to each BCKi server, i.e. a channel encryption of communication, which should be distinguished from encryption using the Kseed seed encryption key that was proposed above as an option. Thus, if this option is chosen, the Si shares, before being encrypted using the kBi session keys, may have been previously encrypted using the Kseed seed encryption key or come from a seed that has been previously encrypted with the Kseed seed encryption key.

[0317] B11. Sending encrypted shares to the orchestrator

[0318] [HW —> ORC1]

[0319] {Sl}kBlll{S2}kB2ll....ll{Si}kBill...ll{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] BCKIDII{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] {Si}'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 manner that it is linked to the user's identity

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

[0332] LNKSi = {SillHPIDi}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 LNKSi data resulting from this calculation forms an encrypted data linking the part Si and the pivot identity PID of the user and will be designated “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 manner 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 certain servers only. 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 which is a function of this pivot identity.

[0340] The derivation function FDERIV is for example the HKDF function which is a simple key derivation function (KDF) based on the HMAC message authentication code. The obtained 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 manner 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 certain 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 Si share in such a manner that it is linked to the user's identity

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

[0346] LNKSi = Hash(SillHPIDi) -> 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 Si part. 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 Si part it 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 manner 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, EncSillHPIDi) -> 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 orchestrator ORC1 by an “OKi” message (i ranging from 1 to m) that it has decrypted and stored the part of the seed entrusted to it. Optionally, each BCKi server can send an encrypted proof of the decryption of the part Si using a hash code signed with its session key. This signed hash code will be passed back to the HW device to be verified.

[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] - HSW companion software records the backup identifier BCKID,

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

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

[0367] The HSW companion software records the backup identifier BCKID and can also update the user's UACC client account by recording the backup identifier 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 pivot identity of the legitimate user, the BCKDT backup data could, in some embodiments, not include the PID data. Although it is more convenient to include the PID data in the BCKDT data to retrieve the Si shares in the BCKi servers from information relating to the identity of their owners, the BCKDT data could be reduced to other types of information, for example the name of the backup and / or the date of the backup, provided that the legitimate user can remember them at the time he wishes 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(PIDIIODT) -> STORE

[0373] An example of a seed restoration algorithm applicable to the system of [Fig.3A] and implementing various aspects of the embodiments of the method previously described will now be described in relation to Figures 5A, 5B, 5C. [Fig.5C] 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 consider 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 certification authority and the public key PL of the certification authority (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] RL Device sends a restore request to the orchestrator

[0377] HW' -> ORC1

[0378] RESTRQ[BCKID]

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

[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, ReOIIPeO)

[0384] CeO = PeOIISign (pO, ReOIIPeO)

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

[0386] ORC1 -> HW'

[0387] CeOIICO

[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 ephemeral certificate figure

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

[0392] kO = ECDH(peD, PeO)

[0393] Sign(pD, ReDIIPeD)

[0394] {Sign(pD, ReDIIPeD)}k0

[0395] CeD = PeDII{Sign(pD, ReDIIPeD)}k0

[0396] {CD]kO

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

[0398] [HW' -> ORC1]

[0399] CeDII{CD}k0

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

[0401] kO = ECDH(peO, PeD)

[0402] CD={CD}*k0

[0403] Sign(pD, ReDIIPeD) = {Sign(pD, ReDIIPeD)} *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] BCKIDIlCeDIlCD -> BCKi

[0410] The ORC1 orchestrator sends to each backup server BCKi 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, through 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, ReBIIPeBi)

[0419] CeBi = PeBillSign (pBi, ReBIIPeBi)

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

[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(PeBillBCKIDIIBCKDT)

[0425] CHi = {Hi]kBi

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

[0427] [BCKi -> ORC1]

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

[0429] RETDTi = CeBillCBillCHi

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

[0431] [ORC1 —> HW']

[0432] {BCKIDIIBCKDTIIRETDT1I.. .HRETDTill.. .IIRETDTm}k0

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

[0434] {BCKIDIIBCKDTIIRETDT11...HRETDTill...HRETDTm] *k0

[0435] R5.7. Validation of backup data by the user

[0436] Validate BCKDT

[0437] The user validates the data of 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. Generation by the device of kBi session keys and verification of session codes encrypted hashes CHi

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

[0443] kBi = ECDH(peD, PeBi)

[0444] {Hi]*kBi

[0445] Validate Hi (Hi = Hash(PeBillBCKIDIIBCKDT)

[0446] R6. Preparation of restoration

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

[0448] [HW'-> ORC1]

[0449] {ConfirmRestorel}kBlll{ConfirmRestore2}kB2ll.. .H{ConfirmRestorei}kBill.. .11 {ConfirmRestorem}kBm —> ORC1

[0450] The HW device returns to the ORC1 orchestrator for each BCKi server, an individual restoration confirmation "ConfirmRestore;" 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] BCKIDII{ConfirmRestorei}kBi -> BCKi

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

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

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

[0457] {ConfirmRestore;} '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] Server click BCKi indicates to the orchestrator ORC1 that it is ready to restore the part Si that it has saved provided that the user identifies himself through an IDVi step.

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

[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] It should be noted that the duration of each IDVRi identity verification step can range from a few minutes to several days depending on the requirements of each BCKi server or the service provider carrying out the IDVRi. Verifications by individuals may be systematically planned with certain 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 from the IDVSi service, containing the identity of the user and the result of the IDV, allowing it to reconstruct the data of the pivot identity PID'. This report is preferably signed by the service IDV. The BCKi server can then validate that the IDV is successful, and that the identity contained in the report matches the saved PID identity.

[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 shares of the seed, if the user who is attempting to restore the seed here is not a usurper. Each BCKi server then generates a HPIDi' restoration code based on the PID' data in the same way that generated the HPIDi backup code 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 restoration of the seed is not a usurper, 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 carried out 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 carried out 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'IIODT

[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. Restoration of secure communication channels after completion of the IDVi identity verification steps

[0483] [HW' ORC1]

[0484] Continue Restore

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

[0486] Repetition of steps R2.1 to R2.7, R3, R5.1 to R5.9 ([Fig.5B])

[0487] As several days may pass during the performance of 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 kO 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 will be noted that if during the IDVRi steps one of the BCKi servers has not been able to verify the identity of the user 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 identity of the user 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 identity of the user. It can optionally decide to subject the user to an additional procedure for verifying his identity.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 what follows in parentheses, this step is limited to n backup servers BCKi, instead of all the backup servers, if only n parts are necessary for the reconstitution of the seed, with n less than m.

[0494] RIO. 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 CD certificate of the HW' device is the same as the CD certificate received before conducting the IDVi identity verification steps, which it has retained.

[0498] R10.2.a. Decryption by each BCKi server of the encrypted link data LNKSi containing the Si share 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 = SillHPIDi = {SillHPIDi]pBi 1

[0501] COMPARE {HPIDi', HPIDi]

[0502] During this step, each BCKi server decrypts the LNKSi data stored in its memory to extract the part Si and the backup code HPIDi. The decryption is carried out 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 restoration code HPIDi' and the backup code HPIDi. If the user requesting the restoration of the seed is not a usurper, the restoration code HPIDi' 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 share 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}KII„-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 B 13.2', because the codes HPIDi' and HPIDi are identical. The same derivation function as that used in step B 13.2' must of course be used, for example the function HKDF.

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

[0510] R10.2.C. Decryption by each BCKi server of the encrypted link data LNKSi containing the Si share 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]KiDi1

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

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

[0517] Si = {EncSi]PBi1

[0518] LNKSi'= Hash(SillHPIDi')

[0519] COMPARE {LNKSi, LNKSi'}

[0520] This step is a variant of step R10.2.a and is implemented if the variant B13.2.d of step B13.2.aa was 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 recovery 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 restoration code HPIDi' and the encrypted link data LNKSi calculated at the time of the backup. If the user requesting the restoration of the seed is not a usurper, LNKSi' is equal to LNKSi and each BCKi server agrees to return the share Si that it holds, otherwise refuses to return it.

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

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

[0524] LNKSi' = HMAC(pBi, EncSillHPIDi')

[0525] COMPARE {LNKSi, LNKSi'}

[0526] If = {EncSi}pBi1

[0527] This step is a variant of step R10.2.a and is implemented if variant B13.2.e of step B13.2.a has been 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 restoration 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 the 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 that it holds, after having decrypted it using the secret key pBi, otherwise refuses to return it.

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

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

[0531] {Sl}kBlll{S2}kB2ll....ll{Si}kBill...ll{Sm}kBm -> ORC1

[0532] Each BCKi server sends to the orchestrator ORC1 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] {Sl}kBlll{S2}kB2ll....ll{Si}kBill...ll{Sm}kBm -> HW'

[0535] The orchestrator 0RC1 sends to the HW' device all the shares Si 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} 'kBi

[0539] S = SS 1 (SI, S2,...Si...Sm)

[0540] (or S = SS 1 (SI, S2,...Si...Sn))

[0541] After having decrypted each share of rank i by means of 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 the 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 Fseed1 corresponding to the inverse function of the function Fseed:

[0543] S = Fseed '(S)Kseed

[0544] In a variant R13' of step R13 corresponding to variant B9' of step B9, each part Si that the device HW' has decrypted has been originally encrypted with the seed encryption key Kseed. Each part 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'(Si)Kseed}'kBi

[0547] S = SS 1 (SI, 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^ORCl

[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 which has been described is susceptible of numerous other variants and embodiments. The structure of the cer documents involved in the process have been described above according to two variants, for example:

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

[0554] Cex = Pexll{Sign(px, RexIlPex)

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

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

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

[0558] [Fig.6A] shows a system for implementing the method of the invention which differs from that of [Fig.3A] in 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 orchestrator OCR2, following which the orchestrator ORC2 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 identity of the user. If this step is successful, the orchestrator issues backup authorizations BCKPASSi to the HW device, at a rate of one authorization per backup server BCKi, and sends each authorization to the BCKi server concerned.

[0560] Each BCKPASSi authorization forms a sort of "passport" allowing the HW device to know which BCKi server it must address to save a Si share of the seed, and allowing it to connect to the BCKi server to carry out the backup without being rejected by the latter. Each BCKPASSi authorization may include various information and in particular the information which previously appeared in the BCKDT backup data and the BCKID identifier. The BCKPASSi authorizations are stored by the companion software as well as, preferably, in the UACC user account on the UASRV account server. In a variant, the orchestrator issues a general BCKPASS authorization containing a concatenation of all the information appearing in the BCKPASSi authorizations.

[0561] With reference to [Fig.6B], when the user wants to restore the seed, the software The companion connects to the BCKi backup servers that it identifies using the addresses contained in the BCKPASSi authorizations, and then hands over to the HW device to establish secure channels with the BCKi backup servers, using key exchanges as described above. Once the secure channels have been established, the BCKi backup servers initiate the IDVi steps of verifying the user's pivot identity.

[0562] The role of supervisor of the IDVi steps which 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 deleting 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 failure of the system, or loss of the BCKID identifier (embodiment figures 3A, 3B) or of 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 offer 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] [Fig.7] shows an exemplary embodiment of a hardware wallet HW enabling 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 SEL. For this purpose, the input / output resources of the secure element SE1 are divided into three input / output groups IOGA, IOGB, IOGC. The IOGA input / output group is assigned to implement a BS1 bus connecting the SE1 secure element to the MCU1 microcontroller. The IOGB input / output group is assigned to implement a BS2 bus connecting the SE1 secure element to the EID display, and the IOGC input / output group is assigned to implement 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, provides the voltage Vbat to the battery when it needs to be charged, and provides a regulated supply voltage Vcc to the microcontroller MCU1, the secure element SE1 and the touch screen TS1;

[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 voltage Vqi to the PMIC circuit for battery charging;

[0569] - a USB Ul port. The USB port provides the PMIC circuit with a Vusb voltage for the charging the battery, 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 BTA antenna, 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 microcontroller MCU1. 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 by 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 the cold storage of private keys offering the highest level of security.The SE1 secure element also includes a memory space MS 1 comprising a read-only memory area, an electrically erasable and programmable non-volatile memory area and an area. volatile memory. The electrically erasable, 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 lends itself well 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 cryptoasset wallet CW2 of the type shown in [Fig.8]. The cryptoasset wallet CW2 comprises a secure microcontroller SMCU, a screen TS2 which can be touch-sensitive, communication interface circuits CINT1 including in particular wifi 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 in the 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, [Fig.9] 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 DV device comprises an MPU microprocessor equipped with a CINT2 communication interface allowing it to connect to the Internet, volatile RAM memory and non-volatile NVM memory, for example a magnetic hard disk or a solid-state drive (SSD). The CW3 program forming the software cryptoasset wallet is stored in the NVM non-volatile memory of the DV device and is executed by the MPU microprocessor using its RAM memory.

Claims

Claims

1. 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 (B 11, 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 - storing the encrypted link data in a memory (MEM) of the backup server.

2. Method according to claim 1, in which 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.

3. Method according to one of claims 1 and 2, in which 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) as a function of 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) as a function of the data (BCKDT, PID) defining the identity of the first user, and - encrypt the secret part (Si) using the first derived key (KIDi).

4. 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.

5. 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) by means of 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 by means of 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.

6. 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.

7. 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.

8. 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, verify their validity with the participation of the second user, and provide them to at least one backup server, and - by means of the backup server, verify, 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.

9. 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).

10. 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) therefrom, - comparing the restoration code (BCKDT', PID', HPIDi') and the backup code (BCKDT, PID, HPIDi), and - restoring the secret part (Si) present in the link data encrypted (LNKSi) if the two codes are identical, and refuse to return it if the two codes are not identical.

11. 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, verify their validity with the participation of the second user, and provide them to at least one backup server, and - using the backup server: - generate (R7.2) a restoration code (BCKDT, PID', HPIDi') based 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 backup server using as derivation diversifier the restoration code (BCKDT', PID', HPIDi'), to obtain a second derived key (KIDi') as a function of the data (BCKDT', PID') defining the identity of the second user, and - if the first and second derived keys are identical, decrypt the encrypted link data (LNKSi) using the second derived key (KIDi') and extract the secret part (Si).

12. A method according to claim 4, comprising a step of restoring the secret comprising the steps of: - collect (R7.1) data (BCKDT', PID') defining the identity of a second user, verify their validity with the participation of the second user, and provide them to at least one backup server, and - using the backup server, - generate (R7.2) a restoration code (BCKDT', PID', HPIDi') based on the identity of the second user, - decrypt the secret part (Si) using the secret key of the backup server, - combine (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 - return the secret part (Si) if the new encrypted link data (LNKSi') and the encrypted link data (LNKSi) are identical, otherwise refuse to return the secret part (Si).

13. A method according to claim 5, comprising a step of restoring the secret comprising the steps of: - collect (R7.1) data (BCKDT', PID') defining the identity of a second user, verify their validity with the participation of the second user, and provide them to at least one backup server, and - by means of the backup server, - generate (R7.2) a restoration code (BCKDT, PID', HPIDi') depending on the identity of the second user, - combine (R10.2.e) the secret part and the restoration code, and encrypt the combination of the secret part and the restoration 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).

14. 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.

15. 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.

16. 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.

17. 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).

18. 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.

19. Server for saving and restoring a secret data item (Si), configured to, in response to a request to save the secret data item: - receive the secret data item (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 item (LNKSi) which is a function of the secret data item (Si) and the data (BCKDT, PID) defining the identity of the first user, and - store the encrypted link data item in a memory (MEM) of the server.

20. Server according to claim 19, configured to generate the encrypted link data (LNKSi) by executing 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.

21. 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).

22. 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.

23. Server according to claim 19, configured to generate the data of encrypted link (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) based 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.

24. 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.

25. 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.

26. 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.

27. ​​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') based 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') function of 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 secret data (Si) therefrom.

28. 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') based 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 recovery code, hash the combination of the secret data and the recovery 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 (Si).

29. 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') based on the identity of the second user, - combine (R10.2.e) the secret data and the recovery code, and encrypt the combination of the secret data and the recovery code using the server's secret key (pBi) 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 restore the secret data (Si).

30. 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.

31. 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.