Shared encrypted asset account management system with multi-party signatures

Abstract

The present invention relates to a system for centralized management of encrypted asset accounts in which a request to perform a transaction on an encrypted asset account can be performed only upon receipt of an agreement of at least one approver and satisfaction of a governance rule. The system comprises a first hardware security module (HSM1) configured to execute a governance rule, an intermediate signature device (SIGNDV), and a second hardware security module (HSM2) configured to sign a transaction in batches upon request of the first hardware security module (HSM1), the transaction signature is a multi-party signature based on a first signature (SIG1) provided by the intermediate signature device and a second signature (SIG2) provided by the second hardware security module (HSM2).

Description

Technical Field

[0001] The present invention relates to a system and method for shared management of crypto asset accounts, wherein a request to execute a transaction on a crypto asset account cannot be executed until approval is received from at least one approver and governance rules are met. Background Technology

[0002] In recent years, the development of cryptocurrencies and other types of blockchain-managed crypto assets, such as non-fungible tokens (“NFTs”) and smart contracts, has led to various methods for storing and preserving the private and public keys associated with these different types of crypto assets. This has resulted in the emergence of crypto asset wallets, which are hardware or software devices that function to store the private and public keys associated with a crypto asset account and use these keys to sign transactions.

[0003] Figure 1 An example is illustrated of a hardware crypto asset wallet HW (e.g., a device sold by the applicant under the names "Nano" or "Stax") and a host device HDV that executes a companion application HSW (e.g., the "Ledger Live" application developed by the applicant). Since the device HW cannot be directly connected to the internet for security reasons, it is associated with the host device HDV to execute transactions on the blockchain BCN. The host device HDV is, for example, a computer, mobile phone, tablet, or equivalent. The connection between the device HW and the host device HDV can be, for example, USB or Bluetooth.

[0004] During the initial commissioning of device HW, the device generates a master key K0, which can then be used to derive the private key Kj of the encrypted asset account and provide the user with a 24-word recovery phrase that the user should keep on appropriate physical media (e.g., a piece of paper or an immutable medium such as an engraved metal plate), which the user should store in a secure location.

[0005] Once connected to the host device, the device HW can interact with the accompanying software, enabling the user USR to execute transactions on the blockchain BCN or on decentralized exchanges. The device HW can also communicate with a hardware security module HSM located in a data center. This type of hardware security module is also known as a transaction black box BTN (https: / / fr.wikipedia.org / wiki / Hardware_Security_Module). Generally, the hardware security module HSM does not store the user's private key, but only ensures control over the authenticity of the device HW, its debugging, its operating system updates, and the download of certified applications.

[0006] There are exceptions to the shared management of crypto asset accounts, where a transaction cannot be executed on a crypto asset account until approval from at least one approver is received and governance rules are met. In this case, a hardware security module is provided to perform transaction governance services and sign transactions. For this purpose, the hardware security module maintains the master key and / or private key of the crypto asset account involved. When a request to execute a transaction is made to the hardware security module, the module identifies the governance rules applicable to the requested transaction and then requests approval from the operator designated by those governance rules. Upon receiving approval from the operator, the hardware security module signs the transaction with the appropriate private key and then broadcasts it on the relevant blockchain.

[0007] Therefore, in the context of shared management of crypto asset accounts, the security of these accounts relies on the inviolability of a hardware security module. This module protects private keys, verifies the authorization process, and generates transaction signatures according to predefined governance rules.

[0008] Furthermore, patent application WO2023046409A1 discloses a transaction approval system for non-shared crypto asset accounts, in which a hardware wallet addresses transactions to be signed to a policy service. This policy service provides signing authorization to a signature service. The signature service signs the transaction and returns it to the hardware wallet, which then places the signed transaction on the blockchain. The policy service and signature service are not executed by a hardware security module, but rather by a public hardware security module. After an integration phase involving building and deploying secrets, the public hardware security module provides a public key to the policy service, which sends the public key to the signature service in a form encrypted by the building and deploying secrets. The public hardware security module also provides the signature service with the signature of the transaction approved by the policy service.

[0009] The applicant uses hardware security modules hosted in secure data centers around the world, and these hardware security modules provide very high levels of security that meet, for example, FIPS 140-2 Level 3 standards, and also implement various additional hardware and software security measures.

[0010] The applicant also conducted various research efforts to maintain the highest level of security provided by the hardware security module. In 2019, the applicant thus discovered 14 vulnerabilities in the HSM module. Exploiting these vulnerabilities could allow a remote attacker to gain arbitrary code execution in the HSM and potentially extract all secret keys without any authentication. The issue was publicly disclosed and appropriately corrected by the HSM vendor to the best of their ability, which improved the security level of the entire HSM industry. See: https: / / donjon.ledger.com / BlackHat2019-presentation

[0011] Although no security issues are known to date that could lead to attacks on shared account keys held by such hardware security modules, the applicant continues to seek improvements aimed at enhancing the security level of the systems it develops (see https: / / donjon.ledger.com).

[0012] Therefore, it may be desirable to improve the security level provided by the type of shared encrypted asset account management system just described. Summary of the Invention

[0013] The implementation scheme relates to a shared crypto-asset account management system, wherein a request to execute a transaction on a crypto-asset account cannot be executed until approval is received from at least one approver and governance rules related to the execution of the transaction are met. The system includes: a transaction platform executed by a server, capable of creating transaction descriptions on the transaction platform, configured to issue a request to execute the transaction after its creation; a first hardware security module coupled to the transaction platform, configured to execute governance rules related to the execution of the transaction; a second hardware security module; a signature service configured to generate signatures for transactions, the signature service including a first signature service executed by an intermediate signature device and configured to generate a first signature from first secret data, and a second signature service executed by the second hardware security module and configured to generate a second signature from second secret data; and a memory receiving the second secret data, the memory being readable and writable by the second hardware security module and inaccessible to the first hardware security module. The first hardware security module is configured to respond to a request from the trading platform to execute a transaction, requesting approval from at least one approver device and verifying whether the governance rules applicable to the requested transaction are satisfied. Then, when the governance rules are satisfied, it transmits a request to at least the first signature service to sign the transaction. The system is configured to provide a multi-party signature as a function of the first and second signatures as the transaction signature.

