A collaborative signature method

Abstract

This invention relates to the field of digital signature technology, specifically to a collaborative signature method. In this application, when generating a key, the key is directly saved to the server and a corresponding key ID is generated. When a user performs collaborative signature, the certificate status corresponding to the key ID is first checked, and then the key ID with a normal certificate status is displayed to the user. The user only needs to select the key ID to use and authorize it, without the need for the user to save the key themselves, thus solving the problem that the key on the user's mobile device is easily lost during collaborative signature.

Description

Technical Field

[0001] This invention relates to the field of digital signature technology, and more specifically to a collaborative signature method. Background Technology

[0002] The collaborative signature server is a secure private key escrow collaborative signature system designed based on the domestic cryptographic algorithms SM2, SM3, and SM4, providing a secure and compliant end-user authentication solution for user operation terminals.

[0003] Currently, when mobile phones and servers collaborate on signing, the mobile phone calculates a portion of the intermediate signature result, while the server calculates and synthesizes the actual signature result. However, the keys stored on the mobile phone for existing collaborative signing are usually saved as files and protected by passwords, which are easily lost or corrupted (e.g., when the app is uninstalled). Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a collaborative signature method to overcome the problem that the client's mobile key is easily lost in current collaborative signature methods.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] A collaborative signature method, comprising:

[0007] The client logs into the first server using the user information entered by the user;

[0008] The first server generates a first server public key using a pre-generated first server private key;

[0009] The second server generates a second server public key using a pre-generated second server private key;

[0010] The second server generates a collaborative public key based on the first server's public key and the second server's public key, and sends the collaborative public key and the second server's public key to the first server;

[0011] The first server generates a key ID based on the first server public key, the second server public key, and the collaborative public key, and stores the first server public key, the second server public key, and the collaborative public key;

[0012] The first server generates a first CSR code based on the key ID selected by the user, using the first server private key corresponding to the key ID, and generates an intermediate result using the first server private key;

[0013] The first server sends the CSR encoding and the intermediate result to the second server using collaborative public key encryption;

[0014] The second server generates a second CSR encoding based on its private key, and generates a complete signature based on its private key and the intermediate result.

[0015] The second server combines the first CSR encoding and the second CSR encoding into a complete CSR based on the complete signature, and sends the complete CSR to the first server using the collaborative public key;

[0016] The first server sends the complete CSR to the CA to generate a certificate;

[0017] The client obtains the user's data to be signed and sends the data to be signed to the first server;

[0018] The first server detects the certificate status corresponding to the user's key ID and sends the key ID with a normal certificate status to the client.

[0019] The client sends the signature key ID selected by the user to the first server;

[0020] The first server generates a hash value based on the data to be signed, generates an intermediate signature result using the first server's private key corresponding to the signature key id, and encrypts and sends it to the second server using the collaborative public key corresponding to the signature key id.

[0021] The second server obtains the user's authorization instruction, and generates a complete signature result based on the second server's private key and the intermediate signature result using the authorization instruction. The complete signature result is then encrypted and sent to the first server using the collaborative public key, thereby completing the signing.

[0022] Furthermore, in the method described above, the second server generates a second server public key using a pre-generated second server private key, including:

[0023] The second server receives the access result from the user's handheld application and generates a random challenge request based on the access result, which is then sent to the user's handheld application.

[0024] The user's handheld application terminal generates a challenge response by signing it with the private key of the Fido authorization key, and then sends the challenge response to the second server;

[0025] The second server obtains user authorization by verifying the signature result of the challenge response, and generates the second server public key using the pre-generated second server private key.

[0026] Furthermore, in the above-described method, the first server generates a key ID based on the first server public key, the second server public key, and the collaborative public key, and stores the first server public key, the second server public key, and the collaborative public key, including:

[0027] The first server generates a collaborative public key based on the first server public key and the second server public key, and compares and verifies it with the collaborative public key generated by the second server. If the verification is successful, the first server generates a key ID based on the first server public key, the second server public key and the collaborative public key, and stores the first server public key, the second server public key and the collaborative public key.

