A co-signature method and system based on double-end private key fragmentation

Abstract

This invention provides a collaborative signature method and system based on dual-end private key sharding, relating to the field of data processing technology. The method includes: acquiring data to be signed for collaborative computation, determining a first hash integer and a first elliptic curve point to obtain a first signature parameter set; the server receiving the first signature parameter set, extracting the response latency of sharded storage nodes, calculating the per-node response latency drop difference between adjacent nodes to obtain a latency drop difference sequence; dividing the system into steady-state response clusters and transient congestion clusters based on the latency drop difference sequence, and extracting a set of nodes from the transient congestion cluster. This invention achieves a balance between distributed key storage security and collaborative signature processing efficiency in high-concurrency scenarios by real-time sensing of sharded node congestion status and adaptively constructing a private key sharding reading topology path. Simultaneously, it ensures compliant and reliable signature computation through multi-dimensional sharding constraint verification and standardized collaborative computation.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a collaborative signature method and system based on dual-end private key fragmentation. Background Technology

[0002] Collaborative signature technology is a cryptographic scheme in which two communicating parties each hold a fragment of their private key and jointly complete the digital signature through interactive computation. This can reduce the security risks caused by the complete leakage of the private key by a single node to a certain extent. Currently, this type of scheme has been explored and applied in scenarios with certain requirements for key security, such as mobile payment, electronic contract signing, and IoT device authentication. Existing schemes typically split the user's private key into two fragments, stored separately on the collaborating device and the server. During signing, the two parties complete the computation through multiple rounds of interaction, making it difficult for either party to independently recover the complete private key. This has positive implications for improving the security of key storage and use.

[0003] On the server side, to further enhance the storage security of private key fragments, some deployment schemes adopt a distributed storage architecture, which disperses the server-side private key fragments across multiple physical storage nodes to prevent the key fragments from being directly exposed if a single node is compromised. However, in actual operation, this distributed storage method may face certain challenges in terms of collaborative signature efficiency. Specifically, the completion of collaborative signatures depends on the server reading private key fragments from multiple storage nodes and performing recombinant calculations. In some cases, when the response speed of some storage nodes varies due to factors such as network transmission fluctuations, instantaneous request congestion, or changes in resource load, it may have a certain impact on the real-time performance and success rate of the signature.

[0004] For example, in the actual operation of a third-party payment institution, its server distributes private key shards across storage nodes in multiple data centers within the same city. During off-peak hours, the response time for collaborative signature requests is generally maintained at the tens of milliseconds level, and the system operates relatively smoothly. However, during peak transaction periods brought about by certain promotional activities, some storage nodes experienced a certain degree of request queuing due to a concentration of concurrent read requests. The response latency of some nodes increased compared to normal levels, and occasionally a small number of signature requests failed to complete in time due to long waiting times, putting some pressure on the continuity of the payment business and user experience. According to preliminary analysis by operations and maintenance personnel, the above situation may be related to the fact that the existing collaborative signature scheme has not fully integrated the real-time operating status of storage nodes into the private key shard reading path. That is, regardless of whether the storage node is currently in a relatively busy state, the signature process usually reads shards sequentially according to a preset fixed order, and there is currently a lack of a mechanism to flexibly adjust the shard acquisition path based on the real-time response status of the nodes. Summary of the Invention

[0005] This invention provides a collaborative signature method and system based on dual-end private key sharding, which avoids slowing down the overall signature process due to continuous reading congestion nodes and effectively reduces the business risks of collaborative signature request timeouts and processing failures in high-concurrency transaction scenarios.

[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: Firstly, a collaborative signature method based on dual-end private key fragmentation, the method comprising: Step 1: Obtain the data to be signed and participate in the collaborative operation to determine the first hash large integer and the first elliptic curve point, and obtain the first signature parameter set; Step 2: The server receives the first signature parameter set, extracts the response latency of the sharded storage nodes, calculates the per-node response latency drop difference between adjacent nodes, and obtains the latency drop difference sequence; based on the latency drop difference sequence, it divides the steady-state response cluster and the transient congestion cluster, and extracts the node set of the transient congestion cluster. Step 3: Accumulate the congestion depth value for each node in the transient congestion cluster node set to obtain the accumulated congestion depth value; extract the remaining computing resources of each node in the steady-state response cluster, summarize to obtain the total available computing power value, multiply the total available computing power value by the maximum queue processing capacity of a single node to obtain the processing capacity threshold, and compare the accumulated congestion depth value with the processing capacity threshold to obtain the topology reconstruction judgment result. Step 4: Determine the target reorganization mapping based on the topology reconstruction determination results; Step 5: Reassemble the private key fragments of both ends according to the target reassembly mapping and participate in the collaborative signature operation to obtain the second signature parameter set; Based on the second signature parameter set, perform reverse blinding calculation processing in combination with the private key fragments of the collaborative end to obtain the final large integer signature. Step 6: Concatenate and process the final signature large integer with the second signature large integer in the second signature parameter set to obtain the target collaborative signature data.

[0007] Secondly, a collaborative signature system based on dual-end private key fragmentation includes: The collaborative operation module is used to obtain the data to be signed and participate in the collaborative operation, determine the first hash large integer and the first elliptic curve point, and obtain the first signature parameter set. The feature extraction module is used to receive the first signature parameter set on the server side, extract the response latency of the sharded storage nodes, calculate the per-node response latency drop difference between adjacent nodes, and obtain the latency drop difference sequence; divide the steady-state response cluster and transient congestion cluster according to the latency drop difference sequence, and extract the node set of the transient congestion cluster. The reconstruction determination module is used to accumulate the congestion depth value node by node in the transient congestion cluster node set to obtain the accumulated congestion depth value; extract the remaining computing resources of each node in the steady-state response cluster, summarize to obtain the total available computing power value, multiply the total available computing power value by the maximum queue processing capacity of a single node to obtain the processing capacity threshold, and compare the accumulated congestion depth value with the processing capacity threshold to obtain the topology reconstruction determination result. The reorganization mapping module is used to determine the target reorganization mapping based on the topology reconstruction determination results; The computation and processing module is used to fragment and reassemble the private keys of both ends according to the target reassembly mapping and participate in the collaborative signature operation to obtain the second signature parameter set; based on the second signature parameter set, combined with the fragmentation of the private keys of the collaborative end, reverse blind computation processing is performed to obtain the final signature large integer; The merging module is used to concatenate and process the final signature large integer with the second signature large integer in the second signature parameter set to obtain the target collaborative signature data.

[0008] Thirdly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0009] The above-described solution of the present invention has at least the following beneficial effects: This solution, building upon the existing dual-private-key sharded collaborative signature cryptographic system on both the collaborative end and the server, adds real-time node status awareness and dynamic topology reconfiguration logic for business deployment scenarios involving distributed multi-node storage with server-side private key sharding. Unlike existing technologies that read key shards in a fixed order, this solution can collect the response latency of each shard storage node in real time, automatically distinguishing between steady-state idle nodes and transient congested nodes. It can identify node queuing and congestion caused by business peaks and network fluctuations, preventing continuous reading of congested nodes from slowing down the overall signature process and effectively reducing the business risks of collaborative signature request timeouts and processing failures in high-concurrency transactions and batch signing scenarios. By quantifying the cluster congestion level and the schedulable computing power of steady-state nodes to form the basis for topology reconfiguration, two types of shard reading mapping strategies are set for different congestion levels. The two paths can be switched on demand, reducing shard addressing and transmission costs while fully utilizing idle cluster computing resources to achieve load balancing of distributed storage nodes.

