Electronic signature system and method based on commercial cryptographic technology and storage medium

Abstract

The application discloses an electronic signing system and method based on commercial cryptographic technology and a storage medium, and particularly relates to the field of distributed storage security technology. The electronic contract signing request is initiated at a first signing node, and the signing data is encrypted using a commercial cryptographic algorithm, and then the encrypted data is distributed to multiple signing nodes using the security channel of the commercial cryptographic protocol. After receiving the signing request, each signing node verifies the signing data and the key state using a distributed consistency algorithm, generates a local signature after verification, and aggregates the local signature to form a final signature result. A fuzzy logic-based analytic hierarchy model and a time series decomposition model are used to analyze the path and response consistency of the signing nodes to determine the credibility of the signature result. When the result is credible, the signed electronic contract is stored in a distributed ledger, and if the result is not credible, a re-verification mechanism is triggered to ensure the security and consistency of the signing data.

Description

Technical Field

[0001] The present invention relates to the field of distributed storage security technology, and more specifically, to an electronic signing system, method and storage medium based on commercial cryptographic technology. Background Art

[0002] With the rapid development of internet technology and the improvement of information technology, electronic contracts have gradually become a common contract signing method for governments, businesses, and individual users. Compared with traditional paper contracts, electronic contracts offer significant advantages in convenience and efficiency, significantly reducing the time cost of contract signing and management. Existing technologies typically use encryption, digital signatures, and multi-node distributed storage to enhance the immutability and data consistency of contracts. However, in multi-party collaborative electronic contract signing scenarios, the contract data and authentication information involved are often distributed across different nodes, which may be located in different network environments and are independent and decentralized.

[0003] In multi-party collaborative electronic signing scenarios, the data and authentication information involved are often distributed across different nodes. However, to ensure the immutability and efficient signing of electronic contracts, the signing data and key distribution status must be synchronized in real time across distributed nodes to maintain the consistency of the signing results. However, if the distributed consistency of data cannot be guaranteed in the high-frequency multi-node signing requests, the credibility of the signing results will be reduced and the risk of data tampering will increase, thus affecting the efficiency of signing.

[0004] In order to solve the above problems, a technical solution is now provided. Summary of the Invention

[0005] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide an electronic signing system, method and storage medium based on commercial cryptographic technology to solve the problems raised in the above-mentioned background technology.

[0006] To achieve the above object, the present invention provides the following technical solutions:

[0007] The electronic signing method based on commercial cryptographic technology includes the following steps:

[0008] Initiate an electronic contract signing request at the first signing node, encrypt the signing data using a commercial cryptographic algorithm, and distribute the encrypted data to multiple signing nodes via a secure channel using the commercial cryptographic protocol;

[0009] After receiving the signing request, each signing node uses a distributed consistency algorithm to verify the signing data and key status. If the verification is successful, it proceeds to the next step;

[0010] Generate local signatures at the signing nodes that have passed verification and aggregate them into the final signature result;

[0011] A hierarchical analysis model based on fuzzy logic was used to analyze the distribution of consensus paths among contracting nodes and assess the path differences between contracting nodes. Time series decomposition and a composite cointegration model were used to analyze the response time differences among contracting nodes and assess the consistency of consensus responses among contracting nodes.

[0012] Based on the path differences and consensus response consistency between signing nodes, determine whether to trust the final signature result;

[0013] When the final signature result is trusted, the signed electronic contract of the final signature result is stored in the distributed ledger; when the final signature result is not trusted, the signing node re-verification mechanism is triggered.

[0014] In a preferred embodiment, an electronic contract signing request is initiated at the first signing node, and the signing data is encrypted using a commercial cryptographic algorithm. The encrypted data is distributed to multiple signing nodes via a secure channel of the commercial cryptographic protocol. Specifically,

[0015] The first signing node generates a signing request for the electronic contract and integrates the request information into the signing data to form a complete signing data package;

[0016] Encrypt the signed data packet using a commercial cryptographic algorithm;

[0017] Establishing a secure communication channel through the first signing node based on a commercial cryptographic protocol;

[0018] The encrypted signing data is sent to multiple signing nodes through the established secure communication channel.

[0019] In a preferred embodiment, after receiving the signing request, each signing node uses a distributed consensus algorithm to verify the signing data and key status. If the verification is successful, the next step is to proceed to the following:

[0020] Each signing node receives the encrypted signing data packet from the first signing node and decrypts the data packet to obtain the signing data content;

[0021] Each signing node confirms whether the received signing data packet is complete through the consistency check mechanism;

[0022] Decrypt the encrypted contract data packet using the key of the commercial cryptographic algorithm to obtain the plaintext information of the contract data;

[0023] Each signing node uses a distributed consistency algorithm to verify the consistency of the decrypted signing data to confirm that the data content is consistent across all nodes;

[0024] Each signing node verifies the key status according to the distributed consistency algorithm to ensure that the key distribution status of each node is consistent. If the verification is passed, it proceeds to the next step.

[0025] In a preferred embodiment, a local signature is generated at the verified signing node and aggregated into a final signature result, specifically:

[0026] Each signing node extracts key information from the decrypted signing data and generates a local signature using the private key;

[0027] After generating the local signature, each signing node encapsulates the signature, adds the signing node identifier and the signing data summary;

[0028] Each signing node transmits the encapsulated local signature to the signature aggregation center node, which receives and confirms the validity of the signature;

[0029] The aggregation center node combines the local signatures of all signing nodes into the final signature result through a commercial cryptographic signature aggregation algorithm.

