Transaction methods and systems for secure multi-party computation

Abstract

This invention provides a transaction method and system based on multi-party secure computation. The method includes: upon receiving transaction information, obtaining the client's authorization request and encrypting and sending it to a server cluster; the server cluster verifies the client's identity, generates a user authorization credential, encrypts it, and sends it back to the client; the client generates initial signature information, generates session information, encrypts it, and sends it to the server cluster; the server cluster verifies the validity of the signature, decrypts it, and adds a secure signature to generate secure signature information, which is then encrypted and sent to a hardware security node; the hardware security node verifies the permissions, signs the secure signature information using a hardware key, obtains a signature result, and encrypts it, sending it back to the server cluster; the server cluster aggregates the signatures to generate a final valid signature and broadcasts it to the blockchain network. This method, through multi-party secure computation and aggregation rules, synthesizes a final valid signature for transaction processing, ensuring that the complete private key is never reconstructed or stored at any time, significantly improving transaction security.

Description

Technical Field

[0001] This invention relates to the field of online payment technology, and in particular to a transaction method and system for multi-party secure computation, applicable to commercial settlement application scenarios. Background Technology

[0002] In blockchain-based cryptocurrency trading applications, a client-server interaction model is typically used to send and execute transaction instructions. To ensure data transmission security, existing technologies generally encrypt transaction information on either the client or server side, establishing a communication link using asymmetric encryption algorithms or symmetric key mechanisms. The encrypted transaction data is then transmitted over the network to the server for decryption and signature verification. Subsequently, the server or hardware device holding the complete private key generates a digital signature and broadcasts it to the blockchain network to complete settlement. However, in existing technologies, because the encryption process often relies on a single end, and the complete user private key is usually stored centrally on a single node or device, there is a risk of exposure or tampering in the data transmission link or key storage. Once this single point is breached, user assets can easily be lost, and the overall security of the transaction process faces a serious challenge. Therefore, existing technologies for cryptocurrency trading suffer from insufficient transaction security. Summary of the Invention

[0003] This invention provides a transaction method and system for multi-party secure computation, aiming to solve the problem of insufficient transaction security in existing technical methods for crypto asset transactions.

[0004] In a first aspect, embodiments of the present invention provide a transaction method for multi-party secure computation. The method is applied to a transaction system comprising a client, a server cluster, and a hardware security node. The client communicates with the server cluster to transmit data, and the server cluster communicates with the hardware security node and a blockchain network. The server cluster consists of multiple service nodes. The method includes: The client receives transaction information input by the user, obtains an authorization request corresponding to the client, and sends it to the server cluster through the first encrypted transmission channel; The server cluster verifies the identity of the authorization request. If the identity verification is successful, it generates a user authorization credential corresponding to the authorization request and sends it back to the client through the first encrypted transmission channel. The client generates initial signature information corresponding to the transaction information based on the preset signature policy and the user authorization credentials; The client generates session information based on the transaction information, the initial signature information, and the user authorization credential, and sends it to the server cluster through the first encrypted transmission channel. The server cluster performs a validity check on the session information. If the check is valid, it decrypts the information to obtain the plaintext transaction information corresponding to the session information. The server cluster signs the plaintext transaction information according to a preset signing strategy, generates corresponding secure signing information, and sends it to the hardware security node through the second encrypted transmission channel. The hardware security node performs permission verification on the security signature information. If the permission verification shows that the node has permission, it obtains the hardware key corresponding to the security signature information, signs the security signature information to obtain a signature result, and feeds it back to the server cluster through the second encrypted transmission channel. The server cluster aggregates the session information, the security signature information, and the signature result according to preset aggregation rules to generate a final valid signature; The server cluster broadcasts the transaction information in the session information and the final valid signature to the blockchain network to complete the transaction settlement.

[0005] Secondly, embodiments of the present invention also provide a multi-party secure computation transaction system, the transaction system including a client, a server cluster and a hardware security node; the client communicates with the server cluster to realize the transmission of data information, the server cluster communicates with the hardware security node and the blockchain network, the server cluster is composed of multiple service nodes, and the transaction system is used to execute the multi-party secure computation transaction method as described in the first aspect; The transaction system includes an authorization request sending unit, an initial signature information acquisition unit, and a session information generation unit configured on the client; a user authorization credential sending unit, a legality verification unit, a security signature information generation unit, an aggregation processing unit, and a broadcast unit configured on the server cluster; and a signature result acquisition unit configured on the hardware security node. The authorization request sending unit is used to receive transaction information input by the user, obtain the authorization request corresponding to the client, and send it to the server cluster through the first encrypted transmission channel; The user authorization credential sending unit is used to verify the identity of the authorization request. If the identity verification is successful, it generates a user authorization credential corresponding to the authorization request and sends it back to the client through the first encrypted transmission channel. The initial signature information acquisition unit is used to generate initial signature information corresponding to the transaction information according to the preset signature strategy and the user authorization certificate; The session information generation unit is used to generate session information based on the transaction information, the initial signature information and the user authorization credential, and send it to the server cluster through the first encrypted transmission channel. The validity verification unit is used to perform validity verification on the session information. If the verification is valid, the unit decrypts the plaintext transaction information corresponding to the session information. The secure signature information generation unit is used to sign the plaintext transaction information according to a preset signature strategy, generate corresponding secure signature information, and send it to the hardware security node through the second encrypted transmission channel. The signature result acquisition unit is used to perform permission verification on the security signature information. If the permission verification shows that the user has permission, the unit obtains the hardware key corresponding to the security signature information, signs the security signature information to obtain a signature result, and feeds it back to the server cluster through the second encrypted transmission channel. The aggregation processing unit is used to aggregate the session information, the security signature information and the signature result according to the preset aggregation rules to generate a final valid signature; The broadcasting unit is used to broadcast the transaction information in the session information and the final valid signature to the blockchain network to complete the transaction settlement.

[0006] Thirdly, embodiments of the present invention also provide an electronic device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect above.

[0007] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, can implement the method described in the first aspect.

[0008] This invention provides a transaction method and system based on multi-party secure computation. The method includes: upon receiving transaction information, obtaining the client's authorization request and encrypting and sending it to a server cluster; the server cluster verifies the client's identity, generates a user authorization credential, encrypts it, and sends it back to the client; the client generates initial signature information, generates session information, encrypts it, and sends it to the server cluster; the server cluster verifies the validity of the signature, decrypts it, and adds a secure signature to generate secure signature information, which is then encrypted and sent to a hardware security node; the hardware security node verifies the permissions, signs the secure signature information using a hardware key, obtains a signature result, and encrypts it, sending it back to the server cluster; the server cluster aggregates the signatures to generate a final valid signature and broadcasts it to the blockchain network. This method, through multi-party secure computation and aggregation rules, synthesizes a final valid signature for transaction processing, ensuring that the complete private key is never reconstructed or stored at any time, significantly improving transaction security. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 A flowchart illustrating the transaction method for multi-party secure computation provided in an embodiment of the present invention; Figure 2 A schematic block diagram of a transaction system for multi-party secure computation provided in an embodiment of the present invention; Figure 3 A schematic block diagram of an electronic device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating an application scenario of the multi-party secure computation transaction method provided in an embodiment of the present invention. Detailed Implementation

[0011] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0012] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0013] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0014] It should also be further understood that the term "and / or" as used in this specification and appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations. Embodiments of this invention provide a transaction method and system for multi-party secure computation. For specific application scenarios of this multi-party secure computation transaction method, please refer to... Figure 4 , Figure 4This is a schematic diagram illustrating an application scenario of the multi-party secure computation transaction method provided in an embodiment of the present invention. The multi-party secure computation transaction method is applied in, for example... Figure 4 In application scenarios, specifically, the multi-party secure computation transaction method is applied to a transaction system 100, which includes a client 10, a server cluster 20, and a hardware security node 30. The client 10 communicates with the server cluster 20 to transmit data information, and the server cluster 20 communicates with the hardware security node 30 and the blockchain network 40. The server cluster 20 consists of multiple service nodes 21. The client 10 is a terminal device for personal use, such as a desktop computer, laptop, tablet, or mobile phone. The server cluster 20 is a server cluster composed of multiple servers. The hardware security node 30 is a hardware security module, a dedicated physical hardware encryption device specifically used to securely generate, store, and manage encrypted private keys, key fragments, and certificates. The key never leaves the hardware, cannot be exported, and cannot be tampered with. The blockchain network 40 is a distributed hardware network formed by the interconnection of multiple blockchain nodes. The invention will now be described in detail through specific embodiments.

