Electronic signing system and method based on commercial password technology, and storage medium

Abstract

The invention discloses an electronic contract signing system and method based on a commercial password technology and a storage medium, and particularly relates to the technical field of distributed storage security. An electronic contract signing request is initiated at a first contract signing node, and after contract signing data is encrypted by using a commercial password algorithm, the electronic contract signing request is sent to a second contract signing node; the encrypted data is distributed to a plurality of signing nodes using a secure channel of a commercial cryptographic protocol. And after each signing node receives the signing request, signing data and a key state are verified by adopting a distributed consistency algorithm, a local signature is generated after verification is passed, and the local signature is aggregated to form a final signature result. And analyzing the path and response consistency of the signing node based on an analytic hierarchy model and a time sequence decomposition model of fuzzy logic so as to judge the credibility of a signature result. And when the result is credible, the signed electronic contract is stored in the distributed account book, and if the result is not credible, a re-verification mechanism is triggered to ensure the security and consistency of 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, enterprises and individual users. Compared with traditional paper contracts, electronic contracts have significant advantages in convenience and efficiency, and can greatly reduce the time cost of contract signing and management. Existing technologies usually use encryption, digital signatures and multi-node distributed storage to improve the immutability and data consistency of contracts. However, in the electronic signing scenario of multi-party collaboration, the contract data and authentication information involved are often distributed on different nodes, and these nodes may be located in different network environments, independent and dispersed from each other.

[0003] In the scenario of electronic signing with multi-party collaboration, the data and authentication information involved are often distributed on different nodes. However, in order to ensure the immutability and efficient signing of electronic contracts, it is necessary to synchronize the signing data and key distribution status in real time between distributed nodes to maintain the consistency of the signing results. However, if the distributed consistency of data cannot be guaranteed in high-frequency multi-node signing requests, the credibility of the signing results will be reduced and the risk of data tampering will be increased, 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, the 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 through a secure channel of 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 a local signature at the signing node that has passed the verification and aggregate it into the final signature result;

[0011] The fuzzy logic-based hierarchical analysis model is used to analyze the distribution of consensus paths among contracting nodes and evaluate the path differences among contracting nodes. The time series decomposition and composite cointegration model is used to analyze the response time differences among contracting nodes and evaluate the consistency of consensus responses among contracting nodes.

[0012] Based on the path differences and consensus response consistency between the 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, and the encrypted data is distributed to multiple signing nodes through 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 packet;

[0016] Encrypt the signed data packet using a commercial encryption 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 consistency algorithm to verify the signing data and key status. If the verification is successful, the next step is entered, which is specifically:

[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 a 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 among 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 passes, 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 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 of the 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 diversity matrix to determine whether the comprehensive differences among the signing nodes on the consensus path are 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 performs trend and seasonal decomposition on the collected response time series and extracts 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, based on the path differences and consensus response consistency between the signing nodes, it is determined whether to trust the final signature result, specifically:

[0043] When the comprehensive differences among the signing nodes on the consensus path are not too large, and the response time differences among 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 of 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 results;

[0052] Consensus path analysis module: Analyze the consensus path distribution of each contracting node based on the fuzzy logic hierarchical analysis model to evaluate the path differences between contracting nodes;

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

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

[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, on which a program or instruction is stored, and 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 contract 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 signing data in a distributed environment is ensured. After each signing node receives the data, a distributed consistency algorithm is used to verify the signing data and key status, thereby improving the distributed consistency in a 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 signing process.

[0059] 2. The present invention further uses the hierarchical analysis model of fuzzy logic, time series decomposition and composite cointegration model to comprehensively evaluate the path differences and response time consistency between contracting nodes, 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 unreliable, the re-verification mechanism of the contracting node is triggered to ensure the efficiency and data security of the entire contracting process. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 A schematic diagram of the electronic signing method based on commercial cryptographic technology of the present invention;

[0061] Figure 2 It is a structural schematic diagram of the electronic signing system based on commercial cryptographic technology of the present invention. DETAILED DESCRIPTION

[0062] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0063] Example 1

[0064] Figure 1 The electronic signing method based on commercial cryptographic technology of the present invention is provided, which comprises 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 has passed 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 contracting nodes and evaluate the path differences among contracting nodes. The response time differences among contracting nodes are analyzed through time series decomposition and composite cointegration model to evaluate the consistency of consensus responses among contracting nodes.

[0069] Based on the path differences and consensus response consistency between the 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] 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 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 obtaining the contract signing requirements, the first contract signing node first generates an electronic contract signing request internally, which contains the relevant data and accompanying information of the electronic contract. In order to facilitate the data integrity and security management in the subsequent distribution process, the first contract signing node organizes the key information in the contract signing request and integrates the request information into the contract signing data, thus forming a complete contract signing data packet. This data packet not only contains the contract content itself, but also covers the necessary information involved in the contract signing process, such as the contract signing request identification, party information, and contract signing timestamp. The process of forming a complete data packet ensures the uniformity of the data structure in subsequent operations.

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

