EP4639835A1 - Procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur - Google Patents

Procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur

Info

Publication number
EP4639835A1
EP4639835A1 EP23844173.7A EP23844173A EP4639835A1 EP 4639835 A1 EP4639835 A1 EP 4639835A1 EP 23844173 A EP23844173 A EP 23844173A EP 4639835 A1 EP4639835 A1 EP 4639835A1
Authority
EP
European Patent Office
Prior art keywords
server
ephemeral
certificate
backup
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23844173.7A
Other languages
German (de)
English (en)
Inventor
Laurent Castillo
Andrianina Sandra RASOAMIARAMANANA
Daniel ROCHA FURTADO
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR2214387A external-priority patent/FR3144465B1/fr
Priority claimed from FR2214391A external-priority patent/FR3144471B1/fr
Priority claimed from FR2214386A external-priority patent/FR3144463B1/fr
Application filed by Individual filed Critical Individual
Publication of EP4639835A1 publication Critical patent/EP4639835A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the present invention relates to a method for backing up and restoring a secret held by an electronic device, and to 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.
  • NFTs non-tangible tokens
  • Smart Contracts Smart Contracts
  • a cryptoasset wallet is a hardware or software device whose function is to store private and public keys attached to cryptoasset accounts, and to sign transactions using these keys.
  • hot wallets and so-called cold wallets.
  • Hot Hot wallets are connected to the Internet and susceptible to hacker attacks or exposure to viruses and malware.
  • 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 attacks. “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 calculation means. Transactions involving private keys are signed in an offline environment. Any transaction made online is temporarily transferred to the hardware wallet to be digitally signed offline, before the signature is transmitted to the online network. Since private keys are not communicated to online servers during the signing process, a hacker cannot access them.
  • Such a type of hardware wallet is therefore today considered the safest solution against hacker attacks. Its only drawback lies in the risk of loss, theft or destruction (fire for example) 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.
  • the BIP39 standard also provides for expressing the seed, which is a long binary number, in the form of a mnemonic phrase also called "recovery phrase”. sentence").
  • 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.
  • a hardware wallet For generating a recovery phrase, a hardware wallet generates a sequence of 256 random bits using a random number generator. The first 8 bits of an 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 only requires a single backup of the seed, preferably at the time of its commissioning, from which it is possible to derive the entire descending tree of keys.
  • FIG 1 schematically shows a portfolio of cryptoassets comprising an HW hardware wallet, for example the device marketed by the applicant under the name "Nano” or “Stax”, and an HDV host device running a HSW companion application, for example the “Ledger Live” application developed by the applicant.
  • 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 can be USB or Bluetooth for example.
  • 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”) 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 verification of the authenticity of the HW device, its commissioning, updating of its operating system, downloading of certified application programs, etc.
  • the HW device When the HW device is first put into service, it provides the user with a 24-word recovery phrase which the user must keep on an appropriate physical medium, for example a sheet of paper or an unalterable medium such as a engraved metal plate, which he must keep in a safe place.
  • an appropriate physical medium for example a sheet of paper or an unalterable medium such as a engraved metal plate, which he must keep in a safe place.
  • 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 certificate authority.
  • the device and the server are configured to execute 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 ephemeral public key of the server; 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 ephemeral public key of the device, and using the first session key, the server decrypts the signature present in the ephemer
  • the server transfers its certificate to the device, the device encrypts its own certificate with the first session key, the device transfers its certificate to the server certificate encrypted with the first session key, and using the first session key, the server decrypts the certificate of the device.
  • the device before generating the first signature of its ephemeral public key, the device concatenates its ephemeral public key with data.
  • the device verifies the validity of the server's ephemeral certificate by means of the server's certificate
  • the device verifies the validity of the server's certificate by means of the public key of the certification authority
  • the server verifies the validity of the ephemeral certificate of the device by means of the certificate of the device
  • the server verifies the validity of the certificate of the device by means of the public certification key.
  • the device comprises a hardware wallet of cryptoassets comprising a main secret data, or master key.
  • the hardware wallet has no means of connecting 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 .
  • Embodiments also relate to a method for safeguarding a plurality of secret data held by a cryptoasset wallet, the secret data being stored by the cryptoasset wallet or capable of being generated by the cryptoasset wallet from a piece of data main secret held by the cryptoasset wallet, the cryptoasset wallet being the property of 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 in which the orchestrator program is configured to establish a secure data link with the cryptoasset portfolio in accordance with the method which has just been 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.
  • the information relating to the identity of the user includes at least the user's first name, the user's last name and the user's date of birth.
  • 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 session 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
  • each backup server verifies the validity of the certificate of the cryptoasset wallet by means of the public certification key
  • each backup server verifies the validity of the ephemeral certificate of the cryptoasset wallet by means of the certificate of the cryptoasset wallet
  • the cryptoasset wallet verifies the validity of the certificate of each backup server by means of the public certification key
  • the cryptoasset wallet verifies the validity of the ephemeral certificate of each backup server by means of the certificate of each server.
  • data for the attention of the cryptoasset portfolio transmitted to the orchestrator program by a backup server is transmitted by the orchestrator program to the cryptoasset portfolio in an encrypted form by means of the first session key, and in which some of this data is previously hashed by the backup server by means of a hash function, then encrypted by means of the second session key.
  • the method comprises an initial step of verifying the identity of the user by the orchestrator program, and the orchestrator program is configured not to allow the saving of data in the backup servers if the verification of The identity is not conclusive.
  • the 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 secret data.
  • master key from a threshold of n secret data.
  • m is equal to 3 and n is equal to 2.
  • the method comprises a step of restoring all or part of the secret data in a second portfolio of cryptoassets, the restoration step being preceded by steps of recovering all or part of the secret data in the servers of backup via the orchestrator 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 part of the servers backup, a backup server configured to verify the identity of the user also being configured to refuse to restore the secret data it holds if the verification of the identity of the user is not conclusive
  • 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 server specialized in order to put the user in contact with this server.
  • FIG. 2A and Figure 2B show a portfolio of cryptoassets according to the invention and the architecture of a system provided for the implementation of a first embodiment of the method according to the invention, Figure 2A illustrating a data backup step and Figure 2B a data restoration step,
  • Figure 3A and Figure 3B show a portfolio of cryptoassets according to the invention and the architecture of a system provided for the implementation of a second embodiment of the method according to the invention, Figure 3A illustrating a data backup step and Figure 3B a data restoration step,
  • Figure 4A describes an algorithm executed by the system of Figures 3A, 3B, during the data saving step
  • Figure 4B is a sequence diagram which represents the steps of the algorithm of Figure 4A in the form of interactions between different elements of the system of Figures 3A, 3B,
  • Figure 5A describes an algorithm executed by the system of Figures 3A, 3B, during the data restoration step
  • Figure 5B is a sequence diagram which represents the steps of the algorithm of Figure 5A in the form of interactions between different elements of the system of Figures 3A, 3B,
  • FIG. 6A and Figure 6B show a portfolio of cryptoassets according to the invention and the architecture of a system provided for the implementation of a third embodiment of the method according to the invention
  • Figure 6A illustrating a data backup step and Figure 6B a data restoration step
  • - Figure 7 shows a portfolio of cryptoassets according to the invention and an example of hardware wallet architecture according to the invention allowing the implementation of the method according to the invention
  • FIG. 8 shows steps carried out by the user of the hardware wallet of Figure 7 for saving the seed stored in the hardware wallet
  • FIG. 9 shows steps carried out by the user of the hardware wallet of Figure 7 for restoring the seed
  • FIG. 10 shows another embodiment of a portfolio of cryptoassets making it possible to implement the method according to the invention
  • FIG. 11 shows yet another embodiment of a portfolio of cryptoassets making it possible to implement the method according to the invention.
  • the invention provides a method for producing a cryptoasset wallet offering a unique functionality in the field of hardware wallets, namely a seed saving functionality which is automated while being highly secure. Such functionality allows users to free themselves from all the difficulties and dangers that come with having to preserve a recovery phrase themselves in a safe place.
  • the unique functionalities offered by a cryptoasset portfolio according to the invention will be described further in relation to Figures 8, 9 and tables 2 and 3. Embodiments of the method according to the invention will first be described.
  • FIG. 2A shows a cryptoasset portfolio CW1 and a system provided for implementing an embodiment of the method of the invention.
  • the CW1 cryptoasset wallet here includes an HW device and an HDV host device.
  • the HW device is a hardware wallet ensuring the cold storage of an S seed or master key, of a set of cryptoassets.
  • the HW device does not include any means of connection to the Internet and is connected to the HDV host device, which runs HSW companion software allowing it to connect to the Internet, for example by means of a USB or Bluetooth connection.
  • the system and method according to the invention make it possible to save or restore the seed S (master key) stored in the device HW.
  • the system essentially comprises a set of m BCKi backup servers (BCK1, BCK2,... BCKi,... BCKm) each provided with a MEM backup memory (magnetic hard disk or solid state memory) for backing up shares Si of the seed S.
  • Each backup server includes a back-end program BEi (BE1,... BEi,... BEm), or "back-end" program, designed for implementing the process.
  • BEi back-end program
  • Each BCKi backup server is also associated with an HSM security module.
  • the device HW is configured to divide the seed S into a plurality of secret data Si (S1, S2...Si,...Sm) which will be saved on the BCKi servers.
  • 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 “parts"("shares"), and allowing the reconstitution of the seed from a threshold of n secret data If:
  • the SS function allows the seed to be divided into three parts S1, S2, S3 but only two parts will be necessary to reconstitute the seed.
  • the HW device When the user wishes to save his seed, the HW device establishes LNKi data links (LNK1 to LNKm), for example HTTPS type, with each BCKi backup server, via the HDV host device. These data links are then secured by the creation of secure SCP ("Secure Channel Protocol") type channels between the HW device and each BCKi backup server, in a manner which will be described.
  • LNKi data links LNK1 to LNKm
  • HTTPS type Secure SCP
  • the creation of such secure channels is ensured using a public key infrastructure managed by a CA certification authority.
  • 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: pL: private key of the certification authority
  • 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 pBi: private key of a BCKi server (for i ranging from i to m)
  • PBi public key of a BCKi server (for i ranging from i to m)
  • 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.
  • the signature function “Sign” is for example generated by means of an ECDSA signature algorithm based on elliptic curves (“Elliptic Curve Digital Signature Algorithm”).
  • the CA certification authority is preferably held by the manufacturer of the HW device, to allow it to control the allocation of CBi certificates to BCKi backup servers.
  • THE BCKi backup servers may be held by the manufacturer of the HW device, or be third-party partner servers participating in the implementation of the process.
  • the pBi, PBi keys of the BCKi backup servers are held by their respective HSM modules, which support the cryptographic calculations carried out using these keys. In what follows and for the sake of simplification of the language, we will consider that such cryptographic calculations are carried out by the servers themselves.
  • each BCKi backup server generates a pair of ephemeral PeBi private and PeBi public keys by means of an asymmetric key generator, then communicates its ephemeral public key PeBi to the HW device in an ephemeral CeBi certificate that it signed with its private key pBi, as well as its CBi certificate signed by the trusted authority:
  • CeBi [PeBi, Sign(pBi, PeBi)]
  • CBi [PBi, Sign(pL, PBi)] ii) the HW device itself generates a pair of ephemeral private peD and public PeD keys, then communicates its ephemeral public key PeD to the BCKi backup servers in an ephemeral CeD certificate which he signed with his pD private key, as well as his CD certificate signed by the trusted authority, i.e.:
  • each BCKi backup server verifies the signature of the ephemeral public key PeD of the HW device using the public key PD present in its CD certificate, then verifies the signature of the public key PD present in the CD certificate 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), 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, v) each BCKi backup server generates an ephemeral session key kBi from its ephemeral private key peBi and the ephemeral public key Pe
  • the HW device After generating the Si shares of the seed S, the HW device conducts symmetric encryption steps of each Si share with the session key kBi common to the backup server BCKi to which the Si share must be sent, which therefore forms a key shared.
  • the HW device generates three shares S1, S2, S3 (the threshold n can then be equal to 2 or 3) and three backup servers BCK1, BCK2, BCK3 are provided.
  • Each BCKi server generates its own session key kB1, kB2, kB3 and the HW device for its part generates each of these session keys after an exchange of keys with each server in the manner which has just been described.
  • the device HW carries out symmetrical encryption steps of the shares S1, S2, S3 using these keys, i.e.:
  • Each BCKi backup server then decrypts the encrypted part ⁇ Si ⁇ kBi that it received from the HW device, and stores it in its MEM memory.
  • the restoration of the seed S is carried out in a second hardware wallet denoted HW.
  • HW a second hardware wallet
  • This may be a device other than the HW device if it has been lost, stolen or destroyed. It can also be the HW device if it has been reset, the HW device then being considered as an "other" device from the point of view of the process, since it no longer has the seed.
  • each server encrypts the part Si that it holds with the session key kBi, i.e. ⁇ Si ⁇ kBi, then sends it to the HW device.
  • the latter decrypts each Si part using the corresponding session key kBi, then reconstitutes the seed S using the inverse function of that which made it possible to generate the Si shares, denoted "SS -1 ":
  • FIG. 3A shows the architecture of a system making it possible to implement another embodiment of the method of the invention.
  • an ORCSR server 1 is interposed between the HDV host device and the BCKi backup servers.
  • This server called non-limitingly “orchestrator server”, executes a back-end or "back-end” ORC1 program. 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:
  • a first data link LNK1 is established between the device HW and the orchestrator ORC1 by means of the host device HDV, for example an HTTPS link.
  • a plurality of LNK2i data links are also established between the orchestrator and the BCKi backup servers, for example HTTPS links, IPsec VPN, etc.
  • the data link between the orchestrator and the HW device is secured by the creation of a secure channel using the same technique as that described above: i) the orchestrator ORC1 generates a pair of private PeO and public PeO keys then communicates its ephemeral public key PeO to the HW device in an ephemeral CeO certificate that it signed with its private key pO, accompanied by its CO certificate signed by the trusted authority, i.e.:
  • CO [PO, Sign(pL, PO)] ii) the HW device generates a pair of ephemeral private PeD and public PeD keys then communicates its ephemeral public key PeD to the orchestrator in an ephemeral CeD certificate that it has signed with its private key pD, accompanied by its CD certificate signed by the trusted authority, i.e.:
  • Secure channels are also created between the HW device and the BCKi backup servers using session keys kBi which are generated following a key exchange via the LNK1 data link, with the orchestrator acting as gateway or "proxy server” between the HW device and the BCKi servers.
  • the method of the invention implements two improvements concerning the transmission of the CD certificate of the HW device as part of a key exchange with any server.
  • the sending by the device of its CD certificate as part 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.
  • an ECDSA signature makes it possible to find the value of the corresponding public key.
  • 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.
  • CO [PO, Sign(pL, PO)] 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, iii) the device generates the session key kO from its ephemeral private key peD and the ephemeral public key PeO of the orchestrator, iv) the device encrypts its certificate CD with session key kO:
  • the device encrypts the first signature Sign(pD, PeD) using the session key kO:
  • the device transfers to the orchestrator its CD certificate encrypted with the session key kO as well as its ephemeral CeD certificate including the signature of its ephemeral public key PeD encrypted with the session key kO :
  • the orchestrator generates the session key kO from its ephemeral private key peO and the ephemeral public key PeD received from the device, and viii) by means of the key session kO, the orchestrator decrypts the signature present in the ephemeral CeD certificate and decrypts the device CD certificate.
  • the step of saving the seed S can in this case be implemented as follows, with reference to Figure 3A: i) establishment of the LNK1 connection between the device HW and the orchestrator and sending by the device HW of a BCKRQ backup request to the orchestrator, ii) generation by the orchestrator of a random BCKID identifier of the backup, establishment of LNK2i links between the orchestrator and the BCKi backup servers, sending by the orchestrator to the backup servers BCKi backup of the BCKID identifier, iii) creation of the secure channel between the HW device and the ORC1 orchestrator using the kO session key, iv) creation of secure channels between the HW device and the BCKi backup servers using session keys kBi, via the orchestrator ORC1, v) generation by the device HW of the shares Si of the seed S:
  • the step of restoring the seed S in a new HW device comprises the following steps: i) establishment of the LNK1 link between the device HW and the orchestrator and the HW device sends a RESTRQ restoration request to the orchestrator, accompanied by the backup identifier BCKID, ii) establishment of the 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, iii) creation of the secure channel between the HW device and the ORC1 orchestrator by means of a new kO session key, iv) creation of secure channels between the HW device and the BCKi backup servers by means of new kBi session keys, via the orchestrator ORC1, v) reading by each BCKi backup server, in its memory, at by means of the BCKID identifier, from
  • Si ⁇ Si ⁇ ' 1 kBi x
  • the orchestrator can only collect n parts necessary for reconstituting the seed, if n is less than m.
  • the seed is reconstituted from the n parts recovered:
  • a UASRV customer account server comprising a UACC user account in which various data concerning the user are stored, in particular the BCKID identifier of the backup.
  • the UASRV server is associated with an HSM security module receiving a private key pC, a public key PC, a CC certificate signed by the certification authority, and the public key PL of the latter.
  • the HW device establishes a data link with the UASRV server through an exchange of keys making it possible to define a session key for the creation of a secure channel, with reciprocal verification of certificates.
  • the HSW companion software connects to the UACC customer account to retrieve the BCKID.
  • the BCKID identifier is stored on the UASRV server but is not communicated to the companion software.
  • a secure connection is established between the UASRV server and the ORC1 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.
  • the user's identity is also associated with the backup process, by defining a set of information forming a "pivot identity" allowing the user to be identified.
  • the information forming the pivotal 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 brings it together to form a binary string which we will refer to as “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 later distinguish between several backups, if they hold several hardware wallets).
  • the orchestrator When initializing the backup, as shown in Figure 3A, the orchestrator communicates the BCKDT data to the BCKi backup servers which will associate them, as well as the BCKID identifier, with the backed-up Si shares. For confidentiality reasons, it could be preferred, in certain embodiments, that the orchestrator does not retain the BCKDT data once the backup has been made.
  • the BCKDT data are in this case only kept by the BCKi servers, which communicate them to the USR user for confirmation by the latter of his identity at the time of restoration, as shown in Figure 3B.
  • the pivotal identity of the user is verified during at least one identity verification step designated "IDV" ("Identity Verification") which is conducted before restoring the seed .
  • IDV identity verification
  • several IDVi identity verification steps are preferably provided before proceeding with the restoration of the seed, these steps being carried out by all or part of the BCKi backup servers requested for the restitution of a part If of the seed S.
  • these identity verification steps are entrusted to specialized service providers instead of being carried out by the BCKi backup servers themselves.
  • Such providers have IDVSRVi servers each running an IDVSi automated identity verification service accessible via a GTW gateway ("Gateway").
  • Each BCKi backup server can be assigned a different IDVSRVi server, and configured to connect to the GTW gateway of the IDVSi service run by that server.
  • IDVSi services are not entirely automated, at least for some of them, and include human intervention, particularly in the event of doubt about the identity of a person.
  • each BCKi backup server or at least part of them is configured to carry out an IDVi step of verifying the pivotal identity of the user when it receives a request for restitution of a part of the seed .
  • the server is then preferably configured to refuse to return the share if this verification is not conclusive.
  • the seed saving step is also preceded by an initial IDVO step, conducted by the orchestrator or supervised by it, of verifying the pivotal identity of the user (i.e. minus his first name, last name and date of birth).
  • 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.
  • the orchestrator connects the USR user to the appropriate IDVSO or IDVSi service, via the appropriate GTW gateway .
  • the user must perform certain actions requested of him through the screen of the HDV host device and the camera with which it is equipped (for example a mobile phone camera, a personal computer webcam, etc.).
  • the IDVSO or IDVSi service asks him to present a valid identity document including a photo of his person, to take a photo of the identity document with his camera and to send it to him
  • the IDVSO service or IDVSi then asks him to take a photo (selfie) or video of his face and send it.
  • the IDVSO or IDVSi service then verifies the authenticity of the identity document from the photo or video of its face, and the identity document, once verified, allows it to verify the identity data pivot with a degree of certainty which can, in certain embodiments, give rise to a score.
  • the result of this verification, and optionally the score, is communicated to the orchestrator.
  • the IDV steps may also include verifications on government bases.
  • the IDVO step is not as critical as those carried out by the BCKi servers when returning Si shares, it ensures that the user has not made an error in providing the relative information. to his identity, which are incorporated into the BCKDT data. Furthermore, the information collected by the orchestrator during this step, such as the photo of his identity document and the photo or video of his face, can optionally be communicated to the BCKi backup servers via a communication channel. specific, since this information is not part of the BCKDT backup data.
  • the ORC1 orchestrator may suspend the seed saving process if it judges that the initial verification of the user's identity is inconclusive or is assigned too low a score. Furthermore, in another embodiment or in addition, the orchestrator receives from the BCKi backup servers information on the success of the IDVi identity verification steps that they have carried out or which have been carried out by the service providers with which they are affiliated. If a specified number of BCKi servers have not successfully verified the user's identity and refuse to return the Si shares they hold, the orchestrator can be configured to suspend the return of Si shares by the servers that successfully verified the user's identity. The orchestrator can optionally decide to subject the user to an additional identity verification step.
  • 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/her status. identify.
  • a solution can be provided to allow it to recover its seed.
  • the user will then have to undergo a plurality of individual steps to verify their identity with each BCKi server to recover each Si part of the seed.
  • Each IDV provider will also be able to 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 natural persons with more in-depth investigation procedures. , 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 an educational background or of a user's employee journey, etc.
  • the BCKID backup data could, in one embodiment, include in compressed form the data collected in the IDVO step to verify the user's pivotal identity, such as the photo or video of their face and a photo of an identity document.
  • the automated steps for verifying the user's pivotal identity as carried out by IDVSi services executed by IDVSRVi servers or by the BCKi backup servers themselves, may include at least two of the following steps: acquisition, by via a camera, 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 movement, with live detection to verify that the user is real; acquisition of proof of address, such as an electricity or telephone bill; acquiring a fingerprint of the user; acquisition of a validation code received by the user in a message telephone, 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 a non-expired identity document.
  • Figure 4A is a sequence diagram which represents the steps of the algorithm in the form of interactions between:
  • the USR user selects a seed saving option in the HW device.
  • the user through the HDV host device, creates a backup account on the UASRV account server.
  • the HW device establishes a data link with the ORC1 orchestrator and sends it the backup request:
  • the HW device offers the possibility to the user to choose the number m of parts Si that he wishes to generate for saving the seed, and the threshold n corresponding to the number of parts necessary for the reconstitution of the seed S.
  • the HW device can present the user with a list of BCKi backup servers, some of which may be external partners, and ask the user to indicate which ones they wish to use. Otherwise, these are selected automatically by the orchestrator.
  • the ORC1 orchestrator establishes a data link with the BCKi servers and then initiates the backup process according to the steps described in the following.
  • the ORC1 orchestrator generates the BCKID of the backup, for example a random number, and transfers it to the HW device and BCKi servers.
  • the ORC1 orchestrator connects the user to the IDVSRVO server through a GTW gateway.
  • the IDVSO service carries out a verification of the pivotal identity of the IDVO user.
  • the IDVSRVO server confirms to the orchestrator ORC1 that the IDV has been carried out successfully, and the orchestrator ORC1 confirms to the user via the HW device that his identity has been verified and that the backup step of the seed can be initiated. During this step, the orchestrator ORC1 can generate the data from the BCKDT backup, and send them to the HW device.
  • the ORC1 orchestrator 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.
  • the orchestrator calculates the signature of its ephemeral public key PeO after having concatenated it with ReO data.
  • the ReO data specifies for example the role that the orchestrator server plays in the process, for example the role of orchestrator for the establishment of a secure channel.
  • the orchestrator then generates an ephemeral CeO certificate by concatenation of the ephemeral public key PeO and the signature.
  • the ORC1 orchestrator sends its ephemeral certificate and its CO certificate to the HW device.
  • the HW device verifies the orchestrator's certificate chain, in the manner described above, using the public key PL of the certification authority.
  • 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 ephemeral public key PeO of the orchestrator using the ECDH algorithm.
  • the HW device then calculates the signature of its ephemeral public key PeD by means of its private key pD, here after having concatenated the ephemeral public key PeD with data ReD.
  • the ReD data specifies for example the role that HW plays 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 concatenation of the ephemeral public key PeD and the encrypted signature. Finally, the HW device encrypts its CD certificate using the kO key, in accordance with the certificate encryption method described above.
  • the HW device sends its CD certificate encrypted using the kO key as well as its ephemeral CeD certificate including the encrypted signature to the orchestrator ORC1. Thanks to certificate encryption and ephemeral certificate signature encryption, the PD public key 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.
  • 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.
  • CD ⁇ CD ⁇ 1 kB
  • Orchestrator ORC1 decrypts the HW device's CD certificate and the HW device's ephemeral certificate signature, then verifies the certificate chain.
  • B6 Sending BCKID, BCKDT data and device CeD and CD certificates to BCKi servers
  • the ORC1 orchestrator sends to each BCKi server the BCKID backup identifier, the BCKDT backup data which includes at least the pivot identity data.
  • 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 at 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 customer accounts server and transmitted to the BCKi servers after the backup.
  • CeBi PeBi
  • 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 ReB data 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 managing the secure channel. Then each BCKi server generates an ephemeral CeBi certificate by concatenation of the ephemeral public key PeBi and its signature.
  • 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.
  • Each BCKi server then generates a hash code Hi from a binary string including its ephemeral public key PeBi, the BCKI D data and the BCKDT backup data. Each BCKi server then encrypts the Hi code using the session key kBi to obtain an encrypted hash code CHi.
  • Each BCKi server sends to the orchestrator ORC1 a binary string RETDTi including its ephemeral CeBi certificate, its CBi certificate and the encrypted hash code CHi.
  • B8.5 Sending BCKi server certificates and encrypted hash code to the device
  • the orchestrator ORC1 returns to the device the BCKID, BCKDT data and all RETDTi data received from the BCKi backup servers, in encrypted form using the kO key. It will be noted here that the orchestrator does not have access to the RETDTi data because it does not know the kBi private keys of the BCKi servers. The data in the secure communication channel between the orchestrator and the device is therefore encrypted twice.
  • the HW device decrypts the data string to extract the BCKID, BCKDT data and the CeBi, CBi, CHi certificates.
  • the natural person user validates the BCKDT backup data and the BCKi servers in charge of the backup, which are presented to them on the screen of the host device.
  • the HW device verifies the certificate chain of each BCKi server.
  • the HW device For each BCKi server, the HW device generates the session key kBi then decrypts the Hi code and validates it by itself recalculating the Hi code and comparing it to the decrypted code.
  • the device HW By means of the secret sharing function SS, the device HW generates the m parts Si to be saved in the different servers BCK1, BCK2... BCKm, with a threshold of n parts to recover the seed S.
  • the HW device For each BCKi server, the HW device encrypts the Si portion intended for it with the kBi key specific to it.
  • the HW device then sends all the shares to the orchestrator ORC1. It will be noted that the orchestrator is not aware of the value of each part Si because it is encrypted with the key kBi which he does not know.
  • the ORC1 orchestrator sends to each BCKi server the encrypted Si part intended for it, accompanied by the backup identifier.
  • Each BCKi server decrypts the Si part that it has received and stores it in its MEM memory so that it can be saved.
  • 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.
  • each BCKi server can send encrypted proof of decryption of the Si part using a hash code signed with its session key. This signed hash code will be passed back to the HW device for verification. B15. Confirmation of backup to user
  • the ORC1 orchestrator sends a backup success message ("OK") to the HW device, which displays a backup confirmation message on its screen for the user.
  • the HSW companion software records the BCKID backup identifier
  • the ORC1 orchestrator does not hold the S seed nor the BCKDT backup data, and only holds the BCKID backup identifier
  • each BCKi server holds the BCKID backup identifier, the BCKDT backup data which contains at least the pivotal identity of the user, and the Si part of the seed entrusted to it.
  • the HSW companion software records the BCKID backup ID and can also update the user's UACC customer account by recording the BCKID backup ID.
  • Figure 5A is a sequence diagram which represents the steps of the algorithm in the form of interactions between the entities mentioned above.
  • the user has lost their HW device, or has irrecoverably lost the password which allows them to use it. He obtains a new HW device which he will use to recover the seed S, and connects it to the HDV host device whose HSW companion software has memorized the BCKID backup identifier.
  • the new HW device could also be the HW device that was reset.
  • the HW device holds a private key pD, a public key PD, a CD certificate 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 HW device certificates).
  • the restore step includes the steps described below. Steps similar to those previously described will not be commented on again.
  • the device sends a restore request to the orchestrator
  • the restoration is initiated by the HW device sending a RESTRQ restoration request to the orchestrator.
  • the request contains the BCKID backup identifier. It is issued at the user's request and selected through a menu displayed on the screen of the HW device or on the screen of the HDV host device.
  • CD ⁇ CD ⁇ ' 1 kB
  • Verif CeD Verif CD R3. Sending BCKID data and CeD, CD certificates to BCKi servers
  • the ORC1 orchestrator sends to each BCKi backup server the backup identifier BCKID, the ephemeral CeD certificate and the CD certificate of the HW device.
  • CeBi PeBi
  • the user validates the BCKDT backup data, including first name, last name, date of birth, optionally place of birth.
  • the HW device sends back to the orchestrator ORC1 for each BCKi server, an individual restoration confirmation "Confirm Restore' 1 which is encrypted with the key kBi of each BCKi server.
  • Each confirmation is a predefined binary code.
  • the ORC1 orchestrator sends to each BCKi server the concatenated BCKID backup identifier and the restoration confirmation ⁇ Confirm RestoreJkBi intended for it.
  • Each BCKi server decrypts the confirmation message sent by the device HW and which was communicated to it by the orchestrator ORC1, and memorizes the certificate CD of the device H which it has previously verified.
  • BCKi server click indicates to the ORC1 orchestrator that it is ready to restore the Si part that it has saved provided that the user identifies himself through an IDVi step.
  • 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 verifies the user's identity, then confirms to the orchestrator ORC1 that his identity has been verified and that the seed saving step can be initiated.
  • each IDVRi identity verification step can range from a few minutes to several days depending on the requirements of each BCKi server or of the service provider carrying out the IDVRi. Verifications by natural persons may be systematically planned with certain IDV providers.
  • the HW device sends a “Continue Restore” request to the orchestrator ORC1.
  • 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.
  • the orchestrator relays the request to continue the restoration to the BCKi servers. 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 specified number of BCKi backup servers have not successfully verified the user's identity and refuse to return the data they hold, the orchestrator can be configured to suspend the return of shares by the servers that successfully verified the user's identity. It may optionally decide to subject the user to an additional identity verification procedure. The orchestrator can also be configured to analyze user identity verification confidence scores, as discussed above, and make a decision based on that analysis.
  • this step is limited to n BCKi backup servers, instead of all the backup servers, if only n parts are necessary for reconstitution of the seed, with n less than m.
  • 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.
  • Each BCKi server sends to the orchestrator ORC1 the part Si that it holds, encrypted using its key kBi, which the orchestrator does not know.
  • the orchestrator ORC1 sends to the HW device all the Si shares received from the BCKi servers in encrypted form using the kBi keys.
  • the HW device After having decrypted each share of rank i using the corresponding key kBi, the HW device restores the seed from the shares received, or part of them if their number is greater than n.
  • the HW device confirms to the ORC1 orchestrator that the seed restoration is complete.
  • Ephemeral certificates could also be of the type:
  • the method can also be implemented with any certificate structure.
  • X509 type certificates can be used.
  • other encryption functions or cryptographic algorithms can be used, particularly in the context of an implementation based on RSA cryptography.
  • Figure 6A shows a system for implementing the method of the invention which differs from that of Figure 3A in that the ORCSRV1 server is replaced by an ORCSRV2 server which executes an ORC2 orchestrator program (hereinafter "orchestrator ORC2").
  • ORC2 ORC2 orchestrator program
  • the OCR2 orchestrator differs from the ORC1 orchestrator in that it does not ensure the transmission of data transmitted by the BCKi backup servers to the HW device, and vice versa, and therefore does not act as a gateway or "proxy server". ".
  • the HW device sends a BCKRQ backup request to the OCR2 orchestrator following which the ORC2 orchestrator initiates the previously described steps of generating a BCKID identifier of the seed. backup, and collection of information concerning the user, to generate the data of the BCKDT backup.
  • the orchestrator also conducts the initial IDVO step of verifying the user's identity. If this step is successful, the orchestrator delivers BCKPASi backup authorizations to the HW device, at the rate of one authorization per BCKi backup server, and sends each authorization to the BCKi server concerned.
  • Each BCKPASSi authorization forms a sort of "passport" allowing the HW device to know which BCKi server it must contact to save a Si part of the seed, and allowing it to connect to the BCKi server to proceed with 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.
  • BCKPASSI permissions are maintained by the companion software as well as, preferably, in the user's UACC account on the UASRV account server.
  • the orchestrator issues a general BCKPASS authorization containing a concatenation of all the information contained in the BCKPASSi authorizations.
  • the companion software when the user wants to restore the seed, the companion software connects to the BCKi backup servers which it identifies by means of the addresses contained in the BCKPASSi authorizations, then hands over to the HW device so that it establishes secure channels with BCKi backup servers, through key exchanges as described above.
  • the BCKi backup servers initiate the IDVi steps of verifying the user's pivotal identity.
  • the role of supervisor of the IDVi stages which was previously assigned to the orchestrator ORC1 can also be assigned here to the orchestrator ORC2.
  • the latter is then requested by the BCKi backup servers to analyze the results of the IDVi steps. If these results are conclusive, the ORC2 orchestrator issues 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 RESTPASSi authorizations to recover the Si shares of the seed.
  • the organization in charge of the orchestrator ORC1 or ORC2 delivers to the user, for example by post, a backup certificate coated with an inviolable certificate of authenticity such as a hologram.
  • a backup certificate coated with an inviolable certificate of authenticity such as a hologram.
  • Such a certificate backup will not spare the user the steps of verifying his identity with the backup servers, but will include sufficient information to provide an additional degree of certainty as to his status as the legitimate holder of the seed when the verification steps IDVi will be conducted.
  • FIG. 7 shows an example of an HW hardware wallet enabling the implementation of the method.
  • the HW device includes a secure element SE1, a microcontroller MCU1 and a touch screen TS1 ("Touch Screen").
  • the TS1 touch screen includes an EID electronic ink display ("E-Ink Display”) and a TM touch module ("Touch Module”).
  • the touch screen TS1 is under the control of the secure element SE1.
  • the resources in terms of inputs/outputs of the secure element SE1 are divided into three groups of inputs/outputs IOGA, IOGB, IOGC.
  • the IOGA input/output group is assigned to the implementation of a BS1 bus 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 secure element SE1 to the EID display, and the IOGC input/output group is assigned to the implementation of a BS3 bus connecting the secure element SE1 to the touch module TM.
  • the BS1 bus is for example an IEC/ISO 7816 bus
  • the BS2 bus is for example an SPI bus
  • 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:
  • a PMIC power management integrated circuit receives a voltage Vbat from the battery when it is charged, supplies the voltage Vbat to the battery when it must be charged, and supplies a regulated supply voltage Vcc to the microcontroller MCU1, to the secure element SE1 and to the touch screen TS1;
  • the QiA antenna is connected to a wireless charging integrated circuit WCIC (“Wireless Charging Integrated Circuit”).
  • the WCIC circuit provides a voltage Vqi to the PMIC circuit for charging the battery;
  • the USB port provides the PMIC circuit with Vusb voltage for battery charging, provides the MCU1 microcontroller with DTu data received from an external device connected to the USB port, and transmits DTu data to the external device;
  • 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.
  • the HW device has the advantage of having a touch screen exclusively controlled by the secure element SE1 and therefore not susceptible to corruption, including in the event of an attack on the MCU1 microcontroller.
  • the latter does not run any application programs and does not store any 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 includes a memory space MS1 comprising a read-only memory zone, a programmable and electrically erasable non-volatile memory zone and a volatile memory zone.
  • the programmable and electrically erasable non-volatile memory area receives an operating system from the secure element. This is configured to allow the implementation of the method of the invention.
  • the HW device lends itself well to the implementation of the method thanks to its touch screen, which can be chosen large and have for example a diagonal greater than or equal to 3.5 inches (one inch being equal to 2.54 cm ), and include at least 600 x 400 pixels.
  • the screen has a diagonal of 3.9 inches (9.906 cm) and offers 670 x 496 pixels, which constitutes a very large screen for a hardware cryptoasset wallet without Internet connectivity.
  • Tables 2 and 3 below as well as Figures 8 and 9 describe an example of configuration of the HW device and the HSW companion software for the implementation of an embodiment of the method of the invention, in which three servers backup are used, the seed therefore being saved by means of three parts.
  • the HW device is used in association with the HDV host device to which it can be connected via its USB or Bluetooth interface.
  • the HDV host device itself includes a screen allowing the USR user to drive with the companion software, certain steps of the process while other steps are carried out with the device H.W.
  • entries in square brackets correspond to virtual buttons that the user must press to select the option they choose.
  • Mentions in quotation marks are information displayed by the HW device or HDV host device.
  • the “xx” mentions correspond to displayed areas or areas in which the user must provide the requested information.
  • 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. We assume here that the HW device was previously put into service but that the user never saved his seed. The latter therefore chooses the first option.
  • 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 using an automatic protection service implementing the method according to the invention .
  • the user is invited to create an account on the customer account server.
  • the user creates this account and provides information relating to his identity, at least part of which constitutes the information of his pivotal identity incorporated in the BCKDT backup data.
  • a step D5 he defines the password for his account.
  • a step D6 the companion software reminds the user that he will have to undergo a step of verifying his identity.
  • the IDVO step is conducted in steps D7 to D11 using the screen of the HDV host device, as well as its camera. Once the IDVO step has been successfully completed, the user must connect the HW device to the HDV host device in step D12.
  • the device HW takes care of the rest of the process by asking the user in a step D13 to enter his password, then in steps D14, D15 to verify his identity. The HW device then proceeds to save the seed in step D16.
  • the user chooses the Initialize/Restore option.
  • the companion software asks the user to connect the HW device to the HDV host device.
  • the companion software and the HW device confirm that the connection has been made.
  • the user must enter the password of the HW device.
  • 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 carry out a restoration from a recovery phrase.
  • the user chooses the “restoration” option.
  • the HW device asks the user if 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 (restoration manual). The user chooses the protection service.
  • the companion software takes care of the rest of the process and informs the user that he will have to undergo three steps to verify his identity.
  • the first will be carried out with the HW device and the other two will be carried out with IDV providers.
  • the user must confirm the information displayed by the HW device concerning his pivot identity (information additional to that forming the pivot identity can be displayed by the HW device during this step, as we seen in table 3).
  • 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 a partner IDVSRVi server, via its GTW gateway, as described above.
  • steps D28 to D32 the user carries out 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 device HDV host.
  • 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.
  • steps summarized in the table by a single step D34 the user carries out 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 for the first identity verification.
  • the identity verification is not completed once these steps have been carried out and that the result of each verification could only be provided to the user a few hours or even a few days later, as has been explained more high.
  • the device HW recovers the parts S1, S2, S3 of the seed and restores it during a step D35.
  • the method which has just been described can also be implemented with other types of cryptoasset wallets than that which has just been described.
  • the method can in particular be implemented with a portfolio of cryptoassets CW2 of the type shown in Figure 10.
  • the portfolio of cryptoassets CW2 comprises a secure microcontroller SMCU, a screen TS2 which can be touchscreen, 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 TZ zone being called "trust zone" ("Trust Area").
  • the secure microcontroller can, in certain embodiments, be equipped with a secure element SE2 coupled to the trust zone TZ to carry out cryptographic calculations and conduct the most sensitive operations in terms of security, in particular storing the seed as well as various cryptoasset account keys.
  • Each zone can operate independently of the other while using the same core.
  • 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 the equivalent of 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.
  • FIG. 11 shows a CW3 cryptoasset portfolio of software type executed by an electronic device DV which can be of the aforementioned type, computer, mobile telephone or equivalent.
  • the DV device comprises an MPU microprocessor equipped with a CINT2 communication interface allowing it to connect to the Internet, a volatile RAM memory and a non-volatile memory NVM, for example a magnetic hard disk or a hard disk solid state (SSD).
  • the CW3 program forming the software cryptoasset portfolio is stored in the non-volatile memory NVM of the DV device and is executed by the MPU microprocessor using its RAM memory.
  • Table 2 Seed save, interaction between user, HW hardware wallet and HDV host device
  • Table 3 Seed recovery, interaction between user and HW hardware wallet and HDV host device

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Power Engineering (AREA)