[0015] Figure 1 This is a flowchart illustrating a multi-party secure computation transaction method provided in an embodiment of the present invention. This transaction method can be applied to application scenarios of aggregated exchange and payment of digital currencies, and also to application scenarios of exchange and payment of physical currencies. Figure 1 As shown, the method includes the following steps S110-S190.

[0016] S110. The client receives the transaction information input by the user, obtains the authorization request corresponding to the client, and sends it to the server cluster through the first encrypted transmission channel.

[0017] The transaction information refers to the specific parameters of the transaction to be executed, which are entered by the user on the client interface. This information includes the payee's address, payer's address, exchange rate, transaction amount, and currency. Based on the user's input, corresponding transaction path parameters are matched, and a timestamp is generated to obtain the transaction information. Therefore, the transaction information includes the user's input information, transaction path parameters, and timestamp. The authorization request is an authentication data packet constructed by the client to initiate a transaction. Its sources include the user's account, password, client IP address, transaction digest obtained by hashing the transaction information, and SMS verification code or secondary token. The first encrypted transmission channel is a secure communication link established between the client and the server cluster. Its function is to ensure the confidentiality and integrity of data during transmission over the public network. Specifically, the first encrypted transmission channel is built based on the bidirectional TLS (mTLS) protocol, using a negotiated unique AES session key (i.e., the first session private key) to perform symmetric encryption on the data. For example, after receiving a user's transfer instruction, the client assembles the user ID, transaction amount, and dynamic verification code into an authorization request. This request is then encrypted using a pre-negotiated first-session private key and sent to the server cluster via a TCP connection. This multi-layered identity verification data encapsulation and secure channel transmission effectively prevents malicious attacks, ensuring that only legitimate user requests proceed to subsequent processing.

[0018] In a specific embodiment, before step S110, the method further includes the steps of: establishing a first encrypted transmission channel between the client and the server cluster; and establishing a second encrypted transmission channel between the server cluster and the hardware security node.

[0019] Before transmitting information, a first encrypted transmission channel and a second encrypted transmission channel can be constructed separately. The first encrypted transmission channel, which is the encrypted link used to ensure secure data communication between the client and the server cluster, is built based on the bidirectional TLS (mTLS) protocol. The establishment process of this channel includes three stages: certificate pre-issuance, bidirectional authentication, and session key negotiation. Specifically, the certificate management node in the server cluster pre-configures the root CA certificate and generates digital certificates containing public and private keys for both the client and the communication service node in the server cluster that communicates with the client. The client's private key is encrypted and stored in the local key management system, while the communication service node maintains the root CA trust store. When the connection is established, the client initiates a TCP connection request, the communication service node issues its TLS certificate chain, and the client verifies the signature validity, validity period, and domain name matching of the certificate. Subsequently, the communication service node requests the client to present its certificate, the client sends its own certificate chain, and the server cluster verifies its CA signature, authorization purpose, and device identifier. Only when both certificates pass verification is the identity deemed legitimate. After successful authentication, both parties generate temporary elliptic curve key pairs using the ECDHE algorithm and exchange temporary public keys. Based on their local private keys and the other party's public keys, they calculate the same shared secret seed, thereby deriving a unique first session private key (i.e., an AES symmetric key) for encrypted transmission of subsequent communication content. For example, when a client establishes a connection with a communication service node in the server cluster, if the communication service node detects that the client's connection certificate is not on the whitelist or has been revoked, it immediately disconnects the connection, effectively resisting malicious attacks. This dual certificate verification mechanism ensures the authenticity and trustworthiness of the communication entity, laying the foundation for the secure transmission of subsequent authorization requests.

[0020] Furthermore, the second encrypted transmission channel is a dedicated encrypted link used to ensure secure command and data exchange between the server cluster and the Hardware Security Node (HSM). Its construction principle is similar to the first encrypted transmission channel, also employing a bidirectional TLS protocol. This channel requires the signing service node and the hardware security node in the server cluster to mutually verify the legitimacy of their certificates. Specifically, the hardware security node internally stores its TLS certificate (HSM-side certificate) and private key. The private key cannot be exported and is only used within the HSM's internal TLS module. Simultaneously, the HSM has a built-in root CA certificate trust store, trusting only service node certificates issued by the same root CA. The service node, on the other hand, stores its TLS certificate (service node certificate) and private key encrypted in an application-specific trust pool. During the handshake process, the hardware security node issues a certificate for the service node to verify and mandates that the service node return a certificate for reverse verification. The verification includes the certificate signature, validity period, IP whitelist, and device identifier. Both parties generate an independent second session private key through ECDHE key negotiation. This key is only valid within the current connection session and does not reuse historical keys. For example, if the hardware security node discovers that the certificate IP address provided by the service node is not in the whitelist, it will refuse to establish a connection and terminate the handshake process. By constructing this second encrypted transmission channel, the confidentiality and integrity of highly sensitive data such as transaction plaintext information, signature information, and signature results are ensured when transmitted between the server cluster and the hardware security node, preventing key fragments from being exposed or tampered with during transmission.

[0021] This application establishes a dual security protection system covering the entire link from client to server cluster to hardware security node by pre-constructing a first encrypted transmission channel and a second encrypted transmission channel. The first encrypted transmission channel utilizes a two-way certificate verification mechanism to ensure the secure transmission of user authorization requests and initial signature information in the public network environment, effectively blocking the access of unauthorized terminals. The second encrypted transmission channel further establishes a financial-grade trusted link between the core processing area and the hardware security area, ensuring the absolute security of the private key sharding interaction process. Both channels use dynamically negotiated session keys (first session private key and second session private key), achieving one-time pad security, so even if the session key is leaked in one session, it will not affect the security of other sessions. On this basis, the first encrypted transmission channel provides a trusted data input source for subsequent identity verification, while the second encrypted transmission channel provides a protected instruction transmission path for hardware security nodes to perform permission verification and secure signatures. The two work together to form the communication security cornerstone of the multi-party secure computation transaction method, significantly improving the entire transaction system's ability to resist malicious attacks, replay attacks, and spoofed node access.

[0022] S120. The server cluster verifies the identity of the authorization request. If the identity verification is successful, it generates a user authorization credential corresponding to the authorization request and sends it back to the client through the first encrypted transmission channel.

[0023] After receiving an authorization request, the server cluster verifies the user's identity to determine whether the verification is successful. If successful, a user authorization credential corresponding to the authorization request is generated and sent to the client. Since a first encrypted transmission channel has been established between the server cluster and the client, the transmission of the user authorization credential relies on this channel. The identity verification process involves the verification service nodes in the server cluster comparing the legality of the transaction account information, password, and verification code contained in the authorization request. The user authorization credential is a one-time authorization token generated after successful identity verification. It includes fields such as the authorization validity period, the bound transaction digest, and the user ID, used to prove that the user has been authorized and to restrict the transaction scope (such as the amount limit or the whitelist of called contracts) in subsequent transactions. This credential is generated based on preset authorization parameters, specifically by combining the authorization validity period, transaction digest, and user ID and performing a hash operation. For example, after the server cluster verifies that the user's password and SMS verification code are correct, a temporary token with a validity period of 5 minutes is generated and encrypted using the first session private key corresponding to the first encrypted transmission channel. The encrypted user authorization credential information is then sent to the client. This step aims to achieve reliable identity verification and reduce the risk of exposing the master private key. By setting time and amount limits on user authorization credentials, it ensures that subsequent operations are only valid within a specific context.

[0024] In a specific embodiment, step S120 includes the following sub-steps: the verification service node in the server cluster verifies the transaction account information in the authorization request to obtain an identity verification result; if the identity verification result is successful, a user authorization credential corresponding to the authorization request is generated according to the preset authorization parameters; the user authorization credential is encrypted according to the first session private key corresponding to the first encrypted transmission channel to obtain the corresponding encrypted user authorization credential information and feed it back to the client through the first encrypted transmission channel.

[0025] Specifically, the verification service node is a functional unit within the server cluster dedicated to identity verification. Transaction account information refers to the character sequence entered by the user on the client or stored locally to identify the user, including the user ID, verification code, registered mobile phone number, email address, and the associated digital wallet address. This verification process aims to confirm whether the entity initiating the transaction request is a legitimate registered user. Specifically, the verification service node compares the received transaction account information with the digital wallet account status in a pre-stored whitelist database or blockchain ledger, checking if the account exists, is frozen, and if the verification code or biometric information (such as facial recognition) matches. If the comparison matches and the account status is normal, the identity verification result is considered successful; otherwise, if the account does not exist, has been cancelled, or one piece of information is incorrect, it is considered unsuccessful. For example, when the user enters the user ID User_12345, the verification service node searches the database and finds that the corresponding digital wallet account is marked as active, and the provided verification code matches the system's sent record, thus generating a successful identity verification result. This verification mechanism effectively blocks access requests from unauthorized users, ensuring the security of the transaction system's entry point from the source.