[0014] According to one implementation, a first hardware security module, an intermediate signature device, and a second hardware security module are configured such that the second hardware security module never receives transactions, and the second hardware security module is configured to generate a second signature without knowing the content of the transaction.

[0015] According to one implementation, the second hardware security module is configured to generate a second signature from the first signature and the second secret data, the second signature forming a transaction signature.

[0016] According to one implementation, the first signature and the second signature are complementary, and the system includes a blockchain transaction broadcasting service configured to combine the first signature and the second signature to obtain a transaction signature.

[0017] According to one implementation, the first hardware security module is configured to transmit, at least to the intermediate signature device, a digest of the transaction generated by the hash function, and complementary data that enables the intermediate signature device to generate a first signature from the digest when the governance rules are satisfied.

[0018] According to one implementation, the complementary data includes a hierarchical deterministic derivation path and a signature function to be used to generate the signature, or an identifier for that function.

[0019] According to one implementation, a first hardware security module is located at a first location with restricted access, and a second hardware security module is located at a second location with restricted access, the second location being different from the first location.

[0020] According to one implementation, the governance rules define at least the number of approvals to be received from the approver's device for transactions to be signed and executed.

[0021] According to one implementation, the system includes at least one approver device, which includes a cryptographic computing device to establish a secure communication channel with a first hardware security module.

[0022] According to one implementation, the first hardware security module and the approver device are members of the same public key infrastructure, which includes a certification authority (CA) providing the public key, and wherein the approver device and the first hardware security module are configured to establish a secure communication channel between them by performing the following steps: each entity mutually verifies that the other entity possesses a valid static certificate of the public key of the public key infrastructure; each entity generates a temporary certificate, which includes a temporary public key signed with the entity's private key; each entity mutually verifies that the other entity's temporary certificate is valid relative to its static certificate; a session key is generated through a Diffie-Hellman key exchange between the two entities, and the session key is used to encrypt the secure communication channel.

[0023] According to one implementation, in order to send transaction approval to the first hardware security module, the approver device is configured to display a description of the transaction to the natural person user, collect the user's approval, sign the query or data including the query received from the first hardware security module using a private key, and then send the obtained signature to the first hardware security module.

[0024] The implementation also relates to a method for shared management of crypto-asset accounts, wherein a request to execute a transaction on a crypto-asset account cannot be executed until approval is received from at least one approver and governance rules relating to the execution of the transaction are met. This method is implemented using a system comprising: a transaction platform executed by a server, capable of creating transaction descriptions, the transaction platform being configured to issue a request to execute the transaction after its creation; a first hardware security module coupled to the transaction platform, the first hardware security module being configured to execute governance rules relating to the execution of the transaction; a second hardware security module; a signature service configured to generate signatures for the transaction, the signature service including a first signature service executed by an intermediate signature device and configured to generate a first signature from first secret data, and a second signature service executed by the second hardware security module and configured to generate a second signature from second secret data; and a memory receiving second secret data, the memory being readable and writable by the second hardware security module and inaccessible to the first hardware security module. In response to a request to execute a transaction issued by a trading platform, the method includes the steps of: requesting approval from at least one approver device and verifying whether governance rules applicable to the requested transaction are satisfied, using a first hardware security module; when the governance rules are satisfied, transmitting a request to sign the transaction to at least a first signature service; generating a first signature using the first signature service; generating a second signature using a second signature service; and generating a multi-party signature as a function of the first and second signatures, the multi-party signature forming the transaction signature.

[0025] According to one implementation, the second hardware security module never receives transactions and is configured to generate a second signature from the first signature without knowing the content of the transaction.

[0026] According to one implementation, the first signature and the second signature are cumulative, and a second hardware security module is configured to generate a second signature from the first signature and the second secret data, the second signature forming a transaction signature.

[0027] According to one implementation, the first signature and the second signature are complementary, and the system includes the step of combining the first signature and the second signature to obtain a transaction signature.

[0028] According to one implementation, the method includes the steps of: transmitting, by means of a first hardware security module, at least a digest of the transaction generated by a hash function, and complementary data that enables the generation of a first signature from the digest, to an intermediate signature device when governance rules are satisfied.

[0029] According to one implementation, the complementary data includes a hierarchical deterministic derivation path and a signature function to be used to generate the signature, or an identifier for that function.

[0030] According to one implementation, a first hardware security module is located at a first location with restricted access, and a second hardware security module is located at a second location with restricted access, the second location being different from the first location.

[0031] According to one implementation, the governance rules authorize the signature of a transaction based on the number of approvals to be received from the approver's device. Attached Figure Description

[0032] The following will describe, through non-limiting examples and with reference to the accompanying drawings, an implementation scheme for the shared management of encrypted asset accounts, in which: Figure 1 As previously described, this schematically illustrates a traditional system for non-shared management of crypto asset accounts; Figure 2 A shared encrypted asset account management system according to a first embodiment is shown; Figure 3 Showing more details Figure 2 The system; Figure 4A It shows in Figure 3 The first transaction signature method implemented in the system; Figure 4B It shows in Figure 3 The second transaction signature method implemented in the system; Figure 5 This shows the process during the creation of governance rules. Figure 3 System configuration; Figure 6 It is a flowchart describing the steps used to create governance rules; Figure 7 The key ceremony was shown Figure 3 System configuration; Figure 8 This is a flowchart describing the steps of a key ceremony; Figure 9 It is a description using Figure 3 The sequence diagram of the system executing transactions; Figure 10 It is a description Figure 9 A flowchart of the steps in the sequence diagram; Figure 11 It is a description used in Figure 3 A sequence diagram of the steps involved in creating a secure channel in the system; Figure 12 It is a description Figure 11A flowchart of the steps in the sequence diagram; Figure 13 It is a description used for approval Figure 3 A sequence diagram of the transaction steps in the system; Figure 14 It is a description Figure 13 A flowchart of the steps in the sequence diagram; Figure 15 A shared encrypted asset account management system according to the second implementation scheme is shown; Figure 16A , Figure 16B , Figure 16C and Figure 16D It shows in Figure 15 Four implementation schemes for the transaction signature method implemented in the system; Figure 17 It is a description using Figure 15 The system executes a sequence diagram of transactions; and Figure 18 It is a description Figure 17 The flowchart of the steps for creating a sequence diagram. Detailed Implementation