[0030] In a preferred embodiment, the consensus path distribution of each contracting node is analyzed based on a fuzzy logic-based hierarchical analysis model to evaluate the path differences between contracting nodes, specifically:

[0031] Load the fuzzy logic-based hierarchical analysis model at the aggregation center node and set the initial parameters and model structure for path difference evaluation;

[0032] Each signing node uploads the path data of its participation in the signing consensus process to the aggregation center node;

[0033] According to the requirements of the hierarchical analysis model, weights are set for key factors in the path;

[0034] The aggregation center node generates a path difference matrix based on the collected data and the set weights, forming a difference relationship between the path distributions of each contracting node;

[0035] Analyze the path difference matrix to determine whether the comprehensive difference between each signing node on the consensus path is too large.

[0036] In a preferred embodiment, the response time differences between the contracting nodes are analyzed by time series decomposition and compound cointegration model to evaluate the consensus response consistency between the contracting nodes, specifically:

[0037] Load the time series decomposition model at the aggregation center node and set the initial parameters for response time difference analysis;

[0038] The response time data of each signing node during the consensus process is uploaded to the aggregation center node to form a response time series;

[0039] The aggregation center node decomposes the collected response time series into trend and seasonality to extract key time features;

[0040] The decomposed response time series data are input into the composite cointegration model to identify the time response relationship between contracting nodes;

[0041] The aggregation center node analyzes and reviews the cointegration results to determine whether the response time differences between the contracting nodes remain consistent.

[0042] In a preferred embodiment, whether to trust the final signature result is determined based on the path differences and consensus response consistency between the signing nodes, specifically:

[0043] When the comprehensive differences among the signing nodes on the consensus path are not too large and the response time differences between the signing nodes remain consistent, the final signature result is determined to be trusted; otherwise, the final signature result is determined to be distrusted.

[0044] In a preferred embodiment, when the final signature result is not trusted, the signing node re-verification mechanism is triggered, specifically:

[0045] The aggregation center node triggers the re-verification mechanism of the contracting node;

[0046] Under the re-verification mechanism, the signing nodes re-collect and verify their respective signing data and key status, and submit them again after completion;

[0047] The aggregation center node re-determines the credibility of the signature result based on the re-verified data and decides whether to store it in the distributed ledger.

[0048] On the other hand, the present invention provides an electronic signing system based on commercial cryptographic technology, including a signing request initiation module, an encrypted data distribution module, a local signature generation module, a consensus path analysis module, a response time analysis module, a signature result determination module, and a signature result storage module;

[0049] Signing request initiation module: initiates an electronic contract signing request at the first signing node, encrypts the signing data using a commercial cryptographic algorithm, and distributes the encrypted data to multiple signing nodes through a secure channel using a commercial cryptographic protocol;

[0050] Encrypted data distribution module: After receiving the signing request, each signing node uses a distributed consistency algorithm to verify the signing data and key status. If the verification is successful, it proceeds to the next step;

[0051] Local signature generation module: Generates local signatures at the verified signing nodes and aggregates them into the final signature result;

[0052] Consensus path analysis module: Based on the fuzzy logic hierarchical analysis model, it analyzes the consensus path distribution of each contracting node and evaluates the path differences between contracting nodes;

[0053] Response time analysis module: Analyzes the response time differences between contracting nodes through time series decomposition and compound cointegration models, and evaluates the consensus response consistency between contracting nodes;

[0054] Signature result judgment module: Based on the path differences and consensus response consistency between the signing nodes, it determines whether to trust the final signature result;

[0055] Signature result storage module: When the final signature result is trusted, the signed electronic contract of the final signature result is stored in the distributed ledger; when the final signature result is not trusted, the signing node re-verification mechanism is triggered.

[0056] On the other hand, the present invention also provides a computer-readable storage medium, which stores a program or instruction. When the program or instruction is executed by a processor, an electronic signing method based on commercial cryptographic technology is implemented.

[0057] The technical effects and advantages of the electronic signing system, method, and storage medium based on commercial cryptographic technology of the present invention are as follows:

[0058] 1. The present invention effectively improves the security and consistency of electronic contracts in multi-party collaborative contracting scenarios through an electronic signing method based on commercial cryptographic technology. By initiating an electronic contract signing request and encrypting data at the first signing node, and then distributing the encrypted data to multiple signing nodes through the secure channel of the commercial cryptographic protocol, the secure transmission of the contract data in a distributed environment is ensured. After each signing node receives the data, a distributed consistency algorithm is used to verify the contract data and key status, thereby improving the distributed consistency in the multi-node environment, ensuring the synchronization of data and key distribution status, preventing data inconsistency problems caused by different network environments, and improving the credibility and efficiency of the contract signing process.

[0059] 2. The present invention further comprehensively evaluates the path differences and response time consistency between contracting nodes through the hierarchical analysis model of fuzzy logic, time series decomposition and composite cointegration model, thereby adding a multi-dimensional verification mechanism when determining the final signature result. The credibility of the signature result is comprehensively judged based on the path and response consistency, effectively reducing the potential risk of data tampering caused by response differences or path differences between nodes. When the signature result is judged to be credible, the signed electronic contract of the final signature result can be directly stored in the distributed ledger to ensure the non-tamperability and traceability of the contract; if the judgment result is untrustworthy, the re-verification mechanism of the contracting node is triggered, ensuring the efficiency and data security of the entire contracting process. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 This is a schematic diagram of the electronic signing method based on commercial encryption technology of the present invention;

[0061] Figure 2 This is a schematic diagram of the structure of the electronic signing system based on commercial encryption technology of the present invention. DETAILED DESCRIPTION