[0026] Furthermore, the user authorization credential, also known as a one-time token generated by the server cluster after successful identity verification, is used to prove that the user has obtained temporary authorization in subsequent transactions. This credential has time-limited, binding, and scope-restricted characteristics. Pre-defined authorization parameters include the authorization validity period (TTL), transaction digest hash value, user unique identifier (user ID), a whitelist of allowed smart contracts, and the maximum allowed transaction amount. The user authorization credential is obtained by combining the field values ​​corresponding to the fields included in the above authorization parameters into a string according to preset rules, and then performing a hash operation on this combined string. Specifically, the system concatenates the authorization expiration time (determined based on the correspondence between the current time and the authorization validity period), the hash value of the transaction information (such as a SHA-256 digest), the user ID, the whitelist of smart contracts matching the authorization request, and the maximum allowed transaction amount to generate an irreversible encrypted string as the credential content. The purpose of this credential is to limit the upper limit of the transaction amount, the validity period, and the scope of operable contracts without exposing the user's master private key. For example, by setting the authorization validity period to 300 seconds, allowing calls only to specific transfer contracts, and limiting the maximum transaction amount to 1000 (e.g., in YUAN currency), the system combines these parameters to generate a hexadecimal token string. This dynamically generated and strictly constrained credential mechanism achieves fine-grained access control. Even if the credential is intercepted, attackers cannot use it outside the validity period or beyond the specified scope, thus significantly reducing the risk of exposing the master private key.

[0027] Furthermore, the first session private key is a temporary symmetric key (such as an AES key) negotiated through a two-way TLS handshake protocol when the client and server cluster establish the first encrypted transmission channel. This key is only valid during the current session and expires after the session ends. It is not directly transmitted over the network but is calculated locally by each communicating party using the Elliptic Curve Diffie-Hellman (ECDHE) algorithm. The encrypted user authorization credential information is the ciphertext data obtained by symmetric encryption of the user authorization credential using the first session private key. Specifically, the server cluster calls the encryption module, employing encryption algorithms such as AES-GCM or AES-CBC, using the first session private key as the key, to encrypt the generated plaintext user authorization credential, generating a ciphertext packet. Subsequently, the server cluster encapsulates this ciphertext packet in an HTTPS response message and sends it back to the client through the established first encrypted transmission channel.

[0028] This application achieves multi-layered security protection by rigorously verifying transaction account information through verification service nodes, combining this with user authorization credentials generated based on pre-set authorization parameters and constrained by conditions, and encrypting the credentials using the first session private key negotiated through the first encrypted transmission channel. The verification step ensures the legitimacy of the requesting entity; the user authorization credential generation step limits the risk of credential abuse by introducing constraints on validity period, amount, and contract scope; and the encryption step relies on a secure key negotiation mechanism to guarantee the confidentiality of the transmission channel. The synergistic effect of these three elements enables the system to accurately identify legitimate users during the identity authentication phase while ensuring the security of authorization credentials throughout the generation, transmission, and use process. This effectively resists security risks caused by replay attacks, malicious attacks, and credential leakage, laying a solid security foundation for subsequent transaction signing and settlement.

[0029] S130, The client generates initial signature information corresponding to the transaction information according to the preset signature policy and the user authorization certificate.

[0030] The client generates initial signature information corresponding to the transaction information using a pre-configured signature policy and received user authorization credentials. The signature policy is side information pre-installed on the client and used for partial signing. It includes a ratio determination rule and the client's private key (i.e., the private key fragment A allocated to the client in the distributed key generation protocol). The initial signature information is a partial signature result generated by the client after partially signing the transaction data. The specific generation process includes: first, assembling the client's terminal information (such as MAC address and IP address), transaction information, and user authorization credentials to generate transaction assembly data; second, encrypting the transaction assembly data using the first session private key to obtain encrypted transaction information and generating a corresponding first digest; then, determining the signature ratio according to the ratio determination rule in the signature policy, which can be calculated by taking the remainder of the hexadecimal string of the user authorization credentials; finally, partially signing the first digest using the client's private key and the determined signature ratio to obtain the initial signature information.

[0031] In a specific embodiment, step S130 includes the following sub-steps: assembling the client's terminal information, the transaction information, and the user authorization credential to generate corresponding transaction assembly data; encrypting the transaction assembly data according to the first session private key corresponding to the first encrypted transmission channel to obtain corresponding transaction encrypted information; generating a first digest corresponding to the transaction encrypted information; determining the signature ratio corresponding to the user authorization credential according to the ratio determination rule in the signature strategy; and partially signing the first digest according to the client private key in the signature strategy and the signature ratio to obtain corresponding initial signature information.

[0032] Specifically, terminal information is a set of data used to uniquely identify the hardware characteristics and network environment of the client device, including the client device's MAC address, IP address, device serial number, and digital wallet address; transaction information includes the payee's address, payer's address, exchange rate, transaction amount, currency, transaction path parameters, and timestamp; the user authorization credential is a one-time token generated by the server cluster after successful identity verification, with validity period, amount limits, and contract call scope restrictions. Transaction assembly data is obtained by serializing and concatenating the aforementioned terminal information, transaction information, and user authorization credential according to a pre-defined data structure format. For example, the MAC address and IP address can be used as header information, followed by core transaction fields such as the transaction amount and payee's address, and finally appended with the hexadecimal string of the user authorization credential, forming a continuous binary data stream. This assembly method binds the terminal information, transaction content, and user authorization credential together, ensuring that the object of subsequent signature operations contains complete context information, preventing replay attacks or tampering.

[0033] Furthermore, the first session private key is a temporary symmetric key (such as an AES key negotiated based on the ECDHE algorithm) negotiated through a two-way TLS handshake protocol when the client and server cluster establish the first encrypted transmission channel. The encrypted transaction information is ciphertext data obtained by encrypting the assembled transaction data using a symmetric encryption algorithm (such as AES-256-GCM) and the first session private key. This first session private key is valid for a single session and is regenerated each time a new encrypted transmission channel is established, without reusing historical keys. For example, when the client initiates a new transaction request, both parties re-perform the TLS handshake, generate a new random number seed to derive the first session private key, and use this key to encrypt the assembled data. By using this session private key for encryption, it is ensured that even if the assembled transaction data is intercepted during the transmission from the client to the server cluster, it cannot be decrypted, thus guaranteeing the confidentiality of the data during the transmission link.

[0034] Furthermore, the first digest is a fixed-length digital fingerprint obtained by hashing the encrypted transaction information. Specifically, the client calls a pre-defined hash algorithm (such as SHA-256 or SM3), using the encrypted transaction information as input data, and calculates and outputs a fixed-length hash value. For example, if the length of the encrypted transaction information is arbitrary bytes, after SHA-256 operation, the generated first digest will be fixed at 256 bits (32 bytes). This first digest is used to characterize the integrity of the encrypted transaction information; any minor modification to the original encrypted information will cause a significant change in the first digest, thus providing an accurate and tamper-proof data object for subsequent partial signatures.

[0035] Furthermore, the ratio determination rule is a dynamic calculation mechanism used to determine the proportion of data segments participating in the signature based on the reception time of the user authorization credential. The signature ratio is calculated based on the client's reception time of the user authorization credential and the numerical characteristics of the user authorization credential itself. Specifically, firstly, the system time when the client receives the user authorization credential is obtained and converted into a hexadecimal string; simultaneously, the user authorization credential itself is also a hexadecimal string. Since the reception time of the user authorization credential is highly random, the obtained signature ratio is also highly random, significantly increasing the difficulty of cracking partial signatures and improving the security of the transaction process. Next, the hexadecimal string of the converted time is moduloed by the hexadecimal string of the user authorization credential, and the last digit of the remainder is extracted (if the last digit is zero, the digit preceding the last digit is taken); finally, the extracted number is divided by a preset fixed value (e.g., 30), and the result is the signature ratio. For example, assuming the last digit of the hexadecimal string of the received time moduloed by the user authorization credential is 9, and the fixed value is 30, then the calculated signature ratio is 9 / 30, or 0.3. By using this dynamic calculation method based on time and credential content, the signing ratio for each transaction is different, which increases the difficulty for attackers to predict signing behavior and realizes the randomization and dynamism of the signing strategy.

