Method for securely backing up and restoring a seed held by a cryptoasset wallet

Abstract

Method for backing up and restoring a seed (S) held by a cryptoasset wallet (CW1), comprising, for backing up the seed, the steps of providing a plurality of backup servers (BCKi), generating a plurality of secret data (Si) from the seed (S), and transferring to each backup server one of the secret data provided by the cryptoasset wallet. The method also comprises a step of encrypting at least one of the secret data (Si) generated from the seed (S), before transferring it (B11, B12) to a backup server, by means of a seed encryption function (Fseed) and a seed encryption key (Kseed). Figure for abstract: Fig. 3A

Description

Title of the invention: Method for the secure backup and restoration of a seed held by a cryptoasset wallet. Technical field

[0001] The present invention relates to a method for securely backing up and restoring a seed held by an electronic device. The present invention particularly relates to hierarchical deterministic hardware wallets used for storing private keys for managing accounts on the blockchain. 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 most secure solution against hacker attacks. Its only drawback lies in the risk of loss, theft or destruction (e.g. fire) of the hardware wallet, or loss of the user's personal password allowing it to be used. The keys it contains must therefore generally be saved 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 "Nano" or "Stax", and a host device HDV running a companion application HSW, for example the application "Ledger Live" developed by the applicant. Since the HW device cannot connect directly to the Internet, it is associated with the host device HDV to carry out transactions on the blockchain. The 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. Summary

[0013] Embodiments relate to a method for backing up and restoring a seed held by a cryptoasset wallet, comprising the steps of providing a plurality of backup servers and, by means of the cryptoasset wallet, generating a plurality of secret data from the seed and transferring to each backup server one of the secret data provided by the cryptoasset wallet, the method also comprising a step of encrypting, by means of a seed encryption function and a seed encryption key, at least one of the secret data generated from the seed, before transferring it to a backup server.

[0014] According to one embodiment, the step of encrypting at least one of the secret data comprises at least one of the following steps: using the seed encryption function and the seed encryption key, encrypting the seed before generating the plurality of secret data from the seed, using the function seed encryption and the seed encryption key, encrypting said at least one secret data before transferring it to a backup server.

[0015] According to one embodiment, the seed encryption key is recorded in a non-volatile memory of the hardware wallet, during its customization or during a subsequent update.

[0016] According to one embodiment, the seed encryption key is common to a plurality of cryptoasset wallets.

[0017] According to one embodiment, the seed encryption key is derived from a secret known to the user.

[0018] According to one embodiment, each secret data is transferred to a backup server in an encrypted form using a session key which is known only by the cryptoasset wallet and the backup server for which it is intended.

[0019] According to one embodiment, the method further comprises steps of collecting information relating to the identity of the user, communicating to each backup server the information relating to the identity of the user, and associating each secret data with the identity of the user in each backup server.

[0020] According to one embodiment, the information relating to the identity of the user comprises at least the first name of the user, the last name of the user and the date of birth of the user.

[0021] According to one embodiment, the cryptoasset wallet is configured to generate a plurality of secret data by means of a secret sharing function provided to generate a number m of secret data from the seed and allow the reconstitution of the seed from a threshold of n secret data.

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

[0023] According to one embodiment, the method comprises, for the restoration of the seed, the following steps: communication to each backup server of the information relating to the identity of the user, reception by the cryptoasset wallet, in a form encrypted by a session key, of all or part of the secret data held by the backup servers, and reconstitution of the seed by the cryptoasset wallet from the secret data provided by the backup servers and by means of an inverse function of the seed encryption function.

[0024] According to one embodiment, the method comprises the steps of providing an orchestrator program executed by a server, and configuring the program orchestrator and the cryptoasset wallet to perform at least one of the following steps: when backing up the seed, transfer to the orchestrator program by the cryptoasset wallet of the secret data generated by the cryptoasset wallet, and transfer to the backup servers, by the orchestrator program of the secret data received from the cryptoasset wallet, and when restoring the seed, reception by the orchestrator program of all or part of the secret data held by the backup servers, and transfer of this secret data to the cryptoasset wallet by the orchestrator program.

[0025] According to one embodiment, the method comprises the steps of establishing a first secure communication channel between the cryptoasset wallet and the orchestrator program, by means of a first session key generated after a key exchange between the cryptoasset wallet and the orchestrator program, and establishing a second secure communication channel between the cryptoasset wallet and each backup server via the orchestrator program, by means of a plurality of second session keys generated after a key exchange between the cryptoasset wallet and each backup server via the orchestrator program.

[0026] According to one embodiment, before providing the secret data that it holds, at least one backup server subjects the user to a step of verifying his identity, and refuses to restore the secret data if the verification of the user's identity is not conclusive.

[0027] Embodiments also relate to a cryptoasset wallet holding or intended to hold a seed, configured to provide a user with the following options: saving the seed manually in the form of a recovery phrase to be retained by the user, or saving the seed in a plurality of backup servers, and, if the user chooses to save the seed in a plurality of backup servers: generating a plurality of secret data from the seed, transferring each secret data to a backup server, and using a seed encryption function and a seed encryption key, encrypting at least one of the secret data generated from the seed, before transferring it to a backup server.