[0010] A fragmentation and reassembly verification model is constructed, incorporating multi-dimensional constraints such as physical memory address, node storage capacity, and node communication latency. This model can automatically select the globally optimal fragmentation parameters for optimized reassembly, avoiding anomalies such as fragmentation address conflicts, insufficient storage resources, and cross-node communication timeouts that may occur after dynamically adjusting the read path. This reduces signature operation errors caused by fragmentation read anomalies. The core cryptographic operation process fully utilizes the existing shared public key generation and dual-end collaborative signature framework. Only the server-side private key fragmentation read scheduling stage is enhanced with topology awareness and dynamic reconstruction mechanisms. No modifications are required to the original private key fragmentation and elliptic curve collaborative operation logic on the collaborating end and server side. This allows for seamless integration with existing electronic signature, IoT authentication, and mobile payment systems, reducing the implementation costs of solution deployment, modification, and system replacement. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating a collaborative signature method based on dual-end private key fragmentation, provided by an embodiment of the present invention.

[0012] Figure 2 This is a schematic diagram of a collaborative signature system based on dual-end private key fragmentation provided by an embodiment of the present invention. Detailed Implementation

[0013] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0014] like Figure 1 As shown, an embodiment of the present invention proposes a collaborative signature method based on dual-end private key fragmentation, the method comprising the following steps: Step 1: Obtain the data to be signed and participate in the collaborative operation to determine the first hash large integer and the first elliptic curve point, and obtain the first signature parameter set; Step 2: The server receives the first signature parameter set, extracts the response latency of the sharded storage nodes, calculates the per-node response latency drop difference between adjacent nodes, and obtains the latency drop difference sequence; based on the latency drop difference sequence, it divides the steady-state response cluster and the transient congestion cluster, and extracts the node set of the transient congestion cluster. Step 3: Accumulate the congestion depth value for each node in the transient congestion cluster node set to obtain the accumulated congestion depth value; extract the remaining computing resources of each node in the steady-state response cluster, summarize to obtain the total available computing power value, multiply the total available computing power value by the maximum queue processing capacity of a single node to obtain the processing capacity threshold, and compare the accumulated congestion depth value with the processing capacity threshold to obtain the topology reconstruction judgment result. Step 4: Determine the target reorganization mapping based on the topology reconstruction determination results; Step 5: Reassemble the private key fragments of both ends according to the target reassembly mapping and participate in the collaborative signature operation to obtain the second signature parameter set; Based on the second signature parameter set, perform reverse blinding calculation processing in combination with the private key fragments of the collaborative end to obtain the final large integer signature. Step 6: Concatenate and process the final signature large integer with the second signature large integer in the second signature parameter set to obtain the target collaborative signature data.

[0015] In this embodiment of the invention, based on the existing dual-private-key sharded collaborative signature cryptographic system of the collaborative end and the server end, a new logic for real-time node status awareness and dynamic topology reconstruction is added for the business deployment scenario of distributed multi-node storage of server-side private key shards. Unlike the existing technology's fixed-order key shard reading mode, this new logic can collect the response latency of each shard storage node in real time, automatically distinguish between steady-state idle nodes and transient congested nodes, and identify node queuing and congestion states caused by business peaks and network fluctuations. This avoids continuously reading congested nodes and slowing down the overall signature process, effectively reducing the business risks of collaborative signature request timeouts and processing failures in high-concurrency transactions and batch signing scenarios. By quantifying the cluster congestion level and the schedulable computing power of steady-state nodes to form the basis for topology reconstruction judgment, two types of shard reading mapping strategies are set for different congestion levels. The two paths are switched on demand, reducing shard addressing transmission costs and fully utilizing idle cluster computing resources to achieve load balancing of distributed storage nodes.

[0016] A fragmentation and reassembly verification model is constructed, incorporating multi-dimensional constraints such as physical memory address, node storage capacity, and node communication latency. This model can automatically select the globally optimal fragmentation parameters for optimized reassembly, avoiding anomalies such as fragmentation address conflicts, insufficient storage resources, and cross-node communication timeouts that may occur after dynamically adjusting the read path. This reduces signature operation errors caused by fragmentation read anomalies. The core cryptographic operation process fully utilizes the existing shared public key generation and dual-end collaborative signature framework. Only the server-side private key fragmentation read scheduling stage is enhanced with topology awareness and dynamic reconstruction mechanisms. No modifications are required to the original private key fragmentation and elliptic curve collaborative operation logic on the collaborating end and server side. This allows for seamless integration with existing electronic signature, IoT authentication, and mobile payment systems, reducing the implementation costs of solution deployment, modification, and system replacement.

[0017] In a preferred embodiment of the present invention, the collaborative signature system adopts a three-layer architecture consisting of a collaborative terminal, a server, and sharded storage nodes. The collaborative terminal device is a shard holding the first private key. The client entity, specifically a secure element or trusted execution environment in a smartphone, tablet, or personal computer, is responsible for generating the first set of signature parameters and completing the reverse blinding computation of the final signature. The server is a server cluster deployed on a cloud platform or local data center, holding a second private key shard. The logical ownership of the storage node is responsible for receiving the first set of signature parameters, performing response latency detection and congestion clustering analysis on the sharded storage nodes, generating topology reconstruction mapping, completing server-side private key sharding and reassembly, and coordinating signature server-side computation. The sharded storage nodes are independent storage servers distributed across multiple physical data centers within the same city. Each sharded storage node uniquely stores server-side private key shards. A sub-segment.

[0018] The 256-bit prime field elliptic curve used in the SM2 elliptic curve cryptography algorithm standard has the following equation: ; Where: eigenvalues ​​of the prime field The SM2 standard uses 256-bit large prime numbers; the elliptic curve equation has fixed coefficients. , The parameters are set to SM2 standard values; the three sets of parameters meet the SM2 standard constraints. .

[0019] Elliptic curve standard fixed base point Using the SM2 national standard preset base point, the curve order corresponding to this base point is... The given value is a 256-bit large prime number according to the SM2 standard. The hash algorithm uses the SM3 cryptographic hash algorithm, outputting a fixed 256-bit hash value. Private keys are fragmented at the collaborating end. It is generated internally by the security element on the collaborative end and stored locally with encryption, and is never transmitted externally or leaked to the ground. Server-side private key fragmentation. It is split into the Shamir threshold secret sharing algorithm. Each sub-shard is stored independently. In each sharded storage node. Collaborative public key. It is jointly generated by the collaborating end and the server end through a two-party secure computing protocol during the key initialization phase. There is no risk of unilateral key leakage, and it can be publicly used for signature verification.

[0020] The correspondence between sharded storage nodes and server-side private key sub-shards is defined as a linear mapping. Assume the total number of sharded storage nodes is 12, and each sharded storage node is numbered sequentially from smallest to largest based on its physical memory address. to The corresponding server-side private key fragment number is to . No. One sharded storage node physical memory address With the corresponding sub-fragment logical index number Satisfying linear mapping relationship In the formula The value is 256MB, which is a fixed physical memory address offset. This linear mapping allows the server to directly look up the corresponding sub-shard logical index number using the node's physical memory address, without requiring additional index lookup overhead.

