System for the pooled management of multiparty signature cryptoasset accounts

Abstract

The invention relates to a system for the pooled management of cryptoasset accounts, in which a request to perform a transaction in a cryptoasset account can only be executed after having received the agreement of at least one approver and meeting a governance rule. The system comprises a first hardware security module (HSM1) configured to execute governance rules, an intermediate signature device (SIGNDV) and a second hardware security module (HSM2) configured to batch-sign transactions at the request of the first hardware security module (HSM1), the transaction signatures being multiparty signatures based on a first signature (SIG1) provided by the intermediate signature device and on a second signature (SIG2) provided by the second hardware security module (HSM2).

Description

Shared management system for crypto-asset accounts with multi-party signature

[0001] The present invention relates to a system and method for shared management of cryptoasset accounts, in which a request to carry out a transaction on a cryptoasset account can only be executed after receiving the agreement of at least one approver and satisfying a governance rule. Background

[0002] In recent years, the development of cryptocurrencies or other types of cryptoassets managed by blockchain, such as non-fungible tokens ("NFTs") and smart contracts, has given rise to various means of storing and preserving the private and public keys attached to these different types of cryptoassets. This is how cryptoasset wallets, commonly called "wallets", have emerged, allowing the storage and preservation of these keys. A cryptoasset wallet is a hardware or software device whose function is to store the private and public keys attached to cryptoasset accounts, and to sign transactions using these keys.

[0003] The diagram shows an example of a hardware wallet for HW cryptoassets, for example the device marketed by the applicant under the name "Nano" or "Stax", and an HDV host device running an HSW companion application, for example the "Ledger Live" application developed by the applicant. Since the HW device cannot connect directly to the Internet for security reasons, it is associated with the HDV host device to carry out transactions on a BCN blockchain. The HDV host device is for example a computer, a mobile phone, a tablet or the like. The connection between the HW device and the HDV host device may be of the USB or Bluetooth type for example.

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

[0005] Once connected to the host device, the HW device can interact with the companion software to allow a USR user to carry out transactions on the BCN blockchain or on decentralized exchange sites. The HW device can also communicate with a hardware security module (HSM) located in a data center. Such a hardware security module is also called a "transactional black box" (BTN) (https: / fr.wikipedia.org / wiki / Hardware_Security_Module). It is generally the case that the HSM does not store the user's private keys and only ensures the authenticity of the HW device, its commissioning, the updating of its operating system, the downloading of certified application programs, etc.

[0006] An exception to this rule must be made in the case of shared management of cryptoasset accounts, in which a transaction on a cryptoasset account can only be executed after receiving the agreement of at least one approver and satisfying a governance rule. In this case, a hardware security module is provided to execute a transaction governance service and sign the transactions. For this purpose, the hardware security module must hold the master key and / or the private keys of the cryptoasset accounts concerned. When the hardware security module is requested to carry out a transaction, it identifies the governance rule that applies to the requested transaction, then requests the agreement of operators designated by this governance rule. When the agreement of the operators is received, the hardware security module signs the transaction with the appropriate private key and then broadcasts it on the relevant blockchain.

[0007] Thus, in the context of shared management of crypto-asset accounts, the security of these accounts relies on the inviolability of the hardware security module. This module protects private keys, validates authorization processes and generates transaction signatures in accordance with predetermined governance rules.

[0008] Also known, from WO2023046409A1, is a system for approving transactions relating to non-mutualized crypto-asset accounts, in which a hardware wallet sends 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 integration of 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 signing service with the signature of the transaction approved by policy services.

[0009] 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 security features are also implemented.

[0010] It also conducts various research projects to maintain the highest level of security offered by hardware security modules. In 2019, the plaintiff discovered 14 vulnerabilities in an HSM module. Exploitation of these vulnerabilities could have allowed a remote attacker to obtain arbitrary code execution in the HSM and potentially extract all secret keys, without any authentication. This issue was responsibly disclosed and properly patched by HSM vendors, raising the security bar for the entire HSM industry. See: https: / donjon.ledger.com / BlackHat2019-presentation.

[0011] Despite the absence of any known security problem to date that could have led to an attack on shared account keys held by such hardware security modules, the applicant is constantly seeking improvements aimed at increasing the level of security of the systems it develops (Cf. https: / donjon.ledger.com).

[0012] It might therefore be desirable to increase the level of security offered by a shared management system for crypto-asset accounts of the type just described. Summary

[0013] Embodiments relate to a system for shared 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 to the first hardware security module. The first hardware security module is configured to, in response to a request to carry out 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 to at least the first signature service. The system is configured to provide, as a signature for a transaction, a multi-party signature based on the first signature and the second signature.,

