Digital contract signing method, device, medium and program product

Abstract

Embodiments of the present application provide a digital contract signing method and device, medium and program product, comprising: receiving commitment messages of each signing party device through a trusted third-party device, indicating signing intention, generating an aggregated signature according to each commitment message, after each signing party passes the verification of the aggregated signature, sending a contract request to the trusted third-party device, the trusted third-party device judging the authenticity and integrity of the contract request, if the judgment is passed, generating a digital contract, and receiving the commitment messages sent by the signing party device, the commitment messages can be processed concurrently, the signing party sends the commitment messages asynchronously, and the aggregation technology and ASW protocol are combined, effectively resisting replay attacks and double commitment attacks, meeting the requirements of digital contract integrity, authenticity, non-repudiation, traceability and strong fairness, significantly improving signing flexibility, execution efficiency and system robustness without reducing security strength.

Description

Technical Field

[0001] This application relates to the field of contract signing technology, and more specifically, to a digital contract signing method, device, medium, and program product. Background Technology

[0002] With the continuous development of network technology, signatories and offerors perform signing operations online. According to the GB / T36298-2018 standard process, signatories are required to follow a fixed order. If a digital contract requires multiple signatories to complete, each signatories must complete the signing operation in turn. If a signatories delay their operation, the entire signing process will be halted, resulting in the digital contract failing to be completed. Thus, the signing efficiency of digital contracts is low. Summary of the Invention

[0003] The purpose of this application is to provide a digital contract signing method, device, medium, and program product to improve the signing efficiency of digital contracts.

[0004] In a first aspect, embodiments of this application provide a method for signing a digital contract, including: The system receives a commitment message sent by the signing device, wherein the commitment message is determined by the signing device based on the digital contract text, the contract unique identifier, the signing public key, the trusted public key, the number of signing parties, the signing restriction time, and the hash value of the first commitment random number, which is obtained by hashing the commitment random number. If the commitment message passes the signature verification, the commitment message from the signatory device and the single signature data from the trusted third-party device are aggregated to generate an aggregated signature; The aggregated signature is sent to the signing device so that the signing device can verify the aggregated signature; If the signing device passes the verification of the aggregated signature, a contract request is received from the signing device, wherein the contract request includes the promised random number and the promised random number signature information corresponding to the promised random number; Based on the promised random number, the signature information of the promised random number, the hash value of the first promised random number, and the public key of the signer, determine whether the contract request is effective; If the contract request takes effect, the signatory device sends a commitment random number from all signatory devices and trusted third-party devices, along with signature information obtained by signing the commitment random number, to the signatory device. This enables the signatory device to verify the signature using the public key of the trusted third-party device, and confirms the official effectiveness of the digital contract by calculating and comparing the hash value of the commitment random number.

[0005] In this embodiment, a trusted third-party device receives commitment messages from each signatory device, indicating their intention to sign. An aggregate signature is generated based on each commitment message. After each signatory verifies the aggregate signature, they send a contract request to the trusted third-party device. The trusted third-party device determines whether the contract request is valid. If valid, a digital contract is generated. In this way, the trusted third-party device simultaneously receives commitment messages from the signatory devices, enabling concurrent processing of these messages. The signatory can sign commitment messages asynchronously. Combined with aggregation technology and the ASW protocol, this effectively resists replay attacks and double commitment attacks, meeting the requirements of digital contract integrity, authenticity, non-repudiation, traceability, and strong fairness. Without reducing security strength, it significantly improves signing flexibility, execution efficiency, and system robustness.

[0006] Optionally, determining whether the contract request is effective based on the committed random number, the signature information of the committed random number, the hash value of the first committed random number, and the public key of the signer includes: The aggregated signature is sent to the signing device so that the signing device verifies the aggregated signature and obtains a first verification result. The first verification result is used to determine whether the trusted third-party device has received the commitment messages from all signing devices within the signing restriction time. If the first verification result is successful, a contract request sent by the signing device is received, the contract request including the commitment random number and the commitment random number signature information corresponding to the commitment random number; The signature information of the promised random number is verified to obtain a second verification result, which is used to determine the authenticity and integrity of the promised random number. If the second verification result is successful, the validity of the contract request is determined based on the promised random number and the hash value of the first promised random number.

[0007] In this embodiment, the signatory confirms that all other participating parties besides itself have committed to signing before the final formal signing takes place. This dual verification enhances the security of digital contract generation.

[0008] Optionally, if the second signature verification result is successful, determining whether the contract request is effective based on the promised random number and the hash value of the first promised random number includes: Perform a hash operation on the promised random number to obtain the hash value of the second promised random number; The hash values ​​of the first and second commitment random numbers are compared. If the hash value of the first commitment random number matches the hash value of the second commitment random number, the contract request is deemed to be effective.

[0009] In this embodiment, a trusted third-party device determines whether the contract request is effective based on the promised random number and the hash value of the first promised random number, thereby improving the accuracy of digital contract generation.

[0010] Optionally, the commitment message is obtained in the following manner: The signing device determines the digital contract data based on the digital contract text, the unique contract identifier, the signer's public key, the trusted public key, the number of signers, and the signing restriction time. The signing device randomly generates a base random number and a commitment random number, the commitment random number being used to initiate the contract; The signing device uses its private key to sign the digital contract data and the hash value of the commitment random number to obtain the commitment message.

[0011] In this embodiment, the signing device uses its private key to sign the digital contract text, the contract's unique identifier, the signing party's public key, the trusted public key, the number of signing parties, the signing restriction time, and the hash value of the first commitment random number, thereby generating a commitment message to ensure the uniqueness of the data and provide security for the data signing.

[0012] Optionally, the signing device uses a private key to sign the digital contract data and the hash value of the promised random number to obtain the promise message, including: Based on the signatory's identity information and elliptic curve-related parameters, the first contract parameter Z1i is determined; Perform a hash operation on the promised random number to obtain the first hash parameter ωi; The first contract data Ci is determined based on the first hash parameter, the first contract parameter, and the digital contract data; Perform a hash operation on the first contract data to obtain the second hash parameter ei; The first verification data ri is determined based on the second hash parameter and the first point on the finite elliptic domain; The first processing result si is determined based on the signer's private key di, the first verification data ri, and the basic random number; The commitment message is determined based on the first verification data, the first processing result, the points on the finite elliptic domain, and the first hash parameter.

[0013] Optionally, the commitment message is determined through signature verification in the following manner: The second contract parameter Z2i is determined based on the signatory's identity information and elliptic curve parameters. The second contract data Ci is determined based on the first hash parameter ωi, the second contract parameter Z2i, and the digital contract data C; Perform a hash operation on the second contract data to obtain the third hash parameter ei; The second processing result ti is determined based on the first verification data ri and the first processing result si; Based on the first processing result, the second processing result, and the signatory's public key, determine the second point information on the finite elliptic domain; The second verification data R is determined based on the third hash parameter ei and the second point information on the finite elliptic domain; If the first verification data and the second verification data are the same, the commitment message is determined to have passed the signature verification.

[0014] Optionally, if the commitment message passes signature verification, the process of aggregating the commitment message from the signing device and the single signature data from the trusted third-party device to generate an aggregated signature includes: The second hash parameter in the commitment message of the signing device and the trusted hash parameter in the single signature data of the trusted third-party device are concatenated to obtain concatenated data. The single signature data is obtained by signing the digital contract data with the private key of the trusted third-party device, and the single signature data contains a trusted hash parameter, which is an intermediate hash value generated by the trusted third party during the signing process of the digital contract data. Perform a hash operation on the concatenated data to obtain the fourth hash data E; Determine the information of the third point in the finite elliptical domain based on the points in the finite elliptical domain; Based on the fourth hash data E and the third point information, the third verification data R is determined; Based on the first processing result si, the fourth verification data U is determined; Based on the first processing result si, the first verification data ri, and the first hash parameter, the time limit data T is determined; The aggregate signature is determined based on the third verification data R, the fourth verification data U, and the time limit data T.

[0015] In this embodiment, replay attacks can be effectively resisted by using a one-time commitment to a random number, a unique contract identifier ID, a time limit, and a digital signature; at the same time, double commitment attacks can be effectively resisted by strongly binding the commitment information with the contract context and globally locking the aggregated signature, thus ensuring the uniqueness of the contract session.

[0016] Optionally, the signing device verifies the aggregated signature to obtain a first verification result, including: The third contract parameter Z3i is determined based on the signatory's identity information and elliptic curve parameters. The third contract data Ci is determined based on the first hash parameter ωi, the third contract parameter Z3i, and the digital contract data C; Perform a hash operation on the third contract data to obtain the fifth hash parameter ei; The fifth hash parameter is concatenated to obtain the concatenated data; Perform a hash operation on the concatenated data to obtain the sixth hash parameter d; Based on the fourth verification data U, the second processing result ti, and the signer's public key, the fourth point information on the finite elliptic domain is determined. The fifth verification data is determined based on the information of the fourth point on the finite elliptic domain and the sixth hash parameter; If the third verification data R and the fifth verification data are the same, it is determined that the signer has passed the verification of the aggregated signature.

[0017] In this embodiment, by embedding the unique identity of the signatory into the signature, verifying each signature individually with a trusted third-party device, retaining the association information of each signatory in the aggregated signature, and binding the unique contract ID throughout the process, TTP completes the notarization after completing the signature aggregation and generating the formal contract, thus achieving traceability, identifiable responsibility, and non-repudiation of the behavior.

[0018] Optionally, the method further includes: if the trusted third-party device does not receive commitment messages from all signing party devices within a first preset time period, receiving a contract termination request sent by the signing party devices, wherein the contract termination request includes a termination identifier and the signing party's commitment message; determining a first token information type corresponding to the termination identifier based on the contract termination request, wherein the first token information type includes a first termination token or a first resolution token, the first termination token being used to revoke the digital contract, the first resolution token being used to determine that the digital contract has taken effect and is irrevocable, and the first preset time period being within the signing restriction time; Based on the first token information type, determine the execution operation corresponding to the contract termination request.