[0033] Figure 2 The general architecture of a first implementation of an enhanced security transaction system for shared management of crypto asset accounts is shown.

[0034] For at least one set of crypto asset accounts derived from the master key K0, the system is designed to be used by a group of participants PAI, where a distinction is made between the shared owners of the account OWNi, the administrator ADMi, and the operator OPi. The system includes a trading platform TPF that enables multiple operators OPi (OP1…OPN) to perform operations on such crypto asset accounts, subject to approval by a defined number of operators as defined by governance rules.

[0035] Administrators define governance rules. In one implementation, they may also approve or even designate a share owner. The share owner generates the master key K0 for the group of crypto asset accounts based on their own master key K0i. Operators OPi initiate transactions or approve transactions initiated by other operators. Each participant ADMi, OWNi, or OPi includes a cryptographic computing device.

[0036] The presented system advantageously includes two hardware security modules, HSM1 and 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 described above, typically housed in a data center, providing, for example, a high level of hardware and software security conforming to FIPS 140-2 Level III standards.

[0037] Participant PAi (ADMi, OWNi, or OPi) can connect to server SRV1 via secure data link https1. Server SRV1 can connect to server SRV2 via secure data link https2. Share owner OWNi can also connect to server SRV2 via secure data links https1 and https2. Server SRV1 is preferably used as an intermediary server or proxy server to enable them to connect to module HSM2.

[0038] It should be noted that although HTTPS-type links are cited by way of example in this disclosure, these secure data links can be any other known type, such as VPN, TLS, etc.

[0039] Server SRV1 includes and executes the transaction platform TPF, as well as the notification service NOTIF and the orchestrator service ORCH. Module HSM1 includes and executes the governance service GOV. Server SRV2 includes and executes the link service LKS, which enables the establishment of HTTPS2 links with module HSM2. Module HSM2 includes and executes the signature service SIGN1. Module HSM2 also includes and executes the key ceremony service KCER1, enabling the master key K0 to be recorded in the memory MEM. Finally, the system includes the service BCAST for broadcasting signed transactions on the blockchain network BCN.

[0040] The BCAST service is shown here by way of non-limiting example as being performed by server SRV1, but it may also be performed by server SRV2, as shown by the dashed line, or by any other server or device associated with the system.

[0041] The memory MEM that receives the master key K0 can be located inside or outside module HSM2. The system is designed such that the memory MEM is inaccessible to module HSM1 and can only be read and written by module HSM2. In practice, modules HSM1 and HSM2 are preferably located in different secure locations, which can be very far apart from each other.

[0042] This system can be used to perform three types of operations: recording management rules, generating the master key K0 during the key ceremony, and transactions on crypto asset accounts. Because it provides two hardware security modules, HSM1 and HSM2, and separates management functions (i.e., management of the transaction approval process) from transaction signing functions, the system offers a higher level of security than traditional systems.

[0043] Figure 3 It shows Figure 2A more detailed implementation of the system. Each participant, PAI, is included here: - A personal safety device (PSDi) associated with a host device (HDVi) executing a companion application (HSW), such as the "Ledger Live" application developed by the applicant. - Natural person user USRi, who can perform actions on the host device HDVi's human-machine interface or on the personal security device PSDi's human-machine interface.

[0044] In one implementation, the Personal Security Device (PSDi) is a device having a hardware cryptographic asset wallet architecture and including an integrated circuit security element associated with an integrated circuit microcontroller configured to enable the security element to establish a secure communication channel with the hardware security module HSM1 via a host device HDVi executing the accompanying application HSW. Such security devices are, for example, devices or equivalents sold by the applicant under the names "Ledger Blue," "Nano," or "Stax."

[0045] In another implementation, the personal security device PSDi and the host device HDVi form a single device, such as a so-called "blockchain" phone, including an integrated hardware wallet made of an integrated circuit security element or a Trusted Execution Environment (TEE) that simulates a security element. Such a phone executes a security application that ensures the execution of the steps described below.

[0046] In other implementations, the participating device PAI may be a portable or non-portable computing device connected to the server SRV1 via an application programming interface (“API”).

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

[0048] In one implementation, the Personal Security Device (PSDi), Module HSM1, and Module HSM2 are members of a Public Key Infrastructure (PA) managed by a Certification Authority (CA) that provides the public key PA. Each includes a private key (dPi, dH1, dH2, respectively), a static public key (PPi, PH1, PH2, respectively), and a certificate (CPi, CH1, CH2, respectively). The certificate is provided by the CA and includes their public key and a signature generated by the CA using their private key dA.

[0049] Since the validity of these certificates can be verified using the public key (PA) of a trusted authority, each device PSDi can establish a secure communication channel SC1i with module HSM1. Module HSM1 can establish a secure communication channel SC2 with module HSM2. Each device PSDi can also establish a secure communication channel SC3i with module HSM2. Here, the secure communication channel SC1i between device PSDi and module HSM1 is established via a secure data link https1. Here, the secure communication channel SC3i between device PSDi and module HSM1 is established via both secure data links https1 and https2. Here, the secure communication channel SC2 between modules HSM1 and HSM2 is established via a secure data connection https2.

[0050] Figure 4A , Figure 4B It shows the use of Figure 3 Two implementation schemes for the transaction signature method implemented in the system. Figure 4A In this process, after receiving the transaction description and verifying that the associated governance rules are met, module HSM1 typically transmits transaction T to module HSM2 in its original form, known as the "original transaction".

