A method and system for electronic contract signing based on delivery of anti-repudiation

Abstract

The present disclosure provides a delivery anti-repudiation electronic contract signing method and system based on delivery anti-repudiation. A trusted center generates an electronic contract signature by symmetric key encryption according to the request of each signing party and sends the signature to each signing party. After each signing party verifies the correctness of the electronic contract signature, the trusted center requests delivery anti-repudiation signature. After verifying the identity of each signing party, the trusted center performs delivery anti-repudiation signature on each signing party. Each signing party sends the received delivery anti-repudiation signature to the other party, and each signing party sends the delivery anti-repudiation signature of the other party to the trusted center for verification. After verification, each signing party sends confirmation information to the trusted center, and the electronic contract signing is completed. The security of the traditional electronic contract signing method based on PKI is fundamentally eliminated.

Description

Technical Field

[0001] This disclosure pertains to the field of encrypted communication in quantum cryptography networks, specifically relating to a delivery-based non-repudiation electronic contract signing method and system. Background Technology

[0002] The statements in this section are merely background information relating to this disclosure and do not necessarily constitute prior art.

[0003] Electronic contracts, also known as e-commerce contracts, emerged with the development of computer technology and automated office technology. Essentially, they transmit information via electronic pulses, thus changing the traditional practice of using paper as the primary document; the document itself is a set of electronic information. Generally, an electronic contract can be defined as an agreement between two or more parties, reached electronically through an electronic information network, establishing, modifying, or terminating property-related civil rights and obligations. In short, an electronic contract is a contract concluded electronically, primarily referring to an agreement reached by the parties under network conditions.

[0004] Current electronic contracts are mostly implemented based on PKI technology. The RSA asymmetric key encryption algorithm is computationally secure. However, with the foreseeable research and construction of quantum computers, classical public-key cryptography systems based on computational complexity face security risks. Therefore, current electronic contract signing methods based on asymmetric key technology have security vulnerabilities. At the same time, existing methods for signing non-repudiated electronic contracts require more data interaction verification, which increases the security risks during data transmission. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this disclosure provides a delivery-based non-repudiation electronic contract signing method and system, which fundamentally eliminates the security deficiencies of traditional PKI-based electronic contract signing methods that rely on computational security.

[0006] According to some embodiments, the present disclosure adopts the following technical solutions:

[0007] The primary objective of this disclosure is to provide a delivery-based non-repudiation method for signing electronic contracts.

[0008] A method for signing electronic contracts based on delivery non-repudiation includes the following steps:

[0009] The Trusted Center distributes the shared key to all signatories through a quantum cryptography network;

[0010] Based on the requests generated by each signatory using the shared key, the Trusted Center verifies the identity of each signatory using the shared key, generates an electronic contract signature, and sends it to each signatory.

[0011] Each signatory uses a shared key to verify the correctness of the electronic contract signature with the Trusted Center and requests the Trusted Center to deliver a non-repudiation signature;

[0012] After verifying the identity of each signer using the shared key, the Trust Center delivers a non-repudiation signature to each signer and sends it to each signer.

[0013] Each signatory shall send the delivery non-repudiation signature received to the other party, and each signatory shall send the other party's delivery non-repudiation signature to the Trust Center for verification.

[0014] After successful verification, each signatory sends a confirmation message to the Trusted Center, and the electronic contract is signed.

[0015] As an optional implementation, there is a first signatory and a second signatory. The first signatory generates a signature request based on the first shared key, and the second signatory generates a signature request based on the second shared key. The trusted center verifies the identity of the first signatory and the second signatory based on the first shared key and the second shared key, respectively. After successful verification, an electronic contract signature is generated and sent to each signatory.

[0016] As an optional implementation, there is a first signer and a second signer. The first signer applies to the Trusted Center for a non-repudiation signature based on a third shared key, and the second signer applies to the Trusted Center for a non-repudiation signature based on a fourth shared key. The Trusted Center verifies the identity of the first signer and the second signer based on the third shared key and the fourth shared key, respectively. After verification, it generates a delivery non-repudiation signature and sends it to each signer.

