Shared management system for multi-party crypto-asset accounts

Abstract

A shared crypto-asset account management system in which a request to execute a transaction on a crypto-asset account can only be processed after receiving approval from at least one approver and satisfying a governance rule. The system comprises a first hardware security module (HSM1) configured to execute governance rules, an intermediate signing device (SIGNDV), and a second hardware security module (HSM2) configured to jointly sign transactions upon request from the first hardware security module (HSM1). The transaction signatures are multi-party signatures based on a first signature (SIG1) provided by the intermediate signing device and a second signature (SIG2) provided by the second hardware security module (HSM2). Fig. 16

Description

Title of the invention: System for the shared management of crypto-asset accounts with multi-party signature Technical field

[0001] The present invention relates to a system and 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 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 the blockchain, such as non-fungible tokens ("NFTs") and smart contracts, has given rise to various means of storing and preserving the private and public keys attached to these different types of cryptoassets. This is how cryptoasset wallets, commonly called "wallets", appeared, allowing the storage and preservation of these keys. A cryptoasset wallet is a hardware or software device whose function is to store the private and public keys attached to cryptoasset accounts, and to sign transactions using these keys.

[0003] [Fig.l] schematically 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 the blockchain. The HDV host device is for example a computer, a mobile phone, a tablet or equivalent. The connection between the HW device and the HDV host device can be of the USB or Bluetooth type for example.

[0004] When the HW device is first put into service, it generates a master key KO 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 for example elsewhere 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) in French (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 authenticity of the HW device, its commissioning, the updating of its operating system, the downloading of certified application programs, etc.

[0006] However, an exception to this rule must be made in the case of 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 receiving the agreement of at least one approver and satisfying a governance rule. As illustrated in [Fig.2], in this case, a transaction server SRVO is provided, coupled to a hardware security module HSMO having access to a memory MEM in which the master key KO is recorded for generating the derived keys Kj of the crypto-asset accounts whose management is shared. The hardware security module HSMO executes a transaction governance service GOV in which governance rules have been recorded. The server SRVO executes a transaction platform TPF allowing a plurality of OPi operators (OPi...OPN), to carry out operations on such crypto-asset accounts subject to the agreement of a specific number of operators defined by the governance rules.

[0007] When an OPi operator connects to the TPF transaction platform and requests the completion of a transaction, the requested transaction is communicated to the HSMO hardware security module. The HSMO module identifies the governance rule that applies to the requested transaction, then requests the agreement of OPi operators designated by this governance rule. When the agreement of the operators is received, the HSMO module signs the transaction with the appropriate private key Kj and then broadcasts it on the relevant blockchain.

[0008] 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 protects private keys, validates authorization processes and generates transaction signatures in accordance with predetermined governance rules.

[0009] The applicant uses hardware security modules hosted in secure data centers located in various parts of the world, and offering very high level 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] She also conducts various research projects to maintain as much as possible high 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 known absence to date of any security problem which 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 system for the shared management of 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 receiving the agreement of at least one approver and satisfying a governance rule, the system comprising a first hardware security module for executing governance rules, and a signature service configured to generate a signature of a transaction, the first hardware security module being configured to, in response to a request to carry out a transaction, request the approval of at least one approving device and verify whether a governance rule applicable to the requested transaction is satisfied, system in which the signature service comprises a first signature service executed by an intermediate signature device and configured to generate a first signature from a first secret data item,a second signature service executed by a second hardware security module and configured to generate a second signature from a second secret data, the signature of a transaction being a multi-party signature depending on the first signature and the second signature, the first hardware security module being configured to, when the governance rule is satisfied, transmit a request to sign the transaction at least to the first signature service.