[0014] According to one embodiment, 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.

[0015] According to one embodiment, 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.

[0016] According to one embodiment, 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.

[0017] According to one embodiment, 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.

[0018] According to one embodiment, 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.

[0019] According to one embodiment, the first hardware security module is arranged in a first restricted access location, and the second hardware security module is arranged in a second restricted access location different from the first location.

[0020] According to one embodiment, a governance rule defines at least a number of approvals to be received from approving devices for a transaction to be signed and executed.

[0021] According to one embodiment, the system comprises at least one approving device, the approving device comprising cryptographic computing means for establishing a secure communication channel with the first hardware security module.

[0022] According to one embodiment, 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 a secure communication channel between them 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.,

[0023] According to one embodiment, to send a transaction approval to the first hardware security module, 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.

[0024] Embodiments also relate to a method for shared management of cryptoasset accounts, in which a request to carry out a transaction on a cryptoasset account can only be executed after receiving the agreement of at least one approver and satisfying a governance rule relating to the carrying out 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 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, 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 carry out 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 verifying 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.;

[0025] According to one embodiment, 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.

[0026] According to one embodiment, 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.

[0027] According to one embodiment, 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.

[0028] According to one embodiment, 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.

[0029] According to one embodiment, 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.

[0030] According to one embodiment, the first hardware security module is arranged in a first restricted access location, and the second hardware security module is arranged in a second restricted access location different from the first.

[0031] According to one embodiment, a governance rule authorizes the signing of a transaction based on a number of approvals to be received from approving devices. Summary description of the drawings

[0032] Embodiments of a method and system for shared management of cryptoasset accounts will be described in the following without limitation in relation to the attached figures, among which:

[0033] - the previously described schematically represents a classic system for non-mutualized management of crypto-asset accounts,

[0034] - shows a system for shared management of crypto-asset accounts according to a first embodiment,

[0035] - shows the system in more detail,

[0036] - shows a first transaction signature process implemented in the system of the,

[0037] - shows a second transaction signature process implemented in the system of the,

[0038] - shows a system configuration when creating governance rules,

[0039] - is a flowchart describing the steps for creating governance rules,

[0040] - shows a system configuration during a key ceremony,

[0041] - is a flowchart describing the steps of the key ceremony,

[0042] - is a sequence diagram describing the performance of a transaction using the system,

[0043] - is a flowchart describing steps in the sequence diagram of the,

[0044] - is a sequence diagram describing steps in creating a secure channel in the system,

[0045] - is a flowchart describing steps in the sequence diagram of the,

[0046] - is a sequence diagram describing steps for approving a transaction in the system,

[0047] - is a flowchart describing steps in the sequence diagram of the,

[0048] - shows a system for shared management of crypto-asset accounts according to a second embodiment,

[0049] - la, la, laet lashow four embodiments of a transaction signing method implemented in the system of la,

[0050] - is a sequence diagram describing the performance of a transaction using the system, and

[0051] - is a flowchart describing steps in the sequence diagram of the. Detailed description

[0052] Lamontre shows the general architecture of a first embodiment of a security-enhanced transaction system for the shared management of crypto-asset accounts.

[0053] 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 determined number of operators defined by governance rules.

[0054] 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 for the set of cryptoasset accounts, from their own master keys K0i. OPi operators initiate transactions or approve transactions initiated by other operators. Each ADMi, OWNi, or OPi participant includes cryptographic computing resources.

[0055] 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" refers to 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 the FIPS 140-2 level III standard.

[0056] PAi participants (ADMi, OWNi or OPi) can connect to the SRV1 server via a secure https1 data link. The SRV1 server can connect to the SRV2 server via a secure https2 data link. OWNi co-owners can also connect to the SRV2 server via the secure https1 and https2 data links, with the SRV1 server preferably being used as an intermediary or proxy server to allow them to connect to the HSM2 security module.

[0057] It will be noted that although https type connections are cited as examples in this description, these secure data connections can be of any other known type, for example VPN, TLS, etc.

[0058] The SRV1 server includes and runs the TPF transaction platform, as well as a NOTIF notification service and an ORCH orchestrator service. The HSM1 module includes and runs a GOV governance service. The SRV2 server includes and runs a LKS link service to establish the https2 link with the HSM2 module. The HSM2 module includes and runs a SIGN1 signature service. The HSM2 module also includes and runs a KCER1 key ceremony service, to record the master key K0 in a MEM memory. Finally, the system includes a BCAST service for broadcasting signed transactions on BCN blockchain networks.

[0059] The BCAST service is shown here without limitation 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.