[0017] As an optional implementation, the Trusted Center stores the identity registration information and shared key of each signatory in the database. Each signatory securely stores the shared key and, together with the shared key in the Trusted Center's database, divides the shared key according to the length of the shared key used each time and synchronizes the sequential numbering.

[0018] As an optional implementation, each shared password is marked as used after it has been used.

[0019] As an optional implementation, the request generated by each signatory using the shared key includes the signatory's identification code, the trusted center's identification code, the contract's hash value, the shared key's serial number, and the key-related message authentication code for each relevant data.

[0020] As an optional implementation, each signatory's request to the Trusted Center for delivery of a non-repudiation signature includes the signatory's own identification code, the electronic contract signature, the serial number of the shared key, and the message authentication code associated with the key of each relevant data.

[0021] As an optional implementation, within a set time period, each signatory receives the delivery non-repudiation signature sent by the other party and verifies the correctness of the delivery non-repudiation signature at a trusted center.

[0022] As an optional implementation, after all the delivery non-repudiation signatures received by each signatory have been verified, each signatory shall retain the other party's delivery non-repudiation signature and electronic contract signature.

[0023] As an optional implementation, the signatory who has not received a delivery non-repudiation signature or whose received delivery non-repudiation signature is incorrect shall send its correct delivery non-repudiation signature to the Trusted Center and apply to the Trusted Center to cancel the signature of the electronic contract.

[0024] As a further limitation, after receiving a request to cancel the signature of an electronic contract, the Trust Center verifies the correctness of the delivery non-repudiation signature of each signatory. If it is incorrect, the cancellation request is rejected; otherwise, the center sends the delivery non-repudiation signature of the signatory requesting cancellation of the electronic contract to the other party and informs the other party that the electronic contract signature will be cancelled after a set time.

[0025] After receiving the notification from the Trusted Center that the electronic contract signatory has applied to cancel the delivery non-repudiation signature and that the electronic contract signature will be canceled after a set time, the other party verifies the correctness of the delivery non-repudiation signature of the electronic contract signatory applying to cancel the electronic contract. If correct, the other party sends its own delivery non-repudiation signature to the electronic contract signatory applying to cancel the electronic contract.

[0026] When the party requesting cancellation of the electronic contract receives the non-repudiation signature from the other party, it verifies the correctness of the signature. If correct, it sends a notification message to the Trusted Center that it has received the other party's non-repudiation signature, and the electronic contract signing is completed.

[0027] If the Trust Center does not receive a notification from the party requesting cancellation of the electronic contract that it has received the other party's non-repudiation signature within the set time, the electronic contract signing will fail.

[0028] A second objective of this disclosure is to provide an electronic contract signing system based on delivery non-repudiation.

[0029] An electronic contract signing system based on delivery non-repudiation includes:

[0030] The electronic contract signing server is configured as a trusted third party in the electronic contract signing process. It performs symmetric key signing on the electronic contract to obtain a digital signature, distributes a shared key to each client signer through a quantum cryptography network, divides the keys in the true random number digital signature key library according to the length used for each digital signature, and verifies the electronic contract signature.

[0031] Several clients are configured to provide information services to each signatory during the contract signing process and to communicate with other clients and the electronic contract signing server.

[0032] As an alternative implementation, the electronic contract signing server distributes a shared key to the certified signer of each client, saves the signer's identity registration information and the shared key, and the client saves the shared key and, together with the shared key in the electronic contract signing server's database, divides the shared key according to the length of the shared key used each time and synchronizes the sequential numbering.

[0033] As an alternative implementation, each client uses a key with a different number for each communication with the electronic contract signing server.

[0034] As an alternative implementation, each client and the electronic contract signing server obtain a shared key through quantum key distribution. When the number of shared keys is lower than a set value, the signer of each client uses the unused shared key to perform mutual identity authentication with the contract signing server.