[0021] The server is configured with a probe message sending module, with a fixed probe message sending period of 100ms. Each time a collaborative signature request arrives, the server sends a round of probe messages. The number of probe messages in each round equals the total number of sharded storage nodes. Each probe message is a 48-byte lightweight UDP data packet, containing a 4-byte session identifier, a 4-byte node identifier, a 4-byte timestamp, a 4-byte sequence number, and a 32-byte message authentication code. Probe messages are sent in a round-robin fashion, with the server sending them sequentially according to the increasing order of the nodes' physical memory addresses, at a fixed interval of 2ms. Upon receiving a probe message, each sharded storage node immediately returns a 48-byte acknowledgment message, containing the same session identifier, node identifier, original timestamp, received timestamp, and an updated message authentication code.

[0022] In a preferred embodiment of the present invention, the execution process of step 1 is as follows: The collaborating device acquires the raw byte stream of the data to be signed and divides it into blocks of a fixed block size B = 512 bytes. Let the total byte length of the data to be signed be L, and the number of blocks... For the first The data is divided into blocks, and the collaborating end calls the compression function of the SM3 cryptographic hash algorithm to perform block hashing to obtain the first data block. Block compression intermediate value Traverse all data blocks to obtain a set of compressed results. Then, sort the compressed results according to the timestamp order of the data blocks (i.e., block number). The data is processed block by block in ascending order. The concatenation method involves concatenating the 256-bit byte strings of the compressed intermediate values ​​of each block end to end in sequence, resulting in a concatenated byte string of fixed length of 256 bits. This concatenated byte string is then converted into a large integer representation to obtain the first hash large integer. ,Right now .

[0023] It should be noted that when the total byte length of the data to be signed is L≤B bytes, only a unique data block is generated (C=1). In this case, the set of multiple compressed results contains only a single compressed intermediate value H0 and the first hash large integer. This is the value of H0 after it has been converted to a large integer.

[0024] The collaborating endpoint extracts the associated curve parameters of its public key from the SM2 elliptic curve parameter storage area embedded within its secure element. These associated curve parameters include: elliptic curve equation coefficients. and eigenvalues ​​of prime number fields The coordinates of the base point and the order of the elliptic curve The collaborating operating system calls the hardware random number generator to generate the first random number. The first random number and Its entropy source is the physical noise source built into the collaborative terminal device (oscillator phase jitter), resulting in a 256-bit large integer. .

[0025] First hash large integer The 256-bit byte string and the first random number The 256-bit byte string is concatenated byte by byte, and the concatenation order is as follows: The byte string comes first. The byte string is followed by the base point seed value. After concatenation, they are combined into a complete 512-bit byte sequence. The large integer value corresponding to the base point seed value is compared with the order of the elliptic curve. Perform the modulo operation, and the remainder obtained is the candidate value of the x-axis. Substitute the candidate values ​​of the x-axis into the standard SM2 elliptic curve equation. To perform the solution calculation, that is, to substitute the fixed curve parameters. , With prime number field Calculate the result of the operation on the right side of the equation. .

[0026] judge Is it a model? The quadratic residue below, if For model The quadratic residue is solved by using a square root algorithm to find the modulus. The square root is used to obtain the candidate values ​​for the ordinate. ;like If the result is not a quadratic residue, then the candidate values ​​of the x-coordinate are incremented by 1 each time, and the equation is repeatedly substituted into the equation for calculation. The process continues until a valid x-coordinate that can generate a quadratic residue result is found, and the matching y-coordinate is calculated to obtain a complete valid coordinate pair. The quadratic residue determination is as follows: for non-zero integers... If there exists any integer It can satisfy Then it is called For model The quadratic residue represents the current x-coordinate. It can correspond to a valid ordinate on an elliptic curve; if no integer satisfies the condition... Then it is called For model Since the x-coordinate is not a quadratic residue, it is invalid and cannot form a valid coordinate point for the elliptic curve.

[0027] Combine the x-coordinate and y-coordinate values ​​that satisfy the equation of the elliptic curve to obtain the coordinates of a point on the elliptic curve (i.e., take the coordinates of the point obtained from the first successful solution). (Coordinate pairs) to obtain the base point of the dynamic elliptic curve Due to the base point seed value Relying on random generation for each signature Data pending signature hash value Therefore, the dynamic elliptic curve base points generated by each collaborative signature are different and unpredictable. This dynamic base point mechanism increases the difficulty for side-channel attackers to predict the intermediate values ​​of the elliptic curve operation.

[0028] The collaborating end will generate the first random number. With dynamic elliptic curve base point Perform scalar multiplication. The scalar multiplication is implemented using the Montgomery ladder algorithm to avoid timing-side channel leakage caused by conditional branches. The result of the scalar multiplication operation is denoted as... .

[0029] scalar multiplication result Mapping coordinates (affine coordinates) to a finite field , obtain the elliptic curve points For the original coordinate points Performing limited-domain compliance protocol processing, i.e., extraction The original x-axis Value, original ordinate The values ​​are the original large integers and the eigenvalues ​​of the prime field, respectively. Perform global modulo operation, i.e. , If the modulo result is 0, the zero value is retained. If the result exceeds the finite field interval, it is converged to the valid interval by modulo operation, ultimately yielding valid elliptic curve points that perfectly fit the prime finite field and conform to the SM2 standard. The finite field specifically refers to the 256-bit prime finite field defined by the SM2 algorithm, which consists of prime numbers... The global domain is defined such that the range of values ​​for all integers, coordinate parameters, and operation results involved in the operation is constrained within the domain. Within the interval, all addition, subtraction, multiplication, division, square root, and modulo operations are performed under this finite field rule, which is the fundamental operation field for all cryptographic operations on the SM2 elliptic curve.

[0030] The collaborating end encapsulates the first hash integer, the first random number, the complete coordinate parameters of the dynamic elliptic curve base point, and the complete coordinate parameters of the elliptic curve point after compliance with the specification into a structured and unified parameter encapsulation. The encapsulation format adopts the TLS standard ASN.1DER encoded structure, which includes four types of standardized TLV fields: a 256-bit hash integer field, a 256-bit random number field, a 512-bit uncompressed base point coordinate field, and a 512-bit uncompressed elliptic curve point coordinate field. After encapsulation and format verification, a complete first signature parameter set is generated. The collaborating end then transmits the encapsulated first signature parameter set to the server via an encrypted secure channel.

[0031] In a preferred embodiment of the present invention, step 2 is performed as follows: The server receives the first signature parameter set sent by the collaborating end through a secure channel. The server decodes the first signature parameter set and extracts the fragmented storage node identifier list from it. The fragmented storage node identifier list is generated and persistently stored by the server during the system initialization phase, and is specifically an ordered list of {node physical memory address, node IP address, node UDP port number} triples for 12 fragmented storage nodes.

[0032] The server initiates the probe message sending process. Using the current system time as the probe reference time, the server sends probe messages to each shard storage node sequentially, according to the increasing order of physical memory addresses in the shard storage node identifier list. Each probe message is sent at a fixed 2ms interval, with the timestamp field containing its sending time, calculated as reference time + sequence number × 2ms. There are a total of 12 shard storage nodes, and the total time for sending all probe messages is 24ms. Upon receiving a probe message, each shard storage node immediately generates an acknowledgment message and returns it. The server records the reception time of each acknowledgment message and calculates the round-trip response latency for each shard storage node, which is equal to the reception time minus the corresponding sending time. The server iterates through all shard storage nodes to obtain the set of node response latencies.