[0076] The first signing node generates a pair of keys for the encryption process, namely a public key and a private key, where the public key is used for data encryption and the private key is used for data decryption. The commercial cryptographic algorithm uses an asymmetric encryption mechanism to ensure data security in a multi-node environment. Specifically, after obtaining the data packet, the first signing node calls the commercial cryptographic algorithm based on the preset encryption standard to encrypt the data packet, and the encrypted data packet becomes an "encrypted signing data packet." The key generation in the encryption process follows the commercial cryptographic standard and ensures the uniqueness and unpredictability of the key.

[0077] In this process, the data packet content is processed into ciphertext by a commercial encryption 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 the commercial cryptographic protocol, a secure communication channel is established through the first signing node to provide an encrypted channel for subsequent data distribution:

[0081] The first signing node uses the key exchange mechanism of the commercial cryptographic protocol to ensure the security of key exchange with each signing node. This process is based on the preset security standards and verifies the node identity through the authentication mechanism of the commercial cryptographic protocol to ensure that the recipient is a trusted signing node. Then, the first signing node securely distributes the generated symmetric encryption key to other signing nodes to establish the symmetric key transmission foundation required for data transmission. This key exchange mechanism uses the encryption algorithm built into the commercial cryptographic protocol to ensure the uniqueness and randomness of the key.

[0082] When establishing a secure communication channel, the security of the transmission channel is ensured through authentication and key exchange of 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 with 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 between the first signing node and the signing node is formally established 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 the identity of each node.

[0088] The encrypted signing data is sent to multiple signing nodes through the established secure communication channel to ensure 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 meta information 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 receipt information 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 consistency 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 contract node, each contract node first decapsulates the data packet. The decapsulation process specifically includes reading the contract information and other necessary metadata in the data packet, such as the contract request identifier, contract data length, sending node identifier, etc. Through decapsulation, each contract node can accurately locate the content of the data packet 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 the packet integrity verification, and D is the decapsulated signed data content.

[0097] If the node-generated hash value 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 encryption algorithm to decrypt the encrypted signing data packet to obtain the plaintext information of the signing data:

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

[0100] The key to the decryption process is to convert the encrypted contract data packet into plain text through the private key, so as to verify the consistency of the contract data content in the subsequent steps. The decrypted plain text contains the contracting party, contract content and other additional information, ensuring that the data content is complete and correct, and providing a data basis 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 among all nodes:

[0102] Each signing node generates a unique data summary from the contract data content it obtains, which is used for consistency comparison between contract nodes. After generating the data summary, each contract node distributes the summary value to other contract nodes in the network for comparison and verification of multiple contract nodes. After receiving the data summaries of other contract nodes, each contract node compares them one by one to check whether the data summaries generated by all contract nodes are consistent, so as to determine whether each contract node has the same contract data content.

