Method for establishing a secure data link between an electronic device and a server

Abstract

Method for establishing a secure data link between an electronic device (HW) and a server (ORC1), in which the server generates (B5.1) an ephemeral private key (peO), an ephemeral public key (PeO) and an ephemeral certificate (CeO) signed with its private key (pO), and transfers (B5.2) its ephemeral certificate to the device. The device generates (B5.4) an ephemeral private key (peD) and an ephemeral public key (PeD), a first signature of its ephemeral public key from its private key, a first session key (k0) from its ephemeral private key (peD) and the ephemeral public key (PeO) of the server, then encrypts (B5.4) the first signature using the first session key (k0), to obtain an encrypted signature, and transfers (B5.5) to the server an ephemeral certificate (CeD) comprising its ephemeral public key (PeD) and the encrypted signature. Figure for abstract: Fig. 4A

Description

Title of the invention: Method for establishing a secure data link between an electronic device and a server Technical field

[0001] The present invention relates to a method for backing up and restoring a secret held by an electronic device, and a method for securing the backup and restoration of a secret held by an electronic device. The present invention also relates to securing a secure data link between an electronic device and a server. The present invention relates in particular 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 in- . computer cannot access it.

[0003] This type of hardware wallet is therefore now considered the most secure solution against hacker attacks. Its only drawback is 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 an HDV host device running an app HSW companion application, for example the "Ledger Live" application developed by the applicant. Since the HW device cannot connect directly to the Internet, it is associated with the HDV host device to carry out transactions on the blockchain. The HDV host device is, for example, a computer, a mobile phone, a tablet or the like. The connection between the HW device and the HDV host device may 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 its problems. 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 recovery phrase in a highly secure manner. Summary

[0013] Embodiments relate to a method for establishing a secure data link between an electronic device and a server, wherein the server and the device each have a private key, a public key, a certificate signed by a certification authority, and a public key of the certification authority. According to the method, the device and the server are configured to perform the following steps: the server generates an ephemeral private key, an ephemeral public key, and an ephemeral certificate signed with its private key, and transfers its ephemeral certificate to the device; the device generates an ephemeral private key and an ephemeral public key; the device generates a first signature of its ephemeral public key from its private key; the device generates a first session key from its ephemeral private key and the the server's ephemeral public key; the device encrypts the first signature using the first session key, to obtain an encrypted signature; the device transfers to the server an ephemeral certificate comprising its ephemeral public key and the encrypted signature; the server generates the first session key from its ephemeral private key and the device's ephemeral public key, and using the first session key, the server decrypts the signature present in the ephemeral certificate.

[0014] According to one embodiment, the server transfers its certificate to the device, the device encrypts its own certificate with the first session key, the device transfers to the server its certificate encrypted with the first session key, and using the first session key, the server decrypts the certificate of the device.

[0015] According to one embodiment, before generating the first signature of its ephemeral public key, the device concatenates its ephemeral public key with a piece of data.

[0016] According to one embodiment, the device verifies the validity of the server's ephemeral certificate using the server's certificate, the device verifies the validity of the server's certificate using the certification authority's public key, the server verifies the validity of the device's ephemeral certificate using the device's certificate, and the server verifies the validity of the device's certificate using the certification public key.

[0017] According to one embodiment, the device comprises a hardware wallet of cryptoassets comprising a main secret data, or master key.

[0018] According to one embodiment, the hardware wallet is devoid of means of connection to the Internet and is configured to be connected to the server via a host device running companion software and provided with a connection to the Internet.

[0019] Embodiments also relate to a method for backing up a plurality of secret data held by a cryptoasset wallet, the secret data being stored by the cryptoasset wallet or being able to be generated by the cryptoasset wallet from a master secret data held by the cryptoasset wallet, the cryptoasset wallet being owned by a user, the method comprising the steps of providing an orchestrator program executed by a server to implement and supervise the backup of the data and providing a plurality of backup servers, and wherein the orchestrator program is configured to establish a secure data link with the cryptoasset wallet in accordance with the method just described, communicate to each backup server information relating to the identity of the user,receive the data to be backed up from the cryptoasset wallet, and transfer one of the data to be backed up to each backup server.

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