[0036] Furthermore, the client's private key, which is a fragment of the private key (i.e., private key fragment A) generated and stored locally on the client during the Distributed Key Generation (DKG) phase, is not the complete user private key, but only a part of it. Partial signing means that only the portion of the data in the first digest that meets the signature ratio is signed, rather than signing the entire first digest. The initial signature information is generated by using a threshold signature protocol (such as Threshold ECDSA) to perform encryption operations on a specific fragment extracted from the first digest using the client's private key. Specifically, if the total length of the first digest is 32 bytes, and the calculated signature ratio is 0.3, the system extracts the first 10 bytes of the first digest (32 × 0.3 = 9.6, rounded to the nearest integer) as the data to be signed, and uses the client's private key to perform a signature operation on this 10-byte data to generate the initial signature information. Throughout this process, the client's private key remains within the client's secure area and does not participate in the reconstruction of the final valid signature; it only contributes to the fragmentation function. By using this partial signature mechanism, combined with the fragmented signatures of subsequent service nodes and hardware security nodes, a valid signature can be synthesized without exposing the complete private key, effectively avoiding the risk of single-point private key leakage and improving the overall security of the system.

[0037] This application achieves secure and controllable initial signature generation on the client side through the synergistic effect of the aforementioned technical features. Specifically, by assembling and encrypting terminal information, transaction information, and user authorization credentials, the integrity and confidentiality of the signature source data are ensured. Furthermore, by utilizing dynamically changing signature ratio rules, the digest fragment used by the client's private key is different in each transaction, breaking the regularity of the traditional fixed signature mode. On this basis, combined with the fact that the private key fragments stored on the client only sign a partial digest, the core idea of ​​multi-party secure computation (MPC) is reflected, namely, no single point of contact holds the complete private key. This mechanism not only prevents the client's private key from being maliciously modified or abused, but also increases the cost of brute-force and predictive attacks through dynamic ratios, thereby significantly improving the transaction system's resistance to attacks and privacy protection level while ensuring the legality of transactions.

[0038] S140, The client generates session information based on the transaction information, the initial signature information and the user authorization credential, and sends it to the server cluster through the first encrypted transmission channel.

[0039] Further, based on the transaction information, initial signature information, and user authorization credentials, corresponding session information is generated, and the session information is again encrypted and transmitted through the first encrypted transmission channel. The user authorization credentials are the credentials obtained in the previous steps used to authorize this transaction. The session information is a data transmission packet formed by logically combining the encrypted transaction information, the first digest, the initial signature information, and the user authorization credentials. This step is executed by encapsulating the various data fragments generated in the previous steps according to a predefined data structure. For example, the client packages the encrypted transaction information, the first digest generated in step S130, the initial signature information based on the private key fragment A signature, and the currently valid user authorization credentials to form complete session information, and sends it to the server cluster again through the first encrypted transmission channel. This result provides a complete data foundation for subsequent server cluster verification and multi-party collaborative signing, ensuring the consistency and immutability of the transaction context.

[0040] In a specific embodiment, step S140 includes the following sub-steps: obtaining transaction encryption information and a first digest corresponding to the transaction information; combining the transaction encryption information, the first digest, the initial signature information and the user authorization credential to obtain the corresponding session information and sending it to the server cluster through the first encrypted transmission channel.

[0041] Specifically, the transaction encryption information is the ciphertext data obtained by the client using the first session private key negotiated with the first encrypted transmission channel to symmetrically encrypt the transaction assembly data, which contains terminal information, transaction information, and user authorization credentials. The first digest is a fixed-length feature value generated by calculating the transaction encryption information using a hash algorithm (such as SHA-256), used for integrity verification and fragmented signature in subsequent multi-party signature processes. Specifically, the transaction encryption information originates from the encryption operation performed by the client according to a pre-defined signature strategy. Its purpose is to ensure the confidentiality of the original transaction content during transmission to the server cluster and prevent information leakage due to malicious attacks. The first digest is generated by performing a one-way hash mapping on the encrypted data, providing standardized input data blocks for subsequent partial signatures. For example, if the transaction assembly data is encrypted in AES-GCM mode to obtain transaction encryption information of 1024 bytes, then a first digest of 32 bytes (256 bits) is calculated using the SHA-256 algorithm. This first digest will be used as the object for threshold signature by the client, service node, and hardware security node. By acquiring these two key data points, a data foundation is laid for constructing session information containing complete contextual information.

[0042] Furthermore, combining multiple sets of information involves encapsulating the four independent data units into a complete logical data packet according to a predefined data structure protocol. The initial signature information is a partial signature generated by the client using its private key fragmentation and a dynamically calculated signature ratio based on the authorization credential to partially sign the first digest. The user authorization credential is a one-time token issued by the server cluster after successful identity verification, with time-limited validity and restricted access. The session information is generated by using the encrypted transaction information as the payload, the first digest as the verification index, the initial signature information as the client-side signature contribution, and the user authorization credential as the authentication basis; these four elements together constitute an indivisible transaction context. The purpose of this session information is to submit a complete request to the server cluster containing both the encrypted transaction content and preliminary signature evidence, enabling the server cluster to initiate subsequent legitimate verification and signing processes. Specifically, the combination process can use JSON serialization or Protobuf encoding to ensure clear field boundaries and a fixed order. For example, session information is constructed as a structure containing four fields: encrypted_data (transaction encryption information), digest (first digest), partial_sig_client (initial signature information), and auth_token (user authorization credential). This combination and transmission mechanism ensures that the data received by the server cluster possesses all the elements necessary to verify identity, decrypt content, and continue executing multi-party signatures, thereby significantly improving the consistency and security of transaction processing.

[0043] This application achieves a high degree of integration between transaction data and signature credentials by obtaining encrypted transaction information and a first digest, and combining them with initial signature information and user authorization credentials to generate session information. Leveraging the secure transmission characteristics of the first encrypted transmission channel, the combined session information can be delivered completely to the server cluster without tampering. Furthermore, the encrypted transaction information ensures the confidentiality of the content, the first digest provides a unified signature benchmark, the initial signature information reflects the client's signature contribution, and the user authorization credentials establish the legitimacy of the operation. These four elements work together, enabling the server cluster to parse the plaintext of the transaction and verify the pre-signature status without multiple interactions. This efficiently triggers subsequent signing service node processing and the final signature by the hardware security node, effectively avoiding process interruptions or repeated verifications due to missing data packet structures, and significantly improving the overall processing efficiency and system robustness of multi-party secure computation transactions.

[0044] S150. The server cluster performs a validity check on the session information. If the check is valid, it decrypts the information to obtain the plaintext transaction information corresponding to the session information.

[0045] After receiving the session information, the server cluster performs a validity check. If the check is valid, it decrypts the encrypted transaction information in the session information to obtain the plaintext transaction information. This validity check involves the server cluster comprehensively verifying the legitimacy of the user's authorization credentials, the transaction data, the anti-replay mechanism, and the permissions of the wallet account address. The plaintext transaction information is the original transaction data restored after the session information is decrypted. Specifically, the server cluster uses the first session private key corresponding to the first encrypted transmission channel to decrypt the encrypted portion of the session information. For example, upon receiving the session information, the server cluster first verifies whether the user's authorization credentials are valid and unaltered, and confirms the correct format of the initial signature information; it calculates the verification digest corresponding to the encrypted transaction information and determines whether the verification digest matches the first digest to verify whether the data has been tampered with during transmission; if all the above verifications pass, a valid verification result is obtained; if any of the above verifications fail, an invalid verification result is obtained. After the validity check, the session key is used to decrypt the encrypted transaction information to obtain the plaintext transaction information containing details such as the payee and amount. This significantly improves the accuracy of transaction processing, ensuring that only legitimate transactions that have undergone multiple verifications will proceed to the signature stage.

[0046] S160. The server cluster signs the plaintext transaction information according to a preset signing strategy, generates corresponding secure signing information, and sends it to the hardware security node through the second encrypted transmission channel.