[0033] The server sorts the elements in the node response latency set according to the ascending order of the physical memory addresses of the sharded storage nodes. Since the list of sharded storage node identifiers is already sorted by physical memory address, the original order of the node response latency set is the sorted order. After sorting, starting from the second node, the server calculates the response latency difference between each node and its preceding neighbor node, i.e., subtracting the round-trip response latency of the previous node from the round-trip response latency of the current node, to obtain the node-by-node response latency difference. This process is repeated for all nodes until the difference between the last node and the second-to-last node is calculated.

[0034] The node-by-node response latency dropout values ​​are arranged in ascending order of timestamps from the original node numbers to obtain a latency dropout value sequence. The server then performs a sliding window local mean calculation on this sequence. The sliding window width is set to 5, and the sliding step is 1. For each node in the latency dropout value sequence at its current index position... Calculate the local mean of the five difference elements covered by the sliding window centered on the center.

[0035] For each difference in the latency drop difference sequence, determine whether the difference is greater than its corresponding local mean. If the difference is greater than the local mean, the latter of the two sharded storage nodes corresponding to that difference may exhibit congestion characteristics with a sharp drop in response rate, and this latter node is marked as a transient congested node. If the difference is not greater than the local mean, the node remains unmarked. After traversing all latency drop differences, the congestion status marking of all nodes is completed. The identifiers of all nodes marked as transient congested nodes are summarized to obtain the transient congested node set.

[0036] The server aggregates and partitions nodes in the transient congestion node set based on the principle of physical memory address continuity. Specifically, it iterates through the list of nodes sorted by physical memory address in the transient congestion node set. If the difference in physical memory address between two adjacent transient congestion nodes is equal to a fixed physical memory address offset, i.e., 256MB, then these two nodes are aggregated into the same transient congestion cluster. When the address difference is greater than the physical memory address difference, the current transient congestion cluster is closed, and the aggregation of the next transient congestion cluster begins with the current node. After aggregation, a set of transient congestion clusters is obtained.

[0037] All remaining nodes not included in the transient congestion node set (i.e., fragmented storage nodes with normal response latency) are aggregated into one or more steady-state response clusters. The aggregation method for steady-state response clusters is the same as that for transient congestion clusters, i.e., non-congested nodes are aggregated consecutively based on the principle of contiguous physical memory addresses. After aggregation, a set of steady-state response clusters is obtained. The server extracts the node identifiers (node ​​physical memory address, node IP address, node UDP port number) of all nodes within each transient congestion cluster to obtain the set of transient congestion cluster nodes.

[0038] In a preferred embodiment of the present invention, step 3 is performed as follows: For each transient congestion cluster in the set of transient congestion cluster nodes, the server traverses all the fragmented storage nodes within the cluster and extracts the current queue length from the network protocol stack of each node's operating system kernel. To avoid inaccurate congestion determination due to instantaneous fluctuations in a single sample, the server continuously collects three sample values ​​of the queue length for each node (sampling interval of 10ms), and takes the median of the three values ​​as the current congestion depth value for that node. The queue length represents the number of packets waiting to be processed in the outbound network interface sending queue of the node, expressed in packets. The queue length directly reflects the current network congestion severity of the node; the longer the queue, the more severe the congestion.

[0039] The server reads and extracts the queue length value for each node in each transient congestion cluster, and uses the queue length of each transient congestion node as the congestion depth value for that node. For all transient congestion nodes in the transient congestion cluster node set, the server accumulates the congestion depth value for each node to obtain the accumulated congestion depth value. The accumulated congestion depth value quantitatively represents the total congestion severity of all transient congestion clusters.

[0040] For each steady-state response cluster in the set of steady-state response clusters, the server iterates through all the fragmented storage nodes within that cluster and extracts the remaining computing resources at the current moment from the operating system resource monitoring interface of each node. The remaining computing resources are defined as a weighted composite index of the node's CPU idle rate and available memory capacity. Specifically, the node's CPU idle rate is multiplied by a first weighting coefficient, and then the ratio of the node's available memory capacity to the total physical memory capacity is multiplied by a second weighting coefficient to obtain the node's available computing power. The first weighting coefficient is set to 0.6, the second weighting coefficient to 0.4, and their sum to 1. The CPU idle rate has a higher weight than the memory availability rate, reflecting the fact that CPU computing power is the dominant resource in collaborative signature computation.

[0041] The server sums the available computing power values ​​of all nodes within the steady-state response cluster to obtain the total available computing power value, representing the upper limit of redundant processing capacity that all nodes within the steady-state response cluster can provide externally. The server compares the accumulated congestion depth value with the processing capacity threshold of the steady-state response cluster. The processing capacity threshold is obtained by multiplying the total available computing power value by the maximum queue processing capacity of a single node, where the unit of the maximum queue processing capacity of a single node is the number of packets; in this implementation, it is set to 100 packets. The comparison yields the topology reconfiguration determination result. Specifically, when the accumulated congestion depth value is not greater than the processing capacity threshold, it indicates that the available computing power of the steady-state response cluster is sufficient to cover the full congestion depth of the transient congestion cluster, and there are sufficient redundant resources within the steady-state cluster to handle the private key fragment reading task of the congestion cluster. In this case, a local reconfiguration flag is appended to the topology reconfiguration determination result, indicating that the local nearest reconfiguration mapping mode is preferred.

[0042] When the accumulated congestion depth exceeds the processing capacity threshold, it indicates that the congestion depth of the transient congestion cluster has exceeded the available computing power limit of the steady-state response cluster, and relying solely on the resources of the local steady-state cluster is insufficient to handle the workload of the congested nodes. In this case, a cross-cluster reconfiguration flag is added to the topology reconfiguration determination result, indicating that a cross-cluster distributed reconfiguration mapping mode has been triggered.

[0043] The server encapsulates the above determination results, namely the local reassembly identifier or the cross-cluster reassembly identifier, along with the corresponding congestion depth accumulation value and the processing capacity threshold, to obtain the topology reconfiguration determination result. The local reassembly type identifier indicates that the current network congestion depth does not exceed the available computing power of steady-state nodes, and only requires local reassembly of private key fragments within the steady-state response cluster. The cross-cluster reassembly type identifier indicates that the current network congestion depth exceeds the available computing power of steady-state nodes, and requires distributed fragmentation and reassembly across the boundary between the transient congestion cluster and the steady-state response cluster.

[0044] In a preferred embodiment of the present invention, step 4 is performed as follows: The server parses the identifier type in the topology reconstruction determination result and generates the topology reconstruction mapping in two different cases depending on the identifier type.

[0045] Specifically, scenario one: Local remapping of mappings: When the identifier type in the topology reconfiguration determination result is local reorganization, the server selects the steady-state response cluster from the steady-state response cluster set whose physical memory address is closest to that of the nodes in the transient congestion cluster node set as the receiving cluster. Specifically, the average physical memory address of all nodes in each steady-state response cluster is calculated, and the average physical memory address of all nodes in each transient congestion cluster is also calculated. The steady-state response cluster with the smallest absolute difference between the average physical memory address of the steady-state response cluster and the average physical memory address of the transient congestion cluster is selected as the corresponding receiving cluster.