[0021] According to one embodiment, each backup server has a private key, a public key, a certificate signed by the certification authority, and the public key of the certification authority, each backup server transfers its certificate to the orchestrator program, which transfers it to the cryptoasset wallet, each backup server generates an ephemeral private key, an ephemeral public key and an ephemeral certificate signed with its private key, and transfers the ephemeral certificate to the orchestrator program which transfers it to the cryptoasset wallet, the cryptoasset wallet transfers its certificate and its ephemeral certificate to the orchestrator program, which transfers it to each of the backup servers, each backup server generates a second session key from its ephemeral private key and the ephemeral public key of the cryptoasset wallet,the cryptoasset wallet generates the second session key of each backup server from its ephemeral private key and the ephemeral public key of the backup server, the cryptoasset wallet encrypts the data intended for each backup server with the second session key, transfers it to the orchestrator which transfers it to the backup server, and each backup server decrypts the received data using the second session key, and stores it in a memory.

[0022] According to one embodiment, each backup server verifies the validity of the certificate of the cryptoasset wallet using the public certification key, each backup server verifies the validity of the ephemeral certificate of the cryptoasset wallet using the certificate of the cryptoasset wallet, the cryptoasset wallet verifies the validity of the certificate of each backup server using the public certification key, and the cryptoasset wallet verifies the validity of the ephemeral certificate of each backup server using the certificate of each server.

[0023] According to one embodiment, data for the cryptoasset portfolio transmitted to the orchestrator program by a backup server are transmitted by the orchestrator program to the cryptoasset portfolio in an encrypted form using the first session key, and in which some of this data is previously hashed by the backup server using a hash function, then encrypted using the second session key.

[0024] According to one embodiment, the method comprises an initial step of verifying the identity of the user by the orchestrator program, and the orchestrator program is configured to not allow the backup of the data in the backup servers if the identity verification is not conclusive.

[0025] According to one embodiment, the cryptoasset wallet is configured to generating the plurality of secret data from the master key using a secret sharing function configured to generate a number m of secret data and allow the reconstitution of the master key from a threshold of n secret data.

[0026] According to one embodiment, m is equal to 3 and n is equal to 2.

[0027] According to one embodiment, the method comprises a step of restoring all or part of the secret data in a second cryptoasset wallet, the restoration step being preceded by steps of recovering all or part of the secret data in the backup servers via the or-chestrator program, and the steps of recovering the secret data in the backup servers are preceded by a plurality of steps of verifying the identity of the user by at least some of the backup servers, a backup server configured to verify the identity of the user also being configured to refuse to return the secret data that it holds if the verification of the identity of the user is not conclusive

[0028] According to one embodiment, at least one backup server is configured to delegate the identity verification step to a server specialized in identity verification, the backup server being configured to establish a data link with the specialized server in order to put the user in contact with this server.

[0029] Embodiments also relate to a method for backing up and restoring a secret held by a first cryptoasset wallet that is owned by a user, the method comprising the steps of generating, by means of the cryptoasset wallet, a plurality of secret data from the secret, backing up the secret data in a plurality of backup servers, each backup server receiving at least one secret data, restoring the secret in a second cryptoasset wallet from all or part of the secret data held by the backup servers.According to the method, the step of saving the secret data is preceded by an initial step of collecting information relating to the identity of the user, and a step of communicating, to each backup server, the information relating to the identity of the user, and the restoration step is preceded by a plurality of steps of verifying the identity of the user by at least some of the backup servers, a backup server configured to verify the identity of the user also being configured to refuse to restore the secret data that it holds if the verification of the identity of the user is not conclusive.

[0030] According to one embodiment, the method also comprises, after the initial step of collecting information relating to the identity of the user, a step of verifying the identity of the user.

[0031] According to one embodiment, the step of saving the secret data is not carried out if the initial verification of the identity of the user is not conclusive.

[0032] According to one embodiment, the user identity information defines a pivot identity of the user which comprises at least the user's first name, the user's last name and the user's date of birth, and in which at least one user identity verification step relates to the verification of his pivot identity.

[0033] According to one embodiment, at least one step of verifying the identity of the user is carried out by an identity verification server, the step of verifying the identity of the user comprising a step of creating a data path between the cryptoasset wallet and the identity verification server, for communicating to the identity verification server information collected by the cryptoasset wallet.

[0034] According to one embodiment, the restoration step comprises, in relation to the restoration of at least two secret data by two backup servers, at least two different user identity verification steps, and wherein two different user identity verification steps are based on different information provided by the user, and / or on different methods for collecting the information provided by the user, and / or on different methods or algorithms for analyzing the information provided by the user.