[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 knowing the content 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 forms the intermediate signature device and executes the first signature service.

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

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

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

[0023] 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 public key session by Diffie-Hellman key exchange between the two entities, and use of the session key to encrypt the secure communication channel.

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

[0025] Embodiments also relate to a 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, method implemented by means of a system comprising a first hardware security module, and a signature service configured to generate a signature of a transaction, method in which, in response to a request to carry out a transaction, the first hardware security module requests the approval of at least one approving device and verifies whether a governance rule applicable to the requested transaction is satisfied, the method comprising the steps of providing a first signature service executed by an intermediate signature device and configured to generate a first signature from a first secret data item,providing a second signature service executed by a second hardware security module and configured to generate a second signature from a second secret data, and 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, the signature of the transaction being a multi-party signature based on the first signature and the second signature.

[0026] 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 content of the transaction.

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

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

[0029] 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 complementary data making it possible to generate the first signature from this digest.

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

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

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

[0033] Embodiments of a method and a system for shared management of crypto-asset accounts will be described in the following without limitation in relation to the attached figures among which:

[0034] - the [Fig.l] previously described schematically represents a classic system non-mutualized management of crypto-asset accounts,

[0035] - the [Fig.2] previously described schematically represents a classic system shared management of crypto-asset accounts,

[0036] - [Fig.3] shows a system for shared management of crypto-asset accounts according to a first embodiment,

[0037] - [Fig.4] shows in more detail the system of [Fig.3],

[0038] - [Fig.5A] shows a first transaction signature method implemented in the system of [Fig.4],

[0039] - [Fig.5B] shows a second transaction signing method implemented in the system of [Fig.4],

[0040] - [Fig.6] shows a configuration of the system of [Fig.4] when creating governance rules,

[0041] - [Fig.7] is a flowchart describing steps in creating governance rules governance,

[0042] - [Fig.8] shows a configuration of the system of [Fig.4] during a ceremony of keys,

[0043] - [Fig.9] is a flowchart describing steps of the key ceremony,

[0044] - [Fig. 10] is a sequence diagram describing the completion of a transaction by means of the system of [Fig.4],

[0045] - [Fig.l 1] is a flowchart describing steps of the sequence diagram of [Fig. 10],

[0046] - [Fig. 12] is a sequence diagram describing steps in creating a secure channel in the system of [Fig.4],

[0047] - [Fig. 13] is a flowchart describing steps of the sequence diagram of [Fig. 12],

[0048] - [Fig. 14] is a sequence diagram describing steps in approving a transaction in the system of [Fig.4],

[0049] - [Fig. 15] is a flowchart describing steps of the sequence diagram of [Fig. 14],

[0050] - [Fig. 16] shows a system for shared management of crypto-asset accounts according to a second embodiment,

[0051] - [Fig.l7A], [Fig.l7B], [Fig.l7C] and [Fig.l7D] show four modes of implementation of a transaction signature process implemented in the system of [Fig.16],

[0052] - [Fig. 18] is a sequence diagram describing the completion of a transaction by means of the system of [Fig. 16], and

[0053] - [Fig. 19] is a flowchart describing steps of the sequence diagram of [Fig. 18], Detailed description

[0054] For a set of crypto-asset accounts derived from the same KO master key, the system is intended to be used by a set of PAi participants in which we distinguish co-owners of OWNi accounts ("shared-owner"), ADMi administrators, and OPi operators.

[0055] The administrators define governance rules. They can also, in one embodiment, approve or even designate co-owners. The co-owners generate the KO master key of the set of crypto-asset accounts, from KOi master keys 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.

[0056] 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 HSM1 is coupled to a second server SRV2. The term "hardware security module" designates a module of the type discussed above, offering a high level of hardware and software security, for example compliant with the FIPS 140-2 level III standard.

[0057] PAi participants (ADMi, OWNi or OPi) can connect to the SRV1 server via a secure httpsl 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 httpsl and https2 data links, with the SRV1 server preferably being used as an intermediary server or proxy server to allow them to connect to the HSM2 security module.

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

[0059] The SRV 1 server comprises and executes a TPF transaction platform, a NOTIF notification service and an ORCH orchestrator service. The HSM1 module comprises and executes a GOV governance service. The SRV2 server comprises and executes a LKS link service for establishing the https2 link with the HSM2 module. The HSM2 module comprises and executes a SIGNL signature service. The HSM2 module also comprises and executes a KCER1 key ceremony service, for recording the KO master key in a MEM memory. Finally, the system comprises a BCAST service for broadcasting signed transactions on blockchain networks.

[0060] The BCAST service is shown herein without limitation as executed by the SRV 1 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.

[0061] The MEM memory receiving the master key KO 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.

[0062] Three types of operations can be performed with the system: the registration of governance rules, the generation of the master key KO 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 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.

[0063] [Fig.4] shows a more detailed embodiment of the system of [Fig.3]. Each PAi participant here includes:

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

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

[0066] In one embodiment, the personal security device PSDi is a device having a hardware cryptoasset 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.

[0067] In another embodiment, the personal security device PSDi and the host device HDVi form a single device, for example a so-called "blockchain" telephone, comprising an integrated hardware wallet made from a secure element in integrated circuit or from a trusted execution environment TEE which emulates a secure element. Such a telephone executes a secure application which ensures the conduct of the steps described in the following.

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

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

[0070] In one embodiment, the personal security devices PSDi, the module HSM1 and the module HSM2 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, dHl, dH2, a static public key, respectively PPi, PHI, 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.

[0071] Thanks to 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 SCli 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 SCli between a PSDi and the HSM1 module is established here through the secure data link httpsl. The secure communication channel SC3i between a PSDi and the HSM1 module is established here through the secure data link httpsl and the secure data link https2. The communication channel Secure SC2 communication between HSM1 and HSM2 modules is established here through the secure https2 data link.

[0072] Figures 5A, 5B illustrate two embodiments of a transaction signing method implemented using the system of [Fig.4].

[0073] In [Fig.5A], 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 a “raw transaction”.

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

[0075] {

[0076] "coin": "eth"

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

[0078] "sender": "0x473780deaf4a2ac070bba936b0cdefe7f267dfc",

[0079] "amount": "0.000567202182620675",

[0080] "maxGas": "0.00000005"

[0081] }

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

[0083] f86e826f4a8505f901eadd826b6c94388c818ca8b925 lb39313 lc08a736a67ccbl92978 801167140fda3d0818025a0dcbal464c58f31892bd0ae8e6271f83 8189cd344d98e928f3 194efe4bce9ebc6a04fOfc71bee74ala6fafbel7cde3c35981c93b58703856ef5dd53884alb 153773

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

[0085] {

[0086] "r"

[0087] "0xb91467e570a6466aa9e9876cbcd013baba02900b8979d43fe208a4a4f339f5fd",

[0088] "s":

[0089] "0x60 07e7 4cd82e037b8 0018 6422fc2dal67c7 4 7ef04 5e5dl8a5f5d4 300f8ela02 9"

[0090] "v": 28

[0091] }

[0092] The transaction T and its signature SIG1 are then transmitted to the BCAST broadcast service so that it broadcasts the transaction on the relevant 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 in [Fig.4], 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.

[0093] The embodiment of [Fig.5B] differs from that of [Fig.5A] in that the HSM1 module does not communicate the raw transaction T to the HSM2 module, but the digest 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 digest, is carried out by the HSM1 module. In this case the HSM1 module also transmits to the HSM2 module information which is necessary for it 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 which may be necessary for generating signatures).

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