[0060] The MEM memory receiving the master key K0 can be internal or external to the HSM2 module. The system is designed so that the MEM memory is inaccessible to the HSM1 module and can only be read and written by the HSM2 module. In practice, the HSM1 and HSM2 modules are preferably arranged in different secure locations, which may be very far from each other.

[0061] Three types of operations can be performed with the system: the registration of governance rules, the generation of the master key K0 during a key ceremony, and transactions on crypto-asset accounts. The system offers a higher level of security than conventional systems thanks to the provision of 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.

[0062] Lamontre shows a more detailed embodiment of the system. Each PAi participant here includes:

[0063] - a PSDi personal security device, associated with an HDVi host device running an HSW companion application, for example the "Ledger Live" application developed by the applicant, and

[0064] - a natural person user USRi, who can act both on a human-machine interface of the HDVi host device or on a human-machine interface of the PSDi personal security device.

[0065] In one embodiment, the personal security device PSDi 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 hardware security module HSM1 via the host device HDVi running the companion application HSW. Such a security device is for example the device marketed by the applicant under the name "Ledger BLue", "Nano" or "Stax", or an equivalent device.

[0066] In another embodiment, the personal security device PSDi and the host device HDVi 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 which emulates a secure element. Such a phone executes a secure application which ensures the conduct of the steps described in the following.

[0067] In other embodiments, the PAi participating devices may be portable or non-portable computing devices that connect to the SRV1 server via an application programming interface ("API").

[0068] These different types of participating devices can naturally coexist in the system described herein.

[0069] In one embodiment, 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.

[0070] Using these certificates, the validity of which can be verified by means of the public key PA of the trusted authority, 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.

[0071] Figures 4A, 4B illustrate two embodiments of a transaction signing method implemented using the system of the. On the, the HSM1 module, after having received a description of the transaction and verified that the associated governance rule is satisfied, transmits the transaction T to the HSM2 module, generally in a raw form called “raw transaction”.

[0072] For example, the description of a transaction concerning Ethereum might take the following form:

[0073] {

[0074] "coin": "eth"

[0075] "addr": "0x388c818ca8b9251b393131c08a736a67ccbl9297",

[0076] "sender": "0x473780deaf4a2ac070bbba936b0cdefe7f267dfc",

[0077] "amount": "0.000567202182620675",

[0078] "maxGas": "0.00000005"

[0079] }

[0080] The transaction according to the example above, when transformed into a raw transaction, can for example have the following value (in hexadecimal):

[0081] f86e826f4a8505f901eadd826b6c94388c818ca8b9251b393131c08a736a67ccbl92978801167140fda3d0818025a0dcbal464c58f31892b d0ae8e6271f838189cd344d98e928f3194efe4bce9ebc6a04fOfc71bee74ala6fafbel7cde3c35981c93b58703856ef5dd53884albl53773

[0082] The HSM2 module, using its signature service SIGN1, then signs the raw transaction T using a private key of the relevant cryptoasset account, derived from the master key K0 held in the MEM memory, and produces a signature SIG1(T, K0) based on the raw transaction T and the secret K0. Each signature algorithm is specific to the BCN blockchain in question. For example, the two main blockchains (Ethereum and Bitcoin) use the ECDSA / secp256k1 / SHA256 algorithm as a means of signature, i.e. a signature generated with the ECDSA algorithm (Elliptic Curve Digital Signature Algorithm) configured with the secp256k1 parameter, including a prior hashing of the raw transaction using the SHA-256 (Secure Hash Algorithm) function to obtain the transaction hashcode or digest. This algorithm produces signatures of the following type:

[0083] {

[0084] "r"

[0085] <h2 style=";text-align:left;direction:ltr">"0xb91467e570a6466aa9e9876cbcd013baba02900b8979d43fe208a4a4f339f5fd",<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr">

[0086] <h2 style=";text-align:left;direction:ltr"> "s":<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr">

[0087] <h2 style=";text-align:left;direction:ltr"> "0x60 07e7 4cd82e037b8 0018 6422fc2dal67c7 4 7ef04 5e5dl8a5f5d4 300f8ela02 9" ,<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr">

[0088] <h2 style=";text-align:left;direction:ltr"> "v": 28<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr">

[0089] <h2 style=";text-align:left;direction:ltr">}<h2 style=";text-align:left;direction:ltr"> <h2 style=";text-align:left;direction:ltr">

[0090] The transaction T and its signature SIG1 are then transmitted to the BCAST broadcast service so that it broadcasts the transaction on the relevant BCN blockchain. In this embodiment, 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. In this case, the SIGN1 signature is communicated to the HSM1 module by the HSM2 module. In this method, the data links between the HSM1 and HSM2 modules are made through secure communication channels, examples of which will be described later.