[0019] In this embodiment of the application, the suspension sub-protocol is a suspension token that can be issued by a trusted third-party device, allowing the contract to be revoked before all signatories have fulfilled their commitments; Optionally, the method further includes: If the signing device does not receive a digital contract sent by a trusted third-party device within a second preset time period, the signing device receives a contract resolution request sent by the signing device, wherein the contract resolution request includes an aggregate signature, and the second preset time period is within the signing restriction time. Based on the contract resolution request, a corresponding second token information type is determined, wherein the second token information type includes a second termination token or a second resolution token; the second termination token is used to determine that the digital contract has been revoked, and the second resolution token is used to force the digital contract to take effect; Based on the second token information type, determine the execution operation corresponding to the contract resolution request.

[0020] In this embodiment, the resolution sub-agreement is an alternative contract that can be signed by a trusted third-party device, providing non-repudiable proof of the commitments made by both parties, preventing the signatory from reneging on their commitment, and forcing the contract to take effect. Through time limits and the digital contract termination and resolution sub-agreements, it is ensured that the process will not be blocked indefinitely, and the signatory will not wait indefinitely; they can proactively cancel the digital contract or force it to take effect.

[0021] Secondly, embodiments of this application provide a digital contract signing device, comprising: The receiving module is used to receive a commitment message sent by the signing device, wherein the commitment message is determined by the signing device based on the digital contract text, the unique identifier of the contract, the signer's public key, the trusted public key, the number of signers, the signing restriction time, and the hash value of the first commitment random number, wherein the hash value of the first commitment random number is obtained by hashing the commitment random number; The aggregation module is used to aggregate the commitment message from the signatory device and the single signature data from the trusted third-party device to generate an aggregated signature, provided that the commitment message passes the signature verification. The first signature verification module is used to send the aggregated signature to the signing device so that the signing device can verify the aggregated signature. The request module is configured to receive a contract request sent by the signing device when the signing device passes the verification of the aggregated signature, wherein the contract request includes the promised random number and the promised random number signature information corresponding to the promised random number; The second signature verification module is used to determine whether the contract request is effective based on the promised random number, the signature information of the promised random number, the hash value of the first promised random number, and the public key of the signer. The generation module is used to send the commitment random numbers of all signer devices and trusted third-party devices, along with signature information obtained by signing the commitment random numbers, to the signer device when the contract request takes effect. This enables the signer device to verify the signature using the public key of the trusted third-party device and confirm the official effectiveness of the digital contract by calculating and comparing the hash values ​​of the commitment random numbers.

[0022] In this embodiment, a trusted third-party device receives commitment messages from each signatory device, indicating their intention to sign. An aggregate signature is generated based on each commitment message. After each signatory verifies the aggregate signature, they send a contract request to the trusted third-party device. The trusted third-party device determines whether the contract request is valid. If valid, a digital contract is generated. In this way, the trusted third-party device simultaneously receives commitment messages from the signatory devices, enabling concurrent processing of these messages. The signatory can sign commitment messages asynchronously. Combined with aggregation technology and the ASW protocol, this effectively resists replay attacks and double commitment attacks, meeting the requirements of digital contract integrity, authenticity, non-repudiation, traceability, and strong fairness. Without reducing security strength, it significantly improves signing flexibility, execution efficiency, and system robustness.

[0023] Optionally, the second signature verification module is used for: The aggregated signature is sent to the signing device so that the signing device verifies the aggregated signature and obtains a first verification result. The first verification result is used to determine whether the trusted third-party device has received the commitment messages from all signing devices within the signing restriction time. If the first verification result is successful, a contract request sent by the signing device is received, the contract request including the commitment random number and the commitment random number signature information corresponding to the commitment random number; The signature information of the promised random number is verified to obtain a second verification result, which is used to determine the authenticity and integrity of the promised random number. If the second verification result is successful, the validity of the contract request is determined based on the promised random number and the hash value of the first promised random number.

[0024] In this embodiment, the signatory confirms that all other participating parties besides itself have committed to signing before the final formal signing takes place. This dual verification enhances the security of digital contract generation.

[0025] Optionally, the second signature verification module is used for: Perform a hash operation on the promised random number to obtain the hash value of the second promised random number; The hash values ​​of the first and second commitment random numbers are compared. If the hash value of the first commitment random number matches the hash value of the second commitment random number, the contract request is deemed to be effective.

[0026] In this embodiment, a trusted third-party device determines whether the contract request is effective based on the promised random number and the hash value of the first promised random number, thereby improving the accuracy of digital contract generation.

[0027] Optionally, the commitment message is obtained in the following manner: The signing device determines the digital contract data based on the digital contract text, the contract's unique identifier, the signer's public key, the trusted public key, the number of signers, the signing restriction time, and the hash value of the first commitment random number; The signing device randomly generates a base random number and a commitment random number, the commitment random number being used to initiate the contract; The signing device uses its private key to sign the digital contract data and the hash value of the commitment random number to obtain the commitment message.

[0028] In this embodiment, the signing device uses its private key to sign the digital contract text, the contract's unique identifier, the signing party's public key, the trusted public key, the number of signing parties, the signing restriction time, and the hash value of the first commitment random number, thereby generating a commitment message to ensure the uniqueness of the data and provide security for data signing.

[0029] Optionally, the signing device includes a signing module, the signing module being used for: Based on the signatory's identity information and elliptic curve-related parameters, the first contract parameter Z1i is determined; Perform a hash operation on the promised random number to obtain the first hash parameter ωi; The first contract data Ci is determined based on the first hash parameter, the first contract parameter, and the digital contract data; Perform a hash operation on the first contract data to obtain the second hash parameter ei; The first verification data ri is determined based on the second hash parameter and the first point on the finite elliptic domain; The first processing result si is determined based on the signer's private key di, the first verification data ri, and the basic random number; The commitment message is determined based on the first verification data, the first processing result, the points on the finite elliptic domain, and the first hash parameter.

[0030] Optionally, the signing module is used for: The second contract parameter Z2i is determined based on the signatory's identity information and elliptic curve parameters. The second contract data Ci is determined based on the first hash parameter ωi, the second contract parameter Z2i, and the digital contract data C; Perform a hash operation on the second contract data to obtain the third hash parameter ei; The second processing result ti is determined based on the first verification data ri and the first processing result si; Based on the first processing result, the second processing result, and the signatory's public key, determine the second point information on the finite elliptic domain; The second verification data R is determined based on the third hash parameter ei and the second point information on the finite elliptic domain; If the first verification data and the second verification data are the same, the commitment message is determined to have passed the signature verification.

[0031] Optionally, the aggregation module is used for: The second hash parameter in the commitment message of the signing device and the trusted hash parameter in the single signature data are concatenated to obtain concatenated data. The single signature data is obtained by signing the digital contract data with the private key of the trusted third-party device, and the single signature data contains a trusted hash parameter, which is an intermediate hash value generated by the trusted third party during the signing process of the digital contract data. Perform a hash operation on the concatenated data to obtain the fourth hash data E; Determine the information of the third point in the finite elliptical domain based on the points in the finite elliptical domain; Based on the fourth hash data E and the third point information, the third verification data R is determined; Based on the first processing result si, the fourth verification data U is determined; Based on the first processing result si, the first verification data ri, and the first hash parameter, the time limit data T is determined; The aggregate signature is determined based on the third verification data R, the fourth verification data U, and the time limit data T.

[0032] In this embodiment, replay attacks can be effectively resisted by using a one-time commitment to a random number, a unique contract identifier ID, a time limit, and a digital signature; at the same time, double commitment attacks can be effectively resisted by strongly binding the commitment information with the contract context and globally locking the aggregated signature, thus ensuring the uniqueness of the contract session.

[0033] Optionally, the signing module is used for: The third contract parameter Z3i is determined based on the signatory's identity information and elliptic curve parameters. The third contract data Ci is determined based on the first hash parameter ωi, the third contract parameter Z3i, and the digital contract data C; Perform a hash operation on the third contract data to obtain the fifth hash parameter ei; The fifth hash parameter is concatenated to obtain the concatenated data; Perform a hash operation on the concatenated data to obtain the sixth hash parameter d; Based on the fourth verification data U, the second processing result ti, and the signer's public key, the fourth point information on the finite elliptic domain is determined. The fifth verification data is determined based on the information of the fourth point on the finite elliptic domain and the sixth hash parameter; If the third verification data R and the fifth verification data are the same, it is determined that the signer has passed the verification of the aggregated signature.

[0034] In this embodiment, by embedding the unique identity of the signatory into the signature, verifying each signature individually with a trusted third-party device, retaining the association information of each signatory in the aggregated signature, and binding the unique contract ID throughout the process, TTP completes the notarization after completing the signature aggregation and generating the formal contract, thus achieving traceability, identifiable responsibility, and non-repudiation of the behavior.

[0035] Optionally, the generation module is used to: If a trusted third-party device does not receive commitment messages from all signing party devices within a first preset time period, it receives a contract termination request sent by the signing party devices, wherein the contract termination request includes a termination identifier and a commitment message from the signing party; based on the contract termination request, it determines a first token information type corresponding to the termination identifier, wherein the first token information type includes a first termination token or a first resolution token, the first termination token is used to revoke the digital contract, the first resolution token is used to determine that the digital contract has taken effect and is irrevocable, and the first preset time period is within the signing restriction time; Based on the first token information type, determine the execution operation corresponding to the contract termination request.

[0036] In this embodiment of the application, the suspension sub-protocol is a suspension token that can be issued by a trusted third-party device, allowing the contract to be revoked before all signatories have fulfilled their commitments; Optionally, the generation module is used to: If the signing device does not receive a digital contract sent by a trusted third-party device within a second preset time period, the signing device receives a contract resolution request sent by the signing device, wherein the contract resolution request includes an aggregate signature, and the second preset time period is within the signing restriction time. Based on the contract resolution request, a corresponding second token information type is determined, wherein the second token information type includes a second termination token or a second resolution token; the second termination token is used to determine that the digital contract has been revoked, and the second resolution token is used to force the digital contract to take effect; Based on the second token information type, determine the execution operation corresponding to the contract resolution request.