[0035] After successful identity authentication, the contract signing server distributes quantum keys to the signatories of each client through the quantum secure channel of the quantum cryptography network. The contract signing server and each client encrypt the newly distributed quantum key using the unused key, use the ciphertext as the new shared key, and divide and number the new shared key sequentially.

[0036] Compared with the prior art, the beneficial effects of this disclosure are:

[0037] 1. This disclosure proposes an electronic contract signing method and system based on symmetric key signature. It adopts a symmetric cryptographic algorithm and has the characteristics of resisting quantum attacks. It fundamentally eliminates the security defects of traditional PKI-based electronic contract signing methods that rely on computational security, and effectively avoids the data interaction verification risk in the signing process of delivering non-repudiated electronic contracts.

[0038] 2. The method provided in this disclosure is based on quantum cryptography network and uses a labeling method to prevent reuse of the used key, thus realizing the one-time pad encryption method with unconditional security.

[0039] 3. The electronic contract signing method provided in this disclosure strictly follows the Fair Exchange Protocol, ensuring the fairness of electronic contract signing.

[0040] Advantages of this disclosure in some respects will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of this disclosure.

[0041] Advantages of this disclosure in some respects will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of this disclosure. Attached Figure Description

[0042] The accompanying drawings, which form part of this disclosure, are used to provide a further understanding of this disclosure. The illustrative embodiments of this disclosure and their descriptions are used to explain this disclosure and do not constitute an undue limitation of this disclosure.

[0043] Figure 1 This is a diagram showing the relationship between the signatories and the Trust Center in this first embodiment.

[0044] Figure 2 This is a flowchart of the electronic contract signing method in this embodiment one;

[0045] Figure 3 This is a flowchart of the arbitration method in Embodiment 1.

[0046] Figure 4 This is a system structure diagram of Embodiment 2. Detailed Implementation

[0047] The present disclosure will be further described below with reference to the accompanying drawings and embodiments.

[0048] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of this disclosure. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0049] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this disclosure. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms “comprising” and / or “including” are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0050] Where there is no conflict, the embodiments and features described herein can be combined with each other.

[0051] Example 1:

[0052] This embodiment relies on the abundant symmetric key resources of quantum cryptography networks to implement an electronic contract signing method based on symmetric keys. Symmetric key algorithms are cryptographic algorithms that use the same secret key for both encryption and decryption. This cryptosystem is characterized by low mathematical computation, fast encryption speed, and ease of processing; however, distributing the symmetric key is relatively difficult. The emergence of quantum cryptography networks has solved the problem of symmetric key distribution. Through quantum cryptography networks, both parties can easily obtain a shared symmetric key using quantum key distribution.

[0053] Appendix Figure 1 This is a diagram showing the relationship between the signatory and the trusted center in this embodiment. The functions of each component are described in detail below:

[0054] The Trusted Center, a trusted third-party organization, is responsible for digital signatures of electronic contracts, registration of signatories' identities, authentication of signatories during electronic contract signing, and the server used for electronic contract signing. A true random number digital signature keystore is established within the Trusted Center for digital signatures of electronic contract data. The keys in the keystore are divided according to the length used for each digital signature, and the divided keys are sequentially numbered.

[0055] The signatories of an electronic contract are the two parties preparing to sign the contract through a trusted center. Before signing the electronic contract, each signatory submits an identity registration application to the trusted center via a quantum cryptography network terminal using a quantum secure channel. The quantum secure channel is an encrypted channel with a shared quantum key. The shared quantum key is used to encrypt the identity registration information on the network terminal, and then decrypted at the trusted center using the same shared quantum key to obtain secure transmission of the identity registration information. After accepting the signatory's identity registration application, the trusted center reviews the submitted materials. If the review is successful, the trusted center distributes a shared key to the signatory through the quantum cryptography network's quantum secure channel. The trusted center stores the signatory's identity registration information and the shared key in its database. The signatory securely stores the shared key and, together with the shared key in the trusted center's database, divides the shared key according to the length of each use and synchronizes the sequential numbering.