[0028] According to one embodiment, the wallet is configured to conduct the step of encrypting at least one of the secret data by executing at least one of the following steps: using the seed encryption function and the seed encryption key, encrypting the seed before generating the plurality of secret data from the seed, using the seed encryption function and the seed encryption key, encrypting said at least one secret data before transferring it to a backup server.

[0029] According to one embodiment, the wallet is configured to conduct a step of collecting information relating to the identity of the user, in the presence of the user, and a step of communicating to each backup server the information relating to the identity of the user.

[0030] According to one embodiment, the wallet is configured to also offer the user the following options: restore the seed manually from a recovery phrase, or restore the seed from a plurality of backup servers, and, if the user chooses to restore the seed from a plurality of secret data held by a plurality of backup servers, reconstruct the seed from the data provided by the backup servers and by means of an inverse function of the seed encryption function.

[0031] According to one embodiment, the wallet is configured to generate a plurality of secret data from the seed by means of a secret sharing function provided to generate a number m of secret data and allow the reconstitution of the seed from a threshold of n secret data.

[0032] According to one embodiment, the wallet is configured to, if the user chooses to restore the seed from the secret data, conduct at least one step of verifying the identity of the user at the request of a backup server.

[0033] According to one embodiment, the wallet comprises a hardware wallet without means of connection to the Internet, and a host device running companion software and provided with a connection to the Internet, the companion software complementing the hardware wallet for carrying out steps requiring interaction with the user, in particular steps of collecting information relating to the identity of the user. Summary description of the drawings

[0034] 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:

[0035] - the [Fig.l] previously described schematically shows a portfolio of cryptoassets and an example of its use,