[0037] In this embodiment, the resolution sub-agreement is an alternative contract that can be signed by a trusted third-party device, providing non-repudiable proof of the commitments made by both parties, preventing the signatory from reneging on their commitment, and forcing the contract to take effect. Through time limits and the digital contract termination and resolution sub-agreements, it is ensured that the process will not be blocked indefinitely, and the signatory will not wait indefinitely; they can proactively cancel the digital contract or force it to take effect.

[0038] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, can implement the method described in any embodiment of the first aspect.

[0039] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the method described in any embodiment of the first aspect.

[0040] Fifthly, embodiments of this application provide a computer program product, the computer program product including a computer program, wherein when the computer program is executed by a processor, it can implement the method described in any embodiment of the first aspect. Attached Figure Description

[0041] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 A flowchart illustrating a digital contract signing method provided in an embodiment of this application; Figure 2 A schematic diagram illustrating the normal signing process of the main agreement for a digital contract, provided in an embodiment of this application; Figure 3 A flowchart illustrating the digital contract termination sub-protocol provided in this application embodiment; Figure 4 A flowchart illustrating the digital contract resolution sub-protocol provided in this application embodiment; Figure 5 A schematic diagram of the structure of a digital contract signing device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0043] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0044] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0045] Electronic contracts refer to agreements between natural persons, legal persons, and other organizations with equal rights, using electronic data messages and electronic communication methods to establish, modify, or terminate civil rights and obligations. Digital contracts refer to commitments made in digital form by data providers, data users, data service providers, and other relevant participants regarding the expected aspects of data circulation and use, including but not limited to the data content, users, usage methods, frequency of use, scope of use, usage environment, delivery method, and delivery address. Therefore, digital contracts are a special form of electronic contracts.

[0046] GB / T 36298-2018 defines the electronic contract signing process as including four stages: identity registration, identity authentication, electronic contract signing, and electronic contract query / download / verification. In the electronic contract signing stage, the signatory holds a digital certificate and electronically signs the contract. The signatory is divided into the offeror and the offeree. Specifically, the offeror creates the contract text, digitally signs it, and initiates an electronic contract signing application to the offeree through the electronic contract service platform. After receiving the electronic contract signing data and agreeing to sign, the offeree digitally signs it and sends it to the electronic contract service platform. The electronic contract service platform verifies the electronic signatures of the offeror and offeree. If the verification is successful, an electronic contract is generated; otherwise, the process ends immediately. The standard stipulates that the conclusion of an electronic contract should meet the principles of validity, independence, confidentiality, non-repudiation, tamper-proof, authenticity, and completeness.

[0047] A trusted data space is a data circulation and utilization infrastructure based on consensus rules, connecting multiple entities to achieve data resource sharing and utilization. Digital contracts are the core mechanism for realizing trusted interaction and automated execution of data services within a trusted data space. The "Technical Requirements for Digital Contracts in a Trusted Data Space" (TC609-6-2025-14) outlines the digital contract business process, including five stages: contract creation, contract negotiation and signing, contract filing, contract performance, and contract termination. This standard specifies that digital contracts should meet security requirements regarding integrity, authenticity, confidentiality, and secure performance. In short, it should ensure the integrity of the digital contract and its log records; it should guarantee the authenticity of the signatories' identities through identity authentication and digital signature technologies, confirming consensus among all parties and avoiding subsequent disputes; it should encrypt sensitive contract information for confidentiality protection to prevent leakage; and it should record operation logs throughout the entire process, supporting evidence preservation and traceability. Furthermore, digital contract protocols should meet the principle of fairness (strongly fair exchange), meaning that when the agreement ends, either all participants receive a valid contract, or none receive one, avoiding unfair situations where some receive and others do not. According to the FLP impossibility theorem, in asynchronous distributed systems, a Trusted Third Party (TTP) must be introduced as a trust anchor to achieve strongly fair exchange. With a TTP, the exchange will only be completed when all signatories fulfill their obligations (e.g., both parties submit their signatures); if any party defaults, the TTP will roll back the transaction to ensure fairness for both parties.

[0048] The standard structure of the digital contract for the Asokan-Shoup-Waidner optimistic contract signing protocol is as follows: The protocol has security flaws that make it vulnerable to double-commitment and replay attacks, and it only supports negotiation of two-party digital contracts. Attackers can intercept and store commitment messages sent by sender O. and contract authentication parameters In subsequent new transactions, the attacker impersonates the sender O and resends this old data, inducing the receiver R to enter into an old contract with the attacker, thus compromising the timeliness and fairness of the transaction. Specifically, the double commitment attack involves the sender O sending contract authentication parameters... Although it is a commitment message to the recipient R The response was received, but the two parameters were unrelated, and the protocol could not prove they belonged to the same interaction. Malicious receiver. Newly generated malicious promises can be used match A valid but different contract is generated before the sender O. And save it, but do not expose it. This allows O to only obtain data based on... The contract is flawed because the sender O and receiver R each hold a valid but different contract, thus undermining the fairness and enforceability of the protocol.

[0049] The Garay-Jakobsson-MacKenzie private contract signing protocol has a single point of failure risk in TTP. If the TTP key is compromised, an attacker can obtain the TTP termination token. It is also possible to obtain the private signature combination of sender A. and An attacker could simultaneously induce A to abandon its contract claims and terminate the contract, while forcing B to take effect, resulting in a conflict in the protocol's state and undermining fairness. Furthermore, the action of TTP converting a private contract signature to a regular signature is untraceable; TTP could secretly leak the signature, maliciously convert it, or terminate the contract.

[0050] Multi-signature aggregation technology is a cryptographic technique that integrates the core advantages of multi-signature's "multi-party collaborative authorization" and aggregation signature's "efficient signature compression." Essentially, it allows multiple signers to sign the same message separately, then uses cryptographic algorithms to aggregate these independent signatures into a single, fixed-length unified signature. The verifier only needs a single aggregate public key to verify validity. This paper employs a locally verifiable aggregation signature algorithm based on national cryptographic algorithms, using aggregation signatures to improve verification efficiency and analyzing the correctness and security of the scheme. Multi-party contract signing protocols based on trusted third parties (TTPs) satisfy properties such as timeliness and non-repudiation; however, they require interaction between signatories in a fixed order and involve numerous steps. Currently, multi-signature aggregation technology is mainly applied in blockchain consensus and cross-chain interaction, and vehicle network security authentication. This application, based on the advantages of multi-signature aggregation technology, proposes an asynchronous signing method applicable to digital contracts, which not only meets the security requirements of digital contracts but also offers greater flexibility and high performance.

[0051] The existing technology has the following objective disadvantages: Limited signing order and insufficient flexibility: Existing technologies (such as the GB / T 36298-2018 standard process) require signatories to strictly follow a fixed order. The offeror must complete the signing first, and the offeree can only proceed with the signing operation after the TTP has been forwarded. This constraint makes the signing process highly dependent on the preceding steps. If any signatory delays its operation, it will directly cause the entire process to stop. Furthermore, it cannot support any signatory initiating a contract, making it difficult to adapt to business scenarios with multi-party collaboration and flexible signing requirements, thus limiting its scope of use. Insufficient resistance to attacks: Existing technologies are unable to defend against replay attacks and double commitment attacks, which can easily lead to contract inconsistencies and the failure of fairness; TTPs have single points of security risk, as key leaks can allow malicious manipulation of contract states, and such actions are untraceable; at the same time, the lack of a full-process evidence storage and traceability mechanism makes it difficult to locate anomalies and responsibilities. In addition, current digital contract standards have multiple dimensions of security requirements, making it a significant challenge to balance usability and process efficiency under high security requirements.

[0052] Lack of fault tolerance and state recovery mechanisms: Existing technologies do not have a contract exception handling process. When situations such as a signer failing to submit a signature within a timeout period, network interruption, node crash, or TTP anomaly occur, there is a lack of a mechanism to actively revoke the contract and a mechanism to force the contract to take effect. This can lead to the signing process being blocked indefinitely and signers having to wait meaninglessly. At the same time, the contract state cannot be effectively locked and recovered, making it difficult to guarantee the fairness and timely execution of digital contracts, and seriously reducing system availability and business continuity.

[0053] Frequent interactions and low efficiency: Some existing solutions require multiple information confirmations and status synchronizations between signatories to ensure signature validity and process continuity. Frequent interactions not only increase the burden on network communication but also significantly prolong signing time. When the signatories' network environment is unstable, problems such as information transmission delays and loss are likely to occur, further reducing signing efficiency. Signature verification is computationally expensive and resource-intensive: For digital contracts with m signatories, existing technologies require each signatory to independently verify the signatures of all signatories, i.e., performing m verification operations. As the number of signatories increases, the computational load of signature verification grows linearly, resulting in low verification efficiency.

[0054] like Figure 1 As shown in the embodiment of this application, a method for signing a digital contract is provided, which may include the following steps: S101. Receive a commitment message sent by the signing device, wherein the commitment message is determined by the signing device based on the digital contract text, the contract unique identifier, the signing public key, the trusted public key, the number of signing parties, the signing restriction time, and the hash value of the first commitment random number, wherein the hash value of the first commitment random number is obtained by hashing the commitment random number; Specifically, the embodiments of this application are applied to a signing system, which includes a trusted third-party device and multiple signing devices. The number of signing devices can be set as needed and is not specifically limited. The multiple signing devices communicate with the trusted third-party device TTP (Trusted Third Party).

[0055] Each signatory's equipment Use the private key to check the digital contract text separately. Contract ID is the unique identifier of the contract, and the public keys of all signatories. Number of signatories Signing time limit First commitment random number hash value Perform digital signature and generate commitment message A trusted third-party device receives signature messages sent by each signatory device, which indicate the signatory device's intention to sign the digital contract.

[0056] S102. If the commitment message passes the signature verification, the commitment message from the signatory device and the single signature data from the trusted third-party device are aggregated to generate an aggregated signature. Specifically, upon receiving the commitment messages from each signatory device, the trusted third-party device verifies the signature of each commitment message using the signatory public key of each signatory device. If all commitment messages pass verification, the trusted third-party device also generates single signature data and aggregates the commitment messages from all signatory devices and the single signature data from the trusted third-party device to generate an aggregate signature. .

