Method, device and equipment for proving possession of private key component in collaborative signature

Abstract

The present application relates to the field of security protocol technology, and specifically provides a method, apparatus, and device for proving possession of a private key component in a collaborative signature. The method is applied to a first terminal in a collaborative signature system, which also includes a second terminal; the first terminal and the second terminal respectively hold a first private key component and a second private key component of a private key in the collaborative signature system; the method includes: determining data to be verified based on key parameters, the key parameters including: a first private key component, a public key corresponding to the private key, and a random number; the data to be verified including: first data and second data; and sending the data to be verified to the second terminal so that the second terminal can determine whether the second private key component matches the first private key component based on the data to be verified. Some embodiments of the present application can determine the security of private key component storage and improve the security of collaborative signing or decryption.

Description

Technical Field

[0001] The present application relates to the technical field of security protocols, and in particular to a method, apparatus and device for proving possession of a private key component in a collaborative signature. Background Art

[0002] With the development of cloud computing, big data, and the Internet of Things (IoT), collaborative signatures are playing an increasingly important role in ensuring data security and promoting multi-party collaboration. With the rapid development of mobile internet technology, generating user keys and running cryptographic algorithms within mobile terminal apps has become a mainstream application requirement. In existing collaborative encryption schemes, the user's private key is typically divided into two private key components and stored on different terminals. When performing signing or decryption operations, the terminals must interact to jointly generate the signature value or decrypt the ciphertext. During the collaborative decryption process, any collaborating party must use its own private key component to perform the relevant operations. These operations can be exploited by malicious attackers to trick the collaborating party into decrypting specific ciphertext, potentially leading to unauthorized use of the private key or leakage of security-sensitive parameters.

[0003] Therefore, how to provide a technical solution for a secure method of proving possession of private key components in collaborative signatures has become a technical problem that needs to be solved urgently. Summary of the Invention

[0004] The purpose of some embodiments of the present application is to provide a method, device and equipment for proving the possession of private key components in collaborative signatures. Through the technical solutions of the embodiments of the present application, the security of the storage of private key components can be determined, so that a trust relationship can be established between the collaborating parties in the collaborative signature system, thereby ensuring the security of collaborative signatures or decryption.

[0005] In a first aspect, some embodiments of the present application provide a method for proving possession of a private key component in a collaborative signature, which is applied to a first terminal in a collaborative signature system, and the collaborative signature system also includes a second terminal; the first terminal and the second terminal respectively hold a first private key component and a second private key component of a private key in the collaborative signature system; the method includes: determining data to be verified based on key parameters, wherein the key parameters include: the first private key component, the public key corresponding to the private key, and a random number; the data to be verified includes: first data and second data; the data to be verified is sent to the second terminal, so that the second terminal determines whether the second private key component matches the first private key component based on the data to be verified.

[0006] Some embodiments of the present application transmit to a second terminal data to be verified, obtained by calculating key parameters on a first terminal, so that the second terminal can confirm, based on the data to be verified, whether the private key components stored by the two terminals match. This method can confirm the security and validity of the private key components stored between the two terminals, resist malicious attackers from impersonating one terminal to initiate a collaborative process on the other, and further improve the security of the collaborative signature system. Furthermore, before executing a collaborative signature or decryption, checking and confirming that the private keys held by both parties participating in the collaborative signature match can effectively prevent the terminal from executing a cryptographic protocol with a malicious party, thereby preventing related malicious attacks.

[0007] In some embodiments, the first terminal is a server and the second terminal is a client; or, the first terminal is a client and the second terminal is a server.

[0008] In some embodiments of the present application, the types of the first terminal and the second terminal can be flexibly set, and the practicality is relatively wide.

[0009] In some embodiments, determining the data to be verified based on the key parameters includes: calculating the first private key component, the public key, the random number, and a base point of an elliptic curve whose order is a prime number to obtain the first data; and calculating the random number and the base point to obtain the second data.

[0010] Some embodiments of the present application calculate all or part of the data in the key parameters to obtain first data and second data, provide data support for verifying whether there are matching private key components between two terminals, and realize security verification of the private key components.