[0056] This embodiment is based on a two-party electronic contract signing method. It is assumed that the two parties participating in the electronic contract signing are A and B (A and B represent the identity identification codes of the contract signatories, and A and B have completed identity registration in the trusted center in advance). The contract to be signed by A and B is C (A and B have agreed on the content of C in advance).

[0057] Appendix Figure 2 The implementation process of electronic contract signing based on delivery non-repudiation provided in this embodiment is described in detail below:

[0058] S1: A and B respectively send a signature request for electronic contract C to the Trusted Center;

[0059] A uses the shared key K1, which is not used by the Trusted Center, to calculate the message authentication code HMAC (A||B||TP||H(C)||N1; K1) related to the key of the relevant data (TP is the identification code of the Trusted Center, H(C) represents the hash value of contract C, N1 is the sequence number of key K1, and || represents the data concatenation operation). A sends an electronic contract signing request to the Trusted Center and sends A, B, TP, N1, H(C) and HMAC (A||B||TP||H(C)||N1; K1) to the Trusted Center, marking K1 as used.

[0060] B uses the shared key K2, which is not used by the Trusted Center, to calculate the message authentication code HMAC(A||B||TP||H(C)||N2; K2) related to the key of the relevant data (TP is the identification code of the Trusted Center, H(C) represents the hash value of contract C, N2 is the sequence number of key K2, and || represents the data concatenation operation). B sends an electronic contract signing request to the Trusted Center and sends A, B, TP, N2, H(C) and HMAC(A||B||TP||H(C)||N2; K2) to the Trusted Center, marking K2 as used.

[0061] S2: The Trusted Center receives the signature requests from A and B, verifies the identities of A and B, and accepts the signature requests if they are correct.

[0062] After receiving the signature request and data A, B, TP, N1, H(C) and HMAC(A||B||TP||H(C)||N1; K1) from A, the Trusted Center reads the shared key K1 with A, with sequence number N1, from the database. If K1 has been used, A's signature request is rejected; otherwise, the correctness of HMAC(A||B||TP||H(C)||N1; K1) is verified. If correct, A's identity authentication is successful, the signature request is accepted, and K1 is marked as used.

[0063] After receiving the signature request and data A, B, TP, N1, H(C) and HMAC(A||B||TP||H(C)||N2; K2) from B, the Trusted Center reads the shared key K2 with B, with sequence number N2, from the database. If K2 has already been used, A's signature request is rejected, and the correctness of HMAC(A||B||TP||H(C)||N2; K2) is verified. If it is correct, B's identity authentication is successful, the signature request is accepted, and K2 is marked as used.

[0064] S3: The Trusted Center accepts the signature requests from A and B, electronically signs the electronic contract C, and sends the signature to A and B;

[0065] After receiving the signature requests from A and B, the Trusted Center confirms that they are for the same contract C. It then retrieves the unused key K (serial number N) from the signature key repository and performs a symmetric key signature on contract C, obtaining the signature data: HMAC(A||B||TP||TS||H(C)||N;K), where TS is the timestamp of the signature and N is the serial number of the signature key K. DS = A||B||TP||TS||H(C)||N||HMAC(A||B||TP||TS||H(C)||N;K) is used as the electronic signature of electronic contract C, and key K is marked as used. The Trusted Center then sends DS to A and B respectively.

[0066] S4: After A and B receive the signature of electronic contract C from the Trusted Center and verify the correctness of the signature, they request the Trusted Center to deliver a non-repudiation signature.

[0067] After receiving DS, A verifies the correctness of DS at the Trusted Center. Using the unused key K3 shared with the Trusted Center, A calculates the message authentication code HMAC (A||TP||DS||N3; K3) related to the key of the relevant data (TP is the identification code of the Trusted Center, and N3 is the sequence number of key K3). A sends the data A, DS, N3 and HMAC (A||TP||DS||N3; K3) to the Trusted Center, requests the Trusted Center to deliver a non-repudiation signature, and marks K3 as used.