[0051] For example, a description of an Ethereum transaction can take the following form: { "coin": "eth "addr": "0x388c818ca8b9251b393131c08a736a67ccbl9297", "sender": "0x473780deaf4a2ac070bbba936b0cdefe7f267dfc", "amount": "0.000567202182620675", "maxGas": "0.00000005" } When the transaction in the example above is transformed into the original transaction, it may have, for example, the following values ​​(in hexadecimal): f86e826f4a8505f901eadd826b6c94388c818ca8b9251b393131c08a736a67ccbl92978801167140fda3d0818025a0dcbal464c58f31892b d0ae8e6271f838189cd344d98e928f3194efe4bce9ebc6a04fOfc71bee74ala6fafbel7cde3c35981c93b58703856ef5dd53884albl53773 Then, module HSM2, with the help of its signature service SIGN1, signs the original transaction T using the private key of the involved crypto-asset account derived from the master key K0 held in memory MEM, and generates a signature SIG1(T, K0) as a function of the original transaction T and the secret K0. Each signature algorithm is specific to the blockchain BCN under consideration. For example, the two major blockchains (Ethereum and Bitcoin) use the ECDSA / secp256k1 / SHA256 algorithm as the signature means, that is, the signature generated by the ECDSA algorithm (Elliptic Curve Digital Signature Algorithm) configured with the secp256k1 parameter, including a previous hash of the original transaction using the SHA-256 (Secure Hash Algorithm) function to obtain the transaction's "hash code" or digest. This algorithm produces the following types of signatures: { "r" "0xb91467e570a6466aa9e9876cbcd013baba02900b8979d43fe208a4a4f339f5fd", "s": "0x60 07e7 4cd82e037b8 0018 6422fc2dal67c7 4 7ef04 5e5dl8a5f5d4300f8ela02 9", "v": 28 } Then, transaction T and its signature SIG1 are transmitted to the broadcast service BCAST, causing it to broadcast the transaction on the relevant blockchain BCN. In this implementation, module HSM2 is aware of the transaction because it is sent to this module to generate signature SIG1. Therefore, the broadcast service BCAST can be executed by server SRV2 coupled to module HSM2, as... Figure 3As shown by the dashed line, transaction T is received from module HSM2. This broadcast service can also be performed by server SRV1, which is coupled to module HSM1. In this case, signature SIGN1 is transmitted from module HSM2 to module HSM1. In this method, the data link between modules HSM1 and HSM2 is implemented through a secure communication channel, an example of which will be described later.

[0052] Figure 4B Implementation plan and Figure 4A The implementation differs in that module HSM1 does not transmit the original transaction T to module HSM2. Instead, it transmits its digest or "hash code" HT, or a portion thereof, to module HSM2, which is generated by a hash function (such as the SHA-256 function). In other words, the first step in generating the signature (i.e., calculating its digest) is performed by module HSM1. In this case, module HSM1 also transmits to module HSM2 the information required for it to generate the transaction signature, such as the applicable derivation path DRV (Hierarchical Deterministic Derivation Path) and the signature function ECDSA or its identifier (module HSM2 typically has a directory of functions that may be needed to generate the signature in its memory). Transaction T and its signature SIG1 are then transmitted to the broadcast service BCAST as before, causing it to broadcast the transaction on the blockchain BCN.

[0053] In this implementation, module HSM2 is unaware of transaction T at this stage because the transaction has not been transmitted to this module to generate signature SIG1. Therefore, to improve system security, it can be decided to ensure that the transaction is never transmitted to the system, since the system does not need the transaction, and the transaction is also never transmitted to server SRV2 coupled to module HSM2. Therefore, the signature service can only transmit signature SIG1 to broadcast service BCAST. Then, transaction T is transmitted by module HSM1 to service BCAST. In this case, broadcast service BCAST cannot be executed by server SRV2, but by server SRV1, as follows... Figure 3 The solid line in the diagram is shown because the latter knows the transaction T.

[0054] In summary, the proposed shared transaction management system architecture includes two separate hardware security modules: the first applies governance rules and authorizes transaction signing when the rules are met, and the second signs the transactions. Figure 4B The implementation scheme stipulates that the hardware security module authorized to sign transactions cannot sign transactions itself because it does not possess the secret K0 that enables the transaction to be signed, and the hardware security module that signs the transaction is unaware of the transaction.

[0055] Figure 5 This illustrates the process of implementing governance rule recording methods. Figure 3 The system configuration. Server SRV2 and module HSM2 do not interfere with this process and are not shown. Figure 6 The flowchart illustrates the implementation of this method. In step G1, the administrator ADMi connects to the service ORCH of server SRV1 and requests configuration from the governance service GOV. In step G2, a secure communication channel SC1i is established between module HSM1 and the administrator ADMi's personal security device PSDi, and the personal security device PSDi connects to the governance service GOV. In step G3, the administrator defines one or more governance rules. In step G4, the administrator's personal security device PSDi sends the desired governance rules to the governance service via channel SC1i. In step G5, the governance service requests server SRV1's notification service NOTIF to send a notification to other administrators ADMi regarding voting on the governance rules. In step G6, a secure communication channel SC1i is established between the personal security modules PSDi of other administrators ADMi and the governance service. In step G7, the personal security devices PSDi of other administrators transmit their agreement or rejection of each proposed rule to the governance service. In step G8, the rules are adopted in whole or in part based on the administrators' votes.

[0056] Governance rules can be defined and adopted using various methods besides those described above. The arbitration set and majority rule adoption rules used to define governance rules can be "hard-coded" within the governance service. Governance rules can be simple, complex, unique, or multiple. For example, they can define the minimum number of unidentified operators who must approve transactions based on the type of crypto asset involved and / or the transaction amount, or define by name the operators who can approve transactions based on the type of crypto asset involved and / or the transaction amount. They can also define operators authorized to create transactions on the platform TPF for this type or similar crypto asset, as well as unauthorized operators who can only act as approvers of transactions.

[0057] In one implementation, the request for approval of governance rules issued by the administrator, which is then collected by the governance service, includes the following steps: - The governance service sends random challenges and governance rule descriptions to the other security devices (PSDi) of the administrators involved. - Each administrator's security device PSDi then displays a description of the governance rules to the corresponding administrator user USRi, collects user approval, and then signs the challenge with their private key dPi, sending the signed challenge to the governance service. - The governance service verifies the validity of the signature. If the signature is valid, the governance rule is considered to have been approved by the relevant administrator.

[0058] Figure 7 The key ceremony was shown Figure 3 The system configuration. Figure 8 The flowchart illustrates the steps of the key ceremony implementation. In step K1, the shared owner OWNi connects to the orchestrator service ORCH of server SRV1. In step K2, the shared owner OWNi activates the key ceremony service KCER1 via the orchestrator service. In step K3, the notification service NOTIF of server SRV1 sends an invitation to the ceremony to each other shared owner OWNi. In step K4, a secure communication channel SC3i is established between each shared owner OWNi's personal security device PSDi and the key ceremony service KCER1. In step K5, service KCER1 receives the master key K0i or a portion of the master key from each device PSDi. In step K6, service KCER1 generates a private key K0 from the received master key or a portion of the master key and stores it in memory MEM.

[0059] In one implementation, a fragment of the master key is generated using the derived function BIP32 m / code1' / key, where "m" is the master key. " / ": Indicates the separator between export levels "code1" is method-specific code, which can be arbitrary. "key" indicates the next level key derived from the parent key.

[0060] The master key K0 is then obtained by XORing all fragments derived from the master key of the device PSDi of the shared owner OWNi. The key for the crypto asset account is then derived from this key. For example, the extended private key or master key xprv for a Bitcoin account is conventionally generated by applying the HMAC-SHA512 hash algorithm to the key K0, which uses the term "Bitcoin seed" as the key and the term "master seed" as the message.

[0061] Figure 9 Described by means of Figure 3 The system executes transactions, and Figure 10 Described Figure 9 The steps are shown below. In the following text, the operator requesting approval for the transaction will be referred to as the "Approver APi" to distinguish them from the operator OPi or creator operator at the source of the transaction request.

[0062] In step S1, the operator OPi connects to the trading platform TPF. In step S2, the operator creates a transaction description. In step S3, the platform TPF sends a transaction request, including the transaction description, to the governance service GOV. In step S4, the governance service generates a transaction approval request for the approver APi, which is designated by applicable governance rules as permitted to approve the transaction request. An exemplary implementation of such approval requests from random queries will be described later.

[0063] At step S5, the governance service notifies the notification service of the transaction request via NOTIF. At step S6, the notification service sends transaction notifications to all relevant approver operators (APi) as specified by the applicable governance rules. At step S7, each approver Api's personal security device (PSDi) creates a secure channel (SC1i) with the governance service. Figure 3 In step S8, the governance service sends a transaction description and approval request to each approver APi's personal security device PSDi. In step S9, each approver APi checks and approves the transaction. This involves verifying the natural person user USRi of the transaction displayed by the personal security device PSDi. This step implements a 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 still involves the natural person performing an action on the human-machine interface of their personal security device to confirm their approval. In step S11, each approver's personal security device PSDi generates a transaction approval. In step S12, each approver's personal security device sends its transaction approval to the governance service GOV. Figure 9 As shown in the box labeled "SC1i", during steps S8 and S12, data transmission between the governance service and each device PSDi is performed using the secure channel SC1i. At step S13, the governance service GOV verifies the approval of transactions received from each device PSDi.

[0064] If the transaction approval conditions are met, specifically if the required arbitration set of approvers is reached, the system executes the step that appears in the "QR" box, meaning "arbitration set reached"; otherwise, the system executes the step that appears in the "QNR" box, meaning "arbitration set not reached". First, the steps appearing in the QR box will be described.

[0065] At step S20, the governance service generates the original transaction from the transaction description. However, this calculation of the original transaction performed by the governance service, as shown here, can be delegated to server SRV1 or any suitable external service.

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

[0067] In step S31, the governance service sends the original transaction T to the signature service SIGN1. Figure 4A The implementation scheme), or send it a digest of the original transaction HT, along with the derived path DRV and the identifier IDF of the signature function ( Figure 4B (Implementation scheme). The transmission of this data may be accompanied by a signature request, which may be implicit or command-based. In step S32, the signature service SIGN1 signs the original transaction.

[0068] In step S33, transaction T and its signature SIG1 are sent to the broadcast service BCAST. If the signature service is aware of transaction T, the transaction is provided by signature service SIGN1 along with its signature SIG1. Figure 4A The implementation plan). If the signature service does not know the transaction T ( Figure 4B In the implementation scheme described above, the transaction is transmitted by the governance service GOV of module HSM1 during step S33'. At step S34, the BCAST service places the signed transaction on the relevant blockchain BCN.

[0069] If the approval conditions provided by the applicable governance rules are not met (QNR box), the governance service erases the transaction from its memory at step S50. At step S51, it sends a transaction approval failure message to the notification service NOTIF. At step S52, the notification service sends a failure notification to the transaction platform, the creator, and the approver.

[0070] Figure 11 Described for use in Figure 3 The steps to create a secure channel between two entities in a system. Figure 12 Described Figure 11 The steps of the sequence diagram are as follows. Two entities are designated as X and Y. If entity X is a Personal Security Device (PSDi), then entity Y can be module HSM1 (Governance Service GOV) for creating channel SC1i, or module HSM2 (Signature or Key Ceremony Service) for creating channel SC3i. Entity X can also be module HSM1, and entity Y can be module HSM2 for creating channel SC2.

[0071] Each entity X and Y possesses a private key d. X d Y Public key P X P Y And Certificate C X C YThe certificate includes its public key and a signature made to it using the private key dA of a Certificate Authority (CA): C X = [P X , sign(P X , dA)] C Y = [P Y , sign(P Y , dA)] In step S60, entity X generates a temporary private key and a public key pair. X Pe X In step S61, entity X generates a temporary certificate Ce. X The temporary certificate includes its temporary public key, Pe. X and has its private key d X Signature: Ce X = [Pe X , sign(Pe X , d X )] In step S62, entity X sends its temporary public key Pe to entity Y. X Temporary Certificate Ce X Its public key P X and its certificate C X In step S63, entity Y verifies entity X's authentication chain: PA → C X (P X ) → Ce X (Pe X ) In fact, the certification authority's public key (PA) enables it to verify certificates that appear in the certificate (C). X The public key P in X The validity of the signature, and then the verified public key P. X This enables it to verify the temporary public key Pe that appears in the temporary certificate. X The validity of the signature.

[0072] If the verification is conclusive, then at step S64, entity Y generates a temporary private key and public key pair. Y Pe Y In step S65, entity Y generates a temporary certificate Ce. Y The temporary certificate includes its temporary public key, Pe. Y and has its private key d Y Signature: Ce Y = [Pe Y , sign(PeY , d Y )] At step S66, entity Y obtains its temporary private key from its private key via a key exchange function (such as, for example, the ECDH function (Elliptic Curve Diffie-Hellman Key Exchange)). Y And the temporary public key Pe of entity X X To generate a temporary session key k, that is: k = ECDH(de Y Pe X ) At step S67, entity Y sends its temporary public key Pe to entity X. Y and sending its temporary certificate Ce in encrypted form using key k. Y and its public key P Y Certificate C Y : Pe Y , {Ce Y C Y}k At step S68, entity X itself uses the same function as entity Y (here, the ECDH function) to decipher its temporary private key de X And the temporary public key Pe of entity Y Y Generate session key k: k = ECDH(de X Pe Y ) At step S69, entity X is therefore able to respond to message {Ce Y C Y Decrypt using}k.

[0073] In step S70, entity X verifies the authentication chain of entity Y: PA → C Y (P Y ) → Ce Y (Pe Y ) In other words, and as mentioned earlier, the certification authority's public key PA enables it to verify the certificate C. X The public key P in Y The validity of the signature, and then the authenticated public key P. Y This enables it to verify the temporary public key Pe that appears in the temporary certificate. Y The validity of the signature.

[0074] At step S71, the two entities have mutually authenticated themselves as belonging to the same public key infrastructure. The ephemeral session key k they jointly generate is non-replayable and unaffected by man-in-the-middle attacks. Therefore, it can be securely used to encrypt exchanged messages.

[0075] Although advantageous methods for creating secure channels based on Diffie-Hellman key exchange have been described herein, those skilled in the art can provide various other methods for forming secure channels SC1i, SC3i, and SC2, particularly based on symmetric cryptography techniques using private keys recorded in modules HSM1 and HSM2.

[0076] Figure 13 An implementation scheme for a method for approving transactions by the approver APi is described, and an example is shown. Figure 9 Steps S4, S7 to S13, plus steps S100 and S101 implemented when the operator has not approved the transaction. Figure 14 The implementation scheme is described. Figure 13 The steps.

[0077] In step S4, the governance service GOV generates a query C for transaction approval: C = RandomBytes(32) "RandomBytes(32)" is a known function that generates a 32-byte (256-bit) random data string.

[0078] At step S7, the governance service creates a secure channel SC1i with the approver APi's personal security device PSDi. At step S8, the governance service sends the transaction description and challenge C to the device PSDi. At step S9, the approver APi checks and approves the transaction. As mentioned above, this involves verifying the natural person user USRi of the transaction. At step S10, if the natural person approver has approved the transaction, they confirm their approval to the personal security device PSDi by performing an action on the personal security device PSDi. Figure 13 (The "Approval" box in the text). In step S11, device PSDi signs the challenge C with its private key dPi: S = Sign(dPi, C) In one variant, the transaction description can be cascaded with a query or any other data: S = Sign(dPi, C ||T) At step S12, device PSDi sends the signed challenge to the governance service. At step S13, the governance service verifies the signature S of the challenge. If the natural person approver instructs device PSDi to reject the transaction at step S100, the device returns an error message to the governance service during step S101.

[0079] Figure 15 The architecture of a second implementation of a trading system for shared management of crypto asset accounts is shown. This system is related to... Figure 3 The difference with this system is that it implements a multi-party signature algorithm, also known as the MPC (“Multi-Party Computation”) signature algorithm, through which a signature is generated by at least two parties. Therefore, in addition to the second hardware security module HSM2 coupled to the server SRV2, the system also includes at least one additional signature device SIGNDV.

[0080] Device SIGNDV is a secure device accessible via the Link Service LKS' performed by device DV3, such as an HSM-type secure device or a PSD-type device. If device SIGNDV is an HSM, then device DV3 is, for example, a server; or if device SIGNDV is a PSD, then device DV3 is a host device. The Link Service LKS' enables the establishment of a secure data link https3 between device SIGNDV and server SRV1. This link also enables operator OPi's personal secure device PSDi to establish a secure communication channel SC4i with module HSM2 via links https1 and https3. For this purpose, device SIGNDV is a member of the Public Key Infrastructure (PA) and includes a private key dD, a public key PD, and a certificate CD.

[0081] Device SIGNDV includes and executes a signature service MSIGN1, which uses an MPC signature share SH1 stored in memory MEM1. Similarly, module HSM2 includes and executes a signature service MSIGN2, which replaces the previously described service SIGN1 and uses a signature share SH2 stored in memory MEM2. Module HSM1 cannot access either memory MEM1 or MEM2. Module HSM2 cannot access the memory MEM1 of device SIGNDV, and device SIGNDV cannot access the memory MEM2 of module HSM2.

[0082] Each share SH1, SH2 is conventionally part of a shared secret and is generated during a key ceremony, during which services MSIGN1 and MSIGN2 exchange information via a secure channel. In some implementations, the key ceremony may include a step of drawing random numbers, thereby enabling the generation of shares SH1, SH2. In other implementations, the shared owner OWNi may participate in the key ceremony, such that their respective device PSDi's master key K0i is used to generate shares SH1, SH2.

[0083] Figure 16A , Figure 16B , Figure 16C and Figure 16D It shows the result of Figure 15 Several implementation schemes of the MPC signature method implemented in the system. Figure 16A and Figure 16B In the illustrated implementation, the MPC signature of the transaction is generated through accumulation. Signature service MSIGN2 provides signature SIG2, which is a function of signature SIG1 provided by signature service MSIGN1 and constitutes the transaction signature. Figure 16C and Figure 16D In the illustrated implementation, the MPC signature of the transaction is generated through combination. Signature service MSIGN1 provides a partial signature SIG1, and signature service MSIGN2 provides a partial signature SIG2. These two partial signatures are combined using the combination function Fmpc to obtain the transaction signature. This combination function can be executed by the broadcast service BCAST or any other service that can be provided upstream of the BCAST service for preparing signed transactions to be broadcast.

[0084] exist Figure 16A In one implementation, module HSM1 provides transaction T to the signature service MSIGN1 of device SIGNDV, and the latter provides signature SIG1 to module HSM2 as a function of transaction and share SH1. Signature service MSIGN1 provides transaction T and signature SIG1 to signature service MSIGN2, and the latter provides signature SIG2 as a function of transaction T, signature SIG1, and share SH2 to broadcast service BCAST. Alternatively, transaction T may be provided by module HSM1 to service MSIGN2. Service BCAST receives transactions from service MSIGN2, but may also receive transactions directly from module HSM1.

[0085] In this implementation scheme (where transaction T is known for different parts of the system), the broadcast service BCAST can be performed by server SRV1 coupled to module HSM1, such as Figure 15As shown by the solid line in the figure, or even executed by the server SRV2 coupled to module HSM2 or by the device DV3 coupled to the signature device SIGNDV, as Figure 15 As shown by the dashed line in the image.

[0086] exist Figure 16B In one implementation, module HSM1 provides the signature service MSIGN1 with a transaction digest HT, an appropriate derived path DRV, and an identifier IDF (or the signature function itself) of an appropriate signature function. Signature service MSIGN1 provides module HSM2 with a signature SIG1, which is the function of the digest HT and share SH1. Signature service MSIGN1 provides the digest HT, derived path DRV, identifier IDF, and signature SIG1 to signature service MSIGN2, which in turn provides the broadcast service BCAST with a signature SIG2, which is the function of the digest HT, signature SIG1, and share SH2. Alternatively, the digest HT, derived path DRV, and identifier IDF may be provided to service MSIGN2 by module HSM1. Service BCAST receives the transaction from module HSM1, but service MSIGN2 is unaware of the transaction.

[0087] In this implementation (where transaction T is unknown to the two signature services MSIGN1 and MSIGN2), the broadcast service BCAST can be executed by server SRV1 coupled to module HSM1. Therefore, as previously described, a system architecture is obtained in which the hardware security module authorized to sign transactions cannot itself sign transactions because it does not possess the secrets SH1 and SH2 that enable transaction signing, and the signature service signing the transaction is unaware of the transaction.

[0088] exist Figure 16C In the implementation scheme, module HSM1 provides transaction T to the signature service MSIGN1 of device SIGNDV and the signature service MSIGN2 of module HSM2. Signature service MSIGN1 provides a partial signature SIG1 to broadcast service BCAST as a function of transaction and share SH1. Signature service MSIGN2 provides a partial signature SIG2 to broadcast service BCAST as a function of transaction and share SH2. The BCAST service combines these two partial signatures using the Fmpc function to obtain the transaction signature. Transaction T can be provided to service BCAST by either signature device or by module HSM1.

[0089] In this implementation, although transaction T is known to different parts of the system, neither signing party can sign the transaction if the partial signature provided by the other party is unknown. It is likely preferable that the broadcast service BCAST is performed by server SRV1, coupled to module HSM1, such as... Figure 15The solid line in the diagram indicates that the broadcast service BCAST is not performed by one or the other of the two signatories.

[0090] exist Figure 16D In the implementation scheme, module HSM1 provides the transaction digest HT, the derived path DRV, and the identifier IDF of the signature function to the signature service MSIGN1 of device SIGNDV and the signature service MSIGN2 of module HSM2. Signature service MSIGN1 provides the broadcast service BCAST with a partial signature SIG1, which is a function of digest HT and share SH1. Signature service MSIGN2 provides the broadcast service BCAST with a partial signature SIG2, which is a function of digest HT and share SH2. Service BCAST combines the two partial signatures using the Fmpc function to obtain the transaction signature. Transaction T is here provided to the BCAST service by module HSM1.

[0091] In this implementation, the broadcast service BCAST can be performed by the server SRV1 coupled to module HSM1, such as... Figure 15 As shown by the solid line in the figure, a system architecture as described above is obtained, in which the hardware security module authorized to sign transactions cannot sign transactions itself because it does not possess the secrets SH1 and SH2 that enable transactions to be signed, and the signing service that signs transactions is unaware of the transactions.

[0092] Figure 17 It is a description based on Figure 16C or Figure 16D One of the implementation schemes is to rely on Figure 15 The system implements a sequence diagram of transactions. Figure 18 Described Figure 17 The steps of sequence diagrams. For example... Figure 17 As shown and by Figure 18 The described signature methods include those with Figure 9 The steps in the diagram are the same, namely, steps S1 to S20 and S50 to S52. This method is similar to... Figure 9 The essential difference in the method lies in the fact that steps S30 to S34, which involve signing and broadcasting the transaction, are replaced by steps S40 to S46. In step S40, the governance service GOV establishes a secure communication channel SC2a with the signing service MSIGN1 via link https3, and a secure communication channel SC2b with the signing service MSIGN2 via link https2. In step S41, the governance service sends the original transaction T(…) to the signing service MSIGN1 via the secure channel SC2a. Figure 16C Or send it its summary HT, export path DRV, and identifier IDF ( Figure 16DThe data is optionally accompanied by a signature request (which can be implicit or command-based). At step S41', the governance service sends the original transaction T to the signature service MSIGN2 via the secure channel SC2b. Figure 16C Or send it its summary HT, export path DRV, and identifier IDF ( Figure 16D This data may optionally be accompanied by a signature request (which may be implicit or command-based).

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

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

[0095] At this stage, the process is protected by a partial signature of the transaction, meaning that if the transaction is intercepted and altered by an attacker, the partial signature will be incorrect, and the final signature will also be incorrect. In fact, neither the HSM2 module nor the SIGNDV device can sign a transaction independently. Both signatures are required to sign a transaction.

[0096] In step S46, the service BCAST uses the Fmpc function to assemble partial signatures SIG1 and SIG2 together to obtain a transaction signature, and then broadcasts the signed transaction on the relevant blockchain BCN. If signatures SIG1 and SIG2 are generated from digest HT, then signature services MSIGN1 and MSIGN2 cannot transmit the original transaction T to the service BCAST. Then, a step can be provided where module HSM1 transmits transaction T to module BCAST, which is not included in the above steps. Figure 17 Presented in (see Figure 16D ).

[0097] It will be apparent to those skilled in the art that the implementation scheme of the enhanced security transaction system for shared management of crypto asset accounts, just described, is prone to various variations. In particular, a third or even fourth part signature device can be provided to generate multi-party signatures comprising three or more components.

Claims

1. A shared encrypted asset account management system, wherein, The request to execute a transaction on a shared cryptoasset account cannot be executed before receiving an approval from at least one approver and before the governance rules related to the execution of the transaction are satisfied, characterized in that the shared cryptoasset account management system comprises: - a transaction platform (TPF) executable by a server (SRV1) on which a transaction description can be created (S1, S2), the transaction platform being configured to issue a request to execute the transaction after the transaction is created, - a first hardware security module (HSM1) coupled to the transaction platform (TPF), the first hardware security module being configured to execute the governance rules related to the execution of the transaction, - a second hardware security module (HSM2), - a signing service (MSIGN1, MSIGN2) configured to generate a signature (SIG1, SIG2) of a transaction (T), the signing service comprising a first signing service (MSIGN1) executable by an intermediate signing device (SIGNDV) and configured to generate a first signature (SIG1) from first secret data (SH1), and a second signing service (MSIGN2) executable by the second hardware security module (HSM2) and configured to generate a second signature (SIG2) from second secret data (SH2), and - a memory (MEM2) receiving the second secret data (SH2), the memory (MEM2) being readable and writable by the second hardware security module (HSM2) and inaccessible to the first hardware security module (HSM1), the first hardware security module (HSM1) being configured to request an approval from at least one approver device (APi) and to verify that the governance rules applicable to the requested transaction are satisfied in response to a request to execute a transaction issued by the transaction platform, then, when the governance rules are satisfied, to transmit a request to sign the transaction at least to the first signing service (MSIGN1), the system being configured (HSM2, BCAST) to provide a multi-party signature as a function of the first signature (SIG1) and of the second signature (SIG2) as a transaction signature.

2. The system of claim 1, wherein, the first hardware security module (HSM1), the intermediate signing device (SIGNDV) and the second hardware security module (HSM2) being configured so 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 knowing the content of the transaction.

3. The system of one of claims 1 and 2, wherein, the second hardware security module (HSM2) being configured to generate the second signature from the first signature and from the second secret data (SH2), the second signature forming the transaction signature.

4. The system of one of claims 1 and 2, wherein, The first signature (SIG1) and the second signature (SIG2) are complementary, the system comprising a blockchain transaction broadcast service (BCAST) configured to combine (Fmpc) the first signature and the second signature to obtain the transaction signature.

5. The system according to one of claims 1 to 4, wherein, The first hardware security module (HSM1) is configured to transmit, at least to the intermediate signing device (SIGNDV), when the governance rule is fulfilled, a digest (HT) of the transaction (T) generated by a hash function, and to enable the intermediate signing device to generate from the digest complementary data of the first signature (SIG1).

6. The system of claim 5, wherein, The complementary data comprise a hierarchical deterministic derivation path (DRV) and a signature function to be used to generate the signature, or an identifier (IDF) of the function.

7. The system of 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, the second location being different from the first location.

8. The system of one of claims 1 to 7, wherein, The governance rule defines at least a number of approvals to be received from approver devices (OPi, APi) for the transaction to be signed and executed.

9. The system of one of claims 1 to 8, comprising at least one approver device (OPi, APi) comprising a cryptographic calculation means (PSDi) to establish a secure communication channel with the first hardware security module.

10. The system of claim 9, wherein, The first hardware security module (HSM1) and the approver device (OPi, APi) are members of a same public key infrastructure (PA) comprising a certification authority (CA) providing the public keys, and wherein the approver device and the first hardware security module (HSM) are configured to establish a secure communication channel between them by performing the following steps: - verifying by each entity that the other entity possesses a valid static certificate with respect to the public key of the public key infrastructure, - generating by each entity a temporary certificate comprising a temporary public key signed with the private key of the entity, - verifying by each entity that the temporary certificate of the other entity is valid with respect to its static certificate, - generating a session key (k) by Diffie-Hellman key exchange between the two entities and using the session key to encrypt the secure communication channel.

11. The system of one of claims 9 and 10, wherein, To send a transaction approval to the first hardware security module (HSM1), the approver device (OPi, APi) is configured to display a description of the transaction (S9) to a natural person user (USRi), to collect a user's approval (S10), to sign (S11) a challenge or data comprising the challenge received from the first hardware security module (HSM1) with a private key (dPi), and then to send (S12) the obtained signature to the first hardware security module.

12. A method for shared management of a cryptoasset account, wherein, The request to execute a transaction on a cryptoasset account cannot be executed before receiving an approval from at least one approver and before the governance rules related to the execution of the transaction are satisfied, characterized in that the method is implemented by means of a system comprising: a transaction platform (TPF) executable by a server (SRV1) on which a transaction description can be created (S1, S2), the transaction platform being configured to issue a request to execute the transaction after the transaction is created, a first hardware security module (HSM1) coupled to the transaction platform (TPF), the first hardware security module being configured to execute the governance rules related to the execution of the transaction, 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 first secret data (SH1), and a second signature service (MSIGN2) executed by the second hardware security module (HSM2) and configured to generate a second signature (SIG2) from second secret data (SH2), and a memory (MEM2) receiving the second secret data (SH2), the memory (MEM2) being readable and writable by the second hardware security module (HSM2) and inaccessible to the first hardware security module (HSM1), and characterized in that the method comprises the following steps: in response to a request to execute a transaction issued by the transaction platform, requesting, by means of the first hardware security module (HSM1), an approval from at least one approver device (APi) and verifying that the governance rules applicable to the requested transaction are satisfied, when the governance rules are satisfied, transmitting a request to sign the transaction to at least the first signature service (MSIGN1), generating the first signature (SIG1) by means of the first signature service (MSIGN1), generating the second signature (SIG2) by means of the second signature service (MSIGN2), and generating a multipartite signature as a function of the first signature (SIG1) and the second signature (SIG2), the multipartite signature forming the transaction signature.

13. 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 knowing the content of the transaction.

14. The method according to one of claims 12 and 13, wherein, 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 transaction signature.

15. The method according to one of claims 12 and 13, wherein, 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 to obtain the transaction signature.

16. The method according to one of claims 12 to 15, comprising the step consisting in transmitting, by means of the first hardware security module (HSM1), at least to the intermediate signing device (SIGNDV), when the governance rule is fulfilled, a digest (HT) of the transaction (T) generated by a hash function, and complementary data enabling the first signature (SIG1) to be generated from the digest.

17. The method of claim 16, wherein, The complementary data comprise a hierarchical deterministic derivation path (DRV) and a signing function to be used to generate the signature, or an identifier (IDF) of the function.

18. The 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, the second location being different from the first location.

19. The method according to one of claims 12 to 18, wherein, The governance rule authorizes the signature of the transaction based on the number of approvals to be received from approver devices (OPi, APi).

Images