[0046] Within the selected steady-state response cluster, the server sequentially selects nodes with consecutive physical memory addresses adjacent to the same number of nodes in the transient congestion cluster, in ascending order of physical memory address, as replacement nodes. Each congested node in the transient congestion cluster is mapped to a corresponding replacement node in the steady-state response cluster, establishing a one-to-one local nearest reorganization mapping relationship between congested nodes and replacement nodes. This mapping relationship is stored in the server's memory as a key-value hash table, where the key is the physical memory address of the congested node and the value is the physical memory address of the replacement node. The hash table uses open addressing to resolve collisions, and the load factor threshold is set to 0.75. The completed hash table is the local nearest reorganization mapping. The server outputs the local nearest reorganization mapping as the target reorganization mapping.

[0047] Scenario 2: Cross-cluster distributed reorganization mapping: When the topology reconfiguration result is a cross-cluster reconfiguration type, the total congestion depth of the transient congested clusters has exceeded the total available computing power of the steady-state response clusters. Therefore, it is necessary to cross cluster boundaries and utilize more widely distributed steady-state node resources to complete the fragmentation and reconfiguration. The server constructs the cross-cluster distributed reconfiguration map using the following process.

[0048] Specifically, the server calculates the difference between the accumulated congestion depth and the processing capacity threshold, representing the congestion handling needs that cannot be covered even with the local steady-state cluster's computing power. The computing power gap value is converted into a dynamic read step size. The dynamic read step size is calculated as follows: the computing power gap value is divided by the product of the average available computing power per node within the steady-state response cluster and the maximum queue processing capacity per node, and the result is rounded up to obtain the dynamic read step size. The unit of the dynamic read step size is an integer multiple of the physical memory address offset, with each offset being 256 MB. The average available computing power per node within the steady-state response cluster is the median of the available computing power values ​​of all nodes within the steady-state response cluster. The maximum queue processing capacity per node is measured in packets, which is 100 packets in this implementation. The meaning of the dynamic read step size is: the number of congested packets exceeding the steady-state cluster's processing capacity is converted into a multiple of the physical address offset that needs to be traversed; the larger the address offset traversed, the more abundant the available steady-state computing power resources.

[0049] The server sorts all nodes in the transient congestion cluster node set by their physical memory address values ​​in ascending order, selects the node with the smallest physical memory address value, and marks its physical memory address value as the first sharding address identifier; it selects the node with the largest physical memory address value and marks its physical memory address value as the second sharding address identifier.

[0050] Within the steady-state response cluster, the server calculates the absolute difference between the physical memory address of each non-congested node and the physical memory address corresponding to the second sharding addressing identifier. The node with the smallest absolute difference is selected from all absolute differences, and its physical memory address is marked as the third sharding addressing identifier. The third sharding addressing identifier represents the address of the nearest available node in the steady-state response cluster to the exit of the congested cluster, serving as the target endpoint for cross-cluster addressing.

[0051] The server starts at the physical memory address corresponding to the second segment addressing identifier and performs progressive addressing along the direction of increasing physical memory address values, with a dynamic read step size as the increment interval. During each progressive addressing, the current addressing position is updated to: ; In the formula: For the first The cursor position (physical memory address value) of the next cross-cluster recursive addressing; This is the starting position, which is the physical memory address corresponding to the second segment addressing identifier; The increments are based on the number of iterations, starting from 1 and increasing sequentially. For dynamic read step size (already converted to an integer multiple of the physical memory address offset); It equals 256MB, which is a fixed physical memory address offset.

[0052] After each progressive addressing, the server checks whether the difference between the current cross-cluster addressing cursor position and the physical memory address corresponding to the third shard addressing identifier is less than the product of the dynamic read step size and the fixed physical memory address offset. When the termination condition is met—that is, the difference between the current cursor position and the target address is less than the above product—the progressive addressing stops. All shard storage nodes corresponding to the cross-cluster addressing cursor positions traversed during this round of cross-cluster addressing are marked as a bridging shard storage node set. The physical memory addresses of the bridging shard storage nodes are located between the transient congestion cluster exit and the steady-state response cluster target entry, serving as cross-cluster bridges.

[0053] The server sequentially links the nodes corresponding to the first shard addressing identifier, the nodes corresponding to the second shard addressing identifier, the nodes in the bridging shard storage node set (sorted by ascending physical memory address), and the node corresponding to the third shard addressing identifier, according to their physical memory address values ​​in ascending order. This constructs a complete cross-cluster distributed reassembly map, including congestion source, congestion exit, bridging segment, and steady-state entry point. The complete cross-cluster distributed reassembly map is stored in a singly linked list structure. Each linked list node contains the physical memory address of the current node, the physical memory address of the next-hop node, and the logical index number of the server sub-shard corresponding to the current node. The server outputs the complete cross-cluster distributed reassembly map as the target reassembly map.

[0054] In a preferred embodiment of the present invention, step 5 is performed as follows: The server extracts the corresponding server-side private key sub-fragments from each node sequentially according to the node path indicated by the target reassembly map. Specifically, the server traverses each node in the target reassembly map. For local reassembly maps, it traverses the list of alternative nodes; for cross-cluster distributed reassembly maps, it traverses the singly linked list from head to tail. A sub-fragment read request is sent to each node, containing a session identifier, the logical index number of the sub-fragment to be read, and a message authentication code. After the node verifies the message authentication code, it reads the corresponding sub-fragment value from its own secret shared storage area and returns it. The server collects all returned sub-fragment values ​​to obtain a candidate fragment set.

[0055] The server constructs a sharding spatial distribution graph using the physical memory addresses of nodes corresponding to the private keys of each sub-shard in the candidate sharding set as vertex coordinates. Each vertex in the vertex set corresponds to the physical memory address of a node containing a sub-shard in the candidate sharding set. The edge set consists of pairwise connections between all vertices. The comprehensive path cost weight of each path edge is calculated by weighted fusion of three constraint indicators: physical address span, remaining node storage capacity, and inter-node communication latency. Addressing the core requirements of low latency, high reliability, and low input / output overhead for collaborative signature services, extensive data center cluster simulation tests and stress sampling were conducted to determine the three-dimensional constraint weight allocation rules: communication latency is the core real-time indicator with the highest priority; physical address span determines memory input / output read overhead and has the second highest priority; and remaining node storage capacity is a steady-state auxiliary indicator with the lowest priority. The fixed weights for the three-dimensional constraints are: communication latency 0.5, physical address span 0.3, and remaining storage capacity 0.2, with a sum of 1.

[0056] Based on the fragmented spatial distribution map, the server establishes a set of fragmented reorganization constraint equations, which includes three types of constraints: The first type of constraint is the edge length constraint, which uses the difference in physical memory addresses between nodes corresponding to adjacent server private key shards as the edge length. For any edge in the sharded spatial distribution graph... The edge length constraint requires that the difference in physical memory addresses of the edge does not exceed a preset maximum path span threshold. ; In the formula: and Vertices and vertex The corresponding physical memory address value of the node; The maximum path span threshold is fixed at 2048MB in this embodiment, which corresponds to the physical address span of 8 consecutive shard storage nodes. This ensures that the reassembled path maintains spatial locality in the physical topology and avoids excessively high communication latency caused by long-distance shard reading across data centers. This is a subset of the edges corresponding to the actual traversal path.