[0095] 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 in [Fig.4], since it is aware of transaction T.

[0096] In summary, the shared transaction management system architecture that has just been proposed comprises two separate hardware security modules, the first for applying governance rules and authorizing the signing of transactions when the governance rules are satisfied, the second for signing the transactions. According to an embodiment of this architecture illustrated in [Fig.5B], the hardware security module that authorizes the signing of transactions cannot sign them itself because it does not have the KO secret allowing them to be signed, and the hardware security module that signs the transactions has no knowledge of them.

[0097] [Fig.6] shows the configuration of the system of [Fig.4] 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 in [Fig.7] describes an embodiment of this method. 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 SCli 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 SCli channel. In a step G5, the governance service requests the NOTIF notification service of the SRV1 server to send a governance rule voting notification to the other ADMi administrators.In step G6, secure SCli 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 vote of the administrators.

[0098] The governance rules can be defined and adopted according to various methods other than the one just described. Adoption rules defining a quorum and a majority rule for the adoption of governance rules can be hard-coded in the governance service. The governance rules can be simple, complex, single or multiple. They can, for example, define a minimum number of unidentified operators who must approve a transaction per type of cryptoasset concerned and / or according to the amount of the transaction, or define specifically the operators who can approve a transaction per type of cryptoasset concerned and / or depending on the amount of the transaction. They can also define the operators authorized to create a transaction on the TPF platform for a particular type of cryptoasset, and those who are not authorized and can only be transaction approvers.

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

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

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

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

[0103] [Fig.8] shows a configuration of the system of [Fig.4] during a key ceremony. The flowchart of [Fig.8] 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 to 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 KOi or a part of the master key of each device PSDi.At step K6 the KCER1 service generates the private key KO from the master keys or parts of master keys received, and stores it in the MEM memory.

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

[0105] "m" is the master key

[0106] : indicates the separation between the derivation levels