[0091] The embodiment of theis distinguished from that of thein that the HSM1 module does not communicate the raw transaction T to the HSM2 module, but the hash or "hashcode" HT of it or of a part of it, produced by a hash function, for example the SHA-256 function. In other words, the first step in producing the signature, namely the calculation of its hash, is carried out by the HSM1 module. In this case 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).Then, 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.

[0092] In this embodiment, 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, 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. Thus, 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. In this case, 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 has knowledge of the transaction T.

[0093] In summary, the proposed shared transaction management system architecture comprises two separate hardware security modules, the first to apply governance rules and authorize the signing of transactions when the governance rules are satisfied, the second to sign the transactions. According to the embodiment of the, the hardware security module that authorizes the signing of transactions cannot sign them itself because it does not have the K0 secret allowing them to be signed, and the hardware security module that signs the transactions has no knowledge of them.

[0094] La shows the configuration of the system during the implementation of a governance rule registration process. The SRV2 server and the HSM2 module are not involved in this process and are not shown. The flowchart of la describes an embodiment of this process. In a step G1, an ADMi administrator connects to the ORCH service of the SRV1 server and requests the configuration of the GOV governance service. In a step G2, a secure communication channel SC1i is created between the HSM1 module and the ADMi administrator's PSDi personal security device, and the PSDi personal security device connects to the GOV governance service. In a step G3, the administrator defines one or more governance rules. In a step G4, the administrator's PSDi personal security device sends the desired governance rules to the governance service via the SC1i channel.In step G5, the governance service requests the NOTIF notification service of the SRV1 server to send a notification of the governance rule vote to the other ADMi administrators. In step G6, secure SC1i communication channels are established between the PSDi personal security modules of the other ADMi administrators and the governance service. In step G7, the PSDi personal security devices of the other administrators communicate to the governance service their agreement or refusal of each proposed rule. In step G8, the rules are adopted in whole or in part, depending on the administrators' vote.

[0095] Governance rules may be defined and adopted using various processes 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 per type of cryptoasset concerned and / or based on the transaction amount, or specifically define the operators who may approve a transaction per type of cryptoasset concerned and / or based on the transaction amount. 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 may only be transaction approvers.

[0096] In one embodiment, the solicitation and then collection, by the governance service, of an approval of a governance rule issued by an administrator comprises the following steps:

[0097] - the governance service sends a random challenge and the description of the governance rule to the other PSDi security devices of the administrators concerned,

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

[0099] - the governance service checks the validity of the signature, the governance rule being deemed approved by the administrator concerned if the signature is valid.

[0100] La shows a configuration of the system during a key ceremony. The flowchart of la describes steps of an embodiment of this key ceremony. In a step K1, a co-owner OWNi connects to the orchestrator service ORCH of the server SRV1. In a step K2, the co-owner OWNi activates the key ceremony service KCER1 via the orchestrator service. In a step K3, the notification service NOTIF of the server SRV1 sends each other co-owner OWNi a notification of invitation to the ceremony. In a step K4, secure communication channels SC3i are established between the personal security device PSDi of each co-owner OWNi and the key ceremony service KCER1. In a step K5, the service KCER1 receives the master key K0i or a part of the master key of each PSDi device. At step K6 the KCER1 service generates the private key K0 from the master keys or parts of master keys received, and stores it in the MEM memory.

[0101] In one embodiment, fragments of the master keys are generated using a BIP32 derivation function m / code1' / key in which

[0102] "m" is the master key

[0103] " / " : indicates the separation between the derivation levels

[0104] "code1'" is a process-specific code, which can be arbitrary,

[0105] "key" indicates the next level key, derived from the parent key.

[0106] The master key K0 is then obtained by calculating the EXCLUSIVE OR of all fragments derived from the master keys of the PSDi devices of the OWNi co-owners. The keys of the crypto-asset accounts are then derived from this key. For example, 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.

[0107] The describes the completion of a transaction using the system and the describes the steps shown by the. In the following, operators requested for transaction approval will be called "APi approvers" to distinguish them from the OPi operator who initiated the transaction request, or creator operator.

[0108] In step S1, an OPi operator connects to the TPF transaction platform. In step S2, the operator creates the transaction description. In step S3, the TPF platform sends a transaction request including the transaction description to the GOV governance service. In step S4, 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 how such an approval request is made, based on a random challenge, will be described later.