[0103] If the data summaries generated by all contracting nodes are consistent, it means that the contracting data content of all contracting nodes is consistent and the verification is passed; if the data summaries of any contracting nodes are different, it is considered that the consistency verification has failed, indicating that the data content of some contracting nodes may be different. At this time, the system will trigger the exception handling mechanism and re-verify or re-transmit the contracting nodes with differences to ensure the final consistency.

[0104] 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 passes, proceed to the next step:

[0105] Each signing node generates a key status identification information, which contains the key status summary of the current signing node. Each signing node distributes the generated key status identification information to the network for other signing nodes to compare for consistency. After receiving the key status information of other signing nodes, each signing node compares its identification information one by one to see if it is consistent with other signing nodes, to ensure that in a multi-signing node environment, the key status of all signing nodes is the same.

[0106] If the key status identifiers of all signing nodes are consistent, it means that the key status is consistent among the signing nodes, and the verification is passed, then proceed to the next step. 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 deviated. The system will trigger a redistribution or update mechanism to ensure that the key status of each signing node remains consistent.

[0107] The local signature is generated at the signing node that has passed the verification and aggregated into the final signature result, which is as follows:

[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 information related to the contract from the decrypted contract data content, including the contract content, party identification, timestamp, etc., and then calls the commercial cryptographic signature algorithm to perform a local signature generation operation. The signature generation process uses the private key of each signing node to sign the contract data content, thereby generating a unique signature for the signing node.

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

[0111] After generating the local signature, each signing node will encapsulate the signature result. The encapsulated data package includes the generated local signature, signing node identification, signing data summary, etc., to ensure that the signature of each signing node can be accurately distinguished in the subsequent signature aggregation process. After the encapsulation step is completed at each signing node, it will provide 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 completed, each signing node passes the 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 been verified for consistency.

[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 aggregation center node receives the local signatures of all the contracting nodes, the center node will integrate the local signatures of each contracting node into a final signature result according to the commercial cryptographic signature aggregation algorithm. The aggregation center node first matches and verifies the signature identification information of all contracting nodes to confirm that all signatures come from the verified contracting nodes; after completing the confirmation, the aggregation center node combines all the signature information through the aggregation algorithm to generate an independent, globally unique final signature result. The final signature result will serve as the unique identifier of the electronic contract signing to ensure the non-tamperability of the contract signing.

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

[0117] After the final signature result is generated, the aggregation center node confirms the integrity of the signature result to ensure that the signature complies with the preset signature format and security standards. After the confirmation is completed, the final signature result will be stored and enter the subsequent storage and distributed ledger recording stage.

[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] The fuzzy logic-based hierarchical analysis model is loaded in the aggregation center node for subsequent path difference evaluation. Specifically, the aggregation center node needs to configure the model structure and the required initial parameters, which are the basis for analyzing the path distribution. The model structure defines the key factors in the path hierarchically through the hierarchical analysis method, so that the subsequent path data can be evaluated at different levels. When loading the model, the aggregation center node also needs to set specific rules of fuzzy logic to meet the requirements of path difference 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 hierarchical analysis model is loaded, each contracting node uploads the path data generated during the contracting consensus process to the aggregation center node. The path data contains key information such as the node identification, path flow direction, and timestamp of participating nodes of each contracting node in the contracting consensus process. The process of uploading path data is a key step to ensure that the aggregation center node can grasp the path distribution information of each contracting node. After receiving the data of each contracting node, the aggregation center node associates the path data with metadata such as node identification and path generation time, so that the path characteristics of each node can be accurately tracked and compared in the 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 of each factor in the path difference assessment:

[0124] After the aggregation center node receives the path data of each contracting node, it sets weights for the key factors in the path according to the requirements of the hierarchical analysis model. The weight setting is based on the actual needs of the path difference assessment to ensure that the model can highlight the importance of key factors at different levels. For example, the weights of key factors such as "number of node hops", "communication time difference between contracting nodes", and "response delay of the path" in the path are set. Through weight setting, the influence of different factors can be reasonably allocated in the path difference assessment. The principle of setting weights depends on the hierarchical analysis method of the model, and the weights are divided level by level to ensure that the effects 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 They represent the weight values ​​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 the difference relationship of the path distribution between 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 ​​according to each key factor in turn. In 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 diversity matrix is: Among them, 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 diversity matrix enables the aggregation center node to comprehensively analyze the path distribution differences between the contracting nodes.

[0130] Calculate the path difference index, the calculation formula is: Among them, P i，j is the path difference index, which indicates 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] After each element of the path difference matrix is ​​compared layer by layer in the hierarchical analysis model, it reflects the path differences of each contracting node on different factors. After the path difference matrix is ​​generated, the aggregation center node obtains the overall difference relationship of the path distribution between each contracting node.

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

[0133] A difference threshold T is set 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 does not affect the overall consistency within a reasonable range.

[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 nodes that satisfy P in the path difference matrix. i，j >T items, record the items that satisfy P i，j >T number of contracted node pairs.

[0138] If P is satisfied i，j >T exceeds the corresponding preset ratio, it is judged that the comprehensive difference between the contracting nodes on the consensus path is too large; if P is satisfied i，j If the number of signing node pairs with >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 here 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 the 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 changes in system load or network latency. The setting of initial parameters helps the model to 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 contracting node to complete the contract response from receiving the contract request. Each data point represents the response time of a single contract request. Each contracting node will generate response time data multiple times during the consensus process, and these data will be 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 node collects the response time series of all contracted nodes, the center node decomposes the data to extract trend and seasonal characteristics. Trend decomposition is used to analyze the long-term growth or decline trend in the response time series, while seasonal decomposition is used to identify the pattern of cyclical fluctuations in the time series.

[0149] The specific steps of decomposition include:

[0150] Trend decomposition: The aggregation center node applies the 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 of each time period to obtain a smooth curve of trend changes.

[0151] Seasonal decomposition: Use Fourier transform or other frequency analysis methods on the response time series to identify seasonal fluctuation characteristics in the time series. Seasonal decomposition can help the aggregation center node identify the periodic components of the time series in order to analyze the 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 the 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 ), where 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 every 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] When the proportion of response time differences between nodes is greater than the corresponding preset proportion, it is determined that the response time differences between the contracted nodes are not consistent. At this time, it means 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] When the proportion of response time differences between nodes that are considered too large is less than or equal to the corresponding preset proportion, the response time differences between the contracted nodes are determined to be consistent. At this time, it means that the consistency of response time between nodes is good 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 the historical response data, and usually takes the upper limit of the acceptable error in the consistency of the 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 tolerable response time difference ratio of the system 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, determine 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 among 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 comprehensive difference between the consensus paths of the signing nodes reflects the path consistency of each node during the data flow process. If the path difference is too large, it may mean that there is information asymmetry or security risk, affecting the credibility of the final signature. Secondly, whether the response time difference between the signing nodes is consistent is a key factor in measuring the responsiveness and synchronization of each node. Too large a time difference will cause synchronization failure between nodes, which may affect the consistency and integrity of the data. Therefore, only when the consensus path difference is not large and the response time is consistent can the signature result be judged to be credible. Otherwise, it will be regarded as a potential risk and the final signature result will be judged as not trusting, 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 data packets of the signed electronic contract and writes the encrypted contract data into the ledger through the distributed ledger interface. The distributed ledger ensures the immutability and traceability of the electronic contract in the ledger through a consensus protocol. After the storage is completed, the status of the signed electronic contract becomes "completed" and no longer triggers the re-verification process.