[0057] In this embodiment, aggregate signature technology is used to aggregate the commitment messages of each signer device and the single signature data of a trusted third-party device. Among them, multi-aggregate signature technology is a cryptographic technology that combines the core advantages of multi-signature "multi-subject collaborative authorization" and aggregate signature "efficient signature compression". It allows multiple signers to sign the same message separately, and then uses cryptographic algorithms to aggregate multiple independent signatures into a unified signature of fixed length. The signer device only needs to use a single aggregate public key to complete the validity verification.

[0058] S103. Send the aggregated signature to the signing device so that the signing device can verify the aggregated signature; Specifically, the trusted third-party device sends the aggregated signature to each signatory device, thus completing the first stage of the signatory devices confirming their intention to sign the contract to the trusted third-party device.

[0059] After receiving the aggregated signature, the signing device verifies the aggregated signature using the public keys of all signing parties and trusted third parties. If the verification passes, it confirms that all signing devices have committed to signing the digital contract.

[0060] S104. If the signing device passes the verification of the aggregated signature, the trusted third-party device receives the contract request sent by the signing device, wherein the contract request includes the promised random number and the promised random number signature information corresponding to the promised random number; Furthermore, after the signing device passes the verification of the aggregated signature, that is, after each signing device has confirmed that all signing parties have committed to signing the digital contract, the signing device uses its private key to sign the commitment random number to obtain the commitment random number signature information. Each signing device then sends a contract request to a trusted third-party device. This contract request includes the commitment random number and the corresponding commitment random number signature information.

[0061] S105. Determine whether the contract request is effective based on the promised random number, the signature information of the promised random number, the hash value of the first promised random number, and the public key of the signer.

[0062] Specifically, when a trusted third-party device receives the promised random number and the promised random number signature information sent by each signer device, it uses the signer public key of each signer device to verify the promised random number signature information. If the verification is successful, it performs a hash operation on the promised random number to obtain a hash value, and compares the hash value with the hash value of the first promised random number. If the two are the same, it means that the contract has officially taken effect and a digital contract is generated.

[0063] S106. If the contract request is effective, send the commitment random number of all signer devices and trusted third-party devices and the signature information obtained by signing the commitment random number to the signer device, so that the signer device can use the public key of the trusted third-party device to verify the signature, and confirm that the digital contract is officially effective by calculating and comparing the hash value of the commitment random number.

[0064] Specifically, once the contract request is confirmed to be effective, the trusted third-party device concatenates the committed random numbers of all signatory devices with the committed random numbers of the trusted third-party device to obtain a concatenated random number. Based on this concatenated random number and the aggregated signature generated by aggregating all committed random numbers, it sends the concatenated random number to each signatory device. Each signatory device performs a hash calculation on the committed random number and then performs a comparison and verification. If the verification passes, the digital contract is confirmed to be effective.

[0065] In this embodiment, a trusted third-party device receives commitment messages from each signatory device, indicating their intention to sign. An aggregate signature is generated based on each commitment message. After each signatory verifies the aggregate signature, they send a contract request to the trusted third-party device. The trusted third-party device determines whether the contract request is valid. If valid, a digital contract is generated. In this way, the trusted third-party device simultaneously receives commitment messages from the signatory devices. The commitment messages can be signed asynchronously. Combined with aggregation technology and the ASW protocol, replay attacks and double commitment attacks are effectively resisted. This satisfies the requirements of integrity, authenticity, non-repudiation, traceability, and strong fairness of digital contracts. Without reducing security strength, it significantly improves signing flexibility, execution efficiency, and system robustness.

[0066] Another embodiment of this application further supplements the description of the digital contract signing method provided in the above embodiments.

[0067] like Figure 2 As shown, existing digital contract signing technologies suffer from problems such as fixed signing order, frequent interactions, low verification efficiency, insufficient anti-attack capabilities, high single point of failure risk in TTP, and lack of exception handling mechanisms. Furthermore, they are difficult to balance usability and process efficiency under comprehensive security standards. This application proposes an asynchronous digital contract signing method that integrates the national cryptographic SM2 aggregate signature, based on the ASW protocol and with improvements and optimizations.

[0068] This application uses a Trusted Third-Party Device (TTP) as a trust anchor and applies multi-signature aggregation technology to the asynchronous signing scenario of digital contracts. It supports asynchronous initiation, out-of-order submission, and non-interactive collaborative signing by any signatory. The TTP uniformly completes the signature verification and signature aggregation, and the signatory only needs to verify the legality of the multi-party signatures once.

[0069] The digital contract signing method provided in this application includes normal signing of the main agreement, suspension of the sub-agreement, and resolution of the sub-agreement. The overall operation follows the logic of "normal performance of the main agreement and fallback of the sub-agreement in case of anomalies": the normal signing of the main agreement adopts a two-stage structure of "commitment first, signing later". The contract will only enter the effective stage after all signatories have completed the submission of their commitments; the suspension of the sub-agreement is applicable to scenarios where the first stage of the main agreement is not completed and the signatories have not received confirmation of commitments from all signatories within the time limit. It supports the active cancellation of the contract and avoids invalid waiting; the resolution of the sub-agreement is applicable to scenarios where the main agreement has completed the commitments of all signatories, but the final effective contract cannot be obtained due to anomalies. It supports the forced effectiveness of the contract and ensures that the commitments can be fulfilled.

[0070] Among them, the suspension sub-agreement and the resolution sub-agreement adopt the first-come-first-served and mutually exclusive execution rules, and are uniformly arbitrated by TTP. The two cannot take effect at the same time, ensuring that the contract state is unique and consistent. From the process and mechanism level, it strictly guarantees strong fairness that "either all signatories obtain a valid contract or none of them can obtain a valid contract", prevents state conflicts, and ensures strong fairness, which constitutes the core of the protocol's security.

[0071] Meanwhile, the embodiments of this application, in conjunction with TTP redundancy and distributed evidence storage mechanisms, solve the problems of process blockage, fairness imbalance and single point of failure. They can effectively resist replay attacks and double commitment attacks, and meet the requirements of digital contract integrity, authenticity, non-repudiation, traceability and strong fairness. Without reducing security strength, they significantly improve signing flexibility, execution efficiency and system robustness, and provide highly secure, efficient and highly available digital contract signing support for scenarios such as trusted data spaces and multi-party data circulation. They have important technical value and application prospects.

[0072] To ensure fairness in the contract, a formal signing process only commences after the signatory has received signing commitments from all other signatories. Based on the ASW protocol execution process, the main agreement proposed in this application embodiment is divided into two phases, the first phase being the signing parties… Sign the commitment The first step is to send a commitment random number to the TTP, indicating the intention to sign the contract; the second step is for the signatory to confirm that all other signatories have committed to signing before sending the commitment random number. Digital contracts are officially launched.

[0073] The structure of a normally signed digital contract is as follows: Among them, aggregate signature Commitment message for all signatory devices Commitment messages with trusted third-party devices TTP Generated by mathematical operations and aggregation. String concatenation for a promise of random numbers.

[0074] The specific agreement process is as follows: Phase 1: Signatory equipment Use private keys separately Digital contract text Contract ID, public keys of all signatories Number of signatories , specified time , promise random number hash value Perform digital signature and generate commitment message And send it to a trusted third-party device TTP, indicating an intention to sign a digital contract, in which ; The trusted third-party device TTP receives a signature message from any of the signing party devices. Then, use the signer's public key. After all individual signatures have been verified, the trusted third-party device TTP, acting as a special signatory, also signs the digital contract, thus obtaining a commitment message from the trusted third-party device. Then, the commitment messages from each signatory device and the commitment messages from the trusted third-party device are aggregated to generate a signature result. (Includes all committed random number hashes) ), and broadcast to all signatory devices. Finally, log evidence is stored.

[0075] Optionally, the commitment message is obtained in the following manner: The signing device determines the digital contract data based on the digital contract text, the unique contract identifier, the signer's public key, the trusted public key, the number of signers, and the signing restriction time. The signing device randomly generates a base random number and a commitment random number, wherein the commitment random number... Used to initiate a contract; The signing device uses its private key to sign the digital contract data and the hash value of the commitment random number to obtain the commitment message.

[0076] In this embodiment, the signing device uses its private key to sign the digital contract text, the contract's unique identifier, the signing party's public key, the trusted public key, the number of signing parties, the signing restriction time, and the commitment random number hash value, generating a commitment message to ensure the uniqueness of the data and provide security for data signing. Optionally, the signing device uses its private key to sign the digital contract data and the commitment random number hash value to obtain the commitment message, including: Based on the signatory's identity information and elliptic curve parameters, the first contract parameter Z1i is determined; Perform a hash operation on the promised random number to obtain the first hash parameter ωi; The first contract data is determined based on the first hash parameter, the first contract parameter, and the digital contract data. ; Perform a hash operation on the first contract data to obtain the second hash parameter ei; The first verification data ri is determined based on the second hash parameter and the first point on the finite elliptic domain; The first processing result si is determined based on the signer's private key di, the first verification data ri, and the basic random number; The commitment message is determined based on the first verification data, the first processing result, the points on the finite elliptic domain, and the first hash parameter.

[0077] Specifically, the signing device concatenates the x and y coordinates of the base point information on the finite elliptic domain with the identification information of the signing device, and then performs a hash operation on the concatenated data to obtain the first contract parameter Z1i, which is as follows: , in: For the identification information of the signing party's equipment, for The length is converted into 2 bytes of data, where ; The commitment random number from the signatory device is hashed to obtain the first hash parameter ωi; then the first contract parameter, the first hash parameter, and the digital contract data C are concatenated to obtain the first contract data. Specifically: ,in ; Perform a hash operation on the first contract data to obtain the second hash parameter ei, i.e. ; Based on the base random number of the signing device, the first point information on the finite elliptic domain is determined. Then, based on the second hash parameter ei and the first point information xi on the finite elliptic domain, the first verification data ri is determined, i.e. ; Where mod is the modulo operation; Based on the signer's private key di, the first verification data ri, and the basic random number ki, the first processing result si is determined, i.e. ; Based on the first verification data, the first processing result, the points on the finite elliptic domain, and the first hash parameter, the commitment message is determined, i.e., the commitment message is... .