[0109] At step S5, the governance service informs the notification service NOTIF that a transaction is requested. At step S6, the notification service sends a transaction notification to all the relevant APi approver operators, designated by the applicable governance rule. At step S7, the PSDi personal security device of each APi approver creates a secure channel SC1i with the governance service (). At step S8, the governance service sends to each PSDi personal security device of each APi approver the description of the transaction and the approval request. At step S9, each APi approver reviews and approves the transaction. Here, it is the user USRi (a natural person) who verifies the transaction as displayed by the PSDi personal security device.This step implements a well-known security principle called "WYSIWYS", which stands for "what you see is what you sign". In step S10, each approver APi confirms its approval to its personal security device PSDi. This is always the physical person who acts on the human-machine interface of their personal security device to confirm its approval. In step S11, the personal security device PSDi of each approver generates an approval of the transaction. In step S12, the personal security device of each approver sends its approval of the transaction to the governance service GOV. As shown in the figure by means of a frame labeled "SC1i", the data transmissions between the governance service and each PSDi device during steps S8 and S12 are carried out using the secure channel SC1i.At step S13, the governance service GOV verifies the approval of the transaction received from each PSDi device.

[0110] If the transaction approval conditions are met, including the required quorum of approvers, the system executes steps in a "QR" box, which stands for "Quorum Reached." Otherwise, the system executes steps in a "QNR" box, which stands for "Quorum Not Reached." Steps in the QR box will be described first.

[0111] At step S20, 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 any appropriate external service.

[0112] Once the raw transaction is generated, 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.