[0036] - [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,

[0037] - [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,

[0038] - [Fig.4A] describes an algorithm executed by the system of figures 3A, 3B, during the data backup step,

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

[0040] - [Fig.5A] describes an algorithm executed by the system of figures 3A, 3B, during the data restoration step,

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

[0042] - [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,

[0043] - [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,

[0044] - [Fig.8] shows steps carried out by the user of the hardware wallet of the [Fig.7] for saving the seed stored in the hardware wallet,

[0045] - [Fig.9] shows steps carried out by the user of the hardware wallet of the [Fig.7] for the restoration of the seed,

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

[0047] - [Fig.l 1] shows yet another embodiment of a wallet of cryptoassets allowing the implementation of the method according to the invention. Detailed description

[0048] The invention provides a method for producing a cryptoasset wallet offering a unique functionality in the field of hardware wallets, namely a seed backup functionality that is automated while being highly secure. Such functionality allows users to free themselves from all the difficulties and dangers associated with having to preserve a recovery phrase themselves in a secure location. The unique functionalities offered by a cryptoasset wallet according to the invention will be described later in relation to Figures 8, 9 and Tables 2 and 3. Embodiments of the method according to the invention will first be described.

[0049] [Fig.2A] shows a cryptoasset wallet CW 1 and a system provided for implementing an embodiment of the method of the invention. The wallet of cryptoassets CW 1 here comprises an HW device and an HDV host device. The HW device is a hardware wallet providing 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 HDV host device, which runs HSW companion software allowing it to connect to the Internet, for example by means of a USB or Bluetooth connection. The system and method according to the invention make it possible to save or restore the seed S (master key) stored in the HW device.

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

[0051] 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:

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

[0053] For example, if m is equal to 3 and n 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.

[0054] When the user wishes to save his seed, the HW device establishes with each BCKi backup server, via the HDV host device, 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 BCKi backup server, in a manner which will be described.

[0055] 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:

[0056] pL: private key of the certification authority

[0057] PL: public key of the certification authority

[0058] pD: private key of the HW device

[0059] PD: public key of the HW device

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

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

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

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

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

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

[0066] 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:

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

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

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

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

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

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

[0073] 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),

[0074] 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,

[0075] 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.:

[0076] kBi = ECDH(peBi, PeD)

[0077] 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.:

[0078] kBi = ECDH(peD, PeBi)

[0079] After generating the shares Si of the seed S, the HW device conducts symmetric encryption steps for each share Si with the session key kBi common to the backup server BCKi to which the share Si must be sent, which therefore forms a shared key. In a simple 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 each of these session keys on its side after an exchange of keys with each server in the manner just described. Then, the HW device conducts symmetric encryption steps for the shares SI, S2, S3 using these keys, i.e.:

[0080] - encrypts the SI part with the key kBi, i.e. {Sl]kBl, then sends it to the BCKI server,

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

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

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

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

[0085] 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":

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

[0087] [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:

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

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

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

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

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

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

[0094] 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.:

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

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

[0097] 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,

[0098] 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,

[0099] 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:

[0100] kO = ECDH(peO, PeD)

[0101] 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:

[0102] kO = ECDH(peD, PeO)

[0103] Once the secure channel is created between the orchestrator and the HW device, data intended for the BCKi backup servers can be securely sent by the HW device to the orchestrator, thanks to symmetric encryption using the shared session key 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.

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

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

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

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

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

[0109] In one embodiment, the method of the invention implements two improvements concerning the transmission of the CD certificate of the HW device in the context of a key exchange with any server. Indeed, the sending by the device of its CD certificate in the context of such a key exchange constitutes a breach in terms of confidentiality, the public key PD present in the certificate being exposed in the event of monitoring of the line. Furthermore, it has been demonstrated that an ECDSA signature makes it possible to find the value of the corresponding public key. Thus, the transmission of the signature Sign(pD, PeD) of the ephemeral public key PeD in the ephemeral certificate CeD can also allow a third party to discover the public key PD.

[0110] These two improvements consist respectively in the encryption of the certificate CD and in the encryption of the signature Sign(pD, PeD). As an example, the implementation of these methods will be described in the context of the calculation of the session key kO described previously. The steps relating to the exchange of keys previously described are modified as follows:

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

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

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

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

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

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

[0117] {CD}k0

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

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

[0120] 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:

[0121] {CD]kO II CeD

[0122] either

[0123] {CD]kO II PeD II {Sign(pD, PeD)]kO

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

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

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

[0127] It will be clear to those skilled in the art that these two methods of encrypting the CD certificate and encrypting the signature of the ephemeral public key PeD can be implemented separately, the public key being able to be encrypted without encrypting the signature or vice versa. It will also be clear to those skilled in the art that these two methods are of universal application and can be implemented when creating any secure channel based on a key exchange and the generation of signatures with the ECDSA algorithm.

[0128] Returning to [Fig.3A], it is clear from the above that the provision of the orchestrator ORC1 makes it possible to reduce the number of data links between the HW device and the backup servers BCKi, these links being replaced by the single data link LNK1 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 link LNK1, as indicated above. It is also possible to preserve the confidentiality of the public key PD thanks to the improvements which have just been described. The provision of the orchestrator has various other advantages which will be described later in relation to the implementation of steps for verifying the identity of the user.

[0129] The step of saving the seed S can in this case be implemented as follows, with reference to [Fig.3A]:

[0130] 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,

[0131] 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,

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

[0133] 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,

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

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

[0136] 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,

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

[0138] {Sl}kBlll{S2}kB2ll....ll{Si}kBill...ll{Sm}kBm

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

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

[0141] 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:

[0142] 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,

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

[0144] iii) creation of the secure channel between the HW device and the orchestrator ORC1 by means of a new session key kO,

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

[0146] 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,

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

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

[0149] {Sl]kBl, {S2]kB2,...„ {Si]kBi,.{Sm]kBm

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

[0151] {Sl}kBlll{S2}kB2ll....ll{Si}kBill...ll{Sm}kBm

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

[0153] If={If}'kBi

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

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

[0156] 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:

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

[0158] 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 UASRV client account server can be provided, comprising a UACC user account in which various data concerning the user are retained, in particular the backup identifier BCKID. The UASRV server is associated with an HSM security module receiving a private key pC, a public key PC, a certificate CC signed by the certification authority, and the public key PL of the latter. In this case, the HW device establishes a data link with the UASRV server thanks to a key exchange making it possible to define a session key for the creation of a secure channel, with reciprocal verification of the certificates.Once the secure channel is established, the HSW companion software connects to the UACC client account to retrieve the BCKID. Alternatively, the BCKID is stored on the UASRV server but is not communicated to the companion software. A secure connection is established between the UASRV server and the ORC1 orchestrator. The orchestrator transfers the BCKID to the UASRV server at backup time and reciprocally receives the BCKID from the UASRV server when the user wants to restore their seed.

[0159] In one embodiment, the user's identity is also associated with the backup process, by defining a set of information forming a "pivot identity" allowing it to be identified. The information forming the pivot identity includes, for example, the user's first name, last name, and date of birth, and optionally other information 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 "backup data" BCKDT. The BCKDT data may contain other information such as the date and time of the backup, and a name given by the user to the backup (to allow them to subsequently distinguish between several backups, if they hold several hardware wallets).

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

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

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

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

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

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

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

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

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

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

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

[0171] 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 [Fig.4A]. [Fig.4B] is a sequence diagram which represents the steps of the algorithm in the form of interactions between:

[0172] - the user USR,

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

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

[0175] - the IDVSRV0 server associated with the orchestrator to carry out the IDV0 step of user identity verification,

[0176] - BCKi backup servers, and

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

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

[0179] [Tab 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

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

[0181] B1. Initializing the backup

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

[0183] [HW^ORCl]

[0184] BCKRQ

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

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

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

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

[0189] B3. Carrying out an IDV0 identity verification by the IDVSRV0 server

[0190] [IDVSRV0] IDV0

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

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

[0193] IDV_OK -> HW

[0194] The IDVSRV0 server confirms to the ORC1 orchestrator that 1TDV 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.

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

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

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

[0198] Sign(pO, ReOIIPeO)

[0199] CeO = PeOIISign (pO, ReOIIPeO)

[0200] 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 by means of its private key pO. In a variant retained here, the orchestrator calculates the signature of its ephemeral public key PeO after having concatenated it with a ReO data item. The ReO data item specifies for example the role that the orchestrator server plays in the process, for example the role of orchestrator for the establishment of a secure channel. The orchestrator then generates an ephemeral certificate CeO by concatenating the ephemeral public key PeO and the signature.

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

[0202] CeOIICO -> HW

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

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

[0205] Verif CeO, Verif CO

[0206] The HW device verifies the certificate chain of the orchestrator, in the manner described above, by means of the public key PL of the certification authority.

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

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

[0209] kO = ECDH(peD, PeO)

[0210] Sign(pD, ReDIIPeD)

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

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

[0213] {CD}k0

[0214] 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 piece of data ReD. The data ReD specifies, for example, the role played by HW in the process. The HW device then encrypts the signature of its ephemeral public key with the session key kO, in accordance with the signature encryption method described above. 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, in accordance with the certificate encryption method described above.

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

[0216] [HW -> ORC1]

[0217] CeDII{CD}k0

[0218] 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, as explained above. As indicated above, 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.

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

[0220] kO = ECDH(peO, PeD)

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

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

[0223] CD={CD}1k0

[0224] Sign(pD, ReDIIPeD) = {Sign(pD, ReDIIPeD)} *k0

[0225] Verif CeD, Verif CD

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

[0227] B6. Sending BCKID, BCKDT data and CeD certificates to BCKi servers, Device CD

[0228] [ORC1 -> BCKi]

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

[0230] BCKIDIlBCKDTIlCeDIlCD

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

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

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

[0234] Verif CeD, Verif CD

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

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

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

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

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

[0240] Sign(pBi, ReBIIPeBi)

[0241] CeBi = PeBillSign (pBi, ReBIIPeBi)

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

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

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

[0245] kBi = ECDH(peBi, PeD)

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

[0247] B8.3 Generation by each BCKi server of an encrypted hash code

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

[0249] Hi = Hash(PeBillBCKIDIIBCKDT)

[0250] CHi = {Hi]kBi

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

[0252] B8.4 Sending BCKi server certificates and hash code to the orchestrator figure

[0253] [BCKi -> ORC1]

[0254] RETDTi = CeBillCBillCHi

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

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

[0257] [ORC1 -> HW]

[0258] {BCKI DIIBCKDTIIRETDTlll....llRETDTill...HRETDTm}ko

[0259] The ORC1 orchestrator returns to the device the BCKID, BCKDT and all 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.

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

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

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

[0263] B8.7 User validation of BCKDT data and BCKi servers

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

[0265] Validate BCKDT, BCKi

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

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

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

[0269] Verif CeBi, Verif CBi

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

[0271] B8.9 Generation by the device of kBi session keys and verification of session codes encrypted hashes

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

[0273] kBi = ECDH(peD, PeBi)

[0274] {Hi}'kBi

[0275] Validate Hi

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

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

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

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

[0280] 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 BCK1, BCK2... BCKm. The function Fseed is for example the AES 256 encryption, i.e. a symmetric encryption, the seed encryption key Kseed also forming a decryption key.

[0281] Step B9' in this case comprises the following steps:

[0282] S=Fseed(S)Kseed

[0283] then:

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

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

[0286] 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:

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

[0288] then:

[0289] SI = Fseed(Sl)Kseed

[0290] S2 = Fseed(S2)Kseed

[0291]

[0292] If = Fseed(If)Kseed

[0293]

[0294] Sm = Fseed(Sm)Kseed

[0295] For the sake of simplicity, the same “If” notation will be used to describe the following steps, 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.

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

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

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

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

[0300] B10. Encryption of shares If by the device

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

[0302] {Si]kBi

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

[0304] B11. Sending encrypted shares to the orchestrator

[0305] [HW -> ORC1]

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

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

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

[0309] [ORC1 -> BCKi]

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

[0311] BCKIDII{Si]kBi -> BCKi

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

[0313] B13. Decryption and recording by each BCKi server of the encrypted part Si

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

[0315] {Si}'kBi STORE

[0316] Each BCKi server decrypts the Si share it received and stores it in its MEM memory for safekeeping.

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

[0318] [BCKi -> ORC1] OKi

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

[0320] B15. Confirmation of backup to the user

[0321] [ORC1 -> HW]

[0322] OK

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

[0324] At the end of the process:

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

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

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

[0328] - each BCKi server holds the backup identifier BCKID, the data of the BCKDT backup which contains at least the user's pivot identity, and the Si share of the seed entrusted to him.

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

[0330] An example of a seed restoration 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 [Fig.5A]. [Fig.5B] is a sequence diagram which represents the steps of the algorithm in the form of interactions between the previously mentioned entities.

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

[0332] 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 previously 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 repeated.

[0333] RI. Sending by the device of a restoration request to the orchestrator

[0334] HW' -> ORC1

[0335] RESTRQ[BCKID]

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

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

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

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

[0340] Sign(pO, ReOIIPeO)

[0341] CeO = PeOIISign (pO, ReOIIPeO)

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

[0343] ORC1 -> HW'

[0344] CeOIICO

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

[0346] Verif CeO, Verif CO

[0347] R2.4. Device generation of a session key and an ephemeral certificate figure

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

[0349] kO = ECDH(peD, PeO)

[0350] Sign(pD, ReDIIPeD)

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

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

[0353] {CD}k0

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

[0355] [HW' -> ORC1]

[0356] CeDII{CD}k0

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

[0358] kO = ECDH(peO, PeD)

[0359] CD={CD}*k0

[0360] Sign(pD, ReDIIPeD) = {Sign(pD, ReDIIPeD)} *k0

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

[0362] Verif CeD, Verif CD

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

[0364] [ORC1 -> BCKi]

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

[0366] BCKIDIlCeDIlCD -> BCKi

[0367] 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'.

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

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

[0370] Verif CeD, Verif CD

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

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

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

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

[0375] Sign(pBi, ReBIIPeBi)

[0376] CeBi = PeBillSign (pBi, ReBIIPeBi)

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

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

[0379] kBi = ECDH(peBi, PeD)

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

[0381] Hi = Hash(PeBillBCKIDIIBCKDT)

[0382] CHi = {Hi]kBi

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

[0384] [BCKi -> ORC1]

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

[0386] RETDTi = CeBillCBillCHi

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

[0388] [ORC1 -> HW']

[0389] {BCKIDIIBCKDTIIRETDT 11...HRETDTill... IIRETDTm}k0

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

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

[0392] R5.7 User validation of backup data

[0393] Validate BCKDT

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

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

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

[0397] Verif CeBi, Verif CBi

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

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

[0400] kBi = ECDH(peD, PeBi)

[0401] {Hi]*kBi

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

[0403] R6. Preparation of restoration

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

[0405] [HW-> ORC1]

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

[0407] The HW' device returns to the ORC1 orchestrator for each BCKi server, a Individual restore confirmation "ConfirmRestorei" which is encrypted with the kBi key of each BCKi server. Each confirmation is a predefined binary code.

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

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

[0410] BCKIDII{ConfirmRestorei}kBi -> BCKi

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

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

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

[0414] {ConfirmRestorei} 'kBi

[0415] CD Store

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

[0417] R6.4 Confirmation by each BCKi server that the restoration can be initiated under identity verification reserve

[0418] [BCKi^ ORC1]

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

[0420] OK_for_IDV

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

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

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

[0424] IDVRi

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

[0426] It will 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.

[0427] R8. Restoration of secure communication channels after completion of the IDVi identity verification steps

[0428] [HW' -> ORC1]

[0429] Continue Restore

[0430] 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".

[0431] Repetition of steps R2.1 to R2.7, R3, R5.1 to R5.9

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

[0433] R9. Resumption of restoration

[0434] [ORC1 -> BCKi]

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

[0436] Continue Restore —> BCKi

[0437] 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 servers that have successfully verified the user's identity. It can optionally decide to subject the user to an additional identity verification procedure. The orchestrator can also be configured to analyze certainty scores regarding the verification of the user's identity, as described above, and make a decision based on this analysis.

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

[0439] RIO. Device certificate verification

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

[0441] Verif CD = CD

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

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

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

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

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

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

[0448] {Sl}kBlll{S2}kB2ll....ll{Si}kBill...ll{Sm}kBm -> HW'

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

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

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

[0452] {Si}'kBi

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

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

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

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

[0457] S = Fseed 1(S)Kseed

[0458] 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.:

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

[0460] {Fseed'(S^Kseed}'kBi

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

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

[0463] R14. Final confirmation

[0464] OK^ORCl

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

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

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

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

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

[0470] Cex = Pexll{Sign(px, Pex)

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

[0472] [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 sent by the servers BCKi backup, and vice versa, and therefore does not act as a gateway or "proxy server".

[0473] When the user initiates a seed backup step, the HW device sends a backup request BCKRQ to the OCR2 orchestrator, following which the ORC2 orchestrator initiates the previously described steps of generating a backup identifier BCKID and collecting information about the user to generate the backup data BCKDT. The orchestrator also conducts the initial IDVO step of verifying the user's identity. 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.

[0474] Each BCKPASSi authorization forms a sort of "passport" allowing the HW device to know which BCKi server it must address to save a part Si 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.

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

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

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

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

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

[0480] - a BAT battery;

[0481] - 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;

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

[0483] - 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;

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

[0485] 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 secure element SE1 also comprises an MSI memory space comprising a read-only memory area, an electrically erasable and programmable non-volatile memory area and a volatile memory area. The electrically erasable and programmable non-volatile memory area receives an operating system of the secure element. The latter is configured to allow the implementation of the method of the invention.

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

[0487] Tables 2 and 3 below and Figures 8 and 9 describe an example configuration of the HW device and the HSW companion software for implementing an embodiment of the method of the invention, in which three backup servers are used, the seed therefore being backed up by means of three shares. The HW device is used in association with the HDV host device to which it can be connected via its USB or Bluetooth interface. In addition to the TS1 touchscreen of the HW device, the HDV host device itself has a screen allowing the USR user to drive some steps of the process with the companion software, while other steps are carried out with the HW device.

[0488] In Tables 2 and 3, the bracketed text indicates virtual buttons that the user must press to select the desired option. The quoted text indicates information displayed by the HW device or HDV host device. The "xx" text indicates displayed areas or areas in which the user must provide the requested information.

[0489] Table 2 below and [Fig.8] describe the implementation of the method with regard to saving the seed. During a step DO, the companion software offers the user the choice between, on the one hand, saving his seed and, on the other hand, initializing or restoring the HW device. It is assumed here that the HW device has been previously put into service but that the user has never saved his seed. The latter therefore chooses the first option. During a step D1, the companion software offers two options to the user, namely a classic backup which will consist of the display of the recovery phrase by the HW device so that the user can save it on the medium of his choice, or a backup by calling on an automatic protection service implementing the method according to the invention. During a step D3, the user is invited to create an account on the client account server.In step D4, the user creates this account and provides information about his identity, at least part of which constitutes the information of his pivot identity incorporated in the data of the BCKDT backup. In step D5, he defines the password for his account.

[0490] During a step D6 the companion software reminds the user that he will have to undergo an identity verification step. This is the IDVO step which will allow the orchestrator to ensure that the information constituting his pivot identity is correct, in particular his first name, his last name and his date of birth. The IDVO step is carried out in steps D7 to D1 1 by means of the screen of the HDV host device, as well as its camera. Once the IDVO step has been successfully completed, the user must connect the HW device to the HDV host device in a step D12.

[0491] Then, the HW device takes care of the rest of the process by asking the user at a step D13 to enter his password, then at steps D14, D15 to verify his identity. The HW device then proceeds to save the seed at a step D16.

[0492] Table 3 below and [Fig.9] describe the seed restoration step. In step D0, the user chooses the Initialize / Restore option. In a step D20, the companion software asks the user to connect the HW device' to the HDV host device. In a step D21, the companion software and the HW' device confirm that the connection has been made. In a step D22, the user must enter the password of the HW' device. In a step D22, the HW' device asks the user whether he wants to initialize the HW' device as a new device or whether he wants to restore from a recovery phrase. The user chooses the "restore" option here. In a step D24, the HW' device asks the user whether he wants to restore the HW' device from the protection service according to the invention or from a recovery phrase that he would have kept (manual restoration). The user chooses the protection service.

[0493] During a step D25, the companion software takes charge of the rest of the process and informs the user that he will have to undergo three steps of verification of his identity. The first will be carried out with the HW' device and the other two will be carried out with IDV providers. During a step D26, the user must confirm the information displayed by the HW' device concerning his pivot identity (additional information to that forming the pivot identity may be displayed by the HW' device during this step, as seen in Table 3). During a step D27, the companion software indicates to the user that he will be put in contact with the first IDV partner and asks him to confirm his agreement. The user's agreement leads the companion software to connect with an IDVSRVi partner server, via its GTW gateway, as described above.During steps D28 to D32, the user performs the actions requested by the first IDV partner for acquiring the information necessary for the first identity verification, by means of the screen and the camera of the HDV host device. During a step D33, the companion software indicates to the user that he will be put in contact with the second IDV partner and asks him to confirm his agreement. The user's agreement leads the companion software to connect with another IDVSRVi partner server, via its GTW gateway. During steps summarized in the table by a single step D34, the user performs the actions requested by the second IDV partner for acquiring the information necessary for the second identity verification. These steps may be identical, similar or different from those of the first identity verification.It will be noted that the identity verification is not complete once these steps have been performed and that the result of each verification may not be provided to the user until a few hours or even days later, as explained above. When the user's identity has been verified, the HW' device retrieves the shares SI, S2, S3 of the seed and restores it during a step D35.

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

[0495] 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, a laptop, a mobile phone or the like. 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. 11] shows a software-type cryptoasset wallet CW3 executed by an electronic device DV which can be of the aforementioned type, computer, mobile phone or the like. The device DV comprises a microprocessor MPU equipped with a communication interface CINT2 allowing it to connect to the Internet, a volatile memory RAM and a non-volatile memory NVM, for example a magnetic hard disk or a solid-state hard disk (SSD).The CW3 program forming the software cryptoasset wallet is stored in the non-volatile memory NVM of the DV device and is executed by the MPU microprocessor using its RAM memory.

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

[0497] [Tab 2] Information displayed on the TS1 touchscreen of the HW device Information displayed by the HDV host device User actions USR DO [Backup] [Initialize / Restore] User selects "Backup" DI "Choose the type of protection for your recovery phrase": [Dl.l] [Display the recovery phrase on your device and back it up by yourself] [D1.2] [Automatic recovery phrase protection service] User selects [Automatic recovery phrase protection service] D2 "After creating your account and confirming your identity by one of our IDV partners, your recovery phrase will be securely linked to your identity.Your recovery phrase will be shared in three parts saved in a decentralized manner, and cannot be stolen from you" [Confirm your choice of protection service] Reading the information displayed then confirming the choice of protection service D3 Please create an account first: [Creating an account] Provides your agreement to the creation of the account D4 "Last name: " xx "First name xx "Date of birth xx "Nationality: "xx "Place of birth xx [Validate] "Email address xx [Validate] Provides the requested information, then validates. "Verification code received by email xx [Validate] D5 "Creating a strong password" "Enter your password: "xx" "Confirm password: "xx" [Validate] Provide the password and validate it D6 "Your account has been successfully created. You will now confirm your identity with our partner" [I agree] The user confirms their agreement to the verification of their identity D7 "Choose the type of identity document" [Passport] [Driver's license] [National identity card] [(Other choice)] Chooses the type of document D8 "Present your identity document in the frame" Executes step D9 "Verify the photo and validate its sending" [Send the photo] Verifies and validates the sending of the photo D10 "Place your face in the frame and start the video" [Start recording] Executes the proposed step DU "Verify the video then send it" [Send the video] Verifies the video then validates the sending D12 "Connect the device you want tosave recovery phrase " Connects the HW device to the host device D13 "Enter your PIN code: xx" [Validate] "Unlock your hardware wallet by entering your password (PIN code)" Provides his password D14 [Verify your identity before saving your recovery phrase] Agrees to 1 identity confirmation D15 "Last name, first name, date of birth, nationality, place of birth" Confirms the veracity of the information displayed [Confirm] D16 "Storing your recovery phrase" Waiting for the process to complete D17 "Your recovery phrase stored securely" "Account created: OK Confirming identity: OK Connecting your device: OK Saving your recovery phrase: OK" D18 "Your recovery phrase has been saved. Restore it to another device whenever needed" Table 3: Seed restoration, user-wallet interaction

[0498]

[0499] HW hardware and HDV host device [Tab 3] Information displayed on the HW device's TS1 touchscreen Information displayed on the HDV host device User actions U SR DO [Backup] [Initialize / Restore] User selects "Initialize / Restore" D20 "Pending" "Connect hardware wallet" Connects their device to the host device D21 "Connected" "Connected to your hardware wallet" D22 "Enter your PIN:"xx" "Enter a password (PIN) on your device" Sets their password D23 [D23.1] [New Device] [D23.2] [Restore with a recovery phrase] "How do you want to initialize your device? New Device or restore with a recovery phrase? Make your choice on your device's screen" Chooses the "restore" option D24 [D24.1] [Restore with Protection Service] "How do you want to restore your device? Make your choice on your device" Choose restore with protection service. [D24.2] [Manual restoration with a recovery phrase] D25 "We offer you the following steps: 1. Confirmation of your identity with your device 2. Verification of your identity by a first IDV partner 3. Verification of your identity by a second IDV partner" [I agree] Gives his agreement to the identity verification process proposed to him D26 (HW1 displays the information concerning the user's identity) "Last name xx "First name xx "Date of birth xx "Nationality xx "Place of birth xx "Email address: xx" [Validate] "1. Confirm your identity as displayed on your device" Confirms the information displayed by the device HW' D27 "2.Verification of your identity by our first IDV partner" [Confirm] Gives his agreement D28 "Choose the type of document" [Passport] [Driver's license] [National identity card] [(Other choice)] Chooses the type of document D29 "Present your identity document in the frame" Executes the proposed step D30 "Verify the photo and validate its sending" Verifies to validate the sending of the photo. [Sending photo] D31 "Place your face in the frame and start the video" [Start recording] Executes the proposed step D32 "Verify the video then send it" [Sending video] Verifies the video then validates sending the video D33 "2. Verification of your identity by our second IDV partner" [Confirm] Gives consent D34 (conducting the second identity verification process identical, similar or different from the first) Executes the steps D35 "Restoring your recovery phrase in progress" "1. Confirming your identity with your device: OK 2. Confirming your identity by our first IDV partner: OK 3. Confirming your identity by our second IDV partner: OK D36 Displays a menu "Your recovery phrase has been restored"

Claims

Claims

1. Method for backing up and restoring a seed (S) held by a cryptoasset hardware wallet (CW1, CW2, CW3, HW, HDV), comprising the steps of: - providing a plurality of backup servers (BCKi), - by means of the cryptoasset hardware wallet, generating a plurality of secret data (Si) from the seed (S), and - transferring (B 11, B12) to each backup server one of the secret data provided by the cryptoasset hardware wallet, wherein each secret data (Si) is transferred to a backup server in an encrypted form ({Si}kBi) by means of a session key (kBi) which is known only by the cryptoasset hardware wallet and the backup server for which it is intended, wherein the method also comprises an encryption step, by means of a seed encryption function (Fseed) and a seed encryption key (Kseed),of at least one of the secret data (Si) generated from the seed (S), before transferring it (B11, B12) to a backup server in an encrypted form ({Si}kBi) by means of a session key (kBi) which is known only by the cryptoasset hardware wallet and the backup server for which it is intended.,

2. The method of claim 1, wherein the step of encrypting at least one of the secret data comprises at least one of the following steps: - by means of the seed encryption function (Fseed) and the seed encryption key (Kseed), encrypting the seed before generating the plurality of secret data (Si) from the seed (S), - by means of the seed encryption function (Fseed) and the seed encryption key (Kseed), encrypting said at least one secret data (Si) before transferring it to a backup server.

3. Method according to one of claims 1 and 2, in which the seed encryption key (Kseed) is recorded in a non-volatile memory of the hardware wallet, during its personalization or during a subsequent update.

4. The method of claim 3, wherein the seed encryption key (Kseed) is common to a plurality of cryptoasset wallets.

5. Method according to one of claims 1 and 2, in which the seed encryption key (Kseed) is derived from a secret known to the user.

6. Method according to one of claims 1 to 5, further comprising steps of collecting (B3) information (BCKDT) relating to the identity of the user, communicating (B6) to each backup server the information (BCKDT) relating to the identity of the user, and associating each secret data with the identity of the user in each backup server.

7. The method of claim 6, wherein the user identity information comprises at least the user's first name, the user's last name, and the user's date of birth.

8. Method according to one of claims 1 to 7, in which the hardware wallet of cryptoassets is configured to generate a plurality of secret data (Si) by means of a secret sharing function (SS) provided to generate a number m of secret data from the seed (S) and allow the reconstitution of the seed (S) from a threshold of n secret data (Si).

9. Method according to one of claims 1 to 8, in which the cryptoasset hardware wallet (CW1) comprises a hardware wallet (HW) 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.

10. Method according to one of claims 1 to 9, comprising, for the restoration of the seed, the following steps: - communication (R3) to each backup server of the information (BCKDT) relating to the identity of the user, - reception (RI 1) by the hardware wallet of cryptoassets, in an encrypted form ({Si]kBi) by a session key, of all or part of the secret data (Si) held by the backup servers, - reconstitution (RI3) of the seed by the hardware wallet of cryptoassets from the secret data ({Si]kBi) provided by the backup servers and by means of an inverse function (Fseed-1) of the seed encryption function (Fseed).

11. Method according to one of claims 1 to 10, comprising the steps of: - providing an orchestrator program (ORC1) executed by a server (ORCSRV1), and - configuring the orchestrator program and the cryptoasset hardware wallet so that they execute at least one of the following steps: - when saving the seed, transfer to the orchestrator program by the cryptoasset hardware wallet of the secret data generated by the cryptoasset hardware wallet, and transfer (B 12) to the backup servers, by the orchestrator program of the secret data received from the cryptoasset hardware wallet, and - when restoring the seed, reception (RI 1) by the orchestrator program of all or part of the secret data held by the backup servers, and transfer (R 12) of these secret data to the cryptoasset hardware wallet by the orchestrator program.

12. Method according to claim 11, comprising the steps of: - establishing a first secure communication channel between the cryptoasset hardware wallet and the orchestrator program (ORC1), by means of a first session key (kO) generated after a key exchange (PD, PeD, PO, PeO) between the cryptoasset hardware wallet and the orchestrator program (ORC1), and - establishing a second secure communication channel between the cryptoasset hardware wallet and each backup server (BCKi) via the orchestrator program (ORC1), by means of a plurality of second session keys (kBi) generated after a key exchange (PD, PeD, PBi, PeBi) between the cryptoasset hardware wallet and each backup server (BCKi) via the orchestrator program (ORC1).

13. Method according to one of claims 1 to 12, in which before providing (RI 1) the secret data (Si) that it holds, at least one backup server subjects the user to a step of verifying his identity, and refuses to restore the secret data if the verification of the user's identity is not conclusive.

14. Hardware wallet of cryptoassets (CW1, HW, HDV, CW2, CW3) holding or intended to hold a seed (S), characterized in that it is configured to offer a user the following two options: - save the seed manually (D2.1) in the form of a recovery phrase which must be kept by the user, or - save the seed in a plurality of backup servers (D2.2), and, if the user chooses to save the seed in a plurality of backup servers: - generate a plurality of secret data (Si) from the seed (S), - transfer (B 12) each secret data to a backup server (BCKi), and - by means of a seed encryption function (Fseed) and a seed encryption key (Kseed), encrypt at least one of the secret data (Si) generated from the seed (S), before transferring it to a server backup.

15. Cryptoasset hardware wallet according to claim 14, configured to carry out the step of encrypting at least one of the secret data by executing at least one of the following steps: - by means of the seed encryption function (Fseed) and the seed encryption key (Kseed), encrypting the seed before generating the plurality of secret data (Si) from the seed (S), - by means of the seed encryption function (Fseed) and the seed encryption key (Kseed), encrypting said at least one secret data (Si) before transferring it (B11, B12) to a backup server.

16. Hardware cryptoasset wallet according to one of claims 14 and 15, configured to carry out a step of collecting (B3, D4, BCKID, D8-D11, D28-D32, D34) information relating to the identity of the user, in the presence of the user, and a step of communicating (B6, D9, DI 1, D30, D32) to each server for saving the information relating to the identity of the user.

17. Hardware cryptoasset wallet according to one of claims 14 to 16, configured to also offer the user the following options: - restoring the seed manually (D24.2) from a recovery phrase, or - restoring the seed from a plurality of backup servers (D24.2), and, if the user chooses to restore the seed from a plurality of secret data held by a plurality of backup servers, reconstituting (R13) the seed from the data provided by the backup servers and by means of an inverse function (Fseed-1) of the seed encryption function.

18. Hardware wallet of cryptoassets according to one of claims 14 to 17, configured to generate a plurality of secret data (Si) from the seed (S) by means of a secret sharing function (SS) provided to generate a number m of secret data and allow the reconstitution of the seed (S) from a threshold of n secret data (Si).

19. A hardware cryptoasset wallet according to claim 17, configured to, if the user chooses to restore the seed from the secret data, conduct at least one step of verifying the identity of the user at the request of a backup server.

20. Cryptoasset hardware wallet (CW1) according to one of claims 14 to 19, comprising a hardware wallet (HW) without means of connection to the Internet, and a host device (HDV) running companion software (HSW) and provided with a connection to the Internet, the companion software supplementing the hardware wallet (HW) for carrying out steps (Dl-D13, D20-D38) requiring interaction with the user, in particular steps of collecting information relating to the identity of the user.

Images