[0057] The second type of constraint is the node capacity constraint, which uses the remaining storage capacity of the node where each server's private key shard resides as the node capacity measure. For each vertex in the sharding spatial distribution graph... The node capacity constraint requires that the remaining storage capacity of the node is not less than a preset minimum storage threshold. ; In the formula: As vertex The remaining storage capacity of the corresponding node, in GB; To minimize storage requirements, this embodiment uses a fixed 2GB threshold to ensure that nodes have sufficient storage space to cache the sub-shard data to be reassembled. This is the subset of vertices corresponding to the actual traversal path.

[0058] The third type of constraint is the latency constraint, which uses the communication latency between the nodes where each server's private key shard resides as the latency metric. For all edges on the actual traversal path in the sharded spatial distribution graph, the latency constraint requires that the total communication latency of the path does not exceed a preset maximum allowable latency threshold. ; In the formula: As vertex With vertex The current round-trip time between the corresponding nodes is directly read from the node response time set in step 2 above; The maximum allowable latency threshold is fixed at 50ms in this embodiment. This threshold is set based on actual test data of third-party payment institution business scenarios to ensure that the end-to-end response time of collaborative signature is controlled within the range of user-acceptable perceived latency.

[0059] The server transforms the above three types of constraints into a parameterized expression. A three-dimensional parameter vector to be solved is defined. ,in This is the physical memory address difference parameter. This is the remaining storage capacity parameter. Let be the communication delay parameter. Then the fragmentation and reassembly constraint equations can be uniformly expressed as: ; In the formula: This is a side-length constraint inequality; To store constraint inequalities; This is a time-delay constraint inequality.

[0060] Server-side parameterized expression Perform constraint satisfaction checks. Specifically, substitute the actual physical memory address values, remaining storage capacity, and communication latency corresponding to the candidate shard set into the three constraint inequalities mentioned above, and check whether the three inequalities are simultaneously true. If the candidate shard set simultaneously satisfies the side length constraint, node capacity constraint, and latency constraint (i.e., all three inequalities are true), then the target reassembly mapping verification is considered successful. The server directly performs the Shamir threshold secret sharing inverse operation (Lagrange interpolation reconstruction) on all server private key sub-shards in the candidate shard set according to the node path indicated by the target reassembly mapping, to obtain the reassembled server private key. : ; In the formula: For the first Each server's private key is fragmented; For the first The Shamir interpolation x-coordinate (i.e., the logical index number of the sub-shard) corresponding to each server private key sub-shard. For the first The Shamir interpolation x-coordinate corresponding to each server-side private key shard. ; Multiplication Traverse all The x-coordinate point; This represents the order of the elliptic curve. The threshold for Shamir's threshold secret sharing is 12, meaning that all 12 sub-shards are required to fully reconstruct the server's private key. .

[0061] If any one of the constraints in the candidate shard set is not satisfied (i.e., at least one of the three inequalities is false), the server generates a verification failure flag and proceeds to the optimization and reassembly process. In the optimization and reassembly process, the server performs a global constraint satisfaction check on the parameterized expression, that is, within the entire node range of the steady-state response cluster and the transient congestion cluster, it uses a dynamic programming algorithm to search for the optimal shard reading path that satisfies all constraints. Let the path contain... Each node, state Represented by node The destination and the set of visited nodes are The shortest path length. The state transition equation is: ; in, The set of visited nodes; The current target node; For the previous node, Indicates from set Remove node The set after, For nodes To the node The algorithm calculates the comprehensive path cost (a weighted sum of physical address span, communication latency, and storage capacity constraints). During the search, real-time pruning is implemented; if the total physical address span of a current partial path exceeds the maximum path span threshold or the total latency exceeds the maximum allowable latency threshold, the expansion of that branch is immediately terminated. The worst-case time complexity of this algorithm is O(log n). This approach is feasible and efficient when there are 12 nodes. After traversing all feasible path combinations, a set of feasible parameters is obtained.

[0062] The server selects the optimal reassembly parameters from the feasible parameter set that minimizes the absolute value of the deviation from the side length constraint (i.e., the difference in physical memory addresses minus the maximum path span threshold). The selection criterion for the optimal reassembly parameters is to prioritize satisfying pathspace locality (minimum physical address span), because among the three types of constraints, the physical address span directly affects the fragment read speed. Delay is the dominant factor affecting the overall response time of collaborative signatures.

[0063] After determining the optimal reassembly parameters, the server, based on the valid node topology path corresponding to the optimal parameters, clears the original set of ineligible candidate shards and initiates sub-shard secure read requests node by node according to the new compliant path. It then re-collects all server private key sub-shards that meet the constraints of storage, latency, and address span, forming the optimal compliant shard set. The server performs a full Shamir threshold secret sharing inverse reconstruction operation on the optimal compliant shard set, uses the Lagrange interpolation algorithm to restore the global private key, and obtains the complete and compliant reassembled server private key. .

[0064] The server uses the reconstructed server private key, the first hash integer from the first signature parameter set, and elliptic curve points to participate in the server-side computation of the SM2 collaborative signature. Specifically, the server calls a hardware random number generator to generate a second random number. and the third random number Both are integers greater than or equal to one and less than the order of the elliptic curve. Calculate the points of the second elliptic curve. ,in The SM2 national standard elliptic curve point is a fixed base point and serves as the fundamental reference point for elliptic curve cryptography operations. Cooperative elliptic curve point. ,in These are elliptic curve points in the first set of signature parameters. Let the co-elliptic curve points be... The affine coordinates are , ; Calculate the second signature large integer In the formula: It is the first hash of the large integer; Let be the order of the elliptic curve. or If so, then the second and third random numbers will be regenerated and recalculated.

[0065] Calculate the intermediate component of the second signature on the server side. In the formula: The reconstructed server private key; calculate the intermediate component of the server's third signature. In the formula: The second signature is a large integer.

[0066] large integers Large integers (middle component of the second signature) Large integers (middle component of the third signature) The second signature parameter set is obtained by performing structured encapsulation with the same format as the first signature parameter set. The server sends the second signature parameter set to the collaborating end via a secure channel. The collaborating end receives the second signature parameter set and extracts the large integer from it. , large integer and large integers The collaborating end will handle large integers. With large integers Perform a modulo addition operation to obtain the intermediate signature component, i.e. .

[0067] The collaborating end will use the intermediate signature component Second signature large integer and private key sharding on the collaborating end Participate in the collaborative signature deblinding operation. The purpose of the deblinding operation is to eliminate the random blinding factor introduced in the server-side operation (i.e., and ), recovering only the private key from the collaborating end The standard signature uniquely determined by the SM2 standard signature formula Components. The formula for inverse blinding is: ; In the formula: Fragment the private key for the collaborating end; denoted as the order of the elliptic curve.

[0068] Collaborating end verifies final signature large integer The legitimacy, if or If not, the current collaborative signature is invalid, and the collaborating end will re-initiate the collaborative signature request (starting from step 1). and The final signature is a large integer. For a valid signature component, the coordinating end outputs... As the final large integer signature.

[0069] In a preferred embodiment of the present invention, step 6 is performed as follows: The collaborating end extracts a large integer from the second signature parameter set. , denoted as the second signature large integer The second signature large integer That is, the co-elliptic curve points in the second signature parameter set. The X coordinate and the first hash large integer The sum of the orders of the elliptic curves The result of modulo is specifically as follows: .