[0011] In the second aspect, some embodiments of the present application provide a method for proving possession of a private key component in a collaborative signature, which is applied to a second terminal in a collaborative signature system, and the collaborative signature system also includes a first terminal; the first terminal and the second terminal respectively hold the first private key component and the second private key component of the private key in the collaborative signature system; the method includes: receiving data to be verified sent by the first terminal, wherein the data to be verified is obtained by any method embodiment in the first aspect; the data to be verified includes: first data and second data; based on the second private key component and the data to be verified, determining a verification parameter; and confirming whether the second private key component matches the first private key component based on the verification parameter and the data to be verified.

[0012] Some embodiments of the present application determine whether the private key components of both ends match based on the received data to be verified and the second private key component by the second terminal, thereby achieving accurate verification of whether the private key components match, effectively resisting malicious attackers from impersonating any terminal to initiate a collaborative process to another terminal, and further improving the security of the collaborative signature system.

[0013] In some embodiments, determining the verification parameter based on the second private key component and the data to be verified includes: calculating the second private key component and the first data to obtain the verification parameter; confirming whether the second private key component matches the first private key component based on the verification parameter and the data to be verified includes: if it is confirmed that the verification parameter and the second data are the same, then the second private key component matches the first private key component; if the verification parameter and the second data are not the same, then the second private key component does not match the first private key component.

[0014] In some embodiments, determining the verification parameter based on the second private key component and the data to be verified includes: calculating the second private key component and the second data to obtain the verification parameter; confirming whether the second private key component matches the first private key component based on the verification parameter and the data to be verified includes: if it is confirmed that the verification parameter and the first data are the same, then the second private key component matches the first private key component; if the verification parameter and the first data are different, then the second private key component does not match the first private key component.

[0015] Some embodiments of the present application can achieve efficient verification of whether there are matching private key components between two terminals by comparing the calculated verification parameters with the corresponding data to obtain a matching result.

[0016] In the third aspect, some embodiments of the present application provide a device for proving possession of a private key component in a collaborative signature, which is applied to a first terminal in a collaborative signature system, and the collaborative signature system also includes a second terminal; the first terminal and the second terminal respectively hold the first private key component and the second private key component of the private key in the collaborative signature system; the device includes: a verification data calculation module, used to determine the data to be verified based on key parameters, wherein the key parameters include: the first private key component, the public key corresponding to the private key, and a random number; the data to be verified includes: first data and second data; a first sending module, used to send the data to be verified to the second terminal, so that the second terminal can determine whether the second private key component matches the first private key component based on the data to be verified.

[0017] In a fourth aspect, some embodiments of the present application provide a device for proving possession of a private key component in a collaborative signature, which is applied to a second terminal in a collaborative signature system, and the collaborative signature system also includes a first terminal; the first terminal and the second terminal respectively hold a first private key component and a second private key component of a private key in the collaborative signature system; the device includes: a second receiving module for receiving data to be verified sent by the first terminal, wherein the data to be verified is obtained by any method embodiment in the first aspect; the data to be verified includes: first data and second data; a verification parameter calculation module for determining a verification parameter based on the second private key component and the data to be verified; a verification result output module for confirming whether the second private key component matches the first private key component based on the verification parameter and the data to be verified.

[0018] In a fifth aspect, some embodiments of the present application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the method described in any embodiment of the first aspect.

[0019] In a sixth aspect, some embodiments of the present application provide an electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor can implement a method as described in any embodiment of the first aspect when executing the program.

[0020] In a seventh aspect, some embodiments of the present application provide a computer program product, comprising a computer program, wherein the computer program, when executed by a processor, can implement the method described in any embodiment of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions of some embodiments of the present application, the following is a brief introduction to the drawings required for use in some embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0022] Figure 1 A system diagram for proving possession of a private key component in collaborative signatures provided in some embodiments of the present application;

[0023] Figure 2 One of the flow charts of the method for proving possession of a private key component in collaborative signature provided in some embodiments of the present application;

[0024] Figure 3Flowchart 2 of the method for proving possession of a private key component in collaborative signature provided in some embodiments of the present application;

[0025] Figure 4 Flowchart 3 of the method for proving possession of a private key component in collaborative signature provided in some embodiments of the present application;

[0026] Figure 5 One of the block diagrams of the apparatus for proving possession of a private key component in a collaborative signature provided in some embodiments of the present application;

[0027] Figure 6 The second block diagram of the apparatus for proving possession of a private key component in collaborative signature provided in some embodiments of the present application;