[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 its local signing data status, 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 re-verification mechanism, after each signing node receives the re-verification request from the aggregation center node, it begins to re-collect and verify its local signing data. Each signing node compares the current signing data and key status to confirm whether it meets the consistency requirements. The specific steps include checking whether the signing data is complete, whether the key status is normal, and whether there are any possible abnormalities. After completing the data verification, each signing node submits the verification results to the aggregation center node so that the center node can summarize and make the final credibility judgment.

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

[0174] After all signing nodes submit the re-verification results, the aggregation center node re-determines the credibility of the signature results. The aggregation center node analyzes the re-submitted path differences and response time consistency data to check whether the credibility standards are met. If the signature result is judged to be credible after re-verification, the central node stores the signed electronic contract of the final signature result in the distributed ledger; if it is judged 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 an 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 each signing node receives the signing request, it 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: Analyze the response time differences between contracting nodes through time series decomposition and compound cointegration model, and evaluate the consensus response consistency between contracting nodes.

[0183] Signature result judgment module: Based on the path differences and consensus response consistency between the signing nodes, determine 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, and when the program or instruction is executed by a processor, an electronic signing method based on commercial cryptographic technology is implemented.

[0187] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters and thresholds in the formula 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 programs 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 devices. 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 site, computer, server or data center to another website site, computer, server or data center by wired (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access 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 hard disk.

[0189] Those of ordinary skill 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 to be beyond the scope of this application.

[0190] Those skilled in the art can 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 the present 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 only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, 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 separated, and the components shown as modules may or may not be physical modules, and may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[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 can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods 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 is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope 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 protection scope 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 through a secure channel of 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 a local signature at the signing node that has passed the verification and aggregate it into the final signature result; The fuzzy logic-based hierarchical analysis model is used to analyze the distribution of consensus paths among contracting nodes and evaluate the path differences among contracting nodes. The time series decomposition and composite cointegration model is used to analyze the response time differences among contracting nodes and evaluate the consistency of consensus responses among contracting nodes. Based on the path differences and consensus response consistency between the 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 cryptographic technology according to claim 1 is characterized in that: 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 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 packet; Encrypt the signed data packet using a commercial encryption 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 is characterized in that: 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, 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 a 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 among 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 passes, it proceeds to the next step.

4. The electronic signing method based on commercial cryptographic technology according to claim 3 is characterized in that: The local signature is generated at the signing node that has passed the verification and aggregated into the final signature result, which is as follows: 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; The aggregation center node combines the local signatures of all signing nodes into the final signature result through a commercial cryptographic signature aggregation algorithm.

5. The electronic signing method based on commercial cryptographic technology according to claim 4 is characterized in that: 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: Load the fuzzy logic-based hierarchical analysis model at the aggregation center node and set the initial parameters and model structure of the path difference evaluation; Each signing node uploads the path data of its participation in the signing consensus process to the aggregation center node; According to the requirements of the hierarchical analysis model, weights are set for key factors in the path; 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; Analyze the path diversity matrix to determine whether the comprehensive differences among the signing nodes on the consensus path are too large.

6. The electronic signing method based on commercial cryptography technology according to claim 5 is 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 performs trend and seasonal decomposition on the collected response time series and extracts 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 and reviews the cointegration results to determine whether the response time differences between the contracting nodes remain consistent.

7. The electronic signing method based on commercial cryptography technology according to claim 6 is characterized in that: Based on the path differences and consensus response consistency between the signing nodes, determine whether to trust the final signature result, specifically: When the comprehensive differences among the signing nodes on the consensus path are not too large, and the response time differences among the signing nodes remain consistent, the final signature result is determined to be trusted; Otherwise, it is determined that the final signature result is not trusted.

8. The electronic signing method based on commercial cryptographic technology according to claim 7 is 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.

9. An electronic signing system based on commercial cryptography technology, used to implement the electronic signing method based on commercial cryptography technology as described in any one of claims 1 to 8, 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 of 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 results; Consensus path analysis module: Analyze the consensus path distribution of each contracting node based on the fuzzy logic hierarchical analysis model to evaluate the path differences between contracting nodes; Response time analysis module: Analyze the response time differences between contracting nodes through time series decomposition and compound cointegration model, and evaluate the consensus response consistency between contracting nodes; Signature result determination module: determines whether to trust the final signature result based on the path differences and consensus response consistency between the signing nodes; 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.

10. 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 8 is implemented.

Images