[0028] Furthermore, in the method described above, the second server generates a second CSR encoding based on its private key, and generates a complete signature based on the second server's private key and the intermediate result, including:

[0029] The second server receives the access result from the user's handheld application and generates a random challenge request based on the access result, which is then sent to the user's handheld application.

[0030] The user's handheld application terminal generates a challenge response by signing it with the private key of the Fido authorization key, and then sends the challenge response to the second server;

[0031] The second server obtains user authorization by verifying the signature result of the challenge response, generates a second CSR encoding based on the second server's private key, and generates a complete signature based on the second server's private key and the intermediate result.

[0032] Furthermore, in the method described above, the second server obtains the user's authorization instruction, generates a complete signature result based on the second server's private key and the intermediate signature result using the authorization instruction, and encrypts and sends the complete signature result to the first server using the collaborative public key, thereby completing the signing, including:

[0033] The second server receives the access result from the user's handheld application and generates a random challenge request based on the access result, which is then sent to the user's handheld application.

[0034] The user's handheld application terminal generates a challenge response by signing it with the private key of the Fido authorization key, and then sends the challenge response to the second server;

[0035] The second server verifies the signature result of the challenge response, obtains user authorization, generates a complete signature result based on the second server's private key and the intermediate signature result, and encrypts and sends the complete signature result to the first server using the collaborative public key, thereby completing the signature.

[0036] Furthermore, in the method described above, before the second server receives the access result from the user's handheld application and generates a random challenge request based on the access result to send to the user's handheld application, the method further includes:

[0037] The user's handheld application accesses the second server via a QR code displayed on the client.

[0038] Furthermore, in the above-described method, the client logging into the first server using user information entered by the user includes:

[0039] The client logs into the first server using the username and password entered by the user.

[0040] Furthermore, in the above-described method, the client logs into the first server using a username and password entered by the user, including:

[0041] The client logs into the first server through a browser, using the username and password entered by the user.

[0042] The beneficial effects of this invention are as follows:

[0043] The first server and the second server in this application generate first server public keys and second server public keys respectively based on preset private keys. Then, they generate a collaborative public key based on the first server public keys and the second server public keys, and save the corresponding key IDs generated from the first server public keys, the second server public keys, and the collaborative public keys. Next, they generate a complete CSR code based on the first server private keys and the second server private keys and send it to the CA to generate a certificate. During collaborative signing, the first server first checks the certificate status corresponding to all key IDs and displays the key IDs with normal status to the user. Then, it uses the key ID selected by the user to perform the signing. The client logs into the first server based on user information and sends the data to be signed to the first server. One server generates a hash value based on the data to be signed, and generates an intermediate signature result using the first server's private key corresponding to the signature key ID. This intermediate result is then encrypted using the collaborative public key corresponding to the signature key ID and sent to a second server. The second server, upon receiving the user's authorization instruction, generates a complete signature result using its own private key and the intermediate signature result. This complete signature result is then encrypted using the collaborative public key and sent to the first server, thus completing the signing process. The user's signature key is directly stored in the server's key ID. When performing collaborative signing, the user only needs to select the key ID to use and authorize the process, eliminating the need for the user to store the key themselves. This solves the problem of users easily losing their keys on their mobile devices during collaborative signing. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is a flowchart provided by an embodiment of a collaborative signature method of the present invention. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0047] The collaborative signature server is a secure private key escrow collaborative signature system designed based on the domestic cryptographic algorithms SM2, SM3, and SM4, providing a secure and compliant end-user authentication solution for user operation terminals.

[0048] Currently, when mobile phones and servers collaborate on signing, the mobile phone calculates a portion of the intermediate signature result, while the server calculates and synthesizes the actual signature result. However, the keys stored on the mobile phone for existing collaborative signing are usually saved as files and protected by passwords, which are easily lost or corrupted (e.g., when the app is uninstalled).