[0068] After receiving DS, B verifies the correctness of DS at the Trusted Center. Using the unused key K4 shared with the Trusted Center, B calculates the message authentication code HMAC (B||TP||DS||N4; K4) related to the key of the relevant data (TP is the identification code of the Trusted Center, and N4 is the sequence number of key K4). B sends data B, DS, A4 and HMAC (A||TP||DS||N4; K4) to the Trusted Center, requests the Trusted Center to deliver a non-repudiation signature, and marks K4 as used.

[0069] S5: The Trusted Center receives delivery non-repudiation signature requests from A and B, verifies the identities of A and B, and performs delivery non-repudiation signatures on A and B respectively;

[0070] The Trusted Center receives A's signature request along with data A, DS, N3, and HMAC (A||TP||DS||N3; K3). It then reads the shared key K3 (with sequence number N3) from the database. If K3 is already in use, A's delivery non-repudiation signature request is rejected. Otherwise, the correctness of HMAC (A||TP||DS||N3; K3) is verified. If correct, A's identity is authenticated, A's delivery non-repudiation signature request is accepted, K3 is marked as used, and the key with sequence number N3 is read from the signature database. 1 Unused signing key K1 Calculate the message authentication code HMAC (N) associated with the key of data A||DS||f (where f is the delivery non-repudiation signature identifier). 1 ||A||DS||f;K 1 ), set fADS=N 1 ||TS||A||DS||HMAC(N 1 ||TS||A||DS||f;K 1 As a non-repudiation signature of A, which is the signature data DS, the trusted center sends fADS to A, and K... 1 Marked as used;

[0071] The Trusted Center receives B's signature request along with data B, DS, N4, and HMAC (B||TP||DS||N4; K4). It then reads the shared key K4 (with sequence number N4) from the database. If K4 is already in use, B's delivery non-repudiation signature request is rejected. Otherwise, the correctness of HMAC (B||TP||DS||N4; K4) is verified. If correct, B's identity is authenticated, the delivery non-repudiation signature request is accepted, K4 is marked as used, and the key with sequence number N4 is read from the signature database. 2 Signature key K 2 The message authentication code HMAC (N) associated with the key of the data B||DS||f (where f is the delivery non-repudiation signature identifier) ​​is calculated. 2 ||TS||B||DS||f;K 2 ), set fBDS=N 2 ||TS||B||DS||HMAC(N 2 ||TS||B||DS||f;K 2 As the delivery non-repudiation signature of B for the signature data DS, the trusted center sends fBDS to B, and K... 2 Marked as used;

[0072] S6: After A and B receive the delivery non-repudiation signature from the trusted center, they send it to the other party;

[0073] After receiving fADS, A verifies its correctness at the Trusted Center. If correct, A sends fADS to B. After receiving fBDS, B verifies its correctness at the Trusted Center. If correct, B sends fBDS to A. Within the set time, both A and B receive the delivery non-repudiation signatures fBDS and fADS sent by the other party. They then verify the correctness of the signatures at the Trusted Center. If both are correct, A and B save the other party's delivery non-repudiation signature and signature DS, and send a notification message to the Trusted Center that they have received the other party's delivery non-repudiation signature. The signing process of electronic contract C ends.

[0074] S7: If A or B does not receive the delivery non-repudiation signature sent by the other party, they shall apply for arbitration with the Trusted Center;

[0075] Appendix Figure 3 The arbitration sub-process is detailed below:

[0076] S7.1: If A or B does not receive the other party's delivery non-repudiation signature within the set time, or if the received delivery non-repudiation signature is incorrect, A or B shall send its correct delivery non-repudiation signature to the Trusted Center and apply to the Trusted Center to cancel the signature of the electronic contract C.

[0077] S7.2: After receiving a request from A or B to cancel the signature of electronic contract C, the Trust Center first verifies the correctness of A or B's own delivery non-repudiation signature. If it is incorrect, the cancellation request is rejected. Otherwise, A or B's delivery non-repudiation signature is sent to the other party, and the other party is informed that the electronic contract signature will be cancelled after a set time.

[0078] S7.3: After receiving a notification from the Trusted Center that the other party has delivered a non-repudiation signature and that the electronic contract signature will be cancelled after a set time, A or B verifies the correctness of the other party's non-repudiation signature. If correct, A sends its own non-repudiation signature to the other party.

[0079] S7.4: When A or B receives the other party's delivery non-repudiation signature, it verifies the correctness of the signature. If correct, it saves the other party's delivery non-repudiation signature and signature DS, and sends a notification message to the Trusted Center that it has received the other party's non-repudiation signature. The signing process of electronic contract C ends.

[0080] S7.5: If the Trusted Center does not receive a notification message from A or B confirming receipt of the non-repudiation signature within the set time, it will select the key with sequence number N from the signature key repository. 3 Unused signing key K 3 The calculation data is "cancelled" || DS key-related message authentication code HMAC (N 3 ||TS||“cancelled”||DS;K 3 Obtain signature Cancel signature CDS=N 3 ||TS||“cancelled”||DS||HMAC(N 3 ||TS||

[0081] “cancelled” || DS; K 3 The trusted center sends the CDS to A and B, and saves the CDS, along with the key K. 3 The CDS is marked as used. A and B receive and save the CDS, but the signing of electronic contract C fails.

[0082] After the contract is successfully signed, both parties shall retain their contract signatures and the other party's delivery non-repudiation signature as proof that the contract has been signed.

[0083] The Trusted Center and the electronic contract signatory obtain a shared key through quantum key distribution. When their shared key is about to run out (when the number of keys is lower than a set value), the electronic contract signatory uses the unused shared key to authenticate each other with the Trusted Center. After successful authentication, the Trusted Center distributes a quantum key to the electronic contract signatory through the quantum secure channel of the quantum cryptography network. The Trusted Center and the electronic contract signatory use the unused key to encrypt the newly distributed quantum key, use the ciphertext as the new shared key, and divide and number the new shared key sequentially.

[0084] A fair exchange protocol is a fundamental security protocol that must be followed in the electronic contract signing process. It primarily ensures the security and fairness of information exchange and related matters in a network environment. A fair exchange protocol ensures that the parties involved exchange information in a equitable manner, so that either either party receives the other's information, or neither party receives the other's information. In other words, if the transaction proceeds normally, the protocol guarantees that both parties receive the information they need; if the protocol terminates abnormally, it should ensure that both parties are on equal footing, with neither party having any advantage.

[0085] This embodiment of the electronic contract signing process strictly follows the fair exchange protocol. Due to the special nature of symmetric key signatures, both parties to the contract can generate the same digital signature with the help of a trusted center (the signature files of A and B are identical). We use whether the signatory receives the digital signature sent by the trusted center as the standard to determine whether the signatory has participated in the contract signing. That is, the signatory's delivery non-repudiation signature is used as proof that the contract has been signed. Either both parties to the contract have obtained the other party's delivery non-repudiation signature (the contract is successfully signed), or the contract signing fails (the contract is generated and the signature is canceled).

[0086] During the signing process, if a non-repudiation signature is received from the other party, the signing party needs to notify the Trusted Center. If the Trusted Center does not receive notification from either party (or both parties) of receiving the non-repudiation signature within a set time, it will generate a cancellation signature to terminate the electronic contract signing process. The electronic contract signing process in this embodiment follows a fair exchange protocol. Throughout the signing process, the signing parties maintain a fair position.

[0087] Example 2:

[0088] In this embodiment, an electronic contract signing system based on delivery non-repudiation is provided, such as... Figure 4 As shown, it includes:

[0089] The electronic contract signing server is configured as a trusted third party in the electronic contract signing process. It performs symmetric key signing on the electronic contract to obtain a digital signature, distributes a shared key to each client signer through a quantum cryptography network, divides the keys in the true random number digital signature key library according to the length used for each digital signature, and verifies the electronic contract signature.

[0090] Several clients are configured to provide information services to each signatory during the contract signing process and to communicate with other clients and the electronic contract signing server.

[0091] The electronic contract signing server distributes shared keys to the certified signer on each client, saves the signer's identity registration information and the shared key, and the client saves the shared key and, together with the shared key in the electronic contract signing server's database, divides the shared key according to the length of the shared key used each time and synchronizes the sequential numbering.

[0092] Each client uses a key with a different number for each communication with the electronic contract signing server;

[0093] Each client obtains a shared key from the electronic contract signing server through quantum key distribution. When the number of shared keys is lower than a set value, the signer of each client uses the unused shared key to perform mutual identity authentication with the contract signing server.

[0094] After successful identity authentication, the contract signing server distributes quantum keys to the signatories of each client through the quantum secure channel of the quantum cryptography network. The contract signing server and each client encrypt the newly distributed quantum keys using the unused key, use the ciphertext as the new shared key, and divide and number the new shared key sequentially.

[0095] The working method of the above system is the same as that of the electronic contract signing based on delivery non-repudiation provided in Example 1, and will not be repeated here.

[0096] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0097] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0098] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0099] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0100] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0101] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for signing electronic contracts based on delivery non-repudiation, characterized by: Includes the following steps: The Trusted Center distributes the shared key to all signatories through a quantum cryptography network; Based on the requests generated by each signatory using the shared key, the Trusted Center verifies the identity of each signatory using the shared key, generates an electronic contract signature, and sends it to each signatory. The step of verifying the identity of each signer through a shared key involves confirming the identity of the signer by verifying the Message Authentication Code (HMAC) corresponding to the shared key. Each signatory uses a shared key to verify the correctness of the electronic contract signature with the Trusted Center and requests the Trusted Center to deliver a non-repudiation signature; After verifying the identity of each signer using the shared key, the Trust Center delivers a non-repudiation signature to each signer and sends it to each signer. Among them, the Trusted Center uses unused keys in the True Random Number Digital Signature Key Library to perform HMAC calculations on electronic contract signatures and delivery identifiers, generating a delivery non-repudiation signature containing a timestamp, key serial number, and identity identifier. Each signatory shall send the delivery non-repudiation signature received to the other party, and each signatory shall send the other party's delivery non-repudiation signature to the Trust Center for verification. After successful verification, each signatory sends a confirmation message to the Trusted Center, and the electronic contract is signed.