[0062] The following will provide a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0063] Example 1

[0064] Figure 1 The present invention provides an electronic signing method based on commercial cryptographic technology, which includes the following steps:

[0065] An electronic contract signing request is initiated at the first signing node, and the signing data is encrypted using a commercial cryptographic algorithm, and the encrypted data is distributed to multiple signing nodes through the secure channel of the commercial cryptographic protocol.

[0066] After receiving the signing request, each signing node uses a distributed consistency algorithm to verify the signing data and key status. If the verification is successful, it proceeds to the next step.

[0067] A local signature is generated at the signing node that passes the verification and aggregated into the final signature result.

[0068] The hierarchical analysis model based on fuzzy logic is used to analyze the distribution of consensus paths among each signing node and evaluate the path differences among the signing nodes; the response time differences among the signing nodes are analyzed through time series decomposition and composite cointegration model to evaluate the consistency of consensus responses among the signing nodes.

[0069] Based on the path differences and consensus response consistency between signing nodes, determine whether to trust the final signature result.

[0070] When the final signature result is trusted, the signed electronic contract of the final signature result is stored in the distributed ledger; when the final signature result is not trusted, the signing node re-verification mechanism is triggered.

[0071] The electronic contract signing request is initiated at the first signing node, and the signing data is encrypted using a commercial cryptographic algorithm. The encrypted data is distributed to multiple signing nodes through the secure channel of the commercial cryptographic protocol. Specifically:

[0072] The first signing node generates a signing request for the electronic contract and integrates the request information into the signing data to form a complete signing data package:

[0073] In the initial stage of the electronic signing process, the first signing node assumes the role of initiating the electronic contract signing request.

[0074] After receiving the contract request, the first signing node internally generates an electronic contract signing request, which contains the relevant contract data and accompanying information. To facilitate data integrity and security management during subsequent distribution, the first signing node organizes the key information in the signing request and integrates it into the contract data, thus forming a complete contract data package. This package not only contains the contract content itself but also includes essential information involved in the contract process, such as the signing request identifier, party information, and the signing timestamp. This complete data package ensures a consistent data structure in subsequent operations.

[0075] The signed data packet is encrypted using a commercial cryptographic algorithm to ensure the security of the signed data during subsequent transmission:

[0076] The first signing node generates a pair of keys for the encryption process: a public key and a private key. The public key is used for data encryption, while the private key is used for data decryption. Commercial cryptographic algorithms employ asymmetric encryption mechanisms to ensure data security in multi-node environments. Specifically, after receiving a data packet, the first signing node invokes a commercial cryptographic algorithm based on a preset encryption standard to encrypt the data packet. The encrypted data packet becomes the "encrypted signing data packet." Key generation during the encryption process adheres to commercial cryptographic standards and ensures the uniqueness and unpredictability of the keys.

[0077] During this process, the data packet content is processed into ciphertext by a commercial cryptographic algorithm, and its calculation expression is: C = E PublicKey (M); where E represents the encryption function of the commercial cryptographic algorithm, PublicKey represents the public key generated in the commercial cryptographic algorithm, M is the plaintext content of the contract data packet, and C is the encrypted contract data packet.

[0078] Among them, the plain text content of the signing data packet includes the signing request, contract content, participant information and timestamp, etc.

[0079] After the encryption process is completed, the generated encrypted contract data packet will be used as the transmission content for subsequent distribution to ensure that even if the transmission channel is potentially threatened, the contract data content cannot be maliciously interpreted.

[0080] Based on commercial cryptographic protocols, a secure communication channel is established through the first signing node, providing an encrypted channel for subsequent data distribution:

[0081] The first signing node uses the key exchange mechanism of a commercial cryptographic protocol to ensure secure key exchange with each signing node. This process is based on pre-defined security standards and verifies the node's identity through the commercial cryptographic protocol's authentication mechanism, ensuring that the recipient is a trusted signing node. The first signing node then securely distributes the generated symmetric encryption key to the other signing nodes, establishing the symmetric key transmission foundation required for data transmission. This key exchange mechanism utilizes the commercial cryptographic protocol's built-in encryption algorithm to ensure key uniqueness and randomness.

[0082] When establishing a secure communication channel, the security of the transmission channel is ensured through authentication and key exchange using commercial cryptographic protocols. The process of establishing a secure communication channel is as follows:

[0083] Node identity authentication: The first signing node confirms the identity of each receiving node to ensure that they are all valid signing nodes.

[0084] Symmetric key generation and distribution: The first signing node generates a transmission symmetric key and encrypts it and sends it to other signing nodes.

[0085] Communication channel establishment: After key distribution and identity authentication are completed, a secure communication channel is formally established between the first signing node and the signing node based on the transmission standard of the commercial cryptographic protocol.

[0086] In subsequent data distribution, all data transmission is completed through this communication channel to ensure the confidentiality and integrity of the communication process.

[0087] Commercial cryptographic protocols are used for identity authentication and key exchange between nodes to ensure the legitimacy of each node's identity.

[0088] The encrypted signing data is sent to multiple signing nodes through the established secure communication channel, ensuring that each signing node receives the complete encrypted data:

[0089] The first signing node encapsulates the encrypted signing data packet as the content of data distribution. The data packet contains the metadata required by the signing node to receive the data packet, including the data packet identifier, distribution batch number, etc.

[0090] After the encapsulation is completed, the first signing node transmits the encrypted signing data packet to each signing node one by one through the established secure communication channel to ensure that all nodes receive the complete encrypted data packet.