[0028] Figure 7 A schematic diagram of an electronic device is provided for some embodiments of the present application. DETAILED DESCRIPTION

[0029] The technical solutions in some embodiments of the present application will be described below in conjunction with the drawings in some embodiments of the present application.

[0030] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0031] Related technologies provide a collaborative decryption process for the SM2 algorithm, where the client and server perform decryption according to the specified process. In these collaborative decryption processes, one party (client / server) is typically designated as the initiator of the decryption process, while the other party is designated as the collaborator. In this collaborative decryption process, the client and server are peers, and either party can be the initiator.

[0032] Typically, one collaborating party is responsible for obtaining the ciphertext of business data, while the other party cannot determine whether the received elliptic curve point is derived from a valid business data ciphertext. Therefore, establishing a trust relationship between the two collaborating parties is crucial for protecting the security of the private key component. A typical attack scenario involves performing a cross-ciphertext decryption attack by replacing random elliptic curve points. A malicious client can replace the elliptic curve point by sending a constructed fake ciphertext or by replacing a valid ciphertext with another valid ciphertext (which may correspond to another electronic document). This allows the attacker to decrypt other associated ciphertexts during the collaborative decryption process. In existing technologies, mobile terminal identities are generally authenticated using methods such as usernames and passwords. For example, a mobile terminal maintains a device identifier (DevID), and a password authentication protocol is used to confirm that the device is trusted. However, this method of establishing trust relies on additional authentication factors and cannot directly confirm the trust relationship between the two collaborating parties. Alternatively, methods such as establishing a TLS / SSL encrypted communication channel can be employed. However, the TLS handshake requires multiple round-trip communications, and the multiple interactions for collaborative signing / decryption can significantly increase overall latency. TLS's symmetric and asymmetric encryption operations consume CPU resources, resulting in a significant consumption of computing resources. Furthermore, TLS relies on a CA system, which conflicts with the decentralized trust model of collaborative technology. If the CA is compromised, the TLS channel could be vulnerable to man-in-the-middle attacks, rendering the distributed authentication of the collaborative technology itself ineffective.

[0033] In light of this, some embodiments of the present application provide a method for proving possession of private key components in collaborative signatures. This method improves the security of collaborative signatures or decryption and reduces attacks by proving that the first and second terminals in the collaborative signature system hold matching private key components. Furthermore, before executing collaborative signatures or decryption, checking and confirming that the private keys held by both parties participating in the collaborative signature match can effectively prevent a terminal from executing cryptographic protocols with malicious parties, thereby preventing related malicious attacks.

[0034] The following is combined with Figure 1 The overall structure of the system for proving possession of the private key component in collaborative signature (or referred to as collaborative signature system) provided by some embodiments of the present application is exemplarily described.

[0035] like Figure 1 As shown, some embodiments of the present application provide a system diagram for proving possession of a private key component in a collaborative signature, wherein the system for proving possession of a private key component in a collaborative signature includes a first terminal 100 and a second terminal 200. The first terminal 100 and the second terminal 200 respectively store a public key P of a collaborative signature algorithm. A The corresponding private key d ATwo private key components D1 (as a specific example of the first private key component) and D2 (as a specific example of the second private key component) are provided. When verifying proof of possession of the private key components, the first terminal 100 can calculate the relevant key parameters to obtain data to be verified, and send the data to be verified to the second terminal 200. The second terminal 200 can use the data to be verified to confirm whether D1 and D2 stored on the second terminal and the second terminal match.

[0036] It should be noted that the collaborative signature algorithm can be the national secret SM2 algorithm, or the ECC algorithm, SM9 algorithm, etc. The embodiment of this application does not specifically limit the encryption and decryption algorithm.

[0037] In some embodiments of the present application, when the first terminal 100 is a server, the second terminal 200 is a client; or when the first terminal 100 is a client, the second terminal 200 is a server.

[0038] In actual applications, the client can perform a one-way verification protocol with the server to determine that the client and the server hold matching private key components; or the server can perform a one-way verification protocol with the client to determine that the server and the client hold matching private key components. Alternatively, both parties can perform two-way verification: the client first determines that the server holds a matching private key component, and then the server determines that the client holds a matching private key component; or the server first determines that the client holds a matching private key component, and then the client determines that the server holds a matching private key component. The specific verification method can be selected according to the actual scenario, and the embodiments of this application are not specifically limited here.