2. The electronic contract signing method based on delivery non-repudiation as described in claim 1, characterized in that: There is a first signatory and a second signatory. The first signatory generates a signature request based on the first shared key, and the second signatory generates a signature request based on the second shared key. The trusted center verifies the identity of the first signatory and the second signatory based on the first shared key and the second shared key, respectively. After verification, an electronic contract signature is generated and sent to each signatory. Alternatively, there may be a first signer and a second signer. The first signer applies to the Trusted Center for a non-repudiation signature based on a third shared key, and the second signer applies to the Trusted Center for a non-repudiation signature based on a fourth shared key. The Trusted Center verifies the identity of the first and second signers based on the third and fourth shared keys, respectively. After verification, it generates a delivery non-repudiation signature and sends it to each signer.

3. The electronic contract signing method based on delivery non-repudiation as described in claim 1, characterized in that: The Trusted Center stores the identity registration information and shared keys of each signatory in the database. Each signatory securely stores the shared key and, together with the shared key in the Trusted Center's database, divides the shared key according to the length of the shared key used each time and synchronizes the sequential numbering. Alternatively, each shared password can be marked as used after it has been used.

4. The electronic contract signing method based on delivery non-repudiation as described in claim 1, characterized in that: The request generated by each signatory using the shared key includes each signatory's identification code, the trusted center's identification code, the contract's hash value, the shared key's serial number, and the key-related message authentication code for each relevant data. Alternatively, each signatory may request the Trusted Center to deliver a non-repudiation signature, which may include the signatory's own identification code, the electronic contract signature, the serial number of the shared key, and the message authentication code associated with the key of each relevant data.