[0091] After receiving the encrypted signing data packet, each signing node generates a receipt message and feeds it back to the first signing node through a secure channel to confirm that the data was successfully received.

[0092] After receiving the signing request, each signing node uses a distributed consensus algorithm to verify the signing data and key status. If the verification is successful, it proceeds to the next step, which is:

[0093] Each signing node receives the encrypted signing data packet from the first signing node and decrypts the data packet to obtain the signing data content:

[0094] After receiving the encrypted contract data packet from the first contracting node, each contracting node first decapsulates the packet. This decapsulation process specifically involves reading the contract information and other necessary metadata within the packet, such as the contract request identifier, contract data length, and the sending node identifier. This decapsulation process enables each contracting node to accurately locate the packet content and the storage location of the contract information, laying the foundation for subsequent data verification and decryption operations.

[0095] Each signing node confirms whether the received signing data packet is complete through the consistency check mechanism:

[0096] Specifically, each signing node uses a hash function to perform a hash operation on the decapsulated data content based on a preset consistency check mechanism, and compares the hash value with the hash value attached to the packet header. The calculation expression is: V = H(D); where V is the hash value generated by the node, H is the hash function used in packet integrity verification, and D is the decapsulated signed data content.

[0097] If the hash value generated by the node calculated by each signing node is the same as the hash value attached to the data packet, it means that the data packet has not been tampered with during transmission. Each node confirms the integrity of the data packet, laying the foundation for subsequent decryption operations.

[0098] Use the key of the commercial cryptographic algorithm to decrypt the encrypted contract data packet to obtain the plaintext information of the contract data:

[0099] Each signing node calls the decryption function of the commercial cryptographic algorithm and its private key to decrypt the encrypted signing data packet.

[0100] The key to the decryption process is converting the encrypted contract data packet into plaintext using the private key, enabling consistency verification of the contract data content in subsequent steps. The decrypted plaintext contains the contracting parties, the contract content, and other additional information, ensuring the integrity of the data content and providing the data foundation for consistency verification.

[0101] Each signing node uses a distributed consistency algorithm to verify the consistency of the decrypted signing data to confirm that the data content is consistent across all nodes:

[0102] Each signing node generates a unique data summary based on the contract data it receives, which is used for consistency comparison across signing nodes. After generating the data summary, each signing node distributes the summary value to other signing nodes across the network for comparison and verification across multiple signing nodes. After receiving the data summaries from other signing nodes, each signing node compares them one by one to ensure that the data summaries generated by all signing nodes are consistent, thereby determining whether all signing nodes have the same contract data content.

[0103] If the data summaries generated by all signing nodes are consistent, the contracted data content of all signing nodes is consistent and the verification is successful. If the data summaries of any signing node are found to be different, the consistency verification is considered to have failed, indicating that the data content of some signing nodes may be different. In this case, the system will trigger the exception handling mechanism and re-verify or re-transmit the signing nodes with differences to ensure final consistency.

[0104] Each signing node verifies the key status according to the distributed consensus algorithm to ensure that the key distribution status of each node is consistent. If the verification is passed, the next step is entered:

[0105] Each signing node generates a key status identification message containing a summary of the current signing node's key status. Each signing node distributes this key status identification message to the network for consistency comparison with other signing nodes. Upon receiving key status information from other signing nodes, each signing node compares its identification message with the other signing nodes to ensure consistency across all signing nodes in a multi-signing node environment.

[0106] If the key status identifiers of all signing nodes are consistent, the key status is consistent across the signing nodes, verification is successful, and the next step is advanced. If the key status identifiers of any signing node are different, the consistency verification fails, indicating that the key status of some signing nodes is inconsistent. The system triggers a redistribution or update mechanism to ensure that the key status of all signing nodes remains consistent.

[0107] The local signature is generated at the signing node that passes the verification and aggregated into the final signature result, specifically:

[0108] Each signing node extracts key information from the decrypted signing data and generates a local signature using the private key:

[0109] Each signing node extracts key contract-related information from the decrypted contract data, including the contract details, party identifiers, and timestamps. It then uses a commercial cryptographic signature algorithm to generate a local signature. The signature generation process uses each signing node's private key to sign the contract data, generating a unique signature for that signing node.

[0110] After generating the local signature, each signing node encapsulates the signature, adding the signing node identifier and the signing data summary:

[0111] After generating a local signature, each signing node encapsulates the signature result. This encapsulated data package includes the generated local signature, the signing node identifier, and the signed data summary, ensuring that each signing node's signature can be accurately distinguished during the subsequent signature aggregation process. This encapsulation step, completed by each signing node, provides standardized input for the subsequent signature aggregation step.

[0112] Each signing node transmits the encapsulated local signature to the signature aggregation center node, which receives and confirms the validity of the signature:

[0113] After the encapsulation is complete, each signing node passes its local signature to the preset signature aggregation center node. The aggregation center node is responsible for receiving the local signatures of all signing nodes and confirming the signature content of each signing node to ensure that all transmitted signatures are valid signatures generated by nodes that have undergone consistency verification.

[0114] The aggregation center node combines the local signatures of all signing nodes into the final signature result through the commercial cryptographic signature aggregation algorithm:

[0115] After the central aggregation node receives the local signatures of all contracting nodes, it combines them into a single final signature using a commercial cryptographic signature aggregation algorithm. The central aggregation node first verifies the signature identification information of all contracting nodes, confirming that all signatures originate from verified contracting nodes. Once this verification is complete, the central aggregation node combines all signature information using an aggregation algorithm to generate a single, globally unique final signature. This final signature serves as the unique identifier for the electronic contract, ensuring its immutability.