[0049] Figure 1 This is a flowchart illustrating an embodiment of a collaborative signature method according to the present invention. Please refer to [link / reference]. Figure 1 This embodiment may include the following steps:

[0050] S1. The client logs into the first server using the user information entered by the user.

[0051] S2. The first server generates the first server public key using the pre-generated first server private key.

[0052] S3. The second server generates a second server public key using a pre-generated second server private key.

[0053] S4. The second server generates a collaborative public key based on the public keys of the first server and the second server, and sends the collaborative public key and the public key of the second server to the first server.

[0054] S5. The first server generates a key ID based on the first server public key, the second server public key, and the collaborative public key, and stores the first server public key, the second server public key, and the collaborative public key.

[0055] S6. The first server generates the first CSR code based on the key ID selected by the user and the first server private key corresponding to the key ID, and generates the intermediate result using the first server private key.

[0056] S7. The first server sends the CSR encoding and intermediate results to the second server using collaborative public key encryption.

[0057] S8. The second server generates a second CSR encoding based on its private key, and generates a complete signature based on its private key and intermediate results.

[0058] S9. The second server combines the first CSR encoding and the second CSR encoding into a complete CSR based on the complete signature, and sends the complete CSR to the first server using a collaborative public key.

[0059] S10. The first server sends the complete CSR to the CA to generate the certificate.

[0060] S11. The client obtains the user's data to be signed and sends the data to be signed to the first server.

[0061] S12. The first server checks the certificate status corresponding to all user key IDs and sends the key IDs with normal certificate status to the client.

[0062] S13. The client sends the signature key ID selected by the user to the first server.

[0063] S14. The first server generates a hash value based on the data to be signed, generates an intermediate signature result using the first server's private key corresponding to the signature key id, and encrypts and sends it to the second server using the collaborative public key corresponding to the signature key id.

[0064] S15. The second server obtains the user's authorization instruction, and generates a complete signature result based on the second server's private key and the intermediate signature result using the authorization instruction. The complete signature result is then encrypted and sent to the first server using the collaborative public key, thereby completing the signature.

[0065] Understandably, in this embodiment, the first server and the second server generate a first server public key and a second server public key respectively based on the preset generated private key. Then, they generate a collaborative public key based on the first server public key and the second server public key, and save the corresponding key IDs generated from the first server public key, the second server public key, and the collaborative public key. Then, they generate a complete CSR code based on the first server private key and the second server private key and send it to the CA to generate a certificate. When performing collaborative signing, the first server first checks the certificate status corresponding to all key IDs and displays the key IDs with normal status to the user. Then, it uses the key ID selected by the user to perform the signing. The client logs into the first server according to the user information and sends the data to be signed to the first server. The system involves two servers: the first server generates a hash value based on the data to be signed, generates an intermediate signature result using its private key corresponding to the signature key ID, and encrypts and sends it to the second server using the collaborative public key corresponding to the signature key ID. The second server, upon receiving the user's authorization instruction, generates a complete signature result using its private key and the intermediate signature result, and encrypts and sends the complete signature result to the first server using the collaborative public key, thus completing the signing process. The user's signature key is directly stored in the server's key ID. During collaborative signing, the user only needs to select the key ID to use and authorize the process, eliminating the need for the user to store the key themselves. This solves the problem of users easily losing their keys on their mobile devices during collaborative signing.

[0066] It should be noted that in this embodiment, when the second server sends the collaboration key to the first server, it also sends a key pre-generated by the second server. The first server stores both its own key and its second key in the key ID. That is, when generating the certificate and collaboration signature, the private key used by the second server is the second server's private key corresponding to the key ID. Data transmission between the first server, the second server, and the client is conducted using the internal network to prevent the security risks and potential leaks associated with using the public network.