[0078] Optionally, the commitment message is determined through signature verification in the following manner: The second contract parameter Z2i is determined based on the signatory's identity information and elliptic curve parameters. The second contract data Ci is determined based on the first hash parameter ωi, the second contract parameter Z2i, and the digital contract data C; Perform a hash operation on the second contract data to obtain the third hash parameter ei; The second processing result ti is determined based on the first verification data ri and the first processing result si; Based on the first processing result, the second processing result, and the signatory's public key, determine the second point information on the finite elliptic domain; The second verification data R is determined based on the third hash parameter ei and the second point information on the finite elliptic domain; If the first verification data and the second verification data are the same, the commitment message is determined to have passed the signature verification.

[0079] Specifically, the trusted third-party device TTP receives the commitment message. Then, within time t, immediately send a message to the signing party's equipment. Return Receive Token Within time t, the trusted third-party device TTP receives commitment messages from all signatories, i.e., m digital signature results. Perform the following single commitment message verification steps.

[0080] Trusted third-party devices use the signatory's identity information and elliptic curve parameters, specifically the contract identifier length field, to determine the contract identifier length. Unique identifier of the signatory Elliptic curve parameters (a, b), coordinates of base point G Public key coordinates of the signatory The concatenated data is then hashed to obtain the second contract parameter Z2i. The specific calculation process is as follows: ; Then, the first hash parameter ωi, the second contract parameter Z2i, and the digital contract data C are concatenated to obtain the second contract data, i.e. ; Perform a hash operation on the second contract data to obtain the third hash parameter. ,Right now ; Add the first verification data ri and the first processing result si, and take the modulo of the sum with n to obtain the second processing result ti, i.e. ; Based on the first processing result si, the second processing result ti, and the signatory's public key PPi, the second point information on the finite elliptic domain is determined, namely... ; The second verification data is determined based on the third hash parameter ei and the second point information xi on the finite elliptic domain. ,calculate .

[0081] A trusted third-party device determines whether the second verification data is the same as the first verification data, that is, it determines... The verification process will proceed if the signatures are valid; otherwise, the verification will pass. (If all signatories...) If the signature verification is successful, the trusted third-party device TTP will also digitally sign the digital contract text C according to the above signing steps, generating a signature. And perform the following aggregate signature operation.

[0082] Optionally, if the commitment message passes signature verification, the step of aggregating the commitment message from the signing device and the single signature data from the trusted third-party device to generate an aggregated signature includes: The second hash parameter in the commitment message of the signing device and the trusted hash parameter in the single signature data are concatenated to obtain concatenated data. The single signature data is obtained by signing the digital contract data with the private key of the trusted third-party device, and the single signature data contains a trusted hash parameter, which is an intermediate hash value generated by the trusted third party during the signing process of the digital contract data. Perform a hash operation on the concatenated data to obtain the fourth hash data E; Determine the information of the third point in the finite elliptical domain based on the points in the finite elliptical domain; Based on the fourth hash data E and the third point information, the third verification data R is determined; Based on the first processing result si, the fourth verification data U is determined; Based on the first processing result si, the first verification data ri, and the first hash parameter, the time limit data T is determined; The aggregate signature is determined based on the third verification data R, the fourth verification data U, and the time limit data T.

[0083] Specifically, the Trusted Third-Party Device (TTP) aggregates all commitment messages, which include commitment messages from m signatories. And TTP's own single signature data Aggregate to generate an aggregate signature. And send it to all signatories within the specified time t.

[0084] The specific signature aggregation process is as follows: First, a third-party device can concatenate the second hash parameter in the commitment message from the signing device and the trusted hash parameter in the single signature data to obtain concatenated data. The single signature data is obtained by signing the digital contract data using the private key of a trusted third-party device, and it contains a trusted hash parameter, which is an intermediate hash value generated by the trusted third party during the signing process of the digital contract data. A hash operation is then performed on the concatenated data to obtain the fourth hash data E, i.e. ; A trusted third-party device determines information about a third point on the finite elliptic domain based on the second point on the finite elliptic domain. ; Based on the fourth hash data E and the third point information, the third verification data R is determined, i.e. ; Based on the first processing result si, the fourth verification data U is determined, i.e. ; Based on the first processing result si and the first verification data ri, calculate ; Then, multiple ti and multiple first hash parameters ωi are concatenated to determine the time-limited data T, i.e., the calculation is performed. ; Based on the third verification data R, the fourth verification data U, and the time limit data T, the aggregate signature is determined, i.e., the aggregate signature is... .

[0085] Trusted third-party device TTP aggregates signatures through an encrypted channel. The process is synchronized to all signatory devices and locally stored. Then, the signatory devices verify whether TTP has received commitments from all signatories through the following aggregated verification steps. And obtain the hash values ​​of the commitment random numbers of all signatories. .

[0086] Optionally, the signing device verifies the aggregated signature to obtain a first verification result, including: The third contract parameter Z3i is determined based on the signatory's identity information and elliptic curve parameters. The third contract data is determined based on the first hash parameter ωi, the third contract parameter Z3i, and the digital contract data C. ; Perform a hash operation on the third contract data to obtain the fifth hash parameter ei; The fifth hash parameter is concatenated to obtain the concatenated data; Perform a hash operation on the concatenated data to obtain the sixth hash parameter d; Based on the fourth verification data U, the second processing result ti, and the signer's public key, the fourth point information on the finite elliptic domain is determined. The fifth verification data is determined based on the information of the fourth point on the finite elliptic domain and the sixth hash parameter. ; If the third verification data R and the fifth verification data Similarly, it is determined that the signatory has verified the aggregated signature.

[0087] Specifically, the signatory receives the aggregate signature within the signing restriction period t. Then, use the public keys of all signatories and TTP. Verify that TTP has received all commitment messages by following these steps: The signing party's device determines the third contract parameter Z3i based on the signing party's identity information and elliptic curve-related parameters. ; Based on the first hash parameter ωi, the third contract parameter Z3i, and the digital contract data C, the third contract data is determined. ; Perform a hash operation on the third contract data to obtain the fifth hash parameter. ,Right now ; The fifth hash parameter is concatenated to obtain concatenated data. A hash operation is then performed on the concatenated data to obtain the sixth hash parameter d. ; Based on the fourth verification data U, the second processing result ti, and the signatory's public key, the fourth point information on the finite elliptic domain is determined, i.e., the calculation... ; The fifth verification data is determined based on the information of the fourth point on the finite elliptic domain and the sixth hash parameter d. ,Right now .

[0088] The signing device compares the third verification data R with the fifth verification data, i.e., checks... If the transaction is successful, the signatory device confirms that all signatories have committed to signing the digital contract and that the TTP certificate has been successfully stored.

[0089] In this embodiment, by embedding the unique identity of the signatory into the signature, verifying each signature individually with a trusted third-party device, retaining the association information of each signatory in the aggregated signature, and binding the unique contract ID throughout the process, TTP completes the notarization after completing the signature aggregation and generating the formal contract, thus achieving traceability, identifiable responsibility, and non-repudiation of the behavior.

[0090] In this embodiment, replay attacks can be effectively resisted by using a one-time commitment to a random number, a unique contract identifier ID, a time limit, and a digital signature; at the same time, double commitment attacks can be effectively resisted by strongly binding the commitment information with the contract context and globally locking the aggregated signature, thus ensuring the uniqueness of the contract session.

[0091] Based on the above embodiment, after receiving commitments from each signatory device, the second phase begins: all signatories receive the aggregate signature. Then, use the public keys of all signatories and TTP. Verification is performed; if the signature verification passes, it confirms that all signatories have committed to the digital contract. Then, each signatory device uses its own private key to sign its own committed random number and sends the committed random number to the relevant database. and signature value And sent to TTP; Upon receiving the information, TTP first uses the signer's public key. Verification and confirmation of commitment to random number To verify the authenticity and integrity of the signature, if the signature is verified, the hash value of the promised random number is calculated. The contract is then compared with the data received in the first phase. If they match, the contract officially takes effect and is logged for verification. The final generated formal contract structure is as follows: ; TTP will receive all committed random numbers as well as The signature is sent to all signatory devices. Signatory equipment This can be achieved by calculating the hash value of all committed random numbers. And by comparing it with the previously received data, it was confirmed that the contract had taken effect.

[0092] Optionally, TTP determines whether the contract request is effective based on the promised random number, the signature information of the promised random number, the hash value of the first promised random number, and the public key of the signer, including: The aggregated signature is sent to the signing device so that the signing device verifies the aggregated signature and obtains a first verification result. The first verification result is used to determine whether the trusted third-party device has received the commitment messages from all signing devices within the signing restriction time. If the first verification result is successful, a contract request sent by the signing device is received, the contract request including the commitment random number and the commitment random number signature information corresponding to the commitment random number; The signature information of the promised random number is verified to obtain a second verification result, which is used to determine the authenticity and integrity of the promised random number. If the second verification result is successful, the validity of the contract request is determined based on the promised random number and the hash value of the first promised random number.

[0093] Specifically, each signatory device interacts with TTP to commit to random numbers. This officially launches digital contracts. The signing devices each use their own private keys to commit to a random number. Perform signature processing and generate and commit to random numbers and signature value The signature is sent to TTP. TTP uses the signer's public key to perform a second verification on each signature value, obtaining the second verification result.

[0094] If the second verification result is successful, the trusted third-party device performs a hash operation on the promised random number to obtain the hash result, i.e. and the hash value of the first committed random number. The two hash values ​​are compared. If they match, the trusted third-party device TTP uses its own private key to sign the concatenation result of the promised random numbers from all signing devices and the promised random number from the trusted third party. Generate signature The trusted third-party device broadcasts it to all signatories, and the contract officially takes effect.

[0095] After receiving the data, the signing device first uses the trusted public key. Verification is performed, and then a random number is generated based on the commitment. The commitment hash value obtained by hash calculation is then compared with the hash value received from TTP during the aggregation and verification phase. The comparison confirms that the contract has taken effect.

[0096] In this embodiment, the signatory confirms that all other participating parties besides itself have committed to signing before the final formal signing takes place. This dual verification enhances the security of digital contract generation.