[0107] "codel"' is a process-specific code, which may be arbitrary,

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

[0109] The master key KO 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 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 in ap applying the HMAC-SHA512 hash algorithm to the KO key using the terms "Bitcoin Seed" as the key and "master seed" as the message.

[0110] [Fig. 10] describes the execution of a transaction using the system of [Fig.4] and [Fig.11] describes steps shown by [Fig.10]. 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.

[0111] At a step S1, an OPi operator connects to the TPF transaction platform. At a step S2, the operator creates the description of the transaction. At a step S3, the TPF platform sends to the governance service GOV a transaction request comprising the description of the transaction. At a step S4, the governance service generates a request for approval of the transaction 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 in relation to figures 13 and 14.

[0112] In a step S5, the governance service informs the notification service NOTIF that a transaction is requested. In a step S6, the notification service sends a transaction notification to all the relevant APi approver operators, designated by the applicable governance rule. In a step S7, the PSDi personal security device of each APi approver creates a secure channel SCli with the governance service ([Fig.4]). In a 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. In a step S9, each APi approver examines 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 known security principle called "WYSIWYS", which means "you only sign what you see" ("What-You-See-Is-What-You-Sign"). At a 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 his personal security device to confirm his approval. At a step SI 1, the personal security device PSDi of each approver generates an approval of the transaction. At a step S12, the personal security device of each approver sends its approval of the transaction to the governance service GOV. As shown in [Fig. 10] by means of a frame with the label "SCli", the data transmissions between the governance service and each PSDi device during steps S8 and S12 are carried out by means of the secure channel SCli. At a step S13, the . GOV governance service verifies the approval of the transaction received from each PSDi device.

[0113] If the conditions for approval of the transaction are met, in particular if the required quorum of approvers is reached, the system executes steps appearing in a "QR" frame which means "Quorum reached" ("Quorum Reached"), otherwise the system executes steps appearing in a "QNR" frame which means "Quorum not reached" (Quorum Not Reached). First, we will describe the steps appearing in the QR frame.

[0114] At a step S20, the governance service generates a raw transaction from the description of the transaction. This calculation of the raw transaction shown here as carried out by the governance service can however be entrusted to the server SRV1 or to any appropriate external service.

[0115] Once the raw transaction has been generated, the governance service creates at a step S30 the secure communication channel SC2 with the signature service SIGN1 executed by the module HSM2, via the https2 link.

[0116] At a step S31, the governance service sends the raw transaction T to the signature service SIGN1 (embodiment of [Fig.5A]), 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 [Fig.5B]). 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.

[0117] 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 (embodiment of [Fig.5A]). If the signature service is not aware of the transaction T (embodiment of [Fig.5B]), it is communicated by the governance service GOV of the module HSM1 during a step S33'. In a step S34, the service BCAST places the signed transaction on the corresponding blockchain BNC.

[0118] 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 a step S50. At a step S51, it sends to the notification service NOTIF information that the approval of the transaction has failed. At a step S52, the notification service sends failure notifications to the transaction platform, the creator and the approvers.

[0119] [Fig. 12] describes steps for creating a secure channel between two entities of the system of [Fig.4]. [Fig. 13] describes steps in the sequence diagram of the [Fig. 12]. 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 the creation of the SCli 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.

[0120] Each entity X, Y has a private key dx, dY, a public key Px, PY, and a certificate Cx, CY comprising its public key and a signature of it using the private key dA of the certification authority CA:

[0121] Cx = [Px, sign(Px, dA)]

[0122] CY = [PY, sign (PY, dA)]

[0123] At a step S60, the entity X generates a pair of private and public ephemeral keys dex, Pex. At a step S61, the entity X generates an ephemeral certificate Cex comprising its ephemeral public key Pex and a signature thereof with its private key dx:

[0124] Cex = [Pex, sign(Pex, dx)]

[0125] At a step S62, entity X sends to entity Y its ephemeral public key Pex, the ephemeral certificate Cex, its public key Px and its certificate Cx. At a step S63, entity Y verifies the certification chain of entity X:

[0126] PA CX(PX) Cex(Pex)

[0127] In fact, the public key PA of the certification authority allows it to verify the validity of the signature of the public key Px appearing in the certificate Cx, then the verified public key Px allows it to verify the validity of the signature of the ephemeral public key Pex appearing in the ephemeral certificate.