[0067] In some optional embodiments, the private keys of the first server and the second server are generated using a random number generator, while the public key of the first server is generated using the SECP265K1 algorithm based on its private key, and the public key of the second server is generated similarly. The CSR code, however, is generated by the CSP (Certificate Service Provider) at the same time as the private key is generated when the certificate applicant applies for the digital certificate.

[0068] Preferably, step S3 specifically includes:

[0069] The second server receives the access results from the user's handheld application and generates a random challenge request based on the access results, which is then sent to the user's handheld application.

[0070] The user uses the private key of the Fido authorization key to sign the application, thereby generating a challenge response, and then sends the challenge response to the second server;

[0071] The second server verifies the signature of the challenge response, obtains user authorization, and generates a second server public key using a pre-generated second server private key.

[0072] Understandably, this application requires user authorization when generating the public key on the second server, thereby ensuring the security of the key generation process.

[0073] Preferably, step S5 is as follows:

[0074] The first server generates a collaborative public key based on the first server's public key and the second server's public key, and compares and verifies it with the collaborative public key generated by the second server. If the verification is successful, the first server generates a key ID based on the first server's public key, the second server's public key, and the collaborative public key, and stores the first server's public key, the second server's public key, and the collaborative public key.

[0075] Understandably, to prevent intentional tampering during the generation of the collaborative public key, after the second server generates the key, the first server generates another collaborative key based on the first server's public key and the second server's public key, and compares it with the key generated by the second server, thereby improving key security.

[0076] Preferably, step S8 includes:

[0077] The second server receives the access results from the user's handheld application and generates a random challenge request based on the access results, which is then sent to the user's handheld application.

[0078] The user uses the private key of the Fido authorization key to sign the application, thereby generating a challenge response, and then sends the challenge response to the second server;

[0079] The second server verifies the signature result of the challenge response, obtains user authorization, generates a second CSR encoding based on the second server's private key, and generates a complete signature based on the second server's private key and intermediate results.

[0080] Preferably, step S15 includes:

[0081] The second server receives the access results from the user's handheld application and generates a random challenge request based on the access results, which is then sent to the user's handheld application.

[0082] The user uses the private key of the Fido authorization key to sign the application, thereby generating a challenge response, and then sends the challenge response to the second server;

[0083] The second server verifies the signature result of the challenge response, obtains user authorization, generates a complete signature result based on the second server's private key and the intermediate signature result, and sends the complete signature result to the first server in encryption using the collaborative public key, thereby completing the signature.

[0084] In some optional embodiments, the client can display a QR code, allowing the user's handheld application to access the second server by scanning the QR code. The client can also verify the user's identity through facial recognition or fingerprint recognition. After successful verification, the user can access the second server using the client.

[0085] Preferably, step S1 includes:

[0086] The client logs into the first server using the username and password entered by the user.

[0087] In some alternative embodiments, the client can be a computer used by the user, who can log in to the first server through a browser to access the first server.

[0088] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0089] It should be noted that, in the description of the present invention, the terms "first", "second", etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance. In addition, in the description of the present invention, unless otherwise specified, the meaning of "plurality" is at least two.

[0090] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present invention pertain.

[0091] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0092] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0093] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing module, or each unit may exist physically separately, or two or more units may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or in the form of software functional modules. If the integrated modules are implemented in the form of software functional modules and sold or used as independent products, they may also be stored in a computer-readable storage medium.