[0035] According to one embodiment, a step of verifying the identity of the user comprises a step of acquiring at least one photograph or video of the user and / or an identity document of the user.

[0036] According to one embodiment, steps of verifying the identity of the user are conducted by services executed by servers and comprise automated steps of verifying the identity comprising steps of remotely acquiring information from which the identity of the user is verified, the steps of remotely acquiring information comprising at least two of the following steps: acquiring a photo of an identity document comprising a photo of the user, acquiring one or more photos of the user's face, acquiring a video recording showing the user's face in motion, acquiring proof of address, acquiring a fingerprint of the user, acquiring a validation code received by the user in a message, activating by the user a link received by the user in a message,and acquisition of a hologram present on an identity document.

[0037] According to one embodiment, the method comprises, when the automated steps of verifying the identity of the user are not conclusive, steps of verifying identification of the user's identity conducted by natural persons, 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 background or employment history.

[0038] According to one embodiment, the method comprises providing an orchestrator program executed by a server, the first or second cryptoasset wallet being configured to establish a data link with the orchestrator program before performing the backup or restoration step, the orchestrator program being configured to conduct or control at least one step of collecting information relating to the identity of the user.

[0039] According to one embodiment, the orchestrator program is configured to, during the restoration of the data, receive from each backup server configured to conduct a verification of the identity of the user information on the success of the identity verification conducted by the backup server, and if a determined number of backup servers have not successfully verified the identity of the user, suspend the data restoration process as a whole, including by the servers which have successfully verified the identity of the user, and optionally subject the user to an additional step of verifying his identity.

[0040] According to one embodiment, the orchestrator program is also configured to receive from each backup server, during the restoration of the data, a certainty score regarding verification of the identity of the user, and if the average of the scores is less than a first threshold, or if one of the scores is less than a second threshold, suspend the data restoration process as a whole and optionally subject the user to an additional step of verifying his identity.

[0041] According to one embodiment, the first cryptoasset wallet is configured to, after having received the authorization to save the secret data, establish with each backup server a data link by which it provides each server with the secret data intended for it.

[0042] According to one embodiment, the first cryptoasset wallet is configured to generate the plurality of secret data from the master key by means of a secret sharing function configured to generate a number m of secret data and allow the reconstitution of the seed from a threshold of n secret data, and the second cryptoasset wallet is configured to reconstitute the master key from at least n secret data received during the restoration step.

[0043] According to one embodiment, the first and second cryptoasset wallets each comprise a hardware wallet without means of connection to the Internet and a host device with an Internet connection and running companion software.

[0044] According to one embodiment, the method is implemented with three backup servers and using a secret sharing function configured to generate m secret data from the secret and allow the reconstitution of the secret from at least n secret data, n being less than m. Summary description of the drawings

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

[0046] - the previously described [Fig.l] schematically shows a crypto wallet assets and an example of its use,

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

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

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

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

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

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

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

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

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

[0056] - [Fig.9] shows steps conducted by the user of the hardware wallet of the [Fig.7] for the restoration of the seed,

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

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

[0059] 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 a 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.

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

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

[0062] 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 of 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 If:

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

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

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

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

[0067] pL: private key of the certification authority

[0068] PL: public key of the certification authority

[0069] pD: private key of the HW device

[0070] PD: public key of the HW device

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

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

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

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

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

[0076] The CA certification authority is preferably owned by the manufacturer of the HW device, to allow it to control the allocation of CBi certificates to the BCKi backup servers. The BCKi backup servers may be owned 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 care of the cryptographic calculations carried out using these keys. In the following and for the sake of simplification of the language, we will consider that such cryptographic calculations are carried out by the servers themselves.

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

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

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

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

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

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

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

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

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

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

[0087] kBi = ECDH(peBi, PeD)

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

[0089] kBi = ECDH(peD, PeBi)

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

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

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

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

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

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

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

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

[0098] [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, called, without limitation, "orchestrator server", executes a back-end program or "back-end" ORC1 called in the following "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:

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

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

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

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

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

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

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

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

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

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

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

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

[0111] kO = ECDH(peO, PeD)

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

[0113] kO = ECDH(peD, PeO)

[0114] Once the secure channel is created between the orchestrator and the HW device, data to The attention of 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.

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

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

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

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

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

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

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

[0122] 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 CeO ephemeral certificate to the device as well as its CO certificate:

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

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

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

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

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

[0128] {CD}k0

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

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

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

[0132] {CD}k0 II CeD

[0133] either

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

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

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

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

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

[0139] 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. Orchestrator prediction has various other advantages that will be described later in relation to the implementation of user identity verification steps.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0157] 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 part by means of the new session key kBi,

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

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

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

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

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

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