[0116] After the final signature result is generated, the aggregation center node confirms the signature integrity and enters the storage stage after it meets the format and security standards:

[0117] After the final signature is generated, the aggregation center node verifies the integrity of the signature to ensure that it complies with the pre-set signature format and security standards. Once the verification is complete, the final signature will be stored and entered into the subsequent storage and distributed ledger recording stages.

[0118] The fuzzy logic-based hierarchical analysis model analyzes the consensus path distribution of each signing node and evaluates the path differences between signing nodes. Specifically:

[0119] Load the fuzzy logic-based hierarchical analysis model at the aggregation center node and set the initial parameters and model structure for path difference evaluation:

[0120] A fuzzy logic-based hierarchical analysis model is loaded into the aggregation center node for subsequent path differentiation assessment. Specifically, the aggregation center node configures the model structure and the required initial parameters, which form the basis for analyzing path distribution. The model structure uses the hierarchical analysis method to define key factors in the path hierarchically, allowing subsequent path data to be evaluated at different levels. When loading the model, the aggregation center node also sets specific fuzzy logic rules to meet the requirements of path differentiation analysis and ensure that the importance of path factors at each level can be reasonably distinguished through the model.

[0121] Each signing node uploads the path data of its participation in the signing consensus process to the aggregation center node:

[0122] After the AHP model is loaded, each contracting node uploads the path data generated during the contracting consensus process to the aggregation center. This path data includes key information such as each contracting node's node identity, path flow direction, and participating node timestamps. Uploading path data is a critical step in ensuring the aggregation center has access to the path distribution information for each contracting node. After receiving data from each contracting node, the aggregation center associates the path data with metadata such as the node identity and path generation time, enabling accurate tracking and comparison of path characteristics across nodes in subsequent path difference analysis.

[0123] According to the requirements of the hierarchical analysis model, weights are set for key factors in the path to ensure the hierarchical analysis role of each factor in the path difference assessment:

[0124] After the aggregation center receives path data from each contracting node, it assigns weights to key factors in the path according to the requirements of the hierarchical analysis model. This weighting is based on the actual needs of path differentiation assessment, ensuring that the model highlights the importance of key factors at different levels. For example, weights are assigned to key factors such as the number of node hops, the communication time difference between contracting nodes, and the response delay of the path. This weighting allows for a reasonable distribution of the impact of different factors in path differentiation assessment. The principle of weighting relies on the model's hierarchical analysis method, which assigns weights at each level to ensure that the contributions of different factors do not overlap.

[0125] After the weight setting is completed, the aggregation center node generates a weight set of each key factor, where each weight value represents the importance of the factor in the path difference analysis. Assume that the weight set is W = {w1, w2, w3, ..., w n}; where W is the weight set, w1, w2, w3, ..., w n Represent the weight value of each key factor respectively. These weights serve as important references in the subsequent analysis of the path difference matrix to control the proportion of factors at each level in the analysis results.

[0126] The aggregation center node generates a path difference matrix based on the collected data and the set weights, forming a difference relationship between the path distributions of each contracting node:

[0127] The aggregation center node processes the path data uploaded by each contracting node in a hierarchical manner and generates difference comparison values ​​based on each key factor. During this process, the aggregation center node uses the path data of each pair of contracting nodes and compares them layer by layer according to each key factor.

[0128] The path difference matrix is: Where P is the path diversity matrix, and m represents the total number of signing nodes participating in the consensus.

[0129] The calculation of the path difference matrix enables the aggregation center node to comprehensively analyze the path distribution differences between the contracting nodes.

[0130] Calculate the path difference index, and its calculation formula is: Among them, P i，j is the path difference index, which represents the path difference between the contracting node i and the contracting node j in the path difference matrix; w k Indicates the weight value of the kth key factor in the weight set; d i，j，k represents the path difference comparison value of the kth key factor at the signing node i and the signing node j; n represents the total number of key factors included in the path difference analysis; k represents the number of the key factor.

[0131] Each element of the path difference matrix is ​​compared layer by layer in the hierarchical analysis model, reflecting the path differences between each contracting node on different factors. After generating the path difference matrix, the aggregation center node obtains the overall difference relationship between the path distributions of each contracting node.

[0132] Analyze the path diversity matrix to determine whether the overall differences among the signing nodes on the consensus path are too large:

[0133] Set a difference threshold T, which is used to measure whether the path difference is within an acceptable range. The setting of the difference threshold T is based on the tolerance in actual applications to ensure that the path difference is within a reasonable range and does not affect the overall consistency.

[0134] For each P in the path diversity matrix i，j , the aggregation center node will P i，jCompare with the difference threshold T, the specific rules are as follows:

[0135] If P i，j ≤T, then the path difference between the signing node i and the signing node j is considered to be within an acceptable range and has no negative impact on consistency.

[0136] If P i，j >T, it is considered that the path difference between signing node i and signing node j is too large, which may pose a threat to consensus consistency.

[0137] The aggregation center node counts all the nodes that meet P in the path difference matrix. i，j >T items, record the items that meet P i，j >T number of contracted node pairs.

[0138] If P is satisfied i，j >T The number of contracting node pairs exceeds the corresponding preset ratio, then it is determined that the comprehensive difference between the contracting nodes on the consensus path is too large; if P i，j If the number of signing node pairs with a value greater than T does not exceed the corresponding preset ratio, it is determined that the comprehensive difference between the signing nodes on the consensus path is not too large.