[0039] In addition, if there are more than two clients and a server storing a public key P in other application scenarios A For more than two private key components, the data to be verified on different terminals can be jointly calculated to determine whether the private key components stored between the more than two clients and the server are matched. The calculation principle of the data to be verified is the same as that of the method embodiment provided in this application.

[0040] The following describes the implementation process of the proof of possession of the private key component in the collaborative signature, taking the first terminal 100 as the client and the second terminal 200 as the server. Before executing the following method embodiment, the client and the server are the owners of D1 and D2 respectively. For example, the client has the private key component D1, the server has the private key component D2, and both parties share the private key d A , the corresponding public key is P A =[D1 -1 D2 -1 -1]G. Where G is a prime base point of the elliptic curve.

[0041] The following is combined with Figure 2 The implementation process of proof of possession of a private key component in a collaborative signature performed by the first terminal 100 is exemplarily described in some embodiments of the present application.

[0042] Please see the attached Figure 2 , Figure 2 A flowchart of a method for proving possession of a private key component in a collaborative signature is provided for some embodiments of the present application. The method for proving possession of a private key component in a collaborative signature may include:

[0043] S210, determining data to be verified based on key parameters, wherein the key parameters include: the first private key component, the public key corresponding to the private key, and a random number; the data to be verified includes: first data and second data.

[0044] For example, in some embodiments of the present application, the client can use a random number generation algorithm to generate a random number R1, R1∈[1,n-1], where n is the order of the base point G. Afterwards, the client generates D1, R1, P A Calculate all or part of the parameters in G to obtain the first data Q1 and the second data U.

[0045] In some embodiments of the present application, S210 may include: calculating the first private key component, the public key, the random number, and a base point of an elliptic curve whose order is a prime number to obtain the first data; calculating the random number and the base point to obtain the second data.

[0046] For example, in some embodiments of the present application, D1, R1, P A Calculate with G to get Q1. The specific calculation formula is: Q1=[D1R1](P A + G). R1 ​​and G are calculated to obtain U, that is, U = [R1] G. It is understandable that the calculation method and algorithm used for Q1 and U can be flexibly adjusted according to the actual application scenario, and the embodiments of the present application are not limited thereto.

[0047] S220: Send the data to be verified to the second terminal, so that the second terminal determines whether the second private key component matches the first private key component based on the data to be verified, and determines a matching result.

[0048] For example, in some embodiments of the present application, the client sends Q1 and U to the server. After receiving Q1 and U, the server can calculate and verify them in combination with D2 to confirm whether D1 and D2 on the client and server match.

[0049] The following example illustrates the server-side Figure 2The implementation process of the method embodiment in the embodiment of the invention is to verify the data to be verified and obtain the matching result.

[0050] Please see the attached Figure 3 , Figure 3 A flowchart of a method for proving possession of a private key component in a collaborative signature is provided for some embodiments of the present application. The method for proving possession of a private key component in a collaborative signature may include:

[0051] S310: Receive data to be verified sent by the first terminal, where the data to be verified includes: first data and second data.

[0052] For example, in some embodiments of the present application, by Figure 2 In the embodiment of the method, the client can send the calculated data to be verified to the server. The server receives Q1 and U.

[0053] S320: Determine a verification parameter based on the second private key component and the data to be verified.

[0054] For example, in some embodiments of the present application, the verification parameter may be calculated using the second private key component and the first data; or the verification parameter may be calculated using the second private key component and the second data.

[0055] S330: Confirm whether the second private key component matches the first private key component based on the verification parameter and the data to be verified.

[0056] For example, in some embodiments of the present application, based on the verification parameter and the second data or the first data in S320 , it is confirmed whether D1 of the client and D2 of the server match.

[0057] In some embodiments of the present application, S320 may include: calculating the second private key component and the first data to obtain the verification parameter. S330 may include: if it is confirmed that the verification parameter and the second data are the same, then the second private key component matches the first private key component; if the verification parameter and the second data are not the same, then the second private key component does not match the first private key component.

