EP4706201A1 - Système de gestion mutualisée de comptes de cryptoactifs à signature multipartite - Google Patents

Système de gestion mutualisée de comptes de cryptoactifs à signature multipartite

Info

Publication number
EP4706201A1
EP4706201A1 EP24730079.1A EP24730079A EP4706201A1 EP 4706201 A1 EP4706201 A1 EP 4706201A1 EP 24730079 A EP24730079 A EP 24730079A EP 4706201 A1 EP4706201 A1 EP 4706201A1
Authority
EP
European Patent Office
Prior art keywords
signature
transaction
security module
hardware security
service
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
EP24730079.1A
Other languages
German (de)
English (en)
Inventor
Yacine Bénoni BADISS
Laurent Castillo
Nicolas Jean Marie Joseph CHATAING
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 FR2305259A external-priority patent/FR3149104A1/fr
Priority claimed from FR2305261A external-priority patent/FR3149103A1/fr
Application filed by Individual filed Critical Individual
Publication of EP4706201A1 publication Critical patent/EP4706201A1/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/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/085—Secret sharing or secret splitting, e.g. threshold schemes
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • 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/3247—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 digital signatures
    • H04L9/3255—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 digital signatures using group based signatures, e.g. ring or threshold signatures
    • 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/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/3271—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 using challenge-response
    • 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/46—Secure multiparty computation, e.g. millionaire problem