[0139] The preset ratio is set by analyzing the distribution of path differences in historical data, and is usually set to the upper limit of the difference that the system can tolerate to ensure the overall consistency and stability of the consensus path.

[0140] The response time differences between contracting nodes are analyzed through time series decomposition and compound cointegration model, and the consensus response consistency between contracting nodes is evaluated. Specifically:

[0141] Load the time series decomposition model in the aggregation center node and set the initial parameters for response time difference analysis:

[0142] Load the time series decomposition model at the aggregation center node to prepare for response time difference analysis. When loading the model, you need to set the initial parameters according to the specific requirements of the consensus response consistency analysis.

[0143] Initialization parameters include the decomposition period, trend characteristics, seasonal frequency, etc. of the time series to ensure that the model can recognize different time characteristics.

[0144] For example, in a multi-node consensus scenario, the response time series may show a certain periodicity due to system load changes or network delays. The setting of initial parameters helps the model more accurately extract the trend and seasonal characteristics of the time series.

[0145] The response time data of each signing node during the consensus process is uploaded to the aggregation center node to form a response time series:

[0146] Response time data refers to the time it takes for each signing node to complete the signing response after receiving the signing request. Each data point represents the response time for a single signing request. Each signing node generates response time data multiple times during the consensus process, and this data is aggregated to the aggregation center node to form a time series.

[0147] The aggregation center node performs trend and seasonal decomposition on the collected response time series and extracts key time features:

[0148] After the aggregation center collects the response time series from all contracted nodes, it performs time series decomposition on these data to extract trend and seasonal characteristics. Trend decomposition is used to analyze long-term growth or decline trends in the response time series, while seasonal decomposition is used to identify cyclical fluctuation patterns in the time series.

[0149] The specific steps of decomposition include:

[0150] Trend decomposition: The aggregation center applies a moving average method to each response time series to extract the long-term trend characteristics of the series. The moving average method averages the response time data in each time period to produce a smooth curve of trend changes.

[0151] Seasonal decomposition: Use Fourier transform or other frequency analysis methods on response time series to identify seasonal fluctuations in the time series. Seasonal decomposition helps the aggregation center identify the periodic components of the time series, allowing analysis of response time changes caused by system load or network fluctuations.

[0152] The decomposed response time series data is input into the composite cointegration model to identify the time response relationship between contracting nodes:

[0153] The cointegration model is used to determine whether the response time series of two or more nodes have a long-term cointegration relationship, that is, whether they are consistent in trend and seasonality.

[0154] The basic formula of the compound cointegration model is as follows: a，b =αΘ a +βS a -(αΘ b +βS b ); among them, C a，b represents the cointegration difference index between node a and node b, Θ a and S a are the trend component and seasonal component of node a respectively, Θ b and S b are the trend component and seasonal component of node b, respectively. α and β are the weight parameters used to adjust the influence of trend and seasonal components, respectively.

[0155] If the cointegration difference index is close to zero, it means that nodes a and b have strong consistency in time response; otherwise, if the cointegration difference index deviates significantly from zero, it indicates that there is a large difference in response consistency between nodes a and b.

[0156] The aggregation center node analyzes and reviews the cointegration results to determine whether the response time differences between the contracting nodes are consistent:

[0157] The aggregation center node sets the cointegration difference threshold τ to measure whether the cointegration difference index is within an acceptable range. If some cointegration difference indices exceed the cointegration difference threshold τ, it means that the response consistency of these nodes is poor.

[0158] For each pair of nodes a and b, if |C a，b |≤τ, the response consistency is considered to meet the requirements; if |C a，b |>τ, it is considered that the response time difference between nodes is too large.

[0159] If the ratio of response time differences between nodes is greater than the corresponding preset ratio, the response time differences between the contracting nodes are considered inconsistent. This indicates that there is a large deviation in the consistency of response time between nodes, which cannot meet the consensus consistency requirements of the system.

[0160] If the proportion of response time differences between nodes that are considered excessive is less than or equal to the corresponding preset ratio, the response time differences between the contracting nodes are considered consistent. This indicates that the response time consistency between nodes is within an acceptable range and meets the consensus consistency requirements of the system.

[0161] Among them, the cointegration difference threshold τ is set based on the fluctuation range of historical response data, and is usually taken as the upper limit of the acceptable error in the consistency of response time to ensure that the deviation is within a reasonable range.

[0162] The preset ratio here is calibrated through simulation tests and actual application data, and is set to the response time difference ratio that the system can tolerate in multi-node consensus to ensure the stability and synchronization of the consensus process.

[0163] Based on the path differences and consensus response consistency between the signing nodes, it is determined whether to trust the final signature result. Specifically:

[0164] When the comprehensive differences among the signing nodes on the consensus path are not too large and the response time differences between the signing nodes remain consistent, the final signature result is determined to be trusted; otherwise, the final signature result is determined to be distrusted.

[0165] The degree of comprehensive difference in the consensus path among the signing nodes reflects the path consistency of each node during the data flow process. If the path difference is too large, it may indicate information asymmetry or security risks, affecting the credibility of the final signature. Secondly, whether the response time differences between the signing nodes are consistent is a key factor in measuring the responsiveness and synchronization of each node. Excessive time differences will cause synchronization failure between nodes, which may in turn affect the consistency and integrity of the data. Therefore, only when the consensus path differences are small and the response times are consistent can the signature result be deemed credible. Otherwise, it will be considered a potential risk and the final signature result will be determined to be distrusted, thereby ensuring the security and reliability of electronic signing.

[0166] When the final signature result is trusted, the signed electronic contract of the final signature result is stored in the distributed ledger, specifically:

[0167] The aggregation center node encrypts the signed electronic contract data and writes the encrypted contract data to the ledger through the distributed ledger interface. The distributed ledger uses a consensus protocol to ensure the immutability and traceability of the electronic contract. Once stored, the signed electronic contract status changes to "Completed," and no re-verification process is triggered.

[0168] When the final signature result is not trusted, the signing node re-verification mechanism is triggered, specifically:

[0169] The aggregation center node triggers the re-verification mechanism of the signing node:

[0170] The aggregation center node sends a re-verification request to all signing nodes, requiring each signing node to reconfirm the status of its local signing data, including the integrity of the signing data and the distribution status of the key.

[0171] Under the re-verification mechanism, the signing nodes re-collect and verify their respective signing data and key status, and submit again after completion:

[0172] Under the reverification mechanism, upon receiving a reverification request from the aggregation center, each signing node begins to recollect and reverify its local signing data. Each signing node compares the current signing data and key status to confirm compliance with consistency requirements. This includes checking the integrity of the signing data, the correct key status, and any potential anomalies. After completing data verification, each signing node submits the verification results to the aggregation center, which aggregates and makes a final credibility determination.

[0173] The aggregation center node re-evaluates the credibility of the signature result based on the re-verified data and decides whether to store it in the distributed ledger:

[0174] After all contracting nodes submit their re-verification results, the aggregation center node re-evaluates the credibility of the signature result. The aggregation center analyzes the re-submitted path differences and response time consistency data to check whether it meets the credibility criteria. If the signature result is deemed credible after re-verification, the central node stores the signed electronic contract with the final signature result in the distributed ledger. If it is determined to be untrustworthy, the process returns to the re-verification mechanism to ensure the overall consistency of the system and the reliability of the signature.

[0175] Example 2

[0176] The difference between Example 2 of the present invention and Example 1 is that this example introduces an electronic signing system based on commercial cryptographic technology.

[0177] Figure 2 A structural schematic diagram of the electronic signing system based on commercial cryptographic technology of the present invention is given. The electronic signing system based on commercial cryptographic technology includes a signing request initiation module, an encrypted data distribution module, a local signature generation module, a consensus path analysis module, a response time analysis module, a signature result determination module and a signature result storage module.

[0178] Signing request initiation module: initiates an electronic contract signing request at the first signing node, encrypts the signing data using a commercial cryptographic algorithm, and distributes the encrypted data to multiple signing nodes through the secure channel of the commercial cryptographic protocol.

[0179] Encrypted data distribution module: After receiving the signing request, each signing node uses a distributed consistency algorithm to verify the signing data and key status. If the verification is successful, it proceeds to the next step.

[0180] Local signature generation module: Generates local signatures at the verified signing nodes and aggregates them into the final signature results.

[0181] Consensus path analysis module: Based on the fuzzy logic hierarchical analysis model, the consensus path distribution of each signing node is analyzed to evaluate the path differences between the signing nodes.

[0182] Response time analysis module: Analyzes the response time differences between contracting nodes through time series decomposition and compound cointegration model, and evaluates the consensus response consistency between contracting nodes.

[0183] Signature result judgment module: Based on the path differences and consensus response consistency between signing nodes, it determines whether to trust the final signature result.

[0184] Signature result storage module: When the final signature result is trusted, the signed electronic contract of the final signature result is stored in the distributed ledger; when the final signature result is not trusted, the signing node re-verification mechanism is triggered.

[0185] Example 3

[0186] A computer-readable storage medium stores a program or instruction, which, when executed by a processor, implements an electronic signing method based on commercial cryptographic technology.

[0187] The above formulas are all dimensionless and numerical calculations. The formulas are obtained by collecting a large amount of data and performing software simulation to obtain the most recent real situation. The preset parameters and thresholds in the formulas are set by technicians in this field according to actual conditions.

[0188] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive.

[0189] Those skilled in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0190] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0191] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0192] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, and may be located in one place or distributed across multiple network modules. Some or all of the modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0193] In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0194] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0195] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

[0196] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. An electronic signing method based on commercial cryptographic technology, characterized in that: The steps include: Initiate an electronic contract signing request at the first signing node, encrypt the signing data using a commercial cryptographic algorithm, and distribute the encrypted data to multiple signing nodes via a secure channel using the commercial cryptographic protocol; After receiving the signing request, each signing node uses a distributed consistency algorithm to verify the signing data and key status. If the verification is successful, it proceeds to the next step; Generate local signatures at the signing nodes that have passed verification and aggregate them into the final signature result; A hierarchical analysis model based on fuzzy logic analyzes the consensus path distribution of each signing node and evaluates the path differences between signing nodes. Specifically, the fuzzy logic-based hierarchical analysis model is loaded on the aggregation center node, and the initial parameters and model structure for path difference evaluation are set. Each signing node uploads the path data of its participation in the signing consensus process to the aggregation center node. The aggregation center node combines the local signatures of all signing nodes into the final signature result through a commercial cryptographic signature aggregation algorithm. According to the requirements of the hierarchical analysis model, weights are set for key factors in the path. Based on the collected data and the set weights, the aggregation center node generates a path difference matrix to form the difference relationship between the path distributions of each contracting node. The path difference matrix is ​​analyzed to determine whether the number of contracting node pairs with a path difference index greater than the difference threshold exceeds the corresponding preset ratio. The path difference index represents the path difference between the contracting node i and the contracting node j in the path difference matrix; the difference threshold is used to measure whether the path difference is within an acceptable range; The response time differences between contracting nodes are analyzed through time series decomposition and compound cointegration model to evaluate the consistency of consensus response between contracting nodes. Based on the path differences and consensus response consistency between signing nodes, determine whether to trust the final signature result; When the final signature result is trusted, the signed electronic contract of the final signature result is stored in the distributed ledger; when the final signature result is not trusted, the signing node re-verification mechanism is triggered.