[0164] If = {If} 'kBi

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

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

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

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

[0169] 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 0RC1 orchestrator. The orchestrator transfers the BCKID identifier to the UASRV server at the time of backup and reciprocally receives the BCKID identifier from the UASRV server when the user wants to restore his seed.

[0170] 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 several backups, if they hold several hardware wallets).

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

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

[0173] In an embodiment shown in [Fig.3B], these identity verification steps are entrusted to specialized service providers instead of being performed 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. Each BCKi backup server may be assigned a different IDVSRVi server, and be configured to connect to the GTW gateway of the IDVSi service executed by this server. Preferably, such IDVSi services are not fully automated, at least for some of them. them, and include human intervention, particularly in the event of doubt about a person's identity.

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

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

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

[0177] Although the IDVO step is not as critical as those performed by the BCKi servers at the time of restitution of the Si shares, it makes it possible to ensure that the user has not made a mistake in providing the information relating to his identity, which is incorporated in 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 by a specific communication channel, since these information is not part of the BCKDT backup data.

[0178] In one embodiment, the orchestrator ORC1 can 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 servers BCKi have not successfully verified the identity of the user and refuse to return the shares Si that they hold, the orchestrator can be configured to suspend the return of the shares Si by the servers that have successfully verified the identity of the user. The orchestrator can optionally decide to subject the user to an additional step of verifying his identity.

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

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

[0181] It will be clear to those skilled in the art that the method of the invention is susceptible to various other embodiments and variants. In particular, the data of the BCKID backup could, in one embodiment, include in a compressed form the data collected in step IDV0 to verify the pivot identity of the user, such as the photo or video of his face and a photo of a roomidentity. The automated steps for verifying the pivotal identity of the user as conducted by IDVSi services executed by IDVSRVi servers or by the BCKi backup servers themselves, may include at least two of the following steps: acquisition, via a camera, of a photo of an unexpired identity document including 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 live detection 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.;

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

[0183] - the user USR,

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

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

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

[0187] - BCKi backup servers, and

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

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