[0047] After obtaining the plaintext transaction information, the server cluster signs the plaintext transaction information according to the signing strategy, thereby generating corresponding secure signed information, which is then sent to the hardware security node through the second encrypted transmission channel. The signing strategy is a signature rule pre-installed in the server cluster, including the signing ratio determination rule and the service node's private key (i.e., the private key fragment B allocated to the service node in the distributed key generation protocol). The second encrypted transmission channel is a high-security communication link established between the server cluster and the hardware security node, also built based on the bidirectional TLS protocol and possessing an independent second session private key. The secure signed information is an intermediate signed data packet generated by the server cluster after completing partial signing. Specifically, the server cluster pushes the plaintext transaction to the corresponding signing service node according to the transaction path parameters. This node uses the second session private key to encrypt the plaintext transaction to obtain the signed encrypted information, determines the signing ratio according to the signing ratio determination rule (such as calculation based on the hash value of the reception time), and then uses the service node's private key to partially sign the remaining part or middle section of the first digest to obtain the signed information. For example, if the signing ratio is calculated to be 1 / 2, the service node selects the first 11 bytes of the unsigned 22 bytes of data in the first digest, signs them using fragment B of its private key, and then combines the signed encrypted information with the first digest, the obtained signed information, and the server credentials to form secure signed information, which is then sent to the hardware security node through the second encrypted transmission channel. This step demonstrates the process by which the server cluster and the hardware security node establish a second encrypted transmission channel by exchanging certificate chains, verifying CA signatures, and negotiating temporary ECDHE keys, ensuring the absolute security of the signed information during transmission to the hardware security node.

[0048] In a specific embodiment, step S160 includes the following sub-steps: the server cluster pushes the plaintext transaction information to the signing service node corresponding to the transaction path parameters according to the transaction path parameters in the plaintext transaction information; the signing service node encrypts the plaintext transaction information according to the second session private key corresponding to the second encrypted transmission channel to obtain corresponding signed encrypted information; determines the signing ratio corresponding to the session information according to the signing ratio determination rule in the signing strategy; performs partial signing on the first digest according to the service node private key in the signing strategy and the signing ratio to obtain corresponding signed information; combines the signed encrypted information, the first digest, the signed information, and the server credentials of the signing service node to obtain corresponding secure signed information and sends it to the hardware security node through the second encrypted transmission channel.

[0049] Specifically, transaction path parameters are identifiers used to indicate the flow path of transaction data within the server cluster. These parameters include the target blockchain network type, asset type, or specific routing rule codes. The transaction path parameters originate from the decrypted plaintext transaction information. Specifically, the server cluster parses the header or metadata area of ​​the plaintext transaction information to extract the pre-formatted transaction path parameter fields. The purpose of the transaction path parameters is to guide the server cluster to accurately distribute the data to be processed to specific signing service nodes with corresponding processing capabilities or permissions, thereby achieving load balancing or dedicated chain processing. For example, when the transaction path parameter is identified as A-B, the server cluster pushes the plaintext transaction information to signing service node B, which is specifically responsible for processing the corresponding exchange transaction; if it is identified as C-C, it is pushed to signing service node C, which is dedicated to C-C transfers. Through the mapping relationship between transaction path parameters and signing service nodes, differentiated processing is achieved in multi-chain or multi-asset scenarios, ensuring that different types of transactions are subsequently signed by the most suitable node, improving the system's scalability and processing efficiency.

[0050] Furthermore, the second session private key is a temporary symmetric key generated during the negotiation of the second encrypted transmission channel established between the server cluster and the hardware security node. It is a shared secret value calculated using the ECDHE key negotiation algorithm in the mTLS handshake protocol. Specifically, the signing service node uses the locally stored second session private key to encrypt the received plaintext transaction information using the AES symmetric encryption algorithm, thereby obtaining the signed encrypted information. The purpose of the second session private key is to ensure that transaction data is not exposed or tampered with during transmission from the server cluster to the hardware security node, thus guaranteeing the confidentiality of the communication link. This second session private key has an expiration time; it is regenerated each time a new second encrypted transmission channel is established, and historical keys are not reused. For example, the signing service node reads the second session private key corresponding to the second encrypted transmission channel, encrypts the plaintext transaction information in CBC mode, and outputs a ciphertext data block as the signed encrypted information. Through this encryption mechanism based on dynamic session keys, even if the key is leaked over a long period, the security of a single communication will not be affected, effectively defending against malicious attacks.

[0051] Furthermore, the signature ratio determination rule is the algorithmic logic used to dynamically calculate the proportion of the digest length occupied by the server-side signature. It is a deterministic rule based on a combination of timestamp conversion and modulo operation. The signature ratio is the ratio of the length of the first digest segment covered by the final generated signed information to the total length of the first digest. Specifically, the signature service node obtains the timestamp of the received session information, converts the timestamp into a hexadecimal string, and simultaneously obtains the user authorization credential (also a hexadecimal string) contained in the session information. It then performs a modulo operation on the converted timestamp hexadecimal string using the user authorization credential, takes the last digit of the remainder (or the digit preceding it if the last digit is zero), and divides this number by a preset fixed value (e.g., 20) to calculate the signature ratio. The purpose of the signature ratio is to introduce randomness and dynamism, ensuring that the signature segment length varies for each transaction, increasing the difficulty for attackers to crack private key fragmentation. For example, if the remainder of the hexadecimal string converted from the information reception time to the user authorization credential is 14, and the fixed value is set to 20, then the calculated signing ratio is 14 / 20, or 0.7. If the last digit is 0 and the preceding digit is 8, then the ratio is 8 / 20, or 0.4. This dynamically determined signing ratio allows for flexible configuration of the signature strategy, avoiding the risk of recurring exposure that might arise from a fixed ratio.

[0052] Furthermore, the service node private key is a distributed private key fragment (i.e., private key fragment B) stored locally on the signing service node. It is generated and securely stored during system initialization using the Distributed Key Generation (DKG) protocol and does not contain complete private key information. The signing service node stores multiple sets of service node private keys, each corresponding to a client. Clients can access the stored service node private key that matches the client identifier (such as MAC address, IP address, user authorization credential, or digital wallet address) in the transaction plaintext information. The first digest is the hash value generated based on the encrypted transaction information, typically of fixed length (e.g., 256 bits). Specifically, the signing service node first extracts a segment of the corresponding length from the unsigned remaining fragments of the first digest according to the previously determined signing ratio. The extraction rule can be to extract the middle section of the first digest, i.e., after deducting the client-signed portion, extract the remaining usable part proportionally. Subsequently, the service node uses its private key to perform a partial signature operation using the Elliptic Curve Digital Signature Algorithm (ECDSA) on the extracted digest fragment to generate the signed information. The synergy between the service node's private key and the signing ratio ensures that only nodes holding the correct shard can generate a valid signature, while also increasing the complexity of forging signatures by varying the signature length. For example, if the total length of the first digest is 32 bytes, and the client has already signed the first 10 bytes, leaving 22 bytes, and the calculated signing ratio is 1 / 2, then the signing service node will truncate the middle 11 bytes of the remaining 22 bytes, sign them using its private key, and generate a matching signature message. This process ensures that the server fulfills its signing responsibility without reconstructing the complete private key, adhering to the core principle of secure multi-party computation.

[0053] Furthermore, the server credential, also known as a digital certificate or token, identifies the signing service node. It contains the node ID, public key information, and the issuing authority's signature, used to prove the legitimacy of the data source to the hardware security node. The secure signing information is a composite data packet encapsulated from the signed encrypted information, the first digest, the signed information, and the server credential according to a preset data structure. Specifically, the signing service node serializes and assembles these four elements to form complete secure signing information and sends it to the hardware security node through the established second encrypted transmission channel. The server credential serves to allow the hardware security node to perform authorization verification and source tracing, ensuring that only authorized service nodes can trigger the HSM signing operation. For example, the signed encrypted information is placed at the beginning of the data packet, followed by the original first digest and the newly generated signed information, and appended with a CA-signed server credential X.509 certificate sequence. Through this combination, the hardware security node, upon receiving the data, can verify the sender's identity and obtain complete context information to perform subsequent joint signing operations, thus achieving a secure and seamless connection from the server to the hardware.

[0054] This application constructs a highly secure server-side signature mechanism through the coordinated operation of transaction path parameters, dynamic signature ratios, and service node private key fragmentation. Transaction path parameters enable precise routing for different business scenarios, ensuring that signature tasks are executed by nodes with the appropriate qualifications. The dynamically calculated signature ratio based on timestamps and user authorization credentials makes the length of each signed data fragment unpredictable, effectively preventing statistical analysis attacks targeting fixed signature patterns. The service node's private key, as a key fragment in the distributed private key system, participates only in local signature calculations, eliminating the risk of the complete private key being stored on the server. Furthermore, combined with the mTLS two-way authentication mechanism of the second encrypted transmission channel, the integrity and confidentiality of the signed encrypted information and server credentials are ensured during transmission. The final securely signed information not only carries the necessary signature data but also achieves auditability and traceability of the operation through server credentials. This ensures that the entire signature process meets financial-grade risk control requirements while strictly adhering to the principles of least privilege and zero trust in multi-party secure computation, significantly improving the transaction system's ability to resist internal threats and external attacks.