2. The electronic signing method based on commercial cryptography technology according to claim 1, characterized in that: The electronic contract signing request is initiated at the first signing node, and the signing data is encrypted using a commercial cryptographic algorithm. The encrypted data is distributed to multiple signing nodes through the secure channel of the commercial cryptographic protocol. Specifically: The first signing node generates a signing request for the electronic contract and integrates the request information into the signing data to form a complete signing data package; Encrypt the signed data packet using a commercial cryptographic algorithm; Establishing a secure communication channel through the first signing node based on a commercial cryptographic protocol; The encrypted signing data is sent to multiple signing nodes through the established secure communication channel.

3. The electronic signing method based on commercial cryptography technology according to claim 2, characterized in that: After receiving the signing request, each signing node uses a distributed consensus algorithm to verify the signing data and key status. If the verification is successful, it proceeds to the next step, which is: Each signing node receives the encrypted signing data packet from the first signing node and decrypts the data packet to obtain the signing data content; Each signing node confirms whether the received signing data packet is complete through the consistency check mechanism; Decrypt the encrypted contract data packet using the key of the commercial cryptographic algorithm to obtain the plaintext information of the contract data; Each signing node uses a distributed consistency algorithm to verify the consistency of the decrypted signing data to confirm that the data content is consistent across all nodes; Each signing node verifies the key status according to the distributed consistency algorithm to ensure that the key distribution status of each node is consistent. If the verification is passed, it proceeds to the next step.

4. The electronic signing method based on commercial cryptography technology according to claim 3, characterized in that: The local signature is generated at the signing node that passes the verification and aggregated into the final signature result, specifically: Each signing node extracts key information from the decrypted signing data and generates a local signature using the private key; After generating the local signature, each signing node encapsulates the signature, adds the signing node identifier and the signing data summary; Each signing node transmits the encapsulated local signature to the signature aggregation center node, which receives and confirms the validity of the signature.

5. The electronic signing method based on commercial cryptography technology according to claim 4, characterized in that: The response time differences between contracting nodes are analyzed through time series decomposition and compound cointegration model, and the consensus response consistency between contracting nodes is evaluated. Specifically: Load the time series decomposition model at the aggregation center node and set the initial parameters for response time difference analysis; The response time data of each signing node during the consensus process is uploaded to the aggregation center node to form a response time series; The aggregation center node decomposes the collected response time series into trend and seasonality to extract key time features; The decomposed response time series data are input into the composite cointegration model to identify the time response relationship between contracting nodes; The aggregation center node analyzes the composite cointegration results to determine whether the response time differences between the contracting nodes remain consistent.

6. The electronic signing method based on commercial cryptography technology according to claim 5, characterized in that: Based on the path differences and consensus response consistency between the signing nodes, it is determined whether to trust the final signature result. Specifically: When the number of signing node pairs with a path difference index greater than the difference threshold does not exceed the corresponding preset ratio, and the response time differences between the signing nodes remain consistent, the final signature result is determined to be trusted; Otherwise, the final signature result is determined to be untrustworthy.

7. The electronic signing method based on commercial cryptography technology according to claim 6, characterized in that: When the final signature result is not trusted, the signing node re-verification mechanism is triggered, specifically: The aggregation center node triggers the re-verification mechanism of the contracting node; Under the re-verification mechanism, the signing nodes re-collect and verify their respective signing data and key status, and submit them again after completion; The aggregation center node re-determines the credibility of the signature result based on the re-verified data and decides whether to store it in the distributed ledger.

8. An electronic signing system based on commercial cryptography technology, used to implement the electronic signing method based on commercial cryptography technology according to any one of claims 1 to 7, characterized in that: It includes a signing request initiation module, an encrypted data distribution module, a local signature generation module, a consensus path analysis module, a response time analysis module, a signature result determination module, and a signature result storage module; Signing request initiation module: initiates an electronic contract signing request at the first signing node, encrypts the signing data using a commercial cryptographic algorithm, and distributes the encrypted data to multiple signing nodes through a secure channel using a commercial cryptographic protocol; Encrypted data distribution module: After receiving the signing request, each signing node uses a distributed consistency algorithm to verify the signing data and key status. If the verification is successful, it proceeds to the next step; Local signature generation module: Generates local signatures at the verified signing nodes and aggregates them into the final signature result; Consensus path analysis module: Based on the fuzzy logic hierarchical analysis model, it analyzes the consensus path distribution of each contracting node and evaluates the path differences between contracting nodes; Response time analysis module: Analyzes the response time differences between contracting nodes through time series decomposition and compound cointegration models, and evaluates the consensus response consistency between contracting nodes; Signature result judgment module: Based on the path differences and consensus response consistency between the signing nodes, it determines whether to trust the final signature result; Signature result storage module: When the final signature result is trusted, the signed electronic contract of the final signature result is stored in the distributed ledger; When the final signature result is not trusted, the signing node re-verification mechanism is triggered.

9. A computer-readable storage medium, characterized in that A program or instruction is stored on a computer-readable storage medium, and when the program or instruction is executed by a processor, an electronic signing method based on commercial cryptographic technology as described in any one of claims 1 to 7 is implemented.

Images