[0190] [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 SHA-256 hash function ("Secure Hash Algorithm") Symmetric encryption {.}k0 Algorithm AEAD-AES-SIV-CMAC-256 SS function Shamir Secret Sharing function or other similar function, or Pedersen PVSS publicly verifiable secret sharing based on the curve secp384rl

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

[0192] Bl. Initializing the backup

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

[0194] [HW -> ORC1]

[0195] BCKRQ

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

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

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

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

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

[0201] [IDVSRV0] IDV0

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

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

[0204] IDV_OK -> HW

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

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

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

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

[0209] Sign(pO, ReOIIPeO)

[0210] CeO = PeOIISign (pO, ReOIIPeO)

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

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

[0213] CeOIICO -> HW

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

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

[0216] Verif CeO, Verif CO

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

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

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

[0220] kO = ECDH(peD, PeO)

[0221] Sign(pD, ReDIIPeD)

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

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

[0224] {CD}k0

[0225] 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 key ephemeral public key PeO of the orchestrator using the ECDH algorithm. The HW device then calculates the signature of its ephemeral public key PeD using its private key pD, here after concatenating the ephemeral public key PeD with a ReD data. The ReD data 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.

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

[0227] [HW -> ORC1]

[0228] CeDII{CD]kO

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

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

[0231] kO = ECDH(peO, PeD)

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

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

[0234] CD={CD}1k0

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

[0236] Verif CeD, Verif CD

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

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

[0239] [ORC1 -> BCKi]

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

[0241] BCKIDIlBCKDTIlCeDIlCD

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

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

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

[0245] Verif CeD, Verif CD

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

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

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

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

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

[0251] Sign(pBi, ReBIIPeBi)

[0252] CeBi = PeBillSign (pBi, ReBIIPeBi)

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

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

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

[0256] kBi = ECDH(peBi, PeD)

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

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

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

[0260] Hi = Hash(PeBillBCKIDIIBCKDT)

[0261] CHi = {Hi]kBi

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

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

[0264] [BCKi -> ORC1]

[0265] RETDTi = CeBillCBillCHi

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

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

[0268] [ORC1 -> HW]

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

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

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

[0272] {BCKIDIIBCKDTIIRETDTll...llRETDTill...llRETDTm} >k0

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

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

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

[0276] Validate BCKDT, BCKi

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

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

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

[0280] Verif CeBi, Verif CBi

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

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

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

[0284] kBi = ECDH(peD, PeBi)

[0285] {Hi} *kBi

[0286] Validate Hi

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

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

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

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

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

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

[0293] {Si]kBi

[0294] For each BCKi server, the HW device encrypts the part Si intended for it with its own key kBi.

[0295] B11. Sending encrypted shares to the orchestrator

[0296] [HW -> ORC1]

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

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

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

[0300] [ORC1 -> BCKi]

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

[0302] BCKIDII{Si]kBi -> BCKi

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

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

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

[0306] {Si} 'kBi -> STORE

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

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

[0309] [BCKi -> ORC1] OKi

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

[0311] B15. Confirmation of backup to the user

[0312] [ORC1 —> HW]

[0313] OK

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

[0315] At the end of the process:

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

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

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

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

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

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

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

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

[0324] RL Device sends a restore request to the orchestrator

[0325] HW' -> ORC1

[0326] RESTRQ[BCKID]

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

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

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

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

[0331] Sign(pO, ReOIIPeO)

[0332] CeO = PeOIISign (pO, ReOIIPeO)

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

[0334] ORC1 -> HW'

[0335] CeOIICO

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

[0337] Verif CeO, Verif CO

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

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

[0340] kO = ECDH(peD, PeO)

[0341] Sign(pD, ReDIIPeD)

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

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

[0344] {CD}k0

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

[0346] [HW' -> ORC1]

[0347] CeDII{CD}k0

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

[0349] kO = ECDH(peO, PeD)

[0350] CD={CD]*k0

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

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

[0353] Verif CeD, Verif CD

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

[0355] [ORC1 -> BCKi]

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

[0357] BCKIDIlCeDIlCD -> BCKi

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

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

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

[0361] Verif CeD, Verif CD

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

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

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

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

[0366] Sign(pBi, ReBIIPeBi)

[0367] CeBi = PeBillSign (pBi, ReBIIPeBi)

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

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

[0370] kBi = ECDH(peBi, PeD)

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

[0372] Hi = Hash(PeBillBCKIDIIBCKDT)

[0373] CHi = {Hi]kBi

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

[0375] [BCKi -> ORC1]

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

[0377] RETDTi = CeBillCBillCHi

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

[0379] [ORC1 -> HW']

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

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

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

[0383] R5.7 User validation of backup data

[0384] Validate BCKDT

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

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

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

[0388] Verif CeBi, Verif CBi

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

[0390] For each BCKi server, i ranging from 1 to m [0391 ] kBi = ECDH(peD, PeBi)

[0392] {Hi} *kBi

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

[0394] R6. Preparation of restoration

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

[0396] [HW-> ORC1]

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

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

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

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

[0401] BCKIDII{ConfirmRestorei}kBi -> BCKi

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

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

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

[0405] {ConfirmRestorei} 'kBi

[0406] CD Store

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

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

[0409] [BCKi^ ORC1]

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

[0411] OK_for_IDV

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

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

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

[0415] IDVRi

[0416] 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 verifying the user's identity, then confirms to the 0RC1 orchestrator that their identity has been verified and that the seed backup step can be initiated.

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

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

[0419] [HW' -> ORC1]

[0420] Continue Restore

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

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

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

[0424] R9. Resumption of restoration

[0425] [ORC1 -> BCKi]

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

[0427] Continue Restore —> BCKi

[0428] Once the secure channels are reopened using new session keys, the orchestrator relays to the BCKi servers the request to continue the restoration. It will be noted that if during the IDVRi steps one of the BCKi servers has not been able to verify the identity of the user with a determined degree of certainty, it will refuse to return the share it holds and will inform the ORC1 orchestrator. If a determined number of BCKi backup servers have not successfully verified the identity of the user and refuse to return the data they hold, the orchestrator can be configured to suspend the return of shares by the servers that have successfully verified the identity of the user. It can optionally decide to subject the user to an additional procedure for verifying his identity.The orchestrator can also be configured to analyze certainty scores regarding user identity verification, as discussed above, and make a decision based on that analysis.

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

[0430] RIO. Device certificate verification

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

[0432] Verif CD = CD

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

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

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

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

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

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

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

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

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

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

[0443] {Si}'kBi

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

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

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

[0447] R14. Final confirmation

[0448] OK^ORCl

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

[0450] 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: [0451 ] Cx = [Px, Sign(pL, Px)]

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

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

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

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

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

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

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

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

[0460] The role of IDVi stage supervisor which was previously assigned to The 0RC1 orchestrator can also be assigned here to the 0RC2 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 0RC2 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.

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

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

[0463] [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 from the . ST33K series. The HW device also includes various peripherals controlled by the MCU1 microcontroller, for example:

[0464] - a BAT battery;

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

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

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

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

[0469] 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 a memory space MS 1 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.

[0470] 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 3.9 inches (9.906 cm) and offers 670 x 496 pixels, which is a very large screen for a crypto asset hardware wallet without internet connectivity.

[0471] Tables 2 and 3 below and figures 8 and 9 describe an example of 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 touch screen TS1 of the HW device, the HDV host device itself comprises a screen allowing the user USR to conduct with the companion software, certain steps of the method while other steps are carried out with the HW device.

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

[0473] Table 2 below and [Fig.8] describe the implementation of the method with regard to saving the seed. During a step D0, 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.

[0474] During a step D6 the companion software reminds the user that he will have to undergo an identity verification step. This is the IDV0 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 IDV0 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 IDV0 step has been successfully completed, the user must connect the HW device to the HDV host device in a step D12.

[0475] 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 DI6.

[0476] Table 3 below and [Fig.9] describe the seed restore step. In step DO, 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 to specify whether he wants to initialize the HW' device as a new device or whether he wants to restore from a recovery phrase. Here, the user chooses the "restore" option.During 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.

[0477] 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 the acquisition of 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 the acquisition of the information necessary for the . second identity verification. These steps may be the same, similar, or different from those of the first identity verification. It should 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.

[0478] 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 wifi and / or Ethernet connectivity and allowing it to connect to the Internet. The secure microcontroller uses two virtual processors associated with hardware access control, making it possible to manage two zones TZ, NTZ for executing applications offering different degrees of security, the zone TZ being called the "Trust Zone".The secure microcontroller may, in some embodiments, be equipped with a secure element SE2 coupled to the trusted zone TZ to perform cryptographic calculations and conduct the most security-sensitive operations, including storing the seed and various keys of cryptoasset accounts. Each zone can operate independently of the other while using the same kernel. Typically, the microcontroller runs a so-called "rich" operating system in the less trusted zone NTZ, for example Android, and specialized code in the trusted zone TZ. Such a device is equivalent to the combination of the hardware wallet HW (equivalent to the trusted zone) and the host device HDV (equivalent to the less secure zone) described in the above, and does not need to be connected to a host device to execute operations on the blockchain.

[0479] 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, volatile RAM and non-volatile NVM memory, for example a magnetic hard disk or a solid-state drive (SSD). The CW3 program forming the software cryptoasset wallet is stored in the non-volatile NVM memory of the DV device and is executed by the MPU microprocessor using its RAM memory.

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

[0481] [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] "Verification code received by email xx [Validate] Provide the requested information, then validate D5 "Create a strong password" "Enter your password: "xx" "Confirm the 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 verify 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 Connect the . want to save the recovery phrase " HW device to host device D13 "Enter your PIN code: xx" [Validate] "Unlock your hardware wallet by entering your personal password (PIN code)" Provides its password D14 [Verify your identity before saving your recovery phrase] Agrees to the identity confirmation D15 "Last name, first name, date of birth, nationality, place of birth" [Confirm] Confirms the veracity of the displayed information D16 "Storing your recovery phrase" Waits for the process to complete D17 "Your recovery phrase stored securely" "Account created: OK Identity confirmation: OK Connecting your device: OK Saving your recovery phrase: OK" D18 "Your recovery phrase has been saved. Restore it to another device whenever necessary"

[0482] Table 3: Seed restoration, interaction between user and HW' hardware wallet and HDV host device

[0483] [Tab 3] Information displayed on the HW device's TS1 touchscreen Information displayed on the HDV host device User actions USR DO [Backup] [Initialize / Restore] User selects "Initialize / Restore" D20 "Waiting" "Connect Hardware Wallet" Connects your 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 your password D23 [D23.1] [New Device] [D23.2] [Restore with Recovery Phrase] "How do you want to initialize your device? New Device or Restore with Recovery Phrase? Make your choice on your device screen" Chooses the "restore" option D24 [D24.1] [Restore with Protection Service] [D24.2] [Manual Restore with Recovery Phrase] "How do you want to restore your device? Make your choice on your device" Choose restoration with the D25 protection service "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] Agrees to the identity verification process offered to him D26 (HW1 displays information regarding the user's identity) "Last Name xx "First Name xx "Date of Birth xx "1. Confirm your identity as displayed on your device" Confirms the information displayed by the HW device. "Nationality xx "Place of birth xx "Email address: xx" [Validate] D27 "2. Verification of your identity by our first IDV partner" [Confirm] Gives consent 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" [Sending the photo] Verifies to validate the sending of the 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 the video] Verifies the video then validates the sending of 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) Performs steps D35 "Restoring your "1.Confirmation of your . recovery phrase in progress" identity with your device: OK 2. Confirmation of your identity by our first IDV partner: OK 3. Confirmation of your identity by our second IDV partner: OK D36 Displays a menu "Your recovery phrase has been restored"

Claims

Claims

1. Method for establishing a secure data link (LNK1) between an electronic device (CW1, HW, HDV, CW2, DV, CW3) and a server (0RC1), in which the server and the device each have a private key (pO, pD), a public key (PO, PD), a certificate (CO, CD) signed by a certification authority (CA), and a public key (PL) of the certification authority, method characterized in that the device and the server are configured to perform the following steps - the server generates (B5.1) an ephemeral private key (peO), an ephemeral public key (PeO) and an ephemeral certificate (CeO) signed with its private key (pO), and transfers (B5.2) its ephemeral certificate to the device, - the device generates (B5.4) an ephemeral private key (peD) and an ephemeral public key (PeD) - the device generates (B5.4) a first signature of its ephemeral public key (PeD) from its private key (pD), - the device generates (B5.4) a first session key (kO) from its ephemeral private key (peD) and the ephemeral public key (PeO) of the server, - the device encrypts (B5.4) the first signature using the first session key (kO), to obtain an encrypted signature, - the device transfers (B5.5) to the server an ephemeral certificate (CeD) comprising its ephemeral public key (PeD) and the encrypted signature, - the server generates (B5.6) the first session key (kO) from its ephemeral private key (peO) and the ephemeral public key (PeD) of the device, and - using the first session key (kO), the server decrypts (B5.7) the signature present in the ephemeral certificate (CeD).

2. Method according to claim 1, wherein: - the server transfers (B5.2) its certificate (CO) to the device, - the device encrypts (B5.4) its own certificate (CD) with the first session key, - the device transfers (B5.5) to the server its certificate (CD) encrypted with the first session key, and - by means of the first session key (kO), the server decrypts (B5.7) the certificate (CD) of the device.

3. Method according to one of claims 1 and 2 in which, before generate the first signature of its ephemeral public key (PeD), the device concatenates (B5.4) its ephemeral public key (PeD) with a data (ReD).

4. Method according to one of claims 2 and 3, in which: - the device verifies (B5.3) the validity of the ephemeral certificate (CeO) of the server (0RC1) by means of the certificate (CO) of the server, - the device verifies (B5.3) the validity of the certificate (CO) of the server (0RC1) by means of the public key (PL) of the certification authority, - the server (0RC1) verifies (B5.7) the validity of the ephemeral certificate (CeD) of the device by means of the certificate (CD) of the device, and - the server verifies (B5.7) the validity of the certificate (CD) of the device by means of the public certification key (CL).

5. Method according to one of claims 1 to 4 in which the device (CW1) comprises a hardware wallet of cryptoassets (HW) comprising a main secret data (S), or master key.

6. Method according to claim 5, wherein the hardware wallet (HW) is devoid of means of connection to the Internet and is configured to be connected to the server via a host device (HDV) running companion software (HSW) and provided with a connection to the Internet.

7. Method for backing up a plurality of secret data (Si) held by a cryptoasset wallet (CW1, HW, HDV, CW2, DV), the secret data being stored by the cryptoasset wallet or being able to be generated by the cryptoasset wallet from a master secret data (S) held by the cryptoasset wallet, the cryptoasset wallet being owned by a user (USR), the method comprising the steps of: - providing an orchestrator program (0RC1) executed by a server (0RCSRV1) to implement and supervise the backup of the data, and - providing a plurality of backup servers (BCKSRVi), and wherein the orchestrator program is configured to: - establish a secure data link (LNK1) with the cryptoasset wallet in accordance with the method according to one of claims 1 to 6,- communicate (B6) to each backup server information (BCKDT) relating to the identity of the user, - receive (B 11) from the cryptoasset wallet the data to be backed up ({Si]kBi), and - transfer (B 12) to each backup server one of the data (Si) to be backed up.

8. The method of claim 7, 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.

9. Method according to one of claims 7 and 8, in which: - each backup server (BCKSRVi) has a private key (pO, pD, pBi), a public key (PO, PD, PBi), a certificate (CO, CD, CBi) signed by the certification authority (CA), and the public key (PL) of the certification authority, - each backup server transfers (B8.4) its certificate (CBi) to the orchestrator program, which transfers it (B8.5) to the cryptoasset wallet, - each backup server generates (B8.1) an ephemeral private key (peBi), an ephemeral public key (PeBi) and an ephemeral certificate (CeBi) signed with its private key (pBi), and transfers (B8.4) the ephemeral certificate to the orchestrator program which transfers it (B8.5) to the cryptoasset wallet, - the cryptoasset wallet transfers (B5.5) its certificate (CD) and its ephemeral certificate (CeD) to the orchestrator program, which transfers it (B6) to each of the backup servers (BCKi), - each backup server generates a second session key (kBi) from its ephemeral private key (peBi) and the ephemeral public key (PeD) of the cryptoasset wallet, - the cryptoasset wallet generates the second session key (kBi) of each backup server from its ephemeral private key (peD) and the ephemeral public key (PeBi) of the backup server, - the cryptoasset wallet encrypts (B 10) the data intended for each backup server with the second session key (kBi), transfers it (B11) to the orchestrator which transfers it (B 12) to the backup server, and - each backup server decrypts (B 13) using the second session key (kBi) the data (Si) received, and stores in a memory (MEM).

10. A method according to claim 9, wherein: - each backup server verifies (B7) the validity of the certificate (CD) of the cryptoasset wallet using the public certification key (CL), - each backup server verifies (B7) the validity of the ephemeral certificate (CeD) of the cryptoasset wallet using the certificate (CD) of the cryptoasset wallet, - the cryptoasset wallet verifies (B8.8) the validity of the certificate (CBi) of each backup server (CBi) using the public certification key (CL), and - the cryptoasset wallet verifies (B8.8) the validity of the ephemeral certificate (CeBi) of each backup server using the certificate (CBi) of each server.

11. Method according to one of claims 9 and 10, in which data for the cryptoasset portfolio transmitted to the orchestrator program by a backup server are transmitted (8.5) by the orchestrator program to the cryptoasset portfolio in an encrypted form using the first session key (kO), and in which some of this data (RETDTi) are previously hashed (B8.3) by the backup server using a hash function, then encrypted (B8.3) using the second session key (kBi).

12. Method according to one of claims 7 to 11, comprising an initial step (B3, IDVO) of verifying the identity of the user by the orchestrator program, and in which the orchestrator program is configured not to allow the backup of the data (Si) in the backup servers if the identity verification is not conclusive.

13. Method according to one of claims 7 to 12 in which the cryptoasset wallet (CW1, CW3, DV, CW3) is configured to generate the plurality of secret data (Si) from the master key (S) by means of a secret sharing function configured to generate a number m of secret data and allow the reconstitution of the master key (S) from a threshold of n secret data (Si).

14. The method of claim 13, wherein m is 3 and n is 2.

15. Method according to one of claims 1 to 14, comprising a step (RI 1) of restoring all or part of the secret data in a second cryptoasset wallet (CW1, HW'), the restoration step being preceded by steps (RI 1-R 12) of recovering all or part of the secret data in the backup servers by through the orchestrator program, and in which the steps (R11-R12) of recovering the secret data from the backup servers are preceded by a plurality of steps (R7, IDVi) of verifying the identity of the user by at least some of the backup servers (BCKSRVi), a backup server configured to verify the identity of the user also being configured to refuse to restore the secret data that it holds if the verification of the identity of the user is not conclusive

16. Method according to claim 15, in which at least one backup server (BCKSRVi) is configured to delegate the identity verification step to a server (IDVSRVi) specialized in identity verification, the backup server being configured to establish a data link with the specialized server (IDVSRVi) in order to put the user in contact with this server (IDVSRVi).

Images