[0128] If the verification is conclusive, at a step S64 the entity Y generates a pair of ephemeral private and public keys deY, PeY. At a step S65, the entity Y generates an ephemeral certificate CeY comprising its ephemeral public key PeY and a signature of the latter with its private key dY:

[0129] CeY = [PeY, sign (PeY, dY)]

[0130] In a step S66, the entity Y generates an ephemeral session key k from its ephemeral private key deY and the ephemeral public key Pex 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.:

[0131] k = ECDH(deY , Pex)

[0132] At a step S67, the entity Y sends to the entity X its ephemeral public key PeY as well as, in a form encrypted by means of the key k, its ephemeral certificate CeY and its certificate CY containing its public key PY:

[0133] PeY, {CeY , CY]k

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

[0135] k = ECDH(dex , PeY)

[0136] At a step S69, the entity X is therefore able to decrypt the message {CeY, CY]k.

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

[0138] PA -> CY(PY) -> CeY(PeY)

[0139] In other words, and as previously, the public key PA of the certification authority allows it to verify the validity of the signature of the public key PY appearing in the certificate Cx, then the certified public key PY allows it to verify the validity of the signature of the ephemeral public key PeY appearing in the ephemeral certificate.

[0140] At a step S71, the two entities have mutually authenticated themselves 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.

[0141] 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 SC11, SC31 and SC2, in particular techniques based on symmetric cryptography using private keys recorded in the modules HSM1, HSM2.

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

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

[0144] C = RandomBytes(32)

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

[0146] In step S7, the governance service creates the secure channel SCli with the PSDi personal security device of the APi approver. In step S8, the governance service sends the description of the transaction and the challenge C to the PSDi device. In step S9, the APi approver examines and approves the transaction. As specified above, it is the user USRi, 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 in [Fig. 14]). In step SU, the PSDi device signs the challenge C with its private key dPi:

[0147] S = Sign(dPi, C)

[0148] In a variant, the description of the transaction could be concatenated with the challenge, or any other data:

[0149] S = Sign(dPi, C HT)

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

[0151] [Fig. 16] shows the architecture of a second embodiment of a transaction system for the shared management of cryptoasset accounts. The system differs from that of [Fig. 4] 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.

[0152] 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 personal security devices PSDi of the OPi operators to establish a secure communication channel SC4i 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.

[0153] The SIGNDV device comprises and executes a signature service MSIGN1 using a MPC signature share SH1 which is stored in a memory MEM1. Similarly, the HSM2 module comprises and executes a signature service MSIGN2 which 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.

[0154] Each share SH1, SH2 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 shares SH1, SH2. In other embodiments, co-owners OWNi may participate in the key ceremony so that the master keys KOi of their respective PSDi devices are used to generate the shares SH1, SH2.

[0155] Figures 17A, 17B, 17C and 17D illustrate several embodiments of an MPC signature method implemented by the system of [Fig. 16]. In the embodiments illustrated in Figures 17A and 17B, 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 17A and 17B, 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 by means of 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 that can be provided upstream of the BCAST service for the preparation of the signed transactions to be broadcast.

[0156] In the embodiment of [Fig.17A], 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. Alternatively, 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.

[0157] 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 in [Fig. 16], 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 in [Fig. 16].

[0158] In the embodiment of [Fig.l7B], the HSM1 module provides the MSIGN signature service 1 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 MSIGN2 signature service with the HT digest, the DRV derivation path, the IDF identifier and the SIG1 signature. BCAST broadcast 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.

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

[0160] In the embodiment of [Fig.17C], 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.

[0161] 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 in [Fig. 16], rather than having it executed by one or the other of the two signing parties.

[0162] In the embodiment of [Fig.17D], 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 MSIGN 1 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.

[0163] In this embodiment, the BCAST broadcast service can be executed by the SRV1 server coupled to the HSM1 module, as illustrated in solid lines in [Fig. 16], 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 have the SH1, SH2 secrets allowing them to be signed, and the signature services which sign the transactions do not have knowledge of them.

[0164] [Fig. 18] is a sequence diagram describing the performance of a transaction by means of the system of [Fig. 16] according to one of the embodiments of FIGS. 17C or 17D. [Fig. 19] describes steps of the sequence diagram of [Fig. 18]. The signature method as shown in [Fig. 18] and described by [Fig. 19] comprises steps identical to those of the diagram of [Fig. 10], namely steps S1 to S20, S50 to S52. This method is essentially distinguished from the method of [Fig. 10] in 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 ([Fig.l7C]) or sends it its digest HT, the derivation path DRV and the identifier IDF ([Fig.l7D]). This data is 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 ([Fig.l7C]) or sends it its digest HT, the derivation path DRV and the identifier IDF ([Fig.l7D]). This data is possibly accompanied by a signature request (which can be implicit or take the form of a command).