[0058] For example, in some embodiments of the present application, the server D2 and Q1 are calculated to obtain the verification parameter Q2, i.e., Q2 = [D2] Q1. By comparing Q2 with U, it can be confirmed whether the client D1 and the server D2 match. In other words, if Q2 = U, then the client D1 and the server D2 match; if Q2 ≠ U, then the private key verification fails, and the two parties possess mismatching private key components.

[0059] In some other embodiments of the present application, S320 may include: calculating the second private key component and the second data to obtain the verification parameter. S330 may include: if it is confirmed that the verification parameter and the first data are the same, then the second private key component matches the first private key component; if the verification parameter and the first data are different, then the second private key component does not match the first private key component.

[0060] For example, in some embodiments of the present application, the server calculates D2 and U to obtain the verification parameter Q2', that is, Q2'=[D2 -1 By comparing Q2' with Q1, we can confirm whether the client's D1 and the server's D2 match. That is, if Q2' = Q1, then the client's D1 and the server's D2 match; if Q2' ≠ Q1, then the private key verification fails, and the two parties possess mismatched private key components.

[0061] It should be noted that Q2=U or Q2'=Q1 can prove that the private key components of both ends match, which is derived according to the formula. The following example illustrates the derivation process of Q2=U:

[0062] P A =[D1 -1 D2 -1 -1]G

[0063] Q1=[D1R1](P A +G)=[D1R1]([D1 -1 D2 -1 -1]G+G)=[D2 -1 R1]G

[0064] U=[R1]G

[0065] Q2=[D2]Q1=[D2][D2 -1 R1]G=[R1]G=U

[0066] It can be seen that if D1 and D2 satisfy P A The calculation formula of the public key P A The corresponding private key d A It can be deduced that Q2=U. It should be noted that the above formula can be flexibly adjusted, as long as the public key P is guaranteed. A The corresponding private key d A The corresponding relationship with Q2=U or Q2'=Q1 remains unchanged.

[0067] The following uses the example of the client and server performing two-way verification to see whether the other party holds a private key component that matches their own to illustrate the implementation process of proof of possession of the private key component in collaborative signature.

[0068] The following is combined with Figure 4 The specific process of proving possession of the private key component in the collaborative signature provided by some embodiments of the present application is exemplified.

[0069] Please see the attached Figure 4 , Figure 4 A flowchart of a method for proving possession of a private key component in collaborative signature is provided for some embodiments of the present application.

[0070] The above process is described below as an example.

[0071] S401: The client generates a random number R1.

[0072] Where R1∈[1,n-1]

[0073] S402, client to D1, R1, P A Calculate with G to get Q1 and U.

[0074] S403: The client sends Q1 and U to the server.

[0075] S404: The server calculates Q1 and D2 to obtain Q2.

[0076] S405, determine whether Q2 is equal to U, if so, execute S406, otherwise execute S412.

[0077] S406: The server generates a random number R2.

[0078] Where R2∈[1,n-1].

[0079] S407, the server to D2, R2, P A Calculate with G to get Q3 and V.

[0080] S408: The server sends Q3 and V to the client.

[0081] S409: The client calculates Q3 and D1 to obtain Q4.

[0082] S410, determine whether Q4 is equal to V, if so, execute S411, otherwise execute S412.

[0083] S411, confirm that D1 on the client side matches D2 on the server side.

[0084] S412, feedback error prompt.

[0085] Among them, the error prompt indicates that the private key certification failed, the private key components of the two terminals do not match, and there is a security risk.

[0086] It is understandable that if S412 is executed directly from S405, the server will feed back an error prompt to the client; if S412 is executed from S410, the client will feed back an error prompt to the server.

[0087] It should be noted that the specific implementation process of S401 to S412 can refer to the method embodiment provided above, and in order to avoid repetition, the detailed description is appropriately omitted here.

[0088] It can be seen that Figure 4 The client and server in the process each generate random numbers and use them in the calculation steps, so that the elliptic curve points output during each private key component possession proof are unique and can resist replay attacks. In practical applications, dedicated equipment / chips can be used to generate true random numbers that meet the detection specifications. Based on the "one-time one-pad" concept, the security of the private key component during the private key component possession proof process is guaranteed. In the private key component possession proof implementation process, the two terminals only disclose the intermediate results of the elliptic curve points and do not disclose any direct calculation results of the private key components. In this solution design, the discrete logarithm problem on the elliptic curve ensures the security of the private key component.

[0089] Through some of the embodiments of the present application described above, it can be seen that in the embodiments of the present application, the intermediate results disclosed by both parties during the interaction between the two terminals do not include intermediate results used in the collaborative signature or protocol decryption process (such as temporary elliptic curve points, temporary variables disclosed by linear equations, etc.), which prevents attackers from using these intermediate results to attack the collaborative signature and collaborative decryption protocols. In the private key component certification process proposed in the present invention, it can be confirmed that the other party holds matching private key components, so that a trust relationship is established between the collaborating parties (i.e., the client and the server), and then the collaborative signature, collaborative decryption and other processes are executed, which can resist malicious attackers from impersonating mobile terminals to initiate collaborative processes to the server, further improving the security of the system. In addition, after trust is established between the collaborating parties, the collaborative signature and collaborative decryption processes can be executed multiple times within a certain time range or number of times without repeated verification.

[0090] Please refer to Figure 5 , Figure 5 A block diagram illustrating the components of an apparatus for proving possession of a private key component in a collaborative signature, as provided in some embodiments of the present application, is provided. It should be understood that the apparatus for proving possession of a private key component in a collaborative signature corresponds to the aforementioned method embodiment and is capable of executing each step involved in the aforementioned method embodiment. The specific functions of the apparatus for proving possession of a private key component in a collaborative signature can be found in the description above, and a detailed description is omitted here to avoid repetition.

[0091] Figure 5The device for proving the possession of a private key component in a collaborative signature includes at least one software functional module that can be stored in a memory in the form of software or firmware or solidified in the device for proving the possession of a private key component in a collaborative signature. The device for proving the possession of a private key component in a collaborative signature is applied to a first terminal in a collaborative signature system, and the collaborative signature system also includes a second terminal; the first terminal and the second terminal respectively hold the first private key component and the second private key component of the private key in the collaborative signature system; the device includes: a verification data calculation module 510, which is used to determine the data to be verified based on key parameters, wherein the key parameters include: the first private key component, the public key corresponding to the private key and a random number; the data to be verified includes: first data and second data; a first sending module 520, which is used to send the data to be verified to the second terminal, so that the second terminal can determine whether the second private key component matches the first private key component based on the data to be verified.

[0092] Please refer to Figure 6 , Figure 6 A block diagram illustrating the components of an apparatus for proving possession of a private key component in a collaborative signature, as provided in some embodiments of the present application, is provided. It should be understood that the apparatus for proving possession of a private key component in a collaborative signature corresponds to the aforementioned method embodiment and is capable of executing each step involved in the aforementioned method embodiment. The specific functions of the apparatus for proving possession of a private key component in a collaborative signature can be found in the description above, and a detailed description is omitted here to avoid repetition.

[0093] Figure 6 The device for proving the possession of a private key component in a collaborative signature includes at least one software functional module that can be stored in a memory in the form of software or firmware or solidified in the device for proving the possession of a private key component in a collaborative signature. The device for proving the possession of a private key component in a collaborative signature is applied to a second terminal in a collaborative signature system, and the collaborative signature system also includes a first terminal; the first terminal and the second terminal respectively hold a first private key component and a second private key component of a private key in the collaborative signature system; the device includes: a second receiving module 610, for receiving data to be verified sent by the first terminal, wherein the data to be verified includes: first data and second data; a verification parameter calculation module 620, for determining a verification parameter based on the second private key component and the data to be verified; a verification result output module 630, for confirming whether the second private key component matches the first private key component based on the verification parameter and the data to be verified.

[0094] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working process of the device described above can refer to the corresponding process in the aforementioned method, and will not be described in detail here.

[0095] Some embodiments of the present application further provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the operations corresponding to any of the above methods provided in the above embodiments.

[0096] Some embodiments of the present application further provide a computer program product, which includes a computer program, wherein when the computer program is executed by a processor, it can implement the operations corresponding to any of the above methods provided in the above embodiments.

[0097] like Figure 7 As shown, some embodiments of the present application provide an electronic device 700, which includes: a memory 710, a processor 720, and a computer program stored in the memory 710 and executable on the processor 720, wherein the processor 720 can implement a method as described in any of the above embodiments when reading the program from the memory 710 through the bus 730 and executing the program.

[0098] Processor 720 can process digital signals and can include various computing architectures, such as a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements a combination of multiple instruction sets. In some examples, processor 720 can be a microprocessor.

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

[0100] The foregoing is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included within the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined or explained in subsequent figures.

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

[0102] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

Claims

1. A method for proving possession of a private key component in a collaborative signature, characterized in that: The method is applied to a first terminal in a collaborative signature system, the collaborative signature system also including a second terminal; the first terminal and the second terminal respectively hold a first private key component and a second private key component of a private key in the collaborative signature system; the method includes: Determine the data to be verified based on key parameters, wherein the key parameters include: the first private key component, the public key corresponding to the private key, and a random number; the data to be verified includes: first data and second data; The data to be verified is sent to the second terminal, so that the second terminal determines whether the second private key component matches the first private key component based on the data to be verified; the second terminal is used to confirm whether the second private key component matches the first private key component by determining whether a verification parameter calculated for the second private key component and the first data is the same as the second data; or the second terminal is used to confirm whether the second private key component matches the first private key component by determining whether a verification parameter calculated for the second private key component and the second data is the same as the first data.

2. The method according to claim 1, wherein The first terminal is a server and the second terminal is a client; or, the first terminal is a client and the second terminal is a server.

3. The method according to claim 1 or 2, wherein: The determining of the data to be verified based on the key parameters includes: Calculating the first private key component, the public key, the random number, and a base point of an elliptic curve whose order is a prime number to obtain the first data; The random number and the base point are calculated to obtain the second data; wherein the calculation result of the second private key component and the first data is the same as the second data; and the calculation result of the second private key component and the second data is the same as the first data.

4. A method for proving possession of a private key component in a collaborative signature, characterized in that: The method is applied to a second terminal in a collaborative signature system, wherein the collaborative signature system further includes a first terminal; the first terminal and the second terminal respectively hold a first private key component and a second private key component of a private key in the collaborative signature system; the method includes: Receiving data to be verified sent by the first terminal, wherein the data to be verified is obtained by the method according to any one of claims 1 to 3; the data to be verified includes: first data and second data; determining a verification parameter based on the second private key component and the data to be verified; confirming, based on the verification parameter and the data to be verified, whether the second private key component matches the first private key component; The confirming, based on the verification parameter and the data to be verified, whether the second private key component matches the first private key component includes: confirming whether the private key component matches the first private key component by determining whether the verification parameter calculated from the second private key component and the first data is the same as the second data; or Whether the private key component matches the first private key component is confirmed by determining whether the verification parameter calculated based on the second private key component and the second data is the same as the first data.

5. The method according to claim 4, wherein The first terminal is a server and the second terminal is a client; or, the first terminal is a client and the second terminal is a server.

6. A device for proving possession of a private key component in a collaborative signature, characterized in that: The device is configured to execute the method according to claim 1; the device is applied to a first terminal in a collaborative signature system, the collaborative signature system further comprising a second terminal; the first terminal and the second terminal respectively hold a first private key component and a second private key component of a private key in the collaborative signature system; The device comprises: A verification data calculation module, configured to determine data to be verified based on key parameters, wherein the key parameters include: the first private key component, a public key corresponding to the private key, and a random number; the data to be verified includes: first data and second data; The first sending module is configured to send the data to be verified to the second terminal, so that the second terminal determines whether the second private key component matches the first private key component based on the data to be verified.

7. A device for proving possession of a private key component in a collaborative signature, characterized in that: The apparatus is configured to execute the method according to claim 4; the apparatus is applied to a second terminal in a collaborative signature system, the collaborative signature system further comprising a first terminal; the first terminal and the second terminal respectively hold a first private key component and a second private key component of a private key in the collaborative signature system; the apparatus comprises: A second receiving module is configured to receive data to be verified sent by the first terminal, wherein the data to be verified is obtained by the method according to any one of claims 1 to 3; the data to be verified includes: first data and second data; a verification parameter calculation module, configured to determine a verification parameter based on the second private key component and the data to be verified; A verification result output module is used to confirm whether the second private key component matches the first private key component based on the verification parameters and the data to be verified.

8. An electronic device, characterized in that: The method comprises a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the computer program executes the method according to any one of claims 1 to 5 when run by the processor.

Images