[0055] S170. The hardware security node performs permission verification on the security signature information. If the permission verification shows that the node has permission, it obtains the hardware key corresponding to the security signature information, signs the security signature information to obtain a signature result, and feeds it back to the server cluster through the second encrypted transmission channel.

[0056] After receiving the security-signed information, the hardware security node verifies its permissions. If the permissions are valid, it obtains the hardware key corresponding to the security-signed information and signs it to obtain a signature result. This signature result is then sent back to the server cluster via a second encrypted transmission channel. The hardware security node (HSM) is a trusted execution environment with physical protection capabilities. It internally stores a hardware key (i.e., a private key fragment C allocated in the distributed key generation protocol), and this private key cannot be exported. The permission verification is essentially the HSM's verification of the caller's IP whitelist, interface permissions, and the legality of the request signature. The signature result is an encrypted response body output by the HSM after performing a final partial signature using its internal hardware key. Specifically, the HSM first authenticates the security-signed information. If successful, it decrypts the encrypted information to obtain the plaintext of the signature request. After verifying the digest consistency, it extracts the stored hardware key and performs a partial signature on the remaining unsigned portion of the first digest to obtain the security signature information. Finally, it combines the hardware basic information and the security signature information and encrypts them to generate the signature result. For example, after HSM detects a request from a legitimate service node, it invokes the private key shard C in its internal secure area to sign the last segment of the transaction digest, generating an encrypted response containing hardware node credentials and sending it back. By introducing a hardware secure node, the physical isolation of the private key shard's storage and signature computation is achieved, effectively combating memory attacks and debugging attacks, and reaching financial-grade security standards.

[0057] In a specific embodiment, step S170 includes the following sub-steps: performing permission verification on the secure signature information according to a preset permission verification strategy to obtain a permission verification result indicating whether permission is granted; if the permission verification result indicates permission is granted, decrypting the signature encryption information in the secure signature information to obtain the corresponding signature request plaintext; obtaining the hardware key corresponding to the signature request plaintext and partially signing the first digest in the secure signature information to obtain the corresponding secure signature information; combining the hardware basic information of the hardware security node with the secure signature information to generate the corresponding response information; encrypting the response information according to the second session private key corresponding to the second encrypted transmission channel to obtain an encrypted response body; combining the encrypted response body with the hardware node credential of the hardware security node to obtain the corresponding signature result and feeding it back to the server cluster through the second encrypted transmission channel.

[0058] Specifically, the permission verification policy is a series of access control rules executed by the hardware security node when it receives an external request. Its function is to identify and intercept unauthorized calls, ensuring that only authorized server clusters can initiate signature requests. The specific execution methods of this policy include IP whitelist matching, interface permission verification, and request signature validity verification. Specifically, the hardware security node first extracts the sender's IP address from the security signing information and compares it with a pre-set whitelist; simultaneously, it parses the server credentials to verify whether it has the permission to call the current signing interface; furthermore, it uses the stored public key to verify the digital signature in the request to confirm that the data has not been tampered with and indeed comes from a legitimate signing service node. For example, if the source IP of a request is 192.1XX.X.105, but the whitelist only contains network segments from 192.1XX.X.100 to 192.1XX.X.104, it is determined to be unauthorized; or, if the timestamp in the request exceeds the allowed time window (e.g., exceeding the allowed time window by 30 seconds), it is also determined to be illegal. This multi-dimensional permission verification mechanism effectively prevents replay attacks and unauthorized access, building the first line of defense for subsequent key operations.

[0059] Furthermore, the signed encrypted information is the ciphertext of the transaction data encrypted by the signing service node using the second session private key (i.e., the symmetric key negotiated during the TLS handshake). The decryption process is performed within the secure enclave inside the hardware security node, ensuring that the key material does not leave the domain. Specifically, the hardware security node calls its internal cryptographic operation module, using the second session private key bound to the second encrypted transmission channel to perform AES or SM4 decryption operations on the signed encrypted information, thereby restoring the original plaintext signing request. This plaintext typically contains core business data such as transaction path parameters, transaction amount, and receiving address. For example, when receiving a 256-byte ciphertext data, the hardware security node completes decryption in the secure isolation area of ​​memory, generating a plaintext structure containing Amount:100YUAN,To:0xABC... (YUAN corresponds to the currency unit). This process ensures that even if the external interface of the hardware security node is eavesdropped on, attackers cannot obtain the transaction details in the plaintext, achieving confidentiality of data transmission.

[0060] Furthermore, the hardware key is a private key fragment (i.e., private key fragment C) pre-generated using the Distributed Key Generation (DKG) protocol and securely stored within the hardware security node. Its function is to work with the client and server node's signature fragments to form a complete threshold signature. The hardware security node stores multiple hardware keys corresponding to clients, and uses the hardware key that matches the client identifier (such as MAC address, IP address, user authorization credential, or digital wallet address) in the plaintext of the signing request. The first digest is the hash value generated based on the transaction assembly data, representing a unique fingerprint of the data to be signed. Partial signing utilizes the hardware key to sign only the remaining portion of the first digest that has not yet been signed by other nodes. Specifically, the hardware security node first retrieves the corresponding hardware key from its internal keystore based on the user ID or transaction identifier in the signature request plaintext. Then, according to predetermined segmentation rules (such as bitwise truncation or proportional segmentation), it locates the remaining fragment in the first digest that has not been covered by the client's initial signature or the service node's signature. Finally, using the Elliptic Curve Digital Signature Algorithm (ECDSA) or the Chinese national cryptographic algorithm SM2, it performs a signature operation on this remaining fragment using the hardware key to generate a secure signature. For example, if the first digest is 32 bytes long, the first 10 bytes have been signed by the client, and the middle 11 bytes have been signed by the service node, then the hardware security node will sign the remaining 11 bytes. In this way, the complete private key is never reconstructed on any single node, significantly improving the system's resistance to single-point attacks.

[0061] Furthermore, the hardware basic information, which is metadata used to identify the identity and device status of the hardware security node, includes the device serial number, firmware version number, and current running status code. Its purpose is to allow the recipient (server cluster) to verify the authenticity of the signature result and the health of the device. Combination involves encapsulating the aforementioned metadata and secure signature information according to a predetermined data structure (such as a JSON object or binary TLV format). Specifically, the hardware security node reads its own register data to obtain the device serial number and firmware version, and concatenates them with the generated secure signature information to form a complete response payload. For example, the response information can be constructed as {DeviceID:HSM-001,Firmware:v2.3.1,SignaturePartC:0x9A...}. This step ensures that after receiving the signature result, the server cluster can not only verify the mathematical correctness of the signature but also confirm that the signature was generated by a legitimate, healthy hardware device, thereby enhancing the traceability and auditability of the entire transaction chain.

[0062] Furthermore, the second session private key, which is a temporary symmetric session key negotiated through a two-way TLS handshake protocol (such as ECDHE key exchange) when establishing the second encrypted transmission channel, serves to ensure the secure transmission of response information back to the server cluster and prevent malicious tampering. The encryption process employs a symmetric encryption algorithm, offering both efficiency and security. Specifically, the hardware security node reuses the currently established TLS connection context, extracts the second session private key, and encrypts the generated response information to produce an encrypted response body. For example, if the response information is 512 bits long, it is encrypted using AES-256-GCM mode to generate an encrypted response body containing ciphertext data and an authentication tag. This mechanism ensures that even if there are risks in the network link, the data intercepted by an attacker is merely unreadable gibberish; only the legitimate server cluster holding the corresponding session key can decrypt and restore it, achieving end-to-end communication confidentiality.

[0063] Furthermore, the hardware node credential, also known as a digital certificate issued by a trusted Certificate Authority (CA) or the system's root CA, contains the hardware security node's public key and identity information. Its function is to prove the sender's true identity to the server cluster, preventing impersonation by forged nodes. The combination process involves packaging the encrypted data payload and certificate file into a standard network protocol message. Specifically, the hardware security node uses the encrypted response body obtained above as its payload, attaches its own X.509 format hardware node certificate, and constructs the final signature result data packet. Subsequently, this data packet is sent back to the server cluster through the established second encrypted transmission channel (i.e., a two-way authenticated TLS tunnel). For example, the data packet structure could be [TLSRecord Header][Encrypted Payload][HSM Certificate Chain]. After receiving the signature result, the server cluster first verifies the validity of the hardware node credential using its built-in root CA certificate. Once the identity is confirmed, it uses the session key to decrypt and obtain the secure signature information. By introducing dual protection through hardware node credentials and session encryption, this step not only ensures data integrity but also establishes a device-level trust chain, laying a solid foundation for the subsequent generation of the final valid signature.