[0097] Optionally, if the second signature verification result is successful, the validity of the contract request is determined based on the promised random number and the hash value of the first promised random number, including: Perform a hash operation on the promised random number to obtain the hash value of the second promised random number; The hash values ​​of the first and second commitment random numbers are compared. If the hash value of the first commitment random number matches the hash value of the second commitment random number, the contract request is deemed to be effective.

[0098] In this embodiment, a trusted third-party device determines whether the contract request is effective based on the promised random number and the hash value of the first promised random number, thereby improving the accuracy of digital contract generation.

[0099] Based on the above embodiments, the existing technology does not have a contract exception handling process. When situations such as the signer failing to submit the signature within the time limit, network interruption, node crash, or TTP abnormality occur, there is a lack of a mechanism to actively revoke the contract and a mechanism to force the contract to take effect. This leads to the signing process being easily blocked indefinitely, and the signer having to wait meaninglessly. At the same time, the contract state cannot be effectively locked and restored, making it difficult to guarantee the fairness and timely execution of digital contracts, and seriously reducing system availability and business continuity.

[0100] Furthermore, in this method, both the single signature verification and signature aggregation steps are executed by the TTP. To avoid single points of failure, i.e., if the TTP temporarily fails due to malicious attacks or other events, a specific signatory can be designated as a backup node in advance. During key steps such as successful signature verification, aggregated signature generation, sub-protocol processing, and contract activation, the main TTP synchronizes the contract status, signature data, and operation logs to the backup TTP in real time.

[0101] Based on this, this application also provides a contract termination sub-agreement and a contract resolution sub-agreement, such as Figure 3 Optionally, the method further includes: if the trusted third-party device does not receive commitment messages from all signing party devices within a first preset time period, receiving a contract termination request sent by the signing party devices, wherein the contract termination request includes a termination identifier and the signing party's commitment message; determining a first token information type corresponding to the termination identifier based on the contract termination request, wherein the first token information type includes a first termination token or a first resolution token, the first termination token being used to revoke the digital contract, the first resolution token being used to determine that the digital contract has taken effect and is irrevocable, and the first preset time period being within the signing restriction time; Based on the first token information type, determine the execution operation corresponding to the contract termination request.

[0102] Specifically, when the signing party's equipment A commitment message has been sent. However, I haven't received confirmation from TTP that all commitments have been collected within the signing deadline t. This means that the first phase of the main agreement was not successfully completed, and the signatory's equipment... The abort sub-protocol can be initiated to revoke the digital contract. Possible scenarios include failure to verify the commitment message received by TTP, other signatories refusing to commit to signing the digital contract, system failures such as network outages and node crashes. The digital contract abort token structure is as follows: The specific agreement process is as follows: Signatory device A initiates a contract termination request to a trusted third party, TTP. ; Trusted third-party device TTP checks whether the digital contract has been resolved: If the issue remains unresolved, the digital contract is revoked, and a first termination token is generated and returned. And log evidence is stored; If resolved, the contract is now officially in effect and irrevocable, generating and returning the first resolution token. .

[0103] In this embodiment of the application, the suspension sub-protocol is a suspension token that can be issued by a trusted third-party device, allowing the contract to be revoked before all signatories have fulfilled their commitments.

[0104] like Figure 4 As shown, optionally, the method further includes: If the signing device does not receive all committed random number splices from the trusted third-party device within the second preset time period. and its signature In the case of receiving a contract resolution request sent by the signing device, wherein the contract resolution request includes the aggregate signature. The second preset time period is within the signing restriction time. Based on the contract resolution request, a corresponding second token information type is determined, wherein the second token information type includes a second termination token or a second resolution token; the second termination token is used to determine that the digital contract has been revoked, and the second resolution token is used to force the digital contract to take effect; Based on the second token information type, determine the execution operation corresponding to the contract resolution request.

[0105] Specifically, when the signatory Confirmation has been received that TTP has collected all commitments. However, the finalized digital contract cannot be obtained within the specified time t. This can initiate a resolution sub-protocol, forcing the contract to take effect. Possible scenarios include other signatories failing to execute the next step of the protocol (the second phase involves sending a commitment random number). System failures such as network outages and node crashes. Digital contracts resolve system failures such as network interruptions and node crashes. The replacement contract generated by the sub-protocol is... .

[0106] Signatory A may initiate a contract settlement request to TTP. ; TTP checks whether the digital contract has been suspended: If not aborted, the digital contract is forced to take effect, generating and returning a second resolution token. ; If the contract has been suspended, the prohibition resolution has been revoked, and a second suspension token is generated and returned. .

[0107] In this embodiment of the application, the solution sub-protocol is that a trusted third-party device can issue an alternative contract. This provides non-repudiable proof of commitment from both parties, preventing any signatory from reneging on their commitment and forcing the contract to take effect. Through time limits and digital contract suspension and resolution sub-agreements, it ensures the process is not blocked indefinitely and that signatories do not wait indefinitely. They can proactively cancel the digital contract or force it to take effect. The asynchronous digital contract signing method proposed in this application basically complies with the electronic contract conclusion process requirements in GB / T 36298-2018, but improves the contract cancellation and forced effect by designing suspension and resolution sub-agreements for abnormal situations, making it more convenient, flexible, and efficient.

[0108] This application provides a locally verifiable aggregate signature algorithm based on the Chinese national cryptographic standard SM2, applicable to the aggregate signature of different messages. This application introduces a committed random number during the signing process and combines it with the ASW protocol execution process. The TTP participates in contract signing not only as an aggregator but also as a special signatory, simplifying the signature algorithm for signing the same digital contract.

[0109] Another method for signing a digital contract provided in this application includes: 1) Each signatory and trusted third party uses a preset key generation algorithm to generate the private and public keys of each signatory; Each signatory obtains digital contract text information, contract identifier corresponding to the digital contract text information, signatory name, number of signatories, signatory public key, trusted third-party public key, and signing restriction time, determines digital contract data C, and generates contract identifier information for each digital contract data; Specifically, digital contract signatories After completing identity registration and authentication, proceed with digital contract negotiation to clarify digital contract information M and the signatories. And quantity m, trusted third party (TTP) The time limit t is a constraint on the transmission of TTP messages in either signing direction, designed to meet the timeliness and termination requirements of digital contracts.

[0110] Any signatory Digital contract data can be created in TTP And obtain a unique contract identifier ID. After creation, TTP establishes an encrypted channel to all authenticated signatories. Publish digital contract data .

[0111] System setup and parameter disclosure: Defining large prime numbers finite field , Elliptic curve The parameters, The base point on the elliptic curve and , Based on, Based on The rank, The abstract length is The hash function.

[0112] 2) Each signatory randomly generates a base random number and a commitment random number, the commitment random number being used to initiate the contract; Each signatory uses a private key The digital contract data C is signed to obtain a commitment message. ; Each signatory will send its commitment message to a trusted third party; Specifically, multiple signatories And TTP select random number ,and .calculate Its public-private key pair is .

[0113] Multiple signatories Each holds a private key Select random number and (in It is a commitment to random numbers (used to initiate contracts), which are then used to process digital contract data. Perform digital signature And respectively (i.e. asynchronously) send m commitment messages Send to TTP.

[0114] 3) The trusted third party receives the commitment message sent by each signer, returns a receiving token to each signer within time t, and verifies the commitment message using the public key of each signer within time t; 4) After the trusted third party verifies the signatures of all signatories, it digitally signs the digital contract data according to the above-mentioned signing method to obtain a single-signature data. ; 5) A trusted third party aggregates the commitment messages from each signatory and the single signature data to generate an aggregated signature, and sends the aggregated signature to each signatory; The multi-aggregate signature scheme used in this asynchronous digital contract signing method is a signature technology scheme based on asymmetric cryptography. Its core objective is to allow multiple signers (m≥2) to generate independent digital signatures for the same message (such as a digital contract). Then, a specific entity (such as the trusted third party TTP in this method) aggregates all valid independent signatures into a unified aggregate signature using a cryptographic algorithm. Subsequent verification only requires a single verification operation to validate the legality of all signatures, while ensuring a strong binding between the signature, the message, and the signer's identity. The multi-aggregate signature algorithm used in the proposed method is not specifically limited in the embodiments of this application.

[0115] 5) TTP aggregates signatures through an encrypted channel. The agreement is then synchronized with all signatories and locally stored. The signatories then verify, through the following aggregated signature verification steps, whether the TTP has received commitments from all signatories. And obtain the hash values ​​of the commitment random numbers from all signatories. .

[0116] 6) The signer verifies the aggregated signature and obtains the first verification result, that is, the signer performs aggregated verification on the aggregated signature to determine whether the trusted third party has received the commitment messages of all signers and obtains the commitment random number hash value ωi of all signers; 7) The signer uses its own private key to calculate the signature of the promised random number, thus obtaining the signature information of the promised random number. And will commit to random numbers and the promised random number signature information Send to a trusted third party.

[0117] 8) A trusted third party uses the signer's public key to verify the signed promise random number, and calculates the hash of the received promise random number and compares it with the hash value of the previously received promise random number. If they match, then a random number is generated by combining the commitments of all signatories. And sign. Send to the signatory; the signatory receives Then, the signature is verified using the public key of a trusted third party, by verifying the committed random number. Perform hash calculations and combine them with the data received from TTP during the earlier aggregation and signature verification phase. The comparison confirms that the contract has taken effect.

[0118] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0119] This application embodiment is based on the ASW protocol execution process, improves the multi-signature aggregation technology and innovatively applies it to digital contract signing. It supports any signatory to submit signatures asynchronously and out of order, without the need for a fixed signing order and interaction with multiple parties. The TTP uniformly completes signature aggregation and one-time signature verification, which greatly improves signing flexibility, signature verification efficiency and reduces communication overhead.