[0113] At a step S31, the governance service sends the raw transaction T (embodiment of the) to the signature service SIGN1, or sends it the HT digest of the raw transaction accompanied by the DRV derivation path and the IDF identifier of the signature function (embodiment 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. At a step S32, the signature service SIGN1 signs the raw transaction.

[0114] In a step S33, 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 (implementation of the). If the signature service is not aware of the transaction T (implementation of the), it is communicated by the governance service GOV of the module HSM1 during a step S33'. In a step S34, the BCAST service places the signed transaction on the relevant BCN blockchain.

[0115] In the event that the approval conditions provided for by the applicable governance rule are not satisfied (QNR framework), the governance service erases the transaction from its memory at step S50. At step S51, it sends information about the transaction approval failure to the notification service NOTIF. At step S52, the notification service sends failure notifications to the transaction platform, the creator and the approvers.

[0116] Describes steps for creating a secure channel between two entities in the system. Describes steps in the sequence diagram. The two entities are designated X and Y. If entity X is a PSDi personal security device, entity Y can be the HSM1 module (GOV governance service) for creating the SC1i channel, or the HSM2 module (signing or key ceremony service) for creating the SC3i channel. Entity X can also be the HSM1 module and entity Y can be the HSM2 module for creating the SC2 channel.

[0117] Each entity X, Y has a private key d X , d Y , a public key P X , P Y , and a C certificate X , C Y including its public key and a signature of it using the private key dA of the certification authority CA:

[0118] C X = [P X , sign(P X , dA)]

[0119] C Y = [P Y, sign(P Y , dA)]

[0120] At step S60, entity X generates a pair of ephemeral private and public keys of X , Pe X . At step S61, entity X generates an ephemeral certificate Ce X including its ephemeral public key Pe X and a signature of it with its private key X :

[0121] This X = [Pe X , sign(Pe X , d X )]

[0122] At step S62, entity X sends its ephemeral public key Pe to entity Y X , the ephemeral certificate This X , its public key P X and his C certificate X . At step S63, entity Y verifies the certification chain of entity X:

[0123] PA → C X (P X ) → This X (Pe X )

[0124] In fact, 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 C certificate 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.

[0125] 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 step S65, entity Y generates an ephemeral certificate Ce Y including its ephemeral public key Pe Y and a signature of it with its private key Y :

[0126] This Y = [Pe Y , sign(Pe Y , d Y )]

[0127] At a step S66, the entity Y generates an ephemeral session key k from its ephemeral private key of Y and the ephemeral public key PeX of entity X, by means of a key exchange function such as for example the ECDH function (Elliptic Curve Diffie–Hellman key exchange), i.e.:

[0128] k = ECDH(of Y , Pe X )

[0129] At step S67, entity Y sends its ephemeral public key Pe to entity X Y as well as, in an encrypted form using the key k, its ephemeral certificate Ce Y and his C certificate Y containing his public key P Y :

[0130] Pe Y , {This Y , C Y}k

[0131] At a step S68, the entity X itself generates the session key k from its ephemeral private key of X and the ephemeral public key Pe Y of entity Y, using the same function as that used by entity Y, here the ECDH function:

[0132] k = ECDH(of X , Pe Y )

[0133] At a step S69, the entity X is therefore able to decrypt the message {This Y , C Y}k.

[0134] At step S70, entity X verifies the certification chain of entity Y:

[0135] PA → C Y (P Y ) → This Y (Pe Y )

[0136] In other words, and as before, 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 C certificate 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.

[0137] At step S71, the two entities have mutually authenticated each other as belonging to the same public key infrastructure. The ephemeral session key k that they have jointly 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.

[0138] Although an advantageous method for creating secure channels based on a Diffie-Hellman key exchange has been described here, various other methods could be provided by those skilled in the art for forming the secure channels SC1i, SC3i and SC2, in particular techniques based on symmetric cryptography using private keys stored in the modules HSM1, HSM2.

[0139] Describes an embodiment of a method for approving a transaction by an APi approver, and shows steps S4, S7 to S13 of the, plus steps S100 and S101 occurring in the event of non-approval of the transaction by the operator. Describes the steps of the according to this embodiment.

[0140] In step S4, the GOV governance service generates a challenge C for transaction approval:

[0141] C = RandomBytes(32)

[0142] "RandomBytes(32)" being a well-known function that generates a 32-byte (256-bit) string of random data.

[0143] In step S7, the governance service creates the secure channel SC1i with the PSDi personal security device of the APi approver. In step S8, the governance service sends the transaction description and the challenge C to the PSDi device. In step S9, the APi approver reviews and approves the transaction. As mentioned above, it is the USRi user (a natural person) who verifies the transaction. In step S10, if the natural person approver has approved the transaction, he confirms his approval to the PSDi personal security device by an action on it ("Approve" box on the). In step S11, the PSDi device signs the challenge C with its private key dPi:

[0144] S = Sign(dPi, C)

[0145] Alternatively, the transaction description could be concatenated with the challenge, or any other data:

[0146] S = Sign(dPi, C ||T)

[0147] In step S12, the PSDi device sends the signed challenge to the governance service. In 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 he refuses the transaction, the device returns an error message to the governance service during a step S101.

[0148] La shows the architecture of a second embodiment of a transaction system for the shared management of cryptoasset accounts. The system differs from that of the in that it implements a multi-party signature algorithm, also called MPC ("Multi-Party Computation") signature algorithm, by which a signature is generated by at least two parties. Thus, in addition to the second hardware security module HSM2 coupled to the server SRV2, the system comprises at least one additional signature device SIGNDV.

[0149] The SIGNDV device is a secure device, for example of the HSM type, or a PSD type device, accessible via a link service LKS' 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 link service LKS' 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. For this purpose, 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.

[0150] The SIGNDV device includes and executes a signature service MSIGN1 using a MPC signature share SH1 that is stored in a memory MEM1. Similarly, 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.

[0151] 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. In some embodiments, the key ceremony may include a step of drawing a random number to generate the SH1, SH2 shares. In other embodiments, 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.

[0152] Figures 16A, 16B, 16C and 16D illustrate several embodiments of an MPC signature method implemented by the system of the. In the embodiments illustrated in Figures 16A and 16B, the MPC signature of a transaction is produced by accumulation, 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. In the embodiments illustrated in Figures 16A and 16B, the MPC signature of a transaction is produced by combination, 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 combining function may be performed by the BCAST broadcast service or any other service that may be provided upstream of the BCAST service for the preparation of signed transactions to be broadcast.

[0153] In the embodiment of the, the HSM1 module provides the transaction T to the signature service MSIGN1 of the SIGNDV device, and the latter provides the HSM2 module with the signature SIG1 which is a function of the transaction and the share SH1. The signature service MSIGN1 provides the transaction T and the signature SIG1 to the signature service MSIGN2, and the latter provides the broadcast service BCAST with the signature SIG2 which is a function of the transaction T, the signature SIG1 and the share SH2. Alternatively, the transaction T can be provided to the service MSIGN2 by the HSM1 module. The BCAST service receives the transaction from the service MSIGN2 but could also receive it directly from the HSM1 module.

[0154] In this embodiment where the transaction T is known to the different parts of the system, the BCAST broadcast service can be executed by the server SRV1 coupled to the module HSM1, as illustrated in solid lines on the, or by the server SRV2 coupled to the module HSM2 or by the device DV3 coupled to the signature device SIGNDV, as illustrated in dotted lines on the.

[0155] In the embodiment of 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 module 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. Alternatively, 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.

[0156] In this embodiment where the transaction T is not known to the two signature services MSIGN1, MSIGN2, the BCAST broadcast service can be executed by the server SRV1 coupled to the module HSM1. As previously, we thus obtain 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 do not have knowledge of them.

[0157] In the embodiment of the, the HSM1 module provides the transaction T 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 transaction and the part SH1. The signature service MSIGN2 provides the broadcast service BCAST with a partial signature SIG2 which is a function of the transaction 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 can be provided to the BCAST service by either of the signing devices or by the HSM1 module.

[0158] In this embodiment, although the transaction T is known to the different parts of the system, neither of the two signing parties can sign the transaction if it is not aware 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 one or other of the two signing parties.

[0159] In the embodiment of the, 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 device SIGNDV 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 function Fmpc to obtain the signature of the transaction. The transaction T is provided here to the BCAST service by the HSM1 module.

[0160] In this embodiment, 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 do not have knowledge of them.

[0161] Lais a sequence diagram describing the performance of a transaction by means of the system of laaccording to one of the embodiments of figures 16C or 16D. Ladescribes steps of the sequence diagram of la. The signature method as shown in laand described by laincludes steps identical to those of the diagram of la, namely steps S1 to S20, S50 to S52. This method is essentially distinguished from the method of lain that steps S30 to S34 of signing the transaction and broadcasting it are replaced by steps S40 to S46. In step S40, the governance service GOV creates a secure communication channel SC2a, via the link https3, with the signature service MSIGN1, and a secure communication channel SC2b, via the link https2, with the signature service MSIGN2.At 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 digest HT, the derivation path DRV and the identifier IDF (). These data are possibly accompanied by a signature request (which can be implicit or take the form of a command). At a step S41', the governance service sends to the signature service MSIGN2, via the secure channel SC2b, the raw transaction T () or sends it its digest HT, the derivation path DRV and the identifier IDF (). These data are possibly accompanied by a signature request (which can be implicit or take the form of a command).

[0162] In step S42, the signature service MSIGN1 generates the partial signature SIG1 using the part SH1. In step S43, the signature service MSIGN1 sends the partial signature SIG1 to the broadcast service BCAST.

[0163] In step S44, the signature service MSIGN2 generates the partial signature SIG2 using the part SH2. In step S45, the signature service MSIGN1 sends the partial signature SIG1 to the broadcast service BCAST.

[0164] At this point, 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.

[0165] At a step S46, the BCAST service assembles the partial signatures SIG1, SIG2 using 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 figure, can then be provided (Cf.).

[0166] It will be clear to those skilled in the art that the embodiments just described of a security-enhanced transaction system for the shared management of cryptoasset accounts are susceptible to various variants. In particular, a third or even a fourth partial signature device could be provided to generate a multi-party signature comprising three or more components.

Claims

A system for shared management of crypto-asset accounts, in which a request to carry out a transaction on a crypto-asset 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, characterized in that it comprises:- a transaction platform (TPF) executed by a server (SRV1), on which transaction descriptions can be created (S1, S2), the transaction platform being configured to, after creation of a transaction, issue a request to carry out the transaction,- a first hardware security module (HSM1) coupled to the transaction platform (TPF), configured to execute governance rules relating to the carrying out of transactions,- a second hardware security module (HSM2),- a signature service (MSIGN1, MSIGN2) configured to generate a signature (SIG1, SIG2) of a transaction (T),the signature service comprising a first signature service (MSIGN1) executed by an intermediate signature device (SIGNDV) and configured to generate a first signature (SIG1) from a first secret data item (SH1), and a second signature service (MSIGN2) executed by the second hardware security module (HSM2) and configured to generate a second signature (SIG2) from a second secret data item (SH2), anda memory (MEM2) receiving the second secret data item (SH2), the memory (MEM2) being accessible in read and write mode to the second hardware security module (HSM2) and inaccessible to the first hardware security module (HSM1),the first hardware security module (HSM1) being configured to, in response to a request to carry out a transaction issued by the transaction platform, request the approval of at least one approving device (APi) and verify whether a governance rule applicable to the requested transaction is satisfied, then,when the governance rule is satisfied, transmitting a request to sign the transaction at least to the first signature service (MSIGN1), the system being configured (HSM2, BCAST) to provide, as a signature of a transaction, a multi-party signature based on the first signature (SIG1) and the second signature (SIG2)., The system of claim 1, wherein the first hardware security module (HSM1), the intermediate signature device (SIGNDV) and the second hardware security module (HSM2) are configured such that the second hardware security module (HSM2) never receives the transaction, the second hardware security module being configured to generate the second signature (SIG2) without having knowledge of the contents of the transaction. System according to one of claims 1 and 2, in which the second hardware security module (HSM2) is configured to generate the second signature from the first signature and the second secret data (SH2), the second signature forming the signature of the transaction. System according to one of claims 1 and 2, in which the first signature (SIG1) and the second signature (SIG2) are complementary, the system comprising a service (BCAST) for broadcasting the transaction on the blockchain configured to combine (Fmpc) the first signature and the second signature in order to obtain the signature of the transaction. System according to one of claims 1 to 4, in which the first hardware security module (HSM1) is configured to, when the governance rule is satisfied, transmit at least to the intermediate signature device (SIGNDV) a digest (HT) of the transaction (T) generated by a hash function, and additional data allowing the intermediate signature device to generate the first signature (SIG1) from this digest. The system of claim 5, wherein the complementary data comprises a hierarchical deterministic derivation path (DRV) and a signature function to be used to generate the signature or an identifier (IDF) of that function. System according to one of claims 1 to 6, wherein the first hardware security module (HSM1) is arranged in a first location with restricted access, and the second hardware security module (HSM2) is arranged in a second location with restricted access different from the first location. System according to one of claims 1 to 7, in which a governance rule defines at least a number of approvals to be received from approving devices (OPi, APi) for a transaction to be signed and executed. System according to one of claims 1 to 8, comprising at least one approving device (OPi, APi), the approving device comprising cryptographic calculation means (PSDi) for establishing a secure communication channel with the first hardware security module. System according to claim 9, wherein the first hardware security module (HSM1) and the approving device (OPi, APi) are members of the same public key infrastructure (PA) comprising a certification authority (CA) providing said public key, and wherein the approving device and the first hardware security module (HSM) are configured to establish a secure communication channel between them by performing 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 (k) by Diffie-Hellman key exchange between the two entities,and use of the session key to encrypt the secure communication channel., System according to one of claims 9 and 10, in which to address a transaction approval to the first hardware security module (HSM1), the approving device (OPi, APi) is configured to display to a natural person user (USRi) a description of the transaction (S9), collect the user's approval (S10), sign (S11) with a private key (dPi) a challenge or data comprising the challenge received from the first hardware security module (HSM1), then send (S12) the signature obtained to the first hardware security module. Method for shared management of crypto-asset accounts, in which a request to carry out a transaction on a crypto-asset 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, method characterized in that it is implemented by means of a system comprising:- a transaction platform (TPF) executed by a server (SRV1), on which transaction descriptions can be created (S1, S2), the transaction platform being configured to, after creation of a transaction, issue a request to carry out the transaction,- a first hardware security module (HSM1) coupled to the transaction platform (TPF), configured to execute governance rules relating to the carrying out of transactions,- a second hardware security module (HSM2),- a signature service (MSIGN1, MSIGN2) configured to generate a signature (SIG1,SIG2) of a transaction (T), the signature service comprising a first signature service (MSIGN1) executed by an intermediate signature device (SIGNDV) and configured to generate a first signature (SIG1) from a first secret data item (SH1), and a second signature service (MSIGN2) executed by the second hardware security module (HSM2) and configured to generate a second signature (SIG2) from a second secret data item (SH2), and- a memory (MEM2) receiving the second secret data item (SH2), the memory (MEM2) being accessible in read and write mode to the second hardware security module (HSM2) and inaccessible to the first hardware security module (HSM1), and in that it comprises the steps of:- in response to a request to carry out a transaction issued by the transaction platform, requesting, by means of the first hardware security module (HSM1),the approval of at least one approving device (APi) and verifying 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 (MSIGN1),- by means of the first signature service (MSIGN1), generating the first signature (SIG1),- by means of the second signature service (MSIGN2), generating the second signature (SIG2), andgenerating a multi-party signature based on the first signature (SIG1) and the second signature (SIG2), the multi-party signature forming the signature of the transaction., The method of claim 12, wherein the second hardware security module (HSM2) never receives the transaction, the second hardware security module being configured to generate the second signature (SIG2) from the first signature (SIG1) without having knowledge of the contents of the transaction. Method according to one of claims 12 and 13, in which the first signature (SIG1) and the second signature (SIG2) are cumulative, the second hardware security module (HSM2) being configured to generate the second signature from the first signature and the second secret data (SH2), the second signature forming the signature of the transaction. Method according to one of claims 12 and 13, in which the first signature (SIG1) and the second signature (SIG2) are complementary, the system comprising a step consisting of combining the first signature and the second signature in order to obtain the signature of the transaction. Method according to one of claims 12 to 15, comprising the step of, by means of the first hardware security module (HSM1), when the governance rule is satisfied, transmitting at least to the intermediate signature device (SIGNDV) a digest (HT) of the transaction (T) generated by a hash function, and additional data making it possible to generate the first signature (SIG1) from this digest. The method of claim 16, wherein the complementary data comprises a hierarchical deterministic derivation path (DRV) and a signature function to be used to generate the signature or an identifier (IDF) of that function. Method according to one of claims 12 to 17, wherein the first hardware security module (HSM1) is arranged in a first location with restricted access, and the second hardware security module (HSM2) is arranged in a second location with restricted access different from the first. Method according to one of claims 12 to 18, in which a governance rule authorizes the signing of a transaction based on a number of approvals to be received from approving devices (OPi, APi).

Images