[0064] This application constructs a robust hardware-level security protection system through the synergistic effect of the aforementioned technical features. By combining pre-defined permission verification strategies with hardware node credentials, dual authentication from the network layer to the application layer is achieved, effectively blocking unauthorized access attempts. The interaction data is fully encrypted using the second session private key corresponding to the second encrypted transmission channel. Combined with the isolated storage and partial signature mechanism of the hardware key within the hardware security node, this ensures that private key fragments never leave the security boundary, completely eliminating the risk of memory leaks and debugging attacks. Furthermore, through the division of labor in partial signing of the first digest, the client, service node, and hardware security node can generate a joint signature conforming to blockchain network verification standards without reconstructing the complete private key. This satisfies the theoretical requirements of Multi-Party Secure Computation (MPC) and achieves financial-grade compliance standards by leveraging the physical characteristics of HSM. Ultimately, this layered verification, decryption, signing, and feedback mechanism significantly improves the overall attack resistance and credibility of the transaction system, ensuring the security and reliability of digital asset transaction settlement.

[0065] S180. The server cluster aggregates the session information, the security signature information, and the signature result according to preset aggregation rules to generate a final valid signature.

[0066] The server cluster aggregates the initial signature information, the signed information from the security signing information, and the security signature information from the signature result according to aggregation rules to generate a final valid signature. The aggregation rules are mathematical synthesis logic based on threshold signature algorithms (such as Threshold ECDSA), used to synthesize local signatures scattered across different nodes into a complete digital signature. The final valid signature is a complete transaction signature that can be recognized and verified by the blockchain network. Specifically, after receiving the signature result, the cluster server can first verify the signature result, such as verifying whether the hardware node credentials in the signature result are consistent with the basic hardware information. After verification, the server cluster extracts the initial signature information from the session information, the signed information from the security signing information, and the security signature information from the signature result, and uses the MPC protocol for interactive computation to synthesize the final valid signature without reconstructing the complete private key. For example, the system substitutes the client shard signature, the service node shard signature, and the HSM shard signature into the aggregation formula of the elliptic curve signature algorithm to generate a standard ECDSA signature pair (r,s). This step ensures that even if any node in the transaction chain is compromised, the attacker cannot recover the complete private key. At the same time, the generated signature can be directly verified using the global public key of the entire blockchain network, achieving a balance between high security and compliance.

[0067] S190, The server cluster broadcasts the transaction information in the session information and the final valid signature to the blockchain network to complete the transaction settlement.

[0068] The blockchain network is a decentralized distributed ledger system used to record transactions and execute smart contracts. This step involves packaging the plaintext transaction information and the final valid signature into a standard transaction format, which is then broadcast to blockchain nodes via the distributed network. For example, a server cluster broadcasts transaction data containing the transfer amount and recipient address, along with the aggregated final valid signature. All nodes in the network verify the signature using the global public key generated during the DKG phase. Once verification is successful, the transaction is recorded on the blockchain and becomes effective. The access control list (ACL) is then updated in the smart contract to complete the settlement. This achieves network-wide consensus and immutable record-keeping of transactions, completing a closed-loop process from user-initiated request to on-chain settlement.

[0069] This application constructs a multi-layered security defense system through the collaboration of the client, server cluster, and hardware security nodes. By using a distributed key generation (DKG) protocol to split the user's private key into multiple fragments and store them separately on different entities, and combining this with a multi-party secure computation (MPC) protocol for interactive computation during the signature phase, it ensures that the complete private key is never reconstructed at any single point, fundamentally eliminating the risk of private key leakage. Simultaneously, the dual construction of a first and second encrypted transmission channel, particularly the dynamic session key negotiation mechanism based on bidirectional TLS, guarantees the confidentiality and integrity of data during transmission from the client to the server and from the server to the hardware security node. The introduction of user authorization credentials further binds the transaction context, restricting the scope of permissions for a single operation and effectively preventing replay attacks. Finally, a threshold signature algorithm aggregates the partial signatures of all parties into a final valid signature recognized by the blockchain. This not only meets the compliance requirements of institutional-level custody but also significantly improves the system's ability to resist single points of failure and malicious attacks, achieving highly secure and efficient digital asset transaction settlement.

[0070] The multi-party secure computation transaction method disclosed in the above embodiments includes: upon receiving transaction information, obtaining the client's authorization request and encrypting and sending it to the server cluster; after identity verification, the server cluster generates a user authorization credential and encrypts it, sending it back to the client; the client generates initial signature information, generates session information, and encrypts and sends it to the server cluster; after legal verification, the server cluster decrypts and signs the securely signed information, encrypts it, and sends it to the hardware security node; after permission verification, the hardware security node signs the securely signed information using a hardware key to obtain a signature result and encrypts it, sending it back to the server cluster; the server cluster aggregates the signatures to generate a final valid signature and broadcasts it to the blockchain network. This method synthesizes a final valid signature through multi-party secure computation and aggregation rules for transaction processing, ensuring that the complete private key is never reconstructed or stored at any time, significantly improving transaction security.

[0071] Figure 2 This is a schematic block diagram of a transaction system for multi-party secure computation provided in an embodiment of the present invention. Figure 2 As shown, corresponding to the above-mentioned multi-party secure computation transaction method, the present invention also provides a multi-party secure computation transaction system, wherein the system is configured in such a way as... Figure 4 In application scenarios. For details, please refer to [link / reference]. Figure 2 The multi-party secure computation transaction system 100 includes an authorization request sending unit 101, an initial signature information acquisition unit 102, and a session information generation unit 103 configured on the client 10; a user authorization credential sending unit 201, a legal verification unit 202, a secure signature information generation unit 203, an aggregation processing unit 204, and a broadcast unit 205 configured on the server cluster 20; and a signature result acquisition unit 301 configured on the hardware security node 30.

[0072] The authorization request sending unit 101 is used to receive transaction information input by the user, obtain the authorization request corresponding to the client, and send it to the server cluster through the first encrypted transmission channel.

[0073] The user authorization credential sending unit 201 is used to verify the identity of the authorization request. If the identity verification is successful, it generates a user authorization credential corresponding to the authorization request and sends it back to the client through the first encrypted transmission channel.

[0074] The initial signature information acquisition unit 102 is used to generate initial signature information corresponding to the transaction information according to the preset signature strategy and the user authorization certificate.

[0075] The session information generation unit 103 is used to generate session information based on the transaction information, the initial signature information and the user authorization credential, and send it to the server cluster through the first encrypted transmission channel.

[0076] The validity verification unit 202 is used to perform validity verification on the session information. If the verification is valid, the transaction plaintext information corresponding to the session information is decrypted and obtained.

[0077] The secure signature information generation unit 203 is used to sign the plaintext transaction information according to a preset signature strategy, generate corresponding secure signature information, and send it to the hardware security node through the second encrypted transmission channel.

[0078] The signature result acquisition unit 301 is used to perform permission verification on the security signature information. If the permission verification shows that the user has permission, the hardware key corresponding to the security signature information is obtained to sign the security signature information to obtain a signature result, which is then fed back to the server cluster through the second encrypted transmission channel.

[0079] The aggregation processing unit 204 is used to aggregate the session information, the security signature information and the signature result according to the preset aggregation rules to generate a final valid signature.

[0080] The broadcasting unit 205 is used to broadcast the transaction information in the session information and the final valid signature to the blockchain network to complete the transaction settlement.

[0081] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned multi-party secure computation transaction device and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0082] The aforementioned multi-party secure computation transaction device can be implemented as a computer program, which can, for example... Figure 3 It runs on the electronic device shown.

[0083] Please see Figure 3 , Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of the present invention. The electronic device 800 can be a terminal or a server. The terminal can be an electronic device with communication functions. The server can be a standalone server or a server cluster composed of multiple servers.

[0084] See Figure 3 The electronic device 800 includes a processor 802, a memory, and a network interface 805 connected via a system bus 801. The memory may include a non-volatile storage medium 803 and internal memory 804.

[0085] The non-volatile storage medium 803 may store an operating system 8031 ​​and a computer program 8032. The computer program 8032 includes program instructions that, when executed, cause the processor 802 to perform a transaction method for secure multi-party computation.

[0086] The processor 802 provides computing and control capabilities to support the operation of the entire electronic device 800.