[0120] In this embodiment, during the process of signature verification, aggregate signature generation, sub-protocol processing, or contract activation by the primary trusted third-party device, the contract status, signature data, and operation logs are synchronized to the backup trusted third-party device in real time, thus resolving the single point of failure in TTP and improving system robustness. This asynchronous digital contract signing method uses a two-part structure of a main protocol that requires commitment before signing. It is designed with and complements contract termination and resolution sub-protocols, which can proactively revoke contracts or force contracts to take effect in abnormal scenarios, ensuring that the process is not blocked and that signing is timely. It strictly guarantees strong fairness: either everyone gets a valid contract or no one gets one, and no one can profit unilaterally. It builds a highly secure and traceable overall protection mechanism, which resists replay and double commitment attacks by binding commitment information with contract context. Combined with identity-embedded signature and master-slave TTP distributed storage, it achieves full traceability and solves the single point of failure of TTP.

[0121] The digital signature technology in this application embodiment guarantees the signing party's rights. The TTP identity information is authentic and valid, and the transmitted data has not been tampered with or deleted, ensuring data authenticity and integrity. Digital contracts are concluded through a TTP independent of the signatories. This meets the requirement of GB / T 36298-2018 that electronic contracts should be concluded through a third-party electronic contract service platform independent of the contracting parties. Through primary and backup TTP redundancy and distributed notarization, the risk of TTP failure is mitigated. The aggregated signature embeds a single, non-public TTP signature, preventing attackers from impersonating TTPs and generating aggregated signatures, thus achieving single-point-of-failure disaster recovery for the TTP.

[0122] The asynchronous method provided in this application embodiment does not require the signer to follow a specific signing order, and any signer can initiate contract signing, making it more convenient and flexible. The aggregation technology reduces the number of signature verifications and computational costs for the signer, especially for contract signing scenarios with multiple signers.

[0123] Please refer to Figure 4 , Figure 4 A block diagram illustrating the composition of a digital contract signing apparatus provided in some embodiments of this application is shown. It should be understood that this digital contract signing apparatus is similar to the one described above. Figure 1Corresponding to the method embodiments, it is able to execute the various steps involved in the above method embodiments. The specific functions of the digital contract signing device can be found in the description above. To avoid repetition, detailed descriptions are appropriately omitted here.

[0124] Figure 5 The digital contract signing device includes at least one software function module that can be stored in memory or embedded in the digital contract signing device in the form of software or firmware. The digital contract signing device includes: The receiving module 401 is used to receive a commitment message sent by the signing device, wherein the commitment message is determined by the signing device based on the digital contract text, the unique identifier of the contract, the signer's public key, the trusted public key, the number of signers, the signing restriction time, and the hash value of the first commitment random number, wherein the first commitment random number hash value is obtained by hashing the commitment random number; The aggregation module 402 is used to aggregate the commitment message from the signatory device and the single signature data from the trusted third-party device to generate an aggregated signature when the commitment message passes the signature verification. The first signature verification module 403 is used to send the aggregated signature to the signing device so that the signing device can verify the aggregated signature. The request module 404 is used to receive a contract request sent by the signing device when the signing device passes the verification of the aggregated signature, wherein the contract request includes the promised random number and the promised random number signature information corresponding to the promised random number; The second signature verification module 405 is used to determine whether the contract request is effective based on the promised random number, the signature information of the promised random number, the hash value of the first promised random number, and the public key of the signer; The generation module 406 is used to send the commitment random numbers of all signer devices and trusted third-party devices and the signature information obtained by signing the commitment random numbers to the signer device when the contract request takes effect, so that the signer device can use the public key of the trusted third-party device to verify the signature, and confirm that the digital contract has officially taken effect by calculating and comparing the hash value of the commitment random number.

[0125] In this embodiment, a trusted third-party device receives commitment messages from each signatory device, indicating their intention to sign. An aggregate signature is generated based on each commitment message. After each signatory verifies the aggregate signature, they send a contract request to the trusted third-party device. The trusted third-party device determines whether the contract request is valid. If valid, a digital contract is generated. In this way, the trusted third-party device simultaneously receives commitment messages from the signatory devices, enabling concurrent processing of these messages. The signatory can sign commitment messages asynchronously. Combined with aggregation technology and the ASW protocol, this effectively resists replay attacks and double commitment attacks, meeting the requirements of digital contract integrity, authenticity, non-repudiation, traceability, and strong fairness. Without reducing security strength, it significantly improves signing flexibility, execution efficiency, and system robustness.

[0126] Optionally, the second signature verification module is used for: The aggregated signature is sent to the signing device so that the signing device verifies the aggregated signature and obtains a first verification result. The first verification result is used to determine whether the trusted third-party device has received the commitment messages from all signing devices within the signing restriction time. If the first verification result is successful, a contract request sent by the signing device is received, the contract request including the commitment random number and the commitment random number signature information corresponding to the commitment random number; The signature information of the promised random number is verified to obtain a second verification result, which is used to determine the authenticity and integrity of the promised random number. If the second verification result is successful, the validity of the contract request is determined based on the promised random number and the hash value of the first promised random number.

[0127] In this embodiment, the signatory confirms that all other participating parties besides itself have committed to signing before the final formal signing takes place. This dual verification enhances the security of digital contract generation.

[0128] Optionally, the second signature verification module is used for: Perform a hash operation on the promised random number to obtain the hash value of the second promised random number; The hash values ​​of the first and second commitment random numbers are compared. If the hash value of the first commitment random number matches the hash value of the second commitment random number, the contract request is deemed to be effective.

[0129] In this embodiment, a trusted third-party device determines whether the contract request is effective based on the promised random number and the hash value of the first promised random number, thereby improving the accuracy of digital contract generation.

[0130] Optionally, the commitment message is obtained in the following manner: The signing device determines the digital contract data based on the digital contract text, the unique contract identifier, the signer's public key, the trusted public key, the number of signers, and the signing restriction time. The signing device randomly generates a base random number and a commitment random number, the commitment random number being used to initiate the contract; The signing device uses its private key to sign the digital contract data and the hash value of the commitment random number to obtain the commitment message.

[0131] In this embodiment, the signing device uses its private key to sign the digital contract text, the contract's unique identifier, the signing party's public key, the trusted public key, the number of signing parties, the signing restriction time, and the hash value of the promised random number, thereby generating a commitment message to ensure the uniqueness of the data and provide security for data signing.

[0132] Optionally, the signing device includes a signing module, the signing module being used for: Based on the signatory's identity information and elliptic curve-related parameters, the first contract parameter Z1i is determined; Perform a hash operation on the promised random number to obtain the first hash parameter ωi; The first contract data Ci is determined based on the first hash parameter, the first contract parameter, and the digital contract data; Perform a hash operation on the first contract data to obtain the second hash parameter ei; The first verification data ri is determined based on the second hash parameter and the first point on the finite elliptic domain; The first processing result si is determined based on the signer's private key di, the first verification data ri, and the basic random number; The commitment message is determined based on the first verification data, the first processing result, the points on the finite elliptic domain, and the first hash parameter.

[0133] Optionally, the signing module is used for: The second contract parameter Z2i is determined based on the signatory's identity information and elliptic curve parameters. The second contract data Ci is determined based on the first hash parameter ωi, the second contract parameter Z2i, and the digital contract data C; Perform a hash operation on the second contract data to obtain the third hash parameter ei; The second processing result ti is determined based on the first verification data ri and the first processing result si; Based on the first processing result, the second processing result, and the signatory's public key, determine the second point information on the finite elliptic domain; The second verification data R is determined based on the third hash parameter ei and the second point information on the finite elliptic domain; If the first verification data and the second verification data are the same, the commitment message is determined to have passed the signature verification.

[0134] Optionally, the aggregation module is used for: The second hash parameter in the commitment message of the signing device and the trusted hash parameter in the single signature data are concatenated to obtain concatenated data. The single signature data is obtained by signing the digital contract data with the private key of the trusted third-party device, and the single signature data contains a trusted hash parameter, which is an intermediate hash value generated by the trusted third party during the signing process of the digital contract data. Perform a hash operation on the concatenated data to obtain the fourth hash data E; Determine the information of the third point in the finite elliptical domain based on the points in the finite elliptical domain; Based on the fourth hash data E and the third point information, the third verification data R is determined; Based on the first processing result si, the fourth verification data U is determined; Based on the first processing result si, the first verification data ri, and the first hash parameter, the time limit data T is determined; The aggregate signature is determined based on the third verification data R, the fourth verification data U, and the time limit data T.

[0135] In this embodiment, replay attacks can be effectively resisted by using a one-time commitment to a random number, a unique contract identifier ID, a time limit, and a digital signature; at the same time, double commitment attacks can be effectively resisted by strongly binding the commitment information with the contract context and globally locking the aggregated signature, thus ensuring the uniqueness of the contract session.

[0136] Optionally, the signing module is used for: The third contract parameter Z3i is determined based on the signatory's identity information and elliptic curve parameters. The third contract data Ci is determined based on the first hash parameter ωi, the third contract parameter Z3i, and the digital contract data C; Perform a hash operation on the third contract data to obtain the fifth hash parameter ei; The fifth hash parameter is concatenated to obtain the concatenated data; Perform a hash operation on the concatenated data to obtain the sixth hash parameter d; Based on the fourth verification data U, the second processing result ti, and the signer's public key, the fourth point information on the finite elliptic domain is determined. The fifth verification data is determined based on the information of the fourth point on the finite elliptic domain and the sixth hash parameter; If the third verification data R and the fifth verification data are the same, it is determined that the signer has passed the verification of the aggregate signature.

[0137] In this embodiment, by embedding the unique identity of the signatory into the signature, verifying each signature individually with a trusted third-party device, retaining the association information of each signatory in the aggregated signature, and binding the unique contract ID throughout the process, TTP completes the notarization after completing the signature aggregation and generating the formal contract, thus achieving traceability, identifiable responsibility, and non-repudiation of the behavior.

[0138] Optionally, the generation module is used to: If a trusted third-party device does not receive commitment messages from all signing party devices within a first preset time period, it receives a contract termination request sent by the signing party devices, wherein the contract termination request includes a termination identifier and a commitment message from the signing party; based on the contract termination request, it determines a first token information type corresponding to the termination identifier, wherein the first token information type includes a first termination token or a first resolution token, the first termination token is used to revoke the digital contract, and the first resolution token is used to determine that the digital contract has taken effect and is irrevocable, and the first preset time period is within the signing restriction time; Based on the first token information type, determine the execution operation corresponding to the contract termination request.