[0094] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0095] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0096] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A collaborative signature method, characterized in that, include: The client logs into the first server using the user information entered by the user; The first server generates a first server public key using a pre-generated first server private key; The second server generates a second server public key using a pre-generated second server private key; The second server generates a collaborative public key based on the first server's public key and the second server's public key, and sends the collaborative public key and the second server's public key to the first server; The first server generates a key ID based on the first server public key, the second server public key, and the collaborative public key, and stores the first server public key, the second server public key, and the collaborative public key; The first server generates a first CSR code based on the key ID selected by the user, using the first server private key corresponding to the key ID, and generates an intermediate result using the first server private key; The first server sends the first CSR encoding and the intermediate result to the second server using collaborative public key encryption; The second server generates a second CSR encoding based on its private key, and generates a first complete signature based on its private key and the intermediate result. The second server combines the first CSR encoding and the second CSR encoding into a complete CSR based on the first complete signature, and sends the complete CSR to the first server using the collaborative public key; The first server sends the complete CSR to the CA to generate a certificate; The client obtains the user's data to be signed and sends the data to be signed to the first server; The first server detects the certificate status corresponding to all the user's key IDs and sends the key IDs with normal certificate status to the client. The client sends the key ID selected by the user from the key IDs in the certificate status normal to the first server as the signing key ID; The first server generates a hash value based on the data to be signed, generates an intermediate signature result using the first server's private key corresponding to the signature key id, and encrypts and sends it to the second server using the collaborative public key corresponding to the signature key id. The second server obtains the user's authorization instruction, and generates a second complete signature based on the second server's private key and the intermediate signature result using the authorization instruction. The second complete signature is then encrypted and sent to the first server using the collaborative public key, thereby completing the signing process.

2. The method according to claim 1, characterized in that, The second server generates a second server public key using a pre-generated second server private key, including: The second server receives the access result from the user's handheld application and generates a random challenge request based on the access result, which is then sent to the user's handheld application. The user's handheld application terminal generates a challenge response by signing it with the private key of the Fido authorization key, and then sends the challenge response to the second server; The second server obtains user authorization by verifying the signature result of the challenge response, and generates the second server public key using the pre-generated second server private key.

3. The method according to claim 2, characterized in that, The first server generates a key ID based on the first server public key, the second server public key, and the collaborative public key, and stores the first server public key, the second server public key, and the collaborative public key, including: The first server generates a collaborative public key based on the first server public key and the second server public key, and compares and verifies it with the collaborative public key generated by the second server. If the verification is successful, the first server generates a key ID based on the first server public key, the second server public key and the collaborative public key, and stores the first server public key, the second server public key and the collaborative public key.

4. The method according to claim 3, characterized in that The second server generates a second CSR encoding based on its private key, and generates a first complete signature based on its private key and the intermediate result, including: The second server receives the access result from the user's handheld application and generates a random challenge request based on the access result, which is then sent to the user's handheld application. The user's handheld application terminal generates a challenge response by signing it with the private key of the Fido authorization key, and then sends the challenge response to the second server; The second server obtains user authorization by verifying the signature result of the challenge response, generates a second CSR encoding based on the second server's private key, and generates a first complete signature based on the second server's private key and the intermediate result.

5. The method according to claim 4, characterized in that, The second server obtains the user's authorization instruction, and generates a second complete signature based on the second server's private key and the intermediate signature result using the authorization instruction. The second complete signature is then encrypted and sent to the first server using the collaborative public key, thereby completing the signing process. This includes: The second server receives the access result from the user's handheld application and generates a random challenge request based on the access result, which is then sent to the user's handheld application. The user's handheld application terminal generates a challenge response by signing it with the private key of the Fido authorization key, and then sends the challenge response to the second server; The second server obtains user authorization by verifying the signature result of the challenge response, generates a second complete signature based on the second server's private key and the intermediate signature result, and encrypts and sends the second complete signature to the first server using the collaborative public key, thereby completing the signing.

6. The method according to claim 2, characterized in that, Before the second server receives the access result from the user's handheld application and generates a random challenge request based on the access result to send to the user's handheld application, it further includes: The user's handheld application accesses the second server via a QR code displayed on the client.

7. The method according to claim 5, characterized in that, The client logs into the first server using user information entered by the user, including: The client logs into the first server using the username and password entered by the user.

8. The method according to claim 7, characterized in that, The client logs into the first server using a username and password entered by the user, including: The client logs into the first server through a browser, using the username and password entered by the user.

Images