5. The electronic contract signing method based on delivery non-repudiation as described in claim 1, characterized in that: Within the set time, each signatory received the delivery non-repudiation signature sent by the other party and verified the correctness of the delivery non-repudiation signature at the trusted center. Alternatively, after all signatories have received and verified the delivery non-repudiation signatures, each signatory shall retain the other party's delivery non-repudiation signature and electronic contract signature.

6. The electronic contract signing method based on delivery non-repudiation as described in claim 1, characterized in that: If a signatory does not receive a delivery non-repudiation signature or receives an incorrect delivery non-repudiation signature, it shall send its correct delivery non-repudiation signature to the Trust Center and apply to the Trust Center to cancel the signature of the electronic contract.

7. The electronic contract signing method based on delivery non-repudiation as described in claim 6, characterized in that: After receiving a request to cancel the signature of an electronic contract, the Trust Center verifies the correctness of the delivery non-repudiation signature of each signatory. If it is incorrect, the cancellation request is rejected; otherwise, the center sends the delivery non-repudiation signature of the signatory requesting cancellation of the electronic contract to the other party and informs the other party that the electronic contract signature will be cancelled after a set time. After receiving the notification from the Trusted Center that the electronic contract signatory has applied to cancel the delivery non-repudiation signature and that the electronic contract signature will be canceled after a set time, the other party verifies the correctness of the delivery non-repudiation signature of the electronic contract signatory applying to cancel the electronic contract. If correct, the other party sends its own delivery non-repudiation signature to the electronic contract signatory applying to cancel the electronic contract. When the party requesting cancellation of the electronic contract receives the non-repudiation signature from the other party, it verifies the correctness of the signature. If correct, it sends a notification message to the Trusted Center that it has received the other party's non-repudiation signature, and the electronic contract signing is completed. If the Trust Center does not receive a notification from the party requesting cancellation of the electronic contract that it has received the other party's non-repudiation signature within the set time, the electronic contract signing will fail.