[0139] In this embodiment of the application, the suspension sub-protocol is a suspension token that can be issued by a trusted third-party device, allowing the contract to be revoked before all signatories have fulfilled their commitments; Optionally, the generation module is used to: If the signing device does not receive a digital contract sent by a trusted third-party device within a second preset time period, the signing device receives a contract resolution request sent by the signing device, wherein the contract resolution request includes an aggregate signature, and the second preset time period is within the signing restriction time. Based on the contract resolution request, a corresponding second token information type is determined, wherein the second token information type includes a second termination token or a second resolution token; the second termination token is used to determine that the digital contract has been revoked, and the second resolution token is used to force the digital contract to take effect; Based on the second token information type, determine the execution operation corresponding to the contract resolution request.

[0140] In this embodiment, the resolution sub-agreement is an alternative contract that can be signed by a trusted third-party device, providing non-repudiable proof of the commitments made by both parties, preventing the signatory from reneging on their commitment, and forcing the contract to take effect. Through time limits and the digital contract termination and resolution sub-agreements, it is ensured that the process will not be blocked indefinitely, and the signatory will not wait indefinitely; they can proactively cancel the digital contract or force it to take effect.

[0141] It is understood that the above-described device embodiments correspond to the method embodiments of the present invention. The digital contract signing device provided by the embodiments of the present invention can implement the digital contract signing method provided by any one of the method embodiments of the present invention.

[0142] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0143] like Figure 6 As shown, some embodiments of this application provide an electronic device 500, which includes: a memory 510, a processor 520, and a computer program stored on the memory 510 and executable on the processor 520, wherein when the processor 520 reads the program from the memory 510 via a bus 530 and executes the program, it can implement any of the methods included in the above-described digital contract signing method.

[0144] Processor 520 can process digital signals and can include various computing architectures. For example, it can be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 520 can be a microprocessor.

[0145] The memory 510 can be used to store instructions executed by the processor 520 or data related to the execution of instructions. These instructions and / or data may include code for implementing some or all of the functions of one or more modules described in the embodiments of this application. The processor 520 of this disclosure embodiment can be used to execute the instructions in the memory 510 to implement the methods shown above. The memory 510 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.

[0146] Some embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, describes the method described in the method embodiments.

[0147] Some embodiments of this application also provide a computer program product that, when run on a computer, causes the computer to perform the methods described in the method embodiments.

[0148] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0149] It should be understood, in the several embodiments provided in this application, that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0150] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0151] If the aforementioned functions are implemented as software functional 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 this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0152] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

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

[0154] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for signing a digital contract, characterized in that, The method includes: The system receives a commitment message sent by the signing device, wherein the commitment message is determined by the signing device based on the digital contract text, the contract unique identifier, the signing public key, the trusted public key, the number of signing parties, the signing restriction time, and the hash value of the first commitment random number, which is obtained by hashing the commitment random number. If the commitment message passes the signature verification, the commitment message from the signatory device and the single signature data from the trusted third-party device are aggregated to generate an aggregated signature; The aggregated signature is sent to the signing device so that the signing device can verify the aggregated signature; If the signing device passes the verification of the aggregated signature, a contract request is received from the signing device, wherein the contract request includes the promised random number and the promised random number signature information corresponding to the promised random number; Based on the promised random number, the signature information of the promised random number, the hash value of the first promised random number, and the public key of the signer, determine whether the contract request is effective; If the contract request takes effect, the signatory device sends a commitment random number from all signatory devices and trusted third-party devices, along with signature information obtained by signing the commitment random number, to the signatory device. This enables the signatory device to verify the signature using the public key of the trusted third-party device, and confirms the official effectiveness of the digital contract by calculating and comparing the hash value of the commitment random number.

2. The digital contract signing method according to claim 1, characterized in that, The step of determining whether the contract request is effective based on the promised random number, the signature information of the promised random number, the hash value of the first promised random number, and the public key of the signer includes: The aggregated signature is sent to the signing device so that the signing device verifies the aggregated signature and obtains a first verification result. The first verification result is used to determine whether the trusted third-party device has received the commitment messages from all signing devices within the signing restriction time. If the first verification result is successful, a contract request sent by the signing device is received, the contract request including the commitment random number and the commitment random number signature information corresponding to the commitment random number; The signature information of the promised random number is verified to obtain a second verification result, which is used to determine the authenticity and integrity of the promised random number. If the second verification result is successful, the validity of the contract request is determined based on the promised random number and the hash value of the first promised random number.

3. The digital contract signing method according to claim 2, characterized in that, If the second signature verification result is successful, determining whether the contract request is effective based on the promised random number and the hash value of the first promised random number includes: Perform a hash operation on the promised random number to obtain the hash value of the second promised random number; The hash values ​​of the first and second commitment random numbers are compared. If the hash value of the first commitment random number matches the hash value of the second commitment random number, the contract request is deemed to be effective.

4. The digital contract signing method according to claim 1, characterized in that, The commitment message is obtained in the following manner: The signing device determines the digital contract data based on the digital contract text, the unique contract identifier, the signer's public key, the trusted public key, the number of signers, and the signing restriction time. The signing device randomly generates a base random number and a commitment random number, the commitment random number being used to initiate the contract; The signing device uses its private key to sign the digital contract data and the hash value of the commitment random number to obtain the commitment message.

5. The digital contract signing method according to claim 4, characterized in that, The signing device uses its private key to sign the digital contract data and the hash value of the commitment random number, obtaining the commitment message, including: The parameters of the first contract are determined based on the signatory's identity information and the relevant parameters of the elliptic curve. Perform a hash operation on the promised random number to obtain the first hash parameter; The first contract data is determined based on the first hash parameter, the first contract parameter, and the digital contract data; Perform a hash operation on the first contract data to obtain the second hash parameter; The first verification data is determined based on the second hash parameter and the first point on the finite elliptic domain; The first processing result is determined based on the signer's private key, the first verification data, and the basic random number; The commitment message is determined based on the first verification data, the first processing result, the points on the finite elliptic domain, and the first hash parameter.

6. The digital contract signing method according to claim 5, characterized in that, The commitment message is verified through signature verification in the following manner: The parameters of the second contract are determined based on the signatory's identity information and the relevant parameters of the elliptic curve. The second contract data is determined based on the first hash parameter, the second contract parameter, and the digital contract data; Perform a hash operation on the second contract data to obtain the third hash parameter; The second processing result is determined based on the first verification data and the first processing result; Based on the first processing result, the second processing result, and the signatory's public key, determine the second point information on the finite elliptic domain; The second verification data is determined based on the third hash parameter and the second point information on the finite elliptic domain; If the first verification data and the second verification data are the same, the commitment message is determined to have passed the signature verification.

7. The digital contract signing method according to claim 6, characterized in that, If the commitment message passes signature verification, the process of aggregating the commitment message from the signing device and the single signature data from the trusted third-party device to generate an aggregated signature includes: The second hash parameter in the commitment message of the signing device and the trusted hash parameter in the single signature data are concatenated to obtain concatenated data. The single signature data is obtained by signing the digital contract data with the private key of the trusted third-party device, and the single signature data contains a trusted hash parameter, which is an intermediate hash value generated by the trusted third party during the signing process of the digital contract data. Perform a hash operation on the concatenated data to obtain the fourth hash data; Determine the information of the third point in the finite elliptical domain based on the points in the finite elliptical domain; Based on the fourth hash data and the third point information, the third verification data is determined; Based on the first processing result, determine the fourth verification data; The time limit data is determined based on the first processing result, the first verification data, and the first hash parameter; The aggregated signature is determined based on the third verification data, the fourth verification data, and the time limit data.

8. The digital contract signing method according to claim 7, characterized in that, The signing device verifies the aggregated signature to obtain a first verification result, including: The parameters of the third contract are determined based on the signatory's identity information and the relevant parameters of the elliptic curve. The third contract data is determined based on the first hash parameter, the third contract parameter, and the digital contract data; Perform a hash operation on the third contract data to obtain the fifth hash parameter; The fifth hash parameter is concatenated to obtain concatenated data, and a hash operation is performed on the concatenated data to obtain the sixth hash parameter; Based on the fourth verification data, the second processing result, and the signer's public key, the fourth point information on the finite elliptic domain is determined. The fifth verification data is determined based on the information of the fourth point on the finite elliptic domain and the sixth hash parameter; If the third verification data and the fifth verification data are the same, it is determined that the signer has passed the verification of the aggregated signature.

9. The digital contract signing method according to claim 1, characterized in that, The method further includes: If a trusted third-party device does not receive commitment messages from all signing party devices within a first preset time period, it receives a contract termination request sent by the signing party devices, wherein the contract termination request includes a termination identifier and a commitment message from the signing party; based on the contract termination request, it determines a first token information type corresponding to the termination identifier, wherein the first token information type includes a first termination token or a first resolution token, the first termination token is used to revoke the digital contract, the first resolution token is used to determine that the digital contract has taken effect and is irrevocable, and the first preset time period is within the signing restriction time; Based on the first token information type, determine the execution operation corresponding to the contract termination request.

10. The digital contract signing method according to claim 1, characterized in that, The method further includes: If the signing device does not receive a digital contract sent by a trusted third-party device within a second preset time period, the signing device receives a contract resolution request sent by the signing device, wherein the contract resolution request includes an aggregate signature, and the second preset time period is within the signing restriction time. Based on the contract resolution request, a corresponding second token information type is determined, wherein the second token information type includes a second termination token or a second resolution token; the second termination token is used to determine that the digital contract has been revoked, and the second resolution token is used to force the digital contract to take effect; Based on the second token information type, determine the execution operation corresponding to the contract resolution request.

11. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the program, it can implement the signing method of the digital contract as described in any one of claims 1-10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, characterized in that, when the program is executed by a processor, it can implement the digital contract signing method according to any one of claims 1-10.

13. A computer program product, said computer program product comprising a computer program, wherein, When the computer program is executed by a processor, it can implement the digital contract signing method according to any one of claims 1-10.

Images