[0087] The internal memory 804 provides an environment for the execution of the computer program 8032 in the non-volatile storage medium 803. When the computer program 8032 is executed by the processor 802, the processor 802 can execute a transaction method for multi-party secure computation.

[0088] This network interface 805 is used for network communication with other devices. Those skilled in the art will understand that... Figure 3The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the electronic device 800 to which the present invention is applied. The specific electronic device 800 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0089] The processor 802 is used to run a computer program 8032 stored in a memory to implement the steps included in the above-described multi-party secure computation transaction method.

[0090] It should be understood that, in this embodiment of the invention, the processor 802 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0091] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0092] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to perform steps included in the transaction method for secure multi-party computation described above.

[0093] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0094] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0095] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0096] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0097] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0098] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A transaction method for multi-party secure computation, characterized in that, The method is applied to a trading system, which includes a client, a server cluster, and a hardware security node. The client communicates with the server cluster to transmit data, and the server cluster communicates with the hardware security node and the blockchain network. The server cluster consists of multiple service nodes. The method includes: The client receives transaction information input by the user, obtains an authorization request corresponding to the client, and sends it to the server cluster through the first encrypted transmission channel; The server cluster verifies the identity of the authorization request. If the identity verification is successful, it generates a user authorization credential corresponding to the authorization request and sends it back to the client through the first encrypted transmission channel. The client generates initial signature information corresponding to the transaction information based on the preset signature policy and the user authorization credentials; The client generates session information based on the transaction information, the initial signature information, and the user authorization credential, and sends it to the server cluster through the first encrypted transmission channel. The server cluster performs a validity check on the session information. If the check is valid, it decrypts the information to obtain the plaintext transaction information corresponding to the session information. The server cluster signs the plaintext transaction information according to a preset signing strategy, generates corresponding secure signing information, and sends it to the hardware security node through the second encrypted transmission channel. The hardware security node performs permission verification on the security signature information. If the permission verification shows that the node has permission, it obtains the hardware key corresponding to the security signature information, signs the security signature information to obtain a signature result, and feeds it back to the server cluster through the second encrypted transmission channel. The server cluster aggregates the session information, the security signature information, and the signature result according to preset aggregation rules to generate a final valid signature; The server cluster broadcasts the transaction information in the session information and the final valid signature to the blockchain network to complete the transaction settlement. The client generates initial signature information corresponding to the transaction information based on a preset signature policy and the user authorization credentials, including: The client's terminal information, the transaction information, and the user authorization credential are assembled to generate corresponding transaction assembly data; The transaction assembly data is encrypted using the first session private key corresponding to the first encrypted transmission channel to obtain the corresponding encrypted transaction information. Generate a first digest corresponding to the encrypted transaction information; The signature ratio corresponding to the user authorization credential is determined according to the ratio determination rules in the signature strategy. The first digest is partially signed based on the client's private key in the signature policy and the signature ratio to obtain the corresponding initial signature information.

2. The transaction method for multi-party secure computation according to claim 1, characterized in that, The server cluster verifies the identity of the authorization request. If the identity verification is successful, it generates a user authorization credential corresponding to the authorization request and sends it back to the client through a first encrypted transmission channel, including: The verification service node in the server cluster verifies the transaction account information in the authorization request and obtains the identity verification result of whether it passes or fails. If the identity verification result is successful, a user authorization credential corresponding to the authorization request is generated based on the preset authorization parameters; The user authorization credential is encrypted using the first session private key corresponding to the first encrypted transmission channel to obtain the corresponding encrypted user authorization credential information, which is then fed back to the client through the first encrypted transmission channel.

3. The transaction method for multi-party secure computation according to claim 1 or 2, characterized in that, The client generates session information based on the transaction information, the initial signature information, and the user authorization credentials, and sends it to the server cluster through the first encrypted transmission channel, including: Obtain the encrypted transaction information and first digest corresponding to the transaction information; The transaction encryption information, the first digest, the initial signature information, and the user authorization credential are combined to obtain the corresponding session information, which is then sent to the server cluster through the first encrypted transmission channel.

4. The transaction method for multi-party secure computation according to claim 3, characterized in that, The server cluster signs the plaintext transaction information according to a preset signing strategy, generates corresponding secure signing information, and sends it to the hardware security node through a second encrypted transmission channel, including: The server cluster pushes the plaintext transaction information to the signature service node corresponding to the transaction path parameters based on the transaction path parameters in the plaintext transaction information. The signature service node encrypts the plaintext transaction information according to the second session private key corresponding to the second encrypted transmission channel to obtain the corresponding signature encrypted information; The signature ratio corresponding to the session information is determined according to the signature ratio determination rule in the signature strategy. The first digest is partially signed based on the service node private key in the signing strategy and the signing ratio to obtain the corresponding signing information; The signed encryption information, the first digest, the signed information, and the server credentials of the signed service node are combined to obtain the corresponding secure signed information, which is then sent to the hardware security node through the second encrypted transmission channel.

5. The transaction method for multi-party secure computation according to claim 4, characterized in that, The hardware security node performs permission verification on the security-signed information. If the permission verification indicates that the node has the necessary permissions, it obtains the hardware key corresponding to the security-signed information, signs the security-signed information to obtain a signature result, and sends it back to the server cluster through the second encrypted transmission channel. This includes: The security signature information is verified according to a preset permission verification policy to obtain a permission verification result indicating whether the user has permission. If the permission verification result is that the user has permission, the encrypted signature information in the security signature information is decrypted to obtain the corresponding plaintext signature request. Obtain the hardware key corresponding to the plaintext of the signing request and partially sign the first digest in the security signing information to obtain the corresponding security signature information; The hardware basic information of the hardware security node is combined with the security signature information to generate the corresponding response information; The response information is encrypted using the second session private key corresponding to the second encrypted transmission channel to obtain an encrypted response body. The encrypted response body is combined with the hardware node credentials of the hardware security node to obtain the corresponding signature result, which is then fed back to the server cluster through the second encrypted transmission channel.

6. The transaction method for multi-party secure computation according to claim 5, characterized in that, Before obtaining the authorization request corresponding to the client and sending it to the server cluster through the first encrypted transmission channel, the method further includes: A first encrypted transmission channel is established between the client and the server cluster; And to establish a second encrypted transmission channel between the server cluster and the hardware security node.

7. A transaction system for secure multi-party computation, characterized in that, The transaction system includes a client, a server cluster, and a hardware security node; the client communicates with the server cluster to transmit data information, the server cluster communicates with the hardware security node and the blockchain network, the server cluster consists of multiple service nodes, and the transaction system is used to execute the transaction method of multi-party secure computation as described in any one of claims 1-6. The transaction system includes an authorization request sending unit, an initial signature information acquisition unit, and a session information generation unit configured on the client; a user authorization credential sending unit, a legality verification unit, a security signature information generation unit, an aggregation processing unit, and a broadcast unit configured on the server cluster; and a signature result acquisition unit configured on the hardware security node. The authorization request sending unit is used to receive transaction information input by the user, obtain the authorization request corresponding to the client, and send it to the server cluster through the first encrypted transmission channel; The user authorization credential sending unit is used to verify the identity of the authorization request. If the identity verification is successful, it generates a user authorization credential corresponding to the authorization request and sends it back to the client through the first encrypted transmission channel. The initial signature information acquisition unit is used to generate initial signature information corresponding to the transaction information according to the preset signature strategy and the user authorization certificate; The session information generation unit is used to generate session information based on the transaction information, the initial signature information and the user authorization credential, and send it to the server cluster through the first encrypted transmission channel. The validity verification unit is used to perform validity verification on the session information. If the verification is valid, the unit decrypts the plaintext transaction information corresponding to the session information. The secure signature information generation unit is used to sign the plaintext transaction information according to a preset signature strategy, generate corresponding secure signature information, and send it to the hardware security node through the second encrypted transmission channel. The signature result acquisition unit is used to perform permission verification on the security signature information. If the permission verification shows that the user has permission, the unit obtains the hardware key corresponding to the security signature information, signs the security signature information to obtain a signature result, and feeds it back to the server cluster through the second encrypted transmission channel. The aggregation processing unit is used to aggregate the session information, the security signature information and the signature result according to the preset aggregation rules to generate a final valid signature; The broadcasting unit is used to broadcast the transaction information in the session information and the final valid signature to the blockchain network to complete the transaction settlement.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the transaction method of multi-party secure computation as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which includes program instructions that, when executed by a processor, cause the processor to perform the transaction method of multi-party secure computation as described in any one of claims 1-6.

Images