[0070] The collaborating end will ultimately sign a large integer. The 256-bit byte string and the second signature large integer The 256-bit byte string is arranged in a fixed byte order ( The byte string comes first. The byte string (with the first byte at the end) is concatenated and processed. The length of the concatenated byte string is 512 bits (64 bytes). This concatenation format is completely consistent with the signature data format specified in the Chinese national cryptographic standard SM2 digital signature algorithm.

[0071] The collaborating end performs a format compliance check on the concatenated and merged data. The check rules include: First, whether the total length of the byte string is equal to 64 bytes (512 bits); Second, ... byte string and Third, are the first bytes of each byte string a positive integer? and Do all the values ​​fall within the legal range? Inside; Fourth, will Substitute into the SM2 standard signature verification formula (using the collaborative public key) Perform local pre-signature verification to determine if the pre-signature verification is successful. Specifically, this relies on the collaborative public key. First hash large integer e, signature component The verification process follows the complete workflow of the standard signature verification algorithm, performing step-by-step calculations and judgments, i.e., reconfirmation. , If any value exceeds the limit, the pre-verification is immediately deemed unsuccessful, and all verifications are terminated; then, the elliptic finite field modular addition operation is performed, i.e. ;like If the calculation result is 0, the pre-verification check is deemed unsuccessful, and subsequent point calculations will not be performed; the SM2 standard is used as the fixed base point. Global collaborative public key Using these as the bases for scalar multiplication, the Montgomery ladder algorithm is used to calculate... , Two sets of elliptic points; after the two sets of scalar multiplications are completed, the x and y coordinates of each are reduced modulo the prime field, outputting two valid elliptic points within the finite field; the two valid elliptic points are then subjected to SM2 standard finite field point addition operations to generate the verification benchmark elliptic points. = ,extract Affine x-coordinates; using the x-coordinates of the verification points Perform modulo addition and modulo operation on the hash integer e to calculate the comparison value. Complete comparison With the second signature large integer All 256-bit large integer values; only when and If the two values ​​are completely equal, the local pre-verification is deemed to have passed; if there is any bit difference between the two values, the pre-verification is deemed to have failed, indicating that the signature data has been tampered with, the transmission is abnormal, or the two-end collaborative operation has failed.

[0072] After all four format compliance checks pass, the collaborating end will merge the data and output the target collaborative signature data. The target collaborative signature data can be used in the subsequent digital signature verification process. The verifying party can complete the signature verification using the collaborative public key and the SM2 standard verification algorithm without needing to be aware of the internal details involved in the signature generation process, such as the splitting of private keys between the two ends, distributed storage, and topology reconstruction.

[0073] It should be noted that the complete collaborative signature process consisting of steps 1 to 6 above is executed in one round each time a collaborative signature request arrives. Among them, the latency detection, congestion clustering and topology reconstruction mapping generation processes in steps 2 to 4 are calculated in real time according to the current network status and node load for each signature request, ensuring that the sharding read path is always optimally adapted to the real-time operating status of the system, thus avoiding the performance degradation problem caused by the fixed sharding read path in traditional solutions.

[0074] like Figure 2 As shown, embodiments of the present invention also provide a collaborative signature system based on dual-end private key fragmentation, comprising: The collaborative operation module is used to obtain the data to be signed and participate in the collaborative operation, determine the first hash large integer and the first elliptic curve point, and obtain the first signature parameter set. The feature extraction module is used to receive the first signature parameter set on the server side, extract the response latency of the sharded storage nodes, calculate the per-node response latency drop difference between adjacent nodes, and obtain the latency drop difference sequence; divide the steady-state response cluster and transient congestion cluster according to the latency drop difference sequence, and extract the node set of the transient congestion cluster. The reconstruction determination module is used to accumulate the congestion depth value node by node in the transient congestion cluster node set to obtain the accumulated congestion depth value; extract the remaining computing resources of each node in the steady-state response cluster, summarize to obtain the total available computing power value, multiply the total available computing power value by the maximum queue processing capacity of a single node to obtain the processing capacity threshold, and compare the accumulated congestion depth value with the processing capacity threshold to obtain the topology reconstruction determination result. The reorganization mapping module is used to determine the target reorganization mapping based on the topology reconstruction determination results; The computation and processing module is used to fragment and reassemble the private keys of both ends according to the target reassembly mapping and participate in the collaborative signature operation to obtain the second signature parameter set; based on the second signature parameter set, combined with the fragmentation of the private keys of the collaborative end, reverse blind computation processing is performed to obtain the final signature large integer; The merging module is used to concatenate and process the final signature large integer with the second signature large integer in the second signature parameter set to obtain the target collaborative signature data.

[0075] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0076] Embodiments of the present invention also provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0077] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A collaborative signature method based on dual-end private key fragmentation, characterized in that, The method includes: Step 1: Obtain the data to be signed and participate in the collaborative operation to determine the first hash large integer and the first elliptic curve point, and obtain the first signature parameter set; Step 2: The server receives the first signature parameter set, extracts the response latency of the sharded storage nodes, calculates the per-node response latency drop difference between adjacent nodes, and obtains the latency drop difference sequence; based on the latency drop difference sequence, it divides the steady-state response cluster and the transient congestion cluster, and extracts the node set of the transient congestion cluster. Step 3: Accumulate the congestion depth value for each node in the transient congestion cluster node set to obtain the accumulated congestion depth value; extract the remaining computing resources of each node in the steady-state response cluster, summarize to obtain the total available computing power value, multiply the total available computing power value by the maximum queue processing capacity of a single node to obtain the processing capacity threshold, and compare the accumulated congestion depth value with the processing capacity threshold to obtain the topology reconstruction judgment result. Step 4: Determine the target reorganization mapping based on the topology reconstruction determination results; Step 5: Reassemble the private key fragments of both ends according to the target reassembly mapping and participate in the collaborative signature operation to obtain the second signature parameter set; Based on the second signature parameter set, perform reverse blinding calculation processing in combination with the private key fragments of the collaborative end to obtain the final large integer signature. Step 6: Concatenate and process the final signature large integer with the second signature large integer in the second signature parameter set to obtain the target collaborative signature data.

2. The collaborative signature method based on dual-end private key fragmentation according to claim 1, characterized in that, Step 1 includes: Obtain the byte stream of the data to be signed, input the data to be signed into the digest compression algorithm to perform block hash operation, and obtain multiple compressed results; concatenate the multiple compressed results according to the timestamp order to obtain a large integer e; Extract the associated curve parameters of the collaborative end public key to obtain the coefficients of the elliptic curve equation and the order of the elliptic curve; call the hardware random number generator to generate the first random number to obtain the large integer k1; The large integer e and the large integer k1 are concatenated byte by byte to obtain the base point seed value; the base point seed value is then moduloed with the elliptic curve order to obtain the x-coordinate value. Substitute the x-axis values ​​into the elliptic curve equation corresponding to the coefficients of the elliptic curve equation to calculate the y-axis values. The x-coordinate values ​​are combined with the y-coordinate values ​​to obtain the base point of the dynamic elliptic curve; a scalar multiplication operation is performed between the large integer k1 and the base point of the dynamic elliptic curve, and the result of the multiplication operation is mapped to a finite field to obtain the elliptic curve point q1. The large integer e, the large integer k1, the base point of the dynamic elliptic curve, and the elliptic curve point q1 are encapsulated as parameters to obtain the first signature parameter set.