8. An electronic contract signing system based on delivery non-repudiation, employing the electronic contract signing method based on delivery non-repudiation as described in claim 1, characterized in that: include: The electronic contract signing server is configured as a trusted third party in the electronic contract signing process. It performs symmetric key signing on the electronic contract to obtain a digital signature, distributes a shared key to each client signer through a quantum cryptography network, divides the keys in the true random number digital signature key library according to the length used for each digital signature, and verifies the electronic contract signature. Several clients are configured to provide information services to each signatory during the contract signing process and to communicate with other clients and the electronic contract signing server.

9. The electronic contract signing system based on delivery non-repudiation as described in claim 8, characterized in that: The electronic contract signing server distributes shared keys to the certified signer on each client, saves the signer's identity registration information and the shared key, and the client saves the shared key and, together with the shared key in the electronic contract signing server's database, divides the shared key according to the length of the shared key used each time and synchronizes the sequential numbering.

10. The electronic contract signing system based on delivery non-repudiation as described in claim 8, characterized in that: Each client uses a key with a different number for each communication with the electronic contract signing server; Alternatively, each client and the electronic contract signing server can obtain a shared key through quantum key distribution. When the number of shared keys is lower than a set value, the signer of each client uses the unused shared key to perform mutual identity authentication with the contract signing server. After successful identity authentication, the contract signing server distributes quantum keys to the signatories of each client through the quantum secure channel of the quantum cryptography network. The contract signing server and each client encrypt the newly distributed quantum keys using the unused key, use the ciphertext as the new shared key, and divide and number the new shared key sequentially.

Images