[0165] In a step S42, the signature service MSIGN1 generates the partial signature SIG1 by means of the part SH1. In a step S43, the signature service MSIGN1 sends the partial signature SIG1 to the broadcast service BCAST.

[0166] In a step S44, the signature service MSIGN2 generates the partial signature SIG2 by means of the part SH2. In a step S45, the signature service MSIGN1 sends the partial signature SIG1 to the broadcast service BCAST.

[0167] At this stage, 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 erroneous and the final signature will also be erroneous. Indeed, neither the HSM2 module nor the SIGNDV device can sign the transaction alone. To sign the transaction, both signatures are required.

[0168] At a step S46, the BCAST service assembles the partial signatures SIG1, SIG2 at using the Fmpc function to obtain the signature of the transaction, then broadcasts the signed transaction on the relevant BNC blockchain. 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 [Fig. 18], can then be provided (Cf. [Fig.l7D]).

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

Claims

Claims

1. 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, the system comprising: - a first hardware security module (HSM1) for executing governance rules, and - a signature service (MSIGN1, MSIGN2) configured to generate a signature (SIG1, SIG2) of a transaction (T), the first hardware security module (HSM1) being configured to, in response to a request to carry out a transaction, request the approval of at least one approving device (APi) and verify whether a governance rule applicable to the requested transaction is satisfied,system characterized in that the signature service comprises: - 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), - a second signature service (MSIGN2) executed by a second hardware security module (HSM2) and configured to generate a second signature (SIG2) from a second secret data item (SH2), the signature of a transaction being a multi-party signature depending on the first signature (SIG1) and the second signature (SIG2), the first hardware security module (HSM1) being configured to, when the governance rule is satisfied, transmit a request to sign the transaction at least to the first signature service (MSIGN1).,

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. System according to one of claims 1 to 6, wherein the first hardware security module (HSM1) forms the intermediate signature device (SIGNDV) and executes the first signature service (MSIGN1).

8. System according to one of claims 1 to 7, in which 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.

9. System according to one of claims 1 to 8, 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.

10. System according to one of claims 1 to 9, 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.

11. The system of claim 10, 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 in which 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.

12. System according to one of claims 10 and 11, 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 (S 10), sign (SI 1) with a private key (dPi) a challenge or data comprising the challenge received from the first hardware security module (HSM1), then send (S 12) the signature obtained to the first hardware security module.

13. 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 satisfied a governance rule, method implemented by means of a system comprising: - a first hardware security module (HSM1), and - a signature service (MSIGN1, MSIGN2) configured to generate a signature (SIG1, SIG2) of a transaction (T), method in which, in response to a request to carry out a transaction, the first hardware security module (HSM1) requests the approval of at least one approving device (APi) and verifies whether a governance rule applicable to the requested transaction is satisfied, method characterized in that it comprises the steps of: - providing a first signature service (MSIGN1) executed by a intermediate signature device (SIGNDV) and configured to generate a first signature (SIG1) from a first secret data item (SH1), - provide a second signature service (MSIGN2) executed by a second hardware security module (HSM2) and configured to generate a second signature (SIG2) from a second secret data item (SH2), and - when the governance rule is satisfied, transmit a request to sign the transaction at least to the first signature service (MSIGN1), - by means of the first signature service (MSIGN1), generate the first signature (SIG1), - by means of the second signature service (MSIGN2), generate the second signature (SIG2), the signature of the transaction being a multi-party signature based on the first signature (SIG1) and the second signature (SIG2).

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

15. Method according to one of claims 13 and 14, 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.

16. Method according to one of claims 13 and 14, in which the first signature (SIG1) and the second signature (SIG2) 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.

17. Method according to one of claims 13 to 16, 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 complementary data making it possible to generate the first signature (SIG1) from of this condensate.

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

19. Method according to one of claims 13 to 18, wherein the first hardware security module (HSM1) is arranged in a first restricted access location, and the second hardware security module (HSM2) is arranged in a second restricted access location different from the first.

20. Method according to one of claims 13 to 19, 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).