3. The collaborative signature method based on dual-end private key fragmentation according to claim 2, characterized in that, Step 2 includes: The sharded storage nodes and the server private key shards have a one-to-one storage relationship, that is, each sharded storage node uniquely stores one server private key shard, and the physical memory address of the node is linearly mapped to the logical index number of the corresponding shard; the sharded storage node identifier list is extracted from the first signature parameter set, probe messages are sent to each sharded storage node in the sharded storage node identifier list, and the response latency of each node returning the acknowledgment message is recorded to obtain the node response latency set; The node response latency set is sorted according to the node's physical memory address, and the response latency difference between adjacent nodes is calculated to obtain the per-node response latency drop value. The per-node response latency drop value is then arranged in timestamp order to obtain the latency drop value sequence.

4. The collaborative signature method based on dual-end private key fragmentation according to claim 3, characterized in that, Based on the time delay drop difference sequence, steady-state response clusters and transient congestion clusters are divided, and the node set of the transient congestion cluster is extracted, including: Calculate the local mean within a sliding window centered on the current node in the latency drop difference sequence, filter out the nodes corresponding to the node-by-node response latency drop difference values ​​that are greater than the local mean, mark the filtered nodes as transient congestion nodes, and obtain the set of transient congestion nodes. The transient congestion node set is aggregated and divided into transient congestion clusters, and the remaining nodes are divided into steady-state response clusters to obtain the cluster division results; the server extracts the identifiers of all nodes in the transient congestion clusters to obtain the transient congestion cluster node set.

5. The collaborative signature method based on dual-end private key fragmentation according to claim 4, characterized in that, Step 3 includes: The queue length of each node in the transient congestion cluster node set is extracted as the congestion depth value; the server accumulates the congestion depth value node by node to obtain the accumulated congestion depth value. Extract the remaining computing resources of each node within the steady-state response cluster and summarize them to obtain the total available computing power. Compare the accumulated congestion depth value with the processing capacity threshold, which is the product of the total available computing power value and the maximum queue processing capacity of a single node. When the accumulated congestion depth value is greater than the processing capacity threshold, a cross-cluster reconfiguration flag is generated; otherwise, a local reconfiguration flag is generated, and the topology reconfiguration determination result is obtained.

6. The collaborative signature method based on dual-end private key fragmentation according to claim 5, characterized in that, Step 4 includes: If the identifier type in the topology reconstruction determination result is a local reorganization identifier, then select nodes with adjacent physical addresses within the steady-state response cluster and construct a local nearest reorganization mapping. If the identifier type in the topology reconstruction determination result is a cross-cluster reconstruction identifier, then the dynamic reading step size is determined based on the difference between the accumulated congestion depth value and the processing capacity threshold. The node with the smallest physical address value in the transient congested cluster is the first fragmentation addressing identifier, the node with the largest physical address value is the second fragmentation addressing identifier, and the node with the smallest absolute difference between the address value of the second fragmentation addressing identifier and the node in the steady-state response cluster is the third fragmentation addressing identifier. Starting with the address value corresponding to the second fragment addressing identifier, addressing is performed incrementally in the increasing direction with a step size to determine the position of the cross-cluster addressing cursor; When the difference between the cross-cluster addressing cursor position and the third fragment addressing identifier address value is less than the dynamic read step size, the progressive addressing stops. During this progressive addressing process, all nodes corresponding to the cross-cluster addressing cursor positions are marked as the bridged fragment storage node set. According to the physical memory address values ​​in ascending order, the first fragment addressing identifier, the second fragment addressing identifier and each node in the bridge fragment storage node set are sequentially linked to construct a cross-cluster distributed reassembly mapping. The local nearest reorganization map or the cross-cluster distributed reorganization map is output as the target reorganization map.

7. The collaborative signature method based on dual-end private key fragmentation according to claim 6, characterized in that, Step 5 includes: Extract the corresponding server-side private key fragments based on the node path indicated by the target reassembly mapping to obtain a candidate fragment set; A spatial distribution map of the fragmentation is constructed using the physical memory address values ​​of the nodes where each fragment is located in the candidate fragmentation set as vertex coordinates. The physical address difference between adjacent fragments, the remaining storage capacity of each node, and the communication latency between each node are used as the side length constraint, capacity constraint, and latency constraint, respectively, to establish a set of fragmentation reorganization constraint equations. The constraint equations are transformed into a parameterized expression with physical address, storage capacity, and communication latency as the parameters to be solved. A constraint satisfaction check is then performed on the parameterized expression. If all constraints are satisfied, the server private key fragments in the candidate fragment set are directly reassembled according to the target reassembly mapping to obtain the reassembled server private key. If any constraint is not satisfied, the process switches to optimization reassembly to obtain the optimal reassembly parameters. The server private key fragments in the candidate fragment set are then reassembled according to the optimal reassembly parameters to obtain the reassembled server private key. The recombined server private key, the large integer e from the first signature parameter set, and the elliptic curve point q1 are used to participate in the collaborative signature operation, and the output is a second signature parameter set containing large integers r, s2, and s3. Extract r, s2, and s3 from the second signature parameter set. Add s2 and s3 modulo to obtain the intermediate signature component. Perform reverse blinding operation on the intermediate signature component, r, and the collaborating private key d1 to obtain the final signature large integer s.

8. The collaborative signature method based on dual-end private key fragmentation according to claim 7, characterized in that, Step 6 includes: Extract a large integer r from the second signature parameter set, denoted as the second signature large integer r, which is the hash value of the x-coordinate of the elliptic curve point in the second signature parameter set; concatenate and merge the final signature large integer s with the second signature large integer r in a fixed byte order to obtain concatenated and merged data; perform a format compliance comparison on the concatenated and merged data, and obtain the target collaborative signature data after the comparison is passed.

9. A collaborative signature system based on dual-end private key fragmentation, the system implementing the method as described in any one of claims 1 to 8, characterized in that, include: The collaborative operation module is used to obtain the data to be signed and participate in the collaborative operation, determine the first hash large integer and the first elliptic curve point, and obtain the first signature parameter set. The feature extraction module is used to receive the first signature parameter set from the server, extract the response latency of the sharded storage nodes, calculate the per-node response latency drop difference between adjacent nodes, and obtain the latency drop difference sequence. Based on the time delay drop difference sequence, the steady-state response cluster and the transient congestion cluster are divided, and the node set of the transient congestion cluster is extracted; The reconstruction determination module is used to accumulate the congestion depth value node by node in the transient congestion cluster node set to obtain the accumulated congestion depth value; extract the remaining computing resources of each node in the steady-state response cluster, summarize to obtain the total available computing power value, multiply the total available computing power value by the maximum queue processing capacity of a single node to obtain the processing capacity threshold, and compare the accumulated congestion depth value with the processing capacity threshold to obtain the topology reconstruction determination result. The reorganization mapping module is used to determine the target reorganization mapping based on the topology reconstruction determination results; The computation and processing module is used to fragment and reassemble the private keys of both ends according to the target reassembly mapping and participate in the collaborative signature operation to obtain the second signature parameter set; based on the second signature parameter set, combined with the fragmentation of the private keys of the collaborative end, reverse blind computation processing is performed to obtain the final signature large integer; The merging module is used to concatenate and process the final signature large integer with the second signature large integer in the second signature parameter set to obtain the target collaborative signature data.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when executed by a processor, implements the method as described in any one of claims 1 to 8.

Images