Abstract

Procédé pour établir une liaison de données sécurisée entre un dispositif électronique (HW) et un serveur (ORC1), dans lequel le serveur génère (B5.1) une clé privée éphémère (peO), une clé publique éphémère (PeO) et un certificat éphémère (CeO) signé avec sa clé privée (pO), et transfère (B5.2) son certificat éphémère au dispositif. Le dispositif génère (B5.4) une clé privée éphémère (peD) et une clé publique éphémère (PeD), une première signature de sa clé publique éphémère à partir de sa clé privé, une première clé de session (kO) à partir de sa clé privée éphémère (peD) et de la clé publique éphémère (PeO) du serveur, puis chiffre (B5.4) la première signature au moyen de la première clé de session (kO), pour obtenir une signature chiffrée, et transfère (B5.5) au serveur un certificat éphémère (CeD) comprenant sa clé publique éphémère (PeD) et la signature chiffrée.

Description

DESCRIPTION
Procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur
Domaine Technique
La présente invention concerne un procédé pour la sauvegarde et la restauration d’un secret détenu par un dispositif électronique, et un procédé pour sécuriser la sauvegarde et la restauration d’un secret détenu par un dispositif électronique. La présente invention concerne également la sécurisation d'une liaison de données sécurisée entre un dispositif électronique et un serveur. La présente invention concerne notamment les portefeuilles matériels déterministes hiérarchiques utilisés pour le stockage de clés privées permettant de gérer des comptes sur la blockchain.
Arrière-plan
Ces dernières années, le développement des cryptomonnaies ou autres types de cryptoactifs gérés par la blockchain, tels que les jetons non tangibles ("NFT") et les contrats intelligents ("Smart Contracts"), a donné naissance à divers moyens de stockage et de conservation des clés privées et publiques attachées à ces différents types de cryptoactifs. C’est ainsi que sont apparus les portefeuilles de cryptoactifs communément appelés "wallets" permettant le stockage et la conservation de ces clés. Un portefeuille de cryptoactifs est un dispositif matériel ou logiciel dont la fonction est de stocker les clés privées et publiques attachées à des comptes de cryptoactifs, et de signer des transactions au moyen de ces clés. On distingue les portefeuilles dits "chauds" ("hot wallets") et les portefeuilles dit froids ("cold wallets"). Les portefeuilles "chauds " sont connectés à l’Internet et susceptibles d’attaques de pirates ou d’exposition à des virus et malwares. Il peut s’agir de portefeuilles gérés par des plateformes d’échange centralisé ou de programmes installés sur des téléphones mobiles, tablettes ou ordinateurs personnels ("software wallets"). De tels portefeuilles sont connectés à Internet et donc eux-mêmes susceptibles d’attaques. Les portefeuilles "froids" ou portefeuilles matériels ("hardware wallet") sont en revanche dépourvus de tout accès direct à Internet, ce qui réduit la surface d'attaque et donc le risque de vol par piratage informatique. Un portefeuille matériel est généralement un dispositif électronique portatif, équipé d’un processeur ayant des moyens de calcul cryptographique. Les transactions mettant en jeu des clés privées sont signées dans un environnement hors ligne. Toute transaction réalisée en ligne est temporairement transférée vers le portefeuille matériel pour y être signée numériquement hors ligne, avant que la signature ne soit transmise au réseau en ligne. Comme les clés privées ne sont pas communiquées aux serveurs en ligne pendant le processus de signature, un pirate informatique ne peut pas y accéder.
Un tel type de portefeuille matériel est donc aujourd’hui considéré comme la solution la plus sûre contre les attaques de pirates informatiques. Son seul inconvénient réside dans le risque de perte, de vol ou de destruction (incendie par exemple) du portefeuille matériel, ou de perte du mode de passe personnel de l'utilisateur permettant de s’en servir. Les clés qu’il contient doivent donc généralement être sauvegardées en lieu sûr.
Un premier problème qui s’est posé dans le passé a été de trouver un moyen de simplifier le nombre de clés à sauvegarder, celles-ci pouvant être très nombreuses si l’utilisateur possède de nombreux comptes de cryptoactifs sur la blockchain. Pour solutionner ce problème, le portefeuille déterministe hiérarchique a été proposé par Bitcoin. D'abord proposé dans la norme BIP32, puis optimisé avec les normes BIP39, BIP43 et BIP44, il permet à un utilisateur de ne pas avoir à réaliser une nouvelle sauvegarde pour toute nouvelle paire de clés générée, une unique sauvegarde pour l'ensemble des clés de son portefeuille étant suffisante. Cette solution est aujourd’hui utilisée par la grande majorité des portefeuilles de cryptoactifs logiciels ou matériels.
Avec un portefeuille déterministe hiérarchique, toutes les clés privées de l’utilisateur sont générées à partir d’une graine aléatoire d’origine, généralement appelée "seed" ou "master key" (clé maître). Il suffit qu’un utilisateur conserve en lieu sûr la graine pour récupérer toutes ses clés, qui sont dérivées de la graine et peuvent être reconstituées à partir de celle-ci ("clés enfants").
Afin de faciliter la mémorisation et le stockage de la graine, la norme BIP39 prévoit également d'exprimer la graine, qui est un nombre binaire de grande longueur, sous la forme d’une phrase mnémonique appelée aussi "phrase de récupération" ("recovery phrase"). Le type exact de graine BIP39 utilisé actuellement dans les appareils de la demanderesse est une phrase de récupération qui se compose de 24 mots choisis dans une liste de 2048 mots définis par la norme précitée.
Pour la génération d’une phrase de récupération, un portefeuille matériel génère une séquence de 256 bits aléatoires à l'aide d’un générateur de nombres aléatoires. Les 8 premiers bits d’un hachage SHA-256 des 256 bits initiaux sont ajoutés à cette chaîne de bits, ce qui donne 264 bits. Les 264 bits sont répartis en 24 groupes de 11 bits par l’appareil. Chaque groupe de 11 bits est interprété comme un nombre compris entre 0 et 2047, qui sert d'index à la liste de mots BIP39, ce qui permet d’obtenir la phrase mnémonique de 24 mots. Ce type de portefeuille ne nécessite donc qu’une seule sauvegarde de la graine, de préférence au moment de sa mise en service, à partir de laquelle il est possible de dériver l’ensemble de l’arbre descendant de clés.
La figure 1 montre schématiquement un portefeuille de cryptoactifs comprenant un portefeuille matériel HW, par exemple le dispositif commercialisé par la demanderesse sous l’appellation "Nano" ou "Stax", et un dispositif hôte HDV exécutant une application compagnon HSW, par exemple l’application "Ledger Live" développée par la demanderesse. Le dispositif HW ne pouvant pas se connecter directement à l’Internet, il est associé au dispositif hôte HDV pour réaliser des transactions sur la blockchain. Le dispositif hôte HDV est par exemple un ordinateur, un téléphone mobile, une tablette ou équivalent. La connexion entre le dispositif HW et le dispositif hôte HDV peut être de type USB ou Bluetooth par exemple. Une fois relié au dispositif hôte, le dispositif HW peut interagir avec le logiciel compagnon pour permettre à un utilisateur USR de réaliser des transactions sur la blockchain BCN ou sur des sites d’échange décentralisé. Le dispositif HW peut par ailleurs communiquer avec un module de sécurité HSM ("Hardware Security Module") situé dans un datacenter. Le module HSM est classiquement un boîtier de chiffrement matériel permettant de générer, stocker et protéger des clés cryptographiques. . Le module HSM ne stocke aucune clé privée de l’utilisateur et assure seulement le contrôle de l’authenticité du dispositif HW, sa mise en service, la mise à jour de son système d’exploitation, le téléchargement de programmes d’application certifiés, etc.
Lors de la première mise en service du dispositif HW, celui-ci fournit à l’utilisateur une phrase de récupération de 24 mots que celui-ci devra conserver sur un support physique approprié, par exemple une feuille de papier ou un support inaltérable tel une plaque de métal gravée, qu'il devra conserver en lieu sûr.
Une telle conservation en lieu sûr de la phrase de récupération ne va pas sans poser de problèmes. En effet, si un tiers s’empare de la phrase de récupération, le tiers pourra accéder à l’ensemble des comptes de cryptoactifs de l’utilisateur générés à partir de la graine et transférer sur d’autres comptes les sommes qu’ils comportent, et il sera ensuite très difficile de l’identifier.
Il pourrait donc être souhaité de prévoir un moyen permettant d’offrir aux utilisateurs un moyen simple et pratique pour conserver leur phrase de récupération de manière hautement sécurisée.
Résumé
Des modes de réalisation concernent un procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur, dans lequel le serveur et le dispositif possèdent chacun une clé privée, une clé publique, un certificat signé par une autorité de certification, et une clé publique de l’autorité de certification. Selon le procédé, le dispositif et le serveur sont configurés pour exécuter les étapes suivantes : le serveur génère une clé privée éphémère, une clé publique éphémère et un certificat éphémère signé avec sa clé privée, et transfère son certificat éphémère au dispositif ; le dispositif génère une clé privée éphémère et une clé publique éphémère ; le dispositif génère une première signature de sa clé publique éphémère à partir de sa clé privé ; le dispositif génère une première clé de session à partir de sa clé privée éphémère et de la clé publique éphémère du serveur ; le dispositif chiffre la première signature au moyen de la première clé de session, pour obtenir une signature chiffrée ; le dispositif transfère au serveur un certificat éphémère comprenant sa clé publique éphémère et la signature chiffrée ; le serveur génère la première clé de session à partir de sa clé privée éphémère et de la clé publique éphémère du dispositif, et au moyen de la première clé de session, le serveur déchiffre la signature présente dans le certificat éphémère.
Selon un mode de réalisation, le serveur transfère son certificat au dispositif, le dispositif chiffre son propre certificat avec la première clé de session, le dispositif transfère au serveur son certificat chiffré avec la première clé de session, et au moyen de la première clé de session, le serveur déchiffre le certificat du dispositif.
Selon un mode de réalisation, avant de générer la première signature de sa clé publique éphémère, le dispositif concatène sa clé publique éphémère avec une donnée.
Selon un mode de réalisation, le dispositif vérifie la validité du certificat éphémère du serveur au moyen du certificat du serveur, le dispositif vérifie la validité du certificat du serveur au moyen de la clé publique de l'autorité de certification, le serveur vérifie la validité du certificat éphémère du dispositif au moyen du certificat du dispositif, et le serveur vérifie la validité du certificat du dispositif au moyen de la clé publique de certification.
Selon un mode de réalisation, le dispositif comprend un portefeuille matériel de cryptoactifs comprenant une donnée secrète principale, ou clé maître.
Selon un mode de réalisation, le portefeuille matériel est dépourvu de moyen de connexion à l’Internet et est configuré pour être relié au serveur par l’intermédiaire d’un dispositif hôte exécutant un logiciel compagnon et pourvu d’une connexion à l’Internet.
Des modes de réalisation concernent également un procédé pour la sauvegarde d’une pluralité de données secrètes détenues par un portefeuille de cryptoactifs, les données secrètes étant stockées par le portefeuille de cryptoactifs ou pouvant être générées par le portefeuille de cryptoactifs à partir d’une donnée secrète principale détenue par le portefeuille de cryptoactifs , le portefeuille de cryptoactifs étant la propriété d’un utilisateur, le procédé comprenant les étapes consistant à prévoir un programme orchestrateur exécuté par un serveur pour mettre en œuvre et superviser la sauvegarde des données et prévoir une pluralité de serveurs de sauvegarde, et dans lequel le programme orchestrateur est configuré pour établir une liaison de données sécurisée avec le portefeuille de cryptoactifs conformément au procédé qui vient d'être décrit, communiquer à chaque serveur de sauvegarde des informations relatives à l’identité de l’utilisateur, recevoir du portefeuille de cryptoactifs les données à sauvegarder, et transférer à chaque serveur de sauvegarde l’une des données à sauvegarder.
Selon un mode de réalisation, les informations relatives à l’identité de l’utilisateur comprennent au moins le prénom de l’utilisateur, le nom de famille de l’utilisateur et la date de naissance de l’utilisateur.
Selon un mode de réalisation, chaque serveur de sauvegarde possède une clé privée, une clé publique, un certificat signé par l’autorité de certification, et la clé publique de l’autorité de certification, chaque serveur de sauvegarde transfère son certificat au programme orchestrateur, qui le transfère au portefeuille de cryptoactifs, chaque serveur de sauvegarde génère une clé privée éphémère, une clé publique éphémère et un certificat éphémère signé avec sa clé privée, et transfère le certificat éphémère au programme orchestrateur qui le transfère au portefeuille de cryptoactifs, le portefeuille de cryptoactifs transfère son certificat et son certificat éphémère au programme orchestrateur, qui le transfère à chacun des serveurs de sauvegarde, chaque serveur de sauvegarde génère une deuxième clé de session à partir de sa clé privée éphémère et de la clé publique éphémère du portefeuille de cryptoactifs, le portefeuille de cryptoactifs génère la deuxième clé de session de chaque serveur de sauvegarde à partir de sa clé privée éphémère et de la clé publique éphémère du serveur de sauvegarde, le portefeuille de cryptoactifs chiffre la donnée destinée à chaque serveur de sauvegarde avec la deuxième clé de session, la transfère à l’orchestrateur qui la transfère au serveur de sauvegarde, et chaque serveur de sauvegarde déchiffre au moyen de la deuxième clé de session la donnée reçue, et la stocke dans une mémoire.
Selon un mode de réalisation, chaque serveur de sauvegarde vérifie la validité du certificat du portefeuille de cryptoactifs au moyen de la clé publique de certification, chaque serveur de sauvegarde vérifie la validité du certificat éphémère du portefeuille de cryptoactifs au moyen du certificat du portefeuille de cryptoactifs, le portefeuille de cryptoactifs vérifie la validité du certificat de chaque serveur de sauvegarde au moyen de la clé publique de certification, et le portefeuille de cryptoactifs vérifie la validité du certificat éphémère de chaque serveur de sauvegarde au moyen du certificat de chaque serveur.
Selon un mode de réalisation, des données à l’attention du portefeuille de cryptoactifs transmises au programme orchestrateur par un serveur de sauvegarde sont transmises par le programme orchestrateur au portefeuille de cryptoactifs sous une forme chiffrée au moyen de la première clé de session, et dans lequel certaines de ces données sont préalablement hachées par le serveur de sauvegarde au moyen d’une fonction de hachage, puis chiffrées au moyen de la deuxième clé de session.
Selon un mode de réalisation, le procédé comprend une étape initiale de vérification de l’identité de l’utilisateur par le programme orchestrateur, et le programme orchestrateur est configuré pour ne pas permettre la sauvegarde des données dans les serveurs de sauvegarde si la vérification d’identité n’est pas concluante.
Selon un mode de réalisation, le portefeuille de cryptoactifs est configuré pour générer la pluralité de données secrète à partir de la clé maître au moyen d’une fonction de partage de secret configurée pour générer un nombre m de données secrètes et permettre la reconstitution de la clé maître à partir d’un seuil de n données secrètes.
Selon un mode de réalisation, m est égal à 3 et n est égal à 2.
Selon un mode de réalisation, le procédé comprend une étape de restauration de tout ou partie des données secrètes dans un deuxième portefeuille de cryptoactifs, l’étape de restauration étant précédée par des étapes de récupération de tout ou partie des données secrètes dans les serveurs de sauvegarde par l’intermédiaire du programme orchestrateur, et les étapes de récupération des données secrètes dans les serveurs de sauvegarde sont précédées d’une pluralité d’étapes de vérification de l’identité de l’utilisateur par au moins une partie des serveurs de sauvegarde, un serveur de sauvegarde configuré pour vérifier l’identité de l’utilisateur étant également configuré pour refuser de restituer la donnée secrète qu’il détient si la vérification de l’identité de l’utilisateur n’est pas concluante
Selon un mode de réalisation, au moins un serveur de sauvegarde est configuré pour déléguer l’étape de vérification de l’identité à serveur spécialisé dans la vérification d’identité, le serveur de sauvegarde étant configuré pour établir une liaison de données avec le serveur spécialisé afin de mettre l’utilisateur en relation avec ce serveur.
Description sommaire des dessins
Ces caractéristiques ainsi que d'autres de la présente invention, seront mieux comprises à la lecture de la description suivante, faite à titre non limitatif en relation avec les figures jointes parmi lesquelles :
- la figure 1 précédemment décrite montre schématiquement un portefeuille de cryptoactifs et un exemple d'utilisation de celui-ci,
- la figure 2A et la figure 2B montrent un portefeuille de cryptoactifs selon l’invention et l'architecture d'un système prévu pour la mise en oeuvre d'un premier mode de réalisation du procédé selon l'invention, la figure 2A illustrant une étape de sauvegarde de données et la figure 2B une étape de restauration des données,
- la figure 3A et la figure 3B montrent un portefeuille de cryptoactifs selon l’invention et l'architecture d'un système prévu pour la mise en oeuvre d'un deuxième mode de réalisation du procédé selon l'invention, la figure 3A illustrant une étape de sauvegarde de données et la figure 3B une étape de restauration des données,
- la figure 4A décrit un algorithme exécuté par le système des figures 3A, 3B, lors de l'étape de sauvegarde de données,
- la figure 4B est un diagramme de séquences qui représente les étapes de l'algorithme de la figure 4A sous forme d'interactions entre différents éléments du système des figures 3A, 3B,
- la figure 5A décrit un algorithme exécuté par le système des figures 3A, 3B, lors de l'étape de restauration de données,
- la figure 5B est un diagramme de séquences qui représente les étapes de l'algorithme de la figure 5A sous forme d'interactions entre différents éléments du système des figures 3A, 3B,
- la figure 6A et la figure 6B montrent un portefeuille de cryptoactifs selon l’invention et l'architecture d'un système prévu pour la mise en œuvre d'un troisième mode de réalisation du procédé selon l'invention, la figure 6A illustrant une étape de sauvegarde de données et la figure 6B une étape de restauration des données, - la figure 7 montre un portefeuille de cryptoactifs selon l’invention et un exemple d'architecture de portefeuille matériel selon l'invention permettant la mise en œuvre du procédé selon l'invention,
- la figure 8 montre des étapes conduites par l'utilisateur du portefeuille matériel de la figure 7 pour la sauvegarde de la graine stockée dans le portefeuille matériel,
- la figure 9 montre des étapes conduites par l'utilisateur du portefeuille matériel de la figure 7 pour la restauration de la graine,
- la figure 10 montre un autre mode de réalisation d’un portefeuille de cryptoactifs permettant de mettre en œuvre le procédé selon l’invention,
- la figure 11 montre encore un autre mode de réalisation d’un portefeuille de cryptoactifs permettant de mettre en œuvre le procédé selon l'invention.
Description détaillée
L'invention prévoit un procédé permettant de réaliser un portefeuille de cryptoactifs offrant une fonctionnalité unique dans le domaine des portefeuilles matériels, à savoir une fonctionnalité de sauvegarde de la graine qui est automatisée tout en étant hautement sécurisée. Une telle fonctionnalité permet aux utilisateurs de s'affranchir de toutes les difficultés et dangers qui s'attachent au fait de devoir préserver eux-mêmes dans un lieu sûr une phrase de récupération. Les fonctionnalités uniques offertes par un portefeuille de cryptoactifs selon l'invention seront décrites plus loin en relation avec les figures 8, 9 et les tableaux 2 et 3. Des modes de réalisation du procédé selon l'invention seront tout d'abord décrits.
La figure 2A montre un portefeuille de cryptoactifs CW1 et un système prévu pour la mise en œuvre d'un mode de réalisation du procédé de l'invention. Le portefeuille de cryptoactifs CW1 comprend ici un dispositif HW et un dispositif hôte HDV. Le dispositif HW est un portefeuille matériel ("hardware wallet") assurant le stockage à froid d’une graine S ou clé maître, d’un ensemble de cryptoactifs. Le dispositif HW ne comporte aucun moyen de connexion à l'internet et est relié au dispositif hôte HDV, qui exécute un logiciel compagnon HSW lui permettant de se relier à l'Internet, par exemple au moyen d'une liaison USB ou Bluetooth. Le système et le procédé selon l'invention permettent de sauvegarder ou de restaurer la graine S (clé maître) stockée dans le dispositif HW.
Le système comprend essentiellement un ensemble de m serveur de sauvegarde BCKi (BCK1 , BCK2,... BCKi,... BCKm) pourvu chacun d'une mémoire de sauvegarde MEM (disque dur magnétique ou mémoire à l'état solide) pour sauvegarder des parts Si de la graine S. Chaque serveur de sauvegarde comporte un programme dorsal BEi (BE1 ,... BEi,... BEm), ou programme "back-end", conçu pour la mise en œuvre du procédé. Chaque serveur de sauvegarde BCKi est également associé à un module de sécurité HSM. Selon le procédé de l'invention, le dispositif HW est configuré pour diviser la graine S en une pluralité de données secrètes Si (S1 , S2...Si,...Sm) qui seront sauvegardées sur les serveurs BCKi. Plutôt qu'un simple fractionnement, qui n'est toutefois pas exclu du champ de la présente invention, cette "division" est de préférence assurée au moyen d'une fonction de partage de secret SS permettant de générer un nombre m de données secrètes appelées "parts " ("shares"), et permettant la reconstitution de la graine à partir d’un seuil de n données secrètes Si :
S1 , S2,... , Si,... , Sm = SS (S)
Par exemple si m est égal à 3 et n égal à 2, la fonction SS permet de diviser la graine en trois parts S1, S2, S3 mais deux parts seulement seront nécessaires pour reconstituer la graine.
Lorsque l'utilisateur souhaite sauvegarder sa graine, le dispositif HW établit avec chaque serveur de sauvegarde BCKi, par l'intermédiaire du dispositif hôte HDV, des liaisons de données LNKi (LNK1 à LNKm), par exemple de type HTTPS. Ces liaisons de données sont ensuite sécurisées par la création de canaux sécurisés de type SCP ("Secure Channel Protocol") entre le dispositif HW et chaque serveur de sauvegarde BCKi, d'une manière qui va être décrite.
La création de tels canaux sécurisés est assurée au moyen d'une infrastructure à clés publiques gérée par une autorité de certification CA. Le dispositif HW et les serveurs de sauvegarde BCKi possèdent chacun une clé privée, une clé publique, un certificat signé par l'autorité de certification, ou certificat statique, ainsi que la clé publique de l'autorité de certification. La notation suivante sera utilisée dans ce qui suit : pL : clé privée de l'autorité de certification
PL : clé publique de l'autorité de certification pD : clé privée du dispositif HW
PD : clé publique du dispositif HW
CD = [PD, Sign(pL, PD)] : certificat du dispositif (certificat statique), comprenant sa clé publique PD et une signature de sa clé publique au moyen de la clé privée pL de l'autorité de certification pBi : clé privée d'un serveur BCKi (pour i allant de i à m)
PBi : clé publique d'un serveur BCKi (pour i allant de i à m)
CBi = [PBi, Sign(pL, PBi)] : certificat d'un serveur BCKi (certificat statique), comprenant sa clé publique PD et une signature de sa clé publique au moyen de la clé privée pL de l'autorité de certification.
La fonction de signature "Sign" est par exemple générée au moyen d'un algorithme de signature ECDSA basé sur les courbes elliptiques ("Elliptic Curve Digital Signature Algorithm").
L'autorité de certification CA est de préférence détenue par le fabricant du dispositif HW, pour lui permettre de contrôler l'allocation de certificats CBi aux serveurs de sauvegarde BCKi. Les serveurs de sauvegarde BCKi peuvent quant à eux être détenus par le fabricant du dispositif HW, ou être des serveurs de tiers partenaires participant à la mise en oeuvre du procédé. Les clés pBi, PBi des serveurs de sauvegarde BCKi sont détenues par leurs modules HSM respectifs, qui prennent en charge les calculs cryptographiques réalisés au moyen de ces clés. Dans ce qui suit et dans un souci de simplification du langage, on considérera que de tels calculs cryptographiques sont réalisés par les serveurs eux-mêmes.
Pour mettre en œuvre un canal de communication sécurisé, un échange de clés est prévu entre le dispositif HW et chaque serveur de sauvegarde BCKi, permettant de générer des clés de session kBi propres à chaque serveur BCKi mais connues du dispositif HW. Cet échange de clés est par exemple un échange de clés Diffie Hellman réalisé conformément aux étapes suivantes : i) chaque serveur de sauvegarde BCKi génère une paire de clés privée peBi et publique PeBi éphémères au moyen d'un générateur de clés asymétriques, puis communique sa clé publique éphémère PeBi au dispositif HW dans un certificat éphémère CeBi qu'il a signé avec sa clé privée pBi, ainsi que son certificat CBi signé par l'autorité de confiance :
CeBi = [PeBi, Sign(pBi, PeBi)]
CBi = [PBi, Sign(pL, PBi)] ii) le dispositif HW génère lui-même une paire de clés privée peD et publique PeD éphémères, puis communique sa clé publique éphémère PeD aux serveurs de sauvegarde BCKi dans un certificat éphémère CeD qu'il a signé avec sa clé privée pD, ainsi que son certificat CD signé par l'autorité de confiance, soit :
CeD = [PeD, Sign(pD, PeD)]
CD = [PD, Sign(pL, PD)] iii) chaque serveur de sauvegarde BCKi vérifie la signature de la clé publique éphémère PeD du dispositif HW au moyen de la clé publique PD présente dans son certificat CD, puis vérifie la signature de la clé publique PD présente dans le certificat CD au moyen de la clé publique PL de l'autorité de certification, ou vice-versa (vérification de la signature de la clé publique PD avant vérification de la signature de la clé publique éphémère PeD), iv) de même, le dispositif HW vérifie la signature de la clé publique éphémère PeBi de chaque serveur BCKi au moyen de la clé publique PBi présente dans le certificat CB, puis vérifie la signature de la clé publique PBi présente dans le certificat CB au moyen de la clé publique PL de l'autorité de certification, ou vice-versa, v) chaque serveur de sauvegarde BCKi génère une clé de session éphémère kBi à partir de sa clé privée éphémère peBi et de la clé publique éphémère PeD du dispositif HW, au moyen d'une fonction d'échange de clés telle, par exemple la fonction ECDH (échange de clé Diffie Hellman basée sur les courbes elliptiques ou "Elliptic Curve Diffie-Hellman"), soit : kBi = ECDH(peBi, PeD) vi) le dispositif HW génère la clé de session éphémère kBi de chaque serveur de sauvegarde BCKi à partir de sa clé privée éphémère peD et de la clé publique éphémère PeBi du serveur de sauvegarde BCKi, au moyen de la même fonction, soit : kBi = ECDH(peD, PeBi)
Après avoir généré les parts Si de la graine S, le dispositif HW conduit des étapes de chiffrement symétrique de chaque part Si avec la clé de session kBi commune au serveur de sauvegarde BCKi à qui la part Si doit être envoyée, qui forme donc une clé partagée. Dans un exemple simple de mise en œuvre, le dispositif HW génère trois parts S1, S2, S3 (le seuil n pouvant alors être égal à 2 ou à 3) et trois serveurs de sauvegarde BCK1, BCK2, BCK3 sont prévus. Chaque serveur BCKi génère sa propre clé de session kB1, kB2, kB3 et le dispositif HW génère de son côté chacune de ces clés de sessions après un échange de clés avec chaque serveur de la manière qui vient d'être décrite. Ensuite, le dispositif HW conduit des étapes de chiffrement symétrique des parts S1 , S2, S3 au moyen de ces clés, soit :
- chiffre la part S1 avec la clé kB1 , soit {S1}kB1 , puis l'envoie au serveur BCK1 ,
- chiffre la part S2 avec la clé kB2, soit {S2}kB2, puis l'envoie au serveur BCK2,
- chiffre la part S3 avec la clé kB3, soit {S3}kB3, puis l'envoie au serveur BCK3.
Chaque serveur de sauvegarde BCKi déchiffre ensuite la part chiffrée {Si}kBi qu'il a reçu du dispositif HW, et la stocke dans sa mémoire MEM.
Selon le procédé, et comme illustré sur la figure 2B, la restauration de la graine S est réalisée dans un deuxième portefeuille matériel noté HW. Il peut s'agir d'un autre dispositif que le dispositif HW si celui-ci a été perdu, volé ou détruit. Il peut aussi s'agir du dispositif HW si celui-ci a été réinitialisé, le dispositif HW étant alors considéré comme un "autre" dispositif sous l'angle du procédé, puisqu'il ne possède plus la graine.
Pour la restauration de la graine, les étapes de création de canaux sécurisés décrites ci-dessus sont répétées. De nouvelles clés de sessions kBi sont générées. Ensuite, chaque serveur chiffre la part Si qu'il détient avec la clé de session kBi, soit {Si}kBi, puis l'envoie au dispositif HW. Ce dernier déchiffre ensuite chaque part Si au moyen de la clé de session kBi correspondante, puis reconstitue la graine S au moyen de la fonction inverse de celle qui a permis de générer les parts Si, notée "SS-1" :
S = SS-1 (S1 , S2,... , Si,... , Sm)
La figure 3A montre l'architecture d'un système permettant de mettre en œuvre un autre mode de réalisation du procédé de l'invention. Dans ce mode de réalisation, un serveur ORCSR 1 est interposé entre le dispositif hôte HDV et les serveurs de sauvegarde BCKi. Ce serveur, appelé à titre non limitatif "serveur orchestrateur", exécute un programme dorsal ou "back-end" ORC1 appelé dans ce qui suit "programme orchestrateur" ou "orchestrateur". Le serveur ORCSRV1 est relié à un module de sécurité HSM pourvu d'une clé privée pO, d'une clé publique PO, et d'un certificat CO (certificat statique) signé par l'autorité de certification CA :
CO = [PO, Sign(pL, PO)]
Pour la mise en œuvre du procédé, une première liaison de données LNK1 est établie entre le dispositif HW et l'orchestrateur ORC1 au moyen du dispositif hôte HDV, par exemple une liaison HTTPS. Une pluralité de liaisons de données LNK2i sont également établies entre l'orchestrateur et les serveurs de sauvegarde BCKi, par exemple des liaisons HTTPS, VPN IPsec, etc.
La liaison de données entre l'orchestrateur et le dispositif HW est sécurisée par la création d'un canal sécurisé selon la même technique que celle décrite ci-dessus : i) l'orchestrateur ORC1 génère un paire de clés privée PeO et publique PeO puis communique sa clé publique éphémère PeO au dispositif HW dans un certificat éphémère CeO qu'il a signé avec sa clé privée pO, accompagné de son certificat CO signé par l'autorité de confiance, soit :
CeO = [PeO, Sign(pO, PeO)]
CO = [PO, Sign(pL, PO)] ii) le dispositif HW génère une paire de clés privée peD et publique PeD éphémères puis communique sa clé publique éphémère PeD à l'orchestrateur dans un certificat éphémère CeD qu'il a signé avec sa clé privée pD, accompagné de son certificat CD signé par l'autorité de confiance, soit :
CeD = [PeD, Sign(pD, PeD)]
CD = [PD, Sign(pL, PD)] iii) l'orchestrateur ORC1 vérifie la signature de la clé publique éphémère PeD du dispositif HW au moyen de la clé publique PD présente dans le certificat CD, puis vérifie la signature de la clé publique PD au moyen de la clé publique PL de l'autorité de certification, ou vice-versa, iv) de même, le dispositif HW vérifie la signature de la clé publique éphémère PeO de l'orchestrateur au moyen de la clé publique PO présente dans le certificat CO, puis vérifie la signature de la clé publique PO au moyen de la clé publique PL de l'autorité de certification, ou vice-versa, v) l'orchestrateur ORC1 génère une clé de session éphémère kO à partir de sa clé privée éphémère peO et de la clé publique éphémère PeD du dispositif HW : kO = ECDH(peO, PeD) vi) le dispositif HW génère la clé de session éphémère kO à partir de sa clé privée éphémère peD et de la clé publique éphémère PeO de l'orchestrateur : kO = ECDH(peD, PeO) Une fois le canal sécurisé créé entre l'orchestrateur et le dispositif HW, des données à l'attention des serveurs de sauvegarde BCKi peuvent être envoyées en toute sécurité par le dispositif HW à l'orchestrateur, grâce à un chiffrement symétrique au moyen de la clé de session partagée kO de tout ou partie des données échangées. Réciproquement l'orchestrateur peut communiquer au dispositif HW sous une forme chiffrée au moyen de la clé kO des données reçues des serveurs de sauvegarde BCKi.
Des canaux sécurisés sont également créés entre le dispositif HW et les serveurs de sauvegarde BCKi au moyen de clés de session kBi qui sont générées au terme d'un échange de clés par l'intermédiaire de la liaison de données LNK1 , l'orchestrateur agissant comme passerelle ou "serveur proxy" entre le dispositif HW et les serveurs BCKi.
Après exécution de ces étapes, on distingue :
- à travers la liaison de données LNK1 , un canal sécurisé par la clé de session kO partagée par l'orchestrateur et le dispositif HW, qui permet de chiffrer les données échangées entre l'orchestrateur et le dispositif HW,
- à travers les liaisons de données LNK2i, des canaux sécurisés par les clés de session kBi propre à chaque serveur de sauvegarde BCKi et connues du dispositif HW, ce qui permet au dispositif HW d'échanger avec chaque serveur BCKi des données sous forme chiffrée.
Il peut par ailleurs être prévu, dans certains cas, de chiffrer avec la clé kO des données qui sont reçues par l'orchestrateur sous une forme chiffrée par les clés kBi, ce qui correspond à un surchiffrement de ces données.
Dans un mode de réalisation, le procédé de l'invention met en œuvre deux perfectionnements concernant la transmission du certificat CD du dispositif HW dans le cadre d'un échange de clés avec un serveur quelconque. En effet l'envoi par le dispositif de son certificat CD dans le cadre d'un tel échange de clés, constitue une faille en termes de confidentialité, la clé publique PD présente dans le certificat étant exposée en cas de surveillance de la ligne. Par ailleurs, il a été démontré qu'une signature ECDSA permet de retrouver la valeur de la clé publique correspondante. Ainsi, la transmission de la signature Sign(pD, PeD) de la clé publique éphémère PeD dans le certificat éphémère CeD peut également permettre à un tiers de découvrir la clé publique PD.
Ces deux perfectionnements consistent respectivement dans le chiffrement du certificat CD et dans le chiffrement de la signature Sign(pD, PeD). A titre d'exemple, on décrira la mise en œuvre de ces procédés dans le cadre du calcul de la clé de session kO décrite précédemment. Les étapes relatives à l'échange de clés précédemment décrites sont modifiées comme suit : i) l'orchestrateur génère une clé privée éphémère peO, une clé publique éphémère PeO et un certificat éphémère CeO signé avec sa clé privée pO, et transfère son certificat éphémère CeO au dispositif ainsi que son certificat CO : CeO = [PeO, Sign(pO, PeO)]
CO = [PO, Sign(pL, PO)] ii) le dispositif HW génère une clé privée éphémère peD et une clé publique éphémère PeD et calcule une première signature Sign(pD, PeD) de sa clé publique éphémère PeD à partir de sa clé privé pD et au moyen de l'algorithme ECDSA, iii) le dispositif génère la clé de session kO à partir de sa clé privé éphémère peD et de la clé publique éphémère PeO de l'orchestrateur , iv) le dispositif chiffre son certificat CD avec la clé de session kO :
{CD}kO v) le dispositif chiffre la première signature Sign(pD, PeD) au moyen de la clé de session kO :
{Sign(pD, PeD)}kO vi) le dispositif transfère à l'orchestrateur son certificat CD chiffré avec la clé de session kO ainsi que son certificat éphémère CeD comprenant la signature de sa clé publique éphémère PeD chiffrée avec la clé de session kO :
{CD}kO || CeD soit
{CD}kO || PeD || {Sign(pD, PeD)}kO
("||" étant le symbole de la concaténation) vii) l'orchestrateur génère la clé de session kO à partir de sa clé privé éphémère peO et de la clé publique éphémère PeD reçue du dispositif , et viii) au moyen de la clé de session kO, l'orchestrateur déchiffre la signature présente dans le certificat éphémère CeD et déchiffre le certificat CD du dispositif.
Il apparaîtra clairement à l'homme de l'art que ces deux procédés de chiffrement du certificat CD et de chiffrement de la signature de la clé publique éphémère PeD peuvent être mis en œuvre séparément, la clé publique pouvant être chiffrée sans chiffrer la signature ou réciproquement. Il apparaîtra également à l'homme de l'art que ces deux procédés sont d'application universelle et peuvent être mis en œuvre lors de la création de tout canal sécurisé basé sur un échange de clés et la génération de signatures avec l'algorithme ECDSA.
De retour à la figure 3A, il ressort de ce qui précède que la prévision de l'orchestrateur ORC1 permet de réduire le nombre de liaison de données entre le dispositif HW et les serveurs de sauvegarde BCKi, ces liaisons étant remplacées par l'unique liaison de données LNK1 entre le dispositif HW et l'orchestrateur, tout en assurant un degré de sécurité supplémentaire grâce à la possibilité de surchiffrer des données transitant par la liaison LNK1, comme indiqué plus haut. Il est de plus possible de préserver la confidentialité de la clé publique PD grâce aux perfectionnements qui viennent d'être décrits. La prévision de l'orchestrateur présente divers autres avantages qui seront décrits plus loin en relation avec la mise en œuvre d'étapes de vérification de l'identité de l'utilisateur.
L'étape de sauvegarde de la graine S peut dans ce cas être mise en œuvre comme suit, en référence à la figure 3A : i) établissement de la liaison LNK1 entre le dispositif HW et l'orchestrateur et envoi par le dispositif HW d'une requête en sauvegarde BCKRQ à l'orchestrateur, ii) génération par l'orchestrateur d'un identifiant aléatoire BCKID de la sauvegarde, établissement des liaisons LNK2i entre l'orchestrateur et les serveurs de sauvegarde BCKi, envoi par l'orchestrateur aux serveurs de sauvegarde BCKi de l'identifiant BCKID, iii) création du canal sécurisé entre le dispositif HW et l'orchestrateur ORC1 au moyen de la clé de session kO, iv) création de canaux sécurisés entre le dispositif HW et les serveurs de sauvegarde BCKi au moyen des clés de session kBi, par l'intermédiaire de l'orchestrateur ORC1 , v) génération par le dispositif HW des parts Si de la graine S :
S1 , S2,... , Si,... , Sm = SS (S) vi) chiffrement par le dispositif HW de chaque part Si au moyen de la clé de session kBi du serveur de sauvegarde BCKi à qui la part Si est destinée, vii) envoi par le dispositif HW de l'ensemble des parts chiffrées {Si}kBi à l'orchestrateur :
{S1}kB 11 |{S2}kB211... . | |{Si}kBi 11... | |{Sm}kBm viii) envoi par l'orchestrateur à chaque serveur de sauvegarde BCKi de la part chiffrée {Si}kBi qui lui est destinée, ix) déchiffrement par chaque serveur BCKi de la part Si qui lui est communiquée, et stockage dans sa mémoire en association avec l'identifiant de la sauvegarde BCKID.
Par ailleurs, l'étape de restauration de la graine S dans un nouveau dispositif HW, illustrée sur la figure 3B, déclenchée à la demande de l'utilisateur USR, comprend les étapes suivantes, : i) établissement de la liaison LNK1 entre le dispositif HW et l'orchestrateur et envoi par le dispositif HW d'une requête en restauration RESTRQ à l'orchestrateur, accompagnée de l'identifiant de la sauvegarde BCKID, ii) établissement des liaisons LNKi entre l'orchestrateur et les serveurs de sauvegarde BCKi, et envoi par l'orchestrateur aux serveurs de sauvegarde BCKi de l'identifiant BCKID, pour qu'ils soient informés de la restauration à réaliser, iii) création du canal sécurisé entre le dispositif HW et l'orchestrateur ORC1 au moyen d'une nouvelle clé de session kO, iv) création de canaux sécurisés entre le dispositif HW et les serveurs de sauvegarde BCKi au moyen de nouvelles clés de session kBi, par l'intermédiaire de l'orchestrateur ORC1 , v) lecture par chaque serveur de sauvegarde BCKi, dans sa mémoire, au moyen de l'identifiant BCKID, de la part Si qu'il détient, et chiffrement de celle-ci au moyen de la nouvelle clé de session kBi, vi) transmission à l'orchestrateur, par chaque serveur de sauvegarde BCKi, de la part chiffrée {Si}kBi, vii) collecte par l'orchestrateur de toutes les parts chiffrées {Si}kBi fournies par les serveurs de sauvegarde BCKi :
{S1}kB1, {S2}kB2,...., {Si}kBi,... , {Sm}kBm viii) transmission au dispositif HW de chaque part chiffrée {Si}kBi, une après l'autre ou toutes ensemble :
{S1}kB 11 |{S2}kB211... . | |{Si}kBi 11... | |{Sm}kBm ix) déchiffrement, par le dispositif HW, de chaque part Si au moyen de la clé de session kBi du serveur de sauvegarde BCKi correspondant :
Si = {Si}’1 kBi x) reconstitution de la graine par le dispositif HW et stockage de celle-ci dans sa mémoire :
S = SS’1 (S1 , S2,... , Si,... , Sm)
Il sera noté que dans un mode de réalisation l'orchestrateur peut ne collecter que n parts nécessaires à la reconstitution de la graine, si n est inférieur à m. Dans ce cas, la graine est reconstituée à partir des n parts récupérées :
S = SS’1 (S1 , S2,... , Si,... , Sn)
On a supposé dans ce qui précède que l'identifiant de la sauvegarde BCKID a été conservé par le logiciel compagnon HSW du dispositif hôte HDV malgré la perte du dispositif HW utilisé lors de la sauvegarde. Dans un mode de réalisation permettant de prévenir le cas où l’utilisateur aurait désinstallé définitivement le logiciel compagnon HSW, un serveur de comptes clients UASRV peut être prévu, comprenant un compte utilisateur UACC dans lequel diverses données concernant l'utilisateur sont conservées, notamment l'identifiant BCKID de la sauvegarde. Le serveur UASRV est associé à un module de sécurité HSM recevant une clé privée pC, une clé publique PC, un certificat CC signé par l'autorité de certification, et la clé publique PL de cette dernière. Dans ce cas, le dispositif HW établit une liaison de données avec le serveur UASRV grâce à un échange de clés permettant de définir une clé de session pour la création d'un canal sécurisé, avec vérification réciproque des certificats. Une fois le canal sécurisé établi, le logiciel compagnon HSW se connecte au compte client UACC pour récupérer l’identifiant BCKID. Dans une variante, l’identifiant BCKID est stocké sur le serveur UASRV mais n'est pas communiqué au logiciel compagnon. Une liaison sécurisée est établie entre le serveur UASRV et l'orchestrateur ORC1. L'orchestrateur transfère l'identifiant BCKID au serveur UASRV au moment de la sauvegarde et réciproquement reçoit l'identifiant BCKID du serveur UASRV lorsque l'utilisateur veut restaurer sa graine.
Dans un mode de réalisation, l'identité de l'utilisateur est également associée au processus de sauvegarde, en définissant un ensemble d'informations formant une "identité pivot" permettant de l'identifier. Les informations formant l'identité pivot comprennent par exemple le prénom, le nom et la date de naissance de l'utilisateur, et optionnellement d'autres informations telles que son lieu de naissance. Ces informations sont collectées par le logiciel compagnon et sont communiquées à l'orchestrateur qui les rassemble pour former une chaîne binaire que l'on désignera "données de la sauvegarde" BCKDT. Les données BCKDT peuvent contenir d'autres informations comme la date et l'heure de la sauvegarde, et un nom donné par l'utilisateur à la sauvegarde (pour lui permettre ultérieurement de distinguer plusieurs sauvegardes, s'il détient plusieurs portefeuilles matériels).
A l'initialisation de la sauvegarde, comme montré sur la figure 3A, l'orchestrateur communique les données BCKDT aux serveurs de sauvegarde BCKi qui vont les associer, ainsi que l'identifiant BCKID, aux parts Si sauvegardées. Pour des raisons de confidentialité, il pourrait être préféré, dans certains modes de réalisation, que l'orchestrateur ne conserve pas les données BCKDT une fois la sauvegarde réalisée. Les données BCKDT sont dans ce cas uniquement conservées par les serveurs BCKi, qui les communiquent à l'utilisateur USR pour confirmation par ce dernier de son identité au moment de la restauration, comme montré sur la figure 3B.
Dans un mode de réalisation du procédé, l'identité pivot de l'utilisateur est vérifiée au cours d'au moins une étape de vérification d'identité désignée "IDV" ("Identity Vérification") qui est conduite avant la restauration de la graine. Dans un mode de réalisation, plusieurs étapes de vérification d'identité IDVi sont de préférence prévues avant de procéder à la restauration de la graine, ces étapes étant conduites par tout ou partie des serveurs de sauvegarde BCKi sollicités pour la restitution d'une part Si de la graine S.
Dans un mode de réalisation montré sur la figure 3B, ces étapes de vérification d'identité sont confiées à des prestataires spécialisés au lieu d'être réalisées par les serveurs de sauvegarde BCKi eux-mêmes. De tels prestataires possèdent des serveurs IDVSRVi exécutant chacun un service de vérification d'identité automatisé IDVSi accessible via une passerelle GTW ("Gateway"). Chaque serveur de sauvegarde BCKi peut se voir attribuer un serveur IDVSRVi différent, et être configuré pour se relier à la passerelle GTW du service IDVSi exécuté par ce serveur. De préférence, de tels services IDVSi ne sont pas entièrement automatisés, au moins pour une partie d'entre eux, et incluent une intervention humaine notamment en cas de doute sur l'identité d'une personne. Ainsi, chaque serveur de sauvegarde BCKi ou au moins une partie d'entre eux, est configuré pour réaliser une étape IDVi de vérification de l'identité pivot de l'utilisateur lorsqu'il reçoit une demande de restitution d'une part de la graine. Le serveur est alors de préférence configuré pour refuser de restituer la part si cette vérification n'est pas concluante.
Dans un mode de réalisation, l’étape de sauvegarde de la graine est également précédée d’une étape initiale IDVO, conduite par l'orchestrateur ou supervisée par celui-ci, de vérification de l'identité pivot de l'utilisateur (soit au moins son prénom, son nom et sa date de naissance). Dans ce cas, un serveur IDVSRVO est également associé à l'orchestrateur ORC1 , et l'orchestrateur est configuré pour se relier à une passerelle GTW d'un service IDVSO exécuté par ce serveur pour la réalisation de l'étape IDVO.
Au cours de l'étape optionnelle IDVO précédant la sauvegarde ou de chacune des étapes IDVi intervenant avant la restitution des parts de la graine, l'orchestrateur met l'utilisateur USR en relation avec le service IDVSO ou IDVSi approprié, via la passerelle GTW appropriée. L'utilisateur doit réaliser certaines actions qui lui sont demandées par l'intermédiaire de l'écran du dispositif hôte HDV et la caméra dont il est équipé (par exemple une caméra de téléphone mobile, une webcam d'ordinateur personnel, etc.). A titre d’exemple, le service IDVSO ou IDVSi lui demande de présenter une pièce d'identité valide comprenant une photo de sa personne, de prendre une photo de la pièce d'identité avec sa caméra et de la lui envoyer Le service IDVSO ou IDVSi lui demande ensuite de prendre une photo (selfie) ou une vidéo de son visage et de l'envoyer. Le service IDVSO ou IDVSi vérifie ensuite l'authenticité de la pièce d'identité à partir de la photo ou de la vidéo de son visage, et la pièce d'identité, une fois vérifiée, lui permet de vérifier les données de l'identité pivot avec un degré de certitude qui peut, dans certains modes de réalisation, donner lieu à un score. Le résultat de cette vérification, et optionnellement le score, est communiqué à l'orchestrateur. Dans un mode de réalisation, les étapes d'IDV peuvent également inclure des vérifications sur des bases gouvernementales.
Bien que l'étape IDVO ne soit pas aussi critique que celles réalisées par les serveurs BCKi au moment de la restitution des parts Si, elle permet de s'assurer que l'utilisateur n'a pas fait d'erreur en fournissant les informations relatives à son identité, qui sont incorporées dans les données BCKDT. Par ailleurs, les informations collectées par l'orchestrateur au cours de cette étape, telle que la photo de sa pièce d'identité et la photo ou la vidéo de son visage, peuvent optionnellement être communiquées aux serveurs de sauvegarde BCKi par un canal de communication spécifique, puisque ces informations ne font pas partie des données de la sauvegarde BCKDT.
Dans un mode de réalisation, l'orchestrateur ORC1 peut suspendre le processus de sauvegarde de la graine s'il estime que la vérification initiale de l’identité de l’utilisateur n’est pas concluante ou se voit attribuer un score trop faible. Par ailleurs, dans un autre mode de réalisation ou en complément, l'orchestrateur reçoit des serveurs de sauvegarde BCKi des informations sur le succès des étapes de vérification d’identité IDVi qu'ils ont conduites ou qui ont été conduites par les prestataires auxquels ils sont affiliés. Si un nombre déterminé de serveurs BCKi n’a pas vérifié avec succès l’identité de l’utilisateur et refuse de restituer les parts Si qu’ils détiennent, l'orchestrateur peut être configuré pour suspendre la restitution des parts Si par les serveurs qui ont vérifié avec succès l’identité de l’utilisateur. L'orchestrateur peut optionnellement décider de soumettre l’utilisateur à une étape supplémentaire de vérification de son identité.
Dans une variante, ou en complément, l'orchestrateur reçoit de chaque serveur de sauvegarde BCKi ayant conduit une étape de vérification d'identité, un score de certitude quant à l’identité de l’utilisateur. Si la moyenne des scores est inférieure à un premier seuil, et/ou si l’un des scores est inférieur à un deuxième seuil, l'orchestrateur suspend le processus de restauration et optionnellement soumet l’utilisateur à une étape supplémentaire de vérification de son identité.
Dans le cas, ultime, où l’utilisateur aurait fermé son compte sur le serveur de compte UASRV, aurait désinstallé le logiciel compagnon en effaçant les données qu'il comportait, et aurait perdu son portefeuille matériel HW et ne pourrait donc plus récupérer l'identifiant de la sauvegarde BCKID, une solution peut être prévue pour lui permettre de récupérer sa graine. L'utilisateur devra alors se soumettre à une pluralité d'étapes individuelles de vérification de son identité auprès de chaque serveur BCKi pour récupérer chaque part Si de la graine. Une procédure faisant intervenir un officier ministériel, tel un notaire, peut également être prévue. Chaque prestataire d'IDV pourra également vérifier que sa démarche est légitime en s'assurant qu'il n'existe aucun compte attaché à cet utilisateur dans le serveur de comptes du système, et confier à des personnes physiques des procédures d'investigation plus approfondies, telles que la conduite d’un entretien téléphonique avec l’utilisateur, la conduite d’une vidéo conférence avec l’utilisateur, la conduite d’un entretien en face à face avec l’utilisateur, la validation d'un parcours scolaire ou d’un parcours d'employé de l’utilisateur, etc.
Il apparaîtra clairement à l'homme de l'art que le procédé de l'invention est susceptible de divers autres modes de réalisation et variantes. Notamment, les données de la sauvegarde BCKID pourraient, dans un mode de réalisation, inclure sous une forme compressée les données recueillies à l'étape IDVO pour vérifier l'identité pivot de l'utilisateur, telle que la photo ou la vidéo de son visage et une photo d’une pièce d'identité. Les étapes automatisées de vérification de l’identité pivot de l’utilisateur telles que conduites par des services IDVSi exécutés par des serveurs IDVSRVi ou par les serveurs de sauvegarde BCKi eux-mêmes, peuvent comprendre au moins deux des étapes suivantes : acquisition, par l’intermédiaire d’une caméra, d’une photo d’une pièce d’identité non périmée comprenant une photo de l’utilisateur ; acquisition, par l’intermédiaire d’une caméra, d’une ou de plusieurs photos du visage de l’utilisateur ; acquisition, par l’intermédiaire d’une caméra, d’un enregistrement vidéo montrant le visage de l’utilisateur en mouvement, avec détection du vivant pour vérifier que l’utilisateur est réel ; acquisition d’une justification de domicile, telle une facture d’électricité, de téléphone ; acquisition d’une empreinte digitale de l’utilisateur ; acquisition d’un code de validation reçu par l’utilisateur dans un message téléphonique, par email ou par courrier ; activation par l’utilisateur d’un lien reçu par l’utilisateur dans un message téléphonique, par email ou par courrier, et acquisition d’un hologramme présent sur une pièce d'identité non périmée.
On décrira maintenant en relation avec la figure 4A un exemple d'algorithme de sauvegarde de la graine applicable au système de la figure 3A et mettant en œuvre divers aspects des modes de réalisation du procédé précédemment décrits. La figure 4B est un diagramme de séquences qui représente les étapes de l'algorithme sous forme d'interactions entre :
- l'utilisateur USR,
- le dispositif HW et son dispositif hôte HDV (considérés comme une seule et même entité formant le portefeuille de cryptoactifs CW1),
- I'orchestrateur ORC1 et le module de sécurité HSM qui lui est associé (considérés également comme une seule et même entité), et
- le serveur IDVSRVO associé à I'orchestrateur pour réaliser l'étape IDVO de vérification de l'identité de l'utilisateur,
- les serveurs de sauvegarde BCKi, et
- les serveurs IDVSRVi associés aux serveurs BCKi pour réaliser les étapes de vérification d'identité ultérieures, au moment de la restauration de la graine.
Certaines fonctions utilisées dans l'algorithme sont indiquées dans le tableau 1 ci-après, à titre d'exemple non limitatif :
[Tab 1]
Description de l'algorithme, en relation avec les figures 4A et 4B.
B1. Initialisation de la sauvegarde L’utilisateur USR sélectionne dans le dispositif HW une option de sauvegarde de la graine. L’utilisateur, par l'intermédiaire du dispositif hôte HDV, crée un compte de sauvegarde sur le serveur de compte UASRV. Le dispositif HW établit une liaison de données avec l'orchestrateur ORC1 et lui envoie la requête en sauvegarde :
[HW — > ORC1]
BCKRQ
Optionnellement le dispositif HW offre la possibilité à l'utilisateur de choisir le nombre m de parts Si qu’il souhaite générer pour la sauvegarde de la graine, et le seuil n correspondant au nombre de parts nécessaires à la reconstitution de la graine S. Toujours de manière optionnelle, le dispositif HW peut présenter à l'utilisateur une liste de serveurs de sauvegarde BCKi, certains pouvant être des partenaires externes, et demander à l’utilisateur d’indiquer ceux qu’il souhaite utiliser. Sinon, ceux-ci sont sélectionnés automatiquement par l'orchestrateur. L'orchestrateur ORC1 établit une liaison de données avec les serveurs BCKi, puis engage le processus de sauvegarde selon les étapes décrites dans ce qui suit.
B2. Génération et envoi au dispositif HW et aux serveurs BCKi de l'identifiant de la sauvegarde
[ORC1 BCKi, HW] BCKID
L'orchestrateur ORC1 génère l'identifiant BCKID de la sauvegarde, par exemple un nombre aléatoire, et le transfère au dispositif HW et aux serveurs BCKi.
B3. Réalisation d’une vérification d’identité IDVO par le serveur IDVSRVO
[IDVSRVO] IDVO
L'orchestrateur ORC1 connecte l’utilisateur au serveur IDVSRVO à travers une passerelle GTW. Le service IDVSO procède à une vérification de l’identité pivot de l’utilisateur IDVO.
B4. Confirmation par l'orchestrateur du succès de la vérification d'identité
IDV_OK — > HW
Le serveur IDVSRVO confirme à l'orchestrateur ORC1 que l’IDV a été réalisée avec succès, et l'orchestrateur ORC1 confirme à l’utilisateur par l'intermédiaire du dispositif HW que son identité a été vérifiée et que l'étape de sauvegarde de la graine peut être initiée. A l'occasion de cette étape l'orchestrateur ORC1 peut générer les données de la sauvegarde BCKDT, et les envoyer au dispositif HW.
B5. Authentification mutuelle et création d’un canal sécurisé entre l'orchestrateur et le dispositif
B5.1 Génération par l'orchestrateur d'un certificat éphémère
(peO, PeO) = AsymKeyGen()
Sign(pO, ReO||PeO)
CeO = PeO||Sign(pO, ReO||PeO) L'orchestrateur ORC1 génère une clé privée éphémère peO et une clé publique éphémère PeO. L'orchestrateur calcule la signature de sa clé publique éphémère PeO au moyen de sa clé privée pO. Dans une variante retenue ici, l'orchestrateur calcule la signature de sa clé publique éphémère PeO après avoir concaténée celle-ci avec une donnée ReO. La donnée ReO spécifie par exemple le rôle que joue le serveur orchestrateur dans le processus, par exemple le rôle d’orchestrateur pour l’établissement d’un canal sécurisé. L'orchestrateur génère ensuite un certificat éphémère CeO par concaténation de la clé publique éphémère PeO et de la signature.
B5.2 Envoi au dispositif des certificats de l'orchestrateur
CeO||CO — > HW
L'orchestrateur ORC1 envoie au dispositif HW son certificat éphémère et son certificat CO.
B5.3. Vérification par le dispositif des certificats de l'orchestrateur
Verif CeO, Verif CO
Le dispositif HW vérifie la chaîne de certificats de l'orchestrateur, de la manière décrite plus haut, au moyen de la clé publique PL de l'autorité de certification.
B5.4. Génération par le dispositif HW d’une clé de session kO et d’un certificat éphémère
(peD, PeD) = AsymKeyGen() kO = ECDH(peD, PeO)
Sign(pD, ReD||PeD)
{Sign(pD, ReD||PeD)}kO
CeD = PeD||{Sign(pD, ReD||PeD)}kO
{CD}kO
Le dispositif HW génère une clé privée éphémère peD et une clé publique éphémère PeD, puis une clé de session kO à partir de sa clé privée éphémère peD et de la clé publique éphémère PeO de l'orchestrateur au moyen de l’algorithme ECDH. Le dispositif HW calcule ensuite la signature de sa clé publique éphémère PeD au moyen de sa clé privée pD, ici après avoir concaténé la clé publique éphémère PeD avec une donnée ReD. La donnée ReD spécifie par exemple le rôle que joue HW dans le processus. Le dispositif HW chiffre ensuite la signature de sa clé publique éphémère avec la clé de session kO, conformément au procédé de chiffrement de la signature décrit plus haut. Le dispositif HW forme ensuite un certificat éphémère CeD par concaténation de la clé publique éphémère PeD et de la signature chiffrée. Enfin, le dispositif HW chiffre son certificat CD au moyen de la clé kO, conformément au procédé de chiffrement du certificat décrit plus haut.
B5.5. Envoi à l'orchestrateur des certificats du dispositif
[HW — > 0RC1] CeD||{CD}kO
Le dispositif HW envoie à l'orchestrateur ORC1 son certificat CD chiffré au moyen de la clé kO ainsi que son certificat éphémère CeD comprenant la signature chiffrée. Grâce au chiffrement du certificat et au chiffrement de la signature du certificat éphémère, la clé publique PD n’est pas exposée, comme expliqué plus haut. Comme indiqué plus haut, l'ordre de ces étapes peut être inversé, le dispositif pouvant envoyer son certificat, ici chiffré, avant d'envoyer son certificat éphémère, comprenant ici la signature chiffrée.
B5.6. Génération par l'orchestrateur de la clé de session kO k0 = ECDH(peO, PeD)
L'orchestrateur ORC1 génère la clé de session kO à partir de sa clé privée éphémère peO et de la clé publique éphémère PeD du dispositif HW au moyen de l’algorithme ECDH.
B5.7. Vérification par l'orchestrateur des certificats du dispositif
CD={CD} 1kO
Sign(pD, ReD||PeD) = {Sign(pD, ReD||PeD)}-1kO
Verif CeD, Verif CD
L'orchestrateur ORC1 déchiffre le certificat CD du dispositif HW ainsi que la signature du certificat éphémère du dispositif HW, puis vérifie la chaîne de certificats.
B6. Envoi aux serveurs BCKi des données BCKID, BCKDT et des certificats CeD, CD du dispositif
[ORC1 BCKi]
Pour chaque serveur BCKi, i allant de 1 à m
BCKID||BCKDT||CeD||CD
L'orchestrateur ORC1 envoie à chaque serveur BCKi l’identifiant de la sauvegarde BCKID, les données de la sauvegarde BCKDT qui incluent au moins les données de l'identité pivot. Comme indiqué plus haut, d'autres données peuvent optionnellement être envoyées ou avoir été envoyées aux serveurs de sauvegarde par d'autres canaux, comme la photo ou vidéo du visage de l'utilisateur prise à l'étape IDVO, et la photo d'un document d'identité. Si ces données ne sont pas incluses dans les données de la sauvegarde BCKDT, elles pourront être stockées par le serveur de comptes clients et transmises aux serveurs BCKi après la sauvegarde.
B7. Vérification par chaque serveur BCKi des certificats du dispositif
Pour chaque serveur BCKi, i allant de 1 à m
Verif CeD, Verif CD Chaque serveur BCKi vérifie la chaîne de certificats du dispositif HW de la manière précédemment décrite.
B8. Authentification mutuelle et création d’un canal sécurisé entre les serveurs BCKi et le dispositif, par l'intermédiaire de l'orchestrateur
B8.1 Génération par chaque serveur BCKi d’un certificat éphémère
Pour chaque serveur BCKi, i allant de 1 à m
(peBi, PeBi) = AsymKeyGen()
Sign(pBi, ReB||PeBi)
CeBi = PeBi||Sign(pBi, ReB||PeBi)
Chaque serveur BCKi génère une clé privée éphémère peBi et une clé publique éphémère PeBi. Chaque serveur BCKi calcule la signature de sa clé publique éphémère PeBi après l’avoir concaténée avec une donnée ReB au moyen de sa clé privée pBi. ReB spécifie par exemple le rôle que joue chaque serveur dans le processus, par exemple le rôle de serveur de sauvegarde pour la gestion du canal sécurisé. Ensuite chaque serveur BCKi génère un certificat éphémère CeBi par concaténation de la clé publique éphémère PeBi et de sa signature.
B8.2 Génération par chaque serveur BCKi d’une clé de session kBi
Pour chaque serveur BCKi, i allant de 1 à m kBi = ECDH(peBi, PeD)
Chaque serveur BCKi génère ensuite une clé de session kBi à partir de sa clé privée éphémère peBi et de la clé publique éphémère PeD du dispositif HW, au moyen de l’algorithme ECDH.
B8.3 Génération par chaque serveur BCKi d’un code de hachage chiffré
Pour chaque serveur BCKi, i allant de 1 à m
Hi = Hash(PeBi||BCKID||BCKDT)
CHi = {Hi}kBi
Chaque serveur BCKi génère ensuite un code de hachage Hi à partir d’une chaîne binaire comprenant sa clé publique éphémère PeBi, les données BCKI D et les données de la sauvegarde BCKDT. Chaque serveur BCKi chiffre ensuite le code Hi au moyen de la clé de session kBi pour obtenir un code de hachage chiffré CHi.
B8.4 Envoi à l'orchestrateur des certificats des serveurs BCKi et du code de hachage chiffré
[BCKi ORC1]
RETDTi = CeBi||CBi||CHi
Chaque serveur BCKi envoie à l'orchestrateur ORC1 une chaîne binaire RETDTi comprenant son certificat éphémère CeBi, son certificat CBi et le code de hachage chiffré CHi. B8.5 Envoi au dispositif des certificats des serveurs BCKi et du code de hachage chiffré
[ORC1 HW]
{BCKI D||BCKDT||RETDT1 ||....||RETDTi||... ||RETDTm}ko
L'orchestrateur ORC1 renvoie au dispositif les données BCKID, BCKDT et toutes les données RETDTi reçues des serveurs de sauvegarde BCKi, sous une forme chiffrée au moyen de la clé kO. Il sera noté ici que l'orchestrateur n’a pas accès aux données RETDTi car il ne connaît pas les clés privées kBi des serveurs BCKi. Les données dans le canal sécurisé de communication entre l'orchestrateur et le dispositif sont donc chiffrées deux fois.
B8.6 Déchiffrement par le dispositif des certificats des serveurs BCKi et du code de hachage chiffré
{BCKI D| | BC KDT| | RETDT11... 11 RETDTi 11... 11 R ETDTm } 1 kO
Le dispositif HW déchiffre la chaîne de données pour en extraire les données BCKID, BCKDT et les certificats CeBi, CBi, CHi.
B8.7 Validation des données BCKDT et des serveurs BCKi par l’utilisateur
Pour chaque serveur BCKi, i allant de 1 à m
Validate BCKDT, BCKi
L’utilisateur personne physique valide les données de la sauvegarde BCKDT et les serveurs BCKi en charge de la sauvegarde, qui lui sont présentées sur l'écran du dispositif hôte.
B8.8 Vérification par le dispositif des certificats des serveurs BCKi
Pour chaque serveur BCKi, i allant de 1 à m
Verif CeBi, Verif CBi
Le dispositif HW vérifie la chaîne de certificats de chaque serveur BCKi.
B8.9 Génération par le dispositif des clés de session kBi et vérification des codes de hachage chiffrés
Pour chaque serveur BCKi, i allant de 1 à m kBi = ECDH(peD, PeBi)
{Hi}’1 kBi
Validate Hi
Pour chaque serveur BCKi, le dispositif HW génère la clé de session kBi puis déchiffre le code Hi et le valide en recalculant lui-même le code Hi et en le comparant au code déchiffré.
B9. Préparation de la sauvegarde, génération des m parts Si
S1, S2,...Si,..Sm = SS(S) Au moyen de la fonction SS de partage de secret, le dispositif HW génère les m parts Si à sauvegarder dans les différents serveurs BCK1 , BCK2... BCKm, avec un seuil de n parts pour récupérer la graine S.
B10. Chiffrement des parts Si par le dispositif
Pour chaque serveur BCKi, i allant de 1 à m
{Si}kBi
Pour chaque serveur BCKi, le dispositif HW chiffre la part Si qui lui est destinée avec la clé kBi qui lui est propre.
B11. Envoi à l'orchestrateur des parts Si chiffrées
[HW — > ORC1]
{S 1 }kB 11 |{S2}kB2| | .... | |{Si}kBi| | ... | |{Sm}kBm ORC1
Le dispositif HW envoie ensuite l’ensemble des parts à l'orchestrateur ORC1. Il sera noté que l'orchestrateur n’a pas connaissance de la valeur de chaque part Si car celle-ci est chiffrée avec la clé kBi qu’il ne connaît pas.
B12. Envoi aux serveurs BCKi des parts Si chiffrées
[ORC1 BCKi]
Pour chaque serveur BCKi, i allant de 1 à m
BCKI D| |{Si}kBi BCKi
L'orchestrateur ORC1 envoie à chaque serveur BCKi la part Si chiffrée qui lui est destinée, accompagnée de l’identifiant de la sauvegarde.
B13. Déchiffrement et enregistrement par chaque serveur BCKi de la part Si chiffrée
Pour chaque serveur BCKi, i allant de 1 à m
{Si}’1 kBi STORE
Chaque serveur BCKi déchiffre la part Si qu'il a reçue et la stocke dans sa mémoire MEM pour qu’elle soit sauvegardée.
B14. Confirmation de la sauvegarde à l'orchestrateur par chaque serveur BCKi
[BCKi ORC1] OKi
Chaque serveur BCKi confirme à l'orchestrateur ORC1 par un message "OKi" (i allant de 1 à m) qu’il a déchiffré et stocké la part de la graine qui lui a été confiée. Optionnellement, chaque serveur BCKi peut envoyer une preuve chiffrée du déchiffrement de la part Si à l’aide d’un code de hachage signé avec sa clé de session. Ce code de hachage signé sera répercuté au dispositif HW pour être vérifié. B15. Confirmation de la sauvegarde à l'utilisateur
[ORC1 HW]
OK
L'orchestrateur ORC1 renvoie un message de réussite ("OK") de la sauvegarde au dispositif HW, lequel affiche sur son écran à l’attention de l'utilisateur un message de confirmation de sauvegarde.
A la fin du processus :
- le dispositif HW détient toujours la graine S,
- le logiciel compagnon HSW enregistre l’identifiant de la sauvegarde BCKID,
- l'orchestrateur ORC1 ne détient pas la graine S ni les données de la sauvegarde BCKDT, et détient seulement l’identifiant de la sauvegarde BCKID,
- chaque serveur BCKi détient l’identifiant de la sauvegarde BCKID, les données de la sauvegarde BCKDT qui contiennent au moins l’identité pivot de l’utilisateur, et la part Si de la graine qui lui a été confiée.
Le logiciel compagnon HSW enregistre l’identifiant de la sauvegarde BCKID et peut aussi mettre à jour le compte client UACC de l’utilisateur en y enregistrant l’identifiant de la sauvegarde BCKID.
On décrira maintenant en relation avec la figure 5A un exemple d'algorithme de restauration de la graine applicable au système de la figure 3A et mettant en œuvre divers aspects des modes de réalisation du procédé précédemment décrits. La figure 5B est un diagramme de séquences qui représente les étapes de l'algorithme sous forme d'interactions entre les entités précédemment citées.
On considère ici que l’utilisateur a perdu son dispositif HW, ou a perdu de manière irrécupérable le mot de passe qui permet de l'utiliser. Il se procure un nouveau dispositif HW qu’il va utiliser pour récupérer la graine S, et le connecte au dispositif hôte HDV dont le logiciel compagnon HSW a mémorisé l’identifiant de la sauvegarde BCKID. Le nouveau dispositif HW pourrait aussi être le dispositif HW qui a été réinitialisé.
Au commencement du processus le dispositif HW détient une clé privée pD, une clé publique PD, un certificat CD certifié par l’autorité de certification et la clé publique PL de l'autorité de certification (la même désignation que précédemment sera utilisée pour les clés et certificats du dispositif HW). L'étape de restauration comprend les étapes décrites ci-après. Les étapes semblables à celles précédemment décrites ne seront pas de nouveau commentées.
R1. Envoi par le dispositif d’une requête de restauration à l'orchestrateur
HW’ 0RC1 RESTRQ[BCKID]
La restauration est initiée par l’envoi par le dispositif HW à l'orchestrateur d’une requête en restauration RESTRQ. La requête contient l’identifiant de la sauvegarde BCKID. Elle est émise à la demande de l’utilisateur et sélectionnée à travers un menu affiché sur l’écran du dispositif HW ou sur l’écran du dispositif hôte HDV.
R2. Authentification mutuelle et création d’un canal sécurisé entre l'orchestrateur et le dispositif
R2.1 Génération par l'orchestrateur d’un certificat éphémère
(peO, PeO) = AsymKeyGen()
Sign(pO, ReO||PeO)
CeO = PeO||Sign(pO, ReO||PeO )
R2.2 Envoi au dispositif des certificats de l'orchestrateur
ORC1 HW
CeO||CO
R2.3. Vérification par le dispositif des certificats de l'orchestrateur
Verif CeO, Verif CO
R2.4. Génération par le dispositif d’une clé de session et d’un certificat éphémère chiffré
(peD, PeD) = AsymKeyGenQ kO = ECDH(peD, PeO)
Sign(pD, ReD||PeD)
{Sign(pD, ReD||PeD)}kO
CeD = PeD||{Sign(pD, ReD||PeD)}kO
{CD}kO
R2.5. Envoi à l'orchestrateur des certificats du dispositif HW
[HW ORC1]
CeD||{CD}kO
R2.6. Génération par l'orchestrateur de la clé de session kO kO = ECDH(peO, PeD)
CD={CD}’1kO
Sign(pD, ReD||PeD) = {Sign(pD, ReD||PeD)}-1kO
R2.7. Vérification par l'orchestrateur des certificats du dispositif
Verif CeD, Verif CD R3. Envoi aux serveurs BCKi des données BCKID et certificats CeD, CD
[ORC1 BCKi]
Pour chaque serveur BCKi, i allant de 1 à m
BCKID||CeD||CD BCKi
L'orchestrateur ORC1 envoie à chaque serveur de sauvegarde BCKi l’identifiant de la sauvegarde BCKID, le certificat éphémère CeD et le certificat CD du dispositif HW.
R4. Vérification par chaque serveur BCKi des certificats du dispositif
Pour chaque serveur BCKi, i allant de 1 à m
Verif CeD, Verif CD
R5. Authentification mutuelle et création d’un canal sécurisé entre les serveurs BCKi et le dispositif, par l'intermédiaire de l'orchestrateur
R5.1 Génération par chaque serveur BCKi d’un certificat éphémère
Pour chaque serveur BCKi, i allant de 1 à m
(peBi, PeBi) = AsymKeyGen()
Sign(pBi, ReB||PeBi)
CeBi = PeBi||Sign(pBi, ReB||PeBi)
R5.2 Génération par chaque serveur BCKi d’une clé de session
Pour chaque serveur BCKi, i allant de 1 à m kBi = ECDH(peBi, PeD)
R5.3 Génération par chaque serveur BCKi d’un code de hachage chiffré
Hi = Hash(PeBi||BCKID||BCKDT)
CHi = {Hi}kBi
R5.4 Envoi à l'orchestrateur par chaque serveur BCKi de son certificat et du code de hachage chiffré
[BCKi ORC1]
Pour chaque serveur BCKi, i allant de 1 à m
RETDTi = CeBi||CBi||CHi
R5.5 Envoi au dispositif des données reçues des serveurs BCKi
[ORC1 HW]
{BCKI D| | BCKDT| | RETDT11... 11 RETDTi| | ... 11 RETDTm}kO
R5.6 Déchiffrement par le dispositif de la chaine de données reçue de l'orchestrateur {BCKI D| | BCKDT| | RETDT11... 11 RETDTi| | ...11 RETDTm}’1 k0
R5.7 Validation des données de la sauvegarde par l’utilisateur
Validate BCKDT
L’utilisateur valide les données de la sauvegarde BCKDT, notamment prénom, nom de famille, date de naissance, optionnellement lieu de naissance.
R5.8 Vérification par le dispositif des certificats des serveurs BCKi
Pour chaque serveur BCKi, i allant de 1 à m
Verif CeBi, Verif CBi
R5.9 Génération par le dispositif des clés de session kBi et vérification des codes de hachage chiffrés CHi
Pour chaque serveur BCKi, i allant de 1 à m kBi = ECDH(peD, PeBi)
{Hi}’1 kBi
Validate Hi (Hi = Hash(PeBi||BCKID||BCKDT)
R6. Préparation de la restauration
R6.1 Envoi par le dispositif à l'orchestrateur de confirmations de restauration
[HW^ ORC1]
Le dispositif HW renvoie à l'orchestrateur ORC1 pour chaque serveur BCKi, une confirmation de restauration individuelle "Confirm Restore'1 qui est chiffrée avec la clé kBi de chaque serveur BCKi. Chaque confirmation est un code binaire prédéfini.
R6.2 Envoi aux serveurs BCKi des confirmations de restauration
Pour chaque serveur BCKi, i allant de 1 à m
BCKID||{ConfirmRestorej}kBi — > BCKi
L'orchestrateur ORC1 envoie à chaque serveur BCKi l’identifiant de la sauvegarde BCKID concaténé et la confirmation de restauration {Confirm RestoreJkBi qui lui est destinée.
R6.3 Vérification par les serveurs BCKi des confirmations de restauration
Pour chaque serveur BCKi, i allant de 1 à m {ConfirmRestorej}-1 kBi
Store CD Chaque serveur BCKi déchiffre le message de confirmation émis par le dispositif HW et qui lui a été communiqué par l'orchestrateur ORC1 , et mémorise le certificat CD du dispositif H qu’il a précédemment vérifié.
R6.4 Confirmation par chaque serveur BCKi que la restauration peut être initiée sous réserve de vérification d’identité
[BCKi— > ORC1]
Pour chaque serveur BCKi, i allant de 1 à m
OK_for_IDV
Claque serveur BCKi indique à l'orchestrateur ORC1 qu’il est prêt à restituer la part Si qu’il a sauvegardée sous réserve que l’utilisateur s’identifie à travers une étape IDVi.
R7. Réalisation des étapes de vérification d'identité IDVi par les serveurs IDVSRVi
Pour chaque serveur BCKi, i allant de 1 à m
IDVRi
L’utilisateur est redirigé par l'orchestrateur ORC1 sur chaque serveur BCKi et chaque serveur BCKi procède à sa propre vérification IDVi de l’identité pivot de l’utilisateur. Dans le présent mode de réalisation où les étapes IDVi sont confiées à des prestataires, chaque serveur BCKi connecte l’utilisateur au serveur IDVSRVi auquel il est affilié à travers une passerelle GTW. Le service IDVSi du prestataire procède à une vérification de l’identité de l’utilisateur, puis confirme à l'orchestrateur ORC1 que son identité a été vérifiée et que l'étape de sauvegarde de la graine peut être initiée.
Il sera noté que la durée de chaque étape de vérification d'identité IDVRi peut aller de quelques minutes à plusieurs jours selon les exigences de chaque serveur BCKi ou du prestataire qui réalise l’IDVRi. Des vérifications par des personnes physiques peuvent être systématiquement prévues avec certains prestataires d'IDV.
R8. Rétablissement des canaux de communication sécurisés après réalisation des étapes de vérification d'identité IDVi
[HW ORC1]
Continue Restore
Une fois l'étape de vérification d'identité terminée, soit parfois plusieurs jours plus tard, l’utilisateur relance l'étape de restauration. Le dispositif HW envoie à l'orchestrateur ORC1 une demande de reprise de la restauration "Continue Restore ".
Répétition des étapes R2.1 à R2.7, R3, R5.1 à R5.9
Comme plusieurs jours peuvent s’écouler pendant la réalisation des étapes de vérification IDVi, dans un mode de réalisation les certificats de session précédents ne sont pas conservés. Ainsi, les étapes R2.1 à R2.7, R3, R5.1 à R5.9 sont exécutées de nouveau pour reprendre le processus de restauration là où il s’était arrêté, mais avec de nouvelles clés de session kO et kBi.
R9. Reprise de la restauration
[ORC1 BCKi]
Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n)
Continue Restore -> BCKi
Une fois les canaux sécurisés réouverts au moyen de nouvelles clés de session, l'orchestrateur répercute aux serveurs BCKi la demande de poursuite de la restauration. Il sera noté que si au cours des étapes IDVRi l’un des serveurs BCKi n’a pas pu vérifier l’identité de l’utilisateur avec un degré de certitude déterminé, il refusera de restituer la part qu’il détient et en informera l'orchestrateur ORC1. Si un nombre déterminé de serveurs de sauvegarde BCKi n’a pas vérifié avec succès l’identité de l’utilisateur et refuse de restituer les données qu’ils détiennent, l'orchestrateur peut être configuré pour suspendre la restitution des parts par les serveurs qui ont vérifié avec succès l’identité de l’utilisateur. Il peut optionnellement décider de soumettre l’utilisateur à une procédure supplémentaire de vérification de son identité. L'orchestrateur peut également être configuré pour analyser des scores de certitude quant à la vérification de l’identité de l’utilisateur, comme indiqué plus haut, et prendre une décision en fonction de cette analyse.
Par ailleurs, dans une variante du procédé mentionnée ci-dessus et dans ce qui suit entre parenthèses, cette étape est limitée n serveurs de sauvegarde BCKi, au lieu de l'ensemble des serveurs de sauvegarde, si n parts seulement sont nécessaires à la reconstitution de la graine, avec n inférieur à m.
R10. Vérification du certificat du dispositif
Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n)
Verif CD = CD
Chaque serveur BCKi s'assure que le certificat CD du dispositif HW est le même que le certificat CD reçu avant la conduite des étapes de vérification d'identité IDVi, qu’il a conservé.
R11. Transfert des parts à l'orchestrateur par les serveurs BCKi
Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n)
{S 1 }kB 11 |{S2}kB2| | .... | |{Si}kBi| | ... | |{Sm}kBm ORC1
Chaque serveur BCKi envoie à l'orchestrateur ORC1 la part Si qu’il détient, chiffrée au moyen de sa clé kBi, que l'orchestrateur ne connaît pas.
R12. Transfert des parts au dispositif par l'orchestrateur
{S1}kB1 ||{S2}kB2||....||{Si}kBi||... ||{Sm}kBm HW L'orchestrateur ORC1 envoie au dispositif HW toutes les parts Si reçues des serveurs BCKi sous forme chiffrée au moyen des clés kBi.
R13. Déchiffrement des parts par le dispositif et restauration de la graine
Pour chaque serveur BCKi, i allant de 1 à m (ou i allant de 1 à n)
{Si} 1 kBi
S = SS-1 (S1 , S2,...Si...Sm)
(ou S = SS-1 (S1 , S2,...Si...Sn))
Après avoir déchiffré chaque part de rang i au moyen de la clé kBi correspondante, le dispositif HW restaure la graine à partir des parts reçues, ou d’une partie de celles-ci si leur nombre est supérieur à n.
R14. Confirmation finale
OK — >■ ORC1
Le dispositif HW confirme à l'orchestrateur ORC1 que la restauration de la graine est terminée.
Il apparaîtra clairement à l'homme de l'art que le procédé qui a été décrit est susceptible de nombreuses autres variantes et modes de réalisation. La structure des certificats mis en jeu dans le procédé a été décrite ci-dessus selon deux variantes, par exemple :
Cx = [Px, Sign(pL, Px)]
Cex = Pex||{Sign(px, Rex||Pex)
Les certificats éphémère pourraient aussi être du type :
Cex = Pex||{Sign(px, Pex)
Le procédé peut aussi être mis en oeuvre avec toute structure de certificat. Des certificats de type X509 peuvent notamment être utilisés. De même, d'autres fonctions de chiffrement ou algorithmes cryptographiques peuvent être utilisés, notamment dans le cadre d'une mise en oeuvre basée sur la crytographie RSA.
La figure 6A montre un système pour la mise en œuvre du procédé de l'invention qui se distingue de celui de la figure 3A en ce que le serveur ORCSRV1 est remplacé par un serveur ORCSRV2 qui exécute un programme orchestrateur ORC2 (ci-après "orchestrateur ORC2"). L'orchestrateur OCR2 diffère de l'orchestrateur ORC1 en ce qu'il n'assure pas la transmission au dispositif HW des données émises par les serveurs de sauvegarde BCKi, et réciproquement, et n'agit donc pas comme une passerelle ou "serveur proxy".
Lorsque l'utilisateur initie une étape de sauvegarde de la graine, le dispositif HW adresse à l'orchestrateur OCR2 une requête en sauvegarde BCKRQ à la suite de quoi l'orchestrateur ORC2 engage les étapes précédemment décrites de génération d'un identifiant BCKID de la sauvegarde, et de collecte d'informations concernant l'utilisateur, pour générer les données de la sauvegarde BCKDT. L'orchestrateur conduit également l'étape initiale IDVO de vérification de l'identité de l'utilisateur. Si cette étape est concluante, l'orchestrateur délivre au dispositif HW des autorisations de sauvegarde BCKPASSi, à raison d'une autorisation par serveur de sauvegarde BCKi, et envoie chaque autorisation au serveur BCKi concerné.
Chaque autorisation BCKPASSi forme une sorte de "passeport" permettant au dispositif HW de savoir à quel serveur BCKi il doit s'adresser pour sauvegarder une part Si de la graine, et lui permettant de se connecter au serveur BCKi pour procéder à la sauvegarde sans être rejeté par ce dernier. Chaque autorisation BCKPASSi peut comprendre diverses informations et notamment les informations qui figuraient précédemment dans les données de la sauvegarde BCKDT et l'identifiant BCKID. Les autorisations BCKPASSi sont conservées par le logiciel compagnon ainsi que, de préférence, dans le compte de l'utilisateur UACC sur le serveur de compte UASRV. Dans une variante, l'orchestrateur délivre une autorisation générale BCKPASS contenant une concaténation de toutes les informations figurant dans les autorisations BCKPASSi.
En référence à la figure 6B, lorsque l'utilisateur veut restaurer la graine, le logiciel compagnon se connecte aux serveurs de sauvegarde BCKi qu'il identifie au moyen des adresses contenues dans les autorisations BCKPASSi, puis passe la main au dispositif HW pour qu'il établisse des canaux sécurisés avec les serveurs de sauvegarde BCKi, par des échanges de clé tels que décrits plus haut. Lorsque les canaux sécurisés ont été créés, les serveurs de sauvegarde BCKi engagent les étapes IDVi de vérification de l'identité pivot de l'utilisateur.
Le rôle de superviseur des étapes IDVi qui a été précédemment dévolu à l'orchestrateur ORC1 peut également être dévolu ici à l'orchestrateur ORC2. Ce dernier est alors sollicité par les serveurs de sauvegarde BCKi pour analyser les résultats des étapes IDVi. Si ces résultats sont concluants, l'orchestrateur ORC2 délivre au dispositif HW des autorisations de restauration RESTPASSi qu'il communique également aux serveurs de sauvegarde BCKi. Le dispositif HW rétablit ensuite un canal sécurisé avec les serveurs de sauvegarde BCKi et leur présente les autorisations RESTPASSi pour récupérer les parts Si de la graine.
Dans le cas, ultime, où l’utilisateur aurait fermé son compte sur le serveur de compte UASRV, désinstallé le logiciel compagnon en effaçant les données qu'il comportait, et ne pourrait donc plus récupérer les autorisations BCKPASSi, ainsi que dans le cas, tout aussi ultime, où l'orchestrateur ORC2 n'existerait plus, une solution peut être prévue pour permettre à l'utilisateur de récupérer sa graine, en lui permettant de conduire une pluralité d'étapes individuelles de vérification de son identité auprès de chaque serveur de sauvegarde BCKi .
Dans une variante du procédé permettant de faciliter la récupération des parts en cas de défaillance totale du système, ou de perte de l'identifiant BCKID (mode de réalisation figures 3A, 3B) ou des autorisations BCKPASSi, il peut être prévu que l'organisation en charge de l'orchestrateur ORC1 ou ORC2 délivre à l'utilisateur, par exemple par la voie postale, un certificat de sauvegarde revêtu d'un certificat d'authenticité inviolable tel un hologramme. Un tel certificat de sauvegarde n'épargnera pas l'utilisateur des étapes de vérification de son identité auprès des serveurs de sauvegarde, mais comportera suffisamment d'informations pour offrir un degré supplémentaire de certitude quant à sa qualité de détenteur légitime de la graine lorsque les étapes de vérification IDVi seront conduites.
La figure 7 montre un exemple de réalisation d’un portefeuille matériel HW permettant la mise en œuvre du procédé. Le dispositif HW comprend un élément sécurisé SE1 , un microcontrôleur MCU1 et un écran tactile TS1 ("Touch Screen"). L’écran tactile TS1 comprend un afficheur à encre électronique EID ("E-Ink Display") et un module tactile TM ("Touch Module"). L’écran tactile TS1 est sous le contrôle de l’élément sécurisé SE1. A cet effet, les ressources en termes d’entrées/sorties de l’élément sécurisé SE1 sont réparties en trois groupes d’entrées/sorties IOGA, IOGB, IOGC. Le groupe d’entrées/sorties IOGA est affecté à la mise en œuvre d’un bus BS1 reliant l’élément sécurisé SE1 au microcontrôleur MCU1. Le groupe d’entrées/sorties IOGB est affecté à la mise en œuvre d’un bus BS2 reliant l’élément sécurisé SE1 à l’afficheur EID, et le groupe d’entrées/sorties IOGC est affecté à la mise en œuvre d’un bus BS3 reliant l’élément sécurisé SE1 au module tactile TM. Le bus BS1 est par exemple un bus IEC/ISO 7816, le bus BS2 est par exemple un bus SPI et le bus BS3 un bus I2C. L’élément sécurisé est par exemple une puce STMicroelectronics® de la série ST33K. Le dispositif HW comporte par ailleurs divers périphériques contrôlés par le microcontrôleur MCU1 , par exemple :
- une batterie BAT ;
- un circuit intégré PMIC de gestion d’alimentation reçoit une tension Vbat de la batterie lorsque celle-ci est chargée, fournit la tension Vbat à la batterie lorsque celle-ci doit être chargée, et fournit une tension d’alimentation régulée Vcc au microcontrôleur MCU1 , à l’élément sécurisé SE1 et à l’écran tactile TS1 ;
- une antenne QiA pour la charge de la batterie par induction conformément à la technologie Qi. L’antenne QiA est reliée à un circuit intégré de charge sans fil WCIC (“Wireless Charging Integrated Circuit") . Le circuit WCIC fournit une tension Vqi au circuit PMIC pour la charge de la batterie ;
- un port USB U1. Le port USB fournit au circuit PMIC une tension Vusb pour la charge de la batterie, fournit au microcontrôleur MCU1 des données DTu reçues d’un dispositif externe connecté au port USB, et transmet des données DTu au dispositif externe ;
- une antenne Bluetooth BTA, recevant un signal radiofréquence RFS fourni par un circuit BTM de gestion des communications Bluetooth. Le circuit BTM fournit des données DTb échangées avec un dispositif externe via une liaison Bluetooth ou transmet des données DTb au dispositif externe via la liaison Bluetooth.
Le dispositif HW présente l’avantage de posséder un écran tactile exclusivement contrôlé par l’élément sécurisé SE1 et donc non susceptible de corruption, y compris en cas d’attaque sur le microcontrôleur MCU1 . Ce dernier n'exécute aucun programme d’application et ne stocke aucun des secrets cryptographiques utilisés par l’élément sécurisé. Il gère seulement les périphériques en transmettant à l’élément sécurisé les données DTb, DTu reçues par l’interface de communication choisie par l’utilisateur, ou en transmettant au dispositif externe des données DTb, DTu fournies par l’élément sécurisé. Le dispositif HW n’offre donc aucune possibilité de connexion directe à l’Internet et reste, malgré son écran tactile, un portefeuille matériel pour le stockage à froid de clés privées offrant le plus haut niveau de sécurité. L’élément sécurisé SE1 comporte également un espace mémoire MS1 comprenant une zone de mémoire morte, une zone mémoire non volatile programmable et effaçable électriquement et une zone mémoire volatile. La zone mémoire non volatile programmable et effaçable électriquement reçoit un système d’exploitation de l’élément sécurisé. Celui-ci est configuré pour permettre la mise en œuvre du procédé de l'invention.
Le dispositif HW se prête bien à la mise en œuvre du procédé grâce à son écran tactile, qui peut être choisi de grande taille et présenter par exemple une diagonale supérieure ou égale à 3,5 pouces (un pouce étant égal à 2,54 cm), et comprendre au moins 600 x 400 pixels. Dans un mode de réalisation, l’écran présente une diagonale de 3,9 pouces (9,906 cm) et offre 670 x 496 pixels, ce qui constitue un très grand écran pour un portefeuille matériel de cryptoactifs dépourvu de connectivité Internet.
Les tableaux 2 et 3 ci-après ainsi que les figures 8 et 9 décrivent un exemple de configuration du dispositif HW et du logiciel compagnon HSW pour la mise en œuvre d'un mode de réalisation du procédé de l'invention, dans lequel trois serveurs de sauvegarde sont utilisés, la graine étant donc sauvegardée au moyen de trois parts. Le dispositif HW est utilisé en association avec le dispositif hôte HDV auquel il peut être relié via son interface USB ou Bluetooth. En sus de l'écran tactile TS1 du dispositif HW, le dispositif hôte HDV comporte lui-même un écran permettant à l'utilisateur USR de conduire avec le logiciel compagnon, certaines étapes du procédé tandis que d'autres étapes sont réalisées avec le dispositif HW.
Dans les tableaux 2 et 3, les mentions entre crochets correspondent à des boutons virtuels que l'utilisateur doit presser pour sélectionner l'option qu'il retient. Les mentions entre guillemets sont des informations affichées par le dispositif HW ou le dispositif hôte HDV. Les mentions "xx" correspondent à des zones affichées ou des zones dans lesquelles l'utilisateur doit fournir les informations demandées.
Le tableau 2 ci-après et la figure 8 décrivent la mise en œuvre du procédé en ce qui concerne la sauvegarde de la graine. Au cours d'une étape D0, le logiciel compagnon offre à l'utilisateur le choix entre, d'une part, sauvegarder sa graine et, d'autre part, initialiser ou restaurer le dispositif HW. On suppose ici que le dispositif HW a été préalablement mis en service mais que l'utilisateur n'a jamais sauvegardé sa graine. Ce dernier choisit donc la première option. Au cours d'une étape D1 , le logiciel compagnon offre deux options à l'utilisateur, à savoir une sauvegarde classique qui consistera dans l'affichage de la phrase de récupération par le dispositif HW afin que l'utilisateur puisse la sauvegarder sur le support de son choix, ou une sauvegarde en faisant appel à un service de protection automatique mettant en œuvre le procédé selon l'invention. Au cours d'une étape D3, l'utilisateur est invité à créer un compte sur le serveur de comptes clients. Au cours d'une étape D4, l'utilisateur crée ce compte et fournit des informations relatives à son identité, dont une partie au moins constitue les informations de son identité pivot incorporée dans les données de la sauvegarde BCKDT. Au cours d'une étape D5 il définit le mot de passe de son compte.
Au cours d'une étape D6 le logiciel compagnon rappelle à l'utilisateur qu'il va devoir se soumettre à une étape de vérification de son identité. Il s'agit ici de l'étape IDVO qui permettra à l'orchestrateur de s'assurer que les informations constituant son identité pivot sont correctes, notamment son prénom, son nom et sa date de naissance. L'étape IDVO est conduite à des étapes D7 à D11 au moyen de l'écran du dispositif hôte HDV, ainsi que sa caméra. Une fois l'étape IDVO réalisée avec succès, l'utilisateur doit connecter le dispositif HW au dispositif hôte HDV à une étape D12.
Ensuite, le dispositif HW prend en charge la suite du processus en demandant à l'utilisateur à une étape D13 de saisir son mot de passe, puis à des étapes D14, D15 de vérifier son identité. Le dispositif HW procède ensuite à la sauvegarde de la graine à une étape D16.
Le tableau 3 ci-après et la figure 9 décrivent l'étape de restauration de la graine. A l'étape DO, l'utilisateur choisit l'option Initialiser/Restaurer. Au cours d'une étape D20, le logiciel compagnon demande à l'utilisateur de connecter le dispositif HW au dispositif hôte HDV. Au cours d'une étape D21, le logiciel compagnon et le dispositif HW confirment que la connexion a été effectuée. Au cours d'une étape D22, l'utilisateur doit entrer le mot de passe du dispositif HW. Au cours d'une étape D22, le dispositif HW propose à l'utilisateur de préciser s'il veut initialiser le dispositif HW en tant que nouveau dispositif ou s'il veut procéder à une restauration à partir d'une phrase de récupération. L'utilisateur choisit ici l'option "restauration". Au cours d'une étape D24, le dispositif HW demande à l'utilisateur s'il veut restaurer le dispositif HW à partir du service de protection selon l'invention ou à partir d'une phrase de récupération qu'il aurait conservée (restauration manuelle). L'utilisateur choisit le service de protection.
Au cours d'une étape D25, le logiciel compagnon prend en charge la suite du processus et informe l'utilisateur qu'il va devoir se soumettre à trois étapes de vérification de son identité. La première sera effectuée avec le dispositif HW et les deux autres seront effectuées auprès de prestataires d'IDV. Au cours d'une étape D26, l'utilisateur doit confirmer les informations affichées par le dispositif HW concernant son identité pivot (des informations supplémentaires à celles formant l'identité pivot peuvent être affichées par le dispositif HW au cours de cette étape, comme on le voit sur le tableau 3). Au cours d'une étape D27, le logiciel compagnon indique à l'utilisateur qu'il va être mis en relation avec le premier partenaire d'IDV et lui demande de confirmer son accord. L'accord de l'utilisateur conduit le logiciel compagnon à se mettre en liaison avec un serveur partenaire IDVSRVi, par l'intermédiaire de sa passerelle GTW, comme décrit plus haut. Au cours d'étapes D28 à D32, l'utilisateur réalise les actions demandées par le premier partenaire d'IDV pour l'acquisition des informations nécessaires à la première vérification d'identité, au moyen de l'écran et de la caméra du dispositif hôte HDV. Au cours d'une étape D33, le logiciel compagnon indique à l'utilisateur qu'il va être mis en relation avec le deuxième partenaire d'IDV et lui demande de confirmer son accord. L'accord de l'utilisateur conduit le logiciel compagnon à se mettre en liaison avec un autre serveur partenaire IDVSRVi, par l'intermédiaire de sa passerelle GTW. Au cours d'étapes résumées dans le tableau par une seule étape D34, l'utilisateur réalise les actions demandées par le deuxième partenaire d'IDV pour l'acquisition des informations nécessaires à la deuxième vérification d'identité. Ces étapes peuvent être identiques, similaires ou différentes de celles de la première vérification d'identité. Il sera noté que la vérification d'identité n'est pas achevée une fois ces étapes réalisées et que le résultat de chaque vérification pourrait n'être fourni à l'utilisateur que quelques heures voire quelques jours plus tard, comme cela a été expliqué plus haut. Lorsque l'identité de l'utilisateur a été vérifiée, le dispositif HW récupère les parts S1, S2, S3 de la graine et restaure celle-ci au cours d'une étape D35.
Il apparaîtra clairement à l'homme de l'art que le procédé qui vient d'être décrit peut également être mis en œuvre avec d'autres types de portefeuilles de cryptoactifs que celui qui vient d'être décrit. Le procédé peut notamment être mis en œuvre avec un portefeuille de cryptoactifs CW2 du type montré sur la figure 10. Le portefeuille de cryptoactifs CW2 comprend un microcontrôleur sécurisé SMCU, un écran TS2 pouvant être tactile, des circuits d’interface de communication CINT1 comprenant notamment une connectivité wifi et/ou Ethernet et lui permettant de se relier à l'Internet. Le microcontrôleur sécurisé utilise deux processeurs virtuels associés à un contrôle d'accès matériel, permettant de gérer deux zones TZ, NTZ d’exécution d’applications offrant des degrés de sécurité différents, la zone TZ étant appelée "zone de confiance" ("Trust Zone"). Le microcontrôleur sécurisé peut, dans certains modes de réalisation, être équipé d’un élément sécurisé SE2 couplé à la zone de confiance TZ pour réaliser des calculs cryptographiques et conduire les opérations les plus sensibles en termes de sécurité, notamment stocker la graine ainsi que diverses clés de comptes de cryptoactifs. Chaque zone peut fonctionner indépendamment de l'autre tout en utilisant le même noyau. En général, le microcontrôleur exécute un système d'exploitation dit "riche" dans la zone la moins fiable NTZ, par exemple Android, et un code spécialisé dans la zone de confiance TZ. Un tel dispositif est l'équivalent de la combinaison du portefeuille matériel HW (équivalent à la zone de confiance) et du dispositif hôte HDV (équivalent à la zone moins sécurisée) décrits dans ce qui précède, et n’a pas besoin d’être relié à un dispositif hôte pour exécuter des opérations sur la blockchain.
Le procédé de l’invention peut également être mis en œuvre avec un portefeuille de cryptoactifs de type logiciel ("software wallet"). Contrairement à un portefeuille en ligne, un portefeuille logiciel permet stocker des clés de cryptoactifs directement sur un ordinateur de bureau, un ordinateur portable, un téléphone mobile ou équivalent. L'utilisateur conserve la propriété de ses clés et de la graine, et doit sécuriser lui-même leur stockage en faisant en sorte qu'un fraudeur ne puisse pas s'en emparer. A titre d'exemple, la figure 11 montre un portefeuille de cryptoactifs CW3 de type logiciel exécuté par un dispositif électronique DV qui peut être du type précité, ordinateur, téléphone mobile ou équivalent. Le dispositif DV comprend un microprocesseur MPU équipé d'une interface de communication CINT2 lui permettant de se relier à l'Internet, d'une mémoire volatile RAM et d'une mémoire non volatile NVM, par exemple un disque dur magnétique ou un disque dur à l'état solide (SSD). Le programme CW3 formant le portefeuille de cryptoactifs logiciel est stocké dans la mémoire non volatile NVM du dispositif DV et est exécuté par le microprocesseur MPU à l'aide de sa mémoire RAM.
Tableau 2 : sauvegarde de la graine, interaction entre l'utilisateur, le portefeuille matériel HW et le dispositif hôte HDV
[Tab 2]
Tableau 3 : Restauration de la graine, interaction entre l'utilisateur et le portefeuille matériel HW et le dispositif hôte HDV
[Tab 3]

Claims

REVENDICATIONS
1. Procédé pour établir une liaison de données sécurisée (LNK1) entre un dispositif électronique (CW1, HW, HDV, CW2, DV, CW3) et un serveur (ORC1), dans lequel le serveur et le dispositif possèdent chacun une clé privée (pO, pD), une clé publique (PO, PD), un certificat (CO, CD) signé par une autorité de certification (CA), et une clé publique (PL) de l’autorité de certification, procédé caractérisé en ce que le dispositif et le serveur sont configurés pour exécuter les étapes suivantes :
- le serveur génère (B5.1) une clé privée éphémère (peO), une clé publique éphémère (PeO) et un certificat éphémère (CeO) signé avec sa clé privée (pO), et transfère (B5.2) son certificat éphémère au dispositif,
- le dispositif génère (B5.4) une clé privée éphémère (peD) et une clé publique éphémère (PeD)
- le dispositif génère (B5.4) une première signature de sa clé publique éphémère (PeD) à partir de sa clé privé (pD),
- le dispositif génère (B5.4) une première clé de session (kO) à partir de sa clé privée éphémère (peD) et de la clé publique éphémère (PeO) du serveur,
- le dispositif chiffre (B5.4) la première signature au moyen de la première clé de session (kO), pour obtenir une signature chiffrée,
- le dispositif transfère (B5.5) au serveur un certificat éphémère (CeD) comprenant sa clé publique éphémère (PeD) et la signature chiffrée,
- le serveur génère (B5.6) la première clé de session (kO) à partir de sa clé privée éphémère (peO) et de la clé publique éphémère (PeD) du dispositif, et
- au moyen de la première clé de session (kO), le serveur déchiffre (B5.7) la signature présente dans le certificat éphémère (CeD).
2. Procédé selon la revendication 1 , dans lequel :
- le serveur transfère (B5.2) son certificat (CO) au dispositif,
- le dispositif chiffre (B5.4) son propre certificat (CD) avec la première clé de session,
- le dispositif transfère (B5.5) au serveur son certificat (CD) chiffré avec la première clé de session, et
- au moyen de la première clé de session (kO), le serveur déchiffre (B5.7) le certificat (CD) du dispositif.
3. Procédé selon l’une des revendications 1 et 2 dans lequel, avant de générer la première signature de sa clé publique éphémère (PeD), le dispositif concatène (B5.4) sa clé publique éphémère (PeD) avec une donnée (ReD).
4. Procédé selon l’une des revendications 2 et 3, dans lequel : - le dispositif vérifie (B5.3) la validité du certificat éphémère (CeO) du serveur (ORC1) au moyen du certificat (CO) du serveur,
- le dispositif vérifie (B5.3) la validité du certificat (CO) du serveur (ORC1) au moyen de la clé publique (PL) de l'autorité de certification,
- le serveur (ORC1) vérifie (B5.7) la validité du certificat éphémère (CeD) du dispositif au moyen du certificat (CD) du dispositif, et
- le serveur vérifie (B5.7) la validité du certificat (CD) du dispositif au moyen de la clé publique de certification (CL).
5. Procédé selon l’une des revendications 1 à 4 dans lequel le dispositif (CW1) comprend un portefeuille matériel de cryptoactifs (HW) comprenant une donnée secrète principale (S), ou clé maître.
6. Procédé selon la revendication 5, dans laquelle le portefeuille matériel (HW) est dépourvu de moyen de connexion à l’Internet et est configuré pour être relié au serveur par l’intermédiaire d’un dispositif hôte (HDV) exécutant un logiciel compagnon (HSW) et pourvu d’une connexion à l’Internet.
7. Procédé pour la sauvegarde d’une pluralité de données secrètes (Si) détenues par un portefeuille de cryptoactifs (CW1 , HW, HDV, CW2, DV), les données secrètes étant stockées par le portefeuille de cryptoactifs ou pouvant être générées par le portefeuille de cryptoactifs à partir d’une donnée secrète principale (S) détenue par le portefeuille de cryptoactifs, le portefeuille de cryptoactifs étant la propriété d’un utilisateur (USR), le procédé comprenant les étapes consistant à :
- prévoir un programme orchestrateur (ORC1) exécuté par un serveur (ORCSRV1) pour mettre en œuvre et superviser la sauvegarde des données, et
- prévoir une pluralité de serveurs de sauvegarde (BCKSRVi), et dans lequel le programme orchestrateur est configuré pour :
- établir une liaison de données sécurisée (LNK1) avec le portefeuille de cryptoactifs conformément au procédé selon l’une des revendications 1 à 6,
- communiquer (B6) à chaque serveur de sauvegarde des informations (BCKDT) relatives à l’identité de l’utilisateur,
- recevoir (B11) du portefeuille de cryptoactifs les données à sauvegarder ({Si}kBi), et
- transférer (B12) à chaque serveur de sauvegarde l’une des données (Si) à sauvegarder.
8. Procédé selon la revendication 7, dans lequel les informations relatives à l’identité de l’utilisateur comprennent au moins le prénom de l’utilisateur, le nom de famille de l’utilisateur et la date de naissance de l’utilisateur.
9. Procédé selon l’une des revendications 7 et 8, dans lequel :
- chaque serveur de sauvegarde (BCKSRVi) possède une clé privée (pO, pD, pBi), une clé publique (PO, PD, PBi), un certificat (CO, CD, CBi) signé par l’autorité de certification (CA), et la clé publique (PL) de l’autorité de certification,
- chaque serveur de sauvegarde transfère (B8.4) son certificat (CBi) au programme orchestrateur, qui le transfère (B8.5) au portefeuille de cryptoactifs,
- chaque serveur de sauvegarde génère (B8.1) une clé privée éphémère (peBi), une clé publique éphémère (PeBi) et un certificat éphémère (CeBi) signé avec sa clé privée (pBi), et transfère (B8.4) le certificat éphémère au programme orchestrateur qui le transfère (B8.5) au portefeuille de cryptoactifs,
- le portefeuille de cryptoactifs transfère (B5.5) son certificat (CD) et son certificat éphémère (CeD) au programme orchestrateur, qui le transfère (B6) à chacun des serveurs de sauvegarde (BCKi),
- chaque serveur de sauvegarde génère une deuxième clé de session (kBi) à partir de sa clé privée éphémère (peBi) et de la clé publique éphémère (PeD) du portefeuille de cryptoactifs,
- le portefeuille de cryptoactifs génère la deuxième clé de session (kBi) de chaque serveur de sauvegarde à partir de sa clé privée éphémère (peD) et de la clé publique éphémère (PeBi) du serveur de sauvegarde,
- le portefeuille de cryptoactifs chiffre (B10) la donnée destinée à chaque serveur de sauvegarde avec la deuxième clé de session (kBi), la transfère (B11) à l’orchestrateur qui la transfère (B12) au serveur de sauvegarde, et
- chaque serveur de sauvegarde déchiffre (B13) au moyen de la deuxième clé de session (kBi) la donnée (Si) reçue, et la stocke dans une mémoire (MEM).
10. Procédé selon la revendication 9, dans lequel :
- chaque serveur de sauvegarde vérifie (B7) la validité du certificat (CD) du portefeuille de cryptoactifs au moyen de la clé publique de certification (CL),
- chaque serveur de sauvegarde vérifie (B7) la validité du certificat éphémère (CeD) du portefeuille de cryptoactifs au moyen du certificat (CD) du portefeuille de cryptoactifs,
- le portefeuille de cryptoactifs vérifie (B8.8) la validité du certificat (CBi) de chaque serveur de sauvegarde (CBi) au moyen de la clé publique de certification (CL), et
- le portefeuille de cryptoactifs vérifie (B8.8) la validité du certificat éphémère (CeBi) de chaque serveur de sauvegarde au moyen du certificat (CBi) de chaque serveur.
11. Procédé selon l’une des revendications 9 et 10, dans lequel des données à l’attention du portefeuille de cryptoactifs transmises au programme orchestrateur par un serveur de sauvegarde sont transmises (8.5) par le programme orchestrateur au portefeuille de cryptoactifs sous une forme chiffrée au moyen de la première clé de session (kO), et dans lequel certaines de ces données (RETDTi) sont préalablement hachées (B8.3) par le serveur de sauvegarde au moyen d’une fonction de hachage, puis chiffrées (B8.3) au moyen de la deuxième clé de session (kBi).
12. Procédé selon l’une des revendications 7 à 11 , comprenant une étape initiale (B3, IDVO) de vérification de l’identité de l’utilisateur par le programme orchestrateur, et dans lequel le programme orchestrateur est configuré pour ne pas permettre la sauvegarde des données (Si) dans les serveurs de sauvegarde si la vérification d’identité n’est pas concluante.
13. Procédé selon l’une des revendications 7 à 12 dans lequel le portefeuille de cryptoactifs (CW1 , CW3, DV, CW3) est configuré pour générer la pluralité de données secrète (Si) à partir de la clé maître (S) au moyen d’une fonction de partage de secret configurée pour générer un nombre m de données secrètes et permettre la reconstitution de la clé maître (S) à partir d’un seuil de n données secrètes (Si).
14. Procédé selon la revendication 13, dans lequel m est égal à 3 et n est égal à 2.
15. Procédé selon l’une des revendications 1 à 14, comprenant une étape (R11) de restauration de tout ou partie des données secrètes dans un deuxième portefeuille de cryptoactifs (CW1 , HW), l’étape de restauration étant précédée par des étapes (R11-R12) de récupération de tout ou partie des données secrètes dans les serveurs de sauvegarde par l’intermédiaire du programme orchestrateur, et dans lequel les étapes (R11-R12) de récupération des données secrètes dans les serveurs de sauvegarde sont précédées d’une pluralité d’étapes (R7, IDVi) de vérification de l’identité de l’utilisateur par au moins une partie des serveurs de sauvegarde (BCKSRVi), un serveur de sauvegarde configuré pour vérifier l’identité de l’utilisateur étant également configuré pour refuser de restituer la donnée secrète qu’il détient si la vérification de l’identité de l’utilisateur n’est pas concluante
16. Procédé selon la revendication 15, dans lequel au moins un serveur de sauvegarde (BCKSRVi) est configuré pour déléguer l’étape de vérification de l’identité à serveur (IDVSRVi) spécialisé dans la vérification d’identité, le serveur de sauvegarde étant configuré pour établir une liaison de données avec le serveur spécialisé (IDVSRVi) afin de mettre l’utilisateur en relation avec ce serveur (IDVSRVi).
EP23844173.7A 2022-12-23 2023-12-22 Procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur Pending EP4639835A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FR2214387A FR3144465B1 (fr) 2022-12-23 2022-12-23 Procédé pour la sauvegarde et la restauration personnalisées d’un secret détenu par un portefeuille de cryptoactifs
FR2214391A FR3144471B1 (fr) 2022-12-23 2022-12-23 Procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur
FR2214386A FR3144463B1 (fr) 2022-12-23 2022-12-23 Procédé pour la sauvegarde et la restauration d'un secret détenu par un portefeuille de cryptoactifs
PCT/FR2023/000197 WO2024134039A1 (fr) 2022-12-23 2023-12-22 Procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur

Publications (1)

Publication Number Publication Date
EP4639835A1 true EP4639835A1 (fr) 2025-10-29

Family

ID=89663557

Family Applications (3)

Application Number Title Priority Date Filing Date
EP23847744.2A Pending EP4639837A1 (fr) 2022-12-23 2023-12-22 Procédé pour la sauvegarde et la restauration d'un secret détenu par un portefeuille de cryptoactifs
EP23847745.9A Pending EP4639838A1 (fr) 2022-12-23 2023-12-22 Procédé pour la sauvegarde et la restauration d'un secret détenu par un portefeuille de cryptoactifs
EP23844173.7A Pending EP4639835A1 (fr) 2022-12-23 2023-12-22 Procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur

Family Applications Before (2)

Application Number Title Priority Date Filing Date
EP23847744.2A Pending EP4639837A1 (fr) 2022-12-23 2023-12-22 Procédé pour la sauvegarde et la restauration d'un secret détenu par un portefeuille de cryptoactifs
EP23847745.9A Pending EP4639838A1 (fr) 2022-12-23 2023-12-22 Procédé pour la sauvegarde et la restauration d'un secret détenu par un portefeuille de cryptoactifs

Country Status (4)

Country Link
EP (3) EP4639837A1 (fr)
KR (3) KR20250153184A (fr)
CN (3) CN120642292A (fr)
WO (3) WO2024134038A1 (fr)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013100635A1 (de) * 2013-01-22 2014-07-24 IDnow GmbH Benutzer-Identifikation
EP3073670B1 (fr) * 2015-03-27 2020-09-02 Black Gold Coin, Inc. Système et procédé d'identification personnelle et de vérification
EP3550458A1 (fr) * 2018-04-05 2019-10-09 Keyp GmbH Dispositifs électroniques et procédés d'identification et/ou d'authentification d'un utilisateur
DE102018127529A1 (de) * 2018-11-05 2020-05-07 Infineon Technologies Ag Elektronische Vorrichtung und Verfahren zum Signieren einer Nachricht
JP2022536645A (ja) * 2019-06-10 2022-08-18 ティーゼロ・アイピー，エルエルシー 暗号化された秘密シェアを使用した鍵の回復
US11626997B2 (en) * 2020-03-06 2023-04-11 Vaultie, Inc. System and method for authenticating digitally signed documents
US12014361B2 (en) * 2020-11-25 2024-06-18 Coinbase, Inc. Systems and methods for improved hot wallet security

Also Published As

Publication number Publication date
CN120642292A (zh) 2025-09-12
CN120530598A (zh) 2025-08-22
WO2024134037A1 (fr) 2024-06-27
EP4639838A1 (fr) 2025-10-29
KR20250153184A (ko) 2025-10-24
WO2024134039A1 (fr) 2024-06-27
KR20250151371A (ko) 2025-10-21
KR20250151370A (ko) 2025-10-21
EP4639837A1 (fr) 2025-10-29
WO2024134038A1 (fr) 2024-06-27
CN120530599A (zh) 2025-08-22

Similar Documents

Publication Publication Date Title
JP5663083B2 (ja) 移動中のデータをセキュア化するためのシステムおよび方法
US20190280863A1 (en) Recovery of secret data in a distributed system
EP2811708B1 (fr) Système et méthode pour l'authentification d'un utilisateur
AU2018100503A4 (en) Split data/split storage
US11522691B2 (en) Techniques for virtual cryptographic key ceremonies
WO2022042745A1 (fr) Procédé et appareil de gestion de clé
FR3144471A1 (fr) Procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur
WO2024134039A1 (fr) Procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur
WO2024134040A1 (fr) Procédé pour la sauvegarde et la restauration sécurisée d'une graine détenue par un portefeuille de cryptoactifs
FR3144463A1 (fr) Procédé pour la sauvegarde et la restauration d'un secret détenu par un portefeuille de cryptoactifs
FR3144465A1 (fr) Procédé pour la sauvegarde et la restauration personnalisées d’un secret détenu par un portefeuille de cryptoactifs
WO2025133847A1 (fr) Procédé pour lier à l'identité d'une personne la sauvegarde d'un secret
TWI706277B (zh) 資料備份方法、電腦裝置及電腦可讀取的記錄媒體
HK40129421A (zh) 用於个性化备份和恢复由加密资产钱包持有的秘密的方法
HK40129422A (zh) 一种用於在电子设备与服务器之间建立安全数据连接的方法
HK40129729A (zh) 用於备份和安全地恢复由加密资产钱包持有的种子的方法
EP1262860B1 (fr) Système et procédé d'authentification d'un utilisateur
JP7783468B1 (ja) リカバリシステム、リカバリ装置、リカバリプログラム、リカバリ方法
TWM581231U (zh) Computer device for backing up data
FR2913551A1 (fr) Methode d'authentification mutuelle et recurrente sur internet.
WO2024246702A1 (fr) Système de gestion mutualisée de comptes de cryptoactifs, ayant des modules matériels de gouvernance et de signature distincts
WO2025120454A1 (fr) Procédé de gestion centralisée d'au moins un processus d'approbation d'une action
WO2021099199A1 (fr) Procede et systeme pour le provisionnement ou remplacement securise d'un secret dans au moins un dispositif de communication portable.
FR3137769A1 (fr) Procédé de sauvegarde de données personnelles sensibles sur une chaîne de blocs
WO2021028705A1 (fr) Récupération de données secrètes dans un système distribué

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250718

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)