Definitions

  • the present invention relates to a system and method for mutualized management of cryptoasset accounts, in which a request to carry out a transaction on a cryptoasset account can only be executed after having received the agreement of at least one approver and satisfying a governance rule.
  • a cryptoasset wallet is a hardware or software device whose function is to store the private and public keys attached to cryptoasset accounts, and to sign transactions using these keys.
  • HW hardware wallet of crypto assets
  • HW for example the device marketed by the applicant under the name "Nano” or “Stax”
  • HSW companion application
  • the HW device cannot connect directly to the Internet for security reasons, it is associated with the host device HDV to carry out transactions on a BCN blockchain.
  • the host device HDV is for example a computer, a mobile phone, a tablet or equivalent.
  • the connection between the HW device and the host device HDV can be of the USB or Bluetooth type for example.
  • the HW device When the HW device is first put into service, it generates a master key K0 from which it can subsequently derive private keys Kj of crypto-asset accounts, and provides the user with a 24-word recovery phrase that the user must keep on an appropriate physical medium, for example a sheet of paper or an unalterable medium such as an engraved metal plate, which the user must keep in a safe place.
  • an appropriate physical medium for example a sheet of paper or an unalterable medium such as an engraved metal plate, which the user must keep in a safe place.
  • 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 hardware security module HSM ("Hardware Security Module") located in a data center.
  • HSM Hardware Security Module
  • Such a hardware security module is also called in French “transactional black box” BTN (https:/fr.wikipedia.org/wiki/Hardware_Security_Module). It is generally the rule that the hardware security module HSM does not store the user's private keys and only ensures the control of the authenticity of the HW device, its commissioning, the updating of its operating system, the downloading of certified application programs, etc.
  • a hardware security module is provided to execute a transaction governance service and sign the transactions.
  • the hardware security module must hold the master key and/or the private keys of the cryptoasset accounts concerned.
  • the security of these accounts is based on the inviolability of the hardware security module. This protects private keys, validates authorization processes and generates transaction signatures in accordance with predetermined governance rules.
  • WO2023046409A1 Also known, from WO2023046409A1, is a system for approving transactions relating to non-mutualized crypto-asset accounts, in which a hardware wallet addresses a transaction to be signed to policy services.
  • the policy services provide signature authorizations to a signature service.
  • the signature service signs the transaction and returns it to the hardware wallet, which places the signed transaction on a blockchain.
  • the policy services and the signature service are not executed by a hardware security module but use a common hardware security module. After a phase of integrating construction and deployment secrets, the common hardware security module provides the policy services with public keys that the latter send to the signature service in a form encrypted by the construction and deployment secrets.
  • the common hardware security module also provides the signature service with the signature of the transaction approved by policy services.
  • the applicant uses hardware security modules hosted in secure data centers located in various parts of the world, and offering a very high level of security compliant for example with the FIPS 140-2 level 3 standard, and in which various additional hardware and software securities are also implemented.
  • Embodiments relate to a system for mutualized management of cryptoasset accounts, in which a request to carry out a transaction on a cryptoasset account can only be executed after having received the agreement of at least one approver and satisfying a governance rule relating to the carrying out of the transaction, the system comprising: a transaction platform executed by a server, on which transaction descriptions can be created, the transaction platform being configured to, after creation of a transaction, issue a request to carry out the transaction; a first hardware security module coupled to the transaction platform, configured to execute governance rules relating to the carrying out of transactions; a second hardware security module; a signature service configured to generate a signature of a transaction, the signature service comprising a first signature service executed by an intermediate signature device and configured to generate a first signature from a first secret data item, and a second signature service executed by the second hardware security module and configured to generate a second signature from a second secret data item, and a memory receiving the second secret data item, the memory being accessible in read and write mode to the second hardware security module and inaccessible
  • the first hardware security module is configured to, in response to a request to perform a transaction issued by the transaction platform, request the approval of at least one approving device and verify whether a governance rule applicable to the requested transaction is satisfied, then, when the governance rule is satisfied, transmit a request to sign the transaction at least to the first signature service.
  • the system being configured to provide, as a signature of a transaction, a multi-party signature based on the first signature and the second signature.
  • the first hardware security module, the intermediate signature device, and the second hardware security module are configured such that the second hardware security module never receives the transaction, the second hardware security module being configured to generate the second signature without having knowledge of the contents of the transaction.
  • the second hardware security module is configured to generate the second signature from the first signature and the second secret data, the second signature forming the signature of the transaction.
  • the first signature and the second signature are complementary, the system comprising a service for broadcasting the transaction on the blockchain configured to combine the first signature and the second signature in order to obtain the signature of the transaction.
  • the first hardware security module is configured to, when the governance rule is satisfied, transmit at least to the intermediate signature device a digest of the transaction generated by a hash function, and additional data allowing the intermediate signature device to generate the first signature from this digest.
  • the complementary data comprises a hierarchical deterministic derivation path and a signature function to be used to generate the signature or an identifier of this function.
  • the first hardware security module is arranged in a first restricted access location
  • the second hardware security module is arranged in a second restricted access location different from the first location
  • a governance rule defines at least a number of approvals to be received from approving devices for a transaction to be signed and executed.
  • the system comprises at least one approving device, the approving device comprising cryptographic calculation means for establishing a secure communication channel with the first hardware security module.
  • the first hardware security module and the approving device are members of the same public key infrastructure comprising a certification authority providing said public key, and in which the approving device and the first hardware security module are configured to establish between them a secure communication channel by executing the following steps: mutual verification by each entity that the other entity has a static certificate valid with respect to the public key of the public key infrastructure, generation by each entity of an ephemeral certificate comprising an ephemeral public key signed with a private key of the entity, mutual verification by each entity that the ephemeral certificate of the other entity is valid with respect to its static certificate, generation of a session key by Diffie-Hellman key exchange between the two entities, and use of the session key to encrypt the secure communication channel.
  • the approving device is configured to display to a natural person user a description of the transaction, collect the user's approval, sign with a private key a challenge or data comprising the challenge received from the first hardware security module, then send the obtained signature to the first hardware security module.
  • Embodiments also relate to a method for mutualized management of cryptoasset accounts, in which a request to perform a transaction on a cryptoasset account can only be executed after having received the agreement of at least one approver and satisfying a governance rule relating to the performance of the transaction.
  • the method is implemented by means of a system comprising: a transaction platform executed by a server, on which transaction descriptions can be created, the transaction platform being configured to, after creation of a transaction, issue a request to perform the transaction; a first hardware security module coupled to the transaction platform, configured to execute governance rules relating to the performance of transactions; a second hardware security module; a signature service configured to generate a signature of a transaction, the signature service comprising a first signature service executed by an intermediate signature device and configured to generate a first signature from a first secret data, and a second signature service executed by the second hardware security module and configured to generate a second signature from a second secret data; and a memory receiving the second secret data, the memory being accessible in read and write mode to the second hardware security module and inaccessible to the first hardware security module.
  • the method comprises the steps of, in response to a request to perform a transaction issued by the transaction platform, requesting, by means of the first hardware security module, the approval of at least one approving device and checking whether a governance rule applicable to the requested transaction is satisfied; when the governance rule is satisfied, transmitting a request to sign the transaction at least to the first signature service; by means of the first signature service, generating the first signature; by means of the second signature service, generating the second signature; and generating a multi-party signature based on the first signature and the second signature, the multi-party signature forming the signature of the transaction.
  • the second hardware security module never receives the transaction, the second hardware security module being configured to generate the second signature from the first signature without having knowledge of the contents of the transaction.
  • the first signature and the second signature are cumulative, the second hardware security module being configured to generate the second signature from the first signature and the second secret data, the second signature forming the signature of the transaction.
  • the first signature and the second signature are complementary, the system comprising a step of combining the first signature and the second signature in order to obtain the signature of the transaction.
  • the method comprises the step of, by means of the first hardware security module, when the governance rule is satisfied, transmitting at least to the intermediate signature device a digest of the transaction generated by a hash function, and additional data making it possible to generate the first signature from this digest.
  • the complementary data comprises a hierarchical deterministic derivation path and a signature function to be used to generate the signature or an identifier of this function.
  • the first hardware security module is arranged in a first restricted access location
  • the second hardware security module is arranged in a second restricted access location different from the first.
  • a governance rule authorizes the signing of a transaction based on a number of approvals to be received from approving devices.
  • the system For at least one set of cryptoasset accounts derived from a master key K0, the system is intended to be used by a set of PAi participants in which we distinguish co-owners of the OWNi accounts ("shared-owner"), ADMi administrators, and OPi operators. It includes a TPF transaction platform allowing a plurality of OPi operators (OP1... OPN) to carry out operations on such cryptoasset accounts, subject to the agreement of a specific number of operators defined by governance rules.
  • the administrators define the governance rules. They can also, in one embodiment, approve or even designate co-owners.
  • the co-owners generate the master key K0 of the set of cryptoasset accounts, from master keys K0i that are specific to them.
  • the OPi operators initiate transactions or approve transactions initiated by other operators.
  • Each ADMi, OWNi or OPi participant includes cryptographic calculation means.
  • the system shown advantageously comprises two hardware security modules HSM1, HSM2.
  • the first hardware security module HSM1 is coupled to a first server SRV1 and the second hardware security module HSM2 is coupled to a second server SRV2.
  • the term "hardware security module” designates a module of the type discussed above, generally housed in a data center, offering a high level of hardware and software security, for example compliant with FIPS 140-2 level III.
  • the SRV1 server includes and executes the TPF transaction platform, as well as a NOTIF notification service and an ORCH orchestrator service.
  • the HSM1 module includes and executes a GOV governance service.
  • the SRV2 server includes and executes a LKS link service for establishing the https2 link with the HSM2 module.
  • the HSM2 module includes and executes a SIGN1 signature service.
  • the HSM2 module also includes and executes a KCER1 key ceremony service, for recording the master key K0 in a MEM memory.
  • the system includes a BCAST service for broadcasting signed transactions on BCN blockchain networks.
  • the BCAST service is shown herein as non-limiting as being executed by the SRV1 server but could also be executed by the SRV2 server, as shown in dotted lines, or any other server or device associated with the system.
  • the system offers a higher level of security than conventional systems thanks to the provision of the two hardware security modules HSM1, HSM2 and the separation of the governance function - i.e. the management of transaction approval processes - and the transaction signing function.
  • Each PAi participant here includes:
  • PSDi personal security device associated with an HDVi host device running a HSW companion application, for example the “Ledger Live” application developed by the applicant, and
  • the PSDi personal security device is a device having a cryptoasset hardware wallet type architecture and comprising an integrated circuit secure element associated with an integrated circuit microcontroller, the microcontroller being configured to allow the secure element to establish a secure communication channel with the HSM1 hardware security module via the HDVi host device running the HSW companion application.
  • a security device is for example the device marketed by the applicant under the name "Ledger BLue”, “Nano” or “Stax”, or an equivalent device.
  • the PSDi personal security device and the HDVi host device form a single device, for example a so-called "blockchain" phone, comprising an integrated hardware wallet made from an integrated circuit secure element or from a trusted execution environment TEE that emulates a secure element.
  • a so-called "blockchain” phone comprising an integrated hardware wallet made from an integrated circuit secure element or from a trusted execution environment TEE that emulates a secure element.
  • TEE trusted execution environment
  • the PAi participating devices may be portable or non-portable computing devices that connect to the SRV1 server via an application programming interface (“API").
  • API application programming interface
  • the personal security devices PSDi, the HSM1 module and the HSM2 module are members of a public key infrastructure PA managed by a certification authority CA providing a public key PA. They each comprise a private key, respectively dPi, dH1, dH2, a static public key, respectively PPi, PH1, PH2, and a certificate, respectively CPi, CH1, CH2.
  • This certificate is provided by the certification authority CA and comprises their public key and a signature thereof produced by the certification authority using its private key dA.
  • each PSDi device can establish a secure communication channel SC1i with the HSM1 module.
  • the HSM1 module can establish a secure communication channel SC2 with the HSM2 module.
  • Each PSDi device can also establish a secure communication channel SC3i with the HSM2 module.
  • the secure communication channel SC1i between a PSDi and the HSM1 module is established here via the secure data link https1.
  • the secure communication channel SC3i between a PSDi and the HSM1 module is established here via the secure data link https1 and the secure data link https2.
  • the secure communication channel SC2 between the HSM1 and HSM2 modules is established here via the secure data link https2.
  • FIGS 4A, 4B illustrate two embodiments of a transaction signing method implemented using the system of the .
  • the HSM1 module after receiving a description of the transaction and verifying that the associated governance rule is satisfied, transmits the transaction T to the HSM2 module, generally in a raw form called a “raw transaction”
  • the transaction according to the example above when transformed into a raw transaction, can for example have the following value (in hexadecimal):
  • the HSM2 module by means of its signature service SIGN1, then signs the raw transaction T using a private key of the cryptoasset account concerned, derived from the master key K0 held in the MEM memory, and produces a signature SIG1(T, K0) depending on the raw transaction T and the secret K0.
  • Each signature algorithm is specific to the BCN blockchain considered.
  • the two main blockchains (Ethereum and Bitcoin) use the ECDSA/secp256k1/SHA256 algorithm as a means of signature, i.e.
  • the transaction T and its signature SIG1 are then transmitted to the BCAST broadcast service so that it broadcasts the transaction on the BCN blockchain concerned.
  • the HSM2 module is aware of the transaction since it was communicated to it for generation of the SIG1 signature.
  • the BCAST broadcast service can therefore be executed by the SRV2 server coupled to the HSM2 module, as shown in dotted lines on the , and receive the transaction T from the HSM2 module. It can also be executed by the SRV1 server coupled to the HSM1 module.
  • the signature SIGN1 is communicated to the HSM1 module by the HSM2 module.
  • the data links between the HSM1 and HSM2 modules are made through secure communication channels, examples of implementation of which will be described later.
  • the method of realization of the is distinguished from that of the in that the HSM1 module does not communicate the raw transaction T to the HSM2 module, but the hashcode HT of the latter or of a part of it, produced by a hash function, for example the SHA-256 function.
  • the first step in producing the signature is carried out by the HSM1 module.
  • the HSM1 module also transmits to the HSM2 module information that it needs to generate the signature of the transaction, such as the applicable DRV derivation path (hierarchical deterministic derivation path) and the ECDSA signature function or an identifier thereof (the HSM2 module generally having in memory a catalog of functions that may be needed to generate signatures).
  • the transaction T and its signature SIG1 are as previously transmitted to the BCAST broadcast service so that it broadcasts the transaction on the BCN blockchain.
  • the HSM2 module does not, at this stage, have knowledge of the transaction T since it has not been communicated to it for the generation of the SIG1 signature. It can therefore be decided, in order to increase the security of the system, to ensure that the transaction is never communicated to it, since it does not need it, and that it is also never communicated to the SRV2 server coupled to the HSM2 module.
  • the signature service can only communicate the SIG1 signature to the BCAST broadcast service.
  • the transaction T is then communicated to the BCAST service by the HSM1 module.
  • the BCAST broadcast service cannot be executed by the SRV2 server, and is executed by the SRV1 server, as shown in solid lines on the , since the latter is aware of transaction T.
  • the proposed multi-tenant transaction management system architecture comprises two separate hardware security modules, the first to enforce governance rules and authorize transaction signing when the governance rules are satisfied, the second to sign transactions.
  • the hardware security module that authorizes the signing of transactions cannot sign them itself because it does not have the K0 secret allowing it to sign them, and the hardware security module that signs the transactions has no knowledge of them.
  • a step G1 an ADMi administrator connects to the ORCH service of the SRV1 server and requests the configuration of the GOV governance service.
  • a secure communication channel SC1i is created between the HSM1 module and the personal security device PSDi of the ADMi administrator, and the personal security device PSDi connects to the GOV governance service.
  • the administrator defines one or more governance rules.
  • the personal security device PSDi of the administrator addresses the desired governance rules to the governance service via the SC1i channel.
  • a step G5 the governance service requests the NOTIF notification service of the SRV1 server to send to the other ADMi administrators a notification of voting on the governance rules.
  • a step G6 secure communication channels SC1i are established between the personal security modules PSDi of the other ADMi administrators and the governance service.
  • the PSDi personal security devices of the other administrators communicate to the governance service their agreement or refusal of each proposed rule.
  • the rules are adopted in whole or in part, depending on the vote of the administrators.
  • Governance rules may be defined and adopted using various methods other than the one just described. Adoption rules defining a quorum and a majority rule for the adoption of governance rules may be hard-coded into the governance service.
  • Governance rules may be simple, complex, single or multiple. For example, they may define a minimum number of unidentified operators who must approve a transaction by type of cryptoasset concerned and/or based on the amount of the transaction, or define by name the operators who may approve a transaction by type of cryptoasset concerned and/or based on the amount of the transaction. They may also define the operators authorized to create a transaction on the TPF platform for a given type of cryptoasset, and those who are not authorized and can only be approvers of transactions.
  • the solicitation and then collection, by the governance service, of an approval of a governance rule issued by an administrator comprises the following steps:
  • the governance service sends a random challenge and the description of the governance rule to the other PSDi security devices of the administrators concerned,
  • each PSDi security device of each administrator then displays to the corresponding administrator user USRi the description of the governance rule, collects the user's approval, then signs the challenge with his private key dPi, sends the signed challenge to the governance service,
  • the governance service checks the validity of the signature, the governance rule being deemed approved by the administrator concerned if the signature is valid.
  • a co-owner OWNi connects to the orchestrator service ORCH of the server SRV1.
  • the co-owner OWNi activates the key ceremony service KCER1 via the orchestrator service.
  • the notification service NOTIF of the server SRV1 sends to each other co-owner OWNi a notification of invitation to the ceremony.
  • secure communication channels SC3i are established between the personal security device PSDi of each co-owner OWNi and the key ceremony service KCER1.
  • the service KCER1 receives the master key K0i or a part of the master key of each PSDi device.
  • the service KCER1 generates the private key K0 from the master keys or parts of master keys received, and stores it in the memory MEM.
  • fragments of the master keys are generated using a BIP32 derivation function m/code1'/key in which
  • code1' is a process specific code, which can be arbitrary
  • key indicates the next level key, derived from the parent key.
  • the master key K0 is then obtained by calculating the EXCLUSIVE OR of all the fragments derived from the master keys of the PSDi devices of the OWNi co-owners.
  • the keys of the cryptoasset accounts are then derived from this key.
  • the extended private key or xprv master key of a Bitcoin account is generated classically by applying the HMAC-SHA512 hashing algorithm to the key K0 using the terms "Bitcoin Seed” as the key and the terms "master seed” as the message.
  • an OPi operator connects to the TPF transaction platform.
  • the operator creates the transaction description.
  • the TPF platform sends to the GOV governance service a transaction request including the transaction description.
  • the governance service generates a transaction approval request for the attention of APi approvers who are designated by the applicable governance rule as able to approve the transaction request. An example of carrying out such an approval request, from a random challenge, will be described later.
  • the governance service informs the NOTIF notification service that a transaction is requested.
  • the notification service sends a transaction notification to all the concerned APi approver operators, designated by the applicable governance rule.
  • the PSDi personal security device of each APi approver creates a secure channel SC1i with the governance service ( ).
  • the governance service sends to each PSDi personal security device of each APi approver the description of the transaction and the approval request.
  • each APi approver reviews and approves the transaction.
  • each APi approver confirms his approval to his PSDi personal security device.
  • the PSDi personal security device of each approver generates an approval of the transaction.
  • each approver's personal security device sends its approval of the transaction to the GOV governance service.
  • the data transmissions between the governance service and each PSDi device during steps S8 and S12 are performed by means of the secure channel SC1i.
  • the governance service GOV verifies the approval of the transaction received from each PSDi device.
  • the governance service generates a raw transaction from the transaction description. This calculation of the raw transaction shown here as performed by the governance service can however be entrusted to the SRV1 server or to any appropriate external service.
  • the governance service creates at step S30 the secure communication channel SC2 with the signature service SIGN1 executed by the HSM2 module, via the https2 link.
  • the governance service sends to the signature service SIGN1 the raw transaction T (implementation mode of the ), or sends it the HT digest of the raw transaction accompanied by the DRV derivation path and the IDF identifier of the signature function (implementation of the ).
  • the transmission of this data may be accompanied by a signature request, which may be implicit or take the form of a command.
  • the signature service SIGN1 signs the raw transaction.
  • the transaction T and its signature SIG1 are sent to the broadcast service BCAST.
  • the transaction T is provided by the signature service SIGN1 at the same time as its signature SIG1 if the signature service is aware of the transaction (embodiment of the ). If the signature service is not aware of transaction T (mode of execution of the ), this is communicated by the governance service GOV of the HSM1 module during a step S33'.
  • the BCAST service places the signed transaction on the BCN blockchain concerned.
  • the governance service erases the transaction from its memory at a step S50.
  • it sends to the NOTIF notification service information that the approval of the transaction has failed.
  • the notification service sends failure notifications to the transaction platform, the creator and the approvers.
  • entity X is a PSDi personal security device
  • entity Y can be the HSM1 module (GOV governance service) for the creation of the SC1i channel, or the HSM2 module (signing or key ceremony service) for the creation of the SC3i channel.
  • entity X can also be the HSM1 module and entity Y can be the HSM2 module for the creation of the SC2 channel.
  • Each entity X, Y has a private key d X , d Y , a public key P X , P Y , and a certificate C X , C Y including its public key and a signature of it using the private key dA of the certification authority CA:
  • the entity X generates a pair of ephemeral private and public keys of X , Pe X .
  • the entity X generates an ephemeral certificate Ce X comprising its ephemeral public key Pe X and a signature of the latter with its private key d X :
  • entity X sends to entity Y its ephemeral public key Pe X , the ephemeral certificate Ce X , its public key P X and its certificate C X .
  • entity Y verifies the certification chain of entity X:
  • the public key PA of the certification authority allows it to verify the validity of the signature of the public key P X appearing in the certificate C X , then the verified public key P X allows it to verify the validity of the signature of the ephemeral public key Pe X appearing in the ephemeral certificate.
  • the entity Y If the verification is conclusive, at a step S64 the entity Y generates a pair of ephemeral private and public keys of Y , Pe Y. At a step S65, the entity Y generates an ephemeral certificate Ce Y comprising its ephemeral public key Pe Y and a signature of the latter with its private key d Y :
  • the entity Y generates an ephemeral session key k from its ephemeral private key of Y and the ephemeral public key Pe X of the entity X, by means of a key exchange function such as for example the ECDH function (Diffie Hellman key exchange based on elliptic curves or "Elliptic Curve Diffie–Hellman”), i.e.:
  • a key exchange function such as for example the ECDH function (Diffie Hellman key exchange based on elliptic curves or "Elliptic Curve Diffie–Hellman"), i.e.:
  • entity Y sends to entity X its ephemeral public key Pe Y as well as, in a form encrypted using key k, its ephemeral certificate Ce Y and its certificate C Y containing its public key P Y :
  • the entity X itself generates the session key k from its ephemeral private key of X and the ephemeral public key Pe Y of the entity Y, by means of the same function as that used by the entity Y, here the ECDH function:
  • the entity X is therefore able to decrypt the message ⁇ Ce Y , C Y ⁇ k.
  • step S70 entity X verifies the certification chain of entity Y:
  • the public key PA of the certification authority allows it to verify the validity of the signature of the public key P Y appearing in the certificate C X , then the certified public key P Y allows it to verify the validity of the signature of the ephemeral public key Pe Y appearing in the ephemeral certificate.
  • the two entities have mutually authenticated each other as belonging to the same public key infrastructure.
  • the ephemeral session key k that they have commonly generated is not replayable and is also not susceptible to a man-in-the-middle attack. It can therefore be used securely to encrypt the exchanged messages.
  • step S4 the GOV governance service generates a challenge C for the approval of the transaction:
  • RandomBytes(32) being a well-known function that generates a 32-byte (256-bit) string of random data.
  • step S7 the governance service creates the secure channel SC1i with the personal security device PSDi of the approver APi.
  • the governance service sends the description of the transaction and the challenge C to the PSDi device.
  • step S9 the approver APi examines and approves the transaction. As specified above, it is here the user USRi natural person who verifies the transaction.
  • step S10 if the approver natural person has approved the transaction, he confirms his approval to the personal security device PSDi by an action on it ("Approve" frame on the ).
  • step S11 the PSDi device signs the challenge C with its private key dPi:
  • transaction description could be concatenated with the challenge, or any other data:
  • step S12 the PSDi device sends the signed challenge to the governance service.
  • step S13 the governance service verifies the signature S of the challenge. If the natural person approver, in a step S100, indicates to the PSDi device that it refuses the transaction, the device returns an error message to the governance service during a step S101.
  • the system differs from that of the in that it implements a multi-party signature algorithm, also called a MPC ("Multi-Party Computation") signature algorithm, by which a signature is generated by at least two parties.
  • a multi-party signature algorithm also called a MPC ("Multi-Party Computation") signature algorithm
  • the system comprises at least one additional signature device SIGNDV.
  • the SIGNDV device is a secure device, for example of the HSM type, or a PSD type device, accessible via a LKS’ link service executed by a DV3 device.
  • the DV3 device is for example a server if the SIGNDV device is of the HSM type or a host device if the SIGNDV device is of the PSD type.
  • the LKS’ link service makes it possible to establish a secure https3 data link between the SIGNDV device and the SRV1 server. This link also allows the PSDi personal security devices of the OPi operators to establish a secure SC4i communication channel with the HSM2 module via the https1 and https3 links.
  • the SIGNDV device is here a member of the public key infrastructure PA and comprises a private key dD, a public key PD and a certificate CD.
  • the SIGNDV device includes and executes a signature service MSIGN1 using a MPC signature share SH1 that is stored in a memory MEM1.
  • the HSM2 module includes and executes a signature service MSIGN2 that replaces the previously described SIGN1 service and uses a signature share SH2 stored in a memory MEM2.
  • the HSM1 module does not have access to any of the memories MEM1, MEM2.
  • the HSM2 module does not have access to the memory MEM1 of the SIGNDV device and the SIGNDV device does not have access to the memory MEM2 of the HSM2 module.
  • Each SH1, SH2 share is typically a part of a shared secret and is generated during a key ceremony in which the MSIGN1 and MSIGN2 services exchange information via secure channels.
  • the key ceremony may include a step of drawing a random number to generate the SH1, SH2 shares.
  • co-owners OWNi may participate in the key ceremony so that the master keys K0i of their respective PSDi devices are used to generate the SH1, SH2 shares.
  • FIGS 16A, 16B, 16C and 16D illustrate several embodiments of an MPC signature method implemented by the system of the .
  • the MPC signature of a transaction is produced by accumulation, with the signature service MSIGN2 providing a signature SIG2 which is a function of a signature SIG1 provided by the signature service MSIGN1 and which constitutes the signature of the transaction.
  • the MPC signature of a transaction is produced by combination, with the signature service MSIGN1 providing a partial signature SIG1 and the signature service MSIGN2 providing a partial signature SIG2.
  • the two partial signatures are combined using a combination function Fmpc to obtain the signature of the transaction.
  • This combination function can be performed by the broadcast service BCAST or any other service which can be provided upstream of the BCAST service for the preparation of the signed transactions to be broadcast.
  • the HSM1 module provides the transaction T to the MSIGN1 signature service of the SIGNDV device, and the latter provides the HSM2 module with the SIG1 signature which is a function of the transaction and the SH1 share.
  • the MSIGN1 signature service provides the transaction T and the SIG1 signature to the MSIGN2 signature service, and the latter provides the BCAST broadcast service with the SIG2 signature which is a function of the transaction T, the SIG1 signature and the SH2 share.
  • the transaction T can be provided to the MSIGN2 service by the HSM1 module.
  • the BCAST service receives the transaction from the MSIGN2 service but could also receive it directly from the HSM1 module.
  • the BCAST broadcast service can be executed by the SRV1 server coupled to the HSM1 module, as illustrated in solid lines on the , or by the SRV2 server coupled to the HSM2 module or by the DV3 device coupled to the SIGNDV signature device, as illustrated in dotted lines on the .
  • the HSM1 module provides the MSIGN1 signature service with the HT digest of the transaction, the appropriate DRV derivation path and the IDF identifier of the appropriate signature function (or the signature function itself).
  • the MSIGN1 signature service provides the HSM2 with the SIG1 signature which is a function of the HT digest and the SH1 share.
  • the MSIGN1 signature service provides the HT digest, the DRV derivation path, the IDF identifier and the SIG1 signature to the MSIGN2 signature service, which provides the BCAST broadcast service with the SIG2 signature which is a function of the HT digest, the SIG1 signature and the SH2 share.
  • the HT digest, the DRV derivation path, the IDF identifier can be provided to the MSIGN2 service by the HSM1 module.
  • the BCAST service here receives the transaction from the HSM1 module, the MSIGN2 service not knowing it.
  • the broadcast service BCAST can be executed by the server SRV1 coupled to the module HSM1.
  • the hardware security module that authorizes the signing of transactions cannot sign them itself because it does not possess the secrets SH1, SH2 allowing them to be signed, and the signature services that sign the transactions are not aware of them.
  • the HSM1 module provides the transaction T to the MSIGN1 signature service of the SIGNDV device and to the MSIGN2 signature service of the HSM2 module.
  • the MSIGN1 signature service provides the BCAST broadcast service with a partial signature SIG1 that is a function of the transaction and the SH1 share.
  • the MSIGN2 signature service provides the BCAST broadcast service with a partial signature SIG2 that is a function of the transaction and the SH2 share.
  • the BCAST service combines the two partial signatures by means of the Fmpc function to obtain the transaction signature.
  • the transaction T can be provided to the BCAST service by either of the signing devices or by the HSM1 module.
  • the transaction T is known to the different parties of the system, neither of the two signing parties can sign the transaction if it does not have knowledge of the partial signature provided by the other party. It may be preferable to have the BCAST broadcast service executed by the SRV1 server coupled to the HSM1 module, as illustrated in solid lines on the , rather than having it executed by either of the two signatory parties.
  • the HSM1 module provides the transaction digest HT, the derivation path DRV and the identifier IDF of the signature function to the signature service MSIGN1 of the SIGNDV device and to the signature service MSIGN2 of the HSM2 module.
  • the signature service MSIGN1 provides the broadcast service BCAST with a partial signature SIG1 which is a function of the digest HT and the part SH1.
  • the signature service MSIGN2 provides the broadcast service BCAST with a partial signature SIG2 which is a function of the digest HT and the part SH2.
  • the BCAST service combines the two partial signatures by means of the Fmpc function to obtain the signature of the transaction.
  • the transaction T is provided here to the BCAST service by the HSM1 module.
  • the BCAST broadcast service can be executed by the SRV1 server coupled to the HSM1 module, as illustrated in solid lines on the , to obtain as previously a system architecture in which the hardware security module which authorizes the signing of transactions cannot sign them itself because it does not possess the secrets SH1, SH2 allowing them to be signed, and the signature services which sign the transactions are not aware of them.
  • step S40 the governance service GOV creates a secure communication channel SC2a, via the https3 link, with the signature service MSIGN1, and a secure communication channel SC2b, via the https2 link, with the signature service MSIGN2.
  • a step S41 the governance service sends to the signature service MSIGN1, via the secure channel SC2a, the raw transaction T ( ) or sends it its HT condensate, the DRV derivation path and the IDF identifier ( ).
  • This data is possibly accompanied by a signature request (which can be implicit or take the form of a command).
  • the governance service sends to the signature service MSIGN2, via the secure channel SC2b, the raw transaction T ( ) or sends it its HT condensate, the DRV derivation path and the IDF identifier ( ).
  • This data may be accompanied by a request for signature (which may be implicit or take the form of an order).
  • the signature service MSIGN1 generates the partial signature SIG1 by means of the part SH1.
  • the signature service MSIGN1 sends the partial signature SIG1 to the broadcast service BCAST.
  • the signature service MSIGN2 generates the partial signature SIG2 by means of the part SH2.
  • the signature service MSIGN1 sends the partial signature SIG1 to the broadcast service BCAST.
  • the process is secured by the partial signature of the transaction so that if the transaction is intercepted and altered by an attacker, the partial signature will be wrong and the final signature will be wrong too. This is because neither the HSM2 module nor the SIGNDV device can sign the transaction alone. To sign the transaction, both signatures are required.
  • the BCAST service assembles the partial signatures SIG1, SIG2 by means of the Fmpc function to obtain the signature of the transaction, then broadcasts the signed transaction on the BCN blockchain concerned. If the signatures SIG1, SIG2 were generated from the HT digest, the signature services MSIGN1, MSIGN2 cannot communicate the raw transaction T to the BCAST service. A step of transmission of the transaction T to the BCAST module, by the HSM1 module, not shown in the , can then be planned (Cf. ).
  • a security-enhanced transaction system for the mutualized management of cryptoasset accounts are susceptible to various variants.
  • a third or even a fourth partial signature device could be provided to generate a multiparty signature comprising three or more components.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Système de gestion mutualisée de comptes de cryptoactifs, dans lequel une demande de réalisation d'une transaction sur un compte de cryptoactif ne peut être exécutée qu' après avoir reçu l'accord d'au moins un approbateur et satisfait une règle de gouvernance. Le système comprend un premier module de sécurité matériel (HSM1) configuré pour exécuter des règles de gouvernance, un dispositif de signature intermédiaire (SIGNDV) et un second module de sécurité matériel (HSM2) configurés pour signer ensemble des transactions sur demande du premier module de sécurité matériel (HSM1), les signatures de transaction étant des signatures multipartites fonction d'une première signature (SIG1) fournie par le dispositif de signature intermédiaire et d'une seconde signature (SIG2) fournie par le second module de sécurité matériel (HSM2).

Description

    Système de gestion mutualisée de comptes de cryptoactifs à signature multipartite
  • La présente invention concerne un système et un procédé de gestion mutualisée de comptes de cryptoactifs, dans lequel une demande de réalisation d’une transaction sur un compte de cryptoactif ne peut être exécutée qu’après avoir reçu l’accord d’au moins un approbateur et satisfait une règle de gouvernance.
    • Arrière-plan
  • Ces dernières années, le développement des cryptomonnaies ou autres types de cryptoactifs gérés par blockchain, tels que les jetons non fongibles ("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. .
  • La montre schématiquement un exemple de portefeuille matériel de cryptoactifs 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 pour des raisons de sécurité, il est associé au dispositif hôte HDV pour réaliser des transactions sur une blockchain BCN. 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.
  • Lors de la première mise en service du dispositif HW, celui-ci génère une clé maître K0 à partir de laquelle il pourra ultérieurement dériver des clés privées Kj de comptes de cryptoactifs, et 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 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é matérielle HSM ("Hardware Security Module") situé dans un datacenter. Un tel module de sécurité matérielle est également appelé en français "boîte noire transactionnelle" BTN (https:/fr.wikipedia.org/wiki/Hardware_Security_Module). Il est généralement de règle que le module de sécurité matérielle HSM ne stocke pas les clés privées 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.
  • Une exception à cette règle doit être faite dans le cas d’une gestion mutualisée de comptes de cryptoactifs, dans laquelle une transaction sur un compte de cryptoactif ne peut être exécutée qu’après avoir reçu l’accord d’au moins un approbateur et satisfait une règle de gouvernance. On prévoit dans ce cas un module de sécurité matérielle pour exécuter un service de gouvernance de transactions et signer les transactions. A cet effet, le module de sécurité matérielle doit détenir la clé maître et/ou les clés privées des comptes de cryptoactifs concernés. Lorsque la réalisation d’une transaction est demandée au module de sécurité matérielle, celui-ci identifie la règle de gouvernance qui s’applique à la transaction demandée, puis sollicite l’accord d'opérateurs désignés par cette règle de gouvernance. Lorsque l’accord des opérateurs est reçu, le module de sécurité matérielle signe la transaction avec la clé privée appropriée puis la diffuse sur la blockchain concernée.
  • Ainsi, dans le cadre d’une gestion mutualisée de comptes de cryptoactifs, la sécurité de ces comptes repose sur l’inviolabilité du module de sécurité matérielle. Celui-ci protège les clés privées, valide les processus d'autorisation et génère des signatures de transaction conformément à des règles de gouvernance prédéterminées.
  • On connaît également, par WO2023046409A1, un système d’approbation de transactions relatives à des comptes de cryptoactif non mutualisés, dans lequel un portefeuille matériel (« wallet ») adresse une transaction à signer à des services de politique. Les services de politique fournissent des autorisations de signature à un service de signature. Le service de signature signe la transaction et la renvoie au portefeuille matériel, qui place la transaction signée sur une blockchain. Les services de politique et le service de signature ne sont pas exécutés par un module de sécurité matérielle mais utilisent un module de sécurité matérielle commun. Après une phase d'intégration de secrets de construction et de déploiement, le module de sécurité matérielle commun fournit aux services de politique des clés publiques que ces derniers envoient au service de signature sous une forme cryptée par les secrets de construction et de déploiement. Le module de sécurité matérielle commun fournit également au service de signature la signature de la transaction approuvée par des services de politique.
  • La demanderesse utilise des modules de sécurité matérielle hébergés dans des data centers sécurisés se trouvant en diverses parties du monde, et offrant une sécurité de très haut niveau conforme par exemple à la norme FIPS 140-2 niveau 3, et dans lesquels diverses sécurités matérielles et logicielles supplémentaires sont en outre mises en œuvre.
  • Elle conduit par ailleurs divers travaux de recherche permettant de maintenir au plus haut niveau la sécurité offerte par les modules de sécurité matérielle. En 2019, la demanderesse a ainsi découvert 14 vulnérabilités dans un module HSM. L'exploitation de ces vulnérabilités aurait pu permettre à un attaquant distant d'obtenir une exécution de code arbitraire dans le HSM et éventuellement d'extraire toutes les clés secrètes, sans aucune authentification. Ce problème a été divulgué de manière responsable et correctement corrigé par les fournisseurs de HSM, ce qui a permis de relever le niveau de sécurité pour l'ensemble de l'industrie du HSM. Voir : https:/donjon.ledger.com/BlackHat2019-presentation.
  • Malgré l’absence connue à ce jour d’un quelconque problème de sécurité qui aurait pu conduire à une attaque sur des clés de comptes mutualisés détenues par de tels modules de sécurité matérielle, la demanderesse est sans cesse en recherche de perfectionnements visant à augmenter le niveau de sécurité des systèmes qu’elle développe (Cf. https:/donjon.ledger.com).
  • Il pourrait donc être souhaité d’augmenter le niveau de sécurité offert par un système de gestion mutualisée de comptes de cryptoactifs du type qui vient d’être décrit.
    • Résumé
  • Des modes de réalisation concernent un système de gestion mutualisée de comptes de cryptoactifs, dans lequel une demande de réalisation d’une transaction sur un compte de cryptoactif ne peut être exécutée qu’après avoir reçu l’accord d’au moins un approbateur et satisfait une règle de gouvernance relative à la réalisation de la transaction, le système comprenant : une plateforme de transaction exécutée par un serveur, sur laquelle des descriptions de transactions peuvent être créées, la plateforme de transaction étant configurée pour, après création d’une transaction, émettre une demande de réalisation de la transaction ; un premier module de sécurité matériel couplé à la plateforme de transaction, configuré pour exécuter des règles de gouvernance relatives à la réalisation de transactions ; un second module de sécurité matériel ; un service de signature configuré pour générer une signature d’une transaction, le service de signature comprenant un premier service de signature exécuté par un dispositif de signature intermédiaire et configuré pour générer une première signature à partir d’une première donnée secrète, et un second service de signature exécuté par le second module de sécurité matériel et configuré pour générer une seconde signature à partir d’une seconde donnée secrète, et une mémoire recevant la seconde donnée secrète, la mémoire étant accessible en lecture et écriture au second module de sécurité matériel et inaccessible au premier module de sécurité matériel. Le premier module de sécurité matériel est configuré pour, en réponse à une demande de réalisation d’une transaction émise par la plateforme de transaction, solliciter l'approbation d’au moins un dispositif approbateur et vérifier si une règle de gouvernance applicable à la transaction demandée est satisfaite, puis, lorsque la règle de gouvernance est satisfaite, transmettre une demande de signature de la transaction au moins au premier service de signature. Le système étant configuré pour fournir, comme signature d’une transaction, une signature multipartite fonction de la première signature et de la seconde signature.
  • Selon un mode de réalisation, le premier module de sécurité matériel, le dispositif de signature intermédiaire et le second module de sécurité matériel sont configurés en sorte que le second module de sécurité matériel ne reçoive jamais la transaction, le second module de sécurité matériel étant configuré pour générer la seconde signature sans avoir connaissance du contenu de la transaction.
  • Selon un mode de réalisation, le second module de sécurité matériel est configuré pour générer la seconde signature à partir de la première signature et de la seconde donnée secrète, la seconde signature formant la signature de la transaction.
  • Selon un mode de réalisation, la première signature et la seconde signature sont complémentaires, le système comprenant un service de diffusion de la transaction sur la blockchain configuré pour combiner la première signature et la seconde signature afin d’obtenir la signature de la transaction.
  • Selon un mode de réalisation, le premier module de sécurité matériel est configuré pour, lorsque la règle de gouvernance est satisfaite, transmettre au moins au dispositif de signature intermédiaire un condensat de la transaction généré par une fonction de hachage, et des données complémentaires permettant au dispositif de signature intermédiaire de générer la première signature à partir de ce condensat.
  • Selon un mode de réalisation, les données complémentaires comprennent un chemin de dérivation déterministe hiérarchique et une fonction de signature à utiliser pour générer la signature ou un identifiant de cette fonction.
  • Selon un mode de réalisation, le premier module de sécurité matériel est agencé dans un premier lieu à accès restreint, et le second module de sécurité matériel est agencé dans un second lieu à accès restreint différent du premier lieu.
  • Selon un mode de réalisation, une règle de gouvernance définit au moins un nombre d'approbations à recevoir de dispositifs approbateurs pour qu’une transaction soit signée et exécutée.
  • Selon un mode de réalisation, le système comprend au moins un dispositif approbateur, le dispositif approbateur comprenant des moyens de calcul cryptographique pour établir un canal de communication sécurisé avec le premier module de sécurité matériel.
  • Selon un mode de réalisation, le premier module de sécurité matériel et le dispositif approbateur sont membres d'une même infrastructure à clé publique comprenant une autorité de certification fournissant ladite clé publique, et dans lequel le dispositif approbateur et le premier module de sécurité matériel sont configurés pour établir entre eux un canal de communication sécurisé en exécutant les étapes suivantes : vérification mutuelle par chaque entité que l'autre entité possède un certificat statique valide au regard de la clé publique de l'infrastructure à clé publique, génération par chaque entité d'un certificat éphémère comprenant une clé publique éphémère signée avec une clé privée de l'entité, vérification mutuelle par chaque entité que le certificat éphémère de l'autre entité est valide au regard de son certificat statique, génération d'une clé de session par échange de clés Diffie-Hellman entre les deux entités, et utilisation de la clé de session pour crypter le canal de communication sécurisé.
  • Selon un mode de réalisation, pour adresser une approbation de transaction au premier module de sécurité matériel, le dispositif approbateur est configuré pour afficher à un utilisateur personne physique une description de la transaction, recueillir l'approbation de l'utilisateur, signer avec une clé privée un challenge ou une donnée comprenant le challenge reçu du premier module de sécurité matériel, puis envoyer la signature obtenue au premier module de sécurité matériel.
  • Des modes de réalisation concernant également un procédé de gestion mutualisée de comptes de cryptoactifs, dans lequel une demande de réalisation d’une transaction sur un compte de cryptoactif ne peut être exécutée qu’après avoir reçu l’accord d’au moins un approbateur et satisfait une règle de gouvernance relative à la réalisation de la transaction. Le procédé est mis en œuvre au moyen d’un système comprenant : une plateforme de transaction exécutée par un serveur, sur laquelle des descriptions de transactions peuvent être créées, la plateforme de transaction étant configurée pour, après création d’une transaction, émettre une demande de réalisation de la transaction ; un premier module de sécurité matériel couplé à la plateforme de transaction, configuré pour exécuter des règles de gouvernance relatives à la réalisation de transactions ; un second module de sécurité matériel ; un service de signature configuré pour générer une signature d’une transaction, le service de signature comprenant un premier service de signature exécuté par un dispositif de signature intermédiaire et configuré pour générer une première signature à partir d’une première donnée secrète, et un second service de signature exécuté par le second module de sécurité matériel et configuré pour générer une seconde signature à partir d’une seconde donnée secrète ; et une mémoire recevant la second donnée secrète, la mémoire étant accessible en lecture et écriture au second module de sécurité matériel et inaccessible au premier module de sécurité matériel. Le procédé comprend les étapes consistant à, en réponse à une demande de réalisation d’une transaction émise par la plateforme de transaction, solliciter, au moyen du premier module de sécurité matériel, l'approbation d’au moins un dispositif approbateur et vérifier si une règle de gouvernance applicable à la transaction demandée est satisfaite ; lorsque la règle de gouvernance est satisfaite, transmettre une demande de signature de la transaction au moins au premier service de signature ; au moyen du premier service de signature, générer la première signature ; au moyen du second service de signature, générer la seconde signature ; et générer une signature multipartite fonction de la première signature et de la seconde signature, la signature multipartite formant la signature de la transaction.
  • Selon un mode de réalisation, le second module de sécurité matériel ne reçoit jamais la transaction, le second module de sécurité matériel étant configuré pour générer la seconde signature à partir de la première signature sans avoir connaissance du contenu de la transaction.
  • Selon un mode de réalisation, la première signature et la seconde signature sont cumulatives, le second module de sécurité matériel étant configuré pour générer la seconde signature à partir de la première signature et de la seconde donnée secrète, la seconde signature formant la signature de la transaction.
  • Selon un mode de réalisation, la première signature et la seconde signature sont complémentaires, le système comprenant une étape consistant à combiner la première signature et la seconde signature afin d’obtenir la signature de la transaction.
  • Selon un mode de réalisation, le procédé comprend l’étape consistant à, au moyen du premier module de sécurité matériel, lorsque la règle de gouvernance est satisfaite, transmettre au moins au dispositif de signature intermédiaire un condensat de la transaction généré par une fonction de hachage, et des données complémentaires permettant de générer la première signature à partir de ce condensat.
  • Selon un mode de réalisation, les données complémentaires comprennent un chemin de dérivation déterministe hiérarchique et une fonction de signature à utiliser pour générer la signature ou un identifiant de cette fonction.
  • Selon un mode de réalisation, le premier module de sécurité matériel est agencé dans un premier lieu à accès restreint, et le second module de sécurité matériel est agencé dans un second lieu à accès restreint différent du premier.
  • Selon un mode de réalisation, une règle de gouvernance autorise la signature d’une transaction en fonction d’un nombre d'approbations à recevoir de dispositifs approbateurs.
    • Description sommaire des dessins
  • Des modes de réalisation d'un procédé et d'un système de gestion mutualisée de comptes de cryptoactifs seront décrits dans ce qui suit à titre non limitatif en relation avec les figures jointes parmi lesquelles :
  • - la précédemment décrite représente schématiquement un système classique de gestion non mutualisée de comptes de cryptoactifs,
  • - la montre un système de gestion mutualisée de comptes de cryptoactifs selon un premier mode de réalisation,
  • - la montre plus en détail le système de la ,
  • - la montre un premier procédé de signature de transaction mis en œuvre dans le système de la ,
  • - la montre un second procédé de signature de transaction mis en œuvre dans le système de la ,
  • - la montre une configuration du système de la lors de la création de règles de gouvernance,
  • - la est un organigramme décrivant des étapes de création de règles de gouvernance,
  • - la montre une configuration du système de la lors d’une cérémonie de clés,
  • - la est un organigramme décrivant des étapes de la cérémonie de clés,
  • - la est un diagramme de séquence décrivant la réalisation d’une transaction au moyen du système de la ,
  • - la est un organigramme décrivant des étapes du diagramme de séquence de la ,
  • - la est un diagramme de séquence décrivant des étapes de création d’un canal sécurisé dans le système de la ,
  • - la est un organigramme décrivant des étapes du diagramme de séquence de la ,
  • - la est un diagramme de séquence décrivant des étapes d’approbation d’une transaction dans le système de la ,
  • - la est un organigramme décrivant des étapes du diagramme de séquence de la ,
  • - la montre un système de gestion mutualisée de comptes de cryptoactifs selon un second mode de réalisation,
  • - la , la , la et la montrent quatre modes de réalisation d’un procédé de signature de transaction mis en œuvre dans le système de la ,
  • - la est un diagramme de séquence décrivant la réalisation d’une transaction au moyen du système de la , et
  • - la est un organigramme décrivant des étapes du diagramme de séquence de la .
    •  Description détaillée
  • La montre l’architecture générale d’un premier mode de réalisation d’un système de transaction à sécurité améliorée pour la gestion mutualisée de comptes de cryptoactifs.
  • Pour au moins un ensemble de comptes de cryptoactifs dérivés d’une clé maître K0, le système est prévu pour être utilisé par un ensemble de participants PAi dans lequel on distingue des copropriétaires des comptes OWNi ("shared-owner"), des administrateurs ADMi, et des opérateurs OPi. Il comprend plateforme de transaction TPF permettant à une pluralité d’opérateurs OPi (OP1… OPN) de réaliser des opérations sur de tels comptes de cryptoactifs, sous réserve de l'accord d’un nombre déterminé d’opérateurs défini par des règles de gouvernance.
  • Les administrateurs définissent les règles de gouvernance. Ils peuvent également, dans un mode de réalisation, approuver, voire désigner des copropriétaires. Les copropriétaires génèrent la clé maître K0 de l’ensemble de comptes de cryptoactifs, à partir de clés maîtres K0i qui leur sont propres. Les opérateurs OPi initient des transactions ou approuvent des transactions initiées par d'autres opérateurs. Chaque participant ADMi, OWNi ou OPi comprend des moyens de calcul cryptographique.
  • Le système représenté comprend avantageusement deux modules de sécurité matérielle HSM1, HSM2. Le premier module de sécurité matérielle HSM1 est couplé à un premier serveur SRV1 et le second module de sécurité matérielle HSM2 est couplé à un second serveur SRV2. Le terme "module de sécurité matérielle" désigne un module du type discuté plus haut, généralement logé dans un datacenter, offrant un haut niveau de sécurité matérielle et logicielle, par exemple conforme à norme FIPS 140-2 de niveau III.
  • Les participants PAi (ADMi, OWNi ou OPi) peuvent se relier au serveur SRV1 via une liaison de données sécurisée https1. Le serveur SRV1 peut se relier au serveur SRV2 via une liaison de données sécurisée https2. Les copropriétaires OWNi peuvent également se relier au serveur SRV2 via les liaisons de données sécurisées https1 et https2, le serveur SRV1 étant de préférence utilisé comme serveur intermédiaire ou serveur proxy pour leur permettre de se relier au module de sécurité HSM2.
  • Il sera noté que bien que des liaisons de type https soient citées à titre d’exemple dans la présente description, ces liaisons de données sécurisées peuvent être de tout autre type connu, par exemple VPN, TLS, etc.
  • Le serveur SRV1 comprend et exécute la plateforme de transaction TPF, ainsi qu’un service de notification NOTIF et un service orchestrateur ORCH. Le module HSM1 comprend et exécute un service de gouvernance GOV. Le serveur SRV2 comprend et exécute un service de liaison LKS permettant d’établir la liaison https2 avec le module HSM2. Le module HSM2 comprend et exécute un service de signature SIGN1. Le module HSM2 comprend et exécute également un service de cérémonie de clés KCER1, permettant d’enregistrer la clé maître K0 dans une mémoire MEM. Enfin, le système comprend un service BCAST de diffusion de transactions signées sur des réseaux de blockchains BCN.
  • Le service BCAST est montré ici à titre non limitatif comme exécuté par le serveur SRV1 mais pourrait aussi être exécuté par le serveur SRV2, comme montré en traits pointillés, ou tout autre serveur ou dispositif associé au système.
  • La mémoire MEM recevant la clé maître K0 peut être interne ou externe au module HSM2. Le système est conçu pour que la mémoire MEM soit inaccessible au module HSM1 et ne puisse être lue et écrite que par le module HSM2. En pratique, les modules HSM1 et HSM2 sont de préférence agencés dans des lieux sécurisés différents, pouvant être très éloignés l’un de l’autre.
  • Trois types d’opérations peuvent être réalisées avec le système : l’enregistrement de règles de gouvernance, la génération de la clé maître K0 au cours d’une cérémonie de clés, et des transactions sur des comptes de cryptoactifs. Le système offre un niveau de sécurité plus élevé que les systèmes classiques grâce à la prévision des deux modules de sécurité matérielle HSM1, HSM2 et la séparation de la fonction de gouvernance - c'est-à-dire la gestion des processus d'approbation de transaction - et de la fonction de signature des transactions.
  • La montre un mode de réalisation plus détaillé du système de la . Chaque participant PAi comprend ici :
  • - un dispositif de sécurité personnel PSDi, associé à un dispositif hôte HDVi exécutant une application compagnon HSW, par exemple l’application "Ledger Live" développée par la demanderesse, et
  • - un utilisateur personne physique USRi, qui peut agir à la fois sur une interface homme-machine du dispositif hôte HDVi ou sur une interface homme-machine du dispositif de sécurité personnel PSDi.
  • Dans un mode de réalisation, le dispositif de sécurité personnel PSDi est un dispositif ayant une architecture de type porte-monnaie matériel de cryptoactifs et comprenant un élément sécurisé en circuit intégré associé à un microcontrôleur en circuit intégré, le microcontrôleur étant configuré pour permettre à l'élément sécurisé d’établir un canal de communication sécurisé avec le module de sécurité matérielle HSM1 par l’intermédiaire du dispositif hôte HDVi exécutant l’application compagnon HSW. Un tel dispositif de sécurité est par exemple le dispositif commercialisé par la demanderesse sous l’appellation "Ledger BLue", "Nano" ou "Stax", ou un dispositif équivalent.
  • Dans un autre mode de réalisation, le dispositif de sécurité personnel PSDi et le dispositif hôte HDVi ne forment qu’un seul dispositif, par exemple un téléphone dit « blockchain », comprenant un portefeuille matériel intégré réalisé à partir d'un élément sécurisé en circuit intégré ou à partir d'un environnement d'exécution de confiance TEE qui émule un élément sécurisé. Un tel téléphone exécute une application sécurisée qui assure la conduite des étapes décrites dans ce qui suit.
  • Dans d'autres modes de réalisation, les dispositifs participants PAi peuvent être des dispositifs informatiques portatifs ou non qui se relient au serveur SRV1 par l'intermédiaire d'une interface de programmation d'application ("API").
  • Ces différents types de dispositifs participants peuvent naturellement coexister dans le système présentement décrit.
  • Dans un mode de réalisation, les dispositifs de sécurité personnels PSDi, le module HSM1 et le module HSM2 sont membres d’une infrastructure à clé publique PA gérée par une autorité de certification CA fournissant une clé publique PA. Ils comprennent chacun une clé privée, respectivement dPi, dH1, dH2, une clé publique statique, respectivement PPi, PH1, PH2, et un certificat, respectivement CPi, CH1, CH2. Ce certificat est fourni par l’autorité de certification CA et comprend leur clé publique et une signature de celle-ci produite par l’autorité de certification au moyen de sa clé privée dA.
  • Grâce à ces certificats dont la validité peut être vérifiée au moyen de la clé publique PA de l’autorité de confiance, chaque dispositif PSDi peut établir un canal de communication sécurisé SC1i avec le module HSM1. Le module HSM1 peut établir un canal de communication sécurisé SC2 avec le module HSM2. Chaque dispositif PSDi peut également établir un canal de communication sécurisé SC3i avec le module HSM2. Le canal de communication sécurisé SC1i entre un PSDi et le module HSM1 est établi ici à travers la liaison de données sécurisée https1. Le canal de communication sécurisé SC3i entre un PSDi et le module HSM1 est établi ici à travers la liaison de données sécurisée https1 et la liaison de données sécurisée https2. Le canal de communication sécurisé SC2 entre les modules HSM1 et HSM2 est établi ici à travers la liaison de données sécurisée https2.
  • Les figures 4A, 4B illustrent deux modes de réalisation d’un procédé de signature de transaction mis en œuvre au moyen du système de la . Sur la , le module HSM1, après avoir reçu un descriptif de la transaction et vérifié que la règle de gouvernance associée est satisfaite, transmet la transaction T au module HSM2, généralement sous une forme brute appelée « transaction brute » (« raw transaction »)
  • À titre d'exemple, le descriptif d'une transaction concernant l'Ethereum peut prendre la forme suivante :
  • {
  • "coin": "eth"
  • "addr": "0x388c818ca8b9251b393131c08a736a67ccbl9297",
  • "sender": "0x473780deaf4a2ac070bbba936b0cdefe7f267dfc",
  • "amount": "0.000567202182620675",
  • "maxGas": "0.00000005"
  • }
  • La transaction selon l'exemple ci-dessus, lorsqu'elle est transformée en transaction brute, peut par exemple avoir la valeur suivante (en hexadécimal) :
  • f86e826f4a8505f901eadd826b6c94388c818ca8b9251b393131c08a736a67ccbl92978801167140fda3d0818025a0dcbal464c58f31892bd0ae8e6271f838189cd344d98e928f3194efe4bce9ebc6a04fOfc71bee74ala6fafbel7cde3c35981c93b58703856ef5dd53884albl53773
  • Le module HSM2, au moyen de son service de signature SIGN1, signe ensuite la transaction brute T à l'aide d'une clé privée du compte de cryptoactif concerné, dérivée de la clé maître K0 détenue dans la mémoire MEM, et produit une signature SIG1(T, K0) fonction de la transaction brute T et du secret K0. Chaque algorithme de signature est spécifique à la blockchain BCN considérée. À titre d'exemple, les deux principales chaînes de blocs (Ethereum et Bitcoin) utilisent comme moyen de signature l'algorithme ECDSA/secp256k1/SHA256, soit une signature générée avec l’algorithme ECDSA (Algorithme de signature numérique à courbe elliptique) configuré avec le paramètre secp256k1, incluant un hachage préalable de la transaction brute au moyen de la fonction SHA-256 (Secure Hash Algorithm) pour obtenir le « hashcode » ou condensat de la transaction. Cet algorithme produit des signatures du type suivant :
  • {
  • "r"
  • "0xb91467e570a6466aa9e9876cbcd013baba02900b8979d43fe208a4a4f339f5fd",
  • "s" :
  • "0x60 07e7 4cd82e037b8 0018 6422fc2dal67c7 4 7ef04 5e5dl8a5f5d4 300f8ela02 9" ,
  • "v": 28
  • }
  • La transaction T et sa signature SIG1 sont ensuite transmises au service de diffusion BCAST pour qu’il diffuse la transaction sur la blockchain BCN concernée. Dans ce mode de réalisation, le module HSM2 a connaissance de la transaction puisqu’elle lui a été communiquée pour génération de la signature SIG1. Le service de diffusion BCAST peut donc être exécuté par le serveur SRV2 couplé au module HSM2, comme montré en traits pointillés sur la , et recevoir la transaction T du module HSM2. Il peut également être exécuté par le serveur SRV1 couplé au module HSM1. Dans ce cas, la signature SIGN1 est communiquée au module HSM1 par le module HSM2. Dans ce procédé, les liaisons de données entre les modules HSM1 et HSM2 se font à travers des canaux de communications sécurisés, dont des exemples de réalisation seront décrits plus loin.
  • Le mode de réalisation de la se distingue de celui de la en ce que le module HSM1 ne communique pas la transaction brute T au module HSM2, mais le condensat ou « hashcode » HT de celle-ci ou d’une partie de celle-ci, produit par une fonction de hachage, par exemple la fonction SHA-256. En d’autres termes, la première étape de production de la signature, à savoir le calcul de son condensat, est réalisé par le module HSM1. Dans ce cas le module HSM1 transmet également au module HSM2 des informations qui lui sont nécessaires pour générer la signature de la transaction, tel que le chemin de dérivation DRV applicable (chemin de dérivation déterministe hiérarchique) et la fonction de signature ECDSA ou un identifiant de celle-ci (le module HSM2 ayant généralement en mémoire un catalogue de fonctions pouvant être nécessaires pour générer des signatures). Ensuite, la transaction T et sa signature SIG1 sont comme précédemment transmises au service de diffusion BCAST pour qu’il diffuse la transaction sur la blockchain BCN.
  • Dans ce mode de réalisation, le module HSM2 n’a pas, à ce stade, connaissance de la transaction T puisqu’elle ne lui a pas été communiquée pour la génération de la signature SIG1. Il peut donc être décidé, pour augmenter la sécurité du système, de faire en sorte que la transaction ne lui soit jamais communiquée, puisqu’il n’en a pas besoin, et qu’elle ne soit également jamais communiquée au serveur SRV2 couplé au module HSM2. Ainsi, le service de signature ne peut que communiquer la signature SIG1 au service de diffusion BCAST. La transaction T est alors communiquée au service BCAST par le module HSM1. Dans ce cas, le service de diffusion BCAST ne peut pas être exécuté par le serveur SRV2, et est exécuté par le serveur SRV1, comme montré en traits continus sur la , puisque celui-ci a connaissance de la transaction T.
  • En résumé, l’architecture de système de gestion mutualisée de transaction qui vient d’être proposée comprend deux modules de sécurité matérielle distincts, le premier pour appliquer des règles de gouvernance et autoriser la signature de transactions lorsque les règles de gouvernance sont satisfaites, le second pour signer les transactions. Selon le mode de réalisation de la , le module de sécurité matérielle qui autorise la signature de transactions ne peut pas les signer lui-même car il ne possède pas le secret K0 permettant de les signer, et le module de sécurité matérielle qui signe les transactions n’a pas connaissance de celles-ci.
  • La montre la configuration du système de la lors de la mise en œuvre d'un procédé d'enregistrement de règles de gouvernance. Le serveur SRV2 et le module HSM2 n'interviennent pas dans ce processus et ne sont pas représentés. L'organigramme de la décrit un mode de réalisation de ce procédé. A une étape G1, un administrateur ADMi se connecte au service ORCH du serveur SRV1 et sollicite la configuration du service de gouvernance GOV. A une étape G2, un canal de communication sécurisé SC1i est créé entre le module HSM1 et le dispositif de sécurité personnel PSDi de l'administrateur ADMi, et le dispositif de sécurité personnel PSDi se connecte au service de gouvernance GOV. A une étape G3, l'administrateur définit une ou plusieurs règles de gouvernance. A une étape G4, le dispositif de sécurité personnel PSDi de l'administrateur adresse les règles de gouvernance souhaitées au service de gouvernance via le canal SC1i. A une étape G5, le service de gouvernance demande au service de notification NOTIF du serveur SRV1 d'envoyer aux autres administrateurs ADMi une notification de vote des règles de gouvernance. A une étape G6, des canaux de communication sécurisés SC1i sont établis entre les modules de sécurité personnels PSDi des autres administrateurs ADMi et le service de gouvernance. A une étape G7, les dispositifs de sécurité personnels PSDi des autres administrateurs communiquent au service de gouvernance leur accord ou leur refus de chaque règle proposée. A une étape G8, les règles sont adoptées en tout ou en partie, en fonction du vote des administrateurs.
  • Les règles de gouvernance peuvent être définies et adoptées selon divers procédés autres que celui qui vient d'être décrit. Des règles d'adoption définissant un quorum et une règle de majorité pour l'adoption de règles de gouvernance peuvent être inscrites "en dur" dans le service de gouvernance. Les règles de gouvernance peuvent être simples, complexes, uniques ou multiples. Elles peuvent par exemple définir un nombre minimal d'opérateurs non identifiés devant approuver une transaction par type de cryptoactif concerné et/ou en fonction du montant de la transaction, ou définir nommément les opérateurs qui peuvent approuver une transaction par type de cryptoactif concerné et/ou en fonction du montant de la transaction. Elles peuvent également définir les opérateurs autorisés à créer une transaction sur la plateforme TPF pour tel ou tel type de cryptoactif, et ceux qui ne sont pas autorisés et ne peuvent qu'être approbateurs de transactions.
  • Dans un mode de réalisation, la sollicitation puis la collecte, par le service de gouvernance, d'une approbation d'une règle de gouvernance émise par un administrateur comprend les étapes suivantes :
  • - le service de gouvernance envoie un challenge aléatoire et le descriptif de la règle de gouvernance aux autres dispositifs de sécurité PSDi des administrateurs concernés,
  • - chaque dispositif de sécurité PSDi de chaque administrateur affiche ensuite à l'utilisateur administrateur correspondant USRi la description de la règle de gouvernance, recueille l'approbation de l'utilisateur, puis signe le challenge avec sa clé privée dPi, en envoie le challenge signé au service de gouvernance,
  • - le service de gouvernance vérifie la validité de la signature, la règle de gouvernance étant réputée approuvée par l'administrateur concerné si la signature est valide.
  • La montre une configuration du système de la lors d’une cérémonie de clés. L'organigramme de la décrit des étapes d'un mode de réalisation de cette cérémonie de clés. A une étape K1, un copropriétaire OWNi se connecte au service orchestrateur ORCH du serveur SRV1. A une étape K2, le copropriétaire OWNi active le service de cérémonie de clés KCER1 via le service orchestrateur. A une étape K3, le service de notification NOTIF du serveur SRV1 envoie à chaque autre copropriétaire OWNi une notification d'invitation à la cérémonie. A une étape K4, des canaux de communications sécurisés SC3i sont établis entre le dispositif de sécurité personnel PSDi de chaque copropriétaire OWNi et le service de cérémonie de clés KCER1. A une étape K5, le service KCER1 reçoit la clé maître K0i ou une partie de la clé maître de chaque dispositif PSDi. A une étape K6 le service KCER1 génère la clé privée K0 à partir des clés maîtres ou des parties de clés maîtres reçues, et la stocke dans la mémoire MEM.
  • Dans un mode de réalisation, des fragments des clés maîtres sont générés au moyen d'une fonction de dérivation BIP32 m/code1'/key dans laquelle
  • "m" est la clé maître
  • "/" : indique la séparation entre les niveaux de dérivation
  • "code1'" est un code spécifique du procédé, pouvant être arbitraire,
  • "key" indique la clé de niveau suivant, dérivée de la clé parente.
  • La clé maître K0 est ensuite obtenue en calculant le OU EXCLUSIF de tous les fragments dérivés des clés maîtres des dispositifs PSDi des copropriétaires OWNi. Les clés des comptes de cryptoactif sont ensuite dérivées de cette clé. Par exemple la clé privée étendue ou clé maître xprv d'un compte Bitcoin est générée classique en appliquant à la clé K0 l'algorithme de hachage HMAC-SHA512 en utilisant comme clé les termes "Bitcoin Seed" et comme message les termes "master seed".
  • La décrit la réalisation d’une transaction au moyen du système de la et la décrit des étapes montrées par la . Dans ce qui suit, des opérateurs sollicités pour l'approbation de la transaction seront appelés "approbateurs APi" pour les distinguer de l'opérateur OPi à l'origine de la demande de transaction, ou opérateur créateur.
  • A une étape S1, un opérateur OPi se connecte à la plateforme de transaction TPF. A une étape S2, l’opérateur crée la description de la transaction. A une étape S3, la plateforme TPF envoie au service de gouvernance GOV une demande de transaction comprenant la description de la transaction. A une étape S4, le service de gouvernance génère une demande d’approbation de la transaction à l’attention d’approbateurs APi qui sont désignés par la règle de gouvernance applicable comme aptes à approuver la demande de transaction. Un exemple de réalisation d’une telle demande d’approbation, à partir d’un challenge aléatoire, sera décrit plus loin.
  • A une étape S5, le service de gouvernance informe le service de notification NOTIF qu'une transaction est demandée. A une étape S6, le service de notification envoie une notification de transaction à tous les opérateurs approbateurs APi concernés, désignés par la règle de gouvernance applicable. A une étape S7, le dispositif de sécurité personnel PSDi de chaque approbateur APi crée un canal sécurisé SC1i avec le service de gouvernance ( ). A une étape S8, le service de gouvernance envoie à chaque dispositif de sécurité personnel PSDi de chaque approbateur APi la description de la transaction et la demande d'approbation. A une étape S9, chaque approbateur APi examine et approuve la transaction. Il s'agit ici de l'utilisateur USRi personne physique qui vérifie la transaction telle qu'affichée par le dispositif de sécurité personnel PSDi. Cette étape met en œuvre un principe de sécurité connu appelé "WYSIWYS", qui signifie "vous ne signez que ce que vous voyez" ("What-You-See-Is-What-You-Sign"). A une étape S10, chaque approbateur APi confirme son approbation à son dispositif de sécurité personnel PSDi. Il s'agit toujours ici de la personne physique qui agit sur l'interface homme-machine de son dispositif de sécurité personnel pour lui confirmer son approbation. A une étape S11, le dispositif de sécurité personnel PSDi de chaque approbateur génère une approbation de la transaction. A une étape S12, le dispositif de sécurité personnel de chaque approbateur envoie son approbation de la transaction au service de gouvernance GOV. Comme montré sur la au moyen d'un cadre portant le libellé "SC1i", les transmissions de données entre le service de gouvernance et chaque dispositif PSDi au cours des étapes S8 et S12 sont réalisées au moyen du canal sécurisé SC1i. A une étape S13, le service de gouvernance GOV vérifie l'approbation de la transaction reçue de chaque dispositif PSDi.
  • Si les conditions d'approbation de la transaction sont réunies, notamment si le quorum d'approbateurs requis est atteint, le système exécute des étapes figurant dans un cadre "QR" qui signifie "Quorum atteint" ("Quorum Reached"), sinon le système exécute des étapes figurant dans un cadre "QNR" qui signifie "Quorum non atteint" (Quorum Not Reached"). On décrira en premier lieu des étapes figurant dans le cadre QR.
  • A une étape S20, le service de gouvernance génère une transaction brute ("raw transaction") à partir de la description de la transaction. Ce calcul de la transaction brute montré ici comme réalisé par le service de gouvernance peut toutefois être confié au serveur SRV1 ou à tout service externe approprié.
  • Une fois la transaction brute générée, le service de gouvernance crée à une étape S30 le canal de communication sécurisé SC2 avec le service de signature SIGN1 exécuté par le module HSM2, via la liaison https2.
  • A une étape S31, le service de gouvernance envoie au service de signature SIGN1 la transaction brute T (mode de réalisation de la ), ou lui envoie le condensat HT de la transaction brute accompagné du chemin de dérivation DRV et de l’identifiant IDF de la fonction de signature (mode de réalisation de la ). La transmission de ces données peut être accompagnée d’une demande de signature, qui peut être implicite ou prendre la forme d’une commande. A une étape S32, le service de signature SIGN1 signe la transaction brute.
  • A une étape S33, la transaction T et sa signature SIG1 sont envoyées au service de diffusion BCAST. La transaction T est fournie par le service de signature SIGN1 en même temps que sa signature SIG1 si le service de signature a connaissance de la transaction (mode de réalisation de la ). Si le service de signature n’a pas connaissance de la transaction T (mode de réalisation de la ), celle-ci est communiquée par le service de gouvernance GOV du module HSM1 au cours d’une étape S33’. A une étape S34, le service BCAST place la transaction signée sur la blockchain BCN concernée.
  • Dans le cas où les conditions d'approbation prévues par la règle de gouvernance applicable ne seraient pas satisfaites (cadre QNR), le service de gouvernance efface la transaction de sa mémoire à une étape S50. A une étape S51, il envoie au service de notification NOTIF une information d'échec de l'approbation de la transaction. A une étape S52, le service de notification envoie des notifications d'échec à la plateforme de transaction, au créateur et aux approbateurs.
  • La décrit des étapes de création d’un canal sécurisé entre deux entités du système de la . La décrit des étapes du diagramme de séquence de la . Les deux entités sont désignées X et Y. Si l'entité X est un dispositif de sécurité personnel PSDi, l'entité Y peut être le module HSM1 (service de gouvernance GOV) pour la création du canal SC1i, ou le module HSM2 (service de signature ou de cérémonie de clés) pour la création du canal SC3i. L'entité X peut aussi être le module HSM1 et l'entité Y être le module HSM2 pour la création du canal SC2.
  • Chaque entité X, Y possède une clé privée dX, dY, une clé publique PX, PY, et un certificat CX, CY comprenant sa clé publique et une signature de celle-ci au moyen de la clé privée dA de l'autorité de certification CA :
  • CX = [PX, sign(PX, dA)]
  • CY = [PY, sign(PY, dA)]
  • A une étape S60, l'entité X génère une paire de clés éphémères privée et publique deX, PeX. A une étape S61, l'entité X génère un certificat éphémère CeX comprenant sa clé publique éphémère PeX et une signature de celle-ci avec sa clé privée dX :
  • CeX = [PeX, sign(PeX, dX)]
  • A une étape S62, l'entité X envoie à l'entité Y sa clé publique éphémère PeX, le certificat éphémère CeX , sa clé publique PX et son certificat CX. A une étape S63, l'entité Y vérifie la chaîne de certification de l'entité X :
  • PA → CX(PX) → CeX(PeX)
  • En effet, la clé publique PA de l'autorité de certification lui permet de vérifier la validité de la signature de la clé publique PX figurant dans le certificat CX, puis la clé publique vérifiée PX lui permet de vérifier la validité de la signature de la clé publique éphémère PeX figurant dans le certificat éphémère.
  • Si la vérification est concluante, à une étape S64 l'entité Y génère une paire de clés éphémères privée et publique deY, PeY. A une étape S65, l'entité Y génère un certificat éphémère CeY comprenant sa clé publique éphémère PeY et une signature de celle-ci avec sa clé privée dY :
  • CeY = [PeY, sign(PeY, dY)]
  • A une étape S66, l'entité Y génère une clé de session éphémère k à partir de sa clé privée éphémère deY et de la clé publique éphémère PeX de l'entité X, au moyen d'une fonction d'échange de clés telle que par exemple la fonction ECDH (échange de clé Diffie Hellman basée sur les courbes elliptiques ou "Elliptic Curve Diffie–Hellman"), soit :
  • k = ECDH(deY , PeX)
  • A une étape S67, l'entité Y envoie à l'entité X sa clé publique éphémère PeY ainsi que, sous une forme cryptée au moyen de la clé k, son certificat éphémère CeY et son certificat CY contenant sa clé publique PY :
  • PeY, {CeY , CY}k
  • A une étape S68, l'entité X génère elle-même la clé de session k à partir de sa clé privée éphémère deX et de la clé publique éphémère PeY de l'entité Y, au moyen de la même fonction que celle utilisée par l'entité Y, ici la fonction ECDH :
  • k = ECDH(deX , PeY)
  • A une étape S69, l'entité X est donc en mesure de décrypter le message {CeY, CY}k.
  • A une étape S70, l'entité X vérifie la chaîne de certification de l'entité Y :
  • PA → CY(PY) → CeY(PeY)
  • En d'autres termes, et comme précédemment, la clé publique PA de l'autorité de certification lui permet de vérifier la validité de la signature de la clé publique PY figurant dans le certificat CX, puis la clé publique certifiée PY lui permet de vérifier la validité de la signature de la clé publique éphémère PeY figurant dans le certificat éphémère.
  • A une étape S71, les deux entités se sont authentifiées mutuellement comme appartenant à la même infrastructure à clé publique. La clé de session éphémère k qu'elles ont communément générée n'est pas rejouable et n'est pas non plus susceptible d'une attaque de l'homme du milieu. Elle peut donc être utilisée en toute sécurité pour crypter les messages échangés.
  • Bien que l'on ait décrit ici une méthode avantageuse de création de canaux sécurisés à base d'un échange de clé Diffie-Hellman, diverses autres méthodes pourraient être prévues par l'homme de l'art pour former les canaux sécurisés SC1i, SC3i et SC2, notamment des techniques à base de cryptographie symétrique utilisant des clés privées enregistrées dans les modules HSM1, HSM2.
  • La décrit un mode de réalisation d'un procédé d’approbation d’une transaction par un approbateur APi, et montre les étapes S4, S7 à S13 de la , plus des étapes S100 et S101 intervenant en cas de non-approbation de la transaction par l'opérateur. La décrit les étapes de la selon ce mode de réalisation.
  • À l'étape S4, le service de gouvernance GOV génère un challenge C pour l'approbation de la transaction :
  • C = RandomBytes(32)
  • "RandomBytes(32)" étant une fonction connue qui génère une chaîne de 32 octets (256 bits) de données aléatoires.
  • À l'étape S7, le service de gouvernance crée le canal sécurisé SC1i avec le dispositif personnel de sécurité PSDi de l'approbateur APi. À l'étape S8, le service de gouvernance envoie la description de la transaction et le challenge C au dispositif PSDi. À l'étape S9, l'approbateur APi examine et approuve la transaction. Comme précisé plus haut, il s'agit ici de l'utilisateur USRi personne physique qui vérifie la transaction. À l'étape S10, si l'approbateur personne physique a approuvé la transaction, il confirme son approbation au dispositif de sécurité personnel PSDi par une action sur celui-ci (cadre "Approve" sur la ). À l'étape S11, le dispositif PSDi signe le challenge C avec sa clé privée dPi :
  • S = Sign(dPi, C)
  • Dans une variante, la description de la transaction pourrait être concaténée avec le challenge, ou toute autre donnée :
  • S = Sign(dPi, C ||T)
  • À l'étape S12 le dispositif PSDi envoie le challenge signé au service de gouvernance. À l'étape S13, le service de gouvernance vérifie la signature S du challenge. Si l'approbateur personne physique, à une étape S100, indique au dispositif PSDi qu'il refuse la transaction, le dispositif renvoie un message d'erreur au service de gouvernance au cours d'une étape S101.
  • La montre l’architecture d’un second mode de réalisation d’un système de transaction pour la gestion mutualisée de comptes de cryptoactifs. Le système se distingue de celui de la en ce qu’il met en œuvre un algorithme de signature multipartite, également appelé algorithme de signature MPC (« Multi-Party Computation »), par lequel une signature est générée par au moins deux parties. Ainsi, en sus du second module de sécurité matérielle HSM2 couplé au serveur SRV2, le système comprend au moins ’un dispositif de signature supplémentaire SIGNDV.
  • Le dispositif SIGNDV est un dispositif sécurisé, par exemple de type HSM, ou un dispositif de type PSD, accessible via un service de liaison LKS’ exécuté par un dispositif DV3. Le dispositif DV3 est par exemple un serveur si le dispositif SIGNDV est de type HSM ou un dispositif hôte si le dispositif SIGNDV est de type PSD. Le service de liaison LKS’ permet d’établir une liaison de données sécurisée https3 entre le dispositif SIGNDV et le serveur SRV1. Cette liaison permet par ailleurs aux dispositifs de sécurité personnels PSDi des opérateurs OPi d’établir avec le module HSM2 un canal de communication sécurisé SC4i via les liaisons https1 et https3. À cet effet, le dispositif SIGNDV est ici membre de l’infrastructure à clé publique PA et comprend une clé privée dD, une clé publique PD et un certificat CD.
  • Le dispositif SIGNDV comprend et exécute un service de signature MSIGN1 utilisant une part (« share ») SH1 de signature MPC qui est stockée dans une mémoire MEM1. De même, le module HSM2 comprend et exécute un service de signature MSIGN2 qui remplace le service SIGN1 précédemment décrit et utilise une part SH2 de signature stockée dans une mémoire MEM2. Le module HSM1 n'a accès à aucune des mémoires MEM1, MEM2. Le module HSM2 n'a pas accès à la mémoire MEM1 du dispositif SIGNDV et le dispositif SIGNDV n'a pas accès à la mémoire MEM2 du module HSM2.
  • Chaque part SH1, SH2 est de façon classique une partie d’un secret partagé et est générée au cours d’une cérémonie de clés au cours de laquelle les services MSIGN1 et MSIGN2 échangent des informations via des canaux sécurisés. Dans certains modes de réalisation, la cérémonie de clés peut inclure une étape de tirage d’un nombre aléatoire permettant de générer les parts SH1, SH2. Dans d’autres modes de réalisation, des copropriétaires OWNi peuvent participer à la cérémonie de clés afin que les clés maîtres K0i de leurs dispositifs PSDi respectifs soient utilisées pour générer les parts SH1, SH2.
  • Les figures 16A, 16B, 16C et 16D illustrent plusieurs modes de réalisation d’un procédé de signature MPC mis en œuvre par le système de la . Dans les modes de réalisation illustrés sur les figures 16A et 16B, la signature MPC d’une transaction est produite par accumulation, le service de signature MSIGN2 fournissant une signature SIG2 qui est fonction d’une signature SIG1 fournie par le service de signature MSIGN1 et qui constitue la signature de la transaction. Dans les modes de réalisation illustrés sur les figures 16A et 16B, la signature MPC d’une transaction est produite par combinaison, le service de signature MSIGN1 fournissant une signature partielle SIG1 et le service de signature MSIGN2 fournissant une signature partielle SIG2. Les deux signatures partielles sont combinées au moyen d’une fonction de combinaison Fmpc pour obtenir la signature de la transaction. Cette fonction de combinaison peut être exécutée par le service de diffusion BCAST ou tout autre service pouvant être prévu en amont du service BCAST pour la préparation des transactions signées devant être diffusées.
  • Dans le mode de réalisation de la , le module HSM1 fournit la transaction T au service de signature MSIGN1 du dispositif SIGNDV, et ce dernier fournit au module HSM2 la signature SIG1 qui est fonction de la transaction et de la part SH1. Le service de signature MSIGN1 fournit la transaction T et la signature SIG1 au service de signature MSIGN2, et ce dernier fournit au service de diffusion BCAST la signature SIG2 qui est fonction de la transaction T, de la signature SIG1 et de la part SH2. Alternativement, la transaction T peut être fournie au service MSIGN2 par le module HSM1. Le service BCAST reçoit la transaction du service MSIGN2 mais pourrait aussi la recevoir directement du module HSM1.
  • Dans ce mode de réalisation où la transaction T est connue des différentes parties du système, le service de diffusion BCAST peut être exécuté par le serveur SRV1 couplé au module HSM1, comme illustré en traits pleins sur la , ou encore par le serveur SRV2 couplé au module HSM2 ou par le dispositif DV3 couplé au dispositif de signature SIGNDV, comme illustré en traits pointillés sur la .
  • Dans le mode de réalisation de la , le module HSM1 fournit au service de signature MSIGN1 le condensat HT de la transaction, le chemin de dérivation DRV approprié et l’identifiant IDF de la fonction de signature appropriée (ou la fonction de signature elle-même). Le service de signature MSIGN1 fournit au module HSM2 la signature SIG1 qui est fonction du condensat HT et de la part SH1. Le service de signature MSIGN1 fournit le condensat HT, le chemin de dérivation DRV, l’identifiant IDF et la signature SIG1 au service de signature MSIGN2, qui fournit au service de diffusion BCAST la signature SIG2 qui est fonction du condensat HT, de la signature SIG1 et de la part SH2. Alternativement, le condensat HT, le chemin de dérivation DRV, l’identifiant IDF peuvent être fournis au service MSIGN2 par le module HSM1. Le service BCAST reçoit ici la transaction du module HSM1, le service MSIGN2 ne le connaissant pas.
  • Dans ce mode de réalisation où la transaction T n’est pas connue des deux services de signature MSIGN1, MSIGN2, le service de diffusion BCAST peut être exécuté par le serveur SRV1 couplé au module HSM1. On obtient ainsi comme précédemment une architecture de système dans laquelle le module de sécurité matérielle qui autorise la signature de transactions ne peut pas les signer lui-même car il ne possède pas les secrets SH1, SH2 permettant de les signer, et les services de signature qui signent les transactions n’ont pas connaissance de celles-ci.
  • Dans le mode de réalisation de la , le module HSM1 fournit la transaction T au service de signature MSIGN1 du dispositif SIGNDV et au service de signature MSIGN2 du module HSM2. Le service de signature MSIGN1 fournit au service de diffusion BCAST une signature partielle SIG1 qui est fonction de la transaction et de la part SH1. Le service de signature MSIGN2 fournit au service de diffusion BCAST une signature partielle SIG2 qui est fonction de la transaction et de la part SH2. Le service BCAST combine les deux signatures partielles au moyen de la fonction Fmpc pour obtenir la signature de la transaction. La transaction T peut être fournie au service BCAST par l’un ou l’autre des dispositifs signataires ou par le module HSM1.
  • Dans ce mode de réalisation, bien que la transaction T soit connue des différentes parties du système, aucune des deux parties signataires ne peut signer la transaction si elle n’a pas connaissance de la signature partielle fournie par l’autre partie. On pourra préférer de faire exécuter le service de diffusion BCAST par le serveur SRV1 couplé au module HSM1, comme illustré en traits pleins sur la , plutôt que de le faire exécuter par l’une ou l’autre des deux parties signataires.
  • Dans le mode de réalisation de la , le module HSM1 fournit le condensat HT de la transaction, le chemin de dérivation DRV et l’identifiant IDF de la fonction de signature au service de signature MSIGN1 du dispositif SIGNDV et au service de signature MSIGN2 du module HSM2. Le service de signature MSIGN1 fournit au service de diffusion BCAST une signature partielle SIG1 qui est fonction du condensat HT et de la part SH1. Le service de signature MSIGN2 fournit au service de diffusion BCAST une signature partielle SIG2 qui est fonction du condensat HT et de la part SH2. Le service BCAST combine les deux signatures partielles au moyen de la fonction Fmpc pour obtenir la signature de la transaction. La transaction T est fournie ici au service BCAST par le module HSM1.
  • Dans ce mode de réalisation, on pourra faire exécuter le service de diffusion BCAST par le serveur SRV1 couplé au module HSM1, comme illustré en traits pleins sur la , pour obtenir comme précédemment une architecture de système dans laquelle le module de sécurité matérielle qui autorise la signature de transactions ne peut pas les signer lui-même car il ne possède pas les secrets SH1, SH2 permettant de les signer, et les services de signature qui signent les transactions n’ont pas connaissance de celles-ci.
  • La est un diagramme de séquence décrivant la réalisation d’une transaction au moyen du système de la selon l’un des modes de réalisation des figures 16C ou 16D. La décrit des étapes du diagramme de séquence de la . Le procédé de signature tel que montré sur la et décrit par la comprend des étapes identiques à celles du diagramme de la , à savoir les étapes S1 à S20, S50 à S52. Ce procédé se distingue essentiellement du procédé de la en ce que les étapes S30 à S34 de signature de la transaction et de diffusion de celle-ci sont remplacées par des étapes S40 à S46. A l'étape S40, le service de gouvernance GOV crée un canal de communication sécurisé SC2a, via la liaison https3, avec le service de signature MSIGN1, et un canal de communication sécurisé SC2b, via la liaison https2, avec le service de signature MSIGN2. A une étape S41, le service de gouvernance envoie au service de signature MSIGN1, via le canal sécurisé SC2a, la transaction brute T ( ) ou lui envoie son condensat HT, le chemin de dérivation DRV et l’identifiant IDF ( ). Ces données sont éventuellement accompagnées d’une demande de signature (qui peut être implicite ou prendre la forme d’une commande). A une étape S41’, le service de gouvernance envoie au service de signature MSIGN2, via le canal sécurisé SC2b, la transaction brute T ( ) ou lui envoie son condensat HT, le chemin de dérivation DRV et l’identifiant IDF ( ). Ces données sont éventuellement accompagnées d'une demande de signature (qui peut être implicite ou prendre la forme d’une commande).
  • A une étape S42, le service de signature MSIGN1 génère la signature partielle SIG1 au moyen de la part SH1. A une étape S43, le service de signature MSIGN1 envoie la signature partielle SIG1 au service de diffusion BCAST.
  • A une étape S44, le service de signature MSIGN2 génère la signature partielle SIG2 au moyen de la part SH2. A une étape S45, le service de signature MSIGN1 envoie la signature partielle SIG1 au service de diffusion BCAST.
  • À ce stade, le processus est sécurisé par la signature partielle de la transaction de sorte que si la transaction est interceptée et altérée par un attaquant, la signature partielle sera erronée et la signature finale le sera aussi. En effet, ni le module HSM2, ni le dispositif SIGNDV ne peuvent signer la transaction seuls. Pour signer la transaction, il faut les deux signatures.
  • A une étape S46, le service BCAST assemble les signatures partielles SIG1, SIG2 au moyen de la fonction Fmpc pour obtenir la signature de la transaction, puis diffuse la transaction signée sur la blockchain BCN concernée. Si les signatures SIG1, SIG2 ont été générées à partir du condensat HT, les services de signature MSIGN1, MSIGN2 ne peuvent pas communiquer la transaction brute T au service BCAST. Une étape de transmission de la transaction T au module BCAST, par le module HSM1, non représentée sur la , peut alors être prévue (Cf. ).
  • Il apparaîtra clairement à l'homme de l'art que les modes de réalisation qui viennent d'être décrits d’un système de transaction à sécurité améliorée pour la gestion mutualisée de comptes de cryptoactifs, sont susceptibles de diverses variantes. En particulier, un troisième voire un quatrième dispositif de signature partielle pourraient être prévus pour générer une signature multipartite comprenant trois composantes ou plus.
    •

Claims (19)

  1. Système de gestion mutualisée de comptes de cryptoactifs, dans lequel une demande de réalisation d’une transaction sur un compte de cryptoactif ne peut être exécutée qu’après avoir reçu l’accord d’au moins un approbateur et satisfait une règle de gouvernance relative à la réalisation de la transaction, caractérisé en ce qu’il comprend :
    - une plateforme de transaction (TPF) exécutée par un serveur (SRV1), sur laquelle des descriptions de transactions peuvent être créées (S1, S2), la plateforme de transaction étant configurée pour, après création d’une transaction, émettre une demande de réalisation de la transaction,
    - un premier module de sécurité matériel (HSM1) couplé à la plateforme de transaction (TPF), configuré pour exécuter des règles de gouvernance relatives à la réalisation de transactions,
    - un second module de sécurité matériel (HSM2),
    - un service de signature (MSIGN1, MSIGN2) configuré pour générer une signature (SIG1, SIG2) d’une transaction (T), le service de signature comprenant un premier service de signature (MSIGN1) exécuté par un dispositif de signature intermédiaire (SIGNDV) et configuré pour générer une première signature (SIG1) à partir d’une première donnée secrète (SH1), et un second service de signature (MSIGN2) exécuté par le second module de sécurité matériel (HSM2) et configuré pour générer une seconde signature (SIG2) à partir d’une seconde donnée secrète (SH2), et
    une mémoire (MEM2) recevant la seconde donnée secrète (SH2), la mémoire (MEM2) étant accessible en lecture et écriture au second module de sécurité matériel (HSM2) et inaccessible au premier module de sécurité matériel (HSM1),
    le premier module de sécurité matériel (HSM1) étant configuré pour, en réponse à une demande de réalisation d’une transaction émise par la plateforme de transaction, solliciter l'approbation d’au moins un dispositif approbateur (APi) et vérifier si une règle de gouvernance applicable à la transaction demandée est satisfaite, puis, lorsque la règle de gouvernance est satisfaite, transmettre une demande de signature de la transaction au moins au premier service de signature (MSIGN1),
    le système étant configuré (HSM2, BCAST) pour fournir, comme signature d’une transaction, une signature multipartite fonction de la première signature (SIG1) et de la seconde signature (SIG2).
  2. Système selon la revendication 1, dans lequel le premier module de sécurité matériel (HSM1), le dispositif de signature intermédiaire (SIGNDV) et le second module de sécurité matériel (HSM2) sont configurés de sorte que le second module de sécurité matériel (HSM2) ne reçoive jamais la transaction, le second module de sécurité matériel étant configuré pour générer la seconde signature (SIG2) sans avoir connaissance du contenu de la transaction.
  3. Système selon l’une des revendications 1 et 2, dans lequel le second module de sécurité matériel (HSM2) est configuré pour générer la seconde signature à partir de la première signature et de la seconde donnée secrète (SH2), la seconde signature formant la signature de la transaction.
  4. Système selon l’une des revendications 1 et 2, dans lequel la première signature (SIG1) et la seconde signature (SIG2) sont complémentaires, le système comprenant un service (BCAST) de diffusion de la transaction sur la blockchain configuré pour combiner (Fmpc) la première signature et la seconde signature afin d’obtenir la signature de la transaction.
  5. Système selon l’une des revendications 1 à 4, dans lequel le premier module de sécurité matériel (HSM1) est configuré pour, lorsque la règle de gouvernance est satisfaite, transmettre au moins au dispositif de signature intermédiaire (SIGNDV) un condensat (HT) de la transaction (T) généré par une fonction de hachage, et des données complémentaires permettant au dispositif de signature intermédiaire de générer la première signature (SIG1) à partir de ce condensat.
  6. Système selon la revendication 5, dans lequel les données complémentaires comprennent un chemin de dérivation déterministe hiérarchique (DRV) et une fonction de signature à utiliser pour générer la signature ou un identifiant (IDF) de cette fonction.
  7. Système selon l’une des revendications 1 à 6, dans lequel le premier module de sécurité matériel (HSM1) est agencé dans un premier lieu à accès restreint, et le second module de sécurité matériel (HSM2) est agencé dans un second lieu à accès restreint différent du premier lieu.
  8. Système selon l'une des revendications 1 à 7, dans lequel une règle de gouvernance définit au moins un nombre d'approbations à recevoir de dispositifs approbateurs (OPi, APi) pour qu’une transaction soit signée et exécutée.
  9. Système selon l'une des revendications 1 à 8, comprenant au moins un dispositif approbateur (OPi, APi), le dispositif approbateur comprenant des moyens de calcul cryptographique (PSDi) pour établir un canal de communication sécurisé avec le premier module de sécurité matériel.
  10. Système selon la revendication 9, dans lequel le premier module de sécurité matériel (HSM1) et le dispositif approbateur (OPi, APi) sont membres d'une même infrastructure à clé publique (PA) comprenant une autorité de certification (CA) fournissant ladite clé publique, et dans lequel le dispositif approbateur et le premier module de sécurité matériel (HSM) sont configurés pour établir entre eux un canal de communication sécurisé en exécutant les étapes suivantes :
    - vérification mutuelle par chaque entité que l'autre entité possède un certificat statique valide au regard de la clé publique de l'infrastructure à clé publique,
    - génération par chaque entité d'un certificat éphémère comprenant une clé publique éphémère signée avec une clé privée de l'entité,
    - vérification mutuelle par chaque entité que le certificat éphémère de l'autre entité est valide au regard de son certificat statique,
    - génération d'une clé de session (k) par échange de clés Diffie-Hellman entre les deux entités, et utilisation de la clé de session pour crypter le canal de communication sécurisé.
  11. Système selon l'une des revendications 9 et 10, dans lequel pour adresser une approbation de transaction au premier module de sécurité matériel (HSM1), le dispositif approbateur (OPi, APi) est configuré pour afficher à un utilisateur personne physique (USRi) une description de la transaction (S9), recueillir l'approbation de l'utilisateur (S10), signer (S11) avec une clé privée (dPi) un challenge ou une donnée comprenant le challenge reçu du premier module de sécurité matériel (HSM1), puis envoyer (S12) la signature obtenue au premier module de sécurité matériel.
  12. Procédé de gestion mutualisée de comptes de cryptoactifs, dans lequel une demande de réalisation d’une transaction sur un compte de cryptoactif ne peut être exécutée qu’après avoir reçu l’accord d’au moins un approbateur et satisfait une règle de gouvernance relative à la réalisation de la transaction, procédé caractérisé en ce qu’il est mis en œuvre au moyen d’un système comprenant :
    - une plateforme de transaction (TPF) exécutée par un serveur (SRV1), sur laquelle des descriptions de transactions peuvent être créées (S1, S2), la plateforme de transaction étant configurée pour, après création d’une transaction, émettre une demande de réalisation de la transaction,
    - un premier module de sécurité matériel (HSM1) couplé à la plateforme de transaction (TPF), configuré pour exécuter des règles de gouvernance relatives à la réalisation de transactions,
    - un second module de sécurité matériel (HSM2),
    - un service de signature (MSIGN1, MSIGN2) configuré pour générer une signature (SIG1, SIG2) d’une transaction (T), le service de signature comprenant un premier service de signature (MSIGN1) exécuté par un dispositif de signature intermédiaire (SIGNDV) et configuré pour générer une première signature (SIG1) à partir d’une première donnée secrète (SH1), et un second service de signature (MSIGN2) exécuté par le second module de sécurité matériel (HSM2) et configuré pour générer une seconde signature (SIG2) à partir d’une seconde donnée secrète (SH2), et
    - une mémoire (MEM2) recevant la second donnée secrète (SH2), la mémoire (MEM2) étant accessible en lecture et écriture au second module de sécurité matériel (HSM2) et inaccessible au premier module de sécurité matériel (HSM1),et en ce qu’il comprend les étapes consistant à :
    - en réponse à une demande de réalisation d’une transaction émise par la plateforme de transaction, solliciter, au moyen du premier module de sécurité matériel (HSM1), l'approbation d’au moins un dispositif approbateur (APi) et vérifier si une règle de gouvernance applicable à la transaction demandée est satisfaite,
    - lorsque la règle de gouvernance est satisfaite, transmettre une demande de signature de la transaction au moins au premier service de signature (MSIGN1),
    - au moyen du premier service de signature (MSIGN1), générer la première signature (SIG1),
    - au moyen du second service de signature (MSIGN2), générer la seconde signature (SIG2), et
    générer une signature multipartite fonction de la première signature (SIG1) et de la seconde signature (SIG2), la signature multipartite formant la signature de la transaction.
  13. Procédé selon la revendication 12, dans lequel le second module de sécurité matériel (HSM2) ne reçoit jamais la transaction, le second module de sécurité matériel étant configuré pour générer la seconde signature (SIG2) à partir de la première signature (SIG1) sans avoir connaissance du contenu de la transaction.
  14. Procédé selon l’une des revendications 12 et 13, dans lequel la première signature (SIG1) et la seconde signature (SIG2) sont cumulatives, le second module de sécurité matériel (HSM2) étant configuré pour générer la seconde signature à partir de la première signature et de la seconde donnée secrète (SH2), la seconde signature formant la signature de la transaction.
  15. Procédé selon l’une des revendications 12 et 13, dans lequel la première signature (SIG1) et la seconde signature (SIG2) sont complémentaires, le système comprenant une étape consistant à combiner la première signature et la seconde signature afin d’obtenir la signature de la transaction.
  16. Procédé selon l’une des revendications 12 à 15, comprenant l’étape consistant à, au moyen du premier module de sécurité matériel (HSM1), lorsque la règle de gouvernance est satisfaite, transmettre au moins au dispositif de signature intermédiaire (SIGNDV) un condensat (HT) de la transaction (T) généré par une fonction de hachage, et des données complémentaires permettant de générer la première signature (SIG1) à partir de ce condensat.
  17. Procédé selon la revendication 16, dans lequel les données complémentaires comprennent un chemin de dérivation déterministe hiérarchique (DRV) et une fonction de signature à utiliser pour générer la signature ou un identifiant (IDF) de cette fonction.
  18. Procédé selon l’une des revendications 12 à 17, dans lequel le premier module de sécurité matériel (HSM1) est agencé dans un premier lieu à accès restreint, et le second module de sécurité matériel (HSM2) est agencé dans un second lieu à accès restreint différent du premier.
  19. Procédé selon l'une des revendications 12 à 18, dans lequel une règle de gouvernance autorise la signature d’une transaction en fonction d’un nombre d'approbations à recevoir de dispositifs approbateurs (OPi, APi).
EP24730079.1A 2023-05-26 2024-05-24 Système de gestion mutualisée de comptes de cryptoactifs à signature multipartite Pending EP4706201A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR2305259A FR3149104A1 (fr) 2023-05-26 2023-05-26 Système de gestion mutualisée de comptes de cryptoactifs, ayant des modules matériels de gouvernance et de signature distincts
FR2305261A FR3149103A1 (fr) 2023-05-26 2023-05-26 Système de gestion mutualisée de comptes de cryptoactifs à signature multipartite
PCT/IB2024/055084 WO2024246704A1 (fr) 2023-05-26 2024-05-24 Système de gestion mutualisée de comptes de cryptoactifs à signature multipartite

Publications (1)

Publication Number Publication Date
EP4706201A1 true EP4706201A1 (fr) 2026-03-11

Family

ID=91335120

Family Applications (2)

Application Number Title Priority Date Filing Date
EP24730436.3A Pending EP4706202A1 (fr) 2023-05-26 2024-05-24 Système de gestion mutualisée de comptes de cryptoactifs, ayant des modules matériels de gouvernance et de signature distincts
EP24730079.1A Pending EP4706201A1 (fr) 2023-05-26 2024-05-24 Système de gestion mutualisée de comptes de cryptoactifs à signature multipartite

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP24730436.3A Pending EP4706202A1 (fr) 2023-05-26 2024-05-24 Système de gestion mutualisée de comptes de cryptoactifs, ayant des modules matériels de gouvernance et de signature distincts

Country Status (4)

Country Link
EP (2) EP4706202A1 (fr)
KR (2) KR20260017404A (fr)
CN (2) CN121548969A (fr)
WO (2) WO2024246702A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3557511A1 (fr) * 2018-04-17 2019-10-23 Metaco SA Portefeuille de crypto avec contrôle de la politique de sécurité hors chaîne
US12475454B2 (en) 2021-09-21 2025-11-18 International Business Machines Corporation Digital asset platform with HSM verification

Also Published As

Publication number Publication date
WO2024246704A1 (fr) 2024-12-05
CN121359411A (zh) 2026-01-16
KR20260015219A (ko) 2026-02-02
EP4706202A1 (fr) 2026-03-11
KR20260017404A (ko) 2026-02-05
CN121548969A (zh) 2026-02-17
WO2024246702A1 (fr) 2024-12-05

Similar Documents

Publication Publication Date Title
US20260111863A1 (en) System and Process for Providing an NFT Ricardian contract
US11799668B2 (en) Electronic identification verification methods and systems with storage of certification records to a side chain
CN114866323B (zh) 一种用户可控的隐私数据授权共享系统及方法
EP3721578B1 (fr) Procédés et systèmes de récupération de données au moyen de mots de passe dynamiques
EP3506556B1 (fr) Méthode d'échange de clés authentifié par chaine de blocs
EP2441207B1 (fr) Procédé cryptographique d'authentification anonyme et d'identification séparée d'un utilisateur
US20140157393A1 (en) Proxy authentication network
Karbasi et al. A post-quantum end-to-end encryption over smart contract-based blockchain for defeating man-in-the-middle and interception attacks
WO2018145127A1 (fr) Procédés et systèmes de vérification d'une identification électronique avec stockage d'enregistrements de certification sur une chaîne latérale
EP3403213A2 (fr) Procédés et systèmes mis en oeuvre dans une architecture en réseau de noeuds susceptibles de réaliser des transactions basées sur messages
CN112084521B (zh) 用于区块链的非结构化数据处理方法、装置及系统
USRE49968E1 (en) Electronic identification verification methods and systems with storage of certification records to a side chain
WO2022038096A1 (fr) Procédé de connexion à une visioconférence sécurisée par authentification forte
Hernandez-Ardieta et al. An optimistic fair exchange protocol based on signature policies
EP4012972A1 (fr) Méthode de divulgation sélective de données via une chaine de blocs
EP3219077B1 (fr) Procédé et système de gestion d'identités d'utilisateurs destiné à être mis en oeuvre lors d'une communication entre deux navigateurs web
WO2024246704A1 (fr) Système de gestion mutualisée de comptes de cryptoactifs à signature multipartite
FR3149103A1 (fr) Système de gestion mutualisée de comptes de cryptoactifs à signature multipartite
FR3149104A1 (fr) Système de gestion mutualisée de comptes de cryptoactifs, ayant des modules matériels de gouvernance et de signature distincts
FR3144471A1 (fr) Procédé pour établir une liaison de données sécurisée entre un dispositif électronique et un serveur
CN115361135B (zh) 一种用于解决多平台之间相互通信的身份认证系统及方法
WO2025120454A1 (fr) Procédé de gestion centralisée d'au moins un processus d'approbation d'une action
Meister et al. Password-less key recovery via multi-factor multi-party authentication
EP1992104B1 (fr) Authentification d'un dispositif informatique au niveau utilisateur
WO2025133847A1 (fr) Procédé pour lier à l'identité d'une personne la sauvegarde d'un secret

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: 20251203

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